Choose APK when
A complete standalone package is available and it matches your Android version and device architecture.
Android package documentation
Enter a Google Play URL or Android package name to request the available files for a selected device profile. The documentation below explains how APK, split APK, XAPK, APKM, APKS and OBB packages differ, when each format is used, and what users should verify before installation.
Downloader
Example: com.android.chrome or a URL containing ?id=com.android.chrome.
Android package guide
Android applications are not always delivered as one universal installer. The package a user receives depends on how the developer publishes the app, which Android version is running, the processor architecture, the screen configuration, the selected language and whether the app includes large game or media assets.
APK stands for Android Package Kit. It is the standard installable package format used by Android. A traditional APK contains the application manifest, compiled code, resources, certificates and metadata required by the Android package installer. When an app is distributed as one universal APK, the same file may contain resources and native libraries for several device configurations.
Universal APK files are easy to copy and install because they behave like a single installer. The trade-off is file size: a universal package may include resources that a specific device never uses. Modern app distribution often avoids this duplication by delivering configuration-specific split packages.
Every Android application has a unique package identifier, such as com.android.chrome.
The package name is used by Android to distinguish one installed app from another and by Google Play to identify the application page.
It is not the same as the visible app title. An app may change its display name while keeping the same package identifier.
A split installation usually begins with a base APK. The base package contains the core application manifest and code, while additional split APK files provide only the resources needed for a particular device. Common splits include processor architecture, screen density, language and optional features.
For example, an arm64 phone configured in English may receive the base package, an arm64-v8a split,
an English language split and a density-specific split. These files form one installation set.
Installing only the base APK can produce a missing-resource error or an application that cannot start.
Developers may upload an Android App Bundle rather than a single universal APK. The bundle is a publishing format used to describe the complete app. Distribution services can then generate optimized APK sets for each device configuration. End users normally do not install the original bundle file directly.
Formats such as APKS, APKM and XAPK are commonly used to package several installation components into one downloadable archive. They are not all official Android installer formats, and each may require a compatible bundle installer or extraction process.
OBB files are expansion files traditionally used by large Android games and media-heavy applications. They contain data that is separate from the main APK, such as maps, audio, textures or other assets. An OBB file is not an application installer and cannot run by itself.
When an app requires OBB data, the APK must be installed and the matching OBB directory must be placed under
/Android/obb/<package-name>/. The package name and OBB version must match the installed app.
Newer applications may use Play Asset Delivery instead of traditional OBB expansion files.
Android packages contain both a user-facing version name and an internal version code.
The version name may look like 12.4.1, while the version code is an integer used by Android to determine update order.
A package with a lower version code normally cannot replace a newer installed version unless the newer app is removed first.
Compatibility also depends on the minimum Android SDK, target SDK, CPU architecture, required hardware features and package signature. Selecting the wrong architecture or an incomplete split set can result in an installation failure even when the app appears to support the Android version.
Reference table
Use this table to identify what each file usually contains, how it is installed and when it is commonly encountered.
| Format | What it contains | Installation method | Typical use | Important limitation |
|---|---|---|---|---|
| APK | One Android application package | Android package installer | Universal or standalone apps | May not include required split resources or external data |
| Base APK | Core code and manifest for a split installation | Installed together with required splits | Modern apps generated from an App Bundle | Often incomplete when installed alone |
| Split APK | Architecture, language, density or feature resources | Split-capable installer | Device-optimized app delivery | All required components must be installed as one set |
| APKS | An archive containing a generated APK set | Bundletool or compatible installer | Testing and distributing generated split sets | Not handled directly by the default Android installer |
| APKM | Base and split packages in a vendor-specific archive | A compatible APKM installer | Bundled distribution of modern apps | Vendor-specific packaging, not an Android standard |
| XAPK | APK files plus optional OBB or supporting data | XAPK-capable installer or manual extraction | Large games and multi-file downloads | Archive structure can vary between providers |
| OBB | Expansion data such as game assets or media | Placed in the matching Android OBB directory | Large legacy games and apps | Cannot install or run without the matching application |
| App Bundle | Publishing bundle containing the complete app definition | Uploaded by developers; APKs are generated from it | Google Play publishing and optimized delivery | Not normally installed directly by end users |
A complete standalone package is available and it matches your Android version and device architecture.
The app is distributed as a base package plus configuration-specific APK files. Install every required component together.
You need a single archive containing several package components and have a trusted compatible installer.
The installed app explicitly requires matching expansion data. The OBB folder and version must correspond to the package.
Request flow
The downloader uses the package identifier and selected device profile to request the files available for that configuration. The process does not change the app package or remove licensing requirements.
The tool accepts either a package name such as com.android.chrome or a Google Play URL containing the same identifier.
The package name is used to locate the requested application.
The selected device type, CPU architecture, Android version and language are combined into a request profile. These options help determine which configuration-specific package files may be needed.
The service sends the request to its backend infrastructure and waits for the available package information. Depending on the app, the response may include a standalone APK, a base APK with split files, or additional OBB data.
The result can include version information, file sizes, package components and generated download links. Some apps may not be available for the selected configuration or may require installation through Google Play.
Device support
Android packages can target different device classes. Selecting the closest matching device type helps avoid incompatible layouts, missing resources or unsupported hardware requirements.
Phones are the most common target. Modern phones usually use arm64 processors and receive density, language and architecture splits. A phone package may depend on touchscreen, telephony, camera or location features.
Tablet and foldable builds can include layouts optimized for larger screens. Some applications use the same package as phones, while others expose tablet-specific features or exclude unsupported devices.
TV apps must support remote navigation, landscape layouts and television features. A phone APK may install on a TV but still be unusable because it requires touch input or lacks a TV launcher activity.
ChromeOS can run many Android apps through its Android runtime. Compatibility depends on the Chromebook model, supported CPU architecture, Play Store availability and whether the app supports larger screens and keyboard input.
Wear OS apps are designed for watches and use different screen, interaction and hardware assumptions. A standard phone package should not be treated as a Wear OS build unless the developer explicitly supports watches.
Emulators may use x86, x86_64 or translated ARM libraries. The package must match the emulator architecture and Android API level, and some apps may block emulators or require unavailable hardware services.
ABI reference
Android native libraries are compiled for one or more application binary interfaces, usually called ABIs. Choosing the wrong architecture can cause an installation error or an app crash at startup.
| ABI | Processor family | Common devices | When to choose it |
|---|---|---|---|
| arm64-v8a | 64-bit ARM | Most modern Android phones, tablets and TVs | Use for current ARM-based devices unless the app only provides a 32-bit build |
| armeabi-v7a | 32-bit ARM | Older phones, entry-level devices and legacy Android hardware | Use for older 32-bit ARM devices or when a 64-bit variant is unavailable |
| x86 | 32-bit Intel/AMD | Older emulators and a limited number of Android devices | Use only when the emulator or device explicitly reports x86 |
| x86_64 | 64-bit Intel/AMD | Modern Android emulators and some ChromeOS environments | Use for 64-bit x86 emulator images or compatible ChromeOS systems |
Device-information apps can display the supported ABIs. Advanced users can also use ADB and inspect
ro.product.cpu.abilist. The first listed ABI is usually the preferred architecture.
Many 64-bit ARM devices can run 32-bit ARM apps, but this is not guaranteed on every newer device. A 32-bit device cannot run a package that contains only 64-bit native libraries.
A universal APK may contain libraries for several ABIs. It is easier to install but usually larger than an architecture-specific package.
Errors such as INSTALL_FAILED_NO_MATCHING_ABIS indicate that the package does not contain native libraries compatible with the device.
Documentation library
Open a focused reference page for installation, compatibility, troubleshooting, security, common questions or Android package terminology.
Content information
This guide provides general technical information about Android package formats, compatibility and installation. It does not replace instructions from the application developer, Android device manufacturer or Google Play.