iBotPeaches/Apktool · error · AndrolibException
Legacy aapt is no longer supported.
Error message
Legacy aapt is no longer supported.
What it means
Thrown (as an AndrolibException) by the apktool CLI when the user supplies a custom aapt binary via --aapt and that binary reports version 1. Apktool only supports aapt2; the legacy aapt was removed because modern resource tables (resources.arsc v2+) cannot be rebuilt with it. The CLI catches the exception, prints the message, and exits with code 1.
Source
Thrown at brut.apktool/apktool-cli/src/main/java/brut/apktool/Main.java:585
config.setNoApk(true);
}
if (cli.hasOption(buildNoCrunchOption)) {
config.setNoCrunch(true);
}
if (cli.hasOption(buildCopyOriginalOption)) {
config.setCopyOriginal(true);
}
if (cli.hasOption(buildDebuggableOption)) {
config.setDebuggable(true);
}
if (cli.hasOption(buildNetSecConfOption)) {
config.setNetSecConf(true);
}
if (cli.hasOption(buildAaptOption)) {
try {
String aaptBinary = cli.getOptionValue(buildAaptOption);
if (AaptManager.getBinaryVersion(new File(aaptBinary)) == 1) {
throw new AndrolibException("Legacy aapt is no longer supported.");
}
config.setAaptBinary(aaptBinary);
} catch (AndrolibException ex) {
System.err.println(ex.getMessage());
System.exit(1);
return;
}
}
File outFile = null;
if (cli.hasOption(buildOutputOption)) {
if (cli.hasOption(buildNoApkOption)) {
printOptionConflict(buildOutputOption, buildNoApkOption);
} else {
outFile = new File(cli.getOptionValue(buildOutputOption));
}
}View on GitHub (pinned to 79b63384d7)
Solutions
- Remove the --aapt option entirely and let apktool use its bundled aapt2 (recommended).
- Point --aapt at an aapt2 binary (e.g. $ANDROID_HOME/build-tools/<ver>/aapt2) and verify it prints `aapt2 version` output like "Android Asset Packaging Tool (aapt) 2:".
- Update the SDK build-tools to 26.0.2+ so the binary identifies itself as aapt2.
Example fix
# before apktool b dist/myapp -o myapp.apk --aapt /opt/sdk/build-tools/25.0.3/aapt # after apktool b dist/myapp -o myapp.apk # or, if a custom binary is required: apktool b dist/myapp -o myapp.apk --aapt /opt/sdk/build-tools/33.0.0/aapt2
Defensive patterns
Strategy: validation
Validate before calling
// Before passing --aapt, probe the binary yourself
String out = OS.execAndReturn(new String[]{aaptPath, "version"});
if (out == null || !out.startsWith("Android Asset Packaging Tool (aapt) 2")) {
throw new IllegalArgumentException("Not a usable aapt2 binary: " + aaptPath);
} Prevention
- Do not pin --aapt to old build-tools paths in scripts; prefer the bundled aapt2.
- Assert `aapt2 version` output starts with 'Android Asset Packaging Tool (aapt) 2' in CI before invoking apktool.
When it happens
Trigger: Running `apktool b app-dir --aapt /path/to/old/aapt` where `aapt version` prints a string starting with "Android Asset Packaging Tool, v0." (parsed as version 1 by AaptManager.getVersionFromString). Also triggered when the given path is an old SDK build-tools aapt binary instead of aapt2.
Common situations: Scripts or CI setups written against apktool 2.x that pinned an old build-tools aapt path; upgrading apktool to a version that dropped aapt1 support; pointing --aapt at the wrong file inside build-tools (aapt vs aapt2).
Related errors
- Could not execute aapt binary at location:
- Could not identify aapt binary version:
- Stream advanced past chunk end.
- Unexpected EOF while skipping chunk.
- Error while skipping chunk.
AI-assisted analysis of iBotPeaches/Apktool@79b63384d7 (2026-08-14).
Data as JSON: /api/errors/807bd05cb7919217.
Report an issue: GitHub.