am: caf8c3c160
* commit 'caf8c3c160952aff4b4197c1e0282489583a942d':
Fix issue #28931042: wtf in system server
Change-Id: I86bf73a1294ccf4ef7ef63188e72942b17e61b0c
am: 4cb2d09cc9
* commit '4cb2d09cc9ffeb2826a6409ccfe5e9a40bf5b71d':
Fix issue #28931042: wtf in system server
Change-Id: I157db2bf789bcf339748f5462e8ce3e4dc41478a
am: 15d6c4bf7c
* commit '15d6c4bf7c5feb1e77a50ae014e3e2c27740c898':
Add a flag to toggle the automatic storage manager on and off.
Change-Id: I39652f61fc252bfd7a50b801ea46d7d00c60e83b
am: 9bebd9edb0
* commit '9bebd9edb0ca6131da4b0e34dc58328f9e5b26cf':
Fix issue #28931042: wtf in system server
Change-Id: Ic42f1fbaff38f96f5215aa959a5bad209052eba2
am: 3f2704b112
* commit '3f2704b112efd596c732965840762a3a53e5831b':
Fix issue #28931042: wtf in system server
Change-Id: I9c49dc77bcd6b6ef31342da9846cbe672f46f57d
am: 7a1aa92610
* commit '7a1aa926109b090251d193426ba9fdc699e6f3b7':
Fix issue #28931042: wtf in system server
Change-Id: I84142fe627ae93b680577bff91327419715db4bb
am: 9746deefbb
* commit '9746deefbbfa3f6561bdf27e7d697cc352853f13':
Add a flag to toggle the automatic storage manager on and off.
Change-Id: Icd5688b8ea9c72c6bab9dbb0eedd895bd0b09aca
am: ae02bfdd28
* commit 'ae02bfdd289f7172faeb57664ef47de8b547fa05':
Fix issue #28931042: wtf in system server
Change-Id: I0b15977a1b4e79743a6fe6937cd3463a4e3c2c3c
am: 7a1aa92610
* commit '7a1aa926109b090251d193426ba9fdc699e6f3b7':
Fix issue #28931042: wtf in system server
Change-Id: Ifc7c884f7fe54f4b4d9d0769c1a0af1b9f6f2e0b
am: ae02bfdd28
* commit 'ae02bfdd289f7172faeb57664ef47de8b547fa05':
Fix issue #28931042: wtf in system server
Change-Id: I24ca8dbb0f9935651fbeaf84b58407eb05abc064
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
Local user restrictions were not being updated in
AppOpsService#setUserRestrictions when a restriction was removed.
Bug: 28908581
Change-Id: If22f5834fadca33ec8b80bc4fb3993c1e1c29824
Also, if by the time the app is closing, a window is still invisible
in layout (or is already removed), mark the window as mAnimatingExit,
so that the surface is destroyed (or saved again). If it's marked
for removal, the window gets removed as well.
bug: 28913302
Change-Id: Ifa3dc0742f9c8c09d741fd64dcdc01b49075628c
Previous change hid this constructor. Now removing it entirely for completeness.
Issue #28296200 API Review: LocaleList
Change-Id: I43476994070b101999d338ec1f5d1a1a0a2a7658
