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
Add resource overlay and carrier config which will determine
which package / network services will be bound to.
Bug: 64132030
Test: regression tests
Change-Id: I5f515ec16b712e7be25f69e0e079d672227542b0
This change also adds the BiometricAuthenticator interface for the future
BiometricManager
Fixes: 72529467
Test: FingerprintDialog, FingerprintSystemDialog apks
Test: CTS Verifier apk
Change-Id: I703d004a3aebcbc473329d531505ffb647b91950
Rename and change signature/behavior to match up with middleware
vendor's expectations
Test: run CTS tests
Change-Id: If18acff5631cfc0473c342e9250973866e960d69
Bug: 34881007
Test: bit CtsGraphicsTestCases:*
Test: bit CtsUiRenderingTestCases:.testclasses.HardwareBitmapTests
Change-Id: Ic751c356682ea3db17a1b031ec46106a1a2ab918
* changes:
Add and trigger onReady API for SMS over IMS.
Unhide SMS over IMS APIs
Remove internal version of SMS apis
Move Sms API to proper MMTelFeature class
Add unique id for sms APIs to be able to trigger correct smstracker
Test: manual test that normal code path is fine since this code path is
not yet exercisable.
BUG=69846044
Merged-In: Icb15ca4aa6606fba641f6270dca5e0e06fc4466a
Change-Id: Icb15ca4aa6606fba641f6270dca5e0e06fc4466a
This reverts commit 860b8ba719.
The original change that was reverted contained a bug that allowed an
http view/browsable intent used to query for browsers to be considered
as a candidate for instant apps. This was resulting in an attempt to
bind to the instant app resolver while holding a lock on mPackages.
This change ensures that PMS doesn't bind while checking for the browser
status of a package in both the instant app filtering code and by adding
the FLAG_IGNORE_EPHEMERAL to the canonical browser intent.
Reason for revert: Applying fix
Change-Id: I4896b3a15416a11fdc3f6c191e552c4ce8963623
Fixes: 63117034
Fixes: 71916178
Test: Manual using test app at google_experimental/users/patb/InstantAppsInP
Test: atest android.appsecurity.cts.EphemeralTest passes after modification
While here add more constants for send sms result.
Test: manual
BUG:69846044
Merged-In: I66fdcff51dc5ded9f6199d09bb667c89f38b6d59
Change-Id: I66fdcff51dc5ded9f6199d09bb667c89f38b6d59
