我在关注这些文章：Verifying Back-End Calls from Android Apps and Stopping Vampires using License Verification Library (from 24:57 to 25:34) to implementation an In-App Purchase verification system for our Android apps。
我有点困惑这是如何端到端工作的，以及我们可以假设通过使用找到的第一个电子邮件地址调用GoogleAuthUtil.getToken()生成的令牌- 当 AccountManager 返回多个帐户时。我的问题如下：
我们是否应该假设用户用于购买我们的应用程序的任何电子邮件地址都会生成相同的令牌（即，相同的用户 + 应用程序 ==> 相同的令牌）？
如果问题 1 的答案是否定的，有没有办法为特定帐户/电子邮件启动应用内购买？
看起来 Google 正在为其应用内购买对话框选择 AccountManager 返回的第一个电子邮件地址。我们可以假设启动应用内购买对话框后用户不会更改此设置吗？我们如何确定在应用内购买返回后这是否发生了变化？
我们应该在数据库中存储什么来识别这个用户？是否允许使用电子邮件地址和/或令牌？令牌何时到期？
乍一看，java-client 库看起来很有前途且功能强大。但是，许多事情仍然令人困惑。是否有文章描述了端到端场景——从应用程序发起对后端服务器的调用到启动应用程序内购买对话框、获取结果并在服务器上提交并关闭？
哪些文章对于在 Android 上完成此任务最有用？
我们试图解决的主要问题是全面了解情况。
我们的想法是，我们可以通过使用 java 客户端功能和使用令牌来避免要求用户 ID/密码。我们已经按照 Google API 控制台的说明注册了我们的项目（Web 应用程序和 android 应用程序都在同一个项目上）。我们的后端服务器上有用于 Google Play 服务的 php java-client。我们让我们的 Android 应用使用第一个电子邮件地址生成令牌，然后调用应用内购买对话框并在对话框结束时处理用户响应。我们有零件。现在，我们需要将所有东西粘合在一起。我们正处于与后端服务器集成的阶段。例如，Redirect URI 应该在我们的服务器中指向什么？我们有一个 php url，我们为我们的服务器应用程序执行 http 发布消息。我们已经包含了 Google API 客户端示例的代码示例——带有客户端 ID、秘密、简单的 api 密钥等填写 - 作为我们 php.ini 的包含。但是，我们应该在重定向 uri 中添加什么（我们缺少示例代码的使用说明）？
此外，我们希望避免用于应用内购买的电子邮件与我们在服务器数据库中作为用户购买应用的地址登录的电子邮件不同；如果地址是正确的跟踪地址，我们希望它与用于购买的地址相同。如果我们犯了这个错误并阻止他们使用他们支付的功能，这可能会让我们的用户感到沮丧。我们不想犯这个错误，需要澄清一下 Google Play 服务的工作原理。如果我们启动工作流的服务器部分以获取 Android 设备上第一个电子邮件地址的应用程序 Nonce / Payload / Credentials，我们希望在整个工作流中使用该地址。如果用户沿线更改了这一点，我们希望意识到这一点并优雅地恢复。到目前为止，这些文章很有帮助，但不完整。