В Android 13 появилась новая возможность – Photo Picker. Она позволяет получать доступ к отдельным пользовательским фото и видео без выдачи приложению полного доступа к фото/видео или вовсе всей памяти устройства. Хорошая функция для ограничения доступа приложения к личным данным пользователя. Сразу же было объявлено, что эта функция будет также работать на Android 11 и новее (с поддержкой Mainline обновлений), а еще позже её поддержку добавили на все устройства с Android 4.4 и выше через Google Play Services.

Я сразу задался вопросом, почему так не делали раньше? И ответ тут простой – Android не позволял такое реализовать, но благодаря тому, что Google боролась с фрагментацией и работала над возможностью независимого обновления Android, это стало реальностью.

В этой статье я буду рассказывать про большую боль Android – фрагментацию. Вы узнаете, что это такое, причины ее появления и почему она уже не так актуальна. Также расскажу про пути решения этой проблемы, которые Google делала на протяжении первых 10 лет существования Android и почему обновления устройств до свежих версий Android уже не будут так важны, как прежде.

Если вам интересно следить за самыми последними новостями Android разработки и получать подборку интересных статей по этой тематике, тогда вам стоит подписаться на Телеграм-канал Android Broadcast и мой YouTube канал "Android Broadcast"

Краткая история Android ОС

Чтобы понять проблемы, с которыми столкнулись разработчики ОС, нам надо погрузиться в прошлое. История Android начинается в 2004 году. Энди Рубен решил разработать операционную систему для цифровых камер, которые тогда были очень популярны. Но из-за проблем с финансированием и не таким уж и большим рынком цифровых камер систему переориентировали на смартфоны как конкурента Symbian и Windows Mobile.

В 2005 компанию покупает Google. Корпорация добра решила выйти на рынок мобильных телефонов, продавая свою операционку производителям устройств. В 2007 году был создан Open Handset Alliance, одновременно с которым анонсировали Android как открытую мобильную платформу.

Прототипы Android-устройств были похожи на смартфоны Blackberry: нет сенсорного дисплея, физическая QWERTY клавиатура. Одним словом – Blackberry. Наступает 2007 год, который ознаменовался выходом первого iPhone. Этот смартфон изменил рынок смартфонов, компьютеров и до сих пор задает тренды. Google участвовала в подготовке софта для первого смартфона Apple и поняла, куда дует ветер, поэтому в спешке стали переделывать Android.

Резко произошло изменение концепции Android-смартфона: сенсорный экран и минимум физических кнопок. Первый смартфон на Android – HTC Dream был гибридом изначального видения устройства Google и трендом, заданным Apple. Полная клавиатура пряталась под большим по меркам того времени сенсорным экраном.

Задача Android для первого релиза была проста – завестись на устройстве и как-то работать. Из-за ограниченности в ресурсах разработки на первых этапах брались уже готовые открытые, бесплатные и популярные технологии: ядро Linux, Java, OpenGL, FreeType, Skia. Ядро Linux не было взято в исходном виде, а переделано с особенностями мобильных устройств с малым количеством оперативной памяти и медленными процессорами, также разработали собственную JVM виртуальную машину – Dalvik, которая также отличалась от стандартной JVM машины с учетом малого количества оперативной памяти, одного ядра процессора и работе устройства от батарейки.

Также надо учитывать, что, в отличие от iOS, с самой первой версии Android был открыт инструментарий для разработчиков, а онлайн-магазин приложений Android Market (теперь известный как Google Play) запустили 22 октября 2008 года (на 4 месяца позже App Store для iOS).

Весь этот сложный и тернистый путь сказался на особенностях Android-системы и ее архитектуры. Я думаю у разработчиков так бывает часто: пилится MVP в простом варианте без закладывания масштабирования, потом еще прилетают новые требования, а сроки поджимают. Одно дело пилить приложение или бэкенд, но совсем другое, когда такие проблемы были заложены в операционную систему и софт так просто не обновишь.

Также нужно было понимать, что Google занималась лишь разработкой ОС, вендоры же брали систему, дорабатывали и обновляли независимо от корпорации. В развитии ОС, в первую очередь, Google сосредоточилась на развитии устройства с сенсорными экранами и поддержке актуальных технологий, нужно было увеличить скорость работы ОС, дать больше возможностей разработчикам и пользователям.

Фрагментация

Фрагментация – это проблема, связанная с тем, что на рынке существует огромное количество устройств, работающих на разных версиях операционной системы и с разными модификациями от производителей. Всё это не позволяло и до сих пор не дает гарантии того, что если приложение работает на эмуляторе или одном устройстве, то оно сможет работать корректно на всём спектре устройств.

Подобные проблемы приводят к тому, что разработчикам приходится тратить больше времени на разработку, адаптацию и тестирование приложений и делать это только под срез наиболее популярных устройств среди своих пользователей.

Вы можете увидеть визуализацию фрагментации Android-устройств на 2014 год, а на сегодняшний момент картинка будет только хуже. Адаптация свежих версий ОС также оставляет желать лучшего, но раньше все было хуже.

С одной стороны, фрагментации – это боль, но с другой – огромная возможность и простор для инноваций производителей устройств. Они могут реализовывать собственные функции, делать уникальный интерфейс и выделяться на фоне других. Благодаря этому мы увидели складные смартфоны, игровые, с E-inк дисплеями, слайдеры, модульные и другие форматы.

Если посмотреть смартфоны на Windows Mobile или Windows Phone, то все они были одинаковы в софте и во внешнем виде. Просто потому что Microsoft не дала возможности модификации ОС вендорам. У Nokia было такое право, но они решили им не пользоваться, чтобы не нарушать пользовательский опыт, который реализовали мелкомягкие. Что из этих решений хорошо или плохо, судить не мне, но рассудило время – ОС Android жива и процветает, являясь не только самой популярной мобильной ОС, но и даже среди десктопных ОС, а вся разработка мобильных версий WIndows закрыта в 2017, а поддержка в 2020.

Обновления вендоров

Также причиной фрагментации является и то, что каждый из производителей обновляет свои устройства независимо, что тоже является проблемой. Да и компаниям надо продавать новые устройства, чтобы зарабатывать.

Производители Android-устройств не могли делать это быстро из-за того, что их цикл обновления был последовательным: нужно получить исходники в AOSP и свежие драйвера для чипов в устройстве, затем смержить все полученные изменения со своей оболочкой, после этого надо адаптировать изменения из новой версии ОС в свою оболочку, а затем всё это отправить на устройства пользователей.

Этот процесс занимает время, очередь из моделей на обновление составляется по принципу “свежесть устройства и его цена”. Бюджетные модели и вовсе не обновлялись из-за того, что производитель не закладывал их поддержку. Были случаи, когда вендоры отправляли патчи пустышки – обновления по факту приходят, а в нем нет ничего. Такие обновления можно назвать “плацебо”, т.к. часть пользователей верит, что они делают их устройства быстрее и безопаснее.

Кажется, Google тут должна была что-то предпринять, но либо у нее не получалось это сделать, либо они боялись давить на производителей устройств на заре становления Android. Такие разборки делали с HTC, так как на старте они вообще не обновляли свои устройства, независимо от их цены.

Android Jetpack

Развитие новых версий Android SDK и медленное обновление устройств привело к тому, что рынок был наводнен множеством устройств со всеми возможными версиями Android. Бизнесу было важно, чтобы все эти устройства поддерживались, соответственно разработчикам ставилась задача. Код наводнялся простынями из конструкций `if…else` с проверкой версий Android.

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
    // КОД для Android 5.0 Lollipop и выше
} else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.ICE_CREAM_SANDWICH) {
    // КОД для Android 4.X
} else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
    // КОД для Android 3.X
} else {
    // КОД для всех остальных поддерживаемых в приложении версий Android
    // (minSdk из AndroidManifest и выше)
}

Google решила все это сделать самостоятельно для наиболее популярных API из Android SDK, представив Android Support Library, а позже реформировала её в Android Jetpack или еще ее называют AndroidX.

Она содержала множество различных Compat API, которое позволяло вызвать API из новых версий Android на старых. На старых версиях ОС это зачастую приводило к простому игнорированию вызова, хотя для части API происходили вызовы аналогов из старой версии Android SDK.

Следующим большим этапом стало портирование новых API, аналогов которых не было в старых версиях SDK. Сообщество начало это делать раньше, например, одна из самых популярных библиотек, которая сделала Jake Wharton легендой – ActionBarSherlock. Библиотека являлась первым вариантом App Compat и перенесла Action Bar из Android 3.0 на Android 2.

Почему это сделал энтузиаст, а не Google? Выход Android 3.0 очень сильно изменил Android, т.к. это была первая ОС с официальной поддержкой планшетов, а также первый раз в истории, когда Google не открыла исходный код Android.

Произошло это из-за боязни портирования свежей планшетной версии Android на смартфоны. В Honeycomb представили первую версию Holo – фирменного дизайна Android, который закрепился до 2014 года. Когда был представлен Android 5.0 и Material дизайн, актуальный даже сегодня, также появилась его третья версия – Material You.

Google Play Services для распространения функционала

Android Open Source Project (AOSP) – эта пустая версия Android ОС, в которой вы не найдете множества привычных для вас приложений и сервисов.

То что вы найдете на устройствах Samsung, Google, Xiaomi и других популярных производителей Android-смартфонов, это версия Android, сертифицированная Google, с Google Mobile Services: магазином приложений Google Play, поиском Google, браузером Chrome, Google Play Services, а также другой гуглософт, предустановленный по умолчанию.

Google Play Services – это фреймворк, который позволяет разработчикам использовать различные функции и сервисы от Google в своих приложениях. Этот фреймворк включает в себя такие функции как авторизация Google, местоположение, Firebase сервисы, Push сообщения, аналитику и другие сервисы, которые могут использоваться разработчиками для улучшения своих приложений. Без Google Play сервисов у вас не будет работать Google WearOS, которая через фирменные сервисы обеспечивает передачу данных между устройствами, а также часть функций из Android SDK.

Фирменные сервисы компании позволяют распространять обновления или давать функционал сквозь все версии ОС. Например, если вы будете изучать, как получить местоположение пользователя, то в официальной документации вы найдете руководство, которое базируется на Fused Location Provider из Google Play Services, а не API по работе с локацией в Android SDK.

Google Play Services устанавливается на большинстве устройств на Android и обновляется автоматически через Google Play Store. Все обновления в сервисах доставляются независимо от производителя устройства, оператора и версии Android. Это важный момент, так как Google может доставлять исправления багов, новые фичи и другие улучшения самостоятельно, в отличие от прошивок и библиотек, подключаемых разработчиками приложений. И это тоже способ борьбы с фрагментацией, когда компания не привязана к производителям устройств и может контролировать процесс обновления API самостоятельно. Рабочее решение, только оно требует от разработчиков подключения библиотек с клиентским API для взаимодействия с сервисом из Google Play Services.

Звучит, что все хорошо, но гугл сервисы стали и злом. Для установки Google Play и одноименных сервисов любой вендор должен выполнить строгие правила компании Google, которые включают в себя предустановку приложения, папку с приложениями компании на главном экране дефолтного лаунчера, а также много других скрытых частей и специальных условий для вендоров. Почему все на это идут? Google Play – самый крупный каталог Android-приложений, содержащий топ 1000 самых популярных Android-приложений. Все гайды от Google пропитаны использованием этих сервисов и все разработчики целятся на работы с сервисами Google, даже если их софт распространяется через другие магазины приложений. Это связано с тем, что гугл сервисы есть практически на любом популярном устройстве за пределами Китая. Google сервисы – царь и бог на Android-устройствах, а разработчикам только остаётся делать функции на основе их. Не надо думать, что при наличии возможности сделать свои сервисы с такими же привилегиями у другой компании, она ей не воспользуется. Иметь гарантии работы своих приложений на устройстве – цель любого разработчика, как прошивок, так и сторонних.

Вы можете вспомнить про AOSP и почему вендоры не станут использовать его? Это же открытый вариант Android? Для начала у него есть своя лицензия, которую тоже надо изучать. Везде в документации вы найдете формулировку “Открытый исходный код”, которая не означает общую доступность. Вы когда-нибудь использовали устройства на AOSP? Голый Android на Nexus и Pixel – это не AOSP. AOSP – это билд Android без магазина приложений, без нормальных стандартных приложений для работы с почтой и SMS, там не будет пушей, а часть рекламируемых Google функций будут попросту отсутствовать. Вот вендорам и остаётся два варианта: принимай условия Google или делай все сервисы сам и надейся, что устройство будут покупать, а разработчики адаптировать софт. По второму пути вынужденно пошла Huawei и устройства вендоров в Китае, так как там никогда не было гугл сервисов.

Для обычных пользователей Google Services стали неотъемлемой частью понимания Android ОС, а Google получает контроль над всеми устройствами, которые даже не производит, хотя он и не полный. Это логично. Ведь компания тратит огромные суммы на развитие и поддержку операционной системы, когда другие компании практически все наработки делают только для себя.

A/B System Updates

A/B обновления – это функциональность, которая позволяет обновлять устройство, не прерывая работу приложений и не затрагивая данные пользователя. Они работают путем загрузки дополнительного образа системы, который устанавливается на неактивном разделе, а затем переключается на активный раздел после перезагрузки устройства. Это позволяет устройству быстро переключаться между различными версиями системы без необходимости полной перезагрузки.

Вроде причем тут это к фрагментации, но новая система позволила делать прозрачные для пользователя обновления системы, которые не заставляют его ждать обновления в процессе загрузки устройства, а происходит простая незаметная перезагрузка, которую пользователю система может произвести, пока он не пользуется устройством. Заметить такое явно можно, когда ваше устройство просит разблокировки по кодовому паролю и отпечаток пальца или сканер лица не подходят. Установка обновления происходит во время работы устройства в фоне. Это все также медленно, но какая разница, если можно посидеть в любимых приложения и играх.

Direct Boot

Если перезагрузка устройства может происходить незаметно для пользователя, то как останутся работать приложения? Для этого сделали механизм Direct Boot, который позволяет приложениям работать до ввода пароля на устройстве. Приложение сможет использовать часть хранилища, которая не требует разблокировки пользователем, а достаточно загрузить устройство. Так вы без проблем получите SMS, телефонные звонки, будильники, пуш уведомления и др. Эта функция позволяет критическому функционалу остаться рабочим и не заподозрить пользователю, что устройство перезагружалось. Ход со стороны Google прекрасный, так как подготавливало Android к будущим изменениям для отвязки обновлений от производителей устройств.

Project Treble (Android 8)

Процесс обновления Android был небыстрым до Android 9. Причина в том, что производители устройства должны были получить обновления драйверов для всех чипов в устройстве, исходный код новой ОС, а затем адаптировать свою оболочку и другие наработки. В Google решили разорвать зависимости между этими частями.

Project Treble – это масштабное изменение в архитектуре Android, реализованное в Android 8 Oreo, которое разделяет ОС на две части: Android-систему и низкоуровневый софт для работы устройства (их еще называют реализацией вендора). Между ними был добавлен новый слой – интерфейс вендора, нечто подобное интерфейсу в коде. Разработчикам устройств предоставляется прослойка, которая имеет гарантии обратной совместимости и проходит специальные тесты – Vendor Test Suite (VTS).

Благодаря Project Treble появились Generic System Images (GSI), который собирается из исходников Android и гарантирует обратную совместимость с 3 предыдущими версиями реализации вендора. Это значит, что GSI Android 13 можно будет установить на любое устройство с Android 12, 11 и 10.

Поддержка Project Treble является обязательной для всех устройств, которые сразу выходили на Android 8 и выше. Для тех, кто обновлялся с предыдущих версий, это требование было необязательно.

Рефакторинг архитектуры системы позволил производителям быстрее обновлять устройства до новых версий Android, так как им не нужно ждать обновления драйверов. Вместо этого они могут работать со стандартизированным интерфейсом и заниматься своей частью адаптации прошивки.

Treble оказал эффект на скорость обновления устройств, что можно видеть на графике, а значит напрямую влияет на уменьшение степени фрагментации устройств, но это все равно не решало проблем со старыми версиями операционной системы. Они зависли мёртвым грузом, но новые версии со временем успешно вытесняли.

Если посмотреть на сегодня, то версии Android 8 и ниже не растут в долях, а вот версии новее только набирают обороты, Android 10 и выше занимает более двух третьих всего рынка.

Модульная система компонентов ОС (Project Mainline)

Project Treble был хорошим решением, но все равно оставил для Google зависимость от вендоров и от их оперативности и желания обновления устройств. Нужно было найти решение, чтобы обновлять устройства независимо от производителей.

Решение лежало на поверхности – разделить систему на части, которые можно доставлять через системный сервис на устройстве с полными правами. Так и появился Project Mainline в Android 10, который отделил системные компоненты и позволил им обновляться независимо от обычного цикла обновлений операционной системы.

Теперь вопрос: у кого в Android может быть достаточно прав, чтобы обновить модули? Конечно же Google Play Services! Но они не единственные, способные сделать это. Подойдет любой сервис с теми же правами от производителя устройства.

Обновление модулей не может предоставить новых API в рамках него, но может изменить поведение. С новыми версиями API модулей может расшириться, но будет гарантировать обратную совместимость. Стабильность этого гарантируется Compatibility Test Suite (CTS) – специальным набором тестов, с помощью которых Google проверяет реализацию API вендорами устройств. Все модули обновляются или откатываются автоматически.

Например, такая система позволила получить обновления сетевого стека и тайм зон без необходимости ожидания, когда это сделает вендор или разработчик приложения затянет новую версию базы данных.

APEX

Для распространения модулей в Android SDK появился новый формат файлов – APEX и утилита для его установки во время загрузки устройства – APEX Manager (apexer). APEX формат своей структурой напоминает APK, но APK не подходит, так как не может быть установлено на этапе загрузке операционной системы.

APEX файл является валидным APK файлом, потому что использует ту же схему подписи и содержит AndroidManifest, который обязателен для любого APK. Все это нужно, чтобы полностью использовать весь тулинг для APK файлов: установщик APK на устройстве, adb, утилиту для подписи, PackageManager API.

Android SDK Extensions

В Android 11 разработчики фреймворка пошли дальше и решили реализовать возможность добавления нового API для старых версий Android. Фактически эта возможность стала расширять Android SDK новыми API. Обновляемые модули теперь могут добавлять новые фичи, а Android SDK Extensions добавляют API для его использования разработчиками.

// Проверяем, что у нас Android 13
if (Build.VERSION.SDK_INT >= Build.VERSION_CODE.TIRAMISU) {
		// Запускаем PhotoPicker
		context.startActivity(Intent(MediaStore.ACTION_PICK_IMAGES))
}


// Код выполняется на Android 11 и выше
// Проверяем, что доступно расширение и оно нужной версии
if (SdkExtensions.getExtensionVersion(Build.VERSION_CODES.R) >= 2) {
		// Запускаем PhotoPicker
		context.startActivity(Intent(MediaStore.ACTION_PICK_IMAGES))
}

Результатом стало появление SDK Extensions модуля в ОС. SDK Extensions имеют версию, нечто подобную тому, как мы проверяем API с помощью Build.VERSION_CODE, но благодаря расширениям теперь в документации вы сможете увидеть, что описывается не только API level, где доступно API и набор SDK Extensions и его версия, которая будет содержать это API.

При настройке проекта нам нужно указывать теперь версию compileSdk, а также версию подключаемых расширений для SDK. Не забудьте предварительно его установить в SDK Manager из Android Studio. При использовании части фичей Android теперь проверяется не уровень Android SDK, а версию расширений, о чем вам напомнит Android Lint.

// build.gradle.kts
android {
    compileSdk = 33 // Android 13 T
		// Будет использоваться T Extentions
		// Указываем версию расширений. По умолчанию не подключаются
    compileSdkExtension = 5
}

Смысл новых версий Android

Остался главный вопрос, стоит ли ждать новых версий ОС и когда обновление с ней придёт на ваш смартфон? Я считаю, что нет. Каждая версия Android приносит все меньше новых функций для пользователей, а множество новых API для разработчиков подключаются через библиотеки в рамках Jetpack и Google Play Services. Все усилия Google направлены на то, чтобы иметь возможность полного контроля обновлений ОС, независимо от производителей устройств. Последние соскочить с Android так просто не смогут, альтернативных ОС попросту нет. Разработать свою – долго и дорого. Менеджеры корпорации добра сделали все очень верно, дав много свободы и возможностей, чтобы заманить к себе производителей и разработчиков, но уже не один год работают над тем, чтобы вернуть полный контроль себе и, как я рассказал вам, у них всё это получается.

Каждый год я разбираю очередной релиз ОС Android и вижу, как много происходит изменений под капотом: выделение новых Mainline модулей, интеграции технологий из Jetpack на уровень Android-фреймворка, интеграция новых технологий, связанных с железом. Это показывает, что Google делает Android для себя, частично своих партнеров, преследуя свои бизнес-интересы.

Пишите в комментариях, что вы думаете о тенденциях развития Android ОС. Я буду рад обсудить их с вами и взглянуть на ситуации под иным углом.