Как работать с тестовыми и примерными пакетами в Android

Тестовые и примерные пакеты (com.android.test, com.example.android, com.android.start) — это шаблонные имена, которые используют для примеров, тестов и демо‑проектов; их не стоит оставлять в релизных приложениях. В первом абзаце — короткий ответ: используйте уникальный обратный домен как package/applicationId для реального релиза; com.example.* и com.android.* подходят только для локальных примеров, тестов и шаблонов.

Что означают com.android.test, com.example.android, com.android.start

com.example.android — стандартный примерный пакет, который IDE и туториалы подставляют для демонстрации.
com.android.test — часто используется для тестовых модулей / instrumentation tests (например, тестовый package для androidTest).
com.android.start — пример начального шаблона проекта.

Эти имена:

  • не гарантируют уникальность (Play Store отклонит конфликтующие applicationId);
  • удобны для примеров и CI, но не для выпуска;
  • иногда автоматически добавляются в generated files (шаблоны, sample apps).

Не публикуйте приложение с package name com.example.* или с com.android.* — это частая причина конфликтов и отказа в публикации.

Когда их используют и как заменить правильно

Где встречаются:

  • шаблоны Android Studio (New Project),
  • примерные репозитории / демонстрации,
  • модульные/инструментальные тесты (androidTest часто использует com.example.test),
  • временные прототипы.

Как безопасно заменить перед релизом:

  1. Решите окончательный package name по принципу обратного доменного имени: например, ru.example.appname.
  2. В Android Studio: Refactor → Rename для пакетов в дереве java/kotlin (переименуйте папки и package declarations).
  3. Обновите applicationId в module-level build.gradle (или namespace в плагине Gradle 7+). applicationId — это идентификатор в Play Store, он может отличаться от package в коде, но должен быть уникальным.
  4. Исправьте манифесты (android:authorities, provider, intent‑filters) и внешние ссылки, если они содержат старый пакет.
  5. Проверьте тесты: тестовые пакеты и instrumentationRunner обычно должны ссылаться на правильный applicationId.
  6. Выполните clean/rebuild и запустите тесты, чтобы найти оставшиеся импорты R из старого пакета.

Если используете модульные проекты, держите applicationId независимым от исходного кода: это позволяет использовать один код с разными идентификаторами для staging/prod.

Практические риски и лучшие практики

  • Уникальность: всегда используйте юридически контролируемый домен (вашей компании/проекта).
  • Безопасность: некоторые компоненты (ContentProvider, permissions) зависят от package — изменение влияет на доступ.
  • CI и подпись: настройте signingConfig и ключи для final build; тестовые пакеты могут мешать автоматизированным публикациям.
  • Документация/интеграции: сторонние сервисы часто привязываются к applicationId — обновляйте конфигурации одновременно.

Рекомендации:

  • До релиза выполните поиск по проекту на com.example, com.android: замените все вхождения.
  • Используйте applicationIdSuffix в debug сборках для одновременного тестирования разных версий.
  • Автоматизируйте проверку уникальности с помощью линтера/CI.

Частые ошибки

  • Публикация с com.example.* — конфликт на Play Store.
  • Переименование только папок без изменения package declarations — приведёт к ошибкам компиляции.
  • Забытые зависимости, где старый пакет указан в манифесте, провайдерах или intent-filter.
  • Несоответствие applicationId и подписи: нельзя установить релизный apk, подписанный другим ключом.

FAQ

  • Нужно ли менять package в тестовом модуле?
    Да, если тесты взаимодействуют с релизным приложением или используются в CI, привяжите их к реальному applicationId или настройте testOnly applicationId.

  • Что важнее — namespace или applicationId?
    namespace (Gradle Plugin 7+) определяет пространство имён исходников; applicationId — идентификатор выпуска. Для публикации критичен applicationId.

  • Можно ли оставить старый пакет в коде, но поменять applicationId?
    Да, это допустимо: package declarations в коде могут остаться, но applicationId определяет идентификатор приложения в магазине.

Резюме: шаблонные пакеты удобны для разработки и примеров, но требуют тщательной замены и проверки перед релизом. Следуйте правилам обратного домена, обновляйте applicationId/namespace и проверяйте манифест и тесты — тогда проблем при публикации и интеграции не будет.