Fixed
Status Update
No update yet.
Comments
lb...@gmail.com
Hi,
Thank you for taking the time to improve libphonenumber!
We are looking into this and will respond as soon as possible.
lb...@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.
zb...@gmail.com
+923146233552
lb...@gmail.com
@5 No. But it ruins the flow (and how the app is intended to work) of it on every app that does it for the first time, while giving the user the feeling that something is wrong with the app.
Imagine for example that you use Chrome, and you do something with it in the background (download something or play music), and now you chose to grant the install permission for it.
Now it will force stop, meaning it will stop what it did (downloading/playing music), and won't resume it on its own.
In a way, this is actually worse than a crash, because apps can do something about crashes, and in some cases they can even restore themselves automatically (example is a service).
Imagine for example that you use Chrome, and you do something with it in the background (download something or play music), and now you chose to grant the install permission for it.
Now it will force stop, meaning it will stop what it did (downloading/playing music), and won't resume it on its own.
In a way, this is actually worse than a crash, because apps can do something about crashes, and in some cases they can even restore themselves automatically (example is a service).
am...@google.com
lb...@gmail.com
This occurs on Android 11 beta 3 too.
Google please fix this issue. At the very least, if you can't fix it on time, put some workaround for apps, or write to the user:
"App will be closed upon turning on", and save the complete app state (including memory, stack trace, everything...).
And after it got closed, put button "restore app to original state", to restore it to the exact state it was before , as if all is fine and that the app was never closed.
Google please fix this issue. At the very least, if you can't fix it on time, put some workaround for apps, or write to the user:
"App will be closed upon turning on", and save the complete app state (including memory, stack trace, everything...).
And after it got closed, put button "restore app to original state", to restore it to the exact state it was before , as if all is fine and that the app was never closed.
lb...@gmail.com
Or make some Intent that will get back to the app, to let it restore itself (will be sent before requesting).
sa...@google.com
The app will indeed be killed, but the system will already automatically try to re-create it using the regular methods. If the app saves state correctly, it should automatically be restarted in the background. We've found that this restoring doesn't appear to happen when the app is launched from the debugger, but it does work when the app is launched from the launcher. If you observe a different behavior, can you please attach some sample code so we can look at it?
lb...@gmail.com
@10 No, I can't see that it changed. The process still gets killed, as I've reported.
The process shouldn't be killed when the user grants a permission. Maybe when denying a permission, but not when granting.
I've tested now on Chrome, letting it play some music in the background while installing an APK for the first time, and it didn't get restored. The music stopped and didn't resume.
So this is still a bug. Even for an app of Google itself.
I'm sure that if I try something similar on other apps (including of Google), I will notice the same thing. Example is copying a lot of files in the background using a foreground service (which shouldn't be killed so easily).
And as you've found, from the debugger it's quite annoying.
Please fix this bug. Restoring is better, but it's still a bug.
If you fail to do it for Android 11 on time, could you please fix it on Android 12 ?
The process shouldn't be killed when the user grants a permission. Maybe when denying a permission, but not when granting.
I've tested now on Chrome, letting it play some music in the background while installing an APK for the first time, and it didn't get restored. The music stopped and didn't resume.
So this is still a bug. Even for an app of Google itself.
I'm sure that if I try something similar on other apps (including of Google), I will notice the same thing. Example is copying a lot of files in the background using a foreground service (which shouldn't be killed so easily).
And as you've found, from the debugger it's quite annoying.
Please fix this bug. Restoring is better, but it's still a bug.
If you fail to do it for Android 11 on time, could you please fix it on Android 12 ?
lb...@gmail.com
@10 Not only that , but it's not true that the app will get restarted.
Check attached tiny sample, which has a button to open the app-info screen. The moment you grant the permission, the app's task is not restored, so when you press the back key, it won't go to the app.
It also occurs when I try to use root to grant the permission myself.
Check attached tiny sample, which has a button to open the app-info screen. The moment you grant the permission, the app's task is not restored, so when you press the back key, it won't go to the app.
It also occurs when I try to use root to grant the permission myself.
ar...@gmail.com
FWIW in 11 DP3 I'm observing our app (APKMirror Installer) correctly get restored after getting killed, with the activity that had the Install button respawned correctly, so from what I can tell the bug is mostly fixed for us.
lb...@gmail.com
@13 I know, but the fact remains:
The app process gets killed, and in various cases, it won't be restored at all.
And if you try what I wrote about Chrome, for example, you will see that too.
I can provide a video to show that this issue still exists, and take Chrome as an example.
The app process gets killed, and in various cases, it won't be restored at all.
And if you try what I wrote about Chrome, for example, you will see that too.
I can provide a video to show that this issue still exists, and take Chrome as an example.
[Deleted User] <[Deleted User]>
We just hit this issue in our instrumentation tests where we previously used pm install command via androidx.test.uiautomator.UiDevice and upon attempting to migrate to PackageInstaller we found no way to get REQUEST_INSTALL_PACKAGES without getting instrumentation test process killed. I am really frustrated here as there is no way to test such flows on Android R - one of such flows was to simulate app upgrade scenario where we first install an older version of our app and then install a newer version to catch issues in DB migrations etc.
What is recommended solution to perform installs in instrumentation, how Google does it internally?
[Deleted User] <[Deleted User]>
What is worse is that it is even not possible to run adb shell pm grant com.sample android.permission.REQUEST_INSTALL_PACKAGES before running the test instrumentation, I would assume adb has ability to automate such things but we get:
Exception occurred while executing 'grant':
java.lang.SecurityException: Permission android.permission.REQUEST_INSTALL_PACKAGES requested by com.sample is not a changeable permission type
at com.android.server.pm.permission.BasePermission.enforceDeclaredUsedAndRuntimeOrDevelopment(BasePermission.java:432)
at com.android.server.pm.permission.PermissionManagerService.grantRuntimePermissionInternal(PermissionManagerService.java:1451)
at com.android.server.pm.permission.PermissionManagerService.grantRuntimePermission(PermissionManagerService.java:1404)
at com.android.server.pm.PackageManagerShellCommand.runGrantRevokePermission(PackageManagerShellCommand.java:2287)
at com.android.server.pm.PackageManagerShellCommand.onCommand(PackageManagerShellCommand.java:249)
at android.os.BasicShellCommandHandler.exec(BasicShellCommandHandler.java:98)
at android.os.ShellCommand.exec(ShellCommand.java:44)
at com.android.server.pm.PackageManagerService.onShellCommand(PackageManagerService.java:21605)
at android.os.Binder.shellCommand(Binder.java:929)
at android.os.Binder.onTransact(Binder.java:813)
at android.content.pm.IPackageManager$Stub.onTransact(IPackageManager.java:4603)
at com.android.server.pm.PackageManagerService.onTransact(PackageManagerService.java:4306)
at android.os.Binder.execTransactInternal(Binder.java:1159)
at android.os.Binder.execTransact(Binder.java:1123)
lb...@gmail.com
@16 About granting this permission via adb, sadly Google chose to have some permissions granted in a weird way, and for some I have no idea how to grant.
In this case, it's not via "shell pm grant".
You can use this instead:
appops set $packageName REQUEST_INSTALL_PACKAGES allow
It works using root, at least.
But I wrote to myself that indeed it closes the app
:(
I really don't get why the need to have it this way of killing apps. All other permissions don't work this way.
In this case, it's not via "shell pm grant".
You can use this instead:
appops set $packageName REQUEST_INSTALL_PACKAGES allow
It works using root, at least.
But I wrote to myself that indeed it closes the app
:(
I really don't get why the need to have it this way of killing apps. All other permissions don't work this way.
al...@ozerov.de
@10, @13
> The app will indeed be killed, but the system will already automatically try to re-create it using the regular methods...
Can you please provide more details how the app is going to be recreated. What are exactly the regular methods? Intent parameters?
> The app will indeed be killed, but the system will already automatically try to re-create it using the regular methods...
Can you please provide more details how the app is going to be recreated. What are exactly the regular methods? Intent parameters?
lb...@gmail.com
@18 They only talk about the specific use case of using the new API to install apps.
If you use the old one (of just an Intent), the app won't get restarted. Same goes for when using adb (or root).
You could try to re-open the app yourself, perhaps, but the state won't be restored.
If you use the old one (of just an Intent), the app won't get restarted. Same goes for when using adb (or root).
You could try to re-open the app yourself, perhaps, but the state won't be restored.
al...@ozerov.de
@19 I'm also talking about the app killed when granting REQUEST_INSTALL_PACKAGES permission. I want to understand how the system is going to recreate the app exactly.
lb...@gmail.com
@20 So again, it's not about requesting the permission.
It's only when using the new API for when you install the APK.
Meaning when you got STATUS_PENDING_USER_ACTION .
It's only when using the new API for when you install the APK.
Meaning when you got STATUS_PENDING_USER_ACTION .
al...@ozerov.de
@21 Which new API are you referring to? The PackageInstaller API that sends a broadcast with STATUS_PENDING_USER_ACTION was introduced in Android 5 (SDK 21).
lb...@gmail.com
@22 Read @19.
The old one is the Intent. The new one is using the PackageInstaller API.
The old one is the Intent. The new one is using the PackageInstaller API.
na...@google.com
The issue has been fixed and it will become available in a future Android release.
lb...@gmail.com
@24 Meaning on Android S?
st...@gmail.com
Is there some news about the release in which the fix will be applied?
lb...@gmail.com
@26 Sure it wasn't fixed on Android S ?
st...@gmail.com
@27 yes, you're right. I never check on devices with Android > 11. Thank you.
li...@gmail.com
google fix this bug in there commit:
e9e278f67074892adf3a57bb314dfc362b486149
9da97c2d39d4e6ef968d8436698fd9f959e16b2e
hope the information is useful
e9e278f67074892adf3a57bb314dfc362b486149
9da97c2d39d4e6ef968d8436698fd9f959e16b2e
hope the information is useful
am...@gmail.com
where i can get these commits ? which repo has this changes
am...@gmail.com
Comment has been deleted.
Description
Sample and video:
This never occurred before. Never a user has granted a permission to an app, and got the app force-stopped from the OS, by design.
It doesn't make sense, and cause the app itself to look as if it has a bug, that it can't handle the change.
Even for runtime permissions, when the app is being denied a permission it had before, it gets restarted in case it has a running foreground service, but here it's a full force-stop.
Please avoid this new behavior. Have it as before: if the user grants the permission, it shouldn't kill the app.
Users will complain just because of this bad choice. Don't put weird behaviors like Xiaomi does.