Previzualizare pentru dezvoltatori Android 11: Toate noile funcții de confidențialitate și securitate

Google a lansat primul Android 11 Developer Preview pentru Pixel 2, 3, 3a și 4. Iată toate noile funcții de confidențialitate și securitate pe care le-au anunțat.

Înainte de termen, Google astăzi a lansat primul Developer Preview a următoarei versiuni a sistemului de operare Android: Android 11. Imaginile de sistem sunt disponibile pentru Pixel 2, Pixel 3, Pixel 3a, Pixel 4, dar dacă nu dețineți una dintre acestea dispozitive, puteți încerca și Previzualizarea dezvoltatorului prin emulatorul Android Studio sau sistemul generic Imagine. Deși Google salvează majoritatea noilor funcții interesante pentru utilizatori și dezvoltatori pentru un anunț măreț la Google I/O 2020, compania a împărtășit o multitudine de modificări care sunt disponibile în prima Previzualizare pentru dezvoltatori. Iată un rezumat al tuturor noilor funcții legate de confidențialitate și securitate pe care Google le-a anunțat în Android 11 Developer Preview 1.

Previzualizarea dezvoltatorului Android 11 1 - Noi funcții de confidențialitate

Acces o singură dată cu permisiunea

Android controlează ce tipuri de aplicații de date pot accesa prin sistemul său de permisiuni. Înainte de Android 6.0 Marshmallow, aplicațiile solicitau să li se acorde permisiuni la instalare, așa că utilizatorii trebuiau să decidă dacă sunt de acord ca o aplicație să aibă anumite permisiuni înainte de a o instala. Android 6.0 Marshmallow a introdus permisiuni de rulare pentru un set select de permisiuni sensibile, inclusiv acces la locație, acces la microfon și acces la cameră. Permisiunile de rulare pot fi acordate numai după instalare, iar aplicația care le solicită trebuie să solicite utilizatorului printr-un dialog furnizat de sistem pentru a permite accesul. În cele din urmă, în Android 10, Google a introdus o versiune specială a permisiunii de rulare care permite utilizatorului să acorde acces numai în timp ce aplicația este în uz activ; cu toate acestea, Google a introdus doar opțiunea „în timp ce aplicația este în uz” pentru permisiunea de locație.

În Android 11, Google oferă utilizatorilor un control mai precis asupra altor permisiuni sensibile, inclusiv accesul la cameră și microfon. Compania a introdus o nouă funcție de „permisiune unică” în Android 11 Developer Preview permite utilizatorului să acorde temporar unei aplicații acces la o permisiune atâta timp cât acea aplicație se află în prim plan. Odată ce utilizatorul navighează departe de aplicație, aplicația pierde accesul la acea permisiune și trebuie să o solicite din nou.

Modificări în domeniul de stocare

În Android 10 beta 2, Google a propus o schimbare radicală a modului în care aplicațiile accesează stocarea externă pe Android. (Stocarea externă, aici, este definită ca datele vizibile pentru utilizator și alte aplicații situate în /data/media.) modificarea, denumită „Scoped Storage”, a avut ca scop eliminarea utilizării prea largă a READ_EXTERNAL_STORAGE permisiune. Prea multe aplicații din Magazinul Google Play solicitau și li se acorda acces la întreaga stocare externă în care utilizatorii își salvau documentele private, fotografiile, videoclipurile și alte fișiere. Cu Scoped Storage, aplicațiilor li se va acorda, în mod implicit, doar capacitatea de a-și vedea directoarele de date private. Dacă o aplicație deține permisiunea READ_EXTERNAL_STORAGE în conformitate cu aplicarea spațiului de stocare, atunci poate vizualiza anumite fișiere media accesibile prin API-ul MediaStore. În mod alternativ, aplicația poate folosi Storage Access Framework pentru ca utilizatorul să selecteze manual fișierele prin selectorul de fișiere de sistem. În cele din urmă, aplicațiile care au nevoie de acces larg la stocarea externă, cum ar fi managerii de fișiere, pot folosi cadrul de acces la stocare pentru a solicita utilizatorul să acorde aplicației acces la directorul rădăcină al stocării externe, acordând astfel acces la toate subdirectoarele sale, de asemenea.

Aplicarea spațiului de stocare a fost setată să intre în vigoare pentru toate aplicațiile din Android 10, dar după feedback și critici din partea dezvoltatorilor, Google a relaxat schimbările, fiind necesare doar pentru aplicațiile care vizează nivelul API 29 (Android 10). După 1 august 2020, toate aplicațiile noi trimise către Magazinul Google Play trebuie să vizeze Android 10 și același lucru este valabil pentru toate actualizările aplicațiilor existente după 1 noiembrie 2020. În plus, în Android 11, dezvoltatorii de aplicații de gestionare a fișierelor trebuie să depună un formular de declarație la Google pentru a avea acces larg la stocarea externă; odată acceptate, aplicațiile de gestionare a fișierelor vor avea o vizualizare nefiltrată a MediaStore, dar nu vor avea acces la directoarele externe de aplicații.

În plus, Google a introdus și alte modificări la Scoped Storage în Android 11 Developer Preview. Aplicațiile se pot înscrie pentru a obține calea fișierului brut și pentru a efectua operațiuni de editare în lot pentru fișierele media din MediaStore. DocumentsUI a fost actualizat pentru a fi mai simplu pentru utilizatori. Aceste modificări au fost anunțate la Android Dev Summit anul trecut și ni s-au promis îmbunătățiri suplimentare pentru Scoped Storage în viitoarele versiuni Android 11.

Previzualizarea dezvoltatorului Android 11 1 - Noi funcții de securitate

Asistență pentru licență de conducere mobilă

De la începutul anului trecut, Google a lucrat la IdentityCredential API și HAL în AOSP. Această caracteristică pune bazele pentru stocarea în siguranță a documentelor de identificare pe dispozitivul dvs. mobil și, în special, a permiselor de conducere mobile conforme cu ISO 18013-5. Google oficial a anunțat această funcție la Google I/O 2019, iar acum este în sfârșit acceptat în Android 11 Developer Preview 1.

Google nu a avut multe de spus despre această caracteristică în comunicatul de presă, dar pentru că caracteristica este dezvoltată în mod deschis, știm deja multe despre ceea ce este planificat. La I/O 2019, Google a declarat că lucrează cu ISO pentru a standardiza o implementare a pașapoartelor electronice; încă nu știm când vor fi disponibile pașapoartele electronice, dar există deja mai multe state din S.U.A. unde eDL-urile sunt implementate sau sunt în faza de încercare. Google a mai spus că lucrează pentru a oferi o bibliotecă Jetpack, astfel încât dezvoltatorii să poată crea aplicații de identitate. Cu toate acestea, nu știm cât de curând dezvoltatorii vor putea testa această caracteristică, deoarece suportul adecvat necesită hardware securizat pe dispozitiv. The Unitate de procesare securizată pe Qualcomm Snapdragon 865 acceptă API-ul IdentityCredential, deși este posibil să nu accepte modul de acces direct al API, deoarece SPU este integrat în SoC; Modul Acces Direct ar permite utilizatorului să scoată un ID electronic stocat chiar și atunci când nu există suficientă putere pentru a porni Android. Pentru mai multe informații despre acest API, recomand citind acoperirea noastră inițială unde Shawn Willden, liderul echipei de securitate cu suport hardware Android, și-a oferit contribuția.

Noi module principale ale proiectului

Una dintre cele mai mari schimbări în Android 10 pentru dispozitivele nou lansate a fost introducerea Linia principală a proiectului, care în ciuda numelui său, nu are nimic de-a face cu suportarea nucleului principal Linux pe Android. (Proiectul respectiv, de altfel, se numește Generic Kernel Image și este încă un lucru în curs.) În schimb, scopul proiectului Mainline este pentru Google va prelua controlul asupra componentelor cheie ale cadrului și aplicațiilor de sistem de la OEM. Fiecare modul Mainline este încapsulat fie ca APK sau un fișier APEX și poate fi actualizat de Google prin Magazinul Play. Utilizatorul vede actualizările ca o „Actualizare a sistemului Google Play” (GPSU) pe dispozitivul său, iar actualizările sunt lansate cu o cadență obișnuită ca un tren (de ex. sunt descărcate și instalate în același timp).

Beneficiile Project Mainline. Sursa: Google.

Google impune includerea unor module Mainline specifice, care la momentul Google I/O 2019, includeau 13. Acum, Google impune un total de 20 de module Mainline în Android 11 Developer Preview 1.

Modulele principale inițiale (@ Google I/O 2019)

Modulele curente principale (pentru Android 11 Developer Preview 1)*

UNGHI

Conectare la portalul captiv

Conectare la portalul captiv

Conscript

Conscript

Rezolvare DNS

Rezolvare DNS

Interfața de utilizare pentru documente

Interfața de utilizare pentru documente

ExtServices

ExtServices

Codecuri media

Codecuri media

Componentele cadrului media

Componentele cadrului media

Metadatele modulului

Metadatele modulului

Stiva de rețea

Stiva de rețea

Configurarea permisiunii stivei de rețea

Configurarea permisiunii stivei de rețea

Controller de permisiuni

Controller de permisiuni

Date de fus orar

Date de fus orar

Modul de permisiuni nou

Noul modul furnizor media

Noul modul API de rețele neuronale (NNAPI).

*Notă: la momentul publicării, Google nu ne-a furnizat lista completă a modulelor Mainline care sunt necesare în prezent. Vom actualiza acest tabel odată ce vom avea lista completă.

Modificări biometrice prompte

A fost introdus Android 9 Pie API-ul BiometricPrompt, un API unificat pentru hardware-ul de autentificare biometrică. API-ul oferă dezvoltatorilor o modalitate de a provoca utilizatorul prin datele biometrice salvate, fie că este amprenta digitală, față sau iris. Înainte de BiometricPrompt, dezvoltatorii trebuiau să-și creeze propriul dialog de autentificare și să folosească API-ul FingerprintManager, care accepta doar autentificarea cu amprentă, pentru a provoca utilizatorul. Pe smartphone-urile Galaxy cu scanere iris, dezvoltatorii au trebuit să folosească SDK-ul Samsung pentru a provoca utilizatorul. Cu BiometricPrompt, dezvoltatorii pot provoca utilizatorul cu orice metodă biometrică acceptată, iar sistemul oferă utilizatorului dialogul. Astfel, dezvoltatorii nu mai trebuie să-și facă griji cu privire la furnizarea de suport în mod specific pentru un anumit tip de hardware biometric și, de asemenea, nu mai trebuiau să codifice interfața de utilizare pentru dialogul de autentificare. The Hardware-ul securizat de recunoaștere facială al Pixel 4, de exemplu, poate fi folosit pentru autentificare în aplicațiile care folosesc BiometricPrompt.

Autentificare facială folosind BiometricPrompt.

Ce este nou pentru BiometricPrompt în Android 11 Developer Preview 1? Google a adăugat 3 noi tipuri de autentificare: autentificare puternică, slabă și dispozitiv. Înainte de Android 11, dezvoltatorii puteau interoga doar hardware-ul biometric securizat al dispozitivului - scaner de amprentă, scaner de recunoaștere facială 3D sau scaner de iris - atunci când foloseau BiometricPrompt. Începând cu Android 11 Developer Preview 1, dezvoltatorii pot interoga și metode biometrice considerate „slabe”, cum ar fi soluțiile de recunoaștere facială bazate pe software găsite pe multe telefoane. De exemplu, Google a trecut anterior pe lista neagră a mai multor telefoane Samsung Galaxy pentru returnarea unui autentificator de recunoaștere facială slab atunci când încercați o autentificare bazată pe cripto. Acum depinde de dezvoltator să decidă de ce nivel de granularitate a autentificării biometrice are nevoie aplicația lor.

Stocarea și partajarea în siguranță a BLOB-urilor

Un nou API numit BlobstoreManager va face mai ușor și mai sigur pentru aplicații să partajeze blob-uri de date între ele. Google citează aplicațiile care partajează modele de învățare automată ca un caz de utilizare ideal al noului API BlobstoreManager.

Întărirea platformei

În efortul de a reduce suprafața de atac a Android, Google folosește Dezinfectante LLVM pentru a identifica „erori de utilizare greșită a memoriei și comportament nedefinit potențial periculos”. Google extinde acum utilizarea acestora dezinfectante bazate pe compilator la mai multe componente critice pentru securitate, inclusiv BoundSan, IntSan, CFI și Shadow-Call Stack. Pentru a detecta problemele de memorie în producție, Google activează „etichetarea indicatorului heap„ pentru toate aplicațiile care vizează Android 11 sau o versiune ulterioară. Etichetarea pointerului heap este acceptată pe dispozitivele ARMv8 pe 64 de biți cu suport nucleu pentru Ignorare ARM Top-byte (TBI), o caracteristică în care „ hardware-ul ignoră octetul superior al unui pointer atunci când accesează memorie.” Google avertizează dezvoltatorii că aceste îmbunătățiri de întărire pot „Apar mai multe blocări repetabile/reproducibile ale aplicațiilor”, așa că dezvoltatorii ar trebui să-și testeze temeinic aplicațiile pe noul dezvoltator Android 11 Previzualizare. Pentru a găsi și a remedia multe erori de memorie din sistem, Google a folosit un instrument de detectare a erorilor de memorie numit AddressSanitizer asistat de hardware (HWASan). Google oferă imagini de sistem prefabricate compatibile cu HWASan pe serverul de compilare AOSP în cazul în care sunteți interesat să găsiți și să remediați erorile de memorie în propriile aplicații.


Google va anunța cu siguranță funcții suplimentare pentru a proteja confidențialitatea utilizatorilor și pentru a îmbunătăți securitatea, așa că asigurați-vă că fiți cu ochii pe acoperirea noastră Android 11 pentru a rămâne la curent.

Știri Android 11 pe XDA