You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Attach a portable USB drive to USB-C port - because of getSdCardBaseFolderScopedStorage() use - which causes it to to become the path of internal because getExternalStorageDirectory() provided by Android doesn't work with USB drives and the code issue there makes it broken as well as other issues surrounding traditional paths use here.
This results in "Manage users..." showing incorrect chroot path and problems using the USB storage.
Comments:
May want to rethink how the chroot works. This is because DocumentFile does not actually work with full paths and USB drive is worse than sd card. It returns "name:path". That is technically the full chroot for DocumentFile.
The "/storage" is omitted, and while I thought "/storage" had the USB drive before, it is not that way today on my test device with the latest Android OS updates on that device (it is indeed in /storage on Android 8.0 so I'm not seeing things). I don't yet know if "/mnt/media_rw/usb name" works which is the only place I'm seeing the USB drive now. That's not looking like a great idea today.
Also, File is incompatible here with the DocumentFile URI path and there's a ton of those uses with File that I left in for scoped storage where it just happened to work for lack of better words. So, have to rework a lot since chroot is heavily tied to File use.
It is tempting to just have chroot fake apply /storage/URI as a workaround. But, there's still a lot of FIle uses that would need to try to find the storage, dir, and file that way and would have ugly adjustments all over the place anyway.
It might be even better if all File uses could be decoupled such as getFile() (or whatever name) that deals with getting and returning either File or DocumentFile. That I think should lower the amount of code and make things simple. Instead of doing sdk version checks at every single File use and doing DocumentFile based code there as well. Would still be a lot of changes though. Edit Added pull request #204
The text was updated successfully, but these errors were encountered:
Xavron
changed the title
USB storage and chroot has wrong appearance on Android 13
USB storage doesn't get correct chroot on Android 13
Apr 22, 2023
What this is doing to me: d'oh!
Attach a portable USB drive to USB-C port - because of getSdCardBaseFolderScopedStorage() use - which causes it to to become the path of internal because getExternalStorageDirectory() provided by Android doesn't work with USB drives and the code issue there makes it broken as well as other issues surrounding traditional paths use here.
This results in "Manage users..." showing incorrect chroot path and problems using the USB storage.
Comments:
May want to rethink how the chroot works. This is because DocumentFile does not actually work with full paths and USB drive is worse than sd card. It returns "name:path". That is technically the full chroot for DocumentFile.
The "/storage" is omitted, and while I thought "/storage" had the USB drive before, it is not that way today on my test device with the latest Android OS updates on that device (it is indeed in /storage on Android 8.0 so I'm not seeing things). I don't yet know if "/mnt/media_rw/usb name" works which is the only place I'm seeing the USB drive now. That's not looking like a great idea today.
Also, File is incompatible here with the DocumentFile URI path and there's a ton of those uses with File that I left in for scoped storage where it just happened to work for lack of better words. So, have to rework a lot since chroot is heavily tied to File use.
It is tempting to just have chroot fake apply /storage/URI as a workaround. But, there's still a lot of FIle uses that would need to try to find the storage, dir, and file that way and would have ugly adjustments all over the place anyway.
It might be even better if all File uses could be decoupled such as getFile() (or whatever name) that deals with getting and returning either File or DocumentFile. That I think should lower the amount of code and make things simple. Instead of doing sdk version checks at every single File use and doing DocumentFile based code there as well. Would still be a lot of changes though. Edit Added pull request #204
The text was updated successfully, but these errors were encountered: