The root cause is we can't unbind blue service when bluetooth isnot disbaled
Otherwise the bluedroid stack will be out of sync with bluetooth service
only unbind bluetoothservice, when bluetooth is at OFF state.
bug 7376846
Change-Id: If5a11926f77a1ac29e75cdddbf5e90d492179f43
Rely on behavior of already-released CountDownLatch instead of
clearing the reference.
Bug: 7290521
Change-Id: I787e673b97d18be412d5b37e279fbf1275b49151
(This relates to the new vibration fallback behavior, where
notifications that expect to make a sound should always
vibrate in vibrate mode. We should not vibrate if the
notification's sound is silent, but we should also not
vibrate if the notification uses the default sound and the
default is silent.)
Bug: 7537077
Change-Id: I08e149c8c00ef2d2f61e418d88a086cb5e9cf241
- When notifications vibrate as a fallback (that is,
because they want to play a sound but the device is in
vibrate mode), this no longer requires the VIBRATE
permission.
- As a bonus, if your notifications use DEFAULT_VIBRATE,
you don't need the VIBRATE permission either.
- If you specify a custom vibration pattern, you'll still
need the VIBRATE permission for that.
- Notifications vibrating in fallback mode use a different
vibration pattern.
- The DEFAULT_VIBRATE and fallback vibrate patterns are now
specified in config.xml.
Bug: 7531442
Change-Id: I7a2d8413d1becc53b9d31f0d1abbc2acc3f650c6
LocationManagerService was serially stuffing the same Location into
multiple Intents, which it would immediately hand off to
ActivityManagerService, running as a different thread in the same
process. LocationManager would continue to work with that Location
while ActivityManagerService worked with a Parceled version of it.
However, Location.mExtras is also a Bundle, and both
ActivityManagerService and LocationManagerService ended up working
with references to the same Bundle. ActivityManagerService needs
it in Parceled form (ie mParceledData != null), but
LocationManagerService was triggering Bundle.unparcel() when
referencing the data contained within.
As a result, LocationManagerService was able to trigger NPE (or
worse) in ActivityManagerService by manipulating the mExtras
member of a Location that was in the process of being reported to
listeners.
To resolve this issue, I copy-construct a new Location to report to
each listener. This should prevent ActivityManagerService and
LocationManagerService from referencing the same Bundle data, as
Location's copy constructor also copyconstructs the mExtras member,
rather than simply share references.
Bug: 7518371
Change-Id: I1a92615cba361831494447d5de085a8d910b6b2c
the root cause is the A2dp and Pbap service need receive STATE_TURNING_OFF intent
to shutdown cleanly. So we need send completely state transition intents
in user switch handler.
bug7403171
Change-Id: Ic92bc85c2b74ae7c95440b237ea8851771ee9f04
(Unless the notification specifies no ringtone AND no
vibration, in which case it will remain silent.)
Bug: 7516358
Change-Id: I926d0fe0165b9622cd117e6c3ef6e3637772b444
(Unless the notification specifies no ringtone AND no
vibration, in which case it will remain silent.)
Change-Id: I926d0fe0165b9622cd117e6c3ef6e3637772b444
Omits service name from destroyed events, since it can be derived by
looking back to the created event with the same ServiceRecord.
Change-Id: Ib7ab1031c0859437735e1fc985d58f47629b7ac4
Some Wifi display devices like to rename themselves after a
connection completes (or at other times). Make sure to update
the name of the display when we detect that it changed in
our scan results.
This problem is somewhat complicated by the fact that we remember
the display name persistently, so we need to update our list
of remembered displays too.
Improve the state machine to avoid redundant attempts to
disconnect or cancel connection.
Bug: 7478895
Change-Id: I35a9e2c6a8deadbe892dacd5e3b4a5a2b12d6cf0
Bug: 7490028
Otherwise notifications such as the USB debugging and OTA notifications will be
dismissed when any user is stopped.
Change-Id: I0ae0c1136a999dd3aade99ca9e71c714b359eab4
Currently, installd doesn't correctly evict VFS cache entries for
FUSE emulated external storage. This means zygote processes have an
inconsistent view of the FUSE daemon when the system rapidly
recycles user IDs.
To work around this, only consider recycling a user ID after its
VFS cache entries have expired. The emulated storage FUSE daemon
currently uses a 'entry_valid' timeout of 10 seconds.
Bug: 7407902
Change-Id: Id80cbdd2215d8456467fb31e4c209ca12a505e16
Geofences are broken in multiuser, and need to be fixed before
reenabling the feature for secondary users.
Change-Id: Ief3008a294deed47760ee25efcf1cdef5371b038
Process the location of the fence as soon as it is added.
Clarified how the distance to the fence was being used.
Added more debug logs (disabled by default).
Fixed a numerical overflow in the location request if the
distance to the border of the nearest fence was greater
than about 2000Km.
Removed a useless call to request location updates passively
when the geofence manager is initialized. We have no need
of location updates unless there are active geofences.
The effect of this call was undone the next time the location
request was updated anyhow.
Changed the location request to always request a fastest update
interval of 0 which accomplishes the goal of passively
monitoring all updates. This does not increase the power
consumption because we are conservative about choosing
a minimum location update interval. We're simply stating
that the geofence manager is willing to handle a higher
report rate which is very important.
Subject location to a "freshness test" - only use relatively
recent locations for geofence testing.
Run all geofence updates on the handler and avoid making
multiple redundant calls into the location manager when
updating the provider requirements.
Ensure that we update geofences correctly even if we don't
know the initial location of the device at the time the
geofence is created.
Pin update interval value to the range [1m..2hr].
Distance to fence is now distance to fence's border, not
distance to fence's centre.
Bug: 7466334
Change-Id: I28e571ecfc508d5ceb9bb2afcabaaf05abb26369
This adds a means of determining when the device is in safe mode,
as required by keyguard to disabled some features.
Change-Id: I31d357e6738c92e1837f9e0263e5f3f4de66315a
The gnarly stuff where we keep track of the old input method
window as if it was still there was sitting around leaving things
in a stuck state. Now we clear this out at key points in the
window manager (freezing screen, user change), and the input
method manager service is less aggressive about asking the window
manager to do it.
Also fixed a problem that was causing flickers during some
wallpaper transitions -- when we are animating two things on
top of the wallpaper and one of them disappears, we need to
make sure the wallpaper target points to whatever the current
target should be (if any), not left pointing to the old target
that has gone away.
Change-Id: I2fb9600f569a5bd5e3528aaf24cde9340af56cb0
...lockscreen sometimes and remains black / blank
The problem was that we were using the animation-side wallpaper state
in cases where it was not updated yet.
The mWallpaperTarget variable is propagated over to the animation
side when the main window manager state updates. On the animation
side, this is used by hideWallpapersLocked() to determine if the
current wallpaper should be hidden.
The problem is that various paths to hideWallpapersLocked() can
come from the layout side of the window manager instead of the
animation side. This causes the problem here because in this case
the wallpaper state may not have yet been propagated to the
animation side, so it could incorrectly decide to hide the wallpaper
because it thinks there is not a target when in fact a target is
set in the layout side. This won't get fixed until some time way
later that the layout side decides that a new window is being shown
that may need to have the wallpaper shown.
The fix here is pretty gross, but as safe as possible -- the
hideWallpapersLocked() function now uses either the animation or
layout wallpaper state depending on where the call to it is coming
from.
Change-Id: I9250bfeae6e11c1761760bcc696fdb33fb5c8a5f
Decrement the number of updates after a location fix has been sent to a
a listener. This is necessary for respecting calls such as
requestSingleUpdate().
Bug: 7460868
Change-Id: Iea207ab494b93b936ca434d59652bb2cb6404cef
