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
Add 'host' into the name of fields regarding path on the host side to
distinguish between paths on the device(which will be added in the
following commit), and paths on the host.
Bug: 158843648
Test: build and flash, and then
adb wait-for-device \
&& adb -s $S root \
&& adb -s $S logcat \
| grep -E 'ClassLoaderContext [a-z ]+ mismatch' -C 1
Change-Id: Ib2645ed51591ba2f4b726c115b401ad2bd6675da
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
Previous refactorings of the code for creating these two files caused
them to be created before the boot.prof file instead of afterwards. As
a result even though they were appended to the list of files to install
they were discarded when the boot.prof file set the list rather than
appended to it. That worked before the refactoring because the
boot.prof file set the list first before the others were appended to
it.
This change appends the boot.prof file to the list making the order in
which they are added irrelevant.
Bug: 187494247
Test: m nothing
- check DEXPREOPT_IMAGE_PROFILE_BUILT_INSTALLED in generated
make_vars file to ensure it includes all 3 files.
Change-Id: Idb94531daf61b1b047c72eb5c67a57d3fdced05c
This is part of the work needed to allow the exported_java_libs
property to be replaced by exported_bootclasspath_fragments.
Bug: 187266082
Test: m nothing
m SOONG_CONFIG_art_module_source_build=false nothing
Change-Id: I2c1d70a390200b93163f9799719290c9d55a041c
The libs property in java_sdk_library is not safe to export as it can
contain libraries that contain implementation specific classes. No
snapshot appears to need this capability but if it does become
necessary then either it will need to use the existing stub_only_libs
property or a new one will need to be added.
Bug: 157884619
Test: m nothing
Change-Id: I60a069177dbee4070d311b23d25f4eb3c5e7ea13
Previously, only those SdkMemberTypes which had specific need to
automatically add some of their dependencies as sdk members would cause
the sdk to visit their transitive dependencies. However, as any module
can have dependencies on license modules and license modules need to be
included in the sdk then it needs to visit transitive dependencies of
all members.
So, this change removes the support for allowing an SdkMemberType to
control whether its transitive dependencies are visited and just visits
them all.
This does not have any effect on sdk snapshots as in order for a
dependency to be added to an sdk it needs to be added with a tag that
implements SdkMemberTypeDependencyTag and the only tags that implement
this are used by SdkMemberTypes that had enabled transitive members.
Bug: 181569894
Test: m art-module-sdk art-module-host-exports art-module-test-exports
- verify that this change has no effect on the generated snapshots
Change-Id: If0293af0237aa7e39335e5b8383a41c023ff5853
A follow up change will add methods to SdkBase which requires its
module field to have been initialized.
Bug: 181569894
Test: m nothing
Change-Id: I9b02f260ad3f82316cc7ab3b5717b7e81090b0d8
Consistent with plumbing of boot jars. SystemServerJars only support /system/framework/ jars.
Bug: 180105615, 155630745
Test: m && launch_cvd
Change-Id: I58b005b7c4103c8e250090e995b1d9b2f9ed4a76
Maintain compatibility with previous behavior by ignoring dex_import
during hidden API processing.
Bug: 179354495
Test: m nothing
Change-Id: I976b02129bf981b7b61dce233567d6f89e04f92d
R8 processes are sometimes hanging on the build servers. Wrap R8 with
run_with_timeout to dump the stacks with jstack and kill the process
after 30 minutes. Switch from running with the r8-compat-proguard
shell script to running the jar directly so that jstack gets the pid
of the java process.
Bug: 181095653
Test: m checkbuild
Test: m NetworkStackNextIntegrationTests
Test: m USE_RBE=true RBE_R8=true RBE_R8_EXEC_STRATEGY=remote NetworkStackNextIntegrationTests
Change-Id: If6996bd8eb39c7a8453d79e825004339c009ade2
The previous attempt, which simply skipped the hidden API processing
altogether when unbundled builds were enabled failed when attempting to
build module snapshots as while they enabled an unbundled build they
actually need the hidden API processing to be performed.
This change just checks whether missing dependencies are allowed and if
so it fakes up any missing files so that the build will only fail if
they are not present AND they are used.
Bug: 186695448
Bug: 185828824
Test: tapas Calendar
m -j60
Change-Id: Ie13fed05af0aba51f45f6791fce944d0e4285037
The main difference between the dexpreopt_bootjars singleton and the
platform_bootclasspath singleton module is the way they find the
modules to use. The former searches all modules, the latter adds
dependencies on the modules that they need. This change separates the
finding of the modules from the copying of the boot jars for those
modules to make it easier to move the remaining functionality to
platform_bootclasspath.
This temporarily creates a singleton specific copy of the hidden API
function isModuleInConfiguredList() to select the modules in place of
the logic in the getBootJar() method. There is a slight loss of context
information from the error messages but as these methods will be
removed once the boot image creation has moved this is not an issue.
While switching the isModuleInConfiguredListForSingleton() to use the
SingletonContext the error message was fixed to include the name of
the module with the issue.
Bug: 177892522
Test: m nothing
Change-Id: Iaea906da95d9da5301fb964fc593890f2216d336
The getBootImageJar function will be removed once the boot image
creation has been moved to the platform_bootclasspath and
bootclasspath_fragment module types. However, the consistency checks
that it performs are still useful so this change moves them out
first.
The ART boot image related checks are now performed in the
bootclasspath_fragment module type. A previous change accidentally
disabled the checks when the contents property was not empty which has
been fixed. Also, the error messages have been tweaked to make it clear
that the art-bootclasspath-fragment is now the source of truth as to
its contents not the configuration.
The framework boot image related checks are now performed in the
platform_bootclasspath module type.
Initially, this change included an extra check to make sure that
UpdatableBootJars comes from updatable APEXes but that broke because
framework-wifi and framework-tethering are not currently marked as
updatable in AOSP.
Bug: 177892522
Test: m nothing
Change-Id: I80fb600fa2c7cec4566b3461c6a33c4c6f0743f4
