Фрагментация Android: минимальная версия ОС и устройства для тестов

Короткий ответ

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

1. minSdk выбирают по данным, а не «чтобы работало везде»: смотрят, сколько пользователей вы теряете при отказе от старой версии, и сравнивают с ценой её поддержки.
2. Тестируют на матрице, которая покрывает ключевые различия: версии, производителей, мощность железа и размеры экранов.

Три параметра SDK, которые путают

android {
    compileSdk = 36        // с каким SDK компилируется проект
    defaultConfig {
        minSdk = 26        // самая старая поддерживаемая версия Android
        targetSdk = 36     // под поведение какой версии адаптировано приложение
    }
}

Значения здесь для примера. Важно различать:

• minSdk определяет, на каких устройствах приложение вообще можно установить. Это решение о бизнесе и аудитории.
• targetSdk Google Play регулярно требует поднимать до свежего уровня, иначе не получится выпускать обновления. Это обязательство, а не выбор.
• compileSdk обычно равен последней стабильной версии.

Откуда брать данные

• Android Studio при создании проекта показывает распределение версий API — это глобальная картина.
• Play Console для уже опубликованного приложения показывает версии Android и модели устройств ваших реальных пользователей.
• Ваша аналитика — данные о моделях и версиях ОС из мобильной аналитики или веб-сайта, если приложения ещё нет.
• Региональная статистика — грубый ориентир по рынку.

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

Чего стоит поддержка старых версий

Учтите и внешний фактор: библиотеки Jetpack, Firebase и Google Play services периодически поднимают свой минимальный уровень. Держаться за очень старую версию может оказаться невозможно, даже если вы готовы её поддерживать.

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

Экраны и оболочки производителей

Экраны. Компактные и большие смартфоны, планшеты, складные устройства, вырезы под камеру, жестовая и кнопочная навигация. Отдельно проверяйте крупный системный шрифт: на нём ломается больше всего интерфейсов. Для адаптивной вёрстки используйте window size classes вместо привязки к конкретным разрешениям.

Оболочки. Samsung One UI, Xiaomi HyperOS и MIUI, ColorOS у OPPO и realme, оболочки vivo, Huawei и Honor ведут себя по-разному. Типичные проблемы:

• агрессивная экономия батареи закрывает фоновые задачи и задерживает push-уведомления;
• дополнительные разрешения на автозапуск и работу в фоне;
• собственные диалоги разрешений и настройки уведомлений;
• различия в работе камеры, файлов и WebView.

Фоновые задачи стоит строить на WorkManager, а пользователю в нужный момент объяснять, как отключить оптимизацию батареи для приложения.

Как собрать реалистичную матрицу устройств

1. Выпишите самые популярные модели вашей аудитории из аналитики.
2. Покройте ключевые измерения: минимальная и последняя версии ОС, основные производители, слабое устройство, маленький и большой экраны.
3. Разделите уровни: несколько физических устройств для ключевых сценариев, эмуляторы для версий ОС и экранов, облачные фермы вроде Firebase Test Lab для длинного хвоста.
4. Пересматривайте матрицу, когда меняется аналитика.

Пример набора:

Частые ошибки

• minSdk оставлен из шаблона без сверки с аудиторией.
• Тесты только на флагмане разработчика, а пользователи сидят на бюджетных моделях.
• targetSdk не обновляется вовремя, и выпуск обновлений блокируется.
• Не проверены крупный шрифт и тёмная тема.