Report: Android security

Executive summary

Android is secure in many respects but its security is not uniform across the ecosystem. Google provides a strong platform: app sandboxing, SELinux, Verified Boot, Google Play Protect, monthly security bulletins, Project Mainline (Google Play System Updates), and hardware-backed keystores. These built-in controls have stopped or limited many attacks and enable enterprise certifications (e.g., DoD approvals, SESIP Level 5 on some stacks). (Source excerpts below.)

At the same time, Android's openness and ecosystem fragmentation create real gaps: delayed OEM updates, outdated vendor blobs in firmware, widespread app-side vulnerabilities (permissions, intent handling), Play Store malware incidents and effective obfuscation/evasion techniques that defeat detection. For many users and organizations these gaps translate into measurable risk unless mitigations are applied.

What proponents say (the platform's strengths)

"Android assigns a unique user ID (UID) to each Android app and runs it in its own process." (source)
"SELinux enforces mandatory access control over all processes, including those with root or superuser privileges... operating on the principle of default denial." (source)
"Google publishes Android Security Bulletins on the first Monday of each month, detailing vulnerabilities and their fixes." (source)
"Google Play System Updates modularize key system components, enabling faster delivery of security fixes." (source)
Enterprise certifications and tamper-resistant hardware recommendations (TEE/SE, secure boot) let Android devices reach high-assurance use cases (e.g., DoD-approved Pixel models, SESIP Level 5 on pKVM-certified stacks). (source, source)

What critics say (real-world failures and limitations)

"A study analyzing security updates from top OEMs and Google found that devices receive updates at varying frequencies—monthly, quarterly, or biannually—affecting the number of security updates, support duration, and release delays." (source)
"A study found that about 82% of firmware releases contained outdated GPU blobs, some up to 1,281 days old." (source)
High-impact vulnerabilities have occurred in the past (e.g., Stagefright) and new privilege-escalation CVEs keep appearing—successful exploitation is more likely on devices that haven't received patches. (See CVE example: CVE-2025-26420) (source, source)
Malware detection tools can be defeated: obfuscation and adversarial tricks reduce detection rates dramatically in research settings (some tools drop from ~87% to 67%, or lower under hybrid obfuscation). (source)
Permission and intent handling mistakes (misspelled custom permissions, implicit intent hijacking, exported components) have led to privilege escalation and data leaks in apps. (source, source)

Where Android is 'secure enough' — and for whom

Individual users who keep devices up-to-date (recent Pixel, Samsung flagship on AER list) and avoid side-loading or risky apps are well protected by default.
Enterprises that standardize on Android Enterprise Recommended devices, enable MDM, require tamper-resistant hardware, and enforce update policies can reach high assurance comparable to other platforms for most mobile workloads.
High-risk users/organizations (sensitive government secrets, high-risk individuals) require strict device selection, hardware-based attestation, frequent monitoring, and fast update pipelines to reduce exposure.

Practical mitigations (how to make Android safer)

Buy devices on the Android Enterprise Recommended list or those with long update commitments (Pixel, some flagship models). (source)
Enable automatic updates and install monthly security patches promptly. (source)
Use Google Play Protect and download apps from Managed Google Play or vetted stores; avoid side-loading. (source)
Enforce MDM policies: disk encryption, biometrics or strong passcodes, screen lock timers, remove unused apps, disable unknown sources. (source)
Require hardware-backed keystore (TEE/SE) and Verified Boot for high-assurance cases. (source)
For developers: follow best practices for explicit intents, exported component checks, correct permission declarations, and limit use of sensitive APIs. (source)

Trade-offs and final judgement

Android provides a modern, layered security model and frequent patches from Google. When the full stack (hardware + OS + vendor support + enterprise policy) is in place, Android can be very secure.
However, the open ecosystem and fragmented update path mean that many devices remain exposed for long periods. Security is therefore conditional: Android can be secure, but it is not automatically or universally secure for every device or user.

Conclusion: Android is secure as a platform when used with recommended devices, up-to-date software, and correct policies — but the ecosystem realities (fragmentation, vendor delays, app mistakes, malware evasion) mean many users remain at risk unless they take active steps.

Selected excerpts & citations

"Android assigns a unique user ID (UID) to each Android app and runs it in its own process." (source)

"A study analyzing security updates from top OEMs and Google found that devices receive updates at varying frequencies—monthly, quarterly, or biannually—affecting the number of security updates, support duration, and release delays." (source)

"A study found that about 82% of firmware releases contained outdated GPU blobs, some up to 1,281 days old." (source)

"Obfuscation techniques significantly hinder the detection capabilities of Android malware detection tools, especially when multiple or hybrid obfuscations are employed." (source)