Skip to content

Android Development Tutorial: A Working Introduction

Understand Android development from the kernel up. OS architecture, ART runtime, SDK and NDK, AVD emulator, project layout, plus Kotlin vs Java choice.

· · 8 min read
Android phone displaying app icons next to a laptop running Android Studio with a project tree

Quick Take

Android is a Linux-based OS that runs on roughly 3 billion active devices. To build apps for it, you need a working mental model of how the platform layers fit together, what Android Studio actually gives you, and which language to pick in 2026.

Quick take: Android is a Linux-kernel-based OS that runs on around 3 billion active devices worldwide as of 2024. Apps are built with the Android SDK in Kotlin (preferred) or Java, compiled to DEX bytecode, and executed by the Android Runtime (ART). The NDK is the optional escape hatch for native C/C++ code. Android Studio is the official IDE and bundles the SDK, build tools, and emulator, so you can go from install to a working mobile app in one sitting.

Android passed 3 billion active devices in 2021 according to Google's I/O keynote, and the number has only grown since. For a developer in 2026, that's a market reach Windows used to have in the desktop era. The platform itself, though, is layered, and trying to write apps without knowing what sits below your code makes everything harder. So let's walk through the stack from the bottom up, then look at what the SDK gives you, and end on the practical project layout you'll see in every new Android Studio project.

I've been writing Android apps on and off since the Eclipse-and-ADT days, and the single biggest jump in developer experience came when Android Studio shipped in 2014. The second biggest was Kotlin becoming first-class in 2017. Both matter for what follows.

What Is the Android OS Architecture?

Android has four big layers, from bottom to top: the Linux kernel, the native libraries plus the Android Runtime, the Java/Kotlin application framework, and finally your apps. Each layer talks only to the one directly above and below it, which keeps the platform manageable across thousands of device models.

The Linux Kernel

At the bottom sits a modified Linux kernel. It handles the same things a Linux kernel does anywhere: process scheduling, memory management, driver interfaces for Wi-Fi, Bluetooth, audio, the camera, and the display. The Android Common Kernel (ACK) is what device manufacturers branch from. The kernel version varies, a Samsung Galaxy S24 typically ships with a kernel in the 6.x series, while a low-end device might still run a 5.x branch.

You almost never write kernel code as an app developer. But the kernel's existence explains why Android can run on hardware ranging from $80 phones to $1,500 flagships, the same kernel architecture handles both.

HAL, Native Libraries, and ART

Above the kernel is the Hardware Abstraction Layer (HAL), a set of standard interfaces device makers implement so that the upper layers don't care about hardware specifics. Sitting next to HAL are native libraries written in C and C++, SQLite for databases, OpenGL for graphics, Skia for 2D, libc for the C standard library.

The Android Runtime (ART) lives at this level too. ART executes the DEX bytecode your Kotlin or Java code compiles to. It performs ahead-of-time (AOT) compilation at install time, which means most of the slow compilation happens once, not every time the app launches. ART replaced the older Dalvik VM in Android 5.0 (Lollipop), and that switch alone made app startup noticeably faster on every device.

Why does this matter for you as a developer? Because your code is ultimately running on top of ART, not directly on the kernel. The implication: anything that's expensive at startup is paid every install, not every launch, which means you can ship code that does more upfront.

The Application Framework

Above ART sits the framework: Activity Manager, Window Manager, Content Providers, View System, Notification Manager, Package Manager. These are the Kotlin/Java APIs you actually call. When you write startActivity(intent), you're calling into Activity Manager. When you findViewById, you're using the View System.

The framework is what most "Android development" actually means. Get comfortable with its core components (Activities, Services, Broadcast Receivers, Content Providers) and the rest of the platform falls into place.

Apps

The top layer is your app, plus the apps that come pre-installed (Phone, Contacts, Settings). All of them, including the system ones, use the same framework APIs. There's nothing magic about Google's apps, they call the same Activity Manager you do.

The green Android robot mascot standing beside a smartphone against a dark background
Photo by Denny Muller on Unsplash

What Are the Android SDK and NDK?

The SDK is the regular toolkit: framework APIs, build tools, platform versions, sample code, the emulator. You install it through Android Studio's SDK Manager, and it gets you everything needed to ship a normal app written in Kotlin or Java.

The NDK is the optional native development kit. You reach for it when you need C or C++ code, usually because you have an existing native library you want to reuse, or because a hot path in audio, video, or game code needs more performance than the JVM gives you. The Android Developers docs say plainly: "Most apps don't need the NDK." That's my experience too. I've shipped maybe two NDK-based features in ten years of Android work, both for audio DSP.

A quick comparison:

SDKNDK
LanguagesKotlin, JavaC, C++
Use caseApp logic, UI, data, networkingNative libs, performance hot paths
Build systemGradle (Kotlin DSL)CMake or ndk-build
DebuggingAndroid Studio debuggerLLDB via Android Studio
Typical app needs it?AlwaysRarely

What Is the Android Emulator and AVD?

The Android Virtual Device (AVD) is a configurable emulator that runs a real Android system image inside a VM on your laptop. You create an AVD in Android Studio's Device Manager: pick a device profile (Pixel 7, Pixel Tablet, a generic phone), pick a system image (API 34 with Google Play services is a sensible default in 2026), and Android Studio downloads roughly 1 GB of system image plus another 500 MB of supporting files.

The emulator runs fast on modern Apple Silicon and on x86_64 PCs with hardware acceleration enabled. On an M2 MacBook Pro, I see cold boot times around 18 seconds. On a Windows machine, you'll want HAXM or WHPX enabled in BIOS, otherwise expect 60-second boots and sluggish UI.

Things the emulator doesn't honestly simulate: real Bluetooth pairing, NFC, accurate battery behaviour, thermal throttling under load, and the quirks of vendor-specific Android skins (One UI on Samsung, MIUI on Xiaomi). For those, you need a physical device.

An Android phone home screen showing a grid of colorful app icons
Photo by Rami Al-zayat on Unsplash

What Does an Android Project Look Like?

When Android Studio creates a new project, you get a structure like this:

MyApp/
  build.gradle.kts          # top-level build config
  settings.gradle.kts
  gradle.properties
  app/
    build.gradle.kts        # module-level build config
    src/
      main/
        AndroidManifest.xml
        java/
          com/example/myapp/
            MainActivity.kt
        res/
          layout/
            activity_main.xml
          values/
            strings.xml
            colors.xml
            themes.xml
          drawable/
          mipmap/           # launcher icons at various densities

Three folders matter most: java/ (Kotlin code lives here despite the name), res/ (resources, layouts, strings, drawables), and the AndroidManifest.xml file at the root of main/.

The Manifest

AndroidManifest.xml is the file Android reads when installing your app. It declares which activities exist, which services run in the background, what permissions you need, and which intent filters route system events to your app. Example:

<manifest xmlns:android="http://schemas.android.com/apk/res/android">
    <uses-permission android:name="android.permission.INTERNET" />

    <application
        android:label="@string/app_name"
        android:icon="@mipmap/ic_launcher"
        android:theme="@style/Theme.MyApp">
        <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>

That <intent-filter> with MAIN and LAUNCHER is what makes the activity show up as an app icon on the launcher. Forget it and your app installs but nobody can launch it.

Gradle Build Files

The two build.gradle.kts files configure how your app is compiled. The top-level one defines plugin versions and shared settings. The module-level one (app/build.gradle.kts) sets the application ID, minimum and target SDK, dependencies, and signing configs. Gradle wraps the Android Gradle Plugin (AGP), which itself wraps the Android build tools.

In 2026, you should be using the Kotlin DSL (.kts files) for new projects. The Groovy DSL (.gradle without .kts) still works for legacy projects but the official docs lead with Kotlin DSL examples now.

Kotlin or Java in 2026?

Pick Kotlin. Google's been clear about this since 2019 when Kotlin became the preferred language, and the gap has only widened. The official Codelabs use Kotlin. Jetpack Compose is Kotlin-only. The Now in Android sample app is Kotlin. Most third-party libraries ship Kotlin-first APIs and treat Java as a compatibility surface.

That said, Java still works. If your team only knows Java, you can absolutely ship a 2026 Android app in Java without trouble. You'll just write more code per feature, miss out on data classes, coroutines, and null-safety, and find yourself reading Kotlin samples and translating them mentally. My recommendation: learn enough Kotlin to read it, and write new code in Kotlin from day one. The companion Kotlin introduction linked below covers the language basics in more depth.

What Should You Build First?

Skip the abstract architecture lectures. The fastest way to learn Android is to build a Hello World, then add a button, then read user input, then display an image. Each step introduces one new platform concept without burying you under abstraction. The four follow-up posts below take exactly that path, in order. Start with the button tutorial after this one and work down the list.

Frequently Asked Questions

What's the difference between Android SDK and NDK?
The SDK is for normal app development in Kotlin or Java, it covers the Android framework APIs. The NDK is for native code in C or C++, used when you need to call existing C libraries or get the last drop of performance out of audio, video, or game code. Most apps need only the SDK.
Is Android based on Linux?
Yes. Android sits on top of a modified Linux kernel. The kernel handles drivers, power management, and process scheduling, while everything above it (the runtime, libraries, framework, and apps) is the part Google maintains as Android proper. The kernel version varies by device manufacturer.
What is ART in Android?
ART is the Android Runtime that executes your app's compiled code. It replaced Dalvik in Android 5.0 (Lollipop, 2014). ART uses ahead-of-time compilation at install time, which makes apps start faster and use less battery than Dalvik's JIT approach. You write Kotlin or Java, ART runs the resulting DEX bytecode.
Do I need a physical device or is the emulator enough?
The emulator is fine for most UI work, but you'll want a physical device for camera, sensors, push notifications, and performance testing. I keep a cheap mid-range Pixel around for QA, the emulator can't honestly reproduce thermal throttling, real Bluetooth pairing, or NFC behaviour.
What is AndroidManifest.xml for?
The manifest declares your app to the system: activities, services, permissions, intent filters, the minimum and target SDK, and the application icon. Android reads it when installing the app and again whenever the launcher needs to know what your app does. Get it wrong and your app either won't install or won't appear in the launcher.