[guardian-dev] The Android Build System Is Broken

Abel Luck abel at guardianproject.info
Sat Apr 13 10:02:06 EDT 2013


Found this today, though it was posted last July:
http://jakewharton.com/the-android-build-system-is-broken/

My thoughts derived from Sweat, Blood And Tears:

I've spent today and yesterday attempting to clean up and add all
Guardian Project projects to our automated build server.

Of course I'm also trying to keep things working with Eclipse.

Turns out these two goals seem to be in direct conflict.

I believe a project should be SIMPLE to setup;
          reducing the time-to-coding for new developers is crucial

I believe a project should explicitly specify its dependencies in
          its repo, so EVERYONE is using the same versions

I believe a project should be buildable from the command line with
          minimal setup. It should be reducible to one command ideally.

These are simple principles of software engineering I've learned leads
to elegant code and frictionless processes. The time and effort required
to go from 'git clone' to a functioning binary should be minimal
(assuming system level things like the SDK, eclipse installed, etc)

Eclipse, and Android (in particular ADT) seem to actively defy all these
principles.

Here are three simple rules I've been trying to implement to create
clean project repositories that are clearly specify dependencies and are
easy to setup and use by developers:

1. No eclipse files in git
2. All external dependencies defined as submodules in external/
3. .. unless they're jars, those go in libs/

A complex project repo sould look like this:

/  (git repo)
|- app/
|----- AndroidManifest.xml
|----- src/
|----- libs/
|----- etc..
|- external/
| --------- library1/ <--- submodules
| --------- library2/ <--- submodules
|- README

Broken Things and Process:

ADT's library project handling is totally broken
  example: http://s10.postimg.org/46r1uxe55/shittyadt.png
  Both those directories exist and are imported.

Whether it works or not, and how it breaks depends upon the order the
projects were added to the Eclipse workspace, except when it doesn't in
which case it just doesn't work.

If you get it working, god forbid you add another 3rd party library at
some point in the future.

---

Jar dependency conflict resolving sucks
...and by sucks I mean doesn't exist. If two dependencies depend on the
same jar, they better be exactly the same (as determined by a sha1sum)
or the project won't compile.

I realize this problem stems from a a limitation in Dalvik BUT the
consequence here is that it is common accepted practice to copy and
overwrite jars among all your submodules. WTF?!

(why are we shipping jars in the repo at all?)

---

Android "support" library should support the developer
Imagine if each Android project repo had to ship the SDK as well as its
own code. Crazy right? So, why does each project repo need to ship the
android support library? Why do I have to write a script like this?
https://gist.github.com/abeluck/5374457

The support library should be versioned. And, sorry, but when I have 10
different jars with "v4" in the name, v4 ceases to mean "version 4"

$ find ~/src -name android-support-v4.jar | while read jar; do sha1sum
$jar; done | awk '{print $1}' | sort |uniq | wc -l
10

*sigh*


More information about the Guardian-dev mailing list