Because our expectations are low, we just retrigger like https://tbpl.mozilla.org/php/getParsedLog.php?id=33835106&tree=Mozilla-Inbound https://tbpl.mozilla.org/php/getParsedLog.php?id=33837463&tree=Mozilla-Inbound https://tbpl.mozilla.org/php/getParsedLog.php?id=33841267&tree=Mozilla-Inbound (that's the three times, so far, we've attempted to do a debug build on one push) all day long. That ain't right, and we should stick an export MOZ_DISABLE_PROGUARD=1 into http://mxr.mozilla.org/mozilla-central/source/mobile/android/config/mozconfigs/common until it can be made to actually, you know, *build*.

See Bug 946083.

More examples of Proguard choking on inconsistent sets of classes because of junk leftover in the object directory from prior builds, it seems. A clobber should fix such madness but, of course, is costly. (But maybe what you need to get this particular build through). Also sufficient would be deleting the classfiles from the object directory between builds (At the cost of around 10s per build). Perhaps this is a sensible alternative to disabling Proguard outright. Disabling it for a nontrivial period may lead to patches landing that don't properly annotate their entry points, causing the world to end immediately after you turn it on again. As you might know, there's a bug for solving the problem with less of a kludge this that RNewman seems to have mostly figured out - Bug 946083.

Yeah, the best short term solution is `make -C $objdir/mobile/android/base clean` prior to building.