MyMobiSafe® Mobile Antivirus next Android App?

MyMobiSafe^® Mobile Antivirus Security Solution
http://www.mymobisafe.com/

I stumbled upon this site today while searching for news about Android.
Could we be seeing the first Mobile Antivirus application for Android?

And could this become the winner of the $10 Million Dollar Prize?

Do you really think there is a need for Mobile Antivirus Applications at the moment? In the future?
I bet as these Phones get more popular and we see more applications we will also be seeing more need for Security for the Mobile Platform.

Only time will tell.

Android running on a real device

Check out the video below it is a Armadillo-500 running an actual Android Application.
Pretty interesting video and I can't wait to see what all of these Developers come up with.

We should have some pretty interesting Applications in the near future!

Artificial Life -

Artificial Life -

Artificial Life, a mobile entertainment and game company announced that they will be making Games and Applications for Android.
The company looks pretty interesting so hopefully some cool applications will come out of this.

You can check their site out here:
artificial-life.com

jflubber - Google Code

jflubber - Google Code

jflubber

A simple java GUI tool to record flub points (mistakes) in recordings

Developed for the podcast I am a co-host of. The tool is like a simple stopwatch with the capability of recording any number of flub points - points with mistakes in the recording. It can then save a file which can be loaded directly into audacity as a label track, showing you exactly where the mistakes are to speed up editing.

See the developer.com article Building Java GUIs with Matisse: A Gentle Introduction at http://www.developer.com/java/ent/article.php/3589961 for much more information about the reason for writing jFlubber, and how it was built.

Download the executable Jar file with jflubber in it from the downloads section on the right.

For more help, see DownloadingAndRunning

Android Developers Blog: A Stitch in Time

Android Developers Blog: A Stitch in Time


Background: While developing my first useful (though small) application for Android, which was a port of an existing utility I use when podcasting, I needed a way of updating a clock displayed on the UI at regular intervals, but in a lightweight and CPU efficient way.

Problem: In the original application I used java.util.Timer to update the clock, but that class is not such a good choice on Android. Using a Timer introduces a new thread into the application for a relatively minor reason. Thinking in terms of mobile applications often means re-considering choices that you might make differently for a desktop application with relatively richer resources at its disposal. We would like to find a more efficient way of updating that clock.

The Application: The rest of the story of porting the application will be detailed in future blog entries, but if you are interested in the application in question and the construction of it, you can read about it in a not-so-recent Developer.com article about using Matisse (a GUI builder for Swing). The original application is a Java Swing and SE application. It is like a stopwatch with a lap timer that we use when recording podcasts; when you start the recording, you start the stopwatch. Then for every mistake that someone makes, you hit the flub button. At the end you can save out the bookmarked mistakes which can be loaded into the wonderful Audacity audio editor as a labels track. You can then see where all of the mistakes are in the recording and edit them out.

The article describing it is: http://www.developer.com/java/ent/print.php/3589961

In the original version, the timer code looked like this:

class UpdateTimeTask extends TimerTask {
public void run() {
    long millis = System.currentTimeMillis() - startTime;
    int seconds = (int) (millis / 1000);
    int minutes = seconds / 60;
    seconds     = seconds % 60;

    timeLabel.setText(String.format("%d:%02d", minutes, seconds));
}
}

And in the event listener to start this update, the following Timer() instance is used:

if(startTime == 0L) {
startTime = evt.getWhen();
timer = new Timer();
timer.schedule(new UpdateTimeTask(), 100, 200);
}

In particular, note the 100, 200 parameters. The first parameter means wait 100 ms before running the clock update task the first time. The second means repeat every 200ms after that, until stopped. 200 ms should not be too noticeable if the second resolution happens to fall close to or on the update. If the resolution was a second, you could find the clock sometimes not updating for close to 2 seconds, or possibly skipping a second in the counting, it would look odd).

When I ported the application to use the Android SDKs, this code actually compiled in Eclipse, but failed with a runtime error because the Timer() class was not available at runtime (fortunately, this was easy to figure out from the error messages). On a related note, the String.format method was also not available, so the eventual solution uses a quick hack to format the seconds nicely as you will see.

Fortunately, the role of Timer can be replaced by the android.os.Handler class, with a few tweaks. To set it up from an event listener:

private Handler mHandler = new Handler();

...

OnClickListener mStartListener = new OnClickListener() {
public void onClick(View v) {
    if (mStartTime == 0L) {
         mStartTime = System.currentTimeMillis();
         mHandler.removeCallbacks(mUpdateTimeTask);
         mHandler.postDelayed(mUpdateTimeTask, 100);
    }
}
};

A couple of things to take note of here. First, the event doesn't have a .getWhen() method on it, which we handily used to set the start time for the timer. Instead, we grab the System.currentTimeMillis(). Also, the Handler.postDelayed() method only takes one time parameter, it doesn't have a "repeating" field. In this case we are saying to the Handler "call mUpdateTimeTask() after 100ms", a sort of fire and forget one time shot. We also remove any existing callbacks to the handler before adding the new handler, to make absolutely sure we don't get more callback events than we want.

But we want it to repeat, until we tell it to stop. To do this, just put another postDelayed at the tail of the mUpdateTimeTask run() method. Note also that Handler requires an implementation of Runnable, so we change mUpdateTimeTask to implement that rather than extending TimerTask. The new clock updater, with all these changes, looks like this:

private Runnable mUpdateTimeTask = new Runnable() {
public void run() {
final long start = mStartTime;
long millis = SystemClock.uptimeMillis() - start;
int seconds = (int) (millis / 1000);
int minutes = seconds / 60;
seconds = seconds % 60;

if (seconds <>

and can be defined as a class member field.

The if statement is just a way to make sure the label is set to 10:06 instead of 10:6 when the seconds modulo 60 are less than 10 (hopefully String.format() will eventually be available). At the end of the clock update, the task sets up another call to itself from the Handler, but instead of a hand-wavy 200ms before the update, we can schedule it to happen at a particular wall-clock time - the line: start + (((minutes * 60) + seconds + 1) * 1000) does this.

All we need now is a way to stop the timer when the stop button is pressed. Another button listener defined like this:

OnClickListener mStopListener = new OnClickListener() {
public void onClick(View v) {
    mHandler.removeCallbacks(mUpdateTimeTask);
}
};

will make sure that the next callback is removed when the stop button is pressed, thus interrupting the tail iteration.

Handler is actually a better choice than Timer for another reason too. The Handler runs the update code as a part of your main thread, avoiding the overhead of a second thread and also making for easy access to the View hierarchy used for the user interface. Just remember to keep such tasks small and light to avoid slowing down the user experience.

So that's it for the first of what will be a series of Android tips. Hopefully this will save you a little head scratching on what will probably be a fairly common thing to want to do (i.e. make something happen or update at regular intervals in a lightweight way in your application). There is plenty of more material from my experience of porting this very simple application which will be covered in some of the future "tips" articles. There are some other great tips being discussed as well as an opportunity ask questions at the Android Developers Discussion Group.

» Google’s big TV plan: Android on set-top boxes? | Between the Lines | ZDNet.com

Following Credit Suisse’s $900 price target for Google one nagging question remains: Where–and how–is Google going to generate large TV advertising revenue?

If you recall Credit Suisse analyst Heath Terry slapped a big price target on Google and made some assumptions for 2010. One of them was a base case that Google would have TV advertising revenue of $416 million in 2010, up from nothing today. The bullish case called for $1 billion in TV ad revenue with the bear case being $130 million.

All day, I was wondering how Google would get there. Its deal with Echostar isn’t going to cut it. And TV partners are wary of Google anyway.

However, Tech Crunch’s Erick Schonfeld has a working theory. Google will take its Android software to the set-top box, get a bunch of developers on board and give us the future of television. As to be expected, few are commenting on the record about this plan. And Google is doing its denial without denying routine (it likes these rumors).

Color me skeptical. Here’s why:

Android is unproven. There are high hopes for an Android announcement that so far is a nice press release, a developer kit and a partner roster that is a bit noncommittal about the whole thing. If Android were launched by any company other than Google it would be classified as vaporware already. Before Android makes it into a handset, we’re leaping toward the set-top box.

Set-top boxes are difficult to get into. There are two primary makers of set-top boxes–Cisco and Motorola. Any effort for an open platform has to go through them. And then there’s Microsoft, which has spent billions over the years and is just now getting some traction. Sure, the ability for consumers to buy their own set-top boxes (Googlebox) is a plus, but the set-top box sure is getting crowded. On the bright side, Cisco has Web 2.0 religion and Motorola is an Android partner.

Partners matter. In the land of the set-top box, Google will run into the same problem it has in mobile–entrenched players that tell you what you put on their network. Google can have the best set-top software on the planet, but it needs Comcast, Time Warner, Verizon, AT&T and Cablevision to play along.

Maybe we don’t want our set-top boxes to be all Webified. Schonfeld argues quite well that the set-top box is a computer that doesn’t do much. What if it could? Schonfeld argues that a TV screen polluted with widgets, weather, sports scores and stock quotes could be a better experience. Well, I can have all of that now with Verizon FiOS TV via Microsoft’s widgets. I’ve hit the widget button maybe twice for giggles. TV is a different experience and more often than not I want all the boxes, TVs and technology to disappear in the background. Even the news scroll has become annoying. Some of us just want to watch the game in peace–without better targeted ads, widgets and other clutter.

PC World - Google, Sun May Clash Over Android's Use of Java

Google could be heading for a showdown with Sun over the way Android, Google's new mobile phone software platform, handles Java.

Instead of using the standards-based Java Micro Edition (JME) as an engine to run Java applications, Google wrote its own virtual machine for Android, calling it Dalvik. There are technical advantages and disadvantages to using Dalvik, developers say, but technology may not have been the driver for Google.

Google most likely built Dalvik as a way to get around licensing issues with Sun that would have come with using JME, said Stefano Mazzocchi, a developer and board member at Apache Labs.

Phone makers that incorporate JME into their phones must license the technology from Sun if they intend to make any modifications to it, Mazzocchi said. A phone maker could freely use JME under an open source license if it shares innovations to the software with the community, but most large handset makers are reluctant to do that, he said.

Rather than require phone makers to license JME as part of Android, Mazzocchi said, Google built its own virtual machine. Dalvik converts Java bytecodes into Dalvik bytecodes.

"So Google can say Dalvik is not a Java platform," said Hari Gottipatti, a mobile developer who also has been examining the issue.

Google declined to comment on Dalvik.

"I believe Sun didn't see this coming," Mazzocchi said. "I think this was a very smart and clever move."

Still, Google could run into trouble. If Google used any of Sun's intellectual property to build Dalvik, Sun could sue Google for patent infringement, Mazzocchi said. "I'd be very curious to see what Sun would do," he said. That's because Sun is a staunch advocate for open source, so it would hardly appease the open source community to sue Google over an open source software stack.

However, Google's move threatens Sun's business strategy, Mazzocchi said. He believes that Sun sees a bright future in the mobile market and hopes to earn revenue off the use of the Java virtual machine by phone makers. Google's plan diminishes that opportunity for Sun.

While Sun declined to comment directly for this story, it pointed to some public statements from company executives. Jonathan Schwartz, president and CEO of Sun, wrote a blog post congratulating Google on the day of Android's launch. Notably, he refers to Android as a "Java/Linux" platform. By contrast, Google carefully appears to avoid calling Android a Java platform. Google describes the Android software development kit as a set of tools that lets developers create applications using Java.

Sun also shared statements that Rich Green, executive vice president of software at Sun, made during Oracle Open World this week about Android. "We're reaching out to Google and are anticipating they will be reaching out to us to ensure the software and APIs will be compatible--so deployment on a wide variety of platforms will be possible," he said.

Green also said that Sun wants to work with Google to prevent creating a fractured mobile development environment.

That's a concern for other mobile developers like Gottipatti. The mobile environment is already fractured. Even with JME, he has to alter his applications for different phones. "But in that case as a developer I'm porting once and maybe tweaking for different phones," he said. "But with this you'll need to develop a separate application that's not standard. Unless Android becomes main stream and kills J2ME ... why should I develop applications that are not standard which I'm not sure about because I haven't seen any commercial handsets yet?"

Gottipatti believes that the technical differences in Dalvik were the main driver for Google, not the licensing issue. The license fee that handset makers must pay for JME is very nominal, he said. He thinks that if Google asked, Sun would have included JME in Android and waived the licensing fee.

AT&T talks with Google about joining wireless software group

AT&T eyes teaming up

Bloomberg News

Article Launched: 11/17/2007 01:41:05 AM PST

AT&T has talked with Google about joining its mobile-phone software alliance. The phone company is "analyzing the situation" and may use Google's software for phones, Ralph de la Vega, chief executive officer of the wireless unit, said in an interview Friday. He refused to give details of discussions and said he hasn't personally met with Mountain View-based Google. The search-engine giant announced Nov. 5 that it would work with 33 companies to develop software for mobile phones. Wireless carriers Sprint Nextel and T-Mobile USA joined the alliance, looking for features such as local shopping searches that could help them lure new customers.

This could become interesting. Direct competition to the iPhone?

Software tools for Google Android

Google released a software development kit for its Android mobile-phone software on Monday. This shot shows what programming looks like in the open-source Eclipse programming tool project, including an emulator that lets coders get started even if they don't have a phone prototype handy.

Credit: Google

The Android software developer kit includes an interface to the Google Maps service. Pictured here are driving directions shown in a translucent window above a map.

Credit: Google

This shot shows the "home screen" running in the emulator with various menu options below. The user interface look and feel shown in the emulator is a "placeholder" that will change by the time Android phones ship in the second half of 2008, Google said.

Credit: Google

This emulator screenshot shows applications available on an Android phone. Google is offering $10 million in contest prizes to encourage programmers to build new software for the phones.

Credit: Google

What is Android?

What is Android?

Android is a software stack for mobile devices that includes an operating system, middleware and key applications. This early look at the Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.

Features

• Application framework enabling reuse and replacement of components
• Dalvik virtual machine optimized for mobile devices
• Integrated browser based on the open source WebKit engine
• Optimized graphics powered by a custom 2D graphics library; 3D graphics based on the OpenGL ES 1.0 specification (hardware acceleration optional)
• SQLite for structured data storage
• Media support for common audio, video, and still image formats (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF)
• GSM Telephony (hardware dependent)
• Bluetooth, EDGE, 3G, and WiFi (hardware dependent)
• Camera, GPS, compass, and accelerometer (hardware dependent)
• Rich development environment including a device emulator, tools for debugging, memory and performance profiling, and a plugin for the Eclipse IDE

Android Architecture

The following diagram shows the major components of the Android operating system. Each section is described in more detail below.

Applications

Android will ship with a set of core applications including an email client, SMS program, calendar, maps, browser, contacts, and others. All applications are written using the Java programming language.

Application Framework

Developers have full access to the same framework APIs used by the core applications. The application architecture is designed to simplify the reuse of components; any application can publish its capabilities and any other application may then make use of those capabilities (subject to security constraints enforced by the framework). This same mechanism allows components to be replaced by the user.

Underlying all applications is a set of services and systems, including:

• A rich and extensible set of Views that can be used to build an application, including lists, grids, text boxes, buttons, and even an embeddable web browser
• Content Providers that enable applications to access data from other applications (such as Contacts), or to share their own data
• A Resource Manager, providing access to non-code resources such as localized strings, graphics, and layout files
• A Notification Manager that enables all applications to display custom alerts in the status bar
• An Activity Manager that manages the lifecycle of applications and provides a common navigation backstack

For more details and a walkthrough of an application, see Writing an Android Application.

Libraries

Android includes a set of C/C++ libraries used by various components of the Android system. These capabilities are exposed to developers through the Android application framework. Some of the core libraries are listed below:

• System C library - a BSD-derived implementation of the standard C system library (libc), tuned for embedded Linux-based devices
• Media Libraries - based on PacketVideo's OpenCORE; the libraries support playback and recording of many popular audio and video formats, as well as static image files, including MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG
• Surface Manager - manages access to the display subsystem and seamlessly composites 2D and 3D graphic layers from multiple applications
• LibWebCore - a modern web browser engine which powers both the Android browser and an embeddable web view
• SGL - the underlying 2D graphics engine
• 3D libraries - an implementation based on OpenGL ES 1.0 APIs; the libraries use either hardware 3D acceleration (where available) or the included, highly optimized 3D software rasterizer
• FreeType - bitmap and vector font rendering
• SQLite - a powerful and lightweight relational database engine available to all applications

Android Runtime

Android includes a set of core libraries that provides most of the functionality available in the core libraries of the Java programming language.

Every Android application runs in its own process, with its own instance of the Dalvik virtual machine. Dalvik has been written so that a device can run multiple VMs efficiently. The Dalvik VM executes files in the Dalvik Executable (.dex) format which is optimized for minimal memory footprint. The VM is register-based, and runs classes compiled by a Java language compiler that have been transformed into the .dex format by the included "dx" tool.

The Dalvik VM relies on the Linux kernel for underlying functionality such as threading and low-level memory management.

Linux Kernel

Android relies on Linux version 2.6 for core system services such as security, memory management, process management, network stack, and driver model. The kernel also acts as an abstraction layer between the hardware and the rest of the software stack.

Android Developers Blog: This is the droid you're looking for

Android Developers Blog: This is the droid you're looking for

Android Videos

Sergey Brin and Steve Horowitz discuss the availability of the SDK, that it will be open source in the future, and demo some applications.



Three part overview of the Android architecture and APIs






A first hand look at building an Android application





Open

Android allows you to access core mobile device functionality through standard API calls.

All applications are equal

Android does not differentiate between the phone's basic and third-party applications -- even the dialer or home screen can be replaced.

Breaking down boundaries

Combine information from the web with data on the phone -- such as contacts or geographic location -- to create new user experiences.

Fast & easy development

The SDK contains what you need to build and run Android applications, including a true device emulator and advanced debugging tools.

Download the Android SDK - Android

Download the Android SDK - Android

Android SDK is now open to Developers

Open Handset Alliance

Developers

Learn more about the Android Platform.

Download the early look SDK.

Participate in the Android Developer Challenge, which will give away $10 million to developers who build apps on the platform. Learn more

Win $10 Million Dollars!!!!

Rumor: First Android App To Come From WhatsOpen.com?

Here are some leaked Screen's of the First App from WhatsOpen.com for Android.

Looks Interesting. More info as soon as it's available.

Gphone: Everything We Know About the gPhone, Android, and Open Handset Alliance

Gphone: Everything We Know About the gPhone, Android, and Open Handset Alliance

The details on Google's gPhone Open Handset Alliance are coming to light. Here's what we know:
•They're hoping to make a better phone, ultimately. (And sell a ton of ads and services, of course, along the way.)
•Android, an open system for handset dev, is the first joint project and core product of the alliance.
•There are 34 members of the group, including NVIDIA, Intel, Texas Instruments, Synaptics (haptics!), Marvell, Qualcomm (chips), Motorola, Samsung, TMO, Sprint, LG, HTC, KDDI and DOCOMO from Japan and China Mobile Comm. Corp.. Basically, a lot of companies sick of Windows Mobile Slop and other closed up phone systems like the iPhone.
•Who's missing is interesting: Nokia, Sony Ericsson, Blackberry/RIM, Apple, Verizon, and AT&T. Oh, did I forget to mention Microsoft?
•Handsets coming in 2008, second half.
•Nov 12th, the Android early look SDK drops.
•Android built on Linux, made avail as open source via the Apache v2 License.
•Companies can dev custom functionality to Android without contributing the source code back to the community.
• HTC's first prototype is the dream. It's the first set of hardware details we've heard of.
•Chen's rounded up Gphone details from a couple of mainstream publications. There's nothing you haven't read above, but a few more quotes.
•Couple of Videos on the Android. One by devs, one by kids.

I'll update this post as more comes. Just got off a conference call, actually. No new details. This is the basic outline of what we have for now.

Open Handset Alliance FAQ

FAQ

What is the Open Handset Alliance™?
The Open Handset Alliance is a group of more than 30 technology and mobile companies who have come together to accelerate innovation in mobile and offer consumers a richer, less expensive, and better mobile experience. Together we have developed Android™, the first complete, open, and free mobile platform. We are committed to commercially deploy handsets and services using the Android Platform in the second half of 2008.

What types of companies are in the Open Handset Alliance?
All parts of the mobile ecosystem are represented in the Alliance. Members include mobile operators, handset manufacturers, semiconductor companies, software companies, and commercialization companies. The current list of members can be found here.

What have members of the Alliance committed to?
All members of the Alliance have committed to making the initial version of the platform a commercial success. Some companies have contributed significant intellectual property to the Alliance that will be released under the Apache v2 Open Source license. Others are working to make sure their chipsets support the platform. Handset manufacturers and mobile operators are working to develop handsets based on the platform. Commercialization partners are working with the industry to support the platform via a professional services model.

Why is an open platform good for consumers?
Consumers will see cheaper and more innovative mobile devices and services, which will inevitably feature more engaging, easier-to-use interfaces -- as well as a rich portfolio of applications.

Why is an open platform good for mobile operators?
The overall cost of handsets will be lower and mobile operators will have complete flexibility to customize and differentiate their product lines. Furthermore, they will see much more rapid innovation in handsets and in services.

Why is an open platform good for handset manufacturers?
Handset manufacturers will benefit from lower software BOM (bill of material) costs and faster time-to-market for handsets. In addition, they will have greater flexibility to customize and differentiate their product offerings.

Why is an open platform good for semiconductor companies?
As cellphone-on-a-chip becomes closer to reality, semiconductor companies will need access to more sophisticated software that takes advantage of the enhanced features of these solutions. The processors of tomorrow will be multi-core and have access to shared peripherals such as 3D graphics, signal processor cores and dedicated blocks for multi media acceleration, etc. Without support for these peripherals in the platform, semiconductor companies have no clear way to give 3rd party developers access to this enhanced functionality. An open platform helps semiconductor companies add support for their newest products in a timely manner.

Why is an open platform good for software companies?
An open platform allows for simplified integration of software components into a complete mobile platform, and the lower acquisition cost of the mobile platform will increase the ability of handset manufacturers to invest in high value and differentiated software components.

Why is an open platform good for developers?
Developers will be able innovate rapidly because they will have comprehensive API access to handset capabilities that are web-ready. They will experience increased productivity because they will have comprehensive and easy-to-use developer tools. And because open source offers a deeper understanding of the underlying mobile platform, they can better optimize their applications. Finally, the distribution and commercialization of mobile apps will be less expensive and easier.

Who can join the Open Handset Alliance?
The Open Handset Alliance brings together companies in the mobile ecosystem that each contribute to the effort in various ways. We welcome companies willing to make serious and ongoing contributions to openness in the mobile world.

Who do we contact to learn about joining the Open Handset Alliance?
Email us at info@openhandsetalliance.com

Open Handset Alliance

Open Handset Alliance: "What would it take to build a better mobile phone? A commitment to openness, a shared vision for the future, and concrete plans to make the vision a reality. Welcome to the Open Handset Alliance™, a group of more than 30 technology and mobile companies who have come together to accelerate innovation in mobile and offer consumers a richer, less expensive, and better mobile experience. Together we have developed Android™, the first complete, open, and free mobile platform. We are committed to commercially deploy handsets and services using the Android Platform in the second half of 2008. An early look at the Android Software Development Kit (SDK) will be available on November 12th."

Live coverage of Google's Android Gphone mobile OS announcement - Engadget

Live coverage of Google's Android Gphone mobile OS announcement - Engadget

Official Google Blog: Where's my Gphone?

Official Google Blog: Where's my Gphone?

About Android™

Android™ will deliver a complete set of software for mobile devices: an operating system, middleware and key mobile applications. On November 12, we will release an early look at the Android Software Development Kit (SDK) to allow developers to build rich mobile applications.

Open
Android was built from the ground-up to enable developers to create compelling mobile applications that take full advantage of all a handset has to offer. It is built to be truly open. For example, an application could call upon any of the phone's core functionality such as making calls, sending text messages, or using the camera, allowing developers to create richer and more cohesive experiences for users. Android is built on the open Linux Kernel. Furthermore, it utilizes a custom virtual machine that has been designed to optimize memory and hardware resources in a mobile environment. Android will be open source; it can be liberally extended to incorporate new cutting edge technologies as they emerge. The platform will continue to evolve as the developer community works together to build innovative mobile applications.

All applications are created equal
Android does not differentiate between the phone's core applications and third-party applications. They can all be built to have equal access to a phone's capabilities providing users with a broad spectrum of applications and services. With devices built on the Android Platform, users will be able to fully tailor the phone to their interests. They can swap out the phone's homescreen, the style of the dialer, or any of the applications. They can even instruct their phones to use their favorite photo viewing application to handle the viewing of all photos.

Breaking down application boundaries
Android breaks down the barriers to building new and innovative applications. For example, a developer can combine information from the web with data on an individual's mobile phone -- such as the user's contacts, calendar, or geographic location -- to provide a more relevant user experience. With Android, a developer could build an application that enables users to view the location of their friends and be alerted when they are in the vicinity giving them a chance to connect.

Fast & easy application development
Android provides access to a wide range of useful libraries and tools that can be used to build rich applications. For example, Android enables developers to obtain the location of the device, and allow devices to communicate with one another enabling rich peer-to-peer social applications. In addition, Android includes a full set of tools that have been built from the ground up alongside the platform providing developers with high productivity and deep insight into their applications.