Recently I have a published obfuscated Android app with firebase crash reporting enabled. App once crashes and since I haven't uploaded mapping file I cannot read stacktrace properly.
So I wanted to download stack trace and deobfuscate it manually with /retrace.sh -verbose mapping.txt ~/trace.txt
However I'm unable to get raw form of stacktrace...
So I have 2 questions:
How can I get raw form from firebase crash reporting tab on their site?
How can I upload mapping file before publishing app into play store?
Currently, there's no way to get raw stack traces from Firebase Crash Reporting. So you need to copy them manually when viewing the detail of each error.
The problem is the deobfuscation doesn't work with that stack trace string copied from Firebase Crash Reporting, It's because of the missing at statement at the beginning of each line of the stack trace.
For example, this is what you get from Firebase Crash Reporting
Exception java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String com.example.models.User.getUserName()' on a null object reference
com.example.views.adapters.ExampleAdapter.a (SourceFile:110)
com.example.views.adapters.ExampleAdapter.a (SourceFile:31)
b.a.a.a.b.a (SourceFile:54)
b.a.a.a.b.a (SourceFile:54)
android.support.v7.widget.RecyclerView$a.a (SourceFile:6279)
android.support.v7.widget.RecyclerView$a.b (SourceFile:6312)
You just need to add at at the beginning of each line that contains SourceFile string. The result should look like this
Exception java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String com.example.models.User.getUserName()' on a null object reference
at com.example.views.adapters.ExampleAdapter.a (SourceFile:110)
at com.example.views.adapters.ExampleAdapter.a (SourceFile:31)
at b.a.a.a.b.a (SourceFile:54)
at b.a.a.a.b.a (SourceFile:54)
at android.support.v7.widget.RecyclerView$a.a (SourceFile:6279)
at android.support.v7.widget.RecyclerView$a.b (SourceFile:6312)
With this new string, you should be able to deobfuscate the stack trace as usual.
I know, that's a lot of work especially when there are multiple errors occurred but this is the current workaround until the Firebase Crash Reporting team decided to enable a feature to download raw stack traces or just put the at string at the details instead of trimming that out.
Firebase team just recently released a Crash Reporting plugin for this purpose. The guide is here - Uploading ProGuard mapping files with Gradle
Honestly, I haven't been able to enable this plugin successfully, still confused by the guide. I really hope they will make it as simple as in Fabric Crashlytics, by just adding ext.enableCrashlytics = true in the build.gradle file.
There's also another way, by purposely crashing the app before release, then generate a new release APK without the error, and then you can upload the mapping.txt file to Firebase Crash Reporting console. :)
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 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.
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.
I created Xamarin Android app with multidex. I use hockeyapp for crash monitoring. This is my stack trace:
MySpace.MyPage.c004d6fcaf7de57319f01e8b57c149cb4()<dcaea0e8fc154c4c8d3fb16637016fa2>:0
MySpace.MyPage.c2b8486191bd85edf32b8f6498dd867b8.c7e99716f7684490efa5fb61d0ddf4f79()<dcaea0e8fc154c4c8d3fb16637016fa2>:0
MySpace.MyPage.cd793501a5adc9c3bd442847ebe56b06f.c7e99716f7684490efa5fb61d0ddf4f79()<dcaea0e8fc154c4c8d3fb16637016fa2>:0
....
If I understand correctly - dcaea0e8fc154c4c8d3fb16637016fa2 is md5 hash my method(in MyPage). How can I find my method full name?
Md5 to string it is not possible. It remains only to study and decompiling my dex file(with dex2jar and jd-gui).
Any other other(simpler) ideas?
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