Develop Reference

How to reference multiple aar artifacts in a com.android.library module?

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.

Building aar library from multimodule project

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

Why so many metadata files in Android studio?

I created a new project in Android studio and got many files generated, where as my actual code is found in just one folder - src.
Why the so complicated structure? Please explain the motivation of putting meta-files at the root of the project instead of some inner folder named gradle.

Android build system consists of an Android plugin for Gradle. Gradle
is an advanced build toolkit that manages dependencies and allows you
to define custom build logic. Android Studio uses a Gradle wrapper to
fully integrate the Android plugin for Gradle.
Android Studio projects contain a top-level build file and a build file for each module. The build files are called build.gradle, and they are plain text files that use Groovy syntax to configure the build with the elements provided by the Android plugin for Gradle.
Gradle is an automated build toolkit that allows the way in which projects are built to be configured and managed through a set of build configuration files. This includes defining how a project is to be built, what dependencies need to be fulfilled for the project to build successfully and what the end result (or results) of the build process should be. The strength of Gradle lies in the flexibility that it provides to the developer.
For more info you may visit
Gradle Tutorial
Android Application Modules

First of all if you don't want to see those metadata... you can change it(see Image)..
gradle is required to compile your project. for example: In gradle file we specify minsdk version,maxsdk version and dependencies etc
To Know more about gradle go to http://gradle.org/the-new-gradle-android-build-system/

Why the so complicated structure?
IMHO the structure you are referring to is pretty straightforward but your assumption that all those meta-files are related with gradle is wrong.
Meta-files related with your android application are located inside the "app" sub-folder. You have some gradle files there because those are for the purpose of building that specific module.
As pointed out before in a previous answer the best resource to understand the file tree structure for this part is here.
You also have some metadata generated by the IDE (.idea sub-folder):
IntelliJ IDEA stores the configuration data for projects and their
components in plain text XML files making it easy to manage and share
project configuration data with others.
And .iml files:
A module is a discrete unit of functionality which you can compile,
run, test and debug independently.
Modules contain everything that is required for their specific tasks:
source code, build scripts, unit tests, deployment descriptors, and
documentation. However, modules exist and are functional only in the
context of a project.
Configuration information for a module is stored in a .iml module
file. By default, such a file is located in the module's content root
folder.
More info about can be found here.
Please explain the motivation of putting meta-files at the root of the
project instead of some inner folder named gradle.
As mentioned before in some previous answers some metadata is related with the configuration of your project itself and some is module-specific. One example is the build.gradle files. The global file has this comment:
// Top-level build file where you can add configuration options common to all sub-projects/modules.
About the motivation I only assume it was for simplicity and to keep the semantics of the project structure. Other possibility is that it was just by convention.

How to create an inclusive aar file in Android

How do we create an aar file that includes all its dependent projects in Android gradle build?
Say I have ProjectA that is Android gradle library that depends on another library called ProjectB which is in ant build. I would like to build an aar file thats inclusive of 'ProjectB`.
If its not possible across two different build systems.

How to convert apklib to aar

As Gradle does not support apklib dependencies how can one migrate from apklib dependencies to aar dependencies? Is it possible to either manually or automatically convert apklib dependency to aar? If yes - how, if no - why not?
In this question I assume that I don't have original project for apklib, but rather the file itself.

apklib doesn't contain object files, only source files, so the only way it can be included in any project is by recompiling it. According to some docs you can read at:
Android dependencies : apklib vs aar files and https://plus.google.com/+ChristopherBroadfoot/posts/7uyipf8DTau
The apklib format was invented as a way to share Android code+resources. It’s essentially a zipped up Android library project, which was already the status quo for code+resource sharing.
And you can see in Chris Broadfoot's post that the task that generates the apklib just zips up the AndroidManifest.xml file and the src and res directories:
task apklib(type: Zip) {
appendix = extension = 'apklib'
from 'AndroidManifest.xml'
into('res') {
from 'res'
}
into('src') {
from 'src'
}
}
Note that his post is about creating an apklib from Gradle, which is a slightly weird thing to want to do, but it provides a pretty clear idea of how one of these things is structured.
The good news is that this is "standard" Android project structure as of when Eclipse was the primary IDE, and Android Studio knows how to import modules that look like this. So follow these steps:
Unpack your apklib into a temporary directory. It's in zip format, so something like unzip library.apklib should work.
Look at what's unpacked. You should see a directory containing AndroidManifest.xml, src, and res folders.
In Android Studio, inside an existing project, choose File > Import Module and point it at the directory from step 2.
Android Studio should manage the import by copying the files into your project in a new module, arranging them in its preferred directory structure, and will add a build.gradle file for the module.
At this point you're up and running. If you actually want the .aar file, then check to see if your new module is set up as a library module or an application module. In its build.gradle, if you've got apply plugin: 'com.android.library' then it's a library module, and Gradle will generate an .aar as part of the build: it will be in the build/outputs/aar directory after a successful build.
If your module imported as an app module and not a library (apply plugin: 'com.android.application', then change that apply plugin statement, and you may also need to remove the applicationId statement from the build file. Now it should compile as a library and generate a .aar.
Happy coding!

You cannot convert the apklib to aar. You have to update the dependencies manually to point to an aar file. The aar is compiled and contain lint and proguard rules which the apklib can't necessarily determine automatically.
You can read a bit more on the differences here:
Android dependencies : apklib vs aar files