Window tokens can now only be on one display, so we now require clients
that want to add/remove window tokens to specify the display they would
like the token to be created on. This simplifies the token handling code
in WM and will be useful moving forward for clients that want to add
windows to external displays.
Test: Existing tests pass
Change-Id: I6b2d8d58a913b3624f1a9a7bebbb99315613f103
Cleanup:
- Make sure all the state is nicely dumped.
- Remove some unused stuff.
- Fix a flicker when occluded -> unlocked
Bug: 32057734
Change-Id: Id87e26adccef740d608b325c2dc1f6db14dd4ec3
- Creating a PinnedStackController to keep track of the state of the PIP
to prevent changes in the system (ie. IME showing) and user interaction
from clobbering each other.
- Refactoring calls in AM into WM/controller
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: Ie59dfd45d5c54764ba69a589b3b8148845e92cc3
Signed-off-by: Winson Chung <winsonc@google.com>
- Ensure we use the right display size when calculating PIP bounds.
- Also update interface to take the display id.
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: #testPinnedStackDefaultBounds
Test: #testPinnedStackMovementBounds
Change-Id: I01fd8ba6dee212c29a9a092673ee8f7843e41af6
Now display-specific settings, such as dimensions and orientation,
are stored in display override config. For default display it is
mirroring the global config. Each time when global config is updated,
override of the default display should be updated too and vice versa.
Test: Existing and manual tests still pass.
Change-Id: Ic6c2190092d328820f314a05bed43c875db18170
- This CL provides the framework for manipulating the pinned stack using
an input policy (to be determined later) provided by the SystemUI.
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: #testNonTappablePipActivity
Change-Id: I025c41fff26ed05a35d68e59f10330680ed11ea8
NOTE: Linear blending is currently disabled in this CL as the
feature is still a work in progress
Android currently performs all blending (any kind of linear math
on colors really) on gamma-encoded colors. Since Android assumes
that the default color space is sRGB, all bitmaps and colors
are encoded with the sRGB Opto-Electronic Conversion Function
(OECF, which can be approximated with a power function). Since
the power curve is not linear, our linear math is incorrect.
The result is that we generate colors that tend to be too dark;
this affects blending but also anti-aliasing, gradients, blurs,
etc.
The solution is to convert gamma-encoded colors back to linear
space before doing any math on them, using the sRGB Electo-Optical
Conversion Function (EOCF). This is achieved in different
ways in different parts of the pipeline:
- Using hardware conversions when sampling from OpenGL textures
or writing into OpenGL frame buffers
- Using software conversion functions, to translate app-supplied
colors to and from sRGB
- Using Skia's color spaces
Any type of processing on colors must roughly ollow these steps:
[sRGB input]->EOCF->[linear data]->[processing]->OECF->[sRGB output]
For the sRGB color space, the conversion functions are defined as
follows:
OECF(linear) :=
linear <= 0.0031308 ? linear * 12.92 : (pow(linear, 1/2.4) * 1.055) - 0.055
EOCF(srgb) :=
srgb <= 0.04045 ? srgb / 12.92 : pow((srgb + 0.055) / 1.055, 2.4)
The EOCF is simply the reciprocal of the OECF.
While it is highly recommended to use the exact sRGB conversion
functions everywhere possible, it is sometimes useful or beneficial
to rely on approximations:
- pow(x,2.2) and pow(x,1/2.2)
- x^2 and sqrt(x)
The latter is particularly useful in fragment shaders (for instance
to apply dithering in sRGB space), especially if the sqrt() can be
replaced with an inversesqrt().
Here is a fairly exhaustive list of modifications implemented
in this CL:
- Set TARGET_ENABLE_LINEAR_BLENDING := false in BoardConfig.mk
to disable linear blending. This is only for GLES 2.0 GPUs
with no hardware sRGB support. This flag is currently assumed
to be false (see note above)
- sRGB writes are disabled when entering a functor (WebView).
This will need to be fixed at some point
- Skia bitmaps are created with the sRGB color space
- Bitmaps using a 565 config are expanded to 888
- Linear blending is disabled when entering a functor
- External textures are not properly sampled (see below)
- Gradients are interpolated in linear space
- Texture-based dithering was replaced with analytical dithering
- Dithering is done in the quantization color space, which is
why we must do EOCF(OECF(color)+dither)
- Text is now gamma corrected differently depending on the luminance
of the source pixel. The asumption is that a bright pixel will be
blended on a dark background and the other way around. The source
alpha is gamma corrected to thicken dark on bright and thin
bright on dark to match the intended design of fonts. This also
matches the behavior of popular design/drawing applications
- Removed the asset atlas. It did not contain anything useful and
could not be sampled in sRGB without a yet-to-be-defined GL
extension
- The last column of color matrices is converted to linear space
because its value are added to linear colors
Missing features:
- Resource qualifier?
- Regeneration of goldeng images for automated tests
- Handle alpha8/grey8 properly
- Disable sRGB write for layers with external textures
Test: Manual testing while work in progress
Bug: 29940137
Change-Id: I6a07b15ab49b554377cd33a36b6d9971a15e9a0b
- Prevent third party apps from inadvertently changing internal SystemUI
flags through a call to setSystemUiVisibility(). These flags are only
set in the individual SystemUI components and can be updated in WMS
directly.
Bug: 29875297
Change-Id: I5ea238c8fb16a0eccd6e993d95a912acb359cee6
Add "wm surface-trace" command which enables tracing of surface
commands to be switched on at runtime. Primarily intended for use
by WM CTS tests. First target in CTS will be to use show/hide
events to eliminate polling in WM tests and increase speed. Next up
looking at things like verifying various transitions and relaunch
scenarios are flicker free. Later we may want to look at a smarter
or more structured format...but it's really not much hassle to parse
the commands off a pipe so I wanted to get us started.
Test: cts-tradefed run singleCommand cts -o --module CtsWindowManagerHostTestCases --test android.server.cts.SurfaceViewMovementTests#testSurfaceMovesWithParent
Change-Id: I1ff912c405a6cb9996ee9b6e2c465d57706191ba
Restrict saved surface to launcher start (ACTION_MAIN&CATEGORY_
LAUNCHER), or there is no intent at all (eg. task being brought to
front). If the intent is something else, likely the app is going
to show some specific page or view, instead of what's left last time.
This solves problems like the launcher shortcuts on DeckClock,
each of them is a different intent and will show one specific
view regardless of last states. Another example is Chrome tab
opened directly by action VIEW to open some URL.
(Note that this doesn't solve the problem with Chrome homescreen
shortcuts, it will still start with saved surface (if Chrome
is already open). This is because the shortcut is a trampoline
activity that starts the real chrome tab activity, but when
the trampoline is started, the whole task is already brought
to front, and ChromeTab could become visible with the task
before we actually start it.)
bug: 31055479
bug: 27747315
Change-Id: Id3e61c61ef516b0edc1f174320f02661222f226b
(cherry picked from commit ad24f96def)
Restrict saved surface to launcher start (ACTION_MAIN&CATEGORY_
LAUNCHER), or there is no intent at all (eg. task being brought to
front). If the intent is something else, likely the app is going
to show some specific page or view, instead of what's left last time.
This solves problems like the launcher shortcuts on DeckClock,
each of them is a different intent and will show one specific
view regardless of last states. Another example is Chrome tab
opened directly by action VIEW to open some URL.
(Note that this doesn't solve the problem with Chrome homescreen
shortcuts, it will still start with saved surface (if Chrome
is already open). This is because the shortcut is a trampoline
activity that starts the real chrome tab activity, but when
the trampoline is started, the whole task is already brought
to front, and ChromeTab could become visible with the task
before we actually start it.)
bug:27747315
Change-Id: Id3e61c61ef516b0edc1f174320f02661222f226b
Just leaving the implementation empty as that should avoid the crash
when calling it. The default stub was returning null and all the uses
were expecting an instance of SpareArray
Bug: http://b.android.com/211529
Change-Id: I497f823a6bfb7a6a946ba20c4f31b1020d2a0cef
(cherry picked from commit 98b704a284870b52cec37bf19370432c194e0608)
This is intended to cover the edge case in ConstraintLayout (and
possibly in other places) where an attribute is defined as
reference|enum.
If we can not resolve the value as a reference, try to resolve it as an
enum and return the value.
Change-Id: I2817aa5d78500247a2e9aec5411586a1db13791d
(cherry picked from commit b24b563654bf7c007f0912bf32fbab948fcb6daa)
Currently, the only way that layoutlib has to detect if the support
library is a dependency of the project is to try to instantiate one of
the classes. In some cases, this might report errors that we do not want
the user to see since we will fall back to loading the non-appcompat
version.
Bug: http://b.android.com/218478
Change-Id: I064209f2c31d00c0cdfc9edb4cddec40e8e8f416
(cherry picked from commit 71dcc03353d4412231c8d8d0398ccdcad6c225d1)
When quickly toggling between two apps, app could be resumed while
it's stopping but not yet stopped. Upon resuming, it could have
surfaces that's marked mDestroying and waiting for the stopped
to be destroyed.
We need to dispose these surfaces properly. If the window is already
removed, we destroy them. Otherwise, clear mDestroying flag so that
the window is ready to be used again. Leaving mDestroying=true makes
the window ineligible for certain things such as receiving wallpaper.
bug: 30255354
Change-Id: Id881653550595ab8e702d6950949bf202ac5a0d9
Make the release of all the VGroups deterministic once the root group
has been freed by a finalize call.
Also, free and clear the children array.
Disable assert in DelegateManager that would slow down layoutlib when
there are many delegates and assertions are enabled (dev and canary
builds).
Bug: http://b.android.com/214026
Change-Id: Ic7775d360ae4997f54f30fb75851879acaf8d824
(cherry picked from commit f6d8bba638baedc39d1d8f7bd3c69f4956819c71)
This CL adds new code to handle the support preferences classes. If the
support library is not installed in the project, it will use the regular
inflater as fallback.
This also ports the hotfix that used to live in Android Studio to
support "*Compat" preferences to the regular BridgePreferenceInflater.
Change-Id: I8ff34455d46b6188f0931e821d329224f6a0a343
(cherry picked from commit 90110d50f4c48ea7ec196a068f55b0eb86114c46)
The pointer to the root group in the VPathRenderer is not freed anywhere
in the Java side so we need to take care of it on the "native" side.
Change-Id: I2ca60b1f0e975a0b5d29799c5f6f31b5f8d42b9d
(cherry picked from commit ffdb1b241d9458196403c8f16264aa7053487323)
When activity transition triggers a rotation change, the starting
window will normally be the top window at the time we try
to select the window animation. However, these layout params won't
have the apps rotation animation set (as the client code will set that
on the real window, not the starting window). Eventually we would
like to add API to specify rotation animation via manifest to solve
this problem cleanly. In the mean time, we can force a specific rotation
animation from the double tap gesture, and clean up some camera
ugliness. We accomplish this by attaching an animation hint to
ActivityOptions.
Bug: 28838855
Change-Id: If052cd8cbae76651da43f3b4c590cd9dcc1afc0f
