Finding your way around Android Studio

Android Studio has hundreds of buttons, and you will use about fifteen of them every day. This lesson names those fifteen, shows where each one is and what it is for, and leaves the rest for when you need them. The aim is that by module 2 you stop hunting for things and start reading code.

The window has three areas worth naming: the editor in the middle, tool windows docked around the edges (Project, Logcat, Build, Running Devices and others, each opened from a strip of icons or from View → Tool Windows), and the toolbar at the top with the device menu and the Run and Debug buttons.

The Project window: Android view and Project view

The Project window (Alt + 1 on Windows and Linux, Cmd + 1 on a Mac) shows your files, but by default it does not show them as they are on disk. At the top of the window is a menu with two views worth knowing.

Android view (the default) groups files by what they are for:

app
├── manifests
│   └── AndroidManifest.xml
├── java
│   └── com.riztechacademy.mandibhav
│       └── MainActivity.kt
└── res
    ├── drawable
    ├── mipmap
    └── values
Gradle Scripts
├── build.gradle.kts (Project: ...)
├── build.gradle.kts (Module :app)
├── libs.versions.toml
└── ...

The exact group names vary a little between releases (the source group may read kotlin+java), but the shape is the same.

It hides build outputs, flattens long package paths and gathers every build file under Gradle Scripts, labelled with whether it belongs to the project or to the app module. That label matters: there are two files called build.gradle.kts, and editing the wrong one is a classic first-week mistake.

Project view shows the real folders on disk: app/src/main/java/com/riztechacademy/mandibhav/, app/build/, gradle/, .gitignore, local.properties. Switch to it when you need the truth: to find the APK the build produced (app/build/outputs/apk/debug/app-debug.apk), to see what is committed to git, or to understand why a file is not where the Android view suggested.

Work in the Android view; switch to the Project view when you need to know where something really is. Module 2's first lesson goes through every file in both.

Gradle sync

Android Studio does not read your build files directly. It asks Gradle, the build system, to read them and report back what the project contains: which libraries, which source folders, which SDK. That conversation is a sync, and the editor's understanding of your code comes from the last successful one.

Sync happens when you open a project, and Android Studio offers it with a Sync Now banner whenever you edit a build file. You can also run it yourself with the Sync Project with Gradle Files button in the toolbar, or by finding that action with Cmd/Ctrl + Shift + A. Progress and errors appear in the Build tool window.

The trap: you add a library to build.gradle.kts, ignore the banner, and start typing code that uses it. The import stays red, autocomplete offers nothing, and it looks as if the library does not exist. It exists; the editor has not been told. After any edit to a build file, sync before you judge anything the editor says.

Run, Debug and Apply Changes

The toolbar, left to right, has the things you press most:

• The run configuration (normally app) and the device menu, where you pick the emulator or phone. Wireless pairing lives in this menu too.
• Run: builds, installs and starts the app. If it is already running, it is restarted.
• Debug (the bug icon): the same, but with the debugger attached, so breakpoints stop the app.
• Apply Changes and Restart Activity and Apply Code Changes: push a small edit to the running app without reinstalling. They are faster, and they cannot handle every kind of change; when they refuse, they say so, and Run is the fallback.
• Stop: kills the app process.

To feel the debugger once: click in the gutter to the left of the Text( line in Greeting to set a red breakpoint, then press Debug. The app stops before drawing, the Debug window shows name = "Mandi Bhav", and the app resumes when you press Resume. Breakpoints, stepping and the layout inspector get a full lesson in the quality module.

Logcat

Every Android device keeps one shared log, and Logcat (Alt + 6 or Cmd + 6, or View → Tool Windows → Logcat) is the window that reads it. It is where crashes show their stack traces, and where your own Log messages appear.

The log is noisy because it holds everything: the system, Google Play services, every app. Here is a real fragment from launching Mandi Bhav and then rotating the emulator, with a temporary Log.d("MandiBhav", ...) line added at the top of onCreate, read with adb logcat and trimmed:

I/ActivityManager(  662): Start proc 13649:com.riztechacademy.mandibhav/u0a229 for next-top-activity {...}
D/MandiBhav(13649): onCreate, savedInstanceState = null
I/ActivityTaskManager(  662): Displayed com.riztechacademy.mandibhav/.MainActivity for user 0: +789ms
D/MandiBhav(13649): onCreate, savedInstanceState = Bundle[{android:viewHierarchyState=...}]

Read it line by line. The system started a process (number 13649) for the app. Your log line ran with nothing saved. The system reports the first frame after 789 ms, the same figure am start -W gives you. Then the screen rotated, and onCreate ran again, in the same process, this time with a saved Bundle. Rotating the phone destroyed your activity and built a new one. That one line is the reason the lifecycle and state modules exist; for now, notice it.

Each line has a level letter: Verbose, Debug, Info, Warn, Error and Assert (shown as fatal). Logcat in Android Studio filters with a query bar, which usually starts at package:mine, meaning your project's app only. The queries worth knowing:

Press Ctrl + Space in the query bar to see suggestions. If you delete the query and see the whole device's log scroll past, you now know why the filter exists.

Finding anything: Search Everywhere

Press Shift twice. Search Everywhere opens and searches files, classes, symbols, settings and actions at once. Type MainAct and MainActivity.kt is the first result. Type sdk manager and the SDK Manager is there too. When you cannot remember where a menu item lives, this is quicker than looking.

Its narrower sibling, Find Action (Cmd/Ctrl + Shift + A), searches only actions, and shows each action's keyboard shortcut next to it. It is the best way to learn shortcuts: find the action by name once, read the shortcut, use the shortcut next time.

The shortcuts worth learning

These are the default keymaps. On a Mac, Ctrl means the Control key and Cmd the Command key; they are different, and Android Studio uses both.

Do not try to learn the table in a day. Learn three this week: Search Everywhere, quick fix and Run. Add two more each week. Alt + Enter (Option + Enter) alone will save you hours: on any red or yellow underline it offers the fix, usually including the missing import.

If a shortcut does nothing, your keymap may differ (some Linux desktops and Mac system shortcuts steal keys). Find Action shows what is actually bound on your machine.

Check your work

Which Project window view shows the real folders on disk? The Project view. The Android view groups by purpose and hides build outputs.

Where is the APK after a debug build? app/build/outputs/apk/debug/app-debug.apk, visible in the Project view.

You added a library and its import is red. First thing to do? Sync the project with Gradle files.

What is the difference between Run and Apply Changes? Run builds, reinstalls and restarts; Apply Changes pushes a small edit into the running app, and refuses changes it cannot apply.

What does package:mine level:WARN show? Warnings, errors and asserts from your own app only.

What did the Logcat fragment show happening on rotation? onCreate ran again with a saved Bundle: the activity was destroyed and recreated.

In practice 6, why does material3 show no version? Its catalog entry has no version; the Compose BOM supplies it. With the BOM missing, nothing does.

How do you find a shortcut you do not know? Find Action (Cmd/Ctrl + Shift + A) shows it next to the action.

Practice

1. Switch the Project window between Android and Project views. In the Project view, find app-debug.apk and local.properties.
2. Open both build.gradle.kts files from Gradle Scripts and say which is the project's and which is the module's.
3. Use Search Everywhere to open libs.versions.toml, then the SDK Manager, without touching the mouse.
4. Set a breakpoint on the Text( line, run with Debug, and find name in the variables view. Resume, then remove the breakpoint.
5. Add Log.d("MandiBhav", "onCreate") as the first line after super.onCreate(savedInstanceState), using Alt + Enter to import android.util.Log. Run, filter Logcat with tag:MandiBhav, rotate the emulator and watch the line appear again. Then remove the line and the import so your project matches the course again.
6. Break it on purpose: in libs.versions.toml, change composeBom to "2026.99.00", sync and build. The error reads Could not find androidx.compose:compose-bom:2026.99.00, lists the two repositories Gradle searched, and then adds Could not find androidx.compose.material3:material3:. with nothing after the last colon. Work out why the second one has no version (hint: look at the material3 line in the catalog). Restore the original value and sync again.
7. Harder: for one full day of this course, use no mouse for navigation. Every time you reach for it, use Find Action to discover the shortcut instead, and write it down. At the end of the day, you have your personal shortcut list.

Official documentation

• Meet Android Studio — The official map of the window, tool windows and main features.
• Projects overview — The Android view and the Project view side by side, and what every folder is for.
• View logs with Logcat — The full query language, including regular expressions and saved filters.
• Keyboard shortcuts — The complete default keymap for Windows, Linux and Mac.

Next: module 2 opens with the anatomy of a project, every file the wizard created and why.

---

That is module 1. You can now:

• explain what Android development involves beyond drawing screens, and why the phones your users actually have shape every decision;
• install Android Studio and the SDK, name each SDK package, and fix a missing platform;
• create a Compose project, make it match a given starter, and choose minSdk knowing what it costs;
• run an app on an emulator, on your own phone over USB or Wi-Fi, and from the terminal with adb;
• move around Android Studio, read Logcat, and use the shortcuts that matter.

You have also seen, without yet understanding it, an activity being destroyed and recreated when the screen rotates. Module 2, How an Android App Is Put Together, starts there: the files a project is made of, Gradle and the version catalog (including what happens when compileSdk is too old), the manifest, activities and the lifecycle that catches everyone.