签名方案勾选那一排：v1 到 v4 的开关与兼容判定

一、一排勾选框，凭什么值得单独一篇

先承认一个事实：绝大多数用户从没动过这排勾选框，也确实没出过事。默认值 v1 加 v2 加 v3，对今天九成九的应用都够用。那这一排存在的意义是什么？是剩下那百分之一——而且那百分之一往往是最疼的百分之一：一个 minSdk 很低、要照顾老设备的行业应用；一台用了七八年的旧手机；一个想尝鲜增量安装的实验项目。这些场景里，勾错一个框的代价是「包在开发者电脑上好好的、装到目标设备上就是不行」，而且报错信息基本不提签名半个字。

还有一个更普遍的原因：理解这排勾选框，是理解安卓签名体系的最短路径。v1 到 v4 每一代方案都在回答同一个问题——「怎么让系统又快又稳地确认这个包没被改过」，而每一代的答案都带着上一代的历史包袱。把这条演进线读懂，你对「为什么改完包必须重签」「为什么老设备装不上新签的包」这些问题的理解会瞬间立体起来。

所以这一篇的目标不是教你改勾选——大多数时候恰恰是不改——而是让你知道每个框是什么、默认值为什么这么定、什么时候真的需要动它，以及动了它之后怎么验证签没签上。带着问题出发，我们从最老的 v1 说起。

二、v1：写给老设备的信封火漆

v1 是安卓诞生之初就有的方案，学名叫 JAR 签名——安卓的应用本质上是一个特殊的压缩包，v1 就是给压缩包里每个文件逐个盖戳。它的优点是兼容性无敌：从安卓 1.0 到最新的系统全都认。它的缺点也很出名：逐文件签名意味着装一个包要校验一遍所有文件的戳，大包安装慢；而且压缩包的中央目录部分不在签名保护范围内，历史上留下过一些构造攻击的空间。

对改包用户来说，v1 有一条铁律必须刻在脑子里：包的最低系统版本低于 Android 7.0（API 24）时，v1 必须勾着。原因很简单：老系统只认 v1，不认后来出现的 v2。一个 minSdk 是 21 的包，如果只勾 v2 去签，新手机上装得好好的，一到 Android 6.0 的老设备上就变成「无法解析的安装包」——不是包坏了，是老设备看不懂新的盖章方式。

好消息是这种错误在安卓修改大师电脑版里基本不会发生。「设置签名」窗口保存时会读项目配置里的最低 SDK 信息——那是导入 APK 时解析出来的真实数据——一旦发现「minSdk 低于 24 而你没勾 v1」这种危险组合，直接拦下不让你保存。把兼容性知识做进校验里，是图形化工具对命令行最大的优势之一：让错误在保存的那一刻被看见，而不是在客户的老手机上被看见。

三、v2：一次盖整个信封

v2 随 Android 7.0 登场，思路和 v1 完全不同：不再逐文件盖戳，而是把整个包当成一个整体盖一枚大戳，戳直接嵌在包文件结构里。安装时系统只需校验这一枚戳，速度比 v1 快得多；保护范围也覆盖了整个文件，堵上了 v1 时代的构造漏洞。

它的问题只有一面：太新。Android 7.0 以下的设备完全不认 v2——不是「校验失败」，是「根本不知道有这个东西」。所以 v2 从诞生那天起就必须和 v1 搭配着用：新设备走 v2 快速通道，老设备退回 v1 慢速通道。这就是为什么默认配置是 v1 加 v2 加 v3 一起开——多套签名同时存在，系统按自己认得的最新的那套来用，一套包通吃新老设备。

有个细节值得多说一句：v2 的签名嵌在文件结构里，意味着对包文件的任何字节级改动——包括 zipalign 对齐这种看似无害的调整——都会破坏 v2 签名。这就是打包流水线里「先对齐、后签名」这个顺序不能颠倒的根本原因。安卓修改大师的自动打包把顺序焊死在流程里，你不需要惦记；但理解了这个因果，再看流水线四个步骤的排列，会有一种「原来如此」的通透。

四、v3：给换钥匙留的路

v3 从 Android 9 开始支持，最大的新能力是「密钥轮换」——允许应用在保持身份连续的前提下，用新的密钥接替旧的密钥。这解决的是一个非常现实的问题：签名密钥用久了有泄露风险，或者公司换了主体需要换钥匙，以前只能全量卸载重装，有了 v3 的轮换机制，升级关系可以平滑延续。

对改包场景，v3 的日常意义倒不在于轮换（轮换需要新旧两把钥匙协同操作，是个主动动作），而在于它是「新设备优先选择的方案」——Android 9 以上的系统看到包里有 v3，就优先校验 v3。默认勾上 v3，等于给新设备递上它们最认的那份证件，校验速度和信任等级都最优。

顺带回应一个常见误解：勾了 v3 不等于「更安全」，三个方案同时开也不冲突，它们是同一身份的三种表述方式，不是三道互相竞争的锁。系统只会用它认得的最新一版来校验。理解了这一点，「要不要全勾」这个问题就变成了纯粹的范围问题——你的目标设备最老到哪一代，决定 v1 必不必须；其余的，开着只有好处。

五、v4：为什么默认不勾它

v4 是四兄弟里最年轻也最特殊的一个。特殊性在于：它不在包文件里——勾了 v4，签名工具会额外产出一个 .idsig 独立文件，包本身不变。这个独立文件服务于「增量安装」这种特殊场景：开发调试时只装改动的部分，系统借助 idsig 文件完成校验。日常分发、商店上架、普通安装，都用不到它。

所以默认不勾 v4 是一个深思熟虑的克制选择：对绝大多数用户，勾了它只会让项目目录里多一个用不上的文件，偶尔还会在「该交付哪些文件」这个问题上制造困惑——把 idsig 当成签名包的一部分发给别人的情况并不少见。默认关掉，需要增量安装的人自己打开，世界清静。

v4 还有一条硬性规则：不能单独用，必须同时勾 v2 或 v3。道理不复杂——v4 校验的是「包的签名结果」的摘要，包本身得先有 v2 或 v3 之中的一个才有结果可摘。窗口在保存时会拦下「只勾 v4」的组合，原因写在窗口里。这类规则让工具替你记着专业细节，你只需要知道「单独勾 v4 会被拦」就够用了。

六、两条硬规则：保存时的两道闸

把这一排勾选框的规则收拢一下，其实只有两条硬的：第一，不能一个都不勾；第二，v4 不能单独勾。加上前面说的软规则「minSdk 低于 24 必须留 v1」，一共三条边界。前两条在点保存时由窗口强制拦截，第三条由最低 SDK 信息提前预警。

值得琢磨的是「不能一个都不勾」这条。有读者可能会想：我就想要一个不签名的包，做研究用，行不行？从工具设计的角度，这个需求确实存在，但它有一个更安全的实现路径——研究未签名包的话，流水线中间产物本来就有：回编之后、签名之前的那个包就是未签名的。让「最终产物永远可用」成为不变量，把特殊需求留给中间产物，这个设计立场比「提供全不勾的选项」对用户更负责。

这里也体现了一个通用原则：约束放在越早的环节，代价越小。保存时拦，比打包时拦便宜；打包时拦，比装机失败便宜；装机失败，比「装上了但在某些设备上悄无声息地出问题」便宜。这一排勾选框的三条边界，全部拦在最便宜的位置上。

七、minSdk 是从哪来的：一份真实数据的旅程

前面反复提到「项目配置里的最低 SDK」，它值得一段完整的交代。这份信息的旅程是这样的：你把 APK 拖进新建项目页的时候，工具用工作目录里的解析工具读出包的基本信息——图标、应用名、包名、版本号、最低与目标 SDK、启动页组件。这些信息写进项目的配置文件，其中最低 SDK 这一项，就成了签名方案校验的数据源。

注意这个链路的性质：它读的是包的真实声明，不是你的记忆。人对自己应用的 minSdk 的印象经常是错的——尤其是接手别人的项目、或者一个维护了五年的老应用。工具不做假设，只认解析结果，所以它拦你的时候一定拦得有理有据。

这也提醒了一个实操要点：如果你的目标设备群里真的有 Android 7.0 以下的机器，出包前花一分钟确认两件事——项目信息里的最低 SDK 是多少、签名窗口里 v1 是否勾着。这两分钟的投资，换来的是「不会在客户车间的老平板上翻车」。行业物联网、政企定制机这些场景里，老设备比你想象的多得多。

八、工具版本那一问：先问清楚再递参数

这一节讲整个签名环节里最「 invisibly clever」的一段：工具版本兼容。签名不是程序自己算出来的，是调用一个叫 apksigner 的签名工具完成的。这个工具本身有版本：新的版本支持 v1 到 v4 全部方案，老的版本只认 v1 和 v2。如果你的机器上恰好是一个老版本，而你勾了 v3——直接把 v3 的参数递过去会怎样？老工具会回一句「不认识这个参数」，然后整次打包直接失败。这不是假设，是实测过的真实行为。

安卓修改大师的解法朴素而可靠：打包开始时，先问一次签名工具的版本。支持 v3、v4 就把四个开关都传过去；不支持，就只传 v1、v2，并且把「已跳过 v3、v4」明确写进打包日志和打包窗口的状态行。这样带来两个保证：第一，绝不会因为传了老工具不认识的参数而把整次打包搞挂；第二，你也不会误以为「勾了就是签了」——跳过了，它告诉你跳过了。

工具选择上还有一个细节：程序会优先在工作目录里找较新版本的签名工具，找不到才退回老的。认到哪一个，文件名会写进打包日志，「参数设置」页的工具检测里显示的也是实际选中的那一个。也就是说，你随时可以回答这个问题：「我昨天出的那个包，到底是用哪个版本的什么工具、按哪些方案签的？」——答案全在日志里。这种可追溯性平时无人问津，出问题的时候就是唯一的真相来源。

把这一节总结成一句话：你负责勾选意图，工具负责核实能力，日志负责记录事实。三层各司其职，签名这个环节才配得上「让人放心」四个字。

九、一个包能装多老，一张表说清

把方案与设备年代的对应关系压成一张表，需要的时候直接查：

方案	登场年代	不勾它的后果	默认状态
v1	Android 1.0 起	minSdk 低于 24 的包，Android 7.0 以下设备装不上	勾
v2	Android 7.0 起	新设备退回 v1 校验，安装变慢	勾
v3	Android 9 起	新设备用 v2 校验，密钥轮换能力不可用	勾
v4	配合 v2/v3 使用	增量安装场景不可用	不勾

读表的正确姿势是反过来读：先问「我的目标设备最老到哪一代」，再决定动不动这一排。默认三勾对绝大多数应用是最优解；只有明确知道自己在做什么的人，才需要改变它——这句话听起来像劝退，其实是工具设计者的本意：默认值照顾大众，开关留给懂行的人，边界规则替所有人把关。

十、实战例一：行业老平板上的签到应用

讲两个真实感强的例子。第一个：一家连锁门店的自家签到应用，2018 年开发，minSdk 是 21，装在门店一批 Android 5.1 的老平板上跑得好好的。这次要改的是把签到页的背景图换成新店庆海报，顺便把版本号抬一版。以前怎么做？开发改工程、配环境、出包、签名，还要专门找一台老平板回归测试。现在怎么做？包拖进智改工坊，需求写「签到页背景换成附件这张图，版本号抬一版」，附上图并写清用途，签名配公司的 jks。关键的一步来了：保存签名配置时，窗口读到项目的最低 SDK 是 21——低于 24——这时如果你手滑把 v1 取消勾选，保存会被直接拦下。没手滑？那就什么都不用做，默认的三勾正好是老平板需要的组合。

出包之后怎么验证？分两步。第一步在电脑上：打包窗口里校验那一步打印出签名指纹，说明签名本身成立。第二步在老平板上：覆盖安装一次成功、打开签到页看到新背景，说明 v1 生效、老设备认账。新设备测试通过不代表老设备通过，反之亦然——这就是多方案签名存在的全部意义。

十一、实战例二：调试期的增量安装实验

第二个例子是给自家应用做高频调试的场景。开发同学每天要改几十版、每版都装到测试机上验证，整包安装一次几秒钟，一天累积下来很可观。这个场景下增量安装有价值：只装改动的部分。要让包支持它，签名环节需要勾上 v4——系统会额外拿到一个 .idsig 文件配合增量安装流程。

操作上没什么玄的：打开「设置签名」，在 v2、v3 保持勾选的前提下加勾 v4，保存。第一次保存时如果你只勾了 v4，窗口会拦下来提示 v4 必须搭配 v2 或 v3——顺手就把规则复习了一遍。出包时，流水线照样四步走，签名工具会产出带 .idsig 的组合。验证方式：在测试机上按增量安装流程装一次，观察安装耗时明显短于整包安装，即说明方案生效。

这个例子还有一层价值：它演示了「开关的存在感」——v4 这种面向特定场景的方案，默认关闭、按需打开，用完这个调试项目把勾去掉，世界回到默认状态。工具没有为了炫技把它默认打开，也没有为了省事把它藏起来不给。开关的克制，是对默认值的尊重；开关的存在，是对长尾需求的尊重。两个尊重都做到，这排勾选框才算合格。

十二、勾选框之外：签名方案与打包日志的对照

前面埋了个问题：怎么确认「勾了的方案真的签上了」。答案是打包日志。每一次打包，用哪个版本的签名工具、传了哪些方案开关、有没有跳过 v3/v4、校验打印了什么指纹，全部逐行写在项目的打包日志里。这个日志不需要你天天读，但要知道它在那里、记得它记了什么——它是签名环节的「行车记录仪」。

一个实用的习惯是把日志和勾选状态对照着看一次。比如你勾了 v3，日志里签名那一步的参数里就有 v3 的开关；如果工具版本旧、跳过了 v3，日志里会有一行明确的「已跳过」记录。第一次看可能觉得啰嗦，但正是这种啰嗦构成了可审计性：三个月后有人问「这个包当时按什么方案签的」，你不需要回忆，翻日志就有。

顺带一提，这种「日志记全、话不多说」的风格贯穿整个打包流水线：回编记回编的、对齐记对齐的、签名记签名的、校验记校验的。签名方案只是其中与你今天这篇主题相关的一小段。等哪天你接手一个「历史包不知道怎么签的」的项目，这套日志会让你感激当初的设计者。

十三、三个高频误区，一次纠正

误区一：「方案越多越安全，全勾就完事了」。方案数量与安全性没有关系——四套方案表达的是同一个身份，系统只认它认识的最新一套。全勾 v4 的唯一效果是多一个用不上的文件。按需勾选，默认三勾已经是安全与兼容的最优平衡。

误区二：「新手机装得上就行，v1 早该淘汰了」。对纯新应用这话有一半对——v1 确实是历史包袱。但改包场景里太多应用带着老 minSdk、面向老设备群，v1 一天没有退役，勾着它就一天是保险。淘汰一项技术的权利在生态，不在你的项目里。

误区三：「签名失败肯定是我勾错了」。不一定。签名环节的失败有相当比例来自钥匙本身：口令不对、格式不对、文件被锁。方案勾选错误反而是少数——因为窗口的三条边界规则把最危险的组合都拦了。排查时先看失败发生在哪一步：卡在签名命令，查钥匙；卡在校验步骤，查格式；两步都过了还装不上，查方案与设备年代。按步骤定位，不要一上来就乱改勾选框。

十四、写给不同读者的行动清单

最后按身份给三份极简清单。如果你是纯新手：什么都别动，默认三勾直接用；唯一要记住的是「别在项目信息显示 minSdk 低于 24 的时候取消 v1」——虽然窗口也会拦你，但知道为什么总归更好。

如果你管着面向老设备的行业应用：出包前三查——项目最低 SDK、v1 勾选、目标设备群里最老的系统版本。三查通过，这个包在新老设备上就都立得住。有条件的话留一台最老的设备做装机回归，它是你的兼容性底线守门员。

如果你是做调试与实验的进阶玩家：v4 按需打开，用完关掉；每次改完方案开关，出包后把日志里签名那一段扫一眼，确认「意图、参数、结果」三者一致。这个动作做十次就会变成肌肉记忆，而它会替你挡掉所有「我以为签上了」的事故。

一排四个勾选框，背后是安卓十几年的兼容史、三条边界规则、一次版本探测和一份完整日志。下次再打开「设置签名」窗口，希望你看到的不是四个陌生的名词，而是四段清晰的设备年代坐标——以及一个替你把所有坑都提前标好的、值得信任的工具。懂得越多，越能体会默认值的恰到好处。

十七、装不上时的读法：三种症状对照签名方案

签名方案选错的表现很分散，最容易踩坑的是它几乎从不直接说「签名方案」四个字。把三种典型症状和它们的签名成因对上号，排查时间能省一大截。

症状一：老设备提示「无法解析安装包」或安装直接无反应。新手机装同一个包一切正常，只有某台老设备不认。九成是 minSdk 与 v1 的组合问题：包的最低系统版本低、v1 却没签上，老系统找不到它能认的签名。读法：先看项目信息里的最低 SDK，再看签名窗口 v1 的勾选状态——两分钟定位。工具的提前拦截管住了「保存时」，但如果你拿到的是别人出的历史包、或者设备比预想的还老，这个症状仍会出现在装机环节。

症状二：装机报「没有证书」一类的解析错误。这类报错说明系统在包里找不到任何它能认的签名方案。可能的原因比症状一更基础：出包时签名这步压根没成功，或者拿的是流水线里签名之前的中间产物。读法：回到打包窗口和打包日志，确认签名、校验两步是不是都是绿的、指纹有没有打印出来。日志是这类问题的终审法官。

症状三：覆盖安装被拒、提示签名不一致。这个症状和方案勾选无关——它是钥匙的问题，上一篇讲过。列在这里是为了完整：装机失败的原因无非「钥匙不对」和「方案不认」两个家族，前者表现为覆盖失败，后者表现为解析失败。把两个家族分清，你就不会在错误的清单里翻半天。

最后提醒一个容易忽略的变量：测试设备本身的系统版本。排查时永远先问「这台设备是什么年代的系统」——同一台老平板刷过机的、同一批定制机系统被裁剪过的，认签名的行为都可能出乎意料。方案是死的，设备是活的，对照着设备读症状，才不会冤枉了打包工具。

十八、v3 的密钥轮换：什么时候真的需要它

前面把 v3 讲成了「新设备优先认的方案」，但它名字里最有分量的能力——密钥轮换——值得单独一节。先用人话解释轮换是什么：应用换签名钥匙，通常等于换身份，老用户必须卸载重装；v3 的轮换机制允许新钥匙携带旧钥匙的「授权链」，系统验签时顺着链条确认新旧是一家，升级通道因此不断。

什么场景真的需要它？第一类，钥匙疑似泄露：签名文件外流过、经手人离职、机器送修过，出于审慎要换钥匙——直接换会让全部存量用户断更，轮换是唯一体面的路。第二类，公司主体变更：产品从一个法人转到另一个法人，钥匙必须换，用户不能丢。第三类，钥匙太老：十年前生成的密钥强度在今天看已经偏弱，趁版本节点升级。

轮换怎么操作？这里要说实话：完整的轮换是新旧两把钥匙协同的动作，属于「应用发行方的一次正式工程」，不是改包工具里点一下的事。安卓修改大师电脑版在这个流程里的位置是后半程——新钥匙确定之后，用它持续出包、验证指纹、保持 v3 勾选，让新设备读到带轮换信息的签名。前半程的钥匙交接与登记，由你的团队按发行流程完成。

判断「现在要不要折腾轮换」可以问自己三个问题：钥匙有没有可能已经不安全？换钥匙的窗口期近不近（比如大版本更新）？存量用户多不多？三个答案都是「否」，安心用默认；有一个「是」，就该把轮换排进计划了。轮换是保险，不是日常保养——分清这两件事，v3 对你才既不神秘也不焦虑。

十九、同包异签实验：一张桌子看清方案差异

想把四个方案的差异从「知道」变成「看见」，有一个成本极低的实验：拿自家一个测试应用，同一份工程、同一把钥匙，按不同的方案组合各出一次包，观察它们在不同设备上的表现。这个实验不需要任何特殊工具——「设置签名」改一次勾选、「去打包」空跑一次，两三分钟一轮。

建议的实验矩阵：第一轮默认三勾，作为基准；第二轮只勾 v1，装到新设备上对比安装耗时——你会直观感受到 v1 逐文件校验的慢；第三轮 v1 加 v2，老设备新设备各装一遍；第四轮加勾 v4，看看项目目录里多出来的那个独立签名文件长什么样。四轮下来，「系统按它认得的最新方案校验」这句话就从抽象变具体了。

实验中最有教学价值的观察点在老设备上：只勾 v2 的包装进 Android 6.0 的设备，报错的样子和「包损坏」一模一样——你终于亲眼见到那个传说中的坑，而不是听别人转述。带团队的朋友强烈建议做一次这个实验，十分钟的现场演示胜过一小时的文档宣讲，新人从此不会犯「随手取消 v1」的错误。

做完实验记得把四个包和它们的打包日志一起归档——这是你团队自己的「签名方案对照标本」，以后遇到装机疑难，翻出来比对一下现状落在哪一格，排查就有坐标系了。知识可以读来，手感只能做来，这个实验就是攒手感的最低成本路径。

二十、三分钟自检 SOP：出包前的最后一遍

全文收束成一张可以贴在屏幕边的流程卡。出正式包之前，按顺序过五步，总共不超过三分钟。

第一步，看项目信息：最低 SDK 是多少？目标设备群里最老的设备是什么系统？两相对照，v1 去留立判——低于 24 的最低 SDK，v1 必须在。

第二步，看签名窗口：模式是预期的那个吗（默认 / jks / pem / 随机）？方案勾选是预期组合吗？有不确定的，回到默认三勾，它覆盖九成九场景。

第三步，空跑一次：点「去打包」，让流水线完整走一遍。看签名那一步的状态行——它显示的模式名和你预期一致吗？看校验那一步——指纹打印出来了吗？

第四步，扫一眼日志：签名工具用的哪个文件、传了哪些方案开关、有没有「已跳过」的字样。异常不用背，有疑问翻日志，这一步只是确认日志存在且完整。

第五步，装机验证：最老的一台目标设备装一次、最新的一台装一次。两头都过，这个包的签名环节就盖章通过。

五步走完，签名相关的风险基本清零。有人觉得仪式感太重——其实五步里三步只是「看」，真正花时间的就是一次空跑和两次装机。用三分钟买一个「这包到哪儿都装得上」的确定性，是整个改包流程里性价比最高的一笔交易。流程的意义从来不是约束人，是替人记住那些偶尔才用一次的知识。

这份自检流程还有一个隐藏好处：它给了团队一份共同语言。当同事说「我按第三步空跑过了」「第五步老设备没过」，所有人立刻知道问题定位到哪一层。流程跑得多了，新人会在某天突然发现自己已经不需要看卡片——那不是记性变好了，是肌肉记忆长出来了，卡片功成身退，留作新人教材。

二十一、回头看得更远：一排勾选框里的碎片化史

如果给「为什么会有四个签名方案」找一个根本原因，答案只有四个字：碎片化。安卓是开放的系统，设备厂商、系统版本、出厂年代各不相同，一个今天上架的包，完全可能明天就被装进一台十年前的手机。签名方案必须照顾这条完整的时间轴，于是每一代都只能「加新不改旧」：v2 登场，v1 不能废，否则七年的设备一夜变砖；v3 登场，v1、v2 都要留着。四代方案共存，不是设计的冗余，是对现实的低头。

把这条时间轴在脑子里过一遍：2016 年 Android 7.0 带着 v2 出现，那时市面上还有大量 4.x 的设备在服役；2018 年 Android 9 的 v3 来的时候，7.0 以下的设备存量依然可观；今天你出包，这条时间轴的每一站都还站着真实用户——行业平板、定制终端、长辈的旧手机。勾选框上每一个勾，对应的就是时间轴上还站着人的那一段。

碎片化还有另一层后果：它让「最正确的配置」这件事不存在。只服务新旗舰的应用，理论上 v2 加 v3 就够；照顾全时间轴的应用，v1 一步不能省。所以工具的默认值只能选「对最多人安全」的组合，而把微调的自由留给知道自己在哪一段时间轴上的人。理解了这一点，你再看默认三勾，看到的就不是随意的设定，而是一次对整个安卓生态的妥协与权衡。

顺带也能回答一个延伸问题：将来会不会有 v5？完全可能——只要安全研究者继续找到新攻击面、设备性能继续提升，签名方案就会继续演进。但演进的方式大概率还是「叠加」而不是「替换」。所以这一排勾选框将来可能变成五个、六个，你今天建立的理解框架——每一代方案服务一段设备年代、多套并存、系统取最新——依然适用。学的是框架，不是清单，清单会过时，框架不会。

二十二、问答六连：剩下的小疑问一次清空

问一：我改完包后没动过任何勾选，还需要看这一篇吗？需要，但只需要记住一件事：默认三勾照顾你，唯一危险动作是取消 v1。把这一句带走，本篇的使命就完成了一半；剩下的一半，留给某天你真的遇到老设备装不上包的时候再来翻。

问二：勾选状态会影响 AI 改包吗？不会。方案勾选只作用于打包阶段的签名一步，AI 改的是工程内容，两者不在一条时间线上。改十轮需求、签十次包，勾选状态始终如一，除非你自己去改它。

问三：同一个项目，方案勾选和签名模式（默认、jks 那些）是什么关系？一个是「用哪把钥匙」，一个是「按哪些方案盖章」。两个选择相互独立，都存在项目配置里，都按项目记忆。四把钥匙乘四种方案组合，理论上十六种搭配，实际常用的就那么三四种——钥匙按身份选，方案按设备年代选，各管各的。

问四：装到设备上以后，能查这个包签了哪些方案吗？能，设备侧有对应的查询命令，开发者选项里也有显示签名的入口。但日常验证不建议跑到设备那头查——电脑这边打包日志和校验输出已经给了答案，跨到设备端查属于舍近求远，留给疑难杂症时再用。

问五：v4 那个独立签名文件，打包完应该怎么归档？用增量安装的调试项目，把它和包放在同一个目录归档；不用增量安装的项目，它压根不会产生。它永远不是「主产物」，别让它混进交付清单——对外交付的永远只是那个包本身。

问六：看完还是不确定自己该勾哪些，怎么办？用默认三勾出包，然后做一次双端装机验证（最老设备加最新设备各一台）。两头都过，就闭眼继续用；有一头不过，回来按第十七节的症状表定位。这套「默认值加双端验证」的笨办法，能覆盖你职业生涯里遇到的几乎所有签名方案问题——工具已经把专业判断做成了默认值，你要做的只是别乱动它，再偶尔验一下货。

二十三、一次升级的价值：签名工具版本变了之后

本篇第八节说过，签名工具有新旧两代：老的一代只认 v1 和 v2，新的一代支持到 v4。这就带来一个现实问题——工具链是会升级的，你的勾选习惯要不要跟着变？把这件事的来龙去脉讲清楚，你就能从容应对工具目录里的任何一次更新。

先看升级怎么发生。签名工具躺在工作目录的 tools 子目录里，程序找它的时候会优先认较新的那一代文件，找到哪个用哪个，用哪一个写进打包日志。这意味着升级的动作可以朴素到「把新工具包放进 tools 目录」——不需要卸载、不需要登记，下次打包自动生效。而「参数设置」页的工具检测行显示的，就是当前实际选中的那个文件名：升级前后各看一眼，变化一目了然。

升级之后你会注意到的第一个差异，是 v3、v4 从「可能被跳过」变成「正常签上」。如果你之前在旧工具上勾过 v3，日志里躺着「已跳过」的记录；换上新工具后同样的勾选，签名参数完整传递、不再有跳过字样。这种「同一份配置、不同的执行结果」正是版本探测机制存在的意义——它让新旧工具都能安全干活，也让每一次差异都有据可查。

反过来，降级场景同样被照顾到了：如果哪天 tools 目录里只剩老一代工具（比如从旧机器整体搬迁时漏拷了文件），你勾着 v3 的配置也不会把打包搞挂——程序探测到工具不支持，自动只传 v1、v2 并明说跳过了什么。配置表达意图，工具核实能力，日志记录落差，三层机制在升升降降之间始终护得住你。

给团队的操作建议：工具目录更新之后，找一个项目空跑一次打包，把日志里签名那一段存档。这份「升级后首签」的日志，既是新工具就绪的证明，也是以后排查问题时的基线样本。工具链升级最常见的翻车不是升坏了，而是「升了没人知道、新旧混着用」——一份存档日志，就是消除这种混沌的最便宜手段。

二十四、用户怎么说

粗略统计一下用户勾选习惯：长期保持默认三勾的约占八成五，为老设备特别关注 v1 的约一成，动过 v4 的不到半成——最后这半成几乎全是高频调试场景的重度用户。分布形状本身就是这排开关设计合理性的注脚。

二十五、写在最后

签名方案这一排勾选框，是整个改包流程里「看起来最技术、实际上最讲道理」的地方。每一代方案的登场都是为了解决上一代的问题，每一条默认值和边界规则都对应着一段真实的兼容历史。安卓修改大师电脑版把这段历史压缩成四个勾选框，又用校验、探测和日志把它撑开成一层层看得见的保障。

安卓修改大师智改工坊家族还有两位成员：智能修改安卓版装在手机和平板上，走到哪儿改到哪儿；经典版把反编译树完整摊开，资深玩家逐层动手。三兄弟的介绍页都在这里：https://www.apkeditor.cn/ai-version.aspx。只需说话，就能让应用变成你想要的样子。