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.
Related
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?
Background
I wanted to simplify the usage of DB in an Android app.
For this, I've compared some third party libraries that create a DAO layer.
I've come up with a nice library called "GreenDao" (presentation about it here) . The website shows that it's faster than other competitors (like ORMLite) and is optimized for Android.
The problem
For some reason, on some device (usually old devices, with GB) , I get the next console error when trying to install the app:
Installation error: INSTALL_FAILED_DEXOPT
Please check logcat output for more details.
Launch canceled!
I've searched for the reason of this error, but couldn't find out how to solve it. Many complain about this error, but I can't find out why it occurs, and what can be done.
The error is quite common and known, but it's never mentioned as the result of using this library, yet when I remove the usage of this library, everything works fine...
Also note that on newer devices (like nexus 4) it installs and works just fine, and that the sample itself also works fine no matter which device I test it on.
The question
Why does it occur?
Is it possible that the structure of the classes is just too much for old devices to load, since we use other libraries ?
Could it be that I've reached the limit of code that is supported by android apps?
The jar file itself takes just 87KB ...
How can I solve this?
Ok, I've found the problem and the solution:
It has nothing to do with GreenDao.
It's because the app uses too many jars, so maybe Android has a limitation of code.
The solution is to either delete un-needed jar files or delete a lot of code.
Obviously with code, errors can occur anywhere. So without having try/catch blocks all over the place (which as I understand it is major overhead) how do I allow errors to bubble up to the application level and then handle them there? Or at the very least, record the error somehow for troubleshooting? I found information on an product called ACRA, but the setup instructions are geared for Eclipse projects. I am using Mono for Android in Visual Studio 2010.
That's a bit of an "It depends" question.
The appropriate handling of an errors is going to depend on what the recovery strategy needs to be, how much information you want the user to see etc.
I wouldn't worry how many Try/Catch blocks you use - just use them wherever you need to handle an error that gets thrown - if they're everywhere, your strategy is probably wrong.
It terms of logging and later interrogation, you can log caught errors using the Android.Util.Log class.
These can be interrogated (provided you're debugging on your own device) using Logcat.
There's some more info on logging and Logcat here.
Found this project that writes crash info to google docs. Android Crasher
What are the list of bugs you got, when you were developing an Android Application?
There are some known bugs and some unknown(they not described in documentation).
For example
Known Bug :
Several devices by several manufacturers are affected by the ANDROID_ID bug in 2.2.
As far as I've been able to determine, all affected devices have the same ANDROID_ID, which is9774d56d682e549c. Which is also the same device id reported by the emulator.
Unknown Bug :
telephonyManager.getLine1Number() : Used to read phone number, but some devices(not any specific) returns null, even though they having Phone application.
So I think there should be a list of bugs, where at the time of development, we can keep those in mind.
There could be some API wise bugs. Can you list them please?
A known bug, but will show at compile time with error
R cannot be resolved
when we use android SDK with eclipse..Eclipse sometimes erronously add
import android.R
which will break the make process during compilation..google documented against this bug in this page.
Note: Eclipse sometimes likes to add an import android.R statement at
the top of your files that use resources, especially when you ask
eclipse to sort or otherwise manage imports. This will cause your make
to break. Look out for these erroneous import statements and delete
them.
Strange thing i could remember at the moment is if You use a RelativeLayout inside tabs for Android 2.1 it will give some decoreView error , while works fine with otherLayouts . so test your app on 2.1 if have TabWidget
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.