Audio Bluetooth de bajo consumo

El audio Bluetooth de bajo consumo (LEA) garantiza que los usuarios puedan recibir audio de alta fidelidad sin sacrificar la duración de batería y les permite cambiar sin problemas entre diferentes casos de uso. Android 13 (nivel de API 33) incluye compatibilidad integrada con LEA.

La mayoría de los auriculares LEA serán de modo dual hasta que crezca la cuota de mercado de los dispositivos de origen LEA. Los usuarios deben poder vincular y configurar ambos transportes en sus auriculares de modo dual.

Casos de uso

Te recomendamos que integres LEA para los siguientes casos de uso:

• Compartir audio: Los usuarios pueden compartir varios flujos de audio de forma simultánea en uno o más dispositivos de destino de audio. El audio se sincroniza entre el dispositivo de origen y los dispositivos conectados.

• Audio de transmisión: Los usuarios pueden transmitir audio a amigos y familiares, y conectarse a transmisiones públicas para obtener información, entretenimiento o accesibilidad.

• Compatibilidad con códecs de audio LC3: Es el códec de audio predeterminado y reemplaza el códec SBC utilizado para A2DP (contenido multimedia) y mSBC en HFP (voz). LC3 es más eficiente, reconfigurable y de mayor calidad.

• Mejoras en el muestreo de audio: Los auriculares pueden mantener una alta calidad de salida de audio cuando usan micrófonos. La versión clásica de Bluetooth reduce la calidad del audio cuando se utilizan micrófonos Bluetooth. Con el audio BLE, el muestreo de entrada y salida puede alcanzar los 32 kHz.

• Micrófono estéreo: Los dispositivos auditivos pueden grabar audio con micrófonos estéreo para mejorar el audio espacial.

• Compatibilidad con el perfil de audífonos (HAP): El HAP ofrece a los usuarios una mayor accesibilidad y uso que los protocolos ASHA anteriores. Los usuarios pueden usar sus audífonos para las llamadas telefónicas y las aplicaciones de VoIP.

• Compatibilidad con el protocolo de atributos mejorados (EATT): EATT permite que los desarrolladores envíen varios comandos a la vez a los dispositivos auditivos vinculados.

Situaciones clave

Existen cuatro categorías principales de casos de uso:

1. Conversacional: Las aplicaciones de Teléfono y VoIP que requieren enrutamiento de comunicación de baja latencia ofrecen audio de alta calidad y menos uso de la batería.

2. Videojuegos: El micrófono simultáneo y la reproducción de alta fidelidad permiten que los juegos transmitan audio de alta calidad a los dispositivos de audio. Una app de juego puede acceder a la entrada de audio BLE cuando un juego activa el micrófono Bluetooth como listo para usar. Luego, cuando un jugador inicia una conversación en vivo con otro jugador, la app de juego puede usar los datos del micrófono sin demora.

3. Multimedia: Las aplicaciones multimedia pueden establecer el dispositivo preferido del administrador de audio. El usuario puede anular esta acción cambiando el dispositivo preferido desde la configuración del sistema.

4. Accesibilidad: Ahora, los audífonos compatibles con BLE Audio pueden usar el micrófono, lo que les permite a los usuarios utilizarlos continuamente para una llamada.

APIs y métodos de BLE Audio

Se requieren las siguientes APIs y métodos para admitir dispositivos auditivos de audio BLE:

AudioManager

• setCommunicationDevice() selecciona el dispositivo de audio que se debe usar para los casos de uso de comunicación, por ejemplo, llamadas de voz o videollamadas. Las aplicaciones de chat de voz o video pueden usar este método para seleccionar un dispositivo de audio diferente del que selecciona la plataforma de forma predeterminada. Esta API reemplaza las siguientes APIs obsoletas: startBluetoothSco(), stopBluetoothSco() y setSpeakerphoneOn().
• Se llama a clearCommunicationDevice() después de que tu app finaliza una llamada o sesión para ayudar a garantizar que el usuario tenga una excelente experiencia cuando se mueva entre diferentes aplicaciones.

BluetoothProfile

• BluetoothLeAudio controla el servicio de Bluetooth a través del objeto de proxy.

Telecom InCallService

• InCallService#requestCallEndpointChange() reemplaza las APIs de InCallService.setAudioRoute() y InCallService.requestBluetoothAudio() que dejaron de estar disponibles para permitir que las apps soliciten el enrutamiento de audio a un CallEndpoint específico. Los clientes no deben definir su propio CallEndpoint cuando solicitan un cambio. En su lugar, el extremo nuevo debe ser uno de los extremos válidos proporcionados por InCallService.onAvailableCallEndpointsChanged(java.util.List).
• CallEndpoint.TYPE_BLUETOOTH dirige la transmisión de audio a través de Bluetooth.
• Estas APIs de InCallService antes mencionadas están diseñadas para que las use la app de teléfono predeterminada en un teléfono Android o en otras plataformas de llamadas, como wearables, automóviles y otros dispositivos Bluetooth que puedan influir en el enrutamiento de audio.

Telecom CallControl

• La nueva clase CallControl se introduce en el nivel de API 34 para reemplazar Connection y ConnectionService solo para aplicaciones de VoIP.
• CallControl.requestCallEndpointChange() también solicita un cambio de CallEndpoint. Esta API reemplaza las APIs obsoletas de Connection.requestBluetoothAudio() y Connection.setAudioRoute().
• Además de las APIs actualizadas de la plataforma de telecomunicaciones, se recomienda la biblioteca de Jetpack de telecomunicaciones cuando se compilan aplicaciones de voz o videollamadas. Esta biblioteca puede simplificar enormemente el proceso de integración y mejorar las llamadas VoIP en todas las plataformas de Android.

Información del dispositivo de audio

• AudioDeviceInfo.TYPE_BLE_HEADSET describe el tipo de dispositivo de audio como un dispositivo de LEA. Se usa para identificar si el dispositivo auditivo es un dispositivo LEA.

Grabador de audio

• setPreferredDevice() establece el dispositivo preferido para que use el enrutamiento de audio. El usuario puede anular esto en la configuración del sistema.

Adaptador Bluetooth

• isLeAudioSupported() se muestra si el hardware de la plataforma admite LEA.
• Se muestra isLeAudioBroadcastSourceSupported() si el hardware de la plataforma admite LEA.

Guías basadas en el caso de uso

A continuación, se presentan las pautas para implementar el LEA en función de casos de uso específicos.

Aplicaciones de comunicación por voz

Las aplicaciones de comunicación por voz pueden administrar el enrutamiento de audio y el estado del dispositivo administrando su estado por su cuenta o usando la API de Telecom, que realiza la lógica de enrutamiento de audio y estado por ti.

• Autoadministrado: En el caso de las aplicaciones que actualmente usan startBluetoothSco(), stopBluetoothSco() y setSpeakerphoneOn(), o que desean autoadministrar el estado de enrutamiento de audio, sigue la guía de llamadas autoadministradas del Administrador de audio.

• Administrada: Usa la biblioteca de Jetpack de telecomunicaciones o las APIs de la plataforma de telecomunicaciones para crear una aplicación de llamadas de audio o video.

Estas dos soluciones te permiten controlar el enrutamiento de audio y cambiar entre dispositivos Bluetooth con rapidez y facilidad. Para obtener más información, consulta la guía de llamadas administradas por telecomunicaciones.

Aplicaciones de grabación de audio

• Grabadora de contenido multimedia: Cuando grabes audio con la grabadora de contenido multimedia, ahora podrás grabar en estéreo si el dispositivo auditivo Bluetooth admite LEA. Consulta la Guía de grabación de audio.

Recomendaciones de auriculares LE Audio (LEA)

A medida que se lanzan más visores LEA, descubrimos problemas en las pruebas en el mundo real que degradan la experiencia del usuario. La especificación no abarca todos estos problemas. En la siguiente tabla, se proporciona una lista de recomendaciones que deben seguir los fabricantes de auriculares LEA para mejorar la experiencia de extremo a extremo de los usuarios de Android.

Descripción	Contexto
Compatibilidad con la derivación de claves de transporte cruzado (CTKD) para auriculares de modo doble: Admite la derivación de claves para la vinculación de Classic a LE y de LE a Classic.	La mayoría de los auriculares de la LEA nuevos serán de modo dual hasta que aumente la participación de mercado de los dispositivos de origen de la LEA. Es importante que los usuarios puedan vincular sus auriculares de modo dual sin problemas y configurar ambos transportes. Esto también es importante para la vinculación rápida de Google.
Admite anuncios segmentados (TA) si quieres que tus auriculares LEA se vuelvan a conectar de forma confiable a los dispositivos de origen. Los auriculares de audio LE deben usar TA para solicitar una conexión entrante de los dispositivos centrales. Se agregará a la próxima reunión de BT SIG.	A diferencia del modelo de paginación de BR/EDR, en el que el teléfono o los auriculares pueden iniciar una conexión, el dispositivo central debe iniciar una conexión en LEA. Actualmente, muchos auriculares no usan TA, lo que significa que es posible que el dispositivo central no pueda volver a conectarse al periférico sin agregarlo a una lista de entidades permitidas. Sin embargo, una solución de lista de entidades permitidas podría impedir que los auriculares se conecten a un dispositivo central diferente. Por lo tanto, es importante que los auriculares LEA admitan los TA de forma correcta para que el dispositivo central pueda volver a conectarse de forma confiable sin soluciones alternativas que puedan interrumpir las conexiones multipunto.
Visibilidad optimizada de los auriculares de modo dual El auricular principal (componente BR/EDR) debe anunciarse con su dirección pública y habilitar la consulta y el escaneo de páginas con su nombre disponible a través de EIR, y establecer el bit de audio LE 14 en 1 en las clases de servicio principales de la clase de dispositivo (CoD). Auricular principal: componente LE: El auricular principal debe realizar una publicidad conectable y detectable (limitada o general) con la misma dirección pública que el componente BR/EDR y el mismo nombre local completo que el componente BR/EDR, con su categoría de apariencia establecida como una categoría de apariencia adecuada que coincida con el tipo de dispositivo remoto con la expectativa de que el dispositivo central use esta información para ajustar sus políticas de enrutamiento de audio y de la IU. Auricular secundario: Solo LE: El auricular secundario debe realizar un anuncio conectable y no detectable con su categoría de apariencia establecida como una categoría de apariencia adecuada que coincida con el tipo de dispositivo remoto con la expectativa de que el dispositivo central use esta información para ajustar su IU y sus políticas de enrutamiento de audio. Los auriculares deben elegir de forma dinámica un líder del grupo de CSIP para que sea el dispositivo principal. Si el auricular está en modo dual, el dispositivo principal debe estar en modo dual para garantizar que tanto las funciones LE como la clásica funcionen correctamente después de la vinculación.	Esto evita que los auriculares LEA de modo dual aparezcan como entradas duplicadas en la configuración de Bluetooth, lo que podría confundir a los usuarios y comprometer la experiencia de vinculación de LEA. La elección de líder dinámico es especialmente importante para los dispositivos de modo dual que se vinculan de forma incremental. Por ejemplo, si solo hay un auricular disponible durante el emparejamiento inicial, este debería presentarse como un dispositivo de modo dual. Cuando un usuario vincula el segundo auricular más adelante, solo debe vincularlo con el componente LE, y CSIP se asegurará de que se agrupen en Android. Se recomienda usar la dirección de identidad durante el emparejamiento porque el componente BR/EDR ya expone la dirección pública del dispositivo a los dispositivos cercanos.
Admite el protocolo de atributos mejorado (EATT).	Reduce la latencia de vinculación y conexión.
Admite almacenamiento en caché GATT sólido.	Reduce la latencia de conexión, especialmente para los auriculares TWS.
Admite la subclasificación de conexión.	Permite una programación de paquetes más flexible y un ahorro potencial de batería.
Asegúrate de que, durante el procesamiento previo y posterior para la reproducción y la captura, la canalización de procesamiento de señal pueda funcionar a 16, 24, 32 y 48 kHz y admitir frecuencias más altas.	Aprovecha las tasas de muestreo más altas admitidas para las llamadas de LEA o las rutas de captura de VoIP y la reproducción de contenido multimedia.
Compatibilidad con el control de energía LE	Mejor administración de energía

Compatibilidad con el tipo de contexto

Descripción	Contexto
Usa todos los tipos de contexto especificados en Assigned Numbers 6.12.3, a menos que el visor no admita explícitamente un tipo de contexto determinado.	Por ejemplo, si el tipo de contexto "Juego" no se admite, Android enviará sonidos de juego. En particular, ten en cuenta que el tipo de contexto "Sin especificar" no significa "cualquier tipo de contexto" y no abarca los tipos de contexto no compatibles.
Cuando el dispositivo central interactúa con el ASCS del dispositivo periférico, este último debe conectarse a los MCS y TBS del dispositivo central. Es posible que el dispositivo central no siempre use LE Audio como ruta de transmisión porque podría recurrir a A2DP o HFP. El dispositivo periférico puede usar la interacción de ASCS como un indicador de si el dispositivo central usará audio LE para la transmisión. Algunos ejemplos de interacciones de ASCS son leer, escribir y registrarse para recibir notificaciones.