Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Return Content URI in saveMedia for Android #104

Open
stephan-fischer opened this issue Dec 13, 2024 · 1 comment
Open

feat: Return Content URI in saveMedia for Android #104

stephan-fischer opened this issue Dec 13, 2024 · 1 comment

Comments

@stephan-fischer
Copy link
Contributor

Description

Currently, the saveMedia method in the Capacitor-Media plugin returns only the file's absolute path (file://). However, Android restricts the use of file:// URIs for sharing files between apps, requiring a content:// URI instead. This feature request proposes adding support for returning a content:// URI when saving media on Android.


Use Case

  1. File Sharing Between Apps:

    • When media is saved via saveMedia, it is often shared with other apps. Returning a content:// URI would make it easier to share files securely without triggering a FileUriExposedException.
  2. Compliance with Android Scoped Storage:

    • content:// URIs align with Android's Scoped Storage policies, ensuring compatibility with modern Android versions.
  3. Reduce Overhead for Developers:

    • Currently, developers need to manually generate a content:// URI from the returned file path. Returning a content:// URI directly simplifies the workflow.

Suggested Implementation

Android Implementation

Modify the saveMedia method to return both the absolute file path (file://) and the content:// URI.

import androidx.core.content.FileProvider;

try {
    File expFile = copyFile(inputFile, albumDir, fileName);
    scanPhoto(expFile);

    // Generate the content URI using FileProvider
    Uri contentUri = FileProvider.getUriForFile(
        getContext(),
        getContext().getPackageName() + ".fileprovider",
        expFile
    );

    // Return both file path and content URI
    JSObject result = new JSObject();
    result.put("filePath", expFile.toString());  // Absolute file path
    result.put("contentUri", contentUri.toString());  // Content URI
    call.resolve(result);
} catch (RuntimeException e) {
    call.reject("Error saving media", e);
}

Example Return Value

When the method resolves successfully, the returned object could look like this:

{
  "filePath": "/storage/emulated/0/Android/media/com.example.app/Example/IMG_20241213_165249028.jpeg",
  "contentUri": "content://com.example.app.fileprovider/media_files/IMG_20241213_165249028.jpeg"
}

API Changes

No breaking changes are introduced. The existing filePath property remains, and a new property contentUri is added for additional functionality.


Expected Behavior

  • Existing functionality: The method continues to return the absolute file path (filePath) for backward compatibility.
  • New functionality: Adds the contentUri field to provide a content:// URI for better compatibility and ease of use.

Platform Support

  • Android: Full support for content:// URIs using FileProvider.
  • iOS: Not applicable, as iOS doesn't use content URIs.

Conclusion

Adding support for returning content:// URIs in saveMedia enhances the Capacitor-Media plugin by aligning it with modern Android storage policies. It simplifies file-sharing workflows for developers and ensures better compatibility with other apps and Android versions.

If you need further clarification or additional details, feel free to ask! 😊

@nkalupahana
Copy link
Collaborator

nkalupahana commented Dec 17, 2024

@stephan-fischer what specific use case are you trying to solve? I believe that the standard for apps accessing images from other apps is to use the Photo Picker API, but I might be misunderstanding what you're trying to accomplish here. I don't believe just using a content:// URL magically gives an app access to images that are scoped to another app, but again, might be missing something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants