Combine classpaths configs from multiple sources. Platform and apexes export configurations for *CLASSPATH variables via their etc/classpaths proto configs. At runtime the service parses the configs, combines them, and generates actual environ variables for init.rc to set. Generally, the order of the configs is: 1. ART module config; 2. System config; 3. Non-ART apex configs (apexes sorted by pathname); Individual jar ordering within a single config is not changed upon combinding the configs; i.e. each apex can define relative order of their jars. This provides deterministic ordering of the classpath jars at runtime to avoid unnessary re-optimization on mainline updates (or even worse on phone reboot). See go/updatable-classpath for more details. Bug: 180105615 Test: launch_cvd, presubmit, DeviceBootTest Change-Id: I911a76baa279720c605804a2dce8d22455125a14
SdkExtensions is a module that decides the extension SDK level of the device, and provides APIs for applications to query the extension SDK level.
The module is packaged in an apex, com.android.sdkext, and has two components:
bin/derive_sdk: Native binary that runs early in the device boot process and reads metadata of other modules, to set system properties relating to the extension SDK (for instance build.version.extensions.r).javalib/framework-sdkextension.jar: This is a jar on the bootclasspath that exposes APIs to applications to query the extension SDK level.derive_sdk is a program that reads metadata stored in other apex modules, in the form of binary protobuf files in subpath etc/sdkinfo.binarypb inside each apex. The structure of this protobuf can be seen here. The exact steps for converting a set of metadata files to actual extension versions is likely to change over time, and should not be depended upon.
The module exposes a java class SdkExtensions in the package android.os.ext. The method getExtensionVersion(int) can be used to read the version of a particular sdk extension, e.g. getExtensionVersion(Build.VERSION_CODES.R).
For every new Android SDK level a new extension version should be defined. These are the steps necessary to do that:
derive_sdk.cpp by:GetSdkLevel with the new enum setderive_sdk_test.cpp verifying the new extensions worksSdkExtensions.getExtensionVersion API support the new extensions.RollbackManagerServiceImpl#getExtensionVersions to account for the new extension version.