How to fix exported Android components (activities, services, receivers, providers)
An exported component with no permission is callable by any app on the device — a common IPC, privilege-escalation and data-leak vector. Here's how to lock them down.
Last updated 2026-09-07
android:exported="false" unless the component genuinely needs to be public; gate the ones that do with a signature-level permission, and scope ContentProvider URI grants tightly.Read in context. These instructions need to be adapted to your app and platform version. New scans provide static detections; they do not establish current backend access. Current methodology.
What "exported" means
A component is exported if android:exported="true", or (on apps targeting below API 31) if it declares an <intent-filter> and doesn't set exported at all — the implicit default that has burned many apps. Since Android 12 (API 31) you must set it explicitly, which is why raising your targetSdk is itself a fix.
The risks by component type
- Activities — task hijacking / StrandHogg, intent redirection, exposing internal screens.
- Services — an unprotected exported service can be driven by any app (e.g. to perform privileged actions on its behalf).
- Broadcast receivers — spoofed broadcasts; a high-priority exported receiver can intercept or abort system events.
- Content providers — the sharpest one: an exported provider without permission (or with loose
grantUriPermissions) can leak or corrupt data, and path-traversal via a FileProvider can read arbitrary files.
The fix
- Default to
android:exported="false"on every component that doesn't need to be reachable by other apps. - For ones that must be public, require a permission: define a custom permission with
android:protectionLevel="signature"and set it on the component — only apps signed with your key can call it. - For ContentProviders, set
android:exported="false", or scope access with narrow<path-permission>/grantUriPermissionsand validate every incoming URI. - For deep links, prefer verified App Links (
android:autoVerify="true"+ a hosted assetlinks.json) over unverified custom schemes an attacker can register.
This maps to MASVS-PLATFORM-1 and CWE-926 (Improper Export of Android Components).
Frequently asked questions
How do I tell which components are exported?
Read the merged manifest (Android Studio → Merged Manifest, or decompile the APK) and list every activity/service/receiver/provider with exported=true or an intent-filter and no explicit exported. A scan flags exported components without a permission guard.
Is exporting always bad?
No — launchers, share targets, App Links and inter-app integrations need it. The risk is exporting without a permission something that handles sensitive data or actions. Export deliberately, and guard it.
What about deep links?
A browsable deep link makes the activity reachable from the web. Use verified App Links so only your domain triggers it, and never trust the incoming intent's data without validation.