A seminar report

On
Understanding the AOSP

Submitted by

Bodhisatwa Kumar
(Regd. No. 1601110053 )

Guided By:
Dr. Basant Kumar Swain
Prof. (CSE)
DEPT. OF COMPUTER SC. AND ENGINEERING

GOVERNMENT COLLEGE OF ENGINEERING KALAHANDI,

BHAWANIPATNA

(A Constituent College of BPUT, Odisha)

July, 2020
 DECLARATION
I declare that this written submission represents my ideas in my own words and
where others’ ideas have been included. I have adequately cited and referenced
the original sources. I also declare that I have adhered to all principals of
academic honesty and integrity and have not misrepresented or fabricated or
falsified any idea/data/act source in my submission. I understand that any
violation of the above will be cause for disciplinary action by the Institute and
can also evoke penal action from the sources which have thus not been properly
cited or from whom proper permission has been taken when needed.

Bodhisatwa Kumar
(Regd. No. 1601110053)

i
 ACKNOWLEDGEMENT
​The satisfaction that successful completion of this seminar would
be incomplete without the mention of the people who made it possible,
without whose constant guidance and encouragement would have made
effort go in vain. I consider myself privileged to express gratitude and
respect towards all those who guided us through the completion of this
seminar.

I convey thanks to my guide Prof. Basant Kumar Swain and

Asst.Prof. Ramesh Chotiya for providing encouragement, constant
support and guidance which was of great help to complete this seminar
successfully.

I am very grateful to Asst. Prof. Dillip Ranjan Nayak, Head of

the Department of Computer Sc. and Engineering for giving support and
encouragement that was necessary for the completion of this seminar.

I would also like to express my gratitude to Dr. Dulu Patnaik

Principal, Government College of Engineering Kalahandi, Bhawanipatna
for providing us a congenial environment to work in.

Bodhisatwa Kumar
(Regd. No. 1601110053)

ii
 CERTIFICATE

This is to certify that the seminar report entitled ​“​Understanding the AOSP​”
submitted by Bodhisatwa Kumar (Regd. No. 1601110053) to Government
College of Engineering Kalahandi, Bhawanipatna, in partial fulfilment for the
award of the degree of B. Tech in (Computer Sc. and Engineering) is a
bona-fide work carried out by him under our supervision. The contents of this
seminar report, in full or in parts, have not been submitted to any other
Institution or University for the award of any degree or diploma.

Bodhisatwa Kumar
(Regd. No. 1601110053)

iii
 ABSTRACT
AOSP refers to Android open source project. Android runs on Linux kernel and
uses JVM for running its applications. It is currently developed and maintained
by Google. Android activity lifecycle is different from traditional GUI
programming because It saves battery power by calling appropriate methods
when the user is no longer directly interacting with the app GUI. The well
defined sequence (rather cycle) of method calls makes it very intuitive for
programmers. The main thread (UI thread) is restricted from making a set of
non UI related operations (such as network calls). This keeps the activity
running smoothly. Android also offers BroadCast receivers. It triggers code on
the occurrence of an event in Android. For example clicking of a picture or
battery running low etc. So, that all apps don't have to monitor events
themselves.

Bodhisatwa Kumar
(Regd. No. 1601110053)

iv
List of Figures ii
Declaration iii
Certificate iv
Acknowledgement v
Abstract vi
CONTENTS

1.Introduction 1
2.Android Activity Lifecycle 1
2.1.Introduction to lifecycle 2
2.2.Lifecycle callbacks 3
2.2.1. onCreate 3
2.2.2. onResume 3
2.2.3. onPause 4
2.2.4. onStop 4
2.2.5. onDestroy 4

3. Method Overriding in Java 5

4. BroadCasts in Android 6
4.1. Algorithm 6

v
List of Figures

2.7 ​Activity Lifecycle methods

vi
1. Introduction
Android is a mobile operating system based on a modified version of the Linux kernel and
other open source software, designed primarily for touchscreen mobile devices such as
smartphones and tablets. Android is developed by a consortium of developers known as the
Open Handset Alliance and commercially sponsored by Google. It was unveiled in 2007,
with the first commercial Android device launched in September 2008.

It is free and open source software; its source code is known as Android Open Source Project
(AOSP) which is primarily licensed under the Apache License. However most Android
devices ship with additional proprietary software pre-installed, most notably Google Mobile
Services (GMS) which includes core apps such as Google Chrome, the digital distribution
platform Google Play and associated Google Play Services development platform. About 70
percent of Android smartphones run Google's ecosystem; competing Android ecosystems and
forks include Fire OS (developed by Amazon) or LineageOS. However the "Android" name
and logo are trademarks of Google which impose standards to restrict "uncertified" devices
outside their ecosystem to use Android branding.

2. Android Activity Lifecycle

To navigate transitions between stages of the activity lifecycle, the Activity class provides a
core set of six callbacks: onCreate(), onStart(), onResume(), onPause(), onStop(), and
onDestroy(). The system invokes each of these callbacks as an activity enters a new state.
As the user begins to leave the activity, the system calls methods to dismantle the activity. In
some cases, this dismantlement is only partial; the activity still resides in memory (such as
when the user switches to another app), and can still come back to the foreground. If the user
returns to that activity, the activity resumes from where the user left off. With a few
exceptions, apps are restricted from starting activities when running in the background.
The system’s likelihood of killing a given process—along with the activities in it—depends
on the state of the activity at the time. Activity state and ejection from memory provides more
information on the relationship between state and vulnerability to ejection.
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 R.attr.windowIsFloating set), Multi-Window mode or embedded into other windows.

1
2.1 Introduction to lifecycle
Activities in the system are managed as activity stacks. When a new activity is started, it is
usually placed on the top of the current 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. There can be one or multiple activity stacks visible on screen.
An activity has essentially four states:
1. If an activity is in the foreground of the screen (at the highest position of the topmost
stack), it is active or running. This is usually the activity that the user is currently
interacting with.
2. If an activity has lost focus but is still presented to the user, it is visible. It is possible
if a new non-full-sized or transparent activity has focus on top of your activity,
another activity has a higher position in multi-window mode, or the activity itself is
not focusable in current windowing mode. Such activity is completely alive (it
maintains all state and member information and remains attached to the window
manager).
3. If an activity is completely obscured by another activity, it is stopped or hidden. 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.
4. The system can drop the activity from memory by either asking it to finish, or simply
killing its process, making it destroyed. When it is displayed again to the user, it must
be completely restarted and restored to its previous state.

There are three key loops you may be interested in monitoring within your activity:
1. 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().
2. 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
no longer sees what you are displaying. The onStart() and onStop() methods can be
called multiple times, as the activity becomes visible and hidden to the user.

2
 3. The foreground lifetime of an activity happens between a call to onResume() until a
corresponding call to onPause(). During this time the activity is visible, active 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.

2.2 Lifecycle callbacks

2.2.1 onCreate()
You must implement this callback, which fires when the system first creates the activity. On
activity creation, the activity enters the Created state. In the onCreate() method, you perform
basic application startup logic that should happen only once for the entire life of the activity.
For example, your implementation of onCreate() might bind data to lists, associate the
activity with a ViewModel, and instantiate some class-scope variables.
This method receives the parameter savedInstanceState, which is a Bundle object containing
the activity's previously saved state. If the activity has never existed before, the value of the
Bundle object is null.

2.2.2 onStart()
When the activity enters the Started state, the system invokes this callback. The onStart() call
makes the activity visible to the user, as the app prepares for the activity to enter the
foreground and become interactive. For example, this method is where the app initializes the
code that maintains the UI.

When the activity moves to the started state, any lifecycle-aware component tied to the
activity's lifecycle will receive the ON_START event.

2.2.3 onResume()
When the activity enters the Resumed state, it comes to the foreground, and then the system
invokes the onResume() callback. This is the state in which the app interacts with the user.
The app stays in this state until something happens to take focus away from the app. Such an
event might be, for instance, receiving a phone call, the user’s navigating to another activity,
or the device screen turning off.
When the activity moves to the resumed state, any lifecycle-aware component tied to the
activity's lifecycle will receive the ON_RESUME event. This is where the lifecycle

3
components can enable any functionality that needs to run while the component is visible and
in the foreground, such as starting a camera preview.

2.2.4 onPause()
The system calls this method as the first indication that the user is leaving your activity
(though it does not always mean the activity is being destroyed); it indicates that the activity
is no longer in the foreground (though it may still be visible if the user is in multi-window
mode). Use the onPause() method to pause or adjust operations that should not continue (or
should continue in moderation) while the Activity is in the Paused state, and that you expect
to resume shortly. There are several reasons why an activity may enter this state.

2.2.5 onStop()
When your activity is no longer visible to the user, it has entered the Stopped state, and the
system invokes the onStop() callback. This may occur, for example, when a newly launched
activity covers the entire screen. The system may also call onStop() when the activity has
finished running, and is about to be terminated.

When the activity moves to the stopped state, any lifecycle-aware component tied to the
activity's lifecycle will receive the ON_STOP event. This is where the lifecycle components
can stop any functionality that does not need to run while the component is not visible on the
screen.

2.2.6 onDestroy()
onDestroy() is called before the activity is destroyed. The system invokes this callback either
because:

1. the activity is finishing (due to the user completely dismissing the activity or due to
finish() being called on the activity), or
2. the system is temporarily destroying the activity due to a configuration change (such
as device rotation or multi-window mode)
When the activity moves to the destroyed state, any lifecycle-aware component tied to the
activity's lifecycle will receive the ON_DESTROY event. This is where the lifecycle
components can clean up anything it needs to before the Activity is destroyed.

4
 Fig: 2.7 Activity Lifecycle methods

3. Method Overriding in Java

If subclass (child class) has the same method as declared in the parent class, it is known as
method overriding in Java.
In other words, If a subclass provides the specific implementation of the method that has been
declared by one of its parent class, it is known as method overriding.
Usage of Java Method Overriding
1. Method overriding is used to provide the specific implementation of a method which
is already provided by its superclass.
2. Method overriding is used for runtime polymorphism

5
Rules for Java Method Overriding
1. The method must have the same name as in the parent class
2. The method must have the same parameter as in the parent class.
3. There must be an IS-A relationship (inheritance).

4. BroadCasts in Android
Android apps can send or receive broadcast messages from the Android system and other
Android apps, similar to the publish-subscribe design pattern. These broadcasts are sent when
an event of interest occurs. For example, the Android system sends broadcasts when various
system events occur, such as when the system boots up or the device starts charging. Apps
can also send custom broadcasts, for example, to notify other apps of something that they
might be interested in (for example, some new data has been downloaded).
Apps can register to receive specific broadcasts. When a broadcast is sent, the system
automatically routes broadcasts to apps that have subscribed to receive that particular type of
broadcast.
Generally speaking, broadcasts can be used as a messaging system across apps and outside of
the normal user flow. However, you must be careful not to abuse the opportunity to respond
to broadcasts and run jobs in the background that can contribute to a slow system
performance, as described in the following video.

4.1 About system broadcasts

The system automatically sends broadcasts when various system events occur, such as when
the system switches in and out of airplane mode. System broadcasts are sent to all apps that
are subscribed to receive the event.
The broadcast message itself is wrapped in an Intent object whose action string identifies the
event that occurred (for example android.intent.action.AIRPLANE_MODE). The intent may
also include additional information bundled into its extra field. For example, the airplane
mode intent includes a boolean extra that indicates whether or not Airplane Mode is on.
For more information about how to read intents and get the action string from an intent, see
Intents and Intent Filters.