This is needed to allow the art-host-module-exports to restrict itself
to just managing the linux 64 bit version of the host tools as that is
the only variant that is currently supported by all host tools. This
greatly simplifies that process and allows us to make progress on the
unbundling.
Bug: 142935992
Bug: 153306490
Test: m nothing
Merged-In: I62d016d97c2df73e5feecf912638f477fedd97c9
Change-Id: I62d016d97c2df73e5feecf912638f477fedd97c9
With Host_supported: true, C++ part of sysprop_library will create host
variant which can be used from host modules. As there are no native
system property support on host, libbase functions will be used instead.
Adding support on host will help reduce code complexity of other
host_supported modules.
Bug: 147708854
Bug: 153306490
Test: m, sysprop_test, manually test host binary
Merged-In: I850d91fea298ef1a0c16c6a7a9ec1aca5cf37e69
Change-Id: I850d91fea298ef1a0c16c6a7a9ec1aca5cf37e69
min_sdk_version is the minimum version of the sdk that the compiled
artifacts will run against.
For example, when a module is used by two APEXes and their
min_sdk_versions are set to 29 and 30, then the module should support
both versions even if it is compiled against 30. Therefore,
min_sdk_version of the module needs to be set 29 in that case. In
general, this is set as the minimum value of min_sdk_vesions of APEXes.
For now, there's no build-time checks about this prop even if the prop
is set.
Bug: 145796956
Bug: 152655956
Bug: 153333044
Test: m nothing
Change-Id: I072ad8c317d2615e8b08e4e7ea2db8e7955b4b12
The NDK prebuilts are implicitly used when building with sdk_version set.
Make the module types be available to any apex so that we don't need to
manually add apex_available property to the module definitions manually.
Exempt-From-Owner-Approval: cherry-pick from AOSP
Bug: 150999716
Test: m
Merged-In: I0870afa4c74b4a06ab1273dff84615778561ecc9
(cherry picked from commit e01e228270)
Change-Id: I0870afa4c74b4a06ab1273dff84615778561ecc9
The marked library(ies) were available to the APEXes via the hand-written
whitelist in build/soong/apex/apex.go. Trying to remove the whitelist
by adding apex_available property to the Android.bp of the libraries.
Exempt-From-Owner-Approval: cherry-pick from AOSP
Bug: 150999716
Test: m
Merged-In: I91d1b1076733a949ca2a959ba640ce34d0233492
(cherry picked from commit 541142ce6b)
Change-Id: I91d1b1076733a949ca2a959ba640ce34d0233492
Bug: http://b/153164546
Test: Built aosp_blueline successfully. Kernel also verified without
needing workarounds from LLD crash.
Change-Id: I41ae5a5be0065da98dd941b16196a3f4888b86b1
Merged-In: I41ae5a5be0065da98dd941b16196a3f4888b86b1
(cherry picked from commit 883a0fdfd9)
This CL adds a remoteexec package that allows adding a configurable RBE
prefix to the template.
Test: built aosp crosshatch userdebug with and without RBE_CXX_LINKS.
Change-Id: Ica920c3d7f79f2996210b9cbd448126451c1707c
platform.
The NOTICE file generation depends on the NOTICE targets for all static
library dependencies. If such a dependency didn't have
//apex_available:platform it didn't get any AndroidMk entry and hence
no NOTICE target via soong_cc_prebuilt.mk. If it was then depended upon
by a binary or library that is accessible to platform, the NOTICE
dependency failed.
Normally such a dependency is invalid, but there are corner cases where
binaries go neither into platform nor any APEX module, and they can
legitimately have such dependencies (cf. b/152241137).
With this CL requests to skip installation of such a static libraries
are ignored so that they get AndroidMk entries, which will always have
LOCAL_UNINSTALLABLE_MODULE set.
Test: "m simpleperf_ndk" with https://r.android.com/1273016, which
removes //apex_available:platform from libs that simpleperf_ndk
depends on statically.
Bug: 152241137
Bug: 149217815
Change-Id: If36e85dd16ade56d4ec1d6744811df5a15b6242c
Merged-In: If36e85dd16ade56d4ec1d6744811df5a15b6242c
It has been wrong to split ALL_VERSIONS into exclusive two sets of
before/after TARGET_PLATFORM_VERSION.
And PLATFORM_VERSION_ALL_CODENAMES supports all *active* list of
non-finalized codenames.
Bug: 152960049
Test: m
Exempt-From-Owner-Approval: cp from master
Merged-In: I78ca88758998e440bea72ba2d56d90eea3ec99ae
Change-Id: I78ca88758998e440bea72ba2d56d90eea3ec99ae
(cherry picked from commit 424175d72a)
Installed name of prebuilt shared library should be stem or module name.
For example:
cc_prebuilt_library_shared {
name: "libfoo",
srcs: ["libbar.so"],
}
should install with the filename libfoo.so, and
cc_prebuilt_library_shared {
name: "libfoo",
stem: "libbaz",
srcs: ["libbar.so"],
}
should install with the filename libbaz.so.
Prebuilt Windows PE library should specify its import library.
For example:
cc_prebuilt_library_shared {
name: "libfoo",
srcs: ["libfoo.dll"],
windows_import_lib: "libfoo.lib",
enabled: false,
target: {
windows: {
enabled: true,
},
},
}
Bug: 151744695
Test: prebuilt_test.go && built walleye-userdebug
Change-Id: Ia8d0afb7fa46783c670870440432779c5fc7321a
If a lib has stubs, that means the library provides stable C APIs and
the APIs are guaranteed to be maintained in a backwards compatible
manner. Then there is no reason to have the same library in VNDK,
because VNDK is for libraries (usually having C++ interfaces) where API
stability across the yearly releases is hard (or impossible) to be
guaranteed.
This change triggers an error when the build system finds a VNDK lib
which has stubs defined. Users are suggested to make the lib an LLNDK
one.
Exempt-From-Owner-Approval: cherry-pick from AOSP
Bug: 151303316
Test: m
Merged-In: Id305196a9d5a6fc7e7f9c02f3fa076859dc9a282
(cherry picked from commit ea97f51a29)
Change-Id: Id305196a9d5a6fc7e7f9c02f3fa076859dc9a282
The default build-id is generated using timestamp. Pass -Brepro to
avoid using timestamp for deterministic build.
Bug: 153462962
Test: build fastboot.exe twice, got same shasum
Change-Id: I38fe993eec23c60bfcf1b76188774bfe06839fa4
Merged-In: I38fe993eec23c60bfcf1b76188774bfe06839fa4
(cherry picked from commit a3c22e7ee2)
Exempt-From-Owner-Approval: backport
"version" mutator creates stubs variants for "cc" libraries with
"stubs.versions". These stubs are for APEX-APEX or APEX-Platform
boundaries.
For host/ramdisk/recovery variants, stubs are not necessary.
Bug: 153698496
Test: m
Change-Id: Id576c4318d9d69246a4a7e2fb4145d5fd2ab9416
For VNDK-Lite devices, which doesn't define BOARD_VNDK_VERSION, VNDK
APEX is built with only VNDK-Sp libraries with core variants.
Bug: 141908078
Bug: 152353068
Bug: 151635128
Test: TH
Merged-In: I0d08d32473368fd158818d4c2c72fc4cfad68ce6
Change-Id: I0d08d32473368fd158818d4c2c72fc4cfad68ce6
(cherry picked from commit 65d8a6262c)
Exempt-From-Owner-Approval: cp from internal
Change-Id: I0d08d32473368fd158818d4c2c72fc4cfad68ce6
The default build-id is generated using timestamp. Pass -Brepro to
avoid using timestamp for deterministic build.
Bug: 153462962
Test: build fastboot.exe twice, got same shasum
Change-Id: I38fe993eec23c60bfcf1b76188774bfe06839fa4
Apex can use codenames like "Q", "R" for its min_sdk_version property.
Also, cc_library can use codenames for its stubs.versions.
Bug: 152655956
Test: m
Merged-In: I077ad7b2ac5d90b4c8708921e43846206f05ba70
Change-Id: I077ad7b2ac5d90b4c8708921e43846206f05ba70
(cherry picked from commit 29e91d2121)
* Disable it for the next clang compiler update
until all source files with this warning are fixed.
Bug: 153464409
Test: WITH_TIDY=1 make
Change-Id: I126d2f5170f3883192348577e523ef99f5c5a70e
