These two methods did very similar jobs and merging them together
simplifies the behavior.
Bug: 179354495
Test: m droid
Merged-In: Ibe1a23d54105e6a0e5693079cd8743679301fc85
Change-Id: Ibe1a23d54105e6a0e5693079cd8743679301fc85
(cherry picked from commit 74d18d1d6ff1ad8ec47c34182d1a22945e05e9d5)
The configurationName was intended to separate the name of the module
from the name used in configuration (such as BootJars) so that the
child implementation library of a java_sdk_library on the bootclasspath
would have hidden API encoding performed on it just as for the main
java_library embedded within the java_sdk_library.
While that did use to work it no longer does as the test added in the
preceding change proves. It is not surprising that this regression does
not appear to have caused any issues as the the child implementation
library is only a build time artifact and not used at runtime.
In future the only modules that will require hidden API encoding are
those that are part of a bootclasspath module so there is no point in
maintaining this capability.
Bug: 179354495
Test: m droid
Merged-In: Ief8136fa9e98600cdd8d36108ec22edc2ebd7c69
Change-Id: Ief8136fa9e98600cdd8d36108ec22edc2ebd7c69
(cherry picked from commit 66cdbf07ef2af6caf42e2c7b77b1a5fb86a4cee3)
Fill a hole in the testing of hidden API encoding. Some comments in the
code indicate that the child implementation java_library of a
java_sdk_library should have hidden API flags encoded in its dex jar
just like the embedded java_library. However, this test proves that it
is not working. This will be fixed in a follow up change.
Bug: 179354495
Test: m nothing
Merged-In: Ia581a17f1e48dff252d17f16bf76adf039f46b60
Change-Id: Ia581a17f1e48dff252d17f16bf76adf039f46b60
(cherry picked from commit 0d586581d1c2d6d22e7f00007e50e579ca90df29)
For running dex2oat on the target_files, the paths should be use the
device install path instead of the path starting with $(OUT).
So add usesTargetFiles option and basePath option which indicates
extracted path. With those options, the path is replaced with
$(basePath)/$(device path)
And also, add DexPreoptImageDeviceLocations in the config which refers
to the boot image path(without arch) on the device. Because
DexPreoptImage related device path was missing.
Bug: 158843648
Test: dexpreopt_gen -usesTargetFiles -basePath (extract path) and then
check if paths in the generated shell script are based on on-device
path.
Change-Id: I9667fadbf3b7c6f770e0d1bcbee5d67c1ecd8a3d
Merged-In: I9667fadbf3b7c6f770e0d1bcbee5d67c1ecd8a3d
(cherry picked from commit 4dda75e73e3e52e11b1cd37af33645fcfe5ed980)
Hidden API processing of a bootclasspath_fragment requires the fragment
provides information, such as dependencies on other fragments and flag
files to override the default flags. Failing to do so will cause hidden
API generation to either fail or to generate different flags to that
generated by the hidden API processing done by platform_bootclasspath
which will cause the build to fail.
Previously, this was handled by only performing hidden API processing
for those modules that provide stub libs and relied on there only being
bootclasspath_fragments defined for ART (which already supports hidden
API processing), and Conscrypt and I18n neither of which provide stubs.
Unfortunately, that can no longer be relied upon due to a couple of
recent changes:
1. A java_sdk_library in a bootclasspath_fragment's content property is
automatically treated a stub library. That avoids duplication for
most bootclasspath_fragments that provide the implementation and
stub libraries through the same java_sdk_library. It does not affect
either ART, conscrypt or i18n as they all define the implementation
separately to the stubs.
2. bootclasspath_fragment modules have been defined for a number of
android modules as they are needed for reasons other than hidden API
processing.
In combination this meant that rules to perform hidden API processing
were being created but they were not currently being used which is
good because they fail.
However, adding the fragment to the platform-bootclasspath will cause
those rules to be used as the platform_bootclasspath module performs a
consistency check on the hidden API flags generated by each of the
fragments to ensure that they are consistent with those it generates
itself.
The dynamic bootclasspath work will need to add fragments to the
platform_bootclasspath and without this change that would be blocked
until all fragments had been switched to generating hidden API flags
properly.
This change adds a new fragments property to the bootclasspath and
disables hidden API processing for everything other than ART and tests
if the fragments property or stub libs is empty.
Bug: 179354495
Test: - Before making this change.
- Add com.android.os.statds-bootclasspath-fragment to platform-bootclasspath.fragments
m out/soong/hiddenapi/hiddenapi-flags.csv
- hidden API processing fails in statsd as it cannot find java.lang.Object.
- After making this change, run the above command again and it should pass.
Merged-In: Ifbb362f8fcfb2c06595fbd5ae39421b536e329ef
Change-Id: Ifbb362f8fcfb2c06595fbd5ae39421b536e329ef
(cherry picked from commit 70cfdff3da2ea07cd5cb7f7b91474f6fa0c248e5)
The destination path, i.e. the path the file will occupy in the APEX is
more stable and less likely to change than the source path, i.e. the
path of the file in the out or source directories. This makes it easier
to diff changes in the copy commands.
Bug: 179354495
Test: m com.android.art com.android.ipsec com.android.os.statsd com.android.conscrypt
- verify that this does not change the contents of the apex files
- verify that this does change the order of copy_commands for the above apexes
Merged-In: Ia9ebe8418c59903cd738ee0fb9262b3f32a4ddbf
Change-Id: Ia9ebe8418c59903cd738ee0fb9262b3f32a4ddbf
(cherry picked from commit 56060290077a28257760e10fdf7894b99eb397a3)
Checking sdk_version broke mainline code that compiles against a current
API level but needs to be able to run on an older API level.
Bug: http://b/187907243
Test: treehugger
Change-Id: If1192ef2809e39b043f0a384775b6c9e3a8bd619
test_options in cc_test can have vsr_min_shipping_api_level to define
the minimum shipping api level that checks vendor api level in
addition to the device shipping api level. It can be used for the
tests that have dependency on the vendor api level.
vsr stands for the vendor software requirements.
Bug: 181284704
Test: manual test
Change-Id: I7f2cecd2818d35d86f7c08cb220e0c9db71fe0a8
Merged-In: I7f2cecd2818d35d86f7c08cb220e0c9db71fe0a8
(cherry picked from commit a364cfb69d3c5a3660bc4b19e40b4cd916496682)
go best practices recommend defining an interface where it is used and
limiting the scope
Test: go test soong tests
Change-Id: I96293ba594d37360b1a8910161477133d4aafdd9
A previous change treated this as an error in order to try and detect
issues with misconfigured java_sdk_library modules and/or
bootclasspath_fragment modules but unfortunately this is not always an
error, e.g. when migrating a library that was a shared library to the
bootclasspath.
This change stops treating that as an error.
Bug: 179354495
Test: m nothing
Change-Id: I4a833ab5f4caf86c6cd340090fc65d2c2f141512
Instead of encoding the hidden API with an empty set of flags when the
monolithic flags are not available this simply disables encoding
altogether which should have the same behavior at runtime.
This change also removes the unused flags field in hiddenAPISingleton
which was set but never read.
Bug: 179354495
Test: m nothing
Change-Id: I32d5825e5271829993dd4e5be4d4ee1b22fa7b22
The rules to extract hidden API information from an individual module
in order to create module specific files are no longer necessary as
the monolithic files are created directly from the module's class jars
and not the module specific files.
Bug: 179354495
Test: verified that the monolithic out/soong/hiddenapi/... files are
unchanged by this change
Change-Id: I573ac17f3ea5da5a2a7e4f08718160dacca71c0c
Previously, the monolithic hidden API files, e.g. hiddenapi-index.csv
file, were generated in two steps. First, each module created its own
files using the information in its class jars. Then, the monolithic
files were created by merging those module specific files into a larger
file.
This change switches to generating the monolithic files directly from
the class jar files and bypassing the intermediate files.
In order to ensure that this change did not change the monolithic files
it is necessary for the hiddenapi-metadata.csv to go through a
reformatting step. Hopefully, this will be able to be removed in a
follow up change.
Bug: 179354495
Test: verified that the monolithic out/soong/hiddenapi/... files are
unchanged by this change
Change-Id: I5a78e747516014b7c0f402a4b4431b14be6a84b2
Bug: 179354495
Test: verified that the monolithic out/soong/hiddenapi/... files are
unchanged by this change
Change-Id: I54b677c97712a7573ff5eed017c1b2198b80bc51
Paul Duffin