Android Development

Learning Objectives

• Describe the Android platform, its runtime, and the tools used to build apps for it.
• Set up an Android development environment using Android Studio and the Android SDK.
• Explain the core Android building blocks: Activities, Fragments, Views, Layouts, Intents, Services, Broadcast Receivers, and Content Providers.
• Write a simple Kotlin Activity that responds to user interaction.
• Trace the lifecycle of an Android Activity and explain why it matters for app stability.

Quick Answer

Android development is building apps for Google's Android operating system, which powers roughly 70% of the world's smartphones. Developers primarily use Kotlin (Google's preferred language since 2019) or Java, along with Android Studio, the official IDE, and the Android SDK, a set of libraries and tools for building, debugging, and packaging apps. Android apps are structured around a handful of core building blocks — Activities (screens), Fragments (reusable screen pieces), Views (UI elements), and Intents (a messaging system for navigating between screens or app components). Learning Android matters because it's the largest single platform for reaching mobile users worldwide, especially outside North America and Western Europe.

Overview

Android is an open-source operating system originally developed by Android Inc. and acquired by Google in 2005. Because manufacturers like Samsung, Xiaomi, and Google itself can license and customize it, Android runs on an enormous range of devices — from budget phones to high-end tablets to smart TVs and watches. That diversity is Android's biggest strength and its biggest development challenge: an app has to work correctly across thousands of device configurations and multiple OS versions still in active use.

At the center of Android development sits Android Studio, Google's official IDE, built on IntelliJ IDEA. It bundles a code editor, a visual layout designer, an emulator for testing without physical hardware, and Gradle, the build system that compiles Kotlin/Java code and packages it into an installable .apk or .aab file. Since 2019, Kotlin has been Google's recommended language for Android — it's more concise than Java and has built-in protections against a notorious source of Android crashes: null pointer exceptions.

Core Concepts

The Android Runtime and SDK

Definition: The Android Runtime (ART) executes compiled app code on the device; the Android SDK is the set of libraries, APIs, and command-line tools used to build, test, and package that code.

Explanation: When you write Kotlin or Java code, it's compiled into bytecode and packaged into an .apk/.aab file. On the device, ART translates this into machine instructions the phone's processor can execute, handling memory management (garbage collection) along the way. The SDK provides the APIs your code calls into — for the camera, GPS, storage, networking, and every other capability the OS exposes.

Example: Calling Toast.makeText(this, "Saved!", Toast.LENGTH_SHORT).show() uses a class from the Android SDK (Toast) to display a small pop-up message; ART is what actually executes that call on the device.

Real-World Example: When Google releases a new Android version (say, Android 14), it ships an updated SDK with new APIs (e.g., new permission models). Developers must update their targetSdkVersion in Gradle to use these features, and Google Play eventually requires apps to target recent SDK versions before allowing updates.

Why It Matters: Understanding the SDK/runtime split explains why apps sometimes behave differently across Android versions — an API available in Android 13 might not exist on a device still running Android 9, requiring developers to write version-aware code.

Common Misunderstanding: Students often think "Android" and "Java/Kotlin" are the same thing. In reality, ART and the Android SDK form a separate execution and API environment from a standard Java Virtual Machine — you can't simply take arbitrary Java code written for a desktop app and run it unmodified on Android.

Activities, Fragments, and Views

Definition: An Activity represents a single screen with a user interface; a Fragment is a reusable portion of a UI that can live inside an Activity; a View is an individual UI element such as a button or text field.

Explanation: Every screen a user sees in a typical Android app is backed by an Activity. Activities can host one or more Fragments — useful for building UIs that adapt to different screen sizes (e.g., showing two Fragments side-by-side on a tablet but one at a time on a phone). Views are the actual widgets — Button, TextView, EditText — arranged using a Layout (e.g., ConstraintLayout, LinearLayout) that determines their position and sizing.

Example: A login screen is one Activity containing an EditText for the username, another for the password, and a Button to submit — all Views arranged inside a ConstraintLayout.

Real-World Example: A news app might use a single Activity with two Fragments — an article list and an article detail view — showing them side by side on a tablet, but navigating between them as separate full screens on a phone.

Why It Matters: This separation lets developers reuse UI pieces (Fragments) across different screen configurations without duplicating code, and it keeps each screen's logic isolated in its own Activity class.

Common Misunderstanding: Beginners sometimes assume Fragments are optional or purely advanced. In practice, most professional Android codebases use Fragments extensively, even for phone-only apps, because they make navigation and state management (via the Navigation component) far more manageable.

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        val nameInput = findViewById<EditText>(R.id.nameInput)
        val greetButton = findViewById<Button>(R.id.greetButton)
        val greetingText = findViewById<TextView>(R.id.greetingText)

        greetButton.setOnClickListener {
            val name = nameInput.text.toString()
            greetingText.text = "Hello, $name!"
        }
    }
}

Intents, Services, Broadcast Receivers, and Content Providers

Definition: These are Android's mechanisms for communication and background work: an Intent requests an action (like starting a new Activity), a Service runs code in the background, a Broadcast Receiver listens for system-wide events, and a Content Provider shares structured data between apps.

Explanation: Intents can be explicit (start a specific Activity in your own app, e.g., moving from a login screen to a home screen) or implicit (ask the OS to find any app that can handle a general action, e.g., "open this URL" or "share this photo"). Services keep running when the user isn't looking at the app — for example, playing music or downloading a file. Broadcast Receivers react to system events like the device finishing charging or connectivity changing. Content Providers expose a structured interface (similar to a database table) that other apps can query, such as the system Contacts provider.

Example: Tapping a "Share" button that opens an implicit Intent lets the user choose from any installed app (Messages, Email, social apps) capable of handling shared text.

val shareIntent = Intent(Intent.ACTION_SEND).apply {
    type = "text/plain"
    putExtra(Intent.EXTRA_TEXT, "Check out this app!")
}
startActivity(Intent.createChooser(shareIntent, "Share via"))

Real-World Example: A music streaming app uses a foreground Service so playback continues after the user switches to another app; a fitness app uses a Broadcast Receiver to detect when the phone has connected to a charger and trigger a background sync.

Why It Matters: These components let an app behave like part of the OS ecosystem rather than an isolated silo — sharing data, responding to system events, and doing background work without needing the user to keep the app open on screen.

Common Misunderstanding: Students often assume Services can run indefinitely in the background with no restriction. Since Android 8 (Oreo), the OS aggressively limits background execution to save battery, so long-running work generally needs to use WorkManager or a foreground Service with a persistent notification.

The Activity Lifecycle

Definition: A predictable sequence of callback methods (onCreate, onStart, onResume, onPause, onStop, onDestroy) that Android invokes as an Activity moves between visible, background, and destroyed states.

Explanation: Because a phone can interrupt an app at any moment (an incoming call, the user pressing "home," rotating the screen), Android needs a formal way to tell your code "you're about to lose focus" or "you're being recreated." onCreate() runs once when the Activity is first created — this is where you set up the UI. onPause()/onStop() run when the Activity is no longer in the foreground, a good place to save transient state. onDestroy() runs when the Activity is being removed from memory.

Example: Rotating the phone from portrait to landscape by default destroys and recreates the Activity — onSaveInstanceState() lets you preserve data (like text typed into a form) across that recreation.

Real-World Example: A video app should pause playback in onPause() when the user switches to another app, and release camera or microphone resources in onStop()/onDestroy() to avoid draining the battery or blocking other apps from using the hardware.

Why It Matters: Ignoring the lifecycle is one of the most common sources of Android bugs and crashes — memory leaks (holding a reference to a destroyed Activity), lost user input, or apps that keep using battery-draining resources after the user has left the screen.

Common Misunderstanding: Many beginners believe an app is "closed" the moment the user presses the home button. In reality, the Activity typically moves to a paused/stopped state but remains in memory, ready to be resumed instantly — it's only later, if the OS needs memory, that it may be fully destroyed.

Visual Learning

Key Terms

Term	Definition
Android Studio	Google's official IDE for Android development, built on IntelliJ IDEA.
Android SDK	The set of libraries, APIs, and tools used to build Android apps.
ART (Android Runtime)	The runtime environment that executes compiled Android app code on-device.
Activity	A class representing a single screen with a user interface.
Fragment	A reusable portion of a UI that lives within an Activity.
Intent	A messaging object used to request an action, such as starting an Activity.
Service	A component that runs operations in the background without a UI.
Gradle	The build system used to compile and package Android apps.
APK/AAB	The installable package formats for Android apps (Android Package / Android App Bundle).

Common Mistakes

Misconception 1: "Pressing the home button closes the app completely." Why it's wrong: The Activity typically moves into the background (paused/stopped) but stays in memory so it can resume instantly; it isn't destroyed unless the system reclaims memory. Correct understanding: Apps go through lifecycle states (paused, stopped) before actual destruction, and developers should release only the resources appropriate to each state.

Misconception 2: "Fragments are an optional, advanced feature only needed for tablets." Why it's wrong: Fragments are the standard way to structure UI and navigation in modern Android apps, phone or tablet, especially when using Jetpack's Navigation component. Correct understanding: Most production Android apps use Fragments (or Compose screens) as their default building block for individual UI sections, not just for large-screen layouts.

Misconception 3: "A background Service can run forever without restriction." Why it's wrong: Since Android 8 (Oreo), the OS imposes strict background execution limits to conserve battery, killing long-running background Services that aren't in the foreground. Correct understanding: Long-running background work should use WorkManager (for deferrable tasks) or a foreground Service with a visible notification (for tasks the user needs to know are active, like music playback).

Comparison and Connections

Aspect	Activity	Fragment	Service
Has its own UI	Yes	Yes (hosted inside an Activity)	No
Runs in background	No (has visible lifecycle)	No	Yes
Reusable across screens	Limited	Yes, designed for reuse	N/A
Typical use	One screen	Part of a screen	Background task (sync, playback)

Aspect	Kotlin	Java
Null safety	Built into the type system	Not built-in, relies on developer discipline
Verbosity	Concise (less boilerplate)	More verbose
Google's recommendation	Preferred since 2019	Still fully supported
Interoperability	Fully interoperable with Java	N/A

Practice Questions

Recall 1: What is the role of Gradle in Android development? Answer guidance: Gradle is the build system that compiles Kotlin/Java source code, manages dependencies, and packages the app into an APK or AAB file.

Recall 2: List the six primary Activity lifecycle callback methods in order. Answer guidance: onCreate(), onStart(), onResume(), onPause(), onStop(), onDestroy().

Understanding 1: Explain the difference between an explicit and an implicit Intent. Answer guidance: An explicit Intent specifies the exact component (e.g., a specific Activity class) to launch, typically within the same app. An implicit Intent describes an action to perform (e.g., "send text") and lets the OS find any installed app capable of handling it.

Understanding 2: Why does Android restrict background Services starting with Android 8 (Oreo)? Answer guidance: To conserve battery life and system resources, since unrestricted background execution across many apps was a major cause of poor battery performance.

Application 1: You're building a chat app and need messages to keep syncing even when the user has switched to another app. What Android component should you use, and why? Answer guidance: A foreground Service (or WorkManager for periodic sync) — it can continue running with a visible notification, satisfying Android's background execution limits while keeping messages up to date.

Application 2: A user rotates their phone while filling out a form, and the text they typed disappears. What Android concept explains this, and how would you fix it? Answer guidance: Rotating the screen by default destroys and recreates the Activity, resetting UI state. The fix is to preserve the input in onSaveInstanceState() and restore it in onCreate(), or use a ViewModel that survives configuration changes.

Analysis 1: Compare using multiple Activities versus a single Activity with multiple Fragments for a five-screen app. Which is generally preferred today and why? Answer guidance: A single Activity with multiple Fragments (managed by the Navigation component) is generally preferred — it simplifies shared state, animations between screens, and back-stack management, whereas multiple Activities duplicate lifecycle overhead and complicate data sharing.

Analysis 2: Evaluate the trade-off of writing an app in Kotlin versus Java for a new Android project in terms of safety and hiring. Answer guidance: Kotlin offers null safety and more concise syntax, reducing a class of runtime crashes and speeding up development, but a team with deep existing Java expertise or legacy Java code might weigh migration cost against these safety benefits; most new projects favor Kotlin given Google's official recommendation.

FAQ

Do I need to know Java before learning Kotlin for Android? No. Kotlin is a standalone, beginner-friendly language, and Google's official documentation and courses teach Android with Kotlin directly. Learning Java afterward is easy if you ever need to read older codebases.

What's the difference between an APK and an AAB? An APK is a complete, installable Android package. An AAB (Android App Bundle) is the format Google Play now requires for publishing — Google Play uses it to generate optimized APKs for each device configuration, reducing download size for users.

Can I test Android apps without an Android phone? Yes. Android Studio includes an emulator that simulates a wide range of virtual devices and OS versions, which is often used for the bulk of development and testing.

Why does my app behave differently on different Android versions? Because manufacturers and Google release new Android versions with new APIs, permission models, and behavior changes; apps must handle these differences (often using if (Build.VERSION.SDK_INT >= ...) checks) to work consistently across the OS versions still in active use.

What is Jetpack Compose, and do I still need to learn Views/Layouts? Jetpack Compose is Android's modern, code-first UI toolkit that replaces XML layouts with declarative Kotlin functions. It's increasingly the recommended approach for new apps, but understanding Views, Layouts, and the Activity lifecycle is still foundational, since Compose builds on the same underlying Android framework concepts.

Quick Revision

• Android is Google's open-source mobile OS, powering around 70% of smartphones worldwide.
• Kotlin is Google's preferred language since 2019; Java remains fully supported.
• Android Studio (built on IntelliJ IDEA) is the official IDE; Gradle is the build system.
• ART (Android Runtime) executes compiled app bytecode on-device.
• Core building blocks: Activity (screen), Fragment (reusable UI piece), View (widget), Layout (arrangement of views).
• Intents request actions — explicit (specific component) or implicit (let the OS choose a handler app).
• Services run background work; since Android 8, background execution is tightly restricted.
• Broadcast Receivers listen for system-wide events; Content Providers share structured data between apps.
• The Activity lifecycle (onCreate→onStart→onResume→onPause→onStop→onDestroy) governs how apps respond to interruptions and screen rotations.
• Apps are packaged as APK (installable) or AAB (Play Store distribution format).

Related Topics

Prerequisites: Basics of Mobile Application Development, object-oriented programming fundamentals.

Related Topics: iOS Development (the Apple equivalent), Mobile App Security, Database Management Systems (for local storage with SQLite/Room).

Next Topics: iOS Development, Mobile App Security.