Update for Android Support Library, revision 25.1.0

[martijn00]

Revision 25.1.0 has been released: https://developer.android.com/topic/libraries/support-library/revisions.html

[Redth]

Already working on it ;)

[kjeremy]

@Redth Is there anything we can do to help out with the support library releases in the future? It looks like you've put in a bunch of work for the build environment recently. Clearly this project is not as simple as a typical Android Bindings project.

[Redth]

You're right, it's unfortunately not!

Right now we're going through some internal QA processes against the release, which is why there's no stable release yet.

The QA process on this release is made much more time consuming as we're also including and testing in this release some compile time improvements to how the libraries download their dependencies (so the .aar files from Google), and how those files get referenced by your project.

This is all being handled by a new package Xamarin.Build.Download which looks for information from other nuget packages' .targets files and handles the downloading/caching/extraction/merging of dependencies in a modular and reusable way.

This new download mechanism brings some big improvements.

1. It will first inspect your Android SDK home for the required dependencies, and use them from that location if they exist.
2. If the dependencies do not exist, it will download them, but instead of downloading some ~250mb .zip file, it is actually going to do a partial .zip download of only the bits of that file it needs using a HTTP range request. This means we now need to download ~10mb instead of ~250mb at build time.

You'll see we've added a partial-download-info.json file with a bunch of hashes, ranges, and offsets. This is what we use to generate the .targets files for each nuget package so that Xamarin.Build.Download knows what to do.

I've also been working to getting things compiling on Windows. One small tweak was utilizing MaxCpuCount in msbuild to speed things up on Windows. I'm not sure if we'll see the same gains on Android Support, but for Play Services, windows builds now take 1/4 of the time that they did before.

The next thing I need to work on is making the tooling for generating this file public (Xamarin.Build.Download will be open sourced too), and documenting the process for doing an end to end build of the nuget packages (this isn't so hard, you just need to run the right cake targets in sequence).

Finally, it's worth reiterating that for the most part, if you see a pre-release version of bindings, I would argue there is a perceivably small risk to using these packages in a stable environment. Bindings usually either compile and work, or they don't. The biggest risk with prerelease versions is some API changes which might cause your build to break until you change your use of them, and then maybe having to change back after we fix the regression in future versions. To this date I can only remember one (maybe 2) cases where the generated JNI code was actually broken in a binding. I guess my point is, pre-releases are basically feature complete bindings that haven't been 100% vetted for API regressions or gone through the full QA process.

Hope that brings some transparency to what we're working on! Feel free to ask any questions!

[Redth]

@kjeremy I guess to really answer your question of what you can do to help.

Use the pre-releases and report any API regressions or problems as github issues. I'll be starting to go through more of these open issues now and as the build process is more well documented you can definitely build locally, fix things, and send PR's :)

Unfortunately for new versions of things, at this point we'll have to start a branch with the basics in place.

[kjeremy]

Thanks for the detailed response. We appreciate the progress report.