[FIX] Image autoupload uploads images twice under certain conditions

[JuancaG05]

Related Issues

App: #3983

• Add changelog files for the fixed issues in folder changelog/unreleased. More info here
• Add feature to Release Notes in ReleaseNotesViewModel.kt creating a new ReleaseNote() with String resources (if required)

---

QA

• (1) Camera folder not selected [FIX] Image autoupload uploads images twice under certain conditions #4571 (comment) [FIXED]
• (2) Multiaccount [FIX] Image autoupload uploads images twice under certain conditions #4571 (comment) [FIXED]

[joragua]

LGTM! Good job @JuancaG05 💯 Let's see if it works.

NOTE: Don't forget to add calens file and release note if this PR is going to be merged into master branch.

[jesmrec]

(1) [FIXED]

1. Install the app from scratch
2. Add an account
3. Enable auto uploads for pictures
4. Choose the Camera folder (required) and submit

Current:

No folder is chosen, therefore no pictures are uploaded

Expected:

Folder chosen is set as subtitle and uploads work

Pixel 7
Xiaomi Redmi 13
Samsung A8
87e6bcec0

[jesmrec]

(2) [FIXED]

1. Add two accounts to the device
2. Enable Automatic Picture uploads
3. Select one of them as Account to upload pictures and an upload path
4. Then, click on Account to upload pictures and select the other account
5. Click on Picture upload path

Current:

The list of spaces is the one of the first account (the one selected in step 3.)

Expected:

The list of spaces is the one of the second account (the one selected in step 4.)

Pixel 7
Xiaomi Redmi 13
Samsung A8
87e6bcec0

[JuancaG05]

@jesmrec (1) and (2) should be fixed now

[jesmrec]

(3)

After some tests, i got some duplications... this is the log if it helps somehow:

owncloud.2025-04-16_08.41.04.log

Samsung A8

[JuancaG05]

@jesmrec regarding (3), those duplicates seen in logs refer to 0B files... let's see at least if worker flow is correct now (timestamp taken is correct, as seen in those logs) and maybe we can address the 0B problem in a separate issue

[joragua]

Some conclusions:

• We added more verbosity to the AutomaticUploadsWorker to see the point at which it stops. After adding the logs, we noticed that those placed after the filter (where the files to be uploaded are chosen) don’t appear in the logs file. In my opinion, the problem is related to the way Android manages workers (not directly related to the code). After testing on a specific device (Google Pixel 7), we have seen that the system launches a new worker before the previous one has finished and, consequently, the timestamp is updated every time. That is the reason why the files are not uploaded correctly. In any case, if we keep the previous code (update the timestamp after the worker has finished) we will have duplicated files because there are workers running at the same time with the same files, so... 🫠

• We changed the existing periodic work policy from KEEP to a new policy (UPDATE) but the behavior is the same.

NOTE: In my device (Samsung Galaxy A51), automatic uploads are working well and I don't have duplicated files.

[jesmrec]

Logs over all the tests done are available, just in case

[apollo13]

@joragua Did the logging improvements already make it into a playstore release? I have the problems that nothing get's uploaded (well with a two days delay or so…) and I'd love to look at the logs with more information.

[JuancaG05]

Hi @apollo13! No, unfortunately the verbosity added to logs is not in Play Store, and there are no plans to upload it since it's just some internal testing. But since you are interested on it, I'll provide an APK with the new verbosity.

You can download it here: https://infinite.owncloud.com/s/OeffTWmcFNXtmxi (password: $xP$r58W-,PB)

We would be thankful if you tell us if there is any new finding from your side! 🍻

[apollo13]

@JuancaG05
owncloud_log_sanitized.txt
I have attached a logfile from today where I added comments when I took photos etc… What stands out is that there seems to be many AutomaticUploadsWorker operating somewhat in parallel and that they don't execute continuously given log lines like these:

I: 2025-05-16 10:34:21:079(AutomaticUploadsWorker.kt:136)Timestamp updated correctly. Current timestamp: Fri May 16 10:34:21 GMT+02:00 2025
I: 2025-05-16 10:40:59:975(AutomaticUploadsWorker.kt:269)CurrentTimestamp Fri May 16 10:34:21 GMT+02:00 2025 

Looking at the code, it is not clear to me where the worker could sleep between those timestamps. My owncloud is empty since I am currently evaluating it, there is no way it takes 6 minutes to go from updating the timestamp to redisplaying it in getFilesReadyToUpload

I hope this helps, I am running a Pixel 6a with the latest Android. Happy to chat on matrix or whatever if you prefer realtime comms at some point.

[apollo13]

And at 13:30 still no uploads, the last try was:

I: 2025-05-16 12:13:40:060(AutomaticUploadsWorker.kt:78)Starting AutomaticUploadsWorker with UUID c9f87e48-a622-450e-89d0-077cff8721b8
I: 2025-05-16 12:13:40:144(AutomaticUploadsWorker.kt:136)Timestamp updated correctly. Current timestamp: Fri May 16 12:13:40 GMT+02:00 2025
I: 2025-05-16 12:13:40:152(AutomaticUploadsWorker.kt:252)Source uri is: content://com.android.externalstorage.documents/tree/primary%3ADCIM%2FCamera
I: 2025-05-16 12:13:40:159(AutomaticUploadsWorker.kt:256)Document tree is: androidx.documentfile.provider.TreeDocumentFile@237360a
I: 2025-05-16 12:13:40:218(AvailableOfflinePeriodicWorker.kt:48)Available offline files that needs to be synced: 0
I: 2025-05-16 12:13:48:041(AutomaticUploadsWorker.kt:260)The search of local files has finished. Now, all files are going to be filtered

Given that the next logline should be "Last Sync", this code appears to hang in

android/owncloudApp/src/main/java/com/owncloud/android/workers/AutomaticUploadsWorker.kt

Line 262 in b20a9f3

val filteredList: List<DocumentFile> = arrayOfLocalFiles

or it got killed

[apollo13]

@jesmrec As mentioned two comments up, it is a Pixel 6a running latest Android (15). Anything more specific you are looking for?

[jesmrec]

@apollo13 i have the same behaviour with Pixel 7, just to know whether the device has something to do. Because with other brands, it's working fine.

[jesmrec]

You can reach us in https://talk.owncloud.com/channel/mobile

[apollo13]

Looking at some "debugging" options I think it would be a good idea to implement onStopped in the worker (https://developer.android.com/reference/kotlin/androidx/work/ListenableWorker#onStopped()) and call getStopReason there (https://developer.android.com/reference/kotlin/androidx/work/ListenableWorker#getStopReason()) to see when a worked stops.

I'll try to get some further information via https://developer.android.com/develop/background-work/background-tasks/testing/persistent/debug

[JuancaG05]

Hi @apollo13! Thanks for your ideas!

Seems that since we're using CoroutineWorker, the method onStopped is final there (https://developer.android.com/reference/kotlin/androidx/work/CoroutineWorker#onStopped()), so we cannot override it. In any case, I added in the worker a new try - catch block to catch the CancellationException, which should be triggered in case the worker is cancelled. When this exception is caught, a new log is printed, but to see the real stop reason (method getStopReason), a device with at least API 31 (Android 12) should be used. This stop reason will be printed as a numerical constant, which needs to be checked together with the constants listed in https://developer.android.com/reference/android/app/job/JobParameters.html#constants_1.

Let's try this for the moment, and if we don't get further information, we can try the custom initialization mentioned in https://developer.android.com/develop/background-work/background-tasks/testing/persistent/debug#enable-logging, which will add much more verbosity to the current logs.

The new APK can be downloaded here: https://infinite.owncloud.com/s/cXkqstdShbaMevX (Password: Fja_'O188N,c)

Tell us if you have any new finding, and thanks a lot for your collaboration! 🤜 🤛