手机本地跑 Debian：安卓版 AI 改包沙箱内核拆解

先把结论放在前面，省得你带着疑问往下读：手机能改包，不是把电脑上的几个命令行工具“搬”过来那么简单。APK 的反编译与回编依赖 Java、依赖 aapt、依赖一套能读能写的 Linux 文件系统，还要有足够的内存和正确的框架资源表。安卓应用进程本身跑不了这些重活，系统也不允许你随手往 /usr/bin 里装东西。所以真正的难点不是“有没有 apktool”，而是“在哪里给 apktool 造一个像电脑一样的家”。

安卓版的答案，是在设备上跑一个 Debian 用户态沙箱：用 PRoot 做路径映射，把应用私有目录里的项目文件夹“变成”沙箱里的 /root/projects，再把 JRE、apktool、aapt、框架文件按需放进去。听起来像变魔术，拆开看全是工程取舍。下面从这台 Debian 为什么能塞进手机讲起，一路讲到 Android 16 上那 18 个“伪九宫格”文件引发的真实警告。

一、把一台 Debian 装进口袋，这件事到底难在哪

在电脑上改一个 APK，流程是熟的：装 JDK，装 apktool，准备 aapt，反编译出 smali 和 res，改完回编，zipalign 对齐，apksigner 签名，最后 adb install。每一步都有成熟的命令行工具，出错就翻日志。工具链之所以“听话”，是因为 Windows 或 macOS 本来就提供了完整的文件系统、进程模型和运行库，缺什么装什么。

手机不是这样。Android 底层确实是 Linux，但应用看到的世界是被裁剪过的：没有 glibc 的完整用户态，没有 /usr/bin，没有包管理器，普通应用也没有 root。apktool 是一个 Java 程序，启动它需要 JRE；回编资源时需要 aapt 或 aapt2；两者都要在文件系统里找库、找临时目录、找框架文件。只把 jar 塞进 APK 里，点一下运行，等着的往往是 could not exec 或者一次把前台界面顶掉的内存崩溃。

更现实的问题是内存与前台优先级。反编译一个几十 MB 的包，apktool 要吃掉几百 MB 内存，还会持续读写大量小文件。把这套东西直接跑在应用主进程里，用户切出去回个消息，系统就可能把进程回收；界面稍一卡顿，ANR 弹窗就来了。改包不是“算一下”那么简单，它更像在手机里开一间小型工厂，需要独立的车间、独立的仓库和独立的电闸。

所以安卓版没有走“把工具塞进 App 进程”的路，而是复用了设备上本来就要常驻的 Debian 沙箱。这个沙箱不是为改包临时造的，它是智能修改引擎的住处；改包只是把 apktool 这间“车间”也搬了进去。沙箱有独立的 shell、独立的文件系统视图、独立的内存预算，崩了不影响前台界面，改到一半切走也不会把工程弄丢。这个设计选择，决定了后面所有的技术细节。

“在手机上改包”真正稀缺的不是算力，而是一个可控、可解释、可回退的运行环境。算力早就够了，缺的是把电脑上的那套坐标系完整地搬过来。

这也是为什么安卓版第一次使用要先下载约 246 MB 的环境包：Debian 的 rootfs、Node 层、适配层、内置框架、终端组件都在里面。APK 本身只有约 7 MB，负责下载、校验、解压和引导。把重资产放到环境包里，带来的直接好处是应用本体轻、更新快；代价是第一次使用需要一段准备时间。这个取舍后面会单独用一章讲透。

二、PRoot 的路径魔术：宿主与访客的两套坐标

要理解安卓版的沙箱，先要接受一个事实：同一个项目目录，在应用看来和在 Debian 看来，路径不一样。

应用侧看到的是 Android 的文件路径，大致长这样：应用私有目录下的 user-data/Project/<项目目录>。Debian 侧看到的是 /root/projects/Project/<项目目录>。这不是两份文件，而是同一份文件的两个门牌号。PRoot 把宿主的 user-data 目录绑定到访客的 /root/projects，于是应用写进去的 source.apk，在沙箱里立刻就能被 apktool 读到；沙箱里回编出来的 unsigned.apk，应用侧也能马上拿去对齐、签名。

PRoot 是什么？一句话：一个用户态实现的 chroot 加 mount --bind。它借助 ptrace 跟踪访客进程的系统调用，在调用真正落到内核之前，把路径参数改写成宿主能理解的路径，再把结果伪装成访客期待的样子。访客以为自己站在 / 下，其实每一步都被重定向到了应用私有目录里的一棵 Debian 文件树。因为不涉及内核模块，也不需要真实 root，普通应用就能跑起来——这是“手机不 root 也能改包”的前提。

这套映射最直接的好处是“零拷贝”。反编译产物可能有几百 MB，如果每次都在沙箱和宿主之间复制一遍，慢不说，手机存储也吃不消。现在文件只有一份，沙箱里的 apktool 改完，应用侧直接读同一个目录；项目的 apktool.log 也是同一份，内置的文本查看器能打开，出问题不用连电脑抓日志。

第二个好处是可解释。很多“手机改包”工具把过程包成一个黑盒，成功了不知道为什么成功，失败了也不知道卡在哪。安卓版保留了 apktool 的原始日志，项目目录里能看到 source.apk、反编译工程、build 目录和日志。AI 改了什么、回编用了哪条路线、签名有没有通过，都能在文件层面复盘。对普通用户，这是“改坏了还能找回来”的安全感；对开发者，这是可以拿去和同事讨论的证据。

理解了这一层，再看“手机本地改包”就不会觉得神奇了。它没有把手机变成服务器，也没有偷用云端算力；它只是用 PRoot 在应用私有目录里搭了一个足够像 Linux 的房间，然后把 Java、apktool、aapt 这些老牌工具请进去。工具还是那些工具，难的是让它们在 ARM64 的手机上、在没有 root 的前提下、在应用随时可能被系统回收的环境里，稳定地把活干完。

三、工具链的三条命：JRE 21、双 apktool 与 aapt 的分工

沙箱有了，接下来要回答一个更具体的问题：工具从哪来，凭什么能在 ARM64 上跑起来。这里藏着整套方案里最容易被人忽略、也最容易翻车的一段。

先看 Java。apktool 是 Java 程序，没有 JRE 就没有一切。安卓版没有把“在沙箱里 apt 安装 Java”当成主路径，而是让应用侧先下载一份自带 JRE 21（Temurin，linux/arm64），解到工具目录，再在每次执行 guest 命令时把它的 bin 挂到 PATH 最前面。原因很现实：沙箱能不能联网，取决于用户的网络环境，而“把 Java 装好”不应该依赖沙箱联网。自带 JRE 走的是手机自己的网络，下载一次，之后每次反编译、回编都直接可用；沙箱里的 apt-get install default-jre-headless 只作为最后的兜底。

这里有个很典型的“魔鬼在细节里”。JRE 解包时如果丢掉 tar 里记录的可执行位，bin/java 也许还能跑，但 JVM 启动子进程要用的 lib/jspawnhelper 和 lib/jexec 一旦没有执行权限，表现就不是“权限不足”这么直白，而是 apktool 在回编时报一句 Could not execute aapt binary，把人引向 aapt 本身。安卓版在解包时按 tar 的 mode 落盘，之后每次检查工具还会顺手补一次执行位，就是为了把这类“看起来像 A 问题、实际是 B 问题”的坑提前填掉。

再说 aapt。apktool 自带 aapt/aapt2 的 prebuilt，但那是 x86_64 的，在 ARM64 的 Debian 里根本 exec 不了。真机上的原话是 could not exec: [...]，然后卡在 I: Building resources...。所以安卓版必须自己准备 ARM64 的 aapt 和 aapt2——工具包里带的是 Debian 的 13 个 .deb，由应用侧用纯 Java 的 ar + xz + tar 解开，不依赖沙箱里的 dpkg/apt。为什么不在 guest 里解？因为真机上 guest 的 dpkg-deb 读这 13 个包时一律读不出包名，前面还跟着 Android linker 的报错；换到宿主侧解，问题就绕开了。

解出来的 aapt 还有个细节：它的 RPATH 写死指向 /usr/lib/aarch64-linux-gnu/android，而安卓版并没有把这些库铺进 rootfs。所以执行时必须显式带上 LD_LIBRARY_PATH，指向解包树里同一层的库目录。少了这一步，表现是“文件明明在、就是跑不起来”。这类问题在日志里往往只有一行 error while loading shared libraries，但排查起来非常费时间。

然后是这条链路的主角：apktool 的双版本。默认路线是 3.0.3，它只支持 aapt2；备用路线是 2.12.1，最后一个 2.x 版本，能走 aapt1。两个 jar 都在工具包里，按官方 release 的体积和 SHA-256 认版本，文件名分别落到 apktool.jar 和 apktool2.jar。

为什么不用一个版本包打天下？因为 3.x 砍掉 aapt1 支持，只认 aapt2；而沙箱里的 aapt2 是 Debian 那套 AOSP 14 时代的版本，遇到 Android 15/16 的新资源表就是读不了。aapt1 的读取方式更宽松，同一个框架包它能吃下去，所以必须有 2.12.1 这条“老将”路线兜底。另一个原因是反编译行为：早期 2.9.x 会把 lib/**/*.dex 也解开，有些加固包在 lib/armeabi 下放了一个“名字叫 .dex、内容其实是 zip”的文件，apktool 解析到一半就抛 not a valid dex，整个反编译跟着失败。3.x 默认只解根目录的 classes[0-9]*.dex，正是改图标、改名称、改资源想要的行为。走 2.12.1 时，命令里会显式补上 --only-main-classes，让两条路线的“只解根 dex”规则保持一致。

还有一个很不起眼、但会直接决定回编成败的参数差异。apktool 3.0.3 调 aapt2 时会传 --no-compile-sdk-metadata，而 Debian 那份 aapt2 不认这个选项，直接打 usage 退出。安卓版的做法是给 aapt2 套一层很薄的壳脚本，只把这个不认识的参数按位置过滤掉，再原样转发其余参数。壳脚本不拼字符串、按位置参数重建 argv，所以路径里有空格也不会出错。这种“不修改工具本体、只在调用边界做适配”的工程手法，比到处打补丁更容易维护。

为什么版本要按哈希认、不能只看“文件在不在”？因为工具目录里的旧 jar 会一直躺在那里。用户升级应用后，如果只判断文件存在，就会继续用 2.9.3 的老行为，反编译失败还找不到原因。安卓版对两个 jar 都校验字节数和 SHA-256，对不上就当没有，重新下载或用工具包里的替换。下载也走多镜像回退，下到的文件先落到临时名字，校验通过才改成正式文件名；镜像挂掉、返回错误页、下到半截，都不会污染工具目录。

真正让“手机改包”可用的，不是某一个神奇工具，而是这些看起来不性感、但每一处都在防翻车的细节：执行位、库路径、参数过滤、哈希校验、失败回退。科技含量往往就藏在这些地方。

对用户来说，这一章可以浓缩成一句使用建议：第一次打包如果需要补工具，耐心等它下完，不要中途杀掉应用；之后工具就常驻在项目工作区里，换项目、重启应用都不必重来。如果你看到日志里出现“备用 apktool 下到 25%”之类的提示，说明当前路线需要 2.12.1，属于正常的兜底流程，不是出错。

四、框架、资源表与 Android 16：一次真实的三级降级

如果说 JRE 和 aapt 是“工具”，框架就是“字典”。apktool 反编译和回编资源时，需要一份系统框架资源表来认识 android: 命名空间下的属性、样式和维度。字典版本不对，轻则警告，重则整包编不过。

安卓版不再用 apktool if 去“安装框架”，而是直接把设备自带的 /system/framework/framework-res.apk 复制成项目里的 apktool-framework/1.apk，反编译和回编都显式传同一个 -p 目录。这个改动解决过一个很隐蔽的问题：以前回编没传 -p，apktool 会去默认目录 ~/.local/share/apktool/framework/ 找框架，而那里可能躺着一个旧版本留下的 1.apk，于是回编报 failed to load include path。现在两边共用项目里的同一份框架，OTA 更新后只要文件大小变了就重新复制，版本不会悄悄漂移。

但“用设备框架”有一个前提：沙箱里的 aapt2 得读得懂它。Android 15/16 的 resources.arsc 换了新的条目编码，Debian 的 AOSP 14 版 aapt2 直接报 RES_TABLE_TYPE_TYPE entry offsets overlap actual entry data。这句报错对普通用户像天书，对工具链就是明确的信号：该换框架了。

怎么判断“读得懂”？这里有一个很值得讲的工程选择。早期尝试过 dump 框架资源表，看输出里有没有包名，但很快发现两条路都不稳：设备框架很大，dump 很慢，可能超时；内置框架只带 resources.arsc、没有 res/，会刷几千行 “resource ... but no such path exists” 的警告，把关键行挤出屏幕。更坑的是，aapt2 在某些失败场景下退出码仍然是 0。于是探测方式改成：拿这份框架做一次最小的 aapt2 link，用空清单当输入，看退出码。这正是回编时真正要做的事，能过就是能用，过不了就是读不了，没有歧义。

这套降级不是拍脑袋的“多试几次”，而是有顺序、有记录的。反编译时会探一次框架，决定用哪条路线，并把结果写进项目的 build/toolchain.txt；回编前还会现场再判一次，因为内置框架可能随工具包更新，不能死记上一次的结论。两种工程格式也有单向兼容：2.x 解出来的工程，3.x 可以直接回编；3.x 解出来的工程，2.x 回编不了。所以往 aapt2 方向可以升级，往 aapt1 方向必须重新反编译。这个细节决定了“降级”不是换个命令，而是一次完整的重来。

Android 16 上的 18 个“伪九宫格”

讲一个真机上发生过的案例，它特别能说明“日志里哪些是警告、哪些才是错误”。

在一次 Android 16 设备的测试里，用 2.12.1 反编译一个自家应用，日志里连续出现了 18 条警告，大意是：Could not find 9patch chunk ... Renaming it to *.png。这 18 个文件都是 77 字节，扩展名是 .9.png，但里面根本没有九宫格数据——它们是“伪九宫格”，可能是占位图、空资源，或者历史遗留的假文件。

九宫格（NinePatch）是 Android 特有的一种图片格式，文件名以 .9.png 结尾。它在图片四周留出 1 像素的边框，用纯黑像素标记可拉伸区域和内容区域，编译时由 aapt 转成带 npTc 块的二进制图。apktool 反编译时如果发现某个 .9.png 里找不到合法的九宫格块，就会按标准兜底逻辑去掉 .9，把它当普通 PNG 处理，并打印这条警告。

关键点在于：这是警告，不是失败。改名之后，资源名不变，引用它的地方仍然能找到图；回编继续跑，最后的产物是成功的。很多人看到屏幕上刷出十几条“Renaming”，第一反应是“坏了”，其实包已经好好打出来了。正确的验证方式不是盯着警告数，而是看回编是否成功、产物是否生成、装到设备上图标和界面是否正常。这个案例后来被当作“日志阅读课”的素材：先分清 W 和 E，再看阶段标记，最后才看具体行。

当然，九宫格本身也有真会失败的情况。旧 APK 或加固包里常见一种图：四边像素不是“透明或纯黑”，而是残留了图片颜色，比如右边框整列是橙色。aapt2 会报 found an invalid color，整个回编失败。安卓版在回编前会扫一遍 res 下的 .9.png：边合法、上/左边有拉伸标记的，一个字节都不动；只有颜色不对的，把非法边像素改成透明、保留黑色标记；实在修不好（没有拉伸标记、图太小、解码失败），就去掉文件名里的 .9 变成普通 PNG，保证还能打包。这个处理只动有问题的文件，正常图不会被无差别重编码。

把这些串起来看，Android 16 带来的挑战并不是“系统太新，工具全废”，而是“资源表的代际差需要一条有秩序的降级路径”。设备框架优先，内置框架接力，aapt1 收尾；每一步都有探测、有日志、有回退。对用户来说，你只需要在遇到新系统时多一点耐心，必要时重跑一次打包；对工具来说，这已经是把能做的兼容都做在了前面。

五、环境包自举：7 MB 的壳，246 MB 的家

聊完工具，再看“家”是怎么搬进来的。安卓版的 APK 大约 7.8 MB，版本号 50.06.00.00，最低支持 Android 10，目标 SDK 是 36。它不把 Debian rootfs、Node、DSH、内置框架、终端组件打进安装包，而是首次使用时从 down.apkeditor.cn 下载约 246 MB 的环境包，解压到应用私有目录的 files/env。这件事只做一次，之后每次启动只做存在性检查，很快。

这个取舍值得展开。把环境打进 APK，首次安装就能离线用，听起来更省心；但安装包会膨胀到几百 MB，应用商店审核、下载、更新都会变重，而且每次修一个工具版本都要重新发一个巨包。把环境拆出去，APK 保持轻量，环境可以独立更新，内置框架这类“关键小文件”也能随环境包快速迭代，不必等应用市场放行。代价是第一次使用必须有网、必须等，且对存储空间有要求。对一款面向手机和平板的改包工具来说，这个取舍是合理的：改包本来就是低频、重操作的任务，用户愿意为“一次准备、长期本地用”付出一次下载。

环境包的安装流程，比“下载—解压”多了三道保险。

第一道是临时目录。下载文件先落在缓存目录，解压到 env-staging，不会直接往正在使用的 env 里写。解压时逐条检查条目名，绝对路径、..、空名、带冒号的路径一律拒绝，防止压缩包把文件写到目录外面去。

第二道是逐文件校验。解压完读 env-manifest.json，对里面列出的每一个文件核对大小和 SHA-256。不是“解压成功就算成功”，而是“每一个字节都对得上才算成功”。只要有一个文件缺失、大小不对、哈希不对，整次安装就判失败，不会把一个半残的环境交给用户。

第三道是原子替换与回滚。校验通过后，先把旧的 env 改名成 env-old，再把 staging 改名成 env；新目录就位失败时，尽量把旧目录换回去。首次安装没有旧环境，直接落位；升级时旧环境一直留到新环境成功为止。下载的压缩包在装完后删除，不占长期空间。

下载本身也有防呆。连接超时 30 秒、读取超时 90 秒；服务器返回非 2xx 直接报错；读到一半断开、实际字节数和 Content-Length 对不上，也会判“不完整”并重来。7z 是固实压缩包，为了算解压进度，程序只读 7z 的头拿到条目大小，而不是逐条“跳过”一遍——后者在固实包上会把数据解压两次，白白浪费时间和电量。这些细节用户看不见，但它们决定了“第一次使用”是顺滑还是折磨。

还有一个经常被问到的边界：为什么只支持 ARM64 设备。因为运行层、JRE、aapt 都是 ARM64 的；x86_64 的雷电、夜神等模拟器即便报告“支持 ARM 转译”，主 ABI 仍然是 x86_64，PRoot 在模拟器上还会遇到额外的 ptrace 限制。安卓版判断的是主 ABI，不是“支持列表里有没有 arm64-v8a”。有些模拟器的 abilist 里确实带 arm64-v8a，但那是翻译层的声明，不能当成原生执行能力。所以 x86_64 模拟器会在反编译入口就直接收到“当前版本仅支持 ARM64 设备”的提示，不会先让你下 246 MB、再在启动 PRoot 时失败。

从产品角度看，环境包自举还有一个隐性好处：它把“改包能力”和“应用版本”解耦了。工具链升级不必等应用商店审核，内置框架换新也不必让用户重装应用。对经常面对新系统、新资源格式的改包工具来说，这种可更新性比“安装包小一点”重要得多。

六、打包流水线：回编、对齐、v1+v2+v3 签名与验证

前面都是准备，这一章才是“把 APK 做出来”。一个项目在手机上落地后，目录结构大致是：source.apk 保存原始包，apktool 是反编译工程，build 放回编产物和日志，apktool.log 记录反编译输出。项目列表里可以打开详情、浏览文件，内置文本查看器能直接看日志和 XML。

打包的第一步不是回编，而是确认反编译产物还在。项目目录在用户空间里，清理存储、反编译中途被杀，都可能留下一个空壳目录。只判断“目录存在”不够，安卓版以工程根目录下有没有 apktool.yml 为准；没有就自动重新反编译一次，再继续打包。这个设计看起来只是容错，实际上省掉了大量“我明明改过，怎么又让我重新反编译”的困惑。

第二步是回编前的清理。加固包可能把资源文件名写成以 $ 开头，aapt 不认；也可能在 XML 元素名里塞乱字节，aapt2 会报 not well-formed。安卓版会把非法字符替换成下划线，并同步修改引用它的地方；只动文本 XML，二进制 XML 跳过，因为后者按资源 ID 引用，不需要改名。随后再跑一遍九宫格修复。这两步都是幂等的，重复跑不会越改越乱。

第三步是回编。根据项目记录的路线，调用 apktool 3.0.3 或 2.12.1，显式把 aapt/aapt2 路径和框架目录喂进去。回编失败时不是立刻判死，而是按前面说的顺序兜底：先看是不是内置框架不认识新属性，是就摘掉重试；再看日志里有没有“aapt2 读不了框架”的特征，是就换 aapt1 路线，用 2.12.1 重新反编译再回编。产物先写成 build/unsigned.apk。

第四步是对齐。用和 zipalign 等价的实现，在应用进程内做 -p 4 对齐：4 字节边界让资源读取更高效，-p 还会把共享库按页对齐，方便系统直接 mmap。为什么对齐要放在签名之前？因为 v2/v3 签名覆盖的是整个 APK 文件的内容，包括对齐产生的填充；如果先签名再对齐，文件字节变了，签名立刻失效。这个顺序不能反。

第五步是签名。安卓版在应用进程内用 apksig 生成 v1、v2、v3 三种签名方案，输出 build/<应用名>_<版本>_signed.apk。三种方案不是“越多越好”的堆砌，而是覆盖不同系统版本和不同校验层级：

• v1（JAR 签名）：最老，按条目逐个签名，兼容旧系统；对 ZIP 元数据的修改比较敏感。
• v2（APK Signature Scheme v2）：对整个 APK 文件做签名，校验更快、覆盖更完整，Android 7.0 起支持。
• v3（APK Signature Scheme v3）：在 v2 基础上支持密钥轮换，Android 9.0 起支持；对新系统更友好。

三者同时带上，是为了让同一个包既能装到老设备，也能在新系统上通过完整性校验。尤其是 targetSdk 36 的应用，新系统对签名方案有硬性要求，只带 v1 的包可能连安装都过不了。签名完成后再做一次验证，确认“到底签没签上”，而不是只看命令退出码。签名文件、口令、证书信息都按项目配置管理，默认签名适合内部测试；要长期分发，应该在项目里换成自己的签名文件，并妥善备份。

最后，整个打包过程会写日志，产物可追溯。对普通用户，日志是“出问题能求助”的凭据；对开发者，日志是“这条流水线到底做了什么”的说明书。一个改包工具愿不愿意把日志摊开，某种程度上决定了它是不是只做一锤子买卖。

七、两个真实改包实例：从“折腾一下午”到“说几句话”

技术讲到这里，该落到具体动作上了。下面两个例子都来自自家应用或已获授权的内部应用，不涉及任何他人的商业包。每个例子都按“以前怎么做 / 现在怎么做 / 改完怎么验证”写，方便你对照自己的场景。

再补一个更轻的场景：自家的电商展示 App 要做活动，需要把首页 banner 换成活动图、把 WebView 打开的网址换成本地活动页、再出一个渠道包。以前要等前端发版、打包、提审；现在把活动图和网址作为附件和需求交给安卓版，在手机上改完、签名、安装，运营自己就能先看效果。这类“只动资源、不动逻辑”的修改，正是本地改包最舒服的用武之地。

注意：上面所有例子都建立在“应用是自己的，或者已经获得授权”的前提下。给自家应用换图标、改内测名、切内网地址，是正常的研发和内测行为；拿同样的手段去改别人的付费应用、绕过安全机制，性质完全不同，也不在本文讨论范围内。

八、给第一次上手的你：一条不会迷路的路线

技术细节讲了这么多，真正动手时其实不需要记住 PRoot 怎么改写路径，也不需要背 apktool 的参数。安卓版把复杂留在了后面，把操作压成了一条很短的路线。下面按顺序走一遍，第一次用的人照着做就行。

1. 确认设备。Android 10 及以上的 ARM64 手机或平板；预留至少 1 GB 存储；第一次准备环境时连稳定 Wi-Fi。x86_64 模拟器不用试，入口会直接提示不支持。
2. 完成首次准备。打开应用，按提示下载约 246 MB 的环境包；第一次打包时还可能补约 49 MB 的工具包。让它下完，不要中途杀进程。装完后环境会常驻，之后启动很快。
3. 导入要改的包。可以从文件夹里选 APK、JAR、APKS、XAPK、APKM，也可以直接从已安装应用里挑。导入后应用会解析图标、应用名、包名、版本、SDK 和启动页，先确认这些信息对不对。
4. 进入项目，先看目录。每个项目都有独立的 source.apk、反编译工程、build 目录和日志。项目文件可以浏览，日志可以打开，这一步能让你对“改的是哪个包”有底。
5. 写需求，必要时加附件。把“改什么、改成什么、哪些不要动、怎么算改好”写清楚；图标、启动图、配置文件这类素材作为附件加进去，每个附件写一句用途。需求越具体，返工越少。
6. 点“立刻修改”，等它跑完。AI 在沙箱里改 apktool 工程，改完自动回编、对齐、签名。过程中可以看滚动日志；不要在这个时候清理后台，也不要手动改项目目录。
7. 安装或分享。打包完成后可以直接安装，也可以分享到微信、QQ 给同事测试。如果安装失败，先看是不是签名冲突，再决定卸载旧版还是换签名。
8. 按清单验收。看图标、看名称、看启动页、看版本号、走一遍核心功能、确认签名和日志。验收通过再把包发给更多人，别把“能装上”当成“改好了”。
9. 留档。需要继续维护就保存源码 ZIP；需要复现某次修改就翻项目历史，把当时的需求原文找回来。下一次改同类型的东西，可以照着历史再改一遍。

这套写法不只适用于 AI，也适用于人。你把需求交给同事时，如果只丢一句“改个图标”，对方也要来回问三轮；把四个格子填满，一次就能说清。安卓版把这句话变成工程动作，但“说清楚”这件事仍然是你最有价值的输入。

常见问题速查：先看现象，再看原因

谁最适合用：从独立开发者到不改代码的运营

安卓版的适用人群比很多人想象的宽。它不是只给逆向工程师准备的，也不是只给“会写代码的人”准备的。只要你的需求落在“改自己应用的外观、文案、配置、内测标识”这个范围内，它都能帮上忙。

• 独立开发者：没有完整的发版流水线，改个图标、改个名字、出个渠道包，不想每次都开电脑、等 CI。手机上导入、说一句、装上看效果，反馈循环短很多。
• 运营与市场：活动要换 banner、换启动页、换分享文案，等开发排期太慢。把素材准备好，自己在测试机上改一版，先看效果，再决定要不要进正式发版流程。
• 设计与产品：想验证新图标在桌面上的实际观感、新主题色在真实页面里的协调度，不必等开发打包。改完直接装，所见即所得。
• 企业 IT 与内部工具维护者：内网地址切换、版本号标识、内部标识文案、部门定制包，这些“不值得走一次完整发版”的需求，在手机上就能闭环。
• 学生与教学场景：想理解 APK 的结构、资源目录、签名机制，又不想一上来就折腾 Linux 环境。安卓版把沙箱和工具链准备好了，项目目录和日志都开放，适合边改边学。
• 爱折腾的普通用户：给自己写的、自己用的应用换个图标、改个名字、去掉自己加的开屏广告。门槛低，不需要 root，也不需要懂 smali。

“上手门槛低”不等于“能力缩水”。前面几章讲的 PRoot 路径映射、双 apktool、aapt 解包、框架三级降级、环境包逐文件校验、v1+v2+v3 签名，这些都不是演示用的花架子，而是每天真实打包会走到的路径。只不过它们被收在了界面后面：用户看到的是“导入、说话、打包、安装”，工程上跑的是一整套在 ARM64 上重新搭起来的改包流水线。这种“把复杂留给自己、把简单留给用户”的设计，才是它真正的科技含量。

用户评价

“我最看重的不是‘一句话’，而是它把 apktool 的日志和工程目录都留给我看。出了问题能顺着日志找到是哪一步、哪条路线，不是点完按钮干等。”

—— 老周 · 安卓逆向爱好者

“在平板上给自己写的 App 换图标、改内测名，改完直接装，不用回书房开电脑。对独立开发者来说，这种反馈速度很上瘾。”

—— 阿岚 · 独立开发者

“内部工具切内网地址，以前要收齐大家的电脑、逐个装，现在发一个包到群里，各自装完截图确认版本号就行。省下来的不是技术成本，是沟通成本。”

—— 陈工 · 企业 IT 运维

“我是设计专业的，第一次知道 APK 里还有这么多密度目录。按提示把图标和启动页素材放进去、把要求写清楚，居然真的能看到自己的配色跑在手机上。”

—— 小满 · 视觉设计专业学生

“活动期要换首页 banner、换活动页地址，等开发排期最快也要两天。现在素材给我，我自己在测试机上改一版先看，合适了再走正式流程。”

—— 林姐 · 电商运营

写到这里，这篇拆解也该收尾了。从手机里那台 Debian，到 PRoot 的路径映射；从 3.0.3 与 2.12.1 的双路线，到 aapt1/aapt2 的分工；从 246 MB 环境包的逐文件校验，到 Android 16 上 18 个伪九宫格的虚惊一场——每一层都在回答同一个问题：怎样让“改包”这件事在手机上变得可靠、可解释、可重复。

如果你也想试试这种“把电脑上的重活搬进手机”的体验，可以了解安卓修改大师安卓版，也可以先看看它的完整介绍：https://www.apkeditor.cn/ai-version.aspx。官网是 www.apkeditor.cn，电脑版、安卓版和经典版的区别在那边写得更清楚。

最后再把那句话送给你：只需说话，就能让应用变成你想要的样子。工具已经装进口袋，剩下的，就是你想让应用变成什么样。