Escolher a API certa para manter o dispositivo ativado
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Quando o usuário deixa o dispositivo Android ocioso, ele entra rapidamente no
estado de suspensão para evitar o descarregamento da bateria. No entanto, há momentos em que um
app precisa impedir que a CPU entre no estado de suspensão. Em alguns casos, o
app pode precisar manter a tela ligada enquanto está funcionando. Em outros casos, o app
não precisa manter a tela ligada, mas ainda precisa que a CPU esteja ativa.
O método escolhido depende das necessidades do app. No entanto, uma regra geral é usar a abordagem mais leve possível para minimizar o impacto nos recursos do sistema. Este documento ajuda você a escolher a tecnologia Android correta para sua situação.
Escolher a tecnologia certa
A melhor opção para manter o dispositivo ativo depende das necessidades do seu app. Esta seção ajuda você a escolher a abordagem certa.
O app precisa manter a tela ligada?
Se a resposta for Sim, consulte Manter a tela ativada. Pode haver uma API de propósito especial que faça o que você precisa. Por exemplo, se você estiver implementando uma interface de chamada telefônica, use o framework de telecomunicações do Android, que mantém a tela ligada quando necessário. Se não houver uma API de propósito especial para sua situação, use a API keepScreenOn.
Seu app está executando um serviço em primeiro plano, e você precisa manter o dispositivo
ativo com a tela desligada enquanto o serviço está em execução?
Se a resposta for Não, não é necessário manter o dispositivo ativo. Se o usuário estiver
interagindo ativamente com o app, o dispositivo vai permanecer ativo. Se o
usuário não estiver interagindo com o app e você não estiver executando um
serviço em primeiro plano, deixe o dispositivo entrar no modo de suspensão quando
necessário. Se você só precisa garantir que algum trabalho seja feito enquanto o
usuário está longe do app, consulte a documentação sobre tarefas em segundo plano
para encontrar a melhor opção.
Se a resposta for Sim, primeiro confirme se você realmente precisa usar um serviço em
primeiro plano. Dependendo da sua situação, talvez haja uma API de finalidade especial
que você possa usar para atender à sua necessidade em vez de um serviço em primeiro plano.
Você pode encontrar informações sobre eles na documentação do serviço em primeiro plano. Por exemplo, se você precisar rastrear a localização do usuário, poderá usar a API Geofencing em vez de um serviço em primeiro plano location.
Isso prejudicaria a experiência do usuário se o dispositivo fosse suspenso enquanto
o serviço em primeiro plano estivesse em execução e a tela do dispositivo estivesse desligada? Por exemplo, se você estiver usando um serviço em primeiro plano para atualizar notificações, não será uma má experiência do usuário se o dispositivo for suspenso.
Se a resposta for Não, não use um wake lock. A ação é retomada
automaticamente quando o usuário interage com o dispositivo, o que o tira
do estado de suspensão.
Se a resposta for Sim, talvez seja necessário usar um wake lock. No entanto, verifique se você já está usando uma API ou fazendo uma ação que declara um wake lock em seu nome, conforme discutido em Ações que mantêm o dispositivo ativo.
Ações que mantêm o dispositivo ativado
Se o app estiver fazendo alguma das ações a seguir, não será necessário definir um wake lock
manualmente. As ações e APIs a seguir mantêm o dispositivo ativo para você.
Se você estiver reproduzindo áudio, o sistema de áudio vai definir e gerenciar um bloqueio de despertar para
você. Não é necessário fazer isso por conta própria.
Se você estiver usando APIs ou bibliotecas de programação de tarefas, como WorkManager, JobScheduler ou DownloadManager, o sistema ou a biblioteca vai adquirir
um wake lock atribuído ao seu app.
Alguns sensores de dispositivos são sensores de ativação. Use SensorManager
para que esses sensores ativem o dispositivo quando tiverem dados para informar. Para
verificar se um sensor é de despertar, chame Sensor.isWakeUpSensor.
Se você programar um alarme, o dispositivo vai despertar quando ele tocar, mesmo que o app não esteja em execução.
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
Última atualização 2025-09-08 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-08 UTC."],[],[],null,["When the user leaves their Android-powered device idle, it quickly goes into the\nsuspend state to avoid draining the battery. However, there are times when an\napp needs to prevent the CPU from going to the suspend state. In some cases, the\napp may need to keep the screen on while it's working. In other cases, the app\ndoesn't need to keep the screen on but still needs the CPU to be active.\n\nThe approach you take depends on the needs of your app. However, a general rule\nis that you should use the most lightweight approach possible, to minimize your\napp's impact on system resources. This document helps you choose the correct\nAndroid technology for your situation.\n| **Note:** You may be familiar with **wake locks**. An app can set a wake lock to keep the device from suspending. However, using a wake lock can quickly drain the device battery. You should only use a wake lock if there's no other option that will do what you need. If you do use a wake lock, you should release it as soon as possible.\n\nChoose the right technology\n\nThe best option for keeping your device awake depends on your app's needs. This\nsection helps you choose the right approach.\n\n- Does your app need to keep the screen on?\n - If **Yes** , see [Keep the screen on](/develop/background-work/background-tasks/awake/screen-on). There may be a special-purpose API that does what you need; for example, if you're implementing a phone-call UI, you can use the [Android telecom\n framework](/reference/android/telecom/package-summary), which keeps the screen on when needed. If there's no special purpose API for your situation, you can use the `keepScreenOn` API.\n- Is your app running a foreground service, and you need to keep the device awake when screen is off while the service is running?\n - If **No** , you do not need to keep the device awake. If the user is actively interacting with the app, the device will stay awake. If the user is not interacting with your app and you are not running a foreground service, you should let the device go into suspend mode when necessary. If you just need to make sure some work gets done while the user is away from the app, see the [background tasks](/develop/background-work/background-tasks) documentation to find the best option.\n - If **Yes** , first confirm that you actually need to use a foreground service. Depending on your situation, there may be some special-purpose API you can use to accomplish your need instead of a foreground service. You can find information about these [in the Foreground Service\n documentation](/develop/background-work/services/fgs/service-types). For example, if you need to track the user's location, you might be able to use the [geofencing API](/develop/sensors-and-location/location/geofencing) instead of a `location` foreground service.\n- Would it be detrimental to the user experience if the device suspends while the foreground service is running and the device screen is off? (For example, if you're using a foreground service to update notifications, it wouldn't be a bad user experience if the device is suspended.)\n - If **No**, do not use a wake lock. The action resumes automatically once the user engages with their device, which takes it out of suspend.\n - If **Yes** , you might need to [use a wake lock](/develop/background-work/background-tasks/awake/wakelock). However, you should still check to see if you're already using an API or doing an action that declares a wake lock on your behalf, as discussed in [Actions that keep the device awake](#actions-keep).\n\nActions that keep the device awake\n\nIf your app is doing any of the following, you don't need to set a wake lock\nyourself. The following actions and APIs all keep the device awake for you.\n\n- If you're playing audio, the audio system sets and manages a wake lock for you; you don't need to do it yourself.\n- If you're using task scheduling APIs or libraries such as [WorkManager](/develop/background-work/background-tasks/persistent), [`JobScheduler`](/reference/android/app/job/JobScheduler), or [`DownloadManager`](/reference/android/app/DownloadManager), the system or library acquires a wake lock that is attributed to your app.\n- If you're using [Media3 ExoPlayer](/media/media3/exoplayer), you can use [`ExoPlayer.setWakeMode()`](/reference/androidx/media3/exoplayer/ExoPlayer#setWakeMode(int)) to have the player set a wake lock for you.\n- Certain device sensors are wake-up sensors; you can use [`SensorManager`](/reference/android/hardware/SensorManager) to have those sensors wake up the device when they have data to report. To check if a sensor is a wake-up sensor, call [`Sensor.isWakeUpSensor`](/reference/android/hardware/Sensor#isWakeUpSensor())).\n- If you [schedule an alarm](/develop/background-work/services/alarms), the device wakes up when the alarm goes off, even if your app is not running.\n\nSee also\n\n- [Use wake locks](/develop/background-work/background-tasks/awake/wakelock)\n- [Keep the screen on](/develop/background-work/background-tasks/awake/screen-on)"]]