Android Autoを使うと、ナビ音声が流れるたびに音楽の音量が約20%まで下がる。車（MMI）とナビアプリの両方で「案内中にメディア音量を下げる」をオフにしても発生する。このダッキングは車ではなくスマホのAndroidフレームワークが引き起こす。Samsung GalaxyならGood LockのSound Assistantのトグル一つでオフにできる。2026-07-14の実走行で、
dumpsys audioの実測によりこの組み合わせでダッキングが消えたことを確認した。
この文書は、同じ症状の人が (1) 原因を確認し (2) Samsung端末で解決する方法をまとめる。2026-07時点で、Samsung Galaxy S25 Ultra（Android 16 / One UI 8.5）＋ Audi A5（2026, B10）＋ Android Auto（USB）の組み合わせで adb shell dumpsys audio により直接確認した結果。
Android 8.0（Oreo）以降、アプリが AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK タイプでオーディオフォーカスを要求すると、フレームワークが他アプリの音を直接下げる。 減衰量は固定の-14dB（線形スケールで約0.2、つまり20%）。アプリが音量を調整するのではなく、OSが介入する。
ナビアプリは案内音声を鳴らすたびにこの MAY_DUCK フォーカスを要求する。GoogleのAndroid Autoナビアプリガイドが、案内音声の再生時に USAGE_ASSISTANCE_NAVIGATION_GUIDANCE + MAY_DUCK の要求を求めているためだ。つまりナビアプリは仕様を守っており、その代償としてフレームワークの自動ダッキングが強制される。
adb shell dumpsys audio のイベントログにこの過程がそのまま残る。
ナビアプリが案内音声ごとにフォーカスを要求する（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
フレームワークが音楽プレーヤーを音量 1.0 → 0.2 にダッキングし、案内が終わると復帰させる:
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
ducking/unducking イベントが案内音声の開始・終了と1:1で正確に同期する。
Android AutoはスマホがオーディオをレンダリングしてUSBで車にストリーミングする構造だ。メディアと案内音声を別チャンネルで送り、車がミキシングする。上記ログでは音楽がスマホ内ですでに20%まで下がっているので、車はすでに小さくなった音を受け取る。 MMIの設定をいくらいじっても無駄な理由だ。
adb dumpsys audio では、音楽プレーヤーとナビ音声プレーヤーが異なる仮想出力（deviceId）でレンダリングされること、そしてAndroid Autoセッション（gearhead）の活動区間が確認できる。ダッキングはミキサー（AudioTrack）レベルで適用されるため、車へ出ていくメディアPCM自体がすでに減衰した状態だ。
なお、一部の車は案内音声チャンネルがアクティブなときに追加の減衰（二重ダッキング）をかけることもある。しかし今回のケースはスマホ側のダッキングだけで症状がすべて説明できる。
Apple Musicはダッキングを自前で処理しない（willPauseWhenDucked を申告しない）。そのためフレームワークが代わりに自動ダッキングする。一方Spotifyのようにアプリがフォーカス喪失を自ら検知して音量を調整するアプリは、フレームワークの自動ダッキングが適用されず挙動が異なることがある。原因を切り分けたいなら音楽アプリを変えて比較する。
One UI 7以降のSamsung端末には、このダッキングを無視するフラグ（mIgnoreDuckingByNavigation）がフレームワークにある。デフォルトはOFF。Good LockのSound Assistantモジュールのトグルでのみオンにでき、adb settings put では変更できない（settings DBのキーではなくAudioService内部の設定）。
動作原理: フォーカスを取得したアプリのusageが USAGE_ASSISTANCE_NAVIGATION_GUIDANCE であれば、ローカルのメディアダッキングを省略する。今回のケース（ナビのusage = ナビゲーション案内、音楽がローカルでダッキングされる）と正確に一致する。
手順:
adb shell dumpsys audio | grep -i ignoreducking
# mIgnoreDuckingByNavigation=true が表示されれば反映済み
効果の検証（走行後）:
adb shell dumpsys audio > dumpsys_audio_after.txt
grep -E 'ducking player|unducking' dumpsys_audio_after.txt
案内音声の時点で ducking player ... com.apple.android.music イベントが表示されなければ、スマホ側のダッキングが解消されている。
実測検証（2026-07-14 実走行）: フラグをオンにして走行した後にダンプした結果、ナビアプリは依然として
req=3（MAY_DUCK）フォーカスを要求し（走行区間で15回）、Apple Musicも同時に再生中だったが、ducking player/unducking/VolumeShaperイベントは0回だった。同じ組み合わせでフラグだけをオンにすると、スマホ側のダッキングが完全に消え、体感でも案内時に音楽が下がらなくなった。
dumpsys audioのイベントリングバッファは長く保持されない。案内音声の時点のダッキングイベントを残すために、走行直後にダンプすること。
注意: コミュニティの報告には、このトグルがAndroid Autoセッションでは効かなかったという事例もある（車種・アプリの組み合わせ次第）。ただし今回の分析のようにダッキングがスマホのフレームワークで発生していることが dumpsys で確認された組み合わせなら、効果が出る可能性が高い ― 上記の実測検証がその例だ。別の組み合わせなら、適用後に上記の手順で自分で検証することを勧める。
mIgnoreDuckingByNavigation はSamsung One UI固有の機能だ。素のAndroidや他メーカー、iPhone（CarPlay）にはこのトグルがない。Android Auto（gearhead）自体にもダッキングを切る設定はなく、2026-07時点でGoogle公式の解決策もない。この場合、音楽アプリを自前でダッキング処理するアプリ（Spotifyなど）に変える回避策が現実的な選択肢だ。
これはAudi固有の問題ではない。Ford、メルセデス・ベンツ、シボレーなど多くのブランドで、Naver Map・TMAPなど多くのナビアプリで同様に報告されている。「スマホ単体/Bluetooth再生は正常だが、Android Auto接続時のみダッキングする」というユーザーテストが多数あり、上記の分析（スマホのフレームワークが原因）と一致する。Android Autoプロジェクションという共通構造に由来する問題だ。
同じように adb を使ってAndroid Autoの別の問題を絞り込んだ事例は、ワイヤレスAndroid Autoの繰り返し切断の診断を参照。