Audio Bluetooth de bajo consumo

El audio de baja energía de Bluetooth (LEA) garantiza que los usuarios puedan recibir audio de alta fidelidad sin sacrificar la duración de la 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 participación de mercado de los dispositivos de origen LEA. Los usuarios deberían poder vincular y configurar ambos transportes en sus auriculares de modo dual.

Casos de uso

Es posible que quieras integrar LEA para los siguientes casos de uso:

• Compartir audio: Los usuarios pueden compartir varias transmisiones de audio simultáneamente en uno o más dispositivos de receptor de audio. El audio se sincroniza entre el dispositivo de origen y los dispositivos conectados.

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

• Compatibilidad con el códec de audio LC3: Este es el códec de audio predeterminado y reemplaza el códec SBC que se usa 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 audio de salida cuando se usan micrófonos. El Bluetooth clásico reduce la calidad de audio cuando se usan micrófonos Bluetooth. Con el audio BLE, el muestreo de entrada y salida puede alcanzar los 32 kHz.

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

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

• Compatibilidad con el protocolo de atributo mejorado (EATT): EATT permite a los desarrolladores enviar varios comandos a la vez a los dispositivos de audio vinculados.

Situaciones clave

Existen cuatro categorías principales de casos de uso:

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

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

3. Contenido multimedia: Las aplicaciones de contenido multimedia pueden configurar el dispositivo preferido del administrador de audio. El usuario puede anular esta opción si cambia su dispositivo preferido desde la configuración del sistema.

4. Accesibilidad: Los audífonos que admiten audio BLE ahora pueden usar el micrófono, lo que permite a los usuarios usar sus audífonos de forma continua para una llamada.

APIs y métodos de audio BLE

Se requieren las siguientes APIs y métodos para admitir dispositivos 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 video. Las aplicaciones de chat de voz o videochat 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().
• clearCommunicationDevice() Se llama a después de que tu app finaliza una llamada o sesión para garantizar que el usuario tenga una excelente experiencia cuando se mueve entre diferentes aplicaciones.

BluetoothProfile

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

Telecom InCallService

• InCallService#requestCallEndpointChange() reemplaza las APIs obsoletas InCallService.setAudioRoute() y InCallService.requestBluetoothAudio() para permitir que las apps soliciten el enrutamiento de audio a un CallEndpointespecí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 que proporciona InCallService.onAvailableCallEndpointsChanged(java.util.List).
• CallEndpoint.TYPE_BLUETOOTH dirige la transmisión de audio a través de Bluetooth.
• Estas InCallService APIs mencionadas anteriormente están diseñadas para usarse con la app de teléfono predeterminada en un teléfono Android o con otras superficies de llamadas, como wearables, automóviles o 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 VoIP.
• CallControl.requestCallEndpointChange() también solicita un CallEndpoint cambio. Esta API reemplaza las APIs obsoletas Connection.requestBluetoothAudio() y Connection.setAudioRoute().
• Además de las APIs actualizadas de la plataforma de Telecom, se recomienda la biblioteca de Telecom Jetpack se encarecidamente cuando se compilan aplicaciones de llamadas de voz o video. Esta biblioteca puede simplificar en gran medida el proceso de integración y mejorar las llamadas VoIP en todas las superficies de Android.

Información del dispositivo de audio

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

Grabador de audio

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

Adaptador Bluetooth

• isLeAudioSupported(): Muestra una @BluetoothStatusCodes constante (FEATURE_SUPPORTED, FEATURE_NOT_SUPPORTED o un código de error) que indica si el hardware del dispositivo admite LE Audio.
• isLeAudioBroadcastSourceSupported(): Muestra una @BluetoothStatusCodes constante (FEATURE_SUPPORTED, FEATURE_NOT_SUPPORTED o un código de error) que indica si el hardware del dispositivo admite la fuente de transmisión de LE Audio.

Guías basadas en casos de uso

A continuación, se incluyen lineamientos para implementar LEA en función de casos de uso específicos.

Aplicaciones de comunicación de voz

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

• Administración automática: Para las aplicaciones que actualmente usan startBluetoothSco(), stopBluetoothSco(), y setSpeakerphoneOn() o que desean administrar automáticamente el estado de enrutamiento de audio, sigue la guía de llamadas administradas automáticamente del administrador de audio.

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

Estas dos soluciones te permiten controlar de forma rápida y sencilla el enrutamiento de audio y cambiar entre dispositivos Bluetooth. Para obtener más información, consulta la guía de llamadas administradas de Telecom.

Aplicaciones de grabación de audio

• Grabador de contenido multimedia: Cuando grabas audio con el grabador de contenido multimedia, ahora puedes grabar en estéreo si el dispositivo de audio Bluetooth admite LEA. Consulta la guía de grabación de audio.

Recomendaciones para auriculares LE Audio (LEA)

A medida que se lanzan más auriculares LEA, descubrimos problemas en las pruebas del 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 los fabricantes de auriculares LEA deben seguir para mejorar la experiencia integral de los usuarios de Android.

Descripción	Contexto
Admite la derivación de claves de transporte cruzado (CTKD) para auriculares de modo dual: Admite la derivación de claves para el emparejamiento de Classic a LE y LE a Classic.	La mayoría de los auriculares LEA nuevos serán de modo dual hasta que crezca la participación de mercado de los dispositivos de origen LEA. Es importante que los usuarios puedan emparejar sus auriculares de modo dual sin problemas y configurar ambos transportes. Esto también es importante para Google Vinculación rápida.
Admite anuncios segmentados (TAs) si quieres tus auriculares LEA se vuelvan a conectar de forma confiable a los dispositivos de origen. Los auriculares de audio LE deben usar TAs para solicitar una conexión entrante desde los dispositivos centrales. Se agregará a la próxima BT SIG.	A diferencia del modelo de paginación de BR/EDR, en el que la conexión puede iniciarse desde el teléfono o los auriculares, la conexión en LEA debe iniciarse desde el dispositivo central. Actualmente, muchos auriculares no usan TAs, 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 alternativa 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 TAs de forma adecuada para que el dispositivo central pueda volver a conectarse de forma confiable sin soluciones alternativas que puedan interrumpir las conexiones multipunto.
Visibilidad optimizada para auriculares de modo dual Auricular principal: componente BR/EDR debe anunciarse con su dirección pública, habilitar la consulta y el análisis de página con su nombre disponible a través de EIR y establecer el bit 14 de audio LE en 1 en las clases de servicio principales de la clase de dispositivo (CoD). Auricular principal: componente LE: El auricular principal debe realizar un anuncio conectable y visible (limitado 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 su IU y las políticas de enrutamiento de audio. Auricular secundario: solo LE: El auricular secundario debe realizar un anuncio conectable y no visible 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 las políticas de enrutamiento de audio Los auriculares deben elegir de forma dinámica un líder del grupo CSIP para que sea el dispositivo principal. Si el auricular es de modo dual, el dispositivo principal debe ser de modo dual para garantizar que las funcionalidades LE y Classic funcionen correctamente después del emparejamiento.	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 emparejamiento de LEA. La elección dinámica de líder es especialmente importante para los dispositivos de modo dual que se emparejan de forma incremental. Por ejemplo, si solo hay un auricular está disponible en el emparejamiento inicial, debe presentarse como un dispositivo de modo dual. Cuando un usuario se empareja con el segundo auricular más adelante, solo necesita emparejarse con el componente LE, y CSIP se asegurará de que estén agrupados en Android. Se recomienda 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 atributo mejorado (EATT).	Reduce la latencia de emparejamiento y conexión.
Admite el almacenamiento en caché de GATT sólido.	Reduce la latencia de conexión, en especial para los auriculares TWS.
Admite la subcalificación de conexión.	Permite una programación de paquetes más flexible y posibles ahorros de batería.
Asegúrate de que, durante el preprocesamiento y el posprocesamiento para la reproducción y la captura, la canalización de procesamiento de señales pueda operar a 16, 24, 32 y 48 kHz, además de admitir frecuencias más altas.	Aprovecha las tasas de muestreo más altas admitidas para las rutas de captura de llamadas o VoIP de LEA y la reproducción de contenido multimedia.
Admite 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 Números asignados 6.12.3 a menos que los auriculares no admitan explícitamente un tipo de contexto determinado.	Por ejemplo, si no se admite el tipo de contexto "Juego", Android enviará sonidos de juegos. En particular, ten en cuenta que el tipo de contexto "No especificado" no significa "cualquier tipo de contexto" y no abarca los tipos de contexto no admitidos.
Cuando el dispositivo central interactúa con el ASCS del dispositivo periférico, el periférico debe conectarse al MCS y al TBS del dispositivo central. Es posible que el dispositivo central no siempre use el audio LE como la ruta de transmisión ya que podría volver a usar A2DP o HFP. El dispositivo periférico puede usar la interacción ASCS como una indicación de si el dispositivo central usará audio LE para la transmisión. Algunos ejemplos de interacciones ASCS son leer, escribir y registrarse para notificaciones.

Nota: De acuerdo con la especificación, los auriculares pueden quitar tipos de contexto de los tipos de contexto disponibles en cualquier momento y para todos los dispositivos conectados, incluso un dispositivo que actualmente transmite un tipo de contexto determinado. Se recomienda que los auriculares no quiten el tipo de contexto que se transmite actualmente de los tipos de contexto disponibles en el dispositivo que transmite ese tipo de contexto.