Hello, I have just released my first app called College Football Fight Songs. It is obviously an app that plays all of the college football fight songs. I am a beginner programmer with little experience and have been testing it on a Nexus S 2.3.4 throughout my development. It has worked perfectly even after releasing the app on the Market.
The only problem is that for some reason, it does not work on all devices for whatever reason. I am very confused and don't quite know what to do. It has been made for Android 2.1 and up, and works perfectly on my Nexus S.
The problem with other devices is that when either going to another screen, or going back from a screen, it force closes.
I would like any feedback regarding this problem, or any criticism that you can offer on my app, thanks!
Because I do not have very many posts, I cannot post a link to the Market or even a QR code, but if you just search "College Football Fight Songs" or "Eric Carboni" in the Market, my app is there.
Thanks
Can anyone help?
Sent from my Nexus S using XDA Premium App
ericcarboni said:
Can anyone help?
Sent from my Nexus S using XDA Premium App
Click to expand...
Click to collapse
I'll take a look later tonight after the kids go to sleep and see if I can recreate the fc. If it is in the market have you looked at the error reports and the stack traces?
Sent from my Nexus S using XDA Premium App
I grabbed it quick.....some initial impressions:
It's huge. You should reduce the package size if possible. Make each conference downloadable as a package possibly. You can leverage the market for this. 30 MB is a *large* app especially if I only want a few fight songs.
Since I can't recreate the fc I'll ask a few questions.
How are you handling the player resources in your onPause and onResume methods ?
How are you allocating new resources to play? Are you checking if it is already in use and calling stop before trying to play?
Do you have any error reports that you could post the stack trace from?
Sent from my Nexus S using XDA Premium App
First I just wanted to say thanks for taking the time to help me out with this. Also, I want to say how amazing your NFC Task app is: I've had it for a while now and I've been using it with some key chain tags. I love it.
Yes, I know it is huge. In fact, it is one of the biggest apps I have on my device. After I fix this problem, I will work on making each conference downloadable.
Right now, with my experience with Java, everything I have done with the playing and pausing is really basic. I am not checking if it is already in use to stop it before playing. Right now I have this -- once you are in the 'now playing' screen, I have the onPause method to stop each song from playing. I assumed there was a simpler way to do this..
But anyways, right now, there is one error report that I've gotten. I don't really understand it, but right now all I've gotten out of it is that the error is on the onPause action.
This is the stack trace for that report:
java.lang.RuntimeException: Unable to pause activity {com.carboni.fightsongs/com.carboni.fightsongs.BIG12}: java.lang.NullPointerException
at android.app.ActivityThread.performPauseActivity(ActivityThread.java:3348)
at android.app.ActivityThread.performPauseActivity(ActivityThread.java:3305)
at android.app.ActivityThread.handlePauseActivity(ActivityThread.java:3288)
at android.app.ActivityThread.access$2500(ActivityThread.java:125)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2044)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:123)
at android.app.ActivityThread.main(ActivityThread.java:4627)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:521)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:893)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:651)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.NullPointerException
at com.carboni.fightsongs.BIG12.onPause(BIG12.java:159)
at android.app.Activity.performPause(Activity.java:3842)
at android.app.Instrumentation.callActivityOnPause(Instrumentation.java:1190)
at android.app.ActivityThread.performPauseActivity(ActivityThread.java:3335)
... 12 more
Any other help you can give me is greatly appreciated, thank you very much
ericcarboni said:
First I just wanted to say thanks for taking the time to help me out with this. Also, I want to say how amazing your NFC Task app is: I've had it for a while now and I've been using it with some key chain tags. I love it.
Yes, I know it is huge. In fact, it is one of the biggest apps I have on my device. After I fix this problem, I will work on making each conference downloadable.
Right now, with my experience with Java, everything I have done with the playing and pausing is really basic. I am not checking if it is already in use to stop it before playing. Right now I have this -- once you are in the 'now playing' screen, I have the onPause method to stop each song from playing. I assumed there was a simpler way to do this..
But anyways, right now, there is one error report that I've gotten. I don't really understand it, but right now all I've gotten out of it is that the error is on the onPause action.
This is the stack trace for that report:
java.lang.RuntimeException: Unable to pause activity {com.carboni.fightsongs/com.carboni.fightsongs.BIG12}: java.lang.NullPointerException
at android.app.ActivityThread.performPauseActivity(ActivityThread.java:3348)
at android.app.ActivityThread.performPauseActivity(ActivityThread.java:3305)
at android.app.ActivityThread.handlePauseActivity(ActivityThread.java:3288)
at android.app.ActivityThread.access$2500(ActivityThread.java:125)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2044)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:123)
at android.app.ActivityThread.main(ActivityThread.java:4627)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:521)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:893)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:651)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.NullPointerException
at com.carboni.fightsongs.BIG12.onPause(BIG12.java:159)
at android.app.Activity.performPause(Activity.java:3842)
at android.app.Instrumentation.callActivityOnPause(Instrumentation.java:1190)
at android.app.ActivityThread.performPauseActivity(ActivityThread.java:3335)
... 12 more
Any other help you can give me is greatly appreciated, thank you very much
Click to expand...
Click to collapse
Calling pause / stop in the onPause is probably best. You can likely stop it instead of pausing it. The garbage collection should take care of freeing the resources as long as they are not in use when the Activity finishes.
This is the relevant error:
Code:
Caused by: java.lang.NullPointerException
at com.carboni.fightsongs.BIG12.onPause(BIG12.java:159)
I am guessing this is where you are accessing the player object in the onPause() method. However for whatever reason the object is null. It's a good idea to do a null check on the object itself before operating on it.
For operations like this I'd also recommend a try / catch and logging the exception via Log.d or Log.e so that if there is an issue you can pull it from logcat. You can call Lod.d("TagName", "Error and info you want to print") as well we e.printStackTrace() assuming you've named the Exception that is caught e. This will help log info for users (or yourself) for more useful debugging info.
Essentially you want to prevent your app from crashing on non show stopper exceptions. By wrapping these operations in try/catch blocks you're able to gracefully handle the exceptions and move on with your application without FCing.
Using try/catch blocks is really cheap (from an operational perspective) for small apps like this. The catch is the most expensive part, but it will really help you to gracefully handle issues that arise and eliminate force closes.
If you're having trouble tracking down the issue I'll take a look at the source if you want to zip/rar it up and send it over.
Which operations would I wrap a try/catch around?
Thanks for all your help, I think I might send you the source code eventually if I can't figure it out.
And I have a question: why would the app work perfectly on Gingerbread but not other phones with Froyo? Just curious to why this is
ericcarboni said:
Which operations would I wrap a try/catch around?
Thanks for all your help, I think I might send you the source code eventually if I can't figure it out.
And I have a question: why would the app work perfectly on Gingerbread but not other phones with Froyo? Just curious to why this is
Click to expand...
Click to collapse
Honestly - wrap any operations that may result in an exception being thrown (within reason). Depending on your experience this may or may not be something you'll be able to see easily or not. You'll learn quite a bit by trial and error
Generally though if you're dealing with resources that may or may not be available (even if they should *always* be available) it doesn't hurt to wrap them in a try/catch in case an exception is thrown.
Any time you are parsing potentially invalid input and / or casting data it's good to try/catch and handle any exceptions that may creep up.
Some of the audio code (libaudio or libmedia) was changed from Froyo to Gingerbread - you're also working with potential issues from Rosie(Sense)/Touchwiz/Blur. Most of these frameworks make alterations to the subsystems in some form or another and do not always behave in the same manner as an AOSP rom 100 % of the time. You're also dealing with varying devices with varying amounts of resources and multiple services competing for these resources.
In the SDK documentation the classes themselves will show what exceptions are thrown - these are thrown to prevent the app/subsystem from crashing or getting unexpected results. It is your job as the developer to catch these exceptions and handle them.
Obviously it's wasteful to try/catch everything - there's no reason, for example, to try catch the overloaded ++ operator for an integer. If you are doing string manipulation on user input though then you should be doing some sanity checking / handling of exceptions as you may get completely unexpected and bad data.
Any time you are dealing with system resources you'll want to verify that the resource did properly get assigned and handle the exceptions that it may throw as a good practice though.
For example, when you play a media file you are counting on:
The DSP device being availble
The handle to the device being appropriately acquired
The resource to be played being present and properly allocated
The playing of this resource to be properly executed by the subsystem
If any of these things goes wrong then an exception is going to be raised by the subsystem so that it can be handled in your application. If you do not handle the exception your app crashes and you FC. If you handle it though you can deal with it as is appropriate and move on (e.g: inform the user there was an error, log the exception and move on).
ich habe das gleiche problem!!
I've been working on it; do you think using a try/catch for the exceptions that need it will solve the problem completely?
Sent from my Nexus S using XDA Premium App
ericcarboni said:
I've been working on it; do you think using a try/catch for the exceptions that need it will solve the problem completely?
Sent from my Nexus S using XDA Premium App
Click to expand...
Click to collapse
Yes, assuming you're not doing something crazy with the object or resources - your app is FC's because an exception is being raised and not handled. By catching and handling the exception (assuming there isn't an issue with the underlying code) you are able to programmatically deal with these issues.
krohnjw said:
Yes, assuming you're not doing something crazy with the object or resources - your app is FC's because an exception is being raised and not handled. By catching and handling the exception (assuming there isn't an issue with the underlying code) you are able to programmatically deal with these issues.
Click to expand...
Click to collapse
I have done a few, and now it works on a 2.2 emulator, but not on a 2.1, or a 2.2 Galaxy S.. Do you think if I send the project to you, could you take a quick look at it? You've been a lot of help, I appreciate it
Related
There are many C++/CX codes in my Windows Phone 8 app so there might be many dangling pointers access which will cause AccessViolationException. Actually I know that __try & __except can catch them but I hope that my app can get notified like some callback function can get called while AccessViolationException raised that it's NOT surrounding by __try __except.
And I have tried Application.UnhandledException in C# code and ::SetUnhandledExceptionFilter(which is private API and I somehow successfully invoke it) but still failed to get called.
So is there any way to get notified while AccessViolationException is raised?
In case somebody has the same problem, I solve my problem by using _set_se_translator, a crt API
Ooh, details on that would be good (OK, I should just go read the docs...) but thanks for posting the solution! C++/CX has way too many modes of memory management; it's pretty easy to get it wrong if you try doing anything even vaguely outside the standard use cases. (Example: Do not malloc an array of Platform::String and then assign to it. Any non-nulls in the array (leftover data from prior allocations) will be treated as though they are valid strings that you are assigning over, which means the "old string's" reference count will be decremented, which may lead to memory corruption. Using calloc instead works, by the way, though it's still kind of a hack.) Anyhow, debugging that stuff is annoying, especially since you can only debug native *or* managed, not both.
(I am new and cannot post in dev forum, that's why I posted this here. Still hope someone will be able to help.)
Is there a way to get crash-dumps out of Windows Phone 8 during development time? I am after a file that is dumped similarly to when a normal Win32 app crashes. Or similar to what is saved on iOS devices at crash to be investigated at a later point.
My question is specifically about somehow retrieving this (or similar) file/info from the phone after a crash without me having to do anything in my code e.g. manually writing the stack trace to a file from an unhandled exception.
I am aware the option of getting "live" crash reports from a beta-submitted app but that is not what I am after.
Thanks!
Can Visual Studio's debugger generate crash dumps? I'd expect so (I know windbg can, but I haven't managed to attach windbg to a phone app) and that would be the obvious approach.
Not sure why you want a dump when you can do live debugging, though...
GoodDayToDie said:
Can Visual Studio's debugger generate crash dumps? I'd expect so (I know windbg can, but I haven't managed to attach windbg to a phone app) and that would be the obvious approach.
Not sure why you want a dump when you can do live debugging, though...
Click to expand...
Click to collapse
Hmmm, I never thought of using windbg because that never came up as a tool that is used with WP8.. Will give it a try and see if I get anywhere.
I need a crash dump because the crash does not happen when a debugger is attached.
I am trying other options to catch the issue: isolating the code the crash might happen, dump the stack trace into a log file, but a crash log would be the most obvious place to look at and I am shocked that it is not possible or at least this hard.
There's a way on the ATIV S to get crash dumps (without even crazy hacks, I mean; it's a hidden option in the Diagnosis application) but I think they're only for the OS, not for individual apps.
A crash that only happens without the debugger attached is a very irritating sort of crash!
GoodDayToDie said:
There's a way on the ATIV S to get crash dumps (without even crazy hacks, I mean; it's a hidden option in the Diagnosis application) but I think they're only for the OS, not for individual apps.
A crash that only happens without the debugger attached is a very irritating sort of crash!
Click to expand...
Click to collapse
Amazing, I have access to an Ativ S device so will give a try! Thanks!
I have got a confirmation directly from Windows Phone team: what I am asking for is not possible at the moment.
I have provided them feedback on what kind of situation this can put some developers, I hope they will consider it and look into doing something about it.
In the meantime your options are to manually dump the stack trace (along with any info you want) from an unhandled exception or to upload your app for beta testing and check the crashlogs on the dashboard of your developer account.
Yeah, sorry. I should have mentioned that my approach is to always implement a custom unhandled exception function (there's a stub for it in App.xaml.cs) and either present an error message or write an error file. It's not a true crash dump, but it's often enough to help you find the spot where the problem occurred.
Hmm... I wonder how hard it would be to write a native component that would generate a crash dump on demand. I mean, it *should* be possible to do it, since you have raw pointer access and file I/O. I've just never tried.
ART Explained http://source.android.com/devices/tech/dalvik/art.html
ART Features
Ahead-of-time (AOT) compilation
Improved garbage collection
Development and debugging improvements
Known Issues
Fixed issues
Enabling ART in Android Build
Reporting Problems
See also
Verifying App Behavior on the Android Runtime (ART)
ART is a new Android runtime being introduced experimentally in the 4.4 release. This is a preview of work in progress in KitKat that can be turned on in Settings > developer options. This is available for the purpose of obtaining early developer and partner feedback.
Important: Dalvik must remain the default runtime or you risk breaking your Android implementations and third-party applications.
Most existing apps should just work when running with ART. However, some techniques that work on Dalvik do not work on ART. For information about the most important issues, see Verifying App Behavior on the Android Runtime (ART).
ART Features
Here are some of the major new features implemented by ART.
Ahead-of-time (AOT) compilation
ART introduces ahead-of-time (AOT) compilation, which can improve app performance. ART also has tighter install-time verification than Dalvik.
At install time, ART compiles apps using the on-device dex2oat tool. This utility accepts DEX files as input and generates a compiled app executable for the target device. The utility should be able to compile all valid DEX files without difficulty. However, some post-processing tools produce invalid files that may be tolerated by Dalvik but cannot be compiled by ART. For more information, see Addressing Garbage Collection Issues.
Improved garbage collection
Garbage collection (GC) can impair an app's performance, resulting in choppy display, poor UI responsiveness, and other problems. ART improves garbage collection in several ways:
One GC pause instead of two
Parallelized processing during the remaining GC pause
Collector with lower pause time for the special case of cleaning up recently-allocated, short-lived objects
Improved garbage collection ergonomics, making concurrent garbage collections more timely, which makes GC_FOR_ALLOC events extremely rare in typical use cases
ART currently does not use compacting GC, but this feature is under development in the Android Open Source Project (AOSP). In the meantime, don't perform operations that are incompatible with compacting GC, such as storing pointers to object fields. For more information, see Addressing Garbage Collection Issues.
Development and debugging improvements
ART offers a number of features to improve app development and debugging.
Support for sampling profiler
Historically, developers have used the Traceview tool (designed for tracing application execution) as a profiler. While Traceview gives useful information, its results on Dalvik have been skewed by the per-method-call overhead, and use of the tool noticeably affects run time performance.
ART adds support for a dedicated sampling profiler that does not have these limitations. This gives a more accurate view of app execution without significant slowdown. Sampling support has also been added to Traceview for Dalvik.
Support for more debugging features
ART supports a number of new debugging options, particularly in monitor- and garbage collection-related functionality. For example, you can:
See what locks are held in stack traces, then jump to the thread that holds a lock.
Ask how many live instances there are of a given class, ask to see the instances, and see what references are keeping an object live.
Filter events (like breakpoint) for a specific instance.
See the value returned by a method when it exits (using “method-exit” events).
Set field watchpoint to suspend the execution of a program when a specific field is accessed and/or modified.
Improved diagnostic detail in exceptions and crash reports
ART gives you as much context and detail as possible when runtime exceptions occur. ART provides expanded exception detail for java.lang.ClassCastException, java.lang.ClassNotFoundException, and java.lang.NullPointerException. (Later versions of Dalvik provided expanded exception detail for java.lang.ArrayIndexOutOfBoundsException and java.lang.ArrayStoreException, which now include the size of the array and the out-of-bounds offset, and ART does this as well.)
For example, java.lang.NullPointerException now shows information about what the app was trying to do with the null pointer, such as the field the app was trying to write to, or the method it was trying to call. Here are some typical examples:
java.lang.NullPointerException: Attempt to write to field 'int
android.accessibilityservice.AccessibilityServiceInfo.flags' on a null object
reference
java.lang.NullPointerException: Attempt to invoke virtual method
'java.lang.String java.lang.Object.toString()' on a null object reference
ART also provides improved context information in app native crash reports, by including both Java and native stack information.
Known Issues
The following known issues are present in the 4.4.1 implementation of ART.
Compile-time issue: As noted above, ART flags unbalanced monitorenter/moniterexit instructions. We relaxed this check in 4.4.1 but intend to restore this verification in the future once tools are fixed, as this check is necessary for certain compiler optimizations. https://code.google.com/p/android/issues/detail?id=61916
Run-time issue: There was an issue where JNI GetFieldID and GetStaticFieldID were using the wrong class loader on unattached threads, often leading to later CheckJNI errors or NoSuchFieldError exceptions. http://code.google.com/p/android/issues/detail?id=63970
Run-time issue: Calling JNI NewDirectByteBuffer() with byte size of 0 led to the following CheckJNI error:
JNI DETECTED ERROR IN APPLICATION: capacity must be
greater than 0: 0
http://code.google.com/p/android/issues/detail?id=63055
Fixed issues
Compile-time issue: Overly aggressive verification and compilation of unused portions of dex files lead to corrupt package messages. This was addressed in AOSP with: https://android-review.googlesource.com/#/c/72374/
Debug-time issue: Interactive debugging performance was slow, even in code without breakpoints. This has been addressed in the latest AOSP code.
Enabling ART in Android Build
Two runtimes are now available, the existing Dalvik runtime (libdvm.so) and the ART runtime (libart.so). A device can be built using either or both runtimes. (You can dual boot from Developer options if both runtimes are installed.) See runtime_common.mk. That is included from build/target/product/runtime_libdvm.mk or build/target/product/runtime_libdvm.mk or both.
The dalvikvm command line tool can run with either runtime now. It will default to using the runtime specified in developer options. The default can be overridden by specifying the desired runtime library, for example with -XXlib:libart.so
A new PRODUCT_RUNTIMES variable controls which runtimes are included in a build. Include it within either build/target/product/core_minimal.mk or build/target/product/core_base.mk.
Add this to the device makefile to have both runtimes built and installed, with Dalvik as the default:
PRODUCT_RUNTIMES := runtime_libdvm_default
PRODUCT_RUNTIMES += runtime_libart
Reporting Problems
If you run into any issues that aren’t due to app JNI issues, please report them via the Android Open Source Project Issue Tracker at https://code.google.com/p/android/issues/list. Please include an "adb bugreport" and link to the app in Google Play store if available. Otherwise, if possible, attach an APK that reproduces the issue. Please note that issues (including attachments) are publicly visible.
Except as noted, this content is licensed under Creative Commons Attribution 2.5. For details and restrictions, see the Content License.
About Android | Community | Legal |
Click to expand...
Click to collapse
Another great post from simms no surprises there lol great detailed explanation thanks.
Sent from my Nexus 5 using XDA Premium 4 mobile app
sharingan92 said:
Another great post from simms no surprises there lol great detailed explanation thanks.
Sent from my Nexus 5 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Dude he is just quoting the developer page for art written by someone at Google, he even used quotation and everything.
It's a good page nevertheless and its nice to have it posted here.
mortenmhp said:
Dude he is just quoting the developer page for art written by someone at Google, he even used quotation and everything.
It's a good page nevertheless and its nice to have it posted here.
Click to expand...
Click to collapse
I never stated it was his own words i was merely stating the fact that once again simms has posted something people would like to read to understand android a little more just like all the information he gives users over on the trinity thread
Sent from my Nexus 5 using XDA Premium 4 mobile app
sharingan92 said:
I never stated it was his own words i was merely stating the fact that once again simms has posted something people would like to read to understand android a little more just like all the information he gives users over on the trinity thread
Sent from my Nexus 5 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I've been using this runtime for several months and I'm very happy! Thanks a lot
So, what's art again? Hahahahaha. Jk. Cool, well done simms. [emoji12]
Sent from my Nexus 5 using Tapatalk
Before I go through the pain of enabling ART, only to have to disable it again, are there any common apps that are known to be incompatible at this point?
Last time when I tried ART, Whatsapp wouldn't run.
Ender666666 said:
Before I go through the pain of enabling ART, only to have to disable it again, are there any common apps that are known to be incompatible at this point?
Last time when I tried ART, Whatsapp wouldn't run.
Click to expand...
Click to collapse
That was 7 months ago!
Sent from my Nexus 5
Good to know how long it's been, but it doesn't fly answer the question... I am wondering if everything is hunky dorry, or if there are any common apps that remain broken. WhatsApp was just a single example.
Sent from my Nexus 5 using Tapatalk
I don't use whatsapp, but I have used ART since a week after the Nexus 5 came out.
I have experienced absolutely zero downsides. Everyone's usage is different, but even 6 months ago many people were saying that ART worked great for them. I would say most even.
Whatsapp is a common app, don't get me wrong...but since literally every other app I have ever loaded on my phone works perfectly...I'm of the opinion that some people "blame" ART.
If even freeware apps that have been written and not touched by the developer for 2 years can run just fine in ART, than whatsapp has no excuse for it not having gotten its ducks in a row. (Maybe it has now, I don't know...like I said, I don't use whatsapp)
Granted, if I picked up your phone and switched it to ART, and lets assume you didn't have any of those apps that for whatever reason didn't work well with ART....
I seriously doubt you would even realize I had switched it.
Cirkustanz said:
I don't use whatsapp, but I have used ART since a week after the Nexus 5 came out.
I have experienced absolutely zero downsides. Everyone's usage is different, but even 6 months ago many people were saying that ART worked great for them. I would say most even.
Whatsapp is a common app, don't get me wrong...but since literally every other app I have ever loaded on my phone works perfectly...I'm of the opinion that some people "blame" ART.
If even freeware apps that have been written and not touched by the developer for 2 years can run just fine in ART, than whatsapp has no excuse for it not having gotten its ducks in a row. (Maybe it has now, I don't know...like I said, I don't use whatsapp)
Granted, if I picked up your phone and switched it to ART, and lets assume you didn't have any of those apps that for whatever reason didn't work well with ART....
I seriously doubt you would even realize I had switched it.
Click to expand...
Click to collapse
i use whatsapp, and it works perfectly fine when i use art. the only app that doesnt work for me on art is pandora.
simms22 said:
i use whatsapp, and it works perfectly fine when i use art. the only app that doesnt work for me on art is pandora.
Click to expand...
Click to collapse
Pandora 5.0+ works on art
sent from my Paranoid Rasta HAMMERHEAD
CRIME INC. said:
Pandora 5.0+ works on art
sent from my Paranoid Rasta HAMMERHEAD
Click to expand...
Click to collapse
yup, so ive heard. not here. i boot up, it force closes on boot, and thats all she wrote.
simms22 said:
yup, so ive heard. not here. i boot up, it force closes on boot, and thats all she wrote.
Click to expand...
Click to collapse
Are you running a modified Pandora apk by chance simms? I've seen that ART does not play well with modified apks.
Sent from my Nexus 5 using Tapatalk
Cirkustanz said:
I don't use whatsapp, but I have used ART since a week after the Nexus 5 came out.
I have experienced absolutely zero downsides. Everyone's usage is different, but even 6 months ago many people were saying that ART worked great for them. I would say most even.
Whatsapp is a common app, don't get me wrong...but since literally every other app I have ever loaded on my phone works perfectly...I'm of the opinion that some people "blame" ART.
If even freeware apps that have been written and not touched by the developer for 2 years can run just fine in ART, than whatsapp has no excuse for it not having gotten its ducks in a row. (Maybe it has now, I don't know...like I said, I don't use whatsapp)
Granted, if I picked up your phone and switched it to ART, and lets assume you didn't have any of those apps that for whatever reason didn't work well with ART....
I seriously doubt you would even realize I had switched it.
Click to expand...
Click to collapse
not really. I guess I feel a difference between Dalvik and ART and it was quite obvious, I must say. I felt like there's something missing when I'm on Dalvik. Especially when I'm using the recent app button. Dalvik is just slower than ART on that.
akash3656 said:
Are you running a modified Pandora apk by chance simms? I've seen that ART does not play well with modified apks.
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
yup :angel:
Not sure if anyone watches baseball at all, but the MLB app will not stream video on ART. Crashes every time. I've had to revert to Dalvik for it to work properly.
The only apps I've had problems with are QuizUp (when it first came out, since fixed), and Google Sound Search (had to disable it...Google Now has the functionality built in now..). Amazingly better battery life.
simms22 said:
yup :angel:
Click to expand...
Click to collapse
Then that's probably why it doesn't work haha. If you bother you could try out the official apk and it might work.
Note: I don't use Pandora myself. Don't think it's available at my region.
Sent from my Nexus 5 using Tapatalk
---------- Post added at 03:41 PM ---------- Previous post was at 03:39 PM ----------
zander21510 said:
The only apps I've had problems with are QuizUp (when it first came out, since fixed), and Google Sound Search (had to disable it...Google Now has the functionality built in now..). Amazingly better battery life.
Click to expand...
Click to collapse
Hmmm. Not saying you're wrong. In my experience, using ART seems to have about the same battery life as dalvik. Or a little worse.
It might be just my setup and personally I don't worry too much about the little extra drain.
Sent from my Nexus 5 using Tapatalk
Well it's official! Just read an article on XDA portal. Google is replacing dalvik with art finally. I guess the changes were added to AOSP for the next OS.
check it out, top story on xda portal right now!
I'm trying to load in a static XSharedPreferences instance in a separate class via
Code:
private static XSharedPreferences prefs = new XSharedPreferences(BuildConfig.PACKAGE_NAME);
Everything compiles, but at runtime I'm given:
Code:
09-27 08:59:26.929 24976-24976/com.versobit.kmark.xhangouts E/AndroidRuntime﹕ FATAL EXCEPTION: main
Process: com.versobit.kmark.xhangouts, PID: 24976
java.lang.NoClassDefFoundError: de.robv.android.xposed.XSharedPreferences
at com.versobit.kmark.xhangouts.XApp.<clinit>(XApp.java:33)
at java.lang.Class.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1208)
at android.app.Instrumentation.newApplication(Instrumentation.java:990)
at android.app.Instrumentation.newApplication(Instrumentation.java:975)
at android.app.LoadedApk.makeApplication(LoadedApk.java:509)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4446)
at de.robv.android.xposed.XposedBridge.invokeOriginalMethodNative(Native Method)
at de.robv.android.xposed.XposedBridge.handleHookedMethod(XposedBridge.java:631)
at android.app.ActivityThread.handleBindApplication(Native Method)
at android.app.ActivityThread.access$1500(ActivityThread.java:144)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1265)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5146)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:732)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:566)
at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:132)
at dalvik.system.NativeStart.main(Native Method)
Been at this for four or five hours and I'm out of ideas. I'm correctly providing the BridgeApi file in my gradle build. I've even tried loading in the jar manually and using reflection, but that doesn't seem to work properly. The class will load but nothing is read.
Are you trying to import that in a non Xposed class? AFAIK, it'll only work for classes loaded by Xposed.
GermainZ said:
Are you trying to import that in a non Xposed class? AFAIK, it'll only work for classes loaded by Xposed.
Click to expand...
Click to collapse
Yep. That's unfortunate. I was under the false impression that Xposed injected itself into every class loader context. It does modify the system classpath but that doesn't seem to have any effect on Dalvik apps. Here's my long-winded solution.
Thanks for the help.
Kevin M said:
Yep. That's unfortunate. I was under the false impression that Xposed injected itself into every class loader context. It does modify the system classpath but that doesn't seem to have any effect on Dalvik apps. Here's my long-winded solution.
Thanks for the help.
Click to expand...
Click to collapse
For what's it's worth, pretty much all modules use MAKE_WORLD_READABLE. IIRC, XSharedPreferences also has a helper to set that if it isn't already.
Edit: also, XSharedPreferences isn't very different from SharedPreferences. From memory, the only differences are a few extra helpers and read only support.
GermainZ said:
For what's it's worth, pretty much all modules use MAKE_WORLD_READABLE. IIRC, XSharedPreferences also has a helper to set that if it isn't already.
Click to expand...
Click to collapse
I found the usage of WORLD_READABLE common while looking around for ideas, but didn't notice the helper function somehow, after pouring over the source. Now that I'm looking at it again my concern is that the XSharedPreferences instance is running with the same permissions as my module, which certainly doesn't have the permissions required to chmod files owned by other users when running in the hooked process.
Kevin M said:
I found the usage of WORLD_READABLE common while looking around for ideas, but didn't notice the helper function somehow, after pouring over the source. Now that I'm looking at it again my concern is that the XSharedPreferences instance is running with the same permissions as my module, which certainly doesn't have the permissions required to chmod files owned by other users when running in the hooked process.
Click to expand...
Click to collapse
Wouldn't you be able to get (or create) an instance of SharedPreferences and edit what you want in that case, though?
Or get a Context and use that if it's not a preference file you're interested in.
GermainZ said:
Wouldn't you be able to get (or create) an instance of SharedPreferences and edit what you want in that case, though?
Or get a Context and use that if it's not a preference file you're interested in.
Click to expand...
Click to collapse
Unless I have a Context to my own application when my hook is running I don't see that working. The only time a Context to my app would even be alive would be when the PreferenceActivity was loaded. When my hook is running it's running inside the other application's process so I can't just spawn a SharedPreference to what is now a foreign resource.
Kevin M said:
Unless I have a Context to my own application when my hook is running I don't see that working. The only time a Context to my app would even be alive would be when the PreferenceActivity was loaded. When my hook is running it's running inside the other application's process so I can't just spawn a SharedPreference to what is now a foreign resource.
Click to expand...
Click to collapse
Ah, I misunderstood what you wanted. Basically I'd do something like this:
If I'm trying to access the hooked app's files, get a Context from the hooked app.
If I'm trying to access my own app's files, get a Context from the hooked app then use IPC (e.g. a BroadcastReceiver for my app, and use Context.sendBroadcast() from the hooked app).
I think you want the second but that's what you're doing currently if I'm not mistaken.
GermainZ said:
Ah, I misunderstood what you wanted. Basically I'd do something like this:
If I'm trying to access the hooked app's files, get a Context from the hooked app.
If I'm trying to access my own app's files, get a Context from the hooked app then use IPC (e.g. a BroadcastReceiver for my app, and use Context.sendBroadcast() from the hooked app).
I think you want the second but that's what you're doing currently if I'm not mistaken.
Click to expand...
Click to collapse
Yep, just used a ContentProvider/Resolver instead. :good:
I have a brand new kindle fire 7, just did the steps for installing Google play store, installed a few apps but the gmail app won't stay open and work.... What do I do now?
Same with me. I would love to find the answer to this. Thanks.
I'm having the same problem... Have tried most of the standard attempts to fix it. It did refresh the messages initially, but it still opens, then immediately closes. (Still shows it's running and have cleared that, rebooted, etc). Very frustrating! (Sorry.... probably the wrong thread, but's happening on my new Fire 8HD 2017 too)
Getting the same error here, so I did a logcat on it:
Code:
E/DatabaseUtils(15437): Writing exception to parcel
E/DatabaseUtils(15437): java.lang.SecurityException: Permission Denial: reading com.android.providers.downloads.DownloadProvider uri content://downloads/all_downloads/73 from pid=15497, uid=10016 requires android.permission.ACCESS_ALL_DOWNLOADS, or grantUriPermission()
E/DatabaseUtils(15437): at android.content.ContentProvider.enforceReadPermissionInner(ContentProvider.java:539)
E/DatabaseUtils(15437): at android.content.ContentProvider$Transport.enforceReadPermission(ContentProvider.java:452)
E/DatabaseUtils(15437): at android.content.ContentProvider$Transport.enforceFilePermission(ContentProvider.java:443)
E/DatabaseUtils(15437): at android.content.ContentProvider$Transport.openTypedAssetFile(ContentProvider.java:388)
E/DatabaseUtils(15437): at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:313)
E/DatabaseUtils(15437): at android.os.Binder.execTransact(Binder.java:446)
W/GAV2 (15497): Thread[Background tasks,5,main]: dispatch call queued. Need to call GAServiceManager.getInstance().initialize().
--------- beginning of crash
E/AndroidRuntime(15497): FATAL EXCEPTION: Background tasks
E/AndroidRuntime(15497): Process: com.google.android.gm, PID: 15497
E/AndroidRuntime(15497): java.lang.SecurityException: Permission Denial: reading com.android.providers.downloads.DownloadProvider uri content://downloads/all_downloads/73 from pid=15497, uid=10016 requires android.permission.ACCESS_ALL_DOWNLOADS, or grantUriPermission()
E/AndroidRuntime(15497): at android.os.Parcel.readException(Parcel.java:1548)
E/AndroidRuntime(15497): at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:185)
E/AndroidRuntime(15497): at android.database.DatabaseUtils.readExceptionWithFileNotFoundExceptionFromParcel(DatabaseUtils.java:148)
E/AndroidRuntime(15497): at android.content.ContentProviderProxy.openTypedAssetFile(ContentProviderNative.java:691)
E/AndroidRuntime(15497): at android.content.ContentResolver.openTypedAssetFileDescriptor(ContentResolver.java:1080)
E/AndroidRuntime(15497): at android.content.ContentResolver.openAssetFileDescriptor(ContentResolver.java:921)
E/AndroidRuntime(15497): at android.content.ContentResolver.openFileDescriptor(ContentResolver.java:778)
E/AndroidRuntime(15497): at android.content.ContentResolver.openFileDescriptor(ContentResolver.java:733)
E/AndroidRuntime(15497): at android.app.DownloadManager.openDownloadedFile(DownloadManager.java:1040)
E/AndroidRuntime(15497): at ene.a(SourceFile:636)
E/AndroidRuntime(15497): at ene.a(SourceFile:439)
E/AndroidRuntime(15497): at com.google.android.gm.job.DownloadCompleteJob.a(SourceFile:40)
E/AndroidRuntime(15497): at eks.run(Unknown Source)
E/AndroidRuntime(15497): at android.os.Handler.handleCallback(Handler.java:739)
E/AndroidRuntime(15497): at android.os.Handler.dispatchMessage(Handler.java:95)
E/AndroidRuntime(15497): at android.os.Looper.loop(Looper.java:135)
E/AndroidRuntime(15497): at android.os.HandlerThread.run(HandlerThread.java:61)
It appears that com.google.android.gm doesn't have the permissions it needs (ACCESS_ALL_DOWNLOADS), so I tried to grant this permission with:
Code:
adb shell pm grant com.google.android.gm android.permission.ACCESS_ALL_DOWNLOADS
but I got:
Code:
Operation not allowed: java.lang.SecurityException: Package com.google.android.gm has not requested permission android.permission.ACCESS_ALL_DOWNLOADS
Anyone find a solution to this?
Try disabling "Download attachments" under Gmail's account settings while disconnected from WiFi.
Zeranoe said:
Try disabling "Download attachments" under Gmail's account settings while disconnected from WiFi.
Click to expand...
Click to collapse
Yes, I tried that...
Having the same issue. Can we downgrade the gmail app or something?
cduced said:
Having the same issue. Can we downgrade the gmail app or something?
Click to expand...
Click to collapse
Nope - characteristic if the underlying components that Gmail relies on. Can't downgrade those; will either fail or immediately self-updating to latest version. Look to another mail client (many fine options in Play Store) or use web interface.
gmail app quits
same problem - same with inbox spp. starts for few seconds then goes away. is still running but not in screen!
---------- Post added at 04:51 PM ---------- Previous post was at 04:38 PM ----------
just got off the phone with Amazon. needless to say they do not troubleshoot Google's apps! Nice guy, second tier informed him. so either Google fixes this or we are SOL! Maybe if we get a long enuf thread here! Anyone here work for Google?
carlscheider said:
same problem - same with inbox spp. starts for few seconds then goes away. is still running but not in screen!
---------- Post added at 04:51 PM ---------- Previous post was at 04:38 PM ----------
just got off the phone with Amazon. needless to say they do not troubleshoot Google's apps! Nice guy, second tier informed him. so either Google fixes this or we are SOL! Maybe if we get a long enuf thread here! Anyone here work for Google?
Click to expand...
Click to collapse
Unlikely either party will pursue a 'fix' as Amazon and Google don't pursue mutual business objectives or cross validate apps. Especially hacks. Best option IMO is to consider a different mail app (there are many fine alternatives in the Play Store) or use the Gmail web interface (spartan but serviceable).
thanks
that makes perfect sense. i do use an email app but prefer gmail direct.
i will hold out hope. Had the same problem with Amazon's washington post - it finally fixed itself! found i could sometimes get it to work by just shutting it off normally.
i used to be a cto - crappy code lives forever. no attention to zero defect.
appreciate the wisdom. saves a few frustrating calls.
carlscheider said:
that makes perfect sense. i do use an email app but prefer gmail direct.
i will hold out hope. Had the same problem with Amazon's washington post - it finally fixed itself! found i could sometimes get it to work by just shutting it off normally.
i used to be a cto - crappy code lives forever. no attention to zero defect.
appreciate the wisdom. saves a few frustrating calls.
Click to expand...
Click to collapse
I suspect (but have no direct evidence to support) a new dependency on a core Google component not included with the basic Play Store install for this device (FireOS v5 in general). Haven't peeled back the onion to identify root cause as I do not run FireOS on any of my devices. Do have temporary access to a 'stock' HD 8. Will take a look if time permits.
Could simply be a version mismatch on Android code shared between FireOS and Google components. That would be a tougher fix on unrooted devices.
Davey126 said:
I suspect (but have no direct evidence to support) a new dependency on a core Google component not included with the basic Play Store install for this device (FireOS v5 in general). Haven't peeled back the onion to identify root cause as I do not run FireOS on any of my devices. Do have temporary access to a 'stock' HD 8. Will take a look if time permits.
Could simply be a version mismatch on Android code shared between FireOS and Google components. That would be a tougher fix on unrooted devices.
Click to expand...
Click to collapse
I am a little surprised too. You can download it from the Play Store from the tablet so it's not to do with compatibility I don't think. I had the same problem earlier with Weather Underground and I downgraded a few versions and it worked. Could be an update Amazon snuck by us too. The tablet kicks you out right after you setup Gmail. It's like you can do everything else except read your Email. It even still sends you notifications. I thought it was working after my reset an hour ago because of the notifications. I tapped the icon, it went to setup and when it got to the inbox, it kicks me out. I'll reinstall it later using an older version and see if it works. I don't worry about auto update as I don't let my play store apps auto update.
EDIT: I recall when I had my Fire 7 working, you could go back a few versions of an app and update it from the play store to most recent and that fixed the issue. Perhaps try that?
Old version - good thinking
Didn't realize I could do that. I grew up coding assembly language on an IBM 50 - left when Smalltalk and C++ were all the rage.
I will stop auto updates and see about getting an older version.
I am kind of amazed that Amazon allows this "side loading" - it isn't really a root - just a sidestep.
Glad it works. The Fire 8 is a marvelous little gadget for the price. It will change EVERYTHING - like FIRE..
And it makes Jeff just a bit richer - like he needs it.
Many thanks.
cannot regress in Fire
carlscheider said:
Didn't realize I could do that. I grew up coding assembly language on an IBM 50 - left when Smalltalk and C++ were all the rage.
I will stop auto updates and see about getting an older version.
.
Click to expand...
Click to collapse
OK, after a bit of a search, I found a repository of older versions.
Is this reliable? https://gmail.en.uptodown.com/android/old
I am on 7.7.2 - I see there is even a newer one.
OK, 7.5.21 lasts a little longer - not much.
7.5.7 nope. 7.4.23 , 6.11.27, nope.
I am going to stop for now. I did find that it seems useful to delete the storage BEFORE uninstalling. It's like the next install picks up on the existing memory and just uses it. If you delete that, it starts fresh. Not that it is getting me anywhere. Thanks. Later.
carlscheider said:
OK, after a bit of a search, I found a repository of older versions.
Is this reliable? https://gmail.en.uptodown.com/android/old
I am on 7.7.2 - I see there is even a newer one.
OK, 7.5.21 lasts a little longer - not much.
7.5.7 nope. 7.4.23 , 6.11.27, nope.
I am going to stop for now. I did find that it seems useful to delete the storage BEFORE uninstalling. It's like the next install picks up on the existing memory and just uses it. If you delete that, it starts fresh. Not that it is getting me anywhere. Thanks. Later.
Click to expand...
Click to collapse
Older versions are also available on APKMirror. Not that it matters as it would seem an underlying dependency is missing. Becomes a cat-and-mouse game. Consider using a different mail app or the Gmail web interface.
Davey126 said:
Older versions are also available on APKMirror. Not that it matters as it would seem an underlying dependency is missing. Becomes a cat-and-mouse game. Consider using a different mail app or the Gmail web interface.
Click to expand...
Click to collapse
Damn shame no one these days has built in POP options anymore. I'd take a totally manual interface over an app any day.
---------- Post added at 10:45 AM ---------- Previous post was at 10:42 AM ----------
carlscheider said:
OK, after a bit of a search, I found a repository of older versions.
Is this reliable? https://gmail.en.uptodown.com/android/old
I am on 7.7.2 - I see there is even a newer one.
OK, 7.5.21 lasts a little longer - not much.
7.5.7 nope. 7.4.23 , 6.11.27, nope.
I am going to stop for now. I did find that it seems useful to delete the storage BEFORE uninstalling. It's like the next install picks up on the existing memory and just uses it. If you delete that, it starts fresh. Not that it is getting me anywhere. Thanks. Later.
Click to expand...
Click to collapse
Google is good about putting updates across all versions. If that is the case with Gmail, no older ones will work.
Gmail used to work. I did have it on the tablet a while back. Though I never reinstalled it after I did my first reset.
Davey126 said:
Look to another mail client (many fine options in Play Store) or use web interface.
Click to expand...
Click to collapse
You were right, there are other email apps that are fine... Thanks.
Would having root allow one to give the gmail app the proper permissions?