1. What is an Activity?

An Activity in mobile application development, particularly in Android, is one of the

fundamental building blocks of an application. It represents a single screen with a user
interface (UI) that allows users to interact with the application. Each activity typically
corresponds to one screen, and an app can have multiple activities, each representing
different screens or different states of the UI.
Key Concepts of an Activity:

● UI Representation:
● Lifecycle Management:
● Navigation:
● Interaction with Other Components:
● Configuration Changes:

2. Life-Cycle of an Activity
 Activities have a well-defined lifecycle managed by the Android operating system. The
lifecycle of an activity includes several stages, such as:

a. onCreate(): Called when the activity is first created. It’s where you initialize your
activity, set up the UI, and connect with other components.
b. onStart(): Called when the activity becomes visible to the user.
c. onResume(): Called when the activity starts interacting with the user.
d. onPause(): Called when the activity is partially obscured by another activity (like a
dialog).
e. onStop(): Called when the activity is no longer visible to the user.
f. onDestroy(): Called before the activity is destroyed by the system or by the user’s
action.

3. What is a Service in Android Development?

In Android development, Services are a type of component that performs long-running

operations in the background without providing a user interface. Services are useful when
you need to keep some processing going even when the user is not interacting directly with
your app or when an activity is not in the foreground.

Types of Android Services

1. Foreground Services:

Services that notify the user about its ongoing operations are termed Foreground Services.
Users can interact with the service by the notifications provided about the ongoing task.
Such as in downloading a file, the user can keep track of the progress in downloading and
can also pause and resume the process.

2. Background Services:

Background services do not require any user intervention. These services do not notify the
user about ongoing background tasks and users also cannot access them. The process like
schedule syncing of data or storing of data falls under this service.

3. Bound Services:

A Bound Service in an Android application is a service that allows other application

components, such as activities, to bind to it and interact with it through a well-defined
interface. This type of service is designed to provide a client-server interface that enables
components to communicate with the service, request data, perform operations, and receive
results back.
4. The Life Cycle of Android Services

In Android, services have 2 possible paths to complete their life cycle: Started and Bounded.

1. Started Service (Unbounded Service):

Following this path will initiate a service when an application component calls
the startService() method. Once initiated, the service can run continuously in the
background even if the element is destroyed which was responsible for the start of the
service.

Two options are available to stop the execution of service:

● By calling stopService() method,

● The service can stop itself by using stopSelf() method.

Use Cases for Unbounded Services:

● Downloading files or data from the internet.
● Uploading files to a server.
● Processing large files.
● Playing music in the background.

2. Bounded Service:

It can be treated as a server in a client-server interface. By following this path, android

application components can send requests to the service and fetch results. A service is
termed as bounded when an application component binds itself with a service by
calling bindService() method. To stop the execution of this service, all the components must
unbind themselves from the service by using unbindService() method.

Use Cases for bounded Services:

A common use case for a bound service is a music player app where the user interface (UI)
components, like activities or fragments, need to control playback (play, pause, stop) and get
information about the current track (like the track's duration and current position).
 Example of Services

To carry out a downloading task in the background, the startService() method will be called.
To get information regarding the download progress and to pause or resume the process
while the application is still in the background, the service must be bounded with a
component that can perform these tasks.

5. What is an Intent?

In Android programming, Intents are a powerful mechanism used to facilitate

communication between different components within an Android application, or even
between different applications. Intents are essentially messaging objects that allow you to
request an action from another app component, such as starting an activity, sending a
broadcast, or starting a service.

6. Types of Intents:

1. Explicit Intents:
o Explicit intents specify the exact component (activity, service, or broadcast receiver)
to be started. They are typically used within your own application when you know
the exact class you want to start.
o Example: Starting a new activity within the same app.

2. Implicit Intents:
o Implicit intents do not specify a specific component to start. Instead, they declare a
general action to perform, and the Android system will resolve the best component
(either within your app or another app) that can handle that action.
 o Example: Sharing a piece of text using any app that supports sharing
7. Key Uses of Intents:
1. Starting Activities:

o The most common use of intents is to start activities. When you want to open a new
screen or switch from one screen to another within your app, you use an intent.

o For example, opening a detail screen from a list item:

2. Starting Services:

o Intents are used to start a service. You can either start a service using an explicit
intent (if you know the service) or with an implicit intent (if you want any service
that can handle the action).

3. Sending Broadcasts:

o Intents are used to send broadcasts, either within your app or system-wide, to notify
other components of events. Broadcast receivers can then listen to these broadcasts
and react accordingly.

4. Transferring Data:

o Intents can carry additional data that you want to pass to the target component. This
data is added as "extras" in the intent, which the receiving component can then
extract and use.

o For example, sending data to a new activity:

5. Navigating Between Applications:

o Implicit intents allow your app to interact with other apps. For example, you can use
an intent to open a web browser, send an email, or dial a phone number.

o Example: Opening a web page in a browser.

Broadcasting Intents

Broadcasting Intents in Android is a powerful feature that allows your app to send messages to other
apps or system components. These messages are broadcasted using Intents, and any interested
component can receive them and act accordingly.

Types of Broadcasts:
● Normal Broadcasts:

o These are unordered broadcasts that are delivered asynchronously. The receivers of
the broadcast are not guaranteed to run in any specific order.

o All registered receivers will receive the broadcast, and they will handle it at their own
pace.

● Ordered Broadcasts:

o These are delivered to one receiver at a time in a specified order.

o Each receiver can either stop the broadcast from being propagated to others or
modify the data in the Intent before passing it along.

● Sticky Broadcasts:

o These are a special type of broadcast that "sticks around" even after being sent. They
allow receivers to obtain the data even if they register after the broadcast was sent.

o Note: Sticky broadcasts are deprecated for third-party apps starting from Android 5.0
(Lollipop).

Broadcasting an Intent:

● To broadcast an Intent, you generally use one of the following methods:

o sendBroadcast(): Sends a normal broadcast to all receivers.
o sendOrderedBroadcast(): Sends an ordered broadcast where receivers
handle the broadcast in sequence.
o sendStickyBroadcast(): (Deprecated) Sends a sticky broadcast

LocalBroadcastManager:
● LocalBroadcastManager is a utility class that allows you to send broadcasts within your app,
ensuring that the broadcast doesn't leave your app.

● This is more efficient and secure because it avoids unnecessary inter-app communication.
Use Cases for Broadcasting Intents:
● System Broadcasts: You can send a broadcast when your app detects a specific system event,
like low battery or screen off, and other apps or components can act on it.

● Custom Events: For example, your app could broadcast an Intent when a user logs in, and
other components within your app could listen for this event and update their UI or state
accordingly.
Receiving Intents

Receiving Intents in Android allows an app component, such as an Activity, Service, or

BroadcastReceiver, to respond to an event or request from another component or app. When an
Intent is broadcasted or sent, it can be received by components that are registered to listen for that
particular action.

Receiving Intents in an Activity

● When an Activity is started with an Intent, you can retrieve the data passed with the Intent in
the onCreate() or onNewIntent() methods.

Receiving Intents in a BroadcastReceiver

● BroadcastReceivers are components that respond to broadcast messages (Intents)

sent by the system or other applications.

Receiving Intents in a Service

● A Service can also receive Intents, typically via the onStartCommand() method if it’s an
unbounded service.
Intent filters

Intent filters in Android are a crucial component that enables the Android system to understand
what kind of Intents an app component (like an Activity, Service, or BroadcastReceiver) can respond
to. An Intent filter is essentially a declaration in the app's manifest file (or sometimes
programmatically) that specifies the types of Intents the component can handle.

Key Components of an Intent Filter:

An Intent filter consists of three main elements:

1. Action:

● This is the primary thing the component can do. It corresponds to the action string in an
Intent.

● Common actions include [Link], [Link], etc.

● Custom actions can also be defined and used.

2. Category:

● This is an additional classification that provides more context about the action.
● It is often used to specify the type of component that should handle the Intent. The most
common category is [Link], which is required for any component
that responds to implicit Intents.
● Other categories include [Link],
[Link], etc.

3. Data:

● This defines the type of data that the component can handle. It specifies a URI (Uniform
Resource Identifier) and/or a MIME type.

● This is crucial for components like activities that want to respond to specific types of content
(e.g., opening a specific type of file).

Practical Uses:

● Launching Activities from Other Apps: If an app wants to open a specific activity from
another app, it can do so by sending an Intent that matches the receiving activity's Intent
filter.

● Responding to System Events: Components like BroadcastReceiver can listen to system-wide

broadcasts (e.g., connectivity changes) by declaring appropriate Intent filters.

● Content Sharing: Intent filters make it easy for apps to handle shared content, like images,
text, or files, from other apps.

Important Points:

● If multiple components have matching Intent filters, the user might be prompted to choose
which one to use.

● If no components match the Intent, the system might throw an error or the action will simply
not be performed.
 Android Manifest file

The Android Manifest file is a critical component of Android app development. It

contains essential metadata and configurations, such as app permissions, activities,
services, and intent filters. It defines the app's structure and behavior, ensuring proper
execution on Android devices and interaction with the system and other apps.

Purpose of the Android Manifest File

The Android Manifest file, typically named [Link], is a critical file in

Android app development. Its primary purposes are:

● App Identification:
The manifest file identifies the app to the Android operating system, providing
essential information such as the app's package name and version code. This
information is crucial for the system to manage and update the app.
● Permissions:
It specifies the permissions required by the app to access device resources or interact
with other apps. Android enforces these permissions to protect user privacy and
security.
● App Components:
The manifest defines the app's components, including activities, services, broadcast
receivers, and content providers. These components are the building blocks of an
Android app.
● Intent Filters:
It declares intent filters for components, which specify the types of intents they can
respond to. This allows other apps and the system to interact with the app's
components.
● App Configuration:
Various app configurations, such as screen orientations, supported screen sizes, and
minimum Android API levels, are specified in the manifest.
● App Icon and Label:
The manifest defines the app's launcher icon and label, which appear on the device's
home screen and app drawer.

Structure of the Android Manifest File

The Android Manifest file is written in XML (eXtensible Markup Language) and
follows a specific structure. Here's a breakdown of its key elements:

● <manifest> Element:
This is the root element of the manifest file. It contains essential attributes
like package (the app's unique identifier), versionCode (an integer representing the
app's version), and versionName (a human-readable version string).
● <manifest xmlns:android="[Link]
● package="[Link]"
● android:versionCode="1"
● android:versionName="1.0">
● Permissions:
The <uses-permission> element is used to declare permissions required by the app.
For example, if your app needs access to the device's camera, you would include the
following:
● <uses-permission android:name="[Link]" />
● App Components:
Various components like activities, services, broadcast receivers, and content
providers are defined within the manifest. Each component has its own XML element.
For instance, an activity is defined as follows:
● <activity android:name=".MainActivity">
● <intent-filter>
● <action android:name="[Link]" />
● <category android:name="[Link]" />
● </intent-filter>
● </activity>

In this example, the <activity> element declares the MainActivity class as an activity,
and the <intent-filter> specifies that it should be the launcher activity.

● Intent Filters:
As shown in the activity example above, intent filters are used to specify the types of
intents a component can respond to. In the case of activities, the MAIN action and
LAUNCHER category indicate that this activity is the app's main entry point.
● App Configuration:
The <application> element contains app-wide configuration settings, such as the
supported screen orientations and theme:
● <application
● android:allowBackup="true"
● android:icon="@mipmap/ic_launcher"
● android:label="@string/app_name"

android:theme="@style/AppTheme">
 permissions

In Android application development, permissions are a way to protect the privacy

and security of users by controlling what sensitive information or system features an
app can access. When an app needs to use certain features or access sensitive data, it
must explicitly request permission from the user.

Types of Permissions

1. Normal Permissions:
o These are permissions that do not pose a significant risk to the user's privacy
or the device's operation. For example, accessing the internet or setting a
wallpaper. These permissions are automatically granted by the system when
the app is installed, and the user is not explicitly asked for approval.
2. Dangerous Permissions:
o These permissions can potentially affect the user's privacy or the device's data.
For example, accessing the user's location, contacts, camera, microphone, or
sending SMS messages. Because of their sensitivity, the system asks the user
to grant these permissions explicitly, usually at runtime, when the app first
tries to use the feature.
3. Signature Permissions:
o These are granted only if the requesting app is signed with the same certificate
as the app that declared the permission. This is usually used for sharing data or
features between apps from the same developer.
4. Special Permissions:
o These include permissions like SYSTEM_ALERT_WINDOW (which allows
an app to display overlays on top of other apps) and WRITE_SETTINGS
(which allows an app to modify system settings). These require the user to
manually enable them in the device settings.

How Permissions Work

● Requesting Permissions: In Android, permissions are requested in two main ways: at

install time (for normal permissions) and at runtime (for dangerous permissions).
o Install-time Permissions: For normal permissions, the user grants these
automatically when they install the app.
o Runtime Permissions: For dangerous permissions, the app must request them
at runtime. The system will prompt the user with a dialog, asking them to
allow or deny the permission. The user can also revoke these permissions later
through the device settings.
 Context
A Context gives you access to information about the current state of your
Application. It grants access to resource files, pictures, themes/styles, and
external directory locations to Activities, Fragments, and Services.

Retrieving Context
Retrieving a context means to get/extract the current state(it could be activity
context or application context). Now, Let's take a look at three of the most
commonly used Context retrieval functions.
1. getContext(): It returns the context associated with the Activity from
which it was invoked.
2. getApplicationContext(): It returns the context, which is linked to the
Application and contains all of the activities that are running within it.
Types of Context in Android
In Android, there are primarily two types of context available. These are as
follows:
● Application Context
● Activity Context
Activity Context

Context is connected to an Activity and its lifecycle in getContext(). Context can

be thought of as a layer that sits behind Activity and will last as long as Activity
does. The context will die when the Activity dies(mean when on destroy is
called in Activity).
Usage:
Activity Context is most useful when we are doing the UI-related work(front
end work) like creating a toast or alert dialog box or an object with utilization
only up to the lifecycle of that Activity.

Application Context
It's used to get the context associated with the Application, which contains all
of the activities running within it. Our context is connected to the Application
and its lifetime in getApplicationContext(). It can be thought of as a layer that
sits behind the entire program. So, as long as it does not kill (on destroy call)
the entire Application, this context stays alive.

Activity vs Application Context

The main difference is that the Application's Context is unrelated to the user
interface. This means that We shouldn't utilize it to Inflate a Layout, Show a
Dialog(alert dialogue builder) or Start an Activity. The rest of the functionality
from the Activity's Context is likewise available in the Application's Context.