Face Unlock used to show on first boot via an onScreenTurnedOn()
callback. At some point something changed and this no longer gets
called at boot time. This left us in the state where the black box
was covering the backup method, but Face Unlock was not starting.
Instead of finding a new way to make Face Unlock start at boot, it
was decided that it is probably best for it not to start at boot
anyway. So much is happening at boot time, including camera
initialization, that trying to make this work right might cause more
problems than it solves.
This fix moves the code that makes the black box cover the backup
method. Instead of happening when the layout is originally created,
it now happens in the show() function, which gets called not only
when the screen is turned on, but also before the screen turns off,
such that it is ready to go when the screen turns back on. This not
only keeps the black box from displaying on boot (because show()
doesn't get called at boot time), but also makes sure the black box is
already there before the screen is turned on, preventing any glitches
that may briefly show the underlying backup method.
Change-Id: I99bdae561a70918b5f12ea5badff08b07d74403c
1. Now if the widget is not interacted with shows a smaller selector
wheel with the increment and decrement arrows at the top and bottom
respectively.
2. Tapping an arrow button now animates the widget to the new value. i.e.
rotates the selector whell to the next value.
3. Fixed a bug that double tapping on the input shows the IME but then
after pressing an arrow button the IME is not hidden.
4. Fixed a bug that was exposed via late changes in the framework or the
graphics and was manifested of the selector wheel not having fading
edges.
bug:5251980
bug:5383502
Change-Id: I4a089dc69b07a3b28a514017cddf786cb9f4af16
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
