Androidキオスク設定:デバイス所有者が設定画面をロックした場合の対処法
A10.1インチ Android タブレット aDB、カスタムランチャー、およびデバイスオーナーを用いてキオスク用途向けに設定されました。再起動後、アプリケーションは期待通りに起動しましたが、デバイスは通常の Android 設定画面にアクセスできなくなりました。
これはキオスク展開においてよくある課題です。システムのナビゲーションやデバイス管理機能が制限された状態で、タブレットをさらにテストするための復旧はどのように行えばよいでしょうか?また、アプリケーションが Wi-Fi その他のシステム機能を開こうとする場合、どの Android Intent を引き続き使用できるのでしょうか?
顧客はまず、ADB コマンドを用いてシステム UI の動作を変更しました:
adb shell settings put system hide_navbar 1
adb shell settings put system statusbar_disp 1
adb shell settings put system swipe_show_nav_bar 0
adb shell settings put system power_button_show 0
その後、アプリケーションを既定のホーム画面として設定し、「デバイスオーナー」として設定しました。 デバイスオーナー 必要なデバイス管理機能を有効化するため。
再起動後、 Androidキオスクタブレット アプリケーションが予定通り自動起動しました。しかし、顧客はアプリケーションのメイン画面から抜け出してAndroidの設定やその他のシステム機能にアクセスできなくなりました。アプリ内に組み込まれた「設定」および「Wi-Fi」ボタンも、対応するシステム画面を開かなくなりました。
当初の課題は単にアプリケーションから抜ける方法を見つけることではありませんでした。顧客は、今後のテストのためにこの アンドロイドタブレット を確実に復旧できる手段を必要としていたほか、自社アプリケーションで利用可能なシステムIntentについても理解したいと考えていました。
Androidタブレットへのアクセスが困難になった理由
この問題は、複数のレイヤーにわたるデバイス制御機能が同時に適用されたことに起因していました。
カスタムランチャーは、ホーム画面にどのアプリケーションを表示するかを決定しました。一方、デバイスオーナーは、アプリケーションに対してデバイスのポリシーを広範囲に制御する権限を付与します。Androidの専用端末向けドキュメントでは、キオスクや管理対象端末の展開に適したこの種の設定をサポートしており、たとえばデフォルトのホームアプリケーションの制御や、システム機能へのアクセス制限などが含まれます。
ADBコマンドは、システムUIの動作を変更することで、さらに別の制御層を追加しました。これらの設定は、汎用的なAndroid APIではなく、端末またはファームウェアに依存するものであるため、その具体的な効果は、タブレットのファームウェアがどのように実装しているかに左右されます。
これはつまり、 キオスク端末として使用されるAndroidタブレット において、ランチャー、デバイスオーナー設定、システムUI制限、およびアプリケーション内ナビゲーションのすべてが同時に変更された場合、復旧が困難になる可能性があることを意味します。
アプリの「設定」または「Wi-Fi」ボタンが機能しなくなったからといって、そのインテント自体が不正であるとは限りません。対象となる設定アクティビティは、現在の端末構成において利用不可・制限されている、あるいは他の理由でアクセスできない可能性があります。Androidでは、インテントを起動する前に、その解決(resolve)が可能かどうかを事前に確認することを推奨しています。

ロックされたAndroidキオスクタブレットの復旧方法
アプリケーションがすでにデバイス所有者(Device Owner)として設定済みの場合、ソフトウェアによる復旧をまず検討してください。
Androidの DevicePolicyManager は、デバイス所有者が利用可能なデバイス管理機能を提供します。Androidのバージョンおよびアプリケーションの設定に応じて、デバイス所有者アプリケーションは適切なデバイスワイプ機能を用いて、テスト用にタブレットをクリーンな状態へ戻すことができます。 wipeData() はユーザー データをワイプするための標準APIですが、新しいAndroidバージョンでは追加のデバイスワイプ機能も提供されています。
非推奨となった clearDeviceOwnerApp() この方法は、一般的な生産環境での復旧手段としては扱ってはいけません。Androidの公式ドキュメントでは、これは主にテスト目的で提供されるAPIであり、デバイス所有者関係を解除する標準的な方法は工場出荷状態へのリセット(ファクトリーリセット)であると明記されています。
ADBにはデバイスポリシー管理コマンドも用意されていますが、これらには制限があります。例えば、 adb shell dpm remove-active-admin は、デバイス所有者を解除するための汎用的な手段ではなく、AndroidのADBドキュメントでは、対象アプリケーションが testOnly 属性を宣言していることなどの条件が明記されています。
ソフトウェアによる復旧が不可能な場合(アプリケーションが所定の操作を実行できない場合)は、残された手段は ハードウェアによる工場出荷状態へのリセット、またはAndroidのリカバリ手順です。 .
リカバリモードへの進入に必要なボタン操作は、他のAndroidタブレットのモデルから推測してはいけません。リカバリ動作は、各タブレットのファームウェアおよびハードウェア実装によって決まります。したがって、カスタマイズされたAndroidタブレットプロジェクトでは、実際の機種およびファームウェアに対して適切なリカバリ手順を、導入前に必ず確認してください。
このようなタイプの Androidキオスクタブレット 回復方法が明確に定義されていることは、統合テスト中に特に有用です。これは、システムレベルの設定によって通常のユーザーによるナビゲーションが意図的に無効化される場合があるためです。
Androidタブレットにおける設定インテントおよびシステム機能のテスト
顧客の2つ目の質問は、アプリケーションが「設定」や「Wi-Fi」などのシステム機能を直接起動できるかどうかでした。
これらの機能には、Androidが標準で提供する設定アクションが用意されています。たとえば:
|
機能 |
標準Androidインテント |
|
メイン設定 |
Settings.ACTION_SETTINGS |
|
Wi-Fi設定 |
Settings.ACTION_WIFI_SETTINGS |
|
ワイヤレス設定 |
Settings.ACTION_WIRELESS_SETTINGS |
|
Bluetoothの設定 |
Settings.ACTION_BLUETOOTH_SETTINGS |
|
ディスプレイ設定 |
Settings.ACTION_DISPLAY_SETTINGS |
|
位置情報の設定 |
Settings.ACTION_LOCATION_SOURCE_SETTINGS |
|
サウンドの設定 |
Settings.ACTION_SOUND_SETTINGS |
|
セキュリティの設定 |
Settings.ACTION_SECURITY_SETTINGS |
|
アプリの設定 |
Settings.ACTION_APPLICATION_SETTINGS |
|
アプリの設定 |
Settings.ACTION_APPLICATION_DETAILS_SETTINGS |
これらは、特定の Androidタブレットメーカー固有のインターフェースではなく、標準的なAndroid設定アクションです。 ただし、Intentが存在しても、すべての端末やすべてのキオスク構成で確実に起動するとは限りません。Androidでは、起動前に resolveActivity() メソッドでIntentを確認することを推奨しています。
システム統合型Androidタブレットの場合、Intentのテストは、実際に展開に使用されるファームウェアおよびAndroidバージョン上で行う必要があります。テストでは、Intent自体の存在確認に加え、デバイスオーナー設定、ランチャーやシステムUIの制限を適用した後に、対応するActivityに正しく到達できるかも検証する必要があります。
Androidキオスクタブレットまたはシステム統合プロジェクトを担当されており、デバイスオーナーの復旧、設定インテント、および関連する構成問題についてご支援が必要な場合は、タブレットの機種名とAndroidバージョンをお知らせください。技術サポートおよびカスタマイズ可能なオプションについて、ご相談させていただきます。
他のシステム機能にも同様の原則が適用されます。標準的なAndroid APIは存在しても、実際のカスタマイズ済みタブレットの動作は、そのAndroidバージョン、ファームウェアの構成、およびデバイスマネジメントポリシーに依存します。
「ウェイクリクエスト」については?
お客様がお尋ねの「ウェイクリクエスト」とは、設定画面を起動することとはやや異なります。
Intent.ACTION_SCREEN_ON は、画面がインタラクティブ状態になったことを示すシステムブロードキャストです。これは保護されたシステムブロードキャストであるため、アプリケーションはこれを単に送信してタブレットを起動できるような通常のインテントとして扱ってはなりません。
要件が以下のいずれかの場合: 画面を起動する、画面を常時オン状態に保つ、または画面のオン/オフ動作を制御する 、適切なメカニズムは、具体的なアプリケーション要件によって異なります。Android では、こうしたシナリオに対応するため、電源管理およびウィンドウ/アクティビティに関する API を提供しており、その一例として PowerManager および必要に応じたウェイクロック機能があります。
この区別は、 Androidキオスクタブレット 向けのアプリケーションを開発する際に重要です。「システム機能を起動する」と「デバイスの電源状態を制御する」は、異なるシステム操作であり、それぞれ専用の API を用いて処理する必要があります。

Android タブレット連携に関する技術サポート
この事例はまた、キオスク展開が Android タブレットの基本的なハードウェア構成だけでは不十分である理由も示しています。
タブレットを専用アプリケーション、POS システム、キオスク、産業用システム、またはその他の管理対象デバイスに統合する際には、ランチャーやデバイスオーナー、システム UI、アプリケーション権限、設定インテント、および復旧動作など、ソフトウェア構成が複数の要素にまたがって関与します。
以下の用途を要するプロジェクトでは、 カスタマイズ済み Android タブレット 設定項目であり、最終的なテスト段階で個別の課題として扱うのではなく、ハードウェアおよびAndroidシステムの構成と併せて総合的に評価する必要があります。
適切な解決策は、使用しているAndroidのバージョン、タブレットのファームウェア、アプリケーションの設定、およびシステムインテグレーターが制御したい機能によって異なります。また、利用可能なシステムインターフェース、サポートされるインテント(Intents)、権限(permissions)、デバイス固有の制限事項などをもとに、技術文書を作成することも可能です。
キオスク展開またはシステム統合向けに アンドロイドタブレット テストを実施中で、以下のいずれかの問題に遭遇した場合 デバイスオーナー(Device Owner)、カスタムランチャー、キオスクモード、設定用インテント(Settings Intents)、システムUIの制限、デバイスの復旧機能 , お願いします お問い合わせ 技術サポートをご依頼ください .
タブレットの機種名、Androidバージョン、展開設定、および実現しようとしている具体的な機能についてお知らせいただければ、利用可能な Androidタブレットのカスタマイズおよび技術サポート プロジェクト向けの選択肢をご確認ください。