Android 12 has been here for about a month, and I’ve been using it as my daily driver on the Google Pixel 6 Pro since its launch. Android 12 represents API level 31, and it arrived in the form of an AOSP source code drop a few weeks before rolling out to Pixel smartphones.
In previous years, the new Android version would roll out to previous Pixel phones ahead of the launch of whatever new device is coming, but Google held back this time around. The cynic in me feels that it was for marketing purposes — after all, the entire tagline for the Pixel 6 series was that it was “For All You Are” with a heavy focus on personalization. Given that Android 12 is all about personalization, I don’t really think it’s controversial to think that Google intentionally held back the Android 12 Pixel rollout in order to reveal it alongside a new smartphone with a completely new look and feel when compared to its predecessors.
There’s a lot to delve into when it comes to Android 12, and while I’m comfortable in saying it’s my favorite Android version from an aesthetic point of view, I’m unsure if it’s my favorite overall. Google continues to blur the lines of what’s a Pixel-exclusive feature and what’s an Android 12 feature, but everything that I’ve identified as a Pixel exclusive feature will be identified as such.
Navigate this review:
Material You and other UI changes
By far the biggest change in Android 12 is Material You
If you want to learn more about it, you can check out our explainer of how Material You works.
Quick Settings
Android 12’s quick settings seem to be extremely polarising. There are some pretty big buttons, a whole new opening animation, and everything is very rounded. I love the new pull-down animation, though I miss the gaussian blur behind the notifications. The solid color doesn’t do it for me, even if it is also Material You inspired. Still, this new pull-down animation is one of my favorite animations in all of Android.
I think that Android 12's notifications and quick settings look a whole lot nicer
To be honest, I also think it’s probably better if the buttons contain the name of the function, too. I’m a power user, so I know what the icons mean, but does everyone really? I’m sure some of the basic ones like Wi-Fi nearly everyone could hazard a guess at, but the do-not-disturb option, in particular, is one that I could see confusing people. There’s also a power button that brings you to a power menu, though the default behavior from Android 12L is that the power button in the quick settings will open up the Assistant first unless you long tap it.
I think that the most redundant addition to the quick settings has to be the Google Pay card. You don’t ever need to open Google Pay to pay with your card, as it works from any screen on your phone at any time. The only time you’ll really ever need to open it is to choose a specific card if you want to use one that isn’t your default, but how often do most people do that? I also don’t really ever use the smart home device controls option, as my lights are voice-activated. I access the device controls part of my phone maybe once a week at most.
Another controversial change made in Android 12 is how you switch off Wi-Fi on an Android 12 device. Tapping the internet quick settings tile will bring you to another menu where you can toggle your mobile data, your Wi-Fi, or select another Wi-Fi network.
If I’m honest, I personally do prefer this change over what it once was, but I can understand the frustration thanks to the introduction of an extra button tap. From my own experience, I feel that it makes sense for Wi-Fi and mobile data to be under the same umbrella. However, if you want to get back a dedicated button to toggle your Wi-Fi, Mishaal Rahman shared a command on Twitter that you can execute via adb to get it back.
adb shell settings put secure sysui_qs_tiles "$(settings get secure sysui_qs_tiles),wifi"Overall, I think that the new notifications drawer and quick settings are well designed, and I do prefer both of them, even if I would have liked to see the apps behind my notifications akin to previous Android versions. I think that a lot of these changes make sense, and I don’t necessarily buy into the hatred of some of them.
Widgets
Google’s suite of apps has a ton of Android 12 Material You-compatible widgets, and they all take after whatever the dominant system theme is. They can be sometimes slow to change to fit the rest of the system theme, but they adjust based on where they’re located on the home menu, too. I still don’t really ever use Android’s widgets (I don’t spend a lot of time on my home screen or really care about making it look fancy anymore), but for people that do, you might like these changes.
Google announced an overhaul of widgets in Android 12, and the company definitely delivered. To align with the visual changes in Android 12, Google is encouraging developers to implement widgets with rounded corners with padding. The Widgets API was reworked entirely in order to enhance user experience across multiple platforms, Android variants, and launchers. Widgets got more dynamic controls that allow you to interact with checkboxes, radio buttons, and switches right from your home screen. The widget picker even offers responsive previews.
The new API also adds support dynamic coloring as part of the Material You theming engine, allowing widgets to adapt to the wallpaper, like other visual elements. Google has also removed the required configuration step when placing a widget on the home screen and has added a new API to construct backward-compatible widgets.
Interestingly, the information from widgets can now be accessed by Google Assistant to offer quick insights using the Capabilities API. In a blog post, Google noted that the Assistant would be able to provide users with “one shot answers, quick updates, and multi-step interactions” by glancing over the information available in widgets.
Pixel Launcher (Pixel exclusive)
The Pixel Launcher is obviously a Pixel exclusive feature, and it’s as barebones as ever. There’s a search bar permanently stuck at the bottom of the screen, an at-a-glance widget at the top, and the Google app sits to the left of the home screen. It’s simplistic and it works, but I know a lot of people would prefer to be able to remove the Google search bar.
The Pixel launcher comes with the ability to offer up suggestions of apps to launch, both in the dock at the bottom and in the full-length app drawer. App suggestions are powered by artificial intelligence and are based on your phone’s usage. I’ve noticed that the apps at the bottom often differ from the recommended apps in the app drawer, suggesting that the recommended apps in both of these places are calculated differently.
The Pixel Launcher also allows for changing the app grid size, enabling themed icons, and switching between a dark and a light theme. The themed icons are marked as “beta” which… is good because they don’t look great. I like the idea that Google is going for with them as they’re Material You themed, but they don’t look good, especially when unsupported apps are shown right beside them.
The Pixel Launcher is very much the iOS launcher of the Android world
The Pixel Launcher is very much the iOS launcher of the Android world. It lacks quite a lot of customization that we’ve come to expect from the likes of Nova Launcher or any of the other best Android launchers you can get. Some people like that simplicity, and while I don’t mind it, having options to play around with is cool.
Recents URL Sharing (Pixel exclusive)
Recents URL sharing is a Pixel-exclusive feature that allows users to share links to recently viewed web content straight from the recent screen. Any app can enable it, but it’s enabled by default in Google Chrome, and it’s a quick and easy way to share links across applications and adds even more functionality to the Recents menu.
Other changes
My biggest gripe with Android 12 is the change in how battery statistics are displayed. Particularly as a reviewer, these are extremely problematic for a number of reasons. Not only are the axes not labeled in any way, but the data is so much less usable than before. My app usage over the past 24 hours doesn’t reset after charging my phone, meaning that I can no longer show screenshots of battery statistics after a day of usage. I’ve resorted to using another app, GSam, just to collect data for battery statistics. It’s made even worse because each bar is a two-hour gap, which offers me practically nothing. It’s almost insulting that Google added that functionality as if it’s an improvement over older Android versions. That part is a Pixel exclusive by the way — you can’t tap those bars in Android 12 by default.
Another small gripe that I have is that the under-display fingerprint scanner doesn’t show up at the same time as the pattern keyguard. You can either input a pattern or put in your fingerprint, and if you swipe up to access your pattern, you then need to swipe back to access your fingerprint sensor. Why can’t both be enabled? It would make more sense and be more cohesive, especially because the keyguard itself doesn’t take up a lot of space. It feels like a weird decision, especially when other OEMs have figured this out already.
Performance class
The Android Compatibility Definition Document is an important part of the Android ecosystem. In order to maintain consistency in APIs and platform behavior between Android devices, Google bundles the distribution of Google Mobile Services (which includes applications and frameworks like the Google Play Store and Google Play Services) with license agreements mandating that devices adhere to the rules under Google’s “Android Compatibility Program” (among other requirements). The Android Compatibility Program consists of multiple automated test suites and a set of rules enumerated in the CDD (CDD PDF for Android 12 available here).
In the case of Android 12, there are a couple of changes that the CDD outlines, but most are pretty small or really only have an impact on OEMs. One of the biggest changes we’ve seen was the introduction of a “performance class” that can be defined in the build properties of an Android smartphone. Google already announced this alongside the release of Android 12 Beta 1, and it’s an easy way for developers to check how fast an Android smartphone actually is. On the Android Developers page, Google says that each version of Android has its own corresponding performance class, which means there’s a performance class for Android 12 and there’ll be one for Android 13, 14, and so on.
Performance classes are forward-compatible. This means that a device can upgrade to a new Android version without changing its performance class, but it also means that devices can change their class if they meet the requirements of that new OS version. Some key requirements for performance class 12 are below.
Performance class 12 key requirements
- At least 6GB of RAM
- At least 400dpi and 1080p resolution
- At least 120MB/s sequential write, 250MB/s sequential read, 10MB/s random write, and 40MB/s random read speeds
- Must have (at minimum) a 12MP rear camera capable of 4K 30 FPS recording
- Must have (at minimum) a 4MP front-facing camera capable of 1080p 30 FPS recording
Performance classes may be useful for app developers to improve the overall experience on not just devices meeting the “performance class” spec, but also for lower-end phones. If an app detects a phone doesn’t meet the requirements for a “performance class” device, they can turn off certain, more demanding features or visual effects in order to improve the way that the app works on lower-end phones. Likewise, it can also detect if it’s running on one of the best Android phones, in which case, it can enable high-performance features.
In the past, we’ve seen Google attempt to define different types of minimum hardware for particular functions. Remember Google’s Daydream VR? The company set out a minimum compatibility requirement in the CDD for Daydream-compatible devices with the launch of Android 7.1 Nougat. Some of those requirements included a physical core requirement, Vulkan support, screen size minimum and maximum, HEVC and VP9 support, and more. This is clearly an evolution of that concept, though applied more broadly across the Android ecosystem.
Confusingly, performance classes seem to be released in tandem with Android versions but also operate independently of them. A device on Android 12 can launch with performance class 12, and then upgrade to Android 13 in the future but maintain its older performance class. A performance class for Android 11 was defined retroactively in the CDD.
The purpose is a confusing one, but it seems to just be a minimum specification that apps can check out and see if they’re running on a reasonably powerful device or not. I’m not sure what exact way an app developer would make use of these specifications, but I think that additional information about the device being made available to app developers is ultimately a good thing, even if it likely needs to be fleshed out and given a particular purpose. It seems that right now, it’s primarily aimed at “media performance”, which explains why a lot of the focus is on storage speed, screen resolution, and camera capabilities.
Privacy
Privacy has increasingly been one of Google’s biggest focuses over the past few years. Over 2.5 billion devices are running Android around the world, and such a big install base means there’s a lot of unwanted interest from threat actors. That’s why each new version of Android adds features to ensure your sensitive information is available only to you. Android 12 introduces a ton of new privacy-related changes. Not only is there the new headlining Privacy Compute Core (currently a Pixel-exclusive), but there’s also the Privacy Dashboard, camera and microphone indicators, location controls, and more.
Over 2.5 billion devices are running Android around the world
Privacy Dashboard
This new privacy dashboard screen gives users information on how frequently components such as the camera, microphone, and location are accessed by apps, and it also lets users know which apps are accessing them, how often they’re accessing them, and lets users revoke those permissions if they think they’re accessing them too often. It’s a fantastic addition that makes it really easy to see how vital permissions are accessed by various different apps.
Reduced location access
Android 12 has introduced the ability to give apps an “approximate” location rather than a precise location. For example, think about your weather app. Does it really need to know your exact address? Generally not, and it makes more sense that all it might need is knowledge of your general locality. This concept has been implemented in Android 12 so that you can decide whether an app gets access to your precise location or an approximate location.
Clipboard access notification
Google added a toast message that appears when an app accesses your clipboard. We’ve all stored sensitive data on our clipboard before, generally because we need to copy that data from one place to another. However, previous to Android 12, apps could access the clipboard at will, and there was no way to know if and when they were doing it. The toast does not show if the request to access the clipboard originates in the same app that it was copied in.
Camera and microphone access
You can cut-off camera and microphone access from your phone’s quick settings with ease, and the best part is that the system handles it for you. As a result, apps will gracefully handle the cutoff and won’t crash if you suddenly revoke access, so long as they follow best practices. For example, apps will just see a black viewfinder when camera access is disabled. These toggles are not in the quick settings by default and need to be dragged out manually. In my opinion, I feel that privacy-centric features such as these should be surfaced and made much more prominent to the end-user so that they know they exist.
Private Compute Core (Pixel-exclusive)
Private Compute Services is said to provide a privacy-preserving bridge between the Private Compute Core and the cloud, making it possible to deliver new AI models and other updates to sandboxed machine learning features over a secure path. Google says communication between features and Private Compute Services happens over a set of purposeful open-source APIs, which removes identifying information from data and applies privacy technologies like Federated Learning, Federated Analytics, and Private information retrieval. If you want to learn more about this, you can check out our explainer of everything we know about the private compute core in the Google Pixel 6 series.
Under-the-hood changes in Android 12
The introduction of the Generic Kernel Image
Google has been working on reducing fragmentation on Android for years, though part of the cause of that is the inherent nature of Android. There are countless OEMs active in the space, and all of them want to make their own modifications for their own devices. The problem then is that it looks like Android OS updates are slow to roll out across the board, but there’s not a lot that Google can actually do to force OEMs to update their devices. As such, the next best thing that Google can do is make the update process as easy as possible.
In order to address this fragmentation, Google worked on the Android Generic Kernel Image (GKI). This is essentially a kernel compiled straight from an ACK branch. The GKI isolates SoC vendor and OEM customizations to plugin modules, eliminating out-of-tree code and allowing Google to push kernel updates directly to the end-user. For over a year, Google has been working on a way to deliver GKI updates via the Play Store, through the use of a Mainline module. Be sure to check out how the Generic Kernel Image is the next step towards solving Android’s fragmentation problem.
Phantom processes
Android 12 introduced a couple of restrictions on background processes; the first is that child processes of apps consuming too much CPU in the background will be killed if the parent process is also in the background. The second restriction introduced is a limit on the number of child processes that can be active at any given time. From the commit history, it would appear that Google was trying to clamp down on rogue background processes.
“Apps could use Runtime.exec() to spawn child process and framework will have no idea about its lifecycle. Now track those processes whenever we find them – currently during the cpu stats sampling they could be spotted. If it’s consuming too much CPU while its parent app process are also in the background, kill it. By default we allow up to 32 such processes; the process with the worst oom adj score of their parents will be killed if there are too many of them.”
Of course, Android smartphones are already notorious for background app killing. Pretty much all major OEMs engage in it in some way, shape, or form, and companies like OnePlus, Samsung, and Xiaomi are considered amongst the worst. While AOSP has some background app restrictions, it’s typical of manufacturers to build their own restrictions on top of AOSP. However, these are pretty strict limitations for power users and encourage behaviors that power users have been vocally against for a long time. Maybe it will increase battery life in the long run, but it’s a rather user-hostile approach.
Android 12 is my favorite iteration of Android yet
Android 12 is the most polished and most complete version of Android yet
Is there a point wherein it’s change for the sake of change? Maybe, but I’m not quite sure that we’ve reached that yet. Android 11 looked good, but it also looked very barebones. Visual clutter is bad, and I feel that Android 12 manages to achieve a new, updated look without adding any additional clutter. Having said that, I understand the arguments regarding wasted space — I just don’t really care enough about it. My phone still works, it looks prettier, and I think it’s a more palatable look to the average (read: not enthusiast) user.
A lot of these changes will need to be improved upon in Android 13. I don’t necessarily feel like I’m using a beta, but it feels like Google can do more. It feels like there’s more that needs to be done, and there’s more that will be done.
The post Android 12 Review: My favorite iteration of Android yet appeared first on xda-developers.
from xda-developers https://ift.tt/3cYEPKJ
via IFTTT
Aucun commentaire:
Enregistrer un commentaire