sbt and sbt-android offer a wide range of possibilities to include external code into your project. Besides pulling library as managed dependencies from the web and dumping *.jar files to a libs/ folder, you can also create sbt sub-projects or reference code from a Git repository.

Managed Dependencies

The preferred way to add dependencies are managed dependencies. They are easy to maintain and offer fine-grained control of the dependencies. Library dependencies are maintained via the sbt configuration key libraryDependencies. The sbt documentation provides more detailed information on managing dependencies.

libraryDependencies ++= Seq(
  "com.android.support" % "appcompat-v7"    % "23.1.0",
  "com.android.support" % "cardview-v7"     % "23.1.0",
  "com.android.support" % "design"          % "23.1.0",
  "com.android.support" % "gridlayout-v7"   % "23.1.0",
  "com.android.support" % "recyclerview-v7" % "23.1.0",
  "com.android.support" % "support-v4"      % "23.1.0")

Besides simple Scala or Java libraries, you can also reference Android aar or apklib packages. Usually, the sbt-android plugin is able to detect and handle these dependencies correctly, but in some cases it might be necessary to mark them explicitly with aar() or apklib() (e.g. aar( "com.android.support" % "appcompat-v7" % "23.1.0" )).

After adding a managed dependency, you have to run sbt reload and you should also run sbt clean to enforce a rebuild of the Proguard cache.

Unmanaged Dependencies

It is sometimes necessary to drop in a simple *.jar file as a dependency. This jar file is then called an unmanaged dependency and you are generally discouraged to use it. It is harder to maintain than a managed dependency and it does not play well with version control systems.

The jar file may be placed in the src/main/libs/ directory and will then be automatically picked up by sbt in order to compile your code. A valid drop in location is also test/main/libs/, if you want to narrow the scope or your unmanaged dependency.

sbt Sub-projects

sbt allows you to split your codebase into sub-modules. This might be a convenient way to manage large codebases. It also works for projects using sbt-android. Please refer to the sbt documentation to learn how such a setup is configured.