android.os.FileUriExposedException: file:///... exposed beyond app through Intent.getData() means the app sent a file:// URI outside its process through an Intent or related cross-app flow. Android throws this diagnostic exception for apps targeting Android N/API level 24 or higher. The safest first action is to inspect Intent data, EXTRA_STREAM, ClipData, and any camera output URI for the remaining file:// value before changing provider settings.

What android.os.FileUriExposedException means

The exception applies to cross-app file exposure, not every Android file-access failure. It commonly appears in ACTION_VIEW, ACTION_SEND, ACTION_SEND_MULTIPLE, camera capture, attachment, printing, and share-sheet flows.

The exception was added in API level 24 and is thrown for apps targeting Android N or higher. The device’s Android version and the app’s targetSdkVersion are related conditions but are not interchangeable. The Android FileUriExposedException reference identifies the supported replacement as a content:// URI with temporary access for the receiving app.

Absence of the exception under another SDK configuration does not make file:// sharing safe. Android describes the exception as diagnostic rather than a security mechanism by itself.

Find the file:// URI that is leaving the app

When this applies: Perform this inspection before configuring FileProvider, including when the message ends with Intent.getData() or ClipData.Item.getUri().

Prerequisites: The exception text and the source for the outgoing Intent flow.

  1. Inspect the URI printed in the exception and confirm that its scheme is file.
  2. Review the application frames immediately before the exception to locate where the outgoing URI is created or attached.
  3. Check for Uri.fromFile() and parsing of a value beginning with file://.
  4. Inspect Intent data, EXTRA_STREAM, every ClipData item, and any camera output URI independently.
  5. Record the source and actual location of the file. Those details determine whether an existing authorized URI or FileProvider is appropriate.

Expected result: You identify every file:// URI in the failing flow and the point where each URI enters the Intent.

Risk and warning: This is a read-only diagnostic step. Do not assume changing only Intent data is sufficient if another URI-bearing field remains. Whether ClipData is involved must be confirmed by inspecting the actual Intent.

Choose the correct content URI source

When this fix applies: Use this route when the source already supplies an authorized content:// URI, such as a user-selected document or shared media item.

Prerequisites: Confirm that the existing URI remains authorized for the intended operation.

  1. Preserve the existing content:// URI instead of converting it into a filesystem path.
  2. Use the Storage Access Framework for user-selected documents.
  3. Use an appropriate MediaStore URI for shared media.
  4. Place that authorized URI into the required Intent field and continue to the temporary-permission checks below.

Expected result: The cross-app flow retains an authorized content:// URI without introducing a new FileProvider.

Risk and rollback: Risk is low. If the source cannot provide an authorized URI suitable for the operation, use FileProvider only when the app owns the file. Do not convert every path through FileProvider by default.

Configure AndroidX FileProvider in the manifest

When this fix applies: Use AndroidX FileProvider when the app owns a file and must expose it to another app.

Prerequisites: AndroidX FileProvider must be available, you must control the manifest, and you must be able to create a provider-paths XML resource. The exact authority is app-specific.

  1. Declare a provider whose android:name is FileProvider or the app’s FileProvider subclass.
  2. Set android:authorities to an app-specific authority.
  3. Set android:exported="false".
  4. Set android:grantUriPermissions="true".
  5. Add the FileProvider metadata entry that references the provider-paths XML resource.
  6. Confirm that the authority used later to generate the URI exactly matches the manifest authority.

The AndroidX FileProvider documentation supports this provider model and its temporary URI grants.

Expected result: The app has a non-exported provider capable of generating authorized content:// URIs for configured files.

Risk and rollback: Risk is low. Remove the provider and its metadata if the sharing feature is removed. Do not publish or copy a universal authority value because it must match the app’s configuration.

Limit file_paths XML to the files that must be shared

When this fix applies: Complete this step whenever FileProvider is used.

Prerequisites: Know the exact directory containing the file that must be shared.

  1. Define only the directory or directories required by the sharing feature.
  2. Prefer the narrowest directory that still contains the intended file.
  3. Avoid broad roots that include unrelated app or shared-storage files.
  4. Verify that the file resolves inside one of the configured roots before generating its content URI.

The precise XML entry cannot be universal because it depends on where the app stores the file. Android’s Android 7.0 file URI exposure changes recommend the FileProvider migration rather than continued file URI exposure.

Expected result: FileProvider can resolve the intended file while unrelated locations remain outside the provider’s configured scope.

Risk and rollback: Risk is medium because an overly broad root can expose more files than intended. Tighten the paths XML if review or testing shows excessive coverage; do not broaden it merely to bypass a configured-root failure.

Replace file:// and grant only the required temporary access

Create and attach the FileProvider content URI

When this fix applies: Use it after the manifest authority and narrow provider paths are configured for an app-owned file.

Prerequisites: The file must be inside an allowed provider root, and the URI-generation authority must match the manifest.

  1. Create the URI with FileProvider instead of Uri.fromFile() or a manually constructed file:// value.
  2. Put the resulting content:// URI in Intent data, EXTRA_STREAM, or the camera output field required by the existing flow.
  3. For multiple files, replace every exposed URI rather than only the first item.
  4. Inspect ClipData and any other URI-bearing field so the old file URI is not retained elsewhere.

Expected result: The outgoing Intent carries FileProvider content:// URIs instead of file:// URIs.

Risk and rollback: Risk is low and this operation does not delete the file. Do not restore cross-app file:// sharing in production; the previous URI source is suitable only for isolated local debugging that does not expose the URI.

Grant temporary URI permissions

When this fix applies: Use temporary grants when the receiving app must read or modify the content referenced by the Intent.

Prerequisites: The Intent must carry a valid content:// URI, and the receiver’s required access level must be known.

  1. Add FLAG_GRANT_READ_URI_PERMISSION when the receiver must read the file.
  2. Add FLAG_GRANT_WRITE_URI_PERMISSION only when the receiver must modify the file.
  3. Attach the URI through ClipData when that is needed for permission propagation in the supported flow.
  4. Do not add broader filesystem permissions or write access unrelated to the operation.

Expected result: The receiver obtains the minimum temporary access required while the provider remains non-exported.

Risk and rollback: Risk is low when access is limited. Remove write or read grant flags when the receiver no longer requires that capability. ClipData propagation is flow-specific and must be tested on the supported Android versions.

Verify the receiving app can access the content URI

When this applies: Verify the complete flow after replacing the URI and applying temporary grants.

Prerequisites: The intended receiving component must be available for testing.

  1. Confirm that every outgoing URI uses the content scheme.
  2. Confirm that the generated URI authority exactly matches the provider authority declared in the manifest.
  3. Confirm that the file resides inside a configured provider root.
  4. Recheck Intent data, EXTRA_STREAM, ClipData, and output URIs for any remaining file:// value.
  5. Test the actual receiving app with read permission and add write permission only if modification is required.
  6. Confirm that the receiver can perform the intended operation without broadening the provider root or permissions.

Expected result: The outgoing flow no longer exposes a file URI, and the receiving component can access the authorized content URI with the minimum required grant. This must be confirmed by testing; changing the scheme alone does not guarantee receiver access.

Risk and warning: Verification is low risk. If the original exception is gone but access still fails, manually check the authority, provider metadata, configured paths, URI grants, and actual file location. Do not suppress detection with StrictMode.VmPolicy, lower targetSdkVersion, expose broad roots, or grant write access by default. Those actions hide or weaken the problem rather than repairing the cross-app sharing design.