I have an app with Proguard enabled (minifyenabled true) and recently got a crash report in the Google Play Dev Console. When I looked at it, I saw
the following:
I was surprised to see the full class and method names in line 1, as Proguard is enabled. I've always previously seen things like this:
at com.myname.myapp.c.f (Unknown Source)
I'm also curious how the line number is appearing as I'm not preserving line numbers in my Proguard config file (hence, why I usually see 'Unknown Source' in my stacktraces).
I decompiled my .apk, peeked at the classes.dex file and it all looked OK. I located the class referenced in line 1 of the stacktrace and the class name was indeed obfuscated, as was the method name.
Now, 'MyActivity' (line 2 of the stacktrace) is the launch Activity of my app, and as such is declared in the Manifest, so I understand why it's name is not obfuscated, and the 'onConnected' method is not a method of mine (it comes from Google Play Games Services), so, again, this is OK.
'MyMethodName' is called from within onConnected like so:
#Override
public void onConnected(Bundle arg0) {
myClassObject.myMethodName(); //Where myClassObject is an instance of MyClassName
}
Debug is set to disabled in my build.gradle file.
I don't upload mapping.txt files to the Play Console, I run retrace manually to see my de-obfuscated stacktraces.
I'd appreciate if someone could help me understand why I'm seeing my full class and method name here? What can/should I do to prevent this?
After weeks of agonising over this, I finally discovered the cause...
Suffice is to say, my released app is completely obfuscated - these de-obfuscated stack traces are coming from my own test device!!
Yes, my own test device running the app directly via Android Studio and unsigned. (And for obvious reason, I don't enable ProGuard on my debug builds).
The device I used for testing this app isn't a 'mainstream' device and the 'name' that appears in the Dev Consol bears no resemblance to the actual name of the device so I didn't notice straight away.
I'm fairly sure this never happened in the past (I've certainly not see it until now) - quite why anyone would want crash reports from their debug builds to appear in the Dev Console along with production build crashes, I don't know.
So, if someone is seeing this problem, check it's not your own debug builds causing the influx of stack traces before anything else!
I don't upload mapping.txt files to the Play Console, I run retrace
manually to see my de-obfuscated stacktraces.
Then you may want to add the mapping.txt to google play which will ensure that your packages and classes names are obfuscated.
Related
In play market console I see just statistic how many times my app was crashed. How I can see stack for this crashes?
Should I do some additional steps in adding my app to play market. I just added APK.
what I see on playmarket
In the GooglePlay Console, on the left menu in Quality (Качество) section, select Android Vitals -> Crashes and ANRs (Сбои и ошибки ANR in Russian)
It will give you detailed information about crashes.
But to see the full stack trace first you need to upload ReTrace mapping file (Файл сопоставления ReTrace) - you can find this option in "App Bundle Explorer" when selecting your APK version.
Otherwise you'll see an obfuscated stack trace.
Probably you already have this file (mapping.txt) among the generated files of the project. If not, read here how to generate this file: https://support.google.com/googleplay/android-developer/answer/9848633
I've just built and deployed an app to Google Play. It worked well when I was running it through Android Studio but now it crashes when I download it from Google Play. Because this is my first time, I don't even know how to view the crash report/stacktrace of the app that was downloaded from Google Play. I appreciate any and all help.
UPDATE
So I got the stacktrace for the APK. It tells me that my TopImageFragment.java class cannot create my MemeViewModel.java class. I have no clue why its giving this error. Everything works fine as it is. It seems that proguard is indeed phasing out an important class:
2019-04-18 00:46:32.062 8099-8099/? E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.ozbek.onur.memegenerator, PID: 8099
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.ozbek.onur.memegenerator/com.ozbek.onur.memegenerator.MainActivity}: java.lang.RuntimeException: Cannot create an instance of class com.ozbek.onur.memegenerator.MemeViewModel
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2853)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2928)
at android.app.ActivityThread.-wrap11(Unknown Source:0)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1609)
at android.os.Handler.dispatchMessage(Handler.java:105)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6703)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:769)
Caused by: java.lang.RuntimeException: Cannot create an instance of class com.ozbek.onur.memegenerator.MemeViewModel
at android.arch.lifecycle.ViewModelProvider$NewInstanceFactory.create(ViewModelProvider.java:155)
at android.arch.lifecycle.ViewModelProvider$AndroidViewModelFactory.create(ViewModelProvider.java:210)
at android.arch.lifecycle.ViewModelProvider.get(ViewModelProvider.java:134)
at android.arch.lifecycle.ViewModelProvider.get(ViewModelProvider.java:102)
at com.ozbek.onur.memegenerator.TopImageFragment.onActivityCreated(TopImageFragment.java:89)
This kind of problem usually happens because your app deployed to Google Play was a release build and proguard minified your app and removed a class it shouldn't have. When you build in Android Studio it is a debug build that does not get minified. That's why you see the crash only from Google Play.
Before uploading to Google Play, test out your release APK file on a device and watch logcat for the error. That should tell you what class got removed by mistake and you can correct that by specifying custom proguard rules and trying again until the app stops crashing. Then when you upload to Google Play, you should be good.
You can also enable proguard in a debug build as well by changing your build.gradle file. Then when you run through Android Studio, you should see the same error as you see through Google Play.
One other alternative, you can disable proguard/minification in your release build. However this is not recommended because your app will be larger than it needs to be.
Check if you have any java files that don't have an access modifier. In my experience, just declaring a class without a public or private modifier, causes this problem.
My app suffered the same problem and it was a ProGuard kill.
Because ProGuard renames all classes unless otherwise instructed.
So, in your case, you have to add
#Keep
annotation before your class name MemeViewModel.
example,
#Keep
class MemeViewModel{
//
//
}
In my suggestion, keep your phone connected to your your PC/Laptop while you download and attempt to open it. Use Logcat on android studio, it mostly has all answers or at least errors that lead to the answers. try putting error logs here so we can have a proper look at it.
1) Try the same version of your application that you deployed on Google play store by pushing it through the android studio and see if the problem continues!
2) If same thing happens then put breakpoint on the entry point (onCreate method in most cases in MainActivity class) of your application and Go to Run->Debug "YourProject" option and do step by step debug for each command being executed and see which one is causing problem.
I want to upload errors to the user in the app to the database server, but in the Release version, because it's used with Proguard, it does not correctly represent the classes that have encountered the error, as in the example Has been laid.
Sample error message
Attempt to write to field 'java.lang.String com.employe.school.Application.Message.c.c' on
a null object reference
Instead of "c.c", your actual class name will be displayed.
In general, I want to handle the App errors myself and do not use Firebase or other crash reporters.
Is there a way to solve this problem?
%SDK_DIR%\tools\proguard\bin\retrace mapping.txt errors.txt > fixed.txt
Do the work.
Android studio create mapping(build/outputs/mapping/release/mapping.txt) file under release folder for Release builds. You can use them to find out where the error is occured. Re-mapping is already implemented on Google Play Console and crashlytics. You just put mapping file with corresponding APK to play console and errors are shown correctly.
Today i've checked my crashes and ANR on my google play developer account, The thing is for every crash, The location of the error doesn't exist in my project. I'm getting something like:
nameofpackage.ui.activities.ak.a
My package called activities doesn't have any class called ak, neither a !
also:
nameofpackage.ui.chants.a.onClick
Chants also doesn't have a class called a !
is this normal?
Those names probably generated by proguard. if you have the line:
-printmapping out.map
Inside the rules file of proguard then you have file called:
out.map
In your project tree, there you can see what was the origin class of this Exception.
resolved, there is proguardgui which retrace the pile. You can fin it in:
sdk\tools\proguard\bin
I'am working with a large android project,very large,and we obfuscate our code when we release our apk to market,now the trouble is:
when our application crashed,actually，our application would post the crash log to our service,but the crash log make no mean,because we have obfuscated it already,we got infomation like this:a(),b(Unknown Source),c()....
so,how to deal with it?how to geting a readable crash log in obfuscate apk?Thanks!
When you obfuscate your code, a file called mapping.txt is generated. This file describes the mapping between your original symbols and their obfuscated versions.
If you save this file for your public builds, you can use the retrace tool to deobfuscate any stack traces you receive from crashes, thereby making them useable for fixing bugs! You invoke the tool as follows:
retrace.sh -verbose mapping.txt obfuscated_trace.txt