Not all vendor modules are meant to be working with multiple versions of
vndk unmodified. This restricts all vendor or vendor_available modules
to only one variant. Modules under proprietary directories will only
have BOARD_VNDK_VERSION variant, while modules under AOSP directories
will only have PLATFORM_VNDK_VERSION variant.
Bug: 157106227
Bug: 157133296
Test: capture snapshot from R
Test: try building master with R snapshot
Change-Id: I4ebe1da8d887cd76722fa8ab5ae9305da09074d4
This is a partial cherry-pick of Ic30ab6b844684bfc3e8ece5a1913980d5fbf8de2
so that modules with sdk_version properties added to cc_genrules can be
backported to rvc-dev. The property does nothing for now.
Bug: 149591340
Test: treehugger
Merged-In: Ic30ab6b844684bfc3e8ece5a1913980d5fbf8de2
Change-Id: I7be8efe8880130db10fb517b12606100c85a1411
When PRODUCT_PRODUCT_VNDK_VERSION is set to 'current', product
modules are enforced to use only VNDK libs from the system partition
as BOARD_VNDK_VERSION does to vendor partition.
Modules with 'vendor_available: true' create product variant as well
as core and vendor variants. The product variant as an image variant
is used for the modules in /product or /system/product.
It must not affect the current build behavior without
PRODUCT_PRODUCT_VNDK_VERSION set.
Bug: 134099726
Bug: 138966004
Bug: 144534640
Test: build without PRODUCT_PRODUCT_VNDK_VERSION set
Change-Id: I4d3585c110d84493e45bf76d550dc240bb26137f
Run the imageMutator between osMutator and archMutator so that
different arch variants can be set for the different partitions.
Bug: 142286466
Test: m checkbuild
Change-Id: I65d05714b75aa462bf9816da60fdc2deda4de593
Merged-In: I65d05714b75aa462bf9816da60fdc2deda4de593
(cherry picked from commit 9c8f687584)
Prepare for making the image mutator available to all modules and
moving it between the os and arch mutators by moving it into the
android package and using an interface implemented by the module
types to control it.
Bug: 142286466
Test: No unexpected changes to out/soong/build.ninja
Change-Id: I0dcc9c7b5ec80edffade340c367f6ae4da34151b
genrule modules were not mutated by the apex mutator. As a result, a
module that is mutated for an apex have depended on the genrule modules
host_bionic_linker_{asm|flags} that are not mutated for the APEX.
This in turn caused an inconsistency problem because the
host_bionic_linker_* genrules use the dynamic linker that isn't mutated
for APEX as an input, while the outputs of the genrules are used by
modules mutated for APEX. The inconsistency caused b/135008828.
Fixing this issue by correctly let genrule to be mutated by the apex
mutator.
Bug: 135008828
Test: checkout master-art-host
ALLOW_MISSING_DEPENDENCIES=true DIST_DIR=out/dist
./art/tools/dist_linux_bionic.sh -j50 showcommands
com.android.runtime.host
is passing
Change-Id: I92d90400c61d3951f6202d932832d0cb63c95a7d
A cc_library or cc_library_shared can be configured to have stubs
variants of the lib.
cc_library_shared {
name: "libfoo",
srcs: ["foo.cpp"],
stubs: {
symbol_file: "foo.map.txt",
versions: ["1", "2", "3"],
},
}
then, stubs variants of libfoo for version 1, 2, and 3 are created
from foo.map.txt. Each version has the symbols from the map file where
each symbol is annotated with the version that the symbol was introduced
via the 'introduced=<ver>' syntax. The versions don't need to be in sync
with the platform versions (e.g., P for 28). The versions are local to
the library.
For another library or executable to use the versioned stubs lib, use
the new 'name#ver' syntax to specify the version:
cc_binary {
name: "test",
....
shared_libs: ["libFoo#2"],
}
Internally, a new mutator 'version' is applied to all cc.Module objects.
By default, a variant named 'impl' is created for the non-stub version.
If the versions property is set, additional variations are created per a
version with the mutable property BuildStubs set as true, which lets the
compiler and the linker to build a stubs lib from the symbol file
instead from the source files.
This feature will be used to enforce stable interfaces among APEXs. When
a lib foo in an APEX is depending on a lib bar in another APEX, then bar
should have stable interface (in C lang) and foo should be depending on
one of the stubs libs of bar. Only libraries in the same APEX as foo can
link against non-stub version of it.
Bug: 112672359
Test: m (cc_test added)
Change-Id: I2488be0b9d7b7b8d7761234dc1c9c0e3add8601c
recovery_available property is required in cc_genrule. Specifically,
we will mark libminijail as recovery_available:true as part of building
adbd and other stuffs for recovery. Some source code of libminijail is
created via cc_genrule, so we need recovery_available in the module
type.
Bug: 79146551
Test: m -j
Change-Id: I0cf0d9b1004dda055373573e5c5a7debd112685f
cc_genrule is the same as a normal genrule, but can depend on other cc
modules (like cc_object).
Test: mmma external/minijail
Change-Id: I8df87665c7bdc76ce89c92755c054f967a818e57
