Google I/O 2011: 5 things to keep watching

From Chromebooks to Arduino to bots: Mike Loukides examines I/O's big themes.

All the robots …

More than anything else, I’ll remember the robots at <a href="

“>Google I/O 2011 — from the minuscule Arduino bots at the After Dark party to the massive PR2, a full-sized humanoid robot. Perhaps I’m biased because of my daughter’s participation in FIRST Robotics (go Apple Pi 2067), and perhaps it’s just because robots are among the coolest toys possible, but it was hard to avoid robotics. And the cute Hasbro Androids rolling around while balancing on two wheels were hard to resist.

PR2 robot
The PR2 robot at Google I/O 2011

But that’s getting ahead of the story. This was my fourth I/O. As I’ve come to expect, it’s a high-energy, exciting conference with a lot of first-rate technical content. The keynotes were less ambitious than the last two years, and with good reason. After all the excitement around Wave in 2009, Google has dropped it (though ideas from Wave are starting to reappear in other Google apps), and after wowing us with Google TV last year, that product is off to a slow start at best. So Google limited themselves to less ambitious announcements and demos — wisely, I think.

Android housekeeping

The keynotes started with a series of minor announcements that were necessary, and important to Android developers, but not particularly exciting. Google will be providing some tooling and library improvements that limit the problem of Android API fragmentation. Android has fragmented because it has succeeded, and to that extent I think whining about fragmentation is just that. Would you rather work on a fragmented platform with 100 million devices, or in a monoculture with a few hundred thousand? But tools to help developers deal with the problems of success are a no-brainer.

It’s also good to hear that Google has a plan to bring carriers in line about device upgrades. Getting carriers to upgrade devices promptly is a serious problem. I’m skeptical about whether Google has really solved the problem; network carriers can be awfully recalcitrant. We’ll see. Finally, it was good to hear that Android 3.1 (“Ice Cream Sandwich”) will be released as open-source code by the end of the year. I’m not terribly religious about open source, but it is A Good Thing, and Google’s reluctance to open source Honeycomb has been an unnecessary distraction.

Movies and music: OK, but unimpressive

Google’s movie rental service and Music Beta were OK, but unimpressive.

Google will have to go to some lengths to compete with Netflix for streaming movie rentals (though the ability to “pin” downloads for offline viewing is a nice feature). And while Google’s cloud capabilities are second to none, including Amazon, they really only supply cloud storage, streaming, and a more capable player. That would be enough if Amazon didn’t already offer a streaming music service for virtually any device, along with the ability to purchase music. Yes, I understand that Google is at a disadvantage; according to one engineer, they had the software ready a year ago, but have been unable to reach an agreement with the music labels.

Google Music BetaAmazon is risking being taken to court by the record labels, but they have one huge advantage that Google lacks: they already account for the lion’s share of CD sales. Google has to move forward with or without the labels, and the music industry may well decide to sit on the sidelines and pout about “theft” rather than build new business models that might actually work; but it still makes for a product that’s less than it could, and should, be.

The Accessory Development Kit is a big deal

The Accessory Development Kit (ADK) for Android was the most important announcement on the first day, if not of the entire conference. And yes, most of those robots wandering around were controlled by Android phones. The time is ripe for a wave of creativity around interfacing external devices to phones and tablets. It’s a game changer. A phone or a tablet can become a personal data collection device, a general control, whatever you can imagine. While I don’t use an exercise bike, using a phone to record and track your progress, save exercise programs, and so on, is a compelling application.

By choosing Arduino as the hardware platform for the ADK, Google has chosen to make Android hacking as easy as possible, as open as it can be. As Phil Torrone points out, there are already more than 300,000 Arduinos “in the wild”, and a corresponding number of developers already up to speed and ready to hack. I said a “wave of creativity,” but it’s not going to be a wave, it’s going to be a flood. Furthermore, the accessory API takes Android into territory that the iOS world is unlikely to explore. I cannot imagine Apple allowing an iOS attachment that is not Apple-branded.

Chromebook and developers

The second day’s keynotes focused on Chrome, ChromeOS, and Chromebooks. I never got one of last year’s experimental CR48 Chromebooks; the unit they’ll be sending to attendees later in the year sounds much more impressive. I find the Chromebook vision compelling, because it delivers on something I’ve long thought was necessary. I have several laptop, desktop, and tablet computers in my household (more than there are people), and I also take care of my mother’s computing needs (limited to email). All this hardware requires a lot of local management: backups, virus protection, software installation, updates, all the hassle that we’re all familiar with. In an ideal world, all of these tasks would be handled by professionals. I know few users, even the most sophisticated, who have adequate backups. I also know few users who haven’t lost photos, music, documents, whatever when a disk suddenly fails. I survived my last disk failure unscathed, thanks to Apple’s TimeMachine. But the answer isn’t better backup software and better backup devices, particularly when computing equipment is so mobile. The answer is to put these functions back where they belong: in a data center, managed by professionals. ChromeOS is very much the right vision.

Whether or not Google will succeed with ChromeOS is an open question. ChromeOS doesn’t look like an environment where you can write a whole lot of Java or C code and compile and install the results, so it isn’t immediately useful for developers. Google’s route to adoption runs through the software development community. If software development on a ChromeOS device is difficult (and I don’t just mean development for the device itself), Google will have an uphill battle, regardless of whether the device is a better fit for my mother.

Still, though, Google finds friends in unlikely places. If solid state disks don’t become a lot more reliable, if Apple persists in requiring developers to download a 4 GB XTools package from their store (the $5 charge isn’t a big deal, but the size of the download is), and if Google can build a cloud-based general-purpose software development environment, I can imagine a 4G-enabled Chromebook becoming the darling of the developer community. Light, with broadband wireless, USB and HDMI, and a (hypothetical) suite of software development tools: what’s not to like? Chromebooks could also be compelling as remote enterprise devices: bigger, easier to use, and less limiting than tablets, while much less expensive than Windows laptops. I don’t see the Chromebook as a “windows killer” any more than I think it’s an Apple killer. To challenge Microsoft, Google would need significantly more enterprise adoption for their cloud services. Currently Google apps are at best a tolerable replacement for Office. But again, it’s a possible future, and an intriguing one.

JavaScript is a first-class programming language

Of course, the importance of Chrome isn’t just ChromeOS. In keynotes and in sessions, Google demonstrated many improvements in HTML5 and JavaScript performance and features. While server-side software isn’t an important topic at I/O, it’s important that their V8 JavaScript engine is the enabling technology behind Node.js, which is now revolutionizing web development. With tools like V8, the Closure and Traceur compilers, and their involvement in the development of HTML5, Google has led the way in making JavaScript a first-class programming language, not just a bit of glue for web pages. I wouldn’t necessarily say that JavaScript is being used any more than it was, but if you’ve been watching, you’ve probably noticed that the way JavaScript is used has changed and matured in the last year.

A few more thoughts on I/O

I won’t say much about the giveaways beyond this: When a $400 conference ticket gets you $1,000 worth of hardware, conference registration turns into a feeding frenzy. Google has created a problem for themselves.

I do want to point to one important development that wasn’t represented. Just before the conference, Jacek Ambroziak released his eCarrel ebook reader in the Android store, for both tablets and phones. I’ve had an early version on my phone since February, and it’s by far the best reader I’ve seen. It was good on the phone, but reading a book on a cell phone is uncomfortable at best. On the tablets, eCarrel is a great experience. If readers are the killer app for tablets, eCarrel is a glimpse of the future.

All in all, I/O was exciting, if not as flashy as the past two years. Whether or not ChromeOS succeeds, it has the potential to bring “it just works” computing to a new level, and a class of users. The Android Accessory API takes the Android world into a new class of applications that could fundamentally change what we expect of our mobile devices. It’s a future that’s both more realistic than last year’s TV-based vision, and more radical.


  • Why Google Choosing Arduino Matters
  • Arduino is a building block for the world to come
  • Fun with RFID and NFC at Google I/O BootC
  • Android Controlled 3D Printed Slalombot
  • Why fragmentation is a good sign for Android
  • tags: , , ,
    • Phillipus

      JavaScript is a first-class programming language?

      You must be joking.

    • Mike

      Another thing to watch is the Chrome Developer Tools:


      People that still have that attitude are swiftly being overtaken by people that have listened to people like Doug Crockford ( and developing really great products and technologies based on the language. JavaScript is much more than you apparently think it is, and this is coming from someone that used to feel the same way.

      • I have to say that I’ve never been a Javascript fan, and almost wish I could take @phillipus’ side. But between Crockford and Flanagan, plus the developments in Node.js, etc., Javascript has become essential. Who was it that said “the only important programming languages are the ones people complain about?”

    • Mike

      Anybody that still has doubts about JavaScript should watch this video from Doug Crockford:

      JavaScript: The Good Parts

    • 1st a correction or two. You mentioned Android 3.1 as Ice Cream Sandwich (ICS). 3.1 is an update to Honeycomb that is getting out to devices imminently. ICS is the unified version between Honeycomb and Gingerbread which has been indicated as “2.4” unofficially though I wouldn’t be surprised if they jumped to “4.0” version number given the unifying nature of the release.

      >”Android has fragmented because it has succeeded, and to that extent I think whining about fragmentation is just that.”

      The biggest problem with “fragmentation” is that it’s an innocuous term, misused in the press (in general), and those organizations who actually have a hand in it seem to spin things in a way minimizing their culpability / involvement.

      What you are talking about is OS & device differentiation; not fragmentation at least from the definition I’ll now provide.

      Fragmentation is what happens when OS and device differentiation fails to honor standards and contracts of developer APIs.

      As a developer using Android since 1.0 when the G1 hit my hands in Oct ’08 and doing low level dev w/ OpenGL ES I can unequivocally vouch that fragmentation as per my definition exists and it being a problem for developers producing non-trivial apps & games that target the long tail of Android let alone the cutting edge. It was immediately apparent to me that the additive nature of the SDK would cause consternation, but it’s the bugs and breaking of developer APIs & contracts across OS releases mainly from Google and in some cases device specific fragmentation from OEMs / ODMs that is the real problem. Low level dev w/ Android & Java has practically seen a different major frag issue with each OS release. On last check 2.3 was the only one that didn’t cause problems for Java real time app / game dev.

      In the link you referenced I actually commented then on the big low level Froyo frag-bomb; Honeycomb notwithstanding I’m afraid has a big one too. 3.0 has a critical flaw for the Java NIO API that swaps byte order (that is little endian to big endian swap) that corrupts data of a NIO buffer. What is worse is that byte order is immutable for non ByteBuffer objects. For those that know Java the NIO API is a crucial performance API for OpenGL, any native binding, and it simply can’t be broken if non-trivial apps are to be made. Sun never messed it up and I doubt Oracle will, but Google did.

      “In short” code that works on desktop J2SE 1.4, 5.0, 6.0, 7.0, Android 1.0 – 2.3 breaks on Android 3.0. That is fragmentation and an onerous example as it took me 45 hours of my unpaid dev time to debug as when I got the LG G-Slate all I got was a blank screen when running my OpenGL apps. I had to debug from creating a GL context on up and this was absolutely no fun at all especially when my work runs on every other device I have OS 1.5+ including the G2x which also is a Tegra 2 SoC / same as G-Slate; the difference, the G2x runs Froyo!

      Now with such a critical flaw Google fixed it immediately the day I reported it which is great in general for the Android team as often bugs languish and don’t get looked at or resolved quickly (kudos to them!), but this shows the critical nature of such a problem that unfortunately somehow slipped by unit tests and onto every shipping Honeycomb device. Originally this fix was slated for Ice Cream Sandwich, but it appears it may have been promoted to 3.1 though I still seek info confirming that. It’s a critical fragmentation worthy example that clearly breaks the contract of crucial developer APIs, so I hope it does make 3.1 and as many devices get updated as possible. Low level buffer corruption by a faulty and immutable endian swap is stuff that just shouldn’t occur. I did however find a workaround for my extended NIO API / code, but that won’t help if all you got is a jar from an external company or open source project that is affected where one can’t change the code easily.

      Now it’s not just bugs in Android OS mediated by Google. ODM (original device manufacturer) fragmentation occurs too and that again is breaking developer contracts / APIs. This is _just_ pinging on my radar (3 hours old) and likely I’m going to have to pay $500 out of pocket to pick up the Xperia Play now as there apparently are issues with a broken contract surrounding the poorly documented and much maligned multitouch API; maligned from poor implementation to little to no documentation; the no documentation part could have alone been a source of this particular ODM fragmentation.

      Yep.. Comment is getting long. Fragmentation is alive and well with Android and is a problem. Low level devs are not whining we are exasperated especially from the financial burden at least for indie devs like myself! It’s a sore spot if you will, but there is hope.. :)

      OS and device differentiation is another matter though and there are sane ways to deal with it and it should be embraced and celebrated.

      For instance anyone complaining that X new device with a way better SoC / graphics processor enables better games they can’t play on their G1 is whining.. ;P Mike, once we are talking about the same thing I agree with you! :)

      “I’m skeptical about whether Google has really solved the problem.”

      I’ll “me too” that. Getting new releases out quicker and making it easier for carriers to get them OTA is certainly a good thing, but that doesn’t fix fragmentation as per my definition nor address fragmentation across the active ecosystem as a whole.

      As a disclaimer I’ve been working on a middleware SDK / platform that runs on top of J2SE & Android 1.5+ that fixes as many of the inherent frag problems / API contract breakages in each OS release in addition to custom handling for ODM frag issues for problem devices minimizing fragmentation for real time app & game devs; lets say I have intimate knowledge on the subject from Android 1.0 onward. Proper middleware seems to be the only solution as it provides a stable layer of software across the ecosystem that devs can write to and be more assured things work correctly without testing every device / OS combination. Release soon. It’s not a fun or easy problem to solve and quite costly from a device acquisition perspective.

      Hopefully this is received as more informative with recent examples of fragmentation and less “rantish”.. I sure am passionate on my fragmentation ;)

      Good post about the rest of I/O; I too look forward to the accessory development kit and that was great news, but the best news from my perspective is the enhanced USB support in 3.1 / ICS; particularly game controller / joystick support. The future is exciting for Android!

    • Mike

      Just wanted to add that this is also a great video to change your attitude about JavaScript:

      Google I/O 2011: Learning to Love JavaScript

    • Eddie

      Glad that Vic Gundotra this year didn’t do another amateur stunt like last year (implying Steve Jobs is Big Brother). Vic seems to be growing up.