Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Implementando Health 2.0

Todo el código de healthd se ha refactorizado en health@2.0-impl y libhealthservice , luego se ha modificado para implementar health@2.0 HAL. Estas dos bibliotecas están vinculadas estáticamente por health@2.0-service, lo que le permite realizar el trabajo realizado anteriormente por healthd (es decir, ejecutar healthd_mainloop y realizar sondeos). En init, health@2.0-service registra una implementación de la interfaz IHealth para hwservicemanager . Al actualizar dispositivos con una imagen de proveedor de Android 8.xy un marco de trabajo de Android 9, es posible que la imagen de proveedor no proporcione el servicio health@2.0. Esto se aplica mediante el calendario de desactivación .

Para resolver este problema:

  1. healthd registra IHealth en hwservicemanager (a pesar de ser un demonio del sistema). IHealth se agrega al manifiesto del sistema, con el nombre de instancia "respaldo".
  2. Marco y storaged comunican con healthd través hwbinder en vez de binder .
  3. El código para el marco y el storaged se cambian para recuperar la instancia "predeterminada" si está disponible, luego "copia de seguridad".
    • El código de cliente de C ++ usa la lógica definida en libhealthhalutils .
    • El código de cliente Java utiliza la lógica definida en HealthServiceWrapper .
  4. Una vez que IHealth / default esté ampliamente disponible y las imágenes del proveedor de Android 8.1 estén en desuso, IHealth / backup y healthd pueden quedar obsoletos. Para obtener más detalles, consulte Desactivación de health@1.0 .

Variables de construcción específicas de la placa para healthd

BOARD_PERIODIC_CHORES_INTERVAL_* son variables específicas de la placa que se utilizan para construir healthd . Como parte de la división de construcción del sistema / proveedor, los valores específicos de la placa no se pueden definir para los módulos del sistema. En health@2.0, los proveedores pueden anular estos dos valores en healthd_mode_ops->init ( libhealthservice dependencia health@2.0-service.<device> en health@2.0-service.<device> y volviendo a implementar esta función).

Biblioteca de implementación estática

A diferencia de otras bibliotecas de implementación de HAL, la biblioteca de implementación health@2.0-impl es una biblioteca estática a la que health@2.0-service, charger, recovery y legacy healthd link.

health@2.0.impl implementa IHealth como se describió anteriormente y está destinado a envolver libbatterymonitor y libhealthd. BOARD . Estos usuarios de health@2.0-impl no deben usar BatteryMonitor o las funciones en libhealthd directamente; en cambio, estas llamadas deben reemplazarse con llamadas a la clase Health , una implementación de la interfaz IHealth . Para generalizar más, el código healthd_common también se incluye en health@2.0-impl. El nuevo healthd_common contiene el resto del código común entre health@2.0-service, charger y healthd y llama a los métodos IHealth en lugar de BatteryMonitor.

Implementación del servicio Health 2.0

Al implementar el servicio health@2.0 para un dispositivo, si la implementación predeterminada es:

  • Suficiente para el dispositivo, use android.hardware.health@2.0-service directamente.
  • No es suficiente para el dispositivo, cree el ejecutable android.hardware.health@2.0-service.(device) e incluya:

    #include <health2/service.h>
    int main() { return health_service_main(); }
    

Entonces:

  • Si libhealthd: específico de la libhealthd:

    • Existe, enlace a él.
    • No existe, proporcione implementaciones vacías para las funciones healthd_board_init y healthd_board_battery_update .
  • Si las variables BOARD_PERIODIC_CHORES_INTERVAL_* específicas de la BOARD_PERIODIC_CHORES_INTERVAL_* :

    • Están definidos, cree un HealthServiceCommon.cpp específico del dispositivo (copiado de hardware/interfaces/health/2.0/utils/libhealthservice ) y personalícelo en healthd_mode_service_2_0_init .
    • No están definidos, enlazan a libhealthservice estáticamente.
  • Si dispositivo:

    • Debe implementar las API getStorageInfo y getDiskStats , proporcionar la implementación en las funciones get_storage_info y get_disk_stats .
    • No debe implementar esas API, enlace a libstoragehealthdefault estáticamente.
  • Actualice los permisos necesarios de SELinux.

  • Implemente HAL en recuperación instalando una implementación de paso a través en la imagen de recuperación. Ejemplo:

    // 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>
    

Para obtener más información, consulte hardware / interfaces / health / 2.0 / README.md .

Clientes de salud

Consulte Clientes de salud para la salud 2.1 HAL .

Cambios de SELinux

El nuevo health@2.0 HAL incluye los siguientes cambios de SELinux:

  • Agrega health@2.0-service a file_contexts .
  • Permite system_server y storaged al uso hal_health .
  • Permite que system_server ( BatteryService ) registre batteryproperties_service ( IBatteryPropertiesRegistrar ).
  • Permite que healthd proporcione hal_health .
  • Elimina las reglas que permiten system_server / storaged poner en healthd a través de aglutinante.
  • Elimina las reglas que permiten a healthd registrar batteryproperties_service ( IBatteryPropertiesRegistrar ).

Para dispositivos con su propia implementación, pueden ser necesarios algunos cambios de SELinux del proveedor. Ejemplo:

# 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.

Interfaces del kernel

Consulte Interfaces del kernel para salud 2.1 HAL .

Pruebas

Android 9 incluye nuevas pruebas VTS escritas específicamente para health@2.0 HAL. Si declara un dispositivo para proporcionar HAL health@2.0 en el manifiesto del dispositivo, debe pasar las pruebas correspondientes VTS. Las pruebas se escriben tanto para la instancia predeterminada (para garantizar que el dispositivo implemente la HAL correctamente) como para la instancia de respaldo (para garantizar que healthd continúe funcionando correctamente antes de que se elimine).

Requisitos de información de la batería

Consulte Requisitos de información de la batería .