Fixed
Status Update
Comments
ti...@google.com <ti...@google.com>
ib...@google.com <ib...@google.com> #2
The most common devices for the first crash sorted from highest to lowest:
Samsung S8 (5% of all crashes), S9 (4%), S8+ (4%), S10+ (3%), S9+ (3%), Huawei P20 Pro & Lite (9%)
The most common devices for the second crash:
HUAWEI Y6 2019 (38% of all crashes), HUAWEI Y5 2019 (17%), Nokia 3 (10%), Nokia 2.1 (9 %), Oppo realme 1 (5%)
The most common devices for the third crash:
Samsung Galaxy A5 (14% of all crashes). S7 Edge (9%), Spa Condor Electronics PGN610 (17% of all crashes)
Samsung S8 (5% of all crashes), S9 (4%), S8+ (4%), S10+ (3%), S9+ (3%), Huawei P20 Pro & Lite (9%)
The most common devices for the second crash:
HUAWEI Y6 2019 (38% of all crashes), HUAWEI Y5 2019 (17%), Nokia 3 (10%), Nokia 2.1 (9 %), Oppo realme 1 (5%)
The most common devices for the third crash:
Samsung Galaxy A5 (14% of all crashes). S7 Edge (9%), Spa Condor Electronics PGN610 (17% of all crashes)
ma...@gmail.com <ma...@gmail.com> #3
Crash 3 is a dupe of issue 138825362
ib...@google.com <ib...@google.com> #4
Which library version are you using?
ma...@gmail.com <ma...@gmail.com> #5
yeap, at least #1 was reported against the alpha here: https://stackoverflow.com/q/56358422/270197 - while the lib is now in beta
ma...@gmail.com <ma...@gmail.com> #6
#1 and #3 are definitely fixable in the support library. #2 can likely be resolved by the app checking BiometricManager#canAuthenticate() before requesting BiometricPrompt#authenticate().
For #1)
Looks like somehow the app is trying to display the dialog after onSaveInstanceState(), e.g. the activity/fragment is ending its lifecycle? Curtis perhaps we should do some lifecycle checks here.
For #2)
tranced.freak@ do you happen to know which devices are reporting this?
There is a chance the following is happening:
- device does not have fingerprint hardware
- app requests authenticate()
- hasSystemFeature(FP) fails, but invokes sendError
- sendError needs FPM to get error string.
A solution on the app side is to check BiometricManager#canAuthenticate() before requesting authentication. Is this something the app is already doing? We will focus this bug on #1 and #3 until we hear otherwise.
For #3)
Similar onSaveInstanceState issue
For #1)
Looks like somehow the app is trying to display the dialog after onSaveInstanceState(), e.g. the activity/fragment is ending its lifecycle? Curtis perhaps we should do some lifecycle checks here.
For #2)
tranced.freak@ do you happen to know which devices are reporting this?
There is a chance the following is happening:
- device does not have fingerprint hardware
- app requests authenticate()
- hasSystemFeature(FP) fails, but invokes sendError
- sendError needs FPM to get error string.
A solution on the app side is to check BiometricManager#canAuthenticate() before requesting authentication. Is this something the app is already doing? We will focus this bug on #1 and #3 until we hear otherwise.
For #3)
Similar onSaveInstanceState issue
ib...@google.com <ib...@google.com> #7
Edit, just read comment #2 . Y5, Nokia 3, Nokia 2.1, Realme1 don't have fingerprint sensors.
The only other device, Y6 does have a fingerprint sensor but it's possible the only other device (Y6) did not declare FEATURE_FINGERPRINT.
Either way, checking androidx.BiometricManager#canAuthenticate (added in beta01) will resolve this issue.
The only other device, Y6 does have a fingerprint sensor but it's possible the only other device (Y6) did not declare FEATURE_FINGERPRINT.
Either way, checking androidx.BiometricManager#canAuthenticate (added in beta01) will resolve this issue.
ib...@google.com <ib...@google.com> #8
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 549dceb1f3104bc4c4cb3e5168114f99e84a223c
Author: Curtis Belmonte <curtislb@google.com>
Date: Tue Sep 17 11:24:07 2019
Fix biometric dialog crashes due to state loss
Making fragment transactions such as adding or removing dialogs after
the host activity's state has been saved is currently causing crashes in
the biometric library. normally For multiple reasons (outlined in
b/138825362 ), allowing these dialogs to be dismissed with state loss is
probably preferable anyway, so this commit makes that change. It also
tries to prevent BiometricPrompt from triggering authentication in the
first place if the host's state has already been saved.
Test: ./gradlew biometric:connectedAndroidTest
Test: Trigger delayed dismissal of dialog and quickly finish activity
Test: Enable "Don't Keep Activities", show prompt and back out
periodically
Before: App crashes
After: App no longer crashes
Fixes: 138825362
Bug: 140447194
Change-Id: Ic2cf512c9441c2c8b83a051ff788210ae10d64b1
M biometric/src/main/java/androidx/biometric/BiometricPrompt.java
M biometric/src/main/java/androidx/biometric/FingerprintDialogFragment.java
https://android-review.googlesource.com/1122833
https://goto.google.com/android-sha1/549dceb1f3104bc4c4cb3e5168114f99e84a223c
Branch: androidx-master-dev
commit 549dceb1f3104bc4c4cb3e5168114f99e84a223c
Author: Curtis Belmonte <curtislb@google.com>
Date: Tue Sep 17 11:24:07 2019
Fix biometric dialog crashes due to state loss
Making fragment transactions such as adding or removing dialogs after
the host activity's state has been saved is currently causing crashes in
the biometric library. normally For multiple reasons (outlined in
probably preferable anyway, so this commit makes that change. It also
tries to prevent BiometricPrompt from triggering authentication in the
first place if the host's state has already been saved.
Test: ./gradlew biometric:connectedAndroidTest
Test: Trigger delayed dismissal of dialog and quickly finish activity
Test: Enable "Don't Keep Activities", show prompt and back out
periodically
Before: App crashes
After: App no longer crashes
Fixes: 138825362
Bug: 140447194
Change-Id: Ic2cf512c9441c2c8b83a051ff788210ae10d64b1
M biometric/src/main/java/androidx/biometric/BiometricPrompt.java
M biometric/src/main/java/androidx/biometric/FingerprintDialogFragment.java
ib...@google.com <ib...@google.com>
ap...@google.com <ap...@google.com> #9
are these fixes released in beta02?
ap...@google.com <ap...@google.com> #10
> are these fixes released in beta02?
Unfortunately no, but fixes for (1) and (3) from comment #2 will be in rc01, which should be released very soon. :-)
As kchyn@google.com said, an app-side solution is probably most appropriate for (2).
Unfortunately no, but fixes for (1) and (3) from
As kchyn@google.com said, an app-side solution is probably most appropriate for (2).
ap...@google.com <ap...@google.com> #11
I did use alpha version first and then upgraded to beta-02 and I had the same issues.
Unfortunately at the moment I can't use this library until the state errors will be fixed, so I use my own solution as a workaround.
Unfortunately at the moment I can't use this library until the state errors will be fixed, so I use my own solution as a workaround.
ap...@google.com <ap...@google.com> #12
Sit tight, rc01, which contains the fixes for 1 and 3 is coming in before the end of next week.
ap...@google.com <ap...@google.com> #13
Project: platform/frameworks/support
Branch: androidx-main
commit 67282b9c5804e5b8bb28993e57940b322b963988
Author: Ian Baker <ibaker@google.com>
Date: Tue Apr 09 17:30:03 2024
Document ExifInterface 'rational' attributes returned as decimals
These specific attributes have special handling, for backwards
compatibility with the implementation of ExifInterface that preceded the
platform android.media.ExifInterface. See more context in this
internal code review comment from 2016:
http://ag/c/platform/frameworks/base/+/909922/2..9/api/current.txt#b20093
Also add tests for this handling, including the current behaviour of
rejecting/ignoring the 'correct' rational format when passed to
setAttribute(String, String). A follow-up change adds support for this
format (and updates these tests to reflect this).
Bug: 312680558
Test: ExifInterfaceTest
Change-Id: Ia09c2956f0f80279108ccf872174eb98214a38a8
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
M exifinterface/exifinterface/src/main/java/androidx/exifinterface/media/ExifInterface.java
https://android-review.googlesource.com/3037113
Branch: androidx-main
commit 67282b9c5804e5b8bb28993e57940b322b963988
Author: Ian Baker <ibaker@google.com>
Date: Tue Apr 09 17:30:03 2024
Document ExifInterface 'rational' attributes returned as decimals
These specific attributes have special handling, for backwards
compatibility with the implementation of ExifInterface that preceded the
platform android.media.ExifInterface. See more context in this
internal code review comment from 2016:
Also add tests for this handling, including the current behaviour of
rejecting/ignoring the 'correct' rational format when passed to
setAttribute(String, String). A follow-up change adds support for this
format (and updates these tests to reflect this).
Bug: 312680558
Test: ExifInterfaceTest
Change-Id: Ia09c2956f0f80279108ccf872174eb98214a38a8
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
M exifinterface/exifinterface/src/main/java/androidx/exifinterface/media/ExifInterface.java
ib...@google.com <ib...@google.com>
na...@google.com <na...@google.com> #14
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.exifinterface:exifinterface:1.4.0-alpha01
Description
Version used: 1.3.6
Devices/Android versions reproduced on: ALL
Steps to reproduce:
1. Create ExifInterface for an image file
2. Set time exposure attribute to value 0.000625 which corresponds to time exposure value of 1/1600
3. Save attributes to image file
Actual outcome:
- When reading exposure time value from that file the value is 0.0006, so it is truncated. This results in exposure time changed from 1/1600 to 1/1666.
Expected outcome:
- The exposure time value should be 0.000625 which corresponds to the expected exposure time value of 1/1600.
Reproducibility:
It seems to occur on all devices and all image files/formats. Likely the problem is that the double value is converted to rational value which has limited precision.