如果你使用的apk版本与谷歌比赛中的apk版本不同，就会发生这种情况。

最近谷歌对他们的系统进行了更改，因为你已经上传了至少一个APK到你的控制台，你可以用你的应用程序测试你的应用内请求，使用任何版本代码/号码。

交叉参考LINK

配置gradle为调试版本签名。

android {
    ...
    defaultConfig { ... }
    signingConfigs {
        release {
            storeFile file("my-release-key.jks")
            storePassword "password"
            keyAlias "my-alias"
            keyPassword "password"
        }
    }
    buildTypes {
        debug {
            signingConfig signingConfigs.release
            ...
        }
    }
}

我的问题是，我试图用调试检查它。密钥库，我是说在eclipse中运行它。我将它与我在alpha模式下发布的密钥存储库一起导出(在您可以测试它之前必须发布它)。把它安装在我的手机里，然后我就可以正常测试了。

与SO和其他网站上的许多答案和评论相反，你不需要使用从谷歌Play下载到测试设备上的产品alpha/beta版本进行初步测试(alpha/beta发布过程通常要花半天时间)。你也不需要从你的开发工作室加载和重新加载一个签名的apk到你的测试设备。

You CAN debug preliminary Google Play in app billing services using the debug app as loaded from your developer studio directly to your test device via ADB. If you are experiencing errors that prevent this, likely you have done something wrong in your code. Pay especially close attention to the CASE of your SKU's (product ids) and their format (for example, if you load your APK as com.mydomain.my_product_id, be sure your try to purchase it this way - providing the same case and domain). Also, pay especially close attention to your itemType - this should be either "inapp" or "subs" for managed/unmanaged in app purchases or subscriptions, respectively.

As suggested by Chirag Patel, provided you have your billing code properly established, perform all testing using the android.test.purchased Sku (product ID) during your preliminary tests. Check for this ID throughout your billing operations to pass it through signature, token and payload checks, since this data is not provided by the Google test system. Additionally, give one of your test products this ID to test its purchase, unlock/load and presentation all the way through your schema. To CLEAR the purchase, simply consume it, passing the same Sku AND a token string formatted this way - no other fields are relevant :

    "inapp:"+appContext.getAppContext().getPackageName()+":android.test.purchased";

Once you have completed this phase of testing, move to semi-live testing with your alpha/beta product. Create a Google group (essentially a mailing list), add your test users emails to it, and add/invite this group to test your device in this phase (performed at the "APK" portion of your app's Google developer listing). Purchases will be simulated but not actually charged - however to clear and re-test the purchases, Google indicates that you must refund them from your Google wallet. THIS is the only phase of testing that requires the time-consuming process of using alpha/beta loads and test users.

让我补充一下发生在我身上的事，也许能帮到别人。

这主要是由于签约。

由于我已经在Project结构中添加了签名细节，所以我认为每次运行时，都安装了期望的签名apk。但是选择了“调试”构建类型。

下面的修复为我解决了问题。

生成构建类型为“release”的签名apk。 手动安装apk。

2021年结论

对于所有关心调试的人，您可以在调试模式下运行、调试和测试代码

下面是你如何测试这个过程:

(当然，这取决于您已经添加并激活了您的产品，并且您的代码已经准备好与这些产品集成)

将com.android. selling . billing添加到清单中 上传签名apk到内部测试 添加许可证测试员(播放控制台->设置->许可证测试)-如果你在你的设备上使用多个帐户，你不确定使用哪一个，只需将它们都添加为测试员。 像往常一样，从Android Studio运行应用程序(*应用程序应该具有与您刚刚上载到内部测试的应用程序相同的版本代码)

我做了上面的事情，它工作得很好。