Phase 3 — ChipTool commissioning UI
Layer: Native (no JS)
ChipToolCommissioningActivity is launched with the Matter onboarding payload (QR text from Phase 2). The activity owns all user-facing steps before CHIP starts pairing — there is no Google Play Services Matter system UI in this path.
Call chain
Class: ChipToolCommissioningActivity
| Step | API / input | Behavior |
|---|---|---|
| Intent extra | AppConstants.EXTRA_ONBOARDING_PAYLOAD | Matter QR (MT:…) or manual pairing code |
| Parse | OnboardingPayloadParser.parseQrCode / parseManualPairingCode | Discriminator (long form), setup PIN, vendor/product IDs |
| Wi‑Fi | NetworkCredentials.forWiFi(ssid, password) | Alert dialog; SSID and password required |
| Fabric guard | FabricSessionManager.getCurrentFabric() | Must have groupId, fabricId, rootCa, ipk from Phase 2 |
| ChipClient | Constructor with fabric fields | Registered via FabricSessionManager.setCurrentChipClient before BLE |
| Permissions | BLUETOOTH_SCAN + BLUETOOTH_CONNECT (API 31+) or ACCESS_FINE_LOCATION (older) | Requested before scan if missing |
| Back press | OnBackPressedCallback | Disabled during commissioning to avoid half-paired devices |
Onboarding payload parsing
The activity uses the pure-Kotlin matter.onboardingpayload.OnboardingPayloadParser (not the JNI SetupPayloadParser) so recent connectedhomeip builds work without an extra native parser library.
- QR codes must start with the
MT:prefix. - The long (12-bit) discriminator is always passed to BLE scan and to the Matter SDK, even when the payload uses a short discriminator flag.
What could go wrong
Missing or invalid onboarding payload → activity finishes with COMMISSIONING_ERROR (source: CHIP_TOOL). User cancels the Wi‑Fi dialog → COMMISSIONING_ERROR with cancelled message. BLE permissions denied → error and activity finish. Fabric not stored in FabricSessionManager (Phase 2 failed) → chiptool_status_missing_fabric.