NAME NIKHIL KUMAR SINGH
ROLL NUMBER 2314106726
SESSION JULY/SEP 2025
PROGRAM BCA
SEMESTER VI
CODE & NAME DCA3201– MOBILE APPLICATION
DEVELOPMENT
ANSWER
SET-I
[Link]: Here's the diagram we're talking about:
Now let's break down each layer, starting from the bottom:
I. Linux Kernel (The Foundation)
This is the very bottom layer, the bedrock of the entire Android system. Think of it as the engine
of the car. It's built on a well-known operating system called Linux.
• What it does:
o Manages Hardware: It talks directly to your phone's physical parts like the
camera, Wi-Fi, battery, and screen.
o Memory Management: It decides which programs get how much memory to
use.
o Process Management: It handles when apps start, stop, and run.
o Security: It provides the basic security for the system.
o Drivers: It includes all the "drivers" (small programs) needed for the hardware to
work.
II. Hardware Abstraction Layer (HAL)
Right above the Linux Kernel is the HAL. This layer acts like a translator.
• What it does:
o Standard Interface: Different phone manufacturers (like Samsung, Google,
Xiaomi) use different camera chips or Wi-Fi chips. The HAL provides a standard
way for the higher layers of Android to talk to these different hardware
components without needing to know their specific details. It "hides" the messy
hardware differences.
o So, a developer writes code for "the camera," and the HAL makes sure that code
works whether the phone has a Sony camera sensor or a Samsung one
III. Android Runtime & Native Libraries (The Core Helpers)
This layer has two main parts that work closely together:
a) Android Runtime (ART)
This is a super important part! It's like the chef who cooks the food (your apps).
• What it does:
o Runs Apps: When you open an app, ART is responsible for executing its code
and making it run smoothly. Before ART, Android used something called
"Dalvik," but ART is newer and more efficient.
o Memory Management: It helps manage how much memory each app uses,
trying to make everything efficient.
o Garbage Collection: It automatically cleans up unused parts of memory.
b) Native C/C++ Libraries
These are like the specialized tools in the kitchen (e.g., a good blender, a sharp knife). They are
pre-written codes that do common, heavy-lifting tasks.
• What it does:
o Graphics (Surface Manager, OpenGL ES): Helps draw what you see on the
screen, like smooth animations and complex game graphics.
o Media (Media Framework): Handles playing videos and music.
o Web Browsing (WebKit): Powers the web browser within apps (and Chrome
itself).
o Database (SQLite): Helps apps store and manage data efficiently on your device.
o Security (SSL/TLS): Provides secure communication over the internet.
IV. Java API Framework (The Developer's Toolkit)
This is the layer that app developers interact with the most. Think of it as a cookbook full of
recipes and ingredients.
• What it does:
o APIs (Application Programming Interfaces): These are ready-made building
blocks that developers use to create apps. Instead of writing code from scratch to
make a button or open the camera, developers use these "APIs."
o Activity Manager: Manages the "activities" (screens) in your apps.
o Package Manager: Handles installing, uninstalling, and managing app packages.
o View System: Helps create the user interface (UI) – what you see on the screen
like buttons, text fields, and lists.
o Notifications: Helps apps send you alerts and messages.
o Location Manager: Allows apps to find your device's location.
V. System Apps & User Applications (What You See & Use)
This is the top layer, the finished meal that you enjoy!
• What it does:
o System Apps: These are the apps that come pre-installed on your phone and are
crucial for its basic functions (e.g., Phone app, Contacts, Messages, Camera,
Gallery, Clock, Gmail).
o User Applications: These are all the apps you download yourself from the
Google Play Store or other sources (e.g., WhatsApp, Instagram, YouTube, games,
banking apps).
All these layers work together, from the very core hardware management to the apps you tap on
every day, making your Android phone a powerful and versatile device!
[Link]:
a) Creating a new, empty project in Android Studio is the first step for building any app. It
involves setting up the basic file structure and configuration. Here are the major steps:
1. Open Android Studio & Start: First, launch the Android Studio program. You will be
greeted by a Welcome window. From here, select "New Project" to begin the process.
2. Choose a Project Template: Android Studio will then ask you to select a template.
These are pre-built layouts for different devices (phones, watches, etc.). For a standard,
blank project, you must choose "Empty Views Activity" (on older versions, this might
be called "Empty Activity").
This gives you one blank screen and the essential files. Click "Next".
3. Configure Your Project: This is the most important step, where you define your app's
identity:
a. Name: The user-facing name of your app (e.g., "MyCalculator").
b. Package Name: A unique internal ID for your app (e.g.,
[Link]). This must be unique if you publish it on the Google
Play Store.
c. Save Location: The folder on your computer where the project will be stored.
d. Language: You can choose between Java or Kotlin. For many BCA courses,
Java is the standard language taught.
e. Minimum SDK: This setting determines the oldest Android version your app can
run on.
4. Finish and Build: Once all the details are filled in, click the "Finish" button. Android
Studio will now prepare your project. You will see a "Gradle Sync" process, which is just
the system downloading necessary files and organizing your project. Once it's complete,
your empty project is ready to be worked on.
b) In an Android project, .java and .xml files work together as a team, but they have completely
different and separate responsibilities. The easiest way to understand them is to think of XML as
the "face" (the design) and Java as the "brain" (the logic).
Function of .xml Files (The "Face")
The .xml (eXtensible Markup Language) files are used to define the User Interface (UI) of your
application. They are static "layout" files, found in the res/layout folder.
• Blueprint: Think of an XML file as the architectural blueprint for a screen. It describes
what elements are on the screen and where they are placed.
• Defines Views: You use XML tags to create visual components, which are called
"Views." For example, you use <Button> to add a button, <TextView> to add text, and
<ImageView> to add an image.
• Static Properties: You also use XML to set the static properties of these views, such as
the text on a button (android:text="Click Me"), the color of the background, the size of
the text, and the spacing.
By itself, an XML file is just a static drawing; it can't do anything.
Function of .java Files (The "Brain")
The .java files (found in the java/[Link] folder) provide the logic and functionality
that brings the app to life.
• Controls Behavior: This is where you write the code to make your app interactive.
• Event Handling: The Java code "listens" for user actions (events). For example, what
happens when the user taps the <Button> you defined in your XML? The Java code
handles that "click event."
• Connecting to XML: In your Java file (like [Link]), you write code to find
the views from your XML (e.g., findViewById). Once you have a reference to the button,
you can tell it what to do.
• Performing Actions: When the button is clicked, your Java code runs to perform tasks
like calculating a number, saving data, opening a new screen, or connecting to the
internet.
This separation is a core part of Android development: XML handles the look, and Java handles
the work.
[Link]:
Dalvik Virtual Machine (DVM)
Dalvik Virtual Machine (DVM) was the original runtime environment used by the Android
operating system, from its first version up until Android 4.4 (KitKat). A "runtime" is the engine
inside the OS that is responsible for running your apps.1 Think of it as a special "virtual
computer" built inside your phone that translates app code into instructions your phone's
processor can understand.
The most important feature of DVM was its use of JIT (Just-In-Time) compilation. Here’s
how it worked: When you downloaded an app, it came as a .dex (Dalvik Executable) file.2 This
file is not native to the phone's processor. So, every time you opened the app, the DVM's JIT
compiler would quickly translate the parts of the code it needed at that moment into native
machine code.
This method had one main advantage: app installations were very fast because the phone didn't
do any heavy processing upfront. However, it had significant disadvantages. App launch times
were slower because of that "just-in-time" translation step. Furthermore, because the phone's
processor was constantly working to translate code as you used the app, it led to higher battery
consumption. As phones became more powerful, DVM's slowness became a major problem.
Android RunTime (ART)
Android RunTime (ART) is the modern runtime environment that replaced Dalvik.4 It was
introduced with Android 5.0 (Lollipop) and is the standard on all Android devices today.5 It was
designed from the ground up to fix all the performance problems that DVM had.
ART's biggest and most important difference is its use of AOT (Ahead-Of-Time) compilation.
Unlike DVM, which compiled code every time you ran the app, ART compiles the code only
once. When you first install an app from the Google Play Store, ART takes the entire .dex file
and translates it into native machine code right then and there.7 This pre-compiled code is then
stored on your device.
The benefits of this AOT approach are huge:
1. Faster App Launch: Because all the code is already translated, apps open much, much
faster.
2. Better Performance: The entire app runs more smoothly and feels more responsive.
3. Improved Battery Life: The phone's processor doesn't have to waste energy on
compilation while the app is running, which saves battery.
The only small trade-offs are that app installations take a few seconds longer (because of that
one-time compilation step) and the installed app takes up slightly more storage space. ART also
features a more advanced "garbage collector" (for cleaning up memory), which helps apps run
without stuttering.
SET-II
[Link]:
In Android, you cannot perform long-running tasks like fetching data from a database on the
main UI thread, as it will freeze the app. The Loader framework is designed to solve this by
loading data in the background.
Think of it as a team with three main roles:
1. LoaderManager (The Boss): This is the manager that coordinates the entire data-
loading operation.
2. CursorLoader (The Worker): This is the specialist who actually goes to the database
(on a background thread) to fetch the data.
3. LoaderCallbacks (The Instruction Manual): This is the set of instructions you write to
tell the LoaderManager what to do.
The Role of LoaderManager and LoaderCallbacks
The LoaderManager is an Android system component that manages one or more "Loaders"
(like a CursorLoader). You don't create a CursorLoader yourself; you ask the LoaderManager to
create and manage one for you. This is smart because the LoaderManager is aware of your app's
lifecycle (e.g., screen rotations, app closing) and will automatically handle re-querying data or
reusing old data without freezing the UI.
But how does the LoaderManager know what data you want or what to do when the data is
ready?
This is the job of [Link]. This is an "interface," which is like a
contract. Your Activity or Fragment must "implement" (agree to) this contract by providing three
specific methods.1 These methods are the "callbacks" (the instructions) that the LoaderManager
will "call back" at different stages of the loading process.
Significance of the Callback Methods
The LoaderCallbacks interface forces you to write three key methods that are the core of the
framework:
1. onCreateLoader(int id, Bundle args)
a. Significance: This is where you create the worker. The LoaderManager calls this
method exactly once when you first request the data.
b. Your Job: Your only job here is to new up and return your CursorLoader. You
tell it what to fetch (e.g., the URI for contacts, the specific columns you want,
etc.). You don't actually run the query here; you just hand the "worker" (the
CursorLoader) to the manager.
2. onLoadFinished(Loader<Cursor> loader, Cursor data)
a. Significance: This is the most important method. It is called on the main UI
thread after the CursorLoader has successfully finished its background query.
b. Your Job: The LoaderManager hands you the final Cursor (the data). Your job is
to take this data and update your app's screen. For example, you would pass this
Cursor to an adapter to show the list of contacts in a ListView or RecyclerView.
3. onLoaderReset(Loader<Cursor> loader)
a. Significance: This is a cleanup method. It is called when the LoaderManager
knows the data is no longer valid (e.g., the app is closing or the underlying data
has changed).
b. Your Job: Your job is to remove any old data from your UI. You would typically
tell your adapter that the data is now null. This prevents your app from using stale
data and avoids memory leaks. You do not close the Cursor yourself; the
framework handles that.
[Link]:
How Broadcast Receivers Work
A BroadcastReceiver is an Android component that allows your app to "listen" for and respond
to system-wide or app-specific messages, known as "broadcasts." Think of it as your app's ear,
waiting for a specific announcement.
These announcements (broadcasts) are sent out as Intent objects by the Android system or by
other apps when an event of interest occurs. Examples of system broadcasts include:
• The device has finished booting up (ACTION_BOOT_COMPLETED).1
• The network connection has changed (e.g., Wi-Fi disconnected).2
• The battery is low (ACTION_BATTERY_LOW).
• A new photo has been taken by the camera.
Here’s the step-by-step process:
1. The Broadcast: An event happens. The system (or an app) creates an Intent describing
the event (e.g., ACTION_BATTERY_LOW) and broadcasts it across the entire system.
2. Registration (Listening): Your app must first tell the system it's interested in a specific
broadcast. There are two ways to do this:
a. Static Registration: You declare the receiver in your app's [Link]
file. This lets the system know your app cares about an event even if your app is
currently closed. The system can start your app to handle the broadcast.
b. Dynamic Registration: You register the receiver in your code (e.g., within an
Activity).3 This is useful for events you only care about while your app is actively
running. The receiver is unregistered when the component (like the Activity) is
destroyed.
3. The onReceive() Method: When the system sends a broadcast that your receiver is
registered for, it creates an instance of your BroadcastReceiver and calls its single most
important method: onReceive(Context context, Intent intent).
4. Taking Action: Inside the onReceive() method, you write the code for what you want to
do. This method runs on the main UI thread and must complete very quickly (within 10
seconds).4 It's meant for short, simple tasks like starting a Service, showing a notification,
or updating a database.
Example Scenario: A Download Manager App
Imagine you are building an app that downloads large files. You want this app to be smart and
only download over Wi-Fi to avoid using the user's expensive mobile data.
• Problem: If the user starts a download on Wi-Fi and then leaves their house, the phone
will switch to mobile data, and the download will either fail or cost the user money.
• Solution with a BroadcastReceiver:
o You would create a BroadcastReceiver and dynamically register it within your
app to listen for the CONNECTIVITY_CHANGE broadcast.
o When the user's network connection changes (e.g., Wi-Fi disconnects and mobile
data connects), the Android system sends this broadcast.
o Your receiver's onReceive() method is triggered.5
o Inside this method, your code checks the new network status.
o If it detects that Wi-Fi is no longer connected, your code can immediately pause
the download service.
o Later, when the user connects to Wi-Fi again, another broadcast is sent, and your
receiver can automatically resume the download.
This makes the app much more intelligent and user-friendly, reacting to system events without
the user having to do anything.
[Link]:
CRUD stands for the four basic, essential operations that can be performed on any database:
Create, Read, Update, and Delete.1 These are the fundamental actions for managing data in a
table.
Let's use a simple example of a table named Users to illustrate each operation.
Imagine the Users table has this structure:
• id (INTEGER, PRIMARY KEY)
• name (TEXT)
• email (TEXT)2
1. Create (INSERT)
What it is: The "Create" operation is used to add new data, or a new record (row), into a
database table.3 In SQL (the language used by SQLite), this is done with the INSERT INTO
command.
Example:
To add a new user named "Nikhil" with the email "nikhil@[Link]" to our Users table, you
would use the following SQL command:
SQL
INSERT INTO Users (name, email)
VALUES ('Nikhil', 'nikhil@[Link]');
This command creates a new row in the Users table and fills the name and email columns with
the provided values.
2. Read (SELECT)
What it is: The "Read" operation is used to retrieve or fetch data from a database table. This is
the most common operation you will perform. The SELECT command is used for this. You can
read all data or use a WHERE clause to filter for specific rows.
Example (Read all):
To get a list of every user in the table:
SQL
SELECT * FROM Users;
(* is a wildcard that means "all columns")
Example (Read specific):
To find only the user whose name is "Nikhil":
SQL
SELECT * FROM Users WHERE name = 'Nikhil';
3. Update (UPDATE)
What it is: The "Update" operation is used to modify or change existing data that is already in a
table.4 This is done using the UPDATE command.5 It is crucial to use a WHERE clause to
specify which row(s) you want to change.
Example:
Let's say Nikhil's email address has changed. We want to update his record:
SQL
UPDATE Users
SET email = '[Link]@[Link]'
WHERE name = 'Nikhil';
This command finds the row where the name is "Nikhil" and changes only the email column for
that specific row.
4. Delete (DELETE)
What it is: The "Delete" operation is used to permanently remove one or more records (rows)
from a database table.6 This is done with the DELETE FROM command. Just like with
UPDATE, using a WHERE clause is essential to ensure you only delete the specific data you
intend to.7
Example:
To remove the user "Nikhil" from the Users table:
SQL
DELETE FROM Users
WHERE name = 'Nikhil';
This command finds the row where name is "Nikhil" and removes that entire row from the table.