Android - тестирование по сравнению с производственной версией

Ответ 1

Лично я использую это, чтобы определить, находится ли я в режиме отладки:

final PackageInfo pinfo = getPackageInfo(ctx);
final boolean debugMode = (pinfo.applicationInfo.flags & ApplicationInfo.FLAG_DEBUGGABLE) != 0;

Этот код основан на атрибуте debuggable тега Application android-manifest.xml:

• Если этот атрибут явно установлен на true debugMode, будет установлен true.

• Но если он явно установлен в false или не присутствует в xml (неявные значения), debugMode будет установлен в false.

Таким образом, вы не можете запускать оба приложения на одном устройстве одновременно с тем, что двум APK необходимо установить два разных имени пакета, которые будут установлены одновременно. Таким образом, вам нужно построить два проекта eclipse, каждый из которых имеет свое собственное имя пакета (например, com.example.myapp.debug и com.example.myapp) и почему бы не использовать общую библиотеку lib (com.example.myapp.common), которая содержала бы почти весь ваш код:

• com.example.myapp.debug имеет флаг debuggable, установленный в true

• и com.example.myapp имеет флаг debuggable, установленный на false

Ответ 2

Насколько я вижу, вам действительно нужно создавать различные приложения из вашего базового кода. Один из способов сделать это, как я сделал это, - использовать Ant script, который копирует весь источник проекта в другой каталог, скажем, "тестирование", и при этом заменяет (например, используя фильтрацию копирования) определенные значения из файлов XML, например, из AndroidManifest.xml. Одной из первых вещей, которые нужно заменить, является пакет приложений, который должен быть уникальным для каждого приложения. Классы Java, такие как Activities, все еще могут находиться в исходных пакетах, их имена в AndroidManifest.xml просто должны быть абсолютными. Как только источник был скопирован и отфильтрован, вы можете использовать задачу Ant antcall из основного файла build.xml для создания настроенного приложения. Поэтому в конце вы можете сказать, например: "ant -Denv = test build", и у вас есть APK, который можно установить рядом с вашей производственной версией.

Другая альтернатива - использовать Maven, чтобы плагины Android поддерживали наложение проектов. И, конечно, вы можете использовать библиотечные проекты, см. Android - несколько пользовательских версий одного и того же приложения.

Ответ 3

Я думаю, что самое простое решение - использовать для этого какой-то инструмент управления исходным кодом. Есть так много веских причин использовать контроль источника, что я считаю, что большинство разработчиков уже используют его.

Сумма решения:

• Имейте 2 репозитория (или ветки), один для разработки и один для производства.
• Выберите другое название пакета для приложений для разработки и разработки.
• Используйте абсолютный путь для действий, а не относительный в файле манифеста.
• Решите конфликт только в первый раз, когда вы переносите изменения из разработки в производственную среду.

Описание решения.

Я лично работаю с GIT, я считаю, что этот подход будет работать с другими инструментами SCM, но я не тестировал его.

• У меня есть 2 репозитория, один для разработки и один для производства (вы можете получить тот же эффект, используя производственную ветвь, но я предпочел разные репозитории, так как я никогда не знаю, когда у меня появятся другие разработчики, я не хочу дать кому-либо (включая меня) возможность совершить ошибку с кодом, не имея резервной копии для него.

• Все, что вам нужно сделать, это установить другое имя пакета в файле манифеста в каждом репозитории, например:

• Имя пакета разработки - dev.com.foo.appName

• Имя пакета производственного манифеста - com.foo.appName

• Для каждого вида деятельности необходимо использовать абсолютный путь, а не относительный подход. Поскольку нет реального варианта, что вы измените имя своего пакета, и если вы это сделаете, все изменения внесены в файл манифеста, я не думаю, что с этим подходом есть почти какие-то недостатки.

• Затем каждый раз, когда вы переносите свои изменения из репозитория разработчика на производственный, должен быть "конфликт" на этих строках в файлах манифеста, но на самом деле конфликт будет только в первый раз вы вытаскиваете код, после чего инструменты слияния знают, какую строку вы предпочитаете в производственном репозитории.

ИЗМЕНИТЬ

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

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

Есть 3 решения этой проблемы:

Хорошее: Это решение является наиболее надежным, и я предлагаю вам использовать его (не пробовал сам, хотя). Идея этого решения состоит в том, чтобы сгенерировать R файл в другое имя класса, нежели указанное в манифесте. В манифесте пакет будет dev.com.foo.appName, но файл R будет сгенерирован в com.foo.appName. Чтобы достичь этого, следуйте этому ответу

Плохой: НЕ используйте это решение, это действительно плохо, я заявляю, что вы можете его избежать. В каждом файле, который использует файл R, добавляется импорт в файл R с именем пакета в манифесте. Это очень плохое решение, так как вы введете много несвязанного кода, вам нужно будет изменить его в рабочей среде, и для каждого нового класса вам нужно будет запомнить его.

И Ugly: Лучше не использовать это решение, так как это своего рода хак. Это решение полезно только для зрелых приложений, которые не имеют большого количества изменений в своих ресурсах. Когда вы когда-либо меняете свои ресурсы, R файл генерируется снова, затем он генерируется в имя пакета, как в манифесте. Все, что вам нужно сделать, это изменить имя пакета (в манифесте) как в производственной среде, очистить проект, снова создать его и изменить имя пакета в среду разработки. Затем eclipse спрашивает, нужно ли изменять конфигурацию, и вы не хотите. Таким образом, будут существовать 2 файла R, один с именем пакета разработки и один с производственным. Поскольку в зрелых приложениях не так много изменений в ресурсах, вы будете делать это время от времени. Вы не сможете забыть об этом, так как если вы измените ресурс, вы увидите странные ошибки.

Ответ 4

Я знаю, что вопрос задерживается, но я отвечу.

Вы можете использовать Gradle.

В файле build.gradle вы можете определить отдельный buildTypes следующим образом:

buildTypes {
    release {
      runProguard false
      proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'      
    }   

    test {
      applicationIdSuffix ".test"
      versionNameSuffix "t"
      debuggable false
    }

С помощью set applicationIdSuffix для установки можно установить тестовую и выпускную сборку на одном устройстве

Для получения дополнительной информации перейдите к http://tools.android.com/tech-docs/new-build-system/user-guide