Can't deliver broadcast错误，随后应用被系统kill掉

lion7beck 2018-09-28 07:22:17


我的一个测试app，会进行：
-音乐播放，一直进行
-视频播放/图片显示：间歇性进行
-CPU高负载运行：一直进行
总计运行4小时。

总计跑了100次，大约5次会出现被系统kill掉的情况。
看log是因为：系统要把广播（android.intent.action.BATTERY_CHANGED）发送给应用时却失败了，从而导致应用被系统杀掉。

其它背景：
-这个应用通过shareUserId的方式与“android.uid.system”共享user ID；
-应用的安装包即apk文件在手机的system/app目录下。
-应用的pid是8047。

不知道什么原因会引起系统发广播给我的应用时，出现了抛出DeadObjectException的失败的情况？

相关log片段如下：


09-27 22:21:58.240  1283  1418 W BroadcastQueue: Can't deliver broadcast to com.my.app (pid 8047). Crashing it.

09-27 22:21:58.242  1278  1402 I ActivityManager: Killing 8047:com.my.demo/1000 (adj 0): scheduleCrash for 'can't deliver broadcast' failed

09-27 22:21:58.259  1283  1418 W BroadcastQueue: Failure sending broadcast Intent { act=android.intent.action.BATTERY_CHANGED flg=0x60000010 (has extras) }

09-27 22:21:58.259  1283  1418 W BroadcastQueue: android.os.DeadObjectException: Transaction failed on small parcel; remote process probably died

09-27 22:21:58.259  1283  1418 W BroadcastQueue: 	at android.os.BinderProxy.transactNative(Native Method)

09-27 22:21:58.259  1283  1418 W BroadcastQueue: 	at android.os.BinderProxy.transact(Binder.java:764)

09-27 22:21:58.259  1283  1418 W BroadcastQueue: 	at android.app.IApplicationThread$Stub$Proxy.scheduleRegisteredReceiver(IApplicationThread.java:1560)

09-27 22:21:58.259  1283  1418 W BroadcastQueue: 	at com.android.server.am.BroadcastQueue.performReceiveLocked(BroadcastQueue.java:491)

09-27 22:21:58.259  1283  1418 W BroadcastQueue: 	at com.android.server.am.BroadcastQueue.deliverToRegisteredReceiverLocked(BroadcastQueue.java:703)

09-27 22:21:58.259  1283  1418 W BroadcastQueue: 	at com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:858)

09-27 22:21:58.259  1283  1418 W BroadcastQueue: 	at com.android.server.am.BroadcastQueue$BroadcastHandler.handleMessage(BroadcastQueue.java:171)

09-27 22:21:58.259  1283  1418 W BroadcastQueue: 	at android.os.Handler.dispatchMessage(Handler.java:106)

09-27 22:21:58.259  1283  1418 W BroadcastQueue: 	at android.os.Looper.loop(Looper.java:164)

09-27 22:21:58.259  1283  1418 W BroadcastQueue: 	at android.os.HandlerThread.run(HandlerThread.java:65)

09-27 22:21:58.259  1283  1418 W BroadcastQueue: 	at com.android.server.ServiceThread.run(ServiceThread.java:46)

09-27 22:21:58.328  1283  7817 I WindowManager: WIN DEATH: Window{5fdb8d6 u0 com.my.demo/com.my.demo.MyTestMain}

09-27 22:21:58.329  1283  2949 I PowerManagerService: Going to sleep due to screen timeout (uid 1000)...

09-27 22:21:58.334  1283  2960 I WindowManager: WIN DEATH: Window{202cf6 u0 com.my.demo/com.my.demo.DemoTestTestingActivity}

09-27 22:21:58.336  1283  1732 W ActivityManager: Scheduling restart of crashed service com.my.demo/.DemoTestService in 1000ms

09-27 22:21:58.337  1283  1732 W ActivityManager: Force removing ActivityRecord{73be0d2 u0 com.my.demo/.DemoTestTestingActivity t18}: app died, no saved state

09-27 22:21:58.401  1283  1732 W ActivityManager: Slow operation: 52ms so far, now at startProcess: returned from zygote!

09-27 22:21:58.401  1283  1732 W ActivityManager: Slow operation: 52ms so far, now at startProcess: done updating battery stats

09-27 22:21:58.401  1283  1732 W ActivityManager: Slow operation: 52ms so far, now at startProcess: building log message

09-27 22:21:58.401  1283  1732 I ActivityManager: Start proc 19855:com.my.demo/1000 for activity com.my.demo/.DemoTestMain

09-27 22:21:58.402  1283  1732 W ActivityManager: Slow operation: 53ms so far, now at startProcess: starting to update pids map

09-27 22:21:58.402  1283  1732 W ActivityManager: Slow operation: 53ms so far, now at startProcess: done updating pids map
...全文
5509 5 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
5 条回复
切换为时间正序
请发表友善的回复…
发表回复
u013816238 2020-04-29
  • 打赏
  • 举报
 回复
这是个很好的问题，希望有更多贡献想法
forrey 2019-04-30
  • 打赏
  • 举报
 回复
最近也遇到类似的问题，但是我们的sdk已经适配target26，项目内代码绝大部分使用了本地广播，部分使用隐式广播intent也加上了packname,不知道为什么还会出现这个问题，请问你最终如何解决的
jzp12 2019-04-30
  • 打赏
  • 举报
 回复
你应该没有register android.intent.action.BATTERY_CHANGED这个广播吧，这是个stick广播，立即返回，
分析是你APP Slow operation导致广播给android.uid.system组的这个广播处理不过来，从面kill了你APP。
jzp12 2019-04-30
  • 打赏
  • 举报
 回复
root cause应该在Slow operation...
先查找到Slow operation的原因
wd623894174 2018-11-30
  • 打赏
  • 举报
 回复
482 void performReceiveLocked(ProcessRecord app, IIntentReceiver receiver,
483 Intent intent, int resultCode, String data, Bundle extras,
484 boolean ordered, boolean sticky, int sendingUser) throws RemoteException {
485 // Send the intent to the receiver asynchronously using one-way binder calls.
486 if (app != null) {
487 if (app.thread != null) {
488 // If we have an app thread, do the call through that so it is
489 // correctly ordered with other one-way calls.
490 try {
491 app.thread.scheduleRegisteredReceiver(receiver, intent, resultCode,
492 data, extras, ordered, sticky, sendingUser, app.repProcState);
493 // TODO: Uncomment this when (b/28322359) is fixed and we aren't getting
494 // DeadObjectException when the process isn't actually dead.
495 //} catch (DeadObjectException ex) {
496 // Failed to call into the process. It's dying so just let it die and move on.
497 // throw ex;
498 } catch (RemoteException ex) {
499 // Failed to call into the process. It's either dying or wedged. Kill it gently.
500 synchronized (mService) {
501 Slog.w(TAG, "Can't deliver broadcast to " + app.processName
502 + " (pid " + app.pid + "). Crashing it."); //here
503 app.scheduleCrash("can't deliver broadcast"); //crash app
504 }
505 throw ex;
506 }
507 } else {
508 // Application has died. Receiver doesn't exist.
509 throw new RemoteException("app.thread must not be null");
510 }
511 } else {
512 receiver.performReceive(intent, resultCode, data, extras, ordered,
513 sticky, sendingUser);
514 }
515 }

@binder.c
4067err_alloc_t_failed:
4068err_bad_call_stack:
4069err_empty_call_stack:
4070err_dead_binder:
4071err_invalid_target_handle:
...
4081 binder_debug(BINDER_DEBUG_FAILED_TRANSACTION,
4082 "%d:%d transaction failed %d/%d, size %lld-%lld line %d\n",
4083 proc->pid, thread->pid, return_error, return_error_param,
4084 (u64)tr->data_size, (u64)tr->offsets_size,
4085 return_error_line);

11-25 09:31:23.786059 1052 1052 I [128416.232769](6)[1052:ActivityManager]binder: 1025:1052 transaction failed 29201/-28, size 792-8 line 3781

return_error --> 29201 --> BR_FAILED_REPLY
return_error_param --> 28 --> ENOSPC /* No space left on device */
31#define ENOSPC 28 /* No space left on device */
RemoteServiceException: can‘t deliver broadcast 问题分析
源码层面分析RemoteServiceException: can't deliver broadcast 问题的根本原因。
Broadcast发送流程分析
Android Source Tools : androidxref.com Original stack trace: android.app.RemoteServiceException : can’t deliver broadcast at android.app.ActivityThreadH.handleMessage(ActivityThread.java:2038)atandroi...
记一次Binder内存不足导致的应用被杀
可以看到BtGatt也在打印错误，这是BLE蓝牙的相关打印，结果压测场景是按住遥控器说话（这个过程会通过遥控器收音，发送语音数据给设备），所以确定是这个操作引发。这个内存不足的猜想，要么是每次传递数据过大，要么就段时间传递的太多了，导致这时候广播通知，跨进程发现共享内存不足，kill APP，通过Log发现parcel size = 160字节，应该不是太大导致，于是开始查看传递次数，发现出问题这次，收音持续了10分钟多，远超过脚本设定的每20S，收音2S的情况。通过过滤这两个关键字，发现是第二个原因。
在Service中发送广播被kill掉的Activity能不能收到？
不能请看下面的实践：在发送广播前，Service会先打印消息，然后再发送广播，当Activity被kill掉后，Service会自动重启，然后继续发送广播，但是此时Activity都被kill了，是收不到广播的。当Activity重启之后能继续接受广播...
BroadcastReceiver 工作过程
说道广播的使用，就不得不提它的两种注册方式，动态注册和静态注册。静态注册在程序启动加载manifest文件时候完成。因此这里就以动态注册来看一下BroadcastReceiver 的工作过程。 注册广播 BroadcastReceiver 是一个抽象的类，因此我们需要继承BroadcastReceiver 实现一个我们自己的广播类 class MyReceiver extends Broa...
Android

80,472

社区成员

91,384

社区内容

发帖
与我相关
我的任务
社区描述
移动平台 Android
androidandroid-studioandroidx 技术论坛（原bbs）
社区管理员
  • Android
  • yechaoa
  • 失落夏天
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告
暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章