An APK, short for Android Package, is the file format that Android uses to install and distribute applications. It is a ZIP archive with a defined structure that contains the app’s compiled code, resources, native libraries and manifest, together with a cryptographic signature that identifies the developer and protects the contents from tampering.
In mobile distribution, the APK is the unit that actually lands on a device. Even when developers upload an Android App Bundle to Google Play, the store generates optimized APKs from it, and those are what the phone installs.
What an APK file contains
An APK follows a fixed internal layout that the Android package manager reads during installation. Each part serves a specific role in running the app.
| Entry | Contents | Purpose |
|---|---|---|
| AndroidManifest.xml | Package name, components, permissions, SDK levels | Tells the system what the app is and needs |
| classes.dex | Compiled Dalvik bytecode, possibly several files | App code executed by the Android Runtime |
| resources.arsc | Compiled resource table | Strings, dimensions and resource lookups |
| res/ | Layouts, images, other resources | Interface assets by density and language |
| lib/ | Native libraries per CPU architecture | C and C++ code such as arm64-v8a builds |
| assets/ | Raw files read at runtime | Data, fonts, models |
| META-INF/ | Legacy signature files | Signature verification for older devices |
The manifest is stored in a compiled binary XML format, not as plain text. Uncompressed native libraries and resources are aligned to 4-byte boundaries with the zipalign tool so the system can map them into memory directly, which saves RAM and speeds up loading.
During installation, the package manager verifies the signature, parses the manifest, checks that the device meets the declared minimum API level and CPU architecture, and copies the APK into a protected system directory. It then assigns the app a unique Linux user ID and may compile frequently used code ahead of time, so the first launch runs faster.
How APK signing works
Every APK must be signed with the developer’s private key before Android will install it. The signature proves that later updates come from the same developer: an update is accepted only if it is signed with the same key or an approved successor.
| Scheme | Introduced in | Key feature |
|---|---|---|
| v1 (JAR signing) | Android 1.0 | Signs individual entries, slower and weaker |
| v2 | Android 7.0 | Signs the whole file, faster verification |
| v3 | Android 9 | Supports key rotation |
| v4 | Android 11 | Separate signature file for incremental installs |
Losing the signing key used to mean that an app could never be updated again under the same package name. Play App Signing reduces this risk by letting Google hold the app signing key while the developer signs uploads with a separate upload key that can be reset.
APK compared with other mobile package formats
The APK is an installable artifact, while some neighboring formats are publishing artifacts that a store processes first. The comparison clarifies where each format fits.
| Format | Platform | Installed directly on devices | Main use |
|---|---|---|---|
| APK | Android | Yes | Installation, sideloading, alternative stores |
| AAB (Android App Bundle) | Android | No | Upload format for Google Play |
| Split APKs | Android | Yes, as a set | Device-specific delivery generated from an AAB |
| IPA | iOS and iPadOS | Only through approved channels | App Store, TestFlight, enterprise distribution |
Google Play requires new apps to be published as AABs. From the bundle, Play generates a base APK and configuration splits for screen density, CPU architecture and language, so each device downloads only the parts it needs.
Installing and distributing APK files
APKs reach devices through app stores, enterprise management or sideloading. Each channel offers a different balance between reach, control and security review.
| Channel | Typical use | Security consideration |
|---|---|---|
| Google Play | Public consumer apps | Store review and Play Protect scanning |
| Alternative app stores | Regional markets, devices without Google services | Review quality varies |
| Managed Google Play or MDM | Internal company apps | Distribution limited to managed devices |
| Sideloading | Testing, open-source apps | User must allow installs from that source |
| ADB install | Development and debugging | Requires developer options and USB access |
Since Android 8.0, permission to install unknown apps is granted per source app, such as a specific browser or file manager, rather than globally. This limits the damage if a user is tricked into downloading a malicious APK.
Common mistakes with APK files
- Shipping a debug-signed APK. Debug keys are not accepted for store releases and cannot be trusted for updates.
- Forgetting to raise versionCode. An update with the same or a lower version code is rejected by the device.
- Bundling every native architecture. A universal APK can be several times larger than necessary.
- Installing APKs from unknown websites. Repackaged APKs are a common way to spread mobile malware.
Release teams also benefit from inspecting the final APK with tools such as the APK Analyzer, which shows which resources, libraries and code contribute most to download size.
The idea in brief
An APK is the file that holds an Android app, much like a setup file on a computer. It packs the app’s code, pictures and settings into one box. It also carries a seal that shows who made it.
When you install an app from a store, an APK is delivered behind the scenes. You can also install one by hand. Only do that from sources you trust, because a fake APK can contain harmful software.
A practical scenario
A logistics firm builds an internal scanning app for warehouse handhelds that run Android without Google services. The release pipeline produces a signed release APK for the arm64-v8a architecture, and the firm’s MDM pushes it to 600 devices overnight.
When a later version fails to install, the logs show that the developers had forgotten to increase versionCode. After fixing it, the update installs silently. The team also stores the signing key in a hardware security module, because losing it would make every future update impossible to install over the existing app.