WakeLock: Was es ist, Typen und Verwaltung der Schlafsperre

Was ist WakeLock

WakeLock ist eine Systemsperre, die verhindert, dass Android das Gerät in den Energiesparmodus versetzt. Normalerweise schaltet Android nach einigen Sekunden der Inaktivität des Benutzers den Bildschirm aus und versetzt die CPU in den Tiefschlafzustand (Deep Sleep), wodurch Hintergrund-Threads angehalten werden. WakeLock verhindert diesen Übergang, indem es die CPU aktiv hält.

Der WakeLock-Mechanismus wird über den Systemdienst PowerManager verwaltet, der über die Methode getSystemService(Context.POWER_SERVICE) aufgerufen wird. Der Entwickler erstellt ein WakeLock-Objekt, gibt den Sperrentyp an und muss es nach Abschluss der Aufgabe garantiert freigeben, sonst wird der Akku des Geräts schnell entladen. Das System gibt WakeLock nicht automatisch frei — dies liegt in der Verantwortung der App.

Mit jeder größeren Android-Version verschärft Google die Kontrolle über WakeLock. Ab Android 9 (API 28) kann eine App im Hintergrund ohne triftigen Grund kein WakeLock erwerben, und das System überwacht Apps, die Sperren missbrauchen, und kann sie zwangsweise freigeben. In Android 12+ wurden zusätzliche Einschränkungen für den PowerManager-Zugriff von Hintergrund-Apps eingeführt.

Wann WakeLock benötigt wird

WakeLock wird in Szenarien benötigt, in denen eine Aufgabe nicht durch den Schlafmodus des Geräts unterbrochen werden darf: Herunterladen einer großen Datei über eine instabile Verbindung, Videoaufnahme, Durchführung langer Berechnungen ohne Benutzerinteraktion. Ohne eine Schlafsperre geht die CPU in den Tiefschlaf, alle Threads werden eingefroren und die Aufgabe bleibt unerledigt.

Google empfiehlt jedoch dringend, die Verwendung von WakeLock zu minimieren. In den meisten Fällen kann dieselbe Aufgabe mit Foreground Service mit Benachrichtigung, WorkManager oder JobScheduler gelöst werden. Diese Mechanismen berücksichtigen den Batterie- und Netzwerkzustand, was die Akkulaufzeit des Geräts verlängert.

Wie WakeLock funktioniert

WakeLock funktioniert über den PowerManager-Systemdienst, der den Stromzustand des Geräts verwaltet. Wenn eine App über powerManager.newWakeLock() eine Sperre anfordert, erhöht das System die CPU-Aktivität und verhindert den Tiefschlaf. Nach dem Aufruf von wakeLock.release() kehrt das System in den normalen Energiesparmodus zurück.

Es ist wichtig zu verstehen, dass WakeLock nicht alle Energiesparmodi verhindert. Der Doze-Modus (Schlafmodus ab Android 6+) kann WakeLock in bestimmten Phasen ignorieren — eine App mit gehaltenem WakeLock erhält während der Doze-Wartungsfenster keinen Netzwerkzugriff. Dies bedeutet, dass selbst ein aktives WakeLock keine Netzwerkoperationen während der zweiten Doze-Phase garantiert.

Jedes WakeLock ist mit einem PowerManager.WakeLock auf der Framework-Seite verbunden. Das System zählt aktive Sperren auf Prozessebene: Wenn ein Prozess mehrere WakeLocks hält, summieren sie sich, und die Freigabe erfolgt erst nach dem Aufruf von release() für jede Sperre. Android unterstützt auch WakeLock-Timeouts — automatische Freigabe nach einem bestimmten Intervall. Sich auf das Timeout zu verlassen, wird jedoch nicht empfohlen: Die Aufgabe kann früher abgeschlossen sein, und die zusätzliche Haltezeit verkürzt die Akkulaufzeit.

WakeLock und Systemereignisse

Wenn das Gerät in den Schlafmodus wechselt (Ein-/Ausschalter), gibt Android zwangsweise alle SCREEN_DIM_WAKE_LOCK und SCREEN_BRIGHT_WAKE_LOCK frei, behält aber PARTIAL_WAKE_LOCK bei. Dies bedeutet, dass eine Bildschirmsperre das Display nicht eingeschaltet halten kann — nur PARTIAL_WAKE_LOCK kann nach dem Drücken des Ein-/Ausschalters weiterarbeiten.

Arten von WakeLock in Android

Android hat mehrere Arten von WakeLock, die jeweils bestimmte Gerätekomponenten steuern. Die Wahl des Typs bestimmt, welche Hardwarekomponenten nach der Sperre aktiv bleiben. Die falsche Wahl führt zu übermäßigem Stromverbrauch, da unnötige Module eingeschaltet bleiben.

PARTIAL_WAKE_LOCK — Haupttyp

PARTIAL_WAKE_LOCK ist der am häufigsten verwendete und empfohlene Typ. Er hält die CPU aktiv, erlaubt aber das Ausschalten des Bildschirms und der Tastaturbeleuchtung. Dies ist die optimale Wahl für Hintergrundaufgaben: Daten laden, Bildverarbeitung, Synchronisation. Der Bildschirm schaltet sich nach dem System-Timeout aus, was Batterie spart, während für den Benutzer unsichtbare Arbeit ausgeführt wird.

Veraltete Typen (deprecated)

SCREEN_DIM_WAKE_LOCK, SCREEN_BRIGHT_WAKE_LOCK und FULL_WAKE_LOCK sind seit Android 7 (API 24) veraltet. Sie halten den Bildschirm eingeschaltet, was zu erheblichem Batterieverbrauch führt. Google empfiehlt stattdessen die Verwendung von FLAG_KEEP_SCREEN_ON über Activity.getWindow().addFlags() — dieses Flag funktioniert nur, wenn die Activity aktiv ist, und benötigt keine WAKE_LOCK-Berechtigung, während das System die Bildschirmhaltezeit automatisch verwaltet.

WakeLock und Stromverbrauch

WakeLock ist einer der Hauptstromverbraucher auf Android. Jede Sekunde, in der eine Schlafsperre gehalten wird, verbraucht zusätzliche Energie, da die CPU nicht in einen energieeffizienten C-State wechseln kann. Die Forschung des Google Power Dashboard zeigt, dass Apps mit unsachgemäß freigegebenen WakeLocks den Stromverbrauch des Geräts im Standby-Modus um 30–50% erhöhen können.

Das System verfolgt Apps, die WakeLock missbrauchen, über die Komponente Battery Historian. Der Entwickler kann das Stromverbrauchsprofil analysieren und Sperrlecks identifizieren — Situationen, in denen ein WakeLock erstellt, aber nicht freigegeben wurde. Die Google Play Console zeigt WakeLock-Statistiken für veröffentlichte Apps, und eine hohe Haltezeit kann zu schlechten Bewertungen führen.

Der Doze-Modus und App Standby schränken den WakeLock-Betrieb weiter ein. In der ersten Doze-Phase (Light Doze) erlaubt das System WakeLock in kurzen Wartungsfenstern. In der zweiten Phase (Deep Doze) wird WakeLock mit anderen Sperren zusammengeführt und in einem gemeinsamen Fenster ausgeführt. Wenn eine App länger als 10 Minuten ohne Benutzerinteraktion einen WakeLock hält, kann das System ihn zwangsweise freigeben und die App in die schwarze Liste der Batterieoptimierung aufnehmen.

• Battery Historian — Tool zur Analyse des Stromverbrauchs und von WakeLock-Lecks
• Doze-Modus — schränkt WakeLock in Wartungsfenstern ein, führt Sperren zusammen
• Google Play Console — zeigt WakeLock-Statistiken für veröffentlichte Apps
• Schwarze Liste — die App kann vom System als stromhungrig markiert werden

Bewährte Verfahren zur Nutzung

Die korrekte Verwendung von WakeLock ist eine Balance zwischen der Notwendigkeit, eine Aufgabe zu erledigen, und der Schonung des Akkus des Geräts. Google empfiehlt, mehrere Grundsätze zu befolgen: WakeLock immer in einem finally-Block oder über acquire(timeout) freigeben, den minimal benötigten Sperrentyp verwenden und längeres Halten ohne äußerste Notwendigkeit vermeiden.

Freigaberegel

WakeLock sollte im selben Codeblock freigegeben werden, in dem es erstellt wurde. Um die Freigabe bei Ausnahmen zu gewährleisten, wird die try-finally-Konstruktion oder der use-Block von Kotlin verwendet. Ab Android 10+ zeigt das System eine Warnung im Logcat an, wenn ein WakeLock länger als 60 Sekunden gehalten wird: "WakeLock held for more than 60 seconds" — dies signalisiert ein mögliches Leck.

Timeout bei der Erfassung

Die Methode acquire(long timeout) gibt WakeLock automatisch nach der angegebenen Zeit in Millisekunden frei. Dies ist eine Absicherung für den Fall, dass der Freigabecode aufgrund einer Ausnahme oder eines Fehlers nicht ausgeführt wird. Es wird empfohlen, immer ein Timeout anzugeben, das der maximal erwarteten Aufgabenausführungszeit plus einer Marge von 10–20% entspricht.

Überprüfung des Sperrzustands

Vor dem Aufruf von release() sollte überprüft werden, ob der WakeLock derzeit gehalten wird. Ein erneuter Aufruf von release() ohne vorheriges acquire() löst eine RuntimeException: WakeLock under-locked aus. Es wird empfohlen, ein Zustandsflag (isHeld) zu speichern und vor der Freigabe wakeLock.isHeld() zu überprüfen.

Verwendung von WakeLock in Kotlin

Betrachten wir die korrekte Erstellung und Freigabe von WakeLock in Kotlin. Das Beispiel demonstriert asynchrones Datenladen mit gehaltenem PARTIAL_WAKE_LOCK, garantierte Freigabe in einem try-finally-Block und ein Timeout als Absicherung gegen Lecks. Der Dienst verwendet CoroutineScope mit dem IO-Dispatcher zur Ausführung von Hintergrundaufgaben.

class DownloadService : Service() {

    private lateinit var wakeLock: PowerManager.WakeLock
    private val scope = CoroutineScope(Dispatchers.IO + SupervisorJob())

    override fun onCreate() {
        super.onCreate()
        val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
        wakeLock = powerManager.newWakeLock(
            PowerManager.PARTIAL_WAKE_LOCK,
            "download:wakelock"
        )
    }

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        wakeLock.acquire(60000)
        scope.launch {
            try {
                downloadFile()
            } finally {
                if (wakeLock.isHeld()) {
                    wakeLock.release()
                }
            }
        }
        return START_NOT_STICKY
    }

    private suspend fun downloadFile() {
        // Simulation des Dateidownloads
        delay(30000)
    }

    override fun onDestroy() {
        super.onDestroy()
        scope.cancel()
        if (wakeLock.isHeld()) {
            wakeLock.release()
        }
    }

    override fun onBind(intent: Intent): IBinder? = null
}

Berechtigungsdeklaration im Manifest

Zur Verwendung von WakeLock muss die Berechtigung in AndroidManifest.xml hinzugefügt werden. Die WAKE_LOCK-Berechtigung ist eine normale Berechtigung — sie erfordert keine Laufzeitanfrage beim Benutzer und wird bei der Installation der App automatisch erteilt. Allerdings kann Google Play die Veröffentlichung ablehnen, wenn die App keinen offensichtlichen Anwendungsfall für WakeLock hat.

<uses-permission
    android:name="android.permission.WAKE_LOCK" />

<uses-permission
    android:name="android.permission.DEVICE_POWER" />

Alternativen zu WakeLock

WakeLock ist ein Low-Level-Mechanismus, und Google empfiehlt, ihn wann immer möglich durch modernere APIs zu ersetzen. Die wichtigste Alternative ist Foreground Service mit einer Benachrichtigung, der automatisch die CPU-Sperre für die Dauer des Dienstes hält. Das System selbst verwaltet WakeLock für Foreground Service und befreit den Entwickler von explizitem Erwerb und Freigabe.

WorkManager ist das zweitwichtigste Tool für Hintergrundaufgaben. Es garantiert die Aufgabenausführung auch wenn das Gerät in den Doze-Modus wechselt und nach einem Neustart. WorkManager unterstützt intern eine Halte-Sperre (Hold Lock) — der Entwickler muss nicht explizit mit PowerManager arbeiten. Die Aufgabe wird im Doze-Wartungsfenster mit automatischer Schlafsperrenverwaltung ausgeführt.

Für wiederkehrende Aufgaben, die eine genaue Zeitsteuerung erfordern, wird AlarmManager mit setAndAllowWhileIdle() verwendet, der das Gerät aus dem Doze-Modus wecken kann. AlarmManager ist jedoch nur für kurze Operationen geeignet — er ist nicht für längeres WakeLock-Halten ausgelegt. Wenn eine Aufgabe länger als 10 Sekunden dauert, kombinieren Sie AlarmManager mit einem BroadcastReceiver, der einen Foreground Service startet.

• Foreground Service — automatische WakeLock-Verwaltung mit Benachrichtigung
• WorkManager — garantierte Ausführung mit Doze- und Neustart-Unterstützung
• JobScheduler — Planung mit Netzwerk, Ladung und Leerlauf
• AlarmManager — Wecken des Geräts für kurze geplante Aufgaben