Google is finally helping developers fight back against smartphone manufacturers breaking how Android apps work - Android Police

The new CTS-D and its first test could have a huge and beneficial impact on developers and customers — if Google gives it teeth
We dance around it and claim that it's less of an issue every year, but Android still has problems because of fragmentation. One of the most annoying ways fragmentation can still manifest is when smartphone manufacturers mess with how apps work and behave, breaking expected behaviors or adjusting how they work to plump out battery life. This means that, from phone to phone and manufacturer to manufacturer, apps can behave differently than customers expect, offering an inconsistent experience and a developer support nightmare.
Android is open source, and anyone can change how it works to do whatever they'd like, but Google is implementing a new set of compatibility tests submitted by developers to ensure that smartphone makers don't break expected behaviors or add frustrating limitations. And, if it pans out, developers won't have to worry as much about making workarounds for specific devices or see their apps simply break with no way to fix it on others.
Back in 2020, I did an investigation into smartphone manufacturer background and foreground app management practices after receiving years of complaints from developers regarding how big-name companies were adjusting behaviors in a way that app-makers couldn't anticipate. Frustrations ran the gamut from apps dying faster than expected when not visible, to delayed notifications or other app events, to not being able to wake up at the right time. If you rely on your smartphone for things like glucose monitoring or insulin delivery, these issues aren't just frustrating, they could be lethal. This caused customer support headaches as apps would often break in unexpected ways when used on different devices and required that developers either come up with tailored workarounds for specific smartphone manufacturer software skins (if workarounds were even possible) or ignore the issues entirely, leaving customers without a solution.
There's a song at the end of this presentation, at least skip to the end and play it while you read — it's kind of funny.
Some of the affected developers I spoke to at the time told me that it was a nightmare. Not only did they have to handle angry reviews from customers who hadn't done anything wrong, they had to individually troubleshoot and determine if and how the problems could be fixed on a nearly device-specific basis. That's an incredible amount of work that smartphone manufacturers pushed onto developers merely to eke out a few extra minutes of battery life. While the changes made to individual phones and software skins are at fault here, ultimately the issue stemmed from Google's failure to put its foot down and require that certain behaviors in Android remain unmodified.
For context: Android is open source and anyone can change it or use it pretty much as they see fit. But if you want access to the Play Store or Google's apps then there are rules you have to follow. But even where Google does impose certain standards in its various public and confidential documents, the company was hesitant to step in on this particular situation. This opened the door for manufacturers to potentially offer "improvements" to Android, but the actual impact was almost universally the opposite, with some companies outright breaking how apps worked, dragging down the Android ecosystem, developer expectations, and customer experiences.
Urbandroid, the developers behind the popular Sleep as Android app, had been maintaining a list of manufacturers and how apps running on them were affected called Don't Kill My App. The developers even put together a brand new app behavior benchmark for us to use as part of our investigation.
According to Petr Nalevka, one of the developers at Urbandroid, Google's new CTS-D tests might be the solution we're finally waiting for, and Google's going to let developers themselves put their foot down on its behalf.
The CTS-D is a new "module" for the Android Compatibility Test Suite (CTS) that will take advantage of developer-submitted tests (the -D in CTS-D). That means any developer that has run into compatibility issues on certain devices for their apps can figure out the precise nature of the issue they're having and come up with a way to test against it. That test can then be submitted back to Google and potentially included in the new CTS-D.
This could be huge because devices must pass the Android CTS to get Google's apps. If a smartphone manufacturer wants access to the Play Store (and they all do), then they have to meet minimum standards that include the Compatibility Test Suite to ensure expected behaviors are maintained. If the CTS now includes developer-submitted tests — and this might actually be a big "if," more on it in a second — that means device manufacturers will have to pass those developer-submitted tests too to get access to Google's Apps and storefront. In fact, the first test ever accepted to the CTS-D was submitted by Urbandroid's Nalevka to address the issue we've reported for years, hopefully preventing apps from being killed by overly aggressive management practices.
The first CTS-D test addressing background work in apps.
Nalevka has been on a tear, submitting different tests to the CTS-D for ways to measure the background work problem and working with Google engineers since last year on the best way to accomplish these changes, almost as a test in itself for how the CTS-D will work. And the first CTS-D test, which appears to be based on the Don't Kill My App Benchmark itself with a similar score metric, has been accepted. These developer-submitted tests for the CTS will be available as part of Android's open-source code for both developer and manufacturer scrutiny.
This doesn't mean that things are "fixed" yet, and there's still a little potential ambiguity here. Google confirmed to us that the CTS-D is essentially an extension of the CTS to include third-party developer contributions, but at least one detail in the announcement makes it sound as if it might not be subject to the same kind of enforcement, with Google only claiming that it is "strongly advising manufacturers to use CTS-D to discover and mitigate issues," emphasis mine. When it comes to Google's testing requirements in other contexts, like the Android Compatibility Definition Document (CDD), "strongly advise" or "strongly recommend" typically means something isn't actually a requirement, just a recommendation.
We know for a fact that CTS testing is required for GMS licensing, but it's not clear if Google has carved out some kind of gray-area exception for the CTS-D compared to the rest of the CTS. The CTS-D documentation elsewhere claims that accepted submissions from developers are accepted into the CTS itself, implying there is no distinction. Developers that notice a device doesn't pass a CTS-D test can report it in an issue tracker template, and Google will work with its partners (i.e., the device manufacturers) to solve it, but it's not clear if the CTS-D has real "teeth" behind it like the CTS does. We've reached out to Google to confirm how the CTS-D will be enforced and if the tests in it will be treated any differently than the CTS itself.
"When every smartphone treats apps differently, and some of them break how apps work at a fundamental level, that's Android's fragmentation problem at its very worst."
Google tells us that the focus for new tests right now is primarily meant to address power and battery behaviors, but it sounds like tests for more types of issues will be considered soon. There are also a few pretty logical guidelines that developers have to follow when coming up with tests, and Google won't accept just anything. First, they must test against public API behaviors described in the Android developer documentation. Second, they must have requirements included in the Android Compatibility Definition Document. Third, they must not be duplicate test cases already covered elsewhere in the CTS. And even if tests meet these requirements, submissions are merely proposals subject to the review of the Android team. While they have developer interests at heart, if a test goes against their plans for the platform or could have other unintended consequences, it probably won't make the cut.
Back in 2020, Google said in rather bland terms that, while it was committed to fixing background app management, premature app death, issues waking, and other problems caused by smartphone manufacturer "optimizations," it wasn't actually going to do much about it directly. While the company claimed it would stop manufacturers from exempting their changes through allowlists (as many did, to keep certain messaging apps working better), all Google would impose was a requirement that customers be informed if more aggressive app restrictions were being applied automatically and that there be a way to opt out of this behavior. The (then-new) crash reasons API was also presented by Google as a way for developers to see what went wrong and to measure if devices were treating their apps poorly in unexpected ways, but knowing why an app died can't prevent the issue from happening if it's out of app-developers' hands.
I didn't think Google's stance regarding the issue in 2020 went far enough, and I frankly didn't trust the company to enforce what little it claimed it would do since it ignored app-based allowlisting for background work that was ostensibly against the rules for years. Managing an ecosystem that's as far-reaching as Android does admittedly require a light touch to ensure you don't disenfranchise novel use cases or potential improvements and platform advancement, but this was a serious issue that was doing harm to the ecosystem, alienating the developers that it relies on to succeed and actively interfering with how customers wanted to use their apps. When every smartphone treats apps differently, and some of them break how apps work at a fundamental level, that's Android's fragmentation problem at its very worst. This required a firmer hand to deal with, and in the last two years, it looks like Google may have finally worked up the courage.
Just earlier this year at I/O, Google brought out a handful of other changes it was planning in Android 13 that would improve the situation, like giving users the ability to see when apps are consuming too much power and a foreground task manager, while also letting them swipe away foreground service notifications. This doesn't fix the problems directly, but it gives customers the ability to make an informed decision to control apps themselves, reducing the need for smartphone manufacturers to make dumb decisions on their behalf. Google also reiterated some best practices developers can follow in the hopes that apps can manage resources better.
The new Android CTS-D sounds like Google has reconsidered its position here in a very positive way, accepting that developers might have problems they can see and the insight to fix them, all through empirical tests that can demonstrate precisely how smartphone makers are screwing things up for developers' apps. If Google does plan to enforce the CTS-D tests as it does other CTS tests, making them a requirement to license its apps and services, then our long collective background app nightmare might be over. Perhaps soon, we can return to a world of prompt messaging notifications, reliable and functional sleep- and activity-tracking apps, consistent alarms, and more. OnePlus, Samsung, and Xiaomi will have some phones to fix, and Android developers everywhere owe Nalevka a beer.
Ostensibly a senior editor, in reality just some verbose dude who digs on tech, loves Android, and hates anticompetitive practices. His only regret is that he didn’t buy a Nokia N9 in 2012. Email tips or corrections to ryne at androidpolice dot com.

source