We’re used to installing killer tasks on our Android devices to stop the most “exhilarating” applications. We explain why this behavior is useless and we will show you how to work effectively to reduce RAM and CPU consumption for unwanted autorun applications.
We explain why this behavior is useless and we will show you how to work effectively to reduce RAM and CPU consumption for unwanted autorun applications.
Looking for the Internet, there are many guides where it is advised to install a killer task on your Android device to control applications that we believe are “heavy” or unnecessary to boot or to close closure.
What we do not know is that such behavior is completely useless and the motivations are numerous:
A closed app forcibly will try to reopen, almost immediately;The killer task, to force the closure of “just re-opened” apps, will consume more RAM, CPU, and closed application battery;The killer task closes only the process, leaving basic services and orphaned libraries in memory; the latter will try to reopen the reference process, forcing the task killer further;Android is absolutely capable of managing the processes started in RAM memory by automatically closing applications that are no longer used or in the background for a long time when memory is scarce.We can see that this approach is not the best if our goal is to reduce the number of processes and the consumption of RAM (and to increase battery life, especially if the apps we use are of a heavy nature even in the background).
The goal is another: prevent these apps from being opened autonomously, at system startup, or at any time without any apparent reason; the system does not really need their boot, if not extensively requested by the owner of the device (manual launch of the app from the menu or from the launcher).
Once started, it’s so good to let it run on Android!
This scenario is very common: we have applications (including system) that we do not use, or we use very little, but these are (somehow) always present in memory, or they start automatically when we do some smartphone operations.
Some easy examples: Google Maps, Google Translator, YouTube, Browser, more third-party apps you do not have to always get active.
In the worst scenarios, some apps start auto-booting since booting the system, slowing down the boot process and occupying memory before other major applications.
You can lock their boot on birth through an advanced app manager: Gemini App Manager.
Under the lookup of the killer ( a feature that we will not use) hides the advanced features used to control the services and processes of an application, blocking each automatic startup or unauthorized user by removing permissions to individual processes, services, and libraries associated with the application.
Applications will still be usable and bootable manually, only when we need it.