WAI
Status Update
No update yet.
Comments
ar...@gmail.com
Hi,
Thank you for taking the time to improve libphonenumber!
We are looking into this and will respond as soon as possible.
ab...@gmail.com
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
Numbertype 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 ofpossible phone number length - 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.
- Marking the field as
[jstype = JS_STRING] - 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.
vk...@google.com
na...@google.com
+923146233552
na...@google.com
A label is not being included on the session params. The launcher requires this to add the icon.
lb...@gmail.com
@6 Again, incorrect, and doesn't make sense, and also the docs don't say anything about it either.
In fact the docs say it's optional.
Why do you write those things without checking it out?
And why do you keep on closing issues without letting me write a reply?
This is rude.
Here, again:
https://issuetracker.google.com/issues/158285671
In fact the docs say it's optional.
Why do you write those things without checking it out?
And why do you keep on closing issues without letting me write a reply?
This is rude.
Here, again:
ja...@google.com
Hello,
We are checking it out, thank you for making us aware the docs don't match advice from engineering.
We will always get your replies no matter what the bug status says - it is just a way for us to keep track of what bugs require followup with engineering.
Thank you very much for your time & help,
James
We are checking it out, thank you for making us aware the docs don't match advice from engineering.
We will always get your replies no matter what the bug status says - it is just a way for us to keep track of what bugs require followup with engineering.
Thank you very much for your time & help,
James
ja...@google.com
It appears there's several separate bugs, filed starting in March, for this conversation:
151242179 - API doesn't work in the emulator
153223644 (this one) - API should work without any additional parameters or doc should be changed to reflect required parameters
158285671 - same as above bug, if I understand correctly
158124551 - package name is required for API to work (I'd argue this is a subset of this bug, 153223644)
157674841 - internal framework bug filed for engineering response to 153223644
159426943 - internal bug from DevRel filing on behalf of this developer
I'm duping the internal ones to 159426943 and assigning it to the appropriate team
151242179 - API doesn't work in the emulator
153223644 (this one) - API should work without any additional parameters or doc should be changed to reflect required parameters
158285671 - same as above bug, if I understand correctly
158124551 - package name is required for API to work (I'd argue this is a subset of this bug, 153223644)
157674841 - internal framework bug filed for engineering response to 153223644
159426943 - internal bug from DevRel filing on behalf of this developer
I'm duping the internal ones to 159426943 and assigning it to the appropriate team
lb...@gmail.com
@9 I see. Sorry for that. OK mark them all as duplicates, but to this one:
https://issuetracker.google.com/issues/159275209
It's a request showing that I was instructed multiple times with different things by Google (including here, where you guys tell me that what I'm missing is a label and not a package name), all are incorrect.
The request is to be able to finally use it in both API and adb, without package name.
In adb it's the most annoying, because you don't have any adb command to make it fetch the package name from an APK and put it there as parameter. I have a tiny batch file that I use to make installing an APK file easily into emulator/device, by just double clicking on it. With the new INSTALL_REASON_USER , it's impossible to use it because each APK file has a different package name which needs to be fetched.
It's a request showing that I was instructed multiple times with different things by Google (including here, where you guys tell me that what I'm missing is a label and not a package name), all are incorrect.
The request is to be able to finally use it in both API and adb, without package name.
In adb it's the most annoying, because you don't have any adb command to make it fetch the package name from an APK and put it there as parameter. I have a tiny batch file that I use to make installing an APK file easily into emulator/device, by just double clicking on it. With the new INSTALL_REASON_USER , it's impossible to use it because each APK file has a different package name which needs to be fetched.
Description
- Steps to reproduce the problem (including sample code if appropriate).
Try the old API to install an APK file and try to use the new one, and provide "reason" as parameter (or don't because sadly it doesn't do anything, as opposed to using with adb), to encourage the launcher to create a new icon for the installed app:
...
val packageInstaller: PackageInstaller = packageManager.packageInstaller
val params = PackageInstaller.SessionParams(PackageInstaller.SessionParams.MODE_FULL_INSTALL)
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O)
params.setInstallReason(PackageManager.INSTALL_REASON_USER)
...
To try using the attached sample, put the sample APK file into the root of the main storage, and launch the app of the sample project.
- What happened.
When using the old API, it puts the app icon on the launcher, without even requiring us to add any "reason" of installation.
When using the new API, even if you do add the "reason", it doesn't add the app icon
- What you think the correct behavior should be.
Should be possible for both APIs to request "reason", and not be ignored for it.
This same API is used to install split APKs, too, BTW, and the same issue occurs there too.
Sadly, though, there is no "old API" for installing split APKs, so there it will never create a new app icon, unless using adb (or rooted device)