Con Android Auto, cada aviso de navegación baja el volumen de la música hasta cerca del 20%. Ocurre incluso tras desactivar "bajar el volumen multimedia durante la guía" tanto en el coche (MMI) como en la app de navegación. Este ducking lo causa el framework de Android del teléfono, no el coche. En un Samsung Galaxy, un único interruptor en Sound Assistant de Good Lock lo desactiva. Una conducción real el 2026-07-14 confirmó, mediante
dumpsys audio, que el ducking desapareció para esta combinación.
Este documento ayuda a cualquiera con el mismo síntoma a (1) confirmar la causa y (2) solucionarlo en un teléfono Samsung. A fecha de 2026-07, se verificó directamente con adb shell dumpsys audio en un Samsung Galaxy S25 Ultra (Android 16 / One UI 8.5) + Audi A5 (2026, B10) + Android Auto (USB).
Desde Android 8.0 (Oreo), cuando una app solicita el foco de audio con AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK, el propio framework baja el volumen de las demás apps. La atenuación es un valor fijo de -14 dB (aproximadamente 0,2 en escala lineal, es decir, el 20%). La app no ajusta el volumen: interviene el SO.
La app de navegación solicita este foco MAY_DUCK cada vez que reproduce un aviso, porque la guía de apps de navegación de Android Auto de Google exige USAGE_ASSISTANCE_NAVIGATION_GUIDANCE + MAY_DUCK para la reproducción de la guía. Así que la app de navegación cumple la especificación, y el precio es el auto-ducking forzado del framework.
El registro de eventos de adb shell dumpsys audio recoge esto exactamente.
La app de navegación solicita el foco en cada aviso (req=3 = GAIN_TRANSIENT_MAY_DUCK):
07-13 22:28:57:337 requestAudioFocus() from uid/pid 10399/10098
AA=USAGE_ASSISTANCE_NAVIGATION_GUIDANCE/CONTENT_TYPE_SPEECH
callingPack=com.nhn.android.nmap req=3 flags=0x0
El framework baja el reproductor de música de volumen 1.0 → 0.2 y lo restaura cuando el aviso termina:
07-13 22:28:57:338 ducking player piid:20199 (com.apple.android.music)
usage=USAGE_MEDIA ... VolumeShaper.Configuration{ mDurationMs=500.0, mVolumes[]=[1.0, 0.2] }
07-13 22:29:04:133 unducking piid:20199
Los eventos ducking/unducking coinciden 1:1 con el inicio y el fin de cada aviso de navegación.
Android Auto renderiza el audio en el teléfono y lo transmite al coche por USB. El contenido multimedia y la guía van por canales separados, y el coche los mezcla. En el registro anterior, la música ya está reducida al 20% dentro del teléfono, así que el coche recibe un audio que ya viene más bajo. Por eso tocar los ajustes del MMI no sirve de nada.
adb dumpsys audio muestra que el reproductor de música y el de la voz de navegación se renderizan en salidas virtuales distintas (deviceIds), y la ventana de actividad de la sesión de Android Auto (gearhead). El ducking se aplica a nivel del mezclador (AudioTrack), así que el PCM multimedia que sale hacia el coche ya está atenuado.
Ten en cuenta que algunos coches añaden su propia atenuación (doble ducking) cuando el canal de guía está activo. Pero en este caso, el ducking del lado del teléfono por sí solo explica todo el síntoma.
Apple Music no gestiona el ducking por sí misma (no declara willPauseWhenDucked), por lo que el framework le aplica auto-ducking. En cambio, apps como Spotify detectan la pérdida de foco y ajustan su propio volumen, de modo que no se aplica el auto-ducking del framework y el comportamiento puede diferir. Para aislar la causa, cambia de app de música y compara.
Los teléfonos Samsung con One UI 7 o posterior tienen un flag del framework (mIgnoreDuckingByNavigation) que ignora este ducking. Por defecto está en OFF. Solo se puede activar mediante el interruptor del módulo Sound Assistant en Good Lock: adb settings put no puede cambiarlo (no es una clave de la base de datos de ajustes, sino un ajuste interno de AudioService).
Cómo funciona: si la app que tomó el foco tiene usage USAGE_ASSISTANCE_NAVIGATION_GUIDANCE, se omite el ducking multimedia local. Eso coincide exactamente con este caso (usage de navegación = guía de navegación, música con ducking local).
Pasos:
adb shell dumpsys audio | grep -i ignoreducking
# mIgnoreDuckingByNavigation=true significa que está aplicado
Verifica el efecto (después de conducir):
adb shell dumpsys audio > dumpsys_audio_after.txt
grep -E 'ducking player|unducking' dumpsys_audio_after.txt
Si no aparece ningún evento ducking player ... com.apple.android.music alrededor del aviso, el ducking del lado del teléfono está resuelto.
Verificación medida (conducción real, 2026-07-14): tras conducir con el flag activado y volcar los datos, la app de navegación seguía solicitando el foco
req=3(MAY_DUCK) (15 veces durante la conducción) y Apple Music sonaba al mismo tiempo, y aun así hubo cero eventosducking player/unducking/VolumeShaper. Cambiar únicamente el flag a ON para la misma combinación hizo desaparecer por completo el ducking del lado del teléfono, y la música ya no bajaba durante los avisos.
El búfer circular de eventos de
dumpsys audiono se conserva mucho tiempo. Vuelca los datos justo después de conducir para que los eventos de ducking de la ventana del aviso sigan presentes.
Advertencia: hay informes de la comunidad de casos en los que este interruptor no funcionó en una sesión de Android Auto (depende de la combinación de coche y app). Aun así, cuando dumpsys confirma que el ducking ocurre en el framework del teléfono —como en este análisis—, es probable que el interruptor ayude, y la verificación medida anterior es uno de esos casos. Para una combinación distinta, verifícalo tú mismo con los pasos anteriores tras aplicarlo.
mIgnoreDuckingByNavigation es una función específica de One UI de Samsung. Android puro, otros fabricantes e iPhone (CarPlay) no tienen este interruptor. El propio Android Auto (gearhead) no tiene ningún ajuste para desactivar el ducking y, a fecha de 2026-07, no hay solución oficial de Google. En esos casos, cambiar a una app de música que gestione su propio ducking (como Spotify) es la solución alternativa realista.
No es un problema exclusivo de Audi. Se ha informado en muchas marcas (Ford, Mercedes-Benz, Chevrolet, etc.) y muchas apps de navegación (Naver Map, TMAP, etc.). Muchas pruebas de usuarios indican que "la reproducción solo con el teléfono / por Bluetooth va bien; el ducking ocurre solo por Android Auto", lo que coincide con el análisis anterior (la causa es el framework del teléfono). Se deriva de la arquitectura común de proyección de Android Auto.
Para otro caso de uso de adb para acotar un problema distinto de Android Auto, consulta Diagnóstico de desconexiones repetidas de Android Auto inalámbrico.