为什么“多申请一个权限”会变成上架问题
很多团队在开发期为了方便，会在 AndroidManifest 里一次性声明定位、通讯录、短信、通话记录等权限，等上线前再考虑删减。问题在于，应用商店审核和终端安全检测看的不是“你有没有用”，而是“你声明了什么、SDK 在运行时调用了什么”。当声明范围明显超出功能所需，审核方会要求说明用途，安全软件则可能直接给出风险提示。
这里的关键概念是最小必要原则：应用只应申请与当前核心功能直接相关、且用户可感知的权限。定位用于附近门店或配送地址是合理的，通讯录用于邀请好友需要明确交互入口，若两者都没有对应界面，却出现在权限列表里，就很难解释。
定位权限：精度与使用场景要匹配
定位是最容易被误判的权限之一。常见问题包括：
- 只做城市级内容推荐，却申请精确位置（ACCESS_FINE_LOCATION），而非粗略位置。
- 后台持续定位没有前台可见提示，用户无法判断何时被采集。
- 地图、推送、统计等第三方 SDK 在初始化时顺带触发定位请求，主业务并未使用。
审核侧通常关注三点：权限是否与可见功能对应、是否在用户触发相关操作时才请求、是否有清晰的用途说明。终端检测侧则更关注行为：应用在冷启动阶段就请求定位，或频繁在后台读取位置，容易被标记为异常采集。
通讯录权限：调用路径要能被解释
通讯录权限的敏感度更高，因为它直接关联他人信息。合理场景通常有明确入口，例如“邀请好友”“发现已注册联系人”，并且需要用户主动点击后才发起请求。不合理的情况包括：
- 首次启动即弹窗申请通讯录权限，与当前页面功能无关。
- 申请后上传全量联系人，但产品内没有对应的好友推荐或邀请功能。
- 通过 SDK 间接读取通讯录，主工程代码中看不到调用，但运行时确实发生。
这类问题在上架审核中往往表现为“用途说明不充分”，在 APK 检测中则可能被归入过度收集个人信息的行为特征。
SDK 合规：声明与调用不一致是重灾区
权限问题很少只来自主工程。广告、统计、推送、分享类 SDK 常自带权限声明，或在初始化时触发定位、设备标识读取。若开发者只在主工程里删了权限，却没有检查合并后的 Manifest 和 SDK 运行时行为，就会出现“代码里没写、包里却有”的情况。
建议在发版前做一次合并清单核对：查看最终 APK 的权限列表，逐项对应到具体功能和 SDK；对无法解释的权限，要么删除声明，要么移除触发它的 SDK 初始化时机。站内关于第三方组件引入风险的讨论可参考 第三方 SDK 接入与合规自查 中的思路。
APK 检测视角：权限组合比单个权限更敏感
安全软件和部分分发平台的 APK 检测，往往不是看单一权限，而是看组合与行为。例如“通讯录 + 短信 + 后台定位”同时出现，又没有明确的业务场景，风险评分会明显上升。再叠加频繁自启动、读取设备标识、静默下载等行为，就可能触发报毒或风险提示。
这类提示不一定意味着应用真的有恶意代码，但对下载转化和用户信任的伤害是直接的。处理顺序上，应先核对权限声明与 SDK 调用，再检查网络传输与签名完整性，具体排查路径可参考 安装包风险提示的排查顺序。
可落地的收敛清单
- 按功能列出权限清单，每个权限写明使用场景和触发页面，删除无对应入口的声明。
- 优先使用低精度定位和一次性授权，避免默认申请后台位置。
- 通讯录等敏感权限改为用户主动触发后再请求，并提供跳过路径。
- 检查合并后的 Manifest，确认第三方 SDK 带入的权限是否必要。
- 在真机上走一遍首次启动流程，观察是否有与当前页面无关的权限弹窗。
- 发版前用检测工具查看权限组合与运行时行为，记录整改结果。
权限治理不是一次性的上架前动作，而是随功能迭代持续收敛的过程。把最小必要原则落实到声明、调用和 SDK 管理三个层面，才能同时降低审核受阻和报毒提示的概率。