音频焦点
在启动逻辑声音流之前，应用应使用将用于其逻辑声音流的同一个音频属性来请求获得音频焦点。虽然我们建议发送此类焦点请求，但系统不会强制要求发送。有些应用可能会明确跳过发送请求的步骤，以实现特定行为（例如，在通话期间故意播放声音）。
为此，您应将焦点视为间接控制播放和消除播放冲突的一种方式，而不是作为主要的音频控制机制；也就是说，车辆不应依赖于焦点系统来操作音频子系统。
焦点交互
为了支持 AAOS 的需求，系统会根据请求的 CarAudioContext 和当前焦点持有者的 CarAudioContext 之间的预定义交互来处理音频焦点请求。交互类型分以下三种：独占、拒绝和并发。
独占交互
在独占交互中，一次只允许一个应用持有焦点。因此，在传入的焦点请求被授予焦点的同时，现有的焦点持有者会失去焦点。例如，用户在现有应用中播放音乐时启动新的音乐应用。由于这两个应用都在播放媒体内容，因此一次只允许其中一个应用持有焦点。结果就是，新启动的应用发出的焦点请求将会返回 AUDIOFOCUS_REQUEST_GRANTED；而当前在播放的应用将收到焦点更改事件，该事件中的丢失状态与所发请求的类型相对应。这是 Android 中最常见的交互模型。
拒绝交互
在拒绝交互中，传入的请求一律会遭到拒绝。尝试在通话过程中播放音乐就是拒绝交互的一个示例。在这个例子中，如果拨号器正为某个通话持有音频焦点，而另一个应用要请求焦点来播放音乐，则音乐应用发出的请求会收到 AUDIOFOCUS_REQUEST_FAILED 响应。由于焦点请求遭拒，因此系统不会向当前焦点持有者分派任