Android

Inspect an APK in the browser

Drop a .apk to list its ZIP entries, count DEX files, detect lib/**/*.so, compute SHA-256 with Web Crypto, and pull printable-string hints from binary AndroidManifest.xml. The file is not uploaded to DroidXP. This is not a full AXML decode and not a substitute for apktool.

No file selected

Drop your APK here or click to browse — processing stays on your device 
Select an APK to analyze.

When to use this — and when not to

Use it when you already have an .apk and need a two-minute structural check: is the manifest present, how many DEX files shipped, did the ABI split include the .so you expected, and does the SHA-256 match the file QA downloaded. Typical moments: a CI artifact before testers, a Play upload that failed on version identity, or a sideload you do not want to install blindly.

Do not use it when you need a decoded AndroidManifest.xml tree, smali, resource IDs, or signing-block verification. That is apktool, aapt / aapt2 dump, apksigner verify, or Play Console’s pre-launch report. This page will not unpack an .aab.

How the algorithm works in this browser

The drop zone hands the file to JavaScript as an ArrayBuffer. JSZip (loaded from the CDN on this page) treats the APK as a ZIP and walks every entry. We count names ending in .dex, flag paths under lib/ that end in .so, and note AndroidManifest.xml, resources.arsc, and META-INF when they appear. Web Crypto crypto.subtle.digest('SHA-256', buffer) hashes the entire file, not a single ZIP entry.

The packaged manifest is almost always binary AXML. We do not run a binary XML parser. We extract printable ASCII strings (length ≥ 4) from the manifest bytes and regex-guess package=, versionName, and versionCode. Those hints are best-effort. If the strings are UTF-16, obfuscated, or simply not stored as readable ASCII, the “Possible package” line will be empty even though the app is valid.

Limits and failure modes: JSZip must load (needs the network once for the library). Very large APKs can exhaust tab memory — you will see a hung UI or a thrown error, not a partial server-side job. Split APKs are valid ZIPs; you are inspecting that slice, not the reconstructed install set. If JSZip fails to parse the file, it was not a readable ZIP (wrong extension, truncated download, or a bundle).

Worked example

Take a release APK named com.example.notes-release-24.apk, 18 MB. After drop, a healthy report looks like: 

File: com.example.notes-release-24.apk
SHA-256: 7f3c…a91b
ZIP entries: 412
DEX files: 2
AndroidManifest.xml: present (binary AXML)
Native .so libraries: detected under lib/
Possible package: com.example.notes
Possible versionName: 2.4.0
Possible versionCode: 24003

Read it this way: two DEX files means multidex (or a companion classes2.dex) — expected for a non-trivial Kotlin app. Native libs mean you should confirm the ABI you intended (arm64-v8a vs a leftover armeabi-v7a that bloats the download). Compare the SHA-256 to the hash your Gradle job printed. If versionCode is missing from the heuristic block, do not assume the APK is unsigned — switch to source XML in the Manifest Validator or run aapt dump badging.

Mistakes people make

  • Treating heuristic versionCode as Play-authoritative. Play reads the binary manifest / bundle metadata, not our regex.
  • Dropping a single split APK and concluding “no native libs” because the .so files live in config.arm64_v8a.apk.
  • Comparing SHA-256 of a locally rebuilt APK to a Play-signed artifact. Play App Signing changes the bytes testers install.
  • Uploading an .aab renamed to .apk. The ZIP may open; the layout is not an installable APK.

How this differs from apktool, aapt, and Play Console

  • apktool decodes resources and AXML to text you can edit. We only list and hash.
  • aapt / aapt2 dump badging prints package, versions, and permissions from the compiled manifest. Use that when our string scan is empty.
  • Play Console is the source of truth for upload errors (versionCode collision, missing targeting, signing). Use this page before you burn an upload slot.

Related

Workflow write-up: How to analyze APK files without installing them. Next checks: APK String Extractor and Permissions Decoder.

Frequently asked questions

Does the APK Analyzer upload my APK?

No. The file is read in this tab with the File API and parsed by JSZip in memory. DroidXP does not receive the bytes as part of this tool.

Why is AndroidManifest.xml not shown as XML?

Packaged manifests are binary AXML. This tool lists the archive and scans printable strings. It does not reconstruct the XML tree.

Can I inspect split APKs or App Bundles?

Any readable .apk ZIP works, including one split. .aab is a different format — use bundletool to produce APKs first.

Why is “Possible package” blank on a real app?

The heuristic only sees ASCII strings in the binary manifest. Many builds will not expose package= that way. Use aapt or a decompiled manifest.

What if JSZip fails to load?

The library is loaded from a CDN. Offline or blocked third-party scripts produce “JSZip failed to load.” Allow that script or use a desktop unzip + aapt instead.