Add action to force close currently opened app with kill -9 command

[sds100]

• [ ] email Jaime on 28/07/2022 when implemented

[felagund]

What is this going to do? I am basically aiming for the same thing that happens when I press the x button in the app switcher, is this going to be it? Can't wait for ti to be implemented though, would love to bind this to CTRL+Q.

[sds100]

Yeah, hopefully I can find a way to do exactly that!

[sds100]

I really don't think there is a cross-device way to do this.

[dumblob]

Any way to support at least some devices? This is basically the only feature I am missing since I started using KeyMapper months ago.

Maybe some hack as creating a an emulated physical keyboard and then issuing Alt+F4. IDK

[sds100]

@dumblob But doesn't that just go to the home screen?

[sds100]

Also why this action would be unnecessary anyway https://www.slashgear.com/910451/why-you-need-to-stop-closing-apps-on-your-android-phone/

[dumblob]

@dumblob But doesn't that just go to the home screen?

Good question - I did not try to connect a physical keyboard to my phone but read it on the internet. I have only tried to instruct KeyMapper to generate this shortcut but it did nothing (even if I used the KeyMapper keyboard as my default as suggested).

Also why this action would be unnecessary anyway https://www.slashgear.com/910451/why-you-need-to-stop-closing-apps-on-your-android-phone/

Interesting - my reasons are not mentioned there at all :wink:. There are several:

1. weird-behaving apps - especially painful if you have some activity with input fields, you save/submit it and the app "minimizes" the activity (happens e.g. when directly adding a new calendar event) - but in reality this activity is still opened and shows the already submitted inputs as if they were not submitted :open_mouth: - and the response from devs is either something about bad Android API or behavior or simply that they will not fix it
2. UX convenience - I hate scrolling/switching between apps which I know I will not use in the next few hours at the least and I hate to manually close apps every single time I switch to home screen knowing I will not use it for the next couple of hours
3. privacy - call me paranoid but I do want to stream my data (incl. real time data) only in certain situations - e.g. I do want to use maps (and live-stream my position, behavior, identity, etc. to Google/Apple/... servers) only when driving on a longer trip once in a week and not every day, every hour, every minute or even every second. Same goes for ads - I do not want to provide piles of data about my everyday life if I can simply kill the app instead of leaving it running in the background.
4. older phones - wast majority of people (incl. myself) do not have the most modern android versions and many things mentioned in the article you linked are simply not true for them (even flag ship modern phones new to market in 2021 and 2022 do still have issues with killing your most used apps)
5. privacy SW greatly amplifies the power consumption of network-enabled apps - DPI Tunnel, TrackerControl, etc. filters all traffic and the less apps are running the lower battery consumption I have (yes, really measured hours and the difference goes quickly to tens of percent of battery life with just 4 net-enabled apps)
6. I have one battery-unoptimized app which I want to use due to its enormous market reach (there is really no good alternative - yes, this really can happen) - in this case nothing except for manually closing the app works as if I left it to some automation, it would randomly kill it due to the apps weird behavior combined with the aggressive killer-app behavior in the middle of me using it (by frequently switching between 3 apps - typically translator, web browser and this battery-unoptimized app).

So I totally understand many (most?) people do not have these issues. OTOH I think it makes it pretty clear that there are very good reasons to kill apps :wink:.

Any ideas how to go about killing apps using a KeyMapper? An old way suggested by the internet goes like this:

Declare a permission for that in your AndroidManifest.xml file. here it is :

<uses-permission android:name="android.permission.KILL_BACKGROUND_PROCESSES" />

and now use ActivityManager class to kill other apps and it will work.

ActivityManager am = (ActivityManager)getSystemService(Activity.ACTIVITY_SERVICE); am.killBackgroundProcesses(packageName);

[dumblob]

Wow, I have now connected a physical keyboard to one of my phones (Android 7.1 from Samsung but without DeX) and Alt+F4 really closed the app and not just minimizing it.

[sds100]

Woah, it actually kills it? Would the key event action with Alt+F4 and Shizuku work then? Also, there is confusion in the community because swiping the app away in Recents does not actually kill the app and all these solutions kill the Linux process. This is may or may not be what people are expecting. The system just tells the activity to stop when you swipe the recents. So from the privacy point of view an app can just start a Service and collect that information even if you swipe it away. This is recommended anyway because you want that stuff to run in the background.

[sds100]

The KILL_BACKGROUND_PROCESSES permission and method don't seem to work. :/ I am pretty confident there isn't a public, and permissionless API to kill arbitrary processes on the system. We have enough trouble with the system killing stuff, imagine if 3rd party apps could... They would just kill other apps so they aren't killed. 😂

[dumblob]

Woah, it actually kills it? Would the key event action with Alt+F4 and Shizuku work then?

I do not know what exactly it does. I did not try Shizuku which would not solve my problem anyway (I do not have any rooted phones)? But the two apps (yeah, statistical unsignificance rulez!) I closed with the physical keyboard attached disappeared from Recents and one of them could also not be killed from Settings (i.e. "Force Stop" was already "pressed") and the other could (because it has a background process).

Also, there is confusion in the community because swiping the app away in Recents does not actually kill the app and all these solutions kill the Linux process. This is may or may not be what people are expecting. The system just tells the activity to stop when you swipe the recents. So from the privacy point of view an app can just start a Service and collect that information even if you swipe it away. This is recommended anyway because you want that stuff to run in the background.

Yes, this is my expectation - I do not demand to "Force Stop" (i.e. kill -9) the app - I want to send it a "stop" request (killl -15 i.e. SIGTERM or an Android alternative using message bus/passing/whatever Android prefers/uses) as you called it. But I would accept "Force Stop" if the "normal stop" was not available.

Regarding privacy etc. this is fine as I have other means to check (or ensure) the app can (or can not) run in the background. So I am really just interested in the foreground activities & apps.

This reminded me of the time 14 years ago when I made a prank Android app which could not be uninstalled without debug tools and could not be easily detected (it ran in the background as a special service) but mainly it was impossible to kill it (without debug tools) and one had to restart the whole phone to stop it. Coll stuff in those old days of Android :wink:. Note I am not doing Android development since 12 years ago and from what I saw in the new APIs it is a whole new system, not even resembling those old days.

The KILL_BACKGROUND_PROCESSES permission and method don't seem to work. :/ I am pretty confident there isn't a public, and permissionless API to kill arbitrary processes on the system.

Of course not! KeyMapper would have to ask for permission to kill other apps once the user chose the "Action" to kill the currently opened app activity. At leas that is how I understood the snippet I found on the internet.

We have enough trouble with the system killing stuff, imagine if 3rd party apps could... They would just kill other apps so they aren't killed.

App store is full of battery/memory/... optimizers which must kill stuff somehow (I guess they use "Force Stop" to achieve the goal though).

[dumblob]

Wait, Shizuku does not need root? I will then have to try play with it! You said I shall try Alt+F4. I will take a look how to achieve that with adb (i.e. Shizuku).

[dumblob]

Oops, that was a bit premature excitement - until Android 10 it needs a computer connected over usb to run adb - and this after each phone restart. And from Android 11 it does not need a computer but it seems it needs wifi AP instead (and anyway still needs quite some manual steps after each phone restart).

[sds100]

Cool, you're an Android dev too ;). Yeah, it is completely different these days.... waaaay more permissions and "bureaucracy" on the system to do anything. 😂 I just installed one of these dodgy "optimiser" apps, I'm not sure if it did anything. a) one of the "kill" apps just takes you to the device Settings page to manually force stop it and b) i pressed another kill button and it did not do anything to any of the apps. the Notifications were still running, they were still in the background etc.

Yeah, the killBackgroundProcesses method doesn't do anything. You also don't have permission to do killall in the shell without su. I did su killlall <app> and it worked as expected - the process was completely killed and you can tell this on Android when the notifications disappear. This did not remove it from recent apps as expected due to the swiping away not actually killing the process. Also, more importantly, the system just restarted the process straight after so even using the most aggressive form of killing won't actually do anything 😉

The only way to do what it sounds like you want is to do the exact same thing the system does when you swipe an app away in the recents menu. But there is no API to do this. :(

[dumblob]

Cool, you're an Android dev too ;). Yeah, it is completely different these days.... waaaay more permissions and "bureaucracy" on the system to do anything. joy

I can feel your pain.

I just installed one of these dodgy "optimiser" apps, I'm not sure if it did anything. a) one of the "kill" apps just takes you to the device Settings page to manually force stop it and b) i pressed another kill button and it did not do anything to any of the apps. the Notifications were still running, they were still in the background etc.

Hm, interesting. Would not expect this to happen. Maybe I will take a look into it as some years ago it did work for people around me if IIRC :wink:.

Yeah, the killBackgroundProcesses method doesn't do anything. You also don't have permission to do killall in the shell without su. I did su killlall <app> and it worked as expected - the process was completely killed and you can tell this on Android when the notifications disappear. This did not remove it from recent apps as expected due to the swiping away not actually killing the process. Also, more importantly, the system just restarted the process straight after so even using the most aggressive form of killing won't actually do anything wink

Thanks for trying. That further deepens my interest in finding out why is it so and when did this happen (with which Android version). Will see if I find some time to do such investigation.

The only way to do what it sounds like you want is to do the exact same thing the system does when you swipe an app away in the recents menu. But there is no API to do this. :(

That really is a pity :cry:. What would you say about the hack with Alt+F4 (and thus maybe emulation of a physical keyboard)?

[sds100]

Key Mapper already has a way to emulate another input device with the key event action. You can use an IME or Shizuku. But to make the key event look like it can from another device you have to have that device physically plugged in. There is no way AFAIK for a 3rd party app to add a fake but real device to the system without root.

[dumblob]

Key Mapper already has a way to emulate another input device with the key event action. You can use an IME or Shizuku.

Will take a look at the IME way. I probably need to install some IME SW/keyboard first. Potentially related: https://github.com/keymapperorg/KeyMapper/issues/1004 .

But to make the key event look like it can from another device you have to have that device physically plugged in.

Makes sense actually.

There is no way AFAIK for a 3rd party app to add a fake but real device to the system without root.

Yeah, that su**s.

[sds100]

But with the IME method the IME must be one of the Key Mapper keyboards. There is no way to tell an input method that you haven't coded to input arbitrary events for security reasons. 😄

[sds100]

I'm going to close #1004 since it isn't possible

[dumblob]

But with the IME method the IME must be one of the Key Mapper keyboards. There is no way to tell an input method that you haven't coded to input arbitrary events for security reasons. smile

Ok, so basically the same I already did a few days ago and it did not work for some reason :cry:. Maybe Alt+F4 works only with real USB-connected keyboards? Does that make sense or is it some glitch in Android API?

[sds100]

It won't work with the Key mapper IME because an IME inputs key events into the foreground app. The system isn't aware of any key events sent by the IME. Using shizuku should work because this injects key events into the system.

[dumblob]

Ok, then the only option seems to be to create & sell a magnificent all-encompassing HW USB-C plug of miniature size (imagine the size of the connector with a "cap" on wireless chargers) with ping/round-trip HID capabilities :wink:. KeyMapper would then send HID commands (or other USB-compatible protocol supported by every android version so far) to the device and the plug would send it back to Android as HID scancodes or alike.

Or alternatively try some non-power-hungry automation apps detecting what is being shown on screen etc. and reacting to that by touches/swipes/you_name_it.

Interesting how Android became nearly more constrained than the Apple ecosystem over the years :open_mouth:.

Either way, thanks for you precious time!

[sds100]

@dumblob That would actually be really cool. A device that can simulate any hardware device at a hardware level. Do you know of any USB HID dongles that can be dynamically programmed?

[dumblob]

Not now, but some are "quite close" - Tomu family and other such coin-sized usb PCBs. In the end something like Fairberry @dakkaron is working on really hard might also come handy :wink:.

All these can be turned to a tiny PCB (10x4 mm) with a vertical USB-C with some subtle "mushroom head looking" plastic cover (something nicer than just https://cdn.hackaday.io/images/7065761640066907946.png ).

[Dakkaron]

First, regarding the issue at hand, I got a workaround for you.

Download and open the Automate app from Llamalab.

Create a new flow with the following blocks:

In the "is foreground app" block, change "Proceed" to "immediately". In it's "Output variables" section type the word packageName into the field "foreground package".

Save and open the "Kill app package" block. Pres the fx-icon at the right and input the word packageName into the field.

Save and use the back arrow to get to the flow overview screen. At the top it should say (or something similar, I am translating). Press that and change the flow's name to something useful. Press start once (it will fail, but it will ask for the required permissions).

Now switch to Key Mapper. Create a new mapping and for the action use "flow shortcut". Search for Automate and then the flow you just created.

Save everything and you have the functionality you want.

Regarding Fairberry If the people at the Key Mapper project find it useful, it would be rather trivial to use the Fairberry as a IME bouncer, so that they can emulate any key (as long as it's on the selected keyboard layout) without using a real IME at all. Would just need them to implement something that sends the key strokes using USB Serial, and I need to implement the firmware feature for it, but it's fairly trivial.

[dumblob]

I have now quickly tried the Automate app from Llamalab on an old Android (7.1.1) and the "Kill app" block requires a rooted phone which it is not (and it was my goal to not have to root the phone :wink:) otherwise it throws an exception java.lang.IllegalStateException: Failed to bind Superuser service: a rooted device is required.

Thanks anyway for the tip on Automate and a very detailed guide how to achieve it on rooted phones!

[Dakkaron]

I fear, killing other apps will always require root... Using kill -9 command will also require root for killing other apps than the currently opened one.

Routing through an USB device would work, but that requires an USB device.

@sds100 If you are using the kill command, might as well add the ability to execute arbitrary shell commands, what do you think?

[sds100]

@Dakkaron yeah, it will always require root. Someone else just emailed me requesting this feature and they are rooted so I will implement this to make those people happy 🙂. Executing shell commands is planned as well #661 . Right now I'm trying to clean up some tech debt with configuring actions... right now it isn't fun or easy to implement good user interfaces for configuring actions.

[Dakkaron]

@sds100 Nice, thanks! The tech debt is something I can understand wellˆˆ

[jswinde]

@sds100 Just checking to see if you have made any progress on this request? I find this to be a very useful feature!