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
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
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
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: 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
am: e468c2380d
* commit 'e468c2380ddcc1a7c1f2fa3c9995ad999e9c0ca8':
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: Ibb8848aed348e85fff5a47562212e88172557b0b
Fixed a bug where animators could run forever because of
a negative start delay.
Also fixed a bug where the shadow would continuously update
when it shouldn't.
Change-Id: Id115d179d99fecf72c5f2b3be1a4c8590361469e
Fixes: 28930837
am: 85b7df2697
* commit '85b7df26975997826a738a46ae4ab797941175ea':
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: If25728a85efb5b0ed46e87c45916621d8ad1d9ab
- Instead of waiting for the broadcast to start loading the user’s
widgets, handle them in the service callbacks to ensure the app widget
update broadcasts are enqueued earlier.
Bug: 27262341
Change-Id: I095abe5e15fe46412d00438986f7a9aee50872ca
Read time and I/O for OTA update from last_install, and report the
statistics using MetricsLogger.histogram.
Bug: 28658632
Change-Id: I7fd06a82cbabd346d6d44f81ebad08f6baf4b8d0
We allow each individual Resources object to select the best
Locale for the given APK. This allows one update to the configuration
instead of multiple updates, once the locale is chosen.
The Java locale is selected from the app context's locale.
Bug:28625993
Bug:27325465
Change-Id: I99e1e53f522e560f3b80bbd1e1c605f552dbdff0
Collect child invalidations during layer bounds change, then dispatch a
single invalidation if any children requested invalidation. This prevents
re-entrance from, for example, a LayerDrawable.updateLayerBounds() call
invoking setBounds() on a child, which necessarily calls invalidateSelf()
and immediately propagates up to ImageView.invalidateDrawable(), which
then calls configureBounds() and puts us back in updateLayerBounds().
Bug: 28636072
Change-Id: I36c9eefc18904d493292d51b37e4b05cfddcf794
