Как создать приложение для Android: гайд по разработке

В России перекос в пользу Android заметный, но за последний год он сократился. По данным Statcounter на март 2026 года расклад такой: Android 67,5 %, iOS 32,3 %. Годом раньше было 72 % против 27,6 % — доля iPhone за год выросла, хотя принято считать наоборот.

Вывод двойной. Android остаётся обязательной платформой: две трети пользователей — это весь рынок целиком. Но планировать продукт только под него больше не стоит, потому что треть аудитории, причём более платёжеспособная, сидит на iOS. Массовый российский смартфон по-прежнему средний по цене аппарат Xiaomi, Samsung, Realme или Tecno, и именно такие устройства задают требования к производительности.

Разницу между Android и iOS любят сводить к дизайну. На деле она в другом: iOS — это закрытая монолитная экосистема, где устройств мало и они предсказуемы, а Android — открытая платформа на тысячах разных аппаратов от десятков производителей. Это и есть фрагментация — главная техническая особенность Android, которая напрямую бьёт по бюджету тестирования.

Раскладывается она на несколько слоёв:

• Устройства и экраны. Тысячи моделей с разной диагональю, плотностью пикселей, вырезами под камеру, соотношениями сторон. Вёрстка должна тянуться от маленького бюджетника до планшета и складного экрана, вместо попадания в один размер.
• Версии ОС. В активном парке одновременно живёт несколько поколений Android. Здесь вступают в игру два параметра проекта: minSdkVersion — самая старая версия, которую вы соглашаетесь поддерживать, и targetSdkVersion — версия, под которую приложение оптимизировано. Опустить minSdk слишком низко — тянуть совместимость с архаикой и раздувать тесты; задрать слишком высоко — отрезать часть аудитории на старых аппаратах. Это продуктовое решение с понятной ценой.
• Оболочки производителей. «Чистый» Android есть мало у кого. One UI у Samsung, HyperOS (бывший MIUI) у Xiaomi, собственные надстройки у остальных меняют поведение системы — особенно в части уведомлений и работы в фоне. Приложение, которое идеально ведёт себя на «голом» Android, может молча не присылать пуши на Xiaomi из-за агрессивной экономии батареи.

К этому добавляются механики, которых на iOS либо нет, либо они устроены иначе: разрешения запрашиваются в рантайме (начиная с Android 6 пользователь даёт доступ к камере, геолокации и уведомлениям по ходу дела и может отозвать его позже), ограничения фоновой работы (режим Doze и лимиты на фоновые сервисы убивают наивные реализации синхронизации и пушей), scoped storage (с Android 10 приложение не лазит по файловой системе как попало).

Всё это — не экзотика, а базовые вещи, которые отличают живое приложение от падающего на половине устройств.

Практический смысл: проверить приложение на своём флагмане и выложить не получится. Команда, которая тестирует на одном дорогом телефоне, ловит баги уже в отзывах магазина.

Матрицу устройств для Android собирают по данным аудитории; количество телефонов в офисе роли не играет.

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

Отдельно проверяют поведение оболочек: агрессивное энергосбережение Xiaomi и Huawei убивает фоновые задачи и задерживает уведомления, и на чистом Android этот дефект не воспроизводится. Как устроено мобильное QA целиком, разобрано в материале про тестирование мобильного приложения.

Kotlin, и почему Java осталась в legacy

Новые Android-приложения пишут на Kotlin — с 2019 года это язык, который Google рекомендует по умолчанию: компактнее, безопаснее по работе с null, современнее. Java никуда не делась, но её роль теперь — поддержка больших старых проектов, начатых десять лет назад. Для нового продукта Java не выбирают; если подрядчик предлагает писать новый Android-проект на чистой Java, это либо очень специфический случай, либо повод задать неудобные вопросы.

Jetpack Compose или XML-вёрстка: выбор с позицией

Интерфейс под Android сегодня строят двумя способами, и выбор не вкусовой.

XML + View — классический императивный подход с полутора десятками лет истории: разметка в XML, логика в коде. Максимум готовых решений, поддержка самых старых версий, гигантская база примеров.

Jetpack Compose — современный декларативный тулкит: интерфейс описывается прямо на Kotlin, кода меньше, скорость разработки выше, проще делать анимации и динамические экраны.

Позиция на 2026 год: для нового проекта берут Compose — он стабилен, закрывает абсолютное большинство задач и заметно ускоряет работу, особенно в связке с Material Design 3. Классический View-стек остаётся там, где живёт большой legacy на XML, нужна поддержка совсем старых устройств или используются зрелые библиотеки, которых под Compose пока нет.

На практике крупные приложения часто гибридные: новые экраны на Compose, старые постепенно мигрируют. «Перепишем всё на Compose» ради моды — плохая причина; «возьмём Compose, потому что проект новый» — хорошая.

Android Studio, Gradle и что из этого важно заказчику

Разработку ведут в Android Studio — официальной среде с эмуляторами, отладчиком и редактором интерфейсов; внутри — Android SDK и система сборки Gradle. Для бизнеса здесь важны не названия инструментов, а одна вещь: сетевой слой (обычно на библиотеке Retrofit), сборка и зависимости — это та инфраструктура, которую подрядчик обязан настроить чисто, потому что от неё зависит, сможет ли другая команда подхватить проект.

Грязная сборка и спутанные зависимости — частая причина того, что приложение невозможно передать и развивать. Прозрачность здесь проверяют на старте, пока это ничего не стоит.

Мы по умолчанию предлагаем Flutter — и сразу объясним, где это правильно, а где честнее взять нативку. Подавать кроссплатформу как «всегда лучше» было бы тем самым снобизмом наоборот, которого мы избегаем — разбор подходов есть в материале про нативную и кроссплатформенную разработку.

Вот здесь Android расходится с iOS сильнее всего. На iPhone канал по сути один — App Store. На Android каналов несколько, и в российских реалиях 2026 года выбор между ними — не про удобство, а про то, сможете ли вы вообще принимать деньги.

RuStore: уже не опция, а база. Российский магазин стал обязательным к предустановке: требование действует с 2023 года, а летом 2025-го закон расширили — с 1 сентября 2025-го возможность установки и обновления RuStore (и мессенджера MAX) должна быть на всех продаваемых в России смартфонах и планшетах, включая устройства Apple и Xiaomi, и производителям запрещено мешать работе и платежам российских приложений.

Для разработчика это значит, что у RuStore работает российский биллинг, регистрация бесплатна, а сам магазин гарантированно есть у пользователя из коробки. По совокупности RuStore сегодня базовый канал для российского Android-продукта, а дополнительным его считать давно неверно.

AppGallery, GetApps, NashStore и прочие. Магазин Huawei (AppGallery) важен для аудитории Huawei и Honor — там нет Google-сервисов, и это отдельная инженерная история (см. раздел про пуши). Galaxy Store у Samsung, GetApps у Xiaomi, NashStore — нишевые каналы, которые добирают аудиторию, но базовую связку обычно образуют RuStore плюс Google Play (для охвата) плюс прямой APK.

Прямой APK — суперсила Android, которую начинают подрезать. В отличие от iOS, Android исторически позволяет раздавать приложение файлом — выложить APK на сайт, и пользователь поставит его сам. Для бизнеса, выбитого из сторов, это спасательный круг. Но именно эту свободу сужает новое требование Google: на сертифицированных устройствах приложения — включая устанавливаемые в обход магазинов — должны быть от верифицированного разработчика.

Внедрение поэтапное: с сентября 2026-го — первые страны (Бразилия, Индонезия, Сингапур, Таиланд), с 2027-го и далее — шире. Для опытных пользователей обещают «продвинутый поток» установки с подтверждением рисков, а разработчикам останется ADB для отладки — но общий вектор понятен: анонимная раздача APK кому угодно постепенно закрывается. Это стоит закладывать в стратегию дистрибуции уже сейчас.

Требование, о котором заказчики узнают по падению установок. Google обязывает ежегодно поднимать целевую версию системы, под которую собрано приложение.

С 31 августа 2026 года новые приложения и любые обновления в Google Play должны собираться под Android 16, существующие — минимум под Android 15. Отсрочку при необходимости запрашивают до 1 ноября 2026 года.

Коварство в механике наказания. Приложение с устаревшей целевой версией не блокируют и не удаляют — его перестают показывать на новых устройствах. Магазин работает, действующие пользователи ничего не замечают, а поток новых установок иссякает. Со стороны это выглядит как «реклама перестала приводить людей».

Отсюда следствие для бюджета: приложение требует обязательного технического обновления минимум раз в год, даже когда новых функций не планировали. Это часть владения продуктом.

Google вводит проверку личности разработчика и прав на имя пакета на уровне самой системы Android. Правило касается приложений из любого источника — не только Google Play, но и других магазинов и установки файлом.

Сроки поэтапные: с 30 сентября 2026 года требование действует в Бразилии, Индонезии, Сингапуре и Таиланде, распространение на остальные регионы планируется в 2027 году.

Что это значит для российского продукта. Даже публикуясь только в RuStore, разработчику предстоит пройти верификацию в консоли Google и зарегистрировать имя пакета; организации понадобится международный идентификатор D-U-N-S. Если приложение уже есть в Google Play, отдельная процедура не нужна — подходит имеющийся ключ подписи.

Процесс публикации в RuStore при этом не меняется, но время на верификацию в план релиза заложить стоит: получение идентификатора для юрлица занимает недели.

Любое Android-приложение перед публикацией подписывается криптографическим ключом — это цифровой паспорт, по которому система понимает, что обновление пришло от того же автора, что и установленная версия. Тема кажется технической, но одна ошибка здесь способна заблокировать развитие продукта навсегда.

Ключ хранится в файле keystore (обычно .jks). Если его потерять или забыть пароль, вы не сможете выпустить обновление к уже установленному у пользователей приложению — система отвергнет сборку с чужой подписью, и единственным выходом останется публиковать продукт заново, потеряв накопленную базу установок и отзывы.

Поэтому keystore — это не «файл в проекте», а ценность уровня доступов к банку: его бэкапят и хранят так, чтобы он пережил увольнение разработчика и смену подрядчика.

В Google Play схему частично подстраховали через Play App Signing: вы загружаете сборку своим upload-ключом, а финальной подписью для пользователей управляет Google, храня основной ключ у себя. Потеряли upload-ключ — его можно перевыпустить через поддержку, и это спасает.

Но в каналах, где такой подстраховки нет (RuStore, прямой APK), вся ответственность за ключ — на вас. Отсюда практическое правило: формат и ключи проговариваются на старте, а keystore передаётся заказчику вместе с исходниками — иначе вы привязаны к подрядчику самим фактом владения ключом.

По форматам: в Google Play публикуют AAB, а вот для RuStore и прямой раздачи нужен обычный APK. Нормальный конвейер сборки умеет выпускать и то, и другое из одного проекта — это вопрос настройки, но проверить его наличие стоит заранее.

Пуш-уведомления на Android традиционно ходят через Firebase Cloud Messaging (FCM) — сервис Google. И тут два слоя проблем, специфичных для России.

Первый: FCM в России работает нестабильно. Сервисы Google периодически недоступны, доставка проседает, и закладывать уведомления только на FCM в 2026 году рискованно. Второй слой — устройства, где сервисов Google нет вовсе, и о них следующая глава.

Это весь парк Huawei и Honor последних лет, где вместо сервисов Google стоят Huawei Mobile Services. На таком телефоне приложение, умеющее только FCM, не получит ни одного уведомления, а заодно может потерять карты и авторизацию через Google.

Рабочее решение — не привязываться к одному провайдеру. У RuStore есть Push SDK и универсальная схема, которая позволяет работать сразу с несколькими источниками — FCM, HMS и собственным пушем RuStore — и автоматически выбирать доступный на конкретном устройстве.

Для российского продукта это сегодня грамотный дефолт: пуши доходят и на «голый» Android, и на Huawei, и на устройства, где Google недоступен. Зависимость от GMS в принципе стоит закладывать в архитектуру как параметр: чем её меньше, тем шире парк устройств, на которых приложение работает полноценно. (На iOS, для сравнения, пуши идут через серверы Apple — APNs; это разобрано в парной статье.)

Ошибки на этой платформе свои, и каждая стоит денег:

• Тест только на одном флагмане. Игнорирование фрагментации — и приложение сыплется на бюджетниках, складных экранах и старых версиях ОС, которых у реальной аудитории большинство.
• Ставка только на Google Play. Логично для 2020 года, разорительно для 2026-го: монетизация для РФ закрыта, а RuStore по закону уже у пользователя. Публикация в один канал = добровольный отказ от денег и охвата.
• Жёсткая привязка к Google-сервисам. Приложение, намертво завязанное на GMS, не живёт на Huawei и спотыкается там, где Google недоступен. Зависимость от GMS — то, что проектируют осознанно.
• Небрежное отношение к keystore. Потерянный ключ — это невозможность обновить приложение и потеря базы. Бэкап и передача ключа заказчику — обязательны.
• Игнор фоновых ограничений и экономии батареи. Doze и агрессивные «оптимизаторы» оболочек (особенно у Xiaomi) тихо убивают фоновую синхронизацию и пуши, если их не учитывать. «У меня всё работает» на одном телефоне ничего не доказывает.

Как Android-проект встраивается в общий маршрут разработки, показано в гайде по созданию мобильного приложения.

Маршрут Android-проекта складывается из понятных шагов — мы проходим его как разработку приложения под ключ:

• Определить, хватит ли Flutter или нужна нативка на Kotlin
• Заложить поддержку реального парка устройств и версий ОС (матрица тестирования, разумные minSdk/targetSdk)
• Выбрать стек интерфейса (Compose для нового проекта)
• С самого начала спроектировать дистрибуцию под российские реалии — RuStore как база, Google Play для охвата, прямой APK и, при необходимости, AppGallery
• Не привязываться жёстко к Google-сервисам в пушах и картах
• Настроить чистую сборку с AAB и APK и безопасно хранить keystore
• Заранее решить, как принимать деньги, раз Google Play для этого больше не годится

Самое дорогое в Android-проекте — не код, а ошибки на стыках: протестировали на одном телефоне и поймали баги в отзывах; выложились только в Google Play и остались без монетизации; завязались на GMS и потеряли аудиторию Huawei; потеряли ключ и не смогли обновиться.

Code Pilots проводит проект через все эти рубежи целиком — расскажите о задаче, подскажем, где хватит Flutter, а где нужна нативка, и доведём приложение до публикации во всех каналах, которые в России реально работают.

Ориентир по деньгам: Android-приложение мы делаем от 1,8 млн ₽ — на Flutter, с публикацией в Google Play и RuStore, урезанная первая версия — от 1 млн ₽. Смету двигают фрагментация устройств, интеграции и требования к офлайну — опишите задачу, оценим бесплатно.

Прикинуть вилку по своему набору экранов можно в бесплатном калькуляторе оценки.

Мы делаем мобильные продукты для российского рынка, где Android — платформа большинства, а правила дистрибуции меняются каждый год. Знаем, чем оборачивается устаревшая целевая версия, как собрать пуши на парк без сервисов Google и почему ключ подписи хранят отдельно от подрядчика.

По умолчанию работаем на общей кодовой базе под обе платформы, нативную разработку берём там, где она действительно нужна. Команда собрана внутри, цену и срок фиксируем до старта.

Обсудить проект →