Decompiling an Android APK file turns a packaged app back into a form that a person can study. APKTool handles resources and the manifest and the low level code layout. Jadx handles Java style code that reads much like original source. Together they give a fuller picture than either tool alone. APKTool is strong for layout and resource work. Jadx is strong for logic and flow work. A beginner should learn both tools in small steps. Start with a test app that you built yourself. That choice makes the learning safe and clear. You can compare tool output with your own source code. That comparison shows what each tool preserves and what it loses. It also builds trust in the results. For a wider view of the field see APK reverse engineering basics.
An APK file is a compressed archive with a fixed structure. It holds DEX files and resources and native libraries and a signature block. APKTool unpacks the archive and decodes resources into readable XML. It also disassembles DEX code into Smali code. Jadx reads DEX code and rebuilds Java style classes. The two outputs look different but describe the same app. Smali is close to the machine and shows exact calls. Java style code is easier to read for logic and flow. Analysts switch between the two views as needed. That switch is a core skill in this work.
Preparing A Clean Workspace
A clean workspace prevents confusion and lost files. Create one folder for the original APK file. Create a second folder for APKTool output. Create a third folder for Jadx output. Keep the original file read only when possible. Copy the file before any experiment. Name folders with the app name and the date and the tool name. That naming makes later review simple. It also stops test files from mixing with release files. A clean workspace matters more as projects grow. Large apps produce thousands of files. Without order the analyst wastes time searching for one class.
Check tool versions before starting work. APKTool and Jadx both change with new Android versions. An old version may fail on a new APK format. A new version may change output layout in small ways. Record the version used in your project notes. That record helps another person repeat your work. It also helps you explain a strange result later. Install the tools in a folder that is easy to reach from a terminal. Test each tool with a tiny file before a large app. That quick test catches setup errors early.
Decoding With APKTool
APKTool decoding is a simple command with a clear result. The tool reads the APK file and writes an output folder. That folder holds decoded resources and Smali code and the manifest. Layout files appear as readable XML files. String files appear in resource folders by language. Image files appear in density folders. The manifest shows activities and services and permissions. Smali files appear in folders that match the package layout. Each Smali file holds one class in low level form. The analyst can open any file in a text editor. That direct access makes resource study fast.
Decoded output is not the same as original source. Resource names may change during the build. Some values may appear in a compiled form. Smali code may look verbose compared with Java code. That verbosity is normal and useful. It shows the exact calls that the app makes. It also shows the exact order of those calls. Analysts read Smali when Java output is unclear. They also read Smali when they need to change a small detail. For resource changes see the work on modifying layout resources in a later article.
Reading Code With Jadx
Jadx turns DEX code into Java style classes. The output opens in a graphical view or as exported files. Classes appear in a tree that matches the package layout. Methods appear with readable names when the app keeps them. Control flow appears as loops and branches and returns. That readable form helps a person follow app logic. It helps find where a feature starts and where it ends. It also helps find where data moves from input to storage. Jadx may fail on heavily changed code. It may show errors for some methods. In that case Smali remains the fallback view. The analyst should not trust a single failed method as proof of a flaw.
Search is a key skill in Jadx work. Search for a string that appears on a screen. Search for a permission name or a network host. Search for a class name linked to a feature. Each search narrows the code to a small set of files. Read those files in full before drawing a conclusion. Check callers of a method as well as the method itself. A method may look risky alone but prove safe in context. A method may look safe alone but prove risky when called with bad input. Context decides the real meaning.
Common Problems And Fixes
Decoding can fail for several clear reasons. A damaged APK file will fail in both tools. A new format may need a newer tool version. A large app may need more memory for Jadx. A protected app may use tricks to slow decompilers. In each case check the error message first. The message often names the failing file or step. Try the other tool to see if it handles the same file. Try a smaller test app to check your setup. If the test app works then the problem lies with the target file. If the test app fails then the problem lies with your setup. That simple split saves a lot of guesswork.
Output errors also need care. A missing resource may point to a split APK file. A split app stores parts in separate files. Jadx may show a class with no body when code is native. Native code lives in shared libraries and needs a different tool. A class with odd names may be the result of name shortening. That process renames classes to short symbols. It does not change the logic but it hides intent. Analysts learn to follow calls rather than trust names alone. That habit keeps analysis honest.
apktool d sample.apk -o sample-out
apktool b sample-out -o sample-new.apk
jadx -d jadx-out sample.apk
ls sample-out/res/layoutRebuilding After A Change
Rebuilding is the reverse step after a study or a small edit. APKTool can rebuild a decoded folder into a new APK file. The new file needs signing before it can run on a device. Signing for a test build uses a debug key on a test device. Never share a rebuilt app as if it were the original release. Label test builds clearly in file names and notes. Test the rebuilt app on a spare device or an emulator. Check the changed feature first. Then check nearby features for side effects. A small change can break a layout or a flow in a surprising way. Learning about decompiling and recompiling APK files gives the full rebuild workflow in order.
Keep a log of every rebuild step. Record the input file and the tool version and the change made. Record the test device and the result. That log turns a lucky success into a repeatable process. It also helps you undo a change that caused a problem. If a rebuild fails then compare the new output with the last good output. The difference often points to the bad edit. Fix one problem at a time. Test after each fix. That slow pace feels tedious but it works.
Organising Large Decoding Projects
Large apps produce thousands of decoded files. A project folder needs a clear layout from the start. Keep APKTool output and Jadx output in separate folders. Keep notes in a third folder with dates. Keep the original file in a fourth folder that stays read only. That layout stops files from mixing by accident. It also makes it easy to find a class later. A messy folder wastes time on every search. A tidy folder saves time on every review. Start tidy even for a small project. The habit will pay off on a large project.
Naming rules help even more than folder layout. Name a notes file with the app name and the date. Name a test build with the app name and a test tag. Name a screenshot with the feature it shows. Avoid vague names like final or new or test. Vague names cause confusion after a few days. A clear name tells the story at a glance. It also helps a peer understand the project without asking. Write the naming rule at the top of your notes. Follow that rule for every new file. Consistency matters more than cleverness here.
Search skills matter most in a large project. Search by string to find a screen text. Search by class name to find a feature. Search by permission to find a risky area. Save useful searches in your notes with the result count. A saved search can be rerun after a new decode. That rerun shows what changed between versions. It also shows if a fix removed a risky call. Compare search results across versions with care. A missing result can mean a fix or a tool error. Verify a missing result with a second search method.
Version comparison is a useful skill for analysts. Decode two versions of the same test app. Compare the manifest first for new permissions. Compare the resource folders next for new screens. Compare the code folders last for new methods. Note each change in a short list. That list tells a story about the update. It can reveal a new feature or a new data flow. It can also reveal a removed feature. A version diff turns a large app into a small change list. That list is far easier to review than a full decode.
Time management also matters in a large project. Set a clear question before opening a tool. Stop when the question has an answer. Record the answer and the evidence. Move to the next question only after that record exists. Without a question the work can drift for hours. With a question the work stays focused and useful. A short session with a clear question beats a long session with no goal. That rule holds for beginners and for experts alike. It also makes progress easy to show to a peer.
- Create separate folders for each tool output.
- Name files with app name and date.
- Save useful searches with result counts.
- Compare versions one area at a time.
- Stop when the set question has an answer.
- Keep the original file read only.
Keeping Notes That Others Can Follow
Notes should let another analyst repeat your work without asking you. A note should state the input file and the tool version. It should state the command or the steps used. It should state the result in plain words. It should state the next question that remains. That five part structure covers most cases. It also keeps notes short and useful. A note without a tool version cannot be repeated exactly. A note without a result cannot guide a fix. A note without a next step leaves the project stalled. Write notes during the work rather than after it. Details fade fast after a session ends.
Notes also help you learn from mistakes. A failed decode teaches a tool limit. A failed rebuild teaches a format detail. A wrong guess teaches a pattern to avoid. Record failures with the same care as successes. A failure note should state the error and the fix tried. It should state whether the fix worked. Over time failure notes become a troubleshooting guide. That guide saves time on future projects. It also helps a peer avoid the same trap. Good analysts value failure notes highly.
- State the input file and tool version in each note.
- Record the command and the result in plain words.
- Note failures with the fix tried.
- Write notes during the work not after it.
Comparing Tool Output Side By Side
Comparing APKTool and Jadx output side by side teaches a lot about an app. Open the same class in both tools. Note where the Java output is clear and where it is vague. Open the Smali output for the vague parts. That comparison shows the strengths of each view. It also shows where a decompiler made a guess. A guess in Java output can look like a fact. Smali output reveals the guess as a simpler instruction. That insight protects an analyst from overtrusting a tool. It also builds skill in switching views at the right time.
Side by side work also helps with resource questions. A layout file in APKTool output shows the screen structure. A Java class in Jadx output shows how the screen is used. Together they explain a feature fully. A layout alone cannot show logic. A class alone cannot show the screen. Use both views when a feature is unclear. That pair of views answers most early questions. It also prepares an analyst for harder code study later.
Keep a comparison note for a class that taught you something. State the class name and the tool outputs. State what each output revealed. State what remained unclear after both views. That note becomes a reference for similar classes. It also shows a peer how you reached a conclusion. Good comparison notes are short and specific. They avoid vague claims about a whole app. They focus on one class and one lesson at a time.
Tool output also changes with app size. A small app decodes fast in both tools. A large app may need more memory for Jadx. A large app may produce a huge Smali folder. Plan time and disk space for large apps. Close other apps before a large decode. That simple step avoids a memory error. It also keeps the decode from slowing a whole machine.
Readers who want a related topic can explore DEX code and Smali layouts next in this series.
Conclusion
APKTool and Jadx form a strong pair for APK study. APKTool gives resources and Smali and the manifest. Jadx gives readable Java style logic. Together they support study and testing and small fixes. Beginners should practise on their own apps first. They should keep a clean workspace and clear notes. They should verify findings across both tools. That method builds skill that transfers to larger apps. It also keeps the work safe and honest.
The steps above follow the approach described in the official developer documentation for Android applications and in widely used testing guidance for mobile software.
