What is actually inside an APK file?

Open an APK in a text editor and you get noise. Open it as a ZIP and it suddenly makes sense: an Android package is an ordinary archive with a strict set of expected entries.

The entries that matter

• AndroidManifest.xml — the app identity: package name, version code, minimum SDK, permissions, activities and intent filters. Inside an APK it is stored as binary AXML, not text, so a plain viewer shows garbage until it is decoded.
• classes.dex (and classes2.dex, classes3.dex…) — the compiled Dalvik bytecode. Multiple files mean the app crossed the 64K method limit and was split.
• resources.arsc — the compiled resource table mapping IDs to strings, colours and dimensions for every locale and density.
• res/ — drawables, layouts and mipmap icons, mostly compiled.
• lib/<abi>/ — native .so libraries per architecture. If you only see arm64-v8a, the build dropped 32-bit devices.
• META-INF/ — the signature block: the manifest digest list and the signing certificate.

Why the manifest looks broken

AXML replaces tags and attribute names with indexes into a string pool and stores integers as raw four-byte values. That is why extracting an APK with a normal unzip tool and opening the manifest gives you unreadable output. The APK Analyzer decodes the string pool and rebuilds readable XML in the browser, so you can read permissions and exported components without installing a toolchain.

Reading the signature

Every Android package is signed. The certificate does not prove the app is safe — it proves that this build came from the same key as the last one, which is how Android blocks a malicious update from replacing a legitimate app. The fingerprints matter in practice: Google Sign-In, Maps and Firebase all key off the SHA-1 or SHA-256 fingerprint of the signing certificate.

If a login works in debug and fails in release, the fingerprint is almost always the reason. Run the release build through the APK Certificate Inspector and compare the SHA-256 against the value registered in the provider console.

Sanity checks before you ship

• Confirm the permission list matches what the app really needs — every extra one is a Play Store review question.
• Check the ABI folders under lib/ against your target devices.
• Look at the largest entries; oversized PNGs in res/ are the usual cause of a bloated download size.
• Verify the signing fingerprint of the exact artefact you are uploading, not the one from your last build.

An APK is a ZIP, but it is a ZIP where every entry means something. Once you know what to look for, unpacking one is a two-minute audit rather than a reverse-engineering project.