这里是安卓修改大师智改工坊。本文只讲一件事：自有应用里的权限与采集项，怎么减。你可以先打开 https://www.apkeditor.cn/ai-version.aspx 看看智能修改电脑版的产品形态，再回到这篇文章。文中所有改动都只针对自有版权或已获授权的应用，也请勿用于破解他人付费应用、去除授权校验或绕过安全机制。

被点名的从来不是「功能不够」，而是「东西太多」

青柚是一个十二人的小团队，做两件事：一款面向用户的记账应用「青柚记账」，和一个给门店巡检员用的内部工具「青柚巡检助手」。两款应用都是自家开发、自有版权，代码在团队自己手里。按理说，这样的团队做合规改造应该最轻松——想改什么就能改什么。但今年第三季度的自查，这件事还是卡住了两周。

卡住的地方很具体。一份第三方检测报告列出了几条问题：应用申请了通讯录读写、精确定位、读取手机状态等权限，而产品说明书里只写了记账、报表、备份、多设备同步；首次启动时连续弹出三个弹窗，隐私政策、活动推荐和版本更新提示叠在一起；在部分机型的日志里，能看到设备标识和订单字段。报告没有直接写「不合规」，它写的是「申请范围与业务功能不匹配」。这句话翻译成产品语言就是：你申请了不需要的东西。

产品负责人苏禾的第一反应是找法务。法务的回复很直接：把不用的权限删掉。可「不用的权限」到底是哪几个，谁也说不清。她转头找开发周航，周航说：「删声明我能删，但删完会不会崩，得把代码逐个查一遍。」于是这件事被拆成了两份工作：法务不知道哪一行是权限，开发不知道哪一条是合规要求。两周过去，报告还压在待办里。

后来他们换了个角度：不去争论「合规该怎么定义」，而是把它当成一次改包任务——目标是把多余的权限与采集项减下去，边界是不动核心功能，验收是真机上权限列表变短、主流程照常跑。这么一换，事情立刻变得可执行：哪些要减、减到什么程度、怎么算减对了，都能写成一段话，交给改包流程去落地。

这里先把一个判断标准立起来：一条权限该不该留，不看它「有没有用」，而看它「在当前的业务功能里有没有对应」。用户点开应用的第一分钟看不到的功能，就没有理由在安装时要求权限。按这个标准把青柚记账过一遍，问题清单很快成形。

表格里最后一列，才是这份清单真正的价值：它把「删什么」变成了「删哪些、留哪些」。很多人做合规改造会掉进一个坑——以为目标是权限越少越好，于是把相机、麦克风也一起删了。结果扫码登录失效、语音记账报错，用户在应用商店里给了一星。合规不是把应用削成空壳，而是在「功能需要」和「用户预期」之间找到那条线。

为什么这件事过去总是卡住？因为法务和开发看的是两张不同的图。法务看到的是「报告里第几条被点名了」，这是一条文字结论；开发看到的是「这个包里有几千个文件和几万行代码」，这是一片没有标注的地图。中间缺的是一层翻译：把「申请范围与业务功能不匹配」翻译成「删除这几条声明、确认这几个调用点、保留这几处逻辑」。翻译做完，两份工作就合成了一份；翻译不做，就永远停在「你去改」和「我不知道改哪」之间。

还有一个容易被忽略的视角：权限列表是用户唯一能直接看到的隐私说明。产品说明书写得再好，用户在安装页和设置页看到的那一列权限，才是他真正的判断依据。少一条用不上的权限，比多写一页隐私政策更有说服力。这也是为什么「减权限」这件事，值得产品、开发、法务坐到同一张桌子前——只是过去，他们缺一个能同时说清「哪一条」和「怎么改」的东西。

权限长在三处：清单声明、动态申请、SDK 自带

要减权限，先得知道权限在哪。很多人以为权限就是清单文件里的几行声明，删掉就完事。实际上，同一个权限可能同时存在于三个地方，而这三处的处理方式完全不同。

第一处是清单里的静态声明。在反编译出来的工程里，它通常出现在 AndroidManifest 中，形式是一行声明语句，写明这个应用需要某项系统能力。这一行决定应用「声称需要什么」，它会直接出现在系统设置的应用权限列表里，也会出现在应用商店的权限展示中。用户在安装页看到的「读取联系人」，就是这一行造成的。声明了却不用，用户看到的就是一条多余的解释成本。

第二处是运行时的动态申请。从 Android 6 开始，危险权限必须在运行时向用户申请，代码里通常表现为一次申请调用，可能写在启动页，也可能写在某个功能页的入口。这里有一个非常容易踩的坑：删掉声明、留着申请，用户点了「允许」也没用，申请会失败甚至抛异常；反过来，删掉申请代码、留着声明，权限列表里依然会有这一条，合规检查照样点名。所以声明和申请必须一起处理，谁也不能单飞。

第三处是第三方 SDK 自带的权限。SDK 的清单文件会在打包时被合并进最终清单，这个过程是自动的，不需要你写任何东西。结果就是：你在自己的清单里搜不到它，装机后权限列表里却出现了它。常见来源是广告、统计、推送、地图、分享这几类 SDK。处理这类权限有两条路：如果业务根本不需要这个 SDK，直接停用，权限和采集项一起消失；如果 SDK 必须保留，就要在合并规则里显式移除，但要清楚这可能影响 SDK 的部分功能，必须实测。

把三处放在一起看，就能理解为什么「只删声明」经常出事。声明是应用对系统的承诺，申请是代码对用户的动作，SDK 是别人替你做的承诺。三者里少处理任何一处，要么崩，要么白改。正确的顺序是：先在工程里定位，再判断代码里是否真的在用，最后才动手删。

在反编译工程里定位权限，有三个搜索方向。第一，搜权限的短名，例如联系人、定位相关的常量名，短名比全名更容易命中，因为代码里常以常量形式出现；第二，搜申请相关的方法调用，把申请点和权限名对上；第三，搜 SDK 的初始化位置，通常在应用的启动入口里，找到初始化就意味着找到了采集项的入口。这三个方向搜完，你手里就有一张「权限—代码—SDK」的对应表。这张表比任何一份合规报告都好用，因为它直接告诉你改哪一行。

采集项与「噪音」：日志、Toast、弹窗、埋点、广告 SDK

权限之外，合规报告里出现频率同样高的是「采集项」和「噪音」。这两类东西有个共同点：它们不影响功能，却影响观感、影响审核、影响用户信任。而且它们比权限更难发现，因为它们不会出现在安装页上。

调试日志是最常见的一类。开发期为了排查问题，代码里会打印请求参数、返回值、用户标识、订单号，上线时忘了关。从合规角度看，日志可能被系统日志缓冲区记录，也可能被第三方工具读取，敏感字段暴露的风险实实在在。技术做法不难：找到打印语句，删掉或者改成只输出非敏感信息。但这里有条纪律——只删输出，不删逻辑。有的打印语句旁边就是错误捕获和重试逻辑，一删就删掉了容错。

Toast 提示是第二类。它的典型特征是「开发觉得有用、用户觉得多余」：接口返回正常、数据加载完成、保存成功、请稍后重试。有些是调试遗留，有些是早期版本的交互习惯。处理方式是把调用点找出来，删掉或者合并成一条必要的提示。要注意保留真正有价值的失败提示，比如「网络不可用，请检查连接」，删掉它反而让用户更迷茫。

弹窗是第三类，也是最容易被用户记住的一类。首启时隐私政策弹窗、活动推荐弹窗、版本更新提示、评分邀请叠在一起，用户点掉四个弹窗才能看到首页。这里要区分「必要」和「多余」：隐私政策弹窗是必要的，而且必须在收集信息之前出现；活动推荐和评分邀请属于运营诉求，可以延后到用户完成一次核心操作之后；版本更新提示如果不是强制更新，也可以改成静默检查。减弹窗不等于减掉必要告知，这条线要划清。

埋点上报是第四类，也是争议最大的一类。早期埋点往往上报设备标识、位置、页面路径、停留时长，字段多、频率高，而业务侧早就不用这些数据了。处理方式不是「全删」，而是「收敛」：保留自己真正需要的统计口径，把与业务无关的字段去掉，把频率降下来。全删会让产品失去数据支撑，全留又说不清必要性。

第五类是广告 SDK。如果一款自有应用根本不靠广告变现，那么广告 SDK 带来的权限、采集项和后台进程就是纯粹的成本。把它整体去掉，权限列表会立刻变短，启动速度也可能变好。判断方法很直接：看这个 SDK 有没有出现在变现路径上，没有就删。

话术库在这里派上用场。智能修改电脑版的详情页内置了三千条话术，分六类，每类五百条，包括界面美化、弹窗引流、去除限制、常规修改、混淆去毒、插件添加。其中「常规修改」这一类里，就有去日志、去 Toast、去弹窗、去权限、SDK 版本这些成型指令。点选一条，它会填进输入框，你再按自己的包名、类名、字段名把具体值补上。要提醒的是：话术是模板，不是结论。点选之后如果不补齐定位，改动只能按通用理解去走，结果往往不是你要的。

处理噪音还有一个判断顺序，值得记一下：先处理「输出」，再处理「触发」，最后处理「上报」。输出指的是日志和 Toast，删掉它们不影响业务逻辑，风险最低；触发指的是弹窗的弹出时机，改它要连带想清楚「用户此刻在做什么」，风险中等；上报指的是埋点和 SDK，动它可能影响数据看板和第三方功能，风险最高，必须先和业务方确认。按这个顺序做，一次改造可以分阶段验收，不必把风险堆在一起。

把这张表贴在需求旁边，写需求的时候就不会漏项。青柚团队后来把「噪音」这一栏单独做成了一个检查项，每次出包前对照一遍：这次有没有新增日志、有没有新增弹窗、有没有新引入的 SDK。合规改造最怕的不是改得少，而是改了又加回去。

一句话需求怎么写才算有效：定位、结果、边界、验收

需求写得清不清楚，直接决定改包是一次成还是来回三趟。一句「把权限删一下」是没法执行的：不知道删哪个，不知道代码里有没有在用，也不知道删完怎么算对。有效的需求，至少要包含四样东西。

第一样是定位：改哪里。写清权限的中文名加常量短名，写清它出现的位置（首启、首页、我的页面），写清相关的类名或页面名。定位越具体，返工越少。如果只知道中文名，也可以写「与通讯录相关的全部权限」，但要接受范围会略宽。

第二样是结果：要什么效果。用可观察的方式描述，比如「权限列表里不再出现通讯录与精确定位」「首启只保留一次隐私政策弹窗」「正式包的日志里不再出现订单号」。避免「优化一下」「清理干净」这类没有验收标准的说法。

第三样是边界：别动什么。这是最容易被漏掉、也最重要的一条。核心功能、包名、签名、数据库结构、登录态、支付链路，都要明确写进「不要动」。边界写得越清楚，改动的风险越小；很多人担心改包会改坏东西，其实大部分「改坏了」都源于需求里没写边界。

第四样是验收：怎么算对。写成可执行的检查项，比如「真机安装后权限列表只剩六项」「主流程走一遍无崩溃」「日志里没有异常堆栈」「覆盖安装不报降级」。验收标准是给未来的自己看的：三天后回来核对，不用回忆当时想的是什么。

下面这段是青柚记账实际用过的需求原文，可以直接照着改：

这是自有版权的青柚记账，本次只做权限与采集项收敛，不改功能：

一、删除通讯录读写权限的声明，并确认代码里没有残留调用；若有调用，一并移除或改为不依赖该权限的实现。

二、精确定位权限来自已停用的广告 SDK，停用该 SDK 后一并移除相关权限与初始化调用。

三、删除读取手机状态的权限声明及其调用点，设备标识逻辑改为使用不依赖该权限的方式。

四、正式包去掉调试日志里的订单号与设备标识字段，保留错误捕获与重试逻辑。

五、首启只保留一次隐私政策弹窗，去掉活动推荐弹窗，版本更新提示改为非强制时静默检查。

边界：不改包名、不换签名、不动数据库结构与登录态；记账、报表、备份恢复、扫码登录必须可用。

验收：真机权限列表从十一项减到六项；主流程走一遍无崩溃；日志中不再出现订单号；覆盖安装不报降级。

这份需求之所以有效，是因为它把「法务的要求」翻译成了「工程的动作」：删除哪些声明、确认哪些调用、保留哪些逻辑、改完怎么验。右侧的 AI 工作区拿到的不是一句口号，而是一张带边界和验收标准的工单。

附件也是需求的一部分。智能修改电脑版支持一次多选文件，但每个文件都要写用途，而且不少于十个字；系统会检查文件是否存在、是不是目录、是不是零字节、能不能读。别嫌这条规则啰嗦——它逼着写需求的人把「这张表给谁看、对应哪一处」说清楚。文件会按序号加路径加说明拼进需求里一起发出，而历史记录里只保留用户的原话。也就是说，需求原话给你留档，附件说明给执行用，两者分工明确。

需求写完点「立刻修改」，原文和日期会写进项目的历史记录，需求送进右侧的 AI 工作区开始执行。AI 完成后会在项目目录留一个完成标记，主窗口每两秒轮询一次，读到就处理；等待上限是一小时，超时会按超时处理并留下日志。这条时间约束在合规改造里很有用：它让「改不完」变成一件能被看见的事，而不是无限期挂着。

改包链路：从拖入安装包到装机验证

合规改造在智能修改电脑版里的链路是固定的，一共八步，每一步都有产物可查。把这八步记住，比记住任何一条具体指令都管用。

1. 拖入安装包：支持 APK、JAR、APKS、XAPK、APKM、CLASS 等格式。导入时用 aapt 解析图标、应用名、包名、版本、SDK 和启动页，先让你确认拿到的是不是正确的包。
2. 建立项目：每个项目一个八位随机目录，里面写配置文件与历史记录，并复制一份原始安装包。这份原始包，是后面所有回退的底气。
3. 写需求：在详情页输入，可以从话术库点选；有附件就加上，每份写清用途，不少于十个字。
4. 点「立刻修改」：需求原文和日期写进历史记录，需求送进右侧 AI 工作区执行。
5. AI 改反编译工程：反编译产物在 apktool 目录，日志是 apktool.log。实测十二兆左右的包约三秒完成反编译；如果超过十分钟还没结束，会中断并报错，避免无限等待。
6. 自动回编、对齐、签名、复核：这四步是固定的，全部写进打包日志。
7. 装机验证：adb 找设备、装包、拉起主界面，再用系统命令复核前台应用；连着手机时可以用 scrcpy 投屏到电脑上看效果。
8. 留档：项目目录、日志、需求原文、签名复核输出一起归档，下次改造可以直接复用需求结构。

这条链路对合规改造特别重要，因为它把「改了什么」和「怎么装进去」分成了两段。前半段是反编译工程里的编辑，随时可以看、可以比对；后半段是回编、对齐、签名、复核，一步不落。过去手工做这两段时，最怕的是「改了但没打进去」——比如改了资源却回编失败，人以为成功了，实际产物还是旧的。链路固定之后，每一步都有日志和产物，改了没改、打进没打进，看一眼就知道。

八步里最容易被忽略的是第二步和第八步。第二步决定了你能不能回退：原始安装包一直在项目目录里，改坏了重新建一个项目或者用原包再来一次就行，不需要到处找旧版本安装文件。第八步决定了这件事能不能沉淀：一次合规改造的需求写清楚了，下一次换个应用、换几条权限，改改具体值就能用，不必从零想一遍。

还有几个细节值得记住。项目目录里的历史记录是「最新在上」的完整原文，右侧有「选择」按钮可以回填到输入框；项目列表里可以查看历史、删除项目，但只允许删项目目录的直接子目录，避免误删。工作目录会自动挑盘，顺序是 D、E、F、G、C，取第一个可读写且剩余不少于 1GB 的盘，下面分工具链与项目两个子目录。做合规改造前，建议在设置页点一次工具链体检，确认反编译、对齐、签名要用的组件都在。

装机预览这一环，在合规改造里有额外价值。权限相关的问题往往要装到真机才看得出来：权限列表有没有变短、弹窗出现几次、日志还打不打印敏感字段。智能修改电脑版在打包后会自动找设备、装包、拉起主界面，组件名的查找有三档：先读项目配置里的启动页，找不到就用系统的组件解析命令，再不行走旧方式兜底。拉起之后还会复核前台应用，确认真的进入了目标应用，而不是停在桌面。手机连着的时候可以投屏到电脑，模拟器会被提到最前，方便截图留档。

打包四步与 pack.log：回编、对齐、签名、复核

打包是四步，顺序不能换，少一步都不算完成。很多人把注意力全放在「改了什么」上，忽略了「怎么把改过的东西装进一个能安装的包」，结果改动本身是对的，包却装不上。

1. 回编：用 apktool 把改过的代码和资源重新组装成未签名的包。失败时先看反编译日志，多半是资源名冲突、图片格式不支持或者 XML 语法问题。
2. 对齐：用 zipalign 做四字节对齐，让包内未压缩的数据按边界排布，减少安装后的内存开销。对齐失败通常是输入包本身有问题，回到上一步看日志。
3. 签名：用 apksigner 签名。签名方式有四种可选：默认签名、JKS 或 keystore、PEM 加 PK8、随机签名；签名版本支持 v1、v2、v3、v4，默认是 v1、v2、v3 一起签。口令通过环境变量传入，不拼进命令行，也不写进日志。
4. 复核：用 apksigner 的 verify 确认证书主题、摘要和签名版本。这一步是很多人的盲区：密钥格式不对、口令不对、签名版本缺失，往往只有复核阶段会明确报出来，签名阶段看着是成功的。

为什么合规改造也要关心签名？因为覆盖安装必须用同一套签名。自家应用正式版用的是公司证书，你的改造包就必须用同一套，否则测试机上覆盖安装会失败，用户端更不可能平滑升级。默认签名适合内部测试，省事，但不能用来覆盖已经用公司证书签过的正式包；JKS 适合企业自有应用，能保证后续升级；PEM 加 PK8 适合手里只有密钥对的场景；随机签名适合一次性试验，不适合需要升级的包。

打包全过程会写进打包日志。另外还有几个日志各管一段：反编译日志记录工程还原的输出，异常日志记录未处理的错误，窗口日志记录界面吸附和布局。合规改造时最常翻的是反编译日志和打包日志：前者告诉你改动落到了哪个文件，后者告诉你四步里哪一步出了问题。养成「先看日志再重试」的习惯，比连点五次执行有用得多。

复核这一步报出来的问题，通常集中在三类。第一类是密钥格式与口令：证书文件格式和签名方式不匹配，或者口令传递的方式不对，签名阶段不报错，复核阶段直接给出证书读取失败。第二类是签名版本缺失：目标设备里有较老的系统，但包里只有较新的签名方案，装上去就提示解析失败；这也是为什么默认把三个版本一起签，省掉很多兼容性排查。第三类是证书主题不符：包签上了，但签的不是你以为的那张证书，覆盖安装时系统会判定签名不一致。三类问题有一个共同点——它们都不会在「看起来成功」的时候暴露，只有主动复核才能发现。

最后是回退。原始安装包从建项目那一刻起就一直保留，日志也都在项目目录里。改坏了的处理方式不是「在新包上继续改」，而是回到原包重新来一次——因为连续修补最容易把问题叠在一起，而合规改造的验收标准恰恰要求「主流程不受影响」，叠了问题就说不清了。青柚团队吃过一次亏：连续三次在同一个项目上打补丁，最后分不清哪个改动是有效的，只能全部推倒重来。

验证清单：装真机、跑主流程、看权限列表、抓日志、覆盖安装

改完不等于改对。合规改造的验证有五项，缺一项都不算完成。这五项的顺序也有讲究：从「能不能装」到「用起来对不对」，再到「痕迹有没有留下」，最后回到「升级这条路通不通」。

开始之前，建议先把这五件事准备好，后面每一步都会省事：

• 改前的权限清单截图，作为对照的基准；
• 必须可用的功能清单，写清哪些路径一定要走通；
• 一台新系统真机和一台旧系统真机，都登录好测试账号；
• 公司签名文件与版本号口径，确认覆盖安装不会失败；
• 一份写清定位、结果、边界、验收的需求原文。

第一项，装到真机。模拟器不能完全代替真机：权限列表的展示、弹窗的出现时机、SDK 的行为，在真机上更接近用户的真实情况。至少准备两台机器，一台新系统、一台旧系统，因为权限模型在不同版本上差异不小。安装要分两种：干净安装看首次体验，覆盖安装看升级路径。

第二项，跑一遍主流程。不要只看首页能不能打开。按自家应用的核心路径走一遍：打开应用、登录、进核心功能、完成一次真实操作、查看结果、退出再进。合规改造最容易伤到的地方，恰恰是被删掉权限牵连到的分支，比如扫码、导出、备份，这些都要手动点一遍。

第三项，看权限列表是否减少。位置在设置里的应用信息页。拿改前的清单逐项对照：该消失的消失了没有，该保留的还在不在。这里有个常见误判：如果旧版本已经装过并被用户授过权，覆盖安装后系统对权限列表的刷新可能不是即时的。所以看到不一致时，先卸载重装再看一次，不要急着下结论。

第四项，抓日志确认没有异常报错。过滤应用包名，再按错误级别筛一遍，重点看启动阶段和主流程阶段。同时确认一件事：改造前会打印的敏感字段，现在真的不打印了。这一步最好用改前的日志做对照，否则你很难判断「没有报错」是真的干净，还是日志级别设错了。

第五项，覆盖安装再验一次。覆盖安装要满足三个条件：版本号递增、签名一致、数据保留。装完之后回到权限页再看一眼。第五项之所以单独列出来，是因为它模拟的是真实用户的升级路径——你发出去的不是一个全新的包，而是要让已经装了旧版本的人平滑升上来。

这五项里，第一项和第五项最容易被省掉。团队常在开发机上装一次就认为验完了，结果发到用户那里出现覆盖安装失败、数据丢失、权限状态混乱。合规改造的验收不是「我这边没问题」，而是「用户那边不会出问题」。这两者的差别，就在多装的那一次、多跑的那一遍。

实例一：自家记账应用的权限收敛

以前怎么做。周航在开发工具里打开清单文件，按报告逐条搜权限，删了三行，装到测试机上发现「邀请好友」页面白屏——因为通讯录相关的调用还在代码里，权限被删后调用直接失败。他只能改回来。接着发现广告 SDK 带来的定位权限在自己的清单里根本搜不到，查了一圈才明白 SDK 的清单会在打包时被合并进来；最后是整体停用了那个 SDK，权限才消失。整个过程两天，打了六七个包，测试机来回卸载重装。改动记录散在聊天记录里，下次要改同一处，还得从头查一遍。

现在怎么做。把安装包拖进智能修改电脑版，导入时解析出包名、版本、SDK 和启动页，确认无误后建好项目；然后在详情页写下前面那段需求，加两个附件——一份权限对照表，写清哪些删、哪些留；一份主流程清单，写清必须可用的功能。每份附件的用途都写足了十个字以上。点「立刻修改」之后，需求进入右侧工作区，改动落到反编译工程里；完成后自动回编、对齐、签名、复核，再装到测试机上。整个过程里，周航没有打开过一次开发工具，但他能说出每一处改动落在哪个文件，因为需求里把位置写清楚了。

改完怎么验证。第一，权限列表逐项对照，从十一项减到六项；第二，主流程走一遍，记账、报表、备份恢复、扫码登录全部可用；第三，抓日志，确认订单号与设备标识不再打印，同时没有新增异常；第四，覆盖安装一次，版本号递增、数据保留、权限状态符合预期。

这次改造还留下一个副产品：那份权限对照表。表里写清了每一项权限的去留理由，法务拿着它可以直接解释，开发拿着它可以直接改，产品拿着它可以判断下次新增功能时要不要申请新权限。过去这类表格要靠人工整理，现在它成了需求的一部分——因为写需求的时候就必须把「哪些删、哪些留、为什么」说清楚。

周航后来说了一句挺实在的话：以前做合规改造，最怕的是「删了之后不知道什么时候会崩」；现在最坏的情况也就是崩在测试机上，因为原始包还在，重来一次就行。可控，才是他愿意做这件事的前提。

实例二：内部巡检工具的噪音清理

第二个例子是内部工具，场景更典型。青柚巡检助手是给门店巡检员用的应用，装在自家员工手机上，功能不复杂：扫码、拍照、填表、上传。它的权限问题不严重，但「噪音」很多。

以前怎么做。这款工具一直是外包维护的。每次提需求都要先写邮件，再等对方排期，改一版大概三天。需求本身也很零碎：「把日志关掉」「提示太多了减一点」「更新弹窗别每次都弹」。外包改完之后，打包和签名还要自己来，签名一直用的是默认签名，结果员工手机上覆盖安装经常失败，每次升级都要先卸载，本地没上传的巡检草稿就丢了。巡检员抱怨最多的不是功能，而是「又要重装」。

现在怎么做。把安装包拖进智能修改电脑版，建项目，在详情页打开话术库的「常规修改」类，点选「去日志」「去 Toast」「去弹窗」几条成型指令，填进输入框，再按自己的包名、类名把具体值补上；另外加一条：停用早期接入的一个分享 SDK，业务上没人用过。签名换成公司统一的证书，从这一版起内部工具也用同一套签名，后续升级可以直接覆盖。改完自动回编、对齐、签名、复核，再装到员工手机上。

改完怎么验证。第一，找两位巡检员在真机上装一遍，走完整的一次巡检流程：扫码、拍照、填表、上传；第二，抓一遍日志，确认调试输出消失，同时确认上传失败时的错误提示还在；第三，数一数弹窗：首启只剩一次必要的隐私提示，更新提示改成静默检查；第四，确认签名，这次因为换了签名，员工需要先卸载旧版再装一次，之后就都是直接覆盖升级了。这一条要提前在群里说清楚，否则又会被当成「又坏了」。

这里有个经验值得单独说：内部工具换签名，是一次性的成本。因为旧包用的是默认签名，新包用公司证书，第一次必须卸载重装。但如果这次不换，以后每次升级都要卸载，成本会一直存在。所以正确的做法是「趁这次一次换到位」，并且把原因写进通知，让使用者知道这是一次性动作。

两个例子放在一起看，会发现合规改造的收益不只是「过检查」。记账应用少了几条权限，用户在安装页看到的解释成本低了；巡检工具少了日志和弹窗，员工每天用的体验顺了；签名统一之后，升级路径也顺了。这些变化都不算「功能」，但它们决定了应用被信任的程度。

合规边界：能改什么，不能改什么

整篇文章的技术内容，都建立在一个前提上：你改的是自己的应用，或者已经获得明确授权的应用。这个前提不是客套话，而是所有操作能不能做的分界线。越过了这条线，工具再顺手，也不该用。

先说能改的。自有版权或已获授权的应用，可以做这些事：减少用不到的权限与采集项；去掉调试日志、多余 Toast、叠加的弹窗；停用不用的第三方 SDK；调整权限申请的时机，把「安装即要」改成「用时再要」；改应用名、图标、启动页、文案；改内部环境的接口地址；调整版本号。这些都属于「在授权范围内优化自己的产品」，是合规改造的正题。

再说不能改的。不要用它去除他人的授权校验或绕过安全机制；不要用来破解他人付费应用；不要用伪造签名的方式冒用他人应用身份；不要把改包当成绕过应用商店审核的手段。这些做法不只是不合规，也会让工具本身背上风险。合规改造的「合规」二字，说的是两头都合规：既让自己的应用符合规范，也让自己的行为符合法律和平台规则。

需要提醒的是：合规改造不等于绕过发布流程。自有应用的正式发布，仍然要走公司自己的测试、审核和灰度节奏；改包适合的是内部验证、授权渠道交付、以及发版前的自查整改。把「改包快」当成「不用走流程」，迟早会出问题。

最后把话说完整：本篇涉及的操作，只用于自有版权或已获授权的应用，请勿用于破解他人付费应用、去除授权校验或绕过安全机制。这条边界写在最前面，也写在最后面，因为它比任何一个技术细节都重要。

用户评价

以前删权限靠猜，删完白屏再改回来，来回两天。现在需求里写清「删哪条、留哪条、怎么验」，一次改完，权限列表从十一项减到六项，心里终于有底了。

—— 周航 · 安卓开发

最有用的是那份权限对照表。每一项为什么留、为什么删，都写在里面，向业务和检测方解释的时候不用再翻代码。

—— 苏禾 · 产品负责人

我一直以为权限就是清单里那几行。后来才知道 SDK 也会带权限进来，而且是在打包时自动合并的，难怪自己搜不到。

—— 老季 · 测试工程师

巡检工具这次把日志和弹窗都清了，更新提示也不再每次弹。升级终于不用先卸载，草稿不会丢，这是巡检员最在意的事。

—— 阿岑 · 门店运营主管

我最看重的是可回退。原始包一直留在项目目录里，改坏了重来一次就行。敢动手，是因为知道退得回去。

—— 小樊 · 独立开发者

回到青柚那次自查。两周的僵局，最后是用一份写清了定位、结果、边界和验收的需求解开的。苏禾把这份需求存成了模板，下一次自查换几条权限、换几个弹窗，改改具体值就能用。她说，合规改造最难的不是技术，而是把一句模糊的要求，变成一段可以被执行、也可以被验证的话。

这也是安卓修改大师智改工坊想讲的：工具的价值不是让人人都会写代码，而是让懂业务的人能把明确的改动落地，让懂技术的人把精力放在判断和复核上。智能修改电脑版把导入、反编译、改代码与资源、回编、对齐、签名、复核、装机预览串成一条线，Windows 10/11 64 位、.NET Framework 4.6.2 以上就能跑，安装包约 6.86 MB；但它不替你做判断。哪条权限该留、哪个 SDK 该停、弹窗该延后到哪一步，仍然要人来决定。

还是那句口号：只需说话，就能让应用变成你想要的样子。对做自有应用的小团队来说，这句话的前提是「你清楚自己的应用需要什么，也有权改它」。在这个前提下，剩下的交给流程，交给一次次被验证过的细节。更多版本信息可以看 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

合规提醒：本文涉及的操作只适用于自有版权或已获授权的应用。请勿用于破解他人付费应用、去除授权校验或绕过安全机制。改包不替代正式发布流程，自有应用的对外发版仍应遵循团队自己的测试与审核节奏。

安卓修改大师智改工坊 · 把多余的减下去，把该留的留住