This avoids having to specify boot libraries in both the boot_image
and separately as java_libs on the apex. Simply add them to the
boot_image (happens automatically ATM when using image_name: "art")
and add the boot_image to the apex.
Bug: 177892522
Test: m nothing
Change-Id: I7e0c41665604b73780cdf0dc555067497b1e6ef0
Allows boot_image modules to be created for any module that contributes
to the boot class path, e.g. core-i18n from the com.android.i18n.
A boot_image module with a contents property cannot specify an
image_name, and vice versa. Only those boot_image modules with an
image_name create .art, .oat and .vdex files, either in their
associated APEX or as part of the framework "boot" image.
Bug: 177892522
Test: m nothing
Change-Id: Idfc2bcf00dd6d3ed36ac4df46fcf18e8aa7e2c92
Adds dependencies for the art boot image. The art boot image only
includes modules from the com.android.art APEX and so this change adds
some verification to make sure that the APEX component of the
configuration is compatible with the boot_image's apex_availabilty
settings and then just adds dependencies on the modules. It relies on
the normal APEX processing to cause the com.android.art variant of the
boot_image to depend on the equivalent variant of its contents.
This purposely does not check that the configuration specifies an APEX
of com.android.art and instead relies on the apex_available property
being set.
Bug: 177892522
Test: m nothing
Change-Id: I75a8238546b01e1f166a1d1444215f4afb441780
This is part of the work to rename boot_image to bootclasspath_fragment
which is being done for two reasons:
1. To avoid clashing with the bootimg module type.
2. To better reflect what this represents.
While a bootclasspath_fragment can create what ART calls a boot image
(which is different to what the bootimg module type represents) it does
not have to do so.
Bug: 177892522
Test: m nothing
Change-Id: Ib45604be7adc790ded9e27a2ac812dd7522ca8db
Previously it was unrealistic because the "boot" image cannot be added
to an apex (because it references modules from multiple different
apexes). Only the "art" image can be added to an apex. So, this change
switches to use the "art" image which requires the apex name is changed
to "com.android.art".
This change also adds an equivalent test for prebuilt_boot_image as
well as a check of the module dependencies for the mybootimage module.
Bug: 177892522
Test: m nothing
Change-Id: I20089b02c80bedc072dbb950dce09bc4e8397f3a
building test_for modules.
This extends the current approach where test modules always depend on
the platform variants of the APEX libs, and only skips the stubs on
them. It still has the limitation that the internal libs must have the
exact same apex_available lists.
Also some improvement of the test accuracy in TestTestFor.
Test: m libartagent-target
with http://r.android.com/q/topic:libdexfile-noext applied
Bug: 183217299
Change-Id: I2118b8a22c887077867a3ddbbe73437b4a29a6ad
Test behavior was changed a while ago so that tests by default ignore
non-existent source paths (unless they explicitly check for/rely on
them). Prior to that CheckSnapshot() could detect when files were
missing from the snapshot but it no longer can.
This change disallows non-existent source files in all the sdk tests
which means that they are disallowed when processing the snapshots as
they use the same preparers as were used to process the sources.
This caused a test failure which has been temporarily ignored and has
a TODO and bug associated with it.
Bug: 183184375
Test: m nothing
Change-Id: I969d8515d20ef5ae515f2b5f93d8ed4e4f8ede75
This change needed to add some additional files to the registered
files for PrepareForTestWithJavaDefaultModules because otherwise they
would fail when "TestAllowNonExistentPaths = false". Those files were
being added by the TestJavaLintRequiresCustomLintFileToExist (albeit in
some cases in different locations to that required by the default
modules but as the files are needed by the modules defined in
PrepareForTestWithJavaDefaultModules they should be defined in it.
A couple of other places also provided some files so moving them into
PrepareForTestWithJavaDefaultModules caused some conflicts which needed
to be resolved.
Bug: 183184375
Test: m nothing
Change-Id: I76ce9f1673c1c1c4000635b76b8377d582224bf1
Creates a new deptag type for it so that it can implement the marker
interfaces that will exclude it from being added to the APEX and from
visibility enforcement. The latter is probably not an issue ATM because
the dependencies are added after visibility checks are enforced but
this code is undergoing lots of refactoring so that may change.
Bug: 177892522
Test: m nothing
Change-Id: Ibd167d557adec761a2e3eed78f4d334c40a04fb9
The ExcludeFromApexContentsTag marker interface was added to avoid
every implementation of DepIsInSameApex() from having to deal with the
special tags, like PrebuiltDepTag. Unfortunately, when adding that
not all calls to DepIsInSameApex() were protected which meant that the
BootImageModule, which panics if it doesn't recognize a tag, was
causing failures. This change documents the need and improves the
consistency.
A follow up change will add a test for this.
Bug: 182992071
Test: m nothing
Change-Id: If0bf9a7447ebf7a0bb0c88e91951a7220d4af45c
This allows the testCustomizers to be switched to FixturePreparers
incrementally rather than in one go.
Bug: 181070625
Test: m nothing
Change-Id: Idd9d2e28abf9b17fc46b5566ab8d3affa330287e
