Inspect permissions before installing

The single question that matters when you hold an APK file or an app page in front of you is not “is this app safe?” It is: does this app need the access it is asking for, given what it claims to do? A flashlight app that wants your contacts is a bigger warning sign than a file with a slightly odd name. Reviewing declared capabilities catches intent problems, while signature and hash checks catch tampering problems. You need both, but the material below covers the capability layer. Before you tap the button, inspect permissions before installing: open the list, compare every entry against the app’s stated job, and walk away if anything does not belong.

Why declared capabilities are the first filter

Android permissions are not a rating system. They are a request list. When you set up an app, the system shows you what it wants to access, and in most cases you can deny individual items later. The danger is not that an app asks for access; the danger is that an app asks for access that has no relationship to what the app claims to do.

A calculator does not need your contacts. A flashlight app does not need your location. A note-taking app does not need to send SMS. When you see that mismatch, you have already learned more than any virus scanner can tell you. The official Android documentation states that permissions are the app’s declaration of what data or actions it can access, and you should review them before proceeding (Android Developers, “Permissions overview,” 2024).

The core question is simple: does the requested access make sense for the app’s stated purpose?

How Android controls access

Android permissions are declared in the app’s manifest. When you install from the Play Store, the system shows a summary of what the app requests. When you sideload an APK, Android shows a similar list during the setup flow, before the install button becomes active. You can also review permissions after setup in Settings → Apps → [app] → Permissions, and on many devices you can revoke individual items without removing the app (Android 6.0 and later, per Android Developers documentation).

Two categories matter for the pre-install check:

1. Install-time permissions, granted when you tap Install. These include things like “Read phone status” or “Access all files.” You cannot selectively deny them at install time on most Android versions; you can only deny them after setup if the app targets a modern Android version (Android 6.0 / API 23 or higher).
2. Runtime permissions, requested while the app is running (e.g., camera, microphone, location). Android shows a dialog and you can allow or deny each one. The key pre-install check is not the runtime prompt, but the full list of permissions in the app’s store listing or manifest.

The question you are answering before tapping install is simple: does every requested permission have a plausible connection to the app’s core purpose? If the answer is no, do not install.

What a capability review is and what it is not

Reading the list of permissions an app requests and comparing it to what the app says it does is a capability review. It is not a malware scan. A clean list does not prove an app is safe; a suspicious list does not prove an app is malware. The permission list is one signal in a set of checks that also includes the app’s source, its signature, and its update history. The Android permission system is the operating system’s gatekeeper: it controls what an app can access on the device, and the Play Store or the installer shows you that list before you tap Install.

On modern Android versions, permissions are usually granted at runtime, meaning the app asks for access while you are using it. But the app’s manifest still declares the full set of permissions it can request, and this declaration is visible before installation. Reading the list before you proceed is the single most useful habit you can build. The list is not a guarantee of safety, but it is the most concrete signal you have that an app’s behaviour will match its stated purpose.

What a permission actually grants

A permission is not a review score. It is a capability. When an app asks for READ_CONTACTS, it is asking for the ability to read the contact list on your device. When it asks for ACCESS_FINE_LOCATION, it is asking for precise GPS position. The Android permission system is the boundary between what the app can do and what you allow it to do. Android Developers documentation (2024) describes permissions as “the access rights an app needs to use specific device features or data.” The key phrase is “needs”: every permission request should be justified by the app’s core purpose.

On modern Android versions, many permissions are granted at runtime, meaning the app asks you the first time it needs the data. But the manifest still lists all permissions the app can request, and you can see that list before you install. On Android 6.0 and later, dangerous permissions are requested when the app first uses them, not at install time. On older Android versions, all permissions are granted at install time.

The three protection levels

Android permissions are divided into three levels:

• Normal permissions: automatically granted; low risk; e.g., INTERNET, ACCESS_NETWORK_STATE. These do not require user approval.
• Dangerous permissions: require explicit user consent at runtime on Android 6.0 (API 23) and later. They cover contacts, camera, location, microphone, phone, sensors, storage, and similar sensitive data.
• Signature permissions: granted only to apps signed with the same certificate; rarely visible to normal users.

The Android permission model is described in Android Developers’ documentation “Permissions overview” (Google, updated 2024). The key point for installation is that the permission list is declared in the app manifest before installation. On modern Android versions you are asked to grant or deny many permissions at runtime, but the full list is visible in the app’s Play Store listing or APK metadata before you install.

How to inspect an app’s requested permissions

The decision rule in one sentence

Before you install, list the permissions the app requests, and reject the install if any requested permission has no plausible relationship to the app’s stated purpose. Then verify that the app’s signature matches the developer’s own release channel.

Where permissions actually live

Permissions are declared in the app’s manifest, which is inside the APK or generated from the app bundle. You see a summary at install time, but the full list is longer than what the Play Store shows. Android groups permissions into normal (granted automatically) and dangerous (shown to you), and since Android 6.0 (API 23), dangerous permissions are requested at runtime, not at install. That means the install-time list is only part of the story: an app can ask for more permissions later, when it needs them. The Android Developers documentation on app permissions (2024) states that runtime permission requests should be granted only when the app is in use, and that you can revoke them at any time in Settings.

What “inspect permissions” actually means

When you inspect permissions, you are comparing two things: what the app says it does, and what it asks to access. A file manager asking for location is not automatically malicious, but it is a sign that the app may collect data beyond its core purpose. A calculator asking for contacts is a stronger red flag. The decision rule is not “permissions are bad”; it is “permissions must match the app’s stated purpose.”

Before you install, open the app’s page in the store or the developer’s site and read the permission list. On Google Play, tap “About this app” then “App permissions.” On a sideloaded APK, you can inspect the manifest before installing using a tool like aapt from Android SDK or an online APK analyzer, but the practical check is the permission screen the system shows at install time.

The permission checklist

Use this order when you review any app, whether from the Play Store, a device-maker store, a developer’s site, or a sideloaded APK:

1. List the permissions the app requests.
2. Write down the app’s core purpose in one sentence.
3. Mark each permission as “needed for the core purpose”, “plausible for a feature”, or “unrelated”.
4. If any permission is unrelated, do not install.
5. If the app is a minor update of one you already use, compare the new permission list against the old one. A sudden jump in permissions is a stronger warning than a static list.

The permission list is available before installation: on Google Play, open the app page and scroll to “About this app” → “App permissions”; on a developer’s site, the APK’s manifest can be inspected with aapt from Android SDK Build Tools or with an online manifest viewer. On a device, go to Settings → Apps → the app → Permissions after install, but at that point you have already granted them.

How the permission model has changed across Android versions

Android 6.0 (API 23) introduced runtime permissions, so dangerous permissions are asked at the moment of use, not at install. Android 11 (API 30) added one-time permissions. Android 13 (API 33) introduced granular media permissions. The practical consequence: an app that targets an old SDK may still request all permissions at install time, while a modern app asks contextually. If an app targets an old SDK, the old-style install-time permission list is a warning that the app is not maintained (Android Developers, 2023).

Android permissions are grouped into normal, dangerous, and signature levels. Dangerous permissions are the ones that matter for privacy: camera, microphone, location, contacts, storage, SMS, and call logs. The Play Store listing shows these as “App permissions” under “About this app”; the Play Console “App content” page shows the same data. The Android Developers documentation “Permissions overview” (updated 2023) states that dangerous permissions require runtime approval on Android 6.0 (API 23) and later; the user can grant or deny each one at launch, and later revoke them in Settings. For apps installed from outside the Play Store, the same runtime permission model applies, but the initial “install from unknown source” prompt is a separate gate. The Play Store’s “App permissions” section is a summary of the manifest; it is not a live audit. For a live list, use the OS’s built-in permission manager: Settings > Apps > [app] > Permissions (exact path varies by device maker and Android version).

The Android permission model is not a single list. Android 6.0 (API 23) introduced runtime permissions, where the user grants dangerous permissions while the app runs, not at install time (Android Developers, Android 6.0 Changes, 2015). Android 10 (API 29) added scoped storage, Android 11 (API 30) added one-time permissions, and Android 13 (API 33) introduced a granular media permission split. The practical result: on modern Android, a permission listed on the Play Store page is only the maximum set the app can request; the app must ask for sensitive permissions at runtime, and you can deny them individually. The decision rule for a sideloaded APK is the same as for a Play Store app: does the permission set match the app’s core purpose? A calculator that asks for location and contacts is a red flag regardless of where the APK came from.

The Play Store’s data safety section and the Android permission dialog both show what the app wants, but the dialog appears after install, during first use. The install-time decision is therefore made on the manifest’s permission list, which is visible in the Play Store listing and in the APK’s metadata before you install. On Android, the permission list is shown in the “About this app” or “App permissions” section of the Play Store listing. For sideloaded APKs, the system shows a permission summary at install time, but it is easy to tap through without reading. The practical method is to compare the requested permissions with what the app must do.

Inspect permissions before you install: a step-by-step walkthrough

Open the app’s store page or, for a sideloaded file, begin the install flow until the system shows the permission summary. Read every entry aloud or write it down. Write one sentence that captures what the app claims to do. Cross out any entry that has no plausible link to that sentence. If even one entry remains uncrossed, stop. Do not complete the install. For apps you already use, open Settings > Apps > [app] > Permissions once a month and revoke anything you cannot tie to a feature you actively use. A matching hash proves file identity and a matching signing certificate supports publisher continuity; neither proves an app is harmless. Use the capability review first, then layer on signature and source checks.