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
Added correction of MODE_RINGER_STREAMS_AFFECTED setting in
case it is inconsistent when read from the database: ringtone,
notification and system streams are always affected by ringer mode.
A corruption of this setting persists accross reboots and propagates via
backup/restore causing devices to play notification and ringtones in silent mode.
Bug 7384750.
Change-Id: I23170413d01e6a8e34ef514f1516d7b9ab8bc656
Bug #7391098
The existing code was doing a make current to guarantee we have a
current context. This can however fail when the surface is destroyed
which could lead to GL calls without an EGL context, and therefore
potential leaks. This change fixes the issue by using a technique
found in HardwareRenderer.destroyHardwareResources(). If the surface
is not available then we use a special 1x1 pbuffer as a way to get
a valid context.
Change-Id: I716d3799bf90120d793d76e90a83956837ecd491
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
Throw an InvalidDisplayException to addView if the display being
added to has been removed. Handle this exception in Dialog.show()
by removing the view after it has been added and rethrow the
exception from there.
Add javadoc to ViewManager.addView and Presentation.show explaining
the new exception and how best to handle it.
Bug: 7368565 partially fixed. It remains for the Videos app to
handle Presentation.show throwing the InvalidDisplayException.
Change-Id: Ib4303c9b3f7bf7a0cfa95d19bd60a0c128658c48
Added a keyguardVisibilityChanged callback to indicate when the
keyguard is covered by something (alarm, phone, etc). Face unlock
doesn't start if it's not visible and it restarts appropriately when
it gains visibility again. This mostly fixes b/7362774 and b/7376783,
but there's some jank when face unlock goes away (if it was interrupted
while running).
Change-Id: I7bdf8ef6af687acaa7152d8e61bfdcc1979259ff
A bug in software rendering caused animations on views that are offscreen
to not get drawn, therefore the animation doesn't continue (since old-style
animations depend on the logic in the drawing code to keep running). Fix is
to special case the isAnimating case in ViewRoot to go ahead and schedule
a traversal even if the dirty rect does not intersect with the visible region.
Issue #7396035 Animations starting offscreen don't draw run/end/draw properly (sw rendering only)
Change-Id: Iae25b3a424ddc5a16ba431ecd68cf42d5500db3f
