Android ऐप्लिकेशन के लिंक की पुष्टि करें

Android ऐप्लिकेशन लिंक, एक खास तरह का डीप लिंक होता है. इसकी मदद से, आपकी वेबसाइट के यूआरएल, आपके Android ऐप्लिकेशन में उससे जुड़ा कॉन्टेंट तुरंत खोल सकते हैं. इसके लिए, उपयोगकर्ता को ऐप्लिकेशन चुनने की ज़रूरत नहीं होती. Android ऐप्लिकेशन लिंक, Digital Asset Links API का इस्तेमाल करके यह भरोसा दिलाते हैं कि वेबसाइट ने आपके ऐप्लिकेशन को उस डोमेन के लिंक अपने-आप खोलने की अनुमति दी है. अगर सिस्टम यह पुष्टि कर लेता है कि आपके पास यूआरएल का मालिकाना हक है, तो सिस्टम उन यूआरएल इंटेंट को आपके ऐप्लिकेशन पर अपने-आप भेज देता है.

यह पुष्टि करने के लिए कि आपके पास ऐप्लिकेशन और वेबसाइट, दोनों के यूआरएल का मालिकाना हक है, यह तरीका अपनाएं:

  1. ऐसे इंटेंट फ़िल्टर जोड़ें जिनमें autoVerify एट्रिब्यूट शामिल हो. यह एट्रिब्यूट, सिस्टम को यह सिग्नल देता है कि उसे पुष्टि करनी चाहिए कि आपका ऐप्लिकेशन, आपके इंटेंट फ़िल्टर में इस्तेमाल किए गए यूआरएल डोमेन से जुड़ा है या नहीं.

  2. अपनी वेबसाइट और इंटेंट फ़िल्टर के बीच असोसिएशन की जानकारी दें. इसके लिए, यहां दी गई जगह पर डिजिटल ऐसेट लिंक की JSON फ़ाइल होस्ट करें:

    https://domain.name/.well-known/assetlinks.json

इस बारे में ज़्यादा जानकारी इन संसाधनों पर मिल सकती है:

ऐप्लिकेशन लिंक की पुष्टि के लिए इंटेंट फ़िल्टर जोड़ना

अपने ऐप्लिकेशन के लिए, लिंक हैंडल करने की पुष्टि करने की सुविधा चालू करने के लिए, ऐसे इंटेंट फ़िल्टर जोड़ें जो यहां दिए गए फ़ॉर्मैट से मेल खाते हों:

<!-- Make sure you explicitly set android:autoVerify to "true". -->
<intent-filter android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />

    <!-- If a user clicks on a shared link that uses the "http" scheme, your
         app should be able to delegate that traffic to "https". -->
    <!-- Do not include other schemes. -->
    <data android:scheme="http" />
    <data android:scheme="https" />

    <!-- Include one or more domains that should be verified. -->
    <data android:host="..." />
</intent-filter>

हर होस्ट के लिए, सिर्फ़ एक <intent-filter> एलिमेंट में autoVerify शामिल करना काफ़ी है. भले ही, उस होस्ट का इस्तेमाल बिना मार्क किए गए अन्य एलिमेंट में किया गया हो. हालांकि, हमारा सुझाव है कि आप हर <intent-filter> एलिमेंट में autoVerify जोड़ें, ताकि सभी एलिमेंट एक जैसे हों. इससे यह भी पक्का होता है कि मेनिफ़ेस्ट फ़ाइल में एलिमेंट हटाने या फिर से बनाने के बाद भी, आपका ऐप्लिकेशन उन सभी डोमेन से जुड़ा रहेगा जिन्हें आपने अब भी तय किया है.

डोमेन की पुष्टि करने के लिए, इंटरनेट कनेक्शन की ज़रूरत होती है. साथ ही, इस प्रोसेस को पूरा होने में कुछ समय लग सकता है. इस प्रोसेस को बेहतर बनाने के लिए, सिस्टम किसी ऐसे ऐप्लिकेशन के डोमेन की पुष्टि सिर्फ़ तब करता है जो Android 12 या उसके बाद के वर्शन को टारगेट करता है. ऐसा तब किया जाता है, जब वह डोमेन किसी ऐसे <intent-filter> एलिमेंट में हो जिसमें पिछले कोड स्निपेट में बताया गया सटीक फ़ॉर्मैट शामिल हो. उदाहरण के लिए, "http" और "https" के अलावा, <data android:scheme="custom" /> जैसे अन्य स्कीम, <intent-filter> को डोमेन की पुष्टि को ट्रिगर करने से रोकेंगे.

एक से ज़्यादा होस्ट के लिए, ऐप्लिकेशन लिंक करने की सुविधा

सिस्टम को ऐप्लिकेशन के यूआरएल इंटेंट फ़िल्टर के डेटा एलिमेंट में बताए गए होस्ट की पुष्टि करनी चाहिए. यह पुष्टि, उस इंटेंट फ़िल्टर में मौजूद वेब डोमेन पर होस्ट की गई डिजिटल एसेट लिंक फ़ाइलों के आधार पर की जानी चाहिए. अगर पुष्टि नहीं हो पाती है, तो सिस्टम डिफ़ॉल्ट रूप से अपने स्टैंडर्ड तरीके से काम करता है. ऐसा, ऐप्लिकेशन के कॉन्टेंट के लिए डीप लिंक बनाना में बताए गए तरीके के हिसाब से होता है. हालांकि, ऐप्लिकेशन के अन्य इंटेंट फ़िल्टर में तय किए गए किसी भी यूआरएल पैटर्न के लिए, ऐप्लिकेशन को डिफ़ॉल्ट हैंडलर के तौर पर पुष्टि की जा सकती है.

ध्यान दें: Android 11 (एपीआई लेवल 30) और उससे पहले के वर्शन पर, सिस्टम आपके ऐप्लिकेशन को डिफ़ॉल्ट हैंडलर के तौर पर तब तक नहीं मानता, जब तक उसे मेनिफ़ेस्ट में बताए गए सभी होस्ट के लिए, मैच करने वाली डिजिटल एसेट लिंक फ़ाइल नहीं मिल जाती.

उदाहरण के लिए, अगर किसी ऐप्लिकेशन में इन इंटेंट फ़िल्टर का इस्तेमाल किया गया है, तो सिर्फ़ https://www.example.com के लिए पुष्टि की जाएगी. ऐसा तब होगा, जब assetlinks.json फ़ाइल https://www.example.com/.well-known/assetlinks.json में मिल जाए, लेकिन https://www.example.net/.well-known/assetlinks.json में न मिले:

<application>

  <activity android:name=”MainActivity”>
    <intent-filter android:autoVerify="true">
      <action android:name="android.intent.action.VIEW" />
      <category android:name="android.intent.category.DEFAULT" />
      <category android:name="android.intent.category.BROWSABLE" />
      <data android:scheme="http" />
      <data android:scheme="https" />
      <data android:host="www.example.com" />
    </intent-filter>
  </activity>
  <activity android:name=”SecondActivity”>
    <intent-filter>
      <action android:name="android.intent.action.VIEW" />
      <category android:name="android.intent.category.DEFAULT" />
      <category android:name="android.intent.category.BROWSABLE" />
      <data android:scheme="https" />
     <data android:host="www.example.net" />
    </intent-filter>
  </activity>

</application>

ध्यान दें: एक ही इंटेंट फ़िल्टर में मौजूद सभी <data> एलिमेंट को एक साथ मर्ज कर दिया जाता है, ताकि उनके एट्रिब्यूट के सभी वैरिएंट को शामिल किया जा सके. उदाहरण के लिए, ऊपर दिए गए पहले इंटेंट फ़िल्टर में एक <data> एलिमेंट शामिल है, जो सिर्फ़ एचटीटीपीएस स्कीम के बारे में बताता है. हालांकि, इसे दूसरे <data> एलिमेंट के साथ जोड़ा जाता है, ताकि इंटेंट फ़िल्टर, http://www.example.com और https://www.example.com, दोनों के साथ काम कर सके. इसलिए, अगर आपको यूआरआई स्कीम और डोमेन के खास कॉम्बिनेशन तय करने हैं, तो आपको अलग-अलग इंटेंट फ़िल्टर बनाने होंगे.

एक से ज़्यादा सबडोमेन के लिए, ऐप्लिकेशन लिंक करने की सुविधा

डिजिटल एसेट लिंक प्रोटोकॉल, आपके इंटेंट फ़िल्टर में मौजूद सबडोमेन को यूनीक और अलग-अलग होस्ट के तौर पर मानता है. इसलिए, अगर आपके इंटेंट फ़िल्टर में अलग-अलग सबडोमेन वाले कई होस्ट शामिल हैं, तो आपको हर डोमेन पर मान्य assetlinks.json पब्लिश करना होगा. उदाहरण के लिए, यहां दिए गए इंटेंट फ़िल्टर में www.example.com और mobile.example.com को स्वीकार किए गए इंटेंट यूआरएल के होस्ट के तौर पर शामिल किया गया है. इसलिए, assetlinks.json को https://www.example.com/.well-known/assetlinks.json और https://mobile.example.com/.well-known/assetlinks.json, दोनों जगह पर पब्लिश करना ज़रूरी है.

<application>
  <activity android:name=”MainActivity”>
    <intent-filter android:autoVerify="true">
      <action android:name="android.intent.action.VIEW" />
      <category android:name="android.intent.category.DEFAULT" />
      <category android:name="android.intent.category.BROWSABLE" />
      <data android:scheme="https" />
      <data android:scheme="https" />
      <data android:host="www.example.com" />
      <data android:host="mobile.example.com" />
    </intent-filter>
  </activity>
</application>

इसके अलावा, अगर आपने वाइल्डकार्ड (जैसे, *.example.com) के साथ अपना होस्टनेम बताया है, तो आपको अपनी assetlinks.json फ़ाइल को रूट होस्टनेम (example.com) पर पब्लिश करना होगा. उदाहरण के लिए, नीचे दिए गए इंटेंट फ़िल्टर वाला ऐप्लिकेशन, example.com के किसी भी सब-नेम (जैसे, foo.example.com) की पुष्टि करेगा. हालांकि, इसके लिए ज़रूरी है कि assetlinks.json फ़ाइल को https://example.com/.well-known/assetlinks.json पर पब्लिश किया गया हो:

<application>
  <activity android:name=”MainActivity”>
    <intent-filter android:autoVerify="true">
      <action android:name="android.intent.action.VIEW" />
      <category android:name="android.intent.category.DEFAULT" />
      <category android:name="android.intent.category.BROWSABLE" />
      <data android:scheme="https" />
      <data android:host="*.example.com" />
    </intent-filter>
  </activity>
</application>

एक ही डोमेन से जुड़े कई ऐप्लिकेशन देखना

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

ऐसे मामले में, उपयोगकर्ता के डिवाइस पर ऐसे ऐप्लिकेशन देखें जो आपके ऐप्लिकेशन के साथ काम न कर रहे हों. ऐसा तब ही करें, जब आपके पास पैकेज के दिखने से जुड़ी ज़रूरी जानकारी हो. इसके बाद, अपने ऐप्लिकेशन में पसंद के मुताबिक चुने जाने वाले आइटम का डायलॉग बॉक्स दिखाएं. इसमें queryIntentActivities() को कॉल करने से मिले नतीजे शामिल होने चाहिए. उपयोगकर्ता, डायलॉग में दिखने वाले मिलते-जुलते ऐप्लिकेशन की सूची से अपना पसंदीदा ऐप्लिकेशन चुन सकता है.

वेबसाइट के असोसिएशन की जानकारी देना

आपकी वेबसाइट पर डिजिटल ऐसेट लिंक JSON फ़ाइल पब्लिश होनी चाहिए. इससे, वेबसाइट से जुड़े Android ऐप्लिकेशन के बारे में पता चलता है. साथ ही, ऐप्लिकेशन के यूआरएल इंटेंट की पुष्टि की जा सकती है. JSON फ़ाइल, इन फ़ील्ड का इस्तेमाल करके, ऐप्लिकेशन की पहचान करती है:

  • package_name: ऐप्लिकेशन की build.gradle फ़ाइल में बताया गया ऐप्लिकेशन आईडी.
  • sha256_cert_fingerprints: आपके ऐप्लिकेशन के साइनिंग सर्टिफ़िकेट के SHA256 फ़िंगरप्रिंट. Java keytool की मदद से फ़िंगरप्रिंट जनरेट करने के लिए, इस कमांड का इस्तेमाल किया जा सकता है:
    keytool -list -v -keystore my-release-key.keystore
    
    इस फ़ील्ड में कई फ़िंगरप्रिंट काम करते हैं. इनका इस्तेमाल, अपने ऐप्लिकेशन के अलग-अलग वर्शन के साथ काम करने के लिए किया जा सकता है. जैसे, डीबग और प्रोडक्शन बिल्ड.

    अगर आपने अपने ऐप्लिकेशन के लिए Play ऐप्लिकेशन साइनिंग का इस्तेमाल किया है, तो आम तौर पर keytool को स्थानीय तौर पर चलाने से जनरेट किया गया सर्टिफ़िकेट फ़िंगरप्रिंट, उपयोगकर्ताओं के डिवाइसों पर मौजूद फ़िंगरप्रिंट से मैच नहीं होगा. Release > Setup > App signing में जाकर, यह पुष्टि की जा सकती है कि आपने अपने Play Console डेवलपर खाते में, अपने ऐप्लिकेशन के लिए Play ऐप्लिकेशन साइनिंग का इस्तेमाल किया है या नहीं. अगर आपने ऐसा किया है, तो आपको उसी पेज पर अपने ऐप्लिकेशन के लिए सही डिजिटल ऐसेट लिंक JSON स्निपेट भी दिखेगा.

यहां दी गई उदाहरण assetlinks.json फ़ाइल, लिंक खोलने का ऐक्सेस com.example Android ऐप्लिकेशन को देती है:

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
  }
}]

किसी वेबसाइट को एक से ज़्यादा ऐप्लिकेशन से जोड़ना

कोई वेबसाइट, एक ही assetlinks.json फ़ाइल में कई ऐप्लिकेशन के साथ असोसिएशन का एलान कर सकती है. यहां दी गई फ़ाइल की सूची में, स्टेटमेंट फ़ाइल का एक उदाहरण दिया गया है. इसमें दो ऐप्लिकेशन के साथ अलग-अलग असोसिएशन की जानकारी दी गई है. यह फ़ाइल https://www.example.com/.well-known/assetlinks.json पर मौजूद है:

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example.puppies.app",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
  }
  },
  {
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example.monkeys.app",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
  }
}]

अलग-अलग ऐप्लिकेशन, एक ही वेब होस्ट के तहत अलग-अलग संसाधनों के लिंक हैंडल कर सकते हैं. उदाहरण के लिए, ऐप्लिकेशन 1, https://example.com/articles के लिए इंटेंट फ़िल्टर का एलान कर सकता है और ऐप्लिकेशन 2, https://example.com/videos के लिए इंटेंट फ़िल्टर का एलान कर सकता है.

ध्यान दें: किसी डोमेन से जुड़े एक से ज़्यादा ऐप्लिकेशन पर, एक ही या अलग-अलग सर्टिफ़िकेट से हस्ताक्षर किए जा सकते हैं.

एक ही ऐप्लिकेशन से कई वेबसाइटों को असोसिएट करना

कई वेबसाइटें अपनी assetlinks.json फ़ाइलों में, एक ही ऐप्लिकेशन के साथ असोसिएशन का एलान कर सकती हैं. यहां दी गई फ़ाइल लिस्टिंग में, उदाहरण के लिए, app1 के साथ example.com और example.net के असोसिएशन का एलान करने का तरीका बताया गया है. पहली लिस्टिंग में, example.com को ऐप्लिकेशन 1 से जोड़ा गया है:

https://www.example.com/.well-known/assetlinks.json

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.mycompany.app1",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
  }
}]

अगली लिस्टिंग में, example.net को app1 से असोसिएट किया गया है. इन फ़ाइलों को होस्ट करने की जगह (.com और .net) अलग-अलग होती है:

https://www.example.net/.well-known/assetlinks.json

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.mycompany.app1",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
  }
}]

पुष्टि करने वाली JSON फ़ाइल पब्लिश करना

आपको पुष्टि करने वाली JSON फ़ाइल को यहां पब्लिश करना होगा:

https://domain.name/.well-known/assetlinks.json

इन बातों का ध्यान रखें:

  • assetlinks.json फ़ाइल को content-type application/json के साथ दिखाया जाता है.
  • assetlinks.json फ़ाइल को एचटीटीपीएस कनेक्शन से ऐक्सेस किया जा सकता हो. इससे कोई फ़र्क़ नहीं पड़ता कि आपके ऐप्लिकेशन के इंटेंट फ़िल्टर, एचटीटीपीएस को डेटा स्कीम के तौर पर मानते हैं या नहीं.
  • assetlinks.json फ़ाइल को किसी दूसरे यूआरएल पर रीडायरेक्ट किए बिना ऐक्सेस किया जा सकता हो. इसमें, 301 या 302 रीडायरेक्ट भी शामिल हैं.
  • अगर आपके ऐप्लिकेशन के लिंक, एक से ज़्यादा होस्ट डोमेन के साथ काम करते हैं, तो आपको हर डोमेन पर assetlinks.json फ़ाइल पब्लिश करनी होगी. एक से ज़्यादा होस्ट के लिए, ऐप्लिकेशन लिंक करने की सुविधा देखें.
  • मेनिफ़ेस्ट फ़ाइल में ऐसे डेवलपर/टेस्ट यूआरएल के साथ अपना ऐप्लिकेशन पब्लिश न करें जिन्हें सार्वजनिक तौर पर ऐक्सेस नहीं किया जा सकता. जैसे, सिर्फ़ वीपीएन की मदद से ऐक्सेस किए जा सकने वाले यूआरएल. ऐसे मामलों में, बिल्ड वैरिएंट कॉन्फ़िगर करें, ताकि डेवलपर बिल्ड के लिए अलग मेनिफ़ेस्ट फ़ाइल जनरेट की जा सके.

Android ऐप्लिकेशन के लिंक की पुष्टि करना

जब आपके ऐप्लिकेशन के कम से कम एक इंटेंट फ़िल्टर में android:autoVerify="true" मौजूद होता है, तो Android 6.0 (एपीआई लेवल 23) या उसके बाद के वर्शन पर आपके ऐप्लिकेशन को इंस्टॉल करने पर, सिस्टम आपके ऐप्लिकेशन के इंटेंट फ़िल्टर में मौजूद यूआरएल से जुड़े होस्ट की अपने-आप पुष्टि कर लेता है. Android 12 और इसके बाद के वर्शन पर, पुष्टि करने के लॉजिक की जांच करने के लिए, पुष्टि करने की प्रोसेस को मैन्युअल तरीके से शुरू भी किया जा सकता है.

अपने-आप पुष्टि होना

सिस्टम की अपने-आप पुष्टि करने की सुविधा में ये शामिल हैं:

  1. सिस्टम उन सभी इंटेंट फ़िल्टर की जांच करता है जिनमें इनमें से कोई एक शामिल है:
    • काम: android.intent.action.VIEW
    • कैटगरी: android.intent.category.BROWSABLE और android.intent.category.DEFAULT
    • डेटा स्कीम: http या https
  2. ऊपर दिए गए इंटेंट फ़िल्टर में मिले हर यूनीक होस्ट नेम के लिए, Android https://hostname/.well-known/assetlinks.json पर मौजूद डिजिटल ऐसेट लिंक फ़ाइल के लिए, उनसे जुड़ी वेबसाइटों से क्वेरी करता है.

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

adb shell am start -a android.intent.action.VIEW \
    -c android.intent.category.BROWSABLE \
    -d "http://domain.name:optional_port"

मैन्युअल तरीके से पुष्टि करना

Android 12 में, किसी डिवाइस पर इंस्टॉल किए गए ऐप्लिकेशन के लिए, मैन्युअल रूप से डोमेन की पुष्टि की जा सकती है. भले ही, आपका ऐप्लिकेशन Android 12 को टारगेट करता हो या नहीं, फिर भी यह प्रोसेस की जा सकती है.

इंटरनेट कनेक्शन जोड़ना

डोमेन की पुष्टि करने के लिए, आपका टेस्ट डिवाइस इंटरनेट से कनेक्ट होना चाहिए.

डोमेन की पुष्टि करने की अपडेट की गई प्रोसेस के साथ काम करना

अगर आपका ऐप्लिकेशन Android 12 या उसके बाद के वर्शन को टारगेट करता है, तो सिस्टम अपने-आप डोमेन की पुष्टि करने की अपडेट की गई प्रोसेस का इस्तेमाल करता है.

इसके अलावा, पुष्टि करने की अपडेट की गई प्रोसेस को मैन्युअल तरीके से भी चालू किया जा सकता है. ऐसा करने के लिए, टर्मिनल विंडो में यह कमांड चलाएं:

adb shell am compat enable 175408749 PACKAGE_NAME

किसी डिवाइस पर Android ऐप्लिकेशन लिंक की स्थिति रीसेट करना

किसी डिवाइस पर डोमेन की पुष्टि मैन्युअल तरीके से शुरू करने से पहले, आपको टेस्ट डिवाइस पर Android ऐप्लिकेशन लिंक की स्थिति को रीसेट करना होगा. ऐसा करने के लिए, टर्मिनल विंडो में यह कमांड चलाएं:

adb shell pm set-app-links --package PACKAGE_NAME 0 all

यह निर्देश, डिवाइस को उसी स्थिति में ले जाता है जिसमें वह किसी भी डोमेन के लिए डिफ़ॉल्ट ऐप्लिकेशन चुनने से पहले था.

डोमेन की पुष्टि की प्रक्रिया शुरू करना

किसी डिवाइस पर Android ऐप्लिकेशन लिंक की स्थिति रीसेट करने के बाद, खुद ही पुष्टि की जा सकती है. ऐसा करने के लिए, टर्मिनल विंडो में यह कमांड चलाएं:

adb shell pm verify-app-links --re-verify PACKAGE_NAME

पुष्टि के नतीजों की समीक्षा करना

पुष्टि करने वाले एजेंट को अपने अनुरोध पूरे करने के लिए कुछ समय दें. इसके बाद, पुष्टि के नतीजों की समीक्षा करें. ऐसा करने के लिए, यह कमांड चलाएं:

adb shell pm get-app-links PACKAGE_NAME

इस कमांड का आउटपुट इस तरह का होता है:

com.example.pkg:
    ID: 01234567-89ab-cdef-0123-456789abcdef
    Signatures: [***]
    Domain verification state:
      example.com: verified
      sub.example.com: legacy_failure
      example.net: verified
      example.org: 1026

जिन डोमेन की पुष्टि हो जाती है उनकी डोमेन की पुष्टि की स्थिति verified होती है. किसी भी अन्य स्थिति से पता चलता है कि डोमेन की पुष्टि नहीं की जा सकी. खास तौर पर, none की स्थिति से पता चलता है कि हो सकता है कि पुष्टि करने वाले एजेंट ने अब तक पुष्टि की प्रोसेस पूरी न की हो.

नीचे दी गई सूची में, डोमेन की पुष्टि करने पर मिलने वाली संभावित वैल्यू दी गई हैं:

none
इस डोमेन के लिए कुछ भी रिकॉर्ड नहीं किया गया है. पुष्टि करने वाले एजेंट के डोमेन की पुष्टि से जुड़े अनुरोधों को पूरा करने के लिए, कुछ और मिनट इंतज़ार करें. इसके बाद, डोमेन की पुष्टि करने की प्रोसेस फिर से शुरू करें.
verified
ऐप्लिकेशन की जानकारी देने के लिए, डोमेन की पुष्टि हो गई है.
approved
डोमेन को जबरन मंज़ूरी दी गई थी. आम तौर पर, शेल कमांड का इस्तेमाल करके ऐसा किया जाता है.
denied
डोमेन को आम तौर पर शेल कमांड चलाकर, जबरदस्ती अस्वीकार कर दिया गया था.
migrated
सिस्टम ने पिछली प्रोसेस का नतीजा सेव किया है, जिसमें लेगसी डोमेन की पुष्टि की गई थी.
restored
उपयोगकर्ता के डेटा को वापस लाने के बाद, डोमेन को मंज़ूरी दी गई. यह माना जाता है कि डोमेन की पुष्टि पहले ही की जा चुकी है.
legacy_failure
पुराने वर्शन वाले पुष्टि करने वाले टूल ने डोमेन की पुष्टि अस्वीकार कर दी. रिफ़ंड न होने की वजह पता नहीं है.
system_configured
डिवाइस कॉन्फ़िगरेशन की मदद से, डोमेन को अपने-आप मंज़ूरी मिल गई थी.
1024 या उससे ज़्यादा का गड़बड़ी कोड

गड़बड़ी का कस्टम कोड, जो डिवाइस के पुष्टि करने वाले टूल के हिसाब से होता है.

दोबारा जांच लें कि आपने नेटवर्क कनेक्शन सेट अप किया है या नहीं. इसके बाद, डोमेन की पुष्टि करने की प्रोसेस फिर से शुरू करें.

उपयोगकर्ता से अपने ऐप्लिकेशन को किसी डोमेन से जोड़ने का अनुरोध करना

आपके ऐप्लिकेशन को किसी डोमेन के लिए मंज़ूरी पाने का एक और तरीका है. इसके लिए, उपयोगकर्ता से अपने ऐप्लिकेशन को उस डोमेन से जोड़ने के लिए कहें.

देखें कि आपके ऐप्लिकेशन को डोमेन के लिए पहले से ही मंज़ूरी मिली हुई है या नहीं

उपयोगकर्ता से अनुरोध करने से पहले, देख लें कि आपका ऐप्लिकेशन उन डोमेन के लिए डिफ़ॉल्ट हैंडलर है या नहीं जिन्हें आपने अपने <intent-filter> एलिमेंट में तय किया है. अनुमति की स्थिति के बारे में जानने के लिए, इनमें से किसी एक तरीके का इस्तेमाल करें:

  • DomainVerificationManager एपीआई (रनटाइम पर).
  • जांच के दौरान, कमांड-लाइन प्रोग्राम.

DomainVerificationManager

यहां दिए गए कोड स्निपेट में, DomainVerificationManager एपीआई को इस्तेमाल करने का तरीका बताया गया है:

Kotlin

val context: Context = TODO("Your activity or fragment's Context")
val manager = context.getSystemService(DomainVerificationManager::class.java)
val userState = manager.getDomainVerificationUserState(context.packageName)

// Domains that have passed Android App Links verification.
val verifiedDomains = userState?.hostToStateMap
    ?.filterValues { it == DomainVerificationUserState.DOMAIN_STATE_VERIFIED }

// Domains that haven't passed Android App Links verification but that the user
// has associated with an app.
val selectedDomains = userState?.hostToStateMap
    ?.filterValues { it == DomainVerificationUserState.DOMAIN_STATE_SELECTED }

// All other domains.
val unapprovedDomains = userState?.hostToStateMap
    ?.filterValues { it == DomainVerificationUserState.DOMAIN_STATE_NONE }

Java

Context context = TODO("Your activity or fragment's Context");
DomainVerificationManager manager =
        context.getSystemService(DomainVerificationManager.class);
DomainVerificationUserState userState =
        manager.getDomainVerificationUserState(context.getPackageName());

Map<String, Integer> hostToStateMap = userState.getHostToStateMap();
List<String> verifiedDomains = new ArrayList<>();
List<String> selectedDomains = new ArrayList<>();
List<String> unapprovedDomains = new ArrayList<>();
for (String key : hostToStateMap.keySet()) {
    Integer stateValue = hostToStateMap.get(key);
    if (stateValue == DomainVerificationUserState.DOMAIN_STATE_VERIFIED) {
        // Domain has passed Android App Links verification.
        verifiedDomains.add(key);
    } else if (stateValue == DomainVerificationUserState.DOMAIN_STATE_SELECTED) {
        // Domain hasn't passed Android App Links verification, but the user has
        // associated it with an app.
        selectedDomains.add(key);
    } else {
        // All other domains.
        unapprovedDomains.add(key);
    }
}

कमांड-लाइन प्रोग्राम

ऐप्लिकेशन को डेवलप करने के दौरान उसकी जांच करते समय, आपके पास उन डोमेन की पुष्टि की स्थिति के बारे में जानकारी पाने के लिए, यह कमांड चलाने का विकल्प होता है जिनका मालिकाना हक आपके संगठन के पास है:

adb shell pm get-app-links --user cur PACKAGE_NAME

यहां दिए गए उदाहरण के आउटपुट में, "example.org" डोमेन के लिए ऐप्लिकेशन की पुष्टि नहीं हो पाई है. हालांकि, उपयोगकर्ता 0 ने सिस्टम सेटिंग में ऐप्लिकेशन को मैन्युअल रूप से अनुमति दी है. साथ ही, उस डोमेन के लिए किसी दूसरे पैकेज की पुष्टि नहीं की गई है.

com.example.pkg:
ID: ***
Signatures: [***]
Domain verification state:
  example.com: verified
  example.net: verified
  example.org: 1026
User 0:
  Verification link handling allowed: true
  Selection state:
    Enabled:
      example.org
    Disabled:
      example.com
      example.net

शेल कमांड का इस्तेमाल करके, उस प्रोसेस को भी सिम्युलेट किया जा सकता है जिसमें उपयोगकर्ता यह चुनता है कि किसी डोमेन से कौनसा ऐप्लिकेशन जुड़ा है. इन निर्देशों के बारे में पूरी जानकारी, adb shell pm के आउटपुट से मिलती है.

अनुरोध के लिए कॉन्टेक्स्ट दें

डोमेन की पुष्टि का अनुरोध करने से पहले, उपयोगकर्ता को कुछ जानकारी दें. उदाहरण के लिए, उन्हें स्प्लैश स्क्रीन, डायलॉग या यूज़र इंटरफ़ेस (यूआई) का कोई ऐसा एलिमेंट दिखाया जा सकता है जिससे उपयोगकर्ता को यह पता चल सके कि किसी खास डोमेन के लिए, आपका ऐप्लिकेशन डिफ़ॉल्ट हैंडलर क्यों होना चाहिए.

अनुरोध करना

जब उपयोगकर्ता को यह समझ आ जाए कि आपका ऐप्लिकेशन उनसे क्या करने के लिए कह रहा है, तब अनुरोध करें. ऐसा करने के लिए, किसी ऐसे इंटेंट को ट्रिगर करें जिसमें ACTION_APP_OPEN_BY_DEFAULT_SETTINGS इंटेंट ऐक्शन और टारगेट ऐप्लिकेशन के लिए, package:com.example.pkg से मैच करने वाली डेटा स्ट्रिंग शामिल हो. जैसा कि यहां दिए गए कोड स्निपेट में दिखाया गया है:

Kotlin

val context: Context = TODO("Your activity or fragment's Context")
val intent = Intent(Settings.ACTION_APP_OPEN_BY_DEFAULT_SETTINGS,
    Uri.parse("package:${context.packageName}"))
context.startActivity(intent)

Java

Context context = TODO("Your activity or fragment's Context");
Intent intent = new Intent(Settings.ACTION_APP_OPEN_BY_DEFAULT_SETTINGS,
    Uri.parse("package:" + context.getPackageName()));
context.startActivity(intent);

इंटेंट का इस्तेमाल करने पर, उपयोगकर्ताओं को डिफ़ॉल्ट रूप से खोलें नाम की सेटिंग स्क्रीन दिखती है. इस स्क्रीन पर, काम करने वाले लिंक खोलें नाम का एक रेडियो बटन होता है, जैसा कि पहली इमेज में दिखाया गया है.

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

रेडियो बटन चालू होने पर, सबसे नीचे मौजूद सेक्शन में
    चेकबॉक्स के साथ-साथ &#39;लिंक जोड़ें&#39; नाम का बटन भी दिखता है
पहला डायग्राम. सिस्टम सेटिंग की स्क्रीन, जहां उपयोगकर्ता यह चुन सकते हैं कि कौनसे लिंक डिफ़ॉल्ट रूप से आपके ऐप्लिकेशन में खुलेंगे.
हर चेकबॉक्स, ऐसे डोमेन को दिखाता है जिसे जोड़ा जा सकता है. डायलॉग बॉक्स के बटन, &#39;रद्द करें&#39; और &#39;जोड़ें&#39; हैं.
दूसरी इमेज. डायलॉग बॉक्स, जिसमें उपयोगकर्ता आपके ऐप्लिकेशन के साथ जोड़ने के लिए, अन्य डोमेन चुन सकते हैं.

अपने ऐप्लिकेशन में ऐसे डोमेन खोलना जिनकी पुष्टि आपका ऐप्लिकेशन नहीं कर सकता

हो सकता है कि आपके ऐप्लिकेशन का मुख्य फ़ंक्शन, तीसरे पक्ष के तौर पर लिंक खोलना हो. हालांकि, वह अपने मैनेज किए जा रहे डोमेन की पुष्टि नहीं कर सकता. अगर ऐसा है, तो उपयोगकर्ताओं को बताएं कि वे वेब लिंक चुनते समय, पहले पक्ष के ऐप्लिकेशन और आपके (तीसरे पक्ष) ऐप्लिकेशन में से किसी एक को नहीं चुन सकते. उपयोगकर्ताओं को डोमेन को आपके तीसरे पक्ष के ऐप्लिकेशन से मैन्युअल तरीके से जोड़ना होगा.

इसके अलावा, कोई डायलॉग या ट्रैंपोलिन गतिविधि शुरू करें. इससे उपयोगकर्ता को, प्रॉक्सी के तौर पर काम करके, पहले पक्ष के ऐप्लिकेशन में लिंक खोलने की अनुमति मिलती है. इस तरह के डायलॉग या ट्रैंपोलिन गतिविधि को सेट अप करने से पहले, अपने ऐप्लिकेशन को इस तरह से सेट अप करें कि वह आपके ऐप्लिकेशन के वेब इंटेंट फ़िल्टर से मैच करने वाले पहले पक्ष के ऐप्लिकेशन में पैकेज दिखे.

ऐप्लिकेशन के लिंक की जांच करना

ऐप्लिकेशन को लिंक करने की सुविधा लागू करते समय, आपको लिंक करने की सुविधा की जांच करनी चाहिए. इससे यह पक्का किया जा सकता है कि सिस्टम आपके ऐप्लिकेशन को आपकी वेबसाइटों से जोड़ सकता है और यूआरएल के अनुरोधों को आपकी उम्मीद के मुताबिक मैनेज कर सकता है.

किसी मौजूदा स्टेटमेंट फ़ाइल की जांच करने के लिए, स्टेटमेंट की सूची जनरेटर और टेस्टर टूल का इस्तेमाल किया जा सकता है.

पुष्टि करने के लिए होस्ट की सूची की पुष्टि करना

जांच करते समय, आपको उन होस्ट की सूची की पुष्टि करनी चाहिए जिनकी पुष्टि सिस्टम को आपके ऐप्लिकेशन के लिए करनी चाहिए. उन सभी यूआरएल की सूची बनाएं जिनके इंटेंट फ़िल्टर में ये एट्रिब्यूट और एलिमेंट शामिल हैं:

  • android:scheme एट्रिब्यूट की वैल्यू http या https हो
  • डोमेन यूआरएल पैटर्न वाला android:host एट्रिब्यूट
  • android.intent.action.VIEW ऐक्शन एलिमेंट
  • android.intent.category.BROWSABLE कैटगरी एलिमेंट

इस सूची का इस्तेमाल करके देखें कि नाम वाले हर होस्ट और सबडोमेन पर, डिजिटल ऐसेट लिंक JSON फ़ाइल उपलब्ध है या नहीं.

डिजिटल ऐसेट लिंक की फ़ाइलों की पुष्टि करना

हर वेबसाइट के लिए, Digital Asset Links API का इस्तेमाल करके पुष्टि करें कि डिजिटल ऐसेट लिंक JSON फ़ाइल को सही तरीके से होस्ट किया गया है और उसे सही तरीके से तय किया गया है:

https://digitalassetlinks.googleapis.com/v1/statements:list?
   source.web.site=https://domain.name:optional_port&
   relation=delegate_permission/common.handle_all_urls

टेस्टिंग की प्रोसेस के तहत, लिंक मैनेज करने के लिए सिस्टम की मौजूदा सेटिंग देखी जा सकती हैं. कनेक्ट किए गए डिवाइस पर मौजूद सभी ऐप्लिकेशन के लिए, लिंक मैनेज करने से जुड़ी मौजूदा नीतियों की सूची देखने के लिए, नीचे दिए गए निर्देश का पालन करें:

adb shell dumpsys package domain-preferred-apps

इसके अलावा, यह तरीका भी काम करता है:

adb shell dumpsys package d

ध्यान दें: ऐप्लिकेशन इंस्टॉल करने के बाद, कम से कम 20 सेकंड तक इंतज़ार करें, ताकि सिस्टम पुष्टि की प्रोसेस पूरी कर सके.

यह कमांड, डिवाइस पर मौजूद हर उपयोगकर्ता या प्रोफ़ाइल की सूची दिखाता है. इसके पहले, हेडर इस फ़ॉर्मैट में दिखता है:

App linkages for user 0:

इस हेडर के बाद, आउटपुट में इस फ़ॉर्मैट का इस्तेमाल करके, उस उपयोगकर्ता के लिए लिंक मैनेज करने की सेटिंग की सूची बनाई जाती है:

Package: com.android.vending
Domains: play.google.com market.android.com
Status: always : 200000002

इस सूची से पता चलता है कि उपयोगकर्ता के लिए कौनसे ऐप्लिकेशन, किन डोमेन से जुड़े हैं:

  • Package - किसी ऐप्लिकेशन की पहचान उसके पैकेज के नाम से की जाती है, जैसा कि उसके मेनिफ़ेस्ट में बताया गया है.
  • Domains - उन होस्ट की पूरी सूची दिखाता है जिनके वेब लिंक इस ऐप्लिकेशन को मैनेज करने हैं. इसके लिए, डेलिमिटर के तौर पर खाली जगहों का इस्तेमाल किया जाता है.
  • Status - इस ऐप्लिकेशन के लिए, लिंक मैनेज करने की मौजूदा सेटिंग दिखाता है. जिस ऐप्लिकेशन की पुष्टि हो चुकी है और जिसके मेनिफ़ेस्ट में android:autoVerify="true" है उसकी स्थिति always दिखती है. इस स्टेटस के बाद मौजूद हेक्साडेसिमल नंबर, उपयोगकर्ता के ऐप्लिकेशन लिंक करने की प्राथमिकताओं के Android सिस्टम के रिकॉर्ड से जुड़ा होता है. इस वैल्यू से यह पता नहीं चलता कि पुष्टि हो गई है या नहीं.

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

टेस्ट का उदाहरण

ऐप्लिकेशन लिंक की पुष्टि हो सके, इसके लिए ज़रूरी है कि सिस्टम आपके ऐप्लिकेशन की पुष्टि उन सभी वेबसाइटों के साथ कर सके जिनके बारे में आपने किसी इंटेंट फ़िल्टर में बताया है. यह फ़िल्टर, ऐप्लिकेशन लिंक की ज़रूरी शर्तों को पूरा करता हो. यहां दिए गए उदाहरण में, मेनिफ़ेस्ट कॉन्फ़िगरेशन दिखाया गया है. इसमें कई ऐप्लिकेशन लिंक तय किए गए हैं:

<application>

    <activity android:name=”MainActivity”>
        <intent-filter android:autoVerify="true">
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.DEFAULT" />
            <category android:name="android.intent.category.BROWSABLE" />
            <data android:scheme="https" />
            <data android:scheme="https" />
            <data android:host="www.example.com" />
            <data android:host="mobile.example.com" />
        </intent-filter>
        <intent-filter>
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.BROWSABLE" />
            <data android:scheme="https" />
            <data android:host="www.example2.com" />
        </intent-filter>
    </activity>

    <activity android:name=”SecondActivity”>
        <intent-filter>
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.DEFAULT" />
            <category android:name="android.intent.category.BROWSABLE" />
            <data android:scheme="https" />
            <data android:host="account.example.com" />
        </intent-filter>
    </activity>

      <activity android:name=”ThirdActivity”>
        <intent-filter>
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.DEFAULT" />
            <data android:scheme="https" />
            <data android:host="map.example.com" />
        </intent-filter>
        <intent-filter>
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.BROWSABLE" />
            <data android:scheme="market" />
            <data android:host="example.com" />
        </intent-filter>
      </activity>

</application>

ऊपर दिए गए मेनिफ़ेस्ट में मौजूद होस्ट की सूची, जिनकी पुष्टि प्लैटफ़ॉर्म करेगा:

www.example.com
mobile.example.com
www.example2.com
account.example.com

ऊपर दिए गए मेनिफ़ेस्ट में, जिन होस्ट की पुष्टि प्लैटफ़ॉर्म नहीं करेगा उनकी सूची यहां दी गई है:

map.example.com (it does not have android.intent.category.BROWSABLE)
market://example.com (it does not have either an "http" or "https" scheme)

स्टेटमेंट की सूचियों के बारे में ज़्यादा जानने के लिए, स्टेटमेंट की सूची बनाना लेख पढ़ें.

लागू करने से जुड़ी सामान्य गड़बड़ियां ठीक करना

अगर आपको अपने Android ऐप्लिकेशन के लिंक की पुष्टि करने में समस्या आ रही है, तो इन सामान्य गड़बड़ियों की जांच करें. यह सेक्शन, प्लेसहोल्डर डोमेन नेम के तौर पर example.com का इस्तेमाल करता है. इन जांचों को करते समय, example.com को अपने सर्वर के असल डोमेन नेम से बदलें.

इंटेंट फ़िल्टर गलत तरीके से सेट अप किया गया
देखें कि आपने किसी <intent-filter> एलिमेंट में ऐसा यूआरएल शामिल किया है या नहीं जिसका मालिकाना हक आपके ऐप्लिकेशन के पास नहीं है.
सर्वर का गलत कॉन्फ़िगरेशन

अपने सर्वर के JSON कॉन्फ़िगरेशन की जांच करें और पक्का करें कि SHA वैल्यू सही हो.

यह भी देखें कि example.com. (ट्रेलिंग पीरियड के साथ) और example.com, दोनों एक ही कॉन्टेंट दिखाते हैं या नहीं.

सर्वर साइड रीडायरेक्ट

अगर आपने इस तरह का रीडायरेक्ट सेट अप किया है, तो सिस्टम आपके ऐप्लिकेशन के लिए किसी भी Android ऐप्लिकेशन लिंक की पुष्टि नहीं करता:

  • http://example.com से https://example.com
  • example.com से www.example.com

ऐसा करने से, आपके ऐप्लिकेशन की सुरक्षा बनी रहती है.

सर्वर की परफ़ॉर्मेंस

देखें कि आपका सर्वर, आपके क्लाइंट ऐप्लिकेशन से कनेक्ट हो सकता है या नहीं.

ऐसे लिंक जिनकी पुष्टि नहीं की जा सकती

जांच के मकसद से, ऐसे लिंक भी जोड़े जा सकते हैं जिनकी पुष्टि नहीं की जा सकती. ध्यान रखें कि Android 11 और उससे पहले के वर्शन पर, इन लिंक की वजह से सिस्टम आपके ऐप्लिकेशन के सभी Android ऐप्लिकेशन लिंक की पुष्टि नहीं करता.

assetlinks.json में गलत हस्ताक्षर

पुष्टि करें कि आपका हस्ताक्षर सही है और वह आपके ऐप्लिकेशन पर हस्ताक्षर करने के लिए इस्तेमाल किए गए हस्ताक्षर से मेल खाता है. आम तौर पर, ये गलतियां होती हैं:

  • ऐप्लिकेशन को डीबग सर्टिफ़िकेट से साइन करना और assetlinks.json में सिर्फ़ रिलीज़ साइन होना.
  • assetlinks.json में हस्ताक्षर लोअर केस में हो. हस्ताक्षर, अंग्रेज़ी के बड़े अक्षरों में होना चाहिए.
  • अगर Play ऐप्लिकेशन साइनिंग की सुविधा का इस्तेमाल किया जा रहा है, तो पक्का करें कि आपने उस हस्ताक्षर का इस्तेमाल किया हो जिसका इस्तेमाल Google आपकी हर रिलीज़ को साइन करने के लिए करता है. वेबसाइट असोसिएशन की जानकारी देने के बारे में दिए गए निर्देशों का पालन करके, इन जानकारी की पुष्टि की जा सकती है. इसमें पूरा JSON स्निपेट भी शामिल है.