On Monday, Google
Rubin, director of mobile platforms at Google, talked to CNET News.com about what Android phones will look like, whether they will compete with Apple's iPhone, and why the software took so long to build.
Q: What does Android look like?
Rubin: Google has stepped up on behalf of the alliance to do various components of the support from a developer community perspective. We have a user interface team continuing development on the UI, and there will actually be a replacement UI.
We've been building it as a mobile mashup platform. That is a new concept for cell phones. So the developer can now stand on the system platform and take advantage of other developers' work for the first time. So, that just creates more flexibility for the developers, less work, faster turnaround, rapid prototyping, and all that stuff, and we're really, really excited about that concept.
Q: Is there a prototype dubbed Dream? Who has it, and when are we going to see it?
Rubin: I actually don't know where that name come from. That's been an internal code name that's been kicked around here, but it changes quite constantly.
We have manufacturing partners in the alliance, and they're building products, and Google has been given some of those devices. As part of the SDK, there's a complete hardware emulator that runs on the PC. It runs on Mac, Windows, and Linux. It's literally a hardware emulator of various devices--you know, different screen formats: horizontal, landscape, or portrait and, with the QWERTY keyboard and without a QWERTY keyboard, with touch, without touch.
Q: But consumers won't see devices until next year, right?
Rubin: That's right.
Q: So, will there be a Google phone?
Rubin: I'm going to say "no comment" on that.
Q: Why did you pick Linux as the foundation for Android?
Rubin: One of the advantages of Linux is, it's a pretty prevalent operating system. The portion of Linux that we use for Android is just the kernel portion, and the benefit of kernel, of course, is that it's been already ported to all the varieties of semiconductors that run in cell phones.
Q: Why don't you join an existing Linux phone effort like the
Rubin: One of the key differences in
A lot of industry efforts just write specifications, and then they expect the rest of the industry to meet those specifications when they build their product.
Q: What were the design goals for the Android project? What do you want Android to do that can't be done with Symbian, Windows Mobile, OS X, Palm OS?
Rubin: Openness. The platform is completely open in a variety of ways. Of course it has open APIs, but it's also open source, and it being open source means it's (open to inspection). So expect to have the entire industry crawling all over the source base, trying to make sure that there aren't security issues, and there aren't inefficiencies in how the platform is designed.
Q: Who will do the technical support for Android?
Rubin: Within the alliance, there are five categories: semiconductor companies, OEMs (original equipment manufacturers), carriers, software companies, and commercialization partners. The commercialization partners will do the support.
Q: What's Google's business model for Android? Assuming that it's free to use, where is Google's return on investment?
Rubin: Google's mission is organize the world's information and make it universally accessible and relevant. This Android project satisfied the universal-access component of our mission. We need to make sure that on cell phones everywhere, consumers who carry them throughout their day have access to Google services.
Q: Does advertising play into this at all?
Rubin: There is no direct-advertising component in the platform. (But consumers will be able to) access advertising the same way you're doing on your desktop PC through the browser.
Q: Will the browser in Android be tied to the platform, or can I use any mobile browser I like?
Rubin: You can use any mobile browser you like.
Q: What were the primary development challenges for Android? Did you design it with high-end or mainstream hardware in mind, and what are the system requirements?
Rubin: When we built the system, we wanted it to be as flexible as possible. We did a lot of work to write our own library, and it's 250 kilobytes, not 3.4 megabytes.
We took a lot of those types of considerations when we were developing the platform. The platform is capable of running, as I said, on kind of mid- to lower-end devices as well.
We feel that one of the platform's distinguishing features is how it handles access to data. I talked about the mashups on the Internet and everything else. So, although the platform can run in a stripped-down fashion on mass-market phones, we think that the initial devices will be mid- to higher-end phones just because of the data access capabilities of the platform.
The minimal requirements are 32 megabytes of RAM, 32 megabytes of flash, and a 200-megahertz online processor. There are companies within the alliance working to bring that to even lower-power phones.
Q: Will there be different versions of Android devices where there will be a commonality, or a basic level of compatibility, that they all must maintain for applications to run on them?
Rubin: It's really important that we don't create a fragmented environment, and one of the complaints I think developers have with open source is that there is really no way to guarantee compatibility.
In the SDK, there is a scripting engine that allows remote test scripts to be run on the emulator on a phone. Also, there is a secondary compatibility (test for) support for services.
It's important for third-party developers to make sure that the applications run across different phones. There's not going to be a hard certification requirement. That doesn't make sense in an open environment. But we'll provide the tools necessary to make sure that these applications can be made compatible, if that's what the industry wants.
The platform itself has the ability to be targeted toward all sorts of different screen sizes and input mechanisms--touch devices, trackballs, five-way keypads, portrait displays, landscapes, big displays, small displays, QWERTY keyboards, non-QWERTY keyboards. When the developer writes an app, and that app is on portrait display, the platform also will run that same app on a landscape display.