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.
![Illustrazione di come Sospensione applica un primo livello di
limitazioni relative all'attività di sistema per migliorare la durata della batteria](https://developer.android.com/static/images/android-7.0/doze-diagram-1.png?authuser=9&hl=it)
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](https://developer.android.com/static/images/android-7.0/doze-diagram-2.png?authuser=9&hl=it)
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 annunciCONNECTIVITY_ACTION
se si registrano il suoBroadcastReceiver
conContext.registerReceiver()
e questo contesto è ancora valido. - Il sistema non invia più annunci
ACTION_NEW_PICTURE
oACTION_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/oMODE_WORLD_WRITEABLE
, attiverà unSecurityException
.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'URIfile://
attiva unFileUriExposedException
. Il modo consigliato per condividere i contenuti di un file privato utilizzanoFileProvider
. -
DownloadManager
non può più condividere in privato i file archiviati per nome. Le applicazioni legacy potrebbero presentare percorso non accessibile durante l'accesso aCOLUMN_LOCAL_FILENAME
. Targeting per app Android 7.0 o versioni successive attiva unSecurityException
quando tentativo di accessoCOLUMN_LOCAL_FILENAME
. Applicazioni legacy che impostano il percorso di download su un percorso pubblico utilizzandoDownloadManager.Request.setDestinationInExternalFilesDir()
oDownloadManager.Request.setDestinationInExternalPublicDir()
possono comunque accedere al percorsoCOLUMN_LOCAL_FILENAME
, tuttavia, questo è fortemente sconsigliato. Il modo migliore per accedere a un file esposto daDownloadManager
sta usandoContentResolver.openFileDescriptor()
.
Condivisione di file tra app
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](https://developer.android.com/static/images/android-7.0/screen-zoom-1.png?authuser=9&hl=it)
![Schermo che mostra l'effetto dell'aumento delle dimensioni di visualizzazione di un dispositivo su cui è installata un'immagine di sistema Android 7.0](https://developer.android.com/static/images/android-7.0/screen-zoom-2.png?authuser=9&hl=it)
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
egetJNIEnv
dalibandroid_runtime.so
:AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h> AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or JavaVM::AttachCurrentThread from <jni.h>.
- Usa
__system_property_get
anziché ilproperty_get
privato simbolo dilibcutils.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
dalibcrypto.so
. Ad esempio, devi collegare in modo staticolibcyrpto.a
in il tuo file.so
o includi una versione dilibcrypto.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 unIllegalArgumentException
. - 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 metodicreateAndInitializeUser()
sono deprecati; il nuovo li sostituisce con il metodoDevicePolicyManager.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 valorenull
. - 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 daDevicePolicyManager.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 delDevicePolicyManager
; puoi far presa su questo genitore chiamata al numeroDevicePolicyManager.getParentProfileInstance()
. Ad esempio, se chiami l'oggettolockNow()
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'autorizzazioneWRITE_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 generaTransactionTooLargeExceptions
comeRuntimeExceptions
, anziché registrarli o eliminarli in modo invisibile. Uno. un esempio comune è l'archiviazione di troppi datiActivity.onSaveInstanceState()
, che fa sì cheActivityThread.StopInfo
generi unRuntimeException
quando la tua app ha come target Android 7.0. -
Se un'app pubblica
Runnable
attività su unView
eView
non è collegato a una finestra, il sistema mette in coda l'attivitàRunnable
conView
; 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 ilRunnable
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 ha pubblicato contenuti in un
-
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 aspettarsiSTATUS_PENDING_USER_ACTION
come stato del reso quando richiamanoPackageInstaller.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.