These variants will compile with -DMICRODROID flag, which will allow us
to exclude init features that are not needed for Microdroid, and
introduce features that only work in Microdroid.
Bug: 287206497
Test: build com.android.virt APEX
Change-Id: Ib9af0cfcdf06c70fc39e6e6ac8ef07bb69982969
Previously, libdm ensured that uevent will be generated when a dm device
is deleted. However, there actually are cases where uevent can't be
expected; for example, if an empty dm device is created, but then gets
deleted without being activated, then there should be no uevent upon
deleting because there actually is nothing to remove from /dev. (dm
device gets added to /dev only if it is activated).
Actually such a case exists in apexd. As a performance optimization, it
proactively creates empty dm devices for all APEXes it scanns. But
some of them don't ever get activated if the APEX is already in a
dm-verity protected block device (i.e. the pre-instaled APEX is the
latest one). In that cases, the empty dm devices are deleted at the end
of the boot process as a clean up.
The libdm triggered error during the clean up, because there was no
uevent generated for the empty dm devices. This has triggered a lot of
false alarms to the apex team.
This CL fixes this by ensuring uevent only for activate dm devices. If
the dm device doesn't show up in /dev, we just delete the in-kernel
object and don't expect it to generate uevent for it - which actually is
the kernel's behavior.
Bug: 286176029
Test: build and run aosp_cf_x86_64_phone. observe dmesg.
Before the change:
I apexd : Deleting unused dm device com.android.hardware.core_permissions
E apexd : Didn't generate uevent for [com.android.hardware.core_permissions] removal
W apexd : Failed to delete dm-device com.android.hardware.core_permissions
After the change:
I apexd : Deleting unused dm device com.android.hardware.core_permissions
<no error or warning logs>
Change-Id: I52042de7d4d9ab62e6a13428c32a67e13395d1b5
When IOServiceGetMatchingServices returns an invalid
iterator, IOIteratorReset doesn't help. Break the loop
to prevent being stuck in the reset loop forever.
This should be fine as the open_device() call in the
upper layer is already doing retries.
Bug: 286495045
Test: fastboot update
Change-Id: Ia58fa9285640be34aa22cd77e4f58cc9092679a4
This bypasses CowReader and shows ops directly from CowParserV2. This
will come in handy once CowOperation is versioned and CowReader will be
translating from older versions to new versions.
Bug: 280529365
Test: inspect_cow
Change-Id: Icaeba86105c31c4dfe2812309a4028dd1d0248c0
gflags is a lot cleaner to use than getopt, and we don't really need any
advanced argument parsing.
Test: inspect_cow
Bug: N/A
Change-Id: I19007a787a2e5cd3a67486c7949b34ba76f762e4
Print logs necessary to understand why apexd isn't shutting
down when this test fails, due to a rare flake.
Bug: 285458033
Test: init_kill_services_test (and cause this error to be hit)
Change-Id: Ic9cbf7b2b9fa89504e4a53597065e94c32233e12
The default initalization for mNullValue uses 0 which is in the case of
a std::string TValue will invoke the contructor with undefined behavior
parameter.
Using an empty uniform initialization {} addresses the problem.
Test: Already tested in lrucache_test.cpp
Bug: 257127748
Change-Id: I37420ce8a16c99f3014538a0208d7e113870b1c7
The plan of record for the new CowOperation layout is to automatically
translate from CowOperationV2. However, CowWriterV2 currently imports
directly from CowReader, which means we'd need two translation steps.
Luckily we now have CowParserV2, which means we can directly import into
CowWriterV2.
Bug: 280529365
Test: vts_libsnapshot_test
Test: cow_api_test
Change-Id: I11863dcb483f0448686d6c492d8eb128840ce18c
This only added one real method to ICowWriter, so let's just fold it
into ICowWriter. CompressedSnapshotWriter goes away as well.
CompressedSnapshotReader is now part of libsnapshot_cow.
Bug: 280529365
Test: m otapackage
apply ota
Change-Id: I55358c3c9be111d5aee1a0c22c29cb1539d05494
Call AServiceManager_isDeclared before calling AServiceManager_getService
to avoid the waiting time when aidl service is not available.
Bug: 286969060
Test: run VtsHalGatekeeperTarget
Change-Id: I7d652a546cb810a601338a68950f01d065aea7a5
images are being flashed twice, because of an additional collectImages.
This is resulting in a ~50% increase in flashing time
Test: fastboot flashall -w
Change-Id: I6c271e1e1456cd789f37ebd67cefd221cabc6e7a
This fixes the following compiler errors with gcc
storage.cpp:45:20: error: 'ostream_iterator' is not a member of 'std'
storage.cpp:50:10: error: 'istream_iterator' is not a member of 'std'
Change-Id: I570e332d100bb18e445644a9d57dc14d80f104b5
This fixes the following compiler error with gcc
fastboot_driver.h:51:10: error: ‘function’ in namespace ‘std’ does not name a template type
Change-Id: I3a4d9b48bfdc2c76e443e2efe1761ec9503c6dc5
The ANDROID_SERIAL env is useful for managing multiple
directly connected devices at one time.
Unfortunately for network connected devices, its harder to use.
This is because both adb and fastboot use the same ANDROID_SERIAL
environment value to identify the device to use, and while that
one value works for directly connected devices, when using
network connected devices, the fastboot and adb port numbers may
differ for the same device.
So if I set: `ANDROID_SERIAL="tcp:127.0.0.1:44403"`
fastboot will work, but when I type `adb shell`, I'll get:
adb: device 'tcp:127.0.0.1:44403' not found
As `adb devices` outputs:
List of devices attached
localhost:36697 device
To resolve this, we need separate environment variables,
so introduce a FASTBOOT_DEVICE variable for fastboot.
If FASTBOOT_DEVICE is set, it will use that, and if not
it will fall back to the ANDROID_SERIAL if it is set.
Using an explicit -s argument will still override both.
Change-Id: Icd7db6f29e51ed2decd219e35537f6ed98d698b8
Signed-off-by: John Stultz <jstultz@google.com>
This CL allows restart_period to be set to a value shorter than 5s.
Previously this was prohibited to rate limit crashing services. That
behavior is considered to be a bit too conservative because some
services don't crash, but exit deliverately.
adbd is the motivating example. When adb root or adb unroot is
requested, it changes its mode of operation (via sysprop), exits itself,
and restarts (by init) to enter into the mode. However, due to the 5s
delay, the mode change can complete no earlier than 5 seconds after adbd
was started last time. This can slow the mode change when it is
requested right after the boot.
With this CL, restart_period can be set to a value smaller than 5. And
services like adbd can make use of it. However, in ordef to rate limit
crashing service, the default is enforced if the service was crashed
last time. In addition, such intended restart is not counted as crashes
when monitoring successive crashes during booting.
Bug: 286061817
Test: /packages/modules/Virtualization/vm/vm_shell.sh start-microdroid \
--auto-connect -- --protected
* with this change: within 2s
* without this change: over 6s
Change-Id: I1b3f0c92d349e8c8760821cf50fb69997b67b242
