Fixed
Status Update
Comments
le...@gmail.com <le...@gmail.com> #2
Android 5.0, 5.1: it shows context menu at top of screen, not as popup. See screenshots.
Android framework doesn't support floating toolbar before 23. So this is intended behavior.
The crash information suggests that this is an error from Snapshot. chuckj@ can you please take a look? I don't know what exactly caused the readError
in Snapshot, any suggestions? Thanks a lot!
na...@gmail.com <na...@gmail.com> #3
This looks like another instance of 193006595 which I am looking at now.
gu...@gmail.com <gu...@gmail.com> #4
Project: platform/frameworks/support
Branch: androidx-main
commit beeb84e7be604088ad40e080a8d0adb1bacbf695
Author: Chuck Jazdzewski <chuckj@google.com>
Date: Thu Jul 08 10:04:28 2021
Remove updating the transparent snapshot
A transparent snapshot is create for the block exeucted by
`Snapshot.observe()` which registers read and write observers
but without creating a snapshot. The code to advance the
global snapshot, however, created a new transparent snapshot in
an attempt to update it to the new global snapshot it just
created. This is not necessary, however, as the transparent
snapshot will retrieve the current global snapshot from
`currentGlobalSnapshot` instead of `previousSnapshot` if
`previousSnapshot` is `null`. With the previous code, if the
global snapshot is advanced by applying a new snapshot the
"updated" transparent snapshot will be left referring to an
older snapshot instead of the most recent global snapshot.
Any snapshot object created in the newly applied snapshot
will throw an exception when it is accessed, as reported in
the bugs. The solution is to remove the apparent vetiagal code.
Test: ./gradlew :compose:r:r:tDUT
Fixes: b/193006595 , b/192570897
Change-Id: I2c0d0b8f57bf70e5a98ea36ed141d97142a5e53e
M compose/runtime/runtime/src/commonMain/kotlin/androidx/compose/runtime/snapshots/Snapshot.kt
M compose/runtime/runtime/src/test/kotlin/androidx/compose/runtime/snapshots/SnapshotTests.kt
https://android-review.googlesource.com/1760301
Branch: androidx-main
commit beeb84e7be604088ad40e080a8d0adb1bacbf695
Author: Chuck Jazdzewski <chuckj@google.com>
Date: Thu Jul 08 10:04:28 2021
Remove updating the transparent snapshot
A transparent snapshot is create for the block exeucted by
`Snapshot.observe()` which registers read and write observers
but without creating a snapshot. The code to advance the
global snapshot, however, created a new transparent snapshot in
an attempt to update it to the new global snapshot it just
created. This is not necessary, however, as the transparent
snapshot will retrieve the current global snapshot from
`currentGlobalSnapshot` instead of `previousSnapshot` if
`previousSnapshot` is `null`. With the previous code, if the
global snapshot is advanced by applying a new snapshot the
"updated" transparent snapshot will be left referring to an
older snapshot instead of the most recent global snapshot.
Any snapshot object created in the newly applied snapshot
will throw an exception when it is accessed, as reported in
the bugs. The solution is to remove the apparent vetiagal code.
Test: ./gradlew :compose:r:r:tDUT
Fixes:
Change-Id: I2c0d0b8f57bf70e5a98ea36ed141d97142a5e53e
M compose/runtime/runtime/src/commonMain/kotlin/androidx/compose/runtime/snapshots/Snapshot.kt
M compose/runtime/runtime/src/test/kotlin/androidx/compose/runtime/snapshots/SnapshotTests.kt
kc...@google.com <kc...@google.com> #5
We should probably be less restrictive to support the older devices.
kc...@google.com <kc...@google.com> #6
We need to update FingerprintManagerCompat which also checks PackageManager. On API23 this flag doesn't exist
kc...@google.com <kc...@google.com> #7
aosp/987432 and aosp/987433 merged
Waiting for next core:core release, then need to bump androidx.biometric core:core dependency to next version
Waiting for next core:core release, then need to bump androidx.biometric core:core dependency to next version
an...@google.com <an...@google.com> #8
kc...@google.com <kc...@google.com> #9
Curtis do you have cycles to update the androidx.biometric core:core dependency to 1.1-rc02?
It should have been released per b/135756958
A quick test with an emulator on API23 with the demo app should allow fingerprint auth on API23 with the new core:core library
It should have been released per
A quick test with an emulator on API23 with the demo app should allow fingerprint auth on API23 with the new core:core library
cu...@google.com <cu...@google.com>
ap...@google.com <ap...@google.com> #10
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 40ce60b24ac3ef3bbbd1d6067b574aa5f75e9357
Author: Curtis Belmonte <curtislb@google.com>
Date: Tue Jul 09 10:25:12 2019
Update androidx biometric core dep to 1.1.0-rc02
Updates the androidx biometric package to depend on androidx.core:core
version 1.1.0-rc02 instead of 1.0.0. Among other things, this fixes an
issue where devices with older API versions but otherwise compatible
hardware for fingerprint authentication get a hardware unavailable
error.
Test: On a Pixel 3 emulator with API 23:
1. Ensure a fingerprint is enrolled for the device
2. Install and launch the biometric demo app (with new dep)
3. Host in either an activity or fragment and choose a test setup
4. Tap on "Authenticate" and verify fingerprint dialog is now shown
Fixes: 124066957
Change-Id: Id95b6df1615289609945b0e72644717c17d43fa6
M biometric/build.gradle
https://android-review.googlesource.com/1012624
https://goto.google.com/android-sha1/40ce60b24ac3ef3bbbd1d6067b574aa5f75e9357
Branch: androidx-master-dev
commit 40ce60b24ac3ef3bbbd1d6067b574aa5f75e9357
Author: Curtis Belmonte <curtislb@google.com>
Date: Tue Jul 09 10:25:12 2019
Update androidx biometric core dep to 1.1.0-rc02
Updates the androidx biometric package to depend on androidx.core:core
version 1.1.0-rc02 instead of 1.0.0. Among other things, this fixes an
issue where devices with older API versions but otherwise compatible
hardware for fingerprint authentication get a hardware unavailable
error.
Test: On a Pixel 3 emulator with API 23:
1. Ensure a fingerprint is enrolled for the device
2. Install and launch the biometric demo app (with new dep)
3. Host in either an activity or fragment and choose a test setup
4. Tap on "Authenticate" and verify fingerprint dialog is now shown
Fixes: 124066957
Change-Id: Id95b6df1615289609945b0e72644717c17d43fa6
M biometric/build.gradle
kc...@google.com <kc...@google.com> #11
Sorry my commit message in aosp/987612 was a bit misleading, the flag exists on API23, but OEMs were not setting it properly. I believe we started enforcing this after 23.
[Deleted User] <[Deleted User]> #12
When will this "land" - when will an alpha5 or beta1be released?
as of today the release notes still show this at alpha4 from April ...it seems like that's a lot of delay for something so important and visible and widespread.
https://developer.android.com/jetpack/androidx/releases/biometric
as of today the release notes still show this at alpha4 from April ...it seems like that's a lot of delay for something so important and visible and widespread.
kc...@google.com <kc...@google.com> #13
Sorry for the slow turnaround time, we ran into some unexpected issues. Beta01 is going live on Thursday.
[Deleted User] <[Deleted User]> #14
awesome thanks!
1) Is there a best practice or material design recommendation for user-visible wording in the settings?
"Allow Biometrics" is not very friendly sounding,but continuing with "Enable Fingerprint" wording may not be wise if q4 brings us phones with Face unlock but no fingerprint scanner...
https://material.io/design/platform-guidance/android-fingerprint.html#enrollment
2) Will the beta have canAuthorize similar to the Q version to handle whether to allow this to be shown?
3) And, to combine both those questions - would it be worth consider returning an array of what types of biometrics are supported, or even - long term - a stylable settings "slice" or both?
Thanks
1) Is there a best practice or material design recommendation for user-visible wording in the settings?
"Allow Biometrics" is not very friendly sounding,but continuing with "Enable Fingerprint" wording may not be wise if q4 brings us phones with Face unlock but no fingerprint scanner...
2) Will the beta have canAuthorize similar to the Q version to handle whether to allow this to be shown?
3) And, to combine both those questions - would it be worth consider returning an array of what types of biometrics are supported, or even - long term - a stylable settings "slice" or both?
Thanks
[Deleted User] <[Deleted User]> #15
Thanks for the update, but I think there's bug in the canAuthenticate() method as it does not return proper error code on APIs < 23.
It returns BiometricManager.BIOMETRIC_ERROR_HW_UNAVAILABLE which according to comment is "The hardware is unavailable. Try again later."
Shouldn't it return BiometricManager.BIOMETRIC_ERROR_NO_HARDWARE in this case?
It returns BiometricManager.BIOMETRIC_ERROR_HW_UNAVAILABLE which according to comment is "The hardware is unavailable. Try again later."
Shouldn't it return BiometricManager.BIOMETRIC_ERROR_NO_HARDWARE in this case?
kc...@google.com <kc...@google.com> #16
Forked comment #15 to b/140427586
cu...@google.com <cu...@google.com> #17
Forked comment #14 to b/140497517 . Closing this bug now that the original issue has been addressed.
Description
Devices/Android versions reproduced on: emulator APIs 23-27
In all samples, including official one (
public boolean isFingerprintAuthAvailable() {
// The line below prevents the false positive inspection from Android Studio
// noinspection ResourceType
return mFingerprintManager.isHardwareDetected()
&& mFingerprintManager.hasEnrolledFingerprints();
}
But FingerprintHelperFragment also checks
mContext.getPackageManager().hasSystemFeature(PackageManager.FEATURE_FINGERPRINT)
which can return false, even if scanner exists and fingerprint is configured, and FingerprintManager can be used for authentication.
If this behavior can be reproduced on emulator, so probably it can happen on real device too.