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.

Sicurezza

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

usesClearTraffic deprecation plan

In una versione 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 a quali domini l'app deve stabilire 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 lancia un intent con un URI che ha l'azione Send, SendMultiple o ImageCapture, il sistema concede automaticamente le autorizzazioni URI di lettura e scrittura all'app di destinazione. Prevediamo di modificare questo comportamento in Android 18. Per questo motivo, consigliamo alle app di concedere esplicitamente le autorizzazioni URI pertinenti anziché fare affidamento sul sistema per la concessione delle autorizzazioni.

Limiti del keystore per app

Le app devono evitare di creare un numero eccessivo di chiavi in Android Keystore, perché è una risorsa condivisa per tutte le app sul dispositivo. A partire da Android 17, il sistema impone 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 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 a cui sono destinate.

Se un'app tenta di creare chiavi oltre il limite, la creazione non va a buon fine e viene restituito un KeyStoreException. La stringa del messaggio dell'eccezione contiene informazioni sul limite di chiavi. Se l'app chiama getNumericErrorCode() sull'eccezione, il valore restituito dipende dal livello API a cui è destinata l'app:

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

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, a causa della rotazione) e questa modifica non viene gestita dall'app stessa, la visibilità della tastiera IME precedente non viene ripristinata.

Se la tua app subisce una modifica alla configurazione che non gestisce e deve rendere visibile la tastiera 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 virtuale a livello di programmazione nel metodo onCreate() della tua attività o aggiungi il metodo onConfigurationChanged().

Intervento 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

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 movimenti del puntatore e i gesti di scorrimento dai tocchi dell'utente e li segnala all'app nello stesso modo in cui vengono segnalati i movimenti del puntatore e della rotellina di scorrimento di un mouse acquisito. Nella maggior parte dei casi, in questo modo non è più necessario che le app che supportano i mouse acquisiti aggiungano una logica di gestione speciale per i touchpad. Per maggiori dettagli, consulta la documentazione di View.POINTER_CAPTURE_MODE_RELATIVE.

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

Contenuti multimediali

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 restrizioni alle interazioni audio in background, tra cui riproduzione audio, richieste di focus audio e 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 modifica del volume non vanno a buon fine senza generare un'eccezione o fornire un messaggio di errore. L'API Audio Focus non funziona e restituisce il codice di risultato AUDIOFOCUS_REQUEST_FAILED.

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