Set ScreenshotSurface secure if any secure content is shown.

The screenrecord command can record secure content during rotation.
This is because the ScreenshotSurface surface for rotation animation
is not set secure even though its screenshot contains secure content.

Change-Id: I5a70be71ddfc26de4230e7d4fe547210c2154210
Adjust to the change in the private SSLParameterImpl API.

Conscrypt's SSLParameterImpl getDefaultTrustManager was renamed to
getDefaultX509TrustManager.

Bug: 13563574
Change-Id: I601c651d631f5a2e4a04d21941186553988e5286
Merge "Adjust to the change in the private SSLParameterImpl API."
Fix scaleNinePatch.

Use yDivs for yDivs, and not xDivs.

bug: 13394494

(cherry picked from commit 42a51ae8812bccde7ff370cc2688f7955e489ad4)

Change-Id: Ia0a7d701a170945216ab247a483e7f972b6fe17e
Merge "Set ScreenshotSurface secure if any secure content is shown."
Use X509ExtendedTrustManager and not Conscrypt

This allows the new X509ExtendedTrustManager to be used instead of
Conscrypt directly.

Bug: 13103812
Change-Id: I736f475342395f26657f2371828a6d3a0065a50a
Solve three memory leaks related to PatchCache

A Patch can be fairly large, holding bitmap data, but
is also frequently leaked which adds to the severity.
The feature is used in many important processes such
as Home, SystemUI and Chrome.

The following leaks are solved:

1. The Patch itself was not always freed.
PatchCache::removeDeferred() can mark patches to be
cared for by PatchCache::clearGarbage(). But
mCache.remove() would only destroy the container
and the pointer, not the Patch object itself.

2. The vertices stored in the Patch at Patch::createMesh()
would always leak. The empty/default destructor in Patch
would not properly destroy "vertices" since it's just a
pointer.

3. A BufferBlock that's added to the mFreeBlocks
in PatchCache could leak. The leak happened when a
patch later needed the entire free block, because the
object was removed from the list but never deleted
in PatchCache::setupMesh().

Change-Id: I41e60824479230b67426fc546d3dbff294c8891f
Don't wait for finishing animation when second display is disconnected

Basically WindowManagerService wait for finishing animation when
a window is removed. But when second display is disconnected, windows
on second display can't be shown even if animation is waited for.
On the contrary, it keeps on waiting for finishing the animation
in special case.

With this fix windows are immediately removed without waiting for
animation when second display is disconnected.

Change-Id: I1354c193c04db394a21a11c174e10c8e7da17a0e
Merge "Fix scaleNinePatch."
Merge "Don't wait for finishing animation when second display is disconnected"
Merge "Use X509ExtendedTrustManager and not Conscrypt"
Merge "Solve three memory leaks related to PatchCache"
Merge remote-tracking branch 'aosp/master' into HEAD