Hibernação do aplicativo

Um usuário médio do Android instala mais de 50 aplicativos em seus dispositivos (o número aumenta à medida que a camada de RAM dos dispositivos aumenta). No entanto, um número significativo desses aplicativos não é utilizado pelo usuário por um longo período de tempo.

A hibernação de aplicativos hiberna aplicativos que o usuário não usa há alguns meses, semelhante à revogação automática de permissão. Isso força a parada do aplicativo e o coloca em um estado em que otimizamos o armazenamento em vez do desempenho. A revogação automática de permissão também está incluída neste estado e eles compartilham a mesma configuração de isenção em Settings . Um aplicativo de parada forçada não executa trabalhos ou alertas em segundo plano e não é capaz de enviar notificações push. Quando o usuário usa o aplicativo novamente, o aplicativo sai da hibernação e os trabalhos/alertas/notificações são executados novamente normalmente. Quaisquer trabalhos/alertas/notificações que foram agendados antes de o aplicativo entrar em hibernação precisam ser reprogramados.

Os OEMs que modificam a plataforma podem entrar em conflito com a implementação da hibernação do aplicativo. Por exemplo

  • Modificar a definição de uso do aplicativo ou introduzir formas de ativar um aplicativo que não esteja no AOSP pode interromper a precisão da hibernação do aplicativo
  • O mecanismo de restrição proprietário de um OEM, semelhante à hibernação de aplicativos, pode ter uma finalidade semelhante. Embora ambos possam existir, pode haver alguma sobreposição.

O CDD descreve um novo conjunto de requisitos para alterações baseadas no uso do aplicativo, semelhante ao requisito 3.5.1 existente. A hibernação do aplicativo segue estes requisitos.

O código da estrutura reside em:

A lógica da política reside em:

  • repositório: plataforma/pacotes/módulos/permissão
  • diretório: PermissionController/src/com/android/permissioncontroller/hibernation

Arquitetura de alto nível

O serviço do sistema de hibernação de aplicativos otimiza o armazenamento dos aplicativos usados ​​com pouca frequência pelo usuário e evita que esses aplicativos sejam executados em segundo plano. Para alcançar esses resultados, quando hibernamos um aplicativo, especificamente:

  • Revogar permissões automaticamente
  • Forçar a parada do aplicativo
  • Exclua os arquivos ODEX e VDEX
  • Exclua o cache do aplicativo

Nosso objetivo é implementar a hibernação como uma ação reversível para que o aplicativo ainda esteja disponível para o usuário por meio do Launcher e de outras superfícies com os dados do aplicativo intactos. Ao iniciar o aplicativo, iremos restaurá-lo do estado de parada forçada e continuaremos com a criação dos arquivos ODEX e VDEX normalmente.

O design planejado gira em torno de duas partes principais:

  • Determinando quando um pacote deve hibernar
  • Otimizando o pacote de hibernação

Um novo serviço de sistema, AppHibernationService , e um serviço de trabalho, AppHibernationJobService, em PermissionController são a cola que controla a lógica e a tomada de decisão geral.

A determinação de quando um pacote deve hibernar é baseada principalmente em UsageStatsService e gerenciada por AppHibernationJobService em PermissionController . Essa lógica de política reside no PermissionController para nos permitir atualizar dinamicamente por meio do Mainline. Além disso, planejamos adicionar um novo sinal, uso de componentes, para capturar o uso dos componentes do pacote (por exemplo, serviços, provedores de conteúdo) como uma nova métrica em UsageStatsService .

A otimização de um pacote é onde acontecem todas as economias e otimizações reais. AppHibernationService se comunica com várias partes do sistema para interromper o pacote, excluir dados de cache, excluir artefatos ART e assim por diante. A revogação de permissão é iniciada diretamente no AppHibernationJobService para manter a funcionalidade de revogação automática no Android 11 e em dispositivos anteriores.

Experiência de usuário

O usuário recebe informações e controles sobre quais aplicativos podem ser hibernados.

Semelhante à revogação automática, o usuário recebe uma notificação sobre quais aplicativos estão hibernados e tem a opção de acessar as Configurações diretamente da notificação para abrir o aplicativo e tirá-lo da hibernação ou excluir o aplicativo não utilizado, se necessário.

Continuamos apoiando a intenção do desenvolvedor de solicitar ao usuário uma isenção da hibernação com a intenção de isenção de revogação automática de permissões existentes.

Compatibilidade com versões anteriores

Recursos específicos de hibernação estão disponíveis a partir do Android 12. Esse recurso não funcionava em versões anteriores, pois os componentes da plataforma (como o novo serviço do sistema) não estão presentes. A revogação automática continua a funcionar conforme implementada nas versões anteriores do sistema operacional.

A partir do Android 12, para garantir a compatibilidade com versões anteriores, um botão de hibernação é adicionado à página do aplicativo em Aplicativos e notificações em Configurações, enquanto mantém o botão de revogação automática original no submenu Permissões . Essa alternância controla a isenção geral do sistema de hibernação do aplicativo.

Costumização

Parte da implementação faz parte do componente modular do sistema, portanto os parceiros são desencorajados a modificar o recurso. Em vez disso, os parceiros podem implementar recursos ou funcionalidades semelhantes, desde que sigam os requisitos do CDD.

A hibernação de aplicativos deve ser ativada por padrão para todos os aplicativos direcionados ao Android 11 ou superior. Isso é o mesmo que revogação automática de permissões. Embora a configuração em si possa estar ATIVADA, a implementação da hibernação do aplicativo pode diferir entre aplicativos direcionados ao Android 11 e Android 12. Mais especificamente, a hibernação do aplicativo só funciona para aplicativos direcionados ao Android 11, enquanto é essencialmente apenas revogada automaticamente para aplicativos direcionados ao Android 12.

Além disso, os OEMs podem estar implementando um recurso semelhante. No entanto, esses recursos são direcionados a uma escala de tempo muito mais curta para otimizações de bateria que podem ser específicas do OEM. Quaisquer recursos de restrição de aplicativos semelhantes desenvolvidos por OEMs podem coexistir com o sistema de hibernação de aplicativos, desde que atendam aos critérios existentes definidos no CDD .

Teste

A hibernação do aplicativo possui CTS e testes de unidade para garantir que está funcionando corretamente.