8T OOS13 (F13) Force closed apps don't stay closed

Search This thread

rufik

Senior Member
Jan 18, 2010
334
84
Łódź
On OOS 11 and 12 when I force close any app, it stays closed all the time. I have one or two apps that I don't need to run all the time, just from time to time, so I force them close usually.
But now I'm on OOS 13 and when I force close app it's re-run after some time. It looks like android "revives" app. And this app has unchecked "backgroud activity" and "auto lunch" of course.
Is this a new "feature" of android 13? Or OOS maybe?
 

evilhawk00

Senior Member
Feb 22, 2014
140
136
Taipei
play.google.com
OnePlus 8T
The new "feature" you've said is actually "something normal all the time" form Android 4.0 +. This is something you can have on AOSP. What you want is actually something "dirty" made by the device manufacturer, which is a nightmare for Android developers. Those manufacturers don't follow the Android standard and prevent the software to be triggered under some circumstances, this breaks the functionality of the app.

For example, using the Android WorkManager can register a worker with a scheduled task. Developers can assign the task to be executed at a specific time or every a period of time. The WorkManager is a wrapper for Jobscheduler and AlarmManager. Depending on the Android OS version, the WorkManager automatically choose to use one of the above methods to run the scheduled task. If an app registers a PeriodicWorkRequest and assign it to execute every 2 hours, even the app is closed, the PeriodicWorkRequest still can be triggered and revives the app every 2 hours. The nightmare for developers is that OPPO, Xiaomi...etc, these manufacturers prevent the scheduled tasks to be executed if the app is closed(Hall of shame). They are not following the Android standard, so apps can not behave as expected. It is totally different from the documentation at developer.android.com, but every manufacturer is doing this under the excuse of battery optimization, so many users think this is normal. However this is actually some nasty customization to the OS made by the manufacturer to break many apps on the device. That's why apps with background services, such as, Tasker, Bitwarden can not work correctly on many devices if they're not excluded in battery optimization management apps made by the manufacturer.

Almost every Android developer has to tell users to visit https://dontkillmyapp.com/, because Chinese manufacturers like to kill app services and break all the apps with background services. And finally now Google is introducing CTS-D, to tell devs about how background services work on the device. I guess this is why things are finally moving back to normal in Android 13.

#The page https://dontkillmyapp.com/ is a website made by developers to teach users to whitelist apps after receiving a lot of complaints about apps not working correctly. Thanks to those manufactures created this mess.​
 
Last edited:

Rootk1t

Senior Member
Jun 2, 2013
1,868
784
The new "feature" you've said is actually "something normal all the time" form Android 4.0 +. This is something you can have on AOSP. What you want is actually something "dirty" made by the device manufacturer, which is a nightmare for Android developers. Those manufacturers don't follow the Android standard and prevent the software to be triggered under some circumstances, this breaks the functionality of the app.

For example, using the Android WorkManager can register a worker with a scheduled task. Developers can assign the task to be executed at a specific time or every a period of time. The WorkManager is a wrapper for Jobscheduler and AlarmManager. Depending on the Android OS version, the WorkManager automatically choose to use one of the above methods to run the scheduled task. If an app registers a PeriodicWorkRequest and assign it to execute every 2 hours, even the app is closed, the PeriodicWorkRequest still can be triggered and revives the app every 2 hours. The nightmare for developers is that OPPO, Xiaomi...etc, these manufacturers prevent the scheduled tasks to be executed if the app is closed(Hall of shame). They are not following the Android standard, so apps can not behave as expected. It is totally different from the documentation at developer.android.com, but every manufacturer is doing this under the excuse of battery optimization, so many users think this is normal. However this is actually some nasty customization to the OS made by the manufacturer to break many apps on the device. That's why apps with background services, such as, Tasker, Bitwarden can not work correctly on many devices if they're not excluded in battery optimization management apps made by the manufacturer.

Almost every Android developer has to tell users to visit https://dontkillmyapp.com/, because Chinese manufacturers like to kill app services and break all the apps with background services. And finally now Google is introducing CTS-D, to tell devs about how background services work on the device. I guess this is why things are finally moving back to normal in Android 13.

#The page https://dontkillmyapp.com/ is a website made by developers to teach users to whitelist apps after receiving a lot of complaints about apps not working correctly. Thanks to those manufactures created this mess.​
I think the point rufik made is the opposite. It's not about android autokilling app.
Instead when he force closes the app, it starts again.
 

evilhawk00

Senior Member
Feb 22, 2014
140
136
Taipei
play.google.com
OnePlus 8T
I think the point rufik made is the opposite. It's not about android autokilling app.
Instead when he force closes the app, it starts again.
No, you don't understand my point. I'm talking about this under the view of an app developer. I mean auto killing app also has a feature that prevents Jobscheduler to be called.

What I meant:
Due to no app auto killing => system not preventing Jobscheduler to be executed after app force close => Jobscheduler executed after force close app(Jobscheduler task was created before force close app, and Jobscheduler is not the part of app, so it is not forced closed, it still execute, it should be cancelled by the app itself) => Jobscheduler task call codes from the app => the app starts itself.

More info : https://stackoverflow.com/a/63226260

With Jobscheduler, you can make a app to restart itself after forced close on AOSP. But this trick never works on manufacturer customized Roms with app auto killing feature.
 
Last edited: