Implement support for the Storage Access Framework on Android

[white-axe]

This pull request adds support for the Android Storage Access Framework into the VFS in libretro-common.

It also adds a button to the file browser in Android builds of RetroArch (both the Google Play and non-Google Play builds), similar to the button that's already present in the builds of RetroArch for Apple platforms, that uses the Storage Access Framework to allow the user to mount most directories¹ from internal storage, the SD card (if any), other removable storage devices and any document providers provided by other Android apps on the current device.

That also means Android users can now use the RSAF app and other document providers to access files on remote servers instead of lugging around all their ROMs and whatnot locally.

I mentioned already in #18321 that libretro cores won't be able to access anything the user mounts using the Storage Access Framework unless the libretro core uses the VFS, so be aware that not every libretro core will be able to use this functionality immediately. Also, the VFS is slower when using the Storage Access Framework, in particular the readdir function in the VFS.

• Closes [Bounty] [Android] Implement support for Storage Access Framework #12181
• Closes [Android] Android 11/12 Scoped Storage updates prevent RA from using USB or network directories #13493
• Closes Shader Overrides for games/cores/global no longer automatically loading on Android 11 #13809
• Closes Support for loading content from external USB drive on Android 12  #14666
• Closes [Feature Request] Make use of the vfs in android to access SAF directories #17348
• Closes External USB support on Android 14 #17395

Footnotes

1. According to the documentation, does not allow mounting the root directory of the internal storage, the root directory of SD card volumes or the Download directory, Android/data, Android/obb or any descendants of Android/data and Android/obb. All other directories should be fair game. ↩

[i30817]

before I check this myself by downloading it, can this work with portable playlists?

ie: if I already have a bunch of portable playlists of games, can I copy them over to android and set the base file browser dir (I forget the real name of the setting) and it will accept a SAF path there? Same thing for other paths in the manual scanner like the dat file path, the scan dir path (for if you're creating a new playlist instead of reusing a existing portable one, etc).

The second and third seems like a no-brainer of course, but I thought better asking about the first because it's a feature few use even if it's so very useful, and because there are some directory seperator replacement tricks going on in that code (even if I'm not that worried about that part, just that the 'button' appears in the file chooser generally so a setting that apparently -but wrongly- most people think has nothing to do with 'the scanner' still can use it).

[i30817]

Btw if you don't already know there are some other good news with RSAF: next major version of rclone (and thus RSAF) will allow to mount zips and squash (.sqfs) files, including zstd ones. This can be done locally too, so a document provider like RSAF will be able to pseudo mount a 90gb squash file holding 130gb or something like that, for those people with terrible home servers or networks but that nonetheless still want more space for games than the terrible 128gb that's normal in entry phones.

I said next major version but it's already merged so it may be next minor one when RSAF updates, not sure.

[white-axe]

Yes, you can set the start directory to a SAF path so that portable playlists can load from the SAF. Every setting in RetroArch whose value is a path will give you the option in the UI of opening the OS file picker to mount a new path from the SAF. As far as I can tell, all of RetroArch's file system accesses go through the VFS, so SAF paths should just work.

[i30817]

Good that means that even using remote playlists for multiple devices for a single source of 'truth' could work (instead of copying them over and using portable playlists which is what I'm doing now).

There might be some complications if the code expects being able to write to them and you don't have a write enabled webdav, which is a bit dangerous even with a password in RSAF imo, but it's something to try later. Maybe keeping the history and favorites playlists locally (if possible) and turning off editing (adding renaming or removing entries) might be possible in RA.

Not sure how portable playlists would react (since they can change the directory separator for different windows\unix platforms I'm not sure if that is all in memory or in the file too. For read only portable playlists it would need to be all in memory). Read only playlists would even be sort of necessary to avoid weird bugs if multiple RetroArch instances would be using them at the same time (eg: in a lan party).

That's all a bit complicated so I'm happy with copying over the files though, don't feel like you have to test this. I doubt many will use it like this anyway.

[i30817]

Hey could you test the puae core with a WHDLoad .lha? None of them appear to start, even if the core is supposed to support the libretro vfs. I also opened a issue in the core if you want to coordinate, and I'm just pinging you because I'm not sure this is the core fault, and you probably have a webdav to test setup.

libretro/libretro-uae#715

[esspeecy]

This might be a stupid question but has this fix been built into the latest release or nightly build?

I still get Directory Not Found when browsing SD cards on my Pixel 7 and Pixel Tablet

[white-axe]

This change is included in the stable releases of RetroArch starting from RetroArch 1.22.0 and is also in the nightly builds. However, paths on your SD card are only accessible via the button in RetroArch's internal file picker that opens a directory using the system file picker. The button should appear somewhere in the top level of RetroArch's internal file picker.

[i30817]

Btw @white-axe , the "top level" doesnt appear if you have file browser start directory already set to a webdav saf uri (using rsaf and a local webserver) in the content directory of the manual scanner (load content always starts on that menu though). You go up (repeat), until you get to "./" then the file browser doesnt let you go up anymore. I think partioning URI creates a different top level string than a directory path, and the menu is never triggered.

I opened a bug if you'd like to track it