Introduction to Android & How It Works

What is Android?

Android is the world’s most popular mobile operating system, running on billions of phones, tablets, watches, TVs and even cars. It was built by Google on top of the Linux kernel and is open source, which is why so many manufacturers (Samsung, Xiaomi, OnePlus and others) can use and customise it.

As an app developer, you don’t need to touch Linux directly. Instead, Android gives you a friendly set of building blocks — screens, buttons, databases, notifications — and you combine them to create an app. Your job is to use these blocks well; Android handles the hard, low-level work underneath.

Why understanding the platform matters

Many beginners jump straight to writing code and then get confused when their app crashes after rotating the screen, or when a background task stops working. Almost always, the reason is a misunderstanding of how Android runs your app. Spending ten minutes on the fundamentals here will save you hours of debugging later.

The Android software stack

Think of Android as a layered cake. Each layer only talks to the one directly below it. Your app sits at the very top:

• Linux Kernel — manages memory, security, and talks to hardware (camera, Wi-Fi, sensors) through drivers.
• Hardware Abstraction Layer (HAL) — a standard interface so Android can use any manufacturer’s hardware.
• Native libraries & the Android Runtime (ART) — ART compiles and runs your app’s code efficiently.
• Framework APIs — the ready-made tools you actually call: Activities, Views, databases, notifications.
• Your app — the code you write, sitting safely on top.

The four building blocks of every app

No matter how big an app is, it is built from four kinds of components. Knowing them gives you a mental map of any Android project:

• Activity — a single screen the user sees and interacts with (login, home, profile). This is where most of your early code lives.
• Service — work that runs without a UI, like playing music or syncing data.
• BroadcastReceiver — listens for system-wide events (“battery low”, “connected to Wi-Fi”) and reacts.
• ContentProvider — a controlled way to share data between apps (for example, reading the device’s contacts).

The manifest: your app’s ID card

Every app has an AndroidManifest.xml file. The system reads it before running your app to learn which components exist, which screen launches first, and which permissions the app needs.

<manifest xmlns:android="http://schemas.android.com/apk/res/android">
  <application android:label="MyApp" android:icon="@mipmap/ic_launcher">
    <activity android:name=".MainActivity" android:exported="true">
      <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
      </intent-filter>
    </activity>
  </application>
</manifest>

The <intent-filter> with MAIN and LAUNCHER is what tells Android “this is the first screen to open when the user taps the app icon”.

Kotlin vs Java

You can write Android apps in Kotlin or Java. Kotlin is Google’s recommended language: it is shorter, safer (it prevents most null-pointer crashes), and every new Google sample uses it. We use Kotlin throughout this course.

fun main() {
    println("Hello, Android!")
}

Common beginner mistakes

• Thinking an app is “one program that runs top to bottom”. It isn’t — Android calls your components when needed.
• Forgetting that the system can destroy and recreate your screen at any time (you’ll learn how to handle this in the lifecycle lesson).
• Ignoring the manifest until something breaks.

Summary: Android is a layered OS. You build apps from four components, declared in a manifest, written in Kotlin. Master Activities first — everything else builds on them.