Google introduced Project Mainline in Android 10, modularizing OS components so feature and security updates could be delivered through Google Play instead of regular OTA updates. Android 10 launched with 12 supported Mainline modules, but in the latest release, that number has ballooned to 37 updatable modules. Here’s a look at how Project Mainline is changing in Android 14 and beyond.

First of all, why should you care about Project Mainline updates? Well, Google published a blog post this week revealing that the company was able to deliver key updates to ART (the Android Runtime) through Google Play thanks to Project Mainline. These updates not only delivered new core Java language features for developers and critical security fixes, but they also yielded app start-up improvements of what Google claims is up to 30% on some devices. Since ART became a Project Mainline module in Android 12, that means millions of devices got these improvements straight from Google.

Thanks to recent ART updates delivered through Google Play, some Android devices are seeing an up to 30% improvement in app start-up times.

Mainline is also responsible for delivering several new features to older devices. Android 13’s Photo Picker, for example, was backported to Android 11–12L thanks to a Mainline update.

That being said, I’m sure you’re wondering whether there are any new Project Mainline modules in Android 14 you should care about. Android 14 technically only introduces four new Project Mainline modules, if your definition of a Project Mainline module is an APK or APEX file that’s updatable through Google Play System Updates. That’s a step down from the 11 new modules added in Android 11, but to be fair, it’s expected for this number to go down as more components get added to the Mainline pile.

In any case, here are the four new Mainline modules:

• ConfigInfrastructure: Config Infrastructure provides an updatable DeviceConfig implementation. DeviceConfig is the API used by Google Play Services to remotely toggle flags that control various Android system features. For example, before Android 14 Beta 4, the availability of the split notification & ringtone volume sliders was controlled by a DeviceConfig flag.
• HealthFitness: This contains the Health Connect app and related APIs. Since Health Connect is now baked into the OS, you won’t need to download the app from Google Play anymore, plus it’ll work on devices without GMS. For users who have already downloaded the Health Connect app from Google Play, Google has begun migrating users over to the system version. HealthFitness also contains the backup and restore app, which may eventually enable cloud-based backups of Health Connect data.

• Remote Key Provisioner: This contains the Remote Key Provisioning app and system service.
• Time Zone Data (v5): Okay, this is not really a new module. Every version of Android has its own OS-specific Time Zone Data module. Android 14 is the fifth release that supports Mainline, so we’re now at version 5 of TZ data.

The list of Project Mainline modules can be found in an XML file called “module_metadata.xml”. This XML file is contained within the ModuleMetadata app, which is also responsible for providing the Google Play System Update version that you see in Settings.

Android 14 actually adds two additional APEX modules. APEX is one of two file formats supported by Project Mainline (the other being APK), but not all APEX modules are Project Mainline modules, and vice versa. Since these APEX modules aren’t updated through Google Play System Updates, I left them out of the previous list. Still, I think they’re worth bringing up:

• Device Lock Controller: Device Lock Controller contains the Mainline version of the Google app by the same name. The app in question is used by creditors to manage/lock down financed phones.
• Virt(ualization): This module contains the Android Virtualization Framework (AVF). AVF was actually introduced in Android 13, but it was an optional build at the time. In Android 14, however, the Virtualization module is now included by default when building AOSP. However, devices still need to specifically support AVF. Currently only Tensor-based Pixels support this feature, though future Qualcomm and MediaTek-based flagship devices may support AVF.

A comparison between the /system/apex directories in Android 13 QPR3 (left) and Android 14 Beta 5 (right). The /system/apex directory contains all APEX modules that are built by default when compiling AOSP.

The changes I’m about to list are technically to modules that already exist, but I think they’re worth bringing up anyway:

• Bluetooth is now updatable: Android 13 introduced an APEX module containing Android’s Bluetooth stack, but the APEX wasn’t marked as updatable at launch. Now, however, the module is able to be updated through Google Play System Updates. The Bluetooth module is still optional for OEMs to use, however.
• Cronet in Connectivity: Cronet is the Chromium network stack made available to Android apps as a library. This has been added under the existing Connectivity module.
• Wi-Fi is mandatory: I’ve heard that the Wi-Fi module is no longer optional for OEMs in Android 14.

Project Mainline in Android 15: What to expect

Finally, here’s a sneak peek at some of the new APEX/Project Mainline modules we may see in next year’s Android 15 “Vanilla Ice Cream” release:

• CrashRecovery: I have no idea what this will do. There’s an empty repository in AOSP for it, but that’s all that’s public so far.
• NFC: As I previously reported, Google is working on turning Android’s NFC stack into a modular system component. There’s no code for this in AOSP repositories yet, but a commit description from a Googler suggests it’ll happen.
• RemoteAuth(entication): It’s not entirely clear what RemoteAuth is for, but based on my initial reading of the code that’s public, it seems like it’ll let you use a UWB-enabled smartwatch as a “remote authenticator.” Perhaps this will let you use your smartwatch to unlock apps on your phone in the future.
• ThreadNetwork (part of Connectivity): Google is actively working on a Thread network stack for Android that’s decoupled from Google Play Services. Thread, if you aren’t aware, is a wireless protocol designed for Matter-enabled devices.
• UWB vendor HAL will become updatable: Android 13 introduced an (optional) UWB Mainline module, though only the system-side HAL was updatable. In Android 15, however, the vendor-side HAL will become updatable.

That’s my high-level summary of what’s new in Project Mainline in Android 14 and what to expect in Android 15. There are, of course, more technical, under-the-hood changes that I haven’t brought up, as well as potentially things I missed. Once Google updates the Project Mainline documentation following the launch of Android 14, we’ll know more about what else the company added in the upcoming release.