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

Implementando Saúde 2.0

Todos healthd código foi reformulado em health@2.0-impl e libhealthservice , então modificado para implementar health@2.0 HAL. Estas duas bibliotecas estão ligados estaticamente por health@2.0-service, permitindo-lhe fazer o trabalho previamente feito por healthd (ou seja, executar o healthd_mainloop e fazer polling). Na inicialização, o health@2.0-service regista 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 é reforçado pela programação de depreciação .

Para resolver esse problema:

  1. healthd registra IHealth para hwservicemanager (apesar de ser um daemon do sistema). IHealth é adicionado ao manifesto do sistema, com o nome de instância "backup".
  2. Quadro e storaged comunicar com healthd através hwbinder em vez de binder .
  3. Código para enquadramento e storaged são alterados para buscar a instância de "default" se disponível, em seguida, "backup".
    • Código de cliente C ++ usa a lógica definida em libhealthhalutils .
    • Código de cliente Java usa a lógica definida em HealthServiceWrapper .
  4. Depois iHealth / default é amplamente disponível e imagens Android 8.1 fornecedores estão obsoletos, iHealth / backup e healthd pode ser substituído. Para mais detalhes, consulte Deprecating health@1.0 .

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

BOARD_PERIODIC_CHORES_INTERVAL_* são variáveis específicas de placa usado para construir healthd . Como parte do sistema / fornecedor divisão de construção, valores específicos de bordo não podem ser definidas para módulos do sistema. Em health@2.0, os fornecedores podem substituir esses dois valores em healthd_mode_ops->init (soltando libhealthservice dependência em health@2.0-service.<device> e re-implementação desta função).

Biblioteca de implementação estática

Ao contrário de outras bibliotecas de implementação HAL, o health@2.0-impl biblioteca de implementação é uma biblioteca estática para que health@2.0-service, carregador, recuperação e ligação legado healthd.

health@2.0.impl implementa IHealth como descrito acima e se destina a envolver em torno de libbatterymonitor e libhealthd. BOARD . Esses usuários de health@2.0-impl não deve usar BatteryMonitor ou as funções em libhealthd diretamente; em vez disso, essas chamadas devem ser substituídos por chamadas para a Health aula, uma implementação do IHealth interface. Para generalizar ainda mais, healthd_common código também está incluído no health@2.0-impl. O novo healthd_common contém o resto do código comum entre health@2.0-service, carregador e healthd e chamadas em métodos iHealth em vez de BatteryMonitor.

Implementando 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, utilize android.hardware.health@2.0-service diretamente.
  • Não é suficiente para o dispositivo, criar o android.hardware.health@2.0-service.(device) Executável e incluem:

    #include <health2/service.h>
    int main() { return health_service_main(); }
    

Então:

  • Se específico de bordo libhealthd:

    • Existe, link para ele.
    • Não existe, fornecer implementações vazias para healthd_board_init e healthd_board_battery_update funções.
  • Se específico de bordo BOARD_PERIODIC_CHORES_INTERVAL_* variáveis:

    • São definidos, crie uma específica do dispositivo HealthServiceCommon.cpp (copiado de hardware/interfaces/health/2.0/utils/libhealthservice ) e personalizá-lo em healthd_mode_service_2_0_init .
    • Não estão definidos, link para libhealthservice estaticamente.
  • Se dispositivo:

    • Deve implementar getStorageInfo e getDiskStats APIs, fornecer a implementação em get_storage_info e get_disk_stats funções.
    • Não deve implementar essas APIs, conectar-se a libstoragehealthdefault estaticamente.
  • 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 / saúde / 2.0 / README.md .

Clientes de saúde

Veja os clientes de saúde para a saúde 2.1 HAL .

Mudanças SELinux

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

  • Adiciona health@2.0-service para file_contexts .
  • Permite system_server e storaged para uso hal_health .
  • Permite system_server ( BatteryService ) para registrar batteryproperties_service ( IBatteryPropertiesRegistrar ).
  • Permite healthd para fornecer hal_health .
  • Regras remove que permitem system_server / storaged pôr em healthd via aglutinante.
  • Regras remove que permitem healthd de registrar 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 de kernel

Veja as interfaces do kernel para a saúde 2.1 HAL .

Testando

Android 9 inclui novos testes VTS escritos especificamente para o HAL health@2.0. Se um dispositivo declara fornecer health@2.0 HAL no manifesto do dispositivo, ele deve passar nos testes VTS correspondentes. Testes são escritos tanto para a instância padrão (para assegurar que os instrumentos de dispositivos do HAL corretamente) e a instância de backup (para garantir que healthd continua a funcionar correctamente antes de ser removido).

Requisitos de informação da bateria

Veja os requisitos de informação da bateria .