Google recently introduced Android 12L to the public, and it’s the first major update aimed at large screen devices since the short-lived Android 3.0 Honeycomb release in 2011. Android has matured quite significantly in the last decade, and although Android tablets have not caught up to the iPad in terms of market share, their popularity has grown considerably owing to the COVID-19 pandemic driving work and education to peoples’ homes. Similarly, Chromebooks have been in high demand this past year due to their low cost. On the other end of the price spectrum is the foldable, phones which have captured the attention of casual and enthusiast consumers alike thanks to their novelty. Google sees the growth of these form factors as an opportunity to revitalize Android for large screen devices, which is the driving force behind the changes in Android 12L.
In this article, we’ll dive deep into all the user interface tweaks, new features, behavior changes, and API updates in Android 12L. The bulk of these changes apply to large screen devices, but a few changes also apply to smartphones and other small screen devices.
Table of Contents
- Release date
- User Interface Changes
- New Features
- Behavior Changes
- API Updates
Android 12L Release Date
Android 12L, which is also called Android Sv2, Android SC-V2, or Android 12.1 in documentation, will be released early next year alongside framework API level 32. As of early November, Android 12L is in the Developer Preview phase, and it can only be tested through a system image provided by Google for the Android Emulator. Google will provide an opt-in beta program for Pixel devices starting in December, and some major device makers will also participate in the Android 12L Beta program (thus far, only Lenovo has confirmed its participation, with the Tab P12 Pro). There will be a total of three beta releases, with the first release in December as previously mentioned, followed by a second beta in January 2022 with finalized system behaviors and APIs. The second beta will be the first to use API level 32. The third and final beta release will go live in February 2022, with the final release before the end of Q1 2022.
Although Google states that it has “been careful not to introduce any breaking changes” for app developers in the 12L release, the company will not update Google Play’s target API level requirement to mandate targeting API level 32. However, there are still several notable changes that app developers need to account for, especially if they plan to build applications that target tablets, foldables, or Chromebooks. Device makers that design or manufacture tablets or foldables should also look at what Google is building for Android 12L, even though we can expect few changes to the current compatibility requirements, as the update includes many UI changes and features that Google recommends be adopted or extended. Several device makers have already announced that they will bring some Android 12L features to their existing large screen devices; Samsung, for instance, said it will enable activity embedding on the Galaxy Z Fold 3.
User Interface Changes in Android 12L
Material You for large screen devices
Material You is the third major version of Google’s Material design language, first introduced with Android 5.0 Lollipop in late 2014. Google’s updated design language embraces personalization, adaptive layouts, and accessible styles. Through a new theme engine that dynamically recolors parts of the system, Material You is personal. Through new APIs and user interface changes that make Android look better on tablets and foldables, Material You is adaptive. And finally, through a contextually aware system that customizes the text and size, Material You is accessible.
Material You, also referred to as Material Design 3 or Material Design “Next” in public documentation, made its product debut with Android 12. However, the personalization, adaptability, and accessibility improvements that Material You brought to Android 12 were designed with the smartphone form factor in mind. With the Android 12L release, Google is expanding its redesign efforts to cover large screen devices like tablets and foldables*. Devices with a screen width greater than 600dp have enough real estate to show two panes of content, which is the impetus behind the user interface changes in Android 12L.
Indeed, Android 12L adjusts the layout of multiple system interfaces to take advantage of the wider screens of tablets and foldables. The redesigned elements include the always on display (AOD), lock screen, home screen, notification shade, recent apps overview, power menu, settings, and several system applications.
*Although the term “foldables” typically refers to mobile devices with a foldable display, Google’s definition also covers dual-screen devices (where a hinge physically divides the screen). Thanks to Windows Central for pointing this out.
In Android 12, Google tweaked the lock screen layout to put the clock front and center when all notifications are cleared. By default, AOSP uses a digital clock style, which has been made substantially larger and separated into two rows (one for the hours and one for the minutes). The same is true for large screen devices running Android 12L.
To the top left of the clock is the smart space widget, for which a very basic implementation has been provided as part of AOSP. (A more feature complete implementation can be seen in Google’s Android 12 release for Pixel devices, though the “At a Glance” widget is proprietary to Google.) When there are visible notifications, the clock shifts to the left half of the screen to make room for the notifications column on the right. After 3 notifications are shown, any further notifications will be collapsed in an overflow card. (This configuration is controlled by the integer
keyguard_max_notification_count in SystemUI.)
Additional buttons may be shown on screen depending on the user’s settings. First, if there are multiple profiles on the device, the user account switcher button will appear at the top right. Next, if the user has enabled “show wallet” and “show device controls” in lock screen settings, floating buttons to access the Quick Access Wallet and Device Controls modules will be shown on the bottom right and left, respectively. (In Android 12 and higher, the Wallet UI is part of SystemUI rather than being provided by a separate QuickAccessWallet application. The default package for handling Device Controls remains SystemUI. For more information on implementing Quick Access Wallet and/or Device Controls, please refer to Google’s documentation.)
If the user sets a PIN or pattern to unlock the keyguard, the entry UI will be shown on the left or right half of the screen depending on the side the user swiped from. If the user taps on either the left or right side, the PIN/pattern entry UI will then shift to that side of the screen. This behavior enables one-handed keyguard dismissal on large screen devices. The password entry UI remains centered, with the input method entering its full screen mode.
Always on display
AOSP’s always on display (AOD) implementation does not feature substantial UI differences from the lock screen, as users expect to see a smooth transition between the AOD and lock screen. Like the lock screen, the AOD puts the clock right in the middle of the screen, and it takes up a substantial portion of the viewing area to make the time easy to view at a glance. Beneath the clock, in a much smaller font, is the current battery level. To reduce the number of pixels lit up on the screen on OLED panels, and visual clutter when viewing at a distance, notification previews remain hidden on the AOD in favor of icons.
On large screen devices, Launcher3 is capable of showing two home screen pages simultaneously. This is currently controlled by the Launcher3 flags
In Android 12, and by extension Android 12L, Google significantly revamped the user interface of the notification panel. The brightness slider and Quick Settings tiles have been made substantially larger than before, leaving room for only 8 tiles to be displayed at a time in a 4×2 grid. Text and background color clearly describe the purpose of the tile and its status, though the tile’s description is still shown in the notification panel’s “expanded” state. Expansion of the shade also reveals the build number and allows the user to swipe between pages of Quick Settings tiles.
Beneath the Quick Settings tiles is a row of 3 buttons: Edit, Power Menu, and Settings. The Edit and Settings buttons perform the same actions as before, that is launch the Quick Settings edit flow and the Settings app respectively. Meanwhile, the Power Menu button launches the new compact power menu of Android 12+ in place of the full-screen power menu that integrated the Device Controls and Quick Access Wallet modules of Android 11.
The new, more compact power menu of Android 12+ features up to 2 rows of buttons. The visibility of this new power menu, known internally as “
PMLite”, is set to true by default in AOSP. The power menu is no longer shown by default when the user performs a long-press gesture on the device’s power button; rather, the component set as the default Assistant service is launched when the user long presses the power button. This behavior can be overridden, however. Device makers can also choose whether to surface the setting to change the long press on power button behavior.
Settings is one of the key system applications updated to support a two pane layout. Currently, this interface is gated by a feature flag called
settings_support_large_screen. Once enabled, the Settings UI splits into two panes. The left pane will always show the top-level Settings page, while the right pane will show any Settings subpages that the user opens. If the application supports it, Settings can also embed the Activity specified by the application.
Google made multiple UI changes to the recents overview in Android 12L to accommodate large screen devices. First, the preview card for the app currently in use is much larger. Second, the “split” button to launch the app in split-screen mode is now prominently displayed rather than tucked away behind the context menu that appears when long-pressing the app’s icon. Third, the preview cards for all the previously used apps have been made much smaller to fit within two rows. These UI changes make Android’s multitasking system more discoverable and make switching between recent tasks easier. Coupled with the new taskbar feature, it’s clear that multitasking is a key focus for Google in Android 12L.
Miscellaneous UI changes
- When exiting an app through the back gesture/button, the icon now gracefully animates towards its homescreen location. In Android 12, this animation only occurred when exiting an app through the home gesture/button.
- Settings > Display > Colors now has additional sample photos to showcase how screen mode changes affect color reproduction.
- The screen cast Quick Setting tile now has a chevron indicating it opens a menu rather than acts as an on/off toggle.
- The default position of the slider in audio adjustment settings is now properly centered.
- The default wallpaper included in AOSP has been changed.
These UI changes, while beneficial for large screen consumer hardware, may not be appropriate for enterprise or fleet devices. Because Esper builds Android from source, we can customize, extend, or strip many of these changes. Contact us if you have any requests.
New Features in Android 12L
A staple of desktop operating systems, the taskbar finally makes an appearance in AOSP with Android 12L. Android’s taskbar, like the aforementioned UI changes, only appears on devices with a screen above 600dp. The taskbar is built into Launcher3 and is integrated with the application dock at the bottom of the home screen.
The user’s selection of 5 applications will appear on the taskbar at the bottom of the screen in every application. Google chose an opaque gray color for the taskbar’s background to visually distinguish it from the application window. When the user returns to the home screen, the taskbar’s background becomes transparent to show the wallpaper. The taskbar will automatically minimize when viewing a full-screen application or entering the launcher’s app tray, but it can also be minimized by long-pressing on any part of the taskbar.
The taskbar in Android 12L is rather simple in Developer Preview 1. Users can tap on an app to quickly switch to it, or they can long-press and drag an app’s icon to either half of the screen to quickly launch that app in split-screen mode. The taskbar currently does not support showing recently launched applications, more than 5 applications at a time, or a context menu when long-pressing an app. It also does not integrate any elements currently found in the status bar, such as the date and time, but it does integrate the 3-button navigation keys which are shown on the right edge.
If you wish to test split-screen mode behavior in Android 12L, you can use the new Window Manager shell commands accessed through:
dumpsys activity service SystemUIService WMShell <command>
Here is the documentation for this CLI:
Window Manager Shell commands: help Print this help text.
Dump Window Manager Shell internal state pair unpair Pairs/unpairs tasks with given ids. moveToSideStage Move a task with given id in split-screen mode. removeFromSideStage Remove a task with given id in split-screen mode. setSideStagePosition Sets the position of the side-stage. setSideStageVisibility Show/hide side-stage.
Notification to window
In addition to the taskbar, Google is testing another method in Android 12L to quickly launch an app in split-screen mode. Called notification to window, the feature allows a user to start an app’s PendingIntent (ie. an Activity from a notification) through a notification drag-and-drop gesture. The user can launch an app Activity to a pop-up or split-screen window by long-pressing on a heads-up notification or a notification in the notifications panel and then dragging it to the left or right side of the screen.
This feature is not currently enabled by default in Android 12L preview builds, but it can be by setting the SystemUI configuration value
config_notificationToContents to true. With superuser access, this value can be quickly set to true by creating an overlay through the Fabricated Overlay API or CLI. For example:
cmd overlay fabricate --target com.android.systemui --name NotificationToContents android:bool/config_notificationToContents 0x12 0x01
The generated overlay can then be enabled by running:
cmd overlay enable com.android.shell:NotificationToContents
Note that this feature does not work properly without additional patches; oftentimes, a long press of a heads-up notification will expand to show that notification’s settings rather than pop out as intended. This gesture will likely be optimized in future preview releases.
Dynamic colors in AOSP
Although Google markets its dynamic coloring theme engine as a marquee feature of Android 12, the company did not provide a fully open-source implementation of its theme engine with the AOSP Android 12 source code release. However, that will change with AOSP Android 12L, as not only is the theme engine fully open source, but it is enabled by default in AOSP builds. (This feature is controlled by a SystemUI configuration value called
Material You’s wallpaper-based theming engine, code-named “monet,” generates a rich pastel color palette from the user’s wallpaper. A color extraction engine employing a clustering algorithm with Material color targets determines the dominant and less dominant colors of the user’s wallpaper. A palette generation algorithm then creates a rich palette of 5 colors — 2 neutral and 3 accent colors — and 12 shades of Material color that are used to determine the hues closest to the user’s wallpaper. Finally, these color values are stored in an index that apps can call through an API. (For more information on dynamic color, visit Google’s Material Design 3 documentation.)
With the Android 12L source code release, monet’s palette generation algorithm will be included. The core color extraction algorithm, color appearance model (CAM), and a post-processing/filtering algorithm are already included in the current AOSP Android 12 release, thus many device makers are already moving forward with implementing dynamic colors using their own palette generation algorithm.
For developers looking to test dynamic colors, Android’s “paint chips” widget, which can be added after viewing Android 12’s Easter egg, offers a quick glance at every color generated by the dynamic coloring system.
AOSP does not provide a user affordance to opt out of palette generation once “monet” is enabled, thus every wallpaper change will trigger a change in colors*. This has the added side effect of recreating the activities of every application, akin to a normal configuration change. However, AOSP does not provide a new configuration change type to account for this, so third-party applications cannot opt out of having their activities be destroyed and recreated, as pointed out by CommonsWare. This issue will likely be resolved with the full Android 12L release, as background wallpaper changes can be abused to create a denial-of-service attack, as pointed out by XDA-Developers.
*Although Android does not allow the end-user to opt-out of theme changes when the wallpaper updates, Esper can disable ‘monet’ at the platform level if your business decides it needs to remotely update the wallpaper from our Console.
Dynamic colors in boot animation
Android 12L enables support for dynamic color boot animations. As boot animations are traditionally a sequence of static PNG images, dynamic color is applied to them in a rather clever way. Rather than directly rendering the PNG images contained within the boot animation file, the new dynamic coloring render mode treats the R, G, B, and A channels of each image as area masks, interpolating between the start and end colors based on the progression of the animation.
Device makers can enable dynamic colors for the boot animation by adding the following line as the second line to desc.txt:
dynamic_colors PATH #RGBHEX0 #RGBHEX1 #RGBHEX2 #RGBHEX3
where PATH is the file path of the part to apply the dynamic color transition to, RGBHEX0 is the first start color masked by the R channel, RGBHEX1 is the second start color masked by the G channel, RGBHEX2 is the third start color masked by the B channel, and RGBHEX4 is the fourth start color masked by the A channel.
The end colors, meanwhile, are read from the following four system properties:
Device makers should prepare their PNG images so that the R, G, B, A channels indicate the areas to draw color1, color2, color3 and color4 respectively.
The bootanimation-dark.zip file in Android 12L Developer Preview 1 contains an implementation of this feature. More sample videos can be viewed here.
Press & hold duration for the long-press power button gesture
If the device maker chooses to surface the setting to change the long press on power button gesture, then the user will now have the ability to adjust the gesture’s sensitivity in Android 12L. A new “press & hold duration” slider has been added to the “Press and hold power button” settings page, which lets the user “adjust [the] sensitivity [of the gesture] by choosing how long to press & hold the power button.” The slider ranges from “short” (250ms) to “long” (750ms), with three intermediary values (350, 500, or 650ms). AOSP defaults to a duration of 500ms for triggering this gesture.
Esper can customize the behavior of the power button to meet your needs, whether that’s to disable the assistant invocation, hide the power menu, or do something else.
Quick wallpaper picker
Launcher3’s Developer Options added a new feature flag called “
QUICK_WALLPAPER_PICKER.” Its description reads: “Shows quick wallpaper picker in long-press menu.” When enabled on AOSP, the feature does not seem to function, as the implementation is missing from Launcher3 and WallpaperPicker. In Google builds of Android 12L, however, support for the feature is present. Google’s implementation stores the 5 most recent wallpapers in an array of JSON objects, with the wallpaper’s id, collectionId, thumbnail uri, component, and color. When the user opens the context menu by long-pressing anywhere on the home screen, a carousel containing the thumbnails of these 5 wallpapers is shown at the top.
Google Emoji 14.0
In September, the Unicode Consortium released version 14.0.0 of the Unicode Standard. The updated standard brings 37 new emoji characters. As part of the Android 12L release, Google has updated its Noto Emoji fonts to include the new Emoji 14.0 characters. For a thorough look at the new emoji in Google’s Emoji 14.0 library, we recommend reading Emojipedia’s changelog.
App developers should be aware that starting February 2, 2022, Google Play will require apps running on Android 12 or later to support the latest Unicode Emoji library within 4 months of its release, as pointed out by Android Police. Developers have a few options to remain compliant with this policy update: Enable emoji if AppCompat is in use, use an existing EmojiCompat library across all surfaces within the app, or update the handling and font/images for emoji based on the latest Unicode version. You can read more about Google Play’s upcoming policy changes here, and more specifically about the new Android Emoji policy here.
Behavior Changes in Android 12L
Broader support for multi-window mode
According to Google’s documentation, Android 12 and later releases make multi-window mode standard behavior.
On larger screens (≥ 600dp), Android will force all applications to be resizable regardless of the value they set for the
android:resizeableActivity attribute. However, if this attribute is set to false, then the platform will launch the app in screen compatibility mode to conform to display dimensions. Compatibility mode has been around since the early days of Android, but it has been significantly improved in Android 12L.
On smaller screens (< 600dp), Android will check an activity’s
minHeight to determine if it can run in multi-window mode, assuming that the
android:resizeableActivity attribute is set to true. If it’s false, then Android will not allow the app to run in multi-window mode.
Device makers can override these behaviors by changing the values of
config_respectsActivityMinWidthHeightMultiWindow respectively. These values both default to ‘0’ in AOSP. Developers can override these behaviors at runtime through the ‘wm’ shell command, or by toggling the “force activities to be resizable” and “enable non-resizable in multi window” features in developer options.
Here are the new multi-window shell commands accessed through ‘wm’:
set-multi-window-config Sets options to determine if activity should be shown in multi window: --supportsNonResizable [configValue] Whether the device supports non-resizable activity in multi window. -1: The device doesn't support non-resizable in multi window. 0: The device supports non-resizable in multi window only if this is a large screen device. 1: The device always supports non-resizable in multi window. --respectsActivityMinWidthHeight [configValue] Whether the device checks the activity min width/height to determine if it can be shown in multi window. -1: The device ignores the activity min width/height when determining if it can be shown in multi window. 0: If this is a small screen, the device compares the activity min width/height with the min multi window modes dimensions the device supports to determine if the activity can be shown in multi window. 1: The device always compare the activity min width/height with the min multi window dimensions the device supports to determine if the activity can be shown in multi window. get-multi-window-config Prints values of the multi window config options. reset-multi-window-config Resets overrides to default values of the multi window config options.
Developers are encouraged to build responsive layouts for their apps that adapt to large screen devices. For those apps that have not yet been optimized, such as those that maintain a fixed size or orientation, Android 12L’s screen compatibility mode can letterbox the app and tweak the window frame to provide the best experience on large screens. Apps will be letterboxed if their minimum or maximum aspect ratio is incompatible with the aspect ratio of the display.
Android supports the following UI enhancements to letterboxing:
- Android 12
- App windows can be configured to have rounded corners
- Status bars can be configured to be semitransparent
- An app’s aspect ratio can be configured
- The background type can be configured
- Android 12L
- The default horizontal position of an app window center can be configured
- The restart button UI can be configured
Device makers are responsible for configuring the letterboxing effects, which can be done by overlaying the values
config_letterboxDefaultPositionMultiplierForReachability in the framework. By default, AOSP positions the letterboxed app in the center, does not apply rounded corners to letterboxed app windows, and uses the color #ff76757f for the background (an opaque dark gray).
On Android 12L, device makers and app developers can override these behaviors at runtime through the new ‘
wm set-letterbox-style’ command.
Here are the new letterboxing shell commands accessed through ‘
set-letterbox-style Sets letterbox style using the following options: --aspectRatio aspectRatio Aspect ratio of letterbox for fixed orientation. If aspectRatio <= 1.0 both it and R.dimen.config_fixedOrientationLetterboxAspectRatio will be ignored and framework implementation will determine aspect ratio. --cornerRadius radius Corners radius for activities in the letterbox mode. If radius < 0, both it and R.integer.config_letterboxActivityCornersRadius will be ignored and corners of the activity won't be rounded. --backgroundType [reset|solid_color|app_color_background |app_color_background_floating|wallpaper] Type of background used in the letterbox mode. --backgroundColor color Color of letterbox which is be used when letterbox background type is 'solid-color'. Use (set)get-letterbox-style to check and control letterbox background type. See Color#parseColor for allowed color formats (#RRGGBB and some colors by name, e.g. magenta or olive). --backgroundColorResource resource_name Color resource name of letterbox background which is used when background type is 'solid-color'. Use (set)get-letterbox-style to check and control background type. Parameter is a color resource name, for example, @android:color/system_accent2_50. --wallpaperBlurRadius radius Blur radius for 'wallpaper' letterbox background. If radius <= 0 both it and R.dimen.config_letterboxBackgroundWallpaperBlurRadius are ignored and 0 is used. --wallpaperDarkScrimAlpha alpha Alpha of a black translucent scrim shown over 'wallpaper' letterbox background. If alpha < 0 or >= 1 both it and R.dimen.config_letterboxBackgroundWallaperDarkScrimAlpha are ignored and 0.0 (transparent) is used instead. --horizontalPositionMultiplier multiplier Horizontal position of app window center. If multiplier < 0 or > 1, both it and R.dimen.config_letterboxHorizontalPositionMultiplier are ignored and central position (0.5) is used. --isReachabilityEnabled [true|1|false|0] Whether reachability repositioning is allowed for letterboxed fullscreen apps in landscape device orientation. --defaultPositionForReachability [left|center|right] Default horizontal position of app window when reachability is. enabled. reset-letterbox-style [aspectRatio|cornerRadius|backgroundType |backgroundColor|wallpaperBlurRadius|wallpaperDarkScrimAlpha |horizontalPositionMultiplier|isReachabilityEnabled |defaultPositionMultiplierForReachability] Resets overrides to default values for specified properties separated by space, e.g. 'reset-letterbox-style aspectRatio cornerRadius'. If no arguments provided, all values will be reset. get-letterbox-style Prints letterbox style configuration.
Letterboxing can provide the best experience possible without needing to update an app, but it should not be used as a crutch. If your hardware has an uncommon aspect ratio and the app you want to run cannot be updated, consider tweaking the letterboxing effects to display the app in the best light.
New scaling method for media projection
Google is improving the screen casting experience in Android 12L. When an app uses the media projection API to project the real device’s display onto a virtual display, the system will scale the virtual display to maximize the size of the image on the application-provided Surface while maintaining the proper aspect ratio, in a process similar to ImageView’s
centerInside scale type.
Device makers can override an app’s preferred orientation
screenOrientation Manifest attribute, app developers can specify the orientation that their applications should run in, regardless of the orientation of the device. This lets developers present their app in a fixed aspect ratio, but it results in usability issues on foldable devices that can be oriented based on their fold.
In Android 12 and above, device makers can configure individual device screens to ignore the
screenOrientation attribute, overriding an app’s request for a preferred orientation.
This behavior can be controlled at runtime through the ‘
wm’ shell command:
fixed-to-user-rotation [-d DISPLAY_ID] [enabled|disabled|default] Print or set rotating display for app requested orientation. set-ignore-orientation-request [-d DISPLAY_ID] [true|1|false|0] get-ignore-orientation-request [-d DISPLAY_ID] If app requested orientation should be ignored.
Re-enable volume adjustment for remote media sessions
Casting audio to an external device is a common feature of many media player apps, and for user convenience, most media players also support remote volume adjustment. After configuring a media session to use remote volume handling through
MediaSessionCompat.setPlaybackToRemote(VolumeProviderCompat volumeProvider), apps can receive volume key events. However, this is not the case in Android 12, as the platform no longer passes the volume key event to remote sessions.
On the Google Issue Tracker, a Google employee stated that this behavior will be reverted in SC V2, the code-name for Android 12L. This was reiterated in another comment, which confirmed that Google is working on “a solution to mitigate the situation” that will be included “in 12.1,” or, in other words, Android 12L.
The reason this change was made in the first place was due to an unspecified “legal issue,” according to that same Google employee. The code change in question was committed around the same time that a U.S. International Trade Commission judge issued a preliminary ruling that Google infringed on some of Sonos’ audio patents, as reported by The Verge.
API Updates in Android 12L
As a feature update, Android 12L does not include many new APIs. There are, however, a few notable additions to the platform, which we’ll summarize in this section.
Activity embedding for two-pane browsing
Activity embedding is one of the key ways that apps can take advantage of the larger screens of tablets, foldables, and Chromebooks. As its name suggests, activity embedding enables showing multiple activities at once, usually side by side. The app task window is split into two containers (primary and secondary) that hold activities launched from the main activity or from other activities already in the containers. Activities in the secondary container are stacked as they’re launched. Note that only system and pre-installed apps holding the permission
android.permission.LAUNCH_TWO_PANE_SETTINGS_DEEP_LINK can show their activity in the secondary container of the Settings app.
As the feature handles device orientation and foldable state changes seamlessly, it will be useful for providing an enhanced user experience on large screen devices. Support for activity embedding is baked into Android 12L, but Google says that it will be available on some devices running earlier versions of Android. Samsung, for instance, confirmed that its Galaxy Z Fold 3 will support activity embedding, as reported by 9to5Google. App developers can check whether activity embedding is supported on a device by calling
Rather than calling the new platform API directly, Google has added support for activity embedding in the latest Jetpack WindowManager release. Version 1.0.0-beta03 includes experimental support for activity embedding. The initial release allows for showing two activities side by side, though only the activity that created the split can occupy the primary container, while the secondary container can contain a stack of activities.
For more information, including how back navigation is handled, how to build a multi-pane layout, how to proportion the task window, how to configure split rules, and what the current limitations are, read Google’s documentation on activity embedding.
Audio spatialization with dynamic head tracking
Spatial audio is a feature that has existed for years, but thanks to new consumer hardware from the likes of Sony, Apple, and Oculus, it has never been more popular. The feature creates the effect of 3D audio, “[simulating] sounds originating around the listener as if they were coming from virtual speakers placed around the listener,” as explained by Google in its documentation for the new Spatializer API in Android 12L.
The new Spatializer API lets developers query the capabilities and behavior of sound spatialization on the device. Google says that support for audio spatialization is optional, and if supported, the
AudioManager#getSpatializer() method will return a handle to the platform’s Spatializer instance. Developers can also query whether the device supports multichannel spatialization, whether audio of a particular AudioFormat can be spatialized, and more.
The following shell command reveals the spatial audio capabilities of the device:
dumpsys audio | grep -A 4 Spatial
Spatial audio: mHasSpatializerEffect:false isSpatializerEnabled:false isSpatialAudioEnabled:true
An examination of the system services in Android 12L DP1 reveals additional details on the spatial audio feature.
First, we’ve learned that Google is working on dynamic head tracking support, a feature that’s available on the latest iPhone and iPad when paired to Apple’s latest audio accessories. Head tracking builds upon spatial audio by tracking the position of the user’s head to virtually reposition the sound channels accordingly, providing an even more immersive audio experience. Head tracking is handled by the headphones worn by the user; the accelerometer and gyroscope within the paired accessory determine the position of the user’s head, while additional data from the mobile device determines the position relative to the screen. Like iOS, Android 12L appears to include support for full screen-to-head tracking. There will be three head tracking modes: static (ie. no head tracking), world relative (no screen tracking), and screen relative (full screen-to-head tracking).
Second, we learned that there will be two supported spatialization modes: binaural and transaural. The former means that the spatializer supports producing spatial audio over headphones, while the latter means that it supports it over the loudspeaker.
Exact implementation details have not been published yet, so there are many details we do not know (what Google’s generic head tracker sensor implementation looks like, for example). We will examine future preview releases to learn more about this feature.
Accessibility actions for drag-and-drop
Android’s Accessibility API lets developers build services that help users with accessibility needs. Users who find it difficult to interact with a touchscreen may be unable to perform certain gestures, such as a drag-and-drop. In Android 12L, a drag-and-drop gesture is used to launch an app in split-screen mode from the taskbar. To accommodate those users who may have trouble performing this gesture, which is also used to share data between apps in split-screen view, the Accessibility API has added the following three actions:
Android’s shared “external” storage contains media files, some application data, and other files that are readable by other applications or the user. Before Android 10, applications could gain broad read/write access to the external storage through the
WRITE_EXTERNAL_STORAGE runtime permissions. With the introduction of Scoped Storage in Android 10 (API level 29), however, Google began to restrict access to external storage. As a consequence, two widely used external storage APIs —
Environment.getExternalStoragePublicDirectory() — were deprecated. The former returned the primary external storage root directory, while the latter returned the public external storage directory for saving files of a particular type. With API level 32, Google has decided to undeprecate these two APIs. The reason is that while Android 10 did not support file path operations for apps restricted by Scoped Storage, Android 11 largely restored read access to external storage.
As noted by CommonsWare, however, this does not change storage access rights. Scoped Storage rules still apply, which means that apps cannot read or write to content created by other apps in public directories unless given proper permissions.
Another API that has been undeprecated is the
DATA constant in
MediaStore.MediaColumns. This field was also deprecated with API level 29 when Scoped Storage was first implemented.
More contextual assistant with VoiceInteractionSession updates
Android, through the VoiceInteractionSession API, lets virtual assistant applications receive data from the application that the user is currently viewing when the assistant was invoked. That information can come in the form of a screenshot of what the user is currently viewing, which can then be analyzed via OCR. The Assistant can even request a list of supported actions from within an app. Google’s own Assistant app utilizes this API to obtain contextual information about the app the user is viewing, and in Android 12L, the API is getting even more powerful.
VoiceInteractionSession has added two new callbacks: registerVisibleActivityCallback and unregisterVisibleActivityCallback. The former will let the assistant app register a callback to be notified when there’s a change in the visible activity, while the latter simply unregisters the callback. This will enable more powerful uses of the assistant service, as the service can track the user’s journey from app to app. Knowing what application a user just opened provides a lot of context for what action they might want to take next. The “new” Google Assistant, a faster version of the Google Assistant that’s exclusive to select Pixel devices, will likely make extensive use of this new capability.
At Esper, we support Android on a variety of form factors, including large screen devices like tablets and POS terminals. Although the release of Android 12L is several months away, we’re diligently monitoring the update to see which large screen UI changes to pick, what behavior changes we need to account for, and what features we’ll support. Android is a constantly evolving operating system, so it’s easy to fall behind given the rapid pace of development. 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.