Google Play上架贷款App因权限声明不符被拒问题咨询

你之前三次提交被驳回的核心原因是选的权限场景和实际用途完全错配，对应问题点：

• 选「Default SMS handler」「Default Phone handler」被驳回：这两个场景仅面向替代系统原生短信、拨号功能的默认系统应用开放，贷款类App根本不符合准入前提，属于典型的场景误选，必然被打回。
• 选「SMS-based financial transactions and related activity where access is restricted to financial SMS transactions」被驳回：该场景严格限定App只能读取自身发起的5位短码交易相关短信（比如自家App发送的验证码、放款/还款提醒），明确禁止读取全量短信用于风控建模，和你采集数据训练信用评分模型的用途边界完全不符，审核员只要核对你隐私政策里的数据用途、做运行时行为检测就能判定不符合要求。

你提到的同类型替代信用评分类贷款App能过审，核心是没有硬申请全量SMS/Call Log敏感权限，全部走的合规替代路径，具体可落地方案按优先级排序如下：

方案1：替换为官方认可的无敏感权限实现（过审率100%，为行业通用方案） #

这是目前同类产品的主流做法，完全不需要申请受限的敏感权限就能满足业务需求：

• OTP验证场景：放弃READ_SMS权限，接入Google官方的SMS Retriever API，该接口无需申请敏感权限，只能自动读取发送给当前App的验证码短信，完全符合Google规则。
• 信用评分数据采集：砍掉全量短信、通话记录采集逻辑，换用合规的替代数据维度：
  • 走普通权限采集设备基础信息、已安装应用列表（仅采集金融类、经营类应用相关特征，不要全量上传）、模糊位置信息
  • 引导用户通过系统Storage Access Framework手动选择授权需要的账单、经营流水相关记录，不要默认强制授权
  • 对接运营商官方开放平台，通过OAuth用户授权获取官方出具的话费、缴费记录，不要通过爬取短信的方式获取相关数据

核心判定原则要记清楚：Google对SMS、Call Log这类受限权限的审核底线是，权限必须直接服务于用户可感知的当下核心功能，后台静默采集全量用户数据用于风控建模属于明确禁止的用途，不管你在隐私政策里怎么写都不会过审。

方案2：确需保留相关权限的合规申报方式 #

如果业务逻辑暂时无法调整、必须使用相关权限，按以下要求准备，不要选错场景：

• 场景选择：勾选「SMS based money management」，该场景是专门面向个人财务、信贷类App开放的合规入口，允许读取金融相关短信用于用户财务状况评估，匹配信贷风控的业务场景，不要选之前错配的三类场景。
• 必须同步提交的审核材料：
  • 完整操作录屏：从用户首次打开App开始，完整演示权限申请弹窗的触发时机——必须在用户点击「提交贷款申请」按钮触发信用评估流程时才弹权限申请，同时弹窗旁要附清晰的用户可见说明：授权读取金融类短信将帮助您快速完成信用评估，缩短审核时长，您可随时拒绝授权，不影响App基础功能使用；录屏还要展示用户授权后，权限使用的完整功能链路，不能出现后台静默采集的相关逻辑。
  • 隐私政策匹配说明：明确标注读取SMS/通话记录的具体范围（如仅识别含银行、持牌金融机构关键词的交易类短信，不读取私人社交、非金融类短信）、数据存储周期、第三方共享范围、用户随时删除个人数据的操作入口，不能用「用于提升服务体验」这类模糊表述。
  • 功能自证材料：在App内设置明确的用户可访问入口，展示基于相关数据生成的信用评估结果，证明数据仅用于用户主动发起的信用评估流程，没有超范围滥用。
• 避坑提醒：不要在代码里隐藏全量短信/通话记录上传的逻辑，Google审核会做静态代码扫描和动态运行行为检测，一旦发现实际采集范围和申报内容不符，不仅会拒审，还可能直接限制开发者账号权限。

提前排查易踩的驳回坑点 #

• 清理manifest冗余权限：检查主包和所有接入的第三方SDK，把没有对应面向用户功能的READ_SMS、READ_CALL_LOG、WRITE_CALL_LOG等受限权限全部移除，哪怕是SDK自动带的、你实际没用到的权限也要删掉，多余权限是审核重点排查项。
• 调整权限用途表述：申报表单里不要写「用于反欺诈」「用于风控」这类用户无法感知直接价值的表述，要站在用户视角写收益：授权后可减少手动提交收入证明材料的步骤，将贷款审核时长从24小时缩短至5分钟。
• 不要跨场景申报：不要试图伪装成默认短信应用、反诈骗应用、来电识别类应用蹭权限场景，Google有全量同类App的特征库，一旦被判定为虚假申报，会直接影响账号信誉，后续提交审核的通过率会大幅降低。

内容的提问来源于stack exchange，提问作者reeco