Updates to the Android SDK

by Jason Chen » Fri, 04 Dec 2009 07:43:00 GMT


Sponsored Links
 Hey, folks.

Earlier today, we released updates to several different components in
the Android SDK. Xav announced these updates via the Android
Developers blog: 
 http://android-developers.blogspot.com/2009/12/android-sdk-updates.html. 
If you want to follow the blog via Twitter, you can now do so via
 http://twitter.com/androiddev. 

In addition to the new tools and platforms, there's one other
important change that I wanted to point out. We've added additional
clarification to the docs about android:maxSdkVersion and what effects
it might have on your app if you use it. You can see these details
here: 
 http://developer.android.com/guide/topics/manifest/uses-sdk-element.html #max

Best,

-Jason

--



Updates to the Android SDK

by adamphillips12 » Fri, 04 Dec 2009 14:35:14 GMT


 "The framework now correctly selects application resources in project
folders that use the API Level qualifier. For example, drawable-v4/ is
a folder of drawable resources for API Level 4 (or higher) devices.
This version matching did not work properly and has been fixed."

Did anyone realise this breaks all backwards compatibility on this
qualifier? It's the inverse of how it currently works and makes it a
terrible pain to now support 1.5 to 2.0.1

For someone to selectively target a single sdk that is not the most
current but support the sdks on other side of it, they now always have
to create layout/, layout-vX/, layout-vX+1/, with vX+1/ being nothing
but a duplication of resources in layout/, that are in both layout/
and vX/

If they wanted to selectively target two sdks, they have to create
layout/, layout-vX/, layout-vY/ AND layout-vY+1 again duplicating
resources now against layout/, vX and vY/

etc

While the old method, layout/ is simply your default catch all and you
single out specific sdks for specific resources with a simple layout-
vX.

I don't understand why this was ever classified as a bug, can someone
please explain the opposing logic to this. I would assume the purpose
of a API Level qualifier would be to selectively access specific sdks,
yet this change is the direct opposite of this usefulness, would it
not have been far more appropriate to keep the previous method in tact
but simply expand the functionality of the API Level qualifier to
accept ranges?







--


Sponsored Links


Updates to the Android SDK

by Sekhar » Fri, 04 Dec 2009 15:05:41 GMT


 I'm not able to update 1.6 r1 to 1.6 r2 in Eclipse on Windows, it's
throwing an error "A folder failed to be renamed or moved." Looks like
adb.exe that's running is preventing a move to temp. Anyone else
having this problem?




--



Updates to the Android SDK

by Mark Murphy » Fri, 04 Dec 2009 15:11:58 GMT


 > I'm not able to update 1.6 r1 to 1.6 r2 in Eclipse on Windows, it's

Run adb kill-server, or reboot, and try again. You probably have an adb
daemon process in memory that is tying up adb.exe.

-- 
Mark Murphy (a Commons Guy)
 http://commonsware.com 
Android App Developer Books:  http://commonsware.com/books.html 


--



Updates to the Android SDK

by blindfold » Fri, 04 Dec 2009 15:40:27 GMT


 Yes, I had exactly the same problem last night, with no apparent other
running program blocking the folder renaming. In the end I just quit
Eclipse and deleted the particular 1.6 r1 folder manually in Explorer
(Windows 7 64-bit), after which the update ran without problems.
(Before that, the update had failed both with the "$ android" method
and when launching Android SDK and AVD Manager from Eclipse |
Windows.)




--



Updates to the Android SDK

by blindfold » Fri, 04 Dec 2009 16:14:59 GMT


 Just had this renaming block again on another system, here running
Windows XP SP3. Quitting Eclipse, manually deleting the platforms
\android-1.6 folder, and relaunching Eclipse to run Android SDK and
AVD Manager from its Windows menu again fixed the problem. Looks like
there is something not quite right with the update package.





--



Updates to the Android SDK

by Dianne Hackborn » Fri, 04 Dec 2009 16:56:46 GMT


 



No it doesn't.



No, it fixes this bug that was in 2.0.



I think you are misunderstanding the change.  The change is to make it work
how it was actually documented, and not the horribly broken way it was
before.

-- 
Dianne Hackborn
Android framework engineer
hack...@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails.  All such
questions should be posted on public forums, where I and others can see and
answer them.

--



Updates to the Android SDK

by Sekhar » Sat, 05 Dec 2009 01:01:44 GMT


 Yeah, that was the first thing I tried (kill-server), but adb will get
started again automatically, so that doesn't help. I'd also tried
deleting adb.exe from tools\ in the hope it would'nt get started, but
then I can't even bring up the SDK/AVD manager to do the update. Also,
blindfold: deleting the platforms\android-1.6 is really not a solution
because you're just avoiding dealing with the 1.6 update. Bottom line,
I don't believe there's still a solution to updating from 1.6 r1 to
1.6 r2. This is on Vista 64 bit. Anyone?




--



Updates to the Android SDK

by Mark Murphy » Sat, 05 Dec 2009 01:06:20 GMT


 > Yeah, that was the first thing I tried (kill-server), but adb will get

Here's a procedure I used for grabbing the previous ADT update on Vista
32-bit, where $SDK is the directory you installed the SDK into:

1. Copied $SDK\tools to $SDK\snicklefritz

2. Changed the relevant environment variables (e.g., PATH) to point to
$SDK\snicklefritz instead of $SDK\tools

3. Started up the SDK/AVD Manager from the $SDK\snicklefritz copy

4. Ran the update

5. Changed the environment variables back to point to $SDK\tools

6. After confirming the new $SDK\tools seemed happy, deleted
$SDK\snicklefritz

That was for a slightly different problem than the one you're reporting,
so I'm not sure if this will actually help you, but I just like writing
"snicklefritz". ;-)

-- 
Mark Murphy (a Commons Guy)
 http://commonsware.com 
Android App Developer Books:  http://commonsware.com/books.html 


--



Updates to the Android SDK

by Sekhar » Sat, 05 Dec 2009 02:25:29 GMT


 Unfortunately, that won't work since the SDK/AVD manager will refer to
the its own stuff (platforms, etc.) regardless of how you start it.
I.e., you can't run the manager from one directory and have it refer
to the platforms in another directory. Looks like the install process
is basically broken and needs to be fixed by Google. Or I'm missing
something here (really hope that's the case).




--



Updates to the Android SDK

by Xavier Ducrohet » Sat, 05 Dec 2009 05:50:29 GMT


 adb isn't run from the 1.6 folder so that should have no impact.

If you're having problem, I would suggest updating to the tools r4 first (or
ADT 0.9.5) and then try 1.6_R2. The new SDK Manager is a better at dealing
with this.

Also, if you have an anti-virus you should temporarily disable it as it will
prevent installation by locking folder that needs to be removed.

Xav





>



Updates to the Android SDK

by Sekhar » Sat, 05 Dec 2009 06:42:06 GMT


 Well, if I check the file location for the adb.exe program in Task
Manager, it's showing as from the 1.6 r1 tools/ directory (I have the
SDK set as 1.6 r1 in Eclipse, that's it's launching that - if I change
to 1.5, it loads the adb.exe from 1.5 tools/, but that doesn't help).
And yes, I do have the tools at r4 already and I did disable antivirus
(AVG). But I'm just not able to get past the error. :(





> >



Updates to the Android SDK

by Raphael » Sat, 05 Dec 2009 07:11:05 GMT


 For all of those who have the issue of 1.6_r2 not installing under
Windows: that's because Eclipse is locking the folder. The solution is
to close Eclipse and run the $SDK\tools\android.bat script directly.
Then 1.6_r2 will install correctly.

HTH
R/

--



Updates to the Android SDK

by Sekhar » Sat, 05 Dec 2009 08:17:51 GMT


 Not working for me. The standalone manager won't connect to the SSL
url (https://dl-ssl.google.com/android/repository/repository.xml); and
if I make it http, it won't find compatible updates. This is really
frustrating, can't believe such a basic install issue managed to slip
through the cracks.




--



Updates to the Android SDK

by adamphillips12 » Sat, 05 Dec 2009 09:17:30 GMT


 Sorry Dianne, my reply was intended for public, hit Reply to author by
accident:

"It was documented like so "The SDK version supported by the device,
for example v3. The Android 1.0 SDK is v1,  the 1.1 SDK is v2, and the
1.5 SDK is v3.", if that was supposed to imply that a device supported
its most recent sdk version and perhaps older versions (in terms of
the resource system), then the documentation itself could probably
have been made more clear. All the wording and the examples suggest
the implication that a device has one and only one SDK version it
identifies with, e.g. 1.5 identifies only with v3, if not present it
uses default (given no other qualifiers), otherwise it would of read
"The SDK versions...", the 's' has quite some significance. Obviously
the new "or higher" clause can not follow this single SDK definition,
it is a behavioural change, not merely a fix of the documented
functionality."

--