Marin alexandru Catalin Master univeritar: iisc

Download 101.36 Kb.
Size101.36 Kb.
Universitatea Politehnica Bucureşti

Facultatea Electronică,Telecomunicaţii şi Tehnologia Informaţiei

Studenţi: MARIN Alexandru Catalin

Master univeritar: IISC



Cuprins 2

Ce este Android ? 2

Ce poate face Android ? 3

Licenta. 3

Arhitectura Android 3

Linux Kernel 5

Librarii. 5

Runtime la Android 6

Aplicatii Framework 6

Aplicatii 7

Procese si Threads 7

Stocarea Datelor 10

Evolutie – 1.5(Cupcake), 1.6 (Donut), 2.0(Eclair) 13

Hardware running Android 14

Dezvoltarea Software 14

Android vs. iPhone 3.0 17

Bibliografia 19

Ce este Android ?

Android is a mobile operating system running on the Linux kernel. It was initially developed by Android Inc., a firm later purchased by Google, and lately by the Open Handset Alliance.[3] It allows developers to write managed code in the Java language, controlling the device via Google-developed Java libraries.[4]

The unveiling of the Android distribution on 5 November 2007 was announced with the founding of the Open Handset Alliance, a consortium of 47 hardware, software, and telecom companies devoted to advancing open standards for mobile devices.[5][6] Google released most of the Android code under the Apache License, a free software and open source license.[7]

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

Ce poate face Android ?

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


With the exception of brief update periods, Android has been available as open source since 21 October 2008. Google opened the entire source code (including network and telephony stacks[22]) under an Apache License.[23]

With the Apache License, vendors are free to add proprietary extensions without submitting those back to the open source community.

Arhitectura Android

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

pentru a intelege trebuie sa parcugem arhitectura de baza in sus

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 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

Runtime la Android

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.

Aplicatii Framework

By providing an open development platform, Android offers developers the ability to build extremely rich and innovative applications. Developers are free to take advantage of the device hardware, access location information, run background services, set alarms, add notifications to the status bar, and much, much more.

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 the Notepad Tutorial.


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.

Procese si Threads

When the first of an application's components needs to be run, Android starts a Linux process for it with a single thread of execution. By default, all components of the application run in that process and thread.

However, you can arrange for components to run in other processes, and you can spawn additional threads for any process.


The process where a component runs is controlled by the manifest file. The component elements — , , , and
— each have a process attribute that can specify a process where that component should run. These attributes can be set so that each component runs in its own process, or so that some components share a process while others do not. They can also be set so that components of different applications run in the same process — provided that the applications share the same Linux user ID and are signed by the same authorities. The element also has a process attribute, for setting a default value that applies to all components.

All components are instantiated in the main thread of the specified process, and system calls to the component are dispatched from that thread. Separate threads are not created for each instance. Consequently, methods that respond to those calls — methods like View.onKeyDown() that report user actions and the lifecycle notifications discussed later in the Component Lifecycles section — always run in the main thread of the process. This means that no component should perform long or blocking operations (such as networking operations or computation loops) when called by the system, since this will block any other components also in the process. You can spawn separate threads for long operations, as discussed under Threads, next.

Android may decide to shut down a process at some point, when memory is low and required by other processes that are more immediately serving the user. Application components running in the process are consequently destroyed. A process is restarted for those components when there's again work for them to do.

When deciding which processes to terminate, Android weighs their relative importance to the user. For example, it more readily shuts down a process with activities that are no longer visible on screen than a process with visible activities. The decision whether to terminate a process, therefore, depends on the state of the components running in that process. Those states are the subject of a later section, Component Lifecycles.


Even though you may confine your application to a single process, there will likely be times when you will need to spawn a thread to do some background work. Since the user interface must always be quick to respond to user actions, the thread that hosts an activity should not also host time-consuming operations like network downloads. Anything that may not be completed quickly should be assigned to a different thread.

Threads are created in code using standard Java Thread objects. Android provides a number of convenience classes for managing threads — Looper for running a message loop within a thread, Handler for processing messages, and HandlerThread for setting up a thread with a message loop.

1.3Remote procedure calls

Android has a lightweight mechanism for remote procedure calls (RPCs) — where a method is called locally, but executed remotely (in another process), with any result returned back to the caller. This entails decomposing the method call and all its attendant data to a level the operating system can understand, transmitting it from the local process and address space to the remote process and address space, and reassembling and reenacting the call there. Return values have to be transmitted in the opposite direction. Android provides all the code to do that work, so that you can concentrate on defining and implementing the RPC interface itself.

An RPC interface can include only methods. All methods are executed synchronously (the local method blocks until the remote method finishes), even if there is no return value.

In brief, the mechanism works as follows: You'd begin by declaring the RPC interface you want to implement using a simple IDL (interface definition language). From that declaration, the aidl tool generates a Java interface definition that must be made available to both the local and the remote process. It contains two inner class, as shown in the following diagram:

The inner classes have all the code needed to administer remote procedure calls for the interface you declared with the IDL. Both inner classes implement the IBinder interface. One of them is used locally and internally by the system; the code you write can ignore it. The other, called Stub, extends the Binder class. In addition to internal code for effectuating the IPC calls, it contains declarations for the methods in the RPC interface you declared. You would subclass Stub to implement those methods, as indicated in the diagram.

Typically, the remote process would be managed by a service (because a service can inform the system about the process and its connections to other processes). It would have both the interface file generated by the aidl tool and the Stub subclass implementing the RPC methods. Clients of the service would have only the interface file generated by the aidl tool.

Here's how a connection between a service and its clients is set up:

  • Clients of the service (on the local side) would implement onServiceConnected() and onServiceDisconnected() methods so they can be notified when a successful connection to the remote service is established, and when it goes away. They would then call bindService() to set up the connection.

  • The service's onBind() method would be implemented to either accept or reject the connection, depending on the intent it receives (the intent passed to bindService()). If the connection is accepted, it returns an instance of the Stub subclass.

  • If the service accepts the connection, Android calls the client's onServiceConnected() method and passes it an IBinder object, a proxy for the Stub subclass managed by the service. Through the proxy, the client can make calls on the remote service.

This brief description omits some details of the RPC mechanism. For more information, see Designing a Remote Interface Using AIDL and the IBinder class description.

1.4Thread-safe methods

In a few contexts, the methods you implement may be called from more than one thread, and therefore must be written to be thread-safe.

This is primarily true for methods that can be called remotely — as in the RPC mechanism discussed in the previous section. When a call on a method implemented in an IBinder object originates in the same process as the IBinder, the method is executed in the caller's thread. However, when the call originates in another process, the method is executed in a thread chosen from a pool of threads that Android maintains in the same process as the IBinder; it's not executed in the main thread of the process. For example, whereas a service's onBind() method would be called from the main thread of the service's process, methods implemented in the object that onBind() returns (for example, a Stub subclass that implements RPC methods) would be called from threads in the pool. Since services can have more than one client, more than one pool thread can engage the same IBinder method at the same time. IBinder methods must, therefore, be implemented to be thread-safe.

Similarly, a content provider can receive data requests that originate in other processes. Although the ContentResolver and ContentProvider classes hide the details of how the interprocess communication is managed, ContentProvider methods that respond to those requests — the methods query(), insert(), delete(), update(), and getType() — are called from a pool of threads in the content provider's process, not the main thread of the process. Since these methods may be called from any number of threads at the same time, they too must be implemented to be thread-safe

Stocarea Datelor

A typical desktop operating system provides a common file system that any application can use to store files that can be read by other applications (perhaps with some access control settings). Android uses a different system: On Android, all application data (including files) are private to that application.

However, Android also provides a standard way for an application to expose its private data to other applications — through content providers. A content provider is an optional component of an application that exposes read/write access to the application's data, subject to whatever restrictions it might impose. Content providers implement a standard syntax for requesting and modifying data, and a standard mechanism for reading the returned data. Android supplies a number of content providers for standard data types, such as image, audio, and video files and personal contact information. For more information on using content providers, see a separate document, Content Providers.

Whether or not you want to export your application's data to others, you need a way to store it. Android provides the following four mechanisms for storing and retrieving data: Preferences, Files, Databases, and Network.


Preferences is a lightweight mechanism to store and retrieve key-value pairs of primitive data types. It is typically used to store application preferences, such as a default greeting or a text font to be loaded whenever the application is started. Call Context.getSharedPreferences() to read and write values. Assign a name to your set of preferences if you want to share them with other components in the same application, or use Activity.getPreferences() with no name to keep them private to the calling activity. You cannot share preferences across applications (except by using a content provider).

Here is an example of setting user preferences for silent keypress mode for a calculator:

import android.content.SharedPreferences;

public class Calc extends Activity {

public static final String PREFS_NAME = "MyPrefsFile";
    . . .      


    protected void onCreate(Bundle state){        
    . . .
       // Restore preferences
       SharedPreferences settings = getSharedPreferences(PREFS_NAME, 0);
       boolean silent = settings.getBoolean("silentMode", false);
    protected void onStop(){
      // Save user preferences. We need an Editor object to
      // make changes. All objects are from android.context.Context
      SharedPreferences settings = getSharedPreferences(PREFS_NAME, 0);
      SharedPreferences.Editor editor = settings.edit();
      editor.putBoolean("silentMode", mSilentMode);

      // Don't forget to commit your edits!!!



You can store files directly on the mobile device or on a removable storage medium. By default, other applications cannot access these files.

To read data from a file, call Context.openFileInput() and pass it the local name and path of the file. It returns a standard Java FileInputStream object. To write to a file, call Context.openFileOutput() with the name and path. It returns a FileOutputStream object. Calling these methods with name and path strings from another application will not work; you can only access local files.

If you have a static file to package with your application at compile time, you can save the file in your project in res/raw/myDataFile, and then open it with Resources.openRawResource (R.raw.myDataFile). It returns an InputStream object that you can use to read from the file.

1.7Baze de date

The Android API contains support for creating and using SQLite databases. Each database is private to the application that creates it.

The SQLiteDatabase object represents a database and has methods for interacting with it — making queries and managing the data. To create the database, call SQLiteDatabase.create() and also subclass SQLiteOpenHelper.

As part of its support for the SQLite database system, Android exposes database management functions that let you store complex collections of data wrapped into useful objects. For example, Android defines a data type for contact information; it consists of many fields including a first and last name (strings), an address and phone numbers (also strings), a photo (bitmap image), and much other information describing a person.

Android ships with the sqlite3 database tool, which enables you to browse table contents, run SQL commands, and perform other useful functions on SQLite databases. See Examine databases (sqlite3) to learn how to run this program.

All databases, SQLite and others, are stored on the device in /data/data/package_name/databases.

Discussion of how many tables to create, what fields they contain, and how they are linked, is beyond the scope of this note, but Android does not impose any limitations beyond the standard SQLite concepts. We do recommend including an autoincrement value key field that can be used as a unique ID to quickly find a record. This is not required for private data, but if you implement a content provider, you must include such a unique ID field. See the Content Providers document for more information on this field and the NotePadProvider class in the NotePad sample code for an example of creating and populating a new database. Any databases you create will be accessible by name to any other class in the application, but not outside the application.


You can also use the network to store and retrieve data (when it's available). To do network operations, use the classes in the following packages:



Evolutie – 1.5(Cupcake), 1.6 (Donut), 2.0(Eclair)

Android has seen a number of updates since its original release. These updates to the base Operating System typically fix bugs and add new features.

1.5 (Cupcake)

On 30 April 2009, the official 1.5 (Cupcake) update for Android was released.[24][25] There are several new features and UI updates included in the 1.5 update:

  • Ability to record and watch videos with the camcorder mode

  • Uploading videos to YouTube and pictures to Picasa directly from the phone

  • A new soft keyboard with an "Autocomplete" feature

  • Bluetooth A2DP support (which in turn broke Bluetooth connectivity with many popular cars and headsets. This has still yet to be fixed as of Dec-09)

  • Ability to automatically connect to a Bluetooth headset within a certain distance

  • New widgets and folders that can populate the desktop

  • Animations between screens

  • Expanded ability of Copy and paste to include web pages[26]

1.6 (Donut)

On 15 September 2009, the 1.6 (Donut) SDK was released.[27][28] Included in the update are:

  • An improved Android Market experience.

  • An integrated camera, camcorder, and gallery interface.

  • Gallery now enables users to select multiple photos for deletion.

  • Updated Voice Search, with faster response and deeper integration with native applications, including the ability to dial contacts.

  • Updated search experience to allow searching bookmarks, history, contacts, and the web from the home screen.

  • Updated Technology support for CDMA/EVDO, 802.1x VPN, Gestures, and a Text-to-speech engine

  • Speed improvements for searching, the camera.[29]

2.0 (Eclair)

On 26 October 2009 the 2.0 (Eclair) SDK was released.[30] Among the changes are:[31]

  • Optimized hardware speed

  • Support for more screen sizes and resolutions

  • Revamped UI

  • New browser UI and HTML5 support

  • New contact lists

  • Better white/black ratio for backgrounds

  • Improved Google Maps 3.1.2

  • Microsoft Exchange support

  • Built in flash support for Camera

  • Digital Zoom

  • Improved virtual keyboard

  • Bluetooth 2.1

Hardware running Android

The first phone to run the Android operating system was the HTC Dream, released on 22 October 2008.[39]

By the end of 2009 there will be at least 18 phone models using Android worldwide, according to Google.[40] In addition to the mobile devices that ship with Android, some users have been able (with some amount of hacking, and with limited functionality) to install it on mobile devices shipped with other operating systems.[41]

Dezvoltarea Software

The early feedback on developing applications for the Android platform was mixed.[42] Issues cited include bugs, lack of documentation, inadequate QA infrastructure, and no public issue-tracking system. (Google announced an issue tracker on 18 January 2008.)[43] In December 2007, MergeLab mobile startup founder Adam MacBeth stated, "Functionality is not there, is poorly documented or just doesn't work... It's clearly not ready for prime time."[44] Despite this, Android-targeted applications began to appear the week after the platform was announced. The first publicly available application was the Snake game.[45][46] The Android Dev Phone is a SIM-unlocked and hardware-unlocked device that is designed for advanced developers. While developers can use regular consumer devices purchased at retail to test and use their apps, some developers may choose not to use a retail device, preferring an unlocked or no-contract device.

[edit] Software development kit

The Android SDK includes a comprehensive set of development tools.[47] These include a debugger, libraries, a handset emulator (based on QEMU), documentation, sample code, and tutorials. Currently supported development platforms include x86-architecture computers running Linux (any modern desktop Linux distribution), Mac OS X 10.4.8 or later, Windows XP or Vista. Requirements also include Java Development Kit, Apache Ant, and Python 2.2 or later. The officially supported integrated development environment (IDE) is Eclipse (3.2 or later) using the Android Development Tools (ADT) Plugin, though developers may use any text editor to edit Java and XML files then use command line tools to create, build and debug Android applications as well as control attached Android devices (e.g., triggering a reboot, installing software package(s) remotely).[48]

A preview release of the Android software development kit (SDK) was released on 12 November 2007. On 15 July 2008, the Android Developer Challenge Team accidentally sent an email to all entrants in the Android Developer Challenge announcing that a new release of the SDK was available in a "private" download area. The email was intended for winners of the first round of the Android Developer Challenge. The revelation that Google was supplying new SDK releases to some developers and not others (and keeping this arrangement private) has led to widely reported frustration within the Android developer community.[49]

On 18 August 2008 the Android 0.9 SDK beta was released. This release provides an updated and extended API, improved development tools and an updated design for the home screen. Detailed instructions[50] for upgrading are available to those already working with an earlier release. On 23 September 2008 the Android 1.0 SDK (Release 1) was released.[51] According to the release notes, it included "mainly bug fixes, although some smaller features were added". It also included several API changes from the 0.9 version.

On 9 March 2009, Google released version 1.1 for the Android dev phone. While there are a few aesthetic updates, a few crucial updates include support for "search by voice, priced apps, alarm clock fixes, sending gmail freeze fix, fixes mail notifications and refreshing intervals, and now the maps show business reviews". Another important update is that Dev phones can now access paid apps and developers can now see them on the Android Market.[52]

In the middle of May 2009, Google released version 1.5 (Cupcake) of the Android OS and SDK. This update included many new features including video recording, support for the stereo bluetooth profile, a customizable onscreen keyboard system and voice recognition. This release also opened up the AppWidget framework to third party developers allowing anyone to create their own home screen widgets.[53]

In September 2009 the "Donut" version (1.6) was released which featured better search, battery usage indicator and VPN control applet. New platform technologies included Text to Speech engine (not available on all phones), Gestures & Accessibility framework.[54]

Android Applications are packaged in .apk format and stored under /data/app folder on the Android OS. The user can run the command adb root to access this folder as only the root has permissions to access this folder.

[edit] Android Developer Challenge

The Android Developer Challenge was a competition for the most innovative application for Android. Google offered prizes totaling 10 million US dollars, distributed between ADC I and ADC II.[55][56] ADC I accepted submissions from 2 January to 14 April 2008. The 50 most promising entries, announced on 12 May 2008, each received a $25,000 award to fund further development.[57][58] It ended in early September with the announcement of ten teams that received $275,000 each, and ten teams that received $100,000 each.[59] ADC II was announced on 27 May 2009.[55] The first round of the ADC II closed on 6 October 2009.[60] The first-round winners of ADC II comprising the top 200 applications were announced on 5 November 2009. Voting for the second round also opened on the same day and ended on November 25. Google is reviewing the final results and will announce the top winners on November 30.[61][dated info]

[edit] Google applications

Google has also participated in the Android Market by offering several applications for its services. These applications include Google Voice for the Google Voice service, Scoreboard for following sports, Sky Map for watching stars, Finance for their finance service, Maps Editor for their MyMaps service, Places Directory for their Local Search, Google Goggles that searchs by image, and My Tracks, a jogging application. Android phones that include the 'Google Experience' also have Google Search, Google Calendar, Google Maps, Google Navigation and Gmail integrated.

[edit] Native code

Libraries written in C and other languages can be compiled to ARM native code and installed using the Android Native Development Kit. Native classes can be called from Java code running under the Dalvik VM using the System.loadLibrary call, which is part of the standard Android Java classes.[62][63]

Complete applications can be compiled and installed using traditional development tools.[64] The ADB debugger gives a root shell under the Android Emulator which allows native ARM code to be uploaded and executed. ARM code can be compiled using GCC on a standard PC.[64] Running native code is complicated by the fact that Android uses a non-standard C library (known as Bionic). The underlying graphics device is available as a framebuffer at /dev/graphics/fb0.[65] The graphics library that Android uses to arbitrate and control access to this device is called the Skia Graphics Library (SGL), and it has been released under an open source license.[66] Skia has backends for both win32 and Cairo, allowing the development of cross-platform applications, and it is the graphics engine underlying the Google Chrome web browser.[67]

Elements Interactive Mobile B.V. have ported their EdgeLib C++ library to Android, and native code executables of their S-Tris2 game (a Tetris clone) and Animate3D technology demo are available for download.[68]

[edit] Community-based firmware

There is a thriving community of open-source enthusiasts that build and share Android-based firmware with a number of customizations and additional features, such as FLAC lossless audio support and the ability to store downloaded apps on the microSD card.[69]

Those firmware packages are updated frequently, incorporate elements of Android functionality that haven't yet been officially released within a carrier-sanctioned firmware, and tend not to have arbitrary limitations. CyanogenMod is one such firmware.

On 24 September 2009, Google issued a cease and desist letter[70] to the modder Cyanogen, citing issues with the re-distribution of Google's closed-source applications[71] within the custom firmware. Even though Android OS is open source, phones come packaged with closed-source Google applications for functionality such as the application store and GPS navigation. Google has asserted that these apps can only be provided through approved distribution channels by licensed distributors. Cyanogen has complied with Google's wishes and is continuing to distribute his mod without the proprietary software. He has provided a method to back up licensed Google applications during the mod's install process and restore them when it is complete.[72]

Android vs. iPhone 3.0

Apple's releasing some hot new features in iPhone 3.0 this summer, but will it be better than Google's Android? Let's take a look.

You already know what you get in iPhone 2.0, you've heard about what you get in iPhone 3.0. Let's see how those features stack up against Android's current release and its upcoming update (called "Cupcake") feature by feature.

The Breakdown

There's a whole lot of green in the iPhone 3.0 column of that chart above, and some red and yellow in the Android side. That's mostly because we're comparing Android to the feature set Apple unveiled yesterday; it doesn't mean that new smartphone buyers stuck between iPhone and Android should automatically wait for iPhone 3.0. It all depends on what you need.

The phone features that actually matter to you: While much has been made of cut/copy and paste coming to iPhone 3.0, many smartphone users say they haven't run into many situations where they needed it. The feature that's getting less press but may add more usefulness to iPhone 3.0 is search: with Spotlight, and within Mail, Contacts, and Calendar.

Personally, besides its Gmail client, the feature I love most about Android that the iPhone doesn't come close to is Android's pull-down "window shade" notification area, that lists multiple alerts. So if you've gotten an SMS, new email, a Twitter reply, a missed call, you can drag and drop the window shade down to see them all. (See screenshot.) The iPhone still pops up a box you have to dismiss to do anything else (include hang up a call!), which is simply an inferior way to handle alerts.

Background processes versus push notifications: While it's wonderful in theory that Android runs background processes, Apple's point about how it kills your battery life is absolutely true in my experience. It remains to be seen how well iPhone 3.0's push notifications will work when they actually do come out (hence the yellow coloring in the table), but right now, the battery life point is not just a bunch of marketing hooha (which is why it got the yellow coloring in the table, too). Besides, Apple has promised and not delivered push notifications before, so we'll believe this one when we see it.

iPhone 3.0's application potential: The other big "remains to be seen" part of iPhone 3.0 is where developers will take the new functionality available to them in iPhone 3.0. Voice over IP, maps integration, peer-to-peer Bluetooth, media access, accessory-specific apps—these are really exciting options for application developers that will surely bloom into a million great apps and functionality that haven't been born yet.

When you're in control of the hardware: When two different pieces of software are competing, it's pretty easy to for one to respond to another feature by feature, and we expect Android will offer similar features as iPhone 3.0 eventually. But when you're in control of the hardware like Apple is, you can do things like enable accessory support—which means, for example, that diabetics can plug their glucose meter into the iPhone and download readings. Since Google's Android is just the operating system that will run on various handsets with different hardware configurations, that sort of software-to-hardware control will not be as easy.

But given what we know now... As a former iPhone user who switched to Android, I can say: iPhone 3.0 hasn't made me regret my decision. Yet. Right now, Android's killer Gmail client, proper MMS support (available now), background processes (even though they kill the battery), window shade, and general Google product integration makes me a happy camper. In fact, on the chart above, the top five items are the features most important to me, and Android—right now, not this summer—hits on almost all of them.

That said, given the potential of iPhone 3.0, gamers, audiophiles, and others may disagree. What about you?


Download 101.36 Kb.

Share with your friends:

The database is protected by copyright © 2022
send message

    Main page