HAL de estatísticas de energia

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

A energia do subsistema do dispositivo geralmente é medida e registrada em um ambiente de laboratório para várias condições de estado estável, como quando a tela está ligada ou o dispositivo está em um estado de energia ocioso. Isso funciona para subsistemas com um consumo de energia constante ou em condições que são facilmente medidas em ambientes de laboratório, mas não para determinados casos de uso, como quando uma tela exibe um vídeo.

IPower.hal 1.0 fornece uma interface para transmitir dicas de economia de energia e informar dados cumulativos sobre métricas de estado de suspensão do subsistema. No Android 10 e versões mais recentes, a função de geração de relatórios de estatísticas cumulativas está nas APIs de coleta de estatísticas de energia IPowerStats.hal e oferece uma maneira de extrair dados de uso de energia no dispositivo. Isso substitui a parte de coleta de estatísticas cumulativas da interface IPower.hal, para uma separação mais clara da funcionalidade.

As leituras do serviço IPowerStats não são periódicas. Elas ocorrem em momentos importantes, como quando há uma queda de 1% na bateria. As leituras são menos frequentes quando o consumo de bateria é baixo e mais frequentes quando é alto. Os dados podem ser enviados de volta aos servidores e usados em relatórios de bugs para análise e triagem. Isso apoia os esforços contínuos para reduzir o consumo de energia e aumentar a duração da bateria.

IPower.hal e IPowerStats.hal

As interfaces IPower.hal e IPowerStats.hal estão disponíveis no Android 10, mas a funcionalidade de coleta de estatísticas de IPower.hal só está disponível na interface IPowerStats.hal. A funcionalidade IPowerStats.hal inclui APIs para adquirir e usar dados coletados de medições de energia no dispositivo para dispositivos com suporte:

• Realiza medições de energia no nível do trilho para clientes de baixa (getRailInfo) e de alta frequência (streamEnergyData) e informa a energia acumulada desde a inicialização.
• Informa dados relacionados a cada PowerEntity compatível com os dados disponíveis. Um PowerEntity é um subsistema de plataforma, periférico ou domínio de energia que afeta o consumo total de energia do dispositivo.
• Informa o conjunto de estados de entidade de energia (getPowerEntityStateInfo) para os quais as entidades especificadas fornecem dados de residência e, em seguida, informa os dados acumulados para cada PowerEntity especificado.

As APIs IPowerStats.hal são usadas pelos seguintes clientes:

• Statsd, para coletar métricas de consumo de energia por trilho.
• Perfetto, para correlacionar o consumo de energia com a atividade da CPU.
• Batterystats, para melhorar a atribuição de bateria usando dados medidos em vez de estimar o consumo de bateria de constantes predefinidas em power_profile.xml.

No Android 10 e versões mais recentes, um fabricante de dispositivos pode escolher entre as funções IPower.hal e IPowerStats.hal, mas todos os clientes precisam usar IPower.hal se IPowerStats.hal não estiver implementado .

Opções de implementação de IPowerStats.hal

Apenas as funções IPower.hal estão disponíveis no Android 7 até o Android 9. Os dispositivos que foram atualizados para o Android 10 precisam ter um subsistema de monitoramento de energia de hardware ou outras formas disponíveis para monitorar e registrar estatísticas de energia. Alguns SoCs coletam estatísticas de uso de energia para você, ou você pode receber informações de residência de estado de entidade de energia por meio de software. O hardware de monitoramento de energia só é necessário para oferecer suporte a getRailInfo(), getEnergyData() e streamEnergyData().

Se você implementar IPowerStats.hal sem hardware de monitoramento de energia, getRailInfo(), getEnergyData() e streamEnergyData() vão retornar NOT_SUPPORTED. Da mesma forma, getPowerEntityInfo(), getPowerEntityStateInfo() e getPowerEntityStateResidencyData() também podem retornar NOT_SUPPORTED se não forem usados.

Confira alguns exemplos de dados retornados pelas APIs de monitoramento ferroviário:

• O trilho de energia da tela consumiu X µW.
• O trilho de energia do modem consumiu Y µW.

Exemplos de dados retornados pelas APIs de estado de suspensão do subsistema incluem:

• O modem ficou inativo por X ms.
• O SoC estava no estado de colapso de energia por Y ms.
• A GPU estava no estado de suspensão por Z ms.

Usar um subsistema de monitoramento de energia do hardware

Se o design do dispositivo tiver um subsistema de monitoramento de energia de hardware, implemente IPowerStats.hal criando um único nó sysfs do qual o PowerStats.hal possa analisar dados ou fazendo uma coleção de chamadas de sistema do tipo ioctl.

É necessário implementar o driver do kernel de maneira a evitar o overflow do acumulador. O algoritmo usado depende do design exclusivo do subsistema de monitoramento de energia do hardware, que precisa fornecer tensão de barramento instantânea e média e medições de corrente. O driver do kernel precisa capturar esses dados de uma maneira que não limpe os acumuladores de energia e manter os dados de energia acumulados para cada subtrilha desde a inicialização, na forma de uma variável de 64 bits que é incrementada com a leitura de energia de cada consulta de acumulador.

As estatísticas de um determinado componente (ou, opcionalmente, de vários componentes) precisam estar em um único nó. Embora esse não seja um uso convencional do sysfs, que normalmente limita cada nó a um único valor, ele garante que todos os dados sejam consistentes.

Orientações de design

• Mantenha a latência baixa (1 ms, no máximo) ao ler do nó sysfs ou fazer chamadas de sistema.
• Verifique se a funcionalidade de suporte a estatísticas não aumenta significativamente o consumo de energia:
• Não aumente o ponto de acesso (AP) e/ou o despertar do subsistema para rastrear parâmetros, como o tempo gasto no modo de espera.
• Transfere estatísticas entre o processador de apps e o firmware de forma oportunista com outro tráfego, quando possível.
• Se necessário, o subsistema pode usar as seguintes funções do driver:
• Armazenamento em cache interno de dados para evitar latência/despertar em detrimento de dados um pouco desatualizados.
• A extrapolação é realizada quando o subsistema está inativo, para fornecer o tempo de inatividade atualizado sem despertar o subsistema.

Escolher componentes, subsistemas e estatísticas

Ao escolher quais componentes ou subsistemas coletar dados de IPowerStats.hal, selecione qualquer coisa no dispositivo que consuma corrente significativa (5 mA ou mais) ou que ofereça suporte a vários modos de consumo de energia, como estes:

• Subsistemas SoC individuais.
• Subsistemas parcialmente ou completamente fora do SoC, como Wi-Fi, processador de imagens ou processador de segurança.
• Periféricos, como LEDs e câmeras de alta potência.
• Domínios de energia que usam modos diferentes, como o domínio de energia do SoC como um todo.

Personalização

Esse recurso opcional pode ser personalizado. Crie casos de uso e personalize seu uso:

• Decida quais trilhos medir e com que frequência.
• Decida quando ler os dados e como interpretá-los.
• Decida o que fazer e quando fazer com base nos seus dados.

Validação

Os testes do VTS garantem que os requisitos do Android sejam atendidos. Os comentários em IPowerStats.hal são usados para verificar se um dispositivo está em conformidade.

Por exemplo, se você chamar getRailInfo() e ele não retornar nada, o teste do VTS falhará porque você não recebeu informações sobre os trilhos monitorados ou um status retornado de SUCCESS. Da mesma forma, se você recebeu informações de trilho, mas elas foram acompanhadas de uma resposta NON_SUPPORTED ou FILE_SYSTEM_ERROR, isso também é uma falha. A VTS verifica se a especificação do fabricante do dispositivo é respeitada no arquivo HAL, usando os requisitos nos comentários IPower.hal e IPowerStats.hal. Confira abaixo um exemplo de comentários usados nos testes de VTS:

/**
* Rail information:
* Reports information related to the rails being monitored.
*
* @return rails Information about monitored rails.
* @return status SUCCESS on success or NOT_SUPPORTED if
* feature is not enabled or FILESYSTEM_ERROR on filesystem nodes
* access error.
*/
getRailInfo()
generates(vec<e;RailInfo>e; rails, Status status);