Fixed
Status Update
Comments
ad...@google.com <ad...@google.com> #2
Thank you for reporting this issue. For us to further investigate this issue, please provide the following additional information:
Please provide code snippet or sample project or apk to reproduce the issue. Also mention the steps to be followed for reproducing the issue with the given sample project or apk.
NOTE : To avoid leaking private information, please share screenshots and bugreports only in Google Drive. Share files with android-bugreport@google.com and include only Google drive links in your bug. Bug report attachments should not be included directly in issue reports.
Please provide code snippet or sample project or apk to reproduce the issue. Also mention the steps to be followed for reproducing the issue with the given sample project or apk.
NOTE : To avoid leaking private information, please share screenshots and bugreports only in Google Drive. Share files with android-bugreport@google.com and include only Google drive links in your bug. Bug report attachments should not be included directly in issue reports.
ac...@gmail.com <ac...@gmail.com> #3
I uploaded and shared the apk of the app that exhibits the bug to: https://drive.google.com/file/d/1Jn5K92voSoaBAKfiQO0C6vd5Fs4iAQIP/view?usp=sharing
To reproduce the problem, after installing the app you will be prompted to enter your phone number.
Choose Netherlands as country, the country code +31 should be filled automatically with +31.
In the field labeled "Phone number" (assuming English language settings), fill in a phone number starting with 97 and 9 additional digits to trigger the number check before proceeding to the next step. This number check will fail because of the bug.
Note: I'm not a developer of that app, and I have reported the bug to them also.
As they have not yet responded I decided to look into the problem myself and have found out that way the aforementioned function (com.google.i18n.phonenumbers.PhoneNumberUtil.isPossibleNumber()) is bugged or not yet updated to deal with the newer phone numbers.
To reproduce the problem, after installing the app you will be prompted to enter your phone number.
Choose Netherlands as country, the country code +31 should be filled automatically with +31.
In the field labeled "Phone number" (assuming English language settings), fill in a phone number starting with 97 and 9 additional digits to trigger the number check before proceeding to the next step. This number check will fail because of the bug.
Note: I'm not a developer of that app, and I have reported the bug to them also.
As they have not yet responded I decided to look into the problem myself and have found out that way the aforementioned function (com.google.i18n.phonenumbers.PhoneNumberUtil.isPossibleNumber()) is bugged or not yet updated to deal with the newer phone numbers.
fo...@gmail.com <fo...@gmail.com> #4
Brilliant
ad...@google.com <ad...@google.com> #5
We have passed this to the development team and will update this issue with more information as it becomes available.
ad...@google.com <ad...@google.com> #6
97 seems to be M2M number which the library doesn't support. Also in Netherlands, mobile numbers are usually 9 digits in length and starts with prefix 6X.
If you still think it is a mobile number then please provide any working number to test the range or evidence stating it as Mobile.
If you still think it is a mobile number then please provide any working number to test the range or evidence stating it as Mobile.
ac...@gmail.com <ac...@gmail.com> #7
I only have my personal number (which I'm not willing to disclose on a public forum, for obvious reasons). On how these numbers should be treated, see this statement by the Dutch authority for Consumers and Markets.
As stated, M2M is just one of the possible applications, and 97 numbers need to be treated as any other number series.
https://www.acm.nl/en/publications/information-about-dutch-097-numbers-non-dutch-providers
As stated, M2M is just one of the possible applications, and 97 numbers need to be treated as any other number series.
pi...@gmail.com <pi...@gmail.com> #8
I found the same problem. I tracked Dutch regulatory rules on this subject.
According tohttps://www.rijksoverheid.nl/onderwerpen/telecommunicatie/vraag-en-antwoord/imsi-nummer-mobiele-telefoon-tablet-laptop (Dutch link)
the Autoriteit Consument & Markt (ACM) is responsible in the Netherlands for the IMSI numberplan. Their pages on this subject can be found here (Dutch links):
-https://www.acm.nl/nl/onderwerpen/telecommunicatie/telefoonnummers/telefoonnummers-gebruiken/06--en-097-nummers-voor-spraak-en-data
-https://www.acm.nl/sites/default/files/old_publication/publicaties/16001_097-en-06-nummers-informatie-voor-telecomaanbieders-20160701.pdf
It states that `+31 970 XXXX XXXX` numbers are 12 numbers long (e.g. `0970 XXXX XXXX ` and should be used for mobile data (M2M), which includes:
Machine to Machine (M2M), Machine to Human (M2H), Human to Machine (H2M), Human to Human (H2H).
Can you please allow these numbers within Android?
According to
the Autoriteit Consument & Markt (ACM) is responsible in the Netherlands for the IMSI numberplan. Their pages on this subject can be found here (Dutch links):
-
-
It states that `+31 970 XXXX XXXX` numbers are 12 numbers long (e.g. `0970 XXXX XXXX ` and should be used for mobile data (M2M), which includes:
Machine to Machine (M2M), Machine to Human (M2H), Human to Machine (H2M), Human to Human (H2H).
Can you please allow these numbers within Android?
pi...@gmail.com <pi...@gmail.com> #9
You can find the English text at page 2 of https://www.government.nl/binaries/government/documents/annual-reports/2016/02/16/decree-change-of-telephone-and-isdn-services-numbering-plan-for-m2m-applications/decree-change-of-telephone-and-isdn-services-numbering-plan-for-m2m-applications.pdf . See attached screenshot.
It states that 0970 can be 12 numbers long, so please at least allow +31 970 XXXX XXXX. If you want to be future proof please also allow +31 97[0-8] XXXX XXXX, but perhaps the 0971 to 0978 may use different maximum digits in future.
It states that 0970 can be 12 numbers long, so please at least allow +31 970 XXXX XXXX. If you want to be future proof please also allow +31 97[0-8] XXXX XXXX, but perhaps the 0971 to 0978 may use different maximum digits in future.
pi...@gmail.com <pi...@gmail.com> #10
I supplied the information needed to fix this is on Nov 10,2019. Is there any possibility to create a fix for this in Android?
Thanks in advance. If you need more information, please let me know and I see if I can provide it.
It would be nice if this issue will be resolved in a next Android update.
Thanks in advance. If you need more information, please let me know and I see if I can provide it.
It would be nice if this issue will be resolved in a next Android update.
4d...@gmail.com <4d...@gmail.com> #12
I would like to add that this bug does not only affect Dutch people.
In Ivory Coast million of phone number respect the following pattern ( +225 01 XX XX XX, +225 02 XX XX XX, +225 03 XX XX XX, +225 04 XX XX XX, +225 05 XX XX XX, +225 06 XX XX XX, +225 07 XX XX XX, +225 08 XX XX XX, +225 09 XX XX XX),
and they are all affected by the bug.
Thanks to take it into consideration,
In Ivory Coast million of phone number respect the following pattern ( +225 01 XX XX XX, +225 02 XX XX XX, +225 03 XX XX XX, +225 04 XX XX XX, +225 05 XX XX XX, +225 06 XX XX XX, +225 07 XX XX XX, +225 08 XX XX XX, +225 09 XX XX XX),
and they are all affected by the bug.
Thanks to take it into consideration,
pi...@gmail.com <pi...@gmail.com> #13
I drafted a PR for libphonenumber, see https://github.com/google/libphonenumber/pull/2499 . Can somebody tell me if that PR will fix this issue?
Or can somebody explain what files need to be changed in order to get this bug fixed?
Or can somebody explain what files need to be changed in order to get this bug fixed?
ja...@gmail.com <ja...@gmail.com> #14
" Sep 6, 2019 02:15PM
So more than a year later. Please fix the issue or give us another update.
ja...@gmail.com <ja...@gmail.com> #15
I checked to see that similar issues for other countries are fixed in 2019 within a month. So the issue here is that the Netherlands is low on the priority list.
lu...@gmail.com <lu...@gmail.com> #16
Would love this to be fixed! It seems odd to have such a hole in NL phone number validation, having to patch in your own hot-fix to make sure all phone numbers are actually supported.
ac...@gmail.com <ac...@gmail.com> #17
I would once again like to ask for attention on this issue. This potentially affects many apps, and could prevent users from applying safety measures such as 2FA when initial checks are made using this function.
iv...@radix-trading.com <iv...@radix-trading.com> #18
Still an issue, can't do 2FA for gmail because of this
Description
What happened: The check fails, presumably on number length.
What the correct behavior should be: on a Dutch number, starting with 97 followed by 9 digits should pass the check.
Extra information: data-only phone numbers have been removed from the old mobile number pool (+31 6 followed by 8 digits) to a separate number pool to provide adequate room in both pools for new numbers.
The problem occurs on Android 9, with a Google Pixel 2 XL, in but not limited to the app Signal 4.46.2