IssueTracker

Hi,

Thank you for taking the time to improve libphonenumber!

We are looking into this and will respond as soon as possible.

Hi,

Thanks much for raising this issue. This is one of our known issue, which is not documented. Having phone numbers of this long are very rare. libphonenumber cannot do anything better here.

Reasons:

• JavaScript Number type has limitation of 2^53 (9007199254740992) as the max literal it can hold. When provided more than that like "90018408059449376"(17 digit), JS starts rounding the value. Unfortunately this is within the range of possible phone number length i.e 17 digit.
• Both the alternatives leads to backward-incompatible changes as the type of the field '''national_number''' has to be changed; thus leading to client-side compile issue . Eg: setNationalNumber(1234) / conversions to payloads like JSON.

1. Marking the field as [jstype = JS_STRING]
2. Or using new JS data type BigInt.

We will update FAQ at GitHub stating some of these points. Maybe you can compare with Number.MAX_VALUE and avoid such cases. Or post request to a Java/CPP/PY libphonenumber clients, as these langs have much more matured data type systems.

Added to client FAQ as known issue. https://github.com/google/libphonenumber/pull/2674

Thank you for reporting this issue. We have shared this with our product and engineering team and will update this issue with more information as it becomes available.

Why don't you just update your app with proper button insets? iOS apps have been handling being drawn under system UI elements just fine for years by now. Seems regressive to push for an exception instead of just updating your app according to the latest UI guidelines. At worst, you can just put your app in immersive mode if you don't feel like updating your app's UI.

I work on multiple apps for humanitarian data collection that will also get no tangible benefit from edge-to-edge layout and we'll be using windowOptOutEdgeToEdgeEnforcement when moving to target API 35. As far as I can see (and please correct me if I'm wrong), this change is purely stylistic and offers no functional, privacy or security improvements to users of affected apps so the time spent accounting for it is hard to justify. That's especially true for small teams.

I'd ideally like to see edge-to-edge be returned to an opt-in feature rather than an opt-out one. Moving to total enforcement (the current plan) seems unjustified (to me) currently, but I'm interested to hear if there are good arguments for it.

This is preferable to the system fully handling these areas

It'd be great to get a better explanation on the thinking here. Why is it preferable? The system is actively drawing on these areas - the app has no control of the content and is simply now able to render under the system/bottom bar using edge to edge. For a lot of apps, this doesn't add any advantages, but does add complexity.

I would like to add to this--our app has a small user base with niche demands, and is still using XML, but newer screens are in Compose, but majority is still XML. It would be expensive to move to edge-to-edge as we have lots of screens and it would require us to completely abandon current development efforts just to satisfy this edge-to-edge requirement.

We'd appreciate if the documentation could spell out how to satisfy edge-to-edge for apps that are a mix of XML and Compose, but reading https://developer.android.com/develop/ui/views/layout/edge-to-edge, it's thin on details and is biased to Compose-only apps.