This adds the registration of the mutator to the existing register...
method which will include it in PrepareForTestWithJavaBuildComponents.
Bug: 182885307
Test: m nothing
Change-Id: I6cea716a3ff4d8abdb80543b7e0ddf22246ffa30
It appears as though this is the first pre-singleton type to actually
be registered with the InitRegistrationContext as it failed due to an
uninitialized map, so this change also fixes that.
Bug: 182885307
Test: m nothing
Change-Id: Ibbf6d0db5f3c2fcc89291a16aa5f16b8b5009bd3
The methods returns a copy of TestingBuildParams with every usage of a
path that is relative to the temporary test build directory with a path
relative to a notional top. Similar to how PathRelativeToTop does.
Bug: 182885307
Test: m nothing
Change-Id: I6ec20fc52ed76748138f0d48b4df80f765dfcfdc
When searching for an TestingBuildParams this change will compare the
supplied path against the value returned by PathRelativeToTop() as well
as the String() and Rel() values. In the event that it cannot find the
file it also formats the available outputs, one per line with both rel
and path relative to top.
Bug: 182885307
Test: m nothing
Change-Id: Icbd37018b9a028abf37e27d1bea12a407316e031
Allows the removal of the provider parameter and makes it easier to add
new functionality to baseTestingComponent.
Bug: 182885307
Test: m nothing
Change-Id: Ie8ac600cbce982f2c5fc24a22968efe0c2a29d0c
Link against the libunwind.a shipped with the NDK so it matches what's
linked into the NDK's libc++_shared.so.
Bug: http://b/153025717
Test: device boots, manually inspect some linker command lines
Change-Id: Icc79844f5e70f0eaa97ea758449c30fbddd030d2
Added to reproduce the conditions that lead to the error reported in
the bug so they can be fixed. There were a number of issues that were
fixed in previous changes and this test verifies that they have been
fixed.
Bug: 182992071
Test: m nothing
Change-Id: I2197899b284a99973e698db314b15812f602b141
The visit() method was dropped in favor of a list() method as the
latter makes it easier to treat fixtureFactory, simpleFixturePreparer
and compositeFixturePreparer as simple collections of already flattened
and deduped *simpleFixturePreparers. That will be used in a follow up
change.
Bug: 183235980
Test: m nothing
Change-Id: Ia41ae9bd4f9c39c85865ba698e0da6be00519caf
Extracts the setup for apex from prepareForSdkTest to allow it to be
reused without using all of it. That will allow tests to optimize their
test setup.
Bug: 182638834
Test: m nothing
Change-Id: I2056103b15c2737a616ee29ff890c6af0722e6d2
The ExtendWithErrorHandler method simply wraps the FixtureErrorHandler
in a FixturePreparer that will set the error handler in the fixture.
Bug: 183235980
Test: m nothing
Change-Id: Icf9a5f62cb532efc120300c2f906cd3397aa6763
Using the preparer(s) that were used to run the test to verify the
integrity of the generated snapshot ensures that it will be verified in
the same environment as the snapshot was generated. This ensures that
as sdk tests are migrated to use fixtures that are optimized for each
test that they will benefit from those optimizations when checking the
snapshot.
Bug: 183184375
Test: m nothing
Change-Id: I62b383f9a1d9a77d1cabb101d9d1e4a976170fe3
The Preparer() method allows for another test to be run using the same
preparers as were used to create the TestResult. That is useful when
testing functionality like the sdk snapshot mechanism that generates an
Android.bp and a set of files that are intended to be reconsumed by
Soong. This method allows the test to process that output to ensure
that it is valid. A follow up change will migrate the CheckSnapshot()
method to use this as part of the migration of the sdk package to the
test fixture model.
Previously, the dedupAndFlattenPreparers() would not construct a list
containing all the preparers passed to it as it was trying to avoid
constructing such a list unless necessary. However, as every usage of
this method now needs to construct such a list that functionality has
been added to it.
Bug: 181070625
Test: m nothing
Change-Id: Iab34e2c861bdfd05c44e982224f70c5abc19e468
These packages have already been migrated to use per test build
directory so have no need for a FixtureFactory.
Bug: 183235980
Test: m nothing
Change-Id: I667d1d992caaf0f615de91f89efdae11c44986c2
Prior to this FixtureFactory was basically a FixturePreparer with the
additional support for buildDirSupplier. This makes that a reality by
moving the functionality of FixtureFactory into FixturePreparer and
making FixtureFactory extend that with buildDirSupplier.
This also deprecates the Extend() method in favour of simply using the
GroupFixturePreparers() method.
Once all usages of buildDir have been removed so the buildDirSupplier
is no longer required then FixtureFactory will be removed altogether.
In the meantime follow up changes will migrate those tests that do not
require a buildDirSupplier to just use FixturePreparers in preparation
for the eventual removal of FixtureFactory.
Bug: 183235980
Test: m nothing
Change-Id: Ibb4e5bfec2f76ee34dd7de6aed6bbbfe27d337b8
Background: `min_sdk_version` of a crt object is the oldest SDK version
that the crt object supports. When it's set to for example 16, Soong
creates a number of versioned variants of the crt object starting from
16 to the latest version. The variant for version X is provided to NDK
clients having `min_sdk_version` set to X.
Problem: all versioned variants of a crt object were built with `-target
<arch>-linux-android16`. Therefore they all have been with `#define __ANDROID_API__
16`. This is because the mutated variants still have the same
min_sdk_version property and the clang triple follows min_sdk_version,
not sdk_version. This is too conservative and against our intention to
provide the latest crt object that matches with the min_sdk_version of
the client.
In the other hand, the platform(non-sdk) variant of the crt object
doesn't have such a problem. min_sdk_version is completely ignored.
However, this is a bug and will be fixed by aosp/1640364. As a side
effect of the fixing, the platform variant will begin to built with a
very old __ANDROID_API__ which unnecessarily turns off the new platform
features like the TLS segment over-alignment.
This change fixes the problems:
* For the versioned variants of crt objects, we set both
`min_sdk_version` and `sdk_versio` to the version that the variant is
created for.
* For the platform variant of crt objects, `min_sdk_version` is force
reset to "current".
Bug: 183191008
Test: m
Change-Id: I8c9d0fcea816de8cd1532dac4a47eee4f726c037
Background:
When compiling cc_* modules, min_sdk_version determines the "version"
part of the clang triple: -target <arch>-linux-android<version>. The
version part is used to make sure that calls to the APIs that are added
after the version are guarded with a runtime check (i.e.
__builtin_available).
Previously, min_sdk_version was used as the version part only when the
cc_* module is unbundled (e.g. built for an APEX or built with SDK). In
other words, min_sdk_version has been ignored for the platform variants.
They were built with the version number 10000.
This was problematic for Mainline module tests. Since they are neither
part of an APEX nor built with SDK (because they need to have access to
some of the module-only APIs), they are built with the version number
10000. As a side effect, __builtin_available macro are expanded to 1 at
build time - because 10000 is higher than any API versions. When such a
test built in the latest platform source tree runs on a device running
an old platform, it tries to call an API that might not be available on
the platform and experience a crash, due to the lack of the runtime
check.
This change fixes the problem by using min_sdk_version as the "version"
part of the clang triple, regardless of the module's variant. Then
__builtin_available macro in the tests doesn't expand to 1, but to a
function call to the libclang_rt.builtin library which checks the system
property ro.build.version.sdk.
Bug: N/A
Test: run resolv_stress_test
Change-Id: I88f64c5a35f1b5276c3350e177b116932011a940
PlatformSepolicyVersion and BoardSepolicyVers haven't assigned correctly
so far. Below is the reason why it hasn't been discovered yet.
DeviceConfig.PlatformSepolicyVersion() was added to support mixed
sepolicy build (setting BOARD_SEPOLICY_VERS and building vendor sepolicy
with old plat policy files). Soong compares PlatformSepolicyVersion()
and BoardSepolicyVers(), and used old vendor sources if both are
different. Back then, the only place where such logic played a role was
selinux contexts. Test codes were running as intended: after setting
BOARD_SEPOLICY_VERS the context files were built against old policies.
But there were two mistakes:
1) PlatformSepolicyVersion() was not added to soong_config.mk, so it was
always empty.
2) BOARD_SEPOLICY_VERS was set to default in system/sepolicy/Android.mk,
which was processed after soong_config. So if BOARD_SEPOLICY_VERS was
not set in BoardConfig.mk, BoardSepolicyVers() was empty, not
PLATFORM_SEPOLICY_VERSION.
And there were no issues as Soong only checked equality.
To fix the issue correctly, this commit adds the variable
PlatformSepolicyVersion, and then handles BoardSepolicyVers correctly by
returning PlatformSepolicyVersion if it's empty.
Test: set BOARD_SEPOLICY_VERS and see vendor_file_contexts changes
Change-Id: Ie55827f47d2903e9739eccacc3874d354d5c9f2d
This CL adds no functional changes, it only splits a few functions into
parts that will be reused in a follow-up CL.
Bug: 178467404
Test: lunch aosp_cf_x86_64_phone-userdebug && m
Change-Id: I2bcb3c03d51175130da29fdfaf6dd747e3aea964
There are modules that would have passed verify_uses_library check, but
don't run it for some reason (the check gets enabled either with an
explicit setting, or if the module has nonempty <ues-library> lists in
the build properties). Previously all such modules were assumed to have
empty CLC, which is not always true. In particular, compatibility
libraries are ignored, which affected e.g. Calendar and messaging apps.
This CL gives such apps a chance to have correct CLC. The goal for the
future is to enforce verify_library_check by default.
Bug: 132357300
Test: lunch aosp_cf_x86_64_phone-userdebug && m
Change-Id: Iea3be0fc9d7775c52950848b5a3fd3b7fcd36c53
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
The output from bootstrap would contain the a one-line summary of RBE
download / upload stats.
Bug: b/183007125
Change-Id: I90082a8433504e40bbf92992c3c8d1d656c49429
Java build components invariably require android build components such
as the arch mutator (to create the common variant) so include them
together.
Bug: 181070625
Test: m nothing
Change-Id: I435b09a34c48c67b890368b37b8da27e8de97c9a
The section is stripped from binaries (but preserved in /symbols).
However, is it also unintentionally copied into the minidebuginfo
compressed section, which is included in the final shipped binary.
(This does not affect symtab symbols, which are handled as usual)
Removing it from mini-debug-info shrinks some rust binaries by
up to 10x, saving >10MB on the system partition overall (AOSP).
Test: extract minidebuginfo and check it manually with readelf
Change-Id: I462d81455626bb2b5244e1bf3d5f8b71646f3401
