• Home
  • Platform modules
  • Digital Experience
  • Mobile applications
  • Android
  • Plugin
  • Change Dynatrace Android Gradle plugin configuration based on the project structure

Change Dynatrace Android Gradle plugin configuration based on the project structure

The Dynatrace Android Gradle plugin scans all subprojects and configures the auto-instrumentation process for your application modules. Most other modules are not affected by the plugin and in some cases, such as Android library modules, you might want to adjust the instrumentation process.

The following section describes the behavior of the plugin for certain module types and architectures.

Android library modules

All Android/Java libraries (and third-party libraries) are auto-instrumented when they are part of your Android application. No additional configuration is needed because the plugin has access to all Gradle dependencies of your Android application project. If you want to enrich mobile user experience data generated by your library modules, add the OneAgent SDK manually as Gradle dependency.

Note: You must use the same version for the OneAgent SDK and the Dynatrace Android Gradle plugin. It’s recommended that you specify the OneAgent SDK dependency via the Dynatrace Android Gradle plugin.

If you have multiple library projects in your multi-module project and want to use the OneAgent SDK in every library module, use the following Gradle snippet:

gradle
subprojects { pluginManager.withPlugin("com.android.library") { dependencies { implementation com.dynatrace.tools.android.DynatracePlugin.agentDependency() } } }
gradle
subprojects { pluginManager.withPlugin("com.android.library") { dependencies { "implementation"(com.dynatrace.tools.android.DynatracePlugin.agentDependency()) } } }

You can also use other Gradle features to fine-tune this behavior. For example, the following Gradle snippets use the module name to determine if the OneAgent SDK must be added to a specific Android library module:

gradle
subprojects { project -> pluginManager.withPlugin("com.android.library") { if(project.name == 'firstLibrary' || project.name == 'secondLibrary') { dependencies { implementation com.dynatrace.tools.android.DynatracePlugin.agentDependency() } } } }
gradle
subprojects { project -> pluginManager.withPlugin("com.android.library") { if(project.name == "firstLibrary" || project.name == "secondLibrary") { dependencies { "implementation"(com.dynatrace.tools.android.DynatracePlugin.agentDependency()) } } } }

Android projects with dynamic-feature architecture

The Android Gradle plugin supports Play Feature Delivery. Apps can consist of a base module and one or more dynamic feature modules. Dynamic feature modules can be loaded on demand or even as a single instant feature without having to install the whole app.

The base module applies the com.android.application plugin whereas the dynamic feature modules apply the com.android.dynamic-feature plugin. When you build the app, the plugin auto-instruments both plugin types. The same configuration is used for all modules. With the auto-start injection feature, the plugin instruments the Application class of the base module. This ensures that the agent is always running, even when a dynamic feature runs in instant mode.

Instant delivery and manual startup

If you want to deactivate the auto-start injection feature and start the agent manually in your code, beware of the impact it may have on instant-enabled dynamic feature modules. Instant-enabled modules are intended to run on a device without being installed. This means that only the base module and the instant-enabled dynamic feature module are shipped to the device. For the agent to function properly it must be started in the base module, preferably in the Application class of the base module and not in a class or method that is not invoked in time by the instant module.

Instrumenting Android build variants

If you use product flavors in your modules, use the same product flavor names and dimensions in every module. When you use the missingDimensionStrategy property of the plugin, ensure that each variant in every module is associated with the correct variant-specific configuration by adjusting the variant filter property. You can use the printVariantAffiliation task to determine the associations between variants and configurations.

Android projects with multiple application modules

Configuring the Dynatrace Android Gradle plugin for Android projects with multiple application modules is similar to configuring an Android project that has only a single application module. Follow the instructions at Instrumentation via Dynatrace Android Gradle plugin.
Note: Ensure that you skip Step 3: Apply the Dynatrace Android Gradle plugin and add the configuration snippet.

Instead of applying the com.dynatrace.instrumentation plugin ID to the top-level build.gradle file, apply the com.dynatrace.instrumentation.module plugin ID to the build.gradle of every application module.

gradle
apply plugin: 'com.dynatrace.instrumentation.module' dynatrace { configurations { sampleConfig { autoStart { applicationId '<YourApplicationID>' beaconUrl '<ProvidedBeaconURL>' } } } }
gradle
apply(plugin = "com.dynatrace.instrumentation.module") configure<com.dynatrace.tools.android.dsl.DynatraceExtension> { configurations { create("sampleConfig") { autoStart { applicationId("<YourApplicationID>") beaconUrl("<ProvidedBeaconURL>") } } } }

To customize instrumentation for a specific application, you have to modify the plugin configuration in the build.gradle file of the application. The other application modules will not be affected by this configuration change.

Android projects with multiple application and dynamic-feature modules

When the Android project also contains modules that use the com.android.dynamic-feature plugin, it's recommended that you copy the above snippet into a new .gradle file. The generated file must be applied in the application module and all dynamic-feature modules that belong to this application module. To apply a .gradle file, use the following snippet as described in the official Gradle documentation:

gradle
apply from: 'other.gradle'
gradle
apply(from = "other.gradle.kts")

With this approach the same configuration is used for all modules that belong to the same application.
Note: It's not possible to use different configurations for the same dynamic-feature module (when it belongs to multiple applications).

Android projects with only one build file

When your Android project doesn't use the recommended architecture and consists of only one build.gradle file, the instrumentation steps are slightly different. In this case, both, 'top-level build file' and 'module-level build file', refer to the same build.gradle file.

Perform all steps as described in Instrumentation via Dynatrace Android Gradle plugin, except Step 3: Apply the Dynatrace Android Gradle plugin and add the configuration snippet. Instead of applying the com.dynatrace.instrumentation plugin ID in the build.gradle file, apply the com.dynatrace.instrumentation.module plugin ID. Also make sure that the com.dynatrace.instrumentation.module is applied after the com.android.application plugin and before the com.google.firebase.firebase-perf plugin if that is used as well.

The Firebase Performance Monitoring plugin version 1.4.0+ used with the Android Gradle plugin version 4.2.0 is incompatible with the Dynatrace Android Gradle plugin. For a solution, see Why am I missing web requests when I use the Firebase plugin? in the FAQ.

gradle
apply plugin: 'com.android.application' ... apply plugin: 'com.dynatrace.instrumentation.module' dynatrace { configurations { sampleConfig { autoStart { applicationId '<YourApplicationID>' beaconUrl '<ProvidedBeaconURL>' } } } }
gradle
apply(plugin = "com.android.application") ... apply(plugin = "com.dynatrace.instrumentation.module") configure<com.dynatrace.tools.android.dsl.DynatraceExtension> { configurations { create("sampleConfig") { autoStart { applicationId("<YourApplicationID>") beaconUrl("<ProvidedBeaconURL>") } } } }