Как остановить Gradle для Android From Building * Все * Типы модулей библиотеки библиотеки на каждой сборке?

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

Как остановить Gradle для Android (внутри или за пределами Android Studio) от создания всех типов сборки библиотечного модуля при запросе на создание одного типа сборки? IOW, если я строю debug, как я могу предотвратить Gradle для Android также из здания release?

Предыстория для тех, у кого есть альтернативные идеи:

Предположим, что у меня есть два проекта Android Studio, A и B. Каждый из них имеет два модуля: модуль библиотеки Android и демонстрационное приложение, которое зависит от этой библиотеки. Итак, у меня есть в общей сложности четыре модуля:

  • A L: проект Библиотека
  • A D: проект Демо-приложение
  • B L: библиотека проекта B
  • B D: демонстрационное приложение проекта B

Пока A и B не связаны, жизнь хороша.

Но что, если я хочу, чтобы B L зависел от A L?

Для release, если я хочу, чтобы эти библиотеки вошли в репозиторий артефактов в стиле Maven, мне нужен вариант release B L, чтобы зависеть от опубликованного артефакта A Lсуб > . Таким образом, моя B L POM имеет правильную информацию о зависимости.

Для debug было бы идеально, если B L может зависеть от рабочей копии A L. Хотя настройка этого немного взломана, я могу заставить его работать.

Но если я добавлю материал в L, например новый класс Java, и я попытаюсь использовать его из B L, я не могу его построить. Моя сборка debug отлично подходит AFAICT. Однако, даже если я действительно действительно не хочу делать release сборку, Gradle для Android настаивает на том, чтобы сделать конструкцию release в любом случае:

$ gradle assembleDebug
:demo:preBuild UP-TO-DATE
:demo:preDebugBuild UP-TO-DATE
:demo:compileDebugNdk UP-TO-DATE
:demo:checkDebugManifest
:demo:preReleaseBuild UP-TO-DATE
:richedit:compileLint
:richedit:copyReleaseLint UP-TO-DATE
:richedit:mergeReleaseProguardFiles UP-TO-DATE
:richedit:preBuild UP-TO-DATE
:richedit:preReleaseBuild UP-TO-DATE
:richedit:checkReleaseManifest
:richedit:prepareReleaseDependencies
:richedit:compileReleaseAidl UP-TO-DATE
:richedit:compileReleaseRenderscript UP-TO-DATE
:richedit:generateReleaseBuildConfig UP-TO-DATE
:richedit:generateReleaseAssets UP-TO-DATE
:richedit:mergeReleaseAssets UP-TO-DATE
:richedit:generateReleaseResValues UP-TO-DATE
:richedit:generateReleaseResources UP-TO-DATE
:richedit:packageReleaseResources
:richedit:processReleaseManifest UP-TO-DATE
:richedit:processReleaseResources
:richedit:generateReleaseSources
:richedit:compileReleaseJava

(где richedit - B L, а demo - это B D в моей номенклатуре выше)

Я прошу собрать сборку debug, но она по-прежнему компилирует сборку release. И сборка release не может скомпилироваться, потому что я пытаюсь использовать B L для использования нового неизданного материала из A L.

Я уверенно уверен, хотя и не на 100% уверен, что если Gradle для Android просто беспечно игнорирует release, когда я пытаюсь построить debug, я бы был в форме ОК.

Конечно, возможны обходные пути:

  • Я мог отказаться от идеи, что это отдельные библиотеки и объединить их в один. Я все еще могу это сделать. Но он уверен, что то, что я пытаюсь сделать, должно быть возможным.

  • Я не мог попробовать использовать изменения A L, пока не опубликую release A L, и в этом случае B L может зависеть от опубликованного артефакта как для debug, так и release. Тем не менее, похоже, что это приведет к большому оттоку патчей в проекте A, так как мой основной потребительский "вариант использования" этой новой функции A - это B. Только потому, что у меня есть изменения в A, которые проходят контрольные тесты, это не значит, что они "Будь то, что нужно B, и я не буду знать этого, пока не смогу построить B с изменениями в A.

  • Вариант вышеописанного обходного пути может быть SNAPSHOT выпусками, где я бы как-то разрешил проверку релизов SNAPSHOT для debug, но не для release или что-то еще. Тем не менее, сочетание Maven, Gradle, Android и SNAPSHOT все кажется довольно задокументированным, и я понятия не имею, если это то, что я должен преследовать. И, как и в предыдущей палитре, это все равно приведет к тому, что release будет построено без необходимости; сборка просто преуспеет в моем случае.

Есть ли какой-то параметр Gradle для Android где-то, что мне не хватает, что говорит debug означает просто debug?

Ответы

Ответ 1

fooobar.com/questions/133871/... Если вы исправите свою проблему, мне было бы интересно узнать, как это сделать, потому что она не полностью работоспособна, но использует gradle сборки только с учетом отладки.

Здесь существенные части:

В окне панели "Варианты сборки" слева вы должны увидеть оба своих модуля, а рядом с ними - текущие "активные" варианты. Например,

app debug 
custom_lib debug

Build > Make Project

Создает каждый модуль в проекте в своем текущем варианте

https://code.google.com/p/android/issues/detail?id=52962 потребует создания варианта выпуска custom_lib, и поэтому вы в конечном итоге создадите оба.

Используйте параметр, который говорит Make Module app. Этот параметр изменится с приложения на lib на основе текущего выбора на панели "Проект" или на основе текущего редактора и всегда будет делать только то, что необходимо для создания текущего модуля.

Ответ 2

Здесь есть ошибка: https://code.google.com/p/android/issues/detail?id=52962

Есть ли комментарий № 35, т.е.

Попробуйте установить это в проекте зависимостей

android {
    publishNonDefault true
    ...
}

и это в проекте, который использует его

dependencies {
    releaseCompile project(path: ':theotherproject', configuration: 'release')
    debugCompile project(path: ':theotherproject', configuration: 'debug')
}

Взято отсюда: https://code.google.com/p/android/issues/detail?id=66805

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