Android 前台服务 "Bad Notification" 崩溃机制分析文档

Android 前台服务 "Bad Notification" 崩溃机制分析文档

1. 问题概述

在应用 (com.shawn.guardtest) 启动前台服务 (startForeground) 时，传入的 Notification 包含无法被 SystemUI 解析的布局（引用了 androidx.compose.ui.platform.ComposeView）。导致 SystemUI 渲染失败，进而触发 System Server 的保护机制，最终导致应用进程崩溃并被系统强制查杀。 崩溃信息是通过handler发送消息，最终调用throwRemoteServiceException。但是通过ActivityThread的handler进行try catch，应用仍然会崩溃。

2. 核心原因 (Root Cause)

• 根本原因 ：RemoteViews 机制不支持 Jetpack Compose 组件。SystemUI 进程不包含应用的 Dex 和 Compose 库，解析 XML 时无法找到 ComposeView 类。
• 直接原因：Android 系统（API 31+）强制校验前台服务通知的有效性。当 SystemUI 汇报渲染失败，AMS 判定该服务处于非法状态（Invalid State）。

3. 关键日志证据链 (Log Evidence)

整个崩溃过程在日志中呈现为三个清晰的阶段，完全印证了源码逻辑。

阶段一：SystemUI 渲染失败 (Trigger)

时间点 ：17:09:33.886 进程 ：com.android.systemui 现象 ：SystemUI 试图 Inflate 通知布局时抛出 ClassNotFoundException。

2025-11-28 17:09:33.886 2559-2559 CentralSurfaces com.android.systemui E couldn't inflate view for notification com.shawn.guardtest/0x3e9 android.widget.RemoteViews$ActionException: android.view.InflateException: Binary XML file line #12 in com.shawn.guardtest:layout/notification_error: Error inflating class androidx.compose.ui.platform.ComposeView ... Caused by: android.view.InflateException: Binary XML file line #12 ... Error inflating class androidx.compose.ui.platform.ComposeView Caused by: java.lang.ClassNotFoundException: androidx.compose.ui.platform.ComposeView at java.lang.Class.classForName(Native Method) at java.lang.Class.forName(Class.java:597) at android.view.LayoutInflater.createView(LayoutInflater.java:819) ...

阶段二：应用接收崩溃指令 (Path A: Soft Crash)

时间点 ：(紧随 SystemUI 报错后) 进程 ：com.shawn.guardtest 现象 ：AMS 通过 Binder 通知应用主线程抛出 RemoteServiceException。

2025-11-28 15:51:40.048 27153-27153 ActivityThreadGuard com.shawn.guardtest E Exception message: Bad notification(tag=null, id=1001) posted from package com.shawn.guardtest, crashing app(uid=10247, pid=27153): Couldn't inflate contentViewsandroid.widget.RemoteViews$ActionException: android.view.InflateException: Binary XML file line #12 ...

阶段三：系统强制查杀 (Path B: Hard Kill)

时间点 ：17:20:44.819 进程 ：system_server 现象：AMS 记录下"非法状态"并直接清理进程。

2025-11-28 17:20:44.819 1412-1686 ActivityManager system_server I Killing 14555:com.shawn.guardtest/u0a247 (adj 0): killed for invalid state

---

4. 系统源码执行流程 (Code Flow Analysis)

根据源码追踪，系统内部执行逻辑如下：

1. 渲染报错与上报

   • SystemUI 捕获 InflateException。
   • 调用 IBinder 通知 NotificationManagerService (NMS) 的 onNotificationError 方法。

2. 构建崩溃信息

   • NMS 在 onNotificationError 中构建错误描述："Bad notification(tag= ....."。
   • onNotificationError 调用 ActivityManagerService (AMS) 的 crashApplicationWithType 方法。

1. 执行双重处决 (AppErrors.java) AMS 的 crashApplicationWithType 最终调用 AppErrors.scheduleAppCrashLocked，该方法并行执行了两项操作：

   • 操作 1：发送 Crash 指令 (对应阶段二日志) 调用 ProcessRecord.scheduleCrashLocked -> mThread.scheduleCrash(...)。 这通过 Binder 发送消息给应用进程的 ActivityThread，最终在应用主线程 Handler发送消息SCHEDULE_CRASH ，最终执行 throw new RemoteServiceException(...)。
   • 操作 2：立即查杀进程 (对应阶段三日志) 调用 killAppImmediateLSP(..., "killed for invalid state", ...)。 该方法最终调用 native 层的 Process.killProcessQuiet(mPid)，直接向内核发送 SIGKILL 信号。

5. 时序图总结

6.双重处决的目的是什么

第一重处决：文明的"赐死" (Soft Kill / Crash Instruction)

这是系统给应用留的"最后一点体面"，目的是为了生成错误日志（Stack Trace） ，让开发者知道自己为什么挂了。

• 手段：Binder 跨进程调用。
• 执行者：应用的主线程（UI 线程）。
• 代码路径 ：app.thread.scheduleCrash(...)。
• 表现 ： 应用会在 Logcat 中打印 FATAL EXCEPTION。 你会看到 RemoteServiceException 或 BadForegroundServiceNotificationException。 Crashlytics/Bugly 等崩溃上报工具能捕获到这个异常。
• 目的 ： "告知" 。如果没有这一步，你的进程突然消失了，没有任何 Java 堆栈信息，开发者会一脸懵逼。

第二重处决：暴力的"斩立决" (Hard Kill / Process Cleanup)

这是系统为了系统稳定性 和安全性做的兜底措施。系统认为你的前台服务已经坏了（没有通知），那你这个进程就是"非法"的，必须立刻从内存中清除，不接受任何反驳。

• 手段：内核级信号 (SIGKILL)。
• 执行者：System Server (AMS) 调用系统底层。
• 代码路径 ：ProcessRecord.killAppImmediateLSP(..., "killed for invalid state", ...) -> Process.killProcessQuiet(pid)。
• 表现 ： Logcat 中出现 ActivityManager: Killing <pid> ... killed for invalid state。 进程直接消失，不会走 onDestroy，不会走任何生命周期回调。
• 目的 ： "强制执法" 。确保进程真正死亡，防止应用通过 Hook 吞掉异常后继续在该死的状态下运行（比如占用前台服务配额但不显示通知，这是恶意软件行为）。

7. 结论与解决方案

结论 ： 崩溃是 Android 系统底层机制（ActivityManagerService 和 NotificationManagerService）共同作用的结果。 即使通过 Hook 手段拦截了 Path A 中的 scheduleCrash 消息，应用依然无法逃脱 Path B 中 killAppImmediateLSP 导致的系统级强杀。 所以只是通过hook ActivityThread的handler进行try catch，并不能完全捕获这个崩溃问题。