App Permissions Have Changed: Here’s Our Developer’s Guide!
User privacy is a big deal these days. Google knows this. It wants Android apps to access only permissions that are absolutely necessary. So it keeps tweaking the rules. In this overview, we trace the history of the changes, and show how the process works today…
Why does my flashlight app need to access my microphone? This was a question many users didn’t bother to ask when they were discovering the joy of apps for the first time. They just clicked to grant permission, so they could see in the garden at night.
But after a while, they did start to wonder. Especially when stories of harvested data, malware, and privacy breaches appeared in the media. Wary of the bad press, Google leaped into action. And over the last few years, we’ve seen the user experience of permissions, and the developer process for getting them, change a lot.
It’s a complex area. So let’s start at the beginning.
App Permissions: The Basics
Put simply, permissions are special rights that any app needs to work properly. These permissions can relate to both phone software and hardware.
Every app needs to access some aspects of the device just to function properly. For this reason, system permissions are divided into two groups, sometimes called “normal” and “sensitive.”
Normal permissions are allowed by default because they don’t pose a risk to the user’s privacy. For example, Android allows apps to access the web browser without demanding active consent. Instead, when a person downloads an app, this permission is granted implicitly. Normal permissions include access to:
- Network status
- Background processes
- NFC (near-field communication)
- Battery optimization
- Background image
Sensitive permissions are different. They relate to areas that could lead to security or privacy breaches. They include access to:
- Body Sensors
Google’s Changing Approach
Obviously, Google has always taken steps to ensure that developers get active consent if they want their apps to access these permissions.
At first, this took the form of a pop-up that listed the permissions required and asked the user to accept. Developers just needed to declare each permission in the Manifest. From the user’s POV, a pop-up would appear before installation. He or she was given no real flexibility: it was either accept the permissions or you can’t download the app’.
But this one-off all-or-nothing approach could not last.
Why? Because some unscrupulous developers began to take advantage. Users would accept all permissions just to be able to use the app. Meanwhile, the developer would harvest user data to sell to advertising companies.
All that ended with the release of Android 6.0 in October 2015.
Google changed the rules so that users could decide which permissions to accept on a case-by-case basis — after the app was installed. Developers would have to declare all the permissions in the Manifest, but also request them at runtime. The user could then choose to grant or deny each permission request – something that wasn’t previously possible.
And users were also given the option to go back and readjust app permissions later in settings.
As time wore on, Google continued to tighten up the permission rules.
The Privacy Clampdown
Big changes came in 2018 when Google launched ‘Project Strobe’. This was a root-and-branch review of developer access to Android device data.
In general, the changes gave users more control over their permissions – and made permissions apply only when an app is active.
It meant Android users could go to the Permission Manager in Settings/Privacy to see a listing of all the available permissions.
The menu divided them into three categories:
- Allowed All The Time
- Allowed Only While In Use
Users could find the app they want to modify and change it to one of the following:
- Allow All The Time
- Allow Only While Using The App
- Ask Every Time
And now, with Android 11, users are getting even more control. There is a new option based on unique permissions or one-time use.
What this means is that when an app requests permission related to location, microphone, or camera, the permissions dialog will show an option called “Only this time”. If the user selects it, the app is granted temporary one-time permission.
What’s more, Android 11 resets the permissions of unused apps.
From a developer point of view, the important points are as follows:
- If your app is visible, it can access the data.
- If the user sends your app to the background, you can still access the data for a short time.
- If the user revokes the one-time permission, your app cannot access the data.
How SMS & Call Log Permissions Have Changed
As part of the Android 9 changes in early 2019, Google revised its policy regarding calls and texts.
Google’s motivation was, again, security. It was wary of unscrupulous app developers using these permissions to harvest call records and SMS data.
So it mandated that only the app selected as the phone’s default app for making calls or sending texts would be able to access call logs and SMS data via the SMS and Call Log permissions. However, Google does list some exceptions to this case but states that the use of SMS or Call Log is part of the app’s core functionality, and without it, the app is effectively broken.
It said: “We are limiting apps’ ability to receive Call Log and SMS permissions on Android devices, and are no longer making contact interaction data available via the Android Contacts API.”
Google did offer developers an alternative, however. It stated that other APIs, such as the SMS Retriever API, the SMS Intent API, the Share Intent API, or the Dial Intent API can be used to access the relevant permissions instead.
There’s some useful info on these alternatives here.
Adjustments to the Call Screening Service
With Android 11, Google introduced more adjustments to the Call Screening Service permissions. It did this in an attempt to crack down on robocalls. Interestingly, the Call Screening Service is a permission that doesn’t need approval from Google to be implemented into an app. However, if the user declines this permission (or simply doesn’t request it on Android 11 devices) then some apps lose their core functionality. This affects features such as call blocking.
However, for those of you that still want to apply for call-related permissions, here is an overview of how that process works.
Firstly, please remember that Google wants to make sure it only grants permissions to apps that need SMS or Call Log to enable their core functionality to work.
For this reason, it demands that any developer that gained access prior to Android 9 clean all their channels (beta and release) of these sensitive permissions and then re-apply for them.
If Google notices that the permission is no longer used for the use case as described when the application was approved, Google exercises the right to remove the Call and/or SMS Log permission.
The process for re-gaining permissions is as follows:
- Open the Google Play console
- Go to the ‘app content’ menu
- Go to permissions declaration
- Go to SMS and Call Log menu
- Select from the list of core functionalities of the app (there are around 20)
- Write the nature of your request in the text box (max 500 characters).
- Create a YouTube video and enter the URL (this can be a narrated screen recording, for example, showing how and why the app requires the permission)
It’s not clear whether Google’s decision-making process is manual or algorithmic, but the time taken to make a decision on your application can vary.
If your application is rejected you will receive an email explaining the reasoning behind the rejection.
How Location Permissions Have Changed
Recently Google has also tightened up access to location permissions. Clearly, this is also done with user privacy in mind. The process for applying for Location Permission is similar to SMS & Call Log. The main difference is that the app is required to have at least one feature that needs Background Location to work, but this doesn’t necessarily need to be the primary feature of the app, unlike SMS & Call Log.
When applying you have a 500 character field to explain the main purpose of the app, and then a second 500 character field to describe one of the location-based features that needs access to the location in the background. As with SMS & Call Log, you need to make a YouTube video showing a screen recording that demonstrates the feature.
When applying for any sensitive permissions it’s of course very important that when users go through the opt-in process while installing the app, all permissions, their purpose, and how the data is used, is presented clearly to users. Transparency is the key.
As this post implies, permissions access can be a tricky area for developers. Google frequently changes and updates its policies in order to provide greater security and protection for users so it’s important to stay up-to-date with policy changes and allow yourself time to make adjustments to your app prior to new policies coming into play.