This post is part of a series on private libraries:
Part 1: Private libraries in Android — why you should consider it
Libraries are one of the foundations of Android development. Think about all dependencies in your Android projects, either from Google (the former Support Library and now AndroidX, Material Components, etc.), or other companies (like Square with their famous OkHttp or Retrofit), or developers who simply shared their own work.
The interest of these public libraries is quite obvious: it allows anyone to reuse in his own project a component made by somebody else. What about private libraries? In what situation should we consider a library with a scope specific to some context or organization?
In this post, we will define the concept of a library and discuss its primary purposes including the context which we consider private libraries interesting at Deezer, the content we put into libraries and how we organize them. Although we will talk about Android development, many principles will also apply to other areas.
What is a library?
The concept of a library has been around since the beginning of computer programming. A library can be defined as such:
An independent collection of behaviors, accessible through a well-defined interface and available for reuse by multiple programs.
In the context of Android, a library corresponds to a versioned, compiled artifact: either a JAR (Java archive) or an AAR (Android archive, that can also include Android specific resources), not to mention native libraries (C / C++ libraries with NDK or more recently Kotlin Multiplatform libraries). Libraries can also be composed of multiple artifacts under the same versioning.
At Deezer, each library is an independent Android project with its own repository that can have multiple modules (with possible dependencies among them), each producing an AAR or JAR. Consequently, unique versioning can apply to the entire library (i.e. to all modules of the library).
