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: 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
Here are the list this CL includes:
- Adding missing @NonNull, @Nullable, @IntRange annotations
- Added @Px annotation to Paint.set/getWordSpacing
- Change Builder classes to final.
- Change FileDescriptor to ParcelFileDescriptor as described in guideline.
- With this change, additional error handling is required in old
Typeface.Builder but we can keep the same behavior (silently fallback to
system fallback in error case).
- Fix comment in getLineHyphenEdit in LineBreaker.Result
- Rename setJustified to setJustificationMode in LineBreaker.Builder
Fix: 126702154
Fix: 126701272
Fix: 126701569
Fix: 126701953
Fix: 126701507
Fix: 126701667
Fix: 126700866
Fix: 126701009
Fix: 126700795
Fix: 126700292
Fix: 126699209
Fix: 124795407
Fix: 124795470
Bug: 124794844
Bug: 124794899
Test: m update-api
Test: TreeHugger
Change-Id: If6e8566b0eef9151d35d75b7f258128d7d3df358
