In the project that I am working on, the code base has about 25 modules shared between a couple of apps, the idea being that the same code could be reused between the apps.
When I build the project, I almost always get the following error:
Direct local .aar file dependencies are not supported when building an AAR. The resulting AAR would be broken because the classes and Android resources from any local .aar file dependencies would not be packaged in the resulting AAR.
The module causing that error is usually different.
Oddly, when I run the app instead of building the project, it works just fine.
I have tried Invalidating Cache and Restarting and re-cloning the repo but it doesn't fix the issue.
Worth mentioning that the problem seems to affect only a few developers.
Any idea why the project runs but doesn't build?
You are using an AAR file in another project. Parent AAP/Module needs to add all dependencies which you have used in your local AAR file.
Related
In my Android application project I am trying to avoid referencing an external Maven repository in my project from where I would load multiple .aar artifacts which make up one SDK.
Instead, I would like to put the .aar files into my project and then reference them from one of my Gradle Android library modules.
I already tried different approaches - none worked, though.
Approach 1: Composite build (includeBuild)
Inspired by https://stackoverflow.com/a/72672032/35689
Here my artifact(s) cannot be resolved by Gradle.
I also tried this in isolation with the sample project - for some reason it does not work with my artifacts. In the example there is only one .aar file which might be the reason.
Approach 2: One module per aar
Inspired by https://stackoverflow.com/a/70074787/356895
Here I end up with this error:
jetified-externallibrary-1.2.3/res/values/values.xml:113:5-122:13: AAPT: error: style attribute 'attr/shimmer_auto_start' not found.
You have to manually add all of the .aar file's dependencies to your project in order to make this work. You will also have to substitute the maven dependency with the .aar file manually.
The reason is that an individual .aar file does not contain any metadata like maven coordinates, version, dependencies, etc. Therefore Gradle cannot handle any of this for you automatically.
I've got a multi-module Android project which have one module called app which is the Android application, that contains features where each feature is separate module.
I would like to extract one of the feature modules as a aar library.
I started from creating a demo app inside the project that have my feature module as a dependency:
implementation project(':player')
I adjusted the code of the app to make it working and in my Demo app inside the project it was working as expected.
My next step was to build the aar file and include it in separate project. I did it by using task:
Gradle -> player -> Tasks -> build -> build
After importing created aar file in new project I'm getting a lot of java.lang.ClassNotFoundException exceptions because classes from modules that player module depends on are not in the generated .jar file.
I didn't mention, but player module depends on few other modules like domain, base-android, data and so on and it seems like all of those modules are not included in aar file.
At first I thought that changing from implementation for those modules to api will solve the problem, but it didn't.
My question is: is there something I'm missing while building the aar library? I thought that if something is working great when included in the module within one project then it should also work like that when after creating a aar file, but it seems like it's not.
You are getting ClassNotFoundException as your module's aar doesn't contains your other submodules' code or aar files. To fix this issue you can check out this gradle plugin that will include all sub modules's arr into your main module automatically. Check out fat AAR, here is the link : https://github.com/kezong/fat-aar-android
if I have a project with many library projects linked, could I improve build performances by packaging each of them in an AAR and including it in the main project ? Or this will not make any difference since that when the compiler need to assemble the apk it need to package everything together anyway?
Thanks to any one who will give me some clarifcation about performance differences between the 2 approach
I don't think you will save any build time by wrapping an existing .jar file into a .aar file and using that instead of the original .jar file.
As this SO post notes, .aar files are basically just zip files which may contain a jar file and some android resources.
Also, because .aar files are not precompiled into Dalvik byte code, the build process for your apk file must still carry out that step at least once. So, you won't save dexing time just by wrapping the .jar file into a .aar file either.
If you build a typical Android Studio project (with some Android library dependencies specified in the gradle build file) you can see the directory underneath app/build/intermediates/exploded-aar where these files have been unzipped. That work must still be done by your build machine even though you are using a .aar file.
Finally, as you pointed out, the .apk packaging work must still be done at the end of the build.
I believe the Library projects (which you are using) is the best way to go because of two reasons:
The library project gives the direct access to the code base of the libraries which can be compiled and packaged together with the main app code
In case, multiple .aar files are referenced within the project, then during the apk creation the unpacking, merging of resources and Manifest file will increase the build time.
I would like to include this plist parser module in my Android application, ideally without just copying the entire module source into my source tree (if that would even work).
I have successfully added the module as a project into Eclipse (3.7.0) and resolved errors by fixing the build path to include Android 2.1, which is what I am using. However, now I'm stuck. All of the information on using external libraries with your Android project I can find expect you to have a JAR of the library, but I only have this source code. I can run the plist parser module as an Android application, which appears to compile an .apk, but that doesn't actually do anything because it's not a standalone application. Any options to just build the module without running it are greyed out in the Eclipse interface.
How can I either build this module into a .jar for inclusion, or include it in some other way?
Edit: In order to clear the errors in the module after I added it to Eclipse, I followed the instructions in this answer.
You can either convert the whole thing to a library project or simply include the source code in your app's project. To create a library project, you can import the project from github, and after you get it compile, remove any activities, go to the project's Properties->Android and check the 'Is a library' check box. Then add it as a dependency to your own project.
After updating to ADT 14/15 I started having a couple problems with our build.
With one Android based libraries (call it Framework) which is added into the actual android project app (call it App). The Framework project has a couple jar files in its own lib folder which is added to its own build path. Those same jar files are required to be added to the App's build path as well.
So jar files on the Framework build path
Framework/libs roboguice
Framework/libs gson
Those same jar files on the App build path
Framework/libs roboguice
Framework/libs gson
Also the Framework.apk is added via the Android Library panel in the App's project properties.
Both projects are targeting the same Android.
Now when I build the project I seem to have resolved the errors however when running it, at times I receive the Missing Framework.apk in the console window.
So based on this scenario any thoughts on how to correct this build? I have a feeling its still setup incorrectly.
This should help you out!
http://android-developers.blogspot.com/2011/10/changes-to-library-projects-in-android.html