Updated Jul 15, 2026

Utilities

Unpack an Android APK into smali, resources, and manifest

Decode Android APK files into smali sources and resources.

Agent

overview

What apktool-decode does

Reach for apktool-decode when an APK is opaque and you need a greppable tree before endpoint or secret scanners run. It turns one package into smali, decoded resources, and a readable AndroidManifest.xml.

Input is apk-file (FILE); output is a FOLDER. Set --no-res or --no-src to skip a half on large builds. Use --frame-path or --frame-tag when vendor frameworks must resolve or resource decode fails.

Trickest exposes one APK file as input and a decoded FOLDER as output. Send that folder to a tool or script that explicitly accepts folders. For URL extraction with apkurlgrep, supply the original APK file separately; it does not accept this decoded folder.

source bitbucket.org/iBotPeaches/apktool

use cases

Where apktool-decode fits

Unpack an APK for static analysis

Decode an APK into smali, resources, and a readable manifest so the app's logic, permissions, and components can be reviewed offline.

Surface endpoints and secrets in app code

Produce a source tree that endpoint extractors and secret scanners can grep for hardcoded URLs, API keys, and credentials.

Read the manifest for attack surface

Decode AndroidManifest.xml to inspect exported activities, services, and permissions that define what the app exposes.

Decode a batch of APKs at scale

Run the node across a set of collected APKs in one workflow, writing a decoded tree per app so a fleet of mobile builds can be reviewed in a single pass.

reference

apktool-decode inputs and flags

5 inputs
NameTypeFlagDescription
apk-fileFILE·APK file to decode.
no-resBOOLEAN--no-resDo not decode resources.
no-srcBOOLEAN--no-srcDo not decode sources.
frame-pathFOLDER--frame-pathUse framework files located in this folder.
frame-tagSTRING--frame-tagUse framework files tagged by this tag.

Showing key inputs. apktool-decode exposes 5 inputs in total.

example

Run apktool-decode

apktool-decode · command
# Full decode matching the retained owned-fixture output
apktool d fixture.apk --frame-path /tmp/framework -o decoded
sample output
I: Using Apktool 2.7.0 on fixture.apk
I: Loading resource table...
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: /tmp/framework/1.apk
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values */* XMLs...
I: Baksmaling classes.dex...
I: Copying assets and libs...
I: Copying unknown files...
I: Copying original files...

guidance

Choosing apktool-decode

Use when you have an APK and need smali, resources and a readable manifest for static review. This node decodes packages; it does not rebuild them or run an Android device.

apkurlgrep

Accepts the original APK file for URL extraction. It does not accept apktool-decode’s FOLDER output.

jadx

Decompiles APKs to readable Java instead of smali. Prefer when Java reconstruction is the goal.

faq

apktool-decode questions

A folder with smali disassembly, decoded resources, and a readable AndroidManifest.xml. That tree is what you grep and feed to the next node.

Yes. Set --no-res to leave resources packed when you only need code, or --no-src to skip smali when you only need the manifest and resources.

For apps that reference a device custom framework, common on vendor or system APKs. --frame-path points at framework files; --frame-tag selects a tagged set so resource references resolve.

Use a folder-capable text search or secret scanner on the decoded output. apkurlgrep takes an APK FILE, so give it the original package rather than the decoded folder.

Not with this node. Upstream apktool has apktool b for rebuild. Trickest exposes decode only, so rebuild locally when you need a modified package.

Yes. The sample is retained stdout from the exact existing public image decoding a self-owned synthetic APK offline with Apktool 2.7.0. Full decode, --no-src and --no-res cases passed; a malformed input returned nonzero. This does not establish device compatibility or a new platform smoke.

Run apktool-decode yourself

Retained stdout from an offline test of the existing public image on a self-owned synthetic APK. The sample is a full decode with Apktool 2.7.0; separate --no-src and --no-res tests passed. This is local native evidence, not a new platform smoke or device run.

Facts on this page come from the live Trickest tool library.