Problem:
- Unable to open SDK Manager (Flashes only for a second)
- No build path target in Eclipse
Paths:
Android SDK: C:\Program Files\Android\android-sdk JDK used for android: C:\Program Files\Java\jdk1.7.0_04 (There are other JDKs also in dir Java)
Environment Variables:
ANDROID_SDK_HOME: C:\Program Files\Android\android-sdk JAVA_HOME: C:\Program Files\Java\jdk1.7.0_04;C:\Program Files (x86)\Java\jre1.6.0;C:\Program Files\Java\jre7; System Path: C:\Program Files\Java\jdk1.7.0_04\bin;C:\Program Files\Java\jdk1.7.0_01\bin;C:\Program Files (x86)\Java\jdk1.5.0\bin;C:\Program Files\Android\android-sdk\tools\
Errors:
SDK Manager on cmd Failed to execute tools\android.bat. The system cannot find the file specified Android.bat on cmd Unable to access jar file lib\archquery.jar Invalid path find_java on cmd nothing returned
I had a similar issue - I had to edit the android.bat ( and traceview.bat when I needed it)
in android.bat look for
for /f %%a in ('%java_exe% -jar %frameworkdir%archquery.jar') do set swt_path=%frameworkdir%%%a
replace with
set swt_path=lib\x86
YMMV, but in addition to editing android.bat, as described in the previous answer, I still couldn't get the SDK Manager to run on Windows 8 64-bit, until I first:
- uninstalled ALL versions of Java
- rebooted*
- installed ONLY the X86 JDK (including the Public JRE option in the installer)
I had tried all of these things and more previously *WITHOUT rebooting, and this was the only way I ever got the SDK Manager to run. Hopefully this info saves you from some of the utter frustration and wasted time I experienced. What a pain in the ass just to get the tools running out of the box. Awful experience.
I would have replied as a comment to the previous answer, but apparently I don't have enough rep to do that: https://meta.stackexchange.com/questions/25725/how-do-you-comment-on-a-specific-answer
EDIT: More complete answer below. (I don't think rebooting had anything to do with it.)
There appear to be several ways to launch the SDK Manager:
SDK Manager.exe in the root of the Android SDK.SDK Manager.exe in sdk\tools\lib of the Android SDK.Window -> Android SDK Manager menu in Eclipseandroid.bat in sdk\tools of the Android SDK.
In my case, it looks like android.bat fails on the line:
for /f %%a in ('%java_exe% -jar lib\archquery.jar') do set swt_path=lib\%%a
As far as what that line is doing... if I manually run: "[path_to_java]java" -jar lib\archquery.jar
It successfully returns: x86_64
But when the batch file runs that same command, I don't know why but it fails with the error message:
Unable to access jarfile lib\archquery.jar
So the variable swt_path gets set to an empty string. Everything breaks down from there.
The batch file sets the correct value for the variable java_exe. Others have commonly reported this as a problem, but those workarounds weren't relevant in my case.
People have recommended commenting out the problem line by adding REM to the beginning of it, and adding a line to manually set the swt_path variable, which is a valid workaround:
REM for /f %%a in ('%java_exe% -jar lib\archquery.jar') do set swt_path=lib\%%a set swt_path=lib\x86
BUT, the critical issue in my case is that it's choosing to load a jar file from either the lib\x86 or the lib\x86_64 folder here. At some point, things were getting confused between the BAT file error, a 32-bit JDK, and a 64-bit Android SDK.
SO, the workaround in my case was to:
- Uninstall ALL versions of Java
- Install the JDK
- You can either use the 32-bit Android SDK and install the 32-bit JDK
- Or use the 64-bit Android SDK and install the 64-bit JDK
- But the "bitness" of the JDK should match the Android SDK. It appears that either of the 32-bit or the 64-bit will work on a 64-bit computer, AS LONG AS the JDK bitness matches the Android SDK bitness.
Edit "android.bat"
If using the 32-bit Android SDK/JDK, use lib\x86:
REM for /f %%a in ('%java_exe% -jar lib\archquery.jar') do set swt_path=lib\%%a set swt_path=lib\x86
If using the 64-bit Android SDK/JDK, use lib\x86_64:
REM for /f %%a in ('%java_exe% -jar lib\archquery.jar') do set swt_path=lib\%%a set swt_path=lib\x86_64
After doing this, I can successfully run the SDK Manager by running android.bat, or from the Eclipse menu (but still not by running either of the SDK Manager.exe files directly).
On Windows 7, at least, a batch 'FOR' loop, when executing a command for the list, does not use the current working directory, but the root. In this case, the command is '%java_exe% -jar lib\archquery.jar'. However, it's effectively being run from the root, e.g. 'C:\'. You can see this for your self with this simple test from the command line:
for /f %a in ('CD') do echo %a
So the command to run archquery is looking for the jar relative to the root directory, not your ADT directory, and thus can't be found.
I had similar issue and this is how it is solved.
Open android.bat file from \android-sdk-windows\tools in an editor.
Find the line
for /f "delims=" %%a in ('"%java_exe%" -jar lib\archquery.jar') do set swt_path=lib\%%a
and add rem in front of this line.
In the next line add set swt_path=lib\x86 (if you are using a 32-bit system) or set swt_path=lib\x86_64 (if you are using a 64-bit system).
Save the file. Close the cmd if you have one open. Navigate to android-sdk-windows\tools\ and run android. This should open SDK manager. But be sure to have JAVA_HOME defined in your environment variables and should point to JDK home.
This change to android.bat (below) fixed the problem for me. I can launch the SDK manager from Eclipse now too.
for /f "delims=" %%a in ('"%java_exe%" -jar %~dp0\lib\archquery.jar') do set swt_path=lib\%%a
See What does %~dp0 mean, and how does it work?
I fixed that by replacing:
for /f "delims=" %%a in ('"%java_exe%" -jar lib\archquery.jar') do set swt_path=lib\%%a
with
REM for /f "delims=" %%a in ('"%java_exe%" -jar lib\archquery.jar') do set swt_path=lib\%%a set swt_path="lib\x86_64"
Note that i used " for the swt_path variable.
Hope that could help someone else.
Adding an environmental variable called "ANDROID_SWT" pointing to the directory that holds swt.jar got this to work for me. Seems like a better option then modifying the script.
