The HeadsetService is now bound directly by the BluetoothManagerService.
The IBinder object related to the HeadsetService is then given back to
the BluetoothHeadset and to the client app. This change makes the
HeadsetService available for managed profile clients.
Bug: 16968338
Change-Id: I016d1837e4f987c0fab1fc2c64cb06eb91b24d87
These networks are unneeded and waste battery. We won't bring up these
networks in the first place if they have no chance of becoming highest scoring.
This change handles the case where these networks are already up and
transition to a state where they have no chance of becoming highest scoring.
This happens when another network validates with a score higher than this
network can ever hope to attain.
bug:18489123
Change-Id: I77a96a72e250e25e44e0c50e7a928af8b35bb6ab
CEC HAL does not report initial connection state of the HDMI port
but does it only when the state is updated. For the listeners which
want to get the initial state of the ports, this CL generates
hotplug event per each port when a new listener is added.
Bug: 18488079
Change-Id: I6915a96e3c14ee0db1bfb6912ab77d3ea1bd2f07
Accessibility layer keeps track of the introspectable windows. These
windows are received from the window manager which computes them after
an interesting window transition. The window manager was not sending
the windows to the accessibiltiy manager after an app animation is
completed and as a result the window location reported to accessibility
service was wrong which also resulted in wrong visible to user state
for the nodes in the window.
bug:18517058
Change-Id: I21d65a4e0c0dff9474f7cc47ea819ace5ac1e465
* changes:
Ensuring that the alpha and translation animation durations are the same. (Bug 18609321)
Fix crash when user is both scrolling and tabbing through Recents. (Bug 18552776)
Updates can change the reference without changing the key,
leaving the manager confused about which notification is active.
Fix applies to tracking active sound, vibrate, and lights.
Bug: 18369462
Change-Id: I0f606e6ef441737364795ba6feede1a7e5681191
...uninstalling updates to a system app
Things seem to be working fine, however we were not as aggressive at
writing out the current state in this case as we probably should be.
Also introduce more features to the appops command, which are useful
for testing this.
Change-Id: I177a9cc0e16e98b76fee0d052d742e06842bb3f9
The action was not checking the command type before processing.
Makes sure the right command is given for the rest of the action flow.
Bug: 18592547
Change-Id: Iaf2584501fc70bfc87e00b74f48cb11c6989f283
Add a test for whether a window will be shown to the current user.
Otherwise we wait to process windows that are drawn but will never
be shown. Consequently we end up in a layout loop that continues
to set pendingLayoutChanges at the point where "wallpaper and
commitFinishDrawingLocked true" message is generated.
Fixes bug 18510914.
Change-Id: Ib067b41b5f26b146ee6bdb16c2f3b07d20aa2c54
Add a listener to listen for changes in the Task stacks to preload thumbnails from the
system. In addition, reduce the amount of synchronous work done in activity creation
and first measure/layout passes.
Change-Id: I8bd9155d7a05e89c190a20429acff69a17808208
This makes the following changes in behavior:
-We will only cache a pending intent for a session if it reaches the
one of the playing states.
-If a previously priority session is removed the next session only
gets priority if it is in a playing state. Otherwise we use the removed
session's PendingIntent.
-The last session to have been playing or to have been added gets
priority after any currently playing sessions, but only if it is still
in the list of active sessions.
-We will only use a session that isn't playing and isn't the most recently
playing/added if we don't have a PendingIntent from the last playing session
to fall back on.
bug:18589421
Change-Id: I650c56a782bb1f1d5e64d7574a7d2387606f3b17
The code in place was inappropriately treating all recurring alarms
as non-wakeup for purposes of deferral. Worse, it was overriding the
"this deliverable batch of alarms includes a wakeup alarm" bookkeeping,
so could potentially cause inappropriate deferral of even standalone
wakeup alarms.
Bug 18591317
Change-Id: I2a62ed4badcaeb549c1ac4f086014aa829e45427
...not noon-or-midnight. Fix the initial fstrim delay to properly refer
to midnight rather than ambiguous 12-hour "zero" so that fstrim job
consideration always starts overnight rather than possibly at the following
day's noon, depending on when the device was booted.
Bug 18076397
Change-Id: Ife3cd5bdeb14c7832b6e2a2de88dcfd1ba731b67
In SQLite, if a sort order is not specified then the ordering is
undefined. In pre-L, SQLite would order accounts by the primary key.
But in L, the newer SQLite version appears to be ordering accounts by
the name.
Bug 18453759
Change-Id: I6bf2b0de59eca4c69472b4279b9e4194c3d3471e
The basic principle is: if an app's traffic could possibly go
over a network without the app using the multinetwork APIs (hence
"by default"), then the status bar should show that network's
connectivity.
In the normal case, app traffic only goes over the system's default
network connection, so that's the only network returned.
With a VPN in force, some app traffic may go into the VPN, and thus over
whatever underlying networks the VPN specifies, while other app traffic
may go over the system default network (e.g.: a split-tunnel VPN, or an
app disallowed by the VPN), so the set of networks returned includes the
VPN's underlying networks and the system default.
Specifically:
1. Add a NETWORK_CAPABILITY_VALIDATED bit to NetworkCapabilities.
2. Add a hidden API to retrieve the NetworkCapabilities of
all default networks for a given macro-user.
3. Modify the status bar code that used getActiveNetworkInfo to
determine which network was active, and make it consider all
validated networks instead.
4. Because the set of active networks depends on which VPN app
the user is running, make the status bar re-evaluate the
networking situation when the active user changes.
Bug: 17460017
Change-Id: Ie4965f35fb5936b088e6060ee06e362c22297ab2
Since we have a status icon for SoftAP, the persistent
notification is no longer necessary.
Bug: 17318034
Change-Id: I0c8acb643fc032c9b12feb3a9a155cf95e58eca1
Don't clear notification LEDs when seeing notifications on the
lockscreen.
Also fix a bug where the LED didn't continue flashing after
the screen turned off.
For devices with doze capability, ensure that the LED continuing
to flash after screen off doesn't cause an immediate pulses, but
delay the first pulse by 10s.
Bug: 15449039
Change-Id: Id34d51a2c91ceaf069e49add1ab690bb855f9638
When WiFi's score drops and then comes back up we would previously linger
WiFi but forget to cancel the linger timeout, so 30s later WiFi would
unexpectedly tear down. Also, make sure this is only done for created
Networks as "created" is the signal to initialy match Networks and requests.
bug:18169560
Change-Id: Ia69b110f6473371e556c60b950253758e023b7aa
When a listener requested HINT_HOST_DISABLE_EFFECTS,
fire ACTION_EFFECTS_SUPPRESSOR_CHANGED when it's removed.
Bug: 18578756
Change-Id: Ia20793f17fc376130f370e736efad8b15f0cfa6d
