Android Wrapper Operation

Overview

Android Wrapper Operation: How staff use the Capacitor Android wrapper, permissions, server switching, and recovery during LAN operations. This page is written for event leads, LAN operators, check-in staff, POS staff, roster leads, local admins, and support reviewers, so it uses operational language: what the area is for, what can change, what can go wrong, and what proof another reviewer should expect.

EMS LAN work should be treated as an accountable handoff, not as a private technical action. The source context for this page is fph-lan-ems, partner dashboard Offline Snapshot and Sync History, EMS LAN support routes, and the completed EMS LAN task history.

Scope

Area	What this page covers
Product area	EMS LAN
Docs stage	Runbooks
Practical scope	caller identity, session source, credentials, roles, allowed origins, denied states, and protected routes
Primary outcome	keep an event operating on a trusted local network when internet access is unreliable, then return offline work to the online dashboard with reviewable proof

Online SMS capability boundary

The Android wrapper can expose online-site native capabilities without hardcoding the online pages into the APK. Attendee SMS Blasts are one of those capabilities, but they belong to online mode only.

Mode	SMS campaign behavior	Verification proof
Online Dashboard mode	May report SMS permission state, active SIM inventory, verified sending lines, device health, and leased SMS campaign jobs from the online API.	Device is linked to the partner account, current host is trusted, and the SMS gateway status appears in the online dashboard.
Local LAN mode	Cannot register as an SMS blast device, lease campaign jobs, send attendee SMS campaigns, or access campaign payloads.	LAN operators cannot see attendee SMS campaign controls in local surfaces.

SMS sending requires internet connectivity because jobs, retries, failures, and partner notifications are owned by the online Platform API. Local LAN communications remain separate from SMS Blasts.

When an online SMS job is dispatched, the wrapper starts the online SMS gateway foreground service and records the leased attempt in a capped local outbox before calling Android SmsManager. Android sent and delivery receivers update the same local outbox and append drainable status events. This local evidence does not replace the online API queue, but it lets support distinguish submitted, receiver-confirmed, and locally failed attempts if the page, app, or network is interrupted.

Routes and surfaces

Route or surface	Why it matters	Verification proof
Android APK wrapper	Named product surface or integration context for this page.	Confirm the page, host, event, environment, or integration is the one currently being reviewed.
/control-room	Surface, route, host, or integration context readers should have open while following this page.	Confirm the page, host, event, environment, or integration is the one currently being reviewed.

Page-specific records

Record or contract	What it represents	Verification proof
Native capability state	Record or contract family that can be read, exported, changed, imported, reconciled, or used as support evidence.	Keep the record ID, count, status, timestamp, or owner needed for another reviewer to verify the handoff.
SMS gateway foreground service and local outbox	Online-wrapper-only evidence that SMS dispatch stayed active long enough to submit leased jobs and receive Android result broadcasts.	Foreground service state, outbox counts, attempt ID, message ID, and drained receiver events agree with the Platform API campaign log.
Remembered server URL	Record or contract family that can be read, exported, changed, imported, reconciled, or used as support evidence.	Keep the record ID, count, status, timestamp, or owner needed for another reviewer to verify the handoff.
Notification subscriptions	Record or contract family that can be read, exported, changed, imported, reconciled, or used as support evidence.	Keep the record ID, count, status, timestamp, or owner needed for another reviewer to verify the handoff.

Decision owners

Audience	Responsibility	Verification proof
Android operators	Reader group expected to make or review decisions from this page.	Make sure this group has the required access and escalation path before relying on the workflow.
Event leads	Reader group expected to make or review decisions from this page.	Make sure this group has the required access and escalation path before relying on the workflow.

Mental model

The safe way to use this page is to follow the record, not the screen. A screen, route, file, or response is useful only when staff can connect it to the actor who used it, the record it changed, and the proof that remains afterward.

Use this sequence before relying on the page:

1. Identify the exact event, route, file, account, device, or record family.
2. Confirm which system is the source of truth at this step.
3. Check the role, local account, attendee account, machine token, or service caller.
4. Make the narrowest action that matches the workflow.
5. Verify the result where the next reviewer will look.

Inputs, options, and records to check

Shared item	What it means	Verification proof
Snapshot file	Carries event data into or out of the offline environment.	Event ID, export time, format, file owner, and import history match.
Local SQLite records	Hold LAN-local check-in, claim, POS, inventory, HR, roster, communications, account, and token state.	Local counts are compared to online records after import.
Operator or device identity	Shows who acted in the local environment.	Local user, machine token, Android device, or server operator is named.
Exception notes	Explain manual decisions made while disconnected.	A later reviewer can identify what happened and who owns follow-up.

Operating sequence

Step	Action	Stop if
1	Confirm scope before acting.	The event, file, route, environment, user, or device is unclear.
2	Check authority before changing state.	The actor can view information but should not make this decision.
3	Review the visible option, file, route, or record effect.	The action affects access, money-adjacent records, public information, offline state, or external services without a reviewer.
4	Complete the action only after the expected result is known.	Staff cannot say what success and failure should look like.
5	Save handoff evidence.	The result exists only in memory, chat, or an unsafe screenshot.

Flowchart

flowchart TD
  prepare["<b>Prepare online</b><br/>Confirm event setup, regos, staff, inventory, and roles<br/><i>Docs: Pre-Event Readiness</i>"] --> export["<b>Export snapshot</b><br/>Create the event file and record custody<br/><i>Docs: Export LAN Snapshot</i>"]
  export --> operate{"Operate locally?"}
  operate -- Yes --> lan["<b>Run EMS LAN</b><br/>Use local check-in, claims, POS, inventory, HR, and communications<br/><i>Docs: Operate LAN Check-In</i>"]
  operate -- No --> hold["Hold the file and fix readiness gaps"]
  lan --> import["<b>Import returned file</b><br/>Validate event identity and apply local changes<br/><i>Docs: Import LAN Snapshot</i>"]
  import --> reconcile["<b>Reconcile</b><br/>Compare imported counts, notes, and money-adjacent records<br/><i>Docs: Reconcile After Import</i>"]
  click prepare "/ems-lan/basics/pre-event-readiness/" "Open readiness guide"
  click export "/ems-lan/basics/export-lan-snapshot/" "Open export guide"
  click lan "/ems-lan/basics/operate-lan-check-in/" "Open operation guide"
  click import "/ems-lan/basics/import-lan-snapshot/" "Open import guide"
  click reconcile "/ems-lan/basics/reconcile-after-import/" "Open reconciliation guide"

Verification

Check	Evidence to keep
Scope check	Event ID, route family, file name, record ID, environment, account, or device name.
Actor check	Staff role, attendee account, local user, machine token, service caller, or external system.
Result check	Updated record, imported count, response body, audit entry, local note, sync-history row, or visible status.
Exception check	Warning, skipped row, validation error, denied permission, partial result, or fallback decision.
Handoff check	Named owner and next action for anything unresolved.

Common mistakes

Mistake	Why it causes problems	Recovery
Treating a visible screen as complete proof.	Screens may be filtered, stale, local-only, or scoped to one actor.	Check the underlying record, route evidence, sync history, or audit trail.
Acting without naming the actor.	Permissions and side effects depend on who or what made the request.	Repeat the check with the correct staff role, attendee account, local user, or service caller.
Skipping evidence because the action looked successful.	Support cannot distinguish success, partial success, retry, or workaround later.	Capture timestamp, record ID, result, and reviewer note before closeout.

Related pages

• Pre-Event Readiness
• Export LAN Snapshot
• Operate LAN Check-In
• Import LAN Snapshot
• Reconcile After Import
• EMS LAN Data Records