‹ /compat

Functions

Device

What the device can do, asked with the functions of react-native-keychain 10: its biometry, whether it can authenticate the user, where Android keeps keys, whether there is a passcode.

Import

import { getSupportedBiometryType, canImplyAuthentication, getSecurityLevel, isPasscodeAuthAvailable } from '@apexnative/keychain/compat';

Four questions about the device, answered by the core's device functions and given back with rnk's names. None shows a prompt. For new code, canUseAccessControl answers the question these are usually asked for, whether an item can be locked a given way now, and says why not.

Usage

src/auth/biometrics.ts

import * as Keychain from '@apexnative/keychain/compat';

export async function biometricLabel(): Promise<string | null> {
  switch (await Keychain.getSupportedBiometryType()) {
    case Keychain.BIOMETRY_TYPE.FACE_ID:
      return 'Face ID';
    case Keychain.BIOMETRY_TYPE.TOUCH_ID:
      return 'Touch ID';
    case null:
      return null; // nothing enrolled: don't offer the switch
    default:
      return 'Biometrics';
  }
}

getSupportedBiometryType

function getSupportedBiometryType(): Promise<BIOMETRY_TYPE | null>;

ReturnsPromise<BIOMETRY_TYPE | null>PromptNeverPlatformsiOSAndroid

The biometry the device can use now, as a BIOMETRY_TYPE, or null when none is enrolled, as rnk answers. It asks getBiometryTypes for the sensors and getBiometryState for whether anything is enrolled.

• A device with no biometric sensor, or with one and nothing enrolled, answers null.
• A device with several (Android: a fingerprint and a face) answers the first the system reports. Which one the prompt shows is the system's choice; the core's getBiometryTypes gives them all.

canImplyAuthentication

function canImplyAuthentication(options?: AuthenticationTypeOption): Promise<boolean>;

ReturnsPromise<boolean>PromptNeverPlatformsiOSAndroid

Whether the device can authenticate the user the way authenticationType names:

Parameter	Type	Description
options.authenticationType	AUTHENTICATION_TYPE	DEVICE_PASSCODE_OR_BIOMETRICS: an enrolled biometry or a passcode (`getBiometryState` or `isPasscodeSet`). BIOMETRICS: an enrolled biometry. Default DEVICE_PASSCODE_OR_BIOMETRICS.

await Keychain.canImplyAuthentication({
  authenticationType: Keychain.AUTHENTICATION_TYPE.BIOMETRICS,
}); // true when a finger or a face is enrolled

rnk answers this on iOS only; here Android answers too, with the same meaning.

getSecurityLevel

function getSecurityLevel(options?: AccessControlOption): Promise<SECURITY_LEVEL | null>;

ReturnsPromise<SECURITY_LEVEL | null>PromptNeverPlatformsiOS (not supported)Android

Android: where a new key would live, with rnk's names. It asks getHardwareSecurityLevel:

The core	getSecurityLevel
'strongbox', 'tee'	SECURE_HARDWARE
'software'	SECURE_SOFTWARE
null (iOS)	null

It never answers ANY. The accessControl of the options is checked (APPLICATION_PASSWORD is UNSUPPORTED) and changes nothing: every key of the package lives where the device keeps keys.

isPasscodeAuthAvailable

function isPasscodeAuthAvailable(): Promise<boolean>;

ReturnsPromise<boolean>PromptNeverPlatformsiOSAndroid

Whether the device has a passcode, PIN or pattern: the core's isPasscodeSet.

See also

canUseAccessControlWhether an item can be locked a given way now, and why not.ConstantsBIOMETRY_TYPE, AUTHENTICATION_TYPE, SECURITY_LEVEL.OverviewEvery function of /compat and the core call it makes.