Android Broadcast

🤖Как не утонуть в океане версий Android: расставляем приоритеты в поддержке Каждый Android-разработчик сталкивался с этой болью: сотни версий ОС, десятки производителей с уникальными оболочками, тысячи моделей устройств. И все это нужно поддерживать. Или нет? Я считаю, что не нужно. И вот почему. Ресурсы тестирования конечны. Ваша команда — не Google с его армией QA-инженеров (да и им не хватает на всё). У вас ограниченное время, бюджет и люди. Попытка качественно поддерживать все версии Android, все оболочки вендоров и все устройства — прямой путь к выгоранию команды и багам в проде. Лучше отлично поддерживать 70-80% пользователей, чем посредственно — 100%. 1️⃣Анализируйте данные регулярно Google Play Console — ваш главный источник правды. Там есть всё: распределение по версиям Android, моделям устройств, размерам экранов. Альтернативно используйте Firebase Analytics, Amplitude или любую другую систему аналитики, которая у вас встроена. Важно смотреть на тренды. Если доля Android 6.0 упала с 5% до 1% за полгода — это сигнал пересмотреть поддержку. Рекомендую проводить такой анализ минимум раз в квартал, максимум — раз в год. Привяжите это к циклу планирования или мажорным релизам. 2️⃣Считайте не головы, а деньги У вас 1000 пользователей на Android 6.0? Звучит внушительно. Но задайте себе три вопроса: — Сколько из них активны за последний месяц? — Кто из них делает заказы / смотрит рекламу / оформляет подписки? — Какой у них engagement по сравнению с пользователями на свежих версиях? Если это мертвые души или их монетизация стремится к нулю — может, стоит сокращать поддержку этих версий ОС? Пример из практики: 1000 пользователей на Android 7 могут приносить $50/месяц, а 200 на Android 14 — $2000. Какую версию вам выгоднее поддерживать и проще? 3️⃣Сегментируйте пользователей Не все пользователи одинаково важны. Разделите их на категории: Сегмент A — высокий LTV, активные, платящие Сегмент B — средняя активность, периодические покупки Сегмент C — низкая активность, бесплатные пользователи Теперь посмотрите на распределение этих сегментов по версиям Android. Возможно, окажется, что ваши самые ценные пользователи уже давно на Android 10+, а на старых версиях сидят только "зомби". Это даст вам аргументы для приоритизации — и для разговора с бизнесом. 4️⃣Внедрите систему тиров поддержки Вместо бинарного "поддерживаем/не поддерживаем" используйте гибкую систему приоритетов: Tier 1 — Критичные версии Android 11-16 (условно — актуальные версии) Покрывают 70-80% вашей базы Уровень поддержки: полное ручное тестирование всех фичей перед каждым релизом, быстрые хотфиксы при багах Tier 2 — Важные версии Android 8-10 Покрывают еще 15-20% пользователей Уровень поддержки: проверка основных сценариев вручую + автотесты, хотфиксы по приоритету Tier 3 — Минимальная поддержка Android 7 Остаток пользовательской базы Уровень поддержки: только автотесты на smoke-сценарии, приложение работает, но активно не тестируется. Баги фиксим, только если они критичные Tier 4 — Best effort Всё, что осталось (Android 5-6 и старше) Совсем старые версии, которые еще технически поддерживаются Уровень поддержки: билд собирается, но тестирование отсутствует. Поддержка только на основе user reports Важно: границы тиров будут разными для каждого проекта. Ориентируйтесь на свою аналитику, а не на чужие цифры. 5️⃣Коммуникация с командой и стейкхолдерами Самое сложное — донести эту стратегию до бизнеса и команды. Для бизнеса важны цифры: сколько стоит (денег и времени) и сколько приносит, как можно инвестировать это время Для команды ценность понятна и так — четкие критерии избавляют от хаоса в процессах. Разработчики и QA будут знать, на что тратить время, а на что — нет. Также на принятие решение может влиять сложность поддержки старых версий Android, так как со временем Google и популярный Open Source постепенно откажется от этих версий. Apple вообще тут поступает жестко и убирает в XCode поддержку версий ОС. Например, сейчас Google поддерживает только Android 6.0+ #Android

🤖Посмотрел на обновлённую статистику распространения версий Android на 1 декабря 2025 и вот что интересно. 📈 Android 16 набирает обороты быстрее предшественников За два месяца после релиза Android 16 (API 36) уже захватил 7,5% рынка. Для сравнения, Android 15 (API 35) за аналогичный период имел всего 4,5%. Такой стремительный рост объясняется новой стратегией Google — Android 16 вышел раньше обычного (во втором квартале вместо третьего) и был разделён на два релиза. Это дало производителям больше времени на подготовку обновлений, и многие флагманы 2025 года уже выходили с Android 16 из коробки. ✔️ Минимальная версия: Android 7.0 всё ещё актуален Если смотреть на цифры, то Android 7.0 Nougat (API 24) и выше охватывает 99,2% устройств. Это значит, что отказавшись от поддержки Android 6.0 Marshmallow, вы теряете меньше 1% аудитории. Но помните — это глобальная статистика. Обязательно проверьте свою консоль Google Play: в некоторых регионах или нишах (например, бюджетные устройства для развивающихся рынков) картина может сильно отличаться. ⚖️ Что изменилось за 8 месяцев С апреля (пост с прошлой статой) по декабрь 2025 года произошёл серьёзный сдвиг поколений. Android 14 вырос с 31,9% до 44%, став фактическим лидером. Android 13 упал с 48,7% до 57,9% (кумулятивно), но всё ещё держит солидную базу. А вот старички Android 11 и ниже продолжают уверенно терять позиции — теперь на них меньше 30% устройств против 38,5% восемь месяцев назад. Интересно, что Android 15 за это время вырос до 26,8%, хотя многие производители только начали раскатывать обновления. Samsung, Xiaomi и другие гиганты обычно тянут с апдейтами до весны следующего года, так что пик Android 15 мы увидим ближе к середине 2026. 🏆Лидер всё тот же - Android 14 Самая популярная версия сейчас — Android 14 (API 34) с долей 44%. Это логично: устройства 2024 года выходили именно на этой версии, плюс многие флагманы 2023 года получили обновление. Android 13 на втором месте с 13,9% чистой доли (57,9% - 44% = 13,9%), но его позиции постепенно размываются. Для разработчиков это означает простую вещь: если вы таргетируетесь на API 34 (что обязательно для новых приложений в Google Play), вы автоматически находитесь на самой массовой платформе. А вот с минимальной версией стоит балансировать между охватом и необходимостью поддерживать легаси-код. Android 8.0 Oreo (API 26) даёт вам 98,4% охвата, что для большинства проектов более чем достаточно. 💬 В комментах делитесь совпадает ли статистика Google с реальностью вашего приложения #Android

🤖 Разбираюсь с системой разрешений в Android и снова упираюсь в один и тот же вопрос: почему до сих пор нет AndroidX‑решения, которое бы упростило всю эту рутину? В каждом проекте встречается тонны похожего кода для работы с разрешениями — и чаще всего без учёта лучших практик. Разработчики нередко просто запрашивают разрешение “в лоб”, не обрабатывая отказы корректно. Если пользователь отказал — то сразу перекидывают в настройки, и на этом всё. Google, кажется, слишком усложнила саму концепцию. Система разрешений должна была быть прозрачной и удобной для разработчика, но на практике реализована ею далеко не всегда. Один из выходов, который вижу — жёстче ревьюить сценарии работы с разрешениями и проверять, насколько реализация соответствует рекомендациям платформы. 💬Какой у вас опыт от запроса разрешений в Android? #Android

🤖 Если используете AndroidX Paging, то вам стоит обновить код. Для лучшего определения позиции на основе которой генерировать ключ для обновления появилось API PagingState.closestItemAroundPosition() override fun getRefreshKey(state: PagingState<Int, UiItem>): Int? { val anchor = state.anchorPosition ?: return null val closestItem = state.closestItemAroundPosition( anchorPosition = anchor, // например, пропускаем разделители/заглушки predicate = { it.isAnchorable } ) return closestItem?.id } #Android#AndroidX

🤖Улучшения R8 - минификатора кода в Android В AGP 9.0 R8 получил несколько изменений, в основном направленных на оптимизацию Kotlin-кода, упрощение desugaring-пайплайна и улучшение диагностики. Основные изменения: 👉 Новая опция -processkotlinnullchecks для обработки null-проверок, сгенерированных компилятором Kotlin. Можно задать одно из значений: - keep - оставить проверки; - remove_message - убрать сообщения об ошибках; - remove - полностью удалить проверки. Опция используется для уменьшения байткода и снижения runtime-накладных расходов в production. Я еще в 2019 писал статью про это и удалял код с помощью -assumenosideeffects 👉 Keep rules больше не применяются к companion methods R8 перестал переносить keep-информацию на синтетические companion-методы, сгенерированные при desugaring интерфейсов. Это ломает редкий кейс с minSdk < 24, но делает поведение более консистентным с остальными синтетическими элементами. 👉 Минимизированные имена синтетических классов в L8 L8 теперь генерирует более короткие имена для synthetic-классов ($1, $2 вместо длинных $$ExternalSynthetic...), что уменьшает размер DEX. L8 — это утилита, стоящая за library desugaring в Android. Позволяет использовать новые API на старых версиях Android и править баги в них, делая использование API прозрачным. AGP 9.0 прокачало R8 и L8, чтобы делать меньше лишнего байткода, более агрессивно оптимизировать Kotlin. Большинство изменений работают прозрачно, но в сумме дают более компактные сборки и более предсказуемый build-процесс. 🔗 Источник - документация по AGP 9.0 #Android#AndroiDev#Gradle#R8

🤖 Android Gradle Plugin 9 упрощает запуск unit-тестов По умолчанию Android Gradle Plugin создаёт Gradle-задачи для запуска unit-тестов во всех доступных build types, что на практике почти никогда не нужно. Обычно тесты запускаются только для debug-сборки. В реальных проектах (особенно с product flavors и большим количеством модулей) это приводит к сотням лишних задач, увеличению времени конфигурации и дополнительной нагрузке на IDE и CI. Чтобы оптимизировать работу Gradle, начиная с AGP 9.0, можно в gradle.properties добавить: android.onlyEnableUnitTestForTheTestedBuildType=true После этого unit-тесты будут генерироваться только для основного тестируемого build type (как правило, debug). Это: 👉 убирает лишние Gradle-задачи; 👉 сокращает время конфигурации проекта; 👉 снижает потребление памяти; 👉 ускоряет локальную разработку и CI-пайплайны. Если вы не запускаете unit-тесты для release-сборок (а так делают почти все), то включение этого флага — бесплатная оптимизация сборочной инфраструктуры. Это хороший пример того, как дефолтные настройки инструментов ориентированы на универсальность, а не на эффективность, и почему их стоит регулярно пересматривать в контексте реальной архитектуры проекта. #Android#AndroidDev#Gradle

🏝Когда стоит убить Kotlin демона для ускорения сборки Если у вас тяжёлая Android-сборка (много модулей, R8, CI с ограниченной памятью), имеет смысл принудительно завершать Kotlin Daemon после компиляции и до запуска R8 🔪 Kotlin Daemon нужен только на этапе компиляции Kotlin. После этого он спокойно живёт до конца сборки и держит память. R8 — один из самых прожорливых этапов по CPU и RAM 🔥 По итогу Daemon и R8 начинают конкурировать за ресурсы памяти Что вы реально получаете если убивает Kotlin демона после компиляции кода: 🚀 снижение пикового потребления памяти примерно на 13–15% 🚀 ускорение R8 вплоть до ~7% 🚀 небольшое, но стабильное сокращение общего времени сборки 🚀 максимальный эффект на CI, где нет долгоживущих демонов и инкрементальности ‼️ Этот подход сработал для автора статьи, но для вас может ничем и не помочь, особенно в сборке на локальной машине. 🔗Источник с измерениями и подробным разбором #Android#Kotlin#R8#Gradle

🛒Save for Later — больше гибкости для релизов в Google Play Console Google запустил функцию "Save for later" в Google Play Console. Теперь можно контролировать, какие изменения отправлять на ревью, а какие пока отложить. Раньше все изменения автоматически группировались и отправлялись на ревью вместе. Это создавало сложности: 👉 Приходилось задерживать hot fix или публиковать изменения, которые ещё не готовы 👉 Нельзя было разделить обновление тестовых треков и маркетинговые изменения 👉 Сложно было поменять решения касательно релиз на ходу Теперь в разделе "Changes not yet sent for review" можно отметить группы изменений как "Save for later". Эти изменения: 👉 Не попадут в текущее ревью 👉 Можно в любой момент вернуть обратно 👉 После начала ревью автоматически вернутся в очередь Функция работает вместе с проверками перед ревью. Новая фича позволяет быстрее итерировать и минимизировать влияние реджектов на график релизов. Особенно полезно, когда часть изменений готова, а часть — нет. 🔗Подробности в блоге 💬В комментариях расскажите сталкивались ли вы с подобной задачей и что новая функция упростит вам работу #Android#GooglePlay

🤖Запустить Linux Desktop на Android вполне реально и понятно как. Проект Local Desktop позволит вам это сделать. Запуск происходит через виртуализацию, доступную на Android 16. На скриншоте к посту Linux, запущенный на Pixel Tablet. #Android#Linux

🚀Google взялась за упрощение Picture‑in‑Picture PiP на Android долго был зоопарком: разный API на версиях, разный UI‑стейт, много if (SDK_INT…) и бойлерплейта. Новая Jetpack‑библиотека androidx.core:core-pip как раз и создана, чтобы это спрятать: она выравнивает вызовы PiP между версиями Android, даёт единый способ задавать параметры (особенно для видео/плееров), объединяет разрозненные колбэки состояния PiP и уменьшает количество кода за счёт готовых пресетов действий для типовых сценариев. Требования: обновляем Activity Чтобы всё это заработало, мало просто подключить core-pip — нужно обновиться до свежей Activity 1.13.0 (пока в альфе). В этой версии есть новые API для отслеживания состояния PiP (PictureInPictureUiStateCompat и слушатели), на которых удобно строить логику поведения UI, когда окно уходит в PiP или, например, «прячется» в угол. // Пример кода: реагируем на состояние PiP class PlayerActivity : ComponentActivity() { private val pipUiStateListener = Consumer<PictureInPictureUiStateCompat> { state -> if (state.isStashed) { /* спрятать контролы плеера */ } else { /* показать контролы плеера */ } } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) // ... инициализация UI / плеера ... addOnPictureInPictureUiStateChangedListener(pipUiStateListener) } override fun onDestroy() { removeOnPictureInPictureUiStateChangedListener(pipUiStateListener) super.onDestroy() } } 🔗 Подробности про библиотека в документации #Android#AndroidDev#AndroidJetpack#PIP

🤯Dagger Hilt блокирует переход на AGP 9.0 UPD. 21 января вышел Dagger 2.59 с поддержкой AGP Android Gradle Plugin 9.0 официально зафиксировал новый стабильный конфигурационный API (вышла стабильная версия с релизом AS Otter FD 3) — это одно из самых значимых изменений в инфраструктуре Android и Kotlin Multiplatform за последние годы. Цели понятны и правильные лучше работа с кэшем и общая скорость сборок. Подробнее про все изменения я писал в отдельном посте Google несколько релизов подряд аккуратно готовил экосистему к этому переходу, заранее добавив новый API и дав время авторам плагинов адаптироваться. Но на практике всё упирается в плагины. Я столкнулся с тем, что Gradle-плагин Dagger Hilt до сих пор использует старую модель конфигурации и несовместим с новым DSL из AGP 9.0. В результате проект нельзя перевести на новую версию без отключения Hilt или включения режим совместимости. Иронично, что именно официальный инструмент от Google сейчас становится блокером для обновления. Да, в AGP оставили compatibility-флаги, позволяющие продолжать сборку по старым правилам. Это спасает проекты от немедленного падения, но полностью отключает все ключевые преимущества AGP 9.0 — configuration cache, ускоренную конфигурацию и новую модель плагинов. 💬 Вы уже пробовали миграцию на AGP 9.0? Что блокирует? Делитесь в комментариях мнением. UPD. По заявлениям подписчиков также есть проблемы в работе KAPT и KSP #Android#AndroidDev#Gradle#Dagger#Hilt

🔨Включите эту настройку в Android Studio чтобы получить доступ ко всем AI фичам. Копался в новых фичах Android Studio и не могу понять почему у меня нету фичи ⭐️ "Generate Compose Preview". Изучал почему, а потом случайно нашел, что надо включить шаринг контекста всего проекта и в меню появились дополнительные опции. Сделано супер неочевидно. #AndroidStuduio#Android#AndroidDev#AI