Added a config option to allow the lid switch to turn off the
screen. This is a closer match to what a lid switch should be
doing.
Removed an old feature to bypass keyguard when keyboard is visible
because the way it was plumbed in made bad assumptions about
the meaning of the lid switch. Also, the last product we shipped
that had a physical keyboard turned this config option off.
So away it goes. We can bring it back someday if we really want it.
It's questionable how useful the feature is anyhow, since it only
works when the keyguard is unsecure and when the lid switch is
unlikely to be jostled in the user's pocket.
Fixed a bug where we would tell the power manager that the keyboard
was visible even if the lid switch did not control the keyboard.
This used to cause the power manager to try to set the keyboard
brightness, which doesn't work.
Bug: 6377115
Bug: 6406726
Change-Id: Ic84b71d09563d51c92cd1cf132fa8bdee6509103
This change makes TextureView skip calling the onSurfaceTextureAvailable
callback when setSurfaceTexture is used to change the TextureView's
SurfaceTexture.
Change-Id: Ie08f72f157c3bfce3215076b21994026ef66d88d
Add "set-permission-enforced", which can currently only mutate
enforcement of READ_EXTERNAL_STORAGE.
Bug: 6363043
Change-Id: I3f7929738c8c36b0a54fbf171c03fe16c09b5d99
1. Now we will enable the accessibility focus only if Explore by
Touch is enabled. Enabling this feature allows a blind user to
touch the screen and set the accessibility focus at this
location as well as get spoken feedback. Also an accessibility
service can move the accessibility as a result of user gestures
detected only if Explore by Touch is enabled. Since we will
handle some gestures by default if not accessibility service
does so to provide reasonable built-in navigation of the UI
by "objects" we need the accessibility focus functionality.
bug:6383361
Change-Id: I13ce6072a90f5838c7656379788144c99a772bf0
This will be used to determine which parts of a window a completely
hidden by system UI elements (status bar, nav bar, system bar) so
that they can be clipped out from rendering.
Change-Id: I2c6c6ac67dbdfeed82d2c089ef806fb483165bd9
In the case where a previous AF completion was outstanding but before the completion
notification reached the application, the application cancelled this AF request, and
then started a new AF request. Right after the new AF request, the AF completion
notification for earlier AF request reached the application. The application
could not tell the AF completion notification was meant for the cancelled AF, but
thought the new AF was successfully completed. Subsequently, the application trid to
take a picture, which failed as a result.
The fix is to add an explicit lock in the Camera.java class to fix the race condition to
synchornize autoFocus(), cancelAutoFocus() and the callback of the pending AF
completion message.
o related-to-bug: 6026480
Change-Id: I33d244d908ac066698e792f641ba88fe228b14a9
