Android Architecture

From eLinux.org
Revision as of 12:29, 15 July 2010 by Tim Bird (talk | contribs)
Jump to: navigation, search

See Google's What is Android? page for an overview of Android components, and a diagram of the architecture.

The diagram on that page appears in every presentation I have ever seen about Android technical topics (with the exception of my own).

Architecture Diagram

Here is the Android Architecture Diagram]


It's not copied here for copyright reasons, but basically it has the following layers:

  • applications (written in java, but executing in Dalvik)
  • system services and libraries (written mostly in java)
  • native libraries, daemons and services (written in C or C++)
  • the Linux kernel, which includes
    • drivers for hardware, networking, and inter-process-communication

Breakdown of running Android system

A quick look at Android contents and programs running when Android starts is at:

Relation to the Linux kernel

Here is Greg Kroah-Hartmans presentation on Android from the CELF conference 2010, discussing how Google/Android work (or don't work) with the Linux community.

Java

Java is used as a language for application programming, but it is converted into a non-java byte code for runtime interpretation by a custom interpreter (Dalvik).

Java/Object Oriented Philosophy

Practicality is more important than purity in implementing the Android system.

Dianne Hackborn, one of the principal engineers working on Android, wrote:

It's not like I am a C programmer who doesn't like object oriented design. In fact prior to Android my primary language was C++... and honestly, Java really annoys me in the way it introduces so much more overhead to do things that I could express in very nice OO concepts in C++ with a much lighter-weight result.

Though Java has a lot of other nice attributes that make it good for Android, it also has its share of design flaws and misfeatures that mean we can't be totally beautifully OO as you would like.

Finally, going forward, our API conventions were defined in a way that allowed us to ship a well performing system on the hardware we had the time. As the situation changes (and it slowly is, but not enough yet) that could change... however, I will probably lean towards keeping those API conventions in place just for the sake of consistency with everything that currently exists. Of course if Android is successful and in 10 years from now we are designing a whole new next generation Android framework... well, then the world is a different place.