Introduction

Android is a platform for mobile devices (phones, PDAs, netbooks, tablets, etc.). It is
composed of an operating system, middleware libraries, and a set of applications: a
client email, a browser, a calendar, etc.

Android is based on a Linux kernel. The middleware libraries that compose it are written in C/C++.
The framework is written in Java.

OHA

Android is developed by the OHA (Open Handset Alliance), an international alliance of companies. This
alliance consists of companies that are not part of the same sector.

Thus it is composed:

mobile operator (Vodafone, Telefonica, Telecom Italia, China Mobile, etc.)

mobile phone manufacturers (Asus, HTC, LG, Motorola, etc.)
from semiconductor manufacturers (Intel, Nvidia, ARM, etc.)
software publishers (Ebay, Google, PacketVideo, etc.)
distributors (Aplix corporation, Borqs, TAT)
Today there are 2 billion televisions in the world. 1.5 billion people have access to the internet.
But nearly 4 billion people have a mobile phone, which means that the mobile phone is
the most successful product in the world. That is why the OHA has embarked on the
mobile sector. They hope to provide an innovative and high-performance mobile platform that offers to
users a new mobile usage experience.

History

In July 2005, Google acquired Android, Inc., a small startup that was developing applications for
mobile phones. It was at that time that rumors about Google's entry into the sector began.
Mobile had begun. But no one knew which markets they were going to position themselves in.

After this acquisition, at Google, a team led by Andy Rubin, a former member of Android Inc, began to
work on a mobile operating system based on Linux. For 2 years, before the OHA
officially created, a number of rumors have circulated about Google. It has been said that
Google was developing mobile applications for its search engine, which they were developing a
new mobile phone, etc.

In November 5, 2007, the OHA was

officially announced, as well as
but. Develop standards
open source for mobile devices.

The the first announced standard was

Android, a platform for
mobile devices based on a
kernel linux 2.6.

In September 2008, the first version

the stable version of the SDK has been released, to date

the latest version is 1.2.

Characteristics:

- Framework: Java framework for development

application for the Android platform
- Dalvik virtual machine: Special virtual machine
développée pour Android. Cette machine virtuelle permet
to run the Java applications developed with the Framework.
- Web Browser: Web browser based on the rendering engine
WebKit. WebKit is a software library that allows for
developers to easily integrate a rendering engine
web pages in their software.
- Graphic: 2D graphics library, 3D graphics library based
on OpenGL ES 1.0. Hardware acceleration possible. which defines
a cross-platform API for application design
generating 3D images derived from the OpenGL specification, under
a form adapted to mobile platforms.
- Storage: SQL database: SQLite is used for the
data storage.
- Media: Android supports audio/video/image formats
following: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF
- Connectivité:gsm, edge, 3G, bluetooth, wifi
- Hardware Support: Android is capable of using Camera, GPS,
accelerometer...
- Development environment: Android has a
complete development environment containing: a
emulator, a debugger, a memory and performance analyzer, and a plugin
eclipse.
 Architecture of the Android system

1- General overview:

Android is based on a Linux [Link] kernel, above the kernel is the hardware abstraction layer.
which allows separating the logical platform from the hardware.

Above this layer of abstraction, we find the C/C++ libraries used by a certain
name of components of the Android system.

Above the libraries, we find the Android Runtime; this layer includes the core libraries of
Framework as well as the virtual machine running the applications.

Above the 'Android Runtime' layer and the core libraries, we find the Framework that allows
to the developer to create applications. Finally, above the Framework, there are the applications.
 2- Linux Kernel :

Android is based on a Linux 2.6 kernel but it is not Linux. It does not have a system of
native windowing (X window system), glibc is not supported, Android uses a custom libc
called Bionic libc.

Finally, Android uses a kernel with different patches for power management, sharing
memory, etc. allowing for better management of these characteristics for mobile devices.

Android is not Linux but it is based on a Linux kernel.

Why on a Linux kernel?

The Linux kernel has a memory and process management system recognized for its
stability and its performance.
The security model used by Linux, based on a permission system, known for
to be robust and efficient. It has not changed since the 1970s.
The Linux kernel provides a driver system allowing an abstraction with the
material. It also allows for the sharing of libraries between different processes, the
loading and unloading of hot modules.
the Linux kernel is completely open source and there is a community of
developers who improved it and added drivers.

It is for the points mentioned above that the team in charge of the core decided to use a
Linux kernel.

Modifications made to the kernels

The Android kernel has been patched with different patches:

Alarm

This patch provides a number of timers that allow, for example, to 'wake the device when it
is in sleep mode

Ashmem

Android shared memory

This patch allows applications to share memory. This management is done at the kernel level due to
that memory sharing is very used in the Android platform because memory in devices
mobiles est limitée par rapport à des PC.

Memory sharing is mainly used by the Binder.

Binder - Android IPC

Interprocess communication (IPC) can lead to security holes, which is why Android has
its own IPC, the Binder, and that interprocess communication is not left to developers
of the application. Moreover, having a centralized IPC system allows for easier maintenance and a
correction of general security issues.

In Android, each application runs in a different process. These different processes have
Need to communicate together, to share data. This IPC is possible with the Binder.

It allows multiple processes to share data, to communicate with each other using the
memory sharing (ashmem driver). This technique allows for improved performance compared to
copy data into memory, or serialization.

Concurrency issues, when multiple processes try to access at the same time to a
Same memory zone (on the same java object) is managed by the Binder. All calls are synchronized.
between the processes.

Operation

IPC
With its emphasis on isolating apps and services in process boundaries, it is clear that Android
requires a lightweight IPC. The IPC mechanism in Android is called Binder and is based on
shared memory. Recall that when a process starts it registers itself with the Service Manager.
This happens behind the scenes, and upon registration, each process gets what is called
aContextobject – a reference to the Service manager. Now let's say app A needs to
communicate with service B, and the two are running in two separate processes. To do this, app
A asks the Context for Service B by passing the well known name of the service. The Context
returns a reference to the service to A, on which A can call a method–say foo. This method call
is intercepted by the Binder driver. The driver marshals the object and passes a reference of it to
the receiver–B. Note that this is passing by reference, not passing by value, in which the object
is serialized. On the side of the service B, the Binder maintains a thread-pool (transparent to the
service). One of the threads in this pool receives the incoming call, locates the actual object in the
service B and make the call. The return value is then similarly passed back to the caller.
following diagram (from[Link]
illustrates this:

Application A retrieves a reference to Service B using the Context Manager. The Context Manager
can be compared to a DNS. It allows retrieving a reference to a Java object using a name.
For those who know RMI (Remote Method Invocation), it is the registry. If we want to share some
objects must first be registered in the Context Manager.

Once the reference to service B is retrieved, the foo() method of service B is called by
the application A. The binder intercepts this call, and with the help of one of the free threads present in its thread
pool (thread pool or thread reservoir), it will execute the method on service B.

Food management:

Issue:

Mobile devices depend on battery power and batteries have a limited capacity.

Power Management Properties

o Power Management is built on top of the standard Power Management
Linux.
o Power Management supports a more aggressive power management policy.
o Components make requests to remain on standby through 'Wake Locks'.
o Power Management supports different types of 'Wake Locks'.
 If there are no active 'Wake Locks', the processor will be disabled.
If there are no partial 'Wake Locks', only the screen and the keyboard will be turned off.

Android supports its own Power Management (based on the standard Linux Power Management),
designed on the principle that the CPU should not consume energy if none of the applications or
services require a power supply.

Android requires applications and services to request CPU resources with 'Wake Locks' at
through the Android Application Framework and the native Linux libraries.

If there are no active 'Wake Locks', Android will stop the CPU.

The image below illustrates the Android power management architecture.

Types of 'Wake Locks'

Wake Lock Description

ACQUIRE_CAUSES_WAKEUPUsually, wake locks do not wake up the device, they will

just get him to stay awake once it's already done.

Think of the video player app as a common behavior. The

notifications that arise and want the device to be awake are the
exceptions; use this option to be like them.

FULL_WAKE_LOCK Wake lock that ensures the screen and keyboard are fully on
brightness.

ON_AFTER_RELEASE When this wake lock is released, reset the activity timer.
the user so that the screen stays on for a little longer.

PARTIAL_WAKE_LOCK Wake lock that ensures the CPU is on. The screen may not
to be on the move.
 3- The Bookstores

Above the kernel are the native libraries. These libraries are written in C/C++. They provide the
low-level features of Android.

Bionic Libc

Android does not support glibc, which is why we developed a C library (libc) called Bionic libc. It is
optimized for mobile devices and was developed especially for Android.

The Android platform needs its own libc because it needed a lightweight libc (the libc will be loaded
in each process) and fast (mobile devices do not have powerful CPUs).

The Bionic libc was written to support ARM CPUs, although x86 support is present. There is no
support for other CPU architectures such as PowerPC or MIPS. Nevertheless, for the market of
mobile devices, only the ARM architecture is important.
The ARM architectures, developed byARM Ltd are 32-bit RISC architectures.

Equipped with a relatively simpler architecture than other families of processors, and benefiting from a
low power consumption, ARM processors have become dominant in the field of computing
onboard, particularly mobile telephony and tablets.

These processors are manufactured under license by a large number of manufacturers.

This libc is under the BSD license, it incorporates a large part of the code from glibc derived from OpenBSD,
FreeBSD and NetBSD.

Features:
It has a size of about 200KB, which is half of glibc.

The implementation of pthreads (POSIX thread) has been completely rewritten to support threads.
from the Dalvik virtual machine. As a result, the Bionic libc does not support POSIX threads

C++ exceptions and 'wide char' are not supported

There is no 'Standard Template Library' (STL)

The Standard Template Library (STL) is a C++ library standardized by ISO.

ISO/IEC 14882) and implemented using templates.
This library provides:

. a set of container classes, such as vectors (vector), arrays

associative (map), linked lists (list), which can be used to contain
any type of data provided it supports certain operations such as
the copy and the assignment.
. an abstraction of pointers: iterators. They provide a simple way and
elegant to traverse sequences of objects and allow for the description of algorithms
independently of any data structure.
. generic algorithms such as insertion/deletion algorithms, search
and three.
. a class string that allows for efficient and safe management of strings
characters.
WebKit :

WebKit is a software library that allows developers to easily integrate a

web page rendering engine in their software. It is available under a BSD license and
GNU LGPL. Originally reserved for the Mac OS X operating system (starting from the
version 10.3 Panther), it was ported to Linux and Windows. Thus, the porting of WebKit
for the GTK+ and Qt environments are called WebKitGTK+ and QtWebKit respectively.
WebKit is a fork of the KHTML rendering engine from the KDE project used notably in the
Konqueror browser. It integrates two sub-libraries: WebCore and JavaScriptCore
corresponding respectively to KHTML and KJS.
WebKit is a rendering engine that provides a library on which one can develop a
web browser. It was originally derived by Apple from the KHTML rendering engine to be
used by the Safari web browser and is now developed by the KDE project, Apple,
Nokia, Google, and others. WebKit consists of two libraries: WebCore and
JavascriptCore which are available under GPL license.

WebKit supports CSS, Javascript, AJAX. The version of WebKit present in Android has been
slightly modified to adapt to mobile devices.

Media framework

The Media Framework library is based on OpenCore from PacketVideo. It enables support for
audio/video/images standards.
Android Media Framework is built on top of a set of libraries of
media, including OpenCore, vorbis, and SONiVOX. So, one of the objectives of Android Media
The framework is to provide a consistent interface for all services provided by the
underlying libraries and make them transparent for users.

The figure below shows the dependency relationships between the media libraries.
framework.

In this figure, the green components are the media libraries, the internal Android libraries are
yellow components, the gray components are the external libraries, and the class of
light blue is the Java consumer of the media framework. Except for the class
[Link], all components are implemented in C or C++.

The core of the Media Framework is composed of libmedia, libmediaplayerservice, and libmedia_jni.

libmedia defines the inheritance hierarchy and the base interfaces. It is the core library.

libmedia_jni is the intermediary between the Java application and the native library. First, it
implement the JNI specification (The JNI (Java Native Interface) is a framework that allows for
Java code running inside the JVM to call and be called by applications
natives (that is to say specific programs to the hardware and operating system of the
platform concerned), or with software libraries based on other languages (C,
C++, assembler, etc.) so that it can be used by a Java application. Secondly, it
implement the facade model for the convenience of the caller.
libmediaplayerservice concretely implements certain Media Players and services
media that will manage the instances of these readers.

What is interesting to note in Android is that the application that intends to display the
Media content and the player that actually displays this content (audio, video...) function
in different processes. The red line in the sequence diagram below shows the
limit of two processes.

The figure shows the three most common operations: creating a new Reader, updating
DataSource and Reading. The last object MediaPlayerBase is the interface which object
MediaPlayerService::client is used to refer to the instance of the concrete player. The player
 concrete can be VorbisPlayer, pvPlayer, or any other Player, depending on the type of
average you.

When an application creates an [Link] object, it actually uses a Proxy object.

to manipulate the Concrete Player residing in the MediaServer process. Throughout the
procedure, two processes communicate with Binder IPC.

Having the above knowledge, it is not difficult to understand why MediaPlayer does not
does not provide an API to use as a memory stream source. Because the memory manipulated
by the flow is in the application's address space, and it is not directly accessible by
the media server process.

The diagram below describes all the features provided by this library:

Media libraries – based on OpenCore's PacketVideo; the libraries enabling playback and

audio and video recording, as well as image file management, including MPEG4, H.264,

MP3, AAC, AMR, JPG and PNG.

The diagram below describes all the elements of the architecture of these media libraries:

SURFACE FLINGER :

The Surface Flinger allows for the construction of graphical rendering; it manipulates all the surfaces to be displayed.
coming from the frame buffer. It can combine 2D and 3D from different applications.
The surfaces to be displayed have passed through buffers via the Binder.
The surface flinger uses a double buffer allowing for quick switching from one surface to another.
This double buffer also ensures that incomplete surfaces are never displayed, as the second
The buffer is only displayed when it is full. The two buffers are used alternately.

It can use OpenGL ES and hardware acceleration for 2D rendering using the Khronos API.

Audio Flinger

The audio flinger manages all audio devices. It processes audio streams and routes them to the devices.
output (speaker, Bluetooth, headset).
The Hardware Abstraction Layer

This layer is situated between the libraries and the Linux kernel, it provides the interfaces that must
implement the kernel drivers. This layer separates the logical platform from the hardware interfaces. The
The purpose of this layer is to facilitate the portability of libraries across different hardware.

The designers of Android decided to create this layer because:

Kernel drivers do not all have standardized interfaces.

kernel drivers are under GPL license which would expose the proprietary interfaces of
Manufacturers. Manufacturers want to be able to keep these interfaces 'closed source'.
Android has specific needs for kernel drivers.
Android Runtime
This layer is situated above the C/C++ libraries, it consists of the 'core' of the Framework and the
Dalvik virtual machine.

Dalvik

The Dalvik virtual machine is based on a register architecture like many machines.
virtual and the Java virtual machine that has a stack architecture.

Using a stack or register architecture depends on the strategies of compilation and interpretation.
choose. Generally, machines based on a stack architecture must use instructions
to load the data onto the stack and manipulate this data. This adds instructions into the
code machine, and therefore there is more code than for a machine based on a register architecture.

However, instructions for a machine based on a register architecture must be

encoded for source and destination registers, which also takes up space in the code
resulting machine. The difference is essentially important depending on the machine code interpreter
present in the VM.

Java applications developed for Android must be compiled in the Dalvik executable (.dex) format.
with the dx tool. This tool compiles .java files into .class files and then converts these .class files into .dex. A .dex can
containing multiple classes. The duplicated strings and other constants used in multiple classes
are grouped in a .dex. The bytecode used in .dex is Dalvik bytecode and not Java.
Bytecode.

For comparison, a decompressed .dex is a bit smaller in size than a compressed .jar derived from
same .class files.

Being optimized to use minimal memory, the Dalvik VM has a few characteristics
specific compared to other VMs:

the VM was 'degreased' to use less memory space

no just-in-time compilation
She uses her own bytecode and not the Java bytecode.
The constants table has been modified to use only 32-bit indexes to simplify.
the interpreter.
Core Libraries

The Core libraries provide the Java language available for applications. The Java language comes with
Android largely takes over the JSE 1.5 API. There are things that have been set aside because they were not
of meaning for Android (like printers, swing, etc.) and others because of specific APIs
are required for Android.

JSE 1.5 packages supported by Android Packages JSE 1.5 unsupported by Android
[Link] [Link]
[Link] (except [Link]) [Link]
 support [Link]
[Link] [Link]
[Link] [Link]
[Link] [Link]
[Link] [Link]
[Link] [Link]
[Link] [Link]
[Link] [Link]
[Link] [Link]
[Link] [Link]
[Link] (except [Link]
[Link]
[Link]
[Link] and
[Link] [Link]
[Link] [Link]
[Link] (except [Link]) [Link]
[Link] [Link] (except [Link])
[Link] [Link].*
[Link] [Link].*
[Link].*

Specific libraries added to the Core Libraries of Android:

[Link]
[Link]
[Link]
[Link]
The Application Framework:

The framework is located above the Android Runtime and libraries. It provides APIs that allow for
developers to create rich applications.

Core Platform Services

Android introduces the concept of services. A service is an application that has no interaction with
the user and runs in the background for an indefinite time.
The core services of the platform (Core Platform Services) provide essential services to
functioning of the platform:

Activity Manager: manages the application lifecycle and maintains a 'navigation stack'
(navigation backstack) allowing you to go from one application to another and return to the
previous when the last opened application is closed.
Package Manager: used by the Activity Manager to load information from the
APK files (Android Package Files)
Window Manager: just above the Surface Flinger (link), it manages the windows of applications:
Which window should be displayed in front of another on the screen?
Resource Manage: Manages everything that is not code, all resources --> images, files
audio, etc.
Content Provider: manages the sharing of data between applications, such as the database
contact data, which can be accessed by other applications besides the Contact app.
Data can be shared through a database (SQLite), files, the network, etc.
View System: provides all the graphical components: lists, grid, textbox, buttons, and even a
embedded web browser.
Hardware Services

Hardware Services provide access to low-level hardware APIs:

Telephony Service: allows access to 'telephony' interfaces (gsm, 3G, etc.)

Location Service: permet d'accéder au GPS.
Bluetooth Service: allows access to the bluetooth interface.
WiFi Service: allows access to the Wifi interface.
USB Service: allows access to USB interfaces.
Sensor Service: allows access to sensors (light detectors, etc.)
The Startup Process:

A-Like any Linux system, at startup the bootloader loads the kernel and starts the
init process. The father of all processes.
B-Then a certain number of daemons are launched by the init process:

USB daemon (usbd)

Android Debug Bridge (adbd)
Debugger Daemon (debuggerd); It allows managing debug requests from
process (dump memory, etc.)
Radio Interface Layer Daemon (rild)

Thereafter, the init process launches the Zygote process. At startup, an instance
special Java virtual machine is launched, called zygote. This process loads a
basic Java classes and perform their initial processing, making it possible
to avoid this step for each app launch. Once the initial work is
Indeed, the process is waiting for requests by listening on a socket.

The Zygote process:

 initialize an instance of the Dalvik VM
Pre-load the base classes and listen on a socket to create Dalvik VMs
Fork on demand to create Dalvik VM instances for each [Link] ()
crée un nouveau processus en dupliquant le processus appelant. Le nouveau processus,
called the child, is an exact copy of the calling process, called as parent
The created VMs share common memory areas, which helps minimize the
used memory
Each VM created by zygote is a fork of a "mother" VM, which allows for acceleration
starting an application.

Then the initialization process starts the Runtime process which will in turn launch the Service Manager.
("DNS" providing a way to communicate with a service by its name, responsible for
the management of the IPC allowing to record and retrieve references to Android services
and register this Service Manager as the default Context Manager.

C-Once all of this is done, the Runtime process sends a request to the zygote process itself.
requesting to launch the System Server. Zygote will fork a new instance of Dalvik VM
for the System Server process and start the service. This is the first process (after
Zygote) which executes an instance of Dalvik VM.
The D-Le System Server will launch the Audio Flinger and the Surface Flinger, which will then ...
register with the Service Manager.
The E-Le System Server then launches the Android services (window manager, manager
telephony, Power Manager, activity manager, etc...). These services once launched
will register with the Service Manager.

Once all services are loaded, the system is ready. User applications can be
launched.
At this stage, we have the following processes in place:

1. Init - the original initialization process began with the boot program

2. Demons - started by init

3. Runtime - also started with init

4. Zygote - the original zygote that will endlessly create forks for new applications.
be launched

5. System Server - the first managed process that contains all the services and components of the
base platform.

After that, the home screen or screensaver is launched - essentially the task manager.
(which is inside the server system) sends a message to Zygote to launch the 'Home' activity, this
which causes Zygote to fork into a new process of a Dalvik VM for the activity
"Home." Now, depending on the action taken by the user, the appropriate application would be
launched with the Zygote fork each time to create a new VM instance in a new
process. Thus, for example, if the user launches the Contacts application, the apt process would be
installed

Each new application receives a unique user ID that is unknown to the application, and the
system defines permissions for all files in the application so that only the ID
the user assigned to the application can access these files. this makes the system secure since
It is the only application that has access to the components it needs to do its job and nothing else.
other. However, applications may need to communicate with each other and with the
system services, which are all executed in separate processes. This is accomplished through the
Binder IPC

Applications
An Android application is a collection of components. There are four types of components:

Activity: An activity is a user interface component corresponding to a screen with

which a user interacts in order to do something.
Service: a service is a component of the application without a user interface used for
perform long operations in the background.
Broadcast Receiver: is an element that responds to system-wide broadcasts.
example for the screen off, low battery, etc)

Content provider: A content provider is an element that stores and retrieves the
data and makes it available to all applications. There are different types of
content providers: audio, video, contacts, etc. and you can create your own
content provider as well.
As mentioned earlier, each application runs in its own process. By default, all components used
by that app also run in the same process, and on the main thread. However, it is possible to make
a component of your app runs in a separate process through the manifest file. Thus, an application in
Android may span multiple processes.

As mentioned earlier, each application runs in its own process. By

default, all the components used by this application are also executed in the same
process, and on the main thread.

However, it is possible to create a component of your application running in a process.

separated through the application's 'manifest' file. Thus, an application on Android can
to cover several processes.

Starting an Application
Android is quite a unique model in that there is no single entry point for a
application - there is no main() function.

On the other hand, a component in an Android application can start another in another
application. This communication between applications happens through the IPC mechanism
described previously. Thus, while the activity is held by an application, it is possible for
another application of the launcher (if the proprietary application allows it).

An example is clicking on a hyperlink in an application that opens the browser. This

applies not only to activities, but also to other types of components. To do this, it
there are two necessary steps:

1. In the event that the application is not already launched, the Android system would bring the application to the
lives in a new process by forking the zygote.

The desired component within the application would need to be activated.

Note that in the case where the application is already running, the new component will be instantiated by
defect in the same process.

As mentioned above, the IPC goes through a 'Context' object. So, when a component
"A" inside an application must activate another component "B" in an application
different, or give him something new to do, he essentially uses the object
« Context » to send a message to the other component. In the case of an activity, service or
A BroadcastReceiver takes the form of what is called an 'Intent.'
It is a passive data structure that defines the operation to be performed for an activity and a
service, and for a BroadcastReceiver, it is a definition of the ongoing broadcast declaration.

Content providers are not activated by Intentions, however. Instead, the activation
occurs at the request of a ContentResolver, which acts as a mediator between the component
requester and the content provider.

The Back-Stack
Let's consider the following scenario:

1. You are on the home screen. This is activity 1.

2. You click on the Mail application icon, which activates the main activity in the Mail application.
which appears in the foreground. It is activity 2

3. You now click on Compose, which activates the composing activity in the application.
Mail. This is activity 3

4. You decide to cancel composing a new message and press the back button.
You are returning to activity 2
Here is what is happening in the background:

When one activity starts another, it stops and its state is saved. So, when
Activity 1 starts Activity 2, activity 1 is stopped, its state saved and so on.

The system maintains a stack (called a Back-Stack) with the latest activity on top and the
older activity at the base.

When the user presses the back button on the device, activity 3 is removed from the stack and
Activity 2 has started from its saved state.

The Tasks
In the scenario described above, it is assumed that when the user has been in the application
New Mail (Activity 3), he decided to call someone and pressed the Home button. It's not going to
do not unstack theback-stackbut start a new stack. To do this, the collection of activities
in the first stack needs to move to the background. This is achieved through the concept of 'task'

A task is a coherent unit of Activities. When a task moves to the background, all the
activities in this task are stopped, but theback-stackthe task remains intact, so that
when the user returns to the task, it can resume where it left off. However, for
save memory, theback-stacka background task is not retained for a very long time
period and if the user does not return to the task, theback-stackis erased, with the exception of the activity
root.
Life cycle of an activity
The life cycle of an activity is influenced by its association with other activities, its
mission and its back stack. There are three states in which an activity can exist:

• Replay / In execution: The activity is at the forefront and has user focus. Such
activity is never killed by the system.

• On Pause: The activity is visible, but another activity is in the foreground and has the focus
user. This could happen if the other activity is at its peak, but it is translucent, or
because it does not cover the entire screen. In the pause state, the activity is preserved in
memory, maintains all state information and remains attached to the window manager.
However, it can be killed under extremely low memory conditions.

• Stopped: the activity is not visible to the user. While the activity is retained in
memory, keeps all state information, it does not remain attached to the manager of
windows. The activity can be killed by the system to recover memory if
necessary.
State of activity recording
In order to recover memory, note that it is quite possible that the system can
to destroy an activity, or even the process in which the activity was underway. However,
when the user returns to the activity (via the back stack), we resume from the point where the user
left. To do this, an activity must record its state. This happens through the method
onSaveInstanceState ().
Process life cycle
The Android system may need to kill a process in order to recover from
memory. In order to ensure that this creates minimal impact on the user experience,
Android organizes processes in a priority order:
•Foreground process: A process that is required for what the user is in.
such a process is only killed as a last resort
• Visible processes: This process is not at the forefront, but it can affect what
the user sees on the screen. For example, it can host a paused activity. Such
the process is not killed unless it is necessary to maintain all the processes of the
first plan, in execution
• Processus Service: A process that executes a service and is not one of the two types mentioned.
on top. For example, the service can play music or download
something. The system can keep such a process running as long as there is enough
memory to keep the foreground processes running and visible.
Background process: A process that manages an activity that is not currently
visible to the user (the activity is stopped). Such a process has no impact on the experience
user (if the activity lifecycle is correctly implemented and the activity status
is correctly saved and restored). The system can kill such a process at any
Usually, there are several background processes and the system maintains
a LRU list that is used to kill these processes.
• Empty processes: an empty process holds no active components. The only reason for
that such a process be kept alive, first of all, is for caching and
the improvement of startup time. The system often kills these processes in order to
maintain the balance between process caches and the underlying kernel caches.
Of course, it can happen that a high-priority process is dependent on a process of
low priority. In such a case, the ranking of the serving processes increases to the same level as
that of the dependent process.

A situation where this ranking has a direct impact is as follows:

Your application needs to download something large that may take time and
The user is likely to move away from the application's activity to something else.

If you create a thread for this task and the user moves, the process becomes a
background process.

However, if you create a service instead, the process would be a service process and will be
less likely to be killed

Main / UI Thread
When an application is launched and a new process is created to host it, the application
receives a single thread called the main thread or the interface thread since this thread is
responsible for the user interface service.

The way it works is mostly the same for almost anything.

user interface implementation - whether it is desktop operating systems or
mobile OS.

Basically, the user interface thread runs an infinite loop that checks a queue.
waiting to see if there are any ongoing user interface events. In the case of Android, this
The concept is formalized in the form of a looper.

Le looper traite une MessageQueue (file de messages) qui contient les messages à être expédiés. La
The actual task of queue management is carried out by a manager who is responsible for the
manipulation (adding, removing, dispatching) of messages in the message queue.
For the main thread, a Looper is set up by the system. However, you can also
associate a Looper with your own thread.

Note that the Looper can be associated with a single thread and that the association cannot be
changée.

The way Android ensures this (the association cannot be changed) is by using the looper.
on the thread local storage of the thread and not expose a constructor for the Looper.

So of course, we should not perform a blocking operation on the interface thread.

user. If you do, the messages in the queue will stop being processed and your
The application stopped responding.

The Services
As mentioned earlier, a service is a type of component that is used to achieve
a background operation, and does not provide a user interface. A component of a
the application can start a service, and even if the user switches from the application, the service
continues to operate.

A typical use case is to play music and download a file. Android ensures for
a process of executing a service so that it is not killed as much as possible (see lifecycle of
above process).

Note that by default, a service runs on the main UI thread in the same process. This
means that if we perform a blocking operation, your interface will no longer respond, because the
thread would not be available to execute the activity. To work around this, you must start a
work thread within the service.