Android 11 AMA: скріншоти без прокручування, швидший запуск програм тощо

Вчора Google випустив Android 11 Beta 2, приносячи доопрацьовані SDK, NDK, поверхні для додатків, поведінку платформи та обмеження для інтерфейсів, що не належать до SDK, для розробників. Сьогодні Google відповідає на запитання, пов’язані з Android 11, у спільноті Reddit /r/AndroidDev після запитань минулого тижня. Ось короткий виклад усього, що ми дізналися від Google AMA (Ask Me Anything).

Одна з найбільш очікуваних функцій Android 11 не буде доступна, коли ОС виходить з бета-версії 8 вересня: прокручування скріншотів. Спочатку запланований до запуску в Android 11, тепер Google підтвердив, що ця функція «не потрапила до категорії R». Android 11 Developer Preview 1 і усі наступні випуски DP і Beta мають кнопку-заповнювач для створення знімка екрана, який прокручується виведено вручну за допомогою прихованої команди розробника, але натискання кнопки просто показує повідомлення про те, що функція «не реалізована».

Ми сподівалися, що ця функція потрапить у бета-версію чи навіть у стабільний випуск, але, схоже, цього просто не станеться.

Зрозуміло, що ця новина засмутить деяких користувачів. Зрештою, багато OEM-виробників мають цю функцію у своєму програмному забезпеченні протягом багатьох років, тож чому Google так довго додає її до телефонів Pixel? Як пояснив Ден Сендлер з команди Google System UI, проблема полягає в тому, що Google хоче зробити це правильно. Деякі реалізації знімків екрана з прокручуванням просто емулюють прокручування, а потім з’єднують кілька знімків екрана під час руху екрана. Якщо ви коли-небудь мали справу з автоматизацією інтерфейсу користувача на Android, ви знаєте, що це не завжди працює, оскільки, як згадує пан Сендлер, програми можуть використовувати «болотний стандарт RecyclerView або реалізували власний механізм прокручування з прискоренням OpenGL». Оскільки Google планує запровадити цю функцію не лише для смартфонів Pixel, але й для всієї екосистеми Android як частини AOSP, вони повинні переконатися, що це буде працювати далі все програми, а не просто «одна чи дві підібрані вручну програми на певному пристрої».

Оскільки команді довелося «зосередити [свої] обмежені ресурси», особливо через виклики, які виникли через COVID-19 команда вирішила залишити знімки екрана, що прокручуються, на другий план для майбутньої версії Android.

Нова вимога CDD щодо інформування користувачів про фонові обмеження

Ні для кого не секрет, що багато OEM-виробників Android, особливо китайські, мають жорсткі обмеження на додатки, що працюють у фоновому режимі. Деякі розробники були настільки розчаровані тим, що їхні програми вимикаються у фоновому режимі, що вони об’єдналися, щоб створити веб-сайт під назвою "Не вбивай мій додаток", щоб оцінити виробників обладнання на основі того, наскільки погано вони обробляють фонові процеси додатків. Ті самі розробники навіть нещодавно зробив еталон щоб користувачі могли перевірити, наскільки агресивно їхній пристрій вбиває програми у фоновому режимі. Причина, чому багато OEM-виробників люблять вбивати фонові процеси додатків, складна, але я думаю, що найкраще це пояснюється в цьому коментарі Redditor /u/можливо сумнівно. У коментарі описується складний стан розробки додатків для Android у Китаї, як китайські технологічні компанії залучені до подальшого ускладнення ситуації, і як відсутність служб Google сприяє цьому безлад.

Незважаючи на це, багато розробників додатків, зрозуміло, розчаровані цими налаштуваннями поведінки платформи Android, що призвело до того, що розробники натискають коментарі запитати Google, що вони з цим роблять на вершину Reddit AMA. Ось відповідь Google:

Є кілька речей, які слід взяти з цієї відповіді. По-перше, Google хоче, щоб OEM-виробники були більш прозорими для користувачів щодо фонових обмежень додатків, які вони застосовують. Я перевірив (неопублікований) Android 11 Compatibility Definition Document (CDD) і знайшов таке пропоноване доповнення до Розділу 3.5 – API Behavioral Compatibility:

Якщо в реалізації пристроїв реалізовано власний механізм для обмеження додатків, і цей механізм є більш обмежувальним, ніж «Рідкісне» резервне відро в AOSP, вони:

[C-1-5] ПОВИНЕН інформувати користувачів, якщо обмеження програми застосовуються до програми автоматично. (НОВИНКА) Така інформація ПОВИННА надаватися не раніше ніж за 24 години до застосування таких обмежень.

(Примітка) Примусова зупинка вважається більш обмежувальною, ніж «Рідкісна», і ПОВИННА відповідати всім вимогам згідно з 3.5.1, включаючи новий 3.5.1/C-1-5

По суті, Google не так багато, щоб зупинити OEM-виробників у впровадженні власних обмежувальних функцій знищення програм. Вони лише вимагають, щоб OEM-виробники інформували користувачів, якщо їхні обмеження додатків застосовуються автоматично. OEM може показати діалогове вікно про те, що вони збираються зупинити роботу фонових програм, які витрачають батарею у фоновому режимі, і користувач може дати згоду, не усвідомлюючи, які програми вони дійсно хочуть запускати у фоновому режимі постраждали! Google покладає на розробників обов’язок вирішувати випадки, коли їхні програми несподівано припиняють працювати у фоновому режимі. Дійсно, коментар Reddit продовжує висвітлювати новий "причини виходу з процесу програми" API, який може повідомляти розробникам, чи їхню програму було закрито користувачем, ОС, чи вона просто вийшла з ладу.

З іншого боку, Google нарешті вирішує нечесну практику виробників оригінального обладнання, які дозволяють певним привілейованим програмам обходити обмеження фонових програм. Цей середній допис від розробника Тімоті Асіімве докладно розповідає про такі програми, як WhatsApp, Facebook та інші програми, які автоматично звільняються від суворих фонових обмежень деяких програм OEM. Google каже, що вони «вимагають, щоб виробники пристроїв не створювали дозволених списків для найпопулярніших програм». Ми не знаємо, як це буде виконано, але Приємно знати, що OEM-виробники нарешті будуть змушені ставитися до сторонніх розробників на рівних, незалежно від того, наскільки великі чи маленькі їхні програми є.

Нарешті, Google також згадує, що в Android 11 «додано додаткові заходи для запобігання зловживанням додатків, що працюють неправильно», що робить виробників обладнання менш привабливими для агресивного припинення фонових процесів. Однак компанія не уточнила, що передбачають ці «додаткові заходи».

Покращене резервне копіювання між пристроями

Минулого місяця ми помітили зміни в документації Android 11 натякнув на підтримку кращого локального резервного копіювання даних. В Android 11 система ігноруватиме атрибут маніфесту allowBackup для будь-якої програми, яка націлена на рівень API 30, коли користувач ініціює перенесення файлів програми «з пристрою на пристрій». Співробітник Google Еліот Сток каже, що ця функція призначена для того, щоб «виробникам телефонів було набагато простіше створювати інструменти міграції з пристрою на пристрій», наприклад «чудовий продукт Smart Switch від Samsung» допомогти "забезпечити більш надійну передачу програм між пристроями з точки зору користувача". На жаль, це не стосується хмарних резервних копій, оскільки Google хоче «надати розробникам програмного забезпечення контроль над тим, що відбувається з даними їхніх додатків". Таким чином, Android 11 все ще поважатиме атрибут allowBackup для будь-якого хмарного резервного копіювання та відновлення, наприклад, через вбудований Google Диск служби Google Play. резервне копіювання. Нарешті, Google визнає, що обмеження в 25 МБ для резервного копіювання на програму може бути недостатнім для деяких розробників, тому вони шукають шляхи вирішення цієї проблеми. Однак локальне резервне копіювання на ПК не розглядається, і Google повторює свій план поступово припинити резервне копіювання adb у майбутній версії Android.

Розробникам рекомендується впроваджувати методи безперебійної міграції даних. The нова бібліотека Block Store, яка є частиною бібліотеки Google Identity Services Library, розроблена, щоб полегшити вхід у відновлені програми з хмари на нових пристроях, але розробники вирішують, чи хочуть вони впроваджувати це чи ні бібліотека.

Швидший запуск додатка завдяки процесу читання вводу-виводу (IORap)

Google постійно експериментує зі способами покращення продуктивності Android. Одна з маловідомих функцій, яку вони додали в Android 10, називається Unspecialized App Process Pool (USAP). Ця функція усуває розгалуження Zygote під час процесу запуску програми, заощаджуючи приблизно ~5 мс середньої швидкості запуску програми на пристрої Pixel 2. Функція в даний час вимкнено за замовчуванням в AOSP, і Google пояснює, що додаткове використання пам’яті все ще потребує тестування. Що ще цікавіше, це нова функція, яка з’являється в Android 11 під назвою «Процес читання вводу-виводу» (IORap). За даними Google, ця функція призведе до «більш ніж на 5% швидших холодних стартапів із випадками героїв на 20% швидше». Ця функція "попередньо завантажуватиме артефакти програм (як-от код і ресурси) під час процесу запуску", щоб прискорити запуск програми швидкості.

Google також «покращив профілі, які використовуються для оптимізації шляху класу завантаження та образу системи» що покращить продуктивність програми та зменшить витрати на пам’ять і сховище, пов’язані з системою артефакти. Ці зміни здебільшого принесуть користь пристроям із більшим об’ємом оперативної пам’яті, хоча Google не повідомляє, яке обмеження є для того, де ми побачимо найбільше переваг.

Зміни обмеженого сховища Android 11 – чому доступ до /Downloads обмежено?

Програми, які націлені на Android 11 і використовують намір ACTION_OPEN_DOCUMENT_TREE для запиту доступу до певних каталогів на зовнішньому сховище більше не зможе запитувати у користувачів доступ до кореневого каталогу зовнішнього сховища (/data/media/{user}), завантаження каталог (/data/media{user}/Download) або будь-який із каталогів даних програми на зовнішній пам’яті (/Android/data або /Android/obb). Чому доступ до каталогу завантажень обмежено? За даними Google Roxanna Aliabadi, це тому, що папка завантажень «найбільш ризикує мати конфіденційну інформацію». Як приклад, користувачі, які завантажують свій податок повернень або банківських виписок не варто хвилюватися про те, що програми зловживають безперервним доступом для читання до каталог. Google каже, що засіб вибору документів матиме «оновлений текст... щоб вказати, що Android обмежив певні папки бути вибраним." Сподіваємось, це зменшить плутанину щодо того, чому вони не можуть надавати програмам доступ до певних каталогів більше.

Щоб дізнатися більше про майбутні зміни в політиці Scoped Storage та Play, зверніться до цієї статті.

Різні теми

• Позиція Google щодо рутування/модифікації
  • Джефф Бейлі з команди AOSP Google повторює позицію компанії щодо підтримки вибору. Google «продовжуватиме забезпечувати можливість модифікації/рутування лінійки пристроїв Pixel», але також «підтримуватиме вибір OEM-виробників не дозволяти своїм пристроям Крім того, Google надає розробникам програмного забезпечення вибір «не дозволяти запуску програмного забезпечення на пристроях з root-доступом», посилаючись на останні зміни в виявлення втручання програмного забезпечення API атестації SafetyNet.
• Що сталося з «відкрити та встановити за замовчуванням»?
  • Створено Android 10 трохи дратує встановлення програми як обробника за замовчуванням для конкретних посилань, що, за словами Google, було зроблено для захисту користувачів від «експлуатаційних програм». Google відступив на цю зміну після її переосмислення, внесення «кількох змін за лаштунками» для захисту користувача.
• Використовуєте Vulkan Graphics API для візуалізації інтерфейсу?
  • Згодом Google планує використовувати Vulkan Graphics API для візуалізації інтерфейсу користувача, що призведе до деяких покращень продуктивності. Це все ще оцінюється, але жодної конкретики компанія не повідомила.
• На багатьох пристроях відсутній CallScreeningService
  • Програми для Android можуть реалізувати CallScreeningService API перехоплювати нові вхідні та вихідні дзвінки, дозволяючи їм ідентифікувати абонента та прийняти або відхилити дзвінок. Незважаючи на те, що це офіційно задокументований API, за словами розробника /u/, очевидно, багато OEM-виробників не реалізують його належним чином._zeromod_. Google підтверджує що цей API перевірено Compatibility Test Suite (CTS), автоматизованим набором тестів, який мають пройти всі пристрої, щоб вважатися сумісними з Android. З будь-якої причини цей API повертає нуль під час виклику на пристроях від OEM-виробників, таких як Huawei, Vivo, Xiaomi або Samsung, тому, ймовірно, ці OEM-виробники мають помилку у своєму програмному забезпеченні.
• Немає планів щодо аудіоплагінів
  • Розробник запитав Google, чи планують вони реалізувати фреймворк аудіоплагінів, як-от Apple Audio Units, але відповідь полягає в тому, що це навряд чи станеться найближчим часом.

Ви можете прочитати всі відповіді команди розробників Android тут. Команда розповідає трохи про Java, Kotlin, систему збірки Android, CameraX API та інші теми в кількох коментарях. Також є кілька коментарів щодо Wear OS, Android TV і Android Auto, але Google здебільшого повторює їхньої поточної роботи на цих платформах і радить розробникам стежити за оновленнями, щоб отримати додаткову інформацію під час "Android Beyond Phones" тиждень, починаючи з 10 серпня.