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 korzysta z urządzenia z Androidem, szybko przechodzi ono w stan zawieszenia, aby uniknąć rozładowania baterii. Czasami jednak aplikacja musi uniemożliwić przejście procesora w stan zawieszenia. W niektórych przypadkach aplikacja może wymagać włączonego ekranu podczas działania. W innych przypadkach aplikacja nie musi utrzymywać włączonego ekranu, ale nadal potrzebuje aktywnego procesora.
Podejście, które zastosujesz, zależy od potrzeb aplikacji. Ogólna zasada jest jednak taka, że należy używać jak najlżejszego podejścia, aby zminimalizować wpływ aplikacji na zasoby systemowe. Ten dokument pomoże Ci wybrać odpowiednią technologię Androida w Twojej sytuacji.
Wybór odpowiedniej technologii
Najlepsza opcja utrzymania urządzenia w stanie aktywności zależy od potrzeb aplikacji. Ta sekcja pomoże Ci wybrać odpowiednie podejście.
Czy aplikacja musi utrzymywać włączony ekran?
Jeśli Tak, zapoznaj się z sekcją Włączanie ekranu. Może istnieć interfejs API specjalnego przeznaczenia, który spełnia Twoje potrzeby. Jeśli na przykład implementujesz interfejs połączeń telefonicznych, możesz użyć platformy telekomunikacyjnej Androida, która w razie potrzeby utrzymuje ekran włączony. Jeśli w Twojej sytuacji nie ma interfejsu API specjalnego przeznaczenia, możesz użyć keepScreenOninterfejsu API.
Czy aplikacja korzysta z usługi na pierwszym planie i musisz utrzymywać urządzenie w stanie aktywności, gdy ekran jest wyłączony, a usługa działa?
Jeśli Nie, nie musisz utrzymywać urządzenia w stanie aktywności. Jeśli użytkownik aktywnie korzysta z aplikacji, urządzenie pozostanie włączone. Jeśli użytkownik nie korzysta z aplikacji, a usługa nie działa na pierwszym planie, w razie potrzeby należy przełączyć urządzenie w tryb zawieszenia. Jeśli chcesz tylko mieć pewność, że niektóre zadania zostaną wykonane, gdy użytkownik nie będzie korzystać z aplikacji, zapoznaj się z dokumentacją dotyczącą zadań w tle, aby znaleźć najlepszą opcję.
Jeśli tak, najpierw sprawdź, czy naprawdę musisz używać usługi działającej na pierwszym planie. W zależności od sytuacji możesz użyć specjalnego interfejsu API zamiast usługi na pierwszym planie.
Informacje o nich znajdziesz w dokumentacji usługi na pierwszym planie. Jeśli na przykład musisz śledzić lokalizację użytkownika, możesz użyć interfejsu Geofencing API zamiast location usługi na pierwszym planie.
Czy zawieszenie urządzenia, gdy usługa na pierwszym planie jest uruchomiona, a ekran urządzenia jest wyłączony, wpłynie negatywnie na wrażenia użytkownika? (Jeśli na przykład używasz usługi działającej na pierwszym planie do aktualizowania powiadomień, zawieszenie urządzenia nie wpłynie negatywnie na wrażenia użytkownika).
Jeśli Nie, nie używaj blokady uśpienia. Działanie zostanie automatycznie wznowione, gdy użytkownik zacznie korzystać z urządzenia, co spowoduje wyjście z trybu zawieszenia.
Jeśli Twoja aplikacja wykonuje którąś z tych czynności, nie musisz samodzielnie ustawiać blokady wybudzania. Poniższe działania i interfejsy API utrzymują urządzenie w stanie aktywności.
Jeśli odtwarzasz dźwięk, system audio ustawia i zarządza blokadą wybudzania za Ciebie. 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 to czujniki wybudzania. Możesz użyć SensorManager, aby te czujniki wybudzały urządzenie, gdy mają dane do przekazania. Aby sprawdzić, czy czujnik jest czujnikiem wybudzania, wywołaj funkcję Sensor.isWakeUpSensor.
Jeśli zaplanujesz alarm, urządzenie wybudzi się, gdy alarm zadzwoni, nawet jeśli aplikacja nie będzie działać.
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-09-08 UTC.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 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)"]]
