If the Gradient angle is negative after
modding by 360, maintain the previous platform
behavior of TOP_BOTTOM oreintation instead of
attempting to wrap it
Test: Added CTS test to verify various negative
angle measurements
Bug: 142111195
Change-Id: Id9c050a9e15717bfaff331c6a37cb34cbce0f060
Add support for ViewRootImpl submitting buffers using
BLAST and put this support behind a disabled-by-default
FLAG.
Bug: 135786080
Change-Id: Ia3f205e34db9f9aa574c9c2e2c499dd3046af220
Fixed issue where GradientDrawable orientation had diverged
from the default behavior. Ensured that orientation by default
is configured to LEFT_RIGHT for xml defined GradientDrawables
and programmatically defined GradientDrawables have the
same default orientation of TOP_BOTTOM.
Refactored previous logic that would keep both the mAngle
parameter used in xml inflation and the mOrientation parameter
that is used to configure the angle of the gradient to no longer
keep these 2 values in sync.
Test: Added CTS test to verify orientation for xml and programmatically
defined GradientDrawables
Bug: 140835351
Bug: 139822941
Change-Id: I594496afe48d04d108053bf284e92bbfd3591fa3
This reverts commit d31d096720.
Reason for revert: Although this change fixed the behavior change for for creation of
GradientDrawables defined in xml, the default value for GradientDrawables defined
programmatically is different. The default orientation for GradientDrawables defined
in xml is LEFT_RIGHT, however, the default orientation for GradientDrawables defined
programmatically is TOP_BOTTOM. Since a fix for AAPT has been made to automatically
insert an angle measurement of 0 if one is not defined, we can revert this CL and target
a proper fix in master.
Change-Id: Ib8983386832fb25f53b5e68e76e9d41d9d26fec9
Bug: 140961740
Test: I41a93b47acde6a7985c53107f448a8b647d245d7
If ImageDecoder has a null AssetFileDescriptor, either from a Callable
or from a ContentResolver directly, throw a FileNotFoundException.
Previously, a NullPointerException was thrown attempting to dereference
it.
Change-Id: Ie738b9edc062e520835010befc001578fce09832
Fixed issue where in Android Q if no angle measurement
was specified the default gradient orientation of TOP_BOTTOM
was applied instead of the previous behavior of LEFT_RIGHT
Bug: 139822941
Test: Added CTS test to verify GradientDrawableTest
Change-Id: Ia8c53455740a29e1d123c90616066e16ddb4a241
Pass down a flag to prefer animation over still images
when decodeDrawble is used. Pass the flag via source
to avoid adding this flag to all create/createFrom/
nCreate method variants. Check the flag only in
native_create when we actually create the decoder.
bug: 120414514
bug: 78868457
Change-Id: I84b4edd0225df9eaa59df8a787bd5902146ab500
Some system fonts may not be there because of saving storages, e.g.
on Watch OS. Stop logging missing fonts error.
Bug: 135419244
Test: N/A
Change-Id: I358f45aee35f25911a29ce272ebd0398561d8864
The inner Drawable was never updated.
Bug: 135592087
Test: atest ColorStateListDrawableTest
Test: manual test valid ColorStateList XML in res/color
Change-Id: If922acd3054ded7cc068241376ebf7017e1ff6ff
Added null checks around usages of drawable child layers
within the constructor as well as the isProjected method
Test: Added cts tests to LayerDrawableTest
Bug: 134902243
Change-Id: I94a5fbc896ab53e29f4db4dcd04daf0bf9dd66dc
Bug: 131759669
Test: I5eca77e1a60e484e4e118b7e464a88363c539ca9
Test: Manual - assert no longer fires and app looks normal
The limitation to only support convex paths was due to a limitation
in the old renderer. Today, it is fine to use a concave path. Further,
Skia has changed how it computes complexity - it is more conservative,
so paths which were previously thought to be convex are no longer. We
cannot guarantee that a path will be considered convex (especially
after e.g. rotating it, as in the library in question), so drop the
requirement.
Change-Id: Ice88d0995750e066320cb175a87f8ae70ce3aeed
Added logic to wrap negative angle measures provided
for linear gradients to be between 0 and 360
Test: Added cts test to GradientDrawableTest
Bug: 132650579
Change-Id: Iefde8bfc4b043dbe9dc57247f48077587fb03f6e
The following fields are still lacking public getters:
Landroid/graphics/drawable/GradientDrawable$GradientState;->mStrokeDashGap:F
Landroid/graphics/drawable/GradientDrawable$GradientState;->mStrokeDashWidth:F
Landroid/graphics/drawable/GradientDrawable$GradientState;->mStrokeWidth:I
Removed the maxTargetSdk from the @UnsupportedAppUsage
annotation.
Bug: 132971065
Test: N/A
Change-Id: Id19452a8db6cda43c7d1b3c3c5ee74468c6de4e1
Bug: 132354626
Bug: 129117085
Test: skia unit tests and test cases described in the bug
Change-Id: Ieaa7c831dd6298ac0565e6f1837b1c1dbd4545da
(cherry picked from commit ac33a48751)
consumed properly
Moved methods to resolve the current gradient orientation
from GradientDrawable to GradientState. Fixed issue where
orientation parameter was not consumed properly in the
GradientDrawable constructor causing the angle and orientation
parameters to be out of sync.
Bug: 132420435
Test: Added test to CTS to verify GradientDrawable constructor behavior
Change-Id: I639d1ab4b8791810ea72c3f85878a8c7d9093661
with invalid angle parameters
Previously, GradientDrawable would fail xml parsing if
an angle measurement was not a multiple of 45 and the type
of gradient is linear. Restore the original behavior to only
verify the angle measurement only if the type is linear
instead of verifying this requirement for all gradient types.
Removed restriction that radii must be non-negative as
subsequent logic in GradientDrawable already clamps the radius
to valid parameters.
Bug: 130309904
Test: Updated tests in CtsGradientDrawableTest
Change-Id: Ib1b3a0bb80639ddc00be7e630c62e781dfa6d9cf
Bug: 130148101
Bug: 120904891
Test: I3bdb6a7edbab4b9b8f13d4597e5987e6db6fe928
Bitmap#wrapHardwareBuffer defaults to using the SRGB ColorSpace (i.e. if
null is supplied), but it's possible that where the HardwareBuffer was
originally used, it was associated with a different ColorSpace. Update
clients of this API to pass that ColorSpace.
Pass the ColorSpace's ID. This results in only supporting Named
ColorSpaces, which matches some of our other ColorSpace support, and
should be enough for most use cases.
Change-Id: I02460f079ed467199f368b4a4fd7708d6fa5433a
The key used in Typeface.Builder is different from the key used in
findFromCache method. The problem is key generation in Typeface.Builder
since the key should be created from requested parameters not the actual
font styles.
Here is the raw performance differences on walleye-userdebug
android.graphics.perftests.TypefaceCreatePerfTest(us):
createFromResources: 248 -> 23: (-225, -90.7%)
Bug: 131167183
Test: manually collected perf test result.
Change-Id: Idea25095979707ac84b7f4bc1ede0c2daefd6127
variants
Updated various framework Views to have equivalent BlendMode APIs
to replace the deprecated PorterDuff equivalents.
Updated InspectableProperty annotations to refer to the same
xml attributes as the original tintmode APIs
Bug: 126726419
Test: Added CTS tests to verify new BlendMode APIs
Change-Id: Id9ab36d3d4d29f351250723e9d13d49bc6062c83
Merged-In: Id9ab36d3d4d29f351250723e9d13d49bc6062c83
variants
Updated various framework Views to have equivalent BlendMode APIs
to replace the deprecated PorterDuff equivalents.
Updated InspectableProperty annotations to refer to the same
xml attributes as the original tintmode APIs
Bug: 126726419
Test: Added CTS tests to verify new BlendMode APIs
Change-Id: Id9ab36d3d4d29f351250723e9d13d49bc6062c83
Callers are supposed to close the hardware buffer themselves. Creating
a utility method around this
Bug: 123874711
Test: No more leak warning on device
Change-Id: I2cf215f0646222f63e564a58edab1ffffa396ff3
Added missing usesMathJax tag within Javadoc for
each BlendMode enum value. This should ensure that the
blending formulas are rendered properly in the android documentation
Test: N/A
Bug: 130041190
Change-Id: I6c6dcc1804d8399468191bf758bf6cc7685918b5
(cherry picked from commit 39055b05e0)
