Earlier this year, we released version alpha02 of the JetPack Windows Manager library, a major release update that included some of the deprecated APIs (currently available as version 1.0.0-alpha09). This article reviews the update for you.

The JetPack WindowManager library helps you build applications that are aware of new device features such as folding and hinges, using new features that didn’t exist before. In developing the JetPack WindowManager library, we incorporated developer feedback and continued to iterate over the API in Alpha to provide a cleaner and more complete API interface. We’ve been looking at different areas in the Windows Manager space to provide more functionality, and we’ve introduced Windows Metrics, So that you can use the new APIs added to Android 11 in Android 4.1 (API Level 16) and up.

After the first release, we spent a lot of time analyzing developer feedback and made a lot of updates in Alpha02. Let’s take a look at what’s coming in Alpha02!

Create a new Windows Manager

The Alpha02 version provides a simple constructor that takes a single argument to the Context of a visible entity (such as the currently displayed Activity) :

val windowManager = WindowManager(context: Context)

The original constructor is still available, but has been marked deprecated:

val windowManager = WindowManager(context: Context, windowBackend: WindowBackend?)

When you want to emulate a foldable device with a custom WindowBackend on a common device or emulator, you can test using the original constructor. The implementation in this sample project is for your reference.

In version alpha02, you can still pass null to the parameter WindowBackend. We plan to set WindowBackend as a required parameter in future versions and remove the DEPRECATION flag to promote the use of this interface during testing.

Add DisplayFeature deprecated DeviceState

Another significant change is the deprecation of the DeviceState class, as well as the callbacks that use it to notify you of your application. We do this because we want to provide more generic APIs that allow the system to return all available DisplayFeature instances to your application, rather than defining the global device state. We have removed DeviceState from the public API in Alpha06 version, please use FoldingFeature instead.

Version Alpha02 introduces a new DisplayFeature class with an updated callback protocol to notify your application when the DisplayFeature changes. You can register, unregister callbacks to use these methods:

registerLayoutChangeCallback(@NonNull Executor executor, @NonNull Consumer<WindowLayoutInfo> callback)

unregisterLayoutChangeCallback(@NonNull Consumer<WindowLayoutInfo> callback)

Windows LayoutInfo contains a list of DisplayFeature instances located within the window.

The FoldingFeature class implements the DisplayFeature interface, which contains information about the following types of functionality:


The possible folding states of the device are as follows:

Possible states of the DisplayFeature: Fully expanded, partially open, and flipped

Note that there is no state corresponding to Posture_unknown and Posture_closed postures in DeviceState.

To get the latest status information, you can use the FoldingFeature information returned by the registered callback:

class LayoutStateChangeCallback : Consumer<WindowLayoutInfo> { override fun accept(newLayoutInfo: WindowLayoutInfo) {// Check the return value of newLayoutInfo.getDisplayFeatures () to see if it is an instance of FoldingFeature and get the information in it. }}

How to use this information, please refer to: https://github.com/android/user-interface-samples/tree/main/WindowManager.

Better callback registration

The callback API for the sample code above is also more robust. In previous versions, an exception was thrown if the application registered a callback before the window was available.

In the APLHA02 release we changed the above behavior. You can register these callbacks at any time that is useful for your application design, and the library will send the initial WindowLayoutInfo when the Window is available.

The R8 rules

We added R8’s “keep” rule to the library to preserve methods or classes that might have been removed due to the organizational structure of the internal modules. These rules are automatically incorporated into the final R8 rules that are applied, which prevents the application from crashing as it did in the Alpha01 version.


Due to historical naming conventions and various possible Window Manager states, it can be difficult to get the size information of the current Window on Android. Some of the deprecated approaches in Android 11 (such as Display#getSize and Display#getMetrics) and the use of the new API for window size highlight the growing trend of foldable devices moving from full screen to multi-window and adaptive Windows. To simplify this transition, we added the WindowMetrics API to Android 11.

Before the first layout is complete, Windows Metrics allows you to easily obtain information about the current state of the window and the maximum window size in the current state of the system. On devices like the Surface Duo, for example, the device has a default configuration that determines which screen the app launches from, but it can also be expanded across the device’s hinge to two screens. In its default state, the ‘getMaximumWindowMetrics’ method returns boundary information about the screen on which the application is currently located. When the application is moved to a cross-screen state, the ‘getMaximumWindowMetrics’ method returns boundary information that reflects the new state. This information is provided as early as onCreate, and your Activity can use it to perform calculations or make early decisions to choose the right layout in the first place.

The results returned by the API do not include system inset information, such as the status bar or navigation bar, because in all currently supported versions of Android, the areas corresponding to these values are not available until the first layout is completed. Chris Banes’ article Handling Visual Conflicts with | Gesture Navigation (II) is a great resource for using ViewCompat to get information about the insets available on the system. The boundary information returned by the API also does not respond to layout parameters that may change when the layout is populated.

To access these APIs, you need to first get a Windows Manager object as explained above:

val windowManager = WindowManager(context: Context)

You now have access to the WindowMetrics API and can easily get the size and maximum size information for the current Window.



For example, if your app has a very different layout or navigation mode on the phone and the tablet, you can rely on this information to make layout choices before the view fills in. If you think the user will be confused by the obvious change in the layout, you can ignore the change in the current window size information and select some of the information as constant. Before choosing which to populate, you can use the Window maximum size information.

Although the Android 11 platform already includes an API for getting inset information during onCreate, we haven’t added this API to the Windows Manager library because we wanted to know which of these features would be useful to developers. You can give positive feedback so that we know what values or abstractions you need to know to make it easier to write a layout before you make your first layout.

We hope that these APIs, which are available on lower versions of Android, will help you build applications that respond to window size changes, as well as help you replace the obsolete APIs mentioned above.

Contact us

We’d love to get your feedback on these APIs, especially those that you feel are missing or that will make your development easier. There are some usage scenarios that we may not have considered, so we encourage you to submit bugs or feature requirements to us on Public Tracker.