DroidCore
Module 4 of 20

Android App Components

Explore the core building blocks of Android applications: Activities, Services, Broadcast Receivers, and Content Providers.

Module 4: Android App Components

Learning Objectives

By the end of this module, you’ll understand:

  • Why Android uses components instead of a single main() function
  • The role of the Android Framework in managing components
  • The five core application components
  • How components communicate
  • The concept of Intents
  • Processes, tasks, and the back stack (high level)
  • Component lifecycles
  • When to use each component
  • Real-world examples from popular apps

1. The Philosophy Behind Android Components

Let’s begin with a question.

How does a C program start?

int main() {
    printf("Hello");
}

Execution begins at main().

How about Java?

public static void main(String[] args) {
    System.out.println("Hello");
}

Again, main() is the entry point.

Now imagine Android worked the same way.

fun main() {
    showLoginScreen()
}

Would that work?

No.

Because Android has problems that desktop operating systems don’t.

For example:

  • Phone call arrives
  • Screen rotates
  • Battery is low
  • User presses Home
  • App goes to background
  • Notification arrives
  • Another app wants to open your screen
  • Camera is already in use

Android needs full control over your app.

So instead of allowing your app to control execution,

Android controls execution.

This is the biggest mental shift every Android developer must make.

2. The Android System Is the Boss

Your app never decides:

  • when to start
  • when to stop
  • when to pause
  • when to destroy itself

Android decides.

Think of Android as an operating system scheduler.

          Android System
          /     |      \
         /      |       \
    Gmail   WhatsApp   Spotify

Android constantly decides:

  • Which app gets CPU time?
  • Which app stays in memory?
  • Which app gets killed?
  • Which app gets resumed?

Your code simply responds.

3. Components Are Entry Points

Instead of one main() method,

Android provides multiple entry points.

Each entry point solves a different problem.

Application
     │
     ├── Activity
     ├── Service
     ├── Broadcast Receiver
     ├── Content Provider
     └── Application Class

Notice something.

These aren’t helper classes.

They are objects Android itself creates.

You almost never instantiate an Activity yourself.

Android does.

4. High-Level View

Imagine Instagram.

Instagram

│

├── LoginActivity

├── FeedActivity

├── StoryService

├── NotificationReceiver

├── ImageProvider

Every feature belongs to one of Android’s components.

5. Activity

An Activity represents one UI-focused interaction with the user.

Most people simplify this to:

“One screen.”

That’s a useful approximation, but it’s not the complete story.

A more accurate definition is:

An Activity is a lifecycle-aware controller responsible for presenting a user interface and responding to user interaction.

Example:

Amazon

SplashActivity

↓

LoginActivity

↓

HomeActivity

↓

ProductActivity

↓

CartActivity

Each Activity has its own lifecycle.

Android creates and destroys them as needed.

What Does an Activity Do?

Responsibilities include:

  • Display UI
  • Handle button clicks
  • Request permissions
  • Navigate to other screens
  • Receive lifecycle callbacks

What it shouldn’t do:

  • Business logic
  • Networking
  • Database access

Those responsibilities belong elsewhere (e.g., ViewModels and repositories).

Example:

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

    }

}

Notice:

You never call onCreate().

Android calls it.

6. Fragment

A Fragment is often described as:

A reusable portion of UI.

That definition is true, but incomplete.

A Fragment is:

A modular, lifecycle-aware UI component hosted inside an Activity.

Think of an Activity as a house.

The rooms are Fragments.

Activity

│

├── Home Fragment

├── Profile Fragment

├── Settings Fragment

The house owns the rooms.

The rooms cannot exist without the house.

Similarly,

a Fragment cannot exist without an Activity host.

Why Were Fragments Invented?

Imagine tablets.

Phone:

+------------+

Email List

+------------+

Tablet:

+--------------------------+

Email List | Email Details

+--------------------------+

Google wanted the same code to work on phones and tablets.

Fragments solved this by allowing multiple reusable UI pieces within one Activity.

Today, Fragments are also widely used with the Navigation Component, although some modern Compose apps use a single-Activity architecture with composable destinations instead of Fragments.

7. Service

A Service performs work without presenting a UI.

Examples:

Spotify

Music keeps playing

↓

You leave the app

↓

Music continues

How?

A Service.

Other examples:

  • File upload
  • Download manager
  • Fitness tracking
  • Location tracking
  • Bluetooth communication

Notice:

The user doesn’t interact directly with a Service.

Service Types

Foreground Service

Visible to users.

Example:

Spotify

🎵 Playing Music...

The persistent notification lets users know the service is active.

Background Service

Historically used for background work, but modern Android places strict limits on long-running background services to improve battery life.

Today, for most deferrable background tasks, you’ll use WorkManager, which we’ll cover later.

8. Broadcast Receiver

Android constantly broadcasts system events.

Examples:

Battery Low

Screen Off

Boot Completed

Airplane Mode Changed

Network Connected

Apps can register to receive some of these events.

Imagine Android saying:

“Hey everyone!

The battery is low.”

Every interested app receives the announcement.

Example:

Android

↓

Battery Low Broadcast

↓

Your Receiver

↓

Reduce Sync Frequency

Receivers are designed to do lightweight work and, if necessary, hand off longer tasks to components like WorkManager.

9. Content Provider

Apps normally cannot access each other’s private data.

Example:

Can WhatsApp read Gmail emails?

No.

Android sandboxes apps.

So how can apps safely share data?

Content Providers.

Example:

Your Contacts app stores:

Name

Phone

Email

Another app can request access (with permission) through the Contacts Content Provider.

Contacts App

↓

Content Provider

↓

Your App

The provider controls what data can be read or written.

Many apps consume Content Providers without ever implementing one themselves.

10. Application Class

There is another important component many developers forget.

class MyApplication : Application()

Only one instance exists for your app process.

It’s created before any Activity.

Common uses:

  • Dependency Injection initialization (e.g., Hilt)
  • Logging
  • Analytics SDK setup
  • Crash reporting
  • Global configuration

Avoid storing screen-specific data here; it’s intended for application-wide initialization.

11. Component Communication

How do these components talk to each other?

They don’t call each other directly in most cases.

Instead,

Android provides Intents.

Think of an Intent as a message.

Activity A

↓

Intent

↓

Android

↓

Activity B

The Activity doesn’t launch another Activity directly.

It asks Android to do it.

We’ll study Intents in depth in a later module.

12. Component Lifecycles

Every component has its own lifecycle.

Activity:

Created

↓

Started

↓

Resumed

↓

Paused

↓

Stopped

↓

Destroyed

Fragment:

Attach

↓

Create

↓

Create View

↓

Resume

↓

Destroy View

↓

Detach

Service:

Create

↓

Start

↓

Destroy

Android invokes these callbacks as the component’s state changes.

13. Processes and Components

An app process can host multiple components simultaneously.

Example:

App Process

│

├── LoginActivity

├── MusicService

├── NotificationReceiver

These components can interact within the same process, but Android may also start them independently if needed.

14. Tasks and the Back Stack (High Level)

Suppose you open an app.

Home

↓

Login

↓

Dashboard

↓

Settings

Android keeps these Activities in a back stack.

Top

Settings

Dashboard

Login

Home

When the user presses Back:

Settings is popped off the stack, revealing Dashboard.

This stack-based navigation is fundamental to Android’s user experience. We’ll explore tasks and the back stack in greater detail when discussing navigation.

15. Putting It All Together

Imagine you’re using Spotify.

User opens app
        │
        ▼
MainActivity
        │
        ▼
User taps Play
        │
        ▼
MusicService starts
        │
        ▼
User presses Home
        │
        ▼
Activity stops
        │
        ▼
MusicService continues
        │
        ▼
Headphones unplugged
        │
        ▼
Broadcast Receiver notified
        │
        ▼
Music pauses

Notice how different components collaborate to deliver the experience.

Real-World Examples

AppComponentResponsibility
GmailActivityShow inbox
WhatsAppActivityChat screen
SpotifyServiceContinue music playback
Google MapsServiceNavigation in the background
PhoneBroadcast ReceiverReact to boot completion
ContactsContent ProviderShare contact information securely

Common Mistakes Beginners Make

❌ Putting all logic in an Activity.

Activities should focus on UI. Business logic belongs in ViewModels or other layers.

❌ Treating Fragments like mini-Activities.

Fragments are hosted by Activities and should be designed as reusable UI modules.

❌ Running long tasks in a Broadcast Receiver.

Receivers should return quickly. Schedule longer work appropriately.

❌ Using a Service for every background task.

Modern Android encourages WorkManager for many background jobs instead of long-running services.

Key Takeaways

  • Android is component-based, not main()-based.
  • The Android system creates and manages components.
  • Activities handle user interactions and display UI.
  • Fragments provide modular, reusable UI hosted by Activities.
  • Services perform work without a user interface.
  • Broadcast Receivers respond to system-wide events.
  • Content Providers enable secure data sharing between apps.
  • The Application class is used for app-wide initialization.
  • Components communicate primarily through Intents.
  • Every component has a lifecycle that the Android system controls.

Interview Questions

  1. Why doesn’t Android use a traditional main() method?
  2. What is the responsibility of an Activity, and what should it avoid doing?
  3. How does a Fragment differ from an Activity?
  4. When should you use a Service instead of a WorkManager task?
  5. What is a Broadcast Receiver, and why should it do minimal work?
  6. How do Content Providers maintain app security while allowing data sharing?
  7. What is the purpose of the Application class?
  8. How do Intents enable communication between Android components?
  9. Explain the difference between an app process and an Activity.
  10. What is the Android back stack, and how does it affect navigation?

What’s Next: Module 5 – Activity Lifecycle (Deep Dive)

This is arguably the most important module in Android development.

We’ll go far beyond memorizing lifecycle callbacks. You’ll learn:

  • Why the Activity lifecycle exists.
  • Exactly when each callback is invoked.
  • What Android is doing internally during each transition.
  • How configuration changes (like rotation) affect Activities.
  • Why Activities are destroyed and recreated.
  • How to save and restore UI state.
  • Common lifecycle bugs (memory leaks, duplicate API calls, lost state).
  • How ViewModels interact with the lifecycle.

By the end of that module, you’ll understand one of the most frequently tested and practically important concepts in Android development.

← Previous Module Module 3: Android Project Structure & Build System Next Module → Module 5: Activity Lifecycle (Deep Dive)