Android Package file

 An archive file with .apk suffix.

 a single .apk file is considered to be one application and
is the file that Android-powered devices use to install
the application.
APK file contains all the contents of an Android app
 Application fundamental

 Application lives in its own sequrity sandbox.

 Each application is a different user.
 Each application given a user ID by system.
 Each process has its own virtual machine (VM).
 Every application runs in its own linux process.
 Sharing data b/w Application

 Two application can share the same linux user ID, in

which case they are able to access each other's files.

 An application can request permission to access device

data such as the user's contact, SMS message, SD card
camera, blutooth. All application permissions must be
granted by the user at install time.
 Application Components

 Essential building blocks of an Android application.

There are four different types of app components.

- Activities
- Services
- Content providers
- Broadcast receivers

Android applications consist of loosely tied components.

Components of one app can invoke or use components of
other apps.
 Activity
- An activity represents a single screen with a user
interface.
- Activities always take the entirety of the visual area
and are made to be stacked on top of one another.
- Android intent allows an activity to be displayed as an
icon on the app launcher
- stack of activities is called a task.user can switch to
another task by clicking the Home button and starting
another activity stack from the app launcher.
- An activity is implemented as a subclass of Activity.
 Service
- Android Services are background processes which
perform long-running operations
- A service is activated when another component requires
its services and typically remains active for the
duration required by its caller.
- A service does not provide a user interface.
- an activity, can start the service and let it run or bind to
it in order to interact with it.
 Broadcast Receiver
- Broadcast Receiver responds to system-wide broadcast
announcements.
- Although broadcast receivers don't display a user
interface, they may create a status bar notification to
alert the user when a broadcast event occurs.
- when event occurs, a broadcast receiver is triggered to
handle that event on the app’s behalf.
- When not handling a specific event for which they are
registered, broadcast receivers are otherwise inactive.
 Content Provider
- A content provider manages a shared set of app data.
- an app will include a content provider if it needs to make
its data accessible to other apps.
- Content provider mech so that other apps can query or
even modify the data
- A content provider presents data to external
applications as one or more tables
 Intent
- Intent is an asynchronous message
- Intents bind individual components to each other at
runtime ( late-binding mechanisms)
- Three of the four component types—activities, services,
and broadcast receivers—are activated by intent.
- content provider, is not activated by intents. Rather, it
is activated when targeted by a request from a
ContentResolver.
- The content resolver handles all direct transactions
with the content provider.
 Intent cont..

- Intent can start an activity by passing an Intent to

startActivity() or startActivityForResult() (when you
want the activity to return a result).
- Intent can start a service (or give new instructions to
an ongoing service) by passing an Intent to
startService(). Or you can bind to the service by
passing an Intent to bindService().
- Intent can initiate a broadcast by passing an Intent
to methods like sendBroadcast(),
sendOrderedBroadcast(), or sendStickyBroadcast().
- Intent can perform a query to a content provider by
calling query() on a ContentResolver.
 Process and Threads
- all components of an app are contained within a single
Linux process.
- Whenever an app’s component is activated,a process will
be started to house that app’s components.
- When there are too many processes running to allow for
new ones to start, the Linux kernel’s out-of-memory
(OOM) killing mechanisms will kick in.
- Android’s behavior is predicated on low-memory
conditions.
 Android Architecture
--- Linux Kernel ---

- Android apply their own patches to linux kernel to fix

bugs and enhance the performance or customize the be‐
havior of certain aspects.
- “Androidized” kernel significantly different from what
was found in the “vanilla” kernel.
 Android Architecture
--- Wakelocks ---
-The wakelocks and early suspend functionality are
actually built on top of Linux’s existing power
management functionality.
- Androidized kernel is made to go to sleep as soon and as
often as possible. And to keep the system from going to
sleep while important processing is being done or while
an app is waiting for the user’s input, wakelocks are
provided to keep the system awake.
- Wakelocks and their correlated early suspend
mechanisms have been merged into the mainline kernel.
The early suspend replacement is called autosleep, and
the wakelock mechanism has been replaced by a new
epoll() flag called EPOLLWAKEUP .
- Driver developers can call on the added in-kernel
wakelock primitives to grab and release wakelocks.
 Android Architecture
--- Low Memory Killer ---
- Android’s behavior is very much predicated on low-
memory conditions. Hence, out-of-memory behavior is
crucial.
- The Android development team has added an additional
low-memory killer to the kernel that kicks in before the
default kernel OOM killer.
- Android’s low-memory killer applies the policies, weeding
out processes hosting components that haven’t been
used in a long time and are not high priority.
- The OOM adjustments range from −17 to 15, with a
higher number meaning the associated process is a
better candidate for being killed if the system is out of
memory.
 Android Architecture
--- Binder ---
- Binder is a cornerstone of Android’s architecture. It’s
what allows apps to talk the System Server, and it’s what
apps use to talk to each others' service components,
- app developers don’t actually talk to the Binder directly.
Instead, they use the interfaces and stubs generated
by the aidl tool.
- Since the 3.3 release of the Linux kernel, the Binder
driver has been merged into the staging tree.
 Android Architecture
--- Anonymous Shared Memory (ashmem) ---
- Shared memory ,in Linux usually provided by the POSIX SHM
functionality, part of the System V IPC mechanisms.
- Android development team find use of SysV IPC mechanisms
in Linux can lead to resource leakage within the kernel
- Ashmem it uses reference counting to destroy memory
regions when all processes referring to them have exited, and
will shrink mapped regions if the system is in need of
memory.
- Typically, a first process creates a shared memory region
using ashmem, and uses Binder to share the corresponding
file descriptor with other processes with which it wishes to
share the region. Dalvik’s JIT code cache, for instance, is
provided to Dalvik instances through ashmem. A lot of
System Server components, such as the Surface Flinger and
the Audio Flinger, rely on ashmem.
 Android Architecture
--- Alarm ---
- Android’s alarm driver is actually layered on top of the
kernel’s existing Real-Time Clock (RTC) and High-
Resolution Timers (HRT) functionalities.
- Android’s alarm driver uses the kernel’s HRT functionality
to provide alarms to its users, much like the kernel’s own
built-in timer functionality. However, if the system is
about to suspend itself, it programs the RTC so that the
system gets woken up at the appropriate time. Hence,
whenever an application from user-space needs a specific
alarm, it just needs to use
Android’s alarm driver to be woken up at the appropriate
time, regardless of whether the system is suspended in
the interim.
- Alarm Manager service part of the System Server uses it
to provide alarm services to apps that are exposed to app
developers through the AlarmManager class.
 Android Architecture
--- Logger ---
- It analyze a system’s logs for errors or warnings either
postmortem or in real time can be vital to isolate fatal
errors.
two logging systems:
- kernel’s own log, seen by dmesg cmd
- system logs, stored in files in the /var/log directory
- The kernel’s log usually contains the messages printed
out by the various printk() calls made within the kernel,
either by core kernel code or by device drivers.
- Android defines its own logging mechanisms based on
the Android logger driver added to the kernel.
 Android Architecture
--- Logger Cont.. ---
- Android’s logging functionality manages a handful of
separate kernel-hosted buffers for logging data coming
from user-space. Hence, no task-switches or file-writes
are required for each event being logged.
Instead, the driver maintains circular buffers in RAM
where it logs every incoming event and returns
immediately back to the caller.
- Because of its lightweight, efficient, and embedded-
system-friendly design, Android’s logger can actually be
used by user-space components at runtime to regularly log
events. In fact, the Log class available to app developers
more or less directly invokes the logger
driver to write to the main event buffer.
 Android Architecture
--- Logger Cont.. ---
- logger driver is the core building block on which all other
logging-related functionality relies. Each buffer it
manages is exposed as a separate entry within /dev/log/.
However, no user-space component directly interacts with
that driver. Instead, they all rely on
liblog, which provides a number of different logging
functions.
- Depending on the functions being used and the parameters
being passed, events will get logged to different buffers.
The liblog functions used by the Log and Slog classes.
- Slog class will send it to the “system” buffer. The “main”
buffer is the one whose events are shown by the logcat
command when it’s issued without any parameters.
- Log and EventLog classes are exposed through the app
development API, while Slog is for internal AOSP use only.
 Android Architecture
--- Logger Cont.. ---
- Typically, EventLog is used by system components to log
binary events to the Android’s “events” buffer.
- Some system components, especially System
Server−hosted services, will use a combination of Log ,
Slog , and EventLog to log different events.
- An event that might be relevant to app developers, for
instance, might be logged using Log , while an event
relevant to platform developers or system integrators
might be logged using either Slog or EventLog .
- The logcat utility, which is commonly used by app
developers to dump the Android logs, also relies on
liblog.
 Android Architecture
--- Logger Cont.. ---
- Another feature of liblog is that it requires every event
being logged to have a priority, a tag, and data. The
priority is either verbose , debug , info , warn , or
error . The tag is a unique string that identifies the
component or module writing to the log, and the data is
the actual information that needs to be logged.
- AOSP includes an Android Debug Bridge (ADB) daemon
that runs on the Android device and that is accessed
from the host using the adb command-line tool. When
you type adb logcat on the host, the daemon actually
launches the logcat command locally on the target to
dump its “main” buffer
 Android Architecture
--- RAM Console ---
- Android adds a driver that registers a RAM-based
console that survives reboots and makes its content
accessible through /proc/last_kmsg.
the RAM console’s functionality seems to have been
merged into mainline within the pstore filesystem in the
kernel’s fs/pstore/ directory.
 Android Architecture
--- Physical memory (pmem) ---
- pmem driver allows for sharing memory between
processes. However, unlike ashmem, it allows the
sharing of large chunks of physically contiguous memory
regions, not virtual memory.
- these memory regions may be shared between processes
and drivers.

this driver is considered obsolete and has been dropped.

 Android Architecture
--- Hardware Abstraction Layer (HAL) ---
- consider the HAL layer as being the hardware library
loader, along with the header files defining the various
hardware types, with those same header files being
used as the API definitions for the hardware library .so
files.
- Although Android builds on the kernel’s hardware
abstractions and capabilities, its approach is very
different. Its subsystems and libraries don’t rely on
standard /dev entries to function properly. Instead, the
Android stack typically relies on shared libraries
provided by manufacturers to interact with hardware.
- In addition, most software stacks typically found in
Linux distributions to interact with hardware are not
found in Android. eg. X Window System
 Android Architecture
--- Hardware Abstraction Layer (HAL) cont.. ---
- Android does not in fact specify how the shared library and
the driver or kernel sub‐system should interact. Only the
API provided by the shared library to the upper layers is
specified by the HAL. Hence, it’s up to you to determine
the specific driver interface
that best fits your hardware, so long as the shared library
you provide implements the appropriate API.
- For most hardware types, there has to be a .so file that is
either provided by the AOSP or that you must provide for
Android to function properly.
- A system service corresponding to the type of hardware is
typically responsible for loading and interfacing with the
shared library. That system service will be responsible for
interacting and coordinating with the other system services
to make the hardware be‐have coherently with the rest of
the system and the APIs exposed to app developers.
 Android Architecture
--- Hardware Abstraction Layer (HAL) cont.. ---
- Usually, the system service will be split in two parts: one
part in Java that implements most of the Android-
specific intelligence, and another part in C/ C++ whose
main job is to interact with the HAL, the hardware-
supporting shared library and other low-level functions.
 Android Architecture
--- Hardware Abstraction Layer (HAL) cont.. ---
-- Loading and Interfacing Methods –
there are various ways in which system services and
Android in general interact with the shared libraries
implementing hardware support and hardware devices in
general.
--dlopen() -loading through HAL
Applies to: GPS, Lights, Sensors, and Display. Also
applies to Audio and Camera starting from 4.0/Ice-
Cream Sandwich.
Some hardware-supporting shared libraries are loaded
by the libhardware library.This library is part of
Android’s HAL and exposes hw_get_module() , which is
used by some system services and subsystems to
explicitly load a given specific hardware- supporting
shared library
 Android Architecture
--- Hardware Abstraction Layer (HAL) cont.. ---
-- Loading and Interfacing Methods –
-- Linker-loaded .so files --
Applies to: Audio, Camera, Wifi, Vibrator, and Power
Management
In some cases, system services are simply linked against
a given .so file at build time. Hence, when the
corresponding binary is run, the dynamic linker
automatically loads the shared library into the process’s
address space.
 Android Architecture
--- Hardware Abstraction Layer (HAL) cont.. ---
-- Loading and Interfacing Methods –
-- Hardcoded dlopen() s --
Applies to: StageFright and Radio Interface Layer (RIL)
In a few cases, the code invokes dlopen() directly
instead of going through lib hardware to fetch a
hardware-enabling shared library.
 Android Architecture
--- Hardware Abstraction Layer (HAL) cont.. ---
-- Loading and Interfacing Methods –
-- Sockets --
Applies to: Bluetooth, Network Management, Disk
Mounting, and Radio Interface Layer (RIL)
Sockets are sometimes used by system services or
framework components to talk to a remote daemon or
service that actually interacts with the hardware.
 Android Architecture
--- Hardware Abstraction Layer (HAL) cont.. ---
-- Loading and Interfacing Methods –
-- Sysfs entries--
Applies to: Vibrator and Power Management
Some entries in sysfs (/sys) can be used to control the
behavior of hardware and/or kernel subsystems. In
some cases, Android uses this method instead of /dev
entries to control the hardware. Use of sysfs entries
instead of /dev nodes makes sense, forinstance, when
defaults need to be set during system initialization
when no part of the framework is yet running.
 Android Architecture
--- Hardware Abstraction Layer (HAL) cont.. ---
-- Loading and Interfacing Methods –
-- /dev nodes --
Applies to: Almost every type of hardwareArguably, any
hardware abstraction must at some point communicate
with an entry in /dev, because that’s how drivers are
exposed to user-space.
 Android Architecture
--- Hardware Abstraction Layer (HAL) cont.. ---
-- Loading and Interfacing Methods –
-- D-Bus
Applies to: Bluetooth
D-Bus is a classic messaging system found in most Linux
distributions for facilitating communication between
various desktop components. It’s included in An‐
droid because it’s the prescribed way for a non-GPL
component to talk to the GPL-licensed BlueZ stack—
Linux’s default Bluetooth stack.
 Native User-Space
- “native user-space,” It mean all the user-space
components that run outside the Dalvik virtual machine.
This includes quite a few binaries that are compiled to
run natively on the target’s CPU architecture
- These are generally started either automatically or as
needed by the init process.
- Such binaries usually have direct access to the root
filesystem and the native libraries included in the
system. Their capabilities are restricted only by the
filesystem rights granted to them and their effective
UID and GID.
 Native User-Space
-- Filesystem Layout --
- The two main directories in which Android operates
are /system and /data.
- /system is the main Android directory for storing
immutable components generated by the build of the
AOSP. This includes native binaries, native libraries,
framework packages, and stock apps. It’s usually
mounted read-only from a separate image from theroot
filesystem, which is itself mounted from a RAM disk
image.
- /data, on the other hand, is Android’s main directory for
storing data and apps that change over time. This
includes the data generated and stored by apps installed
by the user alongside datagenerated by Android system
components at runtime. It, too, is usually mounted from
its own separate image, though in read-write mode.
- Android doesn’t include any /bin or /lib directories.
 Native User-Space
--Libraries --
- Android relies on about 100 dynamically loaded libraries,
all stored in the /system/lib directory. A certain
number of these come from external projects that
were merged into Android’s codebase to make their
functionality available within the Android stack, but
a large portion of the libraries in /system/lib are
actually generated from within the AOSP
– Libraries generated from external projects imported
into the AOSP
audio.so, liba2dp, input.so,libbluetooth and
Libbluetoothd By BlueZ
libjpeg.so By libjpeg
libsqlite.so By SQLite database
libwebcore.so By WebKit Open Source Project
 Native User-Space
--Libraries --
- Android-specific libraries generated from within the
AOSP
- Bionic libc.so, libm.so C library and Math library
libdl.so Dynamic linking library
libstdc++.so C++ support library
libthread_db.so Thread debugging library
- Core libbinder.so The Binder library
libutils.so, libcutils.so, libnetutils.so, and lib
sysutils.so Various utility libraries
libsystem_server.so, libandroid_servers.so,
libaudioflinger.so, libsurfaceflinger.so, lib
sensorservice.so, and libcameraservice.so
System-services-related libraries
 Native User-Space
--Libraries --
- Core libcamera_client.so and, in 2.3/Gingerbread, lib
surfaceflinger_client.so c
Client libraries for certain system services
liblog.so The logging library
libandroid_runtime.so The Android Runtime lib.
libandroid.so C interface to lifecycle
mgmt, input events, window mgmt, assets, and
Storage Manager
- Dalvik
libdvm.so The Dalvik VM library
libnativehelper.so JNI-related helper functions
- Hardware
libhardware.so The HAL library that provides
hw_get_module() and uses dlopen() to load hardware
support modules
 Native User-Space
--Libraries --
- Media libmediaplayerservice.so The Media Player
service library
libmedia.so The low-level media functions used
by the Media Player service
- OpenGL
libEGL.so libETC1.so, libGLESv1_CM.so,
libGLESv2.so, and egl/ligGLES_android.so
Android’s OpenGL implementation
 Init
- Android kernel’s boot process is same as linux kernel.
- What changes in Android is what happens once the kernel
finishes booting.
- Traditionally, Linux distributions have relied on SystemV
init for the init process, In embedded Linux systems, the
classic package that provides init is BusyBox, in ubuntu
Upstart
- Android introduces its own custom init, which brings with
it a few novelties.
- Android’s init defines its own configuration semantics and
relies on changes to global properties to trigger the
execution of specific instructions. Where as linux inits
run per the current run-levels’ configuration.
- The main configuration file for init is usually stored as
/init.rc, but there’s also usually a device-specific
configuration file stored as /init.<device_name>.rc, where
<device_name> is the name of the device.
 Init
- Global properties-
A very interesting aspect of Android’s init is how it
manages a global set of properties that can be accessed
and set from many parts of the system, with the
appropriate rights.
Some of these properties are set at build time, while
others are set in init’s configuration
files, and still others are set at runtime.At run‐time, the
system will have over 100 different properties, ranging
from IP and GSM configuration parameters to the
battery’s level. Use the getprop command to get the
current list of properties and their values.
The OOM adjustments are set on startup by the init.rc
file.
 Init
-udev events-
- access to devices in Linux is done through nodes within
the /dev directory. the system in use has been udev,
which relies on runtime events generated by the kernel
every time hardware is added or removed from the
system.
In Android, these events are handled by the ueventd
daemon built as part of Android’s init and accessed
through a symbolic link from /sbin/ueventd to /init.
 Toolbox
-The approach taken by the classic BusyBox package is to
build a single binary that essentially has what amounts
to a huge switch-case , which checks for the first
parameter on the command line and executes the
corresponding functionality. All commands are then
made to be symbolic links to the busybox command. So
when you type ls, for example, you’re actually invoking
BusyBox.
- since BusyBox’s behavior is predicated on the first
parameter on the command line and that parameter is
ls, it will behave as if you had run that command from a
standard Linux shell.
- Android doesn’t use BusyBox but includes its own tool,
Toolbox, that basically functions in the very same way,
using symbolic links to the toolbox command.
Unfortunately, Toolbox is nowhere as feature-rich as
BusyBox.
 Toolbox cont.
-Android developers have stated that their goal was to
create a minimal tool for shell-based debugging and not
to provide a full replacement for shell tools, as BusyBox
is.
 Daemons
-Android’s init starts a few key daemons that continue to
run throughout the lifetime of the system. Some
daemons, such as adbd, are started on demand, depending
on build options and changes to global properties.
Android daemons
ueventd Android’s replacement for udev.
servicemanager The Media server. Hosts most media-
related services.
Zygote The Zygote process. It’s responsible for warming
up the system’s cache and starting the System Server.
installd The .apk installation daemon. Takes care of
installing and uninstalling .apk files
Keystore The KeyStore daemon. Manages an encrypted
key-value pair store for cryptographic keys, SSL certs
for instance.
 Daemons cont..
system_server Android’s System Server. This daemon
hosts the vast majority of system services that run in
Android.
adbd The ADB daemon. Manages all aspects of the
connection between the target and the host’s adb
command.
 Command-Line Utilities
- Around 150 command-line utilities are scattered
throughout Android’s root filesystem. /system/bin
contains the majority of them, but some “extras” are
in /system/ xbin, and a handful are in /sbin.
- Around 50 of those in /system/bin are actually symbolic
links to /system/bin/toolbox.
 Dalvik and Android’s Java
- Dalvik is Android’s Java virtual machine. It allows
Android to run the byte-code generated from Java-
based apps and Android’s own system components and
provides both with the required hooks and environment
to interface with the rest of the system, including
native libraries and the rest of the native user-space.
- Java compiler compile java code into architecture-
independent byte-code that is executed at runtime by a
byte-code interpreter, also commonly referred to as a
“virtual machine.”
- Android relies on the JDK for the Java compiler at build
time, but it doesn’t use the JVM or the libraries found
in the JDK. Instead of the JVM it relies on Dalvik, and
instead of the JDK libraries it relies on the Apache
Harmony project, a clean-room implementation of the
Java libraries hosted under the umbrella of the Apache
project.
 Dalvik and Android’s Java
- JVM work on .class files, Dalvik prefers the .dex .
.dex files are actually generated by postprocessing
the .class files generated by the Java compiler
through Android’s dx utility. Among other things, an
uncompressed .dex file is 50% smaller than its
originating .jar file.
- Dalvik since 2.2/Froyo it has included a Just-in-Time
(JIT) compiler for ARM, with x86 and MIPS having
been added since. Historically, JIT has been a defining
feature for many VMs, helping them close the gap with
noninterpreted languages.
apps take longer to load the first time, but once they’ve
been JIT’ed, they load and run much faster. The only
caveat here is that JIT is available for a limited number
of architectures only, namely ARM, x86, and MIPS.
 Java Native Interface (JNI)
- in an embedded environment such as Android, code
written in Java sometimes needs to interface with code
coming from other languages.
- Java Native Interface (JNI) mechanism is provided. It’s
essentially a call bridge to other languages such as C and
C++.
- App developers sometimes use JNI to call the native
code they compile with the NDK from their regular Java
code built using the SDK.
- Internally, though, the AOSP relies massively on JNI to
enable Java-coded services and components to interface
with Android’s low-level functionality, which is mostly
written in C and C++.
- Java-written system services, for instance, very often
use JNI to communicate with matching native code
that interfaces with a given service’s corresponding
hardware.
 System Services
- System services are Android’s man behind the curtain.
- Binder—the mechanism on which all system services
are built.
- The native user-space designed very much as a support
environment for Android’s system services.
- The “System Server” process houses several system
services within the same process.
- neither “System Server” nor “Media Service” are part
of the “system services.” Instead, they are processes
used to run the latter.

- service list listout currently running services

Service Manager and Binder Interaction
 Service Manager and Binder Interaction
- a process in the system to invoke a system service
through Binder, though, it must first have a handle to it.
- For instance, Binder will enable an app developer to
request a wakelock from the Power Manager by invoking
the acquire() method of its WakeLock nested class.
Before that call can be made, though, the developer
must first get a handle to the Power Manager service.

PowerManager pm = (PowerManager)
getSystemService(POWER_SERVICE);
PowerManager.WakeLock wakeLock =
pm.newWakeLock(PowerManager.FULL_WAKE_LOCK,
"myPreciousWakeLock");
wakeLock.acquire(100);
 Service Manager and Binder Interaction
- Think of the Service Manager as a Yellow Pages book of
all services available in the system. If a system service
isn’t registered with the Service Manager, then it’s
effectively invisible to the rest of the system.
- To provide this indexing capability, the Service Man‐
ager is started by init before any other service. It then
opens /dev/binder and uses a special ioctl() call to set
itself as the Binder’s Context Manager(A1).
- Thereafter, any process in the system that attempts to
communicate with Binder ID 0 is actually communicating
through Binder to the Service Manager.
Thereafter, any process in the system that attempts
to communicate with Binder ID 0
 Service Manager and Binder Interaction
- When the System Server starts, for instance, it registers every
single service it instantiates with the Service Manager (A2).
- when an app tries to talk to a system service, such as the Power
Manager service, it first asks the Service Manager for a handle to
the service (B1) and then invokes that service’s methods (B2).
- a call to a service component running within an app goes directly
through Binder (C1) and is not looked up through the Service
Manager.
- The Service Manager is also used in a special way by a number of
command-line utilities such as the dumpsys utility, which allows you
to dump the status of a single or all system
Services
- To get the list of all services, dumpsys loops around to get every
system service (D1)
- each service, dumpsys just asks the Service Manager to locate that
specific one (D2).
- With a service handle in hand, dumpsys invokes that service’s dump()
function to dumpits status (D3) and displays that on the terminal.
 Then Activity Manager
- It takes care of the starting of new components, such as
Activities and Services, along with the fetching of Content
Providers and intent broadcasting. If you ever got the
dreaded ANR (Application Not Responding) dialog box,
know that the Activity Manager was behind it.
- It’s also involved in the maintenance of OOM adjustments
used by the in-kernel low-memory handler, permissions,
task management, etc
- when the user clicks an icon to start an app from his home
screen, the first thing that happens is the Launcher’s
onClick() callback is called (the Launcher being the default
app packaged with the AOSP that takes care of the main
interface with the user, the home screen). To deal with
the event, the Launcher will then call, through Binder, the
startActivity() method of the Activity Manager service.
The service will then call the startViaZygote() method,
which will open a socket to the Zygote and ask it to start
the Activity.
 System Startup
- Steps
- It has a hardcoded address from which it fetches its first
instructions. That address usually points to a chip that has
the bootloader programmed on it.
- The bootloader then initializes the RAM, puts basic hardware
in a quiescent state, loads the kernel and RAM disk, and jumps
into the kernel.
- The Zygote is a special daemon whose job is to launch
apps.The init doesn’t actually start the Zygote directly;
instead it uses the app_process command to get Zygote
started by the Android Runtime.The runtime then
starts the first Dalvik VM of the system and tells it to invoke
the Zygote’s main() .
Zygote is active only when a new app needs to be launched.The
Zygote then listens for connections on its socket
(/dev/socket/zygote) for requests to start new apps. When it
gets a request to start an app, it forks itself and launches the
new app.
12

10

Column 1
6
Column 2
Column 3

0
Row 1 Row 2 Row 3 Row 4