How to analyze an APK without installing it

What you are looking at

An APK is a ZIP. Inside: binary AndroidManifest.xml, one or more classes*.dex files, resources.arsc, res/, assets/, optional lib/<abi>/*.so, and META-INF signing material. Installing that file on a phone executes whatever those components declare. Reading the ZIP does not.

The browser can list the ZIP, hash the bytes, and guess a few ASCII strings from the binary manifest. It cannot give you a trustworthy decoded manifest tree. Plan the handoff: browser first, aapt dump badging or apktool d when the guess is empty or you need android:exported.

Step 1 — Prove you have the file you think you have

Open the APK Analyzer. Confirm the filename, the SHA-256, ZIP entry count, DEX count, and whether AndroidManifest.xml is present. Copy the report.

Compare the hash to CI output. If QA downloaded a different byte stream than Gradle produced, stop. Play App Signing will also change the artifact users install — do not expect the upload APK and the Play-delivered APK to share a hash.

If DEX count is 0, you are not looking at a Dalvik/ART app (or the file is not an APK). If native libs are missing on a build that must ship arm64-v8a, check whether you opened a configuration split instead of the base APK.

Step 2 — Treat version heuristics as clues, not Play truth

The analyzer regex-scans printable strings for package, versionName, and versionCode. When they appear, match them against the Play listing and the last uploaded versionCode. Play requires a strictly higher integer. Reusing a code is still the most common afternoon we waste — see versionCode upload mistakes.

When the heuristic block is blank, do not invent numbers. Run aapt dump badging your.apk or decode with apktool. The Android version checker is for API-level names (what “API 34” means), not for reading a package.

Step 3 — Get a text permission list and read it like a reviewer

If you have source or apktool output, paste <uses-permission> lines into the Permissions Decoder. You want the dangerous and special rows: CAMERA, location, SMS, Call Log, notifications (API 33+), and MANAGE_EXTERNAL_STORAGE.

Restricted Play permissions (SMS, Call Log, All files access) fail policy even when the APK installs. “The decoder said dangerous” is not the same as “Play will allow this.” Trim leftovers from libraries. Users remember the dialog, not your merge graph — permissions users notice.

Step 4 — Validate text XML, not the binary blob

The Manifest Validator uses the browser DOMParser on text XML. Use it on source or decompiled manifests to catch a broken root, a missing package attribute in the file you are editing, and a missing MAIN/LAUNCHER pair. It will not decode the APK’s binary manifest and it will not certify android:exported for Android 12+.

After Android 12, an activity, service, or receiver with an intent-filter and no explicit android:exported fails install on new devices. That check still belongs in lint / the merged manifest, not in a ZIP listing.

Step 5 — Strings and signing (only if the first four are clean)

The APK String Extractor is for copy review and leftover debug text, not for localization QA of every density. The APK signer guide is a checklist (v2/v3, alignment, upload key vs app signing key), not a keystore. We do not sign APKs in the browser.

When to leave the browser

• You need the real package / versions / permissions: aapt dump badging.
• You need editable XML and smali: apktool.
• You need signature verification: apksigner verify --verbose.
• You have an .aab: bundletool, not a renamed APK drop.

Privacy

DroidXP local APK tools process the file in your tab. We do not operate an upload API for these pages. Your organization’s policy may still forbid opening a production build on a shared laptop. Follow that policy.