Android Studio, как упаковать один AAR из нескольких проектов библиотеки?
Я создаю проект библиотеки Android, который имеет зависимость от другого проекта внутренней библиотеки.
Мне интересно, есть ли способ упаковать одну библиотеку AAR, которая уже содержит внутри нее внутреннюю библиотеку. Я хотел бы поделиться только с одним пакетом библиотеки AAR для разработчиков приложений.
Так выглядят мои файлы build.gradle, но в настоящее время они создают отдельные файлы AAR, и оба они должны быть включены в Application build.gradle. Поскольку приложение разрабатывается другой компанией, нам нужно совместно использовать окончательный файл AAR, а не полные проекты библиотеки.
----- internalLib -------- → → → → →
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.android.tools.build:gradle:0.7.+'
}
}
apply plugin: 'android-library'
repositories {
mavenCentral()
}
android {
compileSdkVersion 18
buildToolsVersion '18.1.1'
}
dependencies {
compile 'com.android.support:support-v4:18.0.0'
}
----- externalLib --------
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.android.tools.build:gradle:0.7.+'
}
}
apply plugin: 'android-library'
repositories {
mavenCentral()
}
android {
compileSdkVersion 18
buildToolsVersion '18.1.1'
}
dependencies {
compile 'com.android.support:support-v4:18.0.0'
compile project(':internalLib')
}
Ответы
Ответ 1
Нет механизма для объединения библиотеки. Это немного сложно, поскольку вы, вероятно, хотите контролировать, какие зависимости объединяются (например, вы, вероятно, не хотите включать поддержку-v4 там). Также вам нужно объединить ресурсы и манифест Android.
В настоящее время нет никакого способа легко взломать что-либо, если вы не уверены, что у ресурсов нет конфликтов между двумя папками res (например, вы могли бы иметь strings_a.xml в одном lib и strings_b.xml в другой lib). Таким образом вы можете просто "объединить" две папки res, скопировав их оба в одно и то же место (в отличие от слияния на уровне андроида).
Для манифеста это будет более сложным, но выполнимым с помощью некоторого пользовательского кода.
Предоставление встроенного механизма для этого очень низкое для нашего приоритета, поэтому не ожидайте его в ближайшее время.