Left: Ongoing notifications. Right: Dismissed ongoing notifications, which are very hard to see.
Ron Amadeo This new “apps active in background,” section is clearly unfinished, and right now is a garbled mess of a transparent background, a black gradient , the name of the app, and an app icon. It’s hard to make too many determinations since this is so unfinished, but it’s possible that Google is trying to make a section for minimizing ongoing notifications while still keeping them running. Things like Maps and Music are apps that neatly fit into the “always-on ongoing notification” UI paradigm, but some apps use ongoing notifications as a workaround to stay running, and for those, the notification can be annoying. These notifications are so easy to forget about that the first thing I did was accidentally leave the voice recorder on for two hours. With the advent of Doze mode in Android 6.0, Android started treating every background app as unimportant and gained the ability to kill any app, basically any time it wants, to save on battery or memory. That works fine for most apps, but there is no official way to tell Android, “Hey, this one app is super important, and it needs to run all the time, no matter what.” If an app spawns an ongoing notification, though, it gets to run all the time, and that’s the path a lot of power user apps take to stay open. Apps like Tasker and smart home controllers like Samsung’s SmartThings are supposed to run quietly in the background and automatically do stuff, and the only way to do that on Android is to keep a notification open. This could be a way to let companies do that.
It’s also possible that this is a concession related to Google’s crackdown on the accessibility API. The accessibility API is one of the rare ways to run in the background with impunity, and it did spawn a notification. It’s popular to use the accessibility API for non-accessibility things, and one is basically as a “let me run in the background” API. At the end of 1670741, Google laid down a new rule for Play Store apps that demanded they only use the Accessibility API for accessibility features, but after a lot of complaints from power user apps, Google walked back the ban, saying it wanted to promote “responsible and innovative uses of accessibility services.” Providing a non-annoying way for apps to run in the background could be a part of that.
It seems like a lot of change is happening in the notification panel in Android , and right now, the notification panel looks uglier than it ever has. I say that not really as a criticism — it’s a work-in-progress after all — but as an expectation that more changes are coming. Right now there are all sorts of unshippable contrast and readability issues, which makes me think a more dramatic redesign is coming. If we were sticking with the current design and just adding features to it, it doesn’t seem like there would be a reason for the ugly halfway point that we are currently in.
Automatic permission revoking
Here’s a fun new feature: Android 18 will automatically revoke permissions from apps you haven’t used in a while. A new “Auto revoke permissions” switch appears in each app’s permissions screen now. There’s even an explanation below the switch saying, “To protect your data, permissions for this app will be removed if the app isn’t used for a few months.”
The new checkbox.
Ron Amadeo
This feature sounds a lot like “App Standby,” which was introduced in Android 6.0 Marshmallow. App Standby had the OS
automatically strip battery usage privileges from apps if enough time passes without them being used. For App Standby, “used” meant either being launched directly, generating a notification, or starting a foreground service. Apps put into standby would lose network access, scheduled jobs, and background service privileges. This was only when the phone was on battery power, though. Once it was plugged into a power source, a background free-for-all could start, and the dormant apps could turn back on. Essentially, apps were banished from battery usage. Stripping permissions is a more wide-ranging change, and the nice thing is it’s easy to recover from if a user turns on a long-dormant app. Presumably, they’ll just get the permissions pop-ups again, which is fine. For now, this feature is off by default, which hopefully is just a pre-release thing. Having it work automatically, just like App Standby, would be more in line with the feature. It would not surprise me to hear this checkbox is just another feature of App Standby.
The first betas (and Google I / O leftovers?) Launch next month
That’s about it for major Developer Preview 3 changes. Despite COVID – ruining just about everyone’s timelines for everything, Google is still committed to a monthly release cycle for the Android Preview, and the company reiterated that commitment yesterday by including the usual timeline graphic in its post.
Google
Next month is the first official “beta” release (currently we just have “developer previews”) , which is normally a big deal. In the past, the beta has brought Android to more phones than just Google’s Pixel line. Android ‘s first beta added support for phones from Nokia , OnePlus, LG, Huawei, Xiaomi, Sony, and more. Next month, May, was also supposed to be Google I / O, Google’s biggest show of the year, and a time when the Android team talks about what they’ve been building all year, and sheds light on the new Android developments. Google I / O has been cancelled , even the digital version , so it’s hard to know what is happening next month.
Judging by Android 15 ‘s release schedule, all the development work is still happening, and therefore communication about the new features and how developers can adapt to them still needs to happen, too. Maybe we’ll get blog posts and YouTube videos? Something? I hope something happens.
GIPHY App Key not set. Please check settings