Have you ever sat through a three-hour presentation? Has anyone ever even asked you to?

Well, yesterday morning my colleague Chris Stewart and I walked down to Google I/O and waited in line for the privilege of doing just that. No doubt you’ve seen a lot of talk about the many announcements they packed into this beast of a session. Thirty minutes into the Android portion, though, I was already leaning over to Chris and saying: “We’re going to have to write a blog post about this stuff.”

Oh, you didn’t see anything exciting? You weren’t looking with the right rose-colored shades on, then. As Android developers, we saw major movements in some fundamental problem areas within our ecosystem.

Doubling Down on Libraries

The first shift is more in what we conspicuously didn’t see yesterday: a new version of Android. And yet we got a bunch of new APIs! What’s up with that?

This is something I have been talking about more and more in my classes: these days, the version of Android you’re programming against matters very little. You can see this idea throughout our Android Programming Guide, too.

It was a slow process getting here, a process that started tentatively a couple of years back with the introduction of the support library, and continued with community acceptance of cross-version libraries like ActionBarSherlock. Slowly but surely, these libraries have become the focus of mainstream app development.

Well, now we have reached the point where Google actually prefers introducing new APIs outside of a minor version release. The new Maps API, the new Locations API (!), cross-platform single sign-on, games services, the new slider drawer in the support library—all of this, and no new version of Android. No doubt we’ll see more revisions of Android, but don’t be surprised if the exciting API and tools action happens elsewhere.

Nifty External Libraries

That has an interesting consequence: technically, third-party libraries are standing on the same ground as the latest hotness from Google itself. As a result, the Android ecosystem is shaping up to look more like the Ruby community than the iOS community, relying more on an array of third-party libraries than solely on code coming out of Mountain View. Even now, a baseline, best-practices Android app at square one includes a raft of third-party libraries like event buses and ABS.

The most interesting talk I saw yesterday was actually exactly that—a third-party library. Granted, it came from Google, but it is not part of the standard library. Volley is an asynchronous networking and caching library, meant to replace ad hoc solutions stitched together out of HttpClient, HttpURLConnection, AsyncTask, HandlerThread or others.

Can you write an app without a library like this? Yes, you can. Would you ever want to? Other unnamed platforms (ahem) include asynchronous magic like this as part of the core APIs. They’re not part of the core for us yet, but in our own practice we should treat them as close to fundamental.

So Long, Eclipse

I would not be surprised if the importance of third-party libraries motivated the most eye-catching bit of news we saw: Android Studio, the new IDE from the Android tools team.

Managing third-party libraries is not pleasant in Eclipse. Out of the box, there’s no declarative way of saying what your dependencies are and where to get them. Maven does this, but it does not integrate very well with Eclipse.

The headlines are calling this the “Android Studio IDE,” but don’t be fooled—this is more about moving away from Eclipse, and towards IntelliJ. IntelliJ handles maven better than Eclipse does right now, but it’s also free of the years of cruft Eclipse has accumulated.

It looks like this lack of cruft has allowed the Android team to move more quickly than they have in the past. So if Android Studio looks more like a dedicated Android IDE than ADT did, it will not be because the Android Tools team are suddenly more ambitious. It will be because they are able to get more done by extending IntelliJ than with Eclipse.

What Now?

So what do all these changes mean for you?

First, you should stay aware. So much development is happening outside of the core Android libraries that critical APIs are now coming from outside the core Android team and release cycle. So keep an eye on places like the Android Developers Blog, the Square blog, and #AndroidDev Weekly to find out about the latest and greatest goings on.

And what about Android Studio? Well, don’t jump just yet. As of today, everything in our Android Programming Guide is still the right way to go. Android Studio is 0.1, so it’s not stable enough for day-to-day development. If you want to go ahead and switch to IntelliJ, go ahead and switch to the current community edition with Android support, but don’t feel compelled to do so. Eclipse support hasn’t been discontinued.

As small as these developments seem to a user, they are very exciting to me as a developer. Developing Android is steadily growing into its own peculiarly pleasant experience. Maybe for our next edition of our guide, we’ll have to replace our cover photo with one of those self-balancing unicycles.