Chapter 0:Application Structure of Android

Application Structure

1.AndroidManifest.xml

Every application must have an AndroidManifest.xml file (with precisely that name) in its root directory. The manifest presents essential information about the application to the Android system, information the system must have before it can run any of the application's code. Among other things, the manifest does the following:

• It names the Java package for the application. The package name serves as a unique identifier for the application.
• It describes the components of the application — the activities, services, broadcast receivers, and content providers that the application is composed of. It names the classes that implement each of the components and publishes their capabilities (for example, which Intent messages they can handle). These declarations let the Android system know what the components are and under what conditions they can be launched.
• It determines which processes will host application components.
• It declares which permissions the application must have in order to access protected parts of the API and interact with other applications.
• It also declares the permissions that others are required to have in order to interact with the application's components.
• It lists the Instrumentation classes that provide profiling and other information as the application is running. These declarations are present in the manifest only while the application is being developed and tested; they're removed before the application is published.
• It declares the minimum level of the Android API that the application requires.
• It lists the libraries that the application must be linked against.

Structure of the Manifest File

The diagram below shows the general structure of the manifest file and every element that it can contain. Each element, along with all of its attributes, is documented in full in a separate file. To view detailed information about any element, click on the element name in the diagram, in the alphabetical list of elements that follows the diagram, or on any other mention of the element name.

<?xml version="1.0" encoding="utf-8"?>



<manifest>



    <uses-permission />

    <permission />

    <permission-tree />

    <permission-group />

    <instrumentation />

    <uses-sdk />

    <uses-configuration />  

    <uses-feature />  

    <supports-screens />  

    <compatible-screens />  

    <supports-gl-texture />  



    <application>



        <activity>

            <intent-filter>

                <action />

                <category />

                <data />

            </intent-filter>

            <meta-data />

        </activity>



        <activity-alias>

            <intent-filter> . . . </intent-filter>

            <meta-data />

        </activity-alias>



        <service>

            <intent-filter> . . . </intent-filter>

            <meta-data/>

        </service>



        <receiver>

            <intent-filter> . . . </intent-filter>

            <meta-data />

        </receiver>



        <provider>

            <grant-uri-permission />

            <meta-data />

        </provider>



        <uses-library />



    </application>



</manifest>

All the elements that can appear in the manifest file are listed below in alphabetical order. These are the only legal elements; you cannot add your own elements or attributes.

<action>
<activity>
<activity-alias>
<application>
<category>
<data>
<grant-uri-permission>
<instrumentation>
<intent-filter>
<manifest>
<meta-data>
<permission>
<permission-group>
<permission-tree>
<provider>
<receiver>
<service>
<supports-screens>
<uses-configuration>
<uses-feature>
<uses-library>
<uses-permission>
<uses-sdk>

File Conventions

Some conventions and rules apply generally to all elements and attributes in the manifest:

Elements

Only the <manifest> and <application> elements are required, they each must be present and can occur only once. Most of the others can occur many times or not at all — although at least some of them must be present for the manifest to accomplish anything meaningful.

If an element contains anything at all, it contains other elements. All values are set through attributes, not as character data within an element.

Elements at the same level are generally not ordered. For example, <activity>, <provider>, and <service> elements can be intermixed in any sequence. (An <activity-alias> element is the exception to this rule: It must follow the <activity> it is an alias for.)

Attributes

In a formal sense, all attributes are optional. However, there are some that must be specified for an element to accomplish its purpose. Use the documentation as a guide. For truly optional attributes, it mentions a default value or states what happens in the absence of a specification.

Except for some attributes of the root <manifest> element, all attribute names begin with an android: prefix — for example, android:alwaysRetainTaskState. Because the prefix is universal, the documentation generally omits it when referring to attributes by name.

Declaring class names

Many elements correspond to Java objects, including elements for the application itself (the <application> element) and its principal components — activities (<activity>), services (<service>), broadcast receivers (<receiver>), and content providers (<provider>).

If you define a subclass, as you almost always would for the component classes (Activity, Service, BroadcastReceiver, and ContentProvider), the subclass is declared through a name attribute. The name must include the full package designation. For example, an Service subclass might be declared as follows:

<manifest . . . >

    <application . . . >

        <service android:name="com.example.project.SecretService" . . . >

            . . .

        </service>

        . . .

    </application>

</manifest>

However, as a shorthand, if the first character of the string is a period, the string is appended to the application's package name (as specified by the <manifest> element's package attribute). The following assignment is the same as the one above:

<manifest package="com.example.project" . . . >

    <application . . . >

        <service android:name=".SecretService" . . . >

            . . .

        </service>

        . . .

    </application>

</manifest>

When starting a component, Android creates an instance of the named subclass. If a subclass isn't specified, it creates an instance of the base class.

Multiple values

If more than one value can be specified, the element is almost always repeated, rather than listing multiple values within a single element. For example, an intent filter can list several actions:

<intent-filter . . . >

    <action android:name="android.intent.action.EDIT" />

    <action android:name="android.intent.action.INSERT" />

    <action android:name="android.intent.action.DELETE" />

    . . .

</intent-filter>

Resource values

Some attributes have values that can be displayed to users — for example, a label and an icon for an activity. The values of these attributes should be localized and therefore set from a resource or theme. Resource values are expressed in the following format,

@[package:]type:name

where the package name can be omitted if the resource is in the same package as the application, type is a type of resource — such as "string" or "drawable" — and name is the name that identifies the specific resource. For example:

<activity android:icon="@drawable/smallPic" . . . >

Values from a theme are expressed in a similar manner, but with an initial '?' rather than '@':

?[package:]type:name

String values

Where an attribute value is a string, double backslashes ('\\') must be used to escape characters — for example, '\\n' for a newline or '\\uxxxx' for a Unicode character.

File Features

The following sections describe how some Android features are reflected in the manifest file.

Intent Filters

The core components of an application (its activities, services, and broadcast receivers) are activated by intents. An intent is a bundle of information (an Intent object) describing a desired action — including the data to be acted upon, the category of component that should perform the action, and other pertinent instructions. Android locates an appropriate component to respond to the intent, launches a new instance of the component if one is needed, and passes it the Intent object.
Components advertise their capabilities — the kinds of intents they can respond to — through intent filters. Since the Android system must learn which intents a component can handle before it launches the component, intent filters are specified in the manifest as <intent-filter> elements. A component may have any number of filters, each one describing a different capability.
An intent that explicitly names a target component will activate that component; the filter doesn't play a role. But an intent that doesn't specify a target by name can activate a component only if it can pass through one of the component's filters.
For information on how Intent objects are tested against intent filters, see a separate document, Intents and Intent Filters.

Icons and Labels

A number of elements have icon and label attributes for a small icon and a text label that can be displayed to users. Some also have a description attribute for longer explanatory text that can also be shown on-screen. For example, the <permission> element has all three of these attributes, so that when the user is asked whether to grant the permission to an application that has requested it, an icon representing the permission, the name of the permission, and a description of what it entails can all be presented to the user.
In every case, the icon and label set in a containing element become the default icon and label settings for all of the container's subelements. Thus, the icon and label set in the <application> element are the default icon and label for each of the application's components. Similarly, the icon and label set for a component — for example, an <activity> element — are the default settings for each of the component's <intent-filter> elements. If an <application> element sets a label, but an activity and its intent filter do not, the application label is treated as the label for both the activity and the intent filter.
The icon and label set for an intent filter are used to represent a component whenever the component is presented to the user as fulfilling the function advertised by the filter. For example, a filter with "android.intent.action.MAIN" and "android.intent.category.LAUNCHER" settings advertises an activity as one that initiates an application — that is, as one that should be displayed in the application launcher. The icon and label set in the filter are therefore the ones displayed in the launcher.

Permissions

A permission is a restriction limiting access to a part of the code or to data on the device. The limitation is imposed to protect critical data and code that could be misused to distort or damage the user experience.
Each permission is identified by a unique label. Often the label indicates the action that's restricted. For example, here are some permissions defined by Android:

android.permission.CALL_EMERGENCY_NUMBERS
android.permission.READ_OWNER_DATA
android.permission.SET_WALLPAPER
android.permission.DEVICE_POWER

A feature can be protected by at most one permission.
If an application needs access to a feature protected by a permission, it must declare that it requires that permission with a <uses-permission> element in the manifest. Then, when the application is installed on the device, the installer determines whether or not to grant the requested permission by checking the authorities that signed the application's certificates and, in some cases, asking the user. If the permission is granted, the application is able to use the protected features. If not, its attempts to access those features will simply fail without any notification to the user.
An application can also protect its own components (activities, services, broadcast receivers, and content providers) with permissions. It can employ any of the permissions defined by Android (listed in android.Manifest.permission) or declared by other applications. Or it can define its own. A new permission is declared with the <permission> element. For example, an activity could be protected as follows:

<manifest . . . >

    <permission android:name="com.example.project.DEBIT_ACCT" . . . />

    <uses-permission android:name="com.example.project.DEBIT_ACCT" />

    . . .

    <application . . .>

        <activity android:name="com.example.project.FreneticActivity"

                  android:permission="com.example.project.DEBIT_ACCT"

                  . . . >

            . . .

        </activity>

    </application>

</manifest>

Note that, in this example, the DEBIT_ACCT permission is not only declared with the <permission> element, its use is also requested with the <uses-permission> element. Its use must be requested in order for other components of the application to launch the protected activity, even though the protection is imposed by the application itself.
If, in the same example, the permission attribute was set to a permission declared elsewhere (such as android.permission.CALL_EMERGENCY_NUMBERS, it would not have been necessary to declare it again with a <permission> element. However, it would still have been necessary to request its use with <uses-permission>.
The <permission-tree> element declares a namespace for a group of permissions that will be defined in code. And <permission-group> defines a label for a set of permissions (both those declared in the manifest with <permission> elements and those declared elsewhere). It affects only how the permissions are grouped when presented to the user. The <permission-group> element does not specify which permissions belong to the group; it just gives the group a name. A permission is placed in the group by assigning the group name to the <permission> element's permissionGroup attribute.

Libraries

Every application is linked against the default Android library, which includes the basic packages for building applications (with common classes such as Activity, Service, Intent, View, Button, Application, ContentProvider, and so on).
However, some packages reside in their own libraries. If your application uses code from any of these packages, it must explicitly asked to be linked against them. The manifest must contain a separate <uses-library> element to name each of the libraries. (The library name can be found in the documentation for the package.)

2. uses-permission & uses- sdk

<uses-permission>

syntax:

<uses-permission android:name="string" />

contained in:

<manifest>

description:

Requests a permission that the application must be granted in order for it to operate correctly. Permissions are granted by the user when the application is installed, not while it's running.

For more information on permissions, see the Permissions section in the introduction and the separate Security and Permissions document. A list of permissions defined by the base platform can be found at android.Manifest.permission.

attributes:

android:name

The name of the permission. It can be a permission defined by the application with the <permission> element, a permission defined by another application, or one of the standard system permissions, such as "android.permission.CAMERA" or "android.permission.READ_CONTACTS". As these examples show, a permission name typically includes the package name as a prefix.

introduced in:

API Level 1

                             In some cases, the permissions that you request through <uses-permission> can affect how your application is filtered by Google Play.

If you request a hardware-related permission — CAMERA, for example — Google Play assumes that your application requires the underlying hardware feature and filters the application from devices that do not offer it.

To control filtering, always explicitly declare hardware features in <uses-feature> elements, rather than relying on Google Play to "discover" the requirements in <uses-permission> elements. Then, if you want to disable filtering for a particular feature, you can add a android:required="false" attribute to the <uses-feature> declaration.

<uses-sdk>

syntax:

<uses-sdk android:minSdkVersion="integer"
          android:targetSdkVersion="integer"
          android:maxSdkVersion="integer" />

contained in:

<manifest>

description:

Lets you express an application's compatibility with one or more versions of the Android platform, by means of an API Level integer. The API Level expressed by an application will be compared to the API Level of a given Android system, which may vary among different Android devices.

Despite its name, this element is used to specify the API Level, not the version number of the SDK (software development kit) or Android platform. The API Level is always a single integer. You cannot derive the API Level from its associated Android version number (for example, it is not the same as the major version or the sum of the major and minor versions).

AIP Levels

What is API Level?

API Level is an integer value that uniquely identifies the framework API revision offered by a version of the Android platform.
The Android platform provides a framework API that applications can use to interact with the underlying Android system. The framework API consists of:

• A core set of packages and classes
• A set of XML elements and attributes for declaring a manifest file
• A set of XML elements and attributes for declaring and accessing resources
• A set of Intents
• A set of permissions that applications can request, as well as permission enforcements included in the system

Each successive version of the Android platform can include updates to the Android application framework API that it delivers.

Eg:  Android 2.2.x has 8 API Level

3. R.java and Resources

   R.java

The " gen " directory in an Android project contains generated values. R.java is a generated class which contains references to certain resources of the the project.
These resources must be defined in the "res" directory and can be XML files, icons or pictures. You can for example define values, menus, layouts or animations via XML files.
If you create a new resource, the corresponding reference is automatically created in R.java via the Eclipse ADT tools. These references are static int values and define ID's for the resources.
The Android system provides methods to access the corresponding resource via these ID's.
For example to access a String with the R.string.yourString ID use the getString(R.string.yourString)) method.
R.java is automatically created by the Eclipse development environment, manual changes are not necessary and will be overridden by the tooling.

R class

In Eclipse, open the file named R.java (in the gen/ [Generated Java Files] folder). It should look something like this:

package com.example.helloandroid;



public final class R {

    public static final class attr {

    }

    public static final class drawable {

        public static final int icon=0x7f020000;

    }

    public static final class id {

        public static final int textview=0x7f050000;

    }

    public static final class layout {

        public static final int main=0x7f030000;

    }

    public static final class string {

        public static final int app_name=0x7f040001;

        public static final int hello=0x7f040000;

    }

}

A project's R.java file is an index into all the resources defined in the file. You use this class in your source code as a sort of short-hand way to refer to resources you've included in your project. This is particularly powerful with the code-completion features of IDEs like Eclipse because it lets you quickly and interactively locate the specific reference you're looking for.
It's possible yours looks slightly different than this (perhaps the hexadecimal values are different). For now, notice the inner class named "layout", and its member field "main". The Eclipse plugin noticed the XML layout file named main.xml and generated a class for it here. As you add other resources to your project (such as strings in the res/values/string.xml file or drawables inside the res/drawable/ directory) you'll see R.java change to keep up.
When not using Eclipse, this class file will be generated for you at build time (with the Ant tool).
You should never edit this file by hand.

Accessing Resources

Once you provide a resource in your application (discussed in Providing Resources), you can apply it by referencing its resource ID. All resource IDs are defined in your project's R class, which the aapt tool automatically generates.

When your application is compiled, aapt generates the R class, which contains resource IDs for all the resources in your res/ directory. For each type of resource, there is an R subclass (for example, R.drawable for all drawable resources) and for each resource of that type, there is a static integer (for example, R.drawable.icon). This integer is the resource ID that you can use to retrieve your resource.

Although the R class is where resource IDs are specified, you should never need to look there to discover a resource ID. A resource ID is always composed of:

• The resource type: Each resource is grouped into a "type," such as string, drawable, and layout. For more about the different types, see Resource Types.
• The resource name, which is either: the filename, excluding the extension; or the value in the XML android:name attribute, if the resource is a simple value (such as a string).

There are two ways you can access a resource:

·         In code: Using an static integer from a sub-class of your R class, such as:

R.string.hello

string is the resource type and hello is the resource name. There are many Android APIs that can access your resources when you provide a resource ID in this format.

                          You can use a resource in code by passing the resource ID as a method parameter. For example, you can set an ImageView to use the res/drawable/myimage.png resource using setImageResource():

ImageView imageView = (ImageView) findViewById(R.id.myimageview);

imageView.setImageResource(R.drawable.myimage);

You can also retrieve individual resources using methods in Resources, which you can get an instance of with getResources().
Here are some examples of accessing resources in code:

// Load a background for the current screen from a drawable resource

getWindow().setBackgroundDrawableResource(R.drawable.my_background_image) ;



// Set the Activity title by getting a string from the Resources object, because

//  this method requires a CharSequence rather than a resource ID

getWindow().setTitle(getResources().getText(R.string.main_title));



// Load a custom layout for the current screen

setContentView(R.layout.main_screen);



// Set a slide in animation by getting an Animation from the Resources object

mFlipper.setInAnimation(AnimationUtils.loadAnimation(this,

        R.anim.hyperspace_in));



// Set the text on a TextView object using a resource ID

TextView msgTextView = (TextView) findViewById(R.id.msg);

msgTextView.setText(R.string.hello_message);

·         In XML: Using a special XML syntax that also corresponds to the resource ID defined in your R class, such as:

@string/hello

string is the resource type and hello is the resource name. You can use this syntax in an XML resource any place where a value is expected that you provide in a resource.

Syntax

Here is the syntax to reference a resource in an XML resource:

@[<package_name>:]<resource_type>/<resource_name>

• <package_name> is the name of the package in which the resource is located (not required when referencing resources from the same package)
• <resource_type> is the R subclass for the resource type
• <resource_name> is either the resource filename without the extension or the android:name attribute value in the XML element (for simple values).

Accessing Resources from XML

You can define values for some XML attributes and elements using a reference to an existing resource. You will often do this when creating layout files, to supply strings and images for your widgets.
For example, if you add a Button to your layout, you should use a string resource for the button text:

<Button

    android:layout_width="fill_parent"

    android:layout_height="wrap_content"

    android:text="@string/submit" />

 

4 Assets

While the res directory contains structured values which are known to the Android platform, the assets directory can be used to store any kind of data. In Java you access this data via the AssetsManager and the getAssets() method .
Assets it also store an external content refer in android applications. Just like images, audio, video, text strings .It same as resources but different in assets directory will maintain its raw file format and, in order to read it, you must use the AssetManager to read the file as a stream of bytes. So keeping files and data in resources (res/) makes them easily accessible.

5.Activities and activity life cycle

 Activity Class Overview

An activity is a single, focused thing that the user can do. Almost all activities interact with the user, so the Activity class takes care of creating a window for you in which you can place your UI with setContentView(View). While activities are often presented to the user as full-screen windows, they can also be used in other ways: as floating windows (via a theme with windowIsFloating set) or embedded inside of another activity (using ActivityGroup). There are two methods almost all subclasses of Activity will implement:

• onCreate(Bundle) is where you initialize your activity. Most importantly, here you will usually call setContentView(int) with a layout resource defining your UI, and using findViewById(int) to retrieve the widgets in that UI that you need to interact with programmatically.
• onPause() is where you deal with the user leaving your activity. Most importantly, any changes made by the user should at this point be committed (usually to the ContentProvider holding the data).

To be of use with Context.startActivity(), all activity classes must have a corresponding <activity> declaration in their package's AndroidManifest.xml.

The activity is the core of an android application. Each application can have one or more activities.

Activities in the system are managed in an activity stack (Last in Last out). When a new activity is launched it becomes on the top of the stack. Any previous activity will be below it and won’t come to the top until the new one exists.

The application on the top of the stack has the highest priority from the operating system. While the activity that is not visible has lower priority even if the a running activity requires more memory, the system can shut down that activity to free memory.

Android runs each activity in a separate process each of which hosts a separate virtual machine. Android saves metadata (state) of each activity so that when a new activity launches so that it can come back to the activity when the user backtracks.

Activity Lifecycle

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.
 
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.

 public class Activity extends ApplicationContext {

     protected void onCreate(Bundle savedInstanceState);



     protected void onStart();

     

     protected void onRestart();



     protected void onResume();



     protected void onPause();



     protected void onStop();



     protected void onDestroy();

 }

 

The activity can be in one of four states:

Active: the activity started, is running and is in the foreground.

Paused: the activity is running and visible but another activity (non full sized) is running on the top or a notification is displayed. The user can see the activity but can not interact with it. A paused activity is fully alive (maintains state and member information) but can be killed by the system in low memory situations.

Stopped: the activity is running but invisible because the user has launched another activity that comes to the foreground the activity is alive (maintains state and member information) but can be killed by the system in low memory situations.

Dead: either the activity is not started or it was in pause or stop state and was terminated by the system to free some memory or by asking the user to do so.

The following figure shows the states of the activity and the methods that handle each state

The sequence is as follows:

• The activity starts, passes through onCreate(), onStart() the activity is still not visible to the user, onResume() then it comes to the foreground and becomes fully running.
• If another activity launches or a notification appears the activity passes through the onPause() method. Then there would be two scenarios:
  1.if the system decides to kill your activity due to low memory the activity starts the cycle again from onCreate() method with Bundle savedInstanceState parameter that holds data about the previous state of the activity.
  2.If the user resumes the activity by closing the new activity or the notification the activity cycle continues from the onResume() method
• When the user is about to close the activity the activity calls onStop() method then onDestroy() method when the system destroys the activity.
  But if another activity runs while the current one is was not shut, the activity calles onStop() method and if it is not killed by the system it will call onRestart() method then onStart() mehod and continues the cycle.
• onCreate(): will be invoked in three cases:
  - the activity runs for the first time and it will be invoked with null Bundle savedInstanceState parameter.
  - the activity has been running then stopped by the user or destroyed by the system then it would be invoked with Bundle savedInstanceState that holds the previous state of the activity.
  - the activity is running and you set the device to different resources like Portrait vs landscape, then the activity will be recreated.in this method you will create the user interface, bind data to controls and register the event handlers for the controls. Then it is followed by onStart() method.
• onStart(): will be invoked when the activity is first launched or brought back to the foreground
  it would be followed by onResume() if the activity continues and comes to foreground, or by onStop() if the activity is killed.
• onRestart(): is invoked in case the activity has been stopped and is about to be run again. Always followed by onStart() mehod.
• onResume(); invoked when the activity is about to come to the foreground and is on the top of the activity stack. It is the place where you can refresh the controls if the activity is using a service that displays some feeds or news. Always followed by onPause() method.
• onPause(): is invoked when another activity launches while the current activity is launched or when the system decides to kill the activity. In this method you have to cancel everything you did in onResume() method like Stopping threads, stopping animations or clearing usage of resources(eg the camera).This method is followed by onResume() if the activity returns back to front or by onStop() if the activity is to be invisible.
• onStop(): is invoked when a new activity is about to come over the current one or the current one is to be destroyed. Always followed by onResume() if the activity comes back or onDestroy() if the activity is to be killed.
• onDestroy():is invoked when the activity is shutting down because the activity called finish() [terminated the activity] or because the system needs memory so it decided to kill the activity.

Killable methods:

There are methods that are “killable” meaning that after theses methods return, the process hosting them can kill the activity without executing any further code (due to lack of memory)

These methods are onPause(), onStop() and onDestroy()

here’s the declaration of the life cycle methods:

    @Override

    public void onCreate(Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);

    }

    @Override

    protected void onStart() {

    }

    @Override

    protected void onPause() {

        super.onPause();

    }

    @Override

    protected void onResume() {

        super.onResume();

    }

    @Override

    protected void onRestart() {

        super.onRestart();

    }

    @Override

    protected void onStop() {

        super.onStop();

    }

    @Override

    protected void onDestroy() {

        super.onDestroy();

    }