Not possible to get results from file picker on some phones

[embray]

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 <input type="file"> 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 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/*:

        <activity-alias
            android:name="com.android.providers.media.photopicker.PhotoPickerGetContentActivity"
            android:targetActivity="com.android.providers.media.photopicker.PhotoPickerActivity"
            android:exported="true"
            android:excludeFromRecents="true"
            android:enabled="false">
            <intent-filter>
                <action android:name="android.intent.action.GET_CONTENT" />
                <category android:name="android.intent.category.OPENABLE" />
                <category android:name="android.intent.category.DEFAULT" />
                <data android:mimeType="image/*" />
                <data android:mimeType="video/*" />
            </intent-filter>
        </activity-alias>

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 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 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
• I updated all Cordova tooling to most recent version
• I included all the necessary information above

[dianasotirova]

+1

[alexisGandar]

Maybe this issue is related to #1530
Switching the cordova config AndroidLaunchMode from singleInstance to singleTask did the trick for me.

[embray]

@alexisGandar Interesting; I thought that seemed a bit sketchy but this old stack overflow answer offers a tantalizing clue: apparently when you launch a task with singleInstance it OR's launchFlags |= Intent.FLAG_ACTIVITY_NEW_TASK into its stored flags. This would explain where then FLAG_ACTIVITY_NEW_TASK is coming from further down in the media gallery UI code...