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 dal 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 per le app

Android 17 introduce limiti di memoria delle app basati sulla RAM totale del dispositivo per creare un ambiente più stabile e deterministico per le tue applicazioni e gli utenti Android. In Android 17, i limiti sono impostati in modo conservativo per stabilire le baseline di sistema, prendendo di mira perdite di memoria estreme e altri valori anomali prima che causino instabilità a livello di sistema, con conseguenti scatti dell'interfaccia utente, consumo eccessivo della batteria e chiusura delle app. Sebbene prevediamo un impatto minimo sulla stragrande maggioranza delle sessioni delle app, consigliamo le seguenti best practice per la memoria, inclusa la definizione di una baseline 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 di 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 dump dell'heap raccolti quando viene raggiunto il limite di memoria.

Per aiutarti a trovare le perdite di memoria, Android Studio Panda aggiunge l'integrazione di LeakCanary direttamente nel Profiler di Android Studio come attività dedicata, contestualizzata all'interno dell'IDE e completamente integrata con il codice sorgente.

Privacy

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

Protezione OTP via SMS

A partire da Android 17, Android sta ampliando la protezione per i messaggi SMS contenenti password usa e getta (OTP).

Nelle versioni precedenti di Android, questa protezione era incentrata principalmente sul formato SMS Retriever. La consegna dei messaggi contenenti un hash SMS Retriever è stata ritardata per la maggior parte delle app di tre ore. Tuttavia, alcune app (come il gestore 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 ha l'autorizzazione a leggere i messaggi SMS, ma non è il destinatario previsto di un messaggio WebOTP (come determinato 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 a livello di programmazione il codice di verifica.

Durante questo ritardo di tre ore, la trasmissione SMS_RECEIVED_ACTION viene sospesa 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 assistente SMS predefinita, le app companion per dispositivi connessi e così via, sono esenti da questo ritardo. Tutte le app che si basano sulla lettura dei messaggi SMS per l'estrazione di 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 di app e dispositivi.

Piano di ritiro di usesClearTraffic

In una versione futura, prevediamo di ritirare l'elemento usesCleartextTraffic. Le app che devono effettuare connessioni non criptate (HTTP) devono eseguire la migrazione all'utilizzo di un file di configurazione della sicurezza di rete, che consente di specificare a quali domini la tua app deve effettuare connessioni in testo non criptato.

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

• Imposta l'attributo usesCleartextTraffic su true
• Utilizzare 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 devi impostare usesCleartextTraffic.

Limita le concessioni implicite di URI

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é fare affidamento sul sistema per concederle.

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

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

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 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:

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

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:

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

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

Limiti del keystore per app

Apps should avoid creating excessive numbers of keys in Android Keystore, because it is a shared resource for all apps on the device. Beginning with Android 17, the system enforces a limit on the number of keys an app can own. The limit is 50,000 keys for non-system apps targeting Android 17 (API level 37) or higher, and 200,000 keys for all other apps. System apps have a limit of 200,000 keys, regardless of which API level they target.

If an app attempts to create keys beyond the limit, the creation fails with a KeyStoreException. The exception's message string contains information about the key limit. If the app calls getNumericErrorCode() on the exception, the return value depends on what API level the app targets:

• Apps targeting Android 17 (API level 37) or higher: getNumericErrorCode() returns the new ERROR_TOO_MANY_KEYS value.
• All other apps: getNumericErrorCode() returns ERROR_INCORRECT_USAGE.

Bloccare 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 in esecuzione su Android 17 o versioni successive, indipendentemente dal livello API di destinazione dell'app.

Esperienza utente e UI di sistema

Android 17 include le seguenti modifiche volte a 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 la rotazione) e questo non viene gestito dall'app stessa, la visibilità della tastiera virtuale precedente non viene ripristinata.

Se la tua app subisce una modifica della configurazione che non gestisce e ha bisogno 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 a livello di programmazione nel metodo onCreate() dell'attività o aggiungi il metodo onConfigurationChanged().

Input umano

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

Beginning with Android 17, if an app requests pointer capture using View.requestPointerCapture() and the user uses a touchpad, the system recognizes pointer movement and scrolling gestures from the user's touches and reports them to the app in the same way as pointer and scroll wheel movements from a captured mouse. In most cases, this removes the need for apps that support captured mice to add special handling logic for touchpads. For more details, see the documentation for View.POINTER_CAPTURE_MODE_RELATIVE.

Previously, the system did not attempt to recognize gestures from the touchpad, and instead delivered the raw, absolute finger locations to the app in a similar format to touchscreen touches. If an app still requires this absolute data, it should call the new View.requestPointerCapture(int) method with View.POINTER_CAPTURE_MODE_ABSOLUTE instead.

Media

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

Protezione dell'audio in background

Beginning with Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user.

If the app tries to call audio APIs while the app is not in a valid lifecycle, the audio playback and volume change APIs fail silently without throwing an exception or providing a failure message. The audio focus API fails with the result code AUDIOFOCUS_REQUEST_FAILED.

For more information, including mitigation strategies, see Background audio hardening.

Connettività

Android 17 include le seguenti modifiche per migliorare la connettività del dispositivo.

Riaccoppiamento autonomo per le perdite di associazione Bluetooth

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

In precedenza, se un'associazione veniva persa, gli utenti dovevano andare manualmente in Impostazioni per annullare l'accoppiamento e poi accoppiare di nuovo la periferica. Questa funzionalità si basa sul miglioramento della sicurezza di Android 16, consentendo al sistema di ristabilire le associazioni in background senza che gli utenti debbano andare manualmente in Impostazioni per annullare l'accoppiamento e accoppiare di nuovo le periferiche.

Sebbene la maggior parte delle app non richieda modifiche al codice, gli sviluppatori devono essere a conoscenza delle seguenti modifiche al comportamento dello 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 accoppiamento automatico avviato dal sistema.
• Aggiornamenti delle chiavi condizionali: le chiavi di sicurezza esistenti verranno sostituite solo se l'accoppiamento automatico va a buon fine e la nuova connessione soddisfa o supera il livello di sicurezza dell'associazione precedente.
• Tempistica degli intent modificata: l'intent ACTION_KEY_MISSING viene ora trasmesso solo se il tentativo di accoppiamento automatico non va a buon fine. In questo modo si riduce la gestione degli errori non necessaria nell'app se il sistema recupera correttamente l'associazione in background.
• Notifica utente: il sistema gestisce l'accoppiamento automatico tramite nuove notifiche e finestre di dialogo dell'interfaccia utente. Agli utenti verrà chiesto di confermare il tentativo di accoppiamento automatico per assicurarsi che siano a conoscenza della riconnessione.

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

• Rimuovi manualmente le informazioni sull'associazione dal dispositivo periferico
• Annulla manualmente l'accoppiamento del dispositivo in: Impostazioni > Dispositivi collegati