I recently installed an update for my application, and the user reported the accident the next day through the Google Play Reporting Service. The stack dump was for LoadApk (), and the error was loading my application class. Here is the dump:
java.lang.RuntimeException: unable to instantiate application com.goalstate.WordGames.FullBoard.library.FullBoardApplication: java.lang.ClassNotFoundException: could not find class "com.goalstate.WordGames.FullBoard.library.FullBoardApplication" on path: [DexPathList ], nativeLibraryDirectories = [/ vendor / lib, / system / lib]] at android.app.LoadedApk.makeApplication (LoadedApk.javahaps16) 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) on android.os.Handler.dispatchMessage (Handler.java:102) on android.os.Looper .loop (Looper.java:146) at android.app.ActivityThread.main (ActivityThread.java∗602) in java.lang.reflect.Method.invokeNative (native method) in java.lang.reflect.Method.invoke (Method .java: 515) at com.android.internal.os.ZygoteInit $ MethodAndA rgsCaller.run (ZygoteInit.java:1283) at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1099) in dalvik.system.NativeStart.main (native method) Called: java.lang.ClassNotFoundException: not found the class "com.goalstate.WordGames.FullBoard.library.FullBoardApplication" along the path: DexPathList [[], nativeLibraryDirectories = [/ vendor / lib, / system / lib]] in dalvik.system.BaseDexClassLoader.findClass (BaseDexClassLoader.ava: 67) in java.lang.ClassLoader.loadClass (ClassLoader.java:497) in java.lang.ClassLoader.loadClass (ClassLoader.java:457) on android.app.Instrumentation.newApplication (Instrumentation.java:981) at android. app.LoadedApk.makeApplication (LoadedApk.java∗11) ... 11 more
I have a library, and my application class is defined in this library. The phenomenon for my application (which used the library) was referencing a class in that library along its full path. He did not have his own application class.
All my internal tests did not reproduce this problem, and even when I tested (using the Samsung Remote Test Lab) on the same device (actually two different devices, one of which works 4.3 and one works on 4.4.4), how reported an accident (Galaxy Note II, running Android 4.4), there were no problems.
When searching for information about this, I found a mention that different devices may have slightly different approaches to resolving class references, and that is probably why most devices did not have problems with my APK, but this is a specific device (which, unlike my test devices were powered by Sprint's Android app). And in a similar way, it may be why only one percent of your own customers encountered a problem, while most were not.
I decided that the best approach would be to make it as simple as possible, even for an inexperienced device, to find the classes that my manifest files referenced. So, I defined a new application class in the package of the application itself (and not in the library), and I had a class inherited from the application class in my library. Otherwise, the new class would be empty.
Then I replaced the link with the full path to the application class in the library with a relative link to the new class that I created in the application itself. So, instead of:
<application android:name="com.goalstate.WordGames.FullBoard.library.FullBoardApplication"
in my manifest, I had:
<application android:name=".FullBoardWordChumsApplication"
This (in accordance with folklore on this subject) should facilitate the success of the process of less complex resolution.
I also took advantage of the full path that I used in the manifest to name my already local activity class and made it relative (just cutting off everything that was to the endpoint).
Additional folklore found on the Internet indicates that it can help turn off "Build Automatically" for a project in Eclipse, then exit Eclipse, re-enter Eclipse, and then, after rebuilding it, go directly to Android Tools to export signed APKs (without automatic inclusion of the assembly). So, throwing salt over my left shoulder and saying a prayer to the gods of fragmented paranoia, I applied this superstition to preparing my APK for release.
Does this help anyone? Time will tell, but so far my updated release has not caused additional failures.