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: Ieb5bf24c13004fc97bb1006494e915924f54c02c
am: 7a1aa92610
* commit '7a1aa926109b090251d193426ba9fdc699e6f3b7':
Fix issue #28931042: wtf in system server
Change-Id: I84142fe627ae93b680577bff91327419715db4bb
am: ae02bfdd28
* commit 'ae02bfdd289f7172faeb57664ef47de8b547fa05':
Fix issue #28931042: wtf in system server
Change-Id: I0b15977a1b4e79743a6fe6937cd3463a4e3c2c3c
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: I634ee39848e5392c2a38be41e17aa36932329e88
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
The current pngs are hardcoded to the green accent color.
Instead, the new vector drawable replacements have colorAccent
set as a tint.
Saves a bit on APK size, especially since ic_bt_cellphone
can be auto-mirrored rather than requiring ldrtl variants.
BUG: 28760785
Change-Id: Ifaec204ad28dd6cbd8463388080583bf7cf62044
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: Ia6f492cb909603e1741e09c5138ea3a7160a97a6
