Android stops background apps from using the camera, microphone and motion sensors, so malware that wants continuous access declares itself a foreground service and shows a notification dressed up as something harmless. MITRE ATT&CK for Mobile records this as T1541 Foreground Persistence, a Defense Evasion and Persistence technique listed for Android only. This guide explains how the foreground service mechanism works, how Android versions from 9 to 14 have tightened it, what ATT&CK's procedure examples show, and how MDM, mobile threat defence (MTD), app vetting and user guidance expose it. It is for Android fleet administrators, mobile security engineers and SOC analysts.
Key takeaways
- Android only. ATT&CK lists T1541 for Android. Apple's App Review Guideline 2.5.4 limits background services to intended purposes such as VoIP, audio playback and location.
- The notification is the disguise. The only visible requirement of a foreground service is a persistent notification; malware such as Mandrake used a transparent notification, as ATT&CK records.
- Android has narrowed the abuse. Android 12 blocks most background starts, Android 13 added the Task Manager, and Android 14 requires a declared service type with a matching permission and lets users dismiss ongoing notifications.
- One mitigation is mapped. M1011 User Guidance: a user who sees a persistent notification they do not recognise should uninstall the source app and look for other anomalies.
- Allow-list the services. ATT&CK's DET0637 alerts on
startForeground()orstartForegroundService()calls from apps not on an approved list, correlated with managed app inventory and DPC policy state.
How foreground persistence works
ATT&CK describes the technique as abusing Android's startForeground() API to keep continuous sensor access. The Android 9 behaviour changes document that background apps cannot access the microphone or camera, and that continuous, on-change and one-shot sensors stop delivering events to them; Android's guidance is to use a foreground service if sensor events are needed. A foreground service tells the system the user is aware of the app, so it is not killed, including by the low memory killer, which ATT&CK also lists as a reason for abuse. Sensor access still depends on permissions the user has already granted. The technique therefore pairs with collection techniques such as T1429 Audio Capture and T1512 Video Capture. For the wider matrix see the MITRE ATT&CK for Mobile Guide.
How Android has tightened foreground services
| Android version | Change | Effect on T1541 |
|---|---|---|
| Android 9 (API 28) | Background apps lose camera, microphone and sensor events | Created the incentive to run in the foreground |
| Android 12 (API 31) | Apps targeting API 31 or higher cannot start a foreground service from the background except for listed exemptions; violations throw ForegroundServiceStartNotAllowedException | Malware needs a user-visible moment or an exemption to start |
| Android 12 (API 31) | Camera and microphone use counted as active for privacy indicators | Users see an indicator when the sensor is used |
| Android 13 (API 33) | Task Manager in the notification drawer lists apps running foreground services; Stop removes the whole app from memory, whatever its target SDK | Users can find and stop the service |
| Android 14 (API 34) | Each foreground service must declare a type (for example camera, microphone, location, dataSync) and hold the matching FOREGROUND_SERVICE_* permission; camera and microphone services cannot be created from the background | Sensor use must match a declared, reviewable type |
| Android 14 (API 34) | Notifications set with setOngoing(true) become dismissable, except when the phone is locked, on Clear all, and for listed exceptions such as DPC packages and media | Persistent decoy notifications are easier to dismiss and question |
Two exemptions matter for defenders. The background start list includes apps holding SYSTEM_ALERT_WINDOW, apps the user excluded from battery optimisation, and apps with device owner or profile owner roles. Malware that persuades a user to grant overlay permission or to turn off battery optimisation regains room to start services. Treat both grants as high-risk in app review.
Procedure examples from ATT&CK
| Software | What ATT&CK records |
|---|---|
| CherryBlos (S1225) | Used foreground services, showing a notification to evade detection |
| DocSwap (S9005) | Checked for the FOREGROUND_SERVICE permission and used the StartForeground API with a notification in Korean reading "Tap to view more details or stop the app" to maintain persistence |
| Drinik (S1054) | Has C2 commands that move the malware in and out of the foreground |
| Mandrake (S0485) | Uses foreground persistence to keep a service running, with a transparent notification |
| TERRACOTTA (S0545) | Has used foreground services |
| Tiktok Pro (S0558) | Showed a persistent notification to keep access to device sensors |
The common thread is a notification designed to look routine or to be invisible. That is why ATT&CK's one mitigation is user guidance, and why platform changes have concentrated on making foreground work visible and stoppable.
Prevention and hardening
- Keep devices on current Android versions. The protections in the table apply by OS version and, for some, by the app's target SDK. Use MDM compliance to block corporate access from devices below your minimum version. See the Android Enterprise Security Guide.
- Restrict app sources. Use managed Google Play and keep Play Protect on. For apps targeting Android 14, Google Play requires a per-type foreground service declaration in Play Console, including a description, the user impact if the task is interrupted and a video of the user triggering the feature.
- Review high-risk grants. Report apps holding camera, microphone or location permissions together with overlay (
SYSTEM_ALERT_WINDOW) or battery optimisation exemptions. - Train users (M1011). Tell users to open the Task Manager or notification settings for any persistent notification they do not recognise, stop the app, and report it. Show them the camera and microphone privacy indicators.
- Write your own apps correctly. Declare accurate foreground service types; Google's policy states not to declare invalid or inaccurate types, and that use must be user-initiated or perceptible, stoppable by the user, and run only as long as needed.
Detection and measurement
ATT&CK's DET0637 Detection of Foreground Persistence correlates three Android sources: managed package inventory and status from Android Enterprise or EMM; runtime traces from app vetting showing startForegroundService() or startForeground() calls from apps not in an approved list; and DPC policy, compliance and security state queries, with SecurityLog events where supported. It alerts on a sequence or state change inconsistent with the device and app baseline, and warns against inferring API calls from management state alone.
- Allow-list: maintain the list of managed apps expected to run foreground services, with their declared types. Flag any app that adds a
cameraormicrophonetype in an update. - Manifest review: in app vetting, compare declared foreground service types and
FOREGROUND_SERVICE_*permissions with the app's stated function. - MTD: on-device agents can flag apps that combine foreground services with sensor permissions and overlays. See the Mobile Threat Defense Buyer's Guide.
- Forensics: in a suspected spyware case, acquire the device and review running and installed packages before stopping or removing anything. See the Mobile Forensics Guide.
Metrics:
- Percentage of Android devices on Android 14 or later.
- Number of managed apps with camera or microphone foreground service types, against the allow-list.
- Number of apps holding overlay or battery optimisation exemptions alongside sensor permissions.
- User reports of unknown persistent notifications per quarter, and time to triage.
Common failure patterns
- Allowing old OS versions. Devices below Android 12 lack background start limits; below Android 13 they lack the Task Manager.
- No list of expected foreground services. Without a baseline, every alert is noise.
- Ignoring overlay and battery grants. These exemptions let malware start foreground work outside user-visible moments.
- Training users to ignore notifications. Users told that persistent notifications are normal will not report decoys like those ATT&CK records.
- Removing the app before collecting evidence. Stopping or uninstalling first loses the evidence of what ran.
Framework mapping
| Framework | Reference | Why it applies |
|---|---|---|
| ATT&CK for Mobile | T1541; M1011 User Guidance; DET0637; related T1429, T1512, T1624 | The technique, mitigation, detection and paired techniques |
| NIST SP 800-53 Rev 5 | AC-19; CM-7 Least Functionality; CM-11; SI-4 | Mobile device policy, limiting functions and installed software, monitoring |
| NIST CSF 2.0 | PR.PS-05; PR.PS-02; DE.CM-09 | Unauthorised software, keeping software current, device monitoring |
| OWASP MASVS | MASVS-PLATFORM; MASVS-PRIVACY | Correct platform API use and data minimisation in your own apps |
Practitioner checklist
- Set a minimum Android version in MDM compliance, ideally Android 14.
- Restrict app sources to managed Google Play and keep Play Protect on.
- Keep an allow-list of apps expected to run foreground services, with their types.
- Flag apps combining sensor permissions with overlay or battery optimisation exemptions.
- Teach users to check the Task Manager and privacy indicators and to report unknown notifications.
- Review foreground service type declarations in your own apps before each release.
- Acquire evidence before stopping or removing a suspicious app.
Standards and references
- MITRE ATT&CK: T1541 Foreground Persistence (Mobile)
- Android Developers: Behaviour changes, all apps (Android 9)
- Android Developers: Restrictions on starting a foreground service from the background
- Android Developers: Foreground service types
- Android Developers: Handle user-initiated stopping of apps running foreground services
- Android Developers: Behaviour changes, all apps (Android 14)
- Google Play Console Help: Foreground service requirements
- Android Open Source Project: Privacy indicators
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Android Security and Privacy Settings Guide · Mobile App Permissions · Android Banking Trojans Guide · Mobile Malware Guide