Dependencies

sbt and the Android SDK Plugin for SBT 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 offer fine-grained control about the dependencies, yet they are still easy to maintain. Library dependencies are maintained via the sbt configuration key libraryDependencies. The Play Framework documentation provides a good introduction to managed, unmanaged dependencies and resolves.

Besides simple Java or Scala libraries, you can also reference Androidaar or apklib packages. Usually, the Android SDK Plugin for SBT is able to detect and handle these dependencies correctly, but in some cases it might be necessary to mark them exeplicitly 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 VCSs.

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 several sub-modules. This might be a convenient way to manage large codebases. It also works for Android SDK Plugin for SBT projects. Please refer to the sbt documentation to learn how such a setup is configured.