Android Wrapper Operation

Use This During Live Operations

Use this guide when event work may happen on local devices, offline files, or LAN-only tools instead of the live online dashboard. In this guide, Android Wrapper Operation narrows that work to how staff use the Capacitor Android wrapper, permissions, server switching, and recovery during LAN operations. Because this is a runbooks page, read it as part of the EMS LAN learning path rather than as an isolated checklist.

EMS LAN keeps an event moving when internet access is unreliable, but it also creates a second place where event records can change. Read the page for the decision it helps a person make, then use the steps and checks as a steady path from context to action to proof.

What This Runbook Stabilizes

This page is for a pressured moment. Use the sequence to slow the work down, assign ownership, protect records, and leave a clear next step. The intended readers are Android operators and Event leads. If the guide names a dashboard route, service area, export, or record type, treat that name as a pointer to real operational responsibility.

• Primary surface or service: Android APK wrapper and /control-room.
• Records or contracts involved: Native capability state, Remembered server URL, and Notification subscriptions.
• Main care point: Watch for losing track of which file, device, person, or import is trusted while attendee, staff, inventory, POS, or check-in records change offline.
• Proof worth keeping: event ID, snapshot filename, export time, device owner, import summary, sync-history entry, reconciliation count, and supervisor note.

Move From Situation To Handoff

1. Name the live situation: Begin by naming the EMS LAN situation, the owner, and the exact item involved in Android Wrapper Operation.
2. Assign the operator and reviewer: Use Android APK wrapper and /control-room to connect the words on the page to the screen, file, service route, or record that people actually use.
3. Perform the smallest safe action: Keep Native capability state, Remembered server URL, and Notification subscriptions in view so the work stays tied to the records or contracts it can affect.
4. Write the handoff before the next person takes over: Before handing off, save proof such as event ID, snapshot filename, export time, device owner, import summary, sync-history entry, reconciliation count, and supervisor note so the next lead can tell which file and device state are trusted.

The Runbook Is Complete When

You are ready to use the rest of this page when the purpose, owner, affected information, and proof are all clear enough for a second person to review.

1. Scope is named: The work is tied to the correct page, event, report, route, file, person, or record.
2. Impact is understood: The operator can explain the effect on offline files, check-in access, staff rosters, inventory counts, POS totals, and import history.
3. Proof is findable: The handoff points to evidence that the next lead can tell which file and device state are trusted.

End-to-end operator runbook

Use this numbered runbook for Android staff devices.

1. Step 1 - Stabilize the situation. Confirm the LAN host is running and the phone is on the same venue network. This is required before the wrapper can load the hosted app.
2. Step 2 - Choose the current source of truth. Launch the APK and let it try the remembered URL and advertised .local defaults, or enter the host URL manually. This connects the native shell to the server.
3. Step 3 - Execute the scenario path. Sign in, open Control Room, and confirm camera, microphone, notifications, and NFC permission states. This prepares device features.
4. Step 4 - Pause at every risk marker. Prefer HTTPS with the local certificate for media-heavy workflows; use HTTP only with known limitations. This prevents scanner and call surprises.
5. Step 5 - Capture proof before the team moves on. Open the intended workspace route and test the needed feature: scanner, POS scan, communications, notification, call, or NFC. This proves the device is ready.
6. Step 6 - Debrief and hand off unresolved work. If the venue network changes, use Control Room to switch or forget the saved LAN server. This keeps the device recoverable.

Permissions

1. Checkpoint 1. Camera is granted for check-in, POS scanning, and video. Use it to confirm the work is still on the right path.
2. Checkpoint 2. Microphone is granted for voice rooms, intercom, PTT, and video calls. Use it to confirm the work is still on the right path.
3. Checkpoint 3. Notifications are granted for local alerts and call invites. Use it to confirm the work is still on the right path.
4. Checkpoint 4. NFC is granted only for devices that need tag read/write. Use it to confirm the work is still on the right path.