IssueTracker

From the method's comment, it is only validating against the number length. So what is missing here is to check:

1. If the number is a valid short number - like the equivalent of US 911: 112 or 110 ... in Germany there ist also 115 and 5 digit numbers starting with 118 (118xx) and 6 digit numbers starting with 116 valid short numbers (116xxx)
2. If the used Region is hasNationalPrefix()
3. If the given number has not used a CountryCode nor a TruncCode

Step 2 & 3 can be done with the currently given set of information and methods of the library (I can provide Java example code for a fix). The First step needs more / accurate information (maybe I am just not aware, that it is already present in some files / configuration) - so I made a separate addition in Java for this kind of check, but I just configured the data for Region DE)

Thanks for the detailed postings. I will try to answer every aspect you mentioned, but not in a lengthy post but rather in dedicated answers (with some time in between, because I will search collect references material, so please do not be disappointed if it will take some time between my answers).

So starting with the short number topic. Your example of 116123 is misleading. Your referenced document stated this would be a legal number and indeed this number has been assigned by the German postal office: https://www.bundesnetzagentur.de/DE/Sachgebiete/Telekommunikation/Unternehmen_Institutionen/Nummerierung/Rufnummern/116xyz/116123_Basepage.html

We need to distinguish between those area independent short numbers and the number length within an area. Since decades this length has been standardised, but shorter numbers which have been assigned before are still valid until the customer gives that number back. So even if the number plan states a specific min-length this regulates new number assignment only and shorter are still valid and assigned. Those length can’t directly be checked directly but indirect by looking for the trunk code (but that will be the next post)

NP. We understand :)

@116xxx example, 116XXX are well known short codes in EU regions (https://en.wikipedia.org/wiki/Short_code#European_Union). So we support specific numbers like 116111 and 116123 only as valid short codes. And all 6 digit ones as possible short numbers.

As short numbers and fixed-line number lengths are overlapping in nature (in cases like this), we have separate utils for them; please structure your client code as mentioned earlier. As Lara suggested in the email, you may use findNumbers() API to whitelist numbers at respective liniency level you want. Based your case where you wnat to check trunk prefix, we recommend PhoneNumberUtil.Leniency.VALID. I am not sure it is clear earlier.

Thanks for your answer - I am sorry if I didn't get your point in the first run. Understanding the German Number Plan (as a German native speaker) is not quite easy. To talk about it in English as a second language does not make it easier.

I will check your suggestion against my test data set and see if it would solve the problem. Please allow me some time for a response - since I do that in my (as always too short) free time.

Neither my first language is English. :) Sure, we can somehow manage. I understand about the delay in responses. Please ping back at the earliest so the context is not lost. Thanks!

Legal all settings services numbers names opened Legal platforms my

Hi, it was just the first weekend with some free time to care about this issue again. So here are my further findings:

The current discussion was mainly about the first checkpoint - if it is a German short number in the fix line network.

With our explanation I investigated the behavior and checked it with the current configured meta data against the formal definition of the German Number Plan:

I) The 116xxx subpart has been officially defined as xxx = 000 ... 999 - see top of page 2.

While the meta data just configured the currently assigned numbers

So the first question is, should shortNumberInfo.isValidShortNumber only be true for already assigned numbers or any defined number (like other checks do, because beside just so short list it is not really possible).

So as example 116555 is defined as a sort number (isPossibleShortNumber==true) but not assigned (isValidShortNumber==false)

II) The 118(0)xx subpart is not supported by the MetaData yet!

Here the list of already assigned numbers is much longer and in contrast to the 116 which needs to be aligned on EU level the 118 needs just to regulated in DE, so there might be more "movement" in this assignment.

Here the meta data leads to isPossibleShortNumber==false which is wrong!

Now that I think I know how to configure this, should I make an independent Merge Request out of it?

The second and third point of my initial list can be combined and can be explained best by the requested example:

I extract the call history of German fixline routers, so those entries included strings of phone numbers how they have been used. In German fix line you can call a phone number in the same area just by the number or (like a number of any other area) with the trunc - code + area code + number; or even bei + country code (no trunc code) + area code + number.

To find those numbers in a contact list of a smart phone, I try to normalize those numbers. Sometimes I also have the area code, where the device is operating, so I could generate the full version.

I suppose the main problem is a misunderstanding. When I read in a previous response „So when it comes to 556677, 55X are valid area codes followed by 3 digit subscriber numbers. This is the reason why 556677 is considered as IS_POSSIBLE than IS_POSSIBLE_LOCAL_ONLY. 556677 is a potential full length number - i.e with area ccde.“ This ambiguity seems to be only true for the data model of the library. In the telephone network, it is unambiguously 556677 is a phone 6 digit number without an area code while 0556677 is a phone number with an invalid area code (only 05565 exists … but lets assume 55 would be an area code ;-) ) - but back from this bad area code example, the leading 0 is the trunc code. The problem is, that the library does not make it easy to handle this.

First of all both numbers have the same National Format representation (0556677) 556677 and 0556677

To make my calculation valid for any kind of number plan with a trunc code, I do not calculate with a static 0, but get the trunc code from the MetaData region. This is not directly supported, because the necessary method is not pubic, so I created a pull request - since I have been ask to try it differently. This is why I came across the method in this issue.

Another approach would be to have a method on the phone number like isTruncCodeUsed to get the information if a trunc code and therefore also an area code is used at the beginning of the number. In correlation to this isCountryExitCodeUsed would make sense (similar to country_code_source == FROM_NUMBER_WITH_IDD or FROM_NUMBER_WITH_PLUS_SIGN or FROM_NUMBER_WITHOUT_PLUS_SIGN), because an exit code would imply a country code plus area code (but not necessary a trunc code - like it is in Germany).

For my use case without access to the trunc code meta data a setAreaCode would be necessary, wich sets a trunc code + that area code infront of a number, or replacing an existing area code within a number.

That are my ideas to solve the need, without changing the issued method. What would be the best approach to proceed?

Thanks.

Just did the MRs as proposed in the previous comment:

• 116xxx -> (rejected to Issue)
• 118xx and 1180xx -> (rejected to Issue)

And in addition I found some mistakes at the German geocoding table for DE area codes, which I also corrected -> (rejected to Issue).

Hi,

As mentioned in our contribution policy, we are not accepting PRs for metadata updates. Thanks much for the changes, and helping us to improve the metadata. We will make the respective changes in upcoming releases.

1. We will be not able to support all the 116 XXX numbers as valid short codes as we add support to specific ones, unlike phone number ranges. As you mentioned if 116555 is valid one, we can add support to only that one.
2. Thanks for geocoding updates. One thing: "/" is our usual syntax for "or" / "alternatives" / "at". As these geocoding details are from official plan, we will investigate changes individually and do the needful.

Thanks again for all the improvements suggested. :)

Hi,

I am sorry that I missed the contribution policy part to Meta Data, I just have been in the flow to give back things I improved locally. So here are some notes to your last comment:

• 116xxx it is absolutely reasonable to stick to the (very) short list of assigned numbers. Since those numbers need to be aligned through the whole EU, Germany can't assign new numbers on their own and that makes it unlikely, that the list will grow much. Therefore please do not add 116555, which is not an assigned number. I will make a cross check about 116xxx configuration for all other EU countries so, that the Meta Data would be consistent.
• 118xx / 1180xx it would really be great if you could add this missing part to the short number configuration (I could remove a lot of custom code then ;-) )
• Geocoding, as I explained in my comment of the other issue, some cities names are detailed by further geo information like near by river. So this "/" is not a logical or but just a seperator as example Stolpe is the city name, while Oder is a nearby river. So "Stolpe/Oder" would be in a human sentence "Stolpe an der Oder". For some Cities this river extension is even part of the official like the Frankfurt am Main while on the counter part Frankfurt an der Oder it is just an informal extension.

If I can help you with your investigation, please let me know (sine I already did this for my own list ;-) )

As promised, I made a cross check of the meta Data of the EU countries with the configuration of 116xxx (EU harmonized social hotlines) ... it was a little bit surprising how many configurations I found. Obviously not all Hotlines are operating in every country, but on the other side the style of coding is quite different. And that valid check is mostly stricter than toll free check, where the other way round only once was made (which is more logical: valid is the definition, so it does need to be strict to the assigned, while toll free should be strict to the real tool free. So if there is a new number, it would rather be good to explicitly configure it to toll free, than to valid. Right now it would not be valid but toll free !!!).

x0 (valid check):

116 - 000..999

x1 (assigned check):

116 - 000
116 - 1 - 06|11|23 

x2 (assigned check):

116 - 00 - 0|6
116 - 1 - 17|23

x3 (assigned check):

116 - 000
116 - 117

x4 (assigned check):

116 - 000|111

x5 (assigned check):

116 - 00 - 0|6
116 - 1 - 11|23

x6 (assigned check):

116 - 00 - 0|6
116 - 11 - 1|6|7
116 - 123

x7 (assigned check):

116 - 00 - 0|6
116 - 111

x8 (assigned check):

11611 - 1|7

x9 (assigned check):

116 - 000
116 - 11 - 1|7
116 - 123

x10 (valid check):

116- 0|1 - 00..99

x11 (assigned check):

116 - 00 - 0|6
116 - 11 - 1|7
116 - 123

x12 (assigned check):

116 - 000
116 - 1 - 11|23

x13 (valid check):

116 - 0 - 00..99
116 - 111
116 - 12 - 0..9

And they are used for SN(short number) / TF (toll free) in those countries (country code in breakers it's a EU candidate others are already members). A letter in brackets mean, that the result of the check is the same as x? check but has a different design / coding:

• (AL) = x1; TF=x10
• AT: SN=x2; TF=x0
• BE: SN=x3; TF=x0 (a)
• BG: SN=x4; TF=x0
• CY: SN=x4; TF=x0
• CZ: SN=x0 (a); TF=x5
• DE: SN=x6 ; TF=x0
• DK: SN=x7; TF=x0
• EE: SN=x4; TF=x0
• ES: SN=x4; TF=x0 (a)
• FI: SN=x8; TF=x0
• FR: SN=x4; TF=x0 (b)
• GR: SN=x9; TF=x0
• HR: SN=x11; TF=x0 (b)
• HU: SN=x12; TF=x0
• IE: SN=x11; TF=x0
• IT: SN=x4; TF=x0
• LT: SN=x9; TF=x13
• LU: SN=x4; TF=x0
• LV: SN=x4; TF=x0
• (ME): SN=x0 (c); TF=NONE_116
• (MK): SN=x0; TF=x0
• MT: SN=x12; TF=x0
• NL: SN=x5; TF=x0
• PL: SN=x12 (a); TF=x0
• PT: SN= x7 (a); TF=x0 (a)
• RO: SN=x12; TF=x0
• (RS): SN=x0 (d); TF=NONE_116
• SE: SN=x11; TF=x0 (a)
• SI: SN=x12; TF=x0 (a)
• SK: SN=x4; TF=x0
• (TR): SN=NONE_116; TF=NONE_116

It's not easy to evaluate the correctnes, because the status might be none, reserved (designed) or in operation (assigned).

At least I found out so far that x8 is excluding 116000 as a short number, and Finland, which is using this check is indeed supporting this number: https://www.suomi.fi/services/phoneservice/116000-european-missing-children-hotline-number-emergency-response-centre-agency-finland/f42acfab-5167-464d-89c2-874ae8d81133 (own issue)

Should this become an own issue? And what about further 116xxx findings?

Hi,

Thanks so much for the details. We will check and add support to the numbers under 116 XXX and 118 XX. Geocoding is comparitively low priority for us and considering the amount of time to investigate, we will firstly get the validation updates done first.

Hi, I just want to bring up, that the main point:

I suppose the main problem is a misunderstanding. When I read in a previous response „So when it comes to 556677, 55X are valid area codes followed by 3 digit subscriber numbers. This is the reason why 556677 is considered as IS_POSSIBLE than IS_POSSIBLE_LOCAL_ONLY. 556677 is a potential full length number - i.e with area ccde.“ This ambiguity seems to be only true for the data model of the library. In the telephone network, it is unambiguously 556677 is a phone 6 digit number without an area code while 0556677 is a phone number with an invalid area code (only 05565 exists … but lets assume 55 would be an area code ;-) ) - but back from this bad area code example, the leading 0 is the trunc code. The problem is, that the library does not make it easy to handle this.

First of all both numbers have the same National Format representation (0556677) 556677 and 0556677

I think the root cause is also documented in the code: // This is safe because there is never an overlap beween the possible lengths and the local-only lengths; this is checked at build time.

While this might be true for number plans without using a trunc code like the NANP it is not true when a number plan is using a trunc code. There fore it needs to be checked, if metadata.hasNationalPrefix()is true and then check if a national prefix has been eliminated during parsing the input.

Are you still working on this - would you be interested in pull request with a suggested solution?

Hi, I added another or to access the hasNationalPrefix information for a region code. That pr would be helpful to fix the issue to identify local-only numbers in regions which use a national prefix. Could someone have a look on it and give a feedback?

https://github.com/google/libphonenumber/pull/2625

Very sad that this is just sad to have this ticket waiting so long and then setting it to won't fix with a comment, which is not accurate.

To make it very clear - it is not about special short numbers which needs to be updated. It is a problem of the algorithm, not knowing, that a German number without area code is only valid locally and not generally.

If this is not clear, because I brought in so many details about additional stuff, I am sorry. I would be happy if we could reopen and discuss this further.

I modified the code . Thank you everyone

int flg = fcntl(fd,F_GETFD);
flg &= ~FD_CLOEXEC;
fcntl(fd,F_SETFD,flg) 

For memfd to be used the vndk version must be >= 29 and the use_memfd property must be set to true, it's currently false for all devices.

flame:/ # getprop | grep vndk [ro.product.vndk.version]: [30] [ro.vndk.version]: [30]

flame:/ # getprop | grep memfd
[sys.use_memfd]: [false]

Anyway, it does need to be fixed so that we can eventually set use_memfd to true, so thanks for fixing.

https://android-review.googlesource.com/c/platform/frameworks/native/+/1419344 improves the documentation, and https://android-review.googlesource.com/c/platform/system/core/+/1419610 adds the missing unit test and fixes the memfd_create(2) path so it will pass the unit test too once it's enabled.