Nice to see activity has continued here. Unfortunately I have gotten quite sick since I last wrote and have not been able to work on this as much as I want.
@hans What you wrote makes me hopeful:
I hope this means that we are already done for the generated zips that do not contain the EULA (which is all of them, except for one). I don’t feel quite relieved here, but I do hope it’s that simple. One thing of note: one of the EULA’d prebuilts is a repo called “sdk”, which contains a bunch of jar-files, like conscrypt.jar. My worry is that they are used as-is (perhaps packaged inside the android.jar?), and then might “infect” the end results with the EULA terms. In fact, this “sdk” even contains several android.jar files, and I do hope the build process doesn’t just copy one of them directly…
But for the one zip with an EULA, “build tools”, I agree we can’t just pass it along to users and say “just ignore that EULA part”. I also think we need to be careful with removing the EULA, in case it does apply. The good part is that this specific zip can mostly be built independent from the SDK, as the work by debian (and not the least, by you yourself) has already demonstrated. If I recall, what remains outside of the already debian-provided programs is:
- r8/d8: this tool is more modern than the other build tools (like aapt, zipalign, …) and has its own repo, and a clean license. However, it also uses gradle to build, so I don’t know if it pulls in some badly licensed/EULA’d dependency.
- there’s a thing called “renderscript”. I don’t know anything about it, maybe it’s affected by the EULA. I read it’s deprecated, so in worst case (it’s affected by the EULA) maybe we can just throw it away.
@Legimet Neat. I had heard of zram, but never tried it. I just enabled another swap partition during my build. Not as pretty, and probably slower than zram, but it worked. I also saw very long build times, that’s just normal for the mess that is android. 
@alaskalinuxuser I have tried building a simple app using your SDK 14 (it’s the only version I had downloaded before vdbhb59 removed them). The good news is: the app worked perfectly fine!
This was only tested against an old 32 bit arm (kitkat) and a more modern 64 bit arm phone. I also only used the android.jar and d8, the rest (zipalign, aapt, apksigner and friends) was those provided by debian.
I know It’s not much. But it’s what I had energy to try, and at least this shows the result are truly usable and useful. When I get better I should try using all tools from your build. I also plan to install android x86 (32 bit and/or 64 bit) on an old eeepc to have a complete test of all targets.
Also this did not use your NDKs, since they don’t support kitkat (I didn’t have the energy to go through and change everything to a later api, and remember to change them back to my beloved kitkat afterwards). But I am very confident it will work, since (I think we agreed) it doesn’t actually recompile the binaries so there should be no real change.
Still, finding some way of building the NDK (at least the clang and utility binaries) from source is something I really hope we figure out.
@alaskalinuxuser update: today I had the energy to change all remaining build tools (aapt, apksigner and zipalign) I use for the app build. The resulting apk installed and ran without any problems, just like before. So to summarize: for me personally your rebuilt sdk zips are sufficient and will work for my project. And hopefully for other apps. Still remains to solve the legal issue, and hopefully rebuild the NDKs from source if possible. But at least, hopefully, make sure there’s older versions of the NDK with kitkat support.
I just want to document this while it’s clear in my head:
