低功耗蓝牙音频 (LEA) 可确保用户接收到高保真度的音频，而不必牺牲电池续航时间，并且还可以在不同使用情形之间无缝切换。Android 13（API 级别 33）内置了对 LEA 的支持。
在 LEA 音源设备市场份额增长之前，大多数 LEA 耳机都将采用双模。用户应该能够在双模耳机上配对和设置这两种传输方式。
使用场景
您可能希望在以下应用场景中集成 LEA：
共享音频：用户可以同时将多个音频串流共享到一个或多个音频接收器设备。音频会在源设备和已连接的设备之间同步。
广播音频：用户可以向朋友和家人广播音频，同时还可以连接到公共广播，以获取信息、娱乐或无障碍功能。
LC3 音频编解码器支持：这是默认音频编解码器，可取代 A2DP（媒体）中使用的 SBC 编解码器和 HFP（语音）中的 mSBC。LC3 效率更高、可重新配置且质量更高。
音频采样改进：使用麦克风时，耳机可以保持高输出音质。使用蓝牙麦克风时，传统蓝牙会降低音质。借助 BLE 音频，输入和输出采样率可达到 32 kHz。
立体声麦克风：可穿戴设备可以使用立体声麦克风录制音频，以增强空间音频效果。
助听器配置文件 (HAP) 支持：与之前的 ASHA 协议相比，HAP 为用户提供了更好的无障碍功能和使用体验。用户可以使用助听器进行电话通话和使用 VoIP 应用。
增强型属性协议 (EATT) 支持：EATT 可让您一次向配对的耳戴式设备发送多个命令。
关键场景
主要有四大类应用场景：
对话：需要低延迟通信路由的拨号器和 VoIP 应用可提供高品质音频，并减少电池用量。
游戏：麦克风和高保真播放功能可同时运行，让游戏能够将高品质音频流式传输到可穿戴设备。当游戏将蓝牙麦克风设置为可供使用时，游戏应用可以访问 BLE 音频输入。然后，当玩家开始与同伴玩家进行实时对话时，游戏应用可以立即使用麦克风数据。
媒体：媒体应用可以设置音频管理器的首选设备。用户可以通过在系统设置中更改其首选设备来替换此设置。
无障碍：支持 BLE 音频的助听器可以使用麦克风，让用户在通话期间持续使用助听器。
BLE 音频 API 和方法
如需支持 BLE 音频可穿戴设备，必须具备以下 API 和方法：
AudioManager
setCommunicationDevice()会选择应在通信用例（例如语音或视频通话）中使用的音频设备。语音或视频聊天应用可以使用此方法来选择与平台默认选择的音频设备不同的音频设备。此 API 取代了以下已废弃的 API：startBluetoothSco()、stopBluetoothSco()和setSpeakerphoneOn()。clearCommunicationDevice()会在应用完成通话或会话后调用，以帮助确保用户在不同应用之间切换时获得良好的体验。
BluetoothProfile
BluetoothLeAudio使用代理对象控制蓝牙服务。
Telecom InCallService
InCallService.requestCallEndpointChange()取代了已废弃的InCallService.setAudioRoute()和InCallService.requestBluetoothAudio()API，并允许应用请求将音频路由到特定CallEndpoint。客户端在请求更改时不应定义自己的CallEndpoint。相反，新端点应是InCallService.onAvailableCallEndpointsChanged(java.util.List)提供的有效端点之一。CallEndpoint.TYPE_BLUETOOTH通过蓝牙引导音频串流。- 这些
InCallServiceAPI 专供手机上的默认电话应用或其他可能需要影响音频路由的通话界面（例如穿戴式设备、汽车或其他蓝牙设备）使用。
Telecom CallControl
CallControl类是在 Android 14（API 级别 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()：返回一个@BluetoothStatusCodes常量（FEATURE_SUPPORTED、FEATURE_NOT_SUPPORTED或错误代码），指示设备硬件是否支持 LE 音频。isLeAudioBroadcastSourceSupported()：返回一个@BluetoothStatusCodes常量（FEATURE_SUPPORTED、FEATURE_NOT_SUPPORTED或错误代码），用于指示设备硬件是否支持 LE 音频广播源。
基于应用场景的指南
以下是根据特定用例实现 LEA 的指南。
语音通信应用
语音通信应用可以选择自行管理其状态，也可以选择使用 Telecom API 来管理音频路由和设备状态，后者会为您执行音频路由和状态逻辑。
自行管理：对于使用
startBluetoothSco()、stopBluetoothSco()和setSpeakerphoneOn()或想要自行管理音频路由状态的应用，请遵循音频管理器自行管理的通话指南。受管理：使用 Telecom Jetpack 库或 Telecom 平台 API 创建音频或视频通话应用。
借助这两个解决方案，您可以控制音频路由并在蓝牙设备之间切换。如需了解详情，请参阅电信管理通话指南。
录音应用
- 录音机：使用录音机录制音频时，如果蓝牙可穿戴设备支持 LEA，您可以录制立体声音频。如需了解详情，请参阅录音指南。
耳机建议
随着更多 LEA 耳机发布，我们在实际测试中发现了一些会降低用户体验的问题。该规范并未涵盖所有这些问题。下表列出了 LEA 耳机制造商应遵循的建议，以改善 Android 用户的端到端体验。
| 说明 | 上下文 |
|---|---|
支持双模耳机的跨传输密钥派生 (CTKD)：
|
在 LEA 音源设备的市场份额增长之前，大多数新 LEA 耳机都将采用双模。用户必须能够无缝配对双模耳机并设置这两种传输方式。这对 Google 快速配对也很重要。 |
|
如果您希望 LEA 耳机能够可靠地重新连接到源设备，请支持定向通告 (TA)。 LE 音频耳机应使用 TA 请求来自中央设备的传入连接。 将添加到即将发布的 BT SIG 中。 |
在 BR/EDR 的分页模型中，手机或耳机都可以发起连接，而 LEA 中的连接必须由中央设备发起。许多耳机不使用 TA，这意味着，如果不将外围设备添加到许可清单，中央设备可能无法重新连接到外围设备。 不过，许可清单解决方法可能会阻止耳机连接到其他中心设备。因此，LEA 耳机必须正确支持 TA，以便中央设备能够可靠地重新连接，而无需采用可能破坏多点连接的权宜解决方法。 |
优化了双模耳机的可检测性
|
这样可以防止双模 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 互动的一些示例包括读取、写入和注册通知。 |
Auracast 发射器建议
本部分提供了有关配置 Auracast 发射器的建议。
间歇性广播
公共场所（例如公交车站）的语音播报通常是间歇性的，中间有很长的静音时间。在公告之间持续流式传输静音或背景音频会浪费接收器电量，并阻止用户收听其主要音频串流，例如本地媒体或其他活跃的 Auracast 音频串流。
为了提升用户体验，Android 建议 Auracast 发射器遵循以下准则来处理间歇性广播。
定义
- 感兴趣的音频：面向用户的核心信息内容，例如登机口或列车广播。
- 背景音频：在感兴趣的音频片段之间传输的背景静音、静态声音或环境音乐。
- 间歇性广播：在感兴趣的音频和背景音频或完全没有音频之间交替的广播。
识别间歇性广播
如需将广播指定为间歇性广播，广播方应在以下两个位置添加 Audio_Active_State 元数据 LTV（长度-类型-值）结构 [1]：
- BASE 结构第 2 级元数据（定期通告）[2]
- 公共广播通告元数据（扩展通告）[3]
为了帮助接收器识别间歇性广播并决定是否播放音频流，广播器还应准确设置 Streaming_Audio_Context 元数据 LTV 结构 [1]。
识别感兴趣的音频
为了动态指示间歇性广播在任何给定时间是否包含感兴趣的音频，发射器会使用 Audio_Active_State 元数据 LTV 结构。
- BASE 结构第 2 级元数据：值为 0x01 表示子群组中的 BIS 包含感兴趣的音频。
- 公共广播公告元数据：值为 0x01 表示 BIG 中的至少一个 BIS 包含感兴趣的音频。
在传输感兴趣的音频之前，应立即将 Audio_Active_State 元数据 LTV 值设置为 0x01，以便扫描设备与公共广播源同步。相反，在传输结束后不久，应将其设置为 0x00。
利用流式音频上下文
提供明确的上下文有助于 Android 框架和接收设备确定传入音频流的优先级。例如，公共广播 (PA) 系统可以将 Streaming_Audio_Context 类型设置为 Instructional，以便让广播能够干净利落地中断接收器的本地媒体播放，并在广播结束后无缝恢复播放。
参考
[1] 蓝牙分配编号，
https://www.bluetooth.com/specifications/assigned-numbers/
[2] 基本音频配置文件，
https://www.bluetooth.com/specifications/specs/basic-audio-profile-1-0-3/
[3] 公共广播配置文件，
https://www.bluetooth.com/specifications/specs/public-broadcast-profile-1-0-2/