Gera Tools

Android APK Inspector

Inspect an APK's manifest, permissions and version code in your browser

Inspect an Android APK in your browser: read the package name, version name and code, min and target SDK, and every declared permission. Decodes AndroidManifest.xml from the binary AXML format locally — the APK is never uploaded. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

Why does an APK manifest need decoding?

Inside an APK the AndroidManifest.xml is not plain text. It is compiled into Android's binary XML (AXML) format, which packs tags, attributes and a string pool into a chunk-based binary layout. The tool decodes that format to recover readable values.

The Android APK Inspector opens an .apk file in the browser and surfaces the key facts from its manifest: the package name, version, target SDK levels and the permissions the app requests. This is the quickest way to audit an APK before sideloading it, to confirm a build’s version code, or to see exactly what an app is allowed to access — without Android Studio, aapt or apktool.

How it works

An APK is simply a ZIP archive, so the inspector starts by reading the ZIP central directory. It scans backwards from the end of the file for the End Of Central Directory record, then walks each central-directory entry until it finds AndroidManifest.xml. From that entry it locates the compressed data and, if the entry uses DEFLATE, inflates it with the browser’s DecompressionStream("deflate-raw").

The decompressed manifest is in Android’s binary XML (AXML) format. AXML is a sequence of typed chunks: a header, a string pool, and a stream of start-element chunks. The tool first reads the string pool (supporting both UTF-8 and UTF-16 encodings), then walks the start-element chunks. For each element it reads the attribute table, resolving each attribute’s value either from the string pool or from its typed data field (integers, booleans and string references).

From those elements it extracts the package, versionName and versionCode off the <manifest> tag, the minSdkVersion and targetSdkVersion off <uses-sdk>, every <uses-permission> name, and a count of <activity> declarations.

Tips and notes

  • Permissions like INTERNET, ACCESS_FINE_LOCATION and READ_CONTACTS reveal what an app can reach — review them before installing.
  • The version code is the integer Android uses to order updates; the version name is the human label such as 2.1.0.
  • Split APKs and bundles may keep some metadata in separate files; this tool reads the base AndroidManifest.xml.

Everything runs locally in your browser — the APK is never uploaded.

Understanding the permission list

The permissions section is the most security-relevant output of the inspector. Android permissions fall into several protection levels, and knowing which level a permission belongs to tells you how risky it is to grant:

Normal permissions (granted automatically, low risk):

  • INTERNET — allows network access; nearly every app requests this
  • ACCESS_NETWORK_STATE — read network connectivity info
  • VIBRATE — control the vibration motor

Dangerous permissions (require explicit user grant at runtime):

  • ACCESS_FINE_LOCATION — GPS-level location tracking
  • ACCESS_COARSE_LOCATION — approximate location from cell towers / Wi-Fi
  • READ_CONTACTS — read the user’s contact list
  • READ_CALL_LOG — access call history
  • CAMERA — use the camera hardware
  • RECORD_AUDIO — access the microphone
  • READ_EXTERNAL_STORAGE / WRITE_EXTERNAL_STORAGE — access files

Signature permissions — only granted if the requesting app has the same signing certificate as the app that defined the permission; used for inter-app communication within the same publisher.

When reviewing an unfamiliar APK, focus on the dangerous-permission group. An app that requests READ_CONTACTS and RECORD_AUDIO but whose function does not require either is a red flag.

Version code vs. version name

The manifest contains two version identifiers with different purposes:

  • versionCode — an integer that increases with each release. Android uses this to determine if an update is newer than the installed version. A device will not install a build with a lower or equal versionCode over a higher one. Developers set this manually or via their build toolchain.
  • versionName — a human-readable string like "2.4.1" or "Spring 2025". This is what users see in the Play Store listing and About screen. It has no semantic meaning to the OS — only versionCode drives update logic.

This matters when sideloading builds: you might receive an APK labeled v3.0-beta (versionName) but with a versionCode of 28, which could be lower than the production version 27 that is already installed.

Minimum SDK and target SDK explained

  • minSdkVersion: the oldest Android version the app will install on. An app with minSdkVersion 24 requires Android 7.0 (Nougat) or newer and will refuse to install on older devices.
  • targetSdkVersion: the Android version the app was designed and tested for. Android uses this to decide which compatibility behaviors to apply — an app targeting SDK 34 (Android 14) gets newer privacy behaviors than one targeting SDK 28, even if both run on Android 14.

A large gap between minSdk and targetSdk is common. What to watch for is a low targetSdk on a current app, which sometimes indicates the developer has not updated the app to comply with newer Android security requirements.