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
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
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
Bug: 120904891
Test: make docs && look at the output
Remove instances of {@link ColorLong}. Although the link is supposed to
go to
https://developer.android.com/reference/android/annotation/ColorLong.html
my web browser redirects me to
https://developer.android.com/reference
Perhaps there's a bug somewhere in the generation (I am able to navigate
to
https://developer.android.com/reference/android/support/annotation/ColorLong?hl=en
by searching on developer.android.com - notice the addition of
"support"), but I still think it would make more sense to send users to
the page for android.graphics.Color directly.
Switch over to {@code ColorLong} (which does not generate a link) and a
reference to look at the {@link Color} class.
Update parameter named "c" to one named "color".
Unify various Canvas#drawColor APIs to say "to draw onto the canvas"
(previously some said this, while others said "to draw with").
Change-Id: I78eff5c35e350f763aac0416f6ec1ccf12f89418
The behavior of the Typeface creating function when unsuppoted font
files are passed has changed unexpectedly. This CL revives the old
behaviors. Here is the list of public APIs and expected behaviors.
Resources#getFont for unsupported font
Exception: Resources#NotFoundException
Resources#getFont for unsupported font in XML
Exception: Resources#NotFoundException
Resources#getFont for unsupported font from provider
No Exception: Typeface.DEFAULT is returned
Typeface#Builder for unsupported font
No Exception: null is returned
Typeface#Builder for unavailable font
No Exception: null is returned
Typeface#createFromAsset for unsupported font
Not Exception: Typeface.DEFAULT is returned
Typeface#createFromAsset for unavailable font
Exception: RuntimeExcetpion
FontsContract#buildTypeface for unspported font
No Exception: null is returned
FontsContract#buildTypeface for unspported font in XML
No Exception: null is returned
FontsContract#buildTypeface for unspported font from provider
No Exception: null is returned
TextView inflation for unsupported font
No Exception: Typeface.DEFAULT is set
TextView inflation for unsupported font in XML
No Exception: Typeface.DEFAULT is set
TextView inflation for unsupported font from provider
No Exception: Typeface.DEFAULT is set
Bug: 127714175
Test: Manually done
Change-Id: Iaab037f4168546409ead67ed8eee7340418418ed
Currently when DWB adjusts the display's white point it uses standard
Illuminant D to convert CCT to CIE xy coordinates. This causes a slight
green tint, detectable by some users. Change this behavior to calculate
CIE xy based on the Planckian locus.
Bug: 128712066
Test:
a. Manual, by overriding target DWB CCT and observing resulting target
xy coordinates
b. atest FrameworksServicesTests:ColorDisplayServiceTest, making sure
there are no new failures (existing failures tracked in a separate bug)
Change-Id: I6fa336ee694730df45d5eacceb442aa556b5718e
The MeasuredText.getChars is used only from text layout internals:
- LineBreaker#computeLineBreaks
- Canvas.drawtextRun
Thus, no need to be exposed to public. Making it @hide
Change-Id: I7c27a4b95d7d5ebc2ad5d74c947cdea3ce08f2ab
Fix: 124795470
Test: N/A
This reverts commit 96e93959fb.
Reason for revert:
This breaks CTS. Looks like even in old devices, we tells errors to
developers. Just suppression is not a right solution here.
Change-Id: Ia1b1916d94d115174afe8e822fc669b37e5f3937
Bug: 77949917
Test: Iac4922cfa86c0c2b3b6c88b39d9b702ab046cd34
In P, the switch to Skia HW rendering lost a feature of HWUI's old
renderer: using a Paint with a BitmapShader resulted in filtering the
Bitmap, regardless of whether FILTER_BITMAP_FLAG was set.
This somewhat restores that behavior, in that it results in filtering
BitmapShaders so long as the client doesn't explicitly turn it off. This
also means that it continues to be possible to get a pixellated drawing
if the client *does* explicitly turn it off.
This reverts commit 1b6927dbb1. Original
CL was reverted due to a broken CTS test, which will be updated along
with this.
Change-Id: I61394b4ca6b93ba8405a0127b9c308444abfcbc2
Bug: 127580253
Test: CtsGraphicsTestCases
Perf: systrace
Follow on to I0b42c17159b290868a6bed7b90da096995504c4d, which did this
for other classes. I expect this to be more efficient due to passing
fewer JNI parameters, which appears to be the case based on the systrace
data for setColor(@ColorLong):
Duration:
(w/o this change) (w/ this change)
avg: 0.010 ms 0.005 ms
max: 9.130 ms 0.239 ms
min: 0.002 ms 0.002 ms
std: 0.052 ms 0.004 ms
The average is twice as fast, the max is significantly shorter, and the
standard deviation is much smaller as well.
Change-Id: I241824bf2a934746df93da1063b14f3080486cb5
Bug: 77949917
Test: I5737be68dccdc5ebb38291bf3515ae25553dcfc2
In P, the switch to Skia HW rendering lost a feature of HWUI's old
renderer: using a Paint with a BitmapShader resulted in filtering the
Bitmap, regardless of whether FILTER_BITMAP_FLAG was set.
This somewhat restores that behavior, in that it results in filtering
BitmapShaders so long as the client doesn't explicitly turn it off. This
also means that it continues to be possible to get a pixellated drawing
if the client *does* explicitly turn it off.
Change-Id: I62c726a0ba281de239092f066a3df041ecbcee5b
Bug: 121304803
Test: Infeasible
Previously, the NativeAllocationRegistry needed to report how much
native memory was being held onto by the Java class in order to get a
more accurate count of how much memory was in use. But recent changes
allow the system to have an even more accurate view of the native memory
with mallinfo(). Further, the AOSP change
Idccb8b50d26c8c3e93cc34040d784f74dfcdbf51 introduces new APIs that allow
distinguishing between large native malloc allocations, which should
cause more frequent mallinfo() checks, and whose sizes need be available
to ahat etc, and smaller native malloc allocations.
Bitmap and AnimatedImageDrawable use the version for large native malloc
allocations. The rest pass an implied size of 0. Note that many of the
old Registries used somewhat arbitrary sizes, reinforcing the fact that
the new way of keeping track of this is better.
Add Bitmap::pixelStorageType to differentiate between types of memory
that should be accounted for by the Registry.
Update Bitmap::getAllocationByteCount to report the actual size of
ashmem allocation.
Fix a typo in LineBreaker.java, discovered while looking to find
existing callers of Bitmap's constructor.
Change-Id: I57c407258450aeaf08b47df32432466639d9faed
Bug: 127580253
Test: CtsGraphicsTestCases
Perf: systrace
Restored with a partial revert of "Add Paint#get(ShadowLayer)ColorLong"
(commit 6ee411010e).
The original CL combined the @ColorInt and @ColorLong version for
simplicity, but required doing extra work for the @ColorInt version.
Separating them back out speeds it up at the cost of more code.
Using systrace I see the following stats:
Duration:
(w/o this change) (w/ this change)
avg: 0.020 ms 0.001 ms
max: 9.141 ms 0.072 ms
min: 0.005 ms 0.001 ms
std: 0.074 ms 0.001 ms
This change shows a significant speed improvement. It does not do the
same for setShadowLayer, which is likely used less frequently.
Change-Id: I9021864fcad7d0149b93674f09339f805c272994
