I recently updated my installation of the Android SDK and ran into a problem that I’ve alway had on my current computer – the SDK Manager would not run after the update.
This is due to a Java path problem for a particular setup:
- a computer running 64-bit Windows (Windows 7 in my case)
- a computer with more than one disk drive installed
I also have Java 6 64-bit installed on the computer (not Java 7 as I use it for Android development).
Android SDK Manager – it no work
To re-iterate the issue: after installing or updating the Android SDK on a system with this setup, the SDK Manager may not be able run.
When trying to start the SDK Manager, in the ‘tools’ directory of the SDK installation, the batch file ‘android.bat’ is run. Inside the batch file it sets various path variables that point to libraries or to your Java installation that is required to run the SDK Manager.
This is where I run into problems.
One issue is this line in ‘android.bat’:
for /f %%a in ('%java_exe% -jar lib\archquery.jar') do set swt_path=lib\%%a
Here it is looking for the file ‘swt.jar’ which is located in the SDK installation under ‘tools\lib\x86’ or ‘tools\lib\x86_64’ depending on whether you are running a 64-bit system.
If you have only 1 drive in your system, then this should work. But if, like me, you have two drives then it may not work and the variable swt_path is not set.
Then there is this line where it tries to find Java:
call lib\find_java.bat
This runs the batch file ‘find_java.bat’ to set the variable ‘java_exe’ to point to the path of java.exe in your Java installation.
for /f %%a in ('%~dps0\find_java.exe -s') do set java_exe=%%a
Once again in my system this doesn’t work and the batch file can’t find my Java executables.
By the way when you try to do a build with Ant, it runs ‘platform-tools\dx.bat’ which also calls ‘find_java.bat’, so it runs into the same problem of not finding Java.
Why Does This Happen?
It seems this all has to do with the way Windows x64 handles the long and short format of file (and directory) names when working out paths.
Of course, this is for my particular setup. On your system it may all work fine – but you only have to do a quick google to see that many others have similar problems.
If you have this issue, then it’s worth checking for more common errors first, e.g.
- the appropriate version of Java is installed correctly
- JAVA_HOME and PATH environmental variables have been configured
Other Java Programs – GMote
I was recently reminded of all this when I was setting up my HTPC. This is a Windows 7 64-bit PC, once again with 2 drives (one for applications and the other for storing media files).
I was trying out GMote (an Android remote control app for playing media on a computer). This has a server component which runs on the computer and is a Java program.
After doing the default installation, I tried to run the GMote server and kept getting an error “Unable to load library ‘libvlc'”. After checking that the ‘libvlc’ library was in a folder in the PATH environmental variable, this error still kept occurring.
It took me a little while to find the problem with getting the GMote server to run:
- I had the 64 bit version of Java installed, so I installed the 32 bit Java and pointed the JAVA_HOME environmental variable to it.
- Since the path to the support library was under the default installation of GMote server at “C:\Program Files (x86)\…”, I re-installed the GMote server to another directory name that did not contain any spaces “C:\media\…”.
Finally it worked.
Why Two Drives?
At this point you might ask why do I have 2 drives on my computers?
I tend to install the system and application files on one drive, and data files on the other, I find this convenient for various reasons:
Backup – I can use different backup strategies on the different drives, e.g. do an disc image backup on the system and application drive and some other type of backup on the data that I want on the other drive. I also point the TEMP environmental variable to the data drive so that the temporary files don’t clog up my image backups.
Performance – Use a SSD for the operating system and applications disk for faster booting and app loading (Of course it would be nice to have a SSD for the data drive as well, but if you have a lot of data then this would be very expensive!).
The Moral of the Story …
So in this particular setup of trying to run Java programs on 64-bit Windows on a computer with multiple disk drives, I follow these guidelines:
- check which version of Java is required by your program (64-bit or 32-bit)
- check whether it requires the JDK or JRE
- install Java programs in a path that doesn’t have spaces in the directory names, as you might do on a UNIX or LINUX system
- point your JAVA_HOME environment to the appropriate Java installation (you can do this in a batch file before launching the Java program so that it is only local and doesn’t affect other Java apps)
So how did I resolve Android SDK issue on my system? If you google this issue, there are various suggestions as to how to fix it. These include things like digging into the Windows and Java internals, registry hacks, etc.
For me, I just took the easy route of editing android.bat to point the variables to the correct paths on my particular system. I know this is not the best way to deal with it, but after many frustrating hours of research, configuration and testing, I wanted to get things up and running quickly.
It’s a shame you have to waste so much time digging into Android issues to find the causes (and if you’re lucky, the solutions) of these problems. It’s not like running Windows x64 or having multiple drives on a computer is all that unusual.
But then the Android build tools have always been a bit flaky, so I guess it’s part of being an Android developer.