Difference between revisions of "Android Architecture"

From eLinux.org
Jump to: navigation, search
m (+ Android internals)
 
(5 intermediate revisions by one other user not shown)
Line 7: Line 7:
  
 
== Architecture Diagram ==
 
== Architecture Diagram ==
Here is the [http://developer.android.com/images/system-architecture.jpg Android Architecture Diagram]]
+
Here is the Android Architecture Diagram, obtained from [http://developer.android.com/images/system-architecture.jpg here].
  
 +
[[image:Android-system-architecture.jpg]]
  
 +
See also [http://www.makelinux.net/android/internals/ Android internals diagram]
  
It's not copied here for copyright reasons, but basically it has the following layers:
+
Basically Android has the following layers:
  
* applications (written in java, but executing in Dalvik)
+
* applications (written in java, executing in Dalvik)
* system services and libraries (written mostly in java)
+
* framework services and libraries (written mostly in java)
 +
** applications and most framework code executes in a virtual machine
 
* native libraries, daemons and services (written in C or C++)
 
* native libraries, daemons and services (written in C or C++)
 
* the Linux kernel, which includes
 
* the Linux kernel, which includes
** drivers for hardware, networking, and inter-process-communication
+
** drivers for hardware, networking, file system access and inter-process-communication
 +
 
 +
== Overview presentations ==
 +
* [http://kobablog.wordpress.com/2011/05/22/android-is-not-just-java-on-linux/ Android is not just Java on Linux]
 +
** Great presentation by Tetsuyuki Kobayashi overview of Android
 +
* See this Android Internals presentation by Karim Yaghmour
 +
** http://www.opersys.com/blog/android-internals-101103
 +
** You'll find both the video and the slides there
 +
* [[Media:Mythbusters_Android.pdf|Mythbusters_Android.pdf]] Presentation by Matt Porter at ELC Europe
 +
** Has bits and pieces showing problematic Android code and policies
  
 
== Breakdown of running Android system ==
 
== Breakdown of running Android system ==
Line 33: Line 45:
  
 
Dianne Hackborn, one of the principal engineers working on Android, wrote:
 
Dianne Hackborn, one of the principal engineers working on Android, wrote:
<pre>
+
<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #CCCC00; padding:0 1em 1em 1em; background-color:#ffffcc; align:right;">
 +
 
 
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.
 
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.
  
Line 39: Line 52:
  
 
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.
 
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.
</pre>
+
</div><br/>
 
 
  
 
[[Category:Android]]
 
[[Category:Android]]

Latest revision as of 08:15, 13 June 2011

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, obtained from here.

Android-system-architecture.jpg

See also Android internals diagram

Basically Android has the following layers:

  • applications (written in java, executing in Dalvik)
  • framework services and libraries (written mostly in java)
    • applications and most framework code executes in a virtual machine
  • native libraries, daemons and services (written in C or C++)
  • the Linux kernel, which includes
    • drivers for hardware, networking, file system access and inter-process-communication

Overview presentations

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.