Q: Virtual memory size of 64KBytes. Physical memory size of 8KBytes.

Cache memory
of 512bytes. Each page size in Virtual and physical memory is 1KBytes. Word size is 4
Bytes. Block size is 4 words. Cache memory is Direct mapping. Calculate the above
required details.

a. Number of bits for TAG

a. 7 bits. (# of bits needed to represent Virtual memory– # of bits needed to
represent Cache memory)
b. Number of bits for Block offset
a. 4 bits
c. Number of bits for Word offset
a. 2 bits
d. Number of bits for byte offset
a. 4 bits
e. Number of blocks in a cache data memory
a. 16 blocks
f. Number of BITS in a Block
a. Check with others. I have written but probably mines is wrong hence not filling urs
g. Total cache memory size= (Valid Bit+tag size+Block size)xNo of Blocks
a. (1+7+16x8)x32 = 544 bytes
h. Number of bits required in Address bus to access cache memory
a. 9 bits
i. Number of Bits mapped for Page offset in address bus
a. 10 bits
j. Number of Bits mapped for Virtual Page numbers in address bus
a. 6 bits
k. Number of Bits mapped for physical Page numbers in address bus
a. 3 bits
l. Number of pages in virtual memory
a. 64 pages
m. If Number of pages in Virtual memory is doubled by increasing one bit of address
bus, Then Number of pages in physical memory will also be doubled [True or false]
a. False
n. If the size of the Physical memory is doubled, the size of the page table origin register
will also get doubled [TRUE/FALSE]
a. False
o. How many rows/ entries in the page table?
a. =VM size/Page size = 64K/1KB=64 entries
p. What is the size [in bits] of each entry/Row in the page table?
a. 4 bits
q. What is the inference if 3 rows/entries of page table PRESENT bit is “1”?
a. If 3 rows of page table PRESENT bit is “1”, it indicates that the particular page and
next 2 pages are in cache. It follows the “Principle of Locality”, aka., there is a
tendency if the compute program to access instructions whose address are near to
one another.
r. If size of Page is doubled, number of pages in the physical memory will not
decrease[TRUE/FALSE].
a. False
Q2: In detail explain Android Framework Architecture and Android Application Architecture

Android Framework Architecture

Android Architecture or Android software stack is categorized into following five parts:

 linux kernel
 native libraries (middleware),
 Android Runtime
 Application Framework
 Applications

Linux Kernel:

The foundation of the Android platform is the Linux kernel. For example, the Android Runtime (ART)
relies on the Linux kernel for underlying functionalities such as threading and low-level memory
management.

Using a Linux kernel allows Android to take advantage of key security features and allows device
manufacturers to develop hardware drivers for a well-known kernel.

Libraries (Middleware)/HAL

The Android system libraries are the layer immediately above the Linux kernel in userspace. The
library LibC provides the interface between the Linux kernel and Android userspace libraries. These
libraries are implemented in C or Cþþ and individually represent a system capability or resource that
is exposed to the application framework but binds to the Linux kernel. These libraries include the
following:

 Surface Manager. A subsystem for managing shared access to the display from among
concurrent applications and services.
 OpenGL. A 3D graphics implementation based on OpenGL ES 2.0 APIs. The OpenGL library
includes a highly optimized 3D software implementation but can also take advantage of
hardware support when available.
 SGL. A 2D graphics engine.
 Media Libraries. These media libraries are based on PacketVideo’s OpenCORE libraries. They
support the encoding and decoding of common multimedia formats for images, audio, and
video including JPG, PNG, AAC, MP3, and H.264.
 FreeType. Bitmap- and vector-based font rendering subsystem.
 SQLite. A lightweight relational database subsystem for persistent structured data storage.
 WebKit. An open-source web browser engine.
 C library. A lightweight BSD-derived implementation of the standard libc system library. A
nonstandard library is used to reduce usage of memory and compute resources.

The libraries and the Android runtime environment comprise the interface against which the
application framework is built.

Android Runtime

For devices running Android version 5.0 (API level 21) or higher, each app runs in its own process and
with its own instance of the Android Runtime (ART). ART is written to run multiple virtual machines
on low-memory devices by executing DEX files, a bytecode format designed specially for Android
that's optimized for minimal memory footprint. Build tools, such as d8, compile Java sources into
DEX bytecode, which can run on the Android platform.

Some of the major features of ART include the following:

 Ahead-of-time (AOT) and just-in-time (JIT) compilation

 Optimized garbage collection (GC)
 On Android 9 (API level 28) and higher, conversion of an app package's Dalvik Executable
format (DEX) files to more compact machine code.
 Better debugging support, including a dedicated sampling profiler, detailed diagnostic
exceptions and crash reporting, and the ability to set watchpoints to monitor specific fields

Prior to Android version 5.0 (API level 21), Dalvik was the Android runtime. If the app runs well on
ART, then it should work on Dalvik as well, but the reverse may not be true.

Android also includes a set of core runtime libraries that provide most of the functionality of the Java
programming language, including some Java 8 language features, that the Java API framework uses.

Each Android application exists within its own Linux process. Additionally, each process includes its
own Dalvik virtual machine instance. The Dalvik VM defines its own program file format and features
a register-based execution model in contrast to the JVM’s stackbased instruction set. The
implementation of systems-software functions, such as access to I/O devices, permissions,
threading, and memory management, is based on support provided in the Linux kernel

Java API Framework

The entire feature-set of the Android OS is available through APIs written in the Java language. These
APIs form the building blocks that’s needed to create Android apps by simplifying the reuse of core,
modular system components and services, which include the following:

 A rich and extensible View System that can be use to build an app’s UI, including lists, grids,
text boxes, buttons, and even an embeddable web browser
 A Resource Manager, providing access to non-code resources such as localized strings,
graphics, and layout files
 A Notification Manager that enables all apps to display custom alerts in the status bar
 An Activity Manager that manages the lifecycle of apps and provides a common navigation
back stack
 Content Providers that enable apps to access data from other apps, such as the Contacts
app, or to share their own data

Developers have full access to the same framework APIs that Android system apps use.

The framework also provides system-level managers for shared resources. These managers are
used to manage device displays and windows, interapplication communication, and access to
hardware
resources, among others. Some of these resources are elaborated on below.

 User interface elements. The framework includes a set of components for display and user
interaction. These include traditional UI widgets such as buttons, images, and checkboxes
along with an embedded web browser and other feature-rich GUI elements.
  Content providers. Applications that share data, or access shared data, can do so via content
providers. The core applications include examples such as contact lists, photographs, and
videos. By leveraging the content provider interfaces, applications can integrate data from
other applications without being responsible for capturing, curating, or maintaining the data
set.
 Resource managers. Some aspects of an application will be common to all devices and users,
and others will be specialized. Resource managers provide application localization support
and enable applications to cleanly separate these two. For example, one application can use
resource managers to manage user-facing application resources, such as text strings and
icons, and specialize them to specific devices (phones versus tablets) and user languages
(English versus Spanish).
 Notification manager. The notification manager serves as the device-wide alert and
notification interface for the user. For example, most phones have a status bar that displays
application and system notifications in a consistent way.
 Activity manager. The activity manager keeps track of the life cycle of application instances.
As we will see, Android takes a much more proactive role in shutting down applications in
response to resource constraints as compared to traditional operating systems. The activity
manager maintains a view of how application components are connected to one another
and the current state of each component. Using this information, the manager maintains a
prioritized list of components that is used to make termination decisions when resources run
low

System Apps

Android comes with a set of core apps for email, SMS messaging, calendars, internet browsing,
contacts, and more. Apps included with the platform have no special status among the apps the user
chooses to install. So a third-party app can become the user's default web browser, SMS messenger,
or even the default keyboard (some exceptions apply, such as the system's Settings app).

The system apps function both as apps for users and to provide key capabilities that developers can
access from their own app. For example, if the app would like to deliver an SMS message, one don't
need to build that functionality—instead one can instead invoke whichever SMS app is already
installed to deliver a message to the recipient.
Android Application Architecture

Android’s architecture encourages component reuse, enable publish and share Activities,

Services, and data with other applications, with access managed by the security restrictions.

The same mechanism that enables to produce a replacement contact manager or phone dialer

can expose the application’s components in order to let other developers build on them by

creating new UI front ends or functionality extensions.

The following application services are the architectural cornerstones of all Android applications,

providing the framework used by the software:

 Activity Manager and Fragment Manager — Control the lifecycle of the Activities and
Fragments, respectively, including management of the Activity stack
 Views — Used to construct the user interfaces for the Activities and Fragments
 Notification Manager — Provides a consistent and nonintrusive mechanism for signalling the
users
 Content Providers — Lets applications share data
 Resource Manager — Enables non-code resources, such as strings and graphics, to be
externalized.
 Intents — Provides a mechanism for transferring data between applications and their
components

Activity Manager and Fragment manager:

Applications use the Android activity component for presenting an entry point to the app. Android
Activities are the components that house the user interface that app users interact with. As end-
users interact with the Android device, they start, stop, and jump back and forth across many
applications. Each navigation event triggers activation and deactivation of many activities in
respective applications.

The Android ActivityManager is responsible for predictable and consistent behavior during
application transitions. The ActivityManager provides a slot for app creators to have their apps react
when the Android OS performs global actions. Applications can listen to events such as device
rotation, app destruction due to memory shortage, an app being shifted out of focus, and so on.

Some examples of the way applications can react to these transitions include pausing activity in a
game, stopping music playing during a phone call.

Views:

Android also provides a means to easily create common visual components needed for app
interaction. These components include widgets like buttons, image holders such as ImageView,
components to display a list of items such as ListView, and many more. The components are
premade but are also customizable to fit app developer needs and branding

Notification Manager:
The Notification Manager is responsible for informing Android users of application events. It does
this by giving users visual, audio or vibration signals or a combination of them when an event occurs.
These events have external and internal triggers. Some examples of internal triggers are low-battery
status events that trigger a notification to show low battery. Another example is user-specified
events like an alarm. Some examples of external triggers include new messages or new wifi networks
detected.

Android provides a means for programmers and end-users to fine-tune the notifications system. This
can help to guarantee they can send and receive notification events in a means that best suits them
and their current environments.

Content Providers:

Android has a standardized way to share data between applications on the device using the content
provider. Developers can use the content provider to expose data to other applications. For
example, they can make the app data searchable from external search applications. Android itself
exposes data such as calendar data, contact data, and the like using the same system

Resource Manager:

Android app usually come with more than just code. They also have other resources such as icons,
audio and video files, animations, text files, and the like. Android helps in making sure that there is
efficient, responsive access to these resources. It also ensures that the right resources are delivered
to the end-users. For example, the proper language text files are used when populating fields in the
apps

Intents:

In Android, intents are asynchronous messages that name the activity, service, operation, or
resource being requested. Intents are a dynamic binding mechanism that enables applications to
specify what operations they want performed (optionally with some input data), without having to
explicitly specify what component will carry out the operation. For example, this binding indirection
would allow a user to change his or her default email client application without needing to
reconfigure any existing applications that rely on an email client to compose or receive email
messages.

The Intent class defines and implements the intent mechanism in the Android platform. It is an
important and substantial class, consisting of 168 constants and 111 public methods, so our
discussion of it will be limited to its high-level characteristics and its common usage.

While not comprehensively true, it is easiest to think about intents as being pairs of operations and
data. Both operations and data are specified via names. Operation names are defined as constants in
the Intent class. Data names are URIs. We now consider a few examples.

 Action: ACTION_VIEW. Data: content://contacts/people/1. Display information about the

person whose identifier is “1.”
 Action: ACTION_VIEW. Data: mailto://contacts/people/1. Invoke an email client and
compose a message populated with this person’s contact information.
 Action: ACTION_EDIT. Data: content://contacts/people/1. Launch an editor for this person’s
contact information.
 Action: ACTION_DIAL. Data: tel:12345678. Launch a phone dialer populated with the
number passed as data.
In the examples above, the names of the provided data suggest that these are easily recognized
types. Indeed, when intents get resolved to a target component, the data portion of the request is
examined in order to find a best match. In fact, as we will see, component declarations include
statements (intent filters) that indicate which actions the component can support. In this way,
component requests and providers can be matched.