Add jni_libs property to java tests and treat it as test data that
should be copied to the lib or lib64 directory in the test directory.
This relands I3a118b933ab30dcd731c6dc2708da9bc63ab5520 with fixes for
the test on mac.
Fixes: 176593487
Test: java_test.go
Change-Id: I2f8c46643cff7a7ae6dc4d4dbad58f0396e45f09
Add jni_libs property to java tests and treat it as test data that
should be copied to the lib or lib64 directory in the test directory.
Fixes: 176593487
Test: java_test.go
Change-Id: I3a118b933ab30dcd731c6dc2708da9bc63ab5520
metalava is run inside sbox with a modified $PWD, so putting $PWD in
the output message results in an incorrect path. It was also always
incorrect when the output directory was an absolute path. Add a
cd $ANDROID_BUILD_TOP to the command line and use relative paths
instead.
Bug: 185516277
Test: m out/soong/.intermediates/frameworks/base/system-api-stubs-docs-non-updatable/android_common/metalava/api_lint.timestamp with lint error
Change-Id: Iefe133cea4c3a604ecd2b0ea20f4ba14ae13b425
The hidden API processing needs access to dex jars for the API stubs in
order to determine which dex members are part of an API surface. The
dex stubs used for the monolithic file are provided by normal
java_library modules for legacy reasons. However, the APEXes that
contribute to the bootclasspath, and so need to perform hidden API
processing, typically provide stubs created by a java_sdk_library.
This change adds support to java_sdk_library/_import to make the dex
stub jars available when requested, that involves:
1. Adding compile_dex property to java_sdk_library_import and
propagating it down the the java_import modules for the stubs. That
is already handled for java_sdk_library.
2. Propagating the java_sdk_library compile_dex property to the
java_sdk_library_import in the generated snapshot.
3. Refactoring and wiring to make the dex stubs jar available to other
parts of Soong.
Bug: 179354495
Test: m nothing
Change-Id: I5895d4f2ba0b684870862b9429b2364865e4afc6
When Soong looks for boot jars among all modules, it applies certain
constraints to each module that looks like a boot jar (e.g. that it
comes from the right apex or platform). Previously these constraints did
not handle boot jars on /system_ext correctly (they were handled like
apex jars, while they should be handled like platform jars).
Bug: 154976937
Test: m nothing (the modified Soong test would fail previously)
Change-Id: I0746a2fd276ab5ef0400340c5b61cf26c2570e5a
Previously, each category of flag file had its own property in the
hiddenAPIAugmentationInfo struct that required a lot of repetition
to use. This change moves the flag file specific handling into a
new hiddenAPIFlagFileCategory struct which allows use of the
hiddenAPIAugmentationInfo struct to be parameterized.
Bug: 177892522
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
Change-Id: I4413134c0c9382139bef3813f847e453f426692c
This change moves the monolithic hidden API index file creation rule
from the hiddenAPISingleton into the platform_bootclasspath.
Bug: 179354495
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
Change-Id: Ib25be3618e30a83dc2929a18062eb58eefdabefb
This change moves the handling of the prebuilt hiddenapi-index.csv file
from the hiddenAPIIndexSingleton and removes that as it no longer
needed.
Bug: 179354495
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
Change-Id: Iab1b39a57f28caa855c48538aa2230795f2c3271
This change moves the monolithic hidden API index file creation rule
from the hiddenAPIIndexSingleton into the platform_bootclasspath. It
also moves the corresponding test from java/hiddenapi_singleton_test.go
to java/platform_bootclasspath_test.go.
Bug: 179354495
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
Change-Id: Ia295d0f7ae9b51ea816f16921aa42339ed91704e
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
Checks to make sure that every module that is part of the platform
bootclasspath has been initialized property for hidden API processing.
Bug: 177892522
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
Change-Id: Ic4368963f2011784b537b8aebf5ef97ea22b2db5
As part of the work to modularize the hiddenAPI processing the
generation of the monolithic hidden API index file needs to be moved
to the platform_bootclasspath module type. Doing that broke the
TestBootDexJarsFromSourcesAndPrebuilts tests which checks the inputs to
the rule that creates that file. Fixing that required added a
platform_bootclasspath module to the test fixture for those tests which
highlighted an issue with the prebuilt_apex module.
Previously, when the prebuilt_apex created apex variants it would use
its own name as the apex variant name, even when that name included the
prebuilt_ prefix. That broke the platform_bootclasspath logic as it was
looking for apex variants for "myapex" but the only ones available were
"prebuilt_myapex".
This change ensures that it always uses the unprefixed name and fixes
the TestNoUpdatableJarsInBootImage to match. This also adds some
improved error reporting in platform_bootclasspath which helped debug
this problem.
Bug: 177892522
Test: m nothing
Change-Id: I3e88b5cec767f77dcc0e94b3ae38b499d07eadf0
incompatibilities.txt doesn't exist anymore, only
"<module>-incompatibilities.txt". Clean up the associated logic that
mapped incompatibilities.txt to android-incompatibilities.txt.
Bug: 178171189
Test: m
Change-Id: I61eeb5dcc82770fa2af356bad11b7205551d6d83
