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.
Related
I am creating SDK and want to modularize it.
And prevent internal APIs from being exposed on your public interface.
Want optional dependency based on features required. If features is not required we can remove dependency and code and imports should not work.
Tried Ways
Submodule dependencies
Fat AAR
Submodule dependencies
when a library module gets built, the .aar artifact will only include code and resources that are in the library module itself. It won’t include:
any code or resources from database and ui-components
links to its transitive dependencies (these go into the build.gradle)
So when the app module directly includes the library as a gradle dependency, it would crash due to missing classes from database and ui-components on its classpath.
Fat AAR
In the fat .aar solution, code and resources of the submodules are bundled into the main SDK module, hence creating a fat .aar
the fat .aar plugin breaks on almost every minor Android Gradle plugin update! This is because it hooks itself into particular tasks of the Android Gradle plugin and these very often get renamed/moved. However, the project maintainer need to do job at fixing those within a few weeks after the breaking change.
Also, because of the way fat .aar references dependencies from submodules, it can significantly increase the binary size of your SDK.
Is there any other possible solution?
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
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.
We are standardizing our infrastructure for Android development and we are trying to incorporate dependency management to our Android library projects. My current track is using the maven android plugin with m2e-android. We have uploaded the Android artifacts to our Artifactory repository with the Android SDK Deployer. We also have an internal framework with a few libraries we can import into our projects and for most part it works fine.
The issue we are facing now is that apklib dependencies containing resource files are hard to set up. The maven plugin can correctly configure the classpath but if the apklib has resource files that needs to be referenced by the parent Android project, Eclipse is unable to find them unless you checkout the Library Project and link it to the parent project through ADT.
After reading m2e-android discussion on issue https://github.com/rgladwell/m2e-android/issues/8, https://stackoverflow.com/questions/6269816/creating-closed-source-android-libraries#answer-6270768 and APKLIB does not get installed in Maven Repo, I'm not convinced maven is the way to go until ADT properly support closed source apk libraries.
I'd like to know how are you handling these kind of dependencies on your Android projects. What strategies are there other than using Maven?
For reference, here's what we have tried so far.
No dependency management. All required jars are stored into the lib folder and pushed to the source control repo. Library projects are set up as subfolders and pushed to the source control repo for each project they are used in. Eclipse project settings are also pushed. Project built with standard ADT Ant script.
Jar dependencies into libs folder and library dependencies as git submodules. Project built with standard ADT Ant script.
Dependency management with maven, including library projects with apklib packaging. Issue with resource files in apklibs.
You can have an insight on how Facebook Android developers address their dependencies issues in this video: How Facebook Built Facebook for Android.
They use Buck for that. Buck is a build system for Android that encourages the creation of small, reusable modules consisting of code and resources. Buck is in github
This might not be the best solution for you but maybe for someone else.
With the advent of Android Studio and Gradle, we are no longer facing issues with project dependencies; Android or otherwise.
Gradle supports Maven dependencies in jar or apklib formats. Popular libraries have been exported to the apklib (aar) format and made available through Maven.