Almost every guide to running an old Android phone as a security camera — including the ones on this blog — ends at the same place. The live view works, you bookmark an address like 192.168.1.7:8080, and then a line appears telling you to go into your router's settings and reserve that address so the bookmark never breaks.
That advice is correct. It is also written for somebody who can log into the router.
A lot of people cannot. The connection in a rented room belongs to the landlord. The line into a shop belongs to the building. The box on the wall was installed by the operator and the operator kept the administrator account. In a joint household, one relative set it up years ago and nobody else has ever seen the password.
This guide is for that situation. You can still run the camera. You just have to solve the address problem from the phone's side, and one of the steps most often suggested for it turns out to be the wrong suspect.
What if you cannot open your router's admin page?
You can still run a phone as a camera, and nothing about the recording is affected. Recording is stored on the phone itself and does not involve the router at all. What you lose is one convenience: a permanent, never-changing address to type into a browser.
You replace it with three things, all free, all done on the phone:
- Learn to read the phone's current address off the phone itself, so you are never dependent on a bookmark.
- Keep the phone continuously on the network, which is what stops the address from rotating in the first place.
- Only if you need it, set the address manually on the phone — with a real caution attached, because on a network you do not administer this is the step that can go wrong.
The rest of this explains why the address moves, and why the fix people reach for first usually is not the cause.
Why does a phone camera's IP address change?
Because it was never yours. It was lent to you.
When your phone joins a Wi-Fi network, it does not choose its own address. It asks, and the router hands one out on a timer. The protocol that does this is DHCP, specified in RFC 2131, and the specification is unusually honest about how strong the promise is. The allocation mechanism, it says, "guarantees not to reallocate that address within the requested time and attempts to return the same network address each time the client requests an address."
Attempts is the entire word. There is a guarantee for the duration of the lease, and after that there is an attempt.
Most of the time the attempt succeeds, which is exactly why it is confusing when it fails. Your phone helps it along: when it rejoins a network it already knows, it does not start from scratch. It broadcasts a request naming the address it had before, and asks to have that one back. The specification calls this the INIT-REBOOT state, and the request "MUST be filled in with client's notion of its previously assigned address."
So the phone asks for its old address. The router usually says yes. The cases where it says no are the ones worth knowing:
- The lease ran out while the phone was off the network, and the address got handed to something else. RFC 2131 describes this directly: where addresses are scarce, "the allocation mechanism will reuse addresses whose lease has expired." Your address is now the television's.
- The router restarted and did not remember. Many consumer routers do not keep their lease table across a reboot. Where mains power is unreliable and the router restarts several times a week, this is not an edge case, it is Tuesday.
- The pool is busy. A connection shared between several flats or several shops cycles through addresses much faster than one household does.
Notice that all three are things happening on the router's side of the problem. Hold that thought.
Check the phone first: the setting people blame, and what the documentation actually says
There is a widely repeated idea that Android's MAC address randomization is what keeps changing your camera's address. The reasoning sounds right. A DHCP server recognises a returning client by its hardware address — RFC 2131 says "the combination of 'client identifier' or 'chaddr' and assigned network address constitute a unique identifier for the client's lease." Change the hardware address and you look like a stranger, so you get treated like one.
The reasoning is fine. The premise is usually wrong, and Android's own documentation is where you can check it.
Android has used a randomized MAC address by default since Android 10. But the Android Open Source Project's page on the behaviour is specific about which kind of randomization: "Android uses the persistent randomization type by default when MAC randomization is enabled." And a persistent randomized address is stable. The same page: "This MAC address remains the same until a factory reset. The MAC address doesn't get re-randomized if you forget and re-add the Wi-Fi network, because the MAC address depends on the network profile's parameters."
So on a normal home or shop Wi-Fi network, your phone is already presenting the same identity to the router every single time. It is not the thing shuffling your address.
There is one real exception, and it is worth thirty seconds of your time to rule out. Android 11 and higher has a global developer setting that switches every network to the non-persistent type, which re-randomizes at the start of a connection. AOSP documents where it lives: Settings > Developer Options > Wi-Fi non-persistent MAC randomization. It also documents exactly when re-randomization then happens — when "The DHCP lease duration has expired and more than 4 hours have elapsed since the device last disconnected from this network," or when "The current randomized MAC for the network profile was generated more than 24 hours ago."
Read those two conditions again with a 24/7 camera in mind. Both are about a device that has been away or idle. A camera that never leaves the network rarely meets either.
What to do: if Developer Options is switched on at all on that phone, check that setting and make sure it is off. If it is off, or Developer Options was never enabled, stop suspecting the phone. Your address is moving for one of the router-side reasons above, and the next section is where the actual work is.
There is also a per-network switch in the Wi-Fi details screen that turns randomization off entirely and reverts to the factory address. You almost certainly do not need it, and it makes the phone individually trackable on every network it ever joins, which is the thing randomization exists to prevent. Leave it alone.
The three things you can do without touching the router
1. Read the address off the phone, not off a bookmark
The address the phone is using right now is visible on the phone, in the Wi-Fi network's own details screen. The exact path and label differ between manufacturers and Android versions, so the reliable instruction is the shape rather than the steps: open Settings, go to the connected Wi-Fi network, and look at its details for the IPv4 address.
Treat that as the truth and the bookmark as a convenience. Once somebody in the household knows how to look it up, a changed address stops being a broken camera and becomes a ten-second correction.
2. Keep the phone on the network, continuously
Every failure path above begins with the phone being away. The lease expiring while the phone is elsewhere. Four hours since it last disconnected. Twenty-four hours since the profile was generated.
A camera is a device that never goes anywhere, which means it is unusually well placed to simply keep renewing the same lease forever. The practical version of this is dull and it works: do not toggle Wi-Fi or airplane mode on that phone, do not carry it out of range and back, and if it drops off after a power cut make sure it rejoins promptly rather than sitting unconnected for a day.
3. Set the address manually — carefully, and last
Android lets you switch a saved network from DHCP to a manually entered address, usually labelled Static or Manual in the network's IP settings. This does genuinely fix the problem, and it needs nothing from the router.
It is also the step that can take the phone off the network entirely, so here is the honest version of the trade.
When you set an address manually, you are claiming one. On a router you administer, you would look at the DHCP pool, pick something outside it, and know you were safe. On a router you cannot log into, you cannot see the pool. If you claim an address the router later leases to somebody's laptop, you get an address conflict, and the symptom is not a clear error — it is two devices intermittently losing the network. You also have to enter the gateway, the network prefix and DNS correctly yourself, and getting those wrong produces a phone that has Wi-Fi and reaches nothing.
So: try it only after the first two, only if the address really is rotating, and pick a high number in the range — routers commonly lease from the low end upward, though that is a tendency and not a rule you can rely on. Then leave the phone for a day and check it is still reachable before you trust it.
A test you can run this week
Do not wait to find out during an actual event. Make it happen on purpose, on an afternoon when nothing depends on the answer.
Write down the address the phone is showing. Turn Wi-Fi off on the camera phone, leave it off long enough to matter, then turn it back on and read the address again. Then do the harder one: after the next time the power goes out and the router restarts, check the address again.
Two readings tell you what your router does, which is the only thing that matters. Some hand back the same address for months. Some do not. Nobody can tell you which yours is from the outside, and it takes one afternoon to stop guessing.
What you give up, stated plainly
A camera you buy in a box never makes you learn any of this. It does not need an address on your network, because it opens a connection outward to the manufacturer's servers and you reach the picture through them. The address problem is solved by never having an address problem. That is a real convenience and it is worth naming rather than talking around.
What you trade for it is that the route to your own camera runs through a company — one that has to keep the service running, keep the app working, and keep charging somebody for it. A phone serving its own picture on your own network has neither the convenience nor the dependency.
If you cannot log into your router, you have a smaller version of the same choice. You give up a permanent address. You keep everything else: the recording stays on the phone, no account is involved, and nothing about the setup requires a card or a monthly payment.
Background Camera RemoteStream records with the screen off, keeps footage on the device rather than in anyone's cloud, and serves a live view from a built-in web server to any browser on your own network.
Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam
Site: https://superfunicular.com
Related reading
- Live View Stopped, Recording Did Not: Three Reasons an Old-Phone Security Camera Loses Its Stream on Patchy Internet — the other reasons a live view drops while the recording is unaffected.
- Can Two People Watch Your Old-Phone Camera at the Same Time? — what changes when more than one person needs the address.
- Why an Android Phone Can Record All Night and Still Be Unreachable — when the address is right and the phone still does not answer.
- How to Watch Your Shop With an Old Android Phone — No Internet Plan, No Subscription, No Credit Card — the full setup, for a connection you may not own.
Sources
- MAC randomization behavior — Android Open Source Project. Persistent vs non-persistent randomization, the default, the re-randomization conditions, and the developer-options path.
- RFC 2131, Dynamic Host Configuration Protocol — R. Droms, March 1997. Lease semantics, address reuse on expiry, the INIT-REBOOT request, and how a lease is identified.
Top comments (0)