Android Fundamentals with Java

Introduction to Android & the Stack

18 min Lesson 1 of 12

Introduction to Android & the Stack

Android is the world's most widely deployed operating system. It runs on phones, tablets, watches, televisions, cars, and embedded devices. As a Java developer you already understand object-oriented design, the JVM, and the standard library. This tutorial series builds directly on that foundation to teach you how to write real Android applications in Java — the language Android was designed around from day one.

Before writing a single line of code it is worth understanding what Android actually is, how its layers fit together, and what fundamentally distinguishes it from a desktop Java program. That understanding is what separates a developer who copies boilerplate from one who knows why the boilerplate exists.

The Android Software Stack

Android is a layered platform. Each layer builds on the one below it, and as an application developer you primarily work in the topmost layer — but the layers underneath shape everything from performance to battery life to security.

Linux Kernel — The foundation. Manages hardware drivers, memory, process scheduling, power management, and networking. You never call the kernel directly; it works silently behind every API call.
Hardware Abstraction Layer (HAL) — A set of standard interfaces that isolate the kernel drivers from the higher layers. Device manufacturers implement these interfaces so that a camera, GPS sensor, or fingerprint reader looks the same to Android regardless of the underlying chip.
Android Runtime (ART) — The virtual machine that runs your application. ART compiles your Java (or Kotlin) bytecode to native machine code using Ahead-Of-Time (AOT) compilation during app installation, so your code runs at near-native speed on the device. This replaced the older Dalvik runtime in Android 5.0.
Native C/C++ Libraries — Core platform capabilities such as the OpenGL ES graphics pipeline, SQLite, WebKit, and the media framework. You access these indirectly through higher-level Java APIs, though the Android NDK lets you call them directly for performance-critical code.
Java API Framework — The layer you spend most of your time in. It exposes the entire platform through well-structured Java packages: android.app, android.view, android.content, android.os, and many more. Every Activity, Service, notification, sensor, and network call is reached through this layer.
System Apps & Your App — The topmost layer. The pre-installed dialer, contacts, camera, and settings apps live here — and so does every app you install, including yours. They are all equal citizens running in the same framework.

ART vs the desktop JVM: On a standard JVM (HotSpot), bytecode is interpreted and then JIT-compiled at runtime. On Android, ART performs AOT compilation at install time, producing native code that starts fast and runs efficiently on constrained hardware. The tradeoff is slightly longer install times and larger on-disk footprint — acceptable in exchange for smooth, battery-friendly execution.

How Android Applications Are Structured

An Android application is not a single executable. It is a package — an .apk (Android Package) or .aab (Android App Bundle) file — that contains compiled bytecode, resources (layouts, strings, images), assets, and a manifest file that describes the package to the operating system.

Inside the running application, the platform organizes code around four fundamental building blocks:

Activity — A single screen with a user interface. Every screen the user sees corresponds to an Activity subclass. The platform creates and destroys Activity instances according to a well-defined lifecycle you will learn in depth in a later lesson.
Service — A component that performs long-running work in the background without a UI. Examples: playing music, syncing data, handling network requests. Services run on the main thread by default and must offload blocking work to background threads.
BroadcastReceiver — A listener for system-wide or application-specific events. The system broadcasts events such as "battery low", "network connected", or "boot completed"; your receiver reacts to them. Receivers have no UI and are expected to complete quickly.
ContentProvider — A structured interface for sharing data between applications. The Contacts and MediaStore databases are exposed as ContentProviders, allowing your app to query them through a URI-based API without knowing their internal storage format.

Most apps you write early on will consist almost entirely of Activities, with Services and BroadcastReceivers appearing as the application grows in complexity.

The Role of the AndroidManifest

Every component — every Activity, Service, BroadcastReceiver, and ContentProvider — must be declared in AndroidManifest.xml before Android will run it. The manifest also declares the permissions the app requires, the minimum and target API levels, hardware features it depends on, and the entry-point Activity that the launcher icon opens. You will study the manifest in detail in Lesson 6; for now, remember that Android will silently refuse to start any component not registered there.

Common early mistake: Creating a new Activity class but forgetting to add it to AndroidManifest.xml. The app will compile cleanly, but attempting to navigate to that screen at runtime throws an ActivityNotFoundException. Android Studio can add the entry automatically when you use the "New Activity" wizard — use it to avoid this.

Sandboxing and Security

Android enforces strict isolation between applications at the operating system level. Each app runs in its own Linux process with a unique user ID (UID). The filesystem directories belonging to one app are inaccessible to another. Even the system cannot read your app's private files without declaring a ContentProvider.

Permissions are the formal mechanism for crossing sandbox boundaries. An app that needs to read the user's contacts must declare uses-permission android:name="android.permission.READ_CONTACTS" in its manifest. On Android 6.0 (API 23) and later, sensitive permissions must also be requested at runtime — the user sees a dialog and can grant or deny each one individually.

Request only what you need. Google Play reviewers and users both scrutinize permission lists. An app that requests camera access but never uses it erodes trust and can get flagged during review. Declare the minimum set of permissions required for the features you actually implement.

API Levels and Versioning

Android versions are identified by two things: a name (e.g. Android 14) and an integer API level (e.g. API 34). API levels are what you work with in code. In your build.gradle you set:

minSdk — The oldest Android version your app supports. Users on older devices cannot install it.
targetSdk — The API level your app is designed and tested against. The system applies backward-compatibility behaviors for any API level above your target.
compileSdk — The version of the Android SDK used to compile your code. Set this to the latest stable API level.

// build.gradle (Module: app)
android {
    compileSdk 34

    defaultConfig {
        applicationId "com.example.myapp"
        minSdk 26         // Android 8.0 — covers >97% of active devices
        targetSdk 34      // Android 14 — opt in to latest behaviors
        versionCode 1
        versionName "1.0"
    }
}

When you call an API introduced in a later level than your minSdk, the compiler emits a lint warning. You must guard that call with a version check:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
    // Code that uses API 26+ features safely
    NotificationChannel channel = new NotificationChannel(
        "updates", "Updates", NotificationManager.IMPORTANCE_DEFAULT);
}

What Makes Android Different from Desktop Java

If you have written Swing or JavaFX applications you are used to a main() method being your entry point and the process living as long as your window is open. Android works differently in several key ways:

No main() method. The Android framework calls lifecycle methods on your components. You respond to callbacks like onCreate(), onStart(), onResume() — you never write a loop that keeps the process alive.
The system owns the process. Android can kill your app's process at any time to reclaim memory — especially when the app is in the background. You must save state before you are killed and restore it when you come back.
One thread for the UI. All UI updates must happen on the main thread (also called the UI thread). Any blocking operation — network calls, file I/O, database queries — must be done on a background thread. Blocking the main thread for more than ~5 seconds triggers an ANR (Application Not Responding) dialog.
Resource-constrained environment. Even modern phones have far less RAM and CPU headroom than a desktop. Memory leaks, unnecessary allocations, and expensive operations on the main thread have immediate, user-visible consequences.

The callback model is the heart of Android development. Instead of controlling the flow of your program top-to-bottom, you implement callbacks that the framework invokes at the right moments. Embracing this event-driven model — rather than fighting it — is the most important mindset shift for a Java developer new to Android.

Summary

Android is a layered platform built on a Linux kernel, with ART executing your Java code as compiled native machine code. Applications are packages composed of four component types — Activity, Service, BroadcastReceiver, and ContentProvider — each declared in AndroidManifest.xml. The platform enforces process-level sandboxing, a permission system, and a strict rule that UI work must stay on the main thread. These constraints exist to keep apps responsive, secure, and power-efficient on the hardware people actually carry. In the next lesson you will install Android Studio, create your first project, and see this structure in a real file tree.