А есть запись общения?)

Или ссылка не поменялась?)

Ссылка менялась. Постом выше есть видос. Щас еще давай залью ссылки на подкаст-площадки

Сам выпуск, в котором обсуждали эту статью уже доступен на различных подкаст площадках.

Google Podcasts - https://podcasts.google.com/feed/aHR0cHM6Ly9hbmNob3IuZm0vcy80YjMyODkxYy9wb2RjYXN0L3Jzcw==

Apple Podcasts - https://podcasts.apple.com/us/podcast/android-guards-community-podcast/id1552280775

Или поищите в своем плеере подкастов, возможно есть уже и там.

Супер)

спасибо!

Вопрос по biometrics. Почему, если я вызываю biometricsManager.authenticate(promptInfo) при этом не передавая никакой CryptoObject, но в AuthenticationResult мне приходит not null CryptoObject.
Хотя в доках написано что это мол тот, который я передал в authenticate. Выходит что в случае с null он системой генерится?

Да, туда должен приходить именно тот, который ты передал. А тебе прямо реальный объект приходит? оО

Ага. Более того, я у него даже вызываю cryptoObject.cipher.doFinal(...), и он шифрует без выбрасывания исключений. Интересно откуда он берётся. Это Android 10. И на эмуляторе и на девайсе пробовал, одинаково.

Хм.. Может быть я что-то не знаю =) А скинь код, у нас одинаковый NDA 😄

В личку)

Ок, доберусь до него, скину!))

Я решил попробовать воспроизвести это прямо в твоей репо с примером имплементации: https://github.com/Fi5t/authenticate-me.
Поначалу реально приходил null, как я не обновлял либы или менял параметры authenticate.

Но я потерпел сокрушительный успех в воспроизведении, когда добавил всего одну строку:

если её добавить, то начинает сразу приходить не-null CryptoObject в onAuthenticationSucceeded, даже если мы его не слали в BiometricPrompt.authenticate()

ну и дальше ещё порылся в недрах Jetpack Biometric и нашёл окончательный кусок паззла :)

Когда ты испольуешь Strong, там врубается 3й класс биометрической аутентификации. Для него cryptoobject является обязательным. Но я не знал, что они прямо его сами генерят

ага! дошло! И ещё вычитал что типа authenticate без параметров использует 2й класс, а authenticate с параметром cryptoObject врубает 3й класс. Но если мы явно указываем вот этот STRONG и при этом не передаём cryptoObject в authenticate, то он пытается фейкать cryptoObject, чтобы  тем самым врубить 3й класс, как мы и просили. Правда, почему-то хак этот он делает только для API < 30, а почему он не нужен на 30 и что будет на API 30 — неясно)

То, что он пытается фейкать это плохое решение, как по мне. Оно очень неявное и непонятно зачем это нужно если пользоваться этим все равно невозможно нормально. Лучше бы сделали контракт и выкидывали крэш при указании STRONG без явного CryptoObject.

Понабирают ото "разработчиков класса А", которые кроме деревьев на доске ничего вертеть не умеют )