APK报‘未包含任何证书’：签名机制、v1/v2/v3与重签排查

APK 装不上，屏幕弹出一句“未包含任何证书”，这个场景我这两年遇到得越来越频繁。前两天还有个朋友半夜发消息问我，说自己从某个渠道拿到的安装包，在部分国产定制系统的新版本上死活装不进去，换台旧手机就能装。这类问题的答案其实很集中：不是安装包坏了，也不是手机设置有问题，而是APK 签名这一层出了状况。签名是安卓应用的身份证明，系统在安装前会先验证它，验证不通过就一句话把你挡回来。这篇内容我打算把“未包含任何证书”这条报错掰开揉碎讲清楚：签名机制到底签了什么、v1/v2/v3 三代方案有什么区别、新版系统为什么越来越挑、以及从生成密钥库到重签验证的完整可复现流程。不管你是刚接触打包的新手，还是天天给别人修包的老手，都能从里面找到能直接抄下来用的命令和判断路径。

1. 先搞清楚这条报错到底在说什么

1.1 报错的真实含义：不是文件坏了，是签名链断了

“未包含任何证书”这句话听起来像是说安装包里缺了个文件，实际上系统表达的意思是：在解析安装包时，没有读到有效的签名证书信息。安卓的包管理服务在真正安装之前会做一道预检，把 APK 当成一个 ZIP 包打开，找到META-INF目录或者签名块，取出 X.509 证书和摘要，然后拿摘要去比对包里每个文件的哈希值。比对通过才认为这个包是完整的、来自某个确定身份的，允许继续走后面的解析流程。

一旦这一步拿不到证书，或者拿到的证书对不上摘要，系统就会抛出INSTALL_PARSE_FAILED_NO_CERTIFICATES，各家定制系统的中文提示措辞略有差异，“未包含任何证书”“安装包无签名”“签名校验失败”基本都指向同一处。所以看到这句话，第一反应不应该是去查手机设置、清缓存、重启，而是应该直接把包拿出来做签名检测。我见过太多人在这上面浪费时间，反复卸载重装、换数据线、换电脑，其实问题从头到尾都在包本身。

顺带说一个容易混淆的点：这条报错和“安装失败，应用签名冲突”（INSTALL_FAILED_UPDATE_INCOMPATIBLE）是两码事。前者是没有证书或者证书无效，后者是有证书但和已装版本的证书不一致。搞清楚这个区分很关键，因为处理方向完全相反：前者要重签，后者要么卸载旧版本，要么用同一把密钥重签。

1.2 四类高发场景，先对号入座

我把这些年遇到的案例归了归类，能触发这条报错的场景基本跑不出下面四种，你可以先花一分钟自测，直接锁定方向，别一上来就闷头重签。

这四类的处理手法不完全一样，但底层逻辑是通的：让包里重新拥有一份当前系统能识别、且覆盖全包内容的有效签名。后面第 4 章我会逐个场景展开，现在先把原理补上，不然后面的命令你只能照抄，出了问题不会判断。

提示：判断是不是签名问题，一条命令就够了——unzip -l your.apk | grep META-INF。如果连MANIFEST.MF、.SF、.RSA这三个文件都看不到，那基本可以确定包里没有 v1 签名信息，问题定性完成。

2. APK签名到底签了什么：从META-INF到签名块

2.1 v1签名：一份逐文件的摘要清单

最早的签名方案（现在统称 v1，也叫 JAR 签名）思路非常朴素，它借用了 Java 生态那套签名机制，在 APK 的META-INF目录里塞三个文件。MANIFEST.MF记录包里每一个条目（entry）的内容摘要，通常用 SHA-256；CERT.SF是对MANIFEST.MF整体再做一次摘要，同时对每个条目在清单里的那一段也做摘要；CERT.RSA（或.DSA、.EC）则是用私钥对CERT.SF的签名结果，外加签发者的 X.509 证书。

验证时的链条是这样的：先用CERT.RSA里的公钥验CERT.SF的签名，确认清单没被改；再用清单里记录的摘要逐个校验包内文件，确认文件没被换。听起来挺严密，但它有个致命的缝隙——ZIP 包的结构性内容不在保护范围内。也就是说，攻击者可以往包里塞进签名清单里没有列出的新文件，而这些新增条目在验证时会被跳过。这个洞在 2016 年前后被反复利用，也直接催生了后面的方案。

现在回头看，v1 的价值主要剩两点：一是兼容 API 24 以下的老系统，二是它的摘要信息是逐文件的，某些场景下排查“到底哪个文件被改了”比新方案更方便。我在做问题定位时，经常先看MANIFEST.MF里的条目数量和实际包内文件数对不对得上，对不上就说明这个包被人动过手脚。

2.2 v2/v3：整包摘要与签名块的位置玄机

Android 7.0 引入了 v2 方案，思路彻底换了。它不再逐文件签名，而是在 ZIP 包的中央目录之前插入一块专门区域，业内叫 APK Signing Block，末尾带一个固定的魔数APK Sig Block 42。这块区域里存放签名者的证书、签名算法标识，以及三组摘要：内容区摘要、中央目录摘要、EOCD（中央目录结束记录）摘要。三者合起来等于给整个包画了一张“全身照”，任何一处的字节变动都会导致校验失败。

这个设计带来的直接后果是：v2 签名之后，包就不能再被任何工具改动结构了。你哪怕只是用某些压缩软件重新保存一次、往 ZIP 注释里写点东西、或者再跑一遍zipalign，签名块的位置关系就变了，校验立刻失败。很多“未包含任何证书”的报错，本质上是渠道包工具、加固工具、资源修改工具在签名之后又动了包结构，把签名块搞没了或者让它失效了。

Android 9 又加了 v3，主要解决密钥轮换问题：应用可以在换签名密钥时，把新旧密钥的对应关系（proof-of-rotation）写进 v3 块，让系统认可这条继承链。而 v4 是配合增量安装（apk.idsig）用的，主要服务于开发调试场景，普通分发很少直接关心。实际打包时，apksigner会默认同时写入 v1、v2、v3（取决于最低支持版本设置），你不需要手工挑，但得知道它们各自管什么。

2.3 凭什么拒你：targetSdk 与签名方案的绑定关系

新版定制系统之所以越来越“挑食”，是因为系统侧对签名方案设了硬门槛。从 Android 11 开始，如果应用的targetSdkVersion达到 30 及以上，只带 v1 签名的包将无法安装，必须至少具备 v2 签名。这条规则一出，一大批只在老构建链上打过包的存量应用直接躺枪，装到新机型上就提示签名无效或者干脆装不上。

这里的判断逻辑要理清：系统不是看你的包“老不老”，而是看包里声明的目标版本。所以有些包明明是很久以前打的，但只要targetSdkVersion写得低，照样能装；反过来，一个包如果声明了高目标版本却没有对应的高版本签名，就会被拒。这也是为什么同一份 APK，在老机器上装得好好的，换到新系统上就不行——不是包变了，是判定规则变了。

另一个容易被忽略的点是最低支持版本（minSdkVersion）与 v1 的关系。如果应用要兼容 API 24 以下的设备，就必须保留 v1 签名；如果确定只跑在新系统上，纯 v2/v3 也能过。apksigner会根据你传入的--min-sdk-version自动决定要不要生成 v1，这个参数不传时它会去读清单里的值，读不到就按保守策略处理，偶尔会生成意料之外的结果。我一般建议手动显式指定，避免踩到工具默认值的坑。

3. 重签实操：从生成密钥库到验证通过的完整链路

3.1 工具准备：版本选错后面全是白干

重签这件事，工具链的版本比命令本身更重要。你需要两样东西：一套 JDK（建议 17 或以上，keytool和jarsigner都在里面），以及 Android SDK 的 build-tools 目录（apksigner和zipalign在里面）。apksigner从 build-tools 24.0.3 开始提供，但这个版本太老，对 v3、v4 支持不全，用老版本签出来的包在新系统上可能出现“方案不全”的怪异表现。我的习惯是直接用 build-tools 34 或 35 里的版本，兼容性好，输出信息也更清楚。

环境变量建议配一下，省得每次写全路径：

# 假设 SDK 装在用户目录下，按自己的实际路径改 export ANDROID_HOME=$HOME/Android/Sdk export PATH=$ANDROID_HOME/build-tools/35.0.0:$PATH export PATH=$ANDROID_HOME/platform-tools:$PATH # 验证版本，两个命令都要能出版本号 apksigner version zipalign -h | head -n 3

这里要提醒一句：不要把不同版本的 build-tools 混用。我遇到过一次，zipalign用的是 30 版，apksigner用的是 35 版，签出来的包在验证阶段一直报摘要不匹配，折腾了一个多小时才发现是工具版本混搭导致的字节对齐差异。统一到一个目录下，问题立刻消失。

注意：如果你只是想让包装上去跑一跑，不要去动别人正式发布包的密钥。用自己的密钥重签意味着这个包和线上版本“血缘不同”，将来无法覆盖安装、无法走应用内更新，这部分后面会详细说。

3.2 生成 keystore：参数怎么定、有效期怎么算

密钥库是一切的起点。没有它，你签出来的包没有任何可追溯的身份。用keytool生成一个 PKCS12 格式的密钥库：

keytool -genkeypair -v \ -keystore demo-release.keystore \ -alias demo-key \ -keyalg RSA \ -keysize 2048 \ -validity 10000 \ -storetype PKCS12 \ -dname "CN=Demo, OU=Dev, O=Demo, L=City, ST=State, C=CN"

参数怎么定，这里展开说几句。-keyalg RSA配合-keysize 2048是目前最稳妥的组合，2048 位在安全性和兼容性之间平衡得最好；如果你有特殊要求也可以用 EC，但部分老旧设备对 EC 签名的兼容性不如 RSA 稳。-validity 10000是天数，约 27 年，这个数字不是随便写的：应用市场普遍要求签名证书的有效期覆盖到某个未来时间点之后，有效期给足了，后续就不用为证书过期发愁。

-storetype PKCS12是重点。老的 JKS 格式在新版 JDK 里已经不被推荐，而 PKCS12 是标准格式，各种工具链都认。我见过有人用 JKS 生成后在某个签名工具里报“无法读取密钥库”，换成 PKCS12 就好了。

-dname里的字段随便填，但别用真实身份信息，尤其是准备对外分发的包。这个字段会写进证书，虽然对安装没有影响，但它是可以被人看到的。

生成完记得把 keystore 文件和密码保管好。丢了密钥库意味着你再也无法给同一个应用发布更新——新包签名不同，用户必须卸载重装。这个代价非常大。

3.3 顺序错了就白签：zipalign 必须在 apksigner 之前

这是所有坑里最高频的一个，我专门单列一节讲。zipalign的作用是让 APK 内的未压缩文件按固定字节边界对齐（通常是 4 字节，-p参数下.so文件还会做页对齐），目的是运行时可以直接 mmap 映射，省内存、启动快。问题是，zipalign会移动包内文件的位置，从而改变字节布局。

所以正确顺序只有一条：先对齐，再签名。如果你先签名再对齐，签名块记录的摘要全部作废，包就成了“有签名块但校验不过”的状态，系统读证书时直接报错，症状和“未包含任何证书”非常接近。

# 第一步：对齐（输入用未签名的原始包） zipalign -p -f -v 4 app-unsigned.apk app-aligned.apk # 第二步：对对齐后的包签名 apksigner sign \ --ks demo-release.keystore \ --ks-key-alias demo-key \ --ks-pass pass:你的密码 \ --key-pass pass:你的密码 \ --v1-signing-enabled true \ --v2-signing-enabled true \ --v3-signing-enabled true \ --out app-signed.apk \ app-aligned.apk

-p参数容易漏。它的作用是让.so库按页边界对齐，虽然不加也能装上，但对启动性能有影响，而且新版系统对 16KB 页对齐提出了新要求，部分构建工具已经支持-P 16参数来处理。如果你手上的工具版本支持，包里又有 native 库，建议一并加上。

还有一个细节：签名后不要再碰包。不要用压缩软件“打开、删个文件、保存”，不要跑二次对齐，不要往 ZIP 注释里写渠道信息。这几年的渠道包方案之所以从“往注释里塞信息”改成“往签名块里塞信息”，就是因为前者在 v2 时代必然破坏签名。

3.4 签名命令逐参数拆解与验证输出解读

上面那条apksigner sign命令，几个参数值得单独说说。--ks-pass和--key-pass后面跟pass:前缀是明文写法，方便脚本化；如果不想让密码出现在命令历史里，用file:前缀指向一个文本文件，或者干脆省略让工具交互式询问。

三个--v1-signing-enabled之类的开关，很多人以为全开最保险，其实要看你分发的目标范围。如果应用要兼容很老的设备，v1 必须开；如果确定只跑在新系统上，全开也没坏处，只是包会大一点点。真正的关键在于--min-sdk-version这个参数：它会联动影响 v1 是否被强制执行，以及摘要算法的选择。不传的时候工具会去读包里的清单，我遇到过清单里版本号写得不规范导致工具判断失误的情况，所以习惯性显式写上。

签完之后必须验证，这一步别省：

apksigner verify --verbose --print-certs app-signed.apk

输出会列出三个方案各自是否通过，以及证书的指纹、主题、有效期。你需要确认两点：一是Verified using v2 scheme: true这一行要为真（针对新系统），二是打印出的证书主题跟你生成的-dname对得上。如果 v2 显示为 false，说明签名块没写进去，或者包在签名后被改动过，那就得从头再来。

另外补充一个jarsigner的用法，它在只做 v1 签名的场景下仍然有用：

jarsigner -verbose \ -sigalg SHA256withRSA \ -digestalg SHA-256 \ -keystore demo-release.keystore \ app-unsigned.apk demo-key

注意jarsigner是原地修改输入文件，没有-out概念，操作前记得备份。而且它只做 v1，签完还得跑一次apksigner补上 v2/v3，顺序不能反。实际工作中我基本不用它，apksigner一个工具能覆盖全部方案，没必要引入第二个。

4. 五类疑难场景的对应打法

4.1 被人二次打包过的渠道包

这是最典型的一类。渠道分发过程中，有人为了让包带上自己的标识，会用工具解开原包、改点东西、再打回去，整个过程没有重签。结果就是原包的签名信息被破坏，或者干脆被剥离掉了。

判断方法很直接：解压看META-INF目录，对比文件数量；或者直接跑apksigner verify，看它报什么。如果报“找不到签名块”又“没有清单文件”，那就是签名信息被完全清除了。

处理办法只有重签。但重签前有个前置判断：这个包本身还能不能正常运行。如果重打包的人改动了代码或资源，重签只能解决安装问题，解决不了功能问题。我的做法是先重签装到测试机上跑一遍核心流程，确认没问题再往外发。另外要提醒一句，重签后的包与原始版本签名不同，如果设备上已经装了原版，必须先卸载，否则会撞上签名冲突的报错。

4.2 debug 产物直接拷出来装

开发阶段最容易出的问题。构建目录里翻出来的app-debug.apk，理论上是带调试签名的，但有两种情况会让它变得不可用：一是构建过程被中断，包只写了一半；二是某些构建插件在打包后又做了字节码插桩或资源替换，改动了包内容却没重签。

这类包的验证很简单，装一次看报错。如果提示签名相关，用apksigner verify看输出，通常会发现 v2 方案为 false。解决思路是重新走一遍完整的打包流程，而不是手动去补签——debug 包补签的价值不大，直接重新构建更省事。

顺带说个经验：调试签名和发布签名的密钥库要分开放。我见过有人图省事，调试也用自己的发布密钥库，结果某次误操作把密钥库文件提交到了代码仓库里。这类事故的修复成本极高，密钥一旦泄露，只能走密钥轮换流程，而轮换在旧系统上还有兼容问题。

4.3 AAB 与 split APK 的签名缺失

现在不少项目用 AAB 格式交付，本地要装就得先转成 APK。用bundletool转换的时候，如果没指定签名参数，产出的 APK 是未签名的状态，直接装就会撞上这条报错。

# 从 AAB 生成 APK 集，并指定签名密钥 bundletool build-apks \ --bundle=app.aab \ --output=app.apks \ --ks=demo-release.keystore \ --ks-key-alias=demo-key \ --ks-pass=pass:你的密码 \ --key-pass=pass:你的密码 \ --mode=universal # 解出通用包 unzip app.apks -d apks-out

--mode=universal生成的是单个包含全部资源的包，方便本地测试；如果要模拟真实分发，用默认模式生成 split APK 集，安装时用adb install-multiple一次性推多个分片。这里有个细节：split APK 的每个分片都需要签名，而且必须用同一把密钥，bundletool在指定了--ks参数后会自动处理，但如果你手工拆包，很容易漏签某个分片，表现就是安装时提示签名无效。

4.4 系统侧门槛：只带 v1 的老包

前面提过，目标版本较高的应用在新系统上只认 v2 及以上。这类包的特征是：apksigner verify输出里 v1 为 true，v2、v3 全为 false。它本身是“有签名”的，只是签名方案达不到系统要求。

处理办法就是重签，加上 v2/v3 开关。但这里有个必须注意的点：重签会改变应用的身份。如果这个包是从线上渠道拿到的正式版本，你用新密钥重签后，它就再也没法和线上版本共存或覆盖升级了。如果只是自己测试用，那无所谓；如果是要给用户分发，就必须用原开发方的密钥重签，这通常意味着你得回到源头去要包。

还有一种情况值得单独提：有些包同时具备 v1 和 v2，但 v2 的摘要对不上。这通常是因为包在签名后被某个工具“无损”改动过——比如只改了 ZIP 注释、只调整了文件顺序。这种包在验证时会显示方案存在但校验失败，重签是唯一出路。

4.5 签名没问题却依然装不进去

签名验证通过了，安装还是失败，这时候问题就不在签名上了。常见的有这么几种：包名相同但签名不同导致覆盖冲突、安装包架构与设备不匹配（比如只带 arm64 的包装到 32 位设备上）、系统的未知来源安装权限没开、包内清单声明的目标版本超出了系统支持范围。

排查顺序我一般的习惯是：先用adb install走命令行安装，命令行会打印出更详细的错误码，比系统弹窗信息量大得多。看到INSTALL_FAILED_UPDATE_INCOMPATIBLE就说明是签名冲突，先卸载旧版；看到INSTALL_FAILED_NO_MATCHING_ABIS就是架构问题；看到INSTALL_PARSE_FAILED_*系列才回到签名和清单解析这条线上。

# 命令行安装，输出错误码更明确 adb install -r -d app-signed.apk # 如果是 split APK adb install-multiple base.apk split_config.arm64_v8a.apk split_config.zh.apk

-d参数允许降级安装，-r是替换已有安装。这两个参数在调试时能省掉不少手工卸载的步骤，但正式排查签名问题时建议先不加参数，让错误原样暴露出来。

5. 排错速查表与几条踩坑实录

5.1 报错码与定位路径对照表

把常见的报错和对应处理整理成一张表，遇到问题时可以照着往下走，不用每次都从头推理。

表格里第三行值得多说一句。“解析包时出现问题”经常被误认为是签名问题，其实更多时候是包在传输过程中损坏了，尤其是通过聊天工具、网盘传输大文件时更容易发生。判断方法是比对文件的哈希值，或者直接看包大小对不对得上。我遇到过一次，包大小比原始文件少了几十 KB，重下一遍就好了。

5.2 我踩过的坑：顺序、缓存、工具链

第一个坑是顺序。早年我第一次接触 v2 签名，习惯性地签完再跑对齐，结果包在任何设备上都装不上，报的正是“未包含任何证书”。当时我以为是密钥库有问题，重新生成、重新签，反复搞了半天，最后才想起对齐会动字节。这个教训我记到现在：对齐在前，签名在后，中间不插任何操作。

第二个坑是工具缓存。有一次改了清单文件重新打包，构建工具判断“输入没变”直接复用了旧的中间产物，导致签出来的包内容还是旧的，签名摘要自然对不上。清除构建缓存、加--rerun-tasks之类的强制重跑参数之后问题消失。这类问题特别隐蔽，因为它不报错，只是结果不对。

第三个坑是压缩工具。某个同事为了让包小一点，用压缩软件把 APK 重新压了一遍，包是变小了，签名也没了。APK 本身就是 ZIP，二次压缩会重写整个结构，签名块首当其冲被丢弃。记住一点：APK 不是普通压缩包，别用压缩软件去“优化”它。

第四个坑跟签名算法有关。同一个包，用老版本的apksigner签出来，在部分设备上校验通过，在另一些设备上失败。查下来是老版本对摘要算法的默认选择有问题，升级工具版本后一切正常。工具的默认值会随版本变化，签名这种对字节极其敏感的操作，不要长期停留在旧版本上。

5.3 一点个人习惯

我现在处理任何“装不上”的包，第一步永远是三件事：看包大小、解压看META-INF、跑一遍apksigner verify --print-certs。这三步能把绝大多数问题定性，比在手机上反复试快得多。定性之后再决定是重签、是重新获取包，还是去查其他方向。

还有一个习惯是保留未签名的中间产物。签名是不可逆的，签错了只能从原始包重来。所以我一般在流程里留一份app-aligned.apk不动，签名输出到新文件，验证不通过就从对齐那一步重跑，省掉前面的解包和重打包时间。

最后说一句密钥管理。密钥库和密码一旦丢失，应用就失去更新能力，这个风险比任何技术问题都严重。我的做法是密钥库文件异地备份两份，密码单独存、不放在同一个地方，并且明确记录每个应用的别名和创建时间。听起来有点小题大做，但真出过一次事故的人，后面都会这么做。