My change to clean up obsolete copy headers would remove valid ones if
thhe LOCAL_COPY_HEADERS_TO path wasn't cleaned. I'm seeing this most
with values that just end in '/', so we end up with a '//' in the path,
which isn't textually equivalent, and we remove it.
Test: No longer seeing constant removals on internal products
Test: Set LOCAL_COPY_HEADERS_TO := ..
Test: Set LOCAL_COPY_HEADERS_TO := ../foo
Test: Set LOCAL_COPY_HEADERS_TO := /foo
Change-Id: Idbeeb207a2bb2a8da766473dbded877cec7c9cc1
Use ro.product.vndk.version to show the VNDK version that the product
partition is using.
When PRODUCT_PRODUCT_VNDK_VERSION is set, add ro.product.vndk.version
in /product/build.prop.
If PRODUCT_PRODUCT_VNDK_VERSION is "current", ro.product.vndk.version
will have the VNDK version in PLATFORM_VNDK_VERSION. Otherwise, it
will have the value defined in PRODUCT_PRODUCT_VNDK_VERSION.
Bug: 144534640
Test: Check if /product/build.prop has "ro.product.vndk.version"
Change-Id: If5e7e3a6c155de45f88f68700f16175656896afe
Dist ramdisk-recovery.img and misc_info.txt. This is useful for
re-creating boot.img without having to download a huge target_files zip
file.
Change-Id: I2e1c1d547c95ca3433f89c68428c0c98fa4d19cd
The check is implemented in Soong via the apex_available property.
For a module that should be in the APEX named "foo" and shouldn't be in
any other APEX and also in the platform (the non-updatable part), the
property can be set to "foo" (without "//apex_available:platform")
to express the restriction and then Soong will enforce it.
Bug: 128708192
Test: m
Change-Id: Ia1aaaacd685f466447b61deae2849cb0aa83def3
As we have base_system_ext.mk for the packages in system_ext
partition, move the group and passwd files for system_ext partition
to base_system_ext.mk.
Bug: 141658360
Test: mainline checks pass
Change-Id: Iff50482b90ff9877a58c54c8149014e8c103a3c6
The test was to ensure that bionic libs are not installed to the
non-updatable part of the platform (e.g. system/lib). However, for
bionic libs, we actually have been installing them for bootstrapping.
Specifically, they are installed to /system/lib/bootstrap, not
/system/lib. The test has passed just because it didn't look into
/system/lib/bootstrap. Removing the unnecessary check.
Bug: 128708192
Bug: 133140750
Test: m
Test: m out/target/prduct/$(TARGET_DEVICE)/system/lib/libc.so doesn't
work
Change-Id: I93cbd74972cdd2daea45612136d5133fa49ab76a
PRODUCT_PRODUCT_VNDK_VERSION sets the VNDK version for product
partition. It may have "current" to use the PLATFORM_VNDK_VERSION.
If PRODUCT_PRODUCT_VNDK_VERSION is set, the native modules in product
partition are enforced to use VNDK's only from the system partition
as BOARD_VNDK_VERSION did to vendor partition.
Bug: 144534640
Test: build
Change-Id: I7ea148f0f8b7e44be7810adcacb30702d66831f1
Use apex_available property to prevent modules that are only for the
NN apex from being used outside of the APEX.
Bug: 128708192
Bug: 133140750
Test: m
Change-Id: I57fe857d99088ef08e065dd2a3fc5a9389b6eb0f
Use apex_available property to prevent modules that are only for the
conscrypt apex from being used outside of the APEX.
Bug: 128708192
Bug: 133140750
Test: m
Change-Id: I08ca6cd8e5e4a254d9dd62695ee3ed317503d874
Compared with board_config.mk and found this one is missing.
Also add docs to explain where are these values from.
Test: pass
Change-Id: Ic22d75a538657bd286edcae6d95f9ee462911975
boringssl_self_test is a required module of the conscrypt.jar.
Therefore, it was installed along with the conscrypt.jar. However,
conscrypt.jar is no longer available for the platform but only for the
conscrypt APEX. The problem here is that the conscrypt APEX having
conscrypt.jar doesn't carry its 'required' property. As a result,
boringssl_self_test is missing. This is b/146549048.
Until the bug is fixed, manually adding the test binary to
PRODUCT_PACKAGES to ensure that it is installed always.
Bug: 146549048
Test: m, device boots
Change-Id: I72dbc51c267f8d8683b70c07ae726c3a3eba0aea
Original Commit Message:
"""
Rename modules that are APEX-only
The renamed modules are only available for APEXes, but not for the
platform. Use the <module_name>.<apex_name> syntax to correctly install
the APEX variant of the modules.
"""
Reason for revert: Build Cop - Breaks about 15 AOSP targets, with high confidence due to these changes being the only non-robot changes in those builds.
Reverted Changes:
I190ce2d10:Use apex_available property
I990e0a67e:Use apex_available property
I0d1295683:Revert "Avoid duplicated classes for boot dex jars...
I5fb725403:Find the jar libraries in APEX from the correct pa...
I322b1efcc:Rename modules that are APEX-only
Ifa2bd0f8f:Use apex_available property
Iac6533177:Use apex_available property
Ie999602c6:Use apex_available property
I2a3d73397:Use apex_available property
Ic91bcbb9a:Use apex_available property
Ia6c324eed:Use apex_available property
I964d0125c:Use apex_available property
Change-Id: I8961702cfb414ebec55014f57e0be3347b34cea9
Original Commit Message:
"""
Rename modules that are APEX-only
The renamed modules are only available for APEXes, but not for the
platform. Use the <module_name>.<apex_name> syntax to correctly install
the APEX variant of the modules.
"""
Reason for revert: Build Cop - Breaks about 15 AOSP targets, with high confidence due to these changes being the only non-robot changes in those builds.
Reverted Changes:
I190ce2d10:Use apex_available property
I990e0a67e:Use apex_available property
I0d1295683:Revert "Avoid duplicated classes for boot dex jars...
I5fb725403:Find the jar libraries in APEX from the correct pa...
I322b1efcc:Rename modules that are APEX-only
Ifa2bd0f8f:Use apex_available property
Iac6533177:Use apex_available property
Ie999602c6:Use apex_available property
I2a3d73397:Use apex_available property
Ic91bcbb9a:Use apex_available property
Ia6c324eed:Use apex_available property
I964d0125c:Use apex_available property
Change-Id: I39316f9ef2b0cd6c0a347f6b51d011748d0681aa
The intention of userspace_reboot.mk is to provide a default
configuration (e.g. userspace reboot watchdog timeout) for devices that
are supporting userspace reboot feature. So far it only contains one
property that tells whenever device supports userspace reboot, more to
follow in separate CLs.
Test: flashed blueline, checked that property is set to true
Bug: 135984674
Change-Id: I32e6281ccc36236ec4fa5cde299753b6e0ece181
Create com.android.tethering apex to pack Tethering.apk and
framework-tethering.jar together.
For go devices, tethering would run in system server process by
InProcessTethering.apk
Bug: 144320246
Test: -build, boot
Change-Id: Id2d68117e99173682908168e99ee28670bd71871
Merged-In: Id2d68117e99173682908168e99ee28670bd71871
* Split warning patterns into *_warn_patterns.py
* Split project list into android_project_list.py
* Split out the Severity class, to be changed later
* Split core of warn.py into warn_common.py and
leave only platform dependent code in warn.py.
This allows the core logic be used with different
parallel processing libraries.
* Old warn.py just calls -m warn.warn.
Test: path_to_build/tools/warn.py build.log
Test: warn.py --url=http://cs/android --separator='?l=' build.log > warnings.html
Change-Id: I6734e4472a21018cd5ce06d549f6dbca24f4de54
These packages are now available in the shim apex package, which is made
available in both flattened and unflattened apex configurations.
Bug: 138429615
Test: atest CtsPrivilegedUpdateTests CtsPermissionTestCases
CtsStagedInstallHostTestCases; (on both flattened and unflattened
configurations)
Merged-In: I03939f6c3e711d5887da201e32173f86a6b0289e
Change-Id: I03939f6c3e711d5887da201e32173f86a6b0289e
When setting target out path at root(/product, /system_ext), either file
system type or prebuilt image must be set. If not, we'd rather raise an
error.
Without raising an error, the artifacts in these directory are not
included in any image.
And also, extract these logics into function, and check product, odm, system_ext
For now, exempt vendor image because of some targets with prebuilt
vendor image.
Bug: 137169253
Test: set TARGET_COPY_OUT_PRODUCT := product
BOARD_PRODUCTIMAGE_FILE_SYSTEM_TYPE :=
BOARD_PREBUILT_PRODUCTIMAGE :=
and then check if it causes an error.
Test: set TARGET_COPY_OUT_PRODUCT := system/product
BOARD_PRODUCTIMAGE_FILE_SYSTEM_TYPE := ext4 or
BOARD_PREBUILT_PRODUCTIMAGE := someimage.img
and then check if it causes an error.
Change-Id: Ibf0f7838111075ba3649e198e5649aa7e8e29d7c
JAR libraries in the ART and conscrypt APEXes are no longer built for
the platform. Therefore, the path out/target/common/<name>_intermediates
does not exist. Instead use the path
out/target/common/<libname>.<apexname>_intermediates paths for those
APEX-only jars.
Bug: 128708192
Bug: 133140750
Test: m
Change-Id: I5fb725403ac22198e5ce6d77ca97c5f3392fabfd
Use apex_available property to prevent modules that are only for the ART
apex from being used outside of the APEX.
Bug: 128708192
Bug: 133140750
Bug: 129006418
Test: m
Test: m libnativeloader doesn't install anything. (because it doesn't
have "//apex_available:platform".
Test: Add "libnativeloader" to shared_libs of "libvndksupport" which is
installed to /system/lib. Then the build fails with following error:
error: system/core/libvndksupport/Android.bp:3:1: module
"libvndksupport" variant "android_arm_armv8-a_core_shared": depends on
//art/libnativeloader:libnativeloader which is not visible to this
module
Change-Id: I964d0125cfedb454a60c098bf1a1797201d5dd40
Linkerconfig should be built as static, but recovery does not have
enough space for static binary. As recovery linker configuration is
quite static and simple, this can be generated from build time. As a
first step linkerconfig binary should be removed from recovery.
Bug: 146384333
Test: m -j passed && crosshatch recovery worked with this change
Change-Id: Ie82da787424c5d1ddd2724808aa2323ea881f75b
Dan Willemsen