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: 134566750
Test: m droid
Change-Id: I2777e8f9da0c7e0f3fc84277600f9db45b2f837e
Exempt-From-Owner-Approval: no response from owners minor build change
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
Test: I7eb02bc2389aadc10ee0b65993bb7e2dab27a129
Also remove gBitmap_getAllocationByteCountMethodID. These called into
Java, which then called back into native. Instead, call the native method
directly. The only extra wrinkle is that the Java method returns 0
if (mRecycled). But we would never reach that return value, since if
it was recycled, we would have crashed in native Bitmap::assertValid.
Instead, throw an IllegalArgumentException when attempting to reuse
it.
This avoids the overhead of two JNI calls, which tend to be slow.
Change-Id: I29e8d2428036252cfad532b1351e3a3d33817b43
ArrayUtils methods can return null. Fix the assumption made by CPUL.
Test: atest android.view.cts.SystemGestureExclusionRectsTest
Change-Id: I513e179b9a5715c381218a1ceb7e35dc91d1797a
