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.
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.
Guys I am getting the below error in RunTime, what is the root cause of this error?
java.lang.VerifyError: appPackageName at java.lang.Class.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1130)
at android.app.ActivityThread.handleCreateService(ActivityThread.java:2698)
at android.app.ActivityThread.access$1900(ActivityThread.java:148)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1413)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:5457)
at java.lang.reflect.Method.invokeNative(Native Method)
You are probably using or accessing something which is simply supported in higher android SDK, as the error shows here java.lang.Class.newInstanceImpl(Native Method).
I happened to have the same kind of VerifyError while I was using String.isEmplty();. It seems you have same kind of problem as the message showing error in java.lang.Class
Thrown when the "verifier" detects that a class file, though well formed, contains some sort of internal inconsistency or security problem.
Here is official docs
Possible causes:
You might have imported something which is using different support v4/v7 library version.
You are targeting something from a higher SDK version. In that case, update your support repository and SDK build version.
Thanks everyone for your support and answers, may be your answers are right but in my case I used extra variables in one method while I was testing, so this exception appeared. Now I get rid of redundant things in my code and it start working. It may help others.
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.
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.
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.