Use try/catch #745
Comments
|
Try/catch can work and has been suggested before but it only hides the issue that makes it harder to find out wheb there's an issue for the plugin to fix. Unless you can provide details on reproducing these issues, from what I've been reading, cases like these are due to not having configured everything properly at some point during the development of an app. This tends to be due to not having done the release build configuration |
|
@MaikuB: As I said, I have 3 million downloads. Notice that the most severe log shows errors in only 3619 users. It is NOT my code, nor it is yours. For some users, notifications just don't work. I have this issue since 2017 when my app was written in Xamarin Forms. I never had any kind of problem in none of my devices (I keep 5 devices, including ancient Motorola G from 2013 and iPhone 5S). There is nothing I can provide for you (since I can't get access to those users), and I know it is not my fault nor your, so, yes, ignore those errors make sense (specially in places where there is no Dart code running, such as in receiving notifications or boot restore on Android). I don't know if this is possible in Java/Objective-C, but, in C#, we could ignore errors in release using this not so beautiful hack: #if RELEASE
try {
#endif
do some code here
#if RELEASE
} catch (Exception ex) {
Log the exception here
}
#endif |
|
This Google Play report shows how Android notifications are problematic. In the last 60 days, the most problematic issue was another plugin that handles notifications as well. Works for 75% of the users, 25% crashes. =\ And the code is simple as:
What can we do if |
I don't know what you were trying to convey by mentioning the number of downloads though. Originally you mentioned this and then attached some graphs so I'm not sure what I'm meant to infer from this
One thing though is that at one point, one of the Flutter SDK releases turned on switched over R8, minification etc so it would've been easy to just upgrade the Flutter SDK without realising extra setup was needed for this plugin. More steps needed to be done for the release build configuration compared to the earlier versions of the plugin as well. I'm curious about the issue you had on Xamarin.Forms. Was it exactly the same issue as I use to build apps using Xamarin.Forms.
I assume the testing was done using release builds? You may be well be right that it's due to Android given there are a lot of companies that put their own customisations. Some don't even support background operations. I've had reports of a null intent for the AppAuth wrapper plugin I maintain too and can't make sense of it either MaikuB/flutter_appauth#128 (comment) |
|
By the way, what version of the plugin is your app using? The first crash looks quite odd... Edit: would also like to know what's the earliest version of the plugin that you've used in this app |
|
If it's possible for you to reference a fork of the plugin on your app, I'd be interested to see if it's possible to get the values of the string at this line I've seen someone say without any further explanation or evidence that the string could just be Edit: if you can use a fork that can capture more info and publish an app update out, then I reckon this is the best opportunity to figure out what the problem is in case there's an issue that can be resolved be rewriting some of the code within that receiver that only occurs in some scenarios |
This: the number of users is far superior than the number of users with crashes.
Ok, but this would crash for 100% of users, right?
Scheduled notifications didn't work, again, for just some users. I don't know if it is the exactly same problem, but the behavior is the same: the notifications works for almost all users, except for a few. There are no correlations of OS version, phone manufacturer, etc.
Yes, I always run all features of my app in release mode in all those devices before submiting them to the stores.
Agree, but this would not make some devices to work and others don't, considering they are the same (for example, in the first report, there are 83% of 3619 users in Samsung models. 12% of those are from Galaxy J5 Prime in the last 90 days. I guess this is about 434 devices, according to Crashlytics. But, in the same period, I had 43439 Galaxy J5 Prime users using the app. I can only assume that, given the same model, a small % of it just crashes. And is hard for me to know which one of them are. I always tought this would have something to do with memory pressure, but Crashlytics has some info about that and I'm seeing RAM free as 377Mb, 392Mb, 460Mb even 1.34Gb of free RAM on a Samsung Galaxy S10e. I had this one user that contact us through a support ticket telling she had a brand new LG K9 with 1 week of use. In her old Samsung J4, notifications worked. In this new phone, no notifications. I have one person that have the exactly same model, I borrowed her phone and it worked. =\ That's why so hard to give you useful information or replication procedures. |
According to the adapted source code I have and Google Play Console logs, this lines gives me a: java.lang.RuntimeException: |
From what I've heard, it's inconsistent, so I would guess not
See my previous message on if it's possible for you to use a fork with more logging. This would greatly help in tracking down the issue. The first crash in your original message looks very odd and the only way I can see that happening is if the JSON didn't get saved properly. Ignoring if there's an issue with intents here, the likely cause of this is due to missing configuration for the Proguard rules file at some in time during development. some of them relate to the GSON library that relates to handling JSON on Android. Would be good to know what versions of the plugin you used during the lifetime of your application as well |
I've seen some crash logs where the line numbers don't match the code properly. Not sure why, perhaps due to minification being enabled. Also, another thing I'd like to know is what's in your Proguard rules file for your application |
The problem is my Java knowledge resumes to be able to add a try/catch =P I can't even configure VSCode to use Java 11 without messing the Flutter compilation =( I tried to implement ACRA, but failed (can't compile it). The crashes I have is before the try/catch (as some users didn't updated their apps, some Google reports are fresh)
I don't know exactly how Proguard and R8 works, but I did my best to disable them (before, Google Play reports were useless, because they didn't had any source information on the stacktrace). Don't know if this information is relevant.
In the last month, the latest (I've downloaded the .zip from pub.dev (1.4.4+2) and used dependency_overrides to make it load from disk instead of pub.) |
|
proguard-rules.pro In the past there was some minification = off on build.gradle, but since I've updated to Flutter 1.19, those configs are no longer there. I can't even say if proguard.pro is being loaded (there is no references in any files). |
As an example, if you have Crashlytics then you could look at code to adding logging. If you're unable to assist in investigating further then I'm afraid that at this stage this issue will persist and you'll need to keep your adapted code with the try catch blocks. Adding try/catch fixes the symptoms but properly fixing this issue should address the cause as close possible. The first crash indicates that there's a path in the code that I would not have expected at all.
It's typically referenced in your app's build.gradle file e.g. |
|
As an alternative, if you're willing to remove the try/catch blocks in your code, I'd be interested to know if the following changes to the receiver would fix some of the issues you're having Not something I've tried yet but the idea is to not using the JSON |
|
Did you end up trying the above changes? |
|
Closing due to lack of updates. Note that I have encountered one app that had an error relating to an icon and this was due to calling |
|
Hi @MaikuB , I'm having the same issue and this is the error stack As I'm sure you already know, this only affects Android devices. And it happens whenever the app I'm developing is currently open (foreground) and then a notification arrives. If it's in background, it works well. In this case, this is what's shown in terminal: I'm gonna try and implement this code and see if it works. Whatever the case, I'll give you feedbacks. By the way, I'm using Thanks for the plugin though. Working great so far. Just only this minor hiccup |
|
Well I tried using the code you provided and that didn't work. I decided to use the latest version (which was 6.1.0 at that particular time even though v7.* was later released the same day). I tried that as well and it didn't work. So I ended up using Flutter's I'm doing something like this atm |
|
Unless a minimal app that can reproduce the issue and steps to reproduce are provided, it's not possible for me to look into this further. The changes I suggested above are based on what another person in the community mentioned without presenting any evidence. It was also based on how those who had used a very old plugin may have had corrupted data. It's odd that you're seeing that particular crash as the |
|
FYI it's still happening in 10.0.0-dev.20 with a similar stack trace: I do not have a minimal repro app. I only know these from production error reports. |
|
@noinskit looking at the stack trace, this would mean the app with this trace is using a version of the plugin before 9.1.3. Do you happen to have version control on your app to know what's the earliest version of the plugin your app had used? Asking because the logic that is being triggered is fallback logic for apps using plugin versions older than 0.3.4 given the JSON. Other potential reason I can think of is what I explained in previous posts where apps using the plugin didn't properly configure the Proguard rules. There isn't anything that can't be done to fix that. If the plugin was to add a null check, it could end up swallowing this error that would help point to a misconfiguration |
|
@MaikuB you're right, my bad. It was an ancient version of my app and I misread its version in the prod error report. Sorry! |
Describe the bug
I have an app with 3 million downloads and flutter_local_notifications are the #1 issues on Crashlytics (not because of this plugin, but because Android itself sucks).
What I do is to fill the plugin Java code with try/catches to ignore errors so the app won't crash (the users will not receive notifications, but at least they can use the app).
Here are some logs (those are just examples: almost every point in this plugin crashes, including boot_received):
The text was updated successfully, but these errors were encountered: