Todo healthd
código ha sido reprogramado para health@2.0-impl y libhealthservice
, a continuación, modificado para implementar HAL health@2.0. Estas dos bibliotecas están vinculados estáticamente por health@2.0-service, lo que le permite hacer el trabajo previamente realizado por healthd
(es decir, ejecutar el healthd_mainloop
y hacer polling). En init, el health@2.0-service registra una implementación de la interfaz de IHealth
a 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 hace cumplir por el programa de desaprobación .
Para resolver este problema:
-
healthd
registraIHealth
ahwservicemanager
(a pesar de ser un demonio de sistema).IHealth
se añade al manifiesto del sistema, con el nombre de instancia "copia de seguridad". - Marco y
storaged
comunican conhealthd
travéshwbinder
en vez debinder
. - Código de marco y
storaged
se cambian a buscar la instancia "por defecto" si está disponible, a continuación, "copia de seguridad".- Código de cliente C ++ utiliza la lógica definida en
libhealthhalutils
. - Código de cliente Java utiliza la lógica definida en
HealthServiceWrapper
.
- Código de cliente C ++ utiliza la lógica definida en
- Después de iHealth / default está ampliamente disponible y las imágenes de Android 8.1 proveedores están en desuso, iHealth / copia de seguridad y
healthd
puede ser obsoleta. Para más detalles, véase deprecating health@1.0 .
Variables de compilación específicas de la placa para healthd
BOARD_PERIODIC_CHORES_INTERVAL_*
son variables pensión específico utilizado para construir healthd
. Como parte del sistema / proveedor de formación dividida, los valores tablero-específicas no pueden ser definidos para los módulos del sistema. En health@2.0, los proveedores pueden anular estos dos valores en healthd_mode_ops->init
(dejando caer libhealthservice
dependencia en health@2.0-service.<device>
y re-aplicación de esta función).
Biblioteca de implementación estática
A diferencia de otras bibliotecas de aplicación HAL, la biblioteca health@2.0-impl aplicación es una biblioteca estática a la que health@2.0-service, cargador, recuperación y enlace legado healthd.
health@2.0.impl implementa IHealth
como se describe anteriormente y está destinado a envolver alrededor de libbatterymonitor
y libhealthd. BOARD
. Estos usuarios de health@2.0-impl no deben utilizar BatteryMonitor
o las funciones en libhealthd
directamente; En su lugar, estas llamadas deben ser reemplazadas por llamadas a la Health
de clase, una implementación de la IHealth
interfaz. Para generalizar más, healthd_common
código 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, cargador, y healthd
y pone en 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, utilice
android.hardware.health@2.0-service
directamente. No suficiente para el dispositivo, crear el
android.hardware.health@2.0-service.(device)
Ejecutable e incluyen:#include <health2/service.h> int main() { return health_service_main(); }
Luego:
Si la tarjeta específica
libhealthd:
- Existe, enlace a él.
- No existe, para proporcionar implementaciones vacías
healthd_board_init
yhealthd_board_battery_update
funciones.
Si la tarjeta específica
BOARD_PERIODIC_CHORES_INTERVAL_*
variables:- Se definen, crear un dispositivo específico
HealthServiceCommon.cpp
(copiado dehardware/interfaces/health/2.0/utils/libhealthservice
) y personalizarlo enhealthd_mode_service_2_0_init
. - No están definidos, enlace a
libhealthservice
estáticamente.
- Se definen, crear un dispositivo específico
Si dispositivo:
- Debe aplicar
getStorageInfo
ygetDiskStats
API, proporcionar a la aplicación enget_storage_info
yget_disk_stats
funciones. - No debe poner en práctica esas API, enlazar a
libstoragehealthdefault
estáticamente.
- Debe aplicar
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 más detalles, consulte el hardware / las interfaces / salud / 2.0 / README.md .
Clientes de salud
Ver clientes de salud para la salud 2.1 HAL .
Cambios de SELinux
El nuevo health@2.0 HAL incluye los siguientes cambios de SELinux:
- Health@2.0-service añade a
file_contexts
. - Permite
system_server
ystoraged
al usohal_health
. - Permite
system_server
(BatteryService
) para registrarbatteryproperties_service
(IBatteryPropertiesRegistrar
). - Permite
healthd
para proporcionarhal_health
. - Elimina las reglas que permiten
system_server
/storaged
poner enhealthd
a través de aglutinante. - Elimina las reglas que permiten
healthd
para registrarbatteryproperties_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
Ver las interfaces del kernel para la salud 2.1 HAL .
Pruebas
Android 9 incluye nuevas pruebas VTS escritos específicamente para la HAL health@2.0. Si un dispositivo declara proporcionar health@2.0 HAL en el manifiesto del dispositivo, debe pasar las pruebas VTS correspondientes. Las pruebas se escriben tanto para la instancia predeterminada (para asegurar que los implementos de dispositivos la HAL correctamente) y la instancia de copia de seguridad (para asegurar que healthd
sigue correctamente a la función antes de que se elimina).