Blocco sveglia disattivato in foreground service con modalità Doze - nuove ottimizzazioni della batteria in Android M

Question

Si tratta di un comportamento apparentemente semi-documentato, se i commenti di Dianne Hackborn su un post G + costituiscono "documentati": https://plus.google.com/+AndroidDevelopers/posts/94jCkmG4jff ma i servizi in primo piano associati a un'icona di notifica dovrebbe essere permesso di mantenere un blocco di scia durante la modalità doze.

Sembra che questo non sia valido quando si dispone di un'attività principale oltre al servizio di primo piano.

devo creare un'implementazione minimale che lo dimostra: https://github.com/petrnalevka/dozetest/blob/master/src/com/urbandroid/doze/DozeService.java

Il problema può essere riprodotto su
Android M, MRA58K Nexus 5 e MRA58N Nexus 6

Il mio servizio in primo piano ha una notifica associato e Tengo un parziale scia di blocco. Sfortunatamente la modalità Doze prende il sopravvento e il mio scia è rotto. Sono stato in grado di prevenirlo solo con un opt-out dall'ottimizzazione della batteria o lasciando l'attività principale.

Credo che questo sia un bug in Android poiché non vi è alcun motivo per cui i servizi in primo piano dovrebbero mantenere il blocco della sveglia ma non se hanno un'attività in alto.

sto mettendo questo problema in modo da anche Ho già segnalato questo su Androdi issue tracker qui https://code.google.com/p/android/issues/detail?id=193802 al fine di trovare soluzioni alternative come questa è una caratteristica crutial al fine di non bisogno dei REQUEST_IGNORE_BATTERY_OPTIMIZATIONS che a quanto pare solo significare REQUEST_REMOVAL_FROM_PLAYSTORE_BY_GOOGLE al momento .

Ecco come sono stato in grado di riprodurre il problema utilizzando ADB grazie ai suggerimenti da + Dianne Hackborn:

Sembra che quando io continuo a un'attività in primo piano, pur avendo anche il servizio di primo piano in esecuzione la mia app è riconosciuto dal gestore potere come:

PARTIAL_WAKE_LOCK    'Doze lock' DISABLED (uid=10112, pid=24649, ws=null) 
ProC# 0: fore F/A/TS trm: 0 24649:com.urbandroid.doze/u0a112 (top-activity) 

Se premo a casa e lasciare l'attività mi trovo in stato di:

PARTIAL_WAKE_LOCK    'Doze lock' (uid=10112, pid=24649, ws=null) 
ProC# 4: prcp F/S/SF trm: 0 24649:com.urbandroid.doze/u0a112 (fg-service) 

Answer 1

Questo è un answe di Dianne Hackborn pubblicato sotto https://plus.google.com/+AndroidDevelopers/posts/94jCkmG4jff. Tuttavia, possiamo fare un brainstorming di soluzioni alternative, in quanto la separazione dei processi potrebbe non essere sempre semplice.

Dianne Hackborn: + Petr Nalevka Siamo spiacenti, questo sembra un bug nella piattaforma. Cercherò di ripararlo quando possibile.

Il tuo lavoro è nella giusta direzione, ma per favore non fare quel tipo di cose con lo stato di attivazione/disattivazione dello schermo. Bene, va bene spostarsi sul retro e farlo quando lo schermo si spegne ... tuttavia, è molto sbagliato forzare te stesso davanti quando lo schermo si accende, perché potrebbe essere acceso per altri motivi (per avviare la fotocamera, l'interazione vocale, ecc.). In realtà è probabilmente qualcosa su cui la piattaforma dovrebbe essere meglio proteggersi.

Quello che vorrei suggerire è ascoltare la modalità doze per iniziare, e solo mettere la tua attività sul retro in quel caso. Puoi farlo ascoltando la trasmissione http://developer.android.com/reference/android/os/PowerManager.html#ACTION_DEVICE_IDLE_MODE_CHANGED e inviandoti indietro quando vedi che il dispositivo inattivo è vero. Ti suggerirei di non preoccuparti di cercare di riportarti in primo piano - nel caso in cui l'utente in realtà non stia usando il dispositivo da molto tempo e ciò accade, tornando indietro e trovandosi in casa non dovrebbe essere una sorpresa

EDIT (di Dianne Hackborn): In realtà, un'altra soluzione: il servizio in primo piano viene eseguito in un processo diverso rispetto all'attività. Da quello che vedo, funzionerà bene. Sarei interessante nel vedere se si ottiene il comportamento desiderato lì.

Anche questa è la nostra pratica consigliata per questa situazione: se si dispone di un servizio in foreground con esecuzione prolungata, dovrebbe essere in un processo separato dall'attività, quindi non impone tutta la memoria associata al attività da tenere in giro. (Questo è anche il motivo per cui questo errore è stato risolto, tutte le nostre app utilizzano questo modello.)