App On The Go
Log in
Free tool · no signup · file deleted after analysis

APK Analyzer
Decode any Android build.

Drop an .apk file to inspect its package name, version, min/target Android version, permissions list, launcher activity, and app icon — straight from AndroidManifest.xml. Nothing is saved on our end.

File is processed in memory and deleted immediately. Nothing is shared with anyone.

What you'll see

  • Identity — app name, package name, version, build number, app icon
  • Android requirements — min & target SDK levels, with friendly version names
  • Launcher activity — the entry point Android opens when you tap the app icon
  • Permissions — every permission declared in the manifest, with the dangerous ones flagged in red

Behind the scenes we use the same php-apk-parser library and resource-table walker that the Android SDK ships with. Same accuracy as aapt2 dump, but without installing the Android SDK.

APK 101

What an APK file actually contains

An APK (Android Package Kit) is a ZIP archive with a specific layout. Renaming an .apk to .zip and unzipping it reveals the entire app: the compiled bytecode, the resources, the manifest declaring what the app does, and the signing block proving who built it.

Inside every APK

  • AndroidManifest.xml — the app's identity card. Package name, version, min/target SDK, permissions, the list of activities and services. Binary-encoded XML; this analyzer decodes it on the fly.
  • classes.dex (and classes2.dex…) — the compiled Java/Kotlin bytecode in Android's Dalvik Executable format.
  • resources.arsc — the compiled resource table. Maps integer resource IDs to actual values (strings, drawables, colors, themes).
  • res/ — uncompiled resources Android decodes at runtime (images, layouts, raw assets).
  • assets/ — raw files the app bundles untouched.
  • lib/ — native code split by architecture (arm64-v8a, armeabi-v7a, x86_64).
  • META-INF/ — signing block (CERT.RSA, CERT.SF, MANIFEST.MF) that proves the APK was built by the developer with their signing key.

Why analyze without installing?

Common reasons developers run an APK through an analyzer instead of adb install-ing it:

  • Sanity check before sharing — confirm the version, package name, and signing identity match what you intended before you send it to testers.
  • Permission audit — a one-glance view of every uses-permission declaration. Dangerous permissions (Camera, Location, Contacts) are flagged in red here.
  • Cross-team handoffs — when QA hands a build to product or marketing, the analyzer shows everyone the same metadata without asking the QA engineer to dig.
  • Investigating third-party APKs — security researchers, threat hunters, or just curious devs can see what a downloaded APK is asking for before installing.
  • CI debugging — confirming that the right versionCode ended up in the artifact your CI uploaded.

APK vs AAB — quick clarification

If your "APK" turns out to be a .aab (Android App Bundle), it's a slightly different beast — the format Google requires for new Play Store submissions since 2021. AAB files split resources by language, density, and architecture so the Play Store can deliver a smaller install to each user. Drop one in our AAB inspector instead.

Got an APK? Ship it.

The same parser that powers this analyzer also extracts metadata when you upload an APK to share — including auto-detecting the icon, version, and bundle ID for the install page.

Upload an APK to share → Analyze an IPA instead