नेटिव ऐप पासकीज़ के लिए पासवर्ड मैनेजर टेस्टिंग

1. परिचय: नेटिव ऐप्स पासकीज़ और थर्ड-पार्टी पासवर्ड मैनेजर्स#

iOS 17 और Android 14 के रिलीज़ होने के साथ, नेटिव मोबाइल ऐप्स के लिए पासकी लैंडस्केप मौलिक रूप से बदल गया है। पहली बार, थर्ड-पार्टी पासवर्ड मैनेजर पासकी प्रोवाइडर के रूप में काम कर सकते हैं, जिससे iCloud Keychain और Google Password Manager की विशेष पकड़ टूट गई है। यह उपयोगकर्ताओं को 1Password, Bitwarden, या Dashlane जैसे अपने स्वयं के विश्वसनीय समाधानों को नेटिव ऐप ऑथेंटिकेशन फ़्लो में लाने की अनुमति देता है। हालांकि यह उपयोगकर्ता की पसंद के लिए एक बड़ी जीत है, लेकिन यह डेवलपर्स के लिए महत्वपूर्ण जटिलता भी लाता है। आपका पासकी कार्यान्वयन नेटिव मोबाइल एप्लिकेशन में विभिन्न पासवर्ड मैनेजर्स में अलग तरह से व्यवहार कर सकता है। इसलिए किसी भी टीम के लिए नेटिव ऐप पासकीज़ और थर्ड-पार्टी पासवर्ड मैनेजर्स का ठीक से परीक्षण करना महत्वपूर्ण है।

यह व्यापक गाइड थर्ड-पार्टी पासवर्ड मैनेजर्स के साथ नेटिव ऐप पासकी टेस्टिंग के लिए हमारे बैटल-टेस्टेड दृष्टिकोण को साझा करती है। हालांकि पासकी इकोसिस्टम 2025 में काफी परिपक्व हो गया है, वास्तविक दुनिया के कार्यान्वयन के लिए अभी भी विविध पासवर्ड मैनेजर कार्यान्वयनों में सावधानीपूर्वक सत्यापन की आवश्यकता है। हमने अपने अनुभव को एक व्यावहारिक टेस्ट प्लान में ढाला है जो सुनिश्चित करता है कि आपका नेटिव ऐप उपयोगकर्ताओं के पसंदीदा पासवर्ड मैनेजर्स के साथ निर्बाध रूप से काम करता है।

2. प्रोडक्शन में पासकी टेस्टिंग क्यों मायने रखती है#

2.1 उपयोगकर्ता अपना स्वयं का पासवर्ड मैनेजर लाते हैं#

पासवर्ड मैनेजर इकोसिस्टम प्लेटफ़ॉर्म-नेटिव समाधानों से आगे विकसित हो गया है। उपयोगकर्ता सक्रिय रूप से अपनी विशिष्ट आवश्यकताओं के आधार पर 1Password, Bitwarden, Dashlane, Proton Pass और NordPass जैसे थर्ड-पार्टी पासवर्ड मैनेजर्स चुनते हैं, जैसे कि क्रॉस-प्लेटफ़ॉर्म सिंक, एंटरप्राइज़ सुविधाएँ या गोपनीयता प्राथमिकताएँ। आपके नेटिव iOS / Android ऐप को उपयोगकर्ताओं को अपने विश्वसनीय पासवर्ड प्रबंधन समाधान को बदलने के लिए मजबूर किए बिना इस विविधता को समायोजित करना होगा।

Corbado पेजों पर हमारे द्वारा मापे गए डेटा के आधार पर, हम देखते हैं कि केवल 5-10% सामान्य उपयोगकर्ता थर्ड-पार्टी पासवर्ड मैनेजर्स पर निर्भर करते हैं। भले ही यह संख्या कम लग सकती है, लेकिन अगर आप बड़े पैमाने के वातावरण में काम कर रहे हैं, तो इसका आपके पासकी कार्यान्वयन की धारणा और सपोर्ट टिकटों की संख्या पर बहुत बड़ा प्रभाव पड़ेगा। हमने देखा है कि कुछ पासवर्ड मैनेजर WebAuthn स्पेसिफिकेशन को थोड़ा अलग तरीके से लागू करते हैं, जिससे उपयोगकर्ता अनुभव में सूक्ष्म बदलाव या बग भी आते हैं।

2.2 नेटिव ऐप्स में विभिन्न UX पैटर्न#

नेटिव iOS और Android ऐप्स पासकी उपयोग के लिए अलग-अलग तरीके प्रदान करते हैं। Android पर, आपको पासकी ओवरले और मैनुअल टेक्स्ट-फ़ील्ड इनपुट का सामना करना पड़ेगा जो एक पासकी सेरेमनी को ट्रिगर करते हैं (वेब ऐप्स के लिए, Android Conditional UI का भी समर्थन करता है)। iOS Conditional UI और मैनुअल टेक्स्ट-फ़ील्ड इनपुट के साथ-साथ अपना स्वयं का पासकी ओवरले प्रस्तुत करता है। इसके अलावा, जाँचने के लिए अन्य एज केस भी हैं। कुल मिलाकर, आपके नेटिव एप्लिकेशन को इन चीज़ों को शालीनता से संभालना चाहिए:

• पासकी ओवरले लॉगिन जो पेज लोड होने पर तुरंत दिखाई देते हैं
• Conditional UI लॉगिन (केवल iOS) जो उपलब्ध पासकीज़ का स्वतः सुझाव देते हैं
• टेक्स्ट-फ़ील्ड लॉगिन जहाँ उपयोगकर्ता बटन पर क्लिक करने से पहले अपना उपयोगकर्ता नाम प्रदान करता है
• क्रॉस-डिवाइस ऑथेंटिकेशन (CDA) किसी अन्य डिवाइस के साथ पासकी के उपयोग के लिए
• फ़ॉलबैक मैकेनिज्म जब पासकी का उपयोग उपलब्ध नहीं होता है

2.3 WebAuthn फ्लैग्स को सटीकता की आवश्यकता होती है#

सही फ्लैग कॉन्फ़िगरेशन यह निर्धारित करता है कि पासकीज़ डिवाइस और प्लेटफ़ॉर्म पर अपेक्षा के अनुरूप काम करती हैं या नहीं। महत्वपूर्ण मानों में शामिल हैं:

• Relying Party ID (rpID): वेब और नेटिव कार्यान्वयन में बिल्कुल मेल खाना चाहिए और यह वह डोमेन है जिससे पासकी जुड़ी हुई है
• यूज़र वेरिफिकेशन: यह निर्धारित करता है कि उपयोगकर्ता को अपना लोकल ऑथेंटिकेशन प्रदान करने की आवश्यकता है
• रेजिडेंट की/डिस्कवरेबल क्रेडेंशियल्स: उपयोगकर्ता नाम-रहित ऑथेंटिकेशन को सक्षम करता है (Conditional UI के लिए अनुमति देता है)
• बैकअप एलिजिबिलिटी (BE) और बैकअप स्टेट (BS): पासकीज़ के क्रॉस-डिवाइस सिंक की अनुमति देता है

गलत कॉन्फ़िगर किए गए फ्लैग हमेशा तुरंत विफलता का कारण नहीं बनते हैं। हालाँकि, वे सूक्ष्म समस्याएं और विसंगतियां पैदा कर सकते हैं जैसे कि पासकीज़ एक डिवाइस पर उपलब्ध हैं लेकिन अन्य डिवाइस पर सिंक नहीं हैं (भले ही समान 3rd-पार्टी पासवर्ड मैनेजर दोनों डिवाइस पर उपलब्ध हो)। टेस्ट में हमारे निष्कर्षों में से एक यह था कि कुछ 3rd-पार्टी पासवर्ड मैनेजर BE/BS फ्लैग्स को गलत तरीके से सेट करते हैं और पासकी समस्याओं के एक बड़े हिस्से के लिए ज़िम्मेदार हैं।

2.4 सिंगल-इंस्टेंस ऐप्स में लाइफसाइकिल मैनेजमेंट#

सिंगल-एक्टिविटी (Android) और सिंगल-सीन (iOS) आर्किटेक्चर को सावधानीपूर्वक लाइफसाइकिल मैनेजमेंट की आवश्यकता होती है। जब एक पासवर्ड मैनेजर शीट दिखाई देती है और हटा दी जाती है, तो आपके ऐप को स्थिति संरक्षित करनी चाहिए, कॉलबैक को संभालना चाहिए, और सही ढंग से फिर से शुरू करना चाहिए। यह Android पर विशेष रूप से महत्वपूर्ण है, जहाँ launchMode कॉन्फ़िगरेशन अप्रत्याशित व्यवहार का कारण बन सकता है।

उदाहरण के लिए, हमने पाया कि MainActivity को launchMode="singleInstance" पर सेट करने से समस्याएँ पैदा हुईं। कुछ Android संस्करणों और OEM कस्टमाइज़ेशन पर, यह मोड Passkey Credential Manager UI को एक अलग टास्क के रूप में खोलने का कारण बनता है। यह न केवल "Recents" स्क्रीन में एक भ्रमित करने वाली, अतिरिक्त ऐप प्रविष्टि जोड़ता है, बल्कि अगर पासकी डायलॉग खुला रहने पर ऐप बैकग्राउंड में जाता है, तो यह ऐप को हैंग भी कर सकता है।

अनुशंसित सुधार कॉन्फ़िगरेशन को launchMode="singleTask" में बदलना है। यह Credential Manager को एक अलग टास्क स्पॉन करने से रोकता है, जिससे विभिन्न OEMs (Samsung, Google, Vivo, आदि) में अधिक पूर्वानुमानित लाइफसाइकिल सुनिश्चित होता है और वेंडर-विशिष्ट बग्स का जोखिम कम होता है। यह नेविगेशन, ओवरले और डीपलिंक्स के परीक्षण के लिए अधिक स्थिर आधार प्रदान करता है।

हमने देखा है कि ऐसी लाइफसाइकिल समस्याएँ अक्सर "पासवर्ड मैनेजर बग्स" के रूप में सामने आती हैं, जबकि वे वास्तव में एप्लिकेशन-स्तर की समस्याएँ होती हैं। विभिन्न प्रदाताओं में उचित इंस्ट्रूमेंटेशन और परीक्षण इन पैटर्न्स को जल्दी पहचानने में मदद करता है।

3. अपना टेस्ट वातावरण सेट अप करना#

3.1 टारगेट पासवर्ड मैनेजर्स#

अपने नेटिव ऐप पासकी टेस्टिंग को सबसे व्यापक रूप से अपनाए गए थर्ड-पार्टी पासवर्ड मैनेजर्स पर केंद्रित करें:

प्राथमिक लक्ष्य (आवश्यक कवरेज):

• 1Password
• Bitwarden
• Dashlane
• Proton Pass
• NordPass

द्वितीयक लक्ष्य (आपके उपयोगकर्ता आधार पर आधारित):

• क्षेत्रीय प्रदाता (जैसे, Samsung डिवाइस के लिए Samsung Pass)
• अगर बिज़नेस यूज़र्स को लक्षित कर रहे हैं तो एंटरप्राइज़ समाधान
• आधार रेखा के रूप में प्लेटफ़ॉर्म डिफ़ॉल्ट (Google Password Manager, iCloud Keychain)

प्रत्येक उपलब्ध पासवर्ड मैनेजर का परीक्षण करने के प्रलोभन से बचें। उन प्रदाताओं पर ध्यान दें जो आपके 90% उपयोगकर्ता आधार का प्रतिनिधित्व करते हैं। हमारे एनालिटिक्स ने दिखाया कि पांच प्राथमिक लक्ष्यों ने EU/USA/UK/AUS/NZ में 85% थर्ड-पार्टी पासवर्ड मैनेजर उपयोगकर्ताओं को कवर किया।

3.2 प्री-फ्लाइट चेकलिस्ट#

प्रत्येक टेस्ट रन शुरू करने से पहले, एक स्वच्छ, पुनरुत्पादनीय वातावरण सुनिश्चित करें:

1. क्रेडेंशियल स्थिति साफ़ करें:

• अपने RP ID के लिए सभी मौजूदा क्रेडेंशियल्स हटा दें
• ब्राउज़र और ऐप कैशे साफ़ करें
• पासवर्ड मैनेजर से पूरी तरह साइन आउट करें और वापस साइन इन करें
• टारगेट ऐप को फ़ोर्स-क्लोज़ करें और फिर से लॉन्च करें

2. टेस्ट वातावरण को स्थिर करें:

• स्थिर नेटवर्क कनेक्टिविटी सुनिश्चित करें (परीक्षण के दौरान कोई VPN नहीं)
• यदि परीक्षण स्वचालित कर रहे हैं तो UI एनिमेशन अक्षम करें
• सुसंगत डिवाइस ओरिएंटेशन का उपयोग करें
• OS संस्करण, ऐप संस्करण और पासवर्ड मैनेजर संस्करण का दस्तावेजीकरण करें

4. व्यापक टेस्ट प्लान#

प्रत्येक परीक्षण पासकी कार्यक्षमता के विशिष्ट पहलुओं को मान्य करता है। पास/फेल स्थिति और किसी भी विसंगतियों के लिए विस्तृत नोट्स का उपयोग करके व्यवस्थित रूप से परिणामों का दस्तावेजीकरण करें।

4.1 मुख्य ऑथेंटिकेशन फ़्लो टेस्ट#

टेस्ट 1: पासकी क्रिएशन रद्द करें (सफल पारंपरिक लॉगिन के बाद)#

सुचारू रद्दीकरण हैंडलिंग को मान्य करें

✓ पासवर्ड मैनेजर शीट सही ढंग से खुलती है
✓ उपयोगकर्ता पासकी बनाए बिना रद्द कर देता है
✓ ऐप लॉगिन स्क्रीन पर वापस आ जाता है ✓ पासवर्ड मैनेजर में कोई अनाथ क्रेडेंशियल नहीं है
✓ UI उपयुक्त रिट्राई विकल्प प्रदर्शित करता है

टेस्ट 2: पासकी बनाएं (सफल पारंपरिक लॉगिन के बाद)#

ऑथेंटिकेशन फ़्लो के बाद पासकी निर्माण सत्यापित करें

✓ लोकल ऑथेंटिकेशन मज़बूती से लॉन्च होता है
✓ बायोमेट्रिक ऑथेंटिकेशन सफलतापूर्वक पूरा होता है
✓ सही RP ID के साथ क्रेडेंशियल बनाया गया
✓ ऐप बिना लूप के प्रमाणित स्थिति में आ जाता है

टेस्ट 3: मौजूदा पासकी के साथ ऑथेंटिकेट करें#

मानक ऑथेंटिकेशन परिदृश्यों का परीक्षण करें

✓ पासकी ओवरले UI दिखाई देता है या उपयोगकर्ता टेक्स्ट-फ़ील्ड परिदृश्य में उपयोगकर्ता नाम प्रदान करता है ✓ बायोमेट्रिक स्कैन और सिंगल बायोमेट्रिक प्रॉम्प्ट सफल ऑथेंटिकेशन की ओर ले जाता है
✓ कोई चयन लूप या शीट का फिर से प्रकट होना नहीं
✓ ऑथेंटिकेशन के बाद सत्र स्थिर रहता है

टेस्ट 4: सेटिंग्स से पासकी बनाएं#

इन-ऐप पासकी प्रबंधन को मान्य करें

✓ सही RP ID, डिस्कवरेबिलिटी और BE/BS फ्लैग्स
✓ क्रिएशन के बाद ऐप प्रमाणित रहता है
✓ पासवर्ड मैनेजर सही लेबल के साथ तुरंत अपडेट हो जाता है

टेस्ट 5: पासकी हटाएं और फिर से लॉगिन करने का प्रयास करें#

क्रेडेंशियल लाइफसाइकिल प्रबंधन का परीक्षण करें

✓ सेटिंग्स में पासकी हटाएं ✓ पासकी लॉगिन संभव नहीं है
✓ उपयुक्त फ़ॉलबैक विकल्प दिया गया है

4.2 क्रॉस-प्लेटफ़ॉर्म संगतता टेस्ट#

टेस्ट 6: वेब में नेटिव-निर्मित पासकी का उपयोग करें (समान डिवाइस)#

ऐप-टू-वेब पोर्टेबिलिटी को मान्य करें

✓ ब्राउज़र ऐप-निर्मित पासकीज़ को पहचानता है
✓ चयन शीट सही RP संबद्धता दिखाती है
✓ बिना QR/CDA चक्कर के ऑथेंटिकेशन पूरा होता है

टेस्ट 7: नेटिव ऐप में वेब-निर्मित पासकी का उपयोग करें#

वेब-टू-ऐप क्रेडेंशियल साझाकरण का परीक्षण करें

✓ ऐप चयन में वेब-निर्मित क्रेडेंशियल को सामने लाता है
✓ पहले प्रयास का ऑथेंटिकेशन सफल होता है
✓ कोई ज़बरन पासवर्ड फ़ॉलबैक नहीं

टेस्ट 8: क्रॉस-डिवाइस सिंक (मोबाइल से डेस्कटॉप)#

नेटिव ऐप से डेस्कटॉप ब्राउज़र में पासकी सिंक सत्यापित करें

✓ ऐप-निर्मित पासकी डेस्कटॉप पासवर्ड मैनेजर से सिंक होती है ✓ सिंक की गई पासकी डेस्कटॉप ब्राउज़र में निर्बाध रूप से काम करती है ✓ कोई QR कोड / क्रॉस-डिवाइस फ़्लो ट्रिगर नहीं होता है ✓ ऑथेंटिकेशन बिना किसी लूप या त्रुटि के पूरा होता है

टेस्ट 9: क्रॉस-डिवाइस सिंक (डेस्कटॉप से मोबाइल)#

डेस्कटॉप ब्राउज़र से नेटिव ऐप में पासकी सिंक सत्यापित करें

✓ डेस्कटॉप-निर्मित पासकी मोबाइल पासवर्ड मैनेजर से सिंक होती है ✓ नेटिव ऐप सही ढंग से सिंक की गई पासकी को सामने लाता है ✓ ऑथेंटिकेशन पासवर्ड फ़ॉलबैक के बिना सफल होता है ✓ लॉग्स दावे को सही क्रेडेंशियल ID से जोड़ते हैं

टेस्ट 10: वेब के लिए ऑथेंटिकेटर के रूप में मोबाइल#

फोन-एज़-सिक्योरिटी-की परिदृश्यों को मान्य करें

✓ फोन वेब CDA के लिए ऐप-निर्मित क्रेडेंशियल प्रदान करता है
✓ कोई झूठी "कोई पासकी उपलब्ध नहीं" त्रुटियाँ नहीं
✓ मोबाइल बायोमेट्रिक के बाद वेब सत्र पूरा होता है

5. आम समस्याएं और शमन रणनीतियाँ#

हमारे व्यापक परीक्षण से कई आवर्ती पैटर्न सामने आए जो थर्ड-पार्टी पासवर्ड मैनेजर पासकी एकीकरण को प्रभावित करते हैं:

क्रॉस-डिवाइस सिंक देरी#

समस्या: एक डिवाइस पर बनाए गए क्रेडेंशियल तुरंत दूसरे डिवाइस पर दिखाई नहीं दे सकते हैं।

समाधान: एक्सपोनेंशियल बैकऑफ़ के साथ रिट्राई लॉजिक लागू करें। सिंक देरी का अनुभव कर रहे उपयोगकर्ताओं के लिए मैन्युअल रीफ्रेश विकल्प प्रदान करें।

वर्ज़न-विशिष्ट व्यवहार#

समस्या: पासवर्ड मैनेजर का व्यवहार OS संस्करणों के बीच काफी भिन्न होता है, विशेष रूप से Android 14+ और iOS 17+ पर।

समाधान: एक संगतता मैट्रिक्स बनाए रखें और पहचाने गए OS संस्करण के आधार पर फ़्लो को समायोजित करें। इष्टतम अनुभव के लिए न्यूनतम संस्करण आवश्यकताओं पर विचार करें।

6. निष्कर्ष: प्रोडक्शन-रेडी पासकी सपोर्ट बनाना#

नेटिव ऐप्स में थर्ड-पार्टी पासवर्ड मैनेजर पासकी समर्थन को सफलतापूर्वक लागू करने के लिए व्यवस्थित परीक्षण और विस्तार पर ध्यान देने की आवश्यकता होती है। हमारी व्यापक टेस्ट प्लान, जिसे वास्तविक दुनिया के परीक्षण के माध्यम से परिष्कृत किया गया है, आपके पासकी एकीकरण को मान्य करने के लिए एक ठोस आधार प्रदान करती है।

प्रोडक्शन डिप्लॉयमेंट के लिए मुख्य बातें:

1. व्यवस्थित रूप से परीक्षण करें: हमारे टेस्ट प्लान को एक आधार रेखा के रूप में उपयोग करें, इसे अपने विशिष्ट उपयोग के मामलों के अनुकूल बनाएं
2. उपयोगकर्ता की पसंद का सम्मान करें: उन पासवर्ड मैनेजर्स का समर्थन करें जिन्हें आपके उपयोगकर्ता पसंद करते हैं, न कि केवल प्लेटफ़ॉर्म डिफ़ॉल्ट का
3. लगातार निगरानी करें: प्रोडक्शन में एज केस पकड़ने के लिए व्यापक लॉगिंग लागू करें
4. पूरी तरह से दस्तावेजीकरण करें: प्रदाता-विशिष्ट व्यवहारों और वर्कअराउंड्स का स्पष्ट रिकॉर्ड बनाए रखें

पासकी इकोसिस्टम का तेज़ी से विकास जारी है। पासवर्ड मैनेजर नियमित रूप से अपने कार्यान्वयन को अपडेट करते हैं, ऑपरेटिंग सिस्टम नई सुविधाएँ पेश करते हैं, और WebAuthn विशिष्टता स्वयं उन्नत होती है। अब एक मजबूत परीक्षण ढांचा स्थापित करके, आप प्रौद्योगिकी के परिपक्व होने पर अनुकूलन करने के लिए तैयार होंगे।

जैसे-जैसे नए पैटर्न उभरते हैं, हम अपने SDKs और परीक्षण पद्धति को अपडेट करना जारी रखेंगे। व्यापक थर्ड-पार्टी पासवर्ड मैनेजर परीक्षण में निवेश से समर्थन का बोझ कम होता है और उपयोगकर्ता संतुष्टि में सुधार होता है। आख़िरकार, ऑथेंटिकेशन को बस काम करना चाहिए - चाहे आपके उपयोगकर्ता कोई भी पासवर्ड मैनेजर चुनें।

Corbado के बारे में

Corbado बड़े पैमाने पर consumer authentication चलाने वाली CIAM टीमों के लिए Authentication Intelligence Platform है। हम आपको वह दिखाते हैं जो IDP logs और सामान्य analytics tools नहीं दिखा सकते: कौन-से devices, OS versions, browsers और credential managers passkeys को support करते हैं, क्यों enrollments login में नहीं बदलते, WebAuthn flow कहाँ fail होता है, और कब कोई OS या browser update चुपचाप login को तोड़ देता है — और यह सब Okta, Auth0, Ping, Cognito या आपके in-house IDP को बदले बिना। दो products: Corbado Observe जोड़ता है passkeys और किसी भी अन्य login method के लिए observability। Corbado Connect देता है analytics के साथ built-in managed passkeys (आपके IDP के साथ-साथ)। VicRoads, Corbado के साथ 5M+ users के लिए passkeys चला रहा है (+80% passkey activation)। Passkey विशेषज्ञ से बात करें →

अक्सर पूछे जाने वाले प्रश्न#

नेटिव ऐप पासकीज़ का परीक्षण करते समय मुझे किन थर्ड-पार्टी पासवर्ड मैनेजर्स को प्राथमिकता देनी चाहिए?#

प्राथमिक लक्ष्यों के रूप में 1Password, Bitwarden, Dashlane, Proton Pass और NordPass को प्राथमिकता दें। ये पांच प्रदाता EU/USA/UK/AUS/NZ बाजारों में 85% थर्ड-पार्टी पासवर्ड मैनेजर उपयोगकर्ताओं को कवर करते हैं, जो लॉन्ग-टेल प्रदाताओं में अधिक निवेश किए बिना व्यापक कवरेज देते हैं।

थर्ड-पार्टी पासवर्ड मैनेजर का उपयोग करते समय किसी नेटिव ऐप में बनाई गई पासकी डिवाइसों में सिंक करने में विफल क्यों होती है?#

गलत बैकअप एलिजिबिलिटी (BE) और बैकअप स्टेट (BS) फ्लैग कॉन्फ़िगरेशन क्रॉस-डिवाइस सिंक विफलताओं का एक प्रमुख कारण है। कुछ थर्ड-पार्टी पासवर्ड मैनेजर इन फ्लैग्स को गलत तरीके से सेट करते हैं, इसलिए एक पासकी एक डिवाइस पर मौजूद होती है लेकिन दूसरों के साथ सिंक नहीं होती है, भले ही वही पासवर्ड मैनेजर दोनों पर इंस्टॉल हो।

मैं Android Credential Manager UI बग्स को कैसे ठीक करूँ जो Recents स्क्रीन में अलग टास्क के रूप में दिखाई देते हैं?#

MainActivity को launchMode singleInstance पर सेट करने से Credential Manager UI एक अलग टास्क के रूप में स्पॉन होता है, जिससे एक भ्रामक Recents प्रविष्टि बनती है और संभावित रूप से बैकग्राउंड में जाने पर ऐप हैंग हो जाता है। कॉन्फ़िगरेशन को launchMode singleTask में बदलने से Samsung, Google और Vivo सहित OEMs में इसका समाधान हो जाता है।

नेटिव iOS या Android ऐप में थर्ड-पार्टी पासवर्ड मैनेजर सपोर्ट को मान्य करते समय मुझे किन ऑथेंटिकेशन फ़्लो का परीक्षण करना चाहिए?#

एक व्यापक टेस्ट प्लान में 10 परिदृश्यों को शामिल किया गया है: पासकी क्रिएशन और शालीन रद्दीकरण, ओवरले और टेक्स्ट-फ़ील्ड ऑथेंटिकेशन, इन-ऐप क्रेडेंशियल प्रबंधन, फ़ॉलबैक के साथ क्रेडेंशियल हटाना और द्विदिश क्रॉस-डिवाइस सिंक। क्रॉस-प्लेटफ़ॉर्म परीक्षणों को भी पुष्टि करनी चाहिए कि ऐप-निर्मित पासकीज़ ब्राउज़र में ऑथेंटिकेट होती हैं और वेब-निर्मित पासकीज़ नेटिव ऐप में ऑथेंटिकेट होती हैं।