This could cause the draw() code of views to be invoked too often
or worse, called with the wrong canvas. For instance, a view backed
by a software layer could get its draw() method called to record a
display list. Using a software layer is the recommended way to use
drawing operations not supported in hardware. Since we would
sometimes call the draw() method with the hardware backend anyway,
the app could crash by executing an unsupported operation.
Change-Id: Ib5f9a3a4c6f3efff5e0162ecd73d2dffe06e30a6
Action bars in dialogs are largely an undocumented "feature" but they
do work - with the exception of this since it previously relied on the
host being an Activity. Make it work.
Change-Id: I52ae24c3bfdd9766e4c0f035183e7f148a4e0162
Apparently the payload for an h.264 track in an .mkv file can contain multiple
NAL fragments, we used to discard everything after the first one before, now
we preserve them all.
Change-Id: Ic7187365309f3880a3256982879a45df50db697d
related-to-bug: 5337218
The onScreenTurnedOn() function in LockPatternKeyguardView was
actually being called in two cases - when the screen was turned on,
AND when the show() function was called in KeyguardViewManager, which
actually happens just before the screen is turned off. Face Unlock
functionality was added to the onScreenTurnedOn() function, not
expecting that the function was also being called just before the
screen turns off. This causes Face Unlock to run when the screen is
turned off, preventing it from running when the screen is turned on.
This was not obvious during testing because it's not a problem when
testing from the lock screen. To reproduce the problem you must log
in successfully, then turn the screen off, wait, and turn it back on.
The solution was to pull the non-face unlock functionality from
onScreenTurnedOn() into its own function called show(), which is
called from the KeyguardViewManager show() function and also called
from onScreenTurnedOn(). In this way, the onScreenTurnedOn()
functionality is not changed, but the show() function can be used
for the onScreenTurnedOn() functionality minus the Face Unlock stuff.
One exception to note - I left setting mScreenOn inside of
onScreenTurnedOn() and didn't pull it into show()...that seems like
the correct thing to do.
Change-Id: I9dcc144c7842112c4d35eb3f8b4ab1cd42c05675
Originally when surfaceChanged() happens, we remove the old window and
create a new window. This causes flickering. Now we just update the window
layout according to the size of the anchor view.
Change-Id: Id741dac07872e473f2c9829b626c5c9568e7e22d
