WindowManager

COMPAT_SMALL_COVER_SCREEN_OPT_IN

public static final int COMPAT_SMALL_COVER_SCREEN_OPT_IN

Value applicable for the PROPERTY_COMPAT_ALLOW_SMALL_COVER_SCREEN property to provide a signal to the system that an application or its specific activities explicitly opt into being displayed on small cover screens on flippable style foldable devices that measure at least 1.5 inches up to 2.2 inches for the shorter dimension and at least 2.4 inches up to 3.4 inches for the longer dimension
Value is COMPAT_SMALL_COVER_SCREEN_OPT_IN

Constant Value: 1 (0x00000001)

PROPERTY_ACTIVITY_EMBEDDING_ALLOW_SYSTEM_OVERRIDE

public static final String PROPERTY_ACTIVITY_EMBEDDING_ALLOW_SYSTEM_OVERRIDE

Application-level PackageManager.Property tag that specifies whether OEMs are permitted to provide activity embedding split-rule configurations on behalf of the app.

If true, the system is permitted to override the app's windowing behavior and implement activity embedding split rules, such as displaying activities side by side. A system override informs the app that the activity embedding APIs are disabled so the app doesn't provide its own activity embedding rules, which would conflict with the system's rules.

If false, the system is not permitted to override the windowing behavior of the app. Set the property to false if the app provides its own activity embedding split rules, or if you want to prevent the system override for any other reason.

The default value is false.

Note: Refusal to permit the system override is not enforceable. OEMs can override the app's activity embedding implementation whether or not this property is specified and set to false. The property is, in effect, a hint to OEMs.

OEMs can implement activity embedding on any API level. The best practice for apps is to always explicitly set this property in the app manifest file regardless of targeted API level rather than rely on the default value.

Syntax:

 <application>
   <property
     android:name="android.window.PROPERTY_ACTIVITY_EMBEDDING_ALLOW_SYSTEM_OVERRIDE"
     android:value="true|false"/>
 </application>
 

Constant Value: "android.window.PROPERTY_ACTIVITY_EMBEDDING_ALLOW_SYSTEM_OVERRIDE"

PROPERTY_ACTIVITY_EMBEDDING_SPLITS_ENABLED

public static final String PROPERTY_ACTIVITY_EMBEDDING_SPLITS_ENABLED

Application level PackageManager.Property that an app can specify to inform the system that the app is activity embedding split feature enabled.

With this property, the system could provide custom behaviors for the apps that are activity embedding split feature enabled. For example, the fixed-portrait orientation requests of the activities could be ignored by the system in order to provide seamless activity embedding split experiences while holding large screen devices in landscape orientation.

Syntax:

 <application>
   <property
     android:name="android.window.PROPERTY_ACTIVITY_EMBEDDING_SPLITS_ENABLED"
     android:value="true|false"/>
 </application>
 

Constant Value: "android.window.PROPERTY_ACTIVITY_EMBEDDING_SPLITS_ENABLED"

PROPERTY_CAMERA_COMPAT_ALLOW_FORCE_ROTATION

public static final String PROPERTY_CAMERA_COMPAT_ALLOW_FORCE_ROTATION

Application level PackageManager.Property for an app to inform the system that the app should be excluded from the camera compatibility force rotation treatment.

The camera compatibility treatment aligns portrait app windows with the natural orientation of the device and landscape app windows opposite the device natural orientation. Mismatch between the orientations can lead to camera issues like a sideways or stretched viewfinder since this is one of the strongest assumptions that apps make when they implement camera previews. Since app and device natural orientations aren't guaranteed to match, the rotation can cause letterboxing. The forced rotation is triggered as soon as an app opens the camera and is removed once camera is closed.

Camera compatibility can be enabled by device manufacturers on displays that have the ignore requested orientation display setting enabled, which enables compatibility mode for fixed-orientation apps on Android 12 (API level 31) or higher. See Device compatibility mode for more details.

With this property set to true or unset, the system may apply the force rotation treatment to fixed-orientation activities. Device manufacturers can exclude packages from the treatment using their discretion to improve display compatibility.

With this property set to false, the system will not apply the force rotation treatment.

Syntax:

 <application>
   <property
     android:name="android.window.PROPERTY_CAMERA_COMPAT_ALLOW_FORCE_ROTATION"
     android:value="true|false"/>
 </application>
 

Constant Value: "android.window.PROPERTY_CAMERA_COMPAT_ALLOW_FORCE_ROTATION"

PROPERTY_CAMERA_COMPAT_ALLOW_REFRESH

public static final String PROPERTY_CAMERA_COMPAT_ALLOW_REFRESH

Application level PackageManager.Property for an app to inform the system that the app should be excluded from the activity "refresh" after the camera compatibility force rotation treatment.

The camera compatibility treatment aligns portrait app windows with the natural orientation of the device and landscape app windows opposite the device natural orientation. Mismatch between the orientations can lead to camera issues like a sideways or stretched viewfinder since this is one of the strongest assumptions that apps make when they implement camera previews. Since app and device natural orientations aren't guaranteed to match, the rotation can cause letterboxing. The forced rotation is triggered as soon as an app opens the camera and is removed once camera is closed.

Force rotation is followed by the "Refresh" of the activity by going through "resumed -> ... -> stopped -> ... -> resumed" cycle (by default) or "resumed -> paused -> resumed" cycle (if overridden, see PROPERTY_CAMERA_COMPAT_ENABLE_REFRESH_VIA_PAUSE for context). This allows to clear cached values in apps (e.g. display or camera rotation) that influence camera preview and can lead to sideways or stretching issues persisting even after force rotation.

The camera compatibility can be enabled by device manufacturers on displays that have the ignore requested orientation display setting enabled, which enables compatibility mode for fixed-orientation apps on Android 12 (API level 31) or higher. See Device compatibility mode for more details.

With this property set to true or unset, the system may "refresh" activity after the force rotation treatment. Device manufacturers can exclude packages from the "refresh" using their discretion to improve display compatibility.

With this property set to false, the system will not "refresh" activity after the force rotation treatment.

Syntax:

 <application>
   <property
     android:name="android.window.PROPERTY_CAMERA_COMPAT_ALLOW_REFRESH"
     android:value="true|false"/>
 </application>
 

Constant Value: "android.window.PROPERTY_CAMERA_COMPAT_ALLOW_REFRESH"

PROPERTY_CAMERA_COMPAT_ENABLE_REFRESH_VIA_PAUSE

public static final String PROPERTY_CAMERA_COMPAT_ENABLE_REFRESH_VIA_PAUSE

Application level PackageManager.Property for an app to inform the system that the activity should be or shouldn't be "refreshed" after the camera compatibility force rotation treatment using "paused -> resumed" cycle rather than "stopped -> resumed".

The camera compatibility treatment aligns orientations of portrait app window and natural orientation of the device. Mismatch between the orientations can lead to camera issues like a sideways or stretched viewfinder since this is one of the strongest assumptions that apps make when they implement camera previews. Since app and natural display orientations aren't guaranteed to match, the rotation can cause letterboxing. The forced rotation is triggered as soon as app opens the camera and is removed once camera is closed.

Force rotation is followed by the "Refresh" of the activity by going through "resumed -> ... -> stopped -> ... -> resumed" cycle (by default) or "resumed -> paused -> resumed" cycle (if overridden by device manufacturers or using this property). This allows to clear cached values in apps (e.g., display or camera rotation) that influence camera preview and can lead to sideways or stretching issues persisting even after force rotation.

The camera compatibility can be enabled by device manufacturers on displays that have the ignore requested orientation display setting enabled, which enables compatibility mode for fixed-orientation apps on Android 12 (API level 31) or higher. See Device compatibility mode for more details.

Device manufacturers can override packages to "refresh" via "resumed -> paused -> resumed" cycle using their discretion to improve display compatibility.

With this property set to true, the system will "refresh" activity after the force rotation treatment using "resumed -> paused -> resumed" cycle.

With this property set to false, the system will not "refresh" activity after the force rotation treatment using "resumed -> paused -> resumed" cycle even if the device manufacturer adds the corresponding override.

Syntax:

 <application>
   <property
     android:name="android.window.PROPERTY_CAMERA_COMPAT_ENABLE_REFRESH_VIA_PAUSE"
     android:value="true|false"/>
 </application>
 

Constant Value: "android.window.PROPERTY_CAMERA_COMPAT_ENABLE_REFRESH_VIA_PAUSE"

PROPERTY_COMPAT_ALLOW_DISPLAY_ORIENTATION_OVERRIDE

public static final String PROPERTY_COMPAT_ALLOW_DISPLAY_ORIENTATION_OVERRIDE

Application level PackageManager.Property for an app to inform the system that the app should be opted-out from the compatibility override that fixes display orientation to landscape natural orientation when an activity is fullscreen.

When this compat override is enabled and while display is fixed to the landscape natural orientation, the orientation requested by the activity will be still respected by bounds resolution logic. For instance, if an activity requests portrait orientation, then activity appears in letterbox mode for fixed-orientation apps with the display rotated to the lanscape natural orientation.

The treatment is disabled by default but device manufacturers can enable the treatment using their discretion to improve display compatibility on displays that have the ignore orientation request display setting enabled by OEMs on the device, which enables compatibility mode for fixed-orientation apps on Android 12 (API level 31) or higher. See Device compatibility mode for more details.

With this property set to true or unset, the system wiil use landscape display orientation when the following conditions are met:

• Natural orientation of the display is landscape
• ignore requested orientation display setting is enabled
• Activity is fullscreen.
• Device manufacturer enabled the treatment.

With this property set to false, device manufacturer per-app override for display orientation won't be applied.

Syntax:

 <application>
   <property
     android:name="android.window.PROPERTY_COMPAT_ALLOW_DISPLAY_ORIENTATION_OVERRIDE"
     android:value="true|false"/>
 </application>
 

Constant Value: "android.window.PROPERTY_COMPAT_ALLOW_DISPLAY_ORIENTATION_OVERRIDE"

PROPERTY_COMPAT_ALLOW_IGNORING_ORIENTATION_REQUEST_WHEN_LOOP_DETECTED

public static final String PROPERTY_COMPAT_ALLOW_IGNORING_ORIENTATION_REQUEST_WHEN_LOOP_DETECTED

Application level PackageManager.Property for an app to inform the system that the app can be opted-out from the compatibility treatment that avoids Activity#setRequestedOrientation() loops. Loops can be triggered by the OEM-configured ignore requested orientation display setting (on Android 12 (API level 31) and higher) or by the landscape natural orientation of the device.

The system could ignore Activity#setRequestedOrientation() call from an app if both of the following conditions are true:

• Activity has requested orientation more than two times within one-second timer
• Activity is not letterboxed for fixed-orientation apps

Setting this property to false informs the system that the app must be opted-out from the compatibility treatment even if the device manufacturer has opted the app into the treatment.

Not setting this property at all, or setting this property to true has no effect.

Syntax:

 <application>
   <property
     android:name=
       "android.window.PROPERTY_COMPAT_ALLOW_IGNORING_ORIENTATION_REQUEST_WHEN_LOOP_DETECTED"
     android:value="false"/>
 </application>
 

Constant Value: "android.window.PROPERTY_COMPAT_ALLOW_IGNORING_ORIENTATION_REQUEST_WHEN_LOOP_DETECTED"

PROPERTY_COMPAT_ALLOW_MIN_ASPECT_RATIO_OVERRIDE

public static final String PROPERTY_COMPAT_ALLOW_MIN_ASPECT_RATIO_OVERRIDE

Application level PackageManager.Property for an app to inform the system that the app should be opted-out from the compatibility override that changes the min aspect ratio.

When this compat override is enabled the min aspect ratio given in the app's manifest can be overridden by the device manufacturer using their discretion to improve display compatibility unless the app's manifest value is higher. This treatment will also apply if no min aspect ratio value is provided in the manifest. These treatments can apply either in specific cases (e.g. device is in portrait) or each time the app is displayed on screen.

Setting this property to false informs the system that the app must be opted-out from the compatibility treatment even if the device manufacturer has opted the app into the treatment.

Not setting this property at all, or setting this property to true has no effect.

Syntax:

 <application>
   <property
     android:name="android.window.PROPERTY_COMPAT_ALLOW_MIN_ASPECT_RATIO_OVERRIDE"
     android:value="true|false"/>
 </application>
 

Constant Value: "android.window.PROPERTY_COMPAT_ALLOW_MIN_ASPECT_RATIO_OVERRIDE"

PROPERTY_COMPAT_ALLOW_ORIENTATION_OVERRIDE

public static final String PROPERTY_COMPAT_ALLOW_ORIENTATION_OVERRIDE

Application level PackageManager.Property for an app to inform the system that the app should be excluded from the compatibility override for orientation set by the device manufacturer. When the orientation override is applied it can:

• Replace the specific orientation requested by the app with another selected by the device manufacturer; for example, replace undefined requested by the app with portrait.
• Always use an orientation selected by the device manufacturer.
• Do one of the above but only when camera connection is open.

This property is different from PROPERTY_COMPAT_IGNORE_REQUESTED_ORIENTATION (which is used to avoid orientation loops caused by the incorrect use of Activity#setRequestedOrientation()) because this property overrides the app to an orientation selected by the device manufacturer rather than ignoring one of orientation requests coming from the app while respecting the previous one.

With this property set to true or unset, device manufacturers can override orientation for the app using their discretion to improve display compatibility.

With this property set to false, device manufacturer per-app override for orientation won't be applied.

Syntax:

 <application>
   <property
     android:name="android.window.PROPERTY_COMPAT_ALLOW_ORIENTATION_OVERRIDE"
     android:value="true|false"/>
 </application>
 

Constant Value: "android.window.PROPERTY_COMPAT_ALLOW_ORIENTATION_OVERRIDE"

PROPERTY_COMPAT_ALLOW_RESIZEABLE_ACTIVITY_OVERRIDES

public static final String PROPERTY_COMPAT_ALLOW_RESIZEABLE_ACTIVITY_OVERRIDES

Application level PackageManager.Property for an app to inform the system that the app should be opted-out from the compatibility overrides that change the resizability of the app.

When these compat overrides are enabled they force the packages they are applied to to be resizable/unresizable. If the app is forced to be resizable this won't change whether the app can be put into multi-windowing mode, but allow the app to resize without going into size compatibility mode when the window container resizes, such as display size change or screen rotation.

Setting this property to false informs the system that the app must be opted-out from the compatibility treatment even if the device manufacturer has opted the app into the treatment.

Not setting this property at all, or setting this property to true has no effect.

Syntax:

 <application>
   <property
     android:name="android.window.PROPERTY_COMPAT_ALLOW_RESIZEABLE_ACTIVITY_OVERRIDES"
     android:value="true|false"/>
 </application>
 

Constant Value: "android.window.PROPERTY_COMPAT_ALLOW_RESIZEABLE_ACTIVITY_OVERRIDES"

PROPERTY_COMPAT_ALLOW_SANDBOXING_VIEW_BOUNDS_APIS

public static final String PROPERTY_COMPAT_ALLOW_SANDBOXING_VIEW_BOUNDS_APIS

Application level PackageManager.Property for an app to inform the system that it needs to be opted-out from the compatibility treatment that sandboxes the View API.

The treatment can be enabled by device manufacturers for applications which misuse View APIs by expecting that View#getLocationOnScreen() and View#getWindowVisibleDisplayFrame() return coordinates as if an activity is positioned in the top-left corner of the screen, with left coordinate equal to 0. This may not be the case for applications in multi-window and letterbox modes.

Setting this property to false informs the system that the application must be opted-out from the "Sandbox View API to Activity bounds" treatment even if the device manufacturer has opted the app into the treatment.

Not setting this property at all, or setting this property to true has no effect.

Syntax:

 <application>
   <property
     android:name="android.window.PROPERTY_COMPAT_ALLOW_SANDBOXING_VIEW_BOUNDS_APIS"
     android:value="false"/>
 </application>
 

Constant Value: "android.window.PROPERTY_COMPAT_ALLOW_SANDBOXING_VIEW_BOUNDS_APIS"

PROPERTY_COMPAT_ALLOW_SMALL_COVER_SCREEN

public static final String PROPERTY_COMPAT_ALLOW_SMALL_COVER_SCREEN

Application or Activity level PackageManager.Property to provide any preferences for showing all or specific Activities on small cover displays of foldable style devices.

The only supported value for the property is COMPAT_SMALL_COVER_SCREEN_OPT_IN.

Syntax:

 <application>
   <property
     android:name="android.window.PROPERTY_COMPAT_ALLOW_SMALL_COVER_SCREEN"
     android:value=1 />
 </application>
 

Constant Value: "android.window.PROPERTY_COMPAT_ALLOW_SMALL_COVER_SCREEN"

PROPERTY_COMPAT_ALLOW_USER_ASPECT_RATIO_FULLSCREEN_OVERRIDE

public static final String PROPERTY_COMPAT_ALLOW_USER_ASPECT_RATIO_FULLSCREEN_OVERRIDE

Application level PackageManager.Property tag that (when set to false) informs the system the app has opted out of the full-screen option of the user aspect ratio compatibility override settings. (For background information about the user aspect ratio compatibility override, see PROPERTY_COMPAT_ALLOW_USER_ASPECT_RATIO_OVERRIDE.)

When users apply the full-screen compatibility override, the orientation of the activity is forced to ActivityInfo.SCREEN_ORIENTATION_USER.

The user override is intended to improve the app experience on devices that have the ignore orientation request display setting enabled by OEMs, which enables compatibility mode for fixed-orientation apps on Android 12 (API level 31) or higher. See Device compatibility mode for more details.

To opt out of the full-screen option of the user aspect ratio compatibility override, add this property to your app manifest and set the value to false. Your app will have full-screen option removed from the list of user aspect ratio override options in device settings, and users will not be able to apply full-screen override to your app.

Note: If PROPERTY_COMPAT_ALLOW_USER_ASPECT_RATIO_OVERRIDE is false, this property has no effect.

Not setting this property at all, or setting this property to true has no effect.

Syntax:

 <application>
   <property
     android:name="android.window.PROPERTY_COMPAT_ALLOW_USER_ASPECT_RATIO_FULLSCREEN_OVERRIDE"
     android:value="false"/>
 </application>
 

Constant Value: "android.window.PROPERTY_COMPAT_ALLOW_USER_ASPECT_RATIO_FULLSCREEN_OVERRIDE"

PROPERTY_COMPAT_ALLOW_USER_ASPECT_RATIO_OVERRIDE

public static final String PROPERTY_COMPAT_ALLOW_USER_ASPECT_RATIO_OVERRIDE

Application level PackageManager.Property tag that (when set to false) informs the system the app has opted out of the user-facing aspect ratio compatibility override.

The compatibility override enables device users to set the app's aspect ratio or force the app to fill the display regardless of the aspect ratio or orientation specified in the app manifest.

The aspect ratio compatibility override is exposed to users in device settings. A menu in device settings lists all apps that have not opted out of the compatibility override. Users select apps from the menu and set the app aspect ratio on a per-app basis. Typically, the menu is available only on large screen devices.

When users apply the aspect ratio override, the minimum aspect ratio specified in the app manifest is overridden. If users choose a full-screen aspect ratio, the orientation of the activity is forced to ActivityInfo.SCREEN_ORIENTATION_USER; see PROPERTY_COMPAT_ALLOW_USER_ASPECT_RATIO_FULLSCREEN_OVERRIDE to disable the full-screen option only.

The user override is intended to improve the app experience on devices that have the ignore orientation request display setting enabled by OEMs, which enables compatibility mode for fixed-orientation apps on Android 12 (API level 31) or higher. See Device compatibility mode for more details.

To opt out of the user aspect ratio compatibility override, add this property to your app manifest and set the value to false. Your app will be excluded from the list of apps in device settings, and users will not be able to override the app's aspect ratio.

Not setting this property at all, or setting this property to true has no effect.

Syntax:

 <application>
   <property
     android:name="android.window.PROPERTY_COMPAT_ALLOW_USER_ASPECT_RATIO_OVERRIDE"
     android:value="false"/>
 </application>
 

Constant Value: "android.window.PROPERTY_COMPAT_ALLOW_USER_ASPECT_RATIO_OVERRIDE"

PROPERTY_COMPAT_ENABLE_FAKE_FOCUS

public static final String PROPERTY_COMPAT_ENABLE_FAKE_FOCUS

Application level PackageManager.Property for an app to inform the system that the application can be opted-in or opted-out from the compatibility treatment that enables sending a fake focus event for unfocused resumed split-screen activities. This is needed because some game engines wait to get focus before drawing the content of the app which isn't guaranteed by default in multi-window mode.

Device manufacturers can enable this treatment using their discretion on a per-device basis to improve display compatibility. The treatment also needs to be specifically enabled on a per-app basis afterwards. This can either be done by device manufacturers or developers.

With this property set to true, the system will apply the treatment only if the device manufacturer had previously enabled it on the device. A fake focus event will be sent to the app after it is resumed only if the app is in split-screen.

Setting this property to false informs the system that the activity must be opted-out from the compatibility treatment even if the device manufacturer has opted the app into the treatment.

If the property remains unset the system will apply the treatment only if it had previously been enabled both at the device and app level by the device manufacturer.

Syntax:

 <application>
   <property
     android:name="android.window.PROPERTY_COMPAT_ENABLE_FAKE_FOCUS"
     android:value="true|false"/>
 </application>
 

Constant Value: "android.window.PROPERTY_COMPAT_ENABLE_FAKE_FOCUS"

PROPERTY_COMPAT_IGNORE_REQUESTED_ORIENTATION

public static final String PROPERTY_COMPAT_IGNORE_REQUESTED_ORIENTATION

Application level PackageManager.Property for an app to inform the system that the app can be opted-in or opted-out from the compatibility treatment that avoids Activity#setRequestedOrientation() loops. Loops can be triggered by the OEM-configured ignore requested orientation display setting (on Android 12 (API level 31) and higher) or by the landscape natural orientation of the device.

The treatment is disabled by default but device manufacturers can enable the treatment using their discretion to improve display compatibility.

With this property set to true, the system could ignore Activity#setRequestedOrientation() call from an app if one of the following conditions are true:

• Activity is relaunching due to the previous Activity#setRequestedOrientation() call.
• Camera compatibility force rotation treatment is active for the package.

Setting this property to false informs the system that the app must be opted-out from the compatibility treatment even if the device manufacturer has opted the app into the treatment.

Syntax:

 <application>
   <property
     android:name="android.window.PROPERTY_COMPAT_IGNORE_REQUESTED_ORIENTATION"
     android:value="true|false"/>
 </application>
 

Constant Value: "android.window.PROPERTY_COMPAT_IGNORE_REQUESTED_ORIENTATION"

PROPERTY_SUPPORTS_MULTI_INSTANCE_SYSTEM_UI

public static final String PROPERTY_SUPPORTS_MULTI_INSTANCE_SYSTEM_UI

Activity or Application level PackageManager.Property for an app to declare that System UI should be shown for this app/component to allow it to be launched as multiple instances. This property only affects SystemUI behavior and does _not_ affect whether a component can actually be launched into multiple instances, which is determined by the Activity's launchMode or the launching Intent's flags. If the property is set on the Application, then all components within that application will use that value unless specified per component. The value must be a boolean string.

Syntax:

 <activity>
   <property
     android:name="android.window.PROPERTY_SUPPORTS_MULTI_INSTANCE_SYSTEM_UI"
     android:value="true|false"/>
 </activity>
 

Constant Value: "android.window.PROPERTY_SUPPORTS_MULTI_INSTANCE_SYSTEM_UI"

SCREEN_RECORDING_STATE_NOT_VISIBLE

public static final int SCREEN_RECORDING_STATE_NOT_VISIBLE

Indicates the app that registered the callback is not visible in screen recording.

Constant Value: 0 (0x00000000)

SCREEN_RECORDING_STATE_VISIBLE

public static final int SCREEN_RECORDING_STATE_VISIBLE

Indicates the app that registered the callback is visible in screen recording.

Constant Value: 1 (0x00000001)

addCrossWindowBlurEnabledListener

public void addCrossWindowBlurEnabledListener (Consumer<Boolean> listener)

Adds a listener, which will be called when cross-window blurs are enabled/disabled at runtime. This affects both window blur behind (see LayoutParams.setBlurBehindRadius) and window background blur (see Window.setBackgroundBlurRadius).

Cross-window blur might not be supported by some devices due to GPU limitations. It can also be disabled at runtime, e.g. during battery saving mode, when multimedia tunneling is used or when minimal post processing is requested. In such situations, no blur will be computed or drawn, so the blur target area will not be blurred. To handle this, the app might want to change its theme to one that does not use blurs.

The listener will be called on the main thread.

If the listener is added successfully, it will be called immediately with the current cross-window blur enabled state.

addCrossWindowBlurEnabledListener

public void addCrossWindowBlurEnabledListener (Executor executor, 
                Consumer<Boolean> listener)

Adds a listener, which will be called when cross-window blurs are enabled/disabled at runtime. This affects both window blur behind (see LayoutParams.setBlurBehindRadius) and window background blur (see Window.setBackgroundBlurRadius).

Cross-window blur might not be supported by some devices due to GPU limitations. It can also be disabled at runtime, e.g. during battery saving mode, when multimedia tunneling is used or when minimal post processing is requested. In such situations, no blur will be computed or drawn, so the blur target area will not be blurred. To handle this, the app might want to change its theme to one that does not use blurs.

If the listener is added successfully, it will be called immediately with the current cross-window blur enabled state.

addProposedRotationListener

public void addProposedRotationListener (Executor executor, 
                IntConsumer listener)

Adds a listener to start monitoring the proposed rotation of the current associated context. It reports the current recommendation for the rotation that takes various factors (e.g. sensor, context, device state, etc) into account. The proposed rotation might not be applied by the system automatically due to the application's active preference to lock the orientation (e.g. with Activity.setRequestedOrientation(int)). This listener gives application an opportunity to selectively react to device orientation changes. The newly added listener will be called with current proposed rotation. Note that the context of this window manager instance must be a UiContext.

addScreenRecordingCallback

public int addScreenRecordingCallback (Executor executor, 
                Consumer<Integer> callback)

Adds a screen recording callback. The callback will be invoked whenever the app becomes visible in screen recording or was visible in screen recording and becomes invisible in screen recording.

An app is considered visible in screen recording if any activities owned by the registering process's UID are being recorded.

Example:

 windowManager.addScreenRecordingCallback(state -> {
     // handle change in screen recording state
 });
 

getCurrentWindowMetrics

public WindowMetrics getCurrentWindowMetrics ()

Returns the WindowMetrics according to the current system state.

The metrics describe the size of the area the window would occupy with MATCH_PARENT width and height, and the WindowInsets such a window would have. The WindowInsets are not deducted from the bounds.

The value of this is based on the current windowing state of the system. For example, for activities in multi-window mode, the metrics returned are based on the current bounds that the user has selected for the Activity's task.

In most scenarios, getCurrentWindowMetrics() rather than getMaximumWindowMetrics() is the correct API to use, since it ensures values reflect window size when the app is not fullscreen.

getDefaultDisplay

public abstract Display getDefaultDisplay ()

This method was deprecated in API level 30.
Use Context.getDisplay() instead.

Returns the Display upon which this WindowManager instance will create new windows.

Despite the name of this method, the display that is returned is not necessarily the primary display of the system (see Display.DEFAULT_DISPLAY). The returned display could instead be a secondary display that this window manager instance is managing. Think of it as the display that this WindowManager instance uses by default.

To create windows on a different display, you need to obtain a WindowManager for that Display. (See the WindowManager class documentation for more information.)

getMaximumWindowMetrics

public WindowMetrics getMaximumWindowMetrics ()

Returns the largest WindowMetrics an app may expect in the current system state.

The value of this is based on the largest potential windowing state of the system. For example, for activities in multi-window mode, the metrics returned are based on the what the bounds would be if the user expanded the Activity's task to cover the entire screen.

The metrics describe the size of the largest potential area the window might occupy with MATCH_PARENT width and height, and the WindowInsets such a window would have. The WindowInsets are not deducted from the bounds.

Note that this might still be smaller than the size of the physical display if certain areas of the display are not available to windows created in this Context. For example, given that there's a device which have a multi-task mode to limit activities to a half screen. In this case, getMaximumWindowMetrics() reports the bounds of the half screen which the activity is located.

Generally getCurrentWindowMetrics() is the correct API to use for choosing UI layouts. getMaximumWindowMetrics() are only appropriate when the application needs to know the largest possible size it can occupy if the user expands/maximizes it on the screen.

isCrossWindowBlurEnabled

public boolean isCrossWindowBlurEnabled ()

Returns whether cross-window blur is currently enabled. This affects both window blur behind (see LayoutParams.setBlurBehindRadius) and window background blur (see Window.setBackgroundBlurRadius).

Cross-window blur might not be supported by some devices due to GPU limitations. It can also be disabled at runtime, e.g. during battery saving mode, when multimedia tunneling is used or when minimal post processing is requested. In such situations, no blur will be computed or drawn, so the blur target area will not be blurred. To handle this, the app might want to change its theme to one that does not use blurs. To listen for cross-window blur enabled/disabled events, use addCrossWindowBlurEnabledListener(Executor, Consumer).

registerBatchedSurfaceControlInputReceiver

public InputTransferToken registerBatchedSurfaceControlInputReceiver (InputTransferToken hostInputTransferToken, 
                SurfaceControl surfaceControl, 
                Choreographer choreographer, 
                SurfaceControlInputReceiver receiver)

Registers a SurfaceControlInputReceiver for a SurfaceControl that will receive batched input event. For those events that are batched, the invocation will happen once per Choreographer frame, and other input events will be delivered immediately. This is different from ERROR(/#registerUnbatchedSurfaceControlInputReceiver(int,android.window.InputTransferToken,android.view.SurfaceControl,android.os.Looper,android.view.SurfaceControlInputReceiver)) in that the input events are received batched. The caller must invoke unregisterSurfaceControlInputReceiver(android.view.SurfaceControl) to clean up the resources when no longer needing to use the SurfaceControlInputReceiver

registerTrustedPresentationListener

public void registerTrustedPresentationListener (IBinder window, 
                TrustedPresentationThresholds thresholds, 
                Executor executor, 
                Consumer<Boolean> listener)

Sets a callback to receive feedback about the presentation of a Window. When the Window is presented according to the passed in TrustedPresentationThresholds, it is said to "enter the state", and receives the callback with true. When the conditions fall out of thresholds, it is then said to leave the state and the caller will receive a callback with false. The callbacks be sent for every state transition thereafter.

There are a few simple thresholds:

• minAlpha: Lower bound on computed alpha
• minFractionRendered: Lower bounds on fraction of pixels that were rendered
• stabilityThresholdMs: A time that alpha and fraction rendered must remain within bounds before we can "enter the state"

The fraction of pixels rendered is a computation based on scale, crop and occlusion. The calculation may be somewhat counterintuitive, so we can work through an example. Imagine we have a Window with a 100x100 buffer which is occluded by (10x100) pixels on the left, and cropped by (100x10) pixels on the top. Furthermore imagine this Window is scaled by 0.9 in both dimensions. (c=crop,o=occluded,b=both,x=none)

b	c	c	c
o	x	x	x
o	x	x	x
o	x	x	x

We first start by computing fr=xscale*yscale=0.9*0.9=0.81, indicating that "81%" of the pixels were rendered. This corresponds to what was 100 pixels being displayed in 81 pixels. This is somewhat of an abuse of language, as the information of merged pixels isn't totally lost, but we err on the conservative side.

We then repeat a similar process for the crop and covered regions and accumulate the results: fr = fr * (fractionNotCropped) * (fractionNotCovered) So for this example we would get 0.9*0.9*0.9*0.9=0.65...

Notice that this is not completely accurate, as we have double counted the region marked as b. However we only wanted a "lower bound" and so it is ok to err in this direction. Selection of the threshold will ultimately be somewhat arbitrary, and so there are some somewhat arbitrary decisions in this API as well.

registerUnbatchedSurfaceControlInputReceiver

public InputTransferToken registerUnbatchedSurfaceControlInputReceiver (InputTransferToken hostInputTransferToken, 
                SurfaceControl surfaceControl, 
                Looper looper, 
                SurfaceControlInputReceiver receiver)

Registers a SurfaceControlInputReceiver for a SurfaceControl that will receive every input event. This is different than calling registerBatchedSurfaceControlInputReceiver(android.window.InputTransferToken, android.view.SurfaceControl, android.view.Choreographer, android.view.SurfaceControlInputReceiver) in that the input events are received unbatched. The caller must invoke unregisterSurfaceControlInputReceiver(android.view.SurfaceControl) to clean up the resources when no longer needing to use the SurfaceControlInputReceiver

removeCrossWindowBlurEnabledListener

public void removeCrossWindowBlurEnabledListener (Consumer<Boolean> listener)

Removes a listener, previously added with addCrossWindowBlurEnabledListener(Executor, Consumer)

removeProposedRotationListener

public void removeProposedRotationListener (IntConsumer listener)

Removes a listener, previously added with addProposedRotationListener(Executor, IntConsumer). It is recommended to call when the associated context no longer has visible components. No-op if the provided listener is not registered.

removeScreenRecordingCallback

public void removeScreenRecordingCallback (Consumer<Integer> callback)

Removes a screen recording callback.
Requires Manifest.permission.DETECT_SCREEN_RECORDING

removeViewImmediate

public abstract void removeViewImmediate (View view)

Special variation of ViewManager.removeView(View) that immediately invokes the given view hierarchy's View.onDetachedFromWindow() methods before returning. This is not for normal applications; using it correctly requires great care.

transferTouchGesture

public boolean transferTouchGesture (InputTransferToken transferFromToken, 
                InputTransferToken transferToToken)

Transfer the currently in progress touch gesture from the transferFromToken to the transferToToken.

This requires that the fromToken and toToken are associated with each other. The association can be done different ways, depending on how the embedded window is created.

• Creating a SurfaceControlViewHost and passing the host's InputTransferToken for SurfaceControlViewHost.SurfaceControlViewHost(Context, Display, InputTransferToken).
• Registering a SurfaceControl for input and passing the host's token to either registerBatchedSurfaceControlInputReceiver(android.window.InputTransferToken, android.view.SurfaceControl, android.view.Choreographer, android.view.SurfaceControlInputReceiver) or registerUnbatchedSurfaceControlInputReceiver(android.window.InputTransferToken, android.view.SurfaceControl, android.os.Looper, android.view.SurfaceControlInputReceiver).

The host is likely to be an AttachedSurfaceControl so the host token can be retrieved via AttachedSurfaceControl.getInputTransferToken().

When the host wants to transfer touch gesture to the embedded, it can retrieve the embedded token via SurfaceControlViewHost.SurfacePackage.getInputTransferToken() or use the value returned from either registerBatchedSurfaceControlInputReceiver(android.window.InputTransferToken, android.view.SurfaceControl, android.view.Choreographer, android.view.SurfaceControlInputReceiver) or registerUnbatchedSurfaceControlInputReceiver(android.window.InputTransferToken, android.view.SurfaceControl, android.os.Looper, android.view.SurfaceControlInputReceiver) and pass its own token as the transferFromToken.

When the embedded wants to transfer touch gesture to the host, it can pass in its own token as the transferFromToken and use the associated host's InputTransferToken as the transferToToken

When the touch is transferred, the window currently receiving touch gets an ACTION_CANCEL and does not receive any further input events for this gesture.

The transferred-to window receives an ACTION_DOWN event and then the remainder of the input events for this gesture. It does not receive any of the previous events of this gesture that the originating window received.

The transferTouchGesture API only works for the current gesture. When a new gesture arrives, input dispatcher will do a new round of hit testing. So, if the host window is still the first thing that's being touched, then it will receive the new gesture again. It will again be up to the host to transfer this new gesture to the embedded.

The call can fail for the following reasons:

• Caller attempts to transfer touch gesture from a token that doesn't have an active gesture.
• The gesture is transferred to a token that is not associated with the transferFromToken. For example, if the caller transfers to a SurfaceControlViewHost not attached to the host window via SurfaceView.setChildSurfacePackage(SurfacePackage).
• The active gesture completes before the transfer is complete, such as in the case of a fling.

unregisterSurfaceControlInputReceiver

public void unregisterSurfaceControlInputReceiver (SurfaceControl surfaceControl)

Unregisters and cleans up the registered SurfaceControlInputReceiver for the specified token.

Must be called on the same Looper thread to which was passed to the registerBatchedSurfaceControlInputReceiver(android.window.InputTransferToken, android.view.SurfaceControl, android.view.Choreographer, android.view.SurfaceControlInputReceiver) or registerUnbatchedSurfaceControlInputReceiver(android.window.InputTransferToken, android.view.SurfaceControl, android.os.Looper, android.view.SurfaceControlInputReceiver)

unregisterTrustedPresentationListener

public void unregisterTrustedPresentationListener (Consumer<Boolean> listener)

Removes a presentation listener associated with a window. If the listener was not previously registered, the call will be a noop.