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
This CL changes the target of VD specific animators to VectorDrawable,
instead of RenderNode. The benefit of doing so is that animators can
now detect whether the animation is meaningful by checking whether
their VD target is in the display list. If not, that means the VD is
not drawing for the current frame, in which case we can be smarter
and more power efficient by removing the animator from the list and
posting a delayed onFinished listener callback.
By setting VD as the animation target, when an ImageView decides to
update its drawable from one AVD to something else, we'll be able
to detect that the previous AVD is no longer in the display list,
and stop providing animation pulse to the stale AVD, which is
something we couldn't do previously. This change also
handles the case where one AVD instance could be drawn in two
different views.
Bug: 27441375
Change-Id: Iaad1ed09cfd526276b95db0dd695275c28e074e8
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
am: ddc6de1eda
* commit 'ddc6de1eda495790e6564438994df5d49ddf248f':
Fixed a few accessibility issues with notifications and groups
Change-Id: Ieec9526a2c54edd2f0d3b34973cc61f610f452ae
am: c5fc6c602c
* commit 'c5fc6c602c16f0e985d8f8ba7f94075229e52320':
Close IME when attaching dock stack
Change-Id: I7921bf88bb49134d1fbde752d5fa963786ec1d46
am: e78ba24c17
* commit 'e78ba24c176fd6a0c54eaf7e52be545952ba1ab7':
Update the light center when the root view's layout changed
Change-Id: Ic973b9b47df6550c5170c2248c7e0f2ab25c6a57
am: c396f0f70e
* commit 'c396f0f70ef40ea0fb42a0872a13f4c4e9a6a5f0':
DO NOT MERGE Remove Pointer Capture API
Change-Id: I77cb742feacdd3b8af0cf33d4e7ab246f776417f
am: 39e8022a75
* commit '39e8022a75507be06179c3de7358cebb1bb22e06':
Force pending transactions to flush before screenshot.
Change-Id: Ib8dd84af143226e2b62cdfa51066e68ba7802d28
am: 7c17e70f2f
* commit '7c17e70f2f795ca06006ff2560c8b8211ce1dd52':
Changes based on API council feedback for performContextClick
Change-Id: Ief8c3036b93c28b27ba2f117ec656d38a1562fcf
am: 50c33d1ca1
* commit '50c33d1ca1218ec00eb37f66a7c11315603c9ef7':
Make IMM more robust to spurious window focus-in
Change-Id: I3c80320a5c6711bf3aaeb3043fe54c741c127966
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
am: 31e49b0964
* commit '31e49b0964cfba0b6b91e8ae67cbc04730098569':
Children should have backgrounds
Change-Id: I1f68467af9048b93631c33243f4a2dd2e67ccf81
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
