The image component incorrectly requires READ permission

[Anke]

The Image component requires READ permission on Android 11+, even if the image belongs to the app. This is a bug and should finally be fixed. I've pointed this out several times already. This is all the more necessary since Google hasn't allowed READ_MEDIA_IMAGES permissions on Android 13+ since May 2025. Furthermore, the image component also requests READ when a contentUri is used. This makes the problem even worse.

In addition, the Play Store version of the Companion app doesn't even declare READ_MEDIA_IMAGES and READ_MEDIA_VIDEO permissions anymore (for the reason stated above), so a permission error is thrown there as well.
@ewpatton

[Anke]

Example (tested on Android 16):

For the Image component you must request READ_MEDIA_IMAGES in order to display the image:

Screenshot

But I found a special path, that does not require READ permission, which makes it even weirder.

[Anke]

Hmm, a week later there's still no comment or reaction to my post.
Could I be wrong here? I don't think so.

[zikunz]

You are right, and this is a known bug with two layers to it.

The first layer is at the manifest level. Image.java declares READ_EXTERNAL_STORAGE as a class-level @UsesPermissions annotation, so the permission appears in the manifest unconditionally whenever an Image component is present in a project, even when the image is loaded from assets. Other media components like Player.java handle this correctly by placing the storage permission at the method level on the Source property setter, so it only gets pulled into the manifest when that property is actually used.

The second layer is at runtime. Even after moving the manifest declaration to the method level, TiramisuUtil.requestImagePermissions still runs for every path passed to the Picture setter, including paths that should not need any permission (like app-owned files or content URIs). That runtime behavior is a separate concern and is what PR #2773 addresses.

I have opened a PR ( Move Image READ_EXTERNAL_STORAGE to method-level on Picture setter by zikunz · Pull Request #3888 · mit-cml/appinventor-sources · GitHub ) that addresses the first layer. It moves READ_EXTERNAL_STORAGE from the class level down to the Picture property setter and adds READ_MEDIA_IMAGES for Android 13+ compatibility, matching the pattern that Player.java already uses. This is tracked on GitHub as issue #2700. The runtime side of the problem is not covered by this PR.

Thank you for documenting this so thoroughly, especially the Android 16 testing and the content URI edge case.

[Anke]

@zikunz

The first layer is at the manifest level. Image.java declares READ_EXTERNAL_STORAGE as a class-level @UsesPermissions annotation, so the permission appears in the manifest unconditionally whenever an Image component is present in a project, even when the image is loaded from assets.

Correct, READ_EXTERNAL_STORAGE is of course unnecessary, but not problematic, as Google has no issues with it up to Android 12. On Android 13+, however, READ_MEDIA_IMAGES must be requested, and Google has not allowed this since May 2025 (without prior approval from Google).

Therefore, the unnecessary declaration of the READ_EXTERNAL_STORAGE permission is only relevant up to Android 12 anyway.

@zikunz

Other media components like Player.java handle this correctly by placing the storage permission at the method level on the Source property setter, so it only gets pulled into the manifest when that property is actually used.

No, the Player component declares basically READ_EXTERNAL_STORAGE and READ_MEDIA_AUDIO in the Manifest. Both permissions are unnecessary here as well, but harmless since Google has no issues with either. However, I always remove these permissions from the Manifest of my Play Store apps beforehand.

As I've been saying for years, requesting storage permissions should, without exception, be left to the app developer! In the past—before the introduction of the Scoped Storage concept—it might have made sense to declare them. Definitely not anymore! It only creates confusion, conflicts, and problems.

[eAcademy]

I raised this issue a long time ago but on Niotron. ListView component also carrying this unnecessary permission Big Bug Report, Permission Not Removing on Removal of Extensions! - Bugs - Niotron Community

We are aware of this but beginners just drag and drop and publish the app to play store and get notice of app suspension, and even the Google never tell actual reason which leads to console account suspension. Temp solution: set bg image to arrangement instead of image component.

[Anke]

@eAcademy

Internet permission is declared by default and as I said READ_EXTERNAL_STORAGE permission is unnecessary, but harmless, as Google will not object to it.

Btw, it's the same with AI2.

[zikunz]

Thank you for the correction. I get it now that Player.java is not a good reference here since it also declares unnecessary storage permissions. I should not have called it a correct reference and the point about Google requiring prior approval for READ_MEDIA_IMAGES since May 2025 is important. My PR originally added that permission to the manifest, which would make Play Store submissions worse rather than better. I have reworked the PR to remove READ_MEDIA_IMAGES and only move READ_EXTERNAL_STORAGE from class level to method level, matching what VideoPlayer.java does for its Source property.

[Anke]

@zikunz

READ_MEDIA_IMAGES since May 2025 is important

You might take a look at my guide Some basics on Android storage system.

[zikunz]

@Anke

Some basics on Android storage system

Thank you, that is such a helpful reference! I will read through it.

[Anke]

One more thing:
In App Inventor, permissions are declared in the Manifest as soon as they are requested in the corresponding blocks. It doesn't matter whether they are actually requested; it's sufficient that they are present somewhere throughout the block area.

So these blocks

declare the following permission in the Manifest:

    <uses-permission android:name="android.permission.READ_MEDIA_AUDIO"/>
    <uses-permission android:name="android.permission.INTERNET"/>
    <uses-permission android:name="android.permission.READ_MEDIA_IMAGES"/>
    <uses-permission android:name="android.permission.CAMERA"/>
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>
    <uses-permission android:maxSdkVersion="29" android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>

So we don't need to worry about declaring the permissions, but only about knowing exactly what permissions are required. However, there's no getting around that.

[zikunz]

Thank you for explaining that! : )

[Anke]

And one more clarification:

1. Of course, my statements only apply insofar as access is to files either from the assets or the PrivateDir.

2. On devices with Android ≤ 10 (API 29) and ≥ 4.4 (API 19), READ_/WRITE_EXTERNAL_STORAGE must always be requested when accessing files from external storage (excluding the ASD).

3. On devices with Android < 4.4 (API < 19), however, storage permission must also be requested (more precisely, it must only be declared in the Manifest, because permission is then granted at install-time) when accessing files in ASD. Strictly speaking, requesting WRITE_EXTERNAL_STORAGE is sufficient, as this implicitly also grants READ_EXTERNAL_STORAGE.

4. However, the request for permissions will only be visible to the user if, firstly, it involves dangerous permissions and occurs on devices with Android ≥ 6 (API ≥ 23, i.e., after the introduction of runtime permissions).

However, since some components and many extensions require a minSdkVersion ≥ 21 (Android 5) and declare this in the Manifest, point 3 is usually not relevant.

[zikunz]

Got it! : )