Как вы управляете несколькими средами при разработке приложений для 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-адресом).