プロビジョニングは、enterprise が policies を使用して管理するデバイスをセットアップするプロセスです。このプロセスでは、policies の受信と適用に使用される Android Device Policy がインストールされます。プロビジョニングが成功すると、API は devices オブジェクトを作成し、デバイスを企業にバインドします。
Android Management API は、登録トークンを使用してプロビジョニング プロセスをトリガーします。使用する登録トークンとプロビジョニング方法によって、デバイスの所有権(個人所有または会社所有)と管理モード(仕事用プロファイルまたは完全管理対象デバイス)が確立されます。
割り当てシステムは、各プロジェクトで管理できるデバイスの数を制御します。最初のデバイスをプロビジョニングする前に、初期デバイス割り当てをリクエストする必要があります。
個人所有のデバイス
Android 5.1 以降
従業員が所有するデバイスには、仕事用プロファイルを設定できます。仕事用プロファイルは、仕事用のアプリやデータのための独立したスペースを提供し、個人用のアプリやデータとは分離されます。ほとんどのアプリ、データ、その他の管理 policies は仕事用プロファイルにのみ適用され、従業員の個人用アプリとデータは非公開のままです。
個人所有のデバイスに仕事用プロファイルを設定するには、登録トークンを作成し(allowPersonalUsage が PERSONAL_USAGE_ALLOWED に設定されていることを確認)、次のいずれかのプロビジョニング方法を使用します。
仕事とプライベートの両用に会社所有のデバイスを利用
Android 8+
仕事用プロファイルを設定して会社所有デバイスをセットアップすると、仕事とプライベートの両方でデバイスを使用できるようになります。仕事用プロファイルのある会社所有デバイスの場合:
- アプリ、データ、その他の管理のほとんどの
policiesは、仕事用プロファイルにのみ適用されます。 - 従業員の個人用プロファイルは非公開のままです。ただし、企業は特定のデバイス全体のポリシーと個人使用ポリシーを適用できます。
- 企業は
blockScopeを使用して、デバイス全体または仕事用プロファイルのみにコンプライアンス アクションを適用できます。 devices.deleteとデバイス コマンドは、デバイス全体に適用されます。
仕事用プロファイルが設定された会社所有デバイスを設定するには、登録トークンを作成し(allowPersonalUsage が PERSONAL_USAGE_ALLOWED に設定されていることを確認)、次のいずれかのプロビジョニング方法を使用します。
仕事専用の会社所有デバイス
Android 5.1 以降
完全デバイス管理は、仕事専用の会社所有デバイスに適しています。企業はデバイス上のすべてのアプリを管理し、Android Management API のポリシーとコマンドをすべて適用できます。
また、専用の目的やユースケースに対応するために、デバイスを単一のアプリまたは少数のアプリ群にロックダウン(ポリシー経由)することもできます。完全管理対象デバイスのこのサブセットを「専用デバイス」と呼びます。これらのデバイスの登録トークンでは、allowPersonalUsage を PERSONAL_USAGE_DISALLOWED_USERLESS に設定する必要があります。
会社所有デバイスで完全管理を設定するには、登録トークンを作成し、allowPersonalUsage が PERSONAL_USAGE_DISALLOWED または PERSONAL_USAGE_DISALLOWED_USERLESS に設定されていることを確認して、次のいずれかのプロビジョニング方法を使用します。
ポリシーは、デバイスのプロビジョニング中の UI の生成に影響を与える可能性があります。このようなポリシーは次のとおりです。
PasswordPolicyScope: パスワードの要件を決定します。PermittedInputMethods: パッケージの入力方法を決定します。PermittedAccessibilityServices: フルマネージド デバイスと仕事用プロファイルで許可されるユーザー補助サービスを決定します。SetupActions: セットアップ時に実行されるアクションを決定します。ApplicationsPolicy: 個々のアプリのポリシーを決定します。
デバイスのプロビジョニング中に、仕事用アプリのインストールとデバイス登録カードとともにパスワードの手順を表示したい場合は、デバイスを隔離状態に保つことで UI 生成の開始を遅らせるようにポリシーを更新することをおすすめします。これは、関連するポリシーなしで登録された場合に発生します。デバイス設定の最終的な選択ポリシーが、設定のニーズに関連する項目で入力されるまで、デバイスを隔離状態に保ちます。デバイスのプロビジョニングが完了したら、必要に応じてポリシーを変更できます。
登録トークンを作成する
登録するデバイスごとに登録トークンが必要です(複数のデバイスで同じトークンを使用できます)。登録トークンをリクエストするには、enterprises.enrollmentTokens.create を呼び出します。登録トークンの有効期限はデフォルトで 1 時間ですが、最大で約 10,000 年までのカスタムの有効期限(duration)を指定できます。
リクエストが成功すると、IT 管理者とエンドユーザーがデバイスのプロビジョニングに使用できる enrollmentTokenId と qrcode を含む enrollmentToken オブジェクトが返されます。
ポリシーを指定する
デバイスの登録と同時にポリシーを適用するために、リクエストで policyName を指定することもできます。policyName を指定しない場合は、ポリシーなしでデバイスを登録するをご覧ください。
個人使用を指定する
allowPersonalUsage は、プロビジョニング中にデバイスに仕事用プロファイルを追加できるかどうかを判断します。PERSONAL_USAGE_ALLOWED に設定すると、ユーザーが仕事用プロファイルを作成できるようになります(個人所有デバイスでは必須、会社所有デバイスでは省略可)。
既存の登録トークンの例外
一部のお客様は、有効期限の長い登録トークンを使用して登録を繰り返しています。既存のワークフローが中断されないように、[Google を使用して認証する] の要件が初めて有効になる前に作成されたトークンは、新しいログイン プロンプトの対象外となります。これらの古いトークンはこれまでどおり機能し、ユーザーは Google 認証プロセスを経ずにデバイスを登録できます。
ただし、Google 認証要件が初めて有効になった後に作成されたトークンは、新しい認証ルールに従います。つまり、これらの新しいトークンを使用するデバイスでは、IT 管理者が選択した設定に従ってユーザーが認証を行う必要があります。ユーザーデータを保存すべきでない専用デバイスでは、認証画面が表示されないように allowPersonalUsage が PERSONAL_USAGE_DISALLOWED_USERLESS に設定されていることを確認します。
登録時に Google 認証を強制する
EMM は、登録トークンまたはログイン トークンに適切な値を設定することで、デバイス登録時に Google アカウントへのログインを強制できます。この設定は、Google ログイン画面で [スキップ] ボタンを非表示にするかどうかを決定します。設定すると、これらのオプションは企業全体の googleAuthenticationSettings ポリシーよりも優先されます。
構成オプション
認証の動作は、EnrollmentToken または SigninDetail のいずれかの googleAuthenticationOptions オブジェクトを使用して制御できます。
| フィールド | 説明 | 値 |
authenticationRequirement |
登録時にユーザーが Google で認証する必要があるかどうかを指定します。 | AUTHENTICATION_REQUIREMENT_UNSPECIFIED: 企業のデフォルト設定にフォールバックします。 省略可: ユーザーに Google ログイン画面が表示されますが、スキップすることもできます。 必須: ユーザーはログインをスキップできません。[スキップ] ボタンが非表示になります。 |
requiredAccountEmail |
ユーザーが使用する必要がある特定の管理対象 Google アカウントのメールアドレス。 注: このフィールドを使用する場合は、 authenticationRequirement を REQUIRED に設定しなければなりません。 |
文字列(例: "user@enterprise.com") |
JSON ペイロードの例
スキップ ボタンを無効にする
[スキップ] ボタンを非表示にして、有効な企業アカウントでのログインをユーザーに強制するには、認証要件を REQUIRED に設定します。
{
...
"googleAuthenticationOptions": {
"authenticationRequirement": "REQUIRED"
}
}
特定のアカウントのメールアドレスを必須にする
ユーザーに指定されたアカウントでのログインを強制するには、requiredAccountEmail 文字列を定義します。要件フィールドが REQUIRED に設定されていない場合、トークン作成リクエストは INVALID_ARGUMENT エラーで失敗します。
{
...
"googleAuthenticationOptions": {
"authenticationRequirement": "REQUIRED",
"requiredAccountEmail": "user@enterprise.com"
}
}
QR コードについて
QR コードは、さまざまなポリシーを維持する企業にとって効率的なデバイス プロビジョニング方法として機能します。enterprises.enrollmentTokens.create から返される QR コードは、登録トークンと、Android Device Policy がデバイスをプロビジョニングするために必要なすべての情報を含む Key-Value ペアのペイロードで構成されています。
QR コード バンドルの例
バンドルには、Android Device Policy のダウンロード場所と登録トークンが含まれています。
{
"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": "{enrollment-token}"
}
}
enterprises.enrollmentTokens.create から返された QR コードは、そのまま使用することも、カスタマイズすることもできます。QR コード バンドルに含めることができるプロパティの一覧については、QR コードを作成するをご覧ください。
qrcode 文字列をスキャン可能な QR コードに変換するには、ZXing などの QR コード生成ツールを使用します。
プロビジョニング方法
このセクションでは、デバイスをプロビジョニングするさまざまな方法について説明します。
[設定] から仕事用プロファイルを追加する
Android 5.1 以降
デバイスで仕事用プロファイルを設定するには、次の操作を行います。
- [設定] > [Google] > [セットアップと復元] に移動します。
- [仕事用プロファイルを設定] をタップします。
この手順を行うと、セットアップ ウィザードが起動し、デバイスに Android Device Policy がダウンロードされます。次に、ユーザーはQR コードをスキャンするか、登録トークンを手動で入力して、仕事用プロファイルの設定を完了するよう求められます。
Android Device Policy をダウンロードする
Android 5.1 以降
デバイスに仕事用プロファイルを設定するには、Google Play ストアから Android Device Policy をダウンロードします。アプリがインストールされると、仕事用プロファイルの設定を完了するために、QR コードをスキャンするか、登録トークンを手動で入力するよう求めるメッセージが表示されます。
登録トークンリンク
Android 5.1 以降
enrollmentTokens.create から返された登録トークンまたは企業の signinEnrollmentToken を使用して、次の形式の URL を生成します。
https://enterprise.google.com/android/enroll?et=<enrollmentToken>
この URL を IT 管理者に提供し、IT 管理者がエンドユーザーに提供できるようにします。エンドユーザーがデバイスからリンクを開くと、仕事用プロファイルの設定手順が表示されます。
ログイン URL
この方法では、ユーザーはプロビジョニングを完了するために必要な追加情報を入力するページにリダイレクトされます。ユーザーが入力した情報に基づいて、デバイスのプロビジョニングに進む前に、ユーザーに適したポリシーを計算できます。次に例を示します。
enterprises.signInDetails[]でログイン URL を指定します。ユーザーが仕事用プロファイルを作成できるようにする場合は、allowPersonalUsageをPERSONAL_USAGE_ALLOWEDに設定します(個人所有デバイスでは必須、会社所有デバイスでは任意)。結果の
signinEnrollmentTokenをプロビジョニングの追加として QR コード、NFC ペイロード、またはゼロタッチ構成に追加します。または、ユーザーにsigninEnrollmentTokenを直接提供することもできます。次のいずれかを選択します。
- 会社所有のデバイス: 新しいデバイスまたは出荷時の設定にリセットしたデバイスの電源を入れた後、
signinEnrollmentTokenをデバイスに渡す(QR コード、NFC バンプなどを使用)か、ユーザーにトークンを手動で入力してもらいます。デバイスで、ステップ 1 で指定したログイン URL が開きます。 - 個人所有のデバイス: ユーザーに[設定] から仕事用プロファイルを追加するよう依頼します。プロンプトが表示されたら、ユーザーは
signinEnrollmentTokenを含む QR コードをスキャンするか、トークンを手動で入力します。デバイスで、ステップ 1 で指定したログイン URL が開きます。 - 個人所有のデバイス: ユーザーに登録トークン リンクを提供します。登録トークンは
signinEnrollmentTokenです。デバイスで、ステップ 1 で指定したログイン URL が開きます。
- 会社所有のデバイス: 新しいデバイスまたは出荷時の設定にリセットしたデバイスの電源を入れた後、
Google がすでにユーザーを認証しているかどうかを確認します。GET パラメータ
provisioningInfoを使用して(デバイス登録中に)デバイス プロビジョニング情報を取得し、フィールドauthenticatedUserEmailの値を確認します。このフィールドに値がある場合、ユーザーはすでに Google によって正常に認証されているため、この ID を追加の認証なしで使用できます。Google がまだユーザーを認証していない場合は、ログイン URL でユーザーに認証情報の入力を求める必要があります。ID に基づいて、適切なポリシーを決定し、GET パラメータ
provisioningInfoを使用して(デバイス登録時に)デバイスのプロビジョニング情報を取得できます。enrollmentTokens.createを呼び出し、ユーザーの認証情報に基づいて適切なpolicyIdを指定します。手順 5 で生成した登録トークンを URL リダイレクトを使用して
https://enterprise.google.com/android/enroll?et=<token>の形式で返します。
ログイン URL フローで Google 認証を適用する
サードパーティのログインフロー(enterprises.create または enterprises.patch 経由)で SigninDetail を使用する場合は、googleAuthenticationOptions を渡すことができます。これにより、ユーザーがサードパーティのログイン URL にリダイレクトされる前にルールが適用されます。
ログイン URL フローの最後に EnrollmentToken が作成されると、その認証要件は最初の SigninDetail とやり取りします。
SigninDetailで Google ログインが必須でなかったためユーザーがスキップした場合でも、結果として得られたEnrollmentTokenの要件が REQUIRED に設定されていると、ユーザーにエラーが表示され、ログインが必要になります。- トークンに
requiredAccountEmailが設定されていて、ユーザーが企業に属する別のメールアドレスでログインした場合、「アカウントが間違っています」というエラーが表示され、正しい必須メールアドレスで再度ログインする必要があります。
QR コードの方法
Android 7.0 以降
会社所有デバイスをプロビジョニングするには、QR コードを生成して EMM コンソールに表示します。
- 新しいデバイスまたは出荷時設定にリセットしたデバイスで、ユーザー(通常は IT 管理者)が画面の同じ場所を 6 回タップします。QR コードのスキャンを求めるメッセージがデバイスに表示されます。
- ユーザーが管理コンソール(または同様のアプリケーション)に表示された QR コードをスキャンして、デバイスを登録、プロビジョニングします。
NFC メソッド
Android 6.0 以降
この方法では、登録トークン、初期ポリシーと Wi-Fi 構成、設定、およびお客様がフルマネージド デバイスまたは専用デバイスをプロビジョニングするために必要なその他のすべてのプロビジョニングの詳細を含む NFC プログラマー アプリを作成する必要があります。お客様またはお客様が Android デバイスに NFC プログラマー アプリをインストールすると、そのデバイスがプログラマー デバイスになります。
NFC メソッドをサポートする方法について詳しくは、Play EMM API デベロッパー ドキュメントをご覧ください。このサイトには、NFC バンプでデバイスにプッシュされるデフォルト パラメータのサンプルコードも含まれています。Android Device Policy をインストールするには、デバイス管理パッケージのダウンロード場所を次のように設定します。
https://play.google.com/managed/downloadManagingApp?identifier=setup
DPC ID メソッド
QR コードまたは NFC を使用して Android Device Policy を追加できない場合は、ユーザーまたは IT 管理者が次の手順に沿って会社所有のデバイスをプロビジョニングできます。
- 新しいデバイス、または出荷時設定にリセットしたデバイスのセットアップ ウィザードの手順に沿って操作します。
- Wi-Fi のログイン情報を入力して、デバイスをインターネットに接続します。
- ログインを求められたら、afw#setup と入力します。これにより、Android Device Policy がダウンロードされます。
- QR コードをスキャンするか、登録トークンを手動で入力して、デバイスをプロビジョニングします。
ゼロタッチ登録
Android 8.0 以降(Pixel 7.1 以降)
ゼロタッチの正規販売パートナーから購入したデバイスは、ゼロタッチ登録の対象となります。ゼロタッチ登録は、デバイスを事前に設定して初回起動時に自動的にプロビジョニングする合理的な方法です。
組織は、ゼロタッチ登録ポータルまたは EMM コンソール(ゼロタッチ Customer API を参照)を使用して、ゼロタッチ デバイスのプロビジョニングの詳細を含む設定を作成できます。初回起動時に、ゼロタッチ デバイスは設定が割り当てられているかどうかを確認します。割り当てられている場合は、Android Device Policy がダウンロードされ、割り当てられた構成で指定されたプロビジョニング エクストラを使用してデバイスのセットアップが完了します。
お客様がゼロタッチ登録ポータルを使用している場合は、作成する各設定の EMM DPC として Android Device Policy を選択する必要があります。ポータルの使用方法(デバイスへの構成の作成と割り当ての方法など)について詳しくは、Android Enterprise のヘルプセンターをご覧ください。
お客様が EMM コンソールから直接設定を設定して割り当てることを希望する場合は、ゼロタッチ Customer API と統合する必要があります。構成を作成するときに、dpcExtras フィールドでプロビジョニング エクストラを指定します。次の JSON スニペットは、dpcExtras に含める内容の基本的な例を示しています。ログイン トークンが追加されています。
{
"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_ADMIN_EXTRAS_BUNDLE":{
"com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN":"{Sign In URL token}"
}
}
セットアップ中にアプリを起動する
setupActions を使用して、セットアップ中にアプリを起動します。policies では、デバイスまたは仕事用プロファイルの設定時に Android Device Policy で起動するアプリを 1 つ指定できます。たとえば、ユーザーがセットアップ プロセスの一環として VPN 設定を構成できるように、VPN アプリを起動できます。アプリは RESULT_OK を返して完了を通知し、Android Device Policy がデバイスまたは仕事用プロファイルのプロビジョニングを完了できるようにする必要があります。セットアップ中にアプリを起動するには:
アプリの installType が REQUIRED_FOR_SETUP であることを確認します。アプリをデバイスにインストールまたは起動できない場合、プロビジョニングは失敗します。
{
"applications":[
{
"packageName":"com.my.vpnapp.",
"installType":"REQUIRED_FOR_SETUP"
}
]
}
アプリのパッケージ名を setupActions に追加します。title と description を使用して、ユーザー向けの指示を指定します。
{
"setupActions":[
{
"title":{
"defaultMessage":"Configure VPN"
},
"description":{
"defaultMessage":"Enable your VPN client to access corporate resources."
},
"launchApp":{
"packageName":"com.my.vpnapp."
}
}
]
}
アプリが launchApp から起動されたことを区別するために、アプリの一部として最初に起動されるアクティビティには、ブール値のインテント エクストラ com.google.android.apps.work.clouddpc.EXTRA_LAUNCHED_AS_SETUP_ACTION(true に設定)が含まれます。このエクストラを使用すると、アプリが setupActions から起動されたか、ユーザーによって起動されたかに基づいてアプリをカスタマイズできます。
アプリが RESULT_OK を返すと、Android Device Policy はデバイスまたは仕事用プロファイルのプロビジョニングに必要な残りの手順を完了します。
セットアップ中に登録をキャンセルする
SetupAction として起動されたアプリは、RESULT_FIRST_USER を返して登録をキャンセルできます。
登録をキャンセルすると、会社所有のデバイスがリセットされるか、個人所有のデバイスの仕事用プロファイルが削除されます。
注: 登録をキャンセルすると、ユーザーの確認ダイアログなしでアクションがトリガーされます。RESULT_FIRST_USER を返す前に、適切なエラー ダイアログをユーザーに表示するのはアプリの責任です。
新しく登録されたデバイスにポリシーを適用する
新しく登録されたデバイスにポリシーを適用する方法は、お客様の要件に応じて選択できます。使用できるアプローチは次のとおりです。
(推奨)登録トークンを作成する際に、デバイスに最初にリンクされるポリシーの名前(
policyName)を指定できます。トークンを使用してデバイスを登録すると、ポリシーがデバイスに自動的に適用されます。ポリシーを企業のデフォルト ポリシーとして設定します。登録トークンでポリシー名が指定されておらず、
enterprises/<enterprise_id>/policies/defaultという名前のポリシーがある場合、新しいデバイスは登録時にデフォルトのポリシーに自動的にリンクされます。Cloud Pub/Sub トピックにサブスクライブして、新しく登録されたデバイスに関する通知を受け取ります。
ENROLLMENT通知に応答して、enterprises.devices.patchを呼び出し、デバイスをポリシーにリンクします。
ポリシーなしでデバイスを登録する
有効なポリシーなしでデバイスが登録されると、デバイスは隔離されます。隔離されたデバイスは、デバイスがポリシーにリンクされるまで、すべてのデバイス機能がブロックされます。
5 分以内にデバイスがポリシーにリンクされない場合、デバイスの登録は失敗し、デバイスは出荷時の設定にリセットされます。検疫デバイスの状態では、ソリューションの一部としてライセンス チェックやその他の登録検証プロセスを実装できます。
ライセンス チェック ワークフローの例
- デバイスがデフォルトのポリシーまたは特定のポリシーなしで登録されている。
- 企業に残っているライセンスの数を確認します。
- 使用可能なライセンスがある場合は、
devices.patchを使用してデバイスにポリシーを適用し、ライセンス数を減らします。使用可能なライセンスがない場合は、devices.patchを使用してデバイスを無効にします。または、登録から 5 分以内にポリシーが適用されていないデバイスは、API によって出荷時の設定にリセットされます。