Skip the Android Studio detour. Open LingCode's Device Manager, create an AVD, boot it, and run a Gradle project on it — same window your iOS Simulator already lives in.
An Android emulator is two pieces glued together. A system image is a complete bootable Android OS — a kernel, framework, and bundled APIs at a specific API level (e.g. android-34) for a specific CPU (arm64-v8a on Apple Silicon, x86_64 on Intel). A device profile is a hardware template: a screen size, a DPI, a RAM budget, the camera and sensor capabilities a Pixel 7 reports. An AVD ("Android Virtual Device") is the name you give a specific pairing of one system image with one device profile, plus a writable disk so the emulator remembers what you installed.
You do not need Android Studio to manage these. Apple ships Simulator.app and xcrun simctl; Google ships emulator, avdmanager, and sdkmanager, and they work fine standalone. LingCode's Device Manager wraps both, so iOS simulators and Android AVDs sit in the same list, with the same Start / Stop / Delete actions and the same toolbar Run Destination picker downstream.
This tutorial is the path from "I just installed LingCode" to "an emulator is booting and my Gradle app is launching on it." It covers the SDK prerequisite, creating the AVD, starting it, selecting it as a run destination, and what to do when the Device Manager shows an empty Android section despite the SDK being installed.
brew install --cask android-commandlinetools followed by sdkmanager "platform-tools" "emulator" "system-images;android-34;google_apis;arm64-v8a". Alternatively, install Android Studio once just to get its bundled SDK — LingCode picks it up automatically from ~/Library/Android/sdk.
In LingCode's menu bar, choose Mobile → Device Manager…. A sheet slides up with four sections: Physical Devices (iOS), Simulators (iOS), Android Emulators (AVDs), and Physical Devices (Android).
Look at the top of the sheet. If you see an orange banner that says "Android SDK not detected," LingCode could not find an SDK — either ANDROID_HOME/ANDROID_SDK_ROOT is unset and the default ~/Library/Android/sdk path is empty, or essential binaries (adb, emulator) are missing inside the SDK directory. The banner's bullet list tells you exactly which check failed; install what's missing, then hit Re-check.
If no banner appears and the Android Emulators section shows "No AVDs configured," the SDK is wired up correctly and you're ready to create one.
ANDROID_HOME first, then ANDROID_SDK_ROOT, then ~/Library/Android/sdk, then ~/Android/sdk. If you already have Android Studio installed, the default ~/Library/Android/sdk is almost always the one to use — don't set the env var unless you're juggling multiple SDKs.
At the top right of the Device Manager sheet, click the + icon and choose New Android Emulator…. A small wizard opens with three fields:
Pixel_7_API_34). No spaces. Use underscores or dashes; the emulator -avd <name> command treats the name as a single token.sdkmanager --list_installed. If the dropdown is empty, install one from the terminal: sdkmanager "system-images;android-34;google_apis;arm64-v8a". The variant matters: google_apis includes Play Services stubs (most apps need this); default is AOSP-only; google_apis_playstore includes the real Play Store (use this if your app needs IAP or Maps).avdmanager list device. LingCode defaults to the first Pixel profile because that's what the AOSP launcher targets. Picking a tablet profile here is fine; picking a watch or TV profile will boot, but won't behave like a phone.Click Create. Behind the scenes LingCode runs avdmanager create avd -n <name> -k <system-image> -d <device> --force and pipes no to the "Do you wish to create a custom hardware profile?" prompt. The sheet closes and your new AVD appears in the Device Manager list.
Click Start next to the AVD row. LingCode spawns emulator @<name> as a detached background process — stdout and stderr are piped to /dev/null because a chatty emulator can stall waiting on a full pipe. The Emulator window appears on your desktop and starts booting Android.
First boots are slow — anywhere from 30 seconds on Apple Silicon to several minutes on Intel — because the emulator has to inflate a fresh userdata image. Subsequent boots reuse the snapshot, so they take a few seconds. The AVD row in Device Manager flips to ● Running as soon as adb devices sees the emulator come online; LingCode polls every couple of seconds to catch it.
emulator -accel-check in your terminal reports problems, fix that first; LingCode can't paper over the missing accelerator.
Device Manager is for lifecycle — create / boot / stop / delete. Once an AVD is running, you choose it as a build target from the Run Destination picker in the top toolbar (the same picker you use for iOS simulators and My Mac). Open it; you'll see a new "Android Emulators" section listing your running AVD as <name> (API XX), and a "Android Offline AVDs" section for any AVD you have but haven't started — picking an offline one and hitting Run auto-boots it first.
Select your AVD. The toolbar shows the AVD name next to the Run button, and LingCode now knows that "Run" on this project means: build for Android, install on this emulator, launch the launcher Activity.
Open an Android project (any folder containing a settings.gradle.kts or settings.gradle with an :app module). LingCode's project-type detector classifies it as gradleAndroid, which is what routes Run through the Android coordinator rather than xcodebuild.
Hit the Run button (or ⌘R). LingCode runs ./gradlew :app:assembleDebug, streams the build log into the Run Console, locates the resulting APK, parses the merged Android manifest for the applicationId and launcher activity, installs the APK with adb install -r, and launches it with adb shell am start -n <applicationId>/<launcher>. The app appears on the emulator.
The Run Console stays open showing each phase. When something fails, the line that failed tells you which phase: Gradle errors come straight from the compiler; install errors come from adb (the most common is a signature mismatch — bump the version in build.gradle.kts or uninstall the old build); launch errors come from am start (usually a wrong activity name in the manifest).
Open the bottom panel and switch to the Run Console. With the AVD as your run destination, LingCode auto-attaches adb logcat filtered to your application's PID — same idea as iOS's "Console output" pane, but with Android's level prefixes (D/, I/, W/, E/). When the app crashes, the stack trace lands here.
This is also the right surface for debugging — LingCode's JDWP forwarder routes the debugger session through the same emulator connection, so breakpoints set in a .kt file in the editor work the same way Kotlin/Java debugging works in Android Studio.
"No AVDs configured" but I just created one. Hit Refresh in the Device Manager header. AVDs are read from emulator -list-avds; if the emulator binary isn't on the path LingCode resolved, it returns empty. Re-check the toolchain banner.
The AVD won't start. Run emulator @<name> -verbose in a terminal — the verbose output reveals whether the failure is acceleration, missing system-image files, or a corrupted snapshot. A corrupted snapshot is fixed by deleting it (emulator @<name> -wipe-data on next start, or delete the AVD and recreate).
Run button does nothing on an Android project. The toolbar destination picker must have an Android target selected. If "My Mac" or an iOS simulator is selected, LingCode will try to build for that target and fail with a destination-mismatch error.
I want a different SDK location. Set ANDROID_HOME in your shell init (e.g. ~/.zshrc) and relaunch LingCode. The toolchain detector reads it on every refresh(), but env vars only propagate to processes that inherit them — a relaunch is the cleanest reset.