Os apps destinados ao Android 12 não podem mais iniciar serviços
em primeiro plano enquanto
são executados em segundo plano, exceto em alguns casos
específicos. Se um app tentar iniciar um
serviço em primeiro plano enquanto estiver em segundo plano e o
serviço em primeiro plano não se enquadrar em um dos casos excepcionais, o sistema
gerará uma ForegroundServiceStartNotAllowedException
.
Alternativa recomendada para serviços em primeiro plano: WorkManager
Se o app for afetado por essa mudança, migre para o WorkManager. O WorkManager é a solução recomendada para iniciar tarefas de maior prioridade em segundo plano.
Com o WorkManager 2.7.0, o app pode chamar o método
setExpedited()
para declarar que um
Worker
precisa usar um job
acelerado. Essa nova API usa jobs acelerados quando em execução no
Android 12 e a API usa serviços em primeiro plano em versões anteriores
do Android para oferecer compatibilidade com elas.
O snippet de código a seguir mostra um exemplo de como usar o método
setExpedited()
:
Kotlin
OneTimeWorkRequestBuilder<T>().apply { setInputData(inputData) setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST) }.build()
Java
OneTimeWorkRequest request = new OneTimeWorkRequestBuilder<T>() .setInputData(inputData) .setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST) .build();
Como os métodos
CoroutineWorker.setForeground()
e ListenableWorker.setForegroundAsync()
usam serviços em primeiro plano, eles estão sujeitos às mesmas
restrições de inicialização de serviços em primeiro plano e
exceções. Você pode usar a API
de maneira oportuna, mas esteja preparado para lidar com uma exceção se o sistema
não permitir que o app inicie um serviço em primeiro plano. Para uma experiência mais consistente,
use setExpedited()
.
Para ver um exemplo completo de como o WorkManager 2.7.0 acelera jobs, confira WorkManagerSample (em inglês) no GitHub.
Jobs acelerados
Os jobs acelerados, novidade do Android 12, permitem que os apps executem
tarefas curtas e que o sistema tenha mais controle sobre o acesso a recursos.
Esses jobs possuem um conjunto de características que se enquadram entre um serviço
em primeiro plano e um job comum do
JobScheduler
:
- Eles são destinados a tarefas curtas que são concluídas em apenas alguns minutos. A menos que o app tenha cota suficiente, o sistema poderá interromper um job acelerado se ele já estiver em execução por pelo menos três minutos.
- Esses jobs são menos afetados por algumas das restrições de gerenciamento de energia do sistema, incluindo a Economia de bateria e o modo Soneca.
- O sistema executa esses jobs imediatamente, desde que a carga de trabalho atual permita fazer isso.
Jobs acelerados podem ser adiados
O sistema tenta executar o job acelerado o quanto antes após ele ser invocado. No entanto, como acontece com outros tipos de jobs, o sistema poderá adiar a inicialização de novos jobs acelerados, como nos casos a seguir:
- A carga do sistema é muito alta. Isso pode ocorrer quando muitos jobs já estiverem em execução ou quando o sistema não tiver memória suficiente.
- A cota limite de jobs acelerados foi excedida. Os jobs acelerados usam um sistema de cotas baseado nos Intervalos do App em espera e limitam o tempo máximo de execução dentro de uma janela de tempo. As cotas usadas para jobs acelerados são mais restritivas do que as usadas para outros tipos de jobs em segundo plano.
Efeitos nas APIs Alarm Manager
Em geral, apps direcionados ao Android 12 não podem iniciar serviços em primeiro plano usando um alarme.
Para oferecer compatibilidade com os casos de uso em que os apps precisam enviar alarmes ou
lembretes urgentes para os usuários, é possível iniciar serviços em primeiro plano quando os alarmes
exatos são acionados. Para defini-los, o app precisa declarar
a permissão
SCHEDULE_EXACT_ALARM
.
Saiba mais sobre a permissão de alarme exato.
Casos em que a inicialização de serviços em primeiro plano pelo segundo plano é permitida
O app poderá iniciar serviços em primeiro plano enquanto estiver em segundo plano nas seguintes situações:
- O app estava em um estado visível para o usuário, como uma atividade.
- O app pode iniciar uma atividade do segundo plano, exceto quando o app tem uma atividade na backstack para uma tarefa existente.
- O app recebe uma mensagem de alta prioridade usando o Firebase Cloud Messaging.
- O usuário realiza uma ação em um elemento da IU relacionado ao app. Por exemplo, o usuário pode interagir com um balão, uma notificação, um widget ou uma atividade.
- O app recebe um evento relacionado à fronteira geográfica virtual ou à transição de reconhecimento de atividade.
- Após o dispositivo ser reiniciado e receber a ação da intent
ACTION_BOOT_COMPLETED
,ACTION_LOCKED_BOOT_COMPLETED
ouACTION_MY_PACKAGE_REPLACED
em um broadcast receiver. - O app recebe a ação da intent
ACTION_TIMEZONE_CHANGED
,ACTION_TIME_CHANGED
ouACTION_LOCALE_CHANGED
em um broadcast receiver. - O app recebe uma transmissão Bluetooth que exige as permissões
BLUETOOTH_CONNECT
ouBLUETOOTH_SCAN
. - Apps com determinados papéis ou permissões do sistema, como proprietários de dispositivo e proprietários de perfil.
O app usa o gerenciador de dispositivo complementar.
Para permitir que o sistema acione o app sempre que houver um dispositivo complementar por perto, implemente o serviço de dispositivos complementares no Android 12.
O sistema reinicia um serviço "fixo" em primeiro plano. Para fazer com que um serviço em primeiro plano seja fixo, retorne
START_STICKY
ouSTART_REDELIVER_INTENT
do métodoonStartCommand()
.O usuário desativa as otimizações de bateria do app. Você pode ajudar os usuários a encontrar essa opção levando-os para a página Informações do app nas configurações do sistema. Para fazer isso, invoque uma intent que contenha a ação da intent
ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS
.