- Introduces getLogger() API.
- A logger should run in the client's process. This helps us manage
sessions specific to a client.
- The logger exposes a tokenizer that clients may use to tokenize
strings for logging purposes.
- Logger subclasses need to provide a writeEvent() implementation.
- SelectionEvent is serializable over IPC.
- Logger takes care of the session management. It writes session
specific information into the SelectionEvent.
- We still keep the SmartSelectionEventTracker for now so clients
can slowly move off of it. The plan is to delete it.
- The plan is to include support other event types. e.g. link events.
Bug: 64914512
Bug: 67609167
Test: See topic
Change-Id: Ic9470cf8f969add8a4c6570f78603d0b118956cd
Uses the TextClassifier to generate links on a background thread.
The links are applied on the calling thread.
Test: see topic
Bug: 67629726
Change-Id: I0f1940a2ffbf19f4436c0a20b0c62e6bbc03cd7a
This reverts commit 5564f880db.
Reason for revert: Resolve merge conflict for another revert (ag/3537193)
Bug: 72710855
Change-Id: Id7c3a3993a45c588ee4668d7486d67d764541b1e
This change removes deprecated classes and constants that were not
renamed from ephemeral to instant prior to O. There were no
consumers of these APIs as correctly named alternatives existed and were
referenced in docs. No known consumers of these APIs exist on user
builds.
Fixes: 38137176
Fixes: 38121489
Test: manual; builds and instant apps launch
Change-Id: I982f8a6edc5668dd42cea65e52a1433ec8d6f8ef
This CL adds new Framework APIs that can be used for the secure
confirmations. This includes support for configuring a key such that
it can only sign data returned by the confirmation APIs.
Bug: 63928580
Test: Manually tested.
Change-Id: I94c1fc532376bd555b3dc37fc4709469450cfde6
* changes:
Modify ImsService API to accomodate compat
Make ImsService API @SystemApi
Integrate new MMTel APIs into the framework
Integrate ImsCallSessionListener API changes
The CL adds the Magnifier#update() method in the public API. The method
is used to refresh the content of the magnifier, whenever this is
desired (usually when there is a chance that the magnifier content
became stale).
The initial plan was that this method would not be included in the
public API. This was relying on a feature request we made to the
graphics team, asking for support to have a callback called whenever the
surface the magnifier is attached to changes. This way, we could
refresh the magnifier content whenever the surface changes, without
requiring the user to call #update(). Once the feature request is
implemented (probably in Q according to the last discussion), we will be
able to deprecate #update().
Bug: 63531115
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: I62c5794c3227e6a5d36d351c10d6bcf18e1d931a
Apps wanting to use a TextClassifier service (instead of an
in-app-process TextClassifier) bind to this service. The service
binds to and reroutes calls to a configured system TextClassifierService.
TextClassifierManagerService manages the lifecycle of the configured
TextClassifierService and binds/unbinds to preserve system health.
A configurable TextClassifierService extends TextClassifierService,
declares an android.textclassifier.TextClassifierService intent, and
requires a permission that is only granted to the system so only the
system may bind to it.
The TextClassifierManagerService implements a similar interface to
TextClassifierService (i.e. ITextClassifierService) but doesn't have to.
This is done for simplicity sake and things may change in the future.
The configuration of the default service is in config.xml.
OEMs may change this with a config overlay.
If no TextClassifierService is specified, the default in app process
TextClassifierImpl is used.
Bug: 67609167
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: tbd
Change-Id: I8e7bd6d12aa1a772897529c3b12f47f48757cfe6
These APIs are useful when an app uses a date value for a credit card
expiration date.
Test: atest CtsAutoFillServiceTestCases:DateValueSanitizerTest \
CtsAutoFillServiceTestCases:DateTransformationTest \
CtsAutoFillServiceTestCases:CustomDescriptionDateTest
Fixes: 72450441
Change-Id: Ie17ab17aa07e0401f4dbba3faa80cc2cc2e7d783
Add a keymaster parameter for keys that should be inaccessible when
the device screen is locked. "Locked" here is a state where the device
can be used or accessed without any further trust factor such as a
PIN, password, fingerprint, or trusted face or voice.
This parameter is added to the Java keystore interface for key
creation and import, as well as enums specified by and for the native
keystore process.
Test: go/asym-write-test-plan
Bug: 67752510
Change-Id: I8b88ff8fceeafe14e7613776c9cf5427752d9172
For devices that use the config_handleVolumeKeysInWindowManager
configuration, add API to receive volume key-related events
directly, without them being processed by the framework
(already not received by apps).
Bug: b/63906162
Test: set config_handleVolumeKeysInWindowManager, use
"adb shell dumpsys audio" to verify adjustVolume methods aren't
logged
Change-Id: I432b14fa9980764d69077b9f1b23b8c95f30814d
Allow for more flexiblity in case the maximum shared
supported shared surface count changes in the future.
Bug: 72562887
Test: Camera CTS
Change-Id: If3be8659c05997502368f51a14152a4516a9f159
Bug: 63117034
Change-Id: Ie3818e913e8e1077f60434a626bc606c0b5015ab
Test: Manual using test app at google_experimental/users/patb/InstantAppsInP
Test: atest android.appsecurity.cts.EphemeralTest passes after modification
This permission would gate if an application is eligible to receive
notifications about nfc transactions taking place on the Secure
Elements.
Bug: 72556384
Test: Test dummy notifications on sample app.
Change-Id: I233f7185bbc3a5511f79ae012cc60a081968eb99
Freeze period is defined as a pair of calendar dates (recurring annually)
during which the system should block any incoming system updates, including
security patches. They are set on top of existing system udpate policy
types (automatic, windowed, postpone) such that outside the freeze
periods existing policy semantics will still apply. They are created to
allow admin to keep their device fleet from any destabilizing changes during
critical period of the year, for example during Christmas sales period.
Device Owner can set several freeze periods, although to prevent the device
from not receiving OTAs indefinitely, each single freeze period is
restricted to be at most 90 days, and adjacent freeze periods need to be at
least 60 days apart. To properly enforce these restrictions, any freeze
periods the device previously experienced is tracked by DevicePolicyManager
and are validated against any new policy. This is to deal with corner cases
such as the admin repeatedly set a short but overlapping freeze period on a
rolling basis, hence bypassing the 90-day freeze period restriction.
Test: runtest -c com.android.server.devicepolicy.SystemUpdatePolicyTest frameworks-services
Bug: 64813061
Change-Id: I2864192797dc194edd9c183b881da6cfe3fdba5e
