デジタルサイネージオープンADB：顧客所有のAndroidアプリの展開

デジタル サイネージ プロジェクトに顧客所有の Android アプリケーションが含まれる場合、Androidデジタルサイネージディスプレイもはや、画面サイズ、解像度、取り付け方法だけの問題ではありません。より重要な問題は、Android プラットフォームがインテグレーターに独自のソフトウェアを展開して実行するための十分な制御を提供するかどうかです。

このことは、ボスニアを拠点とするデジタル サイネージ販売会社から、コンパクトな Android ディスプレイの要件について当社に問い合わせがあったときに明らかになりました。対象となるアプリケーションには情報表示が含まれていましたが、お客様はすでに独自の Android アプリを持っており、工場出荷時にインストールされたランチャーによって制限されることを望まれませんでした。リクエストには、オープン ADB、顧客側の APK インストール、顧客のアプリをランチャーとして使用する機能、さまざまな設置方向に適したスタンドが含まれていました。

このタイプのプロジェクトでは、最初にソフトウェア導入要件を確認します。実際的な質問は単純です。顧客の APK は独立してインストールできますか?そのアプリはデバイスのランチャーになることができますか?再起動後もその設定は残りますか?また、インテグレータが Android 環境を管理する必要がある場合、どのレベルのシステム アクセスが利用可能でしょうか?

こうした疑問から、私たちはディスプレイを単なるコンテンツ再生デバイスとしてではなく、Android プラットフォームとして評価することにしました。

お客様は工場出荷時の Android 環境以上のものを必要としていました

従来のデジタル サイネージの導入は、ディスプレイに付属するソフトウェアに大きく依存する場合がありました。コンテンツは、CMS を通じて配信され、工場のアプリケーションを通じて起動され、メーカーが意図したワークフロー内で管理されます。

独自のアプリケーションを持つインテグレーターには、別の要件があります。ディスプレイはインテグレーターの既存のソフトウェア環境の一部となるため、自己インストールされた APK を展開する機能はハードウェア選択プロセスの一部になります。

この場合、要件は単にアプリケーションを 1 回インストールするだけではありませんでした。顧客は、独自のソフトウェアがユーザーに表示される通常のインターフェイスになることを望んでいました。

この違いにより、リクエストへのアプローチ方法が変わりました。 「Android」を十分な仕様として扱う代わりに、ADB アクセス、APK インストール、カスタム Launcher 動作、起動動作、および Root アクセスといういくつかの実用的な層にデプロイメントを分割しました。

当社が確認した Android サイネージ構成は、これらの要件をサポートしています。 ADB がサポートされており、顧客は ADB を通じて独自の APK をインストールでき、必要な Launcher プロパティを持つアプリで元の Launcher を置き換えることができ、構成された Launcher は再起動後もデフォルトのエントリ ポイントのままになります。ルートもデフォルトで開いています。adbシェルroot権限で動作します。

コンパクトなアプリケーション環境の場合、10.1 インチ RK3588 Android 13 ディスプレイ に、RK3588 Android 13 デジタル サイネージ ディスプレイの関連ハードウェア例を示します。 RK3588プロセッサとAndroid 13を採用しており、ソフトウェアの統合とカスタマイズが必要なアプリケーション向けのAndroidディスプレイとして位置付けられています。

製品自体はこの事件の主要なポイントではありません。重要なのは、インテグレータが固定の工場出荷時のインターフェイスを中心にアプリケーションを構築することを要求するのではなく、ハードウェアが顧客が制御するソフトウェア環境に対応できることです。

オープン ADB により顧客側の APK 導入が可能に

既存の Android アプリケーションのインテグレーターにとって、最初の実際的な問題は、メーカーのプリインストールされたアプリケーション環境に依存せずにソフトウェアを展開できるかどうかです。たとえば、情報表示の場合、展開は次から開始できます。21 インチ RK3399 Android タブレット/オールインワン タッチ スクリーン コンピューター顧客独自の APK を実行します。

Open ADB は、コンピュータから Android デバイスと通信するために使用されるアクセス チャネルを提供します。この展開シナリオで関連する機能は、顧客が ADB を使用して独自の APK をインストールできることです。

これは、サイドロードされた APK デプロイメントと呼ばれることもあります。アプリケーションは、ディスプレイ メーカーによってプリロードされたソフトウェアに限定されるのではなく、顧客によって提供されます。

ADB、APK インストール、ルートは引き続き別の機能として扱う必要があります。 ADB は通信メカニズムです。 APK のインストールはデプロイ操作です。ルートは、Android システム内で使用できる特権レベルを決定します。

ディスプレイは Android をサポートし、インテグレータが必要とするレベルのシステム アクセスを必ずしも提供しなくてもアプリケーションのインストールを可能にすることさえできるため、調達時にこの区別が重要になります。

Android サイネージ製品ラインで確認された構成では、顧客は ADB を使用して独自の APK をインストールできますが、ルート アクセスはデフォルトで利用可能です。これにより、インテグレータは独自のソフトウェアの明確な導入パスを得ることができ、必要に応じて Android 環境にさらに深くアクセスできるようになります。

Android サイネージの自己インストール APK 機能を探している購入者、または独自の APK をインストールする予定の購入者向け デジタルサイネージディスプレイ— これは、単に仕様書で Android のバージョンを探すよりも便利な区別です。

重要なステップは APK のインストール後に行われます

APK をインストールしても、そのアプリケーションが自動的にデバイスのメイン インターフェイスになるわけではありません。

これは顧客の要件の重要な部分でした。顧客はすでに独自のアプリケーションを持っており、ユーザーがそのアプリケーションにアクセスする前に工場出荷時のランチャーから入ることを望んでいませんでした。

適切な Launcher/Home プロパティを持つ Android アプリは、デバイスのデフォルトの Launcher として構成できます。デフォルトのランチャーになると、顧客のアプリケーションは Android システムへの通常のエントリ ポイントになります。

確認された構成はこのアプローチをサポートしています。顧客のアプリに必要な Launcher プロパティがある場合、元の Launcher を置き換えて、デバイスをカスタム ランチャー Android サイネージ ディスプレイ。デバイスが再起動された後、構成されたランチャーはデフォルトのままとなり、デバイスは顧客のアプリに再び入ることができます。

これにより、2 種類の Android サイネージ自己インストール APK プロジェクトの間に大きな違いが生じます。

あるモデルでは、顧客はメーカーのソフトウェアと一緒にアプリケーションをインストールするだけです。もう 1 つは、顧客のアプリケーションがデバイスの主要なインターフェイスになります。 2 番目のモデルは、ディスプレイが独自のアプリケーション環境の一部として動作することを意図している場合に、多くのインテグレータが必要とするものに近いものです。

この違いは、カスタム ランチャー デジタル サイネージ プロジェクトを評価する際に、「APK インストールのサポート」を完全な答えとして扱うべきではない理由でもあります。

ルートアクセスにより、インテグレーターはより深いシステムレベルのオプションを得ることができます

顧客の要件にはオープン システム アクセスも含まれており、ここで Root が関係します。

確認された構成では、デフォルトで Root アクセスが提供されます。より具体的には、adbシェル制限されたシェル ユーザーとしてではなく、ルートとして動作します。

これは、顧客の APK をインストールするためだけに Root が必要であるという意味ではありません。 APK のデプロイとルートはシステムの別個の部分です。

調達時にルートを明確にする理由は異なります。インテグレーターは、独自のソフトウェア環境を適応、構成、デバッグ、または管理するときに、より深いアクセスが必要になる場合があります。それらのタスクについては、NFC およびウォール マウントを備えた 12 インチ RK3288 産業用 Android タブレットは、カスタム統合のための SDK サポートを備えたコンパクトな壁掛け可能なプラットフォームを提供します。

このタイプのプロジェクトの場合、違いは次のように簡単に表現できます。

これは、オープン ADB キオスクのディスプレイ要件を単にルート要件として説明しない理由でもあります。プロジェクトには、すべてのシステム機能をユーザーに公開する必要がなくても、ADB とカスタム Launcher が必要な場合があります。

カスタム ランチャーとキオスクは関連していますが、同一ではありません

カスタム ランチャーは、ユーザー エクスペリエンスの 1 つの重要な部分を解決します。これにより、顧客のアプリが通常のホーム インターフェイスになることが可能になります。

より厳密なキオスク展開では、それ以上のものが必要になる場合があります。 Android デスクトップやシステム設定への通常のナビゲーションが制限されている間、アプリケーションが唯一の実用的なユーザー向け環境であり続ける必要がある場合があります。これは、当社のようなセルフサービス展開に関連するパターンです。POSレジシリーズ。

これらの要件は個別に定義する必要があります。

このケースで説明する確認済みの構成では、顧客のアプリに必要な Launcher プロパティがある場合、そのアプリはデフォルトの Launcher になることができ、デバイスは再起動後にそのアプリに戻ることができます。これにより、アプリケーションの位置がデバイスのプライマリ インターフェイスとして確立されます。

プロジェクトで厳密なアプリケーション ロック、制限されたシステム ナビゲーション、または特定のデバイス管理の実装がさらに必要な場合は、カスタム ランチャーがサポートされているという理由だけでそれらの要件が含まれると想定するのではなく、顧客のアプリケーションと展開方法に従って評価する必要があります。

この違いは、独自のキオスク ソフトウェア環境を構築するインテグレーターに特に関係します。正しい質問は、単にディスプレイがカスタム アプリ用の Android キオスク ディスプレイとして宣伝されているかどうかではなく、Android ユーザー エクスペリエンスのどの部分を顧客のアプリケーションが実際に制御する必要があるかということです。次のようなセルフサービス展開11.6 インチ Android POS キオスクは、Android ベースでプライマリ インターフェイスとして実行されている顧客アプリケーションを示しています。

物理ディスプレイは依然としてアプリケーションに適合する必要がある

ソフトウェア構成は元のリクエストの一部にすぎませんでした。お客様は、コンパクトなディスプレイとさまざまな向きに対応できるスタンドも必要としていました。

この要件は Launcher 構成の外にあります。アプリは縦向きまたは横向きのプレゼンテーション用に設計できますが、ディスプレイの配置方法は物理的な構造によって決まります。

コンパクトなアプリケーション環境の場合、10.1 インチ RK3588 Android 13 ディスプレイ関連するハードウェアの例を示します。 RK3588プロセッサとAndroid 13を採用しており、ソフトウェアの統合とカスタマイズが必要なアプリケーション向けのAndroidディスプレイとして位置付けられています。

製品自体はこの事件の主要なポイントではありません。重要なのは、インテグレータが固定の工場出荷時のインターフェイスを中心にアプリケーションを構築することを要求するのではなく、ハードウェアが顧客が制御するソフトウェア環境に対応できることです。

コンパクトにするにはAndroidデジタルサイネージディスプレイ、10.1 インチ構成は元の要件に近くなります。のRK3288を搭載した15.6インチFHD IPS AndroidタブレットそしてFHD IPS スクリーンと RK3288 を備えた 13.3 インチオールインワン Android タブレットサイネージおよびキオスク アプリケーションのコンパクト フォーマットとラージ フォーマットの間に適合します。より大きなインタラクティブな表面と移動可能な設置が必要なアプリケーションの場合、21.5 インチ RK3588 スタンバイミー Android ディスプレイ同じ一般的な Android プラットフォーム アプローチを使用しながら、異なる物理フォーマットを提供します。

これら 2 つの考慮事項を分離する理由は実際的なものです。ソフトウェアの柔軟性によって機械的な設置が自動的に決まるわけではありません。横向きと縦向きの配置が必要なプロジェクトでも、適切な物理構造、回転機構、またはスタンド構成が必要です。

このため、当社では、Android広告表示範囲アプリケーション環境に応じて評価できるさまざまな商用ディスプレイ形式が含まれています。これには、24 インチ RJ45 PoE オールインワン Android タブレット350cd/m²の明るさ。

要件をデプロイ可能な構成に変換するのにどのように貢献したか

このタイプのプロジェクトの有用な部分は、ディスプレイが Android を実行していることを単に確認することではありません。課題は、顧客の既存のソフトウェアを、それが動作するハードウェア環境に接続することです。

ボスニアを拠点とするディストリビューターにとって、この要件は一連の実践的な質問に変換できます。APK はどのようにデバイスに届くのか、アプリケーションはランチャーになれるか、再起動後に何が起こるか、インテグレーターはどのレベルの Android アクセスを持っているかなどです。

これらの質問が分離されると、ハードウェア要件がより明確になります。

確認された機能は次のように要約できます。

これは、インテグレーターにとって不確実性を軽減できるプロセスの一部です。最初にディスプレイを選択し、後でソフトウェアの制限を発見するのではなく、ソフトウェア要件を使用して、展開に進む前に、オープン ADB とルート アクセス プロジェクトを備えた Android デジタル サイネージ ディスプレイにプラットフォームが適しているかどうかを判断できます。同じアプローチは、顧客のアプリケーションがすでに存在し、そのソフトウェアを市販の Android ディスプレイに展開することが主な要件であるデジタル サイネージのオープン ADB プロジェクトにも使用できます。

独自の Android サイネージ プロジェクトの実用的な出発点

顧客所有の APK は、Android ディスプレイの評価方法を変えます。画面サイズとディスプレイ仕様は依然として重要ですが、それらは展開決定の一部にすぎません。

インテグレーターにとって、より有用な評価はアプリケーションから始まります。つまり、APK を個別にインストールする必要があるかどうか、アプリをランチャーにする必要があるかどうか、再起動後に自動的に表示する必要があるかどうか、より詳細なシステム アクセスが必要かどうかです。

それが、ボスニアを拠点とする要請に対する私たちのアプローチの基礎でした。オープン ADB、APK のインストール、Launcher の動作、および Root を無関係な仕様として扱うのではなく、同じソフトウェア展開要件の一部として評価しました。

プロジェクトにすでに独自の Android APK がある場合、次のステップは、予想されるアプリケーションの動作を定義し、それを適切な動作と一致させることです。Androidデジタルサイネージディスプレイ構成。その後、サンプル デバイスを使用して、APK、ランチャーの動作、再起動の動作、および必要なシステム アクセスを検証してから、より広範な展開に進むことができます。同じ展開パターンが、会議室の予約パネルからレストランの注文画面に至るまで、Android ディスプレイ アプリケーション全体に適用されます。会議室予約タブレットそしてレストラン注文タブレット同様の Android ディスプレイの展開を評価している場合は、私たちのチームに連絡してくださいAPK 要件とデバイス構成について話し合います。