SDK Manager not Working in Windows
A change in the Android Software Development Kit (SDK) Tools that took place between release 16 and release 17 means that on some Windows configurations the Android SDK Manager (SDK Manager.exe) does not run outside of Eclipse, that issue is discussed in this article. Occasionally the SDK Manager does not work for other reasons, in which case one possible solution is to manually update the SDK tools as discussed at the end of the article Keeping the Android SDK Updated. However, if SDK Manager (and other Android utilities) worked prior to release 17 of the SDK tools then read on. The article also discusses why recent Android SDKs fail to install on a Windows 64-bit system.
(This article is now archived.)
Since release 17 of the Android SDK tools some Windows configurations will not run the Android SDK Manager program from the Android SDK Tools program group, although it can be run from within the Eclipse Integrated Development Environment (IDE). This problem can affect 64 bit versions of Windows and non-standard installations of Java and the Android SDK. The problem not only affects SDK Manager.exe but also running the Dalvik Debug Monitor out side of Eclispe (ddms.bat) and the Draw 9-patch utility (draw9patch.bat). Attempting to run these programs from a command console may result in a message similar to:
Failed to convert path to a short DOS path: C:\Windows\system32\java.exe
Followed by text requesting that Java needs to be installed from a Oracle Java download page, even though Java is correctly installed, is available from the Windows path and Eclipse runs without any issues. Running the SDK programs directly from Windows Explorer is unllikely to show the error message (the console window which opens to run the programs closes to quickly to see the error message).
Here it is assumed that Java and Eclipse have been installed correctly and are working, if not then ensure that Eclipse runs before installing or updating the Android Development Tools (ADT) plugin and the Android SDK, see Set Up Windows for Android Development. At the time of writing the Android SDK tools installer is at release 18 (note: a bug fix has updated the SDK tools to release 19, installed via the SDK Manager only. In other words release 18 needs to be installed and working before updating to release 19).
SDK Manager and other utilities prepare to execute by running commands in batch files on the Windows system. One of those batch files, find_java.bat, was changed for the Android Tools SDK release 17 (android-sdk_r17-windows.zip) and the same change is included in release 18 (android-sdk_r18-windows.zip). Until the issue is fixed in the standard release the problem can be resolved by replacing find_java.bat with the copy from the Android Tools release 16 (android-sdk_r16-windows.zip). Doing so will also allow the other utilities such as ddms.bat and draw9patch.bat to work.
If you have already upgraded the Android SDK Tools to version 17 or 18 then you may not have access to the release 16 files. In which case you can download a zipped copy of find_java.bat. Copy the contents of the downloaded zip file into the tools\lib folder on your Windows system where the android-sdk folder is located. Once in place SDK Manager.exe, ddms.bat and draw9patch.bat should run ok outside of Eclipse.
Another solution is to set an environment variable name JAVA_HOME. This will also need to be done if installing the SDK Tools using the program installer_r18-windows.exe from the Android SDK download site. Without the JAVA_HOME environment variable set the installer will display an error message.
To set the JAVA_HOME environment variable select System from Control Panel (via the Start button). Click on Advanced system settings under Control Panel Home on the left hand side. On the System Properties dialog the Advanced tab should be set, click the Environment Variables button. Under System variables click the New button. Enter JAVA_HOME in Variable name then enter the path to the Java JDK in Variable value (e.g. C:\Program Files\Java\jdk1.7.0 but may be different for your system). Click OK to close the dialogs. Setting JAVA_HOME also fixes the execution of the SDK Manager and other utilities without replacing find_java.bat in the tools\lib directory. Although setting JAVA_HOME is not mentioned on the Installing the SDK web page.
Elholios on April 17, 2012 at 9:22 am said: Thanks. Had some issues on Windows 7. Sorted now.
Sachin on April 27, 2012 at 6:19 am said: Thanks, I was experiencing the same problem. BTW, I had solved that, but forgot again. Anyways, good job.
Raja Nagendra Kumar on May 22, 2012 at 2:06 pm said: Fantastic. A simple JAVA_HOME issue.
KTH on October 23, 2012 at 2:24 pm said: Sometimes when I install Android SDK tools in my x64 notebook, I always find your post. Even today. Thanks. From Korea.
Abhishek Rathore on March 13, 2013 at 7:09 am said: I am getting the similar problem while using the command adb install -r \path of apk\ it is showing me something with the message like as protocol failure rm failed for /data/local/tmp/Test.apk, No such file or directory.
Tek Eye on March 13, 2013 at 11:47 am said: Not seen that error before so can only give you some suggestions:
- Ensure only one device is plugged into the computer.
- Reboot the computer to ensure ADB and Eclipse are reset.
- Perform a clean on the project in Eclipse (menu option Project then Clean).
- Try running from Eclipse.
- Make sure the directory in the error message does exist, if a temporary directory delete all the files except the one you are trying to install.
- Move the APK file to a single directory in a root folder and try install from there.
- If the device is from HTC stop HTC Sync, or stop any app that may trying to use the USB port.
- Ensure USB debugging is on (via device settings) and ADB can see the device (“adb devices” command).
- Remove the application from the device then try the command again without the -r option.
- If still not installing post a question on the Android section of Stack Overflow with detailed message outputs and screenshots.
Author:Daniel S. Fowler Published: Archived: