Wybierz odpowiedni interfejs API, aby urządzenie było aktywne
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Gdy użytkownik nie używa urządzenia z Androidem, urządzenie to szybko przechodzi w stan zawieszenia, aby nie wyczerpywać baterii. Czasami jednak aplikacja musi uniemożliwić procesorowi przejście w stan zawieszenia. W niektórych przypadkach aplikacja może wymagać włączonego ekranu podczas działania. W innych przypadkach aplikacja nie musi włączać ekranu, ale musi aktywować procesor.
Wybór podejścia zależy od potrzeb aplikacji. Ogólna zasada jest taka, że należy stosować jak najmniejsze podejście, aby zminimalizować wpływ aplikacji na zasoby systemu. Z tego dokumentu dowiesz się, jak wybrać odpowiednią technologię Androida do danej sytuacji.
Wybór odpowiedniej technologii
Najlepsza opcja utrzymywania urządzenia w stanie czuwania zależy od potrzeb aplikacji. Ten
oddział pomoże Ci wybrać właściwe podejście.
Czy aplikacja musi mieć włączony ekran?
Jeśli odpowiedź brzmi Tak, zapoznaj się z sekcją Pozostawianie ekranu włączonego. Może istnieć interfejs API do specjalnych celów, który spełnia Twoje wymagania. Jeśli na przykład wdrażasz interfejs użytkownika połączeń telefonicznych, możesz użyć ramy telekomunikacyjnej Androida, która w razie potrzeby utrzymuje ekran w stanie włączonym. Jeśli w Twoim przypadku nie ma interfejsu API do specjalnego celu, możesz użyć interfejsu keepScreenOnAPI.
Czy aplikacja uruchamia usługę na pierwszym planie i musisz utrzymać urządzenie w stanie czuwania, gdy ekran jest wyłączony?
Jeśli odpowiedź brzmi Nie, nie musisz utrzymywać urządzenia w stanie czuwania. Jeśli użytkownik aktywnie korzysta z aplikacji, urządzenie pozostanie aktywne. Jeśli użytkownik nie wchodzi w interakcję z Twoją aplikacją i nie uruchamiasz usługi na pierwszym planie, w razie potrzeby przełącz urządzenie w tryb zawieszenia. Jeśli chcesz tylko mieć pewność, że pewne zadania zostaną wykonane, gdy użytkownik nie korzysta z aplikacji, zapoznaj się z dokumentacją dotyczącą zadań w tle, aby znaleźć najlepszą opcję.
Jeśli odpowiedź brzmi Tak, najpierw sprawdź, czy rzeczywiście musisz korzystać z usługi na pierwszym planie. W zależności od sytuacji możesz użyć interfejsu API do specjalnego celu zamiast usługi na pierwszym planie.
Informacje na ten temat znajdziesz w dokumentacji dotyczącej usług na pierwszym planie. Jeśli na przykład chcesz śledzić lokalizację użytkownika, zamiast usługi na pierwszym planie location możesz użyć interfejsu Geofencing API.
Czy wrażenia użytkownika pogorszy zawieszenie urządzenia, gdy uruchomiona jest usługa na pierwszym planie, a ekran jest wyłączony? Jeśli na przykład używasz usługi na pierwszym planie do aktualizowania powiadomień, nie będzie to dla użytkownika problemem, jeśli urządzenie jest zawieszone.
Jeśli odpowiedź brzmi Nie, nie używaj wakelocka. Działanie zostanie wznowione automatycznie, gdy użytkownik wejdzie w interakcję z urządzeniem, co spowoduje jego odwieszenie.
Działania, które powodują, że urządzenie pozostaje aktywne
Jeśli Twoja aplikacja wykonuje którąś z tych czynności, nie musisz samodzielnie ustawiać blokady aktywacji. Poniższe działania i interfejsy API utrzymują urządzenie w stanie czuwania.
Jeśli odtwarzasz dźwięk, system audio skonfiguruje blokadę aktywacji i będzie nią zarządzać. Nie musisz tego robić samodzielnie.
Jeśli używasz interfejsów API lub bibliotek do planowania zadań, takich jak WorkManager, JobScheduler lub DownloadManager, system lub biblioteka uzyskuje blokadę uśpienia przypisaną do Twojej aplikacji.
Niektóre czujniki urządzenia są czujnikami wybudzania. Możesz użyć SensorManager, aby te czujniki wybudzały urządzenie, gdy mają dane do przekazania. Aby sprawdzić, czy czujnik jest czujnikiem wybudzenia, zadzwoń pod numer Sensor.isWakeUpSensor.
Treść strony i umieszczone na niej fragmenty kodu podlegają licencjom opisanym w Licencji na treści. Java i OpenJDK są znakami towarowymi lub zastrzeżonymi znakami towarowymi należącymi do firmy Oracle lub jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-07-26 UTC.
[null,null,["Ostatnia aktualizacja: 2025-07-26 UTC."],[],[],null,["# Choose the right API to keep the device awake\n\nWhen 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---------------------------\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 wakelock. 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----------------------------------\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\nSee also\n--------\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)"]]
