Modifiche al comportamento: tutte le app

La piattaforma Android 17 include modifiche al comportamento che potrebbero influire sulla tua app. Le seguenti modifiche al comportamento si applicano a tutte le app quando vengono eseguite su Android 17, indipendentemente da targetSdkVersion. Devi testare la tua app e poi modificarla in base alle necessità per supportare queste modifiche, ove applicabile.

Assicurati di esaminare anche l'elenco delle modifiche al comportamento che interessano solo le app che hanno come target Android 17.

Funzionalità di base

Android 17 (livello API 37) include le seguenti modifiche che modificano o espandono varie funzionalità di base del sistema Android.

Limiti di memoria delle app

Android 17 introduce limiti di memoria per le app in base alla RAM totale del dispositivo per creare un ambiente più stabile e deterministico per le tue app e gli utenti Android. Questi limiti si concentrano sulle perdite di memoria e su altre anomalie prima che causino un'instabilità a livello di sistema che comporta interruzioni della UI, un consumo maggiore della batteria e l'arresto delle app. Anche se prevediamo un impatto minimo sulla stragrande maggioranza delle sessioni dell'app, ti consigliamo di seguire le best practice per la memoria riportate di seguito, tra cui la definizione di una base di riferimento per la memoria.

Puoi determinare se la sessione della tua app è stata interessata chiamando getDescription in ApplicationExitInfo; se la tua app è stata interessata, il motivo dell'uscita sarà REASON_OTHER e la descrizione conterrà la stringa "MemoryLimiter:AnonSwap" insieme ad altre informazioni. Puoi anche utilizzare la profilazione basata su trigger con TRIGGER_TYPE_ANOMALY per ottenere i dump dell'heap raccolti quando viene raggiunto il limite di memoria.

La documentazione Gestisci la memoria dell'app fornisce informazioni per aiutarti a diagnosticare i problemi di memoria dell'app e ottimizzare il consumo di risorse.

Testa il comportamento della tua app in base ai vincoli di memoria

Puoi utilizzare Android Debug Bridge (adb) per regolare o disattivare i limiti di memoria su qualsiasi dispositivo che li impone. Il comando shell am fornisce tre sottocomandi per regolare i limiti di memoria. Questi comandi non hanno alcun effetto su un dispositivo che non impone limiti di memoria.

  • am memory-limiter ignore <uid>|none|all
  • am memory-limiter manual <pid> <limit>|max|none
  • am memory-limiter status
ignore

Indica al limitatore di memoria di ignorare alcuni o tutti i processi. Il passaggio di un UID (ID utente Android) indica al limitatore di memoria di ignorare l'applicazione su tutti i processi associati a quell'UID. Puoi anche passare all (ignora tutte le app) o none (non ignorare nessuna app). Il passaggio di none sostituisce eventuali chiamate precedenti a am memory-limiter ignore.

Se indichi al limitatore di memoria di ignorare un UID, puoi comunque applicare un limite di memoria manuale a un processo all'interno dell'app chiamando am memory-limiter manual.

manual

Indica al sistema di imporre un vincolo di memoria al processo con il PID (ID di processo) specificato. Il vincolo di memoria è specificato come un numero intero di MB. Ad esempio, se passi 30, specifichi che il processo è limitato a 30 MB di memoria. Se passi max, tutti i limiti di memoria per quel processo vengono rimossi. Se passi none, vengono rimossi tutti i limiti manuali impostati sul processo e viene ripristinato il limite predefinito del sistema (se presente).

status

Segnala lo stato attuale del limitatore di memoria. Lo stato include i limiti di memoria imposti ai processi visibili e non visibili.

Privacy

Android 17 include le seguenti modifiche per migliorare la privacy degli utenti.

Protezione OTP via SMS

A partire da Android 17, Android estende la protezione per i messaggi SMS contenenti password monouso (OTP).

Nelle versioni precedenti di Android, questa protezione era incentrata principalmente sul formato SMS Retriever. La consegna dei messaggi contenenti un hash di recupero degli SMS è stata ritardata di tre ore per la maggior parte delle app. Tuttavia, alcune app (come il gestore di SMS predefinito) erano esenti dal ritardo, così come l'app proprietaria dell'hash.

A partire da Android 17, la protezione viene applicata anche ai messaggi in formato WebOTP. Se un'app dispone dell'autorizzazione per leggere gli SMS, ma non è il destinatario previsto di un messaggio WebOTP (come stabilito dalla verifica del dominio), il messaggio non è accessibile all'app fino a tre ore dopo la ricezione. Questa modifica ha lo scopo di migliorare la sicurezza degli utenti garantendo che solo le app associate al dominio menzionato nel messaggio possano leggere in modo programmatico il codice di verifica.

Durante questo ritardo di tre ore, la trasmissione SMS_RECEIVED_ACTION viene trattenuta e le query del database del fornitore di SMS vengono filtrate. Il messaggio SMS è disponibile per queste app dopo il ritardo. Questa modifica si applica a tutte le app, indipendentemente dal livello API target.

Alcune app, come l'app di assistenza per gli SMS predefinita, le app complementari per i dispositivi connessi e così via, sono esenti da questo ritardo. Tutte le app che si basano sulla lettura dei messaggi SMS per l'estrazione delle OTP devono passare all'utilizzo delle API SMS Retriever o SMS User Consent per garantire la continuità della funzionalità.

Sicurezza

Android 17 include i seguenti miglioramenti alla sicurezza dei dispositivi e delle app.

Piano di ritiro di usesClearTraffic

In una release futura, prevediamo di ritirare l'elemento usesCleartextTraffic. Le app che devono stabilire connessioni non criptate (HTTP) devono eseguire la migrazione all'utilizzo di un file di configurazione della sicurezza di rete, che consente di specificare i domini con cui l'app deve stabilire connessioni in chiaro.

Tieni presente che i file di configurazione della sicurezza di rete sono supportati solo sui livelli API 24 e versioni successive. Se la tua app ha un livello API minimo inferiore a 24, devi eseguire entrambe le seguenti operazioni:

  • Imposta l'attributo usesCleartextTraffic su true
  • Utilizza un file di configurazione di rete

Se il livello API minimo della tua app è 24 o superiore, puoi utilizzare un file di configurazione di rete e non è necessario impostare usesCleartextTraffic.

Limita le concessioni di URI implicite

Attualmente, se un'app avvia un intent con un URI che ha l'azione ACTION_SEND, ACTION_SEND_MULTIPLE o ACTION_IMAGE_CAPTURE, il sistema concede automaticamente le autorizzazioni URI di lettura e scrittura all'app di destinazione. A partire da Android 18, il sistema non concederà più automaticamente queste autorizzazioni. Per questo motivo, consigliamo alle app di concedere esplicitamente le autorizzazioni URI pertinenti anziché affidarsi al sistema per la concessione.

Per rilevare l'utilizzo di questi intent nella tua app, utilizza StrictMode con detectImplicitUriPermissionGrant() per attivare una violazione:

Kotlin

val policy = StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build()
StrictMode.setVmPolicy(policy)

Java

StrictMode.VmPolicy policy = new StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build();
StrictMode.setVmPolicy(policy);

In alternativa, puoi monitorare le eccezioni registrate contenenti il messaggio Please set the grant explicitly in the app che viene visualizzato quando il sistema imposta implicitamente la concessione. Puoi monitorare questi log utilizzando il seguente comando adb:

adb logcat | grep "Please set the grant explicitly in the app"

Per concedere esplicitamente le autorizzazioni necessarie, aggiungi il flag FLAG_GRANT_READ_URI_PERMISSION agli intent ACTION_SEND e ACTION_SEND_MULTIPLE:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

Includi i flag FLAG_GRANT_READ_URI_PERMISSION e FLAG_GRANT_WRITE_URI_PERMISSION per gli intent ACTION_IMAGE_CAPTURE:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

Limiti del keystore per app

Le app devono evitare di creare un numero eccessivo di chiavi in Android Keystore, perché si tratta di una risorsa condivisa per tutte le app sul dispositivo. A partire da Android 17, il sistema applica un limite al numero di chiavi che un'app può possedere. Il limite è di 50.000 chiavi per le app non di sistema che hanno come target Android 17 (livello API 37) o versioni successive e di 200.000 chiavi per tutte le altre app. Le app di sistema hanno un limite di 200.000 chiavi, indipendentemente dal livello API target.

Se un'app tenta di creare chiavi oltre il limite, la creazione non va a buon fine e restituisce un errore KeyStoreException. La stringa del messaggio dell'eccezione contiene informazioni sul limite della chiave. Se l'app chiama getNumericErrorCode() sull'eccezione, il valore restituito dipende dal livello API scelto come target dall'app:

  • App che hanno come target Android 17 (livello API 37) o versioni successive: getNumericErrorCode() restituisce il nuovo valore ERROR_TOO_MANY_KEYS.
  • Tutte le altre app: getNumericErrorCode() restituisce ERROR_INCORRECT_USAGE.

Blocca il traffico di loopback tra profili

A partire da Android 17, il traffico di loopback tra profili non è più consentito per impostazione predefinita. Il traffico di loopback all'interno dello stesso profilo non è interessato. Questa modifica si applica a tutte le app eseguite su Android 17 o versioni successive, indipendentemente dal livello API scelto come target dall'app.

Esperienza utente e UI di sistema

Android 17 include le seguenti modifiche, pensate per creare un'esperienza utente più coerente e intuitiva.

Ripristino della visibilità predefinita dell'IME dopo la rotazione

A partire da Android 17, quando la configurazione del dispositivo cambia (ad esempio tramite rotazione) e questa non viene gestita dall'app stessa, la visibilità dell'IME precedente non viene ripristinata.

Se la tua app subisce una modifica alla configurazione che non gestisce e l'app richiede che la tastiera sia visibile dopo la modifica, devi richiederlo esplicitamente. Puoi effettuare questa richiesta in uno dei seguenti modi:

  • Imposta l'attributo android:windowSoftInputMode su stateAlwaysVisible.
  • Richiedi la tastiera su schermo in modo programmatico nel metodo onCreate() della tua attività o aggiungi il metodo onConfigurationChanged().

Azione umana

Android 17 include le seguenti modifiche che influiscono sul modo in cui le app interagiscono con i dispositivi di input umani, come tastiere e touchpad.

I touchpad forniscono eventi relativi per impostazione predefinita durante l'acquisizione del puntatore

A partire da Android 17, se un'app richiede l'acquisizione del puntatore utilizzando View.requestPointerCapture() e l'utente utilizza un touchpad, il sistema riconosce i gesti di movimento e scorrimento del puntatore dai tocchi dell'utente e li segnala all'app nello stesso modo dei movimenti del puntatore e della rotellina di scorrimento da un mouse acquisito. Nella maggior parte dei casi, in questo modo le app che supportano i mouse acquisiti non devono aggiungere una logica di gestione speciale per i touchpad. Per maggiori dettagli, consulta la documentazione relativa a View.POINTER_CAPTURE_MODE_RELATIVE.

In precedenza, il sistema non tentava di riconoscere i gesti dal touchpad, ma forniva all'app le posizioni assolute e non elaborate delle dita in un formato simile ai tocchi sul touchscreen. Se un'app richiede ancora questi dati assoluti, deve chiamare il nuovo metodo View.requestPointerCapture(int) con View.POINTER_CAPTURE_MODE_ABSOLUTE.

Media

Android 17 include le seguenti modifiche al comportamento dei contenuti multimediali.

Rafforzamento dell'audio in background

A partire da Android 17, il framework audio applica limitazioni alle interazioni audio in background, tra cui la riproduzione audio, le richieste di audio focus e le API di modifica del volume, per garantire che queste modifiche vengano avviate intenzionalmente dall'utente.

Se l'app tenta di chiamare le API audio mentre non si trova in un ciclo di vita valido, le API di riproduzione audio e di modifica del volume non vanno a buon fine senza generare un'eccezione o fornire un messaggio di errore. L'API Audio Focus non va a buon fine con il codice di risultato AUDIOFOCUS_REQUEST_FAILED.

Per ulteriori informazioni, incluse le strategie di mitigazione, consulta Rafforzamento dell'audio in background.

Connettività

Android 17 include le seguenti modifiche per migliorare la connettività dei dispositivi.

Riaccoppiamento autonomo per le perdite di connessione Bluetooth

Android 17 introduce l'accoppiamento autonomo, un miglioramento a livello di sistema progettato per risolvere automaticamente la perdita di accoppiamento Bluetooth.

In precedenza, se un accoppiamento veniva perso, gli utenti dovevano andare manualmente alle Impostazioni per disaccoppiare e poi riaccoppiare la periferica. Questa funzionalità si basa sul miglioramento della sicurezza di Android 16, consentendo al sistema di ristabilire gli accoppiamenti in background senza richiedere agli utenti di andare manualmente alle Impostazioni per disaccoppiare e riaccoppiare le periferiche.

Sebbene la maggior parte delle app non richieda modifiche al codice, gli sviluppatori devono essere consapevoli delle seguenti modifiche al comportamento nello stack Bluetooth:

  • Nuovo contesto di accoppiamento:ACTION_PAIRING_REQUEST ora include l'extra EXTRA_PAIRING_CONTEXT, che consente alle app di distinguere tra una richiesta di accoppiamento standard e un tentativo di riaccoppiamento autonomo avviato dal sistema.
  • Aggiornamenti condizionali delle chiavi:i token di sicurezza esistenti verranno sostituiti solo se il nuovo accoppiamento va a buon fine e la nuova connessione soddisfa o supera il livello di sicurezza dell'accoppiamento precedente.
  • Tempistica dell'intent modificata:l'intent ACTION_KEY_MISSING ora viene trasmesso solo se il tentativo di nuovo accoppiamento autonomo non va a buon fine. In questo modo, si riduce la gestione non necessaria degli errori nell'app se il sistema recupera correttamente l'accoppiamento in background.
  • Notifica all'utente:il sistema gestisce il nuovo accoppiamento tramite nuove notifiche e finestre di dialogo dell'interfaccia utente. Agli utenti verrà chiesto di confermare il tentativo di riaccoppiamento per assicurarsi che siano consapevoli della riconnessione.

I produttori di periferiche e gli sviluppatori di app complementari devono verificare che l'hardware e l'app gestiscano correttamente le transizioni di accoppiamento. Per testare questo comportamento, simula una perdita di associazione remota utilizzando uno dei seguenti metodi:

  • Rimuovi manualmente le informazioni di accoppiamento dal dispositivo periferico
  • Disaccoppia manualmente il dispositivo in: Impostazioni > Dispositivi connessi