Android Collection of Data and Sensitive Data

Android is an open source platform designed to encourage third-party developers. There are now well over two million Android apps, many of them produced by small businesses or indie developers.

But mobile apps have the potential to be intrusive. They can allow complete strangers to monitor people's movements, spending habits, and correspondence. Because of these privacy risks, Google makes strict demands of developers regarding how apps access their users' devices.

Let's see how you can develop an app that fulfills the requirements of both Google and the law.

What is Personal Data?

Personal data (sometimes called "personal information" or "personally identifying information") is information that reveals something about and could be used to identify an individual. This includes:

• Directly identifying information, such as a name or address.
• Indirectly identifying information, such as a username or email address. This information could lead to identification if it were combined with other information.
• Technical information such as cookie data and IP address.

Personal data is the subject of privacy law. Some important privacy laws include:

• California Online Privacy Protection Act (CalOPPA). This must be obeyed by anyone hoping to make their app available throughout the United States.
• General Data Protection Regulation (GDPR) and ePrivacy Directive (sometimes known as the Cookies Directive), which apply to anyone offering their app in the European Union.
• Personal Information Protection and Electronic Documents Act (PIPEDA), which applies to any app offered in Canada.

Android Apps and Personal Data

Our mobile devices are full of personal data. Theoretically, this could include practically anything about us. Commonly, it will include:

• Photos of the device owner and other people
• Biometric information (e.g. fingerprint)
• Financial and banking information
• Contact details of friends and colleagues
• Login credentials for various user accounts
• Correspondence with others, often of a private and intimate nature

A device also transmits personal data in order to identify itself and its owner, such as an IMEI number, IP address and, of course, phone number.

Apps can interact with the user's device so as to retrieve and share this information. They can also activate some of the device's functions, such as the camera and microphone, that can be used to collect additional personal data.

Because of the extremely sensitive personal data that a person's mobile device might contain, development of mobile apps is tightly regulated by privacy laws like those listed above.

Careless treatment of personal data in a mobile app can have disastrous consequences.

Air Canada, for example, suffered a data breach in which mobile app users' passport numbers were stolen, seemingly due to having implemented a weak password system. And in 2018, five companies settled cases with the New York Attorney-General after they allegedly failed to implement proper security procedures in their mobile apps.

Google's Terms and Policies

We've seen that Android app developers must obey privacy laws. They must also obey the rules laid down by Google in its terms and policies.

In this article, we're going to focus mostly on Google's requirements. But first, it's worth noting that one of Google's most important rules is to be legally compliant.

Android Software Development Kit

The Android SDK Terms & Conditions is clear that app developers must comply with relevant privacy law:

Here's another important section from this agreement:

This requires developers to provide information about their practices (i.e. a Privacy Policy) and store all personal data securely.

Google Play

If you're hoping for your Android app to get any kind of an audience, distribution via the Google Play store is essential. This requires you to agree to the Google Play Developer Distribution Agreement.

This agreement contains many similar clauses to those contained in the policies above. Take a look at this section:

Even where a user accuses an app of having processed their personal data unlawfully, Google has the right to take it down from Google Play. Not only that, you'll be liable for refunding anyone who has purchased the app in the previous year.

Google's Requirements for EU Developers

Here's an excerpt from Google's EU User Consent Policy:

This means that any app developer using the Android Software Development Kit (SDK) who is subject to the GDPR must:

• Obtain users' consent for:
• Cookies
• Local storage
• Processing of personal data for ad personalization
• Keep records of consent
• Inform users how they can withdraw consent
• Inform users of any third parties that you might allow process your users' personal data

Google's EU User Consent Policy has implications for any developer serving EU users. However, the policy was mostly written to require consent for personalized and non-personalized ads.

Ads are not the focus of this article. But if your app uses Google Ads, it's important to be aware that Google collects personal data for the purpose of providing these.

Google's Rules on Personal and Sensitive Data

Google gives some specific examples of what it calls "personal and sensitive information" (personal data):

Google places four broad requirements on the publication of apps that collect such data:

1. Consent - you must ask permission from their users when collecting such personal data is required.
2. Transparency (or "disclosure")- you must explain your reasons for requiring this access, and also post a legally compliant Privacy Policy.
3. Data minimization - you must not ask for personal data or request permissions you don't need.
4. Security - you must handle all personal data securely.

We will be focusing on the first two of these requirements - consent, and transparency. Google also provides lots of information about data minimization and security.

Consent and Permissions

Privacy law, particularly the GDPR, requires that you have consent for collecting personal data in certain circumstances. Google's terms also specify this.

Where an app needs to interact with a user's device to retrieve personal data or activate a function, such as turning on the camera or GPS, Google has specific requirements on how developers must seek permission to run such processes.

Certain interactions are more intrusive than others. For example, consider the implications of a user giving an app access to their camera and microphone. If the user isn't sure how secure the app is, or doesn't understand why this is necessary, they will be hesitant about letting a third party see and hear them.

Google uses "permission levels" to classify app/device interactions. There are four permission levels:

1. Normal
2. Signature
3. Dangerous
4. Special

Let's take a look at some examples of these permissions and their implications for app developers.

Normal Permissions

Here are some examples of normal permissions (as of Android 9):

• Pairing Bluetooth devices
• Turning WiFi on and off
• Expanding the status bar
• Opening network sockets
• Setting an alarm
• Setting the wallpaper

You aren't required by Google to request specific consent for normal permissions.

Here's how Google's guidance on permission levels describes normal permissions:

You can see that normal permissions are for things that pose very little risk to a user's privacy. Permissions are granted automatically when an app is installed without prompting the user to grant the permission.

Signature Permissions

Here are some examples of signature permissions (as of Android 9):

• Reading voicemail
• Clearing the app's cache
• Various "bind" permissions, for example, BIND_WALLPAPER which is required by a wallpaper service to show a live wallpaper behind other apps

Signature permissions also do not necessarily require specific approval from the user. Google's app certification process validates a developer's request for signature permissions on install:

There are some minor limitations here in that some signature permissions aren't for use by third-party apps, and the app must have an appropriate certificate to use a permission.

Dangerous Permissions

Dangerous permissions are the most significant class of permission for our purposes.

Dangerous permissions involve personal and sensitive data. Here are some examples of dangerous permissions (as of Android 9):

• Reading and writing to a user's calendar
• Interacting with the call log
• Using the camera
• Reading or writing a user's contacts
• Accessing "coarse" or "fine" location data
• Recording audio
• Making or answering calls, reading the phone state or phone numbers
• Using body sensors
• Sending, receiving or reading SMS
• Reading or writing to external storage

Here's some of Google's guidance on dangerous permissions:

Dangerous permissions require consent on runtime. Here's how this looks in the GPS Route Tracker app:

Below, we'll be looking in more detail at how you should be requesting consent and using in-app disclosures for dangerous permissions.

Special Permissions

Here's Google's advice about the two special permissions:

Because of very specific circumstances in which the special permissions might be used, we won't be focusing on them. As noted by Google, most apps shouldn't - and don't - use them.

Transparency

We've seen that dangerous permissions require specific runtime consent. But it's not enough to just ask for consent without providing any context. Google also requires transparency.

You must make appropriate disclosures both by:

• Writing and displaying a Privacy Policy for your app, and
• Disclosing your specific reasons for requesting dangerous permissions at the point that you request them.

Privacy Policy

Where your app collects personal data, it's not only Google that requires you to have a Privacy Policy. A Privacy Policy is a legal requirement under most privacy laws.

The contents of your Privacy Policy may vary depending on where your users are based. You should be able to cover all bases if you produce a Privacy Policy that complies with the GDPR.

This means including information about:

• Your company's name and contact details
• Details of your Data Protection Officer and EU Representative (if you have nominated either)
• Which categories of personal data you process (e.g. name, location data, cookies)
• Your purposes and lawful bases for processing personal data
• The ways in which you may process personal data (collecting, storing, etc.)
• What types of organizations you might share personal data with (e.g. payment processors)
• How long you store personal data
• How your users can exercise their data rights
• Details of any international data transfers

Your Privacy Policy must be available in via your Google Play listing. Here's an example from Tik Tok:

You must present your Privacy Policy to your users when collecting certain personal data.

For example, your Privacy Policy should be available at or before account creation. Here's an example from Lookout that has the Privacy Policy linked for users who have yet to sign up:

You should also ensure your Privacy Policy is presented to your users each time there's an update. Here's what happens on opening the Candy Crush Saga app after a policy update:

You also need to ensure that your Privacy Policy can be easily accessed via your app. There's a link to the Policy in the settings menu of the Candy Crush app:

It's good practice to embed the policy into your app. Here's how Uber has embedded its Privacy Policy so it opens within the app itself:

How to Create a Privacy Policy for Your Mobile App

In-App Disclosure

Creating a Privacy Policy and conspicuously displaying a link to it within your app is essential. But this is not sufficient to meet Google's transparency requirements.

Google also requires that you disclose certain information from within your app when requesting permissions. Here are some of Google's rules about how you must display this in-app disclosure:

The disclosure must:

• Be part of the app itself
• Not only be part of a Privacy Policy or Terms of Service
• Not require users to navigate to a menu to find it
• Not be included with other disclosures that don't relate to personal or sensitive data collection
• Describe what data is being collected
• Explain how that data will be used

And here's some further instruction from Google about the consent request that must accompany this disclosure:

The consent request must:

• Be presented in a clear and unambiguous way
• Require affirmative user action to prove consent (navigating away doesn't count as consent)
• Not use auto-dismissing messages or messages that expire after a period of time

The collection of personal or sensitive data cannot begin until proper consent is obtained.

This means that even when using Android SDK's standard run-time permission request when requesting dangerous permissions, you'll also need to provide information about why your app is requesting this permission.

Here's an example from Kaspersky. When first opening the app, users see a list of which permissions Kaspersky requires and an an explanation of why each permission is required:

Clicking "Next" prompts the standard runtime permission:

And here's what Snapchat users see when the app requests access to their device's camera for the first time:

Apps collect personal data in other ways. For example, Viber requires users to submit their date of birth as part of its age verification process:

Clicking on the "Why we ask for this information" link leads to a webpage displaying this explanation:

There are two things to note about Viber's consent request.

1. It is not clear that a full date of birth is required, when simply asking for the user's age may be enough. Consider this in the light of Google and the GDPR's requirement that you do not collect unnecessary personal data.
2. This explanation is displayed on a separate webpage and would only be accessible to users with a functioning network connection. Consider this in light of Google's requirement that in-app disclosures "must be within the app itself, not only in the Play listing or a website."

A way around this would be for the app to ask a user to select or enter their specific age (not birthdate), and add a brief statement to that screen itself that says the app needs to know a user's age because users under 16 have different access to the app than older users.

Requirements for Specific Types of Apps

Google has more specific requirements for consent and transparency for the following types of apps:

• Apps that involve a user's financial data
• Apps that access a device's contacts
• Security and anti-virus apps

Here are some of Google's specific requirements relating to these types of apps:

Summary

This has been an introduction to some of the requirements placed on Android app developers when requesting permissions and collecting their users' personal data.

If you're developing an Android app it's important that you read Google's terms and policies in full.

You should now understand the following things:

• Privacy laws and Google's terms regulate the ability of apps to collect personal and sensitive data
• Compliance with Google's terms requires compliance with privacy law
• Google groups app permissions into four types:
• Normal
• Signature
• Dangerous
• Special
• Dangerous permissions have specific consent and disclosure requirements
• You must have a Privacy Policy if you wish to request dangerous permissions
• You must disclose specific information within your app when requesting consent for dangerous permissions