Configure the base module

Most app projects won’t require much effort to support Dynamic Delivery.That’s because the module that includes code and resources for your app’s baseAPK is the standard app module, which you get by default when youcreate a new app project in Android Studio.That is, the module that applies the app plugin below to its build.gradle fileprovides the code and resources for the base functionality of your app.

// The standard application plugin creates your app's base module.
apply plugin: 'com.android.application'

If you are concerned with reducing your app’s initial download size, it’simportant to keep in mind that all code and resources included in this moduleare included in your app’s base APK.

In addition to providing the core functionality for your app, the base modulealso provides many of the build configurations and manifest entries thataffect your entire app project. For example, signing for your app bundle isdetermined by information you provide for the base module, and versioning ofall your app’s APKs are specified on the versionCode attribute in your basemodule’s manifest. Other important aspects of the base module are describedbelow.

The base module manifest

The manifest for your app’s base module is similar to that of any other appmodule. Keep in mind, when Google Play generates your app’s base APK, it mergesmanifests for all modules into that of the base APK. So, if you are consideringadding dynamic feature modules to your app project,there are some aspects to the base APK's manifest that you should keep in mind:

• Because the base APK is always installed first, it should provide the mainentry point for your app. That is, it should declare an activity with thefollowing intent filter:

<intent-filter>
     <action android:name="android.intent.action.MAIN" />
     <category android:name="android.intent.category.LAUNCHER" />
</intent-filter>

• When downloading dynamic feature modules on demand, devices running Android6.0 (API level 23) and lower require the app to restart before completinginstallation of the new modules. However, if you want to be able to accessthe downloaded module’s code and resources immediately after it’s downloaded,you should include support for the SplitCompat library in your manifest. Tolearn more, readAccess code and resources from downloaded modules.

• Similarly, on devices running Android 6.0 (API level 23) and lower, apps needto restart before the platform can apply new manifest entries. So, if yourequire certain permissions or services as soon as a dynamic feature moduleis downloaded, consider including them in the manifest of your base module.

• Android App Bundles include support for uncompressed native libraries. So, ifyou include native libraries in your app and want to reduce disk usage,include the following in your base module's manifest:

<application
    android:extractNativeLibs="false"
    ... >

The base module build configuration

For most existing app projects, you don’t need to change anything in your basemodule’s build configuration. However, if you are considering adding dynamicfeature modules to your app project, there are some aspects to the basemodule’s build configuration that you should keep in mind:

• App signing: You don’t need to include signing information in the buildconfiguration file unless you want tobuild your app bundle from the command line.However, if you do include signing information, you should include it inonly the base module’s build configuration file. For more information, seeConfigure Gradle to sign your app.
• Code shrinking: If you want toenable code shrinking for yourentire app project (including its dynamic feature modules), you must doso from the base module’s build.gradle file. That is, you caninclude custom ProGuard rules in a dynamicfeature module, but the minifyEnabled property in dynamic featuremodule build configurations is ignored.
• The splits block is ignored: When building an app bundle, Gradleignores properties in the android.splits block. If you want to controlwhich types of configuration APKs your app bundle supports, instead useandroid.bundle todisable types of configuration APKs.
• App versioning: The base module determines the version code and versionname for your entire app project. For more information, go to the sectionabout how to Manage app updates.

Re-enable or disable types of configuration APKs

By default, when you build an app bundle, it supports generating configurationAPKs for each set of language resources, screen density resources, and ABIlibraries. Using the android.bundle block in your base module’sbuild.gradle file, as shown below, you can disable support for one or moretypes of configuration APKs:

android {
    // When building Android App Bundles, the splits block is ignored.
    splits {...}
    // Instead, use the bundle block to control which types of configuration APKs
    // you want your app bundle to support.
    bundle {
        language {
            // Specifies that the app bundle should not support
            // configuration APKs for language resources. These
            // resources are instead packaged with each base and
            // dynamic feature APK.
            enableSplit = false
        }
        density {
            // This property is set to true by default.
            enableSplit = true
        }
        abi {
            // This property is set to true by default.
            enableSplit = true
        }
    }
}

Manage app updates

With Android App Bundles and Dynamic Delivery, you no longer have to manageversion codes for multiple APKs that you upload to Google Play. Instead, youmanage only one version code in the base module of your app, as shown below:

// In your base module build.gradle file
android {
    defaultConfig {
        …
        // You specify your app’s version code only in the base module.
        versionCode 5
        versionName "1.0"
    }
}

After you upload your app bundle, Google Play uses the version code in yourbase module to assign the same version code to all the APKs it generates fromthat bundle. That is, when a device downloads and installs your app, all splitAPKs for that app share the same version code.

When you want to update your app with new code or resources, you must updatethe version code in your app’s base module, and build a new, full app bundle.When you upload that app bundle to Google Play, it generates a new set of APKsbased on the version code the base module specifies. Subsequently, when usersupdate your app, Google Play serves them updated versions of all APKscurrently installed on the device. That is, all installed APKs are updated tothe new version code.

Note: Because you no longer need to manage version codes for all of your app’sAPKs, you no longer need to include logic todynamically modify version codesbased on device configuration.

Download additional configuration APKs

One exception to the update flow described above is when an installed apprequires additional configuration APKs. Consider a user who changes theirdefault system language after already downloading your app. If your appsupports that language, the device requests and downloads additionalconfiguration APKs for those language resources from Google Play. However, thistype of update to your app does not change its version code, so the devicedownloads and installs only the configuration APKs that it requires.

上一页
arrow_back Overview

下一页
Configure at-install delivery arrow_forward