| c7619632145c23e6b5dd45620094e0bc686ad2db |
|
25-Apr-2017 |
Philip P. Moltmann <moltmann@google.com> |
Report multiple FillContext-s onSave
To make life easier the reponseId is not part of the FillResponse.
Test: CtsAutofillServiceTestCases (added test for multiple Contexts)
Change-Id: If09e00b7267d293e4234a7a9837ad88d73af1b24
Fixes: 36481649
/frameworks/base/core/java/android/service/autofill/FillCallback.java
|
| e5f9c30688f0277505fb6b50ea385e5df6271ed8 |
|
19-Apr-2017 |
Felipe Leme <felipeal@google.com> |
Some Autofill API changes.
- Added View.IMPORTANT_FOR_AUTOFILL_YES_INCLUDE_DESCENDANTS
- Added View.IMPORTANT_FOR_AUTOFILL_NO_EXCLUDE_DESCENDANTS
- Added FillResponse.Builder.setIgnoredIds()
- Fixed javadoc links.
These changes are not implemented yet....
Bug: 37424141
Bug: 36171235
Test: m update-api
Change-Id: I604960443ab08cd3f2a84a70b0a2cece7cb0a00c
/frameworks/base/core/java/android/service/autofill/FillCallback.java
|
| 013efe173e56612a910ebd8576480ce4ef005e3c |
|
14-Apr-2017 |
Svet Ganov <svetoslavganov@google.com> |
Add support for multiple fill contexts
When saving data filled by the user the platform provides to
an autofill provider the state of the UI allowing the provider
to interpret this state and store relevant information.
A limitation of the current design is that the fill provider
needs to interpret the screen content twice, once handling a
fill request and once handling a save request. To address this
we are introducing a id for each fill request allowing the
autofill provider to associate arbitrary state with each fill
request and store it in the client data bundle later passed
to save.
Another limitation of the current design is that if the screen
changes dynamically while the user interacts with the app the
UI state passed on save represents a static snapshot, therefore
it is not possible to the autofill provider to determine the
context in which the data in the UI was filled. We could
keep the views and have deltas for views being removed/added
/moved/changed but this is not enough as the fill provider
needs to know not only what changed but what changed for every
fill request and in one session there could be multiple fill
requests. To address this we provide a list of fill contexts
on save each of which has the id of the corresponding fill
request. This allows the fill provider to know the exact context
in which the data was popuplated and also use its custom client
state for this fill request if desired.
This change deprecates the old APIs and the new ones delegate
to the old ones. Once the clients migrate to the new APIs we
will remove the old ones.
Test: all autofill CTS tests pass
Change-Id: Idcebcc671aa3c078a305d8c358e225274fccc588
/frameworks/base/core/java/android/service/autofill/FillCallback.java
|
| 2ac463e3f5c3b757ecbc7e30e0fc1e8e0d878272 |
|
13-Mar-2017 |
Felipe Leme <felipeal@google.com> |
Allow users to manually request Autofill.
- Added a requestAutofill(view,flags) method, that when passed with
FLAG_MANUAL_AUTOFILL triggers a manual request.
- Added same method for virtual views
- Overloaded existing AutofillService request methods to take a flag.
- Added an AUTOFILL context menu option on TextViews.
- Added a canRequestAutofill() that is used to enable the context menu.
BUG: 35708229
Test: manual verification
Test: existing CtsAutoFillServiceTestCases pass
Test: android.autofillservice.cts.LoginActivityTest#testManualAutofill pass
Change-Id: I1a64d40da3373774451d178b1cabf20f11120e9d
/frameworks/base/core/java/android/service/autofill/FillCallback.java
|
| 640f30a7763b0a4b80c767acb84c740aac04768b |
|
07-Mar-2017 |
Felipe Leme <felipeal@google.com> |
Replaced auto-fill by autofill to keep it consistent with API style.
This change will affects 2 types of apps: autofill service implementations
and apps that use autofill APIs.
Since just the former is known to be used at the moment, we're not trying
to keep backward compatibility with the latter.
Bug: 35956626
Test: CtsAutoFillServiceTestCases pass
Test: android.provider.SettingsBackupTest pass
Change-Id: Ia720083508716deae9e887f9faa7ae7c5a82f471
/frameworks/base/core/java/android/service/autofill/FillCallback.java
|
| 782043caf81055aa1c331e9cc15b24a10e1bf17a |
|
11-Feb-2017 |
Svet Ganov <svetoslavganov@google.com> |
Refactor auto-fill
* Fix a layering issue where auto-fill manager which is in view
depended on activity which is in app
* Moved auto-fill classes to view or service based on their
purpose and removed dependecy on the classes in view to the
classes in service
* Push state to local auto-fill manager whether auto-fill is
enabled to avoid making IPC for every focus transition if
the user did not enable the feature
* Remove unnecessary offload to messages when handling calls
to auto-fill manager service as these are made over a oneway
interface and in general they do almost no work and typically
we do these on the binder thread
* Removed id from data set and fill response as the provider
can embed everything it needs to id them in the auth pending
intent
* Enforce the auth UI to be only an activity as this will work
with multi-window, recents, and back and also does not require
draw on top of other app special permission
* Authentication also no longer requires passing a remotable
callback to the auth activity but the activity handles the
request as if called for a result
* Handling stopping of a user to clean up in-memory state as
well as handling when a user gets unlocked as a provider may
be non-direct boot aware
* User the correct context when creating an auto-fill manager
* Move the receiver that listens for requests to hide system
windows to the manager service as the UI is a singleton and
no need every per-user state to register its own
* Removed extras from dataset as the only case a provider needs
to associate state with a dataset is for auth and the provider
can embed this data in the auth pending intent
Test: manual and CTS
Change-Id: I4bc54c13cf779d7f6fdb3ab894637f9fac73f603
/frameworks/base/core/java/android/service/autofill/FillCallback.java
|
| 0f4928f1f73407485d6d94beda1dba1a2360ebbf |
|
03-Feb-2017 |
Svet Ganov <svetoslavganov@google.com> |
Refactoring of auto fill - lifecycle, auth, improvements
1. Move management of the remote fill service in a dedicated
class that abstracts away the async and ephemeral nature
of the binding.
2. Update auth to move fingerprint out of the platform and
allow response and dataset auth.
3. Cleaned up the fill and save callback classes.
4. The UI is now shared among all sessions and cleaned up.
5. Reshuffled the remote callbacks to have cleaner separation.
6. Cleaned up and tightened the reponse and dataset classes.
7. Added API to support communicationn with intent based auth.
Test: CTS + manually
bug:31001899
Change-Id: Idc924a01d1aea82807e0397ff7293d2b8470d4d6
/frameworks/base/core/java/android/service/autofill/FillCallback.java
|
| 436ab6a91d64ef6036c67bb361d807e398fb2c4c |
|
15-Dec-2016 |
Felipe Leme <felipeal@google.com> |
Added support to authentication.
AutoFillService can now require user authentication, both at
FillResponse and Dataset levels;
- FillResponse authentication is typically used when the user data
need to be unlocked before the first use.
- Dataset authentication is typically used to unlock sensitive data
such as credit card info.
The authentication can be handled by the service itself (for example,
when it uses the credit card CVV to unlock it) or by the Android
system (when the service asks for fingerprint authentication).
Bug: 31001899
Test: manual verification
Test: CtsAutoFillServiceTestCases passes
Change-Id: If62f42f697ab5ef0d14d991ff1077d1c38808e61
/frameworks/base/core/java/android/service/autofill/FillCallback.java
|
| 3461d3c069468e176fab6bc8b8e78c8e6bc81e8b |
|
19-Jan-2017 |
Felipe Leme <felipeal@google.com> |
Initial IME integration.
- Created an AutoFillManager class, which provides methods to show
the auto-fill bar for views and virtual nodes.
- Automatically launches an auto-fill request when the IME is shown
(and an AutoFillService is set for the given user) on TextViews.
- Updated VirtualNodeListener to use this new API.
BUG: 31001899
BUG: 34171325
Test: CtsAutoFillServiceTestCases passes
Test: manual verification
Change-Id: Id72ce97da70217081b5823cfc7b138412634fcf3
/frameworks/base/core/java/android/service/autofill/FillCallback.java
|
| 6d553874bed06280766ae24ea605f9bbde3f5a4a |
|
09-Dec-2016 |
Felipe Leme <felipeal@google.com> |
YAMAFFR - Yet Another Major AutoFill Framework Refactoring
- Explicitly split View methods into Assist and AutoFill methods, rather
than use an overloaded method that takes flags.
- Simarly, renamed ASSIST_FLAG_SANITIZED_TEXT and
ASSIST_FLAG_NON_SANITIZED_TEXT flags to
AUTO_FILL_FLAG_TYPE_FILL and AUTO_FILL_FLAG_TYPE_SAVE respectively.
- Created a AutoFillUI class to host the auto-fill bar and other UI
affordances.
- Moved the temporary notifications to AutoFillUI (eventually that
class will host the real UI).
- Moved FillData to android.app.view.autofill package.
- Split IAutoFillCallback in 2 (IAutoFillAppCallback and
IAutoFillServerCallback, residing at the app and system_server
respectively), so service cannot fill the app directly (which lets
the framework control the UI).
- Moved assist's IResultReceiver to AutoFillServiceImpl so
system_server can act as a mediator between the AutoFillService
implementation and the app being auto-filled.
- Replaced FillData and FillableInputFields by a bunch of new objects:
- FillResponse contains a group of Datasets, each representing
different values
that can be used to auto-fill an activity (for example, different
user accounts), optional id of fields the service is interested
to save, and an optional bundle for service-side extras.
- Dataset contains a name, Fields, and an optional bundle for
service-side extras.
- Fields contain an AutoFillId (parcelable) and a value (Bundle)
- Changed the temporary notifications to emulate the new workflow:
- Initial notification requests the auto-fill data but do not
auto-fill.
- Once service calls back, a new notification is shown with the
results.
- Then if the user selects a dataset, the activity is auto-filled
with it.
- It also shows a notification to emulate what can be saved.
- Created an VirtualViewDelegate for views that uses a virtual
hierarchy for assist data.
- Added new methods on ViewStructure to add children with virtual ids.
- Added 2 methods on View to support auto-fill:
- autoFill(Bundle) to auto-fill the view.
- getAutoFillType() to return how the view can be auto-filled.
- AutoFillType defines the input fields that support auto-fill:
- Text fields (like EditText)
- Toggle fields (like CheckBox)
- Lists (like RadioGroup)
- AutoFillType can also have a sub-type representing its semantic (for
now only text fields have it, and it's the same as getInputType()).
- etc :-)
Bug: 31001899
Test: manual verification
Change-Id: I2dd2fdedcb3ecd1e4403f9c32fa644cb914e186f
/frameworks/base/core/java/android/service/autofill/FillCallback.java
|
| 1ca634a544a47193dd9e57f9b3eb3e42ab0dbbf1 |
|
29-Nov-2016 |
Felipe Leme <felipeal@google.com> |
AutoFill Framework refactoring.
The AutoFill Framework uses the same AssitStructure provided by the Assist API
and so far it was using the same methods as well, both internally and externally
(public API).
Sharing that internal code internally is fine, but the public APIs must distinguish between the 2 cases so they can fill the assist structures accordingly (although the initial implementation still shares the same logic).
This CL also splits the original 'auto-fill' request in 2 types of requests,
which are set by View flags:
- ASSIST_FLAG_SANITIZED_TEXT
- ASSIST_FLAG_NON_SANITIZED_TEXT
It also added new methods and callbacks to handle save requests.
Bug: 31001899
Test: manual verification
Change-Id: I4eb09099dc19a43cb7e053e64d939aed3704b410
/frameworks/base/core/java/android/service/autofill/FillCallback.java
|
| dfa7fbc8702fae62e6b3f78c4d9245995baee04e |
|
11-Nov-2016 |
Felipe Leme <felipeal@google.com> |
Bind AutoFillService on demand.
BUG: 31001899
Test: manually built and ran it
Change-Id: Ied7028e41c273f5e30f88fc92f919249046877eb
/frameworks/base/core/java/android/service/autofill/FillCallback.java
|
| 29a5b0d0f1cc7fd6cbfe97c816b8a687d9e438cc |
|
25-Oct-2016 |
Felipe Leme <felipeal@google.com> |
Added a callback for AutoFillService.
So far AutoFillService only received the assist data from framework; in
this CL, it also offers a method where the auto-fill provider can send
the auto-fill data back to framework.
The workflow is:
- AFMSI calls a new AM method (requestAutoFillData(), instead
of requestAssistContextExtras()).
- The assist receiver is located in the app, not on system service.
- AM uses a new request type (ASSIST_CONTEXT_AUTOFILL) to request the
assist data to the activity.
- ViewStructure has a new setAutoFillId() method which is used to set an
unique id for the view.
- View uses the accessibility id to implement the auto-fill id.
- When the activity fullfills the request, it creates an IAutoFillCallback
remote object - that will be used to set the auto-fill fields - and
returns it in the assist bundle (using the
VoiceInteractionSession.KEY_AUTO_FILL_CALLBACK key).
- The app-visible AutoFillService class offers an onFillRequest() method,
which contains the assist data and a FillCallback used to handle it.
BUG: 31001899
Test: manually built and ran it
Change-Id: I3d208c14e81022dc96dd03f38bbe25a778b24a67
/frameworks/base/core/java/android/service/autofill/FillCallback.java
|