Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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.
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.
*** Bug 44427 has been marked as a duplicate of this bug. ***
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.
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).