This check isn't needed as super_flash_helper.cpp calls a different
should_flash_in_userspace that isn't reliant on $ANDROID_PRODUCT_OUT
being set. Current code will fail when calling fastboot update
Test: fastboot update update.zip without calling lunch
Bug: 283330320
Change-Id: Icefe6092befb747b7f419ea997e0834602808d69
Old changes didn't actually take into account sources. fastboot update
{update.zip} should read fastboot-info from the update package. It was
instead flashing local images + reading local fastboot-info.txt
Test: m fastboot, fastboot update, fastboot flashall
Bug: 283330320
Change-Id: I9587a7735ddfbfb661153eb12ebc3caa7c32f141
When booting up, Android can boot into one of three modes: normal,
recovery, and charger mode. The set of modules that should be loaded
during first stage init in each mode can differ, which is why init
reads the list of modules to load from modules.load.recovery when
booting into recovery, and modules.load otherwise.
This means that init will read the list of modules to load during first
stage init from modules.load even when booting into charger mode. This
is not ideal, as it causes modules that need to be loaded during
first stage init only when booting into charger mode to also be loaded
during first stage init of normal boot, which can degrade boot time.
Thus, add support for reading modules.load.charger, which contains the
list of modules that need to be loaded during first stage init when
booting into charger mode.
Bug: 266752750
Change-Id: Ib9178bdfe5a6aac57b86b6d453b03625e95d5b48
Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>
These tests have been a plague of flakiness forever, and while we've
made improvements, the test is fundamentally flaky, and keeps showing up
in presubmit.
This change removes the code that attempts to fill /data until it's
almost full, which is unreliable and destructive. Instead, attempt to
allocate a file that is one block smaller than the maximum file size.
This should always fail with ENOSPC, as opposed to the maximum file size
which would fail with EFBIG.
Bug: N/A
Test: vts_libsnapshot_test
Change-Id: I4652b83e31c50975ddb50b6cbe846e102ba0f322
If fastboot-info.txt has wrong format we should not fall back on
hardcoded list silently. Instead we should LOG(FATAL) and fail.
Hardcoded list should only be used when fastboot-info.txt is not found
or is empty
Test: fastboot flashall
Bug: 194686221
Change-Id: I1cada102f3ff12c1f3002d0b61d3785fc25543c1
adb remount clearly indicates that the user will use
a scratch partition to modify RO content. In this CL we're
trying to be more aggressive and take more space from
data to scratch to improve the developers experience.
Bug: 228945443
Test: launch cvd with updated value and check it reflects
Change-Id: Ied9cee6e98d3b2dd594babcf213071a80bd3cf14
Signed-off-by: Dmitrii Merkurev <dimorinny@google.com>
Most callers already converted the reference to a pointer, and pointers
will make it much easier to move around the op list.
Bug: 280529365
Test: builds
Change-Id: I7ec850b58a79c33e57b0e2602e1be953484daa46
Block sizes should not be hardcoded, since the value is set in the
cow header. Move this to snapuserd to isolate use.
Bug: 280529365
Test: builds
Change-Id: I62aa8c7b795f9d258d4b6deb0779a536cba65d52
Clean up the formatting and unit display, and add a line displaying how
long it took to parse the COW.
Example of new output:
Version: 2.0
Header size: 38
Footer size: 84
Block size: 4096
Merge ops: 0
Readahead buffer: 2097152 bytes
Footer: ops usage: 1005680 bytes
Footer: op count: 50284
Parse time: 6.77921ms
Data ops: 50015
Replace ops: 50015
Zero ops: 0
Copy ops: 0
Xor ops: 0
Bug: 280529365
Test: inspect_cow /dev/block/mapper/product_b-cow
Change-Id: Ie8ac02adc004289cc3a08ef44aa3048280a2407f
Done and RDone are not exactly symmetrical, so rename them to match
their underlying STL behavior. Done becomes "AtEnd" and RDone becomes
"AtBegin".
Bug: 280529365
Test: builds
Change-Id: I876f858a7bef84d8b37c1c822fb42941fbcded25
This function cannot fail, so replace it with an infallible version.
This is also slightly more efficient since there's no copying involved.
Bug: 280529365
Test: builds
Change-Id: Iccfd6e72bc2192f4e1efda50cf544e1e956a9263
This also specifies user on an adbd service
declaration which was missing before. It seems
that certain services are declared mulitple
times.
Fixes: 276813155
Test: boot (on CF, the only V device in the tree)
Test: remove 'user' specification and see error
Change-Id: I138f3ace72d46f221551ad61e75ba4c01632da59
Merging as a separate CL due to a log showing up
related to this on hwasan (is a prebuilt pulling
this in?)
Bug: 276813155
Test: boot cf
Change-Id: I19f7fc51c937d0eb1ee17781fc5d201a0972c4b0
Temporarily turn off these tests until root cause is found.
Bug: 279009697
Test: presubmit
Change-Id: I90f695fac318b71871ff60c1f74c90265437687d
Signed-off-by: Akilesh Kailash <akailash@google.com>
Replacing check with PLATFORM_TOOLS_VERSION with FASTBOOT_INFO_VERSION
to indicate waht version of fastboot_info.txt we currently support. This
makes mor sense since PLATFORM_TOOLS_VERSION won't be updated every time
me make a change to the host tool
Test: fastboot flashall
Bug: 194686221
Change-Id: I621b62c92ba129f402857463dae9112a0797ab07
Updating version to just be a single number. Reason for updating is
to keep format the same as Flashstation's
Test: fastboot_test
Bug: 194686221
Change-Id: I21ab0747e620d3f6d05c5170c3e55707eed0288a
Provide profile validity check functions for cases when user wants to
check whether a profile can be successfully applied before actually
applying it. Add test cases to cover new APIs.
Also add a wrapper function for framework code to call it.
Bug: 277233783
Test: atest task_profiles_test
Test: manually verify freezer with outdated cgroup configuration
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Li Li <dualli@google.com>
Change-Id: Iefb321dead27adbe67721972f164efea213c06cb
This added some new failure paths, so the patch also includes an RAII
helper to assist with handling those.
Bug: 278637212
Test: vts_libsnapshot_test
apply ota on CF
Change-Id: Ide59c83cb34b6d448fe9afdc1d15c6139a0c99fa
Bionic requires random numbers to init the shadow call stack. Those
numbers are obtained via the syscall getrandom (non-blocking) and will
fallback to /dev/urandom if the former fails.
When loading pKVM modules, we are so early in the boot process that the
only source of entropy for the linux RNG are the architecture random
number generators... which might be available on some platforms. Without
any source of entropy, the only way of generating a random number is to
try to generate some, which is what the bionic fallback expects via
urandom.
As a consequence, add the urandom node to the initramfs.
Bug: 274876849
Change-Id: I164b08f026a238dad9f27a345bdef96717f2aa74
