Bug 859 - Pre installed Android SDK not being detected.
Summary: Pre installed Android SDK not being detected.
Status: RESOLVED NOT_ON_ROADMAP
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Android Add-in ()
Version: unspecified
Hardware: PC Windows
: Normal normal
Target Milestone: ---
Assignee: Bugzilla
URL:
: 8034 ()
Depends on:
Blocks:
 
Reported: 2011-09-16 14:09 UTC by Punto QA tester
Modified: 2016-09-01 11:15 UTC (History)
11 users (show)

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


Attachments
Android SDK not being detected Windows 7 32bit (120.69 KB, image/png)
2011-09-16 14:09 UTC, Punto QA tester
Details


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:
Status:
RESOLVED NOT_ON_ROADMAP

Description Punto QA tester 2011-09-16 14:09:11 UTC
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.

OS: Windows
Versions: 7 32bit, 7 64 bit, Vista 64bit
Setup: Android SDK pre installed
JDK Version: 7
Visual Studio: 2010
Comment 1 Punto QA tester 2011-09-19 12:38:06 UTC
The same error replicates in Windows XP 64 bit with the Android SDK pre installed setup.

OS: Windows
Version: XP 64bit
Setup: Android SDK pre installed.
JDK Version: 7
Visual Studio: 2010
Comment 2 Jeffrey Stedfast 2011-11-15 12:37:59 UTC
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.
Comment 3 Jeffrey Stedfast 2012-02-15 16:44:32 UTC
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).
Comment 4 Itay Zandbank 2012-08-16 18:27:52 UTC
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.
Comment 5 Mikayla Hutchinson [MSFT] 2012-08-16 20:14:34 UTC
Itay, does bug 6490 match what you're seeing with the installer?
Comment 6 Itay Zandbank 2012-08-17 05:35:18 UTC
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.
Comment 7 Mikayla Hutchinson [MSFT] 2012-08-19 23:50:10 UTC
Sorry, I didn't see that bug was private. I've made it public, as it didn't need to be private.
Comment 8 Itay Zandbank 2012-08-20 00:56:01 UTC
No, it's not the same. I haven't tried running the installer twice, as it hasn't succeeded the first time.
Comment 9 Kevin McMahon 2012-10-16 16:45:25 UTC
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.
Comment 10 Jonathan Pryor 2012-10-16 22:29:40 UTC
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.

    http://stackoverflow.com/a/135697/83444

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:

    http://apple.stackexchange.com/a/57402

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.
Comment 11 Kevin McMahon 2012-10-16 22:53:32 UTC
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.
Comment 12 Jonathan Pryor 2012-10-16 23:09:20 UTC
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...
Comment 13 Marek Habersack 2012-10-17 06:15:39 UTC
(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 :)
Comment 14 Jonathan Pryor 2012-10-29 11:21:10 UTC
*** Bug 8034 has been marked as a duplicate of this bug. ***
Comment 15 Jonathan Pryor 2012-11-01 20:26:00 UTC
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
Comment 16 Miguel de Icaza [MSFT] 2013-05-13 15:37:16 UTC
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
Comment 17 Jon Benson 2014-01-31 21:33:19 UTC
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!
Comment 18 Jon Benson 2014-01-31 21:43:26 UTC
A possible workaround I found via:
http://delog.wordpress.com/2012/03/09/android-sdk-path/

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]
"Path"="D:\\Development\\Android\\sdk"

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.
Comment 19 Jeremy Kolb 2016-08-31 23:06:54 UTC
I HATE this when installing on a new computer.
Comment 20 Itay Zandbank 2016-09-01 06:31:29 UTC
Five years later and this bug still exists?! Wow, snappy response times!
Comment 21 Jeremy Kolb 2016-09-01 11:15:32 UTC
The workaround is to hack the registry before running the installer.