17.1 App Permissions

Understanding App Permissions

Android permissions control what parts of the device and user data your app can access. This chapter focuses on how permission groups work conceptually, what kinds of permissions exist, and how your choices affect user trust and app behavior. Technical details about requesting permissions at runtime are covered in the next chapter.

Why Permissions Exist

Android runs apps in isolated sandboxes. By default, your app cannot read another app’s data, access the camera, or see the user’s contacts. Permissions are the controlled “doors” between your app and sensitive features.

When your app wants to use something that impacts user privacy, security, or cost, it must declare a permission. Android uses these declarations to warn users and to decide whether your app is allowed to perform the requested action.

The core idea is very simple. Access to sensitive features must be explicit, transparent, and limited.

Requesting fewer permissions increases user trust and often improves install and retention rates.

Types of Permissions

Android divides permissions into several categories, each with its own behavior from a user perspective. You will interact mainly with normal and dangerous permissions.

Normal Permissions

Normal permissions cover features that have minimal risk for user privacy and security. For these, Android grants access automatically at install time without asking the user explicitly.

Examples include access to internet or setting alarms. A typical normal permission is:

android.permission.INTERNET

Users do not see a runtime dialog about these. Your responsibility here is to avoid abusing these capabilities and to declare only what you actually use.

Dangerous Permissions

Dangerous permissions control access to very sensitive data or hardware. These always involve user consent at some point, which is handled through the runtime permission system described later.

Examples of dangerous permissions include access to:

Camera
Microphone
Location (fine or coarse)
Contacts
SMS
Phone state and call logs
External storage on older Android versions

These permissions are grouped into permission groups. If the user grants one dangerous permission from a group, other permissions in the same group can sometimes be granted silently to the same app, depending on Android version. Conceptually you should think about groups such as contacts, location, calendar, and phone.

Signature and Special Permissions

There are more restricted permission types that are usually not used in normal apps.

Signature permissions can only be granted if the app is signed with the same certificate as the app that defines the permission. This is used for tightly controlled communication between apps from the same developer or vendor.

Special or privileged permissions cover extremely sensitive capabilities like drawing over other apps or changing system settings. These usually require the user to go to a special system screen and give consent manually. Many of them are reserved for system apps or device manufacturers.

Declaring Permissions in AndroidManifest

Every permission that your app needs must be declared in AndroidManifest.xml using the <uses-permission> tag. This is a static declaration that tells the system and the user what capabilities your app might use at any time.

For example, if your app needs to access the internet and the camera, you add:

<manifest ...>
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.CAMERA" />
    <application ...>
        ...
    </application>
</manifest>

Declaring a permission does not guarantee that your app can use the feature. For dangerous permissions, it only means the app is allowed to ask the user at runtime. The actual access depends on whether the user has granted or denied the permission.

For normal permissions, the manifest declaration is usually enough. The system grants them automatically when the app is installed or first run. For dangerous permissions, you must combine manifest declaration with runtime requests, which you will learn in the next chapter.

Permission Flow from User’s Perspective

It is helpful to understand how permissions look and feel to users, because this heavily influences app design.

When the user installs your app from Google Play, they see a list of some capabilities, depending on Android version. Many users skim or ignore this, so you should not rely on it as your only communication channel.

Inside the app, the user may see:

A permission dialog that appears when a feature is first used or at app startup.
An explanation screen that you show before the dialog to clarify why the permission is needed.
A settings screen where they can review and change permissions later.

Once the user chooses to deny or allow, your app must respect their choice and behave appropriately. For example, if the user denies camera access, a “scan” feature that depends on the camera might remain disabled, and your app should explain why.

Designing Features Around Permissions

A good Android app is careful about when and why it asks for permissions. You should always connect permission requests to user intent.

If a user taps a “Take photo” button, a camera permission request makes sense. If an app asks for camera access as soon as it starts, without clear reason, users become suspicious and may uninstall it.

In practice, you should:

Show permission dialogs only when needed for a specific action.
Offer alternative paths when possible, for example manual input instead of automatic detection.
Clearly explain what benefit the user gets from granting the permission.

Permissions also affect app architecture. Code that depends on a permission must be robust to both success and failure. You should design flows where:

The app works in a limited mode without certain permissions.
Features that require permissions check if access is available before proceeding.
Permission errors are handled gracefully, for example by showing a friendly message and returning to a safe screen.

User Control and Settings

Users can change permissions at any time in the system settings. Your app must be ready for permissions to be revoked while it is running or between sessions.

Typical scenarios include the user going to Settings, opening the App info screen for your app, and disabling location access. On the next launch, your app may discover that it no longer has permission to read the location and must adjust.

This means you cannot assume that a permission granted once stays granted forever. On modern Android versions, the system may also automatically remove permissions from apps that have not been used for a long time. Your app should be prepared to see a permission become unavailable again.

Minimizing and Justifying Permissions

Choosing the right set of permissions is part of designing a secure and respectful app.

You can ask yourself three key questions for each permission you consider:

Is this permission essential for the core function of the app?
Can the same feature be implemented with a less sensitive permission or different approach?
Can this be optional, so that users who deny the permission still get value from the app?

For example, a note taking app likely does not need access to contacts or phone state. If you decide to add a feature like sharing notes via SMS, you must weigh whether it justifies requesting SMS related permissions, or if you can use a standard share action without extra permissions.

The fewer permissions you request, the simpler your app appears to users, and the easier it is to pass reviews and gain trust.

Permissions Across Android Versions

Android’s permission model has changed over time. The main shift was from granting all dangerous permissions at install time to asking for them at runtime when needed. As a developer, you will often have to consider the minimum Android version you support.

Different versions also introduced separate controls for background location, one time permissions, and automatic permission resets for unused apps. While implementation details are handled when you write code, you should conceptually keep in mind that:

Some permissions behave differently in the background compared to the foreground.
Users can grant “only while using the app” type access for sensitive data such as location and microphone.
You should avoid relying on background permissions unless they are critical to your app’s purpose.

Permission Misuse and User Trust

When apps misuse permissions, users lose trust and the entire ecosystem suffers. Typical misuses include requesting broad storage access when only a few files are needed, or asking for contact access just to perform analytics or marketing.

From a practical course perspective, you should treat permissions as a contract with the user. They give your app special access, and in return you use that access only for the purposes you clearly communicated.

This mindset will also help when you later implement runtime permissions and security best practices. You will be better prepared to design flows where users understand what is happening and feel comfortable with their choices.

In summary, app permissions are the formal way your app asks for access to sensitive features and data. You declare what you need in AndroidManifest.xml, you think carefully about which permissions are truly necessary, and you design features that respect user control and privacy. The next chapter will build on this foundation and show you how to request and manage these permissions at runtime in actual code.