Android 14 review: There’s always next year

Does anybody care about Android 14?

This year's release of the world's most popular operating system feels like one of the smallest ever, bringing just a handful of new features. Even during the Android portion of Google's big I/O keynote, Google spent most of its time showing off a new generative AI feature that creates wallpapers for you, as if there aren't enough wallpapers in the world.

Last year's Android 13 release felt small, but that was because it was the second major Android OS release that year. Android 12L—the big tablet and foldable release—came out earlier. What's Android 14's excuse? We're not really sure. We still have a few things to go over, though, like new lock screen customizations, genuinely exciting changes to the way the back button works, and a pile of under-the-hood changes.

The new logo

First up is a new logo! Android's last big rebranding happened with Android 10, and just a few years later, it's time for a new coat of paint. The wordmark is now capitalized, and the little Android "bugdroid" mascot, usually a disembodied head next to the Android wordmark, is getting its body back. The bugdroid is now fully rendered in 3D, and in keeping with Google's Material Design guidelines, it comes in a variety of colors and styles. If you ask me, bugdroid in 3D looks a bit pudgy.

In the videos on Google's redesign blog post, a "Google Android" logo occupies the screen for a good amount of time. I have never seen these two brands together as a single wordmark, and widespread usage of it would certainly be a change. Some people confuse the Android brand with the "Android Open Source Project" and think it's some kind of free-to-use logo, but Android is a trademark of Google, and you can't use it unless you license the Google Play apps. So "Google Android" is totally appropriate.

I've never actually seen the Android logo anywhere in the world outside of tech news, so I'm not sure who this is for. Even if you get a Pixel phone, you won't see the Android logo on the box or in the software. The one spot to catch it in the real world is in a tiny "powered by Android" message on the rarely seen phone boot screen. It's like a branding system exclusively for Google blog posts and trade shows.

The (somewhat) customizable lock screen

iOS 16's headline feature was its new lock screen widgets, and it seems Android wants in on the action, too. Android originally had lock screen widgets back in 2012 with Android 4.2, but they were removed just a few years later in version 5.0. Lock screen widgets are still not back in Android 14, but because Google tries to keep pace with iOS, widgets are probably a lock to appear in Android 15 or 16.

What we have in Android 14's lock screen is a selectable clock style and two shortcuts you can pick from. You can long-press on the lock screen, and a "customize" button will pop up, letting you pick from seven different clock styles. You can choose the clock's color, and a color slider lets you adjust things further. "Contrast" isn't the right word for the slider, but the left side is a lightly tinted almost-black, the right side is a lightly tinted almost-white, and a full, rich color is in the middle somewhere. There's also a "size" setting for the clock, which determines if it kicks into full-screen mode when you have no notifications or just stays small all the time.

You can assign functions to two left and right shortcuts, but the options are strangely limited. You can assign a button to the camera, a do-not-disturb toggle, the flashlight, the Google Home app, Mute, the QR code scanner, the video camera, or Google Wallet. That's it—a weird grab bag of some quick settings toggles and one or two Google apps.

Still, it's great to get an actual settings UI for the lock screen shortcuts. Previously, controlling these shortcuts meant ticking one or two on/off switches in the display settings, which is not great for something that could have multiple options. It should just be all your apps and quick settings buttons—thanks to themed icons, there should be appropriate one-color options for all of these now. Between this shortcut setting, the quick settings "edit" UI, and the app drawer/home screen, that's three "shortcut" UIs where you pick a selection of items from a big bucket of icons. Google should just pick one UI and roll with it everywhere.

In general, though, the lock screen options feel like a precursor to something more robust, with app-supplied widgets.

Blocking old app installs

One of the bigger changes to Android 14 is something most people won't notice. Google is completely banning old app installs.

Previously, Android's legacy app support was basically perfect, with Android 13 able to install apps built all the way back to version 1.0. Part of the reason for such great backward compatibility is the "target API level" system, which lets Android apps declare the newest version of Android they support, giving them access to the latest features. If an API level is old, the Android OS will honor that on higher versions with a backward compatibility mode of sorts. New features won't be available, but new restrictions won't apply, either, as those could break the app. API Levels are basically an internal tracker of OS versions, but instead of the arbitrary, marketing-driven point numbers, the API level goes up by 1 every release. There have been a lot of 0.1 releases, so Android 1.0 was API level 1, but Android 14 is level 34.

Supporting the older app APIs forever is not necessarily ideal. As Android version numbers level up, app security gets better, permissions become more restrictive and granular, and bugs get fixed. At this point, there really aren't any legitimate reasons to use ancient app APIs. Android is 14 years old, and anything written using one of those old API levels usually offers a pretty bad user experience. Old API levels are really the domain of abandonware and—Google's real motivation for cutting off support—malware.

Malware loves old API levels. You get fewer restrictions, more loopholes, and more access to Android. The hard line in the sand—and the API level that Google is now making the minimum for install—is Android API level 23, aka Android 6.0 Marshmallow. This is the version that added support for runtime permissions, requiring users to tap "allow" or "deny" to access any sensitive data like your location or microphone.

Along with the permissions system came the critical "draw over other apps" permission, which lets an app overlay UI elements on the screen, often on top of another app. When used correctly, this enabled fun multitasking, but you can also imagine a piece of malware drawing a fake login screen on top of your banking app and capturing your banking credentials.

If an app targets an API level below Android 6.0, the permissions system doesn't apply to it, and it gets immediate access to all requested permissions at install and is able to draw all over the screen if it wants. Google set it up this way because it didn't want to break old apps by retroactively applying permissions to them, but it's also a gaping hole that malware can walk right through.

Here's a random old app, which happens to target API level 4. It installs just fine on Android 13 but shows this message for Android 14. Credit: Ron Amadeo

To try to shut the door on malware aimed at Android's backward compatibility mode, Android 14 will refuse to install anything older than Android 6.0. Try to install an old app and you'll get the above message saying that the app "isn't compatible" with your device.

In practice, almost no one will notice this change. Android 6.0 is eight years old at this point, so hopefully your favorite apps have been updated since then. And if you exclusively get your apps from the Play Store, you haven't been able to download an old app for a while. The Play Store implemented rolling API minimums in 2018, and since then, publishing or updating an app has required the app to use an API that is one year old or newer.

In 2022, Google added a similar rolling minimum for existing apps; anything targeting an API older than two years is hidden from the store. So even abandonware will get hidden from the store after two years and will only be visible to users who have downloaded the app before.

Putting a hard cap at the OS level instead of the app store level is all about sideloading. Even if there are a ton of examples of the Play Store not being perfect, downloading an infinite number of random apps from an infinite number of random places on the Internet is the primary way to get malware on an Android phone. Sideloading malware will now at least be subject to the permissions system, which will hopefully raise some red flags with users if a bunch of permissions pop-ups occur.

There are a few caveats here: If you upgrade a device from Android 13 to Android 14, Google won't remove your old apps. It's also still possible to install old apps if you tether to a PC and install an app via the ADB command line with a new "--bypass-low-target-sdk-block" flag. Just as with the Play Store minimums, when this feature was first discovered, the (since removed) commit comments mentioned the possibility of a "progressive ramp up" of the minimum level in the future.

Google has not officially said if it will raise the OS install minimum every year like it does with the Play Store, though. My guess is that the company is waiting to see what the fallout from this change will be.

Predictive back finally works (on a single application!)

Android's "back" function does not work like a browser back button, which always just shows the previous screen. Instead, it works more like an "up" button. It tends to navigate from the sub-pages of an app to the main page of an app, eventually closing the app and showing the home screen. That unintuitive functionality can make it tough to predict what the back button will do before you press it, and "Predictive Back"—a feature Google introduced during the release of Android 13—sounded like a nice band-aid. Swipe in from the side of the screen and the main screen will move to the side, showing the previous screen under it. From there, you can either lift your finger to navigate to that page or slide back to cancel.

Predictive Back has never really rolled out to users, though. The animation requires an opt-in from each individual app to work. And rather than releasing during the seven-month Android 13 beta period, it only launched once Android 13 was final. Even if you have apps that have opted in, enabling the feature in Android 13 means finding a checkbox hidden away in the developer settings. All these caveats mean that basically no one other than a testing developer has seen a predictive back animation.

In Android 14, things are looking slightly better. Requiring an opt-in on an individual app level means the system apps need to opt in, too, and they've never done that before. In Android 14, the settings app has opted into this, so out of the box, if you enable the developer setting, you'll finally see a predictive back animation in the settings. That's still a long way from being a normal occurrence or something users can get used to, though.

The version in the settings works great, by the way. Moving from a sub-page of the app to the main page comes with a smooth "slide and fade" animation, while using the back gesture to exit the settings app entirely will move the settings screen over, revealing the home screen. One big advantage of gestures over a simple button is that there are two states. Swiping over from the side starts the animation, previewing where you will navigate to, and you're only committed to that navigation when you lift your finger off the screen—you can also slide back to stay where you are.

The agonizingly slow rollout of this feature is frustrating, especially because iOS has had it for years. We know by now that making this an opt-in feature means developers will never widely adopt it until Google forces it on everyone (see: themed icons, split-screen support, auto-rotate support, transparent nav and status bar, etc.), but we're not even at the point where the base system interface—let alone the packed in apps and wider Google apps—widely supports predictive back animations. Check back in Android 15, maybe?

Permissions changes

The Play Store has been on a "privacy label" kick lately and has been requiring developers to fill out forms describing (based entirely on the honor system) what data they collect and how they plan to use it. In the Play Store, this information lives in the "Data Safety" section of an app listing, but in Android 14, it will start to be surfaced in the OS itself.

The first spot is in a permissions pop-up. When an app requests your location (and only your location), you'll see a new, tappable section just below the title indicating that the app shares data with a third party. Tapping on it will bring up a larger data-sharing pop-up showing the same data that's on the Play Store. It's a shame this is only the data privacy info. For years, developers have begged for a spot where they can explain any time a permission is being requested. This would be the perfect place for something like that, but you only get the data-sharing info.

The other new spot for this data is in the settings, where you'll be able to see "Data sharing updates" for apps. Listing this info on the Play Store is great, but unless you're obsessive about the sharing data, you'll never catch changes to it. That's what the new settings page will do: show you any new data-sharing changes to your installed apps from the past 30 days. You'll even get a notification alerting you to changes when they happen. Again, this is only for location data, not any of the other permissions that are described in the Play Store privacy labels. Also note that I haven't been able to get any of these features working, so I'm just going by Google's pictures and descriptions.

Android's "data safety" features are questionable because no one at Google vets this information. It also distracts from what is the far bigger privacy issue with owning an Android phone—figuring out what Google and all the packed-in apps are doing. Google defines "data safety" only as "sharing data with third-parties" and then says its own apps don't do that. But nobody was particularly worried about third parties. Google's biggest data-acquisition surface—Google Play Services—isn't accessible through a Play Store search to view the data safety page. The listing, if you bother to dig it up via a Google search, doesn't even offer data safety information using the self-serving definitions Google itself has cooked up.

Next up is the ability to individually grant access to a photo or video for an app. Previously, media access was an all-or-nothing affair, and in Android 13, Google added the system photo picker, where you could send an app a photo via the system with no permissions request at all. That's still the recommended way to get a photo, but it was opt-in, and Android developers aren't particularly fond of adopting opt-in features. This is being forced on apps, a strategy that's far more effective.

Now, when apps request a photo or video, you'll see a third option on the permission pop-up: "select photos and videos." This will display a system picker from which you can select photos, and the app will only be granted access to those specific photos. That's simple, easy, and universally compatible. I wish more features like this would be forced on apps.

The new fullscreen notification permission. Credit: Ron Amadeo

There's a new permission for "Full screen notifications." This isn't a pop-up runtime permission but instead something you'll need to dig into the settings to change. It lives in apps -> Special app access -> Full screen notification. full-screen notifications can be triggered by things like incoming calls, an alarm going off, or a car crash detection. If you ban an app from full-screen notifications, you'll just get a regular panel notification instead. As a millennial who doesn't want to ever receive a phone call unless it's a life-or-death situation, I think the ability to ban the call screen is great.

The settings

The settings are always home to a few changes each year. A new "Flash Notifications" setting in settings-> notifications will make the camera LED flash go off when you get a notification, which is extremely noticeable, or you can pick the rather strange option of making the entire screen flash a certain tint when a notification arrives.

Notification chimes and ringtone volume have been split into separate volume sliders in Android 14. You can find these in the settings under "Sound & Vibration" and in the quick change pop-up available from the volume button menu.

Besides the old "contrast" settings in accessibility and the one in the display options for Material You colors, there is now a "contrast" setting in the developer options. You can pick from "Standard," "Medium," and "High," though they don't seem to change much.

A developer setting called "Transparent navigation bar" says it will "make navigation bar background color transparent by default," and forcing this on apps would be very helpful. Android's bottom navigation bar exists solely for gestures, and if an app is designed correctly, it should almost always be transparent and never be a solid bar that blocks content.

Apps can do this, but many—including a lot of heavy hitters from Google—don't. It would be great to completely remove developer control from the status bar and navigation bar and always make them transparent, but that's not what this checkbox does. It doesn't seem to work. At least it didn't fix any of the problems I usually run into, like Gmail and Chrome having pointlessly solid navigation bars.

ART 14 performance improvements

With Android 14 comes ART 14, the Android Runtime. Google numbers the ART releases like major software projects now, and because the runtime is a Mainline module, it will be installed on older versions of Android, too. Ever since ART became a Mainline module in Android 12, users on that version or newer will get a better, faster app engine no matter how long their OEM takes to update the phone. In the future, when all devices get ART updates, it will be great for developers to have a more unified app target. For now, though, Android 12 and up represents just about 30 percent of devices, or 1 billion users.

Google says that "a big focus of Android 14 was on improving the performance and efficiency of the platform," and the company briefly described a few optimizations in an AOSP blog post. When you switch away from an application, the process is referred to as "cached," meaning it's no longer needed but is kept around if the system has spare resources. Android 14 is more aggressive about denying CPU time to these cached background applications, giving them 0 CPU resources sooner than earlier releases did. Cached applications now consume "up to 50% less CPU cycles as compared to Android 13 public devices," Google says, which should result in better battery life and a smoother UI.

Google is also promising "faster app launches" thanks to keeping more apps in memory. These days, flagship Android devices ship with a ridiculous amount of memory, so Google increased the hard limit on the maximum number of apps allowed to start in cache. This won't help with cold app starts after a reboot, but Google says in its testing that "on 8GB devices, the beta group saw 20% fewer cold app starts, and on 12GB devices, it was over 30% fewer."

That’s it!

That's it for Android 14, one of the smallest releases ever—and a very unexciting one for consumers. Android engineering lead Dave Burke said recently that some features planned for Android 14 were instead rushed out the door in Android 13. He cited a desire to get big-screen features into the ecosystem quickly, even though they were originally meant for Android 14. So this tiny release isn't necessarily a sign that mobile operating systems are mature and no more innovations or improvements will be made. It's just an off year.

It's unlikely that consumers will notice many of these changes. There's the new lock screen layout, but even that feels like a half-step toward a return to lock screen widgets. At least you don't have to worry too much about when your device manufacturer will finally roll this out to you.

Listing image: Google

Ron Amadeo Reviews Editor

Ron is the Reviews Editor at Ars Technica, where he specializes in Android OS and Google products. He is always on the hunt for a new gadget and loves to rip things apart to see how they work. He loves to tinker and always seems to be working on a new project.

177

View Comments