Implementar o Google Fit 2.1

No Android 11, todo o código healthd é reestruturado em libhealthloop e libhealth2impl, e depois modificado para implementar a HAL health@2.1. Essas duas bibliotecas são vinculadas de forma estática por health@2.0-impl-2.1, a implementação de passagem direta do Google Fit 2.1. As bibliotecas vinculadas estaticamente permitem que health@2.0-impl-2.1 faça o mesmo trabalho que healthd, como executar healthd_mainloop e fazer pesquisas. Na inicialização, o health@2.1-service registra uma implementação da interface IHealth para hwservicemanager. Ao fazer upgrade de dispositivos com uma imagem do fornecedor do Android 8.x ou 9 e um framework do Android 11, a imagem do fornecedor pode não fornecer o serviço health@2.1. A compatibilidade com versões anteriores de imagens antigas do fornecedor é aplicada pela programação de descontinuação.

Para garantir a 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 framework e o storaged se comunicam com o healthd por meio de hwbinder em vez de binder.
3. O código do framework e do storaged foi alterado para buscar a instância "padrão", 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.
4. Depois que o IHealth/padrão estiver amplamente disponível e as imagens do fornecedor do Android 8.1 forem descontinuadas, o IHealth/backup e o healthd poderão ser descontinuados. Para mais detalhes, consulte Suspensão de uso do health@1.0.

Variáveis de build específicas da placa para o healthd

BOARD_PERIODIC_CHORES_INTERVAL_* são variáveis específicas da placa usadas para criar healthd. Como parte da divisão de build do sistema/fabricante, os valores específicos da placa não podem ser definidos para módulos do sistema. Esses valores costumavam ser substituídos na função descontinuada healthd_board_init.

No health@2.1, os fornecedores podem substituir esses dois valores de intervalo de tarefas periódicas na estrutura healthd_config antes de passar para o construtor da classe de implementação de integridade. A classe de implementação de integridade precisa herdar de android::hardware::health::V2_1::implementation::Health.

Implementar o serviço Health 2.1

Para informações sobre a implementação do serviço Health 2.1, consulte hardware/interfaces/health/2.1/README.md.

Clientes de saúde

health@2.x tem os seguintes clientes:

• carregador. O uso do código libbatterymonitor e healthd_common é encapsulado em health@2.0-impl.
• recuperação. A vinculação a libbatterymonitor é envolvida em health@2.0-impl. Todas as chamadas para BatteryMonitor são substituídas por chamadas para a classe de implementação Health.

• BatteryManager. BatteryManager.queryProperty(int id) era o único cliente de IBatteryPropertiesRegistrar.getProperty. IBatteryPropertiesRegistrar.getProperty foi fornecido por healthd e leu diretamente /sys/class/power_supply.

  Por motivos de segurança, os apps não podem chamar o HAL de integridade diretamente. No Android 9 e versões mais recentes, o serviço de vinculação IBatteryPropertiesRegistrar é fornecido por BatteryService em vez de healthd. BatteryService delega a chamada para o HAL de integridade para recuperar as informações solicitadas.

• BatteryService. No Android 9 e versões mais recentes, BatteryService usa HealthServiceWrapper para determinar se vai usar a instância de serviço de integridade padrão de vendor ou a instância de serviço de integridade backup de healthd. Em seguida, BatteryService detecta eventos de integridade usando IHealth.registerCallback.

• Storaged. No Android 9 e versões mais recentes, storaged usa libhealthhalutils para determinar se vai usar a instância de serviço de integridade padrão de vendor ou a instância de serviço de integridade backup de healthd. Em seguida, storaged detecta eventos de integridade usando IHealth.registerCallback e recupera informações de armazenamento.

Mudanças no SELinux

O HAL health@2.1 inclui as seguintes mudanças do SELinux na plataforma:

• O método android.hardware.health@2.1-service foi adicionado a file_contexts.

Para dispositivos com implementação própria, algumas mudanças no SELinux do fornecedor 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 do kernel

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

• /sys/class/power_supply/*/capacity_level (adicionado no app 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 no Google Fit 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 no app Saúde 2.1)
• /sys/class/power_supply/*/type
• /sys/class/power_supply/*/voltage_max
• /sys/class/power_supply/*/voltage_now

Qualquer implementação de HAL de integridade específica do dispositivo que use libbatterymonitor acessa essas interfaces do kernel por padrão, a menos que seja substituída no construtor da classe de implementação de integridade.

Se esses arquivos estiverem ausentes ou inacessíveis em healthd ou no serviço padrão (por exemplo, se o arquivo for um link simbólico para uma pasta específica do fornecedor que nega o acesso devido à configuração incorreta da política SELinux), eles podem não funcionar corretamente. Portanto, outras mudanças específicas do fornecedor no SELinux podem ser necessárias, mesmo que a implementação padrão seja usada.

Algumas interfaces do kernel usadas no Google Fit 2.1, como /sys/class/power_supply/*/capacity_level e /sys/class/power_supply/*/time_to_full_now, podem ser opcionais. No entanto, para evitar comportamentos incorretos do framework resultantes de interfaces do kernel ausentes, recomendamos escolher CL 1398913 antes de criar o serviço HAL de saúde 2.1.

Teste

O Android 11 inclui novos testes VTS especificamente criados para a HAL health@2.1. Se um dispositivo declarar a HAL health@2.1 no manifesto do dispositivo, ele precisará passar nos testes VTS correspondentes. Os testes são escritos para a instância padrão (para garantir que o dispositivo implemente o HAL corretamente) e a instância de backup (para garantir que o healthd continue funcionando corretamente antes de ser removido).

Requisitos de informações sobre a bateria

A HAL do Health 2.0 declara um conjunto de requisitos na interface da HAL, mas os testes VTS correspondentes são relativamente flexíveis na aplicação deles. No Android 11, novos testes VTS foram adicionados para aplicar os seguintes requisitos em dispositivos lançados com o Android 11 e versões mais recentes:

• As unidades de corrente instantânea e média da bateria precisam ser microampéres (μA).
• O sinal da corrente instantânea e média da bateria precisa estar correto. Especificamente:
  • current == 0 quando o status da bateria é UNKNOWN
  • current > 0 quando o status da bateria é CHARGING
  • current <= 0 quando o status da bateria é NOT_CHARGING
  • current < 0 quando o status da bateria é DISCHARGING
  • Não é aplicada quando o status da bateria é FULL
• O status da bateria precisa estar correto, independentemente de uma fonte de energia estar conectada ou não. Mais especificamente:
  • O status da bateria precisa ser CHARGING, NOT_CHARGING ou FULL se e somente se uma fonte de energia estiver conectada.
  • O status da bateria precisa ser DISCHARGING se e somente se uma fonte de energia estiver desconectada.

Se você usar libbatterymonitor na implementação e transmitir valores de interfaces do kernel, verifique se os nós sysfs estão informando os valores corretos:

• Verifique se a corrente da bateria é informada com o sinal e as unidades corretos. Isso inclui os seguintes nós do sysfs:
  • /sys/class/power_supply/*/current_avg
  • /sys/class/power_supply/*/current_max
  • /sys/class/power_supply/*/current_now
  • Valores positivos indicam a corrente de entrada na bateria.
  • Os valores precisam estar em microampéres (μA).
• Verifique se a tensão da bateria é informada em microvolts (μV). Isso inclui os seguintes nós do sysfs:
  • /sys/class/power_supply/*/voltage_max
  • /sys/class/power_supply/*/voltage_now
  • A implementação padrão do HAL divide voltage_now por 1000 e informa valores em milivolts (mV). Consulte @1.0::HealthInfo.

Para saber mais, consulte Classe de fonte de alimentação do Linux.