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.
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.
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( "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.
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 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.