Gradle: Android Studio наследует buildtype

У меня есть типы построения в стиле gradle (Android Studio) 4

android { buildTypes { release { ... } debug { ... } kindle { ... } kindle_debug { ... } } } 

И я знаю, что моя папка src может иметь для каждой сборки тип одной папки. Таким образом, это заканчивается

  src/ -- debug -- kindle -- kindle_debug -- main // used for every project -- release 

На данный момент kindle_debug – это то же самое, что и release и kindle_debug – это то же самое, что и debug .

Как избежать дублирования папок src? Есть ли способ наследовать от release и debug или мне самому установить src-папки самостоятельно в файле build.gradle ?

Изменить: одно решение, похоже, работает, это установить символические ссылки, но я хочу использовать Mac OS и ОС Windows, и не каждый новый пользователь хочет установить символические ссылки самостоятельно.

Изменить 2: я использую теперь вкусы продукта, из-за этого у меня может быть debug / release и с этим google, amazon и samsung. Это лучшее решение для моей цели.

Solutions Collecting From Web of "Gradle: Android Studio наследует buildtype"

Вы можете наследовать от типов сборки, например:

 buildTypes { release { ... } debug { ... } kindle { initWith buildTypes.release ... } kindle_debug { initWith buildTypes.debug ... } } 

Если я правильно понял это, вы хотите, чтобы только несколько файлов отличались между отладочными и релизными сборками? В этом случае должно работать следующее (Моя учетная запись была такой же, как у вас):

https://stackoverflow.com/a/28279105/1041533

Для полноты я вставлю соответствующую часть выше ответа здесь:

  1. Подход на основе каталога Ressource

Цель заключалась в том, чтобы изменить файл в папке xml каждого клиента на основе того, является ли это выпуском или сборкой отладки. Это может быть достигнуто с помощью соответствующей структуры папок. Исходя из первоначального вопроса, у нас есть 3 клиента, и каждый клиент имеет отладочную и выпускную сборку. Вышеупомянутые xml-файлы различаются для каждого клиента и типа сборки. Следовательно, следующая структура каталогов:

 src/ - customerA //Contains all relevant resource files specific to customer A - customerB //Contains all relevant resource files specific to customer B - customerC //Contains all relevant resource files specific to customer C - customerADebug //Contains debug server-settings file for customer A - customerBDebug //Contains debug server-settings file for customer B - customerCDebug //Contains debug server-settings file for customer C - customerARelease //Contains release server-settings file for customer A - customerBRelease //Contains release server-settings file for customer B - customerCRelease //Contains release server-settings file for customer C 

Таким образом, основное содержание каждого аромата продукта было в папке с тем же именем, что и аромат (customerA, customerB и т. Д. См. Первую часть вышеприведенного фрагмента). Теперь этот один файл, который отличается от того, была ли это отладочной или релизной сборкой для каждого клиента, помещается в соответствующие папки, такие как customerADebug -> содержит файл с настройками сервера для режима отладки и т. Д.

И когда вы создаете customerA, например, правильный файл будет выбран, если вы создадите отладочную или выпускную сборку.

Дайте мне знать, если я уточню это дальше.

Ответ может быть немного запоздалым, но у меня была аналогичная проблема, и мне удалось это решить, выполнив следующие действия:

 android { sourceSets { kindle { java.srcDirs = ["src/release/java", "src/main/java"] } kindle_debug { java.srcDirs = ["src/debug/java", "src/main/java"] } } } 

Если вы добавите это в свой файл build.gradle, тип сборки Kindle будет использовать только java-файлы из основной версии и основной папки, а тип сборки kindle_debug будет использовать папку отладки и выпуска.

Конечно, вы можете добавить папку для Kindle или папку kindle_debug:

 java.srcDirs = ["src/kindle/java", "src/release/java", "src/main/java"] java.srcDirs = ["src/kindle_debug/java", "src/debug/java", "src/main/java"] 

Но вы можете столкнуться с повторяющимися ошибками класса.