Google’s Android Versus Apple’s iOS: And The Winner Is?
Apple’s iPhone
Motorola’s Droid 2
Apple’s iPad
Archos 10 Android tablet
Standard interfaces
Android’s software framework
MeeGo’s architecture
Apple’s iPhone (Fig. 1) made touch and small apps a way of life. Google’s Android has followed suit, providing similar features and performance in an ever-expanding collection of smart phones starting with the Motorola Droid (Fig. 2). Now, Android is under the auspices of the Open Handset Alliance (OHA).
Apple’s iPad (Fig. 3) raised the ante (see “Success Of iPad Is All About Software”). The iPad is not the first tablet PC, but it is by far the most successful (see “With iPad Sales Soaring, Are Netbooks Dead?” Oct. 21).
The iPad’s hardware differs a bit from the iPhone (see “Inside The Apple iPad”). But the underlying software allows applications to run on the iPad as well as the iPhone. Most users get their applications for the iPad and iPhone from Apple’s App Store.
Android users get most of their applications from the Android Marketplace. These users are almost exclusively using Andriod-based smart phones, since they were Android’s initial target. Many companies are looking to take Android to other places as well, including the tablet arena. The Archos 10 Android-based tablet is just one of an expected flood of Android tablets (Fig. 4) expected to hit the market.
The key to success for the iPhone, iPad, and Android smart phones has been the plethora of applications provided by third parties. The underlying operating system, programming framework, and user interface have made these platforms easier to use. Likewise, high-resolution touchscreens and low-power, high-performance multicore processing platforms have delivered the responsiveness needed for highly interactive, touch-based applications.
A typical Android hardware platform (Fig. 5) contains a myriad of interfaces that would have brought a desktop to its knees a decade ago if all the interfaces were in play at the same time. These days, the 3D accelerometers track the movement of the device while the camera is recording and so on. Making this hardware easy to program is the chore of the programming frameworks that are now standard software components.
Touchy Programming Frameworks
Granted, touch interfaces are only part of the programming frameworks found on Apple’s platforms as well as Android platforms. But they also were included from the initial design, not dropped on top of an existing framework.
Apple’s iOS provides the operating system (OS) and the Cocoa-Touch framework for Apple developers. The framework is based on the Mac OS’s Cocoa application programming interface (API). It uses the Model-View-Controller (MVC) architecture.
SQLite is part of the mix, although there is a Core Data store that also can be used to save information. Other major components include items like Core Data, Core Audio, OpenAL, Media Library, and WebKit. Some video components include Core Animation, OpenGL ES, and Quartz 2D.
The native programming language is Objective-C, an object-oriented extension and superset of C. Objective-C is quite different from C++, which many developers are familiar with. Objective-C uses Smalltalk-style message passing, which makes it possible to forward messages.
Continue on next page
Apple’s software development kit (SDK) can handle iPhone and iPad apps. It includes tools like Interface Builder, a graphical editor for creating the user interface of an application.
The Android software framework (Fig. 6) runs on Linux and the Dalvik Java virtual machine (JVM). The Dalvik source code is licensed via the Apache license, which tends to be more amenable to many organizations since changes do not have to be made public as with GPL (General Public License). Android applications are written in Java that runs on Dalvik.
Dalvik is a JVM optimized for mobile devices. There has been much debate about whether the Davlik register-based approach (Fig. 7) is better than the typical stack-based JVM, but it is the platform if Andriod is a requirement.
Also, Dalvik takes a virtual approach to its register file with 64k 32-bit registers, though a small subset is likely to be utilized from an execution standpoint. Java essentially hides the underlying implementation, yet it is still interesting to look under the hood.
Dalvik uses byte codes, but the encoding scheme is different from Sun’s Java specification. Like many physical register-based architectures, Dalvik’s instruction encoding provides access to a limited number of registers based on the instruction being used.
As a result, shorted instructions can access a few registers while providing access to more registers at the cost of longer instructions or indirect access. The theory is that Dalvik’s instruction mapping to an actual processor can be more efficient than the stack-based approach.
Sun has always had a problem differentiating Java the language from Java the platform. Java editions like J2SE (Java 2 Standard Edition) and J2EE (Java 2 Enterprise Edition) were designed to define a framework of libraries. In a sense, Android is comparable to these editions, though Android changes more than just the libraries involved.
For example, Android uses DEX files instead of JAR files. Functionally, the two are identical defining Java classes. It is even possible to translate files between formats. However, differences limit the quality of this translation. Isolated classes can be transcribed, but typically applications depend on a host of base libraries, making application movement between platforms more problematic.
Android essentially defines a collection of core and standard libraries that applications can count on. But Android designers did not start from scratch with all their libraries. In fact, standards provide the basis for many of the libraries.
For example, 2D graphics are custom but 3D graphics are based on the OpenGL ES 1.0 specification, making hardware acceleration easier to provide. Likewise, SQLite provides structured data storage. Developers familiar with SQL will find Android very comfortable.
The integrated browser support is based on the open-source WebKit engine. In addition, the multimedia support uses common audio, video, and still image formats like H.264, MP3, MPEG4, AAC, AMR, GIF, PNG, and JPG.
Android has a communication-rich set of libraries. These libraries address telephony and networking support that often incorporates Wi-Fi, Bluetooth, GSM, EDGE, and 3G. Other libraries handle hardware devices such as cameras, GPS, accelerometers, and compasses.
Android is a multitasking framework. Each process runs in a virtual machine that is implemented via a Linux process. Also, developers new to Android will need to understand how to use and create activities, intents, services, content providers, and broadcast receivers. Activities present an application’s visual interface. An application may present more than one activity.
Continue on next page
An intent is an asynchronous message that is used to activate an activity. Intents can also start services and broadcast receivers. Intent filters match intents to a particular object.
Most intent filters are declared in the AndroidManifest.xml file used to define an application. Unlike activities, services do not have a visual interface but run in the background to perform an operation like audio playback.
An application may also contain any number of broadcast receivers, which are designed to receive intents such as status change messages. For example, an application may have a broadcast receiver that detects a low-battery state. Like services, a broadcast receiver does not have a user interface (UI) but it can initiate an activity.
Content providers handle data storage for applications. A content provider might use the SQLite support for storage. It could also use other storage mechanisms, even working with a remote database via a network link. Applications interact with content providers by using a content resolver object. A content resolver can work with any content provider.
Android applications also have resources associated with the application like most applications have on other platforms such as Apple’s Mac OS and Microsoft’s Windows. A resource can be data that an application can utilize like an image or even text. Development tools can manipulate resources, allowing an application to be customized without code modifications.
Android handles a number of operations automatically. It may start an application if it is needed by another application. Developers need to understand how all these components work and interact to create Android applications.
Embedded Android
Apple’s solution is to deliver hardware and software. This isn’t bad for application developers who want to write for the iPad or iPhone, but it does little for companies that want to build connected embedded devices. Android isn’t as limited by the underlying hardware, which is why it’s finding a home in places other than smart phones and tablets.
Part of the challenge is determining what Android is and how much morphing can be accomplished while retaining useful infrastructure and peripheral support. For instance, GPS location is useful in a mobile device but less useful in a device that will be at a fixed location. The two may share a common display and touch interface, though, and that can be important as switches and buttons move to flat panels and touch interfaces.
Of course, embedded developers know that nothing comes for free. Android customization for a particular hardware platform is more complex than the typical board support package (BSP) for a new piece of hardware.
Software vendors like Mentor Graphics and Wind River can help developers target new hardware platforms with Android. This level of support is important because successful Android support spans the hardware as well as tool suites used for system and application development.
The Mentor Graphics Mentor Embedded ReadyStart platform provides not only system support but also toolset and integrated software. In addition to Android Services, Mentor provides Inflexion UI for Android, which helps deliver 3D effects and rapid UI development. The Inflexion Plug-in for Eclipse can automatically generate Android activity and framework class source code.
Contine on next page
Arm platforms have been very popular for Android, although it is not a requirement. The Arm Solution Center for Android (SCA) is a central Web resource that highlights the Arm/Android community.
Not to be outdone, MIPS Technologies has released Android source code for MIPS platforms. The MIPS architecture actually melds well with the Dalvik virtual machine. It pushes the Android envelope with items like the first LTE Protocol Stack for Android done in conjunction with SysDSoft. It even has symmetrical multiprocessing (SMP) support for Android on MIPS32 platforms as well as graphics hardware acceleration intellectual property (IP).
Other Alternatives
Apple’s iOS and Google’s Android are just two of the many platforms in the mobile space. It is unlikely that iOS will be found on non-Apple platforms, though Apple TV is another consumer product that employs Apple’s technology.
Android is likely to bump into the Linux-based MeeGo and Microsoft Windows Phone 7 platforms (see “Microsoft Starts Over With Windows Phone 7”). Microsoft Windows Phone 7 is a smart-phone platform where the current crop of Android smart phones also resides.
Microsoft’s platform has a comparable framework found on its higher-end systems including the use of the .NET framework. Windows Phone 7 adds the touch interface support, but it did not have to create new display support.
Likewise, features like LINQ (language-integrated query) support is part of the existing Windows framework. The various flavors of Microsoft Windows also target application areas other than smart phones and tablets.
MeeGo is an interesting alternative that Android is likely to encounter in a range of non-smart-phone embedded applications like set-top boxes and smart TVs. Open-source and based on Linux, MeeGo originally targeted Intel’s Atom processor, but the framework is more general. Given the wide range of platforms that support Linux, MeeGo likely will wind up on some of these targets. MeeGo targets applications from netbooks to in-vehicle entertainment to media phones and connected TV.
Of all of these platforms, MeeGo tends to be the most conventional. Its architecture includes services similar to those found on other platforms like Android, including Comms Services, Internet Services, Visual Services, Media Services, and Data Management support (Fig. 7).
In a sense, MeeGo moves the application closer to the hardware. Applications can be written in any language that targets Linux. These aspects can be an advantage as well as a disadvantage.
MeeGo incorporates a range of patches to the standard Linux platform. These patches show up in areas like the kernel, the Linux core functionality, and the X Windows display subsystem.
The MeeGo effort consists of a large number of projects, such as MeeGo Multimedia, MeeGo Bluetooth, MeeGo Cellular, and MeeGo Security Framework. There is even a MeeGo Developer Tools project that addresses developer tools and utilities.
In theory, application distribution services for MeeGo—MeeGo Software, which is comparable to the Apple AppStore and Android Market Place—will target specific implementations. MeeGo essentially limits itself to x86 microprocessors, so most users will likely have a similar user experience for choosing and installing applications. Linux OS vendors like Wind River support MeeGo.
Continue on next page
Like Microsoft Windows Phone 7, MeeGo will be more familiar to developers who are familiar with Linux and Windows, respectively. The toolsets remain the same. The differences tend to be minor and related to some libraries or services that are specific to the target environments. Look for both on tablets.
To Sue Or Compete
Apple has its hardware and software under one roof, but that doesn’t make it immune from outside legal attacks. Likewise, Android is in a state of flux as the giants like Oracle, Google, and Microsoft battle in legal courts and the court of public opinion.
Oracle isn’t keen on Google’s Dalvik implementation, and it is suing over Java. Evidently using a completely different JVM, runtime, and class system is not enough. Android uses the Java language—and only the syntax and semantics.
Lawyers are unlikely to stop challenging any of these platforms. Hopefully, platform popularity will be based on functionality and availability, not on whether it survives a lawsuit.
The winner of any comparison between Android and iOS is essentially the user. Developers will have to choose based on their application, marketing, and a host of other issues unrelated to the architecture.
The two platforms differ enough that writing to a common specification will be daunting and limiting, but the underlying frameworks will make such a task significantly easier.
