Issue #19（親Issue #3）の判断記録。実機検証を行わないまま、dedicated Flavor・Device Owner・カスタムHome・Lock Task modeの実装を保留する。
保留の対象はDevice Owner・カスタムHome・Lock Task・dedicated Flavorに限る。 Issue #16（フェーズ3: Bluetooth接続の製品化）のうち、standard運用として進められる部分（ペアリング済み機器選択、権限要求、状態管理、有限バックオフ再接続、lifecycle対応）は、本trackの結論を待たずに進める。以前記録した「#19 blocks #16」の関係は解消した。
現時点では実装・実機検証に進まない。standard運用（通常端末として維持し、利用者が手動起動する）を当面継続する。専用端末（トラクター常設用タブレット）の調達・運用計画が具体化した時点で、あらためて本trackを再開する。
docs/decisions/p3-android-deployment-modes.mdでstandard/dedicatedのProduct Flavor方針とDevice Owner＋カスタムHome方式が決定され、実装前の最小検証としてIssue #19が作られた。着手にあたり対象実機(Redmi Pad SE 8.7、Android 15/API 35、HyperOS)へ非破壊のadbコマンドで状態を確認したところ、次が判明した。
ro.build.version.release : 15
ro.build.version.sdk : 35
ro.build.display.id : AP3A.240905.015.A2
settings secure user_setup_complete : 1
settings global device_provisioned : 1
登録済みアカウント: Google(akiracraftw***@gmail.com)、Facebook、Facebook Messenger、
Google Duo(com.google.android.apps.tachyon)、Xiaomiアカウント の5件
Device Owner / Profile Owner: 未設定
Android公式ドキュメント(Provision for device management)はdpm set-device-ownerの前提として「対象端末をfactory resetし、ユーザーアカウントが存在しない状態にする」ことを明記している。コミュニティ報告でも「端末上にアカウントが存在するとNot allowed to set the device owner because there are already some accounts on the deviceで失敗する」ことが確認されている一方、アカウントを削除するだけでfactory reset無しに成功する場合があるという未公式の報告もあり、確実な非破壊手段としては保証されていない。
対象実機は本プロジェクトのBluetooth/NMEA・オフライン地図検証（track #13〜#15）で継続利用してきた実機であり、かつ利用者個人のGoogle/Facebook/Xiaomiアカウントが入っている。Device Owner化を試みるには最低でも全アカウントの削除、確実な方法としては工場出荷状態へのリセットが必要になる見込みであり、これは端末の個人利用・既存の検証環境の双方に影響する。
standard運用（通常端末として維持し、利用者が手動起動する）のままでも、P3完了条件（現在地表示・再接続・30分連続利用・接続起動復旧終了手順）は満たせるapps/android-tablet/は現状どおり単一構成（dev.drogger.tablet、Product Flavor分割なし）のまま、standard相当として運用するstandard向けに挙げている「必要なら端末起動後に通知で起動を案内」の方向で別途検討する。具体的な実装（BOOT_COMPLETED受信通知の要否・内容）は本trackのスコープ外とし、着手する場合は改めてtrackを立てる次のいずれかが具体化した時点で、本trackを再開しDevice Owner検証に着手する。
再開時に同じ調査をやり直さずに済むよう、今回確認した公式情報をまとめる。
dpm set-device-owner <component>はadb経由の開発者向けコマンド。前提は「未プロビジョニングの端末（Settings.Secure.USER_SETUP_COMPLETEが一度も設定されていない）」「アカウントが存在しない」こと（Provision for device management、Test device management）ACTION_PROVISION_MANAGED_DEVICEは非推奨。Android 12以降、QRコード/NFC等のプロビジョニングフローを実装する場合はACTION_GET_PROVISIONING_MODEとACTION_ADMIN_POLICY_COMPLIANCEのハンドラをDPC側に実装しないとプロビジョニングが失敗する（DevicePolicyManager）。ただしadb dpm set-device-ownerはこのQR/NFCフローを経由しないため、この検証trackのような単発の実機確認では上記ハンドラの実装は不要。将来、複数台のトラクター向けタブレットへ現地でプロビジョニングする運用（QRコード方式等）を採る場合は、#16でこの実装要否を再検討するカスタムHomeのAndroidManifest宣言:
<activity android:name=".KioskModeActivity" android:launchMode="singleInstance" android:excludeFromRecents="true">
<intent-filter>
<action android:name="android.intent.action.MAIN"/>
<category android:name="android.intent.category.HOME"/>
<category android:name="android.intent.category.DEFAULT"/>
</intent-filter>
</activity>
Home固定はDevicePolicyManager.addPersistentPreferredActivity(adminName, filter, activity)（filterはACTION_MAIN + CATEGORY_HOME + CATEGORY_DEFAULT）で行う
Lock Task許可はsetLockTaskPackages(adminName, arrayOf(PACKAGE))。開始はActivityOptions.setLockTaskEnabled(true)を付けてstartActivity（Android 9+）。UI機能（Home/Overview/通知/電源メニュー/ステータスバー等）はsetLockTaskFeatures()のフラグ組み合わせで制御する
setLockTaskPackages/setLockTaskFeatures/addPersistentPreferredActivityはいずれもDevice Owner権限が必要
DeviceAdminReceiverの具体的なmanifest宣言例（BIND_DEVICE_ADMIN権限、device_adminメタデータXML）は公式ページからは断片的にしか得られなかった。再開時はBuild a device policy controllerとAOSPのTestDPCサンプル実装を参照する
adb shell dpm set-device-owner dev.drogger.tablet.dedicated/.DeviceAdminReceiver
#19 blocks #16の関係は解消した。#16（フェーズ3: Bluetooth接続の製品化）は、standard運用のBluetooth製品化として本trackの結論を待たずに進める。#16のうちdedicated Flavor・Device Owner・カスタムHome・Lock Task関連の実装のみ、本trackの再開・完了を前提とする。