APKLab: an Android reverse-engineering workbench inside VS Code

Who APKLab is built for, and what it replaces

APKLab targets people who modify Android packages rather than merely read them. The README lists the workflow plainly: decode and edit resources, disassemble to smali, decompile to Java, then rebuild, sign and install. Each of those steps normally means a separate command-line tool with its own flags and output directory. APKLab keeps them in one place and treats the Apktool project folder as the unit of work, with apktool.yml as the anchor file that most context-menu actions hang off.

The intended user is a security analyst or an Android developer doing patch-level work: changing a manifest flag, removing a certificate pinning check, adding logging to a method, or generating Frida hooks for a class. The extension is not a general disassembler. Anything that lives in a .so file is outside its scope, and the README never claims otherwise. If your target logic is native, this is the wrong tool regardless of how good the smali support is.

How APKLab orchestrates Apktool, jadx and smali-lsp

APKLab is a VS Code extension written in TypeScript, published under the identifier Surendrajat.apklab, with ./dist/extension as its entry point and onStartupFinished as its activation event. It does not implement decompilation itself. The README states that it integrates Apktool, smali-lsp, jadx, uber-apk-signer and apk-mitm, and the settings expose each of those as a configurable path: apklab.apktoolPath, apklab.apkSignerPath, apklab.jadxDirPath, apklab.smaliLspPath and apklab.javaPath. That design has a concrete consequence: the tools are external JARs and directories on disk, not bundled binaries, so the extension is only as current as the versions you point it at.

Smali editing is handled by smali-lsp, which the README credits with go to definition, find references, hover, call and type hierarchy, code lens, completion and diagnostics. The extension also contributes a smali language definition with a .smali extension mapping and a TextMate grammar at ./syntaxes/smali.tmLanguage.json. In practice the editor experience for smali is the part that distinguishes APKLab from running apktool d in a terminal and opening the output in a generic editor. jadx handles the Java-source view; the two representations coexist against the same project directory.

Installing APKLab and running a first decode, rebuild and sign

The README points at two marketplaces: the Visual Studio Marketplace listing and the Open VSX listing at open-vsx.org/extension/Surendrajat/apklab. Install from whichever one your editor uses, then confirm the prerequisites. The README requires JDK 17 or later and tells you to check it in a shell. quark-engine is optional and only needed for the malware analysis report; adb is optional and only needed to install builds on a device.

java -version

If that command is not found, the README links to Adoptium for a download. Once Java is in place, open the Command Palette with Ctrl+Shift+P and run the open command.

APKLab: Open an APK

That decodes the APK into an Apktool-style project. You can also open an existing project folder directly, which the README lists as an alternative. If Java lives somewhere unusual, point the extension at it rather than editing your PATH.

{
  "apklab.javaPath": "/usr/lib/jvm/java-17/bin/java"
}

With the project open, right-click on or inside apktool.yml and choose the rebuild command. Rebuilding produces output in the dist directory, which is where the install command expects to find the .apk file.

APKLab: Rebuild the APK
APKLab: Install the APK

Signing uses uber-apk-signer by default. To use your own key instead, the README documents four keystore settings: apklab.keystorePath for a .jks or .keystore file, apklab.keystorePassword, apklab.keyAlias and apklab.keyPassword. Two further settings are worth knowing before you start: apklab.initProjectDirAsGit initialises the output directory as a Git repository so you can track your edits, and apklab.updateTools controls whether the extension checks for tool updates and shows a notification.

HTTPS inspection and Frida hooks: the features that need a caveat

Two features go beyond editing. The MITM patch is invoked by right-clicking apktool.yml and choosing APKLab: Prepare for HTTPS inspection, which applies apk-mitm to the project. The Frida gadget injection is invoked the same way, and the README describes it as asking you to select the gadget .so file and target architecture, after which the main activity is patched automatically. Automatic main-activity patching is convenient, and it is also the step most likely to break on an app with an unusual launcher configuration. The README does not document a rollback for either operation. If you run them on a project without version control, you have no clean way back, which is exactly the case apklab.initProjectDirAsGit exists to cover.

Frida hook generation works differently. Right-clicking inside a .method in a .smali file and choosing APKLab: Generate Frida Hook appends the hook to frida_hooks.ts in the project root. That is an append, not a rewrite, so repeated generation accumulates content in one file. The README does not describe deduplication or a way to regenerate the file from scratch.

Platform limits, JDK coupling and where APKLab stops

The requirements section names Linux, Mac and WSL2 as supported. Native Windows is absent from that list, and the README does not describe a Windows path, so Windows users are expected to work through WSL2. That is a real constraint if your device tooling, USB drivers or signing keys live on the Windows side.

The JDK 17 floor is a second constraint. The extension declares vscode ^1.91.0 in package.json, so older VS Code builds will not load it at all. Java 17 is also a hard requirement rather than a preference; the README does not state what happens with an older JRE, and it does not describe an automatic JDK provisioning step. You supply Java, the extension consumes it.

The clearest boundary is the one the feature list implies. Decoding, smali disassembly, Java decompilation, signing and installation are all covered. Native library analysis, dynamic instrumentation beyond Frida gadget injection, and anything resembling a debugger are not. The README also does not document rollback for MITM patching or gadget injection, does not describe how the malware analysis report is composed beyond the quark-engine requirement, and does not state a recovery path if a rebuild fails partway through. Treat the project directory as disposable and keep it in Git.

APKLab compared with running Apktool and jadx by hand

The honest alternative is the toolchain APKLab wraps: Apktool for decode and rebuild, jadx for Java source, uber-apk-signer for signing, driven from a shell. That approach has no JDK 17 coupling imposed by an extension, no VS Code version floor, and no AGPL-3.0 obligations on your own work. It also works identically on native Windows, which APKLab does not claim to support.

The difference is not capability but interaction cost. With the manual route, every rebuild is a command you retype with the right paths, and smali editing happens in whatever editor you already use, without go to definition, find references or diagnostics on .smali files. APKLab's contribution is that smali becomes a first-class language in the editor and that the decode-rebuild-sign-install loop is four context-menu actions against one file. If you patch an APK once, the manual route is fine. If you iterate on the same project for days, the editor integration is the reason to use APKLab.

A second alternative worth naming is apk-mitm used on its own for HTTPS inspection. APKLab exposes it as one command, but the underlying tool is what does the work, and the README treats it as an integrated component rather than a reimplementation.

Licence, maintenance and the upgrade cost you are taking on

APKLab is licensed AGPL-3.0, and package.json carries the license field as SEE LICENSE IN LICENSE with the LICENSE file at the repository root. The AGPL is a strong copyleft licence with a network-use clause, which matters if you were considering embedding or extending the extension in something you distribute or expose over a network. This is a description of the licence identifier, not legal advice; if your organisation has rules about AGPL dependencies, check them before you build on the code rather than merely running the extension.

The repository is not archived, and the last push was on 2026-07-16. The extension declares version 2.0.0 and engines.vscode ^1.91.0. Because the decompiler, signer and language server are external paths rather than bundled dependencies, upgrading APKLab and upgrading Apktool are separate operations: you can move to a newer apktool.jar by changing apklab.apktoolPath alone. The README documents support for Apktool 3.0+ CLI arguments and for Apktool-style projects via apktool.yml, so projects created by the CLI remain usable here. The maintenance cost that falls on you is keeping those external JARs current, since apklab.updateTools only controls a notification.

Editorial conclusion

Adopt APKLab if your work is smali and resource patching on Linux, macOS or WSL2, and you already keep JDK 17 available. Skip it if you need native code analysis, or if you refuse to accept AGPL-3.0 obligations or to store keystore passwords in settings.json. Before relying on it, verify that java -version reports 17 or later and that VS Code is at 1.91.0 or newer, since the extension declares that engine floor and will not activate below it.

Frequently asked questions

Official sources

1. APKLab/APKLab on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README