Chapter 183: Android OEM Customization Surface

同一份 Android 应用安装到不同品牌手机上，用户看到的差异可能表现为主题样式、设置入口、通知延迟、后台任务停止、相机能力缺失、系统更新节奏不同。这些现象来自同一个结构事实：OEM 会把 AOSP、Google 组件、芯片厂商实现、系统应用和自有云服务组合成一套面向用户发行的 Android 系统。

本章讨论 Android OEM Customization Surface，也就是厂商把通用 Android 平台改造成具体手机系统时可触达、可替换、可配置、可扩展的系统表面。读完本章后，读者应能追踪一个 App 可见差异来自 UI 资源、framework policy、system service、native daemon、HAL、vendor partition、预装服务、GMS 组件或兼容性边界中的哪一层。

本章的贯穿材料是一款提醒类 App。它需要通知权限、后台定时、网络同步、相机扫码和系统分享入口。在 A 品牌设备上，它的通知稳定送达；在 B 品牌设备上，它需要用户进入“自启动管理”或“后台保护”后才能稳定运行；在 C 品牌设备上，它的扫码相机可用，但某些厂商相机增强能力对第三方 API 不开放。这个例子足够覆盖 OEM 定制的主要表面：可见 UI、系统策略、底层硬件封装、生态服务和兼容性约束。

Android OEM 定制的主结论可以先放在前面：OEM 系统应理解为受 CDD、CTS、VTS、Treble / vendor interface、GMS 授权和硬件适配共同约束的 Android 再发行平台。表层 UI、底层实现和生态服务都在这条兼容性边界内组合。分析 OEM 差异时，稳定顺序是先看 App 可见行为，再定位 framework API 和系统服务，再判断策略来源，最后确认差异是否进入 HAL、vendor、GMS 或 OEM 云服务边界。

183.1 OEM Customization 在 Android 架构中的位置

OEM Customization 在 Android 架构中的位置可以从“谁拥有默认行为”开始判断。AOSP 提供基础 framework、system service、native service、系统应用框架、权限模型、应用生命周期、构建系统和兼容性目标；芯片厂商和设备厂商提供 kernel 配置、driver、firmware、HAL、vendor daemon、硬件调校和板级配置；OEM 再把 UI、设置、启动器、相机、图库、账号、云服务、推送、应用商店和电源策略组织成用户实际接触的系统。

OEM 定制表面指这些层级中允许或实际发生变化的入口。它表现为一组分散入口：资源 overlay 改变 SystemUI 和 Settings 的显示；system app 改变用户入口；framework policy 改变权限、通知、后台、窗口和电源行为；native daemon 连接厂商硬件、日志、诊断和系统服务；HAL 把相机、音频、指纹、显示、传感器等硬件封装给 framework；vendor partition 存放厂商实现与设备相关库；云服务和预装服务补充账号、推送、商店、同步和多设备协同。

贯穿例子中的提醒类 App 在不同品牌设备上出现通知延迟时，第一层观察点是用户可见设置：是否存在“自启动”“后台保护”“锁屏清理”“省电策略”这类入口。第二层观察点是系统策略：JobScheduler、AlarmManager、foreground service、notification channel、FCM 或厂商推送是否被重新排队。第三层观察点是生态服务：设备是否带有 Google Play services，是否额外接入厂商推送 SDK。只有当现象涉及相机、音频、传感器、蓝牙、显示这类硬件能力时，分析才继续下沉到 HAL、driver 和 firmware。

下面的图把 OEM 定制放进 Android 能力路径中。图的边界是“从 App 行为到用户可见结果”，它不展开具体厂商私有实现，只定位定制可能发生的层级。

图中最容易产生误判的是 System App 和 System Service 的关系。Settings 或安全中心只是用户入口，真正改变后台、通知和权限结果的通常是 service policy、系统数据库、调度队列、白名单、应用状态分组或厂商 daemon。UI 能解释用户在哪里点开开关；App 何时被唤醒、何时被回收、何时收到通知，需要继续检查 service policy、调度队列和厂商 daemon。

183.2 AOSP、GMS、Vendor Layer、OEM Services 的组合关系

AOSP 是 Android 系统的公开基础。它提供可构建的开源平台、SDK/NDK API 基础、framework、system service、ART、Binder、基础系统应用和兼容性目标。对 OEM 来说，AOSP 更接近通用平台骨架，距离成品手机系统还需要 SoC 支持包、firmware、driver、HAL、设备树或板级描述、射频和相机调校、区域法规配置、运营商配置、系统应用、升级服务和售后工具。

GMS 是 Google Mobile Services 的集合，包含 Google 应用、API 和服务。Google 的公开说明明确区分了 AOSP 与 GMS：AOSP 提供通用设备级功能，GMS 不属于 AOSP，设备厂商需要通过 Google 授权获得 GMS；Google Play services 则以主应用中的共享服务和轻量客户端库配合，为应用提供位置、账号、FCM、支付、安全等能力，并独立于 OS、OEM 或 App 更新获得自动更新。这个组合关系解释了一个常见现象：同一 APK 在带 GMS 的设备、无 GMS 的国内设备、使用厂商替代服务的设备上，会看到不同的地图、推送、登录、支付和安全检测行为。公开材料可参见 Android GMS overview 和 Google Play services overview。

Vendor Layer 是设备相关实现的集中区。Android 8.0 以后，Treble 把 framework 和 vendor 实现之间的接口稳定性推到系统架构中心。AOSP 文档中对 HAL 的定义是：HAL 提供标准接口，让硬件厂商实现低层设备能力，同时减少对高层 framework 代码的影响；Android 13 起，HIDL 已被标记为 deprecated，新的 HAL 推荐使用 AIDL，旧 HIDL HAL 仍可被支持。这个边界让 OEM 能替换相机、音频、显示、传感器、蓝牙、指纹等硬件实现，同时让 framework 侧通过标准接口调用能力。相关公开材料可参见 HAL overview。

OEM Services 是厂商面向产品体验添加的服务集合。它们可能包括账号、云同步、设备查找、应用商店、主题商店、广告服务、推送服务、系统诊断、游戏模式、电池管家、安全中心、多设备协同和售后通道。这一层经常以 system app、privileged app、native daemon、framework 扩展、provider、后台 service、账号同步适配器或 push channel 的形式存在。对应用开发者而言，OEM Services 的影响通常体现在设备环境差异：某些 intent 被厂商应用接管，某些通知通道需要接入厂商推送，某些后台行为需要用户加入保护列表。

把四者放在一起看，AOSP 负责共同系统语义，GMS 负责 Google 生态 API 和服务，Vendor Layer 负责硬件实现，OEM Services 负责厂商产品体验和生态绑定。提醒类 App 的通知差异通常先落在 GMS / OEM push 与后台策略；扫码相机差异通常落在 Camera framework、Camera HAL 和厂商相机 App 私有能力；系统分享面板或权限设置差异通常落在 system app、framework resource、permission controller 和 Settings 定制。

183.3 System App、Framework Overlay、Native Service、HAL 的定制入口

System App 是 OEM 最容易暴露给用户的定制入口。Launcher、SystemUI、Settings、Camera、Gallery、Files、Phone、Messages、Security Center、Theme Store、App Store、Cloud、Game Center 都可能是 system app 或 privileged app。它们既提供 UI，也可能持有 privileged permission，调用普通第三方应用无法访问的系统 API。提醒类 App 需要用户打开后台保护时，真正展示这个开关的通常是 Settings 或安全中心；这个入口是否存在、名字如何翻译、是否默认启用，都是 OEM system app 的定制结果。

Framework Overlay 负责改变资源值和配置项。Runtime Resource Overlay（RRO）是 Android 官方支持的资源替换机制：一个 overlay package 可以在运行时改变目标 package 的资源值；Android 11 及以上推荐用资源映射文件定义 overlay；Android 10 及以下存在按资源名匹配的历史规则。RRO 能改变字符串、布尔配置、颜色、尺寸和某些 feature 开关，适合区域差异、设备差异和 UI 配置。它能改变资源解析结果，代码逻辑仍由目标包和系统实现决定；因此它适合解释“设置项文案、默认配置、布局差异”。后台任务被回收这类现象需要继续检查 system service、power policy 和厂商 daemon。公开材料可参见 Runtime Resource Overlay。

Native Service 是 OEM 定制深入系统行为的重要入口。它可能运行在 /system/bin、/vendor/bin、/odm/bin 或厂商分区相关路径中，通过 Binder、socket、netlink、sysfs、property、HAL 或私有协议和 system service、driver、firmware 交互。电池健康、热策略、相机调校、充电、指纹、传感器校准、日志诊断、射频配置、游戏性能模式都可能依赖 native daemon。提醒类 App 的后台行为如果被“电池管家”改写，用户看到的是设置开关，执行层可能是 framework service 与厂商 daemon 共同维护的应用状态。

HAL 是硬件能力定制的标准入口。Camera HAL 可以提供流组合能力、metadata、vendor tag、3A 状态、传感器能力和图像处理路径；Audio HAL 可以暴露音频路由、低延迟、回声消除和 codec 能力；Sensors HAL 可以暴露采样频率、批处理和低功耗传感器。OEM 的硬件差异通过 HAL 进入 framework，再被 Camera2、AudioTrack、SensorManager 等 API 映射给 App。第三方扫码只看到 Camera2 可用的 stream、format、metadata 和控制项；厂商相机 App 可能使用额外私有接口、算法库或 system privilege，因此同一摄像头硬件在默认相机和第三方相机中表现不同。

这四类入口的判断顺序可以固定下来：先看用户入口和 system app，再看 overlay 与资源配置，再看 framework service policy，再看 native daemon 和 HAL。当现象只影响文案、布局、默认开关时，overlay 是优先候选；当现象影响唤醒、权限、通知和进程状态时，system service policy 是优先候选；当现象影响相机、音频、显示、传感器的真实能力时，HAL 与 vendor 实现进入分析主路径。

183.4 UI Customization 与 System Policy Customization 的边界

UI Customization 改变用户看见和操作系统的方式。它包括主题、图标、字体、启动器、状态栏、控制中心、通知样式、设置页布局、权限弹窗文案、相机界面和系统动效。它的输入通常是资源、配置、system app 代码和区域包；输出是可见界面和交互入口。UI 定制能降低用户寻找设置的成本，也会改变用户对系统能力的理解，例如把“后台限制”包装成“省电优化”或“应用保护”。

System Policy Customization 改变系统对 App 的实际处理结果。它包括后台进程分组、启动限制、JobScheduler 配额、alarm 延迟、网络后台策略、通知优先级、电源白名单、权限默认值、相机并发限制、悬浮窗限制、安装限制和 OTA 策略。它的输入是 App 状态、权限、用户设置、电量、温度、网络、屏幕状态、厂商策略和生态服务状态；输出是 App 是否被唤醒、是否被调度、是否被允许访问资源、是否收到回调。

提醒类 App 的例子可以把边界讲清楚。用户在 B 品牌设备上看到“允许自启动”开关，这属于 UI 和 system app 定制；打开开关后，系统把该 App 放入白名单、放宽后台启动或 alarm 限制，这属于 system policy 定制；开关状态被持久化到系统数据库、property 或厂商服务状态中，这属于 service / daemon 数据边界；下一次设备锁屏后，JobScheduler 或厂商策略决定任务是否排队，这才是用户最终感受到的行为差异。

观察对象	更可能属于 UI 定制	更可能属于 System Policy 定制	App 可见结果
设置页位置、开关名称、权限说明	Settings、PermissionController、资源 overlay	权限默认状态和撤销规则	用户能否找到入口
通知样式、分组、横幅样式	SystemUI、通知模板、主题资源	通知权限、通道优先级、后台投递策略	通知是否显示、何时显示
后台保护入口	安全中心、电池设置、开关文案	进程冻结、alarm 配额、job 配额、网络限制	定时任务是否稳定
相机界面效果	默认 Camera App UI、图库入口	Camera service、Camera HAL、并发策略、vendor tag	第三方 API 能否获得能力
系统更新提示	Updater App、设置页	A/B 分区、OTA 策略、兼容性和运营商配置	版本何时到达设备

这张表的使用方式是从结果反推层级。用户只看到“通知晚了十分钟”，开发者需要继续判断通知是否已经到达设备、是否被系统队列延迟、是否被后台网络限制、是否缺少 Google Play services、是否需要厂商推送、是否被用户关闭通知通道。UI 是证据之一，policy 才决定最终运行结果。

183.5 OEM 定制对权限、后台、通知、相机、更新的影响

权限差异通常发生在 PermissionController、Settings、framework service 和厂商安全中心之间。Android 的运行时权限模型提供基础授权语义，OEM 可以改变权限说明、设置入口、默认提示组合、权限管理页面和某些特殊权限的用户路径。提醒类 App 请求通知、相机和精确提醒时，系统是否弹窗、用户在哪里撤销、撤销后回调表现如何，属于 App 可见层；真正执行拒绝的位置在 framework API、system service 或底层资源访问点。

后台差异是 OEM 定制中最常影响开发者的部分。AOSP 提供 Doze、App Standby、foreground service、JobScheduler、AlarmManager、WorkManager 等基础策略；OEM 可能再叠加自启动管理、清理策略、锁屏冻结、耗电排行、游戏模式、后台网络限制和厂商白名单。提醒类 App 的稳定性取决于三个条件：它是否使用符合 Android 版本要求的后台 API；用户是否允许通知和后台运行；OEM 策略是否把它归入受限分组。只查看代码是否调用 WorkManager，无法解释真实设备上的所有执行差异。

通知差异同时受 Android 版本权限、通知通道、系统 UI、推送通道和后台策略影响。带 GMS 的设备上，FCM 可能通过 Google Play services 的后台服务送达；无 GMS 或区域服务不同的设备上，厂商推送通道可能成为主要路径；系统仍会根据通知权限、通道优先级、勿扰模式、电池策略和锁屏策略决定展示结果。开发者看到“推送丢失”时，需要把链路拆成服务器已发送、设备网络可达、push service 已接收、App 进程被唤醒、通知 API 调用成功、SystemUI 展示成功这几个阶段。

相机差异来自硬件、HAL、framework、默认相机 App 和算法库共同作用。第三方 App 通过 Camera2 或 CameraX 看到的是 framework 暴露的能力集合，包括 lens facing、stream combination、format、resolution、capability level、metadata 和控制项。OEM 默认相机可能通过私有权限、私有库、vendor tag 或系统签名能力获得额外功能，例如夜景、多帧融合、特定镜头切换、超级防抖、厂商人像算法。扫码 App 只需要稳定预览、对焦和曝光，因此它应根据公开 API 查询能力并设置降级路径；它不应假设默认相机可见的全部效果都能通过第三方 API 获得。

更新差异来自系统镜像、vendor 分区、GMS 组件、Mainline 模块、运营商配置和 OEM OTA 节奏。Google Play services 可以在带 GMS 的设备上独立更新；部分 Android 模块可通过 Mainline 更新；完整系统版本、vendor 实现、相机调校和 kernel 仍依赖设备厂商的 OTA。用户看到“同为 Android 15，行为仍不同”时，原因往往是安全补丁级别、GMS 版本、Mainline 模块版本、vendor image、OEM policy 和系统应用版本共同不同。

对开发者来说，OEM 影响可以压缩成一个排查顺序：先记录 Android 版本、厂商系统版本、GMS / Play services 状态和权限状态；再区分问题发生在权限、后台、通知、相机或更新；接着用公开 API 查询当前能力；最后把失败结果归入用户设置、system policy、生态服务、HAL 能力或版本差异。这个顺序比按品牌经验猜测更稳定。

183.6 Compatibility、CTS、VTS 与厂商自由度边界

Android 兼容性体系给 OEM 自由度设置了外边界。Android 官方兼容性概览说明，兼容设备必须遵守 Compatibility Definition Document（CDD）并通过 Compatibility Test Suite（CTS）；兼容设备才有资格进入 Android 生态，包括可能获得 Google Play Store、GMS 应用套件和 Android trademark 的授权。CDD 定义设备在某个 Android 版本上需要满足的软件和硬件要求；CTS 用测试集验证应用兼容性和 API 行为；不同 Android 版本有各自对应的 CDD、CTS 和源码分支。公开材料可参见 Android Compatibility program overview。

CTS 主要保护第三方应用面对的公共 Android 语义。它要求设备在 SDK API、权限、基础硬件特性、媒体、图形、输入、存储和行为约束上达到兼容目标。它并不消除所有设备差异，因为硬件能力可以不同，feature flag 可以不同，区域服务可以不同，OEM system app 和系统策略仍有空间。提醒类 App 在兼容设备上可以依赖公开 API 的基础语义，但仍需要查询 PackageManager feature、notification permission、exact alarm 状态、camera characteristics、battery optimization 状态和 Google Play services 可用性。

VTS 主要约束 vendor 实现和接口边界。Treble 之后，framework 与 vendor 分区之间通过稳定接口通信，VTS 检查 HAL、VNDK、vendor interface 和相关依赖。AOSP VNDK 文档描述了 framework 进程、vendor 进程、HIDL / hardware binder 之间的隔离目标，并说明 VTS 会检查 ro.vndk.version 等 vendor 相关属性。这个边界使 OEM 能在 vendor 层实现硬件能力，同时把 framework 更新和 vendor 更新之间的耦合控制在可测试范围内。公开材料可参见 VNDK overview。

GMS 认证进一步影响设备进入 Google 生态的方式。AOSP 可被任何人使用，但带 Google Play Store、Google Play services 和一组 Google 应用的商业设备需要满足 Google 授权和兼容要求。对应用来说，这意味着“Android 设备”这一称呼不足以判断生态 API 可用性。更稳定的判断是：设备是否兼容某个 Android 版本，是否带 GMS，Google Play services 版本是否满足 SDK 要求，目标区域是否提供对应 GMS 应用或服务。

厂商自由度因此呈现为“受测接口以内保持兼容，产品体验和硬件实现保留差异”。OEM 可以做主题、系统应用、相机算法、电源策略、后台管理、云服务和应用商店；它需要保持公共 SDK/NDK API、权限模型、应用安装、基础 Intent、核心硬件声明和 vendor interface 在兼容性边界内运行。对读者来说，CTS / VTS 应落到两个具体问题：这个差异是否破坏公共应用兼容性；这个差异是否越过 framework 与 vendor 的稳定接口边界。

183.7 Android OEM System 作为 AOSP 基础上的平台发行版

一个 Android OEM System 可以理解为基于 AOSP 的平台发行版。它包含 AOSP 基础、设备硬件实现、厂商系统服务、系统应用、区域配置、生态服务、更新通道和兼容性承诺。这个理解能解释为什么不同品牌设备都运行 Android 应用，同时又在后台、通知、相机、设置、云服务和更新节奏上表现不同。

“发行版”这个视角需要保留移动设备的系统边界。移动设备的发行版受硬件封装、签名、Verified Boot、分区布局、商店分发、GMS 授权、运营商配置、隐私权限、电源策略和传感器能力共同约束。OEM 的发行动作会把硬件、系统服务、生态服务和用户体验打包成一个受兼容性测试约束的产品系统。

提醒类 App 的完整判断路径可以作为本章收束。它在某设备上通知延迟时，先确认 Android 版本、OEM 系统版本、GMS / 厂商推送状态和通知权限；再确认 App 使用的后台 API 是否符合版本要求；接着检查系统是否存在后台保护、自启动、锁屏清理、省电模式；然后判断延迟发生在 push service、App 唤醒、Job 调度、notification posting 还是 SystemUI 展示；如果问题转到相机扫码，再查询 Camera characteristics、可用 format、对焦模式和 torch 能力；最后把结论归入 UI 入口、system policy、生态服务、HAL 能力或版本更新差异。

这个路径也给跨设备测试提供方法。测试矩阵应按层级设计：一组设备带 GMS，一组设备使用厂商服务；一组设备同 Android 大版本不同 OEM，一组设备同 OEM 不同系统版本；每台设备记录电池优化、通知权限、后台设置、相机能力、Play services 或厂商推送版本。这样得到的结论会指向“某类能力在某个定制表面上发生差异”，减少品牌评价式判断。

本章最终建立的理解是：Android OEM 定制表面是一张跨 UI、framework、system service、native daemon、HAL、vendor partition、GMS、OEM service 和兼容性测试的责任图。分析 OEM 系统时，先从 App 可见行为进入，再沿着系统路径定位责任主体，最后用 CTS / VTS / GMS / vendor interface 判断自由度边界。

最小自检任务

一款聊天 App 在三台 Android 设备上表现不同：设备 A 带 Google Play services，消息通知稳定；设备 B 无 GMS，需要接入厂商推送后通知才稳定；设备 C 带 GMS，但锁屏后后台任务经常延迟，用户需要在安全中心开启“后台保护”。请分析这三个现象分别落在哪些 OEM 定制表面，并写出排查顺序、责任主体、资源边界、策略判断和用户可见结果。

答案要点

排查顺序应从 App 可见行为开始。先记录 Android 版本、OEM 系统版本、GMS / Play services 状态、厂商推送状态、通知权限、通知通道、后台电池设置和网络状态；再把问题拆成 push service 到达、App 进程唤醒、后台任务调度、通知 API 调用、SystemUI 展示几个阶段；最后把差异归入生态服务、system policy 或 UI 设置入口。

设备 A 的主要责任主体是 Google Play services、Android notification framework、SystemUI 和 App 自身通知代码。它带 GMS，FCM 等 Google 生态能力可用；如果通知稳定，说明生态服务、后台唤醒、通知权限和展示链路在该场景下闭合。资源边界是 Google Play services 提供的后台服务和 framework notification service，用户可见结果是消息按预期展示。

设备 B 的主要责任主体是 OEM push service、厂商云服务、系统白名单和 App 接入的厂商 SDK。无 GMS 使 Google Play services 路径不可用，厂商推送成为稳定送达的主要路径。资源边界从 Google 生态服务切换到 OEM service；策略判断重点是厂商 push 是否被系统允许常驻或唤醒；用户可见结果是接入厂商推送后消息送达率上升。

设备 C 的主要责任主体是 OEM 安全中心、power policy、background policy、JobScheduler / AlarmManager 调度和通知展示链路。它带 GMS，所以生态服务优先级低于后台策略；锁屏后延迟说明后台策略和省电策略需要优先检查。资源边界是应用后台执行预算和系统唤醒预算；策略判断重点是该 App 是否进入受限分组、是否获得后台保护；用户可见结果是打开保护开关后通知延迟降低。

最终结论应保持分层：GMS 状态解释生态 API 和推送通道，厂商推送解释无 GMS 设备的消息通道，安全中心入口解释用户设置位置，power / background policy 解释锁屏后的真实调度结果。CTS / CDD 保障公共 Android 基础兼容，OEM 后台策略和生态服务仍会保留设备差异。

本章知识点总结

• 定制表面：Android OEM 定制表面是厂商在 UI、framework、system service、native daemon、HAL、vendor partition、系统应用和云服务中改变系统行为的入口集合。
• AOSP 基础：AOSP 提供 Android 共同系统骨架，成品设备还需要 vendor 实现、系统应用、区域配置、生态服务和更新通道。
• GMS 边界：GMS 属于 Google 授权服务集合，Google Play services 通过设备端共享服务和轻量客户端库影响位置、账号、推送、安全等能力。
• Vendor Layer：Vendor Layer 承载硬件相关实现，HAL 和 vendor interface 把设备差异封装到 framework 可调用的边界内。
• System App：System app 负责用户入口和部分 privileged 行为，后台保护、安全中心、相机、主题、商店和云服务常通过这一层呈现。
• Framework Overlay：RRO 通过资源替换改变配置和 UI 表达，适合解释文案、资源、默认配置和设备差异。
• Native Service：Native daemon 连接系统服务、vendor 实现、driver 和 firmware，常见于电源、热、相机、传感器、诊断和厂商策略。
• HAL 定制：HAL 决定硬件能力如何进入 framework，相机、音频、显示、传感器等差异需要沿 HAL 和 vendor 实现分析。
• UI 边界：UI customization 解释用户在哪里看到和操作设置，system policy customization 决定 App 是否被调度、唤醒、授权或展示。
• 后台差异：后台行为受 Android 基础策略、OEM 电源策略、用户设置、推送通道和白名单共同影响。
• 通知差异：通知送达需要拆成服务端发送、设备接收、进程唤醒、通知发布和 SystemUI 展示，GMS 与 OEM push 都可能改变链路。
• 相机差异：第三方 App 看到的是公开 Camera API 暴露能力，默认相机可能使用私有权限、vendor tag、算法库或系统签名能力。
• 兼容性边界：CDD、CTS 和 VTS 约束公共 API、设备能力声明和 vendor interface，厂商仍保留产品体验和硬件实现空间。
• 发行版视角：Android OEM System 是基于 AOSP 的移动平台发行版，分析时应从 App 可见行为回溯到系统路径和责任主体。