Android 侧载之困：安全与用户自由如何取舍

Google 刚刚大幅提高了从 Play 商店之外安装应用的门槛。新流程要求，对于未经 Google Play Protect 验证的侧载应用，必须等待 24 小时，在此期间 APK 会被上传到 Google 服务器进行扫描。从第三方渠道装一个应用，你得等整整一天才能用。安全上的理由很直接：恶意 APK 确实是个实实在在的问题，在侧载普遍的地区尤其如此。开发者和高级用户的反应就不那么买账了。

这次改动正好触及了 Android 从诞生起就存在的一个矛盾：既要让用户自由安装想装的任何应用，又要保护那些不懂风险的人。Android 在这个问题上已经摸索了 18 年，答案也一直在变。

Android 应用安装简史

早期的 Android 基本就是蛮荒西部。任何应用都能从任何来源安装，点一下就行。设置里的“未知来源”是一个全局开关，打开之后，设备上的所有应用都能安装 APK。这种方式简单，把控制权交给了用户，但在安全上简直是一场噩梦。

Android 8（Oreo，2017）改为按来源授权。不再是一个全局开关，每个应用都得单独申请“安装未知应用”权限。你可以允许浏览器安装 APK，同时禁止邮件客户端这么做。这确实是个进步，它把被攻陷应用的破坏范围控制住了。

Android 13 引入了受限设置。侧载应用如果想访问某些敏感 API（比如无障碍服务、通知监听），用户必须再经过几道确认对话框。背后的逻辑是：Play 商店之外的应用没有经过审核，不应该轻易拿到最强大的权限。

现在，24 小时验证期又增加了一层门槛。每一次迭代都让侧载更难，而每一次都有真实的安全数据作为依据。问题在于，这些叠加起来的摩擦是否已经越过了界线，从“保护用户”变成了“逼用户去 Play 商店”。

侧载为什么确实是安全问题

在否定 Google 的顾虑之前，先承认一点：侧载恶意软件是真实存在、规模很大的问题。Google 自己的数据显示，从 Play 商店之外安装的应用包含恶意软件的可能性是 Play 商店应用的 50 倍。在东南亚这类第三方应用商店很流行的市场，恶意软件感染率明显高于以 Play 商店为主的市场。

攻击手法相当有效，也让人沮丧。用户收到一条消息（可能是 WhatsApp、短信或邮件），里面附了个链接，让他下载“银行安全更新”“手机清理工具”或者“免费高级版应用”。他下载 APK，无视安全警告（因为大家早已被训练得习惯无视警告），然后安装。恶意软件再通过诱骗用户授权拿到无障碍服务权限，进而窃取银行凭证、截获短信验证码，或者把设备加密后勒索。

这些攻击谈不上多高明，之所以能得手，是因为社会工程学确实好用，而且大多数用户并不理解随便安装代码的风险模型。Google 的立场是：摩擦，也就是让侧载变慢、变麻烦，是最有效的防御手段，因为它能给用户留出重新考虑的时间，也给 Google 留出扫描 APK 的时间。

开发者为什么感到沮丧

开发者的反对意见并不是针对恶意软件，而是关于控制权、分发，以及把应用送到 Google 生态之外的用户手里时越来越多的阻碍。

测试与开发。开发者在开发过程中经常需要侧载。每次测试构建都要等 24 小时，简直荒唐。Google 的解决办法是豁免通过 ADB（Android Debug Bridge）安装的应用，但并非所有测试流程都用 ADB，QA 团队、内测用户和客户演示通常直接安装 APK。
企业分发。通过 MDM 方案在 Play 商店之外分发内部应用的公司，会面临额外的阻碍。企业级 MDM 可以绕过部分限制，但没有 MDM 基础设施的小型组织就受影响了。
替代应用商店。F-Droid、Amazon Appstore、Samsung Galaxy Store，这些合法的分发渠道在 Google 看来都属于侧载。每多一道限制，它们的用户体验相对 Play 商店就更差一分，而这恰恰是批评者指责 Google 想要的结果。
合规要求。欧盟《数字市场法》（DMA）要求守门人（包括 Google）允许侧载，且不能设置不合理的阻碍。在技术上保留侧载的可能性，同时让它实际上变得更糟，正是 DMA 想要防止的那种“合规作秀”。

权限模型的深层问题

侧载限制只是治标不治本，问题出在 Android 的权限模型上：它要求用户做出超出其能力范围的安全决策。“允许此应用访问你的联系人？”“允许此应用读取你的短信？”“允许此应用使用无障碍服务？”大多数用户并不清楚这些意味着什么，结果要么全部同意，要么全部拒绝。

核心问题在于，权限的设计是围绕能力做的二元选择，而用户考虑的是用途。用户并不想决定某个应用能不能读短信，他们真正想决定的是：这个应用能不能验证我的手机号（合理），还是能不能截获我银行的双重验证码（不合理）。两者需要的却是同一个权限。

<!-- AndroidManifest.xml -->
<!-- Both of these use the same permission: -->
<uses-permission android:name="android.permission.READ_SMS" />
<!-- Use case 1: Auto-fill SMS verification code during signup -->
<!-- Perfectly legitimate, saves the user time -->
<!-- Use case 2: Intercept banking 2FA codes and forward to attacker -->
<!-- Malware, obviously -->
<!-- The permission system can't distinguish between these.
The user is asked to make a security decision that requires
understanding the app's implementation, which they can't see. -->

iOS 的解法是干脆不允许侧载（直到监管压力迫使苹果开放有限的替代方案）。这是一种站得住脚的思路：把决策权从用户手里彻底拿走。但它也有代价：开发者被锁定、App Store 收取“租金”，以及无法运行苹果未批准的软件。

更好的系统可能是什么样

无论是 iOS 的“完全禁止侧载”，还是 Android 的“逐步加码摩擦”，都算不上理想。一个更好的系统需要同时解决几个问题。

与风险匹配的摩擦。一个不申请任何危险权限、且由已知开发者签名的应用，应该能立即安装。而一个申请无障碍服务、短信访问和设备管理员权限的应用，则应接受更严格的审查。现在的系统对一个无害的开源计算器和一个索要一切权限的应用施加的是同样的阻力。
用途绑定的权限。与其广泛授予“读取短信”，不如授予“读取短信以自动填充验证码”这种范围受限的权限，只能在特定 API 场景下使用。Android 已经通过 SMS Retriever API 朝这个方向迈了一步，但大多数权限的范围仍然很宽。
不用干等的透明扫描。上传扫描是合理的，但 24 小时的等待就不合理了，尤其是大多数扫描几分钟就能完成。应该把扫描结果展示给用户：结果干净就让他们立即继续，发现问题再发出提醒。
第一方与第三方商店对等。如果 Play 商店可以即时安装应用，那替代商店也应该能做到，前提是它们实现了同等的安全检查。只有当限制真正是为了安全，而非为了竞争优势时，安全论据才站得住脚。

开发者现在该做什么

不管你怎么看 Google 的做法，现实是侧载的摩擦只会增加，不太可能减少。如果你在 Play 商店之外分发应用，就该提前做好准备。

使用 Play 应用签名计划。通过 Google 计划签名的应用，在侧载验证时可能遇到更少的阻碍，因为 Google 可以用已知密钥验证签名。
开发阶段用 ADB。通过 ADB 安装的应用可以绕过 24 小时等待。确保你的 CI/CD 流水线和测试流程用的是 ADB，而不是直接安装 APK。
考虑渐进式 Web 应用（PWA）。对于不需要深度集成平台功能的应用，PWA 可以完全绕开应用商店和侧载问题。它从浏览器安装、自动更新，安装时也不需要任何特殊权限。
如果你运营替代商店，务必做好扫描。展示出良好安全实践的商店，未来或许能获得豁免或减少摩擦，监管环境正朝这个方向推进。
提前告知用户延迟。如果你的分发依赖侧载，就提前提醒用户要等 24 小时。预期内的延迟，比意料之外的延迟更容易被接受。

Android 的开放性从来就是一个光谱，而不是非黑即白的绝对值。每个版本都让这个光谱略微偏向更多管控，理由是真实的安全担忧，同时也被批评恰好与商业利益高度吻合。24 小时侧载延迟只是这条轨迹上的最新一站，大概也不会是最后一站。你觉得它是合理的保护还是人为制造的麻烦，很大程度上取决于你认为安全与自由之间的平衡应该落在哪里。但从技术角度看，事实很清楚：Android 上无摩擦侧载的日子已经结束了，开发者需要相应地调整分发策略。