Ленивые зависимости Android.Как создать библиотеки AAR перед разрешением зависимости gradle - PullRequest
1 голос
/ 13 мая 2019

У меня есть упрощенная схема проекта группы библиотек с закрытым исходным кодом:

- app
  > references library1, library2
- library1
- library2
  > references library3
- library3

Все 3 библиотеки создают файлы aar, на которые обычно можно ссылаться в зависимостях приложения.

dependencies {
    implementation project(":library1")
    implementation project(":library2")
}

Проблема начинается, когда я хочу протестировать свое приложение с обфусцированным aar s (встроенным в режиме выпуска). В настоящее время плагин Android игнорирует это, поэтому я нашел единственный способ сделать это с помощью предварительно собранных ааров.

dependencies {
    //for debug build just use the local project
    debugImplementation project(":library1")
    debugImplementation project(":library2")
    //for release build use manually added aar in libs folder
    releaseImplementation (name: 'library1-release', ext: 'aar')
    releaseImplementation (name: 'library2-release', ext: 'aar')
    //i need to add library3 too otherwise it will not find
    //method referenced there because aar are not bundled togheter
    //by default
    releaseImplementation (name: 'library3-release', ext: 'aar')
}

И это прекрасно работает.

Для этого я создал такой небольшой скрипт (в app / scripts / build-aar.sh)

//move from scripts folder to root project folder
cd "$(dirname "$BASH_SOURCE")/../../"
//assembleRelease all the aar (which enables Proguard obfuscation)
./gradlew clean assembleRelease --info &&
//copy them in the app libs folder
cp -rf library1/build/outputs/aar/library1-release.aar app/libs/library1-release.aar
cp -rf library2/build/outputs/aar/library2-release.aar app/libs/library2-release.aar
cp -rf library3/build/outputs/aar/library3-release.aar app/libs/library3-release.aar

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

Хотя я хотел бы gitignore все aar в папке libs и собирать их на лету, прежде чем приложение будет искать его зависимости.

Я пробовал что-то вроде этого:

applicationVariants.all { variant ->
    if (variant.buildType.name == "release") {
        variant.preBuildProvider.configure {
            dependsOn(buildReleaseAar)
        }
    }
}

task buildReleaseAar {
    dependsOn (
        ':library1:assembleRelease',
        ':library2:assembleRelease',
        ':library3:assembleRelease'
    )
    doLast {
        //copy the aars from build folders in app/libs folder
    }
}

Но зависимости проверены ранее, поэтому я больше не могу синхронизировать проект, не имея aars в папке libs.


Псевдология для решения этой проблемы должна быть:

1) Наличие нового задания для таких зависимостей, как (obfuscatedAar)

2) С помощью этой задачи проверить, есть ли aars в папке libs, если не запускать сборкуRelease для всех 3 библиотек и скопировать туда получившиеся AAR

Примерно так:

configurations {
    releaseObfuscatedAar
}

dependencies {
    //other implementations libs

    //for debug build just use the local project
    debugImplementation project(":library1")
    debugImplementation project(":library2")

    releaseObfuscatedAar('library1')
    releaseObfuscatedAar('library2')
    releaseObfuscatedAar('library3')
}

//and some other task that build the aar before checking if
//dependency is present

Вопросы:

  • Возможно ли это?
  • Является ли это хорошим подходом для проверки моих правил proguard, добавленных в проекты библиотек (и убедитесь, что я не нарушил публичный API, когда обфускация включена)?

Ссылка на тот же вопрос в Gradle Forum

...