Configure the base module

    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 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:

    • 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, read.

    • 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:

    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, see.
    • 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 property in dynamic featuremodule build configurations is ignored.
    • 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 .

    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 block in your base module’sbuild.gradle file, as shown below, you can disable support for one or moretypes of configuration APKs:

    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:

    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.

    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.