When TARGET_VNDK_USE_CORE_VARIANT is set to true, the vendor variant of
VNDK libraries are by default not installed. Instead, the core variant
will be used by vendor binaries at runtime.
To ensure the core variant of VNDK libraries are installed, we also add
a flag LOCAL_VNDK_DEPEND_ON_CORE_VARIANT to indicate that the vendor
variant module depends on the core variant module. This flag should be
set by Soong for all VNDK libraries without the vendor variant
installed. When the flag is set, the vendor variant binary is also
compared against the core variant binary to ensure they are
functionally identical.
As we are merging the two variants for some libraries, we need a new
link type to denote a module is usable as both native:vndk and
native:platform. We add native:platform_vndk for this.
Bug: 119423884
Test: With the corresponding Soong change, build with
TARGET_VNDK_USE_CORE_VARIANT set to true.
Test: Add a dummy VNDK library and a dummy vendor binary that depends
on it. Build with no-vendor-variant VNDK and check the core
variant is installed.
Test: Add conditional compilation based on __ANDROID_VNDK__ in the
dummy VNDK library and check build fails.
Change-Id: I40000f2728e8193212113c1ee950e9d697f2d40d
This is similar to module-built-files, except that it only returns
files built for the target, not the host.
Bug: 119423884
Test: Build with the no-vendor-variant VNDK change that uses this
function.
Change-Id: I2a3d99003b05999eae01c0b90bb62b5263d65592
Skips the step that invokes dot from the build, and instead
prints suitable commands to convert to image formats.
Bug: 114729998
Test: m product-graph
Change-Id: I172e1a792c32c2685d2f439f414dc66267ed6b83
Currently system_other AVB public key is placed in system.img.
However, this makes it's harder to have a *generic* system.img
across different product configs. Moving the key to /product
partition to allow more product-specific AVB keys.
Device board config can add /product/etc/fstab.postinstall,
to mount system_other with this key in /product. It can specify
different mount options, file systems, verity settings, etc., in
this product-specific fstab as well.
Bug: 123611926
Test: `make productimage` checks the following is generated.
$OUT/product/etc/security/avb/system_other.avbpubkey
Also checks it's included in $OUT/installed-files-product.{json, txt}
Test: run the following command and checks that
PRODUCT/etc/security/avb/system_other.avbpubkey is updated:
./build/tools/releasetools/sign_target_files_apks \
--avb_system_other_algorithm SHA256_RSA2048 \
--avb_system_other_key external/avb/test/data/testkey_rsa2048.pem \
out/dist/*-target_files-*.zip signed-target_files.zip
Change-Id: I6804f29941bec54375d80bd68a5aedb5c23b842e
The soong-only variable is used to specify the location where the symbol
file is located. When unspecified, LOCAL_MODULE_PATH is used instead as
before.
This is needed when the path that a file is installed to is different
from the path that the file is accessed from at runtime. For example, if
TARGET_FLATTEN_APEX=true, a file lib/libX.so in an APEX com.android.foo
is installed to /system/apex/com.android.foo/lib/libX.so. However, it's
runtime path is /apex/com.android.foo/lib/libX.so as
/system/apex/com.android.foo is bind-mounted to /apex/com,android.foo.
Bug: 120846816
Test: m and inspect that symbol files exist under
$(PRODUCT_OUT)/symbols/apex/com.android.runtime/
Change-Id: I1b39f6e0cde115d442f14380c365796feff3437b
This is part of prebuilt_internal.mk refactoring work and also a
preliminary task to design and implement its Soong counterpart.
Test: built and flashed an image for a Pixel device + TreeHugger
Change-Id: I89b13b1e0a2780b02fda7ee888e73052ac1abd9c
Like If1f817d855cbe329b83caee9fdd68c2cce55f02b, but for
PRODUCT_PACKAGES, which is only enabled for a few builds.
Also share the ALLOW_MISSING_DEPENDENCIES check with the host
version.
Test: m product-graph
Change-Id: Iab55072e7d7c0fc9f4680cc515e139a5214dc3b4
After migrating the primary install location of test modules into a
generic testcase folder. All test modules will install to
out/target/product/<product>/testcase/<module_name>/ if they don't
specify their LOCAL_MODULE_PATH.
But the dependent test module should also be copied to testcase
folder even its LOCAL_MODULE_PATH be set.
BUG: 128815093
Test: 1. vi cts/tests/signature/api-check/Android.mk
add LOCAL_MODULE_PATH for cts-hiddenapi_flags-csv
2. m CtsHiddenApiBlacklistDebugClassTestCases
Then, hiddenapi_flags.csv should also be copied to testcase
folder.
Change-Id: Iff872447348e74b2728e0913d04e46ccbaa4e972
After I25163e91886cea6941afa25cdb529ed053278dcb there is no longer
a dependency on $(LOCAL_BUILT_MODULE) for boot jars, as boot.art
is installed instead. Add a dependency from boot.art to
$(LOCAL_BUILT_MODULE) so that $(LOCAL_BUILT_MODULE) and its
dependencies (which may include jacoco-report-classes.jar) is
copied for every build.
Fixes: 127702563
Test: forrest
Change-Id: I4db2d1f5fe2e1141fe93317cd7a2a58a33f8fbff
This change splits the LOCAL_SOONG_RRO_DIRS into two,
representing RRO dirs that originated from device and
product overlay configs, respectively.
Also plumb the device/product configs in separately.
Bug: 127758779
Test: verify noop on presubmit targets
Change-Id: Iddee1b4d7303b7ecaeced91216ea82fe29123770
Previously:
if (DAP && !BUILD_SUPER) error;
Now:
if (BUILD_SUPER && !DAP) error;
This allows DAP devices to disable building super partition when the OEM
doesn't want to. The ability to build super partition shouldn't be
a requirement of enabling DAP; rather, building super partition requires
DAP to be enabled.
To do this on a device, PRODUCT_BUILD_SUPER_PARTITION should be set
to false explicitly. If it is unset, it will use the value of
PRODUCT_USE_DYNAMIC_PARTITIONS.
Bug: 127687287
Test: set PRODUCT_BUILD_SUPER_PARTITION to false and build dist
Change-Id: I25f1866e61d73affb445c1aec042cf53aac93583
A few tweaks to make it easier to extend to generating RROs in
multiple partitions:
- deduce the module name inside generate_enforce_rro
- dedup rule definition
- tweak framework-res check to use source module name instead
Bug: 127758779
Test: verify noop on presubmit targets
Change-Id: I2f0d6270b21f5427c372c04a5c6e7fb712e72a9a
Make the runtime vs static resource overlays a little clearer.
This will help adding more logic around determining if an RRO
needs to be generated in /vendor, /product or both.
Bug: 127758779
Test: verify noop on presubmit targets
Change-Id: I43111a1d9bb3405c559faaef56a75a5ad7672ba0
Make it a bit clearer what this code is intended to do.
Bug: 127758779
Test: verify noop on presubmit targets
Change-Id: Ic405fc5d4601b9f0a91b4d24caa06f279267c51a
ro.postinstall.fstab.prefix might be either "/system" or "/product",
to decide the location of the fstab.postinstall, used to mount
system_other partition on A/B devices.
{ro.postinstall.fstab.prefix}/etc/fstab.postinstall
Bug: 112103720
Test: factory reset and boot device, checks cppreopt logs
Change-Id: Ib1e282752c37713e2220239f4f903453ce3c8bab
superimage-nodeps and supernod depends
on images from $(ANDROID_PRODUCT_OUT) (not from
target files package). It doesn't rebuild source
images if they are present.
A typical workflow is:
m -j
# change code in system
m snod -j
m supernod -j
Test: For non retrofit, run:
`m snod -j; m supernod -j`
Fixes: 128321505
Change-Id: Ib8c011cadb9c0cd334234aef39f19be6a48fee62
