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
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
There is no longer a reason to restrict dylibs on product, make them
available.
Bug: 204303985
Test: m
Change-Id: I315d22307f64d02633940f30ae600c63f16f0e7a
Adds dylib support for vendor and recovery images.
This changes the default linkage for vendor and recovery images to
dylib, which matches the platform default linkage. This also means that
by default, dylib-std variants are used for rlib dependencies.
Bug: 204303985
Test: Soong tests.
Test: m dist vendor-snapshot
Test: RECOVERY_SNAPSHOT_VERSION=current m dist recovery-snapshot
Change-Id: If84074b8615a70c45e7e162abeb853dc8c34d49a
The prohibition on Rust dylibs outside system still stands, but rlibs,
rust_ffi_static, and binaries will all work fine.
Test: m nothing (new soong tests added by this commit)
Test: Created sample product_specific rust_binary, checked out/ location
Bug: 165791368
Change-Id: I6453274064bb24b2019f38e57fc0d09b7c0fcf30
InstallIn functions must be hooked up not only to install to special
images, but also to receive special handling by android/arch.go such
that some images are implicitly multilib: first.
Also hook up more product details.
Bug: 178565008
Bug: 165791368
Test: lunch aosp_arm64; m
Change-Id: I1980d5aa9d55f78c222b98d60a404cd6ea5abbfb
Adds support for snapshotting Rust rlibs. This allows us
vendor-specific code that uses rlib-only linkage until dylib
snapshot support is added.
Bug: 184042776
Test: m nothing # new Soong tests pass
Test: Example test Rust vendor module builds
Test: m dist vendor-snapshot # includes rlibs
Change-Id: I4976d3e1efec0ee778cc97730d45be471dffb678
Adds support for platform vendor_available Rust FFI libraries and
binaries to be included in the vendor snapshot.
Because rlib and dylibs are not yet in snapshots, libstd cannot be
included in a vendor snapshot. As a result, vendor-specific Rust code
can't be guaranteed to work with the platform-provided vendor_available
modules built with a newer toolchain. For now, a check is added
indicating vendor-specific Rust code is unsupported.
This changes the linkage for vendor variants of these modules to default
to rlib linkage since dylibs cannot be included in the snapshot yet.
Bug: 184042776
Test: m nothing # new Soong tests pass
Change-Id: I502eaa4bb962eb87ff868fcf49b435f0d2f982e6
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
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
This adds Rust vendor image support for all module types except
Rust prebuilts.
Bug: 184042776
Test: New Soong tests.
Test: Example cc_library vendor module can depend on rust_ffi_shared.
Test: Example rust_library vendor-only module compiles.
Change-Id: Iaa30ad51fdaedcbf14687da5472581f6af62ff59
Refactor rust to use and implement the new common image mutator
interface to handle future image mutations.
Bug: 184042776
Test: m nothing
Change-Id: If6a85e2b8c6a1969d62264eaea6c6b53cae9c039
Similar to our vendor support, this adds support for linking rust static
libraries to vendor ramdisk cc modules.
A bug fix is also included where a restriction against setting rust_ffi
vendor-specific was not being enforced.
Bug: 179397942
Test: Example modules link, Soong tests pass.
Change-Id: I737cdf0c2f49ab349bcea2a0429e6298ebc1313e
The module names for vendor and product variants have the image
variant suffix to avoid conflict with the core modules. It requires
updating the module names in the dependency tree with the suffixes.
We had a hidden bug that used the original module properties to
update the names of its dependent modules.
Also, it must cover the product variants modules.
Test: updated cc_test.go and build
Change-Id: I6b4ea062d13c8fac1e699138d44376e52e0d7852
'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
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
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
We don't have Rust VNDK support yet, but static linkage can be
supported in the interim. This adds support for making rust_ffi_static
libraries available to CC vendor modules.
Since rust_ffi_static modules will link against rlibs, we allow rlib
linkage into vendor as well, but only for the variants which use the
rlib libstd.
Bug: 172525289
Test: New Soong tests pass
Test: Example vendor cc_binary links against rust_ffi_static module.
Change-Id: Idf3aeb51e32293866f1ad965e329aa6b9e0bf2ef
