Your Ad Here

Sunday, June 29, 2008

"Is this interesting to Google?" That's what Andy Rubin was asking Larry Page. It was a spring day in 2005, and the two were in a conference room just off the main lobby at Google's headquarters. A simple yes and Rubin would have walked away happy.

They had met three years before, when Rubin was about to launch a smartphone he'd invented called the Sidekick. At the time, Google was just an up-and-comer, trailing AOL and even Lycos in traffic. But Rubin, a well-known Silicon Valley player, chose Google as the Sidekick's default search engine. Page was flattered by the unexpected endorsement. So when Rubin called out of the blue and requested this meeting, well, Page couldn't say no.

The Google cofounder arrived late, as usual. Rubin walked to the whiteboard and began his pitch. There were nearly 700 million cell phones sold each year compared with fewer than 200 million PCs — and the gap was widening. Increasingly, he said, phones were the way people wanted to connect with each other and with everything else. Yet the mobile industry was stuck in the dark ages. Unlike the Web, where open standards had fostered a multitude of cool companies and applications, mobile was a tyrannical, closed system, repelling all innovators and disrupters who tried to gain entrance.

Rubin said his startup, called Android, had the solution: a free, open source mobile platform that any coder could write for and any handset maker could install. He would make his money by selling support for the system — security services, say, or email management. Android would have the spirit of Linux and the reach of Windows. It would be a global, open operating system for the wireless future.

Rubin didn't want money from Page. He already had funding. What he wanted was Google's imprimatur — even an email from Page would do. Rubin figured he could attract more VC funds with the search giant on board, possibly with a hint that Google might be interested in developing its own branded phone. He pulled out a prototype.

Page picked up the device. He had been personally frustrated yet fascinated by the mobile market for years. He already knew the numbers — he didn't need Rubin to tell him how many PCs and mobile phones were out there. He also knew that it added up to a massive problem for Google.

The desktop metaphor was fading. Phones were going to replace PCs as the main gateway to the Internet, and they were going to do it soon. Why would consumers tether themselves to a PC when phones were growing more and more powerful — and were cheaper, too?

But because cell phones ran on different software, had less memory, and operated under the constraints of pay-per-byte wireless networks, the mobile Web was a stripped-down, mimeographed version of the real thing. Reading and surfing and — more to the point — viewing Google ads was a slow, stultifying chore. Even worse, a second-class Web could derail Google's grand strategy. The company was trying to worm its way deeper into users' lives by hosting applications and personal files on Google servers, then dishing them out to the always-connected consumer whenever and wherever needed. That was easy on PCs, but phones didn't play nice with the cloud. Google dominated the Web today, but tomorrow might be a different story.

Working the problem had been a nightmare. Google engineers had a closet overflowing with mobile phones to test the company's wireless applications — mobile Google, Blogger, search over SMS. There were dozens of operating systems to navigate, a mobile Tower of Babel completely at odds with the easy access and universal language of the Web.

What worried Page most was that the only firm from the PC world that seemed to be successfully navigating the mobile labyrinth was Microsoft, one of Google's biggest rivals. The Windows Mobile platform had less than 10 percent of the US smartphone market, but it was growing fast. Microsoft's system, however, was the ugly stepsister of what Rubin was proposing: Redmond executives cared less about opening up the Net to mobile users than about tying the mobile operating system into its desktop dominance. A decade ago, Microsoft had underestimated the growth of the Web and then lost control of it to Google. Now it looked like it was Google's turn to be caught flat-footed.

If Google had it bad, users had it worse. Every year since 2002, the wireless sector managed to place at or near the top of the Better Business Bureau's tally of the most complained-about industries. Americans would rather do business with a used-car salesman or a collection agent than with a customer service rep for, say, T-Mobile or Motorola. And who could blame them? The plans were expensive, pricing was complex and capricious, and the phones never lived up to expectations. Constant innovation, the first principle of Page and Rubin's world, was anathema to phone companies. There had to be pent-up demand out there for something better.

So was Rubin's pitch interesting to Page? Absolutely. But he didn't want to stick his logo on Rubin's phone. Or write a supportive email. He had a better idea: Google would buy Android.

Rubin was floored. He had come in looking for an encouraging word and left with the biggest payday in his life. (The eventual purchase price was estimated at as much as $50 million.) Now all he had to do was live up to his own hype.

"Google's model is to build a killer app, then monetize it later," Rubin says. We're sitting in another conference room across the street from where he and Page struck their deal three years ago. The building, which houses Google's mobile division, is Rubin's domain now. There's a self-piloting model helicopter bearing an Android logo parked in the hall — Rubin builds them in his spare time. Beyond are floors of people who think of nothing but the cellular future of their employer. In the lobby, a flatscreen TV shows a spinning globe with animated flares erupting wherever people are using Google to search from their mobile phones. This fall, when the first Android phones hit the market, those flares will presumably flame even higher.

Rubin is tall and skinny and a casual dresser even by Google standards. He's 45 but seems younger. Sitting with one leg tucked beneath him, he explains the mission of the Googlefied Android to me, but I barely follow the words. I'm staring at his phone. It's clearly a demo — black, scuffed, covered with fingerprints; most of the face is taken up by the screen. Rubin absentmindedly slides it around the big wooden table, then picks it up and shifts it from hand to hand. It's maddening. All I want to do is get a closer look at his killer app.

After Google bought Android in July 2005, Silicon Valley pulsed with gossip and speculation about what the search giant was planning. Everyone figured Apple had a phone in the works and assumed Google must be developing one too. Rubin and his cofounders, Rich Miner, Nick Sears, and Chris White, weren't talking. "Trying to guess Google's next move recently replaced digging through Steve Jobs' garbage ... at the top of our weekend activities list," wrote tech blog Engadget. When Apple unveiled the iPhone last summer, expectations for a gPhone — could it be called anything else? — grew even more feverish.

But when Google finally broke its silence in early November, there was nothing about a gPhone. Instead, there was a press release. Thirty-four companies — firms like Texas Instruments, Intel, T-Mobile, and Sprint Nextel — were joining Google to build a wireless interface based on open source Linux software. The group dubbed itself the Open Handset Alliance. Competitors sighed in relief. This was how Google planned to shake up the nearly trillion-dollar global wireless market? A consortium?

"Their efforts are just some words on paper," remarked Steve Ballmer, CEO of Microsoft, at a conference in Japan. "Another Linux platform," shrugged the CEO of Symbian, the dominant smartphone operating system outside the US.

A week later, Google upped the ante. The company put a free Android software developer's kit on its Web site and announced the Developer Challenge, with $10 million in prize money to be parceled out to the creators of the best applications for the new system — a great social networking tool, say, or a handwriting recognition program. The Challenge was an open call; anyone was invited to take a shot.

Those hoping for a new gadget to rival the iPhone finally understood that Google had something radically different in mind. Apple's device was an end in itself — a self-contained, jewel-like masterpiece locked in a sleek protective shell. Android was a means, a seed intended to grow an entire new wireless family tree. Google was never in the hardware business. There would be no gPhone — instead, there would be hundreds of gPhones.

HTC, Motorola, and LG all announced plans to market new Android phones in a multitude of shapes and sizes, each with different software options. Android was a fully customizable system. Any application could be removed or swapped out for another. Even the few programs that Google was creating from scratch — an email app, a contacts manager — could be replaced with third-party software that did the same thing. Google didn't care how any individual model was pimped out as long as the hidden Android DNA was there underneath, keeping everything tied to the Internet and running smoothly.

As soon as programmers started playing with the emulator, they saw how big Google's ambitions were. The company was trying to make programming for a cell phone analogous to programming for a PC or the Web. Coders were told that their applications would have constant access to the Net, not the usual mobile hurry-up-and-wait feel. Working with the cloud — enabling programs to push or pull info to or from the Web — was a must. All Android phones would know where they were at all times, either by tapping into onboard GPS or by cross-referencing cell towers using a proprietary database owned by Google. And applications would be allowed to share information, which at the simplest level meant the kind of copy-and-paste functionality across all programs that cell phones currently lack.

Even better, at least in a developer's eyes, the Android team had violated an essential tenet of the wireless industry: that users are too dumb and dangerous to be trusted with downloadable software. Engineers who write for just about any mobile operating system today have to spend time and cash obtaining security keys and code-signing certificates. Android would allow any application to be installed and run, no questions asked.

Wednesday, June 25, 2008

Five Reasons Android Might Deliver Where iPhone Won’t

While the industry puzzles over when Android-supported phones will hit shelves, it is unclear what impact, if any, it will have against growing iPhone adoption.

Google-led Android doesn’t quite get the hype that Apple’s iPhone does, but there are plenty of reasons to get excited for it. For one, Android’s OS looks to offer a lot more than iPhone can with its latest release.

Here are five reasons to buy your loved one an Android-operated phone rather than an iPhone for Christmas:

1. It promises to run on most modern smart phones - More cell networks will support Android than iPhone does — the iPhone is bound to just AT&T. Mobile providers NTT DoCoMo, Sprint Nextel, T-Mobile and more have committed to the project. Also, more handsets will operate on it. You might even get more life out of your old phone if it supports it. Handset manufactures HTC, LG, Motorola and Samsung have already signed on.

2. It’s open-source software - Any programmer can whip up some code to match popular features from any other phone. Under the Apache license, any programmer can take the code and port their own version of the OS.

3. It has support for Google products out of the box - The latest Android demonstration displayed the phone’s compass prominently in Google Maps. You can bet Google will have the latest and greatest features of their software running on Android before it hits other operators.

4. Third-party developers have more access - iPhone prohibits people from using its internet capabilities for things like VoIP or an alternative browser. Android’s API allows you to create an application for anything, even the dialing software. The evidence is in the 50 applications already developed for the Android Developer Challenge last May.

5. Android allows for ‘unlocked’ phones - Most handsets in America, including the iPhone, are locked by software to a cell phone provider’s network. While there are various ways to jailbreak, it’s not easy and might break your terms of service. The availability of downloading and installing your own unlocked OS might just change the game in respect to shopping for mobile phone providers and signing contracts. If this method gets more popular, it is conceivable phone networks may drop the contracts in lieu of (better) European pre-pay pricing.

Apple proved when they launched the OS X powered iPhones, it isn’t just hardware that drives the killer mobile devices that change the industry. From what we can gather from Android, Google gets it too.

Friday, June 6, 2008

50 questions asked and answered on Android

From left to right: Andy Rubin, Brian Swetland, Dan Bornstein, San Mehat, Mike Cleron, Grace Kloba, Dave Bort, Steve Horowitz.

Q. Should we jump in to Android? What’s the guarantee that’s what I will see on a phone? Will service providers turn off things?

A. Keep in mind it hasn’t shipped yet, This is the most interesting time. Once it’s open source, it could be locked down… they could create a derivative work.

We’re going to provide a piece of technology that tests the APIs. No time frame yet. The script will exercise the system. It’s a compatibility test suite, to make sure nothing got disabled or broken by accident, and also ensure that apps will work across OEMs.

Q. What if my app uses location api, and service provider shuts that off, can they?
A. They can do that… it’s not a perfect world. Rather than having us dictate what carriers and OEMs support, we let developers develop killer apps that will require it.

We want to ensure all the application development that goes on for Android… we want to give OEMs an incentive to keep things open. It’s a positive, self fulfilling vision.

Q. If I’m a game developer and I’m building piece of content and I want to sell it, how do I do that and realize revenue.

A. Content distribution — we’ve thought of that. It’d be great if there were a place where people could go to safely download and pay for content.

Q. What about copy protection?
A. We wouldn’t have done our job if we didn’t consider distribution.

Q. (Question from Verizon). We use SMS interception for system signalling. Is there a mechanism for an app to respond and stop the signaling chain? Is there security around that so that one vendor can’t hijack a message and respond to it?
A. There’s a mechanism where an application can register to receive a message with a certain signature and prevent others from getting it.

We have a system of permissions apps are able to declare, enforce, and require to perform certain operations. Things like dial the phone, get to contacts, etc.. But these aren’t things that are baked in the core of the system. An arbitrary app could declare custom permissions.

As far as restricting another app, the model we’ve been going by… the phone is not controlled by the application vendor, it’s controlled by the user. Whether or not the permissions are granted is up to the user that owns the phone. If you created a protocol that intercepts an SMS and another party wrote an app that intercepts the same SMS and the user wants to use that, the user could be free to stick that in.

Q. Can the user set a priority?
A. Don’t know, post your question to the developer’s community board.

Q. (Question from Media Power Group). In a previous release, XMPP was turned into GTalk. Will a future version have XMPP?
A. Goal is to have XMPP support after 1.0.

Q. Java is more than a language. Google implemented its own VM. Could we use the Sun JVM? Explain the reasoning behind having your own.

A. We can have a more efficient interpreter and less memory pressure (by having Dalvik). You have to consider the holistic system performance. We had no choice but to run multiple VMs and processes. Share read-only memory across processes was important. Dalvik does that.

Also we needed something with an Apache license. At the time, nothing was available.

Q. Does Android support the Bluetooth serial port profile?
A. Yes.

Q. Can an application be started on powerup?
A. Yes.

Q. Is Bionic (Google’s version of libc) dynamic linked?
A. Yes, all libs are dynamically linked.

Q. Does Android have USB support? External keyboard, etc.?
A. The hardware should support it but it’s not enabled in the software. Maybe in a point release.

Q. (My question). What’s in the next version of the SDK?
A. No major suprises. We’re cleaning up APIs. Making sure things are named consistently, parameters all need to be there, etc. so there’s some churn. Ensuring what goes out is something we can support until the end of time. For example protected members might go package private so we have the option of changing later.

On the system side, we’re moving towards a tighter security policy. In M5 lots of things run as root, but in the next version almost nothing runs as root. We use the minimum privileges necessary.

What we demoed at the keynote had more apps and a different user interface but the changes are minimal.

Q. Will there be a central registry for intents?
A. That shoulds like a perfect opportunity for a 3rd party developer.

Intents use package naming conventions to prevent collisions, like

Q. Have any advice on general portability strategies; Android, Brew, etc.?
A. Emphasize the commonality between platforms, common profile support, separation between main logic and front end interface. Eventually somebody will add J2ME APIs into the Android platform. But at the user interface level you will want to tie into platform-specific things (for the best user experience).

Access to the web is standard across all platforms.

Q. Can I deploy Linux apps on real handsets? With a modified Qemu?
A. Qemu depends on OEM or carrier. It’s possible that upgrades may have to be signed by carrier.

As far as native code goes, we don’t currently have a bunch of the standard Unix X type stuff in there. Command line stuff compiles and runs as is. Expect that once this is open sourced, people will bolt on an X server and traditional Unix/Linux into the framework. While Java is the primary development language for Android 1.0, the system has been designed to support multiple platforms including native. Also expect the Android framework to run on top of other mobile Linux efforts.

Example: Web browser WebKit is C++ based, and there’s Java chrome on top of that. For debugging I use gdb server to debug native code. JNI layer talks between C++ and Java.

Q. (From Is the magnifier widget shown in the opening session specific to the browser or can I use it in my apps?
A. That one is specific to browser. It’s implemented in the native part of browser.

Q. Gears will eventually be supported on Android. Can we expect that in 1.0?
A. It’s under investigation. Can’t guarantee on 1.0 but we’d like to have it there.

Q. Do you plan to support an extension mechanism like plug-ins? For example secure web site user certificate storage is not supported, and there is no mechanism to add it.
A. We don’t have the full plug-in support. Partial MPPI support… we’re still working on it. Probably not finished by 1.0.

Note we do have the HTTPS support now.

Q. (From Tivo). Is there info on the UI toolkit, animation effects, composition, effects, and what is it based on?
A. We have a couple different approaches to drawing. We have full support for OpenGL ES, and use hardware support if it’s there. For more conventional UI, apps use the View system documented in the SDK. This sits on top of a graphics layer, Canvas SGL.

Q. Does Android compete with JavaFX Mobile?
A. The world doesn’t need another operating system. The world needs an open embedded operating system, open source. (Andy:) I haven’t seen anything that encompasses as much as Android.

Q. We do social apps. We have Javascript expertise but not Java. Is there an API running on localhost to fetch geo locations?
A. There’s a browser and a web view. If you want to write local . If you use the embedded web view you can have Java binding. Javascript calls Java in embedding app. You get your own icon, your own storage, your own world in which to operate.

Q. (From an Android software company). Will there be any Android developer events in India?
A. That makes sense but I’m not sure if any are planned right now.

Q. If a small device manufufacturer wants to run Android, can they just download it and go?

A. Once it’s open source, anyone can download and port Android without joining OHA. Android will be open source before the end of the year.

Q. (From 7 networks mobile messaging software). Can you comment on power management features? How can developers extend battery life?
A. At the kernel level, it goes into low power states even when running. Android supports wake locks. Does it at the platform level so apps don’t have to request that from the kernel. We’re trying to be smart about it. For example, a network event wakes up system, but may not even wake up the screen.

There are two classes of timers - real time timers that can trigger even when device is asleep (like alarms), and free-running timers that only run when device is awake. We’re also working on some visibility to the user, so they can tell what apps are contributing to the device being awake. We’re hoping to set some good examples with core apps, and also provide a way for the end user to see what’s keeping their device awake and be able to uninstall badly behaved apps. Similar to finding out what’s using storage space or CPU time.

Q. We’re working on seamless mobility between cell and wifi calls. Can apps trigger WiFi scanning? Search for SSIDs?
A. WiFi support, we’ve been adding. There’s the connection manager that can see SSIDs, associate, and it supports a number of authentication schemes.

Q. Can a 3rd party application initiate a WiFi scan?
A. Yes, if it has permission.

Q. I want to use native phone dialer to make voip calls, can I do that?
A. We already have hooks for that. System sends an intent, which can be intercepted.

Q. Can I intercept incoming calls too?
A. Not sure, there are security issues.

Q. A VoIP app wants to route audio to earpiece. Normally apps don’t use earpiece. Possible?
A. Post to forum or bug request. The system can do audio routing but I don’t know if it’s been exposed to top level APIs.

Q. Can apps get extra GPS data beyond latitude/longitude?
A. Don’t know if you can get access to the NEMA channel. With M5 we didn’t have full integration but the new version will have more. There’s no reason not to expose it.

Q. What is Android’s business model?
A. Somebody could rip out the Google stuff and put in Yahoo stuff. That’s ok. Our job is to continue to create killer apps that people will want to use. Google search, GMail, maps, etc.. If we ever fail to delight users our core business will go away. That’s why we felt comfortable using the Apache license.

While we’re showing demos with Google applications, but there is no requirement to use them.

Q. (From a mobile linux startup). I’m concerned about giving user complete control over permissions. Won’t users just accept permission dialogs without thinking?
A. Providing a useful security UI is something nobody has done well. We recognize that as a crucial component since we delegated the decisions to the user. We’re working to come up with something better. The #1 goal is to come up with something that provides real security for the user. One way is to educate users, to call things out.

Also we can provide info upstream about what are good and trusted applications that a community has validated as being ok.

There will be a circle of trust, communicating what other users are doing. One star vs. five star ratings.

Q. On application signing, I can’t find any tools?
A. These will be provided. Before last SDK went out it wasn’t implemented yet. Tools for signing will be built into the developer plug-in. Note: Applications will be self signed, no chain back to root certificate.

Q. How synchronous are we going to be able to get with Android?
A. We have an http stack, and you can build whatever you want on top of that. We’re not providing a general sync service.

We have sockets. At some level, 1.0 doesn’t have a general synchronization API, but there is nothing to prevent you from building an app that uses a server to talk to other instances of itself or other apps. Given limitations of network of course. For example GPRS is effectively NAT’d.

Latency is on the order of 200-400ms for a GPRS network; UTMS is getting Latency is on the order of 200-400ms for a GPRS network; UTMS is getting less than 100ms.

Q. Will Android support data from router/WiFi?
A. Yes. It’s not fully enabled in 1.0 but you can even use bluetooth as an interface (ethernet over bluetooth). Ethernet over USB too, on Linux it works great, but some driver work is needed for Windows and OSX.

Q. Can you make telephone calls over bluetooth or WiFi?
A. For VoIP, all you need is an application to do that, it’s just sockets. (Somebody please write that up) (laughs).

Q. If app is self signed, can I use GPS on a real carrier like Sprint?
A. By default, there is no central certifcation authority, so you don’t have to go thru Verisign. Permissions are not based on certificates, they’re based on what the user has chosen to give to that application.

The only thing certs are used for… if two apps are signed by the same key, then they presumably came from the same place. We use that to allow apps to work more closely, for example live in the same process. Apk’s from the same key can share a process and userid. Also we test it to allow you to upgrade an app because it must be from same source. We don’t have to ask the permission questions again (unless the set requested has changed).

Q. Can the carrier stop this?
A. It’s open source, so anybody can do what they want with it. We’re trying to make this open not just source but user control. We’re leading by example, showing it’s ok to do this stuff. Let’s show all the dangers others are trying to avoid don’t really exist.

Signing is to protect the end user. I can’t ship a v2.0 of your app and hijack your users.

“Trust the user” is one of the 10 things Google takes to be true. Give the user enough info to make good informed decisions.

Q. Any details on next round of the Android developer’s challenge?
A. For part 2… we don’t have a lot of details. It will be the other half of the $10 million, and will be after devices are on the market.

Probably early next year. (heads nod)

Q. (Andrew from MIT). We need x.519 personal and root certificates. This relates to updates once software goes out; finger pointing not to be able to push out updates to end user.
A. We don’t want to dictate to OEMs how they upgrade. Parts of the industry makes money in different ways. The technology can receive over the air and over USB updates.

Android has the ability to do very targeted updates to a running system, but also it has the ability to replace the entire world. We don’t require it but we have OTA on the entire system or it can change 1 byte in 1 file. OTA updates will be signed by a real private key unless the OEM wants to make it possible to do it unsigned.

There are 4 different types of updates: patching, complete system partition, baseband radio, and applications OTA.

Q. (Alexi from Java Fusion). Which tools will developers have to handle memory leaks, gc, profiling, etc..
A. We have a lot of hooks for debugging on the device. If you’ve seen the emulator, you can run your favorite IDE with that. It’s connected over a socket transport, and can be turned into using USB transport. The tools worked on real hardware first, and then on the emulator. We make it just as easy if not easier to debug the device itself. We encourage development on a real device.

One developer mentioned traceview, a graphic profiling tool.

We run a VM in each process. You target the debugger at a particular Java process, but you can get an overview at what other processors are doing.

Another developer mentioned he uses GDB every day for native code debugging.

One tool not in the SDK yet will give you a live dump of the views, and let you inspect the view hierarchy and the state of all the views.

Q. (From Boston university). Will Android have UMA support?
A. The platform can’t depend on it but OEMs and carriers are working on it. UMA is based on SIP, handles the handoff from cell to WiFi.

Q. Regarding OTA updates, what tools are available for the application developer to ensure the user has the right version of the platform?
A. Compatability is very important. It’s not done right now but it’s a crucial component. We have tools in place to track changes, version differences.

Q. Can application developers deploy and patch their programs?
A. Distribution is one of the most important needs to support 3rd party developers. Can’t say more strongly how important it is but we have nothing to announce right now.

Q. Can you have incoming commands from server?
A. You can have active connection without a power drain, waiting on data. Android devices are designed to be always-on devices, always have an IP address.

Q. Will GTalk and XMPP be supported in 1.0?
A. Post 1.0.

Q. How do we get Android on our platform?
A. Easiest thing would be to wait until we open source it. We’re not encouraging violation of the early view SDK.

Q. Apple says iPhone will sell 10mil by the end of year (2008). What are the projections on Android?

A. We can’t predict the future. We’re an open source software project, we’re not a phone. A lot of OEMs can build a lot of phones on that. We felt the industry needed a cross-OEM standard operating system.

A long term goal is to put Android on set top boxes, car navigation system, sensors, etc..

There are 1.2 billion internet connected PCs, and 3.2 billion phones.

Open source eliminates the barrier to entry. It reduces the cost of phones by 20%.

.. from here

Wednesday, June 4, 2008

Jason Chen answers questions about Android

At the recent Google I/O 2008 conference, Jason Chen from the Android team presented a 90 minute introduction to Google’s new software platform for mobile devices.

All the source code to Android is currently available to Google’s Open Handset Alliance (OHA) partners. The general public will gain access to the source code when the first handset ships. At that time, Android will be called “version 1.0″.

Once version 1.0 comes out and the source is available, anyone in the world will be able to download and port Android to any phone (or other device) they want. This question came up several times during the conference so it bears repeating: You don’t have to be an OHA member and you don’t have to sign anything or ask anyone’s permission to put Android on a new phone. But you do have to wait until version 1.0 is released.

And when will that be? Google would not give any specific dates other than “the 2nd half of 2008″. When pressed, a Google source said it wasn’t really their call alone. The release date is largely up to OHA members, especially the manufacturers making the phones and the carriers who will sell and distribute them.

After his presentation, Jason opened up the floor for questions…

Q. What if somebody wants to build an application that is similar to a Java Virtual Machine (JVM) that can run other programs. What security implications are there for these kinds of applications?
A. It’s possible to do but we haven’t thought about it. There is a large security team working on Android. There are languages that are working to port their bytecode to the Dalvik VM, so it won’t just be for the Java language.

Q. Traditionally carriers rip out things. What steps do you take to prevent somebody like Cingular from making an “almost-Android” phone?
A. They could do that if they wanted because it’s open source. But Android is a complete stack of software so why would you want to break it? There’s value in a full stack and in a lot of applications. There’s no incentive to alter it in ways that wouldn’t be compatible. We want manufacturers and operators to customize in ways they can differentiate. They don’t all have to have the same home screen, the same look and feel, and so forth but they should be able to run any Android apps.

Q. When do developers get hardware?
A. When everybody else does (when retail phones are for sale).

Q. Does Android platform development follow the JSR (Java Specification Request) model?
A. Android is not Java technology. It uses the Java programming language but Dalvik is not a JVM. It’s not claiming to be Java tech.

Q. Is support for Flash lite planned?
A. Not at the moment.

Q. Will there be an SDK for PPC Macs?
A. Don’t think so. Just Intel.

Q. Will you have aesthetic standards like the iPhone?
A. We’re working with UI designers to put out a user interface guideline. Also android provides standard UI widgets.

Android will be 100% open source, says Google

Contrary to some reports, everything that makes Android “Android”, including all the core platform components and libraries needed to port Android to new devices will be open sourced under commonly used, industry standard licenses, says Google.

.. continue reading this article at the ZDnet Blogs
Your Ad Here

Search Me