As general background, OWNERS files expedite code reviews by helping
code authors quickly find relevant reviewers, and they also ensure
that stakeholders are involved in code changes in their areas.
Some teams under frameworks/base/ have been using OWNERS files
successfully for many years, and we're ready to expand them to cover
more areas. Here's the historical coverage statistics for the last
two years of changes before these new OWNERS changes land:
-- 56% of changes are fully covered by OWNERS
-- 17% of changes are partially covered by OWNERS
-- 25% of changes have no OWNERS coverage
Working closely with team leads, we've now identified clear OWNERS on
a per-package basis, and we're using "include" directives whenever
possible to to simplify future maintenance. With this extensive
effort, we've now improved our coverage as follows:
-- 98% of changes are fully covered by OWNERS
-- 1% of changes are partially covered by OWNERS
-- 1% of changes have no OWNERS coverage
This specific change is automatically generated by a script that
identifies relevant "include" directives.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
Change-Id: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
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 3c7ac7de467fbeb905ed4969a2f2fa59f06f11d1)
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
1. When regular autofill returned null and augmented autofill is
disabled by password. (regular disabled augmented autofill case is
handled by session being destroyed).
2. If the response contains empty/null datasets or service disabled
autofill when response is received by frameworks.
Bug: 159364411
Test: atest InlineLoginActivityTest
Change-Id: Ic0758e757eacd277a5bf43080fe4db82d603953e
This fixes use of the autofill SaveUi for secondary users. Without this
change, when running under a secondary user, the PendingIntent is always
sent to U0.
Bug: 159618798
Bug: 155102708
Test: lunch hawk-userdebug && m
run cts --skip-device-info -s emulator-5554 -m CtsAutoFillServiceTestCases -t android.autofillservice.cts.SimpleSaveActivityTest#testTapUrlSpanOnSuccinctDescription_thenTapBack
Change-Id: Ie6deaaaf47a11ae841c183003471d051df2beb90
AutofillInlineSuggestionsRequestSession controls the inline
communication with the IME, we can centralize the UI show and hide
notification here. Use a variable mPreviousHasNonPinSuggestionShow to
save the previous status, when the display status change, e.g. from
no suggestion to has suggestions we can notify inline ui shown event.
Bug: 157762527
Test: atest android.autofillservice.cts.inline
Test: atest CtsAutoFillServiceTestCases:DatasetFilteringDropdownTest
Test: atest CtsAutoFillServiceTestCases:InlineFilteringTest
Test: atest CtsAutoFillServiceTestCases:LoginActivityTest
Test: Manual. Write a test app and register AutofillCallback, make
sure the callback is called as expected.
Change-Id: I8ee38008874c4a6f110635e8e4107a4eef72ed14
Setting an authentication IntentSender on an Augmented Autofill
suggestion was being ignored. With this change, it will trigger
the auth flow as documented.
Fix: 157863999
Test: Manual
Test: atest android.autofillservice.cts.inline
Change-Id: Id21c8f074bd0f49992e01445d50b1503af4720b6
* For inline autofill, we always need to get an IME callback before
calling the augmented autofill service. This is because although
autofill keeps a list of undestroyed sessions, the IME side
always discards the old callback for autofill when a new one
is created. So in case of switching back to an existing autofill
session, we need to make sure we ask the IME to return a new
callback.
* we current have the check which missed a case where we are
re-entering an existing autofill session, but the standard
autofill was returning null the previous time,
so it goes to trigger augmented autofill directly. In this case,
we need to call IME onCreateInlineSuggestionsRequest to get a
callback before calling the augmented autofill. We didn't, and
this patch fixes it.
Test: atest android.autofillservice.cts.inline
Test: manual
Bug: 158877106
Change-Id: Ie15cf0763ae49a204ad09c2eaac798890388622e
* this reverts ag/11592765 since it causes a regression for b/145949573
in the following case:
1. user taps on a field for which autofill returns null and augmented
autofill is triggered
2. user goes home, which sets the mExpiredResponse to true
3. user comes back to the app, now tapping on the input field over
and over, each tap will trigger a new augmented autofill request
* the fix is to revert the above patch, and then handle the input
method switch for augmented autofill case by setting the current
view to null, and also setting the augmented autofill id to null,
such that the entire autofill flow will be executed again.
* note that this patch changes one behavior - in case regular autofill
returns null and augmented autofill is triggered, switching input
method and tap on the field again, it will trigger regular autofill
again (before this patch, it will only trigger augmented autofill)
Test: relevant cts tests
Test: manual testing that on the chat app, switching input method
and then tap on the field again triggers a new request
Bug: 150483555
Bug: 157412832
Change-Id: I0868ff62047f66402885f9821f7981ca4596f76b
* The bug was introduced in ag/11784240 causing the existing CTS test to
fail: android.autofillservice.cts.augmented.AugmentedLoginActivityTest
#testCancellationSignalCalled_retriggerAugmentedAutofill
* Basically when the dropdown fill window is displayed, we should not mark
the augmented autofill request as complete
Test: atest android.autofillservice.cts.augmented
Test: atest android.autofillservice.cts.inline
Bug: 158864213
Bug: 158038231
Change-Id: Ifb75189c1ba3183c99516bfb9a7053524f4bbddc
* Note that usually the session is destroyed when the focus is
already on a new input field in a different activity, so this
action will be no-op most of the cases
* But in case of augmented autofill service dynamically requesting
a new autofill flow, this works well on clearing the existing
suggestions on the current input field
Test: manual
Test: atest android.autofillservice.cts.inline
Bug: 157515522
Bug: 158038231
Change-Id: I6cedb33737d822c3c3eb4ee127984c24c4307f7a
* The augmented autofill may dynamically request an autofill request
which will "invalidate" the old suggestions. In case the new request
doesn't return any suggestions, we need to make sure the old
suggestions are removed from the IME.
* See the scenario in https://b.corp.google.com/issues/158038231#comment14
Test: manual
Test: atest android.autofillservice.cts.inline
Bug: 157515522
Bug: 158038231
Change-Id: If85592395ad918197566a5ca556fba8ccc971071
This is consistent with dropdown.
The current logic was implemented incorrectly in
I396c2cb279f1eb552bbae8c3509cb29c95e86609.
Fix: 158274878
Test: manual
Test: atest CtsAutoFillServiceTestCases:DatasetFilteringInlineTest
CtsAutoFillServiceTestCases:InlineFilteringTest
CtsAutoFillServiceTestCases:DatasetFilteringDropdownTest
Change-Id: I6d67945944e616d0c30b19eb1430383be754b67c
AutofillService package updated cause autofill framework removed
its service from the cached. When next time want to use the service,
autofill framework will try to update the service information, but the
service will be set as disabled due to can not get the service
information from package manager.
Adds the service package policy flag: PACKAGE_UPDATE_POLICY_REFRESH_EAGER
to early make the cached to avoid this issue.
Bug: 158034069
Test: manual
Test: atest CtsAutoFillServiceTestCases
Change-Id: Ib67617fac8dcaa92b76768bd61aa19211eac523d
* This is to handle the case where when coming back from the
attribution dialog, the augmented autofill is retriggered which
cause the old inline session with the IME to be destroyed and a
new one created, in which case we used to send an empty response
to IME to clear the suggestions. But this would cause flicker in
the IME side, between the time when it's cleared and the new
suggestions arrive.
* It's safe to remove this becasue we now rely on the onStartInput
(or onFinishInput) in the IME side to clear the suggestions
anyways.
Test: atest android.autofillservice.cts.inline
Bug: 157515522
Change-Id: Ie7cb8b164b7f5352632ee509ea978a2d421f5e5b
* This, together with the change on the sample IME, gets rid of the
flicker on the notification pull down/up case, as well as switch
from username to password.
* This doesn't fix the flicker when coming back from the attribution
dialog, yet. As in that case the framework sends an empty suggsetion
upon dismissing the dialog. Will explore fix for that in a separate
patch.
Test: atest android.autofillservice.cts.inline
Bug: 157515522
Change-Id: Ia6d5d2b517cf400980fb602094c1abafb7100786
This is missing notifications on the suggestions being hidden/shown
while filtering, but that is a bit harder to solve as we have to pipe
this state back from AutofillInlineSessionController. (although, I'm not
certain we even want this behavior, however it is inconsistent with the
dropdown behavior for now)
See bugs linked for what is fixed for filtering (some are not marked as
fixed as they still might need cts tests).
The main change is to make the privacy protection mechanism a bit
smarter - it now only applies to text-matching based logic.
Fix: 157763435
Fix: 156930859
Bug: 155517211
Bug: 157762527
Test: atest CtsAutoFillServiceTestCases:DatasetFilteringInlineTest \
CtsAutoFillServiceTestCases:InlineFilteringTest \
CtsAutoFillServiceTestCases:DatasetFilteringDropdownTest
Test: atest android.autofillservice.cts.inline
Change-Id: Icf94e21ba0df3b15a32454038772967cc1f6da79
The lastResponseId does not changed to new value with the
lastResponseIdx at same time.
Bug: 156775277
Test: atest CtsAutoFillServiceTestCases
Change-Id: I6b26f5e82366745e2797c959fa52a7aa7f5bc883
Augmented autofill does not request a new fill request after the old
response is expired
Bug: 157412832
Test: atest CteAutoFillServiceTestCases
Change-Id: I88d400119fbc602869dc23d8b9f6575eb56de2c5
Expired the old response while received input method subtype changed.
When user next tap on an autofill field, trigger a new fill request for
the new input method.
Bug: 150483555
Test: manual switch imput method
Test: atest CtsAutoFillServiceTestCases
Change-Id: I97be067db3a79d2481c05aeb59875ec24514199d
* the behavior was changed in ag/11362916 causing it to be
inconsistent with the dropdown UI.
Test: atest android.autofillservice.cts.inline
Bug: 156667581
Change-Id: I29b5a2cdfacdeda2d36a488c64e745ea795b01f9
