Android is focused on helping users take advantage of the latest innovations
while making their security and privacy top priorities. Use the checklists on
this page as a source for common privacy guidelines and best practices.
Some of the best practices described on this page also appear in the
cheat
sheet
.
Checklist: minimize your permissions requests
Build trust with your users by being transparent and providing
users control over how they experience your app.
- Request the minimum permissions that your feature needs:
when
introducing major changes to your app, review the
requested permissions
to confirm that your
app's features still need them.
- Newer versions of Android often introduce ways to access data in a
privacy-conscious manner without requiring permissions. For more
information, see
Evaluate whether your app needs to declare
permissions
.
- If your app is distributed on Google Play, you can use
Android
vitals
to obtain the percentage of users that deny permissions
in your app. Use this data to reassess the design of features whose
required permissions are most commonly denied.
- Explain why a feature in your app needs a permission:
follow the
recommended flow
to do so. Request the permission when
it's needed, rather than at app startup, so that the permission need is
clear to users.
- Be aware that users or the system can deny the permission multiple
times:
Android respects this user choice by ignoring permission requests
from the same app.
- Degrade gracefully without permission:
your app should degrade
gracefully when users deny or revoke a permission—for example,
disabling voice input if the user doesn't grant the microphone permission.
- Remove access to unnecessary permissions
: when you update your app,
remove its access
to any runtime permissions that it no
longer needs.
- Understand the permissions required by an SDK or library:
if you're
using an SDK or library that accesses data guarded by dangerous permissions,
users generally attribute this to your app. Make sure you
understand the
permissions that your SDKs require and why
.
Checklist: minimize your use of location
Data about a user's location is sensitive; avoid using location data if
possible. If you must use location services, take steps to minimize the
collection of location data. Use the following checklist to minimize your app's
use of location.
- Degrade gracefully without location data:
on Android 10
(API level 29)
and higher, users can limit your app's location access to while the app is
in use. Design your app so that it degrades gracefully when it doesn't have
uninterrupted access to location.
- Use nearby Bluetooth or Wi-Fi devices:
if your app needs to pair the
user's device with a nearby device over Bluetooth or Wi-Fi, use the
companion device manager
, which doesn't require location
permissions. Learn more about
Bluetooth
and
Wi-Fi
permissions.
- Use coarse location accuracy when possible:
review the
level of
location granularity
that your app needs. Coarse location
access is sufficient to fulfill most location-related use cases.
- Access location in the background only as necessary:
if your app
requires background location, such as with geofencing, implement it to be
obvious to users. Learn more about
considerations for using background
location
.
- Access location data while your app is visible to the user:
this lets
users better understand why your app requests location information.
- Don't initiate foreground services from the background:
consider
launching your app from a notification and then executing location code when
your app's UI becomes visible. If your app must retain location access to
support a user-initiated ongoing task after the user navigates away from
your app's UI,
start a foreground service
before going into
the background.
Checklist: handle data safely
Note:
You can read more about what's considered sensitive data in the
User Data article
page in the Google Play Developer Policy Center.
Be transparent, secure, and thorough in how you handle sensitive data. Use the
following checklist as guidance to handle user data more safely in your app.
Audit access to data:
on Android 11 (API level 30) and higher,
perform data access auditing
to gain insights into how your
app and its dependencies access private data from users, making it easier to
identify unexpected data access.
Declare package visibility needs:
if your app targets Android 11 or
higher, the system makes certain apps invisible to your app by default.
Learn how to
make those other apps visible to your app
.
Support scoped storage:
to give users more control and limit file
clutter, apps targeting Android 10 (API level 29) or higher
automatically
have scoped access into external storage, or
scoped storage
.
Such apps have access only to their own directory and media they've created.
Learn how to
migrate to scoped storage
.
Work with user-resettable identifiers:
to protect the privacy of your
users, use the most restrictive identifier that satisfies your use
case—see the
checklist for resettable identifiers in this
document
.
Provide prominent disclosure and consent:
follow the
Google Play User
Data policy best practices
for providing prominent
disclosure and consent requests to users.
Declare your app's data use:
properly fill out the Google Play
Console Data safety form
, which explains to users which
types of user data your app collects and shares.
Securely pass sensitive data to other apps:
use an explicit intent to
pass sensitive data to another app.
Grant one-time data access
to further restrict another
app's access.
Don't include sensitive data in Logcat messages or log files:
learn
more
.
Checklist: use resettable identifiers
Respect your users' privacy and use resettable identifiers. See
Best practices for unique identifiers
for
more information.
Don't access IMEI or the device serial number:
these identifiers are
persistent. An app targeting Android 10 (API level 29) or higher
causes a
SecurityException
if it
tries to access these identifiers.
Only use an advertising ID for user profiling or ads use cases:
always
respect user preferences on
advertisement tracking
for personalization.
Important:
This is required for Google Play.
Use a privately-stored GUID:
for the vast majority of non-ads use cases,
use a privately-stored globally-unique ID (GUID)
, which is
app-scoped.
Use the SSAID for apps that you own:
to share states between apps that
you own without requiring users to sign into an account, use secure settings
Android ID (SSAID). Learn more about
how to save signed-out user
preferences between apps
.
Checklist: support user-facing privacy features
Be transparent, secure, and thorough in how you handle sensitive data. Use the
following checklist as guidance to ensure your app safely handles user data.
Provide a rationale for access to sensitive information:
on Android
12 (API level 31) and higher, users can access the Privacy
Dashboard in system settings to learn details related to when apps access
location, microphone, and camera information. Learn more about
providing
this explanation to users
.
Prompt the user to disable app hiberation
: if a user hasn't interacted
with an app that targets Android 11 (API level 30) or higher for a
few months, the system places that app in a hiberation state. Learn about
app hibernation and how to ask the user to disable it
.
Securely pass sensitive data to other apps:
if you need to pass
sensitive data to another app, use an
explicit intent
.
Grant one-time data access
to further restrict another
app's access.
Visually indicate your app is capturing audio or imagery:
even when your
app is in the foreground, show a real-time indicator that you are capturing
from the microphone or camera. Note: Android 9 (API level 28)
and higher
don't allow for microphone or camera access when your app is in
the background
.
Privacy cheat sheet
The privacy cheat sheet is a quick reference of some of the most useful privacy
APIs in Android, as well as the best practices that you should keep top of mind
when you design your app.
The cheat sheet is also downloadable in PDF format: