Originally, vndk_lite does not include system/lib/vndk-* directory but
searching the required files in system/lib instead. However, in GSI,
they are using the vndk libs which has symbols than core variants.
To avoid this problem, allow the vendor processes in vndk_lite devices
to search system/lib prior to vndk libs.
Bug: 124063441
Test: Check boot for vndk_lite devices.
Change-Id: I89a72e9d43d6fb05f4b6d87bbd4500f8febfe970
The client can include <fs_avb/fs_avb_util.h> to use the two new
functions to load vbmeta for a FstabEntry and extract the hash tree
descriptor from the loaded vbmeta, respectively.
// Given a FstabEntry, loads and verifies the vbmeta.
std::unique_ptr<VBMetaData> LoadAndVerifyVbmeta(...);
// Gets the hashtree descriptor with avb_partition_name from the vbmeta.
std::unique_ptr<FsAvbHashtreeDescriptor> GetHashtreeDescriptor(...);
Bug: 65470881
Test: atest libfs_avb_test
Test: atest libfs_avb_internal_test
Test: atest libfs_avb_device_test
Change-Id: I7d6619eb8140c14734ffb8f8a1b22cddd2f562f0
This commit fixes the search paths for vendor binaries in ASAN targets.
Test: Boot aosp_walleye-userdebug to home screen
Change-Id: Id87ceee3c43098bd453f6fae4f32ea62355f922b
libnativeloader_lazy and libnativebridge_lazy are shim libraries for
libnativeloader and libnativebridge, respectively.
The shim libraries provides the same APIs as their counterparts, but
when the APIs are called, the APIs from the real libraries are
loaded/linked/and executed using dlopen/dlsym.
Bug: 123403798
Bug: 124250621
Test: m
Test: device boots to the UI
Test: mma under system/core/libnativebridge with aosp_cf_x86
adb sync; execute all tests under
/data/nativetest/libnativebridge-lazy-tests
All passes except NativeBridgeTest.V2_Signal which is also failing
in /data/nativetest/libnativebridge-tests.
Change-Id: Ic6484784eaa7872dcdd2decbb30943fb34c1abd7
libbase GetProperty collects the properties properly, which also
allow for content greater than 128 bytes in length.
Replace internal GetProperty and SetProperty helpers with libbase
version.
Test: unit tests
Bug: 121161069
Bug: 124114707
Change-Id: Ic0829955705ebaa19d747bb3f6942f4b9786316a
Move tests in the same directory as the corresponding code, so it's
easier to see what is/isn't tested.
Fix naming of libcutils_tests (plural) to match the singular that's more
common (even though the plural makes more sense to me).
Add these two to system/core/'s TEST_MAPPING.
Remove obsolete AndroidTest.xml.
Fix a flaky (timing-dependent) libcutils test.
Test: ran tests
Change-Id: I7e0a31ff45c8a152562bf66fc97161594249366e
fs_mgr_update_verity_state() has two callers with generally different
intentions. One caller loops through all entries in the default fstab
to set partition.<mount_point>.verified properties. The other caller
is only interested in whether or a specific mount point has verity
enabled.
Given this, we refactor fs_mgr_update_verity_state() to
fs_mgr_get_verity_mount_point() which takes a single FstabEntry and
returns the mount point used for the dm-verity device or an empty
option if verity is not enabled on that mount point.
Test: adb-remount-test.sh test on blueline
Change-Id: Ic7dd8390509e95b2931b21e544c919a544138864
This change fixes the problem that apexd is delaying the entire boot
sequence while waiting for the loopback devices to be created. The delay
was as big as 50 ms per a loopback device.
With this change, apexd is started much earlier: from "on post-fs-data"
to "on init". When it is first started, it scans /system/apex to
determine the number of APEXes and creates that number of loopback
devices priori. Since then it enters into the binder loop.
When the data partition is mounted, init lets apexd to initiate the
apexd boot sequence where APEXes in /data is scanned, verified, and
activated. Since the creation of the loopback devices were requested far
before, it is very likely that dev nodes for the devices are ready at
this moment (even if not, this isn't a lose).
Bug: 123404717
Bug: 123772265
Test: compare boot times.
init_zygote_START_TIME_avg is improved from 2831ms to 2622ms on blueline
Change-Id: I12450cee44aa4d17a11def62261c2f82d3f2c718
It is better to guarantee that a /system or / entry will be present in
first stage mount than it is to maintain the code to fake an entry if
its not present in the input fstab.
Test: adb-remount-test.sh on blueline
Change-Id: I8aa3e704903b8abf06b1c63be071913a9de58eb3
If ro.boot.boottime is malformed or truncated, it will crash
bootstat operations.
Test: compile
Bug: 121161069
Bug: 124114707
Change-Id: Ie2edcffb6d54a8e0c7f2e9a89ae4b29cce246d75
Confusion has occurred with respect to the kernel patch requirements,
added some clarity.
Corrected some spelling mistakes in other areas.
Test: inspect gitties and run spell
Bug: 118225373
Change-Id: I4ff9497aa5a584b20e9cb2028342aa4e7e4660c3
Test: build with master-art manifest
Exempt-From-Owner-Approval: Required for unbreaking ART development.
Change-Id: I6afc0e5444dfa21532a4c802f8c463091cab2b11
Fixes:
system/core/libmeminfo/libdmabufinfo/tools/dmabuf_dump.cpp:109:39: error: format specifies type 'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat]
Test: lunch aosp_arm-eng && m dmabuf_dump
Change-Id: Ie605d9b94f5eff888f6a64801512216253a6babb
bootstat updates boot reason upon boot_complete, however users of the
updated properties e.g. getLastShutdownReason from PowerManager could
be called before boot_complete. This introduces a inconsistency and
racing for those APIs.
In this CL, we change boot reason to be updated at the same time when
zygote starts where persist properties have been loaded already. Also
the initialization of bootloader's boot reason is pulled into post-fs
where all kernel command line arguments have been parsed in init already.
Bug: 122696730
Bug: 119509425
Test: trigger thermal shutdown and see warnings
Test: verify boot reason properties updated correctly post boot
Change-Id: Ia393b98ea072bc0ae6e4110d111393b34be0ee5d
Signed-off-by: Wei Wang <wvw@google.com>
The reconnection test is spuriously failing on test infrastructure for
unclear reasons, which might be due to a race between the connection
attempt and the first command we send. Insert a sleep to hopefully
reduce the flakiness.
Bug: http://b/123247844
Test: ./test_adb.py (but it didn't fail for me in the first place)
Change-Id: Ic36924c16bae424accfec700af4623794fd1f123
If not present, ro.product.[brand|device|manufacturer|model|name] and
ro.build.fingerprint will be resolved during init from
partition-specific properties.
Test: booted system image, verified properties
Test: booted recovery image, verified properties
Bug: 120123525
Change-Id: I7fe2793a7d9eb65645d92ceb408f1f050acf9a81
