Android のエンタープライズ機能は、デバイス、アプリケーション、管理機能を組み合わせた、安全で柔軟かつ統合された Android モビリティ プラットフォームを組織に提供します。Android アプリは、デフォルトで Android のエンタープライズ機能に対応しています。ただし、次の機能を使用すると、管理対象の Android デバイスでアプリを最適に動作させることができます。
- 仕事用プロファイルの互換性 - 管理対象デバイスで最適に動作するように Android アプリを変更します。
- 管理対象設定 - アプリを変更して、IT 管理者がアプリのカスタム設定を指定できるようにします。
- 専用デバイス - Android デバイスにキオスクとしてデプロイできるようにアプリを最適化します。
- シングル サインオン（SSO） - 管理対象の Android デバイスでさまざまなアプリにログインするユーザーのログイン プロセスを簡素化します。
前提条件
- Android アプリの作成が完了しました。
- 組織にとって最適に動作するようアプリを変更する準備が整いました。
- 最小バージョン: Android 5.0 Lollipop 推奨バージョン: Android 6.0 Marshmallow 以降
注: Android のエンタープライズ機能は Android 5.0 デバイスのほとんどに組み込まれていますが、Android 6.0 以降では、特に専用デバイスに関する追加機能が提供されます。
仕事用プロファイル
仕事用プロファイルを通じてユーザーのビジネスデータとアプリケーションを管理できます。仕事用プロファイルとは、Android デバイスのプライマリ ユーザー アカウントに関連付けられた管理対象企業プロファイルです。仕事用プロファイルを使用すると、仕事用のアプリやデータを個人用のアプリやデータから安全に分離できます。この仕事用プロファイルは、ユーザーが管理する個人用プロファイルとは別のコンテナ内にあります。こうした個別のプロファイルを使用することで、業務に関係するデータを管理しながら、デバイス上のデータ以外はすべてユーザーの管理下に置くことができます。 おすすめの方法については、仕事用プロファイル ガイドをご覧ください。ベスト プラクティスの概要については、以下をご覧ください。
仕事用プロファイルの主な機能
- 独立した安全なプロファイル
- アプリ配信用の managed Google Play
- 個別のバッジ付き仕事用アプリケーション
- プロフィールのみの管理機能を管理者が制御
Android 5.0 以降の仕事用プロファイルのメリット
- デバイスの完全な暗号化
- デバイスに個人用プロファイルと仕事用プロファイルが存在する場合、両方のプロファイルに対して 1 つの Android Application Package（APK）
- Device Policy Controller（DPC）は仕事用プロファイルに限定されています。
- DevicePolicyManager クラスによるデバイス管理
仕事用プロファイルに関する考慮事項
- Android システムでは、インテントがプロファイルをまたがることが防止されており、IT 管理者はシステムアプリを有効または無効にできます。
- 一方のプロファイルで有効なファイルパス（Uniform Resource Identifier [URI]）が別のプロファイルでは有効でない場合があります。
プロファイル間でインテントの失敗を防ぐ
複数のプロファイルをまたいだ可能性があるインテントや、ブロックされるインテントを把握するのは困難です。確実に確かめる唯一の方法はテストです。アプリがアクティビティを開始する前に、Intent.resolveActivity() を呼び出して、リクエストが解決されることを確認する必要があります。
nullが返された場合、リクエストは解決されません。- なんらかの結果が返された場合は、インテントが解決されたことと、インテントを送信しても安全であることを示します。
注: 詳細なテスト手順については、インテントの失敗を防ぐをご覧ください。
プロファイル間でファイルを共有する
一部のデベロッパーは、Android でファイルパスをマークするために URI を使用します。ただし、仕事用プロファイルが存在する場合は別々のファイル システムが存在するため、次のようにすることをおすすめします。
|
使用: コンテンツ URI |
|
|
使用しない: ファイル URI |
|
次のステップ: アプリが管理対象プロファイルをサポートしたら、仕事用プロファイルでテストします。アプリをテストするをご覧ください。
管理対象設定を実装する
管理対象設定は、IT 管理者がユーザーのモバイル デバイスを特定の方法で管理するために使用できる一連の手順です。この手順はすべての EMM に共通する手順であるため、管理者はユーザーのスマートフォン上でアプリをリモートで構成できます。
ビジネスや行政機関向けのアプリを開発する場合は、業界に固有の一連の要件を満たすことが必要になる場合があります。IT 管理者は、管理対象設定を使用することで、リモートでユーザーの Android アプリの設定を指定し、ポリシーを適用できます。次に例を示します。
- アプリがモバイル通信/3G を介してデータを同期できるか、Wi-Fi のみを介してデータを同期できるかを設定する
- ウェブブラウザで URL を許可またはブロックする
- アプリのメール設定を構成する
- 印刷を有効または無効にする
- ブックマークの管理
管理対象設定の実装に関するベスト プラクティス
管理対象構成の設定ガイドは、管理対象構成の構築方法とデプロイ方法に関する重要な情報源です。このドキュメントを確認したら、追加のガイダンスについて以下の推奨事項をご覧ください。
アプリの初回起動時
アプリを起動するとすぐに、onStart() または onResume() で、このアプリに対して管理対象設定がすでに設定されているかどうかを確認できます。また、アプリケーションがマネージドであるか、管理対象外であるかも確認できます。たとえば、getApplicationRestrictions() が次のとおり返された場合、次のようになります。
- アプリケーション固有の一連の制限 - 管理対象構成をサイレント モードで（ユーザー入力なしで）構成できます。
- 空のバンドル - アプリは管理対象外のように動作します（個人用プロファイルでのアプリの動作など）。
KEY_RESTRICTIONS_PENDINGが true に設定された単��の Key-Value ペアを含むバンドル - アプリケーションは管理されていますが、DPC が正しく構成されていません。このユーザーはアプリからブロックし、IT 管理者に依頼してください。
管理対象構成の変更をリッスンする
IT 管理者は、管理対象構成とユーザーに適用するポリシーをいつでも変更できます。そのため、次のように管理対象構成に対する新しい制限をアプリで受け入れられるようにすることをおすすめします。
- リリース時の制限を取得する - アプリは
onStart()とonResume()でgetApplicationRestrictions()を呼び出し、古い制限と比較し、変更が必要かどうかを確認する必要があります。 - ランニング中に音声を聞く - 新しい制限を確認した後、実行中のアクティビティまたはサービスに
ACTION_APPLICATION_RESTRICTIONS_CHANGEDを動的に登録します。このインテントは動的に登録されたリスナーにのみ送信され、アプリ マニフェストで宣言されたリスナーには送信されません。 - 実行されていない間は登録を解除する -
onPause()で、ACTION_APPLICATION_RESTRICTIONS_CHANGEDのブロードキャストの登録を解除する必要があります。
専用デバイス
専用デバイスとは、デジタル サイネージ ディスプレイ、チケット印刷キオスク、レジなど、単一の目的のために使用されるキオスク デバイスです。
Android デバイスが専用デバイスとして構成されている場合、ユーザーにはアプリが画面に固定され、アプリから移動するためのホームボタンや最近使ったアプリボタンは表示されません。専用デバイスでは、一連のアプリ（ライブラリ カタログ用のアプリとウェブブラウザを備えたライブラリ キオスクなど）を表示するように設定することもできます。
手順については、専用デバイスをご覧ください。
Chrome カスタムタブによるシングル サインオンの設定
企業ユーザーは、デバイスに複数のアプリを持っていることが多く、一度ログインすればすべての仕事用アプリにアクセスしたいと考えています。通常、ユーザーは WebView を使用してログインします。ただし、次のような理由があります。
- ユーザーが同じ認証情報で複数回ログインしなければならないことがよくあります。多くの場合、WebView ソリューションは真のシングル サインオン（SSO）エクスペリエンスではありません。
- 悪意のあるアプリが Cookie を検査したり、JavaScript® を注入してユーザーの認証情報にアクセスしたりするなど、セキュリティ上のリスクが生じる可能性がある。信頼できるデベロッパーであっても、悪���な可能性のあるサードパーティの SDK に依存している場合は危険です。
どちらの問題も、WebView ではなくブラウザのカスタムタブを使用してユーザーを認証することで解決できます。これにより、認証が次のことが可能になります。
- ホストアプリがコンテンツを検査できない安全なコンテキスト（システム ブラウザ）で発生します。
- Cookie の状態が共有されるため、ユーザーは一度ログインするだけで済みます。
要件
カスタムタブは API レベル 15（Android 4.0.3）まで遡ってサポートされます。カスタムタブを使用するには、Chrome などのサポートされているブラウザが必要です。 Chrome 45 以降では、この機能が Chrome カスタムタブとして実装されています。
カスタムタブに SSO を実装するにはどうすればいいですか？
Google は、カスタムタブを使用する OAuth クライアント ライブラリをオープンソース化し、OpenID Foundation の OpenID Connect ワーキング グループに貢献しています。AppAuth ライブラリを使用して SSO 用のカスタムタブを設定するには、GitHub のドキュメントとサンプルコードをご覧ください。
アプリをテストする
アプリを開発したら、仕事用プロファイルと完全管理対象デバイスの両方でテストする必要があります。下記の手順をご覧ください。
Test DPC を使用して Android アプリをテストする
Android デベロッパーがエンタープライズ環境でアプリをテストできるように、Test DPC アプリが用意されています。Test DPC を使用すると、組織が EMM を使用してデバイスを管理しているかのように、EMM ポリシーや管理対象の構成値をデバイスに設定できます。Test DPC をデバイスにインストールするには、次のいずれかの方法を選択します。
- Google Play から Test DPC をインストールします。
- GitHub のソースからビルドします。
Test DPC の設定方法の詳細については、以下の手順と Test DPC ユーザーガイドをご覧ください。
仕事用プロファイルをプロビジョニングする
仕事用プロファイルでアプリをテストするには、まず Test DPC アプリを使用して、次のようにデバイスに仕事用プロファイルをプロビジョニングする必要があります。
- デバイスに Test DPC をインストールします。
- Android ランチャーで、[Set up Test DPC] アプリアイコンをタップします。
- 画面の手順に沿って操作します。
- アプリをデバイスにインストールし、仕事用プロファイルでの動作をテストします。
Android によって仕事用プロファイルが作成され、Test DPC の��ピーが仕事用プロファイルにインストールされます。この Test DPC の仕事用バッジ インスタンスを使用して、仕事用プロファイルのポリシーおよび管理対象構成を設定します。開発用の仕事用プロファイルの設定について詳しくは、デベロッパー ガイドの仕事用プロファイルをご覧ください。
完全管理対象デバイスをプロビジョニングする
完全管理対象デバイスが使用されるのは、デバイスにすべての管理ポリシーを適用できるからです。完全管理対象デバイスをプロビジョニングする手順は次のとおりです。
- デバイスに Test DPC をインストールします。
- デバイスに他のユーザーまたは仕事用プロファイルがないことを確認します。
- デバイスにアカウントがないことを確認します。
- ターミナルで Android Debug Bridge（adb）コマンドを実行します。
adb shell dpm set-device-owner com.afwsamples.testdpc/.DeviceAdminReceiver
- デバイス所有者のプロビジョニングが完了したら、そのデバイスでアプリをテストできます。特に、対象デバイスで管理対象構成とインテントがどのように機能するかをテストする必要があります。
他のプロビジョニング方法を使用することもできます。Test DPC ユーザーガイドをご覧ください。IT 管理者の一般的な Android 搭載デバイスの登録とプロビジョニングの方法については、デバイスのプロビジョニングをご覧ください。
エンドツーエンド テスト
上記の環境でアプリのテストを完了したら、エンドツーエンドの本番環境でアプリをテストすることをおすすめします。このプロセスには、お客様が組織にアプリをデプロイするために必要な手順が含まれます。これには、次のようなものがあります。
- Google Play を通じたアプリ配信
- サーバーサイド マネージド設定
- サーバーサイドのプロファイル ポリシー制御
エンドツーエンド テストを完了するには、EMM コンソールにアクセスする必要があります。これを取得するには、EMM にテスト コンソールをリクエストするのが最も簡単な方法です。アクセス権を取得したら、次の操作を行います。
- 新しい ApplicationId を使用して、アプリケーションのテスト バージョンを作成します。
- 管理対象の Google ドメインを申請して EMM にバインドします。EMM にバインド済みのテストドメインがすでにある場合、任意の EMM でテストするにはバインドを解除する必要があります。���体的なバインド解除手順については、EMM にお問い合わせください。
- 管理対象の Google ドメインのプライベート チャネルにアプリケーションを公開します。
- EMM コンソールと EMM アプリを使用して、次のことを行います。
- 仕事用デバイスをセットアップします。
- アプリを配布します。
- 管理対象の設定を行います。
- デバイス ポリシーを設定する。
このプロセスは EMM によって異なります。詳しくは、EMM のドキュメントを���覧ください。これでこれらの手順を完了し、アプリが企業ユーザーに対して適切に機能することを確認しました。