libcutils_test is fixed for all architectures and handles cases when
schedtune and/or cpuset cgroup controllers are not enabled. Include it
into presubmit test list.
Test: ran tests
Change-Id: I294220e18aae5e5760e7e6bdee7a2fe4d9c6d6a4
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Update fs_config tests for the new behavior in
a8eb00720c.
Before the above CL, fs_config_cmp() would match any partition prefix
to any path, even if there is not a logical relationship between them.
For example, these two lines in the test the demonstrate the changed
behavior:
{ true, "vendor/lib", "system/vendor/lib/hw", true },
{ true, "system/vendor/lib", "vendor/lib/hw", true },
The first line should match and does; it is testing that files located
at system/vendor/lib/hw are matched by an fs_path_config entry
specified as vendor/lib. This is to allow for applying the policy we
have for the vendor partition to files in /system/vendor in the case
that there is no vendor partition.
The second line should not match. This is testing that a file
that's located at vendor/lib/hw is matched by an fs_path_config entry
specified as system/vendor/lib. This is backwards; we do not want to
have policy specified for system/vendor to impact policy for the
vendor partition.
Also, we never have any relationships from /system/oem to /oem or
/system/odm to /odm, so these are logically unrelated and should fail
to match. We do however have a relationship from /vendor/odm to /odm,
so this test is added.
Test: libcutils unit tests pass on CF
Change-Id: I026f0233e00bbd0aad9bc0fb701aef000d2a037c
Imagine an AIDL file:
package android.foo;
interface IFoo {}
The AIDL C++ backend will generate classes like "::android::foo::IFoo".
In order to avoid ODR conflict, the NDK (Stable C) backend linking
against libbinder_ndk puts everything under the "::aidl" namespace. So,
we have "::aidl::android::foo::IFoo". When using ScopedTrace in a class
implementing a class from this backend, there is this problem.
Bug: 141828236
Test: works
Change-Id: Iafadea11788d4c011229657b4f53063bcf65f8d8
HIDL enum values are zero initialized, not the first value
of the enum. They need to be initialized properly.
Test: pass
Change-Id: I2adb8b851e6ac607ac4f547a6a6600604d07816f
During automatic tests, we sometimes want to reboot the device out of
the rescue party remotely. And per http://go/recovery-adb-access, we
need to grant the adb authorization to enable the adb access. The auth
are only granted for userdebug devices and those with an unlocked
bootloader. Since the user can always flash a custom recovery image if
the bootloader is unlocked.
This cl ignores the ro.adb.secure property under recovery. The other
option is to default this property to 0 when building the boot/recovery
image.
Bug: 141247819
Test: unlock bootloader, run adb under recovery in user build
Change-Id: I424cfed5bf51a1e31d8687256ae4c6eaaa5e6249
Call adb_notify_device_scan_complete when we finish enumerating USB
devices. The original intent of the code appears to have been to have
adb_wait_for_device_initialization return as soon as we've finished
looking around at the system USB environment on daemon startup, but at
some point, we forgot to actually notify the init thread that we
finished scanning all the USB devices, forcing the wait on init_cv to
time out after three seconds on every daemon initialization.
After this change, the daemon starts in a few milliseconds on my Linux
machine
Test: killall adb && sleep 1 && time adb server && adb shell ls
Change-Id: I0bc1da7a597d2077dd2b591560d03798b05905b7
Turns out the Mac doesn't have <error.h>. Add our own "die" function
instead, and use it everywhere so the Mac isn't using an untested
codepath.
One upside to this is that we'll now call ourselves "unzip" even when
run as `ziptool unzip ...`, which was awkward to fix with <error.h> but
trivial if we're rolling our own anyway.
Test: still works on Linux
Change-Id: I9cb1922595a21cd9f6d55a70d67e30090f8b7f21
It should userspace-reboot-requested, not userspace-reboot
Test: adb reboot userspace
Bug: 135984674
Change-Id: I1e844b7705eb70ee3702a1dc0432644592666364
The test is broken because now ProcessUpdateState
checks UPDATED flag as well, and partition "test-snapshot"
does not exist in super partition metadata.
Rewrite the test to mimic the update flow and use
as many public APIs as possible.
Test: libsnapshot_test
Bug: 143551390
Change-Id: I105bad8bb589616b304c511c64be902d4297bda7
If device takes an update from slot A to
B, immediately flashes the B slot, and reboot
into B slot, libsnapshot incorrectly considers
the device booted into the new slot and refuses
to clear update states. Fix this by checking
the UPDATED flag in super partition metadata.
Test: libsnapshot_test
Bug: 143551390
Change-Id: I3cd7bb19b394da6399d4bf2f9d013bfaa7f186f1
Legacy symlink from /charger to /system/bin/charger is
removed. Instead, all Android R devices are required
to use /system/bin/charger instead.
See hardware/interfaces/health/2.1/README.md for details.
Bug: 142286265
Test: charger mode
Change-Id: Ib478a864ef68647bc9fc14650ca3d382952b80c8
Move snapshot_ctl's merge command to SnapshotManager::
InitiateMergeAndWait function so that tests can use
it too.
Test: libsnapshot_test
Bug: 143551390
Change-Id: I0936c262afaca7ba445ee18465dca4e16b9416ad
Allow for module load errors if first stage console is enabled, userdebug
development builds, load what you can and continue.
Test: compile
Bug: 141311820
Change-Id: I30f3ee1129373f6ffedcf03807c212c60d4c39aa
Removing the rest of liblogcat broke logcatd since LogcatPanic() now
actually calls exit(), whereas logcatd relied on it to return
normally.
We can achieve the expected behavior with a small shell script, so
this change does that as well.
Test: logcatd / logpersist work
Change-Id: Icde36a4811a0db987a801978485e1af1dfc3d38c
linkerconfig reads vndk-related libraries.txt files. Now these files are
generated by soong.
Bug: 142963962
Bug: 141450808
Test: m && device boots && TH
Change-Id: I98c2f934815238cacd4ec8536ce2f9f24bbf1b32
This introduces two new commands to the fastboot protocol:
- getvar snapshot-update-status - Return "none", "snapshotted", or
"merging" depending on the current status set by the boot control
HAL.
- snapshot-update [cancel] - Cancel any pending snapshot-based updates
via the boot control HAL. After this, the HAL should return
MergeStatus::CANCELLED and "update-merge-status" should be "none".
If no argument is specified, the snapshot-update-status is returned
via an INFO response.
Bootloaders are expected to implement this in a manner consistent with
the boot control HAL.
Fastboot-based tooling should expect wipes of userdata to fail when
update-merge-status returns "merging". Thus, the force flag now cancel
any pending snapshots.
Bug: 139154945
Test: fastboot getvar snapshot-update-status
fastboot snapshot-update cancel
fastboot snapshot-update
Change-Id: Idc423fe7656b212e929e64eb0e6b85b453e0e8dc
