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
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)
both PorterDuff.Mode and BlendMode
The existing documentation had annotated the PorterDuff.Mode
parameter of Drawable#setTintMode to be @NonNull. However,
some applications were still passing in null as a parameter.
This was fine in previous releases as the default implementation
of Drawable#setTintMode did not read this field. With the
recent changes to introduce the BlendMode API, the nullability
assumption broke for various apps that passed in null, causing
NullPointerExceptions to be thrown.
Instead, update the documentation to be nullable and internally
convert the parameter to the corresponding default for either
PorterDuff.Mode or BlendMode.
Test: Added CTS tests to verify null behavior for each setTintMode
overload
Bug: 129446670
Change-Id: I42a4b03d190e5a64df518b5c768b2c22853abf12
Theme defined GradientDrawable attributes
Fixed issue where attributes that are supposed to be defined
together would throw exceptions if they are configured through
multiple inflation passes both with and without theme attributes.
Removed conditional logic that would parse attributes only
if the corresponding gradient type matched. Instead, attributes
are parsed on each inflation pass, falling back on previously
resolved parameters in the absence of a field. Validation
of the radius parameters has moved to ensureValidRect
Test: Added test to GradientDrawableTest
Bug: 127838188
Change-Id: Ie05e416eb747c774b9a39d4d0be28e1e775f0db5
For some reason this circular dependency will create crash in
robo tests.
Fixes: 129417525
Test: RunSettingsRoboTests
Change-Id: Ic7641840ecfed9ba0270d7d9ce03622a7053df74
Test: CtsGraphicsTestCases, CtsUiRenderingTestCases,
CtsRenderscriptTestCases
This is significantly faster than passing the Java object down and then
calling a JNI method to retrieve the pointer. See
https://buganizer.corp.google.com/issues/16656908#comment19
In some cases this changes what used to be native crashes (due to
android::BitmapWrapper:assertValid's LOG_ALWAYS_FATAL_IF) into
NullPointerExceptions (if a caller used a null Bitmap).
In addition:
- Remove unnecessary JNIEnv param from toBitmap(jlong)
- Change instances of toBitmap(JNIEnv*, jobject) to the above
- Replace calls to GraphicsJNI::getSkBitmap() to inline calls to
toBitmap/getSkBitmap
- make Canvas#nInitRaster @FastNative (FIXME: Could these be
@CriticalNative?)
Change-Id: I6194097be1b6e6952eba70e1e7052a5a250eed93
Updated various framework APIs to leverage the new BlendMode API
that parallels the corresponding porterduff mode equivalent.
Added new Drawable#onApplyBlendMode API that provides a backward
compatible solution for Drawable implementations that leverage
the new BlendMode API as well as fall back on the traditional
setTintMode(PorterDuff.Mode) API for instances where it is not
implemented
Bug:126726419
Test: Re-ran CTS graphics test cases
Change-Id: I119a7f57dce0a095c0a73cf83dc50b82beff5e32
