Android App Structure

An Android app ships as an APK (Android Package). It is really a ZIP archive containing the compiled code, resources, and metadata.

Because it is a ZIP, you can simply unzip it to inspect its contents, which is the first step in mobile pentesting.

An extracted APK contains:

• AndroidManifest.xml: app configuration.
• classes.dex: compiled bytecode.
• res/ and resources.arsc: resources.
• lib/: native libraries.
• META-INF/: signing info.

The AndroidManifest.xml declares the app's components, permissions, and configuration. In the APK it is in a binary XML form that tools can decode.

It is the single most important file for understanding an app's attack surface.

Java/Kotlin source compiles to DEX (Dalvik Executable) bytecode in classes.dex. Modern Android runs it via ART (Android Runtime).

DEX can be converted back toward readable code, which is what static analysis of APKs exploits.

Android apps are built from four component types:

• Activities: screens / UI.
• Services: background work.
• Broadcast Receivers: respond to system events.
• Content Providers: share data between apps.

A component marked android:exported="true" can be invoked by other apps. If such a component performs sensitive actions without checks, it is an attack surface.

Pentesters hunt for exported activities, services, and providers that leak data or perform privileged actions.

Apps request permissions in the manifest (for example INTERNET, READ_SMS, ACCESS_FINE_LOCATION).

Over-broad permissions hint at risky behavior or excessive data access. Custom permissions can also be misconfigured to allow unauthorized access.

Android isolates each app in its own sandbox with a unique Linux UID. By default apps cannot read each other's data.

Vulnerabilities arise when apps weaken this boundary, such as world-readable files or exposed providers.

An installed app stores private data under /data/data/<package>/: databases, shared preferences, and files.

On a rooted device or via backups, a pentester inspects this directory for secrets stored insecurely, which a later lesson explores.

Every APK is digitally signed; the signature lives in META-INF/. Android verifies it on install and for updates.

If you modify and repackage an app, you must re-sign it, which is why developers rely on signing to detect tampering.

Performance-critical or obfuscated logic may live in native libraries (.so files) under lib/, compiled from C/C++.

These are not in DEX, so they require separate analysis with native disassemblers. Developers sometimes hide secrets here, mistakenly believing native code is harder to inspect.

Recall which manifest attribute exposes a component to other apps.

You now understand Android app structure:

• An APK is a ZIP holding AndroidManifest.xml, classes.dex, resources, and signing data.
• Apps use four components; exported ones are attack surface.
• Permissions and the per-app sandbox govern access; private data lives in /data/data/.
• APKs are signed to detect tampering.

Next you will decompile an APK in static analysis.