How to Inspect and Configure the Android Intent Firewall Using ADB dumpsys activity intent-firewall

In the Android operating system, application components (Activities, Services, and Broadcast Receivers) communicate through asynchronous message objects known as Intents. While standard Android security models rely on manifest permissions (uses-permission) and component export attributes (android:exported="true"), malicious applications can exploit implicit intents, unvalidated deep links, or confused-deputy vulnerabilities to invoke internal application components or trigger unauthorized background operations.

To provide low-level, system-wide protection against unauthorized inter-app communications, the Android framework includes a built-in security subsystem: the Intent Firewall. Operating deep within the Activity Manager and Window Manager subsystems, the Intent Firewall evaluates incoming and outgoing intents against declarative XML rules before any target component is instantiated or code executes. Using Android Debug Bridge (ADB), security researchers, device administrators, and ROM developers can inspect the active rule set, deploy custom firewall definitions, and audit blocked intent attempts using dumpsys activity intent-firewall.

Understanding Android Intent Firewall Architecture

The Intent Firewall operates as a gatekeeper inside the Android system_server (specifically com.android.server.firewall.IntentFirewall). Whenever any process issues an intent through methods like startActivity(), startService(), or sendBroadcast(), the execution flow intercepts the intent before resolving the target package:

• Pre-Execution Interception: Evaluates intent attributes — including component name, action string, data URI schemes, MIME types, categories, and sender UID — against XML firewall rules.
• Enforcement Actions: Rules enforce three primary actions: allow (permits execution), block (drops the intent silently without notifying the sender), or log (emits an audit event to Android logcat while permitting execution).
• Storage Location: Persistent firewall rule files are stored within the privileged directory /data/system/ifw/ as standard XML files (e.g. /data/system/ifw/custom_rules.xml).
• Automated File Monitoring: The IntentFirewall daemon uses a FileObserver to monitor the /data/system/ifw/ directory. When a rule file is added, modified, or deleted, the firewall reloads and compiles rules in memory immediately without requiring a system reboot.

Connecting via ADB and Dumping Active Firewall Rules

Ensure Developer Options and USB Debugging are enabled on your test device or emulator. Connect via USB and verify ADB detection:

adb devices -l

To inspect the currently loaded rule set and verify firewall status, execute the following command:

adb shell dumpsys activity intent-firewall

On standard uncustomized retail devices without custom rules installed, the command returns an empty summary:

Intent Firewall:
  Activity rules: 0
  Broadcast rules: 0
  Service rules: 0

When custom rules are present, dumpsys activity intent-firewall outputs the parsed rule hierarchy, component filters, and active rule IDs.

Constructing Declarative Intent Firewall Rules (XML)

Intent firewall rules follow a strict XML schema. The root element is <rules>, containing child containers for <activity>, <broadcast>, and <service> blocks.

Consider a practical security scenario where an organization wants to block all external applications from launching an internal diagnostic activity (com.example.admin/.DiagnosticsActivity) while logging any unauthorized attempts.

Create a rule file named admin_lockdown.xml on your local workstation:

<rules>
    <!-- Rule to block unauthorized diagnostic activity launches -->
    <activity name="BlockAdminDiagnostics" block="true" log="true">
        <component-filter name="com.example.admin/.DiagnosticsActivity" />
        <!-- Permit only the system UID (1000) or internal app UID -->
        <not>
            <sender type="system" />
        </not>
    </activity>

    <!-- Rule to block malicious SMS broadcast interception -->
    <broadcast name="FilterSmsBroadcast" block="true" log="true">
        <action-filter name="android.provider.Telephony.SMS_RECEIVED" />
        <component-filter name="com.suspicious.spyware/.SmsReceiver" />
    </broadcast>
</rules>

Key rule attributes explained:

• block="true": Instructs the firewall to reject the intent dispatch.
• log="true": Outputs an IntentFirewall logcat record whenever the rule matches.
• <component-filter>: Matches the explicit destination package and component class.
• <not><sender type="system" /></not>: Ensures system-level invocations from Android OS are exempted while third-party apps are blocked.

Deploying Rules to /data/system/ifw/ via Root ADB Shell

Because the Intent Firewall resides in protected system memory, deploying rules requires root privileges (available on rooted development devices, Android Automotive head units, or standard AOSP/Google Play Development emulators).

Push the rule file to temporary storage and move it into the firewall directory:

# Push file to temporary directory
adb push admin_lockdown.xml /data/local/tmp/

# Open elevated shell and move into ifw directory
adb shell
su
mkdir -p /data/system/ifw
cp /data/local/tmp/admin_lockdown.xml /data/system/ifw/
chmod 644 /data/system/ifw/admin_lockdown.xml
chown system:system /data/system/ifw/admin_lockdown.xml
exit
exit

Verifying Loaded Rules with dumpsys

Immediately after copying the file, query dumpsys activity intent-firewall again to verify that the file observer compiled the rules:

adb shell dumpsys activity intent-firewall

The diagnostic dump will now report active rule counts and component mappings:

Intent Firewall:
  Activity rules: 1
    Rule: BlockAdminDiagnostics
      Filter: ComponentFilter{com.example.admin/.DiagnosticsActivity}
      Action: block=true log=true
  Broadcast rules: 1
    Rule: FilterSmsBroadcast
      Filter: ActionFilter{android.provider.Telephony.SMS_RECEIVED}
      Action: block=true log=true
  Service rules: 0

Testing and Auditing Blocked Intent Events in Logcat

To verify that the Intent Firewall intercepts and drops matching intents, attempt to launch the blocked component from ADB shell:

adb shell am start -n com.example.admin/.DiagnosticsActivity

The Activity Manager will report that the intent was not started, and logcat will capture the firewall block event in real time:

adb logcat -d -s IntentFirewall:*

Output in logcat confirms the interception:

IntentFirewall: Intent action=null component=com.example.admin/.DiagnosticsActivity: Blocked by BlockAdminDiagnostics

Removing Rules and Restoring Default Operation

To remove firewall restrictions, delete the XML definition file from /data/system/ifw/:

adb shell "su -c 'rm -f /data/system/ifw/admin_lockdown.xml'"

The file observer automatically unloads the rules from memory within milliseconds.