The current mechanism to sync InputMethodService#mIsFullscreen to
InputMethodManager#mFullscreenMode is really fragile because
1. Currently the state change is notified via
InputConnection#reportFullscreenMode(), where InputConnection is
designed to be valid only while the IME has input focus to the
target widget.
2. In favor of performance InputMethodService (IMS) calls
InputConnection#reportFullscreenMode() only when #mIsFullscreen
changed. If InputConnection#reportFullscreenMode() failed, there
is no recovery mechanism.
3. Screen oriantation change is likely to cause Window/View focus
state change in the target application, which is likely to
invalidate the current InputConnection.
What our previous workaround [1] did for Bug 21455064 was actually
relaxing the rule 1 only for InputConnection#reportFullscreenMode().
However, my another CL [2] made the lifetime check of InputConnection a
bit more strict again, which revived the issue as Bug 28157836.
Probably a long-term fix would be to stop using InputConnection to sync
that boolean state between IMS and the application. However, it's too
late to do such a refactoring in N, hence this CL relaxes the rule 1
again keeping it as secure as possible.
The idea is that we allow InputConnection#reportFullscreenMode() to
update InputMethodManager#mFullscreenMode regardless of whether
InputConnection is active or not, as long as the InputConnection is
bound to the curent IME. Doing this as a short-term solution is
supporsed to not introduce any new risk because the active IME is
already able to mess up the InputMethodManager#mFullscreenMode by
calling InputConnection#reportFullscreenMode() on any other active
InputConnection. Bug 28406127 will track the long-term solution.
[1]: Id10315efc41d86407ccfb0a2d3956bcd7c0909b8
da589dffdd
[2]: If2a03bc84d318775fd4a197fa43acde086eda442
aaa38c9f1a
Bug: 28157836
Change-Id: Iba184245a01a3b340f006bc4e415d304de3c2696
Pinned stack doesn't have focus, so there's no need for setting extra
elevation to show shadow for focused case.
This removes extra eleavtion for pinned stack, and improves the PIP
animation quality by preventing extra surface size change
at the end of animation.
Bug: 27364161
Change-Id: Id099a78de48b2e038a69600c94454b5cbfe0628f
am: bf67e5d
* commit 'bf67e5dc63ab801832e83fd09ae525d937ccb451':
Don't count vm_map_ram as used memory in vmallocinfo.
Change-Id: I6cc597d7ac15b2154f21a1efa30249ae37f30289
am: d8a028a
* commit 'd8a028af82d993ad2ab4938c9ce2c9a1a4b3fc9f':
Notify success before configuring the IP address.
Change-Id: I8ec9e8f556e00b4609c7a631110d62c711a44740
am: 4b74f4d
* commit '4b74f4de64806f1d98d9fca172b63fb1daab3b14':
Fix IME adjustment for voice interaction windows
Change-Id: Ifa140242826684c2e2921169f5506cadb68de32e
Because we move the task to the front in startRecentsActivity, we
always overrode the app transition type. Instead, we should remove
this logic and keep a flag whether the animation was prolonging was
finished already. If it was finished already, don't start the
prolonging when starting the transition.
Bug: 27154882
Change-Id: I1cd9e323867726ebd4b131ed5c13c3834d0f1107
am: a572863
* commit 'a57286307b3a5a81f78b47d2a0ac6ae2458f66f9':
Clean up updating bounds after config/display info change
Change-Id: I95f756eedd4b59e7a2c630f98493dedfd36842cf
- Add minimize state to dump
- If the docked app goes through a configuration change while the
docked stack is minimizing, the window list becomes temporarily empty,
and thus Task.isVisibleForCurrentUserLocked == false. Since we already
check at the beginning of the animation, we need to finish the minimize
animation on the docked stack no matter what happens.
- Adjust the condition when to notify divider controller about app
visibility. It turns out that under some conditions an animation is set,
but the app is not an element of mClosingApps nor mOpeningApps, so we
missed the visibility change of the home task
- Use getTopAppToken instead of getTopVisibleAppToken. When the token is
about to hide, it's already hiddenRequested, so we skipped changing the
minimize adjustment.
Change-Id: Ib9e2e3f6a5da7b7854b49857299a236e47baa6fc
Fixes: 28184044
This ensures that IpManager has a complete copy of DHCP state
before configuring the IPv4 address. That way, when the netlink
notification of the IPv4 address arrives, we are guaranteed to
have all DHCP information (including DNS servers and routes)
available and we will never send the IPv4 address before the DNS
servers.
Bug: 27605330
Change-Id: I732424dfe2408be9e40028563e99d610b541e12d
am: 1d3c594
* commit '1d3c59457c9bcf30e6ecb898e64d9d9725e7803e':
Make isCaptivePortal perform both HTTP and HTTPS probes.
Change-Id: I07174ba1c20a2ec6a24923eb3f0948b6432e55fa
am: 831ecc8
* commit '831ecc81f982282bdcc2121c2fa3ece22ac997e0':
Show forced resizable based on top activity
Don't move forced resizable info activity to the front
Change-Id: I30248e5462149359c9200aef069245b9950e639a
Since activity manager only issues a configuration change when
we are not relaunching the activity, the optimization to suppress
that on the client side is not needed anymore and only leads to
issues where there is a change in smallest_width but we are not
relaunching the activity because the change doesn't cross a size
threshold.
Bug: 28050773
Change-Id: I303c190bd7390363d1030edcdb2913b7c64c666d
Touch position is adjusted in HandleView#onTouchEvent to snap to
ideal offset.
Previously, screen coordinate was used for input, but window
coordinate is used for the ideal offset. As a result, window adjusted touch
position will be adjusted to improper position and a handle being
dragged will get moved to unintended line.
Bug: 22308836
Change-Id: I4a5a3cc695a874c85aa341f06ffcba8b7f5e318c
We always update the display info before handling the configuration
change. Thus, we remove this weird interleaving asynchronous beast
of code and handle rotation and density in updateBoundsAfterConfigChange
and everything else in updateDisplayInfo.
Sending an asynchronous message to resize the stack only causes race
condition and issues.
Change-Id: Ifa86f62e816917822a8c1d42d13d4bf1ad9bc5bf
Fixes: 28316517
Bug: 28184044
am: 103fdec
* commit '103fdec4151684686f900bd0a3af0a7fa82bf159':
Don't wait for visible if there is no running activity left.
Change-Id: Iea963aa552092cea3d06e929b7a2828caba5bf4b
am: 697a3334
* commit '697a3334854da5c2c3830f0489a0e7e4c646a7fb':
Do not add duplicates to mWaitingVisibleActivities
Change-Id: I2eb3d4300913377a3a654d3d5ddfc8e8ea9f6c91
If we start the forced resizable activity with an existing task,
avoid moving that task to the front. This can cause that a previous
task that was moved to the back gets moved to the front again just
because we started that activity. That's not good.
Bug: 28223489
Change-Id: If8acf31b8be98b82665de1015d5621331c37fb64
We could run into this situation on some devices (eg. clockworks),
the next activity doesn't get launched until we destroy this one.
allResumedActivitiesVisible() will return false if there is no other
activity running at all. Check top running activity and it's visibility
instead.
bug: 28400334
Change-Id: Ib8957e499580a10206fdd4e27da19fbc2bdb5843
am: 1a2f993
* commit '1a2f993ba5a81899500b989683364708025e13a5':
Fix issue #28431297: Crash in system process
Change-Id: I2a3c9c76a0a9ab708f01265487224b9e19a615ce
