WAI
Status Update
Comments
lb...@gmail.com <lb...@gmail.com> #2
The only solution I've found is to move/copy the file to the "/data/local/tmp/" path, and only there to install, but this is never needed when we do it via adb command of the PC, and was never this way on previous versions of Android.
lb...@gmail.com <lb...@gmail.com> #3
Putting a soft link to the file, using this:
"ln -sf $filePath $tempFilePath"
Also got the same result. It fails to install it. It doesn't even find the file, saying it's not there, even though it succeeded being created there.
"ln -sf $filePath $tempFilePath"
Also got the same result. It fails to install it. It doesn't even find the file, saying it's not there, even though it succeeded being created there.
lb...@gmail.com <lb...@gmail.com> #4
Speaking of symlink, using framework function didn't do anything:
Os.symlink(filePath, tempFilePath)
Os.symlink(filePath, tempFilePath)
lb...@gmail.com <lb...@gmail.com> #5
In fact, choosing to move the file to the "/data/local/tmp/", it actually copies it.
Isn't there any way to avoid extra usage of space while installing? The file is already in the file system. Why make a copy of it...
Isn't there any way to avoid extra usage of space while installing? The file is already in the file system. Why make a copy of it...
lb...@gmail.com <lb...@gmail.com> #6
Oh I was mistaken about the moving part. But it's actually risky to move the file. There should be a way to avoid such operations, just like via adb and via the play store.
ad...@google.com <ad...@google.com>
ad...@google.com <ad...@google.com> #8
Thank you for reporting this issue. For us to further investigate this issue, please provide the following additional information:
We are unable to reproduce the issue with -https://play.google.com/store/apps/details?id=com.lb.app_manager&hl=en
See attached video.
If have additional information to help us, please let us know.
We are unable to reproduce the issue with -
See attached video.
If have additional information to help us, please let us know.
lb...@gmail.com <lb...@gmail.com> #9
@8 I've updated the app to use the workaround of first moving the APK file to this special path (written about it on the StackOverflow post). That's why you can't reproduce it.
If you try to use an older version (before I've reported this issue), you will see the issue on my app. You can also try other apps, such as Titanium Backup (pro), or other backup apps that use root for installing the APK files in the background (without confirmation of user).
What I've used is a bad workaround, because of various disadvantages it brings. An APK file should not be needed to be moved somewhere else in order to install it. If this is another security related decision, it can be easily handled without this new rule. For example, it could lock the file from being modified till the process of installing is done (all in a single atomic operation of installing). And I'm sure there are other solutions I haven't thought about, but having to do this for a rooted device... this is just too weird...
If you wish to try an older version of my app (before this workaround was applied), it's attached here.
If you try to use an older version (before I've reported this issue), you will see the issue on my app. You can also try other apps, such as Titanium Backup (pro), or other backup apps that use root for installing the APK files in the background (without confirmation of user).
What I've used is a bad workaround, because of various disadvantages it brings. An APK file should not be needed to be moved somewhere else in order to install it. If this is another security related decision, it can be easily handled without this new rule. For example, it could lock the file from being modified till the process of installing is done (all in a single atomic operation of installing). And I'm sure there are other solutions I haven't thought about, but having to do this for a rooted device... this is just too weird...
If you wish to try an older version of my app (before this workaround was applied), it's attached here.
ad...@google.com <ad...@google.com> #10
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> #11
We don't support installation of APKs from random directories on the device. They either need to be installed directly from the host using 'adb install' or you have to stream the contents to install --
$ cat foo.apk | pm install -S APK_SIZE
$ cat foo.apk | pm install -S APK_SIZE
lb...@gmail.com <lb...@gmail.com> #12
@11 It was never this way.
It always worked with any path. Why this new limitation for rooted devices?
Also, can you please explain the last line you wrote:
1. Is this a workaround?
2. If so, what is the "-S APK_SIZE" for ? is it the size of the APK file? Why is it needed?
I've tried it as such in the sample app:
val length = File(filePath).length()
commands.add("cat $filePath | pm install -S $length")
Seems to work.
3. Does this workaround avoid the moving/copying of the APK into storage, and without affecting the original file ?
4. Will this support any APK file, even large ones?
5. This is needed only from Android P, right?
It always worked with any path. Why this new limitation for rooted devices?
Also, can you please explain the last line you wrote:
1. Is this a workaround?
2. If so, what is the "-S APK_SIZE" for ? is it the size of the APK file? Why is it needed?
I've tried it as such in the sample app:
val length = File(filePath).length()
commands.add("cat $filePath | pm install -S $length")
Seems to work.
3. Does this workaround avoid the moving/copying of the APK into storage, and without affecting the original file ?
4. Will this support any APK file, even large ones?
5. This is needed only from Android P, right?
lb...@gmail.com <lb...@gmail.com> #13
@11 Also:
6. Why does it need the extra parameter of file size?
6. Why does it need the extra parameter of file size?
ad...@google.com <ad...@google.com> #14
It's an implementation detail of the device, and is subject to change between releases. Manual usage of these commands outside of the OS-provided tools is unsupported by the OS team.
lb...@gmail.com <lb...@gmail.com> #15
@14 It can (and should) be like adb command via PC.
As a developer (and power user too) I find it extremely useful to root devices. It makes so many repeated operations to take much less time, even without a PC around.
I hope it won't have any issues on future releases of Android, and I thank you for helping me on this one. I hope you would agree to help in the future too.
As a developer (and power user too) I find it extremely useful to root devices. It makes so many repeated operations to take much less time, even without a PC around.
I hope it won't have any issues on future releases of Android, and I thank you for helping me on this one. I hope you would agree to help in the future too.
Description
PP2.180412.013
* Is this a regression from O to P?
Doesn't occur on any other Android version
* What device are you using? (for example, Pixel XL)
Pixel 2
* What are the steps to reproduce the problem? (Please provide the minimal reproducible test case.)
1. Download an APK file. Example this one:
2. On Android P DP2, and on previous Android versions, use any app that can install APKs using root access. Alternatively, use the attached project which uses root access to install APK files :
"pm install $filePath"
Example apps that don't work anymore :
a. the pro version of "Titanium backup" - install APK normally (without this app), backup using this app (including APK), uninstall, and then restore with the APK :
b. "App manager" - go to APK files in the navigation drawer, and choose to install the app :
* Issue Category e.g. Framework (platform), NDK (platform), Hardware (CPU, GPU, Sensor, Camera), ART (platform), Runtime Permissions etc
platform
* What was the expected result?
Should install fine, just like when we do it via PC (which works fine)
* Can you provide the API document where this expected behavior is explained?
* What was the actual result?
Can't do it. Instead you get an error of this sort:
avc: denied { read } for scontext=u:r:system_server:s0 tcontext=u:object_r:sdcardfs:s0 tclass=file permissive=0
System server has no access to read file context u:object_r:sdcardfs:s0 (from path /storage/emulated/0/Download/FDroid.apk, context u:r:system_server:s0)
Error: Unable to open file: /storage/emulated/0/Download/FDroid.apk
Consider using a file under /data/local/tmp/
Error: Can't open file: /storage/emulated/0/Download/FDroid.apk
Exception occurred while executing:
java.lang.IllegalArgumentException: Error: Can't open file: /storage/emulated/0/Download/FDroid.apk
at com.android.server.pm.PackageManagerShellCommand.setParamsSize(PackageManagerShellCommand.java:306)
at com.android.server.pm.PackageManagerShellCommand.runInstall(PackageManagerShellCommand.java:884)
at com.android.server.pm.PackageManagerShellCommand.onCommand(PackageManagerShellCommand.java:138)
at android.os.ShellCommand.exec(ShellCommand.java:103)
at com.android.server.pm.PackageManagerService.onShellCommand(PackageManagerService.java:21125)
at android.os.Binder.shellCommand(Binder.java:634)
at android.os.Binder.onTransact(Binder.java:532)
at android.content.pm.IPackageManager$Stub.onTransact(IPackageManager.java:2806)
at com.android.server.pm.PackageManagerService.onTransact(PackageManagerService.java:3841)
at android.os.Binder.execTransact(Binder.java:731)
This worked fine on all previous Android versions.