Вы обновили compileSdkVersion до 35, а minSdkVersion оставили на 26. Через неделю в продакшене на Android 10 падает NoSuchMethodError. Silent failure из-за отсутствия NotificationChannel на Android 7 — пользователи жалуются, что нет уведомлений. Такие баги возникают, когда код использует API новее минимальной версии ОС. Мы сталкивались с этим десятки раз и научились выявлять такие проблемы до релиза. Наша услуга — кроссверсионное тестирование мобильного приложения — гарантирует, что все функции работают корректно на каждой поддерживаемой версии ОС, без артефактов UI и вылетов. Закажите аудит совместимости и получите матрицу версий за 2 дня.
Тестирование совместимости: полный цикл проверки на разных версиях ОС
Как выбрать матрицу версий для тестирования совместимости?
Тестировать каждую версию ОС нерационально. Мы используем принцип приоритетов, основанный на аналитике и требованиях проекта.
| Приоритет | Версии iOS | Версии Android |
|---|---|---|
| Обязательно | Текущая − 1 (например, iOS 17, 18) | Android 12, 13, 14 (API 31–34) |
| Важно | minDeploymentTarget (например, iOS 15) |
minSdkVersion (например, API 26–28) |
| По аналитике | Версии с долей > 5% у вашей ЦА | То же |
Аналитика Firebase или Mixpanel по полю os_version даёт реальную картину. Если 8% пользователей на iOS 15 — тестируем эту версию. Если 0.3% на iOS 14 — пропускаем. Такой подход сокращает объём работ без потери качества. Кроме того, полезно включить в матрицу версии, на которых произошли крупные изменения API — например, Android 12 (API 31) с изменённым exported в intent-фильтрах.
Почему deprecated API — главная проблема совместимости?
Разрыв между minSdkVersion и compileSdkVersion — 8 лет эволюции API. Пропустить одну deprecated-замену — и приложение падает на старых версиях. Мы системно ловим такие проблемы с помощью статического анализа и точечного тестирования.
Android: три частые ловушки
Уведомления (API 26+). На Android 8+ все уведомления требуют NotificationChannel. Без него notify() тихо игнорируется. Код проверки:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) { val channel = NotificationChannel(CHANNEL_ID, "General", NotificationManager.IMPORTANCE_DEFAULT) notificationManager.createNotificationChannel(channel) } Разрешения (API 33+). READ_EXTERNAL_STORAGE заменён на гранулированные READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO. Запрос старого разрешения на Android 13 не даёт доступа к медиа.
Foreground Service (API 34+). Android 14 требует указывать тип foreground service (dataSync, mediaPlayback и др.) — без него SecurityException.
| API | Версия Android | Типичная проблема |
|---|---|---|
| NotificationChannel | API 26+ | Без channel notify() игнорируется |
| Granular media permissions | API 33+ | READ_EXTERNAL_STORAGE не работает |
| Foreground service type | API 34+ | SecurityException без типа |
Инструмент для проверки: lint с правилом NewApi. Он автоматически находит вызовы API, доступные выше minSdkVersion без @RequiresApi или проверки Build.VERSION.SDK_INT. Опыт показывает, что lint находит 80% проблем до запуска.
iOS: @available и #available
if #available(iOS 16.0, *) { NavigationStack { ... } } else { NavigationView { ... } } Компилятор предупреждает об использовании нового API без проверки — это ловится статически. Но в больших кодовых базах такие предупреждения теряются. Самые частые жертвы: ContentUnavailableView (iOS 17), NavigationStack (iOS 16), Charts (iOS 16) — без fallback приложение падает с dyld: Symbol not found. Подробнее — в документации @available.
Инструмент для iOS: Xcode Simulator
Скачиваем дополнительные runtime: Xcode → Settings → Platforms → + → iOS 15.x Simulator Runtime. После загрузки создаём симулятор и проверяем на нём.
Как автоматизировать поиск deprecated API?
Статический анализ с lint и Xcode Build & Analyze находит несовместимости в 10 раз быстрее ручного поиска. Мы запускаем его в CI на каждый PR. Для более глубокой проверки используем Firebase Test Lab — виртуальные устройства с разными API-уровнями. Это быстро, дёшево и покрывает большинство несовместимостей. Например, на одном из проектов мы нашли 12 deprecated API до релиза, что сэкономило клиенту значительную часть бюджета на исправления в продакшене.
Как мы тестируем без реальных устройств?
Эмуляторы покрывают 90% случаев. Реальные устройства нужны только для специфических прошивок (Samsung, Xiaomi) или аппаратных особенностей (камера, NFC). Мы комбинируем:
- В CI: прогон lint + сборка с
-Werrorдля iOS. - Smoke-тесты на эмуляторах с минимальной, средней и текущей версиями ОС.
- Firebase Test Lab для интеграционных сценариев.
Это даёт быструю обратную связь без затрат на физические девайсы. Вы экономите на дорогостоящих исправлениях после релиза и оптимизируете бюджет на тестирование.
Процесс работы
- Аудит текущей
minSdkVersion/minDeploymentTargetи аналитика распределения версий. - Составление матрицы поддерживаемых версий с приоритетами.
- Статический анализ на deprecated API (lint/Xcode) с полным списком найденных проблем.
- Тестирование на приоритетных версиях (smoke + точечное).
- Отчёт с матрицей совместимости и рекомендациями по исправлению.
- Консультация по спорным моментам и помощь с исправлением кода.
Свяжитесь с нами, чтобы обсудить ваше приложение и получить индивидуальный план тестирования.
Что входит в работу
- Документация: матрица поддерживаемых версий с приоритетами, список найденных несовместимостей, рекомендации по исправлению.
- Доступы к отчётам в Firebase Test Lab и CI-логам.
- Консультации по исправлению кода и адаптации под старые версии ОС.
- Поддержка в течение 5 рабочих дней после сдачи отчёта.
Опыт нашей команды — более 7 лет в мобильной разработке, 40+ протестированных приложений с аудиторией от 50 000 пользователей. Оценим ваш проект за 2 дня. Свяжитесь с нами, чтобы получить консультацию. Закажите тестирование и получите полный отчёт с матрицей совместимости.