microG 工作原理：签名伪装如何让应用认账

关键前提：签名伪装（signature spoofing）

安卓系统校验组件身份的方式是"包名 + 签名"。谷歌框架的包名是固定的，签名则是谷歌的私钥。microG 做法分两步：

1. 占用同名包：microG Services 使用与 Play Services 相同的包名注册进系统，应用按包名找服务时自然找到它。
2. 伪装签名：系统层面的"签名伪装"功能让 microG 在被询问签名时，报出谷歌的签名而非自己的。没有这一步，很多应用一查签名不符就直接拒绝工作。

这就是为什么 microG 要求 ROM 支持 signature spoofing——这是一项系统级能力，普通官方系统默认不给，也是整个安装流程里最需要提前确认的一环。

装上之后发生了什么

• API 层补齐：应用调用推送、定位、地图等接口时，请求被路由到 microG 实现的对应服务，由它决定是本地处理还是连接谷歌服务器。
• 后台常驻：开启推送后，microG 会维持一条到谷歌推送服务器的长连接，替代每家应用各自的后台轮询。
• 账号可选：不需要谷歌账号的应用可以完全不登录；需要登录的应用（如要同步订阅列表的场景）再走 microG 的账号认证流程。

一张流程图看懂角色

应用（调用谷歌 API）
      │  以为对面是 Play Services
      ▼
系统（包名路由 + 签名伪装）
      │
      ▼
microG Services（开源实现）
      │  按需连接、剥离设备标识
      ▼
谷歌服务器（推送 / 账号 / 验证等）

为什么说它"轻"

官方 Play Services 是一个庞杂的常驻套件，顺带承担大量遥测。microG 只实现被请求的 API，分析与广告类接口刻意不做，后台进程和内存占用都明显更小——这也是很多用户装它的初衷之一。具体能替代什么、替代不了什么，见 能力边界。