Android Enterpriseについて適当に騙る

Android Enterprise とは

Android Enterpriseについて

複数の事項に対してAndroid Enterpriseの名称が付けられており、主にデバイス管理に関しての事柄について記載する。
文字通りAndroidを企業で使う場合のシステムというかモード。かつてはAndroid for Workと言われていた。
ざっくりと「Android Enterpriseを使う」≒「デバイスをAE化する」≒「Device Owner権限を用いてデバイスをEMMで管理できるようにする」といった感じで、デバイス周りと対応EMMの話を少々、あとは関連するAPIについて。

このDevice Ownerを使わないと、意外と制限や設定できることが少なかったり、そもそもAndroid 10以降でまともに使えないし、そうでなくとも動作が怪しかったり強制的に無効化しやすかったり良いことが無い。詰む。
遠隔管理するにゃほぼ必須と考えた方がいいかも知れない。というか、今時のMDMなら、管理しようとするとだいたいDevice Ownerになってくれる。（AE化してくれる）

なお本文中の用語のうち、MDMはEMMと同義と読み替えてください。

個人で遊ぶ方法は後半。

Android Enterprise Recommendedとは

Android Enterpriseの名を関するものの一つ。
GoogleがAndroid Enterpriseを使うにあたって、特にオススメしている機種やEMMや事業者。略してAER。
なんかそれ用の審査を通らないと取れないらしい。

AERな機種を選ぶ利点としてとりあえず挙げられるのは以下の三点。

• この記事で語るAEのモードにとりあえず対応
• 最低限のスペックを担保（あまり高くはないけども、そのうち見直されるだろう）
• 一定のアップデートを担保

AERな事業者の利点

• 後述するZero Touchの設定をデバイスに付与することができる
• 導入コンサルティング、AERなデバイスとEMMの調達、キッティング（包括的初期設定）、展開の支援
• 運用支援
• Android Enterprise認定資格保持者を抱えている

Android Enterprise Recommended デバイスの要件概要
それ以外の要件概要

これらの認定されたものについてはEnterprise Solutions Directoryにて確認できる。

費用について

AE化するとか、Zero Touchを使うとかそのあたりは基本的に無料。
しかし、活用するためにはEMMが必要で、EMMがだいたい1台あたり月額or年額いくら方式で有料。
また、独自アプリの配信を用いる場合、配信方法によってはGoogle Play Consoleの申し込みが必要で、$25を一回こっきり払う必要がある。

ざっくりと種類分け

コロコロ変わっているので把握できない。たぶん違っている。
大きく3つのSolution Setsと、+1つの組み合わせの、計4種類をとりあえず考えておけばいいかもしれない。
それぞれMDMの対応が必要。

なお、非Android EnterpriseのMDM管理状態（Device Ownerを用いない古い仕組み）はDevice AdminとかLegacy Modeとか呼ばれるそうな。

• Work Profile
  • Androidの中に、個人用の環境と仕事用の環境を作る。仕事用プロファイルとも
  • それぞれ独立しているので、それぞれの環境に個別にアプリを入れることができる
    • 例えばアプリ一覧の中にChromeのアイコンが2つあり、それぞれの設定が独立しており、仕事用のChromeは管理者が設定を強制してセキュアに使うとか
  • たぶん主目的はBYODで使うこと
• Fully managed device
  • デバイスを丸ごと企業の管理下に置く。かつてはDevice Owner Modeとか言われていたらしい
  • デバイスすべてがMDMの管理化にあり、制御されることからiOSの監視モードに近いと考える
  • たぶん一般的に、会社が社員にスマホを貸与する場合に主に使われそうな気がする
  • 個人的に趣味で遊ぶ分にもイイかもしれない
• Dedicated device
  • Android端末で専用機（飲食店の注文用タブレットとか、POSレジとか？）とする用なのか
  • COSUとも言われていたそうな
  • iOSのシングルAppモードよりかは柔軟性があるらしい。（複数アプリを設定できる）
  • 子供用に勉強用とかで押し付けるのにアリかもしれない
• COMP（Fully managed devices with work profiles）
  • Fully Managed Deviceの上にWork Profileを乗っけたもの
  • COPEとも言う様子
  • 会社が貸与した機器の上に個人で使ってもいいよ的領域を区切るようなイメージか
    • もしくは、よりセキュアな領域を作るような使い方もできそう

AE化に対応するデバイス

まず、Android 5以上であること。
次にPlay Storeがプリインされていること。
（ストアとか開発者サービスが無くても使えるMDMもあるけれども、Play Storeアプリと開発者サービスが割と密接にManagement APIに関係するため、Dedicated以外で一般利用するデバイスに遠隔管理で使うのであれば、これらが無いと詰む。）

推奨は、Android Enterprise Recommendedの認定を受けていること。
理想はAndroid 9以降のRecommended、せめて8以降。というか極力新しいOS。

とりあえず「Android Enterprise Solution Directory」を見るのが早い。

遊ぶだけであればガラホとかKindle Fireとかエミュレータのストア無し版でも動くっぽい。

AE化する方法

基本的には対応したMDMが必要だけど、テスト用の仕組みが設けられている。（後述）
以下の方法からやる。
なお、一般のMDMの場合はMDMと通信しないといけなかったり、アプリをダウンロードさせるためにデータ通信できることが必要。
モバイルデータ通信をやる場合はSIMを刺すだけで通信できるものでないと、途中でAPN設定ができないので詰む。Wi-Fi使うしかない。

MDM Agentを入れる

現在利用中の端末にPlay StoreなどからMDM Agentをインストールし設定を進めるとWork Profileで適用される。

G Suiteアカウントでログインする

管理者が予めG Suiteで設定しておくと、G SuiteアカウントでサインインするとWork Profileで適用されるらしい。初期画面で入れるとFullyらしい。

DPC-identifier

DPCハッシュとかDPCトークンと言われる場合もあるらしい。 Androidの初期設定画面（初期化直後の最初の設定ウィザード）中のGoogleアカウント入力画面で、Googleアカウントの代わりにMDMごとに決められた文字列を入力する。
形式は「afw#[文字列]」。例として「afw#setup」とか。それ以降はそれぞれのお作法がある様子。
洋物MDMはある程度ここにまとめられている。

NFC

Androidの初期設定画面（初期化直後の最初の設定ウィザード）一番最初の画面（ようこそと出ているところ）で、NFCを読ませる。
一般的には別のAndroid端末に専用のアプリを入れて設定をして、そのAndroid端末と設定したいAndroid端末を接触させる。
DPC-identifierの方法と比べて、追加設定を入れられるようになる。
Android 6以上で、もちろんNFC搭載機種でなければならない。
生カードから作ればそれぞれのMDMのものは作れる様子。

QRコード

Androidの初期設定画面（初期化直後の最初の設定ウィザード）一番最初の画面（ようこそと出ているところ）で、画面を7連打するとQR読み込み画面が出てくる。
そこで設定用QRコードを読ませる。QRコードの中身は後述
NFC方式と同様に、DPC-identifierの方法と比べて、追加設定を入れられるようになる。
Android 7以上で対応。なおAndroid 9未満の場合はQRコードリーダーアプリを裏でダウンロードするらしく、Wi-Fiの手動設定かAPNが自動設定できるモバイルデータ通信が必須っぽい。
9以降ならQRコードの中にWi-Fi設定を入れて自動化できる。

Zero-Touch

概要はこちら
ヘルプはこちら
iOSのDevice Enrollment Program（DEP）に似る。
Googleのサーバ上でデバイスとMDMを紐づけておくことで、勝手に設定される。
イメージとしては強制的ににNFCやQRが読み取りされて設定が突っ込まれる感じ。
一部機種を除いてAndroid 8以上で、たぶん個人では無理。
とりあえず下の方に少しだけ記載

サムスンは独自でKnox Mobile Enrollmentがあり、こっちならなんとか個人でも遊べる。

【おまけ番外編】adbコマンド経由でdpmコマンド

デバッグモードでコマンドを叩く。
書式は「adb shell dpm set-device-owner "[COMPONENT_NAME]"」
アカウント設定が無い状態で叩かなければならないので、一部キャリアモデル（標準で勝手にアカウントが入っていて消せないもの）は追加作業でpmコマンドで一部プリインパッケージの無効化か削除が必要。
Qiita上にも記事はあるので、それ参照。
初期化せずに遊びたい場合や上記の他の手段が取れない（稀にそんな機種が居る）場合に使えなくもない。 　Kindleやガラホ、Android Studioのエミュレータでもこれを使えばAndroid EnterpriseのFully Managedが使える。まともに使えるのかは別として。

なお、デバイスがAE化されていると、通知欄に「これは組織が所有するデバイスです」っぽいことが表示される。OSバージョンやEMMによって文言が変わる場合もある。（対応するEMMだと文言設定が可能）
また、設定のセキュリティ詳細設定内にて、「デバイス管理アプリでOFFにできないものが出現する」「管理対象デバイスの情報が表示される」といった動作が確認できる。
さらに、バグレポート（またはdumpsys device_policy）にて、Device Owner権限を持つパッケージ名が「DUMP OF SERVICE device_policy」の項に表示される。

ざっくりまとめ

DedicatedとCOMPはFullyに準じると考えればいいのかもしれない。

方式	バージョン	Work Profile	Fully Managed
MDM Agentインストール	たぶん5以降	○	×
G Suite	たぶん5以降	○	○？
DPC-Identifier	6以降	×	○
NFC	6以降	×	○
QR	7以降	×	○
Zero-Touch	8以降	×	○
dpm	たぶん6以降	×	○

Android Enterpriseを試す、遊ぶ

個人的に利用する場合でメリットがありそうなのは、以下の二点

• 初期設定時にシステムアプリの挙動を指定できる（Fully Managedの場合）
  • キャリアアプリやGoogleアプリ、3rdパーティーアプリでプリインされているものをアンインストールまたは無効とさせる
    • ただし、通常状態で無効化できないものでも一部無効化される場合がある
      • キャリア独自のアプリやデバイスメーカーが仕込んでいるアプリなどで、潰してしまうとマズいものも潰れる場合があり、その場合はそのパッケージが司るサービスは使えなくなる
• 同一のアプリを独立して二つ動かせる（work Profile、COMPで）
  • 一部の機種では元から「デュアルアプリ」や「ツインアプリ」といった機能があるが、仕組みは似たようなもの

iOSと比べ、キャリアやメーカーのプリインアプリが大量に突っ込まれるAndroid。
SIMフリー版でも買えばええんでないのと思うが、キャリアから安く買えたりする。
標準でインストールされているメーカーやキャリアのアプリの大半がアンインストールまたは無効とされた状態とすることができるので、それらのアプリがうっとうしいと思う人は少し幸せになれるかもしれない。

あとはプライベートでの二台持ちの代わりになるかもしれない。同時起動は無理かも知んないけど。

どうやって遊ぶのか

最も手軽なのはTest DPCを利用すること。
Work ProfileにするのであればPlay Storeからインストール。
Fully Managedを試すのであればそれ以外の方法で。
NFCはちょっと面倒なので後述。
QRかDPC-Identifierが手っ取り早い。ただしデバイスを一回初期化する必要があるので、dpmコマンドでもいいかもしれない。

QRコードの書式（一部 Zero-TouchのCusom DPCに流用可能）

例

{
    "android.app.extra.PROVISIONING_LEAVE_ALL_SYSTEM_APPS_ENABLED": false,
    "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME": "com.afwsamples.testdpc/com.afwsamples.testdpc.DeviceAdminReceiver",
    "android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION": "https://play.google.com/managed/downloadManagingApp?identifier=testdpc",
    "android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM": "gJD2YwtOiWJHkSMkkIfLRlj-quNqG1fb6v100QmzM9w=",
    "android.app.extra.PROVISIONING_LOCALE": "ja_JP",
    "android.app.extra.PROVISIONING_TIME_ZONE": "Asia/Tokyo",
    "android.app.extra.PROVISIONING_WIFI_SSID": "Wi-Fi SSID",
    "android.app.extra.PROVISIONING_WIFI_SECURITY_TYPE": "WPA",
    "android.app.extra.PROVISIONING_WIFI_PASSWORD": "password"
}

各項目の解説は後述。
なお、Wi-Fi設定を入れている場合、そのWiFiに接続できないと先に進まないので、以下はWi-Fi設定を抜いたQRコード

NFC方式を使う場合

Play Storeにそれ用のアプリが転がっていたり、MDMメーカーがそれ用のAPKを公開していたり。
nfcpyを使うことでPCに接続したPasoriでカードに書き込んだり、Pasoriにスマホを乗っけてデータを送りこんでプロビジョニングさせる。

個人的にはNFC Tools - Pro Editionを購入し、時々利用している。
NFCカードの作成・複製ができ、逆にカードから設定値を読み取ることもでき、設定値を保存しておくことができ、カードをエミュレートし実カードが無くても行ける場合があり。

NFC用のカードの作り方

■材料
　生カード 適量
　　NDEFタグで書き込みできるもの。Amazonとかで「NTAG216」で出てくるカードが無難。ちょっと反応鈍いけど。
　　某ゲーム用とかに使われるNTAG215は容量が微妙。Felica Lite-Sとかは容量的に無理。Felica Standardは一次発行ができるならアリかもしんない。やり方わからんし高いけど。

　NDEF書き込み用ソフト
　　とりあえず前述のnfcpyかNFC Toolsは手元で実績あり。ただし、nfcpyとWindowsの相性はあまりよろしくない。

■作り方
　生カードにデータを書き込む
　mime（typename）は「application/com.android.managedprovisioning」
　データはQRとほぼ同様。JSONではない。
　一部記号のエスケープはバックスラッシュ。だいたい無くても行ける。EXTRATS_BUNDLEの複数項目は「\n」で区切る。

nfcprovisioning_customize.txt

android.app.extra.PROVISIONING_LEAVE_ALL_SYSTEM_APPS_ENABLED=false
android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME=com.afwsamples.testdpc/com.afwsamples.testdpc.DeviceAdminReceiver
android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION=https://play.google.com/managed/downloadManagingApp?identifier=testdpc
android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM=gJD2YwtOiWJHkSMkkIfLRlj-quNqG1fb6v100QmzM9w
android.app.extra.PROVISIONING_LOCALE=ja_JP
android.app.extra.PROVISIONING_TIME_ZONE=Asia/Tokyo

PCでやる場合は、上のテキストファイルを作成しておき、ndeftoolとnfcpyのソースに内包されているtagtool.pyを使って以下のようにやるといい感じ

WIFI_SSID の値だけはダブルクォーテーションで括る必要あるかも。

カードを作成するコマンド
コマンド実行後、待機状態になるので書き込み可能なカードをリーダ・ライタに乗っける。

Write_NFC_Card

ndeftool tn "application/com.android.managedprovisioning" pl "$(cat nfcprovisioning_customize.txt)" | python3 tagtool.py load -

カードをエミュレートするコマンド
コマンド実行後、待機状態になるのでプロビジョニングするスマホをリーダ・ライタに乗っける

NFC_Emulate

ndeftool tn "application/com.android.managedprovisioning" pl "$(cat nfcprovisioning_customize.txt)" | python3 tagtool.py emulate - tt3

キーの概要

• PROVISIONING_LEAVE_ALL_SYSTEM_APPS_ENABLED

  • システムアプリの挙動を設定
  • 省略時の適用値はFalseっぽい
  • Falseにすると消せるアプリはすべてアンインストール、消せなくとも無効化できるアプリはすべて無効化した状態になる
  • アンインストールされたアプリを復活させられるかはアプリ次第。（再インストールの手段があるかどうか。Play Storeに無いとちょっと辛い）
  • 非表示となったアプリを再表示できるかはMDM次第（MDMで指定したシステムアプリの最有効化をする機能があるか）
  • TestDPCの場合はメニューの「Enable System App」から
  • Trueにすると通常と同様（Android Enterpriseを利用しない素の状態）となる
  • 極稀に「True」にしておかないと無効化しちゃいけないパッケージを無効化してしまいプロビジョニングにコケる機種がいる
  • 一部のEMMが持っている「システムアプリを有効にする」よりも先に働くため、この値の設定とEMMの設定の組み合わせによってざっくり3パターンほどのアプリ構成になる
    • この値がTrueの場合はすべてのアプリが生き残り、EMMのアプリ有効化設定の値は影響しない
    • この値がFalseで、EMMが有効化の組み合わせの場合、アンインストールされたアプリは復活せず、無効化されたアプリのみが有効化される
    • この値がFalseで、EMMでも有効化設定が施されていない場合は、最小限のアプリ構成となる
    • なお、EMMにより「無効化されたプリインアプリをすべて有効化する」「無効化されたプリインアプリを指定して有効化する」があるため注意は必要（前者は意図しないアプリが起きてくる、後者はパッケージ名を確認しておかなければならない）

• PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME

  • 必須値
  • 代わりにPROVISIONING_DEVICE_ADMIN_PACKAGE_NAMEもあるが安定しない
    • 「This constant was deprecated in API level 23.」とあるので、PACKAGE_NAMEではなくCOMPONENT_NAMEを使うほうが良いのだろう
    • QRで使うと割と失敗しNFCならまだ行ける感じがするが、結局はAPKの作り次第かもしれない
  • Android Eterpriseをするのに用いるアプリのパッケージ名とコンポーネント名
    • PROVISIONING_DEVICE_ADMIN_PACKAGE_NAMEはパッケージ名のみ
  • 調べる場合は一旦APKをインストールしてBugreportを見るか、Activityの中でDEVICE_ADMIN_ENABLEを持っている奴を総当たり

• PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION

  • ほぼ必須値（対象APKがプリインされているのであれば省略可能）
  • APKのダウンロード元のURL
    • http://、https://以外が行けるかは知らん
      • file://がいけたらSDカードやUSBメモリからプロビジョニングができて便利そうなんだけども
  • 一部MDMのAPKは「https://play.google.com/managed/downloadManagingApp?identifier=[DPC-Identifier]」でもDL可能
    • TestDPCの場合は「https://play.google.com/managed/downloadManagingApp?identifier=testdpc」

• PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM

  • ほぼ必須値（対象APKがプリインされているのであれば省略可能）
  • APKのパッケージ署名のチェックサムで、署名証明書のSHA256ハッシュをバイナリ化してURLセーフなBase64符号化したもの
    • こんな感じ
    • URLセーフでなくともいける場合があるが、少しでもデータ量を減らすために一応URLセーフとしておいたほうがいいかもしれない
  • 代わりにPROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUMでも可能
    • APKのSHA256ハッシュを同様に変換したもの
    • ダウンロードさせるAPKのバージョンアップを考慮すると、原則変更のないSIGNATURE_CHECKSUMのほうがいいかもしれない
  • 5（Lolipop）の場合はDEVICE_ADMIN_SIGNATURE_CHECKSUM非対応で、DEVICE_ADMIN_PACKAGE_CHECKSUMをSHA256ではなくSHA1で書く必要があるっぽい

• [PROVISIONING_WIFI_SSID](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#EXTRA_PROVISIONING_WIFI_SSID">
  PROVISIONING_WIFI_SSID)

  • 設定時に自動接続するWi-Fiのアクセスポイント名
  • Android Pi(9)未満ではQRコードリーダーをダウンロードするため、何かしらのデータ通信設定が必要になるので設定してもあまり意味がない
  • 仮にモバイルデータ通信や他のWi-Fiに接続が可能であったとしても、このキーが設定されている場合はこのAPに接続へ切り替えようとする
    • 接続できなかった場合は、プロビジョニングに失敗となる

• PROVISIONING_WIFI_SECURITY_TYPE

  • WIFI_SSIDを指定した場合にたぶん必須
  • 「NONE、WEP、WPA、EAP」から指定
    • EAPはほぼAndroid Q（10）以降の対応
    • EAPの場合はさらに別のオプションが必要
      • コレとか
      • 正直、証明書情報とかQRでもNFCにも入りきらないので、実質NFCエミュレートかZero Touch用
    • WPA2の場合でも指定はWPAでOKっぽい

• PROVISIONING_WIFI_PASSWORD

  • Wi-Fi接続のパスワード
  • WPA/WPA2ならWIFI_SSID、WIFI_SECURITY_TYPE、WIFI_PASSWORDの3つで完結

その他、WI-Fiに関しては以下の設定があるので必要に応じて。

• PROVISIONING_WIFI_HIDDEN
  • APがステルスの場合はtrueに
• プロキシ設定が必要な場合
  • 手動でホストとポートを設定する場合はPROVISIONING_WIFI_PROXY_HOSTとPROVISIONING_WIFI_PROXY_PORT
  • PACで自動設定させる場合はPROVISIONING_WIFI_PAC_URL
  • 例外設定を行う場合はPROVISIONING_WIFI_PROXY_BYPASS
  • Android 9だか10あたりからEAP認証の設定も入れられるが、証明書は到底QRとNFCには入らないので実質Zero Touch用

他に使うと便利かもしれないもの（Zero-touchでも使えそうなもの）

• PROVISIONING_ADMIN_EXTRAS_BUNDLE

  • MDMごとの固有設定を記載する項目
  • 例は後述
  • MDMによって配下に記載するキーが異なるため、MDMベンダーに聞くしかない
  • うまく使えばだいぶ自動化できる。文字通りゼロタッチで
  • 洋物MDMのいくつかがここにまとめられている

• PROVISIONING_LOCALE

  • 地域と言語の設定
  • 「ja_JP」としておけば、Pixel3とかSIMを刺していないと日本語になってくれない奴らに便利
  • キャリアモデルだとたまに指定していると落ちる奴がいる

• PROVISIONING_TIME_ZONE

  • タイムゾーンの設定
  • 「Asia/Tokyo」としておけば、稀にデフォルト設定が海外となっている奴らに便利
  • キャリアモデルだとたまに指定していると落ちる

• PROVISIONING_SKIP_ENCRYPTION

  • ストレージ暗号化のスキップ
  • 古い機種で、ストレージの暗号化を別途行わないといけないものの場合は、これを設定しておかないと初期設定中にストレージの暗号化処理が行われ時間を要してしまう
  • このキーをtrueで設定しておくと、ストレージの暗号化を後回しにできる

• PROVISIONING_USE_MOBILE_DATA

  • プロビジョニング時にWi-Fiではなくモバイルデータ通信を利用するための設定
  • なぜか最初これを書いた時にはドキュメントに記載がなく、一部のMDMがこっそりと生成していたりしたがいつのまにか掲載されていた
  • 「Added in API level 33」とあるがガセ、たぶん
  • APN設定はできないので、デフォルトのAPN設定で通信できるSIMが刺さっていないとダメ（≒MVNOじゃ基本ダメ）

あんまり詰め込みすぎるとQRが細かすぎて読めなくて詰む。
作業場を設けてガツガツやるなら上のPCを使ったemulate方式なら割とデータ量が多くてもOK。

TestDPCを用いてQRコード方式でFully Manged Deviceにする場合の画面

機種：L-03KでAndroid 8.1

→ 画面連打 → → 画面連打 → → Wi-Fi設定

上のQRコードを読ませる
→ →

細かい設定はTestDPCアプリで

無効化されたシステムアプリの復活は「Enable System Apps」から

動画

Bayton氏がYoutubeに掲載しているもの。
EMMはたぶんMobileIron
なお、この方のサイトは上にも張ったDPC-Identiferの他に一部EMMのEXTRA_BUNDLEが纏まっていたりする。

NFC方式でFully Managed Deviceにする場合

NFCカードをAndroidで作って使う例

MiradoreがYoutubeに掲載しているもの。
なお、無料でも使えるが無料だと機能が足りぬ。

• NFC BUMP用のアプリのデータを別のAndroid機に読み込ませカードデータを得る。
• 得たカードデータを生カードに書き込む
• 書き込んだカードを初期化されたデバイスに当ててプロビジョニング

NFCエミュレートを使う例

Managed Google Playストアとアカウント

管理されたストア。デフォルトでは管理者が許可したアプリしか出てこない。対応したEMMであれば、管理者が禁止していないアプリと有料アプリ以外は出現する割と普通のストアっぽくなる。

使うためにはManaged Google アカウントかManaged Google Playアカウントが必要。
G SuiteとかCloud Identityで使われるのが前者。

後者はMDMが勝手に作ってくれる。Managed Google Playストアを使うためだけの、それ以外のGoogleサービスはろくに使えないようになっている特殊アカウント。
管理の概念は無く自動生成。MDMによってアカウントぼ使い回しがどうなるか異なる。
デバイスに対してユーザーを割り当てることができるMDMの場合、デバイスに依存するのか、それともデバイスに割り当てたユーザー依存であるのか把握しておいた方が良い。
（あまり大きな問題ではないが、インストール済みアプリとか履歴がアカウントに紐づいて連動するので）

ストア以外のGoogleサービスもある程度使いたいけどタダで済ませたいならCloud Identity Freeといった選択肢が考えられるが、どこまで使えるか不明。

注意事項として、アカウント追加制限設定やPlay Storeのアカウント切り替え禁止が漏れると通常のPlay Storeが開いてアプリ入れ放題になる。管理上よろしくない。

Managed Google Playの動作には許可リスト方式と制限リスト方式がある。
許可リスト方式は、Play Storeに管理者が承認したアプリしか出てこない。
制限リストは素のPlay Storeが開くが、管理者が指定したものは非表示となる方式。
個人的な体感では、制限リストに対応したMDMはかなり少ない印象。

課金系（有料アプリの購入）もManaged Play Storeでは不可
ただ、まあ仕事で使うアプリの場合は（業種や規模にもよるが大半が）「アプリは無料、利用アカウントに別途課金（box、MS365、slackとかそんな感じのアレ）」なものだと思うのであまり問題ではないかもしれない。
ただどうしても有料アプリを導入する必要があるのであれば、アプリ提供元に相談するか、Managed Google Playの利用を諦めなきゃならん。

Managed Google Playには限定公開機能があり、Play Consoleを利用しなくとも、そのストア（≒MDM）の管理範囲に限定して独自のアプリを配信できる機能がある。
が、アプリ識別子の縛りとかが結構厄介なのであんまりお勧めしたくない。MDM切り替えの時とか組織改変の時に詰む。
PWAを配信できるWebアプリ機能もある。ただ大体の場合においてChrome Enterpriseの方が気楽かもしれん。

極まれに「URLの直指定であればストアページが開くのに、ストア上での検索には引っかからない」といったアプリが存在する。これをManaged Google Playストアの許可リストに登録するにはゴニョゴニョするか、EMMベンダーの協力が不可欠。主にGoogle系のアプリなので何とかしてくださいGoogleさん。

Android Enterpriseは必要なのか

MDMでデバイス管理する場合、今後はこれにしておかないとバージョンアップに伴い遠隔管理機能がどんどん制限されているとかでいろいろと厳しいらしい。
特に企業向けで必要な機能としてはアプリのインストール管理が要件として挙がってくることもあるかもしれないが、Android Enterpriseにしておくことで「提供元不明アプリのインストール禁止」「デバッグモードの禁止」でAPKのインストールを塞いだうえで、管理者が承認したアプリしかインストールできないManaged Google Playを利用することができ、それにより管理者の意図しないアプリのインストールを防ぐことができるようになったり。

Managed Google Playを試すのであれば、Android Management Experienceが手軽だったが、現在新規利用申し込みができなくなっているので、別記事のAPI直叩きで。

Android Management Experience

Android Management Experienceとは、Googleが提供している、Android EnterpriseとManaged Google Playのお試し版。無料で使える。もう新規不可だけど

以下の機能を利用できる。

• とりあえずWork ProfileとFully managed
• Managed Google Play
  • iframe方式
    • Play Store上の無料アプリ
    • 限定公開アプリとしてAPKを登録可能。
    • Progressive Web App（PWA）としてWebAppを登録可能
    • Managed Google Play Store上のレイアウトを指定可能
  • 指定したアプリの自動インストール
  • Managed Configによるアプリの遠隔設定
    • 何を設定できるのかはアプリ次第
    • 例としてこのアプリのように「このアプリは管理対象設定を提供しています。」とManaged Google Play Store上に出ていれば設定可能。
• ポリシーは以下のみを適用可能
  • 強制でデバッグの無効
  • スクショ禁止の指定
  • コピペ禁止の指定
  • 画面ロックパスワード強制の指定
  • アプリ権限要求の自動化
    • 但し自動許可にすると、自動許可を想定していない一部アプリで詰む。
  • Wi-Fi設定の適用
    • WEPとWPAのパーソナルをいずれかひとつのみ

どんなものかを試す分にはいいが、適用できるポリシーが少なすぎて個人レベルでの実用でも辛い。
家庭向けのペアレントコントロール用に提供元不明アプリインストール禁止と初期化禁止とアプリブラックリストとアカウント追加禁止と遠隔ロック・初期化もできるようになればいいなと妄想。

Android Management ExperienceのQRコード方式を用いる場合の内容

QRでさっくり登録させたい場合はここの内容の応用で可能な様子

AndroidManagementExperience

{
  "android.app.extra.PROVISIONING_LEAVE_ALL_SYSTEM_APPS_ENABLED": false,
  "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":
    "com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver",
  "android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM":
    "I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg",
  "android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION":
    "https://play.google.com/managed/downloadManagingApp?identifier=setup",
  "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE":
    {
      "com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN":
        "【登録コード】"
    }
}

PROVISIONING_LEAVE_ALL_SYSTEM_APPS_ENABLED は好きな方で。でも無効化したものを再有効化する機能は無い様子。キャリアモデルならtrueの方がいい。
DEVICE_ADMIN_xxxxの類は「Android Device Policy」を用いる。
PROVISIONING_ADMIN_EXTRAS_BUNDLE内でAPKに対して登録コードを指定することで、QRを読ませるだけで登録が完了する。
他のMDMでも、上記パッケージを用いるものなら流用可能。（Intuneとか）

なお、DPC-Identifierは「afw#demo」と指定されるが、「afw#setup」と同一っぽい。

どうでもよい感想とか

EMMを作っている所は極力Recommendedを目指してほしい。
キオスクアプリとかを作っている人はQR方式とかでさくっと実装できるように作ってほしい。adbでdpm set-device-owner打つの面倒くさい。

特に初期設定に必要な値はPROVISIONING_ADMIN_EXTRAS_BUNDLEで指定できるようにして、手作業を極力なくすことを目指してほしい。あまりにも多すぎるとQRやNFCの容量足りなくなるけど。

ゼロタッチについて少しだけ

再掲：Googleヘルプ

Googleのシステム上に端末の、セルラー対応であればIMEI、非対応であればシリアル番号を登録し、さらにそれらに対してEMM設定を指定しておくことで初期設定時に自動的にAndroid Enterpriseでのデバイス登録が行われる。

必要なもの

• Android Enterprise Zero Touch対応デバイス
• Android Enterprise 登録可能な販売事業者
  • 日本国内ではこの記事を書いた当初は主要MNO3社と商社1社だけが対応であったが、割と増えた
    • 端末製造元や中古端末販売事業者も対応し、いわゆるSIMフリーモデルや中古デバイスも付与できる世の中なのかもしれない
• 会社（組織）のメールアドレスのGoogleアカウント
  • ポータルサイト開設のため、販売事業者に伝える
  • 開設後はポータルサイトで管理者の追加・削除は可能
    • 同一のアカウントで複数環境の管理者になることも可能
• Zero Touchに対応したEMM
  • このリストに上がっていても、登録完了まで自動化できないものもあって詰む場合がある
  • このリストに上がっていなくても、なぜか使えるものもある
  • とりあえずEMM提供元に聞いて見せてもらわないと詰む
  • たまにEMMが余計な機能を備えており、Zero Touchポータルの設定を全部書き換えて詰む

仕組みの概要

• Android端末の初期設定時にデータ通信ができる場合、自動的にGoogleから設定したEMMの情報を取得して加入処理を行う
  • 半強制的にQRまたはNFCを読み込ませるような感じ
  • データ通信をさせずに初期設定するとZero Touchが適用されずに普通の状態で設定が終わってしまうが、その後通信をすると一定時間後に強制初期化される
• EMMの設定を行う際に「DPC補足情報」欄に追加設定を入れることができる。上記QRコードの中身と同一書式のJSONが利用できる
  • DEVICE_ADMIN_COMPONENT_NAME、DEVICE_ADMIN_SIGNATURE_CHECKSUM、ADMIN_PACKAGE_DOWNLOAD_LOCATIONは不要。（プルダウンから選択すれば良い仕組み）
• EMMの割当を変更しても、初期化しないと反映はされない

ざっくりとApple Device EnrollmentやSAMSUNG KNOX Enrollmentと仕組みは概ね同じ。
EMMで指定するDEPプロファイルの代わりとなるのがDPC補足情報

Android Enterpriseでデバイスに設定できることを適当に抜粋しようと思ったが、量が多くEMM差分も大きいので挫折した雑記

• GoogleがAPIを実装していても、EMMによって使える使えないが変わる
  • iOSの仕組みと大きく異なるので、iOSであればカスタムプロファイルで何とかできることに対し、AndroidはEMMが対応していないと利用は不可
• OSバージョンによっても変わる
  • 当たり前な話、Android12から対応しているAPIをAndroid11で使うことはできない
• 一時的な変更と永続的な変更がある。一時的な変更は割と対応範囲が広そう
  • いわゆる、制限設定とただの遠隔設定
• 一部の機種（というかデバイスメーカー）ではOEMConfigを使うことで、そのデバイス独自の機能制限や遠隔設定を施すことができる
  • これに対応するためには、メーカーが対応するOEMConfigアプリを提供していることと、EMMがアプリに対する管理設定機能を実装している必要がある
    • 例えば京セラはこんな感じ