immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-07-25 14:00:45 +03:00
Code Issues 783 Packages Projects Releases 22 Wiki Activity

[PR #789] [MERGED] fix(mobile): run background service after being killed #8762

New Issue
Closed
opened 2026-02-05 13:52:50 +03:00 by OVERLORD · 0 comments
OVERLORD commented 2026-02-05 13:52:50 +03:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/immich-app/immich/pull/789
Author: @fyfrey
Created: 10/6/2022
Status: ✅ Merged
Merged: 10/6/2022
Merged by: @alextran1502

Base: main ← Head: dev/background-service-killed-solution

📝 Commits (1)

  • fba6317 run background service after being killed

📊 Changes

6 files changed (+40 additions, -53 deletions)

View changed files

📝 mobile/android/app/src/main/AndroidManifest.xml (+8 -5)
➖ mobile/android/app/src/main/kotlin/com/example/mobile/AppClearedService.kt (+0 -25)
📝 mobile/android/app/src/main/kotlin/com/example/mobile/BackgroundServicePlugin.kt (+8 -7)
📝 mobile/android/app/src/main/kotlin/com/example/mobile/ContentObserverWorker.kt (+3 -4)
➕ mobile/android/app/src/main/kotlin/com/example/mobile/ImmichApp.kt (+19 -0)
📝 mobile/android/app/src/main/kotlin/com/example/mobile/MainActivity.kt (+2 -12)

📄 Description

Currently, the background backup service does not work well/reliable on devices with low RAM or very strict background process limits (you can easily observe the behavior on your device/emulator if you set "background progress limit" in "developer options" to 1 and open some other app after Immich).
On such devices, the following happens:

The user navigates away from Immich to some other app, the system kills Immich to free resources. The user takes a new picture and expects Immich to perform the backup. However, it does not run the backup because the first trigger only initializes the WorkManager but not our background backup task. If the user takes a second picture (after waiting 5 seconds) , this second trigger would actually start the background backup. But as the system has again killed the Immich process to free resources, the second trigger is actually like the first and only initializes the WorkManager.

This PR solves the above described hell loop by using a custom WorkManager initialization that always runs a backup after initializing. This has the consequence that a background backup is always run when the Immich process is created (triggered by taking a new picture OR simply opening the app after the process was killed). If background backup is disabled, the service is not run. As a bonus, this allows to remove the AppClearedService (which turns out to be a rarely working workaround for the same issue); reducing the number of running/active services.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/immich-app/immich/pull/789 **Author:** [@fyfrey](https://github.com/fyfrey) **Created:** 10/6/2022 **Status:** ✅ Merged **Merged:** 10/6/2022 **Merged by:** [@alextran1502](https://github.com/alextran1502) **Base:** `main` ← **Head:** `dev/background-service-killed-solution` --- ### 📝 Commits (1) - [`fba6317`](https://github.com/immich-app/immich/commit/fba63171ed100cc7db5d4f6d54806fbfb3c8e958) run background service after being killed ### 📊 Changes **6 files changed** (+40 additions, -53 deletions) <details> <summary>View changed files</summary> 📝 `mobile/android/app/src/main/AndroidManifest.xml` (+8 -5) ➖ `mobile/android/app/src/main/kotlin/com/example/mobile/AppClearedService.kt` (+0 -25) 📝 `mobile/android/app/src/main/kotlin/com/example/mobile/BackgroundServicePlugin.kt` (+8 -7) 📝 `mobile/android/app/src/main/kotlin/com/example/mobile/ContentObserverWorker.kt` (+3 -4) ➕ `mobile/android/app/src/main/kotlin/com/example/mobile/ImmichApp.kt` (+19 -0) 📝 `mobile/android/app/src/main/kotlin/com/example/mobile/MainActivity.kt` (+2 -12) </details> ### 📄 Description Currently, the background backup service does not work well/reliable on devices with low RAM or very strict background process limits (you can easily observe the behavior on your device/emulator if you set "background progress limit" in "developer options" to 1 and open some other app after Immich). On such devices, the following happens: > The user navigates away from Immich to some other app, the system kills Immich to free resources. The user takes a new picture and expects Immich to perform the backup. However, it does not run the backup because the first trigger only initializes the WorkManager but not our background backup task. If the user takes a second picture (after waiting 5 seconds) , this second trigger would actually start the background backup. But as the system has again killed the Immich process to free resources, the second trigger is actually like the first and only initializes the WorkManager. This PR solves the above described hell loop by using a custom WorkManager initialization that always runs a backup after initializing. This has the consequence that a background backup is always run when the Immich process is created (triggered by taking a new picture OR simply opening the app after the process was killed). If background backup is disabled, the service is not run. As a bonus, this allows to remove the `AppClearedService` (which turns out to be a rarely working workaround for the same issue); reducing the number of running/active services. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
OVERLORD added the pull-request label 2026-02-05 13:52:50 +03:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:skip
changelog:translation
cli
date-time
dependencies
documentation
external-library
format
good first issue
mobile-beta
mobile-beta
mobile-beta
needs-answer
nice to have
pull-request
Mirrored from GitHub Pull Request
 sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#8762
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?