3

I need an automatic brute-force method for unrooted Android devices to kill selected apps that keep restarting in the background, i.e. an appropriate "automatic task killer". Ideally, such method entails a kill command running inside an indefinite loop. Two illustrative examples:

  1. In Windows, you can run the following batch script from the command prompt:
:start
taskkill /f /im "process_name"
goto start
  1. In Linux, you can run the following bash script from the terminal:
while true
do
    pkill -f process_name
done

What I need is an equivalent for Android, but unfortunately, I do not have any experience with programming Android applications yet.

I have tested several "task killer" apps such as SuperFreezZ, but you can only terminate processes manually with those. If Android decides to restart a terminated or frozen process against your will, the new instance is not automatically terminated, rendering all these apps useless.

Are there any apps out there that can get the job done? If not, is there a simple way to implement a background script for Android and have it run permanently?

IMPORTANT NOTE: I do not - I repeat - I do not care about CPU/memory/battery usage or any overhead caused by the task-killing app. The sole purpose is to kill selected background apps as soon as they get (re)started, be it by Android or user action. A small app or script that just keeps sending appropriate kill commands every few milliseconds would do the job (hence "brute force"). The assumption here is that one cannot prevent Android from restarting apps in the background without rooting the device, but one can keep force-closing them the moment they are launched.

For better motivation, one (out of several) use cases for me is terminating Samsung's infamous Game Optimizing Service (GOS), which cannot be uninstalled even via adb as it gets immediately reinstalled (reminiscent to malware). When terminated by the user, it gets restarted after several minutes. An appropriate task killing app would automate the termination process for the user and ensure that GOS is running only for a miniscule fraction of system run time. There are several more reasons for me to desire such solution, which I do not want to get into here as it is irrelevant to the question.

1

1 Answer 1

0

You can do it using an automation app, plus using adb over wireless as stated by @Andrew T. and @Morrison Chang respectively.

A. Enable Wireless debugging

  1. Make sure that Developer options is enabled.
  2. In the Developer options, enable Wireless debugging.

B. Using Automate

You can use Automate or other apps such Macrodroid, Tasker, etc.

  1. Open Automate, go to Settings.
  2. Under "Privileged & Superuser" section, select "Privileged service start method", then select "Android Debug Bridge (ADB)".
  3. A notification will appear. Press Show. The Developer options will open. Go to Wireless debugging and select Pair device with pairing code.
  4. Another notification will appear. Enter the code shown. Automate will be wirelessly paired using adb.
  5. Go back to Automate and create the flow shown on the picture below.
  6. Press +, go to Date & Time, select Delay.
  7. Press the Delay block, press Duration and enter the duration the block must wait. Press Save.
  8. Press +, go to Apps, select Apps in foreground?.
  9. Set it Proceed to Immediately. Seclect the package (this is the app you want to stop). Press Save.
  10. Link the Delay and Apps in foreground? blocks.
  11. Press +, go to Apps, select App kill. Select the package you want to stop. Press Save
  12. Link Apps in foreground?'s No path to the In path of the App kill block.
  13. Link Apps in foreground?'s OK path to the In path of the Delay block.
  14. Optional, to select all blocks, press on Copy icon, then Paste icon. Change the package to stop on the new blocks.
  15. Press Back button/gesture. Press Start
  16. Give the necessary permissions if requested.
  17. Press Start, select the starting points, then Start. Or press Start All.

11
  • Hi, thank you very much for your suggestion. I've installed the latest version of Automate, but I don't quite understand your solution yet. See also my questions in the comments below he question: Why do you need an adb connection? Is it just to set up the this flow chart/code or do you need a permanent debugging connection for your solution to work (= would render it impractical for mobile devices)? Also: Why not use the privileged service start method Manually (Execute "sh /sdcard/Android/data/com.llamalab.automate/cache/start.sh") instead?
    – srhslvmn
    Commented Mar 6 at 17:17
  • Okay, first problem with your solution: I've followed all your steps, set up one Automate flow and tried to start it. But when trying to grant the permission "access screen content and observe your actions" and confirming the subsequent popup prompts, nothing happens (i.e. the permission is not granted). What is the issue here?
    – srhslvmn
    Commented Mar 6 at 19:25
  • ...to be more precise: I keep cycling/bouncing back and forth between the two confirmation prompts "Automate requires the following privilege..." (confirm by tapping "Grant") and "Automate uses the Accessibility API to..." (confirm by tapping "Ok").
    – srhslvmn
    Commented Mar 6 at 19:31
  • Update: Okay, the problem with granting "access screen content and observe your actions" permissions is solved, I had the package com.samsung.accessibility uninstalled, which is required by Automate. But upon running the suggested flow, the following errors are displayed in the log:
    – srhslvmn
    Commented Mar 6 at 21:04
  • Flow beginning >> Delay >> App in foreground? >> App kill >> Failed to start privileged service >> java.util.concurrent.CancellationException: Please execute: sh /sdcard/Android/data/com.llamalab.automate/cache/start.sh >> java.util.concurrent.TimeoutException: Service startup timeout >> Stopped by failure
    – srhslvmn
    Commented Mar 6 at 21:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .