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
The generate.sh script can generate the file, but current policy file does not match it.
And the rules are not appropriate, like missing "sysinfo", causing the
debuggerd_test to fail in system model. So we match the policy to
what it should be.
Test: make debuggerd_test
Change-Id: I57ebd7713f2ab939d01bfefcc7935e234fdd3e13
Signed-off-by: liwentao <liwentao@eswincomputing.com>
Some testing environments can have a test that is sending many
thousands of messages to the log. When this type of process crashes
all of these log messages are captured and can cause OOM errors
while creating the tombstone.
Added a test to verify the log messages are truncated. Leaving this
test disabled for now since it is inherently flaky due to having to
assume that 500 messages are in the log.
Added a test for a newline in a log message since it's somewhat
related to this change.
NOTE: The total number of messages is capped at 500, but if a message
contains multiple newlines, the total messages will exceed 500.
Counting messages this way seems to be in the spirit of the cap,
that a process logging a large message with multiple newlines does
not completely fill the tombstone log data.
Bug: 269182937
Bug: 282661754
Test: All unit tests pass.
Test: The disabled max_log_messages test passes.
Change-Id: If18e62b29f899c2c4670101b402e37762bffbec6
Report Battery health INCONSISTENT when there is a battery recalibration
pending.
Bug: 283182048
Test: m
Change-Id: I8b944ddac7cc919fc95b1b71b015101642a62f96
Signed-off-by: Jack Wu <wjack@google.com>
apexd restarts the device, so it causes flakes here,
especially in presubmit.
Bug: 280514080
Test: init_kill_services_test
Change-Id: I4455704795961f3ae94e29bdf098eca739130973
The type of f_frsize is `unsigned long` which is 32 bit for some system so it will overflow after multiplied by f_bfree. This solution adds one more type casting to ensure the type is 64 bit unsigned integer during the computing.
Bug: 281599020
Test: adb root; adb shell disable-verity
Change-Id: I377ed722d5e245c235c3ae12ff66ac7e91d1d6e8
Just noticed some opportunities while skimming.
Test: adb shell debuggerd $(adb shell pidof com.android.systemui)
Test: All unit tests pass (both 32 bit and 64 bit).
Test: Ran unit tests in a loop hundreds of times.
Change-Id: I428d0cf599ed603a21944b084b95594db893cbd5
Now that the code has moved, delete the local implementation in favor of
the common one.
Test: builds
Change-Id: Ic29d7c9bcd3d623204f3e4de3a3434483021cbac
It can be difficult to figure out where this test
is while it's executing, so I've added logs.
Bug: 280514080
Test: init_kill_services_test (w/o tradefed to avoid reboot), then:
:) adb logcat -d | grep init_kill_services_test
... I init_kill_services_test: hello lmkd!
... I init_kill_services_test: okay, now goodbye lmkd
... I init_kill_services_test: I said goodbye lmkd!
... I init_kill_services_test: are you still there lmkd?
... I init_kill_services_test: I'm done with lmkd
... I init_kill_services_test: hello ueventd!
... I init_kill_services_test: okay, now goodbye ueventd
... I init_kill_services_test: I said goodbye ueventd!
... I init_kill_services_test: are you still there ueventd?
... I init_kill_services_test: I'm done with ueventd
... I init_kill_services_test: hello hwservicemanager!
... I init_kill_services_test: okay, now goodbye hwservicemanager
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: are you still there hwservicemanager?
... I init_kill_services_test: I'm done with hwservicemanager
... I init_kill_services_test: hello servicemanager!
... I init_kill_services_test: okay, now goodbye servicemanager
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: are you still there servicemanager?
... I init_kill_services_test: I'm done with servicemanager
Change-Id: I2466f574fc06cdf1b01db82f89649f39b0f34345
When we changed our ENOSPC tests, it exposed a path in F2FS were
fallocate can return EAGAIN. This is expected if F2FS attempts GC to
acquire more chunks, and it can leave the file in a partially allocated
state.
As a fix, keep attempting fallocate() as long as (1) it returns EAGAIN,
and (2) the allocated size keeps growing. If (2) fails we return ENOSPC.
Bug: N/A
Test: treehugger
Change-Id: I5f867b5a200b9260e486985f203f9872a949b3f9
We've had flake in libdm_test for a long time, with no clear cause.
Lately however it has become particularly reproducible when running
the UeventAfterLoadTable test in isolation, and thus we've identified
the root cause.
uevents for device-mapper are fired when the sysfs node is added, but at
that time, the "dm" subnode has not yet been added. The root node and dm
node are added very close together, so usually it works, but sometimes
ueventd is too fast.
Instead of relying on sysfs, query the uuid/name node directly from
device-mapper.
Bug: 270183812
Test: libdm_test
Change-Id: I258de5de05d813c3cb7f129e82e56dbfe8bf3117
Make sure that all the threads have started up, otherwise the main part
of the test might not be testing as stressful a situation as expected.
Note that the "race" moniker is still valid because of the debuggerd
timeout.
The test is now faster (405ms) when run under good conditions.
Test: atest 'debuggerd_test:debuggerd_client#race'
Test: Ran debuggerd_client.race 1000 times on its own.
Test: Ran the whole suite of debuggerd unit tests 1000 times.
Change-Id: I487e7654a71df9f1799f09c6f385c929ddf2f234
* changes:
Merge "DO NOT MERGE: libsnapshot: Fix test failures on certain configurations." into android13-tests-dev am: 1264f39449
[automerger skipped] DO NOT MERGE: libsnapshot: Fix test failures on certain configurations. am: 3f96053b38 -s ours
am skip reason: skipped by user dvander
Original change: https://android-review.googlesource.com/c/platform/system/core/+/2577014
Change-Id: Ie3c4bf3d52ddcf6ca7e13cf108f523b2b5f45fc7
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
Borrow the code from AttestKeyTest.cpp (in KeyMint VTS) for determining
the devices IMEI value(s), and use that as default value.
Also update to use the newer provisioning message if the second IMEI is
set.
Test: provision a test device
Change-Id: Ie8e183dc50ac9107c2c2c2966c591e8b6022fd20
Instead of crashing the gatekeeperd on incorrect
inputs to AIDL interface, return errors from the
service.
Test: m gatekeeperd, booted device
Bug: 279970163
Change-Id: Ifd3330e749f4ce147db5886f1f2dbb00c322bed2
The prop can be consumed by init scripts to do customized setup:
on property:ro.gsid.dsu_slot=oemtest
# Do setup for test
on property:ro.gsid.dsu_slot=oemdemo
# Do setup for demo
Bug: 277691885
Test: m
Change-Id: I7bd78b9ba31021b27d57c6f092dad5d7ebf6e59b
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
