Chapter 161: Android Native Service Map

Android 的 Native Service 是图形、音频、媒体、相机、传感器等能力的低延迟控制层。读完本章，读者应能把一次视频通话、视频播放、拍照预览或传感器监听放回 Android 的跨层路径中，定位请求经过哪类 native service、进入哪个 HAL、受哪些资源边界约束，以及失败时应先判断哪一层。

本章用一个贯穿场景串联这些服务：视频通话应用启动后，界面需要显示本地预览，麦克风需要持续采集，扬声器需要播放远端音频，摄像头需要输出帧，屏幕需要合成应用窗口和系统栏，传感器可能提供旋转、接近或运动事件。这个场景横跨 SurfaceFlinger、AudioFlinger、MediaCodecService、CameraService 和 SensorService，正好暴露 native service 的共同职责。

Android 官方文档把图形、音频、媒体、相机、传感器都放在系统级架构说明中，例如 Android graphics architecture、Android audio、Android media、Android camera 和 Android sensors。这些文档提供公开边界，本章把它们整理成一张可迁移的 native service map。

Native service 的核心结论是：Java framework 暴露用户和应用可见 API，native service 持有低层资源的会话、队列、缓冲区和实时调度状态，HAL 把服务请求转换成厂商硬件接口，kernel driver 负责设备节点、中断、DMA、内存映射和硬件控制。分析 Android 低层能力时，先确定能力归属，再追踪会话对象和 buffer 流向，最后根据错误表现判断 service、HAL、driver 或硬件边界。

161.1 Native Service 在 Android 架构中的位置

Native Service 指运行在 native 进程中的系统服务或守护进程，它们通常使用 C++ 实现，通过 Binder、AIDL/HIDL、socket、shared memory、file descriptor、native handle 等机制连接 framework、HAL 和 kernel。它们的输入来自 framework 或其它系统进程，输出通常是 buffer、event、handle、callback、状态码或硬件动作。图形合成、音频混音、媒体编解码、相机会话和传感器分发都属于这类路径。

Native service 出现在 Android 架构中的原因和移动设备约束直接相关。音频播放需要稳定的周期性回调，图形合成需要跟 VSync 对齐，相机需要在多个 stream 之间管理 buffer，传感器需要把持续事件分发给多个 client。把这些工作放在 native 层，可以缩短热路径，减少跨语言对象转换，并让服务直接管理 file descriptor、shared memory、fence、native handle 和 HAL 接口。

在视频通话场景中，应用看到的是 Camera2、AudioRecord、AudioTrack、MediaCodec、Surface 和 SensorManager 这些 framework API。系统路径展开后，请求会进入不同 native service：预览 buffer 进入 SurfaceFlinger 的合成路径，麦克风和扬声器进入 AudioFlinger 的采集与播放路径，视频编码进入 MediaCodecService 或相关 codec 进程，相机设备打开进入 CameraService，屏幕旋转或接近检测进入 SensorService。

这张图展示 native service 与周边层级的关系。它的边界是能力路径，不覆盖所有 Android 进程。

图中有两个入口。部分请求先进入 system_server 中的 Java service，再由 Java service 调用 native service；部分请求通过 framework proxy 直接进入 native service。共同点是 native service 会成为低层资源状态的 owner：它知道当前有哪些 client、会话是否有效、buffer 是否可用、HAL 是否已经返回错误、硬件是否被其它 client 占用。

Native service 与 HAL 的边界需要单独固定。Native service 属于 Android system side，负责平台策略、client 生命周期、资源仲裁和跨进程对象管理；HAL 属于 framework 与 vendor 之间的硬件接口边界，负责把标准调用转成具体厂商实现。Project Treble 之后，很多 HAL 通过稳定接口和 VINTF 约束与 system partition 分离。分析问题时，native service 负责解释“系统为什么这样调度或拒绝”，HAL 负责解释“厂商实现如何驱动硬件”。

161.2 SurfaceFlinger 与系统图形合成

SurfaceFlinger 是 Android 的系统图形合成服务。它接收来自应用、系统 UI、视频解码器、相机预览等 producer 的 buffer，把它们组织成 layer，根据 transaction 更新 layer 状态，再结合 Hardware Composer HAL 决定哪些 layer 交给显示硬件合成，哪些 layer 由 GPU 合成，最后把结果送往 display present。Android 图形文档明确指出，BufferQueue 连接图形 buffer 的 producer 和 consumer，SurfaceFlinger 接收多来源 buffer 并合成到显示设备，Hardware Composer HAL 决定如何利用可用硬件完成合成。

视频通话应用中的本地预览通常会把相机输出连接到一个 Surface。从应用角度看，预览只是某个 view 区域显示图像；从系统角度看，camera pipeline 产生 buffer，Surface 或 SurfaceTexture 持有 BufferQueue，SurfaceFlinger 在合成时把该 layer 与应用 UI、状态栏、导航栏和输入法窗口放入同一帧输出。这里的关键对象是 layer、buffer、transaction、fence、composition strategy 和 display timeline。

transaction 表示 layer 状态更新，例如位置、裁剪、透明度、层级、可见性、transform、buffer latch 条件。应用线程或系统 UI 可以提交 transaction，SurfaceFlinger 在合成周期中读取这些状态。应用绘制逻辑已经在 producer 侧完成，SurfaceFlinger 处理提交到系统合成器的 layer 状态与 buffer。应用卡顿、buffer 生产延迟、SurfaceFlinger 合成负载、HWC 能力不足，都会在用户眼中表现为掉帧，但责任边界完全不同。

HWC 是 SurfaceFlinger 进入显示硬件能力的 HAL 边界。HWC 可以把某些 layer 交给 display controller 的 overlay plane，减少 GPU composition 的开销；也可以要求 SurfaceFlinger 先用 GPU 合成出 client target，再交给显示硬件扫描输出。一个简单判断顺序是：先看应用是否按时提交 buffer，再看 SurfaceFlinger 是否按时 latch 和合成，再看 HWC 是否接受 device composition，最后看 display present 是否被硬件时序、fence 或刷新率策略延迟。

SurfaceFlinger 的失败表现通常有三类。第一类是应用 producer 问题，例如 UI 线程阻塞、渲染线程错过 frame deadline、解码器或相机没有按时提交 buffer。第二类是系统合成问题，例如 layer transaction 频繁变化、过多透明层、复杂裁剪或 GPU 合成耗时增加。第三类是 HWC/display 问题，例如 overlay 数量不足、HDR/色彩格式转换开销增加、外接显示或虚拟显示改变输出路径。Native service map 的价值在于把这三类表现分到不同 owner。

视频通话中“预览画面卡住但按钮还能点击”通常指向相机 buffer 或对应 surface producer；“整个界面一起卡住”更可能指向应用主线程、render thread、SurfaceFlinger 合成或设备整体调度压力；“录屏画面正常但外接屏异常”则需要把虚拟显示、HWC 与 display path 放入判断。SurfaceFlinger 提供的是合成控制面，用户看到的是多个 producer 共享一个显示时间线后的结果。

161.3 AudioFlinger 与音频混音、路由、低延迟路径

AudioFlinger 是 Android native audio path 的核心服务之一，负责管理 playback track、record track、mixer thread、record thread、output stream、input stream、effect chain 与 Audio HAL 交互。Android 音频文档把 audio service、HAL 和 kernel driver 分为连续层级：音频服务与 HAL 交互，HAL 定义音频服务调用的标准接口，kernel driver 与实际音频硬件和 HAL 实现交互。

视频通话场景中，远端语音通过解码后写入 AudioTrack，本地麦克风通过 AudioRecord 持续采集。Framework API 创建 track 后，底层会在 AudioFlinger 中建立对应 client track。Playback path 会把多个 track 的 PCM 数据放入 mixer thread，根据音量、格式、采样率、效果和路由策略形成输出 stream。Record path 会从 input stream 读取麦克风数据，再分发给申请录音的 client。

AudioFlinger 和 AudioPolicyService 的职责需要分开。AudioFlinger 更接近数据面，处理 track、buffer、thread、mixer、record 和 HAL stream；AudioPolicyService 更接近策略面，决定声音应该路由到扬声器、听筒、蓝牙、USB 还是其它设备，并处理通话、媒体、通知、闹钟等用途的策略优先级。实际设备上二者协作，用户看到的是音量、路由、延迟、录音权限和播放中断的组合结果。

低延迟音频路径的核心约束是周期。普通 mixer path 可以容忍一定 buffer 深度，因为它需要混合多个 track、做采样率转换和效果处理；fast path 更关注小 buffer、稳定调度和硬件参数匹配。一个 track 进入 fast path 通常需要满足格式、采样率、buffer 大小、线程负载和输出设备条件。条件不满足时，系统会落回普通 mixer path，播放仍可继续，但延迟会增加。

录音路径也有类似边界。麦克风采集需要从 HAL input stream 取得数据，经 record thread 分发到 client。若应用请求高频率、小 buffer 采集，系统需要看设备是否支持对应 input profile、是否有并发录音限制、是否存在语音通话或隐私策略占用。录音失败可能来自权限拒绝、AudioPolicy 路由选择、AudioFlinger track 创建失败、Audio HAL open input 失败或 kernel driver 无法启动硬件采集。

在视频通话中，“能听到远端声音但对方听不到我”通常沿 record path 检查：应用是否获得麦克风权限，AudioRecord 是否成功创建，record thread 是否有数据，Audio HAL input 是否打开，麦克风 route 是否正确，driver 是否产生采样。“对方能听到我但我听不到声音”沿 playback path 检查：AudioTrack 是否写入，mixer 是否处理，AudioPolicy 是否路由到正确设备，Audio HAL output 是否打开，硬件输出是否被静音或被蓝牙/听筒路径接管。

AudioFlinger 的 native service 特征在于它同时管理实时线程和跨进程 client。Binder 负责控制面，shared memory 或 fast message queue 一类机制负责数据传输，HAL 负责打开 input/output stream，kernel driver 负责最终音频硬件。对音频问题下判断时，先分 playback 与 record，再分策略面与数据面，最后进入 HAL 与 driver。

161.4 MediaService / MediaCodecService 与媒体解码编码

Android 媒体路径的核心任务是把容器解析、DRM、编解码、buffer 传递和渲染时序组织成一条可控 pipeline。Android media 文档说明，Stagefright 是 native level 的媒体播放引擎，支持软件 codec、硬件 codec 集成、会话管理、同步渲染、传输控制和 DRM。Android 7.0 的媒体框架加固把多个职责拆到独立进程中，例如 codec、DRM、extractor、camera 和 audio 相关进程，以降低单一 mediaserver 被攻破后的权限面。

视频通话场景中，远端视频需要解码，本地视频可能需要编码。应用通过 MediaCodec 请求某种 codec，例如 H.264 decoder 或 HEVC encoder。Framework 层会查询 codec 能力，创建 codec 实例，配置 input/output format，把 encoded sample、surface input、surface output 或 byte buffer 交给 native 媒体层。MediaCodecService 或相关 codec process 会负责分配 codec、维护 client lifecycle、与硬件 codec 或软件 codec 通信，并把 buffer 按时返回或渲染到 Surface。

MediaService 与 MediaCodecService 的边界需要按历史和设备实现理解。早期 Android 中大量媒体能力集中在 mediaserver。Android 7.0 之后，媒体解析、codec、DRM、camera、audio 等职责进一步拆分，官方文档说明 mediaserver 负责 playback/recording 的驱动和跨组件 buffer 同步，mediacodec 进程承载部分 encoder/decoder，mediaextractor 承载文件解析，mediadrmserver 承载 DRM 相关能力。由于 vendor 依赖，某些 codec 或安全路径可能保留在特定进程中。分析时要以目标 Android 版本和设备实现为边界。

Codec allocation 是媒体路径的第一个判断点。系统需要根据 mime type、profile、level、secure playback、hardware acceleration、低延迟要求、颜色格式、surface input/output、并发实例数量和厂商声明能力选择 codec。应用看到的错误可能只是 configure 或 start 失败；系统内部分解后，可能是 codec list 没有匹配项、硬件 codec 实例达到上限、secure decoder 要求 protected buffer、DRM session 未就绪，或 vendor codec 初始化失败。

Extractor 与 codec 的关系在本地文件播放中更明显。Extractor 负责解析 MP4、MP3、Matroska 等容器，输出 encoded sample；codec 负责把 encoded sample 解码为 PCM 或 video frame。视频通话常用网络传输和实时编码，extractor 角色较弱，但 codec lifecycle 仍然存在：create、configure、start、queue input、dequeue output、flush、stop、release。每个阶段都可能因为格式、buffer ownership、surface 生命周期或硬件资源不足失败。

DRM 和 secure codec 是媒体路径中的安全边界。受保护内容需要 DRM 组件、secure buffer、可能的 TEE 或硬件保护路径配合。普通媒体播放的 buffer 可以跨进程共享；受保护内容的 buffer handle、解密位置、显示输出能力和截图/录屏限制需要遵守安全策略。这里的 native service 既管理媒体会话，又承担权限缩减和进程隔离后的安全责任。

判断媒体问题时，先问三件事：输入是文件 sample、网络 sample、surface input 还是 camera frame；输出是 byte buffer、audio sink、Surface 还是 protected path；codec 是软件、硬件还是 secure codec。随后把错误放进 allocation、configuration、data feeding、output rendering、release 五个阶段。Native service map 能把“播放失败”拆成 extractor、codec、DRM、audio、SurfaceFlinger、HAL 和 driver 的多段责任链。

161.5 CameraService 与 Camera HAL 访问

CameraService 是 Android 相机能力的 native owner。Android camera 文档公开说明，framework 层通过 camera binder interface 跨进程调用 camera service，CameraService 位于 frameworks/av/services/camera/libcameraservice/CameraService.cpp，实际与 HAL 交互；Camera HAL 位于 camera driver 与更高层 Android framework 之间，提供 framework 操作相机硬件所需的标准接口。Android 8.0 之后，Camera HAL 实现使用 HIDL API；较新的平台也在推进 AIDL HAL 形态，设备实现需要以对应版本为准。

视频通话应用打开摄像头时，Framework 的 CameraManager、CameraDevice 和 CameraCaptureSession 会把设备 ID、stream 配置、Surface target、capture request、callback 等信息传到 CameraService。CameraService 负责确认调用者身份、权限状态、摄像头是否存在、设备是否被占用、client priority 是否允许抢占、当前 thermal 或 privacy 状态是否允许继续，然后创建 client、session 和 stream。

Camera HAL 的关键对象是 provider、device、session、stream、request、result 和 buffer。Provider 用来枚举相机设备和状态；device 表示某个相机硬件；session 表示一次打开后的活动连接；stream 表示预览、拍照、录像、分析等输出或输入通道；capture request 携带曝光、对焦、白平衡、目标 surface、帧号等 metadata；capture result 返回实际结果、时间戳、状态和 buffer。CameraService 的职责是组织这些对象并对 app 暴露稳定语义。

Resource arbitration 是 CameraService 中最容易影响用户体验的部分。移动设备可能有前后摄、多摄组合、超广角、长焦、深度相机和逻辑相机，同一时间还可能有系统相机、二维码扫描、视频通话、第三方拍照应用或手电筒请求。CameraService 需要决定谁能打开设备、谁被断开、哪些 stream 组合可用、哪些 request 需要拒绝。用户看到的是“相机被占用”“无法连接相机”“预览黑屏”“切换摄像头失败”等结果。

Session 与 stream configuration 是相机路径的稳定边界。应用配置预览 Surface、录像 Surface、ImageReader Surface 后，CameraService 会把 stream 组合提交到 HAL。HAL 根据 sensor、ISP、内存带宽、格式、分辨率、帧率和硬件 pipeline 能力确认是否支持。配置成功后，重复 request 形成预览流，单次 request 形成拍照或特定捕获。配置失败通常说明应用请求组合超出设备声明能力，或者已有 client、thermal、privacy、HAL 状态限制了当前路径。

Camera buffer 通常跨越多个 native service。相机 HAL 产生的帧可能进入预览 Surface，被 SurfaceFlinger 合成；也可能进入 MediaCodec 作为视频编码输入；还可能进入 ImageReader 给应用做分析。每条路径都有独立的 buffer ownership、fence 和回调时序。视频通话中“预览正常但编码卡顿”可能是 MediaCodec input/output 压力；“编码正常但预览黑屏”可能是 Surface 或合成路径；“全部相机输出停止”才更接近 CameraService、HAL、driver 或硬件层问题。

CameraService 的安全边界也很清晰。权限授予发生在 framework 与系统策略层，运行时检查会沿 service path 生效，privacy indicator 和 AppOps 等用户可见机制会反映敏感硬件使用状态。Camera HAL 文档还强调 HAL 与 camera service 之间是安全边界，HAL 需要验证 service 传入的参数，因为 HAL 拥有不同资源访问能力。这个边界提醒我们：service 负责平台策略和会话，HAL 负责硬件接口实现，同时也承担输入验证责任。

161.6 SensorService 与 Sensors HAL 数据流

SensorService 管理 Android 传感器事件的注册、采样、batching、分发和 client 连接。Android sensors 文档说明，设备上的传感器列表由 HAL implementation 报告；传感器常以 wake-up 与 non-wake-up 成对出现；Android sensors 以 sensor event 序列提供数据，每个 event 包含传感器 handle、基于 SystemClock.elapsedRealtimeNanos() 的时间戳和具体数据。

视频通话场景中，传感器可以影响旋转、接近、头部朝向、稳定性或后台功耗。应用通过 SensorManager 请求某类传感器，例如 accelerometer、gyroscope、proximity 或 rotation vector。Framework 层把 listener、sampling period、max report latency 等参数传给 SensorService。SensorService 维护 client connection，把请求合并后配置 Sensors HAL，再把 HAL 上报的事件分发给对应 client。

Sensor event 的核心价值是时间和来源。每个事件带有 sensor handle 和 timestamp，系统可以把它与输入、相机帧、音频采样或渲染时间线进行关联。对于移动 OS，传感器数据很少只是一次函数返回值；它通常是持续流，系统需要处理频率、延迟、功耗、唤醒和多 client 分发。SensorService 因此更像事件 broker 和策略协调者。

Batching 是传感器路径中的功耗控制点。应用可以声明可接受的最大报告延迟，系统据此允许 HAL 或 sensor hub 先缓存事件，再批量唤醒 AP 分发。低延迟交互需要更频繁分发，后台统计或运动检测可以接受更长 batch。这个取舍直接影响功耗与时延。若视频通话需要实时旋转或头部方向，系统会倾向短延迟；若只是后台步数统计，系统可以使用低功耗常驻单元和 batching。

Wake-up sensor 与 non-wake-up sensor 的差异决定休眠状态下的行为。Wake-up sensor 可以在事件到达时唤醒 AP 或让事件在唤醒后及时交付；non-wake-up sensor 通常依赖系统已经处于可处理状态。用户看到“锁屏后某些动作仍能触发”“后台传感器数据延迟到亮屏后才到达”，背后往往是 wake-up 能力、batching 配置、功耗策略和应用后台限制共同作用。

SensorService 的失败定位也要分层。若应用没有收到事件，先看传感器是否存在、权限或隐私开关是否限制、listener 是否注册成功、sampling period 是否合理；再看 SensorService 是否有 client connection、HAL 是否返回事件、batching 是否导致延迟；最后进入 sensor hub、I2C/SPI driver、中断、固件和物理传感器。把“没有事件”直接归因给硬件会漏掉中间的 client、batching 和 wake-up 边界。

161.7 Native Service、HAL、Kernel Driver 的跨层关系

Native service、HAL、kernel driver 和硬件构成 Android 低层能力的四段责任链。Native service 管理 Android system side 的会话、client、队列、权限上下文、跨进程对象和错误返回；HAL 提供 framework 与 vendor implementation 之间的标准硬件接口；kernel driver 通过设备节点、中断、DMA、memory mapping、power state 和 bus protocol 控制设备；硬件提供真实能力和物理状态。

这四段链路可以用同一组问题判断。第一，App 请求的能力是什么：图形合成、播放、录音、解码、编码、拍照、预览、传感器监听。第二，native service owner 是谁：SurfaceFlinger、AudioFlinger、MediaCodecService、CameraService、SensorService 或其它服务。第三，会话对象是什么：layer、track、codec、camera session、sensor connection。第四，buffer 或 event 如何流动：BufferQueue、shared memory、native handle、fence、callback、sensor event。第五，HAL 接口是什么：HWC HAL、Audio HAL、Codec HAL、Camera Provider HAL、Sensors HAL。第六，driver 与硬件负责什么：显示控制器、音频 codec、video accelerator、ISP/sensor、sensor hub 或具体总线设备。

同一个用户现象在不同层级有不同证据。预览黑屏可以来自应用没有提交 Surface、CameraService session 配置失败、Camera HAL stream 创建失败、driver 没有输出帧、SurfaceFlinger 没有合成对应 layer。录音无声可以来自权限拒绝、AudioPolicy 路由错误、AudioFlinger input stream 未启动、Audio HAL input 失败、麦克风硬件故障。传感器无事件可以来自 listener 注册、batching 延迟、HAL 未上报、sensor hub 固件或物理传感器。native service map 的作用是把这些证据放入顺序。

判断低层能力问题时，推荐使用“可见 API → service 会话 → buffer/event → HAL 调用 → driver/hardware”的顺序。可见 API 告诉你用户或应用意图；service 会话告诉你系统是否接受并拥有资源；buffer/event 告诉你数据是否已经流动；HAL 调用告诉你问题是否跨入 vendor 边界；driver/hardware 告诉你是否涉及内核设备状态和物理能力。这个顺序能减少把上层状态错误误判成硬件故障的概率。

跨 native service 的问题需要先找主路径，再看旁路。视频通话卡顿可能主路径是 camera frame 到 codec，再到 network；旁路是 preview layer 到 SurfaceFlinger；音频旁路是 AudioFlinger playback/record；传感器旁路是旋转或接近事件。主路径决定用户最敏感的失败表现，旁路决定现象是否扩散。预览卡但编码正常、编码卡但预览正常、音频正常但画面卡、画面正常但旋转延迟，分别对应不同 native service 的责任边界。

版本边界也要写入判断。Android 7.0 的 media framework hardening 改变了 mediaserver、mediacodec、mediaextractor、mediadrmserver、audioserver、cameraserver 等进程拆分；Android 8.0 之后 Camera HAL 使用 HIDL API，后续平台逐步引入更多 AIDL HAL。具体设备还会受 SoC vendor、OEM 配置、VINTF manifest、HAL version、kernel driver 和固件版本影响。公开文档能固定架构角色，具体设备行为需要结合对应系统版本和厂商实现解释。

本章建立的最终判断是：Android native service 是低层能力的系统控制面。它们靠 Binder 接收请求，靠会话对象管理资源，靠 buffer/event 传递数据，靠 HAL 进入厂商硬件边界，靠 driver 与硬件完成最终动作。面对图形、音频、媒体、相机和传感器问题，先找 native service owner，再追踪会话与数据流，最后进入 HAL 和 driver，这就是 Android native service map 的实际用途。

最小自检任务

一个视频通话应用在 Android 手机上出现如下现象：本地相机预览画面停止更新，远端仍能听到本机麦克风声音，本机也能听到远端声音，界面按钮可以点击，屏幕旋转事件仍然生效。请按本章的 native service map 写出排查路径，说明哪些层级更可能相关，哪些层级当前证据较弱，并给出下一步应观察的 service 会话和 buffer/event 证据。

答案要点

预览画面停止更新但音频双向正常，说明 AudioFlinger playback path 和 record path 仍在工作，Audio HAL 与音频 driver 的相关性较低。界面按钮可以点击，说明应用主线程和输入处理仍有基本响应；屏幕旋转事件仍生效，说明 SensorService 至少仍能分发相关 sensor event。主要路径应放在 camera preview 与 display composition 上。

第一步确认 CameraService 中对应 camera client、session、stream 是否仍然存在，尤其是预览 Surface 对应的 stream 是否持续收到 capture result 和 buffer。若 CameraService 已经断开 client、session 出错或 HAL 返回设备错误，问题更接近 CameraService、Camera HAL、driver 或 sensor 硬件。第二步确认预览 Surface 的 BufferQueue 是否有新 buffer 入队，若 camera request 有 result 但 Surface 没有新 buffer，重点转向 camera buffer 输出和 Surface 连接。

第三步查看 SurfaceFlinger 中对应 layer 是否仍可见、是否 latch 新 buffer、是否参与 composition。若 BufferQueue 有新 buffer 但 SurfaceFlinger 未合成，问题更接近 layer 状态、transaction、fence 或 HWC/display path。若 SurfaceFlinger 正常合成其它 UI 且只有预览 layer 停止，主责任更接近 camera stream 到 Surface 的 producer path。答案的核心判断是：当前证据优先指向 CameraService/Camera HAL 到预览 Surface 的路径，其次才是 SurfaceFlinger layer latch；AudioFlinger 和 SensorService 目前提供的是排除性背景证据。

本章知识点总结

• 服务位置：Native service 位于 framework API 与 HAL/driver 之间，承担低层能力的会话、队列、buffer 和实时状态管理。
• 共同路径：Android 低层能力通常沿 App API、Binder、native service、HAL、kernel driver、hardware 的方向展开。
• 图形合成：SurfaceFlinger 接收多来源 buffer，管理 layer transaction，并与 HWC 协作完成 display present。
• 音频数据面：AudioFlinger 管理 playback track、record track、mixer thread、record thread 和 Audio HAL stream。
• 音频策略面：AudioPolicyService 决定路由和用途优先级，AudioFlinger 负责实际数据处理和 HAL 交互。
• 媒体管线：MediaService 和 MediaCodecService 把 extractor、codec、DRM、buffer transfer 和 client lifecycle 组织成播放或编解码路径。
• 相机会话：CameraService 管理 camera client、session、stream、resource arbitration，并通过 Camera Provider HAL 进入厂商相机实现。
• 传感器事件：SensorService 把传感器注册、batching、wake-up 能力、client connection 和 HAL event 分发放在同一事件流中。
• 资源仲裁：相机、音频、codec 和传感器都需要在多个 client、后台策略、隐私状态和硬件能力之间做资源判断。
• HAL 边界：HAL 是 Android system side 与 vendor hardware implementation 的接口边界，service 负责平台语义，HAL 负责硬件适配。
• 驱动边界：Kernel driver 负责设备节点、中断、DMA、bus protocol、power state 和硬件控制，通常位于问题定位的后段。
• 判断顺序：低层能力故障应先定位 native service owner，再看会话对象和 buffer/event，最后进入 HAL、driver 和硬件。
• 版本边界：媒体进程拆分、Camera HAL 形态和 HAL 稳定接口会随 Android 版本变化，设备行为还受 vendor 与 OEM 实现影响。