We might have a pending MSG_RESIZED_REPORT, but if it's executed after
relayoutWindow, mPendingInsets will already be the new value and it'll
not forceLayout. So we need to forceLayout here to make sure the measure
cache is cleared.
bug: 29391054
Change-Id: I73793b1427b89e75700369ec3b37053a6a732f0d
Fixes: 29223302
If the surface only changed we want to just call onSurfaceChanged,
not onSurfaceCreated.
Change-Id: I65c8b210a7e34eaa2862020335ee7f6ef56eeac2
Un-reverts ag/1057448, but uses a version of Resources#getText
that returns null rather than throw an exception when no title
is available. This is the same call made before, so this change
should be safer.
Bug: 28744278
Change-Id: I8c123f4f6d74f796ab9e8ffcf955aaf881770da1
At the end of the animation (when going from larger to smaller),
we are left with a scaled surface, that we want to seamlessly
resize to an unscaled surface of the new size. Because we have scaled
the shadow region of the surface, the position of the content
will differ before and after the resize applies. We use new
SurfaceFlinger API to cause position updates to apply after
resize. Because we have to switch into SCALING_MODE_FREEZE,
we could end up prematurely cropping the window, so we
switch to using screen space crop for the pinned stack.
Bug: 28899837
Change-Id: I9b762a237413e4fa3d432e67d30c7125bfef484c
When calculating scroll amount, we should check whehter focus
is visible using before-scrolling position.
It's possible that the view is already scrolled, then visible
insets changes (eg. IME went away). Previous scroll position
still makes the focus visible, but it will leave the focus
in a bad position when it should be scrolled back.
bug: 29025892
Change-Id: I091f16bebc4c1e5ba831616c51ab2ac75d4c4b3c
InputMethodManager (IMM) has a latch switch named IMM#mHasBeenInactive
to forcefully refresh IME focus state when an inactive client
(IMM#mActive == false) is gaining window focus. However, it turns out
that there is a race condition where the latch could be unexpectedly
turned off. This is probably what we have been chasing in bug 25373872.
Imagine the following scenario:
1. An app receives MSG_WINDOW_FOCUS_CHANGED w/ hasWindowFocus=false
2. IMM inside the app receives MSG_SET_ACTIVE w/ active=false
3. The app receives MSG_WINDOW_FOCUS_CHANGED w/ hasWindowFocus=true
4. The app receives MSG_WINDOW_FOCUS_CHANGED w/ hasWindowFocus=false
5. The app receives MSG_WINDOW_FOCUS_CHANGED w/ hasWindowFocus=true
Here, our current strategy has been:
A. Turn on the latch when MSG_SET_ACTIVE (w/active=false) is handled.
B. Turn off the latch and ask IMMS to start input when
MSG_WINDOW_FOCUS_CHANGED (w/ hasWindowFocus=true) is handled.
The problem is that in the step B IMMS can reject the request if
WindowManagerService (WMS) tells that the window in question no longer
has window focus. This is not surprising because the app is
just handling messages in the message queue sequentially. As a result,
the IME focus is not updated expectedly in the step 5, because the latch
is no longer enabled as we expected.
With this CL, the latch will be re-enabled if the app fails to start
input while IMM#mActive is false as a short-term solution.
In future we may want to address this issue in protocol level so that
we can address other known issues such as bug 26851566 at the same time.
Bug: 28281870
Change-Id: I60adb38013b063918b074c7b947649eada77b2c8
To add a background to children of a group, a couple of things
are changed when a group is in the expanded state:
- The parent's shadow + background is removed
- The group header is given a background and elevation
- The children are elevated to cast a shadow and have backgrounds
- When it's fully expanded the dividers won't be shown
- There's extra height added to the parent so that the child
may cast the bottom shadow of the group
- As the children move into the bottom stack the last visible
one alters its height and the ones below it are hidden
to achieve the clipping effect
Fixes: 27591195
Fixes: 28655641
Change-Id: I0484308843e9b8bc10391387e54de07973a48f7d
Following 14e54ba747 (ag/1043009) we need to push an empty
synchronous transaction if we want to ensure all previous
transactions have occured before taking a screenshot. In
light of Bug 7552304 it seems wise to do this before screenshoting
applications.
Bug: 27098060
Bug: 7552304
Change-Id: I6d7dfbe634a288c55449d2f1d6fbbfc13bab08ad
TalkBack is seeing crashes that I can only explain by our assumption
that window layer is unique in all cases. TalkBack reports that it
happens during animation, so I assume that the layer may repeat
transiently.
Reducing our dependence on this assumption by traversing the list of
windows sorted by layer without assuming that the list has the same
length as the list of unsorted windows.
Also documenting the undefined behavior of SparseArray when indexing
beyond its bounds. The undefined behavior itself is intentional for
performance reasons.
Bug: 28679528
Bug: 28815817
Change-Id: I0c9f90b0b458b4cde465f603ba204fe6691e5c2c
Since LocaleList needs to depend on android.os.Parcelable, we cannot let
that class belong to "android.util" package, which causes layering
violation.
Bug: 28819696
Change-Id: Ia8de2ee9df3dd0a42b1fe84574439519b680fe18
The underlying implementation needs to be completely rethought. If a
process crashed while you were in pointer capture mode, you were
pretty much stuck in it. If the mouse happened to move outside of
your bounds right before you called the API, you'd never actually get
an event (whatever it was hovering over would). There's no easy way
for the system to tell you when you enter or exit this mode because
it doesn't actually track who the current request is from.
These are all solvable, but not in the N time frame. Maybe next time.
Bug: 26830970
Change-Id: I03efd63c499b86dc278491ca3284566c1965581f
- Added ActivityOption to mark a starting activity as a taskOverlay
activity. That is the activity will always be the top activity of the
task and doesn't cause the task to be moved to the front when it is added.
- Only set the starting window state of the ActivityRecord to shown if
window manager actually showed the starting window for the activity.
Avoids incorrectly trying to remove starting window for an activity that
didn't show any.
- When starting additional activity in a task, transfer the starting
window from the top most activity with a starting window. It is possible
the top most window does have a starting window like in the case of the
forcedResized activity.
- Only ensure visiblity of an activity we are starting in a task whose top
activity is a task overlay. They need to start in the visible-paused state
and not the resumed state which just causes extra churn in the system.
- Always add additional starting activities in a task with an overlay
activity below the overlay activity.
Bug: 28751186
Change-Id: I3624a4313ae9c406d42c67a3537f67ad685791af
We need to incorporate task bounds when calculating the inset hint
so we don't specify something wrong to the client which we correct
immediately after.
Bug: 28697105
Change-Id: I23cec7d6cc62a4d982e0796a867e803d4cce0803
Make getX/getY return view-relative position as specified in the class
JavaDoc.
Fix obvious errors in JavaDoc for getX/getY
Bug: 28793547
Change-Id: Ic2ac646189711e7466594d4fc8326408fc0348e1
This is a follow-up to my previous CL [1] for Bug 15922840 so that we
can clear the following variables in a more reliable way.
- PhoneWindowManager#mLastInputMethodWindow
- PhoneWindowManager#mLastInputMethodTargetWindow
The idea behind CL [2] is that when InputMethodManagerService (IMMS) is
switching from an IME to another IME, IMMS can send a signal to
WindowManagerService (WMS) to remember the current IME's inset so that
the system can continue using it to reduce jank until the new inset is
specified by the next IME. As summarized in Bug 28781358, however, if
the next IME does not show the window after the IME switch, WMS (or
PhoneWindowManager to be precise) keeps using the previous IME's inset
unexpectedly until the new IME shows its window. All we have seen in
Bug 15922840 and Bug 26663589 fall into this category.
The idea of this CL is just adding a hidden API to InputMethodManager so
that InputMethodService#clearInsetOfPreviousIme() can surely terminate
the IME transition state managed in PhoneWindowManager, rather than
relying on a hack of calling SoftInputWindow#show() and
SoftInputWindow#hide(), which actually does not work for Bug 26663589.
[1]: Ib04967f39b2529251e4835c42e9f99dba2cf43f2
2977eb7b6c
[2]: I5723f627ce323b0d12bd7b93f5b35fc4d342b50c
792faa2c16
Note that addressing all the corner cases in [2] still requires lots of
non-trivial change. Hence this CL focuses only on Bug 26663589 (and
the case we handled in Bug 15922840).
Bug: 26663589
Change-Id: Ib567daa009c1139858dccadcfc6a04465ebecf36
This change fixes the issue where
getChildVisibleRect(View, Rect, Point, boolean) call isn't recursive.
The method was introduced in I49550ed4082bcbdcfe4643b962b50f3308092525
Bug: 28514727
Change-Id: Ib6b0fb67ca6c700b44f645319c23b1213a2742d4
Currently every focus change causes a freeform window to jump
for a few frames. The size of the jump is equal to the difference
in inset size (which is derived directly from the window elevation).
This problem goes away for most real use cases if the insets are
not allowed to decrease.
Bug: 28318973
Bug: 22668382
Change-Id: I77ca440a7d9c89cc4d45e6667bf37da94a5c8a9a
This CL fixes 2 bugs in View's addFocusables implementations.
1) addFocusables(list, dir) method was always returning focusables in
touch mode even if the device is not in touch mode.
2) addFocusables(list, dir, mode) was not respecting the provided mod.
Bug: 28745577
Change-Id: I9b9e5af27f8f5b1bb3cc601584fdad7c73e54a5d
