Enrollment and Provisioning

Enrollment and Provisioning

There are two ways a device becomes managed: direct enrollment (sign in and it registers), and token provisioning (pre-register by IMEI, then the device claims a token).

Direct enrollment (the simple path)

When a user signs into the app, EnrollmentManager:

1. Derives a stable hardware ID (IMEI → serial → Android ID, then cached so it never changes).
2. Writes/updates /devices/{hardwareId} with model, OS, deviceUid (the signed-in UID), and lastSeen.
3. If the document doesn't exist yet, it's created with ownerId = the signing-in user. If it exists, only non-ownership fields are updated (so an admin-assigned ownerId is preserved).

Note (fixed in v0.3.2): a brand-new device's first update() can come back as PERMISSION_DENIED rather than NOT_FOUND (the update rule can't read a doc that doesn't exist). The app now treats that as "create", so new devices enroll correctly.

After enrollment the device appears in the owner's console and MdmCommandService begins listening.

Token provisioning (super-admin)

For controlled rollouts, the super-admin can pre-register devices and hand out one-time tokens.

Collections

• device_inventory/{imei} — a pre-provisioning record with an enrollmentStatus (PENDING → ENROLLED → DISENROLLED) and token fields.
• enrollment_tokens/{token} — the 32-char random token is the secret; any signed-in device can look it up, only the super-admin can create one, and the device deletes it after use.

Flow

1. Super-admin opens the Admin panel → pre-register a device by IMEI, which issues a token.
2. The token is delivered to the device (QR/manual).
3. The device verifies the token client-side and marks its inventory record ENROLLED (the rules allow exactly that PENDING → ENROLLED transition).
4. The device consumes (deletes) the token.

Admin actions in the console

Issue/copy token, renew token, mark enrolled/disenrolled, block/unblock, delete record.

Hardware ID & identifiers

• IMEI/serial need privileged access (Device Owner); without it the app falls back to Android ID.
• The derived ID is cached in SharedPreferences so it's stable across permission/reboot changes and is used as the Firestore document ID.

Related

• Firestore Data Model — device_inventory, enrollment_tokens schemas
• Security Rules — who can read/write tokens and inventory
• Device Owner Setup — QR/NFC provisioning as Device Owner