Google udgav den første Android 11 Developer Preview til Pixel 2, 3, 3a og 4. Her er alle de nye privatlivs- og sikkerhedsfunktioner, de annoncerede.
Forud for tidsplanen, Google i dag udgivet den første Developer Preview af den næste version af Android OS: Android 11. Systembilleder er tilgængelige for Pixel 2, Pixel 3, Pixel 3a, Pixel 4, men hvis du ikke ejer en af disse enheder, kan du også prøve Developer Preview via Android Studio-emulatoren eller det generiske system Billede. Selvom Google gemmer de fleste af de spændende nye bruger- og udviklerfunktioner til en storslået meddelelse på Google I/O 2020, har virksomheden delt et væld af ændringer, der er tilgængelige i den første Developer Preview. Her er en oversigt over alle de nye privatlivs- og sikkerhedsrelaterede funktioner, som Google har annonceret i Android 11 Developer Preview 1.
Android 11 Developer Preview 1 - Nye privatlivsfunktioner
Engangstilladelsesadgang
Android styrer, hvilke typer data-apps der kan få adgang til via dets tilladelsessystem. Før Android 6.0 Marshmallow anmodede apps om at få tilladelser ved installationen, så brugerne skulle beslutte, om de var okay med, at en app havde bestemte tilladelser, før de installerede den. Android 6.0 Marshmallow introducerede runtime-tilladelser for et udvalgt sæt følsomme tilladelser, herunder placeringsadgang, mikrofonadgang og kameraadgang. Kørselstilladelser kan kun tildeles efter installationen, og den app, der anmoder om dem, skal bede brugeren via en system-forsynet dialog for at tillade adgang. Endelig, i Android 10, introducerede Google en speciel version af runtime-tilladelsen, som tillader brugeren kun at give adgang, mens appen er i aktiv brug; Google introducerede dog kun muligheden "mens appen er i brug" for placeringstilladelsen.
I Android 11 giver Google brugerne mere finmasket kontrol over andre følsomme tilladelser, herunder kamera- og mikrofonadgang. Virksomheden har introduceret en ny "engangstilladelse"-funktion i Android 11 Developer Preview giver brugeren mulighed for midlertidigt at give en app adgang til en tilladelse, så længe den pågældende app er i forgrunden. Når brugeren navigerer væk fra appen, mister appen adgangen til denne tilladelse og skal anmode om den igen.
Omfanget lagerændringer
I Android 10 beta 2, foreslog Google en radikal ændring af den måde, apps får adgang til det eksterne lager på Android. (Ekstern lagring er her defineret som de data, der er synlige for brugeren og andre apps placeret i /data/media.) change, kaldet "Scoped Storage", havde til formål at eliminere den alt for brede brug af READ_EXTERNAL_STORAGE tilladelse. For mange apps i Google Play Butik anmodede om og fik adgang til hele det eksterne lager, hvor brugerne gemte deres private dokumenter, billeder, videoer og andre filer. Med Scoped Storage vil apps som standard kun få mulighed for at se deres private datamapper. Hvis en app har READ_EXTERNAL_STORAGE-tilladelsen under Scoped Storage-håndhævelse, kan den se visse mediefiler, der er tilgængelige via MediaStore API. Alternativt kan appen bruge Storage Access Framework til at få brugeren til manuelt at vælge filer gennem systemfilvælgeren. Endelig kan apps, der har brug for bred adgang til det eksterne lager, såsom filadministratorer, bruge Storage Access Framework til at anmode om brugeren til at give appen adgang til rodbiblioteket på det eksterne lager og derved give adgang til alle dets undermapper, også.
Håndhævelse af Scoped Storage var indstillet til at træde i kraft for alle apps i Android 10, men efter feedback og kritik fra udviklere, Google lempet ændringerne, der kun kræver dem for apps, der er målrettet mod API-niveau 29 (Android 10). Efter 1. august 2020 skal alle nye apps, der sendes til Google Play Butik, målrette mod Android 10, og det samme gælder for alle opdateringer til eksisterende apps efter 1. november 2020. Desuden, i Android 11, udviklere af filhåndteringsapps skal indsende en erklæringsblanket til Google for at få bred adgang til det eksterne lager; når de er accepteret, vil filhåndteringsapps have en ufiltreret visning af MediaStore, men vil ikke have adgang til eksterne app-mapper.
Derudover har Google introduceret andre ændringer til Scoped Storage i Android 11 Developer Preview. Apps kan tilmelde sig for at få råfilstien og udføre batch-redigeringshandlinger for mediefiler i MediaStore. DocumentsUI er blevet opdateret for at være enklere for brugerne. Disse ændringer blev annonceret kl Android Dev Summit sidste år, og vi er lovet yderligere forbedringer til Scoped Storage i fremtidige Android 11-udgivelser.
Android 11 Developer Preview 1 - Nye sikkerhedsfunktioner
Mobil kørekortsupport
Siden begyndelsen af sidste år har Google arbejdet på IdentityCredential API og HAL i AOSP. Denne funktion danner grundlaget for sikker opbevaring af identifikationsdokumenter på din mobile enhed, og især ISO 18013-5 kompatible mobile kørekort. Google officielt annoncerede denne funktion på Google I/O 2019, og nu er det endelig understøttet i Android 11 Developer Preview 1.
Google havde ikke meget at sige om denne funktion i pressemeddelelsen, men fordi funktionen udvikles i det fri, ved vi allerede meget af, hvad der er planlagt. Ved I/O 2019 oplyste Google, at de arbejdede sammen med ISO for at standardisere en implementering af elektroniske pas; vi har stadig ikke en anelse om, hvornår ePassports vil være tilgængelige, men der er allerede flere amerikanske stater, hvor eDL'er er implementeret eller er i prøvefasen. Google sagde også, at de arbejder på at levere et Jetpack-bibliotek, så udviklere kan oprette identitetsapps. Vi ved dog ikke, hvor hurtigt udviklere vil være i stand til at teste denne funktion, da korrekt support kræver sikker hardware på enheden. Det Sikker behandlingsenhed på Qualcomm Snapdragon 865 understøtter IdentityCredential API, selvom det muligvis ikke understøtter API's Direct Access-tilstand, da SPU'en er integreret i SoC'en; Direkte adgangstilstand ville give brugeren mulighed for at hente et lagret elektronisk ID, selv når der ikke er nok strøm til at starte Android. For mere information om denne API anbefaler jeg læser vores indledende dækning hvor Shawn Willden, lederen af Android-hardwarestøttet sikkerhedsteam, kom med sit input.
Nye projekthovedlinjemoduler
En af de største ændringer i Android 10 for nyligt lancerede enheder var introduktionen af Projekt Hovedlinje, som på trods af sit navn ikke har noget at gøre med at understøtte Linux-kernen på Android. (Dette projekt hedder i øvrigt Generic Kernel Image og er stadig et work-in-progress.) Formålet med Project Mainline er i stedet for Google vil fravriste OEM'er kontrollen over nøglerammekomponenter og systemapplikationer. Hvert hovedlinjemodul er indkapslet som enten en APK eller en APEX fil og kan opdateres af Google via Play Butik. Brugeren ser opdateringer som en "Google Play System Update" (GPSU) på deres enhed, og opdateringer udgives på en almindelig kadence som et tog (dvs. de downloades og installeres på samme tid).
Google påbyder medtagelsen af specifikke Mainline-moduler, som på tidspunktet for Google I/O 2019 omfattede 13. Nu kræver Google i alt 20 hovedmoduler i Android 11 Developer Preview 1.
Indledende hovedlinjemoduler (@ Google I/O 2019) |
Aktuelle hovedlinjemoduler (til Android 11 Developer Preview 1)* |
---|---|
VINKEL |
Captive Portal Login |
Captive Portal Login |
Conscrypt |
Conscrypt |
DNS-resolver |
DNS-resolver |
Dokumenter UI |
Dokumenter UI |
ExtServices |
ExtServices |
Medie-codecs |
Medie-codecs |
Medierammekomponenter |
Medierammekomponenter |
Modul metadata |
Modul metadata |
Netværksstak |
Netværksstak |
Konfiguration af netværksstaktilladelse |
Konfiguration af netværksstaktilladelse |
Tilladelseskontrollant |
Tilladelseskontrollant |
Tidszonedata |
Tidszonedata |
Nyt tilladelsesmodul |
Nyt medieudbydermodul | |
Nyt neurale netværk API (NNAPI) modul |
*Bemærk: på udgivelsestidspunktet har Google ikke givet os den fulde liste over hovedlinjemoduler, som er nødvendige i øjeblikket. Vi opdaterer denne tabel, når vi har den fulde liste.
Biometriske promptændringer
Android 9 Pie introduceret BiometricPrompt API, en samlet API til biometrisk godkendelseshardware. API'en giver udviklere en måde at udfordre brugeren gennem deres gemte biometri, uanset om det er fingeraftryk, ansigt eller iris. Før BiometricPrompt skulle udviklere oprette deres egen autentificeringsdialog og bruge FingerprintManager API, som kun understøttede fingeraftryksgodkendelse, for at udfordre brugeren. På Galaxy-smartphones med iris-scannere skulle udviklere bruge Samsungs SDK for at udfordre brugeren. Med BiometricPrompt kan udviklere udfordre brugeren med enhver understøttet biometrisk metode, og systemet leverer dialogen til brugeren. Udviklere behøver således ikke længere bekymre sig om specifikt at yde support til en bestemt slags biometrisk hardware, og de behøvede heller ikke længere at kode brugergrænsefladen til autentificeringsdialogen. Det Pixel 4s sikre ansigtsgenkendelseshardware, kan for eksempel bruges til godkendelse i apps, der bruger BiometricPrompt.
Hvad er nyt for BiometricPrompt i Android 11 Developer Preview 1? Google har tilføjet 3 nye godkendelsestyper: stærk, svag og enhedslegitimationsoplysninger. Før Android 11 kunne udviklere kun forespørge på enhedens sikre biometriske hardware – fingeraftryksscanner, 3D ansigtsgenkendelsesscanner eller irisscanner – når de brugte BiometricPrompt. Fra Android 11 Developer Preview 1 kan udviklere også forespørge på biometriske metoder, der anses for "svage", såsom de softwarebaserede ansigtsgenkendelsesløsninger, der findes på mange telefoner. For eksempel Google tidligere sortlistet flere Samsung Galaxy-telefoner for at returnere en svag ansigtsgenkendelses-autentificering, når du forsøger krypto-baseret godkendelse. Det er nu op til udvikleren at beslutte, hvilket niveau af biometrisk godkendelsesgranularitet deres app har brug for.
Sikker opbevaring og deling af BLOB'er
En ny API kaldet BlobstoreManager vil gøre det nemmere og mere sikkert for apps at dele data-blobs med hinanden. Google nævner apps, der deler maskinlæringsmodeller, som en ideel anvendelse af den nye BlobstoreManager API.
Platformhærdning
I et forsøg på at reducere angrebsfladen på Android, bruger Google LLVM desinfektionsmidler at identificere "fejl i hukommelsesmisbrug og potentielt farlig udefineret adfærd." Google udvider nu brugen af disse compiler-baserede desinfektionsmidler til flere sikkerhedskritiske komponenter, herunder BoundSan, IntSan, CFI og Shadow-Call Stack. For at fange hukommelsesproblemer i produktionen aktiverer Google "heap pointer tagging" for alle apps, der er målrettet mod Android 11 eller nyere. Heap pointer tagging understøttes på ARMv8 64-bit enheder med kerneunderstøttelse af ARM Top-byte Ignore (TBI), en funktion, hvor "den hardware ignorerer den øverste byte af en markør, når den får adgang til hukommelsen." Google advarer udviklere om, at disse hærdende forbedringer kan "oplev mere repeterbare/reproducerbare appnedbrud", så udviklere bør grundigt teste deres apps på den nye Android 11-udvikler Forhåndsvisning. For at finde og rette mange hukommelsesfejl i systemet brugte Google et værktøj til registrering af hukommelsesfejl kaldet hardware-assisteret AddressSanitizer (HVASan). Google tilbyder HWASan-aktiverede forudbyggede systembilleder på AOSP build-serveren hvis du er interesseret i at finde og rette hukommelsesfejl i dine egne apps.
Google vil helt sikkert annoncere yderligere funktioner til at beskytte brugernes privatliv og forbedre sikkerheden, så sørg for at holde øje med vores Android 11-dækning for at holde dig opdateret.
Android 11 Nyheder på XDA