Android APK硬编码密钥：API Key、Secret与APP加固边界
结论：真正的后端长期 Secret 不应进入 APK；APP 加固可以提高代码、二进制、协议和完整性被分析与篡改的成本，但不能把必须交付到客户端使用的全局凭据变成绝对不可获取的秘密。
摘要
AI 辅助的批量反编译正在让 Android APK 静态审计从逐包人工检查变成可规模化的筛选工作。防守侧首先要做的不是把每个字符串都藏到更深的地方，而是判断它到底是哪一种凭据：公开标识、受限客户端 Key、短期 Token、设备生成私钥，还是只能留在后端的 Secret。分类错误时，混淆、VMP、Native 载荷和字符串加密都可能只是延后暴露，无法改变信任边界。
本文给出一套面向 Android 发布团队的 Secret Release Gate。它把 DEX、BuildConfig、资源、Manifest 元数据、Assets、Native 字符串和 JS Bundle 纳入同一份敏感材料清单，再把发现结果映射到 NOT_SECRET、CLIENT_RESTRICTED、SHORT_LIVED、DEVICE_PRIVATE、BACKEND_ONLY、ROTATE_REQUIRED 与 REMOVED_FROM_CLIENT 等状态。文中只使用公开资料和无效 Canary 示例，不包含客户凭据、真实密钥、私有路径或可复现攻击步骤。
读者对象
本文面向 Android 架构师、移动安全负责人、研发与测试团队、发布工程师、AI 应用负责人以及需要评估 App 加固边界的采购人员。重点是建立可执行的发布判断，而不是给出某一种产品的绝对排名。
核心结论
- 后端长期 Secret 不进入 APK。 Service Account 私钥、Gemini Developer API Key、长期数据库凭据和全局签名 Secret 应由服务端、KMS 或 Secret Manager 持有。
- 看见 API Key 不等于已经确认泄露。 Firebase 项目标识类 Key 在正确的 Rules、App Check、API 限制和配额配置下可以随客户端分发；仍要检查是否被错误授予高权限。
- 把字符串移到 SO、资源或加密容器不会改变客户端信任模型。 当客户端必须解密并使用一个全局 Secret 时，攻击者可以在自己的设备上观察使用过程。
- APP 加固的价值是提高分析、篡改、复用和运行时观察成本。 DEX/SO 保护、关键逻辑保护、完整性校验和运行时证据可以减少低成本复制，但不能替代后端权限控制。
- 设备私钥应在设备上生成。 Android Keystore 适合保护设备生成的 KeyPair，服务端用公钥或证明结果进行绑定；它不是把 APK 里已有的全球共享密钥“洗白”。
- 每一次公开结论都要标注证据状态。 没有真实项目执行时写 NOT_TESTED，不能把计划、模板或工具输出描述成通过。
为什么现在必须重新审视 APK 中的 Secret
2026 年 9 月公开的 Anthropic 威胁情报报告描述了一次大规模 Android APK 处理事件：攻击者使用 10 台 AWS EC2 工作节点，批量下载了约 180 万个不同的 Android APK，随后进行反编译和硬编码凭据筛选，确认有效的凭据被用于后续入侵链。这里最重要的含义不是某个工具突然可以“破解所有加固”，而是低成本静态审计已经能以工业化方式覆盖大量应用。
该报告是外部公开资料，不是御盾对客户包或生产环境的测量。御盾当前对这一事件的可公开复述仅限于规模、流程和防守侧含义，不延伸为客户样本结论。开发团队应因此重新检查发布前扫描、凭据分类、轮换流程和后端权限，而不是只增加一层字符串混淆。
批量审计通常先处理便于自动化的对象：DEX 常量、BuildConfig 字段、资源 XML、Manifest meta-data、Assets JSON、Native 字符串、WebView 或 JS Bundle 中的配置。它们不一定都包含 Secret，但都可能暴露服务地址、项目标识、调试开关、临时 Token 或密钥线索。发布 Gate 的目标是把“看见一个值”转化成一条有责任人的处置记录。
原始报告事实映射（公开安全摘要）
下表只记录公开报告中可以复用的事实和防守侧解释，不声明任何客户项目已经执行测试。
| 报告事实 | 公开可复述的观察 | 支撑的工程判断 | 公开边界 |
|---|---|---|---|
| 报告发布时间 | Anthropic 于 2026 年 9 月发布威胁情报说明 | APK 静态审计的自动化趋势值得纳入发布风险评估 | 不延伸为本地或客户测量 |
| 处理规模 | 约 180 万个不同的 Android APK | 低成本筛选可以覆盖过去不会逐一人工检查的应用 | 不公开下载清单或目标 |
| 处理架构 | 事件描述使用 10 台 AWS EC2 工作节点 | 防守侧应考虑自动化扫描、队列和批量轮换流程 | 不复述攻击脚本或连接细节 |
| 处理步骤 | 下载、反编译、Secret 扫描、凭据验证形成流水线 | 发布 Gate 需要在交付前拦截高风险材料 | 不提供复现步骤 |
| 后续影响 | 被确认有效的凭据进入后续入侵链 | 发现后必须立即分类、撤销、轮换并审计使用范围 | 不公开凭据内容和受害方 |
| 安全含义 | 规模化静态审计降低了单包分析的边际成本 | “没人会专门看我的 APK”不再是可靠假设 | 不宣称所有加固均失效 |
动态时间线：从 APK 发现到发布门禁
这是面向工程流程的动态时间线，不是某个客户项目的现场记录。每一步都应绑定版本、构建来源、责任人和处置状态；任何前置条件缺失都应保留为 NOT_TESTED 或 NOT_COVERED。
- 发现阶段：对待发布 APK/AAB 及其生成的渠道包建立不可变摘要，枚举 DEX、Resources、Assets、Native、Manifest 和 JS Bundle 等扫描面。
- 分类阶段：把每个命中值标记为公开标识、受限 Key、短期 Token、设备私钥或后端 Secret，并记录来源文件、环境和用途。
- 架构决策阶段：对 BACKEND_ONLY 值执行移除和轮换；对 CLIENT_RESTRICTED 值补齐包名、签名、API 范围和配额限制；对 DEVICE_PRIVATE 值确认是否由 Keystore 生成。
- 保护候选阶段：在不改变信任边界的前提下，对需要留在客户端的逻辑使用 R8、VMP、Native 保护、完整性和运行时策略，明确未覆盖资产。
- 复核阶段：用同一发布版本比较原始 Release、基础保护和目标保护，记录明文可见性、类型识别、运行时材料化和业务兼容状态。
- 发布决策阶段：服务端确认合法版本集合、凭据轮换状态、最小权限、灰度范围和回滚包；只有满足条件的候选才进入发布队列。
- 运营阶段：持续观察第三方滥用、配额异常、错误率、Token 过期和用户反馈，发现疑似泄露时按状态机撤销或轮换。
本页的公开证据状态为：来源是公开威胁报告和官方文档，样本与 Secret 均为 none，执行状态为 NOT_TESTED，决策原则是 backend_only_secret_never_enters_apk。
测评目标与非目标
本轮主题目标是建立公开可复用的 Secret 分类与发布门禁，不是宣称已经完成真实 APK 测量。以下矩阵中的“验收问题”描述应执行的检查，结果默认是 NOT_TESTED。
| 目标 | 观察范围 | 验收问题 | 非目标 |
|---|---|---|---|
| 材料枚举 | DEX、资源、Manifest、Assets、SO、JS Bundle | 是否覆盖所有交付载体 | 不上传真实凭据 |
| 凭据分类 | Key、Token、证书、私钥和配置 | 是否能区分公开标识与后端 Secret | 不把字符串命中直接定性为漏洞 |
| 架构处置 | 后端代理、短期 Token、Keystore | 是否把高权限长期凭据移出客户端 | 不用加固替代服务端授权 |
| 保护复核 | 原始 Release、基础保护、目标保护 | 是否记录保护范围与未覆盖项 | 不宣称静态工具失败就是安全 |
| 发布闭环 | 轮换、撤销、合法版本集合、回滚 | 是否能在发布前阻断高风险候选 | 不公开客户渠道或内部系统 |
五级 Secret 分类矩阵
1. PUBLIC_IDENTIFIER：公开标识类值
Firebase 项目 Key 等值通常用于标识项目或请求来源，本身不等于数据库密码。Firebase 官方要求通过 Security Rules、IAM、App Check、API 限制和配额控制实际权限。它可以出现在客户端，但仍应限制 API 范围、包名、签名证书和环境，避免把“可公开”误解为“无需治理”。
2. CLIENT_RESTRICTED：受限客户端 Key
Maps 等客户端 Key 可以在应用中使用，但应绑定 Package Name、签名证书、API Scope 和配额。发布 Gate 要检查限制是否随环境正确切换，测试 Key 是否被误带入正式包，超额或异常使用是否有告警。该类值的保护目标是降低滥用和复制成本，而不是提供后端权限。
3. SHORT_LIVED：短期 Token
短期 Access Token 可以在运行期暂存，但必须有最小 Scope、短 TTL、受控刷新和撤销机制。客户端日志、崩溃报告、剪贴板、深链和 WebView 都不应意外持久化 Token。加固可以保护派生逻辑和请求签名逻辑，但 Token 本身仍应假设可能被观察，服务端必须校验有效期、受众和业务上下文。
4. DEVICE_PRIVATE：设备生成私钥
设备私钥应在 Android Keystore 中生成，并尽量保持私钥材料不离开受保护的硬件或系统边界。服务端注册公钥、校验证明和绑定设备生命周期。若业务需要迁移、注销或恢复，应定义明确的重新注册和撤销流程。把一把已写入 APK 的全局密钥再导入 Keystore，不属于这一类，也不能获得同样的安全性质。
5. BACKEND_ONLY：后端专属 Secret
Service Account Private Key、Gemini Developer API Key、长期数据库凭据、签名服务 Secret 和跨用户共享的全局密钥不应进入 APK、AAB、资源、SO、Assets 或 JS Bundle。正确架构是由后端持有并通过鉴权、短期 Token、最小 Scope 和审计接口为客户端提供有限能力。若历史版本已经包含此类值，应立即标记 ROTATE_REQUIRED，完成撤销、轮换、旧版本处置和日志审计。
| 分类 | 是否随 APK 分发 | 主要手段 | 御盾边界 |
|---|---|---|---|
| PUBLIC_IDENTIFIER | 可以，需正确限制 | Rules、App Check、API Restriction、配额 | 不把标识类值冒充后端 Secret |
| CLIENT_RESTRICTED | 可以，需绑定客户端 | 包名、签名、Scope、配额与告警 | 提高复制与滥用成本 |
| SHORT_LIVED | 临时存在 | 短 TTL、最小权限、刷新与撤销 | 保护使用链，不承诺不可观察 |
| DEVICE_PRIVATE | 可以由设备生成 | Keystore、注册、公钥证明、撤销 | 不负责替代后端权限 |
| BACKEND_ONLY | 不可以 | 服务端、KMS、Secret Manager | 明确要求移出客户端并轮换 |
API Key 不是一个统一的安全概念
Android 官方安全建议指出，若把 API Key 编译进应用，攻击者可能通过反编译找到它，因此应做限制、轮换、环境隔离，并对真正敏感服务使用后端代理。这个原则与“所有 Key 都不能出现在客户端”不同：判断重点是权限、用途、范围和生命周期。
Firebase 文档同时区分了项目配置中的 API Key 与 Gemini Developer API Key。Firebase API Key 通常是项目标识的一部分，数据访问仍由 Rules、IAM、App Check 和 API 限制负责；Gemini Developer API Key 则不应放进客户端代码或配置文件。把两者都叫作“API Key”会导致错误的发布决策。
因此扫描命中后的第一问应是：“这个值能做什么？”第二问是：“它的权限是否被限制？”第三问是：“它是否跨用户、跨环境长期有效？”只有回答完这三问，才能决定是保留、限制、短期化、移除还是轮换。
Android Keystore 解决什么，不解决什么
Keystore 适合设备生成 KeyPair、保护私钥使用、绑定用户认证或硬件能力，并让服务端根据公钥和证明信息判断设备注册状态。它可以降低私钥材料被直接导出的风险，也能为短期会话建立更好的设备绑定。
Keystore 不会把编译进 APK 的全局 Secret 变成真正的后端秘密。若 APK 在首次运行时已经携带该值，或者代码能在运行期还原该值，最初的分发事实就没有改变。正确顺序是：设备生成密钥、服务端注册公钥、按会话或业务授予有限权限；不是先把全球共享 Secret 写入 APK，再在本地保存一份副本。
技术拆解：APP 加固真正保护什么
御盾的客户端加固适合用于提高以下资产被低成本分析、篡改和复用的成本：
- 关键业务算法、接口签名逻辑和授权流程的 DEX 语义；
- Native 代码、SO 载荷、资源和配置的结构化保护；
- 包名、签名、版本、资源摘要与合法版本集合的完整性关联；
- 二次打包、重签名、资源替换和运行时篡改的证据采集；
- 调试、Hook、异常环境和材料化窗口的运行时风险信号；
- 保护候选包在关键业务路径上的兼容性与发布门禁。
加固不应被描述为“把所有 Secret 藏起来”。对于后端专属 Secret，最正确的动作是移除；对于受限客户端 Key，加固可以保护请求构造、限制逻辑和使用链；对于设备私钥，加固可以保护注册、调用和错误处理逻辑，但私钥生成和服务端裁决仍是核心。
APP 加固硬编码密钥检测：Secret Release Gate
发布前可建立如下 Gate，所有状态必须可追踪：
| Gate | 检查内容 | 通过条件 | 失败处置 |
|---|---|---|---|
| 载体枚举 | DEX、BuildConfig、Resources、Manifest、Assets、SO、JS Bundle | 扫描面清单完整 | 标记 NOT_TESTED 或补齐扫描 |
| 值分类 | 每个命中值的用途、权限、TTL、环境 | 有责任人和分类状态 | ROTATE_REQUIRED 或 CLIENT_RESTRICTED |
| 后端隔离 | BACKEND_ONLY 值是否离开客户端 | APK/AAB/渠道包无后端专属 Secret | 阻断发布并轮换 |
| 客户端限制 | 包名、签名、Scope、配额、环境 | 限制与正式构建匹配 | 降权、修配置或阻断 |
| 设备密钥 | 是否由 Keystore 生成、能否撤销 | 公钥注册和生命周期完整 | 重新注册或标记未覆盖 |
| 保护复核 | 原始、基础、目标保护对照 | 保护范围与未覆盖项可解释 | 回到 PoC，不扩大结论 |
| 服务端门禁 | 版本集合、Token 新鲜度、业务上下文 | 服务端能解释并执行策略 | 观察、挑战、延迟或拒绝 |
| 轮换回滚 | 轮换、撤销、旧版本、回滚包 | 有操作责任人和时间窗口 | 延迟发布并保留证据 |
合成 Canary PoC（未执行）
为了避免触碰任何客户凭据，可以建立完全无效的 Canary 值，例如带有 CANARY_NOT_SECRET 前缀且无法访问任何服务的测试字符串。将它分别放入 DEX 常量、资源文件、Manifest meta-data、Assets JSON、Native 字符串和 JS Bundle，用于验证扫描面是否完整。
候选对照可以使用：
- A：Original Release；
- B：R8 基础收敛；
- C：御盾基础保护；
- D：御盾目标保护。
本页不宣称以上四组已经完成测量。推荐记录明文是否直接可见、值的类型是否容易识别、引用关系是否集中、运行时是否需要材料化，以及扫描工具是否把无效 Canary 与真实 Secret 区分开。所有结果在没有授权环境和真实执行记录时都写成 NOT_TESTED，不能凭工具截图推导“绝对安全”。
静态分析面清单
发布 Gate 应至少覆盖以下载体：
| 载体 | 常见内容 | 需要回答的问题 |
|---|---|---|
| DEX / BuildConfig | 环境常量、请求构造、调试开关 | 是否有长期凭据或高权限配置 |
| Resources / Manifest | meta-data、URL、Provider 配置 | 是否误带测试环境或签名信息 |
| Assets / JSON | 第三方配置、模型和功能开关 | 值是标识、受限 Key 还是 Secret |
| Native / SO | 字符串、派生逻辑、协议实现 | 是否只是把全局 Secret 换了载体 |
| JS Bundle / WebView | 前端配置、短期 Token、Endpoint | 是否有可持久化的凭据或调试入口 |
| 崩溃与诊断材料 | 日志、异常上下文、支持包 | 是否在运行后再次泄露敏感值 |
扫描结果必须回到分类和处置，而不是停留在命中数量。一个公开标识类 Key 可能不需要阻断，一个后端专属私钥即使只出现一次也必须阻断并轮换。
AI 批量逆向不等于所有加固失效
批量下载、反编译和字符串筛选主要降低了“发现候选问题”的成本，并不等于已经完成控制流理解、运行时还原、协议复用或业务闭合。不同保护策略对静态可见性、动态材料化、完整性和兼容性的影响不同，必须按真实候选包、设备、版本和业务路径进行授权复核。
因此产品评估应同时问三件事：第一，关键逻辑在静态视角下是否仍容易定位；第二，运行期材料化是否有明确生命周期和证据；第三，异常客户端是否会被服务端合法版本集合、Token 新鲜度和业务策略限制。单看反编译器是否报错，不能替代这三层判断。
攻防视角
防守侧要假设攻击者可以自动化获取公开 APK，并把低成本静态筛选结果交给后续分析。高价值目标包括长期凭据、可跨用户复用的签名材料、未限制的客户端 Key、调试端点、测试环境配置和可预测的 Token 生成逻辑。应对方法是先移除不应分发的值，再用最小权限、短期化、设备密钥和服务端策略降低剩余风险，最后用 APP 加固提高逻辑与完整性被分析和篡改的成本。
御盾与后端承担不同职责。御盾可以让关键逻辑、请求签名、完整性和运行时证据更难被低成本复制；后端负责发放有限权限、校验合法版本、处理轮换和决定业务动作。两者结合时，单个客户端值即使被观察，也不应直接获得跨用户长期能力。
工程落地
建议把 Secret Gate 放在构建、测试、发布和运营的交界处：
- 构建前：维护环境变量与 Secret Inventory，禁止把后端专属值写进源码、模板或构建参数。
- 构建后：对原始 Release、AAB 生成的渠道 APK 和最终发布包分别扫描，避免只看未签名中间产物。
- 保护后：比较 Original、R8、基础保护和目标保护的扫描面，记录哪些命中被移除、哪些属于公开标识、哪些仍需后端处置。
- 验收时：以同一设备和业务路径核对登录、WebView、JNI、升级和错误处理；没有真实执行时保持 NOT_TESTED。
- 发布前：确认后端合法版本集合、Token TTL、配额告警、轮换联系人和回滚包均已准备。
- 发布后：按版本、渠道和环境监控异常调用、配额激增、Token 重放迹象和用户反馈，发现异常时先限制影响面再轮换。
原因链：为什么“藏得更深”仍然可能失败
第一，客户端是攻击者可控制的运行环境，任何必须被客户端使用的全局值都可能在使用时被观察。第二，载体迁移只改变静态位置，不改变值的权限、生命周期和跨用户复用能力。第三，单点扫描命中无法区分公开标识与后端 Secret，误报会导致不必要的阻断，漏报则会让高权限凭据继续流入生产。第四，若服务端没有版本集合、Token 新鲜度和轮换机制，即使客户端保护提高了成本，泄露后的影响仍可能持续。第五，只有把分类、移除、加固、运行时证据和后端门禁串成同一条流程，发布决策才可解释、可回滚。
风险边界
本文不承诺任何 APK、VMP、SO 或字符串保护绝对不可提取，也不把公开威胁报告外推为御盾客户结果。Firebase 项目标识类 Key、受限客户端 Key、短期 Token 和设备私钥都需要按具体权限与生命周期评估；后端专属 Secret 直接移出客户端。系统不会因为“加固成功”就自动替代 API 限制、Rules、IAM、App Check、Keystore、服务端鉴权、轮换和审计。
没有授权样本、设备、候选包、真实日志和业务路径时，本文所有合成 Canary、原始/保护对照和兼容判断均为 NOT_TESTED。如发现历史版本已经包含后端 Secret，应先进入 ROTATE_REQUIRED，完成撤销、轮换、版本下线和日志审查，再讨论是否需要进一步加固。
常见误区
- 把每个 API Key 都当成密码。 先看权限、限制、配额和用途，再决定处置。
- 把每个字符串命中都当成泄露。 公开标识、受限 Key、短期 Token 和后端 Secret 的责任不同。
- 把全局 Secret 搬到 Native 就算安全。 载体变化不会改变客户端信任边界。
- 把 Keystore 当作任意密钥保险箱。 它最适合设备生成的密钥，不是历史硬编码 Secret 的补救。
- 把加固工具报错当成证明。 静态不可读不等于运行时不可观察，更不等于后端权限已经收敛。
- 把发现问题后的“删除字符串”当作全部工作。 还要撤销、轮换、下线旧版本、审计调用并验证回滚。
- 把客户端风险信号直接当成业务封禁。 服务端应结合账号、会话、版本、渠道和业务动作解释。
事实依据与脱敏证据
本节列出本文实际采用的公开依据与可公开的工程判断；没有客户样本、真实凭据或本地执行结果。
| # | 证据来源 | 可复述事实 | 工程判断 | 边界 |
|---|---|---|---|---|
| 1 | Anthropic 2026 年 9 月威胁情报报告 | 公开描述了约 180 万 APK、10 台 EC2 工作节点和 Secret 筛选流程 | 批量静态审计应被纳入发布风险模型 | 不公开样本、下载清单或攻击细节 |
| 2 | Android Developers 安全建议 | 编译进应用的 API Key 可能通过反编译被发现 | 重要凭据应限制权限并优先后端化 | 不声称每个 Key 都是 Secret |
| 3 | Firebase API Key 文档 | 项目 Key 通常是标识，权限由 Rules、IAM、App Check 等控制 | 分类比简单阻断更重要 | 具体配置需由项目负责方复核 |
| 4 | Android Keystore 文档 | 设备生成的密钥可在 Keystore 中受保护使用 | 设备密钥与全局硬编码值应分开治理 | 不宣称能挽救历史硬编码值 |
| 5 | 御盾静态载体说明 | 公开页讨论 DEX、Native、Assets 与明文面复核的观察边界 | 扫描面要覆盖多载体并保留未覆盖项 | 不外推为客户包结果 |
| 6 | 御盾运行时防护说明 | 公开页强调运行时材料化、完整性与服务端证据边界 | 加固应与服务端门禁协同 | 不公开内部实现或测试细节 |
| 7 | 御盾发布身份与 PoC 资料 | 公开页强调包名、签名、候选包、回滚与兼容性验收 | Secret Gate 应纳入发布链 | 具体项目需授权 PoC |
来源简表
| 来源 | 用途 | 公共链接 |
|---|---|---|
| Anthropic 威胁情报（2026 年 9 月） | 批量 APK 审计趋势 | 公开报告 |
| Android Developers 安全建议 | API Key 暴露与后端化 | 安全建议 |
| Firebase API Key 文档 | 标识类 Key 与 Gemini Key 分类 | API Key 管理 |
| Android Keystore | 设备生成私钥与保护边界 | Keystore |
| 御盾静态载体说明 | DEX、Native、Assets 观察边界 | 静态载体与明文面 |
| 御盾运行时防护说明 | 运行时材料化与证据边界 | 运行时防护 |
| 御盾二次打包治理 | 签名、资源、DEX/SO 与发布链 | 二次打包治理 |
| 御盾产品与 PoC 入口 | 保护范围与授权评估 | 御盾 App 加固产品 |
FAQ
APK 中出现 API Key 是否必然是漏洞？
不必然。先确认它属于 Firebase 项目标识、受限客户端 Key、短期 Token、设备私钥还是后端专属 Secret，再检查权限、限制、TTL 和使用范围。后端专属 Secret 一旦进入 APK，应立即轮换；公开标识类值则需要正确的 Rules、App Check、API 限制和配额。
加固能否保护 Gemini Developer API Key？
不能替代后端隔离。Gemini Developer API Key 不应放进客户端代码或配置文件；应由后端代理调用，并使用最小权限、审计、轮换和限流。加固最多提高相关调用逻辑被分析和篡改的成本。
把 Secret 放进 Native 或加密容器可以吗？
如果它是跨用户长期有效的后端 Secret，不可以。Native、VMP 或加密容器能改变静态观察成本，但客户端在某个时刻仍需使用该值。正确做法是移到后端；只有受限 Key、短期 Token 或设备生成密钥才按具体模型评估。
Android Keystore 能隐藏 APK 里的硬编码密钥吗？
不能。Keystore 适合在设备上生成并保护新的 KeyPair；已经随 APK 分发的值在进入 Keystore 之前就可能被获取。应改为设备生成、公钥注册和服务端授权。
发布前 Secret Gate 应该怎么做？
枚举所有载体，给命中值分类，移除并轮换后端专属 Secret，限制客户端 Key，检查 Token 生命周期，确认 Keystore 设备密钥与服务端注册，再对原始和保护候选做同版本复核。任何未执行项都标记 NOT_TESTED，不要用加固工具输出代替真实证据。
内链与后续动作
建议把本页作为 Secret Release Gate 的公开入口，并与静态载体与明文面复核、运行时防护边界、二次打包治理、御盾 App 加固产品、PoC 验收指南 和 R8 性能矩阵 互相链接。对于团队内部使用，可进一步维护 Secret Inventory、轮换记录、合法版本集合和回滚清单；这些资料只有在脱敏并完成授权后才适合公开。