diff options
author | Raphael <raphael@google.com> | 2011-11-11 10:43:03 -0800 |
---|---|---|
committer | Raphael <raphael@google.com> | 2011-11-11 14:17:33 -0800 |
commit | 58fd50795e20449fcf880022a9debbbcb2357376 (patch) | |
tree | 65ea6454b88409756cd6837d478391f2d7add357 /files | |
parent | 560f2d0d14992389a367cbfef84b0e4a16796681 (diff) | |
download | sdk-58fd50795e20449fcf880022a9debbbcb2357376.zip sdk-58fd50795e20449fcf880022a9debbbcb2357376.tar.gz sdk-58fd50795e20449fcf880022a9debbbcb2357376.tar.bz2 |
SDK Manager Windows: detach from java process.
This fixes 2 issues:
- A bug in android.bat was that the bat+lib were
only copied if the arguments were 'update sdk'.
However since Tools R14 the sdkmanager doesn't
use these arguments anymore.
- Consequently when invoked as 'android sdk' it was
not copying itself in the temp folder and thus
was locking the tools folder, preventing updates.
- The new behavior is to always copy, like that we
don't care how the app is launched.
- The SDK Manager.exe was launching android.bat and
then waiting for it to finish, capturing its
stdout in care there's an error to display.
That locks SDK Manager.exe and thus prevent from
updating it too. So instead we just don't wait for
the bat to finish, don't capture/display its stdout.
If there's an error, the user can still use the
command line version to find out what's wrong.
SDK Bugs: 21212:SDK Setup.exe [keeps] an open file handle
SDK Bugs: 11989:SDK Manager.exe should be able to detach
(it doesn't do the part where the sdk manager could restart
itself after an update though. I'll file a different issue.)
Change-Id: Id473ce58d3f36d417b6c0ee5f07a039adbbe06c0
Diffstat (limited to 'files')
-rwxr-xr-x | files/find_java.bat | 26 |
1 files changed, 21 insertions, 5 deletions
diff --git a/files/find_java.bat b/files/find_java.bat index 13cb74c..db1f949 100755 --- a/files/find_java.bat +++ b/files/find_java.bat @@ -24,10 +24,13 @@ rem http://technet.microsoft.com/en-us/library/bb490890.aspx rem Check we have a valid Java.exe in the path. The return code will
rem be 0 if the command worked or 9009 if the exec failed (program not found).
rem Java itself will return 1 if the argument is not understood.
-set java_exe=java
+set java_exe=java.exe
+rem search it in the path and verify we can execute it
+for %%a in (%java_exe%) do set java_exe=%%~s$PATH:a
+if not exist %java_exe% goto SearchForJava
%java_exe% -version 2>nul
if ERRORLEVEL 1 goto SearchForJava
-goto :EOF
+goto :SearchJavaW
rem ---------------
@@ -49,7 +52,7 @@ echo Checking if Java is installed in %ProgramFiles%\Java. set java_exe=
for /D %%a in ( "%ProgramW6432%\Java\*" ) do call :TestJavaDir "%%a"
-if defined java_exe goto :EOF
+if defined java_exe goto :SearchJavaW
rem Check for the "default" 64-bit version if it's not the same path
:Check64
@@ -59,7 +62,7 @@ echo Checking if Java is installed in %ProgramW6432%\Java instead (64-bit). set java_exe=
for /D %%a in ( "%ProgramW6432%\Java\*" ) do call :TestJavaDir "%%a"
-if defined java_exe goto :EOF
+if defined java_exe goto :SearchJavaW
rem Check for the "default" 32-bit version if it's not the same path
:Check32
@@ -69,7 +72,7 @@ echo Checking if Java is installed in %ProgramFiles(x86)%\Java instead (32-bit). set java_exe=
for /D %%a in ( "%ProgramFiles(x86)%\Java\*" ) do call :TestJavaDir "%%a"
-if defined java_exe goto :EOF
+if defined java_exe goto :SearchJavaW
:CheckFailed
echo.
@@ -104,3 +107,16 @@ echo - Under Windows Vista or Windows 7, open Control Panel / System / Advanced echo At the end of the "Path" entry in "User variables", add the following:
echo ;%full_path%
echo.
+goto :EOF
+
+rem ---------------
+:SearchJavaW
+rem Called once java_exe has been set. Try to see if we can find a javaw
+rem to use. If not, we'll default to using java_exe.
+for %%a in (%java_exe%) do set p=%%~pa
+for %%a in (%java_exe%) do set n=%%~na
+for %%a in (%java_exe%) do set x=%%~xa
+set n=%n:java=javaw%
+set javaw_exe=%p%%n%%x%
+if not exist %javaw_exe% set javaw_exe=%java_exe%
+goto :EOF
|