Make call composer APIs use e164 number
http://cl/166294495 fixes the issue where requestCapabilities tries to
get capabilities for a national number. All of the other number based
APIs need to have this functionality too, otherwise they'll fail for
the same reason.
This CL fixes the issue by being a bit tricky. Since requestCapabilities
only requests for numbers which are e164 formatted, the RCS stack will
send the number back as e164 formatted and. We save that formatted
version of the number with the capabilities so it can be used by the
other APIs. This is needed because libphonenumber's parse method must
be called on the background thread. StartCallComposerSession isn't
called on a background thread, and so can't format the given number
itself.
Note that this change specifically targets the numbers which are passed
to the enriched call service.
Bug: 63564400
Test: Various tap targets
PiperOrigin-RevId: 166911300
Change-Id: I28b975bf14a10ac15348a86ae8dde4eb02ea2ea8
diff --git a/java/com/android/dialer/location/CountryDetector.java b/java/com/android/dialer/location/CountryDetector.java
index c4bed14..110cf45 100644
--- a/java/com/android/dialer/location/CountryDetector.java
+++ b/java/com/android/dialer/location/CountryDetector.java
@@ -72,7 +72,7 @@
// exceedingly rare event that the device does not have a default locale set for some reason.
private static final String DEFAULT_COUNTRY_ISO = "US";
- @VisibleForTesting static CountryDetector sInstance;
+ @VisibleForTesting public static CountryDetector sInstance;
private final TelephonyManager telephonyManager;
private final LocaleProvider localeProvider;
@@ -80,7 +80,7 @@
private final Context appContext;
@VisibleForTesting
- CountryDetector(
+ public CountryDetector(
Context appContext,
TelephonyManager telephonyManager,
LocationManager locationManager,
@@ -192,7 +192,7 @@
}
/** Interface for accessing the current locale. */
- interface LocaleProvider {
+ public interface LocaleProvider {
Locale getLocale();
}