PerformanceHintManager.Session is in java, so add JNI and a HintSessionWrapper
class in HardwareRenderer. Then pass the two calls as two std::functions
into DrawFrameTask.
Note Session is created per HardwareRenderer, not global (per
RenderThread).
Session includes UI thread, render thread, and the thread pool.
Desired duration is from the intended start duration to the frame
deadline. Add an actual frame start time to compute
Add system properties:
debug.hwui.use_hint_manager to enable PerformanceHintManager
debug.hwui.target_cpu_time_percent to control percentage of frame time
to be used for target cpu duration.
Test: Manual test that there are no crashes and values make sense.
Bug: 158791282
Change-Id: I83f25433c10daa20033803fb7c4ae45eab34f1d3
This is the re re..re-merging of ag/12923546 (where most of that original
message is posted below). This includes various bug fixes.
Slow prefetch requests would block user interactive requests, creating
noticeable sluggishness and unresponsiveness in accessibility services,
especially on the web.
Let's make it so a user interactive requests stops prefetching.
We can't interrupt an API call, but we can stop in between API calls.
On the service side, we have to separate the prefetch callbacks from the
find callback. And we have to make it asynchronous. It does dispatch
intothe main thread, so the AccessibilityCache can remain single threaded.
When the calls are interrupted on the application side,
returnPendingFindAccessibilityNodeInfosInPrefetch checks the find
requests that are waiting in the queue, to see if they can be addressed
by the prefetch results. If they can be, we don't have to call into
potentially non-performant application code. We don't check requests
that have differing prefetch flags (FLAG_INCLUDE_NOT_IMPORTANT_VIEWS,
FLAG_REPORT_VIEW_IDS) that would result in different caches. We satisfy
at most one pending request.
We also make mPendingFindNodeByIdMessages thread-safe and ensure in
ActionReplacingCallback we don't return null results. Merged
ag/13246536, ag/13256330
Messages should be added to PrivateHandler and
mPendingFindNodeIdMessages at the same time to avoid a race condition
where we try removing a message from the handler before it's actually
enqueued. This was causing double recycling
We call into AccessibilityCache from the Binder thread, now that the
cache doesn’t call out to the app main thread with a lock(ag/14020225)
Added tests to verify AccessibilityInteractionController interactions
Test: atest AccessibilityInteractionControllerNodeRequestsTest
atest CtsAccessibilityServiceTestCases CtsAccessibilityTestCases
CtsUiAutomationTestCases
FrameworksServicesTests:com.android.server.accessibility
FrameworksCoreTests:com.android.internal.accessibility
FrameworksCoreTests:android.view.accessibility
Bug: b/184076735
Change-Id: Iaad1b9100655ec86a788ba1c89edd2dd8a7df1f6
Besides UI contexts, the context created via
Context#createConfigurationContext with a proper configuration
should be allowed to inflate views or obtain ViewConfiguration.
An example is that a wear device inflate views into bitmap and pass
the bitmap to the Wear OS Companion app on the phone.
Bug: 177847640
Test: atest StrictModeTest
Change-Id: Iab232a80a973f54bf0484262d45af3e4c2f0e5dc
The arrays would be cleared while next time we use them, so they could
constantly occupy the memory.
This CL clears the temp arrays right after we use them. So they won't
occupy the memory while they are not being used.
Fix: 183684434
Test: Use Android Memory Profiler to check if there is
InsetsAnimationControlImpl or WindowInsetsAnimation instances
after GCing after playing insets animation in Launcher.
Change-Id: Iaae1e11d1c0cc1a9ac345beb3d7e8b596ea1b4ba
Update RenderNodeDrawable to hole punch areas into
layers created for SurfaceView
Bug: 184297961
Test: Added CTS test to SurfaceViewTests
Change-Id: I1f03a4fe34c5a8b7411ebe728ea3d4195fcd1fac
To switch magnification mode, a user has to click the magnifcation
button UI. However magnification button UI is visible only when
there is an user touch interaction or the magnification shortcut
triggered event.
However some a11y services like switch-access or voice-access
can only interact with magnification UI by performing
accessibility actions. To make magnification button showing and
able to interact with a user, we also trigger updating
magnification button UI when an accessibility action is performed.
Bug: 179442890
Test: atest WindowMagnificationControllerTest;
atest WindowMagnificationTest;atest MagnificationControllerTest;atest WindowMagnificationManagerTest
Change-Id: I8d762096c9cb6a4421d024a7a1af99b3a48a3462
With Frame Rate Override enabled, an app could get an onDisplayChanged
events which seems redundant. An example would be:
1. Display changed refresh rate to 60Hz - onDisplayChanged was called
2. App's frame rate override changed to 60Hz - onDisplayChanged was called
To avoid sending these redundant events, DisplayManagerGlobal caches
the last DisplayInfo that was reported to the app and based on it it
decides whether to send the event or not.
Bug: 184588343
Test: atest SetFrameRateTest
Test: atest FrameRateOverrideHostTest
Change-Id: I97c7b2b9a799424998b1b717a4311d3d08b3178f
Test: Install a test app that can reproduce the null pointer
exception. Flash and install a build with this CL. Null
pointer exception can no longer be observed.
Bug: 183386115
Change-Id: Iab155dfca20e0119cc401d111ace23e416e93b93
Otherwise, it will make the ViewRootImpl pause forever. Because there
won't be any frame-drawing callback where we clear the flag.
Fix: 182797514
Test: steps in the bug
Change-Id: Iadd35f1b112626399c064a1cd7d7da323bb9e36c
- Prints the window title instead of dumping the whole window in
InsetsSourceProvider.
- Stops printing mFakeControl, because it is the same in each
InsetsSourceProvider.
- Removes redundant blanks after '='.
- Refines indentation.
- Prints requested visibility while dumping WindowState instead of
printing the raw mRequestedInsetsState.
Fix: 184237588
Test: check the output of "dumpsys window -a"
Change-Id: I3e0ac2335c29b7f2449b890b4070c62d77ff7f7f
In an effort to reduce unnecessary String operations and Binder calls
from AccessibilityInteractionClient, also add channels to propagate
tracing state to AccessibilityInteractionClient through
AccessibilityManager.
Bug: 157601519
Test: adb shell cmd accessibility start-trace
adb shell cmd accessibility stop-trace
Change-Id: Idfe220bc64a9c83679201b9a9a36b1c492f9d6cc
Previously, it was possible to receive a FrameMetrics callback after the view was already detached from window. In that situation, the mInputEventReceiver is set to null and the object is disposed.
But InputMetricsListener used to store another reference to mInputEventReceiver. So it's own object was never set to null. We would then try to send the timeline to native input receiver, and crash because the native object has already be deleted by the earlier dispose() call.
So the sequence of events was:
dispatchDetachedFromWindow
mInputEventReceiver.dispose()
native input receiver is deleted
InputMetricsListener::onFrameMetricsAvailable
mInputEventReceiver.reportTimeline
try to access a native object using a null pointer
crash
A few options to fix this were investigated:
1) Unregister the observer when mAttachInfo.mThreadedRenderer is set to null.
This is good to do, but it's not sufficient. The problem is that the native call to RenderProxy 'removeObserver' is not serviced immediately, but is posted to be completed sometime in the future. Therefore, the crash would not be fixed by it.
Still, we should always register the observer for the active threadedRenderer, which is done in this CL.
2) Keep a weak reference to mInputEventReceiver inside InputMetricsListener. This would allow InputMetricsListener to check on the status of mInputEventReceiver. When it's disposed, it would be also set to null, so the weak reference resolution would fail.
Unfortunately, 'mInputEventReceiver' is not the only reference to the object of WindowInputEventReceiver. It turns out that the receiver is also stored inside the queued events (see class QueuedInputEvent { private InputEventReceiver mReceiver }). From reviewing ag/153113, it should be OK to remove the receiver from QueuedInputEvent and simply keep track of whether the event is synthesized or not.
But, that change would be too significant to make in this CL. Also, weak references have performance impact, so this may not be desirable anyways.
3) Do not store mInputEventReceiver in InputMetricsListener
The chosen option is to simply use the variable mInputEventReceiver from the outer class. If the receiver is null, we don't notify about the metrics.
This reverts commit d187cc7627.
Reason for revert: fixing this properly instead
Bug: 184255546
Bug: 169866723
Test: settings -> privacy -> permission manager -> body sensors -> show system (only click once) -> google play services -> deny -> deny anyway
Repeat the above 20 times. Observe that there's no crash of the activity.
Change-Id: I5cf36ef068f7964572ab1a1475ff8ac53ae6beb5
While we are working on a proper fix for the issue, let's turn off
timeline reporting to avoid hitting this path.
Bug: 184255546
Test: manual
Change-Id: Ie8b6c6222a0a8d7b8d3fd96f25d5f59b96de2255
Add the IntRange and IntDef annotations on the getInitialText{Before,After}Cursor API.
BUG: 184017538
Test: atest FrameworksCoreTests:EditorInfoTest
Test: atest CtsInputMethodTestCases:EditorInfoTest
Change-Id: Ifebeeac6863600363ebcf6c73263874604ea3428
This issue caused by the input location length is too large to make
the OOM crash when constructing the rectangle array.
Due to the constructed rectangle array needs to send back to services
through the binder transaction, so limiting the text location length
to avoid the binder transaction failure or the OOM crash.
Bug: 159355942
Test: a11y CTS & unit tests
Change-Id: I3b48b8999967347475b830d94d641b45259152ae
The server might return a control without a leash to a client while the
setup-transaction of the leash has not been applied yet. If the client
tries to play the animation with the control, the animation won't take
effect.
This CL sets mIsAnimationPending while changing the requested visibility
while the leash of the real control (not the fake one in transient mode)
is not ready. So when the client receives the leash later, the animation
will be played.
Fix: 183362710
Test: steps in the bug
Change-Id: I53108bacf98ac76c3f1e46cdae0a98581bef77f5
- Allows launcher to get the associated launch cookies for
the task
Bug: 129067201
Test: Manual, check the task info for the animation targets
Change-Id: I4b9d974af1732d0ec7b19681f4772b692f614e5e
