WakeLock: vad är det, typer och hantering av sömnlås

Vad är WakeLock

WakeLock är ett systemlås som förbjuder Android att försätta enheten i lågenergiläge. Normalt stänger Android efter några sekunders inaktivitet av användaren av skärmen och för processorn i djupsömn (deep sleep), där bakgrundstrådar pausas. WakeLock förhindrar denna övergång genom att hålla CPU:n aktiv.

WakeLock-mekanismen hanteras via systemtjänsten PowerManager, som nås via metoden getSystemService(Context.POWER_SERVICE). Utvecklaren skapar ett WakeLock-objekt med angivande av låstyp och måste garanterat frigöra det efter slutförd uppgift, annars kommer enhetens batteri att laddas ur snabbt. Systemet frigör inte WakeLock automatiskt — detta är appens ansvar.

Med varje större Android-version skärper Google kontrollen över WakeLock. Från och med Android 9 (API 28) kan en bakgrundsapp inte få WakeLock utan giltig anledning, och systemet övervakar appar som missbrukar lås och kan tvinga dem att frigöras. I Android 12+ infördes ytterligare begränsningar för åtkomst till PowerManager för bakgrundsappar.

När är WakeLock nödvändigt

WakeLock krävs i scenarier där uppgiften inte kan avbrytas av att enheten går i viloläge: nedladdning av stor fil via instabil anslutning, videoinspelning, utförande av långa beräkningar utan användarmedverkan. Utan sömnlås går processorn i djupsömn, alla trådar (threads) fryser och uppgiften förblir oavslutad.

Google rekommenderar dock starkt att minimera användningen av WakeLock. I de flesta fall kan samma uppgift lösas med Foreground Service med notis, WorkManager eller JobScheduler. Dessa mekanismer tar hänsyn till batteri- och nätverksstatus, vilket förlänger enhetens batteritid.

Hur WakeLock fungerar

WakeLock fungerar via systemtjänsten PowerManager som hanterar enhetens strömstatus. När en app begär lås via powerManager.newWakeLock() ökar systemet CPU:ns aktivitetsnivå och förhindrar övergång till djupsömn. Efter anrop av wakeLock.release() återgår systemet till normalt energisparläge.

Det är viktigt att förstå att WakeLock inte förhindrar alla energisparlägen. Doze Mode (viloläge Android 6+) kan ignorera WakeLock i vissa faser — en app med ett hållet WakeLock får inte nätverksåtkomst i Doze-underhållsfönster. Detta innebär att även ett aktivt WakeLock inte garanterar utförande av nätverksoperationer under den andra fasen av Doze.

Varje WakeLock är kopplat till PowerManager.WakeLock på ramverkssidan. Systemet håller räkning på aktiva lås på processnivå: om en process håller flera WakeLock summeras de och frigöring sker först efter anrop av release() för varje lås. Android stöder även wake lock timeouts — automatisk frigöring efter angivet intervall. Att förlita sig på timeout rekommenderas dock inte: uppgiften kan slutföras tidigare och den extra hålltiden minskar batteritiden.

WakeLock och systemhändelser

När enheten går i viloläge (strömknappen) frigör Android tvångsmässigt alla SCREEN_DIM_WAKE_LOCK och SCREEN_BRIGHT_WAKE_LOCK men behåller PARTIAL_WAKE_LOCK. Detta innebär att skärmlåset inte kan hindra enheten från att stänga av displayen — endast PARTIAL_WAKE_LOCK kan fortsätta fungera efter att strömknappen tryckts in.

WakeLock-typer i Android

I Android finns flera WakeLock-typer, som var och en hanterar specifika enhetskomponenter. Valet av typ avgör vilka hårdvarukomponenter som förblir aktiva efter låsning. Felaktigt typval leder till överdriven energiförbrukning på grund av aktivering av onödiga moduler.

PARTIAL_WAKE_LOCK — huvudtypen

PARTIAL_WAKE_LOCK är den mest använda och rekommenderade typen. Den håller CPU:n aktiv men låter skärmen och tangentbordsbelysningen stängas av. Detta är det optimala valet för bakgrundsuppgifter: datanedladdning, bildbehandling, synkronisering. Skärmen släcks efter systemets timeout, vilket sparar batteri vid utförande av arbete som är osynligt för användaren.

Föråldrade typer (deprecated)

SCREEN_DIM_WAKE_LOCK, SCREEN_BRIGHT_WAKE_LOCK och FULL_WAKE_LOCK är markerade som föråldrade från och med Android 7 (API 24). De håller skärmen påslagen, vilket leder till betydande batteriförbrukning. Google rekommenderar att man istället använder FLAG_KEEP_SCREEN_ON via Activity.getWindow().addFlags() — denna flagga fungerar endast med aktiv Activity och kräver inte WAKE_LOCK-tillstånd, och systemet hanterar automatiskt skärmens hålltid.

WakeLock och energiförbrukning

WakeLock är en av de största batteriförbrukarna på Android. Varje sekund som sömnlåset hålls förbrukar extra energi eftersom processorn inte kan gå över till energieffektivt C-state. Google Power Dashboard-forskning visar att appar med felaktigt frigjorda WakeLock kan öka enhetens energiförbrukning med 30–50% i standby-läge.

Systemet övervakar appar som missbrukar WakeLock via komponenten Battery Historian. Utvecklaren kan analysera energiförbrukningsprofilen och upptäcka låckage — situationer där WakeLock skapades men inte frigjordes. Google Play Console visar WakeLock-statistik för publicerade appar och lång hålltid kan leda till dåliga recensioner.

Doze Mode och App Standby begränsar ytterligare WakeLock-funktionen. I den första fasen av Doze (Light Doze) tillåter systemet WakeLock i korta underhållsfönster. I den andra fasen (Deep Doze) kombineras WakeLock med andra lås och körs i ett gemensamt fönster. Om en app håller WakeLock i mer än 10 minuter utan användarinteraktion kan systemet tvinga frigöring och placera appen på svarta listan för batterioptimering.

• Battery Historian — verktyg för analys av energiförbrukning och WakeLock-läckage
• Doze Mode — begränsar WakeLock i underhållsfönster, kombinerar lås
• Google Play Console — visar WakeLock-statistik för publicerade appar
• Svarta listan — appen kan markeras av systemet som energikrävande

Bästa praxis för användning

Korrekt användning av WakeLock är en balans mellan behovet att utföra en uppgift och hänsyn till enhetens batteri. Google rekommenderar att följa några principer: frigör alltid WakeLock i finally eller via acquire(timeout), använd minimalt nödvändig låstyp och undvik långvarigt hållande utan absolut nödvändighet.

Frigöringsregel

WakeLock bör frigöras i samma kodblock där det skapades. För garanterad frigöring vid undantag används konstruktionen try-finally eller Kotlins use-block. På Android 10+ visar systemet en varning i logcat om WakeLock hålls i mer än 60 sekunder: "WakeLock held for more than 60 seconds" — detta är en signal om möjligt läckage.

Timeout vid förvärv

Metoden acquire(long timeout) frigör automatiskt WakeLock efter angiven tid i millisekunder. Detta är ett skyddsnät om frigöringskoden inte körs på grund av undantag eller bugg. Det rekommenderas att alltid ange en timeout som är lika med maximal förväntad exekveringstid för uppgiften plus 10–20% marginal.

Kontroll av låsets existens

Innan anrop av release() bör man kontrollera om WakeLock för närvarande hålls. Upprepat anrop av release() utan föregående acquire() orsakar RuntimeException: WakeLock under-locked. Det rekommenderas att lagra en statusflagga (isHeld) och före frigöring kontrollera wakeLock.isHeld().

Använda WakeLock i Kotlin

Låt oss titta på korrekt skapande och frigöring av WakeLock i Kotlin. Exemplet visar asynkron datanedladdning med hållande av PARTIAL_WAKE_LOCK, garanterad frigöring i try-finally-blocket och angivande av timeout för skydd mot läckage. Tjänsten använder CoroutineScope med IO-dispatch för att utföra bakgrundsuppgiften.

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() {
        // Simulering av filnedladdning
        delay(30000)
    }

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

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

Deklarera tillstånd i manifestet

För att använda WakeLock måste du lägga till tillstånd i AndroidManifest.xml. WAKE_LOCK-tillståndet är normalt (normal) — det kräver ingen runtime-förfrågan från användaren och beviljas automatiskt vid installation av appen. Google Play kan dock vägra publicering om appen inte har ett tydligt användningsscenario för WakeLock.

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

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

Alternativ till WakeLock

WakeLock är en lågnivåmekanism och Google rekommenderar att den där möjligt ersätts med modernare API:er. Det främsta alternativet är Foreground Service med notis, som automatiskt håller CPU-låset under tjänstens drift. Systemet hanterar själv WakeLock för Foreground Service, vilket befriar utvecklaren från behovet av explicit förvärv och frigöring.

WorkManager är det näst viktigaste verktyget för bakgrundsuppgifter. Det garanterar utförande av arbete även när enheten går i Doze och efter omstart. WorkManager stöder hållande av lås (hold lock) internt — utvecklaren behöver inte arbeta explicit med PowerManager. Uppgiften körs i Doze-underhållsfönstret med automatisk hantering av sömnlåset.

För regelbundna uppgifter som kräver exakt tid används AlarmManager med setAndAllowWhileIdle(), som kan väcka enheten från Doze. AlarmManager är dock endast lämplig för korta operationer — den är inte avsedd för långvarigt hållande av WakeLock. Om uppgiften tar längre tid än 10 sekunder måste AlarmManager kombineras med en BroadcastReceiver som startar Foreground Service.

• Foreground Service — automatisk WakeLock-hantering med notis
• WorkManager — garanterad utförande med hänsyn till Doze och omstart
• JobScheduler — schemaläggning med hänsyn till nätverk, laddning och inaktivitet
• AlarmManager — väckning av enhet för korta uppgifter enligt schema