वर्शन के साथ काम करने वाली सुविधाएं

Credential Manager की क्रेडेंशियल वापस लाने की सुविधा, Android 9 (एपीआई लेवल 28) और इसके बाद के वर्शन वाले डिवाइसों पर काम करती है. इसके लिए, Google Play services (GMS) का कोर वर्शन 242200000 (v24.22) या इसके बाद का वर्शन और androidx.credentials लाइब्रेरी का 1.5.0 या इसके बाद का वर्शन होना ज़रूरी है. जिन डिवाइसों पर Google Play services या GMS का पुराना वर्शन मौजूद है उन पर CreateCredentialProviderConfigurationException और GetCredentialProviderConfigurationException को कैच करें, ताकि आपका ऐप्लिकेशन स्टैंडर्ड साइन-इन पर वापस आ जाए.

ज़रूरी शर्तें

पासकी के सर्वर की तरह ही, WebAuthn रिलाइंग पार्टी सर्वर को कॉन्फ़िगर करें. अगर आपके पास पहले से ही पासकी की मदद से पुष्टि करने के लिए सेट अप किया गया कोई सर्वर है, तो रीस्टोर कुंजियों के लिए, WebAuthn रजिस्ट्रेशन और दावा करने वाले एंडपॉइंट का फिर से इस्तेमाल किया जा सकता है.

डिपेंडेंसी

अपने ऐप्लिकेशन मॉड्यूल की build.gradle फ़ाइल में, ये डिपेंडेंसी जोड़ें:

dependencies {
    implementation("androidx.credentials:credentials:1.7.0-alpha02")
    implementation("androidx.credentials:credentials-play-services-auth:1.7.0-alpha02")
}

dependencies {
    implementation "androidx.credentials:credentials:1.7.0-alpha02"
    implementation "androidx.credentials:credentials-play-services-auth:1.7.0-alpha02"
}

क्रेडेंशियल वापस लाने की सुविधा, androidx.credentials लाइब्रेरी के 1.5.0 और इसके बाद के वर्शन पर उपलब्ध है. हालांकि, हमारा सुझाव है कि जहां भी हो सके, डिपेंडेंसी के सबसे नए स्टेबल वर्शन का इस्तेमाल करें.

android:allowBackup से, क्रेडेंशियल रीस्टोर करने की सुविधा पर क्या असर पड़ता है

android:allowBackup मेनिफ़ेस्ट एट्रिब्यूट, ऐप्लिकेशन के डेटा के बैकअप को कंट्रोल करता है. यह Restore Credentials के साथ तीन अलग-अलग तरीकों से इंटरैक्ट करता है:

• कुंजी ट्रांसफ़र करने की सुविधा को पहले जैसा करना (allowBackup से अलग): Google Play services, पूरी तरह सुरक्षित क्लाउड बैकअप या डिवाइस से डिवाइस (डी2डी) पर डेटा ट्रांसफ़र करने की सुविधा का इस्तेमाल करके, RestoreCredential कुंजी का जोड़ा ट्रांसफ़र करती है. इससे कोई फ़र्क़ नहीं पड़ता कि android:allowBackup, true है या false. D2D ट्रांसफ़र के लिए, रीस्टोर कुंजी हमेशा ट्रांसफ़र होती है. यह सिर्फ़ तब ट्रांसफ़र नहीं होती, जब उपयोगकर्ता ने Android की सेटिंग में जाकर, क्लाउड बैकअप से ऑप्ट आउट किया हो.
• BackupAgent में बैकग्राउंड में डेटा वापस लाने की सुविधा (इसके लिए, android:allowBackup="true" ज़रूरी है): उपयोगकर्ता के नए डिवाइस (BackupAgent.onRestoreFinished()) पर ऐप्लिकेशन खोलने से पहले, बैकग्राउंड में साइन-इन करने की सुविधा सिर्फ़ तब काम करती है, जब आपके मेनिफ़ेस्ट में android:allowBackup="true" और android:backupAgent को कॉन्फ़िगर किया गया हो. अगर android:allowBackup="false", तो जब उपयोगकर्ता पहली बार आपका मुख्य Activity लॉन्च करे, तब सेशन को रीस्टोर करें. रिस्टोरेशन को ज़्यादा बेहतर बनाने के लिए, दोनों तरीकों को भी लागू किया जा सकता है.
• Android Studio में क्लाउड बैकअप की जांच करना (इसके लिए, android:allowBackup="true" ज़रूरी है): Android Studio के बैकअप और रीस्टोर टूल में, क्लाउड बैकअप टाइप की जांच करने के लिए, android:allowBackup="true" ज़रूरी है. हालांकि, एक डिवाइस से दूसरे डिवाइस पर डेटा ट्रांसफ़र करने की जांच करने के लिए, allowBackup की ज़रूरत नहीं होती.

खास जानकारी

क्रेडेंशियल रीस्टोर करने की सुविधा, उपयोगकर्ता के पुराने और नए डिवाइसों पर तीन चरणों वाली लाइफ़साइकल को फ़ॉलो करती है:

1. पिछले डिवाइस पर, डेटा वापस पाने के लिए पासकी बनाएं: उपयोगकर्ता के साइन इन करने के बाद (या ऐप्लिकेशन के स्टार्टअप पर, अगर उपयोगकर्ता ने पहले से साइन इन किया हुआ है और लोकल स्टोरेज में डेटा वापस पाने के लिए कोई पासकी रिकॉर्ड नहीं की गई है), तो रिलाइंग पार्टी सर्वर से पासकी बनाने के विकल्प फ़ेच करें और credentialManager.createCredential() को कॉल करें.
2. नए डिवाइस पर रीस्टोर कुंजी की मदद से साइन इन करना: ट्रांसफ़र किए गए RestoreCredential को वापस पाने के लिए, दो चरणों वाली रणनीति का इस्तेमाल करें: पहला, BackupAgent.onRestoreFinished() में बैकग्राउंड में (जब android:allowBackup="true"), ताकि बैकग्राउंड सिंक और पुश नोटिफ़िकेशन तुरंत फिर से शुरू हो जाएं. दूसरा, ऐप्लिकेशन को पहली बार लॉन्च करने पर, लॉन्चर Activity.onCreate() में फ़ॉलबैक के तौर पर.
3. साइन-आउट करने पर, डेटा वापस पाने की कुंजी मिटाएं: जब उपयोगकर्ता साइन आउट करता है या सर्वर उसके सेशन को अमान्य कर देता है, तो ClearCredentialStateRequest(ClearCredentialStateRequest.TYPE_CLEAR_RESTORE_CREDENTIAL) के साथ credentialManager.clearCredentialState() को कॉल करें और अपने लोकल सिंक फ़्लैग को मिटाएं.

रिस्टोर कुंजी बनाना

आपके ऐप्लिकेशन को उपयोगकर्ता के साइन इन करने के सभी मामलों को कवर करना चाहिए, ताकि यह पक्का किया जा सके कि सक्रिय उपयोगकर्ताओं के लिए रीस्टोर करने की कुंजी बनाई गई है. रीस्टोर पासकोड इन स्थितियों में बनाएं:

• अगर उपयोगकर्ता ने साइन इन किया हुआ है और पहले से कोई रीस्टोर कुंजी नहीं बनाई गई है, तो मुख्य Activity के लिए onCreate() तरीके का इस्तेमाल करें.
• जब उपयोगकर्ता साइन इन कर रहा हो या नए खाते के लिए रजिस्ट्रेशन की प्रोसेस पूरी कर रहा हो.

हर बार ऐप्लिकेशन लॉन्च होने पर createCredential() को कॉल करने से बचने के लिए, लोकल स्टोरेज में has_synced_restore_credential जैसा लोकल सिंक फ़्लैग सेव करें. इस फ़्लैग को डिफ़ॉल्ट रूप से बैकअप लिए गए SharedPreferences या DataStore में तब तक सेव न करें, जब तक कि उस फ़ाइल को data_extraction_rules.xml में शामिल न किया गया हो. ऐसा न करने पर, ऑटो बैकअप की सुविधा has_synced_restore_credential = true को नए डिवाइस पर कॉपी कर देती है. साथ ही, नए डिवाइस को अपनी रीस्टोर कुंजी जनरेट करने या उसे बदलने से रोकती है.

Credential Manager को इंस्टैंशिएट करना

CredentialManager ऑब्जेक्ट को इंस्टैंशिएट करने के लिए, अपने ऐप्लिकेशन की गतिविधि के कॉन्टेक्स्ट का इस्तेमाल करें.

// Use your app or activity context to instantiate a client instance of
// CredentialManager.
private val credentialManager = CredentialManager.create(context)

अपने ऐप्लिकेशन सर्वर से क्रेडेंशियल बनाने के विकल्प पाना

अपने क्लाइंट ऐप्लिकेशन को, क्रेडेंशियल वापस लाने के लिए ज़रूरी PublicKeyCredentialCreationOptions JSON भेजने के लिए, अपने ऐप्लिकेशन सर्वर में FIDO के मुताबिक लाइब्रेरी का इस्तेमाल करें. सर्वर-साइड पर लागू करने के बारे में ज़्यादा जानकारी के लिए, सर्वर-साइड से जुड़े दिशा-निर्देश देखें.

पासकी बनाने के विकल्पों का JSON, पासकी रजिस्ट्रेशन के स्ट्रक्चर जैसा ही होता है:

{
  "challenge": "<base64url-encoded challenge>",
  "rp": {
    "name": "<relying party name>",
    "id": "<relying party host name>"
  },
  "user": {
    "id": "<base64url-encoded user ID>",
    "name": "<user name>",
    "displayName": "<user display name>"
  },
  "pubKeyCredParams": [
    {
      "type": "public-key",
      "alg": -7
    }
  ],
  "attestation": "none",
  "excludeCredentials": [
    {
        "id": "<base64url-encoded credential ID to exclude>", 
        "type": "public-key"
    }
  ],
  "authenticatorSelection": {
    "requireResidentKey": true,
    "residentKey": "required",
    "userVerification": "required"
  }
}

पक्का करें कि क्रिएशन विकल्प JSON इन ज़रूरी शर्तों को पूरा करता हो:

• challenge और user.id: दोनों वैल्यू को अनपैडेड Base64URL स्ट्रिंग के तौर पर कोड में बदलें. इसके लिए, + को - से और / को _ से बदलें. साथ ही, आखिर में मौजूद = को हटाएं. स्टैंडर्ड Base64 वर्णों या रॉ इंटिजर आईडी की वजह से, CreateRestoreCredentialDomException या IllegalArgumentException गड़बड़ी होती है.
• rp.id: इसे अपनी रिलाइंग पार्टी के डोमेन पर सेट करें (उदाहरण के लिए, example.com).
• pubKeyCredParams: {"type": "public-key", "alg": -7} (ES256) और {"type": "public-key", "alg": -257} (RS256) को शामिल करें.

रीस्टोर कुंजी बनाना

अपने सर्वर से सार्वजनिक पासकोड बनाने के विकल्पों का JSON मिलने के बाद, JSON को CreateRestoreCredentialRequest ऑब्जेक्ट में रैप करें. इसके बाद, CredentialManager ऑब्जेक्ट पर createCredential() को कॉल करें.

// requestJson contains the credential creation options sent by the server
val createRestoreRequest = CreateRestoreCredentialRequest(requestJson)
val response = try {
    credentialManager.createCredential(context, createRestoreRequest)
} catch (e: E2eeUnavailableException) {
    // Fall back to local device-to-device (D2D) restore if cloud E2EE is unavailable
    credentialManager.createCredential(
        context,
        CreateRestoreCredentialRequest(requestJson, isCloudBackupEnabled = false),
    )
}

कोड के बारे में अहम बातें

• CreateRestoreCredentialRequest ऑब्जेक्ट में ये फ़ील्ड शामिल होते हैं:

  • requestJson: क्रेडेंशियल बनाने के विकल्प, जिन्हें ऐप्लिकेशन सर्वर ने PublicKeyCredentialCreationOptionsJSON के लिए वेब ऑथेंटिकेशन एपीआई फ़ॉर्मैट में भेजा है.

  • isCloudBackupEnabled: Boolean फ़ील्ड, जिससे यह तय किया जाता है कि रीस्टोर कुंजी का बैकअप क्लाउड में लिया जाना चाहिए या नहीं. डिफ़ॉल्ट रूप से, यह फ़्लैग true पर सेट होता है. इस फ़ील्ड में ये वैल्यू होती हैं:

    • true: (सुझाया गया) इस वैल्यू की मदद से, रीस्टोर की कुंजियों का बैकअप क्लाउड पर लिया जा सकता है. हालांकि, इसके लिए ज़रूरी है कि उपयोगकर्ता ने Google बैकअप और पूरी तरह सुरक्षित होने की सुविधा चालू की हो. जैसे, स्क्रीन लॉक.
    • false: इस वैल्यू से, डिजिटल बटन को क्लाउड के बजाय डिवाइस में सेव किया जाता है. अगर उपयोगकर्ता क्लाउड से डेटा वापस पाने का विकल्प चुनता है, तो नए डिवाइस पर कुंजी उपलब्ध नहीं होती. हालांकि, केबल या वाई-फ़ाई की मदद से डिवाइस-टू-डिवाइस (डी2डी) सेटअप के दौरान, यह अब भी ट्रांसफ़र होती है.

क्रेडेंशियल बनाने के रिस्पॉन्स को मैनेज करना

Credential Manager API, CreateRestoreCredentialResponse टाइप का रिस्पॉन्स दिखाता है. इस रिस्पॉन्स में, सार्वजनिक पासकोड क्रेडेंशियल के रजिस्ट्रेशन का रिस्पॉन्स JSON फ़ॉर्मैट में होता है.

अपने ऐप्लिकेशन से response.registrationResponseJson को रिलाइंग पार्टी सर्वर पर भेजें, ताकि उपयोगकर्ता के खाते के साथ-साथ सार्वजनिक पासकोड की पुष्टि की जा सके और उसे सेव किया जा सके. इसके बाद, लोकल स्टोरेज में अपने लोकल सिंक मार्कर को रिकॉर्ड करें. सर्वर साइड से की जाने वाली पुष्टि के बारे में ज़्यादा जानने के लिए, पासकी से जुड़े दिशा-निर्देश देखें.

रिस्टोर कुंजी बनाने की प्रोसेस के दौरान, इन अपवादों को मैनेज करें:

• CreateRestoreCredentialDomException: यह अपवाद तब होता है, जब requestJson अमान्य हो और PublicKeyCredentialCreationOptionsJSON के लिए WebAuthn फ़ॉर्मैट का पालन न करता हो.
• E2eeUnavailableException: यह अपवाद तब होता है, जब isCloudBackupEnabled की वैल्यू true हो, लेकिन उपयोगकर्ता के डिवाइस में डेटा बैकअप या एंड-टू-एंड एन्क्रिप्शन (E2EE) की सुविधा न हो. जैसे, स्क्रीन लॉक.
  यह पक्का करने के लिए कि क्लाउड ई2ईई उपलब्ध न होने पर भी, एक डिवाइस से दूसरे डिवाइस (डी2डी) पर डेटा ट्रांसफ़र करने के लिए, क्रेडेंशियल वापस लाने की सुविधा उपलब्ध हो, E2eeUnavailableException को कैच करें और CreateRestoreCredentialRequest(requestJson, isCloudBackupEnabled = false) के साथ createCredential() को तुरंत फिर से आज़माएं.
• IllegalArgumentException: यह गड़बड़ी तब होती है, जब requestJson खाली हो, मान्य JSON न हो या उसमें मान्य Base64URL-एन्कोडेड user.id न हो, जो WebAuthn स्पेसिफ़िकेशन के मुताबिक हो.

रीस्टोर कुंजी की मदद से साइन इन करना

डिवाइस सेटअप करने की प्रोसेस के दौरान, उपयोगकर्ता को बैकग्राउंड में साइन इन कराने के लिए, क्रेडेंशियल रीस्टोर करने की सुविधा का इस्तेमाल करें.

ऐप्लिकेशन सर्वर से क्रेडेंशियल वापस पाने के विकल्प पाना

नए डिवाइस पर getCredential() को कॉल करने से पहले, अपने ऐप्लिकेशन सर्वर से WebAuthn PublicKeyCredentialRequestOptions JSON चैलेंज का अनुरोध करें. नए डिवाइस पर मौजूद ऐप्लिकेशन को अब तक यह नहीं पता होता कि कौनसा उपयोगकर्ता साइन इन कर रहा है. इसलिए, इस एंडपॉइंट को बिना पुष्टि वाला (उपयोगकर्ता के बिना खोजा जाने वाला) होना चाहिए. सर्वर से जुड़े दिशा-निर्देशों के लिए, पासकी से साइन इन करना और सर्वर-साइड की पुष्टि करने की गाइड देखें.

डेटा वापस पाने के विकल्पों वाले JSON का स्ट्रक्चर इस तरह का होता है:

{
  "challenge": "<your app challenge>",
  "allowCredentials": [],
  "rpId": "<your app server domain>"
}

अपने सर्वर पर, JSON फ़ॉर्मैट में डेटा वापस पाने के विकल्पों को इस तरह कॉन्फ़िगर करें:

• allowCredentials: इस फ़ील्ड को छोड़ दें या खाली कलेक्शन ([]) पास करें, क्योंकि खाते को वापस लाने से पहले उपयोगकर्ता के खाते की जानकारी नहीं होती. getCredential() के वापस आने के बाद, आपका सर्वर response.userHandle फ़ील्ड से उपयोगकर्ता की पहचान करता है. यह फ़ील्ड, खाता बनाते समय रजिस्टर किए गए user.id से मेल खाता है. इसके बाद, आपका सर्वर id (credentialId) से सार्वजनिक पासकोड को खोजता है.
• userVerification: इसे "discouraged" (या "preferred") पर सेट करें. क्रेडेंशियल वापस लाने की सुविधा, बायोमेट्रिक या स्क्रीन लॉक यूज़र इंटरफ़ेस (यूआई) के बिना बैकग्राउंड में काम करती है. इसलिए, Android, "required" को "discouraged" से बदल देता है. साथ ही, आपके सर्वर पर भेजे गए ऑथेंटिकेटर डेटा में, उपयोगकर्ता की पुष्टि हो गई (uv) फ़्लैग को false पर सेट किया जाता है. अपने WebAuthn सर्वर वेरिफ़ायर को कॉन्फ़िगर करें, ताकि वह कुंजी को वापस लाने के लिए uv = false को स्वीकार करे.

रीस्टोर करने के लिए पासकोड पाना

नए डिवाइस पर रीस्टोर पासकोड पाने के लिए, सर्वर के requestJson को GetCredentialRequest में मौजूद GetRestoreCredentialOption में रैप करें. इसके बाद, CredentialManager ऑब्जेक्ट पर getCredential() को कॉल करें.

दो चरणों वाली रीस्टोरेशन रणनीति लागू करें, ताकि उपयोगकर्ता साइन इन कर सकें. भले ही, बैकग्राउंड में ऐप्लिकेशन का डेटा रीस्टोर करने की सुविधा चालू हो या नहीं:

• टियर 1 (BackupAgent.onRestoreFinished() में बैकग्राउंड में डेटा वापस लाना): अगर ऐप्लिकेशन के डेटा का बैकअप लेने की सुविधा चालू है (android:allowBackup="true"), तो BackupAgent को सबक्लास करें और onRestoreFinished() को बदलें (onRestore() का इस्तेमाल न करें, जिसे सिर्फ़ लेगसी की-वैल्यू बैकअप के लिए कॉल किया जाता है). onRestoreFinished() सिंक्रोनस है और getCredential() एक Kotlin suspend फ़ंक्शन है. इसलिए, runBlocking(Dispatchers.IO) का इस्तेमाल करके कॉल को ब्रिज करें. रीस्टोर करने की कुंजी (क्रेडेंशियल) मौजूद न होने पर, NoCredentialException को चुपचाप पकड़ें.
• टियर 2 (लॉन्चर Activity.onCreate() में फ़ोरग्राउंड फ़ॉलबैक): जब कोई लोकल सेशन मौजूद न हो, तो पहली बार ऐप्लिकेशन लॉन्च करने पर, लॉगिन स्क्रीन दिखाने से पहले lifecycleScope से getCredential() को कॉल करें. यह android:allowBackup="false" वाले ऐप्लिकेशन को मैनेज करता है. साथ ही, अगर onRestoreFinished() के चलने के दौरान डिवाइस ऑफ़लाइन था, तो यह उसे वापस लाता है.

अगर किसी ऐसे ऐप्लिकेशन में नया BackupAgent जोड़ा जाता है जो पहले से ही android:allowBackup="true" के साथ ऑटो बैकअप का इस्तेमाल करता है, तो AndroidManifest.xml में <application> एलिमेंट पर android:fullBackupOnly="true" भी सेट करें. इससे Android, लेगसी की-वैल्यू बैकअप पर स्विच करने के बजाय, ऑटो बैकअप का इस्तेमाल जारी रखेगा.

    suspend fun getRestoreKey(
        fetchAuthenticationJson: () -> String,
    ) {
        // Fetch the options required to get the restore key
        val authenticationJson = fetchAuthenticationJson()

        // Create the GetRestoreCredentialOption object
        val options = GetRestoreCredentialOption(authenticationJson)
        val getRequest = GetCredentialRequest(listOf(options))

        try {
            val response = credentialManager.getCredential(context, getRequest)

            // Type-check and extract the restore credential
            val credential = response.credential
            if (credential is RestoreCredential) {
                val responseJson = credential.authenticationResponseJson
            }
        } catch (e: NoCredentialException) {
            // No restore key is present on this device
        }
    }

class MyBackupAgent : BackupAgent() {

    override fun onRestoreFinished() {
        super.onRestoreFinished()
        val credentialManager = CredentialManager.create(this)
        val restoreFunctions = RestoreCredentialsFunctions(this, credentialManager)

        runBlocking(Dispatchers.IO) {
            restoreFunctions.getRestoreKey(
                fetchAuthenticationJson = {
                    /* Fetch challenge JSON from server */ ""
                }
            )
        }
    }
}

Credential Manager API, GetCredentialResponse दिखाता है. इसकी credential प्रॉपर्टी, RestoreCredential होती है, न कि PublicKeyCredential. इसमें authenticationResponseJson शामिल होता है.

साइन-इन के जवाब को मैनेज करना

ऐप्लिकेशन से restoreCredential.authenticationResponseJson को अपने रिलाइंग पार्टी सर्वर पर भेजें, ताकि क्रिप्टोग्राफ़िक दावे की पुष्टि की जा सके और उपयोगकर्ता के लिए नया सेशन टोकन जारी किया जा सके. सर्वर साइड से की जाने वाली पुष्टि के बारे में ज़्यादा जानने के लिए, पासकी की मदद से साइन इन करना लेख पढ़ें.

रिस्टोर की जाने वाली कुंजियों के लिए, बैकएंड स्टोरेज और लाइफ़साइकल की नीतियां डिज़ाइन करते समय, इन दिशा-निर्देशों का पालन करें:

• रीस्टोर की को उपयोगकर्ता की पासकी से अलग करना: अपने डेटाबेस में रीस्टोर की को टैग करें, ताकि वे इस्तेमाल करने वाले लोगों के लिए उपलब्ध पासकी मैनेजमेंट स्क्रीन से छिपी रहें. साथ ही, उपयोगकर्ता की पुष्टि (uv = true) करने की जांच से छूट मिल सके.
• हर उपयोगकर्ता के लिए, एक से ज़्यादा चालू डिवाइसों पर काम करना: किसी उपयोगकर्ता के पास एक से ज़्यादा डिवाइस हो सकते हैं. जैसे, फ़ोन और टैबलेट. हर उपयोगकर्ता खाते के लिए, एक से ज़्यादा चालू रीस्टोर कुंजियों की अनुमति दें. उदाहरण के लिए, किसी एक लाइन को ओवरराइट करने के बजाय, डिवाइस या इंस्टॉलेशन आईडी के हिसाब से कुंजी असाइन करें.
• सही टीटीएल सेट करें और ऐसी कुंजियां मिटाएं जिनका इस्तेमाल नहीं किया जा रहा है: किसी ऐप्लिकेशन को अनइंस्टॉल करने या उसका डेटा मिटाने पर, आपके सर्वर को सूचना दिए बिना, लोकल रीस्टोर कुंजी मिट जाती है. रीस्टोर पासकोड को लंबे समय तक सेव रखें, ताकि डिवाइस अपग्रेड विंडो के दौरान उनका इस्तेमाल किया जा सके. भले ही, उपयोगकर्ता ने डेटा ट्रांसफ़र करने के बाद पुराने डिवाइस से साइन आउट कर दिया हो. साथ ही, इस्तेमाल न होने की वजह से एक्सपायर हो चुके पासकोड या हर उपयोगकर्ता के लिए तय की गई पासकोड की सीमा के आधार पर, पुराने पासकोड मिटाएं.

रीस्टोर करने के लिए इस्तेमाल होने वाली कुंजी मिटाना

Credential Manager स्टेटलेस है और उपयोगकर्ता गतिविधि के बारे में नहीं जानता, इसलिए यह इस्तेमाल के बाद, रीस्टोर कुंजियों को अपने-आप नहीं मिटाता. रीस्टोर कुंजी को मिटाने के लिए, clearCredentialState() तरीके को कॉल करें. सुरक्षा के लिए, जब भी कोई उपयोगकर्ता साइन आउट करे, तो पासकोड मिटा दें. इससे, अगली बार ऐप्लिकेशन लॉन्च होने पर, वह उपयोगकर्ता अपने-आप साइन इन नहीं होगा.

रीस्टोर बटन सिर्फ़ इन स्थितियों में हटाए जाते हैं:

• सिस्टम-लेवल की कार्रवाइयां: उपयोगकर्ता, ऐप्लिकेशन को अनइंस्टॉल करते हैं या उसका डेटा मिटाते हैं.
• ऐप्लिकेशन-लेवल कॉल: अपने ऐप्लिकेशन के कोड में उपयोगकर्ता के साइन-आउट को मैनेज करते समय, clearCredentialState() को कॉल करके, कुंजी को प्रोग्राम के हिसाब से मिटाएं.

डिफ़ॉल्ट ClearCredentialStateRequest() सिर्फ़ स्टैंडर्ड सेशन की स्थिति को मिटाता है और रीस्टोर कुंजी को बरकरार रखता है. इसलिए, साइन-आउट करने पर दोनों को मिटाएं:

1. क्रेडेंशियल उपलब्ध कराने वाली सेवा के चालू सेशन की स्थिति को मिटाने के लिए, credentialManager.clearCredentialState(ClearCredentialStateRequest()) को कॉल करें.
2. सेव किए गए RestoreCredential को मिटाने के लिए, ClearCredentialStateRequest(ClearCredentialStateRequest.TYPE_CLEAR_RESTORE_CREDENTIAL) से credentialManager.clearCredentialState() पर कॉल करें.
3. लोकल स्टोरेज से, लोकल has_synced_restore_credential मार्कर को मिटाएं.

// Clear active credential provider session state
credentialManager.clearCredentialState(ClearCredentialStateRequest())

// When the user logs out, delete the restore key
val clearRequest = ClearCredentialStateRequest(TYPE_CLEAR_RESTORE_CREDENTIAL)
val response = credentialManager.clearCredentialState(clearRequest)

अगले चरण

• क्रेडेंशियल रीस्टोर करने की सुविधा की जांच करना: Android Studio या adb shell bmgr का इस्तेमाल करके, क्लाउड और एक डिवाइस से दूसरे डिवाइस (डी2डी) पर डेटा ट्रांसफ़र करने की सुविधा की जांच करें.
• अपने-आप बैकअप लेने और उसे वापस लाने की सुविधा की जांच करना: सीआई में CLOUD_ENCRYPTED और DEVICE_TO_DEVICE को वापस लाने की सुविधा की पुष्टि करने के लिए, BackupRestoreController के साथ JUnit 5 होस्ट टेस्ट लिखें.