nucleus-ffm / foss_warn

An unofficial open source application to get emergency alerts from https://warnung.bund.de/meldungen.
GNU General Public License v3.0
98 stars 6 forks source link

Crash #90

Closed toas-koas closed 10 months ago

toas-koas commented 1 year ago

Describe the bug After start from the phone the app is crashing

To Reproduce Start the phone

Expected behavior No crash

**Device :** - Device: pixel 2xl - OS: Android 13 - App-version Version 0.5.1 - Battery optimization [false] ``` type: crash osVersion: google/lineage_taimen/taimen:13/TQ2A.230505.002/eng.emy.20230613.033103:user/release-keys package: de.nucleus.foss_warn:27 process: de.nucleus.foss_warn java.lang.RuntimeException: Unable to start receiver com.dexterous.flutterlocalnotifications.ScheduledNotificationBootReceiver: java.lang.RuntimeException: Missing type parameter. at android.app.ActivityThread.handleReceiver(ActivityThread.java:4312) at android.app.ActivityThread.-$$Nest$mhandleReceiver(Unknown Source:0) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2149) at android.os.Handler.dispatchMessage(Handler.java:106) at android.os.Looper.loopOnce(Looper.java:201) at android.os.Looper.loop(Looper.java:288) at android.app.ActivityThread.main(ActivityThread.java:7884) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:952) Caused by: java.lang.RuntimeException: Missing type parameter. at g0.a.d(Unknown Source:26) at g0.a.(Unknown Source:7) at com.dexterous.flutterlocalnotifications.FlutterLocalNotificationsPlugin$a.(Unknown Source:0) at com.dexterous.flutterlocalnotifications.FlutterLocalNotificationsPlugin.loadScheduledNotifications(Unknown Source:25) at com.dexterous.flutterlocalnotifications.FlutterLocalNotificationsPlugin.rescheduleNotifications(Unknown Source:0) at com.dexterous.flutterlocalnotifications.ScheduledNotificationBootReceiver.onReceive(Unknown Source:38) at android.app.ActivityThread.handleReceiver(ActivityThread.java:4303) ... 9 more ```
DocSniper commented 1 year ago

Can confirm this issue.

OS: Android 13 (LineageOS 20) App-version: 0.5.1 (F-Droid)

Process: de.nucleus.foss_warn, PID: 10537
java.lang.RuntimeException: Unable to start receiver com.dexterous.flutterlocalnotifications.ScheduledNotificationBootReceiver: java.lang.RuntimeException: Missing type parameter.
    at android.app.ActivityThread.handleReceiver(ActivityThread.java:4315)
    at android.app.ActivityThread.-$$Nest$mhandleReceiver(Unknown Source:0)
    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2152)
    at android.os.Handler.dispatchMessage(Handler.java:106)
    at android.os.Looper.loopOnce(Looper.java:201)
    at android.os.Looper.loop(Looper.java:288)
    at android.app.ActivityThread.main(ActivityThread.java:7918)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
Caused by: java.lang.RuntimeException: Missing type parameter.
    at g0.a.d(Unknown Source:26)
    at g0.a.<init>(Unknown Source:7)
    at com.dexterous.flutterlocalnotifications.FlutterLocalNotificationsPlugin$a.<init>(Unknown Source:0)
    at com.dexterous.flutterlocalnotifications.FlutterLocalNotificationsPlugin.loadScheduledNotifications(Unknown Source:25)
    at com.dexterous.flutterlocalnotifications.FlutterLocalNotificationsPlugin.rescheduleNotifications(Unknown Source:0)
    at com.dexterous.flutterlocalnotifications.ScheduledNotificationBootReceiver.onReceive(Unknown Source:38)
    at android.app.ActivityThread.handleReceiver(ActivityThread.java:4306)
    ... 9 more
nucleus-ffm commented 1 year ago

Thank you for the bug report. I was able to reproduce the problem myself and also found the solution. The problem can be solved if we add some proguards rules as mentioned here by the developer. I added the file and the crash seems to be fixed. A side effect seems to be that fosswarn triggers the next background task only after the defined frequency and not directly at startup. Before that, fosswarn seems to have restarted because of the crash, which also caused the background service to run directly. Maybe we can think about implementing a callback that manually triggers the background task after startup.

HarriBuh commented 11 months ago

Any news on this issue? I have the same (silent) crash on every boot.