APK Analyzer

Drop an Android package — an .apk file — and read what it declares about itself before it gets anywhere near a phone: its package name and version, the SDK levels it targets, every permission it asks for, whether it allows debugging and backups, which of its components other apps can reach, and the certificates it is signed with. The file never leaves your device: it is opened and parsed in this page, not uploaded, because an APK you are suspicious of is exactly the file you should not be handing to a stranger’s server.

Or drop the file anywhere in this box. Everything below is read from the package itself, on this device — the manifest, the compiled resources and the signature blocks.

What an APK declares before it runs a line of code

An APK is a ZIP archive with opinions. Before Android runs any of its code, the system reads the binary AndroidManifest.xml inside it, and that one file is a surprisingly complete statement of intent. It names the package — the identity updates are matched against — and its version. It states the oldest Android release the app claims to support and the release whose behaviour rules it was built against, which is why the target SDK matters: a low target quietly keeps older, looser permission behaviour alive. It lists every permission the app will ever be able to use, because a permission that is not declared cannot be granted later. It says whether the build is debuggable — a flag that should never survive into a release — and whether its data may be swept into device backups. And it inventories the app’s components: the activities, services, receivers and providers, each with an exported state that decides whether other apps on the device can call into it. An exported component with no permission check is the classic Android attack surface, and you can see it here, in the manifest, without installing anything.

The other half of the story is the signature. Android will only install an update over an existing app when both are signed with the same key, so the signer certificate’s fingerprint is the app’s continuity of identity: the same package name signed by a different key is a different app wearing a familiar label. This page reads both generations of signature — the Jar-style certificates in META-INF and the APK Signature Scheme v2/v3 block — and shows each signer’s subject, issuer, validity window and SHA-256 fingerprint, which the certificate and key matcher can compare against a key or CSR you hold. The companion guide, what is inside an APK before you install it, walks the whole inspection as a checklist. Two honest limits: this page reads declarations, not behaviour — it does not decompile code, execute the app or judge whether it is malware — and where the manifest itself is ambiguous (an omitted exported flag on a component with an intent-filter, a label the compiled resources will not resolve), it says so rather than filling the gap with a guess. For what the app does on the network once it is running, the PCAP analyser reads the capture.

Frequently asked questions

Where does my APK file go?

Nowhere. The file is opened and parsed in this page, on your device, and nothing is uploaded, transmitted or stored — analysing a file makes no network request. That matters here more than for most tools: the APKs people most want inspected are the ones they already distrust — a file from a forum, a direct download, an app store listing that looks wrong — and sending a suspicious binary to a remote scanning service is its own exposure. It also works offline once the page has loaded.

What should I check before installing an APK?

Four things, all visible above. The package name: is it the publisher’s real namespace, or a lookalike with one character changed? The permissions: does a torch app really need your contacts, call log and precise location — and are any of them signature- or special-level requests dressed up as routine? The exported components: every activity, service, receiver or provider other apps can reach is surface you are accepting. And the signer: an update must carry the same signing certificate as the installed app, so compare the SHA-256 fingerprint against the copy you trust before sideloading a “newer version” from anywhere.

Can this tell me whether an app is malware?

No, and any tool that promises that from a manifest alone is overselling. This page reads what the package declares — identity, permissions, components, flags and signatures — which is enough to catch the careless and the impersonators: a clone with the wrong signer, a flashlight demanding SMS access, a release build left debuggable. Judging what the code actually does needs decompilation, dynamic analysis or a reputable scanner’s verdict on the binary itself. Treat a clean result here as “nothing declared looks wrong”, never as a safety certificate.

Why do some permissions say “not in the reference table”?

Because honesty beats a plausible guess. The protection levels shown — normal, dangerous, signature, special — come from a curated table of the well-known android.* permissions and the level the framework assigns each. Vendors add their own permissions, manufacturers add more, and new Android releases introduce new names; none of those are in the table, so the page says so explicitly. An unknown level does not mean the permission is harmless or dangerous — it means this reference does not cover it, and the permission’s own name and namespace are the place to start checking.

What does “exported: not specified” mean?

It means the manifest genuinely does not say. When a component declares an intent-filter but omits android:exported, the effective answer has depended on the app’s target SDK and the Android version — older rules defaulted such components to exported, newer ones refuse to install the app until the developer decides. A reader that printed a confident true or false would be inventing a fact the file does not contain, so this page reports the omission itself. For your own builds it is the one row worth fixing explicitly.