Android 11 AMA: Без превъртане на екранни снимки, по-бързо стартиране на приложения и др

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

Една от най-очакваните функции на Android 11 няма да бъде налична, когато ОС излиза от бета на 8 септември: Превъртане на екранни снимки. Първоначално планирано за стартиране в Android 11, сега Google потвърди, че функцията "не е направена за R." Android 11 Developer Preview 1 и всички следващи версии на DP и Beta имат бутон за запазване на място за правене на превъртаща се екранна снимка, която може да бъде ръчно се появи със скрита команда на разработчика

, но докосването на бутона просто показва тост съобщение, в което се посочва, че функцията „не е внедрена“.

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

Разбираемо е, че тази новина ще разстрои някои потребители. В края на краищата, много производители на оригинално оборудване имат тази функция в собствения си софтуер от години, така че какво отнема толкова време на 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 иска производителите на оригинално оборудване да бъдат по-прозрачни с потребителите относно ограниченията на фоновите приложения, които прилагат. Проверих (непубликувания) Android 11 Compatibility Definition Document (CDD) и открих следното предложено допълнение към раздел 3.5 – API поведенческа съвместимост:

Ако внедряванията на устройства прилагат патентован механизъм за ограничаване на приложения и този механизъм е по-рестриктивен от „Редки“ контейнер в режим на готовност на AOSP, те:

[C-1-5] ТРЯБВА да информира потребителите, ако ограниченията за приложението се прилагат автоматично към приложение. (НОВО) Такава информация ТРЯБВА да се предоставя не по-рано от 24 часа преди прилагането на такива ограничения.

(Забележка) Принудителното спиране се счита за по-рестриктивно от „Рядко“ и ТРЯБВА да отговаря на всички изисквания по 3.5.1, включително новите 3.5.1/C-1-5

По принцип Google не е много, за да спре OEM производителите да внедрят свои собствени ограничителни функции за убиване на приложения. Те изискват само производителите на оригинално оборудване да информират потребителите, ако техните ограничения за приложения се прилагат автоматично. Производител на оригинално оборудване може да покаже диалогов прозорец, че ще спре изсмукващите батерия фонови приложения да работят в фон и потребителят може да се съгласи, без да осъзнава, че приложенията, които наистина искат да работят във фонов режим, също са засегнат! Google възлага отговорността на разработчиците да се справят със случаите, когато тяхното приложение бъде унищожено неочаквано във фонов режим. Всъщност коментарът на Reddit продължава, за да подчертае новия "причини за излизане от процес на приложение" API, който може да каже на разработчиците дали приложението им е било унищожено от потребителя, операционната система или просто се е сбило.

От друга страна, Google най-накрая се справя с нечестната практика на производителите на оригинално оборудване, позволяващи на определени привилегировани приложения да заобикалят ограниченията си за фонови приложения. Тази средна публикация от разработчика Тимъти Асимиве навлиза в подробности за приложения като WhatsApp, Facebook и други приложения, които автоматично се освобождават от суровите фонови ограничения на някои OEM софтуер. Google казва, че "изискват производителите на устройства да не създават списъци с разрешени за най-добрите приложения." Не знаем как ще бъде наложено това, но добре е да знаете, че производителите на оригинално оборудване най-накрая ще бъдат принудени да третират разработчиците на трети страни на равна основа - без значение колко големи или малки са техните приложения са.

И накрая, Google също споменава как Android 11 е „добавил допълнителни мерки за предотвратяване на злоупотреба от неправилно работещи приложения“, което прави по-малко привлекателно за OEM производителите да убиват агресивно фонови процеси. Компанията обаче не уточнява какво включват тези „допълнителни мерки“.

Подобрено архивиране от устройство към устройство

Миналия месец забелязахме промяна в документацията на Android 11, която намекна за поддръжка за по-добро локално архивиране на данни. В Android 11 системата ще пренебрегне атрибута на манифеста на allowBackup за всяко приложение, което е насочено към API ниво 30, когато потребителят инициира миграция „от устройство към устройство“ на файлове на приложението. Служителят на Google Елиът Сток казва, че тази функция има за цел да направи „много по-лесно за производителите на телефони да създават инструменти за миграция от устройство към устройство“, като например „отличния продукт Smart Switch на Samsung“ към помогнете „да гарантирате, че приложенията се прехвърлят по-надеждно между устройства от гледна точка на потребителя“. За съжаление, това не се отнася за архивиране в облак, тъй като Google иска да „даде на разработчиците на софтуер контрол върху това, което се случва с техните данни от приложението." Като такъв, Android 11 все още ще зачита атрибута allowBackup за всяко базирано на облак архивиране и възстановяване, като например чрез вградения Google Диск на Google Play Service архивиране. И накрая, Google признава, че таванът от 25 MB за архивиране на приложение може да не е достатъчен за някои разработчици, така че те търсят начини да решат това. Локалните резервни копия на компютър обаче не се разглеждат и Google повтаря своя план за това постепенно премахване на adb архивиране в бъдеща версия на Android.

Разработчиците се насърчават да прилагат методи за безпроблемно мигриране на данни. The нова библиотека на Block Store, който е част от библиотеката на Google Identity Services Library, е предназначен да улесни влизането във възстановени приложения от облака на нови устройства, но зависи от разработчиците да изберат дали искат или не да внедрят това библиотека.

По-бързи скорости на стартиране на приложението с I/O Read Ahead Process (IORap)

Google винаги експериментира с начини за подобряване на производителността в Android. Една от малко известните функции, които добавиха в Android 10, се нарича Unspecialized App Process Pool (USAP). Тази функция елиминира разклоняването на Zygote по време на процеса на стартиране на приложението, спестявайки приблизително ~5ms средни скорости на стартиране на приложението на устройство Pixel 2. Функцията в момента е деактивирано по подразбиране в AOSP, а Google обяснява, че използването на добавената памет все още се нуждае от тестване. По-интересното обаче е нова функция, идваща в Android 11, наречена I/O Read Ahead Process (IORap). Според Google, тази функция ще доведе до „повече от 5% по-бързи студени стартирания със случаи на герои, достигащи 20% по-бързо“. Тази функция „ще изтегли предварително артефакти на приложения (като код и ресурси) по време на процеса на стартиране“, за да стимулира стартирането на приложението скорости.

Google също „направи подобрения в профилите, използвани за оптимизиране на пътя на класа за зареждане и системния образ“ което ще подобри производителността на приложението и ще намали разходите за памет и съхранение, свързани със системата артефакти. Тези промени ще облагодетелстват най-вече устройства с по-голямо количество RAM, въпреки че Google не каза каква е границата за това, където ще видим най-много ползи.

Промени в обхватното хранилище на Android 11 – Защо достъпът до /Изтегляния е ограничен?

Приложения, които са насочени към Android 11 и използват намерението ACTION_OPEN_DOCUMENT_TREE, за да поискат достъп до конкретни директории на външния хранилището вече няма да може да иска от потребителите достъп до главната директория на външното хранилище (/data/media/{user}), изтеглянето директория (/data/media{user}/Download) или някоя от специфичните за приложението директории с данни във външното хранилище (/Android/data или /Android/obb). Защо достъпът до директорията за изтегляне е ограничен? Според Google Roxanna Aliabadi, това е така, защото папката за изтегляне „е най-застрашена от лична информация“. Като пример, потребителите, които изтеглят своя данък връщания или банкови извлечения не трябва да се тревожат за възможността приложенията да злоупотребяват с непрекъснатия си достъп за четене до указател. Google казва, че инструментът за избор на документи ще има „актуализиран текст... за да покаже, че Android е ограничил определени папки да бъдат избрани." Надяваме се, че това ще намали объркването защо не могат да предоставят на приложения достъп до определени директории вече.

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

Разни теми

• Позицията на Google относно рутването/модирането
  • Джеф Бейли от екипа на AOSP на Google повтаря позицията на компанията за подкрепа на избора. Google ще „продължи да гарантира, че е възможно модифициране/руутване на линията устройства Pixel“, но също така ще „подкрепи избора на OEM производители да не разрешават на своите устройства Освен това Google дава на разработчиците на софтуер избор „да не позволяват техният софтуер да работи на руутнати устройства“, във връзка с последните промени в откриване на подправяне на софтуера на SafetyNet Attestation API.
• Какво стана с „отваряне и настройка по подразбиране“?
  • Направен Android 10 малко е досадно да зададете приложение като манипулатор по подразбиране за конкретни връзки, което според Google е направено, за да защити потребителите от „експлоататорски приложения“. Google отстъпи върху тази промяна, след като я преосмислихте, правейки „редица промени зад кулисите“, за да защитите потребителя.
• Използване на API на Vulkan Graphics за изобразяване на потребителския интерфейс?
  • Google в крайна сметка планира да използва API на Vulkan Graphics за изобразяване на потребителския интерфейс, което ще доведе до някои подобрения в производителността. Това е все още се оценява, но от компанията нямаха конкретика за споделяне.
• Липсва CallScreeningService на много устройства
  • Приложенията за Android могат да реализират API на CallScreeningService за прихващане на нови входящи и изходящи повиквания, което им позволява да идентифицират повикващия и да приемат или отхвърлят повикването. Въпреки че това е официално документиран API, очевидно има много OEM производители, които не го прилагат правилно, според разработчика /u/_zeromod_. Google потвърждава че този API е валидиран от Compatibility Test Suite (CTS), автоматизиран тестов пакет, който всички устройства трябва да преминат, за да се считат за съвместими с Android. По някаква причина този API връща нула, когато се извиква на устройства от OEM производители като Huawei, Vivo, Xiaomi или Samsung, така че е вероятно тези OEM производители да имат грешка в софтуера си.
• Няма планове за рамка за аудио добавки
  • Разработчик попита Google дали планират да внедрят рамка за аудио плъгини като аудио модулите на Apple, но Отговорът е, че е малко вероятно да се случи в близко бъдеще.

Можете да прочетете всички отговори от инженерния екип на Android тук. Екипът говори малко за Java, Kotlin, системата за изграждане на Android, CameraX API и други теми в няколко коментара. Има и няколко коментара за Wear OS, Android TV и Android Auto, но Google най-вече повтаря съществуващата им работа върху тези платформи и казва на разработчиците да следят за повече информация по време на "Android Beyond Phones" седмица, започваща на 10 август.