I have an app that I have recently submitted to the play store. I had tested the .apk file and everything was working fine. On the first install (from the store) - you can login but then it crashes. Here is the stack trace I am getting from the report:
java.lang.NullPointerException
at com.latlon.InitialSearchActivity.e(Unknown Source)
at com.latlon.InitialSearchActivity.a(Unknown Source)
at com.latlon.InitialSearchActivity.g(Unknown Source)
at com.latlon.InitialSearchActivity.a(Unknown Source)
at com.latlon.MyResultReceiver.onReceiveResult(Unknown Source)
at android.os.ResultReceiver$MyRunnable.run(ResultReceiver.java:43)
at android.os.Handler.handleCallback(Handler.java:587)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:150)
at android.app.ActivityThread.main(ActivityThread.java:4385)
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:849)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:607)
at dalvik.system.NativeStart.main(Native Method)
I am just not real sure where to start looking. Any ideas?
Well, this part of the stack trace is your code:
java.lang.NullPointerException
at com.latlon.InitialSearchActivity.e(Unknown Source)
at com.latlon.InitialSearchActivity.a(Unknown Source)
at com.latlon.InitialSearchActivity.g(Unknown Source)
at com.latlon.InitialSearchActivity.a(Unknown Source)
at com.latlon.MyResultReceiver.onReceiveResult(Unknown Source)
Your onReceiveResult() method in class MyResultReceiver was called. That method called a method a in the InitialSearchActivity class, which called a method g in that class which called a method a in that class which called a method e in that class. In method e there was a NullPointerException (ie: in that method you tried to use a variable that you thought contained an object reference, but instead that variable contained null.
It looks like the method names have been obfuscated, so you may have to look at the code to figure out what the real method names are.
Looks like you used some toole (like Proguard) to obfuscate your code.
Did you test your APK after obfuscation?
From the logs above a NullPointerException has occured in your code, you'd need to de-obfuscate your code using the key files generated by the obfuscating tool in order to find out the real place (line of code) where null pointer has been accessed.
Please Note,
In the process of obfuscation, sometimes (human error) can cause some of the required methods to be obfuscated. Which in turn causes those methods not to be found, hence an exception (NoSuchMethod) might be raised.
Check the documentation on Proguard (which is the tool that does the code obfusciation).
It is very likely that you "over-obfusciated", which can cause issues with the deployed code. Just like you are seeing.
You can turn off Proguard functionality by editing the "proguard-project.txt" file. To ensure no obfusciation occurs, make sure every line in this file is commented out (by placing a hash - or # mark at the start of each line).
There is a command called retrace that allows you to provide unmap your obfusciation. You will need to provide some files created by proguard to get this working.
Check the docs for full explanation: http://developer.android.com/tools/help/proguard.html
Quick fix (to eliminate Proguard) is to comment the file, so it doesn't run in the first place.
Related
I'm new on react, and i tried to run my app but i got this following error
E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.bits.bee.bwc, PID: 12601
java.lang.AssertionError: APK bundle must contain the expected embedded asset asset_c2f3d742a18a28238b7cd34a5d4b7316.png
at expo.modules.updates.loader.EmbeddedLoader.copyAllAssets(EmbeddedLoader.java:174)
at expo.modules.updates.loader.EmbeddedLoader.processManifest(EmbeddedLoader.java:137)
at expo.modules.updates.loader.EmbeddedLoader.loadEmbeddedUpdate(EmbeddedLoader.java:57)
at expo.modules.updates.UpdatesController.start(UpdatesController.java:286)
at expo.modules.updates.UpdatesController.initialize(UpdatesController.java:96)
at com.bits.bee.bwc.MainApplication.onCreate(MainApplication.java:98)
at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1011)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4552)
at android.app.ActivityThread.access$1500(ActivityThread.java:147)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1342)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5255)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:652)
Can someone explain to me how it's work because i looked it up in my asset folder there's nothing named like that. And how do i fix this? Thanks
Info
This exception only happened to me when running a debug build with react-native run-android and the exception did not appear when running a release build with react-native run-android --variant=release.
Solution
Check whether you have the following line in MainApplication.java and if it's there then remove that line:
import com.facebook.react.BuildConfig;
Explanation
The line import com.facebook.react.BuildConfig; causes UpdatesController.initialize(this); to be called in Debug mode which shouldn't happen.
More detail:
When you look at your Stacktrace you posted the line
at com.bits.bee.bwc.MainApplication.onCreate(MainApplication.java:98)
points to UpdatesController.initialize(this);. Including the line above and below that's how it looks like:
if (!BuildConfig.DEBUG) {
UpdatesController.initialize(this);
}
This BuildConfig here points to the BuildConfig class of your package (com.bits.bee.bwc in your case) which is created during the build. If you import com.facebook.react.BuildConfig it will point to another BuildConfig class which does not contain the correct DEBUG value you want.
Since BuildConfig.DEBUG will then be undefined or false, UpdatesController.initialize(this); is called although it shouldn't during a debug build. Hence, because assets will be not embedded for debug builds, the copyAllAssets function which is eventually called will not find any assets and we get the above error.
Some Context of why I ended up importing com.facebook.react.BuildConfig;
I was facing the issue of java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so in my release build and followed the advice to add that line as stated here https://stackoverflow.com/questions/57036317/react-native-java-lang-unsatisfiedlinkerror-couldnt-find-dso-to-load-libherm/63048532#answer-62119615. It didn't make a change for the release build and I forgot about it. Only later when I attempted to make a debug build I got this error.. took me quite a while to realize that this added line is the cause of the issue!
What I learned from debugging this issue:
Don't just add things because you think it won't hurt. If it doesn't fulfill a certain purpose or has no effect, remove the change immediately. It can otherwise cause strange side effects later.
If you have build issues with Android, debug with Android Studio instead of Flipper. Flipper doesn't display you the entire Stacktrace and in Android Studio you can easily browse through all the Java files which eventually helped me to understand this Exception.
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.
I'm developing for 2.2 (minSdkVersion=8) and suddenly I'm getting this error:
arbitrarily rejecting large method (regs=75 count=28584)
rejected Lcom/Demo/Loyalty/SelectType;.onClick (Landroid/view/View;)V
Verifier rejected class Lcom/Demo/Loyalty/SelectType;
Class init failed in newInstance call (Lcom/Demo/Loyalty/SelectType;)
java.lang.VerifyError: com.Demo.Loyalty.SelectType
at java.lang.Class.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1429)
at android.app.Instrumentation.newActivity(Instrumentation.java:1022)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2577)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2679)
at android.app.ActivityThread.access$2300(ActivityThread.java:125)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2033)
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:858)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
at dalvik.system.NativeStart.main(Native Method)
It was working fine until now.
Note : SelectType class has around 16000 lines of code but that is not that large I guess.
I search a lot on net and from answers, I did following:
Clean the project
Reset the ADB
Restart emulator/device/eclipse
Checked that third party library field is checked in build path
But I'm still getting that error.
Any help appreciated.
The steps you've described probably won't help.
The thing is, it's not a Dalvik issue. Similar verifier is employed in the Oracle Java VM for example. Simple answer: your method is too complex. The error you see is mainly caused by too many:
parameters
local variables
exception handlers
code instructions
More precisely, the issue has been described in this thread: https://groups.google.com/forum/?fromgroups=#!topic/android-developers/4qNoIdBHYFc
To quote:
The value of (number of registers * number of instruction words) is
larger than 2^21. (...)
it's intended to
prevent the verifier from bloating up an app's native heap.
You can also see similar report here: http://www.mentby.com/Group/android-developers/verifyerror-arbitrarily-rejecting-large-method.html with pointers on how to resolve the issue:
Yep, the Dalvik compiler attempts to assign a "register" to every
local variable in the method. It should be able to handle that many,
but apparently can't. By making them instance variables you remove
the compiler's need/desire to "manage" them (and also make the method
a fair amount smaller).
So to solve it, you should generally break the large method (probably onClick()?) into smaller pieces. Also, converting local variables to class fields seemed to help some people with the same issue.
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.
I have a ContentProvider class and is declared in AndroidMenifest.xml like this:
<provider android:name=".MediaSearchProvider"
android:authorities="org.iii.romulus.meridian.mediasearch">
<path-permission android:path="/search_suggest_query"
android:readPermission="android.permission.GLOBAL_SEARCH" />
</provider>
It works well on most devices, but the Market tells me some users are suffering error with it. The stack trace is:
java.lang.RuntimeException: Unable to get provider org.iii.romulus.meridian.MediaSearchProvider: java.lang.ClassNotFoundException: org.iii.romulus.meridian.MediaSearchProvider in loader dalvik.system.PathClassLoader[/mnt/asec/org.iii.romulus.meridian-1/pkg.apk]
at android.app.ActivityThread.installProvider(ActivityThread.java:4509)
at android.app.ActivityThread.installContentProviders(ActivityThread.java:4281)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4237)
at android.app.ActivityThread.access$3000(ActivityThread.java:125)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2071)
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:878)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:636)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ClassNotFoundException: org.iii.romulus.meridian.MediaSearchProvider in loader dalvik.system.PathClassLoader[/mnt/asec/org.iii.romulus.meridian-1/pkg.apk]
at dalvik.system.PathClassLoader.findClass(PathClassLoader.java:243)
at java.lang.ClassLoader.loadClass(ClassLoader.java:573)
at java.lang.ClassLoader.loadClass(ClassLoader.java:532)
at android.app.ActivityThread.installProvider(ActivityThread.java:4494)
... 12 more
I have totally no idea about what's up and I can't reproduce it on any of my phones. I also tried clean and build, but the report still comes up.
Anyone can help? Thanks!
The answers regarding proguard are incorrect. This would cause an easily reproducible error on every phone, every time, because the ContentProvider class would be completely missing. The developer clearly states that they cannot reproduce the error, meaning that the ContentProvider class is present but for some reason is not being found on one of their user's phones.
I have the same crash reported in the market for my app. The stack traces look identical, and the error is occurring at installProvider. I have about 15 test phones in my office and none of them can reproduce this problem. Any other ideas would be appreciated.
Fully qualified names in the manifest are only necessary if your java package names are not the same as your android package name. If a fully qualified name is not specified, the OS will automatically prepend the android package name to the class name specified in the manifest.
Ensure twice that you have correct qualified class name specified in AndroidManifest.xml, it must read something like this:
<provider
android:authorities="org.iii.romulus.meridian.mediasearch"
android:name="org.iii.romulus.meridian.MediaSearchProvider">
</provider>
Notice that #name is fully qualified.
This sounds similar to an issue I had that was caused by an issue with the ClassLoader, see here: Bizarre behaviour when using Apache Commons lib in Android
This bug discusses an error relating to the class loader failing sometimes. The fix for me was to add this line:
Thread.currentThread().setContextClassLoader(this.getClassLoader());
in the constructor of the class that was calling the code that was failing.
Proguard excludes all inherited content providers by default with this line (make sure it's in your cfg):
-keep public class * extends android.content.ContentProvider
If you have any additional inheritance you should exclude it as well or exclude your specific Content Provider class, for example:
-keep public class org.iii.romulus.meridian.MediaSearchProvider
This is an old thread, and the OP didn't have the same ContentProvider declaration as me, but I had the same exact error, so I want to share my findings, in case it helps anyone.
For me, what caused the problem was that the ContentProvider declaration in the AndroidManifest.xml had an exported attribute set to true:
android:exported="true"
Removing it fixed the problem for me. (I didn't really need it)
If your app has grown large enough to require Multidexing and your app is not set up correctly as a Multidex app you will get this error. To set up your app as a multidex app, follow these directions:
Setup multidex app