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.
Created attachment 401 [details]
Android SDK not being detected Windows 7 32bit
In the Windows 7 32bit, 7 64bit, Vista 64bit with Android SDK pre installed setup, Visual Studio and MonoDevelop are unable to find the Android SDK route.
Versions: 7 32bit, 7 64 bit, Vista 64bit
Setup: Android SDK pre installed
JDK Version: 7
Visual Studio: 2010
The same error replicates in Windows XP 64 bit with the Android SDK pre installed setup.
Version: XP 64bit
Setup: Android SDK pre installed.
JDK Version: 7
Visual Studio: 2010
I've had this problem in MacOSX as well (which sorta makes sense since there's no standard location to put the android sdk/etc).
Marking as High priority under the assumption that this is probably pretty important.
This is probably no longer a high priority issue since it is solved by the unified M4A installer (unless the user manually installs everything, I suppose).
This is still a problem.
The installer can't handle a preexisting Android SDK Tools setup on Windows 7 64-bits. It keeps complaining there's a missing "tools" component, although both the SDK tools and the platform tools folders exist, and the everything works great (Eclipse development is peachy).
When I say "keeps complaining" I mean "writes in the log file nobody sees" - that too should be changed.
Itay, does bug 6490 match what you're seeing with the installer?
Michael, I have no idea, I'm not authorized to see bug 6490.
Your support sent me a link to the Mono for Android MSI (not the big unified setup). I couldn't find that MSI when I was looking for it, all the links in your website point to the unified installation. You should put it in a very obvious place, that would save people a lot of grief.
Sorry, I didn't see that bug was private. I've made it public, as it didn't need to be private.
No, it's not the same. I haven't tried running the installer twice, as it hasn't succeeded the first time.
Would like the option to select SDK location or have the installer check for ANDROID_HOME being set and try to use that when installing on a Mac.
We talking about Windows or Mac?
The original bug report was about Windows. Windows has the added benefit that there's a .exe Android SDK installer which adds Registry entries; it is thus POSSIBLE to query the Registry to see if the SDK has been installed. (Install the Android SDK via the .zip, and of course all bets are off, as the Registry won't be updated.)
OS X is in the same boat as the .zip-based Windows installer: there's no "registry"-like mechanism. There are environment variables, but (1) said environment variables won't be automatically set by extracting the .zip, and (2) it's really painful to set a system-wide environment variable, especially without involving logging out and back in again.
Oh, and that's assuming that you can set system-wide environment variables that the installer can see; Mountain Lion removed the ~/.MacOSX/environment.plist support:
Consequently, I don't see how setting an ANDROID_HOME environment variable is going to help: ~no one will set it, and setting it will be annoying at best, painful at worst.
Furthermore, since exporting an ANDROID_HOME environment variable would require manual intervention ANYWAY, there's option #2: create a symlink from $HOME/Library/Developer/Xamarin/android-sdk-mac_x86 to your Android SDK directory. This likewise requires manual intervention, but it doesn't require attempting to set login-wide environment variables which are visible to GUI apps.
The only problem with this manual workaround is that it's completely undocumented (and untested! but it should work...) This is, admittedly, is a major problem with this option, but in the case of .zip-based installs, there are no good options.
You got me! I was being lazy and instead of creating a new bug report for the Mac platform I piggy-backed on this one.
Thanks for the detailed explanation. So what is wrong with asking the user if they'd like to specify a directory for the SDK instead of just automatically installing the stuff? If the user doesn't want to specify, go ahead and handle it the same way as now (which is nice). I get that you can't implicitly figure this out because of the reasons you enumerated but going this route seems a little heavy handed.
Thanks for the response and your time. Keep up the good work.
Alas, I'm not the unified-installer guy, so I don't know what the actual rationale is. I would guess that the reason is KISS (Keep It Stupid Simple) and to reduce apparent complexity. The downside is that this causes a considerable amount of extra data to be downloaded...
(In reply to comment #11)
> You got me! I was being lazy and instead of creating a new bug report for the
> Mac platform I piggy-backed on this one.
> Thanks for the detailed explanation. So what is wrong with asking the user if
> they'd like to specify a directory for the SDK instead of just automatically
> installing the stuff? If the user doesn't want to specify, go ahead and handle
> it the same way as now (which is nice). I get that you can't implicitly figure
> this out because of the reasons you enumerated but going this route seems a
> little heavy handed.
> Thanks for the response and your time. Keep up the good work.
We will change the installer to ask such questions at some point, but unfortunately it's not going to happen very soon. The rationale behind the current behavior is that the Google installer knows best where to put the SDK and we just follow its footsteps to add the components we need. Since it works for the vast majority of users we figured our time is better spent in other areas, for the time being :)
*** Bug 8034 has been marked as a duplicate of this bug. ***
Apparently we may not be detecting a previously installed Android SDK when the Android SDK .exe installer was used; see: http://forums.xamarin.com/discussion/comment/993#Comment_993
The other reason is that it is best to have a well-known configuration of the Android SDK than one that might be incomplete/not configured properly
That's a pretty poor excuse folks. We're developers, surely we're, mostly, smart enough to know where we've installed the SDK. If you need to check if certain things are installed, then do that, don't revert to having to do a full automated install to ensure it.
I have a development machine where the C drive has limited space. My SDK is therefore installed on my D drive.
Forcing me to install where you want, and forcing me to re-install something I've already downloaded, is pretty poor design IMHO.
If it's just a matter of coder hours to get it done I'm sure plenty of folks would volunteer.
I'm off to re-arrange applications that DO let me set their install location!
A possible workaround I found via:
Create the registry entry the installer is looking for and point it to your installation of the SDK:
[HKEY_LOCAL_MACHINE\SOFTWARE\Android SDK Tools]
Though I'm waiting on the other 1.29GB of downloads to know if it's worked it at least got me past that step in the installer.
I HATE this when installing on a new computer.
Five years later and this bug still exists?! Wow, snappy response times!
The workaround is to hack the registry before running the installer.