PAYATHON 2026

Static in-app billing 测试报错 [ RPC:S-7:AEC-0 ]

数据小陈

结论

RPC:S-7:AEC-0 通常不表示 android.test.purchased 商品不存在，而是 Google Play 商店在处理购买请求时，无法确认应用、签名或当前 Google 账号是否有效。这是 Play 商店侧的通用 RPC/账号错误，仅凭错误码无法确定唯一原因。

静态测试商品一般不需要配置真实商品，也不依赖 alpha/beta 渠道发布，但仍需满足这些基本条件：

  • 使用装有 Google Play 商店的真实设备。
  • Google Play 商店已登录有效的 Google 账号。
  • APK 的 package name 与 Developer Console 中的应用完全一致。
  • APK 使用正确且固定的证书签名。
  • Manifest 包含 billing permission。
  • 设备上的 Play 商店、Google Play 服务和账号同步均处于正常状态。

建议先确认本机 APK 是否确实使用了预期的 release keystore，以及设备上是否安装过由其他证书签名的同一应用。

静态商品对测试账号的要求

android.test.purchased 是 Google Play Billing 早期版本提供的保留商品 ID，用于返回“购买成功”的静态响应。例如：

NSString *productId = @"android.test.purchased";

它与真实商品测试的要求不同：

  • 不需要在后台创建 android.test.purchased。
  • 通常不需要将测试账号加入 license tester 列表。
  • 通常不需要先发布到 alpha/beta 测试渠道。
  • 不会产生真实扣款。

不过，购买界面仍由 Google Play 商店提供。设备必须能正常连接 Play 商店，并至少登录一个可正常使用的 Google 账号。账号登录异常、同步失败或 Play 商店缓存损坏，都可能触发 RPC:S-7:AEC-0。

如果测试的是自己在后台创建的真实商品 ID，要求会更严格。应用版本、商品状态、测试轨道、测试账号以及测试计划的加入状态都必须配置正确。

首先核对应用标识和签名

上传到 Developer Console 的 APK 与本机安装的 APK 必须属于同一个应用，package name 要完全一致，不能只核对应用显示名称。

Manifest 中应包含类似配置：

<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.myapp">

    <uses-permission android:name="com.android.vending.BILLING" />

    <application>
        <!-- application configuration -->
    </application>
</manifest>

还要确认 apportable load 生成并安装的是 release 构建，且使用了上传 APK 时的同一份 keystore 和 alias：

BUILD=release \
BUILD_TIMESTAMP=1234567890 \
SIGNING_PUBKEY='base64-public-key-from-developer-console' \
ANDROID_KEYSTORE='/absolute/path/release.keystore' \
ANDROID_KEY_NAME='mykey' \
ANDROID_KEYSTORE_PASS='mypass' \
apportable load

需要逐项确认：

  • BUILD_TIMESTAMP 应填写实际数值，不能使用字面量 numerictimestamp。
  • SIGNING_PUBKEY 应填写 Developer Console 中该应用的 Base64 公钥，而不是签名证书、公钥文件路径或 SHA-1 指纹。
  • ANDROID_KEY_NAME 必须与 keystore 中的 alias 一致。
  • 如果上传 APK 和本地 APK 使用不同证书签名，应先卸载旧版本再重新安装。无法直接覆盖安装，通常就是签名不一致的信号。
  • keystore 密码与 key alias 自身的密码可能不同。是否需要额外参数，取决于所用的 Apportable 版本。

SIGNING_PUBKEY 主要用于校验购买结果的签名。配置错误通常不会导致商品查询失败，但可能使购买结果无法通过校验，因此也需要检查。

清理设备上的 Google Play 状态

如果 package name、permission 和签名均无误，可以按以下顺序检查设备状态：

  1. 卸载当前测试应用。
  2. 打开系统设置，清除 Google Play 商店的缓存和数据。
  3. 必要时清除 Google Play 服务的缓存。
  4. 确认设备的日期、时间和时区正确。
  5. 删除测试用的 Google 账号，然后重新添加。
  6. 打开一次 Google Play 商店，处理可能出现的条款或账号提示。
  7. 重新安装已签名的 release APK。
  8. 再次购买 android.test.purchased。

如果设备登录了多个 Google 账号，Play 商店当前使用的账号可能并非预期账号。测试期间最好暂时只保留一个账号，以排除账号选择和缓存造成的干扰。

模拟器只有使用包含 Google Play 商店且商店能正常运行的系统镜像，才可能完成这类测试。对于较早的 Billing 和 Apportable 环境，建议优先使用真实设备。

区分静态商品测试和真实商品测试

商品查询成功，只能说明 Billing 服务可以识别这个保留 ID，不能证明购买环节涉及的账号、签名和 Play 商店状态都正常。

调用静态商品时，应直接使用保留 ID：

String sku = "android.test.purchased";
String itemType = "inapp";

如果之后改为后台创建的商品，例如：

String sku = "premium_upgrade";

还需检查以下配置：

  • 商品已经激活，不是草稿或停用状态。
  • APK 已上传到适用的测试轨道。
  • 测试账号已加入相应的测试名单。
  • 测试账号已通过邀请链接加入测试。
  • 设备上的应用与后台应用使用相同的 package name 和签名体系。
  • 测试账号不是受发布者账号限制影响的特殊账号，具体规则以当时 Developer Console 的提示为准。
  • 后台配置修改后，已留出时间等待 Google Play 同步。配置通常不会立即在所有设备上生效。

仅将 APK 保存为后台的工作版本或草稿，并不会让真实商品自动对任意账号开放购买。

建议的最小排查路径

不要同时修改测试轨道、商品配置和代码。先用最简单的环境进行验证：

  1. 继续使用 android.test.purchased。
  2. 使用真实 Android 设备。
  3. 确保 Play 商店只登录一个状态正常的 Google 账号。
  4. 核对 package name 是否与后台应用一致。
  5. 确认 APK 包含 com.android.vending.BILLING。
  6. 使用上传版本对应的 release keystore 重新构建。
  7. 卸载旧应用，清除 Play 商店数据，然后重新安装。
  8. 完整记录购买回调、取消回调和错误回调。

如果其他应用也无法通过该账号或设备打开购买界面，问题更可能出在 Google 账号或 Play 商店环境。如果只有当前应用失败，应重点检查 package name、签名、Billing permission 和 Apportable 的 Billing 桥接配置。

RPC:S-7:AEC-0 不能直接对应到某个具体的 Billing 配置项，因此不能据此断定必须配置测试账号或 alpha/beta 渠道。在这个静态商品测试场景中，应先解决签名一致性和设备账号状态问题，再考虑调整发布渠道。

备注：内容仅供参考。