Онзи ден инженерите на Google направиха AMA в Reddit. AMA беше за бета версията на Android Q. Ето обобщение на това, което научихме от техните отговори.
Миналата година екипът на Google за Android беше домакин на Ask Me Anything (AMA) в подредактирата /r/AndroidDev на Reddit, за да задава въпроси относно Предварителен преглед за разработчици на Android P. Тази година инженерният екип, работещ върху бета версията на Android Q, отговори на въпроси в Reddit. AMA започна на 1 август в 12:00 PST и приключи около час и половина по-късно. 33 инженери на Google участваха в AMA, като отговориха на куп въпроси за краткото време на AMA. Ето нашето обобщение на цялата нова информация, която научихме.
Android Q AMA: Всичко, което научихме от Google
Участници от бета екипа на Android Q
- Адам Коен: TLM на Android Launcher / System UI
- Адам Пауъл: TLM на UI инструментариум/рамка; изгледи, жизнен цикъл, фрагменти, поддържащи библиотеки
- Алън Виверет: TLM, Jetpack / AndroidX
- Алън Хуанг: PM за потребителски интерфейс, стартер, известия, интеграции с търсене и още!
- Андрю Сапирстейн: TLM в настройките на Android
- Брахим Елбучихи: PM директор за Android Machine Learning и Camera (NN API, ML Kit, CameraX, Camera Platform)
- Чад Брубейкър: Софтуерен инженер, Сигурност на платформата Android
- Шармейн Д’Силва: ЛС за поверителност
- Чет Хаасе: Главен защитник на Android, връзки с разработчиците
- Даяна Уонг: PM, съвместимост на приложения, използване на API без SDK, ART, NDK
- Даян Хакборн: Мениджър на екипа на рамката на Android (Ресурси, Мениджър на прозорци, Мениджър на активността, Мултипотребител, Печат, Достъпност и др.)
- Е.К. Чунг: Директор на UX
- Иън Лейк: Софтуерен инженер, Jetpack (фрагменти, навигация, архитектурни компоненти)
- Илиян Малчев: Главен софтуерен инженер, Project Mainline
- Джейкъб Лербаум: Директор за връзки с разработчици за Android
- Джейк Уортън: Софтуерен инженер, Jetpack
- Джамал Исън: PM, Android Studio
- Джеф Бейли: TLM, Android Open Source Project (AOSP)
- Джеф Шарки: Софтуерен инженер, Android Framework
- Джефри ван Гог: Android Studio, Компилатори
- Джен Чай: PM, местоположение и контекст, удостоверяване, автоматично попълване, използване на API без SDK, ART
- Карън Нг: Group PM за инструменти за разработчици на Android, Android Studio, Android Tookit и Jetpack
- Пол Банкхед: Директор продуктов мениджмънт, Google Play
- Рохан Шах: Продуктов мениджър, Android System UI
- Ромен Ги: Мениджър на екипа на Android Toolkit/Jetpack
- Сагар Камдар: Директор продуктов мениджмънт, Android
- събота K: Инженерен директор, свързаност с Android
- Селим Чинек: Софтуерен инженер, Android System UI
- Стефани Саад Кътбъртсън: Старши директор продуктово управление, Android
- Сумир Катария: Софтуерен инженер, Jetpack (WorkManager)
- Травис Маккой: PM, Android платформа
- Trystan Upstill: Изтъкнат инженер, водещ за Android System UI & Intelligence
- Винит Моди: PM, Android камера
Прочетете още
Производителите на оригинално оборудване вече не могат да убиват приложения, когато потребителят ги изтрие с пръст в последните
Ако някога сте използвали смартфон от китайска марка, вероятно сте се сблъсквали с досадни функции за „оптимизиране на батерията“, които убийте всичките си любими приложения във фонов режим. Това поведение не само е досадно за потребителите, които очакват определени приложения да продължат да работят във фонов режим по някаква причина, но но също така е досадно за разработчиците, които трябва да страдат от лоши отзиви от потребители, които не разбират, че това не е на приложението грешка. Докато Google е все още не се занимава напълно с този въпрос (те махнаха с ръка на проблема, като заявиха, че това поведение е вероятно вече е в нарушение на изискванията на документа за определяне на съвместимостта с Android), компанията е предприемам действие срещу една промяна в поведението за „пестене на батерията“, използвана от някои производители на оригинално оборудване.
„За да помогнем със ситуацията, добавихме CTS тест в Android Q, за да гарантираме, че дадено приложение няма да бъде унищожено, след като бъде плъзнато от Recents.“
Android R може да внесе повече промени в екранните снимки, отколкото очаквахме
Google планира да добави превъртане на екранни снимки в Android R, но в същото време, Екипът на Android е "като разгледаме отблизо как [те] могат да подобрят цялото изживяване на екрана [X] за R." Така можем вижте други подобрения в поведението на екранната снимка (И скрийнкаст) в следващата основна версия на Android.
Изясняване на новия режим на работния плот на Android Q
The първата публична бета версия на Android Q донесе скрит интерфейс в режим на десктоп към AOSP и Pixel Launcher. Въпреки че Google накратко засегна функцията по време на Google I/O сесия никога не сме чували директно от Google как новата функция се вписва в екосистемата на Android. Google сега изяснява:
„В Q AOSP „десктоп режим“ е опция за разработчици, насочена към разработчиците на приложения. Позволява им да тестват своите приложения в среди с много дисплеи и прозорци със свободна форма. Преди това нямаше удобен начин за тестване на поведението на приложението на вторичен дисплей и със свободно променящи се размери прозорци на стандартен Android. Тази функция не е произведена самостоятелно и в момента не е предназначена за редовни потребители. Въпреки това, това е основата на платформата Android за OEM производителите да правят иновации и да правят страхотни продукти."
По този начин можем да очакваме да видим OEM производителите да надграждат нативния десктоп режим на Android Q. Например, на OnePlus 7 Pro поддържа дисплей през HDMI, така че е възможно това OxygenOS 10, базиран на Android Q ще има свой собствен интерфейс в режим на настолен компютър в бъдеще. Също така се надяваме, че Google надгражда функцията за предстоящото Pixel 4.
Тъмен режим, базиран на времето
Android Q най-накрая носи широко търсена функция: тъмен режим за цялата система. Понастоящем тъмният режим може да бъде активиран ръчно в Настройки или чрез плочка за бързи настройки или може да се активира автоматично, когато е активиран Battery Saver. Преди Android Q имаше опция за активиране на тъмен режим въз основа на времето от деня, но тази опция беше отхвърлена. Според Крис Бейнз:
„Има няколко причини, поради които това е отхвърлено (не е премахнато) в AppCompat v1.1.0: изисква приложенията да изискват разрешенията за местоположение да бъдат точни и дори с валидно местоположение изчисленията на времето за изгрев/залез могат да бъдат бъги."
На въпрос за тези грешки, г-н Бейнз заявява, че „изчисляването на изгрева/залеза е изключително трудно, особено за места близо до северен/южен полюс." Потребителят извежда, че нощната светлина, налична от Android 7.1 Nougat, може да се превключва автоматично въз основа на залез/изгрев графици. След това г-н Banes заявява, че тъй като Night Light използва CalendarAstronomer от ICU4J, той използва "голяма част от кода, от който не бихме искали AppCompat да зависи." Екипът обаче го прави състояние че тази функция е „нещо, което [те] ще проучат“.
Задължителна поддръжка на Camera2 API/Camera HAL3 за стартиращи устройства с Android Q
Google представи Camera2 API, за да дефинира по-добре как приложенията могат да взаимодействат с отделните камери, свързани към вашия смартфон. Докато Google насърчава доставчиците на смартфони да „излагат всичките си физически камери на разработчиците“, много доставчици избират да не го правят, въпреки че „самият API не е предотвратявайки ги днес." Това означава, че много приложения за камери на трети страни не могат да използват вторичните или третичните модули на камерата на модерни смартфони. Въпреки това има напредък, тъй като Android Q се подобри LOGICAL_MULTI_CAMERA, API, който дава на разработчиците по-добър достъп до всички камери на дадено устройство и който дава на производителите на оригинално оборудване контрол върху консумацията на енергия и управлението на множество състояния на камерата.
Освен това Google казва, че са добавили изисквания към всички устройства, стартирани с Android Q, за естествена поддръжка на Camera2 API/Camera HAL3. Според Винит Моди:
„Започвайки с Android P, новите устройства, доставяни с 1 GB или повече RAM, трябва да използват естествено HALv3/camera2. Android Q нататък всички нови устройства трябва да поддържат първоначално HALv3/camera2. За съжаление надстройките от HALv1 до HALv3 са доста сложни по въздуха и може да имат неочаквани последици, поради което трябваше да ограничим обхвата до нови устройства."
Интересно е изявлението на Моди за нормалните RAM устройства за стартиране на Android P противоречи какво ни беше казано по-рано от Google и какво е публикувано на страницата Image Test Suite онлайн.
Динамично оформление на приложения с Jetpack Compose
Рамката за тематизиране OMS на Sony беше добавена към AOSP доста издания назад, но това е само предназначени за OEM производители да надграждам. Това вече го знаем Google е против използването на наслагвания на ресурси по време на работа от потребителите за тематични приложения, но за разработчиците компанията е надявайки се това е Jetpack Compose UI Framework ще предложи „интересни подходи към динамичното оформяне на теми“.
Vulkan-backend за Skia за изобразяване на потребителския интерфейс
Миналата година, забелязахме дискусия сред инженерите на Google, които говорят за плановете си рамката на Android да използва графичния API на Vulkan за изобразяване на потребителския интерфейс. Докато вече е възможно да активирате хардуерно ускорения бекенд на Vulkan без вашия телефон срив, не сме чули никакви конкретни планове от Google за това кога планират да ги пуснат промени. Този AMA не отговаря на този въпрос, но поне имаме потвърждение, че все още се работи по него. Според Ромен Ги:
„Екипът работи върху бекенд на Vulkan за Skia, 2D рендър, използван от Android, но в момента не е активиран по подразбиране. Потребителският интерфейс и Canvas все още преминават през OpenGL ES."
Правене на лентата с жестове на Android Q по-динамична
Някои в XDA все още мислят така Новите жестове на Android са бъркотия, но аз лично смятам, че са добре. Ако обаче си поиграете малко с новите жестове в Android Q, ще забележите, че лентата с жестове не се движи с пръста ви. Освен това се задържа на екрани, където не е необходимо, като началния екран или преглед на последните приложения. Алън Хуанг казва че те са "напълно съгласни, че има възможности" да направят "навигационната линия по-малко статична". Той казва още че „това е нещо, върху което работим – но също така балансираме, така че да не ни разсейва появяване/изчезване."
Подобрения в рамката за достъп до съхранение
Многото промени в Android Q значително подобриха сигурност и поверителност на платформата. Една такава промяна, наречена „Scoped Storage“, ограничава достъпа на приложенията до файловете във външното хранилище по начин, който има смисъл; музикалните приложения не трябва да виждат вашата галерия, например. Приложенията за управление на файлове, работещи в Android Q, трябва да използват API, наречен Storage Access Framework, за да продължат да работят нормално, но някои разработчици смятат този API за по-нисък към това, което е било налично преди това. Джеф Шарки от Google казва екипът е разгледал някои от тези оплаквания на разработчиците:
„Направихме някои подобрения в производителността на SAF в най-новите версии на Android Q Beta; можете ли да проверите вашите показатели спрямо най-новата бета? Също така се уверете, че използвате ContentProviderClient, когато изпълнявате групови операции."
Project Treble подобри приемането на Android Pie спрямо Android Oreo
Вече видяхме как Project Treble, основно преструктуриране на ниско ниво на рамката на Android, подобри приемането на по-новите версии на Android OS. Google приписва на Treble зад множеството доставчици на смартфони, които се присъединяват към Android P бета миналата година и Android Q бета тази година. Илиян Малчев, водещият Project Treble и Основна линия инженер, казва че приемането на Android Pie е „3 пъти“ по-голямо от това на Android Oreo в края на 2018 г.
В същия коментар Дик Дохърти дразни, че се разработват по-полезни показатели за диаграмата за разпространение на версиите на Android. Диаграмата беше последно актуализиран през май, но данните от него са по-полезни за журналистите, отколкото за разработчиците на приложения.
Записът на екрана все още е WIP
Ранните бета версии на Android Q добавиха флаг за функция за основен запис на екран, но самата платформа значително подобри полезността на записа на екрана чрез позволявайки на приложенията да заснемат аудио от други приложения. Стефани Саад Кътбъртсън каза, че екипът обмисля "как бихме могли да се справим по-добре с нуждите от запис на екрана още вчера." Други марки смартфони като OnePlus, ASUS, Huawei и Samsung имат стабилни екранни рекордери, които могат да записват вътрешното аудио, така че Google ще играе наваксване тук.
Тъмна тема Всички неща!
В случай, че сте пропуснали, Google добавя тъмен режим към повечето си приложения. Стефани Саад Кътбъртсън казва да очакваме всички „основни приложения“ да поддържат тъмна тема „от официалното издание на [Android Q].“ Дори Google Chrome, който в момента принуждава презареждане на страницата, когато тъмната тема за цялата система е активирана, ще се актуализира, за да не се опреснява повече, когато темата е променен.
Да, програмите за стартиране на трети страни ще работят с жестове (евентуално)
Жестовете на Android са нещо като повреден, когато използвате стартер на трета страна. Това е така, защото потребителският интерфейс на скорошните приложения се съдържа в приложението за стартиране на акции, а Google все още не е разработи начин да има същите безпроблемни преходи, които виждаме при използване на жестове със стандартния Pixel Стартер. Адам Коен утвърждава Google планира да се справи с тези проблеми „възможно най-бързо след пускането на пазара“. По-нататък той казва, че несъвместимостта "ще бъде разгледана в актуализация след Q и ще бъде пренесена за нови устройства, стартиращи с Q."
Динамичните/логическите дялове не са тук, за да убиват потребителски ROM
С цел подкрепа Динамични системни актуализации в Android Q някои устройства като Google Pixel 3 и Pixel 3 XL използват логически дялове. Тези дялове могат да бъдат динамично преоразмерени. Тази промяна има доказано предизвикателство за осигуряване на работещ root достъп, а някои разработчици са загрижени, че персонализираните ROM са насочени към тях. Илиян Малчев ни уверява, че намерението не е да се ограничават custom ROM-овете. Като обяснява той:
„Динамичните дялове не са предназначени да ограничават това, което можете да правите с персонализирани ROM. Те просто са решение на проблема с фиксираните размери на дяловете и липсата на безопасен начин за повторно разделяне на устройства OTA. Преди динамичните дялове, ако OEM направи грешка при оразмеряването, напр. системния дял, след това те ще бъде ограничено от този избор, което прави практически невъзможно надграждането на устройство след определено време точка. Някои производители на оригинално оборудване преразпределят своите устройства на OTA като въпрос на практика, но това а) не се поддържа официално в Android и б) промяната на таблицата на дяловете се счита за доста рисковано. Динамичните дялове имат за цел да облекчат проблема чрез въвеждане на ниво на индиректност между таблицата на физическите дялове и операционната система. Това от своя страна ни позволява безопасно да коригираме размерите на дяловете на OTA. Що се отнася до персонализираните ROM, не трябва изобщо да сте ограничени повече от това, което сте днес, с това, което можете да правите. Поддръжката на персонализирани ROM е и продължава да бъде нещо, което всеки отделен OEM решава да активира."
Основна линия на проекта - ART модул и дължина на поддръжката
Mainline е нова инициатива на Google, която има за цел да стандартизира определени библиотеки и пакети, така че да могат да се актуализират независимо от актуализациите на платформата. Някои се чудеха защо Android Runtime (ART) все още не е основен модул, но ми казаха в Google I/O, че сложността, свързана с модулирането на ART, им попречи да го включат като един от първоначалните APEX пакети. Като обясни от Илиян Малчев и Даяна Вонг:
„Извършването на актуализации на Runtime (особено производителността и корекциите на GC и основните библиотеки) определено е нещо, което проучваме в контекста на основната линия. Можем да видим много предимства от възможността да направим тези актуализации последователни на всички устройства и в множество издания с основна линия. Това също е огромно техническо предизвикателство, тъй като мислим как да направим това най-добре за разработчиците и вероятно многогодишно усилие. Това не е нещо, което Mainline може да направи в момента, но със сигурност е нещо, за което мислим."
Ако следвате AOSP Gerrit, ще видите, че Google все пак е бил усилено на работа създаване на APEX по време на изпълнение. В момента те изглеждат така разделяне на Bionic и ART/libcore в отделни APEX модули.
По отношение на ползата от Project Mainline, един потребител попита за продължителността на актуализациите на Mainline. В отговор Илиян Малчев казва че „това е въпрос на политика, който все още оценяваме, но искаме да актуализираме основните модули на устройството възможно най-дълго.“ XDA признат разработчик luca020400 попита дали ще бъдат осигурени предварително изградени модули Mainline, така че персонализираните разработчици на ROM да могат да обединяват актуализации, и в отговор Джеф Бейли повтаря че "модулите, които се отделят от AOSP, ще имат версии на източника, съответстващи на всяка версия на модула." Вече можем да видим развитието на нови APEX модули в AOSP, като един за API за невронни мрежи.
CameraX среща ML Kit
На I/O тази година Google представи Библиотека CameraX Jetpack. Тази библиотека е предназначена да улесни разработчиците да поддържат Camera2 API на Android, като същевременно поддържа съвместимост до Android Lollipop. Винит Моди дразни с които компанията работи по интегрирането на CameraX ML комплект, Firebase SDK за машинно обучение на Google, така че разработчиците да могат да подават рамки на изображения в ML Kit за анализ.
Разширения на доставчика на CameraX и дата на издаване
Разработчикът на приложение за камера се оплаква от факта, че разширените функции на камерата като Night Sight на Google Pixel не са достъпни за приложения за камера на трети страни. Предполага се, че това е разрешимо с разширенията на доставчика на CameraX, към които Джеф Шарки от Google казва че "всички устройства Pixel са оптимизирани за CameraX Core." Той дразни, че "аспектът на разширенията ще се поддържа на нови и предстоящи устройства." Освен това Google е "работа с няколко производителя, за да могат да предоставят възможностите на своите устройства както на разработчиците, така и на потребителите." Въпреки че не е директно потвърдено, възможно е да видим функции като Нощен мерник на Google Pixel 4 стават достъпни за приложения за камера на трети страни, които използват библиотеката CameraX.
Г-н Шарки заявява, че Google планира бета версия за края на тази година.
Подобрения в управлението на паметта в Android Q
Pixel 3 беше критикуван за наличието множество проблеми след стартирането, но Google направи много за справяне с тези проблеми чрез множество актуализации след стартиране. Управлението на паметта е един от най-слабите аспекти на Pixel 3, но нещата трябва да са малко по-добри в версията на Android Q. Според Селим Чинек:
„В SystemUI например имахме различни големи усилия за рефакторинг в Q, за да намалим използването на RAM от известия и други повърхности.“
Ще получим ли най-накрая безжичен ADB?
Ако искате безжично да дебъгвате телефона си, ще трябва да руутнете устройството си. Джамал Исън от екипа на Android Studio казва че в момента се занимават с осъществимостта на тази функция.
Google все още ли тества на таблети?
XDA признат разработчик Luk1337 попита дали Google все още тества AOSP UX на таблети. Това е справедлив въпрос, като се има предвид недостиг на добри таблети с Android и на наличие на грешки в текущите версии. Алън Хуанг казва че Google все още "тества и поправя всяка година" и че компанията работи в тясно сътрудничество с партньори, "за да осигури добро изживяване с Android таблети."
Има много повече публикации в цялата нишка в Reddit. Това, което разгледах тук, обобщава цялата нова информация, която научихме, но няколко служители на Google (особено Dianne Hackborn) навлизат в мотивите си зад изрязването на функцията X или неприлагането на Y разрешение. Препоръчвам ви да прочетете пълния AMA, ако искате да разберете малко по-добре вземането на решения от екипа на Android.
Прочетете пълния AMA на /r/AndroidDev