Android 11 Developer Preview: Alla nya sekretess- och säkerhetsfunktioner

Före schemat, Google släppte idag den första Developer Preview av nästa version av Android OS: Android 11. Systembilder är tillgängliga för Pixel 2, Pixel 3, Pixel 3a, Pixel 4, men om du inte äger en av dessa enheter kan du också prova utvecklarförhandsvisningen via Android Studio-emulatorn eller det allmänna systemet Bild. Även om Google sparar de flesta spännande nya användar- och utvecklarfunktioner för ett stort tillkännagivande på Google I/O 2020, har företaget delat med sig av en uppsjö av ändringar som är tillgängliga i den första förhandsgranskningen av utvecklare. Här är en sammanfattning av alla nya sekretess- och säkerhetsrelaterade funktioner som Google har tillkännagivit i Android 11 Developer Preview 1.

Android 11 Developer Preview 1 - Nya sekretessfunktioner

Engångsbehörighetsåtkomst

Android styr vilka typer av dataappar som kan komma åt genom sitt behörighetssystem. Innan Android 6.0 Marshmallow begärde appar att få tillstånd vid installationen, så användare var tvungna att bestämma om de var okej med att en app hade vissa behörigheter innan de installerade den. Android 6.0 Marshmallow introducerade runtime-behörigheter för en utvald uppsättning känsliga behörigheter, inklusive platsåtkomst, mikrofonåtkomst och kameraåtkomst. Körtidsbehörigheter kan endast beviljas efter installationen, och appen som begär dem måste uppmana användaren via en dialogruta som tillhandahålls av systemet för att tillåta åtkomst. Slutligen, i Android 10, introducerade Google en speciell version av runtime-behörigheten som tillåter användaren att endast bevilja åtkomst medan appen är i aktiv användning; Google introducerade dock bara alternativet "medan appen används" för platsbehörighet.

I Android 11 ger Google användarna mer finkornig kontroll över andra känsliga behörigheter, inklusive åtkomst till kamera och mikrofon. Företaget har introducerat en ny "engångsbehörighet"-funktion i Android 11 Developer Preview som tillåter användaren att tillfälligt ge en app åtkomst till en behörighet så länge den appen finns i förgrund. När användaren navigerar bort från appen förlorar appen åtkomst till den behörigheten och måste begära den igen.

Omfattning lagringsändringar

I Android 10 beta 2, föreslog Google en radikal förändring av hur appar kommer åt den externa lagringen på Android. (Extern lagring definieras här som data som är synlig för användaren och andra appar som finns i /data/media.) change, kallad "Scoped Storage", syftade till att eliminera den alltför breda användningen av READ_EXTERNAL_STORAGE lov. För många appar i Google Play Butik begärde och beviljades åtkomst till hela den externa lagringen där användare sparade sina privata dokument, foton, videor och andra filer. Med Scoped Storage skulle appar, som standard, endast ges möjlighet att se sina privata datakataloger. Om en app har behörigheten READ_EXTERNAL_STORAGE under tillämpning av Scoped Storage, kan den se vissa mediefiler som är tillgängliga via MediaStore API. Alternativt kan appen använda Storage Access Framework för att låta användaren manuellt välja filer via systemfilväljaren. Slutligen kan appar som behöver bred åtkomst till den externa lagringen, såsom filhanterare, använda Storage Access Framework för att begära användaren att ge appen åtkomst till rotkatalogen för den externa lagringen och därigenom ge åtkomst till alla dess underkataloger, för.

Tillämpning av lagring med omfattning var inställd att träda i kraft för alla appar i Android 10, men efter feedback och kritik från utvecklare, Google mildrade förändringarna, kräver dem bara för appar som är inriktade på API-nivå 29 (Android 10). Efter 1 augusti 2020 måste alla nya appar som skickas till Google Play Butik riktas mot Android 10, och detsamma gäller för alla uppdateringar av befintliga appar efter 1 november 2020. Dessutom, i Android 11, utvecklare av filhanterarappar måste lämna in en deklarationsblankett till Google för att få bred åtkomst till den externa lagringen; när de har godkänts kommer filhanterarens appar att ha en ofiltrerad vy av MediaStore men kommer inte att ha tillgång till externa appkataloger.

Dessutom har Google infört andra ändringar av Scoped Storage i Android 11 Developer Preview. Appar kan välja att få råfilsökvägen och utföra batchredigeringsoperationer för mediefiler i MediaStore. DocumentsUI har uppdaterats för att vara enklare för användarna. Dessa ändringar tillkännagavs vid Android Dev Summit förra året, och vi utlovas ytterligare förbättringar av Scoped Storage i framtida Android 11-utgåvor.

Android 11 Developer Preview 1 - Nya säkerhetsfunktioner

Mobil körkortssupport

Sedan början av förra året har Google arbetat med IdentityCredential API och HAL i AOSP. Den här funktionen lägger grunden för att säkert lagra identifieringsdokument på din mobila enhet, och i synnerhet ISO 18013-5-kompatibla mobila körkort. Google officiellt tillkännagav den här funktionen på Google I/O 2019, och nu stöds det äntligen i Android 11 Developer Preview 1.

Google hade inte så mycket att säga om den här funktionen i pressmeddelandet, men eftersom funktionen utvecklas i det fria vet vi redan mycket av vad som är planerat. Vid I/O 2019 uppgav Google att de arbetade med ISO för att standardisera en implementering av elektroniska pass; vi har fortfarande inte en aning om när e-pass kommer att finnas tillgängliga, men det finns redan flera delstater i USA där eDL: er är implementerade eller är i testfasen. Google sa också att de arbetar för att tillhandahålla ett Jetpack-bibliotek så att utvecklare kan skapa identitetsappar. Vi vet dock inte hur snart utvecklare kommer att kunna testa den här funktionen, eftersom korrekt support kräver säker hårdvara på enheten. De Säker processorenhet på Qualcomm Snapdragon 865 stöder IdentityCredential API, även om det kanske inte stöder API: s Direct Access-läge eftersom SPU: n är integrerad i SoC; Direktåtkomstläge skulle tillåta användaren att hämta ett lagrat elektroniskt ID även när det inte finns tillräckligt med ström för att starta Android. För mer information om detta API rekommenderar jag läser vår första bevakning där Shawn Willden, ledaren för Android-hårdvarustödda säkerhetsteamet, gav sin input.

Nya projekt huvudlinjemoduler

En av de största förändringarna i Android 10 för nylanserade enheter var introduktionen av Projekt huvudlinje, som trots sitt namn inte har något att göra med att stödja Linux-kärnan på Android. (Det projektet kallas förresten Generic Kernel Image och är fortfarande ett pågående arbete.) Syftet med Project Mainline är istället för Google ska ta bort kontrollen över viktiga ramverkskomponenter och systemapplikationer från OEM-tillverkare. Varje huvudlinjemodul är inkapslad som antingen en APK eller en APEX-fil och kan uppdateras av Google via Play Butik. Användaren ser uppdateringar som en "Google Play System Update" (GPSU) på sin enhet, och uppdateringar släpps på en vanlig kadens som ett tåg (dvs. de laddas ner och installeras samtidigt).

Google kräver inkludering av specifika Mainline-moduler, som vid tidpunkten för Google I/O 2019 inkluderade 13. Nu kräver Google totalt 20 Mainline-moduler i Android 11 Developer Preview 1.

*Obs: vid tidpunkten för publiceringen har Google inte gett oss den fullständiga listan över Mainline-moduler som för närvarande krävs. Vi kommer att uppdatera den här tabellen när vi har den fullständiga listan.

Biometriska promptändringar

Android 9 Pie introduceras BiometricPrompt API, ett enhetligt API för biometrisk autentiseringshårdvara. API: et ger utvecklare ett sätt att utmana användaren genom deras sparade biometri, oavsett om det är fingeravtryck, ansikte eller iris. Innan BiometricPrompt var utvecklare tvungna att skapa sin egen autentiseringsdialog och använda FingerprintManager API, som bara stödde fingeravtrycksautentisering, för att utmana användaren. På Galaxy-smarttelefoner med irisskanner var utvecklarna tvungna att använda Samsungs SDK för att utmana användaren. Med BiometricPrompt kan utvecklare utmana användaren med vilken biometrisk metod som helst som stöds, och systemet tillhandahåller dialogen till användaren. Utvecklare behöver alltså inte längre oroa sig för att specifikt ge stöd för en viss typ av biometrisk hårdvara, och de behövde inte längre koda användargränssnittet för autentiseringsdialogrutan. De Pixel 4:s säkra maskinvara för ansiktsigenkänning, till exempel, kan användas för autentisering i appar som använder BiometricPrompt.

Vad är nytt för BiometricPrompt i Android 11 Developer Preview 1? Google har lagt till tre nya autentiseringstyper: stark, svag och enhetsuppgifter. Innan Android 11 kunde utvecklare bara fråga enhetens säkra biometriska hårdvara – fingeravtrycksläsare, 3D ansiktsigenkänningsskanner eller irisskanner – när de använde BiometricPrompt. Från och med Android 11 Developer Preview 1 kan utvecklare också fråga efter biometriska metoder som anses vara "svaga", såsom mjukvarubaserade ansiktsigenkänningslösningar som finns på många telefoner. Till exempel Google tidigare svartlistat flera Samsung Galaxy-telefoner för att returnera en svag ansiktsigenkänningsautentisering när du försöker kryptobaserad autentisering. Det är nu upp till utvecklaren att bestämma vilken nivå av biometrisk autentisering granularitet deras app behöver.

Säker lagring och delning av BLOB

Ett nytt API kallat BlobstoreManager kommer att göra det enklare och säkrare för appar att dela datablobbar med varandra. Google nämner appar som delar maskininlärningsmodeller som ett idealiskt användningsfall för det nya BlobstoreManager API.

Plattformshärdning

I ett försök att minska attackytan på Android använder Google LLVM desinfektionsmedel för att identifiera "fel med minnesmissbruk och potentiellt farligt odefinierat beteende." Google utökar nu användningen av dessa kompilatorbaserade rengöringsmedel till flera säkerhetskritiska komponenter inklusive BoundSan, IntSan, CFI och Shadow-Call Stack. För att fånga minnesproblem i produktionen aktiverar Google "högpekarmärkning" för alla appar som är inriktade på Android 11 eller senare. Högpekartaggning stöds på ARMv8 64-bitarsenheter med kärnstöd för ARM Top-byte Ignore (TBI), en funktion där "den hårdvara ignorerar den översta byten av en pekare när den kommer åt minne." Google varnar utvecklare för att dessa härdande förbättringar kan "upptäcka fler repeterbara/reproducerbara appkrascher", så utvecklare bör noggrant testa sina appar på den nya Android 11-utvecklaren Förhandsvisning. För att hitta och åtgärda många minnesfel i systemet använde Google ett verktyg för upptäckt av minnesfel som heter hårdvaruassisterad AddressSanitizer (HVASan). Google erbjuder HWASan-aktiverade förbyggda systembilder på AOSP-byggservern om du är intresserad av att hitta och åtgärda minnesfel i dina egna appar.

---

Google kommer säkerligen att tillkännage ytterligare funktioner för att skydda användarnas integritet och förbättra säkerheten, så se till att hålla ett öga på vår Android 11-täckning för att hålla dig uppdaterad.

Android 11 News på XDA