TonfotosSync Automatic backup problem

Jurek

I have successfully backed up all the photos on my phone, and I have enabled Automatic Backup (Only when connected to WiFi) to ensure that all future photos I take will be backed up. I tested this by taking a couple of photos. They were shown correctly on the “Photos to backup” screen, but were NOT uploaded to my PC, no matter how long I waited. When I manually triggered the backup by clicking Start Backup, they were successfully uploaded. I’ve tried this several times, and have un-paired the phone app and the PC app, then started afresh - but nothing I’ve tried will get Automatic Backup to work. There aren’t any error messages, it’s just that nothing happens unless I manually start the backup.

Andrey

Jurek can you please clarify, what phone you are using? Is it iPhone? What OS version?

During our testing we alse had issues with background tasks on iOS. It works as expected on Android, but the same code just refuses to work on iPhone. iOS just refuses to call background task. This is known issue and we are workin on it, but we are kind of in the dead end here. We do everything as documented, but it just does not work.

Jurek

Hello Andrey. I’m using a Google Pixel Android phone (Android version 16).

Andrey

Jurek That is strange. We did test on few phones, and on Android it seemed to work OK. However, in any case it is Android who decides when your background task will be run, we don’t have control over that. Please make sure your phone is on charger, connected to Wi-Fi, and Tonfotos is started, and give it a time (few hours). Only this way you can be sure if it works or not.

Jurek

I have spent a lot of time over the weekend trying to fix the problem, or at least to find clues to what is going wrong, but without success. I was a software engineer for most of my life before my retirement (though unfortunately I know nothing about Android apps!) so I do understand the difficulty of addressing problems that you are unable to replicate, and especially when there are so many versions of the Android operating system still in use on many different phone brands. I did a lot of reading about the subject and tried lots of possible fixes - starting with simple things such as ensuring that the phone was on charge, Wi-Fi was on, the sync app and the Tonfotos program on the PC were both running, un-installing and re-installing both programs. I then progressed to many system changes on the phone, such as ensuring that the power saving modes weren’t stopping the sync app when it was in the background (and many other power-related and hibernation-related settings), playing around with app permissions, checking that background data usage was unrestricted, and lots of other changes - so many that I can’t remember them all! Sadly, none of these changes made any difference. The only bit of information I found that might be useful is that there was a big change in Android 16, with the introduction of “much stricter runtime quotas and job execution rules for background tasks on API 36+” ( That doesn’t mean much to me, but you will probably understand it!). A related bit of info was that many other apps had run into trouble when trying to run on Android 16 because of these changes, and that there was some talk of updates to Android 16 to address these issues. Anyway, if you at some point have the resources to investigate the problem, then I would be willing to help in any way I can, as I can replicate the problem so easily on my phone! 😀 . Thanks again for your help.

Andrey

Jurek Thank you for sharing this all!

Sure you went much further than I ever could since I just don’t have access to your phone and cannot try everything you tried. However, if I had, I would do exactly what you did. And since you did not succeed, I don’t actually think I would.

The thing is that the only my advantage to you is that I have source codes of the application and can do some tweaks there. And in many cases this is decisive factor, but not here unfortunatley. There is barely any setting to tweak, we just call OS API and pray it would listen. On iPhones it does not, and no one knows why. On our testing Android phones it works. But those are definitely not hottest and freshest ones. Actually, those were bought used on aftermarket, for obvious reasons. Your probably is new and you are facing new restrictions everyone else will be facing soon.

I am afraid there not much we can do on the app level if OS just prohibts something.

Jurek

Hi Andrey, I’m not going to keep on bothering you about this, but I thought you might be interested in this bit of information:
The information comes from official Android Developer documentation and developer community insights regarding Android 16 (codenamed “Baklava”) and its stricter background task management.
Here are the specific sources and data points:

New “User-Initiated Data Transfer” Jobs
Android 16 introduces a specific job type that is exempt from ordinary job quotas if it is triggered by a user action. This is the “fix” for apps that fail to start a sync automatically after a file is detected.
Source: Android Developers - User-initiated data transfer
Key Detail: Developers must now declare the RUN_USER_INITIATED_JOBS permission in their app’s manifest to ensure these tasks are not killed by the system.
JobScheduler Quota Enforcements
Starting in Android 16, the system more strictly enforces “runtime quotas” even for apps in an “active” standby bucket. Source: Android Developers - Behavior changes: all apps (Android 16)
Key Detail: Jobs started while an app is visible (top state) but continue after it becomes invisible are now strictly bound by these new quotas.
“Expedited Jobs” and Deferral
Older apps often request “standard” background windows, which Android 16 now “defers” or delays to save battery. The setExpedited(true) flag is required to tell the OS that a task (like a photo sync) should run as soon as possible rather than waiting for a “convenient” system window.
Source: Android Developers - Support for long-running workers
Key Detail: On Android 16, even long-running workers using foreground services can now exhaust an app’s job quota, requiring developers to use the newer user-initiated data transfer jobs for reliability.
Background Task Debugging
Android 16 added a new way for developers to see exactly why a job is stuck.
Source: Android Developers - Better job introspection
Key Detail: Developers can use JobScheduler#getPendingJobReasons to find the specific “implicit constraints” (system rules) that are blocking the automatic sync.

Well that’s it for now, Andrey. I’ll just trigger the sync manually, it’s not exactly a hardship! 😀
Thanks for you help and patience - I’m very surprised that you have the time to answer posts on this forum AND do any development work on the app! It’s a great app, by the way!

Andrey

Jurek Thank you! Yes, I read those, obviously. Not all of that is 100% related to our case, as we are not deferring job, we are starting new one after some period of inactivity.

I guess I now have to be prepared to spend more time on constant updates since mobile world is much more dynamic than desktop, where revolutions are extremely rare. But here, even though application is just released, both stores warn me that I should update app immediately to new SDK version or they will not accept updates…

In any case, background sync is imprtant part of the app and I will continue researching this space. Actually I have some new ideas to try that would work arround this function, but that all requires experimenting.