Google ha rilasciato il 9 ottobre 2026 la Beta 7 di Android 17 QPR2, come indicano le note di rilascio per sviluppatori di Android. L’aggiornamento corregge due problemi principali: un consumo eccessivo di batteria in standby legato alla modalità Shhh e il fallimento immediato dei download HTTPS avviati dal DownloadManager di sistema. Tra i problemi noti compare la possibile nuova registrazione dello Sblocco con il Volto sul Pixel 11 Pro Fold.
Ne avevamo parlato con la Beta 6 del 24 settembre.
Le due correzioni principali della Beta 7
Secondo Google, la nuova build risolve questi problemi:
- consumo eccessivo della batteria negli stati di inattività, quando la modalità Shhh impedisce al dispositivo di entrare in sonno profondo (segnalazioni n. 560036427 e n. 569079944);
- download HTTPS che non andavano a buon fine subito se avviati tramite il DownloadManager di sistema (segnalazione n. 562833711).
Build, patch di sicurezza e problema noto
La Beta 7 porta il numero di build CP41.260831.016 e il livello di patch di sicurezza 2026-10-05. Google Play Services è alla versione 26.28.33. Le immagini per emulatore sono disponibili per x86 a 64 bit e ARM v8-A.
Google segnala un unico problema noto: chi usa un Pixel 11 Pro Fold potrebbe dover registrare di nuovo lo Sblocco con il Volto perché funzioni correttamente.
Le beta di QPR2 finora
Le note di rilascio elencano tutte le beta del ciclo. Le più recenti sono queste:
| Versione | Data di rilascio | Patch di sicurezza |
|---|---|---|
| Beta 5 | 15 settembre 2026 | 2026-08-05 |
| Beta 6 | 24 settembre 2026 | 2026-08-05 |
| Beta 6.1 | 29 settembre 2026 | 2026-08-05 |
| Beta 7 | 9 ottobre 2026 | 2026-10-05 |
Protezione contro le frodi sulla deviazione delle chiamate
Le note descrivono nuove limitazioni di sicurezza sull’inoltro programmatico delle chiamate. Il sistema analizza e limita i codici USSD di inoltro (ad esempio *21#) eseguiti con l’API TelephonyManager.sendUssdRequest().
- L’API non è più accessibile per questi codici con la sola autorizzazione CALL_PHONE. Le app standard che provano a eseguirli in background vengono bloccate e ricevono il callback
USSD_ERROR_NOT_ALLOWED. - Chi compone a mano un codice di trasferimento nel dialer di sistema vede una finestra di conferma a livello di sistema operativo prima dell’esecuzione.
- Le richieste USSD che non riguardano la deviazione delle chiamate, come i trasferimenti di denaro mobile e i controlli dell’account, non sono interessate.
Per gli sviluppatori, Google consiglia di gestire il nuovo errore. Se l’app deve configurare l’inoltro e non rientra in un ruolo esente, il flusso va spostato sull’intent ACTION_DIAL, che precompila il dialer e lascia all’utente la conferma manuale.
Auto-trasmissioni più efficienti
Sui dispositivi con Android 17 QPR2 o successivo, il sistema gestisce in modo diverso le auto-trasmissioni. Sono i broadcast, per esempio quelli inviati con sendBroadcast(), i cui destinatari girano tutti nello stesso processo che li ha inviati. Il sistema li restituisce al processo mittente, che li consegna ai propri ricevitori sul thread principale. Google spiega che così le app non possono restare attive in background inviandosi broadcast ripetutamente. La modifica vale per tutte le app, qualunque sia il loro targetSdkVersion.
- Inviare un’auto-trasmissione non aumenta l’importanza del processo e non impedisce che venga bloccato in cache.
- Se il processo è in cache e bloccato, le auto-trasmissioni attendono che venga sbloccato, per esempio quando l’utente torna all’app.
- Quelle non ancora consegnate restano nella memoria del processo e, se il sistema lo termina prima, vanno perse.
- Non cambia nulla per i broadcast con destinatario in un altro processo, per quelli inviati per conto di un’altra app (ad esempio tramite PendingIntent) e per quelli verso un diverso profilo utente.
Google invita a non usare le auto-trasmissioni come timer o meccanismo keep-alive. Per il lavoro in background indica WorkManager, oppure AlarmManager per le attività a un’ora precisa. Per la comunicazione dentro un processo suggerisce callback diretti o flussi Kotlin.
Cosa significa per chi testa le app
Google precisa che QPR2 non porta modifiche alle API che incidono sulle app. Include però una release minore dell’SDK, senza modifiche al comportamento pianificate, quindi il bisogno di test di compatibilità resta minimo. Le immagini delle beta servono a provare la propria app se si prevedono funzioni che potrebbero influire sull’esperienza utente. Le modifiche correnti all’SDK sono nel report sulle differenze tra le API.