Google I/O: Android Privacy Changes and How to Design for Them

Today at one of Google I/O’s morning sessions, Svetoslav Ganov (Android Team engineer) and Charmaine D’silva (product manager) discussed some of the privacy changes in Android Q. They also highlighted best practices for building privacy forward apps.

How to Properly Engage Users With Application Permissions

Google’s statistics show that only 18% of users allow all permissions from applications. The talk highlighted 3 primary reasons that users deny permissions:

“Apps shouldn’t need the permission”
“Expect app will still work without permission”
“Can always grant permission later”

There are several ways that developers can design their applications to encourage users to engage with permissions. The first strategy highlighted in the session was to look for alternative APIs that could provide access to the data you need. For example, instead of working with the READ_PHONE_STATE permission, developers could utilize the requestAudioFocus() function to get the information that they need while avoiding asking for permission all together. Another strategy to increase engagement is to determine the scope of the permission and think through the best way to ask for it. Users are more likely to allow permission if they understand the specific feature that the permission will allow. Asking a user to allow the application to take a picture is far more engaging than just asking for access to the camera. The presenters also highlighted the importance of making sure users aren’t surprised by the way their data is used. They recommended that developers only request exactly the data that they need, and only store the information for as long as necessary.

Additionally, Android Q will debut more granular control for the way developers request permission from users. Applications will now be able to request only foreground access to data, or foreground and background access. Moving away from a more binary selection process in Android P.

Device Identifiers

In Android Q, hardware based device identifiers will be locked down, requiring developers to use software based, user resettable, device identifiers. Google views this as a much more privacy friendly solution.

App Launching and Notifications

In Android Q, Google is working to make notifications and application launching feel less intrusive. The presenters recommended using Notification APIs to provide information to users without interrupting application flow. This allows notifications for alarms or incoming calls to be served either in full screen mode when the device is locked, or in a less intrusive heads-up notification when the device is in use.

Background Launching Now Requires User Interaction

Moving forward applications will be restricted from launching into the foreground from the background without a user-initiated action. This change is designed to ensure that users are not inappropriately interrupted while using other applications.

Foreground Services

Foreground services offer a lightweight method for providing information, but they can easily become a messy solution when overused. To solve this problem Android Q debuts Service Types, which will limit permission usage based on usage types. Developers will now need to declare the service type in the manifest of their service in order to be able to request access to foreground services. 

Be sure to read the next Security article: Daily API RoundUp: IPinfo, SafetyLocker, Cloverly, SiteWhere

 

Comments (0)