Consapevole del fatto che il consumo eccessivo della batteria è una delle principali preoccupazioni degli utenti Android, Google ha adottato misure significative per aiutare gli sviluppatori a creare app più efficienti dal punto di vista energetico. Il 1° marzo 2026, il Google Play Store ha iniziato a implementare i trattamenti tecnici di qualità del wakelock per migliorare il consumo eccessivo della batteria. Questo trattamento verrà implementato gradualmente nelle app interessate nelle settimane successive. Le app che superano costantemente la soglia "Partial Wake Lock eccessivo" in Android vitals potrebbero subire un impatto tangibile sulla loro presenza nello Store, inclusi avvisi nella scheda dello Store ed esclusione dalle piattaforme di scoperta, ad esempio i consigli.

Se la tua app supera la soglia relativa alle prestazioni scadenti, gli utenti potrebbero visualizzare un avviso nella tua scheda dello Store. 

Questa iniziativa ha elevato l'efficienza della batteria a metrica vitale fondamentale, insieme alle metriche di stabilità come arresti anomali e ANR. La "soglia relativa alle prestazioni scadenti" è definita come il mantenimento di un wakelock parziale non esente per almeno due ore in media mentre lo schermo è spento in più del 5% delle sessioni utente negli ultimi 28 giorni. Un wakelock è esente se è un wakelock di sistema che offre chiari vantaggi per l'utente che non possono essere ulteriormente ottimizzati, ad esempio la riproduzione audio, l'accesso alla posizione o il trasferimento di dati avviato dall'utente. Puoi visualizzare la definizione completa di wakelock eccessivi nella nostra documentazione di Android vitals.

Nell'ambito della nostra iniziativa in corso per migliorare la durata della batteria nell'ecosistema Android, abbiamo analizzato migliaia di app e il modo in cui utilizzano i wake lock parziali. Sebbene a volte i wake lock siano necessari, spesso vediamo app che li mantengono in modo inefficiente o non necessario, quando esistono soluzioni più efficienti. Questo blog esaminerà gli scenari più comuni in cui si verificano wake lock eccessivi e i nostri consigli per ottimizzarli.  Abbiamo già riscontrato un successo misurabile da parte di partner come WHOOP, che hanno sfruttato questi consigli per ottimizzare il comportamento in background.

Utilizzo di un servizio in primo piano anziché di wake lock parziali

Spesso gli sviluppatori hanno difficoltà a comprendere la differenza tra due concetti durante l'esecuzione in background: servizio in primo piano e wake lock parziale.

Un servizio in primo piano è un'API del ciclo di vita che segnala al sistema che un'app sta eseguendo un lavoro percepibile dall'utente e non deve essere chiusa per recuperare memoria, ma non impedisce automaticamente alla CPU di entrare in modalità sospensione quando lo schermo si spegne. Al contrario, un wakelock parziale è un meccanismo progettato specificamente per mantenere la CPU in esecuzione anche quando lo schermo è spento. 

Sebbene un servizio in primo piano sia spesso necessario per continuare un'azione dell'utente, l'acquisizione manuale di un wakelock parziale è necessaria solo in combinazione con un servizio in primo piano per la durata dell'attività della CPU. Inoltre, non è necessario utilizzare un wakelock se utilizzi già un'API che mantiene attivo il dispositivo. 

Consulta il diagramma di flusso in Scegli l'API giusta per mantenere attivo il dispositivo per assicurarti di avere una buona comprensione di quale strumento utilizzare per evitare di acquisire un wake lock in scenari in cui non è necessario.

Librerie di terze parti che acquisiscono wake lock

È comune che un'app scopra di essere segnalata per wake lock eccessivi detenuti da un SDK di terze parti o da un'API di sistema che agisce per suo conto. Per identificare e risolvere questi wake lock, ti consigliamo di procedere nel seguente modo:

• Controlla Android vitals:trova il nome esatto del wakelock problematico nella dashboard dei wakelock parziali eccessivi. Confronta questo nome con le indicazioni riportate in Identificare i wakelock creati da altre API per verificare se è stato creato da un'API di sistema o da una libreria Jetpack note. In questo caso, potrebbe essere necessario ottimizzare l'utilizzo dell'API. Puoi consultare le indicazioni consigliate.
• Acquisire una traccia di sistema:se il wakelock non può essere identificato facilmente, riproduci il problema del wakelock localmente utilizzando una traccia di sistema e ispezionala con la UI di Perfetto. Per scoprire di più su come procedere, consulta la sezione Debug di altri tipi di wake lock eccessivi di questo post del blog.
• Valuta alternative:se la causa è una libreria di terze parti inefficiente e non può essere configurata in modo da rispettare la durata della batteria, valuta la possibilità di comunicare il problema ai proprietari dell'SDK, trovare un SDK alternativo o creare la funzionalità internamente.

Scenari comuni di wakelock

Di seguito è riportata un'analisi dettagliata di alcuni casi d'uso specifici che abbiamo esaminato, insieme al percorso consigliato per ottimizzare l'implementazione del wakelock.

Caricamento o download avviato dall'utente

Esempi di casi d'uso: 

• App di streaming video in cui l'utente attiva il download di un file di grandi dimensioni per l'accesso offline.
• App di backup dei contenuti multimediali in cui l'utente attiva il caricamento delle foto recenti tramite una richiesta di notifica.

Come ridurre i wakelock: 

• Non acquisire un wakelock manuale. Utilizza invece l'API User-Initiated Data Transfer (UIDT). Questo è il percorso designato per le attività di trasferimento di dati a esecuzione prolungata avviate dall'utente ed è esente dai calcoli eccessivi di wakelock.

Sincronizzazioni in background una tantum o periodiche

Esempi di casi d'uso: 

• Un'app esegue sincronizzazioni periodiche in background per recuperare i dati per l'accesso offline. 
• App contapassi che recuperano periodicamente il numero di passi.

Come ridurre i wakelock: 

• Non acquisire un wakelock manuale. Utilizza WorkManager configurato per il lavoro una tantum o periodico. WorkManager rispetta l'integrità del sistema raggruppando le attività e ha un intervallo periodico minimo (15 minuti), che in genere è sufficiente per gli aggiornamenti in background. 
• Se identifichi wakelock creati da WorkManager o JobScheduler con un utilizzo elevato di wakelock, il problema potrebbe essere dovuto a una configurazione errata del worker che non viene completato in determinati scenari. Valuta la possibilità di analizzare i motivi di interruzione del worker, in particolare se riscontri un'alta frequenza di STOP_REASON_TIMEOUT. 

workManager.getWorkInfoByIdFlow(syncWorker.id)
  .collect { workInfo ->
      if (workInfo != null) {
        val stopReason = workInfo.stopReason
        logStopReason(syncWorker.id, stopReason)
      }
  }

• Oltre a registrare i motivi di interruzione del worker, consulta la nostra documentazione sul debug dei worker. Inoltre, valuta la possibilità di raccogliere e analizzare le tracce di sistema  per capire quando vengono acquisite e rilasciate le sveglie.
• Infine, consulta il nostro case study con WHOOP, in cui l'azienda è riuscita a scoprire un problema di configurazione dei propri worker e a ridurre in modo significativo l'impatto del wakelock.

Comunicazione Bluetooth

Esempi di casi d'uso: 

• L'app del dispositivo complementare chiede all'utente di accoppiare il dispositivo esterno Bluetooth.
• L'app del dispositivo complementare è in ascolto degli eventi hardware su un dispositivo esterno e delle modifiche visibili all'utente nella notifica.
• L'utente dell'app del dispositivo complementare avvia un trasferimento di file tra il dispositivo mobile e quello Bluetooth.
• L'app del dispositivo complementare esegue aggiornamenti firmware occasionali su un dispositivo esterno tramite Bluetooth.

Come ridurre i wakelock: 

• Utilizza l'accoppiamento di dispositivi complementari per accoppiare i dispositivi Bluetooth ed evitare di acquisire un wakelock manuale durante l'accoppiamento Bluetooth. 
• Consulta le indicazioni su come  comunicare in background per capire come eseguire la comunicazione Bluetooth in background. 
• L'utilizzo di WorkManager è spesso sufficiente se non vi è alcun impatto sugli utenti in caso di comunicazione ritardata. Se un wakelock manuale è ritenuto necessario, mantienilo solo per la durata dell'attività Bluetooth o del trattamento dei dati delle attività.

Monitoraggio della posizione

Esempi di casi d'uso: 

• App per il fitness che memorizzano nella cache i dati sulla posizione per il caricamento successivo, ad esempio la tracciatura dei percorsi di corsa
• App di consegna di cibo che recuperano i dati sulla posizione con una frequenza elevata per aggiornare lo stato di avanzamento della consegna in una notifica o nell'interfaccia utente di un widget.

Come ridurre i wakelock: 

• Consulta le nostre linee guida per ottimizzare l'utilizzo della posizione. Valuta la possibilità di implementare timeout, utilizzare il batching delle richieste di localizzazione o utilizzare aggiornamenti passivi della posizione per garantire l'efficienza della batteria.
• Quando richiedi aggiornamenti della posizione utilizzando le API FusedLocationProvider o LocationManager, il sistema attiva automaticamente la riattivazione del dispositivo durante il callback dell'evento di localizzazione. Questo wakelock breve e gestito dal sistema è esente dai calcoli dei wakelock parziali eccessivi.
• Evita di acquisire un wakelock continuo separato per la memorizzazione nella cache dei dati sulla posizione, in quanto è ridondante. Conserva invece gli eventi di localizzazione in memoria o nello spazio di archiviazione locale e utilizza WorkManager per elaborarli a intervalli periodici.

override fun onCreate(savedInstanceState: Bundle?) {
    locationCallback = object : LocationCallback() {
        override fun onLocationResult(locationResult: LocationResult?) {
            locationResult ?: return
            // System wakes up CPU for short duration
            for (location in locationResult.locations){
                // Store data in memory to process at another time
            }
        }
    }
}

Monitoraggio dei sensori ad alta frequenza

Esempi di casi d'uso: 

• App contapassi che raccolgono passivamente i passi o la distanza percorsa. 
• App per la sicurezza che monitorano i sensori del dispositivo per rilevare cambiamenti rapidi in tempo reale, per fornire funzionalità come il rilevamento di incidenti o cadute.

Come ridurre i wakelock: 

• Se utilizzi SensorManager, riduci l'utilizzo a intervalli periodici e solo quando l'utente ha concesso esplicitamente l'accesso tramite un'interazione con la UI. Il monitoraggio dei sensori ad alta frequenza può scaricare notevolmente la batteria a causa del numero di riattivazioni e dell'elaborazione della CPU.
• Se monitori il numero di passi o la distanza percorsa, anziché utilizzare SensorManager, sfrutta l'API Recording o valuta la possibilità di utilizzare Health Connect per accedere al numero di passi storici e aggregati del dispositivo e acquisire i dati in modo efficiente dal punto di vista del consumo della batteria.
• Se registri un sensore con SensorManager, specifica un maxReportLatencyUs di 30 secondi o più per sfruttare il batching dei sensori e ridurre al minimo la frequenza delle interruzioni della CPU. Quando il dispositivo viene riattivato da un altro trigger, ad esempio un'interazione utente, il recupero della posizione o un job programmato, il sistema invia immediatamente i dati dei sensori memorizzati nella cache.

val accelerometer = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)

sensorManager.registerListener(this,
                 accelerometer,
                 samplingPeriodUs, // How often to sample data
                 maxReportLatencyUs // Key for sensor batching 
              )

• Se la tua app richiede sia i dati sulla posizione sia quelli dei sensori, sincronizza il recupero e l'elaborazione degli eventi. Utilizzando le letture dei sensori nel breve wakelock che il sistema mantiene per gli aggiornamenti della posizione, eviti di dover utilizzare un wakelock per mantenere la CPU attiva. Utilizza un worker o un wakelock di breve durata per gestire il caricamento e l'elaborazione di questi dati combinati.

Messaggistica remota

Esempi di casi d'uso: 

• App complementari di monitoraggio video o audio che devono monitorare gli eventi che si verificano su un dispositivo esterno connesso tramite una rete locale.
• App di messaggistica che mantengono una connessione socket di rete con la variante desktop.

Come ridurre i wakelock: 

• Se gli eventi di rete possono essere elaborati lato server, utilizza FCM per ricevere informazioni sul client. Puoi scegliere di pianificare un worker rapido se è necessario un ulteriore trattamento dei dati FCM. 
• Se gli eventi devono essere elaborati lato client tramite una connessione socket, non è necessario un wakelock per rimanere in ascolto delle interruzioni degli eventi. Quando i pacchetti di dati arrivano alla radio Wi-Fi o cellulare, l'hardware della radio attiva un interrupt hardware sotto forma di wakelock del kernel.Puoi quindi scegliere di programmare un worker o acquisire un wakelock per elaborare i dati.
• Ad esempio, se utilizzi ktor-network per rimanere in ascolto dei pacchetti di dati su un socket di rete, devi acquisire un wakelock solo quando i pacchetti sono stati inviati al client e devono essere elaborati.

val readChannel = socket.openReadChannel()
while (!readChannel.isClosedForRead) {
    // CPU can safely sleep here while waiting for the next packet
    val packet = readChannel.readRemaining(1024) 
    if (!packet.isEmpty) {
         // Data Arrived: The system woke the CPU and we should keep it awake via manual wake lock (urgent) or scheduling a worker (non-urgent)
         performWorkWithWakeLock { 
              val data = packet.readBytes()
              // Additional logic to process data packets
         }
    }
}

Riepilogo

Adottando queste soluzioni consigliate per casi d'uso comuni come sincronizzazioni in background, monitoraggio della posizione, monitoraggio dei sensori e comunicazione di rete, gli sviluppatori possono lavorare per ridurre l'utilizzo non necessario di wakelock. Per continuare a imparare, leggi il nostro altro blog post tecnico o guarda il nostro video tecnico su come scoprire ed eseguire il debug dei wakelock: Ottimizzare la batteria dell'app utilizzando la metrica wakelock di Android vitals. Consulta anche la nostra documentazione aggiornata sui wakelock. Per aiutarci a continuare a migliorare le nostre risorse tecniche, condividi eventuali feedback aggiuntivi sulle nostre indicazioni nel nostro sondaggio sul feedback della documentazione.