A Spectrum White Paper: Thoughts on Google Android

of 17

A Spectrum White Paper: Thoughts on Google Android

February 2008

spectrum data technologies

of 17 Spectrum Data Technologies, 2008

Contents 1.1.1 The Red Layer ....................................................................................................................................3

1.1.2 The Green Layer................................................................................................................................4

1.1.2.1 Open Source Libraries shipped standard with Android ............................................4 1.1.2.2 The Android Runtime .............................................................................................................4

1.1.2.2.1 Available Java API Packages .............................................................................................4

1.1.2.2.2 The Dalvik Virtual Machine...............................................................................................5

1.1.3 The Blue Layer (Application Frameworks) .............................................................................5

1.1.4 The Blue Layer (Applications) ......................................................................................................6

3.0 Sample Architecture for Secure data storage with Google Android ........................................8

5.0 Are all Applications Created Equal?................................................................................................... 12

6.0 Stability of the Current Android SDK ................................................................................................ 12

7.0 Tradeoffs...................................................................................................................................................... 13

Works Cited......................................................................................................................................................... 15



1.1 Google Android Google Android is a new mobile handset platform based on Linux, Apache Harmony1 and a proprietary, for the moment at least2, custom virtual machine named Dalvik.

Figure 1 Overview of the Android Application Stack3

1.1.1 The Red Layer The red layer from figure 1 represents the services offered by the Linux kernel and associated GNU utility packages ported to the ARM4 architecture. These components are licensed under the GNU General Public License, the GPL5, or the GNU Lesser General Public License, the LGPL6. Being subject to the GNU GPL and LGPL licenses, these components are licensed with all source code included. Furthermore, due to the viral nature of the GPL license, any modification to this layer or derived work must be distributed as source to any 3rd parties using the same licensing terms. The GNU/Linux ARM port is mature, stable, and used in many embedded projects both in and outside of Google7.



1.1.2 The Green Layer The green layer consists entirely of open source libraries available under various licenses. Some of the libraries come from the GNU project8 itself. The licenses here vary from the LGPL, BSD9, MIT10 and are completely in the public domain11 in the case of the SQLite12 database. However, even if the licenses of some of the components found in this layer are more permissive and could allow a hardware vendor for customizations not found in other Android handsets, Google has created the Open Handset Alliance13 that owns the Android trademark. As part of this effort, any phone that wishes to be branded as an Android handset must meet the non-fragmentation rule14. As such, any phone that would customize the libraries found in this layer, add libraries or remove them altogether would no longer be able to brand itself as an Android phone. Furthermore, under this same pledge, its license to the proprietary Dalvik virtual machine found at the core of the Android platform would be considered null and void.

1.1.2.1 Open Source Libraries shipped standard with Android Notable software included in this layer, but not limited to, are:

1. Webkit15. The Web browser engine found at the heart of the Apple Safari16, iPhone17 and Konqueror18 web browsers. Providing an Acid219 compliant web browser featuring HTML 4, JavaScript and CSS. This browser is now also used on high end Nokia phones20.

2. SQLite. This database is the de facto database for embedded products and is now most likely the most widely used database in the world21. It is incredibly small; the library fits comfortably in less than 500KB on disk and yet offers most features found in the SQL-9222 standard.

3. OpenSSL23. The SSL/TLS24 security library used in all Mozilla25 based products, Apple Mac OS X26, Linux27 and many commercial UNIX28 operating systems.

4. OpenGL ES29. OpenGL is a 3D graphics library used by many games, operating systems and applications to achieve high performance 3D graphics. Android’s use of such a library allows application providers to tap into a well-known pool of experts on this technology. OpenGL ES is the embedded version of the OpenGL library and features a subset of the OpenGL API. Additional functionality specific to low powered environments such as phones is also provided by the ES variant of OpenGL.

1.1.2.2 The Android Runtime Also found in the green layer of the Android application stack are the Dalvik virtual machine and the core Java libraries that are used to run and create applications respectively.

1.1.2.2.1 Available Java API Packages The core Java packages that are used to create applications come from two different sources:

1. Google Android specific packages. These packages were created by Google for its Android initiative. They are currently closed source, but Google has committed to making these packages Open Source30. The



packages range from user interface construction to hardware specific functions such as camera control, Bluetooth support, and location services.

2. Java packages that are part of the Java SE 5 specification, these packages

represent the bulk of the Android SDK. In other words, regular Java SE 5 developers can leverage their existing skills to write Android applications. Google obtained these packages from the Apache Harmony project. As such, these packages are licensed under the Apache Software Foundation License version 231. This license is one of the most liberal available today. Companies can use, modify, and commercially exploit code under this license without the need to re-contribute changes back to the original source or any 3rd parties. However, the Android pledge from the Open Handset Alliance still applies at this layer of the software stack meaning that any changes here will disallow the use of the Android brand and Dalvik virtual machine. That being said, not all existing Java SE 5 knowledge applies. The user interface toolkits from Java SE i.e., Swing32 and AWT33, have been stripped in favor of an Android only specific toolkit.

1.1.2.2.2 The Dalvik Virtual Machine The Dalvik virtual machine is an interpreter only machine optimized for use on low powered, low memory devices like phones. Notably, Dalvik does not make use of just in time (JIT) compilation to improve the performance of an application at runtime. Furthermore, Dalvik is not a Java virtual machine. This is because Dalvik is unable to read Java bytecode34, instead it uses its own bytecode format called “dex”. Google claims this format allows battery power to be better-conserved at all different stages of execution of an application. This means that standard Java SE applications and libraries cannot be used directly on the Android Dalvik virtual machine. Dalvik however stands at the center of the Android value proposition. Its low electrical power consumption, rich libraries, and unified, non-fragmented application programming interfaces make it stand out, or so Google hopes, over the fragmented ecosystem that is Java ME35 today. Furthermore, since Dalvik uses the Java programming language but not the Java execution environment (JVM), Google is free to develop Android without the need to license or obtain certification from Sun Microsystems Inc, the legal owner of the Java trademark and brands.

1.1.3 The Blue Layer (Application Frameworks) In this layer, the application developer has access to what Android refers to as “service” processes. These services are invisible to the user of the handset. Application developers can communicate with these services via a message bus. For example, a contact application might instigate a phone call at the behest of a user request by calling on the services of the telephony manager.



All code found in this section is currently closed source, is written in Java specifically for the Dalvik virtual machine. It is not yet clear under what license these modules will be made available in the future.

1.1.4 The Blue Layer (Applications) These are all the applications hosted on the handset. Google or any other 3rd party may have written these applications. Unlike other phone platforms, Android has support for applications that do not have a user interface. The main application types are:

i. User interface applications. Consisting of views that know how to draw themselves on screen.

ii. Intent listeners. Intents are messages that are carried over the message bus of the handset. This allows for different applications on the phone to talk to each other.

iii. Services. Similar to Windows services or UNIX daemon processes. A body of code that runs in the background. The application runs without a user interface but may be essential to an application that does have a user interface.

iv. Content providers. A data storehouse that provides access to data on the device. On Android, unlike all other mobile platforms, all data and files that are created by an application are invisible to all other installed applications. In order to make data visible to other applications, the application or service must make the data available via content providers. Alternatively, an application may only interact with a content provider for its data needs and forego the creation of data and files completely. Unlike other platforms, Android already has a generic, standard way of accessing data in a uniform and standard fashion.

1.2 Security Model The security model in Android is considerably more locked down than other handset platforms. Each application runs in its own instance of the Dalvik virtual machine. Each instance of the Dalvik virtual machine represents a Linux kernel process; hence each instance is completely isolated from the other memory wise. As such it is not possible for an application to steal information from another running application. Files and data held by an application are completely isolated from all other applications. This is enforced by the system by the use of the Linux kernel and traditional UNIX file permissions. For applications to access data from another application, it must first be exposed via a content provider and accessed by the message bus by sending “intents” between the two applications. That being said, it’s still necessary to be careful when handling sensitive data. Memory that was allocated to a now defunct process is not zeroed out. The old tried and true technique of allocating memory only to observe its contents for sensitive information, could still be used by a potential hacker to break into a secure content provider service.



2.0 Sample Architecture for Android within a Federated SSO System

Figure 2 Android and a potential use of single sign on

Using figure 2, we have the following workflow:

1. Login to the local service data storehouse located directly on the phone. 2. This is an Android service application. The application was deployed with the SSL

certificate of the SSO36 service. 3. Using mutual key authentication37. The user’s credentials are validated. Upon

successful login, a SSO token of at least 64 bit in length is returned to the local Android storage service.

4. The user facing application requests data from the local storehouse. 5. If the data is cached locally, it is returned immediately; otherwise, it is requested

from web services. The username and password of the user are not sent to the web service. Instead the SSO token is sent to the web service.

6. The web service requests authorization for the requested operation by the handset using the SSO token.

7. Data is returned to the Android local storehouse service from the web service if the SSO token was valid.

8. The data could be saved locally here.

Return the data to user facing application using the local data storehouse. To make the role of the SSO system clear, some aspects of the architecture were omitted for brevity. We will further expand on this architecture in section 3 of this paper. The main limitations of the current architecture presented here is that the local data storehouse does not validate the SSO token with the SSO service nor does it encrypt the data locally. Furthermore, the username and password is sent over the network to the SSO service. This can also be avoided.



3.0 Sample Architecture for Secure data storage with Google Android

Figure 3 Android and Secure Local Data Storage

We now present a secure data storage solution that could potentially be deployed on Android. It is based on the design presented in section 2 of this document. However, many shortcomings of the design have been addressed. Additional security highlights will be presented at the end of the section. Using figure 3, we have the following workflow:

1. The user enters his credentials on the handset. 2. The credentials are not sent to the SSO service over the network. Instead, the

credentials are used as the passphrase to decrypt the local public/private key pair of the user. We define the public/private key pair to be of type RSA and of at least 4096 bits in size. Already we gain the advantage that the user’s password is not sent over the network.

3. The private key is used to decrypt the symmetric cipher key. The symmetric cipher key is used to encrypt/decrypt any locally cached data. A strong symmetric cipher like 3DES is used.

4. All data found in the local cache is encrypted with the symmetric cipher key defined in step #3.

5. If the requested data is not locally cached or expired. We must communicate with the SSO service again to be able to receive fresh data from the Restful web services. However, unlike the architecture presented in section 2 of this document, we login to the SSO server using a hostile challenge based on the private key of the user. As such, we login with the SSO system using public/private key



infrastructure. The user name and the password are never sent over the network. The SSO system can identify the user based on this challenge and returns a 496 bit alpha numeric token.

6. The tokens generated by the SSO system are set to automatically expire after a given period of time.

7. On reception of the SSO token. The Android background application can now communicate with any Restful web services that adhere to the same SSO federation. Public/private key infrastructure is once again used to setup a secure communication channel between the phone and the server. The certificates of the servers that host the web services are procured from the same certificate authority that shipped with the phone.

8. On reception of a request, the SSO token is extracted from the request. The web service calls upon the SSO system to authorize the operation.

9. On reception of the data, the symmetric cipher described in bullet #3 above is used to encrypt the data before it reaches any local persistent storehouse.

10. Data is returned to the user facing application.

Additional security notes: 1. The public/private key pair of the user is generated directly on the handset at

install time. As such, the private key has never left the phone nor has it been transferred over any network.

2. The certificate of the user must at least be registered once in the SSO application. This could be done at install time of the handset application.

3. “Man-in-the-middle”38 attacks are not possible since the application is deployed with the CA certificate of the company that will be hosting the web services.

4. If the device is lost, all the locally cached data is completely unreadable. The symmetric key that encrypted this data is also unreadable. The public/private keys that are central to the security architecture are protected by a passphrase.

5. The passphrase is the weakest link in the chain. If the user enters an overly simple password, access could be gained to the private key and hence the locally cached data.

6. That being said, it would be possible to further extend this architecture to store the encrypted symmetric key on the server. This way, even if the passphrase of the private key is compromised, the locally cached data still cannot be accessed. This is because the encrypted strong symmetric cipher key is stored on the server. By the time the passphrase has been cracked, there has been ample time to report the stolen phone and revoke this key from this user account on the server. Furthermore, under this scheme, the key stored on the server is still encrypted. Even if this key is intercepted in transit it is useless without the user’s private key.

7. It is also possible to enforce a strong password policy directly from the handset application.



8. Even if this design is significantly more secure than the previous iteration, to the user, the experience is the same. The user must enter a username and password to prove his identify.

9. We could augment the architecture in yet another direction. The local caching system could also require an SSO token and subsequently request authorization from an SSO system. Such a design would prevent terminated employees, i.e., an individual who already knows what the local credentials are, from accessing the locally cached data.

4.0 Execution Environment

Figure 4 Regular Java Execution Process



Figure 5 Android Execution Environment

Figures 4 and 5 represent the regular Java and Android execution paths respectively. It is interesting to note here however is that the Android compilers do not operate on Java language code. Instead, the Android translators work on the resulting Java bytecode emitted from a traditional Java compiler. As such, it is possible to reuse existing Java libraries, even if the original source code is not available. Such libraries must meet stringent requirements however, they need to:

1. adhere to the Java SE 5 dialect 2. not use any Java classes or packages found in Java SE 5 not found in the Android

platform 3. not use any packages or classes specific to the Sun Microsystems platform 4. still behave in a predictable manner under the Apache Harmony Java environment

Following these guidelines, it’s possible to integrate existing Java source code, packages and libraries piecemeal. Special care will be needed in the integration phase of such code but the potential savings offered by such integration far outweighs the cost of rewriting well-coded,



well-documented and well-tested libraries ready for use. Furthermore, it is expected that has Apache Harmony matures, more and more compatibility issues will be resolved further increasing the pool of available Java code that will be able to execute unmodified under the Android platform.

5.0 Are all Applications Created Equal? One of the promises made by Google about its Android platform is that all applications are created equal, meaning that the user can replace bundled applications if he so desires with Google or non-Google alternatives. However, it’s certainly true that Google’s Android platform is more open than the traditional application environment usually found on mobiles today; but it is not a completely open platform. First and foremost, even if the majority of the Android application stack is written in C and C++, Google does not allow writing applications for Android in those languages. All applications written for Android by 3rd parties must be written for the Dalvik virtual machine. Currently, the only officially supported programming language is the Java SE 5 dialect. This also means that custom libraries written in the C or C++ language available for the Linux operating system cannot be deployed to an Android handset, such libraries can only be shipped as part of the base Android image which is under the complete control of Google. As a result, a huge number of already available, potentially useful libraries are cut off from the Android developer. Without such support, the openness of the platform is somewhat constrained. For example, in a traditional handset, it’s not possible to replace the web browser that ships with the phone. This is doable in theory under Android but considering that non-Dalvik libraries cannot be deployed to the handset, it is almost impossible to do so. A user could easily install an alternative web browser that uses the already present WebKit of the phone but could not deploy a Mozilla based browser solution for example. Providing a Mozilla based browser to the handset would require installing native Linux/ARM C++ libraries to the phone. To truly replace the default based WebKit browser would require a 100% Java/Dalvik solution, a massive investment to say the least. Replacing the browser with another one also founded on WebKit now becomes a purely cosmetic exercise. In summary, Google doesn’t impose any legal limits on the replacement of base applications but does however rely heavily on this limitation and simple economics to ensure that it will not be done in the field.

6.0 Stability of the Current Android SDK We would be remiss if we did not mention that Android is currently very much a work in progress. The first SDK39 released, version 0.3, had a large amount of bugs, missing documentation and odd behavior. The use of Apache Harmony as a core technology is also cause for some concern at this time. The Apache Harmony project has yet to release a stable release of their code. It is also hard to quantify exactly how stable, or unstable, Android is considering that Google didn’t host a public bug tracking system until very recently.



The initial public Android SDK was updated to version “m5” on February 13th 2008. The refreshed SDK features a large number of bug fixes... but also features many API changes. Such changes include the addition, renaming and removal of classes, methods, XML elements and packages thus invalidating all existing Android applications. Any Android application written for the 0.3 SDK will not be able to function without at least some modifications under the new “m5” SDK release.

7.0 Tradeoffs Arguably, the Android platform has many advantages over other mobile platforms, both in and out of the scope of security. There are also however, numerous shortcomings of the platform as it exists today.

1. The developer tooling available for Android today is limited to an officially supported module for the Eclipse40 IDE41 that offers very few features in terms of developer support.

2. There are currently no visual user interface designers for Android. As such, the upfront investment required to build a professional looking application is steeper than other platforms that offer such tools.

3. The use of Apache Harmony for the provision of all Java SE 5 packages included in Android is also a cause of concern. The Apache Software Foundation has been unable to acquire a license of the Java Compatibility Kit (JCK) under acceptable terms from Sun Microsystems42. As such, existing Java libraries used on Android may behave differently then when run under Sun’s Java environment. This difference in behaviour may prohibit a large number of libraries from working correctly under Android. Apache Harmony as yet to reach version 1 status and as such is very much a volatile target.

4. It is not yet clear how the Android platform will be upgraded to newer versions of the platform once deployed. In fact, at this time, it is not known if this facility will even be provided.

5. If the Android platform currently deployed on a handset is indeed updated, a large number of bug fixes in Apache Harmony might break existing applications that have been validated to work around these bugs.

6. The same applies for any security updates to the platform. Currently, Google has not set any policies on how it intends to deploy security fixes to handhelds or if it plans to even do so.

7. It is not yet known how applications will be remotely provisioned to handsets. 8. No support for SOAP43 based web services44 is part of the core platform. Many

service-oriented applications (SOA) will not be directly usable from Android. It may be possible, using the technique discussed in section 4 of this paper, to include Java libraries to gain this functionality. It is clear however that Google is favouring a Restful45 approach to the consumption of web services on the Android platform.



9. Even if Google seems to be favouring Restful web services, there is no XML binding framework shipped with Android out of the box. Again, the technique used in section 4 of this paper might be used to gain this functionality.

10. Android, just like Java ME, does not mandate every possible hardware component supported by the platform. For example, a camera or Bluetooth support may be missing from the phone and yet still benefit from the Android brand.

11. Since it is not yet clear how applications will be deployed to the handsets, it is not yet known what kind of digital signatures, if any, will be required for the proper provisioning of applications to handsets.



Works Cited 1. Apache Software Foundation. [Online] Apache Software Foundation, 2008. [Cited: February 13, 2008.] http://harmony.apache.org/.

2. Google. Open Source Licensing Questions - Android. Google Android Site. [Online] 2008. http://code.google.com/android/kb/licensingandoss.html#timeline.

3. —. What is Android? Google Code. [Online] Google, 2008. [Cited: February 13, 2007.] http://code.google.com/android/what-is-android.html.

4. Wikipedia. ARM Architecture. Wikipedia. [Online] January 5, 2008. [Cited: February 13, 2008.] http://en.wikipedia.org/wiki/ARM_architecture.

5. —. GNU General Public License. Wikipedia. [Online] Wikipedia, November 19, 2007. [Cited: February 18, 2008.] http://en.wikipedia.org/wiki/GPL.

6. —. GNU Lesser General Public License. Wikipedia. [Online] February 18, 2007. [Cited: February 13, 2008.] http://en.wikipedia.org/wiki/LGPL.

7. Sun Microsystems. phoneME FAQ. phoneME. [Online] Sun Microsystems. [Cited: February 13, 2008.] https://phoneme.dev.java.net/phone_me_faq.html#cldc4.

8. Wikipedia. GNU Project. Wikipedia. [Online] July 23, 2003. [Cited: February 13, 2008.] http://en.wikipedia.org/wiki/GNU_project.

9. —. BSD licenses. Wikipedia. [Online] August 7, 2001. [Cited: February 13, 2008.] http://en.wikipedia.org/wiki/BSD_license.

10. —. MIT License. Wikipedia. [Online] May 21, 2001. [Cited: February 13, 2008.] http://en.wikipedia.org/wiki/MIT_license.

11. —. Public domain. [Online] November 5, 2001. [Cited: February 13, 2008.] http://en.wikipedia.org/wiki/Public_domain.

12. Hipp, D. Richard. SQLite Home Page. SQLite Web site. [Online] [Cited: February 13, 2008.] http://sqlite.org/.

13. Google. Open Handset Alliance. Web site for the Open Handset Alliance. [Online] Google, November 5, 2007. [Cited: February 13, 2008.] http://www.openhandsetalliance.com/.

14. Perez, Juan Carlos. Google demands non-fragmentation pledge for Android. Wireless IT World. [Online] IDG News Service, Boston Bureau, November 6, 2007. [Cited: February 13, 2008.] http://wireless.itworld.com/4269/071106googleandroid/page_1.html.

15. WebKit. The WebKit Open Source Project. Web site for WebKit. [Online] [Cited: February 13, 2008.] http://webkit.org/.

16. Apple Computer Inc. Safari. Apple Computer Inc. [Online] [Cited: February 13, 2008.] http://www.apple.com/safari/.



17. —. iPhone. Apple Computer Inc. [Online] [Cited: February 13, 2008.] http://www.apple.com/iphone/.

18. KDE. Konqueror. Konqueror. [Online] [Cited: February 13, 2008.] http://konqueror.org/.

19. webstandards.org. Acid2 Browser Test. Site for the web standards group. [Online] July 21, 2006. [Cited: February 13, 2008.] http://www.webstandards.org/action/acid2/.

20. Nokia Corporation. S60WekKit. S60WekKit. [Online] [Cited: February 13, 2008.] http://opensource.nokia.com/projects/S60browser/index.html.

21. Hipp, D. Richard. SQLite. Most Widely Deployed SQL Database. [Online] [Cited: February 13, 2008.] http://sqlite.org/mostdeployed.html.

22. Wikipedia. SQL-92. Wikipedia. [Online] July 19, 2005. [Cited: February 13, 2008.] http://en.wikipedia.org/wiki/SQL-92.

23. The OpenSSL Project. The Open Source toolkit for SSL/TLS. OpenSSL. [Online] [Cited: February 13, 2008.] http://openssl.org/.

24. Wikipedia. Transport Layer Security. Wikipedia. [Online] February 24, 2003. [Cited: February 13, 2008.] http://en.wikipedia.org/w/index.php?title=Transport_Layer_Security&dir=prev&action=history.

25. Mozilla Corporation. Mozilla. Firefox web browser & Thunderbird email client. [Online] [Cited: February 13, 2008.] http://www.mozilla.com/en-US/.

26. Apple Computer Inc. Mac OS X Leopard. Apple. [Online] Apple Computer Inc. [Cited: February 13, 2008.] http://www.apple.com/macosx/.

27. Linux.com. Linux.com. Linux.com. [Online] [Cited: February 13, 2008.] http://www.linux.com/.

28. Wikipedia Foundation. Unix. Wikipedia. [Online] December 8, 2001. [Cited: February 13, 2008.] http://en.wikipedia.org/wiki/Unix.

29. The Khronos Group. OpenGL ES. Khronos Group. [Online] [Cited: February 13, 2008.] http://www.khronos.org/opengles/.

30. Google Code. Open Source Licensing Questions. Android. [Online] Google. [Cited: February 13, 2008.] http://code.google.com/android/kb/licensingandoss.html.

31. Apache Software Foundation. Licenses. Apache. [Online] [Cited: February 13, 2008.] http://www.apache.org/licenses/.

32. Wikipedia Foundation. Swing (Java). Wikipedia. [Online] July 16, 2003. [Cited: February 13, 2008.] http://en.wikipedia.org/wiki/Swing_%28Java%29.

33. —. Abstract Window Toolkit. Wikipedia. [Online] September 13, 2002. [Cited: Ferbruary 13, 2008.] http://en.wikipedia.org/wiki/Abstract_Window_Toolkit.



34. —. Java bytecode. Wikipedia. [Online] May 24, 2005. [Cited: February 13, 2008.] http://en.wikipedia.org/wiki/Java_bytecode.

35. —. Java Platform, Micro Edition. Wikipedia. [Online] March 4, 2002. [Cited: February 14, 2008.] http://en.wikipedia.org/wiki/Java_ME.

36. —. Single sign-on. Wikipedia. [Online] August 24, 2004. [Cited: February 14, 2008.] http://en.wikipedia.org/wiki/Single_sign-on.

37. —. Public key infrastructure. Wikipedia. [Online] March 9, 2003. [Cited: February 14, 2008.] http://en.wikipedia.org/wiki/Public_key_infrastructure.

38. —. Man-in-the-middle attack. Wikipedia. [Online] November 6, 2002. [Cited: February 14, 2008.] http://en.wikipedia.org/wiki/Man-in-the-middle_attack.

39. —. Software development kit. Wikipedia. [Online] January 6, 2003. [Cited: February 14, 2008.] http://en.wikipedia.org/wiki/SDK.

40. —. Eclipse (software). Wikipedia. [Online] April 26, 2003. [Cited: February 14, 2008.] http://en.wikipedia.org/wiki/Eclipse_%28software%29.

41. —. Integrated development environment. Wikipedia. [Online] December 2, 2001. [Cited: February 14, 2008.] http://en.wikipedia.org/wiki/Integrated_development_environment.

42. Jr, Geir Magnusson. Open Letter to Sun Microsystems - JCK. The Apache Software Foundation. [Online] April 10, 2007. [Cited: February 14, 2008.] http://apache.org/jcp/sunopenletter.html.

43. Wikipedia Foundation. SOAP. Wikipedia. [Online] December 12, 2001. [Cited: February 14, 2008.] http://en.wikipedia.org/wiki/SOAP.

44. —. Web service. [Online] September 27, 2002. [Cited: February 14, 2008.] http://en.wikipedia.org/wiki/Web_services.

45. —. Representational State Transfer. Wikipedia. [Online] August 17, 2004. [Cited: February 14, 2008.] http://en.wikipedia.org/wiki/Representational_State_Transfer.

Spectrum Data Technologies Website: www.spectrumdt.com Email: [email protected] Phone: +1.877.800.9012 Copyright © 2008, Spectrum Data Technologies

A Spectrum White Paper: Thoughts on Google Android

Documents

Transcript of A Spectrum White Paper: Thoughts on Google Android