Closed Bug 1469086 Opened 3 years ago Closed 3 years ago
Crash in android
.app .Remote Service Exception: Context .start Foreground Service() did not then call Service .start Foreground() at android .app .Activity Thread$H .handle Message(Activity Thread .java)
This bug was filed from the Socorro interface and is report bp-4d9fba9e-6e5a-404c-a67a-5fb910180615. ============================================================= android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground() at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1768) at android.os.Handler.dispatchMessage(Handler.java:106) at android.os.Looper.loop(Looper.java:164) at android.app.ActivityThread.main(ActivityThread.java:6494) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:440) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807) ============================================================= There are 14 crashes in nightly 62 starting with buildid 20180612100032. In analyzing the backtrace, the regression may have been introduced by patch  to fix bug 1465102.  https://hg.mozilla.org/mozilla-central/rev/0581ff7ccfef
This seems to be the same situation as the one I mentioned in bug 1384866, originating from google's tracker https://issuetracker.google.com/issues/76112072. I think we should revert the patch for now, ni'ing Jan and Mike for their opinions as well
The notification code is hard to follow: are we certain we've had the opportunity to call `startForeground` before we call `stopService`? One red flag in particular is that `onNotificationClose`, which calls stopService, is `synchronized` implying this class is intended to be accessed from multiple threads. It could be that we call startForegroundService and another thread quickly calls onNotificationClose before the new service can start (which will get queued to run on the UI thread when the intent is launched). It doesn't help that this code is underdocumented (why does it need to be thread-safe? What is the difference between a NotificationClient and a NotificationHelper?). But otherwise, I'd have to dig into the code further to understand what it actually does to provide a better response.
Maybe small downloads (especially on fast connections) manage to complete fast enough that we want to cancel the ongoing "Downloading..." notification again (which entails stopping the service) before the NotificationService had a chance to execute onStartCommand?
bug 1465102 was backed out
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.