Google’s Official Plugin-Based Solution – Analyzing Android App Bundles

Hot Article Guide | Click Title to Read

How to Advance in Job Switching Season in September and October?

What Are the Weirdest Requirements Encountered as a Programmer?

Interview Journey in August 2018: 6 Days, 21 Companies

Author: *Jiawei

Source: https://zhuanlan.zhihu.com/p/36902641

Android App Bundles

Android App Bundles (hereinafter referred to as AAB) is a new dynamic framework introduced at this year’s Google I/O conference. Unlike Instant Apps, AAB achieves dynamic loading through Split APK. Before introducing AAB, let’s first understand Split APK.

Split APKs

Split APKs is a multi-APK build mechanism provided since Android 5.0. With Split APKs, one APK can be split into multiple APKs based on ABI and screen density dimensions, effectively reducing APK size. When users download the application package, it will only include the corresponding platform’s SO and resources. Since it requires Google Play support, it is not feasible in China. Most domestic app developers place SO files only in the armabi directory to address different CPU architecture issues. While this can effectively reduce package size, it may lead to performance issues.

When installing the application, the base APK is installed first, followed by the split APKs. To understand how split APKs work, let’s briefly analyze the source code. Since split APKs have been supported since Android 5.0, we will start our analysis from version 5.0.

The principles of componentization explored in iQIYI’s article on dynamic knowledge are introduced, so we won’t elaborate on them here.

In ApplicationInfo, fields related to split APKs are added.

/**
     * Full paths to zero or more split APKs that, when combined with the base
     * APK defined in {@link #sourceDir}, form a complete application.
     */
    public String[] splitSourceDirs;

    /**
     * Full path to the publicly available parts of {@link #splitSourceDirs},
     * including resources and manifest. This may be different from
     * {@link #splitSourceDirs} if an application is forward locked.
     */
    public String[] splitPublicSourceDirs;

In LoadedApk, there is a process for creating PathClassLoader and Resources. LoadedApk#mClassLoader is a reference to the PathClassLoader instance, and then we analyze the PathClassLoader creation process.

public ClassLoader getClassLoader() {
        synchronized (this) {
            if (mClassLoader != null) {
                return mClassLoader;
            }

            if (mIncludeCode && !mPackageName.equals("android")) {

                ......

                final ArrayList<String> zipPaths = new ArrayList<>();
                final ArrayList<String> libPaths = new ArrayList<>();

                .......

                zipPaths.add(mAppDir);
                // Add split apk paths to zipPaths
                if (mSplitAppDirs != null) {
                    Collections.addAll(zipPaths, mSplitAppDirs);
                }

                libPaths.add(mLibDir);

                .......

                final String zip = TextUtils.join(File.pathSeparator, zipPaths);
                final String lib = TextUtils.join(File.pathSeparator, libPaths);

                ......
                // If mSplitAppDirs is not empty, zip will include all split apps paths.
                mClassLoader = ApplicationLoaders.getDefault().getClassLoader(zip, lib,
                        mBaseClassLoader);

                StrictMode.setThreadPolicy(oldPolicy);
            } else {
                if (mBaseClassLoader == null) {
                    mClassLoader = ClassLoader.getSystemClassLoader();
                } else {
                    mClassLoader = mBaseClassLoader;
                }
            }
            return mClassLoader;
        }
    }

When creating the PathClassLoader, the dex file paths include both base app and split apps paths. LoadedApk#mResources is a reference to the Resources instance, and its creation process is as follows.

public Resources getResources(ActivityThread mainThread) {
        if (mResources == null) {
            mResources = mainThread.getTopLevelResources(mResDir, mSplitResDirs, mOverlayDirs,
                    mApplicationInfo.sharedLibraryFiles, Display.DEFAULT_DISPLAY, null, this);
        }
        return mResources;
    }

In this method, the split APK resource paths (LoadedApk#mSplitResDirs) will also be added to Resources.

The above briefly introduces the loading process of split APKs, including code and resources loading. Split APKs do not support dynamic loading of split APKs, meaning that the base APK and split APKs are all installed at the time of app installation. However, through the working principle of split APKs, we can see that they can support on-demand loading.

Introduction to Android App Bundles

To address the shortcomings of split APKs, Google introduced AAB at this year’s I/O conference. AAB provides dynamic installation APK functionality, further reducing APK size. Let’s first look at a diagram.

Unfortunately, AAB requires Google Play support, which means domestic developers are still out of luck.

As shown in the figure, AAB has an additional on-demand mode compared to split APKs. AAB also achieves on-demand loading based on split APKs, and the installation of split APKs requires Google Play.

• Base APK: When users download your app, the base APK is the first to be installed, and all split APKs can access the base APK code and resources.

• Configuration APKs: These APKs contain specific screen density, CPU architecture SO files, and languages. When downloading the base or feature APK, Google Play will download the specified configuration APKs based on the current device characteristics.

• Dynamic feature APKs: These APKs include code and resources, and they are not installed when the app is first installed but will be loaded when the user needs to use that feature.

For more information about AAB, you can read the official documentation. Download the latest Preview release of Android Studio and AAB Sample, and then let’s see how to work with AAB based on the official Samples.

AAB Function Introduction

AAB is not a plugin-based framework; it utilizes the split APK functionality provided by the Android Framework. All operations involving the installation of split APKs are handled through IPC by Google Play. (Third-party apps do not have the capability to install split APKs; only platform-signed applications or rooted devices can do so.)

Dynamic Feature Module

Android Studio has added a new module – Dynamic Feature Module.

When creating a dynamic feature, there are two options that are checked by default, but we can also change their status.

• Enable on-demand: Whether to support on-demand download mode. If not supported, the feature will be installed when the app is installed.

• Fusing: If the app runs on Android 5.0 (excluding 5.0) or lower, checking Fusing means that the feature will be packaged into the complete APK.

Next, we analyze the AAB example.

In the example, there are four features. The module names clearly indicate how to access code, resources, SOs, etc.

The plugin used for compiling the dynamic feature module is com.android.dynamic-feature. So what is unique about this plugin? By analyzing the compiled product, after running the example, we find that an APK file is generated in the build directory of all dynamic feature modules. The unique aspect of com.android.dynamic-feature is that the compilation target is an APK file.

Next, we decompile the main APK (produced by the com.android.application plugin) and discover:

• All dynamic feature module code, resources, and SOs are not packaged into the main APK.

• The manifest information of the main APK includes the manifest of all dynamic feature modules, meaning that feature manifests will be merged into the main APK manifest.

Build Bundle(s)

Android App Bundle provides a new compilation product format file aab.

As shown in the figure, when selecting Build Bundle(s), a bundle.aab file will be generated in the main project’s build directory. This file is a compressed format file, so let’s decompress it for analysis.

From the contents of the aab file, we can see that it includes the base and feature codes, resources, SOs, etc., as well as a configuration file BundleConfig.pb, which is used by Google Play to split APKs. If we need to support dynamic publishing on Google Play, we only need to upload the aab file, and the subsequent work is handled by Google Play.

Additionally, it is important to note that if the app runs on devices with version 4.4 or lower, the user will download a complete APK file, and split APK features are not supported.

The above image is a structure diagram of the aab file provided by the AAB documentation, where the blue box area is the configuration items supported by configuration APKs.

In the previous split APK packaging, language configuration was not supported.

The above briefly introduces the knowledge points related to AAB. If you are interested in learning more, please refer to the official documentation.

Play Core Library

The Play Core Library is the core library provided by AAB for downloading and installing dynamic feature modules. Additionally, we can use these APIs to download on-demand modules for instant apps.

For specific usage of the Play Core Library, please refer to the documentation. This article mainly discusses some theoretical knowledge points.

In the main project module app, let’s first analyze the MainActivity.kt file. This class is written in Kotlin, and if you haven’t encountered it before, don’t worry; you can still understand it generally.

In the onCreate method of MainActivity.kt, add the following logic:

override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        manager = SplitInstallManagerFactory.create(this)
        initializeViews()
        val installedList = manager.installedModules.toList()
        for (item in installedList) {
            toastAndLog("installed module : " + item.toString())
        }
        val splits = applicationInfo.splitSourceDirs
        for ( item in splits) {
            toastAndLog("split dir : " + item.toString())
        }
    }

Printing results are as follows:

D/DynamicFeatures: installed module : native
D/DynamicFeatures: installed module : java
D/DynamicFeatures: installed module : kotlin
D/DynamicFeatures: installed module : assets
D/DynamicFeatures: split dir : /data/app/com.google.android.samples.dynamicapps.ondemand-1/split_assets.apk
D/DynamicFeatures: split dir : /data/app/com.google.android.samples.dynamicapps.ondemand-1/split_java.apk
D/DynamicFeatures: split dir : /data/app/com.google.android.samples.dynamicapps.ondemand-1/split_kotlin.apk
D/DynamicFeatures: split dir : /data/app/com.google.android.samples.dynamicapps.ondemand-1/split_native.apk

From the running results, it can be seen that split APKs (even on-demand modules) are installed immediately after the base APK completes installation in debug mode.

The SplitInstallManager class provides a method to get the installed modules.

Set<String> getInstalledModules();

Since the Play Core Library’s non-public interfaces are obfuscated, we won’t analyze the source code directly. However, by tracing and analyzing the source code, we can see that the core process of obtaining installed modules is:

private final String[] a() {
        try {
            PackageInfo var1;
            return (var1 = this.d.getPackageManager().getPackageInfo(this.e, 0)) != null ? var1.splitNames : null;
        } catch (NameNotFoundException var2) {
            a.c("App is not found in PackageManager", new Object[0]);
            return null;
        }
    }

By accessing the PackageInfo#splitNames field.

In the example, whenever we need to launch a dynamic feature module, we must check if that module is installed. If it is not installed, we will start the download. The Play Core Library provides a comprehensive download status callback, including download progress, failure reasons, etc.

Through rough analysis of these obfuscated source codes, we can conclude that downloading and installing on-demand modules are both handled through IPC by Google Play.

Compatibility Issues

OS Version Not Higher Than 6.0

When the app runs on devices with a version not higher than 6.0, the SplitCompat library must be used to immediately access the downloaded module code and resources. AAB provides the SplitCompatApplication class to enable SplitCompat.

public class SplitCompatApplication extends Application {
    public SplitCompatApplication() {
    }

    protected void attachBaseContext(Context var1) {
        super.attachBaseContext(var1);
        SplitCompat.install(this);
    }
}

In Application#attachBaseContext(Context), SplitCompat.install(Context) is called. This method mainly completes the installation of split APKs code (dex and so) and resources.

Since the code is obfuscated, we can only roughly know what operations SplitCompat performs. In the method SplitCompat#a(boolean), the method com.google.android.play.core.splitcompat.b.b.a() is called, which handles compatibility for different OS versions.

public static a a() {
        if (VERSION.SDK_INT == 21) {
        //com.google.android.play.core.splitcompat.b.c
            return new c();
        } else if (VERSION.SDK_INT == 22) {
        //com.google.android.play.core.splitcompat.b.f
            return new f();
        } else if (VERSION.SDK_INT == 23) {
        //com.google.android.play.core.splitcompat.b.g
            return new g();
        } else {
            throw new AssertionError();
        }
    }

By examining com.google.android.play.core.splitcompat.b.c, com.google.android.play.core.splitcompat.b.f, com.google.android.play.core.splitcompat.b.g, we find that their main tasks are loading SOs and dex files (dex pre-insertion, similar to multi-dex). Resource loading for split APKs occurs in the method SplitCompat#a(boolean), which involves reflection calls to AssetManager#addAssetPath(String).

OS Version Not Lower Than 8.0

In Android 8.0, Instant Apps-related code is embedded in the Framework. Therefore, if the on-demand module is used in Instant Apps, SplitInstallHelper.updateAppInfo(Context) needs to be called upon successful download of the on-demand module.

public static void updateAppInfo(Context var0) {
        if (VERSION.SDK_INT > 25) {
            a.a("Calling dispatchPackageBroadcast!", new Object[0]);

            try {
                Class var1;
                Method var2;
                (var2 = (var1 = Class.forName("android.app.ActivityThread")).getMethod("currentActivityThread")).setAccessible(true);
                Object var3 = var2.invoke((Object)null);
                Field var4;
                (var4 = var1.getDeclaredField("mAppThread")).setAccessible(true);
                Object var5;
                (var5 = var4.get(var3)).getClass().getMethod("dispatchPackageBroadcast", Integer.TYPE, String[].class).invoke(var5, 3, new String[]{var0.getPackageName()});
                a.a("Calling dispatchPackageBroadcast", new Object[0]);
            } catch (Exception var6) {
                a.a(var6, "Update app info with dispatchPackageBroadcast failed!", new Object[0]);
            }
        }
    }

From the above code, we can see that it reflects the call to ActivityThread#dispatchPackageBroadcast. Ultimately, this calls LoadedApk#updateApplicationInfo, which does the following:

• Recreate mClassLoader

• Recreate mResources

• Update applicationInfo (completed by calling LoadedApk#setApplicationInfo).

Loading C/C++ Libraries

The Play Core library provides SplitInstallHelper#loadLibrary for loading C/C++ libraries. For specific usage, please refer to the example.

Conclusion

The emergence of Android App Bundles is equivalent to an official dynamic framework provided by Google, and all on-demand modules will also be reviewed by Google Play, which is very beneficial for users.

What do you want to say? Feel free to leave comments for discussion!

If you have good articles to share, please submit them directly by sending me the article link.

Finally, welcome everyone to join our Knowledge Planet.This session ends on March 10, 2019, so the earlier you join, the better. There are nearly 1000 members now, and the price will significantly increase when we reach 1000 members (there are only a few spots left), so hurry up!

Scan the QR code or click the QR code above to receive advanced resources for Android, Python, AI, Java, etc.

For more learning materials, click the “Read Original” below to obtain them.