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
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
Clean up charger's libhealthd dependency.
- Charger uses libhealthloop to maintain an infinite
loop, similar to all health 2.x services.
- Charger tries to open up health 2.1 HAL implementation
to retrieve health info. If it failed, it falls back
to the legacy code path where a default BatteryMonitor
is used, *except* that it won't depend on libhealthd's
healthd_board_init() and healthd_board_battery_update()
anymore.
- Remove global static variables because they are hard to
track.
- Modernize code by converting charger_state in to a C++
Charger class, transforming all functions into methods,
and moving all other global states into the class.
- Devices that matches all of the following:
- have a customized libhealthd (search for modules
named libhealthd.xxxx)
- uses charger from system image (look for "class charger"
in device init.rc scripts; if you see the binary is named
"/charger" or "/system/bin/charger" then you are using
charger from system image)
... must implement health 2.1 passthrough implementation
properly in order to have charger continue to work.
See hardware/interfaces/health/2.1/README.md for details.
Test: charger test
Test: manual charger mode
Bug: 127677771
Bug: 142286265
Change-Id: I0f26e5c1fe2be6b5952fc019224457c8419e43e4
Also put libfscrypt into fs_mgr via whole_static_libs
since it's now a dependency.
Bug: 143307095
Test: we can use the inline policy on it
Change-Id: I82d7d5330abef76ce82accea25d2663748e87a8b
To be compliant with lvm, instead of just zeroing the first 32 bit of
the COW device, force to zero the whole first chunk.
Also switch to std::vector to store the zeroes, reducing the stack
growth.
Test: libsnapshot_test
Bug: 139202197
Change-Id: I2d98549528a222d6c27bb566c68477b5ec3add20
Signed-off-by: Alessio Balsini <balsini@google.com>
