Android 3.0 SDK Preview was released some days ago. I didn't have time play with it until just now.
In fact every time I upgrade the SDK, I was prompted this error:
A folder failed to be renamed or moved. On Windows this typically means that a program is using that folder (for example Windows Explorer.) Please close all running programs that may be locking the directory 'D:\Android\android-sdk-windows\tools' and try again.
Well, it's really ironic that the program locking that directory is the Java.exe started by the SDK Manager. I noticed this issue long ago but didn't able to find a fix. What I did for all my previous upgrade was:
- manually rename the tools folder to tools.old
- CD into the tools.old folder
- run the command: android.bat update sdk
This workaround did work, but just a bit troublesome. I am enough with this error message and wonder why the problem hasn't been fixed for so many releases. I can't be the only person encountering the problem, right?
Then I've found issue 4410 at the Android project. It seems that many other else were encountering the problem because of Anti-virus. Unfortunately it's the SDK Manager.exe in my case as said above. Luckily I spotted comment #67 and #73 which tell the real problem. The SDK Manager.exe actually runs tools\android.bat internally to for upgrading the SDK.
Looking into the file, you will know that the following code will be executed before upgrading SDK:
if "%1 %2"=="update sdk" goto StartUi
if not "%1"=="" goto EndTempCopy
echo [INFO] Starting Android SDK and AVD Manager
rem We're now going to create a temp dir to hold all the Jar files needed
rem to run the android tool, copy them in the temp dir and finally execute
rem from that path. We do this only when the launcher is run without
rem arguments, to display the SDK Updater UI. This allows the updater to
rem update the tools directory where the updater itself is located.
xcopy %swt_path% %tmp_dir%\%swt_path% /I /E /C /G /R /Y /Q > nul
copy /B /D /Y lib\androidprefs.jar %tmp_dir%\lib\ > nul
copy /B /D /Y lib\org.eclipse.* %tmp_dir%\lib\ > nul
copy /B /D /Y lib\sdk* %tmp_dir%\lib\ > nul
copy /B /D /Y lib\commons-compress* %tmp_dir%\lib\ > nul
rem jar_path and swt_path are relative to PWD so we don't need to adjust them, just change dirs.
Basically the script will create a temp directory containing the necessary JAR files for upgrading. This makes absolute sense as an approach avoiding file locking issues. However, there is a tiny little bugs here. Unlike *nix based OS, Windows get a drive scheme in which each drive is assigned a different letter (C:, D:, etc). The cd command just change the current directory without changing the drive for you. So, if didn't installed the SDK in C:, you probably will have problem here like I do. It is becase the %TEMP% environment variable is by default set to a folder under your home directory (or user profile folder in Windows language). Unless you or your administrator has configure explicitly, it should be at somewhere like i.e. C:\Documents and Settings\yourname or C:\Users\yourname. So if you have installed the Android SDK in any other drives than the one of your profile locates, the cd %tmp_dir% command will fail (yes, it still returns 0, but it's just not doing what it's supposed to do). As a result, the JAR files in the original SDK folder will be used instead of the temporary one - that's why the folder was locked and the upgrade failed.
Solution to this is to change the line (line #65) in android.bat to cd /d %tmp_dir%. Interestingly, from the online Android source repository, the issue has already been fixed. It might be the case that if you upgrade from previous version your android.bat was updated. So either fix it manually or have the whole SDK re-installed :)
BTW, there is another issue installing Honeycomb SDK:
Downloading SDK Platform Android Honeycomb Preview, revision 1http://dl-ssl.google.com/android/repository/android-3.0_pre_r01-linux.zip
The file seems to be removed by Google since this weekend (Jan 29), but why? You can join the discussion here. You can probably find someone sharing the file in the Internet, but you warned: Install from unofficial sources at your own risk.
Update @2011-02-01 03:46 GMT+8:
It's fixed! via @AndroidDev