Android™ プレーヤーの実装 implementing-android-player

この節では、Android™ プレーヤーの設定について説明します。開発およびテストで使用する設定に関して、使用可能および推奨される設定ファイルおよびオプションの情報を提供します。

さらに、プレーヤーをクラッシュから回復させる解決策として、ウォッチドッグ ​があります。アプリケーションは、ウォッチドッグサービスに登録し、アプリケーション自体がアライブであることを知らせるメッセージを定期的に送信する必要があります。ウォッチドッグサービスが所定の時間内にキープアライブメッセージを受信しない場合、サービスはデバイスの再起動を試みます。（十分な権限を持っている場合は）デバイスを再起動してクリーンリカバリを行うか、アプリケーションを再起動します。

Android™ プレーヤーのインストール installing-android-player

AEM Screens 用の Android™ プレーヤーを実装するには、同プレーヤーをインストールしてください。

AEM 6.5 Player のダウンロード ページにアクセスします。

AEM Screens 6.5.5 サービスパック環境の設定 fp-environment-setup

AEM オーサーインスタンスおよびパブリッシュインスタンスの Adobe Experience Manager Web コンソール設定 ​で、login-token cookies の SameSite 属性 ​を Lax から None に設定します。

次の手順に従います。

アドホック方式 ad-hoc-method

アドホック方式を使用すると、最新の Android™ プレーヤー（.exe）をインストールできます。AEM 6.5 Player のダウンロード ページにアクセスします。

アプリケーションをダウンロードしたら、プレーヤー上で以下の手順に従ってアドホックインストールを完了します。

Android™ ウォッチドッグを実装する implementing-android-watchdog

Android™ のアーキテクチャ上、デバイスをリブートするには、アプリケーションがシステム権限を持っている必要があります。製造元の署名キーを使用して apk に署名します。この署名を行わないと、ウォッチドッグはプレーヤーアプリケーションを再起動できても、デバイスは再起動できません。

製造元のキーを使用した Android™ apks への署名 signage-of-android-apks-using-manufacturer-keys

PowerManager や HDMIControlServices など、Android™ の特権付き API にアクセスするには、製造元のキーを使用して Android™ apk に署名します。

次の手順に従って、製造元のキーを使用して Android™ apk に署名します。

Android™ ウォッチドッグサービスについて android-watchdog-services

クロスAndroid™ ウォッチドッグサービスは、AlarmManager を使用して Cordova プラグインとして実装されます。

次の図に、ウォッチドッグサービスの実装を示します。

1.初期化 – Cordova プラグインの初期化時、システム権限を持っているかどうか、さらに、リブート権限を持っているかどうかの確認が行われます。これらの 2 つの条件を満たしている場合は、リブートのペンディングインテントが作成され、条件を満たしていない場合は、（Launch Activity に基づいて）アプリケーションを再起動するためのペンディングインテントが作成されます。

2.キープアライブタイマー – 15 秒おきにイベントをトリガーするためにキープアライブタイマーが使用されます。このイベントの間に、（アプリケーションをリブートまたは再起動する）既存のペンディングインテントをキャンセルし、次の 60 秒の間に新しいペンディングインテントを登録（基本的にリブートを延期）します。

3.アプリケーションのクラッシュ – クラッシュが発生した場合、AlarmManager に登録されたリブートの pendingIntent はリセットされなくなりました。そのため、アプリケーションのリブートまたは再起動が実行されます（Cordova プラグインの初期化時に使用できる権限によって異なります）。

Android™ プレーヤーの一括プロビジョニング bulk-provision-android-player

Android™ プレーヤーを一括で展開する場合、管理者 UI で手動で入力せずに、AEM インスタンスを指すようにプレーヤーをプロビジョニングし、他のプロパティを設定する必要があります。

次の手順に従って、Android™ プレーヤーで一括プロビジョニングを許可します。

ポリシー属性 policy-attributes

次の表に、参照用のポリシー JSON の例と共にポリシー属性を示します。

JSON ポリシーの例 example-json

{
  "server": "https://author-screensdemo.adobecqms.net",
"device": "",
"user": "",
"password": "",
"resolution": "auto",
"rebootSchedule": "at 4:00 am",
"maxNumberOfLogFilesToKeep": 10,
"logLevel": 3,
"enableAdminUI": true,
"enableOSD": true,
"enableActivityUI": false,
"enableNativeVideo": false,
"enableAutoScreenshot": false,
"cloudMode": false,
"cloudUrl": "https://screens.adobeioruntime.net",
"cloudToken": "",
"enableDeveloperMode": true
}

エンタープライズモビリティ管理を使用した Android™ プレーヤーの一括プロビジョニング bulk-provisioning

Android™ プレーヤーを一括デプロイする場合、すべてのプレーヤーを手動で AEM に登録するのは非常に手間がかかります。デプロイメントのプロビジョニングと管理をリモートで行うには、VMWare Airwatch、MobileIron、Samsung Knox などの EMM（エンタープライズモビリティ管理）ソリューションを使用します。AEM Screens Android™ プレーヤーでは、業界標準の EMM AppConfig をサポートしているので、リモートプロビジョニングが可能です。

Android™ プレーヤーの命名 name-android

ユーザーにわかりやすいデバイス名を Android™ プレーヤーに割り当てて、そのデバイス名を AEM（Adobe Experience Manager）に送信することができます。この機能により、Android™ プレーヤーに名前を付けるだけでなく、適切なコンテンツを簡単に割り当てることもできます。

Android™ プレーヤーに名前を設定するには、次の手順に従います。

エンタープライズモビリティ管理を使用した Android™ プレーヤーの一括プロビジョニングの実装 implementation

Android™ プレーヤーの一括プロビジョニングを可能にするには、次の手順に従います。

また、AppConfig のサポートについては、EMM ベンダーに確認してください。VMWare Airwatch、Mobile Iron、SOTI、BlackBerry® UEM、IBM® Maas360、および Samsung Knox など、最も人気のあるデバイスが、この業界標準をサポートしています。

Screens リモート制御の使用 using-remote-control

AEM Screens には、リモート制御機能が用意されています。この機能について詳しくは、Screens リモート制御を参照してください