Android Application Security

Five: the APK code itself, local storage (SharedPreferences, SQLite, files, KeyStore), the network traffic and its TLS configuration, inter-process communication through exported components and deep links, and runtime behaviour such as method hooking and root detection. Every assessment walks these five in turn.

The AndroidManifest.xml. It declares every component, every permission and which components are exported, so it effectively hands you the attack surface before you run the app. Decompile the APK with jadx and read the manifest before any dynamic testing.

Because the app runs on hardware the attacker fully controls. Any secret, check or decision inside the APK can be observed and changed on a rooted device. Real authorisation and secrets must live server-side; the client is never a trust boundary.

Only test apps and devices you own or have explicit written permission to test. Decompiling or intercepting traffic from an app you do not own can breach its terms of service and local law. Practise on your own test apps and lab targets.

Not for static analysis — pulling an APK and reading it with jadx needs only ordinary tools. A device you control (or an emulator) becomes important for dynamic testing with Frida and traffic interception, covered in later lessons.

An APK is a ZIP archive with a fixed layout: a binary AndroidManifest.xml, one or more classes.dex files of Dalvik bytecode, a compiled resources.arsc and res/, native libraries under lib/, raw assets/, and a META-INF signature block. The signature proves integrity and origin but does not encrypt the contents.