WindowManager

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 will not 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 ActivityEmbedding split feature enabled.

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

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"

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.

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 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.

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).

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.

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.