Как вы управляете несколькими средами при разработке приложений для Android?
Мы создаем приложение для Android, которое подключается к облаку. У нас есть тестовый URL для наших API и производственный URL. Мы подключаем приложение к нашим локальным машинам разработки, чтобы разговаривать с базой данных при разработке, но обнаруживаем, что каждый раз, когда мы создаем APk для Play Store, мы модифицируем URL-адрес глобального API для производственного URL.
Есть ли лучший способ управлять средами для Android? Можем ли мы также иметь две версии приложения (версия для разработки) и версию Play Store? Я не могу иметь две версии, так как обе приложения имеют одну и ту же подпись. Как нам лучше всего это сделать?
Ответы
Ответ 1
С андроидной студией и gradle теперь ее просто.
внутри вашего приложения build.gradle редактировать подписи config
signingConfigs {
debug {
storeFile file("debug.keystore")
storePassword "..."
keyAlias "..."
keyPassword "..."
}
prod {
storeFile file("prod.keystore")
storePassword "..."
keyAlias "..."
keyPassword "..."
}
dev {
storeFile file("dev.keystore")
storePassword "..."
keyAlias "..."
keyPassword "..."
}
}
добавить buildTypes
buildTypes {
debug {
buildConfigField 'String', 'BASE_URL', '"http://127.0.0.1:8080/"'
......
signingConfig signingConfigs.debug
}
prod {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
buildConfigField 'String', 'BASE_URL', '"http://prod.example.com"'
......
signingConfig signingConfigs.prod
}
dev {
buildConfigField 'String', 'BASE_URL', '"http://dev.example.com"'
......
signingConfig signingConfigs.dev
}
}
В коде введите базовый url, настроенный в gradle файле этим кодом.
public final static String BASE_URL = BuildConfig.BASE_URL;
Вы также можете поместить другой KEY или любой другой тип, который является типом сборки, указанным в файле gradle, и в коде, который он примет в соответствии с типом сборки, который вы используете.
Возможно даже иметь другое имя пакета.
productFlavors {
my_prod {
applicationId "com.example.packtwo"
}
my_dev {
applicationId "com.example.packone"
}
}
В недавней конфигурации gradle есть некоторые обновления при указании имени пакета. Вы должны добавить flavourDimensions, если используете productFlavours. См. Ниже код с добавленными параметрами flavourDimensions
flavorDimensions "pack"
productFlavors {
flavor_dev {
applicationId 'com.example.packtwo'
dimension "pack"
}
flavor_prod {
applicationId 'com.example.packone'
dimension "pack"
}
}
Это даст вам более подробную информацию о вкусах и размерах продуктов
https://developer.android.com/studio/build/gradle-plugin-3-0-0-migration.html
Проверить дополнительные возможности...
Но если вы используете разные вкусы, вам может потребоваться слияние Manifest и все.
Ответ 2
Это может быть достигнуто с использованием ароматизаторов продукта.
Для достижения этого требования:
Прежде всего, создайте 2 файла под папкой приложения вашего проекта, скажем development.props и production.props. Или вы можете добавить эти 2 файла в пакет под папкой приложения say config.
![введите описание изображения здесь]()
В основном, эти 2 файла содержат ключи и значения. Этот ключ одинаковый для обоих файлов. Но их ценности разные. Эти файлы содержат один ключ: "SERVER_URL" и его значение. Это было бы написано так:
SERVER_URL = "Server_url_value"
В этом случае только URL-адрес отличается. Итак, я добавил в файл реквизита только одну пару "ключ-значение". Вы можете добавить больше.
Затем создайте ProductFlavours в файле build.gradle приложения, скажем, о разработке и производстве. Теперь обращайтесь к различным файлам-реквизитам, содержащим URL-адреса в их соответствующих вариантах:
productFlavors {
development {
getProps('./config/development.props').each { p ->
buildConfigField 'String', p.key, p.value
}
}
production {
getProps('./config/production.props').each { p ->
buildConfigField 'String', p.key, p.value
}
}
}
def getProps(path) {
Properties props = new Properties()
props.load(new FileInputStream(file(path)))
return props
}
Теперь для каждого аромата существует тип сборки. Этот BuildType добавлен в приложение build.gradle. Например, тип сборки Отладка и релиз. И у меня есть два вкуса, то есть разработка и производство. Итак, задача gradle будет создана с использованием как вкуса, так и типа сборки следующим образом:
assemble{flavourName}{BuildType}
Теперь вам нужно ввести только эти команды. Он будет генерировать требуемый APK с соответствующим URL-адресом. Команды:
./gradlew assembleProductionRelease
будет генерировать сборку выпуска с URL-адресом Production.
./gradlew assembleDevelopmentDebug
будет генерировать отладочную сборку с URL-адресом разработки.
./gradlew assembleProductionDebug
будет генерировать отладочную сборку с URL-адресом Production.
./gradlew assembleDevelopmentRelease
будет генерировать сборку релиза с URL-адресом разработки.
Три задачи gradle будут очень полезны. Но последняя задача будет генерировать версию Release с URL-адресом разработки. Но это не рекомендуется. Итак, мы должны остановить разработчика для выполнения этой задачи, т.е. ./gradlew assembleDevelopmentRelease
Теперь Чтобы запретить разработчику создавать сборку релизов с помощью URL-адреса разработки, добавьте этот фрагмент в файл build.gradle приложения:
android.variantFilter { variant ->
if(variant.buildType.name.equals('release')
&& variant.getFlavors().get(0).name.equals('development')) {
variant.setIgnore(true);
}
}
Теперь, если мы попытаемся выполнить задачу i.e. ./gradlew DevelopmentRelease
. gradle прекратит генерировать исключение сборки и throw и скажет: эта задача assembleDevelopmentRelease не найдена в корневом проекте.
Ответ 3
Используйте Ant для создания, по крайней мере, производственных версий. Таким образом, вы можете установить определенные значения конфигурации/флаги во время построения. Скажем, у вас есть файл config.xml, содержащий URL-адрес сервера. У вас могут быть разные цели сборки Ant, которые изменят URL-адрес, чтобы указать на соответствующий сервер. Ознакомьтесь с этим учебником. Это точно объясняет, как это делается.
Ответ 4
Это, я думаю, считается практикой баста в случае, если вы используете студию Android с gradle.
Вы можете посмотреть эту статью: http://tulipemoutarde.be/2013/10/06/gradle-build-variants-for-your-android-project.html
Также доступно в видео youtube: https://www.youtube.com/watch?v=7JDEK4wkN5I
Это также позволяет вам иметь два разных имени пакета для одного и того же приложения.
Он использует gradle ароматы для достижения именно того, что вы ищете, и его очень легко реализовать.
Ответ 5
Вы можете попробовать gradle buildType и productFlavor. Это позволит вам указать разные переменные среды, такие как url, versionName и т.д. И applicationId, которые позволят вам создавать dev и prod.
Для более подробной информации http://developer.android.com/tools/building/configuring-gradle.html
Ответ 6
Я не знаю, какая лучшая практика в этом случае, но мне это нравится:
Вы можете сделать свое приложение LIB и создать 2 приложения: производственное приложение и тестовое приложение. Импортируйте свою библиотеку для этих приложений и создайте свои манифесты (она почти скопирует пасту старого). Затем вы заменяете свои/res/файлы, которые отличаются в каждом приложении... (вы можете создать файл config.xml с URL-адресом).