RobertFlatt
commented
1 year ago Thanks for your feedback, if you'd like to write a subsection on how and when to use MANAGE_EXTERNAL_STORAGE that would be great.
The current omission is deliberate, and that is OK because this is a Users' Guide and not a Reference Manual.
Its not clear that we could create supportable documentation. Sometimes is best not to document the features of other peoples software, at some point you are guaranteed to fail.
The major reasons for omitting this are (perhaps these are things you could address):
-
If we tell users how to use it we also have to tell users when they can use it. Its not clear how to prevent surprises at the Store https://support.google.com/googleplay/android-developer/answer/10467955?hl=en. Surprises would mean unreliable documentation. Too many users do not have the context to know what "Core functionality" means. This document has to be written for the lowest common denominator Python script kiddie, and MANAGE_EXTERNAL_STORAGE breaks the security model. I think 'script kiddie' and 'security model' do not belong in the same sentence. 🤣
-
Interaction with the MediaStore is unclear to me. Can we say the two apis will have consistent state (I'm looking at you MediaStore)? If not there will be unexpected behavior. Can we document this? If we don't we get the why... questions that we don't know the answer to. We don't want to create support issues.
quixotely
Android-for-Python
Not sure if this doc is still maintained, and I commend its authors for providing some sorely needed Kivy/buildozer info. But its coverage of Android storage seems misleading, and arguably incorrect. The sections on shared storage and Kivy's file explorer in particular state that Android does not support file-path, POSIX access to storage; this is untrue.
I suggest that the authors explore Android's All Files Access permission (a.k.a. MANAGE_EXTERNAL_STORAGE). This was added in Android 11 to reinstate the file-path and POSIX file access that was more readily available earlier. With this permission, Python-coded apps can still use Python's portable file tools to process files on Android in shared storage, as well as app private (both "internal" and "external") storage. For a first look, try the dev page.
As an example, I recently published a backup/sync app that's coded in Python and Kivy; uses Python's built-in file tools to process content; and runs Kivy's file explorer to navigate shared and app storage by path names--on all Androids 8 and later, including 13. It obtains All Files Access on 11 and later, and legacy storage permission earlier.
You're invited to fetch this app's trial version to see this in action, at the Play Store. This app's PC versions use the same portable Python and Kivy code, and can be had at its main website.
It's true that All File Access requires Play-store approval, but it's been widely granted for content-processing tools, and this doesn't apply to side-loaded tools. It's also true that accessing shared storage by file paths and POSIX calls incurs some overhead, but this stems from Android's FUSE implementation and its added security checks, and the penalty is a minor price for being able to use existing POSIX code.
More to the point, Python file-path/POSIX processing can be used on Android. This is a huge win for people seeking to use portable Python code on Android, and seems better called out as an option than swept under the rug. With permissions, the only storages truly off limits to Python/Kivy app developers today are other apps' private ("internal") storage, and shared storage's Android/data folder (though some file explorers manage to open this as well).