Analyze split APKs, XAPK and APKS locally

Choose the correct input set

A base APK alone may omit code, language strings, device resources or native libraries. Collect one app version's base APK and relevant splits before drawing conclusions about missing content. AppUnpack accepts a flat APK directory or an unambiguous .xapk/.apks collection you are authorized to inspect.

The extension does not establish that every contained APK belongs together. A bundletool archive with toc.pb may contain alternative device variants and is refused. First use upstream bundletool extract-apks to select a device-specific set, then analyze that extracted directory. AppUnpack does not convert an AAB or create an installable merged APK.

Install the split-analysis prerequisites

Install Git, Node.js 24.11 or newer, npm, a Java 17 or newer JDK with compiler modules, and Python 3.10 or newer. Follow the APK decompilation guide for the initial checkout and install-tools command. The pinned JADX engine performs decompilation; Python prepares and checks the APK set.

If Python is not resolved correctly, set APPUNPACK_PYTHON to your executable's absolute path. For example, in PowerShell:

$env:APPUNPACK_PYTHON = 'C:\Python312\python.exe'
node bin/appunpack.mjs doctor

Replace that sample path with your installed Python. doctor checks the Java/JADX connection, not whether a particular collection is complete or compatible.

Analyze a directory or archive

For a directory input, keep the selected APKs directly inside one folder. Run one command from the AppUnpack checkout:

node bin/appunpack.mjs splits ./apk-set --output ./reports/split-analysis

For an archive, use its actual path. These are alternative examples; each destination must be new:

node bin/appunpack.mjs splits ./Example.xapk --output ./reports/xapk-analysis
node bin/appunpack.mjs splits ./Example.apks --output ./reports/apks-analysis

--output is required. The direct form node bin/appunpack.mjs ./Example.xapk --output ./reports/xapk-analysis also selects split analysis. No other analysis flags are supported by splits. Existing output directories are preserved, including partial output from failed attempts.

Preparation copies the APK members into owned inputs/, records SHA-256 values and checks for exactly one base, matching package/version identifiers, unique split names and referenced feature splits. Unsafe paths, duplicate entries and unsupported archive layouts are refused before combined analysis.

Inspect combined code and per-part resources

Resource paths can overlap between splits. Use the per-part directories to preserve those distinctions; their numbering follows the parts list. Keep the report alongside recovered files so a reader can identify which artifacts produced a finding.

Collect an installed app with ADB

With separately installed Android SDK Platform Tools and a device that has authorized your computer, list devices and explicitly select the correct serial:

node bin/appunpack.mjs devices
node bin/appunpack.mjs pull com.example.app --device emulator-5554 --output ./reports/pulled
node bin/appunpack.mjs splits ./reports/pulled --output ./reports/pulled-analysis

Replace the sample package and serial. pull copies base/split paths reported by that package manager and records local hashes. It does not install or launch the app. An update during transfer can invalidate the set; repeat collection if its identities no longer agree.

Treat completeness as a separate question

Matching package and version declarations do not verify signatures, device compatibility or that every required module was supplied. Expansion OBB payloads are not analyzed. Java recovery can remain partial even for a consistent set, and recovered code does not include the app's backend.

Read the extended Android workflow reference for size limits and tool setup. Return to the coverage table or verification record to check what has actually been tested.