🤖Как не утонуть в океане версий 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
🏝Основы AGSL для android разработчика (17м)
AGSL (Android Graphics Shading Language) — это язык программирования фрагментных шейдеров, представленный в Android 13 (API 33), который позволяет разработчикам создавать сложные графические эффекты, настраивать отрисовку Canvas и фильтровать содержимое View. Он глубоко интегрирован в графический движок Android (Skia), что позволяет применять GPU-ускоренные эффекты напрямую к стандартным элементам интерфейса .
Классная статья, которая описывает простым языком как рабоатет AGSL и какие преимущества дает разработчикам, а также как его начать использовать
#Android
Вот бы классно чтобы все как Uber перешли на Credential Manager API и перенос аккаунтов стал проще для пользователей, а бизнесу дешевле
Подробности в статье от разработчика
#android
🤖Получи ранний доступ к новой системе верификации Android разработчиков
Google открыла прием заявок к раннему доступу в консоль верификации Android разработчиков, которые распространяют приложения за пределами Google Play. Подробности про систему в видео
Подать заявку можно тут (ссылка без спец средств не работала из Беларуси)
#android
🤖Есть ли чувство юмора у разработчиков Android SDK? Однозначно — да!
В исходниках можно найти такие шедевры 👇
// Проверяет используется ли сейчас Monkey Runner
ActivityManager.isUserAMonkey()
UserManager.isUserAGoat()
UserManager.DISALLOW_FUN
// Отдали дань памяти хиту
Chronometer.isTheFinalCountdown()
Log.wtf()
// Попало в релиз, хотя явно должно было быть исправлено
AdapterViewFlipper.fyiWillBeAdvancedByHostKThx()
// Звёздные войны
SensorManager.GRAVITY_DEATH_STAR_I
Разработчики в Google точно любит пошутить 😄
А вы где встречали весёлые названия API или переменных — в Android, KMP или своих проектах?
#android
🤖Появились уточнения касательно процесса верификации Android разработчиков
‼️ Самое важное - разработчики всё также смогут ставить приложения без регистрации через ADB. Вот она лазейка 😁
#android
🤯Последний гвоздь в крышку Nova Launcher - создатель лаунчера покинул компанию, которая купила проект и команду в 2022
Kevin Barry создатель и глава команды разработки оставил проект Nova Launcher. Как обещали ранее, выпускать код в open source не стали и вообще будущее туманное, потому Kevin был последним из 12 человек команды в компании.
Бренд точно останется, но вот это уже будет не тот Nova Launcher, который завоевал сердца пользователей.
Ставьте ❤️ если вы используете или использовали лаунчер
#android
🤖Device Info Library - open-source Kotlin библиотека для Android с API для получения информации о характеристиках устройства.
val sdk = DeviceInfoSDK.getInstance()
// Collect all information at once
val deviceReport = sdk.collectAllInfo()
// Access specific information types
val hardwareInfo = deviceReport.getHardwareInfo()
val systemInfo = deviceReport.getSystemInfo()
val networkInfo = deviceReport.getNetworkInfo()
#android
🤖Scrcpy-GUI - приложения для Windows чтобы управлять Android устройством на основе scrcpy
scrcpy - позволяет зеркалировать экран устройства, управлять им. Можно и без показ экрана делать записи и скриншоты. Тулза очень полезная
До того как функционал зеркалирования появился в Android Studio scrcpy активно использовал для запуска приложения на устройстве, а управлением с компа. Или когда демо проводил.
#android