Find the component and its source
Inspect the build error and merged-manifest report. Determine whether the component comes from your app or a dependency. Modern target requirements make explicit export decisions especially important for components with intent filters.
The exported-component guidance and merger documentation explain the relevant declarations and source relationships.
Choose the value by contract
| Component | Typical decision to investigate |
|---|---|
| Launcher activity | External launch is intentional |
| Private internal activity | Keep unexported unless a documented integration requires otherwise |
| Public deep-link handler | Export intentionally, validate input and protect sensitive operations |
| Internal service or receiver | Avoid external access unless required |
| Library component | Consult the current library version and documented integration |
These are review directions, not rules that replace understanding the component's function.
Patch the right source
For your own component, add the explicit attribute in the appropriate manifest. For a library component, first check whether an updated compatible dependency already fixes the declaration. A local merge override can be appropriate, but should be documented and tested against the library's expected behavior.
Do not remove an intent filter just to avoid the requirement if the app relies on that route for launch or integration.
Test external and internal entry
Verify that legitimate launch and link flows still work. For sensitive components, test direct entry with missing or malformed data using an authorized test setup. Authentication on a previous screen does not protect a component that can be reached independently.
Inspect the release artifact
APKLint's Exported Activity Checker can help review explicit declarations and exposed components. It cannot determine every business authorization rule. Confirm the final merged manifest and close the issue with a test showing both intended access and rejection of unintended use.
Make the launcher and internal entry points explicit
Suppose a build reports a missing exported attribute on the launcher activity and on a library receiver. These declarations need separate decisions. The launcher is intended to be reachable from outside the application's process through the launcher contract. The receiver may be internal or may implement a documented external integration; its purpose determines the appropriate exposure.
The Android 12 target-behavior guidance specifies the explicit declaration requirement for activities, services and receivers with intent filters. Adding true everywhere can make the build pass while exposing components that were never designed to accept untrusted calls.
Review the dependency's intended contract before overriding it
Find the receiver's source in the manifest-merger report and check the dependency version's supported integration. Prefer a compatible upstream fix when available. If a local override is required, document the exact component and why the selected value preserves its contract. Verify the final merged result rather than assuming the override won.
For an externally reachable deep-link activity, validate action, URI and supplied arguments before using them. Recheck authentication and data ownership inside the destination operation. A user having passed through an authenticated home screen earlier does not protect an activity that can be opened directly. Keep validation in the destination's actual execution path so alternate entry routes cannot accidentally skip the check.
Test launcher entry, internal navigation and the documented external integration on the release candidate. In an authorized test setup, try a direct call with missing and malformed arguments and confirm a deliberate rejection without private output or unintended side effects. Check a legitimate caller too, since setting false can break a required integration while superficially reducing exposure. Keep the final manifest and test results with the change. A complete fix satisfies the explicit declaration requirement and preserves the intended access boundary; neither a green build nor a lower count of exported components proves that the application's external interfaces are correctly authorized.
Sources and further reading
- Android Developers: android:exported
- Android Developers: Merge multiple manifest files
- Android Developers: App manifest overview
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
