Vishal Tyagi
Exit/

Setting Up a Flutter Development Environment on Linux

5 min left

About this Codelab

What you'll build

A practical setup for Flutter + Dart on Linux — SDK install, editor config, emulator, and the gotchas that waste the first hour.

What you'll need

Topics: flutter, dart, linux, tooling. Language: Dart.

Duration: ~5 min7 stepsIntroUpdated 2026-06

Install the SDK

Skip your distro’s package manager for this one — Flutter ships its own toolchain and updates fast enough that distro packages are usually a version or two behind by the time you need something they fixed. Clone it straight from source instead:

git clone https://github.com/flutter/flutter.git -b stable ~/flutter
echo 'export PATH="$PATH:$HOME/flutter/bin"' >> ~/.bashrc
source ~/.bashrc
flutter doctor

flutter doctor will flag missing Android SDK components, Chrome (for web), and Linux desktop build dependencies separately — fix them one at a time rather than guessing.

Android toolchain without Android Studio

You don’t need the full IDE just to get flutter doctor green:

sdkmanager "platform-tools" "platforms;android-34" "build-tools;34.0.0"
flutter doctor --android-licenses

Editor setup

VS Code with the official Dart/Flutter extensions covers most day-to-day work — hot reload, widget inspector, and DevTools all work over the same debug session. The pain point is usually the Dart analysis server choking on a large monorepo; if dart analyze feels slow, check .dart_tool/ isn’t being watched by a separate file watcher (fswatch, inotify limits) competing with the IDE.

Emulator vs. physical device

Emulators are fine for UI work but unreliable for anything touching platform channels — telephony, permissions, background services. For that class of bug, a physical device over USB with flutter run --verbose is the faster debugging loop, even with the extra setup friction of enabling USB debugging.

Common first-hour issues (the ones that eat the most time)

  • flutter doctor reports a Chrome problem on a headless box — set CHROME_EXECUTABLE explicitly, or skip web target entirely if you don’t need it.
  • Gradle build first run is slow — this is expected; it’s downloading the Gradle distribution and dependencies, not a hang.
  • Hot reload stops working after a platform-channel change — platform channel and native code changes need a full restart (R in the CLI, not r), hot reload only covers the Dart layer.

inotify limits on large monorepos

Linux’s default inotify watch limit is tuned for typical desktop usage, not for a large Flutter monorepo with many packages and generated files. If the IDE’s file watcher silently stops noticing changes — edits don’t trigger hot reload, or the Dart analysis server falls behind — check cat /proc/sys/fs/inotify/max_user_watches against the actual file count under the workspace, and raise the limit via sysctl rather than assuming the IDE itself is broken. It’s a one-time fix per machine — five minutes once you know to look here, an hour if you don’t and end up blaming Flutter, your editor, and possibly the universe before you find the real cause.

Keep multiple Flutter channels available

Working across more than one project sometimes means each one targets a different Flutter version. Rather than switching the single global SDK back and forth, cloning a second copy of the Flutter repo at a different version and pointing each project’s shell/IDE config at the right one avoids the churn of constantly running flutter channel and flutter upgrade every time you switch contexts.