Google launched Mission Mainline in Android 10, modularizing OS parts so function and safety updates might be delivered by means of Google Play as a substitute of normal OTA updates. Android 10 launched with 12 supported Mainline modules, however within the newest launch, that quantity has ballooned to 37 updatable modules. Right here’s a have a look at how Mission Mainline is altering in Android 14 and past.
To begin with, why do you have to care about Mission Mainline updates? Properly, Google printed a weblog publish this week revealing that the corporate was capable of ship key updates to ART (the Android Runtime) by means of Google Play because of Mission Mainline. These updates not solely delivered new core Java language options for builders and significant safety fixes, however additionally they yielded app start-up enhancements of what Google claims is as much as 30% on some units. Since ART turned a Mission Mainline module in Android 12, which means tens of millions of units received these enhancements straight from Google.
Because of latest ART updates delivered by means of Google Play, some Android units are seeing an as much as 30% enchancment in app start-up instances.
Mainline can be answerable for delivering a number of new options to older units. Android 13’s Photograph Picker, for instance, was backported to Android 11–12L because of a Mainline replace.
That being stated, I’m certain you’re questioning whether or not there are any new Mission Mainline modules in Android 14 you need to care about. Android 14 technically solely introduces 4 new Mission Mainline modules, in case your definition of a Mission Mainline module is an APK or APEX file that’s updatable by means of Google Play System Updates. That’s a step down from the 11 new modules added in Android 11, however to be truthful, it’s anticipated for this quantity to go down as extra parts get added to the Mainline pile.
In any case, listed below are the 4 new Mainline modules:
- ConfigInfrastructure: Config Infrastructure supplies an updatable DeviceConfig implementation. DeviceConfig is the API utilized by Google Play Providers to remotely toggle flags that management varied Android system options. For instance, earlier than Android 14 Beta 4, the provision of the cut up notification & ringtone quantity sliders was managed by a DeviceConfig flag.
- HealthFitness: This incorporates the Well being Join app and associated APIs. Since Well being Join is now baked into the OS, you gained’t have to obtain the app from Google Play anymore, plus it’ll work on units with out GMS. For customers who’ve already downloaded the Well being Join app from Google Play, Google has begun migrating customers over to the system model. HealthFitness additionally incorporates the backup and restore app, which can ultimately allow cloud-based backups of Well being Join knowledge.
- Distant Key Provisioner: This incorporates the Distant Key Provisioning app and system service.
- Time Zone Knowledge (v5): Okay, this isn’t actually a brand new module. Each model of Android has its personal OS-specific Time Zone Knowledge module. Android 14 is the fifth launch that helps Mainline, so we’re now at model 5 of TZ knowledge.
The record of Mission Mainline modules could be present in an XML file known as “module_metadata.xml”. This XML file is contained throughout the ModuleMetadata app, which can be answerable for offering the Google Play System Replace model that you simply see in Settings.
Android 14 really provides two further APEX modules. APEX is one in all two file codecs supported by Mission Mainline (the opposite being APK), however not all APEX modules are Mission Mainline modules, and vice versa. Since these APEX modules aren’t up to date by means of Google Play System Updates, I left them out of the earlier record. Nonetheless, I believe they’re value citing:
- System Lock Controller: System Lock Controller incorporates the Mainline model of the Google app by the identical title. The app in query is utilized by collectors to handle/lock down financed telephones.
- Virt(ualization): This module incorporates the Android Virtualization Framework (AVF). AVF was really launched in Android 13, nevertheless it was an elective construct on the time. In Android 14, nevertheless, the Virtualization module is now included by default when constructing AOSP. Nevertheless, units nonetheless have to particularly assist AVF. At present solely Tensor-based Pixels assist this function, although future Qualcomm and MediaTek-based flagship units could assist AVF.
A comparability between the /system/apex directories in Android 13 QPR3 (left) and Android 14 Beta 5 (proper). The /system/apex listing incorporates all APEX modules which can be constructed by default when compiling AOSP.
The modifications I’m about to record are technically to modules that exist already, however I believe they’re value citing anyway:
- Bluetooth is now updatable: Android 13 launched an APEX module containing Android’s Bluetooth stack, however the APEX wasn’t marked as updatable at launch. Now, nevertheless, the module is ready to be up to date by means of Google Play System Updates. The Bluetooth module continues to be elective for OEMs to make use of, nevertheless.
- Cronet in Connectivity: Cronet is the Chromium community stack made accessible to Android apps as a library. This has been added underneath the present Connectivity module.
- Wi-Fi is obligatory: I’ve heard that the Wi-Fi module is not elective for OEMs in Android 14.
Mission Mainline in Android 15: What to anticipate
Lastly, right here’s a sneak peek at a few of the new APEX/Mission Mainline modules we might even see in subsequent 12 months’s Android 15 “Vanilla Ice Cream” launch:
- CrashRecovery: I don’t know what it will do. There’s an empty repository in AOSP for it, however that’s all that’s public to this point.
- NFC: As I beforehand reported, Google is engaged on turning Android’s NFC stack right into a modular system element. There’s no code for this in AOSP repositories but, however a commit description from a Googler suggests it’ll occur.
- RemoteAuth(entication): It’s not completely clear what RemoteAuth is for, however based mostly on my preliminary studying of the code that’s public, it looks as if it’ll allow you to use a UWB-enabled smartwatch as a “distant authenticator.” Maybe it will allow you to use your smartwatch to unlock apps in your cellphone sooner or later.
- ThreadNetwork (a part of Connectivity): Google is actively engaged on a Thread community stack for Android that’s decoupled from Google Play Providers. Thread, for those who aren’t conscious, is a wi-fi protocol designed for Matter-enabled units.
- UWB vendor HAL will develop into updatable: Android 13 launched an (elective) UWB Mainline module, although solely the system-side HAL was updatable. In Android 15, nevertheless, the vendor-side HAL will develop into updatable.
That’s my high-level abstract of what’s new in Mission Mainline in Android 14 and what to anticipate in Android 15. There are, in fact, extra technical, under-the-hood modifications that I haven’t introduced up, in addition to probably issues I missed. As soon as Google updates the Mission Mainline documentation following the launch of Android 14, we’ll know extra about what else the corporate added within the upcoming launch.