Feature Request to add E.123 as a valid PhoneNumberFormat [221095104]

WAI

Bug

Status Update

No update yet.

Description

oo...@gmail.com

created issue #1

Feb 24, 2022 05:27AM

In phonenumberutil.h it is stated:

  // INTERNATIONAL and NATIONAL formats are consistent with the definition
  // in ITU-T Recommendation E.123. However we follow local conventions such as
  // using '-' instead of whitespace as separators. For example, the number of
  // the Google Switzerland office will be written as "+41 44 668 1800" in
  // INTERNATIONAL format, and as "044 668 1800" in NATIONAL format. E164
  // format is as per INTERNATIONAL format but with no formatting applied e.g.
  // "+41446681800". RFC3966 is as per INTERNATIONAL format, but with all spaces
  // and other separating symbols replaced with a hyphen, and with any phone
  // number extension appended with ";ext=". It also will have a prefix of
  // "tel:" added, e.g. "tel:+41-44-668-1800".

PR 2021 sought to clarify that.

For businesses that use telephony apps that span borders, displaying a list of Phone Numbers using the International and National formats in libphonenumber is inconsistent.

Actual

+1 212-500-4000
+41 44 668 1800

EXPECTED

+1 212 500 4000
+41 44 668 1800

I'd like to request a new PhoneNumberFormat of E123 that EXACTLY follows the ITU-T Recommendation E.123 formatting using only spaces.

Alternatively, add an option to allow one to disable the "local conventions" such that an INTERNATIONAL formatted number follows E.123 Recommendations.

There is value in providing local conventions, however, there is also value in providing access to standards for consistency.

Use cases:

Apps that provide Lists of Phone Numbers mixed between NANPA and non-NANPA countries (there are more of the latter than the former)
Contact Cards for Business Travellers who have multiple numbers
Anywhere consistency is a good and consistent User Interface

Comments

pe...@google.com <pe...@google.com> #2Mar 2, 2022 07:41AM

Status: Won't Fix (Intended Behavior)

Android Studio 3.4.0

Message last modified on Mar 2, 2022 07:42AM

oo...@gmail.com <oo...@gmail.com> #3Mar 2, 2022 08:38AM

The field-minification is actually quite difficult to get exactly right and was recently changed. Simply, for fields on super-types, we might not be able to assign non-unique names and thus we run out of "names" from the obfuscationdictionary faster.

Could you check that some of your base-classes (classes not extending other classes except java.lang.Object) field names are actually minified?

I recently changed how indexes was assigned in a newer version and you might find more of your names are minified. Would you mind trying that version out to see if it matches closer to your expectation?

buildscript {

repositories {
maven {
url "

http://storage.googleapis.com/r8-releases/raw/master"
}
}

dependencies {
classpath 'com.android.tools:r8:44b0356b65ab24779a8051c8f4dd50b0186437a8' // Must be before the Gradle Plugin for Android.
classpath 'com.android.tools.build:gradle:X.Y.Z' // Your current AGP version.
}
}

You might also be able to use -overloadaggressively if not doing that already, although that can lead to verification errors.

pe...@google.com <pe...@google.com> #4Mar 2, 2022 08:59AM

Thanks for quick response.
It should be fixed in 44b0356b65ab24779a8051c8f4dd50b0186437a8.

r8 1.5.21-dev (44b0356b65ab24779a8051c8f4dd50b0186437a8) seems ok:
java.math.BigInteger d -> do
int auth -> µΗ
byte[] EMP -> µH
byte[] k -> µμ
java.math.BigInteger m -> if

r8 1.4.77:
byte[] EMP -> a
java.math.BigInteger d -> b
java.math.BigInteger m -> c
int auth -> e
byte[] k -> d

proguard:
byte[] EMP -> do
java.math.BigInteger d -> if
java.math.BigInteger m -> µμ
byte[] k -> µΗ
int auth -> µH

(don't worry about µΗ and µH in my example, it's not the same character.)

oo...@gmail.com <oo...@gmail.com> #5Mar 2, 2022 07:43PM

However, r8 1.5.21-dev (44b0356b65ab24779a8051c8f4dd50b0186437a8) crash my app.

If you want me to baksmali and check the reason, please let me know.

Message last modified on Mar 2, 2022 07:45PM

oo...@gmail.com <oo...@gmail.com> #6Oct 5, 2022 09:08PM

From the output, I found the issues.

r8 1.5.21-dev (44b0356b65ab24779a8051c8f4dd50b0186437a8):
io.fabric.sdk.android.services.concurrency.AsyncTask -> CoN.coN.coN.coN.coN.CoN.coN:
io.fabric.sdk.android.services.concurrency.AsyncTask$1 -> io.fabric.sdk.android.services.concurrency.AsyncTask$1:

r8 1.4.77:
io.fabric.sdk.android.services.concurrency.AsyncTask -> CoN.coN.coN.coN.coN.CoN.AUx:
io.fabric.sdk.android.services.concurrency.AsyncTask$1 -> CoN.coN.coN.coN.coN.CoN.coN:

io.fabric.sdk.android.services.concurrency.AsyncTask -> CoN.coN.coN.coN.coN.CoN.coN:
io.fabric.sdk.android.services.concurrency.AsyncTask$1 -> io.fabric.sdk.android.services.concurrency.AsyncTask$1:
io.fabric.sdk.android.services.concurrency.AsyncTask$2 -> io.fabric.sdk.android.services.concurrency.AsyncTask$2:
io.fabric.sdk.android.services.concurrency.AsyncTask$3 -> io.fabric.sdk.android.services.concurrency.AsyncTask$3:
io.fabric.sdk.android.services.concurrency.AsyncTask$4 -> io.fabric.sdk.android.services.concurrency.AsyncTask$4:
io.fabric.sdk.android.services.concurrency.AsyncTask$AsyncTaskResult -> CoN.coN.coN.coN.coN.CoN.coN$coN:
io.fabric.sdk.android.services.concurrency.AsyncTask$InternalHandler -> CoN.coN.coN.coN.coN.CoN.coN$cON:
io.fabric.sdk.android.services.concurrency.AsyncTask$SerialExecutor -> CoN.coN.coN.coN.coN.CoN.coN$CoN:
io.fabric.sdk.android.services.concurrency.AsyncTask$SerialExecutor$1 -> io.fabric.sdk.android.services.concurrency.AsyncTask$SerialExecutor$1:
io.fabric.sdk.android.services.concurrency.AsyncTask$Status -> CoN.coN.coN.coN.coN.CoN.coN$CON:
io.fabric.sdk.android.services.concurrency.AsyncTask$WorkerRunnable -> CoN.coN.coN.coN.coN.CoN.coN$AUx:

It seems r8 1.5.21-dev (44b0356b65ab24779a8051c8f4dd50b0186437a8) don't shrink for class$[1-9]*.
Which change access policy, then throws IllegalAccessError.

Issue 221095104