Excessive battery drain

[Alias3333]

• I have searched open and closed issues for duplicates
• I am submitting a bug report for existing functionality that does not work as intended
• I have read https://github.com/signalapp/Signal-Android/wiki/Submitting-useful-bug-reports
• This isn't a feature request or a discussion topic

---

Bug description

Describe here the issue that you are experiencing.

Steps to reproduce

• using hyphens as bullet points
• list the steps
• that reproduce the bug

Actual result: Describe here what happens after you run the steps above (i.e. the buggy behaviour)
Expected result: Describe here what should happen after you run the steps above (i.e. what would be the correct behaviour)

Screenshots

Device info

Device: Manufacturer Model XVI
Android version: 0.0.0
Signal version: 0.0.0

Link to debug log

https://debuglogs.org/android/5.42.7/c7b1be0c78f85a3b2a937a657ee325af04675bebf433f621f5e74e6439a97e7e

[alex-signal]

Please fill out the sheet properly, and check if there are other issues related to this one first.

[caveman1973]

I noticed Signal showing on my battery most use list.

I'm using GrapheneOS in a Pixel 5. Battery optimization is disabled since I'm not using Google Services for push notifications.

Signal is version 5.44.3. previous two versions showed the same problem.

[a13xl]

Same issue on Pixel 6a with GrapheneOS without Google play services.

• Download Signal from Aurora Store (or Homepage)
• Start Signal
• Give Access to Contacts, Sensor and Network
• Try Battery use optimazed and unrestricted
• Close App
• Wait for a while (e.g. 1h)
• Check Battery use in Settings: Signal is running all the time and burn down battery (20% of Battery use for 10 min usage, whole day, is normal)

Pixel 6a
Android 12
Build-Num. SD2A.220601.004.2022080500
Signal 5.44.4

Debug:
https://debuglogs.org/android/5.44.4/c31749b0bb1ff1e8a99be8fe1cad3dc8cfbc7055f04d791e4dcb7eaf16759702

[furai]

Exactly the same issue with LineageOS 19.1 on OnePlus9T without google services.
I don't know how it works exactly but I guess the custom signal service is maintaining connection at all times to get the messages as soon as they arrive.

If my assumption is correct maybe we could poll in intervals which could probably lower the battery drain? I don't need to get every message instantly and I'd be happy to have a setting allowing me to check for new messages every 1-5 or so minutes.

Side note: I'm pretty sure it's been happening as well on older versions of Android. I've been using signal this way without google services for at least 3 years and battery drain was always an issue.

[caveman1973]

I had a Pixel 3 and for the past years I've never seen Signal in the top list of apps that used more battery. For me it's recent. +3 months I think. I don't want to install an old version to test it

[furai]

One thing I've noticed for sure is that if you lock your screen with Signal in foreground - then it's draining battery even faster.

[cody-signal]

Hi folks, unfortunately there's not much we can analyze as Android doesn't surface this information to us to include in our debuglogs. We'd need an Android Bug Report which dumps A TON OF INFORMATION about your entire device. Which is why we don't like asking for them. If you are able to reproduce this on a test device and willing to send us a report, please do so via email to cody at signal dot org.

If you're tech savvy, and want to investigate it using the tooling we would, then you can check out Battery Historian at https://developer.android.com/topic/performance/power/battery-historian to get more details on what exactly SIgnal is doing that's draining your battery.

[furai]

Once I get my hands on a free device to fiddle with I could probably debug it. But it won't happen for another month and I have barely any experience with Android development. Anything in particular what to look for? Any tips other than link above?

[ahaverty]

I hope it's appropriate to drop some info here on what seems to be the same issue recently for myself. I can't say I've seen these warnings from signal over the last year, but seem to get them regularly for the last few days.

Signal v5.48.2
OnePlus 7T Pro
OxygenOS v11.0.9.1.HD01BA (Android 11)

[furai]

I use Don't optimise option per recommendation from signal cause otherwise you can stop receiving messages altogether.

[b0she]

I had to delete Signal on my phone, it killed my battery. Samsung A52s 5G

[FuzzyQuils]

Have the exact same issue here, Pixel 4 running GrapheneOS based on Android 13. Weirdly though I only started seeing the awful battery life after the Android 13 update so I'm not 100% sure it's entirely Signal's fault.

Incidentally I'll be giving battery historian a go, I've done a tiny bit of android dev and may be able to isolate what could be causing this. (My guess is the websocket code's going haywire due to changes in Android 13 but that's assuming other people in this thread are also on 13)

Edit: looking again it looks like other android versions have the issue as well.

[Ronkn]

I'm having this issue using calyxos on a pixel 4a, using websockets for push notitcations. Accounts for 15% battery drain over 10 hours, all the while I had not touched the phone.

Same issue with my wife's pixel 4a running calyxos except she's using MicroG cloud messaging for notifications.

Both on Android 12. Both signal 5.48.3

[Toasterbirb]

I'm also experiencing this battery draining issue with Molly-FOSS, a Signal fork without google play services and I think it uses websockets for notifications.

My battery drain is at this level

I have also posted an issue about it to the respective fork repo mollyim/mollyim-android#126 and apparently this issue is an upstream issue, so I'm also posting about it here

The issue contains some more information and a debug log

[drkhsh]

Same issue on a Pixel 6 with GrapheneOS without Google Play Services. Seems to be worse on mobile data than on WiFi.

[Ronkn]

I don't care anymore as I'll be unsintalling signal once sms support is dropped. I'm not using multiple apps to communicate. Time for Element/Matrix

[Ammako]

How's it looking with 5.53.8? It used to be that Signal was consistently at the top of my list in battery usage, but now it sits all the way down at the bottom alongside my keyboard. I'd be interested in knowing if people are still struggling with this, or if the various improvements in the newer version have actually helped.

[FedFrog]

Same issue with Pixel 7 Pro stock, so with Android 13. VIdeocalling is borderline impossible (20% in 10 mins, super hot phone) and generally Signal takes a lot of battery even for normal chatting

[furai]

How's it looking with 5.53.8? It used to be that Signal was consistently at the top of my list in battery usage, but now it sits all the way down at the bottom alongside my keyboard. I'd be interested in knowing if people are still struggling with this, or if the various improvements in the newer version have actually helped.

I didn't see any difference, issue persists on newer versions.

[Toasterbirb]

It has been a bit better for me. Signal is still topping the charts, but not with as outrageous numbers as before. My phones battery lasts at least for 1-2 days, so its at acceptable levels I'd say.

Same issue with Pixel 7 Pro stock, so with Android 13. VIdeocalling is borderline impossible (20% in 10 mins, super hot phone) and generally Signal takes a lot of battery even for normal chatting

Can confirm. I made a group video call and my phone got extremely hot during it. I think other participants in the call also had to plug their phones into a charger because it was draining so much battery. Their devices had google play services installed though, so that's most likely an entirely different issue

[starbrights]

As of me I wouldn't call battery drain excessive, but definitly more than other messangers/apps.
I am running it without playservices, but with microG instead. It seems not support it's push service, although it would be possible. I just have no choice.

[0-5-0]

I've noticed on my Pixel 6a phone with GrapheneOS that if I launch Signal Messenger then back out of it or press home (leaving it in the "system tray" let's say) then the battery usage is quite high. If I however bring up the "system tray" and clear all apps from the "system tray" or background then the Signal battery usage goes way down and the Signal background service still seems to work fine (I get calls/messages).

This is opposite to how I've seen it work when using the Tutanota client for example. If I clear the Tutanota client from the "system tray" then battery usage goes way up and if I leave it running in the "system tray" then battery usage is way down.

After a fresh reboot for example without launching any apps then Tutanota would use lots of battery but Signal would use little battery.

After launching both apps without clearing the "system tray" then Signal battery usage would go up but Tutanota's would go down.

I would hope that there's a smart way for each app to find out if they're cached and then behave accordingly.

Has anyone experienced this behavior?

[ermirry]

I am also experiencing severe battery drain with signal in the background. I'm using a Pixel 4a with stock Android 13. My battery went from 50% to dead overnight with signal being the biggest battery user in each two hour section of the battery usage graph shown below. I was also fast asleep during these hours, so I was not using the app.

[starbrights]

I found the reason for my higher power consumption (compared to my previous installation). I use microG and this includes cloud messaging. Usually this can be used by apps, but it seems that Signal doesn't use it first. So it has to do this job on it's own. After delete and reinstall it recognises the microG service and returns to a moderate power drain.

BTW: Power drain has been low in Flight mode. Please check that too.

[s7m0n]

Same/similar issue here.
Not at home so no adb or further tools at hand atm.
Just now charging to 100% for another cycle. Any hints on what to try/test.
Currently Signal is set to use "Intelligent Control" for Battery.
Somehow it seems to stay active and not really go to idle even in background.
Device is a OnePlus 7T

[ermirry]

So after my comment yesterday, I changed Signals battery profile in Android 13 from Optimized to Restricted and charged the device to 100%. Waking up this morning, my overnight battery drain is waaaay better. I lost about 10% battery overnight vs the 50% lost when signal was set to Optimized.

Signal is definitely putting in over time in the background when it shouldn't be.

[cody-signal]

To those newly posting on this issue, are you using the background websocket without google push notifications or using push notifications?

Additionally, if you are able to reproduce this issue on a test device, providing an Android Bug Report is the most helpful for looking at battery drain issues. I call out test device because an Android Bug Report contains a ton of personal information we'd rather you not send us and likely you'd rather not share.

Here's the tool we like to use to look at battery usage, feel free to use it yourself and report back what you see:
https://developer.android.com/topic/performance/power/battery-historian

[ermirry]

@cody-signal since I am using stock Android 13 (not rooted), I am assuming that I am just using google's push notifications as is.

I'm going to look around for a test device that supports the latest version of Signal to see if I can gather more data.

[s7m0n]

Hi,

just to be sure on the push notification questions. If i go to App-Info on Signal and then notifications all are enabled.
Or would i need to check another place as well. Unfortunately i currently do have only my main device available.
When back home i might be able to try battery historian to look on my own bug report - but to be honest that will not be soon (currently short on free time and not back till next year).

In case of other things for testing - let me know.
Let me also say thanks for providing Signal and your efforts

Edit:
Also some details on my device:

• Oneplus 7T
• Android 11/ Oxygen OS 11.0.9.1HD65BA
• Not rooted
• Security update: 2022-06-01
• Google Play system update 1 August 2021

[cody-signal]

The easiest way would be to look at your debuglog and in the top block there will be a line like:

FCM : <false|true>

If it's false, you are in websocket mode, and if true, you are using Google's push notification system. Based on your device details I'm going to guess you are in push mode, but it's worth double checking.

[kushagra-xo]

The only solution to use signal without battery drain, for now, is to use molly unifiedpush version with mollysocket. It brings down total battery usage of molly-up + ntfy up to 5% at max. As I figure it has been years since the issue and people can't wait forever for signal to fix this.

you need to self host mollysocket, which i don't find feasible for me.

[duven87]

The only solution to use signal without battery drain, for now, is to use molly unifiedpush version with mollysocket. It brings down total battery usage of molly-up + ntfy up to 5% at max. As I figure it has been years since the issue and people can't wait forever for signal to fix this.

you need to self host mollysocket, which i don't find feasible for me.

Ah! with only mollyup + ntfy.sh I won't get any difference at all?
where to get my own hosted mollysocket without having to purchase a server from a provider? no distributors?

[jayb-g]

It brings down total battery usage of molly-up + ntfy up to 5% at max.

@duven87 this is as good as it gets. For now. On signal you might get up to 50% or more battery usage as reported by users.

where to get my own hosted mollysocket without having to purchase a server from a provider? no distributors?

Fly.io used to have free quota, the answer already links to the repo mollysocket-fly, which guides on how to set it up. Even if not free, it might cost you well under $5 or you can try aws but I have no experience with it.
It might also be possible to self host locally but then it would involve exposing it using expose or dynamic DNS, not sure though.

[aventura-ms]

It brings down total battery usage of molly-up + ntfy up to 5% at max.

@duven87 this is as good as it gets. For now. On signal you might get up to 50% or more battery usage as reported by users.

where to get my own hosted mollysocket without having to purchase a server from a provider? no distributors?

Fly.io used to have free quota, the answer already links to the repo mollysocket-fly, which guides on how to set it up. Even if not free, it might cost you well under $5 or you can try aws but I have no experience with it. It might also be possible to self host locally but then it would involve exposing it using expose or dynamic DNS, not sure though.

After several days of testing I have realized that the consumption has not changed anything with LOS+bitgapps on Pixel 4a.
But yesterday I installed Langis and it's the first time I see the app in 5th position in battery consumption and only 5%. It was always the first with 20-35%.
I think I will stay with it for now.

[jayb-g]

@aventura-ms Langis might not be up to date. Whereas molly is same as latest signal as of now, and fast enough with follow up updates.

[aventura-ms]

that the updates go a little slower in exchange for having a phone that will last many hours more battery, I prefer it.
It seems to be updated often anyway.

[johschmitz]

Signal from Play Store battery usage on a current stock Pixel 8:

[duven87]

What a parasite, not even with google apps yields the battery.
I because they require me Signal at work, otherwise I would have already freed me from it.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[camoz]

some activity

[johschmitz]

This issue seems to still persist. I now updated to Android 15 and will see if that helps somehow.

[lonix1]

Dupe: #9729
If you upvoted this one, upvote that one too, so it rises in the list of top complaints

[atharva-p]

Signal app consumes more battery than playing Minecraft on a remote server, all while having less screen time than the game. I've also noticed overall battery drain after getting signal

[kq01526]

Potential solution:

1. Android Settings > Apps > Signal > App Battery Usage > Allow Background Usage = Enabled and Optimized (not Unrestricted)
2. Android Settings > Apps > Signal > Alarms & Reminders > Allow Setting Alarms And Reminders = Enabled

The second setting is only available when the first setting is not set to Unrestricted.

This is also how it's being done with Thunderbird for Android: https://support.mozilla.org/en-US/kb/configure-push-email-thunderbird-android#w_alarms-reminders-permission-for-android-13-and-above

And at first glance it also seems to noticeably reduce the battery drain on Signal.

It remains to be seen though if the WebSocket based Signal notifications still arrive quickly and reliably with those app settings.

[Ronkn]

Potential solution:

1. Android Settings > Apps > Signal > App Battery Usage > Allow Background Usage = Enabled and Optimized (not Unrestricted)
2. Android Settings > Apps > Signal > Alarms & Reminders > Allow Setting Alarms And Reminders = Enabled

The second setting is only available when the first setting is not set to Unrestricted.

This is also how it's being done with Thunderbird for Android: https://support.mozilla.org/en-US/kb/configure-push-email-thunderbird-android#w_alarms-reminders-permission-for-android-13-and-above

And at first glance it also seems to noticeably reduce the battery drain on Signal.

It remains to be seen though if the WebSocket based Signal notifications still arrive quickly and reliably with those app settings.

I switched to Molly a year ago and it solved all of my problems (your backup eitll transfer fine). I linked the solution that they had at some point in this ticket or another, but signal doesn't seem to care. So that is my reccomendation.

[jayb-g]

It remains to be seen though if the WebSocket based Signal notifications still arrive quickly and reliably with those app settings.

Right. If the message and call notifications are instant, then it would be a good workaround for the time being since signal team doesn't seem to be interested in working towards a fix at all.

[kq01526]

Unfortunately this does not seem to solve the excessive battery drain either after all. The battery is still being drained massively.

So probably the only "solution" at the moment would be to completely block the battery background usage for Signal and to open the app manually on a regular basis to check for new messages/calls. Which would essentially no longer be instant messaging and therefore would unfortunately make Signal on Android somewhat impractical.

@Meredith-Signal @greyson-signal @alex-signal @cody-signal @nicholas-signal @mtang-signal @clark-signal @jim-signal @moiseev-signal @akonradi-signal @andrew-signal @ehrenkret-signal @rashad-signal @adel-signal @eager-signal @jrose-signal @jlund-signal @jon-signal @nina-signal

Why would Signal on Android be so dependent on Play Services / FCM? Is there no way this issue can be solved without installing Play Services / FCM? And is there a specific reason for why there are no updates on this issue (and its duplicate)?

[jm355]

use molly. It has a better websockets implementation, or supports unifiedpush if you set up mollysocket. Why the signal devs haven't integrated any of that is a mystery to me, but at least molly does

[kq01526]

@jm355
use molly. It has a better websockets implementation

Not according to: mollyim/mollyim-android#126

And Signal Android users should not have to use a fork in the first place just to get basic functionality working. And:

@jm355
or supports unifiedpush if you set up mollysocket.

Each Signal Android user having to set up a separate server to be able to receive real-time notifications can not be considered a solution either.

@Ronkn
I switched to Molly a year ago and it solved all of my problems

Not according to: mollyim/mollyim-android#126

@Ronkn
I linked the solution that they had at some point in this ticket or another, but signal doesn't seem to care.

Which is probably referring to: #13337

Even if Molly has merged that already, it does not seem to make a difference.

@Meredith-Signal @greyson-signal @alex-signal @cody-signal @nicholas-signal @mtang-signal @clark-signal @jim-signal @moiseev-signal @akonradi-signal @andrew-signal @ehrenkret-signal @rashad-signal @adel-signal @eager-signal @jrose-signal @jlund-signal @jon-signal @nina-signal

Any update?

[jm355]

I agree it's not a solution. For one thing, a fork is always gonna be at least a little behind upstream so security fixes will take longer to get to those users, but I get minimal drain from molly using websockets. It does actually connect differently, it removes unneeded connections whereas signal has a few that stick around. So for me, the downsides of using a fork are worth good battery life

[kq01526]

@jm355
but I get minimal drain from molly using websockets.

Not according to: mollyim/mollyim-android#126 (comment)

Quote:

"I mean https://ntfy.sh/ with the ntfy.sh app on my phone. I have my own personal instance that I use, but it's effectively the same as using the default ntfy.sh server."

And:

@jm355
So for me, the downsides of using a fork are worth good battery life

Not according to: mollyim/mollyim-android#126 (comment)

Quote:

"The pull request #13337 (which molly uses) makes it better, but it's still not great."

[kq01526]

To add, what might also be worth mentioning:

According to #13704 , apparently the issue is not even fixed even when using Play Services / FCM.

[Ronkn]

Honestly I'm writing off signal and sticking with Molly. I've unsubscribed to this ticket and others I've been subscribed to, and keep getting tagged in them. This issue has been going on for over a year. nearly 3 years. Here's a screenshot of my battery usage on my pixel 4a that's 4 years+ old and currently overall is at 77%. I use the Foss Molly app and not the self hosted unified server for notifications. I get notifications instantly via web sockets and it works fine.

Please don't continue to @ me.

Thank you and good luck. I hope you resolve the issue someday for all of the users that rely and value this project.

Edit:
My wife has a 1 year old pixel 6a. Uses signal with we sockets for notifications. Phone battery is at 71%, signal used 56% and had similar screen time and background time to mine. I'm installing Molly on her phone tonight.

[starbrights]

@Ronkn : Does molly responds fast enough for operating calls? So does it ring?

[jayb-g]

@starbrights yes, no problems at all

[LinuxOnTheDesktop]

Cf. #12341.

[donnm]

I've also had this problem recently following an update to (somewhere around) 7.30.1 (now running 7.33.2) and have been trying to find the cause since. I'm using:

• Signal on LineageOS (no microG)
• Molly on LineageOS (linked device, no microG)
• Signal-Desktop on Debian (linked device)
• signal-cli arm64 on Debian (linked device, raspberry pi)

For me this problem affected latest versions of both Signal and Molly on LineageOS.

From my testing, it looks like Signal and Molly remained active (with Allow background usage set to Optimized) much more than previous versions. My phone was warm and the battery would drain in a matter of hours.

By watching messages received from signal-cli in daemon mode, I could see a flood of unusual envelopes containing "Received a sync message" from both Signal and Molly at intervals varying roughly 1 to 4 seconds (see below, device 1 is Signal Android, device 4 is Molly):

Envelope from: xxx yyy-yyy-yyyy (device: 1) to yyy-yyy-yyyy                                                                                                                                                                
Timestamp: 1740054565152 (2025-02-20T12:29:25.152Z)                                                                                                                                                                         
Server timestamps: received: 1740054565309 (2025-02-20T12:29:25.309Z) delivered: 1740054565310 (2025-02-20T12:29:25.310Z)                                                                                                   
Received a sync message                                                                                                                                                                                                     
                                                                                                                                                                                                                            
Envelope from: xxx yyy-yyy-yyyy (device: 1) to yyy-yyy-yyyy                                                                                                                                                                
Timestamp: 1740054568248 (2025-02-20T12:29:28.248Z)                                                                                                                                                                         
Server timestamps: received: 1740054568410 (2025-02-20T12:29:28.410Z) delivered: 1740054568412 (2025-02-20T12:29:28.412Z)                                                                                                   
Received a sync message                                                                                                                                                                                                     
                                                                                                                                                                                                                            
Envelope from: xxx yyy-yyy-yyyy (device: 4) to yyy-yyy-yyyy                                                                                                                                                                
Timestamp: 1740054570595 (2025-02-20T12:29:30.595Z)                                                                                                                                                                         
Server timestamps: received: 1740054570902 (2025-02-20T12:29:30.902Z) delivered: 1740054570904 (2025-02-20T12:29:30.904Z)                                                                                                   
Received a sync message                                                                                                                                                                                                     
                                                                                                              
Envelope from: xxx yyy-yyy-yyyy (device: 4) to yyy-yyy-yyyy                                                                                                                                                                
Timestamp: 1740054572741 (2025-02-20T12:29:32.741Z)                                                                                                                                                                         
Server timestamps: received: 1740054573050 (2025-02-20T12:29:33.050Z) delivered: 1740054573052 (2025-02-20T12:29:33.052Z)                                                                                                   
Received a sync message                                                                                                                                                                                                     
                                                                                                                                                                                                                            
Envelope from: xxx yyy-yyy-yyyy (device: 4) to yyy-yyy-yyyy                                                                                                                                                                
Timestamp: 1740054575081 (2025-02-20T12:29:35.081Z)                                                                                                                                                                         
Server timestamps: received: 1740054575391 (2025-02-20T12:29:35.391Z) delivered: 1740054575392 (2025-02-20T12:29:35.392Z)                                                                                                   
Received a sync message                 

Looking at the Signal app debug logs, I noticed messages with similar intervals from StorageSyncJob:

02-20 12:20:58.714  6064  6122 I StorageSyncJob: Our version: 445255.1, their version: 445256.2
02-20 12:20:58.714  6064  6122 I StorageSyncJob: [Remote Sync] Newer manifest version found!
02-20 12:20:58.792  6064  6122 I StorageSyncJob: [Remote Sync] Pre-Merge ID Difference :: remoteOnly: 1, localOnly: 0, hasTypeMismatches: false
02-20 12:20:58.792  6064  6122 I StorageSyncJob: [Remote Sync] Retrieving records for key difference.
02-20 12:20:59.917  6064  6122 I StorageSyncJob: [Remote Sync] Remote-Only :: Contacts: 1, GV1: 0, GV2: 0, Account: 0, DLists: 0, call links: 0
02-20 12:20:59.943  6064  6122 I StorageSyncJob: [Remote Sync] Unknowns :: 0 inserts, 0 deletes
02-20 12:20:59.945  6064  6122 I StorageSyncJob: [Remote Sync] Saved new manifest. Now at version: 445256.2
02-20 12:20:59.947  6064  6122 I StorageSyncJob: We are up-to-date with the remote storage state.
02-20 12:20:59.988  6064  6122 I StorageSyncJob: ID Difference :: remoteOnly: 2, localOnly: 1, hasTypeMismatches: false
02-20 12:20:59.988  6064  6122 I StorageSyncJob: We have something to write remotely.
02-20 12:20:59.988  6064  6122 I StorageSyncJob: WriteOperationResult :: ManifestVersion: 445257, Total Keys: 250, Inserts: 1, Deletes: 2
02-20 12:21:00.585  6064  6122 I StorageSyncJob: Saved new manifest. Now at version: 445257.1
02-20 12:21:00.587  6064  6122 D StorageSyncJob: [StorageSync] remote-manifest: 804, remote-id-diff: 84, remote-records: 1124, remote-merge-transaction: 29, local-data-transaction: 43, remote-write: 598, known-unknowns: 1, total: 2682
02-20 12:21:02.803  6064  6121 I StorageSyncJob: Our version: 445257.1, their version: 445258.2
02-20 12:21:02.803  6064  6121 I StorageSyncJob: [Remote Sync] Newer manifest version found!
02-20 12:21:02.850  6064  6121 I StorageSyncJob: [Remote Sync] Pre-Merge ID Difference :: remoteOnly: 1, localOnly: 0, hasTypeMismatches: false
02-20 12:21:02.850  6064  6121 I StorageSyncJob: [Remote Sync] Retrieving records for key difference.
02-20 12:21:03.168  6064  6121 I StorageSyncJob: [Remote Sync] Remote-Only :: Contacts: 1, GV1: 0, GV2: 0, Account: 0, DLists: 0, call links: 0
02-20 12:21:03.178  6064  6121 I StorageSyncJob: [Remote Sync] Unknowns :: 0 inserts, 0 deletes
02-20 12:21:03.179  6064  6121 I StorageSyncJob: [Remote Sync] Saved new manifest. Now at version: 445258.2
02-20 12:21:03.179  6064  6121 I StorageSyncJob: We are up-to-date with the remote storage state.
02-20 12:21:03.219  6064  6121 I StorageSyncJob: ID Difference :: remoteOnly: 2, localOnly: 1, hasTypeMismatches: false
02-20 12:21:03.220  6064  6121 I StorageSyncJob: We have something to write remotely.
02-20 12:21:03.220  6064  6121 I StorageSyncJob: WriteOperationResult :: ManifestVersion: 445259, Total Keys: 250, Inserts: 1, Deletes: 2
02-20 12:21:03.513  6064  6121 I StorageSyncJob: Saved new manifest. Now at version: 445259.1
02-20 12:21:03.515  6064  6121 D StorageSyncJob: [StorageSync] remote-manifest: 288, remote-id-diff: 51, remote-records: 317, remote-merge-transaction: 11, local-data-transaction: 41, remote-write: 295, known-unknowns: 1, total: 1004
02-20 12:21:05.461  6064  6118 I StorageSyncJob: Our version: 445259.1, their version: 445260.2
02-20 12:21:05.461  6064  6118 I StorageSyncJob: [Remote Sync] Newer manifest version found!
02-20 12:21:05.490  6064  6118 I StorageSyncJob: [Remote Sync] Pre-Merge ID Difference :: remoteOnly: 1, localOnly: 0, hasTypeMismatches: false
02-20 12:21:05.490  6064  6118 I StorageSyncJob: [Remote Sync] Retrieving records for key difference.
02-20 12:21:05.846  6064  6118 I StorageSyncJob: [Remote Sync] Remote-Only :: Contacts: 1, GV1: 0, GV2: 0, Account: 0, DLists: 0, call links: 0
02-20 12:21:05.856  6064  6118 I StorageSyncJob: [Remote Sync] Unknowns :: 0 inserts, 0 deletes
02-20 12:21:05.857  6064  6118 I StorageSyncJob: [Remote Sync] Saved new manifest. Now at version: 445260.2
02-20 12:21:05.857  6064  6118 I StorageSyncJob: We are up-to-date with the remote storage state.
02-20 12:21:05.892  6064  6118 I StorageSyncJob: ID Difference :: remoteOnly: 2, localOnly: 1, hasTypeMismatches: false
02-20 12:21:05.892  6064  6118 I StorageSyncJob: We have something to write remotely.
02-20 12:21:05.892  6064  6118 I StorageSyncJob: WriteOperationResult :: ManifestVersion: 445261, Total Keys: 250, Inserts: 1, Deletes: 2
02-20 12:21:06.175  6064  6118 I StorageSyncJob: Saved new manifest. Now at version: 445261.1
02-20 12:21:06.176  6064  6118 D StorageSyncJob: [StorageSync] remote-manifest: 289, remote-id-diff: 30, remote-records: 355, remote-merge-transaction: 12, local-data-transaction: 36, remote-write: 283, known-unknowns: 1, total: 1005

In the periods where I didn't see excessive background battery usage (there were some), these messages did not appear in the app debug log and signal-cli did not print "Received a sync message" messages to stdout (I kept an eye on this because I had to write a small Bash script to filter these from the stdout of signal-cli in order to read other messages).

I then wondered if Signal and Molly were trying to synchronise something with signal-cli, so I updated signal-cli to the latest version from https://github.com/AsamK/signal-cli/wiki/Binary-distributions. Both the Signal app debug log messages about StorageSyncJob and the signal-cli messages are now silent. Was this a bug in signal-cli?

At least in my case, this appears to have fixed the issue and reduced the battery usage to what it was before (it's still the most active app in the battery usage list). Unfortunately all of the debuglogs linked in this issue are returning 404 so I cannot check if they have the same StorageSyncJob messages.