拆不开的包：分卷包与加固包，各自卡在哪一步

改包改到一定阶段，会遇到两类「拆不开」的包。一类下载下来是好几个文件，或者后缀不是常见的那个；另一类只有一个文件，能装能用，但拆开之后看不到真正的代码。

这两类的处理方式完全相反。前者通常能改，只是步骤多几步；后者基本改不动，而且要尽早认出它，免得在上面白花时间。把它们混成一件事，是最常见的浪费。

这篇文章想把这两条路分清楚：分卷包长什么样、怎么改、改的时候容易在哪一步出错；加固包有哪些一眼能认出的特征、遇到它时哪些事还能做、哪些事真的做不了。

只需说话，就能让应用变成你想要的样子。在「安卓修改大师智改工坊」里，常见的包型都能直接反编译成可编辑的工程——不用自己去拆、去拼、去对齐。它知道一个包是怎么组织的，你只需要说清要改什么。想先看看手里的包属于哪一类，可以从 https://www.apkeditor.cn/ai-version.aspx 下载智改工坊，拖进去看它能不能正常展开。

一、先分清：一个文件，还是一包多份

最直观的区别在文件名。一个文件的情况，后缀就是那个最普通的，双击能装，体积一个顶全部。一包多份的情况，后缀会变成另外几种，或者干脆是一个压缩包，里面装着几份。

为什么要拆成多份？因为一个应用里有些东西是「所有设备都一样」的，有些东西是「只有特定设备才需要」的。把后者单独拆出来，每台设备只下载自己需要的那份，整体下载量就小了。这是拆分唯一的目的，也是它唯一的价值。

拆的维度通常有三个：处理器架构（不同芯片要不同的机器码）、屏幕密度（不同清晰度要不同尺寸的图）、语言（不同地区要不同文案）。一份包按这三个维度切，就能切出很多组合。

实际的做法通常是切一刀或两刀，不是全切。常见的组合是「一个所有设备都要的主包，加上每种架构一份、每种高密度一份」。主包里放着代码、清单、通用资源；分出去的包里放着针对性的那部分。

所以判断一个包能不能改，第一步不是看它有多大，而是看它是不是一份。如果是一包多份，改的时候就要先想清楚：我改的那个东西，到底在主包里，还是在某个分出去的部分里。

二、分卷包的三层结构，和「改哪一份」这个问题

把一包多份拆开看，通常能看到三层。

第一层，主包。它里面一定有代码、清单、以及大部分通用资源。这是必改的一层——应用名、版本号、权限、大部分文案和图，都在这儿。

第二层，按架构分的那几份。每份里只有那份架构的原生库。这一层在改包时很少需要动，除非你要换掉某个底层库。但它有一个特性会让很多人吃亏：这些分出去的包里，偶尔也会带资源。

第三层，按密度或者按语言分的那几份。里面是针对性优化的资源。这一层是「改了没变」的高发区——你改的是主包里的那一份，而设备实际加载的是分出去的那一份。

于是就出现了第一个坑：改了主包，界面上没变化。原因不是没生效，是生效了但不是设备用的那一份。这种情况在分卷包上比在单包上更常见，因为「同一份资源分散在多个包里」这件事被结构放大了。

判断方法：改了没变的时候，先确认这台设备会不会加载某个分卷。如果会，就去那个分卷里找同一个名字的资源，一起改掉。

三、三种常见的分卷格式，差别其实只有一层

最后补一句关于「分卷包能不能改成单包再发」的判断标准：看接收方是不是同一批设备。是，就合；不确定，就保持分卷，两步路而已，别图省事给自己留隐患。

分卷包有好几种后缀，很多人以为它们是三种不同的技术。实际差别比想象的小——底层结构都是「一个主包加若干分卷」，区别主要在「外面套了什么」和「名字怎么写」。

后缀	结构	关键差别
apks	一个压缩包，里面装着主包和各个分卷	分成多份，每个文件本身还是标准结构
xapk	同上，另外附带一个说明文件	多一个描述信息，记录了每份是什么
apkm	同上，但外层用了自己的封装	需要按它的方式拆，不能直接当压缩包打开
单包	就是一个文件，没有分卷	最常见，也最容易改

这张表里最值得注意的是最后一行。「单包」不是一种格式，它是「没有分卷」这个状态。很多人把后缀当成技术难度，其实难度不来自后缀，来自「有没有分卷」。一个后缀很陌生的包，如果内部只有一份，改起来和最常见的包没有区别。

所以判断顺序应该是这样：先看解开之后是一份还是多份。一份，按普通包改；多份，就要按分卷包的路子走。后缀只用来决定「用什么方式解开」，不用来判断难度。

还有一个经常被问到的问题：能不能把分卷包合成一个单包？技术上可以，把各份里的内容合并到一起，形成一个所有设备都能用的包。但这样做体积会变成各份之和——分卷的目的本来就是「每台设备只拿自己需要的」，合并等于把这个好处还回去。

什么时候合并才合理？当你要把包发给一批「设备型号已知且一致」的用户时。比如某个门店的一批手持机，架构和屏幕都一样，那分卷就没意义了，合成一个包反而更省事——只留它们需要的那份架构和那档密度即可。

反过来，如果分发对象是未知的，就不要合并。你不知道对方用的是什么设备，合并之后那些用不上的部分就变成了纯粹的下载负担，而这正是分卷想解决的问题。

四、改分卷包的正确顺序

分卷包的改动流程和单包只差一步，但这一步的位置很关键。

第一步，整体解开到外层。先把最外面的封装打开，看到里面有几份。这一步不要急着改，只是看清楚结构：主包叫什么、分卷分别叫什么、有没有说明文件。

第二步，解主包。把主包单独反编译成可编辑的工程。改动的主要战场在这里——应用名、图标、文案、代码、大部分资源。

第三步，判断要不要动分卷。这一步是分卷包特有的。判断依据：你要改的那个东西，会不会有分卷里的版本。图片（按密度分）、文案（按语言分）、原生库（按架构分）这三类都有可能。

第四步，改完重新打包。主包重新打成一份，分卷保持原样（如果你没动它们）。注意这里有个细节：重新打出来的主包，体积和结构可能和原来不完全一样，这是正常的，因为编译过程会做对齐和重新组织。

第五步，重新签名。这一步和单包一样，但要注意每一份都需要签——不是只签主包。有些工具会漏掉分卷，结果装的时候报「包不完整」。

第六步，重新组装成外层。把改好的主包和分卷按原来的结构放回去，保留说明文件。说明文件不要动，它记录了每份的用途，改了可能装不上。

这七步里，第四步和第五步之间有一个很容易被忽略的细节：改完之后主包的体积可能变小，也可能变大。变小通常是因为原来的包里有冗余内容，重新编译时被清掉了；变大则可能是因为新增了对齐填充。两者都不说明问题，判断标准只有一个——装上去之后改动点对不对。

还有一点：重新组装的时候，各份的顺序和目录结构要尽量和原来一致。有些设备的安装器会按文件顺序处理，顺序变了虽然理论上不影响，但会引入不必要的变量。拿到原包之后第一件事，就是把它的结构记下来，改完之后照着放回去。

第七步，装机验证。这一步分卷包更需要认真，因为「改了没变」的概率更高。建议在两台不同架构或者不同密度的设备上各装一次，确认改动能覆盖到。

五、第一个实例：改了主包，平板上的字还是旧的

自家一个门店点单端，发出去的是分卷包。需求：把首页那句欢迎语改掉，另外换掉顶部横幅图。

按单包的习惯，解开主包、改文案、换图、重新打包、签名、装到手机上。手机上看，都对。

拿到平板上装，欢迎语变了，横幅图还是旧的。这就是典型的「改了没变」，而且只在一种设备上出现。

原因在结构上：这个包按屏幕密度分了卷，平板的密度更高，它加载的是高密度那一卷里的横幅图。我们改的是主包里那份通用的，平板根本没读它。

处理方式：把高密度那一卷也解开，找到同名的横幅图，换成同一张新的，重新组装。注意这一卷也要重新签名——这一步当时漏了，装的时候报了一次「包已损坏」，回头补上才通过。

这件小事花了两个小时，其中真正改图的时间不到十分钟。剩下的一小时五十分钟，花在「为什么只有平板不对」这个问题上。

从那以后这个项目多了一条检查项：改动之前，先把所有分卷都解开列一遍，看要改的名字在几个地方出现。这个动作十分钟，但它把「只有某类设备不对」这类问题基本消灭了。

这条检查项还有一个附带的好处：它会让你顺便发现那些「分卷里有、主包里没有」的资源。这些资源如果你改主包，永远不会生效——而在列表上，它们一目了然。

六、另一类「拆不开」：加固包

分卷包的「拆不开」是相对的——多花几步总能改。加固包的「拆不开」是绝对的：能装、能用、能拆开看到目录，但拆开之后看不到真正的业务代码。

加固的思路很直接：把原始的代码加密，再在外面套一层解密和加载的逻辑。应用启动时，外面那层先把代码解密到内存里，再交给系统去执行。所以包里的代码目录只有那一小段「解密加载」的代码，体积很小。

这样做的目的是防逆行——防止别人把应用拆开、看懂逻辑、改掉校验、或者抄走实现。从保护开发者的角度看，这是一件正当的事。

它带来的副作用是：所有常规的改包手段都会失效。因为你改的那些东西——文案、布局、代码里的字符串——大概率在加密的那部分里，而包里根本看不到它们。

这里要区分两个容易混的概念：加固和混淆不是一回事。混淆只是把代码里的名字改成不可读的短字符串，逻辑还在、结构还在、能反编译出来；加固是把整段代码加密，拆开之后根本看不到。前者改包时只是看着累，后者才是真的改不动。判断方法：混淆过的包里代码文件还是好几个、体积正常；加固过的包代码文件少而小。

这一节的重点不是「怎么破」，而是怎么尽早认出来。因为加固包上花的时间，几乎全是白花——而识别只需要五分钟。

七、五个一眼能认出的特征

加固包有几个很稳定的特征。看到其中两三个同时出现，基本就可以停下了。

第一个，代码目录很小，而且只有一个。正常应用有几个代码文件很常见，加固之后通常只剩一个，体积还有一个很明显的特征：几兆甚至几百 K。因为大部分代码不在这里。

第二个，多出几个叫不上名字的原生库。正常应用的原生库一般是三方组件带进来的，名字能对上某个产品。加固之后常会多出一两个、名字像随机字符串的库文件，那就是解密加载器。

第三个，清单里的入口被换掉了。看清单里应用启动时调用的那个类，正常一般是自家包名下的主界面或者应用类；加固之后往往指向一个陌生的类名，那个类是外面那层壳。

第四个，assets 里有可疑的二进制文件。加密后的代码通常以数据文件的形式放在这里，名字可能是几个字母、也可能是某个看起来像普通资源的名字，但体积明显偏大。

第五个，资源里的业务文案不全。拆开之后能看到的字符串，大多是通用提示、错误码、系统级文案；而界面上一句具体的业务描述却搜不到。这说明业务层的东西被加密了。

这五个特征还有个用法：它们可以当成一张入职清单。让新接触这件事的人先看五个包，判断哪些是加固的，再对答案。三五次之后，这个判断会变成一种直觉——耗时不到十秒，但能省掉一整天。

这五个特征里，第一个和第三个最好判断，也最不容易误判。如果这两条同时成立，基本可以确定是加固包，不用再往下试。

八、遇到加固包，还有哪些事能做

「改不了」不等于「什么都做不了」。有些层面确实还能动，只是范围很小。关键是要分清「哪个层面在壳外面」。

能做的第一件：外层清单里的一些属性。应用名、图标、版本号这些通常在壳外面，改它们不影响里面的加密内容。但要注意，改完之后壳自己可能会校验——有些加固会在启动时检查自己的包有没有被改过，一旦发现就直接退出。

能做的第二件：壳外面的资源。如果能拆开看到资源目录，那里面那些通用文案、图标、背景图，理论上是可以换的。判断方法：改了之后装上看有没有变化。变了，说明它在外面；没变或者应用直接退出，说明它在里面，或者壳有校验。

能做的第三件：什么都不改，只做分析。有时候需求不是「改」，而是「搞清楚这个包用了什么」——用了哪些三方组件、申请了哪些权限、有哪些后台地址。这些信息在清单和资源里就能看到，不需要动代码。

不能做的：改业务逻辑、改界面文案、加功能。这些都在加密的那一层里。任何声称能改的说法，本质上都是要去掉加固——那是另一件事，不在「改包」的范围里。

还有一个常被误解的点：加固不等于这个包不能改，而是「能改的范围很小」。换个说法——壳外面的那一层，还是一个正常的包。所以遇到加固包，正确的问法不是「能不能改」，而是「我要改的那个东西在哪一层」。在壳外面，改；在壳里面，换路。

所以遇到加固包的正确答案是：先花五分钟确认它是不是加固，是的话就去和需求方确认「能不能拿到未加固的版本」。这是唯一省时间的路。

九、为什么加固包里还能看到一点点代码

第一次拆加固包的人常有一个疑问：不是说加密了吗，怎么还能看到一个代码文件，里面还有内容？

因为外面那层壳必须存在。壳本身不能加密自己——它要在应用启动的第一时间运行，而那时候还没有任何东西可以解密它。所以壳只能是一段明文的、正常的代码。

你在代码目录里看到的那个文件，内容就是这段壳：找到加密的数据、调用解密、把结果交给系统、然后跳转到真正的入口。它的逻辑很简单，但它是整个应用能不能起来的关键。

这也解释了一个现象：加固包里能搜到的字符串，几乎全是壳自己的提示。比如解密失败、校验不通过、环境异常这类。这些提示和业务无关，改它们没有意义，而且改了可能触发壳的自我保护。

所以看到「能看到代码，但里面全是看不懂的加载逻辑」，这本身就是加固的一个强信号。它比任何其他特征都直接——因为正常的应用，代码文件里应该是业务逻辑，而不是一段加载器。

十、七个问题，分包和加固都问过

一、分卷包能不能只改主包，其他不动？

大多数情况可以。如果改的东西在主包里，而且分卷里没有同名版本，那只改主包就行。但如果改的是图片、文案、原生库这三类，就要先确认分卷里有没有对应的版本——有的话必须一起改，否则会出现「某些设备上是新的、某些还是旧的」。

二、分卷包重新打包之后，体积和原来不一样，正常吗？

正常。重新编译会重新组织包内部的结构、重新对齐、重新压缩，体积差个几百 K 到几兆都很常见。只要不是大比例缩小（比如从四十兆变成二十兆），就不用担心。大比例变化通常意味着有内容被漏掉了。

三、改了分卷，但只签了主包，为什么会报「包已损坏」？

因为每一份都需要签名。分卷包里，各份都是独立的包，各自有各自的签名封条。只签一份，其他几份的封条还是旧的或者是空的，安装时就会被判为不完整。这是分卷包最容易漏的一步。

四、加固包改完应用名，为什么一打开就退出？

因为壳在启动时会检查自己的包有没有被改过。这类校验是加固的一部分，目的就是防改。有些加固允许改清单里的一些属性，有些不允许——这取决于它用的校验策略。遇到这种情况，不要继续试别的改法，去确认能不能拿到未加固的版本。

五、怎么快速判断一个包是不是分卷包？

看解开之后有几份。一份是单包，多份是分卷包。另外看有没有说明文件——分卷包通常带一个记录各份用途的文件。后缀只能作为参考，不能作为判断依据。

六、加固包能不能只换图标？

有时候可以。图标属于资源，通常在外层，改它不一定触发壳的校验。但这个「不一定」是关键词——有些加固会校验整个包的完整性，改任何一处都会退出。试一次就知道：改完装上，能打开就说明可以。别在不确定的情况下批量改。

七、为什么分卷包里有些资源在主包里搜不到？

因为它在某个分卷里。这类资源的特点是「只有特定设备需要」——比如某个高密度专用的图、某种架构专用的库。如果需求是「所有设备都要改」，那就要把主包和各分卷都翻一遍。

十一、拿到一个陌生包，五分钟判断它属于哪一类

下面是实际会用的判断顺序。每一步都有一个明确的「是」或「否」，走完就能得出结论，不需要靠猜。

步	看什么	结果	下一步
1	能不能正常解开成目录	能	看代码目录有几个文件
2	代码目录是否只有一个且很小	是	大概率加固包，看第 3 步
3	清单入口是否指向陌生类名	是	确认是加固包
4	解开后是否有多份	是	分卷包，看第 5 步
5	要改的东西在分卷里有没有同名版本	有	主包和各分卷都要改、都要签
6	以上都不是	—	按普通单包处理

这张表最有用的是第 2 步和第 3 步。它们只用看两个地方：代码目录的文件数、清单里的入口类名。这两处任何一个有异常，就值得停下来确认，而不是继续往下改。

第 5 步是分卷包上最容易漏的。「有没有同名版本」这个问题听起来简单，但实际要搜四五个地方——主包加每个分卷。这个动作十分钟，但它决定了你是改一次还是改三次。

整张表走完，正常情况下不超过五分钟。而它避免的是那种「改了两小时才发现根本改不了」的情况——那种浪费不是时间上的，是心态上的。

把这张表背下来没必要，但前两步要形成条件反射：看解开之后有几份、看代码目录有几个文件。这两个动作加起来不到一分钟，而它们决定了后面两小时是在做事还是在转圈。

十二、什么时候应该停下来

这一节讲的是「止损」。改包这件事最大的浪费，不是改错，是在改不了的东西上反复尝试。

信号一：改完之后应用直接退出，没有任何报错。这不是「改坏了」的常见表现——改坏了通常会在某个页面崩，而不是启动即退。启动即退最可能是完整性校验，也就是包被判定为「被动过」。

信号二：同一个改动，第二次装就失效了。正常改动不会这样。出现这种现象，说明有某种东西在运行中重新校验或者重新覆盖——常见于加固壳，也见于某些自带更新检查的应用。

信号三：代码目录里搜不到任何业务词汇。如果这个应用界面上有几十句具体的业务文案，而代码里一句都搜不到，那业务层不在你能看到的那一层里。这时候继续搜是没意义的。

信号四：需求方说不出这个包的来源。这一条听起来不像技术信号，但它最实用。如果没人知道这个包是谁打的、用的什么工具、有没有加固，那你能做的只有「试」——而试的成本，往往高于去问一句。

停下来之后做什么？不是放弃，是换一条路：去找未加固的版本、去找打包的人、或者把需求改成「只做分析」。这三条路都比继续硬试要快。

止损这件事说起来容易，做起来难。原因是「已经花了两小时」这个事实本身会推着你继续花下去——人会不自觉地想「都到这一步了，再试一下说不定就成了」。而这恰恰是判断力最差的时候。

一个对抗这种心理的办法：在动手之前，先写一句「如果出现什么现象，我就停」。比如「如果改了三次都没变化，就停下来确认结构」。把停止条件写在前面，比在过程中临时判断可靠得多，因为写的时候你还没有沉没成本。

这条经验值得写进任何一份改包流程里：先确认能不能改，再确认怎么改。顺序反了，就会在不能改的东西上花掉一整天。

十三、五个听着有道理、其实是错的判断

这一节列的是这个领域里最常见的五个错误判断。它们的共同点是：听起来很顺，但会把你带到错误的方向。

第一个：包的后缀陌生，所以很难改。错。难度不来自后缀，来自有没有分卷、有没有加固。一个后缀陌生但结构简单的包，改起来和最常见的包一样。

第二个：分卷包就是把一个包切成几份，改一份就行。错。每一份都是独立的包，各自有各自的资源和签名。「改一份就行」这个想法，是分卷包上返工的主要来源。

第三个：加固包只是把代码藏起来了，找到藏的地方就能改。错。藏起来的部分是加密的，而且解密逻辑在壳里、壳还有校验。这不是「找一找」的问题，是「有没有钥匙」的问题。

第四个：改完装上能打开，就说明改成功了。不够。能打开只说明签名和结构没问题。真正的验收是「改动点变了，而且别的没变」——很多人只看了前半句。

第五个：两个包内容一样，改哪个都行。错。如果这两个包是不同分卷，它们面向的是不同设备。改错了那一份，现象是「我这儿是新的，别人那儿是旧的」——而且极难复现，因为你手上那台设备恰好是对的那种。

这五个判断里，第五个是最难自查的。因为它不表现为「错了」，而表现为「看起来成功了」。对抗它的办法只有一个：验收时换设备。只要换一台参数不同的机器，这个错误立刻现形。

这五个判断的共同点是：它们都让你「少做一步」。少做的那一步，往往就是确认结构的那一步。而这一步恰恰是最便宜的——五分钟，看清楚有几份、有没有加固、要改的东西在哪一层。

十四、一次踩坑记录：改了两小时，其实不该改

这件事发生在一个外部合作方发来的包上。需求是「把首页那句宣传语换掉」。

拿到包，看一眼后缀，不认识。解开，是一个压缩包，里面有几份。判断：分卷包。于是按分卷包的路子开始走。

主包解开，搜那句宣传语——搜不到。以为在代码里，去代码目录搜，也搜不到。

再解开两个分卷，搜同样的词，还是没有。到这一步已经有点不对劲了——三句文案的地方都搜不到，说明它不在资源里，也不在能看到的代码里。

接下来又试了一轮：改了资源里那句最接近的文案，打包、签名、组装、装机。界面上没变化，但应用打开时闪了一下就退了。

这时候才回头去看代码目录——只有一个文件，八兆。一个正常的、功能这么全的应用，代码不可能只有一个文件。再看清单里的入口，指向一个陌生的类名。

结论很清楚：这是加固包。前面两个多小时里做的所有事，都是在壳的外面转圈，而需求要改的那句话在壳里面。

后来联系合作方，问「有没有未加固的版本」。对方说有一版内部测试用的，没加固。拿到之后，十分钟改完。两个多小时对比十分钟，差别只在于「先花五分钟确认它属于哪一类」。

这条流程执行下来还有个额外的好处：它把「能不能改」这个问题，从技术问题变成了一个可以提前问的问题。在「安卓修改大师智改工坊」里，这一步更直接——把包拖进去，能正常展开成可编辑工程的就是能改的，展不开或者展开之后明显不对的，工具会先把问题暴露出来，而不是让你改完才发现白做。

这件事之后我们改了一条流程：凡是外部来的包，第一步不看需求，先花五分钟判断它能不能改。不能改的，立刻回去沟通，不进入改的动作。这一条让「白干」这件事基本消失了。

十五、分卷包上最常见的三个报错

分卷包出错时，报错信息和单包不太一样。三个最常见的，各有明确的原因。

第一个：包已损坏。分卷包里出现这个，八成是「签了主包，没签分卷」。因为每一份都是独立的包，各需要自己的封条。检查方法：把每一份单独验一次签名，看哪一份没有。

第二个：缺少所需的资源。这个报错说明结构上少了一份。常见原因是组装的时候漏了某个分卷——尤其是那些名字很相似的分卷，比如两个都以数字结尾，很容易拿错或者漏一个。检查方法：把各份列出来，和原始包的文件清单一一对。

第三个：应用未安装。和单包一样，多半是签名对不上。但分卷包多一种可能：各份之间的版本标识不一致。比如主包是新的、某个分卷还是旧的，系统会判为不匹配。所以重新打包时，每一份都要用同一轮的输出，不要混用。

这三个报错有个共同的排查方法：把「改前」和「改后」的文件清单并排对一遍。少了哪个、哪个名字变了、哪个大小差得离谱，一眼就能看出来。这个动作比读报错原文有效得多，因为报错只说「有问题」，清单能说「哪儿有问题」。

这三个报错还有一个共同的预防办法：组装完成之后，先不装机，而是把整包解一遍，看结构对不对。份数对不对、每份有没有签名文件、主包和各份的版本标识是不是一致——这三项检查两分钟，比装机试错快得多。

顺便说一个经验：分卷包的报错信息，往往比单包更含糊。因为它涉及多个文件之间的配合，系统在报告时倾向于给一个笼统的说法。所以遇到分卷包的报错，不要试图从文字里找线索，直接去比对结构。

最后再强调一次：分卷包上「报错」是少数，「不对」才是多数。所以验收的重点不是「能不能装」，而是「装完之后每一类设备上对不对」。把注意力放在后者，能从根上减少返工。

还有一个不报错但很麻烦的情况：装上了，但某个功能在特定设备上不可用。这种情况往往不是报错，而是「点进去没反应」或者「内容是空的」。它的原因通常是漏改了某个分卷里的资源——而那台设备恰好会加载那一份。

十六、把这件事教给别人，三句话就够

这两类包，讲原理容易讲成两门课。给三句话，对方遇到时能立刻用上。

第一句：先看解开之后有几份，一份就是普通包。不要用后缀判断难度，用结构。

第二句：有几份就要改几份、签几份。分卷包上九成的返工，都出在「只改了一份」或者「只签了一份」。

第三句：代码目录只有一个文件、而且很小，就停下。那是加固包，改不动的，直接去要未加固的版本。

三句话之后补一句：改完至少在两台不同设备上各装一次。分卷包的问题几乎都表现为「一类设备对、另一类不对」，只测一台等于没测。

这三句话还有一个顺序上的讲究：先判结构，再判难易，最后才动手。顺序反了，就会先动手、再遇到麻烦、最后才回头怀疑结构——而那时候你已经花掉了一两个小时。

另外一个建议：把这三句话写成一张便签，贴在改包用那台电脑的显示器边上。听起来有点土，但这类判断最怕的就是「想不起来」。等它变成本能，便签就可以撕了。

这四句话覆盖了这一篇的大部分内容。剩下的细节——七步流程、三个报错、五个特征——属于「遇到了再查」的部分，不需要提前背。

十七、分卷包的验收，和单包不一样

单包的验收很简单：装一台，看改动点变没变，走一遍主要功能。分卷包不能这么做，因为它的问题是「分类出现」的。

第一步，确认每一份都装上了。有些设备只会装主包加其中一份，有些会装两三份。如果测试设备只装了一份，那你验的只是一条路径。

第二步，至少用两台「参数不同」的设备。不同架构、或者不同屏幕密度，这两类差异最容易暴露「漏改分卷」的问题。如果手上只有一台，就把它的语言或者显示大小改一下再测一遍——这相当于人为制造了第二条路径。

第三步，验证「应该变的」和「不该变的」两处。应该变的，是需求要改的那一处；不该变的，是紧邻的一两处。分卷包上还有一个需要额外确认的：换一台设备之后，同一个位置是不是也是新的。

第四步，确认没有多出来的东西。比如某个分卷被漏掉之后，那个功能可能不是「报错」，而是「空白」或者「默认图」。这类问题不会自己冒出来，要主动去看。

这四步加起来大概二十分钟。比单包多的是第二步和第三步的最后一句话——而这两处恰好是分卷包问题的唯一出口。

一个实用的习惯：把「装了几份」写进验收记录。下次同样的包再改，你会知道上一次是在什么结构下验的，而不是从头猜一遍。

还有一个容易被忽略的验收点：装上之后，各份是不是都还在。有些设备在覆盖安装时会清掉旧的分卷，导致新装的包里少了某一份。现象是应用能打开，但某个功能报「资源缺失」。检查方法：装完之后看应用的占用体积，如果比预期小了一截，就是少装了。

十八、用过的人怎么说

五条反馈对应五件事：主包不等于全部、每份都要签、加固包要早认、五分钟判断能省一天、验收要看两类设备。而这五件事，正好是这一篇的五节。

第三条那句"改了两个多小时一点动静都没有"，是这个话题里最典型的一种浪费。它不是技术不够，是顺序反了——先动手，后判断。而这两件事换个顺序，成本差别是十倍以上。

---

只需说话，就能让应用变成你想要的样子。而在"拆不开的包"这件事上，这句话背后还藏着一句提醒：说清"改成什么样"之外，最好先确认"这个包属于哪一类"。剩下的交给安卓修改大师智改工坊——常见包型都能直接展开成可编辑工程，遇到展不开的，它会明确告诉你，而不是让你在里面转两个小时。