CHAPTER 2 ANDROID ARCHITECTURE

*What is Android?
 An Android is a robot or device designed to resemble a human, or it refers to a mobile
operating system developed by Google for smartphones and tablets.
 Android is an open source operating system that is developed for highly portable consumer
devices, such as a Smart phone, Touch screen tables, E-readers, TVs.
 It was developed by ANDY RUBIN.
 It was acquired by Google in the year of 2005.
 It is based on the Linux Platform and Oracle’s Java Programming Language.
 Android is an Open source operating System, so it it allows developer to create their
application at free of cost.

*Versions of Android:
1.0 - September 23, 2008
1.1 - February 9, 2009
1.5 Cupcake April 27, 2009
1.6 Donut September 15, 2009
2.0–2.1 Eclair October 26, 2009
2.2–2.2.3 Froyo May 20, 2010
2.3–2.3.7 Gingerbread December 6, 2010
3.0–3.2.6 Honeycomb February 22, 2011
4.0–4.0.4 Ice Cream Sandwich October 18, 2011
4.1–4.3.1 Jelly Bean July 9, 2012
4.4–4.4.4 KitKat October 31, 2013
5.0–5.1.1 Lollipop November 12, 2014
6.0–6.0.1 Marshmallow October 5, 2015
7.0–7.1.2 Nougat August 22, 2016
8.0–8.1 Oreo August 21, 2017
9.0 Pie August 6, 2018
10 - September 3, 2019
11 - September 8, 2020
12 - October 4, 2021
13 - August 15, 2022
14 - October 4, 2023
2024
15
Introduction to Android Architecture:
Android operating System is Made of Different Layers of software, each layer Provide different
Service to the Layer below.

 Linux Kernel
 Libraries
 Android Run time
 Android Framework
 Applications
 Android Start-up and Zygote
 Android Debug Bridge
 Android permission Model
 Android manifest File.
 Fig 1. Android Framework
2.1 LINUX KERNEL

FIG [Link] KERNEL

 Linux Kernel is the basic layer of android Framework.

 The Linux kernel is the core component of the Linux operating system. It acts as an
intermediary between hardware and software, managing system resources, and providing
essential services to all other parts of the operating system.
 Here's an explanation of its key components and functionality:

1. System Call Interface

 Provides a standard way for user-space applications to request services from the
kernel.
 Examples include file operations (open, read, write), process control (fork, exec), and
network operations.

2. Process Management

 Handles the execution of processes (programs in execution) and ensures multitasking.

 Manages process creation, scheduling, termination, and inter-process communication.
 Includes features like load balancing and prioritization for efficient resource usage.

3. Memory Management

 Manages system memory allocation and deallocation.

 Provides virtual memory, ensuring that applications have access to memory without
conflicts.
 Includes techniques like paging and swapping to optimize memory use.

4. File System Management

  Manages data storage and retrieval on disk drives.
 Supports various file systems (e.g., ext4, NTFS, FAT).
 Ensures data consistency and security through permissions and journaling.

5. Device Drivers

 Acts as a translator between the hardware devices (e.g., keyboard, mouse, disk) and
the software.
 Each hardware device requires a specific driver to communicate with the kernel.

6. Network Stack

 Handles networking protocols (e.g., TCP/IP) for communication between devices.

 Manages network interfaces, packet routing, and security.

7. Kernel Modules

 Dynamically loadable pieces of code that extend the kernel's functionality without
rebooting.
 Commonly used for hardware drivers or system calls.

8. Hardware Abstraction Layer (HAL)

 Abstracts hardware details, providing a consistent interface for software regardless of

the underlying hardware.
 This abstraction enables portability across different hardware platforms.

Features of the Linux Kernel:

1. Monolithic Architecture: Combines all system services in one large kernel, making
it efficient but complex.
2. Open Source: Freely available for modification, distribution, and use.
3. Portability: Runs on a wide range of hardware platforms.
4. Security: Implements access control, user authentication, and encryption features.
5. Performance: Optimized for speed and resource utilization.

2.2 LIBRARIES
 FIG [Link]
 It is a next layer in the Android [Link] sits on the top of Linux Kernel.
 This Layer enables the Devices to handle different types of data.
 This Libraries Are Written in C or C++ Language and are specific for a particular hardware.

*1. Surface Manager

 Responsible for managing access to the display system.

 Enables efficient rendering of 2D and 3D graphics for applications.
 Manages the surfaces where apps draw their user interfaces.

*2. Media Framework

 Provides APIs for playing and recording audio and video.

 Supports common media formats such as MP3, AAC, H.264, MPEG-4, and others.
 Ensures multimedia capabilities in Android applications.

*3. SQLite

 A lightweight relational database engine embedded within Android.

 Used for data storage in apps (e.g., storing user preferences, app settings, or structured
data).
 Supports SQL queries for data manipulation.

*4. OpenGL | ES

 Open Graphics Library for Embedded Systems.

 A cross-platform API for rendering 2D and 3D vector graphics.
 Primarily used for developing games and other high-performance graphical applications.
5. FreeType

 A library for rendering fonts, particularly for TrueType and OpenType fonts.
 Ensures that Android can display text properly, including custom fonts in apps.

*6. WebKit

 A browser engine used to render web pages.

 Powers the built-in Android WebView, enabling web content to be displayed within apps.

7. SGL

 Stands for Skia Graphics Library.

 Responsible for 2D graphics rendering.
 Used for drawing shapes, text, and images in Android.

8. SSL

 Stands for Secure Sockets Layer.

 Provides secure communication through encryption, ensuring data security over networks.
 Essential for secure browsing, app communications, and protecting sensitive data.

9. libc

 A standard C library tailored for Android.

 Provides essential functions like memory management, string manipulation, and file
handling

2.3 ANDROID RUNTIME:

 FIG 4. ANDROID RUNTIME

1. Core Libraries

 Purpose: Provides the essential Java libraries used by Android applications.

 Role:
o These libraries include data structures, utilities, networking, file handling, and other
core functionalities required for application development.
o They allow developers to write Android applications in Java (or Kotlin) with familiar
APIs.
 Examples:
o [Link]: For collections and data manipulation.
o [Link]: For networking functionalities.
o [Link]: For input/output operations.

2. Dalvik Virtual Machine (DVM)

 Purpose: A specialized virtual machine for running Android applications.

 Role:
o Converts app bytecode (DEX format) into executable code at runtime.
o Optimized for devices with limited resources (e.g., low memory, slower processors).
o Supports Just-In-Time (JIT) compilation to improve performance during app
execution.
 Replaced By: Starting with Android 5.0 (Lollipop), the Dalvik Virtual Machine was replaced
by the Android Runtime (ART) for better performance and efficiency.

2.4 APPLICATION FRAMEWORK :

FIG 5. APPLICATION FRAMEWORK

1. Activity Manager

 Purpose: Manages the lifecycle of activities (screens) in Android apps.

 Functionality:
o Keeps track of the state of activities (e.g., starting, pausing, resuming).
 o Handles the back stack of activities, determining what should be shown on the
screen.
o Manages application switching and multitasking.

2. Window Manager

 Purpose: Manages windows and their layout on the screen.

 Functionality:
o Controls the placement of views, dialogs, and other elements on the screen.
o Handles layout and animation for views, managing which window is on top.
o Deals with screen orientation and resolution changes.

3. Content Providers

 Purpose: Manages shared data between different apps.

 Functionality:
o Allows an app to access data from other apps in a standardized way (e.g., contacts,
images, calendar).
o Provides methods for querying, inserting, updating, and deleting data.
o Helps maintain data security and access permissions.

4. View System

 Purpose: Manages user interface elements and their interactions.

 Functionality:
o Handles UI components like buttons, text fields, and lists.
o Provides a hierarchical layout system where views can be nested inside each other
(e.g., linear layouts, relative layouts).
o Supports handling touch events and gestures.

5. Package Manager

 Purpose: Manages app installation, updates, and removal.

 Functionality:
o Provides APIs for interacting with applications installed on the device.
o Handles tasks such as querying app details, checking permissions, and
installing/uninstalling apps.

6. Telephony Manager
  Purpose: Provides access to the phone's telephony services (if applicable).
 Functionality:
o Allows apps to manage phone calls, SMS, network status, and other telephony-
related features.
o Provides APIs for checking SIM card information, network type, and mobile signal
strength.

7. Resource Manager

 Purpose: Manages resources used by Android apps, such as images, strings, and layouts.
 Functionality:
o Allows apps to load and retrieve resources (e.g., images, XML files) in a consistent
manner.
o Handles localization by providing resources tailored to different languages and
regions.

8. Location Manager

 Purpose: Provides location-related services (GPS, network-based location).

 Functionality:
o Allows apps to access device location via GPS, Wi-Fi, or cellular network.
o Supports geofencing, location tracking, and obtaining real-time location updates.

9. Notification Manager

 Purpose: Manages notifications to alert users about app events or system statuses.
 Functionality:
o Allows apps to send notifications (e.g., sound, vibration, pop-ups) to users.
o Provides options for interactive notifications with actions like reply, dismiss, or
mark as done.
o Handles different types of notifications, including background tasks and system
alerts.

2.5 APPLICATIONS
 FIG 6. APPLICATIONS
 Applications are the top layer in the android framework Architecture.

Example:
1. Social Media Applications (e.g., Facebook, Instagram, Twitter)
2. Location-Based Services (e.g., Google Maps, Uber, Lyft)
3. E-commerce Applications (e.g., Amazon, eBay, Flipkart)
4. Communication Applications (e.g., WhatsApp, Skype, Telegram)
5. Media and Entertainment Applications (e.g., YouTube, Spotify, Netflix)
6. Health and Fitness Applications (e.g., Google Fit, Strava, MyFitnessPal)
7. Banking and Finance Applications (e.g., PayPal, Google Pay, Mint)
8. Shopping and Retail Applications (e.g., Walmart, Target, Alibaba)
9. News and Reading Applications (e.g., Google News, Flipboard, Kindle)
10. Utility Applications (e.g., Google Keep, Todoist, Evernote)

2.6 ANDROID STARTUP AND ZYGOTE:

 FIG 7. Android start up process

Android Start-up Process Diagram Overview

1. Bootloader:
o The process begins when the device is powered on.
o The bootloader initializes the hardware and loads the Linux Kernel into
memory.
2. Linux Kernel:
o The Linux Kernel is the core of the system that interacts with the hardware
and manages low-level resources.
o It starts the init process.
3. Init Process:
o init is the first process to run in user space.
o It is responsible for launching the Zygote process and initializing system
properties.
4. Zygote:
 oZygote is responsible for creating and initializing the Dalvik/ART runtime,
loading system libraries, and forking new processes for apps.
o It provides a template process for new apps, which significantly reduces the
time to start new applications.
5. System Server:
o Zygote starts the System Server, which is responsible for initializing essential
Android system services.
o These services include Activity Manager, Window Manager, Package
Manager, Content Providers, Telephony Manager, Notification Manager,
etc.
6. App Launch:
o When an app is launched, the Zygote process forks a new app process.
o The app communicates with System Server to access services like
notifications, permissions, or location services.
o The Activity Manager ensures the proper lifecycle of app activities, rendering
the UI to the user.

2.7 ANDROID DEBUG BRIDGE

Android Debug Bridge (ADB) is a versatile command-line tool that lets you communicate with an
Android device for various tasks like installing and debugging apps, running shell commands, and
accessing the device’s file system. ADB acts as a bridge between the development environment (like
your computer) and the Android device, providing a way for developers to interact with the device
for debugging and testing purposes.

How Does ADB Work?

 ADB Server: The ADB server runs on the development machine. It handles the
communication between the connected Android device(s) and the client.
 ADB Daemon: The ADB daemon runs on the Android device itself. It listens for
incoming commands from the ADB server.
 ADB Client: The ADB client is the command-line interface (CLI) on the developer’s
machine that issues commands to the ADB server.

ADB Commands Overview

Command Description

adb devices List all connected Android devices.

adb install <file> Install an APK on the device.

adb uninstall <package-name> Uninstall an app from the device.

adb shell Open a remote shell on the Android device.

adb logcat View system logs (Logcat) for debugging.

adb push <local> <remote> Push files from your computer to the device.
 Command Description

adb pull <remote> <local> Pull files from the device to your computer.

adb reboot Reboot the device.

adb tcpip 5555 Enable ADB over Wi-Fi.

Connect to a device over Wi-Fi.

adb connect <ip>

2.8 ANDROID PERMISSION MODEL

The Android Permission Model is a system in the Android operating system that controls
access to sensitive data, features, and resources on the device. It ensures that apps can only
access specific resources if the user grants explicit permission. This model helps protect user
privacy and security by preventing unauthorized access to device data and features.

Android permissions are classified into normal permissions and dangerous permissions
based on the level of security and risk involved. Let's go through the details of the Android
permission model:

The main two fundamental goals of the Android permission model are:

1. Protect User Privacy

 The permission model ensures that sensitive user data (such as contacts, location,
camera, and microphone) is only accessible to apps that the user explicitly grants
permission to. This helps prevent unauthorized access to personal information,
safeguarding user privacy.

2. Enhance Device Security

 By restricting access to critical system resources and data, the permission model
prevents malicious apps from compromising the device's security. It ensures that apps
can only

1. Types of Android Permissions

Normal Permissions:

 These permissions allow apps to access features and data that pose minimal risk to the
user's privacy or the system.
 They are automatically granted to apps during installation, without any user intervention.
 Examples:
o INTERNET: Allows an app to use the internet.
 o ACCESS_NETWORK_STATE: Allows an app to check the network state (e.g., whether
the device is connected to Wi-Fi).
o SET_ALARM: Allows an app to set alarms.

Dangerous Permissions:

 These permissions allow apps to access sensitive data or perform actions that can
significantly affect the user’s privacy or the system’s functionality.
 The user must explicitly grant these permissions during runtime (starting with Android 6.0
Marshmallow, API level 23).
 If a user denies the permission, the app cannot access the related feature, and the app may
behave differently or not function as intended.
 Examples:
o READ_CONTACTS: Allows an app to access the user's contacts.
o ACCESS_FINE_LOCATION: Allows an app to access precise location data.
o CAMERA: Allows an app to use the device's camera.
o READ_EXTERNAL_STORAGE: Allows an app to read files from external storage.

2. Permission Request Flow (Runtime Permissions)

Starting with Android 6.0 (API level 23), the Android system introduced runtime
permissions. Before this, permissions were requested at installation time, and users either
accepted or rejected them before the app was installed. With runtime permissions, apps need
to request permissions while the app is running.

1. Declare Permissions in [Link]:

o All permissions the app needs must be declared in the [Link] file.
This ensures that the app will request access to the features or data during
installation or runtime.
o Example:

xml
Copy code
<uses-permission android:name="[Link]"/>

2. Request Permission at Runtime:

o At runtime, the app checks if the required permissions are granted using the
[Link]() method.
o If the permission is not granted, the app requests it using
[Link]().

Example:

java
Copy code
if ([Link](this,
[Link])
!= PackageManager.PERMISSION_GRANTED) {
// Request the permission
[Link](this,
 new String[]{[Link]}, REQUEST_CODE);
}

3. Handle Permission Response:

o When the user responds to the permission request (granting or denying), the app
receives the result in the onRequestPermissionsResult() callback.
o Based on the response, the app can either continue or notify the user about the
necessity of the permission.

Example:

java
Copy code
@Override
public void onRequestPermissionsResult(int requestCode, String[]
permissions, int[] grantResults) {
if (requestCode == REQUEST_CODE) {
if ([Link] > 0 && grantResults[0] ==
PackageManager.PERMISSION_GRANTED) {
// Permission granted, proceed with the functionality
} else {
// Permission denied, show a message or handle the denial
}
}
}

4. Rationale for Denied Permissions:

o If the user denies the permission request, you can show a rationale dialog explaining
why the permission is needed. This is especially important if the user has previously
denied the permission but not selected "Don't ask again."
o Use the shouldShowRequestPermissionRationale() method to determine if
you should show a rationale.

Example:

java
Copy code
if ([Link](this,
[Link])) {
// Show rationale to the user
} else {
// Proceed without permission or take appropriate action
}

3. Permission Groups

Permissions in Android are grouped by category, and some permissions belong to these
groups. For example:

 Location Permissions:
o ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION allow access to location
data.
 Camera and Microphone Permissions:
 o CAMERA and RECORD_AUDIO allow access to hardware like the camera and
microphone.

When an app requests one permission from a group, it can sometimes implicitly gain access
to others in the same group (e.g., requesting CAMERA permission might prompt the user for
other permissions in the camera group).

4. Special Permissions

In addition to normal and dangerous permissions, Android has some special permissions that
provide access to critical features, which are protected and require specific conditions or
device settings to work:

 SYSTEM_ALERT_WINDOW: Allows apps to display system-level overlays (like chat heads in

Facebook Messenger).
 WRITE_SETTINGS: Allows apps to modify system settings like brightness or ringtone volume.
 INSTALL_PACKAGES: Allows apps to install other apps.

5. Permission Decline and Denial

 Permanent Denial (Don’t ask again):

o If the user selects "Don’t ask again" when denying a permission, the app cannot
request the permission again. Instead, the app should guide the user to the system
settings screen to manually enable the permission.

Example:

java
Copy code
if ([Link](this,
[Link])) {
// Show rationale
} else {
// Permission has been denied permanently, redirect to settings
}

 User Education:
o When permissions are denied, it's crucial to educate the user why the permission is
necessary for the app’s functionality. You can provide this information before
requesting the permission or use a dialog explaining the need for permission.

6. Permissions in Android Versions

 Android 6.0 (Marshmallow): Introduced runtime permissions. Apps now request

permissions as they are needed, instead of at installation time.
  Android 8.0 (Oreo): Introduced background location access limitations (users need
to grant permission to access location while the app is in the foreground).
 Android 10 (Q): Scoped storage was introduced to limit apps' access to external
storage, which helps protect user data.

7. Best Practices for Handling Permissions

 Request permissions only when necessary:

o Don’t ask for permissions upfront. Request permissions only when the user actually
needs them for the current functionality.
 Explain why permissions are needed:
o Before asking for sensitive permissions (such as location or camera access), provide
a rationale. This can be done using a dialog or a simple message.
 Handle permission denial gracefully:
o Ensure the app still works even if the user denies a permission. You can fall back on a
simpler version of the feature or explain why the permission is important.