In MR0, we did not allow applications to query enabled status of
location providers they did not have permission to use. Some
applications counted on this behavior, using the thrown
SecurityException to determine whether or not they have permission
to use the specified provider.
Reverting to this behavior fixes the regressions seen in those
applications.
Bug: 7251459
Change-Id: I8b0cfd5862c80f0c831a4ab544c3fa7408bc84a0
1. Accessibility events for changes in the content of a given window, such as
click, focus, etc. are dispatched to clients only if they come from the
active window.
Events for changes in the state of a window, such as window got input focus
or a notification appeared, are always dispatched. The notification events
do not contain source, so a client cannot introspect the notification area
(unless the user explicitly touches it which generates hove events). The
events for a window getting input focus change the active window so they
have to be dispatched.
Events that are a result of the user touching the screen, such as hover
enter, first tocuh, etc. should always be dispatched.
bug:7282006
Change-Id: I96b79189f8571285175d9660a22394cc84f39559
7267494 Calendar is not syncing
Check for whether a content provider is dead before returning
it. This is kind-of a band-aid, but probably the right thing
to do; I'm just not sure exactly the full details of why this
problem is happening. Hopefully this "fixes" it, though I don't
have a way to repro to tell.
7212347 System power off dialog is only visible to user 0
Make it visible. Also turn on some battery debugging stuff and
clean it up so we can just keep it.
Change-Id: I5add25bf2a763c8dfe1df23bc5c753a9ea5d157a
1. During a drag in touch exploration we have two pointers moving in the same
direction but inject only one of them. If the dragging pointer goes up we
send an up to the view system and wait for all pointers to go up to transition
to touch exploring state. At this point the dragging pointer id is cleared
and if a new pointer goes down we are trying to send up (rather do nothing)
for the dragging pointer which we already did and due to the invalid pointer
id we get an exception when splitting the motion event.
bug:7282053
Change-Id: I690bf8bdf6e2e5851ee46a322c4a1bb7d484b53a
Previously dreams could not be started unless plugged in.
Now we allow them to start but they will eventually stop
if a user activity timeout occurs and no screen wakelocks
are held.
Bug: 7253639
Change-Id: I84703e144ca6d4aba1ef9437f04a201c3dde8a49
With this fix, when all users cancel installing an app they were warned about,
then the "Installing..." screen disappears, as desired.
Bug: 7255231
Change-Id: I2475fa790a5d09abbf94411c696682502fb1e8df
Take into account whether the screen off timeout is very short.
If so, we use a shorter dim timeout. Don't allow the dim
time to be more than 20% of the total screen on time so that
the screen remains bright at least 80% of the time even when
the timeout is short.
Bug: 7273646
Change-Id: Iccea764b90f0d8b1df7009d26160c6bcf6eabe5b
We can't accurately detect whether the device is resting
on a wireless charger unless it is actually charging.
So we need to tweak the screen on when plugged / unplugged
policy accordingly to avoid spurious wakeups.
Bug: 7234284
Change-Id: I624b559e2e92b8813b12090bc20eca5f5158997e
Some of the BatteryService state was being locked
sometimes and it wasn't at all consistent.
Bug: 7158734
Change-Id: I46e75f66fde92c5a577a80a6bd99c9573066f3c1
