自 2025 年 3 月 27 日起，我们建议您使用 android-latest-release 而非 aosp-main 构建 AOSP 并为其做出贡献。如需了解详情，请参阅 AOSP 的变更。

应用安全性最佳实践

本部分包含可确保 Android 设备上应用安全性的建议。

源代码审核

进行源代码审核可以发现大量安全问题，包括本文档中指出的问题。Android 强烈建议采用手动和自动两种方式审核源代码。

在进行审核时，应遵循全面的安全指导以确保覆盖率。利用相关的内部或外部标准来确保一致且全面的审核。
对所有使用 Android SDK 的应用代码运行 Linter（例如 Android Studio Liner），并更正发现的所有问题。
使用可以发现内存管理问题（例如，缓冲区溢出和差一错误）的自动工具分析原生代码。
Android 构建系统支持多种 LLVM 排错程序，例如可用于对内存相关问题进行运行时分析的 AddressSanitizer 和 UndefinedBehaviorSanitizer。如果与模糊测试配合使用（在 Android 中通过 libFuzzer 来实现），则排错程序可以发现需要进一步调查的异常极端情况。
经验丰富的安全评估员应审核风险较高的代码，例如加密、付款处理和 PII 处理。

自动测试功能有助于发现大量安全问题，且应定期执行。

在整个开发流程中定期运行最新版 CTS，以便尽早发现问题并缩短解决问题所需的时间。在自动构建流程（每天会构建多次）的连续集成期间，Android 会使用 CTS。
使接口的安全性测试实现自动化，包括使用格式有误的输入内容进行测试（模糊测试）。Android 构建系统支持使用 libFuzzer 来编写模糊测试。

漏洞扫描有助于确保预安装的应用不存在已知的安全漏洞。高级检测可以减少解决这些漏洞以及防止用户和设备面临风险所需的时间和成本。

请务必确保设备上的预安装应用不是潜在有害应用 (PHA)。您要为设备上安装的所有应用的行为负责。在设备发布之前，扫描所有预加载的应用，查找是否有漏洞。

如需详细了解 PHA 以及 Google 如何在 Play 商店中防范它们，请参阅 Google Play 保护机制开发者文档。

为预安装应用授予过多权限可能会带来安全风险。尽可能减少为预安装应用授予的必要权限数量，并确保这些应用无法获取不必要的权限。AndroidManifest.xml 对应用权限进行了说明。

应用签名在保障设备安全方面发挥着重要作用，可用于进行权限检查以及软件更新。在选择为应用签名使用的密钥时，请务必考虑应用是仅在一台设备上使用，还是供多台设备共用。

确保不使用众所周知的密钥（例如 AOSP 开发者密钥）为应用签名。
确保按照与处理敏感密钥方面的业界标准做法一致的方式管理用于为应用签名的密钥，包括使用能够提供有限、可审核访问权限的硬件安全模块 (HSM)。
确保不使用平台密钥为应用签名。这样做可以向应用授予平台签名权限，这些权限非常强大，只能由操作系统的一些组件使用。系统应用应使用特许权限。
确保不使用不同的密钥为软件包名称相同的应用签名。在针对不同的设备开发应用时，经常会出现这种情况，尤其是在使用平台密钥时。如果应用独立于设备，则在多台设备之间使用相同的密钥。如果应用是特定设备专用的，则按设备和密钥创建独一无二的软件包名称。

如果使用得当，Android 沙盒模型可为应用和进程提供额外的安全性。

Root 进程是最常受到提权攻击的目标，因此减少 Root 进程数量有助于降低提权风险。

确保尽可能减少设备上作为 root 代码运行的必要代码的数量。尽可能使用常规 Android 进程而非 root 进程。如果某个进程必须要在设备上作为 root 进程运行，请将该进程记录在 AOSP 功能请求中，以便对其进行公开审核。
应尽可能将 root 代码与不可信数据隔离开来，并尽可能通过进程间通信 (IPC) 访问 root 代码。例如，将 root 功能缩减成可通过 Binder 访问的小型服务，并将这个具有签名权限的服务提供给网络流量处理权限很小或没有此类权限的应用。
Root 进程不得通过网络套接字进行监听。
root 进程不得包含通用运行时（例如 Java 虚拟机）。

一般而言，预安装的应用不应使用共用系统唯一标识符 (UID) 运行。如果某个应用必须使用共用系统 UID 或其他特权服务（例如，电话服务），那么该应用不应导出由用户安装的第三方应用可访问的任何服务、广播接收器或 content provider。

Android 应用沙盒要求应用与系统中的其他进程（包括 root 进程和调试程序）隔离开来。除非应用或用户特意启用了调试功能，否则任何应用都不得违反这一要求。