-Added documentation on RenderEffect usage
-Updated documentation regarding coordinate space
of dst rect to be within bounds of target
RenderNode
-Updated createBlendModeEffect documentation to
remove references to nullability since the parameters
are required to be non-null
Bug: 173657415
Test: N/A
Change-Id: Ief136650e40d1b820de9e175ac906f87c67ea864
Usage has been discovered by an app so reverting this to its previous
state. This is conceptually a partial revert of change 5d123b6775.
NoNonSdkCheck: b/170729553
Bug: 176388660
Test: m
Change-Id: I4399e4d431f8a443343de312e131fbf86d0f60b5
Usage has been discovered by an app so reverting this to its previous
state. This is conceptually a partial revert of change 5d123b6775.
NoNonSdkCheck: b/170729553
Bug: 175939224
Test: m
Change-Id: I277b085b490407bbe1899dd7f4614f51cd9ce36e
Currently SV with blast sync requests a sync transaction from VRI and
merges its transactions with VRI's sync transaction. This can break if
we are not able to set the request in time.
Instead this change will merge SV transaction from the renderthread to
the VRI BlastBufferQueue specifying the framenumber which the
transaction should be merged with. The transaction will be queued until
we submit a VRI buffer with the requested frame number.
Test: open bubbles with sv blast
Test: atest SurfaceViewSyncTest
Bug: 175594838
Change-Id: I87ba346d782f615bab2e8a692adb2b3c49ef4021
The issue is the following:
1. Call relayout from VRI. drawsNeededToReport = 1
2. SV also will need to be updated. drawsNeedToReport = 2
3. VRI is finished rendering, but SV is not. drawsNeedToReport = 1
4. VRI calls relayout again. drawsNeedToReport = 2
5. SV finishes drawing. drawsNeedToReport = 1
BBQ will get stuck since it's waiting indefinitey for a transaction
callback. The previous transaction can never get applied since we're
still waiting until drawsNeededToReport = 0.
This prevents situations like this from happening since it will not
allow a relayout to get called until the previous transaction has been
applied.
Test: Split screen with chrome
Bug: 167202096
Change-Id: I167a90ef00fa6677b3c55239e74eefb6a1384baf
ActivityThread.mBoundApplication has @UnsupportedAppUsage, so apps can
re-send BIND_APPLICATION message with the same AppBindData by using
reflection.
Bug: 174969232
Test: manually tested with the test app in the bug
Change-Id: Ic96d670f6346d9d1373607b4ae6e78b78194a09c
Bug: 174932174
Test: None
We are already OWNERS of the native side (libs/hwui), and we are active
in the development of the Java side as wel.
Change-Id: I3727411e0123b80843fc6f936b8b3700c8943825
Added View API to configure RenderEffect on the underlying
RenderNode
Bug: 159712515
Test: Added CtsUiRenderingTestCase
Change-Id: Ic64009ac79927d61c7c1f63306ced3da18fce1da
Bug: 174932174
Test: I solemnly swear I tested this conflict resolution.
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Change-Id: I9262a08ffc1ccede8e519d0eed90ed2bfcf0232c
As general background, OWNERS files expedite code reviews by helping
code authors quickly find relevant reviewers, and they also ensure
that stakeholders are involved in code changes in their areas.
Some teams under frameworks/base/ have been using OWNERS files
successfully for many years, and we're ready to expand them to cover
more areas. Here's the historical coverage statistics for the last
two years of changes before these new OWNERS changes land:
-- 56% of changes are fully covered by OWNERS
-- 17% of changes are partially covered by OWNERS
-- 25% of changes have no OWNERS coverage
Working closely with team leads, we've now identified clear OWNERS on
a per-package basis, and we're using "include" directives whenever
possible to to simplify future maintenance. With this extensive
effort, we've now improved our coverage as follows:
-- 98% of changes are fully covered by OWNERS
-- 1% of changes are partially covered by OWNERS
-- 1% of changes have no OWNERS coverage
This specific change is automatically generated by a script from
detailed ownership information confirmed by team leads.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I9789c97c1de8e5d962b48c29c57d82fe83729eba
Change-Id: I9789c97c1de8e5d962b48c29c57d82fe83729eba
The fonts.xml is no longer parsed once we move to new model.
Thus, need to parse fonts.xml when SystemFonts#getAvailableFonts
is called.
Bug: 173752727
Test: atest NativeSystemFontTest
Change-Id: I628a2586f8450b942caf34ede5dc827e31fff0ef
FrameInfo will now be per-window; that is, per-ViewRootImpl.
Some of the information should remain “global” (it remain in Choreographer),
while some information is going to become ViewRootImpl-specific.
Before the information gets passed to the native layer,
the ViewRootImpl-specific info will be stitched together
with the general Choreographer info.
This change is useful in order to correctly correlate frames with a specific
input event. In the unlikely scenario of a user touching two windows of the
same app simultaneously, this change will allow us to correctly measure the
latency of both frames produced by the windows.
Design doc: https://docs.google.com/document/d/1KMpMBlOxnl7zkWBCbXZZE6ZlaHEA4efYnN6WYK8n3FE/edit?resourcekey=0-eqooVNP0SskupljlTFvtOQ
Test: atest ViewFrameInfoTest
Bug: 169866723
Change-Id: Ib0bf9cd51cbcc0b9b70460c929c480eb490ec322
Currently, fonts are loaded in Zygote.
This CL adds a preparation to switch it to system server and
bindApplication(), so that system server will be able to update font map
at runtime.
(1) Zygote will be initialized without fonts.
(2) System server will maintain a serialized font map in ashmem.
(3) Apps will load font map from the ashmem in bindApplication().
The change is guarded by Typeface.ENABLE_LAZY_TYPEFACE_INITIALIZATION,
and the new behavior is disabled by default.
I tested with ENABLE_LAZY_TYPEFACE_INITIALIZATION = true.
Bug: 172891184
Test: atest FrameworksCoreTests:TypefaceTest
Test: atest CtsGraphicsTestCases
Test: atest CtsTextTestCases
Test: atest CtsWidgetTestCases
Change-Id: I40832962a4b27f6160c4dc6268689c52f6a4dd33
When getting DISPLAY_EVENT_FRAME_RATE_OVERRIDE from SurfaceFlinger,
expose the overridden frame rate to the relevant application
if the current refresh rate allows that.
Bug: 169271059
Bug: 169271062
Bug: 170503758
Test: manual test using SF backdoor
adb shell service call SurfaceFlinger 1039 i32 <uid> f <refresh rate>
Change-Id: I6ae1a98e6ca13e9d3d095a5713a6b0ca99652256
These frames are used for computing the legacy insets which won't be
used anymore. We should only maintain the new insets system now.
This CL also unhides Rect#inset APIs.
Bug: 149813814
Test: atest WindowFrameTests DisplayPolicyLayoutTests InsetsPolicyTest
SplashscreenTests ManifestLayoutTests WindowMetricsTests
WindowInsetsAnimationImeTests WindowInsetsControllerTests
WindowUntrustedTouchTest DisplayContentTests
Change-Id: I06e40be6342b2ae35f7cc3e6f4ebdbe68edf0499
This has been hardcoded as ALL_SAVE_FLAGS for a couple releases now.
Since it's now permanent behavior, remove the last bit of plumbing
for SaveFlags on saveLayer
Test: builds & boots
Change-Id: Iec92f27199d0b4781c2293dcdcfd45a1562a1b4e
It's necessary to run the following two tests if
android.graphic.drawable.Icon is modified.
* CtsGraphicsTestCases:android.graphics.drawable.cts.IconTest
* FrameworksCoreTests:android.graphics.drawable.IconTest
Test: atest -p framewroks/base/graphics/java/android/graphics/drawable
Test: cd framewroks/base/graphics/java/android/graphics/drawable; \
atest --enable-file-patterns --collect-tests-only
Bug: 172183870
Change-Id: Ic5bcaf3231ead515aeb2cba5b7f977dbbd41f5a9
