DEV Community

Lisajone
Lisajone

Posted on

Inside an APK: Android Package Structure, Signatures, and Safe Sideloading

#android #tutorial #apk

Every Android app you install arrives as a single file with the .apk extension. Whether it comes from an app store or you sideload it yourself, that file is what Android's package manager inspects, verifies, and turns into a running app. Understanding what lives inside an APK — and how Android checks that nobody tampered with it — makes you a safer sideloader.

An APK is just a ZIP archive

Despite the special extension, an APK is a standard ZIP file. Rename app.apk to app.zip and any archive tool will open it. A typical package looks like this:

AndroidManifest.xml
classes.dex
res/
lib/
resources.arsc
META-INF/
Enter fullscreen mode Exit fullscreen mode

Some entries are compressed, while others — already-compressed media and resources.arsc — are stored uncompressed so the runtime can memory-map them for fast access.

AndroidManifest.xml: the identity card

The manifest is a binary XML file declaring everything Android needs before any code runs: the package name that uniquely identifies the app, its version code and version name, the minimum and target SDK levels, requested permissions, and its components — activities, services, broadcast receivers, and content providers. Because it is stored in compiled binary form, you need a tool such as aapt2 or APKTool to read it comfortably.

DEX: where the code lives

Kotlin and Java code is compiled into Dalvik Executable (DEX) bytecode, stored in classes.dex. One DEX file supports roughly 65,000 method references, so larger apps add classes2.dex, classes3.dex, and so on — the multidex approach. At install time, Android's ART runtime compiles the bytecode ahead of time into native machine code. Any C or C++ libraries live separately under lib/<abi>/, with one folder per CPU architecture.

Resources and resources.arsc

Layouts, strings, images, and colors live under res/ and assets/. The compiled table resources.arsc maps each resource ID to its values for every configuration — language, screen density, night mode, and more. When code asks for R.string.app_name, Android resolves it through this table to the variant matching your device.

Signatures: META-INF and v2 signing

Every APK must be signed with the developer's private key; Android refuses unsigned packages outright. The original JAR-style signing scheme places signature files in META-INF/: MANIFEST.MF holds a hash of every file, CERT.SF signs those hashes, and CERT.RSA carries the signature and certificate.

Since Android 7.0, APK Signature Scheme v2 signs the whole file as a single binary blob rather than individual entries. Its signing block sits between the ZIP entries and the central directory, and because the digests cover the entire archive, verification is faster and catches changes that per-file hashing could miss. Later schemes add key rotation (v3) and incremental signing (v4).

One rule matters most: an update must be signed with the same key as the installed app. Android compares certificates when you update, so a re-signed copy can never silently replace the original.

How verification works

At install time, the package manager verifies the signing block and META-INF digests to confirm the file matches what the developer signed, parses the manifest, and checks that the version code is acceptable. If the app is already installed, it compares the new certificate with the existing one. Only then does it extract native libraries for your device's ABI and register the app.

Safe sideloading checklist

Installing APKs from outside a store shifts the verification burden onto you. Before installing:

  1. Download from sources you trust — the developer's own site or a reputable mirror that verifies signatures; research and package information at APKMega can help you check what you are getting.
  2. Confirm the package name matches the official release; clones often alter it slightly.
  3. Compare the certificate fingerprint. Run apksigner verify --print-certs and match the SHA-256 digest against the developer's published value.
  4. Never "update" from a different source. A different signature means a different publisher — full stop.
  5. Scan the file first with a reputable antivirus or multi-engine scanner.
  6. Review the permissions the manifest declares; a calculator requesting SMS access is a red flag.
  7. Avoid modded or cracked builds. Modifying an APK requires re-signing it, which breaks the original trust chain.

An APK is not a black box. Once you see how the manifest, DEX files, resources, and signatures fit together, you can judge for yourself whether a file deserves a place on your phone.

Top comments (0)