Внедрить Здоровье 2.1

В 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. Обратная совместимость со старыми образами поставщика обеспечивается расписанием устаревания .

Для обеспечения обратной совместимости:

  1. healthd регистрирует IHealth в hwservicemanager несмотря на то, что это системный демон. IHealth добавляется в системный манифест с именем экземпляра «backup».
  2. Фреймворк и storaged взаимодействуют с healthd через hwbinder вместо binder .
  3. Код для framework и storaged изменен таким образом, чтобы при наличии извлекался экземпляр «default», а затем «backup».
    • Клиентский код C++ использует логику, определенную в libhealthhalutils .
    • Клиентский код Java использует логику, определенную в HealthServiceWrapper .
  4. После того, как 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
  • Состояние аккумулятора должно соответствовать текущему состоянию, независимо от того, подключен ли источник питания. В частности:
    • Состояние батареи должно быть одним из следующих: 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. Обратная совместимость со старыми образами поставщика обеспечивается расписанием устаревания .

Для обеспечения обратной совместимости:

  1. healthd регистрирует IHealth в hwservicemanager несмотря на то, что это системный демон. IHealth добавляется в системный манифест с именем экземпляра «backup».
  2. Фреймворк и storaged взаимодействуют с healthd через hwbinder вместо binder .
  3. Код для framework и storaged изменен таким образом, чтобы при наличии извлекался экземпляр «default», а затем «backup».
    • Клиентский код C++ использует логику, определенную в libhealthhalutils .
    • Клиентский код Java использует логику, определенную в HealthServiceWrapper .
  4. После того, как 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
  • Состояние аккумулятора должно соответствовать текущему состоянию, независимо от того, подключен ли источник питания. В частности:
    • Состояние батареи должно быть одним из следующих: 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 .