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/IFillCallback.aidl
|
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/IFillCallback.aidl
|
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/IFillCallback.aidl
|
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/IFillCallback.aidl
|