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
This is from API council feedback.
Bug: 124794899
Test: atest CtsTextTestCases
Test: atest CtsGraphicsTestCases
Change-Id: Ifa95f87067239cca9c0791bf079045e4f645c3ad
I suppressed the font error during resource loading only if the
targetSdkVersion is API 28 or before, but it turned out that this
makes developers hard to use font resources since:
- We don't give a list of supported font files and OEM may extend/shrink
the font support.
- There is no way to resolve this error during layout inflation.
So, now always supress the IllegalArgumentException during building
Typeface in resource loading.
Bug: 127714175
Test: atest CtsTextTestCases
Test: atest CtsGraphicsTestCases
Test: atest FontsContractTest
Test: atest CtsWidgetTestCases
Change-Id: I08b9f27aaf25ff491fa36d0a4befb3c6e64abfcf
Adding a corresponding getter for the recently opened View.setAnimationMatrix(Matrix).
Bug: 126376184
Test: new cts tests added
Change-Id: I9d5abb1ae3606d2e3884859ce9a81c11c65613d6
The hyphen edit is packed into 8bit integer in native library, but this
should not be exposed to public API as API council suggested.
This CL includes:
- Removing packing structure from HyphenEdit and move constants from
Hyphenator to Paint.
- Replace LineBreaker's getLineHyphenEdit with two separate start/end
function.
- Replace Paint's getHyphenEdit with two separate start/end function.
- StaticLayout still relies on this packing mechanism but no longer need
to be the same packing structure as in Minikin.
Bug: 124794844
Test: atest CtsGraphicsTestCases
Test: atest CtsTextTestCases
Change-Id: I8206061f554cf6e119b2b565162f54317eac630a
