And also remove some small code duplication (checkNotNull).
Test: built, flashed, runtest frameworks-net
Change-Id: Id6c13bca9d12f70b88806032e0a4fa198efbedc6
* changes:
[CM] Unhide the NetworkSpecifier as object API
Make the NetworkSpecifier a class instead of a string.
Add test coverage for NetworkSpecifiers.
Test: 1. Trigger the confitrmation dialog.
Ensure it looks exactly like the one from settings.
2. Call an API without associating the appa first
Ensure exception is thrown with a message mentioning the need to associate 1st
Change-Id: I94d4116e1988db869ed445ae3fd018c50590e3f4
When saving data filled by the user the platform provides to
an autofill provider the state of the UI allowing the provider
to interpret this state and store relevant information.
A limitation of the current design is that the fill provider
needs to interpret the screen content twice, once handling a
fill request and once handling a save request. To address this
we are introducing a id for each fill request allowing the
autofill provider to associate arbitrary state with each fill
request and store it in the client data bundle later passed
to save.
Another limitation of the current design is that if the screen
changes dynamically while the user interacts with the app the
UI state passed on save represents a static snapshot, therefore
it is not possible to the autofill provider to determine the
context in which the data in the UI was filled. We could
keep the views and have deltas for views being removed/added
/moved/changed but this is not enough as the fill provider
needs to know not only what changed but what changed for every
fill request and in one session there could be multiple fill
requests. To address this we provide a list of fill contexts
on save each of which has the id of the corresponding fill
request. This allows the fill provider to know the exact context
in which the data was popuplated and also use its custom client
state for this fill request if desired.
This change deprecates the old APIs and the new ones delegate
to the old ones. Once the clients migrate to the new APIs we
will remove the old ones.
Test: all autofill CTS tests pass
Change-Id: Idcebcc671aa3c078a305d8c358e225274fccc588
There may be strange states where the user is already authenticated
but still on the lockscreen. The user should be able to dismiss
keyguard in that state.
Fixes: 29306222
Test: unlock phone
go back to keyguard
swipe up screen half way
touch fingerprint sensor (icon should change to unlocked)
then touch fingerprint sensor again (keyguard should be dismissed)
Test: unlock phone and go to settings -> Pixel Imprint
lock phone, unlock phone with fingerprint
touch sensor again and make sure Pixel Imprint page also responds to FP
do this test at least 10 times
Change-Id: I86acd520a06a68fab3548dd4cf6153a7833114fe
There mas a missing defensive copy causing false positive detections of
"associations not changed" case, leading to xml file not being updated once
at least one record is present
Bug: 30932767
Test: Associate at least two different devices and ensure the xml has both.
Change-Id: Ic0dc615dd2b847e137555c1084c616831b4dde83
This effectively treats chooser activity pause event as cancel.
Bug: 30932767
Test: Install two toy apps and call associate API from both.
Ensure foreground app always end up showing fresh data.
Change-Id: I7f5742e9878245550f678efd244bf84c427baef3
This api will return the timestamp at which this activity start was last
initiated by the system. Implementation is wip.
Bug: 9058261
Test: cts-tradefed run singleCommand cts-dev -m CtsAppTestCases -t \
android.app.cts.ActivityStartTimeTest
Change-Id: I396458ecefbb09108f414b95f9c0beb6d609a4e1
- The session might be gone by the time the handler is called, hence check
the sessionID
- Access getClientLocked() and mSession only under mLock.
Test: cts-tradefed run cts-dev AutoFillServiceTestsCases
Change-Id: I445a24557589afadb1f5372b63ef9db88021b609
