Develop Reference

ClassNotFoundException not reported in crashlytics

I noticed a huge difference in the number of crashes reported by Crashlytics (Fabric) and Google Play Developer Console. Also we are using Firebase, it also shows a number similar to Crashlytics. However, there is a huge difference in developer console.
This led me to investigate all the crash report details one by one. Then I found a specific crash which happened many many times. This crash is reported only in developer console. However, it does not exist in Crashlytics and Firebase. Developer console provides a short stacktrace of the exception. Here it is.
java.lang.RuntimeException:
at android.app.ActivityThread.installProvider(ActivityThread.java:5196)
at android.app.ActivityThread.installContentProviders(ActivityThread.java:4799)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4683)
at android.app.ActivityThread.access$1400(ActivityThread.java:168)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1389)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:5493)
at java.lang.reflect.Method.invokeNative(Native Method:0)
at java.lang.reflect.Method.invoke(Method.java:525)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1209)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1025)
at dalvik.system.NativeStart.main(Native Method:0)
Caused by: java.lang.ClassNotFoundException:
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:64)
at java.lang.ClassLoader.loadClass(ClassLoader.java:501)
at java.lang.ClassLoader.loadClass(ClassLoader.java:461)
at android.app.ActivityThread.installProvider(ActivityThread.java:5181)
As you can see, it doesn't tell me which class is not found in the stacktrace. So my hands are tied a little bit here.
Might this crash be happening before the singleton application class is instantiated? Might be happening before Crashlytics and Firebase instances are created?
By the way, this exception is happening only in Android 4.2, 4.3 and 4.4 according to the developer console reports.
Anybody ever experienced this issue, or any ideas? Thanks in advance.

getting a NoClassDefFoundError on "PlusImageView"

Background
My app has a small PlusOne button in it (using Google-Play-Services rev. 21.0.2) , and recently I got the next crash report from one of the users
java.lang.NoClassDefFoundError: android.os.AsyncTask
at com.google.android.gms.plus.data.internal.PlusImageView.a(SourceFile:60)
at com.google.android.gms.plus.internal.bw.a(SourceFile:917)
at com.google.android.gms.common.internal.v.d(SourceFile:200)
at com.google.android.gms.common.internal.u.handleMessage(SourceFile:136)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:130)
at android.app.ActivityThread.main(ActivityThread.java:3770)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:507)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:912)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:670)
at dalvik.system.NativeStart.main(Native Method)
The problem
I've followed all of the instructions of the Play Services for a very long time (including the Proguard part), and never had this issue before.
The weird thing is that I've succeeded running the app on multiple devices without any issue, and there are quite a lot of users out there that use my app . Many also uninstall, but this is the first time I get this crash.
The question
I'm not a Proguard expert, but is it maybe possible that this is the reason for it?
What could be the reason for this issue?
How can I fix this issue?
I've tried to search for this problem and there isn't even a single website that I've found regarding it.

Serious issues with Proguard - NoClassDefFoundError

Background
Recently I've updated my app, and for some reason Proguard seem to ruin the code I've made, causing crashes on a very specific case, even though I didn't add any additional libraries.
The reason I'm so sure it's Proguard's fault is that when I tested it without exporting it, it ran fine.
The problem
After seeing the crash reports' stack traces (and seeing that it does occur, by myself), I've ran the "proguardgui" tool and chose to retrace using the mapping file.
Sadly, instead of showing the real places that the code failed, it showed the exact same stack. I've tried to export the project again and use a new mapping file that was created by it, but I still get the same obfuscated stack trace.
Not only that, but the exception itself is very problematic: java.lang.NoClassDefFoundError .
Here's the stack trace, though I don't think it's readable:
java.lang.NoClassDefFoundError: com.lb.app_manager.utils.r
at com.lb.app_manager.utils.e.c(Unknown Source)
at com.lb.app_manager.activities.app_list_activity.AppListActivity.onContextItemSelected(Unknown Source)
at android.app.Activity.onMenuItemSelected(Activity.java:2620)
at android.support.v4.app.FragmentActivity.onMenuItemSelected(Unknown Source)
at com.actionbarsherlock.app.SherlockFragmentActivity.onMenuItemSelected(Unknown Source)
at com.android.internal.policy.impl.PhoneWindow$DialogMenuCallback.onMenuItemSelected(PhoneWindow.java:3864)
at com.android.internal.view.menu.MenuBuilder.dispatchMenuItemSelected(MenuBuilder.java:735)
at com.android.internal.view.menu.MenuItemImpl.invoke(MenuItemImpl.java:152)
at com.android.internal.view.menu.MenuBuilder.performItemAction(MenuBuilder.java:874)
at com.android.internal.view.menu.MenuDialogHelper.onClick(MenuDialogHelper.java:167)
at com.android.internal.app.AlertController$AlertParams$3.onItemClick(AlertController.java:941)
at android.widget.AdapterView.performItemClick(AdapterView.java:299)
at android.widget.AbsListView.performItemClick(AbsListView.java:1113)
at android.widget.AbsListView$PerformClick.run(AbsListView.java:2904)
at android.widget.AbsListView$3.run(AbsListView.java:3638)
at android.os.Handler.handleCallback(Handler.java:733)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5017)
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:779)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:595)
at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:133)
at dalvik.system.NativeStart.main(Native Method)
This occurs when I choose to share an app, which, for a very short time should show a progress dialog while running an AsyncTask, and then show a dialog of how you wish to share (just like on the screenshot of the play store link, available here in case you can't see it ).
What I've tried
I've tried to add logs in multiple places, and found out that the AsyncTask runs fine, but it doesn't reach "onPostExecute". I know this since I've put log at the end of "doInBackground" and at the beginning of "onPostExecute" .
This got even weirder, when I removed most of the code of "onPostExecute" and now I have only this:
protected void onPostExecute(final Void result)
{
Log.d("Applog","onPostExecute 0");
super.onPostExecute(result);
Log.d("Applog","onPostExecute 1");
progressDialog.dismiss();
}
It doesn't even reach the first line this way.
In the end, I've decided to merge 2 projects (that I made several versions ago), so that there won't be any Android library project that I made. Only a single one.
I've also removed a library that appears not being used (of Apache commons), but I can't believe this is the cause to the problem (because I didn't use it).
The question
Why do such problems occur?
How can I avoid such a problem in the future?

A NoClassDefFoundError generally points to a problem in the build process: some class that is required doesn't end up in your application.
ProGuard prints out information in the build log about the input jars that it reads and the output jars that it writes. You can also specify
-printconfiguration configuration.txt
to get the complete configuration that ProGuard uses, including input and output. This should help you to find out if all expected input jars are present.
If you are using Eclipse to build your application, you may have run into a synchronization problem that seems to run ProGuard when not all compiled files have been written to disk yet. This mysterious problem has been reported a few times, but it is still unsolved. You should then try Ant or Gradle instead.

java.lang.ClassNotFoundException on startup

We have very weird java.lang.ClassNotFoundException on app startup that happens to very small amount of customers (< 1%). We never saw it in dev env and we cannot understand the source of this issue. Here is the stack trace from Google play crash reports.
java.lang.RuntimeException: Unable to instantiate application com.mycompany.myapplication.MyApplication: java.lang.ClassNotFoundException: com.mycompany.myapplication.MyApplication in loader dalvik.system.PathClassLoader[/mnt/asec/com.mycompany.myapplication-1/pkg.apk]
at android.app.LoadedApk.makeApplication(LoadedApk.java:490)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:3784)
at android.app.ActivityThread.access$2200(ActivityThread.java:132)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1082)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:143)
at android.app.ActivityThread.main(ActivityThread.java:4268)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:507)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ClassNotFoundException: com.mycompany.myapplication.MyApplication in loader dalvik.system.PathClassLoader[/mnt/asec/com.mycompany.myapplication-1/pkg.apk]
at dalvik.system.PathClassLoader.findClass(PathClassLoader.java:240)
at java.lang.ClassLoader.loadClass(ClassLoader.java:551)
at java.lang.ClassLoader.loadClass(ClassLoader.java:511)
at android.app.Instrumentation.newApplication(Instrumentation.java:972)
at android.app.LoadedApk.makeApplication(LoadedApk.java:481)
... 11 more

If the issue only occurs on with signed APKs and you are using Eclipse to Export the Signed APK ...
Before you 'Export and sign an APK' in Eclipse turn off the following setting in the menu [Project > Build Automatically] (then can switch it back on later when you continue developing).

I recently deployed an update to my app, and a user reported a crash the very next day via the Google Play reporting facility. The stack dump was for LoadApk() and the error was in the loading of my Application class. Here is that dump:
java.lang.RuntimeException: Unable to instantiate application com.goalstate.WordGames.FullBoard.library.FullBoardApplication: java.lang.ClassNotFoundException: Didn't find class "com.goalstate.WordGames.FullBoard.library.FullBoardApplication" on path: DexPathList[[],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
at android.app.LoadedApk.makeApplication(LoadedApk.java:516)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4703)
at android.app.ActivityThread.access$1600(ActivityThread.java:175)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1368)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:146)
at android.app.ActivityThread.main(ActivityThread.java:5602)
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:1283)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1099)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ClassNotFoundException: Didn't find class "com.goalstate.WordGames.FullBoard.library.FullBoardApplication" on path: DexPathList[[],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:67)
at java.lang.ClassLoader.loadClass(ClassLoader.java:497)
at java.lang.ClassLoader.loadClass(ClassLoader.java:457)
at android.app.Instrumentation.newApplication(Instrumentation.java:981)
at android.app.LoadedApk.makeApplication(LoadedApk.java:511)
... 11 more
I have a library and my Application class was defined in that library. The manifest for my app (which used the library) referred to the class in that library by its full path. It did not have an application class of its own.
All of my in-house testing had not reproduced this problem, and even when I tested (using the Samsung Remote Test Lab) on the same device (actually two different devices, one running 4.3 and one running 4.4.4) as reported the crash (a Galaxy Note II, running Android 4.4), there was no problem.
In searching for information on this I found mention of the fact that different devices may have slightly different approaches to resolving class references, and that is probably why most devices had no problem with my APK, but this particular device (which, unlike my test devices, was provided with its Android flavor by Sprint) did. And similarly, it may be why just one percent of your own customers had the problem, while most did not.
I decided that the best approach would be to make it as easy as possible for even an unsophisticated device to find the classes that were referenced from my manifest file. So, I defined a new application class within the package of the app itself (rather than the library) and I had that class inherit from the application class in my library. The new class was otherwise empty.
I then replaced the full path reference to the application class in the library with a relative reference to the new class I had created in the app itself. So, instead of having:
<application android:name="com.goalstate.WordGames.FullBoard.library.FullBoardApplication"
in my manifest, I had:
<application android:name=".FullBoardWordChumsApplication"
That (according to folklore on this topic) should make it easier for a less sophisticated resolution process to succeed.
I also took the full path that I had been using in the manifest to name my already-local activity class and made it relative (by simply lopping off everything preceding the final dot).
Additional folklore found online indicates that it may help to turn off "Build Automatically" for the project in Eclipse, then exit Eclipse, re-enter Eclipse, and then, after it rebuilds, go directly to Android Tools to export the signed APK (without ever turning on Build Automatically). So, throwing salt over my left shoulder, and saying a prayer to the gods of fragmentation paranoia, I accommodated this superstition in preparing my APK for release.
Does any of this really help? Time will tell, but so far my updated release has not generated any additional crashes.

This Error occurs when in your manifest file in application tag whatever class name you put it is not match with your coding java file .So make a current both in way.

Android FileNotFoundException res/drawable-hdpi/scrollbar_handle_vertical.9.png

The most significant user-reported crash for my app right now is below. It seems like the system cannot find the file res/drawable-hdpi/scrollbar_handle_vertical.9.png
The below example indicates the problem happens when drawing a webview, but it also happens for other activities in my app, all of which work fine most of the time.
I would think this is an android resource that I wouldn't need to worry about. But, just to test, I took the file from the sdk and placed it into my project drawable-hdpi folder for the latest release of my app. However, I still observer the crash reports in google play.
Any thoughts as to what could be happening?
I'm also not using progaurd right now, so no way that is stripping out files it shouldn't.
android.view.InflateException: Binary XML file line #26: Error inflating class com.android.internal.app.AlertController$RecycleListView
at android.view.LayoutInflater.createView(LayoutInflater.java:513)
at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:565)
at android.view.LayoutInflater.inflate(LayoutInflater.java:385)
at android.view.LayoutInflater.inflate(LayoutInflater.java:320)
at android.view.LayoutInflater.inflate(LayoutInflater.java:276)
at android.webkit.WebView$InvokeListBox.run(WebView.java:8308)
at android.os.Handler.handleCallback(Handler.java:587)
at android.os.Handler.dispatchMessage(Handler.java:92)
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:858)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.reflect.InvocationTargetException
at com.android.internal.app.AlertController$RecycleListView.<init>(AlertController.java:703)
at java.lang.reflect.Constructor.constructNative(Native Method)
at java.lang.reflect.Constructor.newInstance(Constructor.java:446)
at android.view.LayoutInflater.createView(LayoutInflater.java:500)
... 14 more
Caused by: android.content.res.Resources$NotFoundException: File res/drawable-hdpi/scrollbar_handle_vertical.9.png from drawable resource ID #0x0
at android.content.res.Resources.loadDrawable(Resources.java:1714)
at android.content.res.TypedArray.getDrawable(TypedArray.java:601)
at android.widget.AbsListView.<init>(AbsListView.java:630)
at android.widget.ListView.<init>(ListView.java:230)
at android.widget.ListView.<init>(ListView.java:226)
... 18 more
Caused by: java.io.FileNotFoundException: res/drawable-hdpi/scrollbar_handle_vertical.9.png
at android.content.res.AssetManager.openNonAssetNative(Native Method)
at android.content.res.AssetManager.openNonAsset(AssetManager.java:405)
at android.content.res.Resources.loadDrawable(Resources.java:1706)
... 22 more

It seems likely that this resource is missing on one (or more devices). i.e. the build of Android on that device is missing this file. It would be interesting to see whether the issue is affecting very specific devices.
I expect the solution will be to use a drawable in your app itself (rather than rely on one in android) and make sure your one is referenced, not the one that is missing on certain devices.
You can use tools like BugSense to track issues like this to collect data on affected devices & platform versions. This is useful if you're unable to get this information from the Google Play Store reporting.

One more case when this happens - when you use attribute/resource introduced in later android versions. There are some complex mappings attributes to indexes and when appt generates R.java it possibly can overlap some old ids and this very weird error occurs.
For me, the same error appeared when in view was set
android:foreground="?android:attr/selectableItemBackground"
selectableItemBackground was introduced in api 11, but was launched at emulator with api 7.
So check your layouts for using some resources introduced later than your minSdkVersion. It can be checked at R.java reference