Ексклюзив: 3 найкращі функції Android 11 не будуть на кожному пристрої

Щороку Google випускає нову версію операційної системи Android. Google випустив першу версію Android 11 Developer Preview ще в лютому, а потім другу, третю та четверту версію для розробників протягом останніх кількох місяців. Раніше цього місяця Google оприлюднив перша бета-версія Android 11 і детально розповіли про найкращі функції для користувачів і для розробників. Однак тепер ми дізналися, що три найпопулярніші функції в Android 11 будуть доступні не на кожному пристрої Android.

Щоб зрозуміти, як це можливо, ми повинні коротко пояснити, як ОС Android поширюється від Google до виробників смартфонів. Android – це операційна система з відкритим кодом під ліцензією Apache 2.0, що означає, що будь-хто, від незалежних розробників до великих компаній, може вільно змінювати та поширювати ОС на своїх власних пристроях. Більшість нових функцій ОС, які Google представила для Android 11, будуть частиною проекту Android Open Source Project (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.

CDD Android 11 стане публічним лише пізніше цього року, ймовірно, на початку вересня. Однак розробник @deletescape поділився попередньою копією документа, у якому детально описано зміни, які надходять до CDD, що дає нам ранній погляд на те, як Google формує Android 11 у всій екосистемі. Переважна більшість із понад 60 змін до CDD не дуже цікаві користувачам — вони описують, як Виробники пристроїв мають реалізувати певні API, оголосити певні функції та реалізувати певне ядро особливості. Однак 3 зміни в CDD привернули нашу увагу, оскільки вони стосуються деяких найцікавіших функцій Android 11. Ось що ми розкрили.

Елементи керування пристроєм

Керування пристроєм — це функція в Android 11, яка дозволяє відображати елементи керування розумною домашньою автоматизацією в меню живлення. Ви можете вимкнути світло, відкрити двері гаража, запустити пилосос, змінити температуру в домі та зробити багато іншого, не відкриваючи десяток різних програм для розумного дому. Google додав API, які розробники додатків для розумного дому можуть використовувати для розміщення елементів керування в меню живлення. Ми вважаємо, що це чудова функція нарешті переносить ваш смартфон у розумний дім. На жаль, немає жодних вимог для виробників комплектного обладнання для його фактичного впровадження. Якщо OEM вважає цю функцію невдалою або хоче піти іншим шляхом (наприклад, дозволити лише інтелектуальний керування домом із пристроїв у їхній власній екосистемі), тоді вони можуть просто вимкнути підтримку для Пристрою Елементи керування.

Коли 25 лютого 2020 року Google вперше додав засоби керування пристроями до CDD, вони зобов’язали їх включити, додавши вимогу «ОБОВ’ЯЗКОВО» в Розділ 2.2.3 – Вимоги до програмного забезпечення портативних пристроїв. Однак 20 травня 2020 року Google оновив текст, щоб видалити запропоноване «ПОВИННО». У новому Розділі 3.8.16 – Елементи керування пристроєм описано, як має бути реалізована функція, але насправді не вимагається, щоб вона була реалізована в першу чергу! Ми сподіваємось, що OEM-виробники не відключать цю чудову функцію, але ми не можемо дізнатися, чи вони вимкнули її, доки вони не готові оприлюднити власні варіанти Android, створені на основі Android 11, що станеться лише через кілька місяців зараз.

Пропонований розділ 3.8.16 (новий) – елементи керування пристроєм (оновлено 20 травня 2020 р.)

3.8.16 Елементи керування пристроєм

Android містить ControlsProviderService та Control API, які дозволяють розробникам публікувати елементи керування пристроєм для швидкого статусу та дій для користувачів.

3.8.16.1 Дозвіл користувача на керування пристроєм

Якщо пристрої використовують елементи керування пристроями, вони:

• [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 API.

читати далі

Розмови в сповіщеннях

Одна з найбільших переваг Android порівняно з iOS полягає в тому, як перша обробляє сповіщення. Цей розрив у зручності використання стане ще більшим в Android 11 із запровадженням «Розмов». В Android 11 сповіщення із програм для обміну повідомленнями згруповані разом і відображаються в окремому розділі на панелі сповіщень над іншими сповіщення. Це дає змогу швидко переглядати повідомлення та відповідати на них, не прокручуючи всі інші незавершені сповіщення. На жаль, ця чудова зміна сповіщень може бути доступною не на всіх пристроях. Google надає OEM-виробникам можливість вибирати, чи хочуть вони «групувати та відображати сповіщення про розмову заздалегідь Постачальники обладнання часто налаштовують панель сповіщень, тому не дивно, що Google надає вибір тут. Тим не менш, на жаль, Google не вирішує забезпечити більшу узгодженість сповіщень в Android 11.

Запропоновані зміни до Розділу 3.8.3.1 – Презентація повідомлень (Оновлено 08.04.2020)

Якщо впровадження пристроїв дозволяє програмам сторонніх розробників сповіщати користувачів про важливі події, вони:

...

Android R представляє підтримку сповіщень про розмову, які є сповіщеннями, які використовують NotificationManager. MessageStyle і надає опублікований ідентифікатор ярлика людей.

Впровадження пристроїв:

• [H-SR] НАСІЙНО РЕКОМЕНДУЄТЬСЯ групувати та відображати сповіщення про розмову перед нерозмовами сповіщення, за винятком поточних сповіщень активної служби та важливість: висока сповіщення.

Якщо сповіщення про розмови згруповані в окремий розділ, то це означає, що пристрої реалізовані

• [H-1-8] ОБОВ’ЯЗКОВО відображати сповіщення про розмову перед сповіщеннями без розмови, за винятком сповіщень поточних служб на передньому плані та сповіщень важливості: високий рівень.

Впровадження пристроїв:

• [H-SR] НАСІЙНО РЕКОМЕНДУЄТЬСЯ надати доступ до таких дій зі сповіщень бесіди: відображати цю бесіду як спливаючу підказку, якщо програма надає необхідні дані для спливаючої підказки

Реалізація AOSP відповідає цим вимогам із системним інтерфейсом користувача, налаштуваннями та запуском за замовчуванням.

читати далі

IdentityCredential - мобільні водійські права

Нарешті, одна з особливостей, яка мене найбільше захоплює, це IdentityCredential API. Як ми детально описували минулого року, IdentityCredential API розроблений, щоб дозволити програмам зберігати на пристрої документи, що посвідчують особу, наприклад мобільні водійські права. Деякі країни (і деякі штати США) у всьому світі вже дозволяють своїм громадянам зберігати свої водійські права в мобільному додатку. Однак Google працює над тим, щоб зробити це безпечнішим, оскільки дані зберігаються офлайн у безпечному середовищі.

Вихідний код для Android 11 містить IdentityCredential API (який розробники викличуть для зберігання документів, що засвідчують особу, у телефоні безпечне середовище) і IdentityCredential HAL (який взаємодіє з безпечним середовищем телефону), але виробники обладнання не зобов’язані реалізувати їх. Коли 10 січня 2020 року Google вперше запропонував включити IdentityCredential у CDD, вони вказали це як вимогу. Однак 18 березня 2020 року вони пом’якшили цю вимогу й тепер лише наполегливо рекомендують виробникам оригінального обладнання підтримувати цю функцію. Ми не здивовані, що Google пом’якшив цю вимогу — додавання зміни, яка впливає на довірене середовище виконання, вимагатиме зусиль від OEM-виробників. Цілком можливо, що OEM-виробникам просто потрібно більше часу, щоб підготуватися до цих змін. Однак для користувачів це означає, що немає гарантії, що ваш конкретний смартфон з Android 11 підтримуватиме безпечне зберігання мобільних водійських прав у безпечному середовищі телефону.

Слід зазначити, що немає жодних технічних обмежень, які перешкоджають широкому впровадженню системи IdentityCredential серед пристроїв Android 11. Однією з вимог для впровадження системи IdentityCredential є те, що пристрій має надійне виконання Середовище (TEE) або виділений захищений процесор, у якому «довірена програма» взаємодіє зі збереженою ідентифікацією документів. Починаючи з Android 7.0 Nougat, Google вимагає, щоб усі сучасні пристрої Android підтримували «ізольоване середовище виконання» (за Розділ 2.2.5 – Модель безпеки в CDD). Пристрої з процесорами ARM зазвичай мають ARM TrustZone TEE, а Google надає Надійна ОС який працює на TrustZone. Наявності TEE достатньо для підтримки системи IdentityCredential, хоча було б безпечніше, якщо облікові дані зберігаються у вбудованому захищеному ЦП (наприклад, у Захищений процесор деяких процесорів Qualcomm Snapdragon) або дискретний захищений ЦП (наприклад, у Titan M. від Google або Нові мікросхеми безпеки Samsung). Примітно, що пристрої з дискретними захищеними процесорами також можуть підтримувати функцію «режим прямого доступу» системи IdentityCredential, що дозволить користувачеві отримати свій документ, що засвідчує особу, навіть якщо в пристрої недостатньо заряду для завантаження основної ОС.

Пропонований розділ 9.11.3 (новий) – ідентифікаційні дані (оновлено 18.03.2020)

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

Впровадження пристроїв:

• [C-SR] НАСІЙНО РЕКОМЕНДУЄТЬСЯ запровадити систему ідентифікаційних даних.

Якщо реалізація пристроїв реалізує систему ідентифікаційних даних, вони:

• [C-0-1] ПОВИНЕН повернути значення, відмінне від null, для 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 більше суворий. Ймовірно, ці зміни були пом’якшені через відгуки виробників оригінального обладнання, яким доведеться повернутися та реалізувати ці функції, якщо вони ще не планували це зробити. Це потребує часу, зусиль і грошей, що може призвести до ще більшої затримки випуску Android 11 для пристроїв, які не належать Google. Проте, якщо Google знову зробить ці функції обов’язковими, ми опублікуємо оновлення на порталі XDA.