特朗普距肥胖只差1斤 医生：看着胖不一定不健康

Welcome to Android API level 31, aka Android 12. Google's latest OS had one of the weirdest rollouts ever. An anticlimactic source code release happened in the beginning of?October,?but if you wanted to run Android 12 on a device officially, you had to wait until Pixel 6 launch day, when Google also shipped Android 12 out to older Pixel devices.

In a way, this was appropriate for Android 12: a Pixel-centric release for what feels like a Google-centric OS. Android 12 rolls out Material You, a design style that Google says will someday follow you across the company's ecosystem. It's a Google-centric design that will probably not please a lot of big brands, but it looks great.

Besides Material You, there are also a million features to cover, like a new file system, a fresher and more upgradable Linux kernel, and notification changes. Let's dive in.

Material You—Google's beautiful, next-gen UI

A rainbow of Android colors. The clock and button colors were automatically generated from the wallpaper.

Credit: Ron Amadeo

The first thing you'll notice when you boot up Android 12 is the new design language, which Google calls "Material You." Google has previously resisted giving version numbers to its Material Design styles, but with some documentation calling this "Material Design 3," the history is clear.?Google introduced the first "Material Design" in Android 5.0, which brought bold colors and white card backgrounds to Android (and to the rest of Google). Google transitioned to Material Design 2 in 2018 with Android 9, and while that brought plenty of color customization for brands, Google went to an all-white theme?that was almost completely devoid of color. The lack of color paved the way for a dark mode in 2019's Android 10, which allowed for an easy change from all white to all dark.

For Android 12, Google is bringing back the color it stripped out. This is the next generation of Material Design, and it's automatically color-coordinated in a way no other OS has been before. Material You isn't just a set of design principles; it's also an algorithm-powered color system (codenamed "Monet") that looks at your home-screen wallpaper and generates a palette of colors for the buttons, backgrounds, and text of the entire OS. So pick a primarily red wallpaper, and you'll get shades of red all over Android.

The exact color picks are up to Google's algorithmic magic, but generally, Android 12 picks a main hue from the wallpaper and pumps out several variations by changing the brightness and saturation. So if you pick a primarily blue wallpaper, by default you'll get something like a bright blue, a darker, deeply saturated blue, a darker blue-gray, and then a background color—either a nearly "white blue" for light mode backgrounds or a nearly "black blue" for dark mode wallpaper.

The Android 12 Easter Egg gives developers some paint chips to decorate with.

Credit: Ron Amadeo

This year's Easter Egg for Android 12 illustrates how it works, showing a full sheet of color swatches available to apps for a given wallpaper setup. There are two neutral colors, two accent colors that match your wallpaper, and then one complementary color. All five of these hues are available in the full range of lightnesses.

To avoid contrast issues, Google pulls colors out of your wallpaper and maps them to the CIELAB color space. Instead of something like RGB values for red, green, and blue, CIELAB gives you an "L"?for perceptual lightness (from black to white), and then, using positive or negative numbers, the "A" value goes from cyan to magenta and the "B" value goes from blue to yellow. Having a lightness value at the ready will let you compute a contrast ratio in software. So for any two combinations of colors, Google can guarantee they will remain readable—and remain within defined contrast accessibility standards for low-vision users.

The algorithmic color picking sounds a lot like Android 5's "Palette" API that Google experimented with back in 2014. Palette would extract colors from images and apply them to the UI, and Android 12's Monet is a ground-up reworking of the same idea. While Palette never lived up to its original promise and wasn't used much, dynamic colors in Android 12 are being rolled out everywhere. Even in the pre-release phase, it was clear the new system would live up to the hype.

Everything in Android 12 is tinted with your wallpaper colors. You'll find wallpaper tones in the?quick settings, notification panel, settings, app icons, and more. Even many of the neutral-looking dark grays or whites tend to ever so slightly live in the same hue family as the wallpaper color scheme. It's tough to find examples of pure white or pure black anywhere in the OS, with the one exception being the background of the notification panel (this is for a cool effect we'll talk about later).

Material You isn't just for the OS. Apps can plug into the Material You color-changing palettes, too, so even Gmail and the Play Store can be color-coordinated with your wallpaper. Unlike the glacially slow rollout of dark mode across Google's app ecosystem, a number of Google apps already support Material You. The Calculator, Clock, keyboard, Gmail, Chrome, Play Store, YouTube Music, Google Calendar, Drive, Keep, Files, and more all pick up on the dynamic colors.

Google has the luxury of not caring too much about other branding on Android, and Material You once again falls into Google-centric habits.?When Google rolled out Material Design 2 in Android 9, it added considerably more customizability at the behest of other brands. Google said it was reacting to feedback?that developers "didn't always see Material Design as flexible enough" and that "products from different brands looked too similar." Material You turns over color control to users, though, and I can't imagine that many big brands, which rely a lot on colors for branding, will be onboard. Would Facebook ever allow a green Facebook app? Would Spotify ever allow a blue Spotify app? I don't think so. Hopefully smaller apps adopt the feature, though.

Material You also isn't just for Android. The new design was introduced at Google I/O by Google's VP of Design, Matias Duarte, and while Duarte started at Android, he's now in charge of Google's overarching "Design" division. At I/O, Duarte said?Material You is coming to Pixel devices and "all your favorite Google Apps" first. Eventually, he says the design will roll out across "the web, Chrome OS, Wearables, smart displays, and all of Google's products."

It could take years, but eventually, this design should be all over Google. Duarte says that someday, the color choices you make with your phone wallpaper "can travel with your account, across every app and every device." So, in this perfect future universe, imagine changing your phone wallpaper to something blue and seeing your Google smart display, web apps, and smartwatch switch over to blue, too. Wild.

When you pick a new wallpaper, you'll have a color option applied, and the wallpaper settings will close. You aren't limited to this first color option, though. If you go?back?into wallpaper settings, you'll be able to pick from four color palette options and a (surprisingly limited) collection of "basic" colors. The default color options seem to go with a matching color, but the extra color settings will usually offer some striking complementary colors, which look really good.

It is extremely fun to flip through wallpapers and see what color combinations Android comes up with. I just wish it was easier. The above process is super clunky: you open the wallpaper settings, pick a wallpaper, the wallpaper settings close, you open the wallpaper settings again, and then you can pick a color. It would be nice if we could do this all in one trip to the wallpaper settings. It would also be nice if there was more of a preview of what the color options will be for each wallpaper.?This color changing comes with some lengthy load times, too, and people with automatic wallpaper switchers have found that you can actually crash a game if it switches in the background.

Another Material You option is "themed icons" for the home screen. This will swap out the normal, multi-colored Android icons for monochrome ones that match the rest of your theme. Currently, this setting is labeled "Beta" on Pixel devices.

The themed icons are kind of weird. First, they remove easy user recognition by color. This isn't a huge deal, as Google has been working toward this vision since it started pushing indistinguishable rainbow icons. Compared to the obnoxious multi-colored Google icons with no individuality, turning off all the color is like turning down the noise, and I like it.

A much weirder component of this change is that the home-screen icons are monochrome, but the app drawer icons are not. So you have two sets of icons to remember and recognize, and it would make way more sense if all the icons, everywhere—in the app drawer and on various app settings screens—all matched.

The third issue is the usual Android issue: not many apps support these themed icons, so while all the Google ones look nice next to each other, if you add many third-party icons, you'll get a messy mix of colored and monochrome icons.

The feature feels like an incredible shout-out to the modding community over at sites like XDA, though. Android modders have been doing themed icons for years, with icon packs on third-party launchers. Google is completely reinventing the wheel here, but it's funny that we're back to the consistency goals that the modding community has been chasing down for over a decade. If there's anything to learn from the modding community, it's that voluntary consistency will never work! If individual developers all followed the rules, we wouldn't need icon packs in the first place. You've got to let users force this on all apps if you actually want it to happen.

The other interesting home-screen color effect has to do with widgets, which don't use the accent color (and therefore won't match your icons) but instead dynamically color themselves based on the wallpaper directly behind them. You can actually move widgets around the screen and see them change color.

The most amazing thing about Material You is that it somehow, always, 100 percent of the time, works. The color combinations look great and never have a contrast issue.?I have maliciously tried to break this by feeding the system crazy wallpapers like fully transparent PNGs, rainbow wallpapers, or wallpapers that aim to cause a contrast issue, and Material You always worked. The only time I've seen even a hint of a system issue is when I eyedropped an accent color from a previous screenshot and set that color as my wallpaper. Android 12 responded by dimming the wallpaper slightly so that everything was still readable. The worst thing you can say about any color combination is that it's boring, but you can always jump into the wallpaper settings again and pick a more vibrant color combination.

The color system in Android 12 works unbelievably well. It's so much fun to change to a new wallpaper and see what color options will pop up, and I think it's going to be one of Android's most popular, easily marketed features. I think it will also lead to more demand for apps that can automatically change your wallpaper so you can get a fresh phone look every day.

The idea of a system that automatically themes itself based on your wallpaper, at least to the degree that Android 12 does, sounds like a pipe dream that might be pitched by a designer only concerned about the limited world of their mockups. One can imagine the skepticism: "There would be so many edge cases! What if the color combinations look ugly or have contrast issues? It will never work!" Plus, imagine being a designer and then told you have to be ok with elements being?any color. It sounds terrifying.?It's an incredible accomplishment to have the guts to design something like Material You's dynamic color system, to actually make it work, and to ship it out to millions (and someday billions) of people.?Now that Google has blazed the trail for dynamic color, this is something I expect most other OS vendors will copy over the next few years.

For journalist and developer types who are regularly producing "example" Android materials, Material You also puts us in an interesting predicament: nothing in Android 12 really has a canonical color. Usually, I strive to take uncustomized?"neutral" screenshots of the defaults, but that's really not possible here. The colors in this article have to?be based on whatever wallpaper I have at the time, but unless two users have the same wallpaper, no two versions of Android 12 will look the same.

Notification panel—Big buttons, a sweet opening animation, and the return of panels

Besides the new color system of Material You, every square inch of Android 12 has been polished. The new design language is very round, with deeply rounded corners on just about everything. This makes much more sense when you look at the design of Android phone hardware—the screens all have similarly rounded corners. Android 12 is designed to match hardware like this, and some parts of the UI actually key off of the hardware corner radius.

The notification panel pulldown is a good example of this hardware-inspired software design, and it's one of the slickest new animations. When you pull down the notification panel from the top of the screen, you start moving a black background with the same shape as the bezel on the top of the phone. On an OLED phone, the blacks are so black that, for a second, it looks like you're expanding the phone bezel itself, since the display corner radii stay consistent.?The notification panel has the only instance of pure black in Android 12, presumably so Google can really sell this effect on an OLED display. It's a great example of the attention to detail that is all over Android 12.

Once you get the notification panel open, you'll see a million differences. Starting from the top, Google killed Android 11's weird double status bar layout, which had the time in a top black bar and the date and the status icons in what was effectively a white bar below that. Android 12 skips the time (which is visible in every other interface) and packs everything into a single line, which looks a lot better.

That mostly empty top black bar in Android 11 was actually added all the way back in Android 9, along with official notch support, so I guess it's a spacer to stay away from any notch or camera hole truncation. If you have a huge, dated iPhone-style notch, I could see there not being enough space in Android 12 to show all your status icons on the first notification screen. When you pull down again and expand the quick settings, that big black spacer bar shows up again, pushing the status bar down a level, where a notched phone would have more space.

The quick settings are much bigger in Android 12, and while you only get four of them on the main notification screen, you get names next to each one. I could see people being disappointed with the more limited number, but the names probably help for people who have not memorized a bunch of esoteric symbols. (That circle with a minus in the middle is, uh, do not disturb? I think?) When expanded, you get to see eight quick settings compared to Android 11's six, so it's somewhat of a wash for the "more buttons" crowd.

The semi-permanent media player from Android 11 is still here, just with a slick coat of Material You color-changing paint. Google has also scrapped the notification-type labels like "conversations" and "silent," making the panel a little denser.

A new surprise is a software power button in the expanded quick settings; it brings up the power menu. That hardware power button on the side of your phone is prime real estate, and while a single press to turn the phone screen on and off is kind of non-negotiable, should long-pressing it really open the power menu? Normal smartphone usage doesn't ever require accessing the power menu, so you can understand the argument that quick, global access to the power menu via long-pressing the power button doesn't make sense.

In Android 12, the button is freed up (thanks to the software power button), and long-pressing it brings up the Google Assistant. In Android 11, this brought up a combo screen featuring the power menu, Google Pay, and smart home controls. Google Pay and smart home controls now have quick settings tiles instead. I like the idea of downgrading both services to optional tiles, since there's no reason to open Google Pay if you use a single credit card (just slap your phone on the reader while it's unlocked on any screen), and you might not have a smart home or might not care about Google's smart home interface.

In several?versions?of?Android?now, Google has been flip-flopping back and forth on whether a quick settings button should be a toggle, open an app, or open a floating panel. In Android versions 9 to 11, everything was simplified into a toggle. In Android 12, we're back to a mix of toggles, apps, and panels, with the latter two indicated by a right-facing caret. Internet and Nearby Share will both open a bottom panel with some controls, Screen Recorder will open a?top?panel, and Device Controls, GPay, and Alarm will open full-screen apps.

The "Internet" panel is new and combines both the "Wi-Fi" and "Mobile Data" buttons. The panel will show you other available Wi-Fi networks, and it will let you toggle both Wi-Fi and Data on and off. This panel stuff is all a throwback to Android 8.0, and it's strange that we don't have a Bluetooth panel, since there was one back in the 8.0 days. Toggling Bluetooth and then seeing a list of nearby devices would be handy. One thing the Android 8.0 release got right with the Quick Settings panels was that these opened up atop the quick settings, so your finger was in the right area for the controls. Now, plenty of buttons at the top of the screen open up controls at the bottom of the screen; it requires a lot of movement.

The GKI—Android gets closer to Linux than ever

How Linux gets to a phone: the Linux LTS kernel gets forked by Google for the Android Common Kernel, then Android Common gets forked by an SoC vendor for each chip, then the SoC gets forked again by a device manufacturer.

Credit: Google

Android is a Linux-based OS, but the way the Linux kernel gets to Android is traditionally a lengthy and convoluted process. Basically, there are forks upon forks. Google forks the Linux LTS kernel into the "Android Common kernel," which traditionally includes changes for phone call support and other Android-specific things like wakelocks (apps get to keep the system awake). Android Common then gets forked by your SoC vendor—like Qualcomm, Samsung, or MediaTek—and gains chip-specific hardware support. The SoC kernel gets forked again, this time for each individual device with more specific hardware support, and?that kernel, three forks removed from Linux, is what ships to consumers.

The result is a hot mess of an Android kernel. By the time a kernel gets to consumers, it's running as much as 50 percent out-of-tree code compared to mainline Linux, and the kernel is usually two years old. Every month, kernel security patches need to be ported down through this entire process, and as Android VP of Engineering Dave Burke told us, around 40 percent of Android's security vulnerabilities come from this kernel process. Google actually has an entire public page detailing "the costs of fragmentation" of the kernel, outlining the difficulties fragmentation causes with regard to security fixes, upstreaming, and Android OS development.

Android 12 is out to fix kernel fragmentation with the "Generic Kernel Image," or GKI, which will cut the number of forks between the Linux kernel and Android down from three to one. The GKI will be a single Android version of the Linux kernel, made by Google, shipping in actual devices. The GKI has so much in common with Google's other Android modularization efforts. If you recall our many, many talks about Project Treble,?that project created a stable interface between the Android OS and hardware support, leading to the creation of the GSI, or Generic System Image, a version of Android that can run on all devices. The GSI doesn't actually make it out to consumers, due, as usual, to the original sin of the Android ecosystem: allowing manufacturers to change stuff. Shipping the GSI would mean shipping stock Android, and we can't have that.

Also in the GKI's family tree is Project Mainline. Mainline modularized core Android components for easier updating through the Play Store (thanks to the more powerful "APEX" file type). The GKI is basically the same story but for the Linux kernel. Google calls up the entire Galactic Senate of the Android ecosystem and asks, "Do you guys really need to change all this?" The features that come back with "No" get standardized. For everything else, Google builds a modular system that vendors can plug into and pushes partners to upstream features.

Google wants all hardware-specific code out of Android Generic Kernel and into all the new "Vendor Modules" that hardware companies can create. Just like Treble, there is now a "Kernel Module Interface" (or "KMI") that vendor modules can plug into, and there's now a Google side of the KMI and a vendor side. Google's side of the KMI has its own module system, too. Google wants any out-of-tree code in new GKI modules, with the Generic Kernel making only the bare minimum of changes to the Linux kernel and adding hooks for the module systems.?Vendors can plug their drivers into the kernel using this module system, and—as long as Google doesn't break the?application binary interface (ABI)—Google can update the kernel across devices without a vendor's help.

Google software engineer?Todd Kjos told the Linux Plumbers Conference, "We want to be as close to upstream as we possibly can" for the Android Generic Kernel. Starting in 2023, Google also wants to take an "upstream first" development model for kernel features, where it will work with the Linux community to get new Android features in the kernel before immediately going the forking route.

Starting with Android 12, the GKI will actually ship to consumers and be used in a commercial Android phone. This is for new Android 12 phones only and not devices that are upgrading to Android 12. So the Pixel 6 is the world's first GKI phone.

This plan already seems to be working. The current Android fork-a-thon includes phones typically shipping with a Linux kernel that is two years old. Meanwhile, the Pixel 6 ships with kernel 5.10, which is just under a year old. For its first swing at this, Google cut the age of an Android Linux kernel in half. As for non-Pixels, any new device that ships with Android 12 and kernel 5.10 or higher is required to ship the GKI.

Play Store kernel updates?

Google sounds like it wants to ship even newer kernels in the future, too. Google's kernel fragmentation page cites the age of a typical Android kernel as a major problem for upstreaming features. When you're doing all your development work on a two-year-old kernel, it's hard to merge that with the current kernel code, which also includes two years' worth of changes. Starting in 2023, Google hopes to have caught up enough to start taking an "upstream first" approach to feature development in the kernel. Google wants to work with the Linux community to make sure new Android features land in the Linux kernel, rather than just defaulting to more fork work.

Google's GKI page also points out that the fragmented, difficult-to-update Android Common Kernel creates plenty of work for the Android OS development team. Android devices almost never jump major kernel versions—even if an Android device updates from Android 10 to Android 11, the device will still have the Linux kernel it launched with for Android 10 (plus some LTS security fixes). This gets worse with low- and mid-range SoCs, which get one major kernel version and can ship in new devices for several years. Because Google wants to support devices for several years, the frozen-in-time kernels mean every Android version has to support multiple kernels. This gets complicated so, so fast. To quote Google's GKI page, "Android 10 supports 3.18, 4.4, 4.9, 4.14, and 4.19 kernels, which in some cases haven't been enhanced with new features since Android 8 in 2017." That's five versions of Linux kernels.

According to the page, one of Google's goals with the GKI release is to "reduce cost of updating major kernel version for devices." Google is actually working toward devices that jump major kernel versions, which, someday, could make Android development a lot easier. In the future, Google wants to "maintain only one GKI kernel binary per architecture by updating kernel versions with a clear process for upgrading."?For now, though, Android 12 still needs to support devices on old kernels and devices on the new GKI. Unless Google wants to dramatically cut off update support for older devices, I can't imagine kernel uniformity being anything less than a five-year process.

The first step to making any of this work is getting a kernel update system up and running. Currently, devices can update minor LTS kernel versions through the monthly security OTA updates, but OTA updates are unnecessarily slow, full of roadblocks, and need the cooperation of your device manufacturer. Google is working on a much better system: Linux kernel updates through the Play Store, via a Project Mainline module. This would make updating the kernel as easy as updating an app.

We're not sure when kernel updates are happening, but since the Pixel 6 is the first GKI device, we'll keep a close eye on it in case it gets any Play Store kernel updates. Breaking free of monthly OTA updates also means the kernel could be updated faster than monthly.?On the Linux side of things, LTS releases happen weekly, if Google wants to keep up with all that. If nothing else, an emergency patch could probably happen faster than normal.

Widgets—Newer, prettier, and not just for the home screen anymore

Android has had home-screen widgets since the dawn of time (well, OK, since 2008). But with iOS's recent discovery of the feature in 2020, the time has come for a refresh. Material You has splashed paint all over the widgets of many apps, and Google seems to be constantly rolling out refreshes for various app widgets.

The widgets look nice, and they occasionally have wacky designs, like a set of five buttons in what I can only describe as a flower layout. Some widgets, like Google Search's weather app, have several layouts they automatically switch to depending on how you size them. A small widget shows the current, high, and low temperature, bigger versions can add an hourly forecast, and an even bigger version can display the next two days of weather. It's nice.

Android 12 still doesn't fix something I've been concerned with for years: all of Android's widgets still feel gigantic. They all seem designed for a tablet screen, where you can fit several widgets and icons on a big 10-inch display. For a phone, however, you'll be lucky if you can fit two of Google's widgets on a screen. Nearly all the third-party widgets seem to understand this and take a more zoomed-out approach to the UI. Google, on the other hand, still makes everything take up an incredible amount of space. The Jitterbug-style overwhelming bigness of UI elements is a problem I have with most of Google's default sizing (which thankfully is configurable via the "Display" settings and therefore not worth complaining about too much). But you really feel it on configurable areas like the home screen.

One of the nicest new features is dynamic corner radiuses. This is going to be such a big deal for people who want their home screens to look consistent. With the first launch of Material Design in Android 5.0 Lollipop, the recommendation was that your widgets should have square corners. At some point after that, Android's design style shifted, and the recommendation became rounded corners. Every app designed its widget at different times, so they all come from different design eras. The result is chaos: tons of differently radius-ed widgets living next to each other on the home screen, looking completely terrible.

Android 12 sets out to fix this with system-adjustable widget corners! Instead of just baking a shape into a background PNG or the XML, Android 12 can now pass a radius value to the app. This means that all widgets (that are updated for Android 12) can have a standard shape. Besides a background radius, there is also an inner radius that developers can use for secondary views inside a widget. Device manufacturers can actually change these values at a system level, so compatible widgets should match the Material You radius on Pixel phones and also match whatever unnecessary changes Samsung makes when it rolls out a skinned version of Android 12.

Some third-party home-screen replacements, like Nova Launcher, have been able to forcibly mask widgets so they have matching radiuses (but with no developer support) that could lead to cropped controls. Google now recommends developers allow for some missing corner pixels.

Widgets are also getting a new "reconfigure" button, giving users an easy way to access a widget's options. Previously, long-pressing a widget would make a resizing UI pop up, and now this UI will also have a reconfigure button in the bottom-right corner. Previously, there really wasn't a good way to edit an existing widget. Usually, widget editing would?involve something like placing the widget, opening the app, going into the main app settings, finding a heading for "widgets," and then tapping on the listing for the widget you just put down. Now, the button can link directly to the widget settings activity.

Google is also making it easier for widgets to provide stateful controls, like on/off switches, checkboxes, and radio buttons. You might recall things like the Google Keep widget showing a checkbox image, but those were never functional and only ever launched the bigger app. Now, you can actually work these controls directly from the widget.

Widgets are now the remote content API?!

One of the really interesting additions to Android 12 is the ability for the widget API to be used in more places than the home screen. If you've been following our Android deep dives for a while, then you might remember an Android 9 API called "App Slices." Google wanted "one reusable API for remote app content in Android," and it wanted app slices to be used for home-screen widgets, long-press pop-ups, push notifications, and search results. The slices API plan never took off, but now it seems like Google is pitching the widgets API as a replacement. Widgets can appear not just on the home screen but in other remote locations now.

Those remote locations are Android search, the Google Assistant, and Android Auto. It's hard to know how well any of this will really work since there aren't any real-world uses for it yet. Google's demo for this involves making a food order with Dunkin' Donuts via the widget system. The demo shows a "recent orders" widget that works on the home screen and on Android Auto, and Google says that "you'll be able to complete an order, from start to finish, using a widget in Google Assistant." It certainly makes sense to have a hands-free voice order in the Google Assistant and in Android Auto, and maybe a "recent orders" home-screen widget, but building the entire order flow inside the widget API seems like overkill, since you would never pin any of that to your home screen. I guess when you make a single API for remote content in several places, not all of that content is going to be appropriate everywhere.

One decent example is a shopping-list widget. Of course, you'd want a home-screen widget of your shopping list. Now, when you tell the Google Assistant to add an item to the shopping list, you automatically get a feature-rich interactive shopping list in the Google Assistant, because it's just reusing the home-screen widget code.

So many other UI changes

One of the best ways to show off Material You's new color-changing feature is with the lock screen, which shows this huge, two-line clock when there aren't any notifications. This giant clock configuration also works on the always-on display, so it's easy to read the time from a serious distance. When you have a notification, the lock screen will change to something that looks a lot like Android 11, with a smaller clock and a list of notifications.

At the bottom of the lock screen are two new buttons. One is for the smart home controls that were introduced in Android 11, and the other will launch an NFC credit card screen. Again, this is only useful if you have multiple credit cards—the NFC chip is always active with your default card, so you don't need to open this to make a payment.

Google seriously messed up the Android 12 lock screen on the Pixel 6, which is its first device with an in-screen fingerprint reader. In-screen readers have to be given a UI by the system OS, and Android 12 neglects to enable the fingerprint reader on the lock-screen keypad. When it's time to enter your pin, pattern, or password, that's the only thing you can do on Android 12, while other OEMs like Samsung and OnePlus still give you the option of using the fingerprint reader.

Nearly every OEM uses the in-screen fingerprint reader better than Google. How is the fingerprint reader not accessible from the keypad lock screen?! This is so annoying.

Credit: Ron Amadeo

If you press on the fingerprint icon on the lock screen, the phone will unlock. If you do literally?anything else, the keypad will pop-up instead, so it is very, very important that the fingerprint reader still be active on the keypad screen. I accidentally bring up this screen all the time, and while it was never a problem on other phones, on Android 12, being forced to actually use the keypad instead of the fingerprint is awful.

Recent apps has a slightly tweaked layout, with more rounded corners on the thumbnails, a solid color background instead of a dimmed wallpaper, and an app icon that doesn't overlap with the thumbnail.

If you encounter a Chrome thumbnail, you'll see a few cool new features, though. First off, a link icon will sit next to the address bar, and with a quick tap you can copy the link to your clipboard or share it. This button is incredibly useful, since it matches a normal workflow pretty well. A lot of times I'll be texting someone and will leave the chat app to Google something in order to share the resulting link in my conversation. It makes a ton of sense to be able to copy between apps from this screen—it feels like the mobile version of copying data between apps on a multiwindow desktop OS.

Chrome will also show a button for pictures in the Recent Apps screen. This will let you quickly funnel a picture to Google Lens, which is nice. There are also "Share," "Copy," and "Save" buttons, but keep in mind this will probably grab a low-resolution image, so it's not ideal.?At the bottom, you'll get a few sharing shortcuts for apps, which isn't supported by a lot of things. It seems to work for Google Messages and Drive but not Google Chat.

The search bar at the top of the app drawer has been revamped. It's now "universal search" and will find all sorts of stuff for you inside your phone. It will search for apps, app shorts, settings options, contact share targets, Google Assistant routines, and more. All the way at the bottom of the list, it will offer to pass your query to Google Search. The one thing it doesn't offer is the ability to pass your search to the Play Store, which is a feature of third-party launchers like Nova Launcher. My use case is usually something like, "I need this app, I'm not sure if it's installed," and the Nova search bar will either find it on my device or pass the search to Google Play so I can download it. It's great, but it's not on Google's home screen.

Speaking of the app drawer, somebody messed up the alignment on it. After the search bar, there's a row of suggested apps, then a small horizontal divider. If that looks a bit weird, it's because the divider is not centered horizontally. The app icon grid is adjustable, and it seems like the horizontal divider doesn't change with the scaling app grid. If you go with a 4×4 grid, it looks closer to centered (but still wrong by a few pixels). I'm using 5×5 spacing, though, so it was off-center by almost?30 pixels on the Pixel 4 XL I was using to test.

There is surprisingly little to say about the settings this year. I mean, everything looks different, but most of the features are right where they were last year, just with a new coat of Material paint.?There aren't even any esoteric Developer Options to puzzle over in the final build.

The colorful icons on the main screen have been dropped in favor of monochrome icons plus whatever background color you've got going on from Material You. There are also new styles for switches and buttons. Google added big headers to everything, almost like it wanted to make lists more reachable with the giant titles, like Samsung does, but it never quite got there. Most of the controls are where you would expect them to be, though.

The biggest news is that Battery Stats was overhauled, and not in a good way. First of all, the graph is terrible. The x-axis isn't labeled with anything other than a series of two repeating numbers. In the above screenshot, it presents us with an x-axis labeled?"7 1 7 1 7," with no other text to discern what in the world it is talking about. I stared at this chart for a while, thinking, "Obviously, it's going to be time of some sort, but why do the numbers repeat?"

Those numbers at the bottom are actually the time! This screenshot was taken at 7:57. This is a 24-hour chart. The first "7" is actually "7 pm" from 24 hours ago. Then it's showing a "1," which is 1 am from six hours later, and then the next "7" is 7 am from 12 hours ago. Wow, this seems way harder to figure out than it should be. There must to be a better way to label this chart. Writing "24 hours ago," like Android 11 does, would be a lot more understandable at a glance. What was Google thinking here?

Weird labels aside, the really bad thing about this chart is that it maxes out at 24 hours. With phone charges lasting longer than ever now, usually more than a day, this is not enough time for a battery chart. Android 11's chart went back to your last full charge, so you could see more than 24 hours if your phone could survive that long. I don't understand Google's inconsistent chart limitations. The chart for data usage literally has a month selector. You're already logging the data. Just save it!

Everything below the chart on this screen is pretty good, though. You get to see the total minutes of foreground and background runtime for each app, and Android 12 even breaks out things like total Wakelock time, which is the amount of time running apps have prevented your phone from entering a lower-power state (think, playing a video).

Android 12 also fixed a major annoyance from the Android 11 battery screen. If you see an app using too much battery, you can now tap on it and immediately change the adaptive battery settings for that app, limiting its background usage. Android 11 would only link you to the adaptive battery screen, where you'd have to scroll through hundreds of apps to find that specific app again.

Privacy—A dashboard, permission chips, and kill switches

On the app-privacy side of things, one nice addition to Android 12 is the new privacy chips. Any time an app accesses your microphone or camera, a green icon will appear in the top-right corner of the phone. It's sort of like the location status bar icon but with a big green highlight. For longer usage, the green chip will minimize into a tiny circle to be less distracting. It's basically ripped right from iOS, but it's still a good idea.

If you aren't sure which app is triggering your camera or microphone, you can pull down the notification shade and tap on the green chip, which will pop up a message identifying the app in question. From there, you can tap on the message and jump immediately to the permission screen and adjust things if you want.

Keep in mind that on both Android and iOS, if you turn on your voice assistant's "hotword," both OSes will listen for that hotword all the time—yet won't show a microphone icon. The microphone notification will pop up after the hotword is registered, but clearly, the microphone was on before that.?Once a hotword is detected, Google and other services will start recording audio and sending it to the cloud, and for that, a microphone notification will pop up.

Another exception in Android seems to be the optional "Now Playing" feature on the lock screen, which uses the microphone to identify any nearby music that's included in the on-device music database. Like the Google Assistant, Now Playing is on all the time (at least, when the screen is off) yet doesn't trigger the notification.?The microphone notification seems to appear for every other usage of the microphone I could see, though.

If the microphone notification was on all the time, it would basically be useless, but it's still interesting that the Google Assistant can access the microphone without triggering the notification. The reason seems to be a change for the "HotwordDetectionService" system API, which has a special carve-out for "hotword detection without mic access indication." According to the Android Compatibility Definition Document, not triggering the microphone notification requires system-level permissions (so the app must be preinstalled), the app can't record more than 30 seconds of audio, and it has to keep the audio on the device. (You can also still install a third-party voice assistant, but if you have an always-on hotword that isn't from a system app, you'll have an always-on microphone notification.) There is a similar carve-out for the music recognition system.

Android has long had a quick-settings killswitch for location data, but Android 12 also adds buttons for the camera and microphone. In addition to turning off microphone permissions, the microphone button will also throttle sensor sampling rates to 200 Hz. It's actually possible to turn accelerometers and gyroscopes into makeshift microphones by detecting vibrations; limiting the sensor rate is designed to mitigate that possibility. There's a new permission for high-frequency sensor sampling, if an app needs that. (By the way, turning off the microphone will actually disable all of Google's special microphone carve-outs, too. The Google Assistant hotword will stop working.)

To prevent permanently disabling a key phone feature, users get a pop-up message if they try to do something incongruous—like open the camera app while the camera is disabled. An "Unblock device camera?" pop-up will let them re-enable things if they want.

The long-leaked "Privacy Dashboard" finally debuts in Android 12. It gives you an easy way to look at what is pinging your location, camera, microphone, and other permission-locked features. Sadly it only shows the past 24 hours of usage. Other Android data sources like Internet data and screen time usage go back months and months, and it would be interesting to compare this week's usage against last week's, giving users a baseline of permissions usage, but that's not possible.?The Privacy Dashboard is pretty simple and kind of anticlimactic given that this leaked back in 2019, but it's finally here.

The location permission has been updated yet again with the option to grant "precise" or "approximate" location. Something like Google Maps needs your exact location for turn-by-turn directions, while a weather app would only need approximate location. This pop-up also looks great, with two map circles at varying zoom levels showing what "Precise" and "Approximate" locations look like. Any time you can decorate these permission pop-ups, I feel like people are less likely to brainlessly click through them.

"App Hibernation" is the latest Android feature that tries to reduce the scope of access for unused apps (often these "unused" apps are unremovable crapware). Android 11 started automatically stripping unused apps of permissions, and now Android 12 is going to shut down unused apps and strip them of storage space. A hibernated app is force-stopped and can't run in the background and can't send push notifications. For storage reduction, apps will have their cache wiped from the system, and the "app optimization" files—ODEX and VDEX—will get deleted, as well. (This is only for apps that target Android 12 or higher, not older apps. Keep in mind that, with the Play Store's rolling minimum app requirements, all apps will be Android 12 apps by next year.)

The new "unused apps" page lists hibernated apps. In the app info settings, the "remove permissions and free up space" switch can be turned off, which will make apps immune to hibernation.

Credit: Ron Amadeo

As with permission stripping, apps will be scoped back this way if they aren't used for three months. "Usage" counts as tapping on the app icon or interacting with a notification in any way other than dismissing it. If you still have apps you want to keep running that don't meet these criteria, you can dive into the settings and flag these apps as immune from Android's various app shutdown features. Apps can also display a message asking for exemption from the unused app features now, and if any of these unused app restrictions do kick in, they can all be easily reversed by just opening the app.

On Android 11, a page of "Standby" apps was buried in the developer options; there, you could see which apps were swatted down. In Android 12, a new user-friendly "Unused Apps" page now lives under the "App" settings. This shows which apps are limited, explains exactly how they are limited, and each listing links to the app info screen for each app. There's a prominent trash can button next to each app that will offer to uninstall or disable the app in a single tap. The implied messaging here to users is pretty nice: "You haven't used these apps in a while. Want to remove them?"

Private Compute Core—Running AI code in a virtual machine?

Android 12 also has something called a "Private Compute Core," which Google hasn't ever officially explained in detail. It is still completely undocumented on developer.android.com, so the best we've got is this blog post, which calls it "an open-source, secure environment that is isolated from the rest of the operating system and apps." The community's best theory as to what this actually is comes from?MIshaal Rahman, who found evidence that Android is going to get KVM support and run a second, stripped-down, headless version of Android called "Microdroid" in a secure virtual machine. This would certainly satisfy Google's "open-source, secure environment" claims.

Google has been working on porting Chrome OS's CrosVM to Android as a virtual machine manager, and it wants to ship a known, stable hypervisor with the GKI, allowing it to use some of these virtual machine features. Being reliant on the GKI means being reliant on a device shipping with the GKI, which means at the minimum this is for new Android 12 devices only. Rahman also says the 5.10 GKI for Android 12 only includes a "development preview" release of the hypervisor and that a stable release won't arrive until Android 13. None of this actually being done yet would certainly explain why there is no documentation right now.

Google hasn't explained Private Compute Core very well, but it did share this vague diagram in an I/O talk. Our best guess is that it's a secure VM in which onboard AI processing apps can run.

The point of all of this seems to be running onboard AI work in an isolated sandbox. So far, the extent of this work seems to be the "Live caption" voice transcription feature for media; Now Playing, an always-on music identification service for the ambient display; and Smart Reply, which generates short, one-tap reply options in various messaging apps. All of these features existed before the Private Compute Core, but Google is now building a sandbox for them.

Again, this does not seem to be out yet. Google has built a bunch of parts for this that you can see in the diagram, but not all of them. The "Private Compute Services" and "Android Device Intelligence" APKs are both on the Play Store right now and ship on Pixel phones, but they run?inside the Private Compute Core and are not the Private Compute Core itself. Google is also working on a Project Mainline APEX package called com.google.virt, which contains a lot of the virtualization code.

Performance Class—A minimum spec for... something

Launching with Android 12 is something called "Performance Class," which lays out a set of hardware specs for Android devices. We know what the specifications are, but it's not clear how this qualification will be used or why it exists. Google's documentation is vague, and we're still unraveling the mystery of Performance Class, but so far the best explanation we've gotten is from this blog post:

Starting with Android 12 and working together with our ecosystem partners, we’re introducing a common standard for high-performing Android devices.

This standard, called performance class, defines a set of capabilities that go beyond Android's baseline requirements. Devices that meet the performance class requirements can support more demanding use-cases and deliver higher quality content. Developers can check for performance class at runtime and then reliably deliver enhanced experiences that take full advantage of the device’s performance.

Over the years, Google has had to define several custom hardware requirements for various features. For phones that could slot into VR headsets, there were "Daydream-ready" devices, which required things like a low-latency graphics mode, quality motion sensing, and smooth framerates. Today, Google has ARCore phone certifications for augmented reality, which require good motion tracking, a camera that can sync up with the motion sensors, and a fast enough CPU.

Performance Classes are numbered for each version of Android. Some devices will meet future Performance Class specs, and some will not.

Credit: Google

It seems like Performance Class will be a generic version of this idea—a flexible specification that Google can define in each generation and push OEMs toward. Performance Class is named with a number for each Android version, so the current version of the spec is "Performance Class 12" for Android 12, while next year we'll get Performance Class 13. (Google has retroactively defined a Performance Class 11 for older Android 11 devices.) Performance Class will be defined each year in the Android CDD (Compatibility Definition Document), and each device will be given a Performance Class number depending on the spec. While Performance Classes will be named for each Android version and presumably defined around OS release time, they exist independently of the various Android versions. That is, a device can start on Performance Class 12 but might qualify for Performance Class 13 when Android 13 comes out; or, the device might not qualify and would remain on Performance Class 12 even after being updated to Android 13.

Based on the specs we have for the first version, Performance Class seems to be a set of generic performance buckets for devices rather than a focused set of requirements like those we've been given for VR and AR. Google says, "Initially, we’re focusing Performance Class capabilities on media use cases, with requirements including camera startup latency, codec availability, and encoding quality, as well as minimum memory size, screen resolution, and read/write performance."

You can dive into the Android CDD and read the exacting requirements for Performance Class 12, things like a "minimum sequential write performance of at least 125 MB/s." That's not really helpful, though. We know what Performance Class is, but nothing Google has said tells us what problems it's trying to solve. The VR and AR requirements made sense because they were requirements that fulfilled a specific use case, but why would a developer want to limit an app by this random grab bag of requirements? I suppose if you had a resource-intensive app, you could use the Performance Class to rapidly cull cheap and old devices, but it seems like it might be unnecessarily broad and limit your customer base.

For something that's supposed to be built for developers, it's odd that this is still so poorly explained without a single example of why a developer would use this. For something like Private Compute Core, which is for Google's exclusive use, it makes sense that we don't know a ton about it. Google?wants?developers to use Performance Class, though. Right now the lack of documentation seems like it will kill the idea.

The incremental file system and play-as-you-download

New with Android 12 is a Play Store feature for games, one that Google is calling "play as you download." We've seen the idea on console and PC games before: architect your giant game downloads so that players get all the core bits to run the beginning of the game as soon as possible, and then, while they are occupied with level one, later levels can be downloaded in the background.?Google will bring this feature to Android 12, thanks to a combination of the Play Store, Android App Bundles, and a new file system that Google is calling "Incremental FS."

We're still just going by Google's description, since the feature is not open to the public yet, but Google says that it can launch games "at least two times faster" than downloading and installing. That doesn't actually sound great compared to the play-while-downloading implementations on other platforms, but those are all specially coded instances. On Android 12, Google plans to make all of this happen automatically, by default,?without developers needing to specially code their games for the feature. The plan is for every compatible game install to just... magically install faster.

Google Play Games Project Management Director Greg Hartrell described the feature earlier this year, saying, "We crowdsource the typical first-play experiences, including memory access patterns, to automatically deliver the optimal assets to load... Play as you download will not require you to change your game. If you use the app bundle format, simply upload your game, and we'll do the rest on Android 12."

A prerequisite for "play as you download" is the new Android App Bundles (AAB) file format, which Google introduced?in Android 9?and then made mandatory for all new apps in August 2021. (There's no timeline yet for existing apps to adopt AAB.) The?AAB file format replaces the familiar APK (Android PacKage) file as the package that developers use to upload their apps to the Play Store. The difference between the two is that, while the APK is finished, compiled code, an AAB ships the app to Google (or the app store owner) in an intermediate state between finished project and raw code.

Because AABs aren't completely compiled yet, the Play Store's cloud infrastructure can do all sorts of interesting things when it comes to app distribution. End users still receive APK files, but when developers upload an AAB, their users will get APK files that are hyper-customized for each specific device. This means getting an APK that exactly matches a device's CPU architecture, language options, and screen resolution, whereas, before, users might have received a bloated APK with unneeded extras. There are thousands of possible configurations for a given app, and rather than produce monolithic APKs, Google's cloud infrastructure creates "split APKs," which break an app into several pieces, such as core code, language support, and other configuration options.?Google's cloud infrastructure is accomplishing what would otherwise be an infeasible amount of work for each developer. The big downside is that developers have to turn their app signing keys over to Google.

With Google's cloud control over how app code gets compiled and distributed to users, you can see how this "play as you download" format becomes possible. Apparently, Google's crowdsourced analytics will try to figure out how each app works and then configure the AAB to ship the important parts first. That's the plan, anyway. Again, we've never seen this work in real life.

The reason this Play Store feature is an Android 12 exclusive is because it's only supported via a new file system called "Incremental FS." You generally aren't allowed to write to running applications, but on the surface, this is exactly what play as you download calls for. The solution is this new file system, which Google describes as a "special-purpose Linux virtual file system that allows execution of a program while its binary and resource files are still being lazily downloaded over the network."

It looks like the way this is rolling out is a kernel module for the GKI, so it may not be for all Android 12 devices but exclusive to devices that?launched with Android 12 and that support the GKI. So that's the Pixel 6 and future Android phones.

Incremental FS (incfs) runs on top of the main file system. If data isn't downloaded yet, a note is made in the ".pending_reads" file. If a new write comes in, it is appended to the end of the data block.

Credit: Google

Incremental FS won't replace your phone's base file system (which will still be something like ext4 or f2fs). Instead, it will run on top of the normal file system, offering new capabilities to make "play as you download" work. Files on Incremental FS can be delivered at the block level incrementally and out of order; file data is written to the disk in whatever order it arrives rather than the file order.?A new "index" directory exists to make sense of the scrambled block order and to hold links to not-yet-downloaded files.

You still can't write to a file block that is being executed, but thanks to Incremental FS, you're never actually doing that. Whatever code is running remains read only, and any writes that need to happen are just appended to the end of the data blob in a new block and noted in the index. If the system tries to read a file that hasn't been downloaded yet, Incremental FS will notify user space that the file hasn't arrived yet. Rather than instantly throw an error message, the app can hold off on the read until the download finishes or a timeout is reached. Presumably, the Play Store wastes no time getting that missing file—and should note the file's importance in the crowdsourced streaming profile for that app.

All the reads of Incremental FS are logged in a separate file so that Google can feed all of the data into its crowdsourced delivery algorithm for each app. Keep in mind that this is only for "public" app code you've downloaded from the Play Store, not for any private data or game saves, so it shouldn't cause any privacy issues. This also means that if something goes horribly wrong and you lose all your incremental FS data, it doesn't really matter, since you're just losing public app code that you could easily download again.

What I haven't seen anywhere is talk of a cleanup phase. All of this filesystem work and crazy out-of-order file storage is for slamming app code into the phone and running it as swiftly as possible, but once that first launch is over and the app sticks around, are we ever cleaning up this mess? When the phone is idle, charging, and on Wi-Fi, the Play Store automatically wakes up and updates your existing apps. It could easily delete all of this speed-install stuff and replace it with a traditional app install, but I've never seen documentation saying that "play as you download" actually does that. Presumably, Incremental FS would be totally incompatible with app updates, so maybe a clean install happens whenever the version changes? We have absolutely no details on what extra resources are taken up by "play as you download" installs, but presumably, some are.?Since one day this system will affect the majority of games, these extra resources could add up.

Google is aiming for low resource usage, at least. The company notes that an existing?filesystem, FUSE, was tried in a prototype implementation but added a performance overhead of "20-80 percent." That wasn't fast enough, so Google started from scratch. People with slower Internet and slower phones are more likely to get value from a feature like this, so hopefully it works well on those devices.

Google's last update on this feature was in July, when it said the feature would roll out to compatible titles "in the coming weeks." Assuming the GKI really is a requirement, the Pixel 6 is out now, so we should be able to experience this somewhere. Sadly, even Google's example app from the above gif does not work. (We actually have no way to know which other apps to try.) The "more information" link from Google's presentation goes to this page, which calls the feature a "beta" and still asks developers to sign up for it.

The Android update train never stops

That's about it for Android 12, which is definitely one of the more significant Android releases in some time. Material You looks beautiful and distinctive. Users can quickly change the whole look of their phone whenever they want, and it's almost unbelievable how well the automatic color system works.?Comprehensive, automatic theming like this is something other OS vendors will likely copy. Material You is also full of transition animations for things like the power button and the notification panel, making this feel like the smoothest Google OS ever.

Android 12 not only looks dramatically different from Android 11; things like the GKI represent Google's modularity efforts moving even deeper into the OS. Getting closer to the Linux kernel should not only make Android more secure with faster kernel updates—it should eventually ease the difficulty of developing Android. Google can work on upstreaming features more when it's not dealing with two years of lag time in its production code. Meanwhile, an updatable kernel should mean that individual versions of Android don't have to maintain support for a million different kernel versions. We'll be tracking the effects of this for years, starting with the Pixel 6.

The best news for Android 12 is that the Pixel flagship is actually good this year. For most users, I imagine these Android reviews are often exercises in theory, since the product that hits end users usually has to be finger-painted over by Samsung's software division. This year, though, you can just buy a Pixel 6, and you'll get all of the above software without any annoying middlemen.