Your Ad Here
Showing posts with label architecture. Show all posts
Showing posts with label architecture. Show all posts

Saturday, May 23, 2009

Google's Rubin: Android 'a revolution'


Among all the companies fighting to grab a piece of the brightest star in computing--the smartphone--Google seems the least interested in taking the spoils.

Android, Google's mobile operating system, doesn't generate revenue for the company, and likely never will--at least in the direct sense. But Andy Rubin, Google's director of mobile platforms, thinks Google and the world will benefit from any device created with the intent of getting more people onto the Internet, and isn't shy about explaining why the open-source approach chosen for Android holds the most promise of reaching that goal.

Android made its debut in 2007, a few months after another computer with designs on improving the Internet experience on a phone--the iPhone--hit the streets as perhaps the most hyped gadget ever. Buzz has been slower to build around Android, but that could start to change as additional phones arrive that have a bit more pizazz than the G1, the world's first Android phone released last October.

Ahead of next week's Google I/O Developer Conference, where Rubin is expected to discuss future Android phones and goals for the software, he sat down with CNET News to review Google's progress thus far and share his impressions of what makes Android unique.

Q: How do you reconcile the goals of staying open with the need to offer carriers their own experience and the compatibility problems that may come as a part of that?
Rubin: Traditionally what's happened is the burden has been on the (phone makers) to be systems integrators. And what you get is kind of a lowest common denominator of functionality and usability because the software was actually developed by multiple parties, and nobody was really thinking holistically about the user experience.

It's (about) how do people expect these products to perform, and what are the various paces that a consumer will put these products through? No one company was thinking about that.

And so a huge benefit to this open platform is that it's complete, it's basically everything you need to build a phone. Sometimes the reason things fragment is because the platform is incomplete and people need to fill in the pieces. And when you fill in the pieces, you inherently have incompatibility.

It is possible to have a completely different user interface with a completely different look and feel but still be compatible. And that will be demonstrated.

There will be a couple of launches; we've generated a lot of interest in China. The use cases in China are slightly different in the U.S.; typically in China, because of the Asian input, people prefer a pen-based interface rather than a capacitive-touch based interface because they expect a stylus to be able to draw the complex characters. So the use case has completely changed but we have achieved compatibility.

How did the goal of Android evolve after it was brought into Google?
Rubin: The goal was pretty much the same, the business model obviously changed. Google's business model is deep into advertising, and so for Google this is purely a scale of the business, we just want to reach more people, and hopefully they'll use Google and we'll get the upside of the advertising revenue.

By the way, we're confident enough in our advertising business and our ability to help people find information that we don't somehow demand they use Google. If somebody wants to use Android to build a Yahoo phone, great.

Did you ever consider doing a phone? A Google phone?
Rubin: Yeah...I mean, it's funny, if you build one phone...I'd much rather be the guy that does a platform that's capable of running on multiple companies' phones than just focusing on a single product.

A single product is going to have, eventually, limitations. Even if that was two products that's going to have limitations. But if it's a hundred products, now we're getting somewhere, to the scale at which Google thinks people want to access information.

Getting back to business models, Google has a great business model around advertising, and there's a natural connection between open source and the advertising business model. Open source is basically a distribution strategy, it's completely eliminating the barrier to entry for adoption.

When Android was a start-up company, it was always a razor/razor blade business. The razor, the free thing, was the open-source operating system. In Android's original business model, the blades were basically provisioning systems that we sold to wireless carriers that had hooks into the open-source operating system. That was an unproven business model, I would say, and certainly the feedback I got when we were going for venture financing was that it was an unproven business model.

I was willing to give it a go, but then Larry and Sergey and Eric came along and said, "it's much more aligned with Google's core business and Google's business model, and you'll have a much easier time executing within Google." And retroactively, I agree.

Is this a market share play? Is this something where you want to conquer the mobile world?
Rubin: We look at it first from the scale perspective. The mission here is to organize the world's information and make it universally accessible and relevant. So the accessible part: think of a world in which you are somehow prevented from accessing the information you want. When I go to a hotel room and pay the $19.95 to get on the Internet and they have some firewall that doesn't let me get to my Exchange server, it makes me berserk.

I look at things--and Google looks at things--in (terms of) how could the landscape change in such a way that consumers who want to access Google services can't?

In that honest goal of not having consumers being blocked and allowing them to access information, it helps our competitors as well. What we don't want to do is disadvantage anybody by being the only person; we don't want to create any kind of separate structure where people can only access Google. And this is the definition of openness: it's not just open source, it's the freedom to get the information that you're actually looking for.

Why is this approach better what Apple or Palm is doing where they control the whole device?
Rubin: Controlling the whole device is great, (but) we're talking about 4 billion handsets. When you control the whole device the ability to innovate rapidly is pretty limited when it's coming from a single vendor.

You can have spurts of innovation. You can nail the enterprise, nail certain interface techniques, or you can nail the Web-in-the-handset business, but you can't do everything. You're always going to be in some niche.

What we're talking about is getting out of a niche and giving people access to the Internet in the way they expect the Internet to be accessed. I don't want to create some derivative of the Internet, I don't want to just take a slice of the Internet, I don't want to be in the corner somewhere with some dumbed-down version of the Internet, I want to be on the Internet.

Even if that comes at the cost of compatibility or UI advances? If you're going to be the Everyman phone, you're going to have to make some sacrifices at some point, right?
Rubin: I think that's yet to be seen. I think we've done a pretty good job. Again, we're talking about a clean slate technology that didn't exist a few years ago. So I'm actually thinking this could be a revolution.

Remember people used to trumpet "write once, run everywhere"? Well, I think we're actually there. I think when we start talking about the possibility of exploring things like Netbooks and car navigation systems, you have potentially different processor architecture types. You have Intel, you have ARM, set-top boxes have MIPS.

We have all sorts of different processor architectures, and the guys who are steeped in legacy have trouble addressing those markets with a single solution. I actually think Android is the potential single solution that can address all those markets, and it's new, it's revolutionary. It will change the game.

If this is a revolution, why haven't we seen more of these phones?
Rubin: It takes about 18 months to build a phone from end to end. What we wanted to do for our market entry was make sure that we had one successful showcase product to prove that the product was reliable and robust and ready to go. We chose HTC as our partner for that.

The forthcoming Samsung i7500, based on Google's Android
(Credit: Samsung)

At the moment we open-sourced, November 7 (2007), that's when a lot of these guys got their hands on it. We're still in that 18-month window of building products, and what you'll see coming up is a whole string of products.

What did you learn from Android 1.0 to 1.5?
Rubin: I learned that 1.5 was the product I wished was 1.0. The reason is it's a different business for Google: helping the industry build operating systems for their cell phones.

Because on the Web, you can iterate very quickly, and you can put things out in beta, you can fix bugs literally hourly. On cell phones you're blasting something in a ROM in a device that's in manufacturing where you did just-in-time ordering of all the parts and have inventory risk and everything else. Widgets are literally coming down a factory line, and if software isn't ready by the time they reach the end of the line they're going to drop on the floor and pile up. And that winds up costing a lot of people a lot of money. And if you don't get it right, you're kind of hosed.

What is going to dictate who wins and loses in this market? We all have different things that we may want in a phone. How do you try to be the Everyman phone and try to keep up with what's going on?
Rubin: We're trying to be something really unique, and I don't think anybody else is offering this. We put a very focused spotlight on openness, and openness is the means by which you get the product that you want.

Do people care (about openness)? I mean, the industry might care, the partners in the Open Handset Alliance may care, but do consumers?

It's an enabler. I'm not on some marketing campaign to educate consumers about what openness means. Actually, if you ask anybody on the street, you're going to get 10 different definitions of openness. The Symbian guys are going to be like "I'm open," and the LiMo guys are going to say "I'm open."

There's probably like a royal flush of openness, where you can lay your cards on the table and say (pointing) "open, open, open, open, open," it's the guy with the most open that's going to win.

I think we're that. I think that we have an open ecosystem, we have an open-source platform, we chose the right license, there are no viral aspects, it's absolutely 100 percent free, it's complete, it's everything you need to build a phone. When you add all that stuff up, all those ingredients, potentially--I think the jury's still out--we can make a really successful product.

Thursday, February 5, 2009

Android: One Multitasking Operating System

When Google (GOOG) and its partners first unveiled plans for the Android operating system, they billed it as software that would run mobile phones. That mission was accomplished the following year with the late 2008 release of T-Mobile's G1 phone. More Android-enabled handsets are on the way.

But before long, you may be seeing Android in a lot of other electronic devices.

Just ask Mark Hamblin, who helped design the original touchscreen for the Apple (AAPL) iPhone. Now the CEO of Touch Revolution, Hamblin is tinkering with Android so it can work in a slew of gadgets other than wireless phones. In late 2009, Touch Revolution plans to introduce a remote control and a touchscreen land-line home phone that will be powered by Android. Also in the works from Hamblin's company: touchscreen menus for restaurants, Android-based medical devices, and a 15-in. kitchen computer where family members can leave messages for one another.


More Devices on the Way

Android everywhere would come as good news to Google and chipmakers such as Qualcomm (QCOM) and Texas Instruments (TXN) that have invested in its development and would welcome the chance to sell semiconductors in new markets. But Android ubiquity could cause headaches for Microsoft (MSFT), which would rather see its own software on a wider range of electronic devices.

Where will Android end up next? A handful of electronics manufacturers plan to unveil Android-based mobile Internet devices, or MIDs, and stripped-down computers known as netbooks at the GSMA Mobile World Congress, scheduled for later this month in Barcelona. "Nine months ago it was a lot of people who were curious" about using Android, says John Bruggeman, chief marketing officer at WindRiver Systems (WIND), a consulting firm that's working with several Asia-based manufacturers on the products. "Now they are starting to build designs" that effectively bypass Windows altogether, he says. Bruggeman declines to name the companies planning to introduce Android products.

Microsoft says it's undaunted by the prospect of increased competition from Android, itself based on Linux, a software whose code is freely available via the Internet and developed by programmers the world over. "We welcome the chance to compete with others in this space," a Microsoft representative said in a statement. "Overall, we find that customers prefer the familiarity, compatibility, and ease-of-use of Windows over Linux."


Designed to Run on Any Device

Yet in some cases, Android may end up with first-mover advantage as it shows up in devices such as netbooks or digital photo frames where Microsoft has yet to establish a beachhead. "It would make sense for any [software vendor] to play there," Hamblin says. "I see tremendous growth in these ubiquitous computing devices." That looks all the more attractive as growth slows in the computing industry. PC shipments are expected to increase only 4.3% this year, according to researcher iSuppli.

Manufacturers that work with Texas Instruments have built Android into video and audio players and picture frames due out within months. Rival semiconductor manufacturer Qualcomm is helping vendors ready more than 20 Android-based products, including video players and small tablet PCs, for release in 2009 and early 2010.

Google hasn't announced plans to market Android for use in nonphone gadgets. Still, "we are being very supportive to the [developer] community targeting these devices," says Andy Rubin, senior director of mobile platforms at Google.

While they didn't say much about nonwireless devices when they first started talking about Android, Google and its partners designed Android to run on any device—from a smart phone to a server. "We had the foresight to design it with bigger screens and [chips] in mind," Rubin says. Unlike many cell-phone and PC-based operating systems, Android can run on devices powered by a variety of semiconductors with minimal modifications needed. "There's nothing that I've been able to find out that would limit it," says Bill Hughes, an independent software analyst.


Competition from Linux

With flexibility comes economy. Manufacturers can keep costs low by being able to choose from a wider range of chips, for example. The software is also virtually free to use, while Microsoft charges licensing fees.

And just in case consumers fret that they won't be able to use their favorite Microsoft applications on an Android device, a company called DataViz will soon unveil software that it says will let people open, edit, and send Word, Excel, and Microsoft PowerPoint files. The software will also allow synching between Android and Outlook e-mail. "Android has quite a bit of potential," says Ilya Eliashevsky, product manager at DataViz.

As potent as it may be, Android faces competition not just from Microsoft but also Linux. One of Android's creators, Intel (INTC), recently introduced its own Linux software, Moblin, for use with MIDs and netbooks running its Atom processors.

That said, there's no reason why the two efforts couldn't combine, says David Liu, CEO of Good OS, which plans to use parts of Android and Moblin to speed the boot-up times of its own computer software.

And in places where Microsoft is established, consumers familiar with Windows may also hesitate to adopt a new operating system. "People tend to be pretty sticky with their [operating systems]," Hughes says. "[Android] has to offer something cheaper and dramatically easier to use." Woe to Microsoft if it does.

Saturday, January 17, 2009

Android 'Cupcake' update



Notable changes introduced in cupcake:

Applications
  • MMS
    • New features
      • Save attachments from MMS.
    • Significant bug fixes
      • Faster conversation list scrolling
  • Email
    • Significant bug fixes
      • Accounts that were marked "never check" are not auto-checked.
      • Date & time displayed using user preference (e.g. 24 hr vs. AM/PM).
      • cc: displayed in message view.
      • Relaxed POP3 parser rules so it works with non-compliant email servers.
      • Password quoting bugs in IMAP. Makes it work for users with funny chars in their password (e.g. spaces).
      • Various sources of errors in auto & manual account setup.
      • Improvements on how we report various connection errors. Makes it much easier for user to diagnose failed account setups.
      • New-mail notifications for POP3 accounts.
      • Properly recover from POP3 connection failures, so that the next connection has a chance of working properly.
      • Remove automatic accounts setup entries that were broken or not testable. Minor fixes to a few of the remaining entries. Improvements to warning dialogs used for a few special cases.
      • New accounts are now set to check every 15 minutes (instead of defaulting to "never").
      • Fixed a bug causing approximately 1 in 25 outbound messages to freeze up the IMAP connection (to a Gmail based server) when transferred to the Sent folder. This broke the entire connection so new messages could not be downloaded either.
      • Unit test framework so Email can be extended & tested more reliably.
      • Fix IMAP manually-created accounts so message delete works properly.
  • Alarm Clock
    • Significant bug fixes
      • Alert now plays audio/vibe directly, rather than through AlarmManager. AlarmClock alert starts playing audio/vibe in its IntentReceiver, rather than on activity start. These changes should prevent alarms from being blocked by modal dialogs.
  • Package Installer
    • Significant bug fixes
      • Bugs related to replacing existing applications.
  • Settings
    • New features
      • New menu option to list running processes in Settings->ManageApplications.
  • Music
    • New features
      • Music playback fades in after suspending for phone call.
      • New media search intent allows for 3rd party apps to launch or respond to media searches based on artist, album, or title.
        Affects: Music Player, YouTube, Browser applications.
  • Browser
    • New features
      • Updated WebKit browser core, synced with Nov 2008 WebKit version.
      • Support for new, optimized JavaScript engine (SquirrelFish).
      • Copy / paste is enabled in the browser. To copy with touch, press and hold the shift key and select the text. Releasing the shift key or ending the touch drag copies the text. To copy with the trackball, press and hold the shift key, move the cursor to the selection start, click the trackball, and move the trackball to the extend the selection. Releasing the shift key, or clicking the trackball a second time, copies the text.
      • Find is enabled in the browser. To find text, choose it from the menu and type the text to find.
      • Drawing has been sped up substantially by supporting partial content invalidates and partial screen invalidates. Pages with animations are 5x faster.
  • VoiceDialer
    • New features
      • VoiceDialer supports 'open app' command
  • Camera/Gallery
    • New features
      • Video recorder mode
      • Share intent for videos
      • Video thumbnails
      • Local file playback
Download manager
  • New features
    • Support for HTTP codes 301, 302, 303 and 307 (redirects).
    • HTTP code 503 is now handled, with support for retry-after in delay-seconds.
    • Downloads that were cleanly interrupted are now resumed instead of failing.
    • Applications can now pause their downloads.
    • Retry delays are now randomized.
    • Connectivity is now checked on all interfaces.
    • Downloads with invalid characters in file name can now be saved.
Framework
  • New features
    • Support of touch events in WebView.
    • New JavaScript engine (SquirrelFish) in WebView.
    • Input method framework, for soft keyboards and other on-screen input methods. Includes new APIs for applications to interact with input methods, and the ability for third party developers to write their own input methods.
    • Access to the raw audio data for playback and recording from application code.
    • New PendingIntent.FLAG_UPDATE_CURRENT option.
    • Support for top-level boolean resources.
    • Tactile feedback to the LockPatternView. Tactile feedback can be enabled/disabled by going to Settings > Security & location and then checking/unchecking "Use tactile feedback". Note that this can be used independently of the visual feedback of the lines ("Use visible pattern"). Thus it gives users a middle ground between showing the lines on the screen and having no feedback at all.
    • PackageManager changes to support un-installation of partially installed applications. Added new flag PackageManager.GET_UNINSTALLED_PACKAGES to include partially installed apps in all relevant PackageManager api's. ManageApplications screen now lists such partially installed apps and the user can uninstall these applications completely.
    • Support third party updates of system applications. New menu options in Settings->ManageApplications to list updated system applications.
    • Framework support to list current running processes. New API in ActivityManager.
    • Framework feature to declare required configurations by applications. New manifest attribute uses-configuration in android manifest.
    • Hardware accelerated video encode (video recorder) in opencore.
    • Simplified SREC speech recognition API available.
    • Streaming audio I/O for applications.
  • Significant bug fixes
    • Fixed issues with saving state in the view hierarchy, so that you can properly subclass from something like TextView and create your own state that inherits from that provided by TextView.
    • TextView now implements onKeyMultiple(), so that flinging the trackball will result in accelerated scrolling. This required some changes to movement methods, and included some improvements to the acceleration computed when flinging.
    • Framework bug fixes in PackageManager to share/un-share permissions for applications with shared uid's.
    • Significant rework of Settings->ManageApplications Performance and UI enhancements.
    • A number of settings in android.provider.Settings.System were moved to android.provider.Settings.Secure. Only system software can modify these settings. Additionally, a new permission, WRITE_SECURE_SETTINGS, is required to access these settings. The old constants in Settings.System have been deprecated. It is possible to read settings values via Settings.System using the deprecated constants. However, attempts to modify these settings via Settings.System will result in a log message and the setting value will be left unchanged.
    • Many bug fixes in the media framework

Bluetooth
  • New features
    • Support for A2DP & AVRCP profiles.
  • Significant bug fixes
    • First connection after pairing always fails on many carkits.
    • Mini Cooper and some late model BMW cars fail to use Bluetooth or take 2 minutes for Phone Book transfer.
System software
  • New features
    • New kernel based on Linux 2.6.27.
    • Improvements to the wakelock API.
    • Work to transition to the USB Gadget Framework underway.
    • Basic x86 support.

Radio & Telephony
  • New features
    • SIM Application Toolkit 1.0.
    • Green CALL button is no longer a shortcut for "add a new call". This has been a rarely used feature and confusing if triggered accidentally.
    • Longer in-call screen timeout when using the speakerphone.
    • "Show dialpad" / "Hide dialpad" item added to the in-call menu, to make it easier to discover the DTMF dialpad.
  • Significant bug fixes
    • An obscure case where the Phone UI could cause the device to not go to sleep on its own. This would happen if user bails out of the in-call screen by hitting HOME, followed by the call disconnecting remotely.
    • Don't allow a single tap to open the in-call dialpad. It is now required to touch and drag it. This makes it much harder to accidentally open the dialpad by touching the screen with your face.

Developer Tools
  • New features
    • Enable handset manufacturers to extend the Android SDK with add-ons. SDK add-ons will include:
      • system libraries to let developers use additional APIs provided by handset manufacturers or from other 3rd party vendors that handset manufacturers chose to include
      • emulator system images, skins, and hardware configuration to let developers test their applications on their Android implementation
This is work-in-progress. Please note that the latest Android SDK (Android 1.0 SDK, Release 2) is not compatible with the SDK plugin in the new branch, please use ADT 0.8.0. SDK add-on support is planned for future SDK release.

Build System
  • New features
    • The functions in build/envsetup.sh should be much more useful

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 com.google.something.

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 wapreview.com). 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.


Your Ad Here

Search Me