0

On iOS, there are app groups.

On UWP/Windows, there is the shared publisher cache.

On Android, there is no equivalent. Prior to the tightening of security constraints and the abstracting of the file system, one solution was to designate a commonly accessible file folder in storage. The main difference is the designated folder was not connected to the apps and so wouldn't automatically be removed when the last of the apps in the 'group' was removed. But that was manageable.

Starting with Android SDK30 that is no longer an option either.

Shared app storage space is required any time you have more than 1 application that needs to share a local data cache. An example would be an enterprise set of applications that allow offline modes of operation. Locally cached data is expensive to download, and multiple apps are created where any given person might need 1 or more or all apps in the suite sharing this cache.

How can something like this be accomplished after targeting SDK30 or above?

Alternative 1: Storage Access Framework

  • Prompt the user for a folder to use with ACTION_OPEN_DOCUMENT_TREE. Then this same permission prompt has to be done from EACH app and the user had better pick the same folder... That is not ideal, but it could establish permissions to a common folder.
  • Unfortunately even after permission is obtained a cross platform solution based on simple file/folder paths does not work with this approach. The android solution must be abstracted out and implemented differently. More on this below.
  • With Xamarin C# System.IO operations I've been able to test Alternative 1 but can't seem to get the file paths to work from both apps (see https://stackoverflow.com/a/69712669/1735721).

Alternative 2: FileProvider

  • Not sure if it's possible to use the FileProvider process to open up access to a whole folder, including the ability to create new files in that folder from another app... But potentially this might be an option if one of the installed apps becomes the primary storage location and the other apps in the suite read/write to that exposed FileProvider location.
  • I've had no luck trying this option...seems like this is not supported. And the logistics of figuring out which of the installed apps should be primary is tricky.

Alternative 3: MANAGE_EXTERNAL_STORAGE

  • This limited but powerful permission is the "fallback" option, and not sure if it would be accepted by Google Play as an exemption - This use case does not fall into the examples given in the documentation.
  • It would be the "easiest" to implement. Initially an app I tried with this approach was rejected and the appeal is pending.

API vs Files/Folders

In either of the first 2 alternatives it seems like you may have to deal with the Android SAF API to access files. If you are writing Android platform specific code that might work... But if you are using a cross platform framework e.g. Xamarin then this is far less than ideal. Every cross-platform database layer I've looked at relies on folder/file logical access which only works in the app's private sandbox on Android, not shared folders. The traditional file/folder system is much preferable for cross platform logic.

Missing something?

Is there any better way to go approach this and potentially keep using file/folder paths for full read/write access from multiple apps?

EDIT 11/5/2021: Added Alternative 3.

EDIT 12/2/2021: Slightly reorganized and added some content.

DennisWelu
  • 788
  • 13
  • 26
  • I'm going to question your assumptions here- why do you need this? Is shared access to files actually the best way to achieve your goals? What are you actually trying to do with it? – Gabe Sechan Nov 03 '21 at 19:16
  • @GabeSechan Fair question. Basically for the same reasons those mechanisms exist on the other platforms. Decent size enterprise suite of related apps - the choice of apps loaded will vary be user. But they share an overlapping data model and are used offline so the data cache is expensive to obtain. Cross platform apps also, so using the file system is a common denominator way to logically reference files. – DennisWelu Nov 04 '21 at 00:42
  • My main thought is that on Android a ContentProvider is probably more appropriate – Gabe Sechan Nov 04 '21 at 01:09
  • AFAICT, a custom ContentProvider abstracts the data rather than treating them as simply files. A FileProvider serves files, but doesn't allow the direct read, write, AND CREATE access to a location. In both cases, it's my understanding one app would have to be the "owner" of the data and the others would interact with that one app...but no guarantee which app is going to be present. And the data for all will disappear if that one app is uninstalled. – DennisWelu Nov 04 '21 at 03:46
  • Treating them as files isn't really the Android way. You might be able to get it to work, but it's going to be a battle. But the whole problem of "one app owning it" isn't going to go away whatever you do- even if you got a FileProvider to work, one app owns the files. – Gabe Sechan Nov 04 '21 at 04:05
  • BTW it used to be possible to share a user ID between apps, and gain access to another apps files that way. But that mechanism was always a bit broken (you had to declare a user id) and was deprecated in 29. Google's suggested replacement is content providers. – Gabe Sechan Nov 04 '21 at 04:54
  • That all makes sense and matches up to what I've seen. I was hoping I just missed something! – DennisWelu Nov 04 '21 at 11:45

0 Answers0