fix: Android presents file picker for File block upload

[dcalhoun]

What?

Present the OS file picker when attempting to upload within the File block.

Why?

Fix the inability to upload files. Fix CMM-344. Fix #124.

How?

Use ACTION_GET_CONTENT rather than ACTION_PICK, as it appears to be a more
robust and appropriate intent for the use case.

Avoid passing along the empty acceptedTypes values from the web
implementation—e.g., [""]. It is not clear why this empty value is passed along.

Testing Instructions

1: File block allows uploading files

1. Insert a File block.
2. Tap Upload.
3. Verify the file uploads and attaches to the block.

2. Image/Video blocks filter by the appropriate MIME type

1. Insert a block with a specific file type--e.g, Image.
2. Tap Upload.
3. Verify the correct file types are available for selection, not other file
   types.

Accessibility Testing Instructions

N/A, no navigation changes.

Screenshots or screencast

N/A

[nbradbury]

@dcalhoun I set JPAndroid to use the local GutenbergKit build and pulled this branch. I do see that choosing to upload a file now shows the file picker and the appropriate pickers are shown for other media, but after choosing any upload, it fails to be attached to the post.

This is with a physical Pixel 8a, API 35. I tried three different sites with the same result, but nothing helpful appeared in logcat. I also duplicated the issue in an emulator.

image.mp4

[dcalhoun]

@nbradbury that outcome is surprising, and I am unable to reproduce. I do notice the button UI is your recording is misaligned. I'm guessing your local clone does not have a recent build output.

Will you try running make build within your GutenbergKit clone to generate new build output and retesting?

To elaborate, the GutenbergKit repo does not track Android build out in VCS. So, when you "set JPAndroid to use the local GutenbergKit build and pulled this branch," it could very well use old build output or have no build output at all (if you've never built the project).

Running make build will generate new build output for the Android app to load. Alternatively, you can use the make dev-server command to load build output from a dev server.

[nbradbury]

@dcalhoun Thanks for the elaboration, and sorry to be such a noob regarding this form of development! I tried running make build in the GutenbergKit folder, but that resulted in this error:

Cannot read property '@wordpress/api-fetch' of undefined

I've attached the debug log and a screenshot of the Terminal window, but I hate to waste your time tracking down my build issues. Is there a way I can test using a remote hash instead?

2025-05-14T13_07_05_130Z-debug.log

[dcalhoun]

@nbradbury the issue appears to be the issue you've encountered before (p1738080148509469/1738074782.197839-slack-C011BKNU1V5): using an incorrect Node.js version. From your log:

info using npm@6.9.0
info using node@v10.16.1

Before running any project commands, the shell session must be using the correct Node.js version. I believe you need to run nvm use in the GBK clone.

Is there a way I can test using a remote hash instead?

You can update the GutenbergKit version to reference a commit on a specific branch, much like many WP-Android PRs that include newer GBK builds.

[nbradbury]

Thanks @dcalhoun . I've made a note of the commands I need to run in order to use local builds, so hopefully I won't bother you again with this.

I did get make build to work after nvm use and testing image and video uploads worked fine. File uploads worked but what was inserted into the editor wasn't what I expected. It inserts an underlined file name with a "Download" button (?) next to it, but tapping either of those does nothing. This happens regardless of file type.

file.mp4

[dcalhoun]

File uploads worked but what was inserted into the editor wasn't what I expected. It inserts an underlined file name with a "Download" button (?) next to it, but tapping either of those does nothing.

@nbradbury this is expected—to some degree—as links within the editor's canvas universally disabled. If canvas links were not disabled, it would be difficult edit links, as tapping them would navigate to the link rather than moving the cursor to the edit point.

You can verify this existing behavior by performing the same steps in the production web editor in a browser using a cursor device—i.e., a laptop or desktop device.

[nbradbury]

Thanks for your patience with me while testing this. All good, merge when ready!