I had Firebase Crashlytics installed in my Android app, and the reporting is operational.
However, I found that some issues are very similar:
And it'd be helpful if I could treat them as the same issue when debugging or closing.
Is there any chances I can merge them into one?
It is not possible to merge these crashes. Crashlytics will group the issues based on the frame being blamed. In this case, even though they look similar, the frame is under a different line number.
You could file a feature request for this behavior.
Related
The problem I'm facing is that for a given custom event, sometimes certain event parameters are missing in Firebase, even though logcat is showing that everything was submitted correctly. Most notably, sometimes even some of the firebase_* and ga_* parameters are missing in the DebugView. No errors are showing up in logcat or anywhere else.
The set up is as follows:
Blaze plan
6 custom event parameters in total
firebase-analytics:17.2.0
Android API 28
Not reproducible on iOS, only on Android
Unfortunately I can't provide a MCVE right now, but maybe someone has ideas what could potentially cause this? Is this a bug in the Firebase Analytics SDK perhaps?
This is a known issue in the DebugView according to their support. It doesn't affect the actual data, only the DebugView data.
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.
we experienced an instant app indexing error increase from 0 to more than 100k. We cannot explain the spontaneous increase of errors especially cause each error refers to the HTTP schema of deep links that we do not support at all.
We have established a custom schema which is successfully online since years now. Strange thing is also that despite the error reports, the search traffic seems to be okay. It has not dropped since, what we would have expected if there is a real problem.
What is even more confusing is that the deep links generated by the SearchConsoles help page are faulty. Regardless that they are generated with the HTTP schema the generated ADB command is correct but the generated intent URL for browsers is defininetly wrong.
See this example for the site
http://www.finanzen.net/Kursziele/CEWE_Stiftung:
SearchConsole Help: intent://<OURPACKAGE>/http/www.finanzen.net/Kursziele/CEWE_Stiftung#Intent;scheme=android-app;package=undefined;end
Firebase TestConsole Help: intent://www.finanzen.net/Kursziele/CEWE_Stiftung#Intent;scheme=http;package=<OURPACKAGE>;end
So for the moment we suspect an update of SearchConsole to be responsible for this behaviour. If not we are completely puzzled.
Anyone else experiencing this?
I was seeing similar error reporting anomalies and reached out. I've heard from the App Indexing support team that this is a known issue and they are working on it. No ETA yet.
Copy of email from App Indexing support
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 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.