Как создать приложение на Android с помощью ИИ: от экранов до тестовой сборки
Создать приложение на Android с помощью ИИ можно без попытки сгенерировать весь продукт одним запросом. ИИ помогает спроектировать экраны, написать код, объяснить ошибку Gradle и подготовить тесты. Но проект все равно собирается обычными инструментами Android, а результат проверяется на эмуляторе или устройстве.
В этом гайде сделаем небольшое приложение списка дел: пользователь добавляет задачу, отмечает выполненной и видит данные после перезапуска. Цель - получить тестовую сборку, а не сразу публиковаться в Google Play.
Опишите минимальный сценарий
До Android Studio запишите поведение:
1. Пользователь видит список задач.
2. Нажимает кнопку добавления.
3. Вводит короткий текст.
4. Сохраняет задачу.
5. Отмечает ее выполненной.
6. После перезапуска список остается.
Ограничьте первую версию. Без аккаунта, синхронизации, уведомлений и совместного доступа. Каждая из этих функций добавляет разрешения, сервер или фоновую работу.
Определите состояния экрана: пустой список, список с задачами, форма с ошибкой пустого текста и ошибка сохранения. ИИ часто рисует только идеальный путь, если не попросить о других состояниях.
Установите Android Studio
Android Studio - официальная среда разработки Android. Скачайте ее с сайта Android Developers и пройдите Setup Wizard. Он устанавливает Android SDK и компоненты для эмулятора.
Создайте новый проект из минимального шаблона с Jetpack Compose. Выберите понятное имя пакета и минимальную версию Android в соответствии с вашей аудиторией, а не случайно из старого видео.
После создания не меняйте код сразу. Дождитесь первой синхронизации Gradle и запустите шаблон на эмуляторе. Эта исходная проверка показывает, что SDK, JDK и виртуальное устройство работают до участия ИИ.
Если шаблон не собирается, сохраните точную ошибку. Не просите ИИ обновить все версии одновременно: сначала сверяйте совместимость по официальной документации проекта.
Подключите ИИ к проекту
Gemini в Android Studio встроен в среду и может работать с контекстом проекта. В Agent Mode он способен предложить план и изменения в нескольких файлах, которые пользователь затем принимает или отклоняет.
Перед передачей контекста прочитайте настройки приватности и правила вашей организации. Не включайте в запрос реальные ключи, пользовательские данные и закрытый код, если это не разрешено.
Начните с анализа:
Изучи новый проект, ничего не меняй. Объясни, где находится главный Compose-экран, как устроена тема и какой командой собирается debug-версия. Назови файлы-основания.
Сверьте ответ со структурой проекта. Затем сделайте исходный коммит Git.
Спроектируйте данные
Для задачи достаточно модели:
data class Task( val id: String, val title: String, val completed: Boolean )
Но список должен пережить перезапуск. Для совсем учебного прототипа можно выбрать простое локальное хранилище. Для структурированных данных Android обычно использует Room, но добавление библиотеки требует настройки и миграций.
Попросите ИИ сначала сравнить два варианта для текущего объема, не писать код. Выберите один и зафиксируйте границу: данные только локальные, один пользователь, синхронизации нет.
Отдельно определите источник истины для состояния интерфейса. Compose должен получать список из одного слоя данных, а не хранить разные копии в нескольких компонентах.
Соберите первый вертикальный срез
Не создавайте сразу архитектуру всех будущих экранов. Первый срез должен пройти от интерфейса до хранения:
Реализуй минимальный вертикальный срез списка задач.
Сначала предложи план и файлы, затем остановись.
Требования:
- главный экран показывает сохраненные задачи;
- кнопка открывает ввод текста;
- пустой текст не сохраняется и показывает ошибку;
- задача сохраняется локально;
- нажатие на checkbox меняет completed;
- после перезапуска данные остаются.
Не добавляй аккаунты, сеть, уведомления и навигационную библиотеку.
После подтверждения вноси изменения маленькими шагами и собирай проект после каждого логического шага.
Прочитайте план. Для небольшого приложения десятки абстракций могут усложнить проверку. Но и вся логика в одном composable затруднит тестирование. Попросите объяснить каждую границу через текущую задачу.
Проверяйте изменения по частям
После каждого шага смотрите diff. Обратите внимание на build.gradle и каталог версий: ИИ может обновить зависимости, которые не относятся к задаче.
Порядок удобно держать таким:
1. Модель данных и хранилище.
2. Чтение списка.
3. Добавление задачи.
4. Изменение статуса.
5. Ошибки и пустое состояние.
6. Тесты.
Собирайте проект после каждого этапа. Если ошибка появилась после добавления хранения, не продолжайте рисовать интерфейс, пока не восстановили сборку.
Не принимайте объяснение «это предупреждение можно игнорировать» без проверки. Разделите предупреждения и ошибки и сверяйте быстро меняющиеся API с Android Developers.
Запустите на эмуляторе
Создайте Android Virtual Device в Device Manager для поддерживаемой версии Android. Запустите приложение и пройдите сценарий руками.
Проверьте:
• пустое состояние;
• добавление нормальной задачи;
• запрет пустого текста;
• длинный текст;
• несколько быстрых нажатий;
• отметку выполненной;
• поворот экрана;
• перезапуск приложения;
• темную тему;
• маленький и большой экран.
Эмулятор удобен для повторяемости, но перед передачей сборки проверьте хотя бы одно реальное устройство. Там проявляются клавиатура, системные отступы, производительность и поведение разных производителей.
Добавьте тесты
Логику хранения и изменения статуса можно проверить локальными unit-тестами. Пользовательский маршрут Compose проверяется инструментальными UI-тестами.
Попросите ИИ сначала перечислить сценарии и ожидаемый результат, а затем написать тесты. Тест, который просто подтверждает текущее неверное поведение, не приносит пользы.
Минимальный набор:
• пустой заголовок отклоняется;
• новая задача появляется в списке;
• completed меняется и сохраняется;
• сохраненные данные загружаются после нового запуска слоя;
• экран показывает пустое состояние;
• нажатие добавления вызывает нужное действие.
Запускайте тесты независимо и читайте фактический вывод Gradle.
Разрешения и секреты
Нашему локальному списку задач не нужны разрешения камеры, контактов и геолокации. Если ИИ добавил их в manifest, спросите зачем и удалите необоснованные.
Для будущего сетевого приложения ключ закрытого API нельзя вшивать в APK. Мобильную сборку можно разобрать. Секреты должны оставаться на вашем сервере, а приложение обращается к нему с пользовательской авторизацией.
Проверяйте зависимости: кто их поддерживает, зачем они нужны и какие разрешения используют. Не добавляйте большую библиотеку ради одной простой функции без сравнения с платформенным API.
Получите тестовую сборку
Для передачи тестировщику нужна debug APK или другой подходящий тестовый артефакт. Android Studio умеет собрать APK через меню Build, а Gradle - через задачу проекта. Точное имя и путь смотрите в текущем проекте и официальной документации.
Перед сборкой:
• очистите тестовые секреты;
• увеличьте версию осознанно, если сборка не первая;
• выполните тесты;
• соберите проект с чистого состояния;
• установите APK на устройство;
• повторите главный сценарий.
Debug-сборка не предназначена для публикации в магазин. Для release нужны подпись, безопасное хранение ключа, правила версии и отдельная проверка.
Проверьте жизненный цикл Android
Экран может пересоздаваться при повороте, смене темы или нехватке памяти. Данные интерфейса и сохраненные пользовательские записи имеют разный срок жизни. Не держите важную задачу только в памяти composable.
Проверьте переход приложения в фон и возврат. Если пользователь открыл форму и свернул приложение, не должен появляться дубликат или исчезать сохраненная запись. Для процесса, который может быть убит системой, определите, какие данные восстанавливаются.
ИИ может предложить глобальный объект как быстрый способ «сохранить» состояние. Такой вариант часто ломается после перезапуска процесса. Попросите объяснить, где живут данные и что произойдет после полного закрытия приложения.
Доступность и ввод
Кнопки и интерактивные элементы должны иметь понятные семантические описания. Проверьте приложение с увеличенным шрифтом и экранным диктором. Цвет не должен быть единственным способом показать выполненную задачу или ошибку.
Учитывайте программную клавиатуру: она не должна перекрывать поле и кнопку сохранения. Длинный текст должен переноситься, а фокус - перемещаться предсказуемо.
Попросите ИИ предложить accessibility-проверки, но выполните их на устройстве. Автоматический тест не показывает весь опыт пользователя.
Подготовьте передачу тестировщику
Вместе с APK передайте номер версии, дату, поддерживаемую версию Android и короткий сценарий проверки. Укажите известные ограничения: данные локальные, синхронизации нет, тестовый список можно удалить очисткой данных приложения.
Соберите обратную связь по наблюдаемому результату: шаги, ожидаемое и фактическое поведение, модель устройства и версия Android. Скриншот полезен, но без последовательности действий ошибка может не воспроизводиться.
Для каждой найденной ошибки сначала добавьте тест или точный сценарий, затем дайте ИИ ограниченную задачу. Не просите «проверить все приложение» после одного дефекта.
Перед release
Release-сборка подписывается отдельным ключом. Потеря ключа и неправильное управление им затрудняют обновления, поэтому храните его вне репозитория и делайте защищенную резервную копию по правилам команды.
Проверьте release-вариант отдельно: оптимизация и конфигурация могут отличаться от debug. Удалите тестовые адреса, убедитесь, что logging не раскрывает данные, и проверьте сетевые политики.
Публикация в магазине добавляет описание, изображения, политику данных и требования Google Play. Сверяйте их перед релизом: они меняются быстрее, чем базовый код приложения.
Перед каждой новой тестовой сборкой сохраняйте чистый коммит и номер версии. Если тестировщик сообщает проблему, вы должны точно восстановить тот же код и конфигурацию. Файл с названием app-final-new.apk без версии и коммита не дает воспроизводимой точки.
Храните тестовые артефакты ограниченный срок и удаляйте устаревшие сборки осознанно.
Что ИИ не делает за вас
ИИ ускоряет написание кода и диагностику, но не знает продуктовый приоритет, не гарантирует совместимость библиотек и не проверяет реальное устройство сам по себе. Он может предложить устаревший API или слишком сложную архитектуру.
Вы остаетесь владельцем решений: минимальная версия Android, данные, разрешения, зависимости, подпись и критерии готовности.
Если вы хотите пройти путь от интерфейса до backend, базы и публикации, на курсе «Вайбкодинг на максималках» разбирается полный цикл разработки с ИИ, включая Git, API, Docker и безопасность.
Первая Android-версия готова, когда сценарий работает на эмуляторе и устройстве, данные сохраняются, тесты проходят, diff понятен, а APK устанавливается с нуля. После этого добавляйте следующую функцию отдельным вертикальным срезом, а не превращайте прототип в большой проект одним промптом.