Why Can't base.apk Always Be Installed by Itself?

A base.apk can be a complete standalone APK or only the base module of a Split APK set. Learn to identify missing ABI, DPI, language, or feature splits and install the complete set correctly.

Sep 4, 2026

Why Can't base.apk Always Be Installed by Itself?

If you receive a file named base.apk and tapping it says “App not installed,” or the app will not open afterward, a common reason is that this is only the base module of a Split APK app. Other APKs for CPU architecture, screen density, language, or features may be missing. The system needs a complete matching set submitted in one installation.

First, correct a common misconception: the filename base.apk alone does not prove it cannot be installed by itself. A complete standalone APK can also be named base.apk when exported by the system or a backup/extraction tool. Whether it installs alone depends on whether the app is a standalone package or a split set, not just the filename.

What exactly is base.apk?

Android App Bundle (AAB) is a publishing format that developers upload to distribution platforms. A platform can generate a smaller, device-specific set of APKs from an App Bundle. A typical set contains:

base.apk: base code, core resources, and the app's complete declaration;
split_config.arm64_v8a.apk: native libraries for arm64-v8a;
split_config.xxhdpi.apk: images and other resources for xxhdpi screens;
split_config.zh.apk: Chinese-language resources;
split_feature_xxx.apk: a dynamic or optional feature module.

The base APK is central to the app, and other configuration or feature packages depend on it. But “base” does not mean it already includes everything the device needs at runtime.

How base, configuration, and feature APKs fit together

Why use multiple APKs?

If one APK contained every CPU architecture, screen density, and language, users would download substantial content their devices would never use. Split delivery sends only the parts the current device needs, reducing download size and storage use.

For example, a phone with arm64, xxhdpi, and a Chinese-language environment might receive:

base.apk
split_config.arm64_v8a.apk
split_config.xxhdpi.apk
split_config.zh.apk

An x86_64 tablet would receive a different combination. Therefore, a device-targeted split set extracted from phone A might not suit phone B.

Why might base.apk fail on its own?

Cause 1: the installation session lacks required splits

Android's documentation says split APKs must be submitted in the same installation session, and a new installation must include the base APK. Conversely, if the base depends on required configuration splits that are not submitted with it, the installation is incomplete.

On Google-certified devices and devices running Android 10 or higher, partially sideloading without one or more required splits fails. The device may only say “App not installed,” without naming the missing file.

Cause 2: the native library for the ABI is not in base

An app's .so native libraries may be stored separately in split_config.arm64_v8a.apk, split_config.armeabi_v7a.apk, or split_config.x86_64.apk. With only the base, installation may fail, or the app may crash when it launches and loads native code.

Cause 3: screen or language resources are missing

Images, layout variants, and translated text may reside in density or language splits. Without required resources, the app may display incorrectly or even crash while accessing them.

Cause 4: a dynamic feature module was not obtained

Some feature code and resources live in a feature split. Basic functions might open, but a download, map, payment, or other feature may find its module missing. A dynamically delivered app may also expect its original distributor to supply modules on demand.

Cause 5: splits from different versions or sources were mixed

The base and all splits in a session must have the same package name, matching version codes, the same signing certificate, and non-conflicting split names. Combining an old base.apk with new configuration packages, or assembling files from two sources, will cause the system to reject the install.

How can I tell whether my base.apk is complete?

Do not rely on the filename alone. Use these four checks.

Method 1: check where it came from

Downloaded directly as a developer-provided “Universal APK”: more likely a standalone package;
Extracted from /data/app/, a backup, or an extraction tool: check for accompanying split_*.apk files;
Extracted from .apks, .apkm, or .xapk: usually just one part of a set;
Stored alongside several split_config.*.apk files: a strong sign that they need to be installed together.

Method 2: inspect the installed app's paths

If the original app remains installed and ADB is configured, run:

adb shell pm path com.example.app

If the output has multiple lines, showing base.apk plus split paths, that installation uses a split set. For example:

package:/data/app/.../base.apk
package:/data/app/.../split_config.arm64_v8a.apk
package:/data/app/.../split_config.xxhdpi.apk

Replace com.example.app with the actual package name. System paths vary; do not copy the example path to access another app's private data.

Method 3: inspect filenames in the same directory

Common clues include:

split_config.arm64_v8a.apk, split_config.x86_64.apk: CPU architecture;
split_config.hdpi.apk, split_config.xxhdpi.apk: screen density;
split_config.en.apk, split_config.zh.apk: language;
Names containing feature or module: feature modules.

Filenames are clues, not proof that the files match each other. Check package name, version, and signature too.

Method 4: inspect the container format and download instructions

.apks is an APK-set archive that bundletool can generate. .apkm and .xapk are containers used by some distribution tools. Renaming any of them cannot make it one APK. .aab is a publishing format and cannot be installed directly on a device.

How do base.apk, AAB, and APKS differ?

Format	Purpose	Can you tap to install directly?
Standalone `.apk`	A complete installable package	Usually yes
`base.apk` + `split_*.apk`	A set of splits for one app	Must be installed together
`.apks`	An archive containing an APK set	Requires bundletool or a compatible installer
`.apkm` / `.xapk`	Third-party-defined installation containers	Requires a trusted compatible installer
`.aab`	A developer publishing bundle	Cannot be installed directly

An extension describes a container, not whether its source is safe. Whatever the format, verify the developer, signature, hash, and requested permissions.

Install base.apk and its splits correctly

Correct installation choices for base.apk and split packages

Option 1: prefer a complete installation from the original channel

For most users, returning to the developer's site or original app store is safest, because the distributor can choose the complete components for the current device. If the developer also offers a universal APK, verify its signature and version before installing that complete standalone package.

If an APKBang page shows multiple architectures or components for one version, choose a complete matching set. Do not treat the listed base.apk as a universal APK. The page's version, architecture, file size, and hash can help with verification, but developer source and signature still matter.

Option 2: use a trusted installer that supports the container

For .apks, .apkm, or .xapk, use a trusted tool that explicitly supports the format and shows the components it plans to install. Check its chosen ABI, DPI, language, and features, and do not grant permissions unrelated to installation.

Option 3: install multiple APKs together with ADB

If you know Android Platform Tools, put one matching set in a directory and list the files explicitly:

adb install-multiple base.apk \
  split_config.arm64_v8a.apk \
  split_config.xxhdpi.apk \
  split_config.zh.apk

The files required depend on the app and device; this example cannot be copied blindly. Do not use a wildcard that submits APKs from different versions, devices, or sources in the same installation.

Option 4: use bundletool for development and testing

Developers can use Google's bundletool to build an APK set from their own AAB and install it on a connected device:

bundletool build-apks --bundle=app.aab --output=app.apks
bundletool install-apks --apks=app.apks

Configure signing and device-targeting parameters according to the official bundletool documentation. Do not redistribute commercial apps you do not own without authorization.

Four consistency requirements before installation

Putting base and split files together does not automatically make them one set. For a multi-APK installation, check at least:

Same package name: every file belongs to one app;
Same version: modules with different versionCode values must not be mixed;
Same signature: all APKs use the same signing certificate;
Matching components: split names are unique and match the device ABI, DPI, and feature requirements.

If any check fails, you may see “App not installed,” “Invalid APK,” or an ADB INSTALL_FAILED_* error. See What to Do When an APK Says “App Not Installed” for more.

What if it installed but will not open?

A necessary configuration or runtime module may still be missing, or the cause may be ABI, Android version, old data, or a defect in the app itself. Try the following:

Confirm all required splits from the same set were installed together;
Check the device ABI and density;
Do not mix in configuration packages extracted from another device;
Look for UnsatisfiedLinkError, missing resources, or class-loading errors in logcat;
Reinstall the complete version from the original distribution channel.

For a fuller runtime diagnosis, see APK Installed but Won't Open or Keeps Crashing?

Do not handle base.apk this way

Do not merely rename it: a new name cannot turn a split into a complete APK;
Do not extract and recompress it casually: changing its contents breaks the original signature;
Do not mix versions: base, ABI, DPI, and language packages must belong to the same build;
Do not re-sign splits and assemble them: that does not preserve the official update identity;
Do not assume more files are better: a wrong ABI or duplicate split can cause failure;
Do not publicly distribute files extracted from a stranger's device: copyright, account data, authorization, and device compatibility may be involved.

Frequently asked questions

Can I rename base.apk to “AppName.apk” and install it?

Renaming only changes its storage name, not its internal structure. A base missing splits remains incomplete after renaming.

Why does base.apk sometimes install alone?

There are two possibilities: it was already a complete standalone APK that happened to be exported as base.apk, or the system accepted the base but a problem emerges when the app needs another module. Check its source, accompanying files, and pm path output.

Do I need every split_config file?

Not necessarily. You normally need the ABI, density, language, and required feature splits matching this device and app. Wrong or mixed files can also fail, so the original distributor or a trusted installer should choose the set when possible.

Can I rename `.apks` to `.zip` and extract it?

Some .apks files are technically archives, but extracting them manually does not select the correct set for your device. Most users should use bundletool or a trusted installer that explicitly supports the format.

Is base.apk a virus?

No. base.apk is a common system filename, and its name proves neither safety nor maliciousness. Verify its source, signature, hash, permissions, and developer information.

Summary

base.apk often cannot install alone because it belongs to a Split APK set and the device's ABI, DPI, language, or feature modules were not submitted together. But the filename alone is not enough to decide: some complete standalone APKs are also called base.apk. Confirm the origin and split structure, then install a complete, consistent set using the original channel, a trusted compatible installer, adb install-multiple, or a developer's bundletool workflow.