Весь код healthd
был преобразован в health@2.0-impl и libhealthservice
, а затем изменен для реализации Health@2.0 HAL. Эти две библиотеки статически связаны сервисом health@2.0, что позволяет ему выполнять работу, ранее выполняемую healthd
(т.е. запускать healthd_mainloop
и выполнять опрос). В процессе инициализации служба health@2.0 регистрирует реализацию интерфейса IHealth
в hwservicemanager
. При обновлении устройств с образом поставщика Android 8.x и платформой Android 9 служба Health@2.0 может не предоставляться образом поставщика. Это обеспечивается графиком устаревания .
Чтобы решить эту проблему:
-
healthd
регистрируетIHealth
вhwservicemanager
(несмотря на то, что это системный демон).IHealth
добавляется в системный манифест с именем экземпляра «backup». - Framework и
storaged
взаимодействуют сhealthd
черезhwbinder
вместоbinder
. - Код для фреймворка и
storaged
изменен, чтобы получить экземпляр «по умолчанию», если он доступен, а затем «резервную копию».- Клиентский код C++ использует логику, определенную в
libhealthhalutils
. - Клиентский код Java использует логику, определенную в
HealthServiceWrapper
.
- Клиентский код C++ использует логику, определенную в
- После того, как IHealth/default станет широко доступным, а образы поставщиков Android 8.1 устарели, IHealth/backup и
healthd
могут быть объявлены устаревшими. Дополнительные сведения см. в разделе Прекращение поддержки health@1.0 .
Переменные сборки для платы для здоровья
BOARD_PERIODIC_CHORES_INTERVAL_*
— это переменные, специфичные для платы, которые используются для построения healthd
. В рамках разделения сборки системы/поставщика значения, специфичные для платы, не могут быть определены для системных модулей. В Health@2.0 поставщики могут переопределить эти два значения в healthd_mode_ops->init
(путем удаления зависимости libhealthservice
в health@2.0-service.<device>
и повторной реализации этой функции).
Статическая библиотека реализации
В отличие от других библиотек реализации HAL, библиотека реализации health@2.0-impl является статической библиотекой, с которой связаны Health@2.0-service, Charger, Recovery и устаревшие Healthd.
health@2.0.impl реализует IHealth
, как описано выше, и предназначен для работы с libbatterymonitor
и libhealthd. BOARD
. Эти пользователи health@2.0-impl не должны напрямую использовать BatteryMonitor
или функции libhealthd
; вместо этого эти вызовы следует заменить вызовами класса Health
, реализации интерфейса IHealth
. Для дальнейшего обобщения код healthd_common
также включен в health@2.0-impl. Новый healthd_common
содержит остальную часть общего кода между Health@2.0-сервисом, зарядным устройством и healthd
и вызывает методы IHealth вместо BatteryMonitor.
Внедрение службы Health 2.0
При реализации службы health@2.0 для устройства, если реализация по умолчанию:
- Достаточно для устройства, используйте
android.hardware.health@2.0-service
напрямую. Недостаточно для устройства, создайте исполняемый файл
android.hardware.health@2.0-service.(device)
и включите:#include <health2/service.h> int main() { return health_service_main(); }
Затем:
Если
libhealthd:
- Существует, ссылка на него.
- Не существует, предоставьте пустые реализации для
healthd_board_init
иhealthd_board_battery_update
.
Если переменные
BOARD_PERIODIC_CHORES_INTERVAL_*
к плате:- Определены, создайте
HealthServiceCommon.cpp
для конкретного устройства (скопированный изhardware/interfaces/health/2.0/utils/libhealthservice
) и настройте его вhealthd_mode_service_2_0_init
. - Не определены, статическая ссылка на
libhealthservice
.
- Определены, создайте
Если устройство:
- Следует реализовать API
getStorageInfo
иgetDiskStats
, предоставить реализацию вget_storage_info
иget_disk_stats
. - Не следует реализовывать эти API, ссылайтесь на
libstoragehealthdefault
статически.
- Следует реализовать API
Обновите необходимые разрешения SELinux.
Внедрите HAL в восстановление, установив сквозную реализацию в образ восстановления. Пример:
// Android.bp cc_library_shared { name: "android.hardware.health@2.0-impl-<device>", recovery_available: true, relative_install_path: "hw", static_libs: [ "android.hardware.health@2.0-impl", "libhealthd.<device>" // Include the following or implement device-specific storage APIs "libhealthstoragedefault", ], srcs: [ "HealthImpl.cpp", ], overrides: [ "android.hardware.health@2.0-impl-default", ], }
// HealthImpl.cpp #include <health2/Health.h> #include <healthd/healthd.h> using android::hardware::health::V2_0::IHealth; using android::hardware::health::V2_0::implementation::Health; extern "C" IHealth* HIDL_FETCH_IHealth(const char* name) { const static std::string providedInstance{"default"}; if (providedInstance != name) return nullptr; return Health::initInstance(&gHealthdConfig).get(); }
# device.mk PRODUCT_PACKAGES += android.hardware.health@2.0-impl-<device>
Подробнее см. в hardware/interfaces/health/2.0/README.md .
Клиенты здравоохранения
См. Клиенты Health для здоровья 2.1 HAL .
Изменения SELinux
Новый HAL Health@2.0 включает следующие изменения SELinux:
- Добавляет сервис health@2.0 в
file_contexts
. - Позволяет
system_server
иstoraged
использоватьhal_health
. - Позволяет
system_server
(BatteryService
) регистрироватьbatteryproperties_service
(IBatteryPropertiesRegistrar
). - Позволяет
healthd
предоставлятьhal_health
. - Удаляет правила, которые позволяют
system_server
/storaged
вызыватьhealthd
через биндер. - Удаляет правила, позволяющие
healthd
регистрироватьbatteryproperties_service
(IBatteryPropertiesRegistrar
).
Для устройств с собственной реализацией могут потребоваться некоторые изменения поставщика SELinux. Пример:
# device/<manufacturer>/<device>/sepolicy/vendor/file_contexts
/vendor/bin/hw/android\.hardware\.health@2\.0-service.<device> u:object_r:hal_health_default_exec:s0
# 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.
Интерфейсы ядра
См. Интерфейсы ядра для работоспособности 2.1 HAL .
Тестирование
Android 9 включает новые тесты VTS, написанные специально для HAL Health@2.0. Если устройство заявляет о предоставлении HAL Health@2.0 в манифесте устройства, оно должно пройти соответствующие тесты VTS. Тесты написаны как для экземпляра по умолчанию (чтобы убедиться, что устройство правильно реализует HAL), так и для резервного экземпляра (чтобы убедиться, что healthd
продолжает работать правильно, прежде чем он будет удален).