Внедрить Здоровье 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 могут быть объявлены устаревшими. Для получения более подробной информации см. Deprecating health@1.0 .

Специфичные для платы переменные сборки для healthd

BOARD_PERIODIC_CHORES_INTERVAL_* — это переменные, специфичные для платы, используемые для сборки healthd . В рамках разделения сборки system/vendor значения, специфичные для платы, не могут быть определены для системных модулей. Эти значения ранее переопределялись в устаревшей функции healthd_board_init .

В health@2.1 поставщики могут переопределять эти два значения интервала периодических хлопот в структуре healthd_config перед передачей в конструктор класса реализации здоровья. Класс реализации здоровья должен наследоваться от 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 .