What “android:exported needs to be explicitly specified” means

“Manifest merger failed: Apps targeting Android 12 and higher are required to specify an explicit value for android:exported when the corresponding component has an intent filter defined.” means the final manifest contains an activity, service, or broadcast receiver with an intent filter but without an explicit access setting. It applies when the app targets Android 12/API 31 or later.

The equivalent messages for an <activity>, <service>, or <receiver> are the same issue. android:exported controls whether other apps can launch that component. Do not set it to true simply to pass the build. First identify the exact component and source manifest in the merged output. See the official Android 12 exported-component requirement.

This guide is limited to activities, services, and receivers with intent filters. Content providers are not a routine equivalent variant of this Android 12 error.

Find the failing component and its owning manifest

Use manifest-merger output before changing your app manifest. The affected entry can come from the app module, a build variant, a test module, a generated manifest, or a third-party dependency.

  1. Open the affected module’s AndroidManifest.xml in Android Studio.
  2. Select Merged Manifest.
  3. Select the affected activity, service, or receiver.
  4. Use Merging Log and Manifest Sources to identify the manifest that contributes it.
  5. If needed, check the manifest-merger build report.
  6. Correct the owning manifest, or use a narrow higher-priority merge rule only when its prerequisites are met.

Expected result: you know the component type, its name, and the manifest source responsible for the missing or conflicting attribute. This is low risk and needs no runtime rollback; revert only a manifest change if later validation fails. Android documents the merged view, logs, sources, reports, and merge markers in its Android manifest merger documentation.

Choose the correct android:exported value

For a component you own or can edit, add an explicit value in its owning manifest, then rebuild the affected variant and inspect the final merged manifest.

Component purpose Appropriate value Reason
App launcher activity android:exported="true" The launcher is an external app entry point.
Intentionally external activity, service, or receiver android:exported="true" Use only when another app must invoke it.
Internal-only service android:exported="false" Prevents unnecessary external access.
Internal-only receiver android:exported="false" Prevents unnecessary external access.
  1. Open the manifest that owns the affected component.
  2. Add android:exported="true" only when external apps must reach it.
  3. Add android:exported="false" when it is internal-only.
  4. Rebuild the affected variant.
  5. Confirm the final Merged Manifest retains the reviewed value.

Risk: low for the manifest edit, but setting true exposes the component to external access. Intent filters do not by themselves provide sufficient access control for an exposed component. Review the security implications using Android exported-component security guidance. To roll back, remove or change only the added attribute and rebuild.

Fix the MAIN and LAUNCHER activity case

If the affected activity has an intent filter containing MAIN and LAUNCHER, it is the app entry point and should normally declare android:exported="true".

  1. Find the activity with the MAIN and LAUNCHER intent filter.
  2. Set android:exported="true" on that activity.
  3. Build the app.
  4. Install or run it and verify that the launcher icon opens the intended activity.

Expected result: the launcher activity has an explicit exported state and remains launchable. This does not resolve a separately named service or receiver failure. Risk is low; restore the previous declaration only if the activity is no longer a launcher entry point.

If the component comes from a dependency, test module, or generated manifest

If Merged Manifest shows that another input owns the component, do not assume your primary app manifest is the right place to edit. Diagnose the actual contributing dependency, transitive library, test module, build variant, or generated manifest.

Cautious option: if the source appears obsolete, check whether a compatible dependency update is available before maintaining a local override. An update may remove or correct the declaration, but this is not guaranteed and must be tested in the affected variant. Confirm that required dependency features still work and that the final merged manifest contains the intended value.

Do not remove a contributed component just to clear the error. It may be required by a library feature.

Use a narrow manifest-merger override only when required

Use an override only after Merged Manifest proves that a lower-priority manifest defines the same component and there is an actual exported-attribute conflict. The higher-priority declaration must identify the same component by android:name.

Override a reviewed exported value

  1. Declare the tools namespace in the higher-priority manifest.
  2. Declare the matching component with the intended android:exported value.
  3. Use tools:replace="android:exported" only for an actual attribute conflict.
  4. Inspect Merged Manifest to confirm the result.
  5. Rebuild and test the component’s intended entry path.

Risk: medium. An override can change external reachability. Roll back by removing the override component declaration and tools:replace, then rebuild.

Remove a proven-unneeded library component

  1. Verify that the component is not required by the dependency or an app feature.
  2. Add a matching component declaration in the higher-priority manifest.
  3. Apply tools:node="remove" to that component.
  4. Inspect Merged Manifest to confirm removal.
  5. Build the app and test dependency features that could use the removed component.

Risk: medium. Removing a component can break library behavior. Roll back by removing the tools:node="remove" declaration and rebuilding.

Verify the fix in the final manifest and app behavior

  • Confirm Merged Manifest shows an explicit, reviewed android:exported value on the affected component.
  • Build the affected variant successfully.
  • Test the intended entry path: launcher, deep link, service, or receiver behavior as applicable.
  • If a dependency entry changed, test dependency features that could invoke or depend on that component.
  • For an externally reachable component, manually review whether its callers need permission protection or caller validation in addition to exported state.

A successful build confirms the merge requirement is satisfied; it does not by itself prove the component is secure or behaves as intended. File URI sharing is a separate access-control issue: use the guidance to share files with FileProvider instead of exposing file URIs rather than broadly exporting components. Likewise, Android network security policy errors are separate from this manifest-merger failure.

Frequently asked questions

Should I set android:exported=”true” to fix this error?

No. Use true only when other apps must invoke the component. Use false for internal-only activities, services, and receivers, then verify the merged output.

Why does the error remain after I changed my launcher activity?

The failing component may be a different activity, service, or receiver, or it may come from a dependency, test module, variant, or generated manifest. Check Merged Manifest and its sources.

Can I use tools:replace=”android:exported”?

Only when a higher-priority manifest defines the same component and there is an actual exported-attribute conflict. Inspect the final merged result and test the component’s intended entry path.