拆开一个 APK：里面到底装着哪七样东西

刚开始改包的人，最容易卡在同一个地方：知道要改什么，但不知道它在哪。想改桌面上的名字，翻了半天找到一处，改完没变；想换启动图，把包里所有图片都换了一遍，结果启动时还是旧图；想把"版本 1.2"改成"内部版"，改了看得见的那处，另一处还挂着。

这些困惑不是能力问题，是"地图"问题。一个安装包本质上是一个压缩包，里面按用途分成了几个抽屉。你只要知道每个抽屉装什么、改哪个抽屉会动到什么，剩下的事就变成了"照着抽屉找东西"。这篇就是画这张地图。

需要先说明的是：拆包看结构，是"读懂"一个包的前提，不是"破解"它。本文所有讨论都建立在一个前提上——这个应用是你自己做的，或者你已经拿到了权利人的明确授权。拆别人的商业应用去看结构、去改里面的东西，是另一回事，不在讨论范围内。

只需说话，就能让应用变成你想要的样子。这是「安卓修改大师智改工坊」的一句话概括：你说清"把首页顶部的图换成这张"，它替你找到那个抽屉、换掉那张图、重新打包签名。而"它替你找的是哪个抽屉"，恰好就是这篇文章要讲的。想边看边试，可以从 https://www.apkeditor.cn/ai-version.aspx 下载「安卓修改大师智改工坊」，拿一个自己的应用建个项目，反编译完先别改，把目录翻一遍。

一、七个抽屉：一个安装包的基本分区

把一个 apk 用解压工具打开（改后缀改成 zip 也行），看到的目录大致固定是这几样。它们的分工，很像一个公司的部门：有的管"对外的身份"，有的管"里面的装修"，有的管"跑起来的逻辑"，还有的管"这张门禁卡的封条"。

第一个抽屉：AndroidManifest.xml。这是整份"申请书"——应用叫什么名字、图标用哪张、版本号是多少、需要哪些权限、有几个入口（Activity）、装到什么样的系统上能装。改桌面显示名、改图标、改版本号，都要动它。

第二个抽屉：classes.dex。这是编译之后的程序本体，相当于"跑起来的逻辑"。它是一堆给虚拟机看的指令，人看不懂。要改它，通常先被翻译成 smali（一种可读的中间表示）——反编译项目里那个 smali 目录就是它。

第三个抽屉：res。界面上的东西几乎都在这儿——布局文件、图片、颜色、字符串、图标、各种尺寸的图。你平时说的"改界面"、"换图"、"改一句提示语"，绝大多数落在这个抽屉里，或者落在下面第四个抽屉里。

第四个抽屉：resources.arsc。这是"资源索引表"。res 目录里的东西太多、太散，程序运行时不可能按文件名去翻——所以编译时会把它们编成一张表，按编号（资源 ID）索引。这张表就是 arsc。

它和 res 的关系，值得单独说一句：res 是"仓库"，arsc 是"目录卡片"。只换仓库里的货、不改目录卡片，有时候能生效（因为文件名没变），有时候不生效（因为卡片上还写着旧的尺寸、旧的指向）。这也是"我明明换了图，怎么还是旧的"最常见的原因之一。

第五个抽屉：assets。这是应用自己带的"私货"——离线网页、字体、音频、预置数据、模板文件。它不参与资源索引，程序用文件名直接读。所以改 assets 里的东西，一般不需要动 arsc。

第六个抽屉：lib。这是原生库（.so 文件），按 CPU 架构分目录：arm64-v8a、armeabi-v7a、x86_64 之类。里面是 C/C++ 编译出来的机器码，改不了、也不该改。你要做的通常是"确认它在、别误删"。

七个抽屉里，前四个是"改包时真正会碰的"，后三个是"知道就行、别动"。这个比例值得先记住：绝大多数改动发生在 res 和 manifest，少数在 assets，而 smali 只在"这句话写死在代码里"的时候才轮到它。也就是说，你翻目录的时间，八成应该花在前两个地方。

还有一个容易被忽略的细节：res 目录里的文件名有讲究。它只能用小写字母、数字和下划线，不能用大写、不能有空格、不能以数字开头。这个规则看起来只是"命名习惯"，其实是因为编译时资源名会被写进资源表，格式不合法就编译不过。所以在 res 里新建文件，名字要先想想。

第七个抽屉：META-INF。这是签名信息所在的地方。它不是"内容"，是"封条"——你改了包里任何一个字节，这张封条就对不上了，必须重新签。这也是为什么"改包必须重新签名"不是习惯，是硬规则。

二、反编译之后，目录里会多出几样东西

上面的七个抽屉是"包里的原貌"。而当你把这个包反编译成一个可以改的工程，目录会长得不太一样——因为它不是简单解压，而是"翻译"：把二进制翻译成人能读的文本。这一步会多出四样东西。

第一样：AndroidManifest.xml 变成可读的文本。原包里它也是二进制（压缩过的 XML），反编译之后变成你熟悉的标签格式——<application>、<activity> 一层层写着。这是新手的第一个"啊，原来在这儿"。

第二样：smali 目录。这是 classes.dex 翻译出来的结果，一个类一个文件，一行行指令。它不好读，但只要你只是想"改一个写死在代码里的字符串"或者"改一个判断条件"，往往能在里面找到那一行。

第三样：res 目录被展开成"原始文件"。图片从编译后的二进制还原成 png、webp；布局从二进制 XML 还原成可读的标签；字符串回到 values/strings.xml 里。这时候你改图、改字，就是改普通文件——比在二进制里硬改安全得多。

第四样：apktool.yml。这个小文件最不起眼，但它决定了"这个工程还能不能被打回一个包"。它记着原始包的版本信息、资源表的一些编译参数、以及"哪些东西因为翻译不了而被放进 unknown 目录"。

正因为这样，判断"反编译成功没成功"，不能只看有没有报错，要看有没有 apktool.yml。「安卓修改大师智改工坊」在这一步的判定就是两条同时成立：进程退出码为 0，并且工程目录里确实生成了 apktool.yml。少了后者，说明翻译到一半就断了——后续打包一定会失败。

还有两个目录值得认识：original 和 unknown。original 存的是"原封不动的原件"——比如原始签名信息、原始的 AndroidManifest 二进制。unknown 存的是"翻译不了的东西"——某些加固过的特征、某些工具不认识的资源。

顺便说一个新手常问的问题：能不能不解压，直接在压缩包里改一个文件？技术上可以，但那等于把包里的"目录索引"和"实际内容"错位了——尤其是压缩过的那几个文件，改完大小变了，索引对不上，包就可能损坏。而反编译工程没有这个问题，因为它是"整个重编"，不是"局部替换"。

关于 apktool.yml，还有一个实际用法值得知道：它能告诉你这个包"原来是怎么编的"。里面会记着版本的 code 和 name、资源表的一些编译参数、以及这个包有没有被拆成多个 dex。有时候你打出来的包"能用但总有点不对"，翻一眼这个文件，就能看出是编译参数跟原包不一致——比如压缩方式变了、某些资源被重新编过。这类差异不会报错，只会在某个非常具体的场景下露出一点不对，比如某个九图被拉伸、某个动画变得生硬。所以它不只用来判断成功，也用来做"改完之后和原包对比"的参照。

这两个目录的处理原则是一样的：能不动就不动。因为打包的时候，它们会被原样塞回去。你删了 original 里的签名信息，打出来的包签名那一步会出问题；你清了 unknown，某些资源就对不上了。它们看着"没用"，其实是"翻译过程中的存根"。

三、改哪一样，会动到哪个抽屉

这张对照表，是整篇文章最值得存下来的一页。左边是你想改的东西（用日常说法），右边是它通常待的地方。看懂这张表，你就能判断"这件事改起来是五分钟还是五十分钟"。

想改的	通常在哪	风险
桌面显示的名字	AndroidManifest 里 application 的 label，或 strings.xml	低，但太长会被截断
应用图标	mipmap-* 各密度目录 + manifest 的 icon 指向	中，只换一处会"一半新一半旧"
界面上的文案	res/values/strings.xml，或直接写在 layout 里	低，但可能有多语言版本
启动页的图	res/drawable-*，或 assets 里的一张整图	中，比例不对会被拉伸
版本号那行字	manifest 的 versionName + 关于页的一段文本	低，但两处要一起改
写死在代码里的提示	smali 里的一条 const-string	高，改错就崩，且难查
隐藏某个入口	layout 里的 visibility，或去掉一个按钮	低（但这不是权限）

表格里最容易被低估的是"应用图标"那一行。很多人以为图标就是一张图，其实是"一个名字 + 五个尺寸"：系统按屏幕密度去取对应的那张。你只在最高密度目录换了一张，老机器取的是低密度那张，于是看到的是旧图标——这就是"我换了图标，怎么还是旧的"。

这张表还有一层用法：它可以帮你判断"这件事值不值得改"。如果一件事落在"风险高"那一行，而收益只是"看起来好一点"，那多半不值得——因为改坏的代价是"某天崩了，查不出原因"，而改好的收益只是"顺眼一点"。而落在"风险低"那两行的事，反而值得多改几次：换图、改字，改错了看得见，改十次也不会出事故。

还有一点：表里同一条信息可能出现两次。比如应用名，manifest 里有，关于页里也可能有；比如版本号，manifest 里有，某个"设置"页也可能印着一行。所以看到表里写"或"，就要想到"可能两处都有"——这正是下一节要讲的"同一信息多处定义"。

而风险最高的那一行，也值得单独强调：写死在代码里的提示。它之所以危险，不是因为它难找，是因为"改错了不会立刻报错"——包能打出来、能装上、能打开，只有在走到那条分支的时候才崩。而那条分支，可能是一个月才用一次的"提交失败"提示。

四、两个自家应用的实例：一个在清单里，一个在 assets 里

光看表格记不住，落到我们自己改过的两个包上就清楚了。这两个应用都是我们自家做的、授权给内部和合作门店使用的，改的都是"看得见的东西"，没有一处动到逻辑。

第一个：门店巡店端，改的是"桌面名 + 关于页版本行"。这个应用给区域督导用，进店之后按检查项打分、拍照、提交。华东和华西两个大区各要一个自己的版本，名字要能一眼分开。

以前怎么做：打开 manifest 改 label，打一次包；然后在关于页找那段版本文字，发现它不在 strings.xml 里，而是拼在代码里，只能去 smali 里翻，翻到一条 const-string 才改掉。改一次四十分钟，改错了要重来。

现在一句话怎么做：在「安卓修改大师智改工坊」里对着这个项目说"把桌面名字改成'巡店·华东'，关于页的版本行改成'内部版 3.2 华东'"。它会分别去 manifest 和关于页那一处把文字换掉，其余不动，然后走打包、签名。

改完怎么验证：三步，一分钟。装到一台装着旧版的机器上（覆盖安装，不卸载），回到桌面看名字有没有变、有没有被截成两个字加省略号；打开应用进关于页，看那行字是不是新的；再退回首页，确认没有因为改字把某一行挤成两行。

第二个：图书查询端，改的是"启动页那张图"，而它在 assets 里。这个应用给门店查库存和借阅记录，启动时会先出一张品牌图，停留一秒半。

以前怎么做：按经验去 res/drawable 里找启动图，换了一张、打包、装上——启动还是旧图。折腾了两轮才发现，这个应用的启动页是一张整图放在 assets 里，由页面加载时直接读取，跟 drawable 一点关系都没有。

现在一句话怎么做：说"把启动页那张图换成这张，保持原来的比例，别拉伸"。它会去 assets 里换掉那张整图。这里"保持比例"这四个字很关键——因为启动图是整屏铺的，比例不对，四个角会被裁掉或者留黑边。

改完怎么验证：在一台机器上看"启动那一秒半"，看三件事。图有没有被拉伸变形；上下有没有黑边；启动完进首页时有没有一闪。第三件事最容易忽略——因为启动图和首页背景色不一致时，切换会闪一下，看起来像"卡了一下"。

这两个实例里还有一个共同的细节：改完之后，我们都会在项目里留一句"这句话为什么这么改"。比如"华东要独立名字，是因为门店督导装了两套、在桌面上分不清"。这句话只有一行，但半年后接手的人看到它，就不会再问"为什么华东的叫这个名字"。而这个成本，是三十秒。

两个实例放在一起，说明的是同一件事：同样的"改一张图/改一行字"，可能落在完全不同的抽屉里。而"知道它在哪个抽屉"，靠的不是背目录名，是"先找一遍、找到之后记下来"——记在项目里的那份配置上，下次就不用再找。

五、最容易误伤的三处，和它们为什么危险

改包出的问题，多半不是"改错了地方"，而是"顺手动了不该动的地方"。下面这三处，是新手最容易顺手碰到的，也是后果最不直观的。

第一处：resources.arsc。有人发现"某个字符串在 arsc 里也能搜到"，就顺手在那里改了一份。结果是两处不一致——程序运行时按 ID 去查，查到的是没改的那份，界面上还是旧字。

更麻烦的是，arsc 是二进制表结构，手改很容易把整张表的偏移写坏。表现不是"这句没改成功"，而是"整个应用一打开就闪退"——因为所有资源都查不到了。而这时候你很难想到，问题出在半小时前改的那一个字符串上。

正确的做法是：只改 res / values 下的源文件，让打包工具去重新生成 arsc。这也是"反编译成工程再改"比"直接改二进制"安全的核心原因——你改的是"源料"，表是工具重新编的。

第二处：META-INF 里的签名文件。有人想"跳过签名这一步"，就去删 META-INF 里的 .RSA / .SF。结果是包既装不上、也打不出来——因为签名不是"可选装饰"，是系统的校验依据。

而"删签名"这件事还有一个更隐蔽的后果：如果某个包本来是用某种特殊签名（比如系统级签名）才能装的，你重新签成普通签名，它就连装都装不上。这不是你改错了，是这个包本来就不该用普通方式改。

第三处：lib 目录下的 .so 文件。有人为了"减小包体积"，把自认为"用不到"的架构目录删了。结果在某批机器上打开就崩——因为那批机器正好是那个架构，而应用启动时要加载那个库。

这三处的共同点是：它们都不是"内容"，是"让内容能跑起来的基础设施"。内容改错了，看得见、改回来就行；基础设施动坏了，表现是"打不开""装不上""莫名崩"，而报错信息往往指向别处。

这三处还可以用一个更简单的办法来记忆：凡是"改了不会显示在界面上"的地方，都是危险区。你改一张图、改一句话，改完能立刻在屏幕上看到；而你改 arsc、改 META-INF、删 lib，改完什么也看不到——它只是在某个时刻以"装不上""打不开"的方式告诉你。看不见的改动，就是需要多问一句的改动。

所以有一条很朴素的判断：改包时，你的手只应该碰"res / values / assets"这三个地方，偶尔碰 manifest，绝不碰 arsc、META-INF、lib。而"绝不碰"的理由不是"太难"，是"没有必要"——所有正常的改动，都不需要动它们。

六、五个最常被问到的问题

问题一：为什么不直接解压改文件，非要先反编译？

因为包里的关键文件是二进制的。manifest 是二进制 XML，图片被压成特殊格式，字符串在 arsc 里按 ID 编好了号。直接解压，你能看到的只有一堆看不懂的字节；改它，等于在盲改一张有索引的表。反编译的意义，是把这些东西还原成"能读能改的源料"，再让工具重新编回去。

问题二：smali 和 java 是什么关系，我要不要学？

smali 是"dex 的可读形式"，不是 java。java 是源代码，dex 是编译产物，smali 是 dex 反出来的中间表示——它能读懂，但读起来累：一行一个指令，寄存器用 v0、v1 表示。你不需要学它，只需要知道"当一句话在 res 里找不到时，它可能在 smali 里"。

而"要不要动 smali"，有一条很实用的界线：改"值"可以，改"逻辑"要慎重。改一条字符串常量、改一个数字，风险可控；加一个判断、改一个跳转，很容易崩，而且崩了很难查。

问题三：反编译出来的工程，和我拿到的源码工程是一回事吗？

不是。源码工程是"写出来的"，有完整的 java/kotlin 文件、有注释、有构建脚本；反编译工程是"翻译回来的"，只有 smali 和资源，没有注释，变量名可能是 a、b、c。它能被打回一个包，但不能当成"可以长期开发的工程"。

这个区别有一个实际后果：反编译工程适合"改一处、打一次"，不适合"持续加功能"。如果你要长期迭代，最好还是回到源码；而如果你只是想改名字、改图、改一句话，反编译工程足够了。

问题四：为什么有的包反编译会失败？

常见原因有两类。一类是"包本身不标准"——比如被加固过、被改过资源表、或者是一个分卷包（apks / xapk）里的某一部分。另一类是"环境不对"——反编译依赖的几个程序没找到、路径里有空格或中文、磁盘空间不够。

判断是哪一类，看日志最快。「安卓修改大师智改工坊」会把反编译的输出完整写进项目里的 apktool.log，成功与否还要求 apktool.yml 真的生成了。日志最后几行通常在说"哪一步读不下去了"，比界面上那句"反编译失败"有用得多。

问题五：我只想改一个名字，需要看懂这一整套吗？

不需要，但看懂"这个名字在哪"能省你半小时。因为改名字最典型的坑，不是"改不了"，是"改了两处还剩一处"：桌面名在 manifest，关于页那行字在别处，启动页上可能还印着一个。而知道"同一个信息可能在三个抽屉里各有一份"，你就会习惯性地多看一眼。

这五个问题里，第四个值得多说一句：反编译失败时的"重试"是最没用的动作。因为失败的原因几乎都在输入端（包不对、环境不对），重试只是把同一件事再做一遍。更有效的做法是看一眼日志最后五行、确认包是一整个还是分卷、确认工具链找到了那几个程序，然后决定"换个包"还是"修环境"。

五个问题里，其实只有一句话：改包的门槛不在"会不会改"，在"知不知道它在哪"。知道位置，改一个名字是十分钟；不知道位置，改一个名字是一下午，而且很可能漏一处。

七、反编译完先别改：照着这个顺序翻一遍

新手拿到一个反编译好的工程，最常见的动作是"马上开始找要改的地方"。结果是在几百个文件里翻，翻到眼酸。更有效的做法是先花五分钟"认路"，之后每次改都会快很多。

第一步：看根目录有几样东西。有没有 apktool.yml（能不能打回包）、有没有 smali 目录（是不是有代码）、有没有 lib（有没有原生库）、有没有 assets（有没有私货）、res 下面有哪些子目录（界面复杂不复杂）。这一步不打开任何文件，只看目录名。

第二步：打开 AndroidManifest.xml，只看三处。application 的 label（桌面名）、icon（图标指向哪张）、activity 里带 MAIN/LAUNCHER 的那个（启动入口是哪个类）。这三处决定了"这个应用对外的样子"。

第三步：打开 res/values/strings.xml，搜一下你要改的那句话。搜到，说明它是"规范写法"，改这里最安全；搜不到，说明它写在布局里或者代码里，往下走一步。

第四步：在 res/layout 里搜那句话。如果它是直接写在布局里的（很多小应用都这样），你会在这里找到它。改布局里的文字要小心一件事：那句话可能被写死了宽度，改长了会被截成省略号。

第五步：如果还没有，再去 smali 里搜。这一步放到最后，因为它最慢、最容易改坏。而在 smali 里搜到一个字符串，通常意味着"这句话是代码里拼出来的"——它可能带变量，比如"当前版本 1.2.3"里的 1.2.3 是拼进去的，那你改的就不该是整句，是那个版本号本身。

这五步的顺序，其实是一条"从安全到危险"的路。strings.xml 最安全（改文本，不影响结构）；layout 次之（要注意宽度和间距）；smali 最危险（改错就崩）。所以能停在前一步，就不要往后走。

还有一条容易忽略的：认路的时候顺手记下"这个应用的启动 Activity 叫什么"。因为它会出现在好几个地方——manifest 里、装机拉起时用的组件名、以及某些崩溃日志里。名字记不住不要紧，记下"在 manifest 里搜 MAIN 就能找到"这个方法就够了。

顺便给一个"看目录就大概知道这应用难不难改"的经验值：res/layout 里有几百个文件，说明界面很多，改一处文案要找很久；只有十几个，说明界面简单，改起来很快。而 res/drawable 里的图片数量，往往决定了"换个视觉"这件事的工作量——图多的应用，换一套皮就是几百个文件，这种活手工做基本不可能，只能靠批量替换加统一的命名规则。

走完这五步，你其实已经得到了一份"这个应用的地图"。而这份地图值得留下来——留在项目里的那份记录上，写清"名字在 manifest、版本行在关于页第几段、启动图在 assets"。下次改，直接照着做，不用再翻。

八、同名资源散在好几个目录：为什么改一处不够

res 下面不是平铺的，它按"适配"分了层。同一个名字的图，可能同时存在 drawable-mdpi、drawable-hdpi、drawable-xhdpi、drawable-xxhdpi、drawable-xxxhdpi 这几个目录里；同一句文案，可能同时存在 values、values-en、values-zh-rTW 里面。

为什么要这么设计？因为一台机器只会取其中一份。屏幕密度低的老机器取小的那张，新的取大的那张；系统语言是英文的取 values-en，中文的取 values。这样同一个包能适配很多设备，体积也不会翻倍（因为只装一份进内存）。

而这就直接导致了那个经典问题：你改的恰好不是它取的那一份。你在 xxhdpi 目录换了新图标，测试用的那台老机器取的是 hdpi，看到的是旧图标；你改了 values/strings.xml，测试机系统语言是英文，取的是 values-en，看到的还是旧字。

所以"改多个目录"不是啰嗦，是必须。一套完整的图标，通常要换五份（五个密度）；一句要改的文案，要确认有几个语言目录。而这两件事，恰好是"手工改包"最容易漏的地方——因为它要求你把"同一个改动"重复五遍，而人重复到第三遍就会开始走神。

在实际操作里，这件事现在已经可以一句话说清。比如"把所有密度的图标都换成这张"、"把所有语言里的这句提示都改成中文"。工具会去找同名资源、按各自目录的规则替换，而不是只改你眼睛看到的那一份。

验证的方法也很直接：不要只在一台机器上看。至少两台——一台新机器（高密度）、一台老机器（低密度）；如果应用有多语言，再把系统语言切成英文看一次。三处都对，才算换干净了。

多语言这件事还有一个反向的坑：把中文改成了英文，但忘了改 values-en。如果在中文目录里把"提交"改成了"确认提交"，而英文目录里还是"Submit"，那在英文系统上看到的就是没改过的样子。这不算错，只是"两个语言不同步"——但在客户眼里，它就是"你改漏了"。

判断要不要同步，有一个简单标准：这个改动是"品牌层面的"还是"临时层面的"。品牌层面的（名字、口号、客服电话），所有语言都要改；临时层面的（这次活动的说明），通常只改当前语言那一份就够，因为活动只在一个地区做。

还有一个反过来的提醒：不要"顺手多建一个目录"。有人为了放一张大图，自己新建了 drawable-xxxhdpi 目录——如果原来没有这个目录，新建之后系统在某些机器上会优先取它，而那张图可能尺寸不对、比例也不对。资源目录的规则是"系统定的"，不是"你想放哪就放哪"。

九、"我明明改了却没变"：五个原因，按概率排

这句话大概是改包领域出现频率最高的一句。而它背后其实只有五种原因，按出现概率从高到低排，前两个占了八成。

第一个：改了，但没装上去。包打出来了，也发到群里了，但机器上装的还是旧版——可能是没覆盖成功（装的时候点了取消），可能是装到了另一台，也可能装的是同名的另一个包。判断方法很简单：看关于页的版本号，或看桌面图标有没有变。

第二个：改的那一份不是它取的那一份。就是上一节说的密度目录、语言目录。这个原因最"冤"，因为你的操作完全正确，只是系统取了另一份。

第三个：这个名字在包里有多处定义。比如"版本"这个信息，可能同时在 strings.xml 里有一份、在关于页的布局里写死一份、在代码里拼一份。你改了其中一处，另外两处还挂着——于是就出现"一部分变了、一部分没变"的怪现象。

第四个：界面被缓存了。有些应用会把首页内容、图片、配置缓存在本地，下次打开直接读缓存，不去包里取。这种情况下，改包是对的，但要看的是"清缓存之后"的样子。桌面的图标也有缓存——换完图标，有时要重启桌面或者等一会儿才刷新。

第五个：改的是"看起来对"的那一处。比如启动页有一张图，你在 drawable 里换了，但真正的启动图在 assets 里；或者提示语有两句几乎一样，你改了不常出现的那句。这一类最难查，因为它需要你真的理解"这个界面是从哪儿来的"。

五个原因里，前两个靠"看版本号 + 换台机器"就能排除，第三个靠"全局搜一遍"，第四个靠"清缓存再看"，第五个只能靠"认路"。而按这个顺序排查，通常十分钟内就能定位——比"再改一遍试试"快得多。

这五个原因还可以用一个动作一次性排掉大半：改完之后，先"卸载再装"试一次，再"覆盖安装"试一次。卸载重装能装上、覆盖装不上，说明是签名或版本号的问题；两次都装上了但界面还是旧的，说明是你改的位置不对。两种结果指向完全不同的方向，而这两次重装只要三分钟。

还有一条经验值得记住：出现"改了没变"的时候，先别急着再改一次。因为"再改一次"会让变量变多——你既不知道第一次为什么没生效，也不知道第二次改的是不是同一处。而先把"装没装上去"确认清楚，往往问题就自己露出来了。

十、有三种包，拆开看可以，动手改要谨慎

前面讲的都是"标准包"。但现实里你会遇到一些不太标准的包，它们的结构一样、拆开也能看，但一改就容易出问题。认识这三种，能省掉很多"改了却装不上"的困惑。

第一种：加固过的包。特征是 dex 很小、但 lib 里多了几个陌生的 .so，或者 assets 里有一大坨看不懂的二进制。它的代码在运行时才被解出来，所以你反编译出来的 smali 可能是残缺的——改资源（图、字）通常还行，改代码基本不通。

第二种：分卷包（apks / xapk / apkm）。这类包外面是一层压缩，里面是"基础包 + 若干配置分卷"。拆开之后你会发现有好几个 apk，改的时候要认准"哪个是主体"。只改分卷里的资源，很多时候不生效，因为主体里还有一份。

第三种：系统级或特殊签名的包。特征是它平时"装不上"，必须在特定设备或特定权限下才能装。这类包你用普通签名重新签，装的时候会直接被拒——不是你的包有问题，是它本来就要求另一种身份。

这三种包有一个共同的建议：先只改资源，别动代码，别动结构。改完在一台真机上装一次，通过了再往下做。因为它们的"失败"往往不是报错，而是"装不上"或者"打开就退"——而这两种表现，事后很难归因。

另外还有一种情况值得提一句：包是别人的。哪怕它在技术上完全能改，也不代表你可以改。授权这件事不在技术范围里，但它决定了"这件事该不该做"。本文所有例子都建立在自己拥有版权或已获授权的前提上。

这三种包还有一个共同的处理顺序，值得记一下：先试装原包，再试装"只改了一处"的包，最后才做完整改动。因为"原包能不能在自己这台机器上装上"是一个基准——如果原包都装不上（比如它要求更高系统版本），那你后面所有的"装不上"都不是你改出来的，排查方向完全不同。

还有一个判断"这包值不值得改"的小办法：先看它的 AndroidManifest 有多长。如果这个文件只有几十行，说明应用很简单，几乎所有东西都在 res 里，改起来又快又安全；如果它有几百上千行，说明入口很多、权限很多、还带着一堆服务和接收器，那改动的影响面就大得多——你改了一个看起来无关的页面，可能会影响某个后台服务的启动条件。这不是说不能改，是说"改完的验证范围要更大一些"，不能只看你改的那个页面。

把这一节压缩成一句话：结构能看懂，不代表能随便动。先判断"这个包是什么来路"，再决定"改到哪一层"——这一步花两分钟，能避免后面两小时的折腾。

十一、一张速查表：把这张图存下来就够了

前面十节讲的内容，其实可以用一张表装下。表里每一行都是"我想干什么 → 该去哪个抽屉 → 别碰什么"。

动作	去这里	别碰
改应用名	AndroidManifest 的 label / strings.xml	包名（package 属性）
换图标	mipmap-* 各密度 + manifest 的 icon	自适应图标的前景/背景对应关系
改一句话	values/strings.xml → layout → smali	arsc
换启动图	drawable-* 或 assets（看它原来在哪）	别同时换两处，避免半新半旧
改版本号	manifest 的 versionCode / versionName	versionCode 不能往回改
隐藏一个入口	layout 里那个按钮的可见性	别当权限用
减小体积	清掉没用的图片、字体	lib 下的架构目录、META-INF

表里出现三次"别碰"，它们对应三种最难查的故障。碰包名，等于换了一个应用，旧版装不上；碰 versionCode 往回改，同样装不上；碰 arsc，可能是"整个应用一开就退"。这三种故障的共同点是：报错信息不会告诉你"你半小时前动了什么"。

而"去这里"那一列，有一条隐含的顺序：从上往下，越靠下越危险。strings.xml 是纯文本，改错了看得见；layout 要照顾宽度和间距，改错了界面歪；smali 是代码，改错了崩。所以能在上面解决，就别动下面。

这张表还有一个用法：改之前先用手指在屏幕上"点一遍路径"。也就是在脑子里走一次——打开应用、进到那个页面、看到那句话。走不通，说明你对这个应用的界面还不熟，那就该先翻一遍再动手。因为改包改错，多半不是手抖，是"你以为那个页面是从这儿来的"。

最后再补一个很实用的小判断：如果这个改动"一句话说不清"，那多半说明它不该是一个改动。比如"把首页弄得清爽点、把不常用的收起来、重要的往前放"——这不是一句，这是三句，而且每一句都需要判断。把它拆成三句具体的话（把某个版块挪到第二位、把某个入口收进二级页、把某段文字换成一句话），改起来才可控，验起来才有标准。

最后还有一条表外的话：改之前先把当前包复制一份。这不是技术，是习惯——而它是所有习惯里回报最高的一个。因为改坏了只要十秒就能退回去，改好了你可以慢慢研究为什么。

十二、用过的人怎么说

五条反馈讲的是五件事：先认路、别碰 arsc、密度要一起换、先看能不能改、同一信息有多处。而这些恰好是这篇文章的骨架——地图、顺序、范围、边界、重复。

第一条里的那句"把 drawable 里所有 png 都换了一遍"，是这个领域最真实的写照。因为在不知道结构的时候，人的本能是"广撒网"——而广撒网的成本不只是时间，还有"改坏了好几处自己不知道"的风险。而认路这件事，只需要五分钟。

---

只需说话，就能让应用变成你想要的样子。而"说清要改什么"的前提，是你知道它在哪一层——名字在清单里，图可能在 assets 里，一句话可能在三个地方。这篇画的就是这张地图。剩下的交给安卓修改大师智改工坊：它替你翻抽屉、替你重打包、替你签名，你只要把"改成什么样"说清楚。