Android 13: Features and first Developer preview

Features and first Developer preview

Although Google only just unveiled the final beta release of Android 12L, the feature update for tablets and other large-screen devices, the company today took the wraps off of Android 13, Android’s next major OS update. The initial release provides our first look at Android 13 and introduces many new features, API updates, user interface tweaks, and behavioral changes to the Android platform. In this article, we’ll document all of these changes so you can prepare your application or device for Android 13.

A quick note before we dive in: Google has only released the first developer preview of Android 13. That means there will be lots of additional changes introduced in future preview versions. We will update this article as we learn more about the upcoming release.

Table of Contents

When will Android 13 be released?

According to the release timeline, the final release of Android 13 is expected to happen in Q3 2022. There will be 2 Developer Preview and 4 Beta releases before the final release. Android 13 is expected to reach Platform Stability in June 2022 with the third beta release. Once Platform Stability is reached, Android 13’s SDK and NDK APIs and app-facing system behaviors will be finalized. Since the Android 12L release came with framework API level 32, Android 13 is expected to be released alongside framework API level 33.

The release timeline for Android 13. Source: Google.

Android 13 can be installed on PCs through the Android Emulator, on compatible Pixel devices through a device-specific flashable image, or on Project Treble-compatible devices through a Generic System Image (GSI). Pixel devices that are eligible to install the Android 13 Developer Preview include the Pixel 4, Pixel 4 XL, Pixel 4a, Pixel 4a (5G), Pixel 5, Pixel 5a with 5G, Pixel 6, and Pixel 6 Pro.

The Developer Preview is intended for developers only and can thus only be installed manually. Once the first Android 13 beta version is available, consumers will be able to enroll in the Android Beta program to have the release roll out their devices over-the-air.

Developers that set up the Android 13 Developer Preview are encouraged to offer feedback on the new features and APIs and test their app for compatibility issues.

What are the new features in Android 13?

New System Photo Picker

To prevent apps with the broad READ_EXTERNAL_STORAGE permission from accessing sensitive user files, Google introduced Scoped Storage in Android 10. Scoped Storage narrows storage access permissions to encourage apps to only request access to the specific file, types of files, directory, or directories they need, depending on their use case. An app can either use the media store API to access media files stored within well-defined collections, or they can use the Storage Access Framework (SAF) to load the system document picker to let the user pick which files they want to share with that app.

Android’s system document picker app — simply called “Files” — provides a barebones file picking experience. Android 13, however, is introducing a new system photo picker that extends the Files app with a new experience for picking photos and videos. The new system photo picker will help protect photo and video privacy by making it easier for users to pick the specific photos and videos to share with an app. Like the Files app, the new system photo picker can share photos and videos stored locally or on cloud storage.

Apps can use the new photo picker APIs in Android 13 to prompt the user to pick which photos or videos to share with the app, without that app needing permission to view all media files. The new photo picker experience will also roll out to Android devices running Android 11 or higher (excluding Android Go Edition) through an update to the MediaProvider module.

Per-app language preferences

In the Settings app under the System > Languages & input > Languages submenu, users can choose their preferred language. However, this language is applied system-wide, which may not be what multilingual users necessarily prefer. Some applications offer their own language selection feature, but not every app offers this. In order to reduce boilerplate code and improve compatibility when setting the app’s runtime language, Android 13 is introducing a new platform API called LocaleManager which can get or set the user’s preferred language option.

Users can access the new per-app language preferences in Android 13 by going to Settings > System > Languages & input > App Languages. Here, the user can set their preferred language for each app, provided those apps include strings for multiple languages. The app’s language can also be changed by going to  Settings > Apps > All apps > {app} > Language.

Per-app language preferences in Android 13

QR code scanner shortcut

QR codes have been an indispensable tool during the COVID-19 pandemic, as they’re a cheap and highly accessible way for a business to lead users to a specific webpage without directly interacting with them. In light of the renewed importance of QR codes, Google is implementing a handy shortcut in Android 13 to launch a QR code scanner.

Specifically, Android 13 implements a new Quick Setting tile to launch a QR code scanner. Android 13 itself won’t ship with a QR code scanning component, but it will support launching a component that does. The new QRCodeScannerController class in SystemUI defines the logic, and the component that is launched is contained within the device_config value “default_qr_code_scanner”. On devices with GMS, Google Play Services manages device_config values, and hence will likely set the QR code scanner component as Google Lens.

Left: QR code scanner is grayed out because the default_qr_code_scanner value is empty. Right: QR code scanner tile is functional.

The Quick Setting tile is part of the default set of active Quick Settings tiles. Its title is “QR code” and its subtitle is “Tap to scan.” The tile is grayed out if no component is defined in the device_config value “default_qr_code_scanner”. Within the Settings.Secure.sysui_qs_tiles settings value that keeps track of the tiles selected by the current user, the value for the QR code scanner tile is “qr_code_scanner”.

A bunch of new Quick Settings tiles

In addition to the Quick Setting tile for the QR code scanner, Google has added other new tiles. These include:

• A Quick Setting tile for the foreground service manager. This tile opens a dialog which shows the currently running foreground services, likely for development and debugging purposes.
  • The device_config flag “task_manager_enabled” under the systemui category enables the foreground service manager.  
  • Once added to the set of active Quick Settings tiles, the Settings.Secure.sysui_qs_tiles holding the list of Quick Settings tiles for the current user will have “fgsmanager” appended to it.
• A Quick Setting tile to toggle color correction.
• A Quick Setting tile to toggle one-handed mode.
  • One-handed mode is disabled by default in AOSP but can be enabled with ‘setprop ro.support_one_handed_mode true’. One-handed mode settings won’t appear on large screen devices, but the Quick Setting tile can be appended to the set of active tiles by adding “onehanded” to Settings.Secure.sysui_qs_tiles.

Left: QS tile for the foreground service manager. Middle: foreground service manager dialog. Right: QS tiles for one-handed mode and color correction

Clipboard auto clear

Android offers a clipboard service that’s available to all apps for placing and retrieving text. Many keyboard apps like Google’s Gboard extend the global clipboard with a database that stores multiple items. Gboard even automatically clears any clipboard item that’s older than 1 hour.

Although any app can technically clear the primary clip in the global clipboard (so long as they’re either the foreground app or the default input method on Android 10+), Android itself does not automatically clear the clipboard. This means that any clipboard item left in the global clipboard could be read by an app at a later time, though Android’s clipboard access toast message will likely alert the user to this fact.

Android 13, however, has added a clipboard auto clear feature. This feature, which is disabled by default, will automatically clear the primary clip from the global clipboard after a set amount of time has passed. By default, the clipboard is cleared after 3600000 milliseconds has passed (60 minutes), matching Gboard’s functionality.

The logic for this new feature is contained within the ClipboardService class of services.jar. Here is a demonstration of the clipboard auto clear feature in Android 13 with a timeout of 5 seconds:

It’s easier to install apps to guest profiles

When creating a guest user in Android 13, the owner can choose which apps to install to the guest profile. No data is shared between the owner and guest profiles, however, which means that the guest profile will still need to sign in to those apps if need be.

Disable the long-press home button action

Under Settings > System > Gestures > System navigation, a new submenu has been added for the 3-button navigation that lets you disable “hold Home to invoke assistant”. After disabling this feature, a long press of the home button will no longer launch the default assistant activity.

7-day view in privacy dashboard

Android 12 introduced the “Privacy dashboard” feature which lets users view the app that have accessed permissions marked as “dangerous” (ie. runtime permissions). The dashboard only shows data from the past 24 hours, but in Android 13, a new “show 7 days” button is being tested that will show permissions access data from the past 7 days.

This feature is not enabled by default. It is possible that this feature will roll out to Android 12 devices as well with an update to the PermissionController Mainline module.

Media Tap To Transfer

Android 13 contains references to a “Media Tap To Transfer” feature. The feature still appears to be in development, so it is difficult to determine exactly how it works. However, by enabling a hidden SystemUI flag, the feature’s command line interface becomes available. These commands are likely used by Google to quickly prototype the sender/receiver flow. The commands are as follows:

cmd statusbar media-ttt-chip-add-sender [NAME] [MoveCloserToStartCast|TransferInitiated|TransferSucceeded]
cmd statusbar media-ttt-chip-remove-sender
cmd statusbar media-ttt-chip-add-receiver
cmd statusbar media-ttt-chip-remove-receiver

The media tap to transfer chip is shown at the top of the screen after running the ‘cmd statusbar media-ttt-chip-add-sender’ command.

According to Android Police, the media tap to transfer chip will be shown when a user is playing media on a local “media cast sender” device (e.g. a smartphone) and they move their device close enough to a “media cast receiver” device (e.g. a tablet) that they own. The chip will encourage the user to “transfer” the media from the sender to the receiver device. It isn’t clear how the media transfer happens, however.

We would like to thank Danny Lin (@kdrag0n) for his assistance in enabling this feature.

Hub mode

Google believes that tablets are the future of computing, so they’ve recently invested in a new tablet division at Android which has helped oversee some of the new features in Android 12L, the feature update for large screen devices. Some of the major changes in Android 12L focus on improving the overall experience of tablets, but in Android 13, Google is preparing to improve one particular use case.

Android 13 Developer Preview 1 reveals early work on a new “hub mode” feature, referred to internally as “communal mode”, that will let users share apps between profiles on a common surface. Code reveals that users will be able to pick from a list of apps that support hub mode, though it isn’t clear what requirements an app needs to meet to support hub mode. Once selected, the apps will be accessible by multiple users on the common surface. The primary user can restrict which Wi-Fi APs the device has to be connected to in order for applications to be shared, though. These networks are considered “trusted networks”.

Connected network
Previously connected networks
Hub mode
There are no apps which support hub mode
Shared apps
Use hub mode
Trusted networks

It isn’t yet entirely clear what form the common surface will take. Initially, we believed that the common surface would be the lock screen, which has seen some other multi-user improvements in Android 13. However, new code related to “dreams”, Android’s code-name for interactive screensavers, not only points towards a revamp of the old feature but also tie-ins with the new “hub mode”. Couple this with new dock-related code, both in Android 13 and in the kernel, suggests that Google is planning something big for tablets that are intended to be fixed in place on a dock.

Since hub mode is still a work-in-progress, we are not able to demonstrate the feature. Enabling the feature first requires that the build declare support for the feature ‘android.software.communal_mode.’ Then, one needs to set SystemUI’s boolean flag ‘config_communalServiceEnabled’ to true. From there, however, there are several missing pieces, including the communalSourceComponent and communalSourceConnector packages as well as much of the code for the common surface. We also couldn’t find the interface for adding applications to the allowlist for communal mode, which is stored in Settings.Secure.communal_mode_packages.

However, we were at least able to access the screen for choosing “trusted networks”.

Screen saver complications

Google introduced screen savers to Android back in Android 4.2 Jelly Bean, but since the feature’s introduction, it has received few major enhancements. As an aside, screen savers used to be called “daydreams” but were renamed in Android 7.0 Nougat to avoid confusion with Daydream VR, the now-defunct phone-based VR platform. Google still refers to screen savers as “dreams” internally, though, which is important for us to note. That’s because Android 13 introduces a lot of new dream-related code in SystemUI, suggesting that significant changes are on the way.

New classes in Android 13 reveal work on a dream overlay service that is intended to allow “complications” to run on top of screen savers. In Wear OS land, a complication is a service that provides data to be overlaid on a watch face. It appears that dreams will borrow this concept, though we don’t know what kind of complication types Google is planning to support apart from a battery meter.

Google is likely planning other enhancements to the screen saver experience, but we’ll have to wait for the company to release more preview builds to learn more. Given the evidence we’ve seen, however, we’re confident in saying that the company is preparing major enhancements to screen savers, though whether these changes will land in time for the final Android 13 release we cannot say.

What are the UI changes in Android 13?

Taskbar now shows up to 6 apps

The taskbar that Google introduced in Android 12L can now show up to 6 apps on the dock as opposed to the previous 5. It can also show suggested apps.

The media output picker UI has been redesigned

In Android 10, Google introduced an output picker that lets users switch audio output between supported audio sources, such as connected Bluetooth devices. This output picker is accessed by tapping the media output picker button in the top-right corner of the media player controls. Now in Android 13, Google has revamped the media output picker UI.

The highlight of the new media output picker UI is the larger volume slider for each connected device.

The media player UI is being redesigned

In Android 11, Google reworked the media player controls to support multiple sessions and integration with the notifications shade. Now in Android 13, Google is preparing to revamp the media player UIs.

Left: Media player UI in Android 12L. Right: Android 13’s in-development media player UI.

The new media player UI features a larger play/pause button that’s been shifted to the right side, a progress slider that’s at the very bottom and in line with the rest of the media control buttons, and the media info on the left side. Currently, it seems that the new media player design doesn’t show album art, but that may change in a future preview release.

This new design is not active in Developer Preview 1. To enable this new UI, a SystemUI flag must be toggled.

We would like to thank Danny Lin (@kdrag0n) for his assistance in enabling this feature.

Enabling silent mode disables all haptics

When setting the sound mode to “silent”, all haptics are disabled in Android 13, even those for interactions (such as gesture navigation). On Android 12L, “vibration & haptics” are similarly grayed out with a warning that says “vibration & haptics are unavailable because [the] phone is set to silent”, but in our testing, haptics for interactions still work. This is not the case in Android 13, however.

Split screen button in PiP windows returns

Android 12L first introduced a split screen button in picture-in-picture windows whenever another app is open. Tapping the button launches both apps in split-screen mode as an app pair. This feature was disabled by default in Android 12L Beta 3 but is enabled by default in Android 13 Developer Preview 1.

This feature is controlled by the framework configuration value ‘config_pipEnableEnterSplitButton’ and is likely intended to be enabled for large screen devices only.

User switcher on the keyguard

In Android 13, the keyguard screen (ie. the lock screen PIN/password/pattern entry page) can show a large user profile switcher on the top (in portrait mode) or on the left (in landscape mode). This feature is disabled by default but is controlled by the SystemUI boolean ‘config_enableBouncerUserSwitcher’.

Lock screen rotation enabled on large screen devices

Android’s framework configuration controlling lock screen rotation has been set to “false” by default for years, but it is now enabled by default. In Android 13, the lock screen will only rotate on large screen devices, however.

New Material You dynamic color styles

Google introduced dynamic color, one of the key features of Google’s new Material You design language, in Android 12 on Pixel phones. Dynamic color support is set to arrive on more devices from other OEMs in the near future, according to Google, due in large part to new GMS requirements. Google’s dynamic color engine, codenamed monet, grabs a single source color from the user’s wallpaper and generates 5 tonal palettes that are each comprised of 13 tonal colors of various luminances. These 65 colors make up the R.color attributes that apps can use to dynamically adjust their themes.

Each of these colors have undefined hue and chroma values that can be generated at runtime by monet. This is what Google is seemingly taking advantage of in Android 13 for a new feature that will likely let users choose from a handful of additional Material You tonal palettes, called “styles.”

In Android 13, Google is working on new styles that adjust the hue and chroma values when generating the 5 Material You tonal palettes. These new styles are called TONAL_SPOT, VIBRANT, EXPRESSIVE, and SPRITZ. The TONAL_SPOT style will generate the default Material You tonal palettes as seen in Android 12 on Pixel. VIBRANT will generate a tonal palette with slightly varying hues and more colorful secondary and background colors. EXPRESSIVE will generate a palette with multiple prominent hues that are even more colorful. SPRITZ generates an almost grayscale, low color palette.

The specs of these new styles are defined in the new com.android.systemui.monet.Styles class. These new style options are not hooked up to SystemUI’s ThemeOverlayController, however, so no Fabricated Overlays containing the 3 accent and 2 neutral tonal palettes can be generated using these new specs. Furthermore, no code referencing these new styles can be found in the WallpaperPicker app from Android 13 DP1, so there’s also no method for users to pick these new styles. The WallpaperPicker/Theme Picker app interfaces with SystemUI’s monet by providing values to Settings.Secure.THEME_CUSTOMIZATION_OVERLAY_PACKAGES in JSON format. It is likely that a future Android 13 release will update this API to include setting the desired “style” to generate the new tonal palettes.

Although we are unable to demonstrate the new Material You styles in DP1, this post from Android Police contains screenshots that likely show how they’ll differ from the base Material You style.

What are the behavioral changes in Android 13?

Nearby device permission for Wi-Fi

Because a device’s location can be inferred by tracking nearby Wi-Fi APs and Bluetooth devices, Google decided to prevent apps from accessing Bluetooth or Wi-Fi scan results unless those apps hold location permissions. It made sense for Google to gate these features behind location permissions given that they could be used to derive a user’s physical location, but it resulted in confusion from users who believed that their apps were tracking their location, because both ACCESS_COARSE_LOCATION and ACCESS_FINE_LOCATION are “dangerous” (ie. runtime) permissions that require post-install user consent to be granted.

To reduce confusion, Google introduced new BLUETOOTH_SCAN, BLUETOOTH_CONNECT, and BLUETOOTH_ADVERTISE permissions under the NEARBY_DEVICES permission group in Android 12. These permissions can be requested by apps that need to interact with Bluetooth, and when one or more of them are requested by the app, the system prompts the user to allow the app access to “nearby devices”. An optional Manifest attribute called “neverForLocation” lets the app strongly assert that it won’t derive physical location.

In Android 13, Google is similarly decoupling Wi-Fi scanning from location. Android 13 introduces the new NEARBY_WIFI_DEVICES runtime permission under the NEARBY_DEVICES permission group. This permission should be requested by apps that need to manage a device’s connections to nearby Wi-Fi APs and will in fact be required to call many commonly used Wi-Fi APIs. The optional Manifest attribute “neverForLocation” will let developers strongly assert that their app won’t derive physical location from Wi-Fi scan results.

Faster hyphenation

When text reaches the end of a line in a TextView, rather than exceed the margin and go off screen, a line break will be inserted and the text will wrap around to the next line. Hyphens can be inserted at the end of the line to make the text more pleasant to read if a word is split, but enabling hyphenation comes at a performance cost. Google found that, when hyphenation is enabled, up to 70% of the CPU time spent on measuring text is on hyphenation. Thus, hyphenation was disabled by default in Android 10.

However, Android 13 significantly improves hyphenation performance by as much as 200%. This means that developers can enable hyphenation in their TextViews with little to no impact on rendering performance. To make use of the optimized hyphenation performance in Android 13, developers can use the new fullFast or normalFast frequencies when calling TextView’s setHyphenationFrequency method.

The Android Resource Economy

With every new release, Google further restricts what apps running in the background can do, and Android 13 is no exception. Instead of creating a foreground service, Google encourages developers to use APIs like WorkManager, JobScheduler, and AlarmManager to queue tasks, depending on when the task needs to be executed and whether the device has access to GMS. For the WorkManager API in particular, there’s a hard limit of 50 tasks that can be scheduled. While the OS does intelligently decide when to run tasks, it does not intelligent decide how many tasks an app can queue or whether a certain task is more necessary to run.

Starting in Android 13, however, a new system called The Android Resource Economy (TARE) will manage how apps queue tasks. TARE will delegate “credits” to apps that they can then “spend” on queuing tasks. The total number of “credits” that TARE will assign (called the “balance”) depends on factors such as the current battery level of the device, whereas the number of “credits” it takes to queue a task will depend on what that task is for.

Given the complexity of TARE, we will need to continue to analyze it so we can provide you with a better understanding of how background tasks are handled in Android 13. From a cursory analysis, it seems that the EconomyManager in Android’s framework lists how many Android Resource Credits each job takes, the maximum number of credits in circulation for AlarmManager and JobScheduler respectively, and other information pertinent to TARE. For example, the following “ActionBills” are listed, alongside how many “credits” it takes to queue a task: ALARM_CLOCK, NONWAKEUP_INEXACT_ALARM, NONWAKEUP_INEXACT_ALLOW_WHILE_IDLE_ALARM, NONWAKEUP_EXACT_ALARM,  NONWAKEUP_EXACT_ALLOW_WHILE_IDLE_ALARM, WAKEUP_INEXACT_ALARM, WAKEUP_INEXACT_ALLOW_WHILE_IDLE_ALARM, WAKEUP_EXACT_ALARM, and WAKEUP_EXACT_ALLOW_WHILE_IDLE_ALARM.

TARE is controlled by the Settings.Global.enable_tare boolean, while the AlarmManager and JobScheduler constants are stored in Settings.Global.tare_alarm_manager_constants and Settings.Global.tare_job_schedule_constants respectively. TARE settings can also be viewed in Developer Options.

What are the platform changes in Android 13?

Android’s Bluetooth stack is now a Mainline module

Android 13 has migrated Android’s Bluetooth stack from system/bt to packages/modules/Bluetooth, making it updateable as a Project Mainline module. Work is ongoing in AOSP to add new features to the Bluetooth stack — such as support for the new Bluetooth LE Audio standard.

Android’s ultra-wideband stack becomes a Mainline module

The new com.android.uwb APEX module contains Android’s ultra-wideband stack. Ultra-wideband, or UWB for short, is a short-range, high-frequency wireless communication protocol that is commonly used for precise positioning applications, such as pinpointing the location of a lost object that’s nearby. Android 12 first introduced UWB support but restricted API access. With a new Jetpack library on the way, a reference HAL in the works, and an updateable Mainline module, Android 13 will expand the use of UWB hardware for new software features.

Smart idle maintenance

Android 13 adds a smart idle maintenance service, which intelligently determines when to trigger filesystem defragmentation without hurting the lifetime of the UFS storage chip.

Smart idle maintenance can be manually run through the ‘sm’ shell command:

sm idle-maint [run|abort]

Fast Pair in AOSP

Fast Pair, Google’s proprietary protocol for the nearby detection and pairing of Bluetooth devices, appears to be headed to AOSP as part of the new “com.android.nearby” modular system component. The Fast Pair service is currently implemented in Google Play Services, thus requiring Google Mobile Services to be bundled with the firmware. However, the new NearbyManager system API will be available in AOSP. This will let OEMs set up their own server to sync and serve certified Fast Pair devices’ metadata.

For more details on this platform change and how it will impact the Android ecosystem, refer to this article.

Hardware support for Android’s Identity Credential API

To support the development of mobile driver’s licenses applications on Android, Google created the Identity Credential API. This API provides an interface to a secure store for user identity documents, including not just mobile driver’s licenses but any generic document type. The API can be implemented with or without hardware support, but implementing hardware support enables a greater level of security and privacy.

If a device maker chooses to implement hardware support, they must implement the Identity Credential HAL. Implementing this HAL enables the ability to store identity documents in the device’s secure hardware, which on most devices is their Trusted Execution Environment. Few device makers have implemented the IC HAL, but in Android 13, Google plans to make its implementation a requirement for new chipset launches.

For more details on this upcoming platform change, please refer to this article.

What are the new APIs in Android 13?

Themed Icons API

Google introduced the third major version of their Material design language alongside the Android 12 release last year. One of the key features of Material You — the marketing name of Google’s updated design language — is dynamic color. Dynamic color exposes 5 dynamic color tonal palettes, each comprised of 13 color values with various luminance values, as an API that system and third-party apps can call. Apps can follow the Material guidelines for dynamic color or their own design language when deciding how to use the color palettes to theme their own UIs. Since the dynamic color tonal palettes are generated from a single source color, which is usually picked from the user’s wallpaper, the resulting theme that’s applied across system and third-party apps can vary widely and feel personalized to the user.

An app’s UI isn’t the only area where dynamic color can be used. Widgets can also be recolored, as can some app icons in Android 12 on Pixel devices. In Android 12 on Pixel, Google introduced an experimental “themed icons” feature in their Theme Picker app. When enabled, dynamic colors are applied to various Google app icons whenever the wallpaper is changed. However, Google hardcoded a list of themeable icons within a XML file called grayscale_icon_map contained within the launcher, which also contains the drawable resources for the monochrome app icons.

In Android 12 on Pixel, only Google app icons were themeable. In Android 13, all app icons will be themeable. Source: Google.

In Android 13, Google is extending Material You dynamic color to all app icons. Google has updated the AdaptiveIconDrawable API to support themed app icons. Developers need to simply supply a monochromatic app icon and tweak the element in ic_launcher.xml to include the new inner element that points to the monochromatic drawable. Developers that have already supplied an adaptive icon will find it easy to add support for themed icons in Android 13.

Google says that themed app icons will initially appear on Pixel devices, but the company is working with its partners to bring them to more devices.

The feature can be enabled on Launcher3 by setting both the preference KEY_THEMED_ICONS and the feature flag ENABLE_THEMED_ICONS to true.

Quick Settings Placement API

In Android 7.0 Nougat, Google introduced the TileService API to let apps add their own custom tiles to the Quick Settings. However, in order to add a tile from a third-party app to the Quick Settings, the user needs to pull down the notifications shade, tap the Quick Settings edit button (usually taking the form of a pencil icon), and then scroll down to find the tile they want to add. While third-party apps have numerous ways to inform users about the existence of their custom tiles, users still need to manually add the tile.

A screenshot of a sample app using the new tile placement API to prompt a user to add a tile to the set of active Quick Settings tiles. Source: Google.

Starting in Android 13, however, a new tile placement API will let apps prompt users to directly add their custom tile to the set of active Quick Settings tiles. When an app calls this API, a system dialog will appear that lets the user add the tile in a single tap. This will make it easier for users to discover your app’s custom Quick Settings tiles.

Programmable shaders

The Android Graphics Shading Language (AGSL) is derived from the OpenGL Shading Language (GLSL) but is designed to work within Android’s rendering engine to customize painting within Android’s canvas and filter View content. Android internally uses RuntimeShaders, with behavior defined using AGSL, to implement blur, ripple effects, and stretch overscroll in previous versions of Android. With Android 13, developers can create advanced effects of their own using programmable RuntimeShader objects.

OpenJDK 11 support

Google has been recently experimenting with building Android with Java 11 as the default version, and the company says that they plan to not only refresh Android’s Core Libraries in Android 13 but that these changes will be backported to Android 12 devices through an update to the ART module. This means that Android’s Core Libraries will align with the OpenJDK 11 LTS release, bringing both library updates and new programming language features for app and platform developers.

Runtime permission for notifications

Unlike with other APIs, apps by default can post notifications without requesting any permission. Notifications are the key way for Android apps to interact with users outside of the app, so it makes sense why Google didn’t gate them behind a permission check.

While most apps utilize notifications to post useful alerts and reminders, some apps misuse notifications to send unsolicited advertisements. Android does let users turn off notifications on a per-app and per-channel basis through an interface in Settings, however, this approach has multiple problems. By making notifications opt-out rather than opt-in, and putting the settings to opt-out behind several layers in Settings, most users will keep the default notification settings. Developers and marketers who send notifications to reengage users with their apps and services will find this valuable, but if too many apps post notifications, their importance will be reduced and they’ll feel overwhelming to the user.

That’s why in Android 13, Google is preparing to rework the notification contract between apps and the Android OS. In Android 13, Google has added a runtime permission for notifications. It seems that apps that target API level 33 will be prevented from posting notifications unless they hold the new android.permission.POST_NOTIFICATIONS permission. This permission has a protection level of “dangerous” and hence apps are required to show a runtime prompt to the user in order to be granted the permission. Packages that have not been granted the permission will likely have their notifications silently dropped by the system.

Snippet from the Manifest of the Android framework (‘android’ package)

Apps that target API level 32 or lower won’t be required to hold this permission, though given Google Play’s shifting target API level requirement, developers will eventually need to target API level 33 if they want to release a new app or update an existing app. Users on older versions of Android can continue to block notifications post-install by going to Settings.

This change puts Android in line with iOS, which also requires users to opt-in to notifications from apps. Developers of Android apps will need to put in effort to convince users to turn on notifications.

Conclusion

At Esper, we support Android on a variety of form factors, from handhelds to large screen devices like tablets and POS terminals. Although the release of Android 13 is several months away, we’ll be diligently monitoring new releases to see what new features, behavior changes, and APIs that users, developers, and more importantly, enterprises, need to be aware of. Because Android is a rapidly evolving operating system, it’s easy to fall behind the latest developments. Let Esper manage the software that runs on your device fleet; we care about the nitty-gritty implementation details so you don’t have to.

Article changelog

• 2/10/2022 @ 1:40 PM PT: Added a section on clipboard auto clear
• 2/10/2022 @ 2:17 PM PT: Added sections on the user switcher on the keyguard and lock screen rotation
• 2/10/2022 @ 3:58 PM PT: Corrected the section on Themed Icons to reflect that the feature does work in DP1
• 2/10/2022 @ 7:42 PM PT: Added sections on media tap to transfer and the in-development media player design
• 2/11/2022 @ 09:09 AM PT: Added sections on hub mode and screen saver complications
• 2/11/2022 @ 02:06 PM PT: Added screenshots to the per-app language preferences section and added a section on Material You styles.
• 2/14/2022 @ 02:25 PM PT: Added a section on Fast Pair coming to AOSP
• 2/15/2022 @ 09:35 AM PT: Added a section on hardware support for the Identity Credential API