AndroidManifest 最常动的五处：版本号、权限、方向、入口与调试

先说清楚我们在讲什么。安卓修改大师智改工坊是一款 Windows 桌面工具，把"改 APK"这件事压缩成一句话：拖入安装包，用中文写需求，AI 改 smali 与资源，改完自动回编、对齐、签名、校验，最后一键装到手机或模拟器上看效果。它的介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

一个安装包里有成千上万个文件，但真正"面向系统"的只有一份：清单文件 AndroidManifest.xml。系统读它来决定这个应用叫什么、版本是多少、能做什么、从哪个界面开始跑、要哪些能力。也正因为它是"给系统看的那一份"，改它的收益最高 —— 一处改动往往就能改变系统对这个应用的整体态度；风险也最高 —— 改错一处，应用可能直接装不上或者起不来。

反编译之后，这份文件从二进制变成一份可读的 XML 文本，躺在项目的反编译目录里 —— 这既是所有改包工作的入口，也是最容易被改坏的地方。这篇把最常被改动的五处逐个拆开：每一处改的是什么、会影响什么、怎么写才不踩坑，最后再说清工具是在什么时机、以什么方式把改动落进包里的。

一、五处改动，一张总览表

先给一张总览，把"改什么、影响什么、最需要小心什么"摆在一次说完，后面几章再逐处展开：

改哪里	改的是什么	实际影响	最大风险
versionCode / versionName	版本号（整数）与版本文本	能不能覆盖升级、设备认不认它是新版	改小会被拒装；两处只改一处容易混乱
uses-permission	权限声明	功能能不能跑、要不要弹授权	删了会崩、加了不一定拿到
screenOrientation	屏幕方向	界面横竖与旋转行为	代码里另有设置时改了没效果
启动 Activity	入口组件与过滤器	桌面图标、启动路径、自动化脚本	入口没了 = 桌面没图标
debuggable	调试开关	可调试性与数据可见范围	对外包不能带；自家风控可能拦

这五处的共同特征是：它们都不是"界面"，而是"契约"。 界面改错了，用户看得见；契约改错了，系统在最不该出问题的时刻（安装时、启动时）才把问题摊开给你看。所以下面每一章都遵循同一个写法：先讲清这处改动的机制，再讲清最容易踩的坑，最后给一句可以直接写进需求的写法。

为什么"一句话改"这条路走得通？因为清单类改动恰好是最容易被语言描述清楚的一类改动：它不涉及"这个按钮往左挪两个像素"那种需要反复拿捏的审美判断，而是一句"把 A 从 B 改成 C，不要动 D"。这也正是智改工坊的定位所在 —— 拖入安装包，用中文把"改哪一处、改成什么样、边界在哪"说清楚，剩下解析、定位、修改、回编、对齐、签名、校验、装机这一长串动作，交给流水线。对写需求的人来说，需要的不是记住命令，而是知道每一处改动背后会发生什么 —— 这就是本文想补齐的部分。

二、版本号与权限：一处决定"系统认不认它是新版"，一处决定"功能能不能跑"

（一）versionCode 与 versionName：系统只看一个，人只看另一个

这两个字段名字很像，职责完全不同。versionCode 是一个整数，系统用它判断新旧：能不能覆盖安装、算不算降级、桌面要不要认为这个应用变了、以后上架要不要拦你。它是机械判定的，跟"看起来是不是 2.0"没有任何关系。versionName 是一个字符串，给人看的：应用信息里的"2.0 内测版"、关于页里的版本号，都是它。它不参与任何新旧判定。

实际影响里最值得记住的两条：第一，versionCode 改小会被系统拒绝覆盖安装。设备上装的是 v9，你打出来的包是 v6，覆盖安装会直接报"版本降级"，工具这时会自动加一个允许降级的参数再试一次 —— 那是给测试机的便利，不是给发布用的习惯。第二，只改 versionName 不改 versionCode，桌面很可能"没反应"：对系统来说版本号没变，某些桌面就会继续沿用它缓存的图标与名字，于是你看到"改了个寂寞"。

还有一个非常实用的小联动：项目里的版本号是从导入的包里解析出来的，出包时保存的默认文件名会带上"应用名_版本号"这一串。也就是说，只要你每次把版本号写对，产物文件名本身就自带版本标识，不用再靠"哪个是新的"这种问题去问同事。需求写法可以是："把版本号升到 3201，版本名写成『2.0 内测版』。"

版本号的用法上，建议团队尽快形成约定，因为它同时是三件事的锚点：一是升级链路的锚点（每次+1，覆盖安装永远顺理成章）；二是排查时的锚点（设备上出问题，先问"版本号多少"，能立刻把范围缩到某一包）；三是交付时的锚点（产物文件名、修改历史、聊天记录里对同一个版本号，指向同一个包）。可以约定成"主版本 × 10000 + 迭代 × 100 + 构建"这类简单规则，也可以就用一个朴素的自增数 —— 唯一要避免的是"想起来了才改"。至于版本名，它是给人读的，可以放心地承载信息量：'2.0 内测版''3 月联调版'这类写法都在应用信息里看得见，配合版本号一起用，辨识度最高。

（二）uses-permission：声明是"申请"，不是"拿到"

权限这件事，最容易误解的地方在于它有两层：清单里写的是"声明"，运行时要的是"授权"。危险级别的权限从 Android 6.0 起需要在运行时向用户申请，清单声明只是让你"有资格申请"；换句话说，清单里加了权限，不代表应用一定能拿到它，代码里还得走申请流程。

两类翻车方式：删权限——把看起来"用不到"的权限去掉，结果某个埋得深的功能在调用时抛异常、或者静默失败返回空数据。这类问题的坏处是它不报错在你的主流程上，而是报在某个角落，排查成本极高。加权限——同一个能力在不同 Android 版本上是不同的权限名，写错版本、或在低版本设备上加了高版本才有的权限，会出现"这边有效那边没效"的分裂状态。

顺带说清清单里与权限经常一起被提到的另一处：最低支持版本与目标版本。它们不是"权限"，却决定了权限和一大堆系统行为按哪一套规则来执行 —— 同一个权限名、同一个 API，在不同目标版本下的表现可能完全不同。工具在导入包的时候会把这两个版本号解析出来摆在项目信息里，正是因为它属于"描述这个包"的基本事实。这里的建议很直接：把版本号（最低 / 目标）看作"通常不动"的一类字段。 调它是影响面最大的改动之一，除非你很明确自己在解决什么问题，否则不要让它在一次"顺手改改"里被带进去。清单改动的第一原则永远是：先把你要动的那个字段圈出来，剩下的一律不动。

这里有一个"以现场为准"的技巧，比在纸上推演快得多：让应用先跑，把崩溃日志拿到手，再决定加哪条权限。 内部工具里最常见的场景就是"扫码/定位/读文件在真机上失败"，与其凭经验一次加五条，不如先加一条、验证一次、再加第二条 —— 这也是这台工具装到设备上后会自动拉起应用的原因之一：跑一遍就有现场，有现场才有依据。

三、屏幕方向与启动入口：一处管"怎么看"，一处管"怎么进"

（一）screenOrientation：清单一处、代码一处，改哪处要看哪处

屏幕方向由清单里的 android:screenOrientation 属性控制，注意它写在具体的 Activity 上，而不是写在 application 上 —— 只作用于那一个界面。常见取值里，portrait / landscape 是锁死竖屏 / 横屏，sensor 是跟着传感器转，user 是听系统设置。库房盘点这类平板应用锁横屏、展台设备锁竖屏，用的都是这一处。

风险有两个层次的讲究。第一层：方向变化默认会重建 Activity，也就是这个界面会被销毁再创建一次；如果应用没有正确处理状态（表单、播放进度、登录流程），表现就是"转一下屏就回到首页、输入的东西没了"。锁死方向其实也是规避这类问题的一种笨办法 —— 但要知道自己在规避什么。第二层：清单之外还有代码。运行时有一句 API 可以在代码里改方向，它会覆盖清单里的设置；所以"我明明改了清单，怎么还在转"这种情况，多半是代码里另有安排。此类改动最好在需求里点明："如果代码里也设置了方向，一并以清单为准。"

还有一条现实约束值得提前知道：在分屏、多窗口这类形态下，系统的窗口形态优先于应用的固定方向，平板上分屏运行时"锁横屏"可能表现为不锁。这不是改动失效，而是那个形态下系统说了算 —— 排查的时候先看一眼应用是不是被放进了分屏。

（二）启动 Activity：入口一动，一长串东西跟着动

启动入口由 intent-filter 决定：带 MAIN 动作与 LAUNCHER 类别的那个 Activity，就是桌面上点图标之后要跑的那个界面。改动它的方式看起来只是"换个类名、换个过滤器"，实际影响面却很大：桌面图标、系统的启动记录、以及所有"包名 + 组件名"写法的自动化脚本（包括装机后自动拉起的命令）都会跟着变。

三种典型翻车：删掉过滤器或改错类名——装是装上了，但桌面上没有图标，自动化脚本也拉不起来，工具会明确告诉你"设备里找不到这个应用的启动入口"，这句话就是给这种情况准备的；多写了一个 LAUNCHER 过滤器——桌面上出现两个图标，内部功能页被当成了第二个入口露出来；老快捷方式变死链——桌面上的快捷方式是钉在组件名上的，组件改名之后那个钉子就指向了不存在的入口，点了没反应。

顺着"自动化脚本"这条线再多说一句，因为它最容易在多人协作里制造误会：任何按"包名/组件名"拉起应用的脚本、快捷指令、测试用例，都会跟着入口改动而变化。 工具自己的装机链路就是这样一个例子 —— 它把启动入口按三档来查：先看项目配置里记的入口，再问设备（由设备给出这个包的启动组件），最后才退回老办法；所以哪怕你换了入口，它多半也能自己找回正确的那个。但"别人的脚本"未必这么稳健：写死了旧组件名的地方，会在你换入口之后集体失灵。做法上建议：动入口之前先在需求里点明"其它入口保持不动"，改完则用一个最直接的验证 —— 装上去、拉起它、看第一屏是不是你想看到的那一屏。

另外有一条新系统的硬性要求必须知道：带 intent-filter 的组件需要显式声明 exported 属性。对目标 SDK 达到相应版本要求的应用，漏掉这一项会在安装阶段就被系统挡下 —— 属于"装都装不上"级别的错误，而不是运行期的小毛病。这一条的存在也解释了为什么"改入口"这类操作必须一次到位：它牵扯的校验面比看上去宽。

四、调试开关 debuggable：方便与代价写在同一个属性上

清单里的 android:debuggable="true" 打开的是"可调试"这个身份：调试器可以挂上去看运行状态，也可以借这个身份读到应用自己的私有数据。内部联调、现场抓问题的时候，它是实打实的效率工具 —— 尤其是"这个包在客户现场就是不对、在家里就是好的"这类问题，能连上去看一眼，比让人远程描述半小时有用得多。

代价有三条，值得同时摆在桌面上：第一，它削弱了这个包自身的保护边界——调试通道意味着应用内部数据对外部观察者更透明了，所以它绝不能出现在对外分发的包里；第二，一些自家应用会做"自我体检"，其中一类检查就是"我自己是不是可调试的"，内部的调试包被自家风控拦下是很常见的情况 —— 遇到这种"装上了但功能不对劲"，把调试开关关掉再出一版往往就对了；第三，它容易忘记关。所以最稳的用法是把它当成"临时身份"：联调版打开、验证版关掉，并且两款包都保留各自的应用名与版本号，别让它们混在一起。

把调试开关用成"流程"而不是"习惯"，是内测团队最值得做的一件事。具体可以这样落地：联调包和正式包分成两条固定需求存在历史里 —— 一条是"打开调试开关 + 应用名加后缀 + 版本号加一"，一条是"关闭调试开关 + 去掉后缀 + 版本号加一"；每次要出哪一版，把对应那条从历史里点回输入框、按当前迭代改几个字即可。这样做的好处不只是快：它把"有没有忘关调试开关"这个靠人记的问题，变成了"这一版是按哪条需求出的"这个可以查的问题 —— 查一下修改历史就知道答案。对团队协作来说，后者才是可持续的做法。

顺便把容易与它混淆的一个标记说清：清单里还有一种 testOnly 标记，它的含义是"这个包只用于测试"，安装时系统会要求显式允许。这两个标记不是一回事 —— 一个是运行时的调试能力，一个是安装器层面的身份提示。工具对 testOnly 的包会自动换用允许安装测试包的参数再试一次，所以你只要把包交给它装，这两个标记带来的差异基本都不会成为拦路石。

为什么有些改动会让应用起不来

把五处放一起看，"起不来"的原因其实只有三类：

1. 引用了不存在的东西。 清单里写了一个类名，但那个类不存在（或名字差一个字符）—— 安装可能照过，启动时直接崩。资源引用写错也是同一类问题。
2. 清单与代码对不上。 清单里改了组件名或权限，但代码（或其它配置文件）里还有按旧名字写的引用：权限删了、代码还在申请；组件改名、某处还按旧名跳转。系统不会替你检查这种"单方面改约"。
3. 被系统在安装期或启动期直接校验的字段写漏了。 例如带过滤器组件漏了 exported 声明、组件声明不完整 —— 这类错误在安装阶段就会被系统拒绝；工具会把安装失败的原因翻译成人话递给你，省得你去猜那一串英文报错。

把三类原因和对应的排查动作列成一张表，下次遇到"起不来"可以照着走：

表现	常见原因	先做什么
装到一半被拒绝，提示安装失败	清单字段写漏 / 组件声明不完整	看装机环节翻成人话的失败原因，回到改动处补齐
装上了，点开就闪退	引用了不存在的类 / 资源	对照本轮改动，把"新引用的名字"逐个核对
桌面上没有图标，或点了没反应	启动入口被改没 / 快捷方式指向旧组件	让工具拉起一次，看它报的启动入口问题
某个功能静默失效	权限被删 / 声明与代码不一致	先跑出失败现场，以报错为准补齐声明

对应到做法上就是两条纪律：一次只改一处，改完立刻验证（工具装到设备上会拉起应用，跑一遍就有结论）；永远留一条退路 —— 项目目录里始终留着导入时的原始包副本，导进来之后也没动过，任何一轮改坏了，用它可以一比一复原；每一轮改动的需求原文也按顺序记在修改历史里，想退回上一版状态，把上一条需求点回来重改即可。

五、工具在包结构里落笔的时机：从一句话到成包

讲完"改什么"，再讲"怎么落笔"。智改工坊的定位是"一句话改"，翻译成流程其实是四段：需求送出去 → AI 在反编译目录里改 → 标志文件回来 → 主窗口打包。每一段都有它存在的理由。

第一段：发出去的不是你写的那一句，而是三段拼起来的

点「立刻修改」之后，真正发出去的文本是：你的需求原文 + 附件说明 + 一段固定的环境说明。附件说明的格式是"序号. 文件路径 —— 用途说明"，每个附件都必须写不少于 10 个字的用途（文件本身也要过一遍校验：存在、不是目录、不是 0 字节、读得出来），因为"这个文件是干什么的"不能靠 AI 猜。固定的环境说明是给 AI 的操作约定：切到项目工作目录下面去改、改完在项目目录里留一个标志文件、不需要在右侧那个应用里打包。而写进修改历史的只有你的需求原话 —— 附件说明和那段操作约定都不进历史，这样回看历史时不会被一堆固定文本刷屏。

第二段：AI 改完怎么通知主窗口 —— 用一个文件当信号

AI 那边是一个聊天窗口，它没有"回调"这个概念，也没法主动通知主窗口。所以两边约定了一个最朴素的信号：改完之后在项目工作目录里生成一个标志文件。主窗口每 2 秒读一次这个文件，读到就认为改完了，并且立刻把它删掉（免得下一次误判），然后把打包窗口弹出来。为了让"这一次"的信号一定是这一次的，开始等待之前会先清一次同名残留文件；等待上限设为一小时，到点就不再挂着"等待中"的状态。用文件当信号的好处是各方成本都为零：AI 只要写一个空文件，主窗口只要看一眼 —— 出错也不会把谁卡住。

第三段：打包之前，先往包里写一枚"打包标记"

在回编开始之前，工具会先往反编译目录的 res/values/styles.xml 里写一个名为 info 的样式，内容是"谁在哪台机器上打的这个包"的编码串（时间、登录账号、机器码、机器名、系统用户名、程序版本，加上应用名与包名）。写入策略是三种情况分别处理：文件不存在就先造一个空壳；文件里没有这个样式就插在结束标记之前；已经有了就把原先那一块整体替换掉（这样重复打包时，标记里的时间也是新的）。写回时还会保持文件原有的编码标记，不给 apktool 添乱。

为什么写在回编之前？因为它必须被"编进包里"才成立 —— 反编译目录是原料，回编是把原料组装成成品；标记要在原料阶段放进去，才能成为成品的一部分。这一点也顺带回答了另一个问题：为什么这个操作放在自动打包流程里，而不是等你手动点？因为它属于"出包的固定仪式"，包出去之前必须有，晚一步就没有意义。

更值得说的是它在失败时的态度：标记写不进去，只记一行日志，绝不拦打包。 这里的取舍很明确 —— 在一条自动化的出包管线里，"包能出来"永远优先于"标记齐全"。宁可打出一个少了标记的包，也不能让整个包因为一个附加动作而打不出来；日志里会写清是跳过了还是失败了、以及原因，事后要追查也有线索。这种"附加动作不阻断主流程"的设计思路，值得出现在你每一个自动化脚本里。

顺带的技巧：话术库与历史，是把"经验"固化成"资产"的两个抽屉

工具里有两个很容易被低估的功能，恰好都在服务"清单类改动"这种需要精确措辞的场景。第一个是话术库：内置三千条成型指令，分成界面美化、弹窗引流、常规修改、混淆去毒、插件添加等六大分类，每一条都把"要做什么 / 细节要求 / 参数参考 / 范围 / 验收"写全了。它的价值不是替你省几个字，而是示范了"一段能被准确执行的改包需求应该长什么样" —— 新手照着自己改两遍，就知道哪些话必须说、哪些边界必须划。话术库的内容来自程序目录下的一份 XML 文件，可以自己手改，改完点刷新重新读取，团队完全可以把它维护成"自家需求模板库"。第二个是修改历史：每一轮的需求原文完整保留、最新在最上，右侧点一下就能把那条需求填回输入框。对"改完发现不对、想退回上一版再改一次"这类场景，这是最省事的路径；对"这一版当时到底改了什么"这类追溯问题，它就是唯一可信的答案。

第四段：回编，然后才是对齐、签名、校验

标记写好之后，回编把整个反编译目录重新打包成未签名的成品，接着是对齐、签名、校验三步。这四步的每一步在解决什么问题、为什么顺序不能调换，本文不展开 —— 值得单独一篇（签名那一套机制本身就够讲一万字）。这里只留一句判断标准：每一步都有它的产出与日志，出了事顺着日志看是哪一步卡住，比对着屏幕猜要快得多。

六、两个自家改包实例

实例一：自家「库房盘点」平板端 —— 锁横屏 + 打开调试开关做联调包。

以前的做法：先用 apktool 反编译，在清单里从十几个 Activity 中找到主界面那个，给它加上固定横屏的属性；为了让现场同事能连着抓日志，还要把调试开关打开；然后回编、手动对齐、手动签名、adb 装到平板上，拿起来转两圈看方向到底锁住没有。最烦的是"调试开关有没有忘关"这件事 —— 联调包一旦流出去，等于把后门一起发出去了，只能靠人肉记忆和多问一句。

现在一句话："把主界面固定在横屏，打开调试开关，应用名改成『库房盘点 联调版』，版本号加一。"工具改完自动打包，勾选"打包后自动运行"就会把包推到平板上并拉起应用；装完还会用系统命令复核一眼前台应用是不是它。验证动作只有两个：把平板转一下，界面不跟着转就是锁住了；看应用信息里的版本号，就能确认平板上装的是这一版而不是上一版。联调结束后再出一版"关掉调试开关、版本号再加一"的正式包，两个包在历史里各占一条，谁什么时候出的、出的哪一版，都查得到。

实例二：内部「门店点单」手机端 —— 补权限与动启动入口。

以前出过两次事故。一次是扫码功能在门店的手持机上一直失败，排查要先装包、再连日志、翻半天才确定是漏了一条权限声明；另一次更离谱：为了让测试同事直达某个页面，把启动入口的过滤器改了一下，结果装完之后桌面上没有图标，整个小组找了两个小时才发现是入口被改没了 —— 而在那两小时里，所有人的第一反应都是"是不是没装上"，而不是"是不是装上了但进不去"。

现在这两件事都变成一句话："补上扫码功能需要的那条权限声明，只加这一条"和"把启动入口换成测试页，其他入口保持不动"。改完自动打包、自动装机、自动拉起；如果入口真的出了问题，工具在拉起环节会给出明确的失败原因（"找不到这个应用的启动入口"），直接把你从"怀疑没装上"引导到正确的方向上。验证：扫码跑一遍，看功能是否恢复；入口改动则看桌面上图标的数量与点开之后的第一屏。

这两个例子里还有一处细节值得单独指出：它们都不是"改一处就完事"的动作，而是"改一处、走一遍链路、看一个结果"的闭环。 锁横屏要看设备转不转；补权限要跑一次真实功能；换入口要看桌面与首屏。每一步的观察成本都不高，但前提是"链路的另外半截"已经跑通了 —— 包要能出得来、装得进、拉得起。把这三件事交给自动化，你的注意力才能全部放在"我改的那一处到底对不对"上，而不是耗在"包怎么又装不上"上。清单类改动之所以值得写成一篇文章，就是因为它把"想法"和"结果"之间的距离压得很短，而短距离的验证，才让人愿意一次只改一处。

两个实例的共同点是：真正花时间的从来不是"改"，而是"确认改对了没有"。 清单类改动尤其如此 —— 它不像换个图标那样一眼可见，验证必须走完整条链路：装上去、拉起来、看一眼真实行为。工具把这三次确认做成了打包之后的固定动作，剩下的判断（横屏锁没锁住、权限生效没生效、入口对不对）都是你一眼就能给出的。

七、用户评价：他们都在清单上动过哪一笔

八、结语：五处改动，一条纪律

把这篇收成一句话：清单里的五处改动，本质都是在和系统重新签一份契约；契约型改动的纪律，就是"一次只改一处、改完立刻验证、永远留一条退路"。 版本号给系统看，权限给运行时要，方向给手上看，入口给所有人看，调试开关给未来的自己看 —— 每一处都值得你在写下需求之前多想十秒钟。

于是你打开安卓修改大师智改工坊时看到的，就是那句口号描述的样子：只需说话，就能让应用变成你想要的样子 —— 拖入安装包，把"改哪一处、改到什么程度、怎么验证"写成一句话，改完自动回编、对齐、签名、校验，再自动装到设备上拉起来给你看。清单这种看不见的文件，从此也可以"说着改"。

产品介绍页与下载入口：https://www.apkeditor.cn/ai-version.aspx（官网 www.apkeditor.cn）。