Ексклузивно: 3 от най-добрите функции на Android 11 няма да бъдат на всяко устройство

Всяка година Google пуска нова версия на операционната система Android. Google пусна първата визуализация за разработчици на Android 11 през февруари, последвана от втората, третата и четвъртата визуализация за разработчици през последните няколко месеца. По-рано този месец Google представи първата бета версия на Android 11 и говорихме подробно за най-добрите функции, на които потребителите да се насладят и които разработчиците да внедрят. Сега обаче научихме, че три от най-добрите функции в Android 11 няма да са налични на всяко устройство с Android.

За да разберем как е възможно това, трябва накратко да обясним как операционната система Android се разпространява от Google до производителите на смартфони. Android е операционна система с отворен код лицензиран под Apache 2.0, което означава, че всеки, от независими разработчици до големи компании, е свободен да променя и разпространява операционната система на собствените си устройства. Повечето от новите функции на ОС, които Google представи за Android 11, ще бъдат част от проекта с отворен код на Android (AOSP), който смартфон производителите на устройства базират собствения си софтуер, но лицензът Apache 2.0, както споменах преди, позволява на всеки да променя софтуера, както вижда годни. За да поддържа последователност в API и поведението на платформата между устройствата с Android, Google обединява разпространението на Google Mobile Services (което включва приложения и рамки като Google Play Store и Google Play Services) с лицензионни споразумения, задължаващи устройствата да се придържат към правилата на Google "

Програма за съвместимост с Android“ (наред с други изисквания). Програмата за съвместимост на Android се състои от множество автоматизирани тестови пакети и набор от правила, изброени в Android Документ за дефиниция на съвместимост (CDD).

В CDD Google изброява софтуерни и хардуерни функции, които производителите на устройства „ТРЯБВА“ да прилагат, само „СИЛНО ПРЕПОРЪЧИТЕЛНИ“ са за внедряване или „НЕ ТРЯБВА“ да прилагат. Ако дадена функция е посочена като „ЗАДЪЛЖИТЕЛНА“ за внедряване, тогава производителят на устройството трябва да добави тази функция или няма да може да доставя приложения на Google на своите устройства. Ако дадена функция е посочена като „НЕ ТРЯБВА“ да се прилага, тогава производителят на устройството не може да добави тази функция или не може да обедини приложения на Google. И накрая, ако дадена функция е посочена като „СИЛНО ПРЕПОРЪЧИТЕЛНА“, тогава зависи от производителя на устройството дали иска или не да приложи функцията. CDD е постоянно променящ се документ, дори преди публикуването му всяка година след публичното пускане на нова версия на Android. Google често актуализира документа, за да премахне функции, да промени езика, за да бъде по-ясен, и да облекчи изискванията въз основа на обратна връзка от своите партньори. Въпреки това, след като Google направи публичен CDD за конкретна версия на Android, тези изисквания ще бъдат фиксирани в камък за сертифицирани от Google устройства, работещи с тази версия на Android OS.

CDD за Android 11 няма да стане публичен до по-късно тази година, вероятно в началото на септември. Въпреки това, разработчикът @deletescape сподели предварителна версия на документ, който описва промените, идващи в CDD, което ни дава ранен поглед върху това как Google оформя Android 11 в цялата екосистема. По-голямата част от над 60-те промени в CDD не са много интересни за потребителите – те описват как производителите на устройства трябва да внедрят определени API, да декларират определени функции и да внедрят определено ядро Характеристика. Въпреки това, 3 от промените в CDD привлякоха вниманието ни, защото се отнасят до някои от най-интересните функции в Android 11. Ето какво разкрихме.

Контроли на устройството

Device Controls е функция в Android 11, която позволява контролите за интелигентна домашна автоматизация да се показват в менюто за захранване. Можете да изключите осветлението си, да отворите вратата на гаража си, да стартирате прахосмукачката си, да промените температурата в дома си и да правите много повече, без да отваряте дузина различни приложения за интелигентен дом. Google добави API, които разработчиците на интелигентни домашни приложения могат да използват за извеждане на контроли в менюто за захранване. Смятаме, че това е добра функция, която най-накрая пренася вашия смартфон в интелигентния дом. За съжаление няма изискване производителите на оригинално оборудване действително да го прилагат. Ако OEM смята, че функцията е куца или иска да мине по различен път (като например разрешаване само на смарт домашни контроли от устройства в тяхната собствена екосистема), тогава те могат просто да деактивират поддръжката за Устройство Контроли.

Когато Google за първи път добави Device Controls към CDD на 25 февруари 2020 г., те упълномощиха включването му, като добавиха изискване „ЗАДЪЛЖИТЕЛНО“ в раздел 2.2.3 – Изисквания за ръчен софтуер. На 20 май 2020 г. обаче Google актуализира текста, за да премахне предложеното „ТРЯБВА“. Новият раздел 3.8.16 – Контроли на устройството очертава как трябва да се внедри функцията, но всъщност не изисква тя да бъде внедрена на първо място! Надяваме се производителите на оригинално оборудване да не деактивират тази страхотна функция, но няма начин да разберем дали са я деактивирали, докато не готови да разкрият свои собствени версии на Android, изградени върху Android 11, което няма да се случи преди няколко месеца сега.

Предложен раздел 3.8.16 (Нов) – Контроли на устройството (Актуализиран на 20.05.2020 г.)

3.8.16 Контроли на устройството

Android включва ControlsProviderService и Control APIs, за да позволи на разработчиците да публикуват контроли на устройството за бързо състояние и действие за потребителите.

3.8.16.1 Потребителски права за контрол на устройството

Ако устройствата прилагат Device Controls, тогава те:

• [C-1-1] ТРЯБВА да отчете флага android.software.controls.feature като TRUE
• [C-1-2] ТРЯБВА да предостави на потребителя възможност да добавя, редактира, избира и управлява любимите на потребителя от контролите, регистрирани от приложенията на трети страни чрез android.service.controls. ControlsProviderService и android.service.controls. API за управление.
• [C-1-3] ТРЯБВА да осигури достъп до тази потребителска възможност в рамките на три взаимодействия от стартовия панел
• [C-1-4] ТРЯБВА точно да изобрази в тази потребителска възможност името и иконата на всяко приложение на трета страна, което предоставя контроли чрез android.service.controls. ControlsProviderService API, както и всяка посочена икона, текст на състоянието, тип устройство, име, структура, зона, персонализиран цвят и субтитри, предоставени от android.service.controls. Контролен API

Обратно, ако реализациите на устройства не прилагат такива контроли, тогава те

• [C-2-1] ТРЯБВА да докладва Null за ControlsProviderService и Control APIs.

Прочетете още

Разговори в Известия

Едно от най-големите предимства на Android в сравнение с iOS е как първият обработва известията. Тази празнина в използваемостта ще стане още по-голяма в Android 11 с въвеждането на „Разговори“. В Android 11, известия от приложения за съобщения са групирани заедно и се показват в отделен раздел в панела за известия над повечето други известия. Това ви позволява бързо да виждате и отговаряте на съобщения, без да се налага да превъртате всичките си други чакащи известия. За съжаление, тази изящна промяна в известията може да не е налична на всички устройства. Google дава на производителите на оригинално оборудване опцията да изберат дали искат да „групират и показват известия за разговори преди известия без разговор." Производителите на оригинално оборудване често персонализират панела за уведомяване и затова не е изненада, че Google предоставя на производителите на оригинално оборудване избор тук. Все пак е жалко, че Google не избира да наложи по-голяма последователност в известията в Android 11.

Предложени промени в Раздел 3.8.3.1 – Представяне на уведомления (Актуализирано на 4/08/2020)

Ако внедряването на устройства позволява на приложения на трети страни да уведомяват потребителите за забележителни събития, те:

...

Android R въвежда поддръжка за известие за разговор, което е известие, което използва NotificationManager. MessageStyle и предоставя публикуван ID за бърз достъп до хора.

Реализациите на устройството са:

• [H-SR] СИЛНО ПРЕПОРЪЧИТЕЛНО е групиране и показване на известия за разговори преди тези без разговори известия с изключение на текущи известия за услуги на преден план и важност: висока известия.

Ако известията за разговори са групирани в отделен раздел, реализации на устройства

• [H-1-8] ТРЯБВА да показва известия за разговор преди известия без разговор с изключение на текущи известия за услуги на преден план и важност: високи известия.

Реализациите на устройството са:

• [H-SR] СИЛНО ПРЕПОРЪЧИТЕЛНО е предоставяне на достъп до следните действия от известията за разговори: показване на този разговор като балонче, ако приложението предоставя необходимите данни за балончета

Внедряването на AOSP отговаря на тези изисквания със системния потребителски интерфейс, настройките и стартовия панел по подразбиране.

Прочетете още

IdentityCredential - Мобилни шофьорски книжки

И накрая, една от функциите, които ме вълнуват най-много, е API на IdentityCredential. Както разказахме миналата година, IdentityCredential API е проектиран да позволява на приложенията да съхраняват документи за самоличност, като мобилни шофьорски книжки, на устройството. Няколко държави (и някои щати на САЩ) по света вече позволяват на своите граждани да съхраняват шофьорските си книжки в мобилно приложение. Google обаче работи, за да направи това по-сигурно, като съхранява данните офлайн в защитена среда.

Изходният код за Android 11 включва API IdentityCredential (който разработчиците ще извикат, за да съхраняват документи за самоличност в телефона защитена среда) и IdentityCredential HAL (който взаимодейства със защитената среда на телефона), но от OEM не се изисква да прилагайте ги. Когато Google за първи път предложи включването на IdentityCredential в CDD на 10 януари 2020 г., те го посочиха като изискване. Те обаче смекчиха това изискване на 18 март 2020 г. и сега само силно препоръчват OEM производителите да поддържат тази функция. Не сме изненадани, че Google смекчи това изискване – добавянето на промяна, която влияе на доверената среда за изпълнение, ще изисква усилия от OEM производителите за прилагане. Възможно е производителите на оригинално оборудване просто да се нуждаят от повече време, за да се подготвят за тази промяна. За потребителите обаче това означава, че няма гаранция, че вашият конкретен смартфон с Android 11 ще поддържа сигурно съхраняване на мобилна шофьорска книжка в защитената среда на телефона.

Трябва да отбележим, че няма техническо ограничение, което да възпрепятства широкото приемане на системата IdentityCredential сред устройствата с Android 11. Едно от изискванията за внедряване на системата IdentityCredential е устройството да има Trusted Execution Среда (TEE) или специален защитен процесор, в който „надеждно приложение“ взаимодейства със съхранената самоличност документи. От Android 7.0 Nougat Google изисква всички съвременни устройства с Android да поддържат „изолирана среда за изпълнение“ (съгласно Раздел 2.2.5 – Модел на сигурност в CDD). Устройствата с ARM процесори обикновено разполагат с ARM TrustZone TEE, а Google предоставя Надеждна ОС който работи на TrustZone. Наличието на TEE е достатъчно, за да поддържа системата IdentityCredential, въпреки че би било по-сигурно, ако идентификационните данни се съхраняват във вграден защитен CPU (като например в Сигурен процесор на някои процесори Qualcomm Snapdragon) или отделен защитен процесор (като в Titan M. на Google или Новите чипове за сигурност на Samsung). Трябва да се отбележи, че устройствата с дискретни защитени процесори също могат да поддържат функцията „режим на директен достъп“ на системата IdentityCredential, което ще позволи на потребителя да изтегли своя документ за самоличност, дори когато в устройството няма достатъчно енергия, за да стартира основната операционна система.

Предложен раздел 9.11.3 (Нов) – Идентификационни данни (Актуализиран на 18.3.2020 г.)

Системата за идентификационни данни позволява на разработчиците на приложения да съхраняват и извличат документи за самоличност на потребителя.

Реализации на устройства:

• На [C-SR] СИЛНО СЕ ПРЕПОРЪЧВА прилагането на системата за идентификационни данни.

Ако внедряванията на устройства внедряват системата за идентификационни данни, те:

• [C-0-1] ТРЯБВА да върне ненулево за IdentityCredentialStore#getInstance() метод.
• [C-0-2] ТРЯБВА да се внедрят API на `android.security.identity.*` с код, комуникиращ с доверен приложение, работещо или в доверена среда за изпълнение (TEE), или на специална защитена процесор. Довереното приложение трябва да бъде внедрено така, че Доверена компютърна база за системата за идентификационни данни не включва операционната система Android.

Прочетете още

Google също работи върху библиотека IdentityCredential Jetpack, за да улесни разработчиците да добавят поддръжка за сигурно съхраняване на самоличността документи на Android, но истинското предизвикателство ще бъде да накараш правителствата да оторизират приложения, използващи този API за сигурно съхраняване на държавни идентификатори. Според Engadget, Южна Корея току-що пусна поддръжка за съхраняване на шофьорски книжки в мобилно приложение, така че започваме да виждаме ръст в приемането на тази технология. Аз, например, съм развълнуван да видя къде отива това, защото ще означава едно нещо по-малко, което да нося със себе си, когато излизам навън.

---

Документът, който получихме, изброява промените в CDD до датата, на която тези промени са направени. Последните промени са направени на 10 юни 2020 г., което означава, че документът, с който разполагаме, е доста актуален. Възможно е Google да се откаже от тези промени и да направи отново всички изисквания преди публичното пускане на Android 11, но се съмняваме, че Google внезапно ще направи CDD Повече ▼ строг. Тези промени вероятно са облекчени поради обратна връзка от OEM производителите, които са тези, които ще трябва да се върнат и да внедрят тези функции, ако вече не са били планирани да го направят. Това отнема време, усилия и пари, което само би забавило още повече пускането на Android 11 за устройства, които не са на Google. Все пак, ако Google направи тези функции необходими още веднъж, ще публикуваме актуализация на портала XDA.