Resolve baseline call audio routing
This CL resolves the baseline audio routing in the refactored path.
There were recent changes to resolve the map referencing done when
computing the previced device strategy which was causing audio to stay
on speakerphone even when it was toggled off in Dialer. Instead, we
should just ignore using the preferred device strategy when we're
calculating the baseline route.
Bug: 366059141
Test: Manual to verify speaker can be toggled on/off
Test: Manual verification on WhatsApp
Flag:
com.android.server.telecom.flags.use_refactored_audio_route_switching
Change-Id: I9e4adf249bc745a92e42c4f8ae3f33cdd3305be1
diff --git a/src/com/android/server/telecom/CallAudioRouteController.java b/src/com/android/server/telecom/CallAudioRouteController.java
index efd00f2..6f205c2 100644
--- a/src/com/android/server/telecom/CallAudioRouteController.java
+++ b/src/com/android/server/telecom/CallAudioRouteController.java
@@ -911,7 +911,7 @@
}
private void handleSwitchBaselineRoute(boolean includeBluetooth, String btAddressToExclude) {
- routeTo(mIsActive, getBaseRoute(includeBluetooth, btAddressToExclude));
+ routeTo(mIsActive, calculateBaselineRoute(includeBluetooth, btAddressToExclude));
}
private void handleSpeakerOn() {
@@ -1225,6 +1225,16 @@
return destRoute;
}
+ private AudioRoute calculateBaselineRoute(boolean includeBluetooth, String btAddressToExclude) {
+ AudioRoute destRoute = getPreferredAudioRouteFromDefault(
+ includeBluetooth, btAddressToExclude);
+ if (destRoute != null && !getCallSupportedRoutes().contains(destRoute)) {
+ destRoute = null;
+ }
+ Log.i(this, "getBaseRoute - audio routing to %s", destRoute);
+ return destRoute;
+ }
+
/**
* Don't add additional AudioRoute when a hearing aid pair is detected. The devices have
* separate addresses, so we need to perform explicit handling to ensure we don't