pbl-v7-to-v8-migration

Phase 0: Intent

Announce to the user: "I will migrate this project from PBL 7 to PBL 8."

State that the migration is mechanical rather than architectural. The billing flow, backend integration, and product catalog stay the same. You are renaming classes, updating method signatures, and removing calls that PBL 8 deleted.

If the goal is to land on the current major (PBL 9), use pbl-v7-to-v9-migration instead. It runs this same v7 to v8 work first, then applies the small v8 to v9 delta. PBL 8 itself stops accepting new app and update submissions on August 31, 2027, so prefer going straight to v9 unless you have a reason to stop at 8.

Phase 1: Discovery

Gather the facts before changing anything.

1. Locate the dependency. Open build.gradle, build.gradle.kts, or libs.versions.toml and find com.android.billingclient:billing. Record the current version string.
2. Confirm the effective version. If the version string reads 7.x.x, treat the baseline as PBL 7. If the string is older (for example 5.x or 6.x) but the code still compiles against PBL 7 APIs, also treat the baseline as PBL 7 for this skill. You can migrate directly from 5 or 6 to 8 by following the same steps.
3. Scan for deprecated APIs. Run a repository wide search for every identifier in the rename map in Phase 2. Record every hit. Each hit is a site you must update.
4. Check compile SDK. PBL 8 expects a recent compileSdk. Read build.gradle and note the value. You will bump it in Phase 3 if needed.
5. Note alternative billing usage. Grep for enableAlternativeBilling, AlternativeBillingListener, and AlternativeChoiceDetails. If any hit, the alternative billing rename block in Phase 3 applies.

Report back: "You are on PBL [current]. I found [N] deprecated call sites across [M] files. Planning a direct migration to PBL 8.1."

Phase 2: Plan

Build the checklist. Every item maps to a breaking change from appendix D.

Removed and changed APIs