Советы начинающему Android-разработчику

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

1. Первое приложение делайте маленьким

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

2. Сначала напишите паспорт приложения

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

3. Package ID выбирайте как постоянное имя

Package ID нельзя безболезненно переименовать после первой публикации: другое значение будет другим приложением. Используйте домен, которым действительно управляете, и не оставляйте com.example.

4. Не ставьте зависимости «на будущее»

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

5. Один шаг — один видимый результат

Сначала добейтесь запуска пустого приложения, затем одного экрана, затем одного полного пользовательского сценария. После каждого шага запускайте ближайший тест. Так источник ошибки остаётся понятным.

6. Проверяйте плохие условия

Happy path недостаточен. Проверяйте отказ в permission, отсутствие сети, пустой ответ, медленную загрузку, Back, background/resume, поворот экрана и process recreation. Пользователь встретит эти условия раньше, чем кажется.

7. Эмулятор полезен, но не заменяет всё

AVD удобен для повторяемых тестов разных экранов и версий Android. Физический телефон нужен для поведения камеры, уведомлений, энергосбережения, реальной производительности и обязательной проверки устройства в некоторых аккаунтах Play Console.

8. Ключ подписи резервируйте сразу

Upload key храните вне проекта минимум в двух защищённых местах. Не отправляйте keystore и пароль в Git, чат, почту или облачный лог. До первого релиза проверьте, что backup действительно можно восстановить.

9. Локальный AAB — ещё не финальная сборка

Google Play преобразует AAB в набор APK и подписывает доставляемое приложение. Поэтому после локальных тестов нужен Play-delivered build из internal или closed track и повторный smoke-test.

10. Анкеты заполняйте из фактов, а не по образцу

Data Safety, возрастная аудитория, реклама, app access и privacy policy должны соответствовать текущему коду и SDK. Чужой ответ «No data collected» нельзя копировать: даже сторонняя аналитика или реклама может изменить правильный ответ.

11. Не отправляйте один и тот же дефект повторно

Если review отклонил приложение, сначала прочитайте точную причину, исправьте код, карточку или декларацию во всех каналах, затем повторите проверки. Серия неизменённых повторных отправок не устраняет нарушение и повышает риск санкций.

12. Ведите журнал релиза

Для каждой версии сохраняйте:

• versionCode и versionName;
• SHA-256 проверенного AAB;
• команды и сценарии, которые прошли;
• изменения permissions, SDK и данных;
• тексты release notes;
• кто и когда подтвердил ручные анкеты;
• известные ограничения и способ отката.

Так следующий релиз становится повторением понятного процесса, а не новым экспериментом.

Мой рекомендуемый порядок для первого проекта

1. Бесплатное приложение без рекламы, login и лишних permissions.
2. Один основной сценарий и работающий offline/error state.
3. Native Compose starter для нового Android-first продукта или Capacitor для уже готовой автономной PWA.
4. Автоматический verify плюс ручной AVD smoke.
5. Internal track, затем применимый closed testing gate.
6. Первый production rollout на выбранные страны с включённым Managed publishing и наблюдением за Android vitals.

Следующий шаг: выбрать стек.