Android is focused on helping users take advantage of the latest innovations while making their security and privacy top priorities.
Some of the best practices described on this page also appear in the cheat sheet.
Pay attention to permissions
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. Whenever you introduce major changes to your app, review the requested permissions to confirm that your app's features still need them.
- Keep in mind that 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, Android vitals tells you the percentage of users who deny permissions in your app. Use this data to reassess the design of features whose required permissions are most commonly denied.
Follow the recommended flow to explain why a feature in your app needs a permission. Request the permission when it's needed, rather than at app startup, so that the permission need is clear to users.
Keep in mind that users or the system can deny the permission multiple times. Android respects this user choice by ignoring permission requests from the same app.
Gracefully degrade when users deny or revoke a permission. For example, you can disable your app's voice input feature if the user doesn't grant the microphone permission.
When you update your app, remove your app's access to any runtime permissions that your app no longer needs.
If you are 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.
- If you test your app on Android 11 (API level 30), use data access auditing to discover places in your code and in third-party library code where private data is being accessed.
Minimize your use of location
If your app can support its use cases without requiring any location data, don't request any location permissions. If your app requests permission to access location, help users make an informed decision.
- If your app needs to collect location information, explain to users how your app uses this information to deliver specific benefits to them.
- 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.
- Review the level of location granularity that your app needs. Coarse location access is sufficient to fulfill most location-related use cases.
- Access location data while your app is visible to the user. That way, users can better understand why your app requests location information.
- If your app requires background location, such as when implementing geofencing, make sure that it's critical to the core functionality of the app and is done in a way that's obvious to users. Learn more about considerations for using background location.
- 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 all-the-time access to location.
- If your app needs to retain location access for a user-initiated ongoing task
after the user navigates away from your app's UI, start a foreground
service before your app goes into the
background. You can do this in one of Android's lifecycle callbacks, such as
- Don't initiate foreground services from the background. Instead, consider launching your app from a notification and then executing the location code when your app's UI becomes visible.
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 and secure in how you handle sensitive data.
- Make users aware of when and why your app collects, uses, or shares sensitive data.
- Use the scoped storage model if possible. Learn how to migrate to scoped storage based on your app's use cases.
- Always use secure network connections. For your app's data at rest, use Android's built-in credential encryption. For data in transit, use TLS, the successor of SSL, for all data transmission regardless of sensitivity.
- Place files that contain sensitive data in your app-private directory within internal storage.
- On Android 10 (API level 29), store files only relevant to your app in the app-specific directory in external storage. Learn more about scoped storage.
- If you need to pass sensitive data to another app, use an explicit intent. Grant one-time data access to further restrict the other app's access.
- Even when your app is in the foreground, show a real-time indication that you are capturing from the microphone or camera. Note that Android 9 (API level 28) and higher don't allow for microphone or camera access when your app is in the background.
- Don't include sensitive data in logcat messages or your app's log files. Learn more about how to handle user data.
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, as these identifiers are
persistent. If you try to access these identifiers in an app that targets
Android 10 (API level 29) or higher, a
- Only use an advertising ID for user profiling or ads use cases. For apps in Google Play, this is a requirement. Always respect user preferences on advertisement tracking for personalization.
- For the vast majority of non-ads use cases, use a privately stored globally-unique ID (GUID), which is app-scoped.
- Use the secure settings Android ID (SSAID) to share state between the apps that you own without requiring the user to sign in to an account. Learn more about how to track signed-out user preferences between apps.