权限问题为什么同时影响上架和报毒
很多团队把“上架被拒”和“被报毒”当成两件互不相关的事，实际上它们常常指向同一个根因：应用申请了与当前业务场景不匹配的敏感权限。商店审核看的是“你有没有必要”，安全软件看的是“你像不像在过度收集”。前者是合规判断，后者是行为特征判断，但两者读取的是同一份 AndroidManifest 和同一套运行时调用记录。
换句话说，权限申请不合理并不是单一环节的失误，而是会在分发链路上被反复放大的结构性问题。理解这一点，整改才有方向。
最小必要原则到底在约束什么
最小必要原则的核心不是“少申请权限”，而是“权限范围与业务功能一一对应，并且只在需要时申请”。落到工程实现上，通常包含三层约束：
- 范围最小：能用粗略定位就不申请精确定位，能读单张图片就不申请整个相册。
- 时机合理：用户触发相关功能时再弹窗，而不是启动即申请。
- 可解释：权限弹窗前的说明文案要能让用户明白“为什么现在需要它”。
这三层里，最容易被忽略的是时机。启动即批量申请定位、通讯录、存储，在审核视角里是典型的过度收集特征，在安全软件视角里则接近恶意应用的权限索取模式。
定位权限：精确与粗略要分开看
定位是权限问题的高发区。常见的不合理写法包括：只做城市级内容推荐却申请精确定位；在后台持续获取位置却没有对应的前台可见功能；把定位权限和账号注册流程强绑定，用户拒绝就无法使用核心功能。
更合理的做法是按功能拆分：
- 内容推荐、天气、附近门店列表这类场景，优先使用粗略定位，或在用户手动选择城市后完全不再申请定位。
- 导航、打卡、运动轨迹才需要精确定位，并且应当在使用该功能时申请。
- 后台定位必须有明确且用户可感知的功能支撑，否则不要声明。
如果应用确实不依赖定位，直接在清单里移除相关声明，比在弹窗文案上反复解释更有效。
通讯录权限：能不上传就不上传
通讯录权限的敏感性高于大多数权限，因为它涉及第三方（用户的联系人）信息。常见的不合理场景是“邀请好友”功能直接读取全量通讯录并上传服务端做匹配。即便业务上确有需求，也应优先考虑让用户主动选择联系人、或在本地完成匹配后只上传哈希值。
从审核和检测角度看，通讯录权限 + 网络上传 + 无明确用户操作触发，是风险评分里非常不利的组合。若功能并非核心路径，建议直接移除该权限声明。
第三方 SDK 会悄悄合并权限
很多权限问题的源头不在自研代码，而在依赖的第三方 SDK。统计、推送、广告、分享类 SDK 往往在自身清单中声明了一批权限，打包时通过 manifest 合并进入最终 APK。开发者在自己代码里搜索不到相关调用，但最终产物里权限确实存在。
因此自查时应当直接检查打包后的 APK，而不是只看源码。可以借助 APK 检测类工具查看最终权限清单、SDK 组成与运行时行为，确认每一项敏感权限都能对应到一个具体功能和一段可解释的代码路径。对于确实用不到的 SDK 权限，可通过清单合并规则显式移除，但要注意移除后 SDK 功能是否降级。
一套可执行的自查与整改流程
建议按下面的顺序推进，避免改了文案却没改行为：
- 导出最终 APK 的权限清单，逐项标注对应的业务功能与触发时机。
- 标记无对应功能的权限，优先移除；无法移除的，说明保留理由并记录在合规文档中。
- 检查 SDK 合规信息，确认每个收集行为的 SDK 都有隐私政策披露与初始化时机控制。
- 调整申请时机，把权限弹窗移动到功能入口，并补充前置说明。
- 回归验证，重新打包后再做一次 APK 检测，确认权限清单与预期一致。
这套流程的价值在于把“合规”从文档工作变成可验证的产物检查。审核方和安全软件看到的都是最终包，只有对着最终包核对，结论才可靠。
整改后的收益不只是过审
权限收敛带来的直接效果是审核沟通成本下降、被安全软件提示风险的概率降低；间接效果则是安装转化和留存改善——启动即索要通讯录的应用，用户流失往往发生在第一次弹窗。把敏感权限当成产品设计问题而非纯合规问题来处理，通常能同时解决两头的问题。更多关于打包产物检查与分发环节的排查思路，可在站内相关说明中查阅。