How to Fix android:exported Errors in Android 12 Manifest Files

By the end of this page, you will understand why Android 12 requires android:exported, which components must define it, how manifest merging affects the final result, and how to find the real component causing the error when you already updated part of the manifest.

What android:exported means

android:exported tells Android whether a component can be launched by other apps.

It applies to components such as:

• activity
• service
• receiver
• sometimes other manifest-declared app entry points

Example meanings:

• android:exported="true" → other apps can start or interact with this component if allowed
• android:exported="false" → only your own app can use it directly

Why Android 12 made this required

Starting with apps targeting Android 12 (API 31) and above, any component that has an intent-filter must explicitly declare android:exported.

This rule exists because components with intent-filter are possible entry points into your app. Android now requires developers to state clearly whether those entry points are public or private.

Why your app can still fail even after updating many activities

A common mistake is assuming the error refers only to the manifest file you are currently looking at.

In real Android projects, the final manifest is built by :

Think of your app manifest as a building directory.

Each component is like a room:

• an activity is a room users can enter
• a service is a room where background work happens
• a receiver is a room that reacts when something happens

An intent-filter is like putting a sign outside the building saying:

• "Open this room for launch"
• "Send files here"
• "Open links here"

In Android 12+, if you put up that sign, Android asks:

Should people outside the building be allowed in or not?

That is what android:exported answers.

• true = yes, this room is visible from outside
• false = no, this room is internal only

If you do not answer, Android refuses to build the app because the entry point is ambiguous.

Basic syntax

Activity

<activity
    android:name=".ui.SplashActivity"
    android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

Service

<service
    android:name=".services.ContactChooserTargetService"
    android:permission="android.permission.BIND_CHOOSER_TARGET_SERVICE"
    android:exported="true">
    <intent-filter>
        <action android:name="android.service.chooser.ChooserTargetService" />
    </intent-filter>
</service>

Broadcast receiver

Small example

Suppose you have two manifest files.

Main manifest

<application>
    <activity
        android:name=".MainActivity"
        android:exported="true">
        <intent-filter>
            <action android:name="android.intent.action.MAIN" />
            <category android:name="android.intent.category.LAUNCHER" />
        </intent-filter>
    </activity>
</application>

Flavor manifest

<application>
    <activity
        android:name=".ShareActivity">
        <intent-filter>
            <action android:name="android.intent.action.SEND" />
            <category android:name= />
            
        
    

Where this matters in real apps

Launcher activities

Your app's launcher screen usually has:

• MAIN
• LAUNCHER

That activity must normally be:

android:exported="true"

Deep linking

If your app opens web links such as:

• https://example.com/...
• custom schemes like myapp://...

the responsible activity needs an intent-filter, which usually means it must be exported.

Share targets

If your app appears in Android's Share menu, the receiving activity often uses SEND or SEND_MULTIPLE, so it is typically exported.

Boot receivers

A receiver that listens for BOOT_COMPLETED must be visible to the system, so it usually needs:

android:exported="true"

Internal screens

Activities opened only from inside your own app usually do need an , and often should be:

How developers handle this in real projects

1. Explicitly set android:exported on all entry points

Teams often make this a code review rule:

• every component with intent-filter must declare android:exported
• avoid relying on old defaults

2. Keep internal components private

If an activity does not need to be launched from outside the app:

• remove unnecessary intent-filter
• set android:exported="false"

This reduces accidental exposure.

3. Use merged manifest inspection during debugging

When build variants, product flavors, or libraries are involved, developers check:

• src/main/AndroidManifest.xml
• src/debug/...
• src/release/...
• flavor manifests
• third-party library manifests
• Android Studio's Merged Manifest tab

4. Treat exported components as public API

If a component is exported, developers usually add:

• input validation
• permission checks
• safe intent parsing
• guard clauses against missing extras

1. Updating only one manifest file

In multi-flavor Android projects, there may be several manifest files.

Broken assumption

"I already added android:exported everywhere."

But only the main manifest was updated.

Fix

Check all manifests used by the selected build variant.

2. Forgetting that services and receivers also count

Beginners often update only activities.

Broken code

<receiver android:name=".BootReceiver">
    <intent-filter>
        <action android:name="android.intent.action.BOOT_COMPLETED" />
    </intent-filter>
</receiver>

Fix

<receiver
    android:name=".BootReceiver"
    android:exported="true">
    <intent-filter>
        <action = />
    

android:exported="true" vs android:exported="false"

Component with intent filter vs without intent filter

Quick rules

• Targeting Android 12+ (targetSdkVersion 31 or higher)?
• Any activity, service, or receiver with an intent-filter must explicitly declare android:exported.

Common values

android:exported="true"
android:exported="false"

Usually use true for

• launcher activities
• deep link handlers
• share targets
• broadcast receivers handling system intents
• services intended for system or external interaction

Usually use false for

• internal-only activities
• private services
• internal receivers

Debug checklist

1. Open Merged Manifest.
2. Search for intent-filter.
3. For each matching component, confirm android:exported exists.
4. Check:
   • main manifest
   • flavor manifests
   • debug/release manifests

Why do I get android:exported errors only after upgrading to Android 12?

Because Android 12 introduced a stricter rule for apps targeting API 31+: components with intent-filter must explicitly declare android:exported.

Does every activity need android:exported?

Not necessarily. The Android 12 requirement applies specifically to components with intent-filter. Still, being explicit can improve clarity.

Should I set android:exported="true" on all activities?

No. Only components that should be reachable from outside your app should be exported. Internal components should usually be false.

Why does the build still fail even though I updated my main manifest?

Because Android merges multiple manifests. Another manifest file or a library manifest may still contain a component missing android:exported.

How can I find the exact component causing the error?

Use Android Studio's Merged Manifest view and search for components with intent-filter but no android:exported.

Do services and receivers also need this attribute?

Yes. Activities, services, and receivers with intent-filter must declare it when targeting Android 12+.

• AndroidManifest.xml — This is where components, permissions, and app entry points are declared.
• Manifest merging — Android combines multiple manifest files, which is central to this error.
• Intent filters — The Android 12 rule is triggered when a component declares one.
• Activities — Many exported errors involve launcher or deep-link activities.
• Services — Services with intent filters also need explicit export settings.
• Broadcast receivers — Receivers listening for system broadcasts are common sources of this issue.
• Deep links — Deep-link activities are often intentionally exported.
• Android build variants — Different product flavors and build types can contribute separate manifest files.
• Target SDK version — This behavior changes when the app targets Android 12 or higher.
• Android Studio Merged Manifest view — This is the main debugging tool for finding the real source of the error.