DEV Community

Super Funicular
Super Funicular

Posted on

A 24/7 Phone Camera Fills a 128 GB Card in 28 Hours, and the Write Speed You Paid For Is Only Guaranteed on Empty Space

#android #mobile #tutorial #performance

Most guides about turning an old Android phone into a security camera stop at the camera: resolution, night mode, whether the app survives the screen going off. Almost none discuss the component doing continuous work for the next several months — the flash storage. That is strange, because storage is the only part of the setup with a hard arithmetic ceiling. A radio link can be weak and still work; a battery can be old and still hold. Storage either has room for the next second of video or it does not.

So here is the arithmetic, from two sets of published numbers: what Android guarantees about a phone's own storage, and what the SD Association guarantees about a memory card. Both guarantees are real. Both are narrower than they look, and they are narrow in the same place.

How much storage does a phone security camera use per day?

Short answer: at 1080p and 30 fps, roughly 108 GB per day. At 720p and 30 fps, roughly 43 GB per day. A 128 GB card holds about 28 hours of 1080p30 or about 3 days of 720p30. No consumer memory card holds a week of continuous 1080p — rotation and deletion are not an optimisation, they are a requirement. Apps that record continuously in the background, like Background Camera RemoteStream, write to local storage rather than to a cloud account, which means this arithmetic is yours to manage rather than a subscription tier's.

Here is where those numbers come from, because you should not take a storage figure on trust. YouTube publishes the bitrate it recommends for live ingestion by resolution and frame rate, and since streaming to YouTube Live is one of the things a phone-as-camera does, those are defensible numbers for what a sensible H.264 encoder produces. From YouTube's own table:

Resolution / frame rate Recommended H.264 bitrate
240p–720p @30fps 4 Mbps
720p @60fps 6 Mbps
1080p @30fps 10 Mbps
1080p @60fps 12 Mbps
1440p @30fps 15 Mbps
4K / 2160p @30fps 30 Mbps

Convert those to storage. Eight bits to a byte, 3,600 seconds to an hour:

Resolution / frame rate Bytes per second Per hour Per day
720p @30fps (4 Mbps) 0.5 MB/s 1.8 GB 43.2 GB
720p @60fps (6 Mbps) 0.75 MB/s 2.7 GB 64.8 GB
1080p @30fps (10 Mbps) 1.25 MB/s 4.5 GB 108 GB
1080p @60fps (12 Mbps) 1.5 MB/s 5.4 GB 129.6 GB

And convert those to fill times, using nominal card capacities:

Card 720p30 1080p30
32 GB ~18 hours ~7 hours
64 GB ~1.5 days ~14 hours
128 GB ~3 days ~28 hours
256 GB ~6 days ~2.4 days

Two things fall out of that table immediately. The first is that dropping from 1080p30 to 720p30 buys you two and a half times more recording time for the same card — a bigger effect than any other setting you can change, and the single most useful thing to know if you are equipping a shop or a doorway on a budget. The second is that at any resolution worth recording, you will be deleting old footage continuously. Hold on to that second one. It comes back and it is the whole point of this article.

Is an old phone fast enough to record video 24/7?

Short answer: yes, comfortably, on the sequential-write numbers Android requires — but the margin depends on which of Android's two published write floors your recording pattern actually lands on, and they differ by a factor of ten.

Android's Compatibility Definition Document is the contract a device has to satisfy to ship as a compatible Android handset. Section 8.2 is about file I/O performance, and it publishes four numbers. Quoting the Android 15 CDD directly:

  • [8.2/H-0-1] MUST ensure a sequential write performance of at least 5 MB/s.
  • [8.2/H-0-2] MUST ensure a random write performance of at least 0.5 MB/s.
  • [8.2/H-0-3] MUST ensure a sequential read performance of at least 15 MB/s.
  • [8.2/H-0-4] MUST ensure a random read performance of at least 3.5 MB/s.

Those are floors, not typical values — any compatible handheld must clear them and most clear them by a lot. But a floor is the only thing you can reason about when you do not know which phone the reader owns, which is exactly the situation with an install base of older and budget devices.

Compare floor to demand: 1080p30 needs 1.25 MB/s against a 5 MB/s sequential floor — four times the headroom. 720p30 needs 0.5 MB/s — ten times. So on sequential writes, even the slowest phone allowed to call itself Android has room to spare. Recording video is not a demanding storage workload, and that is worth saying plainly, because the internet's default assumption is that an old phone is too slow for this. It is not.

Now look at the second number again. The random-write floor is 0.5 MB/s. That is 40% of what 1080p30 requires, and exactly equal to what 720p30 requires with no margin at all. If your write pattern stops being sequential, the guaranteed floor stops being sufficient. That comparison is the hinge of this article, and the reason the rest of it is about fragmentation rather than speed.

The gap between the cheapest compliant phone and the most expensive one

The same CDD document has a second set of storage numbers, which apply only to devices that declare a media performance class. From the Android 14 CDD, for devices reporting MEDIA_PERFORMANCE_CLASS of U:

  • [8.2/H-1-1] MUST ensure a sequential write performance of at least 150 MB/s.
  • [8.2/H-1-2] MUST ensure a random write performance of at least 10 MB/s.
  • [8.2/H-1-3] MUST ensure a sequential read performance of at least 250 MB/s.
  • [8.2/H-1-4] MUST ensure a random read performance of at least 100 MB/s.

Put the two tiers side by side and the spread is worth staring at:

Metric Baseline handheld Media performance class U Ratio
Sequential write 5 MB/s 150 MB/s 30×
Random write 0.5 MB/s 10 MB/s 20×
Sequential read 15 MB/s 250 MB/s ~17×
Random read 3.5 MB/s 100 MB/s ~29×

Both columns are Android. Both devices pass compatibility. One is allowed to be thirty times slower at the exact operation a camera performs every second of its life, and nothing on the box tells the buyer which one they have. Most budget handsets do not declare a media performance class at all, which means the only number you can rely on for them is the left-hand column.

This is the storage twin of a pattern I keep running into: the platform guarantees a floor, marketing quotes a ceiling, and the useful engineering happens in between. It is the same shape as the Camera2 hardware level deciding whether your phone can record and stream at the same time — a runtime property that no model name predicts.

What a microSD Speed Class actually guarantees, and the condition attached

If you are recording 24/7 you are probably recording to a memory card, because internal storage on a budget phone is smaller and more annoying to swap. So the card's guarantee matters more than the phone's.

The SD Association is explicit about what its speed markings mean. The class symbols "with a number indicate minimum writing speed," and the standard "assures minimum sequential card access performance ... under defined conditions specified in the standard." That is a floor for sustained writing, precisely the guarantee a continuous recorder wants. A V30 card guarantees 30 MB/s minimum sequential write — 24 times what 1080p30 needs, and six times the floor Android sets for the phone's own internal storage. On paper, then, a mid-range memory card can be substantially faster at sustained writing than a compliant budget phone's built-in storage is required to be, which inverts the usual folk wisdom about cards being the flaky part.

Now the condition, which I have not seen quoted anywhere in the phone-as-camera literature:

"Speed Class write is defined to perform sequential writes to a completely un-fragmented area (called 'Free AU'). ... On the other hand, even unused memory exists in total, there is a possibility that host cannot perform Speed Class recording. In that case, data arrangement to reduce fragmented area or move data to another storage to re-format the card will be required."

Read that carefully. The guaranteed write speed — the number you selected the card for, the number printed on the card — is defined on completely unfragmented free space. The SD Association states outright that a card can have unused capacity in total and still be unable to deliver Speed Class recording, because that capacity is not contiguous.

The loop: the only way to record forever is the thing that voids the guarantee

Put the three findings together.

  1. A 24/7 camera at any useful resolution will fill any consumer card in hours or days. Continuous deletion of old footage is mandatory, not optional.
  2. Continuous write-then-delete-then-write is the canonical way to fragment a filesystem: files of varying length are removed from the middle of the used space and new ones written into the holes.
  3. The card's guaranteed write speed is defined on unfragmented free space, and Android's guaranteed random write floor — 0.5 MB/s — is below what 1080p30 requires.

So the operating mode that makes a 24/7 camera possible is the same one that systematically erodes the conditions under which its storage guarantee was measured. That is not a defect in anybody's product. It is a structural mismatch between how storage performance is specified — clean, sequential, one pass — and how a rotating recorder behaves — dirty, interleaved, forever.

Let me be careful about how strong a claim this is. I am not saying your card will drop frames next Tuesday; modern flash controllers do a great deal of internal work these specifications do not describe, and plenty of setups run for months without trouble. The narrower and more useful claim: when a long-running recorder starts dropping frames or producing short broken files, "the card is worn out" is usually the wrong diagnosis, and "the free space is no longer contiguous" is a hypothesis nobody tests. The SD Association names the remedy in the same paragraph — consolidate the data, or move it off and reformat the card. Ten minutes, documented basis, costs nothing.

If a recording does get cut off mid-write, that is a different problem with a different cause — what Android's low memory killer does to a 24/7 camera covers the memory-pressure version of that failure, and it is worth knowing which of the two you are looking at.

Which card to buy for an older phone, and which number to ignore

This is the part that saves actual money, and it turns on a detail of the SD standard that card marketing does not advertise: speed classes are tied to bus modes. In the SD Association's words, "it is necessary to use a bus mode fast enough that does not affect memory write speed," and it spells out the pairing — "V60 and V90 are used in UHS-II mode or faster," while "V30 can be applied to UHS Bus IF product family."

UHS-II cards have a second row of contacts on the back, and the phone's slot needs matching hardware to use them. Budget and older phones essentially always have single-row UHS-I slots, so a V60 or V90 card in such a phone cannot deliver the speed you paid extra for. The card works; it simply runs at UHS-I speeds. You bought a number the slot cannot reach.

There is a second trap, and the SD Association states it flatly:

"Note that expected write speed will not be available by a combination of different class symbols between host and card such as Host Class 10 and Card U1, Host U1 and Card V10, etc. even those are indicated to the same 10MB/sec write speed."

Two cards can be labelled with the same megabytes-per-second and still behave differently depending on the class family the host expects. The number alone does not settle it.

So, practically, for an old phone running as a camera:

  • Buy capacity first. The table at the top of this article is the real constraint. Given a fixed budget, a larger V10 or V30 card beats a smaller V60 card, every time.
  • V30 is the sensible ceiling for a UHS-I phone. It is applicable to the UHS-I family and guarantees 24× what 1080p30 needs. Paying for V60 or V90 buys a capability the slot cannot use.
  • Ignore the big number on the front of the card. That is usually peak read speed. You are writing, continuously, and the number that describes writing is the small one in the class symbol.
  • Record at 720p unless you specifically need 1080p. It is a 2.5× multiplier on how long your footage lasts before it is overwritten, and for a doorway, a shopfront or a room, 720p usually identifies what you needed identified.
  • Reformat the card periodically rather than only deleting files, and use a tool that writes a proper SD-standard layout. This is the documented remedy for the fragmentation condition above.

None of this requires a subscription, a credit card, or a working internet connection — it is a card, a phone you already own, and the arithmetic. If you want the running-cost side of the same picture, what an old phone actually costs to run for a year does the electricity version of this exercise.

What these documents do not tell you

Five things I could not establish from the published sources, stated plainly rather than guessed at:

  1. Android's CDD specifies storage speed, not storage endurance. Section 8.2 has four throughput requirements and no lifetime-writes requirement. There is no published Android figure for how many terabytes a phone's internal flash must survive. Anyone quoting a specific lifespan for your phone's storage is not getting it from this document.
  2. Whether a given phone's microSD slot is UHS-I or UHS-II is rarely published. The SD standard defines the bus modes; phone spec sheets very often omit which one the slot implements. The single-versus-double-row-of-contacts test applies to the card, not reliably to the slot.
  3. I could not establish that Android exposes the card's Speed Class to apps. An app can measure throughput, but that is a measurement, not a reading of the card's rating.
  4. The baseline CDD numbers are minimums, and I have no data on the distribution above them. A real budget phone may be five or fifty times faster than the 5 MB/s floor. The floor is what is guaranteed; the typical value is not published anywhere I could find.
  5. The fragmentation effect is documented as a condition on the guarantee, not as a measured degradation curve. The SD Association says Speed Class recording may be unavailable on fragmented space. It does not publish how much fragmentation, or how much slower. I have not measured it and I am not going to imply a number I do not have.

The honest summary

  • Storage, not speed, is the binding constraint on a 24/7 phone camera. 108 GB a day at 1080p30, 43 GB at 720p30.
  • Every compliant Android phone is fast enough to write that stream sequentially. The floor is 5 MB/s and 1080p30 needs 1.25 MB/s.
  • The gap between the cheapest compliant phone and a media-performance-class phone is 30× on sequential write and 20× on random write, and nothing on the box tells you which you own.
  • A V30 card guarantees six times more sustained write than Android requires of the phone's own internal storage — the card is not the weak link people assume.
  • But both guarantees are written for clean, sequential, unfragmented writing, and a rotating 24/7 recorder is the workload that removes those conditions. Periodic reformatting is a documented, free remedy that nobody performs.
  • Buy capacity and V30, not V90. Record at 720p. Reformat now and then.

The camera is the interesting part of a phone-as-camera setup. The storage is the part that decides how long it runs.

Background Camera RemoteStream records with the screen off, stores footage locally on the device rather than in a cloud account, and serves a live view from a small web server running on the phone itself — so the storage arithmetic above is yours to control rather than a plan tier's.

Sources

Related reading

Top comments (0)