安卓平板完整改包：从选择文件到安装分享

一、先看清边界：ARM64 平板能做什么，不能做什么

“完整改包”不是只换一张图。它至少包含六段：解析安装包、反编译出 apktool 工程、修改资源或代码、回编成新 APK、对齐并签名、安装到设备上验收。安卓修改大师安卓版把六段收进同一个项目：导入时解析图标、应用名、包名、版本与启动入口；建立项目后得到独立目录；AI 工作台按自然语言修改 apktool 工程；回编、对齐、签名依次自动执行；最后给出可安装、可分享的成品。你不需要在平板上手敲 apktool 命令，但仍然要理解每一步在做什么，否则日志一报错就无从下手。

先说运行边界，因为它决定你会不会在第一步白折腾。安卓版的运行层是 Debian 加 PRoot 的 ARM64 Linux 沙箱，里面的 Node、JRE 21、aapt、aapt2、apktool 都是 ARM64 版本。PRoot 负责把沙箱里的路径映射到应用私有目录，同时用用户态方式隔离文件系统。它依赖设备内核对 ptrace 的支持，也依赖 ARM64 指令集。因此，只有主 ABI 为 arm64-v8a 的手机和平板能正常跑完整链路。x86_64 模拟器即使通过翻译层装上了应用，也会在反编译入口直接停下，提示“当前版本仅支持 ARM64 设备”，既不会下载环境，也不会启动沙箱。这不是 CPU 主频不够，也不是内存不足，而是运行层架构与模拟器 ptrace 限制共同决定的硬边界。

怎么确认自己的平板是不是 ARM64？最稳的办法是看系统信息：设置里找到“关于平板电脑”，处理器一栏通常写着“八核”之类的营销词，不一定给出 ABI；这时可以装一个查看硬件信息的应用，看“支持的 ABI”列表里有没有 arm64-v8a。第二种办法是连电脑用 adb：执行 adb shell getprop ro.product.cpu.abi，返回 arm64-v8a 就符合。第三种最直接：安装安卓修改大师安卓版并打开，如果首页能进入环境准备而不是弹出架构提示，说明设备可用。三种方法任选一种，不要靠“跑分高不高”来判断。

系统版本的要求是 Android 10 及以上。当前构建的目标 SDK 是 36，对应 Android 16，所以在 Android 16 平板上运行没有问题；但“应用能运行”和“被修改的 APK 一定能被反编译”是两件事。Android 15、16 的系统资源表格式较新，沙箱里的 aapt2 有时读不了设备自带的框架资源。工具会先尝试设备自带的 framework-res.apk；读不了就改用内置的 Android 14 AOSP 框架包；仍然不行再退回 apktool 2.12.1 的 aapt1 路线。这套兜底逻辑会在日志里留下痕迹，第五节会逐行教你看。

路线一共十步，后面每一节对应一步或几步。先把地图记住，遇到问题时才知道自己停在哪一段：

1. 安装应用：从介绍页获取约 7.8 MB 的安装包，允许本次安装。
2. 准备环境：首次启动下载约 246 MB 运行环境，校验后解压到应用私有目录。
3. 选择文件：从文件夹选 APK，或从已安装应用里选自家应用。
4. 创建项目：为这次修改建立独立目录，保留原始包。
5. 看目录与日志：确认 apktool 工程、build 产物和日志位置。
6. 写需求：在 AI 工作台描述要改什么、不要改什么、怎么验收。
7. 自动回编：AI 修改完成后，apktool 重新打包。
8. 对齐与签名：ZipAligner 对齐，ApkSigner 生成 v1+v2+v3 签名。
9. 安装与分享：本机安装验证，或把成品发给内部测试同事。
10. 验收与清理：逐项检查图标、名称、启动页、版本、签名，然后清理测试项目、保留可回滚的包。

改包不是无中生有。你只能在自己有权的安装包上做资源与配置层面的调整，不能凭一句需求把别人的商业应用变成自己的产品。本文所有实例都默认你拥有源码、签名或书面授权；如果三者都没有，请先停下来解决授权问题，再谈技术。

二、安装与首次启动：7.8 MB 安装包与约 246 MB 环境

安卓修改大师安卓版的安装包约 7.8 MB，当前版本号为 50.06.00.00，版本代码 12。这个体积只包含应用界面、项目管理和打包编排逻辑，不包含反编译工具链。真正的运行环境在首次使用时按需下载，约 246 MB，来自官方下载地址，下载完成后按清单逐文件校验大小与 SHA-256，全部通过才解到应用私有目录的 env 下。这样设计的好处是安装包小、升级应用不必重下环境；代价是第一次启动必须联网，而且要把这 246 MB 完整走完。

第一步，在平板浏览器打开 https://www.apkeditor.cn/ai-version.aspx，找到安卓版的下载入口。下载完成后，通知栏或浏览器下载列表里会出现一个约 7.8 MB 的 APK 文件。点它，系统会弹出安装界面；如果提示“禁止安装未知应用”，点“设置”，把当前浏览器或文件管理器的“允许安装未知应用”打开，再返回继续。部分系统会弹出应用安全检查，说明这是未经应用商店分发的安装包，确认来源是 apkeditor.cn 后选择“仍要安装”。安装完成后，桌面会出现图标，名称就是“安卓修改大师”。

第二步，首次打开。横屏平板上，首页通常由三块区域组成：上方是产品名与状态提示，中间是项目列表或空状态，边上是导入、新建、设置等入口。空状态会引导你先准备运行环境。点“开始准备”或同义的按钮，应用开始下载环境包。你会看到进度百分比、已下载大小、当前阶段；下载完成后进入校验阶段，界面可能短暂显示“校验中”或“解压中”，此时不要切后台，也不要锁屏。整个流程分为下载、解压到临时目录、按清单校验、原子替换四段：先解到 env-staging，逐个文件比对大小和 SHA-256，全部通过后才替换正式 env 目录；任何一步失败都会保留旧环境，不会把可用环境弄坏。安装完成后，下载的压缩包会被删除，不长期占用空间。

第三步，确认环境可用。环境准备完成后，首页的状态会从“未准备”变成“就绪”，项目入口变为可点。此时可以顺手做一次自检：进入设置或环境信息页，确认 apktool 版本为 3.0.3（默认，只支持 aapt2），备用版本为 2.12.1（走 aapt1 兜底）；确认 JRE 为 21 的 ARM64 版本；确认 aapt 与 aapt2 已从 Debian 的 arm64 软件包离线安装。你不需要记住每个版本号，但要知道“默认链路”和“兜底链路”是两套，后面读日志时能把报错对上号。

环境准备失败并不罕见，尤其是网络不稳或平板剩余空间紧张时。下面这张表按现象给出排查顺序，照着做比反复重装有效：

环境就绪后，建议先拿一个体积小、结构简单的自家 APK 做一次空跑：只导入、建项目、不写需求，直接走完回编、对齐、签名，再安装。这个动作能验证工具链、磁盘空间、安装权限和签名链路是否都正常，避免真正改需求时把环境问题误判成 AI 改坏了。空跑通过，再进入下一节的文件选择。

三、选择文件：从文件夹导入，还是从已安装应用提取

安卓版支持从两条路选文件。第一条是系统文件选择器，从平板的下载、文档、网盘同步目录里挑 APK；第二条是从已安装应用列表里挑一个自家应用，直接读取它当前的安装包。两条路没有优劣，取决于你手里有什么：如果电脑上刚构建出 debug 包，用数据线拷到平板再选文件最直接；如果平板里就装着要改的内测版，从已安装应用导入能省一次传输，还能确保改的就是当前在跑的那一版。

先准备好自家 APK。Android Studio 构建完成后，debug 包通常在 app/build/outputs/apk/debug/ 下，release 包在对应渠道目录下。把文件拷到平板的 Download 目录，文件名保持英文和版本号，例如 ledger-1.6.0-internal.apk。不要依赖聊天软件传包：微信、QQ 接收后可能把后缀改成 .apk.1 或放进带哈希的子目录，选择器里看不到或解析失败。如果只能聊天软件传，接收后先重命名，补回 .apk 后缀，再移到 Download。

支持的格式不止 APK。导入入口同时接受 JAR、APKS、XAPK、APKM：APK 是单包；APKS 是 Android App Bundle 导出的分体包集合；XAPK 与 APKM 常见于第三方分发包，内部同样是 base 加多个 split。分体包导入时，工具会按包结构解析资源与清单。这里有一个容易踩的坑：自家应用如果用了 App Bundle 并按 ABI 或语言拆分，从“已安装应用”读到的可能只是当前设备匹配到的那一份，资源不一定完整。要做完整改包，优先从构建系统导出 APKS，或在 Gradle 里打一个包含全部资源的 APK，再导入。

选完文件后，信息卡是第一次“看到结果”的地方。重点看四行：包名是否与自家应用一致；版本名称与版本代码是否对得上；最低 SDK 是否低于你的平板系统；启动入口是否为空。启动入口为空通常意味着清单里没有可启动的 Activity，或者解析时没取到。这样的包可以反编译，但安装后可能没有桌面图标，验收时会误以为改坏了。遇到启动入口为空，先在电脑上用 aapt 或 Android Studio 的 APK 分析器确认原包是否本来就没有启动页；如果原包有而这里没有，换用 APK 格式重新导入，或者检查包是否被加固或加密。

导入失败常见于四类情况。第一类是文件不完整：下载中断、网盘同步未完成、聊天软件只传了缩略图，文件大小明显小于正常值。第二类是文件被加固或加密：普通 apktool 看到的是壳，资源和 dex 都不完整，反编译会失败或改完无法启动；这类包不在本文讨论范围，应先拿到自家未加固的构建产物。第三类是 AAB：Android App Bundle 不是安装包，不能直接导入，需要先导出 APKS 或通用 APK。第四类是路径问题：文件名含特殊字符、位于 Android/data 等受分区存储保护的目录，系统选择器干脆看不到。把文件移到 Download，改成英文名，通常就能解决。

还有一个与“文件”有关、但常被忽略的问题：目标 APK 里的原生库架构。你在 ARM64 平板上改包，回编签名后的 APK 要在这台平板上运行，就必须包含 arm64-v8a 的 so；如果自家应用只带了 x86 或 x86_64 的 so，改得再对也装不上或启动即崩。导入前用解压工具看一眼 lib 目录，或在 Android Studio 的 APK 分析器里确认 ABI。改包工具不会替你补原生库，它只处理清单、资源与 dex。这一点在验收阶段会以“安装成功但一打开就闪退”的形式出现，提前确认能省很多时间。

文件选对、信息卡核对无误，就可以创建项目了。创建动作看起来只是点一个按钮，实际上工具会做三件事：在 user-data/Project 下建一个独立目录；把原始 APK 复制成 source.apk；准备 apktool 工程与日志文件。下一节把这个目录拆开看，你会知道每个文件在哪、什么时候该看哪一个。

四、创建项目与项目目录：每个改包动作都有独立现场

在信息卡底部点“创建项目”，如果之前没改名，系统会用应用名加时间生成一个项目名。建议在创建前就改成自己能认出的格式，例如“记账-1.6.0-内测名”或“内部工具-主题色-1021”。项目名不是包名，不会写进 APK，只影响你在项目列表里怎么找。命名里带上版本与改动主题，一周后回头看不会只看到一堆“新建项目 1、2、3”。

点确认后，工具在应用私有目录的 user-data/Project 下新建一个独立项目目录，并把导入的 APK 复制为 source.apk。注意“复制”两个字：原始 APK 不会被移动，也不会被改动。之后 AI 修改的是反编译出来的工程，回编产物写在 build 下，source.apk 始终留着。这个设计让你随时可以对照原包、重新开始，或者在改坏时直接用原始包回滚。项目目录大致是下面这样：

项目创建成功后，点项目卡片进入详情。大屏平板上，详情页通常会把“概览、文件、日志、打包”分成几个页签或区块：概览显示图标、名称、包名、版本和当前状态；文件页进入内置文件浏览器；日志页直接打开 apktool.log；打包页负责回编、对齐、签名与产物。第一次进来不要急着点“开始修改”，先按顺序看一遍：版本对不对、source.apk 在不在、apktool 工程有没有展开、build 是否为空、日志末尾有没有报错。这五眼能排除八成“项目看起来建好了但根本没法改”的问题。

内置文件浏览器是平板改包的核心界面之一。它的用法接近桌面文件管理器：顶部是当前路径，中间是文件夹与文件列表，点文件夹进入下一层，点左上角返回上一层。文本查看器能打开清单、资源 XML、json、properties、log 等文本文件；部分界面还提供编辑与保存。大屏的优势在这里最明显：你可以左边开文件列表，右边开日志，底部再留一条 AI 对话框，不用在三个应用之间来回切换。用触控笔点路径、用键盘搜索关键字，比在手机上戳小图标舒服得多。

但文件浏览器不是让你手动改工程的地方。可以看、可以确认、可以在明确知道后果时改一处字符串；不要在 AI 已经改完后手动大段编辑资源，然后再让 AI 改一次。两条修改路径混在一起，出了问题很难判断是谁引起的。正确做法是：AI 改完，先用文件浏览器核对关键文件和修改时间；需要补改，就把补充要求写回工作台，让 AI 在完整上下文里再改一轮。项目目录是“证据”和“现场”，不是第二个编辑器。

空间要提前算。一个 APK 在项目里通常会产生三份主要占用：source.apk 一份；反编译工程一份，资源多的应用可能比原包大不少；build 产物一份。再加上 apktool 缓存与日志，整体占用可能是原包的数倍。一个 60 MB 的自家应用，项目目录很容易到 200 MB 以上；同时留三四个项目，1 GB 就没了。平板空间本来就紧张，建议一次只保留一个正在改的项目，验收完就把中间项目清掉，只留下原始包和最终成品。清理方法在第十节细讲。

项目的价值是“可重复”。source.apk 在，工程在，日志在，你就能解释这次改了什么、为什么这么改、失败在哪一步。只留一个最终 APK，等于把过程丢了；下次遇到同样的问题，还得从头试。

创建项目也可能失败。最常见的是空间不足：解析信息卡时只读了清单，真正复制 source.apk 和展开工程才吃空间，所以“导入成功、创建失败”很典型。先看应用私有目录剩余空间，再清旧项目。其次是同名冲突：连续点两次创建，可能出现两个同名项目，列表里分不清；删掉多余的那个，重新用带时间的名字建。第三是源文件消失：从网盘同步目录选的文件，创建时同步还没完成，复制到一半源文件被移走；把 APK 先落到本地 Download，再导入。第四是权限问题：从受保护目录选的文件，读取被系统拒绝；换到 Download 或文档目录。

五、日志与文本查看器：先看结尾，再倒着找第一处错误

改包出问题，九成答案在日志里。安卓修改大师安卓版把反编译和回编的输出写进项目目录的 apktool.log，打包过程另有一套可追溯的记录，最终产物与日志放在 build 相关位置。点项目详情的日志页，内置查看器会直接打开文本。大屏上可以双指缩放字号，也可以横屏让单行更长，减少折行。日志很长时，不要从第一行开始逐字读，先跳到末尾看最后一条是成功还是异常，再往回找第一处 error 或 exception，那里才是根因，后面的报错往往是连锁反应。

阅读顺序可以固定成四段。第一段看头部：工具版本、框架目录、目标 APK 路径。确认用的是 apktool 3.0.3 还是 2.12.1，框架是设备自带还是内置 AOSP 包。第二段看反编译结束处：资源是否全部解出，有没有“Could not decode”之类的行。第三段看回编：aapt2 编译资源、生成 dex、打包 APK 的过程，错误通常以“error:”开头。第四段看打包编排：对齐、签名、校验是否依次完成。把这四段和界面上的进度对应起来，你就知道当前停在哪一步。

Android 16 平板上最值得讲的一个真实案例，是 9patch 警告。某次把自家应用的启动页与弹窗背景换完，回编日志里连续出现十几行“Could not find 9patch chunk … Renaming it to *.png”。第一次看到会以为图片全坏了，实际上这是 apktool 2.12.1 对“伪 9patch”的标准兜底：APK 里有 18 个扩展名为 .9.png 的图片，每个只有 77 字节，内部根本没有 9patch 的 npTc 数据块。它们可能是占位图、被错误命名的普通图，或者构建时被压缩过的空资源。apktool 读不到数据块，就把文件重命名为普通 .png，后续按普通图片处理。改名后回编仍然成功，产物安装、启动、显示都正常，不影响结果。

正确处理方式是“先确认，再忽略”。确认三点：这些文件是不是你这次改动引入的；原包里是不是本来就有；回编最终是否成功、产物是否可安装。如果三点都指向“原包自带、回编成功”，就把这串警告当成噪音，不要为了消灭警告去删图或改扩展名。反过来，如果警告之后紧跟资源找不到、回编失败，那才需要处理：找到对应图片，确认是保留普通图还是补一张真正的 9patch。判断标准不是日志里有没有 warning，而是最终有没有可用产物。

另一类日志与框架有关。Android 15、16 的系统资源表比沙箱里的 aapt2 新，直接拿设备自带的 framework-res.apk 去反编译，可能报资源表版本或属性无法识别。工具的第一选择是设备自带框架；失败后切到内置的 Android 14 AOSP 框架包 framework-aosp14.apk；再失败才退回 apktool 2.12.1 的 aapt1 路线。切换时日志会显示使用的框架路径或 apktool 版本。你要做的是确认“反编译和回编用的是同一套框架”：反编译时用了 -p 指定框架目录，回编也要用同一个目录，否则资源 ID 对不上，表现是回编报资源不存在或安装后主题错乱。工具内部会保持这种一致性，你手动排查时不要只替换其中一个阶段。

文本查看器还有一个实用场景：确认 AI 到底改了哪些文件。AI 完成后，工作台通常会给出修改说明；不要只看说明，回到文件浏览器，按修改时间排序，逐个打开被改的文本文件。看三样：应用名对应的字符串是否只改了默认语言；版本字段是否同时改了名称和代码；图标引用是否同时覆盖了传统密度目录和自适应图标目录。发现改多或改少，先不要重新打包，把补充要求写清楚再让 AI 修一轮。日志能告诉你“有没有编过”，文件才能告诉你“改得对不对”。

如果日志页打不开，或者打开是空白，先回到项目目录看 apktool.log 是否存在、大小是否为 0。文件不存在，说明反编译还没真正开始，项目可能只完成了复制；大小为 0，说明进程在写日志前就退出了，通常是环境没就绪或存储不可写。这时不要反复点“重新打包”，先回首页看环境状态，再检查剩余空间。日志是结果，不是原因；原因通常在环境、空间、权限这三处。

六、AI 工作台：把“想要的样子”写成可执行的需求

项目建好、日志确认无误，进入 AI 工作台。横屏平板上，工作台一般占据右侧或下半屏：上方是对话记录，中间是输入框，旁边是发送按钮与附件入口，部分界面还会显示当前项目、当前步骤和运行状态。你在这里写自然语言，AI 把它翻译成对 apktool 工程的修改，改完自动触发回编、对齐、签名。整个过程不需要你敲命令，但需求写得清不清楚，直接决定返工次数。

一条可执行的需求，至少包含五要素：对象、位置、期望、约束、验收。对象是哪个应用、哪个页面、哪个资源；位置是桌面图标、应用名、启动页、主题色还是某个按钮；期望是具体的结果，不是“好看一点”；约束是不要动什么，例如包名、登录逻辑、网络请求、数据库；验收是你打算怎么判断成功，例如桌面显示新名字、冷启动看到新背景、深色模式不发白。把这五样写全，AI 不需要猜，回编失败率也会低很多。

实例一：自家记账应用换图标与内测名。这个应用由我们自己的小团队开发，包名固定，已经装了几个月，数据都在本机。目标很简单：把桌面图标换成新设计的账本图形，把显示名改成“随手记账 内测版”，版本名称加 -internal 后缀，其他一律不动。素材是一张 1024×1024 的透明 PNG，主体占画面约 70%，外圈留白，避免自适应图标裁切时切到边。

如果工作台有附件入口，把 PNG 附上，并在附件说明里写“桌面图标前景素材，透明背景，主体居中”；如果没有附件入口，就把素材先放进项目目录，再在需求里写清文件名和所在目录。两种方式都比一句“换个图标”可靠。发送后，工作台会输出执行过程：找到哪些资源、改了哪些文件、是否触发回编。大屏上可以一边看输出一边切到文件页核对，不用等全部结束才发现改错对象。

这个实例的验收点有四个。桌面图标：长按或进应用抽屉看，是否清晰、是否被圆形或方形遮罩裁切；应用名：桌面、设置的应用列表、关于页面三处是否一致；版本：设置里看到 1.6.0-internal，安装器识别到的版本代码比旧版大；功能：打开记账、新增一笔、查看报表，确认数据库和登录没被动过。四处都过，才算这次改包完成。只看到桌面变了就结束，很容易漏掉设置页仍显示旧名，或者版本代码没加导致覆盖安装失败。

实例二：自家内部工具换启动页与主题色。这个工具只在内网使用，装机量不大，但每天都要打开。原启动页是白底加一行小字，暗光环境下刺眼；主题色还是早期的蓝色，与现在的品牌绿不一致。目标是：启动页背景改成品牌绿 #0F6B5C，中部保留白色工具图标，按屏幕比例居中显示，不拉伸；主界面主题色同步为品牌绿，深色模式下背景与文字对比度要够；顺便把内网 API 地址从测试环境切到正式环境，版本名称改为 2.3.5-internal。约束是不要动证书校验、不要改包名、不要改登录方式。

这个实例比换图标多两个风险。第一是主题色不是一处颜色，而是主色、深色变体、强调色、状态栏、导航栏一组值；只改一个主色，界面会出现半新半旧。需求里要明确“同步主题色相关的一组值”，验收时至少看首页、列表页、弹窗、深色模式四个界面。第二是 API 地址切换：如果应用做了证书锁定或域名白名单，只改地址会导致请求全部失败。改之前先和后端确认正式域名是否已在白名单里；如果不在，要么让后端加白名单，要么这次先不改地址，只做视觉调整。不要用“关掉证书校验”来绕过，那是把安全问题当成改包技巧。

启动页在 Android 12 及以上有两层：系统级启动画面和页面内的自定义启动页。系统级画面由应用图标与窗口背景决定，页面内那层才是你写的背景图或主题。只改页面内背景，冷启动时仍可能先闪一下系统画面；只改系统画面，进入应用后又跳到旧背景。需求里最好写清“两层都检查”，验收时用冷启动（先划掉最近任务，再点图标）观察完整过程。Android 16 上还涉及边到边显示，状态栏与导航栏可能透明，启动页背景要延伸到系统栏后面，不能留一条白边。这些细节不写，AI 只能按默认处理，最后就要多改一轮。

工作台输出读完，不要立刻安装。先做一次“改动审计”：打开文件浏览器，按修改时间看最近变动的文件；对照需求逐条核对；确认没有动到包名、版本代码以外的清单项；确认图片资源没有变成 0 字节。审计通过再进入回编。AI 不是不会犯错，它最常见的错不是“改不了”，而是“改多了”或“改到了同名资源”。你把审计做成固定动作，返工就会少很多。

一次只改一类东西。先改图标与名称，验收通过；再改启动页与主题；最后改配置与版本。每轮都留下可安装的产物和日志，出问题时你能明确回到哪一轮，而不是面对一个“什么都改了”的包猜原因。

需求发送后，工作台会自动执行。平板上这段时间不要切后台、不要锁屏，也不要把大文件拷进拷出。AI 修改、回编、对齐、签名是一条连续的本地流水线，中间被杀掉，轻则重来，重则留下半成品产物。大屏的好处是你能看到当前阶段与已用时间；如果进度长时间不动，先看日志最后一行，再决定是等还是停。下一节把这条流水线的四段拆开讲。

七、自动回编、对齐、签名：四段流水线各自在做什么

AI 改完工程，工作台自动进入打包。界面上你会看到阶段提示与进度：正在回编、正在对齐、正在签名、正在校验。这四个动作顺序固定，不能颠倒。回编把 apktool 工程重新组装成 APK；对齐调整 ZIP 内部未压缩条目的偏移，让系统可以更高效地映射读取；签名在最终字节上生成 v1、v2、v3 三套签名；校验再确认签名确实写进去了。对齐必须在签名之前，因为 v2、v3 签名覆盖的是整个文件内容，签名后再移动字节，签名立即失效。工具把顺序编排好，你只需要理解为什么不能手动打乱。

回编默认走 apktool 3.0.3，只支持 aapt2。aapt2 对资源语法的要求比旧的 aapt1 严格：颜色值格式不对、主题属性写错、XML 标签没闭合，都会在编译阶段直接报错并停下。好处是错误暴露得早，坏处是 Android 15、16 的新资源表可能让沙箱里的 aapt2 读不了框架。遇到框架不兼容，工具按前面说的顺序退回内置 AOSP 框架，再不行切 apktool 2.12.1 走 aapt1。你在日志里会看到版本或框架路径变化，不要以为工具“换了个软件”，这只是同一条链路的备用轨道。

对齐的意义常被误解。它不是“压缩得更小”，而是让 APK 里未压缩的条目按固定边界排列，系统可以直接把资源映射进内存，减少启动时的解压与拷贝。对齐做得好不好，用户感知不到，但安装器与运行时会做检查；对齐被破坏的包可能仍能安装，却在某些设备上启动变慢或读取失败。因为对齐会移动字节，它必须发生在签名之前；反过来说，任何“签完名再优化一下 ZIP”的动作都会毁掉 v2、v3 签名。安卓版把 ZipAligner 放在回编与 ApkSigner 之间，就是为了守住这个顺序。

签名一次生成三套方案。v1 是 JAR 签名，逐文件摘要，兼容老系统与部分校验工具；v2 是 APK Signature Scheme v2，对整个文件做摘要，验证更快、篡改成本更高；v3 在 v2 基础上增加密钥轮换等能力，Android 9 及以上支持。三套同时写入，意味着新系统优先用 v2 或 v3 校验，老工具仍能读到 v1。安卓版的最低系统是 Android 10，理论上 v2 就够，但保留 v1 能让一些企业分发工具、旧版校验脚本、第三方安装器也能识别，减少“手机上能装、同事电脑上的工具说包坏了”的争论。

这里必须讲清一个现实问题：重新签名会改变证书。Android 判断两个 APK 能否覆盖安装，第一看包名，第二看签名证书；包名相同但证书不同，安装器会拒绝，报“应用签名不一致”。如果你改的是已经用正式证书上架的应用，而安卓版在本地重新签名时用的不是同一张证书，那么成品不能直接覆盖旧版。处理方式有三条：内测阶段先导出应用数据，卸载旧版再装新版；给内测包使用独立的包名或独立的测试签名，与正式版并存；正式发布仍然回到公司原有的签名流程，不拿本地重签的包去覆盖线上版本。三条都要提前决定，不要等安装报错才想。

版本代码同样影响覆盖安装。Android 不允许用更低的版本代码覆盖更高版本，除非用调试参数强制降级。改版本时，版本名称可以随意改成 1.6.0-internal，版本代码必须在原基础上加一；只改名称不改代码，安装器仍认为这是同一个版本，有时能装、有时提示无更新。AI 需求里要把“版本代码加一”单独写一条，验收时用系统包管理信息复核，而不是只看设置页显示的版本名称。包名、版本代码、签名证书，是覆盖安装的三把锁，缺一把都装不上。

打包过程中不要做三件事：不要锁屏，不要切到后台长时间刷视频，不要把几十 GB 的照片往平板里拷。这些动作会抢 I/O，甚至让系统杀掉后台进程。大屏平板通常能边看进度边做轻量笔记，但不要把“边打包边剪视频”当成多任务能力测试。进度长时间停在同一阶段时，先点开日志看最后一行；如果最后一行是资源编译错误，等多久都不会自己好；如果只是长时间无输出，可能是大包在生成 dex，再等一会儿；超过你平时处理同类包的时长时间仍未动，就停掉重跑，并保留日志。

八、安装与分享：本机验证完，再发给测试同事

签名完成后，项目详情会出现成品入口，通常提供“安装”“分享”“打开所在目录”三个动作。先安装到本机，不要急着分享。点安装，系统包安装器会接管；第一次从该应用安装，可能要求给安卓修改大师安卓版“安装未知应用”的权限，按提示打开即可。部分系统还会弹应用安全检查，确认包来自你自己的本地构建后继续。安装完成后，安装器会给出“打开”和“完成”，先点“完成”，回到桌面用图标冷启动，这样看到的是真实的启动链路，而不是安装器直接拉起的页面。

第一次启动会比平时慢，因为系统要为新的 dex 做编译与优化，尤其是大应用。不要在第一帧还没出来时就判定“改坏了”，给它几秒。真正需要警惕的是三种情况：安装器直接拒绝；安装成功但桌面没有图标；点图标立刻闪退。第一种看安装器错误码，第二种回项目确认启动入口是否为空、清单是否被改坏，第三种接日志或看系统崩溃记录。三种问题的排查路径不同，不要混在一起猜。

本机验收通过后，再分享。点“分享”，系统分享面板会列出微信、QQ、企业微信、网盘、蓝牙等目标。选择内部测试群或同事，发送 APK 文件。分享前做两件事：把产物文件名改成可识别的格式，例如“随手记账-1.6.0-internal-1021.apk”，不要用一串哈希；在消息里写清安装说明，尤其是“这是自有应用的内测重签包，安装前请卸载旧版并备份数据”。收到文件的人如果看到后缀被聊天软件改掉，需要先重命名补回 .apk，再在文件管理器里打开安装。不要把内测包发到公开群、论坛或网盘公开链接，授权范围之外的人不应该拿到它。

分享前还建议记录证书指纹。在电脑上对最终 APK 执行 apksigner verify --print-certs 成品.apk，输出会列出 v1、v2、v3 的验证结果与签名证书 SHA-256。把指纹记在项目记录里，下次更新时先比对：指纹一致，才能覆盖安装；不一致，就必须按新包处理。这个动作看着麻烦，却能避免“测试同事装不上、开发这边能装”的扯皮。没有电脑时，打包日志里的签名信息也能作为线索，但正式分发前最好用 apksigner 再核一次。

分享不是终点，回滚预案要同时准备好。每次打包前，把上一版可安装的 APK 留在平板的固定目录，命名带日期与版本；项目里的 source.apk 也保留。新包出问题时，先卸载新包，再装回上一版；如果新包改了包名，旧包可以并行安装，回滚更简单。应用数据是否保留，取决于你是否卸载以及应用自身的备份能力；重要数据在改包前用应用内导出功能备份，不要指望系统备份一定覆盖。回滚方案写进测试说明，比事后临时找包靠谱。

九、大屏验收：图标、名称、启动页、版本、签名逐项过

大屏验收不是“看一眼觉得对了”，而是按清单逐项确认。平板横屏能同时展示桌面、设置和关于页面，减少来回切换；但屏幕大也容易漏细节，尤其是图标边缘、深色模式、系统栏颜色。下面这张清单按用户实际会看到的顺序排列，建议每改一版都从头过一遍，并把结果记在项目备注里。勾选不是形式，它是你下一次改版的对照基线。

图标要分三层看。传统图标是各密度目录下的方图，自适应图标是前景与背景两层，系统会按启动器形状裁切；Android 13 及以上还有主题图标，系统会用单色层染色。只换传统图标，新系统上可能仍显示旧的自适应图标；只换前景不换背景，圆形遮罩下可能露出一块不协调的底色；主体画得太满，圆形裁切会把边角切掉。验收时至少在标准桌面和圆形图标模式下各看一次，再长按图标看快捷菜单里的小图。大屏平板的启动器网格更大，图标显示尺寸也更明显，瑕疵更容易被发现。

名称要分三处看。桌面标签来自启动入口的标签；设置里的应用名来自应用级标签；关于页面可能是代码里写死的字符串，也可能是资源引用。只改资源，关于页面里硬编码的旧名不会变；只改默认语言，切换到英文或繁体后可能又变回旧名。实例一里我们要求“默认中文生效，英文资源保留原名称”，验收时就要把系统语言切到英文再看一眼，确认没有把英文名也改成中文。多语言不是越多越好，而是每种语言都自洽。

启动页要按“冷启动全过程”看。先在最近任务里划掉应用，确保进程不在；再点桌面图标，观察从点击到首页出现的每一帧：系统启动画面、自定义启动页、首页。三层之间如果有白闪、黑闪、尺寸跳变，说明背景色或图标层次没对齐。横竖屏各来一次，平板还要试分屏与自由窗口，因为不同窗口比例会触发不同的资源限定符。Android 16 的边到边显示会让状态栏透明，启动页背景要铺到系统栏后面；如果只铺到安全区，顶部会留下一条不同颜色的带。深色模式下再走一遍，确认背景与图标对比度足够。

版本与签名要一起看。设置页通常只显示版本名称，不显示版本代码；要确认代码是否加一，用 adb 查看包信息，或者在电脑上把 APK 拖进 Android Studio 的 APK 分析器。签名用 apksigner 验证，重点看三行：v1、v2、v3 是否都通过，签名证书的 SHA-256 是否与你的记录一致，签名方案里有没有缺失。指纹不一致不一定是错，可能只是这次用了不同的签名材料；但对需要覆盖安装的场景，它就是硬错误。把指纹写进验收记录，下次升级前先比对，能避免大部分“装不上”的问题。

实例一的验收重点是“只改该改的”。桌面显示“随手记账 内测版”，图标是新的账本图形；设置里名称一致；关于页面版本为 1.6.0-internal；打开后新增一笔、查看报表、退出重进，数据都在；包名仍是原来的，签名指纹记录在案。实例二的验收重点是“视觉与配置同时成立”。启动页在横屏与竖屏都居中，无拉伸；首页、列表、弹窗主题色统一；深色模式没有白底白字；内网 API 请求成功，登录正常；版本为 2.3.5-internal。两个实例都不要只看一张截图就结束，动态路径和异常路径才是最容易暴露问题的地方。

验收记录至少写四行：包名与版本、签名指纹、改了哪些资源、冷启动与核心功能是否通过。四行字，能让一个月后的你或接手的同事少走很多弯路。截图可以删，记录不要删。

大屏还有一个容易忽略的验收场景：分屏与悬停窗口。平板可能同时开文档与改包工具，应用窗口被压成窄条，启动页与首页布局会走不同的资源分支。改完启动页后，把应用拉到分屏右半边，再冷启动一次，看看背景是否仍然完整、按钮是否被挤出屏幕。Android 16 对大屏窗口更友好，但前提是资源里提供了对应布局；如果原应用本来就没适配，改包也不应该假装它适配了。验收的边界是“改动没有引入新问题”，不是“把原应用的适配债一次还清”。

十、清理与回滚：把现场收好，下一次还能复现

改包完成不等于工作结束。平板空间有限，项目目录、反编译工程、build 产物会一层层堆积；内部工具的安装包里还可能带着内网地址、测试账号提示、未公开的页面结构。清理不是简单地点“删除”，而是先决定留什么、再决定删什么、最后确认删干净。一个健康的节奏是：每个应用保留一个“黄金项目”和一份可安装成品，其余试验项目在验收后当天清掉；环境目录不动，日志与验收记录单独留档；分享出去的测试包在测试结束后提醒对方删除。

先留证据，再删项目。打开项目详情，把最终 APK 复制到平板上一个固定目录，例如 Download/改包归档/应用名/版本/；需要保留工程时，用保存源码 ZIP 的能力把 apktool 工程打包，和成品放在一起；把 apktool.log 与打包日志导出或截图，至少留下最后一轮的记录；在备注里写清包名、版本名称与代码、签名指纹、改动清单、验收结论。做完这四件事，项目目录就可以删了。只删项目、不留成品，下次想回滚还得重新导入；只留成品、不留日志，出了问题只能猜。两边都留一份，成本很低。

项目删除建议从项目列表操作，不要直接进文件管理器删目录。列表删除会同步清理项目索引；手动删目录可能留下“列表里有、目录已空”的僵尸项目，点进去只会报错。如果确实需要手动处理，先退出应用，确认目录路径在 user-data/Project 下，删除后重启应用让列表刷新。删除前问自己三个问题：最终包导出了吗？日志留了吗？这个项目里有没有别处没有的素材？三个答案都是“是”，再动手。

环境目录是另一类。files/env 里是 Debian、Node、JRE、apktool 与框架包，约 246 MB 解压后的占用，删了就得重新下载。日常清理不要碰它，也不要为了“释放空间”去删其中的单个工具，缺一个文件就会让整条链路报错。环境更新失败时，工具会保留旧环境；这是有意的保护，不是残留垃圾。如果怀疑环境损坏，重新走一次环境准备流程，让下载、校验、解压、原子替换从头执行；不要在文件管理器里东删一个目录、西改一个文件名。应用数据清理更要谨慎：清除应用数据会同时删掉项目、环境和设置，相当于回到刚安装的状态。

回滚分四种场景，处理方式不同。视觉回滚：新图标或新启动页不满意，直接装回上一版 APK；如果包名与签名一致，覆盖安装即可，数据保留。配置回滚：API 地址改错导致连不上，回到项目把地址改回，重新打包；如果旧版还在，也可以先装回旧版恢复使用。项目回滚：工程被改乱，删掉当前项目，用 source.apk 重新建一个，从干净的反编译结果开始。环境回滚：环境更新后异常，保留项目，重新准备环境；旧环境在替换失败时会被保留，成功替换后则以新环境为准。四种场景不要混用同一种“重装试试”，否则会把可恢复的问题变成不可恢复。

清理还有一个安全维度。内部工具的安装包可能包含内网域名、测试入口、未公开的功能开关；一旦发到公开渠道，即使没有恶意，也会扩大暴露面。分享时用点对点或受控的内部群，不用公开链接；测试结束后在群里说一句“请删除测试包”，并确认网盘分享已取消。项目目录里的日志同样可能包含包名、路径、接口地址，发日志给同事排查时先扫一眼有没有敏感信息。改包是技术活，分发是管理活，两边都要有边界。

做完一次完整流程，建议给自己留一段复盘：这次卡在哪一步、日志里第一处错误是什么、需求里哪句话导致了返工、下次要提前确认什么。把这些写进项目备注，比记住“下次注意”有用。安卓修改大师智改工坊把工具链收进平板，缩短的是操作路径；真正让效率提升的，是你对边界、验收和回滚的把握。工具会升级，项目会删除，这套方法可以一直用。

用户评价：五种角色，五种关注点

“我主要用 ARM64 平板改自家应用，屏幕大，文件树、日志和对话框能同时摆开。第一次要下约 246 MB 环境，之后就不用重复下。之前试过在 x86_64 模拟器里打开，入口直接提示只支持 ARM64，换回平板就正常。这个边界提前知道，能少折腾很多。”

—— 陈默，独立开发者、平板用户

“我们内部工具不适合上架，以前换个启动页要等外包排期。现在把自有版权的包导进来，品牌色、横竖屏、深色模式一次写清，改完直接分享到内部群。最看重的不是快，而是每次都能在项目里找到改了什么、为什么回编失败。”

—— 林岚，小团队安卓开发

“我最怕的是签名不一致导致同事装不上。现在每次发内测包之前，都会先用 apksigner 看证书指纹，再在群里写清要不要卸载旧版。工具把回编、对齐、签名串起来，省了记命令；但签名策略这件事，还是得自己负责。”

—— 周启，企业信息化负责人

“实验室的平板是 Android 16，第一次回编看到十几行 9patch 警告，以为图全坏了。后来按日志提示确认，那些只是 77 字节的伪 9patch，改名后回编成功，安装也正常。现在我读日志先看结尾，再倒着找第一处真正的错误。”

—— 许知，高校实验室工程师

“我是设计转产品，不会写命令行。把自己画的图标和启动页放进工作台，用大白话写清主体不要被裁、深色模式用哪套色，改完能在桌面直接看到。它不能替我做复杂功能，但做视觉验收和内测包装，沟通成本低了很多。”

—— 苏禾，设计转产品

五条评价放在一起，关注点其实很集中：边界要提前知道，需求要写具体，日志要会读，签名要能追溯，验收要有清单。安卓修改大师安卓版把反编译、回编、对齐、签名收进平板，确实缩短了操作路径；但它不会替你判断素材版权、不会替你决定签名策略、也不会替你对内部包的分发范围负责。把这些判断做好，工具才是加速器，而不是新的风险源。

最后把合规边界说清楚。本文所有操作都只适用于你拥有自有版权、或已取得版权方明确书面授权的应用。请勿用于破解、去除付费限制、绕过安全机制、伪造他人品牌或侵犯知识产权。换图标、改名称、换启动页看起来只是资源替换，但用在别人的商业应用上，同样可能构成侵权或不正当竞争。也不要为了“研究”去修改金融、政务、医疗等敏感应用，或把改包后的应用重新分发。技术能力的边界，应该由授权来划定；请勿用于破解，也不要把内部测试包变成公开传播的版本。

到这里，一条完整的平板改包链路就走完了：安装约 7.8 MB 的安卓修改大师安卓版，首次准备约 246 MB 环境，从文件夹或已安装应用选择自家 APK，创建项目，看目录与日志，在 AI 工作台写需求，自动回编、对齐、签名，安装与分享，最后按清单验收并清理回滚。你可以从最小的动作开始：先只改应用名，跑通全链路；再加图标；最后碰启动页与主题色。每多走一轮，你对日志、签名和边界的理解就更深一层。安卓修改大师智改工坊希望把重复劳动压缩，把判断、审美和责任留给你自己。

准备开始的话，从官方介绍页获取安装包，确认设备是 Android 10 及以上的 ARM64 手机或平板，准备好自家 APK 与素材，按本文的顺序走一遍。官网是 www.apkeditor.cn，介绍与下载页是 https://www.apkeditor.cn/ai-version.aspx。记住这句话：只需说话，就能让应用变成你想要的样子。真正动手时，再把这句话拆成一条条可执行、可验收的需求。