权限问题为什么同时影响上架和报毒
很多团队把上架被拒和报毒当成两件事处理：前者找审核，后者找加固。但在安卓生态里，这两件事经常指向同一个根因——权限申请与实际功能不匹配。应用商店审核看的是“你有没有必要要这个权限”，杀毒引擎和 Google Play Protect 这类风险提示看的是“这个包的行为像不像恶意软件”。一个工具类应用申请读取通讯录，在审核侧是必要性问题，在检测侧就是高风险行为特征。
所以权限收敛不是合规部门的单独任务，而是上架和分发的共同前置条件。
最小必要原则落到三个层面
“最小必要”不是一句口号，它可以拆成三个可检查的层面：
- 声明层：AndroidManifest 里声明了哪些权限，是否包含当前版本根本用不到的项。
- 申请层：运行时是否在用户触发具体功能时才申请，而不是启动即弹窗批量索要。
- 使用层：拿到权限后是否真的用于对应功能，是否存在后台频繁读取。
审核和检测通常三层都会看。声明层最容易查，也最容易被历史代码拖累——早期接入的推送、统计、广告 SDK 往往自带一批权限，主工程早已不用，清单里却还留着。这类“僵尸权限”在审核眼里没有合理解释，在检测引擎眼里则是可疑信号。
定位与通讯录：两个高风险样本
定位权限的问题通常不在“要不要”，而在“精度和频率”。一个只做城市级天气展示的应用申请后台精确定位，理由很难自圆其说；一个签到类应用在用户未进入签到页时就持续请求位置，属于典型的申请时机错误。建议做法是：能用地级市就用粗略定位，能前台用就不申请后台定位，并在申请前用一句话说明用途。
通讯录权限更敏感。除了社交邀请、号码识别这类强关联场景，多数应用没有合理理由读取联系人。即便功能确实需要，也应优先考虑让用户手动选择单个联系人，而不是整本读取。整本读取加上上传行为，是报毒和风险提示的高发组合。
短信、通话记录、无障碍服务同理。无障碍服务被大量恶意样本滥用，正常应用申请它时需要格外克制的说明和严格的调用边界，否则很容易被引擎按高风险归类。
SDK 继承权限是最常见的漏点
很多“我们没申请这个权限”的申诉，最后都指向第三方 SDK。合并后的清单里出现的权限，可能来自广告、统计、推送、分享等组件。处理思路是：
- 导出合并后的 AndroidManifest，逐项对照功能清单，标记无主权限。
- 查清每个权限由哪个 SDK 的哪个版本引入，优先升级到支持权限裁剪的版本。
- 用 tools:node="remove" 等方式移除确认不需要的权限，并回归测试相关 SDK 是否异常。
- 对无法裁剪又确实不需要的 SDK，评估替换或下线。
这一步做完，往往会发现清单能瘦一圈，审核问询和检测告警同时减少。关于 SDK 引入的完整检查思路，可以参考站内 APK 检测与合规说明 中的整理。
申请时机与文案同样被审视
同样是申请定位，启动页一进来就弹窗，和用户点击“附近门店”后再弹窗，审核观感完全不同。建议遵循“功能触发—说明用途—再申请”的顺序，拒绝后提供降级路径而不是反复弹窗。被用户拒绝后仍循环索要，是很多检测规则明确标记的行为。
权限说明文案要具体。写“为了给您更好的体验”没有信息量，写“用于展示您所在城市的天气”才构成合理解释。这部分文案同时会出现在商店的权限说明和数据安全表单里，前后不一致会引发额外问询。
一份可执行的自检清单
- 导出合并清单，逐项标注权限对应的功能与引入方。
- 检查是否存在后台定位、读取通讯录、读取短信等高风险组合。
- 确认所有敏感权限都在用户操作后申请，且有明确说明。
- 检查拒绝权限后的降级逻辑，确认不会循环弹窗。
- 用静态检测工具跑一遍权限与 SDK 清单，比对历史版本差异。
- 提审前用真实设备走一遍首次启动流程，记录弹窗顺序。
权限收敛之后，如果仍在分发环节遇到风险提示，可以按 报毒与风险提示排查路径 的顺序，从权限、SDK、网络传输到签名完整性逐项确认，避免把权限问题误判成加固问题。
结语
敏感权限不是“申请了再说”的选项。声明、申请、使用三个层面任一环节与功能脱节，都可能在审核和检测两端同时放大成本。把最小必要原则做成提审前的固定检查项，比事后申诉和加固补救更省事。