Issue Trackers and the "Can't Deliver Broadcast" Bug
There is a bug, unique to Android 13, with this stack trace:
Fatal Exception: android.app.RemoteServiceException$CannotDeliverBroadcastException: can't deliver broadcast at android.app.ActivityThread.throwRemoteServiceException(ActivityThread.java:1980) at android.app.ActivityThread.-$$Nest$mthrowRemoteServiceException() at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2242) 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:7898) at java.lang.reflect.Method.invoke(Method.java) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
Application code does not appear in the stack trace, and it shows up in apps that do not send or receive broadcasts on their own. The culprit probably is some library (possibly Firebase Cloud Messaging).
So, the community did the right thing and reported this bug, back on September 6. To date, a bunch of name-brand companies have reported seeing the problem with Android 13 devices, including:
- the BBC
Those are just the ones identifiable by domain name. My current employer is part of a similarly-sized brand, and we haven’t posted a “me too!” comment, so my guess is that lots of others are just watching this issue, hoping for a fix.
And it’s probably going to take “somebody who knows somebody” for this issue to get much attention.
Google’s issue tracker has a so-so track record of getting conclusive results. Personally, I have filed 19 issues in that component, only 8 of which got to a real end status (Fixed, WAI, or Infeasible). 3 are still open, including one from 2019. And 8 are “Obsolete”, which basically means it was ignored and then closed. I have a similar track record overall.
Compounding the problem is that this component is riddled with spam. Only 38 of the most recent 250 tickets are real. The rest are spam.
The vibe that this gives off is that Google has largely given up on this issue tracker. That’s Google’s right, of course, as it is their issue tracker.
But, then, how does Google want us to report problems like the one cited above?
In truth, the viability of this issue tracker seems tied to the particular
component. Some Jetpack libraries do a solid job of making use of the issue tracker.
Other components, like the one for
are where issues go to die, buried under yet more spam.
If you work for Google, and you want the community to report issues, make sure that we know where that is. Perhaps it is this issue tracker, in a better-maintained component (or at least one the spammers aren’t using). Perhaps it is GitHub’s issue tracker for some relevant repo. Perhaps you find the best approach is by unofficial means, such as Kotlinlang Slack or social media. So long as you tell us what we should use, we can use it.
And, um, if somebody could look at that bug, I’d really appreciate it.