skip to content

SDK Channels & Doctor

1 roadmap5 questions

Setting up and repairing the Flutter SDK: flutter doctor -v reports what is missing, channels pick stable or beta, and upgrade or downgrade move the SDK. Interviewers probe a broken toolchain.

on this pageshow

explore

questions

5

In Flutter, what does the flutter doctor command check, and how do you read its markers and the extra detail flutter doctor -v adds?

level: juniorimportance: must knowfreq 72%

answer

  1. one validator per toolchain
  2. Flutter, Android, Xcode, Chrome, devices, network
  3. check mark, exclamation, cross
  4. hints print even without -v
  5. -v adds paths, revisions, timings

basics

~20 s

flutter doctor runs validators for the Flutter SDK, each host toolchain, connected devices and network access, marking each [✓] ready, [!] partial or [✗] missing with a fix hint; -v adds paths, revisions and timings.

solid answer

~40 s

`flutter doctor` runs one validator per concern: the Flutter SDK itself (channel, version, whether `flutter` and `dart` on `PATH` point into this SDK), the Android toolchain with its licence sub-check, Xcode and CocoaPods on macOS, Chrome for web, the Linux or Visual Studio toolchain for desktop, connected devices and network resources. Each line gets `[✓]` (ready), `[!]` (partial or not available) or `[✗]` (missing), and problem lines carry the error or hint with the fix. The summary ends with `Doctor found issues in N categories` or `No issues found!`. `flutter doctor -v` runs the same checks but also prints the informational lines — SDK and JDK paths, Dart and engine revisions, feature flags — plus per-check timings, which is what you paste into a bug report.

code

bash · 13 lines
bash
flutter doctor
# Doctor summary (to see all details, run flutter doctor -v):
# [✓] Flutter (Channel stable, 3.47.5, on macOS ..., locale en-US)
# [!] Android toolchain - develop for Android devices (Android SDK version 36.0.0)
#     ✗ Android licenses not accepted. To resolve this, run: flutter doctor --android-licenses
# [✓] Xcode - develop for iOS and macOS
# [✓] Chrome - develop for the web
# [✓] Connected device (2 available)
# [✓] Network resources
#
# ! Doctor found issues in 1 category.

flutter doctor -v   # same checks, plus paths, revisions, JDK source and timings

go deeper

for a junior

Recall the three markers and the main sections: Flutter, Android toolchain, Xcode, Chrome, connected devices. Know that -v prints more detail and that hint lines give you the fix command.

for a middle

Explain that each section is a validator chosen by host OS and enabled platforms, and that -v reveals informational lines such as the JDK source and SDK paths rather than extra checks.

for a senior

Use doctor -v as a diagnostic: read which JDK and SDK were picked and why, fix top-down from the Flutter section, and know doctor checks the machine, not a project's Gradle or signing setup.

for a principal

Treat doctor output as the baseline of a reproducible developer environment: which sections a team must keep green, and which platforms to disable so new machines are not held to targets you never ship.

## What flutter doctor is for The Flutter SDK does not build apps on its own: it drives other toolchains. An Android build needs the Android SDK and a JDK, an iOS build needs Xcode, a web run needs a Chrome binary, and a desktop build needs the host's native compiler. `flutter doctor` is the command that checks all of them at once and tells you, in one screen, which targets this machine can build right now and what to install or configure for the rest. It is the first command after installing Flutter, the first command after an upgrade (the upgrade itself runs it at the end), and the first thing a maintainer asks for in a bug report. ## The validators it runs Each section of the output is a **validator**. Which ones appear depends on the host operating system and on which platforms are enabled in `flutter config`: | Validator title | Appears on | What it checks | |---|---|---| | `Flutter` | every host | channel and version, the upstream git remote, whether `flutter` and `dart` on `PATH` resolve inside this SDK, Dart and engine revisions, feature flags | | `Android toolchain - develop for Android devices` | when Android is enabled | Android SDK location and build-tools, the `cmdline-tools` component, the JDK, and an **Android licence sub-check** | | `Xcode - develop for iOS and macOS` | macOS | Xcode installation and setup, with a CocoaPods sub-check | | `Chrome - develop for the web` | when web is enabled | a Chrome executable (override with `CHROME_EXECUTABLE`) | | `Linux toolchain` / `Visual Studio - develop Windows apps` | Linux / Windows | the native desktop compilers | | `Connected device` | when devices can be listed | how many devices and emulators are visible | | `Network resources` | every host | reachability of the hosts the tool downloads from | A `Proxy Configuration` section appears only when proxy environment variables are set. Since Flutter 3.38 there are **no IDE sections**: doctor stopped validating Android Studio, IntelliJ and VS Code plugins, so an old screenshot showing them is out of date. ## Reading the markers - **`[✓]`** — the validator passed; that target is ready. - **`[!]`** — **partial** or not available: something works but needs attention, such as unaccepted Android licences. It counts as an issue but does not make doctor report failure. - **`[✗]`** — **missing**: the toolchain is absent or unusable, for example no Android SDK found. - **`[☠]`** — the validator itself crashed; the output includes the exception. Inside a section, message lines use `•` for information, `!` for a hint and `✗` for an error. Hint and error lines always print; they carry the actionable text, often an exact command such as `flutter doctor --android-licenses`. The last line totals the damage: `Doctor found issues in 2 categories.` or `No issues found!`. Validators run concurrently, and each has a time limit of four and a half minutes before it is reported as failed, so a hung network check cannot freeze the command forever. ## Summary versus -v | | `flutter doctor` | `flutter doctor -v` | |---|---|---| | Header | `Doctor summary (to see all details, run flutter doctor -v):` | none | | Hints and errors | shown | shown | | Informational lines (paths, versions, revisions, feature flags) | hidden | shown | | Per-validator timing | hidden | shown in brackets | `-v` is the tool-wide verbose flag, so the checks are identical; only the amount printed changes. The verbose view is where you find the **SDK path** (useful before touching the checkout with git), the **`Java binary at:`** line with where that JDK came from, the Android SDK location and the Dart version bundled with this Flutter. ## Using the output well 1. Fix sections top-down: the `Flutter` section first, because a wrong `PATH` or a broken checkout invalidates everything below it. 2. Ignore sections for targets you do not ship. A `[✗]` Visual Studio line on a machine that only builds mobile apps is harmless, and you can hide it by disabling that platform with `flutter config`. 3. Run `flutter doctor -v` when a message is unclear; the informational lines usually explain it (a JDK found on `PATH` instead of Android Studio's, an SDK at an unexpected location). 4. Re-run after every fix. Doctor has no memory; each run re-checks everything. Doctor diagnoses the machine, not a project. A clean doctor does not guarantee a given app builds — Gradle versions, plugin constraints and signing live in the project.

  • Does a [!] section mean you cannot build for that platform?
    Not necessarily. `[!]` is partial: the toolchain was found but something needs attention. Unaccepted Android licences give `[!]`, and the first Gradle build will then fail on them, while other partial results are warnings you can live with. Only `[✗]` (missing) and a crashed validator make doctor report failure; read the hint line to decide.
  • Why would the Flutter section warn about the dart binary?
    The Flutter validator resolves `flutter` and `dart` on `PATH` and warns when either resolves outside the current SDK's `bin` directory, typically because a separately installed Dart SDK comes earlier on `PATH`. That `dart` may be a different version from the one Flutter bundles, so the fix is to put the Flutter SDK's `bin` first.

It is a pre-flight checklist: each instrument gets a tick, a caution or a cross, and the long form of the checklist also records the serial numbers you would quote to a mechanic.

saying these in an interview costs you the question

  • Says flutter doctor also checks the project's pubspec and dependencies
  • Thinks a [!] line always means the platform cannot build
  • Believes errors and hints are only visible with -v
  • Expects doctor to list Android Studio and VS Code plugins today
  • Treats a clean doctor run as proof the app will build
open as a page

How do you install the Flutter SDK so flutter and dart work in any terminal, and what does flutter doctor flag when PATH is wrong?

level: juniorimportance: should knowfreq 40%

basics

~10 s

Extract the Flutter SDK to a user-writable folder and put its bin directory on PATH, which provides both flutter and dart. Doctor warns when either is missing from PATH or resolves outside that SDK.

open as a page

In Flutter, what are the stable, beta and main channels, and how do flutter channel, flutter upgrade and flutter downgrade move the SDK?

level: middleimportance: should knowfreq 52%

basics

~20 s

The Flutter SDK is a git checkout and a channel is its branch: stable for production, beta monthly, main for contributors. flutter channel switches branch, flutter upgrade moves to the channel's latest release, flutter downgrade undoes the last upgrade.

open as a page

In Flutter, what do flutter config --jdk-dir and --android-sdk change, and how does the tool otherwise find a JDK and the Android SDK?

level: middleimportance: should knowfreq 32%

basics

~10 s

flutter config stores per-user overrides: --jdk-dir and --android-sdk pin the JDK and Android SDK paths. Without them Flutter tries Android Studio's JDK, then JAVA_HOME, then PATH, and reads ANDROID_HOME for the SDK.

open as a page

On a new laptop, flutter doctor marks the Android toolchain [!] with 'Android license status unknown' — how do you diagnose and fix it with the Flutter tool?

level: seniorimportance: should knowfreq 42%

basics

~20 s

Doctor checks licences by running the SDK's sdkmanager --licenses with the JDK it found; status unknown means that run failed. Install cmdline-tools, point Flutter at a working JDK, then run flutter doctor --android-licenses and accept.

open as a page