Elige la API correcta para mantener el dispositivo activo
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Cuando el usuario deja inactivo su dispositivo Android, este entra rápidamente en estado de suspensión para evitar que se agote la batería. Sin embargo, hay situaciones en las que una app necesita evitar que la CPU entre en el estado de suspensión. En algunos casos, es posible que la app deba mantener la pantalla encendida mientras funciona. En otros casos, la app no necesita mantener la pantalla encendida, pero sí requiere que la CPU esté activa.
El enfoque que elijas dependerá de las necesidades de tu app. Sin embargo, como regla general, te recomendamos que uses el enfoque más sencillo posible para minimizar el impacto de tu app en los recursos del sistema. Este documento te ayuda a elegir la tecnología de Android correcta para tu situación.
Elige la tecnología adecuada
La mejor opción para mantener el dispositivo activo depende de las necesidades de tu app. En esta sección, se te ayudará a elegir el enfoque adecuado.
¿Tu app necesita mantener la pantalla encendida?
Si la respuesta es Sí, consulta Cómo mantener la pantalla encendida. Es posible que haya una API de propósito especial que haga lo que necesitas. Por ejemplo, si implementas una IU de llamadas telefónicas, puedes usar el framework de telecomunicaciones de Android, que mantiene la pantalla encendida cuando es necesario. Si no hay una API de propósito especial para tu situación, puedes usar la API de keepScreenOn.
¿Tu app ejecuta un servicio en primer plano y necesitas mantener el dispositivo activo cuando la pantalla está apagada mientras se ejecuta el servicio?
Si la respuesta es No, no es necesario que mantengas el dispositivo activo. Si el usuario interactúa activamente con la app, el dispositivo permanecerá activo. Si el usuario no interactúa con tu app y no estás ejecutando un servicio en primer plano, debes permitir que el dispositivo entre en modo de suspensión cuando sea necesario. Si solo necesitas asegurarte de que se realice algún trabajo mientras el usuario no está en la app, consulta la documentación sobre tareas en segundo plano para encontrar la mejor opción.
Si la respuesta es Sí, primero confirma que realmente necesitas usar un servicio en primer plano. Según tu situación, es posible que haya una API de propósito especial que puedas usar para satisfacer tu necesidad en lugar de un servicio en primer plano.
Puedes encontrar información sobre estos en la documentación del servicio en primer plano. Por ejemplo, si necesitas hacer un seguimiento de la ubicación del usuario, es posible que puedas usar la API de geocercas en lugar de un servicio en primer plano de location.
¿Perjudicaría la experiencia del usuario si el dispositivo se suspende mientras se ejecuta el servicio en primer plano y la pantalla del dispositivo está apagada? (Por ejemplo, si usas un servicio en primer plano para actualizar las notificaciones, no sería una mala experiencia del usuario si el dispositivo se suspende).
Si la respuesta es No, no uses un bloqueo de activación. La acción se reanuda automáticamente cuando el usuario interactúa con su dispositivo, lo que lo saca del estado de suspensión.
Si tu app realiza alguna de las siguientes acciones, no es necesario que configures un bloqueo de activación por tu cuenta. Las siguientes acciones y APIs mantienen el dispositivo activo.
Si reproduces audio, el sistema de audio establece y administra un bloqueo de activación por ti, por lo que no es necesario que lo hagas tú mismo.
Si usas APIs o bibliotecas de programación de tareas, como WorkManager, JobScheduler o DownloadManager, el sistema o la biblioteca adquieren un bloqueo de activación que se atribuye a tu app.
Algunos sensores del dispositivo son sensores de activación. Puedes usar SensorManager para que esos sensores activen el dispositivo cuando tengan datos para informar. Para verificar si un sensor es de activación, llama a Sensor.isWakeUpSensor.
Si programas una alarma, el dispositivo se activa cuando suena la alarma, incluso si tu app no está en ejecución.
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2025-09-08 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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)"]]
