应用内文案与系统弹窗：哪些字你能改、哪些字改不了（附判定表）

本文属于"新手上路"里的机制篇。主角是安卓修改大师智改工坊——一款 Windows 桌面工具：把安装包拖进来，用中文写一句需求，AI 在反编译出来的工程里改 smali 与资源，改完自动回编、对齐、签名、校验，最后一键装到手机或模拟器上看效果。它的介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

先讲一个几乎每个改包的人都提过的需求。有人这么写："把弹窗上的『允许』改成『同意』，再把『取消』改成『再想想』。"需求写得很清楚，包也打出来了，也装上了 —— 结果打开应用，系统权限弹窗上的两个按钮一个字都没动。

于是他开始怀疑工具：是不是没改成功？是不是签名不对？是不是模拟器缓存？其实真正的原因特别朴素：那个弹窗不是你的应用画的，是系统画的。 你包里根本没有那两个按钮的文字，改包自然改不到它们。这也是这篇文章要用一整篇讲清的一件事 —— 手机屏幕上同时存在两种字：一种来自你的安装包（能改），一种来自系统自己（改不了）。分不清这两者，就会出现"改了半天，屏幕上一点变化都没有"的挫败感；分得清，你写需求的时候就已经知道这一句该不该写。

一、屏幕上其实有两个"画字的人"

Android 的界面是"拼"出来的：应用进程负责画出自己的窗口，系统进程负责画出系统自己的窗口，两者叠在同一块屏幕上，但用的资源来自完全不同的两个地方。

画字的人一号：你的应用。 界面里的标题、按钮、提示、弹窗正文，绝大多数是应用用自己的资源画出来的 —— 文字存在安装包里的资源表（或者直接写在布局文件、代码里），渲染时由应用进程读取并绘制。这一部分改包一定能改，因为它就在你手里那个包里。

画字的人二号：系统。 权限弹窗、安装界面、"应用无响应"提示、分享面板、系统的设置页面 —— 这些窗口属于系统进程或系统应用，它们用的是系统自己的资源表（系统的框架资源与系统应用自带的字符串）。你的应用在里面只扮演一个"被点名的角色"：系统需要显示应用的名字时，会来查一下你的包里叫什么；除此之外，那些按钮文字、说明文字、标题措辞，一个字都不来自你的包。

这就解释了一个现象：同一句"允许"，在不同的手机上措辞可能不一样 —— "允许""始终允许""仅在使用该应用时允许"，甚至同一个品牌不同系统版本也不一样。这不是应用改过，而是不同系统版本、不同厂商定制里的系统资源本来就不一样。凡是会随系统变化而变化、跟着系统语言走的文案，基本都可以判定为"系统画的"。

一句口诀：先问这句话是谁画的，再问它住在哪一层。 顺序反了，就会在包里翻半天，最后发现那句话压根不在包里。

二、系统渲染清单：这些字不在你的包里

下面这张表把最常见的"系统画的字"列出来。它的用法很直接：想改某项文案之前先来这张表里对一眼 —— 如果它在这里，就别把时间花在改包上，换个思路（比如改应用名、改提问时机、或者干脆接受它）。

界面	谁在画	包里有吗	能改吗
运行时权限弹窗（按钮与说明）	系统权限控制器	不在	改不了
安装器界面（"要安装此应用吗"）	系统 PackageInstaller	不在	改不了
"应用无响应" / 停止运行提示	系统 SystemUI / 系统弹窗	按钮不在，标题里的应用名在	按钮改不了，应用名可改
系统分享面板 / "打开方式"选择器	系统	面板文字不在，分享内容在	面板改不了，分享内容可改
设置里的"应用信息 / 权限管理"页	系统设置	标题里的应用名在	结构性文字改不了
Toast 轻提示	文字来自应用，样式由系统画	文字在	文字可改，样式改不了
应用自己的确认框 / 公告弹窗	应用自己	在（资源或布局里）	可改
通知的标题与正文	应用提供文字，系统负责画	在	可改
应用上方那条系统提示（如"正在其他应用上层显示"）	系统	不在	改不了

表里有一个容易忽略的细节：同一个弹窗里，不同部分的归属可能不同。 权限弹窗整块是系统画的，但"XX 想要访问您的照片"里的那个 XX 是应用名 —— 它来自你的包。这意味着"改应用名"是你在系统界面上唯一能做的一件事，下一章单独讲。

这些字为什么改不到，机制上其实很直白：系统界面的文字来自系统那一侧的字符串资源。权限弹窗由系统的权限管理模块绘制，安装界面由系统的包安装器绘制，状态栏与"无响应"提示属于系统界面进程 —— 它们的多语言字符串跟系统镜像一起发布，和你的安装包没有引用关系。你的包在里面只是一个"数据源"：系统来查一次你的应用名、图标、包名，然后用自己的词把界面画出来。改你自己的资源表，改不动别人家的资源表，这是两套完全独立的账本。

还有一个近年才出现的变化值得知道：新版本的 Android 把权限管理从一个"焊在系统里"的组件变成了可以独立更新的模块（跟着系统更新走，而不是跟着你的手机出厂版本走）。带来的直接结果是：同一台手机、同一个应用，系统升过一次之后权限弹窗的措辞可能就变了；不同品牌的手机更是不必说。所以当你看到"上个月还是『允许』，这个月变成『仅在使用该应用时允许』"时，那不是应用改了，而是系统那边的词库更新了。

还有一个更隐蔽的混合体：应用自己写的对话框，按钮文字却用了系统框架的"确定 / 取消"。Android 框架提供了一组标准字符串（框架资源里的"确定""取消"等多语言值），有些项目图省事，按钮直接用框架那一份 —— 于是对话框虽然是应用画的，按钮文字却跟着系统语言走、跟着系统版本变，改包改不动。判断方法很简单：在反编译产物的 strings.xml 里搜"确定"这两个字。如果搜不到，而界面上确实有"确定"按钮，那它十有八九来自框架资源或系统。 这类"看得见、搜不到"的字，正是本文后面那套三步判断法要解决的问题。

三、系统界面上唯一能改的一类字：你的应用名

系统界面里凡是需要"点名"的地方，点的都是你包里那个应用名。机制是这样的：清单文件（AndroidManifest.xml）里给应用声明了一个名称（通常是引用资源里的一个字符串），系统要显示应用名时，就按这个声明去查询应用的信息。

智改工坊在导入安装包时做的第一件事，就是用工作目录里自带的 aapt 解析包信息（aapt dump badging），一次把图标、应用名、包名、版本号、最低与目标 SDK、启动页都读出来 —— 其中应用名读的就是那个声明值。所以你会在项目详情页上看到它，改完也能立刻在桌面上对照。

把应用名改掉之后，下面这些地方会一起变：桌面/启动器上的图标名、"设置 → 应用"里的名字、系统权限弹窗与卸载界面里点到的那个名字、通知栏里显示的来源名。这就是"系统界面里唯一能改的一类字"。 三个必须记住的注意点：

1. 可能有多份。 做过国际化的应用，应用名会在多个语言目录里各存一份（默认一份、中文一份、英文一份……）。只改默认那份，中文设备上看到的可能还是旧名字 —— 所以需求里要写清"改哪一份、别的语言要不要动"。
2. 系统侧可能有缓存。 桌面图标名是最典型的缓存场景：应用内已经改了，桌面还是旧名。判断办法很直接 —— 换一个没装过这个应用的设备（或先卸载再装）看是不是新名字：是，就说明改成功了，旧设备只是没刷新。
3. 它不能用来"骗"系统。 改应用名只是改显示，包名、签名、权限声明都不变；系统的安全判断（比如哪些权限归哪个包）看的是包名与签名，不看显示名。这一点在自有应用上做内测命名时很好用，但要清楚它改不了任何规则。

顺带说一个很实用的用法：给内部应用加"内测版"后缀。给自家应用改名成"巡检助手 内测版"，桌面上就能和正式版一眼区分；系统弹窗里点到的也是这个名字，同事在权限设置页里不会点错。而且这个改动很干净 —— 不动包名、不动签名，覆盖安装不影响任何数据。

四、一张文案来源判定表，加一套三步判断法

"这句话能不能改"这个问题，问一百遍不如查一次表。下面这张判定表按"文案出现的位置"归类，给出归属、可改性、以及最快的验证方式。它是排查起点，不是规则书 —— 先按表查，查不出来再用后面的三步法。

你看到的那句文案	最可能归谁	怎么一眼验证
应用某个页面上的标题、按钮、提示	应用（资源 / 布局 / 代码）	在反编译工程里按内容搜得到
应用自己弹的确认框、公告、引导页	应用（布局或资源）	搜得到；按钮若用框架串则搜不到
权限弹窗的按钮与整句说明	系统	切系统语言，措辞跟着变
安装 / 卸载界面上的字	系统	换一台不同品牌的设备，措辞不一样
活动海报、运营横幅上的字	服务端下发 / 图片里	断网再看：变兜底文案或空白
H5 页面里的整段说明	网页（远端，或包内 assets）	断网若能显示，多半就在包内
通知栏里那条通知的标题与正文	应用（资源或代码）	搜得到；渠道名另有缓存机制
画在图片上的字（截图式引导页）	就是图片本身	搜文本搜不到，得换图

表只能覆盖"你猜得到的场景"，真遇到没见过的文案，用下面三步法判断。三步的排序是有讲究的：先做成本最低的，再逐步升级。

三步法还有一个"外挂"：换设备对比。同一句话在自家两台手机上措辞不同、或者在一台手机上跟着系统语言变，基本可以当场判定为系统渲染 —— 尤其是国产 ROM 深度定制的那些提示语。这个方法之所以值得单独记住，是因为它的结论最"硬"：系统文案的词库随厂商和版本走，你的包里不可能有那么多份。

这三步之所以按这个顺序排，是因为每一步的成本和结论强度正好相反：搜包最便宜，但只能证明"在不在包里"，证明不了"为什么不在"；切语言要动一次系统设置，却能把"系统渲染"这一类直接钉死；断网要改一次网络状态，专门用来把"远端下发"从剩下的可能性里摘出去。三步走完，剩下的就只有"图片里的字"和"本地缓存的字"两种，而这两种的判断方法后面会讲。换句话说，它是一个把可能性逐层减半的漏斗，而不是一套需要背下来的规则。

把三步法的结论翻译成需求语言，就是三种完全不同的写法：属于应用侧 —— 正常写"改成什么"；属于系统侧 —— 需求里写清"不要动它"（或者干脆放弃这个改动）；属于远端下发 —— 需求里改不了，要去改服务端的内容，或者让包里的兜底文案说得更清楚。

五、应用内文案的三层落点：定位顺序与搜索技巧

确认了"这句话属于应用侧"之后，接下来是把它定位到具体哪一行。应用内的文字可能住在三个层次上，这套分层不是理论，而是搜索顺序：先看它是不是"引用"，再看它是不是"写死"，最后才去代码里找。

不过在"搜"之前，还有一个前提动作值得说明：包必须先被摊平成一棵能读能搜的目录树。 安装包本质是一个压缩包，里面的资源 XML 早就被编译成紧凑的二进制格式 —— 直接对着包文件搜中文，命中率很低，还有一堆二进制噪声。智改工坊的做法是导入后用工作目录里的 apktool 把整个包反编译到项目目录下的一个固定子目录里：资源表被还原成文本、布局还原成 XML、代码还原成 smali，这样一来"资源 / 布局 / 代码"三层才第一次真正暴露成可以搜索的三个位置。这一步跑在后台线程上，界面不卡；实测 12MB 的包大约 3 秒完成，超过 10 分钟会中断并报错。反编译万一失败也不影响项目本身（配置、图标、原始包副本都已经落地），界面会提示原因并给出日志路径（项目目录下的 apktool.log），打开就能看到卡在哪一步。

三层之外还有两个"藏字的地方"值得知道：一是图片里的字（截图式引导页、banner 上的标语）—— 搜文本永远搜不到，只能换图；二是网页里的字（H5 页面）—— 页面若随包发布，就在包内的网页资源目录里；若从服务端加载，包里只有外壳和兜底。这两类在排查时经常被误判成"工具没改到"，实际是搜的对象选错了。

把"文案清单"做成附件：一次说清，长期复用

文案类改动最容易出现的返工，是"改了三处，漏了一处"。有一招能把这个问题从源头掐掉：把要做的事写成一张对照表，作为附件一起发出去。 在需求输入框旁边点「选择附件」，可以一次挑多个文件，并为每个附件写一句"它是干什么用的"，然后点「立刻修改」。

这张对照表里最好包含四列：原文（现在显示成什么，方便定位）、新文（要改成什么）、位置（哪个页面、什么时候出现）、边界（这处不要动 / 别的语言不要动）。附件的用途说明有个硬要求：不少于 10 个字 —— 这不是为难人，而是因为 AI 只拿到一个文件路径，是不知道拿它干什么的。附件在加入前还会校验文件能不能用（存在、不是目录、不是 0 字节、能读出来），同一个路径重复选择会自动去重。这三条小规矩服务的都是同一件事：不让改包的人拿到一个用不了的输入。

还有一个容易被忽略的分层：需求原文进修改历史，附件说明不进。 也就是说，历史里只留你自己写的那句话，不会塞进一长串附件清单 —— 回看历史时干净，点一下「选择」就能把那条需求填回输入框，照着上次再来一遍。而附件是要重新附加的，所以"长期不变的对照表"建议存在固定位置，用的时候再挂上去。

如果连需求都不知道怎么写，界面上的话术库可以帮忙：内置 6 大分类（界面美化 / 弹窗引流 / 去除限制 / 常规修改 / 混淆去毒 / 插件添加）共 3000 条成型指令，每条都把"要做什么、细节要求、参数参考、范围、验收"写全，点「选择」直接填进输入框，点「复制」复制正文。更有价值的是它可以手改：内容来自程序目录下的 Resources\话术库.xml，改完点一下刷新重新读。团队完全可以把自己家应用的几条规范需求（含"某某按钮来自系统框架，不要去动"这种经验）沉淀成固定话术，谁来做都不会漏。

六、"改了没变"的排查顺序

把三层的定位方法和系统的边界都学会之后，还剩最后一件事：改完看不到变化时，按什么顺序排查。下面这份清单按"从最可能到最不可能"排，前几步在一分钟内就能走完。

1. 先确认装上去的是不是刚打的那个包。 看一眼打包窗口是不是四步都过（回编、对齐、签名、校验），产物就在项目目录的 build 子目录里，依次是未签名、已对齐、已签名三个中间件，全过程写在项目目录的 pack.log 里。如果安装被拒（设备上是签名不同的同名应用、或版本更高），那就根本没换包 —— 设备侧会把原因说出来，签名冲突时按提示先卸载再装。
2. 在工程里搜这句原文。 搜到在资源里 → 看是不是改错了语言变体；搜到在布局里 → 看这一屏是不是引用了另一个布局；搜到在代码里 → 看是不是还有第二处拼接。
3. 三处都搜不到，做两步小实验。 切系统语言：措辞跟着变 = 系统渲染，别改了；断网再看：变兜底 = 服务端下发，去改服务端或改兜底。
4. 改对了、也搜得到，但界面还显示旧的。 这类多半是"系统侧或本地有缓存"：桌面图标名缓存（卸载重装或换台机器看）、应用把文案缓存进了本地数据（清除应用数据后重进）、以及一种特别常见的 —— 有些系统里的配置只认第一次：通知渠道的名称与描述就属于这类，如果这个应用之前已经建过渠道，你改了包里的渠道名，系统里显示的仍是第一次那份，必须卸载重装才能刷新（这一点在讲通知图标的那篇里会展开）。
5. 最后才怀疑"是不是图片里的字"。 引导页、活动页、启动图上的文字如果画在图片上，改文本永远不生效，得换图。换图时要按密度目录成套替换，只改一份会在部分机型上"看着没变"。

上面第五条"缓存类"的现象特别多，单独列一张小表，遇到"应该变了却没变"时可以直接照着对。

现象	原因	怎么处理
应用内的名字变了，桌面图标名还是旧的	桌面启动器缓存了应用名	卸载重装，或换一台没装过的设备确认
改了包里的通知渠道名称，通知设置里还是旧名	渠道配置在系统侧只认第一次创建的那份	卸载重装（或清除应用数据）后再看
改了文案，第一次打开是新的、再打开又变回去	本地数据里存了一份旧文案，启动时被读回覆盖	清除应用数据后重进；自有应用可顺手把"读缓存"的逻辑说清
只有某一台设备上是旧文案	那台设备上装的是上一个包，或系统语言不同	先核对包名与版本号确认装的是哪一版

七、两个自家实例：判定在前，动手在后

下面两个例子都发生在自家应用和内部工具上，重点看"以前怎么做、现在一句话怎么做、改完怎么验证"这三步 —— 以及每一步里"判定文案归属"到底省了多少事。

实例一：内部「巡检打卡」工具的退出登录提示，一段说明加一个按钮。

这个工具的"退出登录"弹窗里有一段说明（"确定要退出当前账号吗？退出后需重新登录"），按钮是"确定 / 取消"。以前的做法是先反编译，然后在资源里搜"退出"这两个字，改完回编、签名、装机 —— 但第一次改完发现按钮还是旧的措辞，再翻一遍才明白：说明在资源里，按钮用的是系统框架那组标准串，改不了，也不该改（这属于系统一致性）。整件事来回折腾了两轮，还差点把框架串当成"包里没搜到所以工具坏了"。

现在一句话就够，而且把边界写进去："把退出登录确认框里的正文改成『退出后需要重新登录，打卡记录已同步到服务器』；对话框上的两个按钮文字来自系统，保持原样，不要改。"点「立刻修改」之后，需求原文带着日期写进项目历史，右侧被吸附的 AI 窗口去找、去改；改完在项目目录留下标志文件，主窗口每 2 秒轮询一次读到就自动弹出打包窗口，四步跑完给出 signed.apk。

改完怎么验证：勾上"打包后自动运行"，程序用 adb 找手机或模拟器，装包并用启动组件拉起（拉起走的是系统命令而不是容易被误判的那种方式，装完还会用系统命令复核一次前台到底是不是它），手机走投屏、模拟器把窗口提到最前。然后在设备上触发一次退出登录：正文是新文案、按钮仍是系统那两个字 —— 两个都对，才说明这次改动既命中了自己能改的部分，也没去碰不该碰的部分。

实例二：自家「记账助手」改应用名，同步改掉系统界面上的显示名。

这个应用要发内测版，要求是"安装后一眼能和正式版区分"。以前的做法是：找到清单里的应用名声明，回资源文件里逐语言改一遍，再重装到测试机上看 —— 麻烦在于每换一台测试机都要重新确认（桌面启动器缓存让旧名字残留），而且经常漏改英文那份，同事的英文系统手机上是旧名。

现在同样一句话，但把范围写死："把应用名改成『记账助手 内测版』，只改中文那一份，其它语言保持原样；包名、签名、版本号都不要动。"需要一次覆盖多台机器时，就再加一句"这是内部测试用，装完会卸载重装，不用考虑数据"。改完自动打包、装机，链路和上面一样。

改完怎么验证：三步对照。 第一步看桌面图标下的名字；第二步进"设置 → 应用"里看这个应用的名字（这里是系统界面，名字来自包里的声明，正好验证"系统界面上唯一能改的那类字"确实生效了）；第三步故意触发一次会让系统弹窗出现的操作（比如申请一个还没给的权限），看弹窗里点到的名字是不是新的。如果桌面上还是旧的、设置里已经是新的，那就是启动器缓存作祟，卸载重装或换台机器就能确认改动本身没问题。

两个例子放在一起看，价值就很清楚了：判定文案归属这件事，花的是三十秒，省的是两轮返工。 知道哪句能改、哪句不该动之后，需求里就多了一条别人容易漏的边界，改完的验收也自然收敛到"该变的变了、不该变的没动"这一个判断上。

八、用户评价：他们是怎么分清这两种字的

以下引述来自内部试用与技术交流群里的使用体验整理，属于体验性反馈（文案性内容，非官方统计口径），供你对照自己的场景参考。

九、结语：先分清"谁的字"，再谈改哪一层

把这篇收成三句话：屏幕上有两种字，一种来自你的包、一种由系统画；系统那部分的唯一例外是应用名；判不清就做三个小实验 —— 搜包、切语言、断网。 确认属于应用侧之后，再用"资源 → 布局 → 代码"的顺序定位到具体那一行，需求里把位置、范围、边界和一个验收锚点写全，文案类改动基本就不会再返工。

这也是安卓修改大师智改工坊希望给你的那种确定性：只需说话，就能让应用变成你想要的样子 —— 你把"哪句话、在哪、改成什么、哪些不要动"说清楚，剩下的事情交给流程：AI 在摊平后的工程里定位和落笔，主窗口等标志文件、跑完回编对齐签名校验四步，再把包装到设备上让你亲眼确认。产品介绍页与下载入口：https://www.apkeditor.cn/ai-version.aspx（官网 www.apkeditor.cn）。