Allow LightRefBase to be used with
ANDROID_UTILS_REF_BASE_DISABLE_IMPLICIT_CONSTRUCTION, mainly for
libhwui.
Bug: N/A
Test: libutils_test
Change-Id: I251c874a80f0a069572bc51da45f8f8e74ba6f5b
Now that mkbootfs is in prebuilt build tools, make it have no dynamic
dependency so that the binary is portable.
Bug: 184490452
Test: Presubmit
Change-Id: Ida4ee9af3c51ba9d163cf9c1e7b7098fd24e0de1
Adds the -b option to show the bad data block that failed to decompress.
If the block is large enough, display the front as though it were a
CowOperation, as this is the most likely culprit.
Change-Id: I287f13e0794a1ca9d647d4b1099ab238a6202b23
Bug: 183985866
Test: inspect_cow -db <COW_FILE>
On first boot, FDE devices hang on the command
'wait_for_prop apexd.status activated'. This is because apexd was
already started with the tmpfs /data, then was stopped by
vold.decrypt=trigger_shutdown_framework. Then when apexd is started
again with the real /data, it sees that apexd.status="ready" already, so
it doesn't consider itself to be starting from scratch again. So it
doesn't move apexd.status back to "activated" as expected.
Fix the above by resetting apexd.status to its initial value of the
empty string before trying to start apexd in the post-fs-data trigger.
Note that this also takes care of the userspace reboot case which was
previously handled in the userspace-reboot-requested trigger.
Also, FDE devices hang at the same place on non-first boots with default
encryption (i.e., when no PIN is set) because apexd is still running
after having been started with the tmpfs /data. This is because
vold.decrypt=trigger_shutdown_framework isn't run in that case, but
rather vold manually kills processes that have open files on /data --
which doesn't include apexd. But, apexd should be restarted too.
Fix that by using 'restart apexd' rather than 'start apexd'.
Note that these changes are needed even though FDE devices don't support
updatable APEXes, as apexd is needed regardless.
This is one of a set of changes that is needed to get FDE working again
so that devices that launched with FDE can be upgraded to Android 12.
Bug: 186165644
Test: Tested FDE on Cuttlefish. Also tested userspace reboot (with FBE)
Change-Id: I4fa57cf15d77b64d1167eaf966347d2a9d6a9b72
If precompiled vendor policy has system_ext hash, system_ext also has to
have its hash, to use precompiled sepolicy.
Bug: 186727553
Test: remove system_ext's hash and see sepolicy compiled in runtime
Change-Id: I4af3418d614156b5e9cd0b0116c2814ba994ee81
The existing code has a lot of references to the
`ro.boot.qemu` and `ro.boot.qemu.something` properties
which is not supported by the bootconfig if we place
everything under `androidboot.qemu`.
Bug: 182291166
Test: getprop | grep qemu
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: Icb9d29c8dc39e1fa52a6f2ce43b4f42182b7995d
This test previously expected failure - a machine which does not have
2GiB of memory. However, while today is becoming the past,
2GiB allocations working is no longer a dream of the future!
Fixes: 186569165
Test: libutils_test
Change-Id: I6a9ed608c0989d415b4e7735b8a451b8928b4083
And use the new fs_mgr C++ API.
Bug: 186504948
Test: atest CtsFsMgrTestCases
Test: atest CtsFsMgrTestCases in DSU
Change-Id: I80d68d72fb3aa9f5a0dc7d9400b4d0f80cc7deb3
Currently the gki_4_19_pixel5 presubmit test uses an old
vendor_boot-debug.img from a release branch. Adding fallback
paths to load debug resources from /first_stage_ramdisk dir to
pass the presubmit.
This CL should be reverted later once the vendor_boot-debug.img
gets updated to store the debug resources on the root dir.
Bug: 186082603
Test: boot a device with boot-debug.img
Test: boot a device with vendor_boot-debug.img
Change-Id: I9fcd77fc5a60a15cff254e432e05f1c9122ad80d
Currently the debug resources might under /first_stage_ramdisk/*
of the ramdisk, if there is androidboot.force_normal_boot=1 in the
kernel cmdline to request init chroot into /first_stage_ramdisk dir.
To make a generic boot-debug.img works on devices with and without
this chroot, moving the debug resources to the root of the ramdisk.
And copy them for later use before the chroot.
Bug: 186082603
Test: boot a device with boot-debug.img
Test: boot a device with vendor_boot-debug.img
Change-Id: I052a92b2d26c7fdf749991fc55015ff68743efc2
If one end of the communication socket is closed for some reason, there
is no need to terminate the daemon or the client. Mask
the SIGPIPE using MSG_NOSIGNAL flag - we will
still get EPIPE error but process will not be terminated.
Bug: 186213024
Test: Full OTA
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: Iaa53545c0c4059618f6b49afb9ec24ea5372c7e0
Issue a warning about missing cpu/schedtune controller only if both of
them are missing.
Bug: 185437398
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I3a9d3c9a8c91c8d2c5346bcb431bb0407c64a811
Soong generates classpaths.proto config and puts it into
/system/etc/classpaths/ for derive_classpath to read at runtime. There
is no need to plumb these values via make anymore.
Bug: 180105615
Test: m && launch_cvd; presubmit / DeviceBootTest
Change-Id: I514c5036871233ae865b972effea8321dbe4aea9
Remove the vestigial llndk_library modules and replace them with
properties in the llndk clause of the implementation cc_library.
Bug: 170784825
Test: m checkbuild
Test: compare out/soong/build.ninja
Change-Id: Ie3a1bffcf29bb1b6747f7f708826c61bd43ba5a1
For symmetry, add function CleanupOldScratchFiles in conditional compilation blocks which missing it.
Test: monkey test for one day and one night
Signed-off-by: Jintao Zhu <zhujtcsieee@gmail.com>
Change-Id: Ie754427334c9a9bb7cfed70df45f439c60c9ab16
init starts services in "bootstrap" mount namespace until the "default"
mount namespace is ready even when init's current mount namespace is
"default".
apexd and linkerconfig are those processes to set up the mount
namespaces: apexd activates apexes and linkerconfig generates linker
configs.
Previously apexd is allowed to be started in the "current" namespace by
checking its "service name"(it should be "apexd"). But there can be a
certain environment apexd is started in a different way. For example, in
microdroid, apexd is started using "exec -- /system/bin/apexd --vm"
because it wants to run in a different execution mode.
So, instead of checking the service name, its executable's path is
checked against to allow apexd to be started in the current mount
namespace.
Bug: 179342589
Test: MicrodroidTestCase (microdroid boots)
Test: cuttlefish boots
Change-Id: I7c2490e15d481c28ddf382d2d3fdf58a78e467ec
As ReadFstabFromFile() may append / remove / modify the fstab read from
the file, we cannot make assumptions about the number of fstab entries.
We can however test that the returned fstab contains at least the
entries we expect.
Fixes: 185826755
Test: atest CtsFsMgrTestCases on GSI & DSU
Change-Id: I539e7eed3f7ae14db7e9983bed7f68754c9fff39
