Initial draft

1 files changed, 13 insertions, 0 deletions

diff --git a/full-description.md b/full-description.md
new file mode 100644
index 0000000..d15b8e6
--- /dev/null
+++ b/full-description.md
@@ -0,0 +1,13 @@
+The first step in Android Open Source Project (AOSP) development is coming to terms with its peculiar build system.
+Despite being modular, AOSP's build system can be quite complex and deviate greatly from most other commonly used systems.
+Until version 7, AOSP used a Makefile based system, which in contrast to other Make based build systems, didn't rely on recursive Makefiles that find and invoke other Makefiles contained in subdirectories. Rather it used a custom script that explores all directories in the source directory in search of Android.mk files, which describe how a local module is built and handled.
+The configuration of such system also differs from others such as GNU autotools or kernel-style menuconfig, relying instead on variables that are set either as part of the shell environment or statically and ahead of time on product and device Makefiles.
+As AOSP got larger this system got slow, error prone and hard to scale and test. This Makefile-based system is in the process of being replaced by Soong which aims to add flexibility and speed by incrementally replacing the old Makefiles with Blueprint files, simpler declarative JSON-like descriptions of modules, that get translated into a Ninja manifest describing the commands that need to be run.
+During this transition the remaining Makefiles are translated to Ninja by Kati instead of being executed directly.
+Most GNU/Linux distributions use package managers, which wrap around the build system of choice of the software being packaged and bundles it into a reusable package that can be installed for direct use and or as a dependency for others. These packages can also be delivered and updated via software repositories after the initial installation of the distribution.
+In AOSP, there is no package manager, most software components have to be built from git repositories and are bundled into a single file which includes the majority of the distribution, making updating a single component harder.
+External projects, like Mesa, which are used by AOSP, cannot be built separately as they need to be built for AOSP's libc. In cases like this, Google expects the project maintainers to keep their project compatible with AOSP's build system of choice.
+While supporting Blueprint could be advantageous for Replicant, due to its faster build times, selective recompilation when source files change on disk and ability to support multiple Android versions without convoluted conditional cases, it would be preferable if Android supported some form of packages similarly to GNU/Linux distributions.
+Adding and maintaining Blueprint support in all external software components can be incredibly time consuming and could even be unsustainable.
+The Replicant project, a fork of AOSP with software freedom in mind, wishes to discuss and ultimately decide on a sustainable way to go forward in regard to external software components.
+