经典版导出 Android Studio 工程后怎么继续维护

安卓修改大师智改工坊这次把镜头对准一个很容易被忽略的环节：工程已经从修改大师经典版里导出来了，接下来怎么维护。导出并不等于结束，它更像是把一间刚装修好的房子交到你手里，水电线路都在，但哪根线接哪里、哪个开关控制哪盏灯，需要你自己摸清楚。经典版走的本来就是手动精修路线，反编译、改 smali 与资源、回编、签名，每一步都看得见、改得动，所以导出的 Android Studio 工程也应当被当成一份可以长期维护的资产，而不是一次性的中间产物。

如果你习惯了一句话改包、改完就装的节奏，第一次打开导出工程可能会不适应：目录很多、报错很密、Sync 一跑就是一片红。这很正常。手动路线的价值恰恰在于，每一个红色错误都指向一个具体的、可以解释的原因，修好之后你知道它为什么好，下次再遇到同类问题也能自己判断。本文按八个环节展开，每个环节都写清三件事：怎么做、做完应该看到什么、没看到时先查哪里。你不需要一次记住全部，按顺序走一遍，再回头查表即可。

需要先说明边界：本文讨论的是你自己开发、或者已经获得授权的应用。自有版权是继续维护的前提，请勿用于破解、去除付费限制或绕过他人的安全机制。官网 www.apkeditor.cn 上有各版本的说明，介绍页 https://www.apkeditor.cn/ai-version.aspx 也放在文末，方便你对照自己手上的版本。经典版是 Windows 桌面工具，环境要求 ASP.Net 4.5+ 与 JDK 1.8+，安装包约 13.74 MB，与智能修改电脑版可以同机安装，项目互不冲突。

顺便把路线说清楚：如果你只是想让自家应用换个图标、改个文案、调个启动页，智能修改电脑版和智能修改安卓版提供了更轻的路径，只需说话，就能让应用变成你想要的样子；而经典版负责的是导出之后那段需要人手接管的深水区，改 smali、改资源、接第三方 SDK、做多渠道包，都是它更擅长的场景。两条路线不冲突，很多团队是先用轻量方式定方向，再用经典版做精修和交付。

一、导出的工程到底是什么：先看清结构再动手

从经典版导出 Android Studio 工程，本质上是把反编译得到的清单、代码、资源、so 库和 assets 重新组织成 Gradle 能识别的形状。不同版本、不同选项导出的内容会有差异，所以第一步不是急着点 Sync，而是做一次只读体检。体检的目的只有一个：你能用一张表说清楚每个目录是干什么的，哪些东西可以改，哪些东西一动就会牵连全局。这个习惯能帮你省掉后面大量的返工。

建议先复制一份导出目录做只读快照，命名成 export-baseline-日期，压缩存档后再开始动工。快照的意义在于对照：后面无论改错哪一步，你都能回到最初的样子，而不是在一堆已经变形的文件里猜哪里出了问题。随后按下面的顺序列目录，边看边记，不要跳过。

export/
  settings.gradle
  build.gradle
  gradle/wrapper/gradle-wrapper.properties
  app/
    build.gradle
    src/main/AndroidManifest.xml
    src/main/java 或 src/main/smali
    src/main/res
    src/main/assets
    src/main/libs
    src/main/jniLibs
    proguard-rules.pro

看到这份结构，先判断三件事。第一，构建骨架是否齐全：有没有 settings.gradle、根 build.gradle、app/build.gradle、wrapper 配置。缺哪一层就补哪一层，补的时候以导出目录里的包名、版本号、SDK 版本为准，不要凭印象填。第二，代码形态是什么：如果只有 smali，说明后续改动仍以 smali 为主，Android Studio 在这里主要承担资源编辑、依赖管理和打包；如果同时给了 java 或 kotlin 目录，也要先确认它们和 smali 是否重复，避免同一套逻辑被编译两遍。第三，资源是否完整：res 下的 layout、drawable、values、mipmap、xml、raw 是否都在，assets 里有没有题库、离线网页、模型文件这类大体积内容。

接着建立原包基线。用 aapt 或同类工具把原始 APK 的关键信息导出来，存成文本文件放进工程根目录的 docs 目录，命名 baseline.txt。需要记录的项目包括包名、versionCode、versionName、minSdkVersion、targetSdkVersion、应用名、启动 Activity、屏幕密度、支持的 ABI、签名方案。后面每次构建完，都拿新产物和这份基线对一遍，很多“看起来没问题”的改动就是在这张表上露馅的。

位置	作用	先看什么	常见坑
AndroidManifest.xml	声明包名、组件、权限、SDK 版本	package、application、provider、queries	合并后被第三方库改写，authority 冲突
smali 目录	反编译后的字节码源码	包名层级、方法签名、寄存器数量	手改后寄存器不配对，回编能过但运行崩溃
res 目录	布局、图片、字符串、颜色、主题	values 多语言、drawable 密度、xml 引用	资源名含大写或非法字符，AAPT 直接报错
assets 目录	原样打包的离线内容	文件名大小写、路径引用、体积	改了文件名但代码仍按旧路径读取
libs 与 jniLibs	第三方 jar、aar 与原生 so	ABI 子目录、重复 jar、版本号	同一 SDK 既放 jar 又引 Maven，重复类爆发

这一步的预期结果很具体：你能在 docs 目录里拿出 baseline.txt 和一张目录说明表，能指出哪些文件是“只读参考”、哪些是“可改”、哪些是“改前必须备份”。如果打开工程发现没有 Gradle 骨架，不要慌，先按导出目录里的包名与版本补一份最小骨架，再进入下一步；如果发现清单里中文乱码，先统一成 UTF-8 再保存，避免后续合并时把乱码带进产物；如果 smali 的目录层级和包名对不上，先记下来但不要改，等 Gradle 能同步之后再处理，否则你会在两个问题之间来回打转。

还有一个容易被忽略的点：先确认导出工程里的 applicationId 与原始包名是否一致。维护自家应用时，通常要保留原包名，已安装用户才能覆盖升级；如果为了和原应用共存而加了后缀，就要接受“新包是另一个应用”的事实，签名、权限、数据目录都会分开。这个决定要在动手前做完，不要等打包时才想起来改，否则后面所有的对照都会失去基准。

二、导入 Gradle：JDK、AGP 与 SDK 的三重对齐

工程导入 Android Studio 后，第一道坎几乎总是 Gradle Sync。Sync 失败并不可怕，可怕的是同时改五六个地方，最后不知道是哪一处起了作用。正确做法是把变量分开：先对齐 JDK，再对齐 Gradle 与 Android Gradle Plugin 的版本，最后对齐 compileSdk 与构建工具。每改一项就 Sync 一次，让结果可归因。

先说 JDK。经典版本身要求 JDK 1.8+，这是工具运行环境的要求；而导出工程用什么 JDK 编译，取决于工程里的 Android Gradle Plugin 版本。两者不是一回事，不要混为一谈。较新的 AGP 需要 JDK 17，稍早一些的需要 JDK 11，更老的才用 JDK 8。最稳妥的查法是看根 build.gradle 或 settings.gradle 里声明的 AGP 版本，再按官方兼容表选 JDK。在 Android Studio 里把 Gradle JDK 指到对应版本，项目级的 Java 兼容性设置也一并核对，避免“IDE 用 17、命令行用 8”这种隐蔽的不一致。

再说 Gradle 与 AGP。wrapper 配置里写着分发地址和版本号，这个版本必须能支撑当前的 AGP。AGP 8.x 通常要 Gradle 8.x，AGP 7.4 附近要 Gradle 7.5 以上，AGP 7.0 要 Gradle 7.0.2 以上，AGP 4.2 要 Gradle 6.7.1 以上。版本不匹配时，报错往往不是直接说“版本不对”，而是抛出一段看不懂的类加载异常或方法缺失。遇到这类报错，先怀疑版本组合，再怀疑代码。升级 wrapper 时只改 distributionUrl，让 Gradle 自己下载对应版本，不要手工替换安装目录里的文件。

第三是 SDK。compileSdk 对应的平台必须已经安装，targetSdk 决定运行时的行为边界，minSdk 不能高于工程里任何依赖要求的下限。导出工程如果来自一个较老的应用，compileSdk 可能停在很低的版本，而你现在引入的第三方库要求更高的 compileSdk，这时要么升级编译版本，要么换库，不能靠改一行数字硬压。构建工具、平台工具、命令行工具也建议一起检查，缺少时在 SDK Manager 里补齐，比在报错里猜快得多。

依赖仓库也要检查。较新的工程把仓库声明放在 settings.gradle 的 dependencyResolutionManagement 里，老工程放在根 build.gradle 的 allprojects 里。google() 与 mavenCentral() 是基础，第三方 SDK 往往还要加厂商自己的仓库地址。公司内网环境可能需要镜像或代理，这类配置写在用户级初始化脚本里更合适，不要提交到团队仓库，否则每个人都要改一遍。离线模式只在依赖已经缓存完整时使用，首次导入不要开，否则会把“下载失败”误判成“依赖不存在”。

报错关键词	大概率原因	处理顺序
Unsupported class file major version	JDK 与 AGP 或 Gradle 不匹配	先固定 Gradle JDK，再核对 AGP 版本
Could not find com.android.tools.build:gradle	仓库缺失、网络不通或版本号写错	补 google()，核对版本是否存在
SDK location not found	local.properties 缺失或路径错误	让 IDE 重新生成，不要提交该文件
Plugin with id 'com.android.application' not found	插件仓库未声明或 AGP 未下载	先查 settings.gradle 的插件管理块
Namespace not specified	新 AGP 不再从清单读取 package	在 app/build.gradle 补 namespace

当 Sync 通过、任务列表能正常展开，这一步就算完成。预期结果是：IDE 不再提示“项目配置有问题”，Gradle 面板里能看到 app 模块的 assembleDebug、installDebug 等任务，命令行执行 gradlew tasks 能正常输出。如果 Sync 仍然失败，先看第一条错误而不是最后一条，Gradle 的报错会层层包裹，真正的起因通常在最上面。把完整日志保存到 docs 目录，注明当时的 JDK、AGP、Gradle 版本，下一次换机器时可以少走很多弯路。

三、修依赖与资源 ID：把编译错误逐个消掉

Sync 通过只是说明工程结构被认出来了，真正考验耐心的是编译。第一次点 Make Project，通常会看到两类错误：一类是依赖找不到，一类是资源或符号找不到。不要一口气全改，按“依赖先于资源、资源先于代码”的顺序处理，因为依赖没齐时，资源报错往往是假象。先把 app/build.gradle 的依赖块整理清楚，再谈其他。

依赖块里常见四种写法：本地 jar 或 aar 用 files 引入，同仓库模块用 project 引入，公开库用坐标引入，编译期注解处理器单独声明。每种写法都有适用场景，也都有坑。本地 aar 不会自动带上它自己的依赖，缺什么要手动补；坐标引入会连带解析一长串传递依赖，版本冲突也由此而来；注解处理器如果误写成普通实现依赖，编译能过但生成的代码不参与打包，运行时会报类找不到。整理时给每个依赖加一行注释，写清楚它属于哪个功能、从哪个 SDK 来，三个月后你还会感谢现在的自己。

资源错误里最常见的是 R 引用失效。表现是代码里写着 R.layout.xxx、R.string.xxx，但对应的资源在导出目录里不存在，或者名字被改过。处理方法是回到只读快照里搜原名，确认它是被删了、被改名了，还是被放进了另一个限定目录。能补回就补回，确实不需要就把引用改成现有资源，不要为了消错随手新建一个空文件，空布局或空字符串会把问题推迟到运行时。对于 smali 代码，还要多一层警惕：反编译产物里经常直接写死资源 ID 的数字，工程重新编译后资源表可能重新排布，数字对不上就会加载错资源。维护这类工程时，要么保持资源集合与顺序稳定，要么在每次回编后核对关键 ID 的映射，别只看编译是否通过。

资源命名本身也有硬规则。文件名只能用小写字母、数字和下划线，不能出现大写、空格、横杠；点九图必须是真的点九图，边缘黑线要规范，否则 AAPT 会直接拒绝；矢量图在不同 API 级别上的兼容性要确认，低版本设备可能需要生成兼容位图。多语言目录要成对出现，缺翻译时给默认值，确实不需要翻译的字符串标记为不翻译，避免发布前被语言检查拦住。图片密度目录不要随意复制，同一张图在多个密度里重复放置只会让包体变大，不会让显示更清晰。

还有一类错误来自资源合并。第三方库自带资源时，同名资源会按优先级覆盖，字符串、颜色、样式都可能被库里的默认值顶掉，表现出来就是“我明明改了，安装后还是旧样子”。排查时先看合并后的资源报告，确认最终采用的是哪一份；如果是库资源覆盖了应用资源，可以在应用侧显式声明同名资源，或者用资源前缀把自家资源隔开。构建类型里如果开了资源压缩，还要检查动态读取的资源有没有被误删，反射使用的资源要放进保留规则，不能只靠编译器猜。

资源修完后，建议单独跑一次资源处理任务，而不是直接全量编译。资源任务通过，说明清单、资源表、符号生成这条链路是通的；这时再去编译代码，报错范围会小很多。预期结果是：资源处理任务成功，R 符号能正常生成，代码里不再出现“找不到符号”的红线。如果仍然报错，优先看第一条，它通常指向真正的源头，后面的错误很多是连锁反应。

依赖与资源都理顺后，把 app/build.gradle 里与构建类型相关的开关检查一遍。调试包不建议开代码压缩和资源压缩，否则断点、日志、反射都会变得难以预料；发布包再逐项打开，并且每开一项就完整测一遍。签名配置、版本号、应用后缀这些内容也在这里，先把调试链路跑通，再动发布配置，顺序反了会多花一倍时间。

四、重复类与第三方 SDK：冲突从哪来、怎么解

手动维护导出工程，迟早会撞上“重复类”。报错通常长这样：Duplicate class xxx found in modules a.jar and b.aar。它的含义非常直白：同一个全限定类名，在两个地方各出现了一次，打包工具不知道该用哪个。根因无非三种：同一个库被引了两遍，不同版本的同一个库同时存在，或者旧的支持库与新库混用。解决思路不是见到重复就排除，而是先搞清楚这两个副本分别是谁带进来的。

诊断从依赖树开始。运行依赖查看任务，把 debug 运行时的依赖树导出到文件，按关键字搜索报错里的类名或库名，看它是直接依赖还是被谁传递引入。如果是两个版本并存，用依赖洞察任务看清版本冲突的走向，再决定是统一版本还是排除旧版。统一版本通常更安全，排除某个传递依赖要谨慎，因为被排除的模块可能还带着必要的资源或原生库。每次调整后重新导出依赖树，确认只剩一份，再继续编译。

gradlew.bat :app:dependencies --configuration debugRuntimeClasspath
gradlew.bat :app:dependencyInsight --dependency 库名 --configuration debugRuntimeClasspath
gradlew.bat :app:assembleDebug --stacktrace

如果重复来自“jar 与 Maven 各放了一份”，处理方式是把本地 jar 删掉，只保留坐标依赖；如果本地 jar 是厂商定制版、仓库里没有，就把坐标依赖去掉，只留本地文件。最忌讳的是两边都留，再用排除规则遮住报错，因为运行时仍可能加载到错误的那一份。对于 aar，除了类重复，还要注意资源重复和清单重复，三者往往一起出现，只解决类冲突并不能让应用正常跑起来。

第三方 SDK 接入时，清单合并是第二个高频冲突点。库自带清单里可能声明了应用类、内容提供者、权限、启动 Activity，合并进主清单后可能与现有配置打架。典型表现是：应用启动就崩，日志指向某个 provider 的 authority 重复；或者两个库都要设置应用类，后合并的覆盖了先合并的，导致另一个库没有初始化。处理这类问题，优先用占位符把 authority 参数化，让不同构建类型拿到不同值；确实需要覆盖时，用清单合并工具显式声明替换或移除，并在注释里写清原因。不要直接删库清单里的节点，升级库时会被覆盖回来。

SDK 的初始化顺序也值得单独拿出来说。很多库要求在应用启动时按固定顺序初始化，先隐私合规，再设备标识，再业务模块。顺序错了，表现可能是偶发崩溃、上报缺失、登录失败，而且日志里不一定有直接提示。维护导出工程时，把初始化集中到一个入口类里，按依赖关系排列，每一步加日志开关。这样出问题时能一眼看出卡在哪一步，而不是在几十个调用点里翻找。

原生库冲突同样常见。两个 SDK 都带 so 文件时，可能出现同名不同版本，或者某个 ABI 缺失。前者表现为运行时报符号找不到，后者表现为特定机型直接崩溃。排查时先列出所有 so 的路径与 ABI，确认每个架构下是否齐全；如果确实无法共存，就按业务优先级保留一套，或者在构建时按 ABI 过滤，避免把不支持的架构打进去。只在模拟器上测试是不够的，至少要在目标架构的真机上走一遍核心流程。

处理完冲突，做一次“干净构建”验证：清掉构建目录，重新解析依赖，重新编译。预期结果是依赖树里每个关键库只剩一个版本，清单合并报告没有冲突项，调试包能安装并启动。如果仍然崩溃，回到日志里找第一个异常，不要被后面的连锁错误带偏。把这个过程记录成 checklist，下一次接新 SDK 时直接照着走，能省掉大量试错。

五、跑通 assembleDebug：日志就是你的施工图

前面几步都是准备，assembleDebug 才是第一次真正的交付演练。它会把清单、资源、代码、原生库、assets 全部合成一个可安装的调试包。命令可以在 Android Studio 的终端里跑，也可以在系统命令行里跑，后者更接近持续集成的真实环境。第一次执行建议加上堆栈参数，出错时能拿到完整调用链，而不是只有一句“构建失败”。

构建失败时，先定位“What went wrong”下面的第一条任务级错误，再看它属于哪个任务：资源合并、清单合并、代码编译、dex 转换、打包。不同任务对应不同排查方向：资源合并看文件名与引用，清单合并看权限与 provider，代码编译看符号与语法，dex 转换看重复类与方法数，打包看签名与文件冲突。按任务归类，比在几百行日志里逐行读有效得多。构建成功时也别急着安装，先看产物路径、文件大小、时间戳，确认拿到的是刚构建的那一个。

几个常见的环境型故障要提前知道。内存不足时，构建会卡住或直接退出，调大 Gradle 的堆内存通常能缓解；Windows 上文件被占用，多是因为上一次构建的进程没退干净，停掉守护进程再试；路径过长会导致某些工具打不开文件，把工程放在层级较浅的目录能规避；编码不一致会让中文资源变成乱码，统一成 UTF-8 并在构建参数里声明编码；缓存损坏时，清构建目录、删缓存、重启 IDE 三步走，比继续猜快。把这些写进团队的环境说明，新同事能少踩很多坑。

预期结果是：命令行输出 BUILD SUCCESSFUL，产物目录里出现调试包，用查看工具能读出正确的包名、版本号、启动 Activity，安装到测试机后能正常启动。做到这一步，说明导出工程已经具备最基本的可维护性。接下来才是签名、安装和与原包对照，那几步决定它能不能真正替代旧包，而不是只在自己的电脑上跑得通。

六、签名与安装：从密钥库到真机验证

调试包能构建，不等于能交付。Android 要求每个安装包都有签名，签名不仅证明“这个包是谁做的”，也决定“能不能覆盖安装旧版本”。同一个包名，签名一致才能升级安装；签名不一致，系统会直接拒绝，并提示更新不兼容。很多维护工作卡在这一步，不是因为代码有问题，而是因为换了签名密钥却想覆盖旧包。先把这件事想清楚，再谈安装。

自家应用应当使用固定的发布密钥。密钥库文件不要放进代码仓库，放在受控的备份位置，至少保留两份离线副本，并记录别名、有效期和保管人。口令不要写进构建脚本明文，更不要提交到仓库，用环境变量或本机的私有配置文件注入。团队里常见的坏习惯是把密钥和口令一起塞进工程目录，图一时方便，等到仓库泄露或人员变动时才发现无法收场。密钥一旦丢失，已发布应用就无法再升级，只能换包名重新开始，这个代价远高于多做一次备份。

签名配置写在 app/build.gradle 的签名配置块里，发布构建类型引用它。调试构建可以继续用 IDE 自动生成的调试签名，但要注意：如果某个第三方 SDK 用签名校验做权限保护，调试签名和发布签名不一致时，调试包里的 SDK 可能无法工作。遇到这种情况，可以给调试构建也配置发布签名，或者为调试单独申请一套测试密钥，具体看 SDK 的要求。不要把调试签名当成发布签名用，也不要把发布密钥提交给任何人。

签名方案要覆盖目标设备。较新的系统优先校验 v2 或 v3 方案，较老的设备只认 v1，所以发布包通常同时启用 v1、v2、v3，兼容性最好。只签 v2 的包在很老的设备上会安装失败，只签 v1 的包在新系统上虽然能装，但校验强度和完整性保护都弱一些。签名之前如果手工做过对齐，要先对齐再签名，顺序反了会破坏对齐结果；用构建工具自动完成时，一般会按正确顺序处理，但仍建议在产物上复核一次。

签名完成后一定要验证，而不是只看构建成功。用签名校验工具打印证书信息，确认证书指纹、签名方案、是否通过校验。预期结果是：校验通过，证书指纹与团队记录一致，方案包含 v1、v2、v3。如果校验失败，先看是密钥格式问题、口令问题，还是文件在签名后被改动过；这几种原因的报错不一样，不要用同一个办法反复试。

安装环节建议用命令行，因为输出更明确，也方便脚本化。覆盖安装用保留数据的参数，彻底重装先卸载再装。多设备连接时指定设备序列号，避免装到错误的机器上。安装成功后不要只看“Success”，要确认包名、版本号、签名与预期一致，再启动应用走一遍核心页面。

安装报错	含义	处理方式
INSTALL_FAILED_UPDATE_INCOMPATIBLE	已安装版本与当前包签名不同	找回原签名；否则只能卸载重装并接受数据丢失
INSTALL_FAILED_VERSION_DOWNGRADE	新包版本号低于已安装版本	提升版本号，或卸载后重装
INSTALL_PARSE_FAILED_NO_CERTIFICATES	包未签名或签名文件损坏	重新签名并校验，确认签名后未再改动包体
INSTALL_FAILED_CONFLICTING_PROVIDER	内容提供者 authority 被其他应用占用	改 authority 占位符，避免与共存包冲突

还有一个现实问题：如果你接手的是别人的旧包，而手上没有原始发布密钥，那么重新构建出来的包永远无法覆盖安装旧版本。这不是技术故障，而是签名机制的设计。正确做法是联系原开发者取得授权与密钥，或者接受“换包名、做数据迁移”的方案。本文只讨论自有或已获授权的应用，请勿绕过这一限制去处理不属于你的软件。

七、与原 APK 对照：用清单法确认没有改坏

工程能装、能启动，只说明主流程没断，不代表改动没有副作用。导出重建的工程与原始 APK 之间，可能悄悄变了资源、权限、签名、原生库、甚至启动入口。对照的目的不是要求两者完全一致，而是要求每一处差异都在你的预期之内。做法很简单：把原包和新包各自导出关键信息，放在同一张表里逐项比对，差异项后面写清楚“为什么变、是否可接受”。

第一层对照是包信息：包名、版本号、应用名、最低与目标 SDK、启动 Activity、支持的 ABI、屏幕特性。第二层是清单：权限多了还是少了，组件是否被禁用，provider 的 authority 是否变化，queries 是否完整。第三层是资源：图标、启动图、字符串、颜色、布局是否按预期更新，多语言是否齐全。第四层是内容：assets 里的文件数量与路径、so 库的架构与版本、dex 的方法规模。第五层是签名：证书指纹、签名方案、校验结果。五层都过一遍，基本不会出现“改 A 坏 B”的意外。

资源对照尤其要细。图标在不同密度目录下可能只更新了一张，导致部分机型仍显示旧图；启动页背景换了颜色，但深色模式下的配置没改，夜里打开仍是一片旧色；字符串改了默认语言，其他语言目录还是旧文案，切换系统语言就露馅。把这些逐项列出来，比凭印象点几下页面可靠得多。布局改动还要看不同屏幕尺寸与折叠状态，必要时用系统自带的布局检查工具看实际渲染。

功能对照建议按用户路径走，而不是按页面走。冷启动到首页算一条，登录到核心功能算一条，设置到关于页算一条，分享或支付等关键链路各算一条。每条路径记录：能否进入、停留多久、有无崩溃、日志有无异常。原包和新包用同一台设备、同一网络、同一账号各走一遍，差异才有意义。如果包名相同无法共存，就先测原包并记录，再卸载安装新包复测，中间不要同时改其他变量。

日志对照能发现很多肉眼看不到的问题。重点看启动阶段的异常、第三方 SDK 的初始化结果、网络请求的域名与返回码、权限申请的回调。原包正常的模块，新包出现连续重试或初始化失败，通常意味着依赖版本、清单合并或签名校验出了问题。把两边的关键日志各存一份，标注时间点，排查时能快速定位是“改动引入”还是“环境本来就如此”。

最后做一次体积与性能对照。新包比原包大很多，可能是重复依赖、未压缩资源或不必要的 ABI；启动明显变慢，可能是初始化顺序变化或调试开关没关。不需要追求数字完全一致，但要有合理解释。把对照结果写进发布记录，和版本号一起归档，下一次维护时就有了可追溯的起点。

对照工作最容易被省略的，是那些不常被点到的页面：设置里的二级菜单、帮助与反馈、权限说明、注销流程。这些页面往往承载着品牌文案与合规声明，改版时最容易漏。建议把它们单独列一张小表，逐项标注“已看、已改、无需改”，并附上截图文件名。截图统一放在 docs/compare/版本号 目录下，原包与新包成对命名，半年后回看仍然清楚。

差异处理方法也要提前约定。能解释的差异，写进发布说明；不能解释的差异，一律当作缺陷处理，不要用“可能本来就是这样”搪塞。比如新包多了一个权限，先查是哪个库带进来的；新包少了一个语言，先查资源过滤配置；新包启动页顺序变了，先查清单里的启动模式。每个差异都追到根因，下一次构建才不会重复踩坑。

如果团队里有多个人参与维护，对照环节最好交叉进行：改的人不自测，测的人不看改动清单，按用户路径独立走一遍。这样做看起来费时间，却能发现“改的人以为自己改对了”的盲区。测试结果回到同一张表里，由负责人决定是否发布。流程不复杂，关键是每次都执行，而不是心情好的时候才做。

还有一个小技巧：把原包与新包的包信息导出成同样格式的文本，用差异工具对比，比肉眼扫一遍快得多。差异工具会把新增、删除、修改逐行标出来，你只需要判断每一行是否合理。这个方法对清单、权限、ABI 列表尤其有效，几分钟就能完成过去半小时的核对。

八、版本管理：让精修成果可回退、可交付

手动精修最怕两件事：改着改着不知道哪一步把功能弄坏了；过了几个月想复现某个版本，却找不到当时的工程和密钥。版本管理就是给这两件事上保险。导出工程的第一天就应该初始化仓库，把只读快照、基线信息、构建说明一起提交，之后再开始改。不要等到“改得差不多了”才想起提交，那时你已经无法区分哪些是原始内容、哪些是自己的改动。

仓库里提交什么、不提交什么，要有明确规则。源码、清单、资源、构建脚本、依赖锁定信息、说明文档要提交；构建产物、缓存目录、本机路径配置、签名密钥、口令文件不要提交。大体积的 assets 如果必须入库，评估仓库体积后再决定，必要时用专门的大文件管理方式。忽略规则要写在仓库根目录，团队成员拉下来就能用，而不是每个人各自配置。

分支策略不必复杂，但要能回答“这个改动从哪来、要到哪去”。日常小修可以在主线上小步提交，每次只做一件事；涉及依赖升级、SDK 替换、渠道改造这类影响面大的改动，单独开分支，验证通过再合并。提交信息写清楚动机与验证方式，例如“替换扫码 SDK 并补充清单占位符，已验证登录与扫码”，比“update”有用得多。标签与版本号绑定，标签名里带上 versionName 与 versionCode，方便出问题时快速定位。

发布流程要固化成清单：提升版本号，确认签名配置，跑干净构建，校验签名，安装到测试机，按上一节的五层对照检查，记录产物哈希与构建环境，最后归档安装包、映射文件、构建日志和变更说明。每次发布都照单执行，不因为“这次只改了一个字”而跳步。真正出问题的往往就是那个“只改了一个字”的版本。

多渠道打包也纳入版本管理。渠道差异尽量用构建变体与占位符表达，不要在源码里写死渠道判断；每个渠道的包名后缀、渠道标识、签名配置都要在脚本里可查。打包完成后逐渠道核对渠道标识与关键页面，避免出现“渠道包内容一样、统计全归到一个渠道”的低级错误。渠道数量多时，写一个校验脚本批量读取包信息，比人工一个个点开可靠。

预期结果是：任何一个已发布版本，都能从标签找回对应源码，从归档目录找回安装包与签名记录，从变更说明看懂改了什么，从构建说明复现出接近一致的环境。做到这一点，经典版导出的工程才真正从“一次性工作目录”变成“可长期维护的项目”。

九、两个实战实例：教学 App 与内部工具

前面八节讲的是方法，这一节用两个真实场景把方法串起来。两个应用都是自家或已获授权的项目，改动范围也都在正常维护之内，不涉及破解或去除限制。每个实例都按“以前怎么做、现在怎么做、改完怎么验证”三段写，方便你对照自己的工程。

实例一：教学 App 统一品牌文案并做中文本地化

以前：这个教学 App 最初是外包做的，品牌名散落在几十个布局文件、字符串文件和 assets 里的题库 JSON 中。每次换品牌，维护人员要先把 APK 反编译，用文本编辑器全局搜索旧名字，逐个文件替换，再回编、签名、装到三台测试机上逐页翻。最麻烦的是漏改：首页改了，关于页没改；中文改了，英文目录还是旧名；题库里的品牌名更是经常被忘掉。一次品牌调整往往要花两三天，而且每次都要重新确认有没有漏网之鱼。

现在：用修改大师经典版手动反编译后导出 Android Studio 工程，先按第一节的方法做快照和基线，再把品牌名收敛到一个字符串资源里，布局和代码统一引用这个资源；题库 JSON 里的品牌字段单独列一份清单，用脚本批量替换并生成差异报告；英文与其他语言目录同步更新，缺翻译的先留默认值。改完在 Android Studio 里直接跑 assembleDebug，资源错误在编译期就会暴露，不用等到安装后才发现。需要精修的地方仍然回到 smali 手动改，导出工程负责资源、依赖和打包，两者各司其职。

验证：安装新包后按“启动页、首页、课程列表、课程详情、练习页、个人中心、关于页”的顺序逐页截图，与原包截图并排比对；切换系统语言到英文再走一遍，确认没有残留旧品牌名；用文本搜索在整个工程里搜旧名字，结果为零才算干净；最后核对包名、版本号、签名指纹与基线表一致。整个过程从两三天缩短到半天，而且下一次换品牌只需要改一个字符串资源，风险小了很多。

实例二：内部工具替换扫码 SDK 并切换接口环境

以前：这个内部巡检工具用的是几年前的扫码库，jar 包直接丢在 libs 里，接口地址写死在代码常量中。厂商停止维护后，新机型上偶发识别失败，团队决定换一套仍在维护的 SDK。第一次尝试时，把新 aar 放进 libs 后直接编译，立刻出现重复类；删掉旧 jar 又发现清单里的 provider 冲突；好不容易编译通过，安装后扫码页白屏，日志显示 SDK 没有初始化。前后折腾了一周，靠反复注释代码才勉强跑通。

现在：先导出 Android Studio 工程，按第四节的方法导出依赖树，确认旧库只有本地 jar 一份、没有隐藏的坐标依赖；移除旧 jar，改用新 SDK 的仓库坐标引入，让传递依赖自动补齐；清单合并冲突用占位符改写 authority，并在应用清单里显式声明替换；初始化集中到应用入口，按“隐私合规、设备信息、扫码模块、业务模块”的顺序排列，每一步打日志。接口地址则改成构建字段，测试环境与内网正式环境各一套，打包时按构建类型取值，不再改源码。所有改动在单独分支完成，提交信息里写清楚替换原因与验证范围。

验证：先跑干净构建，确认依赖树里旧库消失、新库只有一个版本；安装到两台不同厂商的测试机，分别验证扫码、登录、上传巡检记录、断网重试；用日志确认 SDK 初始化顺序与接口域名正确；再与原包对照启动时间、包体大小、权限列表，确认没有多申请不必要的权限。上线前把新旧包的扫码成功率各记录一组数据，用结果说话，而不是凭“感觉更快了”。

这两个例子说明一件事：导出工程的价值不在于“看起来更专业”，而在于把原本靠记忆和运气的操作，变成有结构、有日志、可复查的流程。经典版负责把你送到工程这一层，后面的维护质量取决于你是否愿意按步骤核对。需要提醒的是，涉及第三方 SDK 时务必遵守它的授权协议与隐私要求，收集个人信息前先取得用户同意，别为了功能把合规丢在一边。

十、用户评价与合规提醒

下面五条用户评价来自长期维护导出工程的读者反馈，保留了他们的使用场景与原话，方便你判断这套流程是否适合自己的团队。

评价看完，合规这条线必须再说一遍。继续维护一个应用的前提是：你拥有它的自有版权，或者拿到了权利人的明确授权；改动范围限于自家产品、内部工具、已获授权的项目。请勿用于破解付费内容、去除功能限制、绕过安全机制，也不要把改过的包分发给没有授权的第三方。使用第三方 SDK、图标、字体、音频时，逐一确认许可证与商用范围；涉及个人信息收集的，先告知再征得同意，并把权限申请控制在必要范围。技术本身中性，边界感决定了它能走多远。

如果你更希望把精力放在需求本身，而不是构建脚本上，官网 www.apkeditor.cn 还提供了另一条路线：智能修改电脑版负责桌面端的自然语言改包与自动打包，智能修改安卓版负责手机和平板上的本地改包与安装，经典版则留给需要手动精修、导出工程、接 SDK、做多渠道的场景。三者的定位不同，按任务选工具就好。无论用哪一条路线，那句口号都适用：只需说话，就能让应用变成你想要的样子，剩下的交给流程和核对。

回到本文的主题，导出 Android Studio 工程之后的维护，其实可以浓缩成一张循环图：看清结构，跑通构建，修掉冲突，签名安装，对照原包，纳入版本管理。循环每转一次，你对这个应用的掌控就多一分。第一次可能需要一周，第二次可能只要一天，第三次你会开始写自己的检查脚本。到那时，经典版的手动路线不再是负担，而是一种可以复制的能力。