Develop Reference

importing an existing JAR or AAR as new project module

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.

How to add a class / an enum to settings gradle script on gradle 6.0+?

I want to add an enum called modules with the path of the sub module and some compilation types.
I used to have this in the buildSrc before gradle 6 and it was accessible in the settings.gradle
But from gradle 6.0, settings.gradle is compiled before buildSrc project. I have moved my enum to the settings.gradle, now it is not accessible to other project level gradle scripts.
The behaviour change is outlined in the below release notes.
https://docs.gradle.org/current/userguide/upgrading_version_5.html#changes_to_plugins_and_build_scripts
They suggest to add the enums / classes used in the settings.gradle to the build script closure, but I am not really sure how to do that.
https://docs.gradle.org/current/userguide/upgrading_version_5.html#plugins_and_classes_loaded_in_settings_scripts_are_visible_to_project_scripts_and_buildsrc

I've recently hit a similar issue, my company have custom code for authenticating with our Nexus which we were keeping in buildSrc. I can't turn this into a plugin since I'd need to store that in our Nexus and then would be in a catch-22 situation as I'd need to authenticate to get the authentication plugin!
I can see 2 potential workarounds for this:
Publicly published jar.
Build your custom classes as a separate jar, or a Gradle plugin if this fits the use case. Publish the jar to a maven repository that you can access from settings.gradle buildscript (for me this is difficult as it's sensitive company specific code).
This might look something like the following in your settings.gradle:
include "project-name"
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.companyname:gradle-utils:0.0.1'
}
}
Commit the binary
This isn't a desirable option but you can manage the source code for your custom buildSrc classes in another repository, then every time you make a change to them (hopefully infrequently) - you can build the new version and commit the built jar into the repositories that need to use it (perhaps under buildSrc). If your custom code has dependencies that aren't naturally on the classpath when gradle runs, you'd need to package these into the jar that you commit as well.
Your settings.gradle might then look like:
include "project-name"
buildscript {
dependencies {
classpath files("buildSrc/gradle-utils.jar")
}
}

How to publish android library to subversion and use it on projects

There are many posts about publishing android library in github. Is there any way to publish android library to the svn?
EDIT:
I have created a libray and build the aar file. I have imported the aar file in to a tag of the svn. (Ex: svnpath/project/tags/library0.0.1.aar)
I want to use this library in a separate project. I want to use this library as
implementation 'com.android.support.constraint:constraint-layout:1.1.2'
like this. how can i achieve this?

As discussed in the comments, Subversion (SVN) is not an appropriate tool for what you are trying to achieve. Subversion is a version control system which manages the versioning of source code files and associated resources, much in the same manner as Git does.
What you are looking for is a dependency management system using Maven, for example Artifactory. This will allow you to publish your .aar files to either a public-facing or private repository and import those dependencies into your build.gradle file. Unfortunately the process for setting up such a service is too broad for the scope of this question, but once you have it up and running you can add it to your build.gradle file under the repositories section:
repositories {
maven {
url "<url of Maven server>"
credentials {
// If you choose to use authentication
username = <your artifactory username>
password = <your artifactory password>
}
}
}

Managing Android shared resources in repository

I have multiple Android projects that I need to manage in various Git repositories, all of which are being managed by repo. I have found a .gitignore file for Android managed by Git, but I don't see things like image files being ignored:
https://github.com/github/gitignore/blob/master/Android.gitignore
I have also read that creating an Android library which contains my resources would allow for a module that is not an .apk, rather a resource for apps to use.
https://developer.android.com/studio/projects/android-library.html
Is there a best practice for storing shared resources?

Creating an Android library project is trivial; distributing it to your other downstream apps is really the interesting part.
Ideally, it would be nice to do this in a way that mimcs how you use other dependencies on Android, namely adding an artifact to the dependencies block in your build.gradle file and having Gradle automatically fetch it. The trouble there is it's a private library that you wouldn't want to host on JCenter, Maven Central, or other public artifact hosting. Some companies have their own internal instances of artifact hosting servers specifically for this.
Fortunately, you can use the maven-publish Gradle plugin to use Maven locally (on your machine) and achieve the same effect. First, in the library project's build.gradle file, you need
apply plugin: 'maven-publish'
publishing {
publications {
mavenJava(MavenPublication) {
groupId 'your.package.namespace'
artifactId 'library.name'
version '0.1' // for example
artifacts = configurations.archives.artifacts
artifact sourceJar
}
}
}
Next, you need to publish this library to your local Maven cache by running
./gradlew publishToMavenLocal
Next in your downstream project, add mavenLocal as a repository and add your dependency using the group id, artifact id, and version you used earlier:
repositories {
mavenLocal()
/* more repositories here */
}
dependencies {
compile 'your.package.namespace:library.name:version'
/* more dependencies here */
}
This should achieve what you want.
The downside is every developer will have to pull down the library project at least once and run the command to publish to their Maven local, and if the library project changes at all, the version must be updated, and all devs need to pull down the changes and publish again locally. This can get a little unwieldy.
Many companies run their own artifact hosting server instances internally to avoid this, so you publish once to the internal hosting and downstream projects just update the version in their build.gradle and let it sync automatically. This requires some additional configuration for the publishing block (of the library) and the repositories block (of the downstream projects); I leave it to you to research that if you intend to go that direction.

Studio failed to download library from gradle repository

I already saw this question, but it is not helping me. First of all, I tried to add google play services in my project using:
dependencies{
compile 'com.google.android.gms:play-services:6.5.87'
}
It was showing me error:
Then I updated my studio to 1.0.1 and gradle to 1.0.0. And then I again synced the project with gradle. And it worked! It showed me another option despite of two options shown in above screenshot. It was "Install the library"(something like that). I clicked it and it popped up a dialog, and I installed the library(it was like downloadind using SDK manager and not like gradle downloads).
Now, I tried to download this library using:
compile('com.fortysevendeg.swipelistview:swipelistview:1.0-SNAPSHOT#aar') {
transitive = true
}
And it gives me error:
My android repository is updated:
Also, my internet connection is working fine. I tried to sync project many times, but same error all the time. I am not running gradle in offline mode:
How to fix this? And what is the permanent solution? And why is all this happening?

I found this question: Studio failed to download library from gradle repository which describes the exact same error, and that question had this bit of build script that you need to add to the build file that has the dependency statement in question:
repositories {
maven { url 'http://clinker.47deg.com/nexus/content/groups/public' }
}
When I do this, it works for me.
As to the general question of why this happens (and the better question of why the solution is different for different libraries):
Gradle, the build system that Android Studio uses, has the ability to automatically download library dependencies from the Internet. By and large this is a big boon for developers, because instead of having to manually download archive files, put them in the right place in your project, check them into source control, and repeat the process for new versions, now you just have to add a line of build script and the build system takes care of the housekeeping for you. The major downsides are Internet connectivity woes, which affect different developers to different degrees, and some added confusion about what it means when you get an error.
How does Gradle know where to download dependencies? Most Gradle build scripts contain a block that looks like this:
repositories {
jcenter()
}
or it may be mavenCentral() instead of jcenter(). This tells the build system to look in the JCenter or Maven Central global repositories (and JCenter is in a simplistic way of thinking about it a value-added mirror of MavenCentral); these contain archives of many versions of many, many, many libraries and are very convenient to use.
You can specify other repositories as well. This swipelistview library hasn't been uploaded to Maven Central, so the developer has made a repository for it available via a URL: if you add that URL to your repositories block, it will look for it there.
I was worried about the fact that you're accessing a SNAPSHOT version of the library -- these are supposed to be unpublished by definition. But adding a dependency on the snapshot version of the library in my test project worked for me, and looking around that URL in a web browser reveals that there's only a "1.0-" (trailing dash included) version of the library, so there's some subtletly there I'm missing; if you know more, please edit my answer or comment.
In any event, there are a couple caveats to this explanation. Some libraries aren't on Maven Central or on any Internet-accessible archive (at least they're not officially published by Android), but are instead published as part of the Android SDK download and maintained via the SDK manager. The Android support libraries and Google libraries fall under this category. If you get errors about those not being found, you have to fix it via the SDK manager.
How does the build system know to look in the SDK for those, since you didn't tell it via the repositories block? This behavior is hardcoded into the Android Gradle plugin.
The other caveat is that there's a detail that trips up a lot of people, which is that you actually have two repositories blocks, though with the usual Android Studio setup they're often in different files. One is in a buildscript block, which usually lives in the top-level build.gradle file and looks like this:
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
}
}
The other often also lives in the top-level build.gradle, but you can augment it with another block in your module's build.gradle file. The top-level one looks like this:
allprojects {
repositories {
jcenter()
}
}
and a module-level one would look like one of the previous examples in this answer. What do all of these mean?
The buildscript block tells Gradle where to find build system plugins. These are plugins that enhance the functionality of the build system itself but don't say anything about your actual project. In Android projects, the Android Gradle plugin is in this category, and unlike the Android/Google libraries, this one does live on Maven Central. The repositories block (in coordination with the dependencies block, which is not the same as the dependencies block for your project, keep reading) in buildscript tells the build system where to go look for these plugins.
The allprojects block in the top-level build file tells the build system to apply the bit of contained script to all build files in the project. In this example, it's telling it to add a repositories block pointing to JCenter to all subprojects. This is a convenience so you don't have to copy/paste it into multiple build files in your modules.
In your modules, you also have a repositories block, which in conjunction with the allprojects thingy, tells the build system where to go to get library dependencies for your project, as was previously discussed.