Google Git
Sign in
android / platform / packages / modules / SdkExtensions / 0a8b759
commit0a8b75953b90508d81907d909a895cf6c915a818[log] [tgz]
authorsatayev <satayev@google.com>Wed May 12 13:30:40 2021 +0100
committerArtur Satayev <satayev@google.com>Thu May 13 12:16:20 2021 +0000
tree8034eaec51365f4bf19a0658ed79a2dfb46998fd
parent00e15387a8a1b54e8a832b7f949dcd709675f9a4 [diff]
Add bootclasspath_fragment.

Note that the contents of the bootclasspath_fragment are added as
dependencies to an apex, so there is no need to duplicate them in
java_libs.

Contents of the bootclasspath_fragment are jars that are listed
in PRODUCT_UPDATABLE_BOOT_JARS in make. The module modularizes
the treatment of said jars at build time (e.g. follow up changes
could add hidden api bits to this module if needed).

This module is also responsible for generating classpaths.proto
config for the apex which feeds the information about boot jars
it contributes to BOOTCLASSPATH at runtime.

Bug: 180105615
Test: atest CtsClasspathsTestCases
Ignore-AOSP-First: manual cp to avoid merging into mainline-prod
Change-Id: Idba141b6dba3c79768c63a0f16b7c584f8d71a9a
1 file changed
tree: 8034eaec51365f4bf19a0658ed79a2dfb46998fd
  1. derive_classpath/
  2. derive_sdk/
  3. framework/
  4. gen_sdk/
  5. testing/
  6. tests/
  7. Android.bp
  8. com.android.sdkext.avbpubkey
  9. com.android.sdkext.pem
  10. com.android.sdkext.pk8
  11. com.android.sdkext.x509.pem
  12. manifest.json
  13. OWNERS
  14. PREUPLOAD.cfg
  15. README.md
  16. TEST_MAPPING
README.md

SdkExtensions module

SdkExtensions module is responsible for:

  • deciding the extension SDK level of the device;
  • providing APIs for applications to query the extension SDK level;
  • determining the values for the BOOTCLASSPATH, DEX2OATBOOTCLASSPATH, and SYSTEMSERVERCLASSPATH environment variables.

General information

Structure

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.

Deriving 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.

Reading extension SDK level

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).

Deriving classpaths

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.

Developer information

Adding a new extension version

For every new Android SDK level a new extension version should be defined. These are the steps necessary to do that:

  • Add the new modules in this extension version to the SdkModule enum in sdk.proto.
  • Update derive_sdk.cpp by:
  • mapping the modules' package names to the new enum values
  • creating a new set with the new enum values
  • set a new sysprop to the value of GetSdkLevel with the new enum set
  • add a unit test to derive_sdk_test.cpp verifying the new extensions works
  • Make the SdkExtensions.getExtensionVersion API support the new extensions.
  • Extend the CTS test to verify the above two behaviors.
  • Update RollbackManagerServiceImpl#getExtensionVersions to account for the new extension version.