Previously, the split_packages, single_packages and package_prefixes
properties were all optional and the split_packages defaulted to ["*"].
As that value conflicted with the other package properties that meant
that split_packages always had to be specified even if it was to just
set it to an empty array.
This change requires at least one of them to be specified and defaults
split_packages to an empty list which means it is not required,
although it can be helpful to make that explicit.
Bug: 194063708
Test: m nothing
Change-Id: I5a4c2d68e72e39f5c4a2441326dfce8685fc8ff2
The source of truth for what jars are in BOOTCLASSPATH and
SYSTEMSERVERCLASSPATH is make; adding a classpath fragment in soong
with a new jar in the contents without having it declared in make
is wrong (excluding test apexes).
Bug: 191369843
Test: m nothing
Change-Id: Ifd313776ee7ad206031244534ed3870126e4f835
This is in preparation to r.android.com/1740313 where setting correct
variables would be enforced (i.e. apex and non-apex boot jars must be in
config.ApexBootJars and config.BootJars correspondingly).
Bug: 191369843
Test: m nothing
Change-Id: Ic86680c1f7af53d229083b2cc58beb3ceccb4b6a
The configuration of the bootclasspath, e.g. PRODUCT_BOOT_JARS,
includes libraries that are standalone and libraries that are part of
an APEX. All libraries that are part of an APEX must also be part of a
bootclasspath_fragment. Currently, the libraries and fragments are
handled separately but that is limiting as it does not make it easy to
process all the libraries while treating those from fragments
differently to standalone libraries. That is needed for hidden API
processing as it needs to use classesJars from standalone libraries
but pre-generated flag files from fragments.
This change adds support for ClasspathElements which is represents the
classpath as a whole while differentiating between standalone libraries
and fragments.
Bug: 177892522
Test: m nothing
Change-Id: I7a4adc67164a46079eb8ec0a17fc755044b4949d
