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

Implementando Saúde 2.1

Em Android 11, todos healthd código é reformulado em libhealthloop e libhealth2impl , então modificado para implementar o HAL health@2.1. Estas duas bibliotecas estão ligados estaticamente por health@2.0-impl-2.1 , a implementação passthrough da saúde 2.1. As bibliotecas estaticamente ligadas permitir health@2.0-impl-2.1 para fazer o mesmo trabalho que healthd , como a execução healthd_mainloop e votação. Na inicialização, o health@2.1-service regista uma implementação da interface IHealth para hwservicemanager . Ao atualizar dispositivos com uma imagem de fornecedor Android 8.x ou 9 e uma estrutura Android 11, a imagem do fornecedor pode não fornecer o serviço health@2.1. Compatibilidade com imagens de fornecedores de idade é imposta pelo cronograma depreciação .

Para garantir compatibilidade com versões anteriores:

  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. O quadro e storaged comunicar com healthd via hwbinder vez de binder .
  3. O código para a estrutura 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 da divisão de construção do sistema / fornecedor, valores específicos de bordo não podem ser definidas para módulos do sistema. Estes valores usados para ser substituído na função obsoleta healthd_board_init .

Em health@2.1, os fornecedores podem substituir essas duas tarefas periódicas valores do intervalo no healthd_config struct antes de passar para o construtor classe de implementação saúde. A classe de implementação saúde deve herdar de android::hardware::health::V2_1::implementation::Health .

Implementando o serviço Health 2.1

Para obter informações sobre a implementação do serviço de Saúde 2.1, consulte hardware / interfaces / saúde / 2,1 / README.md .

Clientes de saúde

health@2.x tem os seguintes clientes:

  • carregador. O uso de libbatterymonitor e healthd_common código é envolto em health@2.0-impl .
  • recuperação. A ligação para libbatterymonitor é envolto em health@2.0-impl . Todas as chamadas para BatteryMonitor são substituídos por chamadas para a Health classe de implementação.
  • BatteryManager. BatteryManager.queryProperty(int id) era o único cliente de IBatteryPropertiesRegistrar.getProperty . IBatteryPropertiesRegistrar.getProperty foi fornecido por healthd e ler diretamente /sys/class/power_supply .

    Como uma consideração de segurança, os aplicativos não têm permissão para chamar o HAL de integridade diretamente. No Android 9 e superior, o serviço de ligante IBatteryPropertiesRegistrar é fornecido por BatteryService em vez de healthd . BatteryService delegados a chamada para o HAL saúde para recuperar as informações solicitadas.

  • BatteryService. Em Android 9 e superior, BatteryService usa HealthServiceWrapper para determinar se deve usar a instância do serviço de saúde padrão de vendor ou usar a instância do serviço de saúde de backup a partir healthd . BatteryService então escuta para eventos de saúde através IHealth.registerCallback .

  • Estocado. Em Android 9 e superior, storaged usos libhealthhalutils para determinar se deve usar a instância do serviço de saúde padrão de vendor ou usar a instância do serviço de saúde de backup a partir healthd . storaged então escuta para eventos de saúde através IHealth.registerCallback e recupera informações de armazenamento.

Mudanças SELinux

O HAL health@2.1 inclui as seguintes alterações SELinux na plataforma:

  • Adiciona android.hardware.health@2.1-service para file_contexts .

Para dispositivos com sua própria implementação, algumas alterações do fornecedor SELinux podem ser necessárias. Exemplo:

# 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

O healthd daemon e a implementação padrão android.hardware.health@2.0-impl-2.1 acesso as seguintes interfaces do kernel para recuperar informações sobre a bateria:

  • /sys/class/power_supply/*/capacity_level (adicionado na saúde 2.1)
  • /sys/class/power_supply/*/capacity
  • /sys/class/power_supply/*/charge_counter
  • /sys/class/power_supply/*/charge_full
  • /sys/class/power_supply/*/charge_full_design (adicionado na saúde 2.1)
  • /sys/class/power_supply/*/current_avg
  • /sys/class/power_supply/*/current_max
  • /sys/class/power_supply/*/current_now
  • /sys/class/power_supply/*/cycle_count
  • /sys/class/power_supply/*/health
  • /sys/class/power_supply/*/online
  • /sys/class/power_supply/*/present
  • /sys/class/power_supply/*/status
  • /sys/class/power_supply/*/technology
  • /sys/class/power_supply/*/temp
  • /sys/class/power_supply/*/time_to_full_now (adicionado na saúde 2.1)
  • /sys/class/power_supply/*/type
  • /sys/class/power_supply/*/voltage_max
  • /sys/class/power_supply/*/voltage_now

Qualquer implementação HAL saúde específicas de dispositivo que usa libbatterymonitor acessa essas interfaces do kernel por padrão, a menos que substituída no construtor da classe implementação saúde.

Se esses arquivos estão ausentes ou são inacessíveis a partir healthd ou do serviço padrão (por exemplo, o arquivo é um link simbólico para uma pasta específica do fornecedor que nega o acesso por causa da política SELinux mal configurado), eles podem não funcionar corretamente. Portanto, alterações adicionais do SELinux específicas do fornecedor podem ser necessárias, mesmo que a implementação padrão seja usada.

Algumas interfaces do kernel usados em Saúde 2.1, tais como /sys/class/power_supply/*/capacity_level e /sys/class/power_supply/*/time_to_full_now , podem ser opcionais. No entanto, para evitar comportamentos quadro incorretas resultantes da falta de interfaces do kernel, recomenda-se a cereja-escolher CL 1398913 antes de construir o serviço de saúde HAL 2.1.

Testando

Android 11 inclui novos testes VTS escritos especificamente para o HAL health@2.1. Se um dispositivo declara health@2.1 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

O HAL 2.0 de saúde declara um conjunto de requisitos na interface do HAL, mas os testes VTS correspondentes são relativamente relaxados em aplicá-los. No Android 11, novos testes VTS são adicionados para cumprir os seguintes requisitos em dispositivos lançados com Android 11 e superior:

  • As unidades de corrente interna e média da bateria devem ser microampères (μA).
  • O sinal da corrente instantânea e média da bateria deve estar correto. Especificamente:
    • == atual 0 quando o estado da bateria é UNKNOWN
    • atual> 0 quando o estado da bateria é CHARGING
    • atual <= 0 quando o estado da bateria é NOT_CHARGING
    • atual <0, quando o estado da bateria é DISCHARGING
    • Não são aplicadas quando o estado da bateria é FULL
  • O status da bateria deve estar correto em relação ao fato de uma fonte de alimentação estar ou não conectada. Especificamente:
    • estado da bateria deve ser um dos CHARGING , NOT_CHARGING , ou FULL , se e apenas se um fonte de alimentação está ligado;
    • estado da bateria deve ser DISCHARGING se e somente se uma fonte de alimentação está desconectado.

Se você usar libbatterymonitor em sua implementação e passar por valores a partir de interfaces do kernel, garantir os sysfs nós estão relatando valores corretos:

  • Certifique-se de que a corrente da bateria seja relatada com o sinal e as unidades corretos. Isso inclui os seguintes nós sysfs:
    • /sys/class/power_supply/*/current_avg
    • /sys/class/power_supply/*/current_max
    • /sys/class/power_supply/*/current_now
    • Valores positivos indicam corrente de entrada na bateria.
    • Os valores devem estar em microampères (μA).
  • Certifique-se de que a tensão da bateria seja informada em microvolts (μV). Isso inclui os seguintes nós sysfs:
    • /sys/class/power_supply/*/voltage_max
    • /sys/class/power_supply/*/voltage_now
    • Note-se que as divisões de implementação HAL padrão voltage_now em 1000 e os valores relatórios em milivolts (mV). Veja @ 1.0 :: HealthInfo .

Para mais detalhes, consulte classe de alimentação Linux .