An early preview of Android 14

Google may have just released Android 13 a little over a month ago, but they’re already hard at work on the next major version of Android, Android 14. Since Google develops Android behind closed doors, we won’t know the full extent of what’s new in Android 14 until the company releases its source code late next year. The Android 14 Developer Preview will give us a taste of what to expect, but we’ll have to wait at least four months if not longer before we get our hands on it.

However, Google sometimes lets slip bits and pieces of what they’re working on, as not every change is confidential. Some features we’re expecting to see in the next version of Android were already introduced in Android 13, but they either needed more time in the kitchen or developer buy-in, leaving Google no choice but to defer their release. Other changes we can infer based on how close they were to being completed before Google froze development of Android 13.

While I don’t have a laundry list of new features to share, I’ve put together a list of changes I’m confident are being developed for Android 14. Here’s what you should expect.

Predictive back gesture

When using Android’s back gesture, it isn’t always clear to the user whether the action will exit the app or navigate the user to a previous screen within the app. This is because there’s usually no feedback indicating what will happen when the back gesture is performed. Apps can process back press events and provide feedback (eg. in the form of a dialog) asking the user if they want to “exit” them, but many apps don’t do this. 

Since apps can control the behavior of back presses or implement custom back stacks, there’s often no way for the system itself to know what will happen when the back gesture is performed until after it’s done. To solve this problem, Android needs to be able to “predict” what will happen so that it can provide some kind of feedback to the user. 

This is why Google introduced predictive back gesture navigation in Android 13. This feature fixes the aforementioned ambiguity by showing a visual preview of the launcher as the user is performing a back gesture that’ll exit the app. Google calls this visual preview the “back-to-home” animation, and it’s part of AOSP Launcher3 in Android 13.

At a platform level, this feature is already functional, but it requires apps to be updated to utilize the new back navigation APIs. Google warns that users will experience broken back navigation when using apps that have not been updated to support the predictive back gesture, so developers are urged to update their apps as soon as possible. 

To give developers time to update their apps, Google decided to defer the launch of this feature until Android 14. On Android 13, the predictive back gesture isn’t utilized unless an app opts in and the user enables the “predictive back animations” developer option. Starting in Android 14, however, the new back dispatching behavior will be enabled by default for apps targeting API level 34 or higher.

Satellite connectivity?

Following the joint announcement from T-Mobile and SpaceX to use low-Earth orbit satellites to expand coverage to remote locations “previously unreachable by traditional cell signals”, Hiroshi Lockheimer, SVP of Android, took to Twitter to say that he was “excited to support our partners in enabling all of this in the next version of Android!”

With so little information given, it isn’t clear what exactly is being added to Android 14.

The Android Resource Economy

One of the biggest challenges for app developers is dealing with brand-specific idiosyncrasies, especially when it comes to background work. Many brands implement background app management features that are extremely restrictive but worse yet, totally undocumented. Google is slowly attempting to address this issue by introducing new background app management features in the hopes that OEMs will ship or at least extend what’s in AOSP.

Android 13 introduced a number of changes to the way apps perform work in the background, but one of the most significant changes didn’t make it to release. TARE, short for The Android Resource Economy, is a major rethinking of how the system manages background work. It’s disabled by default in Android 13, but a toggle to enable it is buried in developer options. Perhaps the feature wasn’t ready by the time development was frozen for Android 13, but it’s possible Google will enable it in Android 14.

So what is TARE? TARE tweaks the system’s logic when it comes to executing tasks queued using Android's JobScheduler and AlarmManager APIs. Whenever an app wants to do some work at a later time, it uses either of these APIs (or a higher-level wrapper, like WorkManager) to queue tasks. Based on the API that’s used and the parameters that are sent, the system will execute tasks at a set time, around a certain time, or at a time that both meets the app’s request and is optimal for the device’s battery. The problem is that before TARE, Android would only intelligently decide when to execute tasks but wouldn’t intelligently decide how many tasks should be executed or assign more importance to certain tasks.

Under TARE, Android applies basic economic principles of supply and demand to background work. Android creates a supply of “Android Resource Credits” (ARCs) TARE delegates to apps that they can then “spend” to queue tasks. The amount of ARCs that are in “circulation” at any given moment can be changed to limit how much total work can be done. When the battery is “satiated”, ie. full, then the total number of ARCs is at its maximum, which is called the “consumption limit”. 

The “cost to produce” (CTP) of queuing a task depends on the type of work that’s being done: More resource-intensive tasks generally require more ARCs to queue. The system may reward apps with more ARCs for good outcomes, such as when the user taps on a notification to open an app. Excluding apps that are in focus, foreground services, and system-critical processes, when an app runs out of ARCs to spend, it won’t be able to queue any background work. Apps should be designed to choose their actions carefully based on their available ARCs, while the system is designed to maximize its “profits” by running tasks in order of CTP.

Though I believe TARE is still being fine-tuned, it could be scrapped before Android 14 is released. If TARE is ready in time for Android 14, though, I wouldn’t be surprised if Google gives developers a grace period to adapt their apps considering how significantly it affects background work. 

Mandatory support for AV1 decoding

Google is one of the biggest backers of AV1, a royalty-free, highly efficient video compression algorithm developed by the Alliance for Open Media of which Google is a part of. Google’s own YouTube platform already encodes a lot of newly uploaded 4K and 8K resolution content in AV1, for instance. However, this content is also encoded using other codecs (mainly VP9) as many devices are not yet capable of decoding AV1.

Google wishes to lean harder on AV1 in order to save on bandwidth and storage, which is why in recent years they’ve aggressively pushed silicon vendors and device makers to launch products with AV1 decoding support. Televisions launching with Android TV 10 or later, for example, are reportedly required to support AV1 decoding. Where this mandate is codified and how it’s enforced isn’t exactly clear, but it’s likely one of many requirements that TV makers must meet in order to bundle the Android TV-specific GMS package.

Millions of users watch videos on a smartphone or tablet, however. Google has been more conservative with its approach to mandating AV1 support on these devices, having only recently implemented a mandate that some handheld devices ship with support for decoding AV1 content. Specifically, only those devices whose OEMs declare meet the Handheld Media Performance Class requirements for Android 13 must feature hardware-accelerated AV1 decoding support. Since the Handheld Media Performance Class is an entirely optional bar for handheld devices to meet, there’s little pressure on OEMs and mobile silicon vendors to ship products with AV1 support.

Still, several silicon vendors (notably Samsung, MediaTek, and Google themselves) have launched products with AV1 hardware decoding support. Qualcomm’s upcoming flagship Snapdragon chipset is rumored to add support for AV1, rounding out the list of major Android SoC makers that have products supporting AV1 decoding. Most newly launched flagship-tier and upper mid-range handheld devices in 2023 should have AV1 decoding support, with the numbers only growing in 2024. Even so, there will be a significant number of devices launching next year without AV1 support, which is why Android 14’s requirement that all devices must support decoding AV1 feels a bit premature.

This requirement, which hasn’t been previously reported, is hinted at in a code change recently merged to the AOSP Gerrit. The code change is titled “mediav2 CTS: Add AV1 to the required mediaTypes list” and its description reads, “[a]s per android cdd 14, sec 2.2.2 and sec 2.6, Handheld and Tablet device implementations must support decoding AV1”. It was authored by an engineer at Ittiam, the software vendor responsible for upstreaming many media-related changes to Android, including the platform’s HEVC decoder.

“Android cdd 14” refers to an unreleased copy of a preview version of the next Compatibility Definition Document, the document that enumerates all of the hardware and software requirements that device implementations must meet in order to be considered Android-compatible, one of several prerequisites for licensing GMS. Section 2.2.2 covers multimedia requirements for all handheld devices, while section 2.6 covers additional requirements for tablets. “CTS” refers to the Compatibility Test Suite, a key automated test suite that enforces CDD provisions.

According to new code in CodecTestBase, one of the classes responsible for enforcing the CDD’s codec list requirements, if a device is running Android 14 or newer and falls under the CDD’s definition of a handheld or tablet, then it must be able to decode AV1 videos. If it doesn’t, then it will fail the Media V2 CTS test and thus can’t be considered compatible with Android 14. 

However, the test only checks if the device is capable of decoding a compressed frame of a test video encoded in AV1 but not whether the device is using a software or hardware decoder. This means that devices will be able to launch with or upgrade to Android 14 without needing chipset-level support for decoding AV1. Furthermore, the Android 14 CDD isn’t finalized and is subject to change until shortly before the release of Android 14 next year, so there’s no guarantee the AV1 mandate will still be in place when the final version of the document is published.

In any case, it’s surprising to see this new compatibility requirement spelled out so clearly in an AOSP code change well ahead of Android 14’s release. Google is usually tight-lipped about new Android compatibility requirements before the CDD is finalized, but that policy might have changed as the company has recently put up a page to preview the next version of the CDD. That page is currently empty, however.

Mandatory support for the Identity Credential HAL

Android’s Identity Credential API provides an interface to securely store user identity documents such as mobile driver’s licenses. Devices with a Trusted Execution Environment (TEE) can store identity documents even more securely than devices without this hardware support, but this requires the Identity Credential hardware abstraction layer (HAL) to be implemented. 

Currently, only Google’s Pixel devices have implemented the Identity Credential HAL. To expand hardware support for the Identity Credential API, Google planned to require that chipsets launching with Android 13 support the Identity Credential HAL. This would have meant that future flagship devices equipped with next-generation chipsets launching with BSPs built on top of Android 13 would join Pixels in supporting the Identity Credential HAL. Google planned to enforce this requirement through a new test in the Vendor Test Suite (VTS), the automated test suite that validates the compliance of a device’s vendor software. 

However, this requirement was punted to Android 14, according to a code change merged in May. Unless this requirement was scrapped or delayed even further, that means that chipsets launching with Android 14 support will have to support the Identity Credential HAL. OEMs who are upgrading their devices to Android 14 won’t have to implement the Identity Credential HAL because of Google Requirements Freeze (GRF), though.

Read-only partitions formatted in EROFS

EROFS is a read-only file system originally developed by Huawei for their mobile devices. After Huawei deployed it, several other Android OEMs started formatting their devices’ read-only partitions in EROFS because of how much more efficient it was at compression than EXT4. Huawei’s kernel driver for EROFS became part of the mainline Linux kernel with version 5.4 and is available in the android11-5.4 and later branches of the Android Common Kernel.

During development of Android 13, Google added support for parsing EROFS images to update_engine, the userspace process behind A/B and virtual A/B OTAs AKA “Seamless Updates”. Google also started experimenting with deploying APEX image payloads, the meat of most Project Mainline modules, formatted in EROFS. 

Given the benefits of EROFS over EXT4, Google is pushing OEMs to use it for all read-only partitions. Google originally planned to require that all devices launching with Android 13 have EROFS-formatted read-only partitions, but they relaxed that requirement and settled on only requiring that Android 13 launch devices ship with kernel support for EROFS. It’s possible that Google will revisit its EROFS mandate for Android 14, but this remains to be seen. 

Devices with Armv9 CPUs may have to ship with 64-bit only Android

While iOS ended support for 32-bit apps all the way back in 2017, Android still hasn’t dropped support for 32-bit apps. This is despite the fact that the Armv8 ISA launched with the AArch64 execution mode back in 2011 and Android 5.0 Lollipop introduced support for 64-bit apps in 2014. Most Android devices on the market ship with 32-bit ABIs, and it’s only with Android 12 that OEMs could build Android without 32-bit support (and with Android 13 when those builds could be certified).

The reason Android has lagged so far behind iOS when it comes to dropping 32-bit app support is that 32-bit apps remained popular in certain markets like China. Back in 2019, Google Play mandated that apps with native code must include 64-bit libraries. As a result, over 99% of apps with native code on Google Play today support 64-bit devices. Once the top Chinese app stores stop distributing 32-bit apps, OEMs will finally start shipping 64-bit only builds of Android. The benefits of moving to 64-bit only Android include better security, better performance, and easier maintenance.

https://twitter.com/MishaalRahman/status/1419767555892334594

To speed up the adoption of 64-bit only Android, Google may be adding a new test to the Compatibility Test Suite (CTS) that “makes sure that an armv9 core that cannot run 32 bit executables does not export an [sic] 32 bit abis.” More specifically, the test checks the hardware capabilities of each CPU. If the CPU supports SVE2 and BTI, then that means it’s an Armv9 core. If it's an Armv9 core, then it must not export 32-bit ABIs. 

This test is designed to only run on devices launching with Android 14 or later, but the patch implementing it hasn’t been committed yet. This means it isn’t certain whether Android 14 launch devices with Armv9 CPUs will actually have to ship without 32-bit app support. Most Armv9 CPU designs already don’t support executing 32-bit apps, with the exception of the Cortex-A710 and the revised Cortex-A510. It isn’t clear whether Android 14 launch devices with these CPUs will also be required to ship with a 64-bit only build of Android, as this test doesn’t differentiate between the different Armv9 cores.

The true death of Android Beam

With the release of Android 10, Google deprecated Android Beam, a feature that uses NFC to initiate peer-to-peer sharing of files over Bluetooth or Wi-Fi Direct. The code remained within the platform, though, meaning OEMs and tinkerers could easily add it back if they wanted to. However, Google has started to delete all traces of Android Beam from the NFC framework, meaning the feature will truly be dead in Android 14. 

Devices that support StrongBox must implement Insider Attack Resistance

The Android Keystore system is an API that lets apps store cryptographic keys in a secure container (called a keystore). To protect the cryptographic keys from being extracted and thus compromised, the key material can be bound to the device’s secure hardware (such as a Trusted Execution Environment or Secure Element). For even further protection, cryptographic keys can be bound to the device’s StrongBox, a dedicated secure processor with its own CPU and secure storage. 

The CDD outlines the full requirements that a dedicated secure processor must meet in order to qualify as a StrongBox. In order to validate compliance with these requirements, the CDD also recommends that devices implement insider attack resistance (IAR) to guard the encryption keys for user data. IAR ensures that insiders “with access to firmware signing keys cannot produce firmware that causes the StrongBox to leak secrets, to bypass functional security requirements or otherwise enable access to sensitive user data.” While the Android 13 CDD only says that device implementations are “STRONGLY RECOMMENDED” to provide IAR, it says that IAR “will become a MUST requirement in Android 14.”

Updatable SELinux policy

Android 13 introduced support for updatable SELinux policy (SEPolicy) through an APEX module. According to a recent code change, the updatable SEPolicy module will become mandatory in Android 14. AOSP’s makefile defining what packages are included in the system partition has been updated to include ‘com.android.sepolicy’, the package name of the SEPolicy APEX. The reason Google wants this APEX to be included by default is because they “are planning to move parts of the existing platform policy into the apex sepolicy.”

Cross-device APIs in AOSP

At Google I/O 2022, Google announced the cross-device SDK, a set of APIs that simplify nearby device discovery, device wake-up, secure communications, and multi-device sessions over Bluetooth Low Energy (BLE), Ultra-wideband (UWB), and WiFi. A Developer Preview for the SDK launched in late August and is available on Android 8.0+ devices through a new Google Play Services library. 

At I/O, Google said that the new APIs will be added to AOSP in Android 14. The documentation for the Tethering modular system component suggests that these cross-device APIs are already included in AOSP, though I’m unable to find the module itself.

Apps may need to ask the user before they can use exact alarm APIs

Apps can schedule background work to execute at a specific time by using AlarmManager’s exact alarm APIs. Before Android 12, apps didn’t need to hold any permissions to use these APIs. Starting in Android 12, however, apps targeting API level 31 or higher had to hold the SCHEDULE_EXACT_ALARM permission in order to use exact alarm APIs. This permission is automatically granted when an app is installed but can be revoked by the user through the “Alarms & reminders” menu in Settings.

Apps that rely on scheduling exact alarms — such as alarm apps, clock apps, or calendar apps — won’t work reliably if the user revokes this permission. To prevent this from happening, Google recommends that apps check whether they hold this permission before trying to use exact alarm APIs. Still, some users may choose not to regrant the permission even when asked to do so, leaving apps that rely on it for core functionality in trouble.

For apps that rely on exact alarm APIs for their core functionality, Android 13 introduces a new permission called USE_EXACT_ALARM that functions similarly to SCHEDULE_EXACT_ALARM, except the former can’t be revoked by the user after the app is installed. This allows those apps to schedule exact alarms without user prompts. Since the user can’t revoke the USE_EXACT_ALARM permission, Google Play will audit the use of this permission so that only alarm apps, clock apps, and calendar apps request it.

The SCHEDULE_EXACT_ALARM permission remains an option for apps that need to use exact alarm APIs but that don’t rely on them for core functionality. Google planned to have the system automatically deny the SCHEDULE_EXACT_ALARM permission for apps targeting API level 33, meaning users would have to explicitly grant it from Settings. However, Google deferred the enforcement of this change, so apps requesting the permission on Android 13 will be automatically granted it regardless of target SDK version.

It isn’t certain if the default behavior of SCHEDULE_EXACT_ALARM will be changed in Android 14, but a comment suggests it could take effect “in the next SDK.” The benefit of this change is that fewer apps will request and be granted access to exact alarm APIs. Unless an app absolutely needs to schedule work to be done at a specific time, it’s better to let Android batch and queue work to run at an optimal time, such as when the device is idle or charging.

Miscellaneous changes

• Android 13 introduced a new telephony data stack which is enabled by default. The config flag that disables the new data stack and the code for the old data stack will be removed in Android 14.
• Screen recordings initiated through the ‘adb screenrecord’ shell command are limited to 3 minutes in duration. This limit will be raised to 30 minutes in Android 14.
• Non-VNDK devices will not be supported in Android 14. This effectively means that legacy non-Treble compatible devices cannot be upgraded to Android 14. 
• By default, Android is configured to automatically switch away from WiFi networks that lose Internet access (called “bad WiFi”). If, for whatever reason, the OEM configures the system not to avoid bad WiFi networks, then they have the option to choose whether the device should actively prefer bad WiFi to a good cellular connection. The default behavior up to Android 13 is to prefer validated mobile data over a bad WiFi connection that never validated. The default behavior starting in Android 14, however, will be to prefer mobile data until the WiFi completes its first validation attempt, after which the system will prefer the WiFi even if it doesn’t provide Internet (but not if there’s a captive portal).

That’s all the information I’ve put together so far on what’s coming in Android 14. Again, there isn’t much information to go off of, but I’ve refrained from making any wild guesses about future Android functionality. If I uncover any additional (concrete) information about the next version of Android, I’ll update this post with that information.

Everything You Need to Know about MDM