Android Overview
What is Android?
Android is a software stack for mobile devices that includes an operating system, middleware and key applications. The Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.
Kernel
Android is built on Linux Kernel, which was originally created by a student from University of Helsinki. (We hope the same level of innovation from this course!!!). Linux provides the hardware abstraction layer (HAL) for Android, which can allow it to be ported to wide variety of platforms in future. Figure 1 shows the general system architecture for Android.
Figure 1: Android System Architecture
It can be observed that it is based on the layered architecture approach and mainly consists of four layers. Application layer is the top layer in the architecture that interacts directly with the user and executes all applications with the help of application framework.
Application framework provides a building block for developing all applications and is an essential manager for executing all applications. This application framework includes standard components and can be extended by adding more components as needed for application development. The most important parts of this framework are: (1) Activity Framework: controls the lifecycle of the application; (2) Content Provider: encapsulates the data that needs to be shared between applications; (3) Resource Manager: manages all resources; (4) Location Manager: tracks the current location of the phone; (5) Notification Manager: notifies all events and messages.
The layer below application framework comprises of all libraries. These are shared libraries written in C/C++ and are preinstalled by the phone vendor.
Android Runtime is present on the top of the kernel which includes the Dalvik Virtual Machine and core Java libraries. While the concepts of Virtual machines is present in every OS, in case of Android the DalvikVM is specifically designed by Google Inc. which is an optimized version of Java VM. All the code for application development in written in Java and is run within this DalvikVM.
Below these libraries is the Linux kernel. Kernel is responsible for all core functionality for any OS such as process management, resource management, memory management, networking, among others. In addition this kernel is also responsible for providing all the device driver support for executing any application through the application layer. As a user one will never have to worry about the presence of Linux based kernel however, the programmer will have to be aware of its presence for application development.
Activity Lifecycle
Before we go into the specifics of an activity lifecycle, let us have a look at the general overview of the lifecycle of a process in any OS.
Figure 2: Lifecycle of a Process in any OS
A process executes by moving from one queue to another queue. There are mainly two queues present in an OS: (1) Ready queue; and (2) Waiting queue. This movement in process is done with the help of three types of schedulers: (1) Short term scheduler; (2) Long term scheduler; and (3) Mid-term scheduler. When a new process is created the long term scheduler takes this process and places in the ready queue. The number of process admitted in the ready queue is determined by this long term scheduler and therefore it controls the degree of multiprogramming. A process in this state is said to be ready for being executed on the processor. The short term scheduler decides which process will execute the next and pick us a process from ready queue for executing it on the processor. In this state the process is said to be running on the processor. In case of occurrence of an I/O event the process is moved into the waiting queue and is said to be in the waiting state for an I/O completion. In case if there is a higher priority process is waiting in the ready queue while a lower priority process is executing on the CPU, the mid-term scheduler swaps-out the lower priority process and stores it back in ready queue and swaps-in the higher priority process for executing on the processor. When a process is done with executing all its tasks, it is said to be terminated and a new process is scheduled for running on the CPU selected by short term scheduler.
While the above discussion was strictly about the process and how a process executes on a CPU with the help of three schedulers, an application must not be confused with a process. An application is the combination of one or more activity. Each activity has its own life cycle. Therefore an application is the combination of one or more activity and Linux processes.
Activities in the system are managed as an activity stack. When a new activity is started, it is placed on the top of the stack and becomes the running activity -- the previous activity always remains below it in the stack, and will not come to the foreground again until the new activity exits. An activity has essentially four states:
-
If an activity in the foreground of the screen (at the top of the stack), it is active or running.
-
If an activity has lost focus but is still visible (that is, a new non-full-sized or transparent activity has focus on top of your activity), it is paused. A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations.
-
If an activity is completely obscured by another activity, it is stopped. It still retains all state and member information, however, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere.
-
If an activity is paused or stopped, the system can drop the activity from memory by either asking it to finish, or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state.
The following diagram shows the important state paths of an Activity. The square rectangles represent callback methods you can implement to perform operations when the Activity moves between states. The colored ovals are major states the Activity can be in.
Figure 3: Activity State Paths
There are three key loops you may be interested in monitoring within your activity:
-
The entire lifetime of an activity happens between the first call to onCreate(Bundle) through to a single final call to onDestroy(). An activity will do all setup of "global" state in onCreate(), and release all remaining resources in onDestroy(). For example, if it has a thread running in the background to download data from the network, it may create that thread in onCreate() and then stop the thread in onDestroy().
-
The visible lifetime of an activity happens between a call to onStart() until a corresponding call to onStop(). During this time the user can see the activity on-screen, though it may not be in the foreground and interacting with the user. Between these two methods you can maintain resources that are needed to show the activity to the user. For example, you can register a BroadcastReceiver in onStart() to monitor for changes that impact your UI, and unregister it in onStop() when the user an no longer see what you are displaying. The onStart() and onStop() methods can be called multiple times, as the activity becomes visible and hidden to the user.
-
The foreground lifetime of an activity happens between a call to onResume() until a corresponding call to onPause(). During this time the activity is in front of all other activities and interacting with the user. An activity can frequently go between the resumed and paused states -- for example when the device goes to sleep, when an activity result is delivered, when a new intent is delivered -- so the code in these methods should be fairly lightweight.
The entire lifecycle of an activity is defined by the following Activity methods. All of these are hooks that you can override to do appropriate work when the activity changes state. All activities will implement onCreate(Bundle) to do their initial setup; many will also implement onPause() to commit changes to data and otherwise prepare to stop interacting with the user. You should always call up to your superclass when implementing these methods.
Table 1: General Movement through an Activity’s Lifecycle
Method
|
Description
|
Killable
|
Next
|
onCreate()
|
Called when the activity is first created. This is where you should do all of your normal static set up: create views, bind data to lists, etc. This method also provides you with a Bundle containing the activity's previously frozen state, if there was one.
Always followed by onStart().
|
No
|
onStart()
|
onRestart()
|
Called after your activity has been stopped, prior to it being started again.
Always followed by onStart()
|
No
|
onStart()
|
onStart()
|
Called when the activity is becoming visible to the user. Followed by onResume() if the activity comes to the foreground, or onStop() if it becomes hidden.
|
No
|
onResume()
or
onStop()
|
onResume()
|
Called when the activity will start interacting with the user. At this point your activity is at the top of the activity stack, with user input going to it.
Always followed by onPause().
|
No
|
onPause()
|
onPause()
|
Called when the system is about to start resuming a previous activity. This is typically used to commit unsaved changes to persistent data, stop animations and other things that may be consuming CPU, etc. Implementations of this method must be very quick because the next activity will not be resumed until this method returns.
Followed by either onResume() if the activity returns back to the front, or onStop() if it becomes invisible to the user.
|
Yes
|
onResume()
or
onStop()
|
onStop()
|
Called when the activity is no longer visible to the user, because another activity has been resumed and is covering this one. This may happen either because a new activity is being started, an existing one is being brought in front of this one, or this one is being destroyed.
Followed by either onRestart() if this activity is coming back to interact with the user, or onDestroy() if this activity is going away.
|
Yes
|
onRestart()
or
onDestroy()
|
onDestroy()
|
The final call you receive before your activity is destroyed. This can happen either because the activity is finishing (someone called finish() on it, or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method.
|
Yes
|
nothing
|
Share with your friends: |