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
Previously 24 was hardcoded (for somewhat unclear reasons). Update
the tool to accept specifying the correct value on the cmdline.
Test: pom2bp -default-min-sdk-version 24
Change-Id: I39c23dd4bca91684a2a68d7b963cf3cb66eb1f33
Instead, return "any" SDK version 10000, which will cause dexpreopt to
not add any compatibility libraries to class loader context. This is as
good guess as any, and the build system already uses "any" version if
there is not manifest or APK from which to extract targetSdkVersion.
This fixes broken build on cf_x86_auto-userdebug.
Bug: 132357300
Bug: 183943146
Test: lunch cf_x86_auto-userdebug \
&& m out/target/product/vsoc_x86/obj/APPS/playback_intermediates/dexpreopt.zip
Change-Id: I5ee75639ece716c3a9800ddea346fe7c73da7c3a
Otherwise the check fails, as it depend on non-existent dexpreopt.config
files. This CL fixes broken build cf_x86_phone-userdebug_coverage.
Bug: 183931403
Bug: 132357300
Test: forrest build for cf_x86_phone-userdebug_coverage.
Change-Id: Id3ffeb742c1b82c677795fa701a7b5a867eabbbd
When measuring the sections of a binary, the file extension of the
output was replaced. Append the new extension instead, to preserve the
full name of the file measured.
Test: m out/soong/binary_sizes.pb
Change-Id: I4c7b5cf1be3bdce858a7cc72f278ddada0425898
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
Change-Id: Ic1c795d9d961b309d269b1bc4bccb7522f288e9b
Rationale: we haven't modified any gitignore file. lberki has a new proposal to steer this in a new direction, so let's reflect the comment to the current reality.
To be able to avoid registering dependencies on nonexistent host APEXes
in host builds.
Test: art/tools/buildbot-build.sh --host
with http://r.android.com/q/topic:libdexfile-noext applied
Bug: 183217299
Change-Id: Iaa6411b511b6f50da01827b49852607ae825bc83
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
* changes:
Strengthen metalava sandbox support using sbox
Move metalava's output files into a subdirectory
Fix lint warnings in droidstubs.go
Split droidstubs out of droiddoc.go
args properties can access arbitrary files with $(location) expansions,
so they need to pass them through RuleBuilderCommand.PathsForInputs
to produce a path inside the sandbox. Extract the arg expansion out
of collectDeps into a new expandArgs method that takes the
RuleBuilderCommand.
Test: TestDroidstubsSandbox
Change-Id: I9022d17bf3cb64c97b2008c4c1b733bf48edca95
Update the gen_ndk_usedby_apex.sh script to generate NDK API list with
library name.
Test: TARGET_BUILD_APPS=com.android.adbd m dist apps_only
Change-Id: I799e03ad7d81a4184229f658fd6c8824b9ba6e1f
* changes:
Replace ANDROID_SDK_HOME with ANDROID_PREFS_ROOT for metalava
Simplify lint rules using improved RuleBuilder rsp support
Support multiple rsp files in RuleBuilder
Pass rsp files into sbox and rewrapper
Add test for sbox input sandboxing
Support multiple rsp files in REParams
Move response file handling to a separate package
Run sandbox metalava rules inside sbox, which copies only the expected
inputs into a separate directory tree. This ensures it can't read any
extra inputs.
Test: m hwbinder.stubs
Test: TestDroidstubs
Test: TestDroidstubsSandboxed
Change-Id: I71a83e3af6a385cc23f895397c2c883a2ac5fa22
Paul Duffin