The new Android Studio IDE uses a new, Gradle-based build system. If you want to reference other android libraries, the process is now a little more complicated . At face value, the docs suggest you need to

• Turn your project into a multi-project-setup
• Have the library’s source on hand, as a subproject
• Create a build.gradle file for the library, if it doesn’t already have one

Keeping a copy of the library sources around is useful if you need to build it again. If you’re using git, git submodules or one of its alternatives would be useful for this.

OTOH, if the author has kindly uploaded it to a maven repository as an aar (an apklib generated by the android-maven-plugin will not work), you can consume it as a normal dependency, something like:

dependencies {
  compile 'com.github.chrisbanes.actionbarpulltorefresh:library:0.7.+'
}

If all you have is the aar itself though, you’ll be out of luck because local aar files are not supported. So something like:

dependencies {
  compile files('libs/some-awesome-library.aar')
}

will not work, only aar files obtained from say a maven repository are allowed.

It turns out that almost any non-file repository is allowed, even flatDirs, so

repositories {
  mavenCentral()
  flatDir {
    dirs 'libs'
  }
}
...
dependencies {
  compile 'com.actionbarsherlock:actionbarsherlock-local:4.4.0@aar'
}

will work, assuming that your local aars are found in the libs dir. Note the addition of @aar, which indicates the packaging type of the dependency. The group (com.actionbarsherlock in this case) doesn’t actually matter as the artifact name, version and packaging type are all that’s used to look up the aar file.

Whilst this does save you the trouble of having to maintain a dependency to another codebase, it means you’ll probably be checking in a magic, binary artifact. For libraries using the maven plugin to generate an apklib, you still need a build.gradle to produce the actual aar though I have found this to be rather straightforward.