低功耗蓝牙音频

低功耗蓝牙音频 (LEA) 可确保用户在不牺牲电池续航时间的情况下接收高保真音频，并允许他们在不同用例之间无缝切换。Android 13 (API level 33) 内置了对 LEA 的支持。

在 LEA 源设备市场份额增长之前，大多数 LEA 耳机将是双模的。用户应该能够在他们的双模耳机上配对和设置两种传输方式。

用例

您可能希望针对以下用例集成 LEA

共享音频：用户可以同时将多个音频流共享到一个或多个音频接收设备。音频在源设备和连接设备之间同步。
广播音频：用户可以向朋友和家人广播音频，同时也可以连接到公共广播以获取信息、娱乐或无障碍功能。
LC3 音频编解码器支持：这是默认音频编解码器，取代了 A2DP（媒体）中使用的 SBC 编解码器和 HFP（语音）中使用的 mSBC。LC3 效率更高、可重新配置且质量更高。
音频采样改进：耳机在使用麦克风时可以保持高输出音频质量。蓝牙经典在使用蓝牙麦克风时会降低音频质量。通过 BLE 音频，输入和输出采样可以达到 32 kHz。
立体声麦克风：助听设备可以使用立体声麦克风录制音频，以增强空间音频。
助听器配置文件 (HAP) 支持：HAP 比以前的 ASHA 协议提供更好的用户无障碍性和使用性。用户可以将助听器用于电话通话和 VoIP 应用。
增强型属性协议 (EATT) 支持：EATT 允许开发者一次向配对的助听设备发送多个命令。

关键场景

主要有四类用例

对话：拨号器和 VoIP 应用需要低延迟通信路由，提供高质量音频和更少的电池使用量。
游戏：并发的麦克风和高保真播放允许游戏将高质量音频流式传输到助听设备。当游戏准备好使用蓝牙麦克风时，游戏应用可以访问 BLE 音频输入。然后，当玩家开始与同伴玩家进行实时对话时，游戏应用可以无延迟地使用麦克风数据。
媒体：媒体应用被允许设置音频管理器的首选设备。用户可以通过更改系统设置中的首选设备来覆盖此设置。
无障碍功能：支持 BLE 音频的助听器现在可以使用麦克风，允许用户在通话中持续使用助听器。

BLE 音频 API 和方法

支持 BLE 音频助听设备需要以下 API 和方法

AudioManager

setCommunicationDevice() 选择应该用于通信用例（例如语音或视频通话）的音频设备。此方法可用于语音或视频聊天应用，以选择平台默认选择的设备之外的其他音频设备。此 API 取代了以下已弃用的 API：startBluetoothSco()、stopBluetoothSco() 和 setSpeakerphoneOn()。
clearCommunicationDevice() 在您的应用完成通话或会话后调用，以帮助确保用户在不同应用之间切换时获得出色的体验。

BluetoothProfile

BluetoothLeAudio 通过代理对象控制蓝牙服务。

电信 InCallService

InCallService#requestCallEndpointChange() 取代了已弃用的 InCallService.setAudioRoute() 和 InCallService.requestBluetoothAudio() API，允许应用请求将音频路由到特定的 CallEndpoint。客户端在请求更改时，不应定义自己的 CallEndpoint。相反，新端点应该是 InCallService.onAvailableCallEndpointsChanged(java.util.List) 提供的有效端点之一。
CallEndpoint.TYPE_BLUETOOTH 通过蓝牙引导音频流。
上述 InCallService API 旨在由 Android 手机上的默认电话应用或其他呼叫界面（如可穿戴设备、汽车或其他可能希望影响音频路由的蓝牙设备）使用。

电信 CallControl

新的 CallControl 类在 API level 34 中引入，仅用于取代 VoIP 应用的 Connection 和 ConnectionService。
CallControl.requestCallEndpointChange() 也请求 CallEndpoint 更改。此 API 取代了已弃用的 Connection.requestBluetoothAudio() 和 Connection.setAudioRoute() API。
除了更新的 Telecom 平台 API 之外，强烈建议在构建语音和/或视频通话应用时使用 Telecom Jetpack 库。此库可以极大地简化集成过程并改善所有 Android 界面上的 VoIP 通话。

音频设备信息

AudioDeviceInfo.TYPE_BLE_HEADSET 将音频设备类型描述为 LEA 设备。用于识别助听设备是否为 LEA 设备。

录音机

setPreferredDevice() 设置用于音频路由的首选设备。用户可以在系统设置中覆盖此设置。

蓝牙适配器

isLeAudioSupported() 返回平台硬件是否支持 LEA。
isLeAudioBroadcastSourceSupported() 返回平台硬件是否支持 LEA。

基于用例的指南

以下是根据特定用例实现 LEA 的指南。

语音通信应用

语音通信应用可以选择自行管理音频路由和设备状态，或者使用为您处理音频路由和状态逻辑的 Telecom API。

自管理：对于当前使用 startBluetoothSco()、stopBluetoothSco() 和 setSpeakerphoneOn() 或希望自管理音频路由状态的应用，请遵循音频管理器自管理呼叫指南。
管理：使用 Telecom Jetpack 库或Telecom 平台 API 来创建音频或视频通话应用。

这两种解决方案使您能够快速轻松地控制音频路由并在蓝牙设备之间切换。欲了解更多信息，请参阅电信管理呼叫指南。

录音应用

媒体录制器：使用媒体录制器录制音频时，如果蓝牙助听设备支持 LEA，您现在可以录制立体声。请查看录音指南。

低功耗音频 (LEA) 耳机建议

随着更多 LEA 耳机发布，我们在实际测试中发现了一些会降低用户体验的问题。规范并未涵盖所有这些问题。下表列出了 LEA 耳机制造商应遵循的建议，以改善 Android 用户的端到端体验。

描述	背景
双模耳机支持跨传输密钥派生 (CTKD) 支持经典蓝牙到 LE 配对和 LE 到经典蓝牙配对的密钥派生。	在 LEA 源设备市场份额增长之前，大多数新的 LEA 耳机将是双模的。重要的是，用户能够无缝配对其双模耳机并设置两种传输方式。这对于 Google 快速配对也很重要。
如果您希望 LEA 耳机可靠地重新连接到源设备，请支持定向通知 (TA)。 LE 音频耳塞应使用 TA 请求来自中央设备的传入连接。将添加到即将发布的 BT SIG 中。	与 BR/EDR 的寻呼模型不同（其中连接可以由手机或耳机发起），LEA 中的连接必须由中央设备发起。目前，许多耳机不使用 TA，这意味着中央设备可能无法在不将其添加到允许列表的情况下重新连接到外围设备。然而，允许列表的权宜之计可能会阻止耳机连接到不同的中央设备。因此，LEA 耳机正确支持 TA 非常重要，这样中央设备才能可靠地重新连接，而无需可能破坏多点连接的权宜之计。
双模耳塞的优化可发现性主耳塞 - BR/EDR 组件应使用其公共地址进行广告，并启用查询和页面扫描（通过 EIR 提供其名称），并将设备类别 (CoD) 的主要服务类别中的 LE 音频位 14 设置为 1。主耳塞 - LE 组件：主耳塞应使用与 BR/EDR 组件相同的公共地址和相同的完整本地名称执行可连接和可发现（有限或一般）广告，并将其外观类别设置为与远程设备类型匹配的适当外观类别，期望中央设备将使用此信息调整其 UI 和音频路由策略。副耳塞 - 仅 LE：副耳塞应执行可连接、不可发现的广告，并将其外观类别设置为与远程设备类型匹配的适当外观类别，期望中央设备将使用此信息调整其 UI 和音频路由策略耳塞应动态地从 CSIP 组中选举出一个领导者作为主设备。如果耳塞是双模的，则主设备必须是双模的，以确保配对后 LE 和经典功能都能正常工作。	这可以防止双模 LEA 耳塞在蓝牙设置中显示为重复条目，这可能会让用户感到困惑并损害 LEA 配对体验。动态领导者选举对于逐步配对的双模设备尤其重要。例如，如果在初始配对时只有一个耳塞可用，那么它应该将自己呈现为双模设备。当用户稍后与第二个耳塞配对时，他们只需要与 LE 组件配对，CSIP 将确保它们在 Android 上分组在一起。建议在配对期间使用身份地址，因为 BR/EDR 组件已经将其设备的公共地址暴露给附近的设备。
支持增强型属性协议 (EATT)。	减少配对和连接延迟。
支持强大的 GATT 缓存。	减少连接延迟，特别是对于 TWS 耳塞。
支持连接子速率。	允许更灵活的数据包调度和潜在的电池节省。
确保在播放和捕获的预处理和后处理期间，信号处理管道能够以 16、24、32 和 48 kHz 运行，并支持更高的频率。	利用 LEA 通话或 VoIP 捕获路径和媒体播放支持的更高采样率。
支持 LE 功率控制	更好的电源管理

上下文类型支持

描述	背景
除非耳机明确不支持给定的上下文类型，否则请使用分配编号 6.12.3 中指定的所有上下文类型。	例如，如果不支持“游戏”上下文类型，则 Android 将发送游戏声音。特别注意，“未指定”上下文类型并不意味着“任何上下文类型”，它不涵盖不支持的上下文类型。
当中央设备与外围设备的 ASCS 交互时，外围设备必须连接到中央设备的 MCS 和 TBS。中央设备可能不会总是使用 LE 音频作为流媒体路由，因为它可能会回退到使用 A2DP 或 HFP。外围设备可以使用 ASCS 交互作为中央设备是否将使用 LE 音频进行流媒体的指示。 ASCS 交互的一些示例是读取、写入和注册通知。

描述

背景

除非耳机明确不支持给定的上下文类型，否则请使用分配编号 6.12.3 中指定的所有上下文类型。

例如，如果不支持“游戏”上下文类型，则 Android 将发送游戏声音。特别注意，“未指定”上下文类型并不意味着“任何上下文类型”，它不涵盖不支持的上下文类型。

当中央设备与外围设备的 ASCS 交互时，外围设备必须连接到中央设备的 MCS 和 TBS。

中央设备可能不会总是使用 LE 音频作为流媒体路由，因为它可能会回退到使用 A2DP 或 HFP。外围设备可以使用 ASCS 交互作为中央设备是否将使用 LE 音频进行流媒体的指示。

ASCS 交互的一些示例是读取、写入和注册通知。