Gerenciamento de energia

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

As transições de estado são acionadas pela unidade de controle principal 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 despertar e garantir que os desligamentos não sejam adiados indefinidamente.

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 de apps e quais módulos implementam o sistema de gerenciamento de energia. Ele também descreve como esses módulos funcionam juntos e como as transições de estado normalmente ocorrem.

Máquina de estado de energia do carro

O AAOS usa uma máquina de estado para representar o estado de energia do AP. A máquina de estado fornece 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:

• Suspender 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, ao abrir uma porta, a VMCU aplica energia ao SoC. O AAOS é retomado do Suspend-to-RAM e entra no modo "Aguardar VHAL", em que aguarda a coordenação com a VHAL.
• Ativada. A 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 antes do desligamento. Quando o motorista termina de dirigir, a VHAL informa ao AAOS para entrar na fase de preparação antes do desligamento enviando SHUTDOWN_PREPARE. Nesse estado, os listeners de mudança de estado de energia recebem STATE_PRE_SHUTDOWN_PREPARE. Isso serve como um aviso antecipado de que o desligamento está começando.
• Preparação para encerramento. Quando todos os listeners são concluídos ou o tempo limite de preparação pré-desligamento é atingido, o sistema Android entra na fase principal de preparação para desligamento, notificando os listeners com STATE_SHUTDOWN_PREPARE. A tela e o áudio estão desligados, e o AAOS não está interagindo com o motorista. O sistema Android ainda está em execução e pode realizar operações de limpeza e atualização, como executar o modo Garagem.
• Aguarde a conclusão do VHAL. Nesse momento, o AAOS informa à VHAL que está pronto para ser desligado. Espera-se que a VMCU coloque o SoC em modo de espera e remova a energia do processador de aplicativos. O AAOS fica 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 pelos seguintes módulos:

O recurso de sono profundo/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. O AAOS é suspenso gravando mem ou disk nesse 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 a todos os observadores quando ocorre uma transição de estado de energia. Esse serviço também usa a VHAL para enviar mensagens ao hardware.

O CPPD é a fonte da verdade para políticas de energia. Ele gerencia as políticas de energia durante todo o ciclo de vida do dispositivo e notifica o CPMS, a VHAL e outros listeners nativos sobre as mudanças na política de energia. O CPMS delega solicitações de mudança na política de energia ao CPPD.

O CPMS se comunica com a VMCU lendo e gravando propriedades da VHAL relacionadas ao estado de energia, como AP_POWER_STATE_REQ e AP_POWER_STATE_REPORT. 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 Java é anotada com @SystemApi e @hide, o que a torna disponível apenas 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 entrar em sono profundo e sair do sono profundo para explicar como os módulos e apps se comunicam:

Entrar em sono profundo

Somente a VMCU pode iniciar o sono profundo. Depois que o sono profundo é iniciado, a VMCU envia uma notificação ao CPMS pela VHAL. O CPMS muda o estado para SHUTDOWN PREPARE e transmite essa transição de estado para todos os observadores (os apps e serviços que monitoram o 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() para 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 dessa chamada. Os serviços privilegiados podem continuar os preparativos de forma assíncrona depois de retornar para PRE_SHUTDOWN_PREPARE, SUSPEND_ENTER e POST_SUSPEND_ENTER. Nesse caso, o serviço privilegiado deve 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 à VHAL, o CPMS envia periodicamente solicitações de adiamento de desligamento à VHAL.

Quando todos os objetos do CPM concluem os preparativos para desligamento, o CPMS envia AP_POWER_STATE_REPORT para a VHAL, que notifica a VMCU de que o AP está pronto para suspender. A 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 em 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:

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

Siga estas etapas para chamar as APIs fornecidas pelo CPM:

1. Para adquirir a instância do CPM, chame a API Car.
2. Chame o método adequado 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 de 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 implementando CarPowerManager.CarPowerStateListener. Essa interface define um método onStateChanged(), que é uma função de callback invocada quando o estado de energia do CPMS muda. 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 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 a seguir:

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 de sistema na sua implementação do Android

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

• Implementação da interface do kernel para suspender o Android.
• Implemente as funções da VHAL para:
  • Propagar o início da suspensão ou do desligamento do carro para o Android.
  • Envie a mensagem de desligamento do Android para o carro.
  • Inicie o desligamento ou a suspensão do Android pela interface do kernel do Linux.
• Verifique se todas as origens de ativação estão desativadas quando o dispositivo está em suspensão.
• Verifique se os apps são desligados com rapidez suficiente para não adiar indefinidamente o processo de encerramento.
• Verifique se o BSP ativa (ou desativa) os componentes do dispositivo de acordo com a política de energia para não bloquear a suspensão ou 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 para RAM ou disk para suspensão para 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 energia de suspensão. Essa função pode enviar um GPIO para a VMCU para notificar que o dispositivo foi desligado completamente. O integrador também é responsável por remover quaisquer condições de disputa entre a VHAL enviando a mensagem final para a VMCU e o sistema entrando em modo de suspensão ou desligamento.

Responsabilidade da VHAL

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

• Propaga o início da suspensão ou do desligamento do carro para o Android.
• Envia a mensagem de desligamento do Android para o carro.
• Inicia o desligamento ou a suspensão do Android pela interface do kernel do Linux.

Quando o CPMS informa à VHAL que está pronto para desligar, a VHAL envia a mensagem de desligamento pronto para a VMCU. Normalmente, 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 desligar o dispositivo. Antes disso, a VHAL ou o BSP podem alternar um GPIO para instruir a VMCU de que é seguro remover a energia do dispositivo.

A VHAL precisa oferecer suporte às seguintes propriedades, que controlam o gerenciamento de energia pela 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 desligar. 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 enumeração VehicleApPowerStateReq, que representa o novo estado para o qual fazer a transição.
• int32Values[1]: valor de enumeração VehicleApPowerStateShutdownParam. Esse valor é enviado apenas para uma mensagem SHUTDOWN_PREPARE e transmite ao Android as opções que ela 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 está no modo de suspensão. As fontes de despertar comuns incluem pulsações, modem, Wi-Fi e Bluetooth. A única origem de ativação válida precisa ser uma interrupção da VMCU para ativar o SoC. Isso pressupõe que a VMCU pode ouvir o modem para eventos de ativação remota, como partida remota do motor. Se essa funcionalidade for enviada para o AP, será necessário adicionar outra fonte de ativação para atender ao modem.

Apps

Os OEMs precisam ter cuidado ao escrever apps para que eles possam ser desligados rapidamente e não adiem 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 objeto

A Figura 5 ilustra quais objetos têm referências a outros objetos. Uma aresta 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 de objeto.