expose ISurfaceComposer::getAllowedDisplayConfigs to SurfaceControl.
Test: manual test to call getAllowedDisplayConfigs() from SurfaceControl
observe config change.
Bug: 122905403
Change-Id: I0587ac5ed2eb29788c2ce941d9c54ebfd215ddf9
1. Pull out TextClassifierImpl.LabeledIntent to LabeledIntent.
2. LabeledIntent.resolves takes a TitleChooser object, which
allow custom logic like "if the resolved app is a browser, use
title_with_entity. Otherwise, use title_without_entity".
If TitleChooser is not set, the default behavior is to use
title_with_entity if provided, use title_without_entity otherwise.
3. For classifyText, we use a TitleChooser that always return
title_without_entity. So no behavior change in classifyText.
4. If custom titleChooser returns null, fallback to use the default
titleChooser.
BUG: 124428508
BUG: 123946471
Test: atest framework/base/core/tests/coretests/src/android/view/textclassifier/
Change-Id: I7299c40ffc57deb9484d493f8c62b220a5a1e7d8
* changes:
Changed Content Catpure workflow so it notifies when multiple changes are made.
Improved how Content Capture events are flushed when activity is resumed / paused.
Add a doc link to MotionEvent#CLASSIFICATION_AMBIGUOUS_GESTURE, to make
it easier for readers to cross-reference documentation.
Bug: 125800452
Test: m doc-comment-check-docs
Change-Id: Ic7a5a14d30c0cc3aa57f8bcd6af34e2e684f0437
Test: atest CtsContentCaptureServiceTestCases # which was updated to listen to the new events
Test: m update-api
Fixes: 125395044
Change-Id: Ie1ed5d9badaa64ff0921226a1c08bd5e3cbf07d8
Add a new event for display configuration change. This event
will be sent by SF anytime it changes the display config.
Test: Generate DISPLAY_EVENT_CONFIG_CHANGED and observe the log
Bug: 122905403
Change-Id: Ifa473a34d7b313501e5e4e8a67186fb82754fdcd
expose ISurfaceComposer::setAllowedDisplayConfigs to SurfaceControl.
This API is expected to be called by DisplayManager depends on the
current policy in place. Once setAllowedDisplayConfigs is called,
SF can only set a new display config if it is part of the allowed
configurations list.
Test: call setAllowedDisplayConfigs() from SurfaceControl and
observe config change.
Bug: 122905403
Change-Id: I7f8cc09dbec352701f5dcf2595bee66b8380bc00
In pre-P versions of Android, it was allowed to screenshot secure layers if the
buffer queue producer which was the target of the screenshot was owned by
the system (in this case SurfaceFlinger). This really was a synonym for:
The screen rotation animation was allowed to capture secure layers, but the other
code paths weren't. In O we mistakenly changed this check to always allow the system server
to capture secure layers via the captureScreen path (the captureLayers path used for
TaskSnapshots was unaffected). This can result in data leakage in cases where the
system server takes screenshots on behalf of other parts of the system (e.g. for
the assistant). To mitigate this we provide an explicit switch for the system server
to specify whether it wishes to capture Secure layers. While this is dangerous, I think
it is less dangerous than the previous implicit switch of capturing secure layers based on which
type of BufferQueue was passed in. The flag defaults to not capturing secure layers
and we set it to true in the one place we need it (for the screen rotation animation).
Non privileged clients can still not capture secure layers at all directly.
Test: TransactionTest.cpp#SetFlagsSecureEUidSystem
Bug: 120610669
Change-Id: I9d32c5ac2b005059be9f464859a415167d9ddbd4
Prior to this change, it sent a pair TYPE_INITIAL_VIEW_TREE_APPEARING and
TYPE_INITIAL_VIEW_TREE_APPEARED after the initial layout, then it would send invididual events for
the views appeared / disappeared.
This change improves the workflow by also sending this pair of events after each change, which lets
the service know that a bunch of changes were made at the same layout pass.
Test: atest CtsContentCaptureServiceTestCases # which was updated to listen to the new events
Test: m update-api
Bug: 125395044
Change-Id: Ied9def9c95dd0f7711f59bccb2cc89a766fdc36b
We were flushing right after the activity resumed, but the relevant events (views added / removed)
were not generated yet, which made such flushes useless.
This CL changes the workflow to flush them after the ViewRoot finishes doing its work.
Test: atest CtsContentCaptureServiceTestCases
Bug: 125395044
Bug: 122315042
Change-Id: I05bf27069b00c285643b2d23ad6708a6ad7bc8f3
This fix introduced a painful crash that ends up disabling accessibility
services for certain users.
This happens when a client of AccessibilityCache tries to add a node, with the same id as a node previously in the cache, but fewer children, where the removed child is not in the cache.
This is because, when children are removed, and a the node is updated, the cache tries to clear the child trees. But if the child is not in the cache, the cache clears the whole tree. Every node is recycled.
Then the original node being replaced is attempted to be recycled again, and voila crash.
The fix also didn't fix the original issue based on the discussion in
b/114133438.
The risk for this is pretty low, since nothing was built on top of this.
This reverts commit 2f69c16c3d.
Bug: 124676705
Test: Tested to see if above usecase still happens.
Change-Id: I8a39698c4532a1613ba47e1c6ca70201cd496212
Currently, IWindowSession#performHapticFeedback() would first lookup
the WindowState via IWindow token. That would also hold the WMS lock,
so if some function like relayout window is still hold WMS lock,
it may block the function.
Use uid and package name from Session that they already restored.
Bug: 62330939
Test: Open app with autofill edit, type with IME.
Change-Id: I359c106d213b87aa8afee48b0f1ad70011970eab
Added a new test method to allow the client to wait until input windows
have been propagated to InputFlinger before proceeding to inject input.
This ensures that the inject is called when all windows have been set
up.
Bug: 123041491
Test: ListPopupWindowTest, PopupMenuTest
Change-Id: I42abfa4ea23a14ae1a003c6ee8976cc466f1d5af
Prior to this CL we were just caching whether the service supported compatibility mode for the app,
but now we're also caching the logging level and whether the app is whitelisted for augmented
autofill - although right now the augmented autofill info is not used, it will allow us to trigger
it in the scenarios where autofill is disabled for the app.
Bug: 123099842
Bug: 123100824
Test: atest CtsAutoFillServiceTestCases:AugmentedLoginActivityTest \
CtsAutoFillServiceTestCases:VirtualContainerActivityCompatModeTest
atest CtsAutoFillServiceTestCases # sanity check, although still flaky
Change-Id: Iaf8ea6634ca94e5e61131890ec17c96c2fbb329a
