钱包 App Google Play 上架案例:交易截图权限整改

钱包应用 Google Play 权限申请与审核案例


一款海外钱包 App 在准备提交 Google Play 前,发现交易凭证上传功能涉及的图片访问范围与实际使用场景并不完全匹配。本文记录从第三方图片组件、权限调用到 Data Safety 的排查过程,以及提交前如何针对性调整。

一、项目概况

这是一款面向海外用户的钱包类 App,主要功能包括账户管理、交易记录查询和交易凭证上传。

客户找到我们的时候,App 基本已经开发完成,隐私政策、商店资料等也准备得差不多了,下一步就是提交 Google Play。

按照以往的项目流程,我们没有直接拿现有版本去提交,而是先把 App 从头到尾实际操作了一遍。

账户登录、交易记录、凭证上传这些功能都正常。

真正让我们停下来多看了一眼的,是一个很普通的“上传交易截图”功能

二、客户需求

钱包 App 的交易凭证上传并不算复杂。

用户完成交易后,如果需要留存凭证,可以点击上传,从手机里选择一张付款截图。

客户的要求也很明确:

· 交易凭证上传功能需要保留

· 不能因为整改影响正常使用

· 正式提交 Google Play 之前,希望把可能影响审核的问题先处理掉

所以我们当时主要关注一个问题:用户只是选择一张交易截图,App 实际上需要多大的图片访问范围?

这个问题在产品页面上其实看不出来,必须结合实际操作和代码调用一起看。

三、项目问题 / 难点

问题并不是简单的“App 有图片权限”。

我们实际检查后发现,原来的图片上传功能用了第三方图片选择组件。

从用户的操作来看很简单:点击上传 → 选择图片 → 完成上传

但继续往下检查时发现,组件涉及的图片访问能力比这个功能本身需要的范围更大。

这类情况在开发过程中其实并不少见。

为了快速完成上传功能,直接接入一个现成组件很方便,但组件默认提供的能力,并不一定刚好等于产品实际需要的能力。

所以这次的问题并不是:“图片权限不能用。”

而是:这个功能需要的权限范围,和 App 实际要完成的事情是不是完全对应。

我们决定在提交之前先把这里处理掉,而不是等审核阶段出现问题以后再改版本。

四、解决方案

我们没有简单粗暴地把图片权限删掉。第一步是重新确认交易凭证上传到底需要什么。用户只是主动选择一张图片,就没有必要为了这个功能引入更大的访问范围。

接着,我们检查第三方图片组件的实际调用情况,再根据最终的使用场景调整图片选择方案。如果业务确实需要更广泛的图片访问,就保留相应能力;如果只是选择用户主动指定的图片,则尽量让实现方式和这个场景保持一致。

整改过程中,我们也按照 Google Play 的官方要求重新检查了权限用途:Google Play 权限与敏感信息政策


我们更关注的是一个很实际的问题:代码里的实际行为、产品功能和后台申报能不能对得上。

五、项目执行过程

这次没有大改 App,主要就是围绕交易凭证上传这一块往下查。我们先实际操作了一遍:打开交易记录 → 点击上传凭证 → 选择图片 → 完成上传

然后再去看 Android 权限声明,以及第三方图片组件在这个过程中具体调用了什么。确认问题之后,开发团队调整了图片选择部分。

改完以后,我们没有直接结束,而是重新测试了一遍原来的流程。

毕竟权限调整如果影响到用户上传凭证,那就得不偿失了。

功能确认没有问题后,再把新的实际行为和隐私政策、Data Safety 一起核对。

涉及 Data Safety 的部分,也重新参考 Google Play 官方说明进行检查:Google Play Data Safety 官方说明

最后才进入正式提交前的检查。

六、整改前 / 整改后

检查项目

整改前

整改后

交易凭证上传

正常使用

保留原功能

图片访问方式

实际访问范围偏大

根据实际场景调整

第三方图片组件

需要进一步确认调用情况

完成排查和调整

权限声明

需要重新核对

与实际功能重新确认

Data Safety

按原版本信息填写

根据调整后的实际行为重新检查

调整之后,用户原来的操作方式没有发生明显变化,还是可以正常上传交易凭证。变化主要发生在 App 背后的权限处理方式。

七、项目结果

这次整改没有影响交易凭证上传,也没有因为调整权限把原来的功能砍掉。

原本需要在审核阶段解释的问题,我们在提交之前就先处理了。

随后,项目按照调整后的版本继续推进 Google Play 上架。

这里也不把结果简单归结成:“改了权限,所以审核通过。”

Google Play 的审核是综合判断,这次解决的是提交前发现的一个具体问题。

如果已经收到审核反馈,处理方式也会有所不同。不同 App 的功能和审核情况不一样,不能拿一个案例直接套用。

之前我们也整理过一个首次提交被拒的项目,可以作为对比参考:Google Play 首次提交被拒案例

八、项目总结

这个项目给我们留下比较深的印象,反而不是因为问题有多复杂。

上传一张交易截图,看起来就是一个很普通的功能,但真正往下检查之后,会发现它还牵涉到第三方组件、图片访问和后台申报这些东西。

尤其是钱包、支付、账单类 App,类似的图片和文件操作比较多。开发时能正常运行,并不代表提交前就可以完全不检查。

我们现在做这类项目时,通常会先自己把 App 当成普通用户操作一遍。

用户点了什么,App 做了什么,调用了什么权限,再回头看后台填的信息。很多问题其实就是这样查出来的。

如果你的 App 也准备首次提交 Google Play,可以先看看我们的:Google Play 上架服务

如果 App 已经开发完成,只是不确定权限、Data Safety 或提交材料有没有需要调整的地方,也可以在正式提交前先做一次检查。

九、相关服务

Google Play App 上架服务

针对首次提交、版本更新和海外 App 发布,协助检查提交资料、商店信息及审核相关问题。

Google Play 审核整改服务

针对权限、隐私政策、Data Safety、Metadata 等具体问题进行排查,并根据实际情况制定整改方案。

Google Play 提交前检查

从 App 实际功能、权限调用、数据申报和商店资料几个方面进行检查,尽量把容易遗漏的问题放在提交前解决。