What is inside an APK before you install it
An APK is a zip file with a declaration attached. Before Android runs a single line of its code, the package already states who it claims to be, which Android versions it supports, what it wants permission to do, which of its parts other apps may invoke, and who signed it. None of that requires installing anything. Reading it first turns a leap of faith into a ten-minute inspection — and the inspection is often enough to decide.
Why a sideloaded APK deserves a look first
Apps from an official store arrive with a listing, reviews and a publisher page. A sideloaded APK — from a vendor site, a mirror, a forum post, a chat message or an old backup — arrives with none of that context, and the install prompt does not replace it. Android's installer shows the name and icon; permissions appear late, grouped and simplified, when you are least likely to stop and think. Once an app is installed and launched, it may already hold its permissions and have used the network. The cheap moment to ask questions is before that, while the file is still just a file.
None of this is an argument against sideloading itself. Vendors distribute legitimate apps directly, enterprises deploy internal tools this way, and older versions sometimes solve real problems. It is an argument for reading what you were handed. The APK analyser on this site parses the package in your browser — the file is never uploaded and never executed — and lays out the manifest, the permissions, the components and the signing certificate in one view. Whatever tool you use, keep that order: inspect first, install second, and treat any app that cannot survive inspection as an answer in itself.
The manifest is the app's own declaration
Every APK carries an AndroidManifest.xml, stored in binary XML, and it is the app's declaration about itself. It names the package — the unique identity Android uses, such as com.example.app — along with a numeric versionCode and a human-readable versionName. It declares the components the app contains, the permissions it requests, and the hardware and software features it expects. Because Android enforces much of this file, it is harder to fake casually than a store listing or a download page: an app cannot quietly use a permission it never declared, and it cannot pretend to be an update for a package whose name it does not share.
Two numbers in the manifest say a surprising amount about maintenance. The minSdkVersion is the oldest Android the app will run on; a very low floor means support for devices and security models from many years ago, which is sometimes necessary and sometimes simply inherited and forgotten. The targetSdkVersion is the Android behaviour level the app claims to follow. Google raises the target required for store updates every year, because a higher target opts the app into newer privacy and security rules. A sideloaded app targeting a level several years old is not automatically malicious — but it is telling you it has avoided, or never met, those newer rules, and you should ask why.
Permissions, read properly
Android sorts permissions into classes, and the class matters more than the name. Normal permissions are granted automatically at install — access to the network is the familiar example — because the system judges them low-risk. Dangerous permissions cover sensitive data and actions such as contacts, messages, precise location, the microphone and the camera; these need a runtime prompt the user can refuse. Signature permissions are granted only to apps signed with the same certificate, or to the system itself, so a third-party app declaring one gains nothing from it. When you read a permission list, sort it mentally into those buckets before judging any single line.
Context is the verdict, not the count. A flashlight asking to read SMS messages has no honest reason for the request; a messenger asking for the same permission can at least explain itself — reading a verification code, or offering to act as your default messaging app. A banking app may legitimately request many permissions, while a simple game requesting only a few could still include the one that does not fit. So do not score apps by permission count alone. Ask, for each dangerous permission, what feature in this app would break without it. The requests you cannot map to a feature are the finding, and they are exactly what an install-time summary hides.
Exported components and the attack surface they create
An app is built from components — activities (screens), services, broadcast receivers and content providers — and the manifest states which of them are exported, meaning reachable by other apps on the device. Exported components are not a mistake by default: a share target, a file opener and a deep link all work because a component is exported on purpose, guarded, in modern Android, by an explicit declaration. The risk is in exported components that were never meant to be a public door: a service any app can start, a receiver any app can trigger, or a provider that hands out the app's data to whoever asks, with no permission check in front of it.
Two manifest flags deserve a direct look in any production app. An application marked debuggable can be attached to and inspected by tooling on a connected machine; that is a development setting, and shipping it enabled is a red flag about how the release was built. Allowing backup means the app's private data can be included in device backups, which may be convenient and may also move data you assumed stayed inside the app into a much less controlled place. Neither flag proves an app is harmful. Both are cheap to check, hard to justify in a finished product, and exactly the kind of detail that never appears on a download page.
Signing certificates: Android's identity system
Every APK is signed, and the signing certificate is the closest thing Android has to an identity document. Android will only install an update over an existing app when both copies share the same package name and the same signer. That single rule does a lot of quiet work: it means a stranger cannot ship a trojanised update to an app you already trust, because they do not hold the original key, and it means the certificate fingerprint — usually shown as a SHA-256 digest — is the practical way to check continuity. If a vendor publishes an expected fingerprint, compare it. The certificate and key matcher on this site covers the same fingerprint logic for certificates and keys more generally.
Be clear about what a fingerprint proves and does not. It proves this file was signed by whoever holds one particular private key, and that it matches — or not — another file signed by the same key. It does not prove the key holder is honest, competent, or even the company named in the certificate's subject fields, which the signer fills in themselves. A repackaged app is typically signed with a different certificate from the original, so a mismatch is a strong stop signal; a match is only a continuity signal. Identity in Android is continuity of the key, nothing more — treat it accordingly.
A pre-install checklist
Put the pieces together in a fixed order and the inspection takes minutes. First, identity: does the package name match the app you expected, and are the version code and name plausible for the release you meant to download? Second, maintenance: how old are the minimum and target SDK levels, and does that fit an app that is still looked after? Third, permissions: list the dangerous ones and map each to a feature, and stop on any you cannot explain. Fourth, surface: which components are exported, and are debuggable and backup switched on? Fifth, signing: does the certificate fingerprint match the publisher's stated value, or at least the copy you already trust? Run the file through the APK analyser and work down that list on one screen.
Then decide in three buckets, not two. Install, when everything maps to a feature and the fingerprint checks out. Install cautiously — on a test device, in a work profile, or without the questionable permissions — when most of it fits but one item needs watching. Or walk away, when the package name is wrong, the fingerprint does not match, or a dangerous permission has no imaginable feature behind it. Walking away costs a download; the other direction can cost an account. Keep the habit in proportion: this is triage, like the first ten minutes with the packet capture analyser — a fast, honest read of what a file declares, done before you give it a place on the device you carry everywhere.
Frequently asked questions
Does a clean manifest read mean an APK is safe?
No. The manifest is a declaration, not a behaviour report. An app can declare a modest, entirely plausible set of permissions and components and still behave badly in code — phoning home, abusing the permissions it was legitimately granted, or downloading new behaviour after install. Reading the manifest is triage: it catches mismatched identities, unexplained permissions, exposed components and wrong signing certificates quickly and cheaply. It is not a malware verdict, and any tool that turns a manifest read into a green "safe" stamp is claiming more than the evidence supports.
Why does the same app show different permissions in different tools?
Usually for three legitimate reasons. First, gating: a permission can carry a maxSdkVersion, so it applies only up to a certain Android level and different tools report it differently depending on whether they show gated entries. Second, grouping: Android presents permissions in groups at prompt time, while the manifest lists individual permissions, so a grouped view looks shorter than the full list. Third, merging: libraries bundled into the app contribute their own manifest entries, which the build merges into the final file — so the installed manifest can contain permissions no single part of the app's own source ever declared. Differences are a prompt to look at which reason applies, not automatic evidence of tampering.
Can I check an APK without installing anything?
Yes — that is the point of a browser-local analyser. The APK is parsed as a file: its binary manifest is decoded, its resources are read for labels and strings, and its signing certificates are extracted and fingerprinted. The app's code is never executed, nothing is installed on any device, and with the analyser on this site the file is never uploaded either — the parsing happens in your browser tab. If a checking service asks you to upload an APK to a server, ask yourself whether the file — which may be an internal build — belongs on someone else's machine at all.