Protección de audio en segundo plano

A partir de Android 17, el framework de audio aplica restricciones en las interacciones de audio en segundo plano, como la reproducción de audio, las solicitudes de enfoque de audio y las APIs de cambio de volumen para garantizar que el usuario inicie estos cambios de forma intencional.

Si un desarrollador de apps pretende controlar el audio sin una actividad visible, debe asegurarse de que la app tenga un servicio en primer plano (que no sea del tipo SHORT_SERVICE) que se haya iniciado con capacidades de mientras se usa (WIU). Se otorgan capacidades de WIU a un servicio en primer plano si se inicia en respuesta a un MediaSessionEvent o mientras la app está visible para el usuario.

Si la app intenta llamar a las APIs de audio mientras no se encuentra en un ciclo de vida válido, las APIs de reproducción de audio y de cambio de volumen fallarán de forma silenciosa sin arrojar una excepción ni proporcionar un mensaje de error. La API de enfoque de audio falla con el código de resultado AUDIOFOCUS_REQUEST_FAILED.

El objetivo de introducir estas restricciones es reducir las experiencias con errores de audio en segundo plano no intencionales. Aquí encontrarás algunos ejemplos:

• Se pueden congelar las apps que reproducen audio sin un servicio en primer plano. Cuando la app finalmente se reactiva, reanuda la reproducción de audio de forma inesperada, posiblemente horas después.
• Las apps que reproducen audio sin un servicio en primer plano enfrentan diversas restricciones de ejecución que generan un rendimiento de audio entrecortado.
• La reproducción se separa del ciclo de vida de la actividad, lo que podría generar una sesión de reproducción filtrada o eventos de enfoque filtrados que continúan sin que el usuario pueda detener la reproducción.

Recomendamos a los desarrolladores que prueben sus apps y proporcionen comentarios sobre el cambio de comportamiento si hay casos de uso de audio intencionales que se vean afectados de forma negativa. Informa cualquier problema con este seguimiento de problemas de compatibilidad de apps con Android 17.

Identifica los casos de uso de audio en segundo plano afectados

Audita la implementación de la reproducción de audio y determina si tu app pretende proporcionar funcionalidad de interacción de audio en segundo plano incluso en circunstancias condicionales.

Si tu app solo pretende reproducir audio o utilizar APIs de audio mientras muestra una actividad visible para el usuario, incluido el uso del modo de pantalla en pantalla (PIP), no se verá afectada por ninguno de estos cambios.

Si tu app proporciona funcionalidad de VoIP, incluidas las apps de videollamadas, ya debe cumplir con los requisitos que se introducen para la reproducción (por lo general, a través del uso de las APIs de telecomunicaciones recomendadas) para grabar audio correctamente, por lo que es poco probable que se vea afectada.

Si tu app pretende continuar con la reproducción de audio mientras la pantalla está apagada o mientras el usuario descartó por completo tu actividad (lo que se ve con mayor frecuencia en las apps de transmisión de música o de podcasts), se considera que tu app proporciona funcionalidad de audio en segundo plano y debe cumplir con los nuevos requisitos.

Situaciones de audio en segundo plano que probablemente se vean afectadas

Si tu app no sigue el modelo de continuar una interacción de audio iniciada mientras la app estaba abierta o en respuesta a un activador explícito del usuario, es probable que la funcionalidad de la app se suprima de forma silenciosa.

Por ejemplo, si tu app inicia un servicio en primer plano en respuesta a BOOT_COMPLETE y trata de interactuar con el audio, se suprimirá.

Prácticas recomendadas para el audio de fondo y mitigar su impacto

• Usa el componente MediaSessionService de la biblioteca media3 de Jetpack para administrar la reproducción de audio en segundo plano.

  Si lo haces, es probable que tu app no se vea afectada por el refuerzo en segundo plano, ya que la biblioteca ayuda a administrar el ciclo de vida de la reproducción.

• Si no aprovechas la biblioteca de Media3, deberás iniciar manualmente un FGS de mediaPlayback. Siempre inicia un servicio en primer plano mientras la app está en primer plano si es posible que se reproduzca audio en segundo plano.

  Por ejemplo, si tu app es de transmisión de video, que suele ser solo en primer plano, pero contiene una opción para que el usuario siga reproduciendo contenido mientras la pantalla está apagada, cuando se active el disparador de reproducción iniciado por el usuario, tu app deberá iniciar un servicio en primer plano.

  Esto garantiza que el servicio en primer plano se inicie con capacidades de WIU.

• Mantén el FGS de mediaPlayback activo durante las fallas transitorias de menos de 10 minutos.

  Si tu app tiene una falla transitoria, como un problema con el almacenamiento en búfer debido a la actividad de la red, o si hay una interrupción transitoria esperada, como AUDIOFOCUS_LOSS_TRANSIENT, se debe continuar con la intención de reproducción. Por lo tanto, tu FGS debe permanecer activo.

• Detén el servicio en primer plano al final de la reproducción y reiníciala solo si el usuario la reanuda de forma explícita.

  En el caso de un indicador permanente para finalizar la reproducción (por ejemplo, el contenido se completó sin reproducción automática, un AUDIOFOCUS_LOSS, un evento de pausa del UMO o un evento de tecla de medios) o una falla irrecuperable, tu app debe detener la interacción de audio, detener el servicio en primer plano y finalizar la sesión de medios. Todo esto corresponde a la concepción del usuario de "finalizar" la interacción de audio en segundo plano deseada. Después de hacer esto, tu app ya no tendrá capacidades de interacción de audio en segundo plano.

  Posteriormente, si el usuario reanuda la reproducción de forma explícita, por ejemplo, a través de la IU de tu app o el botón de reproducción del objeto multimedia universal, debería volver la intención de iniciar la reproducción de audio, lo que generaría un nuevo servicio en primer plano iniciado.

• Prueba el comportamiento de reproducción de audio con comandos de adb shell.

Prueba de cambios en Android 16 y Android 17

La función ya se implementó en el nivel "advertencia" a partir de Android 16. Esto significa que las apps pueden usar adb shell cmd audio set-enable-hardening para probar manualmente la aplicación de la protección de audio en segundo plano.

Para habilitar la aplicación forzosa en dispositivos con Android 16, ejecuta el siguiente comando:

adb shell cmd audio set-enable-hardening 1

Para inhabilitar la aplicación en dispositivos con Android 17, ejecuta el siguiente comando:

adb shell cmd audio set-enable-hardening 0

También recomendamos usar logcat o el comando adb adb dumpsys audio para identificar si la app tuvo fallas silenciosas debido a la aplicación de la protección de audio. Si es así, el registro tendrá una entrada con el prefijo AudioHardening y el nombre de tu paquete.

Información sobre la FGS con capacidad de uso mientras se conduce

En general, los servicios en primer plano (FGS) deben iniciarse mientras una app está en primer plano para extender las operaciones iniciadas por el usuario. En algunos casos específicos, se permite que las apps inicien un servicio en primer plano mientras se ejecutan en segundo plano. Sin embargo, por lo general, estos servicios en primer plano no tienen capacidades de While-In-Use (WIU).

WIU actúa como una puerta de seguridad: evita que los FGS iniciados en segundo plano realicen ciertos comportamientos sensibles cuando el usuario podría no ser consciente de la actividad de la app. Evita que la app acceda a datos sensibles, como la ubicación, la cámara o el micrófono. Además, a partir de Android 17, también bloquea las APIs de audio que suelen requerir un contexto de IU visible.

Aquí tienes una referencia útil:

• Servicios en primer plano estándar: Los servicios que se inician mientras la app está visible o tienen capacidad de inicio de actividad en segundo plano otorgada tienen acceso a WIU.
• Servicio en primer plano iniciado en segundo plano (BFSL): La mayoría no otorgan acceso a WIU. Las excepciones principales que otorgan WIU son las interacciones que implican la intención explícita del usuario, por ejemplo, los clics en notificaciones, las interacciones con widgets o los eventos de teclas multimedia de un dispositivo externo.
• El sistema inició FGS: Los FGS que se iniciaron con la delegación del servidor del sistema (por ejemplo, con la biblioteca de Jetpack de Telecom) tienen acceso a WIU.

Obtén más información en Restricciones para iniciar un servicio en primer plano desde el segundo plano.

Lista completa de las APIs de Audio afectadas