Android package documentation

Download Android packages and understand what each file contains

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.

Enter a package name or Google Play URL

Example: com.android.chrome or a URL containing ?id=com.android.chrome.

Was this tool useful?
Config
Enter a valid Package or URL.
Android Device Configuration
Device
Arch
Android
Language

Understanding Android app packages

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.

What is an APK?

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.

What is a package name?

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.

Base APK and split APK files

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.

Android App Bundles and generated packages

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 and additional app data

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.

Version code, version name and compatibility

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.

APK format comparison

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

Choose APK when

A complete standalone package is available and it matches your Android version and device architecture.

Choose a split set when

The app is distributed as a base package plus configuration-specific APK files. Install every required component together.

Choose XAPK or APKS when

You need a single archive containing several package components and have a trusted compatible installer.

Use OBB only when

The installed app explicitly requires matching expansion data. The OBB folder and version must correspond to the package.

How APK Downloader Lite works

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.

01

Read the package identifier

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.

02

Build a device profile

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.

03

Request available package data

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.

04

Return file details

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.

Supported Android device types

Android packages can target different device classes. Selecting the closest matching device type helps avoid incompatible layouts, missing resources or unsupported hardware requirements.

Android phones

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.

Tablets and foldables

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.

Android TV and Google TV

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.

Chromebooks

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 devices

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.

Android emulators

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.

CPU architecture and Android ABI

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

How to check your architecture

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.

64-bit and 32-bit compatibility

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.

Universal packages

A universal APK may contain libraries for several ABIs. It is easier to install but usually larger than an architecture-specific package.

Architecture mismatch errors

Errors such as INSTALL_FAILED_NO_MATCHING_ABIS indicate that the package does not contain native libraries compatible with the device.

Detailed Android package references

Open a focused reference page for installation, compatibility, troubleshooting, security, common questions or Android package terminology.

About this documentation

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.

Last reviewed
Content scope
Android package installation and compatibility
Service status
Independent and not affiliated with Google Play