Add setting for users to determine frequency of backup creation

[farewelltospring]

First time contributor checklist

• I have read how to contribute to this project
• I have signed the Contributor License Agreement

Contributor checklist

• I am following the Code Style Guidelines
• I have tested my contribution on these devices:

• Sony Xperia 5iii, Android 13
• Virtual device Pixel 3, Android 13

• My contribution is fully baked and ready to be merged as is
• I ensure that all the open issues my contribution fixes are mentioned in the commit message of my first commit using the Fixes #1234 syntax

---

Description

This pull request allows users change the frequency that backups are made to a selected interval (weekly, monthly, quarterly, every 6 months, annually).

Currently, when backups are enabled, Signal will create a fresh backup every 24-hours. This causes unnecessary write cycles on the device's internal storage or SD card.

• Making backups is a power-intensive process which drains battery and uses CPU cycles which can put a strain on daily usage when users are out and about, and slow down other apps on the device while the backups are being created.
• Different users have different needs from backups. Some users message on Signal all day long, and others message on Signal infrequently. A 24-hour backup schedule is useful for the first group, but is of dubious value for the second group. It will write an identical file over and over.
• Low-end devices are wearing out prematurely. Many low-end Android phones have low-durability eMMC chips. A 24-hour backup schedule makes their already-short lifespan even shorter. eMMC chips will fail catastrophically when they reach end-of-life. The device bricks, and the user must replace the whole thing. This disproportionately hurts Signal's poor users and produces environmental pollution.

A setting to control the backup frequency would also give people more control over their data, which is an important value to cultivate in today's society.

Verified that this behaviour works by setting backup frequency to 30 days and then waiting that long to see if a backup got created (I restarted the device several times during that time period to verify that it persists).

Screen_recording_20240111_000341.mp4

[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.

[farewelltospring]

Fixed the localisation issue. I have only added a string for English but at least there are resources now.

[farewelltospring]

Is there anything I can do to make this PR better?

[farewelltospring]

Added a video recording demonstrating the feature. (link)

[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.

[tkrah]

Found this PR as this is the feature I really miss - what needs to be done to get this merged? This 49ba83d is not be able to replace this PR because it is meant to be used in the upcoming remote chat backup - if you WANT a local backup, we still need this PR.

[greyson-signal]

I'm interested in the feature in general, but I think the UX would be different. Rather than time and frequency sharing a settings row, we'd leave the time row alone, then make a new frequence row with the options "daily, weekly, monthly, manual".

[farewelltospring]

By "manual" you mean backups will only be created when the user presses the create button? I can get behind that.

[farewelltospring]

Ok I uploaded some code. Full disclosure I haven't tested it yet because I gotta head out now and it'll take too long to compile, but I'll test it and take a video when I get back.

[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.

[farewelltospring]

Demo recording attached.

Screen_recording_20250428_015236.mp4

[farewelltospring]

Played around with it a little and I think found an edge case where if you change the frequency from a schedule to NEVER, then the original scheduled backup never gets canceled. So it'll create one more backup according to the previous frequency, and then stop afterwards. Do you think this is acceptable behaviour?

FWIW, I tried to dig into the code to figure out how to avoid this. There's a lot of abstraction and general cruft in the job management system (whose files are also not very well documented) and I can't immediately see a clean way to cancel a scheduled backup. Could you give me a code pointer to cancel a scheduled job? Or I can dig deeper myself at the cost of more time. Having said that, doesn't seem to persist across reboots, so there's that.

Curiously, one thing that does persist across reboots is in-progress backups. This seems to be a built-in feature to the JobRunner/JobDatabase/etc files, because logcat shows that it only tracks when the job was submitted and doesn't seem to respect the backup frequency setting when I switch it to NEVER.

IMO a good UX would be for switching the frequency setting to NEVER to:

1. Cancel future scheduled backups without relying on the user to reboot to clear it out
2. Cancel in-progress backups

If that additional change is not needed then we can review the code more or less as-is (which I'm fine with as well). Please let me know how you would like to move this PR forward.

[farewelltospring]

Come through

[alex-signal]

Cancellation methods are on JobManager, which you can access via AppDependencies.getJobManager()

[gabefair]

Thank you for all the updates to make this feature possible

[farewelltospring]

I've been daily driving this for the past month and the new "never" setting has been working as expected.

• Setting backup frequency to NEVER cancels a scheduled job without a need for reboot, confirmed by having a latest backup from April, setting the frequency to DAILY, and then setting it to NEVER, and confirming that a backup never begins getting created. ☑️
• Setting backup frequency to NEVERcancels an in-progress job, confirmed by checking logcat for W LocalBackupJobApi29: Backup cancelled. ☑️

If there are no other comments, I believe that this PR is ready to be reviewed for full merge.

[farewelltospring]

🙂