Search

Android 11—The Ars Technica Review - Ars Technica

bentangos.blogspot.com
Android 11—The Ars Technica Review
Google

Android 11 has finally arrived after a lengthy beta process that started approximately three years ago in February 2020. This is the 30th release of Android, if we're counting by API levels, and in a year when it seems nearly everything has been delayed or canceled, Google has managed to turn in one of the smaller Android releases.

Last year, Android 10 was a massive release, adding gesture navigation, a dark mode, Project Mainline, a dual-boot system, scoped storage, foldable smartphone support, and a million other things. In comparison, Android 11 is more limited. This being the annual Ars Technica review, however, there are of course still plenty of things to talk about—like yet another notification panel revamp, a new media player, chat bubbles, smart home controls, and more.

Table of Contents

The notification panel

The notification panel is one of the biggest strengths of Android, and Google can't seem to let a major release go by without iterating on it. This year, the theme seems to be around organization and creating what Google calls a "dedicated persistent space" for certain types of notifications.

Notifications are now broken up into five categories, some with big headers on top of each section. "Conversations," "Notifications," and "Silent" notifications get the big header labels in the notification panel, while ongoing notifications from things like Google Maps navigation don't get a label but are pinned to the top of the panel. The fifth type is for media notifications, which now live inside the Quick Settings panel. This is a wild change.

The persistent media carousel

The media player can actually end up in two spots, depending on when you last played a piece of media. If you have a currently playing or recently paused media session, the media player will show up above the notification panel. If you swipe away the media player or haven't played anything in a while, it will show up at the bottom of the expanded Quick Settings. Since you access the expanded Quick Settings from the notification panel, it's sort of like the media player can end up on "Page 1" or "Page 2" depending on how recently it was used.

To make room for the media player, the Quick Settings icons are now down to six icons per page, where previously there were nine icons per page. So you swipe down the notification panel and see six items at the top, and then when you expand the Quick Settings panel you see... the same six icons. It doesn't make a ton of sense.

The media notification space supports multiple players. If you've started up more than one media app recently, you'll be able to horizontally swipe through multiple media players, which is great for switching between a music player and podcast app. It's up to each app to hold a spot for itself in the media player carousel, which can hold up to five apps.

Apps can supposedly secure a persistent spot in the media player by calling the new "MediaBrowserService" API. I don't think any apps, however, actually do this right now, so it's hard to know how it works. Google claims that apps pinging the new API will stick in the media player carousel around forever (sorted by when you last used them), even after a reboot. If any app actually implemented the persistent behavior, you would be able to turn it off by swiping over the media player, pressing the little gear that appears under it, and turning on the option to "hide player when the media session has ended."

The media player has a new output-picker button in the top left, and when you tap on it, you get a pop-up card listing audio devices. Right now, this tends to list things like "Phone Speaker," "Wired headphones," and the names of any connected Bluetooth devices. Since this is all the button ever lists at the moment, it's not particularly useful.

Google's developer documents show Google Cast devices, like Google Home speakers and Chromecasts, popping up in this list, which would be incredible. The docs say, "By default, only local media routes are shown. If your app supports other media routes, such as remote playback you'll need to let the system know." "Remote Playback" here means Google Cast devices, with a "Google Home" and several other speakers popping up in the accompanying picture. So whether or not Google Home speakers appear in this list will be up to each individual app. So that will need to be updated.

For developers, the recommended way to get Google Cast speakers in the audio picker for your app is to include version 1.2.0 of the MediaRouter jetpack library and enable a few remote-playback flags. The problem is this version of the library is still in beta. That means—and this is probably going to be a running theme in this article—that from what I can tell, no apps support this Android 11 feature yet.

I think the particulars of how the new audio picker will work with Google Cast devices is a big deal, because the current Google Cast interface (accessible via the "cast" button inside an app) is probably the single worst interface shipping on a modern Android phone. It reminds me of the share-sheet problems that used to exist before Android 10. The Google Cast list in an app is built at runtime, so when you press the cast button, you first get a blank sheet, and then it slowly fills up as the app pings speakers on your network like it's taking attendance for a classroom. Not all the speakers show up at once, so the list jumps and shifts around as attendance is taken. It's common to see the speaker you want, go to tap on it, and exactly 1 millisecond before you touch the screen, the list updates and the wrong item shifts to the spot beneath your finger.

The list is also sorted alphabetically, not by something more useful like "last-used" or "most-commonly-used." It's also a mishmash of speakers and speaker groups, and there is no way to hide speakers you never start individually or flag certain list items as important. This is crazy, since when you make a speaker group, you'll most likely want to start the speaker group and never an individual speaker. For now, the list isn't even smart enough to put speaker groups at the top.

I really like the idea of the new media controls. Switching between apps with a quick horizontal swipe is handy. Most of the time, all I want to do is resume the last media I was playing, and having a list of my last few media sessions would be a super-easy way to do it. As someone who normally has a few media-player widgets on my home screen for easy startup, a persistent media player seems like an ideal feature. The problem right now is that nothing is actually persistent. No apps turn on persistent mode, so a lot of times you go looking for the media player and it's just... not there. It's pretty disappointing opening the Quick Settings expecting to use your favorite media app and for it to be missing. After a few missed connections, I just gave up trying to use the Quick Settings player. Without persistent mode, it's more-or-less identical to the old media notification, just with the cool multiplayer support.

Conversations and bubbles

Conversations getting their own section in the notification panel is part of a batch of enhancements around messaging notifications. Google's user research has told it that messaging notifications are the most important to people, and while they have been pinned to the top of the notification panel since Android 8, Android 11 brings more features that elevate them above normal notifications.

The biggest new feature is chat bubbles, which were introduced in Android 10 as a Developer Preview and are now live for apps in Android 11. Bubbles are virtually an exact copy of Facebook's old "Chat Heads" feature, and they put incoming messages in a floating chat window that can be minimized or replied to without leaving your current app.

Bubbles are a new level in the messaging notification-importance settings called "Priority." Long press on an incoming message in the notification panel, and you'll see a new "Priority" importance level next to "Default" and "Silent." Only messaging with the "Priority" flag will allow a bubble to spawn, and you'll see the person's profile picture appear in the status bar, instead of the app icon.

A welcome change from Android 10 to 11 is that notification-importance settings for messages are now per-contact and not just per app. So instead of flagging all Hangouts messages as important, you can now flag messages from a specific contact on Hangouts as important and flag that noisy group chat as unimportant.

Bubbles and individual contact-importance settings—Android 11's "Conversation features"—need specific support from apps to work. That means—you guessed it—not many apps support these features. I needed a beta version of Google Messages for this article. Supposedly Facebook supports conversation features, too.

Previously, floating-app features like Facebook's Chat Heads were dirty hacks of the Android APIs, and bubbles are the new, preferred way to make a floating app. Chat Heads used the System Alert Window API that was added all the way back in Android 1.0, which was originally meant for emergency pop-up alerts and system-crash windows. System Alert Windows weren't meant for third-party apps and had a number of security problems. The windows would draw overtop of everything, which broke Android's layering model, where the system UI's navigation buttons and status bar should always be the top-most items. It also wasn't possible to dismiss a system-alert window unless the window included a button to close it, and it was impossible to tell where a system-alert window was coming from unless it identified itself. All of these attributes opened the door to malware, where a malicious developer could make a full-screen, always-on-top ransomware message that locked you out of your phone and was impossible to close.

Google killed the System Alert Window API in 2017 for apps targeting Android 8.0 or higher, and now Bubbles is here as a viable replacement that solves many of the problems inherent in the old Alert Window. Bubbles are properly drawn underneath the status and system bar. They have a built-in mechanism for closing them (just drag them to a popup "x" button at the bottom of the screen). An app icon in the corner of the popup bubble makes the bubble attributable to an app, and the bubble still spawns a normal notification in the notification panel. There are also system-level permissions to block apps from making bubbles.

For now, bubbles are only for messaging apps, but if Google truly wants to replace the System Alert Window with a dedicated UI for floating apps, Bubbles will need to support different types of apps. It sounds like that's going to change in the future, though. On the Android Developers Backstage podcast on Bubbles, Google Product Manager Artur Tsurkan said, "Bubbles is a platform API that lets an application publish some sort of content... It lets you get back to some sort of task. In Android 11, it's going to be focused on conversations." To me, that sounds like an expansion of bubbles is coming in Android 12, and that would make sense since plenty of non-messaging apps have used bubbles. Chris Lacy's Link Bubble is probably the most famous example: a minimizable browser-in-a-bubble that was a great way to open links from an app. (Link Bubble was popular enough to get purchased by Brave Software, which turned it into the Brave Browser.) I could also imagine it being helpful to have a floating notepad or calculator, and even Google has experimented with bubbles for the phone app and Google Assistant.

Notification history

The last thing we'll talk about in the notification panel is also the last thing in the notification panel: a new button at the bottom labeled "history." You'll need to turn this on at first, but once you do, it will keep a running list of your dismissed notifications. The History page has two sections for notifications: "Recently dismissed" and "Last 24 hours," which work differently. Recently dismissed notifications are real notifications, in that tapping on them does whatever tapping on the real notification would have done. So you can instantly jump into a conversation or email directly from this screen.

The bottom "last 24 hours" notification section is dead—tapping on these won't do what a notification normally does, and instead, you'll be taken to the notification settings for that app. They are grouped together for easy parsing, though.

One-time and auto-revoking permissions

Permissions get a handful of new features. The biggest is a new one-time option that will show up for the microphone, camera, or location permissions. For these three permissions, you'll see three options in the popup now: the foreground-only "While using this app" option, the new "Only this time" option, and "Deny."

Allowing location use in the background has actually been banished from the permission popup completely. If an app really needs to track your location all the time, it can spawn a second popup to ask for the permission, but this still can't enable the feature. Instead it just links you to the settings where you can finally check the "Allow all the time" checkbox. Now that allowing background location is no longer part of the default most-obvious path for a user to take, it seems like this change really will reduce the number of apps getting background location. For the type of person that just mashes the "Allow" button so the app will work, background location still won't be allowed.

App permissions will also now auto-reset if an app hasn't been used for a few months. So if you install an app, grant it a bunch of permissions, and then leave it alone for months, all the permissions will automatically get flipped to "Deny," which is the default fresh-install state. The app will then need to re-request permissions when you open it again. This is basically a permission version of the app standby feature, which will block apps from running background services if you haven't opened them for some time.

If you have an app that runs in the background that you don't expect to use much but still want to keep the permissions around, there's also a new checkbox in each app's permission screen that will disable the auto-reset of permissions. Note that all of this auto-revoking stuff is only for apps that target Android 11 (API level 30) and up. For older apps that haven't been updated to support Android 11, they still get to keep permissions forever.

The new power menu and smart home controls

Android 11 features a completely revamped power menu—the menu that pops up when you long-press the power button—and there are so many buttons on it now, I really don't think "Power menu" is an accurate name for the screen anymore. Android 10's tiny four-button power menu has ballooned into a full-screen interface and is now a dumping ground for Google Pay cards, smart home controls, and the old power menu buttons. I don't really see how power, payments, and device controls are so related that they belong on the same screen together, but that's what Google is going with. It feels more like moving into a small space and needing to pack things in wherever they will fit.

And yes, this feature launched early, technically on Android 10, in a Pixel feature drop. Android 11 brings it to all devices, so it's making the review.

First up on the new power menu is Google Pay cards, a feature that shows a horizontally scrolling list of credit cards for tap and pay. You don't actually need to open Google Pay to use your default NFC card, (just slam your unlocked phone down on the reader and it will work), so this section is only really useful if you use more than one card and frequently switch between them. Google calls this section "Cards and Passes," but I think it only shows NFC-enabled cards—it certainly does not show everything in the Google Pay app. With the default NFC card being automatic, the only reason I ever open Google Pay is to scan a barcode loyalty card or gift card. It would be super handy if Android 11 showed these cards, but it does not.

The bottom section features customizable smart home controls, where you'll be able to control lights, thermostats, locks, and view camera feeds. By default, you'll see controls here from the Google Home app, but third-party apps can actually plug in to this screen and provide their own page of controls. Keep in mind that's their own page of controls. This screen is customizable, so it would be helpful if, like the Quick Settings, you could mix together controls from various apps, but instead each app gets its own page.

Your choices for controls are toggles, sliders, and buttons that open some other piece of UI, like a camera feed or thermostat control. It's simple. The controls are nice-looking, though, and it would be great if these were also widgets that we could add to the home screen.

Android 11's power menu is really strange. It's a full-screen interface that scrolls and has settings, so it feels like an app or any other screen of the OS, but because it's built on the power menu code, it acts like a popup menu. That means you can't see the status bar or open the notification panel while this screen is open. When you leave, the power interface doesn't show up in Recent Apps. The back button is also totally broken, and a lot of times I can't enter the settings for the power menu and then press back to return to the power menu. This "not a real interface" behavior all made sense when the power menu was a popup menu. It does not make sense when it's basically a smart home app.

I am not sure what Google was thinking when it made the customization screen, which is one of the most awkward checkbox UIs I have ever seen. You can enable and disable controls here and drag them around for the order, which all sounds fine. However, when you uncheck a control, it rockets to the bottom of the screen, and then the list re-sorts and makes every other control move up one spot. The controls are sorted left to right and wrap to a new line when they reach the edge of the screen, creating a two-column list. So when you remove a single control, everything in the left column moves to the right column and everything in the right column moves to the left, effectively scrambling the list. It's so crazy. Also occasionally your scroll position will follow an unchecked item as it shoots down to the unused section at the bottom of the list, and you'll lose your spot in the list. There is a gif of all this in the gallery, above.

It's hard to say how often this screen will actually appear on non-Google devices. Just about every OEM seems to agree the power button doesn't provide enough value as just a power button, and everyone has been adding some kind of extra functionality to it. Plenty of companies turn it into a user-configurable shortcut button, with options to launch an app, launch the Google Assistant, or, if you're Samsung, launch Bixby. Personally, using power as a Google Assistant launcher is still my favorite use for it, especially since Google Home doesn't support all of my devices. I guess the best-case scenario is that OEMs keep this screen as an option for people who want it.

Get better smart home support, Google

Using Google Home/Google Assistant as the provider for smart home controls isn't really ideal due to Google's relatively poor smart home device compatibility. For a long time, Google's smart home solution was exclusionary toward companies that competed with Nest, and while it seems like Google is slowly recovering from that, it still hasn't caught up to a great compatibility level. For instance, Nest doesn't have a lighting solution, so the light compatibility is excellent. Not only can you add the usual Wi-Fi compatible light bulbs; you can import lights from Z-Wave and Zigbee hubs like SmartThings. It feels like Google gave a best-effort to support lighting and added support for everything it had access to.

Nest does have a preferred door lock, though the "Nest x Yale Smart Lock," which was the first—and for a long time only—compatible door lock. Again, Google is slowly turning the corner on this and adding support for other Wi-Fi door locks, but it still hasn't gotten to the point where it can import locks from other smart home hubs. Camera support is rough—Nest sells cameras that have a monthly fee attached. Thermostat support is surprisingly good, with support for Nest's main competitors like Ecobee and Honeywell.

For me, a SmartThings user, it's annoying that the company can connect to SmartThings for lighting but refuses to add lock support through the open and fully compatible SmartThings API that the company is already using for lights. I have a regular Yale smart lock, not a Yale x Nest smart lock, and Google doesn't let me connect it, which is honestly pretty insulting. Google's lack of support for actual low-power smart home protocols, Zigbee and Z-Wave, seriously limits the company's smart home appeal. You can't just demand that everything has an expensive and power-hungry Wi-Fi connection. Connecting to the free and open smart home hub APIs is a great way to tack on support, but Google has been very hesitant to openly support everything.

Emoji 13.0

With Android 11 comes support for Unicode Emoji 13 and 117 new glyphs. There are 62 totally new emoji, plus 55 gender and skin tone variants. There's now a ninja emoji, "pinched fingers," a "smiling face with tear," and the Groucho Marx-inspired "disguised face" emoji. There are all sorts of inclusive options like a wedding combo of "person in tuxedo" and "person in veil" in all three supported genders (male/female/person), a gender-neutral "Mx Claus" Santa costume, "person feeding a baby," and a transgender flag.

Besides the Emoji 13 additions, Google is also using Android 11 to revamp most of its emoji art. Emojipedia has a full changelog and says "over 2,000 previously available emojis have updated designs." Google seems to have tweaked some of the shading and color rules used to create its emoji, resulting in a profusion of glyphs with slightly different appearances. The animal emoji have gotten the lion's share of the attention, with some designs rolling back to their Android 4.4 appearance, like the turtle and frog.

Project Mainline, Part 2—Even more modularity

Project Mainline, AKA "Google Play System Updates," were introduced in Android 10 as a major effort to make core system components of Android more modular and updatable. Mainline introduced a new "APEX" filetype specifically for system components, with the goal of shipping core Android code through the Play Store as easily as you ship an app update. Previously, Android's only shippable code block was the APK, a filetype originally designed for third-party apps. This came with all sorts of security restrictions and could only start up late in the boot-up process, so APEX was created with more powerful system components in mind. APEXes can only be created by Google or your device manufacturer, so they can be noticeably more powerful and house critical boot-up components like the app runtime.

Mainline isn't just a technical solution, it's also about making more parts of Android centrally distributed by Google, which involves negotiating with device manufacturers and getting them to all agree to ship the same block of code. Mainline modules eventually become mandatory to ship, so Mainline is actually a big collaboration with device manufacturers to make sure a single ecosystem-wide module meets everyone's needs. Not every Mainline module is an ultra-powerful APEX module—some are just APKs that are now Google-distributed Android code.

With Mainline now up and running, "What got modularized this time?" will be a major point of interest with each new Android release. Android 11 contains 10 totally new mainline modules and one module that increased in scope. This year, Google finally started keeping an official count of mainline modules on the source.android.com website. There are even official explanations of each module, which both makes me very happy and saves me oodles of work! First, let's shamelessly copy and paste Google's table with the new modules at the top.

Module name Package name Type Release introduced
adbd com.google.android.adbd APEX Android 11
CellBroadcast com.google.android.cellbroadcast APEX Android 11
IPsec/IKEv2 Library com.google.android.ipsec APEX Android 11
Media com.android.media APEX Android 10 (extractors, MediaSession API)
Android 11 (MediaParser API)
MediaProvider com.google.android.mediaprovider APK-in-APEX Android 11
NNAPI Runtime com.google.android.neuralnetworks APK Android 11
SDK Extensions com.android.sdkext APEX Android 11
Statsd com.google.android.os.statsd APEX Android 11
Telemetry Train Version Package com.google.mainline.telemetry APEX Android 11
Tethering com.google.android.tethering APK Android 11
Wi-Fi com.google.android.wifi.apex APEX Android 11
Captive Portal Login com.android.captiveportallogin APK Android 10
Conscrypt com.android.conscrypt APEX Android 10
DNS Resolver com.android.resolv APEX Android 10
DocumentsUI com.android.documentsui APK Android 10
ExtServices com.android.ext.services APEX (Android 11) Android 10
Media Codecs com.android.media.swcodec APEX Android 10
ModuleMetadata com.android.modulemetadata APK Android 10
Network Stack Permission Configuration com.android.networkstack.permissionconfig APK Android 10
Network Components com.android.networkstack APK Android 10
PermissionController com.android.permissioncontroller APK Android 10
Runtime com.android.runtime.release.apex APEX Android 10
Time Zone Data com.android.tzdata APEX Android 10

Next up: Explanations! We already covered all the Android 10 modules in the Android 10 review, so here's what the new modules do.

  • adbd—ADB, or the "Android Debug Bridge" is the command-line tool developers use to control an Android phone from a PC. You can view logs, install apps, send touch events to the screen, reboot the phone, and do just about anything. The extra "D" here is for "Daemon," meaning the background process, but this is the entire phone side of ADB. Google's page says "Modularizing adbd enables faster delivery of performance improvements, bug fixes, and features that haven't been backported to older versions of Android."
  • Cell broadcast—Cell broadcast is Android's emergency alert system, which will pop up for extreme weather, Amber alerts, or incoming ballistic missile impacts. Google says that making this modular will "streamline carrier testing and certification." There are all sorts of legal requirements around this working correctly, so you can imagine manufacturers just want a version of this that works and then they don't want to touch it.
  • IPsec/IKEv2 Library—This is the VPN module. It negotiates security for VPNs and "Interworking Wireless LAN (IWLAN)," which is when you offload traffic meant for the cellular network to Wi-Fi. Making this updatable means "Ecosystem consistency" and "Quick fixes for security and interoperability issues."
  • Media—The Media module arrived in Android 10, and in Android 11, it expands to include the "MediaParser" API. MediaParser reads media metadata and extracts thumbnails. The media stack is a huge vector for security bugs, and the name "Stagefright" became infamous in 2015 after a series of vulnerabilities.
  • MediaProvider—I know this sounds a lot like the previous module, but this is actually about reading files on your phone's storage and building an index for Android's MediaStore, the shared list of audio, video, and images that apps have access to. With Scoped Storage—limiting app storage access—creating all sorts of changes in Android 10 and Android 11, being able to update this sounds like a good idea.
  • NNAPI Runtime—This is the runtime for Android's Neural Networking API.
  • SDK Extensions—Android offers new APIs to apps through the "SDK level" (or API level) system. Each version of Android has its own SDK level (Android 11 is SDK level 30) and apps get to target a certain SDK level of Android, indicating they're aware of and compatible with the restrictions and features of that release. Typically the SDK level goes up +1 per release. SDK Extensions is a new thing that will apparently ship new developer APIs through the Play Store. We've never seen this before, but apparently devices will now have an "extension SDK level," which sounds like a secondary API level that apps can query. I asked about this in our yearly Android interview, and it sounds like the plan is to ship a new one of these when Android 12 comes out.
  • Statsd—The telemetry module. When something crashes in the core Android OS, this sends an anonymous bug report to Google, provided you have the right check boxes selected.
  • Telemetry Train Version Package—The docs say this ambitious module "doesn’t contain active code and has no functionality on its own." It sounds like it's exactly what it says on the tin: a version number for the telemetry train, which is "a set of metrics-related modules." Google Play uses this to check for updates to "metrics-related modules" and to display the security patch version.
  • Tethering—This one is pretty self-explanatory: it's for tethering. Sharing your cellular connection over Wi-Fi, USB, Bluetooth, or (new for Android 11) Ethernet (usually via a USB dongle).
  • Wi-Fi—Wi-Fi. The IEEE 802.11 standard. Internet and networking without those pesky Ethernet cables. It's cool and now it's updatable.

Google's documents point out over and over again the same benefits for modularity: "End users get a consistent experience," "app developers get reduced platform fragmentation," "OEMs can fulfill carrier requirements while also reducing costs," and "platform developers can patch bugs and deploy new features." That's really the best sales pitch you can give for Mainline. These get released on a monthly cadence, just like security updates, and you can find what version you're on in "Settings -> About Phone -> Android Version." There you'll see a "Google Play System Update" version, which should almost always read back the current month. You can even tap on it to check for an update.

According to Dave Burke, Android's head of engineering, Google is just getting started with Mainline modules: "With Mainline we've started with the less exciting modules at the beginning to prove that all of that infrastructure before you go for the big ones like this." "Like this" was a reference to an in-development Linux kernel module we were asking about. Imagine updating Android's Linux kernel through the Play Store! Someday it might happen, so expect a great deal of mainline talk in the future.

Google's Scoped Storage brinkmanship

Google did some major saber-rattling about the future of storage during the run-up to Android 10. The "Scoped Storage" feature was introduced as a lockdown of Android's shared storage, which previously had been an all-or-nothing free for all. Scoped Storage would restrict apps to their own isolated storage sandboxes, improving privacy and security. Scoped Storage is a real problem for apps that rely on native libraries, though, and Google didn't really consider the "file manager" or "backup app" use case. Google force-enabled Scoped Storage for all apps on the Android 10 beta and broke a ton of apps and sent developers into a panic.

Google only ever said it was enabling scoped storage during the Android 10 Beta to "gather feedback" and never published an original rollout timeline, but after public outcry, Google announced scoped storage would only be enabled for apps that target Android 10 (so not older apps), and even then, Android 10 apps could opt out of the feature. It promised the lockdown would really happen in Android 11, though. Google's blog post at the time threatened: "Scoped Storage will be required in next year’s major platform release for all apps, independent of target SDK level, so we recommend you add support to your app well in advance."

Making a change "independent of target SDK level" would be extremely out of character for Google, since such a move would break tons of legacy apps, and Google usually goes to great pains to maintain legacy support. This is the entire point of the "Target SDK" system, after all. Apps can say what version of Android they are coded for, and the system won't apply newer features and restrictions to it, allowing older apps to still run. Basically every Android change rolls out via the "target SDK" system, and Google doesn't enforce any Android changes on "all apps." Ending the shared storage free for all sounded like a good sanitation move to push apps toward in the future, but there was no critical emergency that justified immediately killing legacy apps in a storage Armageddon. Still, Google's public stance was that this was happening, which, we wrote in the Android 10 review, we had "a hard time believing."

Welp, Android 11 is here, and yeah, it's not happening. Sanity has prevailed, and Scoped Storage, like every other Android change ever, is rolled out via the target SDK system and doesn't affect legacy apps. The opt-out is gone, though, so targeting Android 11 means dealing with storage restrictions. The good news is that there are new APIs designed for file managers and apps that need third-party libraries.

For file managers and backup apps Google has a new permission called "Files and Media Access" that will grant an app access to all shared files. Since this is considered a sensitive "Special app access" permission now, so it's not a runtime permission, you have to dig into the settings to enable it. Google will also require a manual review for apps on the Play Store that use this. For third-party libraries, there's a new File Path API that should allow developers to call the right files in java, C, and C++.

Keyboard autofill gets a big upgrade

One of my favorite new features is that autofill has now merged with the keyboard so that autofill suggestions show up in the autocorrect bar above the keyboard keys, just like on iOS. Depending on what text field is active, this will intelligently display the entire suite of autofill suggestions: your name, address, phone numbers, usernames, passwords, and even credit card numbers, all in a little row of buttons above the keyboard. There are even some non-autofill suggestions that are really handy, like the clipboard contents or SMS verification codes. Since this is part of the autofill API, suggestions from password managers, like 1Password, can pop up here, too.

Another keyboard feature in Android 11, which has apparently been a big request of developers, is the ability to animate their apps alongside the keyboard. When the onscreen keyboard pops up, the area an app gets to draw in suddenly shrinks, and the app needs to resize itself. In the past, apps didn't get any information about the keyboard location as it is sliding up from the bottom of the screen, so the only thing they could do is snap from full screen to the smaller size. There was no animation at all, so—barring a few hacks that were out there—the transition looked janky. Android 11 provides information on the keyboard's location during the animation, so apps can build a transition animation that syncs up with the moving keyboard. Apps can also take control of the keyboard location and slowly slide it up alongside the user's touch input, if they want.

The keyboard is a sensitive piece of the interface since it's used to type in passwords, credit card numbers, and other sensitive data, so Google couldn't just make the keyboard visible to apps. Depending on which method apps want to use, they'll get either the location of the keyboard during the animation or control over the keyboard window location but not what's actually being typed into the keyboard, so apps can animate along with the keyboard without being a keylogger. The ability to synchronize animations between apps like this was only added in Android 9, and you saw a whole lot of it in Android 10's gesture navigation system, where apps can zoom in and out of the launcher and Recent apps. Hopefully we'll see more of it soon.

Grab bag

Welcome to the Grab Bag, which boils down to a list of changes I just don't have much to say about.

  • There's a new screen recorder feature in the Quick Settings, which has been absolutely awesome for this review. Just press the "screen record" button and, after a three-second countdown, you'll start recording everything. Options include showing screen touches with an agreeable circle icon and recording microphone audio for narration. Videos end up in /Movies.
  • Scrolling screenshots were promised and then cut for Android 11, but we did get a new screenshot UI, in the form of a little thumbnail in the bottom-left corner. Just like the notification, it gives you quick shortcuts to "Share" and "Edit." This means the notification, by the way, is dead.
  • On the Pixel 4 at least, there's a new Ethernet tethering option in the hotspot settings. You can plug in a USB Ethernet dongle to the bottom of your phone and turn your phone into a cellular modem.
  • Album art on the lock screen is dead.
  • Dark mode now has settings for a user-set schedule or syncing with sundown and sun up.
  • New in the Wi-Fi settings: it's now possible to have Android remember a Wi-Fi password but not automatically connect to the access point whenever it is in range. Just press the gear next to a connected Wi-Fi network and uncheck the new "Auto-connect" option. Sadly, there is not an equivalent set of options for Bluetooth. You still have to delete the device if you don't want it to auto-pair.
  • For Pixel-specific changes: App suggestions have moved from the Recent App screen to the home screen.
  • Wireless debugging can now be set up with a QR code, which is nice. Before you had to type in an IP address via command line.
  • Android 11 adds Wireless Android Auto to every device, which previously had limited device compatibility. You'll still need a car that supports wireless (not just wired) Android Auto, which currently is very rare.
  • You can pin apps to the share sheet now. Just long-press an app for the option.
  • The Do Not Disturb settings have been rearranged but are mostly the same. The top option is now "People," which, besides the usual setting of letting starred contacts punch through the silent mode, lets you promote conversations, too.
  • Android 11 features a new "Identity Credential API" that implements the ISO 18013-5 spec for a digital driver's license. This is kind of like the COVID-19 notification situation, where Google makes the APIs and it's up to states and other governments to support the API by developing their own app. This plan really didn't work for COVID notifications, with only seven states supporting the API as of September. How many governments will support digital driver's licenses? There isn't really an alternative to this situation for government IDs, I'm just not holding my breath for support.

Building on Android 10, with a few upgrades of its own

Apologies for the startlingly short (by comparison, at least) review, but there really isn't much else in Android 11. The Year of COVID has been tough for everyone, and Google is no exception. Employees were sent home in March and still haven't returned, a move that set the Android team's schedule back a month. It's probably related that at least one high-profile feature didn't make the cut: scrolling screenshot support, which was promised for Android 11 at last year's Google I/O.

In addition to the tougher development situation, Android 10 was a huge release, so it's natural that Android 11 would be a bit smaller. In fact, a lot of the Android 11 features are actually followups to Android 10. Bubbles were introduced in Android 10 as a dev preview, and now they are production-ready. Scoped Storage was introduced in Android 10, and now the opt-out flag has been removed for apps targeting Android 11.

Getting Android 11 quickly isn't going to be that much of a change, since so many features require app support to work. The media player isn't permanent unless apps are updated for it. Chromecast support in the media player sounds like it will be amazing, but apps need to be updated for it. Bubbles and the new conversation settings don't work unless apps are updated for them. You'll probably need a new car for Wireless Android Auto.

Still, there are some features you can take advantage of today. The new keyboard autofill options are very nice, as is the screen recorder. You'll get new emojis, the updated permissions system, the smart home controls, more dark mode options, and a grab bag of other improvements. Updates are always recommended, but Android 11 doesn't offer a single killer new feature, though.

The good

  • Easier paste options on the keyboard are awesome.
  • The screen recorder is just perfect.
  • One-time permissions are a great option for many apps. I also like seeing the more invasive permissions (like always-on location) buried in the settings.
  • The much-requested Dark mode scheduling for sun up and sundown is finally here.
  • Even more Mainline modules mean less reliance on device manufacturer updates.

The bad

  • The new power menu is all sorts of weird. It looks like an app, but because it's actually a big popup menu it doesn't show up in Recent Apps, and you can't use the notification panel when it's open.
  • Google Home's smart home device support is bad.
  • You can't add barcode-driven Google Pay cards to the power menu (loyalty and gift cards), but, as the only cards that don't auto-activate from NFC, these are the ones you actually need quick access to.

The ugly

  • Who broke album art on the lock screen?

Let's block ads! (Why?)



"Review" - Google News
September 21, 2020 at 10:30PM
https://ift.tt/32OF8Dn

Android 11—The Ars Technica Review - Ars Technica
"Review" - Google News
https://ift.tt/2YqLwiz
https://ift.tt/3c9nRHD

Bagikan Berita Ini

0 Response to "Android 11—The Ars Technica Review - Ars Technica"

Post a Comment

Powered by Blogger.