DEV Community: Super Funicular

Which Faults Actually Disqualify an Old Phone From Camera Duty? A Triage List, Including the One We Get Wrong

Super Funicular — Mon, 21 Sep 2026 12:56:09 +0000

Short answer: The fault that quietly ruins the picture is the one nobody inspects: a scratch or hairline crack on the small window over the rear lens. It is filed as cosmetic because a phone lives in a pocket, and it turns every bright object in the scene into a permanent smear of scattered light in the same place in every frame. The fault that actually retires phones is the front display, and that is the one this job cares least about — though not for the reason we used to give here: what a setup session needs is a live touch layer, not a readable screen, and we corrected that ourselves. Below is a triage table for every common fault, a five-minute inspection you can do before committing a handset, and an honest note about the line we have been repeating that skips all of this. Apps like Background Camera RemoteStream run with the display off, which is exactly why the front-glass question turns out to be the easy one.

Almost every article about reusing an old handset as a camera says some version of "any old phone will do." Almost every article about buying one says "check for damage." Neither one tells you which damage, and the two are not the same list. A fault that makes a phone useless in a pocket can be irrelevant on a bracket, and a fault that nobody would return a phone for can wreck a picture permanently.

Here is the triage I would actually run.

The fault that ends a phone's life is the one this job does not use

A phone gets retired for its display more than for anything else. It is the largest, most exposed, most expensive-to-repair part, and once it is unreadable the device is unusable as a phone. So the pile of candidate camera handsets is heavily weighted towards cracked fronts.

For this job that is close to the best possible news. A camera setup runs with the display off — that is the entire premise of leaving a phone recording for weeks — so the condition of the front glass stops mattering the moment setup is finished. What you need is:

Enough of the touch layer alive to complete setup once — which is the binding requirement, not legibility.
Nothing loose enough to fall out of the frame or short something.

That is it. Cracks, dead pixels, colour shifts, a dim backlight, burn-in from a previous life as a dashboard: none of them affect a single frame of recorded video, because none of them are in the optical path. The picture is made by a sensor behind a different piece of glass entirely.

There is one distinction inside this that matters more than the crack itself: broken glass and a dead touch layer are different faults. Spiderwebbed glass that still registers taps is fine. A panel that shows an image but ignores your finger, or a panel that is simply black, is a phone you cannot configure by hand — but it is not a dead end. A wired mouse through a USB-OTG adapter gives you a pointer: Android has supported USB host mode since 3.1, no drivers, and it works on a locked phone. We walked that through, case by case, in a separate piece on setting up a handset you cannot touch.

The piece of glass nobody inspects

Now the other side. There is a small protective window over the rear camera, and it takes exactly the same impacts as the rest of the device. When it chips, scratches or crazes, three things happen at once:

Bright objects smear. Any strong light source in the scene — a bulb, a bright doorway, headlights turning in — gets scattered by the damage instead of passing cleanly through. You get a haze, a streak or a starburst radiating from that light.
It happens in the same place every time. Unlike a smudge you can wipe, the damage is fixed relative to the sensor, so the artefact lands on the same part of the frame in every single frame, all day, for as long as the setup runs.
Contrast falls across the whole image. Scattered light does not only make a streak; it lifts the dark parts of the picture towards grey, which is precisely where the detail you wanted was hiding.

None of this shows up in the way people usually check a phone. A quick snapshot in even indoor lighting can look completely normal. It shows up when there is a strong light in view, which describes most of the situations a camera is pointed at: a door onto daylight, a window, a driveway at dusk, a room with a lamp in the corner.

And crucially, nobody who later looks at that footage says "the lens window is chipped." They say the camera is bad.

Triage table

Fault	Verdict for camera duty	Why
Cracked or shattered front glass, touch still works	Fine	Display is dark the whole time. Needs to survive one setup session.
Display black or touch layer dead	Workable	Not in the optical path. Setup runs off a wired mouse on a USB-OTG adapter, which works even on a locked phone.
Scratch, chip or crack on the rear camera window	Usually disqualifying	Permanent scattered light in a fixed place in every frame; kills contrast around any bright object.
Greasy or hazy rear window, no physical damage	Free to fix	A wipe. Do this before judging any picture, including one you are using to judge a phone you are buying.
Known water exposure in its history	Treat as unknown, not as a pass	Corrosion is slow and cannot be inspected from outside. It may run for years. It is not a device to put somewhere that matters and forget.
Battery will not hold a charge	Less decisive here than elsewhere	The device lives on a cable for this job. There is a lot written about phone batteries already and I am not going to re-run it here.
Missing SIM tray, no service, carrier-locked	Irrelevant	The network story for this setup is Wi-Fi. A handset with no service is still a computer with a camera in it.
Dead speaker or microphone	Depends entirely on whether you want sound	Silent video is a complete answer for many uses and useless for others. Decide before, not after.
Dead power button	Real nuisance	A device you cannot restart by hand is a device that needs a plan for the day it needs restarting.

The five-minute inspection

1. Wipe the rear window with a soft cloth. Do this FIRST — half of
   what looks like damage is a fingerprint from years in a pocket.
2. Hold the rear window at an angle under a bright light and rotate it.
   Scratches are almost invisible face-on and obvious at a glancing angle.
3. Open any camera app and point it at a lit bulb from a few metres away,
   with the rest of the room dim. Damage that hides in daylight is
   unmissable here: streaks and haloes radiating from the light.
4. Take one frame of the actual scene you plan to watch, and look at it
   on the largest screen you own — not on the phone. A phone display
   flatters everything.
5. Only now check the front: can you read enough of it, and does it
   respond to touch, to get through a setup once?

Step three is the whole test. If a phone passes step three, the rest of its cosmetic history is mostly irrelevant to this job.

An honest note about our own line

The line we have repeated more than any other is that the broken old phone somebody was told to recycle still films better than a cheap camera. I still think it is broadly right, and it is true of the specific break that put most of those phones out of service — the front one.

It is not true of all of them, and we have never said which. A phone with a chipped rear window will produce a worse picture than a cheap dedicated camera in exactly the situations you bought a camera for, and no software fixes it, ours included. Repeating a cheerful generalisation without the exception is how people end up disappointed by the right idea.

The exception is one sentence long and it belongs next to the claim every time it is made: check the small window, not the big one.

What this list deliberately does not settle

It does not tell you whether a given handset is fast enough, has enough storage, or will get warm where you want to put it. Those are real questions with real answers and they are not damage questions. This is only the triage for a device that has already been dropped, which is most of the devices anybody is considering for this.

It also cannot tell you about corrosion, board-level damage, or anything else that lives under the case. Nobody can, from the outside. The honest handling of that is not a confident verdict but a placement decision: a device with an unknown internal history goes somewhere you will notice it stopping, not somewhere you are relying on it silently for months.

What to do this week

If there is a retired handset in the house you have been meaning to put to work, do step one and step three above tonight. Five minutes with a cloth and a lamp will tell you whether you have a good camera or a permanently hazy one, and it will tell you before you have chosen a spot, run a cable and started trusting the thing.

More at superfunicular.com, and the app is Background Camera RemoteStream on Google Play.

The Loopback Line: Why a Phone Serving Its Own Camera Page Gets Fewer Browser APIs Than localhost

Super Funicular — Mon, 21 Sep 2026 07:18:34 +0000

You set up an old Android phone as a camera. It records with the screen off, and it runs a small web server so you can open the picture in a browser on your laptop. You type http://192.168.1.42:8080, the feed comes up, and everything works.

Then you notice three things that don't.

The page cannot keep your laptop screen awake while you watch. It cannot register a service worker, so it re-fetches its own shell every single time. And if you try to embed that feed in any dashboard you host over HTTPS, the frame stays empty — not slow, not broken, empty.

None of these are bugs in the server. They are not bugs in the browser either. They are all the same decision, made once, in a specification that never mentions your phone, your network, or private IP addresses at all.

I went looking for the sentence that causes it. The interesting part turned out to be a sentence that isn't there.

The line itself

The W3C Secure Contexts specification defines whether an origin is "potentially trustworthy." Browsers use that one boolean to gate a large set of web APIs. The algorithm is short. In order, an origin is trustworthy if:

Its scheme is https or wss.
Its host matches the CIDR notations 127.0.0.0/8 or ::1/128.
Its host is localhost, localhost., or ends in .localhost / .localhost. — but only "If the user agent conforms to the name resolution rules in [let-localhost-be-localhost]."
Its scheme is file (a SHOULD, not a MUST).
Its scheme is one the user agent considers authenticated, such as chrome-extension:.
It "has been configured as a trustworthy origin."

Otherwise: Not Trustworthy.

Two details in that list are worth slowing down for, because most summaries get them wrong.

The loopback CIDR is unconditional. 127.0.0.1 is trustworthy, full stop. The name localhost is not — it depends on the user agent following particular name-resolution rules, and §5.2 softens it further to a MAY. People say "localhost is a secure context" as if the two were the same rule. They aren't.

And the spec is explicit that the usual levers don't apply: "Neither origin's domain nor port has any effect on whether or not it is considered to be a secure context." Moving your server from 8080 to 8443 changes nothing. It was never about the port.

The sentence that isn't there

Here is the part I actually went to check, because I expected to find a carve-out and an argument about why it was narrow.

There is no carve-out. There is no argument.

I searched the Secure Contexts document for 192.168, 10.0.0.0, RFC1918, "private IP", "private network", "intranet", and 169.254. Every one of them returns zero occurrences. The only CIDR notations in the entire specification are 127.0.0.0/8 and ::1/128.

Private network addresses are not excluded by a rule. They simply fall off the end of the list into step 8, Not Trustworthy, alongside every plain-HTTP address on the public internet. The spec does not discuss them, does not note them as a known gap, and does not leave an issue open about them.

The one remaining route is §7.2, and it is a manual one:

"In order to support developers who run staging servers on non-loopback hosts, the user agent MAY allow users to configure specific sets of origins as trustworthy"

That is a per-user, per-browser, per-machine setting intended for development. It is not something a device on your network can earn, negotiate, or opt into. Every person who ever opens the page would have to set it themselves, in their own browser.

So there is a line, and it runs in a strange place. I've started calling it the loopback line: the boundary between a server talking to itself and the same server talking to the machine next to it.

A phone that serves its camera page to itself is on the trusted side. The instant that identical page — same code, same server, same process, same device — is served to a laptop one hop away, it lands on the untrusted side. Nothing about the software changed. The only thing that changed is that the bytes left the device.

Which is, of course, the entire point of a camera.

What lands on the untrusted side of the line

"Not a secure context" is abstract until you list what it costs. MDN maintains the list of features restricted to secure contexts. For a LAN camera page, these are the ones that bite:

Service workers. Gone. The Secure Contexts spec is blunt: "Only secure contexts may register them." No offline shell, no cached UI, no graceful behaviour when the phone briefly drops off Wi-Fi. Every load is a cold load.

Notifications. Gone. The viewer page cannot raise a desktop notification, which rules out a whole category of "tell me when the feed drops" built in the page itself.

crypto.subtle. Gone — and here is a precision worth keeping, because it's easy to overclaim. It is crypto.subtle that requires a secure context. crypto.getRandomValues() and crypto.randomUUID() do not. "Web Crypto needs HTTPS" is too broad a statement; the subtle-crypto interface is the part that's gated.

getUserMedia(). Gone. MDN lists it separately from the main table, under methods that "require a secure context (even if the associated API does not)." So the LAN page cannot open a camera of its own — relevant the moment you imagine two-way anything.

Screen Wake Lock. Gone. And this is the one I keep turning over.

The Screen Wake Lock API is how a web page asks the browser not to let the display sleep. It exists almost entirely for pages you watch without touching: recipes, dashboards, sheet music, live feeds. It is precisely, exactly the API a camera viewer wants.

A LAN camera page cannot have it. The page whose entire job is to stay visible is denied the one API about staying visible.

There's a symmetry here that I find genuinely funny, in a bleak way. On the recording end, the thing that makes screen-off capture work at all is an Android partial wake lock held by a foreground service — keep the CPU running, let the display die. I've written about that machinery in the context of how Chrome treats a camera tab you walk away from. The recorder fights to keep the CPU awake while the screen sleeps. The viewer wants to keep the screen awake — and is told it hasn't earned the right to ask.

Two wake locks, opposite goals, and only one of them is available to you.

Mixed content, and the trap in the middle of it

The second symptom — the empty iframe — is a different mechanism with the same root.

If you serve any page over HTTPS and it tries to pull a subresource over plain HTTP, that's mixed content. Current browser behaviour splits it into upgradable and blockable content. Scripts, fetch(), XMLHttpRequest, stylesheets, fonts, <object>, sendBeacon and <iframe> sources are all blockable — they fail, they are not retried over HTTP.

Images, audio and video are the upgradable category. The browser rewrites the request to HTTPS and tries again. Which sounds like a loophole: serve an MJPEG snapshot as an <img> and let it upgrade.

It doesn't work, and the reason is a carve-out that's easy to miss. From MDN's mixed content page:

"Mixed content requests that would otherwise be upgraded are blocked if the URL's host is an IP address rather than a domain name."

An upgrade to HTTPS only makes sense if there's a name that could plausibly have a certificate. 192.168.1.42 is an IP literal, so <img src="http://192.168.1.42/snapshot.jpg"> on an HTTPS page is blocked, not upgraded. The category that was supposed to be the lenient one is, for your camera specifically, the strict one.

One more piece of precision, since this is the kind of thing that gets repeated wrongly for years. The "upgradable/blockable" vocabulary is from Mixed Content Level 2, which states that "Upgradeable content was previously referred as optionally-blockable." Level 2 is a First Public Working Draft from October 2020. The CR-level published document is still Level 1, which uses the older "optionally-blockable" wording. If you cite this, cite the level.

And a confirmed absence, because I looked: Mixed Content Level 2 contains zero occurrences of the word "iframe." It reaches iframes through its algorithm — it permits a request whose "destination is 'document', and request's target browsing context has no parent browsing context", i.e. top-level navigations only. A framed document falls through to blocked. MDN says "iframes are blocked" in plain words; the spec never does.

What changed in 2026, and why it doesn't rescue you

For a few years the expected fix for all of this was Private Network Access — a scheme where a public page wanting to reach a private address would send a CORS preflight carrying Access-Control-Request-Private-Network: true, and the local device would answer with Access-Control-Allow-Private-Network: true.

Two corrections, because I nearly wrote this section as current behaviour and it isn't.

First, PNA is a WICG Draft Community Group Report. In its own words: "It is not a W3C Standard nor is it on the W3C Standards Track."

Second, and more importantly: Chrome does not enforce it. From Chrome's own PNA on hold post: "PNA preflights are not currently enforced," the Chrome 130 rollout having been halted over compatibility problems. Anything you read describing that preflight as live browser behaviour is out of date.

What replaced it is Local Network Access, a permission prompt rather than a preflight — "Local Network Access replaces that effort, after PNA was put on hold."

Now look at the shape of it, because the shape is the whole story. LNA is a permission that a page asks for in order to reach into your local network. And "the ability to request this permission is restricted to secure contexts."

So the direction of travel is: an HTTPS page, already trusted, may ask your permission to reach your camera. Your camera's own page, serving from your own network, gains nothing. It is still not a secure context, still cannot register a service worker, still cannot hold a screen wake lock.

The platform is building a door for traffic coming in from the public web. It is not building one for a device on your LAN that wants to be trusted by the machine next to it. If anything, the asymmetry is widening: the capability now flows toward origins that already have certificates.

(This is the browser's half of the story. The operating system has its own, separate story about apps reaching LAN devices — different mechanism, different gate, and not what any of the above describes.)

So why not just serve HTTPS?

Because the certificate model and a phone on your living-room Wi-Fi were designed for different worlds, and a public CA will not issue a certificate for a private IP address. I've written that argument out properly in the LAN threat model for a phone-as-camera server, including why a self-signed certificate trades one problem for a worse habit, so I won't re-run it here.

The relevant point for this article is narrower: even if you solved the transport question, you would be solving it to recover browser APIs, not to protect an already-local link. That's a strange thing to spend a user's trust on.

The design consequence

Once you accept that the viewer page lives permanently on the untrusted side of the loopback line, a lot of architectural decisions stop being decisions.

You build the console as a self-contained page with no secure-context dependencies. No service worker, so no offline shell — the page has to be small enough that a cold load is cheap. No wake lock, so if a user wants the screen to stay on while they watch, that's a setting on their own device, and the honest thing is to say so rather than to ship a button that silently fails. No notifications from the page, so status has to be visible in the page.

And the transport has to be something a plain, unprivileged browser context does natively and well: direct HTTP, an MJPEG or similar stream for live view, and ordinary byte-range requests for recorded files. That last one is less boring than it sounds — the Range header does most of the work of seeking in a recording, which is exactly the kind of capability that survives on the untrusted side because it was never gated in the first place. The embedded-server side of this, on Ktor, I've taken apart separately.

The result looks austere next to a cloud camera's web app. That austerity isn't a shortcut. It's the shape of what remains after you remove everything a non-secure context isn't allowed to touch.

This is the architecture behind Background Camera RemoteStream — an Android app that records with the screen off and serves its own feed over your LAN from a built-in web server, with no cloud account in the path. The design constraints above are not incidental to that; they're most of why the viewer looks the way it does.

The honest trade

A vendor camera with a cloud dashboard has none of these problems, and it's worth being clear about why: their dashboard is served from a domain they own, over HTTPS, with a certificate they renew. It's a secure context. It gets service workers, notifications, wake lock, the lot. That's a real advantage and there's no point pretending otherwise.

What it costs is that the picture goes to their server so that their page can be trusted by your browser. The trust is real, and it's rented.

A phone on your own network keeps the picture where it is and pays for it in browser capabilities — a page that must be simple, stateless between loads, and unable to ask your laptop for much of anything.

I don't think that's a bad trade. But I'd rather explain it as a trade than let someone discover it as a series of small unexplained failures, which is how almost everyone meets the loopback line for the first time.

Background Camera RemoteStream — record with the screen off, stream to YouTube Live, view remotely over your LAN from a built-in web server, with local-only storage.

Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam
Site: https://superfunicular.com

Specification text quoted above was read from the linked primary sources: W3C Secure Contexts, W3C Mixed Content Level 2, the WICG Private Network Access draft, MDN, and Chrome's developer blog. Where a document is a draft rather than a standard, I've said so inline, because the status turned out to matter more than once.

The Offence Is the Listening, Not the Recording: A Real Estate Commission's Own Answer on Cameras During a Showing

Super Funicular — Mon, 21 Sep 2026 06:56:11 +0000

Short answer: The federal wiretap chapter defines its central verb around acquiring a conversation, not around saving one. A state licensing regulator has published what that means for a house on the market: a seller may run video with the microphone off, and a seller who listens live has intercepted the conversation even where no file was produced. Switching off recording is a smaller fix than it sounds, because it is aimed at the wrong half of the device.

A spare handset running as a camera is set up for an empty house. That is the assumption underneath most advice about it: nobody is home, the interesting event is an intrusion, and the useful output is a file you look at afterwards.

Putting the house on the market inverts each of those in the same week. The house is occupied, by appointment, by people the owner has not met. The owner is the one who is out. And the interesting event is no longer an intrusion; it is two people walking from room to room talking to each other about the place, and about what they might pay for it. The camera has not changed. Everything around it has.

Two documents carry most of the weight here, and they point the same way.

The federal definition is built around acquisition, not storage

The definitions section of the federal wiretap chapter, 18 U.S.C. § 2510, says that to intercept means "the aural or other acquisition of the contents of any wire, electronic, or oral communication through the use of any electronic, mechanical, or other device."

Read the first four words before the rest of it. Aural acquisition. Hearing is a way of acquiring. There is no mention of a file, a copy, a disk, a retention period, or a duration. The verb the whole chapter is built on describes something that is finished at the moment a person understands what was said.

The word order is not an accident of drafting, and the statute's own amendment history says so. As enacted in 1968 the definition read aural acquisition and stopped there. The words or other were inserted eighteen years later, by the Electronic Communications Privacy Act of 1986, in the same amendment that added electronic to the list of communications it covers. Hearing was not one option among several that a later Congress trimmed down to. Hearing was the whole of it, and the rest was added on top. The findings published with the 1968 Act use the plainer word: intercepting devices, Congress wrote there, were being used "to overhear oral conversations made in private".

The definition of the device that does the acquiring is drawn just as wide, which you can tell from what had to be written out of it. The list of things that are excluded runs to ordinary telephone equipment used in the ordinary course of business, and then to "a hearing aid or similar device being used to correct subnormal hearing to not better than normal". Congress had to carve out a hearing aid. That is the size of the net a drafter thought they were casting, and a phone on a shelf sits well inside it.

None of that makes hearing your visitors unlawful on its own. The chapter turns on consent, and state statutes differ in how many parties have to agree; the one below describes its own Act as requiring the consent of at least one party to the conversation. The question is therefore not whether a device recorded. It is whether the person listening was a party, or had a party's agreement.

A licensing regulator answers the question directly

The North Carolina Real Estate Commission is the body that issues and removes the licences of brokers in that state, so its bulletins are written to be followed rather than debated. In a September 2023 bulletin for brokers, it walks through the federal prohibition at 18 U.S.C. § 2511 and notes, in its own words, that "This federal statute also prohibits the interception of oral communication, whether it is recorded or not." It then adds the carve-out that the rest of the piece depends on: a person is not in breach where state law permits hearing an oral communication and a party to the conversation has consented.

Then it asks the question a seller would ask, and answers it without hedging. Is it permissible for a seller to either listen to or record a conversation between a potential buyer and their agent?

"No. It is not permissible for a seller to listen in or record a conversation between a potential buyer and their agent because the seller is not a party to the conversation and they have not obtained the written consent of one of the parties."

The reasoning is the part worth carrying away, because it survives the trip to other states even though the conclusion might not. The seller is absent from the conversation. The seller is therefore not the party whose consent a one-party state would accept. And the buyer's own agent, who is a party, has not been asked. A statute that would have been satisfied by one person in the room agreeing is left with nobody who agreed.

The sentence that reaches a phone

The bulletin then does something documents of its kind mostly avoid. It names hardware:

"Although baby monitors and walkie-talkies do not record the conversation, the conversation is still being intercepted by the seller without the consent of the parties."

The bulletin has just told brokers that sellers should not use non-recording audio devices like walkie-talkies or baby monitors. A baby monitor stores nothing. A walkie-talkie stores nothing. They are named anyway, because the thing the statute describes has already happened by the time the sound reaches a speaker somewhere else.

That sentence is written about a nursery gadget from a previous decade, and it lands on a category of software feature that did not exist when the gadget did. A live view with sound, a listen button, a talk-back channel, a remote stream you can hear as well as see: whatever a given app calls it, the described behaviour is the same one. Sound leaves a room the owner is not standing in and arrives somewhere the owner is. The bulletin does not have to mention phones to have described what a phone does.

The video half is left standing

This is not an argument for taking the camera down, and the Commission's own answer to the video question is yes, with conditions: "the seller should exercise caution regarding the placement of the device to ensure a person's privacy is not violated and the audio is turned off". Its own summary of the state Electronic Surveillance Act is that the Act is addressed to oral and electronic communications rather than to video surveillance, which is why the two halves of the same handset land in different places.

The conditions are not decorative. Placement is doing real work in that sentence, and the bulletin gives the obvious example of a room a camera has no business pointing into, a bathroom. It also warns brokers that a seller who tries to gather confidential information about a buyer by listening to their conversation is exposed to criminal or civil liability, which is a different and larger hazard than a tidy question about consent.

And the Commission goes further than the conclusion this piece is heading for. Having said that video without audio is permissible, it recommends that brokers advise their sellers not to use any device as a means to attempt to gain information about potential buyers or their agents. That is a recommendation about the purpose the hardware is put to, not about which of its two inputs is switched on, and it is wider than the fix described below. It should be said plainly rather than left out: the regulator's advice goes past the line this piece stops at.

Why the obvious fix is the wrong one

Somebody who has read this far and is selling a house will reach for the same control that everyone reaches for. Turn off recording. Keep the live view so the house is still watched, and stop writing files while strangers are inside.

On the reading above, that control is pointed at the wrong half. It stops the artefact and leaves the acquisition running. The federal definition is satisfied by the aural acquisition itself, and the bulletin says out loud that a device which stores nothing is still intercepting. A setting that makes the evidence disappear and leaves the conduct in place is worse than no setting at all, because it feels like having done something.

The control that matches the documents is the microphone, and it is a different switch. Sound off, video on, and the two halves of the handset are once again in the two different places the Act puts them.

What this does not settle

One state's regulator reading one state's statute is not a national rule, and it would be dishonest to present it as one. The federal chapter is generally read as a floor that a state may build on, and states differ on how many parties to a conversation have to agree before somebody else may listen. The definition of an oral communication in the federal chapter itself turns on whether the speaker was exhibiting an expectation that the words would not be intercepted, and under circumstances that justify it, which is a question about the room rather than about the statute.

What travels is the distinction, not the verdict. Wherever you are, the question the documents ask is who was party to the conversation, and the question they do not ask is whether a file exists.

What to do with this

Read the two halves of the handset as two different legal objects, because that is what the documents do. We have made the same split from the Android side, where the camera and the microphone are separate permissions and the audio one is the stricter: why the microphone is a different permission from the camera. What is new here is the direction of travel. That piece reasons outwards from the operating system; a regulator writing about somebody's living room arrives at the same line inwards from a statute.
The consent count is a state-by-state fact, and it is the fact everything above turns on. Settle it before a showing is booked rather than during one, and settle it from a real estate commission bulletin rather than a forum, because a regulator publishes what it is prepared to act on.
Tell the listing agent, in writing, what devices are on the property and where they point. The agent has professional exposure of their own here, and a written note converts a surprise into a disclosure.
Point the lens where the people you meant to watch would actually be. The doors and the perimeter were the reason the camera went up; the room where two visitors stand talking was not.
Resist watching a showing live. The temptation is the point of the feature, and it is also the conduct the bulletin describes.

What I could not verify

Whether any enforcement has actually followed from a seller listening during a showing. I found the regulator's position; I did not find a disciplinary case turning on it, and I would rather record the gap than imply a body of precedent I did not read.
How the other states come out. I read one state's regulator and the federal definitions section, and I did not work through the rest. I am not going to point you at a survey I have not opened.
Whether a house being shown commercially weakens the expectation of privacy that the federal definition of an oral communication rests on. It is the obvious counter-argument to everything above, the text does not resolve it, and I found nothing that settled it either way.

None of this is legal advice and I am not a lawyer. It is a reading of two public documents, aimed at people whose camera happens to be a phone and who are about to let strangers walk past it.

Try it: Background Camera RemoteStream on Google Play -- record with the screen off, keep footage on the device, watch it over your own network. More of these readings live at notes on running an old phone as a camera.

Sources. the North Carolina Real Estate Commission on audio and video equipment during showings, and the definitions section of the federal wiretap chapter on Cornell LII. Quotations from the definitions section are verbatim statutory text as published, and the 1986 insertion of or other and the 1968 congressional findings are quoted from the editorial and statutory notes on that same page; quotations from the bulletin are the Commission's own words, including its answers to its own questions. Consent is the hinge, and it swings on whether anyone in that room grasped that somebody outside it was within earshot.

Why Your Phone Security Camera Uses Mobile Data on Shared Wi-Fi - Captive Portals, Explained

Super Funicular — Sun, 20 Sep 2026 21:41:48 +0000

Your old phone is mounted in the corner of the shop, recording. It is connected to the shop's Wi-Fi — the icon is there, full bars. And at the end of the month the mobile bill on that phone is higher than it has ever been, on a handset nobody carries and nobody uses.

The Wi-Fi is connected. The Wi-Fi is just not, as far as Android is concerned, working.

This is one of the most common and least explained situations in a phone-as-camera setup, and it is almost always the same thing: the network has a captive portal — the sign-in page that shops, hostels, guesthouses, cafés, offices and apartment buildings put in front of their Wi-Fi. Android has a specific, documented opinion about networks like that, and once you know what the opinion is, the behaviour stops being mysterious and becomes something you can plan around.

Why does my phone security camera use mobile data when it is connected to Wi-Fi?

Because "connected to Wi-Fi" and "this Wi-Fi can reach the internet" are two different facts, and Android tracks them separately. A network behind a sign-in page is connected but not validated, and Android's default routing prefers a network that is validated. So anything on the phone that wants the internet — including a live stream going out to YouTube — can quietly go out over mobile data instead, while the Wi-Fi sits there looking perfectly healthy.

The part that matters for a camera: this does not affect a live view that is served from the phone itself. Background Camera RemoteStream runs a small web server on the phone, so when you open the camera's address from a laptop or another phone on the same Wi-Fi, that traffic never needs the internet at all. It never leaves the local network. A captive portal can block the path to the outside world and leave the path across the room completely untouched.

That split — local works, outbound does not — is the whole story, and the rest of this piece is why.

Android tracks two separate bits, and most people only know about one

When Android connects to a network, it records a set of capabilities for it. Two of them are doing the work here.

The first is NET_CAPABILITY_INTERNET. The reference page describes it in a single sentence: it indicates that the network "should be able to reach the internet." Note the word should. Android's own connectivity guide is blunter about it — this capability is, in its words, "about setup and not actual ability to reach public servers," and a network can carry it and still "be subject to a captive portal."

The second is NET_CAPABILITY_VALIDATED, and this is the one that reflects reality. It means connectivity on the network "was successfully validated" — Android actually probed it and something answered. The Read network state page states the consequence directly: a network behind a captive portal "doesn't have this capability."

The class documentation for NetworkCapabilities puts the pair together in a line worth keeping: a network "may or may not actually provide connectivity," and apps that care about real connectivity "should usually look at both these capabilities."

So the shop Wi-Fi your camera phone is sitting on has the first bit and not the second. It is set up to reach the internet. It cannot currently reach the internet. Both are true, and the Wi-Fi icon shows you neither.

There is a third capability in play too: NET_CAPABILITY_CAPTIVE_PORTAL, which Android sets when a network "was found to have a captive portal in place last time it was probed." That phrase — last time it was probed — is doing quiet work, and we will come back to it.

What Android does about it

Once a network is unvalidated, Android has to decide where your traffic actually goes, and this is where the mobile bill comes from.

Every app has a default network, and the connectivity guide says plainly that it "is determined by the system," that the system "typically prefers unmetered networks to metered ones and faster networks to slower ones," and — the sentence to underline — that "the network that is set as the default network can change at any time."

A Wi-Fi network that failed validation is not a good candidate for carrying internet traffic, because as far as the system can tell it does not carry internet traffic. Mobile data, which validated fine, is. So the default moves.

Nothing on the phone announces this. There is no error, no dropped connection, no state the app can show you. The recording keeps recording. The Wi-Fi stays connected. Traffic that needs the outside world simply leaves by a different, metered door.

Android does surface the situation once, to the user, through ACTION_CAPTIVE_PORTAL_SIGN_IN — the "sign in to network" notification. The ConnectivityManager reference describes the trigger as a device that "has connected to a network that has presented a captive portal," one "which is blocking Internet connectivity." That notification is the system's one and only attempt to get a human involved.

On a phone that is mounted in a corner with its screen off and nobody looking at it, that notification is seen by no one.

The part I did not expect: you cannot ask for a network that works

This is the detail that reframed the whole problem for me, and it is sitting in plain sight in the ConnectivityManager reference.

You would reasonably assume that an app which needs real internet could simply ask for one — build a NetworkRequest that says give me a network that is validated and not behind a portal, hand it to requestNetwork, and let the platform sort it out. The API looks like it is shaped for exactly that. requestNetwork will "attempt to find the best network that matches the passed NetworkRequest" and will even try "to bring up one that does if none currently satisfies the criteria."

It does not work, and the documentation says why. It is, in the reference's words, "presently unsupported to request a network with mutable NetworkCapabilities" — capabilities that describe states a network "may never attain," because the framework "does not know how to go about satisfying a request with these capabilities."

Validation is mutable. Captive-portal status is mutable. They change based on what happens out on the network, not on anything the device controls. So they cannot go into a request.

You can only read those bits off a network you already have. There is no way to ask the system for the Wi-Fi that works. There is only connecting, finding out, and reacting. Every app on the phone is in the same position, which is worth knowing before you assume yours is broken: this is not a limitation any camera app chose.

And the platform is explicit that it stays in charge regardless — network selection is made "at its own discretion," and a network that no longer matches any request "may be disconnected at any time."

The "Ignore" button is a bigger decision than it looks

Somebody sets the camera up, the sign-in notification appears, they are busy, they dismiss it. On many builds, dismissing that prompt is not a neutral act.

The CaptivePortal class exists so the sign-in screen can tell the system how things went, and one of its two meaningful methods is ignoreNetwork(). The documentation describes it as the case where "the user does not want to pursue signing in to the captive portal," and then states two consequences. The system "should continue to prefer other networks without captive portals" — that is the mobile-data preference, now made sticky. And: "The system will not retest the network for a captive portal."

It will not retest. So even after somebody signs the network in later from a different device, or the portal is removed entirely, that phone may go on treating that Wi-Fi as second-class.

The other method is the way back: reportCaptivePortalDismissed(), after which "the framework will re-evaluate the network's connectivity and might take further action." That is what a successful sign-in triggers. If you are in the "everything looks connected and nothing works" state, forgetting the network and rejoining it from scratch is the crude version of the same thing, and it is usually the fastest fix available from the glass.

The two-network test

Here is a check you can run in a few minutes, on any phone, with no app-specific knowledge and nothing to install. Call it the two-network test. Its whole purpose is to separate the camera is broken from the internet path is broken, which are constantly mistaken for each other.

Set the camera up where it will actually live, on the Wi-Fi it will actually use. Start recording.
On the camera phone, turn mobile data off entirely. Leave Wi-Fi on. You have now removed the escape route, so anything that still works is genuinely working over that Wi-Fi.
From a second device on the same Wi-Fi — a laptop, another phone — open the camera's local address and confirm you get a picture. If you do, the recorder, the Wi-Fi association and the local path are all healthy. This is the half that a captive portal does not touch.
Now, on the camera phone, open any browser and load a site you have never visited from that phone. If a sign-in page appears instead, that network has a portal. If the page simply fails, the network has no working internet at all.
Turn mobile data back on only if you actually want it on. On a metered or prepaid plan, consider leaving it off for the life of the camera.

Step 5 is the one that saves money, and it is the one people skip. A camera phone that has no mobile data cannot spend mobile data. If the only thing you need from it is a live view on the same Wi-Fi and files stored locally, it does not need a working internet connection at all — and turning the radio off converts a silent, open-ended cost into a known zero.

Where this bites hardest

Some of this is specific to how you are set up, and it is worth being direct about which situations actually suffer.

A shop, a stall, a workshop, a guesthouse, a shared building. These are exactly the networks that run portals, and they are also exactly the places where a spare phone as a camera makes the most sense. The portal is not a misconfiguration; it is the point. Someone wants a tap-through before customers get online.

Prepaid and metered data. If the phone has a SIM with credit on it, an unvalidated Wi-Fi turns that credit into the fallback path for anything outbound. The cost is invisible until the balance is gone, because nothing failed — traffic was carried, successfully, by the expensive radio.

Anything going out to the internet. Streaming to YouTube Live genuinely needs real, validated internet; a portal blocks it and no local architecture can rescue that. If outbound streaming is the reason you set this up, the portal is a real blocker and the answer is a network without one.

Local-only setups are barely affected. If what you want is an offline security camera — recording to the phone, viewed from across the room or across the building on the same Wi-Fi — a captive portal is mostly a non-event. The live view is served by the phone. The recordings are on the phone. Neither one asks the internet for permission. That is a consequence of the architecture rather than a feature anyone added: when there is no cloud in the path, there is no cloud outage, no account check, and nothing that stops working because a sign-in page is in the way.

The practical setup order

If you are putting a phone camera on a network you do not control, this order will save you an evening:

Join the Wi-Fi and complete the sign-in page first, on the camera phone itself, before you mount anything. Do not dismiss the notification.
Then decide about mobile data. Off is the safe default for a camera. On is a choice you should make deliberately, knowing it is the fallback path.
Then run the two-network test, so you know which half of the system works before you need it to.
Prefer a network without a portal if you have the option — a home router, or a phone hotspot you control. Portals are built for humans with screens who tap things, and a mounted camera is neither.

None of this requires changing how the camera works. It requires knowing that Android is making a routing decision on your behalf, based on a bit you cannot see, on a network you did not configure.

If you want to go further on the adjacent failure modes: what actually happens to a phone camera during a power cut or an internet outage covers why those two are not the same event; live view stopped, recording did not walks the three reasons the stream goes and the files keep coming; and if outbound streaming is what you are after, streaming to YouTube Live from an Android phone with the screen off runs that whole path end to end.

Background Camera RemoteStream records with the screen off, stores everything locally on the device, and serves its live view from a web server running on the phone itself — so the across-the-room path does not depend on the internet being reachable.

Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam
Site: https://superfunicular.com

Documentation references throughout are to Android's public developer documentation, linked inline. The behaviour described is platform behaviour and applies to any app on the device, not only to ours.

This week on @Digital_Nomad_Media — 25 new clips (2026-W38)

Super Funicular — Sun, 20 Sep 2026 14:03:58 +0000

Quick weekly digest from my YouTube channel — every clip below is fresh in the last 7 days.

Everybody already knew it was going to end under a bridge ✌️🤠

39s

Hi I'm Digi Nomad

37s

It's pretty good weather in Michigan right now. ✌️🤠

10s

We gotta restart it

24s

I'll give this girl any damn thing she wants. Lady the Pitbull

25s

Silver platter delivery

24s

Bet ✌️🤠

Dat wus fast

32s

Conspiracy ✌️🤠

14s

Take 37

45s

lost my cameras

60s

Ride hard in The wind

15s

I feel like George Jetson ☝️

15s

I'm sorry ok!

15s

May 23, 2024

15s

Somebody save the poor man ✌️🤠 #

Bugs

The difference between driving and RIDING

12s

Arriving at the breadbasket of Rome

Green truck ✌️🤠

Onboarding

Bounce ✌️🤠

I also built an app — DigiCam

I also made DigiCam, listed as Background Camera RemoteStream on Google Play. It's the world's first screen-off YouTube live streaming app: stream live with the screen off for ~10× the battery life, plus background recording, remote web console control, file-based YouTube Live, and playlists. Privacy-first, all local storage. Free with ads or Pro for the full feature set:
https://play.google.com/store/apps/details?id=com.superfunicular.digicam

Watch the full channel: @Digital_Nomad_Media

Tags: #SuperFunicular #DigiCam #DigiNomad #YouTubeShorts #ContentCreator #Blizzard #snowstorm #PlanetSide2 #LadyThePitbull

The State's Own Poster Has a Box for Hidden Cameras: Connecticut's Monitoring Law and a Phone on a Shelf

Super Funicular — Sat, 19 Sep 2026 10:58:19 +0000

The State of Connecticut prints a poster for employers to hang on the wall, and one of the boxes you can tick on it says "Camera (including hidden cameras)".

It sits in a list with Telephone, Computer, Radio, Wire, Electromagnetic, Photoelectronic and Photo-optical. The employer ticks the ones that apply, writes in a contact name, and hangs it somewhere staff can read it. The form is a plain single page, and the state has been publishing it for years.

That tick-box is worth pausing on if you are the sort of person who keeps a spare handset running as a camera. The hard parts of that job are usually treated as technical — heat, battery, storage, whether the stream survives a reboot. In Connecticut, if there is an employee in the room, a different question arrives before any of those, and it has a form attached.

The hardware is in the definition by name

Section 31-48d of the Connecticut General Statutes defines electronic monitoring as "the collection of information on an employer's premises concerning employees' activities or communications by any means other than direct observation, including the use of a computer, telephone, wire, radio, camera, electromagnetic, photoelectronic or photo-optical systems".

Read the list rather than the obligation attached to it. A camera sits in the definition by name, next to the computer and the telephone. The statute is not reaching a phone by analogy or by a strained modern reading of an old word. What is described is a device that collects information about what employees are doing, by means other than a person standing there watching. A spare handset on a shelf does that as squarely as a ceiling dome from a security vendor. Nothing in the text turns on what the device cost, who made it, or whether it was sold as surveillance equipment.

That is worth sitting with, because the informality of the hardware does a lot of quiet work on how people feel about it. A dome on a bracket looks like a decision somebody made. A phone on a shelf looks like a phone on a shelf.

The carve-out is narrower than the reason people reach for a phone

The definition carries two exclusions. Information collected "for security purposes in common areas of the employer's premises which are held out for use by the public" is outside it, and so is information "which is prohibited under state or federal law". The first is the one that does the work here.

That exclusion covers a great deal of ordinary retail camera work. A lens over the shop floor, pointed at the part of the premises customers walk into, is doing security in a common area held out for use by the public. Most of the cameras in most small businesses are exactly that, and the statute steps back from them.

Now consider what makes a phone attractive for this job in the first place. It is small, it is quiet, it draws no attention, and it can go somewhere a mounted camera would be conspicuous or expensive. The placements that follow from those properties are the stockroom, the prep table, the back office, the shelf above the spare packaging. Those are, with some precision, the parts of a premises that are not held out for use by the public.

So the shape is an awkward one, and it is better stated plainly than left to be discovered: the more a phone camera is being used for the thing a phone is distinctively good at, the more likely it is that the notice duty attaches. The property that makes the tool worth choosing is the property that moves the deployment out of the exemption.

The notice is the posting

Subsection (b)(1) puts it this way. "Each employer shall post, in a conspicuous place which is readily available for viewing by its employees, a notice concerning the types of electronic monitoring which the employer may engage in. Such posting shall constitute such prior written notice."

Two things follow. The first is that the duty is discharged by a posting rather than by a conversation, so there is a physical artefact involved and its absence is visible. The second is that the posting is the prior written notice, which means an employer who mentioned it to the staff once, and considers the matter handled, has not yet done the thing the section asks for.

This is where the poster comes back. The Connecticut Department of Labor publishes that sample as a public service through its Wage and Workplace Standards Division, with the text of the section reproduced on the reverse. For a small employer it is the practical route through this: it costs an afternoon rather than a lawyer.

And notice what ticking the camera box actually does. The statute's escape hatch from advance notice, which I come to below, is for monitoring undertaken on suspicion. The standing poster offers something different and duller — you declare, in advance and in general terms, that cameras including hidden ones may be in use. The state's own form treats the covert camera as a thing you disclose the possibility of, not a thing you keep to yourself.

What changes at the start of October

Public Act No. 26-73, An Act Concerning the Electronic Surveillance of Employees, was signed on June 4, 2026 and takes effect October 1, 2026. It does not amend section 31-48d so much as repeal and replace it. The definition of electronic monitoring, quoted above, is carried over unchanged, so the part of this that puts a camera in the text survives the rewrite.

What changes is the notice. Since 1998 the posting has had to describe the types of monitoring an employer might engage in. From the effective date, the prior written notice given to affected employees must also tell them the specific locations on the premises where monitoring may occur, and the posting has to describe those locations and be put up "in the specific location on the employer's premises where such monitoring may occur".

That second half is the part aimed squarely at a phone. A single notice by the time clock, describing monitoring in the abstract, stops being sufficient on its own. If the camera is watching the stockroom, the stockroom is where a notice goes. The statute has moved from asking whether people were told to asking whether they were told there.

There are two exceptions to the location disclosure. It does not apply where the premises is an airport, or where the employer has reasonable grounds to conduct the monitoring for security and employee safety purposes. From the effective date there is also a second document in play, easy to miss because it is not a posting at all: employees hired on or after October 1 are to be given, before they start, a plain language written statement of which activities the employer prohibits and may monitor without prior written notice.

The suspicion branch is real, and it is bounded

Subsection (b)(2) lets an employer monitor without prior written notice where there are reasonable grounds to believe employees are engaged in conduct that violates the law, violates legal rights, or "creates a hostile workplace environment", and where the monitoring may produce evidence of that misconduct.

This is the branch that fits the story people actually arrive with. Stock is going missing. Somebody suspects somebody. The camera goes up quietly, because announcing it would defeat the point of putting it there. The section contemplates that situation directly, which is worth knowing before anyone concludes the law forbids the thing they were going to do.

What the branch does not describe is a standing condition. It is tied to grounds held at a particular time, and to monitoring that could produce evidence of that particular misconduct. A camera that went up under suspicion and was still running a year later, watching everybody, has drifted well out of the shape the subsection sets out. The honest reading is that it covers an investigation rather than a permanent arrangement, and that the difference is one of duration and scope rather than intent.

The subsection most write-ups skip

Subsection (d) is two sentences and it is the one I would not want to find out about afterwards. "The provisions of this section shall not apply to a criminal investigation. Any information obtained in the course of a criminal investigation through the use of electronic monitoring may be used in a disciplinary proceeding against an employee."

The first sentence is a carve-out. The second is a one-way door. Footage gathered while the police are involved does not stay inside the criminal matter; it is available for internal discipline afterwards. So the camera that went up to establish who was taking stock can end up furnishing the record in an unrelated dismissal, and the section says so in advance rather than leaving it to be argued.

That is the same structure as the placement problem, one step further along. Choosing to record is also choosing what the recording can later be used for, and both choices get made before anybody is thinking about either.

What enforcement actually looks like

The Labor Commissioner may levy a civil penalty after a hearing. The maximum is "five hundred dollars for the first offense, one thousand dollars for the second offense and three thousand dollars for the third and each subsequent offense", and the new Act leaves that unchanged. Reported alongside the section is the holding that "There is no private cause of action under section", with enforcement limited to proceedings before the Labor Commissioner (294 Conn. 461).

That combination deserves to be read correctly in both directions, because it cuts against alarm as much as against complacency. The exposure is a modest escalating penalty rather than a suit brought by an employee, so getting this wrong is a smaller event than a nervous reading suggests. It is also administrative, which tends to mean it surfaces in the course of some other labour complaint rather than on its own. None of which is an argument for skipping a one-page poster.

What to do with this

Work out whether your own state has a statute of this kind at all. Connecticut is one of several with a notice, acknowledgment or consent requirement; California, Delaware, Maine, New Jersey and New York have their own, with different scope and different triggers. That a camera is legal to own says little about whether it is notifiable to the people it watches.
If Connecticut is the state you are in, look up the Department of Labor template and check whether it has been revised for the location requirement before relying on a copy you already have. The version published as I write is the pre-amendment one.
Settle the placement question before the mount goes up, and settle the notice at the same time, because after October 1 they are the same question.
Treat audio as a separate decision, under separate rules, and take it on its own merits: why the microphone is a different permission from the camera.

What I could not verify

Whether the Department of Labor has a revised template in preparation. The copy on the portal today lists monitoring types only and has no field for locations, which is what the pre-October statute asks for; counsel writing on the Act expect an update, and I found none published.
How the phrase specific location will be read in practice, and whether it resolves to a room, a zone, or a named fixture. The text does not say, and I found no guidance that settles it.
The Act's own text. The General Assembly's PDF would not return content for me, so the amended language here is taken from two independent write-ups that quote it identically, not from the enrolled Act.
I read Connecticut. I did not work through the other states' statutes, and I would rather record that than imply coverage I did not do.

None of the above is legal advice, and I am not a lawyer.

The useful part is smaller than a compliance programme and more annoying than a technical decision. Where a phone ends up pointing has stopped being only a coverage question. From the first of October it also decides which room has a notice on the wall — and there is no placement discreet enough to answer that one by being discreet.

Try it: Background Camera RemoteStream on Google Play -- record with the screen off, keep footage on the device, watch it over your own network.

Sources. Statutory text and the reported holding: Connecticut General Statutes section 31-48d, on Justia. The poster and the reproduced section: the Connecticut Department of Labor sample notice. On Public Act No. 26-73: Wiggin and Dana and Jackson Lewis, writing in the National Law Review. Quotations from the section are verbatim statutory text as published.

Your Phone Camera's Frame Rate Never Reaches the File - What Android Actually Writes Into an MP4 Timeline

Super Funicular — Sat, 19 Sep 2026 05:07:21 +0000

Anyone who has left a phone recording overnight has done the arithmetic at some point. Thirty frames a second, times sixty, times sixty again, times eight hours. Eight hundred and sixty-four thousand frames. From there you can estimate a file size, predict how long a seek will take, work out how many frames a motion-detection pass has to chew through, or convert a scrubber position into a time of day.

Every one of those calculations rests on a number that is not in the file.

An MP4 recorded by an Android phone does not store a frame rate. It stores something else, and the difference is invisible until the moment it isn't — usually when you are trying to work out exactly when something happened.

Does an MP4 recorded on Android store a frame rate?

No. The container stores a timescale and a list of per-sample durations. The playback rate is a consequence of those numbers, not an input to them.

That is not a quirk of any particular app. It is how the ISO base media file format has always worked, and Android's own documentation is unusually explicit that the frame rate you configure does not travel with the media.

The frame rate is a hint, and the documentation says where it stops

When you configure a video encoder on Android you set MediaFormat.KEY_FRAME_RATE. It is required for encoders. It is also, in the platform's own words, advisory:

"For video encoders this value corresponds to the intended frame rate (the rate at which the application intends to send frames to the encoder, as calculated by the buffer timestamps, and not from the actual real-time rate that the frames are sent to the encoder). Encoders use this hint for rate control, specifically for the initial frames, as encoders are expected to support variable frame rate (for rate control) based on the actual buffer timestamps of subsequent frames."

Two things in that paragraph deserve slow reading. The configured rate is described as intended, and it is explicitly calculated from the buffer timestamps rather than from wall-clock arrival. And encoders are "expected to support variable frame rate" driven by "the actual buffer timestamps of subsequent frames." The timestamps are upstream. The rate is downstream of them.

Then the same page closes the loop with one short sentence:

"This key is not used in the MediaCodec input/output formats, nor by MediaMuxer."

The muxer — the component that actually writes the MP4 — is never told the frame rate. Look at the format keys MediaMuxer.addTrack() documents and there is no frame-rate key among them. There is width, height, bit rate, and a set of colour keys. The number you configured stopped at the encoder.

CamcorderProfile uses the same careful vocabulary for the higher-level path. Its field is not called the frame rate; it is:

"The target video frame rate in frames per second."

Target. The sibling fields on that page say "target" too, so this is the page's standing word for a profile value rather than a special caveat about timing. But it is the right word, and it is not "actual."

What the muxer receives instead: one timestamp per frame

What MediaMuxer gets is a buffer and a MediaCodec.BufferInfo. The relevant field is documented in a single line:

"The presentation timestamp in microseconds for the buffer. This is derived from the presentation timestamp passed in with the corresponding input buffer."

So the timeline is assembled one frame at a time, from a value that originates upstream of the encoder. writeSampleData() imposes exactly one ordering rule, and it is weaker than developers tend to assume:

"The application needs to make sure that the samples are written into the right tracks. Also, it needs to make sure the samples for each track are written in chronological order (e.g. in the order they are provided by the encoder.)"

Chronological, per track. That is the whole contract. Worth noting what is not on that page: it never uses the word "monotonic," never says the timestamps must be evenly spaced, and never states what happens if they are not. The documented exceptions for writeSampleData are about invalid arguments and wrong muxer state — neither is tied to timestamp spacing. Nothing in the API is checking that your frames are 33,333 microseconds apart, because nothing in the format requires them to be.

What the container actually stores

On the file side, the relevant structures are the media header and the decoding-time-to-sample table. ISO/IEC 14496-12 defines the timescale in the media header box as:

"timescale is an integer that specifies the time-scale for this media; this is the number of time units that pass in one second. For example, a time coordinate system that measures time in sixtieths of a second has a time scale of 60."

And the stts box, which is mandatory and appears exactly once per sample table:

"This box contains a compact version of a table that allows indexing from decoding time to sample number... Each entry in the table gives the number of consecutive samples with the same time delta, and the delta of those samples. By adding the deltas a complete time-to-sample map may be built."

Each entry carries a sample_count and a sample_delta. The semantics are plain: sample_count "counts the number of consecutive samples that have the given duration," and sample_delta "gives the delta of these samples in the time-scale of the media."

A perfectly regular recording compresses beautifully here: one entry, sample_count = 864,000, sample_delta = a constant. That is the run-length compression the spec means by "a compact version of a table." A recording whose spacing wandered produces more entries. Same box, same rules, no error condition — the format treats even spacing as a lucky case, not a requirement.

And the duration of the track is defined by summation, not by division:

"the sum of all deltas gives the length of the media in the track"

That sentence is the whole argument in miniature. The length of your overnight recording is the sum of how long each frame actually claimed to last. It is not frame count divided by frame rate, because the file never stored a frame rate to divide by.

Where the spacing is documented to move

There is a legitimate, documented mechanism by which capture spacing changes during a recording, and it sits in Camera2. CONTROL_AE_TARGET_FPS_RANGE is typed as a Range<Integer> and described as:

"Range over which the auto-exposure routine can adjust the capture frame rate to maintain good exposure."

The auto-exposure routine adjusts the capture frame rate. That is the documented purpose of the key, not a side effect. And variable ranges are not exotic — CONTROL_AE_AVAILABLE_TARGET_FPS_RANGES guarantees that for devices at the LIMITED level or above, other than those advertising an NIR colour filter arrangement, the list "will always include (min, max) and (max, max) where min <= 15."

So a device is required to offer you at least one range whose floor is 15 or below, alongside a fixed one. If your capture request carries the variable range, you have asked the auto-exposure routine for permission to move the spacing, and the container will faithfully record that it did.

Separately, the same field documents a case where the requested maximum simply cannot be met:

"Note that the actual achievable max framerate also depends on the minimum frame duration of the output streams. The max frame rate will be min(aeTargetFpsRange.maxFps, 1 / max(individual stream min durations)). For example, if the application sets this key to {60, 60}, but the maximum minFrameDuration among all configured streams is 33ms, the maximum framerate won't be 60fps, but will be 30fps."

That is a fixed request of {60, 60} being delivered at 30. Requested and achieved are documented as different quantities.

What the documentation does not say, stated plainly. I went looking for a first-party sentence asserting that frame rate drops in low light, and did not find one. Searches will confidently hand you a specific floor figure, attributed to Android's Low Light Boost AE page. That page contains no FPS figures, no lux figures, and no exposure times at all — no numbers of any kind. The word "light" does not appear in the CONTROL_AE_TARGET_FPS_RANGE field. What is documented is the mechanism ("adjust the capture frame rate to maintain good exposure") and the guaranteed availability of a low-floor range. The size of the effect on your specific handset in your specific hallway is not documented by anyone, and the honest thing to do is measure it rather than quote a number you read.

The last frame is a special case, and it is easy to miss

Buried in writeSampleData() is a rule with no analogue anywhere else in the file:

"For MPEG4 media format, the duration of the last sample in a track can be set by passing an additional empty buffer(bufferInfo.size = 0) with MediaCodec.BUFFER_FLAG_END_OF_STREAM flag and a suitable presentation timestamp set in bufferInfo parameter as the last sample of that track. This last sample's presentation timestamp shall be a sum of the presentation timestamp and the duration preferred for the original last sample. If no explicit END_OF_STREAM sample was passed, then the duration of the last sample would be the same as that of the sample before that."

Every frame's duration is derivable from the gap to the next one. The final frame has no next one, so the muxer guesses — it copies the previous frame's duration. On a clip that ends cleanly, the error is one frame and nobody notices. The reason to know the rule is that it tells you where the file's declared duration comes from at the boundary: it is a convention, not a measurement.

Why any of this matters outside a codec discussion

Three practical consequences, each of which touches something you may already have built.

Seeking is priced in deltas, not in frames. If you are serving recordings from the phone over HTTP, the player converts a scrubber position into a time, the time into a sample via the stts map, and the sample into a byte offset. I wrote about the transport half of that — why the browser's range requests and the position of the moov atom decide whether playback starts in one second or after the whole file downloads — in The Range Header Is the Whole Feature. The timeline described here is the map that request is indexing into.

A truncated recording has no map at all. The sample tables live in moov, and a muxer cannot write them until it knows every delta. That is why a recording interrupted by a crash or a power cut will not open, and why the fixes look the way they do — covered in Why an Interrupted Android Recording Won't Play.

A position in a file is not a time of day. This is the one that bites during an actual incident. The timeline inside the file is an elapsed-time axis with a zero origin — the spec is explicit that "The DT axis has a zero origin." It carries no information about when recording started, and nothing reconciles it with the wall clock afterwards. Converting "01:47:22 on the scrubber" into "the time someone was at the door" is a separate problem with its own failure modes, which I went through in Recording Is the Easy Half.

What to check on your own footage

None of this requires taking my word for it, and the measurement is more useful than the theory.

Read the file's own numbers. ffprobe will report both an average frame rate and a real base frame rate for a stream; when a recording's spacing wandered, those two diverge. On-device, MediaMetadataRetriever exposes METADATA_KEY_DURATION and METADATA_KEY_VIDEO_FRAME_COUNT as separate values — divide one by the other and compare the result to what you configured.
Test the boundary, not the middle. Record a two-minute clip in bright light and a two-minute clip in the dimmest conditions the camera will be working in, with the same settings. Compare duration ÷ frame count for each. That single comparison tells you more about your handset than any specification will.
Decide whether you actually want fixed spacing. If a constant rate matters more to you than exposure, request a fixed range — the (max, max) entry is guaranteed to be on the list. You are trading image quality in dim conditions for a predictable timeline. That is a real trade, and it should be a decision rather than a default.
Do the arithmetic on measured values. Storage estimates, motion-pass costs and retention windows built on a nominal frame rate inherit an error you never measured. Substitute your own numbers from step 1.

The short version

An Android phone does not record at a frame rate. It produces frames, stamps each one with a presentation time, and hands them to a muxer that writes down the gaps. The frame rate is a hint that helps the encoder budget bits and then stops travelling — documented, in so many words, as not reaching the muxer at all. The file that results is an honest record of when frames arrived, which is a more useful thing to have than a nominal rate, provided you know that is what you are holding.

If you are building this, measure the spacing before you build anything on top of it. If you are running a phone as a camera and only ever watch the footage, this is the explanation for why the duration sometimes looks slightly wrong, and it is not your card failing.

Background Camera RemoteStream records with the screen off, keeps footage on the device rather than in anyone's cloud, serves a live view from a built-in web server to any browser on your own network, and can stream to YouTube Live. No account, no subscription. Built in Kotlin on Camera2 with an embedded Ktor server. Free on Google Play — more at superfunicular.com.

Sources, all first-party:

MediaFormat — KEY_FRAME_RATE — intended rate, encoder hint, "not used ... by MediaMuxer"
MediaMuxer — writeSampleData() and addTrack() — chronological-order rule, last-sample duration and END_OF_STREAM
MediaCodec.BufferInfo — presentationTimeUs — microsecond presentation timestamp
CamcorderProfile — videoFrameRate — "The target video frame rate"
CaptureRequest — CONTROL_AE_TARGET_FPS_RANGE — AE adjusts capture frame rate; the {60,60} → 30fps stream-duration cap
CameraCharacteristics — CONTROL_AE_AVAILABLE_TARGET_FPS_RANGES — guaranteed (min, max) with min <= 15, and (max, max)
MediaMetadataRetriever — METADATA_KEY_DURATION, METADATA_KEY_VIDEO_FRAME_COUNT
Low Light Boost AE Mode — checked for FPS claims; contains none
ISO/IEC 14496-12:2015, ISO base media file format — §8.4.2.3 media header timescale, §8.6.1.2 Decoding Time to Sample Box (stts), zero-origin DT axis

Android's September 30 Verification Deadline — What "Verified Developer" Does and Doesn't Tell You About an App

Super Funicular — Sat, 19 Sep 2026 05:06:50 +0000

Google has now put a date on the point at which an unregistered Android app stops installing. It is September 30, 2026, and in this first phase it applies to users in Brazil, Indonesia, Singapore and Thailand, on certified devices running Android 7 or higher, installing from seven participating stores — Google Play, HONOR App Market, OPPO App Market, Galaxy Store, Palm Store, V-Appstore and GetApps. A global rollout to all certified Android devices is scheduled for 2027.

That is a real change in how software reaches Android phones, and it deserves to be read accurately rather than dramatically. Two things are worth separating: what the deadline actually covers, and what the resulting "verified" status actually certifies.

What the deadline covers, precisely

A lot of the commentary has compressed this into "every Android developer must now send Google a government ID." The primary documentation says something narrower.

The September date is store-scoped. Google's FAQ states that enforcement starting September 30 "is limited only to the specific stores mentioned," and that if users sideload an app directly, or install it from a store outside that list, "these new verification requirements won't apply to your app yet."
There is a free tier that takes no ID. Limited distribution accounts opened to everyone in August for hobbyists, students and teachers. They cost nothing, they allow sharing with up to 20 devices that end users have explicitly authorized, and the guide says it plainly: "you don't need to provide a government ID." The $25 fee belongs to a Full Distribution account and is waived for this one.
ADB is untouched. Installing over Android Debug Bridge needs no verification, and the advanced flow's waiting period does not apply to it.
Most Play apps are already done. Google states that Play automatically registers 99% of apps, and that apps using Play App Signing are claimed automatically.

None of that makes the 2027 global phase a small thing, and the developers raising objections to it are not raising imaginary ones. But someone reading only headlines might conclude that the hobby project on their bench dies in eleven days, and that is not what the documents say.

What "verified" certifies — and what it does not

Here is the part worth sitting with. It is not a gotcha, because Google states it clearly itself, in the FAQ, while answering a question about NDAs:

"Verification is narrowly focused on the developer's identity to establish accountability. Android Developer Verification does not collect information about the app content or functionality."

Read that against the programme's stated purpose, which is equally explicit: identity verification "establishes accountability," making it harder for whoever shipped malware to turn around and ship the same thing again under a fresh anonymous identity. That is a genuine problem, and this is a reasonable lever against it.

But accountability is a claim about who. It is not a claim about what. Verification binds a legal identity to a signing key; it does not examine what the software does once it is running. Both of these remain entirely possible after September 30:

A fully verified developer — ID submitted, fee paid, key registered — ships an app that uploads everything it records to a server you know nothing about.
An unverified hobbyist ships an app that never opens a socket in its life.

The risk here is not that verification is bad. The risk is the heuristic users may quietly learn from it. Install friction is about to become visible: an unverified app shows a warning, and reaching one at all takes a deliberate one-time setup involving developer mode, a restart, and a one-day wait. It is very natural to start reading smooth as safe and friction as suspicious. As a privacy heuristic that is unreliable in both directions, because privacy is a question about behaviour and the badge is an answer about identity.

For camera apps, the gap is widest

A camera app is the case where the distance between those two questions matters most. You are handing an application a live view of a room in your home, plus storage, plus — usually — the network. Who wrote it is worth knowing. It is not the thing that determines whether tonight's recording stays on the device.

The useful part is that the behaviour question is testable by the person asking it, without trusting anybody's badge or anybody's marketing copy, ours included:

Cut the network and see what survives. Put the phone in airplane mode, or take it off Wi-Fi, and try to record. Something storing locally keeps working. Something whose pipeline runs through a server will tell you, quickly.
Read the permissions against the feature list. A recorder needs camera, storage, and network if it serves a stream on your LAN. Anything past that is a question you are entitled to ask out loud.
Check whether it insists on an account. An account is the mechanism by which footage becomes associated with a person on somebody else's system. An app that never asks for one cannot do that by that route.
Watch it at rest. Leave it recording nothing in particular for a day, then look at its data usage.

Those four tests work on any camera app on your phone. They are not a pitch. They are precisely the questions the verification programme says it does not answer.

Where we sit

Background Camera RemoteStream is distributed on Google Play, which puts it in the 99% that Google registers automatically. Nothing about September 30 changes how anyone installs it. That is worth stating plainly rather than leaving implied — and it is worth saying in the same breath that it proves nothing whatsoever about our privacy claims. It proves Google knows who we are.

What we would rather you do is run test one. The app is built to record to local storage on the device, and to work without an account; airplane mode is the fastest way to find out whether that description survives contact with your own phone. We would rather be checked than believed, and the four tests above are the ones we would want someone to run on us.

Verification answers a question Android genuinely needed answered: when something harmful ships, who shipped it. That work is real and it is happening on a published schedule. It is simply a different question from the one most people are actually asking when they ask whether an app is private — and only one of those two questions has a deadline attached.

Background Camera RemoteStream is free on Google Play. More at superfunicular.com.

Sources, all first-party:

MantaxOtax Didn't Exploit Anything to Watch Your Screen — And That's the Part Worth Reading

Super Funicular — Fri, 18 Sep 2026 00:20:11 +0000

On September 9, Zimperium's zLabs team published a technical writeup on MantaxOtax, an Android family that pairs file-encrypting ransomware with a full surveillance stack. Infosecurity Magazine covered it the following day. It targets users in Indonesia, arrives as a sideloaded APK from a third-party file host, and — the detail that stopped me — abuses Android's MediaProjection API for screenshots, MP4 screen recording and near-real-time streaming, staging the captures on the free file host Catbox and mailing the links back to its operators. It can also take silent photos on either camera.

I build a background camera app. I want to be precise about why that paragraph is uncomfortable rather than vindicating.

There is no exploit in the capture path

Read the Zimperium writeup looking for the clever bit and you won't find one, at least not in the recording. MediaProjection is the documented, supported way an Android app captures the screen — it's what every screen recorder and every screen-sharing app on your phone uses. Camera access is camera access. The malware's capture stack is not a vulnerability chain. It is the platform working as designed, pointed somewhere you didn't intend.

The actual craft is elsewhere, and it's mundane: convince someone to sideload the APK, then walk them through granting device administrator, then SMS, contacts, audio and images, and finally Accessibility — which, once granted, gives an app broad reach over the device's own interface. Zimperium also describes the C2 domain being resolved from a GitHub repository so operators can rotate infrastructure without shipping new code, and a Firebase misconfiguration that left some of the extortion chats exposed. Clever operationally. Not clever at the camera.

Two other details from the writeup are worth carrying, because they cut against the usual "malware is unstoppable" framing. On Android 10 and later, Scoped Storage confined the encryption routine to the app's own external files directory, sharply reducing what it could reach — a platform change, made years ago for unrelated reasons, blunting a ransomware payload. And the whole thing depends on sideloading plus a permission ladder that the user climbs manually.

So "it can record with the screen off" tells you nothing

Here is the uncomfortable part for anyone in my category.

If you tried to identify malicious software by asking can this app capture without an obvious on-screen sign, you would flag MantaxOtax. You would also flag Background Camera RemoteStream, which is our whole product. Recording with the screen off is not an exotic capability we reverse-engineered; it's a thing Android lets a foreground-service app do, and a dozen legitimate apps — dashcams, baby monitors, trail cameras, screen recorders — do it because the use case requires it. A screen that is off is not an app that is idle. That's true of the malware and it is equally true of us.

Which means capability is not a signal. Both sides of this comparison have the same capability. The distinguishing facts are somewhere else, and the useful thing I can offer here is where.

The questions that actually discriminate

Where do the bytes go? MantaxOtax's answer is Catbox and a rotating C2. That is the load-bearing fact about it — not that it recorded, but that the recording left. For any capture app on your phone, the honest version of the privacy question is not "does it record" but "does it have anywhere to send it, and can you tell." An app whose recordings are written to local storage and never uploaded has a materially different failure mode from one that ships to a server, and you can test the difference: put the device in airplane mode and see whether the feature still works.

What is it asking for, and does the ask match the job? A camera app needs the camera. It does not need Accessibility, and it does not need device administrator. Accessibility in particular is the permission that turns a nuisance into a takeover, and it is the one that should make you stop. Android's permission manager (Settings → Privacy → Permission manager, and the separate Accessibility and Device admin screens) will list every app currently holding these. Most people have never opened those screens. It's worth ten minutes.

Where did it come from? Sideloading is how this particular family arrives. That is not an argument that store distribution is a safety guarantee — plenty of unpleasant things have shipped through official stores, and plenty of excellent, genuinely private software is distributed outside them. F-Droid exists and is not a red flag. But an APK handed to you over a messaging app by someone creating urgency is a different object from a package you went and found.

What does the platform say? Android 12 and later show an indicator in the status bar when the camera or microphone is in use, and the quick-settings panel will name the app. It is not a complete defense, but it is a signal the app doesn't author, and it costs nothing to glance at.

Where we actually sit

Background Camera RemoteStream stores recordings locally, requires no account, and doesn't run analytics or tracking. I want to be careful about how much credit that deserves. "No cloud" is closer to table stakes than a differentiator — there is a healthy set of local-first and open-source Android camera projects making the same commitment, some of them more auditable than us because you can read their source. If your threat model is "I want to verify, not trust," an app you can compile yourself has an argument we can't match, and that's a fair thing for a reader to weigh.

What I'd rather claim is narrower and I think it's true: the difference between our screen-off recording and the screen capture in Zimperium's report is not technical sophistication and it is not capability. It's who initiated the capture, where the output lives, and how much of the device the thing can reach when it goes wrong. A recorder that holds camera and storage permissions and writes to local storage has a bounded blast radius. Something holding Accessibility and device admin does not, and the recording is the least of what you lost.

That framing is less flattering to us than "malware records you, buy our app." It's also the only version that survives contact with the Zimperium writeup, which is right there and which you should read.

Background Camera RemoteStream — local storage, no account required, no tracking, screen-off recording and YouTube Live streaming.
Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam
Site: https://superfunicular.com

Sources: Zimperium zLabs technical writeup, Sept 9, 2026 · Infosecurity Magazine, Sept 10, 2026

Every Guide Says "Reserve the Address on Your Router." What If the Router Is Not Yours?

Super Funicular — Fri, 18 Sep 2026 00:10:26 +0000

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

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.

The Minimum-Version Floor Is What Actually Retires a Phone, and Nobody Publishes It

Super Funicular — Thu, 17 Sep 2026 00:56:23 +0000

Every app on a phone declares the oldest Android version it is willing to install onto. That declaration is routine, necessary and entirely normal — every shipped app has one. It is set by the company that wrote the app, not by the company that sold you the handset, and not by you. The combined effect of all of those declarations on one specific handset is written down nowhere, and it is the thing that actually decides when that handset stops being useful.

The date that is published

Every Android handset carries a date the manufacturer decided: how long it keeps receiving system updates. It is a real date, it is on the device, and it is the one the whole argument about old phones is conducted over.

It deserves to be known, and it answers a specific question: what this handset should not be trusted with. It does not answer the question people actually use it for, which is when the handset stops working for them.

The dates that are not

Walk through how a phone leaves service in an ordinary household. It is rarely retired on a date anybody looked up. It is retired on the morning that something the house depends on refuses to run on it: the bank, the app the school sends messages through, whatever the car park by the office uses now.

The mechanism itself is documented and unremarkable. An app declares minSdkVersion, and Android's own guidance is blunt about what follows: the system prevents installation if the lowest API level the app requires is higher than the device's. Play surfaces that to the person as a message saying the app was made for a newer version of Android.

So what is worth noticing is not the mechanism. It is where the mechanism sits:

The manufacturer's date is one date, published, and on the device.
The version floors are many dates, held by companies that never sold you the handset, moved independently of each other, and announced on no schedule at all.

The reasons behind each one are usually mundane: a platform feature the app wanted, a tier of devices it could no longer test on, a dependency that moved underneath it. Whatever the reason, it was formed inside that company, with no view of your handset, and there is no place where the combined effect on one handset is written down.

So the date you can look up is not the one that decides, and the dates that decide can be found out only by trying.

The check

So try. This takes a few minutes and costs nothing.

Write down the three or four things that genuinely have to work on that handset for the job you have in mind. Not everything you have ever installed — the short list the job actually requires.
On that handset, not on the one in your pocket, open each of those in the Play Store.
Read what it says. An app whose floor is above that handset will tell you, in the listing, that it cannot be installed on this device. That is the answer, and it is the current one, not a forecast.

Two things fall out of doing it in that order.

The list is job-specific, and that is the whole point. A handset that can no longer be someone's main phone is being judged against a list containing a bank, a payment app and a messaging app used by people who upgrade often. Judge the same handset against a list containing one camera app and a browser and you are asking a different question, and you will frequently get a different answer. The hardware did not change between those two questions. The list did.

The published date is still doing a job — a narrower one. A handset past the end of its update window is a poor place for the things you would mind losing. That is a real constraint and none of this dissolves it. It is an argument about what a handset should be asked to do, which is not the same as an argument that it is finished. Something on a shelf pointing at a door, on a network you control, is a materially different proposition to something carrying your bank.

The part where I am one of them

I publish a camera app, so I hold one of these floors, and everything above applies to me. I have not published a schedule for mine and nothing obliges me to — which is the identical complaint I have just made about everybody else. I would be writing an advertisement if I claimed my floor was somehow more considerate than a bank's.

I also cannot usefully tell you where it sits, because the answer that counts is the one the listing gives on the handset you are actually holding.

Which is the part worth taking away. A handset in a drawer does not have a retirement date sitting in it, waiting to be looked up. It has an answer it will give you in four minutes, to a question you have not written down yet.

The recorder behind these notes: Background Camera RemoteStream on Google Play — screen-off recording, local storage, live view over your own LAN.

superfunicular.com

Sources (read directly):

The Range Header Is the Whole Feature: Serving Recorded Video From a Phone's Own Web Server

Super Funicular — Wed, 16 Sep 2026 07:10:47 +0000

If you put an embedded HTTP server inside an Android app so that another device on the
same Wi-Fi can watch the camera in a browser, you will build the live view first. It is
the part everybody asks for, and the part that demos well.

Then someone asks to watch a recording from last night, and you reach for the easy win.
The live view is a moving target: frames arriving from an encoder, a connection that has
to stay open, backpressure, a client that might be on a slow radio. A recording, by
comparison, is a file. It has already finished. It is sitting on the device's storage with
a known size and a known type. Serving it should be strictly less work than serving the
live view.

It is not. Over HTTP, a finished file is the harder of the two, and the reason is a
single request header that the live view never needed and never will.

The two jobs ask for different things from a server

The live view asks a server to answer one question forever: what is happening now. The
client connects once and the bytes keep coming. Nobody asks for the middle. Nobody asks
how long it is, because it does not have a length — it ends when the camera stops or the
browser tab closes. A server can answer that with chunked transfer encoding, with
multipart JPEG, with a segmented format, and in every case it never has to state a
Content-Length, because there is no total to state.

A recording asks a different question, and asks it repeatedly: give me the part of this
that I am about to display. A browser handed a one-hour file does not want the hour. It
wants a few hundred kilobytes to get started, and then, the instant a human drags the
scrubber to 47 minutes, it wants the bytes that live at 47 minutes and nothing before
them.

That request has a name. It is the Range header, and if your server does not implement
it, seeking either does not work or costs the entire file every time.

What the exchange actually looks like on the wire

The client sends a normal GET with one extra line:

GET /recordings/2026-09-15T2214.mp4 HTTP/1.1
Host: 192.168.1.42:8080
Range: bytes=0-1023

A server that supports ranges does not reply 200 OK. It replies
206 Partial Content:

HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Range: bytes 0-1023/2147483648
Content-Length: 1024
Content-Type: video/mp4

Three things are being communicated there, and each one matters to the player:

Accept-Ranges: bytes advertises that this resource can be requested in pieces at all. Per MDN, any value other than none means range requests are supported. Its absence is an answer too.
Content-Range states which bytes these are and the size of the whole resource — the /2147483648 at the end. That total is how the player learns the duration is worth drawing a scrubber for.
Content-Length now describes the slice, not the file.

A client may also ask for several ranges in one request, in which case the response body
becomes multipart/byteranges with each part carrying its own Content-Range. Most
video players do not do this; download managers do.

The failure mode is quiet. A server that does not know about Range does not error — it
ignores the header and returns 200 with the entire body, which is a legal response and
looks fine in a log. You will see a wall of 200s, full-size transfers, and a scrubber
that either does nothing or stalls for ten seconds per drag.

Ktor will not do this for you by default

If the embedded server is Ktor — which it is in our case, and in a lot of Android
projects that need an HTTP surface without shipping a whole app server — range support is
an explicit install, not a default:

install(PartialContent)
install(AutoHeadResponse)

routing {
    staticFiles("/recordings", recordingsDir)
}

The PartialContent plugin carries
three constraints that are easy to trip over on a device:

It applies to GET and HEAD only. A Range header on any other method gets 405 Method Not Allowed. That is correct behaviour, and it is also a good reason to keep the recordings route boringly read-only.
It only works on responses that already have a Content-Length. If you are streaming a file through a channel that does not know its own size, the plugin has nothing to compute an offset against and will not engage. Serve recordings from something that can state its length.
It disables compression on ranged responses. This is the right trade and worth understanding rather than working around: gzipping a byte range would make the offsets in Content-Range describe the compressed stream, not the file, and the client's next seek would land in the wrong place. H.264 in an MP4 container is already compressed; there was nothing to win here anyway.

AutoHeadResponse is in that snippet for a reason. Several players — and every
diagnostic tool you will reach for — probe with HEAD before they commit to a download.
If HEAD 404s because you only registered a GET route, the client concludes the
resource is not there and never sends the range request you carefully implemented.

The second half of the problem is inside the file

Range support is necessary. On a phone it is frequently not sufficient, because of where
the MP4 container puts its index.

An MP4 is roughly two things: mdat, the media payload, and moov, the table that says
what codec the payload uses, where each frame starts, and what timestamp it carries. A
player cannot decode a single frame of mdat without moov — it does not know the frame
boundaries.

moov can only be finalised when recording stops, because until then the recorder does
not know how many frames there will be. The straightforward way to write the file is
therefore to append moov at the end. For a file you open locally this is invisible; the
filesystem seeks to the end in microseconds. Over HTTP it is the entire ballgame. A
player reading progressively from byte zero gets the payload it cannot interpret and
keeps reading, waiting for an index that arrives only after the last byte of a
multi-gigabyte file.

This is where the two halves meet: a player can only skip ahead to fetch the trailing
index if the server supports range requests. Given Accept-Ranges: bytes, a browser
asks for the tail, finds moov, and starts playing in a second. Without it, the same
file on the same network takes as long to start as it takes to download in full — and a
24/7 camera writes files that are
large enough for that to be measured in minutes, not seconds.

The permanent fix, where you control the muxing pipeline, is to relocate the index to the
front of the file — the transformation FFmpeg exposes as -movflags +faststart, which
rewrites the file with moov ahead of mdat. Note that it is a genuine second pass over
the bytes, which on a phone is not free: it is real I/O against storage that is already
being written to continuously.

A disambiguation worth stating, because these two get conflated constantly: this is not
the case where a recording was interrupted and the index was never written at all. Here
the file is complete and healthy. Every byte is present and correct. It simply arrives in
an order that is wrong for a network.

Safari is the strictest client, and that is useful

If you only ever test in Chrome on a laptop, you will ship a server that half-works.

Safari sends a small opening range request before it will commit to a <video>
source — in practice a request for the
first couple of bytes — and if what comes back is a 200 rather than a 206 with proper
range headers, it moves on to the next source in the list. If every source answers the
same way, it renders nothing. No error in the page, no half-loaded player: an empty
element.

Treat this as a free conformance test rather than a Safari quirk. On a LAN camera the
client population is every browser in the household — an iPad in the kitchen, an old
Android tablet, someone's work laptop with a managed policy. Safari is simply the one
that tells you immediately.

How to check it in thirty seconds

From any machine on the same network, ask the server for a slice and look only at the
status line:

curl -s -D - -o /dev/null -r 0-1023 http://192.168.1.42:8080/recordings/clip.mp4

206 Partial Content with a Content-Range — working.
200 OK with the full Content-Length — the header was ignored. Seeking will appear to work in Chrome while transferring the whole file, and will not work at all in Safari.
405 — you sent the range on the wrong method, or a proxy rewrote it.

Then do the same with -I to confirm HEAD is answered at all.

Why this bites harder on a phone than on a CDN

Every hosted video platform solved this years ago, which is why it is easy to forget it
is a problem. On a device-hosted server the constraints are meaner in three specific
ways.

The files are bigger relative to the pipe. A LAN link is fast but the phone's radio is
shared with everything else in the house, and
the numbers Android actually negotiates are often well below the figure on the router's
box.
Sending a two-gigabyte file to satisfy a scrubber drag is not a rounding error there.

The server and the camera are the same device. Bytes you send unnecessarily are bytes
read from the same storage the recorder is writing to, using the same CPU that is running
the encoder, on a battery that is also charging. A naive full-file response is not just
slow; it competes with the job the phone is actually there to do.

And there is no operations team. Whoever installed the app is the sysadmin, and the only
symptom they will ever report is "the video does not work on my iPad." Getting the
protocol right is how you avoid ever having that conversation.

If you are building something similar, the longer write-up of the live-view side —
which is a genuinely different problem with a genuinely different shape — is here:
How an Android Phone Serves Its Own Live Camera Feed Over Your LAN: An Embedded Ktor Server Deep-Dive.
And if you want the other classic way a phone-hosted camera goes quiet without erroring,
Android's camera foreground service type does not cover the microphone.

Background Camera RemoteStream records with the screen off, keeps footage on the
device rather than in anyone's cloud, serves a live view from a built-in web server to
any browser on your own network, and can stream to YouTube Live. No account, no
subscription. Built in Kotlin on Camera2 with an embedded Ktor server, across 75+
AI-assisted development sessions.

Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam
Site: https://superfunicular.com

If you have implemented ranged playback against a device-hosted server and hit something
that is not in here, I would like to read about it in the comments.

DEV Community: Super Funicular

Which Faults Actually Disqualify an Old Phone From Camera Duty? A Triage List, Including the One We Get Wrong

The fault that ends a phone's life is the one this job does not use

The piece of glass nobody inspects

Triage table

The five-minute inspection

An honest note about our own line

What this list deliberately does not settle

What to do this week

The Loopback Line: Why a Phone Serving Its Own Camera Page Gets Fewer Browser APIs Than localhost

The line itself

The sentence that isn't there

What lands on the untrusted side of the line

Mixed content, and the trap in the middle of it

What changed in 2026, and why it doesn't rescue you

So why not just serve HTTPS?

The design consequence

The honest trade

The Offence Is the Listening, Not the Recording: A Real Estate Commission's Own Answer on Cameras During a Showing

The federal definition is built around acquisition, not storage

A licensing regulator answers the question directly

The sentence that reaches a phone

The video half is left standing

Why the obvious fix is the wrong one

What this does not settle

What to do with this

What I could not verify

Why Your Phone Security Camera Uses Mobile Data on Shared Wi-Fi - Captive Portals, Explained

Why does my phone security camera use mobile data when it is connected to Wi-Fi?

Android tracks two separate bits, and most people only know about one

What Android does about it

The part I did not expect: you cannot ask for a network that works

The "Ignore" button is a bigger decision than it looks

The two-network test

Where this bites hardest

The practical setup order

This week on @Digital_Nomad_Media — 25 new clips (2026-W38)

I also built an app — DigiCam

The State's Own Poster Has a Box for Hidden Cameras: Connecticut's Monitoring Law and a Phone on a Shelf

The hardware is in the definition by name

The carve-out is narrower than the reason people reach for a phone

The notice is the posting

What changes at the start of October

The suspicion branch is real, and it is bounded

The subsection most write-ups skip

What enforcement actually looks like

What to do with this

What I could not verify

Your Phone Camera's Frame Rate Never Reaches the File - What Android Actually Writes Into an MP4 Timeline

Does an MP4 recorded on Android store a frame rate?

The frame rate is a hint, and the documentation says where it stops

What the muxer receives instead: one timestamp per frame

What the container actually stores

Where the spacing is documented to move

The last frame is a special case, and it is easy to miss

Why any of this matters outside a codec discussion

What to check on your own footage

The short version

Android's September 30 Verification Deadline — What "Verified Developer" Does and Doesn't Tell You About an App

What the deadline covers, precisely

What "verified" certifies — and what it does not

For camera apps, the gap is widest

Where we sit

MantaxOtax Didn't Exploit Anything to Watch Your Screen — And That's the Part Worth Reading

There is no exploit in the capture path

So "it can record with the screen off" tells you nothing

The questions that actually discriminate

Where we actually sit

Every Guide Says "Reserve the Address on Your Router." What If the Router Is Not Yours?

What if you cannot open your router's admin page?

Why does a phone camera's IP address change?

Check the phone first: the setting people blame, and what the documentation actually says

The three things you can do without touching the router

1. Read the address off the phone, not off a bookmark

2. Keep the phone on the network, continuously

3. Set the address manually — carefully, and last

A test you can run this week

What you give up, stated plainly

Related reading

Sources