As of VNDK deprecation, Device VNDK version should no longer be used
from build. This change removes all references on Device VNDK version
and related logic with it.
Bug: 330100430
Test: AOSP CF build succeeded
Change-Id: Ibc290f0b41e8321f80c75c69f810223989af68dc
Existing snapshot code will no longer work from VNDK deprecation, but it
can give confusion to users if we keep code for the snapshot - and it
adds complexity on existing code while it is not in use. This change
removes all snapshot definition except host snapshot and its usage.
Bug: 330100430
Bug: 332986564
Test: AOSP CF build succeeded
Change-Id: Ieb6fa43d5e38315c662ce997bc305b744b367c24
Platform VNDK version is no longer available based on VNDK deprecation.
Remove all code using Platform VNDK version.
Bug: 330100430
Test: AOSP CF build succeeded
Change-Id: I7d0f7e23eff5d153346890f242a94b78bad6736b
UseVndk is a function to check if the module can use VNDK libraries, but
this function was also used to check if the module is installed in the
treblelized partition (vendor or product). As of VNDK deprecation,
UseVndk funtion will return false even when the module is installed in
vendor / product partition, so we need a separated function to check
this. This change introduces a new function 'InVendorOrProduct' which
replaces UseVndk based on its usage.
Bug: 316829758
Test: m nothing --no-skip-soong-tests passed
Change-Id: Ic61fcd16c4554c355f6005894a4519b044b27fe5
Current CC/Rust Image variations are generated with target VNDK version.
However, this is no longer valid if VNDK is deprecated. This change
generates image variation without version ("vendor", "product") if VNDK
is deprecated.
Bug: 316829758
Test: m nothing --no-skip-soong-tests passed
Test: aosp_cf_x86_64_phone build succeeded
Change-Id: I2387ed8a2632bfd9462621f882a947695ae1653d
Overriding android.ModuleContext's implementations of *Specific()
methods in cc.moduleContext and then passing that back to
android.PathForModuleInstall to affect the install path causes
problems if android.ModuleBase.GenerateBuildActions also tries
to call android.PathForModuleInstall directly with the
android.ModuleContext as it gets a different result.
Add InstallIn* methods to the android.Module interface, implement
default versions in android.ModuleBase, and override them in
cc.Module and rust.Module. Use them in android.PathsForModuleInstall
to allow the module to customize the behavior directly.
Test: TestInstallPartition
Change-Id: I7840e07eae34ac4f4d3490b021143d5f33a83626
This is to handle libz special case. libz has stubs but not an LLNDK.
So, libz.vendor should be treated as non-stub-providing libraries and
Vendor APEX should bundle it if it's used by its contents.
libz will set no_stubs for vendor/product variants.
Bug: 313806237
Test: go tests ./apex/...
Change-Id: I10759d7073838909126f8bfe87654f11aa02fd32
PRODUCT_PRODUCT_VNDK_VERSION is set to 'current' by default. Now, we
can generate product variants without checking the
PRODUCT_PRODUCT_VNDK_VERSION build variable. Remove reading the
PRODUCT_PRODUCT_VNDK_VERSION variable from soong and generate product
variants by default.
Bug: 302255959
Test: m
Change-Id: I9a9b2076f4367c5ce9a393bbb206f8dee3884bd8
Current snapshot definition is located in the CC module, so it is
difficult to capture non-CC module (such as prebuilt_etc) to the
snapshot. Separate general snapshot definition from cc so other modules
can also define its own snapshot.
Bug: 192430376
Test: m nothing passed
Change-Id: Ifb69fb3d2ec555b629aa31ec03e7ce5831fd3063
Export additional fuctions, structs, and interfaces from cc for use in
the rust package to allow for rlib snapshotting.
Bug: 184042776
Test: m nothing
Change-Id: I4c53b9378d5d5b5973dbd23ab692cdfb2ede60b9
This CL exports and refactors some cc vendor-snapshot related functions
so they can be reused by rust modules to support vendor snapshotting.
Bug: 184042776
Test: m nothing
Change-Id: I12706e62ce0ac3b2b4298085fafc1d77b8e0a0c4
VNDK snapshots newer than v30 have LLNDK stub libraries. In that
case, the vendor variant for the BOARD_VNDK_VERSION must not be
generated from the LLNDK modules. They are already provided by the
VNDK snapshots.
Generate the vendor variant of the BOARD_VNDK_VERSION only if
BOARD_VNDK_VERSION has an integer value less than or equal to 30.
Bug: 187963715
Bug: 181815415
Test: m nothing
Change-Id: I31e90f4d7e7678c45558f6bf987f5582a4c34f78
A module will be installed to /debug_ramdisk if debug_ramdisk is set to
true.
This is a reland of f84e9c05e2, with a fix
that removes /first_stage_ramdisk.
Bug: 184004542
Test: soong test
Change-Id: I739de63cfec6b0fec5a90f7c4741fc4d884d209c
Remove the global list of vendor public library modules used to rewrite
dependencies from the vendor module to the stubs for system modules,
and replace it with building the stubs directly in the system variant
of the vendor module.
Bug: 178231622
Test: vendor_public_library_test.go
Change-Id: I826e69ffd507d7e85fa3d4d85b5157428c642143
Remove llndk_library in favor of cc_library with llndk.symbol_file.
Bug: 170784825
Test: m checkbuild
Test: TestLlndkLibrary
Change-Id: I43580976589a7a2a176d7442be53fa043c0c8324
Set llndk.llndk_headers: true to allow a cc_library_headers
module to be used by a cc_library module with llndk.symbol_file set.
Bug: 170784825
Test: TestLlndkHeaders
Change-Id: Ib65a4b70717dc9a54ae30f2991485bb1bb9b8409
This reverts commit f84e9c05e2.
Because this breaks the usage of boot-debug.img and
vendor_boot-debug.img
Bug: 185970130
Bug: 185990198
Test: make bootimage_debug
Change-Id: I7886c971982faae1d5bc34688643de8d94d6e201
A module will be installed to debug_ramdisk (or
debug_ramdisk/first_stage_ramdisk if recovery as boot is true) if
debug_ramdisk is set to true.
Bug: 184004542
Test: soong test
Change-Id: Ic5a4d27407e506fffa462de2149e0785f11b2ac7
As part of adding Vendor support to Rust, refactor the image mutator in
CC to a new common image mutator interface so this logic can be reused
across both CC and Rust.
Bug: 184042776
Test: m nothing
Change-Id: Ia55d5ad840db7cf1a64d6c65ed86487230cb8742
cc modules have complex image variant settings. To avoid setting
wrong partitions to modules, add a test to check the install
partition.
Bug: 184885453
Test: m nothing
Change-Id: I080661335f2da7281d6e6a0d2fedd1fcecb4b2cb
In aosp/531337 support for installing prebuilts to vendor and odm
partitions was introduced.
Since aosp/1542687 allowed installing vendor variants to odm, we
started to see device_specific cc_prebuilts not installed to odm
at all.
The reason for this is the InVendor condition is true for the
device_specific module and VendorVariantToOdm is false in cases
outside the one it was designed for, so SocSpecific returns true and
the module gets installed to vendor instead of odm.
We need to check if we're specifically building a vendor variant
before triggering this VendorVariantToOdm logic.
Bug: 184885453
Change-Id: I05be06a61c5fc3f2f72599eb4746c9c0523b956e
Propgate the Android.mk suffix from source modules into the snapshot so
that it can be used for the prebuilt modules.
Bug: 177098205
Test: vendor_snapshot_test.go
Change-Id: Iea151dc91395f714fbcad1df3a6fd0874e5455d9
'vendor_available: true' creates a vendor variant from a system
module. The vendor variant of the module is installed to /vendor.
However, we may want to install the vendor variant to /odm, instead.
'device_specific: true' does not work for this purpose because
'vendor_available: true' is allowed only for the system or product
modules to create a vendor variant. But 'device_specific: true'
itself creates a vendor variant that may not work with
'vendor_available: true'.
To install the vendor variant to /odm, we define a new property
'odm_available'. 'odm_available' is exactly the same as the
'vendor_available' except the install path of the vendor variant.
By defining 'odm_available: true', the vendor variant of the module
will be installed to /odm or /vendor/odm instead of /vendor.
Bug: 176147321
Bug: 176079978
Test: check if a module with 'odm_available: true' is installed to
/vendor/odm
Change-Id: I2d16bd2c515796597b2fbd1eb66f7c2736434697
Adds a PlatformSanitizable interface which both CC and Rust can
implement so that the sanitizer mutators in CC can sanitize Rust
shared/static libraries appropriately.
Bug: 147140513
Test: m nothing
Change-Id: Ib31103b6c4902a4d5df2565c0d7c981298d100a3
The LLNDK vendor variants need to exist even when the VNDK is not
being used in order for the next patch to list them once the global
maps are removed.
Bug: 176904285
Test: m checkbuild
Change-Id: Ib29ede455d5b6a4b7d3f4685db8fba6d32025314
In case of VNDK, 'vendor_available: false' had a special meaning that
defines VNDK-private libraries. It is not trivial because not
defining a boolean property means 'false' normally. To avoid the
confusion replace it with the 'vndk.private: true' for VNDK-private
libraries and 'private: true' for LLNDK-private libraries.
All VNDK libraries must define 'vendor_available: true' and may have
'vndk.private: true' if they are VNDK-private.
With this change '(vendor|product)_available: false' is the same as
not defining the property.
LLNDK-private must define 'private: true' instead of
'vendor_available: false'.
Bug: 175768895
Test: build
Change-Id: I57fbca351be317257d95027f3cdcdbbe537eab23
Some VNDKs will be available to product modules by adding
'product_available' property. These VNDK libs will be listed in
vndkproduct.libraries.txt and tracked by the build system for the
changes. The product available VNDK list will be frozen by the
release process.
Bug: 174323911
Test: build
Change-Id: Ie1b085851413a8f2273925fefdc14fec3bfc7892
To define VNDK-private libraries, we used `vendor_available: false`.
Because of it, `vendor_available == nil` had different meaning from
`vendor_available: false` for the VNDK libraries.
To clarify this, we change the logic for defining VNDK-private
libraries which was:
cc_library {
name: "vndk_private",
vendor_available: false,
product_available: false,
vndk: {
enabled: true,
},
}
It must be replaced with
cc_library {
name: "vndk_private",
vendor_available: true,
product_available: true,
vndk: {
enabled: true,
private: true,
},
}
Bug: 175768895
Test: m nothing
Change-Id: I81769f57c2231e54b682a28e4b82631ab9f3d390
With this patch, `vendor_available: true` will no longer creates
product variant. Instead, modules need to set `product_available:
true` if they have to be available to product vanriant.
If both properties are defined for VNDKs, they must have the same
values.
Bug: 150902910
Test: m nothing
Change-Id: I28fb6886e6114583227a31151136627c8516ac9c
Rewriting LLNDK dependencies with .llndk suffix requries referencing
a global data structure to determine if a given library is an LLNDK
library and therefore needs the .llndk suffix. References to
global data structures from mutators must be removed to support
incremental Soong analysis. Instead, move the LLNDK stubs rules
into the vendor variant of the implementing cc_library so that
the original name can be used.
As an incremental step, the llndk_library modules are left in
place, and the properties are copied into the cc_library via
the dependency specified by the llndk_stub property. A followup
will move the LLNDK properties directly into the cc_library and
delete the llndk_library modules.
The global list of LLNDK libraries is kept for now as it is used
to generate the vndk.libraries.txt file.
Bug: 170784825
Test: m checkbuild
Test: compare Soong outputs
Test: all Soong tests
Change-Id: I2a942b21c162541a49e27b2e5833c9aebccff1d0
SkipInstall is actually primarily used to prevent making a module
visible to Make, rename it and add new SkipInstall that actually
skips installation without affecting Make.
Call c.SkipInstall() for uninstallable cc modules to allow calling
c.installer.install, which will collect PackagingSpecs for
uninstallable cc modules, allowing them to be used by genrules.
Bug: 124313442
Test: m checkbuild
Change-Id: I8038ed5c6f05c989ac21ec06c4552fb3136b9a7a
Refactors parts of CC to prepare for preliminary support for using Rust
static libraries in vendor images. Some previously private functions are
made public, and additional functions are added to LinkableInterface so
GetMakeLinkType can be passed a LinkableInterface.
Bug: 172525289
Test: m
Change-Id: I5fda48e79532fe9ceab255e18d910af58048a123
To make a module available to product variants, it must define
`product_available: true`. `vendor_available: true` will not create
product variants any more.
However, in this CL, we don't change the behavior of
`vendor_available` property. It still creates both variants. After we
update all Android.bp files that need to provide product variants
with `product_available: true`, we may upload the remaining patches.
Bug: 150902910
Test: lunch aosp_arm64-userdebug && m
Change-Id: I0fd5be7bbae2c45d5cab3c3c2ca49f53a9b6f975
Add vendor_ramdisk_available and vendor_ramdisk attribute to
various rules. When a vendor_ramdisk variant of a module is
generated, it is installed to $OUT/vendor-ramdisk.
It is similar to a ramdisk image.
Test: m nothing -j
Change-Id: Ib2d16459f3094dbe21c3bdb7c016cb4b2bf62765
