What is an APK file?

What is actually inside an APK

Because an APK is a ZIP, opening it reveals a predictable internal structure. The exact entries vary by app, build configuration, and Android Gradle plugin version, but the core files are consistent across virtually every APK:

• AndroidManifest.xml — the app's manifest: package name, version, permissions, declared activities and services, and the minimum Android version. Inside the APK this file is compiled to Android binary XML, not plain text, so you cannot read it with a text editor — you need aapt / aapt2 dump or a binary-XML-aware tool to decode it.
• classes.dex (one or more) — the app's compiled bytecode in Dalvik Executable format. Every .dex file holds the application's code translated into Dalvik bytecode that the Android runtime (ART) executes. Large apps are split into classes.dex, classes2.dex, classes3.dex, and so on because a single DEX is limited to 65,536 method references (a count that includes framework and library methods, not just your own).
• resources.arsc — the compiled resource table. It maps resource IDs (like 0x7f010002) to their values and handles resource lookup at runtime. Text strings, layout references, and theme values are indexed here.
• res/ — compiled resources as produced by the build: layouts, drawables (images), strings, colors, and styles. Most XML here is also in Android binary-XML format.
• assets/ — raw files shipped as-is: fonts, bundled HTML, configuration JSON, databases, or any file the app wants to read at runtime without compilation. These are plain files, not binary-XML.
• lib/ — native libraries, one .so (shared object) per CPU architecture, grouped into subfolders: arm64-v8a/ (modern 64-bit ARM), armeabi-v7a/ (older 32-bit ARM), x86_64/ (emulators and some Chromebooks), and x86/. A given APK usually ships only a subset.
• META-INF/ — the v1 (JAR-style) app signature: MANIFEST.MF (hashes every file), one or more *.SF files (the signature file), and *.RSA or *.EC files (the cryptographic signature block). Tampering with any signed file breaks the signature, which is how Android verifies integrity. Modern APKs additionally use APK Signature Scheme v2/v3, which lives in a dedicated APK Signing Block placed immediately before the ZIP central directory (not as a regular file under META-INF/) — which is why v2/v3-only APKs no longer carry .SF/.RSA entries at all.

How Android uses the APK

When you tap install, Android's package installer verifies the APK's signature, checks that the manifest's requirements are met, and copies the app into place. At runtime, the Android Runtime (ART) — the successor to the older Dalvik VM — runs the .dex bytecode. On install, ART performs ahead-of-time (AOT) compilation of the dex into optimized native machine code, which is what actually executes when the app runs; the original .dex remains for fallback and verification.

The resources in res/ and assets/ are read at runtime via the Android resource system and the AssetManager. Native libraries under lib/ are extracted or loaded directly so the app can call C/C++ code — common for games, media codecs, and performance-critical paths.

APK vs AAB (App Bundle)

Google Play no longer ships a single universal APK to most devices. Since 2021 it has used the Android App Bundle (.aab) as the upload format: developers upload an .aab, and Google Play's servers split it into per-device APKs — shipping only the native library for your device's CPU architecture and only the resources for your screen density and language. The result is a smaller download for each user.

For practical purposes, the distinction matters when you download an app: from Google Play you get an optimized APK generated server-side; from any other source (sideloading, alternative stores, a direct download) you get a plain APK, which may be a universal build carrying every architecture and density and thus larger. An .aab is also a ZIP container internally, but it is not directly installable on a phone — it has to be processed (by bundletool or Google Play) into one or more APKs first.

How to open or inspect an APK without a phone

Because an APK is structurally a ZIP, you have several options for looking inside one without installing it on a device. The quick method: rename app.apk to app.zip and double-click it — your OS will open it like any folder. From a terminal, unzip -l app.apk lists every entry without even renaming. These work because the file is a real ZIP archive.

The cleaner method is to open the APK in an in-browser viewer, which lets you browse the full file tree and preview text, images, and assets without extracting anything to disk. ZipTool parses the archive entirely in your browser (via zip.js) and never uploads it — useful if the APK is sensitive, untrusted, or covered by a data-handling policy. Step by step:

• Open ziptool.app in any modern browser — nothing to install.
• Drag-and-drop the .apk onto the page, use the file picker, or paste a URL (or deep-link with ?zip=<url>&file=<path> to open a remote APK and jump to a specific file).
• The full tree appears: AndroidManifest.xml, classes.dex, res/, assets/, lib/, and META-INF/. Search across filenames to find a specific entry.
• Click any file to preview it inline — images under res/ or assets/ render directly, text and config files open in a syntax-highlighting editor, and a nested .zip entry can be added to the list and browsed separately.
• Nothing is written to disk and nothing is uploaded. Close the tab and the APK is gone. (Note: AndroidManifest.xml and res/ XML are in Android binary-XML format, so they preview as binary rather than readable text — decode them with aapt2 if you need the human-readable manifest.)

Safety: inspecting an APK is low-risk, installing one is the real risk

Browsing an APK's contents — treating it as a ZIP and looking at the tree — is low-risk. You are reading a file's structure, not executing its code, and inspecting an unknown APK before installing it is a genuinely good habit. It is how you spot an app asking for surprising permissions (in the manifest), an unexpectedly large native library for your architecture, or resources that do not match what the app claims to be.

The serious risk is installing and running an APK from an untrusted source. A sideloaded APK can be malware — spyware, banking trojans, adware, or a repackaged legitimate app with malicious code injected. Android warns about installs from unknown sources for exactly this reason. The signature only proves the file has not been modified since the developer signed it; it says nothing about whether the developer or the app itself is trustworthy.

One accuracy caveat worth stating plainly: inspecting contents in a browser is safer than blindly installing, but it is not a guarantee that nothing can go wrong. Parsing still runs JavaScript in a sandboxed browser tab, where library or browser bugs are theoretically exploitable, and any file you later extract and run can still be malware. For the full privacy-vs-safety breakdown — what client-side processing does and does not protect you from — see security and privacy.

Frequently asked questions