Seguir as práticas recomendadas de bloqueio de ativação
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
O uso de um wake lock pode prejudicar o desempenho do dispositivo. Se você precisar usar um bloqueio de
ativação, é importante fazer isso corretamente. Este documento aborda algumas práticas recomendadas
que podem ajudar você a evitar armadilhas comuns de bloqueio de despertar.
Nomeie o wake lock corretamente
Recomendamos que você inclua o nome do pacote, da classe ou do método na tag
wakelock. Assim, se ocorrer um erro, será mais fácil encontrar o local no
código-fonte em que o bloqueio de despertar foi criado. Veja mais algumas dicas:
Não inclua informações de identificação pessoal (PII, na sigla em inglês) no nome,
como um endereço de e-mail. Se o dispositivo detectar informações de identificação pessoal na tag
do wake lock, ele vai registrar _UNKNOWN em vez da tag especificada.
Não busque o nome da classe ou do método de forma programática, por exemplo, chamando getName(). Se você tentar extrair o nome de forma programática, ele
poderá ser ofuscado por ferramentas como o Proguard. Em vez disso, use uma string
codificada.
Não adicione um contador ou identificadores exclusivos às tags de wake lock. O código
que cria um bloqueio de despertar precisa usar a mesma tag sempre que for executado.
Essa prática permite que o sistema agregue o uso de bloqueio de despertar de cada método.
Verifique se o app está visível em primeiro plano
Enquanto um bloqueio de despertar está ativo, o dispositivo está usando energia. O usuário do dispositivo
precisa saber que isso está acontecendo. Por isso, se você estiver usando um
wake lock, mostre alguma notificação ao usuário.
Na prática, isso significa que você precisa receber e manter o wakelock em um
serviço em primeiro plano. Os serviços em primeiro plano precisam mostrar
uma notificação.
Se um serviço em primeiro plano não for a escolha certa para seu app,
provavelmente você também não deve usar um bloqueio de despertar. Consulte a documentação Escolher a API certa para manter o dispositivo ativo e saiba outras maneiras de trabalhar enquanto o app não está em primeiro plano.
Mantenha a lógica simples
Confira se a lógica para adquirir e liberar wake locks é o mais simples
possível. Quando sua lógica de wake lock está vinculada a máquinas de estado, tempos limite, pool de executores ou eventos de callback complexos, qualquer bug sutil nessa lógica pode fazer com que o wake lock seja mantido por mais tempo do que o esperado. Esses bugs são difíceis de diagnosticar
e depurar.
Verifique se o wake lock é sempre liberado
Se você usa um wake lock, verifique se todos os wake locks adquiridos
são liberados corretamente. Nem sempre é tão fácil quanto parece. Por exemplo, o código a seguir tem um problema:
Kotlin
@Throws(MyException::class)fundoSomethingAndRelease(){wakeLock.apply{acquire()doTheWork()// can potentially throw MyExceptionrelease()// does not run if an exception is thrown}}
Java
voiddoSomethingAndRelease()throwsMyException{wakeLock.acquire();doTheWork();// can potentially throw MyExceptionwakeLock.release();// does not run if an exception is thrown}
O problema aqui é que o método doTheWork() pode gerar a exceção MyException. Se isso acontecer, o método doSomethingAndRelease() vai propagar
a exceção para fora, e ela nunca vai chegar à chamada release(). O resultado
é que o bloqueio de despertar é adquirido, mas não liberado, o que é muito ruim.
No código corrigido, doSomethingAndRelease() garante a liberação do
bloqueio de despertar mesmo que uma exceção seja gerada:
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-08-27 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-08-27 UTC."],[],[],null,["Using a wake lock can impair device performance. If you need to use a wake\nlock, it's important to do it properly. This document covers some best practices\nthat can help you avoid common wake lock pitfalls.\n| **Note:** Creating and holding wake locks can have a dramatic impact on the device's battery life. You shouldn't use wake locks if there are any suitable alternatives. For other options, see the [Keep the device awake](/develop/background-work/background-tasks/awake) documentation. If you do need to use a wake lock, make sure to hold it for as short a time as possible.\n\nName the wake lock properly\n\nWe recommend including your package, class, or method name in the wakelock\ntag. That way, if an error occurs, it's easier to find the location in your\nsource code where the wake lock was created. Here are some additional tips:\n\n- Leave out any personally identifying information (PII) in the name, such as an email address. If the device detects PII in the wake lock tag, it logs `_UNKNOWN` instead of the tag you specified.\n- Don't get the class or method name programmatically, for example by calling `getName()`. If you try to get the name programmatically, it might get obfuscated by tools like Proguard. Instead use a hard-coded string.\n- Don't add a counter or unique identifiers to wake lock tags. The code that creates a wake lock should use the same tag every time it runs. This practice enables the system to aggregate each method's wake lock usage.\n\nMake sure your app is visible in the foreground\n\nWhile a wake lock is active, the device is using power. The device's user\nshould be aware that this is going on. For this reason, if you're using a\nwake lock, you should display some notification to the user.\nIn practice, this means you should get and hold the wakelock in a\n[foreground service](/develop/background-work/services/fgs). Foreground services are required to display\na notification.\n\nIf a foreground service isn't the right choice for your app,\nyou probably shouldn't be using a wake lock, either. See the\n[Choose the right API to keep the device awake](/develop/background-work/background-tasks/awake)\ndocumentation for other ways to do work while your app isn't in the foreground.\n\nKeep the logic simple\n\nMake sure the logic for acquiring and releasing wake locks is as simple as\npossible. When your wake lock logic is tied to complex state machines, timeouts,\nexecutor pools, or callback events, any subtle bug in that logic can cause the\nwake lock to be held longer than expected. These bugs are difficult to diagnose\nand debug.\n\nCheck that the wake lock is always released\n\nIf you use a wake lock, you must make sure that every wake lock you acquire\nis properly released. This isn't always as easy as it sounds. For example,\nthe following code has a problem: \n\nKotlin \n\n @Throws(MyException::class)\n fun doSomethingAndRelease() {\n wakeLock.apply {\n acquire()\n doTheWork() // can potentially throw MyException\n release() // does not run if an exception is thrown\n }\n }\n\nJava \n\n void doSomethingAndRelease() throws MyException {\n wakeLock.acquire();\n doTheWork(); // can potentially throw MyException\n wakeLock.release(); // does not run if an exception is thrown\n }\n\nThe problem here is that the method `doTheWork()` can throw the exception\n`MyException`. If it does, the `doSomethingAndRelease()` method propagates\nthe exception outward, and it never reaches the `release()` call. The result\nis that the wake lock is acquired but not released, which is very bad.\n\nIn the corrected code, `doSomethingAndRelease()` makes sure to release the\nwake lock even if an exception is thrown: \n\nKotlin \n\n @Throws(MyException::class)\n fun doSomethingAndRelease() {\n wakeLock.apply {\n try {\n acquire()\n doTheWork()\n } finally {\n release()\n }\n }\n }\n\nJava \n\n void doSomethingAndRelease() throws MyException {\n try {\n wakeLock.acquire();\n doTheWork();\n } finally {\n wakeLock.release();\n }\n }"]]