Google ha rilasciato la prima anteprima per sviluppatori Android 11 per Pixel 2, 3, 3a e 4. Ecco tutte le nuove funzionalità di privacy e sicurezza annunciate.
Prima del previsto, Google ha rilasciato oggi la prima anteprima per sviluppatori della prossima versione del sistema operativo Android: Android 11. Le immagini di sistema sono disponibili per Pixel 2, Pixel 3, Pixel 3a, Pixel 4, ma se non ne possiedi una dispositivi, puoi anche provare l'anteprima per sviluppatori tramite l'emulatore Android Studio o il sistema generico Immagine. Sebbene Google stia riservando la maggior parte delle nuove entusiasmanti funzionalità per utenti e sviluppatori per un grande annuncio al Google I/O 2020, la società ha condiviso una serie di modifiche disponibili nella prima anteprima per sviluppatori. Ecco un riepilogo di tutte le nuove funzionalità relative alla privacy e alla sicurezza che Google ha annunciato in Android 11 Developer Preview 1.
Anteprima per sviluppatori Android 11 1 - Nuove funzionalità per la privacy
Accesso con autorizzazione una tantum
Android controlla a quali tipi di app di dati possono accedere tramite il suo sistema di autorizzazione. Prima di Android 6.0 Marshmallow, le app richiedevano che venissero concesse autorizzazioni al momento dell'installazione, quindi gli utenti dovevano decidere se erano d'accordo con un'app che disponeva di determinate autorizzazioni prima di installarla. Android 6.0 Marshmallow ha introdotto autorizzazioni di runtime per un insieme selezionato di autorizzazioni sensibili, tra cui l'accesso alla posizione, l'accesso al microfono e l'accesso alla fotocamera. Le autorizzazioni di runtime possono essere concesse solo dopo l'installazione e l'app che le richiede deve richiedere all'utente tramite una finestra di dialogo fornita dal sistema di consentire l'accesso. Infine, in Android 10, Google ha introdotto una versione speciale dei permessi runtime che consente all'utente di concedere l'accesso solo mentre l'app è in uso attivo; tuttavia, Google ha introdotto solo l'opzione "mentre l'app è in uso" per l'autorizzazione alla posizione.
In Android 11, Google offre agli utenti un controllo più capillare su altre autorizzazioni sensibili, incluso l’accesso alla fotocamera e al microfono. L'azienda ha introdotto una nuova funzionalità di "autorizzazione una tantum" nell'anteprima per sviluppatori di Android 11 consente all'utente di concedere temporaneamente a un'app l'accesso a un'autorizzazione purché l'app sia nel file primo piano. Una volta che l'utente si allontana dall'app, l'app perde l'accesso a tale autorizzazione e deve richiederla nuovamente.
Modifiche all'archiviazione con ambito
In Android10beta2, Google ha proposto un cambiamento radicale nel modo in cui le app accedono alla memoria esterna su Android. (La memoria esterna, in questo caso, è definita come i dati visibili all'utente e ad altre app situate in /data/media.) Il La modifica, denominata "Scoped Storage", mirava a eliminare l'uso eccessivamente ampio di READ_EXTERNAL_STORAGE autorizzazione. Troppe app sul Google Play Store richiedevano e ottenevano l'accesso all'intero spazio di archiviazione esterno in cui gli utenti salvavano documenti privati, foto, video e altri file. Con l'archiviazione con ambito, per impostazione predefinita alle app sarebbe concessa solo la possibilità di visualizzare le directory dei dati privati. Se un'app dispone dell'autorizzazione READ_EXTERNAL_STORAGE nell'ambito dell'applicazione dell'archiviazione con ambito, può visualizzare determinati file multimediali accessibili tramite l'API MediaStore. In alternativa, l'app può utilizzare Storage Access Framework per consentire all'utente di selezionare manualmente i file tramite il selettore file di sistema. Infine, le app che necessitano di un ampio accesso allo spazio di archiviazione esterno, come i file manager, possono utilizzare Storage Access Framework per richiedere l'utente di concedere all'app l'accesso alla directory principale della memoria esterna, garantendo così l'accesso a tutte le sue sottodirectory, pure.
L'applicazione dell'archiviazione con ambito doveva avere effetto per tutte le app in Android 10, ma dopo il feedback e le critiche degli sviluppatori, Google rilassato i cambiamenti, richiedendoli solo per le app destinate al livello API 29 (Android 10). Dopo il 1° agosto 2020, tutte le nuove app inviate al Google Play Store devono avere come target Android 10 e lo stesso vale per tutti gli aggiornamenti delle app esistenti dopo il 1° novembre 2020. Inoltre, in Android 11, gli sviluppatori di app di gestione file deve presentare un modulo di dichiarazione a Google per avere ampio accesso alla memoria esterna; una volta accettate, le app di gestione file avranno una visualizzazione non filtrata di MediaStore ma non avranno accesso alle directory delle app esterne.
Inoltre, Google ha introdotto altre modifiche all'archiviazione con ambito nell'anteprima per sviluppatori di Android 11. Le app possono scegliere di ottenere il percorso del file non elaborato ed eseguire operazioni di modifica in batch per i file multimediali nel MediaStore. DocumentsUI è stata aggiornata per essere più semplice per gli utenti. Questi cambiamenti sono stati annunciati nel Summit sugli sviluppatori Android l'anno scorso e ci sono stati promessi ulteriori miglioramenti all'archiviazione con ambito nelle future versioni di Android 11.
Anteprima per sviluppatori Android 11 1: nuove funzionalità di sicurezza
Supporto per patenti di guida mobili
Dall'inizio dello scorso anno, Google ha lavorato sul API IdentityCredential e HAL in AOSP. Questa funzionalità pone le basi per archiviare in modo sicuro sul tuo dispositivo mobile i documenti di identità e, in particolare, le patenti di guida mobile conformi alla norma ISO 18013-5. Google ufficialmente ha annunciato questa funzionalità al Google I/O 2019e ora è finalmente supportato in Android 11 Developer Preview 1.
Google non aveva molto da dire su questa funzionalità nel comunicato stampa, ma poiché la funzionalità viene sviluppata pubblicamente, sappiamo già molto di ciò che è in programma. All'I/O 2019, Google ha dichiarato che stava lavorando con l'ISO per standardizzare l'implementazione dei passaporti elettronici; non abbiamo ancora la minima idea di quando saranno disponibili gli ePassport, ma ci sono già diversi stati degli Stati Uniti in cui gli eDL sono implementati o sono in fase di sperimentazione. Google ha anche affermato che sta lavorando per fornire una libreria Jetpack in modo che gli sviluppatori possano creare app di identità. Non sappiamo però quanto presto gli sviluppatori saranno in grado di testare questa funzionalità, poiché un supporto adeguato richiede hardware sicuro sul dispositivo. IL Unità di elaborazione sicura su Qualcomm Snapdragon 865 supporta l'API IdentityCredential, anche se potrebbe non supportare la modalità di accesso diretto dell'API poiché la SPU è integrata nel SoC; La modalità di accesso diretto consentirebbe all'utente di recuperare un ID elettronico memorizzato anche quando non c'è abbastanza energia per avviare Android. Per ulteriori informazioni su questa API, consiglio leggendo la nostra copertura iniziale dove Shawn Willden, il responsabile del team di sicurezza supportato da hardware Android, ha fornito il suo contributo.
Nuovi moduli della linea principale del progetto
Uno dei maggiori cambiamenti in Android 10 per i dispositivi appena lanciati è stata l'introduzione di Linea principale del progetto, che nonostante il nome, non ha nulla a che fare con il supporto del kernel Linux principale su Android. (Quel progetto, tra l'altro, si chiama Generic Kernel Image ed è ancora in fase di elaborazione.) Invece, lo scopo di Project Mainline è quello di Google vuole strappare il controllo dei componenti chiave del framework e delle applicazioni di sistema agli OEM. Ogni modulo Mainline è incapsulato come APK o un File APEX ed è aggiornabile da Google tramite il Play Store. L'utente visualizza gli aggiornamenti come un "aggiornamento di sistema Google Play" (GPSU) sul proprio dispositivo e gli aggiornamenti vengono rilasciati con cadenza regolare come un treno (ad es. vengono scaricati e installati contemporaneamente).
Google impone l'inclusione di moduli Mainline specifici, che al momento del Google I/O 2019 ne includevano 13. Ora, Google richiede un totale di 20 moduli Mainline in Android 11 Developer Preview 1.
Moduli principali iniziali (@ Google I/O 2019) |
Moduli Mainline attuali (per Android 11 Developer Preview 1)* |
---|---|
ANGOLO |
Accesso al portale captive |
Accesso al portale captive |
Coscrypt |
Coscrypt |
Risolutore DNS |
Risolutore DNS |
Interfaccia utente dei documenti |
Interfaccia utente dei documenti |
ExtServices |
ExtServices |
Codec multimediali |
Codec multimediali |
Componenti della struttura multimediale |
Componenti della struttura multimediale |
Metadati del modulo |
Metadati del modulo |
Stack di rete |
Stack di rete |
Configurazione delle autorizzazioni dello stack di rete |
Configurazione delle autorizzazioni dello stack di rete |
Controllore dei permessi |
Controllore dei permessi |
Dati sul fuso orario |
Dati sul fuso orario |
Nuovo modulo permessi |
Nuovo modulo fornitore di contenuti multimediali | |
Nuovo modulo API per reti neurali (NNAPI). |
*Nota: al momento della pubblicazione, Google non ci ha fornito l'elenco completo dei moduli Mainline attualmente richiesti. Aggiorneremo questa tabella una volta che avremo l'elenco completo.
Modifiche biometriche
Presentato Android 9 Pie l'API BiometricPrompt, un'API unificata per l'hardware di autenticazione biometrica. L'API fornisce agli sviluppatori un modo per sfidare l'utente attraverso i dati biometrici salvati, che si tratti di impronte digitali, viso o iride. Prima di BiometricPrompt, gli sviluppatori dovevano creare la propria finestra di dialogo di autenticazione e utilizzare l'API FingerprintManager, che supportava solo l'autenticazione tramite impronta digitale, per sfidare l'utente. Sugli smartphone Galaxy dotati di scanner dell'iride, gli sviluppatori hanno dovuto utilizzare l'SDK di Samsung per sfidare l'utente. Con BiometricPrompt, gli sviluppatori possono sfidare l'utente con qualsiasi metodo biometrico supportato e il sistema fornisce la finestra di dialogo all'utente. Pertanto, gli sviluppatori non devono più preoccuparsi di fornire supporto specifico per un particolare tipo di hardware biometrico e non devono più codificare l'interfaccia utente per la finestra di dialogo di autenticazione. IL Hardware di riconoscimento facciale sicuro di Pixel 4, ad esempio, può essere utilizzato per l'autenticazione nelle app che utilizzano BiometricPrompt.
Quali sono le novità di BiometricPrompt nell'anteprima 1 per sviluppatori di Android 11? Google ha aggiunto 3 nuovi tipi di autenticatore: forte, debole e credenziale del dispositivo. Prima di Android 11, gli sviluppatori potevano interrogare solo l'hardware biometrico sicuro del dispositivo (scanner per impronte digitali, scanner per riconoscimento facciale 3D o scanner dell'iride) quando utilizzavano BiometricPrompt. A partire da Android 11 Developer Preview 1, gli sviluppatori possono anche interrogare i metodi biometrici considerati "deboli" come le soluzioni di riconoscimento facciale basate su software presenti su molti telefoni. Ad esempio, Google precedentemente inserito nella lista nera più telefoni Samsung Galaxy per aver restituito un autenticatore di riconoscimento facciale debole quando si tenta l'autenticazione basata su crittografia. Spetta ora allo sviluppatore decidere quale livello di granularità dell'autenticazione biometrica necessita la sua app.
Archiviazione e condivisione sicure dei BLOB
Una nuova API denominata BlobstoreManager renderà più semplice e sicura la condivisione tra le app dei BLOB di dati. Google cita le app che condividono modelli di machine learning come caso d'uso ideale della nuova API BlobstoreManager.
Rafforzamento della piattaforma
Nel tentativo di ridurre la superficie di attacco di Android, Google utilizza Igienizzanti LLVM per identificare "bug di uso improprio della memoria e comportamenti indefiniti potenzialmente pericolosi". Google sta ora espandendo l’uso di questi disinfettanti basati su compilatore per diversi componenti critici per la sicurezza, tra cui BoundSan, IntSan, CFI e Shadow-Call Stack. Per individuare i problemi di memoria in produzione, Google sta abilitando "codifica del puntatore dell'heap" per tutte le app destinate ad Android 11 o versioni successive. Il tagging del puntatore heap è supportato sui dispositivi ARMv8 a 64 bit con supporto del kernel per ARM Top-byte Ignore (TBI), una funzionalità in cui "il l'hardware ignora il byte principale di un puntatore quando accede alla memoria." Google avverte gli sviluppatori che questi miglioramenti di rafforzamento potrebbero "si verificano arresti anomali delle app più ripetibili/riproducibili", quindi gli sviluppatori dovrebbero testare a fondo le loro app sul nuovo Android 11 Developer Anteprima. Per trovare e correggere molti errori di memoria nel sistema, Google ha utilizzato uno strumento di rilevamento degli errori di memoria chiamato AddressSanitizer assistito da hardware (HWASan). Google offre immagini di sistema predefinite abilitate per HWASan sul server di compilazione AOSP nel caso in cui tu sia interessato a trovare e correggere errori di memoria nelle tue app.
Google annuncerà sicuramente funzionalità aggiuntive per proteggere la privacy degli utenti e migliorare la sicurezza, quindi assicurati di tenere d'occhio la nostra copertura su Android 11 per rimanere aggiornato.
Novità su Android 11 su XDA