DroidCore
Module 1 of 20

Android Ecosystem & Architecture

Learn the foundations of the Android operating system, its software stack, kernel, HAL, and runtime environment.

Module 1: Android Ecosystem & Architecture

Learning Objectives

By the end of this module, you should understand:

  • What Android actually is
  • How Android differs from other operating systems
  • What happens when an Android phone boots
  • How an Android app runs
  • Why Android apps are different from desktop applications
  • The Android software stack
  • The Android application lifecycle at a high level
  • Why Android has components like Activities and Services

1. What is Android?

Most people answer:

“Android is an operating system.”

That’s correct—but incomplete.

A better definition is:

Android is an operating system plus an application framework that allows developers to build apps for phones, tablets, TVs, watches, cars, and more.

Android is based on the Linux kernel, but it isn’t “just Linux.”

Think of Android as a layered cake.

+---------------------------+
|       Your App            |
+---------------------------+
| Android Framework         |
+---------------------------+
| Android Runtime (ART)     |
+---------------------------+
| Native Libraries          |
+---------------------------+
| Linux Kernel              |
+---------------------------+

Every Android app interacts with these layers, whether you realize it or not.

2. What Does an Operating System Do?

An operating system is the manager of all hardware and software resources.

Imagine a restaurant.

  • Customers = Apps
  • Kitchen = CPU
  • Pantry = Memory
  • Waiter = Operating System

Apps don’t directly access the CPU or hardware.

Instead:

App
   ↓
Operating System
   ↓
Hardware

If every app could access the hardware directly:

  • apps could crash the phone
  • steal data
  • interfere with each other
  • drain the battery

Android prevents this by acting as a gatekeeper.

3. Why Android Uses Linux

Android is built on top of the Linux kernel because Linux already provides:

  • Process management
  • Memory management
  • Security
  • File system
  • Device drivers
  • Networking

The Android team added:

  • Touch support
  • Power management
  • Mobile app framework
  • Notification system
  • Runtime (ART)

So Android is not “Linux with icons.”

It’s Linux plus many Android-specific layers.

4. Android Software Stack

Let’s explore each layer.

+--------------------------------+
| Applications                   |
+--------------------------------+
| Application Framework          |
+--------------------------------+
| Android Runtime (ART)          |
+--------------------------------+
| Native C/C++ Libraries         |
+--------------------------------+
| Hardware Abstraction Layer     |
+--------------------------------+
| Linux Kernel                   |
+--------------------------------+

Layer 1: Linux Kernel

This is the foundation.

Responsibilities:

  • CPU scheduling
  • Memory allocation
  • Battery management
  • Security
  • Drivers (camera, Bluetooth, Wi-Fi, audio)

Without the kernel, Android wouldn’t know how to communicate with the hardware.

Example:

You open the Camera app.

The Camera app does not talk directly to the camera hardware.

Instead:

Camera App
      ↓
Camera Framework
      ↓
Camera Driver
      ↓
Linux Kernel
      ↓
Camera Hardware

Layer 2: Hardware Abstraction Layer (HAL)

This layer hides hardware differences.

Imagine two phones:

Phone A

Sony Camera Sensor

Phone B

Samsung Camera Sensor

Their hardware is different.

Instead of every app handling both sensors, Android provides a common interface:

App
 ↓
Camera API
 ↓
HAL
 ↓
Actual Camera Driver

The app only uses the Camera API, and the HAL translates those calls to the specific hardware.

This is why the same app can work on many different Android devices.

Layer 3: Native Libraries

These are written in C and C++ for performance.

Examples include:

  • SQLite (database)
  • OpenGL ES (graphics)
  • Vulkan (graphics)
  • SSL (secure networking)
  • Media codecs (audio/video)

Your Kotlin code usually doesn’t call these libraries directly. Instead, the Android Framework uses them under the hood.

Layer 4: Android Runtime (ART)

This is where your Kotlin and Java code runs.

Think of ART as a translator and execution engine.

Your Kotlin code:

println("Hello")

doesn’t run directly on the CPU.

The flow looks like this:

Kotlin
      ↓
Bytecode
      ↓
ART
      ↓
Machine Code
      ↓
CPU

ART also provides:

  • Garbage Collection (automatic memory cleanup)
  • Thread management
  • Memory optimization

Layer 5: Application Framework

This is the layer Android developers interact with most.

It provides ready-made services like:

  • Activity Manager
  • Window Manager
  • Notification Manager
  • Package Manager
  • Resource Manager
  • Location Manager

For example, when you write:

startActivity(intent)

you’re using the Activity Manager, which decides how to launch the next screen.

Layer 6: Applications

At the top are apps like:

  • WhatsApp
  • Instagram
  • Gmail
  • Spotify
  • Your own app

All apps use the same framework APIs. There isn’t a special API reserved for Google’s own apps.

5. How an Android App Runs

Suppose you tap the Spotify icon.

The sequence is roughly:

User taps icon
        ↓
Launcher
        ↓
Package Manager
        ↓
Activity Manager
        ↓
Starts App Process
        ↓
ART starts JVM environment
        ↓
MainActivity created
        ↓
UI appears

Notice that your app isn’t always running. Android starts it only when needed.

6. Every App Runs in Its Own Sandbox

This is one of Android’s most important security features.

Imagine three apps:

WhatsApp
Instagram
Bank App

Each runs in a separate process with its own memory space.

+-------------+
| WhatsApp    |
+-------------+

+-------------+
| Instagram   |
+-------------+

+-------------+
| Bank App    |
+-------------+

Because of this isolation:

  • one app can’t read another app’s memory
  • one app crashing doesn’t crash all apps
  • each app has its own private storage

Access to shared resources (camera, contacts, location, etc.) requires explicit permissions.

7. Android Is Event-Driven

Desktop applications often start at main() and keep running.

Android apps are different.

They respond to events.

Examples:

  • User taps a button.
  • User rotates the phone.
  • A notification arrives.
  • The battery becomes low.
  • The screen turns off.

Android delivers these events to your app through callbacks.

For example:

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

Here, Android—not your code—calls onCreate() when it’s time to create the screen.

8. Why Android Doesn’t Have a Traditional main()

In a console application, you might write:

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

That main() method is the entry point.

In Android, the system controls when your app starts. Instead of a main(), Android creates your Application object, launches an Activity, and invokes lifecycle methods like onCreate().

This allows Android to manage memory and battery efficiently by starting and stopping apps as needed.

9. High-Level App Flow

Here’s a simplified view of how everything fits together:

User taps app icon
        │
        ▼
Android System
        │
        ▼
Application Process Created
        │
        ▼
Application Object
        │
        ▼
Main Activity
        │
        ▼
Views / Compose UI
        │
        ▼
User Interaction
        │
        ▼
Business Logic
        │
        ▼
Database / Network

This is the overall lifecycle of most Android apps.

Key Takeaways

  • Android is more than an operating system—it’s a complete platform for building apps.
  • The Linux kernel manages hardware resources and provides security.
  • The Hardware Abstraction Layer (HAL) hides differences between device hardware.
  • ART runs your Kotlin/Java code and manages memory.
  • The Android Framework provides high-level APIs for app development.
  • Apps run in isolated sandboxes for security and stability.
  • Android is event-driven: the system decides when your code runs.
  • There is no traditional main() method; Android invokes lifecycle callbacks instead.

What’s Next?

In Module 2: Kotlin Essentials for Android, we’ll focus on the Kotlin features you’ll use every day in Android development, including:

  • Why Kotlin became Google’s preferred language
  • Variables (val vs. var)
  • Functions
  • Classes and objects
  • Data classes
  • Null safety
  • Collections
  • Lambdas
  • Extension functions
  • Scope functions (let, apply, run, also, with)
  • Coroutines (an introduction)

This foundation will make the Android-specific topics much easier to understand.

Next Module → Module 2: Kotlin Essentials for Android