Smali to Java Online

What is Smali?

Smali is the assembly language for the Dalvik virtual machine — the bytecode format Android apps actually run. The name comes from the Icelandic word for "assembler", and its counterpart baksmali ("disassembler") is what apktool uses under the hood to turn a classes.dex file into a tree of readable .smali files.

Each .smali file describes exactly one class: its superclass, its fields, and every method as a sequence of Dalvik instructions with explicit register allocation. Where Java has int x = a + b;, smali has add-int v0, v1, v2. Nothing is inferred and nothing is reconstructed — it is a direct, lossless textual form of the bytecode.

Smali to Java

Going from smali back to Java is a two-stage process, and this tool does both. First the smali source is assembled into a Dalvik executable, which validates that your smali is well-formed and resolves all the register and type references. Then that DEX is decompiled to Java.

This round trip is useful when you have been handed a single smali class out of context — from a bug report, a security advisory, or a colleague — and you want to read it as Java rather than as assembly. Your smali must be a complete class definition, starting with a .class directive; a bare .method block will not assemble on its own.

Smali from APK, XAPK and DEX

Every Android file decompiled on this site now produces a smali/ folder alongside the usual sources/ and resources/ folders. The package structure mirrors the Java tree, so sources/com/example/MainActivity.java has its counterpart at smali/com/example/MainActivity.smali.

Having both is more useful than having either alone, because they fail in different places.

When Smali Beats Decompiled Java

Java decompilers reconstruct source code from bytecode, and reconstruction is a best-effort process. Smali is a transcription, and transcription always succeeds. That difference matters in several common situations:

• Obfuscated and hardened apps — commercial protectors deliberately emit bytecode patterns that break decompilers. The Java output comes back with missing method bodies or // Couldn't decompile comments; the smali is unaffected.
• Verifying what really runs — a decompiler can quietly drop a synthetic method or reorder a switch. If you are doing a security review, the smali is the authoritative record.
• Reflection and dynamic loading — string constants passed to Class.forName are trivial to grep for in smali, where every constant appears literally as const-string.
• Patching — if you intend to modify and rebuild an app, you will be editing smali, not Java. Reading the smali is how you find the instruction to change.

Smali Instruction Basics

Dalvik is register-based rather than stack-based, which makes smali noticeably easier to read than JVM bytecode. A few conventions cover most of what you will see:

• v0, v1, … are local registers; p0, p1, … are parameters, with p0 being this in an instance method.
• invoke-virtual, invoke-static, invoke-direct and invoke-interface distinguish call types; the result is retrieved with move-result.
• Types use JVM descriptors: I is int, Ljava/lang/String; is String, [B is a byte array.
• .line directives carry original source line numbers when the app was not built with debug info stripped.

Frequently Asked Questions