NeoApplications
[Bug] Force stop not working always
Description I restored a few apps yesterday and noticed that force stop isn't working always. For instance it works for JuiceSSH as long as it's not in a session. When it is, it won't be killed.
That also caused some issues with the restorations because apps were still running while being restored.
Steps To Reproduce
- ...
- ...
- ...
- Crash, Nothing happens ....
Expected behavior
App should be killed. Maybe switch to am kill or am force-stop as root to ensure that.
Screenshots Only if there's no clear logs, add screenshots to help explain your problem.
System Information(please complete the following information):
- Device:
- Android Version: 13
- ROM: LineageOS
- App's Version: 8.2
Additional Notes
-
If you're on the latest Test version(from the TG-Channel or Matrix-Room) please report there directly, not here.
-
If you're on the latest github version:
- Please read the FAQ first.
- Please read all the open Issues. If one does match yours, leave a comment there if there's some extra information you can provide.
-
If you're not on the latest github version. Update, then make sure that the bug is still there. If it's go further with reporting.
Thanks for reporting.
I also noticed that force stop didn't always work too on my Android 10 stock Pixel 4a (rooted)
https://developer.android.com/reference/android/app/ActivityManager#killBackgroundProcesses(java.lang.String)
Not much explanation there but maybe it's really only killing background processes and won't do anything it the app is running a foreground service or other foreground work. Either way, interfacing with am directly as root should kill everything.
First: NB does not kill processes, they are paused.
Killing them (in any way) has several disadvantages:
- some apps will not restart and services are not working after that (something like messengers not receiving messages)
- some apps will restart automatically, those will work much more while the backup runs and files will be changed, causing inconsistent backups (and tar complaining -> errors)
- wallpapers and similar may be reset to defaults
- some more effects I don't remember any more
The killing you think of, is probably when installing apps (as part of the restore).
This is a functionality of the system (PackageManager, pm install etc.). Maybe, when trying to install an app, it is able to prevent this.
It seems to be reasonable, when it prevents killing an active ssh session. Why do you want to be thrown out of the connection? Why are you running a connection while restoring that app? I really don't get it.
Your reasoning seems to be "do what I feel is the right thing just now", sometimes you want this, but sometimes you want that. NB (or in this case the system) should guess what your feelings are. If the connection is important to you at that moment, you would probably complain, if you were kicked out.
Think more like "NB or the system should always do this" or give exact conditions (for all possible cases), when it should not.
Maybe, I didn't understand the thoughts that are hidden behind
That also caused some issues with the restorations because apps were still running while being restored
but you didn't describe it
I will only try to click "Force Kill" when I try to do a backup and it gave an error.
Now, when I get an error when trying to do a backup, I typically have to do a "Force Stop" from the app's actual android info screen in order to be able to do that backup without an error.
I was expecting the "Force Kill" would be doing the same as Android's "Force Stop" so that I wouldn't have to navigate out of the NB app to do the force stop, but apparently it doesn't.
So if NB automatically does a "Pause" already before doing a backup, why have a "Force Kill" button that does the same thing?
I would think that the whole purpose of the "Force Kill" button is something to do in a last resort situation - meaning that it isn't something you would normally press - it would be something to do only if the normal backup process failed.
If you want a harder pause/kill, then you may use the pmSuspend option from the developer settings.
But if that option makes a harder pause for ALL backups, then wouldn't that possibly cause the problems stated by hg42?
I was hoping to keep the backup using the normal pause, but just the "Force Kill" button would be a harder pause/kill just in case the normal pause doesn't work for some apps.
Why are you running a connection while restoring that app? I really don't get it.
I was just trying to give a reproducible example of when it will fail. Of course it's nothing I would do intentionally.
but you didn't describe it
I usually only restore data and not the APK. So what happened was that I restored data of one app and then opened it after but it looked just like before restoring it. When I then closed and reopened it, it was fine. Probably it didn't get killed / suspended as it should and just had its data deleted and restored while it was still running. After that I killed / suspended every other app from app info prior to restoring it.
I'm aware that force stopping from app info will make the app not receive any broadcast and not run any service until manually started again and I agree that's not ideal either but at least it will ensure that apps can be restored properly.
When I used Titanium Backup before, it'd always ask me if it should stop the app in case the app was running when trying to restore it.
killed / suspended as it should
but why "should" it?
If you only restore data, it's kind of a hack and then you're responsible for the circumstances. NB cannot know, what you want. There's a kill button on the app sheet, it's only one additional click
sorry, I didn't see the discussion was going on in between
don't confuse kill with pause. pause makes the app sleep and then resumes it after the backup (or the restore).
(btw. pmSuspend only increases the pause, it's still not killing the app)
I once thought about killing apps on restore, at least it's the same like what an install does. So you might be right that NB should kill the app (but only on restore without apk). But your example of killing an ssh session is a strong counter-argument to do it for all packages.
"Force Kill"
does
context.getSystemService(Context.ACTIVITY_SERVICE) as ActivityManager)
.killBackgroundProcesses(app.packageName)
"killBackgroundProcesses" is described as: Have the system immediately kill all background processes associated with the given package. This is the same as the kernel killing those processes to reclaim memory; the system will take care of restarting these processes in the future as needed.
I think this is the same like am kill:
kill [--user <USER_ID> | all | current] <PACKAGE>
Kill all background processes associated with the given application.
For some reason I had an app that failed backup, then I tried "Force Kill" and it still failed. So I had to do the android "Force Stop" and then the backup worked.
other variants:
force-stop [--user <USER_ID> | all | current] <PACKAGE>
Completely stop the given application package.
stop-app [--user <USER_ID> | all | current] <PACKAGE>
Stop an app and all of its services. Unlike `force-stop` this does
not cancel the app's scheduled alarms and jobs.
it seems stop-app would be a good one. We once used force-stop as one variant in our tests (before we decided to pause instead), and users complained about their alarms not being triggered in the morning. Though at that time we killed apps on backups, too.
Actually, I don't remember this option. I guess it only exists in recent Android versions?
For some reason I had an app that failed backup, then I tried "Force Kill" and it still failed. So I had to do the android "Force Stop" and then the backup worked.
now we are talking of backups...
how did the app fail to backup? and which kind of app was it?
As a system administrator I would never backup a system while it runs. Or if I would, then I would need a filesystem that can "snapshot". The file system would freeze, changes go to a kind of overlay file system and on unfreeze those changes are committed to the underlying filesystem. Backups while running have all kinds of problems, either they are inconsistent, or they don't backup the real state (which is partly in memory, if an app runs).
No, it was a regular user app - not system app (I actually have not backed up any system apps yet because of the readme for NB saying that restoring a magisk system apps could cause bricking of the device, so I have stayed clear of system apps with NB)
I don't remember the name - so I will have to get back to you on that.
on backups and restores NB tries it's best to SIGSTOP/SIGCONT (which is pausing) all processes that "belong" to the app. This is not easy to determine.
NB searches all processes that belong to the app user. It also searches all processes that have open files in the app directories.
All these are stopped, unless they are system processes or have names like provider. Those could be used by NB itself and other apps and this may hang the system or NB.
In hindsight, I think, we should probably use a different strategy on restore. I more or less assumed that a restore would kill the app by installing it. Obviously, this doesn't respect data only restores.
No, it was a regular user app - not system app
I wasn't talking about system apps?
"system" administrator was meant as my assumed role on a PC or server.
I actually have not backed up any system apps yet
a backup doesn't hurt, only takes space
because of the readme for NB saying that restoring a magisk system apps could cause bricking
magisk system apps are special. However restoring system apks is not a good idea, either. Some of those apps need to fit to the system (ROM). The data might be ok, but it depends on the data formats used.
i saw am stop-app on api33 (A13)
api26 A8 doesn't have it
api30 A11 doesn't have it
api31 A12 doesn't have it
api32 A12.1 doesn't have it
so it's brand-new
I added code for
am stop-app $package || am force-stop $package
to the restore process
@hg42 that sounds good. When I moved to a fresh ROM, Google would download most apps from Play Store automatically anyway so restoring data was sufficient for me.
Is it also possible maybe to implement a dialog asking if the app should be closed when it is detected running similar to Titanium Backup?