Gerenciamento de energia

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

Para oferecer suporte ao gerenciamento de energia específico do veículo, o Android oferece um serviço CarPowerManagementService e uma interface CarPowerManager.

As transições de estado são acionadas pela unidade de controle mestre do veículo (VMCU, na sigla em inglês). Para se comunicar com a VMCU, os integradores precisam implementar vários componentes. Os integradores são responsáveis pela integração com a camada de abstração de hardware do veículo (VHAL) e a implementação do kernel. Os integradores também são responsáveis por desativar as fontes de ativação e garantir que as desativações não sejam adiadas por tempo indeterminado.

Terminologia

Estes termos são usados em todo este documento:

Design do sistema

Esta seção descreve como o AAOS representa o estado de energia do processador do app e quais módulos implementam o sistema de gerenciamento de energia. Este material também descreve como esses módulos funcionam juntos e como as transições de estado geralmente ocorrem.

Máquina de estado de energia do carro

O AAOS usa uma máquina de estados para representar o estado de energia do AP. A máquina de estado oferece os estados ilustrados abaixo:

Figura 1. Máquina de estado de energia do carro.

As transições mais comuns são destacadas em azul. Estes são os estados e as transições comuns:

• Suspensão para RAM. O veículo e o SoC estão desligados. Nenhum código está sendo executado. A energia é mantida na RAM do SoC.
• Aguarde o VHAL. Quando o motorista interage com o veículo, por exemplo, abrindo uma porta, a VMCU aplica energia ao SoC. O AAOS é retomado da suspensão para RAM e entra em espera para VHAL, onde aguarda a coordenação com a VHAL.
• Sim. O VHAL informa ao AAOS para entrar no estado "Ativado". Nesse estado, o AAOS está totalmente em execução e interagindo com o motorista.
• Preparação para encerramento. Quando o motorista termina de dirigir, o VHAL informa ao AAOS para entrar no Shutdown Prepare. Nesse estado, a tela e o áudio estão desativados, e o AAOS não interage com o motorista. O sistema Android ainda está em execução e pode atualizar apps e o sistema Android. Quando as atualizações, se houver, forem concluídas, o sistema Android entra no modo de espera para a conclusão da VHAL.
• Aguarde a conclusão do VHAL. Nesse ponto, o AAOS informa ao VHAL que ele está pronto para ser encerrado. Espera-se que a VMCU coloque o SoC em suspensão profunda e remova a energia do processador do app. O AAOS está no estado de suspensão para RAM, embora nenhum código esteja sendo executado.

Módulos de gerenciamento de energia

O sistema de gerenciamento de energia é composto por estes módulos:

O recurso de suspensão profunda/hibernação (suspensão do Android para RAM/disco) é implementado no kernel. Esse recurso é exposto ao espaço do usuário como um arquivo especial localizado em /sys/power/state. A AAOS é suspensa gravando mem ou disk neste arquivo.

O CPMS coordena o estado de energia com outros serviços e HALs. O CPMS implementa a máquina de estados descrita acima e envia notificações para cada observador quando ocorre uma transição de estado de energia. Esse serviço também usa o VHAL para enviar mensagens ao hardware.

O CPPD gerencia a política de energia até que o CPMS assuma o controle. Ele também envia notificações de mudança de política de energia para os listeners nativos.

Algumas propriedades são definidas no VHAL. Para se comunicar com a VMCU, o CPMS lê e grava essas propriedades. Os apps podem usar a interface definida no CPM para monitorar mudanças no estado de energia. Essa interface também permite que os apps registrem listeners de política de energia. Essa API pode ser chamada do Java e é anotada com @hide / @System API, o que significa que ela está disponível somente para apps privilegiados. A relação entre esses módulos, apps e serviços é ilustrada abaixo:

Figura 2. Diagrama de referência dos componentes de energia.

Sequência de mensagens

A seção anterior descreveu os módulos que compõem o sistema de gerenciamento de energia. Esta seção usa os exemplos de entrada em suspensão profunda e saída da suspensão profunda para explicar como os módulos e apps se comunicam:

Entrar no sono profundo

Somente a VMCU pode iniciar o modo de suspensão profunda. Quando o modo de suspensão profunda é iniciado, a VMCU envia uma notificação para a CPMS pelo VHAL. O CPMS muda o estado para PREPARE DE DESLIGAMENTO e transmite essa transição de estado para todos os observadores (os apps e serviços que monitoram CPMS) chamando o método onStateChanged() com um novo ID de estado fornecido pelo CPM.

O CPM faz a mediação entre os apps/serviços e os CPMS. O método onStateChanged() dos apps/serviços é invocado de forma síncrona no método onStateChanged() do CPM. A maioria dos apps e serviços precisa concluir a preparação antes de retornar desta chamada. Os serviços privilegiados podem continuar as preparação de forma assíncrona após retornarem para PRE_SHUTDOWN_PREPARE, SUSPEND_ENTER e POST_SUSPEND_ENTER. Nesse caso, o serviço privilegiado precisa chamar complete() no objeto CompletablePowerStateChangeFuture fornecido quando terminar a preparação. A preparação assíncrona não é permitida para SHUTDOWN_PREPARE. Antes que DEEP_SLEEP_ENTRY seja enviado ao VHAL, o CPMS envia periodicamente solicitações de adiamento do desligamento para o VHAL.

Quando todos os objetos do CPM tiverem concluído as preparações para a interrupção, o CPMS vai enviar AP_POWER_STATE_REPORT para o VHAL, que vai notificar o VMCU de que o AP está pronto para ser suspenso. O CPMS também chama o método de suspensão, que suspende o kernel.

A sequência descrita acima está ilustrada abaixo:

Figura 3. Entrar no modo de suspensão profunda.

Interfaces de programação fornecidas pelo CPM

Esta seção descreve a API Java fornecida pelo CPM para apps e serviços do sistema. Essa API permite que o software do sistema faça o seguinte:

• Monitore as mudanças no estado de energia do AP.
• Aplique políticas de energia.

Siga estas etapas para chamar as APIs fornecidas pelo CPM:

1. Para adquirir a instância de CPM, chame a API Car.
2. Chame o método apropriado no objeto criado na etapa 1.

Criar um objeto CarPowerManager

Para criar um objeto CPM, chame o método getCarManager() do objeto Car. Esse método é uma fachada usada para criar objetos de CPM. Especifique android.car.Car.POWER_SERVICE como um argumento para criar um objeto CPM.

Car car = Car.createCar(this);
CarPowerManager powerManager =
  (CarPowerManager) car.getCarManager(android.car.Car.POWER_SERVICE);

CarPowerStateListener e registro

Os apps e serviços do sistema podem receber notificações de mudança de estado de energia ao implementar CarPowerManager.CarPowerStateListener. Essa interface define um método onStateChanged(), que é uma função de callback invocada quando o estado de energia do CPMS é alterado. O exemplo a seguir define uma nova classe anônima que implementa a interface:

private final CarPowerManager.CarPowerStateListener powerListener =
  new CarPowerManager.CarPowerStateListener () {
    @Override
     public void onStateChanged(int state) {
       Log.i(TAG, "onStateChanged() state = " + state);
     }
};

Para instruir esse objeto listener a monitorar uma transição de estado de energia, crie uma nova linha de execução e registre o listener e essa linha de execução no objeto CPM:

executor = new ThreadPerTaskExecutor();
powerManager.setListener(powerListener, executor);

Quando o estado de energia é alterado, o método onStateChanged() do objeto listener é invocado com um valor para representar o novo estado de energia. A associação entre o valor real e o estado de energia é definida em CarPowerManager e mostrada na tabela abaixo:

Cancelamento do registro do CarPowerStateListener

Para cancelar o registro de todos os objetos de listener registrados no CPM, chame o método clearListener:

powerManager.clearListener();

Integração do sistema na implementação do Android

Os integradores são responsáveis pelos seguintes itens:

• Implementação da interface do kernel para suspender o Android.
• Implementar as funções VHAL para:
  • Propague a inicialização da suspensão ou do desligamento do carro para o Android.
  • Enviar a mensagem de desligamento pronto do Android para o carro.
  • Inicia o desligamento ou a suspensão do Android pela interface do kernel do Linux.
• Verifique se todas as fontes de ativação estão desativadas quando o dispositivo está em suspensão.
• Verifique se os apps são encerrados rapidamente o suficiente para não adiar indefinidamente o processo de desligamento.
• O BSP precisa ativar (ou desativar) componentes do dispositivo de acordo com a política de energia para não bloquear a suspensão ou a hibernação.

Interface do kernel: /sys/power/state

O AAOS coloca um dispositivo no modo de suspensão quando um app ou serviço grava mem para suspensão na RAM ou disk para suspensão no disco em um arquivo localizado em /sys/power/state. O integrador precisa fornecer uma função que monitore esse arquivo e coloque o Linux no estado de suspensão. Essa função pode enviar um GPIO para o VMCU para notificar o VMCU de que o dispositivo foi desligado completamente. O integrador também é responsável por remover qualquer condição de corrida entre o VHAL que envia a mensagem final para o VMCU e o sistema que entra no modo de suspensão ou desligamento.

Responsabilidade do VHAL

O VHAL fornece uma interface entre a rede do veículo e o Android. O VHAL:

• Propague a inicialização da suspensão ou do desligamento do carro para o Android.
• Envia a mensagem de desligamento pronto do Android para o carro.
• Inicia o desligamento ou a suspensão do Android pela interface do kernel do Linux.

Quando o CPMS informa ao VHAL que está pronto para ser encerrado, o VHAL envia a mensagem de encerramento pronto para a VMCU. Normalmente, os periféricos no chip, como UART, SPI e USB, transmitem a mensagem. Depois que a mensagem é enviada, o CPMS chama o comando do kernel para suspender ou encerrar o dispositivo. Antes disso, o VHAL ou o BSP pode alternar um GPIO para instruir o VMCU de que é seguro remover a energia do dispositivo.

O VHAL precisa oferecer suporte às seguintes propriedades, que controlam o gerenciamento de energia pelo VHAL:

AP_POWER_STATE_REPORT

Use essa propriedade para informar o estado atual de gerenciamento de energia do Android. Essa propriedade contém dois números inteiros:

• int32Values[0]: enumeração VehicleApPowerStateReport do estado atual.
• int32Values[1]: tempo em milissegundos para adiar, suspender ou encerrar. O significado desse valor depende do primeiro.

O primeiro valor pode ser um dos seguintes. VehicleApPowerStateReport.aidl contém descrições mais específicas, que são armazenadas no hardware/interfaces/automotive/vehicle/aidl/android/hardware/automotive/vehicle.

O estado pode ser definido de forma autônoma ou em resposta a uma solicitação pela VMCU.

AP_POWER_STATE_REQ

Essa propriedade é enviada pela VMCU para fazer a transição do Android para um estado de energia diferente e contém dois números inteiros:

• int32Values[0]: valor de tipo enumerado VehicleApPowerStateReq, que representa o novo estado para a transição.
• int32Values[1]: valor de tipo enumerado VehicleApPowerStateShutdownParam. Esse valor é enviado apenas para uma mensagem SHUTDOWN_PREPARE e transmite ao Android as opções que ele contém.

O primeiro valor inteiro representa o novo estado para o qual o Android vai transitar. A semântica é definida em VehicleApPowerStateReq.aidl e fornecida abaixo:

VehicleApPowerStateShutdownParam é definido em VehicleApPowerStateShutdownParam.aidl. Essa enumeração tem estes elementos:

Origens de ativação

O integrador precisa desativar as fontes de ativação adequadas quando o dispositivo estiver no modo de suspensão. As fontes de ativação comuns incluem batimentos cardíacos, modem, Wi-Fi e Bluetooth. A única fonte de ativação válida precisa ser uma interrupção do VMCU para ativar o SoC. Isso pressupõe que o VMCU possa ouvir o modem para eventos de ativação remota (como a inicialização remota do motor). Se essa funcionalidade for enviada ao AP, outra fonte de ativação para atender ao modem precisará ser adicionada.

Apps

Os OEMs precisam ter cuidado ao programar apps para que eles possam ser encerrados rapidamente e não adiar o processo indefinidamente.

Apêndice

Diretórios na árvore de código-fonte

Diagrama de classes

Este diagrama de classes mostra as classes e interfaces Java no sistema de gerenciamento de energia:

Figura 4. Diagrama de classe de energia.

Relacionamento de objetos

A Figura 5 ilustra quais objetos têm referências a outros objetos. Uma borda significa que o objeto de origem tem uma referência ao objeto de destino. Por exemplo, o VehicleHAL tem uma referência a um objeto PropertyHalService.

Figura 5. Diagrama de referência do objeto.