Какую минимальную версию Android используешь в проектах?

Минимальная версия Android в проектах: стратегический выбор

При выборе минимальной версии Android (minSdkVersion) в проектах я руководствуюсь не единым жестким правилом, а комплексной стратегической оценкой, которая балансирует между доступностью для пользователей, техническими возможностями и экономикой разработки. На практике это чаще всего API 21 (Android 5.0 Lollipop) или API 23 (Android 6.0 Marshmallow), но контекст проекта может изменить это решение.

Ключевые факторы, влияющие на выбор

1. Целевая аудитория и статистика рынка. Я регулярно анализирую официальные данные Google Play Console и отчеты аналитических компаний. Если проект ориентирован на широкую массовую аудиторию, особенно в регионах с большим количеством старых устройств, выбор более низкой версии (например, API 21) может значительно расширить потенциальную базу пользователей. Для нишевого или высокотехнологичного продукта допустима более высокая минимальная версия.

2. Технические требования проекта. Современные библиотеки и архитектурные подходы часто требуют определенного уровня API.

    *   **Jetpack Compose:** Для полноценной поддержки требует минимум API 21, но для стабильной работы всех функций лучше API 24.
    *   **Новые API платформы:** Например, **WorkManager** для надежного бэкграунд-обработки или **BiometricPrompt** для единого стандарта биометрической аутентификации появились позже и могут повлиять на выбор.

1. Снижение затрат на разработку и поддержку. Поддержка очень старых версий (например, API 14-19) оборачивается:

    *   **Значительными накладными расходы:** Необходимость писать ветви условного кода (`if (Build.VERSION.SDK_INT >= ...)`), использовать **поддержки библиотеки (Support Library)** вместо **AndroidX**, искать альтернативы для отсутствующих системных функций.
    *   **Повышенной сложностью тестирования:** Необходимость иметь эмуляторы или устройства с этими версиями.
    *   **Потенциальными проблемами безопасности:** Старые версии Android не получают критических обновлений безопасности.

Пример практического подхода и кода

Рассмотрим ситуацию, когда мы хотим использовать BiometricPrompt (появился в API 28), но поддерживать устройства с API 23. Решение заключается в проверке версии SDK и предоставлении альтернативной реализации для более старых устройств.

fun authenticateUser(context: Context) {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {
        // Используем современный BiometricPrompt на API 28+
        val biometricPrompt = BiometricPrompt(
            context,
            object : BiometricPrompt.AuthenticationCallback() {
                override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) {
                    // Обработка успеха
                }
            }
        )
        val promptInfo = BiometricPrompt.PromptInfo.Builder()
            .setTitle("Вход в систему")
            .build()
        biometricPrompt.authenticate(promptInfo)
    } else {
        // Fallback для API 23-27: используем FingerprintManagerCompat
        val fingerprintManager = FingerprintManagerCompat.from(context)
        if (fingerprintManager.isHardwareDetected) {
            // Старая реализация через Fingerprint API
        } else {
            // Альтернатива: пароль или PIN
        }
    }
}

Моя текущая позиция и рекомендации

Для большинства новых проектов в 2023-2024 годах я рекомендую и устанавливаю minSdkVersion = 23. Этот выбор обеспечивает:

• Широкий охват: Покрывает подавляющее большинство активных устройств (более 90% согласно статистике).
• Критически важные возможности: Включает модель разрешений Runtime Permissions, что фундаментально важно для современной безопасности и UX.
• Стабильную базу для современных библиотек: Полная совместимость с AndroidX, Jetpack компонентами и большинством популярных сторонних библиотек.
• Снижение порога входа для разработчиков: Не нужно углубляться в архаичные API.

В файле build.gradle модуля это выглядит так:

android {
    defaultConfig {
        minSdkVersion 23
        targetSdkVersion 34 // Нацеливаемся на последнюю стабильную версию
        compileSdkVersion 34
    }
}

Итог: Минимальная версия — это не технический каприз, а бизнес-техническое решение. Я начинаю с анализа рынка и требований продукта, и лишь затем фиксирую minSdkVersion, всегда готовый адаптировать его с учетом новых данных и трендов, чтобы проект оставался жизнеспособным, безопасным и экономичным в разработке.