Визуализация за разработчици на Android 11: Всички нови функции за поверителност и сигурност

Предсрочно, Google днес пусна първата визуализация за разработчици на следващата версия на Android OS: Android 11. Налични са системни изображения за Pixel 2, Pixel 3, Pixel 3a, Pixel 4, но ако не притежавате някое от тези устройства, можете също да изпробвате Developer Preview чрез емулатора на Android Studio или Generic System Изображение. Въпреки че Google запазва повечето от вълнуващите нови функции за потребители и разработчици за грандиозно съобщение на Google I/O 2020, компанията сподели множество промени, които са налични в първия преглед за разработчици. Ето обобщение на всички нови функции, свързани с поверителността и сигурността, които Google обяви в Android 11 Developer Preview 1.

Преглед за разработчици на Android 11 1 – Нови функции за поверителност

Достъп с еднократно разрешение

Android контролира до какви видове данни приложенията имат достъп чрез своята система за разрешения. Преди Android 6.0 Marshmallow приложенията искаха да им бъдат предоставени разрешения при инсталиране, така че потребителите трябваше да решат дали са съгласни дадено приложение да има определени разрешения, преди да го инсталират. Android 6.0 Marshmallow въведе разрешения по време на изпълнение за избран набор от чувствителни разрешения, включително достъп до местоположение, достъп до микрофона и достъп до камерата. Разрешенията за изпълнение могат да бъдат предоставени само след инсталиране и приложението, което ги изисква, трябва да подкани потребителя чрез предоставен от системата диалогов прозорец, за да разреши достъп. И накрая, в Android 10 Google представи специална версия на разрешението за изпълнение, което позволява на потребителя да предоставя достъп само докато приложението се използва активно; обаче Google въведе само опцията „докато приложението се използва“ за разрешение за местоположение.

В Android 11 Google предоставя на потребителите по-прецизен контрол върху други чувствителни разрешения, включително достъп до камерата и микрофона. Компанията представи нова функция за „еднократно разрешение“ в Android 11 Developer Preview, която позволява на потребителя временно да предостави на приложение достъп до разрешение, докато това приложение е в преден план. След като потребителят се отдалечи от приложението, приложението губи достъп до това разрешение и трябва да го поиска отново.

Промени в обхвата на съхранението

в Android 10 бета 2, Google предложи радикална промяна в начина, по който приложенията имат достъп до външното хранилище на Android. (Външното хранилище тук се определя като данните, видими за потребителя и други приложения, разположени в /data/media.) промяната, наречена „Scoped Storage“, имаше за цел да елиминира твърде широкото използване на READ_EXTERNAL_STORAGE разрешение. Твърде много приложения в Google Play Store искаха и им беше предоставен достъп до цялото външно хранилище, където потребителите запазваха личните си документи, снимки, видеоклипове и други файлове. Със Scoped Storage приложенията по подразбиране ще получат само възможността да виждат своите лични директории с данни. Ако дадено приложение притежава разрешението READ_EXTERNAL_STORAGE при прилагане на Scoped Storage, то може да преглежда определени медийни файлове, достъпни чрез API на MediaStore. Като алтернатива приложението може да използва Storage Access Framework, за да накара потребителя ръчно да избира файлове чрез инструмента за избор на системни файлове. И накрая, приложения, които се нуждаят от широк достъп до външното хранилище, като например файлови мениджъри, могат да използват рамката за достъп до съхранение, за да поискат потребителят да предостави на приложението достъп до основната директория на външното хранилище, като по този начин предостави достъп до всички негови поддиректории, също.

Налагането на Scoped Storage беше настроено да влезе в сила за всички приложения в Android 10, но след обратна връзка и критика от разработчиците, Google отпусна промените, като ги изисква само за приложения, насочени към API ниво 29 (Android 10). След 1 август 2020 г. всички нови приложения, изпратени в Google Play Store, трябва да са насочени към Android 10 и същото важи за всички актуализации на съществуващи приложения след 1 ноември 2020 г. Освен това в Android 11 разработчиците на приложения за управление на файлове трябва да подаде декларация по образец на Google да получи широк достъп до външното хранилище; след като бъдат приети, приложенията за управление на файлове ще имат нефилтриран изглед на MediaStore, но няма да имат достъп до външни директории на приложения.

Освен това Google въведе други промени в Scoped Storage в Android 11 Developer Preview. Приложенията могат да се включат, за да получат пътя на необработения файл и да извършват операции за групово редактиране за медийни файлове в MediaStore. DocumentsUI е актуализиран, за да бъде по-прост за потребителите. Тези промени бяха обявени на Среща на върха на Android Dev миналата година и са ни обещани допълнителни подобрения на Scoped Storage в бъдещите версии на Android 11.

Преглед за разработчици на Android 11 1 – Нови функции за сигурност

Поддръжка за мобилна шофьорска книжка

От началото на миналата година Google работи върху IdentityCredential API и HAL в AOSP. Тази функция полага основата за сигурно съхраняване на идентификационни документи на вашето мобилно устройство, и по-специално на съвместими с ISO 18013-5 мобилни шофьорски книжки. Google официално обяви тази функция на Google I/O 2019, а сега най-накрая се поддържа в Android 11 Developer Preview 1.

Google нямаше какво да каже за тази функция в прессъобщението, но тъй като функцията се разработва на открито, вече знаем много от планираното. На I/O 2019 Google заяви, че работят с ISO за стандартизиране на прилагането на електронни паспорти; все още нямаме представа кога ePassports ще бъдат налични, но вече има няколко американски щата, където eDLs са внедрени или са в пробна фаза. Google също казаха, че работят за осигуряване на библиотека Jetpack, така че разработчиците да могат да създават приложения за самоличност. Не знаем обаче колко скоро разработчиците ще могат да тестват тази функция, тъй като правилната поддръжка изисква защитен хардуер на устройството. The Сигурен процесор на Qualcomm Snapdragon 865 поддържа IdentityCredential API, въпреки че може да не поддържа режима за директен достъп на API, тъй като SPU е интегриран в SoC; Режимът на директен достъп ще позволи на потребителя да изтегли съхранен електронен идентификатор, дори когато няма достатъчно мощност за зареждане на Android. За повече информация относно този API, препоръчвам четейки нашето първоначално отразяване където Шон Уилдън, ръководителят на екипа за сигурност, поддържан от Android, предостави своя принос.

Нови главни модули на проекта

Една от най-големите промени в Android 10 за новостартирани устройства беше въвеждането на Основна линия на проекта, който въпреки името си, няма нищо общо с поддръжката на основното Linux ядро ​​на Android. (Този проект, между другото, се нарича Generic Kernel Image и все още е в процес на работа.) Вместо това целта на Project Mainline е за Google ще изтръгне контрола върху ключови компоненти на рамката и системни приложения от OEM производителите. Всеки основен модул е ​​капсулиран като APK или ан APEX файл и може да се актуализира от Google през Play Store. Потребителят вижда актуализациите като „актуализация на системата на Google Play“ (GPSU) на своето устройство и актуализациите се пускат редовно като влак (т.е. те се изтеглят и инсталират едновременно).

Google налага включването на конкретни основни модули, които към момента на Google I/O 2019 включваха 13. Сега Google изисква общо 20 основни модула в Android 11 Developer Preview 1.

*Забележка: към момента на публикуване Google не ни е предоставил пълния списък с основни модули, които са необходими в момента. Ще актуализираме тази таблица, след като имаме пълния списък.

BiometricPrompt промени

Представен е Android 9 Pie BiometricPrompt API, унифициран API за хардуер за биометрично удостоверяване. API предоставя на разработчиците начин да предизвикат потребителя чрез техните запазени биометрични данни, независимо дали това е пръстов отпечатък, лице или ирис. Преди BiometricPrompt, разработчиците трябваше да създадат свой собствен диалогов прозорец за удостоверяване и да използват FingerprintManager API, който поддържаше само удостоверяване с пръстови отпечатъци, за да предизвикат потребителя. На смартфони Galaxy със скенери за ириса разработчиците трябваше да използват SDK на Samsung, за да предизвикат потребителя. С BiometricPrompt разработчиците могат да предизвикат потребителя с всеки поддържан биометричен метод и системата предоставя диалога на потребителя. По този начин разработчиците вече не трябва да се тревожат за конкретното осигуряване на поддръжка за определен вид биометричен хардуер и също така вече не трябва да кодират потребителския интерфейс за диалоговия прозорец за удостоверяване. The Защитен хардуер за лицево разпознаване на Pixel 4, например, може да се използва за удостоверяване в приложения, които използват BiometricPrompt.

Какво е новото за BiometricPrompt в Android 11 Developer Preview 1? Google добави 3 нови типа удостоверители: силен, слаб и удостоверение за устройство. Преди Android 11 разработчиците можеха да отправят заявки към защитения биометричен хардуер на устройството – скенер за пръстови отпечатъци, 3D скенер за лицево разпознаване или скенер за ирис – когато използват BiometricPrompt. Започвайки от Android 11 Developer Preview 1, разработчиците могат също така да правят заявки за биометрични методи, считани за „слаби“, като софтуерно базираните решения за лицево разпознаване, които се намират на много телефони. Например Google преди това постави в черния списък множество телефони Samsung Galaxy за връщане на слаб удостоверител за лицево разпознаване при опит за крипто базирано удостоверяване. Сега зависи от разработчика да реши от какво ниво на детайлност на биометричното удостоверяване се нуждае тяхното приложение.

Сигурно съхранение и споделяне на BLOB

Нов API, наречен BlobstoreManager, ще направи по-лесно и по-сигурно за приложенията да споделят блокове данни едно с друго. Google цитира приложения, споделящи модели за машинно обучение, като идеален случай на използване на новия API на BlobstoreManager.

Платформено втвърдяване

В опит да намали повърхността на атака на Android, Google използва LLVM дезинфектанти за идентифициране на "бъгове при злоупотреба с памет и потенциално опасно недефинирано поведение." Сега Google разширява използването им базирани на компилатор средства за дезинфекция на няколко критични за сигурността компонента, включително BoundSan, IntSan, CFI и Shadow-Call Stack. За да улови проблеми с паметта в производството, Google активира "маркиране на указател на купчина“ за всички приложения, насочени към Android 11 или по-нова версия. Маркирането на указател на купчина се поддържа на ARMv8 64-битови устройства с поддръжка на ядрото за ARM Top-byte Ignore (TBI), функция, в която " хардуерът игнорира горния байт на указателя при достъп до паметта." Google предупреждава разработчиците, че тези подобрения на защитата може „покриват повече повторяеми/възпроизводими сривове на приложения“, така че разработчиците трябва да тестват щателно своите приложения на новия Android 11 Developer Преглед. За да намери и поправи много грешки в паметта в системата, Google използва инструмент за откриване на грешки в паметта, наречен хардуерно подпомаган AddressSanitizer (HWASan). Google предлага готови системни изображения с активиран HWASan на сървъра за изграждане на AOSP в случай, че се интересувате от намиране и коригиране на грешки в паметта във вашите собствени приложения.

---

Google със сигурност ще обяви допълнителни функции за защита на поверителността на потребителите и подобряване на сигурността, така че не забравяйте да следите нашето покритие за Android 11, за да сте в течение.

Новини за Android 11 на XDA