apache / apache/cordova-android
Not possible to get results from file picker on some phones
- Dominant language
- JavaScript
- Stars
- 3.8k
- Forks
- 1.6k
- Avg merge
- 16h 18m
- Merged PRs (30d)
- 11
Description
# Bug Report
Not 100% sure if this is really a problem for cordova to solve though it does affect cordova users. In my application when the file picker is launched from the web view via an `` it normally works, but I found that on some devices it never returns a result. I'm also not an Android expert so I'm not sure what a good workaround would be.
After some investigation I concluded that it's due to the recent-ish introduction of the new photo picker app in Android: https://android-developers.googleblog.com/2023/04/photo-picker-everywhere.html Specifically the mention of `GET_CONTENT` takeover at the bottom.
What results is that the DocumentsUI file picker is started in a new task, and can't return results to the cordova app. Read on for more details.
This is also a little bit like #1536 but not the same because the app is not being killed by the OS.
## Problem
### What is expected to happen?
Normally when a file chooser is requested by the browser, `SystemWebChromeClient.onShowFileChooser` is called, and a new `GET_CONTENT` intent is [created](https://github.com/apache/cordova-android/blob/c9e7c5998635ad86412c5e8ef90df357a1676dcf/framework/src/org/apache/cordova/engine/SystemWebChromeClient.java#L221) and an activity is started to get the result of selected files.
How this intent is handled depends on the Android version and any other apps installed with an intent filter for `GET_CONTENT`, but since some time it is by default handled by `com.android.documentsui` which is the system file picker.
### What does actually happen?
The new photo picker, while well-intentioned, throws a wrench into this. It is installed with an intent-filter for `GET_CONTENT` if the MIME type filter matches `image/*` or `video/*`:
```
```
Unfortunately, if the intent for the file chooser is `*/*` this is also picked up by the photo picker. In the Android 13 release of the new photo picker there is [some code](https://android.googlesource.com/platform/packages/providers/MediaProvider/+/android13-mainline-media-release/src/com/android/providers/media/photopicker/PhotoPickerActivity.java#133) that checks if the intent matches exactly `images/*` and/or `videos/*`. If it's anything else (e.g. I want users to be able to select PDF files), it re-routes to the old DocumentsUI.
I can confirm this from the presence of the log message:
```
PhotoPickerActivity: Launch DocumentsUI and finish picker
```
This then creates a new `GET_CONTENT` intent targeted at DocumentsUI:
```
ActivityTaskManager: START u0 {act=android.intent.action.GET_CONTENT cat=[android.intent.category.OPENABLE] typ=*/* flg=0x13800000 cmp=com.google.android.doc
umentsui/com.android.documentsui.picker.PickActivity (has extras)}
```
For reasons I *cannot* understand, the new Intent appears to have the [FLAG_ACTIVITY_NEW_TASK](https://developer.android.com/reference/android/content/Intent#FLAG_ACTIVITY_NEW_TASK) flag set, which results in the following log message:
```
ActivityTaskManager: Activity is launching as a new task, so cancelling activity result
```
And indeed when Cordova resumes the callback gets a `Activity.RESULT_OK` but with `intent == null`, so no results are returned.
### Environment, Platform, Device
Pixel 4
Android version: 13
Google Play system update: July 1, 2023
### Version information
Cordova: 12.0.0 (cordova-lib@12.0.1)
cordova-android: 12.0.0
## Checklist
- [x ] I searched for existing GitHub issues
- [x] I updated all Cordova tooling to most recent version
- [x] I included all the necessary information above
Contributor guide
Research direction
Start at SystemWebChromeClient.onShowFileChooser in framework/src/org/apache/cordova/engine/SystemWebChromeClient.java, especially the GET_CONTENT intent creation around the referenced line. Reproduce the file-selection flow on a Pixel 4 running Android 13 with image/video and */* MIME filters, then trace the activity-result callback. Done means selected files are returned instead of Activity.RESULT_OK with a null intent on affected devices.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, java
- Domain
- mobile-dev
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100