Now in Android.bp files, target.linux applies to all targets running a
linux kernel (android, linux_glibc, linux_bionic). So common
flags/sources/etc can be combined instead of copying them to each
target.
Test: m
Change-Id: If7ad138ea1c540c160731f86b6ccc0daa5c69b83
- make liblog dependency for all library builds (this is required
for files like String8.cpp)
- export liblog headers (because they are used in many header files).
Test: less libraries fail with BOARD_VNDK_VERSION := current
Merged-In: Iecb9cd00deb3a9056ea63c4a087afdb80a51a2b8
Change-Id: Iecb9cd00deb3a9056ea63c4a087afdb80a51a2b8
(cherry picked from commit 43e20cac7b)
Java already restricts properties to only UTF8 valid strings, and
this change makes this restriction also apply to all native code.
Bug: 63177684
Test: new unit tests
Change-Id: I9fa0ecc0da066b0a026db3497c0f0cbf3f5c2d5a
This lib becomes VNDK-SP just because libutils, which is VNDK-SP, is
depending on it. Since libutils provide android::CallStack class for
collecting and printing the callstack, there is no need for vendors to
use the internal libbacktrace library. Thus the lib is marked as
vendor_available: false.
Bug: 64730695
Test: build 2017 pixel device
Change-Id: I4ad91e3a6747bb0ae88d32cd26dfba32239c5b93
Previously there is no vboot 1.0 metadata for ENG builds. It relies on
is_device_secure() to query "ro.secure" and skip setting up dm-verity
if the value is 0 (meaning ENG build).
This change will be submitted together with other changes to add vboot
1.0 metadata for ENG builds with a "disable magic". The resulting
metadata will be the same as triggering an "adb disable-verity" on an
USERDEBUG image.
Bug: 63056044
Test: boot sailfish eng/userdebug builds
Change-Id: I35eef771e1b30bfc6d01b8ed76b40c942fe7b783
Adding a set of automated engineering unit tests with a strict list of
prerequisites. Not meant for "user" builds. Must have a crafted
bootloader that does not set the boot reason. Only works on platforms
where the bootloader either by accident or specifically does not set
the ro.boot.bootreason via kernel command line configuration
androidboot.bootreason=. If the tests do not have the prerequisites,
the test will report success, but with protest.
These new tests should work on current Hikey and Hikey960 bootloaders
but could very well become obsolete if those platform bootloaders
start setting the boot reason.
We do not want a platform solution as it could allow a third party to
override the bootloader boot reason.
Test: system/core/bootstat/boot_reason_test.sh
Bug: 63736262
Change-Id: I1793184a8484b83e1d9077475bc65af9816dadf7
Bug: 67678999
Test: Run serial console on Hikey
Change-Id: Ia5fa9c2af4771508d96545f6a8814a81d5ccee3c
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Use actual test durations to refine future duration estimates.
Better estimates are cosmetic, but lend confidence to the test
results.
SideEffects: none
Test: system/core/bootstat/boot_reason_test.sh
Bug: 63736262
Change-Id: I49143b78a6dc6fb21838a3d6c70b7eb5a8b4cba5
Add cold,powerkey, warm,s3_wakeup and hard,hw_reset so that
sys.boot.reason values can also be enumerated. Also add
some reserved speculative entries associated with forced
suspend to RAM and DISK; shutdown,suspend and shutdown,hibernate
respectively.
Test: system/core/bootstat/boot_reason_test.sh
Bug: 67636061
Change-Id: Ic43523748e6006aaca882f8eec7c1f0c08431bd8
Empty boot reason is mostly unexpected but may take up the bulk of
unknown reported boot reason values.
Bug: none
Test: none
Change-Id: I9978658c2b052d5cf5d28299861b0d1125ba9fc0
Tom Cherry