Introduction

On modern Android, the usual way to turn a file path into a content URI is FileProvider. Direct file:// sharing is heavily restricted, so if you want to hand a file to another app, you normally expose it through a provider and use a content:// URI instead.

Use FileProvider for App Files

If the file belongs to your app, configure a FileProvider in the manifest:

1<provider
2    android:name="androidx.core.content.FileProvider"
3    android:authorities="${applicationId}.fileprovider"
4    android:exported="false"
5    android:grantUriPermissions="true">
6    <meta-data
7        android:name="android.support.FILE_PROVIDER_PATHS"
8        android:resource="@xml/file_paths" />
9</provider>

Then define the allowed paths in res/xml/file_paths.xml:

1<?xml version="1.0" encoding="utf-8"?>
2<paths xmlns:android="http://schemas.android.com/apk/res/android">
3    <cache-path name="cache" path="." />
4    <files-path name="files" path="." />
5</paths>

Now you can convert a File to a content URI:

1import android.net.Uri
2import androidx.core.content.FileProvider
3import java.io.File
4
5fun fileToUri(file: File, context: Context): Uri {
6    return FileProvider.getUriForFile(
7        context,
8        "${context.packageName}.fileprovider",
9        file
10    )
11}

This is the standard answer when the file is inside your app's storage.

Grant Access When Sharing the URI

If you send the URI to another app, also grant temporary read permission:

1val uri = fileToUri(file, context)
2
3val intent = Intent(Intent.ACTION_VIEW).apply {
4    setDataAndType(uri, "image/png")
5    addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)
6}
7
8startActivity(intent)

Without the grant flag, the other app may receive the URI but still fail to open the file.

When the File Is Already in MediaStore

If the file is part of shared media storage and indexed by the system, the right content URI may come from MediaStore rather than FileProvider. In that case, the path-to-URI problem is really a database lookup problem.

That distinction matters because not every filesystem path should be wrapped with FileProvider. FileProvider is for files your app is intentionally exposing. MediaStore URIs represent items already managed by the platform's media database.

Avoid Depending on Raw File Paths

Modern Android development increasingly works with URIs from the start. The Storage Access Framework, media pickers, and many sharing flows already return content:// URIs directly. If your code keeps converting back and forth between path strings and URIs, that is often a sign the design is fighting the platform.

Whenever possible:

• keep the URI you were given
• use ContentResolver to read it
• only create a file path when you truly control the file locally

That approach usually avoids the hardest Android storage edge cases.

Read the URI Through ContentResolver

Once you have a content URI, use the resolver instead of converting it back to a filesystem path:

1context.contentResolver.openInputStream(uri)?.use { input ->
2    val bytes = input.readBytes()
3    println("Read ${bytes.size} bytes")
4}

That keeps the code aligned with how Android expects shared content to be accessed.

Common Pitfalls

• Trying to share a raw file:// URI on modern Android. Other apps often cannot access it, and the platform may block the flow.
• Forgetting to configure the FileProvider authority and allowed paths correctly in the manifest and XML resource.
• Building a content URI string by hand instead of asking FileProvider to generate it.
• Omitting FLAG_GRANT_READ_URI_PERMISSION when handing the URI to another app.
• Treating every filesystem path as if it belongs in MediaStore. Some files are app-private and should be exposed only through your own provider.

Summary

• For app-owned files, use FileProvider.getUriForFile to create a content URI.
• Configure the provider in the manifest and define safe file paths in file_paths.xml.
• Grant temporary permissions when sharing the URI with another app.
• Use MediaStore only when the file is actually represented there.
• Prefer working with content URIs directly instead of converting everything back to raw file paths.