This field is used on pretty much all Autofill metrics, except
AUTOFILL_USERDATA_UPDATED, AUTOFILL_SERVICE_DISABLED_SELF, and
AUTOFILL_INVALID_PERMISSION.
Test: atest CtsAutoFillServiceTestCases
Test: adb shell logcat -b events | grep sysui
Bug: 79351659
Change-Id: I2e2f3dcc780a3896162b158926f5ee89c7cb342d
1. Define default Themes for autofill window and save dialog.
(http://go/theme_autofill). Phone uses light themes, TV uses
dark themes.
2. Apply autofill theme to RemoteViews passed from autofill service.
So this can make sure the textColor of RemoteViews matches
the background of autofill theme uses.
Updated public javadoc that autofill service should not
hardcode color values.
3. A new TV ux that occupies half screen height (go/autofill-for-tv).
TV autofill now passes unhandled physical keyevent to app window
in the same way phone/tablet does.
4. Fixed ATV autofill window to be SYSTEM_DIALOG, so it wont be
clipped by app activity window (DialogLauncherActivityTest).
Bug: 71720680
Bug: 74072921
Test: CtsAutofillTest
Change-Id: Ib570227b0958b1800e8f0600b8aec36478568d74
Save has many limitations on compat mode, so we better not change the SaveInfo
behavior but rather document then.
This reverts commit 4f74a018c8ee9801f1d5ce2c7ec726251efc4fbf.
Test: atest CtsAutoFillServiceTestCases:VirtualContainerActivityTest \
CtsAutoFillServiceTestCases:VirtualContainerActivityCompatModeTest
Bug: 77655074
Change-Id: I36bd28ca546dcedefe75de7815b76b8b5827aee3
Otherwise, it will log false negatives when app launches a new activity in the
same autofill session. Example:
04-18 19:34:32.392 5423 7199 W AutofillSession: Activity ComponentInfo{com.netgear.WiFiAnalytics/com.netgear.WiFiAnalytics.WiFiAnalyticsWifiRoomSignal} forged different component on AssistStructure: ComponentInfo{com.netgear.WiFiAnalytics/com.netgear.WiFiAnalytics.WiFiAnalyticsWifiAnalyzerTab}
Fixes: 78235438
Bug: 69981710
Test: manual verification, cannot be CTS tested.
Test: CtsAutoFillServiceTestCases
Change-Id: I0408cd159c2be22841a1f6c36a4a2c17e59a6219
autofill should use relative location to app window as PopupWindow
is based on relative location.
The fixed reverted changes made in compatibility mode CL that made
autofill window TYPE_SYSTEM_DIALOG.
Changing PopupWindow to use absolute screen location is another fix
choice, but it does not allow autofill window to be automatically
moved when app window changes location (e.g. adjust split window
separator or bring up IME)
The autofill window switches to TYPE_APPLICATION_ABOVE_SUB_PANEL with
IME disabled. So it still appears above IME and most other app
windows, unless app window is TYPE_APPLICATION_ABOVE_SUB_PANEL too.
Fixes: 73555917
Bug: 77587135
Test: manually tested compability mode with chrome amazon login
manually tested splitted window
atest CtsAutoFillServiceTestCases
Change-Id: I6b8ecf3fe7a91cebea1f7a868f4b15fbed8b0051
So it can be customized in a per-device basis...
Test: atest CtsAutoFillServiceTestCases
Bug: 69796626
Change-Id: I1dd617b7ae658dbff898ff5c9c0ee3fbf195a929
These are useful to emulate the behavior of Autofill on TV.
Test: adb shell cmd autofill get full_screen_mode
Test: adb shell cmd autofill set full_screen_mode true # then ran sample
Bug: 77155952
Change-Id: I0cb7757559e8132e9777eb63b5442de485261a0b
When a dataset is selected, the framework tries to autofill all views belonging
to it. But if one (or more view) failed to autofill, we should let the user
recover by tapping the view again.
This scenario typically happens when views are recycled.
Test: atest MutableAutofillIdTest#testViewGoneDuringAutofillCanStillBeFilled
Test: atest CtsAutoFillServiceTestCases # manually retrying flaky failures
Fixes: 76149637
Change-Id: I7a6352c68b4a7d5e4cb80a7346c66efd831f21c8
The contents of a browser URL bar is typically changed for 2 reasons:
1.User entered a new URL.
2.Form was submitted and the URL changed.
On scenario #1, the current session should be canceled, while on #2 it should be
committed. Scenario #2 is already handled when the service sets a SaveInfo, so
this CL handles the other cases:
1.Focus on URL bar is ignored so it does not trigger a new partition.
2.If URL bar changed and service didn't set a SaveInfo, the session is canceled.
Fixes: 76027553
Test: manual test with Chrome
Test: new tests on VirtualContainerActivityCompatModeTest:
testFocusOnUrlBarIsIgnored()
testUrlBarChangeIgnoredWhenServiceCanSave()
testUrlBarChangeCancelsSessionWhenServiceCannotSave
testUrlBarChangeCancelsSessionWhenServiceReturnsNullResponse
Test: atest CtsAutoFillServiceTestCases
Change-Id: I19d2aa4c8b25def0d5eca1c59cfdc2ffe33dd388
It will be removed before the final P build.
Test: atest FrameworksServicesTests:AutofillManagerServiceTest CtsAutoFillServiceTestCases
Fixes: 74445943
Change-Id: I9bc243a3c1ae78f2c385dbb907d362d8ab16b34c
The syntax of that setting changed from P Developer Preview1 to the final P, so
it's safer to use a new name than risk breaking devices during the update.
Bug: 74458004
Test: atest CtsAutoFillServiceTestCases:VirtualContainerActivityCompatModeTest\
FrameworksCoreTests:SettingsBackupTest
Change-Id: I1c507e8eae20f598dfe259178667ae6c2bc892ff
These ids used to be defined at the manifest but now are defined on settings,
so we need to provide default values until the settings are fixed.
Test: atest FrameworksServicesTests:AutofillManagerServiceTest
Bug: 74445943
Change-Id: I050a96d73cb9e008179865381c6abc3041e82844
The manifest attribute is still public as it might have been used by autofill
services deployed against P DP1; it will be removed after the next developer
previs is branched out. We also need to assumie a default value for the buttons
if not specified by settings, but that will be done in a separate change so it
can be easily reverted.
Also implemented support for multiple buttons, and added unit tests.
Test: atest CtsAutoFillServiceTestCases:VirtualContainerActivityCompatModeTest \
CtsAutoFillServiceTestCases:VirtualContainerActivityTest \
FrameworksServicesTests:AutofillManagerServiceTest
Bug: 74445943
Bug: 72811561
Fixes: 73786629
Change-Id: I066ecf40fde2c5318dd8633a659fca8b7af8aecd
This behavior existed since autofill was introduced on O and it won't be fixed
on P, so there's no point on warning. In fact, the warning is often a red
herring for other issues, not to mention a big logcat spammer.
Bug: 35708678
Test: manual verification looking at logcat
Change-Id: I40be4ce25abc5b097ea67e5cb34bb9c4237f0826
This is a regression caused by the autofill compat feature change, as the
Fill UI window was changed from a sub-panel which is auto managed by the window
manager to an overlay, to ensure the fill UI covers all app windows, so compat
mode would work for apps without app changes.
Test: atest CtsAutoFillServiceTestCases:SessionLifecycleTest#testDatasetGoesAwayWhenAutofilledAppIsKilled
Test: atest CtsAutoFillServiceTestCases:SessionLifecycleTest#testSaveRemainsWhenAutofilledAppIsKilled
Test: atest CtsAutoFillServiceTestCases # usual flakiness
Test: manual verification by adb shell kiling an app while UI is shown
Fixes: 73566982
Change-Id: I42f0acbaf3d0b19c081b8cb3613bebb01ceb487a
(cherry picked from commit 57dae0b6f0678d2c43e4556fe7a9efee5214dbd8)
ag/3434666 causes a regression:
Before ag/3434666, autofill gets touch event after IME, autofill
close itself if it gets ACTION_OUTSIDE touch event.
But after ag/3434666, autofill intercepts touch events before IME, if
user touches within IME, autofill still gets ACTION_OUTSIDE event,
and close itself unexpectedly.
The fix moves the closing code to ViewRootImpl.EarlyPostImeStage
around the same place closing tooltip.
If user taps outside autofill window, we will force to close window,
even last autofillid that requestShowUi does not match.
Bug: 73796497
Test: atest CtsAutoFillServiceTestCases
Test: Added LoginActivityTest.testAutofillTapOutside
Test: manually tested using IME and sample app
TODO: need a fake IME service to dispatch given key upon touch.
Change-Id: I10fc0d29dc30d29a48b2118264ec1c4375062deb
Symptom:
RemoteFillService was crashed due to IllegalArgumentException
"Service not registered:" at onServiceConnected.
Root cause:
RemoteFillService#onServiceConnected tries to unbind the connection
if mDestroyed is flagged or mBinding is not flagged. It always fails
with IllegalArgumentException.
Both mDestroyed and !mBinding mean the connection was unbound.
You can't unbind the unbound connection. It's not allowed.
Fixes: 73864601
Fixes: 69905688
Change-Id: If5481468ddac7be41accad63e9d5382bc6c029fd
