CalcSnippets Search
Android 3 min read

`adb reverse` Is the Android Command You Need When Your Local API Works on Desktop and Fails on Device

A practical guide to `adb reverse` for Android developers who need emulators or devices to reach a local backend without changing production URLs or building messy temporary workarounds.

Why this command matters: one of the most common Android dev mistakes is forgetting that localhost on the phone is not your Mac or PC. It is the phone itself.

If your mobile app works fine in a desktop client but fails on Android when pointed at http://localhost:3000, the issue is usually not Retrofit, OkHttp, Axios, or your app code. The issue is network routing. Android’s adb reverse gives you a very clean way to map a port on the device back to a port on your development machine.

What adb reverse does

The Android docs describe adb reverse as a way to reverse socket connections. In practice, that means you can make a port on the device point back to a port on your local machine over ADB.

Typical example:

adb reverse tcp:3000 tcp:3000

Now requests from the device to localhost:3000 go to port 3000 on your computer.

That is usually exactly what you want for local backend testing.

Why developers keep getting this wrong

There are three common confusions:

  1. localhost on the device is not your laptop
  2. emulator shortcuts like 10.0.2.2 do not help on physical devices
  3. changing base URLs in code for every test is brittle and annoying

adb reverse solves these cleanly for many local dev cases because it lets your app keep using localhost, which is often the least disruptive setup.

The simplest working flow

Start your local API:

npm run dev

Or:

uvicorn app.main:app --reload --port 8000

Then connect the Android device or emulator and run:

adb reverse tcp:8000 tcp:8000

Now your Android app can call:

http://127.0.0.1:8000

or:

http://localhost:8000

depending on your client setup.

Verify that the mapping exists

If you are not sure whether the reverse rule is active, list it:

adb reverse --list

This is a good sanity check before you start blaming CORS, SSL, tokens, or JSON parsing.

Good debugging means verifying the network path first.

Remove stale reverse rules when things get confusing

Clear a single mapping:

adb reverse --remove tcp:8000

Or clear all of them:

adb reverse --remove-all

This helps when you changed ports, switched projects, or forgot what your last test left behind.

When adb reverse is the right tool

Use it when:

  1. you are developing against a local backend
  2. you want minimal app-config changes
  3. you are testing on a USB-connected device or supported emulator path
  4. you do not want to expose your machine to the whole LAN

It is often better than temporary public tunnels when you only need device-to-local connectivity.

When it is not enough

adb reverse does not solve every networking problem. It will not magically fix:

  1. Android cleartext HTTP policy issues
  2. backend binding only to the wrong interface
  3. auth bugs
  4. SSL certificate problems

It only fixes the route. That is still extremely valuable, but you should know what question it answers.

A practical setup example

For a React Native or Flutter app calling a FastAPI backend:

uvicorn app.main:app --reload --host 127.0.0.1 --port 8000
adb reverse tcp:8000 tcp:8000
adb reverse --list

Then use http://127.0.0.1:8000 in the app config for your dev flavor.

That is usually simpler than inventing separate IP-based configs for every network.

Final recommendation

If your Android app cannot reach a backend that works perfectly on your laptop, check the routing before you touch the app code. adb reverse is one of the fastest fixes for the “works locally, fails on device” class of bugs and should be part of every Android developer’s default toolbox.

Sources

Keep reading

Related guides