A partir de 27 de março de 2025, recomendamos usar android-latest-release em vez de aosp-main para criar e contribuir com o AOSP. Para mais informações, consulte Mudanças no AOSP.

Esta página foi traduzida pela API Cloud Translation.

Implementando a Saúde 2.0

Todo o código healthd foi refatorado em [email protected] e libhealthservice e, em seguida, modificado para implementar [email protected] HAL. Essas duas bibliotecas são vinculadas estaticamente pelo [email protected], permitindo que ele faça o trabalho feito anteriormente pelo healthd (ou seja, execute o healthd_mainloop e faça o polling). No init, o [email protected] registra uma implementação da interface IHealth para hwservicemanager . Ao atualizar dispositivos com uma imagem de fornecedor do Android 8.x e uma estrutura do Android 9, o serviço [email protected] pode não ser fornecido pela imagem do fornecedor. Isso é imposto pelo cronograma de descontinuação .

Para resolver este problema:

healthd registra IHealth para hwservicemanager (apesar de ser um daemon do sistema). IHealth é adicionado ao manifesto do sistema, com o nome da instância "backup".
Framework e storaged se comunicam com healthd via hwbinder em vez de binder .
Código para framework e storaged são alterados para buscar a instância "default" se disponível, então "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 estiver amplamente disponível e as imagens de fornecedores do Android 8.1 forem preteridas, IHealth/backup e healthd poderão ser preteridos. Para obter mais detalhes, consulte Descontinuando [email protected] .

Variáveis de compilação específicas da placa para healthd

BOARD_PERIODIC_CHORES_INTERVAL_* são variáveis específicas da placa usadas para construir healthd . Como parte da divisão de construção do sistema/fornecedor, os valores específicos da placa não podem ser definidos para os módulos do sistema. No [email protected], os fornecedores podem substituir esses dois valores em healthd_mode_ops->init (eliminando a dependência libhealthservice em [email protected].<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 [email protected] é uma biblioteca estática à qual [email protected], carregador, recuperação e legado healthd link.

[email protected] implementa IHealth conforme descrito acima e destina-se a envolver libbatterymonitor e libhealthd. BOARD . Esses usuários do [email protected] não devem usar o BatteryMonitor ou as funções do libhealthd diretamente; em vez disso, essas chamadas devem ser substituídas por chamadas para a classe Health , uma implementação da interface IHealth . Para generalizar ainda mais, o código healthd_common também está incluído em [email protected]. O novo healthd_common contém o restante do código comum entre [email protected], carregador e healthd e chama os métodos IHealth em vez de BatteryMonitor.

Implementando o serviço Health 2.0

Ao implementar o serviço [email protected] para um dispositivo, se a implementação padrão for:

Suficiente para o dispositivo, use [email protected] diretamente.
Não é suficiente para o dispositivo, crie o executável [email protected].(device) e inclua:
```
#include <health2/service.h>
int main() { return health_service_main(); }
```

Então:

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

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

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

Para obter detalhes, consulte hardware/interfaces/health/2.0/README.md .

Clientes de saúde

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

Alterações do SELinux

O novo [email protected] HAL inclui as seguintes alterações no SELinux:

Adiciona [email protected] a file_contexts .
Permite que system_server e storaged usem hal_health .
Permite que o system_server ( BatteryService ) registre batteryproperties_service ( IBatteryPropertiesRegistrar ).
Permite que healthd forneça hal_health .
Remove as regras que permitem que o system_server / storaged chame o healthd por meio do fichário.
Remove as regras que permitem que o healthd registre o batteryproperties_service ( IBatteryPropertiesRegistrar ).

Para dispositivos com sua própria implementação, algumas alterações do fornecedor SELinux 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 integridade 2.1 HAL .

Teste

O Android 9 inclui novos testes VTS escritos especificamente para o [email protected] HAL. Se um dispositivo declara fornecer [email protected] HAL no manifesto do dispositivo, ele deve passar nos testes VTS correspondentes. Os testes são escritos para a instância padrão (para garantir que o dispositivo implemente a HAL corretamente) e para a instância de backup (para garantir que healthd continue funcionando corretamente antes de ser removido).

Requisitos de informações da bateria

Consulte Requisitos de informações da bateria .