This CL adds a list of components to enable CFI for on Arm64 product
configs.
This list is not directly used anywhere, but product configs can
inherit this to easily enable CFI for all tested components.
Bug: 63926619
Test: Inherit the product config; m -j60; verify that CFI is enabled
Change-Id: I56b6dfd5495639974a19623bc7aea9efeb9acff6
The function along with LOCAL_TEST_DATA are very helpful, but it took me
some extra minutes to figure out the issue with the arguments.
Test: N/A
Change-Id: I2c2878fca99ab77ea881d86635c27c34f9ecf855
This is a list of modules which should be installed by default, but only on
builds which are set up for Address Sanitizer (via SANITIZE_TARGET=address).
Additionally, add sanitizer-status to PRODUCT_PACKAGES_DEBUG so that all
userdebug builds will have the binary. Currently, the module has the
"debug" tag but it may go away in the future.
Change-Id: I0bea4faf9c2a65380292471437e51ef8324b5af3
Normally, when building with VNDK, platform modules are not allowed to
link against vendor libraries, because the ABI of the vendor libraries
are not guaranteed to be stable and may differ across multiple vendor
images.
However, the vendor public libraries are the exceptions. Vendor public
libraries are vendor libraries that are exposed to 3rd party apps and
listed in /vendor/etc/public.libraries.txt. Since they are intended to
be exposed to public, their ABI stability is guaranteed (by definition,
though it is up to the vendor to actually guarantee it).
This change allows platform modules to link to vendor public libraries.
When the name of a vendor public libraries (whose stub is defined via
vendor_public_library in Android.bp) is listed in
LOCAL_SHARED_LIBRARIES, it is actually linked to the stub library which
is available to platform modules.
Bug: 74275385
Test: m -j
Change-Id: I063b43431196190b59332b1bcad59f267073f89f
This CL changes PRODUCT_CFI_INCLUDE_PATHS to be included in all
product configs by default. To maintain the status quo, the sanitizer
logic has been modified to only respect this product config for Arm64
devices (where this was previously enabled).
Bug: 63926619
Test: m -j60 # the device still has CFI enabled thanks to the default
opt-in
Change-Id: I22788d92be881d3290568488f5458c85e02ee8c7
If there are no symbols to keep (i.e. all function symbols are also in
the dynsym table), then the $@.keep_symbols file has size 0.
When objcopy parses a --keep-symbols file, it has a special case for
0-sized files where it silently fails (exits with status 1, no error
message). On the other hand, objcopy is happy with a file containing no
symbols, as long as there is some whitespace or a comment. Avoid the
special case by appending a newline to keep_symbols.
Bug: b/62815515
Bug: b/77242617
Test: manual
Change-Id: I348593164fe78ece5c85db3d28c7daccce3a52fb
AUX modules are not necessarily using the same toolchain
as the TARGET modules. they don't have to depend on
this library.
Change-Id: Ib50cf0eb26c257ae3eb69a43aa1a12c41d5d39b0
Signed-off-by: Alexey Polyudov <apolyudov@google.com>
This variable is equal to the sepolicy version for tip-of-tree development.
Bug: 74622750
Test: ./build/soong/soong_ui.bash --dumpvars-mode -vars PLATFORM_SEPOLICY_VERSION
is unchanged.
Change-Id: I2a62f7399fe245ec0c681e9a789da6b1b83dd9d8
When BOARD_SYSTEMSDK_VERSIONS is set, any apk in the vendor partition
is force built against SystemSDK (or Android SDK if LOCAL_SDK_VERSION is
set to current). However, there should be one exception to this: RRO for
framework-res.apk. This is because the RRO is currently overriding
resources that are not part of SystemSDK. Until SystemSDK is expanded to
cover resources that are eligible for overriding, let's allow the direct
dependency from RRO to framework-res.apk.
Bug: 35859726
Bug: 76398918
Test: m -j
Merged-In: Ib9981b107d78691eef21f4525ebdac9866d5c50e
Change-Id: Ib9981b107d78691eef21f4525ebdac9866d5c50e
(cherry picked from commit d8c4c30ba4)
javadoc expects directories on the sourcepath, not jar files.
The original commit 88b607994a
in 2009 was already passing the jar files, and every revision
since then seems to have kept this habit through cargo cult.
This CL removes the superfluous jar file arguments from the
sourcepath argument to javadoc.
Test: Treehugger
Bug: 76436487
Change-Id: I44b4b8ba248ad4deafbb6462e6f7398f15bd2845
When building vendor modules with BOARD_VNDK_VERSION=current, the
API of the vendor modules will be current PLATFORM_VNDK_VERSION.
__ANDROID_API_FUTURE__ will be used as before if the version is a
CODENAME.
If BOARD_VNDK_VERSION is not "current", that means the VNDK version
of the vendor modules is BOARD_VNDK_VERSION.
Bug: 74833244
Test: Build and check boot.
Change-Id: Iccc603f1b5ffa066e74ba1357f3fbbcc13c58f76
Non-A/B devices need to include the DTBO image
within the recovery partition to be self-sufficient
and prevent OTA failures.
Test: Ran 'm dist' and verified that the DTBO image
was included in recovery.img using unpack_bootimg.
Also ran 'make' and verified that the DTBO image was
included in recovery.img using unpack_bootimg.
Also tested that aosp_angler-userdebug could
boot into recovery(including a fake dtbo.img
in recovery image).
Bug: 74763691
Change-Id: I38c9c395c95d21f4da42cfa646063bd4416f6bd8
With project Treble, it's possible to only update system.img across
Android major releases without changing other partitions. However,
for non-A/B devices, ramdisk cannot be updated via a system-only OTA
because it resides in /boot partition.
This leads to two major incompatibility issues:
- The older /init in ramdisk might not be able to parse the *.rc files
on /system.
- The ramdisk contains /init.rc, which also may be out of date compared to
what is required for the new /system.
Therefore, for new devices launched in P with full Treble support, ramdisk
should be merged into system.img by setting
BOARD_BUILD_SYSTEM_ROOT_IMAGE := True.
Upgrading devices can keep using non-system-as-root configuration.
Bug: 64194858
Test: manual makefile prodding
Change-Id: Ic04c63bd2aac3afa686a6f5cb124beebbcd6a5ee
