Come gestire i WakeLock (orfani)?

Immagino che la maggior parte di voi abbia sentito parlare di WakeLock . Molti di voi li avranno già sperimentati , consapevolmente o no. Alcuni possono sapere come gestirli in generale, ma solo pochi sanno come trattare con i "candidati più complicati".

Per chi non lo sapesse, anche se il link sopra riportato porta a una spiegazione, un breve riepilogo: le app potrebbero richiedere WAKE_LOCKdi impedire la sospensione di un componente del dispositivo, in modo da poter eseguire un'attività anche quando lo schermo è spento. Questo è molto utile nella maggior parte dei casi (ad esempio, tenere lo schermo acceso durante la navigazione, mantenere il WiFi attivo per lo streaming di musica) - ma usato nel modo sbagliato, fa scaricare la batteria a breve termine (fino al 25% all'ora) .

La maggior parte delle volte è facile identificare la fonte (di solito un'app che si comporta male) - lo mostrerò in una risposta di seguito, poiché potrebbe rivelarsi utile per molti utenti. Ma cosa fare se l'app che ha richiesto WakeLock esce senza rilasciarlo? Il sistema Android non se ne occuperà . Certo, un riavvio risolverebbe il problema, ma non è sempre un'opzione (desiderata).

Quindi, dal punto di vista degli utenti (non sto chiedendo soluzioni di sviluppo, ma come un utente può gestire le cose):

Cosa può essere fatto * dall'utente * per risolvere il problema ed evitare un ulteriore consumo della batteria?

Preferisco risposte che non coinvolgono root (quindi tutti gli utenti possono trarne beneficio). Tuttavia, anche le "soluzioni radicate" sono pienamente valide e benvenute.

Come posso sapere che sono interessato?

Questa è probabilmente la prima domanda a coloro che non hanno familiarità con questo argomento. Con Gingerbread (Android 2.3) e versioni successive, hai un servizio a bordo che ti aiuta a capire: statistiche sulla batteria. Sebbene i produttori tendano a posizionarlo in punti diversi, si trova principalmente in Impostazioni → Informazioni sul telefono → Batteria o simile e mostra un elenco delle app che hanno utilizzato la maggior parte della batteria. Inoltre, c'è un piccolo grafico. Tocca quello e ti porta a una schermata simile a questa:

^{Schermata delle statistiche della batteria su Android 2.3}

Ho scelto uno screenshot da uno dei miei dispositivi che illustra il problema. Osservando le due barre blu inferiori ("Aktiv" = Il dispositivo è stato tenuto sveglio (attivo), "Bildschirm an" = "Screen on"), la barra blu più a destra su "Aktiv" indica un WakeLock: il dispositivo è stato tenuto occupato nonostante il fatto che lo schermo fosse spento. Quindi con questo possiamo essere abbastanza sicuri di avere un WakeLock - ma non possiamo dire chi l'abbia causato.

Se il tuo dispositivo non offre questa schermata (o le barre in basso: ho appena scoperto, ad esempio, LG Optimus 4X con Android 4.0.3 ha tagliato queste barre), puoi trovarle, ad esempio, usando GSam Battery Monitor :

^{Informazioni simili da GSam Battery Monitor - qui le "barre blu" menzionate sono di colore giallo / arancione}

Cosa ha causato WakeLock?

Sfortunatamente, non è possibile rispondere a questa domanda utilizzando app preinstallate (tranne, forse, alcune ROM personalizzate). Ma ci sono strumenti disponibili che possono. Il candidato più noto per questo è BetterBatteryStats e ci mostra la causa nella sua sezione parziale di wakelocks :

^{Schermate di BetterBatteryStats}

Nel primo esempio ² (tratto dalla pagina del playstore dell'app), l'evento che ha causato la maggior parte dei WakeLock è stato desiderato: non vogliamo che la riproduzione venga interrotta durante l'ascolto della musica. Quindi il secondo esempio ³ (tratto da un caso reale su uno dei miei dispositivi) potrebbe rivelarsi migliore: i 3 eventi più importanti sono causati dalla stessa app, che aveva bisogno di WakeLock per mantenere attivo il servizio push IMAP.

Per un'alternativa a BetterBatteryStats , controlla l' app Wakelock Detector menzionata nella risposta di UzumApps - che sembra più facile da gestire soprattutto per i non-tecnici:

^{Wakelock Detector - Clicca l'immagine per ingrandire. (Fonte: Google Play )}

Cosa si può fare?

Se il caso è chiaro come nel secondo esempio della sezione precedente, l'azione è abbastanza ovvia - almeno nel mio caso: non ho bisogno di essere informato immediatamente quando arriva una mail; un ritardo di 30 minuti è assolutamente accettabile. Quindi sono entrato nell'app di posta, ho disabilitato Push IMAP (vedi anche: Push Email ) e invece sono passato a un intervallo di polling di 30 minuti. I WakeLock non sono completamente scomparsi, ma sono notevolmente diminuiti: la durata della batteria è notevolmente migliorata.

Poi c'è il caso menzionato nella domanda stessa: un'app che si comporta male non rilasciando WakeLock. Affronta lo sviluppatore con i tuoi risultati e chiedi una soluzione. Se consegna: problema risolto. In caso contrario: è quasi sempre disponibile un'app alternativa.

E se fosse il sistema Android stesso?

Sì, a volte sembra proprio questo: il 98% o più consumato da alcuni servizi Android. Oh, se è del 98%, nella maggior parte dei casi il candidato si chiama LocationManagerService . Cattivo che ci spia? Non necessariamente. In questo caso speciale, il "cattivo" elencato non è nemmeno colpevole, almeno non direttamente. Ecco un'altra app che richiede la posizione corrente troppo frequentemente. C'è un eccellente articolo su Setera.org a riguardo: Individuare il consumo della batteria Android LocationManagerService . Per dare un riassunto: utilizza Androiddumpsysfunzione (richiede root!) per scaricare uno stato del sistema e consente di esaminare i listener stabiliti per LocationManagerService. Uno sguardo più da vicino alla loro configurazione mostra che vengono costantemente "martellati" per le informazioni sulla posizione (alcuni lo fanno in modo permanente, cioè senza una pausa). Poiché l'ID dell'app è elencato insieme e in un altro punto del dump anche insieme al nome tecnico dell'app, è ancora possibile identificarlo e intraprendere le azioni appropriate.

E gli UFO?

Sfortunatamente, ci sono tali: App che hanno registrato un WakeLock e quindi sono usciti senza rilasciarlo. Ciò che resta sono * Unused F *** ing Obsoletes * - I WakeLock non vengono utilizzati. Quindi non c'è modo di portare semplicemente l'app in primo piano e riconfigurare o far rilasciare i suoi WakeLock.

Qui l'unica soluzione a me nota è un riavvio - e vorrei avere una soluzione migliore. Ovviamente, se conosci l'app colpevole, i passaggi relativi sono gli stessi di cui sopra: informa lo sviluppatore, ottieni una correzione o sostituisci l'app. Ma per sbarazzarsi dell'attuale WakeLock? Forse qualcun altro può fornire una migliore alternativa al riavvio?

Ci sono alcune letture consigliate?

Sicuro. Uno per ora, potrei aggiungere più tardi:

• [GUIDA] Definizione di Wakelocks e come prevenirli (XDA Developers, marzo 2013)

In breve, questa è un'ottima domanda, ma temo che meriti di più che informare l'utente finale!

Riprogettare il kernel per eliminare i wake-lock e utilizzare un modo più approfondito ed efficiente di gestire meglio il principio prolungando così la durata della batteria.

Sfortunatamente, è stata accettata come soluzione di fatto per consentire la "gestione dell'alimentazione" nonostante non sia nemmeno esattamente efficiente! C'è stata un'ampia discussione sui wakelocks (con Gregh Kroah Hartman - il guru di Linux per lo sviluppo dei driver - sto cercando su Google il link esatto), altri siti come LWN.net e un altro articolo spiegato nello stesso sito qui . Questo era l'articolo che Gregh Kroah Hartman faceva riferimento a questo blog , in cui sembra concordare con la soluzione alternativa proposta da Rafael J. Wysocki che ha documentato molto sulla potenziale alternativa. Non sono sicuro che sia effettivamente presente nel più moderno kernel v3.xx

Le app mal progettate possono e spesso richiedono wakelock come tenere lo schermo acceso, ma in effetti, in questo scenario per tenere lo schermo acceso, esiste in realtà un modo più efficiente per farlo:

getWindow().addFlags(LayoutParams.FLAG_KEEP_SCREEN_ON);

Mentre, sforzandosi di mantenere questo gergo ecc. Per l'utente finale, in realtà il nocciolo del problema si riduce al codice del kernel nel modo in cui sono gestiti i wakelock.

Ecco un breve riassunto su XDA su ciò che è wakelocks per i non iniziati. Usando BetterBatteryStats , si potrebbe vedere esattamente quale processo sta scaricando la batteria, il wiki è ospitato su github ed è disponibile sul mercato qui .

Dai un'occhiata a Wakelock Detector: XDA-Developers / Google Play :

Il rilevatore di Wakelock raggruppa i wakelock dell'app in una vista espandibile per un aspetto migliore. E mostra quali app sono in esecuzione. E ci sono pulsanti di informazioni di disinstallazione kill nella vista estesa dell'app.

^{Clicca sull'immagine per ingrandirla. (Fonte: Google Play )}

Divulgazione: sono uno degli sviluppatori responsabili di questa app. Altri quattro amici sono con me a lavorare su questo progetto come hobby.

Un paio di modi che potrebbero aiutare gli utenti di dispositivi non rootati

1. Visto che @Uzumapps, uno degli sviluppatori dell'app ha pubblicato una soluzione utilizzando Wakelock Detector ( WLD ), sono sorpreso che non abbia aggiornato sull'utilizzo dell'app che può anche essere usata senza root chiamata Wakelock Detector Light ! Ho scoperto questo alla ricerca di una soluzione per il mio nuovo dispositivo (non rootato).

Questo è uno sviluppo recente e quindi la pubblicazione per utenti di dispositivi non root. Testato per funzionare su Moto X Play (Android 6.0.1)

• Scarica WLD dal link del Play Store sopra

• Manuale per l'uso di WLD qui

• Istruzioni per dispositivi non rooted qui . Ha tutti i dettagli ma per riassumere:

  • Abilita il debug USB sul dispositivo e adb

  • Scarica Wakelock Unlocker per Chrome sul tuo laptop (funziona anche su Chromium)

  • Abilitalo e il gioco è fatto!

  • La versione di Wakelock Detector Light non visualizza le statistiche da Unplugged

    2. Esiste un'altra alternativa su reddit che prevede l'esecuzione del comando di seguito in un ciclo, come menzionato qui

  potere dumpsys shell adb | grep -i partial_wake_lock

Nota: non sono riuscito a far funzionare il secondo metodo, accetterei con favore la soluzione di modifica nel farlo funzionare per ragazzi non esperti come me