[bug] Android file picker does not return actual file name

[velocitysystems]

Describe the problem

On Android, when using plugin-dialog to select a file, the API returns only a content resolver identifier (URI) rather than the actual file name. This prevents a user from performing import operations that depend on the file’s name.

1. Open the file picker via the Tauri plugin on an Android device.
2. Select any file (e.g. example.mp4).
3. Inspect the returned payload.

Note:

• If we pick a file from local storage, then we have the name like a typical URL
• If we pick a file from cloud storage (e.g. Google Drive, possibly others), then we don't have the name

Describe the solution you'd like

The plugin should return both:

• A valid URI/path that can be used for reading or copying the file.
• The actual file name (e.g. "example.mp4").

Alternatives considered

N/A

Related

#3030
#933
#2749

[velocitysystems]

@FabianLars We'd like to propose this enhancement to the open() method:

1. Enhance FilePickerResponse

Current:

struct FilePickerResponse {
    files: Vec<FilePath>,
}

Proposed:

struct FileResponse {
    name: String,      // e.g., "example.mp4"
    path: FilePath,    // content resolver URI
}

struct FilePickerResponse {
    files: Vec<FileResponse>,
}

Cross-platform note: This change affects all platforms. While the name field is essential for Android (content URIs lack file names), it is redundant for iOS/desktop (file names are in the path). However a consistent API across platforms simplifies application code.

[lucasfernog]

Currently you can query this information separately via PathResolver::file_name (Rust side) and path.basename / path.extname (JS). I agree this should be added to the dialog API response, but I'm not sure we should break the API right now, I think it can wait until v3.

[velocitysystems]

Thanks @lucasfernog. Looks like PathResolver::file_name has the needed functionality but is this currently available JS-side? To avoid a breaking API change, what are your thoughts on implementing this as an additive change?

Later on in V3 we could then switch to using the Vec<FileInfo> return type and deprecate Vec<FilePath>.

Current:

struct FilePickerResponse {
    files: Vec<FilePath>,
}

Proposed (V2):

struct FileInfo {
    name: String,      // e.g., "example.mp4"
    path: FilePath,    // content resolver URI
    size: Option<u64>,
    mime_type: Option<String>
}

struct FilePickerResponse {
    files: Vec<FilePath>,
    file_infos: Vec<FileInfo>
}

[lucasfernog]

path.basename / path.extname leverage PathResolver::file_name internally: https://github.com/tauri-apps/tauri/blob/a27948585662db6da90aaef998a7a43efdb6f647/crates/tauri/src/path/plugin.rs#L185

we should then introduce another API, something like open2 (I hate it but it's what a lot of systems that must avoid breaking changes end up doing)

[velocitysystems]

Thanks, @lucasfernog. We’ve discussed this and are happy to use path.basename with the V2 API for now until we can update it in V3. I’ll leave this ticket open. Should we implement this now and target it for a v3.0 branch, or is it better to wait until v3.0 work is underway in the future?