Saturday, 20 December 2014

Layers in Architecture



In this post, we will have a closer look at each layer of the Android Architecture. In case if you have missed reading my previous post, then I would suggest you to read it once.
       The Android architecture consist of four layers, the first and base layer is Linux Kernel version 3.4 or newer (as of January 2014) with slight enhancements. Android has used various kernels since its first 2.6.25. Android's Linux kernel has further more changes done by Google outside the typical Linux Kernel development cycle.
Android's Linux Kernel

Android's Linux Kernel
  As you can see from the figure, it contains all your device drivers which directly talks to your hardware such as Display Driver, Camera Driver, Wifi Drver, Audio Driver, Binder (IPC) Driver etc.

 But here are some enhancements made by Google typically to make Linux Kernel compatible with Android devices.
1) Binder 
  Binder is an Android-specific interprocess communication mechanism, and remote method invocation system. So what it means, one Android process can call routine in another android process.

2) Ashmem 
 Stands for Android Shared Memory. The ashmem subsystem is a new shared memory allocator, but with different behavior and sporting a simpler file-based API." Apparently, supports better for low memory devices.
3) Logger
  It provides system logging facility. This is the kernel support for the 'logcat' command.
4) WakeLocks
   These are used for power management. It tries to holds machine awake on a per-event basis until wakelock is released.
5) No glibc support (bionic libc instead). Does not include the full set of standard Linux utilities.

 Native Libraries and Runtime:

Then we have all Native libraries and even Android Runtime environment in the next layer of architecture.
    In this layer, we have all supported libraries written mostly in C. Here are some key points on this layer:

 Bionic LIBC
 Small size and fast code paths
 Built-in support for Android-specific services
 Not compatible with GNU libc, all native code must be compiled against Bionic

Other important libraries such as:
 Sqlite used for storing data (similar to SQL), Media libs, WebKit used by web browsers etc.

Native Servers such as  Surface flinger, Audio Manager which we will be talking about within next few post.
   Then we have Android Runtime. which consist of Dalvik Virtual Machine. Here are some key point on Dalvik VM:
1) Named after Dalvik, a village in Iceland.
2) Uses JIT Compiler (Just In Time Compiler)

3) Runs optimized file format (.dex) and Dalvik bytecode, Java .class / .jar files converted to .dex at build time

4) Supports multiple virtual machine processes per device.

5) Uses runtime memory efficiently.
Note: Prior to Android 5.0 Lollipop, it was Dalvik VM but now with the release of newest Android version i.e Lollipop we have ART Runtime envirionment which uses AOT Compiler (Ahead of Time)
 

Tuesday, 16 December 2014

Android Architecture

Okay, now lets talk about Android Core. I have been speaking around for a while about how android came into existence and a little comparison between ios and android market share was even adequate. If you have not read my previous post then you I would suggest you to read it in order to know about android history.

   If someone ask you what is android, then you can define it as: 
"Android is a software stack for mobile devices that includes an operating system, middleware and key applications. It is a mobile device platform built on the Linux Kernel version 2.6 with some enhancements like Ashmem (Android Shared Memory), Binder, Logger, Low Memory Killer, and Power Management."

    Android is supported by ARM Architecture based processors with x86 and MIPS are officially supported. Prior to Android 5.0, it was 32-bit support for all three variants but now with gaining support Android Lollipop 5.0 can even support 64-bit processors. All you need to know about Android L 64-bit.

Android Version History:

Android initially released with beta version for the first time on November 2007, later it was officially available to developers and manufacturer's on September 2008 with Android 1.0 . Android different version's have been released with names after dessert. Now why Google would name each version of android after desserts ? Google just doesn't want to explain. "It's kind of like an internal team thing, and we prefer to be a little bit -- how should I say -- a bit inscrutable in the matter, I'll say," said Randall Sarafa, a Google spokesman. "The obvious thing is that, yeah, the Android platform releases, they go by dessert names and by alphabetical order for the most part."
  So here is the list for android versions with code name and their respective API level:

  • Alpha (1.0)
  • Beta (1.1)
  • Cupcake (1.5)
  • Donut (1.6)
  • Eclair (2.0–2.1)
  • Froyo (2.2–2.2.3)
  • Gingerbread (2.3–2.3.7)
  • Honeycomb (3.0–3.2.6)
  • Ice Cream Sandwich (4.0–4.0.4)
  • Jelly Bean (4.1–4.3.1)
  • KitKat (4.4–4.4.4)
  • Lollipop (5.0–5.0.1)


Android architectural building blocks:

Android Architecture
As you can see from the figure shown above, android has four layers of stack starting from Linux base kernel, Native C & C++ libraries and Android Runtime, Application framework and the top level is for all android applications that you interact with everyday on your mobile phone. Now, you must be curious to know about these layers and I will explain them in brief very shortly.

Monday, 15 December 2014

History of Android

In this post, we will see how Android Open Source Project (AOSP) came into existence and what made google to buy an open source linux based mobile operating system.

    Android Inc. was a start-up in  Palo Alto, California founded by Andy Rubin, Rich Miner, Nick Sears and Chris White on October 2003, which was later bought by Google on August 17, 2005. Andy Rubin's intention was to make smarter mobile devices with android that are more aware of its owner's location and preferences.

Google (with Android team) first demonstrated it just a mobile OS based on Linux. Google's vision was to get it's search capabilities and LBS (Location Based Service ) onto mobile handled devices initiated the drive towards "Android - the Mobile platform".

        Later, on November 5, 2007 Open Handset Alliance, consortium of technology companies like Google, samsung, HTC, Sony, Sprint NextTel and T- Mobiles joined their hands together and announced Android operating System based on Linux kernel version 2.6.25.

   Now, Google have this revolutionary mobile operating system to compete Apple's I-Phone which comes with very scalable and flexible applications. Now system applications and third party applications can use the same resources.

  Here's a glimpse of market share between android, ios and other mobile operating system

I'm blown away after seeing this figure. 81% for Android is really huge achievement over the mobile market which makes android most dominating mobile OS.

  But one should not be ignorant to know about the revenue generated by the ios applications is more than android applications. There is always head to head competition between ios and android.




Sunday, 14 December 2014

Let's start with something funny

With my first post of this blog, I will share some of my experience while working on Android Applications and how geeks look at the problem.

    When we get stuck at some point while coding, why we do google for the problem. Because it will find the answer for you, But does it really helps you to improve in any way, may be for the boilerplate code we get lame and doesn't bother about to understand it.

 Let's have a look at the figure to understand how boilerplate code looks like in real life.


Now if we look close enough, every move in the dance was easy until we try to perform every step at once. Even sometimes complex coding problem just bounces over my head, I spend hours and hours try to understand the actual problem.

Now let's look at the Divide and conquer strategy, the easiest way to break down the problem into pieces. When we have some bigger and scary problem, just hold on, don't get scared. Break the problem into parts until you reach to the base problem.

    It really helps me to understand the root cause first. Then building the solution based on this root cause. That's all folks for the first post. I'll get back with some interesting articles soon.