IssueTracker

Diego, currently computeCurrentWindowMetrics requires a @UiContext and will crash if the provided context cannot be unwrapped to an Activity or InputMethodService.

For views that are created without a UiContext, such as in a robolectric test, or when inflated using the applicationContext (for example to be added to window manager directly with WM#addView), should computeCurrentWindowMetrics implement some fallback behavior (such as size of the ViewRootImpl, or default display size)? If not then consumers of this API will need to define their own fallbacks which will lead to inconsistency

Do you mind providing code samples and then I can look into it further.