APK、DEX 与签名完整性如何一起验收

御盾技术指南 · 技术原理与实操 · 简体中文

APK 验收需要把文件内容、签名身份和发布路径作为一个整体。只检查反编译结果或只确认安装成功，都无法回答候选包是否适合正式发布。

先固定候选包身份

每轮验收应记录构建来源、版本号、签名证书摘要和文件摘要。后续静态检查、安装、启动和业务回归都必须使用同一身份。

任何重新构建、重新签名或渠道修改都会产生新的候选包，需要重新记录和验证。

DEX、资源、Manifest 和 Native 库暴露的风险不同。检查时应分别记录可读面、替换面、加载入口和完整性约束。

某一层处理充分不能自动证明其他层也满足要求。

正式用户通常通过升级而不是全新安装获得版本。需要验证从当前线上版本升级、数据保留、渠道配置和关键业务路径。

渠道工具如果会修改资源或 Manifest，应纳入固定构建顺序并对最终产物复核。

客户端可以提供签名、版本和完整性信号，但高风险操作的最终判断应由服务端完成，并保留灰度、误报和应急放行机制。

提交应用的技术栈、关键路径与目标系统范围。登录、注册、申请和项目资料均由御盾中央平台承接。