Is there a way to build a fat aar that includes all the generated code (for example, dagger and ButterKnife generated files) so the client does not have to compile those and is free of their dependency?
I'm trying to make an already made application "plug and play" in which we provide an aar to the client and have to import it. Currently it works but they need to import all our dependencies as well and their version of those dependencies (for example dagger might clash with ours. Also they need to build the generated files.
I have looked at the fat-aar plugin for gradle but it seems like it is outdated and does not work with recent android studio and gradle versions.
Related
I have my legacy version System App which consists of mk files from AOSP.
However, debugging or modifying this app is time-consuming and tedious because you have to port it after building the entire platform.
I just want to modify this app and add features within android studio like the apps I've developed in the past.
Most of the dependencies written in the existing mk file could be configured using gradle script, but androidstudio fails to build because of the part that uses system api or the part where the framework itself is customized.
is there a way for me?
I would split it into two major parts:
For dependencies on Android Application component based Java code:
Try to make a list of all the dependencies you have there and add
them via imports if they're a part of the public Android SDK, and /
or add them to your app via the dependencies block in the module's
build.gradle as an implementation. Make sure to add google() and
mavenCentral() in the repositories. (Plenty of guides on how to add
a dependency of a third party library). And then gradle sync.
For customized framework dependency:
I think the best way to add any custom framework dependency is to add it as a compileOnly file / or implementation / api in the build.gradle of whatever module you have in the app source code on your project as an AAR or a JAR file. To generate this custom framework AAR / JAR (like a CustomServiceManager.java), build that specific module in AOSP environment if it can be built independently or via make framework / make services.
Ref: https://medium.com/#chauyan/import-aosp-framework-jar-file-f0c2ac979a8a
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?
just starting off with coding using Java and publishing it to the play store.
Thinking from a security perspective, I was wondering if dependencies from an android runtime environment get built into an application as libraries. For instance will my deployable application have a file from a Google Android library?
Please feel free to ask more specific questions, and I can try my best to answer those.
Any dependency in your app module's Gradle build script that you add using implementation or api will be packaged into the APK. How much of it will be packaged depends on what you are using from it and your minification (ProGuard) settings.
Things that are not packaged in your APK include:
Test dependencies
The android.jar file that is used at compile time to pull in the Android SDK public API
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'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.