Poiché 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 di qualità tecnica dei wakelock per migliorare il consumo della batteria. Questo trattamento verrà implementato gradualmente nelle app interessate nelle settimane successive. Le app che superano costantemente la soglia "Wakelock parziali eccessivi" 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 come i consigli.

Gli utenti potrebbero visualizzare un avviso nella scheda dello Store se la tua app supera la soglia relativa alle prestazioni scadenti. 

Questa iniziativa ha elevato l'efficienza della batteria a una 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 mantenuto dal sistema che offre chiari vantaggi per l'utente che non possono essere ulteriormente ottimizzati, come la riproduzione audio, l'accesso alla posizione o il trasferimento di dati avviato dall'utente. Puoi visualizzare la definizione completa dei wakelock eccessivi nella nostra documentazione di Android vitals.

Nell'ambito della nostra iniziativa continua per migliorare la durata della batteria nell'ecosistema Android, abbiamo analizzato migliaia di app e il modo in cui utilizzano i wakelock parziali. Sebbene i wakelock siano a volte 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 wakelock 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 loro comportamento in background.

Utilizzo di un servizio in primo piano rispetto ai wakelock parziali

Spesso abbiamo visto gli sviluppatori avere difficoltà a comprendere la differenza tra due concetti durante l'esecuzione in background: servizio in primo piano e wakelock parziali.

Un servizio in primo piano è un'API del ciclo di vita che segnala al sistema che un'app sta eseguendo un'attività percepibile dall'utente e non deve essere terminata per recuperare memoria, ma non impedisce automaticamente alla CPU di entrare in modalità di 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 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 comprendere bene quale strumento utilizzare per evitare di acquisire un wakelock in scenari in cui non è necessario.

Librerie di terze parti che acquisiscono wakelock

È normale che un'app scopra di essere contrassegnata per wakelock eccessivi mantenuti da un SDK di terze parti o da un'API di sistema che agisce per suo conto. Per identificare e risolvere questi wakelock, ti consigliamo di seguire questi passaggi:

• Controlla Android vitals: trova il nome esatto del wakelock problematico nella dashboard dei wakelock parziali eccessivi. Confronta questo nome con le indicazioni Identificare i wakelock creati da altre API per verificare se è stato creato da un'API di sistema nota o da una libreria Jetpack. In caso affermativo, potrebbe essere necessario ottimizzare l'utilizzo dell'API e fare riferimento alle indicazioni consigliate.
• Acquisisci una traccia di sistema: se il wakelock non può essere identificato facilmente, riproduci il problema del wakelock localmente utilizzando una traccia di sistema e ispezionalo con l'interfaccia utente di Perfetto. Puoi scoprire di più su come farlo nella sezione Eseguire il debug di altri tipi di wakelock eccessivi di questo post del blog.
• Valuta le alternative: se una libreria di terze parti inefficiente è responsabile e non può essere configurata per 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 dei wakelock

Di seguito è riportata un'analisi di alcuni dei casi d'uso specifici che abbiamo esaminato, insieme al percorso consigliato per ottimizzare l'implementazione dei 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 lunga esecuzione avviate dall'utente ed è esente dai calcoli dei wakelock eccessivi.

Sincronizzazioni in background una tantum o periodiche

Esempi di casi d'uso:

• Un'app esegue sincronizzazioni in background periodiche 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 attività una tantum o periodiche. 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 dei wakelock, potrebbe essere perché hai configurato in modo errato il worker in modo che non venga completato in determinati scenari. Valuta la possibilità di analizzare i motivi di interruzione del worker, in particolare se riscontri un'elevata 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 acquisiti e rilasciati i wakelock.
• Infine, consulta il nostro case study con WHOOP, in cui è stato possibile scoprire un problema con la configurazione dei worker e ridurre significativamente l'impatto dei 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 ascolta gli eventi hardware su un dispositivo esterno e le modifiche visibili all'utente nella notifica.
• L'utente dell'app del dispositivo complementare avvia un trasferimento di file tra il dispositivo mobile e il dispositivo Bluetooth.
• L'app del dispositivo complementare esegue occasionalmente aggiornamenti del firmware su un dispositivo esterno tramite Bluetooth.

Come ridurre i wakelock:

• Utilizza l'accoppiamento del dispositivo complementare per accoppiare i dispositivi Bluetooth ed evitare di acquisire un wakelock manuale durante l'accoppiamento Bluetooth. 
• Consulta le indicazioni Comunicare in background per capire come eseguire la comunicazione Bluetooth in background. 
• L'utilizzo di WorkManager è spesso sufficiente se non si verifica un impatto sull'utente a causa di una comunicazione ritardata. Se si ritiene necessario un wakelock manuale, mantienilo solo per la durata dell'attività Bluetooth o dell'elaborazione dei dati dell'attività.

Monitoraggio della posizione

Esempi di casi d'uso:

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

Come ridurre i wakelock:

• Consulta le nostre indicazioni per ottimizzare l'utilizzo della posizione. Valuta la possibilità di implementare timeout, sfruttare il raggruppamento delle richieste di posizione o utilizzare gli 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 posizione. 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, perché è ridondante. Memorizza invece gli eventi di posizione 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 di sicurezza che monitorano i sensori del dispositivo per rilevare rapidamente le modifiche in tempo reale, per fornire funzionalità come il rilevamento di arresti anomali 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 dell'interfaccia utente. 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 Connessione Salute per accedere al numero di passi storici e aggregati del dispositivo per acquisire i dati in modo efficiente dal punto di vista della batteria.
• Se registri un sensore con SensorManager, specifica un maxReportLatencyUs di almeno 30 secondi per sfruttare il raggruppamento dei sensori per 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 invierà 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 i dati dei sensori, sincronizza il recupero e l'elaborazione degli eventi. Utilizzando le letture dei sensori sul breve wakelock mantenuto dal sistema per gli aggiornamenti della posizione, non è necessario un wakelock per mantenere attiva la CPU. 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 sul lato server, utilizza FCM per ricevere informazioni sul client. Se è necessaria un'ulteriore elaborazione dei dati FCM, puoi scegliere di pianificare un worker accelerato. 
• Se gli eventi devono essere elaborati sul lato client tramite una connessione socket, non è necessario un wakelock per ascoltare le interruzioni degli eventi. Quando i pacchetti di dati arrivano alla radio Wi-Fi o cellulare, l'hardware radio attiva un'interruzione hardware sotto forma di wakelock del kernel. Puoi quindi scegliere di pianificare un worker o acquisire un wakelock per elaborare i dati.
• Ad esempio, se utilizzi ktor-network per ascoltare i pacchetti di dati su un socket di rete, devi acquisire un wakelock solo quando i pacchetti sono stati consegnati 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 i casi d'uso comuni come le sincronizzazioni in background, il monitoraggio della posizione, il monitoraggio dei sensori e la comunicazione di rete, gli sviluppatori possono ridurre l'utilizzo non necessario dei wakelock. Per continuare a imparare, leggi l'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 dei 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 di feedback sulla documentazione.