21 July 2020
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.
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:
Personal data is the subject of privacy law. Some important privacy laws include:
Our mobile devices are full of personal data. Theoretically, this could include practically anything about us. Commonly, it will include:
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.
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.
The Android SDK Terms & Conditions is clear that app developers must comply with relevant privacy law:
Here's another important section from this agreement:
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.
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:
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 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:
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:
Let's take a look at some examples of these permissions and their implications for app developers.
Here are some examples of normal permissions (as of Android 9):
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.
Here are some examples of signature permissions (as of Android 9):
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 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):
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.
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.
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:
TermsFeed is the world's leading generator of legal agreements for websites and apps.
TermsFeed Generators make it easy for you to generate the necessary legal agreements for your websites and apps:
With TermsFeed, you can generate:
This means including information about:
Enter your email address where you'd like your policy sent, select translation versions and click "Generate."
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:
And here's some further instruction from Google about the consent request that must accompany this disclosure:
The consent request must:
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.
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.
Google has more specific requirements for consent and transparency for the following types of apps:
Here are some of Google's specific requirements relating to these types of apps:
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:
This article is not a substitute for professional legal advice. This article does not create an attorney-client relationship, nor is it a solicitation to offer legal advice.