Open Source Android Development Tools

184

Oh, I’m so sorry everyone! Some unexpected things happened and I ended up becoming too busy. I should have written something, but I kept telling myself I’d get it done “soon”. Time kept slipping… Thank you @Licaon_Kter for reopening this topic and keeping it open!

Anyway, here is the current build solution. It’s a minimal makefile-based approach, just enough to automate the process and make it easy to add more versions (with patches as necessary):

It is far from perfect, I need add a proper readme and also clean up some files a bit Also some versions might have gone out of date by now. @vdbhb59, I can probably send you some of the built files if you want. I’m not 100% sure on the final names for the sdk files yet, and for some ndk packages I have several formats of the same archives (alternatives to .zip: like tar.xz which is more compact… oddly different NDK versions will produce different such alternative archives for some reason).

Also, I made several attempts at building SDK 16. At one point I disabled SMT and reduced core count to 1, to see if the reduced number of jobs would help with the “Too many open files” error. But so far now success. I need to see if a newer version will solve this, or maybe I need to change OS.

1 Like
185

Mate, give me couple of weeks time please. I am stuck with so many things.

186

Of course, take all the time you need! I mean, I kept you waiting for 4 months (yikes!).

Besides, I should check if some of the versions should be updated, try rebuilding the sdk 16, figure out if the resulting file names are good, finish up a readme… so please don’t feel any hurry.

1 Like
187

Just some small updates:

I looked through the current NDK versions, and not much has changed. My current set of packages seem to cover the important versions (current version, lts and an older version supporting kitkat for my interest). But there is likely to be a new stable version released soon.

The SDK for android 15 similarly hasn’t changed: r36 is the latest revision. I did a small change to my scripts/makefiles to also export the repository.xml file that gets created. It might be useful if we want to host the packages so automated tools can access it? I did not find any similar repository.xml created when doing NDK builds.

For android 16 things are trickier. I had issues building r4, and there seem to be new revisions (I saw r5, r6 and r7 tag in some repos). However, I was unable to download the source for any of the more recent revisions: there seems to be certain repos missing the branches for these ones… If I recall, wasn’t google very slow and reluctant to release the sources for android 16? maybe it also included sdk 16 (I think both are tightly connected)?

However, some good news: I noticed Starfish had built the older r2 of sdk 16 and decided to try building it instead. It works! However, bad news: it seems now something else is causing the EULA to get included in some of the resulting packages. It was not enough to apply the same patches as before (adjusting prebuilts/sdk/tools/Android.bp prebuilts/sdk/renderscript/Android.bp). So some new module is now pulling it in. It might take some time to figure out what is causing this.

Given the new license issues, building issues, and unclear what revision is the current to focus on (and presumably going to change rapidly). Maybe it’s best to just leave 16 for now? It doesn’t feel mature and I don’t have the energy to go digging for the new causes of the EULA right now.

More Concerning: I found the following in the top level Android.bp for the prebuilt sdk (prebuilts/sdk/Android.bp, also in older versions, not just for sdk 16):

// *** THIS PACKAGE HAS SPECIAL LICENSING CONDITIONS.  PLEASE
//     CONSULT THE OWNERS AND opensource-licensing@google.com BEFORE
//     DEPENDING ON IT IN YOUR PROJECT. ***

This makes me feel very uneasy… it seems they are not just aware of the EULA attached, but seem confident claiming it applies. Do they have reason to believe this? Are there any restrictive licenses in some of the files we haven’t noticed? Or underlying sources despite seeming to be just Apache 2.0? Of course, the EULA is attached in some files (prebuilts/sdk/NOTICE, prebuilts/sdk/tools/darwin/bin/NOTICE.txt, prebuilts/sdk/tools/linux/bin/NOTICE.txt, prebuilts/sdk/tools/windows/bin/NOTICE.txt), but… that’s about it?

I am just waiting for nasty surprise to get uncovered that will ruin everything (like “hang on, instead of just apache 2.0 there’s a footnote in every android source file that also references the eula” or something). Or even if not, maybe they’re actually prepared threaten with lawsuits to stop this kind of efforts?

Tencent used to host a mirror of all these files (probably downloaded directly from google’s servers), and don’t any more. It is possible this was caused by legal pressure from google. I don’t worry about an actual lawsuit, more of the threat if they are in the right here. I’m just worried all work will end up being for nothing if there is legal basis for them to take it down. On the other hand @beuc’s Android Rebuilds never face any issues from what I know?

I’m tempted to try writing to that address and see if I get a response. I know @alaskalinuxuser already tried reaching out to some developers and never got any response.