Google is investigating phone makers for being too aggressive in killing Android background processes

Over the past few years, Google has made significant improvements to how Android handles background apps. Optimizations like Doze and App Standby Buckets help allocate system resources to the apps that need them most, while ensuring that abusive apps don’t run recklessly in the background.

For a long time, Android users have criticized iOS for the way it aggressively kills apps running in the background. Android phones' multitasking capabilities, larger memory pools, and bigger batteries have been touted as examples of the platform's superiority. However, for various reasons, some manufacturers have taken it upon themselves to take stricter measures, perhaps even against Google's policies, and Google now wants to know who these OEMs are.

Survey Form:

• https://docs.google.com/forms/d/e/1FAIpQLSd9P3gLKgMbVwQnAra6UhOjnCWtKpp55kYmigUKo8-ynmvdPg/viewform?resourcekey=0-e65sRbpisoGmtEe_zPZnMg

Most Android apps may not need to run in the background all the time, but there is definitely a class of apps that do. In fact, there is a class of apps that shouldn't run in the background at all, especially those with tainted intentions, such as malware. However, some health-centric apps may need to run all the time, but the system may not always let these apps run.

Of course, background apps, while they bring a lot of convenience, do not come without a price, usually in terms of CPU usage and ultimately reduced battery life. That's why platforms, including Android, set rules and restrictions on which apps can do so and when. The Android system also leaves room for exceptions and provides ways to support apps going to sleep and waking up again.

On the other hand, Google has also laid out rules for OEMs to make the process of killing apps in the background transparent, but this is where things get a little messy. Some OEMs implement their own app-killing policies on top of Android, but usually don't let developers, let alone users, know about them. This means that some apps, such as sleep monitoring or activity tracking apps, can work on one phone and may not work properly on another brand, simply because the latter is more aggressive in killing apps running in the background.

App developers have been complaining about this situation for years, and it seems that Google has finally heard their pleas. Some have reported that certain brands are even stifling important Android accessibility assistance services (which are seen as an essential feature of the OS to take care of vulnerable groups such as the visually impaired and hearing-impaired). Back in 2018, an issue was created on the AOSP bug tracker detailing how a handful of OEMs were abusing Android's core functionality to disallow third-party apps from running in the background. The issue was filled with responses from hundreds of app developers, echoing similar experiences and urging Google to prevent OEMs from violating Android system compliance and implementing such radical policies.

On June 8, 2021, a user commented that OEMs such as Xiaomi and OnePlus even killed AccessibilityService. In response, a Google employee recently commented that they will study the issue and invite app developers to submit their feedback.

Google requires developers to provide the following details:

• Name of the affected application
• The name of the OEM and device model where they observed the issue
• Android OS version
• Steps to reproduce the problem, along with expected and observed results
• Affected APIs
• Are they able to reproduce the same issue on a Pixel device (or other device running the same Android version).

Considering that this situation has been going on for years, this investigation is really long overdue. Better late than never, as they say. Google doesn't even need to ask developers themselves, because the "Don't Kill My App" website has been around for years, and it's not difficult to get the facts from programmers who have been suffering from phone manufacturers for a long time.