This is useful for long-lived activities (like a browser), so child session can still be reported
after the service is restarted after dying.
Test: manual verification (cannot be tested using CTS because it would kill the test process)
Test: atest FrameworksCoreTests:android.view.contentcapture.ContentCaptureEventTest
Test: m update-api
Bug: 128466656
Change-Id: I9310263e897e929189d323d31853592a374dc6e0
This allows us to expose both system-only and app available APIs for
role in RoleControllerService.
Bug: 127691087
Test: manual
Change-Id: I86fe3736fc28516aae25d48efe3ba599ffdf45d5
This API is needed for high-level events that happened on activities that are
not whitelisted for Content Capture.
Test: atest CtsContentCaptureServiceTestCases:android.contentcaptureservice.cts.LoginActivityTest#testSimpleLifecycle_defaultSession
Test: atest CtsContentCaptureServiceTestCases # sanity check
Test: m update-api
Bug: 126262658
Change-Id: Id2d4ccfb04d56eba561200d6875374a932c526ae
- Use 1/0 instead of true/false for the settings value.
- Improved logging / internal logic by splitting disabled by settings and device config.
- Other minor fixes.
Test: atest CtsContentCaptureServiceTestCases
Bug: 119264902
Change-Id: I51b99588f823c4e1eaf496841efd45757e4258be
Also split some logic from PendingRequest into BasePendingRequest, so they're
not leaked into the async requests.
Test: atest CtsContentCaptureServiceTestCases CtsAutoFillServiceTestCases
Bug: 117779333
Change-Id: Ife9a3ab3a817944408caf9eae69dd75f48ab90c6
Content Capture for an activity and/or package is only available when the Content Capture service
explicitly whitelists it. As the whitelist is kept at system-server level, it's better to fetch that
info when the application is started and cache it locally, so we can optimize the
ContentCaptureManager APIs to return quickly when it's disabled.
This CL also caches other values such as the buffer parameters.
Test: atest CtsContentCaptureServiceTestCases
Bug: 120494182
Bug: 121202151
Change-Id: I9d5211bca496ffa85ba9efc2a7bb32411834b787
To re-enable, it will need to launch a Settings intent
(Settings.ACTION_REQUEST_ENABLE_CONTENT_CAPTURE).
Bug: 123286662
Test: atest CtsContentCaptureServiceTestCases
Change-Id: I0dd03013aba645c188af4034e530492d8294180e
For now it only whitelists packages, not activities.
Test: atest CtsContentCaptureServiceTestCases
Bug: 122595322
Change-Id: I5beb9b027eb704510e68f3af15e84e14bda07eb2
Prior to this change, it would only be disabled on boot.
Test: atest ChildlessActivityTest#testSetContentCaptureFeatureEnabled_disabledByDeviceConfig \
ChildlessActivityTest#testSetContentCaptureFeatureEnabled_disabledThenReEnabledByDeviceConfig
Test: atest CtsContentCaptureServiceTestCases
Bug: 123931489
Change-Id: I9230574db3ee85ba95951a3d9329c96f4e84a87e
Otherwise a bunch of CTS tests fail when the OEM sets a default service.
Test: atest CtsContentCaptureServiceTestCases
Fixes: 123952975
Change-Id: Ia172fbde6670fc5f125425f9dc92a34e8cdfdaed
It should be infered on the server side..
Bug: 123516968
Test: atest CtsContentCaptureServiceTestCases
Change-Id: If6ccf2fa86adb55f43c4b3ffa8b58661ef16dabb
This binder object will be used to implement the ContentCaptureService methods that require calls to
system server.
Bug: 122595322
Test: atest CtsContentCaptureServiceTestCases
Change-Id: If918af540f78777d00970e0fc75df458aad168b7
Tests are in ag/5989968
Fixes: 121047489
Test: atest CtsContentCaptureServiceTestCases # to make sure nothing broke
Test: atest
CtsContentCaptureServiceTestCases:android.contentcaptureservice.cts.BlankActivityTest#testTargetServiceName_enabled
Test: google3 test with test app
Change-Id: I4f11a324beb938a28cd150c35bb3d83c77e59e0b
Long-story short, they must be flushed right away...
Test: atest CtsContentCaptureServiceTestCases
Bug: 121033016
Change-Id: I1b3132ad49674d43bf63717f79848b6e4b23b605
The initial implementation of AbstractPerUserService assumed the
AbstractRemoteService instances would be created in demand, because that was
the aproach used by Autofill (to minimize the time system service is bound to
the autofill service process).
But for other systems like ContentCapture, it makes more sense to keep a
permanent connection to the remote service, which is running all the time, so
this change changes the infra to allow such permanent connection (which includes
defining an idle timeout value that never unbinds).
Bug: 117779333
Test: atest CtsContentCaptureServiceTestCases CtsAutoFillServiceTestCases
Change-Id: I43386a3fddc56f1dfd6e4e55f243eaa297921123
This object is used to bind to the AbstractRemoteInstance and was initially used by
AbstractPerUserSystemService, as the concrete implementations (for Autofill and ContentCapture)
were binding when sessions were created.
But we also need to support binding when the service is created, which was not possible using this
approach; instead, we need to make this object to take the userId on each call, and move it to the
AbstractMasterSystemService.
This change also removed the shared lock from FrameworkResourcesServiceNameResolver.
Bug: 117779333
Test: atest CtsContentCaptureServiceTestCases CtsAutoFillServiceTestCases
Change-Id: I097c226c9b00ddf7827e4f2f99d0adba978f29a2
Such move will allow nested sessions. For example, WebView could create a
new session for the main page, then child sessions for IFRAMEs contained on it.
This CL changes the API and provides an initial implementation, although it's
not quite ready yet - it only allows 1 level of children (from the activity
session), but the full implementation is coming soom to a movie theather near
you...
Bug: 121033016
Bug: 117944706
Test: atest CtsContentCaptureServiceTestCases
Change-Id: I86156bb3b8a2c08cb00b9518599eb6d67fbf77c2
Initially, the ContentCaptureManager (in the app) was calling the
IContentCaptureManager (on system server) for everything, even to pass the
list of captured events, which caused 2 IPCs for each batch of events (i.e.,
from app to system_server, then from system_service to service).
This CL optimizes the workflow by getting rid of the "middle man" and sending
the events from the app to the service directly, which the system_server only
calling the service to notify when the view starts and finishes (and passing
the UID in the former so the servier can validate the sendEvents() calls).
Bug: 119220549
Test: atest CtsContentCaptureServiceTestCases
Change-Id: I6c08dccf755605320ac37cbc9424132e5455a594
- Get rid of activity-level events.
- Renamed InteractionSessionId and InteractionContext to
ContentCaptureSessionId and ContentCaptureContext (and made them public)
- Create the explicit concept of ContentCaptureSesssion (and moved notification
APIs to it).
- Added APIs to let apps create new sessions (not implemented yet).
- Added APIs to remove user data based on some context properties (like URI).
The reasoning behind this change is to let app developers explicitly associate
the captured content with some app-level domain (and also let the app ask the
service to clear such data at user's request). For example, a browser app
(and WebView) can use these APIs to associate the content capture events with
the URL being rendered.
Bug: 117944706
Fixes: 121034139
Test: atest CtsContentCaptureServiceTestCases
Test: m update-api && m
Change-Id: I7841da303b6a39c825651b03a07e3081fbd0bdf5
In these cases the request never times out, so it can be simplified by using
a lambda to represent the request.
Bug: 117779333
Test: atest CtsContentCaptureServiceTestCases CtsAutoFillServiceTestCases
Change-Id: Iba52aad1315ae7d3982671a0fdeabe87a6d6ee04
