Signal-android: Signal is killed for using excessive CPU during backup (when phone is sleeping and not charging)

[Natanji]

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

---

Bug description

I tried doing the new Signal Backup for the first time, but it wasn't working properly. After leaving my phone for a while and coming back, I tried to verify that the backup was finished but noticed that Signal was asking me for my password (showing that the app had been closed/killed). It was also showing the last backup date as "Never".

I could successfully do a backup while the phone is charging and I keep the screen on. I investigated adb logcat and can confirm that Signal is killed for excessive CPU usage.

Steps to reproduce

• Start the Signal Backup (doesn't matter if it is the initial backup process or you just press on "Create Backup" again)
• Unplug the phone from the power source (mine was sitting at around 69% battery at the time)
• Turn off the screen and wait for 15-20 minutes

Actual result: The Signal app is killed for using excessive CPU resources, which also kills the backup process. Upon entering Signal a user-defined unlock password needs to be entered again. A user might think the backup is finished (since the notification disappeared) but it isn't: when going to the Backups part of the settings, the "Last backup" will still say "Never" (or whatever the last successful backup date was).
Expected result: The Signal backup keeps running and backs up Signal.

Device info

Device: Oneplus 3
Android version: 8.0.0
Signal version: 4.17.5

Link to debug log

Debug log from within Signal isn't available because the app is killed/crashes and the log from within signal will only show the current run's log. adb logcat clearly shows that Signal is getting killed and afterwards its services get restarted:

04-03 15:13:25.496  7628  7684 I OHPD    : [BgDetect]detect excessive cpu on process org.thoughtcrime.securesms(pid : 6243) level 3 usage 41
04-03 15:13:27.474  7628  7684 I ActivityManager: Killing 6243:org.thoughtcrime.securesms/u0a195 (adj 200): [BgDetect] kill org.thoughtcrime.securesms (uid 10195) level 3
...
04-03 15:13:27.613  7628  9575 I WindowManager: WIN DEATH: Window{c62f05c u0 org.thoughtcrime.securesms/org.thoughtcrime.securesms.ApplicationPreferencesActivity}
04-03 15:13:27.620  7628 22261 I WindowManager: WIN DEATH: Window{d9c8f05 u0 org.thoughtcrime.securesms/org.thoughtcrime.securesms.RoutingActivity}
...
04-03 15:13:27.644  7628  7661 D ActivityManager: Process org.thoughtcrime.securesms has 3 services
04-03 15:13:27.645  7628  7661 W ActivityManager: Scheduling restart of crashed service org.thoughtcrime.securesms/.service.KeyCachingService in 10840ms
04-03 15:13:27.645  7628  7661 W ActivityManager: Scheduling restart of crashed service org.thoughtcrime.securesms/.service.MessageRetrievalService in 10839ms
04-03 15:13:27.645  7628  7661 W ActivityManager: Scheduling restart of crashed service org.thoughtcrime.securesms/.service.GenericForegroundService in 20839ms

(Backup was started at around 15:00)

[moxie0]

Are you running a custom ROM? I'm not sure there's anything I can do if Android is killing the process.

[Natanji]

No, I'm running stock OxygenOS - the most updated non-beta version available for the Oneplus 3.

From googling "BgDetect", this seems to indeed be a Oneplus-specific quirk. (Now that I think about it, I had similar problems in the past when doing other background-heavy tasks like backing up a large up with TitaniumBackup, and TB getting killed). Apparently running a custom ROM would actually fix this issue. Oh my.

How could one alleviate this problem? My idea would be to delay any backup task until power is connected to the phone, if the device is running OxygenOS or if Signal notices that it has been forcefully killed during the backup. I understand that this is just a somewhat ugly workaround, but the install base of OnePlus is quite large I think which maybe warrants this - otherwise, OnePlus users won't get regular backups on their phones and potentially lose a lot of data.

(Quick question, when a backup is already finished and a new backup is started: is the backup immediately overwritten and thus killing the process also corrupts the past backup - or is the backup done in a different place and only replaces the old backup once the new one successfully finished?)

EDIT: Oneplus definitely thinks they're fine killing foreground apps and don't feel in the wrong and won't patch this.

[moxie0]

How do I know if a device is OxygenOS and not Android?

[Natanji]

SystemProperties.get("ro.build.ota.versionname") should return a string containing "Oxygen" (for me it is "OnePlus3Oxygen_16_1712272249"). This goes for the Oneplus 5 as well as you can see in their build.prop: example.

[utoxxer]

I can confirm this bug. My phone is running LineageOS. I am unable to create a backup because Signal freezes up and android pops up a message telling me Signal is no longer responding.

[Natanji]

That's curious, which phone do you have? LineageOS shouldn't have this "BgDetect" service. I'd say that is a different bug.

[tribut]

Does it make sense to only start the backup while charging? Maybe "unless the last backup is older than N days"?

[eighthave]

I think _JobIntentService_ is meant for situations just like this. I just converted a bunch of _IntentServices_ in F-Droid to deal with similar issues. Seems like the services in question here are not _IntentServices_, so they would be non-trivial to convert. In my experience, converting an _IntentService_ to a _JobIntentService_ was quick and painless.

[greyson-signal]

We're using WorkManager now to schedule all of our jobs, which on newer versions of Android is backed by JobScheduler. Through a combination of both running our task during system-sanctioned periods and using a foreground service, I don't think there's anything more we can do.