For manufacturer service teams and authorized administrators. Verify the physical device, vehicle/instrument identity and basis for the service action. When the user can operate the APP, they can remove their vehicle there. Successful cloud unbinding and local APP credential cleanup do not prove revocation on an offline terminal. Before delivery to a new owner, still verify the physical-device cleanup and old-user rejection below.
Choose the recovery path
| Situation | Current handling |
|---|---|
| Lost license file before activation | Re-download the original license when eligible; see production issuance |
| Activated device with intact license storage | Preserve the license; repair firmware/drivers or handle owner binding as appropriate |
| Activated license storage lost/corrupt with no valid controlled backup | No self-service reissue or re-export endpoint; stop delivery and request review by the issuance team |
| Previous owner unavailable, resale or return | Clear local authorization first, reset cloud binding below, then perform nearby new-owner pairing |
| Instrument board replacement | Give the new board its own identity/license, check model compatibility and change installation; do not copy the old board’s license |
Provide only nonsecret device ID/serial number, hardware identity, model, authorization status, fault details and repair evidence to the issuance team. Do not paste licenses, owner tokens or private keys into ordinary tickets.
Clear local authorization first
Console reset does not erase an offline instrument’s owner. Use the target firmware’s controlled service procedure to clear previous-owner authorization and invalidate running Wi-Fi/BLE sessions and caches. After reboot, verify that the old phone cannot authenticate/control the vehicle and that the device license still verifies.
P4 provides factory_license_clear_owner(), but it only clears persistent owner data; it is not a complete live factory-reset operation. The reference provision.py has no service-reset command. If firmware lacks a tested local reset path, the console cannot complete this step; the firmware owner must resolve it before anyone confirms local clearance. See persistence for storage/session requirements.
Reset cloud binding
- Use a platform or matching manufacturer account with
vehicle:binding:reset, and open the vehicle list. Dealers cannot perform this action. - Find the currently bound vehicle, verify VIN, vehicle ID and installed instrument, then select Reset binding.
- Enter a specific reason (1–500 characters). Confirm physical recovery and clearance of previous local authorization only after actually completing the preceding step.
- Submit and refresh the vehicle details to verify no current user binding. Retain the service record.
- Have the new user complete nearby PIN and cloud binding through the APP. Verify old-user rejection and correct new-user permissions.
The endpoint is POST /api/v1/admin/vehicles/{vehicleId}/binding-reset. Read versions from freshly retrieved vehicle details rather than hard-coding them:
{
"version": 12,
"bindingVersion": 3,
"reason": "Return after physical verification and confirmed local authorization clearance",
"terminalAuthorizationCleared": true
}
These versions are illustrative, not executable device data. Stale versions, no current binding, missing permission or missing local-clearance confirmation are rejected. If a response is lost, refresh state first; do not automatically retry using new versions and risk resetting a subsequent binding.
Reset preserves the vehicle, VIN, device license, installation and history. It closes the current binding and revokes cloud owner credentials. It does not reverse license activation or reopen factory-license downloads.
Board replacement and repair
Preserve the original board’s license partition during repair. If replacement is necessary, issue the new board an independent license through production provisioning. Resolve existing user authorization through APP unbind or the service flow above first.
In the vehicle editor’s Instrument field, choose a compatible, active and available replacement and submit the current page versions. The account needs the corresponding vehicle-edit permission and device:install. The backend changes old/new installation transactionally. After failure, refresh and inspect state; do not bypass occupancy/version checks with database edits. Installation changes do not automatically migrate local owner state, license files or user credentials from the old board.
After provisioning and reboot verification, check the vehicle record, installation, APP rebinding, real telemetry and controls. Recover the old board and verify its former authorization cannot continue controlling the delivered vehicle. Flashing firmware alone does not complete replacement.
Key rotation and offline revocation limits
License v1 does not support updating an existing device license or rotating the signing key, and rejects overwriting an installed license with a different one. Suspected signing-key/device-secret exposure requires platform-team handling; do not regenerate platform keys or bulk-erase NVS as a workaround.
Cloud disable/revocation does not make an offline terminal immediately reject previous authorization; cached APP credentials have an offline window. Immediate physical-access revocation requires a tested local reset path and verification that old sessions fail. A changed cloud status is not proof of completed offline revocation.