BatteryMonitor returns HealthInfo structs directly. Modify
code to adapt to this behavior.
Test: health VTS test 2.0
Bug: 142260281
Change-Id: I5e6605e46bb4f8bb08c1356e5f2233880e6f9d14
Documentation: https://source.android.com/devices/tech/power/batteryless
If a battery device is not detected, the following battery-related
defaults are used on Android 9 and higher:
* Present: false
* Status: unknown
* Remaining capacity: 0
* Health: unknown
* AC charger online: not modified
The previous version of the test failed devices if the vendor HAL
reported BatteryStatus::UNKNOWN. However, the tests were skipped if the
default HAL was the one being used, so this has not come up before for
other batteryless devices.
Bug: 142081126
Test: vts-tradefed run vts -m VtsHalHealthV2_0
Change-Id: I8ca758677478b47511e24990fee545fafa6c7f83
Convert VtsHalAuthSecretV1_0TargetTest to be parameterized test
and add it to vts-core
Bug: 142397658
Test: $atste VtsHalAuthSecretV1_0TargetTest
Change-Id: I6cf21977e1fef8b11bf0517540ef831a52a44937
BatteryMonitor::update no longer calls healthd_board_battery_update
and callback for us.
Test: VTS health HAL 2.0 test
Change-Id: I05fbf60b7e2c38f82e019d2fec2b5f535defaeae
This change converts the original healthd_common.cpp to a
C++ class, HealthLoop, that manages the infinite loop in health-related
modules (charger, health HAL, healthd, etc.). By doing so, the global
static variables (including FDs and healthd_mode_ops) are cleaned up.
This helps us implement health HAL 2.1.
In order to support legacy modules (namely, healthd, charger, health HAL
2.0, which all depends on android.hardware.health@2.0-impl), a
healthd_common_adapter.cpp file is added to
android.hardware.health@2.0-impl, so that the following functions
in healthd/healthd.h continues to be implemented using the global
healthd_mode_ops:
- healthd_register_event
- healthd_battery_update_internal
Test: boot up the device and run VTS test on health HAL.
Bug: 137670450
Bug: 142260281
Change-Id: Iadcfc1315155404a3600f0e1219b5bc370d96409
C++20 will require members in a designated initializer to be in order
unlike C99.
Bug: 139945549
Test: mm
Change-Id: If22be04df7d2d0aae9ed50fada53d0ccd4edc9d1
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
C++20 will require members in a designated initializer to be in order
unlike C99.
Bug: 139945549
Test: mm
Change-Id: I9529dba0fe407f0d16f7aee10e3629f0175b8e3e
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
C++20 will require members in a designated initializer to be in order
unlike C99.
Bug: 139945549
Test: mm
Change-Id: Ifdccde48c47c0495467f438002caf91cfdbd8091
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
C++20 will require members in a designated initializer to be in order
unlike C99.
Bug: 139945549
Test: mm
Change-Id: I387d30e993719014da50207c7114b0003b9450c5
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Chaining the method calls in such a way otherwise returns a dangling
pointer to a temporary object.
Bug: 139945549
Test: mm
Change-Id: I0783fccbb6f11e7e37bd059445265227359649cf
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
C++20 will require members in a designated initializer to be in order
unlike C99.
Bug: 139945549
Test: mm
Change-Id: Ie34b4f3400439817bebd30ee0356e35a87c971e5
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
The XSD has to be kept manually synced to the HAL definition. When some
formats were introduced and the corresponding enum values were added in
the HAL .hal, the XSD was not updated.
Test: xmllint --noout --schema hardware/interfaces/audio/4.0/config/audio_policy_configuration.xsd --xinclude out/target/product/*/vendor/etc/audio_policy_configuration.xml
Bug: 128967080
Change-Id: I8cf36c7717a0dd15fb4f6261f9bb61c88b27a959
As IStream::close only releases internal resources of the stream,
deferring actual stream closing to IStream server object
destruction, which is delivered to the audio HAL server
asynchronously, there is a possibility for a race condition
when streams gets opened and closed in a tight loop as in the VTS
test.
Work around this problem by flushing RPC messages between
the client and the server, and inserting a delay before opening
a new stream.
Bug: 139329877
Test: VtsHalAudioV5_0TargetTest#AudioPrimaryHidlTest.GetMicrophonesTest
Change-Id: Id8744f6f21fd3bfa607f489364925eccbab17b5e
(cherry picked from commit 26f868bb02)
![](/avatar/ef4a85532a29218c6b19b60e782b0746?size=56 "Harpreet \\"Eli\\" Sangha"){kind=small}
