Android Studio Setup & First App

Android Development Fundamentals

Course 1 · Chapter 1 · Android Studio Setup & First App

📱 Android Studio Setup & First App

Both Kotlin courses covered the language; this course covers building actual Android apps with it. This chapter is pure tooling and orientation — installing Android Studio, touring the IDE, understanding what a generated project actually contains, and running a first app on an emulator. Nothing here is Kotlin-specific yet; it's the ground everything else in this course stands on.

⬇️ Installing Android Studio

Android Studio is Google's official IDE for Android development, built on JetBrains' IntelliJ IDEA — the same underlying IDE platform used for pure Kotlin/Java development, with an entire layer of Android-specific tooling added on top (layout editor, emulator management, APK analysis, and more).

Download from developer.android.com/studio — it bundles a compatible JDK, so a separate Java installation usually isn't required.
The installer offers a "Standard" setup type on first run — this downloads the Android SDK, a default emulator system image, and standard build tools. Accept the defaults unless there's a specific reason not to.
First launch takes a few minutes while the SDK and build tools finish downloading — this only happens once.

🆕 Creating Your First Project

From the Android Studio welcome screen, choose New Project, then pick a template. For this course, choose Empty Views Activity — not "Empty Activity," which defaults to Jetpack Compose (covered later, in Course 2). Starting with the traditional View/XML system first, before Compose, matches how this course builds up: Chapter 3 covers XML layouts directly.

Name & Package Name

The project name is just a label. The package name (e.g. com.philip.myfirstapp) is a reverse-domain identifier that must be globally unique if the app is ever published — it can't be easily changed later, so it's worth getting right from the start.

Minimum SDK

The oldest Android version the app will still run on, chosen from a dropdown showing the percentage of active devices each option covers. A higher minimum means fewer devices supported but access to newer APIs without extra compatibility checks.

🧭 A Tour of the IDE

Project View (left)

Browses the project's files — defaults to "Android" view, which groups files by purpose (manifests, java, res) rather than mirroring the raw folder structure exactly. Switch to "Project" view to see the real file layout on disk.

Editor (center)

Standard IntelliJ-style code editing — the same autocomplete, refactoring tools, and inspections as any JetBrains IDE, plus a live XML layout preview when editing a layout file.

Logcat (bottom)

The running app's log output in real time — every println-equivalent (Log.d(...), covered next chapter), crashes, and system messages, filterable by app process and log level.

Device Manager

Where virtual devices (emulators) are created and managed — covered in its own section below.

📂 What a Generated Project Actually Contains

MyFirstApp/
├── app/
│   ├── manifests/
│   │   └── AndroidManifest.xml   # app metadata: package, permissions, activities, launcher icon
│   ├── java/
│   │   └── com/philip/myfirstapp/
│   │       └── MainActivity.kt   # your first Kotlin file — the app's entry-point screen
│   ├── res/
│   │   ├── layout/
│   │   │   └── activity_main.xml # the XML that defines what MainActivity's screen looks like
│   │   ├── values/
│   │   │   ├── strings.xml       # text content, kept separate from layout/code
│   │   │   ├── colors.xml        # named color values
│   │   │   └── themes.xml        # app-wide styling
│   │   └── drawable/              # images and vector icons
│   └── build.gradle.kts          # APP-level build config — dependencies, SDK versions
└── build.gradle.kts              # PROJECT-level build config — shared across all modules
        

AndroidManifest.xml is worth singling out: it's the file the Android OS itself reads to know what your app is — which screens (Activitys) exist, which one launches first, what permissions it needs, what its icon and name are. Nothing runs on a real device or emulator without a correct manifest.

⚠ res/ Files Are Referenced by Name, Not Imported

A string in strings.xml named app_name is referenced from Kotlin as R.string.app_name and from XML as @string/app_name — R is an auto-generated class mapping every resource to a stable ID. This indirection (separate text/color/dimension files instead of hardcoded values in code) is deliberate: it's what makes translations, dark mode, and different screen sizes possible without touching application logic.

🐘 Gradle Basics

Gradle is Android's build system — it compiles Kotlin/Java code, packages resources, resolves dependencies, and produces the final installable app package (an APK or AAB). The two build.gradle.kts files serve different scopes:

// app/build.gradle.kts — this module's specific configuration
android {
    namespace = "com.philip.myfirstapp"
    compileSdk = 34

    defaultConfig {
        applicationId = "com.philip.myfirstapp"
        minSdk = 24
        targetSdk = 34
    }
}

dependencies {
    implementation("androidx.core:core-ktx:1.12.0")
    implementation("androidx.appcompat:appcompat:1.6.1")
}
        

Gradle vs npm — A Familiar Shape

	npm (package.json)	Gradle (build.gradle.kts)
Declares dependencies	"dependencies": { "express": "^4.18.0" }	implementation("androidx.core:core-ktx:1.12.0")
Install/sync command	npm install	"Sync Now" (automatic on file changes)
Where deps come from	npm registry	Maven repositories (Google's, Maven Central)
Build/run command	npm run build	Run ▶ in the IDE, or ./gradlew build

The dependency-declaration idea from Node.js Fundamentals (Course 1, Chapter 2) transfers directly — implementation(...) lines are Gradle's equivalent of entries in package.json's dependencies, just referencing Maven coordinates (group:artifact:version) instead of npm package names.

📲 The Emulator: Running Your First App

The Device Manager creates and manages Android Virtual Devices (AVDs) — emulated phones/tablets that run on the development machine:

Open Device Manager (usually a phone-shaped icon in the toolbar or right-hand panel).
Click Create Device, pick a phone definition (e.g. Pixel 7), and select a system image (an Android version) — Android Studio may need to download the image first.
Once created, click the green Run ▶ button with the new AVD selected as the target — Android Studio builds the app, boots the emulator (first boot takes a minute or two), installs the app, and launches it automatically.

The default Empty Views Activity template shows a single screen with "Hello World!" text — that text lives in activity_main.xml, not hardcoded in MainActivity.kt, following the resource-separation pattern from the warning box above.

💡 A Physical Device Works Too, and Is Often Faster

Enabling Developer Options and USB debugging on an Android phone, then connecting it by USB, lets it appear as a run target alongside emulators — often noticeably faster than emulation, and useful for testing on real hardware. Not required for this course, but worth knowing exists.

💻 Coding Challenges

Challenge 1: Create and Run a Project

Create a new project using the Empty Views Activity template, name it anything you like, set the minimum SDK to API 24, create an AVD, and run the app successfully — confirming "Hello World!" appears on the emulator screen.

Goal: Confirm the full toolchain (Android Studio → Gradle → emulator) works end to end.

→ Solution

Challenge 2: Edit a String Resource

Open res/values/strings.xml, find the string used by the "Hello World!" text (check activity_main.xml for the @string/... reference to identify its name), change its value, and re-run the app to confirm the new text appears — without touching MainActivity.kt or the layout XML at all.

Goal: Get comfortable with the res/ resource-reference pattern by using it, not just reading about it.

→ Solution

Challenge 3: Add a Dependency

Add the com.google.android.material:material dependency to app/build.gradle.kts (a specific, recent version), sync Gradle, and confirm the sync completes without errors. Add a short comment noting what "Sync Now" actually does, based on the Gradle vs npm comparison in this chapter.

Goal: Practice the dependency-declaration + sync workflow that every later chapter's new library will use.

→ Solution

💡 Slow Builds the First Time Are Normal

The very first Gradle sync and build on a new machine can take several minutes as it downloads dependencies and build tools — subsequent builds are dramatically faster thanks to caching. If a first sync seems stuck, it's very likely still downloading, not actually frozen.

🎯 What's Next

Next chapter: Activities & Lifecycle — the Activity class, lifecycle callbacks, savedInstanceState, and reading Logcat output.