We're quickly approaching the final release of Android 11, and as developers continue to work with the software to ensure all of their apps are ready to go at launch, Android's engineering team held an AMA (ask me anything) on Reddit to answer any and all technical questions about the platform update.
The team didn't reveal any new info about Android 11 we didn't already know, but it did offer some insight for features that are being worked on for future Android versions. None of this is concrete or set in stone, but it does give us a little glimpse ahead as to what we can look forward to with Android 12 and other builds beyond it. Or, in some cases, temper our frustration with the current limitations and issues on Android 10 and 11.
Scrolling screenshots
Let's start with the most annoying tidbits that came out of the AMA — an update on Android's scrolling screenshot feature. This is something that's been hinted at in early builds of the Android 11 Beta, but Google quickly deflated any hope we had of it coming to the final build. According to Google, "We're still working on it, but it didn't make the cut for R."
What's the big holdup? Google is apparently designing it to be an API that app developers can adopt. Here's the full answer:
Rather than cranking out a quick hack that works for one or two hand-picked apps on a particular device, our goal on the platform team is to build this in a way that any app can plug into, whether they're using a bog-standard RecyclerView or have implemented their own OpenGL-accelerated scrolling engine. We investigated this throughout the R timeline, involving folks from the window manager and System UI teams; you'll be able to see this scrolling capture framework start to take shape in the AOSP source.In the end, as with every Android release (and especially in this unusual year), we had to make hard choices about where to focus our limited resources; while this is a cool feature that we're still really excited about, we decided not to rush it. Look for it in a future API bump.
Here's the thing, though — a scrolling screenshot feature doesn't need to be an API. It can just be a system-wide feature that's implemented across the board, and once that scrolling screenshot image is saved, any app can handle it how they want. Companies like Samsung and OnePlus have offered their own scrolling screenshot features for years, yet for some reason, Google just can't figure this one out.
We're crossing our fingers we don't have to wait any longer than Android 12 for this to finally come to fruition, but who knows at this point 😅.
Improved cloud backups
Google's cloud backup system for Android is fine, but there's definitely room for improvement. Thankfully, Google says that things are in the works on this front.
When it comes to having more detailed backup information, such as being able to see and manage backups for your various devices, there's a bit of good news:
We know that, especially for users with multiple devices, it's increasingly important to be able to drill into the detail of which devices are backed up, how fresh is that backup, and much more. Many of us at Google want exactly the same thing! So, we hear you, and we will have more to talk about in this area in the future.
Google's backup process currently has a limit of 25MB for app data, and while Google says that's "more than enough," it also acknowledges that more room is sometimes needed by especially heavy users. For them, Google is:
Looking into how best to solve that while being respectful of things like data consumption and battery life, which can be adversely impacted by large backup sets.
We also learned that Google doesn't plan on having a desktop-focused backup solution anytime soon, and "in the next few Android releases" will be killing off the old adb backup feature:
Backing up to a laptop or desktop isn't a use case we're prioritizing. Investing in both cloud backups and device to device migrations is going to be helpful to more users. In fact, we're going to be turning down adb backup in the next few Android releases.
More restrictions on background app killing
For the past few years, there's been a lot of talk about companies that implement their own systems for aggressively killing background apps in Android in the name of extending battery life. Jerry addressed this very topic back in 2019, noting that Google wasn't doing much of anything to stop it. This is something that was addressed in the AMA, with Google saying that it's aware of the issue and continually working to improve it:
Background kills is a complicated topic that our team has been working on for awhile - it doesn't help that each manufacturer does it differently. We feel the developer community's pain and are committed to solving it. We've been in discussions with many device manufacturers to understand the reasoning behind their implementations, not just to preserve battery life, but also to protect users from misbehaving apps. At the same time, we've been working to move them away from using extreme methods such as app force-stop which renders the app unusable for users.
There are a handful of updates in Android 11 that hope to mitigate the issue, such as requiring manufacturers to properly alert users of killing background apps and adding a new API that allows developers to see why their app was killed. They're small steps in the right direction, but there's still work left to be done for future Android versions. Google is perfectly aware of this:
These don't solve everything with background restrictions, and we are far from the finish line. But we're committed to continue working on it, balancing making it easier for the developer community while ensuring our users get the best battery life possible.
Further refinements to gesture navigation
Android 10 introduced fully-gestural navigation to the operating system, and while it's a marked improvement over the two-button navigation we had with Android 9 Pie, the back gesture that interferes with hamburger (slide-in) menus still makes it feel a bit clunky at times. Google says that developers switching over to bottom navigation buttons is a "solid move" and that it is throwing around the idea of having a way to handle the collision with hamburger menus:
From a system perspective, we're still trying to figure out if we want swipes to ever invoke the hamburger menu - given back swipe's >300 times/day/user usage, we'll continue biasing against hamburger menu's low-use swipe (especially as users are more likely to tap the hamburger menu button on non-gesture-nav modes to access the menu versus swiping from the edge).
Google is also "looking to improve the gesture nav back look & feel," but for those of you that really hate it, it doesn't appear to be going anywhere anytime soon. At least we know that Google knows gesture nav isn't perfect and is still being worked on.
Improving third-party launcher experiences
Third-party launchers are one of the best ways to customize your Android phone, but in Android 10, they aren't all that great — especially when it comes to using them with gesture navigation. Thankfully, work is being done to address this:
We've made several improvements in Android 11 that enables better animations on app-switching / going home transitions for launchers. Candidly - we're still assessing the best approach to turn some of the deeper interfaces needed into stable, public APIs and hope to have more to share here in a future release.
Just like so many of these features/updates, it's not very clear when any of this will be ready to go. Even so, better launcher compatibility is definitely something we can get behind. Being able to customize your phone with a launcher is a big deal, and it's never good when that sort of functionality feels second-rate on Android.
Android 11: Everything you need to know!
Have you listened to this week's Android Central Podcast?
Every week, the Android Central Podcast brings you the latest tech news, analysis and hot takes, with familiar co-hosts and special guests.
