[image_picker] Fix/152156 non image files picked

[KristapsRokis]

[image_picker] fix(android): prevent non-image files from being picked in pickMedia (Fixes #152156)

This PR fixes an issue where ImagePicker.pickMedia on Android allowed users to select non-media files, even when the intent should have restricted the selection to image and video MIME types.

What this PR changes

• Updates the Android implementation of pickMedia to explicitly limit the intent’s MIME types to image/* and video/*.

Why this change is needed

Prior to this fix, users could inadvertently pick files outside the intended scope (e.g., PDFs ).

Before / After

Before:

• User could pick PDFs, or any file type when invoking pickMedia.

After:

• Only media files can be selected on Android.

Fixes #152156 - flutter/flutter#152156

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or I have commented below to indicate which version change exemption this PR falls under¹.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or I have commented below to indicate which CHANGELOG exemption this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the gemini-code-assist bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩² ↩³

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests or get an explicit test exemption before merging.

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. If you believe this PR qualifies for a test exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!). The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group.

[gemini-code-assist]

Code Review

This pull request correctly fixes an issue on Android where ImagePicker.pickMedia would allow selecting files of any type. The change replaces a non-standard intent extra key with the correct Intent.EXTRA_MIME_TYPES. The fix is correct and the related CHANGELOG.md and pubspec.yaml updates are appropriate. I've added one comment suggesting the addition of a unit test to prevent future regressions of this behavior, in line with the repository's testing guidelines.

[gemini-code-assist]

This change correctly fixes the issue by using the standard Intent.EXTRA_MIME_TYPES.

To ensure this functionality is covered against future regressions, please consider adding a unit test.¹ A test could verify that when usePhotoPicker is false, the launched Intent has the correct action, type, and EXTRA_MIME_TYPES set.

Here is an example of what such a test could look like in ImagePickerDelegateTest.java:

@Test
@Config(sdk = 30) // To test the 'else' branch for non-photo-picker
public void chooseMediaFromGallery_launchesIntentWithCorrectMimeTypes() {
    ImagePickerDelegate delegate = createDelegate();
    GeneralOptions generalOptions =
        new GeneralOptions.Builder().setAllowMultiple(false).setUsePhotoPicker(false).build();
    delegate.chooseMediaFromGallery(DEFAULT_MEDIA_OPTIONS, generalOptions, mockResult);

    ArgumentCaptor<Intent> intentCaptor = ArgumentCaptor.forClass(Intent.class);
    verify(mockActivity)
        .startActivityForResult(
            intentCaptor.capture(), eq(ImagePickerDelegate.REQUEST_CODE_CHOOSE_MEDIA_FROM_GALLERY));
    
    Intent intent = intentCaptor.getValue();
    assertEquals(Intent.ACTION_GET_CONTENT, intent.getAction());
    assertEquals("*/*", intent.getType());
    String[] mimeTypes = intent.getStringArrayExtra(Intent.EXTRA_MIME_TYPES);
    assertArrayEquals(new String[]{"video/*", "image/*"}, mimeTypes);
}

Style Guide References

Footnotes

1. The repository style guide states that code should be tested, and changes to plugin packages should have appropriate tests. (link) ↩

[stuartmorgan-g]

Thanks for the contribution!

• Updates the Android implementation of pickMedia to explicitly limit the intent’s MIME types to image/* and video/*.

The previous implementation also attempted to do this; do you have links to relevant docs explaining that this approach is correct, or other information about how you tested this?

Given that different devices will have different default handlers, and users can add non-default handlers, it may well be the case that some handlers look at one of these keys and others look at the other, for example.

• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under

This PR will need tests before it can be reviewed. Please mark as Ready for Review once the tests have been added.

[KristapsRokis]

The official Android documentation mentions EXTRA_MIME_TYPES only in connection with ACTION_OPEN_DOCUMENT and ACTION_CREATE_DOCUMENT, not with ACTION_GET_CONTENT.

https://developer.android.com/guide/components/intents-common#OpenFile

But it is recognized by system pickers when used. In cases where a picker doesn’t honor this extra, the intent should fall back to the primary MIME type defined via setType(), as it currently does in production with the existing CONTENT_TYPE.

Testing was done only on a few real devices, all of those supported this picker version.

It may be important to add that, with these changes, the Android Photo picker is shown by default, with an additional option to browse all files, where only media is allowed.

[stuartmorgan-g]

But it is recognized by system pickers when used.

This is just an assertion of the implicit claim of the PR, which is that "system pickers" (all of them?) do recognize EXTRA_MIME_TYPES, and don't recognize "CONTENT_TYPE". My question is how you determined that. If the source of this claim isn't documentation, what is the source?

Imagine for the sake of argument that the reality actually that of the two most common OEM default pickers, one recognizes only EXTRA_MIME_TYPES and one only recognizes "CONTENT_TYPE". If the current implementation were due to someone only testing the latter, and your implementation were due to you only testing the former, then if we land this we will regress a bunch of people. If one of those people only tests their use case, and makes a PR to fix it, then they would make exactly the opposite assertions that you are making here.

In order to avoid that, we need to understand (and record) what the basis of the claims in PRs is, rather than just accept them without evidence.

In cases where a picker doesn’t honor this extra, the intent should fall back to the primary MIME type defined via setType(),

Yes, but that doesn't actually have the desired behavior, so that's not a good fallback.

as it currently does in production with the existing CONTENT_TYPE. [...] Testing was done only on a few real devices, all of those supported this picker version.

If you only tested one specific picker, how do you know that there are not production devices that use "CONTENT_TYPE", such that removing that extra will not regress those devices?

[KristapsRokis]

Now I understand. All of these assumptions came from tests I ran on real devices and emulators — Pixel 7 (Android 14), Pixel 8 Pro (Android 16), and Samsung Galaxy A12 (Android 12) — and from the fact that I couldn’t find any official Android documentation mentioning CONTENT_TYPE.

I’m afraid I don’t have any additional data or evidence that can guarantee this works on all pickers beyond those tests.

I’m open to suggestions on how to handle this more reliably or to broaden testing if needed.

Maybe the safest approach would be to support both EXTRA_MIME_TYPES and CONTENT_TYPE. On my test devices, providing both produced the expected behavior.
I understand that this is still based on assumptions and a very small set of tests, but without any documentation describing these extra keys, it feels like there is nothing we can do