schweizer This is a project account, not a personal account.
schweizer schweizer schweizer schweizer You're greatly underestimating how much power is used by Signal's WebSocket push fallback. The battery usage stats provided by the OS don't fully account for how much power is drained by repeatedly waking the device to keep a push connection alive. The battery usage stats aren't at all precise and it doesn't weight triggering waking up the device a lot as much as it should. It's not the amount of traffic which is relevant but rather repeatedly waking up the application processor and either cellular or Wi-Fi to send and receive data. It doesn't matter that it's a tiny amount of data but rather how many wakeups there are.
Signal does not throttle the push service checks based on network reliability heuristics. Signal pings the connection as much in the background as it does in the foreground. It should be throttling it back to infrequent checks and manually detecting network changes via the appropriate broadcasts.
The reason Signal has it so low is to deal with the worst cases of CGNAT. Without CGNAT, NAT or a stateful firewall in place, a TCP connection can last indefinitely. NAT and stateful firewalls usually permit long idle times. It's CGNAT which causes issues so IPv6 should be heavily preferred for push by attempting to use it first. Both IPv4 and IPv6 can be handled by gradually making the checks more infrequent and detecting if they start failing up to a certain limit which can vary for both.
Signal just doesn't care about optimizing this because it's difficult to do it well and they don't consider it important since only a small portion of people are using it. They only have it so Signal works without complaints and don't care about the battery life. It does drain a lot of power, you just can't fully see it from the battery stats.