I have an Android Instant App with following structure:
B: base module
Installed: installed app module
Instant: instant app module
F: feature with functional specific to Installed app. F depends on local aar library local-lib located in project\F\libs.
F's build.gradle is following:
repositories {
flatDir {
dirs 'libs'
}
}
dependencies {
api ":local-lib#aar"
}
I tried to include F module to Installed app module like this:
dependencies {
implementation project(':B')
implementation project(':F')
}
But gradle couldn't resolve local-lib, giving error:
Error:Could not resolve all dependencies for configuration ':Installed:releaseCompileClasspath'.
> Could not find :local-lib:.
Searched in the following locations:
... some remote repositories ...
Required by:
project :Installed > project :F
I tried to duplicate libs folder to project\Installed\libs, and it worked. So basically I need 2 copies of local-lib to make this work? How should I organise imports to avoid duplication? Perfect case would be if libs folder was inside F module.
IMHO, the cleanest way to make it work would be to use some local repository, like a Maven, publish your local-lib here, and reference it from here, and do the same for each of your libraries. When you publish to an artifact repository manager - let's say a Maven - you will have your .aar coupled with a pom file, containing all the needed dependencies.
You have to keep in mind here that your aar is kind of a flat file, meaning, while you reference it somewhere, there is not way to keep track of the transitive dependencies of it (that's the job of the pom files on Maven).
This means that when you reference F in Installed, the F aar is added, but Installed doesn't know that it has to get local-lib in order for F to work properly, or doesn't know where. That's why you have lines on the remote repositories: gradle searches everywhere (in every possible place = in every repository you have listed) for the dependency.
When you copy/paste the code as a module of your project, the gradle knows what are the transitive dependencies because it can access the gradle file for each dependency.
When you copy the aar directly inthe Installed/libs folder, it also works because gradle checks here (you probably have a compile line in your gradle checking for that folder).
If you want to keep the flat file, you should try putting somewhere reachable by all modules, on the same folder level (take a look at that question), or you could try to add the local-lib as an Android module project, and not just put it in the libs folder.
Related
I have upgraded Android Studio from 4.1.3 to 4.2, using latest gradle and gradle plugin. Now references to using jcenter() in the build script are deprecated due to jcenter being end-of-lifed:
The suggestion is to "migrate" to mavenCentral(). I have various dependencies that are seemingly not on mavenCentral(), because gradle cannot find them, for example:
I Googled the artifact ("materialsearchview" in this case) and found it on the search platform "MVNrepository":
So here is what I have tried (all unsuccessful) to put a reference into my build script to have gradle find this artifact:
I added a reference to the mvnrepository to my project level build.gradle file (which I didn't expect to work given that mvnrepository is a search mechanism) highlighted in the red box in the pic, i.e.:
maven { url 'https://mvnrepository.com/artifact/' }
I added a reference to the repository identified in the blue box at the bottom where mvnrepository says the artifact is located, i.e.
maven {url 'https://repo.spring.io/plugins-release/'}
This generated a slightly different error:
Could not HEAD 'https://repo.spring.io/plugins-release/com/miguelcatalan/materialsearchview/1.4.0/materialsearchview-1.4.0.pom'. Received status code 401 from server: Unauthorized
I found the .aar file for this dependency, added it to my 'libs' directory and updated my app module level build.gradle file like this:
implementation fileTree(include: ['.jar','.aar'], dir: 'libs')
I did an 'invalidate caches and restart' at this point, thinking AS needed to index the newly added .aar file before gradle would recognize it. No joy.
I specifically added the .aar file to the libs directory, then added a reference to it in the app module build.gradle:
implementation(name:'materialsearchview-1.4.0', ext:'aar')
then did another invalidate cache/restart. No joy.
So I guess I have three questions:
Once I find a reference to an artiface in mvnrepository, is there a proper way to reference it in my gradle script so that the build system can reconcile what it needs?
What other ways are there to find what other repositories that gradle CAN address to see if the item is there?
Why is using the .aar file in the libs directory as I am doing it failing? Why can't Gradle see it there?
Thanks!
After discussing this with Mark Murphy of CommonsWare, I realized I was under a misunderstanding about the relationship between the repositories section of the project level build.gradle file, and the implementation statements of the module level build.gradle file.
Here is a good way to think of it thanks to Mark:
Project level build.gradle, i.e.:
repositories {
google()
mavenCentral()
maven { url 'https://maven.preemptive.com/' }
maven { url 'https://jitpack.io' }
//jcenter()
}
Think of these as "Gradle, look into these repositories to reconcile all the 'implementation' statements."
Then in the module level build.gradle I had this:
implementation fileTree(include: ['*.jar','*.aar'], dir: 'libs')
Think of this as "Oh yeah, grab all these things too, even if I didn't mention them as specific dependencies".
My mistake #1 was in thinking I could have an .aar file in the libs directory which ALSO had a corresponding 'implementation' statement. You can't.
My mistake #2 was that I had an implementation statement that referenced a .aar file that was in maven (which is fine since maven is in my repositories block) which itself referenced an .aar file that was not in maven but only in jcenter (which is not since I just removed jcenter from the repositories block). When I removed the reference to jcenter in the repositories block this dependency ("transitive dependency") was not reconciled and the build failed.
So lessons learned:
Any resource referenced in an 'implementation' statement AND ANY RESOURCE THAT IS IN ITS POM THAT IT DEPENDS ON must ALL be in repositories that you define in the repositories block.
If ANY of the dependencies were in jcenter, since I got rid of jcenter then I must:
Find another repository instead of jcenter that has the same resources needed to satisfy the ALL dependencies associated with the resource in question OR
Gather all the .jar/.aar files that represent that resource (the one you want and all the ones it references), place them in the /libs directory (under the module you are building), make sure your have your fileTree statement correctly formed, and REMOVE references to all those same resources from your 'implementations' statements.
How does one identify all the dependencies you ask? Well you can do it the slow way (like I did at first) and keep finding/adding them until the build doesn't break anymore. Or you can be more clever about it and let Gradle tell you which it will do if you ask it (see the docs here).
Finally - don't forget that it is not enough to make sure the referenced .aar file is in libs. In other words, Gradle does not work like: "I will look first at the repositories to satisfy your implementation dependencies and any dependency they reference, and if they are not there then I will look through all the .jar and .aar files in the spot you told me to look in the fileTree statement". Instead, note that any dependency that is referenced by an item in an 'implementation' statement needs to ALSO be able to be found within the repositories. If it can't then your only choice is to use that dependency graph, determine ALL the dependencies, and put all the .aar files into /libs AND remove any from your 'implementation' statements.
Much easier if you can find another repository instead of messing with all the individual .aar files!
For those who want to try the easier way, just go here Android Studio Archive and download the Android Studio v4.1 (Oct 12, 2020) and install it. It is working fine, I have checked it myself.
how to import JAR or AAR package as new project module in A new Android Studio Arctic Fox | 2020.3.1 Canary 9 ?
please let me know.
This works on Android Studio Arctic Fox Beta 02
Step 1 : Navigate to, File -> Project Structure. You can also press Ctrl+Alt+Shift+S
You will see a window just like below.
Step 2 : Click On app module as shown in image
Step 3 : Click on + icon as marked in image
Step 4 : You will see option to select jar/aar dependency. Click on it
You will see another window just like above asking you to specify path. Specify the path in which you kept the aar/jar file and hit Ok.
That should work
You can directly implement using JAR/ARR file path.
implementation files('/File Path/file.aar')
For Android Studio Bumblebee, original answer given here
I have followed steps suggested by the Android developer site:
Copy .aar file into the libs folder of the app
File -> Project Structure... -> Dependencies
Click on "+" icon and select JR/AAR Dependency and select app module
Add .aar file path in step 1.
Check your app’s build.gradle file to confirm a declaration.
Step 1: Put your aar file in the libs folder. And let’s take the file name is supernover.aar as an example.
Step 2: Put the following code in your Project level
build.gradle file,
allprojects {
repositories {
jcenter()
flatDir {
dirs 'libs'
}
}
}
and in the app level module write the below code,
dependencies {
Implementation(name:'supernover', ext:'aar')
}
Step 3: Then Click sync project with Gradle files.
If everything is working fine, then you will see library entry is made in build ->intermediates -> exploded-aar.
In my opinion, the best way to do this is to deploy the jar/aar to a local maven repository. if you install maven, you can use the mavenLocal() repository in gradle and read from there as with any other repo, regardless of the IDE you are using. All versions of Android Studio will work, all version of IntelliJ will work, VSCode will work, the command line will work, etc. Another advantage is, you'll be able to swap versions of the library as you do with all the others, just change the version in gradle (after deploying the new one), and will work for all your projects. Putting jars/aars manually into a project is just a bad practice, and reaaally outdated to top.
Once you installed maven, type this in your terminal:
mvn install:install-file -Dfile=d:\mylibrary-{version}.aar -DgroupId=com.example -DartifactId=mylibrary -Dversion={version} -Dpackaging=aar
Where you swap aar and jar depending on the type. The package name, group ID and library name are up to you, anything will work. I would use the library's package and name, and version 1.0 if you don`t have a version.
Here's an example link. Is old, but the process is the same. mvn install, then consume from mavenLocal().
For anyone in search of a solution still.
Create a new android Application project.
Convert new project into a standalone Library module.
Add maven-publish plugin to the module-level build.gradle
Connect your project to your Github repository (or create a new one).
In the module-level build.gradle, implement the Github Packages authentication flow. I'm using 'zuko' as an example - replace every instance of that name with your Github login.
android {
...
publishing {
repositories {
maven {
name = "GitHubPackages"
url = uri("https://maven.pkg.github.com/zuko/[git-repository]")
credentials {
username = 'zuko'
password = 'token' // this is a Git Personal Access Token
}
}
}
publications {
release(MavenPublication) {
groupId 'com.zuko.libraries'
artifactId 'choose-a-name'
version '1.0.0'
artifact("$buildDir/ogury-mediation-mopub-5.2.0.aar")
// you can actually put the artifact anywhere you want.
// This is the location of where you place your .aar file
}
}
}
...
}
If everything is connected properly, save your work, and run the the task: ./gradlew publish. The error logs are straightforward so just defer to the instructions and Google for more assistance.
To install a successfully published package into your desired project, use the same auth procedure for publishing.repositories, you don't need the second half, publishing.publications.
example: implementation 'com.zuko.libraries:choose-a-name:1.0.0'
You could configure a repository in you buildscript that looks for dependencies in a local directory
Use this to register a local directory as repository in your app module's build.gradle where libs is a directory under app module (<project>/app/libs/)
buildscript {
repositories {
flatDir { dirs 'libs' }
}
}
then declare your dependencies from the local file tree you registered earlier
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar', '*.aar'])
}
This will include all jar/aar artifacts present under libs directory to be included in your module's dependencies.
PS: Local jar/aar artifacts will expect any transitive dependencies to be on the classpath unless they are fat-jars (package all transitive dependencies within the artifact), so these need to be added explicitly as dependencies.
I have a module with a .aar file in libs folder. I used the solution posted here
[1]: http://kevinpelgrims.com/blog/2014/05/18/reference-a-local-aar-in-your-android-project/ to add the .aar file as dependency and was able to compile the module properly.
Now I want to use this module as a dependency to the main module in my project and compile. However when i try to compile, i do see an error which says that gradle was not able to find the particular .aar file. why would my main module not find a file which is in the libs folder of my sub module. Was wondering if anyone came across this issue.
my project structure is like this
--mainmodule
--build.gradle (submodule as a dependency)
--submodule
--libs
-- abc.aar
Here is the error gradle throws: When unzipping library ':abc:, either group, name or version is empty
If I understand your problem right and you've followed the steps described in the link you shared, then adding this to your mainmodule's build.gradle should do the job:
flatDir {
dirs "../submodule/libs"
}
You basically have the same issue that you fixed in your submodule, since the mainmodule is struggling to resolve transitive dependencies (abc.aar) of submodule.
Recommended way:
While the answer above should fix your issue, Android Studio supports a better way to do this. Import a local aar file via the File>New>New Module>Import .JAR/.AAR Package option in Android Studio v1.3+.
You can then have your submodule depend on that aar-module as follows:
dependencies {
compile project(':aar-module')
}
I am using Android Studio 1.2
I create a private library I want to use that one in another application.
To use it I create an AAR files, but this AAR don't work. I have in my library a dependency to an AAR file.
The AAR files do not the dependencies?
If I use the jar and I includ ans create all the dependencies the project works fine.
NOTE :
I know how to importe the AAR file. The problem is to use an AAR in the AAR..
Thanks.
If I'm understanding your question correctly, there are 3 projects involved:
Library Project 2 --> Library Project 1 --> Application Project
You are editing "Library Project 1" and have added to it's app/build.grade a dependency on the Library Project 2's aar. Something like this: compile 'com.arasthel:gnavdrawer-library:1.1.5'
I am not sure where you are running into an issue, but I'll attempt an answer anyway. If I'm completely off-base, can you please elaborate on how the AAR dependency is not working? Any error messages?, a class/resource not found, etc.
I think it's unlikely you are unable to use a class from Library Project 2 inside Library Project 1, because I just tried this myself and it seems to be working just fine. It's worth noting that the Library Project 1 aar file will NOT include classes or resources from Library Project 2. Library Project 2 will be noted as a dependency in Library Project 1's pom if published using gradle's maven plugin to publish Library Project 1.
My guess is that you are having a problem in the Application Project? Perhaps the class from Library Project 2 is not found in the Application Project?
If that is correct, then there are two possible solutions:
Enable transitive dependencies on the aar dependency in the Application project's app/build.gradle: Instead of compile 'com.example:myLibrary:versionX', make it compile('com.example:myLibrary:versionX'){transitive=true}. I just verified this causes gradle to read Library Project 1's pom and automatically add dependencies found there into the Application Project.
If you would like to use transitive dependencies, your Library Project will need to be generating a pom and publishing it along with the aar. See https://stackoverflow.com/a/30085677/431296 for some additional information on how I have this working.
Manually add the dependency on Library Project 2 to the Application Project - so that your Application has a dependency line for both Libraries. Depending on your specific situation this may or may not be a workable solution.
Add following code to you project build.gradle file, and you should put you AAR file to the libs folder.
repositories {
mavenCentral()
flatDir {
dirs 'libs'
}
}
And finally add compile info to your dependencies:
dependencies {
compile(name:'AARFileName', ext:'aar')
}
I'm currently developing both a library (with no activities) and an application that depends on the library. Currently, I have these as separate projects, and I can copy the generated .aar file from the library project into the application project's libs folder, and re-sync gradle. However, this is an inefficient process because I have to rebuild and manually re-copy the .aar file every time I make a change to the library project. My question is, how can I streamline this process so that my application automatically uses the library's most recently generated .aar file?
1) In your app's settings.gradle include your lib as a project:
include ':lib-project'
project(':lib-project').projectDir = new File('../path/to/lib/project/lib-project')
The path to your lib project is relative to the settings.gradle location on your filesystem
2) in your app's build.gradle add lib project as a dependency:
dependencies {
compile project(':lib-project')
...
}
how can I streamline this process so that my application automatically uses the library's most recently generated .aar file?
Option #1: Dedicated Library
Step #1: Put your app project and the library project as children of a common root directory for the overall project. For the purposes of this answer, I'll call these app/ and library/, respectively.
Step #2: In the top level (i.e., the common root directory), have a settings.gradle file that lists these modules:
include ':app', ':library'
Step #3: In the top level, have a build.gradle file that sets up the Gradle for Android plugin and any other common stuff of interest, such as:
// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:1.0.0'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
allprojects {
repositories {
jcenter()
}
}
(note that the above file is what you get from a native Android Studio project, created by the IDE)
Step #3: In the library/ directory, have a build.gradle file that uses the com.android.library plugin
Step #4: In the app/ directory, have a build.gradle file that has compile project(':library') in its dependencies to pull in the library
It may be that your AAR is the deliverable, not the app (e.g., the library is an open source one for community use, and the app is a demo app). In that case, you might use debugCompile in app/ to pull in the local library project for debug builds, but have releaseCompile to pull in the AAR from a published source, to confirm that you can build from the same thing that users of the AAR use.
Most of my CWAC libraries are set up this way (e.g., cwac-richedit).
Option #2: Publish the AAR Locally
You can use the maven plugin and the uploadArchives task to upload to a local Maven-style repo:
apply plugin: 'maven'
uploadArchives {
repositories.mavenDeployer {
pom.groupId = PUBLISH_GROUP_ID
pom.artifactId = PUBLISH_ARTIFACT_ID
pom.version = PUBLISH_VERSION
repository(url: LOCAL_REPO)
}
}
Here, my constants are pulled in from a gradle.properties file, and LOCAL_REPO is a file:/// URL pointing to a local repo. You can then run gradle uploadArchives to generate the AAR and push it to the local repo.
Then, your app can have a maven { url LOCAL_REPO } closure in the repositories closure, and can pull in the AAR artifact from there as if it was coming from a public repo (e.g., Maven Central).
My CWAC libraries use the uploadArchives task, but only for publishing to my local mirror of my Amazon S3-hosted Maven repo.
This approach would be if you really wanted to work off of the AAR, but wanted to do so from multiple projects. Note that you can certainly publish this to some other sort of Maven repo (e.g., a Sonatype server) for enterprise use.
Option #3: Mod a Module to Point to the Library Elsewhere
This is Pavel Dudka's approach in his answer. I haven't tried this. Off the cuff, this would be a good approach if you want to depend upon the library from multiple apps, but you're not really concerned about having an actual AAR as a thing to distribute around.
And I'm sure there are other options than these three.