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
StatusBarIconView uses Icon#loadDrawableAsUser to load drawable defined
by the customized Drawable class. context.createContextAsUser with flag
Context.CONTEXT_INCLUDE_CODE can fix the ClassNotFound found problem.
And, it needs to prevent any security issue by checking if the context
is the same app with the process.
If the parameter userId is the same with context.getUserId(), it
shouldn't create the extra Context instance.
Fixes: 171712189
Test: atest \
CtsGraphicsTestCases:android.graphics.drawable.cts.IconTest \
FrameworksCoreTests:android.graphics.drawable.IconTest
Change-Id: I267fc6eed90a6a6bba39b9976c1d843734e49dec
This is the second try of
commit c7a5b3a90d, which was reverted in
commit 735d447d48
Changes:
- Use reflection to update static final fields, because some apps and
tests rely on Typeface.create() to return references to static final
fields (which is a behavior resulted from the use of internal cache).
- Make setSystemFontMap() thread safe.
- Hold a reference to ByteBuffer so that the memory won't be unmapped.
Bug: 172891184
Test: atest FrameworksCoreTests:TypefaceTest
Test: atest CtsWidgetTestCases:android.widget.cts.TextViewPrecomputedTextTest
Change-Id: I1dea26c08a8585ea10e866c063bef6d682d8b15e
This reverts commit c7a5b3a90d.
Reason for revert: DroidMonitor: Potential culprit for Bug 173096532 - verifying through Forrest before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Change-Id: If71083df98155ae9e7f55ed1ca49b15456d12a82
Bug: 152322291
Bug: 172934376
Test: make
The UI Rendering mainline module is on hold for now, so this does not
need to be @SystemApi. The system can still access it through @hide.
This leaves in place the new Compatibility class (added in
Ie7172fb93364a1e04ab844b8fa64887bf9d8b005), which seems just as good as
the old approach, and we can switch it back to @SystemApi if/when we
restart the module.
Change-Id: I3f6c32603c4eace55ece04936bff6f9336cf6627
