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
When a IRemoteControlClient dies, that client is set to null
in the stack of remote control entries (mRCStack). This is done
by calling registerRemoteControlClient() with a null client.
The bug is that registerRemoteControlClient(), after storing
the new client, uses it to let it know what the current
remote control display is. When that display is non null, the
client is sent the current display. So when a client died
when there was a display, the client reference was accessed
in the part of the method where we haven't yet checked whether
it is null or not.
The fix consists in moving the setting of the display on the
client (method plugRemoteControlDisplay) only after having
checked that the client is non-null.
Change-Id: Ic74d6cba9e3a3a16e78cd80a1ae5901abfeb3905
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
This method is invoked only when the pop-up is currently displayed and the text scrolles.
This is scenario is reproducible only with Voice IME (I think), as the text is inserted without
touching the screen.
Bug: 5290463
Change-Id: I0b842732cc1f115de06e992fbe28cb64eac49b22
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
This makes sure that the page's SSL certificate is cleared when the page load
starts.
Follows on from https://android-git.corp.google.com/g/#/c/138147.
Bug: 5287216
Change-Id: I40f74a72dc495c48d7167b7b70a845a8481feb85
Note that this is an incomplete fix, as we do not clear the responses for
connections currently in use, as they maintain their own cache. See
http:/b/5324235.
Bug: 5287216
Change-Id: I18f6638efeff0bee1e7ffed606be1444d683bebd
This makes it the same as default browser settings (for now). Otherwise
the test may crash due to GPU OOM.
This is to be a workaround only, and should be reverted after the bug is
fixed.
Bug: 5382134
Change-Id: I82a8dd83b69c8fceb657af9e32a2c5fa66ead2ce
results in a blank screen.
The fix involves making the first activity just call the account
type chooser to get the account type to add, rather than having
the account type chooser also kick off the AccountManager.addAccount()
request itself. Instead the first activity will get the type
back and then call AccountManager.addAccount()
Bug: 5346810
Change-Id: I4a0cf2370971b98f8ee0910f5401d97e999e546b
