Android Studio Power Tools

Two developers can write the same app. One of them finds a bug in five minutes; the other spends a whole afternoon adding println statements. The difference is rarely talent. It is knowing the tools that Android Studio gives you for free: Logcat for messages, the Layout Inspector for the live UI tree, the Database Inspector for your Room tables, the Background Task Inspector for WorkManager, the Profiler for CPU, memory and network, and the Compose tooling for previews and live editing.

This lesson covers the Database Inspector and Background Task Inspector items from Unit 6 and Unit 7 of the Android Basics with Compose programme, the Accelerate with tooling item, and the Compose Preview and Layout Inspector tooling items of Pathway 1 of Jetpack Compose for Android developers (https://developer.android.com/courses/pathways/jetpack-compose-for-android-developers-1).

By the end you will be able to:

• Read and filter Logcat effectively.
• Debug with breakpoints, the Debugger window and conditional breakpoints.
• Inspect a running app with App Inspection: Database Inspector, Background Task Inspector, Network Inspector and Layout Inspector.
• Use Compose Preview features: multipreview, interactive and animation preview, device configurations.
• Use Live Edit and Apply Changes to iterate fast.
• Find memory, CPU and battery problems with the Profiler.
• Use lint, code inspections and keyboard shortcuts to move faster.

Big idea: observe first, then fix. A bug you can see in a tool takes minutes. A bug you guess at takes hours.

A note on menus. Android Studio is updated several times a year and window names, menu paths and tool layout move around. This lesson names the tools and their purpose and gives the usual menu path. If a path differs on your version, use Help → Find Action (or press Ctrl+Shift+A, Cmd+Shift+A on macOS) and type the tool's name.

• Android Studio setup, emulator, running an app (lessons 1–5).
• Room and the database (lesson 34).
• WorkManager (lesson 36).
• Recomposition (lesson 37) and Compose layouts (lessons 38–39).
• Coroutines and logging with Log (lessons 23 and 28).

Most of these tools live in App Inspection (a tool window usually at the bottom of the IDE). To use it, run a debuggable build of your app on an emulator or device, and select the process from the dropdown.

Logcat shows system and app messages in real time. Open it with View → Tool Windows → Logcat or the Logcat icon on the bottom bar.

Writing good logs

import android.util.Log
private const val TAG = "OrderViewModel"
fun placeOrder(itemId: Int) {
 Log.d(TAG, "placeOrder: itemId=$itemId")
 try {
 // ...
 } catch (e: Exception) {
 Log.e(TAG, "placeOrder failed for itemId=$itemId", e) // pass the exception as the 3rd argument
 }
}

Never log secrets (passwords, tokens, personal data). Logs can be read by other tools on a rooted or debugging device, and by bug reports. In release builds, debug logs should be removed or disabled (R8 can strip them if configured, or use a logging library that is a no-op in release, lesson 49).

Filtering

The Logcat toolbar lets you:

• Pick the device and process (by default, your app only).
• Set the minimum level (for example Warn to reduce noise).
• Type a search query with filters such as tag:OrderViewModel, level:error, package:mine, message:failed. The query box supports - for "not" (for example -tag:Choreographer) and age:5m for "last five minutes". Check the Logcat help (the question mark in the filter field) for the syntax of your Studio version.
• Switch to compact/standard view, and fold repeated lines.
• Save filters you reuse.

Reading a crash

A crash prints a stack trace. Read it from the top:

FATAL EXCEPTION: main
Process: com.example.classregister, PID: 12345
java.lang.IllegalStateException: Required value was null.
    at com.example.classregister.DetailFragment.onViewCreated(DetailFragment.kt:42)
    at androidx.fragment.app.Fragment.performViewCreated(Fragment.java:3123)
    ...

1. The first line says what (IllegalStateException, with the message).
2. The first line that mentions your package says where (DetailFragment.kt:42). Studio makes it a clickable link.
3. Lines from androidx and android frameworks below it tell you how it got there, which can matter, but start with your code.

If the trace has Caused by: lines, scroll to the last Caused by:; it is the root cause.

Instead of printing values, pause the program and look.

1. Set a breakpoint: click in the gutter (left of the line numbers) next to a line. A red dot appears.
2. Run in debug mode: click the bug icon (Debug) instead of Run. (Alternatively, Attach Debugger to Android Process if the app is already running.)
3. When the line is reached, the app freezes and the Debug window shows the call stack (Frames) and Variables.

Controls (names are consistent between Studio versions; shortcuts are shown in the toolbar tooltips):

Advanced breakpoints

• Conditional breakpoint: right-click the red dot and add a condition (for example student.id == 7), so you stop only for the item you care about instead of 200 times in a loop.
• Log message breakpoint: choose "Evaluate and log" instead of suspending, so you get a println without editing code.
• Exception breakpoint: in the Breakpoints dialog, break whenever a certain exception type is thrown.
• Watches: add an expression to the Watches pane to follow it across steps.

Debugging Compose and coroutines

Breakpoints work inside composables, but a composable can run many times (recomposition), so use a conditional breakpoint. In coroutines, the Debug window shows a Coroutines tab (when the coroutine debugger is available) listing active coroutines and their stacks. Stepping across a suspend call may land on a different thread; this is normal.

Open View → Tool Windows → App Inspection. Run your app (debug build) on a device or emulator. Choose the device and process. Tabs along the top include Network Inspector, Database Inspector and Background Task Inspector. Some Studio versions list the Layout Inspector in the same area; others use a separate window.

Database Inspector

You wrote a Room database in lesson 34. Instead of printing every row to Logcat, look at the tables.

1. Run the Inventory or Class Register app (anything with Room) in debug mode.
2. App Inspection → Database Inspector.
3. In the left pane, expand the database file; double-click a table to see all rows in a grid.
4. Live updates: tick Live updates and see rows change as you use the app.
5. Run a query: open the Query tab, write a SELECT * FROM student WHERE present = 1, run it, and use the results. You can edit cell values directly (for tables, not views) to test how your UI reacts to different data without changing code.
6. Export: right-click a table to export as CSV, or export the database file, which you can open in a desktop SQLite browser.

What it is good for:

• Confirm that an @Insert really saved the row.
• Check foreign keys and defaults (NULL where you expected a value).
• Test your migrations: install version 1, insert rows, run version 2 and compare.
• Run the exact SQL your DAO uses (copy it out of the @Query string).

If the inspector says it cannot see the database, check that you are running a debuggable build, that the process is selected, and that the app has actually opened the database (it is created lazily on first access). In-memory databases (Room.inMemoryDatabaseBuilder) are not inspectable on disk, although the inspector can work with them in some versions.

Background Task Inspector

Lesson 36 taught WorkManager. The Background Task Inspector shows workers, jobs, alarms and wake locks your app has scheduled.

1. Run an app that enqueues work (for example the Blur-O-Matic style app from lesson 36).
2. App Inspection → Background Task Inspector.
3. In the table view you see each Worker with its status: Enqueued, Running, Succeeded, Failed, Cancelled, Blocked. Click one to see its Description (class, tags, constraints, input and output data), Results, and WorkContinuation (the chain of dependent work).
4. The graph view shows chains: A runs, then B, then C. If A fails, B and C never run and appear as Blocked or Cancelled.
5. The timeline shows each task over time, together with alarms and wake locks.
6. A Cancel button lets you stop a worker manually.

This answers questions that are otherwise very hard: Why did my sync never run? (look for Blocked by a constraint such as unmetered network), Why did my chain stop? (a failed parent), How many retries happened? (the attempt count in the description).

Network Inspector

When your Retrofit code (lesson 29) misbehaves, open the Network Inspector. It lists each request with URL, method, status, size and time, and the Connection View shows request and response headers and bodies (JSON is pretty-printed). Use it to catch a wrong URL, a 404, an unexpected response shape, or a request that is sent far more often than you intended. It works with common HTTP stacks such as HttpURLConnection and OkHttp (so Retrofit); other stacks may need extra setup.

The Layout Inspector shows the actual UI tree of your running app, which is invaluable when a screen looks wrong and you cannot tell why.

1. Run the app. Open View → Tool Windows → Layout Inspector (the exact entry may be inside App Inspection on newer versions).
2. Select your process.
3. You see three panes: the Component Tree (hierarchy), a rendering of the screen (you can rotate it in 3D), and the Attributes pane for the selected element.

For View screens, the tree lists ConstraintLayout, TextView, etc. with their XML attributes. For Compose screens, it lists composables (Column, Row, Text, Button) and shows their modifiers, parameters, size and semantic information. For apps that mix both (lesson 43) it shows the Compose tree inside the ComposeView.

Useful tricks:

• Click a node in the screen to see which composable drew it, and use Go to source (right-click, or the Attributes toolbar) to jump to the code.
• 3D mode reveals overlapping or clipped layers.
• Recomposition counts (a checkbox in the Compose tree settings, called Show Recomposition Counts). Interact with the app, and the tree shows how many times each composable recomposed and skipped. A Text that recomposed 300 times while you scrolled is a performance clue (lesson 57).
• Live updates keep the inspector in step as the app runs, at some performance cost. Turn it off if the app becomes slow.
• Inspect semantics (the accessibility tree) to check labels and roles (lessons 46–48).

Layout Inspector needs a debuggable build and, on older devices, extra permission, and it can slow down a weak emulator. Close it when not in use.

You used @Preview in lessons 15–22. The preview window can do far more.

Multipreview annotations

To see a composable in light and dark, large font, and different devices without stacking many annotations by hand, define a multipreview annotation:

package com.example.classregister.ui
import android.content.res.Configuration
import androidx.compose.ui.tooling.preview.Preview
@Preview(name = "Light", showBackground = true)
@Preview(name = "Dark", uiMode = Configuration.UI_MODE_NIGHT_YES, showBackground = true)
@Preview(name = "Large font", fontScale = 1.5f, showBackground = true)
@Preview(name = "Small phone", device = "spec:width=320dp,height=640dp,dpi=320", showBackground = true)
annotation class ThemePreviews

Now one line puts all four previews on any composable:

import androidx.compose.runtime.Composable
@ThemePreviews
@Composable
private fun StudentRowPreview() {
 MaterialTheme { StudentRow(Student(1, "Ada Okafor", present = true), onPresentChange = {}) }
}

Android's UI Tooling library also ships ready-made multipreview annotations, for example @PreviewScreenSizes, @PreviewFontScale, @PreviewLightDark and @PreviewDynamicColors, which are exactly this idea. Check the androidx.compose.ui.tooling.preview package for the current set.

PreviewParameter

Preview the same composable with many sets of data:

import androidx.compose.ui.tooling.preview.Preview
import androidx.compose.ui.tooling.preview.PreviewParameter
import androidx.compose.ui.tooling.preview.PreviewParameterProvider
class StudentProvider : PreviewParameterProvider<Student> {
 override val values = sequenceOf(
 Student(1, "Ada", present = true),
 Student(2, "A very long student name that will have to wrap onto a second line", present = false),
 Student(3, "", present = false)
 )
}
@Preview(showBackground = true)
@Composable
private fun StudentRowVariants(@PreviewParameter(StudentProvider::class) student: Student) {
 MaterialTheme { StudentRow(student, onPresentChange = {}) }
}

This shows three previews: a normal row, a very long name and an empty name. Previewing edge cases catches layout bugs before you run the app.

Interactive, Animation and Deploy to Device modes

Above each preview you can choose:

• Interactive mode: click buttons and type into fields, as if on a device (with some limits).
• Animation Preview: scrub through updateTransition, AnimatedVisibility and similar animations (lesson 41).
• Deploy Preview to Device (the phone icon) runs only that composable on your emulator or device without launching the full app.

Preview limits and tips

• A preview cannot access things that need a real device: network, databases, LocalContext features like real resources of other apps. Give composables plain parameters (state and lambdas), not a ViewModel, so they stay previewable. This is the same advice as state hoisting (lesson 24).
• Use showSystemUi = true to show the status and navigation bars.
• If a preview breaks, press Build & Refresh at the top of the preview. A red banner explains which line failed.

Waiting for a full build every time you change a colour is slow. Android Studio has two faster ways:

To use Live Edit: open Settings → Editor → Live Edit and choose the mode (manual or automatic; the exact labels change between versions). Run your app on a device or emulator on a supported API level (see the documentation for the minimum), edit a composable, and watch the app update in a second or two. Limitations: structural changes (new classes, changes to function signatures, new resources) need a normal run; a status indicator at the top right of the editor tells you whether the last edit was applied or needs a rebuild.

The Android Profiler (View → Tool Windows → Profiler, or the Profile button) is where you investigate performance. Profile the release-like build whenever possible (lesson 49) because debug builds are slower and unrepresentative. The Studio can run the profiler on a profileable build for accurate results.

The main task types (names and layout change between Studio versions):

A short, useful workflow for memory leaks:

1. Rotate the screen and navigate back and forth several times.
2. Click Capture heap dump.
3. Search for your Activity or Fragment class: if there are several instances of the same screen that should be gone, you have a leak.
4. Select an instance and see the References (what keeps it alive). Common leaks: a static or singleton holding a Context or a View, a listener never removed, a fragment binding never nulled (lesson 42).

For jank (stuttering), record a System Trace while scrolling and look at frames longer than 16 ms (at 60 Hz) in the Frame timeline. Long frames show which work ran on the main thread. Lesson 57 goes much deeper (Macrobenchmark and baseline profiles).

The programme's Accelerate with tooling theme is simple: spend 30 minutes learning shortcuts and you will save weeks of typing.

Shortcuts you should memorise (Windows/Linux, macOS in brackets)

Keymaps vary; if a shortcut differs, Settings → Keymap lets you search by action.

Code completion and live templates

• Type Log + Tab expands live templates (Studio has logd, loge, logm). Type comp + Tab in some project setups to scaffold a composable; check Settings → Editor → Live Templates, and create your own: for example vm expanding into a ViewModel class skeleton.
• Postfix completion: type list.size.if and press Tab to wrap it in an if. Type value.var to create a variable.
• Extract: select code, press Ctrl+Alt+M (Cmd+Option+M) to extract a function, Ctrl+Alt+V to extract a variable.

Lint and inspections

Lint is Studio's static analyser: it flags hard-coded text, missing content descriptions, unused resources, missing permissions, likely crashes and deprecated API usage. Run it from Analyze → Inspect Code, or from the command line with ./gradlew lint. For Compose there are extra lint checks (for example for modifier parameters and state reads). Treat red/yellow squiggles seriously; Alt+Enter offers a fix for many of them. The accessibility checks in lint come back in lesson 48.

Version control and local history

The Git tools (Commit window, Log tab, the Show History view) and Local History (right-click a file → Local History → Show History) can recover a deleted block even if you never committed it.

Gemini in Android Studio

Recent Android Studio versions include Gemini, an AI assistant that can explain code, suggest fixes and help generate code in the IDE. Availability, plans and features have changed over time, so check the official Android Studio documentation for what your version offers. Treat suggestions like code from a classmate: read it, understand it, test it.

Mistake #1: Debugging with only println. Fix: use breakpoints and the Variables pane; use log-message breakpoints for quick prints.

Mistake #2: Reading only the last line of a stack trace. Fix: read the top, then find your package's line, and the last Caused by:.

Mistake #3: Logging secrets. Fix: never log tokens, passwords or personal data.

Mistake #4: Inspecting a release build. Symptom: inspectors show nothing. Fix: use a debuggable build (or a profileable one for profiling).

Mistake #5: Profiling a debug build and trusting the numbers. Fix: profile a release-like build.

Mistake #6: Leaving Live updates and Layout Inspector on. Symptom: a sluggish emulator. Fix: turn them off when finished.

Mistake #7: Previews that need a ViewModel. Symptom: preview fails to render. Fix: hoist state and pass plain parameters.

Mistake #8: Ignoring lint warnings. Fix: run Inspect Code before each release and fix real issues.

Mistake #9: Not saving filters. Fix: save a Logcat filter for your package and tag.

Mistake #10: Changing the database schema without checking the inspector. Fix: inspect after migrating.

Question 1. Where do you look first when the app crashes, and what do you read?

Question 2. What can the Database Inspector do that Logcat cannot?

Question 3. What does the Background Task Inspector show?

Question 4. How do you find which composables recompose too often?

Question 5. Why use a multipreview annotation?

Go deeper: official resources

• Jetpack Compose for Android developers, Pathway 1: Getting started
• Android Studio user guide
• Android Studio download page
• Android Basics with Compose course