MobiLauncher

MobiControl setup

The Lockdown Profile bits that matter, with the gotchas. If you've done MobiControl before, the launcher itself is the easy part — the profile config is where you'll spend time.

Two paths

  1. Hosted URL — fastest to start. Lockdown points at our URL, device fetches the launcher every boot. Works on Free + Pro + Ent.
  2. Offline bundle (Pro+) — File Sync pushes the launcher to local storage; Lockdown points at file://. Survives no-network boots.

Use hosted URL for Free tier and for testing. Switch to offline bundle when you have a real fleet running Pro/Ent and a SLA that doesn't tolerate "launcher waited 8 seconds for DNS."

Path 1: Hosted URL

Lockdown Profile → Launcher section

Setting Value
Mode Web URL
URL https://app.mobilauncher.com/t/<your-tenant-id>
Show URL bar No
Allow page zoom Your call (no on a kiosk, yes on a service tablet)
User agent override Leave default
JavaScript Enabled (the launcher is a React SPA)

Lockdown Profile → System UI

Hide the status bar and nav bar — the launcher draws its own header. Leave them on and you get double headers.

Setting Value
Hide status bar Yes
Hide navigation bar Yes
Hide notifications Yes

Lockdown Profile → Permissions

Whitelist any app package names your tile grid launches. If an app tile fires and MobiControl blocks the launch, the launcher shows a toast — but the root cause is here.

Lockdown Profile → Browser settings

The launcher needs cookies (for the per-tenant config cache) and localStorage (for things like dismissed broadcasts).

Setting Value
Cookies Allowed
localStorage Allowed
Cleartext HTTP Up to you — we serve HTTPS, so no need

Path 2: Offline bundle (File Sync)

See offline-bundles.md for the bundle workflow. The MobiControl-side config:

Lockdown Profile → Launcher

Setting Value
Mode Web URL
URL file:///sdcard/mobilauncher/index.html

File Sync section

Same as the bundle doc: source = unpacked launcher/ dir, target = /sdcard/mobilauncher/, mode = Replace.

Permissions to set

Permission Why
Read external storage Launcher reads its own files
Network access Broadcasts polling + (Ent) remote config
Launch installed apps App tile dispatches

If your fleet uses Zebra or Samsung devices and you want agent action tiles (reboot, clearAppData), the MX / Knox SDK permissions show up here too. That's Enterprise tier territory — note that per-OEM SDK certification on physical hardware happens during beta onboarding (see faq.md for current status).

Forcing the launcher to be the home screen

This is the bit MobiControl is for. Lockdown puts the launcher in front of the user with no way out — they tap a tile, the tile runs, the app comes back to the launcher when closed.

Setting Value
Lockdown enabled Yes
Home button intercept Yes (returns to launcher)
Recent apps button Hide
Status bar pull-down Disabled
Power button → power menu Disable if you don't want users to reboot

If you skip Lockdown, the launcher still renders — but the user can swipe down, see Android home, and bail. Don't do that for production.

Updating config

Two patterns depending on path:

Hosted URL path: Customer edits config in Portal. Devices re-fetch on next launcher reload. No MobiControl involvement.

Offline bundle path: Customer downloads a fresh bundle. Replace the File Sync source. MobiControl re-syncs to devices on the next sync window (or you trigger sync from Console).

What MobiControl Console shows you

Once devices are booted into the launcher, MobiControl Console sees them as "running MobiControl Lockdown WebView" — same as any other Lockdown deployment. The launcher itself doesn't expose its own console; that's what our Portal is for.

Common MobiControl-side gotchas

"Tiles render but the apps don't launch when I tap them." Lockdown is blocking the launch. Check that the target package is in the whitelist. The launcher shows an error toast on the tile — the message comes from MobiControl's blocker, not us.

"The launcher works on Wi-Fi but blanks out on cellular." Hosted URL behavior — your cellular APN is probably blocking the domain or the device has no DNS. Switch to the offline bundle path.

"Devices show last week's tile layout instead of today's." Hosted URL path: device's WebView is caching aggressively. We send proper cache-control headers but some MobiControl WebView builds ignore them. Fix: force-reload the launcher (some Lockdown profiles have a hot key for this) or restart the launcher activity from MobiControl Console.

Offline bundle path: File Sync hasn't pushed the new bundle yet. Force-sync from Console.

No MDM? The standalone Android app

For small fleets without MobiControl, we have a sideloadable APK that does the kiosk-WebView job in a single app.

# 1. Build the APK (or grab a prebuilt one from us; coming soon)
cd packages/lockdown-android
./gradlew assembleDebug

# 2. Install on the device (USB debugging on)
adb install -r app/build/outputs/apk/debug/app-debug.apk

# 3. Launch pointed at your tenant
adb shell am start -n com.oakash.mobilauncher.beta/.MainActivity \
  --es url "https://app.mobilauncher.com/t/<your-tenant>"

# 4. Set as default launcher (so the home button stays in our app)
adb shell cmd package set-home-activity com.oakash.mobilauncher.beta/.MainActivity

This is a stopgap for small fleets and a great way to test before you commit MobiControl resources. It does NOT have the full lockdown — power button, volume keys, etc. are still active. For production use on real fleets, MobiControl Lockdown is still the right tool.

We may package this as a real, signed, Play-Store-published app for fleets that want a permanent no-MDM option. Email if that's you.

Sanity check: how do I know it worked?

After applying the profile to a test device:

  1. Device reboots into your launcher (with your deployment name in the header, your tile grid showing)
  2. No status bar, no nav bar
  3. Tapping a tile launches the app or the URL
  4. Home button does nothing (or returns to the launcher)
  5. You can't swipe up to see Android home

If any of those fail, the issue is usually in the Lockdown Profile, not the launcher. See troubleshooting.md.