Reverting this change since I don't have confirmation that the videos will ship by 10am on 6/15.
This reverts commit a1f02ff4e439d9de58ed4a788a52c2f73cfc36ce.
Change-Id: I854c589436bcc4e146770415898996826f552b21
- updated compatibility with future platform releases
- expanded on ways to dignose and debug
Bug: 29215157
Change-Id: Ie63d024eac9914d4553419c734132696fb94d7e5
Architectural changes from the Wear team have required changes to the
semantics of the Keystore on-body feature. Although no devices will
actually implement this feature until the release of new Wear devices
with the necessary sensors, we need to get the API documentation right
now.
Bug: 29369151
Change-Id: I857e00928f994a1337313123eae7e00534c53c3c
We added the toast timeout to fix b/21693547. Where the client
leaks non visible toasts which end up keeping the screen on.
Simply removing the toast windows as we were doing previously,
isn't very good though. If the timeout fires when an app could
still use the toast (e.g. due to long pause under debugger),
the app could crash. It's not obvious how (if even possible
without API semantic/guarantee change) to prevent this issue
from the client side. Furthermore, #33 at b/21693457 implies that
we need to respect FLAG_KEEP_SCREEN_ON even for windows that
never submitted a buffer. With time constraints as they are,
the only solution I can think of that solves both without
chance of regression is just stripping FLAG_KEEP_SCREEN_ON when the
timeout fires.
Bug: 29105388
Change-Id: Ic2df897f86acf814ea3d4f911a0532d65af0c19f
It is possible for a task to be removed from the WM and stack in AM
while resizing (e.g. app crashes). In this case we want to make sure
the task exist in WM before we try to set the dock resizing state vs.
depending on the fact that the task is in recent list in AM.
Bug: 29325623
Change-Id: Ib89a7bfe12fe1f2c4c6c56ac9e13b0052ea2b4ec
It turns out that the performance of
InputMethodManager#getCurrentInputMethodSubtype() is regressed from ~1ms
to ~20ms when
- Settings.Secure.SELECTED_INPUT_METHOD_SUBTYPE == -1 and
- The active IME supports many subtypes (~100)
because we try to find a fallback subtype based on the system locales
every time when IMM#getCurrentInputMethodSubtype() is called.
This could be contributing UI janks because spell checker clients
running in the UI thread indirectly depend on that method.
Fortunatelly the critical path is in
InputMethodUtils#getImplicitlyApplicableSubtypesLockedImpl(), which is
basically a state-less method. We can easily and safely cache its
result by using LocaleList and InputMethod as cache keys.
With this CL the performance basically recovers to the Android M level.
Bug: 28889203
Change-Id: I5ed16c7f14cc18052854f4fd6c9bae8550c332ee
This reverts commit 21893824c1d15a1a46cb75725ad951620569c3c6.
Original commit revealed issue b/29342752 when launch logic was applied
to incorrect stack while moving to PiP mode.
Bug: 29342752
Bug: 29237751
Change-Id: I88d75399eb4b9daf4de87a9a560eb0df0b515173
Because it's not guaranteed to use any builder at all,
there is another case where the SmallIcon could remain null.
We are now checking this lazily instead of ahead of time.
Change-Id: I7a0feff6911b2bce6707427259d3423131a26e32
Fixes: 29255365
