エンタープライズ アプリ向け Android 9 の特長

このページでは、Android 9 で利用可能なエンタープライズ API、機能、動作変更の概要について説明します。

仕事用プロファイルのユーザー インターフェース

Android 9（API レベル 28）では、デフォルト ランチャーのユーザー インターフェースが変更され、ユーザーが個人用と仕事用のアプリを分離できるようになりました。この機能をサポートしているデバイス メーカーは、ユーザーのアプリを仕事用と個人用の個別のタブに表示できます。また、ランチャーの仕事用タブにスイッチを含めることで、デバイス ユーザーが仕事用プロファイルを簡単に有効または無効にできるようになりました。

図 1. デフォルト ランチャーの個人用タブと仕事用プロファイルの切り替えを備えた仕事用タブ

Android 9 では、仕事用プロファイルと管理対象デバイスをプロビジョニングする際に、デバイス ユーザーがこれらの機能を理解できるよう、アニメーション化されたイラストが表示されます。

プロファイル間でアプリを切り替える

Android 9 には、異なるプロファイルでアプリの別のインスタンスを起動して、ユーザーがアカウントを切り替えやすくする API が用意されています。たとえば、メールアプリで、ユーザーが個人用プロファイルと仕事用プロファイルを切り替えて 2 つのメール アカウントにアクセスするための UI を用意できます。すべてのアプリは、すでに他のプロファイルにインストールされていれば、これらの API を呼び出して、同じアプリのメイン アクティビティを起動できます。クロスプロファイル アカウントの切り替えをアプリに追加するには、以下の手順に沿って CrossProfileApps クラスのメソッドを呼び出します。

  1. getTargetUserProfiles() を呼び出して、アプリの別のインスタンスを起動できるプロファイルのリストを取得します。このメソッドは、アプリがプロファイルにインストールされていることを確認します。
  2. getProfileSwitchingIconDrawable() を呼び出して、別のプロフィールを表すために使用できるアイコンを取得します。
  3. getProfileSwitchingLabel() を呼び出して、ユーザーにプロファイルの切り替えを求めるローカライズされたテキストを取得します。
  4. startMainActivity() を呼び出して、別のプロファイルでアプリのインスタンスを起動します。

起動したいメイン アクティビティがアプリのマニフェスト ファイルで宣言され、ACTION_MAIN インテントのアクションがあり、CATEGORY_LAUNCHER インテント カテゴリが含まれていることを確認します。

仕事用プロファイルをプログラムでオンまたはオフにする

デフォルトのランチャー（または MANAGE_USERS または MODIFY_QUIET_MODE 権限を持つアプリ）は、UserManager.requestQuietModeEnabled() を呼び出して、仕事用プロファイルのオンとオフを切り替えることができます。この戻り値を調べることで、状態が変化する前にユーザーが認証情報を確認する必要があるかどうかを確認できます。変更がすぐに適用されない可能性があるため、ACTION_MANAGED_PROFILE_AVAILABLE または ACTION_MANAGED_PROFILE_UNAVAILABLE ブロードキャストをリッスンして、ユーザー インターフェースを更新するタイミングを確認します。

アプリは UserManager.isQuietModeEnabled() を呼び出すことで、仕事用プロファイルのステータスを確認できます。

アプリをデバイスにロックダウンする

Android 9 以降では、デバイス所有者と（セカンダリ ユーザーの）プロファイル所有者は、任意のアプリをロックタスク モードにすることで、デバイスの画面をロックできます。これまで、アプリ デベロッパーはアプリにロックタスク モードのサポートを追加する必要がありました。Android 9 では、関連のないセカンダリ ユーザーのプロファイル オーナーにもロックタスク API が拡張されています。アプリを画面にロックする手順は次のとおりです。

  1. DevicePolicyManager.setLockTaskPackages() を呼び出して、ロックタスク モードのアプリを許可リストに登録します。
  2. ActivityOptions.setLockTaskEnabled() を呼び出して、許可リストに登録されたアプリをロックタスク モードで起動します。

ロックタスク モードでアプリを停止するには、DevicePolicyManager.setLockTaskPackages() を使用して、ロックタスク モードの許可リストからアプリを削除します。

システム UI 機能を有効にする

ロックタスク モードが有効になっている場合、デバイス所有者とプロファイル所有者は、DevicePolicyManager.setLockTaskFeatures() を呼び出して次の機能フラグのビットフィールドを渡すことで、デバイスで特定のシステム UI 機能を有効にできます。

ロックタスク モードが有効になっている場合、DevicePolicyManager.getLockTaskFeatures() を呼び出すと、デバイスで使用できる機能のリストを取得できます。デバイスはロックタスク モードを終了すると、他のデバイス ポリシーで規定されている状態に戻ります。

エラー ダイアログを表示しない

販売店デモや公開情報の表示など、環境によっては、エラー ダイアログをユーザーに表示したくない場合があります。Device Policy Controller（DPC）は、DISALLOW_SYSTEM_ERROR_DIALOGS ユーザー制限を追加することで、クラッシュしたアプリや応答しないアプリのシステム エラー ダイアログを抑制できます。この制限は、デバイス所有者が適用した場合、すべてのダイアログに影響しますが、プロファイル所有者が制限を適用した場合は、プライマリ ユーザーまたはセカンダリ ユーザーに表示されるエラー ダイアログのみが抑制されます。この制限は仕事用プロファイルには影響しません。

Android 9 では、没入型全画面モードで実行されているアプリでは、ロックタスク モードのときにリマインダーのふきだしは表示されません。リマインダーのふきだしは、初回起動時にユーザーに表示されるパネルで、没入モードを終了する方法を説明するものです。

専用デバイスで複数のユーザーをサポート

Android 9 では、専用デバイス（旧称 COSU デバイス）向けのエフェメラル ユーザーという概念が導入されています。一時ユーザーとは、複数のユーザーが 1 台の専用デバイスを共有する場合を対象とする短期ユーザーです。これには、図書館やホテルのチェックイン キオスクなどのデバイス上の一般公開ユーザー セッションや、デバイス上の特定のユーザーセット（シフト勤務者など）間の永続的なセッションが含まれます。

一時ユーザーはバックグラウンドで作成する必要があります。これらのユーザーはデバイスでセカンダリ ユーザーとして作成され、ユーザーを停止、切り替え、またはデバイスの再起動時に（関連するアプリとデータとともに）削除されます。デバイス所有者は、次の方法でエフェメラル ユーザーを作成できます。

  1. DevicePolicyManager.createAndManageUser() を呼び出すときに MAKE_USER_EPHEMERAL フラグを設定します。
  2. DevicePolicyManager.startUserInBackground() を呼び出して、エフェメラル ユーザーをバックグラウンドで起動します。

なお、Android 9 をターゲットとするアプリでは、createAndManageUser() を呼び出すときに UserManager.UserOperationException をキャッチする必要があります。例外の getUserOperationResult() メソッドを呼び出して、ユーザーが作成されなかった理由を調べます。

アクティビティ通知を受信する

DeviceAdminReceiver は、次のイベントに関する通知を受け取ります。

ユーザーにイベント メッセージを表示する

デバイス オーナーは、セッションの開始時と終了時にユーザーに表示されるメッセージを構成できます。

ログアウトしてユーザーを停止

デバイス所有者は、DevicePolicyManager.setLogoutEnabled() を使用して、セカンダリ ユーザーに対してログアウトを有効にするかどうかを指定できます。ログアウトが有効になっているかどうかを確認するには、DevicePolicyManager.isLogoutEnabled() を呼び出します。

セカンダリ ユーザーのプロファイル オーナーは、DevicePolicyManager.logoutUser() を呼び出してセカンダリ ユーザーを停止し、プライマリ ユーザーに戻すことができます。

デバイス所有者は、DevicePolicyManager.stopUser() を使用して、指定されたセカンダリ ユーザーを停止できます。

パッケージのキャッシュ

シフト勤務者用のデバイスなど、固定のユーザーセットがいる共有デバイスでのユーザー プロビジョニングを効率化するために、マルチユーザー セッションに必要なパッケージをキャッシュに保存できます。

  1. DevicePolicyManager.setKeepUninstalledPackages() を呼び出して、APK として保持するパッケージのリストを指定します。これらのパッケージのリストを取得するには、DevicePolicyManager.getKeepUninstalledPackages() を呼び出します。

  2. DevicePolicyManager.installExistingPackage() を呼び出して、setKeepUninstalledPackages() で削除後も保持されているパッケージをインストールします。

追加のメソッドと定数

Android 9 には、共有デバイスでのユーザー セッションをさらにサポートするために、次のメソッドと定数も含まれています。

パッケージデータを消去してアカウントを削除する

デバイス所有者とプロファイル所有者は、clearApplicationUserData() を呼び出して、特定のパッケージのユーザーデータを消去できます。AccountManager からアカウントを削除する場合、デバイス オーナーとプロファイル オーナーは removeAccount() を呼び出します。

ユーザーの制限と設定の管理の強化

Android 9 では、DPC に関する一連のユーザー制限と、APN、時刻とタイムゾーン、デバイスのシステム設定を構成する機能が導入されています。

APNs を設定する

デバイス所有者は、DevicePolicyManager クラスの次のメソッドを使用して、デバイスに APN を設定できます。

時刻とタイムゾーンを設定する

デバイス所有者は、DevicePolicyManager クラスの次のメソッドを使用して、デバイスの時刻とタイムゾーンを設定できます。

重要な設定にユーザー制限を適用する

Android 9 では、システムの機能や設定を無効にするユーザー制限が追加されています。制限を追加するには、次のいずれかの UserManager 定数を使用して DevicePolicyManager.addUserRestriction() を呼び出します。

DISALLOW_CONFIG_BRIGHTNESS と DISALLOW_CONFIG_SCREEN_TIMEOUT がデバイスに適用されている場合、デバイス所有者は引き続き API DevicePolicyManager.setSystemSetting() を使用して、画面の明るさ、画面の明るさモード、画面タイムアウトの設定を行えます。

従量制データ

デバイス所有者とプロファイル所有者は、アプリがデバイスの従量制データ ネットワークを使用できないようにできます。コスト、データの上限、バッテリーとパフォーマンスの問題が原因で、ユーザーが大量のデータ使用量を気にしている場合、ネットワークは従量制とみなされます。アプリが従量制ネットワークを使用できないようにするには、DevicePolicyManager.setMeteredDataDisabledPackages() を呼び出してパッケージ名のリストを渡します。現在制限されているアプリを取得するには、DevicePolicyManager.getMeteredDataDisabledPackages() を呼び出します。

Android の従量制データについて詳しくは、ネットワーク データ使用量の最適化をご覧ください。

DPC の移行

Device Policy Controller（DPC）は、デバイスまたは仕事用プロファイルの所有権を別の DPC に譲渡できます。オーナー権限を譲渡して、一部の機能を Android Management API に移行したり、従来の DPC からデバイスを移行したり、IT 管理者の EMM への移行を支援したりすることが可能です。DPC の所有権を変更するだけであるため、この機能を使用して管理の種類を変更することはできません。たとえば、管理対象デバイスから仕事用プロファイルに移行したり、その逆を行うことはできません。

デバイス管理ポリシーの XML リソースを使用して、このバージョンの DPC が移行をサポートしていることを示すことができます。ターゲット DPC は、<support-transfer-ownership> という名前の要素を含めることで、所有権を取得できることを示します。次の例は、DPC のデバイス管理 XML ファイルでこれを行う方法を示しています。

<device-admin xmlns:android="http://schemas.android.com/apk/res/android">
    <support-transfer-ownership />
    <uses-policies>
        <limit-password />
        <watch-login />
        <reset-password />
    </uses-policies>
</device-admin>

所有権を新しい DPC アプリに移行する DPC は、DeviceAdminInfo メソッド supportsTransferOwnership() を呼び出して、ターゲット DPC のバージョンが移行をサポートしているかどうかを確認できます。所有権を移行する前に、ソース DPC がアプリの署名を比較してターゲット DPC を検証します。PackageManager クラスには、コード署名署名を操作するためのメソッドが含まれています。

Android は、所有権の移行を通じて移行元 DPC のシステムとユーザー ポリシーを保持するため、DPC による移行は必要ありません。ソース DPC は、PersistableBundle 内の Key-Value ペアを使用して、カスタムデータをターゲット DPC に渡すことができます。転送が成功した後、ターゲット DPC は DevicePolicyManager.getTransferOwnershipBundle() を呼び出してこのデータを取得できます。

管理対象デバイスと仕事用プロファイルの所有権を移行する手順は、同じです。

  1. ソース DPC は、ターゲット DPC のバージョンが移行をサポートしていることを確認し、ターゲット DPC のアプリ署名が期待値と一致することを確認します。
  2. 移行元 DPC が transferOwnership() を呼び出して転送を開始します。
  3. システムは、ターゲット DPC をアクティブ管理者にし、管理対象デバイスまたは仕事用プロファイルの所有者として設定します。
  4. ターゲット DPC はコールバック onTransferOwnershipComplete() を受け取り、bundle 引数の値を使用して自身を設定できます。
  5. 移行中に問題が発生した場合は、所有権が移行元 DPC に戻されます。移行元の DPC が所有権の移行が成功したことを確認する必要がある場合は、isAdminActive() を呼び出して、移行元の DPC がアクティブな管理者ではなくなったことを確認します。

仕事用プロファイルで実行されているすべてのアプリは、プロファイルの所有者が変更されると ACTION_PROFILE_OWNER_CHANGED ブロードキャストを受信します。管理対象デバイスで実行されているアプリは、デバイス所有者が変更されると ACTION_DEVICE_OWNER_CHANGED ブロードキャストを受信します。

完全管理対象デバイスの仕事用プロファイル

デバイス所有者とプロファイル所有者として実行されている DPC の 2 つのインスタンスの転送は、2 段階で行われます。個人用プロファイルと仕事用プロファイルが関連付けられている場合は、次の順序で移行を完了します。

  1. まず、仕事用プロファイルのオーナー権限を譲渡します。
  2. 仕事用プロファイルがターゲット DPC に転送されたことを確認するため、DeviceAdminReceiver コールバック onTransferAffiliatedProfileOwnershipComplete() を待ちます。
  3. 最後に、管理対象デバイスの所有権を移行先 DPC に移行します。

無線（OTA）アップデートを延期する

デバイス所有者は、デバイスの OTA システム アップデートを最大 90 日間延期し、重要な期間（休日など）に、そのデバイスで実行されている OS バージョンを凍結できます。システムは、定義済みの凍結期間の後に 60 日間のバッファを必須とし、デバイスが無期限にフリーズするのを防ぎます。

凍結期間中:

  • デバイスは保留中の OTA アップデートに関する通知を受信しません。
  • デバイスは OS に OTA アップデートをインストールしません。
  • デバイス ユーザーが、[設定] で OTA アップデートを手動で確認できない。

凍結期間を設定するには、SystemUpdatePolicy.setFreezePeriods() を呼び出します。凍結期間は毎年繰り返されるため、期間の開始日と終了日は、年の開始からの日数を示す整数で表されます。開始日は、前回の凍結期間の終了日から少なくとも 60 日後にする必要があります。デバイス所有者は SystemUpdatePolicy.getFreezePeriods() を呼び出すことで、以前にシステム アップデート ポリシー オブジェクトで設定された凍結期間のリストを取得できます。DevicePolicyManager.getSystemUpdatePolicy() が更新され、デバイス所有者が設定した凍結期間を返すようになりました。

仕事用プロファイルへの共有を制限する

プロファイルの所有者は、ユーザー制限 DISALLOW_SHARE_INTO_MANAGED_PROFILE を追加することで、ユーザーがデバイス上の仕事用プロファイルに個人データを共有できないようにします。この制限により、次のようなインテントの処理と共有ができなくなります。

  • 個人用プロファイルのアプリが仕事用プロファイルのアプリとデータおよびファイルを共有。
  • 個人用プロファイルからアイテム（画像やファイルなど）を選択する仕事用プロファイル アプリ。

この制限を設定した後も、DPC で addCrossProfileIntentFilter() を呼び出すことで、クロス プロファイル アクティビティ インテントを許可できます。

ハードウェアで保護された鍵とマシン証明書

Android 9 には、鍵と証明書を組み合わせてデバイスを安全に識別するための API が追加されています。プロファイル所有者モードまたはデバイス所有者モードで実行されている DPC、または委任された証明書インストーラは、次のタスクを実行できます。

  • Android デバイスのセキュア ハードウェア（高信頼実行環境（TEE）やセキュア エレメント（SE）など）で鍵と証明書を生成する。生成された鍵はセキュア ハードウェアの外に出ることはなく、Android KeyChain から使用できます。DevicePolicyManager.generateKeyPair() を呼び出して、アルゴリズム（KeyPairGenerator を参照）と証明対象のハードウェア ID（シリアル番号や IMEI など）を指定します。セキュア ハードウェアの変更について詳しくは、Android 9 のセキュリティ強化をご覧ください。
  • 証明書を、デバイスで生成された既存の鍵に関連付ける。DevicePolicyManager.setKeyPairCertificate() を呼び出して、既存の鍵と証明書チェーンのエイリアスを指定します（リーフ証明書で始まり、信頼チェーンを順番に含めます）。
  • キーを使用する前に、セキュア ハードウェアでキーが保護されていることを確認してください。鍵を保護するメカニズムを確認するには、鍵構成証明の手順に沿って操作してください。
  • デバイス所有者と委任された証明書インストーラは、Android システム バージョンを含むデバイスのハードウェア ID の署名付きステートメントを受信できます。DevicePolicyManager.generateKeyPair() を呼び出して、idAttestationFlags 引数で ID_TYPE_BASE_INFO、ID_TYPE_SERIAL、ID_TYPE_IMEI、ID_TYPE_MEID の 1 つ以上を渡します。返される証明書には、構成証明レコードのハードウェア ID が含まれます。ハードウェア ID を含めない場合は、0 を渡します。プロファイル所有者は（ID_TYPE_BASE_INFO を渡すことによって）メーカー情報のみを受け取ることができます。デバイスが ID を証明できることを確認するには、isDeviceIdAttestationSupported() を呼び出します。
  • 鍵証明書を選択不可にすることで、デバイス ユーザーがエンタープライズ鍵を（エンタープライズ以外のタスクで）不正使用するのを防止します。選択できない証明書は選択ツールパネルに表示されません。DeviceAdminReceiver.onChoosePrivateKeyAlias() コールバック メソッドで、エイリアスを企業鍵に返し、システムがユーザーに代わって証明書を自動的に選択するようにします。キーを選択不可にするには、次の DevicePolicyManager メソッドを呼び出します。

これらの API を組み合わせることで、企業はアクセスを提供する前にデバイスを安全に識別し、その完全性を確認できます。

  1. Android デバイスは、セキュア ハードウェアに新しい秘密鍵を生成します。 秘密鍵はセキュア ハードウェアの外部に出ることはなく、外部に漏えいしません。
  2. デバイスはこの鍵を使用して証明書署名リクエスト（CSR）を作成し、サーバーに送信します。CSR には、デバイス ID を含む構成証明レコードが含まれます。
  3. サーバーは（Google 証明書をルートとする）証明書チェーンを検証し、構成証明レコードからデバイスのメタデータを抽出します。
  4. サーバーは、セキュア ハードウェアが秘密鍵を保護し、デバイス ID が企業のレコードと一致することを確認します。サーバーは、Android システムとパッチ バージョンが要件を満たしていることもチェックできます。
  5. サーバーは CSR から証明書を生成し、その証明書をデバイスに送信します。
  6. デバイスは証明書と秘密鍵（セキュア ハードウェアに保持されます）をペアリングして、アプリがエンタープライズ サービスに接続できるようにします。

その他のセキュリティ API、機能、変更点

セキュリティ ログとネットワーク ログの ID

Android 9 では、セキュリティとネットワーク アクティビティ ログに ID が含まれています。この数値 ID はイベントごとに単調に増加するため、IT 管理者はログ内のギャップを見つけやすくなります。セキュリティ ログとネットワーク ログは別々のコレクションであるため、システムは個別の ID 値を保持します。

SecurityEvent.getId()、DnsEvent.getId()、ConnectEvent.getId() のいずれかを呼び出して、ID 値を取得します。DPC がロギングを有効にするたびに、またはデバイスが再起動されると、システムによって ID がリセットされます。DevicePolicyManager.retrievePreRebootSecurityLogs() の呼び出しで取得されたセキュリティ ログには、これらの ID は含まれません。

セキュリティ ロギング

セキュリティ ロギングは、各 SecurityEvent にログレベルを割り当てます。ログレベルを取得するには、getLogLevel() を呼び出します。このメソッドは、ログレベルの値を返します。この値は、LEVEL_INFO、LEVEL_WARNING、LEVEL_ERROR のいずれかです。

Android 9 では、以下の表に記載されているイベントがセキュリティ ログに記録されます。イベントタグを確認するには、getTag() を呼び出します。イベントデータを取得するには、getData() を呼び出します。

タグ 予定の説明
TAG_CERT_AUTHORITY_INSTALLED 新しいルート証明書をシステムの認証情報ストレージにインストールしようとします。
TAG_CERT_AUTHORITY_REMOVED システムの認証情報ストレージからルート証明書を削除しようとした場合。
TAG_CERT_VALIDATION_FAILURE 接続中に Wi-Fi 証明書の検証チェックに失敗しました。
TAG_CRYPTO_SELF_TEST_COMPLETED システムが暗号のセルフテストを完了しました。
TAG_KEYGUARD_DISABLED_FEATURES_SET 管理アプリによって、デバイスまたは仕事用プロファイルのロック画面の機能が無効になりました。
TAG_KEY_DESTRUCTION 暗号鍵を削除しようとした場合。
TAG_KEY_GENERATED 新しい暗号鍵の生成試行。
TAG_KEY_IMPORT 新しい暗号鍵のインポートの試行。
TAG_KEY_INTEGRITY_VIOLATION 破損した暗号鍵または認証キーが検出されました。
TAG_LOGGING_STARTED セキュリティ ロギングの記録を開始しました。
TAG_LOGGING_STOPPED セキュリティ ロギングは記録を停止しました。
TAG_LOG_BUFFER_SIZE_CRITICAL セキュリティ ログ バッファが容量の 90% に達しました。
TAG_MAX_PASSWORD_ATTEMPTS_SET 管理アプリで、パスワード不正試行の許容回数が設定されている。
TAG_MAX_SCREEN_LOCK_TIMEOUT_SET 管理アプリで最大画面ロック タイムアウトが設定されている。
TAG_MEDIA_MOUNT デバイスがリムーバブル ストレージ メディアをマウントしました。
TAG_MEDIA_UNMOUNT デバイスがリムーバブル ストレージ メディアのマウントを解除しました。
TAG_OS_SHUTDOWN Android システムがシャットダウンされました。
TAG_OS_STARTUP Android システムが起動しました。
TAG_PASSWORD_COMPLEXITY_SET 管理アプリで、パスワードの複雑さに関する要件を設定している。
TAG_PASSWORD_EXPIRATION_SET 管理アプリでパスワードの有効期限が設定されている。
TAG_PASSWORD_HISTORY_LENGTH_SET 管理アプリでパスワードの履歴の長さが設定され、ユーザーが古いパスワードを再利用できないようになっています。
TAG_REMOTE_LOCK 管理アプリがデバイスまたは仕事用プロファイルをロックしました。
TAG_USER_RESTRICTION_ADDED 管理アプリがユーザー制限を設定している。
TAG_USER_RESTRICTION_REMOVED 管理アプリがユーザー制限を削除しました。
TAG_WIPE_FAILURE デバイスまたは仕事用プロファイルをワイプできませんでした。

仕事用プロファイルのロック画面チャレンジ

Android 9 以降では、プロファイルの所有者は、DISALLOW_UNIFIED_PASSWORD ユーザー制限を使用して、仕事用プロファイルに個別のロック画面チャレンジを設定するようユーザーに要求できます。ユーザーがデバイスと仕事用プロファイルで同じロック画面チャレンジを設定しているかどうかを確認するには、DevicePolicyManager.isUsingUnifiedPassword() を呼び出します。

デバイスに仕事用プロファイルのロック画面が分離されている場合、DevicePolicyManager.setMaximumTimeToLock() はデバイス全体ではなく、仕事用プロファイルに対してのみロック画面のタイムアウトを設定します。

デベロッパー ツールへのアクセス

仕事用プロファイルに仕事用データを保持するために、Android Debug Bridge（adb）ツールは仕事用プロファイルのディレクトリやファイルにアクセスできません。

追加の生体認証オプションのサポート

Android 9 では、仕事用プロファイルのロック画面での生体認証ハードウェア認証をきめ細かく制御できます。KEYGUARD_DISABLE_FACE と KEYGUARD_DISABLE_IRIS を使用して既存の DevicePolicyManager.setKeyguardDisabledFeatures() メソッドを呼び出します。デバイスが提供する生体認証方法をすべて無効にするには、KEYGUARD_DISABLE_BIOMETRICS を追加します。

デバイス管理ポリシーのサポート終了

Android 9 では、デバイス管理を使用する DPC の以下のポリシーが、非推奨となります。ポリシーは以前と同様に Android 9 で引き続き機能します。Android 10 リリース以降では、同じポリシーがデバイス管理者によって呼び出されると、SecurityException がスローされます。

アプリによっては、ユーザーのデバイス管理のためにデバイス管理コンポーネントを利用している場合があります。たとえば、紛失したデバイスのロックやワイプなどです。これを有効にするために、次のポリシーは引き続き利用できます。

これらの変更について詳しくは、デバイス管理のサポート終了をご覧ください。

QR コード登録の効率化

組み込みの QR ライブラリ

Android 9 には、QR コードによるデバイスのプロビジョニングを効率化する QR ライブラリがバンドルされています。IT 管理者は、デバイスを設定するときに手動で Wi-Fi の詳細を入力する必要がなくなりました。Android 9 では、こうした Wi-Fi の詳細情報を QR コードに含めることができます。IT 管理者が会社所有デバイスで QR コードをスキャンすると、デバイスは自動的に Wi-Fi に接続され、追加の手動入力なしでプロビジョニング プロセスに入ります。

QR コードのプロビジョニング方式では、Wi-Fi の詳細を指定するための次のプロビジョニング エクストラがサポートされています。

プロビジョニング エクストラを使用して日付とタイムゾーンを設定する

QR コードのプロビジョニング方法では、デバイスの時刻とタイムゾーンを設定するためのプロビジョニング エクストラがサポートされています。

データのワイプ オプション

デバイス管理者は、仕事用プロファイルまたはセカンダリ ユーザーを削除するときに、ユーザーにカスタマイズされたメッセージを表示できます。このメッセージは、IT 管理者が仕事用プロファイルまたはセカンダリ ユーザーを削除したことをデバイス ユーザーが把握するのに役立ちます。wipeData(int, CharSequence) を呼び出して、簡単な説明を入力します。プライマリ ユーザーまたはデバイス所有者によって呼び出された場合、システムはメッセージを表示せずに、デバイスの出荷時設定へのリセットを開始します。

埋め込み eUICC SIM からサブスクリプション データを削除するには、wipeData() を呼び出して、flags 引数に WIPE_EUICC を含めます。

関係するプロフィール オーナーへの連絡方法

関連するプロフィールのオーナーは、次のメソッドを使用できます。