The Android emulator is a real Android on your computer, and Google publishes the list of what it cannot do.
The emulator runs a real Android system image on your machine, and a React Native and Expo project starts on it with one command. Google describes it as providing almost all the capabilities of a real Android device, and then names the exceptions in writing: no virtual hardware for Bluetooth, NFC, SD card insert and eject, device-attached headphones, or USB. That list is short, it is specific, and it is the only part of this subject worth memorising. If you were handed a generated project and are not sure what React Native is, start there and come back.
What follows is what the emulator actually is, the documented list of what it will never show you, the four things that break the first time you point an Expo project at it, and the honest answer to whether you need it at all when the build pipeline already puts an APK on your phone. Every figure below carries the date it was read.
Start hereThe short version
Use it for screens. Use a phone for anything with a radio in it.
The split is cleaner than the arguments about it. Layout, navigation, forms, lists, text that overflows at a larger font size, the parts of a generated app you will edit twenty times this week: the emulator is faster than reaching for a phone, and you can keep five screen sizes open at once. Anything that depends on a radio, a port or a physical act, pairing, tapping a card, plugging something in, ejecting a card, belongs on hardware, because Google says the virtual hardware is not there.
There is a second category people miss, and it is networking. The emulator sits behind its own virtual router. Inside it, localhost means the emulator, not your laptop, and your laptop is reachable at the alias 10.0.2.2. Google also states plainly that the emulator does not support IGMP and might not support ICMP, so ping does not work against your host or your network. None of that is a bug in your app, and all of it is written down.
What is the Android emulator actually running?
A whole Android operating system, virtualised, with your app installed on it. Not a preview, not a browser pretending to be a phone. Google describes the emulator as simulating Android devices on your computer so you can test on a variety of devices and Android API levels without owning each one, and ships predefined configurations for phones, tablets, Wear OS, Android Automotive OS and Android TV. The practical consequence for someone who did not write their project is that the emulator will happily run code that a real phone also runs. It is not a simplified target you have to work around.
It costs real machine resources, and the recommended numbers are published. Google's emulator page, read on 17 October 2026, suggests at least 16 GB of RAM, 16 GB of disk space, and 64-bit Windows 10 or higher, macOS 12 or higher, Linux or ChromeOS, and notes that higher API levels and larger screens may require more. The reason a laptop that meets those numbers can still be unusable is hardware acceleration. The emulator needs virtualisation extensions from your processor: Intel VT-x, AMD-V, or Apple silicon, with second-level address translation on Intel and AMD. On macOS it uses the built-in Hypervisor framework, on Linux KVM, and on Windows the Windows Hypervisor Platform, which Google recommends. Google also says its own alternative Windows driver will be sunset on 31 December 2026, so that is not the one to set up now.
One line in that acceleration page explains most complaints about emulator speed. Google warns that virtual devices which do not follow the architecture requirements, such as ARM-based system images on Intel or AMD processors, cannot use the VM acceleration at all. Match the image to the machine. On an Apple silicon Mac that means an arm64-v8a system image, which is also what your users' phones run, so the match is not a compromise. On Intel or AMD it means x86_64. Picking the wrong one does not fail loudly, it just gives you an emulator slow enough that you stop opening it and go back to guessing.
Worth saying what this is not: a decision you need to revisit. The emulator is a tool for looking at an app, not a property of the app. If you are still weighing Flutter against React Native, the Android emulator is the same emulator in both cases, with the same published limits. It belongs to Android, not to your framework.
Android Developers, advanced emulator usage, last updated 6 March 2026, read 17 October 2026
What does Google say the emulator cannot reproduce?
Five items of hardware, named on one page. Google writes that the Android Emulator does not include virtual hardware for Bluetooth, NFC, SD card insert and eject, device-attached headphones, and USB. It adds that the Wear OS watch emulator does not provide the Overview button, the directional pad or a fingerprint sensor. That page was last updated on 6 March 2026 and read on 17 October 2026, and it contains no other statement about what the emulator cannot do. People repeat much longer lists than that, usually from forum posts. The documented list is five lines.
One of those five is contested by Google itself, and you should know it before you plan around it. The Android Emulator networking page, last updated 12 March 2026 and read the same day, carries a capability table that gives Bluetooth from API level 31 with Classic and BLE profiles, Wi-Fi from API 25 as a simulated access point, incoming calls and SMS from API 30, and UWB ranging from API 36. So one Google page says there is no virtual Bluetooth hardware and another gives you its API levels and profiles. The networking page carries the later date, which hints that the limitations list is the stale one, but neither page says so and we could not find a note reconciling them. We are telling you it is unresolved rather than picking the answer that reads better. Pair on a phone.
The headphones entry has a similar wrinkle, which is worth knowing because it looks like a contradiction and is not. There is no virtual hardware for device-attached headphones, and Extended controls still gives you a Simulate Insert Headset switch. The difference is the difference between an event and a device. Your app can be told headphones were plugged in, so code paths that react to that will run. There is nothing on the other end of the cable. If what you need to test is routing audio to a headset, that is hardware. If what you need to test is the branch of your code that fires when a headset appears, the switch is enough.
Then the limits nobody files under hardware. Google states that each instance of the emulator, before Emulator 36.5, runs behind a virtual router or firewall service that isolates it from your development machine's network interfaces and from the internet, and that an emulated device cannot detect your development machine or other emulator instances on the network. It states that the emulator does not support IGMP, and that depending on the environment it might not support other protocols such as ICMP, so users cannot ping the host machine or other devices on the local area network. If your app does local discovery, talks to a device on the same Wi-Fi, or health-checks by ping, the emulator is the wrong room to debug it in.
Check yours
Emulator or a real phone
Tick what you are trying to test. Every answer below is what Google's own emulator documentation says, read on 17 October 2026.
Nothing ticked. For most of a generated app, screens, navigation, forms, lists and the parts you will change twenty times this week, the emulator is the faster place to look.
Android Developers, advanced emulator usage, read 17 October 2026
What breaks the first time you point a generated project at it?
Four things, in roughly this order, and none of them are your app's fault. The first is the toolchain. Expo's own Android Studio Emulator page, last modified 16 October 2026, lists what has to exist before anything runs: JDK 17, Android Studio installed with the Standard install type, Android SDK Platform 36 and Sources for Android 36 ticked under SDK Platforms, because Expo states that the Android 16 SDK, codenamed Baklava, is required to compile a React Native app. Under SDK Tools, Android SDK Build-Tools and Android Emulator have to be installed. A generated project is a normal React Native and Expo project, so it needs exactly what any other one needs.
The second is the shell. On macOS, Expo has you export ANDROID_HOME as $HOME/Library/Android/sdk and add both $ANDROID_HOME/emulator and $ANDROID_HOME/platform-tools to your PATH, then reload the shell and check that adb runs. On Windows it is a user environment variable pointing at the SDK and the platform-tools folder added to Path. If you have ever installed Android tooling another way, you can end up with two copies of adb and an error about the server version not matching the client, which Expo flags with a fix. None of this is interesting, all of it is load-bearing, and it is the step that makes people think the emulator is broken.
The third is the device itself. Open More Actions, then Virtual Device Manager, then Create virtual device, pick a hardware profile, Expo suggests starting with the newest Pixel, pick and download a system image, and finish. After that the Play button in Device Manager starts it any time. Then, from the project directory, npx expo start --android. Worth noting what that page covers and what it does not: it walks through installing Expo Go, and it does not discuss development builds at all. If your project has native code that Expo Go does not carry, Expo Go will not be the thing you run, and that page will not tell you so.
The fourth is the one that wastes a whole afternoon. The app starts, the screens render, and every call to your own server fails while the same URL works in your browser. Inside the emulator, 127.0.0.1 is the emulator's own loopback interface. Your machine is reachable at 10.0.2.2, which Google documents as a special alias to your host loopback interface. The gateway is 10.0.2.1 and the first DNS server is 10.0.2.3. Change the base URL and it works. This one has nothing to do with the emulator's limits and everything to do with a config value that was correct on a laptop and wrong on a virtual phone, which is also the shape of most problems you will meet in a project you did not write. Once it does run, the next thing worth learning is over the air updates, because that is how a fix reaches users without a store round trip.
Expo documentation, Android Studio Emulator, last modified 16 October 2026
Do you need the emulator at all for a generated app?
For Android, less than you would think, and it is worth being specific about why. The emulator exists to give you devices you do not own. If your app is already on a real Android phone in your pocket, the emulator's main advantage has been spent. Newly builds a standalone Android APK and publishes to Google Play internal testing, so the first look at a generated app can be the real thing on real hardware, where the documented limits do not apply and the undocumented ones, how it feels, how warm the phone gets, whether you can reach the buttons, are visible too.
So keep it for the three jobs a phone cannot do. Devices you do not own, which is the whole point: a small screen, a tablet, an old API level you are not going to downgrade your own phone to. Screen sizes side by side, because you can run several virtual devices at once and you own one phone. And states you cannot produce on demand, which is where Extended controls earns its keep: a GPS route played back from a GPX file, a weak signal, roaming, a battery at four percent, a proximity sensor covered, a fingerprint scan. Waiting for a real battery to drain is not testing, it is an afternoon.
iOS is the asymmetry worth planning around. Newly uploads iOS builds to TestFlight, and it does not submit to the App Store on your behalf, because Apple requires the content owner to submit. Android lets you hand someone an APK; iOS does not have an equivalent you can email. So the shape of your testing tends to be real phones on Android early, TestFlight on iOS slightly later, and the emulator and the simulator for the device shapes neither covers.
The cost worth counting is your own time, not a licence. The emulator is free, and 16 GB of RAM plus 16 GB of disk plus an Android Studio install is not free in attention. If you are budgeting the year ahead rather than the afternoon, that is part of what an app costs to maintain, alongside SDK upgrades and store requirement changes that arrive whether you asked for them or not.
Expo documentation, Android Studio Emulator, read 17 October 2026
The emulator against a real phone, by what you are testing
| What you need | Android emulator | A real Android phone | Same answer on both |
|---|---|---|---|
| Bluetooth, NFC, USB, SD card swap | Not virtualised, per Google's own list | Yes | No |
| Sees your laptop on the network | No, host loopback only, at 10.0.2.2 | Yes, same Wi-Fi, same subnet | No |
| ping, and anything using IGMP | IGMP not supported, ICMP may not be | Yes | No |
| Fake GPS route, weak signal, flat battery | Yes | Only by going outside and waiting | No |
| Install an APK by hand | Drag and drop onto the window | Yes, once the phone allows it | Yes |
| Costs you something to own | 16 GB of RAM and 16 GB of disk | The price of the phone | No |
| Has to match your computer's CPU | arm64 images on Apple silicon, x86_64 on Intel | No | No |
Where this lands if a builder generated your app
Nothing about the emulator changes because an agent wrote the code. That is the point, and it is the reassuring part. Newly generates a real React Native and Expo project that you own, so the emulator treats it the way it treats any other Expo project, and the setup steps on Expo's own page are the steps that apply to you. There is no builder-specific runtime to learn and no proprietary preview you are stuck inside. It is $25 a month, with no free plan.
Two things make the local emulator optional rather than mandatory. Newly has two-way GitHub sync, so the project is in a repository you can clone and run locally whenever you want to, which is when the Android Studio install becomes worth doing. And it builds a standalone Android APK and publishes to Google Play internal testing, so there is a path to a real device that does not go through your laptop at all. Install the emulator when you need a device you do not have, not as a rite of passage.
The honest limit: the emulator cannot tell you whether the app is any good. It renders what you built, faithfully, on hardware that does not exist. Everything about feel, weight, warmth, one-handed reach and whether a tap target is where a thumb lands, needs a phone. Use the emulator to see the thing, use a phone to judge it, and keep Google's five-line list of missing hardware in mind when a feature works in one place and not the other.
Questions people ask about running the Android emulator
Expo's Android Studio Emulator page, read on 17 October 2026, gives the order. Install JDK 17. Install Android Studio with the Standard install type. In SDK Platforms select Android SDK Platform 36 and Sources for Android 36, because Expo states that the Android 16 (Baklava) SDK is required to compile a React Native app. In SDK Tools confirm Android SDK Build-Tools and Android Emulator are installed. Set ANDROID_HOME, which on macOS is $HOME/Library/Android/sdk, and add $ANDROID_HOME/emulator and $ANDROID_HOME/platform-tools to your PATH. Create a device under More Actions, Virtual Device Manager, Create virtual device, and Expo suggests starting with the newest Pixel. Then run npx expo start --android from the project directory.
Describe the app, then look at it on something real
Get an APK onto your own phone first, and keep the emulator for the devices and the states you cannot get hold of. That order answers more questions per hour than the other way round.
Start building