Skip to main content

Chapter 157: Android Full Stack Capability Path

Android Full Stack 能力路径指一项应用可见能力从 App 调用入口开始，经过 Framework API、Binder、系统服务、HAL、Linux kernel、driver，最后落到硬件或底层资源，再把结果、状态或错误返回给应用的完整责任链。本章用一次相机预览请求作为贯穿材料：应用调用公开 API 打开摄像头，系统判断权限和前后台状态，Camera 相关服务协调设备占用，HAL 连接厂商实现，内核驱动和硬件完成采集，结果再通过回调、buffer 和错误码回到 App。

读完本章后，读者应能把任意 Android 能力沿同一条路径追踪：先定位 App 调用的公开 API，再定位 Framework 代理和 Binder 接口，再判断系统服务承担的权限、状态和资源仲裁职责，接着识别 HAL 与 vendor 边界，最后把驱动、SELinux、调度、内存和硬件状态纳入失败分析。这个能力用于分析相机打不开、定位无结果、音频路由错误、网络请求被系统收缩、后台任务被限制等现象。

本文以 Android 8 之后的 Treble 分层和 Android 10/11 之后 Stable AIDL、AIDL HAL 的演进方向作为主要版本边界。AOSP 的 Architecture overview 把 app、framework、system services、HAL、native daemons、kernel 放入同一软件栈；本文在这个公开结构之上，把每层转成可检查的请求路径和责任边界。

本章结论是：Android 的系统能力开放给 App 时，App 拿到的是 API 和回调，系统真正持有的是身份、权限、资源状态、vendor 接口、驱动访问和硬件队列。排查一项能力时，稳定顺序是从 App 可见 API 向下追踪责任主体，再从用户可见失败向上还原返回路径。

157.1 Android Full Stack 的分层总图​

Android Full Stack 的第一层判断是把“能力”看成跨层路径。以相机预览为例，App 看到的是 CameraManager.openCamera()、权限弹窗、预览画面、回调和错误码；系统内部处理的是 UID 身份、权限状态、foreground 状态、camera device 占用、HAL 接口版本、driver buffer、sensor 输出和 display / graphics buffer 消费。AOSP 架构文档把 Android framework 定义为 app 构建所依赖的 Java 类、接口和预编译代码，并说明 framework API 会和 system services 通信以访问底层硬件；这给出了 Full Stack 路径的公开分层依据。

这条路径可以先压缩成一个方向明确的链条：

图中的每个节点都回答一个不同问题。App process 表示应用代码的执行身份和生命周期。Framework API 表示公开能力入口和调用语义。Binder proxy 表示跨进程通信和调用方身份传递。System service 或 native service 表示系统资源所有者。Policy and resource arbitration 表示权限、前后台、并发占用和系统状态判断。HAL interface 表示 framework / vendor 边界。Vendor implementation 表示厂商针对 SoC、sensor、firmware 的实现。Linux kernel driver 表示设备文件、内存、调度、中断、DMA、网络栈和安全策略的底层执行点。Hardware 表示能力源头。

相机预览请求在这张图里不是“调用一个库函数”。App 进程发出请求后，Framework 侧会把请求转成面向系统服务的调用。Binder 把调用传到服务进程，并携带调用方身份。服务检查权限和当前资源状态，选择 camera provider / HAL 设备，HAL 与 vendor 实现交互，driver 和硬件产生 frame buffer，服务再把状态变化、错误或 frame 可用事件送回 App。预览画面显示成功时，App 只看到 Surface 上有画面；路径稳定时，每层都完成了自己的判断。

Android Full Stack 分析的关键是保持同一组检查维度：入口 API、调用方身份、系统服务、权限与策略、资源所有权、vendor 边界、kernel 支撑、硬件状态、返回形式。后续小节依次展开这些维度，最终在 157.8 形成可迁移的标准路径。

157.2 App Layer：APK、Process、Component、Sandbox​

App Layer 是能力路径的发起层，它定义了请求从哪个包、哪个 UID、哪个进程、哪个组件、哪个生命周期状态发出。Android Developers 的 Application fundamentals 说明 Android SDK 工具会把代码、数据和资源编译为 APK 或 Android App Bundle；同一文档还说明每个 Android app 处在自己的 security sandbox 中，系统默认给每个 app 分配唯一 Linux user ID，每个 app 默认运行在自己的 Linux process 中。

APK 或 Android App Bundle 是分发和安装单元。系统读取 AndroidManifest.xml 后，才能知道应用声明了哪些组件、权限、硬件特性和最低 API level。组件是系统进入 App 的入口，核心类型包括 Activity、Service、Broadcast receiver 和 ContentProvider。相机预览请求通常由前台 Activity 发起，因为用户可见页面提供了授权、预览 Surface 和生命周期锚点；如果请求来自后台 Service，系统会把后台限制、前台服务要求、相机隐私策略和用户可见提示纳入判断。

Process 是代码实际执行的地址空间。Android 可以在组件需要执行时启动应用进程，也可以在内存紧张时回收不再需要的进程。这个设计把应用生命周期和系统资源回收绑定在一起。相机预览请求到达系统服务时，服务关心的不只是方法名，还会读取调用方 UID、PID、包名、用户 ID、前后台状态和已授予权限。UID sandbox 使 App 默认只能访问自己的文件和被授权的系统能力；同一 UID、签名共享、ContentProvider URI grant、runtime permission 是穿过沙箱的受控方式。

App 层的可见失败通常有四类。第一类是 API 前置条件失败，例如没有声明 android.permission.CAMERA 或运行时授权被拒绝。第二类是生命周期不满足，例如 Activity 已经停止、Surface 已释放、后台状态触发系统限制。第三类是身份或包状态不满足，例如包被禁用、权限被撤销、当前 user profile 无权访问该设备能力。第四类是系统下层失败向上传递，例如 camera device 被占用、HAL provider 不可用、driver 超时、硬件断开。

把 App Layer 放入完整路径时，应先记录五个输入事实：包名和 UID、发起组件、生命周期状态、manifest 声明、用户授权状态。缺少这些事实时，后续 Binder、system service、HAL 和 kernel 分析容易混在一起。相机打开失败时，先确认“哪个 App 身份在什么状态下请求哪项能力”，再向下追踪服务和硬件。

157.3 Java / Kotlin Framework API 作为系统能力入口​

Java / Kotlin Framework API 是 App 能力请求的公开入口。它把底层服务能力整理成稳定的 SDK 类型、方法、回调、异常和权限语义。AOSP 架构文档把 Android API 描述为第三方开发者可用的公开 API，把 Android framework 描述为 app 构建所依赖的 Java 类和接口；这说明 App 看到的能力入口首先是 Framework 的 API 表面，而服务实现和硬件细节在后面分层承接。

Framework API 常见形态是 manager class 加 callback。相机使用 CameraManager、定位使用 LocationManager 或 Google 生态中的 fused location API、网络使用 ConnectivityManager、音频使用 AudioManager。这些 manager 通常通过 Context.getSystemService() 获取，内部持有到系统服务的代理对象。App 调用 manager 方法时，Framework 会检查参数形态、整理 callback executor 或 handler、把 Java / Kotlin 层对象转成可跨进程传递的数据，再进入 Binder 调用。

Permission check 在 Framework API 处有两层含义。第一层是公开 API 文档告知开发者需要声明和请求哪些权限，例如 Android Developers 的 Permissions on Android 区分 install-time permission、runtime permission 和 special permission。第二层是调用路径中的实际检查点，可能发生在 Framework API、system service、native service、HAL 访问前或 kernel / SELinux 边界。相机请求中，App 需要在 manifest 中声明相机权限，并在运行时拿到用户授权；服务侧还会结合 AppOps、前后台状态、隐私开关和设备占用状态继续判断。

Callback 是系统能力返回 App 的主要方式。同步方法适合返回轻量状态，例如 service handle、当前配置或立即可判断的错误。硬件能力通常需要异步返回，因为设备打开、流配置、buffer 生产、传感器状态变化和错误上报都可能跨越多个线程和进程。相机预览的 StateCallback、capture callback、surface buffer 事件共同构成返回路径。App 端看到的 onOpened、onDisconnected、onError 对应系统内部的权限判断、设备状态、HAL 状态和硬件错误。

Framework API 的分析方法是把公开方法拆成四个问题：它要求 App 提供什么输入，它代表什么系统能力，它通过哪个服务代理下沉，它把成功、拒绝、超时、断开和异常用什么形式返回。只停留在 API 用法会丢失系统责任；只看 system service 又会丢失 App 可见语义。稳定分析要把二者连在一起。

157.4 Binder 作为 Framework 与 System Service 的 IPC 主干​

Binder 是 Android Framework 与 system service 之间的 IPC 主干。AOSP 的 AIDL overview 说明 AIDL 用来抽象 IPC，构建系统会根据 .aidl 接口生成 C++ 或 Java binding，使接口可跨进程使用；同页还说明 AIDL 调用会使用 binder kernel driver，把方法标识和对象打包到 buffer，并由远端 binder thread 接收后调用本地 stub 对象。

从 App 视角看，Framework manager 像普通对象。从系统视角看，manager 里的远端接口通常是 Binder proxy。Proxy 把方法调用转成 transaction，Binder driver 把 transaction 送到服务进程，服务端 stub 解包并调用真正的服务实现。这个过程保留调用方身份，使 system service 可以读取 caller UID / PID，并把权限检查和资源策略绑定到真实 App 身份。

相机预览请求经过 Binder 时，最关键的信息不是“调用到了哪个函数”，而是 transaction 携带的对象引用、callback binder、Surface / buffer 相关 handle、调用方身份和同步 / 异步语义。callback 本身也可以是 Binder 对象，服务端保存 callback 后，后续用它把状态变化发回 App。服务死亡、App 进程死亡、callback owner 死亡都会影响这条关系，因此 Binder 的 death recipient 是系统清理资源的重要工具。相机服务发现 App 进程死亡后，需要释放设备占用、断开 session、清理 buffer 和 callback。

Binder thread pool 决定服务进程如何处理并发 transaction。一个 system service 同时面对多个 App、系统组件和 native 服务请求，线程池既要承接调用，也要防止耗时操作阻塞关键路径。服务实现通常会把重任务转移到内部 handler、native thread、设备队列或 HAL callback 中，Binder 线程负责边界检查、对象分发和结果返回。相机、音频、图形这类能力还会叠加高频 buffer 或事件流，系统会把控制路径和数据路径拆开，控制用 Binder，数据用共享内存、buffer queue、DMA-BUF 或专用队列。

Android 8 之后，AOSP 文档中的 Use binder IPC 说明 framework 与 HAL 之间的通信也开始使用 Binder，并引入不同 Binder domain 来拆分 framework 与 vendor 流量；Android 10 的 Stable AIDL 进一步给跨更新边界的接口提供稳定性约束。这里的版本信息说明 Binder 不只连接 App 和 system_server，也连接 framework、native service、HAL 与 vendor 实现。分析 Full Stack 时，应把 Binder 视为身份、对象生命周期、并发和接口稳定性的共同边界。

157.5 System Service 作为能力代理与资源仲裁层​

System Service 是能力路径中的资源代理和策略执行层。AOSP 架构文档列举了 system_server、SurfaceFlinger、MediaService 等 system services，并说明 Framework API 暴露的功能会与 system services 通信以访问底层硬件。实际系统中，服务可能是 Java service 运行在 system_server，也可能是 native service 运行在独立进程，例如 SurfaceFlinger、AudioFlinger、cameraserver 相关服务。共同点是它们代表系统持有状态，并向 App 暴露受控能力。

以相机为贯穿材料，Camera 相关服务要处理五类职责。第一类是权限检查，包括 manifest / runtime permission、AppOps、用户设置、sensor privacy、前后台状态和 profile 限制。第二类是状态管理，包括设备列表、camera ID、可用性、打开状态、session、stream 配置和 callback 注册。第三类是资源分配，包括同一时刻哪些 App 可以使用哪些 camera、是否支持并发、哪个请求需要被拒绝或断开。第四类是策略执行，包括隐私指示器、后台收缩、系统组件优先级和错误上报。第五类是错误返回，把权限拒绝、设备占用、服务死亡、HAL failure、driver timeout 转成 App 可见异常或 callback。

System Service 的价值在于把硬件能力变成可审计、可授权、可仲裁的系统能力。硬件摄像头本身只产生图像信号；Android 对 App 开放的是“在特定身份、生命周期、权限、隐私设置和资源状态下打开 camera device 并接收 buffer”的能力。这个包装让多个 App 和系统组件可以共享同一套规则，也让用户能通过权限页面、隐私开关、状态栏指示器和应用生命周期看到控制结果。

服务层排查要抓住责任边界。权限拒绝属于 service 或 Framework 策略返回；设备被占用属于 service 的资源仲裁结果；HAL 不匹配属于 service 到 HAL 的 vendor 边界问题；driver 超时属于 HAL / kernel / hardware 方向的下层失败；App 进程死亡后的资源释放属于 Binder death 和 service cleanup。把这些现象全归结为“相机 API 失败”会丢失责任主体。

服务层还负责把系统状态转成稳定的开发者语义。比如同样是相机打不开，App 可能收到 SecurityException、CameraAccessException、onDisconnected、onError 或超时后的 UI 卡住。每种返回形式都对应不同检查点：同步权限异常通常发生在请求入口，disconnected 可能表示设备被系统或更高优先级 client 拿走，error 可能来自 HAL 或设备错误，长时间无回调可能指向服务线程、HAL callback 或 driver 事件链。服务层是这些返回语义的汇总点。

157.6 HAL 作为 Framework 与 Vendor Hardware 的边界​

HAL 是 Framework 与 vendor hardware 之间的标准接口边界。AOSP 的 HAL overview 定义 HAL 为硬件厂商实现的标准接口层，它允许厂商实现低层设备特性，同时不影响更高层代码。这个定义说明 HAL 的核心任务是稳定接口、隔离厂商实现、支持系统层按统一方式调用硬件能力。

Android 的 HAL 历史需要按版本边界理解。Android 8 以前存在 legacy HAL 模式，Android 8 的 Treble 架构强化了 framework 和 vendor 的更新边界，并推动 binderized HAL 与 HIDL 接口。AOSP Binder IPC 文档说明 Android 8 后 framework 和 HAL 使用 Binder 通信，并通过 /dev/binder、/dev/hwbinder、/dev/vndbinder 等 domain 区分 framework / vendor 方向的 IPC。Android 10 引入 Stable AIDL 方向，AOSP AIDL 文档说明当 AIDL 用于分开更新的平台组件、APEX 或 HAL 时，需要使用 Stable AIDL；文档还指出 HAL 从 Android 11 开始属于这种跨更新边界场景。

AIDL HAL 和 HIDL HAL 的共同目标是让系统通过稳定接口使用 vendor 实现。接口描述了方法、数据结构、错误返回和版本语义。Vendor implementation 则把接口调用映射到 SoC driver、firmware、sensor、ISP、DSP、modem 或其他设备能力。Framework 和 service 不需要知道每个厂商芯片的寄存器和内部队列；它们根据 HAL contract 调用，HAL 再负责把请求变成厂商设备可执行的操作。

VINTF 是 HAL 边界的兼容性清单。AOSP 的 VINTF object 文档说明 VINTF object 汇总设备信息并通过可查询 API 暴露；device manifest 描述设备可提供给 framework 的静态组件，framework compatibility matrix 描述 framework 对设备的期望，二者在 OTA 时需要匹配。对 Full Stack 分析来说，VINTF 决定“系统认为设备提供了什么 HAL 能力”和“framework 期望设备满足什么接口”。相机服务找不到 provider、HAL 版本不满足、OTA 后能力异常，都可能落在这个边界。

HAL 层失败通常向上表现为设备不可用、能力列表缺失、配置失败、stream 创建失败、buffer error、request timeout 或服务重启。向下看，HAL 可能卡在 vendor library、driver ioctl、firmware 响应、内存分配或硬件中断。向上看，system service 需要把这些失败转成 App 可见错误。分析时应先确认问题发生在接口发现、接口调用、数据传输、硬件执行还是错误回报阶段。

157.7 Linux Kernel 作为进程、内存、驱动、网络和安全基础​

Linux Kernel 是 Android Full Stack 的底层资源管理层。AOSP 的 Kernel overview 说明 Android kernel 基于上游 Linux Long Term Supported kernel，并结合 Android-specific patches 形成 Android Common Kernels；5.10 及以上的 ACK kernel 又与 Generic Kernel Image、vendor modules、Kernel Module Interface 相关。这个版本边界说明 Android 内核既继承 Linux 的通用能力，也为了移动平台、vendor 驱动和系统更新加入特定约束。

在能力路径中，kernel 提供六类基础能力。第一类是进程和线程调度，决定 App、system_server、native service、HAL 进程和 binder thread 何时运行。第二类是内存管理，决定进程地址空间、page cache、匿名内存、共享内存、DMA-BUF 和低内存回收。第三类是文件和设备节点，服务与 HAL 通过设备文件、sysfs、procfs 或专用接口触达 driver。第四类是网络栈，Connectivity、VPN、DNS、socket、radio 相关服务最终依赖内核网络路径。第五类是 driver 和中断，硬件事件、DMA 完成、buffer 可用和错误状态通过驱动进入系统。第六类是安全基础，包括 UID、Linux permission、SELinux policy、capability 和 Binder driver 的访问控制。

Binder driver 是 Android 特有路径中的核心内核支撑。AIDL 文档说明 Binder 调用会经过 binder kernel driver，把调用数据复制到远端进程，由 binder thread 接收后进入 stub。这个内核 driver 同时影响 IPC 延迟、对象引用、transaction buffer、线程等待、死亡通知和调用方身份传递。相机打开这种请求虽然高层是 Framework API，跨进程部分仍依赖 Binder driver 的稳定执行。

SELinux 在 Android 中把进程域、对象类型和操作权限组合成强制访问控制。App sandbox 的 UID 隔离负责基础文件和进程边界，SELinux 进一步约束 system_server、native service、HAL、vendor 进程和设备节点之间的访问。相机路径中，App 不能直接访问 camera device node；Camera service / HAL / vendor 进程在对应 SELinux domain 中按策略访问设备或 binder domain。权限授权成功后，下层 SELinux 仍可能因为策略、label 或 vendor sepolicy 错误拒绝访问。

Kernel 层失败向上表现时经常被包装。Driver 返回 errno、设备超时、中断丢失、DMA buffer 错误、内存分配失败、SELinux denial、Binder transaction failure，都可能被 HAL 和 service 转成统一的 App 错误。排查时要从 App 返回形式反推：如果多个 App 同时失败，关注 service、HAL、driver 或硬件；如果只有某个 App 失败，先关注 UID、permission、lifecycle、AppOps 和组件状态；如果 OTA 或 vendor image 更新后失败，关注 VINTF、HAL 版本、vendor module、KMI 和 sepolicy。

157.8 从 App API 到硬件能力的 Android 标准路径​

从 App API 到硬件能力的标准路径可以写成一组固定判断顺序。这个顺序适用于相机、麦克风、定位、蓝牙、网络、传感器、音频、显示和通知等能力，只是每项能力的 service、HAL、driver 和策略不同。

顺序检查对象相机预览中的判断
1App 身份哪个包名、UID、user、进程和组件发起请求
2API 入口调用哪个 Framework manager，传入哪些参数和 callback
3权限状态manifest、runtime permission、AppOps、sensor privacy 是否允许
4Binder 边界transaction 是否到达服务，caller identity 和 callback binder 是否有效
5服务仲裁camera device 是否存在、是否被占用、前后台和并发策略是否允许
6HAL 边界provider 是否发现，接口版本和 VINTF 是否匹配，stream 配置是否成功
7Kernel / Driver设备节点、SELinux、buffer、调度、中断、DMA、内存是否支撑请求
8返回路径成功 callback、异常、disconnect、error、timeout 分别来自哪个检查点

这张表把 Full Stack 分析从“猜原因”改成“沿责任链定位”。相机打不开时，先确认 App 是否处于前台并持有权限，再看 Framework 调用是否完成参数和 callback 注册，然后看 Binder 是否进入服务。服务层确认设备和资源状态后，再看 HAL provider 与 VINTF。HAL 正常时，继续检查 driver、SELinux、buffer 和硬件状态。返回 App 时，根据异常和 callback 类型判断失败来自哪个阶段。

同一方法可以迁移到定位。定位请求的 App 身份和权限是 ACCESS_FINE_LOCATION / ACCESS_COARSE_LOCATION、前后台定位权限、位置总开关和 AppOps；Framework 入口是 location manager 或平台位置接口；服务层是 location 相关系统服务与 provider 状态；HAL / vendor 方向可能连接 GNSS、Wi-Fi、cell 和 sensor fusion；kernel 和 driver 支撑 GNSS、network、sensor、power 和 wakelock；返回路径是 location callback、provider disabled、permission denial 或 timeout。

同一方法也可以迁移到网络。网络请求从 App socket 或 higher-level API 发起，Framework / libc / netd / ConnectivityService 参与路由、DNS、VPN、网络评分和后台策略，Binder 和 native socket 路径共同工作，kernel 负责 socket、routing、iptables / eBPF、TCP/IP、Wi-Fi 或 cellular driver，modem 和 Wi-Fi 芯片提供硬件连接。App 看到的是连接成功、DNS 失败、timeout、network unavailable 或被后台策略延迟，系统内部对应不同责任层。

标准路径的最终判断是：Android 能力请求总是同时包含“谁在请求”“请求什么能力”“系统是否允许”“资源是否可用”“vendor 接口是否匹配”“底层是否执行成功”“结果如何回到 App”。只要这七个问题被完整回答，一个 App 可见现象就能被放回 Full Stack 责任链中。

最小自检任务​

一个应用在前台 Activity 中调用相机 API 打开后置摄像头。用户已经在权限弹窗中允许相机权限，但应用仍然收到打开失败回调，界面没有预览画面。请沿 Android Full Stack 能力路径写出排查顺序，要求覆盖 App Layer、Framework API、Binder、System Service、HAL、Kernel / Driver / Hardware 和返回路径。

答案要点​

先确认 App Layer：包名、UID、user、前台 Activity 状态、AndroidManifest.xml 中的相机声明、runtime permission、AppOps 和 sensor privacy。权限弹窗允许只能说明用户授权已经通过，还要确认当前 profile、前后台状态和隐私总开关允许使用 camera。

再确认 Framework API：应用是否通过正确的 manager 发起打开请求，camera ID 是否存在，callback / executor / handler 是否有效，预览 Surface 是否已经创建并保持可用。Framework 层负责把公开 API 调用转成系统服务请求，并把同步异常或异步 callback 交回 App。

接着确认 Binder 边界：请求是否作为 transaction 到达 Camera 相关服务，caller UID / PID 是否正确，callback binder 是否仍然存活，App 进程死亡或 Activity 销毁是否触发服务端清理。Binder death 会导致服务释放设备并回调断开或错误。

然后确认 System Service：服务是否识别该 camera device，是否有其他 App 或系统组件占用设备，当前并发策略是否允许打开，前后台策略和隐私指示器是否允许该请求。服务层应把权限拒绝、设备占用、断开、HAL failure 和 timeout 转成 App 可见错误。

继续确认 HAL：camera provider 是否被发现，VINTF 中声明的接口是否与 framework 期望匹配，AIDL / HIDL HAL 版本是否可用，stream 配置和 session 创建是否成功。HAL 层失败常表现为设备不可用、配置失败、provider 崩溃或 request timeout。

最后确认 Kernel / Driver / Hardware：camera driver、设备节点、SELinux label、DMA-BUF、内存分配、中断、sensor / ISP / firmware 是否正常。下层失败会被 HAL 和服务包装后返回到 App，因此要根据 onDisconnected、onError、异常类型和超时位置判断失败阶段。

本章知识点总结​

  • 能力路径：Android 系统能力应沿 App、Framework、Binder、Service、HAL、Kernel、Hardware 和返回路径追踪。
  • App 身份：包名、UID、user、进程、组件和生命周期共同决定请求的系统身份。
  • 沙箱边界：UID sandbox、进程隔离、manifest 声明和 runtime permission 共同形成 App 访问边界。
  • API 入口：Framework manager 把公开 SDK 方法、参数、callback 和异常整理成系统服务请求。
  • 权限检查：权限授权、AppOps、前后台状态、用户设置和隐私开关共同影响能力是否开放。
  • Binder 主干：Binder proxy、transaction、stub、caller identity、thread pool 和 death recipient 构成跨进程控制路径。
  • 服务职责：System service 持有资源状态，执行权限检查、并发仲裁、策略判断和错误返回。
  • HAL 边界：HAL 用标准接口连接 framework 与 vendor implementation，隔离设备差异和厂商实现。
  • VINTF 约束：VINTF 用 manifest 和 compatibility matrix 描述 framework 与 device 的接口匹配关系。
  • 内核基础：Linux kernel 提供调度、内存、文件、网络、driver、SELinux 和 Binder driver 支撑。
  • 返回路径：异常、callback、disconnect、error 和 timeout 分别对应不同层级的检查点。
  • 排查顺序：先看 App 身份和 API 入口，再看 Binder 与服务仲裁，最后看 HAL、driver、硬件和返回语义。