Immutable PendingIntent Enforcement
| Plan | Platforms | MASVS |
|---|---|---|
| Team | Android | MASVS-PLATFORM-1 |
Overview
Immutable PendingIntent Enforcement reduces Android inter-process communication risk by making supported PendingIntent usage immutable during protected build creation. This helps prevent another app from modifying a PendingIntent payload and using your app's identity or permissions in unintended ways.
The control is applied at build time. It does not add a runtime prompt, background service, or ongoing performance cost.
When To Use It
Use this control when your app creates PendingIntents for:
- Notifications, reminders, alarms, or background actions.
- Payment, approval, consent, messaging, or identity workflows.
- Broadcasts, services, or activities that should not be modified by another app.
- Apps subject to secure coding, financial, healthcare, enterprise, or government requirements.
How It Works
During protected Android build creation, AppTego reviews supported PendingIntent construction patterns in the application code and enforces immutable behavior where it is safe to do so. Supported call sites are rewritten so another app cannot fill in or replace mutable intent data later.
Exact bytecode transformations, helper methods, and matching rules are not published in public documentation. AppTego keeps those implementation details private so the hardening logic can evolve safely.
How to Enable the Control
Navigate to Preventative Controls from the AppTego portal, and expand the App Component Security section. Under this section you will find the Immutable PendingIntent Enforcement control. Click Enable to enable it for the next build or for it to be applied with a live push (if enabled).
API Configuration Example
{
"ImmutablePendingIntentPrevention": {
"protection": true,
"allowlist": []
}
}| Field | Purpose |
|---|---|
protection | Enables immutable PendingIntent enforcement for protected Android apps. |
allowlist | Optional list of app-owned methods that should keep their original behavior after compatibility testing. |
Use the allowlist sparingly. Every exception can reintroduce mutable PendingIntent risk in that code path.
Compatibility Notes
Some Android features legitimately require mutable PendingIntents. Common examples include inline notification replies, some media controls, location workflows, and certain third-party SDK integrations. Test these flows carefully after enabling the control.
If a feature breaks, prefer updating the app code or SDK integration first. Use an allowlist only when mutability is required and the affected code path is understood.
Testing Checklist
- Verify notification actions, including reply and media controls.
- Test alarms, reminders, push notifications, and scheduled actions.
- Exercise location, geofencing, and background task flows if used.
- Test third-party SDKs that may create PendingIntents indirectly.
- Review build and runtime logs for PendingIntent-related compatibility errors.