I'm new in gradle and cannot find any documentation about this feature.
All I noticed is that
compile 'com.github.asne:asne-vk:0.2.1' caused some manifest merging problems (some grunting abot different minSdkVersions) and that compile 'com.github.asne:asne-vk:0.2.1#aar' works fine.
The AAR format
is the binary distribution of an Android Library Project.
As described here in the official Android Tools documentation.
In your case, when adding a compile dependency in an Android Gradle project, adding "#aar" means that you would like to fetch the #aar file and not a regular JAR file.
Actually that is not a classifier. Classifier (the term coming from Maven) refers to something else.
See http://www.gradle.org/docs/current/userguide/dependency_management.html#sec:how_to_declare_your_dependencies
This is an optional classifier which indicates which artifact should be downloaded. In this case aar instead of jar is chosen. Here You can find the docs. Search for classifier.
Related
I am trying to publish an Android library written in Kotlin as an AAR on Bintray to distribute it. I have already configured the whole project following various resources that I found online, and the publishing via bintrayUpload goes smoothly. Here's my build.gradle.kts.
However, when I import the library in another project, I can reference all the classes correctly but:
My library depends on RxJava 3, but that (and other dependencies) are not automatically downloading when importing my library in Gradle, resulting in Android Studio complaining about all the Rx classes.
I can't see the sources and the JavaDoc.
On Bintray, everything looks normal: I can see two JAR files (-Javadoc and -sources`), one AAR, and the usual POM file. I've inspected all of them, and they contain everything I'm expecting, including the dependencies in the POM file.
You can inspect the full source code here and the Bintray artifact here.
What am I doing wrong?
I had the same problem with maven-publish plugin. Sources were uploaded to maven repository but could not be downloaded together with aar. Sources were not included in .module.
I have found this plugin: https://plugins.gradle.org/plugin/xyz.tynn.android.sources - with this, sources are included in .module and are automatically downloaded together with aar.
This plugin doens't require any extra tasks for generating sources neither adding extra artifacts.
To use it all what has to be done is apply plugin: "xyz.tynn.android.sources" and publication configured according to official Android documentation
https://developer.android.com/studio/build/maven-publish-plugin
There is also plugin for JavaDoc https://github.com/tynn-xyz/BuildSrc/blob/master/README.md
Not sure why I can't find any answers on this. If I convert my library project into an .aar using Gradle in Android Studio, does it retain all the dependencies of that module?
I'm asking because I'm trying to use a Gradle generated .aar locally, but it looks like only some of the original dependencies have been packaged. Namely, it complains that I'm missing 'OkHttp', but if I add it to the main project I get duplicate class errors.
Usually a library does not directly contain its dependencies. This does not matter whether it is an aar or a jar. Instead, the library declares its dependencies in the Gradle build file and they are resolved when someone uses the library.
I have a library project used by my project. Also my project has several build flavors. In code I reference some classes from that library. I need that library to be removed from my .apk for some of the flavors. I know that this will lead to NoClassDefFoundError but it's ok for me.
I tried to use flavorCompiletask instead of compile but this were leading to errors during compilation of my project (as expected). So how can I make that libeaey project present during compilation but removed from .apk?
P.S. I know that I can remove it during compilation AND alter some of the code files which are using the classes from that library but for me NoClassDefFoundError is ok so I'd like to not have different versions of the same .java files per flavor.
EDIT1
I've found this article but Gradle version seems to be older then current one. Also now I know that I'm looking fot ability to add compile time dependencies.
you could add flavour specific compile block in dependencies, so ex. if you have flavour free and pay
use
dependencies {
payCompile '<something>'
}
you might use provided:
dependencies {
provided 'optional-lib'
}
I've moved my project to Android Studio a month ago, and I'm glad I did, despite the need to switch to a new (and more powerful) build system (gradle). One thing I'd have known in Eclipse, but I can't figure out how to achieve now, is patching the support library. I know that it does not sound like a good practice, but a couple of code lines are driving me crazy, and the solution would be to simply modify it to solve my problem.
I've tried to modify the code in the sdk's ".\extras\android\m2repository\com\android\support" directory, but that does not seem to affect the code that is really used for compilation.
Any idea about how to achieve this ?
Edit:
I tried to create a module "SupportLibraryV4" in my project, and this is what gradle tells me when I try to build it :
Error Code:
1
Output:
trouble processing "java/android/support/v4/R$anim.class":
Ill-advised or mistaken usage of a core class (java.* or javax.*)
when not building a core library.
This is often due to inadvertently including a core library file
in your application's project, when using an IDE (such as
Eclipse). If you are sure you're not intentionally defining a
core class, then this is the most likely explanation of what's
going on.
However, you might actually be trying to define a class in a core
namespace, the source of which you may have taken, for example,
from a non-Android virtual machine project. This will most
assuredly not work. At a minimum, it jeopardizes the
compatibility of your app with future versions of the platform.
It is also often of questionable legality.
If you really intend to build a core library -- which is only
appropriate as part of creating a full virtual machine
distribution, as opposed to compiling an application -- then use
the "--core-library" option to suppress this error message.
If you go ahead and use "--core-library" but are in fact
building an application, then be forewarned that your application
will still fail to build or run, at some point. Please be
prepared for angry customers who find, for example, that your
application ceases to function once they upgrade their operating
system. You will be to blame for this problem.
If you are legitimately using some code that happens to be in a
core package, then the easiest safe alternative you have is to
repackage that code. That is, move the classes in question into
your own package namespace. This means that they will never be in
conflict with core system classes. JarJar is a tool that may help
you in this endeavor. If you find that you cannot do this, then
that is an indication that the path you are on will ultimately
lead to pain, suffering, grief, and lamentation.
1 error; aborting
impressive !
Android sdk doesn't have all required files for building support library.
You need to checkout additional repositories from https://android.googlesource.com:
platform/frameworks/support
platform/prebuilts/gradle-plugin
platform/prebuilts/maven_repo/android
platform/prebuilts/sdk
platform/prebuilts/tools
Please, keep the directory structure as in android repository.
Now you could change any code in support library. If you need to change support library for api v.4 do it in "platform\frameworks\support\v4". For building patched version of support library use gradle with next command:
platform\frameworks\support\v4\gradle clean jar
Resulted jar could be found in "platform\out\host\gradle\frameworks\support\v4\libs\". Put it to the libs folder of your project and add in build.gradle file.
Updated answer 2016 for Linux and OS X using the bundled gradle wrapper instead of the system's gradle installation:
Checkout the following repositories from https://android.googlesource.com and keep the directory structure:
platform/frameworks/support
platform/prebuilts/gradle-plugin
platform/prebuilts/maven_repo/android
platform/prebuilts/sdk
platform/prebuilts/tools
platform/tools/external/gradle
Modify files in the library:
Change files in platform/frameworks/support/
Build AAR
cd platform/frameworks/support
./gradlew jarRelease
The resulting .aar is in platform/out/host/gradle/frameworks/support/<module>/build/outputs/aar/
Add to project
Create a libs/ folder next to your app's build.gradle
Add libs folder to build.gradle: repositories{ flatDir{ dirs 'libs' } }
Copy the .aar file to libs/
Add aar to your dependencies section in build.gradle, e.g.: dependencies { compile(name:'my_custom_supportlib_module', ext:'aar') }
Module already in project
When you patches a support library module that other modules depend on, you'll have it twice in the build causing errors. This can be avoided by excluding the original dependency.
If you for example patch recyclerview-v7 and add
dependencies {
compile(name:'recyclerview-v7-release', ext:'aar')
}
you have to exclude the dependency like this. Change
compile "com.android.support:design:24.2.1"
to
compile("com.android.support:design:24.2.1") {
exclude group: 'com.android.support', module: 'recyclerview-v7'
}
for all modules that depend on the patched module.
Patch the SupportLib and add it manually as a jar:
Put the SupportLib jar into the libs folder
Right click it and hit 'Add as library'
Ensure that compile files('libs/supportlib.jar') is in your build.gradle file
Do a clean build
Disclaimer: Android Studio: Add jar as library?
Turns out that Ilya Tretyakov's answer only works for parts of the support library that don't have resources because they can't be put into a .jar.
The correct way to build for example the design-support-library is as follows:
checkout these repos from https://android.googlesource.com and keep the file structure:
platform/frameworks/support
platform/prebuilts/gradle-plugin
platform/prebuilts/maven_repo/android
platform/prebuilts/sdk
platform/prebuilts/tools
navigate to platform/frameworks/support/design and edit whatever file you want. Now rebuild everything with gradle clean assembleRelease
you can find the resulting library file support-design-release.aar in platform/out/host/gradle/frameworks/support/support-design/build/outputs/aar
create an app/libs folder in your project and edit the app/build.gradle:
repositories{
flatDir{
dirs 'libs'
}
}
dependencies {
compile(name:'support-design-release.aar', ext:'aar')
}
do a clean rebuild of your project and everything will work as intended
I'm using the new Android build system that is based on Gradle, together with the early access preview Android Studio. Now, I have two projects: an Android library project, and an Android app project (basically a demo for the library).
In the library project I have added a dependency to the gson library, so my build.gradle file looks like this:
dependencies {
compile 'com.android.support:support-v4:13.0.+'
compile 'com.google.code.gson:gson:2.2.+'
}
Still, everything works fine and dandy and I'm able to use gson in my library and then my app. But I want to understand where this library is embedded. I've opened both the .aar that is built by the library project and the .apk of the demo app. I was expecting to find the jars for the two dependencies in at least one of these, but I didn't.
So where are they?
From Android Tools website:
These items, plus the output of the compilation of the project’s own source code, are sent to dex for bytecode conversion and inclusion in the final APK.
In other words, they are in your *.dex file inside the APK.
As #SharkyXTS said, the code from any external dependencies is compiled into the final .dex file inside your APK. The reason why you can't find any references to these dependencies in the .aar is because there aren't any.
The .aar format is only supported through Maven for now, so dependencies are found through there. I believe there are plans to eventually support local .aar dependencies (without Maven), but the Android plugin isn't quite there yet. You can see this issue for more information.