Your Camera Phone Is Two Walls Too Far: The Wi-Fi Numbers Android Actually Uses, and Why 5 GHz Is the Wrong Band

Your camera phone does not move. That single fact puts it outside almost everything Wi-Fi was designed around — and it is why the phone in the back room, the outbuilding, or up beside the water tank keeps falling off the network while the phone in your pocket never does.

Most advice about this is guesswork dressed as confidence: move it closer, buy a repeater, use 5 GHz, it's faster. Android does not guess. It uses published numbers to decide whether your Wi-Fi connection is good enough, and those numbers are written down in the Android Open Source Project. This guide uses them.

How far from the router can an old Android phone camera sit?

Far enough that the signal at the phone stays above roughly -73 dBm on 2.4 GHz or -70 dBm on 5 GHz — the thresholds Android's own network-selection code uses to decide a connection is good enough. In practice that is one or two interior walls in brick or concrete construction, or most of a small house in drywall. Put the camera on 2.4 GHz, not 5 GHz.

Those two numbers are the whole article, so it is worth seeing where they come from.

The two numbers Android actually uses

AOSP's Wi-Fi network selection page documents when the framework considers a connection good enough to skip scanning for something better. The thresholds are stated plainly:

RSSI is greater than -73 dBm for the 2.4 GHz band [...] or -70 dBm for the 5 GHz and 6 GHz bands.

There is a second number nearby. Android polls signal strength and link statistics every 3 seconds, but stretches that to 6 seconds when the device is stationary and RSSI is greater than -68 dBm. It drops back to 3 seconds when the device is non-stationary or RSSI falls below -73 dBm.

Read that again with a camera in mind. Android has a notion of a device that is holding still, and it rewards it — a stationary phone with a strong signal gets left alone. Your camera phone is permanently stationary. It qualifies for the calm path, but only if you keep it above -68 dBm. Below -73 it is polled twice as often forever.

The trap: Android judges the weaker band more harshly

Here is the part nobody mentions, and it is a direct consequence of putting those two thresholds side by side.

5 GHz gets the stricter requirement (-70 dBm) — and 5 GHz is also the band that reaches less far. Cisco's Wireless RF Reference Guide puts the physics simply:

The higher the frequency, the shorter the radio wave [...] That is why 2.4 GHz travels farther than 5 GHz.

So the band that arrives weaker at the far end of your house is also the band Android demands 3 dB more of. That is a penalty applied twice, in the same direction, to exactly the device you cannot easily move closer. For a phone you carry, none of this matters — you walk back toward the router. For a camera bolted above a doorway, it decides whether the live view works.

Put the camera phone on 2.4 GHz. You are not streaming 4K across the internet; you are moving a live picture a short distance across your own network. Range matters more than headline speed. The one real cost is congestion: 2.4 GHz has only three non-overlapping channels (1, 6 and 11), and Cisco notes it "will fill up faster and support fewer users" than 5 GHz. On a home or small-shop network with a handful of devices, that trade is worth making.

What a wall costs, and why this is not the same everywhere

Cisco's guide also puts numbers on obstacles:

Typical objects are brick walls (10 dB attenuation); concrete, which has more metal (12 dB); and drywall (typically 3 dB).

Now do the arithmetic that the two sources make possible together. Cisco treats -66 dBm as a standard survey value for solid client coverage. Android's 2.4 GHz cut-off is -73 dBm. That leaves about 7 dB of margin between a comfortable signal and Android's "good enough" floor — less than a single brick wall.

This is where the advice stops being universal. A drywall interior wall costs about 3 dB; a concrete one costs about 12 dB. That is a fourfold difference in attenuation per wall, and it means guidance written for a timber-and-plasterboard house does not transfer to a brick or concrete-block one. Two concrete walls is roughly 24 dB of loss. Cisco notes that "+6 dBm often doubles the range" — inverting that as a rough rule of thumb (my inference from their figure, not their claim), 24 dB is something like four halvings of usable distance.

If your house or shop is concrete or brick, assume you get one wall, and plan the camera's position around that rather than around a number you read in a review written somewhere else.

Screen off changes the rules — and that is our operating mode

This is the part that matters most for a background camera, and it is documented in the same AOSP page.

When the screen is off and the phone is connected to Wi-Fi, the framework stops evaluating the connection:

The framework doesn't initiate an evaluation on the connected network [...] The firmware evaluates the network quality and if the network quality is bad, the firmware might roam or (eventually) disassociate from the network and wake up the host.

And on scanning: "the firmware (Wi-Fi SoC) performs roaming scans. The framework doesn't perform any scans when the screen is off."

So with the screen off — which is how a background camera runs all day — the careful, documented, tunable Android logic hands over to the Wi-Fi chip's own firmware, which is vendor code with no published thresholds. The word to notice is disassociate. A marginal link that limps along while you are looking at the screen can be dropped outright once the screen goes dark.

There is a small mercy in the same document: a connection carrying more than 16 packets per second counts as "sufficient traffic" and is left alone. A live video stream comfortably clears that. The connection is most at risk when nobody is watching.

One honest consequence: this is a live view problem, not a recording problem. Background Camera RemoteStream writes video to the phone's own storage and serves the live picture from a small web server on the phone itself. If the Wi-Fi drops, the recording keeps going, because nothing about capturing video depends on the network. You lose the ability to watch, not the footage. That is a direct benefit of not routing video through a cloud service — there is no upload to fall behind.

The band-steering trap

Many routers publish one SSID for both bands and decide for you which to use. That is convenient for a phone in your pocket and wrong for a camera that never moves: the router may hand your far-away camera to 5 GHz because the signal looked adequate during setup, standing next to the router.

The fix is boring and effective: give the 2.4 GHz radio its own SSID in your router's settings and join the camera phone to that one explicitly. If your router will not split the bands, place the camera where 5 GHz is genuinely strong, or accept that it may switch.

A related failure is worth naming because it points somewhere else: if the live view dies but the camera is fine, the problem may be the viewing device quietly preferring mobile data. AOSP documents that an OEM-supplied network scorer can mark Wi-Fi unusable and trigger "a fallback to mobile data." We covered that failure in detail in what happens during a power cut or an internet outage, and the roaming half — sticky clients and why a new mesh node often does not help — in the first Wi-Fi device you own that never moves.

Setting it up: the ten-minute version

1. Split your router's bands so 2.4 GHz has its own SSID. Join the camera phone to it.
2. Place the phone, then check the signal from where it will live — not from where you are standing. On most Android builds: Settings → Network & internet → Internet → tap the gear beside the connected network. Some builds show signal strength directly; if yours does not, any Wi-Fi analyser app will read the dBm value.
3. Aim for -66 dBm or better. Treat -73 dBm as the wall, not the target. If you are at -70, you have no margin for a closed door or a parked car.
4. Turn mobile data off on the camera phone. It needs none to record and none to serve a live view to someone on the same network, and leaving it on is how a prepaid data pack disappears.
5. Start recording, lock the screen, and walk away for an hour. Then try the live view. This is the only test that matters, because the screen-off path is a different code path from the one you just set up under.
6. If it dropped: move the phone to put one fewer wall in the path before you buy anything. A metre of position is often worth more than a repeater, and it is free.
7. Re-test after any router change. Firmware updates re-enable band steering more often than you would expect.

What I could not establish

Honesty about the edges of this, because the numbers above are precise enough to sound more authoritative than they should:

• These thresholds are defaults, not guarantees. Every value quoted is an AOSP overlay (config_wifi_framework_wifi_score_low_rssi_threshold_24GHz and friends), which device manufacturers are free to change. Your handset may use different numbers, and there is no user-visible way to read what it actually uses.
• Android publishes no minimum signal strength for video streaming. The thresholds above govern network selection, not stream quality. I found no official page stating what RSSI a live video feed needs.
• Whether your phone runs an OEM network scorer is not discoverable from the settings UI. AOSP documents the interface; it does not document who ships one.
• The -66 dBm survey figure is Cisco's enterprise guidance, not an Android number, and not a promise about a phone.

None of that changes the practical advice. It changes how confidently anyone — including us — should state it.

What to do this week

Move the camera phone to 2.4 GHz, check the actual dBm from where it sits, and run the hour-long screen-off test. Those three steps resolve most "it keeps disconnecting" reports before any money is spent on hardware.

And keep the architecture in mind: a camera that records locally and serves its live view from the phone itself degrades gracefully. A bad Wi-Fi link costs you the picture for a while. It does not cost you the recording, and it does not depend on anyone's servers being up. More on that approach at superfunicular.com, and on the wider field in our roundup of free, no-subscription apps for a local-only camera.

Sources re-read on 2026-09-07: the AOSP Wi-Fi network selection page and Cisco's Wireless RF Reference Guide. Figures for our own app describe local recording and local live view; nothing here was measured in a controlled test by us, and no runtime or battery figure is claimed.