Las entradas de audio suelen provenir del micrófono integrado, un micrófono externo o una interfaz de audio conectada al dispositivo. La entrada de audio también puede provenir de una conversación telefónica.
A veces, dos o más apps pueden querer "capturar" la misma entrada de audio. Incluso para diferentes tareas. Por ejemplo, algunas apps que reciben audio podrían estar “grabando”, como una grabadora de voz simple, mientras que otras podrían estar “escuchando”, como Asistente de Google o un servicio de accesibilidad que responde a comandos por voz.
En cualquier caso, esas apps quieren recibir entradas de audio. En esta página, usamos el término "capturar", independientemente de si una app está grabando o solo escuchando.
Si dos o más apps quieren capturar audio al mismo tiempo, puede haber un problema para entregar la señal de audio de la misma fuente a todas ellas. En esta página, se describe cómo el sistema Android comparte la entrada de audio entre varias apps que capturan audio.
Comportamiento anterior a Android 10
Antes de Android 10, una app solo podía capturar el flujo de audio de entrada a la vez. Si alguna app ya estaba grabando o escuchando audio, tu app podría crear un objeto AudioRecord, pero se mostraría un error cuando llamaras a AudioRecord.startRecording() y no se iniciaría la grabación.
Una excepción a esta regla era cuando una app con privilegios (como Asistente de Google o un servicio de accesibilidad) tenía el permiso android.permission.CAPTURE_AUDIO_HOTWORD y usaba una fuente de audio de tipo HOTWORD. En ese caso, otra app podía empezar a grabar. Cuando eso sucedía, finalizaba la app con privilegios y la nueva capturaba la entrada.
Se agregó otro cambio en Android 9: solo las apps que se ejecutan en primer plano (o un servicio en primer plano) pueden capturar la entrada de audio. Cuando una app sin un servicio en primer plano o un componente de la IU en primer plano comenzaba a capturar, la app seguía ejecutándose, pero no se escuchaba, incluso si era la única app que capturaba audio en ese momento.
Comportamiento de Android 10
El comportamiento anterior a Android 10 es "por orden de llegada". Una vez que una app comienza a capturar audio, ninguna otra app puede acceder a la entrada de audio hasta que se detenga la app que está capturando audio.
Android 10 impone un esquema de prioridad que puede cambiar la transmisión de audio de entrada entre apps mientras se ejecutan. En la mayoría de los casos, si una app nueva adquiere la entrada de audio, la app que estaba capturando antes sigue ejecutándose, pero no recibe audio. En algunos casos, el sistema puede seguir enviando audio a ambas apps. A continuación, se explican las diferentes situaciones de uso compartido.
Este esquema es similar a la forma en que el enfoque de audio controla varias apps que compiten por el uso de la salida de audio. Sin embargo, el foco de audio se administra mediante solicitudes programáticas para obtener y liberar el foco, mientras que el esquema de cambio de entrada que se describe aquí se basa en una política de priorización que se aplica automáticamente cada vez que una app nueva comienza a capturar audio.
Para la captura de audio, Android distingue dos tipos de apps:
- El usuario instala las apps "corrientes".
- Las apps "privilegiadas" vienen preinstaladas en el dispositivo. Entre estas, se incluyen el Asistente de Google y todos los servicios de accesibilidad.
Además, una app recibe un trato diferente si utiliza una fuente de audio "sensible a la privacidad": CAMCORDER o VOICE_COMMUNICATION.
Las reglas de priorización para usar y compartir la entrada de audio son las siguientes:
- Las apps privilegiadas tienen mayor prioridad que las comunes.
- Las apps que tienen IU visibles en primer plano tienen mayor prioridad que las que están en segundo plano.
- Las apps que capturan audio de una fuente sensible a la privacidad tienen mayor prioridad que las que no lo hacen.
- Dos apps comunes no pueden capturar audio al mismo tiempo.
- En algunas situaciones, una app privilegiada puede compartir la entrada de audio con otra app.
- Si dos apps en segundo plano de la misma prioridad están capturando audio, la última que se inició tiene mayor prioridad.
Situaciones de uso compartido
Cuando dos apps intentan capturar audio, es posible que ambas puedan recibir la señal de entrada o que una de ellas reciba silencio.
Hay cuatro situaciones principales:
- Asistente y app común
- Servicio de accesibilidad y app común
- Dos apps comunes
- Llamada de voz y app común
Asistente y app común
El Asistente es una app con privilegios porque está preinstalada y tiene el rol RoleManager.ROLE_ASSISTANT.
Se trata de forma similar a cualquier otra app preinstalada con esta función.
Android comparte el audio de entrada según estas reglas:
El Asistente puede recibir audio (no importa si está en primer o segundo plano) a menos que otra app que use una fuente de audio sensible a la privacidad ya esté capturando.
La app recibe audio, a menos que el Asistente tenga un componente de IU visible en la parte superior de la pantalla.
Ten en cuenta que ambas apps reciben audio solo cuando el Asistente está en segundo plano y la otra app no está capturando desde una fuente de audio sensible a la privacidad.
Servicio de accesibilidad y app común
Un AccessibilityService requiere una declaración estricta.
Android comparte el audio de entrada según estas reglas:
Si la IU del servicio está en la parte superior, tanto el servicio como la app reciben la entrada de audio. Este comportamiento ofrece funcionalidades como el control de una llamada de voz o la captura de video con comandos por voz.
Si el servicio no está en la parte superior, este caso se trata como el de dos apps comunes, que se explica a continuación.
Dos apps comunes
Cuando dos apps capturan contenido simultáneamente, solo una recibe audio, y la otra recibe silencio.
Android comparte el audio de entrada según estas reglas:
- Si ninguna de las apps es sensible a la privacidad, la app con una IU en la parte superior recibe audio. Si ninguna tiene una IU, la que haya iniciado la captura más reciente recibirá audio.
- Si una de las apps es sensible a la privacidad, recibe audio y la otra app se silencia, incluso si tiene una IU en la parte superior o comenzó a capturar más recientemente.
- Si ambas apps son sensibles a la privacidad, la app que comenzó a capturar más recientemente recibe audio y la otra recibe silencio.
Llamada de voz y app común
Una llamada de voz está activa si el modo de audio que muestra AudioManager.getMode() es MODE_IN_CALL o MODE_IN_COMMUNICATION.
Android comparte el audio de entrada según estas reglas:
- La llamada siempre recibe audio.
- La app puede capturar audio si es un servicio de accesibilidad.
La app puede capturar la llamada de voz si es una app con privilegios (preinstalada) que tiene el permiso
CAPTURE_AUDIO_OUTPUT.Para capturar el vínculo ascendente (TX), el vínculo descendente (RX) o ambos de la llamada de voz, la app debe especificar las fuentes de audio
MediaRecorder.AudioSource.VOICE_UPLINKoMediaRecorder.AudioSource.VOICE_DOWNLINK, o el dispositivoAudioDeviceInfo.TYPE_TELEPHONY.
Comportamiento de Android 11
Android 11 (nivel de API 30) observa el esquema de prioridad de Android 10 que se describió anteriormente. También proporciona métodos nuevos en AudioRecord, MediaRecorder y AAudioStream que habilitan y deshabilitan la capacidad de capturar audio de forma simultánea, independientemente del caso de uso seleccionado.
Los nuevos métodos son los siguientes:
AudioRecord.Builder.setPrivacySensitive()AudioRecord.isPrivacySensitive()MediaRecorder.setPrivacySensitive()MediaRecorder.isPrivacySensitive()AAudioStreamBuilder_setPrivacySensitive()AAudioStream_isPrivacySensitive()
Cuando setPrivacySensitive() es true, el caso de uso de captura es privado y ni siquiera un asistente con privilegios puede realizar capturas simultáneas. Esta configuración anula el comportamiento predeterminado que depende de la fuente de audio. Por ejemplo, VOICE_COMMUNICATION es privado de forma predeterminada, no así UNPROCESSED.
Cambios de configuración
Cuando varias apps capturan audio de forma simultánea, solo una o dos están "activas" (reciben audio); las demás están silenciadas (reciben silencio). Cuando cambian las apps activas, el framework de audio puede volver a configurar las rutas de audio según estas reglas:
- Es posible que el dispositivo de entrada de audio de cada app activa cambie (por ejemplo, del micrófono integrado a unos auriculares Bluetooth conectados).
- El preprocesamiento asociado a la app activa de mayor prioridad está habilitado. Se ignora todo el procesamiento previo.
Dado que una app activa puede silenciarse cuando se activa una app de prioridad más alta, puedes registrar un AudioManager.AudioRecordingCallback en el objeto AudioRecord o MediaRecorder para recibir una notificación cuando cambie la configuración.
Los posibles cambios podrían ser los siguientes:
- Se silenció o dejó de silenciar la captura.
- Cambió el dispositivo.
- Cambió el preprocesamiento.
- Cambiaron las propiedades de transmisión (tasa de muestreo, máscara de canal y formato de muestreo).
Debes llamar a AudioRecord.registerAudioRecordingCallback() antes de que se inicie la captura.
La devolución de llamada se ejecuta solo cuando la app está recibiendo audio y se produce un cambio.
El método onRecordingConfigChanged() muestra un AudioRecordingConfiguration que contiene el estado actual de captura de audio. Usa los siguientes métodos para obtener información sobre el cambio:
isClientSilenced()- Devuelve un valor verdadero si se está silenciando el audio que se muestra al cliente debido a la política de captura.
getAudioDevice()- Devuelve el dispositivo de audio activo.
getEffects()- Devuelve el efecto de procesamiento previo activo. Ten en cuenta que el efecto activo puede no ser el mismo que devuelve
getClientEffects()si el cliente no es la app activa de mayor prioridad. getFormat()- Devuelve las propiedades de la transmisión. Ten en cuenta que los datos de audio reales que recibe el cliente siempre respetan el formato requerido que muestra
getClientFormat(). El framework realiza automáticamente la conversión de formato, canal y remuestreo necesarios del formato que se usa en la interfaz de hardware al formato que especifica el cliente. AudioRecord.getActiveRecordingConfiguration().- Devuelve la configuración de grabación activa.
Puedes obtener una vista general de todas las grabaciones activas en el dispositivo llamando a AudioManager.getActiveRecordingConfigurations().