Develop Reference

How to use "mapping.txt" file for debug and error-exception handler for Release version in Android

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.

Get raw stacktrace from Firebase crash reporting

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. :)

android NDK HOWTO get stack trace without backtrace

I want to get stack trace when my progrom crash in my .so library, in fact, i call the interface in .so from JNI.
And I follow a old question, but not worked.
All I get in the dumpBacktrace is the signal handler itself.
Here's the link of old question.
platform: arm, ndk-version: android-ndk-r10d

you should definitely check out coffecatch: https://github.com/xroche/coffeecatch

Can't dump the symbols of my native library : loadDataForPdb and loadDataFromExe failed

I copied the sample of Google breakpad for Android and added it to my project. I had first a problem to get the minidumps (I was triggering SIGSEGV errors but nothing was written on my SD card). I finally managed to get some minidumps (I don't really know how but that's not my main problem).
My problem is that I can't dump the symbols of my native libraries, it says the following error message :
dump_syms.exe libcppinterface.so > libcppinterface.so.sym
loadDataForPdb and loadDataFromExe failed
Open failed
Thanks for your help

The Breakpad tools are not very cross-platform friendly. You need to build dump_syms on a Linux machine in order to get a dump_syms binary that can read ELF/DWARF and produce debug symbols from your Android binaries. The Windows dump_syms.exe is only used for dumping symbols from MSVC-produced PDB files.

Obfuscated apk code crash log

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