One major utility of the Keyri mobile SDKs is strong device fingerprinting; in other words, stably associating a given device on which your app is installed to a given user account or set of user accounts, then reading those associations when you want to in order to handle different situations. The fingerprint persists even if the user deletes your app and re-installs it.

All device Keyri fingerprinting functionality and intelligence takes place within the confines of your mobile app, through Keyri SDK methods. Custom logic can be set up on your mobile app or dictated by your backend based on the outputs of Keyri's mobile fingerprint-related methods.

This device fingerprinting and fingerprint reading functionality is independent of the authentication system you use, and the fingerprinting methods outlined below can be embedded into your existing signup and login functions as additional sources of data that enable further conditional app behavior.

1. Avoid accidental multiple account creation: during your registration flow, detect in the background even in an unauthenticated state, whether the user has used an account for your service in the past regardless of what credentials they are using to register the new account. While the user goes through your registration flow, you can call methods in the Keyri SDK, and if they return an account or list of accounts that have been used on that device before, you can suggest or force the user to log into one of those existing accounts, even if they used a different email address or phone number to attempt registering the new account.
2. Avoid fraudulent multiple account creation: using the same existing-account-detection functionality outlined above, you can stop users from creating multiple accounts to exploit your app, such as signup bonus abuse and free trial abuse
3. Actually ban bad actors: in social apps, while you can easily ban individual bad actor accounts by changing their account profiles / access rights, those same individuals can simply create new accounts and sockpuppets. Keyri SDK device fingerprinting methods can help you ensure that, for this group of users, creating a new account is more difficult than simply providing new credentials, such as a different email address, phone number, or a fresh re-installation of your app. Regardless of what new credentials or account identifiers these bad actors input while registering a new account, Keyri SDK methods will inform you that they have already created at least one account before.
4. Continuous on-demand authentication: Keyri cryptographic keys can be used to invisibly re-authenticate your users whenever you want, such as during a sensitive operation like changing their contact details or handle. For more details on this use, please see our Server-Side Authentication documentation.



The two primary Keyri SDK methods used to implant and retrieve user-related device fingerprints are generateAssociationKey(userIdentifier) and listUniqueAccounts() respectively. The former is used to create a key pair for a user and return a public key that you can either ignore or save to your database for further use, such as continuous authentication. The latter is simply used to list the key pairs present on the device, associated with your app, as well as the user identifiers they are associated with, returning an array. If this array is empty, it is highly likely that the user has only recently installed your app and is a legitimate user, thereby allowing them to complete registration with no added friction. On the other hand, if this array is not empty, they can be confidently directed to log into their existing account.

The following example protects your registration/signup flow. Regardless of the credentials that the user inputs when trying to create a new account (like a new username), the Keyri methods included here will detect whether that device has already registered an account, and if so, suggest to the user to log in with that existing account rather than create a new one. Of course, you can implement other logic like allowing up to two accounts, blocking certain accounts altogether, etc. All you're getting when running listUniqueAccounts() is a useful, reliable array of accounts associated with that device, and you can parse and act upon it however you'd like.

If you do not want to lose the list of Keyri accounts after deleting the your Android application, you can configure Backup. This document will help you set up your account backup configuration.

You can find comparison of Key/Value Backup and Auto Backup here: Android Backup Overview.

Keyri backup file keyri_backup_prefs is a SharedPreferences file that contains Keyri accounts. You need to keep this file after app uninstall to prevent the loss of accounts. There are two options for how to do it.

Auto Backup for Apps automatically backs up a user's data from apps that target and run on Android 6.0 (API level 23) or higher.

Make sure that backup is not disabled in your application. allowBackup should not be false. The default value is true but to make your intentions clear, we recommend explicitly setting the attribute in your manifest as shown below:

Control backup on Android 11 and lower

Follow the steps in this section to include or exclude files that are backed up on devices running Android 11 (API level 30) or lower.

1. In AndroidManifest.xml, add the android:fullBackupContent attribute to the <application> element. This attribute points to an XML file that contains backup rules. For example:

2. Create an XML file called @xml/backup_rules in the res/xml/ directory. Inside the file, add rules with the <include> and <exclude> elements. The following sample backs up all shared preferences except device.xml:

If you have more granular control over sharedPref backups, make sure you have included keyri_backup_prefs.xml file.

Control backup on Android 12 or higher

If your app targets Android 12 (API level 31) or higher, follow the steps in this section to include or exclude files that are backed up on devices that are running Android 12 or higher.

1. In AndroidManifest.xml, add the android:dataExtractionRules attribute to the <application> element. This attribute points to an XML file that contains backup rules. For example:

2. Create an XML file called backup_rules.xml in the res/xml/ directory. Inside the file, add rules with the <include> and <exclude> elements. The following sample backs up all shared preferences except device.xml:

If you have more granular control over sharedPref backups, make sure you have include keyri_backup_prefs.xml file.

Check for more details on Back up user data with Auto Backup.

Android Backup Service provides cloud storage backup and restore for key-value data in your Android app. During a key-value backup operation, the app's backup data is passed to the device's backup transport. If the device is using the default Google backup transport, then the data is passed to Android Backup Service for archiving. Data is limited to 5MB per user of your app. There is no charge for storing backup data.

Note: Key-value backup requires you to write code to define your backup content explicitly, while Auto Backup requires no code and will back up entire files. Most apps should use Auto Backup to implement backup and restore. Your app can implement Auto Backup or key-value backup, but not both.

Implement key-value backup

To back up your app data, you need to implement a backup agent. Your backup agent is called by the Backup Manager both during backup and restore.

To implement a backup agent, you must:

1. Declare your backup agent in your manifest file with the android:backupAgent attribute.

2. Define a backup agent by doing one of the following:

• Extending BackupAgent The BackupAgent class provides the central interface that your app uses to communicate with the Backup Manager. If you extend this class directly, you must override onBackup() and onRestore() to handle the backup and restore operations for your data.
• Extending BackupAgentHelper The BackupAgentHelper class provides a convenient wrapper around the BackupAgent class, minimizing the amount of code you need to write. In your BackupAgentHelper, you must use one or more helper objects, which automatically back up and restore certain types of data, so that you don't need to implement onBackup() and onRestore(). Unless you need full control over your app's backups, we recommend using the BackupAgentHelper to handle your app's backups.

Android currently provides backup helpers that will back up and restore complete files from SharedPreferences and internal storage.

You can implement your own backup according to the documentation: Back up key-value pairs with Android Backup Service . In this case just include keyri_backup_prefs string to your BackupAgentHelper as shown below:

After it just add your MyBackupAgent to AndroidManifest.xml:

Or you can just use our KeyriPrefsBackupAgent which implements the necessary logic under the hood as shown below:

See Test backup and restore to test backup of Keyri accounts.