K
Kirill Rozov
Guest
Android is the most popular operating system in the world, powering devices from hundreds of manufacturers. Every year, Google releases a new version of Android, but only its own Pixel devices receive it immediately. Third-party vendors, such as Samsung, typically roll out the update to their flagship devices after about three months. A decade ago, this waiting period used to be as long as 9 to 12 monthsβββand many mid-range or budget devices never received updates at all.
This naturally raises a question: will Android ever reach the same point as Apple, where new versions are released simultaneously for all supported devices?
In this article, weβll explore how Google has gradually re-architected Android to shorten update delays, reduce dependency on device manufacturers, and eventually deliver new features directlyβββwithout waiting for a new OS version. This multi-year journey led to one of the most important initiatives in Androidβs history: Project Mainline.
When Android was first introduced, Google positioned itself as the developer of the OS, licensing its services to manufacturers rather than building its own hardware. Each vendor would take the base Android build from Google and heavily customize it:
While this strategy allowed Android to spread quickly, it created fragmentation. The market became flooded with devices running different OS versions, custom skins, and preinstalled apps.
For years, vendors controlled when and how their devices received new Android versions. The update process took anywhere from 6 to 18 months. In fact, a new Android version could already be released while a vendor was still working on adapting the previous one. And that was the best-case scenarioβββfor flagships. Cheaper devices often received updates much later or not at all.
Why was this so slow? There were three main reasons:
Android was designed as a large, tightly coupled system. Updating it meant that vendors had to:
This process was complex, error-prone, and expensive.
Most smartphone manufacturers make money primarily by selling devices and preinstalled apps. Google, meanwhile, earns from app sales, subscriptions, and services. That misalignment meant vendors had little incentive to quickly update older modelsβββthey preferred pushing users to buy newer, more expensive phones.
Without modularity, vendors had no way to ship incremental updates. Everything required a full firmware release, further delaying the process.
Google was not satisfied with this situation. Around 2017, they introduced Project Treble with Android 8. The idea was to separate the Android OS framework from the vendor implementation (like drivers and low-level components).
How Project Treble changed Android OS architecture
With Treble, device makers and chip vendors could update their parts independently, without touching the Android core. This greatly simplified OS adaptation, but it was only mandatory for devices shipping with Android 8 or later. As a result, adoption took years, and updates were still largely dependent on vendors.
To go further, Google needed a new architecture. With Project Mainline, introduced in Android 10, the OS was broken down into independent updatable modules.
Instead of relying on full firmware updates, Google could now deliver critical components directly to users through Google Play. At launch, there were 9 Mainline modules. As of Android 16, there are over 50 modules, covering core system functions.
This marked a turning point: for the first time, Google could bypass manufacturers and push updates independently.
Mainline modules come in two formats:
APEX file internal structure
Google even added Direct Boot and automatic reboot mechanisms so that APEX updates apply seamlessly, without major disruption for the user.
Updating system components is powerful, but what if developers need access to new APIs introduced in recent Android versions?
For this, Google created SDK Extensions, delivered as Mainline modules. These allow developers to use new APIs even on older OS versions.
For example, the Photo Picker API was originally introduced in Android 13. Thanks to SDK Extensions, the same feature is now available on Android 11 and 12.
Developers can enable this by specifying both compileSdk and compileSdkExtension in their build.gradle:
android {
compileSdk 36
compileSdkExtension 15
}
Instead of checking only the OS version, apps can now query the extension version with:
return SdkExtensions.getExtensionVersion(Build.VERSION_CODES.R) >= 2
This ensures compatibility across devices with different update levels.
Without SDK Extensions, a developer would need to check if the device was running Android 13 or later to use Photo Picker:
fun isPhotoPickerAvailable(): Boolean {
return Build.VERSION.SDK_INT >= 33
}
With SDK Extensions, the same feature becomes available on older Android releases, as long as the right extension is installed:
fun isPhotoPickerAvailable(): Boolean {
return SdkExtensions.getExtensionVersion(Build.VERSION_CODES.R) >= 2
}
This dramatically improves consistency for both developers and users.
Android API Reference. Info about extensions version in which API is available.
Android Lint check an Android Studio
Project Mainline has transformed how Android is updated. By modularizing the OS and introducing APEX modules and SDK Extensions, Google gained the ability to push new features and security updates directlyβββwithout waiting for vendors.
This shift enabled Androidβs new quarterly release model, starting with Android 16. Instead of one big annual release, Google can now ship updates more frequently: new platform versions in the summer, followed by modular updates through Google Play.
In other words, Android is finally catching up to Appleβs modelβββensuring users get updates faster, devices stay secure longer, and developers can rely on a more consistent platform.
Project Mainline: How Google Reshaped Android Updates was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.
Continue reading...
This naturally raises a question: will Android ever reach the same point as Apple, where new versions are released simultaneously for all supported devices?
In this article, weβll explore how Google has gradually re-architected Android to shorten update delays, reduce dependency on device manufacturers, and eventually deliver new features directlyβββwithout waiting for a new OS version. This multi-year journey led to one of the most important initiatives in Androidβs history: Project Mainline.
The Fragmentation Problem
When Android was first introduced, Google positioned itself as the developer of the OS, licensing its services to manufacturers rather than building its own hardware. Each vendor would take the base Android build from Google and heavily customize it:
- Replacing default apps with their own,
- Changing the visual design,
- Adding proprietary features,
- And often even modifying core Android mechanisms.
While this strategy allowed Android to spread quickly, it created fragmentation. The market became flooded with devices running different OS versions, custom skins, and preinstalled apps.
Why Updates Took So Long
For years, vendors controlled when and how their devices received new Android versions. The update process took anywhere from 6 to 18 months. In fact, a new Android version could already be released while a vendor was still working on adapting the previous one. And that was the best-case scenarioβββfor flagships. Cheaper devices often received updates much later or not at all.
Why was this so slow? There were three main reasons:
1. Monolithic Architecture
Android was designed as a large, tightly coupled system. Updating it meant that vendors had to:
- Wait for Google to release a stable OS version.
- Merge it with their own modifications.
- Adapt vendor-specific features to the new OS.
- Test and distribute the new firmware.
This process was complex, error-prone, and expensive.
2. Economics of Hardware Sales
Most smartphone manufacturers make money primarily by selling devices and preinstalled apps. Google, meanwhile, earns from app sales, subscriptions, and services. That misalignment meant vendors had little incentive to quickly update older modelsβββthey preferred pushing users to buy newer, more expensive phones.
3. Lack of Modularity
Without modularity, vendors had no way to ship incremental updates. Everything required a full firmware release, further delaying the process.
Googleβs First Response: Project Treble
Google was not satisfied with this situation. Around 2017, they introduced Project Treble with Android 8. The idea was to separate the Android OS framework from the vendor implementation (like drivers and low-level components).
How Project Treble changed Android OS architecture
With Treble, device makers and chip vendors could update their parts independently, without touching the Android core. This greatly simplified OS adaptation, but it was only mandatory for devices shipping with Android 8 or later. As a result, adoption took years, and updates were still largely dependent on vendors.
Project Mainline: Breaking Android Into Modules
To go further, Google needed a new architecture. With Project Mainline, introduced in Android 10, the OS was broken down into independent updatable modules.
Instead of relying on full firmware updates, Google could now deliver critical components directly to users through Google Play. At launch, there were 9 Mainline modules. As of Android 16, there are over 50 modules, covering core system functions.
This marked a turning point: for the first time, Google could bypass manufacturers and push updates independently.
How Modules Are Delivered: APK vs APEX
Mainline modules come in two formats:
- APK modulesβββwork just like regular app updates. They are installed during runtime and donβt require a reboot.
- APEX modules (Android Pony EXpress)βββspecial containers for low-level components that cannot be updated while the system is running. These require a reboot (e.g., updates to the ART runtime).
APEX file internal structure
Google even added Direct Boot and automatic reboot mechanisms so that APEX updates apply seamlessly, without major disruption for the user.
SDK Extensions: Bringing New APIs to Older Versions
Updating system components is powerful, but what if developers need access to new APIs introduced in recent Android versions?
For this, Google created SDK Extensions, delivered as Mainline modules. These allow developers to use new APIs even on older OS versions.
For example, the Photo Picker API was originally introduced in Android 13. Thanks to SDK Extensions, the same feature is now available on Android 11 and 12.
Developers can enable this by specifying both compileSdk and compileSdkExtension in their build.gradle:
android {
compileSdk 36
compileSdkExtension 15
}
Instead of checking only the OS version, apps can now query the extension version with:
return SdkExtensions.getExtensionVersion(Build.VERSION_CODES.R) >= 2
This ensures compatibility across devices with different update levels.
Practical Example: Photo Picker Across Versions
Without SDK Extensions, a developer would need to check if the device was running Android 13 or later to use Photo Picker:
fun isPhotoPickerAvailable(): Boolean {
return Build.VERSION.SDK_INT >= 33
}
With SDK Extensions, the same feature becomes available on older Android releases, as long as the right extension is installed:
fun isPhotoPickerAvailable(): Boolean {
return SdkExtensions.getExtensionVersion(Build.VERSION_CODES.R) >= 2
}
This dramatically improves consistency for both developers and users.
Android API Reference. Info about extensions version in which API is available.
Android Lint check an Android Studio
Project Mainline has transformed how Android is updated. By modularizing the OS and introducing APEX modules and SDK Extensions, Google gained the ability to push new features and security updates directlyβββwithout waiting for vendors.
This shift enabled Androidβs new quarterly release model, starting with Android 16. Instead of one big annual release, Google can now ship updates more frequently: new platform versions in the summer, followed by modular updates through Google Play.
In other words, Android is finally catching up to Appleβs modelβββensuring users get updates faster, devices stay secure longer, and developers can rely on a more consistent platform.
Project Mainline: How Google Reshaped Android Updates was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.
Continue reading...
