手机管多个项目：项目列表、历史、文件浏览与回退

安卓修改大师智改工坊 这次聊一个很具体的问题：当你在同一台手机上同时改好几个应用，怎么保证每个项目都找得到、每一次修改都说得清、每一个改坏的包都能退回去。产品介绍与下载入口先放在这里：https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。下面所有操作都围绕一个核心：把“改包”从碰运气，变成有项目、有记录、有文件、有回退路径的日常流程。

一、为什么手机上的多个项目，更需要“项目制”管理

先说一个很常见的场面：手机的“下载”目录里躺着 app-release.apk、app-release(1).apk、app-release-final.apk、app-release-final-2.apk。每个包看起来都像最终版，真要用的时候却分不清哪个是昨天还能装的、哪个是今天改坏的。项目一多，问题就不再是“会不会改”，而是“还找不找得到、退不退得回去”。

智能修改安卓版把这件事收拢到一个概念上：项目。导入一个 APK，就建立一个项目；项目里包含源包、反编译工程、回编产物、运行日志，还有你每次提交的修改需求。项目与项目之间互不覆盖，你在项目列表里切换，就像在电脑上切换不同文件夹。这个看似朴素的设计，恰恰是多项目并行的基础。

这套流程在手机本地完成：Android 10 及以上、ARM64 的手机或平板可以使用，首次进入时按提示下载约 246 MB 的运行环境，只需一次；之后的反编译、修改、回编、对齐、签名都在设备上执行，成品可以直接安装，也可以分享给同事做内测。它不要求你随时守着一台电脑，也不要求你把源码传到别人的服务器上。

项目制管理的价值，在项目少的时候不明显，在项目多的时候非常明显。它至少解决四个问题：第一，身份问题，看到项目就知道对应哪个应用、哪个版本；第二，追溯问题，每次修改需求都留在历史里，不用凭记忆复盘；第三，验证问题，产物、日志、文件都在手边，出问题能马上查；第四，回退问题，上一版能装的包和源包都还在，不必从零再来。

很多人把项目管乱，不是因为工具不好用，而是三个习惯没建立。第一个习惯是“只留成品、不留源包”，结果成品签名出问题或者要换一个方向改时，没有重新开始的材料。第二个习惯是“一次改五件事”，图标、名称、接口、启动页、版本号一起上，装上去闪退时根本不知道是哪一步引起。第三个习惯是“改完不验证就继续改”，把问题一层层叠上去，最后只能全部推翻。

所以本文建议你从一开始就按三条规矩来：一个应用对应一个项目，一个项目一次只验证一个主要变化，一次验证通过就导出一份成品做存档。只要这三条守住，项目数量增长不会带来混乱，反而会带来一种很踏实的感觉：每个包从哪来、改过什么、能不能回退，都清清楚楚。说到底，只需说话，就能让应用变成你想要的样子，前提是你说过的每一句话都有地方可查、每一个结果都有文件可找。

接下来的路线是这样：先认识项目目录里的四样东西，再学会看项目列表和项目详情，然后用修改历史、附件和日志把过程留痕，接着进入项目文件浏览与内置文本查看器，最后用两个自家应用的实例，把“两个 App 并行”和“改坏了回到上一个包”完整走一遍，再收尾讲删除、空间清理与合规边界。

二、先看懂项目目录：source.apk、apktool、build 与 apktool.log

在项目详情里打开“项目文件”，你会进入这个项目自己的工作目录。智能修改安卓版把项目放在应用数据区的 user-data/Project 下面，每个项目一个独立目录。不同项目之间不会互相写入，这一点非常重要：它意味着你可以在同一个手机上放心地同时改两个应用，而不用担心中间产物被覆盖。

进入任意一个项目目录，最值得先认识的不是花哨的界面，而是四样最朴素的东西：source.apk、apktool、build 和 apktool.log。把这四样东西的职责分清楚，后面所有的“找文件、查日志、回退”都会变得顺手。

1. source.apk：项目的“原点”，只读不改

source.apk 是你导入时的原始安装包，是整个项目重新开始的依据。它最大的价值不是“能装”，而是“能重来”。反编译工程改乱了、build 里的产物被覆盖了、某次实验把资源改坏了，只要 source.apk 还在，你就可以新建一个项目，从同一个起点再走一遍，而不用到处找当初那个包。

因此有一条硬规矩：不要把 source.apk 当成工作文件去替换。需要换一个新来源的包，正确做法是新建项目再导入，而不是把旧项目的 source.apk 覆盖掉。覆盖之后，旧项目的历史还指向旧需求，源包却已经变成另一个应用，追溯关系就断了。项目管理的核心是“同一个项目里，源包、工程、产物、日志、需求彼此对得上”，一旦源包被偷换，这个对应关系就失效了。

导入完成后，建议先做一次源包确认：应用名、包名、版本号是不是你要改的那个；图标是不是熟悉的那一个；包能不能正常安装启动。如果一导入就发现拿错了包，最省事的处理是删掉这个项目重新导入，而不是在错误的基础上继续改。越早发现，代价越小。

2. apktool：反编译工程，AI 真正动工的地方

apktool 目录是反编译出来的工程，里面有资源、清单、smali 代码等。你在工作台里用一句话描述需求，智能修改安卓版会把需求交给 AI 工作区，AI 修改的就是这个目录里的内容。改完自动回编，回编成功后再对齐、签名，产物进入 build。整个过程你不必手敲命令，但你应该知道“改动发生在哪”。

这个目录也是排查问题的第一现场。比如应用名没变，就去看资源里对应的字符串有没有更新；图标没换，就去看图标资源是不是被正确替换；启动页还是旧的，就去看对应的布局和图片。项目文件浏览配合内置文本查看器，足够你在手机上完成大部分“看一眼”的确认。

需要提醒的是，apktool 目录是“工作区”，不是“仓库”。不要在里面随意删除目录、重命名资源、移动文件。反编译工程对目录结构和资源命名很敏感，手动挪动一个看起来无关的文件，可能让回编直接失败。真想手工调整，也要先复制一份项目做实验，确认能回编、能安装、能启动，再回到正式项目里处理。

3. build：产物目录，上一版能不能装就看它

build 目录放的是回编、对齐、签名之后的产物。你最终安装的包、分享给同事的包，都应该能在这里找到出处。项目改坏时，build 里上一版还能装的成品，往往就是最直接的“回退包”。所以在每次大改之前，尤其是改动启动页、接口地址、版本号这类影响启动的项之前，先把当前 build 里能用的成品导出一份到项目外面，命名成“应用名_日期_版本_可用”，这比任何口头记忆都可靠。

build 里的文件会随着每次打包更新，所以不要把它当永久档案。永久档案应该放在项目的 Downloads 或者你指定的归档目录，按应用分文件夹，保留“当前可用版”和“上一个可用版”两份即可。项目内的 build 是工作产物，项目外的归档才是回退保障，这两个概念分开，清理空间时才不会误删。

4. apktool.log：黑匣子，出问题先看它

apktool.log 记录反编译与回编过程。打包成功时它看起来平平无奇，失败时它就是最有价值的线索。阅读日志有一个小技巧：不要从第一行开始逐行读，先看末尾，找到第一条明确的错误，再往上找触发它的上下文。大量“warning”只是提醒，真正让流程停下的是“error”“exception”“failed”这一类信息。

有些警告看着吓人，其实不影响结果。例如在 Android 16 设备上，反编译时可能看到类似“Could not find 9patch chunk … Renaming it to *.png”的提示，这是 apktool 对伪九宫格图片的标准兜底处理，改名之后回编仍然可以成功，产物也能正常安装。判断标准不是“有没有警告”，而是“回编有没有完成、签名有没有通过、装上去能不能启动”。把警告当失败，容易白白推翻一个本来可用的项目。

把上面四样东西记成一句话：source.apk 用来重来，apktool 用来修改，build 用来安装和回退，apktool.log 用来解释为什么失败。围绕这四样，再补四条纪律：不覆盖源包、不乱删工程、不把 build 当永久档案、不看日志不重试。做到这四条，多项目管理的底盘就稳了。

三、项目列表与项目详情：先确认“这是哪个应用、改到哪一步”

项目列表是你的总览台。每导入一个包，就多一个项目；每个项目都有自己的图标、名称、源包、历史与文件入口。项目少的时候，列表只是方便；项目多的时候，列表就是你的工作台。建议把“打开项目列表”当成每天开始改包前的第一个动作，而不是直接冲进某个项目里改。

看列表时，先做三件事。第一，确认项目数量和你手上的任务数量对得上，多出来的通常是废弃实验，应该及时处理。第二，确认每个项目的名字能让你想起它是谁，如果名字是一串随机字符，就点进详情看源包和应用信息。第三，确认最近改的是哪一个，避免在旧项目上继续叠加新需求，最后装错包。

点进项目详情，相当于进入这个项目的驾驶舱。建议按固定顺序做五项确认：一看应用身份，应用名、包名、版本号是不是目标应用；二看源包，source.apk 是否还在、大小是否正常；三看修改历史，最后一次需求是什么、有没有验证过；四看附件，图标、横幅、文案等素材是否齐；五看产物，build 里有没有可安装的包、生成时间是不是这次修改之后。五项都对上，再动手。

从导入到第一次修改，可以按下面这条固定路径走，熟练之后会变成肌肉记忆：

1. 把 APK 文件名改成能看懂的名字，例如“1008_自家记账_换图标.apk”，再导入。文件名是你在系统文件选择器里最后一道保险。
2. 导入完成后先不要急着改，打开项目详情，核对应用名、包名、版本号与图标。
3. 在详情里找到项目文件入口，确认 source.apk、apktool、build、apktool.log 都在，目录结构完整。
4. 回到修改入口，把这次要改的内容写成一句明确的话，只写一个主要变化，不要把所有想法堆在一起。
5. 提交后等待回编与签名完成，安装成品，按“图标、名称、启动、目标页面”的顺序验证。
6. 验证通过后，把 build 里的成品导出到项目外的归档目录，命名带上日期与版本，再开始下一轮。

这里有一个很容易被忽略的细节：项目详情里的“历史”不是装饰，它是你和这个项目之间的对话记录。你每次提交的需求原文会按时间留下来，最新的在最上面。改到第十次的时候，你未必记得第三次为什么放弃某个方案，但历史记得。养成“改前看一眼历史、改后补一次验证结论”的习惯，项目的可维护性会完全不一样。

多项目并行时，最容易犯的错不是技术错误，而是“进错项目、改错包”。避免方法很朴素：每次动手前，把项目详情顶部的应用名和包名读一遍；每次装包前，把系统安装界面的应用名和版本号读一遍；每次分享前，把文件名和项目名对一遍。三个“读一遍”花不了多少时间，却能省掉大量“怎么装上去还是旧界面”的困惑。

四、修改历史：把每一次“以前”和“现在”都留档

项目一多，记忆就是最不可靠的东西。你可能记得“上周把启动页换过一次”，却未必记得那次换的是哪张图、改完之后有没有闪退、当时为什么又退回旧方案。修改历史解决的正是这个问题：它按时间顺序保存你每次提交的需求，最新的排在最上面，完整保留你当时的原话，并且可以把某一条旧需求重新填回输入框。

历史至少有三种用法。第一种是复盘：应用现在这个效果，是哪一次需求带来的；某个改动为什么被放弃；哪一轮之后开始出现启动变慢。第二种是复用：换季要再换一次横幅，直接把上一季那条需求调出来，改掉附件和日期即可。第三种是交接：把项目交给同事时，不用口头讲半小时，让他从历史最上面往下读，就能明白这个项目经历过什么。

读历史也有方法，不要从第一条开始翻。先看最新三条，确认当前状态；再找最后一次“安装成功、功能正常”的记录，把它当作已知良好点；然后对比它之后的那条需求，看看多改了什么。绝大多数“改坏了”的原因，就藏在这个差值里。如果最近三条都失败了，就继续往前找，直到找到最后一个能正常启动的版本。

写历史比读历史更重要。很多人提交需求时习惯写一大段愿望，比如“界面弄好看点，图标也换一下，顺便改个名字，接口也换成新的”。这样的句子放进历史，第二天自己都看不懂。更好的写法是把对象、变化、验收标准放进一句话里，让历史本身就能当说明书用。

这种写法的好处是，历史里每一条都能独立阅读。你不需要回忆“那次说的好看点到底指什么”，因为对象、变化和验收标准都在句子里。下一轮开始时，还可以在需求开头补一句上一轮的结论，例如“上一轮已验证：图标已换、启动正常；这一轮只改启动页背景”。这样历史就不只是需求清单，而是一条带结论的时间线。

必须把一个概念分清楚：修改历史保存的是“你说过什么”，不是“每个版本的安装包”。它能帮你复现一次修改，但不能代替二进制回退。真正要回到上一个能用的包，靠的是 build 目录里的旧产物，或者你提前导出到项目外的归档包。历史负责“知道怎么改回去”，归档负责“马上能装回去”，两者缺一不可。

多项目并行时，历史还是天然隔离的。每个项目只记录自己的需求，不会把另一个应用的话混进来。但人也容易犯“串项目”的错：在 A 项目里复制了 B 项目的需求，忘了改应用名和素材路径。提交前把需求里的应用名、附件名读一遍，是最便宜的防错手段。历史越清晰，串项目的概率越低。

把历史用成习惯，可以固定成四步：改之前，读最新三条，找到已知良好点；提交时，一句话写清对象、变化、验收标准；装完之后，按验收标准逐条核对；下一轮开始时，用一句话把上一轮结论写进新需求。四步都不复杂，但它们把“凭感觉改包”变成了“有记录地推进”。

五、附件与日志：让需求和结果都能追溯

改包很少是纯文字工作。换图标要图片，换横幅要设计稿，改文案要一份准确的文字表，调启动页要参考截图。附件系统就是为这些“说不清、必须给文件”的需求准备的。把素材附对，AI 才能按你真正想要的样子改；附件乱放，需求写得再长也可能跑偏。

附件的第一条规矩是“每个文件都写用途”。一次可以选择多个文件，但每个文件都要有说明，说明不能敷衍，至少要说清楚它用在哪里、希望达到什么效果。系统会先做基本校验：文件是否存在、是不是目录、是不是空文件、能不能读取。校验不通过的文件不会被带进需求，这是好事，能避免“我以为附上了，其实是个空壳”的尴尬。

通过校验的附件，会按序号、路径和说明整理好，随需求一起送进 AI 工作区。也就是说，AI 看到的不是一堆散落的文件，而是“第一张图是桌面图标，第二张图是启动页背景，第三份文档是新文案”这样有上下文的一组材料。附件说明写得越具体，最终结果越接近你的预期。

哪些东西适合作为附件？第一类是图标和图片素材，例如自家应用的 logo、活动横幅、启动页背景。第二类是文案表，例如统一品牌名之后的名称对照表。第三类是参考截图，用来说明“希望页面上半部分留白更多”这类难以纯文字描述的要求。第四类是自家应用的品牌规范，例如颜色值、字体要求。所有素材都应该来自你自己或已获授权的项目。

哪些东西不适合？命名含糊的“新建文件夹.zip”、零字节的占位文件、整个目录、和本次需求无关的旧素材、包含他人版权内容的图片，以及带有账号、密钥、客户信息的文件。附件不是越多越好，而是越准越好。一次附五个无关文件，不如附一张说清楚用途的正确图片。

附件的操作可以固定成五步：先在文件管理器里把素材改成能看懂的名字；再回到项目详情，打开附件入口；一次选中本次需要的文件；逐个填写用途，写清楚“用在哪、要什么效果”；最后检查附件列表的顺序和说明，确认没有漏项再提交。改完之后，附件仍然留在项目里，下一次换图可以直接复用，不必重新翻相册。

如果说附件是“输入的证据”，日志就是“输出的证据”。项目里最常看的是 apktool.log，它记录反编译与回编的细节；打包过程也有对应的日志，用来确认对齐、签名、产物生成这些步骤有没有走完。成功时它们安静地躺在目录里，失败时它们就是唯一能解释“为什么”的材料。

读日志时，先看最后几十行，找到第一条明确的失败信息，再往上看它发生在哪个阶段。反编译阶段失败，多半和包结构、框架资源有关；回编阶段失败，多半和资源改动、文件缺失有关；签名阶段失败，多半和签名配置有关。不要被满屏的提示吓到，先判断流程停在哪一步，再决定是改需求、换素材，还是回到上一个可用包。

有两种情况特别值得记住。第一种是“看着像错误，其实是正常兜底”：某些较新系统上的伪九宫格图片会触发改名提示，日志里会出现“Could not find 9patch chunk”之类的文字，但回编仍然成功，装上去也正常，不必因此推翻项目。第二种是“环境边界”：如果你在 x86_64 模拟器上使用，反编译入口会直接提示当前版本仅支持 ARM64 设备，这不是包的问题，也不是主频的问题，换一台 ARM64 手机或平板才是正确方向。

日志里可能包含项目路径、包名、版本号等信息，分享到公开场合前要斟酌。给同事排查问题时，也不必把整份日志贴出去，截取“失败阶段前后各十几行”往往就够了。把项目名、本次需求、附件清单、日志末尾的失败信息这四样放在一起描述，别人一看就能明白上下文。

六、项目文件浏览与内置文本查看器：不离开手机也能查工程

项目文件浏览是智能修改安卓版里最容易被低估的功能。很多人只在“找安装包”时打开它，实际上它更像一台 X 光机：源包在不在、工程有没有展开、产物是不是这次生成的、日志写到了哪一步，都能在这里看到。配合内置文本查看器，你不需要把文件传到电脑，也不需要额外装一个文件管理器，就能在手机上完成大部分确认工作。

进入方式很直接：打开项目详情，找到项目文件入口，进入这个项目的目录。顶层通常能看到 source.apk、apktool、build、apktool.log 这几项。点目录可以继续往下看，点文本文件可以用内置查看器打开。看的时候建议按固定顺序：先看 source.apk 在不在，再看 apktool 目录有没有展开，再看 build 里有没有成品，最后打开 apktool.log 看最近一次回编的结果。

文件浏览最适合做五类检查。第一，确认源包存在且不是零字节。第二，确认 apktool 工程里有资源目录和代码目录，说明反编译确实完成了。第三，确认 build 里有可安装的产物，并且生成时间晚于你最后一次提交需求。第四，确认 apktool.log 末尾没有阻断流程的错误。第五，确认你关心的资源文件确实被改动过，例如图标目录里出现了新图片，文案文件里出现了新名称。

内置文本查看器解决的是“打开看一眼”的需求。apktool.log 可以直接读，清单文件可以打开看包名和版本，资源里的文本文件可以打开看应用名和文案，smali 文件也可以打开确认某段逻辑有没有变化。查看器不是编辑器，第一用途是核对而不是改造；把它当成“手机上的放大镜”，比当成“手机上的开发环境”更合适。

如果你确实要用内置编辑器做很小的文本调整，请守住三条：先复制项目做备份，只改纯文本，不碰图片和二进制文件；改完立刻回编，盯住 apktool.log 的最后几行；装到设备上按“启动、目标页面、返回”三步验证。任何一条不满足，就回到备份项目，不要在原项目上反复试错。手工编辑的风险不在“改错一个字符”，而在“改错之后没有退路”。

举三个实际会遇到的核对场景。应用名没变：打开 apktool 里的资源目录，找到存放应用名的文本文件，看名称是不是新的；如果文件里已经是新名字，但桌面还是旧的，多半是装错了包或者旧版本没卸载干净。图标没换：看图标资源目录里是不是新图，再看 build 产物时间是不是这次生成的。启动页没变：看启动页对应的布局和图片有没有替换，再看需求里有没有明确指定“只改启动页”。

文件浏览还有一条安全边界：浏览归浏览，删除归删除。不要一边改项目一边在文件树里删目录、改名、移动文件。反编译工程对结构很敏感，一个看似无关的移动，可能让下一次回编直接失败。确实要清理，也应该等项目验证通过、成品归档之后，回到项目列表用删除功能处理整个项目，而不是在工程目录里做“外科手术”。

把这一节压缩成一套十分钟检查法：两分钟看项目详情，确认应用身份；两分钟看项目文件，确认四样东西齐全；两分钟读历史，确认上一轮结论；两分钟看日志末尾，确认没有阻断错误；两分钟看 build 产物时间，确认是最新一次生成。每天开工前做一遍，比出了问题再到处翻要省时间得多。

七、实例一：两个自家 App 并行，各管各的项目

先看一个多项目并行的典型场景。我们手上有两个自己团队开发、自己维护的应用：一个是自家记账 App，这次要把桌面图标换成新版蓝色图标，应用名改成“XX 记账 内测版”；另一个是自家内部工具，这次要把接口地址从测试环境切到内网正式环境，同时把版本号往上提一位。两个应用都要在同一个手机上装、同一个手机上验，而且中间还会来回切换。

这种场景是对项目管理能力的直接考验。两个应用的目标不同、素材不同、验证方式不同，如果还按“一个包改完再找下一个包”的方式做，很容易出现素材串用、装错包、改完不知道哪个是哪个的情况。项目列表加项目详情，恰好把两条线分开：A 项目只服务记账 App，B 项目只服务内部工具，各自有源包、历史、附件和产物。

以前怎么做

以前的典型做法是守在电脑前：把两个 APK 分别放进两个临时文件夹，用反编译工具展开，手动找图标目录、找名称字符串、找接口配置，改完再回编、对齐、签名，最后用数据线装到手机。中途如果接了个电话，回来就分不清哪个文件夹对应哪个应用；如果第一个包改坏了，第二个包又已经覆盖了同名产物，想退回去只能重新解压、重新改、重新签。

更麻烦的是“版本记忆”。两个应用都叫 release，都有 v1、v2、final，装到手机上之后桌面名称又很接近，验证时经常要打开应用信息看包名才能确认。改一个图标可能要来回折腾几轮，真正的成本不在操作，而在每次都要重新建立“我现在改的是哪个应用”的上下文。

现在怎么做

现在把两条线都放进项目列表。先导入记账 App，文件名改成“1012_自家记账_蓝色图标内测.apk”，建立项目 A；再导入内部工具，文件名改成“1012_内部工具_内网接口.apk”，建立项目 B。两个项目各自拥有独立的 source.apk 和 apktool 工程，互不覆盖。项目列表里一眼能看到两个项目，详情里能确认各自的应用名、包名和版本。

项目 A 的操作顺序是：打开详情，核对应用名和版本；在附件里放入新版蓝色图标，用途写清楚“替换桌面图标，保持圆形裁切，其他不变”；在需求里写“只更换桌面图标并把应用名改为 XX 记账 内测版，启动页、功能、包名都不动；验收标准是桌面图标为蓝色、名称正确、能正常启动”；提交后等待回编签名；安装后逐项验证；最后把成品导出为“自家记账_1012_内测_可用.apk”。

项目 B 的操作顺序是：打开详情，确认这是内部工具而不是记账 App；在需求里写“只把接口地址从测试环境切换到内网正式环境，版本号提升一位，其他界面与功能不变；验收标准是启动后首页能加载内网数据、关于页版本号正确”；提交后等待完成；安装到同一台手机；打开应用触发一次数据请求，确认返回的是内网环境的数据；最后导出为“内部工具_1012_内网_可用.apk”。

两个项目切换时，不需要关掉另一个，也不需要把文件搬来搬去。项目 A 改完，回到列表点项目 B；项目 B 改完，再回列表点项目 A。每个项目的附件、历史、build 产物都留在自己目录里。真正的“并行”不是同时点两个按钮，而是两条工作线各自有独立的上下文，你随时可以放下一条、拿起另一条，而不会把状态搞混。

改完怎么验证

项目 A 的验证分四步：第一步看桌面，图标是不是新版蓝色，名称是不是“XX 记账 内测版”；第二步点开应用，启动页和首页是否正常，原有记账数据是否还在；第三步进系统应用信息，核对版本号与包名，确认装的是这次生成的包；第四步回到项目文件，确认 build 产物时间晚于本次提交，apktool.log 末尾没有阻断错误。四步都过，才算完成。

项目 B 的验证更偏功能：第一步启动应用，看首页是否还能正常加载；第二步触发一次需要联网的操作，确认请求走的是内网正式环境，返回数据符合预期；第三步进“关于”页面，核对版本号是否已经提升；第四步看应用有没有异常退出，再回项目里确认日志没有签名或回编错误。接口类修改最忌讳“能启动就算成功”，一定要走到真正发起请求的那一步。

最后做一次交叉核对：两个应用能不能同时出现在桌面上，取决于它们的包名是否不同。包名不同，可以共存；包名相同，后装的会覆盖先装的，看起来就像“改完没效果”。如果确实需要同包名的两个版本共存，只能改包名另建一个项目，但改包名会影响分享、登录、数据迁移等一连串问题，必须在你自己的测试环境里评估，不能想当然。

这个实例的价值不在于“两个 App 都改完了”，而在于整个过程没有出现一次“这是哪个包”的疑问。项目列表负责分开，项目详情负责确认，历史负责记录，build 负责交付，四者配合，两个项目并行也不会乱。下次再加第三个、第四个自家应用，套用同一套流程即可。

八、实例二：改坏了，怎么回到上一个能用的包

再看另一个更让人紧张的场景。自家展示 App 要换首页横幅，同时把 WebView 打开的网址从测试站点换到自家正式站点。两件事在同一次需求里提交，回编签名都成功，装到手机上却一直黑屏。这个时候最重要的不是“赶紧再改一版”，而是先停下来，把“上一个能用的包”找回来，让手机恢复可用，再从容排查。

以前怎么做

以前的常见做法是只保留一个工作目录：源包解压、改完、回编、签名、安装，下一次直接在同一个目录上继续改。顺的时候很省事，出问题时就很被动：上一版成品已经被新产物覆盖，源包虽然还在，但上一次改了什么、用的哪张横幅、网址具体是什么，全靠记忆。想退回去，只能从头再改一遍，改完还不确定和上一版是否一致。

更危险的是“边猜边改”。黑屏之后，有人会连续换图、换网址、改启动配置，一次装一个包，指望某一次碰巧恢复。每改一次，现场就少一分，最后连最初能用的状态都复现不出来。回退能力不是出事之后才想的，它应该在每次动手之前就准备好。

现在怎么做

现在把这个项目按“改动前、改动中、改动后”三段来管理。改动前，先打开项目详情，确认当前 build 里有一个能正常用的成品，把它导出到项目外的归档目录，命名成“展示App_1010_当前可用.apk”；同时把当前版本号记在需求里，方便回退后核对。这个动作只要一两分钟，却是整个回退方案的支点。

改动中，坚持“一次只改一个主要变量”。横幅和网址都会影响首页显示，最好分成两次提交：先换横幅，装上去看首页是否正常；确认没问题，再换网址，装上去看 WebView 是否能打开。这样一旦黑屏，你马上知道是横幅的问题还是网址的问题。历史里也会留下两条清晰的需求，而不是一条“换了横幅和网址然后黑屏”的混合记录。

如果真的黑屏了，按下面的顺序处理，不要跳步：

1. 停止继续提交新需求，保留当前项目和当前成品，不要删除任何文件。
2. 打开 apktool.log 和打包日志，看末尾有没有阻断错误，确认是回编失败、签名失败，还是安装成功但运行异常。
3. 回到修改历史，找到最后一次“验证可用”的需求，记下它改了什么、用了哪些附件。
4. 从归档目录取出“展示App_1010_当前可用.apk”，这就是回退包；如果归档没有，就去项目 build 里找上一个时间点的产物。
5. 如果新包的版本号高于旧包，系统通常不允许直接降级安装，需要先卸载新包再装旧包；卸载会清除应用数据，这一步要提前有心理准备。
6. 安装旧包后，按“启动、首页、目标页面、图标与名称、版本号”五项验证，确认手机恢复到可用状态。
7. 把失败的那次需求、日志和现象整理出来，在项目里新建一个修复项目，从 source.apk 重新开始，只改一个变量。
8. 修复验证通过后，导出新的可用包，归档里保留“当前可用”和“上一个可用”两份，旧的那份不要急着删。

这里要区分三种“回退”。第一种是包回退：直接安装上一个能用的成品，最快恢复使用，但会丢失新包里的所有改动。第二种是需求回退：在历史里找到上一次可用的需求，重新提交，让 AI 在一个干净的工程上再生成一版，适合新包还能装、只是某个改动不对的情况。第三种是项目回退：删掉改坏的项目，用 source.apk 新建项目，只保留确定正确的需求，适合工程已经被手工改乱、回编反复失败的情况。三种方式没有优劣，只有适用场景。

还有一条容易被忽略：不要在有问题的项目上反复“修修补补”直到它碰巧能启动。这样做即使成功了，你也说不清是哪一步修好的，下一次遇到同类问题仍然没有方法。正确做法是把失败项目保留为证据，另起一个干净项目做对照实验。项目制的好处就在这里：复制一份、重开一个，成本很低，而破坏唯一现场的成本很高。

改完怎么验证

回退后的验证要更严格，因为目标是“恢复”，不是“看起来差不多”。第一步看版本号，确认装回去的确实是归档里的旧版本，而不是系统里残留的新版本；第二步启动应用，看首页能否正常打开；第三步进入之前出问题的页面，确认黑屏、白屏或闪退是否消失；第四步核对图标、名称和包名，确保没有装成另一个应用；第五步看项目日志与系统应用信息，确认没有新的异常记录。

恢复可用之后，再处理“为什么会坏”。把失败包的日志末尾、本次需求、附件清单放在一起看：是网址本身不可达，还是 WebView 的配置不兼容；是横幅图片尺寸或格式有问题，还是资源替换后引用错位。找到原因后，在修复项目里只改那一处，重新走一遍回编、签名、安装、验证。修复包验证通过，再把它归档为新的“当前可用”，旧的回退包继续保留一段时间。

最后记住一句话：回退不是失败，而是流程的一部分。能在一分钟内回到上一个能用的包，才有资格放心地尝试新改动。项目、历史、附件、日志、归档，这五样东西平时看起来有点麻烦，真正出事时，它们就是你的安全绳。

九、删除、空间清理与项目归档：把手机存储管起来

项目多了，存储一定会紧张。一个项目不只是那个几 MB 的 APK，它还包括展开后的 apktool 工程、build 里的中间产物和成品、日志文件。改过几轮之后，同一个项目占用的空间可能比你想象的大。再加上首次使用下载的运行环境约 246 MB，如果平时不整理，手机很快就会提示空间不足。

清理之前，先给项目分三类。第一类是“进行中”，还在改、还要验证，不能动。第二类是“已归档”，成品已经导出、源包也留了副本，项目本身可以保留也可以删除。第三类是“可删除”，实验失败、拿错包、重复导入、已经确认不再维护的项目。分类的标准不是项目大小，而是“删掉之后还能不能恢复工作”。

项目类型	判断标准	处理方式
进行中	还要继续改，或还没完成安装验证	保留，不清理工程和日志
已归档	成品已导出，源包已有副本	可保留最近一版，旧产物可清理
可删除	拿错包、重复导入、确认不再维护	导出需要的东西后整项目删除

删除项目是不可逆的。删除的不只是安装包，还包括这个项目的修改历史、附件、apktool 工程和日志。所以删除前先过一遍清单：成品是不是已经导出到项目外；source.apk 需不需要留一份；历史里有没有以后还要复用的需求；这个项目是不是还在某台测试机上装着；确认删除后不会影响正在进行的另一个项目。五项都确认，再动手。

删除的操作路径很简单：回到项目列表，找到目标项目，使用删除入口，按提示确认。删除时只处理项目本身，不要去应用数据区里手工删目录。手工删除容易误伤环境文件或其他项目，出了问题也不好恢复。项目列表的删除功能只允许处理项目目录，这个边界是保护，不是限制。

有些东西不能删。第一是运行环境目录，首次下载的约 246 MB 环境是反编译、回编、签名的基础，手工删掉之后还得重新下载。第二是其他项目的目录，尤其是名字相近的项目。第三是应用自身的配置和数据目录。第四是系统下载目录里你归档好的成品，它们不在项目内，删项目不会带走它们，但也不要顺手清空整个下载目录。

归档比删除更值得花时间。建议在手机里建一个固定的归档文件夹，按应用分子目录，每个应用只保留两份成品：“当前可用”和“上一个可用”。文件名统一成“应用名_日期_版本_状态.apk”，例如“自家记账_1012_内测_可用.apk”。这样即使项目被删了，你仍然有一个能装的包；即使新包出问题，你也知道该拿哪一份回退。

清理频率不需要很高，一周一次或者每完成一个应用的一轮修改后做一次即可。顺序是：先归档当前可用包，再删除确认废弃的项目，然后清理已归档项目里多余的旧产物，最后看一眼剩余空间。不要一上来就删 build 目录，因为 build 里可能还有你唯一的可用成品；也不要为了省空间删掉正在使用项目的 apktool 工程，那等于让项目回到未反编译状态。

如果环境本身出了问题，例如反编译入口一直报环境缺失，优先按应用内的提示重新准备环境，而不是手工拼目录。环境下载、解压、校验、替换是一套完整流程，手工干预很容易留下半成品。项目可以重建，环境也可以重新准备，但两者的顺序要清楚：先保证环境完整，再谈项目文件。

把这一节收成一句口诀：先归档，再分类；先导出，再删除；环境不动，项目整删；每个应用留两版，当前和上一版。做到这四句，手机空间会被控制在一个可预期的范围里，项目数量增长也不会变成负担。

十、五条用户评价、合规提醒与常见问答

项目列表、历史、文件浏览、回退和清理，这些能力单独看都不算惊艳，真正用起来才知道它们解决的是“长期维护”的问题。下面五条反馈来自我们自己团队和授权测试用户的实际使用记录，已做匿名处理，讲的都是具体场景，不是空泛的夸奖。

合规提醒：工具的能力有边界，使用的人更要有边界

智能修改安卓版是给自有应用和已授权应用做修改的工具，不是绕过规则的工具。使用前请确认三件事：应用是你自己开发、自己维护的，或者你拿到了明确的修改授权；应用里的图片、字体、文案、图标等素材，你有使用权；修改后的成品只在你允许的范围内安装、测试和分发。换句话说，应用必须是自有版权或已获得明确授权，三条里任何一条不成立，就不要动手。

请勿用于破解、绕过付费或安全机制，也不要修改来源不明的应用，不要绕过登录、授权、安全校验等机制，不要制作冒充他人品牌的版本，更不要把改过的包当作官方包对外发布。工具提供的是本地改包能力，不改变应用的版权归属，也不改变你对成品应负的责任。技术上的“能做到”，不等于使用上的“可以这样做”。

另外三点属于操作层面的提醒。第一，改包会改变应用签名，涉及登录、支付、数据同步的应用，务必先在测试设备和测试账号上验证，不要直接覆盖主力机上的正式版本。第二，安装旧包可能需要先卸载新包，卸载会清除应用数据，重要数据要提前备份。第三，分享成品时注意隐私，不要把包含内部地址、账号信息的测试包发到公开群组或公开网盘。

常见问答：把最容易卡住的五个问题说清楚

问：项目里为什么暂时看不到 build 产物？
答：先确认这一轮回编和签名是否已经结束。刚提交需求时，工程还在处理，build 里可能只有上一版产物；打开 apktool.log 看末尾有没有完成信息或错误。如果日志停在某个错误上，先按错误处理，不要反复提交同一条需求。产物生成后，再看文件时间是不是这一次的。

问：安装时提示签名冲突或版本降级怎么办？
答：签名冲突通常是因为设备上还装着同包名但签名不同的旧版本，先备份数据再卸载旧版本；版本降级则是新包的版本号低于已安装版本，系统会拒绝安装。两种情况的共同点是：不要连续盲目重试，先确认包名、版本号和签名来源，再决定是卸载重装，还是用更高版本号重新生成。

问：改完应用名或图标，桌面为什么还是旧的？
答：先确认安装的是不是这次生成的包，再看项目 build 产物的时间，最后核对资源目录里对应文件是否已经替换。桌面启动器有时会缓存图标，卸载旧版、装上新版之后重启一次桌面通常就能刷新。如果系统应用信息里的版本号已经是新的，图标却还是旧的，多半是装错了同包名的另一个包。

问：日志里出现一堆警告，需要全部处理吗？
答：不需要。先区分警告和错误，再看流程有没有走完。某些较新系统上的伪九宫格图片会触发改名提示，属于正常兜底，回编和安装都可以继续；真正需要处理的是让回编或签名停下来的错误。判断标准始终是“产物有没有生成、签名有没有通过、装上去能不能用”，而不是“日志里有没有 warning”。

问：为什么 x86_64 模拟器上不能用？
答：智能修改安卓版的运行环境、Java 运行环境和反编译工具都是 ARM64 架构，只支持主 ABI 为 arm64-v8a 的手机或平板。x86_64 模拟器会在反编译入口直接给出“当前版本仅支持 ARM64 设备”的提示，这不是包的问题，也不是性能问题。换一台 ARM64 真机或平板，流程就能正常走通。

这些问题看起来零散，背后其实是同一条原则：先确认身份，再确认状态，最后才动手。项目名、包名、版本号、产物时间、日志末尾，这五个信息点能解决大部分“怎么和我想的不一样”的疑问。把它们变成每次改包前的固定动作，剩下的就是耐心和记录了。

写到这里，可以把整篇文章压缩成一条工作流：导入前把文件名改清楚；导入后在项目详情里核对身份；改之前先看一眼历史，改的时候一次只动一个主要变量；素材用附件说明白，结果用日志和文件核实；验证通过就导出归档，验证失败就回到上一个可用包；项目不再需要时，先导出再删除，环境目录不要手工动。十步不到，却能覆盖多项目并行的绝大多数情况。

项目管理从来不是“多做几个文件夹”那么简单，它是一套让你敢改、能查、可退的习惯。手机端把反编译、修改、回编、对齐、签名都放进了口袋，剩下的秩序需要你自己建立。建立秩序的成本很低：一个清楚的命名、一条明确的需求、一次认真的验证、一份及时的归档。收益却很高：无论项目增加到几个，你都知道下一步该点哪里。

还是那句话：只需说话，就能让应用变成你想要的样子。但“想要的样子”不是一次碰运气碰出来的，它来自项目列表里的条理、修改历史里的记录、文件浏览里的证据、回退包带来的底气。把这些基础动作做好，再复杂的需求，也只是多走几轮而已。

安卓修改大师智改工坊 · 官网 www.apkeditor.cn · 产品页 https://www.apkeditor.cn/ai-version.aspx