デベロッパー ガイド

Android のエンタープライズ機能により、組織は安全で柔軟性の高い モバイルデバイス、アプリ、モバイルデバイスを組み合わせた統合的な Android モビリティ プラットフォーム 簡単になります。Android アプリは Android のエンタープライズ機能に対応している できます。これに加えて、Google Chat で アプリは管理対象の Android デバイスで最適に動作します。

• 仕事用プロファイルの互換性 - Android に変更を加える 管理対象デバイスで最適に機能します。
• 管理対象設定 - 変更 IT 管理者はカスタム 管理できます。
• 専用デバイス - Android デバイスにキオスクとしてデプロイできるようにする必要があります。
• シングル サインオン（SSO） - ログイン プロセスを簡素化できます ユーザーが管理対象の Android デバイスでさまざまなアプリにログインする際の暗号化機能を実装できます。

前提条件

1. Android アプリが作成されました。
2. 次は、組織に最適なアプリになるようにアプリを変更します。
3. 最小バージョン: Android 5.0 Lollipop 推奨バージョン: Android 6.0 Marshmallow 以降。

注: Android のエンタープライズ機能は、ほとんどの Android 5.0 デバイスAndroid 6.0 以降では 特に専用デバイスの場合は、追加の機能が必要になります。

仕事用プロファイル

ユーザーのビジネスデータとアプリケーションは、 仕事用プロファイル。仕事用プロファイルとは、企業が管理する管理対象プロファイルです。 Android デバイスのメインユーザー アカウントに関連付けられているユーザー ID が必要です。 仕事用プロファイルにより、仕事用のアプリやデータを個人用アプリから安全に分離 データです。この仕事用プロファイルは、サービス アカウントとは別のコンテナにあります。 ユーザー自身が管理できます。これらの個別のプロファイルは 組織は重要なビジネスデータを管理できますが、 ユーザーのデバイスの他のものはすべてユーザーの管理下に置くことができます。 ベスト プラクティスについて詳しくは、 仕事用プロファイル ご覧くださいベスト プラクティスの概要については、以下をご覧ください。

仕事用プロファイルの主な機能

• 分離された安全なプロファイル
• アプリの配布用の managed Google Play
• 個別のバッジ仕事用アプリケーション
• 管理者によって制御されるプロファイルのみの管理機能

Android 5.0 以降での仕事用プロファイルのメリット

• デバイス全体の暗号化
• 両方のプロファイルに 1 つの Android Application Package（APK） デバイスに個人用プロファイルと仕事用プロファイルが設定されている
• Device Policy Controller（DPC）は仕事用プロファイルに限定されています
• デバイス管理 DevicePolicyManager クラス

仕事用プロファイルに関する考慮事項

• Android システムがインテントを プロファイルをまたいで検出し、IT 管理者が システムアプリを有効または無効にします。
• 有効なファイルパス（URI: Uniform Resource Identifier） 一方のプロファイルはもう一方のプロファイルでは有効になりません。

プロファイル間でインテントが失敗するのを防ぐ

プロファイル間でどのインテントが交差する可能性があるかを把握するのは困難です。 表示されます。確実に知るための唯一の方法は、テストすることです。 アプリがアクティビティを開始する前に、 呼び出しによって解決されます。 Intent.resolveActivity()。

• null が返された場合、リクエストは解決されません。
• 何かが返された場合は、インテントが解決されたことが示されます。 インテントを送信することもできます。

注: 詳細なテスト手順については、以下をご覧ください。 インテントの失敗を防ぐ。

プロファイル間でファイルを共有する

Android では、URI を使用してファイルパスをマークしている場合があります。ただし、 仕事用プロファイルが存在する場合は個別のファイル システムがあるため、 次のことをおすすめします。

使用: コンテンツ URI	コンテンツ URI には、コンテンツの認証局、パス、ID が 表示されます。これを生成するには、 FileProvider サブクラスを使用できます。 詳細 次を使用してコンテンツ URI を共有し、アクセス権限を付与します。 できます。権限はプロファイル間でのみ渡すことができます 作成することもできます。別のアプリにアクセス権を付与した場合 ファイルに追加します。 Context.grantUriPermission() ロールが付与されるのは、 同じプロファイルで管理できます。
使用しない: ファイルの URI	デバイス上のファイルの絶対パスを指定します。 ストレージです。 あるプロファイルで有効なファイルパス URI が、あるプロファイルでは有効でない 定義します。 インテントにファイル URI をアタッチした場合、ハンドラは 別のプロファイルでそのファイルにアクセスできます。

次のステップ: アプリが管理対象デバイスに対応した後 仕事用プロファイルでテストする必要がありますアプリをテストするをご覧ください。

管理対象設定を実装する

管理対象設定は、IT 管理者が を使用して、ユーザーのモバイル デバイスを特定の方法で管理できます。 これらの手順はどの EMM でも共通なので、 管理者がユーザーのリモート環境でアプリケーションを 対応しています。

ビジネスや行政機関向けのアプリを開発する場合は、 業種固有の要件を満たすことができます使用 構成する場合、IT 管理者はリモートでその構成を ユーザーの Android アプリの設定とポリシーの適用。 例:

• アプリがモバイル/3G 経由でデータを同期できるようにするか、Wi-Fi のみと同期するかを設定します
• ウェブブラウザで URL を許可またはブロックする
• アプリのメール設定を行う
• 印刷を有効または無効にする
• ブックマークの管理

管理対象設定の実装に関するベスト プラクティス

管理対象設定のセットアップ 「インフラストラクチャの構築とデプロイの方法」 構成を管理します。このドキュメントを確認したら、 以下の推奨事項をご確認ください。

アプリを初めて起動したとき

アプリケーションを起動するとすぐに、 onStart() でこのアプリの設定がすでに設定されています、または onResume()。また アプリがマネージドか非マネージドかですたとえば getApplicationRestrictions() は次のものを返します。

• アプリケーション固有の一連の制限 - アプリケーション固有の制限 マネージド構成をサイレントで構成できる できます。
• 空のバンドル - アプリケーションは以下のように動作します。 管理対象外である（個人用アプリにおけるアプリの動作など） プロフィール）。
• 1 つの Key-Value ペアを含むバンドル KEY_RESTRICTIONS_PENDING を true に設定する - アプリは管理されていますが、DPC が構成されていません。 確認します。このユーザーをアプリからブロックし、 IT 管理者に依頼できます

管理対象設定の変更をリッスンする

IT 管理者は管理対象設定を変更したり、 ユーザーにいつでも適用できます。理由 アプリが新しい仕様を受け入れ、 次の制限が適用されます。

• 起動時の取得制限 - アプリは onStart() の getApplicationRestrictions() に電話 および onResume()、古い制限と比較します。 変更が必要かどうかを確認します。
• 実行中に聴く - 動的に登録 ACTION_APPLICATION_RESTRICTIONS_CHANGED: 実行中のアクティビティやサービス あります。このインテントが送信されるのは、このインテントが アプリで宣言されたリスナーではなく、動的に登録される 使用します。
• 実行中でないときに登録を解除する - onPause() で、 配信への登録を解除する必要があります。 ACTION_APPLICATION_RESTRICTIONS_CHANGED。

専用デバイス

専用デバイスはキオスク デバイスとして使用される デジタル サイネージのディスプレイ、チケット販売、 キオスクやサイネージ、

Android デバイスを専用デバイスとして設定した場合、 ホーム画面や最近使ったアプリがない状態で画面にロックされているアプリ ボタンをタップしてアプリを終了します。専用デバイスは、特定のセッションを たとえば、図書館のキオスクと図書館用のアプリ カタログ、ウェブブラウザです

手順については、以下をご覧ください。 専用デバイス。

Chrome カスタムタブを使用したシングル サインオンの設定

企業ユーザーは多くの場合、デバイスに複数のアプリをインストールしており、 1 回のログインですべての仕事用アプリケーションにアクセスすることを好む傾向があります。 通常、ユーザーは WebView この方法が最適でない理由はいくつかあります。

1. 多くの場合、ユーザーは同じアカウントで複数回ログインする必要がある 認証情報が必要です。WebView ソリューションは、多くの場合、 簡単に管理できます。
2. 悪意のあるアプリケーションなど、セキュリティ リスクが存在する可能性がある Cookie の検査や JavaScript® の挿入によってユーザーの認証情報にアクセスする 認証情報が必要です。信頼できるデベロッパーでさえも 悪意のある可能性のあるサードパーティの SDK をスキャンできます。

どちらの問題も、ブラウザを使用してユーザーを認証することで解決できます。 WebView ではなくカスタムタブ。これにより、認証は以下を保証します。

• 安全なコンテキスト（システム ブラウザ）で行われ、ホストアプリが コンテンツを検査できません。
• Cookie の状態が共有されており、ユーザーがログインするだけで済むようにする 1 回だけです。

要件

カスタムタブは API レベル 15（Android 4.0.3）までサポートされます。 カスタムタブを使用するには、Chrome などの対応ブラウザが必要です。 Chrome 45 以降では、この機能を Chrome カスタムタブ。

カスタムタブを使用した SSO を実装するにはどうすればよいですか？

Google は、カスタム Google Cloud の OpenID Connect ワーキング グループに OpenID Foundation へようこそ。Google Workspace で SSO 用のカスタムタブを設定するには、 AppAuth ライブラリについては、 ドキュメントとサンプルコード （GitHub）をご覧ください。

アプリをテストする

アプリの開発が完了したら、仕事用プロファイルと完全版のアプリの両方で 管理できます。下記の手順をご覧ください。

Test DPC を使用して Android アプリをテストする

Android デベロッパーが企業でアプリをテストできる Test DPC アプリを提供しています。 できます。テスト DPC を使用すると、 管理する場合と同様です。Test DPC をデバイスにインストールするには、次の操作を行います。 次のいずれかの方法を選択します。

• テスト DPC のインストール元 Google Play:
• 上のソースからビルドする GitHub。

Test DPC の設定方法について詳しくは、以下の手順と テスト DPC ユーザー ガイドをご覧ください。

仕事用プロファイルをプロビジョニングする

仕事用プロファイルでアプリをテストするには、まず 次の手順で DPC アプリをテストします。

1. デバイスに Test DPC をインストールします。
2. Android ランチャーで、[Set up Test DPC] アプリのアイコンをタップします。
3. 画面の手順に沿って操作します。
4. デバイスにアプリをインストールして、仕事用プロファイルでの動作をテストします。

Android によって仕事用プロファイルが作成され、仕事用プロファイルに Test DPC のコピーがインストールされます。使用するリソース Test DPC のワークバッジ インスタンスを使用して、仕事用プロファイルでポリシーと管理対象設定を設定します。宛先 開発用の仕事用プロファイルの設定について詳しくは、デベロッパー ガイドをご覧ください 仕事用プロファイル。

完全管理対象デバイスのプロビジョニング

組織はフルマネージド デバイスを使用する。これは、あらゆる管理を強制的に適用できる 管理できます。完全管理対象デバイスをプロビジョニングするには、次の手順を行います。

1. デバイスに Test DPC をインストールします。
2. デバイスに他のユーザーや仕事用プロファイルが存在しないことを確認します。
3. デバイス上にアカウントがないことを確認します。
4. 次の Android Debug Bridge（adb）コマンドを ターミナルに次のコマンドを入力します。

   adb shell dpm set-device-owner com.afwsamples.testdpc/.DeviceAdminReceiver

5. デバイス所有者のプロビジョニングが完了したら、そのデバイス上でアプリをテストできます。マイページ どのようにテストすべきかを 管理対象設定と インテントが機能します。

他のプロビジョニング方法を使用することもできます。Test DPC ユーザーガイドをご覧ください。IT 部門が 管理者は通常、Android 搭載デバイスの登録とプロビジョニング、 プロビジョニング 。

エンドツーエンド テスト

上記の環境でアプリのテストが終わったら、 エンドツーエンドの本番環境でアプリをテストし できます。このプロセスには、お客様が 組織でのアプリのデプロイには、次の点が含まれます。

• Google Play を通じたアプリの配信
• サーバーサイドの管理対象設定
• サーバーサイドのプロファイル ポリシー管理

エンドツーエンドの実装を完了するには、EMM コンソールにアクセスする必要があります 説明します。最も簡単な取得方法は、テスト コンソールをリクエストすることです。 EMM からインポートします。アクセスできるようになったら、次のタスクを完了します。

1. アプリケーションのテスト バージョンを new ApplicationId:
2. 管理対象の Google ドメインを申請して EMM にバインドする。もし EMM にバインド済みのテスト用ドメインがある場合は、 バインドを解除し、お好みの EMM でテストします。詳しくは、 具体的なバインド解除手順用の EMM。
3. アプリケーションをプライベート チャンネルに公開して、 マネージド Google ドメインです。
4. EMM コンソールと EMM アプリケーションを使ってできること: <ph type="x-smartling-placeholder">
   </ph>
   1. 仕事用デバイスをセットアップします。
   2. アプリケーションを配布します。
   3. 管理対象設定を行います。
   4. デバイス ポリシーを設定する。

このプロセスは EMM によって異なります。詳しくは、 詳しくは、EMM のドキュメントをご覧ください。お疲れさまでした。完了しました エンタープライズ ユーザーでもアプリが適切に動作することを確認しました。