Tracking SurfaceFlinger changes. Now to construct a child surface
we need the SurfaceControl as opposed to just the surface, and so
we parcel the SurfaceControl across relayout.
Test: Manual
Bug: 62536731
Bug: 111373437
Bug: 111297488
Change-Id: I0a034767e92becec63071d7b1e3e71b95d505b77
Members modified herein are suspected to be false positives: i.e. things
that were added to the greylist in P, but subsequent data analysis
suggests that they are not, in fact, used after all.
Add a maxTargetSdk=P to these APIs. This is lower-risk that simply
removing these things from the greylist, as none of out data sources are
perfect nor complete.
For APIs that are not supported yet by annotations, move them to
hiddenapi-greylist-max-p.txt instead which has the same effect.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: I020a9c09672ebcae64c5357abc4993e07e744687
Expand the wallpaper color listener for multiple displays. This will
allow the launcher on the secondary display can also receive the
correct wallpaper color.
Bug: 115486823
Test: atest WallpaperManagerTest
Test: atest ActivityManagerMultiDisplayTests
Change-Id: I3d893537a8c606170b5641c9eb4683d09743d80c
- Check consolidated zen policy in volume dialog, seek bar volumizer
and ZenModeControllerImpl instead of default notification policy
- Save ZenPolicy changes on restore
Test: atest ZenModeHelperTest
Test: atest ZenModeControllerImplTest
Bug: 111475013
Change-Id: I43b6dc8c6453739c50c874fe37415d425223d8c4
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
The initial implementation was using a batch the events to optimize the
performance, but that can be optimize behind the scenes (i.e., we can still
send the batches in the binder, but deliver them one by one).
This change not only makes it easier for the service to use the API, but it
paves the way to implement multiple sessions (so we can buffer children events
while the parent session is not completely started yet).
Bug: 121033016
Bug: 117944706
Bug: 121051220
Test: atest CtsContentCaptureServiceTestCases
Change-Id: I713ceb998bd81733255fd3ef8d0b8d7a3fcac20c
This is just a refactoring for now, but it paves the way to support children
sessions.
Bug: 121042846
Bug: 117944706
Test: atest CtsContentCaptureServiceTestCases
Change-Id: I64bb5562dcfd4a9f0f69bb13009e4cf47a4f3b37
Resolvable errors in the download step are present in a bit map and
returned to the calling app. The calling app can resolve all the
resolvable errors at one time.
Also pass cardId around for future use.
Bug: 68941776
Test: test on phone
Change-Id: I37a365bce2eb183161a2649ca8098504b6ed2370
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
And replace it with something more battery friendly!
Test: CTS, runtest systemui-notification
Bug: 111474881
Change-Id: I45af94135fb8d2de050d5f7baaa9724b95bb1907
Provide an API that let the Engine get the corresponding display context.
As a result, wallpaper developers can easily get the right resources.
Bug: 115486823
Test: atest WallpaperManagerTest
Change-Id: I9ec85028331c2d2e4445b9a47ee05dc311a8e3e7
- 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
Whenever NAS called TextClassifier.suggestConversationActions,
it will cache the notification key to result id mapping.
The result id will be used to log subsequent events related to
these suggestions.
This change should allow us to collect CTR.
TODO: Log the coverage, i.e. among all suggestConversationActions
request, how many of them actually contains some suggestions.
BUG: 120803809
Test: atest SmartActionHelperTest
Test: Manual, add a log in TextClassifierImpl.onTextClassifierEvent
1. Send a message notification
2. Expand the notification, observe event is logged.
4. Clicked on one of the replies, observe event is logged.
5. Send another message to myself
6. Inline reply it, observe event is logged.
Change-Id: I590d9bfcdb7ae7ee7976740d71bf7f1204683939
This serves as a general TextClassifier event object for reporting
any textclassifier event and will replace the SelectionEvent class.
Example:
// Smart link clicked.
new TextClassifierEvent.Builder(CATEGORY_LINKIFY, TYPE_LINK_CLICKED)
.setEventContext(new TextClassificationContext.Builder(
pkgname, WIDGET_TYPE_TEXTVIEW)
.build())
.setEntityType(TextClassifier.EMAIL)
.setResultId(textclassification.getId())
.setEventIndex(0)
.setEventTime(now)
.setStart(0)
.setEnd(3)
.build();
Bug: 120837847
Test: See related cts CL
Test: atest cts/tests/tests/view/src/android/view/textclassifier/cts \
frameworks/base/core/tests/coretests/src/android/view/textclassifier
Change-Id: Ifd84a45fc5c46ffdb200dcb9600f6a470ce792bb
Everything that is marked SystemApi or TestApi, but not @hide is still
part of the public SDK, it is therefore not sound to have that combination.
In the future, specifing such a combination will be considered an error
to prevent inadvertently exposing SystemApi and TestApi as public API.
Bug: 115333477
Change-Id: Ibd5d6a22862fdbc1e20a1cb3925280f5a682edea
Test: METALAVA_PREPEND_ARGS="--error UnhiddenSystemApi" m checkapi
Exempt-From-Owner-Approval: API cleanup
1. expose public API for preciseCarrierId and preciseCarrierIdName
2. expose public API for carrier id in CarrierIdentifier
3. New public broadcast for precise carrier identity changed
4. clean up
Bug: 110559381
Test: unit test & atest CtsTelephonyTestCases:TelephonyManagerTest
Change-Id: I18f8bc3252632bba699829c6c577d1041335fee9
- Do not run signal extractors on enqueued notifications - the
assistant isn't told that information and the information that
the extractors base their decisions on it's final. Instead,
extract signals in the post runnable, before the sort/before we
generate the notification update for listeners
- Ignore importance adjustments sent from onNotificationEnqueued
that arrive after the notification was posted, because it's too
late to cancel the notification or silence it.
- Also fix a bug in the handling of importance adjustments
that are sent via adjustNotification: *listen* to the comment that says
'any field that can be changed in an extractor needs to be handled
in handleRankingSort'
Change-Id: I1603d6c5701fcc16f038231e22e21565dd366572
Fixes: 120601946
Test: atest, manual
Originally one field classification algorithm was used to classify every
field. The change allows different category of fields to be classified
by different field classification algorithms.
Change-Id: I27205a4096774d6e0c0d56da5e0fd38dda995d8f
Fixes: 118681526
Test: atest CtsAutoFillServiceTestCases
Test: atest android.autofillservice.cts.FieldsClassificationTest
Bunch of changes:
- Split public SmartSuggestionsService info ContentCaptureService and
AugmentedAutofillService
- Renamed 'intelligence' packages to either 'contentcapture' or
'autofil.augmented'
- Renamed internal packages and classes.
- Changed permissions, resource names, etc...
- Moved Augmented Autofill logic from IntelligeceManagerService (R.I.P.) to
Autofill.
- Optimized IPCs by passing a String instead of the InteractionSessionId
(that also solves the view -> service dependency).
Test: atest CtsContentCaptureServiceTestCases \
CtsAutoFillServiceTestCases \
FrameworksCoreTests:SettingsBackupTest
Test: manual verification with Augmented Autofill Service
Bug: 119638877
Bug: 117944706
Change-Id: I787fc2a0dbd9ad53e4d5edb0d2a9242346e4652d
- Send the initial value of the focused field, so the service can decide whether
or not to display the autofill UI if it's not empty.
- Log how long it took for the service to handle the request and to hte system
to render the UI.
- Use CloseGuard to make sure the UI is properly destroyed.
Bug: 120303290
Bug: 119638877
Test: manual verification
Change-Id: I7abed10c0915ff9a2deddb488c70e1491cdbd480
AbstractRemoteService was spun off from RemoteFillService, which only supports
1 pending request while not bound to the service - if a new request comes,
it cancels the previous one.
This behavior is fine for Autofill, but for Content Capture all requests must be
queued. In fact, the upcoming CTS tests for Content Capture were failing because
the 1st PendingOnContentCaptureEventsRequest would cancel the pending
PendingSessionLifecycleRequest.
So, this CL fix this problem by creating 2 subclasses:
- AbstractSinglePendingRequestRemoteService
- AbstractMultiplePendingRequestsRemoteService
Test: atest CtsContentCaptureServiceTestCases CtsAutoFillServiceTestCases
Bug: 111276913
Bug: 117779333
Change-Id: I43bb98be16f5def037f85a415e1f77799adf156e
