| Age | Commit message (Collapse) | Author |
|---|
|
Bug: 379200787
Test: Manual tests
Flag: EXEMPT minor fix
Change-Id: I1f8ec1ba3f4a76a215d0b922ecad1b2538dcc853
|
|
Bug: 373563472
Test: Manual
Flag: EXEMPT minor ui fix
Change-Id: Ice05f18ca078efce14aec76aa8d218f4b69c33c7
|
|
This CL reconcicles MaterialTheme.colorScheme with AndroidColorScheme,
so that the only colors left in AndroidColorScheme are the ones not
already available in MaterialTheme.colorScheme. See
b/370422346#comment2 for details.
This CL also adds a test that ensures that the Material colors match
the associated value coming from attributes (R.attr.materialColorFoo).
Bug: 370422346
Test: atest PlatformThemeTest
Flag: NONE color alignment
Change-Id: Ieef5db28a4b60e9de0d998597ad489c7d5468ebf
|
|
The get flow was generated with a 'username' bit to account for general
flows, but the passkey flow needs to condition to use displayname where
possible. That conditioning needs to also be done in the biometric
handler when the credential entry is being read.
Bug: 333445772
Test: E2E AndroidVault Test
Flag: EXEMPT bugfix
Change-Id: I6036ef8581cfc573528e4bbe42b3d5e728db365b
|
|
|
|
Test: Cts
Bug: 328457971
arm64-v8a CtsAutoFillServiceTestCases: Passed: 8, Failed: 0, Ignored: 0, Assumption Failed: 0
All tests passed!
Change-Id: I3dac4e3524b1fb81dc0d4e9be9d12b5ca4bd696c
|
|
|
|
Test: Build successful - name change only
Bug: 343401275
Change-Id: Ib71325b802fccf40e517ed230c65a9e840bd2e1a
|
|
Recently, we added a change to Jetpack to bundle BPData properties
within a bundle, rather than directly imbue it into the slice.
This requires us to re-structure our slice parsing, to:
1. Read the bundle from the slice.
2. Parse the bundle after reading from the slice.
Along this change, we also need to know, for a whole many use cases,
when the framework prompt was the originator for the codes of the BP.
This is also a Jetpack decision, so a small bit was added so it can be
utilized in JP.
Bug: 339650358
Test: Build and device tests
Change-Id: I6c3392fb96e6d5409310ba4b840f229444942803
|
|
Bug: 328299228
Test: Built locally & deployed
Flag: ACONFIG android.credentials.flags.credman_biometric_api_enabled NEXTFOOD
Change-Id: I994a288886a8a42653c03037b8d1d17441360868
|
|
Test: N/A
Bug: 341073357
Change-Id: I25328dc2dc3143aeb2b5a11e374ece3fd9f4b7cf
|
|
|
|
This fixes an issue where the provider activity, for whatever reason,
may interrupt the BiometricFlow. Usually, as this exploraiton
identified, this leads to a default cancellation in the finish() term of
activities. This requires properly capturing the state change in the
framework, which is what is done here.
Bug: 335094602
Test: Build Test
Change-Id: I23c7049702445c0ef7340339dd4b693d157de250
|
|
Bug: 337927541, 337926814
Test: manual
Change-Id: Ieef7db5d974bb8f05b1f8e059c4928f66f27d0c6
|
|
This CL aims to propagate the developer cancellation signal to the
biometric prompt, by creating a 'wait/notify' system based on the
underlying viewModel's mutableState. This specifically modifies
BiometricState to contain a new property that acts as the 'notifier' for
cancellation in the SysService.
Bug: 333445003
Test: Sample app configuration test, build test
Change-Id: I10aedc7bd2adeb571a9ffe7d89c5f201fe02e660
|
|
|
|
This reverts commit a03d712c96760319f69bd62570731323f8a302c3.
Reason for revert: Landing the original change
Change-Id: I5858d2e181aa864395a209ade610791f9c867157
|
|
|
|
This reverts commit 70e82cf54a973df47da4f3aaf26a75a71abe8c26.
Reason for revert: <Potential culprit for b/335588704 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.>
Change-Id: I17523162a371319b691073414888186f9884f5de
|
|
|
|
|
|
|
|
Bug: 328086145
Test: Cts
Change-Id: Ie4cac17df2302c7efa8a09d54dc719c200f24c4b
|
|
|
|
Bug: 335048787
Test: Cts
Change-Id: If37ad211bb044c870f0c84bb15df754268402c73
|
|
Previously, we nuanced the fallback around the DEVICE_CREDENTIALS bit,
and allowed other cases to propagate.
Now, we generalize the scope of the initial fallback to avoid having to
call the biometric API at all (and thus avoid the onError() response for
a vast majority of the use cases).
Bug: 334197980
Test: Video tests in the bug and build test
Change-Id: Iee78237156c15400ef5a293ad86b38a43b128e9e
|
|
Dependent on recent discussions, caused by a modality discussion and a
discussion on the nullability of provider input, this CL aims to
finalize and polish all the strings for the BiometricPrompt flow.
Bug: 330396140
Test: Build and video tests
Change-Id: I983d626363c4ff59fcf8d84ad27b6680d0f0e2c6
|
|
|
|
1. Remove question marks to be consistent with the single tap biometrics
titles that also don't have question marks
2. Replace 'sign-in' with 'account' for mixed / unknown credential
presentations.
Test: see screenshot in bug
Bug: 334170176
Bug: 334108777
Change-Id: Id3598bd0d244d3e7608a8b27f0635175118eb4c8
|
|
After running through the API, the builder for the prompt is confirmed
to throw just an IllegalArgumentException, as does the actual calling of the
API. Thus, we can specify to just IllegalArgumentException, and anything
else will be unexpected and should error-out.
Bug: 334923201
Test: Video and Build test
Change-Id: If2028b6a60bf4c95a7a0c41247dcb4284f585cb1
|
|
This change polishes our UI/UX to contain the PromptView that allows for
embedding the more option within it.
As a part of the polish, we met with our BiometricTeam POC and
confirmed the recent changes. We validated the button alignment is as
expected, we made headway on the strings bug, and we confirmed expected
fallback behaviour when no negative button exists.
During CL iteration, some changes raised UX discussion. Namely, a string
that comes from the provider is nullable, and using the existing
approach could at most be a fallback. Secondly, we had discussions
around DEVICE_CREDENTIAL being imbued directly, which matched the mocks,
but raised questions on whether we need a CANCEL instead, and on what to
do in the case of only DEVICE_CREDENTIAL (where it presently goes into
the PIN/Pattern/Etc... screen). This solves the single case, and we have
a path to allow 'CANCEL' instead of the present mocks for device cred
after discussion that will be in a follow up implementation.
Thus, this change ensures the new API is used, confirms the flows are as
expected in test, and kick started discussions that can be followed up.
Bug: b/333445112
Test: Heavily tested, video will be attached to bug pre submission
Change-Id: Ic7713490c0a85a9b6a3286bc0ec61743ac9ef222
|
|
|
|
|
|
Bug: 333596088
Test: Built & deployed locally
Change-Id: Idd93ffbfd5531d85eff680f728062910fc7da369
|
|
|
|
Alongside the CL where we polish the UX to be updated with the mock, this CL aims to
finalize a specific edge case - the lack of a device credential. This is
done and also realizes a second goal - ensuring error propagation for
any non-cancellation based error, as per earlier product decisions.
Bug: 331826599
Bug: 333445754
Test: Video and build tests found in bug
Change-Id: I1015c4142703f3284bdf0e9bac78301ac1d6341a
|
|
This applies to both the single tap and the autofill-credman
feature. For the latter, we don't propagate the cancellation
exception back to the developer as the user can bring up the
selector again.
Bug: 328086145
Test: Cts
Change-Id: Ib30c49aabe64144c44676ba81535822f9a87889a
|
|
|
|
Before this change, a result reciever was added to each pinned dataset's
associated intent, and then retrieved in the from the intent that
starts the credman selector intent which then passed it to credman session.
Now, autofill session constructs one resultreciever per FillRequest and adds it to
client state, proxy service retrieves it from clientstate and
adds it to the req top level bundle, which is then extracted by credman session
and used to propagate the final response.
Hence we remove the dependency on the selector passing the resultReciver to the credman
session
Test: Cts
Bug: 333455221
Change-Id: Ic17091841edbcf0975d0ff238f2d8b72d8cd5593
|
|
This fixes the rotation bug for credential manager by creating a
[BiometricFlowState] object. This object is used throughout the flow to
ensure that on re-compose, the state does not violate any constraints.
Namely, if a rotation or other similar configuration change happens that
causes a recompose, the Ui has consistent state.
Bug: 330396089
Test: Visual/Build Test updated to bug
Change-Id: Ic8a1a09647999abc9bf935d143c7006e0f3860e7
|
|
Similar to the Get flow, this combines 4 previously scoped out bugs.
This adds on all the state management for the single tap create flow,
and sets up detailed conditionals.
This flow can *already* be triggered (as can the get flow) in the present setup,
and further chains will complete the feature. Thus, we introduce an E2E
with which we can continue extending. For example, there have been
recent alignments in UX with the BiometricTeam, and those iterations can
follow once the E2E is embedded, especially since we will continue to
utilize parameters that are in the process of being released.
Bug: 327619148
Bug: 327620245
Bug: 327620327
Bug: 327621520
Test: Junit tests, UX tests, and build tests (flow not triggerable in
normal use cases yet)
Change-Id: I5532662315e9a06b6a74f4454418ee1ff3cd243d
|
|
|
|
When the biometric diaglog was canceled, the UI underneath would remain
awake. This was the first attempted fix, where we listened to a
cancellation error code, and then upon receiving it, given it ensures
the end of a flow, we utilize a viewModel lambda that ensures the
credman UI also ends.
This fix works in practice.
Bug: 331791049
Test: Built and Tested Visually
Change-Id: I076d19e2361ca1017aa57b32150d361eac0ccb97
|
|
This ensures the scrim applies to the whole screen including the status
bar area.
Bug: 332558650
Test: see screenshots in bug
Change-Id: I1447b7bc31401f2fb1d00d6e16ddc095766c5302
|
|
|
|
Bug: 328387993
Test: Cts
Change-Id: I2313160c8c2abd0f7fef090382fb0e70a99eb971
|
|
|
|
Bug: 330587182
Change-Id: Ieecd6192f99f83c1be8d7941fb5ca90ee68fd977
|
|
|
|
|