3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Day 12

STYLY Advent Calendar 2025

@Degly

Device Owner キオスク運用ガイド（デュアルアプリランチャー）

3
Posted at

有料のMDMやデバイスマネージャーを使わなくても、Android標準のDevice Ownerだけでキオスクを無料で構築できることを共有するためにまとめました。

概要

  • Device Owner は Android 標準の管理ロールで、サブスク不要でキオスクロックダウンを実現できる。
  • バックグラウンドサービス + 前景体験のデュアル構成を安全に運用し、更新・復旧・メンテ導線を自社仕様で持てる。
  • 固有名は避け、汎用のパターンとしてまとめています。

課題とゴール

  • 来場者に Home/Recents/通知を触らせず、2 つのアプリを並行・常駐させる。
  • クラッシュや再起動から自動復帰し、スタッフ操作なしで体験に戻す。
  • 200 台超の展開を、ライセンス費やクラウド依存なしで、ブランドやUXを自社制御のまま行う。

Device Owner とは

  • 工場出荷状態の端末に 1 つだけ設定できる管理ロール（複数不可）で、端末全体のポリシーを制御。
  • ロックタスク、デフォルトランチャー固定、セキュア設定変更、権限付与、インストール制御が可能。
  • QR / NFC / ADB など標準プロビジョニングで有効化でき、ライセンス費ゼロ・ベンダーロックインなし。

Device Owner を選ぶ理由

  • コスト最適化: デバイスごとのサブスク不要で、大量・短期展開に有利。
  • セキュリティ: 許可アプリのみ表示し、システムUIを抑止する最小攻撃面。
  • オフライン耐性: クラウドMDM不要。自前エンドポイントやサイドロードで更新可能。
  • ブランド/UX: ランチャーやメンテ導線を自社デザインで統一できる。
  • 運用柔軟性: ウォッチドッグ挙動、更新頻度、退避導線を運用モデルに合わせて設計可能。

本番運用のコアパターン（オーナー型）

  • デフォルトランチャー + ロックタスク: システムランチャーを置き換え、Home/Recents/通知をブロック。許可アプリのみホワイトリスト。
  • 順序付き自動起動: 先にバックグラウンドサービス、次に前景体験を起動。ウォッチドッグで死亡時に再起動。
  • ブート復帰: BOOT_COMPLETED で軽量起動し、サービスに引き渡して電源再投入後も自動復帰。
  • 自動セットアップ: オーナー権限で権限事前付与、画面常時ON、スリープ無効、管理されたインストールを許可。
  • メンテ用退避導線: 隠しジェスチャー + パスワードで退出や限定管理メニューを提供。
  • 現場アップデート: 端末上の「アプリ更新」アクションで署名済みビルドを取得・インストール（ストア非依存）。
  • 多台数プロビジョニング: 標準 QR / ADB でオーナー設定し、バッチスクリプトで APK とポリシーを一括展開。
  • 安全と復旧: オーナー解除にはリセットが必要であることを周知し、工場出荷状態でのセットアップを徹底。

開発・運用で気をつける点

  • 工場出荷状態が前提: アカウント/ユーザーがあるとオーナー設定は失敗。手順に明記し、オペレーションを教育。
  • オーナーは一意: 解除にはリセットが必要。復旧手順とデータ扱いを決める。
  • OEM 差異: ロックタスクやオーバーレイの挙動は端末差があるため、対象機種で早期検証。
  • 更新と署名: 署名キーを維持し、更新URLを検証。ロールバック/再インストール手順を用意。
  • 電源/熱: 常時表示・常駐サービスによる熱と消費電力を検証。
  • 保守導線とログ: 確実な退避ジェスチャー/パスワードと、フィールドでログ取得する手段を用意。
  • プライバシー/法務: ロックダウン挙動やリモートアクセス（例: ADB）を関係者に明示。

よく使う ADB コマンド（汎用）

# オーナー確認
adb shell dpm list-owners

# オーナー設定（工場出荷状態・ユーザーなしが必須）
adb shell dpm set-device-owner com.example.kiosk/.KioskDeviceAdminReceiver

# ロックタスクの確認
adb shell dumpsys activity activities | grep -i "lock.*task"

# ランタイム権限を付与（オーナー権限）
adb shell cmd package grant com.example.kiosk android.permission.RECORD_AUDIO

# 充電中は画面ON（AC+USB+無線=7）
adb shell settings put global stay_on_while_plugged_in 7

# ADB有効化（オーナーのみセキュア設定を書ける）
adb shell settings put global adb_enabled 1

# 強制停止して自動再起動を確認
adb shell am force-stop com.example.background

押さえておきたい Android API / コンポーネント

  • DevicePolicyManager: ロックタスク、ランチャー固定、権限付与、セキュア設定変更などオーナー系ポリシーの中心。
  • ComponentName + 永続優先アクティビティ: HOME を自分のランチャーに固定し、システムランチャーを出さない。
  • startLockTask() / setLockTaskPackages(): Home/Recents/通知をブロックする没入ロックダウン。
  • DownloadManager + FileProvider: 安全なアプリ内アップデート（独自HTTP不要）。
  • フォアグラウンド Service のウォッチドッグ: バックグラウンド/前景プロセスを監視し、死亡時に再起動。
  • BOOT_COMPLETED レシーバ: 再起動後の復帰フローを開始。処理は軽くし、サービスへ委譲。
  • 隠しメンテ導線: ジェスチャー + パスワードで退出や限定管理画面を提供。

まとめ

  • Android 標準の Device Owner だけで商用レベルのロックダウンが可能。追加ライセンスは不要。
  • 成功の鍵は、工場出荷状態・既存オーナー/ユーザーなしで確実にオーナー設定を通すこと。
  • 標準の QR / ADB プロビジョニングだけで十分。スクリプトは多台数での効率化に有効。
  • ゲストには複雑さを隠しつつ、運用者には安全で確実なメンテ・更新経路を用意する。

Device Owner Kiosk Playbook (Dual-App Launcher)

We wrote this to share that you don’t need paid MDM/device-manager subscriptions to ship a locked-down kiosk. Android’s built-in Device Owner is enough to achieve the same control for free.

Executive summary

  • Device Owner is a built-in Android role that delivers full kiosk lockdown without paid MDM licenses.
  • You can run a dual-app LBE experience (background service + foreground experience) with controlled updates, recovery, and maintenance access.
  • The patterns below stay generic so you can adapt them to your own app names and infrastructure.

Problem and goals

  • Prevent guests from reaching Home/Recents/notifications while two apps run side by side.
  • Survive crashes, app kills, and reboots; always return to the experience without staff action.
  • Scale to 200+ devices without per-device fees or cloud lock-in; keep UX and branding under your control.

What is Device Owner

  • A single admin role on a factory-reset device that governs policies for the whole device (only one owner allowed).
  • Controls lock task, default launcher binding, secure settings, permission grants, and install/uninstall rules.
  • Activated through standard Android provisioning (QR, NFC, or ADB); zero licensing cost and no vendor dependency.

Why choose Device Owner for kiosk use

  • Cost control: no subscription fees; ideal for fleets or seasonal deployments.
  • Security posture: least-privilege surface—only whitelisted apps appear, system UI is suppressed.
  • Offline resilience: works without cloud MDM; updates can be sideloaded or hosted on your endpoints.
  • Brand and UX: launcher, menus, and maintenance flows follow your design, not a third-party agent.
  • Operational flexibility: you decide watchdog behavior, update cadence, and escape hatches to match your ops model.

Core patterns for a production kiosk (owner-based)

  • Default launcher + lock task: replace the system launcher, block Home/Recents/notifications, and whitelist only allowed apps.
  • Sequenced auto-launch: start the background service first, then bring the foreground experience forward; add a watchdog to restart either process on death.
  • Boot resilience: register boot receivers and hand off to services so the stack relaunches after power cycles without taps.
  • Auto-configuration: as owner, pre-grant runtime permissions, keep the screen awake while plugged in, disable sleep, and allow managed installs.
  • Maintenance escape hatch: hidden gesture + password to exit or open a limited admin menu for updates/troubleshooting.
  • In-field updates: on-device “update apps” action that downloads and installs signed builds for the kiosk shell and companion apps (no store dependency).
  • Fleet provisioning: rely on stock QR or ADB owner assignment; batch scripts can fan out APK installs and policies to many devices.
  • Safety and recovery: document how to clear owner (requires reset) and ensure devices stay in factory-reset state before provisioning.

Operational considerations when building your own

  • Factory-reset prerequisite: owner assignment fails if any user/accounts exist—train ops and document the requirement.
  • Single-owner rule: only one owner; clearing it requires a reset. Plan recovery paths and data handling.
  • OEM variance: lock task, overlays, and gestures can differ—test on target hardware early.
  • Updates and signing: keep consistent signing keys; validate update URLs; define rollback or reinstall steps.
  • Power/thermal: always-on screens and services need thermal and power validation for your device class.
  • Access and logging: ensure a reliable maintenance gesture/password and a way to pull logs in the field.
  • Privacy/legal: disclose lockdown behavior and any remote access you enable (e.g., ADB).

Handy ADB commands (generic)

# Confirm owner is set
adb shell dpm list-owners

# Set owner (must be factory-reset, no users/accounts)
adb shell dpm set-device-owner com.example.kiosk/.KioskDeviceAdminReceiver

# Check lock task whitelist
adb shell dumpsys activity activities | grep -i "lock.*task"

# Grant a runtime permission (owner privilege)
adb shell cmd package grant com.example.kiosk android.permission.RECORD_AUDIO

# Keep screen awake while plugged in (AC+USB+wireless = 7)
adb shell settings put global stay_on_while_plugged_in 7

# Enable ADB (requires owner to write secure settings)
adb shell settings put global adb_enabled 1

# Force-stop an app and observe watchdog recovery
adb shell am force-stop com.example.background

Key Android APIs and components

  • DevicePolicyManager: owner policies—lock task, launcher binding, permission grants, secure settings.
  • ComponentName + persistent preferred activity: pin your launcher as HOME to suppress the system launcher.
  • startLockTask() / setLockTaskPackages(): enforce immersive lockdown to block Home/Recents/notifications.
  • DownloadManager + FileProvider: safe in-app updates without custom HTTP stacks.
  • Foreground Service as watchdog: monitor background/foreground processes and relaunch on death.
  • BOOT_COMPLETED receiver: relaunch your stack after power cycles; keep it light and defer to services.
  • Hidden maintenance path: gesture listener + password dialog to exit or open a limited admin screen.

Takeaways

  • Production-grade lockdown is achievable with stock Android Device Owner—no paid kiosk/MDM needed.
  • Success depends on factory-reset devices, clean user/account state, and owner assignment that never fails.
  • Standard QR or ADB provisioning is enough; scripts help at scale but aren’t mandatory.
  • Hide complexity from guests, but keep clear, secure maintenance and update paths for operators.
3
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?