This change doesn't contain the virtual view part and the API
dispatchTranslationRequests, it will be done in another change.
Bug: 178046780
Test: manual
Test: atest CtsTranslationTestCases
CTS-Coverage-Bug: 177960696
Change-Id: I65fe1db19c9dff21c0caca425fbb7d08559e730b
* This is only applicable when two consecutive CC events are
both TYPE_VIEW_TEXT_CHANGED event for the same view
* Before this change: we would merge if both events have
non-empty text. However, if the user types fast, CC will
not send the updates for individual word. Moreover, if the
user adds a word and then delete it fast, CC may not capture
the word since it'd be merged away.
* After this change, we change the criteria to consider whether
the current text has a ComposingSpan if it's a Spannable.
The logic is described in the code comment.
Bug: 181906241
Test: atest CtsContentCaptureServiceTestCases
Change-Id: I08d447f557f7e48ef34c5a6241c497db3ce4c5fc
getRawX/Y are implementation specific and are always display
relative. If any apps are using this, they should stop unless
the app is specifically trying to handle raw events.
Usage of getRaw will break under: multi-window, size-compat,
letterbox, display-areas, and independent window rotation.
Bug: 179274888
Test: adb shell dumpsys platform_compat
Change-Id: I2d87d0a62d7a28e15811dda7f9d16996e8159f69
WindowInsets#getInsetsIgnoringVisibility was wrongly written as
WindowInsets#getInsetsIgnoreVisibility
fixes: 183372217
Test: build & run
Change-Id: Ied3c73fe6bd51993b0ac8fe3befe919daedb35ad
In this way, we can clarify the owners and it is easier to maintain.
Also refactor to move WindowContext creation logic to ContextImpl.
Test: atest WindowContext WindowContextTests WindowContextPolicyTests
Bug: 159767464
Bug: 152193787
Change-Id: I78432aa18aa97e001f5a9a04321109e456fd137b
When the frame size and the frame position of the window are changed at
the same time, setPosition to the surface will be applied first, and
the client will draw on the new-size buffer later, which makes the
window flicker.
This CL uses applyWithNextDraw to make the new surface position can be
applied while the new frame is drawn. applyWithNextDraw is applied only
when
- the window doesn't have a move animation. So if a window needs to make
resizing stable, it may need PRIVATE_FLAG_NO_MOVE_ANIMATION.
- it is visible, e.g., the surface is shown, and the window is OK to
display -- for better performance.
If applyWithNextDraw is used while the window frame is changed to an
empty rectangle, e.g., Rect(10, 10 - 1000, 10), mNextDrawUseBlastSync
will stay true forever, because we don't draw while the dirty area is
empty, and ViewRootImpl would lose the only chance to clear the flag.
performTraversals will never be executed.
This CL makes mNextDrawUseBlastSync can be cleared in that case.
Bug: 182729646
Fix: 176874720
Test: steps in the bug
Change-Id: I81b0574ee8db7e4d9053639f56e04858d9feae90
We may still have useBLAST=false when we are detached from
the ViewRoot, the recent CL to remove defer transaction
code mistakenly removed this code.
Bug: 183427823
Test: Existing tests pass
Change-Id: I7ef68ca9da053fd9b488a6da6101572ec05ab9a3
Caller may need to keep the SurfacePackage alive after attaching it
to a SurfaceView. We allow this by creating a copy of the
SurfaceControl inside the SurfacePackage. Since the native layer
handle is ref counted, this will keep the encapsulated Surface hierarchy
alive after it has been released by SurfaceView.
Bug: 182838860
Test: atest SurfaceControlViewHostTests
Change-Id: I49e228b561d7aca23691d683747edc5365fc4206
This is a relatively safe code clean up as a follow up of our recent
CL [1], which introduced InputMethodSessionWrapper for better
readability and maintainability.
Before that CL, it wasn't obvious that our try/catch block in
InputMethodMnager#startInputInner()
was actually taking care of not only RemoteException from
IInputMethodSession#displayCompletions()
but also from RemoteException from
IInputMethodManager#startInputOrWindowGainedFocus()
Now that the former is taken care inside InputMethodSessionWrapper,
this CL tries to further simplify and clean up it.
One potential behavior change is that with this CL the calling app
starts crashing when Binder driver throws RemoteException while
calling one-way Binder IPC
IInputMethodManager#startInputOrWindowGainedFocus()
Note that Completable.getResult(value) has already been rethrowing an
Exception when InputMethodManagerService explicitly throws an
exception since we rewrote the logic with our hand-written Completable
[2], which is indeed more likely to happpen. Thus hopefully having
the same behavior for errors from Binder driver would be acceptable
and make it easier for us to detect something unexpected is happening.
Other than that, there should be no observable behavior change.
[1]: Ifb4f86098011fe74cf4159446106d6c15c30fa30
17827d754a
[2]: If4b40244a2e0e3b11c38c1da9340ba8e5166ad64
b9590fa1e1
Bug: 167948374
Test: atest CtsInputMethodTestCases
Test: atest CtsInputMethodTestCases --instant
Change-Id: I2cc879ba4a02cc9cf0f97c8380fe33c358e3d120
Keep the implementation and Add @Deprecated and @remove for the
deprecated APIs. Use this way can make sure the client doesn't
crash if not updated but when app recompiles would be forced to move
to the new APIs.
Bug: 177789967
Test: Use the app that uses old APIs doesn't crash. When app would
like to recompile cannot see the old APIs.
Change-Id: I700470eaca2df030e50de964be5be2173c89259f
* changes:
Add trace for tracking the performance of new starting window
Force enable hardware accelerated for starting window
Pre-draw AdaptiveIconDrawable and cache it before doFrame
* TranslationContext holds source/dest specs, replacing spec pairs in
methods.
* TranslationCapability holds information on the translation models, as well
as a helper method to generate a TranslationContext for creating
translators.
* TCapability is meant to hold information about the translation models, and
provide information/flag on what the translator can support, versus the
TContext which will indicate exactly which supported flags should be
used and activated by the models.
* Added TM.getTranslationCapabilities, and add/remove TCapabilityUpdateListener
Bug: 176208267
Test: atest CtsTranslationTestCases
Change-Id: I2ab7a3eadcbbc9e13f8f33bf9c51cda69f30fdb7
* Remove all media-specific color extraction and colorization logic
* Remove all 'large icon' gradienting logic
* Simplify base (headerless) style to use a LinearLayout instead of tweaking margins
* Make compact media layout a tweak of the base (headerless) layout
* Make big_media layout a tweak of the big_base layout
* Fix an unnecessary swooping animation that happened on expand
* Ensure RTL layout also works
Fixes: 172652345
Test: manual testing w/ updated notify2
Change-Id: I11c1494c0ac32aaf3e9d2010560cc8f1d8c50037
InputEventAssigner does not currently get notified about all frames. In
the existing logic, only the cases for batched consumption would be
counted as 'choreographer callback'. This misses several cases, such as:
1) CALLBACK_INPUT was never scheduled, but a frame is produced
2) CALLBACK_INPUT was scheduled, but no events were consumed
However, it is critical that InputEventAssigner knows about all frames,
because it needs to reset the 'down' state for proper frame attribution.
At the same time, we refactor the logic in InputEventAssigner. In the
updated logic, we will specifically store the event id with ACTION_DOWN
only. In all other cases, we will use the current / latest input event.
In this CL, we reset the 'down' state after the input event id is
used for the current frame. A good proxy for that is the
ThreadedRenderer::draw call, which in turns
calls attachInfo.mViewRootImpl.getUpdatedFrameInfo().
Also, rename "onChoreographerCallback" since it's not exactly clear
which callback this is referring to. In the new logic, this callback
will happen from 'draw'/'onDraw' functions.
Bug: 167947340
Test: add LOG_ALWAYS_FATAL crashes in LatencyTracker for duplicate
'reportTimeline' calls. The crashes are gone after this CL.
Change-Id: I5fad6665d10e0594963209b138e9bd2bdf00ca38
Currently the hardware acclerated was disabled for starting window, we
will need to enable it to fix the reveal animation janky.
With software rendering, each frame would cost 20~30ms on redfin.
Test: atest KeyguardTests KeyguardLockedTests SplashscreenTests
Bug: 182708883
Bug: 173975965
Change-Id: I4df6891e0b24231b7fd3a1d2d630ca2b9eead79f
The CL applies fade-in/fade-out animations for BEHAVIOR_DEFAULT while
changing the system bar visibility.
Fix: 168913586
Test: WindowInsetsTests
Change-Id: I6e9887baf2ba40b51c01bf2239915d381ba891a6
Translator#translate() is also updated to be asynchronous with callback
instead.
Bug: 178651352
Test: atest CtsTranslationTestCases
CTS-Coverage-Bug: 178651352
Change-Id: Ibe1f97994fe6ee593a3a3bbb452c075b49a7eb5a
To simplify InputMethodManager code logic, have a wrapper
class which encapsulates IPCs from InputMethodManager to
InputMethodService.
Bug: 167948374
Test: atest CtsInputMethodTestCases
Change-Id: Ifb4f86098011fe74cf4159446106d6c15c30fa30
OnReceiveContentListener was already integrated with drag-and-drop
in TextView. The change extends support to all subclasses of View.
If an OnReceiveContentListener is set on the view, the default
implementation of View.onDragEvent will now return true for an
ACTION_DRAG_STARTED event and will call
View.performReceiveContent for an ACTION_DROP event.
Bug: 182617122
Test: atest CtsWindowManagerDeviceTestCases:CrossAppDragAndDropTests
Test: atest CtsViewTestCases:ViewOnReceiveContentTest
Test: atest CtsWidgetTestCases:TextViewOnReceiveContentTest
Test: Manually using ReceiveContentDemo
Change-Id: I98fb703220ebd1953b20dcab60d22847cc5000d8
TextServicesManager#getEnabledSpellCheckerInfos() was introduced in
commit 4c7423735e
as #getEnabledSpellCheckersList().
Then, the following commit added SuppressLint("NullableCollections"):
commit d7f33cd648
As this API has been introduced recently in Android S timeframe, I think
it's better to fix the API behavior before it's finalized.
Bug: 180625329
Test: m checkapi
Change-Id: I33d3c86a0c19c0082299e383e50d3860b072e79d
