For mobile app services to grow, it's important to increase the number of new downloads and that of new app installations from the users.
According to one report from Google, the size of the app package plays a very significant role in app downloads, and therefore we have been working hard to reduce its size. Nevertheless, the recent 64-bit support policy in Google Play has been a hot topic for the increased package size.
We will discuss ANDROID APP BUNDLE (AAB) to address app package size growth, and we'll also introduce you how to easily test your app when you transition to AAB.
According to Google, as the capacity of app packages had been growing by five times from March 2012 to January 2018, app packages are playing a critical role in downloading apps.
They also mentioned that every 6MB increase in app package size results in a significant loss of transition rates.
In traditional Android systems, a device could operate normally in not only 32-bit mode but also in 64-bit, if 32-bit native library was fulfilled. Moreover, it was possible to operate normally on x86 devices without the addition of the native library through the Houdini system. However, with this 64-bit support policy, the capacity of the app package is inevitably growing as the native library for 64-bit needs to be built and added to the package.
In particular, IL2CPP mode should be used to support 64bit for apps using UNITY, and if the app is packaged for both 32-bit and 64-bit, it will be immediately noticeable of the increased size of the app package. AAB is suggested as one of the solutions to address the issue of increased capacity of these app packages.
AAB is a feature that is similar to app thinning in IOS and is proposed by Google for efficient app service operation by reducing the capacity of the package. Here's a summary of the benefits of AAB from Google:
[ ANDROID APP BUNDLE ]
- Reduces download size and disk allocation size when users are downloading apps.
- Reduce download size, disk allocation size, and installation time using a default uncompressed library (higher than Android 6.0) stored in APK instead of the user’s device .
- Features and settings are provided when requested by users instead of when the app is on its installation process.
- Enables efficient building and launching management as it does not require building and publishing APKs.
So if you take a look at the part of what AAB can benefit us regarding the capacity of the package, it's actually reducing the download by creating and deploying the APK and resources that are configured for each user. Android Studio and UNITY help users to easily convert their existing app packages to AAB through simply changing few setups. The information below shows the structure when the existing app package switched to AAB.
[Dependency tree for an app served using split APKs]
AAB TEST
This converted AAB requires a QA for compatibility validation before it is updated to the actual service. The widely used AAB test method is generally proceeded in one of two ways below:
- Register for GOOGLE PLAY BETA TEST
- Direct installation to devices connected to the development environment
AAB INSTALL
- AAB -> APKs -> INSTALL
APKs Mode
- APKs ( dynamic feature modules )
- APKs ( universal module )
APKs (dynamic feature modules) are most similar to how apps are distributed through GOOGLE PLAY when apps are serviced with ABB, and contain a number of split apk for each device in the APKs package. APKs (universal module) consists of a single apk which is a mode that can be installed on every devices through one apk. These modes have the same configurations as existing APKs that do not have the advantage of AAB, which can also be used for purposes other than distribution through GOOGLE PLAY. The command for mode conversion are as follows.
APKs ( dynamic feature modules )
java -jar "bundletool-all-0.10.0.jar" build-apks --bundle="your.aab" --output="dynamic.apks"
APKs ( universal module )
java -jar "bundletool-all-0.10.0.jar" build-apks --mode=universal --bundle="your.aab" --output="universal.apks"
In addition, if you wish to extract and install only APKs(dynamic feature modules) that fit to the devices it is connected to, '--connected-device' can be utilized to save time and resources. Installation to the devices can be proceeded with the extracted APKs as follows:
[ APKs ( dynamic feature modules ) '--connected-device']
java -jar "bundletool-all-0.10.0.jar" build-apks --connected-device --bundle="your.aab" --output="dynamic.apks"
[ bundletool install ]
java -jar "bundletool-all-0.10.0.jar" install-apks --apks="dynamic.apks"
How to Protect AAB safely? Experience LIAPP to make AAB secure
We have now learned how to convert AAB to APKs and INSTALL it. If the app package changes by applying app security services such as LIAPP to the built AAB, you can use jarsigner to perform app signing passively. If the app package changes by applying app security services such as LIAPP to the built AAB, you can use jarsigner to perform app signing passively.
[ AAB SIGNING ]
jarsigner -verbose -sigalg SHA256withRSA -digestalg SHA-256 -keystore [Keystore file Path] [Path of the app that’s to be signed] [alias_name that has been made when the key was produced]
ex. jarsigner -verbose -sigalg SHA256withRSA -digestalg SHA-256 -keystore /your.keystore /your.aab LOCKINCOMPANY
We've covered the structure and advantages of AAB and the TEST method. The examples shown on this post are the most common and easy-to-use command line, and it would be helpful to see more features available through additional options.
Any questions or comments, please feel free to leave them in the comment section :)
Top comments (0)