Update api name to getRecommendedTimeoutMillis.
Api returns timeout for interactive or non-interactive controls.
Also provide the options for a11y service to specify two kinds of
timeout.
Bug: 111210981
Test: atest SettingsBackupTest
Test: atest AccessibilityManagerTest
Test: atest AccessibilityServiceInfoTest
Change-Id: I37d35796fd72bb4d6628a6bb33b111987f321552
The existing documentation suggests that ACTION_UP events will contain a
valid repeat count that is equal to the repeat count of the latest
ACTION_DOWN event. However, in practice, that is not the case.
Rather than changing the behaviour to follow the existing documentation,
change documentation to conform to the existing behaviour. The rationale
here is that changing the behaviour might mean that some apps would
start relying on getRepeatCount() being non-zero. But this would only
work on the latest Android release. So if an app is tested only on the
latest Android release, and not on the release before this behaviour was
changed, the app would be broken on the older releases of Android.
Test: CTS tests will be added for injection
Bug: 113341746
Change-Id: Ia53e0e606c0b3c64135ef00950dc8a19f62933ca
Add the @InspectableChildren, @InspectableNodeName, and
@InspectableProperty annotations, and a host library containing them for
use in the annotation processor.
Bug: 118893821
Test: m
Change-Id: I11dcec09c2c69db951fc87d37463b6f8ca28d8fe
Create a new package, android.view.inspector, which contains the
InspectionHelper interface, and the associated interfaces
ChildTraverser, PropertyMapper, and PropertyReader.
Test: m
Bug: 118895011
Change-Id: Iaedf1c82ac302bbc467300065b8e1612baf57ad7
There seems to be an issue with referencing constructors for
inner classes, working around this until it is investigated.
Bug: 119190588
Test: make droid
Change-Id: I41f98fbe0f066358f3a8bf73052065c7feb7234a
* changes:
WindowInsets: Annotate nullability
WindowInsets: Add Builder
WindowInsets: reimplement WindowInsets on top of Insets
WindowInsets: make WindowInsets.inset() public
Move display update logic from WM into ATM hierarchy by letting
ActivityStack watch for relevant changes and calculate bounds
accordingly and removing configuration updates from WM side
outside of calls from the display-level controller (like how
the other levels work).
One of the main display-changes to account for is rotation. To
make this work without drastically modifying things was to leave
display freeze/startSeamless in WM but move the actual rotation
to ATM while handling SEND_NEW_CONFIGURATION. This prevents
changes to the wm-side hierarchy outside of ATMS's control.
To facilitate this extra communication between ATMS and WM,
this adds rotation into WindowConfiguration. This makes rotation
available to the hierarchy update for policies that care about it
(things like split). It will also replace TaskStack's mRotation
in an upcoming CL and should also let us remove the one-off
variable for landscape->seascape orientation changes (needs
some more research though).
Bug: 113900640
Test: go/wm-smoke + relevant am/wm servicestests
Change-Id: I12c79cc5eb94d48d846f1cf27765c9f9f6741435
Rather than use a local and global id, just use a local, unique id.
Such change not only simplifies the code, but makes it consistent with
TextClassificationSessionId.
Test: mmm -j packages/experimental/FillService && \
adb install -r ${OUT}/data/app/FillService/FillService.apk && \
adb shell settings put secure intel_service foo.bar.fill/.AiaiService
Bug: 111276913
Change-Id: I0e610f825aab1d2b32bbafa1bd3d3c7897d889d6
It's only implementing the activity lifecycle events, but at least they're fed
end-to-end in the pipeline (from app to service implementation).
Test: mmm -j packages/experimental/FillService && \
adb install -r ${OUT}/data/app/FillService/FillService.apk && \
adb shell settings put secure intel_service foo.bar.fill/.AiaiService
Bug: 111276913
Change-Id: I2f46be1e6a6a21ad909e5fffea01bedaa28fb300
It's still full of TODOs, but at leats it now provides an end-to-end
workflow from the activity creation / destruction to the service implementation.
Test: mmm -j packages/experimental/FillService && \
adb install -r ${OUT}/data/app/FillService/FillService.apk && \
adb shell settings put secure intel_service foo.bar.fill/.AiaiService
Bug: 111276913
Change-Id: Id5daf7b8b51e97c74d9b6ec00f953ddb02b48e46
IntelligenceService is a @SystemApi, and hence not available from non-system.
Test: echo "in TH we trust"
Bug: 111276913
Change-Id: I4c28de49334bdf100a26963e47df9630804730df
A.K.A: "The thing's hollow — it goes on forever — and — oh my God! —
it's full of TODOs!"
Bug: 117944706
Test: m update-api && m
Change-Id: I0774a0df4f4ea0810a8c5f72a1fbcd4eef5cd09b
Currently, listModelFiles and findBestModelFile methods only support annotator model.
But we want to extend them to support other models as well, like langID and actions.
Thus, introducing ModelFileManager, which provides listModelFiles and
findBestModelFile. ModelFileManager takes a Supplier<List<ModelFile>> to list model files.
For different types of model, we just need to provide a different supplier to the ModelFileManager.
There should be no behavior change.
Test: atest frameworks/base/core/tests/coretests/src/android/view/textclassifier/ModelFileManagerTest.java
Test: atest frameworks/base/core/tests/coretests/src/android/view/textclassifier/TextClassificationManagerTest.java
Change-Id: I4fc3fd1c9246383ee5d906792bb14b96dbf0a79f
- Add TouchDelegate#onHoverEvent
Bug: 35702820
Test: Install TestBack with flag FLAG_REQUEST_TOUCH_EXPLORATION_MODE
enabled. In Settings APP, enable TestBack then touch/hover into
most left side of SwitchBar in the same subactivity to confirm
Switch delegated and hover enter event exist
Test: manually test with sample app in issue #7. Touch button delegate
and hover move over text view to confirm text get a11y focused.
Change-Id: I0abea81ea2fee4d391e2ee448710c5f0180f7533
Include below refectoring items to support per display AppTransition:
WMS / AM refectoring parts:
- Move AppTransition related stuff from WMS into DisplayContent.
- Move WMS.prepareAppTransition into DisplayWindowController.
- Move WMS.executeAppTransition to DisplayWindowController.
- Move ATM.isNextTransitionForward to DisplayWindowController.
- Move WMS.getPendingAppTransition to DisplayWindowController.
- Move WMS.overrideAppTransition like APIs to DisplayWindowController.
- Move ActivityRecord.applyOptionsLocked to AppContainerController.
- Support tracing all display's AppTransition status for
DisplayContent.pendingLayoutChanges & window hierachy update.
- Modify logics for AppTransition related caller parts.
- Move WindowSurfacePlacer.handleAppTransitionReadyLocked related
stuffs into added class AppTransitionController.
WM unit test parts:
- Add test case for verifying app transition state per display:
- AppTransitionTests.testAppTransitionStateForMultiDisplay
- AppTransitionTests.testCleanAppTransitionWhenTaskStackReparent
- Rename WindowSurfacePlacerTest to AppTransitionControllerTest since
the test is related handle AppTransition flow.
Bug: 111362605
Test: go/wm-smoke
Test: atest ActivityManagerTransitionSelectionTests
Test: atest ActivityManagerMultiDisplayTests
Test: atest FrameworksServicesTests for DisplayContent / AppTransition
related tests.
Change-Id: Ic1793aa794eb161bec31fda57847a6ba2ff4f84f
This is a mechanical refactoring like we did to split
InputMethodClient for Bug 118040692.
So-called "controlFlags" in InputMethodManager (IMM) was originally
introduced for IMM#startInput()/windowGainedFocus() [1] to carry
additional client information then reused when we unify startInput()
and windowGainedFocus() into startInputOrWindowGainedFocus() [2].
This CL mechanically moves the location where those flags are defined,
from InputMethodManager.java to a newly created file
StartInputFlags.java.
This is still just a mechanical refacotring / renaming. There should
be no user-visible behavior change.
[1]: Icb58bef75ef4bf9979f3e2ba88cea20db2e2c3fb
7663d80f6b
[2]: I56934f18e30d90fcdf77bcbb0c35a92a5feb1b82
05c25f8a3a
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:com.android.internal.inputmethod.InputMethodDebugTest
Change-Id: If5a4810dece852edcff0d1119463711249bb7ef2
Also create a new MANAGE_ACCESSIBILITY permission to
perform the shortcut.
Bug: 116118615
Test: make, activate accessibility shortcut
Change-Id: Ic65a0cdf7393429e14cb98f4fb0734d20069b05a
This is another follow up CL to my previous CL [1] that enabled
per-display InputMethodManager (IMM) instance (Bug 115893206).
What we learned in Bug 118341760 is that for some apps
view.getContext() may return a ContextWrapper subclass whose
Context.getDisplayId() and Context.getSystemService() are not
consistent with each other. Although this is considered to be a bug
of such a ContextWrapper subclass, application developers may not be
aware of the issue when such a problematic ContextWrapper came from
libraries that app developers happened to, or had to, depend on.
The key idea of this CL is that
view.getViewRootImpl().getDisplayId()
would be a more robust source of display ID than
view.getContext().getDisplayId()
for most of cases, because to which ViewRootImpl a given View belongs
is already a strong signal about to which display the View belongs.
As far as I've tested locally, this approach seems to be more
promising and is expected to give us better app compatibility in
multi-display scenarios.
[1]: I78ad7cccb9586474c83f7e2f90c0bcabb221c47b
4052a10f29
Bug: 118252837
Fix: 118341760
Test: atest ActivityManagerMultiDisplayTests
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest
Change-Id: If47e48bc8176657bf4bb882146d2affdfe457c90
1. There used to be double offset from the origin.
This is because we used to (in NYC) make the surface position to display
origin and draw content with a offset in the surface. However we lately
let the surface position be inherited from task surface position, so
there will be an offset from surface position and an offset from drawing
content in that surface.
To fix the bug I removed the offset in drawing content. That offset is
provided by WindowState#getBackdropFrame() so it just solved the issue
by moving frame to the origin.
2. Window quickly jumps when user starts drag resizing a window.
The reason is out of synchronization between surface insets change and
graphical buffer update. When user is drag resizing, we suppress window
shadow to save some graphical resources, which will consequently change
surface insets. Change in surface insets will cause the surface being
repositioned to reflect the new surface insets because window frame
doesn't change. However the content is still drawn at old location with
old surface insets for the first a few frames, so the content jumps to a
wrong location for a split second. This also happens when users stop
drag resizing.
I kept the old surface insets when user is resizing so there won't be
surface reposition at the beginning and end of drag resizing, but still
suppress the shadow by adjusting the elevation of DecorView.
Also fixed a synchronization issue we found in BackdropFrameRenderer,
and cleaned up code in it.
Bug: 113254346
Test: Manual tests show drag resizing for both freeform and split screen
works.
Change-Id: I42349f88f14af35fac7c65e784462b5f2e1a71c7
This is a follow up CL to my previous CL [1] that enabled per-display
InputMethodManager (IMM) instance.
One thing I mistakenly assumed in my previous CL is that there is
always a process boundary between IMM#createRealInstance() and
IMMS#addClient(), which is not true when IMM is being instantiated in
the system server process. This means that IMMS may associate an IME
client to wrong PID/UID/DisplayID when certain conditions are met.
With this CL, IMM#createRealInstance() always clears calling identity
so chat IMMS#addClient() can work correctly even for local Binder call
scenarios.
[1]: I78ad7cccb9586474c83f7e2f90c0bcabb221c47b
4052a10f29
Bug: 115893206
Bug: 117594679
Fix: 118335706
Test: atest ActivityManagerMultiDisplayTests
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest
Test: Manually tested with manually simulating the problematic scenario
Change-Id: I318d32d8997b0acb4fb193fe46831bdc9a4dd083
