Hello everyone, I am the developer of the BackgroundWorkAround app and the BackgroundWorkAroundLib library. They are created to demonstrate and use the most aggressive ways of maintaining and restoring operation for background services on Android using standard APIs. The question is, does their use comply with F-Droid rules? Can apps using this (BackgroundWorkAroundLib) library be published on F-Droid? And what about the BackgroundWorkAround app itself, or is it too useless, since it is just a demonstration?
What exactly does it do? I had a look at the repo and it looks like maybe it’ll just test run in the background? That could be cool. Kinda like DontKillMyApps?
Not just tests. Rather, it is an attempt to survive in the background by non-standard methods and to check how effective they are. That same DontKillMyApp is just tests within the framework of ordinary services and permissions of the type Ignore Battery Optimization, whereas mine is more a practice of non-standard methods of survival and restart, not requiring the request of permissions from the user (except perhaps notifications, and even then, as a rule, foreground services can be launched even without them, they will simply be visible only in a special shade and have not such a high priority). The only problem is Android 12, since there was not yet USE_EXACT_ALARM there, and was SCHEDULE, but fortunately this is only a part of my survival mechanisms and little influences result.
But the app itself is a testing app. Its primary function is to test and log the results of its attempts at survival?
If so maybe id suggest adding a database? Collect what works on what devices? This sort of data would be incredibly handy to FOSS apps trying to survive in the background. I believe at the very least this needs looked at by a good few projects that are failing to stay open
It does not record the results of survival attempts, but simply demonstrates them to the user by playing a sound while it is alive, and also showing running processes when the application is opened.
Maybe someday I’ll add a record to the database, but for now it’s a personal testing tool. Conducting performance analysis is more difficult than simply showing the results to the user. For example, we need to know the time an application died and how quickly it restarted. But this is easiest for the user to see. For the system, constantly recording time is a burden.
The funny thing here is that the app is effective on most devices with default settings. So, under normal circumstances, tracking device statistics is pointless. In other cases, the user himself creates the load, and then it is easier for him to detect the fall. For example, a user can intentionally trigger a RAM overflow or change the reboot settings on Xiaomi from the default to the most hostile and then see what happens after the RAM overflow and reboot.
If we’re talking about testing individual survival techniques, this app isn’t for that; it tests them together. Maybe someday I’ll create a special mode or app for testing them individually. But individually, they’re not as effective, meaning we lose the full picture. For example, Set Exact Alarm doesn’t work without Wake Lock because the phone enters Doze.
That is clear But the same DontKillMyApp and DroidStress are on F-Droid. My task is different. My mechanisms (in BackgroundWorkAround) are slightly different. I want to understand if it is possible to use such mechanisms in F-Droid, and therefore whether I can add such a library to my applications. For example, what about goAsync() + Thread.sleep(Long.MAX_VALUE) inside a receiver? And 10 wake locks for 3 seconds in a while true loop with a timeout of 0.33s? And what about sending a Broadcast to a static receiver every 7.5s and separating components into different processes? And is it allowed to perform mutual bind of services of one application in 2 different processes? And is it allowed to reset alarm every 30s? Therefore, I want to find out by trying to publish the BackgroundWorkAround applications on F-Droid.
On AOSP, there’s no need for such tricks, of course, but on MIUI, for example, it can be necessary.
But the same DontKillMyApp and DroidStress are on F-Droid. My task is different. My mechanisms (in BackgroundWorkAround) are slightly different. I want to understand if it is possible to use such mechanisms in F-Droid, and therefore whether I can add such a library to my applications. For example, what about goAsync() + Thread.sleep(Long.MAX_VALUE) inside a receiver? And 10 wake locks for 3 seconds in a while true loop with a timeout of 0.33s? And what about sending a Broadcast to a static receiver every 7.5s and separating components into different processes? And is it allowed to perform mutual bind of services of one application in 2 different processes? And is it allowed to reset alarm every 30s? Therefore, I want to find out by trying to publish the BackgroundWorkAround applications on F-Droid.