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 de healthd foi refatorado para health@2.0-impl e libhealthservice e modificada para implementar a HAL health@2.0. Essas duas opções as bibliotecas são vinculadas estaticamente pela health@2.0-service, permitindo que ela faça trabalho feito anteriormente por healthd, ou seja, executar healthd_mainloop e enquetes). No init, o health@2.0-service registra uma implementação do interface IHealth para hwservicemanager. Ao fazer upgrade de dispositivos 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 é obrigatório ao programação de descontinuação.

Para resolver esse problema:

healthd registra IHealth no hwservicemanager (apesar de ser um sistema do daemon). IHealth foi adicionado ao manifesto do sistema, com o nome da instância "backup".
O framework e o storaged se comunicam com o healthd pelo hwbinder. em vez de binder.
O código do framework e storaged são alterados 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 IHealth/default está amplamente disponível e as imagens de fornecedor do Android 8.1 são descontinuados, IHealth/backup e healthd podem ser descontinuados. Para mais Para mais detalhes, consulte Suspensão de uso do health@1.0.

Variáveis de build específicas da placa para integridade

BOARD_PERIODIC_CHORES_INTERVAL_* são variáveis específicas do quadro usadas para criar healthd. Como parte da divisão de criação do sistema/fornecedor, os valores específicos do quadro não podem ser definidas para módulos do sistema. Na Health@2.0, os fornecedores podem substituir esses dois valores em healthd_mode_ops->init (ao descartar libhealthservice) dependência em health@2.0-service.<device> e reimplementar essa função).

Biblioteca de implementação estática

Ao contrário de outras bibliotecas de implementação de HAL, a biblioteca de implementação health@2.0-impl é uma biblioteca estática para a qual health@2.0-service, carregador recuperação e integridade legada.

health@2.0.impl implementa IHealth conforme descrito acima e tem como objetivo unir ao redor de libbatterymonitor e libhealthd.BOARD. Esses Os usuários de health@2.0-impl não podem usar BatteryMonitor ou as funções em libhealthd diretamente; Essas chamadas devem ser substituídas por chamadas para a classe Health, uma implementação da interface IHealth. Para generalizar além disso, o código healthd_common também é incluído em health@2.0-impl. A nova healthd_common contém o restante do código comum entre health@2.0-service, carregador e healthd, e chama métodos IHealth em vez do BatteryMonitor.

Implementar o serviço Health 2.0

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

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

Depois, siga estas instruções:

Se for específico do board libhealthd:
- Existe, então crie um link para ele.
- Não existe, forneça implementações vazias para healthd_board_init e healthd_board_battery_update.
Se forem variáveis BOARD_PERIODIC_CHORES_INTERVAL_* específicas do quadro:
- São definidos, criam um HealthServiceCommon.cpp específico para o dispositivo (copiado) de hardware/interfaces/health/2.0/utils/libhealthservice) e personalizar em healthd_mode_service_2_0_init.
- Não estiverem definidos, vincular a libhealthservice estaticamente.
Se o dispositivo:
- Precisa implementar as APIs getStorageInfo e getDiskStats, além de fornecer o implementação nas funções get_storage_info e get_disk_stats.
- Estas APIs não podem ser implementadas. Vincular a libstoragehealthdefault estaticamente.
Atualize as permissões necessárias do SELinux.

Implemente a HAL na recuperação instalando uma implementação de passagem para o imagem de recuperação de desastres. 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 de saúde 2.1.

Mudanças no SELinux

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

Adiciona health@2.0-service a file_contexts.
Permite que system_server e storaged usem hal_health.
Permite que system_server (BatteryService) faça o registro batteryproperties_service (IBatteryPropertiesRegistrar).
Permite que healthd forneça hal_health.
Remove as regras que permitem que system_server e storaged chamem healthd pelo binder.
Remove as regras que permitem que o healthd registre o batteryproperties_service. (IBatteryPropertiesRegistrar).

Para dispositivos com implementação própria, algumas mudanças no SELinux do fornecedor podem ser necessários. 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 da Health 2.1.

Teste

O Android 9 inclui novos testes VTS escrita especificamente para a HAL health@2.0. Se um dispositivo declara fornecer HAL health@2.0 no manifesto do dispositivo, ele precisa passar nos testes de VTS correspondentes. Os testes são criados para a instância padrão (para garantir que o dispositivo implementa a HAL corretamente) e a instância de backup (para garantir que healthd continua a funcionar corretamente antes de ser removido).

Requisitos de informações da bateria

Consulte Requisitos de informações sobre a bateria.