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
satayev