Develop Reference

CannotDeliverBroadcastException only on Pixel devices running Android 12

I'm seeing a crash come through Crashlytics that I'm unable to reproduce or locate the cause of. The crash only ever happens on Google Pixel devices running Android 12, and the crash always happens in the background.
This is the crash log from Crashlytics:
Fatal Exception: android.app.RemoteServiceException$CannotDeliverBroadcastException: can't deliver broadcast
at android.app.ActivityThread.throwRemoteServiceException(ActivityThread.java:1939)
at android.app.ActivityThread.access$2700(ActivityThread.java:256)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2190)
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:7870)
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:1003)
I've looked at similar questions (like this and this) but Crashlytics is showing that these users all have plenty of free memory, and nowhere in our codebase are we calling registerReceiver or sendBroadcast so the solutions in that second question aren't any help.
Based on limited logs I'm pretty sure the crash happens when the user receives a push notification, but I have a Google Pixel 4a running Android 12 and I haven't been able to reproduce it at all when sending myself notifications.
We have a custom FirebaseMessagingService to listen for notifications that we register in the Manifest and a couple of BroadcastReceivers that listen for geofencing updates and utilize WorkManager to do some work when a transition is detected. The only thing that's changed with any of those recently is we updated WorkManager to initialize itself using Android's app startup library, but I'm not sure if that's even relevant since the crash logs give me no information, and if there was a problem with our implementation it wouldn't limit itself to just Pixel devices running Android 12.
Has anyone see this before or is there a bug exclusively on Pixel devices that run Android 12? I've spent hours digging into this and am at a complete loss.

With reference to Android 13, rather than earlier issues on 12, there is a Google tracker issue here, which at the time of writing is assigned but awaiting a meaningful response.
A summary of the issue is that it only occurs on 13, and only on Pixel devices.
CommonsWare has a blog entry on this here, and the only other clue I found anywhere was in the changelog for GrapheneOS, here, which has this line entry:
Sandboxed Google Play compatibility layer: don't report CannotDeliverBroadcastException to the user
We use this Play library and experience the fault, so it's possible Graphene have encountered this and had to put in an OS fix.
Update:
I tentatively believe that we as an app have suppressed this issue, and stopped it polluting our stats.
We set an exception handler to absorb it, which is what GrapheneOS are doing - credit to them.
class CustomUncaughtExceptionHandler(
private val uncaughtExceptionHandler: Thread.UncaughtExceptionHandler) : Thread.UncaughtExceptionHandler {
override fun uncaughtException(thread: Thread, exception: Throwable) {
if (shouldAbsorb(exception)) {
return
}
uncaughtExceptionHandler.uncaughtException(thread, exception)
}
/**
* Evaluate whether to silently absorb uncaught crashes such that they
* don't crash the app. We generally want to avoid this practice - we would
* rather know about them. However in some cases there's nothing we can do
* about the crash (e.g. it is an OS fault) and we would rather not have them
* pollute our reliability stats.
*/
private fun shouldAbsorb(exception: Throwable): Boolean {
return when (exception::class.simpleName) {
"CannotDeliverBroadcastException" -> true
else -> false
}
}
}
We have to operate off class name strings because the CannotDeliverBroadcastException class is hidden and not available to us.
We install this handler early in the Application.onCreate() method, like this:
val defaultUncaughtExceptionHandler = Thread.getDefaultUncaughtExceptionHandler()
Thread.setDefaultUncaughtExceptionHandler(
CustomUncaughtExceptionHandler(defaultUncaughtExceptionHandler)
)
I might be a bit premature with this, but so far this has resulted in none of these crashes appearing in Play Console. A few did appear in our other reporting platform, where what is/isn't reported has always varied.
To be clear, I'm not suggesting this is a good approach, or one that you should necessarily take. It requires a client release and it risks masking exceptions not relating to this root cause. Fixing or ignoring this issue at the point of collection is Google's responsibility. However, it has seemingly stopped the impact on our headline reliability statistics, so I thought I'd share it as a possibility.

Our team has noticed a significant downtrend in this crash over the past few months. Possible Google has begun to roll out a fix for Pixel devices. We also have the same crash happening for Pixels running Android 13 and it's also seeing a downtrend. Hopefully others are seeing this as well.

I'm not sure if this will be helpful to anyone, but once we removed WorkManager (which was being initialized via the App Startup library) the crash stopped happening. This was removed alongside a bunch of other code, so I can't say for sure if WorkManager was the problem, if the App Startup library was the problem, or if something else that we removed fixed it.

I received a pre-launch report of my app showing the same problem:
android.app.RemoteServiceException$CannotDeliverBroadcastException: can't deliver broadcast
Device: google Redfin 64-bit only
Android version: Android 13 (SDK 33)
The solution proposed by Rob Pridham fixed the problem. Just in case someone prefers to use Java...
This is the CustomUncaughtExceptionHandler class added to MainActivity:
public static final class CustomUncaughtExceptionHandler implements Thread.UncaughtExceptionHandler {
private final Thread.UncaughtExceptionHandler uncaughtExceptionHandler;
public void uncaughtException(#NotNull Thread thread, #NotNull Throwable exception) {
Intrinsics.checkNotNullParameter(thread, "thread");
Intrinsics.checkNotNullParameter(exception, "exception");
if (!this.shouldAbsorb(exception)) {
this.uncaughtExceptionHandler.uncaughtException(thread, exception);
}
}
private boolean shouldAbsorb(Throwable exception) {
String var10000 = Reflection.getOrCreateKotlinClass(exception.getClass()).getSimpleName();
if (var10000 != null) {
return "CannotDeliverBroadcastException".equals(var10000);
}
return false;
}
public CustomUncaughtExceptionHandler(#NotNull Thread.UncaughtExceptionHandler uncaughtExceptionHandler) {
super();
Intrinsics.checkNotNullParameter(uncaughtExceptionHandler, "uncaughtExceptionHandler");
this.uncaughtExceptionHandler = uncaughtExceptionHandler;
}
}
This is the code added to Oncreate:
Thread.UncaughtExceptionHandler uncaughtExceptionHandler = Thread.getDefaultUncaughtExceptionHandler();
assert uncaughtExceptionHandler != null;
Thread.setDefaultUncaughtExceptionHandler(new CustomUncaughtExceptionHandler(uncaughtExceptionHandler));

Debugging Java InterruptedException i.e. finding the cause

During debugging of Android app, sometimes InterruptedException occurs and crashes the app. I've been able to set a break-point on default exception handler, but call stack is not informative.
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.reportInterruptAfterWait(AbstractQueuedSynchronizer.java:1991)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2025)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1048)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:776)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1035)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1097)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at java.lang.Thread.run(Thread.java:820)
What is telling is that the interrupted thread is always RxCachedThreadScheduler-4 (or some other number)
What would be a systematic approach towards finding the root cause of the exception?

Set breakpoint at the method Thread::interrupt and catch the offender. If you think that this interruption should not happen, and you cannot switch off the call which interrupts your thread, then you can override Thread::interrupt in your thread implementation, and force the the thread pool to use your implementation by providing your own ThreadFactory.

It looks like the crash is happening from a third party code package, you should post your issue with the source project as well for additional help. Please post any code related to how you use this package to help troubleshoot too. Make sure you're using the latest version of this package in case they already fixed this issue. The stack trace isn't very helpful because the other project is launching threads and the crash happens from within one of their threads. Likely, you're not using the package as intended or there is a bug in it that they need to fix.
https://github.com/ReactiveX/RxJava

Widgets lead to DeadObjectException - Transaction failed on small parcel

I'm getting following exception as soon as I want to show a widget and start listening:
// the relevant stack trace, the rest is comming from my code
// before the code line I posted below
java.lang.RuntimeException: system server dead?
at android.appwidget.AppWidgetHost.startListening(AppWidgetHost.java:189)
at com.my.app.utils.WidgetUtil.a(SourceFile:231)
...
android.os.DeadObjectException: Transaction failed on small parcel; remote process probably died
at android.os.BinderProxy.transactNative(Native Method)
at android.os.BinderProxy.transact(Binder.java:503)
at com.android.internal.appwidget.IAppWidgetService$Stub$Proxy.startListening(IAppWidgetService.java:481)
at android.appwidget.AppWidgetHost.startListening(AppWidgetHost.java:185)
at com.my.app.utils.WidgetUtil.a(SourceFile:231)
...
The source in my code is following code line:
mAppWidgetManager = AppWidgetManager.getInstance(context);
mAppWidgetHost = new AppWidgetHost(context, R.string.app_name);
mAppWidgetHost.startListening(); // <= this line leads to the crash
Observations
my app is working normally on a lot of phones (all but one actually)
above crash only happens on one users device (SM-N910C (Samsung Note 4), Android 6.0.1)
the user says, those widgets work fine in his launcher
Does anyone has an idea what could cause this? Is this something I can solve in my app? The user says widgets are working fine in his launcher...

So, a simple Google search led me to this definition of a DeadObjectException :-
The object you are calling has died, because its hosting process no longer exists.
From this, it is obvious that you're getting this error because the process that's hosting mAppWidgetHost has been killed off.
The question now is that why are you getting this error. Overriding and logging onDestroy() to monitor it could be useful, and definitely is worth a shot. But, since its working on all devices except for one, its more than likely that there's nothing wrong with the onDestroy() method. Instead, the OS is killing the process off before you can access the object.
So, now why is the OS doing that? This question had me balled up for the longest time. I still do not have a clear answer or solution to this despite a bevy of Google searches with all kinds of related to the problem. But, after spending a considerable amount of time searching, I noticed a peculiarity - most of the issues with this exception, such as this, this and yours happen with Samsung devices.
My guess is that Samsung's underlying architecture leads to this problem. And, while I do not have a reason why this happens or a plausible solution even after a lot more searching, this could still be a start to find a work around targeting Samsung devices.
UPDATE
I searched a bit more and came across this answer. Take a look at the last comment by the question author on the question :-
Finally it is working fine just by a line of code in manifest file, here it is android:hardwareAccelerated="false" If anybody get the following kind of errors please try by adding the above line signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
I don't know the logic behind this or if it would work or not. Just sharing it with the hope that it could help you - even in the minutest form.

DeadObjectException :
The object you are calling has died, because its hosting process no longer exists.
Possible Solutions:
1) Override your service's onDestroy() method and watch what event flow leads to it. If you catch DeadObjectException without going through this method, your service should have been killed by the OS.
2) by removing Typeface , this might be because of ttf which i was using from assets folder Please try comment the typeface and test it hope it will work for sure
3) put all your code inside the onCreate. From there you will see what is the culprit like a NullPointerException for example but your code will run smoothly already.

App dies with "Sending signal." but no exception or other info

I'm working on an app that is recording data via Bluetooth, but it intermittently crashes after hours of collecting data (making it hard to track down the bug).
The logcat output isn't very helpful:
http://i.imgur.com/EalnX.png
There are no exceptions thrown and no clues for what caused the process to be terminated.
How can I figure out what went wrong? Is there an exception being thrown that isn't being shown by logcat? How can I track this bug down?

Signal 9 is SIGKILL, which will terminate a process immediately (no handlers inside the process will run). From the log line, the process is killing itself, so its not an external agent that is issuing the SIGKILL.
My guess (and its really a guess) is that the memory management code running inside your process (as part of the infrastructure, not code that you wrote) is deciding that you've exhausted some resource and the only recourse is to die. I would expect there to be more messages before this point is reached in the log, so it may be worth browsing the log history to see if there are useful warnings from the process before this point.
The line immediately before this is a GC log, which implies that some sort of memory resource is running low. But it looks like the heaps are not full, so failing allocations seems unlikely. You can still get allocation failures if the object being allocated was too large to fit on the heap, or fragmentation prevented it from being allocated. I'd expect to see more relevant log messages in this case, though.
I think capturing more of the log (perhaps filtering it by your app's PID if necessary) will help you make progress.

In my case there was no warnings or any clues in the log.
Eventually I found that my problem was that one of the activities I was going into (lets say Activity X) was registering to a broadcast receiver but never unregistered from it.
Therefor by closing the activity (Activity X) and coming back to it caused registering Again to the same broadcast receiver - which caused the mess!
Simply adding unregisterReceiver(mybroadcast); (in Activity X) solved it.
(I added mine to onDestroy. make sure you unregister in the right location).
And if you are super desperate I recommend seeing this slide share which explains Android crash debugging your errors.

this problem happens when using RXjava and not implement the onError callback method

Getting: Not allowed to start service Intent ... without permission Service process is bad

ACRA's crush report sends me this error.
java.lang.SecurityException: Not allowed to start service Intent { act=auto_update cmp=net.DailyTimer.CalendarAlarmHelperFree/net.DailyTimer.CalendarAlarmHelper.CalendarAlarmService } without permission Service process is bad
I see this error on limited devices and I can't reproduce. I guess this error depends on running environment.
My question is:
What permission is wrong? I could not find out what "Service process is bad" mean.
EDIT:
I'm getting this error when calling startService(intent) to start remote service. And on many devices it works fine.

Although I have not experienced this myself, I did some looking around and I think these might be useful to you. Here, user Jomia says:
The java.lang.SecurityException you are seeing is because you may
enter two entries pointing to same activity. Remove the second one and
you should be good to go.
Also, consider taking a look at this page, specifically under public static final int CONTEXT_INCLUDE_CODE. Here is the relevant part:
Setting this flags imposes security restrictions on what application
context you can access; if the requested application can not be safely
loaded into your process, java.lang.SecurityException will be thrown.
If this flag is not set, there will be no restrictions on the packages
that can be loaded, but getClassLoader() will always return the
default system class loader.
I hope I could be of some help. If these responses are unrelated to your issue, you might want to try posting relevant code, etc. Cheers.

see Source code Line 10494，if method "bringUpServiceLocked" return false, it would throw "Service process is bad" Exception
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.0.1_r1/com/android/server/am/ActivityManagerService.java#ActivityManagerService.startProcessLocked%28com.android.server.am.ProcessRecord%2Cjava.lang.String%2Cjava.lang.String%29