Getting references to older ADT, SDK versions to prevent early migration

[Adam Vollmer]

We're currently working on a project which is building under the v16 of the SDK tools. We're bringing on another developer to work on this project, but we don't have a good way to point to the v16 instance of the ADT. Our best workaround is to take a copy of the SDK and Eclipse, and copy them over to the new developer's workstation. We could do some work to copy over only the relevant parts, but that involves making sure that we don't miss anything. Another problem is that, until we migrate to r17 or r18, we have to be careful to NOT upgrade our compile tools, or we'll end up having to do the same workaround of copying someone else's workspace over to revert that change.

I'm wondering if there's any support for allowing end users/developers to download older versions of the ADT/SDK, so that work can be performed on older build tools until the project is ready to migrate to newer tools?

[Eric Cloninger]

You can access those earlier projects by specifically referencing
their version numbers with the URL. For example,

http://dl.google.com/android/ADT-16.0.0.zip
http://dl.google.com/android/android-sdk_r16-windows.zip

Of course, it's not guaranteed to last, so if you're dependent upon
them, you should store them locally.

-E

[Xavier Ducrohet]

We currently don't officially support this. As Eric said, while the
files are available, they could be removed at any time.
In practice though we have very rarely removed those files and only
when they were really obsolete.

I think your scenario is one we have to be mindful of though, and we
have to think about how we ca support it.

Of course our first goal should really be to stop breaking everyone's
projects on every release *sigh*

--
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

[Raphaël Moll]

Also note that at this time the SDK Manager has no support for fetching older revisions and actually the xml manifest it uses doesn't even track them. So even if you manually install an older starter package like Eric said, you want to be careful not to try to install a new platform that will force a tools or platform-tools update. You could of course trivially figure the packages' URLs and wget/unzip them manually with the same "it's unsupported" caveat.

R/