We have a shared library which we do not wish to share the symbol names with anything - including Crashlytics.
As such we really want either:
1. The base address at which each .so has been loaded or
2. Module-relative addresses shown in addition to or instead of absolute addresses in stack traces
Either of those would allow us to produce post-processing tooling (ala addr2line, etc) that turn the crash report into something meaningful without sharing library symbols externally.
Is there some way already to get at this information with Crashlytics? If not, any chance it could be added in the near future? What about the crash reporting via Google Play Console?
Crashlytics does not offer a viable solution for this right now. Our symbolication is all or nothing. Thanks!
Related
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.
Various mobile applications we support have crash reporting as an added feature which submits more data to us than the normal device-provided method. We support both iOS and Android apps. This information is sent to us and we shove it into a MySQL database.
This was the first step of the design. Now we want the ability to categorize, group, and count these crash reports by stack trace, device type, app version, OS version, and so on.
We currently are using a MySQL database, as mentioned, but there is no reason we could not move to a different database if it provides better support for what we're trying to do. We are moving our system to AWS, so DynamoDB would be the obvious second choice.
So, before I go any further, if you have any suggestions, please answer now.
More details:
We currently have the following data sent to us:
signal (eg. SIGSEGV)
exception name (eg. java.lang.NullPointerException or NSInvalidArgumentException
exception description (eg. "Unable to instantiate activity..." or "The string argument is NULL")
application name
handheld device type (eg. samsung/m0/GT-I9300 or iPad)
native stack trace (for Android crashes in native code)
OS version (eg. 4.1.1 (SDK Level 16) or 6.1.3)
User ID (if available)
Application version
crash timestamp
stack trace
submission date
other irrelevant data
I am able to group Java stack traces together to some degree using GROUP BY which works surprisingly well... for smaller datasets. But when you have ~300,000 crash logs, it sort of grinds to a halt.
My first thought is to create a separate table for stack traces, include an SHA hash column and add an index to it, which would just be a hash of the stack trace. I could then find or create a stack trace row as necessary. I don't know if this will be faster than simply relying on the database server to do the comparison on the stack trace strings directly. I could include a counter column to count how often each stack trace occurs, although it may be better to simply keep count of those by select count(*) FROM crash_reports GROUP BY fkStackTraceID, so that I could additionally filter by date or application versions.
Currently, this all falls apart when trying to do the same thing with iOS crash logs, or with native Android crash logs. Each one is distinct, due to the inclusion of the memory location of each stack trace each element. I can go to the trouble of finding the offset (which is also included) and subtracting it, which will help.
So some questions:
Are there any other methods of filtering the data to be more easily queryable in whatever way you think would be useful for stack traces? I want to get things right the first time, so any additional ways to separate the data for querying that I can't think of now would be to get in right away.
Is MySQL the best option for this, or would a NoSQL option (i.e. DynamoDB) be more useful?
My previous question again: Are there any prepackaged solutions that do this (or help do this), which function in a manner similar to the crash log sections of the Google Play console and/or the iTunes Connect site?
Found a recent pre-built solution:
http://www.hockeyapp.net
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
Is there any way that I can get crash logs from a device which is signed with a public key, but not uploaded in android market? I need a way to get crash logs from a specific device to see why my application is crashing on it. Anyway to do this?
There are various frameworks for this. ACRA is one of them (http://code.google.com/p/acra/). Another that I frequently use is Bugsense (http://bugsense.com/). There are more also, but I think these two will be perfect for you!
Hope this helps!
Update:
In case you don't want to add any external library, you have to do it by your own. This means that Android in general has a mechanism to catch all uncaught exceptions. This is http://developer.android.com/reference/java/lang/Thread.html#setDefaultUncaughtExceptionHandler%28java.lang.Thread.UncaughtExceptionHandler%29.
There you can catch all uncaught exceptions and handle them as you wish (write to a file, send them, etc). All there libraries internally use this mechanism, but provide a wrapper to the user.
One option is installing and running a LogCat application (e.g. aLogcat) on the target phone. This can capture all logcat output - including exceptions - for the overall system and/or the app in question - using a filter.
Is there a way to report Bugs, similar to the Android Feedback Client, but without registering my application at the market. I'm still working on the application and some users are alpha testing it so it would be useful to receive reports/ stacktraces etc. Is there a common way or an application for that?
You can look at ACRA Project - http://acra.googlecode.com/
You can use Instabug which lets you report bugs right from the app by shaking the phone. It sends you all the device details, network logs, view hierarchy inspection, as well as the steps to reproduce it. It takes a line of code to integrate.
For full disclosure. I work at Instabug.
I've used acra and it works well: http://acra.googlecode.com/
see: How do I obtain crash-data from my Android application?
I have used Android Remote Stacktrace before, it was very easy to setup, but when I set it up I don't think it had as many options as A.C.R.A does - I haven't used either in a while so I'm not sure which is better.