Not everyone can or even wants to spend money on buying the latest flagship smartphone, but fortunately, there are a lot of low-end and mid-range phones on the market to pick from. These phones trade flagship-tier components for a lower price, and while their performance may be acceptable to the vast majority of users, some may find them sluggish. Many users turn to third-party apps in an attempt to speed up their Android phone, but Android can’t be sped up by third-party tools in ways that other platforms might be. Third-party “speed booster” apps can actually end up doing more harm than good, which is why Google is preparing to crack down on them with changes in Android 14 and a warning to app developers on Google Play.
Much has been written over the years about the efficacy of “task killer” apps that claim they can improve performance, and the recommendation has always been not to use them. That’s because the OS already has its own built-in task management mechanisms, which were designed with the memory and power constraints of mobile devices in mind. Killing processes to free up memory without regard for what state they’re in or knowledge of how Android/Linux manages memory can actually negatively affect performance as the OS has to do more work (and thus use more CPU cycles) to perform cold starts of processes the user just killed. It’s almost always better to let the OS manage memory than it is to use a third-party “task killer”/”speed booster” app to kill processes, which is why Google is starting to restrict what these apps can do and preparing to limit how developers market them on Google Play.
Beginning in Android 14, one of the APIs commonly used by “task killer” apps will be restricted. In previous releases, apps that hold the KILL_BACKGROUND_PROCESSES permission (a “normal” ie. install-time permission) can call ActivityManager.killBackgroundProcesses(String) to kill all background processes of a given app. This method does the equivalent of the kernel killing those processes to reclaim memory, leaving it to the OS to restart those processes later when needed.
When apps call this method on devices running Android 14, regardless of that app’s target API level, they can only kill their own background processes. Passing the package name of any other app will have no effect on that app’s background processes, and in fact, the system logs will state that an invalid package name was sent.
Logcat from a device running Android 13 QPR1 using killBackgroundProcesses(...):
03-07 20:28:15.313 1675 4577 I ActivityManager: Killing 23628:com.twitter.android/u0a350 (adj 700): kill background
Logcat from a device running Android 14 DP1 using killBackgroundProcesses(...):
03-07 20:30:24.748 1827 2979 W ActivityManager: Invalid packageName: com.twitter.android
This change was already present in Android 14 DP1, but new documentation was added with the release of Android 14 DP2. The documentation states that apps “shouldn’t use the killBackgroundProcesses() API or otherwise attempt to influence the process lifecycle of other apps, even on older OS versions. Android is designed to keep cached apps in the background and kill them automatically when the system needs memory. If your app kills other apps unnecessarily, it can reduce system performance and increase battery consumption by requiring full restarts of those apps later, which takes significantly more resources than resuming an existing cached app.”
The existence of this API (or rather, its availability to third-party apps) never quite made sense anyway, considering it violates Android’s application sandbox model. Each app is placed in its own sandboxed process that can only interact with one another using well-defined APIs. The killBackgroundProcesses() API allows one app to unilaterally control (kill) the processes of other apps, something that only the system should be able to do. That’s why, starting in Android 14, only system apps holding the new KILL_ALL_BACKGROUND_PROCESSES permission (which has a protection level of “privileged|signature”) can kill the background processes of other apps.
One other tidbit that’s interesting is the note at the bottom of the documentation for this change. It states that “it isn’t possible for a 3rd-party application to improve the memory, power, or thermal behavior of an Android device. You should ensure that your app is compliant with Google Play’s policy against misleading claims.” Google Play has long had a policy against “deceptive behavior,” which includes apps making “misleading claims” about “functionalities that are not possible to implement.” However, the policy never explicitly forbade apps from making claims about boosting the performance of the device/OS and never even listed these claims as examples of common violations. Given this wording, it’s possible that Google will start treating these claims as misleading and will begin cracking down on apps that make them.
Image source: Kari_Caverdos/Shutterstock.com