O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Esta página foi traduzida pela API Cloud Translation.

Implemente a integridade 2.0

Todo o código healthd foi refatorizado para health@2.0-impl e libhealthservice, depois modificado para implementar a HAL health@2.0. Essas duas bibliotecas são vinculadas de forma estática pelo health@2.0-service, permitindo que ele faça o trabalho feito anteriormente por healthd, ou seja, execute o healthd_mainloop e faça a pesquisa. No init, o health@2.0-service registra uma implementação da interface IHealth para hwservicemanager. Ao fazer upgrade de dispositivos com uma imagem do fornecedor do Android 8.x e um framework do Android 9, o serviço health@2.0 pode não ser fornecido pela imagem do fornecedor. Isso é aplicado pela programação de descontinuação.

Para resolver esse problema:

healthd registra IHealth em hwservicemanager, apesar de ser um daemon do sistema. IHealth foi adicionado ao manifesto do sistema, com o nome de instância "backup".
O framework e o storaged se comunicam com o healthd por meio de hwbinder em vez de binder.
O código para framework e storaged foi alterado para buscar a instância "default", se disponível, e depois "backup".
- O código do cliente C++ usa a lógica definida em libhealthhalutils.
- O código do cliente Java usa a lógica definida em HealthServiceWrapper.
Depois que o IHealth/padrão estiver amplamente disponível e as imagens do fornecedor do Android 8.1 forem descontinuadas, o IHealth/backup e o healthd poderão ser descontinuados. Para mais detalhes, consulte Suspensão de uso do health@1.0.

Variáveis de build específicas da placa para o healthd

BOARD_PERIODIC_CHORES_INTERVAL_* são variáveis específicas da placa usadas para criar healthd. Como parte da divisão de build do sistema/fabricante, os valores específicos da placa não podem ser definidos para módulos do sistema. No health@2.0, os fornecedores podem substituir esses dois valores em healthd_mode_ops->init (reduzindo a dependência de libhealthservice em health@2.0-service.<device> e reimplementando essa função).

Biblioteca de implementação estática

Ao contrário de outras bibliotecas de implementação HAL, a biblioteca de implementação health@2.0-impl é uma biblioteca estática à qual health@2.0-service, carregador, recuperação e healthd legados se vinculam.

health@2.0.impl implementa IHealth conforme descrito acima e tem como objetivo envolver libbatterymonitor e libhealthd.BOARD. Esses usuários da health@2.0-impl não podem usar BatteryMonitor ou as funções em libhealthd diretamente. Em vez disso, essas chamadas precisam ser substituídas por chamadas na classe Health, uma implementação da interface IHealth. Para generalizar ainda mais, o código healthd_common também é incluído em health@2.0-impl. O novo healthd_common contém o restante do código comum entre health@2.0-service, charger e healthd e chama métodos IHealth em vez do BatteryMonitor.

Implementar o serviço do Health 2.0

Ao implementar o serviço health@2.0 para um dispositivo, se a implementação padrão for:

Suficiente para o dispositivo, use android.hardware.health@2.0-service diretamente.
Não é suficiente para o dispositivo, crie o executável android.hardware.health@2.0-service.(device) e inclua:
```
#include <health2/service.h>
int main() { return health_service_main(); }
```

Depois, siga estas instruções:

Se for específico para o dispositivo libhealthd:
- Existe, vincule a ele.
- Não existe, forneça implementações vazias para as funções healthd_board_init e healthd_board_battery_update.
Se as variáveis BOARD_PERIODIC_CHORES_INTERVAL_* forem específicas da placa:
- Se a definição for definida, crie um HealthServiceCommon.cpp específico para o dispositivo (copiado de hardware/interfaces/health/2.0/utils/libhealthservice) e o personalize em healthd_mode_service_2_0_init.
- Não estiverem definidos, vincular a libhealthservice estaticamente.
Se o dispositivo:
- Implemente as APIs getStorageInfo e getDiskStats e forneça a implementação nas funções get_storage_info e get_disk_stats.
- Não implemente essas APIs, vincule-as a libstoragehealthdefault de forma estática.
Atualize as permissões necessárias do SELinux.

Implemente o HAL na recuperação instalando uma implementação de passagem para a imagem de recuperação. Exemplo:

// 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 mais detalhes, consulte hardware/interfaces/health/2.0/README.md.

Clientes de saúde

Consulte Clientes de saúde para a HAL 2.1 da saúde.

Mudanças no SELinux

A nova HAL health@2.0 inclui as seguintes mudanças do SELinux:

O serviço health@2.0 foi adicionado a file_contexts.
Permite que system_server e storaged usem hal_health.
Permite que system_server (BatteryService) registre batteryproperties_service (IBatteryPropertiesRegistrar).
Permite que healthd forneça hal_health.
Remove as regras que permitem que system_server e storaged chamem healthd pelo binder.
As regras que permitem que healthd registre batteryproperties_service (IBatteryPropertiesRegistrar) foram removidas.

Para dispositivos com implementação própria, algumas mudanças no SELinux do fornecedor podem ser necessárias. Exemplo:

# 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 do kernel

Consulte Interfaces do kernel para a HAL do app Saúde 2.1.

Teste

O Android 9 inclui novos testes VTS especificamente criados para a HAL health@2.0. Se um dispositivo declarar que fornece a HAL health@2.0 no manifesto do dispositivo, ele precisará passar nos testes VTS correspondentes. Os testes são escritos para a instância padrão (para garantir que o dispositivo implemente o HAL corretamente) e a instância de backup (para garantir que o healthd continue funcionando corretamente antes de ser removido).

Requisitos de informações sobre a bateria

Consulte Requisitos de informações sobre a bateria.