[webview_flutter] Add file chooser on Android

[fesp]

Description

Currently on Android nothing happens for <input type="file">. This PR solves that, allowing the user to choose a file and optionally use the camera.

Related Issues

flutter/flutter#27924

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
• All existing and new tests are passing.
• I updated/added relevant documentation (doc comments with ///).
• The analyzer (flutter analyze) does not report any problems on my PR.
• I read and followed the Flutter Style Guide.
• The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
• I updated CHANGELOG.md to add a description of the change.
• I signed the CLA.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
• No, this is not a breaking change.

[google-cla]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[fesp]

@googlebot I fixed it

[google-cla]

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[ditman]

Something weird happened with the rebase of this branch, I can see things that are already merged (like the move of camera to camera/camera). Do you mind rebasing this a little better, so we can see only the changes you worked on? Thanks!

[ditman]

Also: there's a file_selector plugin incoming; would it make more sense to add an Android version there? See this PR: #3140

[fesp]

Something weird happened with the rebase of this branch, I can see things that are already merged (like the move of camera to camera/camera). Do you mind rebasing this a little better, so we can see only the changes you worked on? Thanks!

Don't know what happened there, but thanks for pointing that out!

[fesp]

@ditman Not sure about the 'file_selector' plugin. Would that also cover taking a picture with the camera?

[ditman]

@ditman Not sure about the 'file_selector' plugin. Would that also cover taking a picture with the camera?

@fesp no, the one that lets you select a picture from the gallery, or take a new one is image_picker.

file_selector is just a generic open file (no "capture" attribute in web).

[fesp]

@ditman Can we use the image_picker plugin in webview_flutter (regarding dependencies)? The point of this PR is to mimic the behaviour that is standard on iOS. I mean, would it make sense to depend on another plugin just for Android?

The current implementation in this PR completely solves the issue we are facing in our app. On iOS we can upload an image (either using the camera or from the library), and with this PR the very same is now possible on Android. No other plugins are required to do this.

[ditman]

@fesp I misunderstood the intent of this PR. This is to enable the input type file when rendering a webview. The other plugins let you select a file in a normal flutter app (not within a webview). Thanks for the contrib!!

[stuartmorgan-g]

@firatcetiner Please do not approve PRs, as it serves no purpose and creates confusion. As our docs say, this is reserved for people with commit access.

[Aulig]

API 30 NOT Works.. but 28,29 works!!

Adding the following lines to AndroidManifest.xml also worked with API 30!

<queries>
    <package android:name="com.google.android.apps.photos" />
    <package android:name="com.google.android.apps.docs" />
    <package android:name="com.google.android.documentsui" />
</queries>

I'm using:

<queries>
    <!-- Needed so file upload can ask the user to take a photo/video to upload -->
    <intent>
        <action android:name="android.media.action.IMAGE_CAPTURE" />
    </intent>
</queries>

With that I get the option of using my camera to take a picture/video or pick a file using the file browser app (from where I could go to my gallery app).

Adding <package android:name="com.google.android.apps.photos" /> didn't offer me the Google Photos app either.

In general I think instead of depending on fixed package names it's better to use general intents, as not everyone uses the Google Photos/Docs/... app.

I tried

<intent>
    <action android:name="android.intent.action.GET_CONTENT" />
    <data android:mimeType="*/*" />
</intent>

but that didn't prompt me to use the gallery directly either. Maybe it'd work on other devices?

[stuartmorgan-g]

@fesp Are you planning on adding tests to this PR to move it forward? Are you still having issues running tests locally?

[fesp]

@fesp Are you planning on adding tests to this PR to move it forward? Are you still having issues running tests locally?

@stuartmorgan I'm sorry it is taking so long, but I'm still planning on getting this done. I'm able to run the tests and wrote one for this PR but didn't get it to work the first time. I'm very busy at the moment, but I'll try to find a moment to look into it a bit more.

[BeshoyAtef]

It's very helpful 👍 , thank you

[paresy]

We are also using this patch successfully. After #3325 got merged this ist the only missing piece for us! A big thumbs up for working on it! 😄 👍

[zhangweiwei0326]

Why hasn't it been fixed？

[renefloor]

After some conversations on the sidelines I want to create a different solution that is easier to test and maintain.
Some of the considerations can be found in this document: https://docs.google.com/document/d/1pcS1fxGw_Arug_V7PA4a-N9X1wS4jAHm9UUau77_ZYM

The solution might be depending on flutter/flutter/issues/94051

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat.

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.

[stuartmorgan-g]

Based on discussion in the document linked above, the way we plan to move forward with file selection is by exposing the callback, so that clients of the plugin can register whatever handler they like. That will avoid the problem of needing to permanently maintain what is essentially a second copy of plugins that we already need to maintain separately, and will give people more flexibility if they want to use different implementations. It also makes the permissions opt-in rather than required, which is also good for flexibility.

Once that's implemented, we can evaluate whether it's helpful to provide a default implementation of that public handler (e.g., using image_picker and an Android implementation of file_selector).

Given that direction, I'm going to close this. Thanks again for the contribution though!

[Aulig]

Is there an issue/a PR where the progress on implementing the above document can be followed?

[stuartmorgan-g]

The issue linked from the PR description is still the relevant issue.

[rashidotm]

Based on discussion in the document linked above,

@stuartmorgan I need to bring your attention that the referenced document is overwritten and its contents have changed. Have a look for yourself.

[stuartmorgan-g]

I don't own that document, so can't change it. The core conclusion from the discussion in the document is summarized above though.

[Shubhankt1]

Hi @fesp / @tneotia
I upgraded to webview_flutter:^3.0.1 and the file structure seems to be different now...
how do I get the same issue working in webview_flutter:^3.0.1 ??

@darshankawar cud you also please have a look?

[Shubhankt1]

@fesp

Guys could anyone help me with which patch I can use to get it working?

[rekire]

@stuartmorgan what is the current status of exposing the callbacks for handling the file uploads? If it is already done can you please link the relevant documentation?