Android 11 fejlesztői előnézet: Az összes új adatvédelmi és biztonsági funkció

A határidő előtt, Google ma megjelent az első fejlesztői előnézet az Android operációs rendszer következő verziójáról: Android 11. A rendszerképek elérhetők a Pixel 2, Pixel 3, Pixel 3a, Pixel 4 telefonokhoz, de ha nem rendelkezik ezek közül eszközökön, kipróbálhatja a Fejlesztői előnézetet az Android Studio emulátoron vagy a Generic Systemen keresztül is Kép. Bár a Google elmenti a legtöbb izgalmas új felhasználói és fejlesztői funkciót egy nagyszerű bejelentésre a Google I/O 2020-on, a vállalat rengeteg változtatást osztott meg, amelyek az első fejlesztői előnézetben elérhetők. Itt található az összes új adatvédelemmel és biztonsággal kapcsolatos funkció összefoglalása, amelyet a Google bejelentett az Android 11 Developer Preview 1-ben.

Android 11 fejlesztői előnézet 1 – új adatvédelmi funkciók

Egyszeri engedély hozzáférés

Az Android szabályozza, hogy az alkalmazások milyen típusú adatokhoz férhetnek hozzá engedélyrendszerén keresztül. Az Android 6.0 Marshmallow előtt az alkalmazások telepítéskor engedélyt kértek, így a felhasználóknak a telepítés előtt el kellett dönteniük, hogy megfelelő-e, ha egy alkalmazás rendelkezik bizonyos engedélyekkel. Az Android 6.0 Marshmallow futásidejű engedélyeket vezetett be bizonyos érzékeny engedélyek csoportjához, beleértve a hely-, mikrofon- és kamera-hozzáférést. Futási engedélyek csak a telepítés után adhatók meg, és az ezeket kérő alkalmazásnak a rendszer által biztosított párbeszédpanelen kell kérnie a felhasználót a hozzáférés engedélyezésére. Végül az Android 10-ben a Google bevezette a futásidejű engedély egy speciális verzióját, amely lehetővé teszi a felhasználó számára, hogy csak az alkalmazás aktív használatában biztosítson hozzáférést; a Google azonban csak a „miközben az alkalmazás használatban van” opciót vezette be a helyengedélyhez.

Az Android 11-ben a Google pontosabban szabályozza a felhasználókat más érzékeny engedélyek felett, beleértve a kamera- és mikrofon-hozzáférést. A vállalat egy új "egyszeri engedély" funkciót vezetett be az Android 11 fejlesztői előnézetében lehetővé teszi a felhasználó számára, hogy ideiglenesen hozzáférést biztosítson egy alkalmazásnak egy engedélyhez, mindaddig, amíg az alkalmazás a előtér. Amint a felhasználó kilép az alkalmazásból, az alkalmazás elveszíti hozzáférését az engedélyhez, és újra kérnie kell azt.

Hatályos tárolási változások

Ban ben Android 10 béta 2, a Google radikális változtatást javasolt abban a módban, ahogyan az alkalmazások hozzáférnek a külső tárhelyhez Androidon. (A külső tárhely itt a felhasználó és a /data/media mappában található egyéb alkalmazások számára látható adatok.) a "Scoped Storage" névre keresztelt változtatás célja a READ_EXTERNAL_STORAGE túlságosan széles körű használatának megszüntetése volt. engedély. A Google Play Áruházban túl sok alkalmazás kért és kapott hozzáférést a teljes külső tárhelyhez, ahová a felhasználók személyes dokumentumaikat, fotóikat, videóikat és egyéb fájljaikat mentették. A Scoped Storage használatával az alkalmazások alapértelmezés szerint csak a privát adatkönyvtárak megtekintését kaphatják meg. Ha egy alkalmazás rendelkezik a READ_EXTERNAL_STORAGE engedéllyel a Scoped Storage kényszerítése alatt, akkor meg tud tekinteni bizonyos médiafájlokat, amelyek a MediaStore API-n keresztül érhetők el. Alternatív megoldásként az alkalmazás használhatja a Storage Access Framework-et, hogy a felhasználó manuálisan válassza ki a fájlokat a rendszerfájlválasztón keresztül. Végül, azok az alkalmazások, amelyeknek széleskörű hozzáférésre van szükségük a külső tárolóhoz, például a fájlkezelők, a Storage Access Framework segítségével kérhetik a felhasználó hozzáférést biztosít az alkalmazásnak a külső tároló gyökérkönyvtárához, ezáltal hozzáférést biztosít az összes alkönyvtárához, is.

A hatályos tárhely kényszerítése az Android 10 összes alkalmazására érvényes lett volna, de a fejlesztők visszajelzései és kritikái után, Google lazította a változásokat, csak a 29-es API-szintet (Android 10) megcélzó alkalmazásokhoz szükségesek. 2020. augusztus 1. után a Google Play Áruházba beküldött összes új alkalmazásnak az Android 10-et kell megcéloznia, és ugyanez vonatkozik a 2020. november 1. után a meglévő alkalmazások minden frissítésére. Továbbá az Android 11-ben a fájlkezelő alkalmazások fejlesztői nyilatkozatot kell benyújtania a Google számára, hogy széles körű hozzáférést kapjon a külső tárhelyhez; Az elfogadás után a fájlkezelő alkalmazások szűretlen nézetet kapnak a MediaStore-ról, de nem férnek hozzá a külső alkalmazáskönyvtárakhoz.

Ezenkívül a Google további változtatásokat vezetett be az Android 11 fejlesztői előnézetében a Scoped Storage területén. Az alkalmazások engedélyezhetik a nyers fájl elérési útját, és kötegelt szerkesztési műveleteket hajthatnak végre a MediaStore-ban lévő médiafájlokhoz. A DocumentsUI frissítve lett, hogy egyszerűbb legyen a felhasználók számára. Ezeket a változásokat a Android Dev Summit tavaly, és további fejlesztéseket ígérünk a Scoped Storage jövőbeli Android 11 kiadásaiban.

Android 11 fejlesztői előnézet 1 – Új biztonsági szolgáltatások

Mobil illesztőprogram-támogatás

Tavaly év eleje óta a Google azon dolgozik IdentityCredential API és HAL az AOSP-ben. Ez a funkció megalapozza az azonosító dokumentumok, különösen az ISO 18013-5 szabványnak megfelelő mobil vezetői engedélyek biztonságos tárolását mobileszközén. Google hivatalosan bejelentette ezt a funkciót a 2019-es Google I/O-n, és most végre támogatott az Android 11 Developer Preview 1.

Erről a funkcióról a sajtóközleményben nem sok mondanivalója volt a Google-nak, de mivel a funkció fejlesztés alatt áll, sok mindent tudunk már a tervekről. A 2019-es I/O rendezvényen a Google kijelentette, hogy együttműködnek az ISO-val az elektronikus útlevelek megvalósításának szabványosításán; még fogalmunk sincs arról, hogy az ePassports mikor lesz elérhető, de az Egyesült Államokban már több olyan állam is van, ahol bevezetik az eDL-eket, vagy próbafázisban vannak. A Google azt is közölte, hogy Jetpack-könyvtárat biztosítanak, hogy a fejlesztők személyazonossági alkalmazásokat készíthessenek. Azt azonban nem tudjuk, hogy a fejlesztők milyen hamar tesztelhetik ezt a funkciót, mivel a megfelelő támogatáshoz biztonságos hardver szükséges az eszközön. A Biztonságos feldolgozóegység a Qualcomm Snapdragon 865-ön támogatja az IdentityCredential API-t, bár lehet, hogy nem támogatja az API közvetlen elérési módját, mivel az SPU integrálva van az SoC-be; A Közvetlen hozzáférés mód lehetővé teszi a felhasználó számára, hogy előhívjon egy tárolt elektronikus azonosítót, még akkor is, ha nincs elég energia az Android indításához. Az API-val kapcsolatos további információkért ajánlom elolvasva kezdeti tudósításunkat ahol Shawn Willden, az Android hardverrel támogatott biztonsági csapata vezette a véleményét.

Új projekt fővonali modulok

Az Android 10 egyik legnagyobb változása az újonnan piacra dobott eszközök esetében a bevezetése volt Projekt fővonal, amelynek a neve ellenére semmi köze a Linux rendszermag fő vonalának támogatásához Androidon. (Azt a projektet egyébként Generic Kernel Image-nek hívják, és még mindig folyamatban van.) Ehelyett a Project Mainline célja az, hogy A Google megszabadítja az OEM-ektől a kulcsfontosságú keretösszetevők és rendszeralkalmazások irányítását. Minden Mainline modul APK-ba van beépítve vagy egy APEX fájl és a Google frissítheti a Play Áruházban. A felhasználó a frissítéseket „Google Play rendszerfrissítésként” (GPSU) látja eszközén, és a frissítések rendszeres ütemben, vonatként (pl. egyszerre töltik le és telepítik).

A Google előírja bizonyos Mainline modulok felvételét, amelyek a Google I/O 2019 idején 13-at tartalmaztak. A Google jelenleg összesen 20 fő modult ír elő az Android 11 Developer Preview 1-ben.

*Megjegyzés: a közzététel időpontjában a Google nem bocsátotta rendelkezésünkre a jelenleg szükséges Mainline modulok teljes listáját. Frissítjük ezt a táblázatot, amint megvan a teljes lista.

Biometrikus prompt változások

Bemutatták az Android 9 Pie-t a BiometricPrompt API, a biometrikus hitelesítési hardver egységes API. Az API lehetőséget biztosít a fejlesztőknek, hogy kihívást jelenthessenek a felhasználó számára mentett biometrikus adataikkal, legyen szó ujjlenyomatról, arcról vagy íriszről. A BiometricPrompt előtt a fejlesztőknek létre kellett hozniuk saját hitelesítési párbeszédpanelt, és a FingerprintManager API-t kellett használniuk, amely csak az ujjlenyomat-hitelesítést támogatta, hogy kihívást jelentsen a felhasználó számára. Az íriszszkennerrel rendelkező Galaxy okostelefonokon a fejlesztőknek a Samsung SDK-ját kellett használniuk a felhasználó kihívásaihoz. A BiometricPrompt segítségével a fejlesztők bármilyen támogatott biometrikus módszerrel kihívhatják a felhasználót, és a rendszer biztosítja a párbeszédpanelt a felhasználó számára. Így a fejlesztőknek többé nem kell aggódniuk amiatt, hogy egy bizonyos típusú biometrikus hardverhez nyújtanak támogatást, és nem kell többé kódolniuk a felhasználói felületet a hitelesítési párbeszédpanelhez. A A Pixel 4 biztonságos arcfelismerő hardvere, például használható hitelesítésre a BiometricPromptot használó alkalmazásokban.

Milyen újdonságok vannak az Android 11 Developer Preview 1 BiometricPrompt alkalmazásban? A Google három új hitelesítőtípust adott hozzá: erős, gyenge és eszközhitelesítési adatokat. Az Android 11 előtt a fejlesztők csak a BiometricPrompt használatakor tudták lekérdezni az eszköz biztonságos biometrikus hardverét – ujjlenyomat-szkennert, 3D-s arcfelismerő-szkennert vagy íriszszkennert. Az Android 11 Developer Preview 1-től kezdve a fejlesztők a „gyengének” ítélt biometrikus módszereket is lekérdezhetik, mint például a számos telefonon megtalálható szoftveralapú arcfelismerő megoldásokat. Például a Google korábban több Samsung Galaxy telefont is feketelistára tett gyenge arcfelismerő hitelesítő visszaadásáért, amikor kriptoalapú hitelesítést próbálnak meg. Most már a fejlesztőn múlik, hogy eldöntse, milyen szintű biometrikus hitelesítésre van szüksége az alkalmazásának.

A BLOB-ok biztonságos tárolása és megosztása

A BlobstoreManager nevű új API megkönnyíti és biztonságosabbá teszi az alkalmazások számára az adatblobok megosztását egymással. A Google a gépi tanulási modelleket megosztó alkalmazásokat említi az új BlobstoreManager API ideális felhasználási példájaként.

Platform keményedés

Az Android támadási felületének csökkentése érdekében a Google ezt használja LLVM fertőtlenítők azonosítani a "memória-visszaélési hibákat és a potenciálisan veszélyes, meghatározatlan viselkedést". A Google most bővíti ezek használatát fordító alapú fertőtlenítők számos biztonsági szempontból kritikus összetevőhöz, köztük a BoundSan, az IntSan, a CFI és a Shadow-Call Stackhez. Az éles memóriaproblémák kiküszöbölése érdekében a Google engedélyezihalommutató címkézése" minden Android 11 vagy újabb rendszert célzó alkalmazáshoz. A halommutató-címkézést támogatják az ARMv8 64 bites eszközök, amelyek a kernel támogatja az ARM Top-byte Ignore (TBI) funkciót, amely szolgáltatásban "a a hardver figyelmen kívül hagyja a mutató felső bájtját a memória elérésekor." A Google figyelmezteti a fejlesztőket, hogy ezek a keményítő fejlesztések „Tegye felszínre több megismételhető/reprodukálható alkalmazás-összeomlást”, így a fejlesztőknek alaposan le kell tesztelniük alkalmazásaikat az új Android 11 Developeren Előnézet. A rendszer számos memóriahibájának megtalálása és kijavítása érdekében a Google egy memóriahiba-észlelő eszközt használt hardveres támogatású AddressSanitizer (HWASan). A Google HWASan-kompatibilis előre elkészített rendszerképeket kínál az AOSP build szerveren arra az esetre, ha szeretné megtalálni és kijavítani a memóriahibákat saját alkalmazásaiban.

---

A Google minden bizonnyal további funkciókat jelent be a felhasználók adatainak védelme és a biztonság javítása érdekében, ezért ügyeljen az Android 11 lefedettségére, hogy naprakész maradjon.

Android 11 hírek az XDA-n