Bug: 152983829
Bug: 119066174
Test: make; flash and boot
This was already renamed to RecordingCanvas, which is in the graphics
package. It was revived in the old location to temporarily support apps
that were relying on the old name. Currently go/nonsdk-dash shows no
usages, neither via runtime logging nor via static analysis.
RecordingCanvas also cannot refer to this hidden class in the view
package once graphics is its own mainline module. Remove the hidden
class, which was the original plan anyway.
Restore RecordingCanvas' constructor back to private, since it had been
changed to protected as part of the revived DisplayListCanvas.
Change-Id: I7ae1fa043811e361efa6c28753a92bb9c30a7198
Bug: 154954875
Bug: 143231863
Test: I93b01cb60a8c76110ea2ff4250d0048512629d8d
I9229039b752bafa9a9b85b914a62093dff1eec34 switched from "==" to
".equals", but it did not take into account that Uri#getScheme() can
return null. Switch around the .equals check so that it is called on
SCHEME_CONTENT, which will never be null.
Change-Id: I0df5d2407a32fad0e21e597697af293fbc2fb315
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: 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
