蓝牙低功耗音频

蓝牙低功耗音频 (LEA) 确保用户可以在不牺牲电池续航时间的情况下获得高保真音频，并允许他们无缝切换不同的用例。Android 13（API 级别 33）包含对 LEA 的内置支持。

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

用例

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

• 共享音频：用户可以同时将多个音频流共享到一个或多个音频接收设备。音频在源设备和连接的设备之间同步。

• 广播音频：用户可以将音频广播给朋友和家人，同时还可以连接到公共广播以获取信息、娱乐或辅助功能。

• LC3 音频编解码器支持：这是默认的音频编解码器，取代了用于 A2DP（媒体）和 HFP（语音）中的 SBC 编解码器以及 mSBC。LC3 效率更高、可重配置且质量更高。

• 音频采样改进：耳机在使用麦克风时可以保持高输出音频质量。经典蓝牙在使用蓝牙麦克风时会降低音频质量。使用 BLE 音频，输入和输出采样可以达到 32 kHz。

• 立体声麦克风：助听器可以使用立体声麦克风录制音频，以增强空间音频。

• 助听器配置文件 (HAP) 支持：与之前的 ASHA 协议相比，HAP 为用户提供了更大的可访问性和使用性。用户可以使用他们的助听器进行电话呼叫和 VoIP 应用。

• 增强型属性协议 (EATT) 支持：EATT 允许开发者同时向配对的助听器发送多个命令。

关键场景

用例主要分为四类

1. 对话式：需要低延迟通信路由的拨号器和 VoIP 应用提供高质量音频和更低的电池使用率。

2. 游戏：并发麦克风和高保真播放允许游戏将高质量音频流式传输到可听设备。当游戏将蓝牙麦克风设置为准备使用时，游戏应用程序可以访问 BLE 音频输入。然后，当玩家与其他玩家开始实时对话时，游戏应用程序可以无延迟地使用麦克风数据。

3. 媒体：媒体应用程序允许设置音频管理器的首选设备。用户可以通过更改系统设置中的首选设备来覆盖此设置。

4. 辅助功能：支持 BLE 音频助听器现在可以使用麦克风，允许用户在通话期间持续使用助听器。

BLE 音频 API 和方法

以下 API 和方法是支持 BLE 音频可听设备所必需的

AudioManager

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

BluetoothProfile

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

Telecom 入呼服务

• setAudioRoute() 将音频路由设置为当前活动设备。
• CallAudioState.ROUTE_BLUETOOTH 将音频流通过蓝牙传输。
• requestBluetoothAudio() 请求将音频路由到特定的蓝牙设备。

音频设备信息

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

音频录制器

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

蓝牙适配器

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

基于用例的指南

以下是基于特定用例实现 LEA 的指南。

语音通信应用程序

语音通信应用程序可以选择通过自行管理其状态或使用 Telecom API（为您执行音频路由和状态逻辑）来管理音频路由和设备状态。

• 自管理：对于当前使用 startBluetoothSco()、stopBluetoothSco() 和 setSpeakerphoneOn() 或想要自行管理音频路由状态的应用程序，请遵循 音频管理器自管理通话指南。

• 管理：使用 Telecom API 创建音频或视频通话应用程序。此 API 允许您快速轻松地控制音频路由并在蓝牙设备之间切换。有关更多信息，请参阅 Telecom 管理通话指南。

音频录制应用程序

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

LE 音频 (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 组件相同的公共地址以及与 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 交互的一些示例包括读取、写入和注册通知。