APK Manifest Viewer Guide: Read an App Manifest Without Installing

Every Android app carries a manifest, a structured file that declares what the app is and what it is allowed to do. Before an app runs, the system reads this manifest to learn its package name, its version, the screens it contains, and the permissions it requests. For anyone reviewing an app file, a store listing, or a sample of code, the manifest is therefore the fastest honest summary available: it states the app's identity and its requested powers in one place, without requiring installation or execution.

The APK Manifest Viewer tool reads package, version, and permissions from pasted manifest text. You paste the manifest XML text, and it lists the key declarations it finds, including the package name, version details, permissions, and activities. It reads text you paste; it does not open an APK file itself, install anything, run the app, or verify that the manifest matches the app's actual behaviour. An app can declare one thing and, in principle, behave differently, and a manifest can be edited, so the viewer is a reading aid for the declared text, not a security verdict on the app. Treat its output as the app's stated claims, to be checked against other evidence when trust matters.

The package name is the app's unique identifier, usually written in reverse-domain form, such as com.example.myapp. It is how the system distinguishes one app from another, and two apps cannot share it. Version information comes in two parts that are often confused: the version name, a human-readable label such as 2.4.1, and the version code, a whole number that increases with each release and that the system uses to decide whether an update is newer. Permissions are the most consequential section. Each permission names a capability, such as reading contacts, accessing location, or using the camera, and the list as a whole describes the app's requested reach. Activities are the screens and entry points of the app, including the main screen that appears in the launcher.

A worked example you can follow

Take a sample manifest for a fictional notes app. Its package is com.example.notes, its version name is 1.3.0, and its version code is 14. It declares 3 permissions: access to the internet, access to network state, and vibration. It declares 2 activities: a main notes list and a note editor. Counting the claims: 1 package, 2 version values, 3 permissions, and 2 activities. The permission count is the first thing to judge: 3 permissions for a notes app that syncs online is plausible, because internet access and network state support syncing, and vibration supports a reminder feature. If the same notes app declared 12 permissions, including contacts, location, camera, microphone, and SMS, the gap between what the app does and what it requests would be 9 extra permissions, since 12 minus 3 equals 9, and each of those 9 would need a justification in the app's description or behaviour.

Now compare two sample versions of the same app. Version 1.3.0 has version code 14, and version 1.4.0 has version code 17. The version name moved from 1.3.0 to 1.4.0, suggesting a minor feature release, and the version code moved from 14 to 17, an increase of 3, since 17 minus 14 equals 3, which is consistent with three builds between the releases. If a supposed update showed version code 14 again, or a lower number, the system would not treat it as an update at all, which is a useful check when a file claims to be newer than the installed app. A second check is the package: if the installed app is com.example.notes but the sample manifest says com.example.notes2, the two are different apps to the system, however similar their names look, and installing one will not update the other.

Reading activities adds a final layer. The main activity, marked as the launcher entry, is the screen users see first. Other activities may be screens reached from inside the app, or screens other apps can open. An app whose manifest lists an activity for a feature its description never mentions deserves a second look, just as a permission list longer than the feature set does. Neither observation proves bad intent on its own, but both are cheap signals that focus further checking where it matters.

Common mistakes to avoid

The first mistake is treating a manifest reading as a safety clearance; it shows declared permissions, not actual behaviour, and a malicious app can declare little while doing much through other means. The second mistake is judging permissions without context: a maps app requesting location is expected, while a torch app requesting contacts is not, so always judge the list against the app's purpose. The third mistake is confusing version name with version code; the name is for humans, the code is what the system compares. The fourth mistake is pasting a manifest that contains secrets, such as API keys, into any tool without considering who can see pasted text; never paste credentials or private keys into a viewer, and strip secrets from a sample before sharing it. The same caution applies to any log or configuration text you paste anywhere.

The Word Counter tool can confirm the size of a pasted manifest, and the JSON Studio tool helps when a related configuration is in JSON rather than XML. For background on keeping accounts and credentials safe, see HTTP Security Headers Guide.

Checking the result before you rely on it

Use a manifest reading as the first step of a review, not the last. Confirm the package matches the expected app, confirm the version code is higher than the installed version when an update is claimed, read every permission against the app's stated purpose, and note any permission or activity that lacks an explanation. When a manifest raises a question, seek the answer in the app's description, its privacy policy, or its observed behaviour, rather than assuming the worst or the best. A manifest cannot tell you whether to trust an app, but it can tell you exactly what questions to ask before you decide.