On some devices (such as tablets) dock stack could be created on top,
but put to right after rotation. Dock create mode needs to be updated
in this case, otherwise when a new stack is attached to the display
(for example launch into now-cropped fullscreen stack),
attachDisplayContent() will use wrong dock mode to derive the bounds.
bug: 28942558
Change-Id: I83e66aeac94bd3f96c4b6a0a740acf76234bbe82
- Throwing SecurityExceptionand and IllegalArgumentException instead of null for new APIs
- removing @removed APIs
Bug:27530098,27379882
Change-Id: Ifbe65bfc5051aa33aff2baa22cfa8e67b0f7c358
Add some leeway in the reported time because some inaccuracy
is expected in these stats between samples.
BUG: 28932100
Change-Id: Ia643fa666ca16c0c707d189ec2bc703fe1ef08a4
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
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
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
Broadcast needs to have a valid action. We'll just pick
a generic one, since the receiver here doesn't care.
Change-Id: Ifff87626d11dd9fafb4e68819e8c8cecdf7fe1aa
- 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
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
When doing a full backup, mark the process as being in
backup and don't deliver any broadcasts to an app in
that state.
Bug: 25350780
Change-Id: I1adc95431f709495d3c1141c7c5d3616cf9cc1f0
When app tries to post its first notification,
value of now is equal to that of mLastEventTime.
And hence getRate return a very large number.
Bug: 28902358
Change-Id: If5b5b3c46e2bb80a9b40988ba7f7d777e40cc8e7
Following 14e54ba747 (ag/1043009) we need to push an empty
synchronous transaction if we want to ensure all previous
transactions have occured before taking a screenshot. In
light of Bug 7552304 it seems wise to do this before screenshoting
applications.
Bug: 27098060
Bug: 7552304
Change-Id: I6d7dfbe634a288c55449d2f1d6fbbfc13bab08ad
* Removed "synchronized" statements that are not needed
* Replaced "synchronized" statements with Read/Write lock as
appropriate. The lock protects the access to and the setting of
BluetoothAdapter.mService and BluetoothManagerService.mBluetooth and
associated state.
Bug: 28734075
Bug: 28799467
Change-Id: I8f8281c505f0a1ae0add1e14a3caba1f5b2a98e4
This is to fix an incorrect unregister() that was crashing
the system server. The only way it could be happening is
because of incorrect locking. So, hopefully this fixes it.
Bug: 28813750
Change-Id: Ie3c47ffa3024a0c533e12db0d2d021df8fc0367a
