firebase-android-sdk
firebase-android-sdk copied to clipboard
firebase
Lack of ability to submit Crashlytics reports immediately and bug in background submission of non-fatal errors on Wear OS
What feature would you like to see?
After using reportException to report non fatal exceptions, I need the reports to be sent right away. Why? Because the user can just remove the app and never return. Or he/she can return in a day, week, month, who knows. How is it possible for this service to not offer such a rudimentary feature?
P.S calling sendUnsentReports does not help. I'm on Wear OS if that matters.
Edit: Further discussion below discovered non fatal errors would normally be sent in the background on Android devices, but not on Wear OS, due to a bug.
How would you use it?
To report bugs and actually get the report.
I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
Hey @uripre, thanks for filing. For context, Crashlytics usually tries to submit the reports via background network connection post-fatal or non-fatal exceptions, but it's not guaranteed until the app is relaunched. This process flow was done to avoid using up a lot of bandwidth and battery.
In your use case, if the user only uses the app once and never returns, Crashlytics should still be able to send the report in the background network, though, there is no set time when this is sent. As for app deletion, if the user removes the app, all processes in the background network is terminated, so Crashlytics wont be able to send those reports.
I understand your pain point, maybe we could offer an option to allow developers to send reports immediately. While we can't promise any timeline for this feature, I'll bring this up to our engineering sync to get some feedback.
For others who find this useful, adding an emoji thumbs up on the original post can help our engineers prioritize adding this to the roadmap.
Thank you @argzdev for the prompt response.
I have tested this quite extensively by both keeping the app open for an hour, and by closing it and waiting 3 hours+. Nothing seems to trigger the submission besides re-launching the app. I've been trying to provide support to some of my users, and had to explicitly ask them to relaunch the app because the non fatal reports weren't being sent for days.
Sorry you're having a bad experience with our product. I was expecting the background network reports to submit at most in a few hours, not days. I'll try testing this on a wear OS, maybe there's a difference in doze or app standby state of background services of phones vs wear os.
Update: You're right, I think there might actually be a problem with the Crashlytics SDK on Wear OS. The supposed report submission via background network connection doesn't seem to trigger.
I'll notify our engineers about this. Thanks!
@argzdev Thank you for looking into this! I'm quite relieved to hear that's not the expected behavior. Looking forward for a fix 🙏
@uripre I took a look at this. I think there is a misunderstanding about what sendUnsentReports does.
If data collection is disabled, Crashlytics will not upload reports automatically. But they will pile up on the device, up to a small limit (I believe it is 8 but not sure?), until either the user enables data collection, or the app calls sendUnsentReports. The idea here is you could make a UI element to allow the user to choose to send you crash reports, or make some kind of consent dialog such that data collection will not enable until the user explicitly agrees.
Unfortunately sendUnsentReports does not deal with reports at the individual event level, that is why it does not upload your non-fatal events immediately. Instead, your non-fatal events are uploaded when the session is finalized, either by a fatal event or starting a new session of your app.
We have a concept of on-demand fatals for platforms like Unity and Flutter where uncaught exceptions don't crash the app. It sounds like what you want is some kind of on-demand non-fatal api. I will consider this a feature request for that api, but I have no time line or anything to give you right now sorry.
Hi @mrober, thank you for the reply.
I fully understand sendUnsentReports doesn't send the reports immediately. However, both I and whoever created the ticket I referenced (and you can find a few other such tickets/inquiries across the web) would like the option to send the reports immediately, and not only when the session is finalized.
Separately, @argzdev and I discussed a potential problem specific to WearOS. He mentioned that even without relaunching the app, there should be a background network connection that takes care of sending the reports. However, on WearOS, it seems there might be a bug inhibiting this feature. Could you shed some light on whether this is a recognized issue, or is it an inherent design decision that I shouldn't get some of my bug reports?
Hi @uripre, after further discussion, we understand that the behavior is somewhat not the same when comparing Android OS vs WearOS. But the issue falls within the scope that non-fatals will only try to submit the reports via background network connection post-crash, and does not guarantee success until the app is relaunched.
As of the moment, we can't promise any timeline, or when this would be revisited, or if this is something that would change in the roadmap in the near future.
Though this might not be the best, but I think your option for now would still be explicitly ask your users or adding a FAQ on your website or your Google Play Store listing to relaunch the app when encountering these type of issues.
That said, I'd like to ask for a favor for anyone else that encounters the same issue to kindly leave a thumbs up on the author's original post. This'll help us prioritize issues based on severity and demand.
Hi @argzdev. Thank you for taking it into a discussion.
I'm obviously not so thrilled about the decision. In my view, you offer a feature to report "non-fatal" exceptions (which can still be critical), and you support Wear OS. This bug essentially compromises the service you intend to deliver. Typically, service providers don't judge the significance of such issues merely based on the volume of requests vs other feature requests.
Furthermore, there is also the question of why you don't allow users to trigger an immediate submission (relevant to all platforms), especially since it sounds like a small 3 story-points task for someone who's familiar with the repo.
Hi @uripre,
Typically, service providers don't judge the significance of such issues merely based on the volume of requests vs other feature requests.
Yes, you're right. We also keep track of our issues not just on demand but also on severity. As you know, our engineers have a lot of workload on their plate, which is why we prioritize features/issues based on these factors before adding them to the roadmap.
Furthermore, there is also the question of why you don't allow users to trigger an immediate submission (relevant to all platforms), especially since it sounds like a small 3 story-points task for someone who's familiar with the repo.
Just for context, Crashlytics was essentially built this way to balance being lightweight at the same time being able to track reports in an effective manner. As a result, the design for Crashlytics was to batch logged exceptions together and sends them the next time the app launches and not as an immediate submission. The SDK uploads finalized reports, and not as individual events.
We do understand your frustration and we appreciate you showing feedback regarding our product. That being said, what we can do is that we'll try to keep bringing this up to our engineers from time to time to see if it’s possible to explore other options on how we can achieve this in the future. However, please note that we are unable to promise any timeline for this. Thanks!
I created an related issue at https://github.com/firebase/firebase-android-sdk/issues/5896
