Как создать приложение для Android: гайд по разработке
Android в России — это платформа большинства: на нём работает почти четыре смартфона из пяти (около 78%). Логично ждать, что и делать под него проще, чем под iPhone, — и в части кода это правда. А вот вокруг кода в 2026 году выросла своя засада, о которой гайды для новичков обычно молчат: монетизация через Google Play для российских разработчиков фактически закрыта, обязательным по закону стал RuStore, а привычная для Android «свобода поставить APK откуда угодно» постепенно сужается под новые требования Google к верификации. Получается парадокс — платформа массовая, а зарабатывать на ней надо иначе, чем написано в большинстве инструкций.
Code Pilots делает мобильные приложения с 2014 года — среди проектов VK Fest, приложения для музея Эрарта, платформа GigAnt, PetShop с рейтингом 4.8★. Работаем и с нативной разработкой на Kotlin, и с Flutter, поэтому про выбор технологии говорим без религиозных войн. Этот материал — про специфику именно Android: где прячется главная боль платформы, какой стек брать в 2026-м, куда публиковать в российских реалиях и как принимать деньги, когда Google Play на это больше не годится. Общие вещи — нужно ли вашему бизнесу приложение, как устроены этапы, сколько это стоит — вынесены в зонтичный гайд «Как создать мобильное приложение» и в статью о стоимости.
Почему в России Android — основная платформа, а не «вторая»
Если в мире Android и iOS делят рынок неравномерно, но соизмеримо, то в России перекос сильный и в пользу Android. На начало 2025 года расклад по операционным системам — около 78% Android против примерно 21% iOS, и доля iOS за три года просела (в 2022-м было под 28%) из-за серого импорта и дорогой техники. Дешёвые и средние аппараты Xiaomi, Samsung, Realme, Tecno и десятков других вендоров — это и есть массовый российский смартфон.
| Метрика | Доля Android в РФ (2025–2026) | Что это значит |
|---|---|---|
| Активные устройства в сети | ~76% | Три смартфона из четырёх в реальном использовании — на Android |
| Доля в новых продажах (штуки) | ~92–96% | Подавляющее большинство новых продаваемых аппаратов — Android |
| Доля рынка по выручке | ~72–75% | Даже по деньгам Android впереди, хотя средний чек у iPhone выше |
Вывод для бизнеса прямой: если продукт массовый и про охват — Android это не «ещё одна платформа», а основная. (iOS-аудитория меньше, но платёжеспособнее и сосредоточена в миллионниках — это разобрано в парной статье про iOS; сам выбор платформы — в зонтичном гайде.)
И ровно здесь поджидает главный подвох российского Android. Платформа массовая, аудитория огромная — а самый привычный способ зарабатывать на ней, через платные приложения и встроенные покупки в Google Play, для разработчика из России больше не работает. К тому, почему так вышло и что с этим делать, мы вернёмся в разделе про публикацию; пока достаточно держать в голове, что «много пользователей» и «легко монетизировать» на российском Android — это сегодня не одно и то же.
Чем разработка под Android отличается: фрагментация — это не «зелёный робот», а главная статья расходов на тесты
Разницу между 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 нельзя «протестировать на своём флагмане и выложить». Нужна матрица из реальных и эмулируемых устройств разных поколений и оболочек — и закладывать это в план тестирования с самого начала. Команда, которая проверяет только на одном дорогом телефоне, гарантированно ловит баги уже в отзывах.
Стек Android-разработки в 2026
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), сборка и зависимости — это та инфраструктура, которую подрядчик обязан настроить чисто, потому что от неё зависит, сможет ли другая команда подхватить проект. Грязная сборка и спутанные зависимости — частая причина того, что приложение невозможно передать и развивать. Прозрачность здесь проверяется на старте, а не когда уже поздно.
Нативка на Kotlin или Flutter под Android — честно, глазами Flutter-first студии
Мы по умолчанию предлагаем Flutter — и сразу объясним, где это правильно, а где честнее взять нативку. Подавать кроссплатформу как «всегда лучше» было бы тем самым снобизмом наоборот, которого мы избегаем.
| Что у вас за продукт | Что брать | Почему |
|---|---|---|
| Каталог, сервис, маркетплейс, ЛК, доставка, B2B | Flutter | Одна кодовая база под Android и iOS — одна команда вместо двух, быстрее и дешевле; разницы пользователь не видит |
| Тяжёлая графика, AR, компьютерное зрение, низколатентный звук | Нативка (Kotlin) | Нужен прямой доступ к железу и системным API на максимуме производительности |
| Глубокая работа с системой Android, виджеты, специфичные API в день выхода | Нативка или гибрид | Системные возможности проще и быстрее закрывать нативно |
| Уже есть большой Android-продукт на Kotlin | Нативка | Переписывать работающее ради кроссплатформы — деньги на ветер |
Где выигрывает Flutter. Для абсолютного большинства бизнес-приложений одна кодовая база на обе платформы — это меньше бюджета и быстрее выход сразу на Android и iOS. Собственный движок рендеринга даёт картинку и отзывчивость, неотличимые от нативных; высокие нагрузки на старте кроссплатформа держит — это видно по нашим же кейсам.
Где честно нужна нативка. Тяжёлый AR и компьютерное зрение, низколатентный звук, выжимание максимума из конкретного железа, экзотические системные API сразу после анонса — здесь нативный Kotlin оправдан, и мы скажем об этом прямо.
Гибрид. Нередко оптимум посередине: ядро на Flutter, а отдельные тяжёлые или системные части — нативными модулями. Это инженерное решение под продукт, а не компромисс от бедности. Развилку видно ещё на аналитике: если в требованиях нет тяжёлого AR, специфичного железа и экзотики — Flutter почти наверняка выгоднее, и переписывать потом не придётся.
Куда публиковать Android-приложение в России в 2026
Вот здесь Android расходится с iOS сильнее всего. На iPhone канал по сути один — App Store. На Android каналов несколько, и в российских реалиях 2026 года выбор между ними — не про удобство, а про то, сможете ли вы вообще принимать деньги.
| Канал | Охват | Монетизация для разработчика из РФ | Нюанс 2026 |
|---|---|---|---|
| Google Play | Максимальный охват аудитории | Закрыта — платные приложения, встроенные покупки и подписки на российский аккаунт не проходят | Бесплатные приложения публиковать и обновлять можно; обязателен формат AAB и свежий target API |
| RuStore | Быстро растёт, предустановлен по закону | Работает — есть российский биллинг | Регистрация бесплатна; де-факто базовый канал для РФ |
| AppGallery (Huawei) | Аудитория Huawei/Honor без Google-сервисов | Работает | Нет GMS — нужен запасной механизм пушей и карт (HMS) |
| Прямой APK с сайта | Кто угодно по ссылке | Любая, через ваш платёжный контур | Свобода сужается верификацией разработчиков Google (см. ниже) |
Google Play: качать можно, зарабатывать — нет. Это ключевой и самый замалчиваемый факт. После марта 2022 года пользователи в России не могут оплачивать покупки через биллинг Google Play, а с 26 декабря 2024-го отключена и монетизация для самих разработчиков с российским расчётным счётом: платные установки, встроенные покупки и подписки через Google Play попросту не проходят. При этом бесплатные приложения публиковать и обновлять по-прежнему можно, и пользователи их скачивают. Вывод: Google Play в России остаётся каналом дистрибуции и охвата, но не каналом заработка — деньги придётся принимать иначе.
Технические требования Google Play тоже стоит знать заранее. Публикуют не голый APK, а Android App Bundle (AAB) — Google сам собирает из него оптимизированные сборки под конкретные устройства. Приложение обязано быть на свежем уровне API: с 31 августа 2025-го новые приложения и обновления должны быть нацелены на Android 15 (API 35), а существующие — не ниже Android 14 (API 34). Аккаунт разработчика — 25 $ единоразово (это разовый сбор Google, в отличие от ежегодных 99 $ у Apple), но с обязательной верификацией личности и без российской карты это отдельный квест; для новых личных аккаунтов добавилось требование прогнать приложение через закрытое тестирование с группой тестировщиков, прежде чем выпускать в продакшен.
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 кому угодно постепенно закрывается. Это стоит закладывать в стратегию дистрибуции уже сейчас.
Подпись приложения и формат сборки: keystore, AAB и почему потеря ключа = катастрофа
Любое Android-приложение перед публикацией подписывается криптографическим ключом — это цифровой паспорт, по которому система понимает, что обновление пришло от того же автора, что и установленная версия. Тема кажется технической, но одна ошибка здесь способна заблокировать развитие продукта навсегда.
Ключ хранится в файле keystore (обычно .jks). Если его потерять или забыть пароль, вы не сможете выпустить обновление к уже установленному у пользователей приложению — система отвергнет сборку с чужой подписью, и единственным выходом останется публиковать продукт заново, потеряв накопленную базу установок и отзывы. Поэтому keystore — это не «файл в проекте», а ценность уровня доступов к банку: его бэкапят и хранят так, чтобы он пережил увольнение разработчика и смену подрядчика.
В Google Play схему частично подстраховали через Play App Signing: вы загружаете сборку своим upload-ключом, а финальной подписью для пользователей управляет Google, храня основной ключ у себя. Потеряли upload-ключ — его можно перевыпустить через поддержку, и это спасает. Но в каналах, где такой подстраховки нет (RuStore, прямой APK), вся ответственность за ключ — на вас. Отсюда практическое правило: формат и ключи проговариваются на старте, а keystore передаётся заказчику вместе с исходниками — иначе вы привязаны к подрядчику самим фактом владения ключом.
По форматам: в Google Play публикуют AAB, а вот для RuStore и прямой раздачи нужен обычный APK. Нормальный конвейер сборки умеет выпускать и то, и другое из одного проекта — это вопрос настройки, но проверить его наличие стоит заранее.
Пуши, Google-сервисы и устройства без GMS
Пуш-уведомления на Android традиционно ходят через Firebase Cloud Messaging (FCM) — сервис Google. И тут два слоя проблем, специфичных для России.
Первый: FCM в России работает нестабильно. Сервисы Google периодически недоступны без VPN, доставка может проседать, и закладывать пуши только на FCM в 2026-м рискованно. Второй, более фундаментальный: есть устройства вообще без Google-сервисов (GMS). Это весь парк Huawei и Honor последних лет, где вместо GMS стоят Huawei Mobile Services (HMS). На таком аппарате приложение, которое умеет только FCM, не получит ни одного пуша, а заодно может потерять карты, авторизацию через Google и другие завязанные на GMS функции.
Рабочее решение — не привязываться к одному провайдеру. У RuStore есть Push SDK и универсальная схема, которая позволяет работать сразу с несколькими источниками — FCM, HMS и собственным пушем RuStore — и автоматически выбирать доступный на конкретном устройстве. Для российского продукта это сегодня грамотный дефолт: пуши доходят и на «голый» Android, и на Huawei, и на устройства, где Google недоступен. Зависимость от GMS в принципе стоит закладывать в архитектуру как параметр: чем её меньше, тем шире парк устройств, на которых приложение работает полноценно. (На iOS, для сравнения, пуши идут через серверы Apple — APNs; это разобрано в парной статье.)
Частые ошибки при разработке под Android
Ошибки на этой платформе свои, и каждая стоит денег:
- Тест только на одном флагмане. Игнорирование фрагментации — и приложение сыплется на бюджетниках, складных экранах и старых версиях ОС, которых у реальной аудитории большинство.
- Ставка только на Google Play. Логично для 2020 года, разорительно для 2026-го: монетизация для РФ закрыта, а RuStore по закону уже у пользователя. Публикация в один канал = добровольный отказ от денег и охвата.
- Жёсткая привязка к Google-сервисам. Приложение, намертво завязанное на GMS, не живёт на Huawei и спотыкается там, где Google недоступен. Зависимость от GMS — то, что проектируют осознанно.
- Небрежное отношение к keystore. Потерянный ключ — это невозможность обновить приложение и потеря базы. Бэкап и передача ключа заказчику — обязательны.
- Игнор фоновых ограничений и экономии батареи. Doze и агрессивные «оптимизаторы» оболочек (особенно у Xiaomi) тихо убивают фоновую синхронизацию и пуши, если их не учитывать. «У меня всё работает» на одном телефоне ничего не доказывает.
С чего начать
Маршрут 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, а где нужна нативка, и доведём приложение до публикации во всех каналах, которые в России реально работают.
Частые вопросы (FAQ)
Для большинства бизнес-приложений (каталоги, сервисы, маркетплейсы, личные кабинеты, доставка) выгоднее Flutter: одна кодовая база сразу под Android и iOS, одна команда, быстрее и дешевле. Нативный Kotlin честно нужен там, где важны тяжёлая графика, AR, низколатентный звук, выжимание максимума из железа или глубокая работа с системой. Нередко оптимум — гибрид: ядро на Flutter, тяжёлые части нативными модулями.
Только в Google Play — плохая идея для России. Пользователи РФ не могут оплачивать покупки через Google Play с 2022 года, а с конца 2024-го отключена и монетизация для разработчиков с российским счётом — заработать через Google Play не получится. RuStore при этом обязателен к предустановке по закону, у него работает российский биллинг, и он уже есть у пользователя из коробки. Поэтому базовая связка — RuStore плюс Google Play для охвата, часто плюс прямой APK.
Привычный FCM работает только там, где доступны Google-сервисы (GMS), а в России он ещё и нестабилен, и полностью отсутствует на устройствах Huawei и Honor (там HMS). Чтобы пуши доходили на весь парк, используют мультипровайдерную схему — например, Push SDK RuStore, который умеет работать одновременно с FCM, HMS и собственным пушем и выбирает доступный на конкретном аппарате.
В Google Play приложение публикуют в формате Android App Bundle (AAB) — из него Google собирает оптимизированные сборки под устройства; для RuStore и прямой раздачи нужен обычный APK. Keystore — это ключ цифровой подписи: потеряете его — не сможете выпустить обновление к уже установленному приложению и потеряете базу. Поэтому ключ бэкапят, безопасно хранят и передают заказчику вместе с исходниками.
Свобода сужается, но не исчезает. Google вводит требование, по которому на сертифицированных устройствах приложения — включая устанавливаемые в обход магазинов — должны быть от верифицированного разработчика; внедрение стартует с сентября 2026-го в нескольких странах и расширяется с 2027-го. Для опытных пользователей обещают «продвинутый поток» установки с подтверждением рисков, а для разработки останется ADB. Раздавать APK можно будет и дальше, но анонимно и без верификации — уже нет, и это стоит учитывать в стратегии дистрибуции.
