Question

Clarification:
My previous Android development environment has been a Win7 machine using command-line build tools with the MinGW bash shell that is installed with Git. I am trying to create a similar environment on an ancient WinXP machine.

Original Question:

I am setting up an old Windows XP machine for my Android development environment. (Yah, I know I wish I had the means to buy a new Win7 — or better yet Win8 — machine. I am making do with what I have for the moment.) My current problem is that when I run my ant -f build-android.xml debug I get the following error:

-dex:
      [dex] Found Deleted Target File
      [dex] Converting compiled files and external libraries into c:\devel\src\java\bbct\bin\classes.dex...
       [dx] ************ java_exe=
       [dx] The system cannot find the path specified.
       [dx]
       [dx] ERROR: No suitable Java found. In order to properly use the Android Developer
       [dx] Tools, you need a suitable version of Java JDK installed on your system.
       [dx] We recommend that you install the JDK version of JavaSE, available here:
       [dx]   http://www.oracle.com/technetwork/java/javase/downloads
       [dx]
       [dx] You can find the complete Android SDK requirements here:
       [dx]   http://developer.android.com/sdk/requirements.html
       [dx]

With a little detective work, I figured out that the -dex target runs ${android.platform.tools.dir}/dx${bat} which in turn runs ..\tools\lib\find_java.bat part of which is as follows:

rem Useful links:
rem Command-line reference:
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 1 if the exec failed (program not found).
for /f %%a in ('%~dps0\find_java.exe -s') do set java_exe=%%a
if not defined java_exe goto :CheckFailed

Running find_java.exe -s from the command-line gives

c:/PROGRA~1/Java/JDK16~1.0_3\bin\java.exe

which is the correct location of my JDK installation. However, when I add an echo statement between the for and if commands in the above batch script snippet, I can see that the java_exe variable is not set or is empty. I have successfully compiled my Android apps on a Win7 machine, so I believe the problem is that the for command above is incorrect for a WinXP environment. How do I change it in order to get it to work in WinXP? If the problem isn’t specific to WinXP, then what is wrong and how do I fix it?

Answer 1

Short Answer:

The short answer is that I think I found a bug in the WinXP command-line interpreter. At the very least, the behavior in Win7 differs from that of WinXP. I start with discussing and breaking down the cause of the problem. I will finish with a proposed fix to the find_java.bat script that comes with the Android SDK.

Long Answer:

The offending line is in fact the for loop from the find_java.bat script:

for /f %%a in ('%~dps0\find_java.exe -s') do set java_exe=%%a

According to the MS docs, the syntax that applies here is for a for loop used to iterate over file names:

for /F ["ParsingKeywords"] {%% | %}variable in (filenameset) do command [CommandLineOptions]

Let’s break this down:

• We are not using the the "ParsingKeywords"
• If this command is used in a batch script, then we need %% in front of the variable name. If we run it from the command-line, then only a single % is used.

• In our situation, '%~dps0\find_java.exe -s' describes the “filenameset”. This should evaluate to the output of running find_java.exe -s.

  • Running find_java.exe manually from the MinGW command-line on my WinXP machine gives correct output.

  • Next I modified the find_java.bat file as follows:

    • rem‘d out the @echo off command at the beginning. (This wasn’t shown in the OP.) This prints out each of the commands from the batch file as they execute.
    • Added an echo command to see the value of java_exe

    To run the modified find_java.bat file directly, I used the native WinXP cmd command-line. (I should also try this using the ant script in MinGW.) The relevant output was

    C:\Program Files\Android\android-sdk\tools\lib>for /F %a in ('C:\PROGRA~1\ANDROID\ANDROI~1\tools\lib\FIND_J~1\find_java.exe -s') do set java_exe=%a
    The system cannot find the path specified.
    
    C:\Program Files\Android\android-sdk\tools\lib>echo ************ java_exe=
    ************ java_exe=
    

    As you can see, java_exe is empty. I also found the path C:\PROGRA~1\ANDROID\ANDROI~1\tools\lib\FIND_J~1\find_java.exe a little bit strange; it should be C:\PROGRA~1\ANDROID\ANDROI~1\tools\lib\find_java.exe, instead. Further investigation shed some light on what is happening:

    • %0, %1, %2, etc. refer to the command-line arguments

    • The syntax %~[modifiers][#] provides some additional arguments about how to deal with the command-line argument. In particular, the values of the modifiers here include

      • d = Expand the drive letter
      • p = Expand the path name
      • s = Expand using short 8.3 DOS names

      The idea is that we want to run the find_java.exe executable which is in the same directory as the find_java.bat script where this code is located. %0 refers to the name of the batch script. Now for some reason, the WinXP command-line interpreter includes the batch script’s file name in this expansion, rather than just expanding the path where it is located. Since the path is incorrect, find_java.exe never executes and the java_exe variable is never set to a valid value. On the other hand, Win7 expands just the path of the batch script and everything runs just fine.

  • The command sets the value of the java_exe variable which is used later in another script.

Solution:
When I remove the s modifier from '%~dps0\find_java.exe -s' gives the path of the executing batch file without the file name. However, now there are possibly spaces and other special characters in the path. To fix this, I simply add double-quotes in appropriate places. The final for command looks like this:

for /f %%a in ('"%~dp0\find_java.exe" -s') do set java_exe=%%a

Since the behavior changes when removing the s modifier, I believe there is a bug in the WinXP command-line interpreter.