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
- Verify manually: `/path/to/aapt2 version` — fix whatever it reports (chmod +x, install libc, use correct arch).
- Drop --aapt and let apktool use its bundled aapt2, which matches supported platforms.
- 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
- Probe custom binaries with `binary version` before handing them to apktool.
- Match the aapt2 architecture to the host (or install Rosetta on Apple Silicon).
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
- aapt2 binaries are not available for 32-bit platforms.
- Could not identify platform: " + OSDetection.returnOS()
- Could not identify aapt binary version:
- Legacy aapt is no longer supported.
- Malicious value for apkFileName: " + mApkFileName
AI-assisted analysis of iBotPeaches/Apktool@79b63384d7 (2026-08-14).
Data as JSON: /api/errors/f47060dc62ef3411.
Report an issue: GitHub.