Introduced with Android 10, Modular System Components enable updating end-user devices outside of the normal Android release cycles. The new Extension SDK framework, now public, aims to make their integration simpler for developers.
Android 10 or higher converts selected system components into modules, some of which use the APEX container format (introduced in Android 10) and some of which use the APK format. The modular architecture enables system components to be updated with critical bug fixes and other improvements as needed.
One major examples of how Google plans to leverage API componentization is the rolling out of the new Privacy Sandbox beta to Android 13 devices, without needing to wait for the next Android release. In addition, modular components also aim to sort of backporting existing features to devices running older Android versions. This is exemplified by the PhotoPicker API, introduced in Android 13, that is available for Android 11 and 12, too, thanks to Modular System Components.
Using the new SDK Extension framework, developers can easily check whether a given feature is available on a device and conditionally enable its use in their apps. For example, the official documentation for the above mentioned PhotoPicker API states that it is available starting with Android 13 as well as on devices running Android R (11) extension 2. With this information, a developer planning to take advantage of the new PhotoPicker API in their app would first check whether the SDK extension version is at least the minimum required for that API, i.e.:
fun isPhotoPickerAvailable(): Boolean {
return SdkExtensions.getExtensionVersion(VERSION_CODES.R) >= 2
}
Previous to SDK Extensions, developers could check the value of Build.VERSION.SDK_INT, e.g. Build.VERSION.SDK_INT >= 33, to ensure a minimum SDK level was available. While still correct and supported, this check would fail for devices running an SDK level less than 33 while having R extension version >= 2.
The SDK Extensions API will be further integrated with Jetpack Compose to make its use more idiomatic, Google says.
Modular System Components are similar to Google Play Services in their intent to make Android devices easier to update without requiring a new OS release. The key difference between the two solutions lies with Modular System Components being part of AOSP, the Android Open Source Platform, while Play Services are a proprietary solution only available to Google and licensing partners. Being part of AOSP means that modularized system components can also be delivered through a third-party over-the-air infrastructure in addition to Google Play, which will be the default for Google and licensing partners.
