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
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
Adding new APIs in display manager to get the user disabled formats, to get the formats
supported by device and get formats reported by display.
Bug: 172905874
Test: N/A
Change-Id: I58a7714f03a3e165bbd22f2fa7a021ad90b41b39
Merged-In: I58a7714f03a3e165bbd22f2fa7a021ad90b41b39
(cherry picked from commit 25f1822005)
This change doesn't contain the virtual view part and the API, it
will be done in the next change.
Bug: 178046780
Test: manual
Test: atest CtsTranslationTestCases
CTS-Coverage-Bug: 177960696
Change-Id: Idba66a882a90168ecdd93423c0d5d054ab040dad
For content insertion from the IME, the platform currently assumes
that it can automatically revoke URI permissions (via
InputContentUriTokenHandler.finalize) any time after the
InputContentInfo instance is garbage collected and
InputContentInfo.releasePermission() has not been called explicitly.
This can cause permissions to be revoked before the receiving code
has had a chance to read the content when using
OnReceiveContentListener, since we did not keep a reference to
InputContentInfo.
This change does the following:
* Sets the InputContentInfo instance in the ContentInfo payload passed
to OnReceiveContentListener.
* Exposes a hidden API on ContentInfo to allow system features to
proactively release permissions for sources that allow this (IME and
drag-and-drop).
* Updates notifications direct-reply code to proactively release
permissions as soon as they are no longer needed.
Bug: 183643556
Test: Manual
Change-Id: I1cbc55d53804810a3cd4b6b97c197f4dd2d7d8e6
Added new APIs to DisplayManager to set the user disabled HDR formats,
and get/set if user disabled formats should be ignored or not.
These new settings are stored in Settings.Global.
Modified the implementation of Display#getHdrCapabilities to not return
the formats disabled by user.
Bug: 172905874
Test: atest CtsDisplayTestCases
Change-Id: I4841af251ee0e4938614b154d0c5239814ea7cd9
Merged-In: I4841af251ee0e4938614b154d0c5239814ea7cd9
Bug: 183190634
Test: 1. make doc-comment-check-docs
2. unzip doc-comment-check-docs-docs.zip in
$ANDROID_BUILD_TOP/out/target/common/docs
3. open RoundedCorner.html in reference/android/view/
Change-Id: Iff8d10db2fd3aaa26035e75c6acb342e5dc07a10
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
Renamed "componentName" to "clientActivity" and "uid" to "clientUid" to
avoid ambiguity.
Bug: 178978545
Test: Presubmit
Change-Id: I66246168bd71f577b9494e91b3a5df086c491cb1
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
