Questa pagina è stata tradotta dall'API Cloud Translation.

Modifiche al comportamento di Android 7.0

Oltre alle nuove funzioni, Android 7.0 include una serie di modifiche al comportamento del sistema e delle API. Questo documento evidenzia alcune delle modifiche chiave che dovresti comprendere e tenere in considerazione nelle tue app.

Se hai già pubblicato un'app per Android, tieni presente che la tua app potrebbero essere interessate da queste modifiche alla piattaforma.

Batteria e memoria

Android 7.0 include modifiche del comportamento del sistema volte a migliorare la durata della batteria dei dispositivi e la riduzione dell'utilizzo della RAM. Queste modifiche possono influire sull'accesso della tua app a risorse di sistema, oltre al modo in cui la tua app interagisce con altre app tramite determinati intent impliciti.

Sospensione

Introdotta in Android 6.0 (livello API 23), la funzionalità Sospensione aumenta la durata della batteria di posticipare le attività di CPU e rete quando un utente lascia il dispositivo scollegato. sedentario e con lo schermo spento. Android 7.0 offre ulteriori miglioramenti alla funzionalità Sospensione applicando un sottoinsieme di limitazioni di CPU e rete quando il dispositivo è scollegato dalla corrente con lo schermo spento, ma non necessariamente stazionario, ad esempio, quando lo smartphone si sposta nella tasca di un utente.

Figura 1. Illustrazione di come Sospensione applica un primo livello di limitazioni relative all'attività di sistema per migliorare la durata della batteria.

Quando un dispositivo è alimentato a batteria e lo schermo è stato spento per un certo periodo attiva la modalità Sospensione e applica il primo sottoinsieme di limitazioni: interrompe l'accesso alla rete delle app e rimanda i job e le sincronizzazioni. Se il dispositivo è che è rimasto fermo per un certo periodo di tempo dopo essere entrato nella modalità Sospensione, il sistema applica il altre limitazioni relative alla sospensione di PowerManager.WakeLock, Sveglie AlarmManager, GPS e ricerche di reti Wi-Fi. Indipendentemente indipendentemente dal fatto che vengano applicate alcune o tutte le limitazioni di sospensione, il sistema riattiva per brevi periodi di manutenzione, durante i quali sono consentite le applicazioni. l'accesso alla rete e può eseguire qualsiasi job/sincronizzazione differito.

Illustrazione di come Sospensione applica un secondo livello di
limitazioni relative alle attività del sistema quando il dispositivo è fermo per un determinato tempo

Figura 2. Illustrazione di come Sospensione applica un secondo livello di limitazioni relative alle attività del sistema dopo che il dispositivo è fermo per un determinato periodo di tempo.

Tieni presente che, attivando lo schermo o collegando il dispositivo alla corrente, rimuove queste restrizioni di elaborazione. Il comportamento aggiuntivo non influenzare i consigli e le best practice per adattare la tua app alle di Sospensione introdotta in Android 6.0 (livello API 23), come discusso in Ottimizzazione per Sospensione e Standby delle app. Dovresti comunque seguire questi suggerimenti, come l'utilizzo di Firebase Cloud Messaging (FCM) per inviare e ricevere messaggi e iniziare a pianificare gli aggiornamenti per soddisfare ulteriori comportamenti di sospensione.

Project Svelte: ottimizzazioni dello sfondo

Android 7.0 rimuove tre trasmissioni implicite per contribuire a ottimizzare entrambi l'uso della memoria e il consumo energetico. Questa modifica è necessaria perché le informazioni gli annunci avviano con frequenza le app che si sono registrate per ascoltarli in sullo sfondo. La rimozione di queste trasmissioni può apportare vantaggi significativi al dispositivo le prestazioni e l'esperienza utente.

I dispositivi mobili subiscono frequenti cambiamenti di connettività, ad esempio durante gli spostamenti tra Wi-Fi e dati mobili. Al momento, le app possono monitorare le modifiche in la connettività registrando un ricevitore per la trasmissione CONNECTIVITY_ACTION implicita nel suo del file manifest. Poiché molte app si registrano per ricevere la trasmissione, una sola l'interruttore di rete può causare la riattivazione e l'elaborazione della trasmissione una volta sola.

Analogamente, nelle versioni precedenti di Android, le app potevano registrarsi per ricevere trasmissioni implicite di ACTION_NEW_PICTURE e ACTION_NEW_VIDEO da altre app, ad esempio Fotocamera. Queste app si attivano quando un utente scatta una foto con l'app Fotocamera per elaborare la trasmissione.

Per ovviare a questi problemi, Android 7.0 applica quanto segue. ottimizzazioni:

Le app che hanno come target Android 7.0 (livello API 24) e versioni successive non ricevono CONNECTIVITY_ACTION trasmette se dichiarano il proprio broadcast receiver nel manifest. Le app continueranno a ricevono annunci CONNECTIVITY_ACTION se si registrano il suo BroadcastReceiver con Context.registerReceiver() e questo contesto è ancora valido.
Il sistema non invia più annunci ACTION_NEW_PICTURE o ACTION_NEW_VIDEO. Questa ottimizzazione riguarda tutte le app, non solo quelle destinate ad Android 7.0.

Se la tua app utilizza uno di questi intent, devi rimuovere le dipendenze il prima possibile, in modo da poter effettuare correttamente il targeting dei dispositivi Android 7.0. Il framework Android offre diverse soluzioni per ridurre la necessità di queste trasmissioni implicite. Ad esempio, l'API JobScheduler offre un solido meccanismo per pianificare operazioni di rete in condizioni specificate, come la connessione a non a consumo. Puoi anche utilizzare JobScheduler per reagire ai cambiamenti apportati ai fornitori di contenuti.

Per ulteriori informazioni sulle ottimizzazioni in background in Android 7.0 (livello API) 24) e su come adattare la tua app, consulta Background Ottimizzazioni.

Modifiche alle autorizzazioni

Android 7.0 include modifiche alle autorizzazioni che potrebbero interessare la tua app.

Modifiche alle autorizzazioni del file system

Per migliorare la sicurezza dei file privati, la directory privata di Le app destinate ad Android 7.0 o versioni successive hanno accesso limitato (0700). Questa impostazione impedisce la perdita di metadati di file privati, come le loro dimensioni o l'esistenza stessa. Questa modifica alle autorizzazioni ha diversi effetti collaterali:

Le autorizzazioni dei file privati non dovrebbero più essere concesse dal proprietario, e un tentativo di farlo utilizzando MODE_WORLD_READABLE e/o MODE_WORLD_WRITEABLE, attiverà un SecurityException.
Nota:al momento questa limitazione non è stata applicata completamente. Le app possono comunque modificare le autorizzazioni per la directory privata utilizzando le API native o l'API File. Tuttavia, scoraggiare il rilascio delle autorizzazioni per la directory privata.
Il passaggio di file:// URI al di fuori del dominio del pacchetto potrebbe lasciare il campo con un percorso non accessibile. Di conseguenza, prova a passare L'URI file:// attiva un FileUriExposedException. Il modo consigliato per condividere i contenuti di un file privato utilizzano FileProvider.
DownloadManager non può più condividere in privato i file archiviati per nome. Le applicazioni legacy potrebbero presentare percorso non accessibile durante l'accesso a COLUMN_LOCAL_FILENAME. Targeting per app Android 7.0 o versioni successive attiva un SecurityException quando tentativo di accesso COLUMN_LOCAL_FILENAME. Applicazioni legacy che impostano il percorso di download su un percorso pubblico utilizzando DownloadManager.Request.setDestinationInExternalFilesDir() o DownloadManager.Request.setDestinationInExternalPublicDir() possono comunque accedere al percorso COLUMN_LOCAL_FILENAME, tuttavia, questo è fortemente sconsigliato. Il modo migliore per accedere a un file esposto da DownloadManager sta usando ContentResolver.openFileDescriptor().

Per le app che hanno come target Android 7.0, il framework Android impone il criterio dell'API StrictMode che vieta l'esposizione di file:// URI all'esterno dell'app. Se un intent contenente l'URI di un file lascia la tua app, l'app non va a buon fine con un'eccezione FileUriExposedException.

Per condividere file tra le applicazioni, devi inviare un URI content:// e concedere un'autorizzazione di accesso temporanea all'URI. Il modo più semplice per concedere questa autorizzazione è utilizzando la classe FileProvider. Per ulteriori informazioni sulle autorizzazioni e sulla condivisione di file, consulta la sezione Condivisione di file.

Accessibilità migliorata

Android 7.0 include modifiche volte a migliorare l'usabilità del per utenti ipovedenti o con disabilità visiva. Queste modifiche dovrebbero generalmente non richiedono modifiche al codice nell'app, ma è consigliabile queste funzionalità e testarle con la tua app per valutare il potenziale impatto sugli utenti un'esperienza senza intervento manuale.

Zoom schermo

Android 7.0 consente agli utenti di impostare Dimensioni di visualizzazione che consentono di ingrandire o riduce tutti gli elementi sullo schermo, migliorando così l'accessibilità del dispositivo. per gli utenti ipovedenti. Gli utenti non possono eseguire lo zoom dello schermo oltre il limite minimo dello schermo larghezza di sw320dp, che è la larghezza di un Nexus 4, un comune telefono di medie dimensioni.

Schermata che mostra le dimensioni di visualizzazione senza zoom di un dispositivo su cui è installata un'immagine di sistema Android 7.0

Schermo che mostra l'effetto dell'aumento delle dimensioni di visualizzazione di un dispositivo su cui è installata un'immagine di sistema Android 7.0

Figura 3. Lo schermo a destra mostra l'effetto aumentare le dimensioni di visualizzazione di un dispositivo su cui è installata un'immagine di sistema Android 7.0.

Quando la densità del dispositivo cambia, il sistema avvisa le app in esecuzione nel nei seguenti modi:

Se un'app ha come target il livello API 23 o precedente, il sistema termina automaticamente tutti i relativi processi in background. Ciò significa che se un utente non fa più parte del di un'app di questo tipo per aprire la schermata Impostazioni e modificare Dimensioni di visualizzazione, il sistema termina l'app rimanendo come in caso di scarsa memoria. Se l'app è in primo piano processi, il sistema avvisa questi processi della modifica alla configurazione descritta in Gestione Modifiche di runtime, come se l'orientamento del dispositivo fosse cambiato.
Se un'app ha come target Android 7.0, tutti i relativi processi (in primo piano e in background) ricevono una notifica della modifica alla configurazione descritta in Gestione Modifiche di runtime.

Per la maggior parte delle app non è necessario apportare modifiche per supportare questa funzionalità, a condizione le app seguono le best practice di Android. Elementi specifici da controllare:

Testa la tua app su un dispositivo con larghezza dello schermo sw320dp e assicurarti che funzioni in modo adeguato.
Se la configurazione del dispositivo cambia, aggiorna gli eventuali dati in base alla densità di informazioni memorizzate nella cache, ad esempio bitmap o risorse caricate nella cache in ogni rete. Verifica la presenza di modifiche alla configurazione quando l'app viene ripresa dalla modalità in pausa stato.
Nota:se memorizzi nella cache i dati dipendenti dalla configurazione, si tratta di una è buona norma includere i metadati pertinenti, come la schermata dimensioni o densità dei pixel per quei dati. Il salvataggio di questi metadati consente di decidere se aggiornare i dati memorizzati nella cache dopo una configurazione modifica.
Evita di specificare dimensioni con unità in pixel, poiché non vengono ridimensionate con densità dello schermo. Specifica invece dimensioni con valori indipendenti dalla densità pixel (dp).

Impostazioni di visione artificiale nella configurazione guidata

Android 7.0 include le impostazioni di Vision nella schermata di benvenuto, in cui gli utenti possono configura le seguenti impostazioni di accessibilità su un nuovo dispositivo: Gesto di ingrandimento, Dimensione carattere, Dimensioni di visualizzazione e TalkBack. Questa modifica aumenta la visibilità dei bug relativi alle diverse impostazioni dello schermo. A valutare l'impatto di questa funzionalità, dovresti testare le tue app con questi attivate. Puoi trovare le impostazioni in Impostazioni > Accessibilità.

Collegamento di app NDK alle librerie della piattaforma

A partire da Android 7.0, il sistema impedisce il collegamento dinamico delle app rispetto a librerie non NDK, causando l'arresto anomalo dell'app. Questa modifica punta a creare un'esperienza di app coerente per tutti gli aggiornamenti della piattaforma e su dispositivi diversi. Anche se il tuo codice potrebbe non essere collegato librerie private, è possibile che una libreria statica di terze parti potrebbe farlo. Pertanto, tutti gli sviluppatori devono verificare che le app non si arrestino in modo anomalo sui dispositivi con Android 7.0. Se la tua app utilizza devi utilizzare solo le API NDK pubbliche.

Esistono tre modi in cui la tua app potrebbe tentare di accedere a una piattaforma privata API:

L'app accede direttamente alle librerie della piattaforma private. Dovresti aggiornare la tua app per includere la propria copia di tali librerie o utilizzare le API NDK pubbliche.
La tua app usa una libreria di terze parti che accede a una piattaforma privata librerie. Anche se hai la certezza che la tua app non abbia accesso a librerie private dovresti comunque testare l'app per questo scenario.
La tua app fa riferimento a una libreria non inclusa nel relativo APK. Per Ad esempio, questo può accadere se provi a utilizzare una tua copia di OpenSSL hai dimenticato di raggrupparlo con l'APK dell'app. L'app potrebbe funzionare normalmente sulle versioni della piattaforma Android che include libcrypto.so. Tuttavia, l'app potrebbe avere un arresto anomalo sulle versioni successive di Android che non includono questa libreria (ad esempio, Android 6.0 e versioni successive). Per risolvere il problema, assicurati di raggruppare tutti le librerie non NDK con l'APK.

Le app non devono utilizzare librerie native non incluse nell'NDK perché potrebbero cambiare o essere rimossi tra le diverse versioni di Android. La passare da OpenSSL a BoringSSL è un esempio di questo cambiamento. Inoltre, perché non sono previsti requisiti di compatibilità per le librerie di piattaforma che non inclusi nell'NDK, dispositivi diversi possono offrire livelli diversi di la compatibilità.

Per ridurre l'impatto che questa restrizione potrebbe avere attualmente app rilasciate, un insieme di librerie che registrano un uso significativo, ad esempio libandroid_runtime.so, libcutils.so, libcrypto.so e libssl.so sono temporaneamente accessibile su Android 7.0 (livello API 24) per le app che hanno come target il livello API 23 o in basso. Se la tua app carica una di queste librerie, logcat genera un avviso e un avviso popup sul dispositivo di destinazione ti avvisa. Se vedi questi avvisi, devi aggiornare l'app in modo da includere la propria copia librerie o solo le API NDK pubbliche. Release future di Android potrebbe limitare del tutto l'uso delle librerie private, causando così il l'arresto anomalo dell'app.

Tutte le app generano un errore di runtime quando chiamano un'API che non è nessuna delle due pubblicamente né temporaneamente accessibili. Il risultato è che System.loadLibrary e dlopen(3) sono entrambi restituiti NULL e potrebbero causare l'arresto anomalo dell'app. Dovresti esaminare codice dell'app per rimuovere l'utilizzo di API della piattaforma privata e testare accuratamente le tue app Utilizzando un dispositivo o un emulatore con Android 7.0 (livello API 24). Se e non hai la certezza che la tua app utilizzi librerie private, puoi controllare in logcat per identificare l'errore di runtime.

La seguente tabella descrive il comportamento che dovresti aspettarti di vedere da una a seconda del suo utilizzo di librerie native private e dell'API target livello (android:targetSdkVersion).

Biblioteche	Livello API target	Accesso al runtime tramite Linker dinamico	Comportamento di Android 7.0 (livello API 24)	Comportamento futuro della piattaforma Android
NDK Pubblico	Qualche	Accessibilità	Funziona come previsto	Funziona come previsto
Private (librerie private accessibili temporaneamente)	23 o inferiore	Temporaneamente accessibile	Funziona come previsto, ma viene visualizzato un avviso logcat.	Errore di runtime
Private (librerie private accessibili temporaneamente)	24 o successiva	Con restrizioni	Errore di runtime	Errore di runtime
Privato (altro)	Qualche	Con restrizioni	Errore di runtime	Errore di runtime

Verificare se l'app utilizza librerie private

Per aiutarti a identificare i problemi di caricamento delle librerie private, logcat potrebbe generare un un avviso o un errore di runtime. Ad esempio, se la tua app ha come target il livello API 23 o e prova ad accedere a una libreria privata su un dispositivo con Android 7.0, è possibile che venga visualizzato un avviso simile al seguente:

03-21 17:07:51.502 31234 31234 W linker  : library "libandroid_runtime.so"
("/system/lib/libandroid_runtime.so") needed or dlopened by
"/data/app/com.popular-app.android-2/lib/arm/libapplib.so" is not accessible
for the namespace "classloader-namespace" - the access is temporarily granted
as a workaround for http://b/26394120

Questi avvisi di logcat indicano la libreria che sta tentando di accedere a un all'API Private Platform, ma non causerà l'arresto anomalo dell'app. Se l'app ha come target il livello API 24 o superiore, tuttavia logcat genera quanto segue un errore di runtime e l'app potrebbe arrestarsi in modo anomalo:

java.lang.UnsatisfiedLinkError: dlopen failed: library "libcutils.so"
("/system/lib/libcutils.so") needed or dlopened by
"/system/lib/libnativeloader.so" is not accessible for the namespace
"classloader-namespace"
  at java.lang.Runtime.loadLibrary0(Runtime.java:977)
  at java.lang.System.loadLibrary(System.java:1602)

Potresti anche vedere questi output logcat se la tua app utilizza librerie di terze parti che si collegano dinamicamente alle API della piattaforma privata. Lo strumento Readelf nel Android 7.0DK ti consente di generare un elenco di tutte le istanze condivise librerie di un determinato file .so eseguendo questo comando:

aarch64-linux-android-readelf -dW libMyLibrary.so

Aggiorna la tua app

Di seguito sono riportati alcuni passaggi che puoi seguire per correggere questi tipi di errori e Assicurati che la tua app non abbia arresti anomali negli aggiornamenti futuri della piattaforma:

Se la tua app utilizza librerie della piattaforma privata, devi aggiornarla in modo da includere una copia di queste librerie o utilizzare le API pubbliche NDK.
Se la tua app utilizza una libreria di terze parti che accede a simboli privati, contatta all'autore della biblioteca per aggiornarla.
Assicurati di pacchettizzare tutte le librerie non NDK con il tuo APK.

Usa le funzioni JNI standard invece di getJavaVM e getJNIEnv da libandroid_runtime.so:

AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h>
AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or
JavaVM::AttachCurrentThread from <jni.h>.

Usa __system_property_get anziché il property_get privato simbolo di libcutils.so. Per farlo, usa __system_property_get che includono:
```
#include <sys/system_properties.h>
```
Nota: la disponibilità e i contenuti delle proprietà di sistema sono non testato tramite CTS. Una soluzione migliore sarebbe evitare di utilizzare questi tutte le proprietà.
Usa una versione locale del simbolo SSL_ctrl da libcrypto.so. Ad esempio, devi collegare in modo statico libcyrpto.a in il tuo file .so o includi una versione di libcrypto.so a collegamento dinamico da BoringSSL/OpenSSL e pacchettizzala nel tuo APK.

Android for Work

Android 7.0 contiene modifiche per le app destinate ad Android for Work, tra cui: modifiche all'installazione dei certificati, alla reimpostazione della password, utente secondario la gestione e l'accesso agli identificatori dei dispositivi. Se stai creando app per Ambienti Android for Work, è necessario rivedere e modificare queste modifiche la tua app di conseguenza.

Devi installare un programma di installazione dei certificati delegato prima che il DPC possa impostare li annotino. Per le app del profilo e delle app proprietario del dispositivo che hanno come target Android 7.0 (livello API 24), devi installare il programma di installazione dei certificati delegato prima dei criteri relativi ai dispositivi le chiamate al controller (DPC) DevicePolicyManager.setCertInstallerPackage(). Se l'installatore non è già installato, il sistema genera un IllegalArgumentException.
Ora la reimpostazione delle limitazioni della password per gli amministratori dei dispositivi viene applicata al profilo proprietari. Gli amministratori dei dispositivi non possono più utilizzare DevicePolicyManager.resetPassword() per cancellare le password o modificarle quelli già impostati. Gli amministratori dei dispositivi possono impostare una password, ma se il dispositivo non ha password, PIN o sequenze.
I proprietari di dispositivi e profili possono gestire gli account anche se esistono limitazioni per iniziare. I proprietari dei dispositivi e dei profili possono chiamare le API di gestione account anche se sono presenti DISALLOW_MODIFY_ACCOUNTS limitazioni relative all'utente.
I proprietari dei dispositivi possono gestire più facilmente gli utenti secondari. Quando un dispositivo viene in esecuzione in modalità proprietario del dispositivo, la limitazione DISALLOW_ADD_USER viene impostato automaticamente. Questo impedisce agli utenti di creare account secondari non gestiti utenti. Inoltre, CreateUser() e I metodi createAndInitializeUser() sono deprecati; il nuovo li sostituisce con il metodo DevicePolicyManager.createAndManageUser().
I proprietari dei dispositivi possono accedere agli identificatori dei dispositivi. Il proprietario di un dispositivo può accedere L'indirizzo MAC Wi-Fi di un dispositivo, utilizzando DevicePolicyManager.getWifiMacAddress(). Se il Wi-Fi non ha mai attivato sul dispositivo, questo metodo restituisce il valore null.
L'impostazione Modalità di lavoro controlla l'accesso alle app di lavoro. Quando la modalità Lavoro è disattivata, in Avvio applicazioni il sistema indica che le app di lavoro non sono disponibili rendendole in grigio. Abilitazione in corso... la modalità di lavoro ripristina nuovamente il normale comportamento.
Quando installi un file PKCS #12 contenente una catena di certificati client e la chiave privata corrispondente nell'interfaccia utente delle impostazioni, il certificato CA non è più installata nell'archiviazione delle credenziali attendibili. In questo modo non influisce sul risultato di KeyChain.getCertificateChain() quando le app tentano di recuperare il client più avanti la catena di certificati. Se necessario, il certificato CA deve essere installato all'archiviazione delle credenziali attendibili tramite l'interfaccia utente delle impostazioni separatamente, con un Formato con codifica DER con estensione .crt o .cer.
A partire da Android 7.0, la registrazione e l'archiviazione delle impronte vengono gestite per utente. Se il client Policy Controller (DPC) del proprietario di un profilo ha come target il livello API 23 (o versioni precedenti) su un dispositivo con Android 7.0 (livello API 24), l'utente deve è ancora in grado di impostare l'impronta sul dispositivo, mentre le applicazioni di lavoro non possono accesso all'impronta digitale del dispositivo. Quando il DPC ha come target il livello API 24 o superiore, l'utente può impostare l'impronta digitale specifica per il profilo di lavoro selezionando Impostazioni > Sicurezza > Sicurezza del profilo di lavoro.
Un nuovo stato di crittografia ENCRYPTION_STATUS_ACTIVE_PER_USER è restituito da DevicePolicyManager.getStorageEncryptionStatus(), indicano che la crittografia è attiva e che la chiave di crittografia è legata al utente. Il nuovo stato viene restituito solo se il DPC ha come target il livello API 24 o superiore. Per le app che hanno come target livelli API precedenti, ENCRYPTION_STATUS_ACTIVE anche se la chiave di crittografia è specifica per l'utente o il profilo.
In Android 7.0, diversi metodi che normalmente interessano l'intero dispositivo si comporta in modo diverso se ha un profilo di lavoro installato con una sfida di lavoro separata. Anziché interessare l'intero dispositivo, questi si applicano solo al profilo di lavoro. L'elenco completo di questi metodi è nella documentazione DevicePolicyManager.getParentProfileInstance(). Ad esempio: DevicePolicyManager.lockNow() blocca solo il profilo di lavoro, anziché bloccare l'intero dispositivo. Per ognuno di questi metodi, è possibile ottenere il vecchio richiamando il metodo sull'istanza padre del DevicePolicyManager; puoi far presa su questo genitore chiamata al numero DevicePolicyManager.getParentProfileInstance(). Ad esempio, se chiami l'oggetto lockNow() dell'istanza padre viene bloccato l'intero dispositivo.

Conservazione delle annotazioni

Android 7.0 corregge un bug per cui la visibilità delle annotazioni veniva ignorata. Questo problema ha consentito al runtime di accedere alle annotazioni che non avrebbero dovuto essere in grado di eseguire. Queste annotazioni includevano:

VISIBILITY_BUILD: destinato a essere visibile solo al momento della build.
VISIBILITY_SYSTEM: destinato a essere visibile in fase di runtime, ma solo al e il sistema sottostante.

Se la tua app si è basata su questo comportamento, aggiungi alle annotazioni un criterio di conservazione che deve: disponibili in fase di runtime. Per farlo, utilizzi @Retention(RetentionPolicy.RUNTIME).

Modifiche alla configurazione predefinita TLS/SSL

Android 7.0 apporta le seguenti modifiche alla configurazione TLS/SSL predefinita usato dalle app per HTTPS e altro traffico TLS/SSL:

Le suite di crittografia RC4 sono ora disattivate.
Le suite di crittografia CHACHA20-POLY1305 sono ora abilitate.

La disattivazione di RC4 per impostazione predefinita potrebbe causare malfunzionamenti di HTTPS o TLS/SSL quando il server non negozia suite di crittografia moderne. La soluzione migliore è migliorare la configurazione del server per consentire una maggiore sicurezza. e più moderni protocolli e suite di crittografia. Idealmente, TLSv1.2 e AES-GCM e le suite di crittografia Forward Secrecy (ECDHE) devono essere abilitate attiva e preferita.

In alternativa, puoi modificare l'app in modo che utilizzi un elemento SSLSocketFactory personalizzato per comunicare con il server. La fabbrica deve essere progettato per creare SSLSocket a quelle istanze che dispongono di alcune suite di crittografia richieste dal server oltre alle suite di crittografia predefinite.

Nota: queste modifiche non riguardano WebView.

App che hanno come target Android 7.0

Queste modifiche del comportamento si applicano esclusivamente alle app scelte come target Android 7.0 (livello API 24) o versioni successive. App che si compilano in base ad Android 7.0, oppure imposta targetSdkVersion su Android 7.0 o versioni successive. È necessario modificare le proprie app per supportare correttamente questi comportamenti, ove applicabile.

Modifiche di serializzazione

Android 7.0 (livello API 24) ha corretto un bug nel calcolo dell'impostazione predefinita serialVersionUID non corrisponde alla specifica.

Classi che implementano Serializable e non specificare un campo serialVersionUID esplicito potrebbe vedranno una modifica nel valore serialVersionUID predefinito che causerebbe un'eccezione quando si tenta di deserializzare le istanze della classe che erano serializzato su una versione precedente o serializzato da un'app che ha come target una versione precedente completamente gestita. Il messaggio di errore sarà simile al seguente:

local class incompatible: stream classdesc serialVersionUID = 1234, local class serialVersionUID = 4567

Per risolvere questi problemi è necessario aggiungere un campo serialVersionUID a qualsiasi classe interessata con il valore stream classdesc serialVersionUID del messaggio di errore, ad esempio 1234 pollice in questo caso. Questa modifica ottempera a tutti i consigli di buone prassi per scrivere il codice di serializzazione e funziona su tutte le versioni di Android.

Il bug specifico corretto era relativo alla presenza di di inizializzazione, ad esempio <clinit>. In base alle specifica la presenza o l'assenza di un metodo di inizializzazione statico influenzerà il valore serialVersionUID predefinito calcolato per quella classe. Prima della correzione del bug, il calcolo controllava anche la superclasse per un un inizializzatore statico se una classe non ne aveva uno.

Per essere chiari, questa modifica non riguarda le app che hanno come target i livelli API 23 o inferiori, corsi con uno o più campi serialVersionUID con un metodo di inizializzazione statico.

Altri punti importanti

Quando un'app viene eseguita su Android 7.0, ma ha come target un livello API inferiore, e l'utente cambia le dimensioni di visualizzazione, il processo dell'app si interrompe. L'app devono poter gestire agevolmente questo scenario. Altrimenti, si arresta in modo anomalo quando l'utente lo ripristina da Recenti.
Devi testare l'app per assicurarti che questo comportamento non si verifichi. Puoi farlo causando un arresto anomalo identico quando si termina manualmente l'app tramite DDS.

Le app che hanno come target Android 7.0 (livello API 24) e versioni successive non vengono automaticamente terminati in seguito alle variazioni di densità; ma possono comunque rispondere insoddisfacente modifiche alla configurazione.
Le app su Android 7.0 devono poter gestire agevolmente le modifiche alla configurazione, e non deve arrestarsi in modo anomalo agli avvii successivi. Puoi verificare il comportamento dell'app modificando le dimensioni del carattere (Impostazioni > Display > Dimensione carattere) e ripristinando l'app da Recenti.
A causa di un bug nelle versioni precedenti di Android, il sistema non ha segnalato la scrittura a un socket TCP sul thread principale come violazione in modalità rigida. Android 7.0 corregge questo bug. Le app che mostrano questo comportamento ora generano un android.os.NetworkOnMainThreadException. In genere, eseguire operazioni di rete sul thread principale non è una buona idea perché queste operazioni di solito hanno una latenza elevata che causa errori ANR e jank.
Per impostazione predefinita, la famiglia di metodi Debug.startMethodTracing() è ora impostata su all'archiviazione dell'output nella directory specifica del pacchetto nello spazio di archiviazione condiviso, anziché al livello superiore della scheda SD. Ciò significa che le app non devono più richiedere l'autorizzazione WRITE_EXTERNAL_STORAGE per usare queste API.
Molte API delle piattaforme hanno ora iniziato a controllare l'invio di payload di grandi dimensioni su Binder transazioni e il sistema ora genera TransactionTooLargeExceptions come RuntimeExceptions, anziché registrarli o eliminarli in modo invisibile. Uno. un esempio comune è l'archiviazione di troppi dati Activity.onSaveInstanceState(), che fa sì che ActivityThread.StopInfo generi un RuntimeException quando la tua app ha come target Android 7.0.
Se un'app pubblica Runnable attività su un View e View non è collegato a una finestra, il sistema mette in coda l'attività Runnable con View; l'attività Runnable non viene eseguita finché View è collegato in una finestra. Questo comportamento corregge i seguenti bug:
- Se un'app ha pubblicato contenuti in un View da un thread diverso da quello previsto nel thread dell'interfaccia utente di ogni finestra, di conseguenza il Runnable potrebbe essere eseguito sul thread sbagliato.
- Se l'attività Runnable è stata pubblicata da un thread diverso da un thread di loop, l'app potrebbe esporre l'attività Runnable.
Se un'app per Android 7.0 con DELETE_PACKAGES prova a eliminare un pacchetto, ma il pacchetto è stato installato da un'altra app. il sistema richiede la conferma dell'utente. In questo scenario, le app devono aspettarsi STATUS_PENDING_USER_ACTION come stato del reso quando richiamano PackageInstaller.uninstall().
Il provider JCA chiamato Crypto è deprecato perché l'unico SHA1PRNG è una crittografia debole. Le app non possono più essere usate SHA1PRNG per derivare (in modo non sicuro) le chiavi, perché questo provider non è più disponibili. Per ulteriori informazioni, consulta il blog post Sicurezza "Crypto" fornitore deprecato in Android N.