This CL addresses a typo in the JavaDoc of IMM#toggleSoftInput(),
which has prevented it from being treated as a valid JavaDoc.
Note that this CL removes @hide simply because it is too late. The
method in question has already been exposed to developers since API
level 3 (Cupcake) because of the typo.
Bug: 13002424
Test: make -j doc-comment-check-docs
Change-Id: I3e42d433f20c56ee63373bb390aad59e3bd7ec4f
Autofill helps users fill credentials, addresses, payment methods,
emails, etc without manually typing. When focus lands on a fillable
element the platform captures a snapshot of the screen content and
sends it to an autofill service for analysis and suggestions. The
screen snapshot is a structured representation of the screen content.
If this content is composed of standard widgets, autofill works
out-of-the-box. However, some apps do their own rendering and
the content in this case looks like a single view to the platform
while it may have semantic structure. For example, a view may render
a login page with two input test fields.
The platform exposes APIs for apps to report virtual view structure
allowing autofill services to handle apps that have virtual content.
As opposed to apps using standard widgets, this case requires the app
developer to implement the new APIs which may require a fair amount
of code and could be seen as a processes that could take some time.
The most prominent typs of apps that fall into this category are
browsers.
Until most apps rendering virtual content and specifically browsers
don't implement the virutal APIs, autofill providers need to fall-
back to using the accessibliity APIs to provide autofill support
for these apps. This requires developers to work against two sets
of APIs - autofill and accessibility - which is incovenient and error
prone. Also, users need to enable two plugins - autofill and
accessibility which is confusing. Additionally, the privacy and
perfomance impact of using the accessibility APIs cannot be addressed
while autofill providers need to use thes APis.
This change adds an autofill compatibility mode that would allow
autofill services to work with apps that don't implement the
virtual structure autofill APIs. The key idea is to locally enable
accessibility for the target package and remap accessibility to
autofill APIs and vise versa. This way an autofill provider codes
against a single set of APIs, the users enable a single plugin,
the privacy/performance implications of using the accessibility
APIs are addressed, the target app only takes a performance hit
since accessibility is enabled locally which is still more efficient
compared to the performance hit it would incur if accessibility is
enabled globally.
To enable compatibility mode an autofill service declares in its
metadata which packages it is interested in and also what is
the max version code of the package for which to enable compat
mode. Targeted versioning allows targeting only older versions of
the package that are known to not support autofill while newer
versions that are known to support autofill would work in normal
mode.
Since compatibility mode should be used only as a fallback we
have a white list setting with the packages for which this mode
can be requested. This allows applying policy to target only
apps that are known to not support autofill.
Test:
cts-tradefed run cts-dev -m CtsAutoFillServiceTestCases
cts-tradefed run cts-dev -m CtsAccessibilityServiceTestCases
bug:72811034
Change-Id: I11f1580ced0f8b4300a10b3a5174a1758a5702a0
The majority of Manager-style classes already use Context.getUserId()
when making calls into the OS, so clean up the remaining callers to
unify behind this strategy.
This gives @SystemApi developers a nice clean interface to interact
across user boundaries, instead of manually adding "AsUser" or
"ForUser" method variants, which would quickly become unsustainable.
Test: builds, boots
Bug: 72863821
Exempt-From-Owner-Approval: trivial changes
Change-Id: Ib772ec4438e57a2ad4950821b9432f9842998451
Don't scale NinePatchDrawable if bitmap has no density.
Fixed bugs around density and input streams.
Update PointerIcon to account for the fact that BitmapDrawable no longer
scales its Bitmap up at decode time. PointerIcon now handles the
scaling. This is necessary because PointerIcon never draws its Bitmap.
Instead, native code uses the Bitmap's internal SkBitmap without
accounting for density.
Test: Ran CTS:
- CtsUiRenderingTestCases
- CtsGraphicsTestCases
- CtsViewTestCases
Change-Id: I030b4bb89c66b0102ccea2d85f5271197558d14e
Since P, we cannot create zero size surface. For compatibility, we
create 1x1 dummy surface when the app claims zero size surface.
Bug: 72416622
Test: Invoke startDragAndDrop with zero size surface
Change-Id: Ifefd07e93389979eaa2a6fbe29abe5850fcdef34
When user tries to switch IME, IMMS.showInputMethodPickerFromClient()
is called. The call fails to validate in newly introduced
canShowInputMethodPickerLocked() in
I4f0fc21268200c64d12b31ca54416acfbf62f37b because
mCurClient.client != client.
This is happening since the new client never started input ever since
we prevented calls to startInputUncheckedLocked in
Ibf9dab3d9c138b5f04e053d41ee4fd248c78e4da.
The fix is to update mCurFocusedWindowClient.client instead of
mCurclient.client in canShowInputMethodPickerLocked()
Fixes: 72557082
Test: manually using the steps in bug
Test: atest InputMethodManagerTest
Change-Id: I4e21625c32a0ca1abc740229efb3c7fcd97141cc
The smartselection token no longer accurately describes the purpose of the
model. This change brings the factory models in line with the path for the
updated model.
Test: Ran framework core tests and tested manually
Change-Id: I7641db313c94b99bb6960cf1efd24f796bb092a2
- 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
The lib2 implementation of libtextclassifier is incompatible with models
for lib1. To avoid trying to load a lib1 model and failing (which happens
when devices are upgraded from O to P), we need a new update model path.
Using this opportunity to remove smartselection from the filename, which
isn't appropriate any more given what the model is used for.
Test: Ran core framework tests
Change-Id: I79a80d10d920019f5091fe9884f370149d39fe88
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
Previously, we were only making sure that the magnified content belongs
to the view the magnifier is attached to. However, when the view was
laid out partially outside the screen, we would pixel copy from outside
the surface the view is attached to. This would lead to the user seeing
a distorted content in the magnifier, in cases when the magnified view
lies outside the screen. This CL addresses this issue, by clamping the
pixel copy coordinates inside the surface we copy the magnifier content
from.
Bug: 72039853
Bug: 63531115
Test: bit CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: Iddab05c98b615259938e0d3a3320b98b3b13b246
For frameworks constants that don't have intrinsic meaning (i.e. their actual
value and order don't matter), so that it is unlikely that their values
will be changed:
This cl introduces proto enums representing some constants found in
the Android codebase, and connects the two.
By using the Proto enum as the source-of-truth, it means that Java and
proto can be kept in sync. Otherwise, when the Java frameworks code
changes, it silently breaks the protos from working properly, since the enums
are wrong. By having the Java code reference the proto enums, it ensures
that everything is in sync. The values of the constants are unchanged.
But future changes to these constants will need to be done in the proto
file, which the Java file merely references.
The protos are necessary for incidentd and statsd and, in the future,
possibly dumpsys. In this way, the logging mechanism is much less likely
to get broken when new constants are added, and we can be ensured that
the logging accurately reflects the underlying codebase.
Bug: 69478930
Test: cts-tradefed run cts-dev -m CtsStatsdHostTestCases
Test: cts-tradefed run cts-dev -m CtsIncidentHostTestCases
Change-Id: If79032c34b2799db1e3e70cb47b1312fd72092b9
