How do I retrace my Proguard Android App with the Crash report in Google Analytics. A few examples as follows:
Note: when crash reports are done by the User with the Google App Console, I can use retrace OK with the mapping.txt file.
Examples (from Google Analytics Behavior Crashes and Exceptions)
RuntimeException (#a:a:-1) {main}
IllegalStateException (#f:a:-1) {main}
NullPointerException (#MainActivity:M:-1) {main}
NullPointerException (#a:l:-1) {main}
NullPointerException (#al:run:-1) {main}
I just started gathering statistics, and ran into this myself. From an exception that happened to me on a not-obfuscated apk, the syntax seems to be:
exception-name (#class-name:method-name:line-number) {thread-name}
class-name: If this is obfuscated, then you're usually stuck, because the package name is not reported. Sometimes you might be able to find the class, like in your 'al' example, because most packages wont have that many classes (search for '-> al').
method-name: If the class-name isn't obfuscated (some class names have to be excluded from obfuscation for the app to work) you can try to look up the method in the mappings.txt. Often there'll be multiple methods with the same mapping (but different calling signatures). As you can not distinguish between them, then you'll have to check them all to see if they could have caused the exception.
Line number: this of no use since it is is obfuscated (-1).
Conclusion: with the standard reporting, most of the time you wont be able to find out what caused the exception. There seems to be the possibility to set up a custom exception parser, possibly allowing you to include the full stack frame. I have not tried this yet, but found a promissing description in this answer.
Related
We use Crashlytics for reporting crashes faced by our Android app users. A lot of our code is native (c++), hence a lot of crashes are in native code. However most (if not all) of them end up getting grouped under "abort_message.cpp line 77". And this is the top part of the stacktrace for all kind of different crashes -
I have tested by making different kinds of crashes in different files, like throw std::runtime_error("Testing crash"), throw std::logic_error("Testing crash2"), but all of them end up having the top few frames same (as the image above).
Now since the top frame of crash stack is abort_message.cpp line 77 for all of them, they get grouped under same head.
Grouping dissimilar crashes in same group, makes it hard to prioritize and target crash fixes. So is there anyway we can fix this? Or workaround this?
NOTE: We are uploading native symbols to crashlytics alright, and our stack traces are quite detailed.
Another thing that bothers me is that different type of crashes are all reported as SIGABRT.
Fabric/Firebaser here -
This looks to be a C++ exception that Crashlytics is not unwinding very well - this is an aspect of NDK integration with Crashlytics that we're looking to improve for the future. When a C++ exception is thrown, the signal that is raised by an uncaught C++ exception is processed rather than handling the exception itself, resulting in these first few frames of the stacktrace being the same and grouping together different issues as a result.
It should still have the relevant crash information, so the frames below should be different, but the blame frame will be that abort_message frame.
Thanks for the report - it's definitely something we're looking into making better soon.
I also have the same complaint.
Is there a workaround?
Just received a spike alert from Firebase from having the same error spiking, and they were all unrelated crashes (from throw exceptions incorrectly grouped as the same)
Why the Google Play Console of my Production app crash reports (located in "Android Vitals" / "ANR and Crashes" and then select any crash to see a stack trace) contains a lot of ORs in the Stack Trace?
What does it mean? Which of that 12 methods actually caused the crash? Why the report so unclear?
Is there a way to get exact method name and ideally the line number in the report? (I have added mapping file under "Deobfuscation files").
The reason is that you are using Proguard for minifying and obfuscating your code (so far so good), and Proguard reuses the same method names as much as it can (i.e. as long as the signature of the methods are different) to minimize the number of letters it has to use. So the minified code contains most likely a dozen of methods with the name "a" in each class, and the stacktrace only gives you the method name, not its signature, so it's unfortunately impossible to know which one of the dozen "a" methods is being called, hence the deobfuscation tool gives you all the possibilities.
You can customise the Proguard configuration to avoid so many conflicts and hence make it easier to debug for you, but that will be at the cost of your app's size.
Edit: Use the -useuniqueclassmembernames flag to avoid these ORs. You can check the ProGuard manual for more details.
I had the same question some time ago:
Strange stacktrace reported by Google Play Console.
In my case i could notice that only one of the functions in each group could be the right one beacause the others where not invoked inside the "above" function.
I think this is a protection method against reverse engineering.
Some version information first: I am talking about the module com.crashlytics.sdk.android:crashlytics:2.8.0 and the Gradle plugin io.fabric.tools:gradle:1.25.1.
I was excited to learn that Crashlytics can also log caught exceptions as nonfatal issues. But this doesn't seem to work the way I hoped it would.
Firstly, logException doesn't seem to trigger anything until the app is restarted after a crash. This renders the feature of logging nonfatal issues (app caught the exception and kept on running!) pretty useless.
Secondly, if there are two or more exceptions logged via logException before a crash, the last one wins and the others vanish into the eternal void. This is what I have observed during my experiments.
So what am I missing? Is there a way to tell Crashlytics that a logged exception should be sent out right away? Is this the way Crashlytics is intended to work, or is the implementation flawed? As it stands now, log und logException aren't of much use.
You're not missing anything, Crashlytics wasn't really designed with that use case in mind, which is related more to analytics than to crash reporting. You could instead use Answers APIs, also part of the Fabric platform. Note however, that there is no guarantee the logs will be sent right away, there is some delay before they appear in the dashboard.
Obviously with code, errors can occur anywhere. So without having try/catch blocks all over the place (which as I understand it is major overhead) how do I allow errors to bubble up to the application level and then handle them there? Or at the very least, record the error somehow for troubleshooting? I found information on an product called ACRA, but the setup instructions are geared for Eclipse projects. I am using Mono for Android in Visual Studio 2010.
That's a bit of an "It depends" question.
The appropriate handling of an errors is going to depend on what the recovery strategy needs to be, how much information you want the user to see etc.
I wouldn't worry how many Try/Catch blocks you use - just use them wherever you need to handle an error that gets thrown - if they're everywhere, your strategy is probably wrong.
It terms of logging and later interrogation, you can log caught errors using the Android.Util.Log class.
These can be interrogated (provided you're debugging on your own device) using Logcat.
There's some more info on logging and Logcat here.
Found this project that writes crash info to google docs. Android Crasher
In the Android docs it talks about getting an application ready for the market.
It says that you should deactivite Log and debugging.
Is this totally neccessary? Or just an suggestion?
Also how do you go about doing this?
You can remove all logging by running progruard with the correct options.
Android Proguard, removing all Log statements and merging packages
Has some of the options needed. Takes some understanding of Proguard but allows the source to keep the log messages while not worrying about them in a released application. Additionally, you can add the other methods to the config as well to remove logging completely. Not all applications do this. Many of Google's own applications are fairly chatty on the log in release.