Bug 42614 - Android Support Library: if build cancelled never works again
Summary: Android Support Library: if build cancelled never works again
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild ()
Version: 6.1.0 (C7)
Hardware: Macintosh Mac OS
: High major
Target Milestone: ---
Assignee: dean.ellis
: 44427 ()
Depends on:
Reported: 2016-07-16 21:27 UTC by Jason DeBoever
Modified: 2017-06-09 14:23 UTC (History)
7 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Jason DeBoever 2016-07-16 21:27:35 UTC
To reproduce you _Can Not_ already have the Android Support Libary Files in ~/.local/share/Xamarin (or Windows equivalent).

* Remove All Xamarin.Android.Support.* files from directory mentioned above.

* Add `Android Support Library` in Android SDK Manager (may require checking "Obsolete")

* Create a Xamarin.Android project and include some Xamarin.Android.Support.* references (through nuget if you like)

* Build Project
**  Since you do not have the support jars cached in the directory, they will have to be downloaded and they are large.  They will actually be downloaded as part of the build process (the user is not clearly aware of this and just thinks the build takes a long time, up to 20 minutes in fact)

* Cancel Build while Support Library jars are downloading.  (This is actually something users do _often_ since the build in this case takes _so very long_ )

This will cause the zip files to be corrupted. However, because they are present, the system will not attempt to download them again.  Anytime the user tries to build _ANY PROJECT_ that includes those support libraries, they will receive an error as the build will keep trying to unzip the corrupt files (it sees they are present and skips the download step).  

This _may_ also be an issue with other libraries of this type like the GooglePlayService.* libraries, but I haven't tested.

This appears to be a pretty common cause of users going through a "I deleted everything and re-installed and now it's working" type 'problem solving' based on a little non-scientific googling and experience with Xam U students.

I'm a little fuzzy on this part of the build process, and so it very well may be an Android bug, but if we could at least work around it somehow we'd have much happier android users.
Comment 1 bryan costanich 2016-07-26 20:37:39 UTC
Hey folks, this is a pretty important UX issue. We've seen it a ton in on-sites, and I ran into it myself. If it weren't for Jason, I would have been at a complete los as to how to solve it.
Comment 2 Nina 2016-10-25 21:56:25 UTC
*** Bug 44427 has been marked as a duplicate of this bug. ***
Comment 3 dean.ellis 2017-06-09 14:22:51 UTC
The download process has changed since that release. We and the component team now support partial downloads and resume. So we can recover from the previous partial download. 
we also look for files in the local sdk directory as well, which removes the need to download the files in the first place.
Comment 4 Jon Dick 2017-06-09 14:23:48 UTC
A bit more context:

In newer versions of the Android Support Library (and Google Play Serices / Firebase) we have started using a custom build task that ships as part of the Xamarin.Build.Download package (you can find the source for it here: https://github.com/xamarin/XamarinComponents/tree/master/Util/Xamarin.Build.Download )

This changes how the .aar files are downloaded by first checking to see if they are in the local SDK location, and if they are not, a HTTP Range request is used to download only the parts of the support library repository that are needed (which is usually only a few MB instead of 100's).