- 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
When we are displaying menus we do not care about that theme setting as
we always want to display the actionbar and the menu.
Bug: http://b.android.com/212320
Change-Id: I3b6200cc42e3c525a3763d14d423ee8371acc2f1
(cherry picked from commit 71eb800c0bb21b0e4cea3b29235ac4e544e765b2)
It turns out that although the method was public, the class is package
protected and hence the "Accessible" call
Change-Id: Iec69ad15db4c22d472a941dd335b6cf7789eea09
(cherry picked from commit ff78c344e63c8665ab7b0773b91e473b4fe650ff)
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
More efficient than an ArrayList since we do a lot of remove operations.
Change-Id: Ic4c89df4560066f1a3ab0e71a3b180a9734f9cd6
(cherry picked from commit 12754d621b20e6a925999096ab6f21c4cbfe594a)
