play-billing-library-version-upgrade

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Phase 0: Intent Message

阶段0：意向通知

Reporting Action: Before proceeding, immediately tell the user: "I will upgrade Play Billing Library to the latest version."

汇报操作：开始前，立即告知用户："我将把Play Billing Library升级至最新版本。"

Phase 1: Discovery & Situational Awareness

阶段1：发现与场景感知

Primary Check (Build Version) : Locate the project's billing dependency (e.g.,
```
com.android.billingclient:billing
```
) in
```
build.gradle
```
,
```
build.gradle.kts
```
, or
```
libs.versions.toml
```
.
Initial Compilation Test: Attempt to sync and build the project immediately.
Fallback Discovery (Effective Version) :
- Trigger: Only if the build fails immediately, scan the source code for deprecated artifacts.
- Logic : The presence of deprecated APIs indicates the "Effective Version" ---defined as the version where those specific APIs were last available, not when they were introduced.
- Example : If
```
SkuDetails
```
  is present, treat the baseline as PBL v7 or earlier (regardless of the version string in
```
build.gradle
```
  ).
Identify Target & Path: Access the version tool or release notes to find the latest stable version and calculate a [Direct/Stepped] migration path based on the Effective Version baseline.

Calculate Migration Path :
- If the Effective Version is within 2 major versions of the target: Plan a Direct Migration.
- If it is more than 2 major versions behind: Plan a Stepped Migration. Migrate by two major versions at a time (e.g., v4 -> v6 -> v8) until you are within two versions of the target.
Reporting Action: Before proceeding, tell the user: "I've detected you are effectively on PBL [Current] and the latest is [Target]. I am planning a [direct/stepped] migration path."

主要检查（构建版本）：在
```
build.gradle
```
、
```
build.gradle.kts
```
或
```
libs.versions.toml
```
中找到项目的billing依赖（例如
```
com.android.billingclient:billing
```
）。
初始编译测试：立即尝试同步并构建项目。
备选发现（实际版本）：
- 触发条件：仅当构建立即失败时，扫描源代码中的已弃用构件。
- 逻辑：已弃用API的存在表明了"实际版本"——定义为这些特定API最后可用的版本，而非其引入版本。
- 示例：如果存在
```
SkuDetails
```
  ，则将基准版本视为PBL v7或更早版本（无论
```
build.gradle
```
  中的版本字符串是什么）。
确定目标与路径：访问版本工具或发布说明，找到最新稳定版本，并基于实际版本基准计算[直接/分步]迁移路径。

计算迁移路径：
- 如果实际版本与目标版本的主版本差距在2以内：规划直接迁移。
- 如果落后超过2个主版本：规划分步迁移。每次升级2个主版本（例如v4 -> v6 -> v8），直到与目标版本的差距在2以内。
汇报操作：开始前，告知用户："我检测到你当前实际使用的是PBL [当前版本]，最新版本是[目标版本]。我将规划[直接/分步]迁移路径。"

Phase 2: Contextual Document Mapping & Planning

阶段2：关联文档映射与规划

For every major version jump identified in your path, you MUST synthesize instructions from:

Migration Guide (where
```
[X]
```
is the target major version).
Release Highlights : The "Deprecations" and "Breaking Changes" sections of the relevant Release Notes.
Developer Documentation: Consult your knowledge of the Google Play Billing documentation regarding the relevant features used in this app (e.g., Subscriptions, One-Time Products).
Develop the Plan: Identify every specific code change required (API removals, class replacements, logic shifts) and print this out as a checklist.

对于路径中每个确定的主版本跳跃，你必须综合以下来源的说明：

迁移指南（其中
```
[X]
```
是目标主版本）。
发布亮点：相关发布说明中的"弃用项"和"重大变更"部分。
开发者文档：参考你所掌握的Google Play Billing文档中与该应用使用的相关功能（例如订阅、一次性产品）的内容。
制定计划：确定所有需要的具体代码变更（API移除、类替换、逻辑调整），并将其打印为检查清单。

Phase 3: Instructions for Execution

阶段3：执行说明

Reporting Action: For each of the following steps, give a brief explanation of what you will be doing prior to execution, and a brief summary of what you accomplished afterwards.

汇报操作：对于以下每个步骤，在执行前简要说明你要做什么，执行后简要总结完成的内容。

Step 1: SDK & Environment Alignment

步骤1：SDK与环境对齐

Action : Update
```
build.gradle
```
to meet SDK requirements (e.g., "PBL 8 requires
```
compileSdk
```
35").
Gradle Version: Verify if the new library requires a newer Android Gradle Plugin (AGP) or Kotlin version.

操作：更新
```
build.gradle
```
以满足SDK要求（例如"PBL 8要求
```
compileSdk
```
为35"）。
Gradle版本：验证新库是否需要更新的Android Gradle Plugin（AGP）或Kotlin版本。

Step 2: Intent-based Refactoring

步骤2：基于意图的重构

Analyze the intent of the existing code rather than performing purely textual string replacement.

Action : You MUST follow all deprecation instructions and refactor patterns from both the references/migration-logic.md section, the official migration guides, and the general documentation pages identified in Phase 2.
Verification : Verify you are doing all steps from all documentation and then making sure you follow the specific directions from the checklist in the references.

分析现有代码的意图，而非仅执行纯文本字符串替换。

操作：你必须遵循[references/migration-logic.md]部分、官方迁移指南以及阶段2中确定的通用文档页面中的所有弃用说明和重构模式。
验证：确认你已完成所有文档中的所有步骤，并确保遵循参考资料中检查清单的具体指示。

Step 3: Sequential Verification (Only applicable for Stepped Migrations)

步骤3：顺序验证（仅适用于分步迁移）

Upgrade to the first major intermediate version in your path.
Run
./gradlew assembleDebug
to verify no intermediate breaking changes were missed.
Repeat until you reach the final target version.

升级至路径中的第一个主中间版本。
**运行
```
./gradlew assembleDebug
```
**以确认没有遗漏中间的重大变更。
重复上述步骤，直到达到最终目标版本。

Step 4: Final Validation Checklist

步骤4：最终验证清单

Smart Checklist Verification:
Open references/version-checklist.md and locate the Smart Version-Specific Checklist.
Action: For every version between your [Detected Effective Version] and [Detected New Version], verify that every item has been addressed in the code using "Find in Files" or structural analysis.
Tests : Run all unit and implementation tests (
```
./gradlew test
```
).
Clean Build : Verify the project completes a full clean build:
```
./gradlew clean assembleDebug
```
. Then, run
```
./gradlew sync
```
and
```
./gradlew build
```
so that the user can immediately test the new version manually.

智能清单验证：
打开[references/version-checklist.md]，找到智能版本特定清单。
操作：对于[检测到的实际版本]与[检测到的新版本]之间的每个版本，使用"查找文件"或结构分析确认代码中已处理所有项。
测试：运行所有单元测试和实现测试（
```
./gradlew test
```
）。
清理构建：验证项目完成完整的清理构建：
```
./gradlew clean assembleDebug
```
。然后运行
```
./gradlew sync
```
和
```
./gradlew build
```
，以便用户可以立即手动测试新版本。

Final Report

最终报告

Explain the "Why" to the developer:

"I updated your SDK to [Version] because PBL [Version] requires it for [Reason from docs]."
"I removed your custom
```
retryConnection()
```
logic because it is now handled natively by the library using
```
enableAutoServiceReconnection()
```
."
"Successfully upgraded from PBL [Old] to PBL [New] and verified with unit tests. Based on an analysis of features in the latest library and this application's current feature set, I suggest exploring [New Feature] (e.g., Prepaid Plans or Installments) from the latest release because it is now available but not yet implemented."

向开发者解释"原因"：

"我将你的SDK更新至[版本]，因为PBL [版本]需要它来[文档中的原因]。"
"我移除了你的自定义
```
retryConnection()
```
逻辑，因为现在库已通过
```
enableAutoServiceReconnection()
```
原生处理该功能。"
"已成功从PBL [旧版本]升级至PBL [新版本]，并通过单元测试验证。基于对最新库功能和本应用当前功能集的分析，我建议探索最新版本中的[新功能]（例如预付费计划或分期付款），因为该功能现已可用但尚未在应用中实现。"