Does sharing your phone's connection drain the battery? What we measured
We benchmarked our own Android sharing node in June and found it using 76% of one CPU core to move 32 Mbps. Here is what that number actually meant, what we fixed, and what we have not.
In June we benchmarked our own Android sharing node and found something we didn't like: moving 32 Mbps of traffic used 76% of one CPU core. That's not a rounding error. That's most of a phone's compute budget spent on a background process most people sharing their connection will never open the app to watch running.
The honest answer to "will this drain my battery" is: on the build we measured, probably more than it should. We've fixed part of what caused it. We haven't fixed all of it, and this post says exactly which is which.
Why we stopped chasing gigabit speeds
There's a well-worn playbook for a fast network datapath: eBPF/XDP in the kernel, DPDK for poll-mode userspace networking, WireGuard compiled into the kernel itself. Real numbers, tested by other people: eBPF/XDP can drop a packet in 38 nanoseconds, and DPDK-style approaches move traffic at line rate on 10Gbps+ hardware. All three need root or a kernel module. On Android, that means the VPN permission or worse, and it breaks the reason a SparkUp node can run as a plain background process at all.
So we asked what problem we were actually solving. A phone shares its own WAN connection — a few hundred Mbps at the outside, usually much less. Chasing a 10Gbps-capable datapath on hardware that will never see 10Gbps is solving a problem nobody has, and every technique that gets you there costs something: more code, more memory, or root access we won't ask for.
We reordered the priorities that had been implicit until then: energy first — battery and heat — then latency, then security, then a light footprint, then simplicity. Throughput dropped off the list. A node that tops out at 300 Mbps but drains a phone in two hours is a worse product than one that moves less and disappears into the background.
What was actually expensive wasn't the traffic
The obvious guess is that moving more bytes costs more battery, in a straight line. On this stack, it doesn't. A SparkUp node runs a full TCP/IP stack in userspace (gVisor) so it can work without the VPN permission or root — the same trick that lets it run as an ordinary background process is what puts a software network stack between every packet and the wire.
The gVisor team has published their own number for this: their netstack spends 20-30% of its time under load on memory allocation and garbage collection, not on the packets themselves. We found we were adding to that ourselves. Our own adapter code allocated a fresh buffer and copied into it for every single inbound packet, on top of whatever the netstack itself already spent. Move enough packets and the CPU spends real time on allocation and cleanup that has nothing to do with the bytes it's supposed to be moving.
What we fixed, and what we have not
We bounded the queue between the tunnel and the network stack. Before that, a slow or lossy connection could let it grow past a couple hundred packets — not a crash risk by itself, but it adds queueing delay nobody asked for (the networking term is bufferbloat), and on a phone, a bigger queue is memory sitting around instead of being freed. It now has a cap: packets past it get dropped and counted, not queued forever. TCP already knows how to recover from a dropped packet. It has no way to recover from a queue that never lets go of the connection's real round-trip time.
We have not shipped the fix our own numbers say matters most. Every inbound packet still gets a fresh heap allocation and a copy before it goes anywhere. The fix is a buffer pool: reuse the same memory for the next packet instead of asking the allocator for new memory every time. It's designed. It's not in the build anyone is running today.
So does sharing your connection drain the battery?
Here is what we can say without guessing. On the build we measured, moving 32 Mbps used 76% of one CPU core on a Galaxy S24 acting as a sharing node — enough to notice if the phone is doing anything else at the same time. Our target once the pooling fix ships is under 30% of one core at 50 Mbps, with the case never reaching the point where Android throttles the chip. We don't have that number yet, because the fix that's supposed to get us there hasn't landed.
SparkUp already watches for the failure mode this creates in the meantime: a thermal and battery guard that pulls sharing back, or stops it outright, if the phone runs hot or the battery gets low. You can also set a bandwidth cap yourself in Settings → Sharing, rather than leaving the app to guess the right number for your specific phone.
What to do if you're sharing today
If your phone is from the last two or three years and mostly plugged in while sharing, you're unlikely to notice. If it's older, or you're sharing on battery while running something else CPU-heavy, set a lower cap in Settings → Sharing until the allocation fix ships. The guard is there to catch the worst case; a cap you chose yourself beats one an already-hot phone triggers for you.
We'll publish the after numbers once the buffer-pool fix ships, from the same benchmark setup, so the before and after are one measurement compared against itself rather than two different runs presented as if they were.