Setting up Android Studio: practical tips and trade-offs

Setting up Android Studio: practical tips and trade-offs

You've decided to build Android apps with Kotlin. Before you write a single line of code, you need to set up your development environment properly—and there are real decisions to make about what tools, templates, and hardware you'll use. Getting this wrong wastes weeks; getting it right means you can focus on learning the language and framework instead of fighting configuration issues.

This guide walks you through installing Android Studio, creating your first project, and running it on both emulators and physical devices. We'll cover the practical trade-offs at each step, so you know why we're making each choice rather than just blindly following a checklist.

Install Android Studio — It includes the SDK, emulator and build tools

Android Studio is the official IDE for Android development. It bundles the Android SDK (Software Development Kit), the emulator, Gradle build system, and debugging tools into one package. You could theoretically use a text editor and command-line tools, but that's like choosing to cut wood with a rock instead of a saw.

Download Android Studio from developer.android.com. The installer is about 1 GB on first run, but it's the base. The full SDK and emulator images will add several more gigabytes once you initialize them.

System requirements matter here:

• RAM: 8 GB minimum, 16 GB recommended. Android Studio and the emulator both consume memory. If you're also running Slack, a browser, and Docker, you'll feel it on 8 GB.
• Disk space: 10 GB for the IDE and tools, plus another 5–10 GB per emulator image. SSDs are not optional; they're table stakes.
• CPU: Modern multi-core processors (2016 or newer). If your machine is older, the emulator will be painfully slow, and you'll want to test on a physical device instead.

Trade-off: local emulator vs. cloud emulator

Running an emulator locally on your machine lets you iterate quickly and debug without network latency. But it's resource-heavy. Some teams use Firebase Test Lab or cloud-based Android emulators (AWS Device Farm, Google Cloud Test Lab) to offload that cost. For learning and development, local emulation is the right choice. Reserve cloud emulators for CI/CD pipelines and integration tests.

Once the installer finishes, open Android Studio. It will prompt you to download additional components: the SDK Platform for the latest Android version, the emulator, and system images. Accept the defaults. This takes 5–15 minutes depending on your internet speed.

Create a project — Pick the Empty Activity template with Compose

Android Studio offers several project templates: Empty Activity, Navigation Drawer Activity, Bottom Navigation Activity, and others. Each one gives you scaffolding code to build on.

For your first project, choose Empty Activity with Compose. Here's why:

• Jetpack Compose is the modern declarative UI toolkit for Android. It's the direction Google is pushing, and it's genuinely easier to learn than the older XML-based layouts. If you learn the old way first, you'll have to unlearn it later.
• Empty Activity gives you just enough structure to understand what's happening. You're not buried in boilerplate or navigation scaffolding you don't need yet.
• No unnecessary dependencies. Some templates pull in libraries (like Navigation or Room) that you don't need on day 2. Complexity is the enemy of learning.

When you create the project, you'll choose:

• Name: Something simple like FirstApp. Avoid spaces.
• Package name: Defaults to com.example.firstapp. You can change this, but com.example is fine for learning.
• Save location: Pick somewhere you'll remember. Avoid paths with spaces or special characters.
• Language: Kotlin (not Java).
• Minimum API level: Start with API 26 or 27. This is Android 8.0 or 8.1, released in 2017. Setting it too low pulls in more compatibility code; too high cuts out older devices. API 26 is a practical middle ground.

After clicking Finish, Android Studio generates the project structure and syncs Gradle. This can take 2–5 minutes the first time as it downloads dependencies. You'll see a progress bar at the bottom of the window.

Once it's done, open MainActivity.kt in the app/src/main/kotlin folder. You'll see something like this:

package com.example.firstapp

import android.os.Bundle
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import androidx.compose.foundation.layout.fillMaxSize
import androidx.compose.material3.MaterialTheme
import androidx.compose.material3.Surface
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.tooling.preview.Preview

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            FirstAppTheme {
                Surface(modifier = Modifier.fillMaxSize(), color = MaterialTheme.colorScheme.background) {
                    Greeting("Android")
                }
            }
        }
    }
}

@Composable
fun Greeting(name: String, modifier: Modifier = Modifier) {
    Text(
        text = "Hello $name!",
        modifier = modifier
    )
}

@Preview(showBackground = true)
@Composable
fun GreetingPreview() {
    FirstAppTheme {
        Greeting("Android")
    }
}

This is your starting point. The template includes:

• MainActivity: The entry point of your app. The onCreate function runs when the app starts.
• Greeting(): A Composable function—a reusable piece of UI. Compose breaks the screen into composables instead of XML layouts.
• GreetingPreview(): A preview function that lets you see your UI in the editor without running the app. This is a huge productivity win.

Trade-off: Compose vs. XML layouts

Some teams still use XML layouts (the older approach). They're more mature in some respects, but Compose is simpler to learn, has better type safety, and requires less boilerplate. For new projects, Compose is the right choice.

Run on an emulator — Create a virtual device in Device Manager

The emulator simulates an Android device on your computer. It's slow compared to a physical phone, but it's free, you can run multiple versions of Android simultaneously, and you can test scenarios (like low battery or airplane mode) easily.

Open the Device Manager in Android Studio: go to Tools → Device Manager (or click the Device Manager icon in the toolbar).

Click Create Device. You'll choose:

• Device type: Pick a phone like Pixel 6. The exact model doesn't matter much for learning; they're all roughly the same.
• OS version (API level): Choose API 34 (Android 14) or the latest available. This matches your target SDK.
• System image architecture: If your computer has an ARM-based processor (Mac with M1/M2/M3 or Windows on ARM), choose ARM64. Otherwise, x86_64 is fine. ARM64 emulation is faster on ARM hosts, x86_64 is faster on Intel/AMD.

After you click Finish, Device Manager downloads the system image (1–2 GB) and creates the virtual device. This takes 5–10 minutes.

Once it's ready, click the green play icon to launch the emulator. The emulator boots like a real Android phone—it takes 30 seconds to 2 minutes depending on your machine. You'll see the Android lock screen, then the home screen.

Back in Android Studio, open your project. Click the green run button (or press Ctrl+R on Linux/Windows, Cmd+R on Mac). Android Studio will build your app and install it on the running emulator. You'll see "Hello Android!" on the screen.

Trade-off: emulator speed vs. accuracy

The emulator can run in snapshot mode (fast boots, state saved) or full mode (slower boots, more accurate simulation). For development, use snapshot mode. For testing, use full mode to catch initialization bugs.

Common emulator issues:

• Emulator won't start: Check that virtualization is enabled in your BIOS. On Windows, make sure Hyper-V or Windows Sandbox isn't conflicting with KVM.
• Emulator is slow: Assign more CPU cores and RAM in the virtual device settings. Start with 4 cores and 4 GB RAM.
• Build fails with "Gradle sync failed": Click File → Sync Now, or click the Sync Now prompt at the top of the editor. This re-downloads dependencies.

Run on a phone — Enable developer options and USB debugging

Running on a physical device is faster than the emulator and lets you test real user experience: touch response, battery drain, network conditions, and sensors.

Step 1: Enable Developer Options on your phone

Go to Settings → About Phone. Find the "Build Number" field. Tap it 7 times rapidly. You'll see a toast message: "You are now a developer." Developer Options will appear in Settings.

Step 2: Enable USB Debugging

Go to Settings → Developer Options (or Settings → System → Developer Options). Toggle on "USB Debugging." You'll see a warning about security; accept it.

Step 3: Connect via USB

Plug your phone into your computer with a USB cable. Your phone will prompt you to allow USB debugging from this computer. Tap "Always allow from this computer" to avoid being prompted every time.

Step 4: Run your app

In Android Studio, click the run button. Instead of launching the emulator, it will detect your phone and install the app there. The first build and install takes 20–30 seconds; subsequent builds are faster if you're iterating on the same device.

Trade-off: USB cable vs. wireless debugging

USB cables are reliable but inconvenient if you're testing across the room. Android 11+ supports wireless ADB (Android Debug Bridge). You can enable it in Developer Options, then connect via Wi-Fi. It's slower than USB and sometimes drops connection, so use USB when you're actively developing and wireless for ad-hoc testing.

Multi-device testing strategy:

As you get more serious, you'll want to test on multiple devices: different screen sizes, OS versions, and manufacturer customizations (Samsung has One UI, Google has Stock Android). For now, pick one device to develop on and one emulator to test on. That's enough.

Common mistakes

• Installing the wrong Android SDK version: Match your Target SDK in Gradle to the SDK Platform you download. If they mismatch, your build fails or behaves unexpectedly.
• Not running "Sync Now" after changing Gradle dependencies: Android Studio sometimes doesn't auto-sync. If Gradle changes don't take effect, manually trigger a sync.
• Using old emulator images: Old system images (pre-API 26) are slow and receive no updates. Start with API 34 or later, then test on older APIs if you need to support them.
• Running the app before a successful build: If you hit run and Gradle is still downloading dependencies, the build might fail mysteriously. Wait for the progress bar to finish before trying again.
• Not checking USB cable integrity: A bad cable is the #1 reason wireless device connection fails. Try a different cable or port if your phone isn't recognized.

Key takeaways

• Android Studio bundles everything you need; download it once and let it manage updates to the SDK and emulator.
• Choose the Empty Activity with Compose template for new projects. Compose is the modern declarative UI toolkit and is easier to learn than XML layouts.
• Start with a local emulator for development speed. Create a virtual device matching your target API level (API 26+), and use snapshots to speed up boot times.
• Test on a physical device early. Enable USB Debugging, connect via USB, and run your app directly. It's faster and more realistic than the emulator alone.
• Allocate enough resources to the emulator (4+ cores, 4+ GB RAM) and your development machine (16 GB RAM, SSD). A slow setup kills productivity.
• Keep dependencies and system images up to date, but don't chase the latest API level blindly. API 26–28 is a stable baseline for learning.