1. The accessibility layer has a back door for a UI test automation code running
from the shell to attach. The unregister code does an incorrect identity check
and as a result the register UI test automation service is not disconnected
until its process is killed. The fix is super safe and simple.
bug:7409261
Change-Id: I4b1da18be6c5619dadd4a58fca6724529bc59dea
Reverts a previous change that made the screen dim slowly instead.
The quick transition does a better job of attracting the user's
attention to the fact that the screen is about to turn off
unless the user touches the screen.
Bug: 7386034
Change-Id: I81e4d8939f6791b96352004984a9e5b2aab79788
Add new API to determine whether a display is secure.
Add new API to make a SurfaceView secure.
Clarify documentation.
Bug: 7368436
Change-Id: I7068c34c910e43b4bc72e43fa0dded59a25f0fe2
When we are clearing activities off the top of a task, propagate
any activity options down from the top-most one to whatever top
activity we are keeping. This ensures that if we set the activity
options on the top activity of the task previously to give it the
correct animation, we still keep that animation for the activity
that really ends up being the top.
Change-Id: I6919b644a530ac283fe4d320496edc2bf72aa04e
It appears that changing an application's signature during boot can pass
an outInfo of null to this function.
Bug: 7402550
Change-Id: I839fea6c8ee728a352c6b906f0fa6671c85f8694
The bug was that when an app was uninstalled, the Backup Manager was
discarding its bookkeeping about that app being represented in the
device's current live backup dataset. This in turn meant that if the
app was subsequently reinstalled, its data would not be restored from
that most-recent dataset: it would be restored from the *ancestral*
dataset if possible, or not at all.
Now the "ever backed up" state is retained correctly, and the app
will get its most-recent-data restored as expected.
Bug 7394519
Change-Id: I733cf41737765676e0a3a05fb1bcd32b165cb4ba
Reintroduced the stability time heuristic which requires brightness
to remain significantly above or below the currently accepted
ambient brightnes before effecting a brightness change. The
heuristic has the nice property of preventing light sensor noise
from causing oscillations in brightness even when the noise has
a relatively large magnitude (such as in low light environments).
The time bound and filter thresholds are current set so that
brightness increases typically occur within 5 seconds of a change
in the ambient environment. Decreases take somewhat longer and
typically occur within 10 seconds.
Changed the timing for brightness animations when the screen is
being dimmed due to a pending user activity timeout. The screen
now dims slowly but then brightens rapidly when touched.
Previously the screen dimmed quickly and brightened slowly which
felt somewhat unresponsive.
Fixed a problem where a brightness change might not occur because
the light sensor had not reported a new value in a long time.
Now we synthesize measurements when needed to ensure that a
transition will take place if appropriate.
Bug: 7387800
Change-Id: I998df2fec59922042a41a1ba4af97ea52c0bd02a
During package scan, only the primary user data directories were
checked. If the secondary user didn't have an application directory, it
would happily ignore it. The app would then crash upon startup.
Bug: 7391882
Change-Id: I1fa92aa27386104d4ac6bc5dc92bfbf2e7dfac9f
Early hardware revisions often have known issues. Add the ro.revision
property to the header for the checkin reports so known issues can
be easily filtered.
Change-Id: I337b09ddfa41ebbe7f8f56223392b0bd491f897b
