commit | 01ea57c593405963274c757bf24b1e95a8b4b6e7 | [log] [tgz] |
---|---|---|
author | Paul Duffin <paulduffin@google.com> | Mon Jan 17 16:39:00 2022 +0000 |
committer | Paul Duffin <paulduffin@google.com> | Mon Feb 07 14:12:17 2022 +0000 |
tree | 3f9f36001334c9ebd18facb33e8adf9fa6bc5546 | |
parent | 6ea0eb45c5d67806d70bb9d70a33d2cddbc4eea1 [diff] |
Support building build target specific snapshots This changes adds support for building target build release specific snapshots. It adds a BuildRelease class that defines the characteristics of the build release, e.g. name, how to create it, etc. It also adds a first_release field to MainlineModule which specifies the first BuildRelease for which a snapshot of the module is required and initializes that field for each module. After these changes this script will generate: 1. A legacy set of snapshots that match the file structure that was generated without this change. This is intended to allow existing consumers of the generated artifacts to continue to work while they are modified to make use of target build release specific snapshots. 2. The set of snapshots for the latest build release, i.e. the build release containing the source from which the snapshots are produced. This includes snapshots for all the modules. 3. For each build release from S onwards a set of snapshots for the modules it supports. It does not currently generate snapshots for Q and R releases as Soong cannot generate a compatible snapshot for them. If it is necessary to generate snapshots for those target build releases (similar to what the packages/modules/common/generate_ml_bundle.sh would produce) then a follow up change will add that capability to this script. Bug: 204763318 Test: atest mainline_modules_sdks_test packages/modules/common/build/mainline_modules_sdks.sh tree out/dist/mainline-sdks out/dist/stubs - check that it adds the for-latest-build directory but is otherwise identical to what was produced before this change. Change-Id: I48eb0b69cbe8664106b826ee0898557c98e039c2
This project includes mainline build and other utility code. Any library code intended for use by modules should go in frameworks/libs/modules-utils
instead.
This project uses a single source path for java code. All java code should go in the java
directory with subdirectories corresponding to the java package. Android.bp
files should go alongside the java source files, and should only include java source for a single java package to encourage good code hygiene.
Tests for java code should go in the javatests
directory and follow the same structure.