Android In App Billing... 为什么会有相互矛盾的信息？答案

【问题标题】：Android In App Billing... Why is there contradicting info?Android In App Billing... 为什么会有相互矛盾的信息？
【发布时间】：2013-06-21 05:03:06
【问题描述】：

我和许多其他人一样，只是在验证静态响应是否正常工作后尝试测试我的应用内购买。但是当我阅读文档、帖子和答案时，似乎没有任何结果。我变得非常沮丧。

我的最终目标是弄清楚我是否可以在不收费的情况下进行测试。

这个文档说我可以 - link

一旦获得测试访问权限，这些用户就可以旁加载您的应用并测试您产品的完整销售、购买和履行流程。测试购买是真实订单，Google Play 以与其他订单相同的方式处理它们。购买完成后，Google Play 会阻止订单进入财务处理阶段，确保不会向用户帐户收取任何实际费用，并在 14 天后自动取消已完成的订单.

和相同的链接

在测试购买期间，用户可以在您的应用中测试实际的推销、购买和履行流程。在购买过程中，应用内商品显示为普通商品，并附有实际价格。但是，Google Play 会在购买对话框的中心标记测试购买，以便于识别

但是在这个页面上，它说 - link

使用测试人员帐户登录测试设备。通过购买一些项目来测试您的应用内结算应用程序，并解决您遇到的任何问题。 如果您不希望实际向测试人员收费，请记住退款！

WTF...所以有人知道吗？可以不收费做检测吗？如果有，怎么做？

【问题讨论】：

您使用的是应用计费版本 3 吗？
在下面查看我的答案。您只需更改我的答案中显示的产品 ID，您就可以免费测试它。干杯！！

标签： android in-app-purchase in-app-billing billing android-billing

【解决方案1】：

如果您使用的是应用内结算版本 3，那么您可以简单地使用 product id="android.test.purchased"。它是虚拟产品，您不应将其添加到开发人员控制台中。您可以免费购买该产品。

android.test.purchased

当您使用此产品 ID 提出应用内结算请求时，Google Play 会做出响应，就像您成功购买了商品一样。响应包含一个 JSON 字符串，其中包含虚假购买信息（例如，虚假订单 ID）。在某些情况下，JSON 字符串是经过签名的，并且响应包含签名，因此您可以使用这些响应测试您的签名验证实现。

希望对你有所帮助。

【讨论】：

正如我在最初的问题中所说，我已经使用了静态响应并验证了它正在使用它们。我现在正在尝试使用实际购买来测试工作流程。
是的，它就像真正的购买一样工作，但您展示的产品是由 google play 创建的虚拟产品。通过使用它，您可以检查您的工作流程，在购买商品后应用程序的导航会发生什么变化等。但是如果你仍然想在你把它放在你的开发者控制台中的真实产品中测试它，那么我认为这是不可能的。
好的，这就是我想要的。我不理解文档，也许是旧版本的文档，但他们绝对不会这么说。即使有 100 篇关于这个主题的帖子，也没有人对它是否可能说是或否。我遇到的问题是我有多个可以多次购买的 IAP（非托管），我能看到区分它们的唯一方法是 productID，如果它总是“android.test.purchased”那么我可以' t告诉发生了什么。我想我可以使用有效载荷或其他东西。
是的，你可能是对的，因为我没有阅读更多关于你所说的另一种测试方法的信息。通常人们遵循这种方法，因为与另一种方法相比，它是最简单的测试方法，你只需更改产品 ID 即可。
@Maulik ：我需要你的帮助。现在我们正在使用测试，但请指导我应该对代码进行哪些更改以使其适用于我的实时应用程序？或者如何在应用内购买对话框中显示我的真实头衔和奖品？

【解决方案2】：

是的：您可以为您在控制台中实际定义的真实商品 (SKU) 进行测试购买，无需支付任何费用。我自己刚刚成功地做到了这一点。

与目前接受的答案中给出的建议相反，没有需要像使用静态测试一样使用虚拟 SKU android.test.purchased。

OP 引用了这段话：

在测试购买期间，用户可以在您的应用中测试实际的推销、购买和履行流程。在购买过程中，应用内商品显示为普通商品，并附有实际价格。但是，Google Play 会在购买对话框的中心标记测试购买，以便于识别

到目前为止，这是正确的，并且与我能够实现的目标一致。

但 OP 引用的后续段落：

使用测试人员帐户登录测试设备。通过购买一些项目来测试您的应用内结算应用程序，并解决您遇到的任何问题。如果您不希望实际向测试人员收费，请记住退款！

就我而言，这（尤其是最后一句话）是不正确的。

你可以按照第一段做。也就是说，只要将测试帐户作为测试人员添加到控制台，那么在尝试进行购买时，对话框（显示价格等）也应该在其中心有一个特殊字符串（如第一段所述）说明“这是一个测试订单，您不会被收费”。

但是，要真正做到这一点，测试人员（或测试设备）使用的实际 APK 也必须是上传到 Alpha 通道的。

所以，我采取的步骤如下：

为 Alpha 通道测试创建一个单独的 Google 组。
将您的 IAP 测试用户 gmail 帐户添加到该组。
将带有应用内购买代码的 APK（导出并使用发行证书签名）上传到 Alpha 通道。
等待一两个小时让 alpha 版本生效。
同时，设置一个单独的测试设备，上面只设置了测试 gmail 帐户。
以测试用户身份登录时，导航至测试设备上的选择加入 URL，选择加入 Alpha 通道测试。
使用该测试人员帐户登录 Play 并从 Play 安装应用程序。此时（或一两个小时后）您上传的最新 alpha 应该是现在安装的那个。
尝试购买。当对话框出现价格时，它应该有一个额外的“这是一个测试订单，你不会被收费”字符串。

事实上，为了完全准确，测试设备似乎不一定需要从 Play 安装 alpha APK。根据我的测试，重要的是您确实有一个 APK 作为 alpha 上传，并且您在测试设备上运行的 APK 具有相同的版本号。此外，测试用户需要选择加入 alpha 版本并在控制台中添加为测试人员（如上所述）。我刚刚导出了另一个经过调整的 APK 版本并使用 adb install 加载到我的测试设备中，我仍然可以尝试购买带有“...您不会被收费”消息的真实 SKU。

【讨论】：

【解决方案3】：

购买后必须消费。

consume.setOnClickListener(new View.OnClickListener() {
        @Override
        public void onClick(View view) {
            Thread t = new Thread(new Runnable() {
                @Override
                public void run() {
                    String purchaseToken = "inapp:" + getPackageName() + ":android.test.purchased";
                    try {
                        Log.d("","Running");
                        int response = mService.consumePurchase(3, getPackageName(), purchaseToken);
                        if(response==0)
                        {
                            Log.d("Consumed","Consumed");
                        }else {
                            Log.d("","No"+response);
                        }
                    }catch (RemoteException e)
                    {
                        Log.d("Errorr",""+e);
                    }

                }
            });
            t.start();
        }
    });

【讨论】：