1. Avoid a seperate IPC querying in to system-server
to initialize the mUseBLAST flag.
2. Avoid calling property_get_bool with each BufferQueue
creation.
Instead we piggy-back both values inside addWindow return values.
Bug: 152501005
Test: Existing tests pass
Change-Id: If130560a8230f8d399cf7631264d551522939faa
Bug: 154628299
Test: ColorStateListDrawableTest, DefaultFocusHighlightTest
The system needs this to show keyboard focus. Apps may want to do
something for keyboard focus, and they may also want to write custom
drawables that handle keyboard focus. Making this API public allows them
to do this.
Change-Id: Id6b2df3a14f15db5b7f8ca664362be0b78c3e2c4
Bug: 154628299
Test: make
This method is no longer used internally. This class is moving to a
mainline module, which should not expose any @hidden methods. Leave the
methods for now due to UnsupportedAppUsage.
Change-Id: I8fbae367d318ddc585c954e6279afe16dacd325f
Bug: 154628299
Test: view the dashboard
Although its usage is listed as LOW, it only shows up in static
analysis. All of the callers are within BitmapDrawable.
Change-Id: I43fc83339336bcddd244990555e7f2dd8eae787f
With HWUI becoming an APEX module, we need to use public apis wherever
possible - since there aren't plans to expose a stable api for physical
display information through native, instead grab the system context
from ActivityThread so that we can use DisplayManager's public apis.
The api for retrieving the system context is left as a hidden api - a
future change should stabilize the API or switch to a new api that does
not yet exist. But, this is the right shape for plumbing through the
display information, as the old code retrieved it through SurfaceFlinger
which should not be stabilized as the source of truth for display
information is DisplayManagerService.
Bug: 146387012
Bug: 150880248
Test: builds, boots, verified that the correct display info is plumbed
down
Change-Id: I1a99a72244969bdece2903993e3beb27a6e534b1
Bug: 148155907
Bug: 150395371
Bug: 150956734
Test: make
All internal callers have been moved to getHardwareBuffer. Although the
method was listed as @UnsupportedAppUsage and go/nonsdk-dash-per-api
lists MEDIUM usage, there is no runtime usage logged, and static
analysis only reveals one call site that has been updated.
Change-Id: If8c652efd68e82286ab46eed0084b5607152ad01
Add missing <p> tags which should make some methods
more readable. Also added a few {@code} tags and a
couple of missing {@link} tags.
Fixes: 154547852
Test: m offline-sdk-docs
Change-Id: I1b8d0212b54e902378d5d25f6d555f69af207604
Bug: 148155907
Bug: 150395371
Test: I638094c90f7a49bf0f625cf5cdc4e5377f67de79
Follow up to I408cff708efa76f89e0c4c6dae16f19166ffe74d. If the
HardwareBuffer (Java object) held by a Bitmap is closed, it is not
useful to a client. Rather than returning it, create a new object from
the native object.
Change-Id: Ia35f211fb9f42929ac5e50f038de201c9912f918
Whenever an activity's configuration is updated, then tell
HardwareRenderer about it. That way, visualizating frame info does not
need to learn the display density from SurfaceFlinger, which reduces the
native-side api surface for displays.
For now, this method is kept hidden and will be stabilized when
HardwareRenderer's apis are stabilized for Mainline inclusion.
Bug: 146387012
Test: boots, builds
Test: jank visualizer
Change-Id: I51d2964bb78882516ebdff05b80819814894bdce
Bug: 153410582
Test: I0a280cdfdb02766f5e415408386cce49a59504ab
For gray color spaces, Skia creates a special toXYZD50 matrix which does
not have any concept of primaries. Update the Java ColorSpace to
recognize such a matrix and treat it specially. Instead of creating
primaries, use a set of dummy values.
This fixes a bug where the Java ColorSpace was invalid (NaNs in its
transforms) and applying it to a new Bitmap yielded incorrect results.
Fix up the @see links in getPrimaries and surrounding methods.
Change-Id: I94fe232e10f56a69832d4a39a2e5909eac641264
(cherry picked from commit d82d585f28)
Merged-In: I94fe232e10f56a69832d4a39a2e5909eac641264
Bug: 153410582
Test: I0a280cdfdb02766f5e415408386cce49a59504ab
For gray color spaces, Skia creates a special toXYZD50 matrix which does
not have any concept of primaries. Update the Java ColorSpace to
recognize such a matrix and treat it specially. Instead of creating
primaries, use a set of dummy values.
This fixes a bug where the Java ColorSpace was invalid (NaNs in its
transforms) and applying it to a new Bitmap yielded incorrect results.
Fix up the @see links in getPrimaries and surrounding methods.
Change-Id: I94fe232e10f56a69832d4a39a2e5909eac641264
Point is moving into the UI/graphics module, so hidden apis need to be
cleaned up:
* printShortString is now publicly exposed and renamed to Point#dump, to
mirror already public APIs such as TokenWatcher#dump
* The two convert methods have very few users and their implementations
are both trivial and only rely on the existing public API, so they are
in-lined directly in the callers.
* Introduce a GraphicsProtos utility class living outside of the module
that just converts Graphics parcelables into protobuf objects. Currently
WindowManager and the view system dump protobuf representations for
debugging. Accordingly GraphicsProtos is a hidden public class, as the
protobuf representation of the graphics classes are not publicly
exposed and should be considered an implementation detail of the system.
Bug: 152804266
Test: boots, builds
Change-Id: I5e25dbbe47b3c690d7d763a0082beb8d8a9c86d3
Bug: 152322291
Test: CtsGraphicsTestCases
ImageDecoder is moving to a mainline module, so the system can no longer
access the @hidden sApiLevel without making it @SystemApi. Instead of
promoting the existing API, provide a common class to be used by any UI
rendering class that needs to access the targetSdkVersion. Switch AVD to
use the new class, which is a SystemApi.
Change-Id: Ie7172fb93364a1e04ab844b8fa64887bf9d8b005
Bug: 152322291
Test: make
go/nonsdk-dash-per-api shows no usage. This was likely a false positive
generated by JNI calls.
Change-Id: I87f9bd0a69c6f7561a5ce3dfe371deb774307b23
Bug: 152322291
Test: make
Once ImageDecoder is in a mainline module, the system (i.e. ImageView)
needs to be able to access this method.
External clients can already use createSource(ContentResolver, Uri). If
they want density scaling, they can use
createSource(Resources, int resId).
Change-Id: I560972c1ef08ee5e610e3c2c182353a6767fd082
Bug: 152322291
Test: Ib50eba48e3557a0147b95dd6ce3e8589ab07c127
These methods are used in various places in the system, and the system
will not be able to access them as @hidden APIs once ImageDecoder is
part of a mainline module. They were originally hidden to discourage
clients from keeping the encoded data allocated in a large buffer,
especially for animated images. But this is already possible using a
ByteBuffer.
Change-Id: If5350d4f2ff88ac634e48b9224d70954fd312d30
Bug: 152322291
Test: make
I originally added this thinking a client might use the following
pattern:
Size size = decoder.getSampledSize(sampleSize);
decoder.setTargetSize(size.getWidth(), size.getHeight());
But this is unnecessary. The client can directly call:
decoder.setTargetSampleSize(sampleSize);
OTOH, if the client wanted to use a crop, too, then it would be useful
to know the exact sampled size. That could also be satisfied by adding
accessors that return the target size.
Change-Id: Id61907a8268f424d70503598d5bf844cde469d60
Bug: 140600285
Test: Ifd9e9abe3f2c89f724a0b918d99ec4e9db65ad56
After adding some tests, I confirmed that newInstance(InputStream) (and
the deprecated version that includes boolean isShareable) can return
null if the InputStream is null. Update the annotations for both - the
old one that has always been wrong, and the new one added in
I0bf8c4c72cc118d2799a59e8eb6c2cede546fceb.
Change-Id: Ib820edd1ad62665092c272a7b89b0a29b0e1bb32
Bug: 152322291
Test: make
Once ImageDecoder is in a mainline module, the system can no longer
access @hidden methods (unless they're @SystemApi), so this
removes/documents some. The ones in Source are not used anywhere outside
ImageDecoder AFAICT, so they are unneeded. Document setOutPaddingRect,
which needs to be public/@hide so it can be accessed by the drawable
package, which will also be in the module.
Change-Id: I5cd9c0553e8d27d6679cbc431fcadc96d818687d
The copy constructor of AdaptiveIconDrawable#LayerState currently does
not copy mSourceDrawableId from the original layer state. This prevents
drawables created from preloaded AdaptiveIconDrawables from having the
correct source drawable resource id.
Bug: 148488431
Test: CtsContentTestCases:android.content.pm.cts.PackageManagerTest
Change-Id: I7795a337a2a364677e375776c7aec5bc9189e0da
Bug: 152322291
Test: none
go/nonsdk-dash shows no usage of postProcessAndRelease, so remove the
annotation.
Change-Id: I7c7b91bd58c30f901f98a11c9688beb0fcd7db91
Bug: 150395371
Test: make
This method is being replaced by
Bitmap#wrapHardwareBuffer(HardwareBuffer) as part of the switch to a
mainline module.
With I41cb03fb65432d208820a428783de82a9f152035, there are no more
callers of this overload.
Change-Id: Ia837d6c4019d1e8495829b606fe62a68d557119a
Bug: 150395371
Test: make && flashall
Bitmap is replacing methods that use a hidden GraphicBuffer with ones
that use the public HardwareBuffer. ScreenshotGraphicBuffer is just a
holder for GraphicBuffer and some metadata; switch it to hold a
HardwareBuffer (and rename to match).
Remove GraphicBuffer#createFromExisting, which was only called by
ScreenshotGraphicBuffer#createFromNative. Also remove JNI references to
that method, which were no longer in use.
Switch uses of GraphicBuffer that retrieve it from a
ScreenshotGraphicBuffer to HardwareBuffer.
Changes are almost entirely mechanical:
- (Screenshot)GraphicBuffer -> (Screenshot)HardwareBuffer
- GraphicBuffer#destroy -> HardwareBuffer#close
- getGraphicBuffer -> getHardwareBuffer
When creating a Snapshot in SurfaceFreezer, use the ColorSpace of the
ScreenshotHardwareBuffer.
Remove GraphicBuffer#createFromExisting. This is no longer necessary,
and although it was marked UnsupportedAppUsage, go/nonsdk-dash shows no
usage.
Change-Id: I41cb03fb65432d208820a428783de82a9f152035
Bug: 150395371
Test: make
This is no longer used internally. Remove @hide so no one is tempted to
use it. Leave the method here out of caution - it is marked
@UnsupportedAppUsage and static analysis shows some usage (though
runtime analysis shows none). Though it's likely unnecessary to keep,
there is little to no burden to keeping it.
Change-Id: I2f2f7b6cec45630acde1e0d903ca5dc6a3fec349
Bug: 150395371
Test: make
After I359187a5c70b5e241c7f5879d50fde2a7449c818, there are no more
internal callers. go/nonsdk-dash only shows Instagram apps calling it.
We've discussed with Instagram, and they no longer use this version.
Change-Id: Ic152223f62becf3e6b3cb0006ad762bf85337db6
Bug: 150395371
Test: I442cd0c7a849e4c6a2fe7ba21b25a6e44417bbf5
The system needs to move off of @hidden Bitmap APIs so Bitmap can move
to a mainline module. It is valuable to provide a public way for clients
to create a Bitmap backed by ashmem, and the method's usage level is
HIGH. As I understand it, ashmem is being deprecated, so make the new
name more general: #asShared(). This method calls createAshmemBitmap(),
which must continue to exist for now due to the greylist. Add a
maxTargetSdk and publicAlternatives to move clients to the new method.
Mark asShared as @NonNull. It should only fail due to a failure to
allocate the shared memory. Throw a RunTimeException in this (rare)
case.
Add a (private) native method to check whether the Bitmap is already
backed by ashmem so it can skip the copy as necessary.
Remove outdated comments in both createAshmemBitmap methods regarding
SRGB. The new Bitmap will have the same ColorSpace as the original.
Remove the Config param from DisplayContent#screenshotLocked. It is only
ever called with ARGB_8888, which matches the ScreenshotGraphicBuffer
it is copied from. This means Bitmap#createAshmemBitmap(Config) does not
need a public version. It may need to continue to exist due to
@UnsupportedAppUsage.
Change-Id: I359187a5c70b5e241c7f5879d50fde2a7449c818
Test: make
This method is marked as UnsupportedAppUsage, but that was for the
signature prior to I0bf8c4c72cc118d2799a59e8eb6c2cede546fceb (which has
not been released). This was a false positive, anyway. No app should be
using this while there is an almost identical public method.
Change-Id: Ib71a58be6ec72cd4c52e8fca3c2cd4055df55ecf
