御盾APK 被重签名后为什么还能安装，风险在哪里
解释 APK 当前签名自洽、官方发布身份、覆盖升级、渠道产物和服务端版本策略之间的区别，并给出重打包治理门禁。
让加固后的 APK 仍能顺利升级和发布
御盾不只处理 DEX，还把资源保护、签名身份、二次打包检查、版本升级和渠道产物放进同一条交付链，避免“能安装、不能升级”或最终渠道包失去保护。
你的 App 是否正遇到这些问题
- DEX 中的业务逻辑和接口规则容易被直接阅读
- 资源、Manifest 或配置被替换后仍能重新打包
- 重新签名后产生仿冒包，服务端却无法区分
- 加固包能全新安装，却无法覆盖线上版本升级
御盾如何处理
DEX 与资源保护
收敛关键代码和敏感资源的静态可读面，按业务风险选择保护强度。
签名与重打包治理
把签名身份、包体完整性和服务端合法版本策略放在一起验证。
升级与渠道验收
测试全新安装、覆盖升级、渠道修改和最终产物身份，结论只绑定最后交付的 APK。
本次公开了什么
- 同时检查启动链、类加载、Native bridge 与 SO VMP
- 核对资源载荷、签名摘要和敏感信息收敛
- 把候选样本与最终发布版本明确分开
说明： 公开结果属于候选包静态测评，仍需真机运行、性能、服务端回执和灰度验证。
从评估到交付
查看交付方法- 01
提交最终构建
提供原始 APK、签名与版本计划，以及渠道工具会修改的内容。
- 02
完成保护配置
分别处理 DEX、资源、Native 载体与完整性，再生成可追踪的候选包。
- 03
验证发布链
核对签名、升级、安装启动和关键业务，最终以渠道产物完成验收。
客户经常关心的问题
查看详情
APK 签名方案 v1 至 v4 解析：验证位置、兼容关系与交付检查
深入理解 Android APK 签名方案 v1 至 v4 的验证位置差异、平台兼容逻辑及更新身份约束，通过 apksigner 工具执行交付前完整性校验。
Android 签名证书轮换与 lineage 验收：连续性判定与旧系统边界
详解 Android v3.1 签名轮换中 lineage 文件的生成规则、证书摘要比对方法及旧系统兼容性边界，提供发布前自动化验收脚本与密钥治理策略。
zipalign 为什么必须放在 APK 签名之前：字节变化、签名失效与流水线顺序
解析 zipalign 与 APK 签名执行次序的因果逻辑，详解字节修改如何破坏各签名方案，并提供可执行的构建诊断与严格顺序方案。
AAB 与 split APK 的最终发布身份如何固定
解析 AAB 上传包、设备交付 split APK 集与取证对象的身份差异，明确签名密钥责任分离与 bundletool 清单验证方法。
多 DEX 应用核心代码防漏保护：构建类映射与自动核对机制
针对 Android 多 DEX 架构，提供从 classes.dex 枚举到业务资产映射的完整方案，建立自动核对机制防止核心代码漏保护。
Manifest 导出组件被修改时的风险评估方法
分析 Android Manifest 中 exported、permission 和 intent-filter 的篡改风险，通过签名差分与静态解析确认调用面变化。
Android 资源表篡改检查：resources.arsc 完整性、签名与允许列表设计
围绕 resources.arsc 结构、APK 签名验证、关键资源允许列表与供应链证明，厘清资源篡改与业务配置、运行时责任边界，提供可落地的摘要校验脚本与端到端验证清单。
渠道包签名后注入元数据为何破坏签名与候选身份
解析签名后修改 APK 导致 v2/v3 完整性失效、重签名引发证书冲突及验收失配的技术根源，提供诊断脚本与决策表。
CI 中验证 APK 签名者与发布证书一致：指纹、方案与来源硬门禁
在 CI 流水线中使用 apksigner 校验 APK 签名证书 SHA-256 指纹，强制比对发布摘要并检查 v2 签名方案覆盖，结合构建证明阻断身份错配。
Android 降级与旧包重放风险治理：versionCode、签名与服务端策略
深入剖析旧包重放与降级攻击面，详解基于 versionCode 单调性、签名连续性和服务端允许版本集合的防御方案，并提供可直接部署的版本校验器实现。
APK 文件摘要为什么不能代替签名验证：字节身份与签名者分开验
说明 APK SHA-256、Android 签名方案、签名证书、apksigner 回执和构建证明各自回答什么，并给出联合校验方法。
APK 内 Native 库的打包对齐怎样验收：ZIP、ELF、ABI 与签名顺序
从最终 APK 枚举 SO，核对 ABI 目录、ZIP 数据偏移、ELF LOAD 对齐、AAB 派生交付和签名后字节稳定性，并给出只读检查代码与发布门禁。
APK 供应链证明能证明什么，不能证明什么
区分 APK 摘要、构建 provenance、attestation 签名者、应用签名证书与运行时安全证据的职责边界。
APK 升级连续性怎样在发布前预检：包名、签名、Split 与设备路径
发布前对照已发布基线和新 APK，检查 applicationId、versionCode、签名关系、split 安装契约、数据迁移与代表性设备升级路径。
APK 发布身份为什么要同时固定包名、版本和证书：候选元组验收方法
把 packageName、versionCode、签名证书、APK 摘要和来源证明合成不可拆分的发布身份，避免测试报告、渠道包与真实候选错配。
怎样阻止调试证书签名的 APK 进入发布
把允许证书、构建变体、签名方案和产物来源做成最终 APK 的不可绕过流水线门禁。
Split APK 安装会话为什么必须原子提交：base、配置 split 与失败回滚
解释 base APK、ABI、语言、密度和 feature split 为何必须在同一 PackageInstaller 会话中核对包名、版本、签名与完整集合，并给出只读清单检查代码。
Play 上传密钥与应用签名密钥有什么区别：提交身份与设备身份分开管
拆清 Play 上传密钥、应用签名密钥、公开证书、商店托管签名和设备升级连续性的责任，并建立不接触私钥的核对清单。
多 Build Variant 的签名配置怎样防止串用
按变体固定包名、渠道、签名责任、允许证书、产物来源和验证任务，阻止测试与正式配置交叉。
AAB 上线前为什么要验收派生 APK：代表设备、模块、ABI 与安装路径
从上传候选 AAB 为代表设备生成 APK set，核对 base、feature、ABI、资源、签名和安装回归，并区分本地 bundletool 证据与商店交付回执。
最终 APK 的 App Link 证书指纹变化怎样验收
联合核对最终 APK 签名证书、Manifest 主机和 assetlinks.json，建立证书漂移的发布门禁与设备回执。
同一源码构建的 APK 摘要不同：从变体到签名的分层归因
冻结两个原始 APK 与构建上下文，按变体、依赖、ZIP 条目、资源、DEX、Native 库和签名层定位摘要差异，区分可解释变化与可复现构建。
最终 APK 权限变化的发布前差分门禁怎么做
从基线与候选 APK 的最终 Manifest 提取权限和导出组件，识别依赖、变体与清单合并带来的新增访问面，并把批准记录绑定到唯一候选。
最终 APK 中 Provider authority 冲突怎样在发布前发现
从最终 APK 提取全部 Provider 的 authority、来源依赖、变体占位符、进程和导出属性，建立重复、空值及跨变体漂移门禁。
AAB 派生 APK 的资源 Split 完整性盘点：语言、密度与设备集合
按目标设备配置核对 base、功能、语言、密度和 ABI split，绑定安装身份与资源清单，并区分本地 bundletool 派生证据和真实商店交付回执。
发布 APK 如何盘点残留的调试文件与敏感资产
只读枚举最终 APK 的 assets、res/raw、未知 ZIP 条目和 DEX 文本线索，区分需复核的调试材料与正常资源，并将发现绑定到唯一候选。
如何从最终 APK 反查第三方 SDK 与构建依赖清单
交叉核对目标变体依赖图、DEX 包前缀、Native 条目、Manifest 权限组件与公开资料，建立带置信度和来源边界的 SDK 二进制清单。
最终 APK 的 minSdk 与 targetSdk 变化怎样做差分门禁
从前后最终 APK 提取 SDK 边界、包名、版本和构建变体，区分安装范围变化与平台运行语义变化，并生成对应设备回归清单。
最终 APK Manifest 与源码不一致：沿变体和依赖追踪合并来源
以最终二进制清单为核对对象，从主模块、构建变体、占位符、直接与传递依赖及 AAB 模块追踪权限、组件、SDK 和元数据漂移。
Google Play 轨道回执怎样绑定 APK 候选身份
将 Play track、versionCode、发布状态、用户比例与本地 APK 摘要、签名证书摘要和构建来源组成可审计回执，避免把 API 接受误写成上线完成。
最终 APK 的 App Link intent-filter 变化怎样做差分门禁
从最终 APK 提取 App Link 组件、scheme、host、path、autoVerify 与 exported，识别新增、删除和匹配面扩大，并建立发布回执。
APK 多签名者与证书轮换 lineage 有什么区别
区分同一 APK 的当前 signer 集合与跨版本有序证书 lineage，建立升级连续性、系统范围、Play 密钥责任和 CI 身份门禁。
APK v1 签名怎样发现未覆盖或异常 ZIP 条目
从最终 APK 的 ZIP 清单、MANIFEST.MF、重复名称和验签结果审查 v1 条目覆盖，并与 v2 及更高签名方案分层取证。
为什么 APK 签名验证要覆盖目标 SDK 范围
从最低支持系统到目标系统建立 apksigner 验证矩阵，分开记录 v1、v2、v3.1、v4、证书轮换与真实设备回执。
增量安装的 idsig 文件如何避免与发布 APK 错配
为 APK 与 v4 idsig 建立成对摘要、生成来源和安装路径回执，识别缺失、串包、重复使用及候选版本错配。
APK 签名证书过期会怎样影响安装与升级
区分证书有效期、Android 签名身份、上传与应用签名密钥、v3.1 轮换和历史包升级，建立可复核连续性门禁。
动态功能模块的最终 Manifest 怎样按交付条件验收
按安装时、条件和按需交付核对 AAB 模块、fusing、依赖、设备派生 APK 与最终组件，避免只审源码 Manifest。
最终 APK 多个 DEX 出现重复类时怎样做发布门禁
扫描全部 classes*.dex 的类描述符并关联 release 依赖图、重定位和残留实现，建立可阻断发布的重复类证据链。
最终 APK 怎样发现未解析或串用的 Manifest 占位值
从最终二进制 Manifest 核对 authority、host、scheme、process 与 meta-data，并追溯变体、依赖和后处理来源。
extractNativeLibs 配置怎样影响 APK 内 SO 的压缩、对齐与安装
联合检查最终 Manifest、SO 的 ZIP 压缩与数据偏移、ABI 路径和 ELF LOAD 对齐，建立可复核的 Native 发布门禁。
购买前常见问题
APK 加固是否只保护 DEX？
不是。DEX 是重要层面，但资源、Manifest、Native 库、签名和版本升级同样影响重打包与发布风险。
重新签名后还能正常安装就安全吗？
不能这样判断。安装成功只说明系统接受该包，不代表签名身份、服务端版本校验和业务完整性仍然成立。
渠道包应在加固前还是加固后生成？
取决于渠道修改范围和签名流程。应先固定构建顺序，再验证每个渠道产物的签名、资源、启动和升级。
如何证明发布的是正确 APK？
记录构建来源、版本、签名证书摘要、文件摘要和回归结果，并让发布系统只接收已批准的候选身份。
安全标准与平台依据
- Android 应用签名
签名身份、升级链和发布一致性
- Android 安全最佳实践
Android 应用安全设计与发布边界
- Play Integrity API
服务端判定与应用完整性信号边界
- OWASP MASVS
移动应用安全控制与验证范围
- Android NDK ABI 指南
Native 架构、ABI 和打包兼容