Условные зависимости с Gradle, возможно ли это?

У меня есть проект Android (уже перенесен в Android Studio и с помощью Gradle), который состоит из разных модулей.

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

Таким образом, ресурсы были разделены на два разных модуля.

Оригинальный автор этого проекта работал в Eclipse и переключил модули ресурсов, включенные в зависимости, на основе того, какое приложение он хотел построить. И он также использовал для изменения вручную имя пакета в AndroidManifest.xml

Я хотел бы автоматизировать все это и все еще иметь одну базу кода, но у меня есть две цели сборки с определенными модулями для каждой цели. Это можно сделать с помощью Gradle?

Update:

Чтобы сделать вещи еще сложнее, у моего проекта есть иерархия, которая в значительной степени такова:

--+--MainProject
  +--LibData
  +--LibBase
  +--LibResA
  +--LibResB

Где:

  • Основной проект зависит от LibBase и LibData.
  • LibData зависит от LibBase
  • LibBase либо зависит от LibResA, либо от LibResB на основе окончательного APK, который мне нужно создать.

Как я уже сказал, я попытался реализовать это с помощью вкусов, добавив в MainProject build.gradle следующее:

productFlavors {
    producta {
    }
    productb {
    }
}

И затем в LibBase я добавил в свой build.gradle следующее:

dependencies {
    productaCompile project(':LibResA')
    productbCompile project(':LibResB')
}

Но тогда, когда я создаю проект, LibData не может найти классы и ресурсы, унаследованные от LibBase. Так что теперь я застрял в этой ошибке. Для меня это похоже, что LibBase не копируется в промежуточные продукты LibData. Таким образом LibData не может разрешать классы в LibBase, но это просто мое предположение.

Обновление 2:

Я продолжал исследовать эту проблему, и теперь я изменил свои файлы build.gradle, чтобы выглядеть так:

Основной проект build.gradle:

defaultPublishConfig "productaRelease"
publishNonDefault true

productFlavors {
    producta {
        applicationId "com.producta"
    }

    productb {
        applicationId "com.productb"
    }
}

dependencies {
    compile project(':LibData')
}

LibData build.gradle(не имеет вкусов продукта, только зависимости):

dependencies {
    compile project(':LibBase')
}

LibBase build.gradle:

defaultPublishConfig "productaRelease"
publishNonDefault true

productFlavors {
    producta {
    }

    productb {
    }
}

dependencies {
    productaCompile project(path: ':LibResA')
    productbCompile project(path: ':LibResB')
}

Таким образом, я не получаю ошибок при выполнении обычного gradle clean build, но я вижу, что вложенные ресурсы всегда принадлежат LibResA, так же как и defaultPublishConfig, который используется всегда.

Если я открою этот проект в Android Studio (0.8.1 атм), результатом будет то, что если я попытаюсь переключить вариант сборки модуля LibBase и установить его в productbRelease, появится следующая ошибка: Ошибка: LibBase 'имеет вариант "productbRelease", но модуль "LibData" зависит от варианта "productaRelease".

У меня заканчиваются идеи.

Ответ 1

Не лучший способ сделать это, но если productFlavors недостаточно, чтобы указать условные зависимости, вы можете положиться на встроенный if и оценить его на основе некоторого значения, которое может быть введено через внешние свойства.

Например, вот как я переключаю LeakCanary (no-op - это просто пустая реализация другой):

build.gradle

dependencies {
    compile "com.squareup.leakcanary:leakcanary-android"+(project.ext.has("leakCanary")?"":"-no-op")+":1.3.1"
}

Чтобы построить с помощью com.squareup.leakcanary:leakcanary-android:1.3.1:

$ ./gradlew :app:assembleDebug -PleakCanary

По умолчанию он строит с пустой реализацией com.squareup.leakcanary:leakcanary-android-no-op:1.3.1:

$ ./gradlew :app:assembleDebug

Это обеспечивает быстрый и более гибкий способ переключения вещей с помощью команды build, но слишком много, и все будет очень беспорядочно.

Ответ 2

Да, это так. Новая система построения Android, основанная на Gradle, поддерживает ваш прецедент с концепцией продукта. http://tools.android.com/tech-docs/new-build-system/user-guide

Обратите внимание, что вы, скорее всего, захотите переключиться с Eclipse на Android Studio при переходе на Gradle build.