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
- 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
Handle onConfigurationChanged() in order to prevent restarting
InputMethodService everytime. We introduce a new API attribute
"configChanges" in InputMethod(attrs.xml) which when declared
by IME, will be responsible for handling mentioned
configuration changes.
This CL re-introduces [1] with fix: Use new Configuration instance for
IMS#mLastKnownConfig and also handle followup comments.
[1] Ib94fddadb0dae648cf73a4c1642e51edebd19f50
Note: this change has no impact for devices not using DisplayAreas.
Bug: 167948419
Test: atest InputMethodServiceTest
Manually:
1. Patch Ie91e7a8e06b80864ef9409031e8543858552d70d to use dual
display area.
2. Open applications with editors on both display areas.
3. Attach a debug point for IMS#onConfigurationChanged().
4. Make sure IMS#resetStateForNewConfiguration() is not called
when IME moves between these two identical DisplayAreas
Also verify that bug 182604598 don't happen.
Change-Id: I43b6b80cdb35410554412ee1d3b0917ee3198272
1. We provide virtual child list to View#onCreateTranslationRequests
but we don't provide a method to allow developers to create
ViewTranslationRequest for virtual AutofillId. Add a builder
constructor to allow developer to use it for virtual AutofillId.
2. Fix some comments in ag/13982294(e1b23cd)
Bug: 177789967
Test: manual on sample app
Test: atest CtsTranslationTestCases
Change-Id: I63e914b888b23cdb7a5169fc6931be93625ca8e4
An app that provided an IME and is deprecating that functionality may
want to still keep it's IME around temporarily, to prevent breaking
clients that hardcode the component name when switching to the IME.
Such an IME may want to not be presented as an option in the Input
Method picker. They can now set showInInputMethodPicker=false for
this.
Fix: 175480153
Test: manual - Test IME with showInInputMethodPicker=false isn't
shown in the IME picker.
Test: [new tests]
atest android.view.inputmethod.cts.InputMethodManagerTest
Test: atest CtsInputMethodTestCases
Change-Id: I18dda0525168f9195606840239507b9daba65be7
Currently, we only report the ui translation state if the Activity is
resumed. But in the real use case, the developer may call
finishTranslation when the Activity moves to background or lock screen
is shown. We should allow the finish/pause state can be updated for
these cases.
Bug: 183980346
Test: manual. Use sample app, press home and call APIs.
Test: atest CtsTranslationTestCases
Change-Id: I4a5cfab9d272e4d5dc23b2f679b4fbeb4a6c9d20
This API is appropriately called "ViewRoot". So far we just expose
an API surface to reparent SurfaceControl to the ViewRoot (but without
exposing the ViewRoot's SurfaceControl, to encourage developers not
to shoot themselves in the foot) and to synchronize with the drawing
of the ViewRoot SurfaceControl.
Bug: 173463039
Test: ViewRootSyncTests
Change-Id: I8ce0ed4b3efe50cdb3b71ae0f05ce25438d42368
The effect is a small ramp, a 50ms gap, and a sharp tick,
evoking the crisp snap of a sail, or a molecule's bonds
approaching and then snapping together.
It might be nice to start this effect slightly early, but
that will require more tweaking to the keypress messaging
and timers. We'll see if it's necessary.
For devices without haptic composer support, fall back to
EFFECT_DOUBLE_CLICK.
Bug: 182381083
Test: manual (literally, you have to hold the device):
adb shell settings put global power_button_long_press 5
adb shell input keyevent --longpress POWER
(or just hold the power button, since you're holding
the device)
Change-Id: I0633efd46296ca3f34e5df60be37871fb1a9fb5d
Calling generateDisplayHash can cause the system to slow down if there
are too many requests. Add throttling logic to prevent apps from calling
the API too frequently. The throttling time is based on a value sent
from ExtServices so it can be adjusted later
Test: DisplayHashManagerTest
Bug: 155825630
Change-Id: Id49d1c4113fc65d7b73a1e7b9fc73f50a8d7041f
The cache calls out with its lock to the app main thread when refreshing
nodes. This opens the door for a deadlock, and causes a slowdown for
non-main threads.
Bug: 180957109
Test: atest CtsAccessibilityServiceTestCases CtsAccessibilityTestCases
CtsUiAutomationTestCases
FrameworksServicesTests:com.android.server.accessibility
FrameworksCoreTests:com.android.internal.accessibility
FrameworksCoreTests:android.view.accessibility
Change-Id: I27e4e64f778ae1c2a348e16cf8739f7a5596e0fc
Makes the API easier to evolve in case we add user-selectable
TranslationServices later, like we do for RecognitionService.
Also makes the create.. name consistent with
SpeechRecognizer#createOnDeviceSpeechRecognizer().
Bug: 176208267
Test: atest CtsTranslationTestCases
Change-Id: I1a66bd045202025b9c5f669018c989654bcaa1ad
