Call for Help: making free software builds of the Android SDK



While we’re waiting for public access to the files, some info for the repository.

I just contacted by a Qt Creator user who couldn’t get it to use our SDK.
One issue is that it used both sdkmanager and did some manual checks for component versions; in particular it checked if build-tools/28.0.3 exists.
We ship build-tools under build-tools/android-9 - because that’s how the official build system generates it.
To avoid this, and also allow parallel installation with e.g. build-tools/28.0.1, I think we’ll have to repackage the generated repo .zips, unless somebody find the appropriate flag :slight_smile:

Also Qt Creator seemed to insist on using 28.0.3 and not 28.0.2 (the one we provide, last time I checked 28.0.3 wasn’t tagged anywhere at AOSP). It would help to know if Qt Creator just enforces using the latest version, or if this version is hard-coded somewhere.
Renaming the directory was enough to make it stop complaining though :wink:


maybe edit too, eg. 25.2.5 has this:




That wasn’t required by the Qt Creator configuration dialog, but that can help, yes.
Make sure you do that before running sdkmanager or update the locally-generated package.xml as well.


Doing my weekly reminder…
@hans any problem?


Sorry, I’m the bottleneck on too many things. Thanks for keeping on nagging. I was waiting for the details like the name and proper packaging and setup before setting up the official repo.

About the naming, I think sdkmanager renames the directory based on data in The official packages also have a base dir of android-9 for build-tools-28.0.3.

Have you tried doing a diffoscope run on your builds vs the original builds? That could be quite useful to see what the diffs are.


About the name, I think I like /android-free/ the best. It is close to Google’s name, which is just /android/, with the essential difference that these builds are actually free, while theirs are not.


Let’s go with android-free then. It would be good to start the repo so we can experiment with it.


works for me, I’ll set it up this week

This forum's notifications

Ok, it is setup:

I think we should follow the conventions of the Google repositories as much as possible. For example repository.xml should have the version number in it for the format that we are using, e.g. repository-12.xml And the dir structure should be the same. Otherwise, I think we’ll see weird issues, since a lot of the Android SDK was not designed to be decentralized and is quite brittle.

Here are some examples:

That also means naming the ZIP files the same, e.g. or

This forum's notifications

FYI, that rsync command is strict, as enforced on the server/remote side. That means if you run it with different options, it will fail. You can add these though for debugging: --verbose --progress The local path can be freely changed, but the remote path cannot.

This forum's notifications

Thanks a lot - I didn’t get notified so I only noticed today while about to complain :wink:
I’m merging a fresh rebuild (that includes the aforementioned build-tools-28.0.3 at last).
(give it some time to upload)

There seem to be another xml location for ‘samples’ and ‘sources’ packages, which I didn’t find.
Also I’m not sure if we should symlink e.g. repository.xml to repository-10.xml.

Is there a way to pass this repository URL to sdkmanager without recompiling it?


Added a new system image compiled during the night! seems important to locate the sys-img additional repository. Lots a naming conventions and lack of provider-oriented documentation makes it difficult to figure things out.

There’s a thing called “user defined sites” but I don’t think this’d work as we want to have priority over the default google repositories.

I don’t use this kind of tools so any help is appreciated :slight_smile: