Implementar Saúde 2.0

Todo o código healthd foi refatorado em health@2.0-impl e libhealthservice e depois modificado para implementar health@2.0 HAL. Estas duas bibliotecas estão ligadas estaticamente pelo health@2.0-service, permitindo-lhe realizar o trabalho anteriormente realizado pelo healthd (ou seja, executar o healthd_mainloop e fazer polling). No init, o serviço health@2.0 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 health@2.0 pode não ser fornecido pela imagem do fornecedor. Isso é imposto pelo cronograma de depreciação .

Para resolver esse problema:

  1. healthd registra IHealth no hwservicemanager (apesar de ser um daemon do sistema). IHealth é adicionado ao manifesto do sistema, com o nome de instância "backup" .
  2. A estrutura e storaged se comunicam com healthd por meio de hwbinder em vez de binder .
  3. O código para estrutura e storaged é alterado para buscar a instância "default" se disponível, e 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 .
  4. Depois que IHealth/default estiver amplamente disponível e as imagens do fornecedor do Android 8.1 forem descontinuadas, IHealth/backup e healthd poderão ser descontinuados. Para obter mais detalhes, consulte Descontinuando health@1.0 .

Variáveis ​​de construção específicas da placa para saúde

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 módulos do sistema. No health@2.0, os fornecedores podem substituir esses dois valores em healthd_mode_ops->init (eliminando a dependência libhealthservice em health@2.0-service.<device> e reimplementando esta 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, charger, recovery e legado healthd se vinculam.

health@2.0.impl implementa IHealth conforme descrito acima e destina-se a envolver libbatterymonitor e libhealthd. BOARD . Esses usuários do health@2.0-impl não devem usar 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 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 de 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 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(); }
    

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:

    • Sã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 APIs getStorageInfo e getDiskStats , fornecer a implementação nas funções get_storage_info e get_disk_stats .
    • Não deveria implementar essas APIs, vincular estaticamente a libstoragehealthdefault .
  • Atualize as permissões necessárias do SELinux.

  • Implemente HAL na recuperação instalando uma implementação de passagem na 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 obter detalhes, consulte hardware/interfaces/health/2.0/README.md .

Clientes de saúde

Consulte Clientes do Health para Health 2.1 HAL .

Mudanças no SELinux

O novo HAL health@2.0 inclui as seguintes alterações no SELinux:

  • Adiciona health@2.0-service 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 regras que permitem que system_server e storaged liguem para healthd por meio do fichário.
  • Remove regras que permitem que healthd registre batteryproperties_service ( IBatteryPropertiesRegistrar ).

Para dispositivos com implementação própria, 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 Health 2.1 HAL .

Teste

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

Requisitos de informações da bateria

Consulte Requisitos de informações sobre bateria .