ClearDeck
  • Intermediate
  • 5 min read
  • Updated 2026-10-09

Power saving and battery use

What a local firewall really costs to run, measured honestly — 20.67 seconds of CPU per half hour — and exactly what the power-saving switch trades away to lower it.

A firewall that sees every connection sounds like something that ought to show up in your battery stats. Rather than reassure you, this page gives the measured number, explains what it means, and then says plainly what the power-saving switch gives up to make it smaller.

What it actually costs

On a OnePlus 6T running Android 11, protection ran for 30 minutes. The engine process accumulated 2067 jiffies — 20.67 seconds of CPU time. Across that half-hour window, that is 1.148% of a single CPU core.

For contrast, the backgrounded app process used 19 jiffies in the same period. That is essentially nothing, because Android had frozen the interface while it was off-screen.

A jiffy is the kernel’s smallest unit of CPU bookkeeping — one scheduler tick. On this build, 100 of them make one second, which is why 2067 jiffies works out to 20.67 seconds. The number worth holding onto is therefore seconds of CPU time on one core: about twenty-one of them across half an hour.

What 1.148% of one core means in practice: take a single core and hand it nothing but ClearDeck, and it would still sit idle roughly 98.9% of the time. A phone has several cores, so ClearDeck’s share of the whole device is smaller again. This is not a drain you will notice; it is closer to a rounding error in the battery graph.

Why it is this cheap: the sampling table

The engine samples on a timer instead of watching traffic continuously, which is what keeps the cost low. A tuning pass slowed those timers down; power saving slows the most important one further still.

What refreshes Before tuning After tuning Power saving
/connections snapshot 1 s 3 s 15 s
Notification update 3 s 5 s —
Statistics flush 15 s 30 s —
Log folding 500 ms 1 s —
Interface polling 5 s 10 s —
Local-network scan 10 s 30 s —

Read it left to right. The “after tuning” column is what a normal install does today; only the /connections row changes again under power saving. Everything else stops being adjustable at that point — the app does not keep speeding the other timers up and down.

What power saving actually gives up

The switch lives in Settings → Power saving, and the app states its effect like this:

Updates the speed readouts less often and pauses Deep inspection, so the battery lasts longer. While it is on, deep URL blocking and the recent-activity list are reduced.

In concrete terms, turning it on does two things:

  • It pauses Deep inspection. The deep URL layer stops blocking while power saving is on. The deep modules show Paused until you switch it off again, which brings them back automatically.
  • It widens the /connections snapshot from 3 seconds to 15 seconds. The snapshot is how the app learns which connections exist. Anything that lives shorter than a full interval can fall between two samples and never be recorded, so the per-app “recent activity” list thins out.
missing src/assets/shots/en/power-saving.png
Settings · Power saving

Two parts of the picture are not affected, and this matters:

  • Per-app and per-domain byte totals stay correct. The snapshot carries cumulative counters, and totals are computed from the difference between samples. A missed sample does not lose bytes.
  • Blocked connections are completely unaffected. Rejections come from the kernel log stream, not from that snapshot — so every block is still seen and counted, and blocking continues at full strength.

The one thing you cannot turn off

The kernel ships its own sampler, running at 1 Hz — once per second — for as long as the library is loaded. It runs unconditionally, and the Kotlin side cannot switch it off. That is the floor under every number above: the resident cost that remains even in power saving. Deep inspection and the fast snapshots are optional; this one is not.

A separate knob: the log window

Not everything about resource use is about timers. Settings → Access log window sets how many access records ClearDeck keeps — 100, 500, 1000 or 2000, with 500 the default. A larger window keeps more history but holds more in memory.

missing src/assets/shots/en/settings-log-window.png
Settings · Access log window

If your concern is memory rather than CPU, this is the knob to reach for. Power saving is about how often the engine looks; the window is about how much it keeps.

When to turn it on — and when not to

Turn power saving on when you are away from a charger, want to stretch the battery, and you do not rely on the two things it pauses. The core domain blocking — ads, trackers, malicious sites — keeps working unchanged, and blocks are still counted in full, so most people give up less than they expect.

Do not turn it on if either of these is true for you:

  • You rely on Deep inspection. Power saving pauses it, so the deep URL layer stops blocking while the switch is on. See Deep inspection for what that layer does.
  • You use the per-app recent-activity list to audit behaviour. Under power saving, only connections that last longer than 15 seconds are recorded, so short-lived requests stop showing up.

With those two caveats understood, it is a fair trade: a real reduction in work for leaner records, with the firewall itself untouched.

Next

This guide is also available in 简体中文

← All guides