Android App Security · Inside an APK · Lesson 1 of 5

What's in an APK

Unzip a real-looking app package and learn what each part does.

Unzipping an app

You saw in Mobile Fundamentals that an APK (Android Package) is really a ZIP archive. Now it's time to open one and look at each part properly, the way a malware analyst would.

Here's what you'll find inside almost every APK:

• AndroidManifest.xml, the app's ID card. It names the app, lists its parts and the permissions it wants. It's stored in a compact binary form, so tools have to decode it before you can read it.
• classes.dex, the app's own code, compiled into a format Android understands. Big apps have several, named classes2.dex, classes3.dex and so on.
• res/, the images, screen layouts and text the app displays.
• resources.arsc, a compiled table that links each resource to its value. It's how the same app shows English text on one phone and Spanish on another.
• lib/, optional native libraries. These are files of machine code built for one specific type of processor, so the CPU runs them directly. They sit in a subfolder named after that processor type.
• META-INF/, a folder that holds signature files for the oldest signing method. Newer methods store the signature in a special block inside the APK file itself. You'll meet signing properly in module 3.

Notice what isn't here: your data. An APK only holds what the developer shipped. Your notes, logins and settings are created later, inside the app's private storage on your phone.

Analysts care about this layout because each part answers a different question. The manifest says what the app wants to do. The DEX files show how it does it. Native libraries are harder to read, and some malware hides its trickiest code there.

On the simulated phone, tap each of the 6 entries in quicknotes.apk and read what it holds. Then check who signed it, at the bottom of the screen.

DEX, ART and the right CPU

App developers usually write in Kotlin or Java. Before the app ships, build tools compile that code into DEX (Dalvik Executable) files. DEX is bytecode: instructions meant for a software engine, not for any particular processor. That's why the same classes.dex works on every Android phone.

The engine that runs it is ART, the Android Runtime. ART replaced an older engine called Dalvik and became the standard in Android 5.0. When you install an app, a tool called dex2oat can compile parts of the DEX code ahead of time into machine code for your phone, so the app starts faster. Recent versions also compile code while the app runs and keep notes on which parts you use most, to speed those up later.

Native libraries skip all of that. They're compiled for one family of processors, called an ABI (application binary interface). The common ones are:

• arm64-v8a, 64-bit ARM, used by almost all modern phones
• armeabi-v7a, 32-bit ARM, found on older or cheaper phones
• x86_64, used by emulators and some Chromebooks

Since 2019, Google Play has required apps with native code to include 64-bit versions.

Shipping every ABI, every screen density and every language in one APK makes it big. So developers publishing on Google Play now upload an Android App Bundle (AAB), and new apps have had to use this format since August 2021. An AAB can't be installed directly. Play uses it to build a base APK plus split APKs for each phone, for example config.arm64_v8a.apk for native code, another for your screen density and another for your language. Your phone installs the set together as one app.

For safety this matters in one practical way. Websites that offer app downloads often bundle splits into their own file formats. Those files didn't come straight from Google Play, and you can't easily tell who put them together.