InspectionHelper has been renamed to InspectionCompanion for clarity
about its lifecycle. The APIs needed to be accessed from the context of
an inspection agent injected by the profiler have been made public.
With a tightend focus on platfrom views and XML resource IDs, the
@InspectableProperty annotation now has affordances for specifying an
attribute resource ID and for defining @IntDef flag and enum mappings.
@InspectableChildren has been removed, as this will be special cased in
the injected inspector. Additionally, support for attribute ID is now
provided in all PropertyMapper methods.
Additionally, PropertyMapper and PropertyReader now have support for
Gravity ints, @ColorInt, @ColorLong, and Color objects.
Test: mmma frameworks/base
Bug: 120224687
Change-Id: If455e2d1d9693eac39c33fc35f892baf75671ba4
AbstractRemoteService was spun off from RemoteFillService, which only supports
1 pending request while not bound to the service - if a new request comes,
it cancels the previous one.
This behavior is fine for Autofill, but for Content Capture all requests must be
queued. In fact, the upcoming CTS tests for Content Capture were failing because
the 1st PendingOnContentCaptureEventsRequest would cancel the pending
PendingSessionLifecycleRequest.
So, this CL fix this problem by creating 2 subclasses:
- AbstractSinglePendingRequestRemoteService
- AbstractMultiplePendingRequestsRemoteService
Test: atest CtsContentCaptureServiceTestCases CtsAutoFillServiceTestCases
Bug: 111276913
Bug: 117779333
Change-Id: I43bb98be16f5def037f85a415e1f77799adf156e
This name is too generic, so we split it in 2 parts:
- ContentCaptureManager: the public API used by views and apps to report their
structure.
- SmartSuggestionsServiec: the system service use to consume these events and
provide autofill suggestions.
This CL also:
- Optimizes ContentCaptureManager allocation so they are not created on contexts that are not
capturing events (such as views from the system server).
- Uses a generic ContentCaptureEventsRequest (rather than a list of events) to make it easier
to be extended.
- Fixed IntelligencePerUserService so it clears the sessions when the
implementation changes.
Test: manual verification
Bug: 119776618
Bug: 117944706
Bug: 119638877
Change-Id: I069bcd23dda94afe18b2781fd3981b8b555afa56
Implements basic API's to control windows generating insets in
the new insets world.
Test: CTS tests will be added at some point in the future
Bug: 118118435
Change-Id: I722d2e58c68734ac131b12da3d9978e946292130
It will allow to call this methods in AndroidX Transition without reflection.
Bug: 117521009
Bug: 117519704
Test: a new test
Change-Id: I68f33365337a3c21c0914e8a02bef47e430d8e46
Developers should use setLeftTopRightBottom() instead. Also making setLeftTopRightBottom final.
Bug: 117520377
Test: none
Change-Id: I67d196e4950d4ef43c9b15dbd00a7dc5d72a59d5
Bug: 117520374
Test: None. There is no getter for it so it's not easy to test. Probably it should be tested on RenderNode side instead.
Change-Id: I399ebb772e557c849b02a1d71be7821121a9ce8a
Navigation bar can show on non-default display now. So the caller
should specify which display the desired navigation bar is on.
Bug: 117474929
Test: atest QuickStepControllerTest
Change-Id: Ibe06a6c7778134204502e6456860d69bea2a9061
Bug: 111514493
Test: Manualy launch an app
Test: Press home when activity is on top of the stack
Test: Quick scrub
Test: Swipe up on the home button, swipe down
Change-Id: Id8196e344585b4f7aebea595c12e7276dbbd881b
With the current implementation, when an ActivityView is created, it creates
a new Display in both DisplayManager and SurfaceFlinger. Then it attaches the
SurfaceView's surface to the Display so the content generated for the second
display renders into the SurfaceView. However, this is inefficient since it
requires the rendered content to get copied over.
With this change, the ActivityView creates a VirtualDisplay but also creates
a new SurfaceControl. It then notifies WindowManager so WM can instead
reparent the windows that represent the new VirtualDispay to be a child of
the SurfaceControl passed in. The SurfaceControl passed in is a child of the
SurfaceView's SC so the content in the new VirtualDisplay will just
automatically render onto the main display without having to copy.
The SF hierarchy will have the VirtualDisplay's surfaces as children of the
SurfaceView, but the WM will still represent the VirtualDisplay as a second
display.
Test: Run app with ActivityView and launch Activity in AV
Change-Id: I21c9bb189b6c12b0d98c67c8e68f53c621a4a802
Fixes: 111440225
This logic is not necessary anymore, and makes transition of the
windows manager flaky.
Bug: 119217735
Test: atest CtsActivityManagerDeviceTestCases:KeyguardTransitionTests
Change-Id: I953b40737f6673b83d27b096dd1f8e81b0cc6e46
Since not all KEYCODE_MEDIA_* keycodes return true in isMediaKey(),
the naming can give confusion. This CL renames the method to
isMediaSessionKey() and revises its Javadoc.
Bug: 119789707
Test: make -j
Change-Id: I36786ccf5606977e6d971c13d77d950356561bda
It will allow to call this method in AndroidX Transition without reflection.
ChangeBounds#BOTTOM_RIGHT_ONLY_PROPERTY,POSITION_PROPERTY are restricted now as well as developers can just use setLeftTopRightBottom method instead (it was used as a performance optimization in third-party transitions backport)
Bug: 117521189
Bug: 117521197
Bug: 117521053
Test: new test added for the method
Change-Id: I0a29bc8cf0b3357e49f6be14270993a21a6dfeee
This CL starts a journey to discover a brave new inset world. The
path to get us there may be rocky, but it's going to be rocky.
One of the main pledges of the new API is that an app can retrieve
what is causing a certain inset easily. For that, we need to
dispatch metadata who is causing what inset, such that we can query
it from the client side.
Furthermore, the client will be able to manipulate insets directly,
but also listen to animation changes. We don't want to go through
window manager for that, thus, there needs to be a local codepath
from (global window state -> WindowInsets).
Because we have these two requirements, we dispatch the relevant
global window state for insets, represented by InsetsState, and
dispatch it to the client. On the client side we take the frame
and the InsetsState and generate WindowInsets out of it.
Bug: 118118435
Test: InsetsSourceTest, InsetsStateTest, InsetsSourceProviderTest,
InsetsStateControllerTest
Change-Id: I2bfe9dda376512916261823fc2ee35cbedeb6731
- Make a better distinction between surface bounds and buffer size by renaming setSize to
setBufferSize and removing setSize for all buffer-less surfaces.
- Adds an error check in SurfaceControl to ensure buffer size is only set for buffer-less surfaces.
- Updates color fade surface to use passed in transaction object.
Bug:114413815
Test: go/wm-smoke
Test: atest FrameworksServicesTests:DimmerTests
Test: atest FrameworksServicesTests:SurfaceAnimatorTest
Change-Id: I88bd1452d6b3b3009e73e26986027d6a5a9efebc
* changes:
ScreenMagnifier: Track SurfaceFlinger Input
Forward SurfaceInsets to InputWindowInfo
Track native changes: Rework InputApplicationInfo
Replace InputWindowInfo#inputChannel with an IBinder token.
Fix name for canReceiveTouchInput
Fix pointer capture
Cleanup Input left-overs.
Port other InputWindowHandles to input surfaces.
Port InputConsumerImpl to SurfaceFlinger input.
Pass InputWindowInfo to SurfaceFlinger.
It will allows the usage of this methods in AndroidX Transitions without reflection.
Bug: 117520180
Test: new cts tests for the methods added
Change-Id: Idf26d4b5c9fd2bb975e5a86dd46bd631c326b861
This change is to support Auto case.
Auto may need to support displays without navigation bar by default,
because the display may be far away from driver.
Note: currently, hasNavigationBar is global since it's from config.
In future patches, it will also check hasSystemDecorations() on
secondary display.
TODO: We may find a way to make OEMs set hasNavigationBar() for each
display.
Fixes: 119584629
Test: atest WmTests
Test: atest InputMethodManagerServiceTests
Test: atest SystemUiTests
Change-Id: I427f8ad1f3da644a2bf79ee5b777830378515348
So that SurfaceFlinger can set the appropriate frame. See
frameworks/native commit and InputWindow.h for detailed
discussion.
Test: Manual
Bug: 80101428
Bug: 113136004
Bug: 111440400
Change-Id: I5df12fa3f90335f2045ee7107d3b1242ff0d00c5
First we move it inside of InputWindowInfo instead of InputWindowHandle
so it is part of the data sent across binder. Second we give it a persistent
identity of an IBinder token and use this for comparisons.
Bug: 80101428
Bug: 113136004
Bug: 111440400
Test: EndToEndNativeInputTest. Existing tests pass.
Change-Id: Id89a40e66887d834020f8e645fd1fb48adb7ee2e
The IBinder token is now being used as the UUID for InputWindows.
We can pass it around without the channel to avoid unnecessary FD
parcelling, duping, and other juggling.
Test: Existing tests pass.
Bug: 80101428
Bug: 113136004
Bug: 111440400
Change-Id: I8eba3fa05f249b7dfcb5c3d9817241cbfe9ab76c
IntelligenceManager must buffer ContentCapture events and send them to the
service in a batch, and this is the initial implementation of such batch:
it's just batching a pre-defined number of events, without any further
optimization (like flushing after x ms).
Test: manual verification
Bug: 111276913
Bug: 119220549
Change-Id: I96a4708fd3fcfd3098a0894a3ae3e967804cf4e6
We will classify the word as "dictionary" if we think user may want to look
it up. A "Dictionary" option will be shown in the floating toolbar
if users select words of this entity type.
A new Intent action is introduced to bring up the dictionary app.
The model that supports this entity type is not checked-in yet.
So no behavior change can be seen for now.
Test: Check-in the WIP model and try to select a "dictionary word".
Test: atest frameworks/base/core/tests/coretests/src/android/view/textclassifier/IntentFactoryTest.java
BUG: 68238822
Change-Id: Ib318d5b2abf79d61e55b33e397065a0714573121
Also don't show smart actions for selections in text with unsupported
characters.
Bug: 116321860
Test: atest android.view.textclassifier.TextClassifierTest \
android.text.util.cts.LinkifyTest \
android.text.util.LinkifyTest \
android.widget.TextViewActivityTest
Change-Id: Id271cab8aef6b9b13ef17f1a8654c7616f75cf13
1) For sysui or launcher used APIs to support multi-display:
- overridePendingAppTransitionMultiThumbFuture
- overridePendingAppTransitionRemote
2) Modify WindowAnimator pending layout change debug log for all displays.
Bug: 119530958
Test: atest ActivityManagerMultiDisplayTests
Test: atest SystemUITests
Change-Id: I46a118a21b4df42c0d1767b77d838956a53262d3
These methods are being reflected into and seem generally useful
to developers.
Bug: 117521349
Bug: 117521191
Test: new CTS in topic
Change-Id: I86e8a379e458aefe7fb2fe936b57eeeffa5ad42d
Augmented Autofill is a mechanism that will let a system-provided service
provide autofill suggestions when the stardand autofill can't.
Because the Augmented Autofill service is a system app, it has less restrictions
than the standard service; in particular, this service will be responsible for
drawing the autofill UI, although the framework will provide a mechanism to host
the window. Right now, it's creating a TYPE_APPLICATION_OVERLAY window in the
service process roughly below the focused view, but in the long-term it will
use the IME suggestion window to display it.
This CL provides the initial APIs and end-to-end workflow for the simplest
scenario, but it's still full of TODO's.
Test: atest CtsAutoFillServiceTestCases # to make sure it doesn't break it
Test: atest FrameworksCoreTests:SettingsBackupTest
Test: mmm -j150 packages/experimental/FillService &&\
adb install -r ${OUT}/data/app/FillService/FillService.apk &&\
adb shell settings put secure intel_service foo.bar.fill/.AiaiService &&\
adb shell settings put global autofill_smart_suggestion_emulation_flags 2 &&\
adb shell pm grant foo.bar.fill android.permission.SYSTEM_ALERT_WINDOW
Bug: 119638877
Change-Id: I8d59b4eab3e530cd89b81456681a72fdab532756
We were not calling it on all places it should. And even worse, it was called
when the view was not laid out yet, which caused a side-effect on TextViews
(as it was calling assumeLayout()).
Bug: 111276913
Fixes: 119786503
Test: manual verification on Hangouts
Test: atest android.view.cts.ViewTest \
android.widget.cts.TextViewTest \
android.widget.cts.EditTextTest \
CtsAutoFillServiceTestCases
Change-Id: I685460d9b1e0428ec0e5377826a549a678f6434e
