When disconnecting from a default network X and falling back on another
connected network Y as the new default, ConnectivityService was
attempting to record this event as a X -> Y "atomic" transition.
In practice the default network connectivity is actually lost and
recovering default network takes some non-zero time.
This patch changes the event recording to always record disconnection as
X -> 0 events. At the same time, if there is a fallback network that is
elected as the new default ConnectivityService will also record a 0 -> Y
event.
This patch also improves pretty-printing of DefaultNetworkEvent.
Extract from $ adb shell dumpsys connectivity_metrics_logger --events
17:51:00.086: DefaultNetworkEvent(0 -> 100:CELLULAR)
17:51:25.232: DefaultNetworkEvent(100:IPv4 -> 101:WIFI) # wifi goes on
17:51:44.064: DefaultNetworkEvent(101:DUAL -> 0) # wifi goes off
17:51:44.187: DefaultNetworkEvent(0 -> 100:CELLULAR)
Bug: 28204408
Change-Id: I63252633235bf6ba833b9ac431a80dda75a93e67
am: 8fba3b395f
* commit '8fba3b395fe45510683ffc199a0101655274ee45':
Fixed a few battery issues in SystemUI
Change-Id: Ic2bb6e80c8276b2029b26095514d1aeb37bbeedb
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
am: a3cb77a9b4
* commit 'a3cb77a9b451b1c02e668024a6a8e3b779a7781d':
Add support for dismissing in Talkback Mode
Change-Id: I0bd9c14ce2c9537df981688eaa87f277cf72a5f3
More broadcasts (from telephony) that should be protected.
Also put a little more information in the wtf message to
help determine where broadcasts from out of the system process
are coming from.
Change-Id: Ie3df25c883482ca54c7a7c5db57ca609950f5cbc
Bug: 28667141
saveLayer clips the layer to the size it needs to
be and will translate content if necessary, but
the drawLayerOp that results from that was not
translated to handle the shifted draw content.
This fixes that
Change-Id: I3c9ffd5d0282fa1b958bced94c25e9744281e9be
Some views were not getting the call to reactivate clipping
this is because only the when the view was made visible
was it reset, views made invisible would be missed.
Fixes: 27364129
Change-Id: Ie6944569f432cd657f7f741c95c4067b346ea98b
am: fc2a7ce7ac
* commit 'fc2a7ce7acc5ede8b26f35819c8287df1fed135c':
Don't deliver broadcast to apps that are being backed up
Change-Id: I531ddd28dd24ff567814cb455059ca9ddb24f145
Broadcast needs to have a valid action. We'll just pick
a generic one, since the receiver here doesn't care.
Change-Id: Ifff87626d11dd9fafb4e68819e8c8cecdf7fe1aa
am: 0a6d5112f1
* commit '0a6d5112f1c0f0574ecf62b440541fca4736a706':
Add check for '.end-content-title' to force the end of content section in an accordion. Fixes js error on mobile when the footer is appended inside of a content section.
Change-Id: Ic7898fd17a5b3ce47a3dc67364635e33436b97d2
am: 5a00e9d345
* commit '5a00e9d3450e0baccc89a88e586f8ce558e14aac':
Add check for '.end-content-title' to force the end of content section in an accordion. Fixes js error on mobile when the footer is appended inside of a content section.
Change-Id: I1d972ef1511ff8205ec54f1af7241db104ea976a
