Make sure we select the proper API level number for the REL
platform version when generating the classpath protos
Bug: 231272086
Test: build + boot emulator
Change-Id: Ib3b711dc05dd6136a68e6de414d806687a849bc9
These attributed define a range for dessert releases where the jars
should be active, and included in corresponding CLASSPATH varibles by
derive_classpath.
Bug: 190818041
Test: presubmit
Change-Id: Ieb9aef29657ad0694d48a63019f93faca2678252
This CL updates platform_systemserverclasspath,
systemserverclasspath_fragment, and
prebuilt_systemserverclasspath_fragment to write entries for
STANDALONE_SYSTEMSERVER_JARS to systemserverclasspath.pb. A new property
`standalone_contents` is aded to `systemserverclasspath_fragment` and
`prebuilt_systemserverclasspath_fragment` to list the standalone system
server jars in the APEX, and entries will be written to
systemserverclasspath.pb accordingly at build time.
To add more context, these entries will be consumed by derive_classpath
in order to generate an environment variable
PRODUCT_STANDALONE_SYSTEM_SERVER_JARS. The environment variable will
then be comsumed by odrefresh to determine what jars to preopt on early
boot.
Note that the variable should not end with "CLASSPATH" because the list
is not used by runtime as a classpath. It is just a colon-separated list
of jars. System server loads the jars separately with paths hardcoded in
the code.
Bug: 203198541
Test: manual -
1. Add some jars to PRODUCT_STANDALONE_SYSTEM_SERVER_JARS
2. Add some other jars to PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS
and standalone_contents.
3. Build an image.
4. Flash the image to a device.
5. adb shell echo \$STANDALONE_SYSTEMSERVER_JARS
6. See the correct list of jars.
Change-Id: I09a6fd1d3db85c194330da9b751702a9bf069e26
Note that ART apex boot jars and core-icu4j are exceptions here as they
are not part of ApexBootJars. ART apex boot jars are defined in their
own variable, while core-icu4j is treated as a regular non-updatable
boot jar.
Bug: 191127295
Test: atest CtsClasspathsTestCases
Change-Id: I3cea3d82ef521655a1a5ffa8cae2258ab9d08bfc
Sometimes the stem property is set to change both the installed file
name and the name use to filter the configured module list, e.g. when
adding a test library to replace the standard library, e.g. test_foo
instead of foo.
Sometimes it is used just to change the installed file name.
This change uses both to filter the updatable boot jars and not just
the stem.
Bug: 180105615
Test: m nothing
Change-Id: I6c459fc3597b1e4f062bc9a4e52843305b538c5f
Any apex classpath fragment that doesn't generate its own classpaths
proto, must still propagate it's boot jars for the platform classpath
fragment to include for complete CLASSPATH variables on device.
Bug: 191127295
Test: atest CtsClasspathsTestCases derive_classpath_test
Change-Id: I93687f69006741fcd66eb6e04891a4b4bbcc3b47
This must always be true for updatable apexes, but is not necessary
for non-updatable apexes like com.android.i18n.
In a follow up this will be used to figure out whether apex boot jars
should be bundled into platform_bootclasspath.
Bug: 191127295
Test: atest CtsClasspathsTestCases derive_classpath_test
Change-Id: Ib7dc5b057cb24955222fb97f3ff9da079f30ed77
There is no need to leak soong module names.
Bug: 180105615
Test: m && launch_cvd; atest CtsClasspathsTestCases
Change-Id: I04f4e181d2f42b9d71641980a2c7c4e8cbc8e426
The intention before was to use relative paths to a partition where a
config is defined. However, jars in /system_ext partition are planned to
be declared in /system's classpaths.proto config.
Bug: 180105615
Test: derive_classpath_test, CtsClasspathsTestCases
Change-Id: Icc3e1a903c34187cfcd67a3ae7bc3dd746445c03
The new info struct can be easily shared with systemserverclasspath
fragments.
Bug: 180105615
Test: m nothing
Change-Id: I9986e64fdf19f4168da63c156de3dc9bcafac8d8
- Adds all required details for bootclasspath_fragment to implement
classpath_fragment.
- Keeps the actual boot jars in platform-bootclasspath to begin with.
- Makes sure to put the file in apex/etc/classpath on device. Note that
for platform versions of classpath fragment AndroidMkEntries perform
the installation, while for APEXes it must be plumbed via apex.go.
Bug: 180105615
Test: m && launch_cvd; atest CtsClasspathsTestCases
Change-Id: I6101ebdf5b8bcbe95c0b7ce21f3f67a2685aef50
Each specific classpath_fragment module knows what jars must be part
of the corresponding classpaths.proto config.
Note that bootclasspath_fragment does not implement classpath_fragment
yet, thus all boot jars and all system server jars go into corresponding
platform classpaths.
Bug: 180105615
Test: m && launch_cvd; atest CtsClasspathsTestCases
Change-Id: I6a8c7b0a5d17d62e790a441b8e2c5c1a816e7f30
Boot jars are different to system server jars at build level, due to
added complexity of dexpreopt. As a logical separation add a new
classpath fragment type and split existing classpaths.proto generation
into relevant pieces.
Bug: 180105615
Test: m && launch_cvd; atest CtsClasspathsTestCases
Change-Id: I88bec09fc920166ffd0092faef980754ddeb6593
Instead of embedding "raw" values from PRODUCT_*_CLASSPATH variables
into /etc/classpath, encode them into classpaths.proto binary format.
Existing platform_bootclasspath{} module is used to generate the whole
monolithic config to begin with. Later, the config will be split
among individual bootclasspath_fragment and
systemserverclasspath_fragment modules.
Bug: 180105615
Test: m && launch_cvd
Change-Id: Ia66f521f8976ff78a62ecf91131d26db21064de7
A skeleton of a classpath fragment's interface and base to be used by
any modules that provide entries for *CLASSPATH variables at runtime.
In follow up changes, this would be extended to generate
packages/modules/SdkExtensions/proto/classpaths.proto configs for such
modules to be bundled into system and individual apex binaries.
Bug: 180105615
Test: m
Change-Id: I2df550862e97222c5650c4d0480c90231fd78ef0
