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.
Related
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.
I collected the Gradle log from my daily build in Android, and I am wondering what is the meaning of
Executing transform IdentityTransform -> ExtractAarTransform -> AarTransform on artifact support-core-ui.aar (com.android.support:support-core-ui:28.0.0)
Just add the support-core-ui:28.0.0 aar to the classpath ?
That's all? correct me if I'm wrong. Thanks!
For aar dependencies, it usually includes .jar (the class files), aidl, jni libs and resources, when you integrate it to your project, gradle tasks will extract those classes and other folders for subsequent steps to process, this is what ExtractAarTransform does, see source code ExtractAarTransform.
For AarTransform, it returns the content of an extracted AAR folder, see AarTransform
AAR or Android Archive is a file that you can use as a dependency for an Android app module and are used as Android Library. Read more here about them. It is basically an archive format like JAR but containing Android App modules as well as layout etc files.
Here's more about the specific android library support-core-ui:28.0.0 aar.
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.
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
I'm developing my project using Android Studio and I have a library imported as module into my project with some xml files modified to fit my needs. My question is if there is a way of modifying those resource files if I add the library as a maven dependency or it can be done only by adding it as a module.
Thanks!
If you add a library as a Maven dependency, e.g.
dependencies {
compile 'com.foo:1.0.0'
}
it's going to download that dependency from the Maven repository in whatever format is specified in the artifact, typically JAR or AAR. If it's downloading a prebuilt library like that, you can't make any local changes to it.
If you need to make changes, your best bet is to include it as a module instead of a Maven-style dependency like that. However, if this is a common library that will be shared among multiple projects, you have a number of options to make that sharing easier. You could build it as a library and include it in your projects via that Maven-style include (perhaps deploying the library to a local or organization-wide repository), or if it suits you better, you could put the library in a common place on local disk and reference it in-place via your settings.gradle file.