I. Introduction

• The Android operating system always focuses on helping users experience the latest innovations, while ensuring the security and privacy of users is always a top priority. In this article, we will learn best practices for Android Privacy.
• The content of the article is referenced here

II. main content

1. Pay attention to authorization requirements

Build trust with our users by being transparent and giving users control over how they experience our application.

• Only requires the minimum permissions our feature needs. Whenever we introduce major changes to our application, review the requested permissions to confirm that the app features still need them.
  1. Keep in mind that newer versions of Android often introduce privacy-conscious ways of accessing data without requiring permissions.
  2. Request permissions as needed rather than upon application start-up, making this permission obvious to the user.
  3. If our app is served on Google Play, Android vitals tells us what percentage of users deny the requested in-app permissions. Use this data to re-evaluate the design of features for which required permissions are often denied.
• Follow the recommended procedure to explain why a feature in our app needs to be authorized.
• Remember that a user or system can deny permissions multiple times. Android respects this user’s choice by ignoring permission requests from the same app.
• Delicately devalue when a user denies or revokes permissions. For example, we can disable voice input of an app if the user doesn’t give permission to the microphone.
• If you are using an SDK or a library to access data protected by malicious permissions, users will often assign this to our application. Make sure we always understand the permissions required by the SDK and why.
  1. If we are testing the app on Android 11, use data access testing to see where in the code is and in the 3rd-party library accessing private data.

2. Minimize the use of location

If our application requires location access, then help the user make an informed decision.

• If our app collects location information, explain to the user how our app uses this information to provide them with specific benefits. If our application can support use cases without asking for any location data, then don’t request any location permissions.
• If our app needs to pair the user’s device with a nearby device via Bluetooth or Wi-Fi then use a companion device manager without asking for location permissions.
• Consider the level of location granularity our application needs. Raw location access is sufficient to cover most location-related use cases.
• Access location data while your app is visible to the user. That way, the user can better understand why our application is requesting location information.
• If our application requires location in the background, such as when implementing geofencing, then make sure it is critical to the core functionality of the application and done. in a way that is easy for the user to see. Learn more about cautions for using locations in the background here
• Our application design can handle it subtly when we don’t have regular access to the location. On Android 10 and up, a user can restrict an app’s location access while the app is in use.
• If our application needs to maintain location access for the persistent user-initiated task after navigating away from the application’s interface, start the background service before our application goes into mode. background level. We can do this in onPause ().
• Do not initialize foreground services from background. Instead, consider launching our application from a message and then executing the location code as the application’s interface renders.

3. Handling data safely

Transparency and confidentiality in the way we handle sensitive data.

• Helping users know when and why our apps collect, use, or share sensitive data.
• Use a range-based storage model if possible. Learn how to switch to scoped memory based on our application use cases here
• Always use a secure network connection. For our app’s data, let’s use Android’s built-in credential encryption. For data in transit, you should use TLS (the legacy of SSL) for all data transfers regardless of sensitivity.
• Files containing sensitive data must reside in our own application directory in internal memory.
• On Android 10, for files related only to our apps, store them in the app-specific folder in external storage. Learn more about range storage here
• If we need to pass sensitive data to another app, use an explicit intent. Grant data access once to further restrict access of another application.
• Even if our application is on foreground, it is best to show a real-time indicator that we are shooting from a microphone or camera. Note that Android 9 and up do not allow microphone or camera access while our app is in the background.
• Jetpack provides several libraries to keep our application data more secure. Learn more in the Jetpack Security and Jetpack Preferences library user guides.
• Do not include sensitive data in logcat or log files in your application. Learn more about how to handle user data here

4. Use a reset identifier

Respect user privacy and use a resettable identifier.

• Do not access the IMEI and the device’s serial number, as these identifiers are immutable. If we try to access these identifiers in an app on Android 10 (API 29) or later, a SecurityException happens.
• Use the Advertising ID only for user profiles or ad usage scenarios. For apps in Google Play this is required. Always respect the user’s preference for ad tracking to personalize.
• For the vast majority of non-ad use cases, use a privately stored, app-scoped universal-unique ID (GUID) .
• Use the Android ID (SSAID) security setting to share status between apps we own without requiring the user to log in to the account. Learn more about tracking logged out user preferences between apps here