Android 11 Preview 3 brings Recent Apps changes, auto-revoked permissions

There's a new Android 11 Developer Preview. This one is Preview 3, and it launched yesterday for Google's Pixel line. Previous Android 11 previews haven't had a ton of new additions, but this version has a lot of strange and interesting UI changes for us to discuss and puzzle over.

Recent Apps loses the app drawer

In Android 9 Pie, the recent apps screen turned into a horizontally scrolling list of thumbnails with an expandable app drawer at the bottom. In the Android 11 Preview 3 release, the app drawer is gone. It's been replaced with a pretty weak selection of two buttons: "Screenshot" and "Share."

Removing the app drawer from Recent Apps is a pretty interesting decision, considering just two years ago Recent Apps was rearchitected to support this access to the app drawer. The app drawer and app icons are all a part of the home screen launcher, so to make the feature work in Recent Apps, the Recent Apps were pulled out of the core System UI and made a part of the launcher code. This saved Google from having to make any kind of special API allowing another app to access the app drawer—everything was just bundled into the launcher app.

The downside to putting Recent Apps in the launcher is that third-party launchers couldn't access the new app-drawer-in-recent-apps feature. If you installed a third-party launcher, the Recent Apps app drawer would just disappear, leaving you with a bare-looking screen that only showed thumbnails. So this change means different things to different people. If you were using the default launcher that came with your phone, the app drawer is going away. If you were using a third-party launcher, two new buttons will pop-up on the Recent Apps screen, in a space that was previously blank.

The two extra buttons—"Screenshot" and "Share"—really don't look like finalized bits of UI in terms of design or functionality. First, they kind of do the same thing. "Screenshot" will save the app thumbnail to your screenshots folder, while "share" will share the thumbnail screenshot to the app of your choice. Normally you would just take a screenshot and then press the share button, so having the two buttons next to each other seems redundant. The Share button seems bugged right now. It doesn't work with some apps and shares the screenshot along with some junk data to others. For instance, in Gmail it will automatically add the app's package name to the "to" field, as if it were a valid e-mail address.

I totally get adding a "screenshot" button to somewhere in the UI that is obvious and easy to find. If you're doing remote tech support on someone's phone, getting less technical users to successfully take a screenshot with a secret key combination (power+volume down) can be difficult. At some point, Google added a screenshot button to the power menu, but that's another secret button—long-pressing power—that users might not find. Some Android skins have been obfuscating the screenshot feature lately, too, making these screenshot instructions even more complicated. On Samsung phones, you have to press power and volume down for one second exactly. If the press is too short, it won't work, if it's too long, I think it will trigger Bixby. An obvious screenshot button somewhere is probably a good idea.

Another addition to Recent Apps is the ability to undo closing an app. For a while, you've been able to "throw an app away" with a swipe up, but now if you swipe down quickly after doing that, you can bring the app back from death. Tossing an app away and bringing it back is also fun to fidget with.

Dismissing ongoing notifications?

Ongoing notifications are for apps that are doing significant work in the background and, in the past at least, these background tasks have spawned a permanent notification that sticks around for as long as the task is happening. The ongoing notification are there to for two reasons. First, they alert the user that something significant is happening in the background, like Google Maps' turn-by-turn navigation mode, a phone call, or a voice recorder. These tasks keep the phone awake, can use a lot of battery, and can have important privacy implications, so letting the user know that they are still on—and encouraging them to turn them off when they are done—is important. The second reason for an ongoing notification is to offer up controls for these ongoing tasks. For instance, if music is playing, it's handy to have the music controls permanently pinned to the notification panel. It answers the "why is my phone playing music?" question and lets users easily stop the appropriate app if they need to. Imagine not knowing which app is playing music and having to open them one by one. It would be a mess.

In Preview 3, ongoing notifications are... dismissable now? Before, ongoing notifications were permanently in the notification panel for as long as the task was happening—this is the whole point of an ongoing notification—but now you can swipe them away like a normal e-mail notification. Having the notification disappear entirely seems like it would be a really bad idea, so dismissed ongoing notifications instead go to a new notification panel section called "Apps active in background," which displays at the bottom of the notification panel.

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 didn't 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 2017, 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 11, 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 11 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."

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-19 ruining just about everyone's timelines for everything, Google is still committed to a monthly release cycle for the Android 11 Preview, and the company reiterated that commitment yesterday by including the usual timeline graphic in its post.

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 10'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 2020 has been cancelled, even the digital version, so it's hard to know what is happening next month.

Judging by Android 11'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.

Listing image by Android

Comments are closed.