Android 项目从旧版 Google Play…

适用于任何使用旧版 Google Play Billing Library 的 Android 项目，将其升级或迁移到最新稳定版 PBL。

适用场景

解决思路

1. Phase 0：开始前立即告诉用户：“我将把 Play Billing Library 升级到最新版本。”
2. Phase 1.1：在 build.gradle、build.gradle.kts 或 libs.versions.toml 中定位项目的计费依赖（例如 com.android.billingclient:billing）。
3. Phase 1.2：立即尝试同步并构建项目。
4. Phase 1.3：仅当构建立即失败时，扫描源代码中的已废弃产物。
5. Phase 1.3：已废弃 API 的存在表示“Effective Version”，其定义为这些特定 API 最后可用的版本，而不是它们被引入的版本。
6. Phase 1.3：例如，如果存在 SkuDetails，则将基线视为 PBL v7 或更早（无论 build.gradle 中的版本字符串是什么）。
7. Phase 1.4：访问版本工具或 release notes，找到最新稳定版本，并基于 Effective Version 基线计算 [Direct/Stepped] 迁移路径。
8. Phase 1.4：如果 Effective Version 与目标版本相差不超过 2 个大版本，计划 Direct Migration。
9. Phase 1.4：如果落后超过 2 个大版本，计划 Stepped Migration；每次迁移两个大版本（例如 v4 -> v6 -> v8），直到进入目标版本的 2 个大版本范围内。
10. Phase 1 Reporting：继续前告诉用户：“我检测到你当前有效版本是 PBL [Current]，最新是 [Target]。我计划采用 [direct/stepped] 迁移路径。”
11. Phase 2：对于路径中识别出的每一个大版本跳跃，必须综合以下来源的说明：
12. Phase 2：Migration Guide（其中 [X] 是目标大版本）：https://developer.android.com/google/play/billing/migrate-gpblv[X]。
13. Phase 2：Release Highlights：相关 Release Notes（references/android/google/play/billing/release-notes.md）的 Deprecations 和 Breaking Changes 部分。
14. Phase 2：Developer Documentation：结合你掌握的 Google Play Billing 文档中与该应用所用相关功能（例如 Subscriptions、One-Time Products）有关的知识。
15. Phase 2：制定计划：识别每一个具体代码变更（API 移除、类替换、逻辑变化），并将其打印为 checklist。
16. Phase 3 Reporting：对于以下每个步骤，在执行前简要说明将要做什么，在执行后简要总结完成了什么。
17. Step 1：更新 build.gradle 以满足 SDK 要求（例如 PBL 9 要求 compileSdk 35）。
18. Step 1：验证新库是否需要更新的 Android Gradle Plugin (AGP) 或 Kotlin 版本。
19. Step 2：分析现有代码的意图，而不是进行纯文本字符串替换。
20. Step 2：必须遵循来自 references/migration-logic.md、官方 migration guides、以及 Phase 2 中识别出的通用文档页面中的所有废弃说明和重构模式。
21. Step 2：验证是否完成了所有文档中的所有步骤，然后确保遵循 references 中 checklist 的具体指示。
22. Step 3：仅适用于 Stepped Migrations：升级到路径中的第一个大版本中间版本。
23. Step 3：运行 ./gradlew assembleDebug，以验证没有遗漏中间破坏性变更。
24. Step 3：重复直到达到最终目标版本。
25. Step 4.1：打开 references/version-checklist.md，找到 Smart Version-Specific Checklist。
26. Step 4.1：针对 [Detected Effective Version] 和 [Detected New Version] 之间的每一个版本，使用 Find in Files 或结构分析验证每一项都已在代码中处理。
27. Step 4.2：运行所有单元测试和实现测试（./gradlew test）。
28. Step 4.3：验证项目完成完整 clean build：./gradlew clean assembleDebug。然后运行 ./gradlew sync 和 ./gradlew build，以便用户可以立即手动测试新版本。
29. Final Report：向开发者解释“为什么”。
30. Final Report：说明将 SDK 更新到 [Version]，因为 PBL [Version] 为 [Reason from docs] 要求这样做。
31. Final Report：说明移除了自定义 retryConnection() 逻辑，因为库现在通过 enableAutoServiceReconnection() 原生处理。
32. Final Report：说明已从 PBL [Old] 成功升级到 PBL [New] 并通过单元测试验证；基于最新库功能和应用当前功能集分析，建议探索 [New Feature]（例如 Prepaid Plans 或 Installments），因为它现已可用但尚未实现。

适用边界 · 注意事项

• 不适用于非 Android 项目。
• 不适用于不使用 Google Play Billing Library 的项目。
• 不适用于已经是最新稳定版 PBL 且无需迁移的项目，或迁移非 Google Play Billing 的其他计费/支付 SDK。