Google ga ut den første Android 11 Developer Preview for Pixel 2, 3, 3a og 4. Her er alle de nye personvern- og sikkerhetsfunksjonene de annonserte.
Forut for skjema, Google lanserte i dag den første forhåndsvisningen for utviklere av neste versjon av Android OS: Android 11. Systembilder er tilgjengelige for Pixel 2, Pixel 3, Pixel 3a, Pixel 4, men hvis du ikke eier en av disse enheter, kan du også prøve utviklerforhåndsvisningen via Android Studio-emulatoren eller det generiske systemet Bilde. Selv om Google lagrer det meste av de spennende nye bruker- og utviklerfunksjonene for en storslått kunngjøring på Google I/O 2020, har selskapet delt en mengde endringer som er tilgjengelige i den første utviklerforhåndsvisningen. Her er et sammendrag av alle de nye personvern- og sikkerhetsrelaterte funksjonene som Google har annonsert i Android 11 Developer Preview 1.
Android 11 Developer Preview 1 – Nye personvernfunksjoner
Engangstilgang til tillatelse
Android kontrollerer hva slags dataapper kan få tilgang til gjennom tillatelsessystemet. Før Android 6.0 Marshmallow ba apper om å få tillatelser ved installasjonen, så brukere måtte bestemme om de var greit med en app som hadde visse tillatelser før de installerte den. Android 6.0 Marshmallow introduserte kjøretidstillatelser for et utvalgt sett med sensitive tillatelser, inkludert posisjonstilgang, mikrofontilgang og kameratilgang. Kjøretidstillatelser kan bare gis etter installasjonen, og appen som ber om dem må spørre brukeren gjennom en dialogboks for å tillate tilgang. Til slutt, i Android 10, introduserte Google en spesiell versjon av kjøretidstillatelsen som lar brukeren bare gi tilgang mens appen er i aktiv bruk; Google introduserte imidlertid bare alternativet "mens appen er i bruk" for plasseringstillatelsen.
I Android 11 gir Google brukere mer finmasket kontroll over andre sensitive tillatelser, inkludert tilgang til kamera og mikrofon. Selskapet har introdusert en ny "engangstillatelse"-funksjon i Android 11 Developer Preview som lar brukeren midlertidig gi en app tilgang til en tillatelse så lenge den appen er i forgrunnen. Når brukeren navigerer bort fra appen, mister appen tilgangen til den tillatelsen og må be om den på nytt.
Omfanget lagringsendringer
I Android 10 beta 2, foreslo Google en radikal endring i måten apper får tilgang til ekstern lagring på Android. (Ekstern lagring, her, er definert som data som er synlig for brukeren og andre apper som ligger i /data/media.) change, kalt «Scoped Storage», var rettet mot å eliminere den altfor brede bruken av READ_EXTERNAL_STORAGE tillatelse. For mange apper i Google Play-butikken ba om og ble gitt tilgang til hele den eksterne lagringen der brukere lagret sine private dokumenter, bilder, videoer og andre filer. Med Scoped Storage vil apper som standard bare få muligheten til å se deres private datakataloger. Hvis en app har READ_EXTERNAL_STORAGE-tillatelsen under Scoped Storage-håndhevelse, kan den se visse mediefiler som er tilgjengelige via MediaStore API. Alternativt kan appen bruke Storage Access Framework for å få brukeren til å velge filer manuelt gjennom systemfilvelgeren. Endelig kan apper som trenger bred tilgang til ekstern lagring, for eksempel filbehandlere, bruke Storage Access Framework for å be om brukeren skal gi appen tilgang til rotkatalogen til den eksterne lagringen, og dermed gi tilgang til alle underkatalogene, også.
Enforcement of Scoped Storage ble satt til å tre i kraft for alle apper i Android 10, men etter tilbakemeldinger og kritikk fra utviklere, Google avslappet endringene, krever dem bare for apper som målretter mot API-nivå 29 (Android 10). Etter 1. august 2020 må alle nye apper som sendes til Google Play Store målrettes mot Android 10, og det samme gjelder for alle oppdateringer til eksisterende apper etter 1. november 2020. Videre, i Android 11, utviklere av filbehandlingsapper må levere erklæringsskjema til Google for å få bred tilgang til den eksterne lagringen; Når de er akseptert, vil filbehandlingsapper ha en ufiltrert visning av MediaStore, men vil ikke ha tilgang til eksterne appkataloger.
I tillegg har Google introdusert andre endringer i Scoped Storage i Android 11 Developer Preview. Apper kan velge å få råfilbanen og utføre batch-redigeringsoperasjoner for mediefiler i MediaStore. DocumentsUI har blitt oppdatert for å være enklere for brukere. Disse endringene ble annonsert på Android Dev Summit i fjor, og vi er lovet ytterligere forbedringer av Scoped Storage i fremtidige Android 11-utgivelser.
Android 11 Developer Preview 1 – Nye sikkerhetsfunksjoner
Støtte for mobil førerlisens
Siden tidlig i fjor har Google jobbet med IdentityCredential API og HAL i AOSP. Denne funksjonen legger grunnlaget for sikker lagring av identifikasjonsdokumenter på din mobile enhet, og spesielt ISO 18013-5 kompatible mobile førerkort. Google offisielt kunngjorde denne funksjonen på Google I/O 2019, og nå støttes den endelig i Android 11 Developer Preview 1.
Google hadde ikke så mye å si om denne funksjonen i pressemeldingen, men fordi funksjonen utvikles i det fri, vet vi allerede mye av det som er planlagt. På I/O 2019 uttalte Google at de jobbet med ISO for å standardisere en implementering av elektroniske pass; vi har fortsatt ikke en anelse om når e-pass vil være tilgjengelig, men det er allerede flere amerikanske stater der eDL-er er implementert eller er i prøvefasen. Google sa også at de jobber med å tilby et Jetpack-bibliotek slik at utviklere kan lage identitetsapper. Vi vet imidlertid ikke hvor snart utviklere vil kunne teste denne funksjonen, siden riktig støtte krever sikker maskinvare på enheten. De Sikker behandlingsenhet på Qualcomm Snapdragon 865 støtter IdentityCredential API, selv om det kanskje ikke støtter APIs Direct Access-modus siden SPU er integrert i SoC; Direct Access-modus vil tillate brukeren å hente en lagret elektronisk ID selv når det ikke er nok strøm til å starte Android. For mer informasjon om dette API anbefaler jeg lese vår første dekning der Shawn Willden, lederen for Android-maskinvarestøttet sikkerhetsteam, kom med sine innspill.
Nye prosjekthovedlinjemoduler
En av de største endringene i Android 10 for nylanserte enheter var introduksjonen av Prosjekt hovedlinje, som til tross for navnet, ikke har noe å gjøre med å støtte hovedlinjen Linux-kjernen på Android. (Det prosjektet heter forresten Generic Kernel Image og er fortsatt et arbeid som pågår.) I stedet er formålet med Project Mainline for Google vil fjerne kontrollen over nøkkelrammekomponenter og systemapplikasjoner fra OEM-er. Hver hovedlinjemodul er innkapslet som enten en APK eller en APEX-fil og kan oppdateres av Google via Play Store. Brukeren ser på oppdateringer som en "Google Play System Update" (GPSU) på enheten sin, og oppdateringer utgis på en vanlig tråkkfrekvens som et tog (dvs. de lastes ned og installeres samtidig).
Google krever inkludering av spesifikke hovedlinjemoduler, som på tidspunktet for Google I/O 2019 inkluderte 13. Nå krever Google totalt 20 hovedlinjemoduler i Android 11 Developer Preview 1.
Innledende hovedlinjemoduler (@ Google I/O 2019) |
Gjeldende hovedlinjemoduler (for Android 11 Developer Preview 1)* |
---|---|
VINKEL |
Captive Portal-pålogging |
Captive Portal-pålogging |
Conscrypt |
Conscrypt |
DNS-løser |
DNS-løser |
Dokumenter UI |
Dokumenter UI |
ExtServices |
ExtServices |
Mediekodeker |
Mediekodeker |
Medierammeverkskomponenter |
Medierammeverkskomponenter |
Modul metadata |
Modul metadata |
Nettverksstabel |
Nettverksstabel |
Konfigurasjon av nettverksstabeltillatelse |
Konfigurasjon av nettverksstabeltillatelse |
Tillatelseskontrollør |
Tillatelseskontrollør |
Tidssonedata |
Tidssonedata |
Ny tillatelsesmodul |
Ny medieleverandørmodul | |
Ny modul for nevrale nettverk API (NNAPI). |
*Merk: på publiseringstidspunktet har ikke Google gitt oss den fullstendige listen over hovedlinjemoduler som er nødvendige for øyeblikket. Vi vil oppdatere denne tabellen når vi har den fullstendige listen.
Biometriske spørreendringer
Android 9 Pie introdusert BiometricPrompt API, en enhetlig API for biometrisk autentiseringsmaskinvare. API-en gir utviklere en måte å utfordre brukeren gjennom deres lagrede biometri, enten det er fingeravtrykk, ansikt eller iris. Før BiometricPrompt måtte utviklere lage sin egen autentiseringsdialog og bruke FingerprintManager API, som kun støttet fingeravtrykkautentisering, for å utfordre brukeren. På Galaxy-smarttelefoner med irisskannere måtte utviklere bruke Samsungs SDK for å utfordre brukeren. Med BiometricPrompt kan utviklere utfordre brukeren med hvilken som helst støttet biometrisk metode, og systemet gir brukeren dialogen. Dermed trenger ikke utviklere lenger å bekymre seg for spesifikt å gi støtte for en bestemt type biometrisk maskinvare, og de trengte heller ikke lenger å kode brukergrensesnittet for autentiseringsdialogen. De Pixel 4s sikre maskinvare for ansiktsgjenkjenning, for eksempel, kan brukes til autentisering i apper som bruker BiometricPrompt.
Hva er nytt for BiometricPrompt i Android 11 Developer Preview 1? Google har lagt til tre nye autentiseringstyper: sterk, svak og enhetslegitimasjon. Før Android 11 kunne utviklere bare spørre enhetens sikre biometriske maskinvare – fingeravtrykkskanner, 3D ansiktsgjenkjenningsskanner eller irisskanner – når de brukte BiometricPrompt. Fra og med Android 11 Developer Preview 1 kan utviklere også spørre etter biometriske metoder som anses som "svake", for eksempel programvarebaserte ansiktsgjenkjenningsløsninger som finnes på mange telefoner. For eksempel Google tidligere svartelistet flere Samsung Galaxy-telefoner for å returnere en svak ansiktsgjenkjenningsautentisering ved forsøk på kryptobasert autentisering. Det er nå opp til utvikleren å bestemme hvilket nivå av biometrisk autentiseringsgranularitet appen deres trenger.
Sikker lagring og deling av BLOB-er
Et nytt API kalt BlobstoreManager vil gjøre det enklere og sikrere for apper å dele datablobber med hverandre. Google nevner apper som deler maskinlæringsmodeller som et ideelt bruksområde for den nye BlobstoreManager API.
Herding av plattform
I et forsøk på å redusere angrepsoverflaten til Android, bruker Google LLVM desinfeksjonsmidler for å identifisere "minnemisbruksfeil og potensielt farlig udefinert oppførsel." Google utvider nå bruken av disse kompilatorbaserte rensemidler til flere sikkerhetskritiske komponenter, inkludert BoundSan, IntSan, CFI og Shadow-Call Stack. For å fange opp minneproblemer i produksjonen, aktiverer Google "haugpekermerking" for alle apper som er målrettet mot Android 11 eller nyere. Heap pointer tagging støttes på ARMv8 64-bits enheter med kjernestøtte for ARM Top-byte Ignore (TBI), en funksjon der "den maskinvare ignorerer den øverste byten til en peker når den får tilgang til minne." Google advarer utviklere om at disse forsterkningsforbedringene kan «opplev mer repeterbare/reproduserbare appkrasj», så utviklere bør teste appene sine grundig på den nye Android 11-utvikleren Forhåndsvisning. For å finne og fikse mange minnefeil i systemet, brukte Google et minnefeildeteksjonsverktøy kalt maskinvareassistert AddressSanitizer (HVASan). Google tilbyr HWASan-aktiverte forhåndsbygde systembilder på AOSP-byggserveren i tilfelle du er interessert i å finne og fikse minnefeil i dine egne apper.
Google kommer garantert til å kunngjøre flere funksjoner for å beskytte brukernes personvern og forbedre sikkerheten, så sørg for å holde øye med Android 11-dekningen vår for å holde deg oppdatert.
Android 11 Nyheter på XDA