Внедрение Здоровье 2.0

Весь код healthd был преобразован в [email protected] и libhealthservice , а затем изменен для реализации [email protected] HAL. Эти две библиотеки статически связаны сервисом [email protected], что позволяет ему выполнять работу, ранее выполняемую healthd (т.е. запускать healthd_mainloop и выполнять опрос). В процессе инициализации служба [email protected] регистрирует реализацию интерфейса IHealth в hwservicemanager . При обновлении устройств с образом поставщика Android 8.x и платформой Android 9 служба [email protected] может не предоставляться образом поставщика. Это обеспечивается графиком устаревания .

Чтобы решить эту проблему:

  1. healthd регистрирует IHealth в hwservicemanager (несмотря на то, что это системный демон). IHealth добавляется в системный манифест с именем экземпляра «backup».
  2. Framework и storaged взаимодействуют с healthd через hwbinder вместо binder .
  3. Код для фреймворка и storaged изменен, чтобы получить экземпляр «по умолчанию», если он доступен, а затем «резервную копию».
    • Клиентский код C++ использует логику, определенную в libhealthhalutils .
    • Клиентский код Java использует логику, определенную в HealthServiceWrapper .
  4. После того, как IHealth/default станет широко доступным, а образы поставщиков Android 8.1 устарели, IHealth/backup и healthd могут быть объявлены устаревшими. Дополнительные сведения см. в разделе Прекращение поддержки [email protected] .

Переменные сборки для платы для здоровья

BOARD_PERIODIC_CHORES_INTERVAL_* — это переменные, специфичные для платы, которые используются для построения healthd . В рамках разделения сборки системы/поставщика значения, специфичные для платы, не могут быть определены для системных модулей. В [email protected] поставщики могут переопределить эти два значения в healthd_mode_ops->init (путем удаления зависимости libhealthservice в [email protected].<device> и повторной реализации этой функции).

Статическая библиотека реализации

В отличие от других библиотек реализации HAL, библиотека реализации [email protected] является статической библиотекой, с которой связаны [email protected], Charger, Recovery и устаревшие Healthd.

[email protected] реализует IHealth , как описано выше, и предназначен для работы с libbatterymonitor и libhealthd. BOARD . Эти пользователи [email protected] не должны напрямую использовать BatteryMonitor или функции libhealthd ; вместо этого эти вызовы следует заменить вызовами класса Health , реализации интерфейса IHealth . Для дальнейшего обобщения код healthd_common также включен в [email protected]. Новый healthd_common содержит остальную часть общего кода между [email protected]сервисом, зарядным устройством и healthd и вызывает методы IHealth вместо BatteryMonitor.

Внедрение службы Health 2.0

При реализации службы [email protected] для устройства, если реализация по умолчанию:

  • Достаточно для устройства, используйте [email protected] напрямую.

  • Недостаточно для устройства, создайте исполняемый файл [email protected].(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 статически.

  • Обновите необходимые разрешения SELinux.

  • Внедрите HAL в восстановление, установив сквозную реализацию в образ восстановления. Пример:

    // Android.bp
cc_library_shared {
    name: "[email protected]<device>",
    recovery_available: true,
    relative_install_path: "hw",
    static_libs: [
        "[email protected]",
        "libhealthd.<device>"
        // Include the following or implement device-specific storage APIs
        "libhealthstoragedefault",
    ],
    srcs: [
        "HealthImpl.cpp",
    ],
    overrides: [
        "[email protected]",
    ],
}

    // 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 += [email protected]<device>

Подробнее см. в hardware/interfaces/health/2.0/README.md .

Клиенты здравоохранения

См. Клиенты Health для здоровья 2.1 HAL .

Изменения SELinux

Новый HAL [email protected] включает следующие изменения SELinux:

  • Добавляет сервис [email protected] в 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 [email protected]. Если устройство заявляет о предоставлении HAL [email protected] в манифесте устройства, оно должно пройти соответствующие тесты VTS. Тесты написаны как для экземпляра по умолчанию (чтобы убедиться, что устройство правильно реализует HAL), так и для резервного экземпляра (чтобы убедиться, что healthd продолжает работать правильно, прежде чем он будет удален).

Требования к информации об аккумуляторе

См. Требования к информации об аккумуляторе .