ユーザー アカウントを実装する

Android Enterprise 登録には、主に managed Google Play アカウントと managed Google アカウントの 2 種類のユーザー ID があります。管理対象 Google Play アカウントはデバイス中心であり、特定のユーザーの Google ID に関連付けられていません。一方、管理対象の Google アカウントはユーザーの企業 Google ID にリンクされているため、デバイスにログインした状態を維持することでユーザー エクスペリエンスが向上します。

以前は、managed Google Play アカウントが標準でした。ただし、Google は、すべての新しい開発で改善された登録フローを使用することを推奨しています。このフローでは、デフォルトで管理対象 Google アカウントが作成されます。

古い実装に関するガイダンスは、このドキュメントの最後にコンテキストとして記載されていますが、すべての新しい開発は、ここで説明する新しい登録フローに沿って行う必要があります。

概要

デバイス登録フローの改善により、いくつかの新しいコンポーネントを活用し、カスタムの Device Policy Controller(DPC)の実装方法を変更することで、デバイスのセットアップが効率化されます。この新しいアプローチでは、カスタム DPC ソリューションが Android Management API(AMAPI)SDK および Android Device Policy と統合され、デバイスの準備とユーザー登録の機能が実行されます。

AMAPI SDK は、デバイス自体で Android デバイス ポリシーを操作するために必要な API を提供します。サーバー側では、Enterprise Mobility Management(EMM)ソリューションが Play EMM API を使用して、デバイス登録プロセスを開始するために必要な登録トークンを生成します。

Android Device Policy アプリは、デバイス側のオペレーションを処理するうえで中心的な役割を担うようになりました。AMAPI SDK は、デバイスでのインストールと必要なアップデートの管理に使用されます。Android Device Policy は、ユーザー認証フローも引き継ぎ、ユーザー認証を直接処理して、ユーザーの ID を EMM に提供します。何らかの理由で Google がユーザーを認証できない場合、新しい managed Google Play アカウントが作成され、フォールバックとしてデバイスに追加されます。

API 統合

開始する前に、Play EMM API クライアントと AMAPI SDK の最新バージョンを使用していることを確認してください。

登録の実装ガイド

このガイドでは、登録を実装するために必要な手順について説明します。環境の準備、さまざまな登録方法の処理、デバイスのライフサイクルの管理について説明します。

環境を準備する

アカウントのセットアップを開始する前に、デバイス環境を準備する必要があります。この準備では、Google Play ストアを最新バージョンに更新し、Android Device Policy(com.google.android.apps.work.clouddpc)をデバイスにサイレント インストールします。Android Device Policy のインストールは、アカウント設定プロセスの重要なコンポーネントを格納しているため、不可欠です。EMM は環境を手動で準備する必要はありません。代わりに、EnvironmentClient を使用し、ドキュメントに記載されているコード例に準拠する必要があります。

サンプルコード

AccountSetup API を使用してデバイスに仕事用アカウントを追加する前に、DPC はまずデバイス環境の準備が整っていることを確認する必要があります。

  • EnvironmentClientFactory を使用して EnvironmentClient をインスタンス化し、prepareEnvironment または prepareEnvironmentAsync を呼び出します。

    val notificationReceiverServiceName = ComponentName(context,
    NotificationReceiver::class.java)
    
    // An EMM should implement android.app.admin.DeviceAdminReceiver and use that
    // class to instantiate a ComponentName
    
    val admin = ComponentName(this, com.example.dpc.DeviceAdminReceiver::class.java)
    
    EnvironmentClientFactory.create(context)
        .prepareEnvironment(
            PrepareEnvironmentRequest.builder()
                .setRoles(
                    listOf(
                        Role.builder().setRoleType(
                            Role.RoleType.DEVICE_POLICY_CONTROLLER
                        ).build()
                    )
                )
        .setAdmin(admin)
                .build(),
              notificationReceiverServiceName,
            )
    
    [Proceed with AccountSetup]
    
    

適切な動作環境を確認するためにアプリケーションがインストールまたは更新されるため、このオペレーションには数秒または数分かかることがあります。Google は、このプロセスをバックグラウンドでできるだけ早く開始し、ユーザーが待機している間は適切な UI を表示することをおすすめします。オペレーションが完了すると、デバイスは DPC が AccountSetup API を使用できる状態になります。

登録フロー

EMM は、すべてのデバイスで users.generateAuthenticationToken()users.insert() の使用を停止する必要があります。代わりに、EMM はデバイス上の API を呼び出してエンドユーザー認証を行う必要があります。新しい API は、DPC に userIdemail を返します。Google がユーザーを認証できない場合、管理対象 Google Play アカウントが作成され、デバイスに追加されます。この場合、Google はそのアカウントの userId を返します。

Google は登録トークンの使用を導入しました。登録トークンは認証 API に渡す必要があります。EMM はトークンを作成するタイミングと方法を決定します。トークンは既存の登録ペイロード(QR コードやゼロタッチ構成など)の一部にすることができます。

ただし、変更を最小限に抑えるため、オンデマンドでトークンを作成し、既存の Managed Google Play Accounts の API を新しい API に置き換えることをおすすめします。

以前の API との一般的な DPC 統合
図 1. 以前の API との一般的な DPC 統合
ユーザーレス デバイス用の新しい API を使用した DPC 統合の例
図 2.ユーザーレス デバイス用の新しい API を使用した DPC 統合の例
ユーザー デバイス用の新しい API を使用した DPC 統合の例
図 3. ユーザー デバイス用の新しい API との DPC 統合の例

改善されたカスタム DPC 登録フローには、次の手順が含まれます。

  1. 登録トークンを作成する: EMM は、Google Play EMM API を使用して登録トークンを作成します。
  2. 環境を準備する: カスタム DPC は、環境を準備するフローを使用して、デバイスが登録の準備ができていることを確認します。
  3. 登録を開始する: カスタム DPC が AMAPI SDK の startAccountSetup API を呼び出し、登録トークンを渡します。注: この API を呼び出す前に、DPC はデバイス オーナーまたはプロファイル オーナーのいずれかである必要があります。
  4. Google 認証アクティビティを起動する: 必要に応じて、カスタム DPC は AMAPI SDK の launchAuthenticationActivity API を呼び出し、AccountSetupAttempt を渡します。これにより、Google 認証アクティビティが開始され、認証が成功するとユーザーはカスタム DPC に戻ります。ユーザーはこのプロセスをスキップすることもできます。この場合、managed Google Play アカウントがデバイスに追加されます。このオプションは、googleAuthenticationOptions を使用して構成できます。
  5. 登録を完了する: AMAPI SDK は、登録結果をカスタム DPC に通知します。
  6. Google サービスを有効にする: 管理対象の Google アカウントが設定されたユーザーのデバイスが企業ポリシーに準拠したら、EMM は Devices.setState() を呼び出す必要があります。この操作により、デバイス上のアカウントで Google サービスにアクセスできるようになります。この呼び出しがないと、Google Play ストアや他の Google サービスは機能しません。

アカウント設定 - サンプルコード

  1. アカウント設定の試行を開始するために、呼び出し元のアプリは AccountSetupClient を使用して、startAccountSetup() メソッドまたは startAccountSetupFuture() メソッドのいずれかを呼び出すことができます。実装例については、次のコードサンプルをご覧ください。

    // Create AccountSetupClient
    val client = AccountSetupClientFactory.create(
        this,
        activityResultRegistry
    )
    lifecycle.addObserver(client.lifecycleObserver)
    
    // Create adminComponent
    val notificationReceiver = ComponentName(this, AccountSetupNotificationReceiver::class.java)
    // Helper method to get enrollment token created with Play EMM API
    val enrollmentToken = getEnrollmentToken()
    val request =
              StartAccountSetupRequest.builder()
                  .setEnrollmentToken(enteredText)
                  .setNotificationReceiverServiceComponentName(notificationReceiver)
                  .setAdminComponentName(
                      ComponentName(this, com.example.dpc.DeviceAdminReceiver::class.java))
                  .build()
    try {
        val accountSetupAttempt = client.startAccountSetup(request)
        // handle attempt
    } catch (e: Exception) {
        // handle exception
    }
      ```
    
  2. AccountSetupListener インターフェースを実装し、受信したステータス更新を処理する方法の実装を提供します。

  3. NotificationReceiverService を拡張し、getAccountSetupListener() をオーバーライドしてステップ 2 で作成した AccountSetupListener インスタンスを指定します。

    // Handles account setup changes
    class AccountSetupNotificationReceiver :
          NotificationReceiverService(),
          AccountSetupListener {
    
        override fun getAccountSetupListener(): AccountSetupListener = this
    
        override fun onAccountSetupChanged(accountSetupAttempt:
      AccountSetupAttempt) {
    
            when (accountSetupAttempt.state.kind) {
                StateCase.ADDED_ACCOUNT -> {
                    val enterpriseAccount = state.addedAccount()
                    val userId = enterpriseAccount.userId
                    val deviceId = enterpriseAccount.deviceId
                    // Handle account added state.
    
                }
                StateCase.AUTHENTICATION_ACTIVITY_LAUNCH_REQUIRED -> {
                    val request = LaunchAuthenticationActivityRequest.builder()
                .setAccountSetupAttempt(accountSetupAttempt)
                .build();
                    // Send the attempt to the foreground activity to call:
                    accountSetupClient.launchAuthenticationActivity(request)
                }
                StateCase.ACCOUNT_SETUP_ERROR -> {
                    // Handle error state.
                    val failureReason = state.accountSetupError().failureReason
                }
                else -> {
                    // Handle unknown account setup attempt state.
                }
            }
        }
    }
    
      ```
    
  4. 拡張された NotificationReceiverService クラスを AndroidManifest.xml に追加し、エクスポートされたことを確認します。

      <application>
        <service
            android:name = ".accountsetup.AccountSetupNotificationReceiver"
            android:exported = "true" />
      </application>
    

    アプリが SDK 30 以降をターゲットとしている場合は、ADP とやり取りすることを指定するために、AndroidManifest.xml に queries 要素が必要です。

      <queries>
        <package android:name="com.google.android.apps.work.clouddpc" />
      </queries>
    

テストのガイダンス

このセクションでは、実装をテストするためのガイドラインとベスト プラクティスについて説明します。

PrepareEnvironment のテスト

  1. デバイスの現在の状態を取得する: EMM は

    adb shell dumpsys package com.google.android.apps.work.clouddpc | grep versionName
    

    デバイスに存在する Android Device Policy のバージョンを取得します。Android デバイス ポリシーがインストールされていない場合、出力は空になります。

  2. PrepareEnvironment を統合する: カスタム DPC は AMAPI SDK の prepareEnvironment API を呼び出し、正しいリクエストを渡します。

  3. PrepareEnvironment の結果を待機: カスタム DPC は prepareEnvironment が完了するまで待機します。

  4. PrepareEnvironment の成功を確認する: 完了すると、EMM が再度実行されます

    adb shell dumpsys package com.google.android.apps.work.clouddpc | grep versionName
    

    このとき、Android Device Policy のバージョンはステップ 1 のバージョンよりも高い必要があります。

Google アカウントの認証をテストする

  1. テスト エンタープライズを作成する: EMM は、テスト EMM にリンクされたテスト ドメインの Google エンタープライズを enterprises.generateSignupUrl で作成します。
  2. Google 認証を有効にする: EMM は、Google 管理コンソールのこちらの手順に沿って、テスト エンタープライズの Google 認証を有効にします。
  3. 登録トークンを作成する: EMM は、タイプ userDevice の Play EMM API を使用して登録トークンを作成します。
  4. 登録を開始する: カスタム DPC が AMAPI SDK の startAccountSetup API を呼び出し、登録トークンを渡します。
  5. アクティビティの起動が必要: AMAPI SDK は、ユーザーを認証するためにアクティビティを起動する必要があることをカスタム DPC に通知します。
  6. ユーザーを認証する: カスタム DPC は launchAuthenticationActivity を呼び出してアクティビティを開始します。ユーザーは、管理対象の Google アカウント(ステップ 1 で作成したエンタープライズの一部)で認証します。
  7. 登録を完了する: AMAPI SDK は、登録結果をカスタム DPC に通知します。

Google 認証のスキップをテストする

ここでは、前述の設定を使用します。

今回は、ステップ 7 で、ユーザーは Google アカウントで認証する代わりに [スキップ] を押します。登録が正常に完了し、デバイスにサービス アカウントがある(つまり、AuthenticationType が匿名である)。

ユーザーのいないデバイスをテストする

改善されたカスタム DPC 登録フローでは、Google 認証が無効になっている場合、次の手順が使用されます。

  1. テスト エンタープライズを作成する: これは、以前に作成したエンタープライズと同じでもかまいません。
  2. 登録トークンを作成する: EMM は、タイプ userlessDevice の Play EMM API を使用して登録トークンを作成します。
  3. 登録を開始する: カスタム DPC が AMAPI SDK の startAccountSetup API を呼び出し、登録トークンを渡します。
  4. 登録を完了する: AMAPI SDK は、登録結果をカスタム DPC に通知します。