Obtaining a thumbnail for a Uri requires opening it with the slightly
obscure openTypedAssetFileDescriptor(), passing in "image/*" with the
right Bundle of EXTRA_SIZE to hint the target area on screen, and
defensively scaling any returned results.
This is pretty tedious to get right, so offer a convenience method
that does all this for the developer. Internally uses ImageDecoder
to follow best-practices, and replaces older getDocumentThumbnail()
implementation by delegating to this one.
A future CL will teach ImageDecoder about how to read any embedded
EXIF thumbnails, including any required rotation.
Bug: 111268862
Test: atest FrameworksCoreTests:android.content.ContentResolverTest
Change-Id: I5c9c09ddf9b480f3b5c6ade0a078cccb68de2f2b
We need to be more precise when removing the window that is being
replaced. We used to depend on the fact that we can remove it after
the first draw of the new added window. However, due to resizing the
old window might reset its draw state and that will trigger a removal
of that window.
We need to add an information about the window that is replacing the
old one and only when this new window draws itself, we remove the old
one.
This improves the transition after maximizing docked window. This is
a situation where first resize operation finishes and immediately
after we have a replacement operation.
Bug: 24914011
Change-Id: Ia8e5bb7872787e663ba23f26588f9c4db1a5e574
We never use this field as a rectangle, we only depend on its left-top
corner. Using a frame is only confusing about the purpose of this field.
Change-Id: I5d6e6321db4fa3203bb7e0f1975ae6ddd1ec09bb
PointF was missing these methods found in Point.
This change also properly implements equals() and hashcode() for
Point to match the PointF implementations.
Change-Id: Ic97280fb9f8c7011d8a13103c67d6e898adf00c0
Applications now get the display size from the window manager. No
behavior should be changed yet, this is just prep for some real
changes.
Change-Id: I2958a6660895c1cba2b670509600014e55ee9273
