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
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
When app has several windows and activity is relaunched + we try to preserve
main window - other windows just stayed around until removed by timeout or
replaced by app. There was a problem when one of the windows registered
broadcast receiver and set its own timer to remove it. In this case all
receivers were removed by framework because windows were considered leaked
and apps' timer caused crash when trying to remove registered receiver.
This CL removes all windows expect the main one, which we're trying to
preserve in this case.
Bug: 28337135
Change-Id: Ib8790cc8c61801f11d871ba3803bb0ebc3d3be01
ThreadedRenderer was never the right place for this anyway, and
ApplicationLoaders can provide both the full library search path (not
just the extracted native library dir) as well as the application loader
namespace.
Bug: 28213888
Change-Id: Ibcc0a9178da4dba6f3f3105932fdac1a1d0261af
The fix passes the calling userId instead of the current userId to
allow apps running as managed profiles to work.
Fixes bug 28666104
Change-Id: I9f8676ab11bd581d9e67b2b9f385036d4d3576ee
It's certainly not needed for two up, so remove the staging aspect.
Freeform resizing is currently broken because of another bug so this
can't be tested, but because we are not "shipping" it in any case
fixing the 2-up bug is more important, but it shouldn't break freeform
anyways.
Bug: 28618501
Change-Id: I6f285a714281fde50fd7328a3f8999cfa8dfb2c5
