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
Not needed anymore for bp2build-incremental since https://android-review.googlesource.com/q/topic:no-include-check.
Not needed for mixed builds either, since cc compile actions aren't sandboxed.
Fixes: 186488830
Test: treehugger and go tests
Change-Id: Ib5d4908dcce6bf910a653c457bb251d726e717d4
Vendor public libraries are checked for product modules, but never
reached because the VNDK check occurs first, and wouldn't work anyways
because vendor_public_library did not have the product_available
property. Reorder the rewrite checks and add VendorProperties, and
add a test.
Bug: 178231622
Test: vendor_public_library_test.go
Change-Id: Idbd2802fbd134d22c30600762cb0465633703506
This reverts commit cba7b0c43c.
Reason for revert: mixed_droid failing: libbacktrace fails due to libasync_safe, linkerconfig (and others) due to duplicate symbols
Change-Id: Ib6dd6bbb6f76048a7abd0970d457cf75921beae6
Previously, both a bootclasspath_fragment and its contents had to be
explicitly added to the sdk. This change means that adding a
bootclasspath_fragment to and sdk will automatically add its contents
as if they were added using java_boot_libs.
Bug: 177892522
Test: m nothing
Change-Id: I8f7e70649f272c9a109d4606571a2d12c44b7904
Previously, only one of the contents or image_name properties could be
specified at once which meant that there was no way to create a
prebuilt which lists its fixed contents while at the same time allowing
it to check that that the contents matched what the build configuration
required.
e.g. a prebuilt_bootclasspath_fragment that had image_name: "art",
could not list its contents and also check that those contents matched
the ART_APEX_JARS which the build configuration required.
This change allows contents and image_name to be specified together and
adds a check to make sure that the contents are consistent with the
configuration appropriate to the image_name. The check is only
performed for modules that are active so that a
prebuilt_bootclasspath_fragment which was created without coverage
enabled (the default) would not cause a build failure in a coverage
build unless it was preferred.
Bug: 177892522
Test: m nothing
Change-Id: Ie601f29f707b3f6030fa7d252afa2c4826cc9f8e
This will allow them to be used from elsewhere in a follow up change.
Bug: 177892522
Test: m nothing
Change-Id: I60e94e148af5b1810aea7f724cba090b49ae758e
This allows a bootclasspath_fragment (specifically the
art-bootclasspath-fragment) to specify additional contents to be
appended when coverage is enabled.
The art-bootclasspath-fragment will use this to add jacocoagent to its
contents to ensure that it is always consistent with the configuration.
Bug: 177892522
Test: m nothing
Change-Id: I50d05fe5e0e9b8c14bdf3dfd63bba0ac97e31d48
The field isn't used anymore.
And DexPreoptImagesDeps will have the slice of which size is the same as
Archs to avoid an error.
Bug: 158843648
Test: m
Change-Id: I520063ff7376811febbc82e1a0a43785feb5bbb2
The dex boot jar for the apex must have had hidden API flags encoded
into it. Currently, the hidden API processing is done within the java
modules themselves so the apex gets the dex boot jar from them.
However, as part of the hidden API modularization work the hidden API
encoding will be performed by the bootclasspath_fragment so this change
prepares for that by delegating the retrieval of the dex boot jars to
the bootclasspath_fragment, via BootclasspathFragmentApexContentInfo.
For the moment that simply delegates straight back to the java module
so this change does not change the build. It will however make it
easier to switch hidden API encoding to the bootclasspath_fragment in
future.
Bug: 179354495
Test: m com.android.art
- verify that this change does not change its contents
Change-Id: I12eba333749be976bcc72661bb9d6be6cc3c56e3
The apexBundle.GenerateAndroidBuildActions is 400+ lines long which
makes it difficult to understand what is happening.
Bug: 177892522
Test: m com.android.art
- verify that this change does not change its contents
Change-Id: I07cb31d246377869771bdb18fdc6291365adf399
Currently, it only contains ART boot image related information, i.e.
.art, .oat and .vdex files. However, follow up changes will extend that
to include other information from bootclasspath_fragment.
Bug: 177892522
Test: m nothing
Change-Id: I2b226131c0eccff0c739a18f265f90caa10a91d9
The BootImageInfo is used to populate an apex. A platform_bootclasspath
module cannot be part of an apex so does not need to provide one.
Bug: 177892522
Test: m nothing
Change-Id: I1e1c4962d9d8106a12af80107c4c35828f54ff81
Previously, the snapshot member list properties were simply copied from
the sdk variants. That worked because the snapshot member list
properties must include all exported (i.e. visible outside the sdk
snaphot) members and only members explicitly specified in the sdk
member list properties were exported. However, a preceding change
allowed members that were transitively added (and so not explicitly
specified on the sdk) to be exported.
This change ensures that those exported members are added to the
snapshot member properties which means that they will now work properly
with the sdk version mutators.
This does not add tests for this because no existing SdkMemberType
exports its transitive dependencies and there is currently no way to
register an SdkMemberType for testing only. A following change will
exercise this functionality.
Bug: 186290299
Test: m nothing
Change-Id: Iadbdd86f6dcdd183fa99f647222a43d412271501
Previously, every module added to an sdk directly through one of the
SdkMemberType specific properties, e.g. java_libs, was exported and
every module added automatically via a transitive dependencies was not
exported. This change allows that behavior to be customized per tag.
Bug: 186290299
Test: m art-module-sdk
- verify that this change does not affect its contents.
Change-Id: I563b5bcd823e61c23cdb706cfcbb13337963d550
Previously, the code was inlined in the addSnapshotModule() method
which made it difficult to follow, did not have clear separation
between the different pieces and duplicated functionality. This
change combines the dynamic and static properties together and then
separates the processing into collation, optimization and property
set updating methods.
Bug: 186290299
Test: m nothing
Change-Id: I311eebca2337cb67634e63d71da12305f4370c07
Previously, the code to add the compile_multilib property was
duplicated. This change moves the logic into the existing
addMemberPropertiesToPropertySet method, renames it to reflect new
behavior and renames and promotes the variantProperties struct from the
addSnapshotModule() method to the package level scope.
Bug: 186290299
Test: m nothing
Change-Id: I832a7fd89a3cf95467a1ff0807902c9be34c50b9
Previously the compile_multilib property was added after the member
list properties at the top level but before them in the target.os
level. This change makes it always be added before them.
Bug: 186290299
Test: m nothing
Change-Id: I01fe272933fd11f7f730cc379f60fb2ce70f2114
Renames some types and adds some documentation to try and clarify how
the sdk handles the members.
Bug: 186290299
Test: m nothing
Change-Id: I4038276f5f4c473a96fe06aedc43050c90416877
Previously, there were two types sdkMemberRef and sdkMember that seemed
as though the former was referring to the latter but that was not the
case. The former was actually information about the dependency the sdk
had on a specific member variant. The latter is all the information
about a specific member, including all its variants.
This change attempts to clarify that relationship, both through a
better type name and through some improved documentation.
Bug: 186290299
Test: m nothing
Change-Id: I1dcc0ddf3333da9e797bb23ae945d04729839014
Also renames files, tests, module types in a similar fashion.
There are still some references to image and boot image. They are kept
for the following reasons:
* image_name - this is the name of an ART boot image, i.e. the
collection of .art/.oat/.vdex files.
* BootImageInfo - again this is related to the ART boot image.
* .../art_boot_images/... paths - ditto.
Bug: 177892522
Test: m nothing
Change-Id: Ie1f4738061d131fee75de48bc26a7601481bad4d
Jeongik Cha