What is Android Architecture?

What is Android Architecture?

Let’s talk software but take a break from code. Many of the components in this model grant developers the super-human powers to build some clever and innovative applications on a wide variety of devices, but, what is Android architecture?


Application Framework

The top layer of Android architecture is called the application framework. This is the layer of abstraction that developers work within. This is where the applications live, a customized software layer just below where front-end users see. In this layer, developers are free to take advantage of the device hardware and some operating systems protocols, such as accessing location information, running background services, setting alarms, adding notifications to the status bar, etc.

Here is a run down of key services included within the Application Framework:

  • Activity Manager – Controls aspects of the application lifecycle and activity stack.
  • Content Providers – Allows applications to publish and share data with other applications.
  • Resource Manager – Provides access to non-code embedded resources such as strings, color settings and user interface layouts.
  • Notifications Manager – Allows applications to display alerts and notifications to the user.
  • View System – An extensible set of views used to create application user interfaces.
  • Package Manager – The system by which applications are able to find out information about other applications currently installed on the device.
  • Telephony Manager – Provides information to the application about the telephony services available on the device such as status and subscriber information.
  • Location Manager – Provides access to the location services allowing an application to receive updates about location changes.


Our next layer down is the language library layer itself. Android includes a set of core libraries which provide access to all of the Android components to build an application. As a developer, you will probably only ever use the first two libraries: the standard Java SDK and the Java-based core Android SDK, but the other libraries deserve mention.


Java developers will be happy to know that almost all of the standard Java functions are here and updated to the most current Java SDK version.
The other vital set of Java libraries are the Android Libraries themselves. These contain the functions for interfacing with the Android hardware. Here you will find graphics rendering, local database access, device network stack access, XML manipulation, dates and times, camera access, GPS access, phone/contacts access, etc; all of the features that were being customized in the Application Framework layer.


As a subset of these libraries, there are the Java Interoperability Libraries which handle the special virtual machine that Android uses and how Java interacts within it. Developers don’t go here.

Android also includes a set of C/C++ libraries. These are used behind-the-scenes by the Java code and Virtual Machine to interact with various components of the Android system. For example, the OpenGL ES library works with the Android OS to deliver graphics. Developers rarely need to access these and in Android Studio they are purposely hidden from direct editing.

Finally, the virtual machine specific libraries, of which no developer should ever access. Let’s enjoy this black box.


Android Runtime

Each Android application does not run as a process directly on the operating system. Instead, during runtime, application instances run though a virtual machine called the Dalvik Virtual Machine, which is similar to the Java Virtual Machine (JVM). The DVM was developed by Google to compile Java using 50% efficiency in memory footprint, compared to Oracle’s JVM.

To create a distribution ready app, most of the Java class files are transformed into .dex (Dalvik Executable Format) files by the developer using the dx tool found inside of the Android Software Development Kit. When the end user starts the application,  their DVM executes the .dex files, and the C/C++ libraries; runtime begins.


Significantly, during runtime each application actually runs within its own instance of the DVM. This creates a sandbox effect. Applications cannot directly access other applications or the operating system. Using a virtual machine also has the big-picture effect of working within a variety of vendor-specific versions of the OS on a countless number of devices.

Linux Kernel

Finally, Android relies on the Linux version 2.6 for core system services which actually means little to us developers. This layer is the lowest abstraction layer and supports all of the higher layers in their interactions with device hardware. But, an important distinction between Linux desktop and Android mobile is that Android uses the Dalvik virtual machine to run every application. The VM communicates with the kernel as separate instances, and is totally different than applications running on a typical Linux OS which run directly on the system.

The kernel provides multi-tasking for running system processes concurrently. It also provides the required system management and core services such as security, memory, power, and process management. It also deals with the network stack, like wifi, and the device drivers for hardware components.

Remember that while based on the  Linux version 2.6 at its core, Android is an operating system for mobile, and many traditional desktop/server ideas simply don’t exist in this environment. For example, applications cannot be controlled via generic GNU/Linux shell commands. They are “locked” from the developer. The only interfaces available are those of which Google has made available via the Application Framework. The terminal environment in Android is not available without “rooting” the device to gain access, and once you are in, it is restricting and underwhelming compared to what you would find with Linux desktop.

That being said, it is refreshing for computer geeks, especially Linux die-hards, to see their favorite operating system core being used inside of the heart of the world’s most popular mobile OS.



Android Architecture is made of four key components:

  1. Application Framework
  2. Libraries
  3. Runtime
  4. Linux Kernel(Just remember “ALAL”.)
    You will also hear the Android Architecture called the Android Stack or the Android Framework.

Pretty sweet, right?

(C++) Objects: Deep copy vs. Shallow Copy

“Ahhhhh, it’s time for C++,  and you know what that means,
A glass of wine, your favorite easy chair,  and of course Microsoft Visual Studio open in your Windows operating system.” -not the intro to “Smash” by the Offspring

What is the difference between a “deep copy” and a “shallow copy” in C++?

Is one better than the other, regarding copying objects?

I thought you would never ask. A shallow copy copies all the member values from one object to another. Great! But what if your member variables include pointers? You are going to run into some problems. To understand the difference between a shallow copy and a deep copy, let’s look at how and where issues can happen.

First, let me get my includes and namespace on:


Now some code:


This most basic C++ object, myObject. There is a single member variable, a pointer variable named ptr.

So let’s look at a shallow copy. Check out the following:


First, we created a method named shallowCopy, and then we pass in myObject as two separate reference parameters named src and dest(source and destination).  Two objects created.  All good, right?

Image result for NO meme

No. dest is pointing to src‘s location. This will lead to some problems with manipulating the data inside of shallow copies. When creating or deleting an object, a shallow copy may cause runtime errors. For example, if object src is deleted, runtime error. The best case for using shallow copies would be when the object is complex and you just need the state of the object at that instance in the program, basically something to reference and nothing more. If you start making changes to a copy of the object, you may be in for a runtime headache of epic proportions. So how can we get an accurate copy of an object, including references that don’t point to other objects?

So let’s look at making a deep copy:

Here is deepCopy with input parameters of references to myObject type named src and dest. The dest pointer is being casted as a char pointer in memory, with the same string length as src, but it exists on its own. Then copy the pointers using strcpy library function.

A deep copy does everything a shallow copy does, but also copies any pointer objects and dereferences them. So the dest and src pointers are no longer pointing to the same location in memory, but pointing at their own locations in memory. Deep copy should be used more often, especially when the size of the copied structure is large. Keep in mind they do cost a little more in memory, but deep copies are almost always the right way to go.

So, the main takeaway here: be sure your pointers are copied over when copying objects, make a deep copy.