Chromecast 内置：如何从硬件用户界面的角度与 3rd 方接收器应用程序交互？

Posted 2023-03-07

【中文标题】Chromecast 内置：如何从硬件用户界面的角度与 3rd 方接收器应用程序交互？

【英文标题】：Chromecast built-in: how to interact with 3rd party receiver applications from hardware user interface perspective?

【发布时间】：2017-02-01 12:05:22

【问题描述】：

根据official documentation，具有支持内置 Chromecast 的物理用户界面（按钮、旋钮）的音频硬件设备（又名 Cast Audio Device）应与接收器应用交互以控制播放

用于音频设备的 Google Cast 可能有自己的播放控件（例如按钮、遥控器）。它们使用为 urn:x-cast:com.google.cast.media 命名空间定义的媒体播放消息（如媒体播放消息中所述）来控制接收器应用程序的播放。您的接收器应用程序必须支持这些媒体播放消息才能支持设备的播放控件。

但是没有更多的细节。特别是我想知道音频设备上的应用程序层（想想 SoC 控制器逻辑）将如何与 3rd 方接收器应用程序交互。我假设控制器逻辑和接收器 API 之间必须是基于 TPC/IP 的 http 通信。

想象以下用例：

用户使用他的智能手机并启动流媒体服务 A 的支持投射的媒体播放器应用程序。 他开始播放流媒体服务 A 的播放列表并点击 Cast 按钮在他的 Chromecast 内置音频设备上播放。 音频设备使用 A 的接收器应用程序接管播放并播放曲目。 稍后，当设备播放 A 播放列表时，用户走到设备并按下音频设备上的物理“下一个”按钮以跳到播放列表中的下一个曲目

现在硬件设备上的应用层可以通过什么方式来控制A接收器应用呢？根据文档，它应该使用媒体播放消息，但设备又应该如何知道控制接收器所需的 mediaSessionId？

【参考方案1】：

由于Cast设备上一次最多运行一个会话，理论上来说，硬件不需要知道sessionId。当硬件设备成为 Cast 设备时，内部的各个层之间存在紧密集成，并且接收器应用程序不需要参与。底线是，只要接收器应用程序使用标准 SDK（因此，使用标准的 urn:x-cast:com.google.cast.media 命名空间），正确的消息将流向接收者，SDK 将做正确的事情；这就是接收器应用程序的开发人员需要关心的全部内容；除此以外的任何内容都属于 Cast 设备的内部。

【讨论】：

谢谢，这就是我的假设——从接收者的角度来看，消息的来源是什么并不重要。我的问题更多是关于硬件方面的集成，还是这也是 Chromecast 内置 SDK 抽象出来的？