Maybe your app is using some third party SDK or code base, after all “standing on the shoulders of giants” is much less time consuming than starting from scratch. As an app developer, you are responsible for the overall health of your app, including the user experience and your code, as well as, of course, third-party SDKS and code libraries.

When you are considering using an SDK or code base, it is important to know how to handle and use data processing so that you can better protect user privacy.

In this article, I’ll share a few tools that can be used at different stages of application development, both during development and after release (this is a supplement to the SDK vendor documentation, which I recommend you read carefully).

Merged the Manifest view

To add flexibility, Gradle supports multiple separate Android Manifest files that are defined with application build configurations, application modules, or code base dependencies. These manifest files contain different default XML elements and attributes depending on project needs. When building an application, Gradle combines all the manifest files into a single manifest file. You can specify “merge rules” to define how values are merged. Next, let’s explore how you can use this tool to gain insight into the SDKS you rely on.

Android Studio provides a simple way to examine the final merged manifest file. Do this by clicking on the “Merged Manifest” TAB at the bottom of the Manifest file editing window. You can clearly distinguish the different Manifest Sources by the different colors highlighted in the interface. These sources include different code base dependencies, for example the following figure shows the permissions used by the dependency named “transport-Backend” in the application.

Merged Manifest view example

This presentation helps you quickly locate abnormal permission requests caused by application dependencies. Because run-time permission request dialogs can change user interactions, this analysis of data is not only useful, but also gives you a more complete picture of what your application’s dependencies are doing with the data. If necessary, you need to explain to the user when and why you want to access certain data.

If you see any unusual use of permissions in the merged manifest file, carefully review the associated dependency library documentation (or contact the developer) and make sure you understand the actual purpose for which the permissions are being used.

This permission is most likely optional for the service you are using. For scenarios where data usage needs to be minimized, you can add a “remove” node flag to the application module’s manifest file to prevent permission requests from that library from being merged into the final application.

<uses-permission android:name="SOME_PERMISSION"
   tools:node="remove"/>
Copy the code

Module dependency view

Another very useful tool in the development tool chain is Gradle’s module dependency support. Dependency diagrams are commonly used to locate problems encountered during the build process. Dependency charts can also show information about indirect dependencies, helping developers to be aware of additional dependencies introduced by dependency libraries. For more information, see: Viewing Module Dependencies.

Next, we’ll introduce another tool that can help you better understand data access in your application.

Data access Audit

As the complexity of your application increases, including the size of your team, it can be difficult to visually check access to sdK-related private data during application development.

Android 11 has introduced a feature called data access auditing, which helps developers determine which code is accessing data during application usage. This feature lets you associate private data with business scenarios in your application, such as “ordering coffee” or “sharing with friends.” Then locate any abnormal data access operations and determine which module or application scenario performed the access operations.

To use this feature, first create a Context object and associate it with a “property tag” that is associated with a business scenario, such as “order coffee”. You can be in OrderCoffeeActivity. The onCreate () method to implement these.

attributionContext = createAttributionContext("orderCoffee")
Copy the code

You can use the attributionContext created above as a parameter of type Context in later API calls to the development framework.

Next, set up a callback that will be invoked when private data is accessed. Inside the callback, you can retrieve the attributionTag (the attribute tag set above) and extract stack information or integrate your own application analysis methods.

val appOpsCallback = object : AppOpsManager.OnOpNotedCallback() {
      // This callback will be invoked when your application accesses private data
      // Such as contact data
      override fun onNoted(syncNotedAppOp: SyncNotedAppOp) {
        logDataAccess(syncNotedAppOp.op,
                 // This returns the tag string passed in when attributionContext was created,
                // For example, here is orderCoffee
                syncNotedAppOp.attributionTag, 
                Throwable().stackTrace.toString())
    }
Copy the code

Data access auditing supports both synchronous and asynchronous API calls and can be used on Android 11 and later devices. For more information, see: Data Access Auditing.

summary

Merged Manifest, Gradle support for module dependencies, and data access audit apis are all added to Android 11 to help developers provide additional monitoring of in-app and SDK-dependent data access and operations. This allows you to show better transparency to end users. It is recommended that you integrate these tools into your existing workflow.

Also, if you are distributing your app through the Google Play Store, make sure you have read the relevant user data policy and that the SDK you are using is compliant.