Now animates the highlight itself as opposed to an outline.
Bug: 70540865
Test: Manually tested it with single and multi-line - ltr and rtl
Change-Id: I8afee259c9952fcff0b713bca62c82a1022f2b0d
MediaControlView2's setTimeout API is removed and MCV2's visibility
handling logic is moved into VideoView2.
Test: build
Change-Id: I149119148f159c78e86c5061d247f0a434310719
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
Switch to reading limit information from NetworkPolicy, which is
typically populated from SubscriptionPlan. This lets users have
direct control over the limits we're using to trigger rapid usage
alerts, and makes the feature work without requiring that the carrier
wire up SubscriptionPlan information.
Let the user "snooze" the rapid usage alerting for a day at a time,
so we're less annoying to them. Send the snooze broadcasts as
foreground, so that we don't re-post notifications while working
through a long background broadcast queue.
Fix notifications to use the "ALERTS" channel, since these alerts
really are higher priority than simple "STATUS" updates; this also
gives us HUN behavior when in full-screen apps.
Update both service and unit tests to work directly with
NotificationManager, instead of the raw AIDL.
Test: bit FrameworksServicesTests:com.android.server.NetworkPolicyManagerServiceTest
Bug: 72444638, 72436702
Change-Id: I8d9138522a7779cc68eb9fa4777b50facb6567b7
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
This allows to dump the USB state as proto-buf. This in turn allows to
automatically process this data.
Test: adb shell dumpsys usb
incident_report usb
No automated test possible as no field is guaranteed to be set
Change-Id: Ifdf22bfaf9c78226c420b11c43278013ce69f849
