android – 在Google Play的Billing API v3中解决耗材的API购买逻辑缺陷(与使用API​​ v3的消耗品的每个人相关)

概述使用Billing API的第3版, Google has removed the distinction between consumable and non-consumable products.两者都被组合成一种名为“托管”的新类型,其行为有点像混合：您的应用需要主动调用方法来“消耗”这些项目.如果从未对一组skus执行此 *** 作,那些项目基本上就像它们是非消耗品一样. documentati 使用Billing API的第3版,Google has removed the distinction between consumable and non-consumable products.两者都被组合成一种名为“托管”的新类型,其行为有点像混合：您的应用需要主动调用方法来“消耗”这些项目.如果从未对一组skus执行此 *** 作,那些项目基本上就像它们是非消耗品一样.

documentation描述了预期的购买流程如下：

>使用getBuyIntent调用启动购买流程.
>从Google Play获取响应包,表明购买是否成功完成.
>如果购买成功,请通过进行消费购买来消费购买.
>从Google Play获取响应代码,指示消费是否成功完成.
>如果消费成功,请在您的应用程序中配置产品.

我看到这种方法存在两个问题.一个是相当明显的,文档中的“BUG”比API更多,但另一个是相当微妙的,我仍然没有想出如何最好地处理它.让我们从显而易见的完整性开始：

问题1：在单个设备上购买丢失：

文档说应用程序应该在每次启动时调用getPurchases以“检查用户是否拥有任何未完成的耗材应用程序内产品”.如果是这样,应用程序应使用这些并配置关联的项目.这包括在购买完成之后但在消耗该物品之前(即在步骤2附近)中断购买流程的情况.

但是如果购买流程在步骤4和5之间中断怎么办？即该应用程序成功完成了购买,但它有机会将产品配置给用户之前已经被杀死(电话进来并且没有足够的内存,电池耗尽,崩溃等等).在这种情况下,购买将不再包含在getPurchases中,基本上用户永远不会收到他所支付的费用(在这里插入愤怒的支持电子邮件和一星评价)……

幸运的是,通过引入“期刊”(like in a file system)将购买流程更改为更类似的内容(步骤1和2与上述相同),这个问题相当容易解决：

>如果购买成功,请进入日记中说“购买后将硬币从300增加到400< order-ID here>成功消费”.
>确认日记帐分录后,通过进行消费购买来消费购买.
>从Google Play获取响应代码,请在您的应用程序中配置产品.
>确认配置后,将日记帐分录更改为“在此处购买< order-ID>已完成”.

然后,每次应用程序启动时,它不应该只检查getPurchases,还应该检查日志.如果getPurchases没有报告未完成购买的条目,请继续执行步骤6.如果稍后的getPurchase应该再次返回该订单ID(例如,如果消费完全失败),则忽略该交易如果期刊将此订单ID列为完整.

这应该解决问题1,但如果您发现此方法存在任何缺陷,请告诉我.

问题2：涉及多个设备时的问题：

假设用户拥有两台设备(例如手机和平板电脑),两者都拥有相同的帐户.

他(或她 – 从现在开始暗示)可以尝试在他的手机上购买更多硬币,并且应用程序可能会在购买完成后被杀死,但在消费之前.现在,如果他接下来在平板电脑上打开应用程序,getPurchases会将产品报告为已拥有.

平板电脑上的应用程序必须假定购买是在那里启动的,并且它在创建日记帐分录之前就已经死亡,因此它将创建日记帐分录,使用产品并提供硬币.

如果手机应用程序在有机会进入日记帐之前就已经死亡,那么硬币将永远不会在手机上配置(在这里插入愤怒的支持电子邮件和一星评价).如果手机应用程序在创建日记帐分录后死亡,则硬币也将在手机上配置,基本上可以让用户在平板电脑上免费购买(在此处插入损失的收入).

解决此问题的一种方法是在购买时添加一些唯一的安装或设备ID作为有效负载,以检查购买是否适用于此设备.然后,平板电脑可以简单地忽略购买,只有手机才会记入硬币并消费该物品.

但是：由于此时sku仍然在用户手中,Play商店将不允许用户购买另一个副本,所以基本上,直到用户再次在他的手机上启动应用程序来完成待处理的交易,他不会能够在平板电脑上购买更多的虚拟硬币(插入愤怒的支持电子邮件,一星评价,以及这里的收入损失).

是否有一种优雅的方式来处理这种情况？我能想到的唯一解决方案是：

>向用户显示一条消息,请先在另一台设备上启动应用程序(哎呀！)
>或为同一消耗品添加多个skus(应该可以工作,但仍然很糟糕！)

有没有更好的办法？或者我可能只是从根本上误解了一些东西,这里真的没有问题吗？ (我意识到这个问题出现的可能性很小,但是有足够大的用户群,“不太可能”最终变成“一直”.)

解决方法 这是解决所有这些问题的最简单方法,到目前为止我已经提出了这个问题.这不是最优雅的方法,但至少它应该工作：

>生成全球唯一的购买ID并将其本地存储在设备上.
>使用购买ID作为开发人员有效负载,使用getBuyIntent启动购买流程.
>从Google Play获取响应包,请配置产品并记住购买ID已完成(必须以原子方式完成).
>如果配置成功,则通过进行消费购买来消费购买(我以“即发即忘”的方式执行此 *** 作).

每次启动应用程序时,请执行以下 *** 作：

>发送getPurchases请求以查询用户的自有应用内商品.
>如果找到任何消耗品,请检查开发人员有效负载中的购买ID是否存储在设备上.如果没有,请忽略该产品.
>对于具有“本地”购买ID的产品,请检查购买ID是否包含在已完成列表中.如果没有,继续上面的步骤4,否则继续上面的步骤5.

以下是单个设备上出现问题的方式以及随后发生的情况：

>如果购买从未开始或未完成,则用户不会收费并且应用程序返回到购买前状态,用户可以再次尝试.未使用的购买ID仍然在“本地”列表中,但这应该只是一个相当小的“内存泄漏”,可以通过一些到期逻辑来修复.
>如果购买完成,但应用程序在步骤4之前消失,当它重新启动时,它会找到待处理的购买(产品仍然报告为已拥有)并可继续执行步骤4.
>如果应用程序在步骤4之后但在产品消耗之前死亡,应用程序会在重新启动时找到待处理的购买,但是知道忽略它,因为购买ID在已完成列表中.该应用程序只是继续第5步.

在多设备情况下,任何其他设备将简单地忽略任何非本地待定购买(报告为拥有的消耗品),因为购买ID不在该设备的本地列表中.

一个问题是待定购买将阻止其他设备能够为同一产品开始并行购买.因此,如果用户在他的手机上的步骤2和5之间(即在购买完成之后,但在消费完成之前)某处有不完整的交易,他将无法再在他的平板电脑上购买相同的产品,直到应用程序完成步骤5,即在手机上使用产品.

通过将每个耗材SKU的多个副本(可能是5个？)添加到Google Play并将第一个列表中的第2步更改为：可以非常轻松地解决此问题(但不是很优雅)：

>使用购买ID作为开发人员有效负载,使用getBuyIntent为集合中的下一个可用SKU启动购买流程.

关于黑客行为的说明(按照黑客难度增加的顺序)：

>通过Freedom APK或类似产品完成虚假购买：这些应用程序基本上冒充Google Play商店完成购买.要检测它们,需要在购买收据中包含verify the signature并拒绝未通过支票的购买,大多数应用程序都不会这样做(right).大多数情况下问题解决了(见第4点).
>通过Game Killer或类似方式增加耗材的应用内帐户余额：这些应用程序将尝试确定应用程序存储当前硬币或其他耗材产品的内存(或本地存储)的位置,以直接修改号码.为了使这更难(即普通用户不可能),人们需要想出一种方法来存储帐户余额而不是“纯文本”整数,而是以某种加密方式或与一些校验和一起存储.大多数情况下问题解决了(见第4点).
>在适当的时间杀死应用程序并弄乱其本地存储：如果有人在手机上购买了可消费产品并且在产品配置之后但在消费之前设法杀死应用程序(可能非常难以强制使用),然后,他们可以修改平板电脑上的本地存储空间,将购买ID添加到本地列表,以便在每台设备上授予一次产品奖励.或者,他们可能会损坏手机上已完成购买ID的列表,然后重新启动应用以获得两次奖励.如果他们在配置之后但在消费产品之前再次设法杀死应用程序(现在只需将手机设置为飞行模式并删除Google Play商店缓存即可轻松实现),他们可以通过这种方式继续窃取越来越多的产品.同样,对存储进行混淆或校验可能会使这变得更加困难.
>为应用程序反编译和开发补丁：当然,这种方法可以让黑客在你的应用程序中做任何他们想做的事情(包括打破为减轻第1点和第2点而采取的任何对策),这将非常难以预防完全.但是,通过使用代码混淆(ProGuard)以及关键购买管理代码的过于复杂的逻辑(可能会导致错误的代码,因此,这不一定是最好的想法)对黑客来说可能更难.此外,代码的编写方式可以修改其逻辑,而不会影响其功能,以允许定期部署打破任何可用补丁的备用版本.

总体而言,购买的签名验证和一些相对简单但非明显的相关数据校验和签名(在内存和本地存储中)应足以迫使黑客反编译(或以其他方式反向工程)应用程序为了窃取产品.除非应用程序非常受欢迎,否则这应该是一个足够的威慑力量.代码中的灵活逻辑与频繁更新可以打破任何已开发的补丁程序,可以使应用程序成为黑客的移动目标.

请记住,我可能会忘记其他一些黑客攻击.如果你知道一个,请评论.

结论：

总的来说,这不是最干净的解决方案,因为需要为每个消耗品保持多个并行SKU,但到目前为止,我还没有找到一个能够解决问题的更好的SKU.

所以,请分享您可能有的任何其他想法. 1保证任何好的指针. 总结

以上是内存溢出为你收集整理的android – 在Google Play的Billing API v3中解决耗材的API购买逻辑缺陷(与使用API​​ v3的消耗品的每个人相关)全部内容，希望文章能够帮你解决android – 在Google Play的Billing API v3中解决耗材的API购买逻辑缺陷(与使用API​​ v3的消耗品的每个人相关)所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。