iBotPeaches/Apktool · error · AndrolibException

Could not baksmali file: {dexName}

Error message

Could not baksmali file: {dexName}

What it means

SmaliDecoder.decode wrapped an IOException thrown while reading dex entries or writing the baksmali output folders. The message names the dex being decoded and preserves the underlying IOException as the cause.

Source

Thrown at brut.apktool/apktool-lib/src/main/java/brut/androlib/smali/SmaliDecoder.java:119

                if (dexFile.supportsOptimizedOpcodes()) {
                    throw new AndrolibException("Cannot disassemble an odex file without deodexing it: " + dexName);
                }

                String dirName = "smali";
                if (dexNum > 1 || !dexName.equals("classes.dex")) {
                    dirName += "_" + dexName.substring(0, dexName.lastIndexOf('.')).replace('/', '@');
                    if (dexNum > 1) {
                        dirName += dexNum;
                    }
                }

                decodeFile(dexFile, new File(outDir, dirName));
            }

            mDexFiles.add(dexName);
        } catch (IOException ex) {
            throw new AndrolibException("Could not baksmali file: " + dexName, ex);
        }
    }

    private void decodeFile(DexBackedDexFile dexFile, File smaliDir) {
        int jobs = Math.min(Runtime.getRuntime().availableProcessors(), 6);

        BaksmaliOptions options = new BaksmaliOptions();
        options.parameterRegisters = true;
        options.localsDirective = true;
        options.sequentialLabels = true;
        options.debugInfo = mDebugMode;
        options.codeOffsets = false;
        options.accessorComments = false;
        options.allowOdex = false;
        options.deodex = false;
        options.implicitReferences = false;
        options.normalizeVirtualMethods = false;
        options.registerInfo = 0;

View on GitHub (pinned to 79b63384d7)

Solutions

  1. Inspect the cause: a write-side exception points at outDir (permissions/space), a read-side one at the APK
  2. Verify dex integrity: `unzip -t app.apk` and confirm CRCs pass
  3. Free space or fix permissions on the output directory, then rerun
  4. If the dex itself is damaged, re-obtain the APK; do not retry unchanged on a known-corrupt input

Example fix

# before
apktool d app.apk -o /read-only/out   # Could not baksmali file: classes.dex

# after
mkdir -p /tmp/work/out && chmod u+w /tmp/work/out
apktool d app.apk -o /tmp/work/out
Defensive patterns

Strategy: try-catch

Validate before calling

// Check writable output and readable input before decode
if (!outDir.isDirectory() || !outDir.canWrite()) throw new IOException("outDir not writable: " + outDir);
long free = outDir.getUsableSpace();
if (free < apkFile.length() * 4) System.err.println("Warning: low disk space for smali output");

Try / catch

try {
    decoder.decode(dexName, outDir);
} catch (AndrolibException e) {
    if (e.getMessage() != null && e.getMessage().startsWith("Could not baksmali file")) {
        IOException cause = (IOException) e.getCause();
        // read side: corrupt dex -> re-obtain APK; write side: fix outDir, then retry ONCE
    } else { throw e; }
}

Prevention

When it happens

Trigger: Any IOException from the container streams (truncated dex entry, CRC failure mid-read) or from writing smali files to outDir (disk full, permission denied, deleted parent directory) during the decode loop.

Common situations: Output directory on a full or read-only mount; APK with a corrupt dex entry that only fails when its bytes are read; long decode runs interrupted by disk/quota limits in CI.

Related errors


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