Status Update
Comments
da...@gmail.com <da...@gmail.com> #2
1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?
vi...@google.com <vi...@google.com> #3
Tested on Android 12 Emulator with custom executor, but cannot repro this issue.
da...@gmail.com <da...@gmail.com> #4
-
Second crash in the description is from a real device. Experienced it myself on two different Xiaomi phones, plus lots of crashes from users in the Google Play console.
-
Dynamic features are not used in the application.
As a wild guess, I have downgraded build tools from 31.0.0 to 30.0.3, compileSdk from 31 to 30, and moved all work with Language ID to the service in a separate process (just to be sure that crash can kill secondary process instead of main). This combination is in beta for 2 days by now and I don't see any SIGSEGV crashes.
vi...@google.com <vi...@google.com> #5
Hmm, I feel the crash might be something related to separate/secondary process.
I also changed compileSdk and targetSDK to 31 but still cannot repro this issue.
kc...@google.com <kc...@google.com>
cu...@google.com <cu...@google.com> #6
On the contrary, there was no separate process before, when crashes started.
In the new build (with the aforementioned changes) I can see SIGSEGV crash, but only one instead of dozens and it has a bit different backtrace:
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
liblanguage_id_jni.so (offset 0x11e000)
backtrace:
#00 pc 000000000003c7c0 /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 000000000003b960 /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 000000000003bb48 /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 000000000003bafc /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 0000000000036c98 /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 0000000000032714 /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 0000000000031cac /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 0000000000057438 /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/oat/arm64/base.odex (offset 0x57000)
Description
Version used:1.0.1
Theme used: Theme.AppCompat.Light.DarkActionBar
Devices/Android versions reproduced on: pixel 2 Android 10, Emulator API 27&29
- Relevant code to trigger the issue: equal to the documentation:
and using setDeviceCredentialAllowed(true)
I implemented the new androidx.biometric:biometric:1.0.1 as described in the documentation and using setDeviceCredentialAllowed(true). On API 29 it works correctly, on API < 29 when there aren't any device credentials set I would expect to get ERROR_NO_DEVICE_CREDENTIAL but I'm getting ERROR_USER_CANCELED, is this a library bug or if not what am I missing?
Since the documenation says this library is backwards compatible I would expect I don't need to handle anything myself for API<29, right?
As I could see in BiometricPrompt.java there is a code-block:
case DeviceCredentialHandlerBridge.RESULT_ERROR:
// Device credential auth failed. Assume this is due to the user canceling.
final CharSequence errorMsg = getActivity() != null
? getActivity().getString(R.string.generic_error_user_canceled) : "";
mAuthenticationCallback.onAuthenticationError(
BiometricConstants.ERROR_USER_CANCELED, errorMsg);
bridge.stopIgnoringReset();
bridge.reset();
break;
Don't know why the lib is returning a generic error code in form of ERROR_USER_CANCELED, nothing of this is documented in BiometricConstants.java.