The New Features in Android Permission

The picture is provided by Unsplash

As a matter of fact, protecting the privacy of users in using Android apps is an extremely vital issue. Google has mentioned that the main goal is to give users more transparency and control to their own personal information, which is being used by Android applications. Therefore, Android permissions play a significant role in this area. This essay aims to discuss some new features and best practices in Android permissions.

Introduction and Overview

As you know, the purpose of a permission is protecting the privacy of an Android user. Android apps must request permission to access sensitive user data such as contacts and SMS, as well as some system features such as camera and internet. Depending on the feature, the system might grant the permission automatically, or might prompt the user to approve the request. By default, a central design point of the Android security architecture is that no application has permission to perform any operations that would adversely impact other Android apps, the Operating System, or the user. This could be included reading or writing the user’s private data such as contacts or emails, reading or writing another app’s files, performing network access, and keeping the device awake.

On all versions of Android, to declare that your app needs a permission, put a <uses-permission> element in your app manifest, as a child of the top-level <manifest> element.

The system’s behavior after you declare a permission depends on how sensitive the permission is. Some permissions are considered “normal” so the system immediately grants them upon installation. Other permissions are considered “dangerous” so the user must explicitly grant your app access.

On Android, Google has mentioned that the goal is to give users more transparency and control to their own personal information, which is being used by applications. To achieve the goal, Google has been working on Android permission to evolve and become it much more private. In Android 10, Google introduced over 50 privacy features, made it much more privacy-friendly release to use. For instance, some new features in Android for having much more privacy-friendly environment could be:

1. Privacy and location top-level settings menu.

2. Introducing more granular location and adding background location reminders.

3. Activity recognition for a dangerous runtime permission.

4. Restricting access to on-device screen content

5. Restricting access to dangerous hardware IDs.

6. Randomizing MAC address by default.

7. Restricting background activities launching from background.

8. Restricting access to background mic and camera.

These are some of the changes that Google has made to Android recently; however, in this essay, just only permissions will be reviewed.

Types of location access

Android’s location permissions face the following categories of location access:

• Foreground location
• Background location

The Operating System considers your Android app to be using foreground location if a feature of your app accesses the device’s current location in one of the following cases:

1. An activity that belongs to your app is visible.

2. Your application is running a foreground service.

Besides, it is recommended that you should declare a foreground service type of location. On Android 10, you have to indicate this foreground service type as follows:

<service
    android:name="MyNavigationService"
    android:foregroundServiceType="location" ... >
   
</service><service
    android:name="MyNavigationService"
    android:foregroundServiceType="location" ... >
   
</service>

Also, You must indicate a need for foreground location when your app requests either the ACCESS_COARSE_LOCATION permission or the ACCESS_FINE_LOCATION permission. For instance:

<manifest ... >
  <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
  <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
</manifest>

An Android app needs background location access if a feature within the app constantly shares location with other users or uses the Geofencing API. The system considers your app to be using background location if it accesses the device’s current location in any case other than the ones that are mentioned in the foreground location section. In Android 10, you have to indicate the ACCESS_BACKGROUND_LOCATION permission in your app's manifest in order to request background location access at runtime.

Privacy and location

In Android 10, Google wanted to enhance the user’s understanding of their current privacy configuration. As a result, they added a new top-level privacy setting that links to the permissions management, but also to privacy-related information, such as their web activity and their ad settings. Another privacy-related settings is the location setting, In the location settings, you can be able to find which app recently used your locations, but also location proxies, such as Bluetooth and Wi-Fi. Now, users are very sensitive about sharing location data; therefore, hence in Android 10, we allowed the users to choose if they share their location data all the time or only while using the app. Some use cases could be:

If the app wants to tag a photo or tag a social media post with location, the user clearly knows it is using the app, and knows how location is used. If the app provides navigation, the user probably select to temporarily use a various apps. In this case, we need the app to show a notification to remind the user that your navigation component is still using location data.

As you know, the background location use cases should become quite rare. Even if the app has a background location feature, the user might still be uncomfortable with sharing their location all the time with this application, and user might deny the access. Implementation-wise, if your feature requires background location access, you have to add an additional permission, that is called modifier permission in your manifest. And this permission is a runtime permission. And once it is granted, it grants background access to the additional foreground. So, this means, in this case, Coarse or Fine location.

<manifest ... >
  <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
</manifest>

As you can see, the background location something very unique. If your app is accessing location in the background, the Android OS will eventually show a notification reminder user that user has the choice to deny background access.

Activity recognition

In Android 9 and before, activity recognition was not considered user sensitive. However, in Android 10, Google has considered it user sensitive. Android 10 introduced the android.permission.ACTIVITY_RECOGNITION runtime permission for Android apps, which need to identify the user's step count or classify the user's physical activity, such as walking, biking, or moving in a vehicle. This is designed to give users visibility of how device sensor data is used in Settings. In addition, some libraries within Google Play services provide this permission, such as the Activity Recognition API and the Google Fit API.

Screen content and screen recording

This feature can restrict access to on device screen content. In fact, access the device’s screen contents require use the MediaProjectionManager API, which displays a prompt asking the user to provide consent.Screen recording is another very sensitive topic for the user. Hence we enforce user consent by requiring all apps to go through the MediaProjectionManager API. Therefore, to use this feature, you have to create a foreground service with a specific type. Then you start the foreground service. Once the foreground service is connected, you start the consent activity. The user can then say yes or no. Once a user says yes, you start the projection.

Some best practices for using permissions in Android development

Basically, Google has recently considered this important point that just only 18% of users allow every permission on their devices. As a result, developers should follow some best practices for engaging users to their apps. For example:

1. Requesting the minimum permissions that your feature needs.
2. Paying attention to your permissions required by libraries because your users do not distinguish between the data that your app is using and the third party SDKs.
3. Minimizing the use of location, particularly background location.
4. Requesting permissions in context for the use case
5. Being transparent about the data that you are using. Let your users know why need access to that data.

The new permission features in Android 11

At the moment, the latest version is Android 11 that is released by Google as a Beta version in August 6, 2020. Initially, Android 11 gives users the ability to specify more granular permissions for location, microphone, and camera. Also, the system resets the permissions of unused apps that target Android 11, and apps might require to update the permissions that they declare if they use the system alert window, or read information related to phone numbers. To be more specific, the changes have been mentioned as follows:

1. Whenever your app requests a permission related to location, microphone, or camera, the user-facing permissions dialog includes an option that is called Only this time. If the user chooses this option in the dialog, your Android app is granted a temporary one-time permission.
2. If your app targets Android 11 and is not used for a few months, the system protects user data by automatically resetting the sensitive runtime permissions that the user had granted your app.
3. If your app targets Android 11 and also requires to access the phone number APIs shown in the following list, you have to request the READ_PHONE_NUMBERS permission instead of the READ_PHONE_STATE permission.
4. In the latest version, there are some changes to how apps are granted the SYSTEM_ALERT_WINDOW permission. These changes are wanted to protect users by making the permission grant more intentional.

In conclusion

Basically, the purpose of a permission is protecting the privacy of an Android user. Android apps must request permission to access sensitive user data such as contacts and SMS, as well as some system features such as camera and internet. This essay considered some new features and best practices in Android permissions based on Google resources.