Unified Android SDK installer?
John McDonald
I was wondering about the feasibility/vision of producing a unified
installer to get developers bootstrapped for Android development from
a clean machine?
Ideally, this would automate all of the steps listed here:
http://developer.android.com/sdk/installing.html
This area currently feels like a heavy, manual process.
I'm convinced that a unified installer is technically feasible (I have
created one that basically sets you up with java, eclipse, the Android
SDK, an AVD for a 2.2 device, and the NDK), but am more wondering
about google's position on distributing such a beast?
Or is this something that is already on the google roadmap?
Thanks in advance,
John McDonald
Mark Murphy
> I'm convinced that a unified installer is technically feasible (I have
> created one that basically sets you up with java, eclipse, the Android
> SDK, an AVD for a 2.2 device, and the NDK), but am more wondering
> about google's position on distributing such a beast?
>
> Or is this something that is already on the google roadmap?
On a tangentially-related note, I am planning on distributing virtual
machine images with the same sorts of stuff in it, mostly for
situations like training classes where people need the tools
temporarily or otherwise are not willing to do a full install.
You did not mention what OS your installer was for. If it'll run on
Ubuntu, drop me a line off-list, as I would be happy to help with
testing your installer as part of my virtual machine work.
--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy
Xavier Ducrohet
We are very interested in making it easier to setup a computer for
Android development.
However I don't think we want to actually bundle things is a huge installer.
I would be more interested in smart downloader based on our SDK Updater.
I could see a light weight package that when launched drives you
through the install, downloads the packages that you want, and then
offers you to create an AVD, letting you choose which platform to base
it on.
There would be a standalone version (download tools, platforms, ndk,
add-ons, ...) for people not using Eclipse
For people using Eclipse I'd like to have a custom Eclipse distrib
that basically does the same on first launch.
The reasoning is that the SDK not a single component but several ones,
each of them released and updated on different schedule. Re-generating
a new installer with all in it would be too complex.
I'd rather have a simple installer that (almost) never changes
(basically only when our repository changes its schema or something
similar), and is basically not tied to our tools or platforms but can
download them.
While we would like to have this, we are not working actively on it,
and would be interested in contributions. See http://tools.android.com
Xav
--
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
Please do not send me questions directly. Thanks!
John McDonald
I think it's fine if the installer goes out and downloads things for you (rather than being xbox-huge to begin with), and I think it's also reasonable for it to be willing to install differing versions of the different components that go into the SDK.
However, for users who are new to Android development, I think it's somewhat daunting to basically have them fend for themselves in terms of which JDK they get, which version of eclipse (or if they even get eclipse), which version of the Android SDK, which version of the NDK, and so on and so forth. For one thing, they don't know what any of that stuff means--they just know that they want to get hello world up and running like it would run on the platform like they would with iOS development (or just vanilla PC development).
In the rendering universe, we refer to this as 'time to first triangle.' :)
Would you agree that there's value in an installer that effectively has 'gilded' versions of the tools, that have been verified to work together properly? I would happily also provide a path for the installer that effectively lets you go off the rails (to pickup other versions of tools and so on).
I think we could dedicate some time to this problem if we knew it was in agreement with Google's vision for where Android is headed.
Thanks in advance,
John McDonald
-McJohn
Haris Peco
Have you seen Android SDK Installer (and Android Sources) on
http://code.google.com/p/adt-addons/ ?
Regards,
Peco
Raphaël Moll
What Xavier meant is that we don't really want to have a "huge"
installer, instead it should be smart enough to download the required
bits so that we don't need to regenerate the installer each time we
update the SDK.
For the Android SDK packages, that's easy since there's a single URL
to check and code on how to do it is right there in sdklib and can be
adapted as needed.
The other more tricky parts are Eclipse and Java.
For Java you'd want to check for its presence and if not download the
installer and run it. That's a click-through license, so I don't think
you can silently install it.
For Eclipse, definitely you'd want to choose a given distrib and
install it more or less silently. There the issue of installing ADT
though that needs to be solved. An alternative that we considered a
while ago was creating a bundled version Eclipse with ADT already set;
however that meant maintaining 3 more binaries for each distrib.
The other thing is that we'd like this to be ideally on the 3
platforms we support (Windows, Mac and Linux) and dealing with 32 vs
64 bits.
Note that since Tools r8, we do expose a windows-only installer. It's
a crude repackaging of the tools r8 starter package wrapped in NSIS.
It's not optimal and I was hoping to replace it by some MSI-based
installer that would download the tools instead. I don't have any
experience with Mac or Linux installers though.
R/
John McDonald
The only issue I've had with just packaging up an eclipse directory that already had the ADT plugin installed was later specifying the location where the Android SDK was installed. I just haven't dug into this yet, though.
Also there are separate licenses that need to be agreed to when installing the ADT plugin, and I wasn't sure how to go about showing those (or even where in the ADT sources I would need to pull them from). To be honest, I haven't actually looked at the ADT licenses yet--like everyone else I pretty much just clicked accept and moved on.
To deal with the 32- and 64-bit issue, I gave up on supporting native 64-bit because some component (I don't remember which one now) was only available as 32-bit, and I was concerned about it interoperating improperly with 64-bit versions of other tools.
I do think that we'd like to provide an installer for each platform (Windows, Mac, Linux), but I don't want any one platform to hold up the others. And ideally, I think the installer should feel native for the platform it's running on (so an installer for windows, DMG for Mac and packages or scripts for linux).
I also used NSIS for my installer, it's so easy to setup. ;)
@Haris, I have not checked that out yet, but will.
Regards,
John McDonald
NVIDIA Corporation
--
-McJohn
József Király
I mean, you simply create an executable, what imitates an installer (selecting install locations, accepting licences), but at the end, it won't just install the stuff, but before it, download the matching content. This way, everyone is happy, as ONLY the asked components will be installed (like me, I don't need NDK), and partial update/upgrade is still possible. And do not forget, this installer would be able to replace all the messy installations ;)
Haris Peco
> the ADT plugin, and I wasn't sure how to go about showing those (or even
> where in the ADT sources I would need to pull them from). To be honest, I
> haven't actually looked at the ADT licenses yet--like everyone else I pretty
> much just clicked accept and moved on.
ADT plugin is released under the EPL v1.0 license. It contains
kxml*.jar which is under BSD license and groovy-all.jar which is under
BSD/Apache license.
You could look at
http://groups.google.com/group/android-contrib/browse_thread/thread/fcc2ad8ec9f34475/
and http://groups.google.com/group/android-contrib/browse_thread/thread/99293cd39f429cfc.
Peco