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
Related
In recent release of our library we decided to add some kotlin-dsl features to our build, though for now we've added buildSrc build.gradle.kts and Dependencies.kts file containing libraries versions for easier use across all modules.
The problem is that this version builds successfuly on jitpack, but downloaded jars are empty. How do I fix this? Also all the resource files are present. The build log file also differs much from previous ones.
Problematic build log file
Working build log file
A link to library on jitpack: https://jitpack.io/#netigenkluzowicz/api_android
Github link
branch to reproduce these build problems is feature/kotlin, we're working to fix it on fix/jitpack-build branch
To Reproduce
Add this dependency to an Android project, sync and check classes.jars
implementation 'com.github.netigenkluzowicz:api_android:2.4.1'
What we did before this problem started to occur:
Added buildSrc directory with build.gradle.kts and Dependencies.kts.
We also extracted android { } block from our modules build.gradle files, it is now applied from android.gradle file.
I've already went through jitpack issues on github, all I found so far are build errors with kotlin-dsl from late 2018. Was following this guide to make a use of kotlin-dsl, though due to having issues with android { } block I didn't migrate all of our gradle files.
I have an Android application using an Android library. The library is a pretty big open-source project on GitHub, and its authors publish the artifacts to Bintray. I can specify the dependency with the usual syntax dependencies { implementation 'group:artifact:version' } in the app's build.gradle.
Now I want to change some code in the library. I git clone it on my machine, I make my changes, then I build the library. But how can I tell my app to use the library I built locally, instead of the one in Bintray?
I don't want to follow the approach in Gradle Local Project Dependency, because that means that the library code is now part of the application project, but I really want to keep things separated.
I think the solution involves publishing to a local Maven repository. I followed the guide at https://proandroiddev.com/tip-work-with-third-party-projects-locally-with-gradle-961d6c9efb02 but the app's Gradle is still picking the original library from Bintray.
Bintray-based projects have the install task. That's the one to be used instead of publishToMavenLocal.
When using install, the artifact version is automatically set to X.X.X before publishing to the local repository. Therefore, in order for the app to pick up the local library, you have to edit the implementation row to group:artifact:X.X.X.
As the guide https://proandroiddev.com/tip-work-with-third-party-projects-locally-with-gradle-961d6c9efb02 suggests, you also need to add mavenLocal() as the first entry in the repositories section in the top-level build.gradle of the application.
After migrating to Android plugin for Gradle 3.0 the OSS license plugin (https://developers.google.com/android/guides/opensource) no longer includes the licenses from the project's library modules dependencies. Only the "app" module.
I'm using com.google.gms:oss-licenses:0.9.1 and com.google.android.gms:play-services-oss-licenses:11.8.0
If I 'apply' the plugin to all my modules, the third_party_license data is generated in the raw folder for each module. But in the end only the data from the app module end up in the APK.
Is there any workaround for this problem?
Yes that is correct.
Based on my search on how the plugin works, the plugin would generate the data into the res/raw folder of the artifact (aar or apk, but not jar files) based on POM files it can get from the libraries. Then the rest of merging is done by Gradle Android Plugin, and not by the OSS License Plugin, which merges the res folders from all of the sources (dependency libs, modules, main app etc.). However here's is the issue, upon merging, the Android Gradle Plugin would choose one if there are duplicates of the same resource (link to explanation), and the one that is chosen is based on a priority, meaning since both the app module and the lib module are generating the R.raw.third_party_license resource which are duplicates, the one from the app module has a higher priority of being included than the one from the module hence the license information from the module are not included.
There are several ways of fixing this:
Include the same dependencies from your library module in your app module. This is probably the worst idea to do but it does not affect your app since Gradle would automatically resolve the dependencies without any issues especially if they will be of the same version, if they were of different versions then Gradle would choose the latest.
Rather than using a module dependency, publish the module to a maven repo (locally or remotely, here's a link to show how it could be done locally), and add it's dependency as such: implementation 'com.mygroup:library:1.0'. Don't forget to remove it from the project build.settings file. This would generate the POM file of the library module and hence get the plugin to read it and include it's library licenses. This means that the library should be compiled and published before compiling the app module, but also it could lead to some weird compiling issues and confusions when errors happen.
Unfortunately there is one more way that I thought would work however it didn't. It is by changing the dependencies in your library module to api instead of implementation. This would expose the library dependencies into the app module dependencies but would increase the build time of the project. But finally it didn't generate the raw resources properly because it seems that the OSS License Plugin only reads the dependencies from a POM file of library and in this case the POM file is not being generated even if the library module dependencies were exposed. Probably should post this as an enhancement or bug request to the developers of the plugin.
I have an Android module from which I export an .aar file.
I imported this .aar with Android Studio Wizard, project compiles, but crashes at runtime with "java.lang.NoClassDefFoundError".
I checked with debugger, Class.forName("retrofit2.Retrofit").. not found.
After unzipping the .aar & checking the classes.jar, I see only my packages, clearly it didn't packaged the libraries I was referencing in build.gradle (ex: Okhttp, Retrofit, Gson.. ).
What I want is a way to keep my build.gradle dependencies. I would prefer it to be packaged into the .aar if possible, else what is the option? Force the client to add in his own gradle my dependencies?
Extra info: I only have gradle dependencies, no jars.
Distribute the AAR via an artifact repository. The metadata in the artifact repository (e.g., the POM file) will contain the information about your transitive dependencies. It also will have information about the version of your AAR, so that consumers of the AARs have clear information about what version they are using. This is how nearly everything else that you are using is distributed: support libraries, Retrofit, etc.
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.