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
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
Bug: 150395371
Test: make
This became BitmapRegionDecoder in
I3e60c7fe4abd0289e1384e69a08fd20fe6fb0e10, but we forgot to delete the
Java file. It's been unused since then.
Change-Id: Ibe4e813d448346c9b15d4e112a2062713321edc9
Bug: 148155907
Bug: 150395371
Test: I652101b6a4b3d9de4e77a316ba0436ce466f3620
Bitmap already has a method to create a Bitmap from a HardwareBuffer,
and the NDK allows doing the reverse. This updates the SDK to allow
retrieving the HardwareBuffer, too.
Update the docs to match wrapHardwareBuffer regarding modifications.
Throw an Exception if called on a non-HARDWARE Bitmap, which is
friendlier than the crash that previously happened on the hidden API
(and the one it replaced).
Change-Id: I408cff708efa76f89e0c4c6dae16f19166ffe74d
Bug: 140600285
Test: CtsGraphicsTestCases:android.graphics.cts.BitmapRegionDecoderTest
Test: I684e0ed6049e146e2c1698383c73709a7163b642
Clean up BRD in preparation for mainline module changes.
isShareable has been ignored for a long time, so update the APIs to
reflect that. Deprecate the existing ones, and add replacements without
isShareable. Make newInstance(FileDescriptor, boolean) into
newInstance(ParcelFileDescriptor), as recommended by the build failure.
- newInstance(byte[], int, int, boolean) has ignored it since
I7dd545c9d52d21c226e11b8921e35a1d9bba9515 (GB)
- newInstance(FileDescriptor, boolean) has ignored it since
Id1e1c8c5938ee1a33c6fa3caabd2c28e89243eb4 (KITKAT)
- newInstance(InputStream, boolean) and newInstance(String, boolean)
have always ignored it
Document WebP and HEIF support.
Add @NonNull annotations. Remove misleading comments about
returning null on failure. My understanding is that if it either returns
an object or throws an Exception, @NonNull is the appropriate
annotation - the client does not need to check for null.
Change-Id: I0bf8c4c72cc118d2799a59e8eb6c2cede546fceb
Bug: 150395371
Test: make
- Mark mDensity as package-protected, since it is not used elsewhere.
- Document getNativeInstance, getOpticalInsets, getNinePatchInsets,
and scaleFromDensity - where they are called, and that they should not
be called from outside the module.
- Mark setImmutable as private. No outside callers use it.
Change-Id: I85efe4829e2914222696aa659f8a21b699c3d788
Bug: 63136392
Bug: 150395371
Test: make
This reverts commit 1480b67635.
Bitmap moving into a new mainline module in S. These module-boundary-
crossing hidden APIs need to be either made official or removed.
We already got the information we need from this logging, so remove it
and the hidden APIs. If/when we need to investigate this in the future,
we should be able to recreate the logging without crossing the boundary.
Change-Id: I5d094a0e427d225719614745867d5b00888d8fec
Previous attempts to do this ignored the offset that the
AssetFileDescriptor may have.
Bug: 149927583
Test: CtsTextTestCases and androidx.appcompat.widget.AppCompatTextViewTest
Change-Id: Idcc8cb83a7f265cfa12707b7ce643b35f7f72352
The logic to attempt to directly mmap uncompressed font assets
has resulted in breakages for some applications and utilities.
This CL disables this speculative optimzation until we can determine
the problem with this approach and if such an optimization is required.
Bug: 149780695
Test: CtsTextTestCases and androidx.appcompat.widget.AppCompatTextViewTest
Change-Id: I3b10a801a5600aefe8573fab1b28cd79c848c892
* changes:
Export symbols for the newly exposed APEX/internal headers
Remove dependence on libandroid_runtime from Bitmap.cpp
Update Region.cpp to use AParcel NDK APIs
Cleanup header and build targets for libhwui clients.
Remove dependencies on headers outside UI module
Cleanup LOG_TAG when bundled in HWUI
Move android.graphics JNI & APEX files into HWUI
The end goal is to have Bitmap.cpp use AParcel, but until that
API is extended to support this use case this is an alternative
way to isolate the graphics files from the libandroid_runtime.
Test: CtsGraphicsTestCases
Bug: 145227478
Change-Id: Ie3854fe03dec4f7b1b485295bb9a5ebba52ddb7c
Bug: 148155907
Bug: 135299581
Test: TODO
Hidden for now. We'd like to make it an SDK API eventually
(b/148155907).
Internal code is currently calling createGraphicBufferHandle. This is
not something we plan to expose from the UI rendering module, so add a
method to get a HardwareBuffer instead. This is something we were
already planning to add. It seems that clients of
createGraphicBufferHandle really wanted a Parcelable to pass the
HARDWARE Bitmap to another thread. This should satisfy that use case.
Change-Id: Id701f7c7eab37830cd7d2cdb929cbe6ba4eca119
A wrapper still exists at android.view.RenderNode animator
as it needs access to internals of the view that would violate
the package layering if moved into android.graphics.animation.
This CL also moves the Java and cpp files associated with creating
a native interpolator that can be run directly on the RenderThread.
Bug: 149293249
Test: CtsViewTestCases
Change-Id: I5260331fedbd634cf2f6d6d392941e7284527420
