DIALの使用
DIAL(Discovery-and-Launch)プロトコル(英語のみ)は、別のデバイスからセカンドスクリーンアプリを使用してFire TV対応アプリを検出し起動できるようにするオープンプロトコルです。これを使用するには、Fire TVとセカンドスクリーンデバイスが同じネットワークに存在する必要があります。
DIALは、ビットストリーミングや画面ミラーリングの機能を提供するAPIではないことに注意してください。セカンドスクリーンデバイスのアプリがFire TVで(オプションのペイロードを使用して)アプリを見つけて起動できるようにするものです。通常は、セカンドスクリーンアプリ(起動メッセージの送信側)と、対応するファーストスクリーンアプリであるFire TV対応アプリ(メッセージの受信側)の両方を作成して管理・実装します。
オープンDIALプロトコルの詳細と、アプリをDIALサービスに登録する方法の詳細については、DIALのウェブサイト(英語のみ)を参照してください。
DIALの有効化
マニフェストの更新
Vega上で、アプリケーションまたはパッケージがDIALをサポートしていることをDIALが検出できるようにするには、manifest.tomlファイルに以下を追加する必要があります。
[[extras]]
key = "dial_id"
value = "<DIAL ID>"
[[extras]]
key = "dial_launch_component"
value = "<pkg URLを使用して起動するコンポーネント名>"
dial_idは、https://www.dial-multiscreen.org/dial-registries/about-the-registryにあるDIALレジストリで選択して登録したアプリ名です。- これは、Fire OSベースの実装で使用されたwhisperplay.xmlファイル内の「dialid」と同じです。
dial_launch_componentは、DIALが起動するパッケージ内の対話型コンポーネントです。DIALから起動URIが送信されるとき、その形式は次のようになります:*pkg://<dial_launch_component>?<DIAL POSTリクエストのペイロード>&DIAL_ADDITIONAL_DATA_URL=http://127.0.0.1:8009/apps/<Dial ID>/dial_data
(任意)<authorizedOrigins>によるCORSのサポート
CORS認証とクライアントオリジンに関する追加要件の詳細については、DIAL spec v2.2.1, section 6.6(英語のみ)を参照してください。Amazonの実装では、ファーストスクリーンアプリのwhisperplay.xmlファイル内で、許可されるCORSオリジンのコレクションを指定する必要があります(上記の例を参照)。この形式では、0文字以上の文字列に一致する「*」文字を使用したワイルドカード一致が許可されています。特定の安全でないURIスキーム(file:、http:、ftp:など)は、許可リストへの登録の有無を問わず、明示的に禁止されています。
許可されるオリジンを指定する場合は、過度に許容しないよう注意してください。たとえば、https://test.amazon.comとhttps://amazon.comの両方を許可する場合、許可されるオリジンを*amazon.comとして指定することは避けてください。これは過度な許容であり、予期しないオリジン(https://evilamazon.comなど)が誤って許可されてしまう恐れがあります。このような場合は、代わりにコレクションを以下のように定義することで、所有するドメインに基づくオリジンだけが確実に許可されるようにすることができます。
CORSをサポートするには、manifest.tomlに以下を追加します。
[[extras]]
key = "dial_origins"
value = "<URL/パッケージ1>,<URL/パッケージ2>"
<authorizedOrigins>)とセカンドスクリーン(ORIGINヘッダー)の両方を追加することを強くお勧めします。起動とadditionalDataUrlの処理
アプリがDIALペイロード(DIAL起動リクエストを介してアプリに渡される情報)を受信するように設定されている場合、このペイロードは、起動URIのパラメーターとして配信されます。オプションで追加情報をPOSTするためにファーストスクリーンアプリによって使用されるadditionalDataUrlは、起動URIの別のパラメーターとして配信されます。その形式は次のようになります: pkg://<dial_launch_component>?<DIAL POSTリクエストのペイロード>&DIAL_ADDITIONAL_DATA_URL=http://127.0.0.1:8009/apps/<Dial ID>/dial_data。
additionalDataUrlの想定される形式はhttp://127.0.0.1:8009/apps/<DIAL ID>/dial_dataで、このURLにファーストスクリーンアプリからデータがPOSTされます。
(任意)追加データのPOST
ごく基本的な双方向通信や、ファーストスクリーンアプリからセカンドスクリーンアプリへのシンプルなフィードバックメカニズムを有効にする場合は、DIALのadditionalDataUrlフィールドを使用できます。この一般的なユースケースとしては、セッショントークンなどの情報をファーストスクリーンアプリの状態に関連付けて共有するケースが挙げられます。これは、ファーストスクリーンアプリからセカンドスクリーンアプリに提供され、Fire TVが再起動されるまで保持されるXMLドキュメントと考えることができます。Fire TV対応アプリからadditionalDataUrlへのPOSTが正常に実行されるようにするには、対応するオリジンがmanifest.toml内のdial_originsエクストラに登録されている必要があります。
ファーストスクリーンアプリとセカンドスクリーンアプリの両方の追加データメカニズムで想定および提供される具体的な形式については、DIAL docs v2.2.1, section 6.3(英語のみ)を参照してください。
セカンドスクリーンアプリの変更
セカンドスクリーンアプリには、以下に示す変更を加える必要があります。
手順A: DIAL対応デバイス検出サービスを実装する
セカンドスクリーンアプリ(DIALクライアント)に、DIALプロトコルのクライアント仕様を実装します。DIALの検出は、UPnP/SSDPの仕様に基づいて構築されています。バックグラウンドアクティビティまたはスレッドで、検索ターゲットを「urn:dial-multiscreen-org:service:dial:1」と指定して、UDP M-SEARCHリクエストを送信します。
M-SEARCHリクエストに対し、Fire TVから、一意のサービス名(USN)、デバイス情報を取得する場所/URL、検索ターゲットを含むレスポンスが返されます。さらにこのレスポンスには、追加のWAKEUPヘッダーが含まれる場合もあります。これは、マジックパケットを使用してサスペンドモードからウェイクアップできる機能がTVに現在備わっていることを示すものです。詳細については、DIAL 2.2.1 spec, section 7(英語のみ)を参照してください。デバイスから複数のM-SEARCHレスポンスを受信することもあるため、USNに基づいて一意のデバイスを抽出する必要があります。
以下は、リクエストとレスポンスの例です。
M-SEARCHリクエストの例:
M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 10
ST: urn:dial-multiscreen-org:service:dial:1
USER-AGENT: OS/version product/version
M-SEARCHレスポンスの例:
HTTP/1.1 200 OK
USN: uuid:7b077d4c-a222-5b72-0000-0000182185c7::urn:dial-multiscreen-org:service:dial:1
CACHE-CONTROL: max-age=1800
EXT:
ST: urn:dial-multiscreen-org:service:dial:1
LOCATION: http://192.168.1.141:60000/upnp/dev/7b077d4c-a222-5b72-0000-0000182185c7/desc
SERVER: Linux/4.4.120 UPnP/1.0 Cling/2.0
次に、デバイスの詳細情報を取得するために、M-SEARCHレスポンスに記載されているデバイス情報のURLを使用してHTTPリクエストを送信します。レスポンスのヘッダーには、Application-URLという重要な属性が含まれます。これは、DIAL RESTサービスと呼ばれます。このApplication-URLは、後でデバイス上のアプリとのやり取りに使用されます。レスポンス本文から、デバイスの通称、モデル名、製造元を抽出して格納し、これらの値をユーザーに表示すると便利です。
M-SEARCHリクエストとデバイス情報リクエストの処理が完了したら、検出されたデバイスのリストをUIに表示できます。
手順B: アプリのステータスを取得する
デバイスでアプリを起動する前に、デバイスでのアプリの状態を知っておく(さらに必要に応じてadditionalDataを読み取り、キャッシュされた情報をファーストスクリーンアプリから読み込んでおく)と便利です。アプリの状態を取得するには、アプリを起動するデバイスをユーザーが選択したら、アプリ名をリソース名として指定して、HTTP GETリクエストをDIAL RESTサービスに送信します。リクエスト内のアプリ名は、DIALレジストリに登録(かつwhisperplay.xmlファイルで指定)されている名前と一致する必要があります。
アプリがインストールされていない場合や、アプリ名が認識されない場合は、HTTP 404エラーが返されます。ファーストスクリーンデバイスにAmazonアプリストアからアプリをインストールするオプションを、セカンドスクリーンデバイス上でユーザーに提示できますが、この機能はDIALプロトコルの範囲外です。
HTTPリクエストが成功すると、DIALサーバーはHTTP 200 OKレスポンスで応答します。レスポンス本文には、アプリの状態を伝える属性(hidden、stopped、running、installable)が含まれています(ただし、installableとhiddenは現在Fire TVのDIALサーバーではサポートされていません)。また、以前ファーストスクリーンアプリからadditionalDataUrlにPOSTされていたXML形式のadditionalDataも含まれています。
手順C: アプリを起動する
次に、アプリ名をリソース名として指定し、起動パラメーターとしてアプリに送信するオプションのペイロードをリクエスト本文に記述して、HTTP POSTリクエストをDIAL RESTサービスに送信すれば、ファーストスクリーンアプリを起動できます。一般的なユースケースとしては、アプリ内で再生するビデオコンテンツや音楽コンテンツへのリンクが挙げられます。
ファーストスクリーンアプリは、セカンドスクリーンアプリから送信されたペイロードに応答してアクションを処理します。ファーストスクリーンのFire TV対応アプリからPOSTされた追加データ(複数のクライアントを同期するための視聴セッショントークンなど)は、セカンドスクリーンアプリから発行される後続のGETリクエストを使用して読み取ることができます。
アプリの開発に関しては、ネットワーク接続リソースのクリーンアップと終了、例外の処理、非UIブロッキングスレッドでのスレッドの起動、ネットワーク操作失敗時の適切な処理に注意を払う必要があります。
Last updated: 2025年9月30日

