Lines Matching defs:service
16 package android.service.autofill;
24 import android.app.Service;
41 * An {@code AutofillService} is a service used to automatically fill the contents of the screen
62 * <li>The Android System binds to the service and calls {@link #onConnected()}.
63 * <li>The service receives the view structure through the
65 * <li>The service replies through {@link FillCallback#onSuccess(FillResponse)}.
68 * <li>The Android System displays an autofill UI with the options sent by the service.
73 * <p>This workflow was designed to minimize the time the Android System is bound to the service;
74 * for each call, it: binds to service, waits for the reply, and unbinds right away. Furthermore,
75 * those calls are considered stateless: if the service needs to keep state between calls, it must
76 * do its own state management (keeping in mind that the service's process might be killed by the
92 * account in the service, the response could be:
118 * <p>If the service does not find any autofillable view in the view structure, it should pass
119 * {@code null} to {@link FillCallback#onSuccess(FillResponse)}; if the service encountered an error
121 * performance reasons, it's paramount that the service calls either
129 * <p>If the service is also interested on saving the data filled by the user, it must set a
136 * <p>The service can provide an extra degree of security by requiring the user to authenticate
151 * the authentication flow, and the service can decrypt the sensitive data.
153 * <p>The authentication mechanism can also be used in scenarios where the service needs multiple
160 * <li>When the user selects the fake dataset, the service displays a dialog with available
162 * <li>When the user select a banking app, the service replies with a new {@link FillResponse}
166 * <p>Another example of multiple-steps dataset selection is when the service stores the user
194 * number, the service would be providing a visual clue for the users to check what would be
197 * <p>When the service detects that a screen has multiple partitions, it should return a
205 * <p>Notice that when the user autofill a partition with the data provided by the service and the
206 * user did not change these fields, the autofilled value is sent back to the service in the
209 * cases where the service must create datasets for a partition based on the choice made in a
229 * <p>Then if the user selected {@code flanders}, the service would get a new
231 * the fields {@code id1} and {@code id2} prepopulated, so the service could then fetch the address
247 * <p>When the service returns multiple {@link FillResponse}, the last one overrides the previous;
253 * <p>When autofilling app-specific data (like username and password), the service must verify
280 * <p>If the service did not store the signing certificates data the first time the data was saved
282 * use the Autofill Framework — the service should warn the user that the authenticity of the
285 * then the service could save the data from the signing ceriticates for future use.
290 * <p>If the service find views that cannot be autofilled (for example, a text field representing
301 * is a {@link android.webkit.WebView}), the service should take the following steps to verify if
331 * above, but the service thinks that it is appropriate to fill persisted credentials that are
332 * stored for the web domain, the service should warn the user about the potential data
333 * leakage first, and ask for the user to confirm. For example, the service could:
343 * requesting credentials for a web domain, but the service could not verify if the app owns
344 * that domain. If the user agrees, then the service can unlock the dataset.
345 * <li>Similarly, when adding a {@link SaveInfo} object for the request, the service should
357 * that request, the service could add an
360 * "Password for some_bank.com". Then when the user taps one of these options, the service
363 * then the service returns an unlocked dataset with the {@code some_bank.com} credentials.
365 * <p><b>Note:</b> The autofill service could also whitelist well-known browser apps and skip the
366 * verifications above, as long as the service can verify the authenticity of the browser app by
376 * <p>It's tricky to handle save for autofill in these situations, because the autofill service must
382 * {@link #onFillRequest(FillRequest, CancellationSignal, FillCallback) fill request}, the service
386 * {@link #onFillRequest(FillRequest, CancellationSignal, FillCallback) fill request}, the service
391 * <li>In the {@link #onSaveRequest(SaveRequest, SaveCallback) save request}, the service uses the
453 * email address), the service should only use it locally (i.e., in the app's process) for
459 * <p>The service can call {@link #getFillEventHistory()} to get metrics representing the user
463 * scenarios where the service knew how to autofill an activity, but Android
465 * which allows the service to dinamically classify the meaning of fields based on the existing user
466 * data known by the service.
470 * address. Once the service identifies that a such field was manually filled by the user, the
471 * service could use this signal to improve its heuristics on subsequent requests (for example, by
478 * cached until the system restarts (or the service is disabled), so it doesn't need to be set for
489 * in cases where the service could not determine how an activity can be autofilled, but it has a
514 * associated with your service. Below is a sample service declaration:
516 * <pre> <service android:name=".MyAutofillService"
519 * <action android:name="android.service.autofill.AutofillService" />
522 * </service></pre>
527 * <pre> <autofill-service xmlns:android="http://schemas.android.com/apk/res/android">
529 * </autofill-service></pre>
547 * Such browsers typically offer an option for users to disable autofill, so your service should
552 public abstract class AutofillService extends Service {
556 * The {@link Intent} that must be declared as handled by the service.
557 * To be supported, the service must also require the
562 public static final String SERVICE_INTERFACE = "android.service.autofill.AutofillService";
568 * android.R.styleable#AutofillService autofill-service}></code> tag.
570 * <pre> <autofill-service
626 * Called when the Android system connects to service.
634 * Called by the Android system do decide if a screen can be autofilled by the service.
636 * <p>Service must call one of the {@link FillCallback} methods (like
652 * Called when the user requests the service to save the contents of a screen.
654 * <p>Service must call one of the {@link SaveCallback} methods (like
658 * <p>If the service could not handle the request right away—for example, because it must
660 * down—the service could keep the {@link SaveRequest request} and reuse it later,
661 * but the service must call {@link SaveCallback#onSuccess()} right away.
663 * <p><b>Note:</b> To retrieve the actual value of fields input by the user, the service
677 * Called when the Android system disconnects from the service.
679 * <p> At this point this service may no longer be an active {@link AutofillService}.
690 * requests. For example, the service might return email addresses in alphabetical order by
693 * <p>The history is not persisted over reboots, and it's cleared every time the service
696 * (if the service doesn't call any of these methods, the history will clear out after some
697 * pre-defined time). Hence, the service should call {@link #getFillEventHistory()} before
