In the InlineSuggestionFactory, it will filter the tooltips by the
field let only the first one can pass to the IME and drop others.
When the IME inflates the inline suggestion, if there is a tooltip of
the suggestion view, inflates the tooltip view at the same time. It
will create the InlineTooltipUi that will be a popup window and
contains the surface view of the tooltip.
Bug: 172024354
Test: atest CtsAutoFillServiceTestCases:InlineTooltipTest
Change-Id: I6f20dcad6d03432017e684964eca52dff2609205
Bug: 168341541
Test: atest CtsAutoFillServiceTestCases:DatasetTest
Test: Manually tested image suggestions when the target app doesn't have media store permissions
Change-Id: I42546c76e45ec404e8d8de3bf63ca094d8a494c6
The test config takes longer than 15mins to run. Move it to a dedicated
group for running slow presubmit Test Mapping tests.
Bug: 174654670
Bug: 174495337
Bug: 175150979
Change-Id: I533e749f57798c4b162a105246b51854a539a65f
Test: None
- Add getLaunchedFromUid and getLaunchedFromPackage into Activity
because they are used in several places.
- Move getActivityClassForToken to ActivityTaskManagerInternal#
getActivityName because it is only used in system server.
- Remove getPackageForToken because it is no longer used.
Bug: 174041144
Bug: 174040691
Test: CtsWindowManagerDeviceTestCases
Change-Id: Iac1581ac2271baf1ab1625ced6cc1f42bf05eaf5
maintenance to Sessions.
* mSessionState is the unique lifecycle State of the current Session.
* mSessionInfo contains metadata and other state identifying booleans
for the current Session.
Bug: 171350451
Bug: 162357598
Test: atest CtsAutoFillServiceTestCases
Change-Id: Id8cead9e5299b3f4e24c035706e04fa46555fc9b
Add basic tests into TEST_MAPPING to make sure the tests can be
tested in presubmit. There is a 30 minutes limitation for presubmit
which doesn't allow to run all autofill tests. We only choose some
tests and add @Presubmit annotation to the tests that want to verify
in presubmit.
The tests contains basic fillUi, saveUi, authentication, filtering,
fill history, virtual view, compat mode. Skip webview because it is
a high flaky fail tests. The presubmit time is 20-30 minutes for now,
we can add/delete the chosen tests in presubmit when we receiving the
fails.
Bug: 154961272
Test: TreeHugger
Change-Id: I25684a2122c4e705b75b9a30c3b7a61337bbd1a7
Starting with S, any app targeting S+ will need to specify
explicitly either FLAG_MUTABLE or FLAG_IMMUTABLE when creating
PendingIntents.
This change helps mitigate against implicit PendingIntent reuse.
At present, all PendingIntents are mutable by default unless
FLAG_IMMUTABLE is explicitly set when creating them. This often
leads to developers accidentally making the PendingIntents mutable
and thus handing their receivers powers to fill in critical fields.
Because the autofill saveui retore mechanism will need to update it,
the PendingIntent should be mutable.
Bug: 170771150
Test: atest CtsAutoFillServiceTestCases
Test: Manual. Make sure the function works normal.
Test: Don't see PendingIntent error log.
Change-Id: I6e03a48968b98dec10e9c9dc05d1f3af42f8f0e5
* Session contains removeFromService() and destroy().
removeFromService() removes the session and also calls destroy()
* AFManagerServiceImpl has renamed methods to remove*Sessions() since
it's actually calling into removeFromService instead of just destroy().
BYPASS_INCLUSIVE_LANGUAGE_REASON=will_do_in_separate_cl
Bug: 162357598
Test: atest CtsAutoFillServiceTestCases
Change-Id: I4ddc4b863b2f3c962408dc0e54f8be5b34ee32b4
Image suggestions (and other rich content) are not handled the same way
as primitive autofill values. These suggestions are also only applicable
to augmented autofill. Therefore, instead of reusing AutofillType and
AutofillValue, we use a separate code path to insert rich content. A
follow-on change will remove AUTOFILL_TYPE_RICH_CONTENT and the
corresponding code on AutofillValue.
Bug: 168837034
Test: Manual and unit tests
atest CtsAutoFillServiceTestCases:DatasetTest
atest CtsAutoFillServiceTestCases:InlineAugmentedAuthTest
atest CtsAutoFillServiceTestCases:InlineAugmentedLoginActivityTest
Change-Id: I4fa3baf2b545908fc25f3a6e28a7addc7004786b
We track whether inline request is needed with a separate boolean. This
also resolve the bug where the CountDownLatch was accounting for both
inline and regular request, and errors when due to async on multiple
requests, receives multiple regular request instead.
Bug: 162357598
Fixes: 159417365
Test: atest CtsAutoFillServiceTestCases
Change-Id: I56e11163d9163f73f807f6adf06d93bf26617173
* Move helper methods to static methods in Helper.java
* Add documentation on ambiguous methods.
* Rename method to end with *Locked for consistency.
Bug: 162357598
Test: atest CtsAutoFillServiceTestCases
Change-Id: I1b2f788a74fa16f566520f5e83c2df21ffbca2dc
In order to provide a better user experience, it would better know the
reason why a save dialog was not shown and improve the autofill experience.
So it is necessary to add the reason why a save dialog was not shown to
FillEventHistory.
Bug: 158328375
Test: atest FillEventHistoryTest
Test: atest InlineFillEventHistoryTest
Change-Id: I50c1e40334066d3f4844426c4b03294079a967b2
* Create InlineFillUiInfo to encapsulate the numberous arguments passed
into the factory.
* Combine CreateInlineSuggestions API for regular and augmented
autofill.
Bug: 162357598
Test: atest CtsAutoFillServiceTestCases
Change-Id: I64d5ca2aec510b9e04ebc3c499ca0029dc96925c
UserController calls SystemServiceManager on some stages of the user
switch lifecycle, and SystemServiceManager calls the respective
callbacks in the SystemService objects it manage.
Prior to Android 11, these callbacks would take a @UserIdInt userid,
but now they take a TargetUser (which in turns contains a Userinfo).
So, currently, UserController calls SystemServiceManager passing the
userid, and SystemServiceManager gets the UserInfo from
UserManagerService. That works fine most of the time, but there might
be some race conditions when a user is removed that can crash the
system when such user is stopped (because UserManagerService doesn't
have its UserInfo anymore).
This CL fixes this issue by refactoring the user switch workflow so:
- TargetUser doesn't hold a reference to the UserInfo anymore, but
offer the methods needed by SystemService implementations.
- SystemServiceManager keeps track of the TargetUser objects used in
the callbacks.
Test: manual verification
Fixes: 159831354
Change-Id: If68ab1b5e247c7389c8cac16432d8b8809507e86
This issue causes CTS test failures while running instant mode tests.
This patch will help partners pass instant mode CTS successfully.
Bug: 153099178
Test: atest --instant android.autofillservice.cts.SimpleSaveActivityTest
Change-Id: I2bd6c553c75a1a207d7bfd7113aad5e377880b3e
This is just a plain refactoring: the removed methods in the changed
classes were called by default by the new methods in the superclass
(SystemService).
Test: m
Test: atest NotificationManagerServiceTest BackupManagerServiceRoboTest
Fixes: 161943081
Exempt-From-Owner-Approval: refactoring without side-effects
Change-Id: Ifd8df592eb4494cc0922b7e0b2ff20187b8a8b3e
Root cause
The error message is set by AutofillService, AutofillService calls
FillCallback.onFailure(null) back to the platform. Because a081250
uses String.valueOf(message), this method will make a null object
become to a "null" string. This may cause the Autofill session to
think we should show message because of a non-null message. And if
the AutofillService target SDK is lower than 29, we don't ignore show
message, then users will see a "null" toast.
Solution
Instead of passing the message parameter to String.valueOf() directly
, we check the message first, only passing to String.valueOf() if the
message is not null. And we pass an empty string if the message
parameter is null.
Bug: 159888723
Test: Use a test AutofillService which target SDK is lower than 29,
make sure no null toast is shown
Test: atest CtsAutoFillServiceTestCases
Change-Id: Id7ff581b3a7f35cf97b4f3405a40bfa1a420823e
(cherry picked from commit 3c7ac7de46)
Root cause
The error message is set by AutofillService, AutofillService calls
FillCallback.onFailure(null) back to the platform. Because a081250
uses String.valueOf(message), this method will make a null object
become to a "null" string. This may cause the Autofill session to
think we should show message because of a non-null message. And if
the AutofillService target SDK is lower than 29, we don't ignore show
message, then users will see a "null" toast.
Solution
Instead of passing the message parameter to String.valueOf() directly
, we check the message first, only passing to String.valueOf() if the
message is not null. And we pass an empty string if the message
parameter is null.
Bug: 159888723
Test: Use a test AutofillService which target SDK is lower than 29,
make sure no null toast is shown
Test: atest CtsAutoFillServiceTestCases:LoginActivityTest#\
testAutofillAgainAfterOnFailure
Change-Id: Id7ff581b3a7f35cf97b4f3405a40bfa1a420823e
The current implementation has a problem where:
In the autofill side, there can be multiple autofill sessions existed
at the same time. But in the IME side, there is always only one
InlineSuggestionSession at any given time. It will cause the previous
autofill session to fail communication with IME.
It would better change to drop down UI when the autofill inline
suggestions don't be shown in IME.
How to reproduce this issue:
To add an input field with autofillable into the authentication activity
of InlineFillService. To tap on the input field of the authentication
activity during the authentication flow. After completing the
authentication, the inline suggestions won't be shown in IME.
BTW, if the input field is marked as non-autofillable, this issue won't
occur.
Manual verification:
1.Tested this patch with InlineFillService and it worked well.
2.Feng also helped to test this patch with the webview
(sort of randomly), and didn't find any broken case
Bug: 158877106
Test: atest CtsInputMethodTestCases
Test: atest CtsAutoFillServiceTestCases
Test: new CTS test Ie1d9055b0eabfcaa00861869467be8dcee25833e
Test: manual verification with InlineFillService
Test: Feng also helped to test this patch with the webview
Change-Id: Ib06edd823fa4478f34362164f3f7dd3544e51705
* For the case where the pinned inline suggestion triggers an
pending intent through the auth flow, and it returns a dataset
to be autofilled, previously we would replace the existing
dataset with the returned dataset. However, this is causing
several potential issues:
1. if the returned dataset doesn't contain inline presentation
the the pinned icon will not show again
2. if the returned dataset contains inline presentation but not
the pending intent, then the pinned icon will show up again
but tapping on it will not launch the pending intent
3. if the returned dataset contains the inline presentaion and
the pending intent, then when we "autofill" it, it'll fire
the pending intent directly as opposed to filling in the
value
* We fix the issue by not replacing the old dataset if the dataset
is a pinned inline suggestion.
* One caveat of the approach is that: a dataset can potentially
have multiple fields, and it's possible that some of the fields'
has inline presentation and some don't. It's also possible that
some of the fields' inline presentation is pinned and some isn't.
So the concept of whether a Dataset is pinned or not is
ill-defined. Here we say a dataset is pinned if any of the field
has a pinned inline presentation in the dataset. It's not ideal
but hopefully it is sufficient for most of the cases.
* An alternative approach is to have the autofill provider telling
whether they want to replace the old dataset or not, through
a new field in the returned Bundle. But that requres an API change
so is infeasible at this time.
Test: atest android.autofillservice.cts.inline
Test: atest android.autofillservice.cts.augmented
Test: atest android.autofillservice.cts.LoginActivityTest
Test: atest android.autofillservice.cts.AuthenticationTest
Bug: 159367101
Change-Id: I6d162aeb88a4655989c1aa315df8304c0980ac60
* Attach to each inline suggestion remote view the user id
and session id, which together identify a session. Then when
the session is destroyed, we release all the remote views
associated with the it.
* Worst scenario is that the IME is still showing the UI when
the remote view is released due to session destroy, in which
case the suggestion will disappear from the IME window. But
we also make sure we send an empty response to IME before
releasing the views, so it should be bad. Plus when a session
is destroyed, interacting with the suggestion UI doesn't do
anything, so it's not very helpful to show them.
* Also add a dump method to the InlineSuggestionRenderService
to help with debugging
Test: atest android.autofillservice.cts.inline
Bug: 154683107
Change-Id: I488fd9d9af08d0df3ffd3c851f96c567d07eed5a
