DEV Community: Super Funicular

Pin the Camera App: How to Stop Someone Closing Your Phone Security Camera Without Locking the Phone

Super Funicular — Tue, 01 Sep 2026 07:15:40 +0000

If you have put an old Android phone on a shelf to watch your shop, your gate, or the room where your children sleep, you have already solved the hard problems. The phone records with the screen off, keeps the video on the phone itself, and shows you a live picture in a browser on your own network.

Then a cousin picks it up to see what it is. A customer waiting at the counter taps the screen. A child presses the round button at the bottom, because pressing it is what that button is for. And the job stops.

Nobody attacked your camera. Somebody was curious, and Android did what it is designed to do: it went home.

There is a setting for this. It has been in Android since 2014, it is free, it takes about forty seconds, and in two hundred articles on this blog I have never once written about it. This is that article.

How do you stop someone from closing your phone security camera app?

Short answer: Turn on Android's built-in app pinning — Settings, then Security (or Security & privacy), then App pinning — and pin the camera app before you walk away. Google describes it plainly: "You can pin an app's screen to keep it in view until you unpin it." With the screen pinned, the Home and Overview buttons are hidden and other apps cannot be opened, so a casual tap can no longer stop your recording.

Can you lock an Android phone to one app?

Short answer: Partly. Android has two versions of this. The one you can turn on yourself is screen pinning, and Google states directly that with it "the person using the device can exit the mode whenever they want." The truly locked version is lock task mode, and it requires a device policy controller — an enterprise management setup — which is out of reach on an ordinary phone. Pin the screen for the accidental exit. Do not sell it to yourself as a lock.

That distinction is the whole article, so here it is in Google's own words before anything else. From the lock task mode documentation:

"Lock task mode and screen pinning are sometimes used interchangeably. Screen pinning appears similar (and provides an immersive experience) but the person using the device can exit the mode whenever they want."

Two names, two very different guarantees, and almost everything written about this online blurs them together.

The failure this actually prevents

Be honest about the threat, because the threat is not a burglar. A person who wants to stop your camera and knows how will stop it — hold the power button, or pull the plug out of the wall. Screen pinning does nothing about either, and I am not going to pretend otherwise.

What it is genuinely good at is the failure that actually happens in a house or a shop: somebody touches the phone without meaning to end anything. The nephew checking whether it plays videos. The shop assistant picking it up to see the time. The toddler. Google's own example for the feature is exactly this — "you can pin an app and hand your phone to a friend. With the screen pinned, your friend can use only that app." A mounted camera is a phone you have handed to everyone who walks past it, permanently.

There is a second benefit that surprised me. Google's Android 5.0 notes say that once screen pinning is active, "users cannot see notifications, access other apps, or return to the home screen, until your app exits the mode," and that "the status bar is blank, and user notifications and status information are hidden." I have written a whole article about what a mounted camera phone silently displays to the room — message previews, sender names, calendar entries — and a longer walkthrough of using Private Space to hide the apps behind them. Neither mentions pinning, and pinning does a good part of that job as a side effect of one toggle.

Turning it on, in order

The path has moved between Android versions and manufacturers, so expect to hunt slightly.

Open Settings. Google's general instructions say Security or Security & location, then Advanced, then App pinning. On newer Pixel devices it is Security & privacy, then More security settings, then App pinning. In 2014 it was Settings, Security, Screen Pinning. If yours is somewhere else again, that is normal — Google's own help page ends with "If you can't find it, get help from your device manufacturer."
Turn the toggle on. On Pixel Tablet the switch reads Use app pinning; elsewhere, App pinning.
Open the camera app and get it into the state you want left running. Pinning preserves what is on screen; it does not configure anything for you.
Open the Overview / Recents screen and pin the app from there.
Test the exit before you walk away. Google documents three unpin gestures: gesture navigation, "Swipe up and hold"; 2-button navigation, "Touch and hold Back and Home"; 3-button navigation, "Touch and hold Back and Overview."

A tip that costs nothing: do step 5 twice, once with the screen freshly woken. The gesture is unusual enough to forget, and a camera phone is a device you may not touch again for weeks.

The credential prompt, and a contradiction worth knowing about

You would like the phone to demand a PIN before anyone unpins it. That option exists — but whether you get a choice about it is unclear from Google's own documentation, because its two help pages say different things.

The general Android help page states it as automatic:

"When app pinning is on, you need to enter your PIN, pattern, or password before you can unpin."

The Pixel Tablet help page states it as an option you are offered:

"When app pinning is on, you'll see an option to ask for your PIN, pattern, or password before unpinning."

Both are first-party Google pages, they do not agree, and neither quotes the exact wording of the switch. So verify it on your own device rather than trusting either page, or this one. Pin the app, try to unpin it, and see whether you are challenged. If you are not, go back into app pinning settings and look for the toggle. It is the only thing standing between "a curious person cannot casually exit" and "a curious person cannot exit at all."

The stronger version you probably cannot have

Since somebody always asks: yes, Android can genuinely lock a device to one app. It is called lock task mode, and the documentation is clear that it is not for individuals.

"Only apps that have been allowlisted by a device policy controller (DPC) can run when the system is in lock task mode."

With a DPC in place, an administrator gets the controls you actually wanted. They can suppress the menu that appears when you long-press power — "a user typically can't power off the device if you disable this dialog." They can mute and lock the volume. They can make an app the device's home app so "it's launched automatically when the device starts up."

To get there you must establish a device owner, and the documented route runs through adb shell dpm set-device-owner on a device with no accounts on it. That is a factory reset, a computer, a cable and a command line — for a phone that was meant to be the cheap, low-effort option. For a shop owner with one spare handset that is not a realistic path, and I would rather say so than write a tutorial nobody can follow.

So: the weak version is one toggle away, the strong version is behind an enterprise setup. Use the weak version, and know what you have.

What the documentation does not tell you

Six real gaps. I went looking for each in Google's own pages and did not find them.

Whether pinning survives a reboot is not documented anywhere I can find — not the Android help page, the Pixel page, the lock task guide, the Android 5.0 notes, or the CDD. No Google page says it persists; none says it is cleared. If you live somewhere with regular power cuts, this is the gap that matters most to you, and you can close it yourself in two minutes: pin the app, restart the phone, look. A camera that comes back unpinned after every outage needs somebody to walk over and re-pin it — and a power cut and an internet outage already do very different things to a phone camera.
What happens when the screen turns off and back on while pinned is not documented either. The nearest statements are about lock task mode, and I will not extrapolate one to the other.
Whether you can still drag down the notification shade while pinned is not stated for screen pinning. The blank-status-bar language is there; the shade itself is only addressed as something a device policy controller can toggle.
Nothing addresses incoming calls, in either mode, on any page I read.
The power button under user screen pinning is never discussed. Everything about suppressing the power menu belongs to the enterprise path.
The exact on-screen label of the require-a-PIN switch is never quoted — which is precisely why two help pages can contradict each other without either being obviously wrong.

Will your phone even have this?

Almost certainly — and this is the good news if you are running an older or budget handset. Screen pinning arrived in Android 5.0 ("Android 5.0 introduces a new screen pinning API that lets you temporarily restrict users from leaving your task or being interrupted by notifications") and it is not optional for manufacturers. The requirement is still in the Android 16 Compatibility Definition Document:

"MUST implement the screen pinning behavior and provide the user with a settings menu to toggle the feature."

There is a condition attached — it applies to implementations that include the recents navigation key — but in practice, if your phone has a Recents button or gesture, the feature is supposed to be there. A phone from 2016 running a forgotten version of Android has this. No new device, no subscription, no account.

The five-minute version

Turn on App pinning in Settings (Security, or Security & privacy).
Open the camera app, get it into the state you want, pin it from Recents.
Check whether unpinning asks for your PIN. If not, find that option and turn it on.
Learn the unpin gesture for your navigation mode, and practise it once.
Test a reboot, because nobody has documented what happens after one.
Remember what you bought: protection against the accidental exit, not against a person who means it.

Background Camera RemoteStream works on the same principle — an old Android phone recording with the screen off, video kept on the device rather than on somebody's server, and a live view you open in a browser on your own network with nothing to install on the second device. Pinning is a good companion to that, because a camera any passer-by can close is not really unattended. It is on Google Play, and there is more at superfunicular.com.

Sources

Android Help, "Pin & unpin screens": https://support.google.com/android/answer/9455138?hl=en
Pixel Tablet Help, app pinning: https://support.google.com/googlepixeltablet/answer/13592197?hl=en
Android Developers, "Lock task mode": https://developer.android.com/work/dpc/dedicated-devices/lock-task-mode
Android Developers, dedicated devices cookbook: https://developer.android.com/work/dpc/dedicated-devices/cookbook
Android 5.0 platform highlights (screen pinning): https://developer.android.com/about/versions/lollipop/android-5.0
Android 16 Compatibility Definition Document, section 3.8.3: https://source.android.com/docs/compatibility/16/android-16-cdd

You Don't Live There: Setting Up a Phone Camera in a House You Only Visit

Super Funicular — Mon, 31 Aug 2026 21:08:10 +0000

Almost every practical instruction I have written about home cameras ends the same way: go back and have a look at it.

Set it up where it will really live, then check on it the next day. Have somebody walk the path at a normal pace, then open the file and see what you actually got. Turn the power off deliberately and watch what the thing asks for when it comes back. That is all good advice. Every line of it quietly assumes something I have never said out loud, which is that you can walk back into the room.

Plenty of these cameras are not in the room. They are in a parent's front hall, in a place somebody lets out, in a house that is only lived in at weekends. Whoever sets it up is a visitor there. They get an afternoon. The next chance to change anything is weeks away and involves a journey.

That changes what a good decision looks like, and not in the direction people expect.

Iterating is a privilege of proximity

At home, the right move is usually to try something and adjust it. Put the camera up, live with it, notice that the hedge fills the top third of the frame in July, move it six inches. The setup improves over a few weeks because you keep walking past it. Every "just tweak it later" recommendation is written for that person.

Somewhere you visit, an arrangement that would benefit from adjusting is an arrangement that stays wrong. There is no later. There is one afternoon, and then there is however many months until the next one.

So the thing to optimise for is not the best placement. It is the placement with the smallest downside if it turns out to be mediocre, and the fewest ways to quietly stop working while nobody is looking.

What "dull" means in practice

A view that will still make sense in December. Foliage, sun angle, and what the room is used for all move with the season. A frame that is perfect in August and useless in November is a frame you will not be there to fix.
A surface nobody needs. A shelf that gets tidied, a windowsill that gets a plant, a hall table that collects post — all of these are places a camera gets nudged, turned, or moved into a drawer. Pick the boring corner nobody has a plan for.
A socket nobody will want back. This is the one that quietly ends most remote setups. A phone running as a camera needs mains power indefinitely, and if it is sharing the only reachable outlet with the kettle or the vacuum, it will lose that argument.
Wi-Fi where the phone actually sits, not where you tested it. Signal in the hall is not signal behind the bookcase in the hall. Check it in the final position, before you leave.
Something that comes back on its own after a power cut. Power will go out at some point in the months you are not there. A setup that needs a human to tap something afterwards is a setup that has ended.

None of this is exciting. That is the point. A remote install is judged on how it behaves unattended for six months, not on how clever it looks on the day.

The person who lives with it did not choose it

There is a second constraint that gets skipped almost universally, and it has nothing to do with placement.

Somebody lives in that house. They did not pick this camera. They are not going to troubleshoot it. They are the one it sits beside all day, every day, long after the person who installed it has driven home.

That means the only control that genuinely has to work is the one that switches it off — and it has to be theirs, without a phone call first. Not "call me and I'll stop the stream." Not a login they do not have. Something they can reach and act on in the room they are standing in.

Anything more demanding than that is a job handed to somebody who never applied for it. It is also, in practice, the difference between a camera that is still there next year and one that has been unplugged and put in a cupboard with no explanation.

If the setup cannot survive the resident turning it off whenever they feel like it, the setup was wrong. Consent that has to be re-negotiated by telephone is not consent, it is an obligation.

Do the checking while you are standing there

The last thing worth saying is about sequencing. Every verification step in every guide I have written takes about two minutes in person, and is close to impossible from a hundred miles away:

Put the phone in its final position, powered, on the network.
Walk the path you actually care about, at a normal pace. Not a slow demonstration walk.
Open the resulting file or stream and look at it. Do not assume — look.
Pull the power for thirty seconds, restore it, and watch what happens without touching anything.
Show the resident the off switch, and watch them use it once.

Do all five before you leave. Every one of them that you defer becomes a question you cannot answer from home, and the honest answer to most of those questions turns out to be "no, it was not recording."

Where the software fits

Most of the above is placement and social arrangement, not software — but the software choice does interact with it in one specific way. A remote install is easier to get right when the recording lives on the device rather than routing through an account and a metered plan, because there is one fewer thing to expire, re-authenticate, or start charging while nobody is watching.

I make one of the apps in this category, Background Camera RemoteStream — an Android app that turns a spare phone into a camera you can check on, with the recording kept on the device. I am not going to claim it is the only thing that does this; there are other apps and self-hosted options, and some of them are good. But if you want to try the approach on a phone you already own, it is free:

Play Store: https://play.google.com/store/apps/details?id=com.superfunicular.digicam
More on the approach: https://superfunicular.com

The general point stands whatever you install. Advice written for a camera you walk past every day is the wrong advice for a camera in a house you visit twice a year. Different constraint, different answer.

Android Guarantees Six Concurrent Video Encoder Sessions - and Your Old Phone Is Probably Exempt

Super Funicular — Mon, 31 Aug 2026 20:19:13 +0000

Short answer: Android's Compatibility Definition Document does require six concurrent hardware video encoder sessions — but only from devices that declare a Media Performance Class. A budget or older handset that reports MEDIA_PERFORMANCE_CLASS = 0 is exempt from that requirement entirely. The only number that describes your phone is getMaxSupportedInstances(), and its own documentation calls it "a hint for an upper bound." If you are building a 24/7 camera app, the encoder is a second scarce resource with its own limit, its own advertising API, and its own way of being taken away from you.

I wrote up the camera side of this question a couple of weeks ago: whether a phone can record and live-stream at once depends on its Camera2 hardware level, because Android publishes a table of stream combinations every device must support, and the lowest tier caps two simultaneous consumers at preview resolution.

That article was only half the story, and a reader-shaped hole has been sitting in it since.

Camera2's guarantee is about frames leaving the sensor. It says nothing about what happens after. Two camera output surfaces are not two videos — they are two sources of raw frames that still have to be compressed by something. On any modern Android device that something is a fixed-function hardware block, and there are not very many of it.

The camera can hand you two streams and the encoder can still say no.

How many video encoder sessions can an Android phone run at the same time?

There is no single answer, and the reason is structural rather than evasive. Android specifies a floor, but it applies the floor conditionally. Devices that opt into the performance-class system inherit a hard requirement; devices that do not, do not. Below is what the Compatibility Definition Document actually says, requirement 5.1/H-1-4, which lives in section 2.2.7.1 (Handheld Media Performance) rather than in the general video encoding section:

CDD	Media Performance Class	Concurrent hardware encoder requirement
Android 11	`R`	6 sessions (AVC or HEVC), any codec combination, at 720p@30fps
Android 12	`S`	6 sessions (AVC, HEVC, VP9 or later) at 720p@30fps — "Only 2 instances are required if VP9 codec is present"
Android 13	`T`	6 sessions (AVC, HEVC, VP9, AV1 or later) at 1080p@30fps
Android 14	`U`	6 sessions of 8-bit (SDR) encoders — 4 at 1080p@30fps and 2 at 4K@30fps
Android 15 / 16	`V`	Same 4×1080p + 2×4K split, plus "there MUST NOT be more than 1 frame dropped per second"

Two things in that table matter more than the numbers.

The first is the 720p→1080p migration between Android 12 and 13. If you read a Stack Overflow answer from 2021 that says "six encoders at 720p" and you are targeting a modern device, that sentence has quietly changed meaning underneath you.

The second is the qualifier that every one of those rows carries, and that almost nobody quotes with them. Each requirement is introduced with a conditional: if the device returns a given constant for MEDIA_PERFORMANCE_CLASS. A handset that declares no performance class at all — which is the default, and which is what an enormous number of shipping budget devices do — is not in breach of anything when it supports two encoder instances instead of six. It was never asked for six.

This is the part that matters if the phone you are targeting cost $80 and shipped four years ago. The reassuring number in the spec is not a promise to you.

The number that does describe your phone

The CDD's companion requirement, 5.1/H-1-3, is the useful one, because it is about disclosure rather than capability. Devices MUST advertise the maximum number of concurrent encoder sessions "via the CodecCapabilities.getMaxSupportedInstances() and VideoCapabilities.getSupportedPerformancePoints() methods."

So the phone will tell you. You have to ask.

MediaCodecList list = new MediaCodecList(MediaCodecList.REGULAR_CODECS);
for (MediaCodecInfo info : list.getCodecInfos()) {
    if (!info.isEncoder()) continue;
    for (String type : info.getSupportedTypes()) {
        if (!type.equals(MediaFormat.MIMETYPE_VIDEO_AVC)) continue;
        int max = info.getCapabilitiesForType(type).getMaxSupportedInstances();
        Log.i(TAG, info.getName() + " -> " + max);
    }
}

getMaxSupportedInstances() has been available since API 23, and on the device side it is not a computed value — it is read from a static configuration file the OEM ships. The AOSP integration docs describe the exact knob: a <Limit name="concurrent-instances" max="…" /> element inside the codec's entry in /etc/media_codecs.xml, enforced at certification time by a CTS test named testGetMaxSupportedInstances.

That has a consequence worth internalising. The value is a vendor's declaration, checked once, about a static ceiling. It is not a live measurement of what is free right now. The javadoc is unusually candid about this:

"This is a hint for an upper bound. Applications should not expect to successfully operate more instances than the returned value, but the actual number of concurrently operable instances may be less as it depends on the available resources at time of use."

Read that twice if you are writing an always-on app. It says the ceiling is real and the floor is nothing. You can query a 4, be the only camera app running, and still fail to allocate your second encoder — because a video call, a screen recorder, or the OS itself got there first.

getSupportedPerformancePoints() is the companion API (added in API 29), and it carries the concurrency caveat explicitly: performance points "assume a single active codec," and for multi-codec use cases you are told to take the highest pixel count and add the frame rates of each individual codec. It is also allowed to return null — notably on devices upgraded to Android 10 or later without a corresponding vendor image update, which describes a lot of long-lived hardware. Plan for the null.

Two failures that look identical and are not

When allocation does not go your way, MediaCodec throws a CodecException, and the error code distinguishes two situations that a naive catch block will flatten into one.

ERROR_INSUFFICIENT_RESOURCE means, per the documentation, "required resource was not able to be allocated." You asked for an encoder and there was not one to give. Nothing of yours was disturbed. This is the polite failure: your existing sessions are intact, and the right response is usually to degrade — drop the second stream to a lower resolution, or run one instead of two — rather than to give up.

ERROR_RECLAIMED is the one that should change your architecture. It means "the resource manager reclaimed the media resource used by the codec." Something else on the device wanted an encoder, the system decided that something outranked you, and it took yours. The documentation is blunt about what you are allowed to do next: "the codec must be released, as it has moved to terminal state."

That last clause is easy to skim past and expensive to get wrong. A reclaimed codec is not retryable in place. It is not a transient hiccup you can sleep on and resume. CodecException exposes two predicates — isRecoverable(), which means you can stop(), configure(), and start() your way back, and isTransient(), which means resources are temporarily unavailable and the call may be retried later — and the docs note the two are never true at the same time. Reclaim is documented as neither. The object is dead; you rebuild from scratch, and you decide what your app looks like in the interval.

For a recorder that is meant to run unattended for weeks, "what your app looks like in the interval" is the entire design problem. Nobody is holding the phone. Nobody will tap Retry.

Who wins, and how honest the documentation actually is

Here is where I want to be careful, because this is the point at which most write-ups start asserting things that the official documentation does not say.

The public docs describe reclaim in terms of priority between processes, not in terms of foreground and background. The SoC integration guide says a vendor error code is used by the media resource manager "as the indicator to potentially preempt media resource from other lower priority process," and the vendor-facing priority knob it documents, OMX_IndexConfigPriority, has exactly two levels — realtime and best-effort — on an inverted scale where a higher number means lower priority. It is explicitly framed as "a hint used at codec configuration and resource planning."

Since Android 15 there is an app-facing knob too: MediaFormat.KEY_IMPORTANCE. The resource manager "may use the codec importance, along with other factors when reclaiming codecs from an application." Two qualifications come attached to it in the same documentation, and both limit how much you should lean on it. "The specifics of reclaim policy is device dependent." And the value is "only relevant within the context of that application" — it lets you tell the system which of your own codecs to sacrifice first. It is not a way to outrank someone else's video call.

What I could not find in any official Google documentation is a statement that the media codec resource manager considers whether your app is in the foreground. It is a reasonable inference from how the AOSP implementation derives process priority, and in practice foregrounded apps do tend to win. But it is an inference from source, not a documented contract, and a documented contract is the only thing you can safely design against. If someone tells you a foreground service is therefore safe from encoder reclaim, ask them for the page. I looked, and I do not believe it exists.

The one piece of unambiguous official guidance is aimed at the other side of the problem — being a good citizen rather than a protected one. The stop() javadoc says plainly that to ensure the codec is available to other clients you should call release() and "don't just rely on garbage collection to eventually do this for you." That is worth honouring even when you are the app that wants to keep running, because in a world of two encoder instances, the app that holds one it is not using is the reason someone else's recording just died.

What this means if you are building one of these

The design conclusions are unglamorous and they hold across the whole category:

Query, never assume. getMaxSupportedInstances() at startup, per codec, and branch on it. A model-name allowlist is a bug with a maintenance schedule.
Treat one encoder as the honest baseline. Two is an optimisation you attempt and fall back from. On a non-performance-class device it is not owed to you by anything.
Handle ERROR_RECLAIMED as a lifecycle event, not an error. Release, rebuild, and — for an unattended recorder — decide explicitly whether the file keeps rolling while the stream does not. That asymmetry is usually the right answer, because the recording is the artifact and the live view is a convenience.
Release aggressively. Every second you hold an encoder you are not writing frames into is a second you are the problem.

This is the same shape as what the low-memory killer does to a long-running camera service, and the same shape as what happens when two apps want the lens at once: Android hands a long-lived background workload a set of resources that were designed around a user holding the phone and looking at it. Nothing about a 24/7 recorder is the case these systems were tuned for. The work is in noticing that early and building the fallback before the device forces you to.

Background Camera RemoteStream is built around exactly this constraint — recording with the screen off, with a live view served over your own network, on hardware that is usually several years old and rarely generous. More on the architecture at superfunicular.com.

Sources: Android Compatibility Definition Documents for Android 11–16 (§2.2.7.1, requirements 5.1/H-1-3 and 5.1/H-1-4), source.android.com; MediaCodecInfo.CodecCapabilities, MediaCodecInfo.VideoCapabilities, MediaCodec.CodecException and MediaFormat API reference, developer.android.com; media codec OEM and SoC integration guides, source.android.com. CDD figures were read from the version-specific documents and reflect the requirement text as published for each release; Android 17's CDD moves these counts out into a separate Media Performance Class definition, so the figures above are quoted through Android 16.

The One Thing a 24/7 Recorder Never Deletes: Android Now Caps How Many Keystore Keys an App Can Own

Super Funicular — Sun, 30 Aug 2026 22:55:52 +0000

Three things pile up inside a long-running Android recorder: files, database rows, and keys.

Two of those get cleaned up, because you can watch them fill the disk. Somebody notices the phone is full, somebody writes a rotation job, and the problem arrives in a unit everyone already understands. Keys are different. A key alias occupies no space you can look at in Settings, appears in no file listing, survives every clean-up you write for the other two, and until recently had no ceiling.

Android 17 gives it a ceiling. The ceiling is a number, and for at least one common design it is a number you reach.

What the platform actually says

From the Android 17 behavior changes for all apps, under Per-app keystore limits:

"Apps should avoid creating excessive numbers of keys in Android Keystore, because it is a shared resource for all apps on the device. Beginning with Android 17, the system enforces a limit on the number of keys an app can own."

The figures are in the same paragraph: "The limit is 50,000 keys for non-system apps targeting Android 17 (API level 37) or higher, and 200,000 keys for all other apps."

The failure is typed: "If an app attempts to create keys beyond the limit, the creation fails with a KeyStoreException."

Three things in that are worth more than the headline number.

The limit is not opt-in. An app that has not raised its target level is not exempt from the cap; it gets the larger of the two figures. The page closes the last door explicitly — "System apps have a limit of 200,000 keys, regardless of which API level they target." There is no exempt category. There is only a version where the wall is further away.

Keystore is described as a shared resource. That is the platform's own framing, and it is the part that explains the change. Your key count is not a private matter between your app and its own storage. It is a draw on something every app on the device draws on.

The error code depends on what you target, and the difference is unkind. An app targeting Android 17 gets a purpose-built code back from getNumericErrorCode() — the page calls it "returns the new ERROR_TOO_MANY_KEYS value". Everything else gets ERROR_INCORRECT_USAGE, the generic code for a malformed request. On the large majority of installed devices, in other words, hitting a platform quota will arrive at your crash reporter wearing the label of a programming mistake. The message string carries the real story — "The exception's message string contains information about the key limit" — but a message string is the one part of an exception that dashboards group away.

Why a recorder is the shape that reaches it

Most apps will never approach 50,000 keys, and Google clearly expects that. The apps that get near it are the ones that mint a key per artifact rather than a key per install, and a continuous recorder is the purest example of that shape: it produces artifacts on a fixed clock, forever, with no user action in between.

The arithmetic is not close to the edge in every design, which is exactly why it is worth writing down rather than worrying about:

key granularity	new keys per day	days to 50,000	days to 200,000
one per five-minute segment	288	174	694
one per ten-minute segment	144	347	1,388
one per motion clip, forty a day	40	1,250	5,000
one per hour	24	2,083	8,333
one per calendar day	1	50,000	200,000

Read the first row again. A camera on a five-minute segment clock, encrypting each segment under its own hardware-backed key, exhausts a targeted app's entire allowance in under six months of continuous operation. That is not an exotic setup. Five minutes is a common segment length precisely because it bounds how much you lose to a single interrupted write.

The second column is the one that decides your fate, and it is a design choice, not a platform constraint. Nothing about encrypting recordings requires a fresh Keystore key per file. The usual pattern is one long-lived Keystore key that wraps a cheap per-file key stored beside the file — the Keystore entry count stays at one no matter how long the camera runs. If you are already doing that, this change is a non-event for you, and you should stop reading here with a clear conscience.

The failure mode is not the one you would guess

The interesting case is not the app that deliberately creates 50,000 keys. It is the app that deliberately creates a few and then never deletes any.

Deleting a recording is a file operation. Deleting the key that recording was encrypted under is a separate call to a separate subsystem, in a separate part of the codebase, with no error if you skip it and nothing visible anywhere if you skip it a thousand times. Every rotation job I have read the description of is written against a storage budget, because storage is what runs out. Nothing runs out on the alias side — or nothing did.

The cheapest design to write is the one that never deletes anything it does not have to. Android 17 turns that from a tidiness question into a failure with a number attached.

What the page does not say, and I am not going to guess

Being precise about the boundary of what I know here matters more than sounding authoritative, so:

Whether deleting an alias frees a slot. The wording is a limit on "the number of keys an app can own", which reads as a live count rather than a lifetime tally — under that reading, KeyStore.deleteEntry() gives the slot back. The page does not say so. I have not tested it, and I am not going to assert it.
How the count is scoped across users and profiles. Keystore entries are per-app-per-user. Whether the quota is applied per user or across all of them is not stated on the page.
Whether StrongBox-backed and TEE-backed entries share one budget. Not stated.
When it lands on any given handset. This is an Android 17 behaviour. Which phone gets Android 17, and when, is a separate question this page does not answer and neither will I.

Each of those is checkable by somebody with a device and an afternoon. None of them is checkable by reading, and reading is what I did.

How to find out where you actually stand

The count is readable in a few lines, and it is the first thing worth knowing:

val ks = java.security.KeyStore.getInstance("AndroidKeyStore")
ks.load(null)
val aliases = java.util.Collections.list(ks.aliases())
android.util.Log.i("keys", "alias count = " + aliases.size)

Run it on a device that has had a build of yours on it for months rather than a fresh emulator. A clean install always looks fine. The whole point of this class of bug is that it is a function of elapsed time, and elapsed time is the one variable a test suite does not have.

If the number surprises you, the fix is boring and cheap: delete the alias in the same code path that deletes the artifact it belongs to, and treat a leftover alias as a leak the same way you would treat a leftover temp file.

This is not the storage argument

It looks adjacent to one and it is not. How many bytes a continuous recorder produces, how long you can keep them, and what happens when the card fills up is a genuinely different question with genuinely different arithmetic, and I have written it out at length in Storage, Not Heat, Is the Real Limit on 24/7 Android Recording — that piece is about bytes, this one is about aliases, and the two budgets are exhausted by different designs at different rates. Likewise, a file that will not open after an interrupted write is a container problem, not a key problem.

The reason it is worth separating them is that the storage budget is visible and the key budget is not. You will find out about the first one from a user. You will find out about the second one from a stack trace that says you passed a bad argument.

The short version

Android Keystore now has a per-app cap: 50,000 entries for apps targeting Android 17, 200,000 for everyone else and for system apps, and a KeyStoreException when you cross it. Most apps will never notice. An app that mints a key per recorded artifact and never deletes one will.

The date it finds out is set by its segment length. Segment length was picked to bound how much a single interrupted write costs you — chosen once, years before anybody had a reason to count keys, to settle a completely different argument.

We build Background Camera RemoteStream, an Android app for running a phone as a camera with the screen off. More of these write-ups at superfunicular.com.

Sources, all first-party: Android Developers, Behavior changes: all apps for Android 17 (last updated 14 August 2026), section Per-app keystore limits — the 50,000/200,000 figures, the shared-resource rationale, the KeyStoreException, and the ERROR_TOO_MANY_KEYS / ERROR_INCORRECT_USAGE split; and the API reference for KeyStoreException and KeyStore.

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

Super Funicular — Sun, 30 Aug 2026 14:03:49 +0000

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

One, two, who, what? ✌️🤠

22s

August 13, 2025

15s

Why my dog is not a baseball star ✌️🤠

22s

Dog Gone Good Times ✌️🤠

51s

Oh no my Pampers! ✌️🤠

16s

No

The great furry hunter ✌️🤠

23s

Crib tours with

28s

Introducing....... "THE PAPERWORK ASSASSIN"

60s

The choir

Wonderful! ✌️🤠🌹

The rope broke

I bought a tiny helicopter for the little people that live under my sink ✌️🤠

23s

They won the whole thing ✌️🤠

57s

Masked Robber's UNPLANNED Heist Caught on Camera!

16s

Directly into my soul

15s

Good morning

25s

Do the chicken dance

15s

Gotta ya!

12s

Boogie Boogie Baby!

17s

Thinking of you guys

Keep your questions to your self

30s

Dog throws man buck naked out the car in hotel parking lot 🤣

60s

You know what the Cowboy Dog said to the other Cowboy Dog?

This is how the whole complex got banned by

51s

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 #travel #cajun #country #YouTubeShorts #ContentCreator #funny #vanlife

The EU's Reporting Clock Starts When Somebody Tells You: What the Cyber Resilience Act Asks of a Camera Vendor Who Cannot See Your Device

Super Funicular — Sun, 30 Aug 2026 12:55:40 +0000

On 11 September 2026 a European regulation starts a stopwatch on camera vendors, and the trigger that starts it is stranger than the deadline it sets.

The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024, and most of it does not apply until 11 December 2027. Two parts arrive early: Chapter IV, on the notification of conformity assessment bodies, applied from 11 June 2026, and the reporting obligations in Article 14 apply from 11 September 2026. The second one is the one that reaches a person working alone. The European Commission's page on the reporting obligations opens with a sentence that leaves little room: "As of 11 September 2026, manufacturers are required to report actively exploited vulnerabilities and severe incidents impacting the security of products with digital elements".

The windows are tight. From the same page: "They need to submit an early warning within 24 hours of becoming aware, and a full notification within 72 hours". A final report follows, no later than fourteen days after a corrective measure is available for an actively exploited vulnerability, and within a month for a severe incident. Everything goes to the national Computer Security Incident Response Team and to ENISA through one platform, which the Commission says "will be operational by 11 September 2026".

I build an Android app that runs a spare phone as a camera. I read this the way anyone with a product on a European store ought to read it, and I came out with a conclusion I had not gone looking for: the duty is easiest to discharge for exactly the architecture I spend most of my time arguing against.

The part small developers assume does not reach them

Two definitions in the Commission's summary of the legislative text do most of the work here, and neither contains the escape hatch a one-person shop expects to find.

A manufacturer, in this regulation, is a person who develops products with digital elements and markets them under their own name, "whether for payment, monetisation or free of charge". Free is not an exemption. A side project with an EU install base and no revenue sits inside the definition; the price was never the test.

And a product with digital elements is "A software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately". That second clause is where two camera companies with near-identical marketing copy stop resembling each other.

The regulated object is not where the icon is

Remote data processing has its own definition: "Data processing at a distance for which the software is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions".

That is a functional test rather than an ownership one. If a camera app cannot show you your own hallway without a relay in the middle, the relay is not a separate service the vendor happens to also operate. Remove it and a function of the product stops working, which is precisely the condition the definition describes.

So for a relay-based camera the regulated object is an app, a handset, a fleet of servers, an account system, and every session that crosses between them. For a camera whose video never leaves the building, the regulated object stops at the edge of the phone.

Two products, two very different perimeters, and until now no rule obliged either vendor to say which one they were selling.

The four words the whole thing turns on

Here is the sentence I keep returning to. On the manufacturer's duties, the summary says: "the manufacturer is required to notify actively exploited vulnerabilities and severe incidents having an impact on the security of the product that it becomes aware of".

That it becomes aware of.

The clock does not start when exploitation begins. It starts when the manufacturer finds out. Which makes the reporting record a measure of how much a vendor can see, and only indirectly a measure of how safe the product is.

There are four ways a vendor learns that something is being exploited in the field.

The first is telemetry the vendor built. The product reports on itself: crash traces, session metadata, anomaly counters, the ordinary exhaust of software that talks to its author.

The second is infrastructure. The vendor watches their own machines and notices a shape that should not be there. Authentication attempts arriving in a burst from one address range. A device requesting streams that belong to a different household.

The third is that somebody tells you. A researcher, a customer, a CSIRT, a reporter with a deadline and a screenshot.

The fourth is the one I nearly left out of this article, and leaving it out would have flattered me. Every app on Google Play gets crash and ANR reporting whether or not its developer builds any, and the Play Console documentation is plain about where it comes from: reports arrive "when an app crashes or is not responding on an Android-powered device whose user has opted in to automatically share their usage and diagnostics data". I did not implement that and I cannot switch it off. It is a real channel and I have it.

It is also a narrow one, in three ways that matter for this regulation. It reports crashes, not exploitation, and the overlap between those two sets is real but partial — plenty of memory-corruption bugs announce themselves as a stack trace, and plenty of successful attacks never crash anything. It covers only the opted-in subset of devices, so it is a sample of unknown size rather than a census. And it is aggregated and dated for product quality: Android vitals updates daily and Google Play "will generally consider the last 28 days of data", which is a sensible window for judging an app's stability and a poor one for a duty measured in twenty-four hours.

So a vendor running a relay has all four, and the first three are theirs, built for the purpose, and pointed at exactly the events the CRA asks about. A vendor whose product never contacts them has the third, plus a fourth that belongs to the app store, was designed to answer a different question, and would tell me an unusual number of my installs started crashing on Tuesday — which is a hint worth having and is not a report of an actively exploited vulnerability.

Which is a cost, and it is mine

I have argued more than once that a camera whose video never leaves your own network is a better arrangement than one that streams through a company's infrastructure, and I still think so, for the reasons I usually give. This is the invoice for that position, and I would rather hand it over myself than have it presented later.

Software that does not phone home cannot tell its author it is under attack. If someone worked out tomorrow how to reach a large number of these installations, the most I would see is whatever fraction of it made the app fall over on a device whose owner had opted into diagnostics, arriving in a dashboard that averages the last twenty-eight days. An attack that works cleanly does not crash anything, and nothing else on my side is collecting the numbers a chart of it would be drawn from. I find out when a person emails me. My twenty-four hours begin at that email and not one second earlier, and the interval between the first exploitation and that email is invisible to everyone, me included.

That is not something I can engineer away without turning into the other kind of company. Visibility and privacy are opposite ends of one wire. Pulling on either end shortens the other.

What the trade actually buys

The honest version is not that local-only is safer in some general way. It is that local-only has a smaller and differently shaped set of things that can go wrong.

A severe incident on a centralised camera platform is, by construction, one event with a large blast radius. One key, one storage bucket, one authentication check written the wrong way round, and the number of affected households is a property of the vendor's customer count rather than of anybody's home network. That is the failure that produces the news story, and producing it requires the vendor to have first built a place where everyone's video converges.

A product that never aggregates anything has no equivalent single point. Whatever goes wrong goes wrong one installation at a time: worse for the household it happens to, and much better for the population.

So from September the regime will generate two kinds of record, and on paper they will look alike. Vendors with visibility will file reports. Vendors without it will file nothing.

What I do not know

I do not know how the phrase severe incident is meant to read for a product with no service standing behind it. The concept is written for something operational, and software running entirely on hardware belonging to somebody else does not obviously have incidents in that sense. It has vulnerabilities, and the two are given separate deadlines in the text, which suggests the drafters had different things in mind for each.

I am also reading a summary rather than the Regulation. The Commission attaches its own warning to that document: "This summary has been prepared by the Commission services and is not meant to systematically cover the full scope of the Regulation". Treat everything above as a developer working through a document in public, not as advice from anybody qualified to give it.

Two details that cut against the drama

The first goes against every vendor, including me. The reporting duty reaches backwards: "Reporting obligations apply to all products with digital elements that have been made available on the Union market, including those already placed on the market before 11 December 2027". Nothing is grandfathered by having shipped early.

The second goes the other way, and it removes most of the fear from the timeline for anybody small. Under the penalties chapter, "manufacturers that qualify as microenterprises or small enterprises may not be fined for failures to meet the 24h deadline for reporting vulnerabilities and severe incidents". The obligation applies to a one-person developer; the fine for missing the twenty-four hours does not. That is careful drafting, and it means the pressure on a small vendor is reputational and procedural rather than financial.

Two things this gives a buyer, before any of it takes effect

A manufacturer has to fix a support period, and the summary is specific about how it is communicated: "The end date of the support period (including month and year) needs to be clearly and understandably specified at the time of purchase". A camera product that cannot name the month its security fixes stop is going to be out of step with that, and a great many of them cannot name it today.

And the reporting platform is not restricted to vendors: "It is also possible for any natural or legal person to notify vulnerabilities, cyber threats, incidents and near misses on a voluntary basis through the CRA Single Reporting Platform". The route around a vendor who does not answer their mail is being built into the same system that is about to start timing them.

The asymmetry to watch for

From September there will be a growing record of manufacturers reporting exploited vulnerabilities, and the names appearing in it most often will not be the least careful ones. They will be the ones whose products talk back to them. A filed report says something definite. An empty row says two entirely different things at once, and looks the same either way: the product was quiet, or its maker had no means of finding out.

Mine has the store's crash feed and the contents of my inbox, and neither was built to answer the question the Regulation asks. I would rather say that here than let a year of empty rows imply the flattering reading of it. What I owe in exchange is the direction I can still control: an address that reaches a person when somebody does find something, and a support-period date that is an actual date rather than a posture.

The app I build for this is Background Camera RemoteStream, which records and streams from a spare Android phone with the screen off. The rest of the writing on running an old handset this way is at superfunicular.com.

Related reading

Best free, no-subscription apps to turn an old Android phone into a local-only security camera — the comparison this regulation sits underneath: which apps keep footage on the phone and which ones do not.
Which free security camera apps quietly meter your free plan — the same question asked about bandwidth caps rather than disclosure deadlines.
Android now caps how many Keystore keys an app can own — a platform limit that lands on background video recording for the same reason: nobody tells the solo developer it arrived.

Sources, all first-party: the European Commission's Cyber Resilience Act reporting obligations page and its summary of the legislative text for Regulation (EU) 2024/2847; and, for what the app store collects without being asked, Play Console Help on viewing crashes and ANR errors and Android vitals.

Your Phone's Screen Is Cracked and the Camera Still Works: Setting Up an Old-Phone Security Camera You Cannot Touch

Super Funicular — Sun, 30 Aug 2026 07:11:01 +0000

Twice in this blog I have told people that a cracked screen does not matter.

In the shop-monitoring guide it is item one on the shopping list: "An old Android phone. Anything you stopped using. A cracked screen is fine — you will not be looking at it." In the pet-camera guide I said it again: "If the screen is cracked, that doesn't matter; the screen will be off."

Both sentences are true about the ten months the phone spends on a shelf. Neither is true about the ten minutes before that.

For those ten minutes you have to unlock the phone, join Wi-Fi, install something, answer four permission dialogs and press start — and every one of those is a touch event, on the exact component that breaks when a phone hits a floor. "You will not be looking at it" answers the display. It does not answer the digitizer. I skipped that, twice, and this is the missing half.

The good news: Android has had a documented answer since 2011, it costs about a dollar, and it does not involve a computer.

Can you use a phone with a broken screen as a security camera?

Short answer: Usually yes. A camera phone does not need its display after setup — but setup itself needs input. If the picture is broken and touch still responds, you can drive it as-is. If touch is dead and the picture is fine, a USB mouse plugged in through a $1 OTG adapter gives you a pointer, with no computer, no drivers and no developer settings. If both are dead, you need a PC — and whether that works depends on a decision you had to make before the screen broke.

How do you set up an Android phone when the touchscreen does not work?

Short answer: Connect a wired USB mouse through a USB-OTG adapter. Android has supported USB host mode since Android 3.1 (API level 12), mice are explicitly among the supported device classes, and Google's own documentation says "No special configuration or driver is needed, in most cases." A pointer appears on screen and you can point, select, drag, scroll and hover through the entire setup. This works on a locked phone, so you can enter the PIN with it too.

The screen is two parts, and they die separately

This decides everything else, and almost nobody separates them.

The panel you look at and the layer that senses your finger are different components stacked on top of each other. A drop can kill one, the other, or both. The spider-web of cracks tells you the glass is broken; it tells you nothing about whether touch still works underneath it.

So before buying anything, find out which failure you have:

Picture fine, nothing responds to touch — dead digitizer. Common with liquid damage and with "the bottom third is dead" phones.
Screen black, dim, or a mess of lines, but the phone vibrates and rings — dying display, working touch.
Nothing at all — either both, or the phone genuinely is dead.

Quick test for the middle case: plug in a charger and tap where the unlock button would be. Haptic feedback in the right places means touch is alive.

Case 1: cracked glass, touch still works

Nothing to solve. Set it up normally, put it where it belongs, and let the display go off for good. This is the case both of my earlier articles were quietly assuming, and it is genuinely the majority of drawer phones — cosmetic damage, working hardware. Write down the Wi-Fi password and the screen-lock PIN while you still can; once the phone is on a wall, a forgotten PIN is a real problem.

Case 2: touch is dead, the picture is fine — use a mouse

This is the fix that deserves to be better known, because it is old, official and cheap.

Android's USB support has two directions. In host mode the phone acts as the host and powers the bus, and the documentation lists what you can plug into it: "Examples of devices include digital cameras, keyboards, mice, and game controllers." That has been in the platform since Android 3.1 — so essentially any phone you are likely to be repurposing already has it.

The 3.1 release notes are explicit about what this feels like to use. On setup: "No special configuration or driver is needed, in most cases." On pointers:

"For pointing devices, the platform supports most types of mouse with a single button and optionally a scroll wheel, as well as similar devices such as trackballs. When these are connected, users can interact with the UI using point, select, drag, scroll, hover, and other standard actions."

Point, select, drag, scroll, hover — every gesture a setup wizard asks for.

What you need: a USB-OTG adapter matching the phone's port (micro-USB or USB-C), and any wired USB mouse. The adapter is usually the cheapest accessory on the shelf. Choose wired over Bluetooth — pairing is itself a touch-dependent task on a phone you cannot touch.

The 60-second test: plug the adapter into the phone, the mouse into the adapter, and move the mouse. If a small arrow appears, you are done deciding; everything from here is clicking. If nothing appears after ten seconds, try a different adapter before giving up — the adapters are the flaky part.

The honest caveat, in Google's own words: "Support for USB host and accessory modes are ultimately dependant on the device's hardware, regardless of platform level." The platform supporting it does not oblige the manufacturer to wire it up. Budget and entry-level models are the most likely to have left it out. There is no way to know from the spec sheet — you test it.

If it works, the mouse solves the whole problem, lock screen included: a pointer clicks PIN pad digits exactly like a finger.

Case 3: both are dead — and the trap in the obvious answer

Search this problem and you will be told to use scrcpy, a free and open-source tool from Genymobile that mirrors an Android screen to a computer and lets you control it with your own keyboard and mouse. It is excellent, it works from Android 5.0 (API 21) upward, and it is exactly the right shape of tool.

It also has a requirement stated plainly in its README: "Make sure you enabled USB debugging on your device(s)." Enabling USB debugging requires tapping through Settings. On the phone. Which is the thing you cannot do.

And it goes a layer deeper: even with debugging already on, the first connection from a new computer triggers an on-device confirmation. scrcpy's FAQ describes it directly — "When connecting, a popup should open on the device. You must authorize USB debugging." A popup you must approve, on a screen that shows you nothing.

So the fork is: if debugging was already on and this computer was already authorized, you are fine — mirror the screen, set the camera up with your desktop mouse, unplug. If it wasn't, the standard advice does not apply to you, however often it is repeated.

One path remains, and it is a nice piece of symmetry. scrcpy has an OTG mode that "allows to control the device using AOA keyboard, mouse and gamepad, without using adb at all (so USB debugging is not necessary)." Your computer stops being a debugger and starts pretending to be a plugged-in mouse. No debugging, no authorization popup.

The catch is the very next sentence: "In this mode, video and audio are disabled."

Control without a picture. You are moving a pointer around a screen you cannot see — workable only if you know the menus by muscle memory and have an identical handset to practise on. I would rather say that than pretend it is a fix.

Notice what the two working paths have in common. In Case 2 the phone is the USB host and the mouse is the peripheral. In Case 3 the roles invert: the computer is the host, the phone the accessory. Same port, opposite direction, and which one you need is decided by which half of the screen survived.

The order to do things in

With limited or borrowed input, do the fiddly things first, while you still have a pointer:

Disable the screen lock, so a reboot after a power cut doesn't lock you out of a phone you can't type on.
Join the Wi-Fi. Typing a WPA2 password is the hardest input task in the process.
Install the camera app and grant every permission. Permission dialogs are modal — an unanswered one blocks everything behind it.
Turn off automatic updates and set display sleep to the shortest interval.
Start the camera and confirm the stream from another device — any phone or laptop with a browser on the same network.
Only then mount it and put the mouse away.

Step 5 matters most: it is the moment the phone's own screen stops being part of the system. From then on the interface is a browser window on a device that works.

What the documentation does not tell you

Six real gaps, stated rather than guessed at:

Which phones actually implement USB host mode. The docs say it depends on the hardware, and name no models, no list, and no way to check short of trying it.
Whether a mouse works on the very first boot. The out-of-box wizard on a factory-reset phone runs before most of the system does; Google's mouse documentation describes a phone already in use.
Input on an encrypted device before first unlock. A just-rebooted phone wants its PIN before almost anything works, and none of these pages address that window.
Power draw. The mouse runs off the phone's battery through the adapter, and no published figure says what that costs a phone with a worn battery.
The age of the source. The clearest description of Android mouse support sits on the Android 3.1 highlights page — last updated 2024-05-20, describing a 2011 release. It has never been rewritten for the modern platform, which is why the capability is so widely forgotten.
Phantom touches. A cracked digitizer can register presses nobody made, and a phantom tap can dismiss a dialog or stop a recording. Nothing documents living with a partially broken input device.

The claim, corrected

"A cracked screen is fine — you will not be looking at it" is right, and I stand by it. It is just incomplete. The full version:

A cracked screen is fine once the phone is running. Getting it running needs input, not a display — and in the common case input costs about a dollar and no computer at all.

That distinction matters because of who it affects. The phones most likely to be sitting unused with a smashed screen are exactly the ones being reused as cameras: three-to-six-year-old budget handsets, in households where a screen replacement costs more than the phone is worth. Telling that reader "the screen doesn't matter" and omitting the setup problem sends them away thinking the phone is unusable, when a mouse would have fixed it in five minutes.

If your phone passes the pointer test, it is a camera. Go and check.

Background Camera RemoteStream records with the screen off, stores video locally on the phone, and serves a live view over your own network to any browser — so once it is set up, the phone's own screen is not part of how you use it. Google Play · superfunicular.com

Sources: USB host and accessory overview (Android Developers, last updated 2026-02-26) · Honeycomb MR1 platform highlights (Android Developers, last updated 2024-05-20) · scrcpy README, FAQ and OTG documentation (Genymobile, Apache 2.0)

The Camera Phone Is the Most Backup-Eligible Device You Own: What Android Auto Backup Actually Uploads From a "Local-Only" Camera

Super Funicular — Sat, 29 Aug 2026 07:09:10 +0000

A phone running as a security camera is supposed to be the boring device in the house. It sits on a shelf, it points at a door, it writes video to its own storage, and nothing leaves the building. That is the whole pitch for the local-only approach, and it is the reason people choose it over a cloud camera.

Here is the part that took me a while to say out loud, and that I have written imprecisely myself in the past: the video files are not the only data on that phone, and Android has a documented, on-by-default system for uploading the rest of it to Google Drive.

It is called Auto Backup. It is not malware, it is not a dark pattern, and it is not something a camera app switches on. It is a platform service that every app targeting Android 6.0 or higher is enrolled in unless the developer opts out. And once you look at the conditions it requires in order to run, you discover something genuinely uncomfortable: a phone mounted as a camera satisfies every one of them, every night, more reliably than the phone in your pocket does.

This is a deep-dive into what that system actually copies, what it provably does not, and how to check the state of it on your own camera phone. Everything below is from Google's published documentation, quoted and linked.

Are my phone security camera recordings backed up to Google Drive?

Short answer: Almost certainly not — video files are far too large for the mechanism. Auto Backup gives each app "up to 25 MB of backup data per app user." A single night of recording is orders of magnitude past that. What can be uploaded is the app's settings data: shared preferences, databases, and internal files. The footage stays where it is. The configuration is the part that travels.

Does a local-only Android security camera app upload anything to the cloud?

Short answer: The app may upload nothing at all. Android, separately and underneath it, may still upload the app's stored settings to your Google Drive as part of a device-wide backup you enabled once and forgot. "Local-only" describes what the app does with your video. It does not describe what the operating system does with the app's data directory. Those are two different questions, and only the first one is answered by a store listing.

The mechanism, in Google's own words

The Auto Backup documentation is unusually direct. "Android preserves app data by uploading it to the user's Google Drive, where it's protected by the user's Google Account credentials."

Enrolment is automatic and the default is on:

"Apps that target Android 6.0 (API level 23) or higher automatically participate in Auto Backup... The default value is true."

What gets included by default is broader than most people assume. Google lists shared preferences files, files in internal storage via getFilesDir() or getDir(), files under getDatabasePath() — "which also includes files created with the SQLiteOpenHelper class" — and, notably, "files on external storage in the directory returned by getExternalFilesDir(String)."

That last one matters for camera apps, and I will come back to it.

Three directories are permanently out of scope: those returned by getCacheDir(), getCodeCacheDir(), and getNoBackupFilesDir(). The docs are emphatic that this is not negotiable — they "are always excluded even if you try to include them."

Storage behaviour is worth knowing precisely. Backup data lives "in a private folder in the user's Google Drive account, limited to 25 MB per app," it "does not count toward the user's personal Google Drive quota," and "only the most recent backup is stored. When a backup is made, any previous backup is deleted." Google also states the data "can't be read by the user or other apps on the device" — which means you cannot open it up and inspect what your camera app put there.

Why a mounted camera is the ideal backup candidate

This is the observation that made me want to write the piece. Auto Backup does not run whenever it likes. It runs when four conditions are all true:

"The user has enabled backup on the device... At least 24 hours have elapsed since the last backup. The device is idle. The device is connected to a Wi-Fi network (if the device user hasn't opted in to mobile-data backups)."

Now read that list as a description of a phone screwed to a wall pointing at a hallway.

It is on Wi-Fi permanently, because a LAN camera is useless otherwise. It is plugged in permanently. And it is idle in the system's sense — nobody picks it up, nobody scrolls on it, nobody has touched the screen since the day it was mounted. It is arguably the most consistently idle, most consistently connected device in the building.

Google's own caveat underlines the contrast: "In practice, these conditions occur roughly every night, but a device might never back up (for example, if it never connects to a network)." A phone that lives in a pocket, drops off Wi-Fi, and gets handled all evening is the one that might go days without qualifying. The camera phone qualifies nightly, without fail.

There is one brake: "To conserve network bandwidth, the upload takes place only if the app data has changed." A camera app whose settings are stable has little to send. But "the app data" includes anything the app writes into a backed-up directory — and a recorder is, by nature, an app that writes things continuously.

The lock screen is doing more work than you think

Here is the second inversion, and it is a security one.

Google's backup security recommendations draw a line that is easy to skim past:

"The Standard Android Backup system always encrypts backup data in transit and at rest. This encryption is applied regardless of the Android version in use and of whether your device has a lock screen. Starting from Android 9, if the device has a lock screen set, then the backup data is not only encrypted, but encrypted with a key not known to Google (the lock screen secret protects the encryption key, thus enabling end-to-end encryption)."

Read it twice. Encryption is unconditional. End-to-end encryption is conditional on a lock screen. The Auto Backup page says the same thing from the other side: the backup "is end-to-end encrypted on devices running Android 9 or higher using the device's PIN, pattern, or password."

Now consider what people actually do to a phone they are turning into a camera. They remove the PIN. It is the rational thing to do: you want to glance at the screen without unlocking, you want it to come back cleanly after a power cut without a human standing there to type a code, and the device is bolted somewhere only you go.

That decision is a reasonable convenience trade-off, and almost nobody making it knows it is also a decision about who holds the key to their cloud backup. The device most likely to have no lock screen is the device best positioned to back up every night. The two choices compound, silently, in opposite directions.

If you keep a lock screen on the camera phone, this whole section is moot and your backup is end-to-end encrypted. That is the fix, and it costs nothing but convenience. It pairs naturally with the Private Space walkthrough we published for phones mounted in shared rooms.

The quota trap nobody warns you about

Return to getExternalFilesDir(String) being backed up by default.

Suppose a camera app stores clips in its app-specific external directory rather than in shared media storage. Those files are, by default, in scope for backup. They are also wildly over the limit. Google documents the consequence:

"If the amount of data is over 25 MB, the system calls onQuotaExceeded() and doesn't back up data to the cloud. The system periodically checks whether the amount of data later falls under the 25 MB threshold and continues Auto Backup when it does."

So the failure is not "your video gets uploaded." The failure is that the backup silently stops happening at all. Your settings, your camera configuration, the thing you would actually want restored on a new phone — none of it is saved, because the recordings crowded it out. And there is no user-visible signal either way.

Both outcomes here are invisible. That is the honest summary of this entire subject: whichever way it goes, nothing on screen tells you.

Turning it off is less binary than it sounds

The obvious response is android:allowBackup="false". It works, with a caveat that Google flags specifically for modern apps:

"For apps targeting Android 12 (API level 31) or higher, this behavior varies. On devices from some device manufacturers, specifying android:allowBackup="false" disables cloud-based backup and restore... but doesn't disable device-to-device transfers for the app."

Cloud off does not mean data still. Device-to-device migration — the flow you use when you set up a new phone from an old one — is governed separately, through dataExtractionRules on Android 12+ (and fullBackupContent on Android 11 and lower; an app supporting both needs both files). And the default when you say nothing is permissive:

"If there are no rules for a particular backup mode, such as if the <device-transfer> section is missing, that mode is fully enabled for all content except for no-backup and cache directories."

There is also a flag built precisely for the lock-screen problem above: disableIfNoEncryptionCapabilities, which makes "the backup happen only if it can be encrypted, such as when the user has a lock screen." It is the correct setting for anything sensitive, and it is opt-in.

What the documentation does not tell you

Six gaps I could not close from the published pages:

No inventory. Because backup data "can't be read by the user or other apps," there is no supported way to see which files a given app actually uploaded. You can see that an app was backed up, not what was in it.
No retention number. Obsolete backup datasets are "automatically deleted after a period of inactivity." The period is never specified.
No quota signal to the user. onQuotaExceeded() is delivered to the app. Nothing surfaces to the person relying on the backup.
The OEM set is unnamed. "Some device manufacturers" ignore allowBackup="false" for D2D. Which ones is not published, which matters most on the budget devices this use case runs on.
"Idle" is undefined here. The scheduling section gives no threshold for what counts as an idle device.
Page staleness. The Auto Backup page carries Last updated 2026-02-26; the backup security page carries Last updated 2024-10-25. The two are not versioned together.

How to check your own camera phone

Nothing here requires a developer. Five minutes, in order:

Settings → Google → Backup. See whether device backup is on at all. If it is off, none of this applies to you.
Check the account. Whichever Google account is signed in is the destination. On a repurposed phone that is often somebody's old personal account, still there because nobody made a decision. Our piece on what stays signed in on a camera phone covers the wider version of this problem.
Set a lock screen. This is the single highest-value action on the list. It is the difference between encrypted and end-to-end encrypted.
Look at the backed-up app list in the Google One / Drive backup view. It will not show you contents, but it will show you participation.
Decide deliberately. Backup on with a lock screen is a defensible setup. Backup off is a defensible setup. Backup on with no lock screen, unexamined, is the one nobody chose on purpose.

Correcting something we wrote

In an earlier article on the most privacy-respecting way to run an old phone as a camera, we wrote of the recordings: "There is no copy on a server. There is no copy in a backup."

For the video files, that holds, and the 25 MB quota is the reason it holds. But the sentence was doing more work than it should have. App data is a different object from app recordings, and Android's backup system treats them differently. The precise claim is: your footage stays on the device; your app's configuration may not, depending on a system setting that has nothing to do with the camera app. We should have drawn that line the first time.

This is the same distinction as our LAN threat model piece: local-only is a statement about a data path, not a blanket privacy guarantee. Every architecture has edges. The useful thing is to name them.

Where this leaves the local-only case

Stronger, not weaker — but only when stated accurately.

A cloud camera uploads your video by design. That is the product. No setting removes it, because removing it removes the feature. What we are discussing here is an optional, user-controlled, encrypted, 25 MB copy of configuration data, which you can inspect the setting for in under a minute and turn off with one toggle. Those are not the same class of exposure, and pretending they are would be as sloppy as ignoring the issue.

The difference that matters is that this one is yours to decide. The video from a phone-as-camera setup is written to the phone and served from the phone. Background Camera RemoteStream records with the screen off and serves the live view from a web server running on the device itself, over your own network — there is no upload path in the architecture for the footage to take. What Android does with an app's settings directory is a platform decision, and now you know where the switch is.

That is the honest version. It is a better argument than the tidy one.

Background Camera RemoteStream turns an Android phone into a screen-off camera with local recording and a built-in web server for remote viewing on your own network. Google Play · superfunicular.com

Sources: Back up user data with Auto Backup (Android Developers, last updated 2026-02-26) · Security recommendations for backups (Android Developers, last updated 2024-10-25)

Best Free Security Camera Apps for Android in 2026 - and Which Ones Quietly Meter Your Free Plan

Super Funicular — Sat, 29 Aug 2026 02:45:49 +0000

Every list of free security camera apps compares the same things: motion detection, night mode, two-way audio, cloud storage days. Almost none of them compare the thing that actually decides whether "free" stays free.

Here it is: does your video pass through the vendor's server on its way to your eyes?

If it does, someone is paying for that bandwidth, and it is not you. That cost has to be recovered, so the free plan gets a meter on it — a daily data allowance, a bitrate ceiling, a resolution cap, a camera count. If your video does not pass through anyone's server — if the phone talks straight to your laptop over your own Wi-Fi — there is no bandwidth bill, so there is nothing to meter. The free tier has no ceiling because a ceiling would be pointless.

That single architectural fork explains nearly every "why is my free plan like this?" complaint in the category. This guide sorts the 2026 field by it.

Which free Android security camera app has no data limit?

Background Camera RemoteStream. It has no data cap on its free use because it does not relay your video through a server. The app runs a small web server on the phone itself, and your browser connects to that phone directly over your local network. There is no middleman hop to meter, so there is no allowance to run out, no bitrate ceiling imposed by a plan tier, and no account to create.

Recording is separate and also uncapped: video is written to the phone's own storage, with the screen off, limited only by the free space on the device.

The rest of this guide covers the other apps worth knowing and exactly where each one's meter sits.

The 2026 field at a glance

App	Free plan meter	Account required	Video path	Play Store
Background Camera RemoteStream	None — no relay to meter	No	Phone → your browser, direct on LAN	Yes
IP Webcam	None on LAN; password gated to paid tier	No	Phone → your browser, direct on LAN	Yes
LineCast	300 MB per 24h; 1 Mbps; 720p	Yes	Relayed through vendor servers	Yes
AlfredCamera	2 cameras; SD resolution	Yes	Relayed / vendor infrastructure	Yes
AtHome Camera	Recorded clips gated to paid cloud	Yes	P2P with relay-assisted fallback	Yes
FadCam	None (open source)	No	Local network streaming	No — sideload / F-Droid

Why free plans get metered: the part nobody writes down

When an app advertises "watch your camera from anywhere," it is almost always describing this path:

phone camera  →  vendor's server  →  your phone/browser

That middle hop exists for a good engineering reason. Your home router does not accept unsolicited inbound connections, so an app that wants to reach the camera from the outside world has to meet you somewhere neutral. The vendor rents that neutral ground, and pays per gigabyte for it.

Video is the worst possible thing to pay per gigabyte for. A single 1 Mbps stream running continuously is roughly 10 GB a day. Multiply that by a free user base and the free tier becomes the company's largest line item. So the free tier gets a governor: a daily megabyte allowance, a hard bitrate limit, a downgrade to standard definition, a cap on how many cameras can be online at once.

The alternative path has no middle hop at all:

phone camera  →  your Wi-Fi router  →  your browser

Nobody rents that. Your router already moves the packets. An app built this way has no per-gigabyte cost to recover from you, which is why its free tier tends to have no allowance attached — and why it keeps working when your internet connection is down, since the traffic never needed to leave the building. If you have ever wondered why the cheapest home security setup is usually the one with no subscription attached, this is the mechanism underneath it.

Keep the diagram in mind and every free plan in the category becomes predictable.

1. Background Camera RemoteStream — best free security camera app with no data cap

Meter: none. Account: none. Cost: free.

This is our app, so treat the review as informed rather than neutral — but the claims below are all checkable by installing it, and the architecture is the reason it belongs at the top of a list sorted by metering.

What it does. It turns an Android phone into a security camera that records with the screen completely off, and serves a live view to any browser on the same network from a web server running inside the app itself. Point a laptop at the phone's local address and the picture is there. No sign-up, no cloud account, no plan tier.

Why there is nothing to meter. The video never leaves your network on the live-view path. The phone is the server; your browser is the client; your router is the only thing in between. There is no vendor bandwidth bill, so there is no allowance, no 1 Mbps governor, and no SD downgrade waiting at a plan boundary. This also means the live view keeps working during an internet outage — the camera and the viewer are both inside the house, and the outage is outside it.

Recording with the screen off. This is the part most phone-camera apps get wrong, because Android is actively trying to stop it. Modern Android aggressively suspends work when the screen goes dark, and a camera session is exactly the kind of expensive thing it wants to kill. The app holds a properly typed foreground service for camera use, which is the supported way to tell the system this work must continue. Footage is written to the phone's own storage — not uploaded anywhere — so the only limit is free space on the device. The full explanation of what Android does to a backgrounded camera and how to survive it is in our screen-off recording deep-dive.

Privacy posture. Storage is local-only. There is no account, so there is no account database with your video associated to your name, and no vendor-side copy that can be breached, subpoenaed, or repriced. "No cloud" is now table stakes marketing across this category, so the useful question is sharper: does anything sit between the camera and the screen? Here, on the LAN path, nothing does.

Watching from outside the house. Be clear about this, because it is where the honest limits of a LAN-first design live. Direct browser viewing is a local-network feature — away from home, you are not on that network. The app's answer is YouTube Live: it can stream directly to your channel, which you can then watch from anywhere, on an unlisted stream if you want it private. That path does traverse the internet, so it uses your data connection like any upload would; the difference is that it is your YouTube channel and your choice, not a vendor relay with a 300 MB allowance attached.

Good for: anyone who wants a camera with no subscription, no account, and no cap; older or budget Android phones; households on metered mobile data, where a relayed app would burn the data plan just by being watched; shops and storefronts monitored from the counter; setups with unreliable or no home internet.

Weak spots: remote viewing means going through YouTube Live rather than a direct connection; there is no motion-triggered alert push and no two-way audio; and getting the local address right takes one minute of reading the first time.

Get it: Google Play · superfunicular.com

2. IP Webcam — the other genuinely unmetered option

Meter: none on the LAN path. Account: none.

The long-running standard for turning an Android phone into a network camera, and architecturally a cousin of ours: it streams inside your Wi-Fi network without needing internet access, and you view it in a browser or in VLC. No account is needed for the basic function, and because the stream is local there is no data allowance to exhaust.

It is deep on features — recording in several container formats, audio streaming, motion detection with a sound trigger, uploads to Dropbox/FTP/SFTP/email via a plugin, multiple web renderers. If you like configuring things, you will like it.

The catch worth knowing before you rely on it: requiring a password on the stream is a premium feature. On a free install, anyone already on your Wi-Fi who finds the address can look through the camera. On a trusted home network that may be acceptable; on shared, office, or dormitory Wi-Fi it is a real exposure. The paid tier also unlocks Tasker integration and interface customization.

Good for: tinkerers, VLC users, people who want format and upload options.
Weak spots: stream password is paywalled; the interface is utilitarian; no YouTube Live path.

3. LineCast — the clearest example of a metered free plan

Meter: 300 MB per 24 hours, 1 Mbps, 720p. Account: yes.

LineCast is a well-built Android CCTV app and is worth taking seriously — it offers screen-off operation and live remote viewing from any web-connected device, which is a genuinely strong combination, and it runs no ads even on the free plan, with no time limit on free use.

It is also the cleanest illustration of this article's thesis, because the company documents the mechanism openly. Its FAQ describes transmitting video and audio from the camera device to viewers — that is, through its infrastructure — and the free plan is metered accordingly: the camera can send up to 300 MB of data per 24 hours, which the company itself estimates at roughly half an hour of footage. Free video quality tops out at 720 vertical pixels and a maximum bitrate of 1 Mbps.

None of that is a criticism of their engineering. It is the honest arithmetic of relaying video for free users, and they publish it plainly rather than burying it. But if your use case is "watch the shop all afternoon," half an hour a day is the binding constraint, and no setting will move it — only a paid plan will.

Good for: people who want remote viewing to just work with zero network setup and are fine with short daily sessions or paying.
Weak spots: 300 MB/24h ceiling; 1 Mbps and 720p on free; account required.

4. AlfredCamera — the biggest name, and the 2026 price move

Meter: 2 cameras, standard definition. Account: yes.

Alfred is the category's most recognizable phone-as-camera app, with the most polished onboarding and the largest support footprint. If you want something your family can install without a phone call, it is the safe pick.

Its 2026 plan changes are a useful data point for anyone budgeting. The company announced that the free tier is limited to up to 2 online cameras, and that the annual price of new Premium Standard subscriptions rises roughly 20% in the United States, from $29.99 to $35.99 per year, with monthly options at $2.99 and $5.99, rolling out through 2026 and effective in the US from 16 March 2026. Premium Standard raises the limit to 4 online cameras; Premium Plus offers unlimited cameras and adds Full HD, 30-day cloud storage and continuous recording. Free video quality is standard definition.

Read that as the relay economics again: the free tier is bounded in the two dimensions that cost the vendor money — how many streams are live, and how many pixels each one carries. We wrote a longer version of this arithmetic when pricing an old phone against a Wyze renewal, and the shape is identical.

Good for: non-technical households; people who want alerts and support and will pay for them.
Weak spots: SD on free; 2-camera free ceiling; price rising; account and cloud required.

5. AtHome Camera — free to watch, paid to keep

Meter: recorded clips are gated. Account: yes.

AtHome is free to download and gives you the core set at no cost — live streaming, motion detection, two-way audio. Its connection design is P2P with relay-assisted fallback: it attempts a direct device-to-device link and falls back to a relay server when networks block that, which is a sensible hybrid.

The meter sits on retention rather than bandwidth: you generally cannot download the scheduled or motion-triggered clips it captures unless you subscribe to the cloud service. So the live picture is free and the evidence is not — which matters, because the reason most people install a security camera is to still have the footage tomorrow.

Good for: multi-platform households wanting two-way audio; people who mainly watch live.
Weak spots: saved footage effectively paywalled; account required; free limits vary by region and platform.

6. FadCam — excellent, open source, and not on Google Play

Meter: none. Account: none. Play Store: no.

FadCam deserves a mention on merit: it is an open-source, ad-free Android recorder that started as a background video recorder and has grown to cover dashcam-style recording, screen recording, live streaming over local networks, and remote camera control. It is actively maintained and, being open source, is fully auditable — genuinely rare in this category and a real advantage if you care about verifying rather than trusting privacy claims.

The practical obstacle is distribution. It is not installable from Google Play; the developer distributes it through GitHub releases, F-Droid, and mirrors like SourceForge. Its developer told us as much directly in the comments on one of our earlier dev.to posts. For a technical audience, sideloading or adding F-Droid is a minor step. For the person setting up a camera for a relative in another city, "download an APK from GitHub" is where the project ends — and on many budget devices in markets where sideloading is discouraged or restricted by the vendor, it is a genuine wall.

We mention it because a fair comparison should include the best tool in the category regardless of where it ships, and because if you are comfortable sideloading, it is very good.

Good for: open-source purists, auditors, technically confident users.
Weak spots: no Play install; setup friction for non-technical users.

Three ways to tell whether an app is metering you

Before you commit a phone to a corner of a room, run these:

Look for a number in the free-plan description. Megabytes per day, kilobits per second, a pixel ceiling, a camera count. Vendors who relay video almost always publish the allowance, because support tickets are worse than disclosure. A free plan described only in features, with no numbers, usually means the numbers are somewhere less prominent.
Turn the internet off and try to watch. Disconnect your router from the internet but leave Wi-Fi running, then open the live view from a laptop on the same network. A direct-connection app keeps showing the picture. A relayed app goes dark, because the path out to the vendor and back is broken. This is the fastest, most honest test in the category, and it takes thirty seconds.
Ask where the recording lands. If the footage is on the phone, the limit is your storage. If it is in the vendor's cloud, the limit is your plan — and the retention window is the number to check, since a camera whose footage expires before you look at it has not really recorded anything.

If your data is metered, this is not a small difference

Most English-language comparisons in this category assume unlimited home broadband, where a 300 MB relay allowance reads as an annoyance rather than a blocker. On a metered mobile data plan — the normal case across much of the world, and for most of the people who install our app — the picture inverts completely.

A relayed camera spends your data twice: the phone uploads the stream, and you download it again to watch. Watch it for an hour and you have paid for that hour twice over, out of a bundle you bought for the month. A direct LAN connection spends none of it, because the packets never touch your data plan at all; they go phone → router → laptop and stop. Two people can watch all day and the bundle does not move.

That is also why the "turn the internet off" test above is not a party trick. If your connection drops for an afternoon — or you simply have not topped up yet — a locally served camera keeps working and a relayed one does not. We wrote a full walkthrough of that setup for running a camera with no internet plan and no credit card.

Verdict

If you want a free Android security camera and you do not want to discover a ceiling later:

No cap, no account, installs from Play → Background Camera RemoteStream. Screen-off recording to local storage, direct browser viewing on your network, YouTube Live when you need to watch from elsewhere.
No cap and you want maximum configurability → IP Webcam, provided you accept that stream passwords are a paid feature.
You want zero network setup and will pay or watch briefly → LineCast (300 MB/24h free) or AlfredCamera (2 cameras, SD free).
You are comfortable sideloading and want auditable code → FadCam.

The general rule holds beyond these six: the free tier is metered exactly where the vendor's costs are. Find the hop, and you have found the cap.

Background Camera RemoteStream records with the screen off, stores video locally on the device, serves a live view from a web server running inside the app, and can stream to YouTube Live — with no account and no cloud.

Try it: Google Play · superfunicular.com

Ring's "Throw Away the Key" Encryption Is a Custody Change, Not a Cryptography One

Super Funicular — Sat, 29 Aug 2026 02:45:16 +0000

On 26 August 2026, Amazon's Ring announced TAKE — Throw Away the Key Encryption — which the company says "will become the default encryption for all Ring customers worldwide when fully rolled out." It rolls out in phases starting in September — days away as I write this. TechCrunch reported the same day that the scheme uses rotating keys held temporarily in the cloud, released to Ring only to power features the user has enabled, and deleted afterward — within 24 hours, per TechCrunch's account. End-to-end encryption remains available as an opt-in setting.

Let me say the fair thing first, because it's true and it matters: this is a real improvement, and Ring deserves credit for it.

Default beats opt-in. Almost nobody changes defaults, so a privacy control that ships off is a privacy control most people never get. Ring's own blog notes E2EE has been available since 2021 — five years of an option that, by construction, protected only the users who went looking for it. Making the stronger setting the default is the single highest-leverage privacy change a consumer product can make. They also built on Messaging Layer Security, a published IETF standard rather than a proprietary scheme, and shipped a white paper describing it. That is how you want a vendor to behave.

So this isn't a "gotcha" post. It's a post about what the announcement actually changes, and what it structurally can't.

The question was never "is it encrypted"

Your Ring video was already encrypted. Ring says so plainly: "Your Ring videos are already encrypted when they travel to the cloud and while they are stored at rest." Transport encryption and encryption-at-rest have been table stakes in this category for years.

What TAKE changes is key custody — who holds a copy of the key that undoes the encryption, and for how long.

Here's Ring's own description of the mechanism:

"A copy of the keys is temporarily held inside a secure enclave within the cloud; think of it as a sealed vault that can only provide Ring access to the key under strict, limited conditions. Ring can only receive access to power the intelligent features that you have active on your account, and then throws away and deletes the keys."

Read that clause again: to power the intelligent features that you have active on your account.

That sentence is the whole architecture. Your key-exposure surface is exactly proportional to how many cloud features you leave switched on. Smart Alerts needs to see the frame to tell a person from a parcel. Video search needs to see the frame to index it. Every cloud-side capability is, definitionally, a moment where something other than your device has plaintext.

Ring is not hiding this. Their E2EE section states the tradeoff outright: with end-to-end encryption enabled, "Shared Users and cloud-based features are not available." That's an honest disclosure, and it's the same tradeoff every cloud camera makes.

What TAKE genuinely innovates is making that tradeoff continuous instead of binary. Before, you chose all-cloud or all-private. Now you choose a dosage. That's useful. It's also a different thing from removing the tradeoff.

The handyman analogy is more revealing than it looks

Ring reaches for a lovely metaphor:

"You might give a spare to a close friend or family member you trust completely. And if a handyman needs to fix your sink, you lend them a key only for as long as the job takes, then get it back."

It's a good analogy — and notice what it concedes. In the metaphor, the handyman really does hold your key. The safety comes from duration and intent, not from impossibility. You are trusting that the key comes back, that nobody copied it while it was out, and that the job was what you were told it was.

That's not a knock on Ring specifically. It's the honest description of what any recoverable, feature-serving key architecture buys you. The second tell is the recovery story: TechCrunch reports that if you lose your devices, you can recover your keys by standing near your Ring cameras, or via "a passphrase, cloud-based backups, another approved device, or passkeys." A key that can be recovered from cloud backup is a key the cloud can, under some conditions, reconstitute. Every consumer product makes some version of this compromise, because the alternative — lose your phone, lose your footage forever — is a support nightmare that most users would hate.

So the honest framing is: TAKE narrows the window. It does not remove the window. And "how wide is the window" is a fundamentally different security property from "there is no window."

Where we sit, and why it's a different question rather than a better answer

I build Background Camera RemoteStream, an Android app that turns a phone into a camera that records with the screen off and streams to a device you already own.

The architecture is deliberately dumber. Footage is stored locally on the device. Live viewing runs over your own network. YouTube Live streaming, if you use it, goes to your channel with your stream key. There is no account to create, because there is no server holding anything that would need one.

I want to be precise about what that does and doesn't buy you, because overclaiming here would be exactly the sin I'm describing.

What it buys: there is no vendor-held key, because there is no vendor-side copy of your video for a key to protect. The question "how long does Super Funicular hold a copy of your key?" has no denominator. Not "24 hours" — undefined. You cannot leak what you never received, and you cannot be compelled to hand over what you don't have.

What it costs, honestly: no cloud-side smart alerts. No server-side video search across months of footage. No frictionless sharing link you can text to a neighbour. If your phone dies with local-only footage on it and no backup, that footage is gone — the same brutal tradeoff Ring's E2EE mode carries, which is precisely why they made it opt-in. Cloud features are genuinely useful, and pretending otherwise is marketing, not engineering.

The point isn't that local-first is universally better. It's that these are different questions. Ring is optimising how briefly a third party holds your key. A local-first tool removes the third party from the diagram entirely, and pays for that in features. Which one you want depends honestly on whether you'd rather have package detection or an architecture with nothing in the middle.

The takeaway for anyone evaluating a camera

When a vendor announces an encryption upgrade, three questions cut through the marketing:

Who can decrypt this, and under what conditions? "Encrypted" alone answers nothing — encrypted to whom is the whole question.
Which features require plaintext? That list is your exposure surface. If it grows, so does the surface, regardless of the encryption scheme.
What happens if I lose every device? If the answer is "you can recover," some recoverable path exists, and that path is part of your threat model.

Ring answered all three publicly and in specific terms, which is more than most of this industry does. Ask their competitors the same three questions and see how many can answer as clearly.

Two of those questions have bitten this category recently in ways worth reading about. On question one, Operation CameraSwarm reached Dahua cameras behind NAT by serial number alone — an inbound path nobody configured and nobody could see, which is what "under what conditions" looks like when the conditions are undocumented. On the broader dependency question, Google Home and Nest went dark worldwide and a factory reset wouldn't have helped, because the broken half wasn't the half you own. And on the duration half of custody specifically, Flock cutting default retention from 30 days to 7 is the same insight TAKE is built on: how long something is held is a security control in its own right.

Background Camera RemoteStream — local-first background camera and YouTube Live streaming for Android. No cloud storage, no account required. More at superfunicular.com.

Sources: Amazon — Ring introduces TAKE (26 Aug 2026) · TechCrunch — Ring introduces a new encryption standard (26 Aug 2026)

Live View Stopped, Recording Did Not: Three Reasons an Old-Phone Security Camera Loses Its Stream on Patchy Internet

Super Funicular — Thu, 27 Aug 2026 07:10:25 +0000

You set an old Android phone up as a security camera. It worked. Then one afternoon you open the viewer on your other phone and the picture is frozen, or the page will not load at all. The camera phone is sitting right there, plugged in, screen off, apparently fine.

Most people's next move is to walk over and restart the app. That is almost always the wrong move.

There are three separate things Android itself does to a running camera's network connection. All three produce the same symptom. None of them stops the recording. Restarting the app does.

Why does my phone security camera live view stop but the recording keep going?

Short answer: because they are two different jobs. Recording writes video to the phone's own storage and needs no network at all. The live view is a network connection, and Android is allowed to move, block, or kill that connection while the recording continues untouched. A frozen live view is normally a network event, not a camera event.

Does an old-phone security camera keep recording without internet?

Short answer: yes, if the app records locally. Background Camera RemoteStream writes video to the phone's own storage with the screen off, and its built-in web server serves the live view over your local network. No internet connection is required for either the recording or for viewing over the same Wi-Fi. The internet is only needed if you want to watch from outside the building, or to push a YouTube Live stream.

That distinction is the whole point. A cloud camera that loses its uplink loses the footage, because the footage was only ever on its way somewhere else. A phone recording to its own storage loses nothing but the view.

Reason 1: Android moved the phone to a different network underneath the app

Every Android app has a default network, and the system picks it, not you. The platform documentation is direct about the preference order: the system "typically prefers unmetered networks to metered ones and faster networks to slower ones."

Picture the common case in a shop or a shared house. The camera phone is streaming over mobile data. Somebody switches the router back on after a power cut, or a neighbour's open network comes back in range. Android sees a free, unmetered Wi-Fi network, decides it is better, and switches.

Here is the part nobody expects, from the same page:

"When a new network becomes the default, any new connection the app opens uses this network. At some point later, all remaining connections on the previous default network are forcefully terminated."

Read "at some point later" carefully. New connections go to the new network immediately, but the connection your live view is already using stays alive on the old network for an unspecified period, and is then killed. From the viewer's side that looks like a stream frozen on its last frame, with no error. Nothing crashed. The connection was cut out from under it.

What to do: reload the viewer page. Nine times out of ten a fresh request opens on the new network and the picture comes straight back. If you are watching over your local network, the phone's address may also have changed with the network — see Reason 3.

How to prevent it: on the camera phone, forget every Wi-Fi network except the one you want it on. A phone that cannot see an alternative cannot be moved to one.

Reason 2: Data Saver blocked it, and you are on mobile data

This one matters most on prepaid connections. Google's own documentation opens the topic with a sentence worth keeping:

"Over the life of a smartphone, the cost of a cellular data plan can easily exceed the cost of the device itself."

Data Saver exists for exactly that. Google says it is "especially useful when roaming, near the end of the billing cycle, or for a small prepaid data pack." When it is on and the phone is on a metered network, the documented behaviour is blunt: "the system blocks background data usage and signals apps to use less data in the foreground wherever possible."

A camera app streaming with the screen off is, as far as the system is concerned, exactly the sort of background data usage Data Saver exists to block. The recording continues, because writing a file to storage is not network usage. The stream does not.

The fix is documented and takes one minute: "Users can allow specific apps to use background metered data usage even when Data Saver is turned on." On most phones that is Settings → Network & internet → Data Saver → Unrestricted data, then switch on your camera app. The exact menu name varies by manufacturer, so search Settings for "Data Saver" if you cannot find it.

Two related traps on the same setting. A Wi-Fi network can itself be marked as metered — many phone hotspots are, by default — so Data Saver can bite even when you are not on mobile data at all. And the per-app "background data" toggle in the app's own data-usage screen is a separate switch from Data Saver, with the same effect. Check both.

If you want to watch what this is costing you rather than guess, we wrote up how to measure it in what happens to a phone security camera during a power cut or an internet outage.

Reason 3: the Wi-Fi came back, but it is not the same network any more

This is the one that makes people think the app is broken, because everything looks restored. The router rebooted, the phone reconnected, the Wi-Fi icon is full — and the viewer still will not load.

The documentation explains half of it:

"When the network disconnects, the Network object stops being usable. Even if the device later reconnects to the same appliance, a new Network object represents the new network."

"The same appliance" is doing a lot of work in that sentence. Same router, same password, same room — and the system still treats it as a new network, deliberately, so that nothing carries on using a connection it only thinks is alive.

The other half is your router. Router addresses are handed out on a lease, and after a reboot the router is free to hand your camera phone a different one than it had before. The address you bookmarked, 192.168.1.7 or whatever it was, may now belong to a television.

What to do: open the camera app on the phone and read the address it is currently showing, then use that. To prevent it: most routers have a setting variously called DHCP reservation, static lease, or address binding — pin the camera phone's address there once and the bookmark stops rotting.

The one thing not to do

All three of the above are network failures. The recording survived all three.

Restarting the camera app is the only action in this article that ends the recording. If something did happen in front of the camera during those minutes, restarting is what turns a viewing outage into missing footage — in response to a problem it does not fix, because the network condition is still there.

So: reload the viewer first. Check the phone's current address second. Check Data Saver third. Touch the app last, and only after you have saved anything you might need.

A five-minute test to run before you rely on this

Start the camera and confirm the live view works from your second device.
Turn the router off at the wall for two minutes and back on.
Do not touch the camera phone.
When the Wi-Fi is back, reload the viewer. If it does not load, read the phone's current address off its screen and try that.
Stop the recording normally and check the file. It should cover the entire outage, including the minutes with no network.

Step 5 is the one that matters. If the file has a hole in it, the app was not recording locally, whatever its store listing said.

What the documentation does not tell you

To be fair about the limits of what is actually written down:

"At some point later" is never given a number. There is no documented maximum time between the default network changing and the old connections being terminated.
The documentation describes what the system does to connections, not what any particular app does about it. Whether an app reconnects on its own is the app's business, not the platform's.
Nothing in the Data Saver documentation addresses a foreground service that is streaming continuously — the examples are all about syncs and downloads.
Manufacturers add their own battery and data restrictions on top of the platform's, and those are not documented by Google at all.
The Data Saver page's own guidance was last updated in January 2024, well before Android 16.
None of this says anything about how any specific competitor's app behaves. We cannot see inside other people's apps, and neither can you from a store listing.

What to do this week

Pick the camera phone up once and do four things: forget the Wi-Fi networks it should not use, add the camera app to Data Saver's unrestricted list, reserve its address on your router, and run the five-minute test above. That is a one-time job.

If you are setting this up somewhere with no router at all, the hotspot arrangement is covered in how to use an old phone as a security camera without a Wi-Fi router. And if you are still choosing an app, we keep a running list of the free, no-subscription options that store video locally.

Background Camera RemoteStream records with the screen off to the phone's own storage, serves a live view from a web server running on the phone itself, and can push to YouTube Live when you want a stream that reaches outside the building. No account, no cloud storage, no subscription. It is free on Google Play, and there is more at superfunicular.com.

Sources

The Preview Is Flipped and the Recording Is Not: Android Mirrors a Front Camera Twice, and Only One Half Had a Public Switch

Super Funicular — Thu, 27 Aug 2026 06:55:32 +0000

Short answer: On Android, a front-camera preview is mirrored and the video file written from that same camera is not. That is not a bug and it is not one setting misapplied. They are two separate settings with two different defaults, and Google's own CameraX guide says so in as many words. Until this month only one of the two had a public switch; a CameraX release dated August 12, 2026 gave the other one a setter and dropped the experimental marker from both. If you have ever put a phone somewhere, watched the live view, and later described the saved clip to somebody from memory, this is the difference between left of the door and right of the door.

The convention nobody states out loud

When you look at a mirror you see yourself reversed, and you have seen yourself that way every morning of your life. A camera pointed at your face does not do that. It shows you what everyone else sees, which — the first time you notice it — looks subtly wrong.

So phone makers flip the front-camera preview horizontally on its way to the screen. The picture behaves like a bathroom mirror because that is what a person holding a phone at arm's length expects. Nothing about the sensor changed. Nothing about the pixels leaving the camera changed. The flip belongs to the display path, not to the footage: it is applied late, to one copy, for the benefit of one viewer.

That works perfectly for the case it was designed for: one person, holding the phone, looking at their own face, comparing it to nothing.

It stops working the moment a phone stops being something you hold and becomes something you put down and leave. Now the same camera has two audiences — whoever is watching the live view, and whoever opens the file afterwards — and those two people are not looking at the same picture.

What Android actually does, in Google's words

The CameraX video-capture guide states the default behaviour directly:

"While the camera preview is mirrored on the front camera by default, videos recorded by VideoCapture are not mirrored by default."

Read that twice, because there are two independent claims in one sentence:

The preview is mirrored. On the front camera. By default.
The recording is not mirrored. By default.

The default is that they disagree. Not on some devices, not under some conditions — by design, as the documented starting state. The same page continues:

"With CameraX 1.3, it's now possible to mirror video recordings so that the front camera preview and the recorded video match."

Which is worth reading for what it concedes. The ability to make the two halves agree is described as an addition. Before it, the disagreement was not something an app author could resolve at all through that library.

The date the switch stopped being experimental

CameraX release notes carry a dated heading for every version, and this is the row that matters. Under Version 1.7.0-alpha03, dated August 12, 2026:

"Added Preview.setMirrorMode, Preview.getMirrorMode and VideoCapture.setMirrorMode to public APIs, and removed the ExperimentalMirrorMode annotation."

Two separate things are packed into that line.

First, Preview got a mirror setter of its own. Before it, the guide's story is one-sided: you could change what the recording does, and the preview did what it did. Now both ends of the pair are addressable, which is the only way to guarantee they agree rather than hoping the defaults line up.

Second, ExperimentalMirrorMode is gone. An experimental annotation in a Jetpack library is a warning that the shape may change and a compiler opt-in you have to write out. Removing it is the library saying this is now something you may depend on.

A note on reading pages like this one, because it takes a second and saves a wrong claim: the footer of a Google documentation page carries a last updated date for the page, and that is a fact about the publishing system, not a date attached to anything written on the page. The video-capture guide quoted above is stamped 2025-12-10 while describing behaviour that is entirely current. The release-notes page has dated headings per version, and those are the dates of the actual events. Quote the dated row, never the footer.

Three constants, and why the middle one is almost never right

The same guide lays out the options:

"There are three MirrorMode options: MIRROR_MODE_OFF, MIRROR_MODE_ON, and MIRROR_MODE_ON_FRONT_ONLY."

Off — never flip. The file matches the sensor. It will not match a mirrored preview.
On — always flip, including the rear camera. A rear camera has no mirror convention to satisfy, because nobody is looking at their own face through it, so flipping it produces a file in which every sign in the picture reads backwards for no reason at all.
On-front-only — flip when it is the front camera, leave the rear one alone.

Google recommends the third one to line up with the preview, and describes it plainly:

"mirroring is not enabled for the rear camera, but is enabled for the front camera"

One small trap if you paste from that page: in the sentence carrying the recommendation, the guide misspells the constant as MIROR_MODE_ON_FRONT_ONLY, dropping a letter from MIRROR. The correct spelling appears in the sentence immediately before it, and again in the code sample below it. If your compiler tells you the symbol does not exist, it is right and the prose is wrong.

Why a phone you put down makes this worse than a selfie does

Handheld, the mismatch is invisible. You look at yourself, you record, you never place the two side by side, and if you did you would have no external reference to say which one was correct.

A phone that has been set up somewhere and left there breaks all three of those conditions:

Somebody describes the picture to somebody else. The bag was on the left of the step. Left in which of the two pictures?
There is text in the frame. A door number, a delivery label, a note taped to a window, a whiteboard, a page held up to the lens. Text is the one thing that makes a horizontal flip instantly, unmissably obvious — and it will be obvious in exactly one of your two pictures.
The live view and the file get compared. Not out of curiosity, but because somebody watched something happen and then went looking for it afterwards. That is the entire reason a recording exists.

And there is a prior question that no documentation can answer for you: which camera is even doing the work. A phone propped in a stand with its screen facing you is watching the room with its rear camera, and none of this applies. A phone with its screen facing the room is using the front camera, and all of it does. That depends on which way round you set the phone down. It is not a thing you can look up. It is a thing you check.

The two-minute check, no compiler required

You do not need to build anything to answer this for your own setup. You need a sheet of paper.

Write a word on the paper. Pick one that is not a palindrome — CAMERA works, MOM does not. Block capitals, thick pen.
Put the phone exactly where you intend to leave it, facing the way you intend it to face. Not on your desk pointed at you. The answer depends on which camera ends up doing the work, so the test has to use the real arrangement.
Hold the paper up in front of the lens and look at the live view. Is the word readable, or reversed?
Record a few seconds. Stop.
Open the saved file and find those same frames. Is the word readable now?

There are four possible outcomes and each one tells you something you can act on:

Live view	Saved file	What you have
readable	readable	The two agree. Nothing to do.
reversed	reversed	The two agree. Also fine — they are consistent with each other.
readable	reversed	The documented front-camera default: preview mirrored, file not.
reversed	readable	The inverse. Rarer, and worth knowing before you rely on it.

Rows three and four are the ones to write down somewhere, because they mean the picture you watch and the picture you keep are mirror images of each other, and the only person who will be caught out by that is whoever has to describe one of them out loud.

If you are the one building it

The guide's own snippet sets the policy on the recording side:

val recorder = Recorder.Builder().build()

val videoCapture = VideoCapture.Builder(recorder)
    .setMirrorMode(MIRROR_MODE_ON_FRONT_ONLY)
    .build()

And as of the August release, Preview carries setMirrorMode and getMirrorMode as public API, so the other half is addressable too. Set both explicitly. Two defaults chosen independently by two different classes is a coin flip you are not obliged to accept, and getMirrorMode means you can assert on it in a test rather than squint at a screen.

If you are using somebody else's camera app rather than writing one, none of those calls are available to you, and the paper test above is the whole of your instrumentation. That is not a small thing — it is a two-minute answer to a question that otherwise surfaces at the worst possible time.

The edges of what these two pages will support

Stating an unknown plainly is worth more than filling it with a guess, so here is where the sources stop:

Whether any particular app exposes this. A library setting is not a user setting. Whether a given camera app surfaces a mirror control, or which default it picked, is not knowable from Google's documentation and is not something to assume in either direction.
What a phone maker's own camera app does. CameraX is one library among several ways to talk to a camera. An OEM app may take an entirely different path and land somewhere else.
Still photographs. The passage quoted here is about VideoCapture. It does not describe what happens to a photo, and this piece does not extend it there.
Which handsets have which behaviour. A library version is chosen by the app that bundles it, not by the phone, so there is no device list to consult.

There is a companion piece to this one about a different gap between what setup guides tell you to do and what actually happens: only one of the two permissions every guide tells you to grant is about the camera.

The one-line version

Mirroring happens on the way to a screen, and Android decides it twice — once for the preview, once for the file — with two different defaults, and for several years an app author could only overrule one of them. Since August 12, 2026 both halves have a public setter. And if you are not the one writing the app, a sheet of paper and two minutes will still tell you which of your two pictures is the flipped one.

Sources: CameraX video capturing architecture and the CameraX release notes, both on developer.android.com. Quotations are verbatim; the dated claim comes from the version heading, not the page footer.

Written while building Background Camera RemoteStream, an Android app for running a phone as a screen-off camera on your own network. More at superfunicular.com.

DEV Community: Super Funicular

Pin the Camera App: How to Stop Someone Closing Your Phone Security Camera Without Locking the Phone

How do you stop someone from closing your phone security camera app?

Can you lock an Android phone to one app?

The failure this actually prevents

Turning it on, in order

The credential prompt, and a contradiction worth knowing about

The stronger version you probably cannot have

What the documentation does not tell you

Will your phone even have this?

The five-minute version

Further reading

Sources

You Don't Live There: Setting Up a Phone Camera in a House You Only Visit

Iterating is a privilege of proximity

What "dull" means in practice

The person who lives with it did not choose it

Do the checking while you are standing there

Where the software fits

Android Guarantees Six Concurrent Video Encoder Sessions - and Your Old Phone Is Probably Exempt

How many video encoder sessions can an Android phone run at the same time?

The number that does describe your phone

Two failures that look identical and are not

Who wins, and how honest the documentation actually is

What this means if you are building one of these

The One Thing a 24/7 Recorder Never Deletes: Android Now Caps How Many Keystore Keys an App Can Own

What the platform actually says

Why a recorder is the shape that reaches it

The failure mode is not the one you would guess

What the page does not say, and I am not going to guess

How to find out where you actually stand

This is not the storage argument

The short version

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

I also built an app — DigiCam

The EU's Reporting Clock Starts When Somebody Tells You: What the Cyber Resilience Act Asks of a Camera Vendor Who Cannot See Your Device

The part small developers assume does not reach them

The regulated object is not where the icon is

The four words the whole thing turns on

Which is a cost, and it is mine

What the trade actually buys

What I do not know

Two details that cut against the drama

Two things this gives a buyer, before any of it takes effect

The asymmetry to watch for

Your Phone's Screen Is Cracked and the Camera Still Works: Setting Up an Old-Phone Security Camera You Cannot Touch

Can you use a phone with a broken screen as a security camera?

How do you set up an Android phone when the touchscreen does not work?

The screen is two parts, and they die separately

Case 1: cracked glass, touch still works

Case 2: touch is dead, the picture is fine — use a mouse

Case 3: both are dead — and the trap in the obvious answer

The order to do things in

What the documentation does not tell you

The claim, corrected

The Camera Phone Is the Most Backup-Eligible Device You Own: What Android Auto Backup Actually Uploads From a "Local-Only" Camera

Are my phone security camera recordings backed up to Google Drive?

Does a local-only Android security camera app upload anything to the cloud?

The mechanism, in Google's own words

Why a mounted camera is the ideal backup candidate

The lock screen is doing more work than you think

The quota trap nobody warns you about

Turning it off is less binary than it sounds

What the documentation does not tell you

How to check your own camera phone

Correcting something we wrote

Where this leaves the local-only case

Best Free Security Camera Apps for Android in 2026 - and Which Ones Quietly Meter Your Free Plan

Which free Android security camera app has no data limit?

The 2026 field at a glance

Why free plans get metered: the part nobody writes down

1. Background Camera RemoteStream — best free security camera app with no data cap

2. IP Webcam — the other genuinely unmetered option

3. LineCast — the clearest example of a metered free plan

4. AlfredCamera — the biggest name, and the 2026 price move

5. AtHome Camera — free to watch, paid to keep

6. FadCam — excellent, open source, and not on Google Play

Three ways to tell whether an app is metering you

If your data is metered, this is not a small difference

Verdict