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
- Inspect the cause: a write-side exception points at outDir (permissions/space), a read-side one at the APK
- Verify dex integrity: `unzip -t app.apk` and confirm CRCs pass
- Free space or fix permissions on the output directory, then rerun
- 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
- Pre-check disk space and output permissions
- Run `unzip -t` on input APKs in CI before decode jobs
- Classify the cause (read vs write) before retrying
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
- Could not generate:
- Could not decode arsc file.
- Error while reading chunk header.
- Error while skipping chunk.
- Error while skipping chunk header.
AI-assisted analysis of iBotPeaches/Apktool@79b63384d7 (2026-08-14).
Data as JSON: /api/errors/762075a3be01f1db.
Report an issue: GitHub.