commit | d7937d1bf032b7f3a598e67bf78d03064bd06c38 | [log] [tgz] |
---|---|---|
author | Alex Light <allight@google.com> | Mon Apr 26 16:49:57 2021 -0700 |
committer | Alex Light <allight@google.com> | Tue Apr 27 14:29:15 2021 -0700 |
tree | 6b0b83417b3a84b41f1bb9cdcbc992d5d2841cc0 | |
parent | 2230c126158b387e8c3363328750fdba5ac4a4bc [diff] |
Support custom output locations for derive_classpath derive_classpath needs to be run during OTA to tell dexopt what the new bootclasspath is. To avoid poluting the /data partition this adds support for specifying a custom location to write the bootclasspath environment variables to. This is all run in a chroot which has the post-ota /system, /vendor, /system_ext, /apex, etc partitions all mounted. The otapreopt system uses these and the /data partition to compile everything using the new bootclasspath. Since this chroot doesn't have an installd, system_server or anything else otapreopt and otapreopt_chroot are responsible for setting up enough of the system to run dex2oat and need to do it in a way that doesn't impact the running system. For derive_classpath it does that by having the new classpaths be written into a tempfile it passes. Test: manual OTA on blueline Bug: 186432034 Change-Id: Ia310b5d4558f708e74f86ae56a4b33d80366534f
SdkExtensions module is responsible for:
The module is packaged in an apex, com.android.sdkext
, and has several components:
bin/derive_classpath
: a native binary that runs early in the device boot process. It reads individual classpath configs files from the system and other modules, merges them, and defines the definition of *CLASSPATH environ variables.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)
.
derive_classpath
service reads and merges individual config files in the /system/etc/classpaths/
and /apex/*/etc/classpaths
. Each config stores protobuf message from classpaths.proto
in a proto binary format. Exact merging algorithm that determines the order of the classpath entries is described in derive_classpath.cpp
and may change over time.
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.