В Android 11 весь код healthd
рефакторится в libhealthloop
и libhealth2impl
, а затем модифицируется для реализации health@2.1 HAL. Эти две библиотеки статически связаны с health@2.0-impl-2.1
, сквозной реализацией Health 2.1. Статически связанные библиотеки позволяют health@2.0-impl-2.1
выполнять ту же работу, что и healthd
, например, запускать healthd_mainloop
и осуществлять опрос. На этапе init health@2.1-service
регистрирует реализацию интерфейса IHealth
в hwservicemanager
. При обновлении устройств с образом поставщика Android 8.x или 9 и фреймворком Android 11 образ поставщика может не предоставлять службу health@2.1. Обратная совместимость со старыми образами поставщика обеспечивается расписанием устаревания .
Для обеспечения обратной совместимости:
-
healthd
регистрируетIHealth
вhwservicemanager
несмотря на то, что это системный демон.IHealth
добавляется в системный манифест с именем экземпляра «backup». - Фреймворк и
storaged
взаимодействуют сhealthd
черезhwbinder
вместоbinder
. - Код для framework и
storaged
изменен таким образом, чтобы при наличии извлекался экземпляр «default», а затем «backup».- Клиентский код C++ использует логику, определенную в
libhealthhalutils
. - Клиентский код Java использует логику, определенную в
HealthServiceWrapper
.
- Клиентский код C++ использует логику, определенную в
- После того, как IHealth/default станет широкодоступным и образы поставщиков Android 8.1 будут объявлены устаревшими, IHealth/backup и
healthd
могут быть объявлены устаревшими.
Переменные сборки, специфичные для платы, для healthd
BOARD_PERIODIC_CHORES_INTERVAL_*
— это переменные, специфичные для платы, используемые для сборки healthd
. В связи с разделением сборки по системе и производителю, специфичные для платы значения не могут быть определены для системных модулей. Эти значения ранее переопределялись в устаревшей функции healthd_board_init
.
В health@2.1 поставщики могут переопределять эти два значения интервалов периодических задач в структуре healthd_config
перед передачей в конструктор класса реализации health. Класс реализации health должен наследоваться от android::hardware::health::V2_1::implementation::Health
.
Внедрить сервис Health 2.1
Информацию о внедрении сервиса Health 2.1 см. в файле hardware/interfaces/health/2.1/README.md .
Клиенты здравоохранения
У health@2.x есть следующие клиенты:
- Зарядное устройство. Использование кода
libbatterymonitor
иhealthd_common
реализовано вhealth@2.0-impl
. - recovery. Связь с
libbatterymonitor
заключена вhealth@2.0-impl
. Все вызовыBatteryMonitor
заменяются вызовами класса реализацииHealth
. BatteryManager.
BatteryManager.queryProperty(int id)
был единственным клиентомIBatteryPropertiesRegistrar.getProperty
.IBatteryPropertiesRegistrar.getProperty
был предоставленhealthd
и напрямую считывал/sys/class/power_supply
.Из соображений безопасности приложениям запрещено напрямую обращаться к HAL-уровнему состояния. В Android 9 и более поздних версиях служба связывания
IBatteryPropertiesRegistrar
предоставляется службойBatteryService
вместоhealthd
.BatteryService
делегирует вызов HAL-уровнему состояния для получения запрошенной информации.BatteryService. В Android 9 и более поздних версиях
BatteryService
используетHealthServiceWrapper
, чтобы определить, использовать ли экземпляр службы работоспособности по умолчанию отvendor
или резервный экземпляр службы работоспособности изhealthd
. ЗатемBatteryService
прослушивает события работоспособности черезIHealth.registerCallback
.Storaged. В Android 9 и более поздних версиях
storaged
используетlibhealthhalutils
, чтобы определить, использовать ли экземпляр службы работоспособности по умолчанию отvendor
или резервный экземпляр службы работоспособности изhealthd
. Затемstoraged
прослушивает события работоспособности черезIHealth.registerCallback
и извлекает информацию о хранилище.
Изменения SELinux
Health@2.1 HAL включает следующие изменения SELinux на платформе:
- Добавляет
android.hardware.health@2.1-service
вfile_contexts
.
Для устройств с собственной реализацией SELinux могут потребоваться некоторые изменения в настройках поставщика. Пример:
# device/<manufacturer>/<device>/sepolicy/vendor/hal_health_default.te
# Add device specific permissions to hal_health_default domain, especially
# if it links to board-specific libhealthd or implements storage APIs.
Интерфейсы ядра
Демон healthd
и реализация по умолчанию android.hardware.health@2.0-impl-2.1
обращаются к следующим интерфейсам ядра для получения информации о батарее:
-
/sys/class/power_supply/*/capacity_level
(добавлено в Health 2.1) -
/sys/class/power_supply/*/capacity
-
/sys/class/power_supply/*/charge_counter
-
/sys/class/power_supply/*/charge_full
-
/sys/class/power_supply/*/charge_full_design
(добавлено в Health 2.1) -
/sys/class/power_supply/*/current_avg
-
/sys/class/power_supply/*/current_max
-
/sys/class/power_supply/*/current_now
-
/sys/class/power_supply/*/cycle_count
-
/sys/class/power_supply/*/health
-
/sys/class/power_supply/*/online
-
/sys/class/power_supply/*/present
-
/sys/class/power_supply/*/status
-
/sys/class/power_supply/*/technology
-
/sys/class/power_supply/*/temp
-
/sys/class/power_supply/*/time_to_full_now
(добавлено в Health 2.1) -
/sys/class/power_supply/*/type
-
/sys/class/power_supply/*/voltage_max
-
/sys/class/power_supply/*/voltage_now
Любая реализация HAL для работоспособности конкретного устройства, использующая libbatterymonitor
, по умолчанию обращается к этим интерфейсам ядра, если только это не переопределено в конструкторе класса реализации работоспособности.
Если эти файлы отсутствуют или недоступны из healthd
или службы по умолчанию (например, файл представляет собой символическую ссылку на папку поставщика, доступ к которой запрещён из-за неправильно настроенной политики SELinux), они могут работать некорректно. Поэтому могут потребоваться дополнительные изменения SELinux, специфичные для поставщика, даже если используется реализация по умолчанию.
Некоторые интерфейсы ядра, используемые в Health 2.1, такие как /sys/class/power_supply/*/capacity_level
и /sys/class/power_supply/*/time_to_full_now
, могут быть необязательными. Однако, чтобы предотвратить некорректное поведение фреймворка из-за отсутствия интерфейсов ядра, рекомендуется выбрать CL 1398913 перед сборкой службы Health HAL 2.1.
Тестирование
В Android 11 включены новые тесты VTS , написанные специально для health@2.1 HAL. Если устройство заявляет health@2.1 HAL в манифесте устройства, оно должно пройти соответствующие тесты VTS. Тесты написаны как для экземпляра по умолчанию (чтобы убедиться, что устройство правильно реализует HAL), так и для резервного экземпляра (чтобы убедиться, что healthd
продолжает корректно работать до его удаления).
Требования к информации о батарее
Стандарт Health 2.0 HAL устанавливает набор требований к интерфейсу HAL, но соответствующие тесты VTS обеспечивают их соблюдение относительно мягко. В Android 11 добавлены новые тесты VTS для обеспечения соблюдения следующих требований на устройствах с Android 11 и более поздними версиями:
- Единицами мгновенного и среднего тока батареи должны быть микроамперы (мкА).
- Знак мгновенного и среднего тока батареи должен быть верным. А именно:
- ток == 0, когда состояние батареи
UNKNOWN
- ток > 0, когда состояние батареи —
CHARGING
- ток <= 0, когда состояние батареи
NOT_CHARGING
- ток < 0, когда состояние батареи -
DISCHARGING
- Не применяется, если аккумулятор
FULL
- ток == 0, когда состояние батареи
- Состояние аккумулятора должно соответствовать текущему состоянию, независимо от того, подключен ли источник питания. В частности:
- Состояние батареи должно быть одним из следующих:
CHARGING
,NOT_CHARGING
илиFULL
, только если подключен источник питания; - Состояние батареи должно быть
DISCHARGING
только в том случае, если источник питания отключен.
- Состояние батареи должно быть одним из следующих:
Если вы используете libbatterymonitor
в своей реализации и передаете значения из интерфейсов ядра, убедитесь, что узлы sysfs сообщают правильные значения:
- Убедитесь, что ток батареи отображается с правильным знаком и единицами измерения. Это касается следующих узлов sysfs:
-
/sys/class/power_supply/*/current_avg
-
/sys/class/power_supply/*/current_max
-
/sys/class/power_supply/*/current_now
- Положительные значения указывают на поступающий ток в батарею.
- Значения должны быть в микроамперах (мкА).
-
- Убедитесь, что напряжение батареи указано в микровольтах (мкВ). Это относится к следующим узлам sysfs:
-
/sys/class/power_supply/*/voltage_max
-
/sys/class/power_supply/*/voltage_now
- Обратите внимание, что реализация HAL по умолчанию делит
voltage_now
на 1000 и выдаёт значения в милливольтах (мВ). См. @1.0::HealthInfo .
-
Подробную информацию см. в разделе Класс источника питания Linux .
, В Android 11 весь код healthd
рефакторится в libhealthloop
и libhealth2impl
, а затем модифицируется для реализации health@2.1 HAL. Эти две библиотеки статически связаны с health@2.0-impl-2.1
, сквозной реализацией Health 2.1. Статически связанные библиотеки позволяют health@2.0-impl-2.1
выполнять ту же работу, что и healthd
, например, запускать healthd_mainloop
и осуществлять опрос. На этапе init health@2.1-service
регистрирует реализацию интерфейса IHealth
в hwservicemanager
. При обновлении устройств с образом поставщика Android 8.x или 9 и фреймворком Android 11 образ поставщика может не предоставлять службу health@2.1. Обратная совместимость со старыми образами поставщика обеспечивается расписанием устаревания .
Для обеспечения обратной совместимости:
-
healthd
регистрируетIHealth
вhwservicemanager
несмотря на то, что это системный демон.IHealth
добавляется в системный манифест с именем экземпляра «backup». - Фреймворк и
storaged
взаимодействуют сhealthd
черезhwbinder
вместоbinder
. - Код для framework и
storaged
изменен таким образом, чтобы при наличии извлекался экземпляр «default», а затем «backup».- Клиентский код C++ использует логику, определенную в
libhealthhalutils
. - Клиентский код Java использует логику, определенную в
HealthServiceWrapper
.
- Клиентский код C++ использует логику, определенную в
- После того, как IHealth/default станет широкодоступным и образы поставщиков Android 8.1 будут объявлены устаревшими, IHealth/backup и
healthd
могут быть объявлены устаревшими.
Переменные сборки, специфичные для платы, для healthd
BOARD_PERIODIC_CHORES_INTERVAL_*
— это переменные, специфичные для платы, используемые для сборки healthd
. В связи с разделением сборки по системе и производителю, специфичные для платы значения не могут быть определены для системных модулей. Эти значения ранее переопределялись в устаревшей функции healthd_board_init
.
В health@2.1 поставщики могут переопределять эти два значения интервалов периодических задач в структуре healthd_config
перед передачей в конструктор класса реализации health. Класс реализации health должен наследоваться от android::hardware::health::V2_1::implementation::Health
.
Внедрить сервис Health 2.1
Информацию о внедрении сервиса Health 2.1 см. в файле hardware/interfaces/health/2.1/README.md .
Клиенты здравоохранения
У health@2.x есть следующие клиенты:
- Зарядное устройство. Использование кода
libbatterymonitor
иhealthd_common
реализовано вhealth@2.0-impl
. - recovery. Связь с
libbatterymonitor
заключена вhealth@2.0-impl
. Все вызовыBatteryMonitor
заменяются вызовами класса реализацииHealth
. BatteryManager.
BatteryManager.queryProperty(int id)
был единственным клиентомIBatteryPropertiesRegistrar.getProperty
.IBatteryPropertiesRegistrar.getProperty
был предоставленhealthd
и напрямую считывал/sys/class/power_supply
.Из соображений безопасности приложениям запрещено напрямую обращаться к HAL-уровнему состояния. В Android 9 и более поздних версиях служба связывания
IBatteryPropertiesRegistrar
предоставляется службойBatteryService
вместоhealthd
.BatteryService
делегирует вызов HAL-уровнему состояния для получения запрошенной информации.BatteryService. В Android 9 и более поздних версиях
BatteryService
используетHealthServiceWrapper
, чтобы определить, использовать ли экземпляр службы работоспособности по умолчанию отvendor
или резервный экземпляр службы работоспособности изhealthd
. ЗатемBatteryService
прослушивает события работоспособности черезIHealth.registerCallback
.Storaged. В Android 9 и более поздних версиях
storaged
используетlibhealthhalutils
, чтобы определить, использовать ли экземпляр службы работоспособности по умолчанию отvendor
или резервный экземпляр службы работоспособности изhealthd
. Затемstoraged
прослушивает события работоспособности черезIHealth.registerCallback
и извлекает информацию о хранилище.
Изменения SELinux
Health@2.1 HAL включает следующие изменения SELinux на платформе:
- Добавляет
android.hardware.health@2.1-service
вfile_contexts
.
Для устройств с собственной реализацией SELinux могут потребоваться некоторые изменения в настройках поставщика. Пример:
# device/<manufacturer>/<device>/sepolicy/vendor/hal_health_default.te
# Add device specific permissions to hal_health_default domain, especially
# if it links to board-specific libhealthd or implements storage APIs.
Интерфейсы ядра
Демон healthd
и реализация по умолчанию android.hardware.health@2.0-impl-2.1
обращаются к следующим интерфейсам ядра для получения информации о батарее:
-
/sys/class/power_supply/*/capacity_level
(добавлено в Health 2.1) -
/sys/class/power_supply/*/capacity
-
/sys/class/power_supply/*/charge_counter
-
/sys/class/power_supply/*/charge_full
-
/sys/class/power_supply/*/charge_full_design
(добавлено в Health 2.1) -
/sys/class/power_supply/*/current_avg
-
/sys/class/power_supply/*/current_max
-
/sys/class/power_supply/*/current_now
-
/sys/class/power_supply/*/cycle_count
-
/sys/class/power_supply/*/health
-
/sys/class/power_supply/*/online
-
/sys/class/power_supply/*/present
-
/sys/class/power_supply/*/status
-
/sys/class/power_supply/*/technology
-
/sys/class/power_supply/*/temp
-
/sys/class/power_supply/*/time_to_full_now
(добавлено в Health 2.1) -
/sys/class/power_supply/*/type
-
/sys/class/power_supply/*/voltage_max
-
/sys/class/power_supply/*/voltage_now
Любая реализация HAL для работоспособности конкретного устройства, использующая libbatterymonitor
, по умолчанию обращается к этим интерфейсам ядра, если только это не переопределено в конструкторе класса реализации работоспособности.
Если эти файлы отсутствуют или недоступны из healthd
или службы по умолчанию (например, файл представляет собой символическую ссылку на папку поставщика, доступ к которой запрещён из-за неправильно настроенной политики SELinux), они могут работать некорректно. Поэтому могут потребоваться дополнительные изменения SELinux, специфичные для поставщика, даже если используется реализация по умолчанию.
Некоторые интерфейсы ядра, используемые в Health 2.1, такие как /sys/class/power_supply/*/capacity_level
и /sys/class/power_supply/*/time_to_full_now
, могут быть необязательными. Однако, чтобы предотвратить некорректное поведение фреймворка из-за отсутствия интерфейсов ядра, рекомендуется выбрать CL 1398913 перед сборкой службы Health HAL 2.1.
Тестирование
В Android 11 включены новые тесты VTS , написанные специально для health@2.1 HAL. Если устройство заявляет health@2.1 HAL в манифесте устройства, оно должно пройти соответствующие тесты VTS. Тесты написаны как для экземпляра по умолчанию (чтобы убедиться, что устройство правильно реализует HAL), так и для резервного экземпляра (чтобы убедиться, что healthd
продолжает корректно работать до его удаления).
Требования к информации о батарее
Стандарт Health 2.0 HAL устанавливает набор требований к интерфейсу HAL, но соответствующие тесты VTS обеспечивают их соблюдение относительно мягко. В Android 11 добавлены новые тесты VTS для обеспечения соблюдения следующих требований на устройствах с Android 11 и более поздними версиями:
- Единицами мгновенного и среднего тока батареи должны быть микроамперы (мкА).
- Знак мгновенного и среднего тока батареи должен быть верным. А именно:
- ток == 0, когда состояние батареи
UNKNOWN
- ток > 0, когда состояние батареи —
CHARGING
- ток <= 0, когда состояние батареи
NOT_CHARGING
- ток < 0, когда состояние батареи -
DISCHARGING
- Не применяется, если аккумулятор
FULL
- ток == 0, когда состояние батареи
- Состояние аккумулятора должно соответствовать текущему состоянию, независимо от того, подключен ли источник питания. В частности:
- Состояние батареи должно быть одним из следующих:
CHARGING
,NOT_CHARGING
илиFULL
, только если подключен источник питания; - Состояние батареи должно быть
DISCHARGING
только в том случае, если источник питания отключен.
- Состояние батареи должно быть одним из следующих:
Если вы используете libbatterymonitor
в своей реализации и передаете значения из интерфейсов ядра, убедитесь, что узлы sysfs сообщают правильные значения:
- Убедитесь, что ток батареи отображается с правильным знаком и единицами измерения. Это касается следующих узлов sysfs:
-
/sys/class/power_supply/*/current_avg
-
/sys/class/power_supply/*/current_max
-
/sys/class/power_supply/*/current_now
- Положительные значения указывают на поступающий ток в батарею.
- Значения должны быть в микроамперах (мкА).
-
- Убедитесь, что напряжение батареи указано в микровольтах (мкВ). Это относится к следующим узлам sysfs:
-
/sys/class/power_supply/*/voltage_max
-
/sys/class/power_supply/*/voltage_now
- Обратите внимание, что реализация HAL по умолчанию делит
voltage_now
на 1000 и выдаёт значения в милливольтах (мВ). См. @1.0::HealthInfo .
-
Подробную информацию см. в разделе Класс источника питания Linux .