⏹ StorageAccess Extension: Simplifying Storage Permissions in MIT App Inventor

You can get access to all type of files with SAF. See preview video of this extension:

You are correct, I know this,
Cause Google’s policy requires that apps justify the need for this permission and demonstrate core functionality that requires such broad access to manage all files. Without a legitimate need for this permission, apps may be rejected from the Google Play Store.

in the video, I could upload images, videos, or even Audio files by default before requesting access

but if I decided to pick any other file types I had to request this permission .

Which extension did you use to pick files?

I use Activity starter

Use SAF and you will find that you can access all documents without any need of permission.

do you mean SAF Picker :point_down: ?

Yes.

Ok I will definitely give it a try thanks @vknow360

Yes, this will only confuse most users and everything has already been explained in detail in this guide:

4 Likes

Hello, I stumbled upon this post created by you nine months ago. Thanks to your extension, I managed to complete my app. However, I still have some issues, and I kindly ask if you could please send me the AIA file of the video so that I can better understand the functioning or the logic of your extension. Let me explain further, I am currently unable to find the logic "if the permissions are granted, then do". Best regards.

This block returns true when successfully granted and false for counter.

Hi Black_Knight, thanks for the answer, but i can t see the block that you mentioned.

I presume it is this one:

See first post

Timai2, this is the block tha i am actualy using. I am sure that imake something wrong.

and this block to grand storage acess

  1. It is unnecessary to request READ and WRITE permissions together on Android < 11, because WRITE permission always implicitly grants READ permission.

  2. Automatically (extension-controlled) requesting storage permissions is generally not a good idea. If only READ permission is required, only that should be requested.

  3. On Android >= 11, it should of course also be possible to request READ permission (Android 11-12: READ_EXTERNAL_STORAGE and Android >= 13: READ_MEDIA_IMAGES (_AUDIO, _VIDEO). On Android 11+, requesting MANAGE_EXTERNAL_STORAGE is only necessary in very rare cases. Namely, in cases where SAF no longer provides a solution. For example, if non-media files from the /Download or root directory of the external storage should be listed.

  4. There is already a guide and an extension that allows you to request MANAGE_EXTERNAL_STORAGE specifically and on demand, and it is not intended to publish the app in the Play Store (because Google will most likely not grant the permission).

In short:
Remove the extension. It only creates confusion and does not solve any problem that cannot be solved more easily and specifically in other ways. It also saves power users the need to to provide time-consuming explanations about the limited usability of your extension. (*)


(*) See here: The ProCamera not take picture? - #6 by lladam

1 Like

For this, I have created a method to pick any file without requesting any permission see here

I don't see any connection at all. Why would we need such an extension that does nothing other than the FilePicker component?

As I said before, and I'll repeat again: MANAGE_EXTERNAL_STORAGE is required when an app absolutely needs access to the root directory or /Download. Google no longer grants access to these directories via SAF on Android 11+.

You've got a point that the initial step of launching the file picker using ActivityStarter with GET_CONTENT does look very similar to what the built-in FilePicker component achieves. I can see why you'd question the need for an extension just for that.

However, where I think we might differ is on what happens after the file is picked, and regarding the permissions.

for Permissions & SAF: You're right that MANAGE_EXTERNAL_STORAGE is the permission needed for broad, direct path access to places like Downloads. But this code uses GET_CONTENT, which is part of the Storage Access Framework (SAF). SAF is Google's intended method for apps to access user-chosen files without needing MANAGE_EXTERNAL_STORAGE. The user grants permission file-by-file via the picker. Crucially, SAF does allow users to pick files from Downloads (and other locations) on Android 11+; that's its purpose. The limitation on Android 11+ is primarily on direct path access without SAF or the special permission, not on using SAF itself."

But also let me move to :

The Extension's Role: The FileUtilities.GetFilePathFromURI block is likely the key reason for the extension here. Handling the content:// ResultUri returned by the picker (whether from ActivityStarter or FilePicker) can be tricky with standard blocks, especially on newer Android versions due to Scoped Storage. Getting a direct, usable file path or copying the file often requires helper functions like those typically found in file utility extensions. So, the extension isn't just replicating the picker; it's likely processing the result.

You can try the method by yourself to reach what I mean: "I don't need any storage permission to to get file path using this extension "

I don't need any explanations about permissions, file access, or SAF. Everything necessary has already been said. It's undisputed that SAF allows you to access every file (media or non-media). For the third time now: Access to the root directory of the external storage and /Download is not possible with SAF.

So what? Of course, the FilePicker doesn't need permission to return the contentUri or file path either. But can I access a non-media file after selecting it via the FilePicker (e.g., read a text file)? I don't think I really need to answer that question!

I also doubt that your extension will return the correct file path when selecting a file from a removable SD card. (I won't test it because I don't want to log in to another AI2 clone platform.)