用户拿到一个应用，第一眼看到的是桌面图标，第二眼是图标下面的名字，点开之后第一眼是启动页。这三处几乎决定了他对“这还是不是原来那个应用”的判断。也正因为如此，三件套看起来最简单，实际最容易在细节上翻车：图标只改了一个密度、名字改完桌面还是旧的、启动图在长屏手机上被拉成一张饼。

从工程角度看，三个动作改的是三类完全不同的东西。换图标改的是图片资源与密度目录，核心问题是“系统会挑哪一张”；改应用名改的是 Manifest 的 label 与字符串资源，核心问题是“哪个 label 最终生效、桌面有没有缓存”；换启动页改的是主题、drawable，部分应用还要动启动 Activity，核心问题是“不同 Android 版本走的是哪条启动路径”。三者的验收方式也不一样：图标要在桌面看，名字要在系统设置和最近任务里看，启动页要冷启动录屏看。把这三件事分开做、分开验收，比“一次让 AI 全改完再一起装”稳得多。

本文按“一个动作一套完整步骤”来组织。每个动作都走同一条流水线：准备素材、写需求或挂附件、AI 修改、回编签名、安装验收、常见失败与排查。中间会插入两个自家应用的实例，一个是记账 App 换新 logo 并改内测名，一个是内部工具换启动页背景，每个实例都写清以前怎么做、现在怎么做、改完怎么验证。你可以按顺序读，也可以直接跳到正在做的那一件。

一、先把三件套放回改包流水线里

很多人把换图标、改名字、换启动页当成三个孤立的“美化动作”，于是分别找教程、分别试工具，最后得到三个互相对不上的半成品。更稳的理解方式是把它们放回同一条流水线：导入 APK、建立项目、写需求、AI 修改工程、回编、对齐、签名、校验、装机预览。三件套只是这条流水线上三个不同的“修改点”，前后的打包与验收完全共用。

电脑版的基本节奏是这样的：把 APK 拖进主窗口，aapt 先把图标、应用名、包名、版本、SDK 与启动页解析出来；确认项目后，程序在 Project 下建一个 8 位随机名目录，写入 config.ini、history.ini，复制 source.apk，并在 apktool 子目录里反编译。之后你在详情页输入需求，点“立刻修改”，原文和日期写进 history.ini，需求被送进右侧 AI 工作区执行。AI 完成后会在项目目录留一个 ai_done.flag，主窗口每 2 秒轮询一次，读到就删，最多等 1 小时。随后进入打包：apktool 回编、zipalign 对齐、apksigner 签名、apksigner verify 校验，最后按需装到手机或模拟器。

这条链路有两个时间数字值得记住。反编译一个 12 MB 左右的包，实测大约 3 秒；超过 10 分钟还没有结束，程序会中断并报错，这时不要反复重试，先去看 apktool.log 的最后几十行。另一个是等待 AI 的上限 1 小时，正常需求远用不到这么久，但如果界面一直停在等待状态，先确认 ai_done.flag 是否出现、error.log 是否有未处理异常，而不是直接关窗口。

现在把入口再放一次，方便你边看边对照：https://www.apkeditor.cn/ai-version.aspx。官网 www.apkeditor.cn 上也能找到版本说明。安卓修改大师智改工坊想解决的问题很具体：把“改一个资源、改一个字符串、换一张启动图”从翻文档、记命令，变成把话说清楚、把附件挂对、把结果验明白。只需说话，就能让应用变成你想要的样子，但前提是你说得够具体，验收做得够扎实。

二、开工前的统一准备：授权、素材、工作目录与验收清单

先把底线说清楚：只修改你拥有自有版权，或者已经拿到明确授权的应用。请勿用于破解、去除付费限制、绕过安全机制，也不要拿去改他人的商业应用。下面所有步骤都建立在这个前提上；如果包不是你的，也不是你有权处理的，请先停下来。

1. 三份底稿：原包、素材清单、验收清单

动手前准备三份底稿。原包备份要保留原始文件名和版本号，单独放一个“未修改”目录，不要把备份和项目目录混在一起；素材清单写清楚每个文件对应哪个资源名、哪个密度、用在哪一层；验收清单在动手前就写好，避免改完之后“看着差不多”就收工。三份底稿看起来是额外工作，实际是出问题时唯一能让你快速回退、快速定位的东西。

素材清单建议用表格维护，至少包含四列：文件名、用途、目标资源名、备注。比如“logo_fg_432.png、自适应图标前景、ic_launcher_foreground、主体在 66dp 圆内”。这张表后面可以直接变成附件说明的底稿，省得每次挂附件时临时想词。

2. 素材规格：图标、名称、启动页各有一套硬指标

图标不要用 JPG。JPG 没有透明通道，桌面的圆角遮罩会把白底一起裁进来，看起来像贴了一张方形贴纸。启动页可以用 JPG，但要注意压缩后的大色块渐变容易出现色带，渐变背景优先 PNG 或高质量 WebP。文件名尽量用英文、数字和下划线，避免空格与中文；有些工具链处理带空格路径时会把参数截断，报错信息还很难看懂。

3. 工作目录与工具链：先让环境可写、可找、可复查

电脑版第一次启动会自动挑工作盘，顺序是 D→E→F→G→C，取第一个可读写且剩余空间不少于 1 GB 的盘，然后在下面建 tools 与 Project 两个子目录。工具链会自动递归搜索，找不到时在参数设置里做一次“工具链体检”。如果你的 D 盘是移动硬盘或网络盘，建议手动把工作目录指到本地固定盘，避免改到一半盘符掉了，项目目录直接失效。

每个项目会在 Project 下生成一个 8 位随机名目录，里面有 config.ini、history.ini、source.apk，反编译产物在 apktool 子目录，反编译日志是 apktool.log。config.ini 记录包名、启动 Activity 等解析结果，history.ini 记录你的需求原话，source.apk 是原始包的副本。这三个文件不要手动改名，后面的自动装机要靠它们找组件；也不要随手删除 source.apk，它是你这一轮改包的回退点。

除了 apktool.log，还要认识另外两个日志：pack.log 记录打包全过程，包括回编、对齐、签名、校验每一步的命令与输出；error.log 记录未处理的异常。界面上的提示往往只有一句“失败”，真正的线索在日志最后几十行。养成“失败先看日志、再决定重试还是改需求”的习惯，可以省掉大量无效重复。

4. 设备与验收环境：至少一台真机、一台旧机或模拟器

准备至少两台设备：一台日常主力机，系统版本较新，带圆角或圆形图标遮罩；一台旧机或模拟器，系统版本较低，用来验证不走自适应图标的那条路径。电脑版支持装到手机，也支持装到模拟器；手机通过 scrcpy 投屏，模拟器窗口会被提到最前。数据线尽量用能传数据的线，只有充电功能的线会让 adb 时有时无，排查起来非常浪费时间。

手机上要打开开发者选项与 USB 调试，第一次连接时在手机上点“允许”。如果电脑上同时开着手机助手、投屏软件、模拟器，adb 可能被抢占，表现是设备列表一会儿有一会儿没有。遇到这种情况，先关掉其他会占用 adb 的程序，再重新连接，不要急着重装驱动。

开工前检查清单

□ 应用为自有版权或已获授权，改包目的合规

□ 原包已备份，版本号与包名已记录

□ 图标五档 PNG 齐全，圆图标与自适应前景也有

□ 应用名中英文对照表已确认，没有特殊符号

□ 启动页至少两种比例，主体在安全区内

□ 工作目录在本地固定盘，剩余空间不少于 1 GB

□ 至少一台真机能被 adb 识别，且已授权调试

□ 验收清单已写好，明确要看哪些界面、查哪些日志

三、换图标（一）：aapt 怎么认密度，65534 为什么不能当最高密度

换图标的第一道坎不是画图，而是“放在哪个目录”。Android 的 launcher 会根据当前屏幕密度去资源目录里挑一张最合适的图。同样叫 ic_launcher.png，放在 mipmap-mdpi 和 mipmap-xxxhdpi 里就是两张不同的资源，系统按密度优先级取用。你只换了一张，剩下的几张还是旧图，在高密度手机上看到的就仍是旧图标。更隐蔽的是自适应图标：系统根本不看那几张 PNG，而是看 anydpi-v26 目录里的 XML。

1. 密度、倍数与目录的对应关系

电脑版导入 APK 后会调用 aapt 解析包信息，包括图标、应用名、包名、版本、SDK 与启动页。aapt 输出的图标路径通常长这样：res/mipmap-xxxhdpi-v4/ic_launcher.png，旁边会带一个密度值。把常见密度、目录、倍数和普通图标边长放在一张表里，后面替换素材时直接照着对。

表格里最后两行是关键。anydpi 表示“任意密度都适用”，aapt 给它的密度值是 65534；nodpi 表示“不要按密度缩放”，aapt 给它的密度值是 65535。还有一些资源密度值会是 0，表示默认。65534 不是一个“比 xxxhdpi 还高的密度”，它是一枚哨兵值，意思是“这张图不参与密度比较”。把这个概念记牢，后面看到 aapt 输出里出现 65534，就不会误判。

2. 把 65534 当最高密度会踩什么坑

如果程序简单地把密度值排序取最大，65534 会排在 640 前面，于是它会把 mipmap-anydpi-v26/ic_launcher.xml 当成“最高清的原图”。可那是一个 XML，不是位图，解码会失败；即使勉强读出来，也拿不到真正的图标像素。电脑版在处理图标时会把 65534 排除在“最高密度原图”的选择之外，只在 PNG、WEBP 这类位图里按真实密度取最高那一张。你手动改包时也要记住同一个道理：不要看到 anydpi 就以为它最大，也不要为了“清爽”把 anydpi 目录删掉。

同样地，65535 的 nodpi 也不能当成最高密度。nodpi 的意思是“这张图不跟随密度缩放”，它可能是一张很大的启动图，也可能是一张很小的装饰图，和图标清晰度没有关系。把 65534、65535、0 这三个值从“最高密度”的候选里排除掉，只在 36 到 640 这些真实密度里排序，逻辑才是对的。

一句话记住

65534 是“任意密度”的哨兵值，65535 是“不缩放”，0 是“默认密度”，三者都不是“最高密度”。真正参与清晰度比较的，是 36、48、72、96、144、192 这些按倍数排列的位图。

3. 自适应图标的三层结构：XML、前景、背景

Android 8.0 以后，很多应用使用自适应图标。它不是一个 PNG，而是一个 XML：mipmap-anydpi-v26/ic_launcher.xml 里引用前景层和背景层，前景层通常是一个 drawable，背景层可以是颜色也可以是图。系统会把这两层裁成圆形、圆角方形、水滴形等不同形状。前景层的画布是 108dp×108dp，但真正保证可见的是中间 72dp×72dp 的区域，最保险的内容再缩到直径 66dp 的圆里。

这带来一个非常常见的翻车点：你在 Android 8.0 以上的手机上只替换了 mipmap-xxxhdpi 里的 PNG，桌面却一点没变，因为系统优先使用了 anydpi-v26 的 XML。正确的做法是同时处理两条路径：保留 XML，把 XML 引用的前景层图片换掉；或者把 XML 与五档 PNG 一起换掉，确保新系统走自适应、老系统走位图。电脑版解析图标时会优先拿最高密度的位图做预览，但真正改包时要让 AI 把 anydpi 与位图两条路径都覆盖，不能只改一处。

自适应图标的背景层也有讲究。如果背景是一张带纹理的图，要注意系统会把它拉伸到整个 108dp 画布，纹理太细会在裁切后出现摩尔纹；如果背景是纯色，直接引用颜色资源最省事，也最不容易在不同遮罩下露出破绽。前景层则要避免把重要元素放在四角，因为圆形遮罩最先裁掉的就是四个角。

4. 透明边、留白与遮罩：图标看起来“小一圈”的原因

图标设计稿通常带透明边。透明边不是越多越好：留白过多，图标在桌面上会显得比旁边的小一圈；完全不留白，圆角遮罩又会切到图形边缘。经验做法是普通图标四周留 4% 到 8% 的透明边，自适应图标把主体控制在中间 66dp 的圆里，四周留够被裁的空间。不要在图标里预先画好圆角、阴影或白色底板，遮罩是系统画的，你画了就会叠两层。

还有两个容易漏的资源：圆形图标 ic_launcher_round.png，以及部分应用在 Manifest 里用 android:roundIcon 单独指定的圆图标。只换 ic_launcher 不换 roundIcon，在部分设备上会出现“桌面是新的、应用信息里还是旧的”这种诡异现象。素材准备时就把圆版一起做出来，改包时一起替换。圆版不是把方版硬裁成圆，而是重新排版：主体略缩小，四周留出圆形安全区，否则裁完会缺角。

5. 换图标常见失败对照表

这张表建议收藏。后面改名字、换启动页各有一张类似的表，三张表合起来，基本覆盖三件套的绝大多数问题。注意一个顺序：先确认“资源有没有换对”，再确认“系统有没有缓存”，最后才怀疑“工具链有没有问题”。绝大多数“没生效”都发生在前两层，真正坏在打包链路上的比例并不高。

四、换图标（二）：从附件到装机的一套完整步骤

理解了密度和自适应结构，接下来把换图标走成一条完整链路。下面七步和后面改名字、换启动页的步骤骨架相同，区别只在素材和需求内容。第一次做建议严格按顺序来，每一步都确认产物再往下走，不要一边改一边猜。

第 1 步：整理素材，保持资源名不变

新建一个 icon_v2 文件夹，把五档普通图标、圆版图标、自适应前景、自适应背景分别放进去。文件名尽量与 APK 里的资源名一致，例如 ic_launcher.png、ic_launcher_round.png、ic_launcher_foreground.png。保持资源名不变有两个好处：AI 不需要猜你想起什么新名字，回编时也不会出现“资源找不到”的连锁错误；你后期对照旧包时，一眼就能看出哪张图换了、哪张没换。

导出前做一次小尺寸预览。把 192 像素的图缩到 48 像素，看看还能不能认出主体；很多在电脑上很精致的 logo，缩到桌面大小就糊成一团。透明边也在这时处理：四周留 4% 到 8%，用裁剪工具把多余的透明区域切掉，再按画布居中。不要用“拉伸到画布”这种方式补边，比例一变，图形就变形了。

第 2 步：导入 APK，先读清楚它原来长什么样

把 APK 拖进主窗口，等解析完成。一个 12 MB 左右的包，实测大约 3 秒完成反编译；超过 10 分钟没有结束，程序会中断并报错。解析完成后先别急着点下一步，花一分钟核对四件事：包名对不对、版本号对不对、应用名对不对、图标路径指向哪里。如果图标路径是 mipmap-anydpi-v26 下的 XML，说明这个包用了自适应图标，后面必须同时处理 XML 引用的前景层；如果路径是某一张 PNG，说明它至少在这个解析结果里走的是位图路线。

解析失败时先看 apktool.log 的最后几十行。常见原因是 APK 不完整、下载时被截断、加了壳导致资源表异常，或者文件其实是 XAPK、APKS 这类分包格式却被当成了单 APK。电脑版支持导入 APK、JAR、APKS、XAPK、APKM 等格式，遇到分包时按对应格式导入，不要手动改扩展名。

第 3 步：挂附件，每个文件写够十个字的用途

换图标最适合用附件，因为图片本身没法用一句话描述清楚。点附件按钮，一次可以多选文件；每个文件都要写用途说明，而且说明不能少于 10 个字。这是硬校验，不是建议：程序会检查文件是否存在、是不是目录、是不是 0 字节、是否可读，说明太短或文件不合格都会被拦下来。附件最终会按“序号 + 路径 + 说明”的形式拼进需求里，一起发给 AI。

不要五个文件都写同一句“这是新图标”。说明的作用是让 AI 在多个附件之间建立对应关系，五张图配五句具体的话，它才知道哪张放 mdpi、哪张放 xxxhdpi、哪张是前景层。附件说明也不会写进 history.ini，历史记录只保留你的需求原话；所以如果你打算以后用历史里的“选择”回填重跑，记得把附件说明另外存一份，重新挂附件时直接粘贴。

第 4 步：写需求，把“改成什么样”拆成五段

需求写得越像一份验收单，AI 改得越稳。可以直接套这个五段结构：目标、位置、约束、不要动、验收。目标说清换成什么；位置说清改哪些资源、哪些密度；约束说清透明边、安全区、背景色；不要动说清包名、版本号、启动页、权限这些不能碰的东西；验收说清改完你要看到什么。下面是一个可以直接改用的例子。

换图标需求示例

把本项目的桌面图标换成附件里的新 logo。要求：一、五档 mipmap 位图全部替换，保留原文件名与目录；二、同步替换 mipmap-anydpi-v26 引用的前景层，背景保持原来的颜色；三、圆版图标 ic_launcher_round 一起替换；四、不要改包名、版本号、应用名和启动页；五、改完保留原资源目录结构，不要新增无关资源。

这段需求里，每一条都在防一种翻车。第一条防“只改一张”；第二条防“新系统走自适应、旧图没换”；第三条防“圆图标没变”；第四条防“AI 顺手把名字也改了，验收时说不清是谁改的”；第五条防“资源目录被重排，回编找不到引用”。你不需要每次写这么长，但上面五种信息至少要有。

详情页里还有 3000 条话术，按 6 类、每类 500 条组织，点选即可填入输入框。话术适合起步，比如“把桌面图标换成新的”，但真正提交前一定要补上资源名、密度和“不要动”的范围。话术是模板，不是合同；模板能帮你想起要说什么，具体约束还得自己补。

第 5 步：点“立刻修改”，等的是文件不是动画

点“立刻修改”后，原文和日期会写进 history.ini，需求被送进右侧 AI 工作区执行。AI 完成后会在项目目录里留下 ai_done.flag，主窗口每 2 秒轮询一次，读到这个文件就删掉，表示这一轮结束；等待上限是 1 小时。界面上有进度和状态，但真正可靠的完成信号是那个文件。等的时候不要反复点提交，重复提交会让 history.ini 里多出几条互相冲突的记录，也会让 AI 工作区同时处理多个任务。

等待期间可以做两件事：一是看 apktool.log 有没有新的报错，二是看 error.log 有没有未处理异常。如果超过预期时间还没结束，先确认 ai_done.flag 是否出现、项目目录是否还在、磁盘是否写满，再决定重试。重试时把需求范围缩小，比如先只换普通图标，确认链路通了，再补自适应前景和圆版。

第 6 步：回编与签名，四步各有各的失败方式

AI 改完并不等于拿到能装的包，还要走打包。电脑版的打包是四步：apktool 回编生成未签名 APK，zipalign 做对齐，apksigner 签名，apksigner verify 校验。每一步都会写进 pack.log。换图标阶段最常见的失败是回编时报资源找不到，通常是因为素材文件名和 XML 引用对不上，或者替换时把某个密度目录整个删了；其次是对齐失败，通常是路径里有中文或空格；签名失败则多半是密钥格式或口令问题，具体排查放在第九节。

第 7 步：装机验收，图标要看三个地方

打包完成后可以直接让程序自动安装。它会先找 adb 设备，装包，然后用 am start -W -n 包名/Activity 拉起应用；组件名有三档查找顺序：先读 config.ini 里的 LaunchableActivity，再用 cmd package resolve-activity --brief 查询，最后走旧方式兜底。装完还会用 dumpsys 复核前台应用，手机通过 scrcpy 投屏，模拟器窗口会被提到最前。看到应用真的起来了，才算装成功，而不是看到“安装完成”四个字就结束。

图标验收至少看三个地方：桌面（方形遮罩和圆形遮罩各看一次）、设置里的应用信息、最近任务卡片。三个地方都显示新图标，才算真的换干净。再补两个动作：在旧机或模拟器上看一次，确认不走自适应图标的那条路径也正常；把桌面图标删掉再重新拖出来，确认不是缓存残留造成的假象。如果只有桌面是旧的，先卸载重装；如果只有应用信息是旧的，多半是 anydpi 前景没换；如果三个地方全是旧的，回头查附件和需求，不要怀疑手机。

五、改应用名（一）：label 的生效顺序与桌面缓存

改应用名看起来只是改一个字符串，实际有三层：Manifest 里的 label、资源里的字符串、桌面缓存下来的显示名。三层里任何一层没处理，结果都可能是“设置里变了、桌面没变”或者“中文变了、英文没变”。这一节把生效顺序讲清楚，下一节再走完整实操。

1. Manifest 里的两个 label，谁说了算

应用名通常写在 AndroidManifest.xml 的 application 节点上：android:label="@string/app_name"。但很多应用会在启动 Activity 上再写一个 android:label。桌面在显示图标名称时，优先使用启动 Activity 的 label；没有才回退到 application 的 label。也就是说，你只改了 application 的 label，启动 Activity 上却写死了旧名字，桌面仍然显示旧名。改之前先用工具或反编译结果确认这两个位置分别是什么，别凭印象。

还有一种更隐蔽的情况：启动 Activity 用的是 activity-alias。alias 自己可以带 label 和 icon，桌面显示的是 alias 的 label。如果包里有 alias，必须把 alias 的 label 一起改，否则改完主 Activity 也没用。判断方法很简单：在反编译出来的 Manifest 里搜 activity-alias，看看有没有指向启动 Activity 的别名节点。

2. 字符串资源与语言限定：为什么英文环境还是旧名

字符串资源放在 res/values/strings.xml 里，默认语言一份；如果应用做了多语言，还会有 values-zh-rCN、values-en-rUS 这类限定目录。系统按当前语言去找最匹配的那份，找不到才回退到默认。你只改了默认的 app_name，用户在英文环境下看到的就是 values-en 里的旧名字。更细的还有 BCP47 形式，例如 values-b+zh+Hans，命名方式不同，作用一样：按语言和文字系统匹配。

改名字时最稳的做法是先搜 app_name，把所有语言目录里的同名条目列出来，再逐条替换。不要只改第一处就以为完事。如果某个语言目录里没有 app_name，它就会回退到默认，那就不用管；如果有，就必须改。还要注意 application 的 label 是否直接写了硬编码字符串，而不是引用 @string/app_name；硬编码的 label 不会跟着 strings.xml 变，必须在 Manifest 里单独改。

XML 的转义也容易出问题。名字里有 & 要写成 &，有单引号要写成 \' 或者用双引号把整段包起来，有尖括号要写成实体。中文名字一般不会遇到这些，但“记账助手 & 报表”这种带符号的名字很常见，写错一个字符，回编就会报错。文件编码用 UTF-8，不要带 BOM；带 BOM 的文件在部分工具链里会在字符串开头多出一个不可见字符，桌面显示时看不出来，搜索和比对时却对不上。

3. 桌面缓存：为什么覆盖安装后还是旧名字

桌面应用（Launcher）会把图标和名称缓存起来，覆盖安装后不一定立刻刷新。不同厂商的桌面刷新策略不一样，有的收到包变更广播就刷新，有的要等下一次重启，有的只在图标被重新拖到桌面时更新。于是你遇到的现象是：设置里的应用信息已经是新名字，桌面还是旧的；或者反过来，桌面上新了，最近任务里还是旧的。

处理顺序建议这样：先确认 APK 里的 label 真的改了（用 aapt 看构建产物），再处理缓存。缓存处理从轻到重：重启桌面进程、切换系统语言再切回来、重启手机、卸载重装。卸载重装最彻底，但会清掉应用数据，动手前先备份。清除桌面数据也能刷新，但会把桌面布局恢复默认，不到万不得已不要用。验收时不要只看桌面，设置里的应用信息、最近任务、通知栏标题都要看一遍。

4. 覆盖安装、签名与包名：改名时最容易忽略的三件事

第一，覆盖安装要求签名一致。同一个包名，旧包用 A 密钥签，新包用 B 密钥签，安装器会直接报签名冲突，常见提示是 INSTALL_FAILED_UPDATE_INCOMPATIBLE。解决方式只有两个：用同一套密钥签，或者先卸载旧包再装。卸载会清数据，内测应用尤其要先跟使用者打招呼。

第二，改名不要顺手改包名。包名是应用的身份，改了包名等于换了一个新应用：旧数据不共享、推送收不到、深链失效、后台白名单要重配。除非你明确要做“并存安装”，否则只改 label，不动包名。要做并存安装，也应该在构建配置里做 applicationId 后缀，而不是在改包时手改 Manifest 里的 package。

第三，版本号要往前走。内测分发时，覆盖安装通常要求新包的 versionCode 不小于旧包；应用商店还要求严格递增。改名字往往伴随一次新内测，把 versionCode 加一、versionName 改成可识别的内测号，后续排查问题时能一眼看出同事装的是哪一版。

5. 名称出现的位置与对应改法

把这张表和前面那张图标失败表放在一起，你会发现一个规律：三件套的“没生效”大多不是改错了，而是改的位置不完整，或者看到的位置有缓存。验收时多换几个入口看，比盯着一个桌面反复重启有效得多。

六、改应用名（二）：三种需求写法对比与自家记账 App 实例

名字的信息量小，写需求时最容易偷懒，只写一句“把名字改成某某”。这一节先给三种写法，再走完整步骤，最后用自家记账 App 的实例把“以前怎么做、现在怎么做、改完怎么验证”串起来。

1. 准备名称对照表

新建一个 name-map.csv，至少四列：语言、旧名、新名、备注。默认语言写一行，中文写一行，英文写一行；如果应用还有繁体或其他语言，也各写一行。备注里写清“内测版”“不得翻译”“保留品牌词”这类约束。这个文件既可以直接当附件，也可以作为你写需求的底稿。名称里不要带表情符号和罕见特殊字符，桌面显示、搜索、通知渠道都可能出问题。

2. 同一需求的三种写法

三种写法不是互相替代，而是三种粒度。第一次改、只有中文、只想验证链路，口语版就够；要发给同事复现，或者应用有中英文两套名字，至少用结构化版；名称涉及多个语言、多个渠道包，附件版最省事。最稳的组合是“结构化正文 + 名称对照附件”：正文写规则，附件给数据，AI 不需要从一句话里猜你的言外之意。

结构化需求示例

修改应用的显示名称。默认语言改为“记账助手 内测版”，英文改为“Ledger Beta”；同步修改 application 的 label、启动 Activity 的 label，若存在 activity-alias 也一并修改；不要改包名、图标和启动页；改完输出所有被修改的资源文件路径，便于核对。

3. 改名字的六步操作

1. 导入 APK，确认包名、版本号与当前应用名，记下启动 Activity 的名字。
2. 挂附件：名称对照表，说明写够 10 字，例如“中英文应用名对照表，默认语言与英文各一行”。
3. 写需求：用结构化模板，明确 application、Activity、alias 三处，明确不要动包名。
4. 点“立刻修改”，等 ai_done.flag 出现；期间不要重复提交。
5. 回编、对齐、签名、校验，四步走完看 pack.log 是否全绿。
6. 安装后按“桌面、应用信息、最近任务、英文环境”四个入口验收，再处理桌面缓存。

验收时先用 aapt 看构建产物，这是最不容易被缓存骗的一步。aapt 的输出里会有 application-label 和带语言后缀的 label 行，确认默认语言与英文都对，再去设备上看。设备上如果桌面仍旧，先别改包，按上一节的缓存顺序处理；如果应用信息里也是旧的，那才是包没改对，回到资源与 Manifest 检查。

4. 实例 A：自家记账 App 换新 logo 并改内测名

背景：团队自己开发的记账 App，包名与数据格式都稳定，内测群里发给同事试用。这一轮要换新 logo，并在名字后加“内测版”，避免和正式版混淆。应用是自有版权，改包目的仅为内测分发，不涉及任何第三方的商业应用。

以前怎么做。设计师给出一张 1024 像素的方图，需要自己导出五档 PNG，再单独做圆版和自适应前景；然后手动进 mipmap 各目录替换，改 strings.xml 的默认值与英文值，还要记得改启动 Activity 的 label；接着 apktool 回编、zipalign 对齐、apksigner 签名，adb 装到手机。每改一个细节就要重来一轮，最容易漏的是圆版图标和英文资源，同事装完经常反馈“桌面还是旧名字”，最后只能卸载重装再试。

现在怎么做。先把六份素材按资源名放好：五档普通图标、圆版、自适应前景，再加一份中英文名称对照表。把 APK 拖进电脑版，确认包名与版本号，挂上附件，每个附件写清用途，例如“新版桌面图标 192 像素透明底，替换 xxxhdpi 普通图标”“自适应前景层，主体居中，替换 ic_launcher_foreground”。需求用结构化写法：换五档图标与圆版、同步自适应前景、默认名与英文名一起改、保留包名与版本号、不要动启动页。点“立刻修改”，等 ai_done.flag，随后回编、对齐、签名、校验，最后自动装到内测同事的手机上。

改完怎么验证。一，在桌面看方形与圆形两种遮罩，确认新 logo 没有被裁边、没有白底；二，进设置的应用信息，确认名字是“记账助手 内测版”；三，打开最近任务，确认卡片标题也变了；四，把系统语言切成英文，确认显示的是英文新名；五，冷启动一次，确认应用正常进入首页，记账数据还在；六，用 aapt 看构建产物的 label，并与设备显示对照；七，检查签名校验输出，确认证书指纹是团队自己的。七项都过，才把包发到内测群。

这个实例的关键不是“AI 一句话搞定”，而是“素材、说明、需求、验收”四件事都具体。换 logo 与改名字放在同一轮做，是因为两者都属于“身份层”的修改，验收入口高度重合；启动页属于“首屏体验”，放到下一轮单独做，出问题时更容易定位。

七、换启动页（一）：三条启动路径、比例与拉伸裁切

三件套里，启动页最容易“看起来改了，实际上没改”。原因是 Android 的启动画面不止一条路径：低版本靠主题的 windowBackground 画一张起始窗口，有些应用另做一个 SplashActivity 显示几秒，Android 12 以后系统又强制接管了一层闪屏。你改了其中一条，另外两条还在，用户看到的就可能是旧图、白屏，或者“图标加纯色底”的系统默认样式。

1. 三条路径：主题、独立页面、系统闪屏

第一条是主题路径。应用在 Manifest 里给启动 Activity 指定一个主题，主题的 windowBackground 设成一张图或一个 layer-list。冷启动时，系统在 Activity 还没绘制完成前，先用这个背景画一个起始窗口，所以用户点开图标后立刻能看到图，而不是白屏。这条路径的优点是快、兼容性好；缺点是它只是“起始窗口”，Activity 一旦绘制完成就被替换，图片能显示多久取决于应用初始化速度。

第二条是独立启动页。应用专门做一个 SplashActivity，布局里放一张全屏图，等初始化完成或倒计时结束再跳主页面。这条路径能精确控制显示时长和动画，但会多一个 Activity，返回栈处理不好会出现“按返回又回到启动页”；热启动时如果直接进主页，启动页可能根本不再出现。改这条路径时，除了换图，还要确认跳转逻辑没有被破坏。

第三条是 Android 12 及以上的系统闪屏。系统会为每个应用显示一层启动画面，背景色、中央图标、图标背景色、退出后的主题分别由 windowSplashScreenBackground、windowSplashScreenAnimatedIcon、windowSplashScreenIconBackgroundColor、postSplashScreenTheme 控制。如果应用没有适配，系统会用默认方式：背景取主题的 windowBackground 颜色，图标取 launcher 图标。于是你只改了旧主题里的背景图，Android 12 以上的手机仍然先显示“launcher 图标 + 纯色底”，看起来像没改。

改启动页前先问一句

这个包在 Android 12 以上跑的时候，系统闪屏用的是什么背景、什么图标？如果答不上来，先让 AI 把三条路径都列出来，再决定改哪几个资源。只改一条，往往等于没改。

2. 比例与安全区：一张图要适配多少种屏幕

启动图最常见的翻车是比例。手机屏幕从 16:9 一路走到 21:9，同一张图在不同机器上要么上下留黑边，要么左右被裁掉。稳妥的做法是做一张主图，主体放在中央安全区，四周留出可裁切的空间；再用 centerCrop 的方式铺满屏幕。这样长屏裁上下、宽屏裁左右，主体都不会丢。

安全区不是“把主体缩小”这么简单。启动页通常有 logo、标语、底部版权或版本号，logo 放中央问题不大，标语和版本号最容易被裁。建议把非关键元素放进中央 50% 的区域，版本号这类“有就行、被裁也无所谓”的信息可以贴近底部，但不要贴着边缘，至少留出状态栏和虚拟按键的高度。做图时把安全区用辅助线标出来，导出前再检查一次，比装到手机上发现被裁要省事得多。

3. 拉伸与裁切：三种铺法各自适合什么图

第一种是居中不缩放。layer-list 里的 bitmap 用 gravity=center，图片按原始像素画在中央，周围由底色填充。这种铺法不会变形，但图片比屏幕小时会露出大片底色，比屏幕大时会被裁掉四周。适合“图标 + 纯色底”的启动页，不适合整张照片。

第二种是铺满并裁切，也就是 centerCrop 的思路。图片等比放大到短边填满屏幕，长边超出部分裁掉。它不会变形，也不会留黑边，是照片型启动页最稳的铺法。实现方式有两种：在独立启动页的布局里用 ImageView 并设置 centerCrop；或者按主要比例各导一张图，让系统按当前比例选最接近的那张。前者一张图走天下，后者更省内存，但素材多。

第三种是拉伸铺满，也就是 fitXY。它会把图片横向和纵向分别拉到屏幕大小，屏幕比例和图片比例不一致时，人像会变胖、圆形会变椭圆。除非你的图是纯色或极简几何，否则不要用。很多人为了让图“刚好铺满”选了这一种，装到长屏手机上立刻看出变形，回头又以为是自己素材做错了。

还有一个容易忽略的细节：图片放在哪个 drawable 目录。放在 drawable-nodpi 里，系统不会按密度缩放，图片按原始像素显示，适合全屏启动图；放在普通 drawable 目录里，系统可能按当前密度放大或缩小，同一张图在不同手机上看到的尺寸不一样。全屏图放 nodpi，图标类资源放 mipmap 对应密度，这是两条不同的规则，不要混用。

4. 九宫格图与那个 77 字节的伪九宫格

有些启动背景用九宫格图，也就是文件名以 .9.png 结尾的图。它在 PNG 四周留了 1 像素的透明边，用来标记可拉伸区域和内容区域：上边和左边画黑线决定哪里能拉伸，下边和右边画黑线决定内容放哪里。九宫格适合“圆角卡片 + 可拉伸中段”这种背景，不适合整张照片，因为照片的可拉伸区域很难标得自然。

真实排错里遇到过一个很典型的例子：在 Android 16 设备上，apktool 2.12.1 对 APK 里 18 个只有 77 字节的伪 .9.png 打印了 “Could not find 9patch chunk … Renaming it to *.png”。这些文件名字带 .9，实际没有九宫格数据，apktool 按标准兜底把它们改名成普通 PNG，回编仍然成功，产物不受影响。看到这条警告不用慌，先确认它说的是“改名后继续”，而不是“编译失败”；真正要担心的是回编阶段报资源找不到，那才是引用断了。

这也解释了为什么改启动页时不要随手把普通 PNG 改名成 .9.png。九宫格不是改个后缀就生效，缺了那 1 像素的标记线，工具链只会给你一条警告，然后按普通图处理；你以为自己做了可拉伸背景，实际得到的还是一张会被裁切的位图。

5. 深色模式与 Android 12 以上

深色模式要有单独的图，或者至少有一个能看的纯色底。只做一张亮色图，系统切到深色模式时，启动页会突然闪一块高亮色，观感很差。做法是准备 values-night 下的一套资源，把背景色或背景图换成深色版本；如果应用本身不支持深色模式，也要确认启动页在深色系统下不会被系统强制反色。

Android 12 以上的系统闪屏要单独适配。核心是四件事：背景色、中央图标、图标底色、退出后的主题。背景色用 windowSplashScreenBackground；中央图标用 windowSplashScreenAnimatedIcon，通常放一个自适应图标或矢量图；图标底色用 windowSplashScreenIconBackgroundColor；退出后要切回应用自己的主题，否则后续界面会继承闪屏主题，出现状态栏颜色不对、背景透明之类的问题。只改旧主题的 windowBackground，系统闪屏仍然会按它自己的规则画，所以验收必须包含一台 Android 12 以上的设备。

八、换启动页（二）：七步操作与内部工具实例

启动页的实操和换图标一样，也是“素材、附件、需求、AI、回编、装机、排查”七步，但需求里要额外写清三件事：改哪条启动路径、图片怎么铺、Android 12 以上怎么处理。下面按顺序走一遍。

第 1 步：准备主图、深色图与安全区

先做一张 1440×3200 的主图，主体放中央，标语和版本号也尽量往中间靠。再用同一版式做一张深色图，背景换成深灰或品牌深色，logo 换成浅色版本。两张图都导出 PNG 或高质量 WebP，控制在合理体积；启动图是冷启动第一帧，文件太大只会拖慢首屏。导出前把图放到 1080×1920 和 1080×2520 两个画布上各裁一次，看看主体是否还在，这比装到手机上试快得多。

第 2 步：导入 APK，确认当前走的是哪条路径

导入后先别写需求，花两分钟确认现状：启动 Activity 是哪一个，它的主题是什么，主题里的 windowBackground 是图还是颜色；有没有独立的 SplashActivity；有没有 values-v31 这类 Android 12 专用资源。电脑版会把启动页信息解析出来，但三条路径的细节仍要结合项目里的资源结构看。确认现状之后再写需求，才不会出现“AI 改了独立页面，实际生效的是系统闪屏”这种白忙一场。

第 3 步：挂附件，把亮色与深色分开说明

启动页附件通常两张：亮色主图与深色图。说明照样不能少于 10 字，而且要写清“哪张用于哪种模式、铺法是什么”。例如“亮色启动页主图 1440×3200，用于普通模式，居中裁切铺满”“深色启动页背景图，用于 night 模式，主体位置与亮色版一致”。如果还有独立启动页的 logo 图，也一并挂上，说明写清是“中央 logo”还是“底部品牌图”，不要让 AI 猜。

附件拼进需求时是按“序号 + 路径 + 说明”排的，说明写反了，图就可能被放到错误的模式里。挂完在界面上从头到尾读一遍，确认序号和图对得上，再点提交。这个动作只要十几秒，却能省掉一轮重打包。

第 4 步：写需求，明确“不改跳转、不拉伸、适配 v31”

启动页需求建议固定包含六条：换哪张图、放哪个目录、怎么铺、深色模式怎么办、Android 12 以上怎么办、哪些东西不能动。下面是一个可以直接改用的版本。

换启动页需求示例

把启动页背景换成附件里的图。要求：一、保留原启动 Activity 与跳转逻辑，不改启动顺序；二、普通模式与深色模式各用对应附件；三、图片放 drawable-nodpi，按居中裁切铺满，不要拉伸变形；四、Android 12 以上补充 v31 主题，设置系统闪屏背景与退出后的应用主题；五、不要改 launcher 图标、应用名、包名与版本号；六、不要把图片改名成九宫格。

第三条和第四条是启动页特有的。只写“换背景”，AI 可能把图塞进普通 drawable，系统按密度一缩放，长屏上就变形了；只写“适配新系统”，又可能把旧版本的起始窗口忘了，低版本用户先看到白屏。把“放哪个目录、怎么铺、两条路径都覆盖”写清楚，返工率会低很多。

第 5 步：AI 修改后，先看改了哪些文件

点“立刻修改”后同样等 ai_done.flag。完成后不要直接打包，先在项目目录里看一圈：主题文件有没有新增 v31 版本，drawable-nodpi 里有没有新图，Manifest 里的启动 Activity 有没有被误改，values-night 是否真的加了资源。电脑版的项目目录保留完整的 apktool 工程，apktool.log 也在里面，配合内置的文本查看器就能核对。看到“改动的文件清单”和需求对得上，再进入打包。

第 6 步：回编、对齐、签名、校验

打包还是四步：apktool 回编、zipalign 对齐、apksigner 签名、apksigner verify 校验。启动页改动通常不涉及代码，回编失败多半是资源引用问题：图片被改名、目录被移动、v31 主题里引用了不存在的 drawable。签名失败则按第九节的方法查密钥与口令。pack.log 里每一步都有命令和输出，失败时直接搜 “error” 和 “Exception”，比在界面上反复点重试有效。

第 7 步：装机验收，冷启动才算数

启动页必须用冷启动验收：先强行停止应用，再点图标打开，看第一帧到底是什么。热启动时应用还在内存里，系统可能直接恢复界面，启动页根本不出现，用它验收会得出错误结论。冷启动至少做三次，分别在不同比例的设备上；再切一次深色模式，再找一台 Android 12 以上的设备看系统闪屏。条件允许的话录屏，逐帧看有没有白闪、黑闪、图跳一下再稳定的情况。

验收还要看“之后”：启动页结束能不能正常进首页，按返回会不会又回到启动页，通知点进来会不会重复显示启动页，深色模式切回亮色后背景有没有残留。启动页是入口，入口坏了，用户连首页都到不了，比图标难看严重得多。

实例 B：自家内部工具换启动页背景

背景：团队内部使用的一个工具类应用，原来启动页是测试环境的亮蓝色背景，上面有旧版 logo。现在要换成品牌深绿背景，并补一套深色模式图。应用是自家开发、内部使用，不对外分发，改包只用于内部更新。

以前怎么做。先在主题文件里找到 windowBackground，确认它指向哪张图；然后按三个比例各导一张，手动放进对应目录；再改深色模式的资源；打包、对齐、签名，把 APK 发到内部群，让同事自己装。最麻烦的是验收：每个人手机比例不同，反馈“图被裁了”“先白闪一下”“深色模式太亮”，只能一张张图改、一轮轮发包。Android 12 的同事还会看到系统闪屏，旧主题改了也没用，得再补一套 v31 资源。

现在怎么做。准备两张图：1440×3200 的亮色主图与同版式的深色图。把 APK 拖进电脑版，确认启动 Activity 和主题现状，挂上两张附件，说明写清“亮色主图，用于普通模式，居中裁切铺满”“深色背景图，用于 night 模式，主体位置一致”。需求按六条写：保留跳转、两套模式、nodpi 目录、居中裁切、补 v31、不要动图标与名称。AI 改完后先看主题与资源目录，确认 v31 和 values-night 都在，再回编、对齐、签名、校验，最后自动装到三台测试机上。

改完怎么验证。一，三台设备各自强行停止后冷启动，录屏看第一帧，确认没有白闪、没有拉伸；二，分别在 16:9、19.5:9、21:9 的屏幕上看主体是否完整；三，切深色模式再冷启动，确认背景变深、logo 清晰；四，在 Android 12 以上的设备上看系统闪屏的背景与图标，确认不是默认样式；五，进首页后按返回，确认不会回到启动页；六，看 pack.log 与签名校验输出，确认这一轮产物可追溯。六项都过，再把包发到内部群。

这个实例说明一件事：启动页的“改”只是几步，“验”才是大头。以前靠人肉收集反馈，现在把验收项固定成清单，三台设备、两种模式、三条路径，一轮就能覆盖大多数问题。安卓修改大师电脑版在这里省掉的是重复打包和装机的体力活，真正决定质量的仍是你有没有把验收做完整。

九、回编、对齐、签名、校验：四步打包到底在做什么

三件套改的都是资源，但资源改完只是“工程变了”，还不是“能装的包”。从工程到可安装的 APK，中间有四步：回编、对齐、签名、校验。很多人把这一步当成黑盒，看到“打包成功”就装机，结果遇到签名冲突、安装解析失败、启动闪退，又回头怀疑自己图改错了。把四步拆开看，每一步的输入、输出和失败方式都很清楚。

1. 回编：把工程重新编译成未签名 APK

回编用 apktool 完成，核心命令是 apktool b -f -o build\unsigned.apk。b 表示 build，-f 表示强制覆盖已有输出，-o 指定输出路径。它会把反编译出来的资源、Manifest、smali 重新编译、打包成一个未签名的 APK。换图标、改名字、换启动页之后，回编是把这些改动真正写进包里的第一步。

回编失败最常见的原因是资源引用断了：图片被改名、目录被移动、XML 里引用的 drawable 不存在、字符串转义写错。apktool.log 会指出哪个文件、哪一行出的问题，先看最后几十行，再往上找第一个 error。还有一种“看起来像错误”的警告：九宫格图缺少 chunk 时，apktool 会提示改名成普通 PNG 然后继续，这种不影响产物；真正的失败会明确写 build failed 或以非零状态结束。

2. 对齐：让未压缩资源落在该落的边界上

对齐用 zipalign，典型命令是 zipalign -f -p 4 build\unsigned.apk build\aligned.apk。-f 覆盖输出，-p 让共享库按页对齐，4 是 4 字节边界。对齐的作用是让 APK 里未压缩的资源在文件中有合适的偏移，系统可以直接映射读取，减少启动和运行时的额外拷贝。没有对齐的包通常也能装，但可能出现读取效率下降，部分安装器或上架检查还会直接拒收。

对齐失败多半是路径问题：输入文件不存在、输出目录没建、路径里有中文或空格被截断。先确认 build 目录存在、文件名没有空格，再重试。对齐完成后可以用 verify 模式检查一次，确认输出确实对齐，而不是只看命令有没有报错。

3. 签名：四种密钥来源与四代签名方案

签名用 apksigner，典型命令是 apksigner sign --ks 密钥文件 --ks-key-alias 别名 --out build\signed.apk build\aligned.apk。电脑版提供四种签名来源：默认签名、JKS 或 keystore、PEM 加 PK8、随机签名。内部试用、只关心能不能装，用默认签名最省事；要覆盖升级、要保持应用身份，必须用同一套自己的密钥；PEM 加 PK8 适合已有证书链的团队；随机签名适合一次性的演示包，不适合长期分发。

签名方案有四代：v1 是传统的 JAR 签名，兼容老系统；v2 是 APK Signature Scheme v2，Android 7 起支持，校验整个 APK；v3 支持密钥轮换，Android 9 起支持；v4 配合增量安装，Android 11 起支持。电脑版默认启用 v1、v2、v3，覆盖绝大多数设备；v4 按需开启。只签 v2 不签 v1，老设备可能装不上；只签 v1 不签 v2，新系统会提示签名方案过旧。默认组合是有意为之，不要为了“包小一点”随手关掉。

密钥口令通过环境变量传入，不拼进命令行，也不写进日志。这是签名环节最重要的一条纪律：命令行会被历史记录、进程列表、日志捕获，口令一旦进了命令行，等于半公开。团队协作时也不要把 keystore 和口令放在同一个目录、同一个仓库里。

4. 校验：为什么多一步 verify 是值得的

签完名，很多人直接装。电脑版在签名之后多做一步：apksigner verify --print-certs。这一步会重新读取 APK，校验签名是否有效，并打印证书信息。多这一步的原因很实际：签名命令返回成功，不代表“签上了”，有些密钥格式错误、别名不对、证书链不完整的问题，只有 verify 会明确报出来。verify 通过，至少说明这个包在签名层面是自洽的；verify 不通过，装到手机上大概率也是白装。

--print-certs 打印出来的证书指纹，建议和团队记录的指纹对一次。覆盖升级时，新旧包的证书必须一致；指纹对不上，安装器会直接拒绝。把指纹写进发布记录，后面排查“为什么装不上”时能省掉大量猜测。整个过程会写进 pack.log，包括每一步的命令、输出和最终产物路径，发布前把这个日志和签名指纹一起归档。

5. 自动装机：从 adb 到前台复核

打包完成后，电脑版可以自动装到手机或模拟器。流程是：找 adb 设备、装包、用 am start -W -n 包名/Activity 拉起应用。组件名有三档查找顺序：先读 config.ini 里的 LaunchableActivity，再用 cmd package resolve-activity --brief 查询，最后走旧方式兜底。装完之后还会用 dumpsys 复核前台应用，确认起来的确实是刚装的那个包，而不是同名的旧版本或者另一个应用。

手机通过 scrcpy 投屏，模拟器窗口会被提到最前。这个设计对三件套验收特别有用：换图标要看桌面，改名字要看应用信息，换启动页要看冷启动第一帧，这三件事都必须在真实设备上看。自动装机把“找包、传包、点安装、找入口”这几步省掉，你要做的只剩下观察和判断。

如果自动装机失败，先分清楚是“装不上”还是“起不来”。装不上看 adb 输出：签名冲突、空间不足、解析失败，各有各的提示；起不来看组件名和 am start 的输出：Activity 找不到、权限拒绝、应用崩溃。电脑版会尽量用三档查找兜底，但如果你在改包时动了启动 Activity 的名字，config.ini 里的记录就会过期，这时要回到项目里重新确认组件，而不是反复重装。

6. 打包与装机失败对照

把这张表贴在打包按钮旁边，遇到失败先对阶段，再对提示，最后才动包。最忌讳的是“失败了就回退所有改动重来”，那样你永远不知道真正的原因，下一轮还会在同一个地方摔倒。

十、三件套联合验收、总排查与合规提醒

三个动作分开做，最后要合在一起验收。因为图标、名字、启动页共享同一个包、同一套签名、同一个桌面入口，任何一处没处理干净，都会在联合验收时暴露。下面这份清单建议在发内测包之前逐项打勾，不要凭印象。

1. 联合验收清单

2. 三件套总排查表

3. 用户评价

下面五条来自不同角色的使用者，场景都围绕换图标、改名字、换启动页。评价只代表个人体验，不构成效果承诺；真正决定结果的，仍是素材质量、需求写法和验收是否完整。

“以前最怕图标‘只换了一半’，高密度手机看新图，老手机还是旧图。文章里把 65534 是任意密度哨兵这件事讲透之后，我才明白为什么工具会把 anydpi 的 XML 当成最高密度。现在换图标固定五档加圆版加前景，一轮就能过。”

—— 老周（独立开发者）

“我们内部工具的启动页以前要按三个比例各导一张，发一次包在群里收一堆‘图又被裁了’的反馈。现在把亮色和深色两张图挂上去，需求里写清 nodpi、居中裁切、补 v31，三台测试机冷启动看一遍就定了，返工少很多。”

—— 阿岚（硬件公司应用维护）

“改应用名最容易漏英文和 Activity label。我第一次只改了默认字符串，桌面没变，还以为工具没生效。后来按结构化写法把 application、Activity、alias 三处都点出来，再挂一张中英文对照表，交付给客户前自己先验四个入口，心里踏实多了。”

—— 唐工（外包团队技术负责人）

“我们自己的展示 App 换活动启动图，最担心长屏裁掉标语。现在主图主体放中央，安全区按文章里的比例表留，装到不同手机上先冷启动录屏，再切深色模式看一遍。附件说明写清楚哪张用于哪种模式，AI 就不会把两张图放反。”

—— 小满（电商运营）

“测试视角看，最有用的是 verify 那一步和 pack.log。签名命令成功不等于签上了，证书指纹对不上，覆盖安装一定失败。现在每次发内测包，我都把 pack.log、证书指纹、versionCode 一起归档，出问题能直接定位到是哪一步，不用让开发重打一版再试。”

—— 陈默（测试工程师）

4. 合规提醒：能改不等于可以随便改

请先确认权利，再动手

本文所有实例都来自团队自有版权或已获明确授权的应用。请勿用于破解、去除付费限制、绕过安全机制，也不要修改他人的商业应用。即使是自有应用，分发时也要遵守原应用的许可协议、公司内部规定以及所在地区的法律法规。改包能力本身是中性的，用它做什么，取决于你的授权边界。

最后把三件套的关系收一下。换图标解决“第一眼认不认得”，改应用名解决“第二眼叫不叫得对”，换启动页解决“点开之后第一帧稳不稳”。三者共用一条流水线：素材要备齐，附件说明要写够，需求要具体，回编对齐签名校验一步不能少，装到手机或模拟器上要按清单验收。把这条流水线走顺，后面换主题色、换 banner、改文案，都是同一套方法。

如果你希望把重复的打包、装机、日志核对交给工具，把精力留在素材和验收上，可以试试安卓修改大师智改工坊里的安卓修改大师电脑版：Windows 10/11 64 位，.NET Framework 4.6.2 以上，安装包约 6.86 MB。产品介绍与下载入口是 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。还是那句话：只需说话，就能让应用变成你想要的样子。前提不变——说清楚、改准确、验完整。