Almost no one who has played Glory of Kings knows the hero "Luban No. 7".
As an Android application package, "APK" is no less famous than the former for experienced Android users.
Because of this, a statement made by Google a few days ago touched the nerves of many Android users.
Google announced that starting in August 2021, the Google Play Store will require developers to use the Android App Bundle (AAB) to release new applications. This will replace APK as the standard publishing format.
▲ Picture from: hitechglitz
As soon as the news came out, some users began to speculate and even worried: "Can I still borrow an APK to talk in the future?" "Is Google deliberately embarrassing domestic brands"?
In fact, friends who have these questions have a high probability of misunderstanding Google's actions.
What is AAB?
The center of this whirlpool of public opinion is the AAB format. So first we have to figure out what AAB is.
At the Google Developers Conference held in May 2018, Google announced the Android App Bundle (AAB) format and said it was part of its modern development.
Google introduced that developers need to use the AAB format when uploading applications to Google Play. Google Play will be responsible for the APK file generation and signature.
There are two important points in this sentence.
One is that AAB is only the format applied when uploading. When users download, they still get the APK.
▲ Picture from: techlog360
For developers, there is no pain point to switch from APK to AAB. AAB is an open source format. When building, just select the relevant tool or engine.
In addition, according to Google’s statement, there is no need to re-upload the AAB file for existing applications. Only starting in August this year, AAB is required when submitting new applications.
Users do not have to worry about it, because what we see on the terminal device is still in APK format.
▲ Picture from: 9to5google
The second is to generate APK, which will be completed by Google Play.
Google Play will extract and assemble code and resources suitable for the user's device from the AAB "source file" according to the configuration of the user's device, thereby generating an APK installation package.
In other words, the application downloaded by the user at this time has been optimized by Google Play to ensure that the application can run in the best state on the current device.
▲Picture from: beebom
To put it another way, it’s easy for you to understand: AAB is like a bag of instant noodles with various flavors. Google Play is the chef. It will determine how long to cook the noodles and what seasoning package to put according to your device preferences.
The final cooked noodle is the APK.
Three advantages of AAB
The main reason why Google wants to "toughly" implement the AAB format is that AAB has many inherent advantages over APK.
The first point is its lightness.
As mentioned above, Google Play will personally generate and optimize APKs from AAB to distribute them to devices and languages of different configurations.
For example: suppose your mobile phone has a 2K screen and the preferred language is Chinese. Then when Google Play assembles the APK, it will only put the resources of 2K resolution and Chinese character packs into the APK.
In the traditional APK, developers will package various resolutions and language packs together. After the user downloads it, the mobile phone needs to select the resources suitable for him to install and run.
With the continuous increase of models, developers need to stuff more and more resources into APK files to improve adaptability. Therefore, apps are getting bigger and bigger, often hundreds of MB.
▲ Picture from: altavia
Then the application of AAB is equivalent to "Leave the complexity to Google Play, and leave the simplicity to the user." The APK downloaded by the user is streamlined by Google, so the size will be smaller.
How much is it smaller? According to Google, this can reduce the size of the APK by 15%.
However, the actual situation may be better than this expectation. For example, Airbnb reduced its volume by 22% after embracing AAB. Netflix is even worse, reaching 57%.
▲ Case of using AAB feature to reduce volume
Therefore, for users, the perceptible point is that the installation package becomes smaller, and the download and installation speed will be faster.
Secondly, AAB enables users to download applications that conform to the device configuration to the greatest extent, so they may run more smoothly. To a certain extent, it can be regarded as improving the performance of the equipment.
▲ Picture from: angelseoservices
The second point is application modularity.
AAB allows developers to separate the functions of the application. Let users in need download it by themselves.
Let's continue with examples. Suppose the developer wants to make a camera app now, my phone is a single camera, and your phone is a dual camera. In order to reduce the initial size of the application, developers can set certain functions to be downloaded on demand.
For example, if you want to use the functions launched for dual-camera phones in this app, you just need to download additional information packages.
▲Picture from: unsplash
Developers can also decide when and to which models to push new features of the application. It is equivalent to customizing and controlling the experience of all kinds of users.
"You and I use the same app but enjoy different functions" may become the norm in the future.
▲Picture from: unsplash
The third point is the free download experience.
AAB's installation-free distribution feature allows users to experience certain functions of the application in Google Play without downloading the application.
For example, there is a game, we are not sure whether it is worth downloading, we can click "Experience Now" to try the first few levels without downloading the app.
This is a bit like the new App Clip feature of iOS 14, which can be seen as a shortcut to the full version of the application, which will contain part of the application's functions.
▲ App Clip function of iOS 14
So for users, we can perceive the promotion of the AAB format, and there will be a better experience.
It's definitely not enough to play the user experience card. You have to consider the developer's feelings. In order to give them motivation to switch to the AAB format, Google gave several reasons:
- Version management is more efficient, and one artifact can contain all the compiled code, resources, and native libraries of the application.
- Modular application development function can improve engineering speed.
- The optimization of the compilation system can shorten the compilation time.
- Custom function delivery, you can control the user experience.
It doesn't matter if you are not interested, then come "hard": starting from August, the application package will not be changed to AAB format, and upload is not allowed, forcing developers to change.
This is enough to show the importance of AAB for the future planning of Google Play.
How does this affect Android users?
Promoting the AAB format is definitely a good thing for mass users. Who doesn't want the apps they download to be small and well adapted?
However, Google only requires Google Play to do so, and does not force other app stores to follow up.
In other words, if you are not using Google Play, then this change is temporarily imperceptible.
▲Picture from: unsplash
But with so many advantages of the AAB format, we have reason to believe that domestic app stores will gradually keep up with Google and embrace AAB.
And as we mentioned above, the installation package downloaded by the user will still be presented in APK format. Therefore, the rumors that "Google's move is to target domestic manufacturers" are self-defeating.
What's more, application stores such as Huawei have supported developers to upload applications in AAB format since the first two years. So users can relax and wait for the bonus of the AAB format promotion.
#Welcome to follow Aifaner's official WeChat account: Aifaner (WeChat ID: ifanr), more exciting content will be provided to you as soon as possible.