Chapter 190: Technical Evaluation of Android OEM Systems

评估 Android OEM 系统，需要把一台手机看成平台工程产品：它在 AOSP 基础上加入厂商服务、硬件适配、算法管线、电源策略、权限中心、更新链路和生态服务，然后把这些能力包装成用户每天可见的稳定性、流畅度、续航、影像、隐私和生命周期。读完本章，读者应能定位一个 OEM 系统的强弱来自哪个系统边界，并能用同一套维度比较不同厂商系统。

本章的贯穿材料是一台主力机的一天：早上 IM 消息需要准时送达，出门地图持续导航，通勤时音乐保持播放，中午调用相机拍照和短视频，晚上玩游戏或长时间视频录制，夜间收到安全补丁或系统更新提示。这个材料覆盖后台、权限、影像、图形、电源、更新和生态服务，也能把 App 可见现象连接到 framework、system service、OEM service、HAL、kernel、driver 和硬件状态。

评估结论应从行为证据推回责任边界。通知延迟可能来自后台进程限制、push 通道、网络省电或厂商白名单；相机第三方效果弱可能来自 Camera2 能力暴露、Camera Extensions 支持、厂商算法闭源或热降级；系统流畅度波动可能来自调度、合成、刷新率切换、触控采样、内存回收或后台清理。用户看到的是一个结果，工程分析要把结果拆回路径。

本章使用的公开资料边界以 Android Developers 与 AOSP 官方文档为准。Android 官方的后台任务文档说明后台任务需要按场景选择异步工作、任务调度或前台服务；运行时权限文档说明 Android 6.0 之后危险权限需要在运行时请求；AOSP 的 VINTF 文档说明设备 manifest、framework compatibility matrix 和 OTA 兼容性校验；AOSP 的 Mainline 文档说明部分模块可通过 APEX 或 APK 形式更新。OEM 私有策略和厂商算法通常无法从公开材料完整还原，本章用可观察行为、公开 API 表面和版本承诺建立技术判断。

190.1 OEM 系统技术评估维度

OEM 系统技术评估的主问题是：厂商在 AOSP 之上增加了哪些平台能力，又在哪些边界引入了额外限制、额外服务和长期维护成本。AOSP 提供 Android framework、核心 system service、权限模型、HAL 接口、更新基础设施和兼容性框架；OEM 系统会加入 launcher、系统 UI、权限中心、后台管控、推送服务、相机算法、游戏调度、电源策略、云服务、设备互联和地区化组件。评估时应把这些改动放回用户可见行为，而非停留在 UI 风格或功能数量。

七类评估维度可以按责任链组织：后台策略回答任务能否持续执行；权限策略回答敏感能力是否透明可控；影像系统回答硬件能力是否通过 HAL、framework 和第三方 API 稳定释放；图形与流畅度回答触控、动画、合成、刷新率和调度是否形成稳定帧；电源与温控回答持续负载下系统如何分配功耗预算；更新维护回答设备在发布后能获得多久的安全和系统修复；生态服务回答厂商账号、push、云同步、设备互联和区域服务是否增强平台能力。

下面的路径图用于把每个评估维度映射到系统边界。图中的失败与降级并非独立层级，它可能发生在权限检查、后台策略、资源调度、HAL 调用、driver 响应或硬件热状态任一位置。

这张图的核心作用是固定判断顺序。先看 App 请求的能力类型，再看它进入哪个 framework API 和 system service；随后看 OEM 是否插入额外服务、白名单、风险控制、游戏模式、影像算法或电源策略；最后观察请求是否到达 HAL、kernel、driver 和硬件，以及返回到用户侧的结果是什么。这样评估才能从“感觉流畅”“续航好”“杀后台重”这类模糊印象，转成可定位的系统判断。

一个完整评估表应包含七个维度、可观察场景、系统责任主体和失败表现。后台策略看 IM、地图、音乐、健康和 IoT；权限策略看相机、麦克风、定位、蓝牙、照片、通知和悬浮窗；影像系统看默认相机、第三方相机、视频录制、HDR、夜景、前后摄切换和防抖；图形流畅度看系统 UI、列表滚动、输入延迟、游戏帧率、刷新率切换和热状态；电源温控看长任务、录像、上传、游戏、低电量和充电；更新维护看安全补丁、系统版本、Mainline、驱动和 OTA 回滚；生态服务看 push、云同步、账号、跨设备、查找设备和区域服务。

评估维度之间存在依赖关系。后台策略过紧会提高待机续航，却会降低通知送达和健康数据连续性；影像算法激进会提升默认相机观感，却可能提高功耗和热压力；高刷新率动画会提高流畅感，却需要调度、合成、GPU、display 和电源策略协同；长期更新承诺需要 Treble、VINTF、kernel、driver、firmware、认证和运营商发布链共同支撑。一个 OEM 系统的质量来自这些取舍的稳定性。

本章采用的综合判断顺序是：先选可重复场景，再记录 App 可见结果，然后定位 framework 与系统服务入口，接着识别 OEM 插入的策略层，最后把结果归因到权限、后台、影像、图形、电源、更新或生态服务。单次体验只能提供线索，跨版本、跨温度、跨网络、跨电量状态的重复观察才适合形成评价。

190.2 后台策略：稳定性、通知送达、任务调度

后台策略评估的是 OEM 系统在前台体验、续航、公平性和消息可靠性之间的调度能力。Android 官方将后台工作拆成异步工作、任务调度和前台服务等类别，系统会对后台 App 施加限制，开发者需要按任务属性选择合适 API。OEM 系统在此基础上常加入自启动管理、后台耗电排行、应用休眠、消息保活、厂商 push、游戏模式和省电模式。这些层级叠加后，用户看到的结果可能是通知延迟、音乐中断、地图停止播报、健康数据断点或 IoT 控制不及时。

评估后台策略应使用同一组场景。IM 场景看息屏后消息是否按网络条件及时到达，通知是否被聚合、延迟或静默；地图场景看后台定位、语音播报、蓝牙连接和网络切换是否连续；音乐场景看播放服务、媒体通知、蓝牙耳机控制和系统清理策略是否协调；健康场景看计步、心率、传感器同步和夜间记录是否完整；IoT 场景看家庭设备控制、后台连接、push 唤醒和低电量状态下的可靠性。

后台策略的责任链可以拆成五层。App 层声明 foreground service、WorkManager、alarm、push SDK 或厂商 SDK；framework 层把任务提交给 JobScheduler、AlarmManager、NotificationManager、ActivityManager 等系统服务；系统服务层根据 App standby bucket、Doze、前台服务类型、通知权限和网络状态做基础限制；OEM 服务层加入自启动、后台冻结、白名单、耗电评分、厂商 push 代理和用户设置；kernel 与驱动层执行 CPU 调度、wakelock、网络唤醒、modem 省电和传感器低功耗采样。

后台评估的关键证据是时间线。记录应用退到后台、息屏、进入省电模式、网络切换、消息产生、push 到达、通知展示和用户点击恢复的时间点。IM 通知慢十分钟，原因可能是 push 通道延迟、网络待机策略、应用被限制、通知权限状态、厂商后台白名单缺失或服务端策略。地图后台断航，原因可能是定位权限降级、前台服务被终止、系统清理、弱网、温控或导航 App 自身策略。工程判断需要把每个时间点放回责任链。

一个后台策略成熟的 OEM 系统会把用户意图、任务类型和资源成本区分清楚。用户正在导航、通话、播放音乐、运动记录或连接 IoT 时，系统应给任务明确的持续执行路径；普通同步、广告拉取、批量上传和低优先级统计则应进入调度窗口。成熟系统还会提供可恢复入口，让用户知道哪个应用被限制、为什么被限制、如何恢复通知或后台运行。缺少可解释入口时，用户只能依赖经验反复开关权限，开发者也难以稳定复现问题。

后台策略的技术评价不能用“杀后台轻或重”一个词完成。高质量系统在待机、低电量、弱网、高温和多任务压力下表现出一致规则：关键任务有可见前台状态，普通任务进入延迟队列，异常耗电有明确提示，用户白名单能稳定生效，厂商 push 与 FCM 或应用自有通道之间的责任边界清楚。对 OEM 来说，后台策略是一套跨 ActivityManager、PowerManager、NotificationManager、Connectivity、厂商服务和内核电源管理的系统工程。

190.3 权限策略：透明度、可控性、过度干预

权限策略评估的是 OEM 系统如何把敏感硬件和敏感数据包装成用户可理解、可授权、可撤销、可审计的能力。Android 运行时权限把危险权限从安装期转到使用期授权，通知、照片、蓝牙、定位、后台定位、相机、麦克风、特殊权限和无障碍服务又有各自的版本边界。OEM 系统会在标准权限模型外加入权限中心、隐私看板、敏感访问提示、剪贴板提示、后台定位提示、风险拦截、应用行为记录和额外弹窗。

评价权限策略的第一步是看透明度。用户应能知道哪个 App 在何时访问了相机、麦克风、定位、蓝牙、通讯录、照片、通知、剪贴板或悬浮窗。透明度来自权限设置页、隐私日志、状态栏指示器、临时授权提示和访问记录。对于相机、麦克风和定位这类用户敏感能力，系统提示应能把访问主体、访问时间和当前授权状态连接起来。只显示一个泛化风险标签，无法支持用户判断具体责任主体。

第二步是看可控性。可控性包含授权粒度、授权时机、撤销入口、一次性授权、仅使用期间授权、后台授权、照片选择器、通知渠道和特殊权限管理。一个成熟 OEM 系统会把标准权限、厂商额外限制和用户设置放在同一条路径上解释。用户关闭后台定位后，导航、运动记录、天气更新和查找设备的表现应有清晰提示；用户拒绝通知后，IM 应提示消息接收风险；用户撤销相机权限后，相机入口应给出恢复路径，而非进入空白错误页。

第三步是看过度干预。OEM 系统可能出于隐私或安全目标加入风险控制，但额外拦截需要有明确边界。典型问题包括同一权限在系统设置、厂商权限中心、应用管控和安全软件中出现多处开关；某些敏感 API 已经授权仍被厂商服务二次拦截；应用行为记录缺少证据细节；系统把后台播放、悬浮窗、辅助功能、通知监听、VPN、短信读取等高风险能力混在同一页。过度干预会让开发者按官方权限流程完成授权后，仍然收到无法解释的失败。

权限策略的系统路径是：App 通过 framework API 请求能力，PermissionController 或相关系统服务检查声明、用户授权、AppOps、特殊权限、后台状态和目标 SDK；OEM 权限中心可能叠加风险规则、地区政策、家长控制、企业策略和安全扫描；能力最终由 system service、HAL 或内容提供者返回结果。用户看到的授权弹窗只是路径中的一个节点，真正的安全边界还包括应用身份、签名、沙箱、AppOps、SELinux、内容 URI 授权、前后台状态和厂商策略。

评估权限策略时，应选三组样本。第一组是普通危险权限，例如相机、麦克风、定位和联系人，观察授权、撤销、再次请求和降级行为。第二组是版本敏感权限，例如通知、附近设备、照片选择、后台定位，观察不同 Android 版本和目标 SDK 的差异。第三组是特殊权限，例如无障碍、悬浮窗、通知监听、VPN、精确闹钟和忽略电池优化，观察 OEM 是否提供清晰风险说明和恢复入口。一个系统的权限质量，体现在用户能否根据提示做出稳定决策，也体现在开发者能否把失败映射到明确的权限或策略节点。

190.4 影像系统：HAL、算法、第三方 App 能力暴露

影像系统评估的是 OEM 如何把相机硬件、ISP、NPU、镜头模组、传感器、厂商算法和 Android Camera API 组合成可用能力。AOSP 的 Camera HAL 定义了 framework 与相机设备实现之间的接口边界，第三方 App 通常通过 Camera2、CameraX、MediaRecorder、MediaCodec 或厂商扩展能力访问相机。OEM 默认相机应用经常拥有更深的算法集成，例如多帧融合、夜景、HDR、人像、超分、肤色、视频防抖和高帧率控制。评估重点在于这些能力是否稳定、是否可预测、是否向第三方 App 合理暴露。

默认相机评估应把结果拆成输入、处理和输出。输入包括镜头、传感器尺寸、对焦能力、曝光策略、帧率、OIS/EIS、麦克风、陀螺仪和环境光；处理包括 ISP、3A、降噪、多帧融合、HDR、夜景、人像分割、色彩映射和视频编码；输出包括预览延迟、快门时延、成片细节、动态范围、肤色、白平衡、视频稳定性、音画同步和热状态。默认相机表现强，可能来自硬件，也可能来自算法、调度、内存带宽和功耗预算。

第三方 App 能力暴露是更能体现平台工程质量的维度。用户在社交软件、视频会议、直播、扫码、文档扫描和短视频 App 中调用相机时，系统给到的并非默认相机完整算法管线。第三方能力取决于 Camera characteristics、stream configuration、logical multi-camera、Camera Extensions、视频编码配置、HDR 支持、图像稳定、焦段切换、预览帧率和热降级策略。一个 OEM 系统如果默认相机强而第三方预览暗、噪点高、焦段少、录制发热快，就说明厂商算法与公开 API 表面之间存在能力落差。

影像系统还要看并发和仲裁。相机通常是强独占资源，视频会议、扫码、拍照、AR、权限弹窗、屏幕录制和后台服务会争用 camera service、buffer、ISP、NPU、编码器和麦克风。成熟系统会在相机被占用、权限被撤销、温度升高、存储不足、低电量、后台切前台和来电打断时给出稳定错误返回。失败表现如果是预览黑屏、App 卡死、录像丢帧、音画不同步或相机服务重启，评估应继续定位到权限、资源仲裁、HAL、driver、media codec 或热管理。

影像评估需要同一套样本动作：默认相机拍普通照片、夜景、HDR、人像、前摄、4K 视频和长时间录像；第三方 App 拍照、扫码、视频会议和短视频录制；高温和低电量下重复相同动作；同时观察启动耗时、预览首帧、快门时延、成片一致性、视频帧率、声音同步和权限提示。该方法能区分硬件规格、默认算法、API 暴露、热策略和 App 适配之间的责任。

厂商私有影像算法的实现细节通常无法通过公开材料确认。工程评价应使用可见结果和公开 API 表面表达结论：默认相机具备哪些模式，第三方 App 可获得哪些 stream 和 extension，录制多长时间触发热降级，切换镜头是否稳定，权限撤销后的错误是否清晰。这样可以把“拍照好看”转成“硬件、HAL、算法、API 暴露和热策略共同输出的系统能力”。

190.5 图形与流畅度：调度、合成、刷新率、触控延迟

图形与流畅度评估的是 OEM 系统能否在交互路径上稳定交付帧。一次滑动从触控控制器产生采样开始，经过 input pipeline、应用主线程和渲染线程、GPU 渲染、SurfaceFlinger 合成、Hardware Composer、display engine、panel 刷新和触控反馈。OEM 会在这条路径中加入触控调参、动画策略、刷新率策略、游戏调度、内存清理、温控降级和系统 UI 动效。用户感受到的“跟手”和“稳帧”，来自这条链路的时间预算。

帧率稳定性需要同时看平均帧率、帧时间分布、卡顿集中位置和热状态。Android 开发者文档中的慢渲染说明把渲染问题归入用户可感知性能指标，工程分析则要继续拆到主线程阻塞、绘制开销、GPU 饱和、buffer 等待、合成压力、内存回收、I/O、Binder 回调和温控降频。OEM 系统的价值在于把前台交互线程、渲染线程、系统 UI、输入和合成放入合适优先级，同时控制后台抢占。

刷新率策略是 OEM 系统差异较大的位置。LTPO、高刷新率、动态刷新率、触控采样率和动画 pacing 需要和应用内容类型配合。列表滚动、游戏、视频播放、电子书、相机预览、Always-On Display 和省电模式都有不同刷新需求。成熟系统会在用户交互时快速提升刷新率，在静态阅读和视频播放中匹配内容帧率，在低电量和高温时给出可预测降级。策略切换迟缓会表现为首段滑动不跟手、动画中途抖动、视频掉帧或游戏帧率震荡。

触控延迟评估要把输入与显示放在同一条时间线上。触控控制器采样、内核输入事件、InputDispatcher、App 事件处理、UI 更新、GPU 提交、合成和屏幕扫描都会贡献延迟。游戏模式常通过提高 CPU/GPU 频率、调整触控采样、降低后台调度干扰和锁定刷新率来改善响应。评估时应区分系统 UI 延迟、普通 App 延迟、WebView 延迟、游戏延迟和外接手柄或蓝牙音频延迟，因为它们经过的服务和驱动路径并不完全相同。

系统 UI 表现是 OEM 图形工程的窗口。状态栏下拉、任务切换、桌面返回、锁屏解锁、相机启动、通知展开和输入法弹出都跨越 system_server、SystemUI、WindowManager、SurfaceFlinger、Launcher、输入法和厂商动画策略。系统 UI 帧稳定，说明系统服务、内存、合成和调度配合较好；系统 UI 频繁卡顿，第三方 App 优化很难完全掩盖底层压力。评估时应在冷启动、长时间使用后、低电量、高温、后台多 App、安装更新后分别观察。

图形评估的结论应落到责任边界：App 代码导致的主线程阻塞归 App；系统 UI 和 launcher 动画掉帧归 OEM framework 与系统组件；合成瓶颈归 layer 数量、透明效果、HWC overlay、GPU composition 和带宽；持续游戏降帧归热管理、GPU 频率、调度、驱动和游戏适配；触控不跟手归输入采样、事件分发、主线程、渲染提交、刷新率切换和 panel。这样的边界划分能让评估从主观体感进入可复盘分析。

190.6 电源与温控：性能释放、降频策略、续航表现

电源与温控评估的是 OEM 系统在有限电池、有限散热和用户体验之间如何分配资源。手机 SoC、display、modem、camera、GPU、NPU、storage、speaker、haptic 和 sensor 都共享功耗预算。短时间性能释放可以依赖频率提升和电流输出，长时间稳定性取决于散热、DVFS、thermal governor、任务迁移、后台收缩、亮度控制、帧率策略和应用场景识别。OEM 系统质量要看持续负载曲线，而非单次跑分峰值。

长任务是评估电源策略的基础样本。大文件下载、视频转码、云相册同步、导航、热点共享、长时间录像、直播推流和游戏都能暴露系统的资源分配。评估时需要记录起始温度、电量、屏幕亮度、网络类型、外壳温度、帧率、任务完成时间、充电状态和系统提示。任务完成快但温度迅速升高，说明系统偏向短时性能；任务慢但温度稳定，说明系统偏向保守续航；任务中途出现降帧、录像规格下降、上传暂停或后台任务延迟，说明系统已经进入降级路径。

温控策略需要看降级顺序。相机长时间录像可能先降低屏幕亮度，再限制帧率或编码参数，最后停止录制；游戏可能先降低 GPU/CPU 频率，再降低刷新率或触控采样；热点共享可能限制 modem 功耗并提高后台任务延迟；充电时可能降低充电功率并限制性能释放。成熟系统会让降级路径与场景相匹配，并给用户可理解提示。没有提示的突然掉帧、相机退出或网络中断，会破坏用户对系统策略的预期。

续航表现要拆成待机、轻负载、混合负载和重负载。待机看后台唤醒、modem 待机、push、传感器和系统服务；轻负载看阅读、聊天、音乐和短视频；混合负载看导航、拍照、社交、支付和消息；重负载看游戏、录像、热点和上传。OEM 系统如果通过极端后台收缩换取待机续航，通知、健康和 IoT 可靠性会下降；如果通过持续高频换取流畅度，温控和电池老化压力会上升。评价需要把续航数字和任务可靠性一起看。

低电量模式是电源策略的集中体现。系统会降低后台执行、网络同步、动画、刷新率、振动、定位精度、亮度和性能释放。评估时应观察用户开启低电量模式后，IM、地图、音乐、相机、支付、闹钟和紧急通信是否仍有明确优先级。优秀的低电量模式会收缩低优先级任务，同时保留用户正在进行的关键任务；失败的低电量模式会让用户无法预测哪些功能会被影响。

电源与温控的结论应采用曲线思维。峰值性能、持续性能、温度平台、降级顺序、用户提示、恢复速度和电池影响共同构成评价。OEM 系统真正的工程能力体现在多子系统协同：PowerManager 识别场景，ActivityManager 管理后台，SurfaceFlinger 和显示策略调节帧，thermal 框架下发限制，kernel 调整频率和调度，modem、camera、GPU、display driver 执行硬件侧降级。用户看到的续航和发热，是这些控制面叠加后的结果。

190.7 更新维护：安全补丁、系统升级、驱动生命周期

更新维护评估的是 OEM 系统在设备售出后的工程寿命。Android 更新链路包含 Google 平台发布、AOSP 代码、Android 安全公告、Mainline 模块、SoC vendor 适配、OEM 系统集成、运营商或地区认证、灰度 OTA、回滚和用户数据保护。一个系统发布时功能丰富，只说明初始集成能力；长期稳定收到安全补丁、系统版本更新、驱动修复和故障回滚，才说明平台维护链条成熟。

安全补丁评估看频率、延迟和覆盖范围。补丁日期本身是用户可见信号，但它只能说明设备声明的安全补丁级别。进一步判断要看厂商是否按月或按季度发布，是否覆盖高危漏洞，是否同步更新 kernel、firmware、media、Bluetooth、Wi-Fi、baseband、WebView、PermissionController、ART、network stack 等组件。AOSP Mainline 将部分系统组件模块化，模块可通过 APEX 或 APK 更新，并支持原子安装和回滚；这提高了部分组件的独立更新能力，但整机 OTA、vendor、kernel 和 firmware 仍需要 OEM 与供应链维护。

系统版本升级评估看 Android 大版本、目标时间、升级后稳定性和功能完整性。Project Treble 与 VINTF 的目标是把 framework 与 vendor 实现通过稳定接口和兼容矩阵连接起来。VINTF 中 device manifest 描述设备能提供什么，framework compatibility matrix 描述 framework 对设备的要求，二者在 OTA 阶段需要匹配。这个机制降低了系统升级时 framework 与 vendor 的耦合，但设备仍受 SoC vendor、driver、firmware、测试认证和 OEM 定制影响。

驱动生命周期是 OEM 更新能力的底层约束。相机、触控、显示、音频、Wi-Fi、蓝牙、baseband、GPU、NPU、storage、充电和安全芯片都依赖驱动与 firmware。SoC vendor 停止维护某一平台后，OEM 可能仍能发布上层系统补丁，但深层 driver、firmware 和 kernel 漏洞修复会变难。评估时应关注芯片平台代际、内核版本、厂商更新承诺、历史补丁兑现情况、相机和通信 bug 修复速度，以及重大漏洞发布后的响应时间。

OTA 质量也属于技术评估。好的 OTA 应该有明确版本说明、下载与安装稳定性、空间检查、低电量保护、失败回滚、首启健康检查、用户数据保护和灰度控制。失败的 OTA 会表现为耗电异常、后台策略重置、权限状态变化、相机质量波动、系统 UI 卡顿、蓝牙或 Wi-Fi 回归问题、应用兼容性下降。评估更新时，发布速度与发布质量需要共同观察。快速推送但频繁回滚，说明测试和灰度不足；稳定但长期缺补丁，说明维护投入不足。

长期支持承诺应转成可验证指标。可观察指标包括官方承诺的系统版本数量和安全补丁年限、实际补丁间隔、重大漏洞响应时间、跨地区推送差异、老设备功能删减、Mainline 模块状态、bootloader 锁状态、恢复环境、回滚策略和售后修复路径。OEM 系统的长期质量，最终体现在设备三年、五年甚至更长时间后，仍能获得安全修复、基础功能稳定和可解释的更新路径。

190.8 从 AOSP 基础到 OEM 平台能力的综合判断

综合判断一个 Android OEM 系统，需要把它看成 AOSP 基础、硬件平台、厂商策略、生态服务和维护链的组合。AOSP 提供共同架构角色，OEM 决定这些角色如何在具体设备上协同。一个系统可能在默认相机、游戏调度和跨设备生态上很强，同时在后台通知、第三方相机暴露和更新频率上较弱；另一个系统可能更接近标准 Android 行为，第三方兼容性较好，但厂商影像算法、生态服务和区域化功能较少。评价应使用场景权重，而非给所有维度相同分数。

综合评估可以采用四层结论。第一层是用户行为结论，例如“IM 通知可靠”“长时间录像降级可预测”“第三方相机能力弱”“系统 UI 高温下掉帧明显”。第二层是系统路径结论，例如“后台策略在息屏后收缩过强”“Camera2 暴露与默认相机算法存在能力差”“刷新率切换和热降级影响交互帧”。第三层是平台工程结论，例如“OEM 服务层和标准 Android API 表面存在额外耦合”“vendor 与 framework 更新边界维护较好”“权限中心可解释性不足”。第四层是购买或选型结论，例如“适合重影像用户”“适合长期安全维护用户”“适合游戏持续负载用户”“适合依赖通知和 IoT 的用户”。

贯穿案例可以收束成一条完整评价链。早上 IM 通知准时，说明 push、后台策略、通知权限和网络待机配合良好；地图导航不断线，说明定位、前台服务、音频、蓝牙和电源策略给了持续任务足够优先级；音乐播放稳定，说明媒体服务和后台清理边界清楚；中午默认相机强但第三方视频会议暗，说明厂商算法与公开 API 暴露存在差距；晚上游戏前十分钟帧率高、二十分钟后稳定降到较低平台，说明热策略偏向可控降级；夜间 OTA 后补丁及时且未破坏权限和后台设置，说明更新维护链较成熟。一个 OEM 系统的画像应从这些证据归纳，而非从单一跑分或单张样张推出。

评估时还要区分官方能力、厂商私有能力和可验证行为。官方 Android 文档能说明后台任务、权限、VINTF、Mainline、Camera HAL 等公共边界；厂商发布会能说明算法、调度、生态服务和更新承诺；用户可验证行为能说明这些能力是否在真实场景中稳定。三类材料的可信度不同，承担的结论也不同。公开文档适合支撑系统角色，厂商资料适合记录承诺和功能范围，行为测试适合判断实际效果。

最终技术评价应输出可迁移判断顺序：先定义用户场景，再拆系统路径；先观察正常结果，再观察低电量、息屏、高温、弱网和 OTA 后的边界；先判断能力能否使用，再判断失败是否可解释；先区分 AOSP 公共机制与 OEM 私有策略，再评价厂商是否把私有能力转化为稳定、可控、可维护的平台能力。这个顺序能把 OEM 系统评价从品牌偏好转成工程分析。

最小自检任务

选择一台 Android OEM 手机，设计一个半天评估流程：上午测试 IM 通知、地图导航和音乐后台播放；中午测试默认相机与第三方 App 相机；晚上测试游戏或 4K 视频录制二十分钟；最后检查系统安全补丁日期、系统更新承诺和 Mainline 相关更新入口。请写出每个场景的 App 可见结果、可能经过的系统服务或 OEM 服务、策略检查点、资源边界和失败表现。

答案要点

合格答案应先把场景分成后台、权限、影像、图形、电源和更新六组，再为每组建立路径。IM 通知路径应覆盖 push、NotificationManager、后台限制、网络待机和 OEM 白名单；地图路径应覆盖定位权限、前台服务、音频播报、网络切换和省电模式；音乐路径应覆盖媒体服务、通知控制、蓝牙和后台清理。相机路径应区分默认相机和第三方 App，说明 Camera API、HAL、厂商算法、视频编码和热降级。游戏或录像路径应说明 CPU/GPU、display、thermal、刷新率、编码器和电源策略。更新路径应覆盖安全补丁、系统版本、Mainline、VINTF、vendor、driver、firmware 和 OTA 回滚。最终结论应把用户可见结果归因到明确责任边界，并说明哪些结论来自公开机制，哪些来自可观察行为。

本章知识点总结

• 评估对象：Android OEM 系统是 AOSP 基础、硬件平台、厂商服务、策略层和维护链共同形成的平台工程产品。
• 七类维度：后台、权限、影像、图形、电源、更新和生态服务共同决定 OEM 系统的技术质量。
• 路径判断：App 可见结果应沿 framework、system service、OEM service、HAL、kernel、driver 和 hardware 逐层定位。
• 后台质量：通知、地图、音乐、健康和 IoT 场景能暴露后台策略在稳定性、续航和用户意图之间的取舍。
• 权限质量：成熟权限策略需要透明访问记录、清晰授权粒度、稳定撤销行为和可恢复入口。
• 影像质量：默认相机表现、第三方能力暴露、HAL 边界、厂商算法和热降级共同决定影像平台能力。
• 流畅质量：触控、调度、渲染、合成、刷新率和温控共同决定系统 UI、普通 App 和游戏的帧稳定性。
• 电源质量：峰值性能、持续性能、温度平台、降级顺序、用户提示和恢复速度共同构成电源温控评价。
• 更新质量：安全补丁、系统升级、Mainline、VINTF、vendor、driver、firmware 和 OTA 回滚共同决定设备工程寿命。
• 材料边界：公开文档支撑系统角色，厂商资料记录承诺和功能范围，可观察行为用于判断真实稳定性。
• 综合结论：OEM 系统评价应从场景证据归纳平台能力，并按用户场景权重形成最终判断。