国内安卓生态的碎片化治理，Google 无能为力了吗

国内安卓生态的碎片化治理，Google 无能为力了吗

去年 Android 14 正式发布，Google 终于对精确闹钟动刀了。SCHEDULE_EXACT_ALARM 这个权限在 API 34 上不再是普通权限，非系统应用默认拿不到，得换成 USE_EXACT_ALARM 或者老老实实引导用户去系统设置里手动开启。这个消息刚出来时，国内开发者群里一片哀嚎，但哀嚎的点根本不是 Google 改了什么——大家早就习惯了 Android 官方文档和真机行为对不上号。真正让人崩溃的是，当你拿着这个变更去适配时，会发现小米 HyperOS、华为 HarmonyOS、OPPO ColorOS 和 vivo OriginOS 各自搞了一套自己的开关位置和授权逻辑。Google 在 AOSP 里画的那条基准线，传到国内厂商手里，已经被改得面目全非。这时候你难免会问：Google 折腾了这么多年的碎片化治理，在国内到底管用了吗？

SCHEDULE_EXACT_ALARM：一个权限四种活法

AOSP 的权限模型在 Android 14 之后变得愈发复杂。精确闹钟本来是为了对抗后台滥用，但在纯净的 Android 上，这个权限的行为是确定的：没有声明 USE_EXACT_ALARM 的应用调用 setExact() 或 setAlarmClock() 会直接抛 SecurityException，除非你动态申请并引导用户去设置页开启。这套逻辑在 Pixel 上跑得通，代码路径清晰，文档写得明明白白。

可一旦把 APK 装到国内手机上，事情就开始魔幻。小米 HyperOS 在 Android 14 基础上额外加了一层"省电策略"，即便用户给了精确闹钟权限，只要你在后台挂了一会儿，闹钟照样会被系统悄悄地往后漂移。华为的 HarmonyOS 4.x 虽然底层是基于 AOSP 12 或 14，但设置里压根找不到标准的"闹钟和提醒"入口，而是把这个开关塞进了"应用启动管理"里，和自启动、后台活动、悬浮窗权限混在一起。OPPO ColorOS 14 的表现更离谱，部分机型上 canScheduleExactAlarms() 返回 true，但调用设置闹钟时依然静默失败，日志里看不到任何异常，就好像系统根本没收到你的请求。

这种差异不是靠适配代码就能抹平的。你不可能为每个 ROM 都写一套检测逻辑，更不可能在应用里教用户"小米用户请去设置-省电与电池-应用智能省电-找到本应用-取消限制-然后往下拉找到闹钟权限"。这根本就不是开发，这是客服。Google 当年设计权限体系时，假设的是一条统一的代码路径，但国内厂商对 AOSP 的修改深度，已经让 Android 的兼容性承诺变成了笑话。

Project Mainline：一场没有观众的演出

Google 从 Android 10 开始力推 Project Mainline，想把系统组件模块化，通过 Google Play Store 直接更新，绕过厂商那慢吞吞的 OTA 流程。像 MediaProvider、Permission Controller、Networking 组件这些模块，理论上可以在整个 Android 生态里快速迭代，修复安全漏洞和兼容性 bug。这个思路在国际上确实起了作用，Play Store 的更新覆盖率很高，很多 CVE 可以通过 Mainline 模块快速下发。

但在国内，Project Mainline 完全是个真空概念。没有 Google Play，就没有 Mainline 的更新通道。国内厂商拿到 AOSP 代码后，会把这些模块拆开，要么用自己的实现替换，要么干脆冻结在发布时的版本。你在 Pixel 上能通过 APEX 模块拿到的 Permission Controller 更新，在小米手机上可能永远停留在出厂版本。这意味着 Google 在 AOSP 里修的权限漏洞、改的 API 行为，根本到不了国内用户手里。

更讽刺的是，国内厂商反而利用这种"模块自由"来加深自己的生态控制。华为的 HMS Core 本质上就是在填补 GMS 缺失留下的空白，但它不是简单替换，而是连带着把账号体系、推送、地图、应用内支付全部重写了一边。小米的 MIUI 框架、OPPO 的 HyperBoost、vivo 的 Multi-Turbo，这些听起来像营销词汇的东西，底层全是深度定制的系统服务。它们在 AOSP 的接缝处插入自己的代码，Project Mainline 想更新的那些模块，早就被架空了。Google 以为自己在治理碎片化，实际上只是把舞台搭好了，发现台下根本没人。

推送服务的巴别塔

后台推送大概是国内安卓开发最耻辱的篇章。FCM（Firebase Cloud Messaging）在全球范围内几乎是事实标准，低延迟、低功耗、免费。但国内网络环境决定了 FCM 根本连不上，或者连上了也随时会断。于是国内搞出了一套堪称工业奇迹的推送联盟：华为 HMS Push、小米 Push、OPPO Push、vivo Push、魅族 Push，还有曾经短暂存在过的统一推送联盟。

一个应用要想在国内保证推送到达率，必须挨个集成这些 SDK。你的 build.gradle 里会塞进去五六个推送库，每个库都有自己的初始化逻辑、Token 申请机制、回调接口和厂商证书。华为要求你在 AppGallery Connect 后台配置 SHA256 指纹，小米要你在开发者后台上传 icon 和渠道配置，OPPO 和 vivo 还有各自的分类限制和频次管控。更坑的是，这些推送服务在不同手机上的保活策略完全不同。华为对 HMS 推送的保活相对友好，但杀起第三方应用后台毫不手软；小米对自家推送有系统级特权，可如果你的应用没有被用户手动设为"无限制"，你照样收不到透传消息。

统一推送联盟曾经让开发者看到一点曙光，2017 年成立时号称要制定行业标准，由工信部牵头。结果呢？几年过去，联盟官网打不开了，标准文档停更了，连 GitHub 上的 demo 仓库都长满了草。这件事的失败再直白不过：让一群互为竞争对手的厂商放弃自己的推送通道，去用一个公共基础设施，本身就是在挑战商业本能。Google 至少在国际上有 FCM 这个强绑定服务，国内没有任何单一实体有权力和动力去推动真正的统一。推送碎片化不是技术问题，是生态权力的分配问题，Google 就算想管，手里也没牌可打。

后台保活的军备竞赛与开发者的代价

国内厂商对后台的管控已经到了变态的程度，而且每家都有自己的黑话。小米叫"省电策略"和"神隐模式"，华为叫"应用启动管理"和"省电精灵"，OPPO 叫"耗电保护"，vivo 叫"后台高耗电"。这些名字听起来是为了用户续航，实际上造就了一个巨大的技术黑洞。

Android 原生的 Doze 模式和 App Standby 已经够让开发者头疼了，但好歹行为是标准化的：有明确的进入条件、有维护窗口、有白名单机制。国内厂商在此基础上各自叠加了不知道多少层 heuristics。比如华为 EMUI/HarmonyOS 有一个著名的"锁屏清理"机制，只要应用不在用户最近任务列表里，锁屏后几分钟就会被强制停止，AlarmManager 的唤醒会被屏蔽，JobScheduler 的任务会被丢弃，甚至连前台服务都保不住。小米的 HyperOS 则引入了更精细的"省电等级"，默认把绝大多数应用扔进"智能限制"档位，这个档位下你的 WorkManager 任务会被无限延迟，直到用户手动打开应用。

说到 WorkManager，这大概是 Android Jetpack 在国内最名不副实的库之一。Google 设计 WorkManager 时，内部会优先使用 JobScheduler，在 API 23 以下 fall back 到 AlarmManager，如果设备有 Google Play Services，还会尝试使用 GCM Network Manager 来优化调度。这个设计在国际上是优雅的，但在国内，GCM 不存在，JobScheduler 被厂商魔改，AlarmManager 被省电策略阉割。你发起一个 setRequiredNetworkType(CONNECTED) 的周期性任务，指望它在 WiFi 环境下同步数据，结果在华为手机上可能三天都没被执行一次。开发者最后只能各显神通：有的用双进程保活，有的用像素点悬浮窗保活，有的干脆引导用户去设置里手动关闭所有电池优化，把用户体验毁得一干二净。

应用商店与 Target API 的猫鼠游戏

Google Play 从 2023 年开始强制要求新应用 targetSdkVersion 必须达到 33（Android 13），2024 年往 34（Android 14）推。这个政策在国际上确实有效，倒逼开发者跟进最新权限模型和行为变更。但在国内，应用商店分散在华为、小米、OPPO、vivo、应用宝、百度、阿里等各个渠道，每家对 targetSdk 的要求节奏完全不同。

华为应用市场算是跟进较快的，但审查粒度很奇特：有时候会因为你的 targetSdk 不够高而拒审，有时候又对你实际运行时权限处理吹毛求疵。小米的审核则更关注隐私合规和敏感 API 调用，对 targetSdk 的要求相对宽松，导致大量老旧应用仍在以 targetSdk 28 甚至 26 运行。你在 Google Play 上可以通过 targetSdk 大致判断一个应用的维护状态，在国内应用商店里，这个数值完全失真。

更深层的问题是，国内厂商并不真心希望你的应用完全遵循 AOSP 的权限规范。他们希望自己的系统服务成为不可替代的中间层。比如华为强力推 HMS Core，要求接入华为账号、华为支付、华为分析；小米在 MIUI 上搞自己的权限弹窗样式，甚至会在某些场景下拦截系统的标准对话框，替换成 MIUI 风格的自定义弹窗。这些做法的潜台词是：Android 是开源的，但这个手机上跑的是"我们的 Android"。Google 的 targetSdk 政策管不到这些商店，也就管不到国内生态的演进方向。

Android 版本号的幻觉

国内厂商现在学聪明了，新旗舰发布时都会宣传"首批搭载 Android 14"，看起来碎片化在缓解，版本号跟上来了。但这只是幻觉。Android 的版本号只代表了底层 Linux 内核和部分 Framework 的基线，真正影响开发者的是厂商对 Framework 的修改深度。

拿荣耀来说，从华为独立出去之后，MagicOS 的基线代码继承了 EMUI 的大量改动，但又得慢慢剥离华为的账号和服务体系。这导致 MagicOS 8 上出现了大量独有的行为：同样的 Intent 跳转在某些场景下会被 MagicOS 的"应用间跳转拦截"机制拦下，返回一个空的 ActivityResult，日志里不报错，但业务直接断掉。再比如 OPPO ColorOS 14，底层虽然是 Android 14，但通知渠道管理上额外加了一层"智能聚合"，你的通知即便按标准 API 创建了 channel，也会被系统根据内容分类重新折叠，用户根本看不到。

版本号跟上了，可兼容性灾难一点没少。Android 14 引入的前台服务类型限制（要求声明 foregroundServiceType）在 Pixel 上是严格执行的，国内厂商呢？有的直接无视，你的服务不声明类型也能启动；有的干脆禁止非白名单应用启动任何前台服务。这种行为的不一致性，比单纯的版本滞后更让开发者绝望。至少以前 Android 版本低的时候，你知道哪些 API 不能用；现在版本号上去了，你发现