Android's security model exists to protect users, apps, and data. Every mechanism documented here has been bypassed, circumvented, or abused in practice by malware, exploit chains, or security researchers. The focus is on how these protections work, where they fail, and how they are defeated.
The Permissions section documents Android's permission system and how every abusable permission is exploited by malware.
Security Architecture
| Layer |
Mechanism |
How It Is Abused |
| Hardware |
Verified Boot, TEE/StrongBox, hardware-backed Keystore |
Firmware persistence, key extraction, bootloader exploits |
| Kernel |
SELinux, seccomp-bpf, dm-verity |
Privilege escalation, policy bypass, kernel exploits |
| Framework |
App sandbox, permission model, Play Integrity |
Sandbox escapes, permission abuse, attestation bypass |
| Application |
Scoped storage, biometric authentication, app signing |
Storage access, authentication bypass, signature verification |
Pages
| Page |
Scope |
| App Sandbox |
Process isolation, UID-based separation, IPC restrictions, sandbox escape history |
| SELinux |
Mandatory access control on Android, policy structure, known bypasses, context transitions |
| Verified Boot |
Boot chain verification, dm-verity, AVB, rollback protection, bootloader unlocking implications |
| Keystore |
Hardware-backed key storage, TEE vs StrongBox, key attestation, extraction research |
| Play Integrity |
SafetyNet to Play Integrity evolution, attestation verdicts, bypass techniques, device trust |
| Biometric Authentication |
BiometricPrompt, CryptoObject binding, fallback to PIN, downgrade attacks |
Planned
| Page |
Scope |
| Scoped Storage |
Storage access framework, MediaStore restrictions, legacy bypass, malware adaptation |
| Permission Model |
Runtime permissions, auto-revoke, one-time permissions, restricted settings, grant flow abuse |
Cross-References