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
Rather than constructing a userdata fstab entry from scratch, this patch
will modify the vendor fstab to preserve the desired encryption
properties and filesystem type.
Bug: 123906417
Test: manual test
Change-Id: I338715fc62628169e8eafbf4a3125e4aadf0ff15
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>
libs(libasyncio libmemtrack libprocinfo libusbhost) have
vendor variants and they are also used by LLNDK(libmediandk)
which means these libs can be double-loaded.
deps:
- libmediandk -> libmedia_jni -> libmtp -> libasyncio
- libmediandk -> libmedia_jni -> libandroid_runtime -> libmemtrack
- libmediandk -> libmedia_jni -> libandroid_runtime -> libdebuggerd_client -> libprocinfo
- libmediandk -> libmedia_jni -> libmtp -> libusbhost
Bug: 121280180
Test: m -j
Change-Id: I2c2b5d67cf47b85a2aa8c08f85c7e1a84490cf4e
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
Previously, we were rejecting the flag and failing with EINVAL. File
handles aren't inherited by default, so just ignore the flag.
Bug: http://b/123753498
Test: adb install --streaming foo.apk
Change-Id: I17401fcdd58024956d47a5c4c0c57b06831d9817
This reverts commit 5c8c6a90fd.
Reason for revert: Another try with http://r.android.com/892234 in place.
Test: Flash and boot
Bug: 113373927
Change-Id: I508c217a177e9cdd65d8a405d1315aeeacabe18d
dmabuf_dump had a hard dependency on debugfs to gather the initial list
of buffers for all proceses, make it optional.
Change-Id: I1d271297c0ad6124b321a1ee8aa01d3e88ca9fed
Signed-off-by: Erick Reyes <erickreyes@google.com>
Removed dependency on libc++fs and changed liblog to shared linkage to
cope with build errors derived from the change.
Removed dmabuf_dump unnecessary dependencies and made it soc_specific.
Removed reference to std::filesystem::is_symlink to workaround the
following error when linking with the library:
ld.lld: error: undefined symbol:
std::__1::__fs::filesystem::__symlink_status(std::__1::__fs::filesystem::path
const&, std::__1::error_code*)
>>> referenced by filesystem:1743
(external/libcxx/include/filesystem:1743)
>>>
dmabufinfo.o:(android::dmabufinfo::AppendDmaBufInfo(int,
std::__1::vector<android::dmabufinfo::DmaBuffer,
std::__1::allocator<android::dmabufinfo::DmaBuffer> >*)) in archive
Bug: 63860998
Change-Id: Ieafdc87c64f153625df9e21fc8299292b2447aef
Signed-off-by: Erick Reyes <erickreyes@google.com>
The sys.use_memfd property is set by default to false in Android
to temporarily disable memfd, till vendor and apps are ready for it.
The main issue: either apps or vendor processes can directly make ashmem
IOCTLs on FDs they receive by assuming they are ashmem, without going
through libcutils. Such fds could have very well be originally created with
libcutils hence they could be memfd. Thus the IOCTLs will break.
Set default value of sys.use_memfd property to true once the issue is
resolved, so that the code can then self-detect if kernel support is present
on the device. The property can also set to true from adb shell, for
debugging.
Bug: 113362644
Change-Id: I0f572ef36cac2a58fe308ddb90bbeffbecdaed3b
Signed-off-by: Joel Fernandes <joelaf@google.com>
