iBotPeaches/Apktool · error · AndrolibException

Could not execute aapt binary at location:

Error message

Could not execute aapt binary at location: 

What it means

AndrolibException from AaptManager.getBinaryVersion() when OS.execAndReturn([bin, "version"]) returns null, meaning the aapt binary could not be executed at all. This is raised while validating a custom --aapt binary (or the bundled one) before a build: the version probe subprocess failed to start or produced no output, so apktool cannot confirm it is aapt2.

Source

Thrown at brut.apktool/apktool-lib/src/main/java/brut/androlib/res/AaptManager.java:84

        setBinaryExecutable(binFile);
        return binFile;
    }

    private static void setBinaryExecutable(File binFile) throws AndrolibException {
        if (!binFile.isFile() || !binFile.canRead()) {
            throw new AndrolibException("Could not read aapt binary: " + binFile.getPath());
        }
        if (!binFile.setExecutable(true)) {
            throw new AndrolibException("Could not set aapt binary as executable: " + binFile.getPath());
        }
    }

    public static int getBinaryVersion(File binFile) throws AndrolibException {
        setBinaryExecutable(binFile);

        String versionStr = OS.execAndReturn(new String[] { binFile.getPath(), "version" });
        if (versionStr == null) {
            throw new AndrolibException("Could not execute aapt binary at location: " + binFile.getPath());
        }

        return getVersionFromString(versionStr);
    }

    public static int getVersionFromString(String versionStr) throws AndrolibException {
        if (versionStr.startsWith("Android Asset Packaging Tool (aapt) 2:")) {
            return 2;
        }
        if (versionStr.startsWith("Android Asset Packaging Tool (aapt) 2.")) {
            return 2; // Prior to Android SDK 26.0.2
        }
        if (versionStr.startsWith("Android Asset Packaging Tool, v0.")) {
            return 1;
        }
        throw new AndrolibException("Could not identify aapt binary version: " + versionStr);
    }
}

View on GitHub (pinned to 79b63384d7)

Solutions

  1. Verify manually: `/path/to/aapt2 version` — fix whatever it reports (chmod +x, install libc, use correct arch).
  2. Drop --aapt and let apktool use its bundled aapt2, which matches supported platforms.
  3. On Apple Silicon, ensure Rosetta 2 is installed if using an x86_64 aapt2, or use the universal build-tools binary.

Example fix

# before
apktool b app --aapt ./aapt2   # not executable
# after
chmod +x ./aapt2 && ./aapt2 version
apktool b app --aapt ./aapt2
Defensive patterns

Strategy: validation

Validate before calling

if (!aaptFile.canExecute() || OS.execAndReturn(new String[]{aaptFile.getPath(), "version"}) == null) {
    throw new IllegalStateException("aapt binary not executable on this host: " + aaptFile);
}

Prevention

When it happens

Trigger: Passing --aapt /path/to/aapt2 where the file is not executable (setExecutable failed or perms changed), the binary is for the wrong architecture (e.g. x86_64 binary on arm64 without Rosetta), glibc is too old for the binary, or the path does not exist.

Common situations: Custom aapt2 copied without preserving the exec bit; running a bundled linux x86_64 aapt2 on arm64 hardware; minimal containers missing libc++/glibc versions required by newer build-tools.

Related errors


AI-assisted analysis of iBotPeaches/Apktool@79b63384d7 (2026-08-14). Data as JSON: /api/errors/f47060dc62ef3411. Report an issue: GitHub.