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

  1. Remove the --aapt option entirely and let apktool use its bundled aapt2 (recommended).
  2. 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:".
  3. 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

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


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