* commit '1fbb5da29a4ebef1d758dffad9c2704a5932d223':
Fix a JNI local reference leak in JNIMediaPlayerListener::notify.
Add null pointer check.
Import translations. DO NOT MERGE
Small DocumentsProvider doc improvements.
Keyguard isn't visible if it hasn't been drawn.
Enable fast camera transition when launched from navbar
Reduce camera launch time by about 250ms.
camera2: Remove prior repeating request when setting.
Adding validation for Global Proxy setting before it is
being set.
Proxy is validated at the boot time also to make sure
the value set is valid.
Signed-off-by: Raj Mamadgi <rmamadgi@sta.samsung.com>
bug:11598568
Change-Id: Idff5ae81119d8143da096b5291ecbfbc5875cbd4
Reduces jank in multiuser lock from QuickSettings. The launcher and
wallpaper were being hidden as soon as the surface for the keyguard
was created. Now they are not hidden until the keyguard has been
drawn. This still leaves a short time where there is a black screen
but it is considerably shorter than it was. Comparable to jb now.
Fixes bug 11046339.
Change-Id: I349d95dba72da27e5c05a7a64c95a2774d17a34e
Extend wifi display connection timeout.
Show a notification while connecting to wifi display.
Ensure that remote display providers are really trusted before
connecting to them.
Bug: 11257292
Change-Id: Iad0caaa30d7946df818bc75ade071f2e377f8a53
Could occur when requestRouteToHostAddress is called on a network
with no associated tracker. Code later in the method handles
this case gracefully but code introduced in JB throws an exception.
Change-Id: I6c8a0e313ecbcca120aeb5dd0802a72114749aa1
Both requests are made using same id; and there is a chance that
stopResolve() is not fully completed when getAddrInfo() is issued. That
results getAddrInfo() failure, because both are using same requestId.
This change fixes this problem by creating a new unique id to call
getAddrInfo() with.
Bug: 11597153
Change-Id: I56bd78740e8a40bd31c52705dc797486aff53a50
If a window claims to handle its own configuration change then we
won't destroy and recreate its window on a configuration change.
Normally that recreation triggers the first layout following
orientation change because mHaveFrame is false. Windows that handle
their own configuration changes never got a relayout pass following a
change in orientation.
This change passes the configuration changes that an application
handles into the AppWindowToken. If the app says it handles
orientation or screen size changes then a relayout will occur when the
configuration has changed.
Fixes bug 11647107.
Change-Id: Ie8d49fd050442ebbdcf0b805087894e3a2fc4be9
Also use the existing full PreferredActivity match machinery instead
of the existing direct comparison now that the intent filters can
be more flexible.
Bug 11482259
Change-Id: Icb649ca60ecfbdb9ee3c256ee512d3f3f989e05f
As a next step they can be moved into separate directories to be
built as separate modules that may or may not be included in a
particular configuration.
Moves AppWidgetService, BackupManagerService, ClipboardService, DevicePolicyMS,
and WallpaperMS.
Change-Id: I33e48d070f38186819d3a1d7a4dc3984b75a9eda
