I've recently added Wear functionality to one of my apps, and I started seeing an obfuscated crash being reported. I've updated the app a few times since then, which included using newer Google Play Service versions. Here's the crash:
java.lang.IllegalStateException
at com.google.android.gms.internal.aa.f()
at com.google.android.gms.internal.r.a()
at com.google.android.gms.common.api.b.bl()
at com.google.android.gms.common.api.b.d()
at com.google.android.gms.common.api.b$2.onConnected()
at com.google.android.gms.internal.r.a()
at com.google.android.gms.internal.r.x()
at com.google.android.gms.internal.q$g.a()
at com.google.android.gms.internal.q$g.d()
at com.google.android.gms.internal.q$b.bQ()
I've looked at any place in my code that uses onConnected, and I can't find anything that would cause an ISE. Anyone see anything like this, or know what it is?
Related
I remember to have seen that Android started to restart apps when these crash for the first time. But I can't find this statement in the documentation or release notes.
Do you know since which OS/SDK version this happen? Maybe I was dreaming?
I've tested with 4 different model devices and the behaviour seems to vary on device rather than android version.
Auto starting after a crash is not a standard behavior of Android. More commonly after an app crash, you are shown a dialog with an option to open the app again if you choose to do so. You can see the dialog in the following document.
Reference: https://developer.android.com/games/optimize/crash
Also, I think auto-restart of an app after a crash is not a good feature. If there is something wrong with the app causing a crash when you launch the app, then there is a good chance it may crash again with the auto relaunch. Why have the user see the crash again unnecessarily.
I'm having a problem where an app I'm developing is working on mobile devices (tested on 4 different devices), but crashing when I try to test it on my tablet. The tablet I'm using is a Tesco Hudl 2, which, although being a good quality low cost device, lacks adb drivers and so you can't debug apps through USB and get the Logcat data. The app was developed using Android Studio.
With other apps I have developed, I have just set up ACRA in the project so I can still get debug information from a crash. This time however, the app is crashing without any information from ACRA and so I'm not quite sure what is going wrong. I'm pretty sure I've set up ACRA correctly given that I've used it in several projects before and see nothing wrong this time. Can it be that whatever is going wrong is happening too early for ACRA to catch?
I have pulled out all the code from the activity so the only thing that happens in code is that ACRA gets initialized in the derived Application class (note that the crash exists without ACRA). The app also uses Google maps and a provider for search suggestions. If there is any code anyone wants to see just ask, but I'm unsure what exactly to post up since everything else was stripped out. So, does anyone have any idea on what I can do to solve this, or what tools I can use to catch whatever sort of errors happen so early in the apps lifecycle?
Thanks
Update with strange behaviour... Downloaded Crashlytics and it also did not catch the crash. I copied the project and removed every .java file except the Application, Activity and provider. The provider functions were empty (save for the return value of 0/false/null/whatever), the application class just initialized Crashlyitcs and the Activity class was empty. This then worked, I was even able to add in a lot of the code and get the google map to load.
Now if I do the same in my main project, except don't delete the .java files, the crash still happens. The classes in these files are not used so I have no idea how they can be causing the crash. Otherwise all the xml, gradle, resources are identical (except the package and app name). Very confusing...
Consider using one of the apps to view logcat on the device:
https://play.google.com/store/apps/details?id=com.nolanlawson.logcat
https://play.google.com/store/apps/details?id=org.jtb.alogcat
Also try using Crashlytics. Maybe it will catch your crash?
But yeah, it's possible to have a crash before any crash reporter (ACRA or Crashlytics) will have a chance to catch it.
And one more note, maybe there is a way to enabled ADB over WiFi.
Normally you would need to enable it via adb but maybe in case of this cheap and strange tablet, there is an option for that enabled in the ROM?
Ok! So it's 1am and I decided to have one final attempt to fix, which I think I did. In my manifest, I had things like
<activity
android:name=".MyActivity"
...
for example, and while this worked fine on the mobiles, for some reason the Hudl required the complete package name, i.e. com.mypackage.MyActivity. Not sure why this is the case but it appears to have fixed the problem.
I use a crash reporting tool that stack traces when an exception is thrown. Now and then I see a java.lang.NoClassDefFoundError and I usually never pay attention to them because it's just 1 crash for every 10.000 sessions or more. The odd thing is:
It's usually with different classes (i.e. NoClassDefFoundError for class MyAwesomeClass and MyOtherAwesomeClass), it rarely happens twice for the same class.
The crash usually happens only once to the same user (i.e. no user has had more than one NoClassDefFoundError for the same class).
I have never been able to reproduce the error.
Now my question is: Could this be a 'device specific issue' i.e. something that Android manufacturer X could have done wrong? Could it be an OS issue?
Has anyone ever had a similar problem? Any theories on why this could happen?
I have also faced NoClassDefFoundError in my projects. This error was thrown when I was running my app on lower version of android like 2.2 and my app uses apis that were not avaiable on lower version of android for example if I am trying to run my code using Fragments on lower version of android or my class declare some Event Listener or code related with NFC etc. that is not available on that android version on which I am running my app.
So to avoid this error may be you can use android version check in your code at places where you are using apis that are not available in lower android version.
I have submitted an app to the Amazon app store. It has been rejected twice now for the same reason, but I can't find the problem. It crashes right at the start, usually 2-3 activity windows in. This error never happens on our test devices, and there hasn't been a single error or crash from the app on the Google market. So thus far I've been completely unable to replicate the error.
On the last rejection we requested a stacktrace, which they sent, but only with errors, not warnings, which from what I gather is what I need to find out exactly what method is causing the Java.Lang.VerifyError from W/dalvikvm. Is it reasonable to assume that when they decompile the app, and inject their amazon drm/tracking/whatever code into the app, and recompile it, it's causing clashing errors with some of my code? or that Amazon are possibly compiling on a different version of Java than we are? (ours is 1.6)
The app has both minSDK and targetSDK set to api8, which is 2.2 minimum, and we compile it against 2.2, Has anyone else had this error with Amazon before and might be able to give me some insight as to how the problem was resolved?
Thanks
Found the problem. In the Manifest there was a .java file that was declared as an activity, which it was originally, but it had been changed to extend Dialog instead.
When Amazon injects code into your app, they look at the manifest to find the Android Activities, and inject code into them such as callbacks and method overrides, some of which are specific to the Activity class. When Amazon looked at my manifest, they thought the class was an Activity, but it was actually now a Dialog, and the app was crashing when trying to override methods that didn't exist.
Once removing the manifest declarations to the classes that weren't actual Activities, the app got approved. Its weird that google and eclipse didn't pick up on the declared activities that weren't activities when the app got compiled.
Hope this can help others who cant seem to find out the reason their apps not getting approved by Amazon.
My app had been chugging along fine on the Android market until last night when it was reported a customer found an error. The customer must have downloaded the latest version of the app because he tried to use it again with the latest version and the error came back.
I looked at the stack trace of the error and found it was caused by a NullPointerException when passing information between two activities, namely with the onActivityResult() method.
I checked the code and can't find what could have caused the error. I tried to figure out what steps the user took to get the error, but found nothing wrong, on the emulator Android 1.6 /Android 2.2 and my own phone (Android 2.2). I couldn't find any problems no matte rhow much I tried to crash the system.
Another thing that is strange is that the particular onActivityResult method is called a lot in my app. So it is odd that only one user has reported problems.
Also, it says the user's platform is "OTHER". I don't know what device that could be.
So my questions are:
1) Could this problem be an issue with the user's device and not my application?
2)What to do when you cannot find the cause of a crash?
1) Yes, they may have a custom ROM; they're known for doing things like this.
2) Unless you can reproduce it, you [probably] can't fix it.
Can you contact this customer? If not, there may be nothing you can do.