वेबसाइट के साथ असोसिएशन और डाइनैमिक नियम कॉन्फ़िगर करना

ऐप्लिकेशन लिंक की सुविधा के लिए, आपको डिजिटल ऐसेट लिंक JSON फ़ाइल बनानी होगी. इसका नाम assetlinks.json होगा. साथ ही, इसे अपनी वेबसाइट पर किसी जानी-पहचानी जगह पर पब्लिश करना होगा. इस फ़ाइल में सार्वजनिक तौर पर यह जानकारी दी जाती है कि आपके डोमेन के लिंक मैनेज करने की अनुमति किन ऐप्लिकेशन को है. Android डिवाइस, इस फ़ाइल को आपके सर्वर से वापस लाएंगे, ताकि आपके डीप लिंक की पुष्टि की जा सके.

Android 15 और इसके बाद के वर्शन में डाइनैमिक ऐप्लिकेशन लिंक के लिए, assetlinks.json फ़ाइल में डाइनैमिक नियमों का कॉन्फ़िगरेशन तय किया जाता है. जैसे, पाथ, फ़्रैगमेंट, और क्वेरी पैरामीटर के लिए पैटर्न मैच करने वाले टूल. Android 15 (एपीआई लेवल 35) या इसके बाद के वर्शन वाले उन Android डिवाइसों पर यह सुविधा काम करती है जिन पर Google की सेवाएं इंस्टॉल हैं. ये डिवाइस, समय-समय पर फ़ाइल को फिर से फ़ेच करेंगे. साथ ही, आपके डाइनैमिक कॉन्फ़िगरेशन को ऐप्लिकेशन के मेनिफ़ेस्ट में मौजूद स्टैटिक कॉन्फ़िगरेशन के साथ मर्ज करेंगे.

इस गाइड में, assetlinks.json फ़ाइल तैयार करने और उसे अपनी वेबसाइट पर पब्लिश करने का तरीका बताया गया है. अगर आपको ठीक लगे, तो Play Deep Links टूल या Android Studio में मौजूद ऐप्लिकेशन लिंक असिस्टेंट से assetlinks.json फ़ाइल जनरेट की जा सकती है. ज़्यादा जानकारी के लिए, ऐप्लिकेशन लिंक के लिए डेवलपर टूल देखें.

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

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

  • package_name: ऐप्लिकेशन की build.gradle फ़ाइल में बताया गया ऐप्लिकेशन आईडी.
  • sha256_cert_fingerprints: यह आपके ऐप्लिकेशन के साइनिंग सर्टिफ़िकेट का SHA256 फ़िंगरप्रिंट होता है. Java keytool का इस्तेमाल करके, फ़िंगरप्रिंट जनरेट करने के लिए इस निर्देश का इस्तेमाल करें:

keytool -list -v -keystore my-release-key.keystore

  • इस फ़ील्ड में एक से ज़्यादा फ़िंगरप्रिंट इस्तेमाल किए जा सकते हैं. इनका इस्तेमाल, आपके ऐप्लिकेशन के अलग-अलग वर्शन के लिए किया जा सकता है. जैसे, डीबग और प्रोडक्शन बिल्ड. अगर आपने अपने ऐप्लिकेशन के लिए Play ऐप्लिकेशन साइनिंग का इस्तेमाल किया है, तो keytool को स्थानीय तौर पर चलाने से जनरेट हुआ सर्टिफ़िकेट फ़िंगरप्रिंट, आम तौर पर उपयोगकर्ताओं के डिवाइसों पर मौजूद फ़िंगरप्रिंट से मेल नहीं खाएगा. Play Console डेवलपर खाते में जाकर, यह पुष्टि की जा सकती है कि आपके ऐप्लिकेशन के लिए Play ऐप्लिकेशन पर हस्ताक्षर करने की सुविधा का इस्तेमाल किया जा रहा है या नहीं. इसके लिए, Release > Setup > App signing पर जाएं. अगर इस सुविधा का इस्तेमाल किया जा रहा है, तो आपको इसी पेज पर अपने ऐप्लिकेशन के लिए सही डिजिटल ऐसेट लिंक 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"]
  }
}]

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

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

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

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"]
  }
}]

डाइनैमिक नियमों को कॉन्फ़िगर करना

Android 15 या इसके बाद के वर्शन में, डाइनैमिक ऐप्लिकेशन लिंक की सुविधा उपलब्ध है. इसकी मदद से, सर्वर-साइड पर डीप लिंक मैच करने के नियमों का इस्तेमाल किया जा सकता है. ये नियम, आपके ऐप्लिकेशन मेनिफ़ेस्ट में स्टैटिक तौर पर तय किए गए नियमों के साथ काम करते हैं. assetlinks.json फ़ाइल में, डाइनैमिक नियम तय किए जाते हैं. इसे शामिल करना ज़रूरी नहीं है.

Android 15 (एपीआई लेवल 35) या इसके बाद के वर्शन वाले ऐसे Android डिवाइस जिन पर Google की सेवाएं इंस्टॉल हैं वे समय-समय पर आपके सर्वर से इस फ़ाइल को वापस पाएंगे. साथ ही, डाइनैमिक नियमों के कॉन्फ़िगरेशन को ऐप्लिकेशन के मेनिफ़ेस्ट में मौजूद स्टैटिक कॉन्फ़िगरेशन के साथ मर्ज करेंगे. यहां डाइनैमिक नियमों वाली assetlinks.json फ़ाइल का उदाहरण दिया गया है:

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.app",
      "sha256_cert_fingerprints": [...]
    },
    "relation_extensions": {
      "delegate_permission/common.handle_all_urls": {
        "dynamic_app_link_components": [
          {"?": {"dl": "*"}},
          {"#": "app"},
          {"/": "/products/*"},
          {"/": "/shoes", "?": {"in_app": "true"}},
          {"/": "*", "exclude": true}
        ]
      }
    }
  }
]

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

  • डाइनैमिक ऐप्लिकेशन लिंक, डिजिटल ऐसेट लिंक का एक नया रिलेशन एक्सटेंशन जोड़ता है. इसे dynamic_app_link_components कहा जाता है. इसमें डाइनैमिक नियमों को कॉन्फ़िगर किया जाता है.
  • डाइनैमिक नियमों में, पाथ, फ़्रैगमेंट, और क्वेरी पैरामीटर के लिए पैटर्न मैच करने वाले टूल शामिल हो सकते हैं.
  • किसी भी पैटर्न मैच करने वाले टूल को 'शामिल नहीं किया गया' के तौर पर भी मार्क किया जा सकता है, ताकि मैच करने वाले यूआरएल आपका ऐप्लिकेशन न खोलें.
  • इस उदाहरण में, पाथ ("/"), फ़्रैगमेंट ("#"), और क्वेरी पैरामीटर ("?") के लिए मैच करने वाले फ़ंक्शन के उदाहरण दिखाए गए हैं. साथ ही, इसमें मैच न करने वाले फ़ंक्शन ("exclude") भी दिखाए गए हैं
  • अगर फ़ाइल में मौजूद कोई भी फ़ील्ड गलत फ़ॉर्मैट में है या खाली है, तो Android डाइनैमिक नियमों को खारिज कर देता है. इसके बाद, डिवाइस उन नियमों का इस्तेमाल करता है जो ऐप्लिकेशन के मेनिफ़ेस्ट में स्टैटिक तौर पर तय किए गए हैं.

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

डाइनैमिक नियमों का एलान करना

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

  • पाथ मैचिंग
    • कुंजी: "/"
    • वैल्यू: एक स्ट्रिंग, यूआरएल पाथ के लिए मैचिंग एक्सप्रेशन
  • फ़्रैगमेंट मैचिंग
    • कुंजी: "#"
    • वैल्यू: एक स्ट्रिंग, यूआरएल फ़्रैगमेंट के लिए मैचिंग एक्सप्रेशन
  • क्वेरी पैरामीटर मैचिंग
    • कुंजी: "?"
    • वैल्यू: यूआरएल क्वेरी पैरामीटर में मौजूद की/वैल्यू पेयर से मेल खाने वाली डिक्शनरी.
    • उदाहरण के लिए, {"?", {"dl": "*", "in_app":"true"} डिक्शनरी, "?in_app=true&dl=abc" क्वेरी स्ट्रिंग से मैच करेगी.
    • डिक्शनरी में मौजूद कुंजी/वैल्यू पेयर का क्रम, क्वेरी स्ट्रिंग में मौजूद पेयर के क्रम से मेल खाना ज़रूरी नहीं है. इसके अलावा, डिक्शनरी को क्वेरी स्ट्रिंग में मौजूद सभी कुंजी/वैल्यू पेयर से मेल खाने की ज़रूरत नहीं है. हालांकि, हर डिक्शनरी एंट्री के लिए एक मैच मिलना ज़रूरी है.
    • उदाहरण के लिए, डिक्शनरी, क्वेरी स्ट्रिंग "?lang=en&in_app=true&tz=pst&dl=abc" से भी मैच करेगी, लेकिन क्वेरी स्ट्रिंग "?lang=en&tz=pst&dl=abc" से मैच नहीं करेगी
  • शामिल नहीं किया गया
    • कुंजी: "exclude"
    • वैल्यू: dynamic_app_link_components में तय किए गए हर नियम के लिए, सही/गलत वैल्यू देना ज़रूरी नहीं है (उदाहरण देखें).

पैटर्न मैच करने वाले फ़ंक्शन में इन खास वर्णों का इस्तेमाल किया जा सकता है:

  • "*" का इस्तेमाल, शून्य या उससे ज़्यादा वर्णों से मेल खाने के लिए किया जाता है. हालांकि, यह तब तक काम करता है, जब तक कि पैटर्न में वाइल्डकार्ड के बाद आने वाला वर्ण, मेल खाने वाली स्ट्रिंग में न मिल जाए
  • "?" किसी भी एक वर्ण से मेल खाता है
  • "?*" एक या उससे ज़्यादा वर्णों से मेल खाता है

वैल्यू के लिए, वर्णों से जुड़ी कोई अन्य पाबंदी नहीं है.

डाइनैमिक नियमों को क्रम में लगाना

नियमों को जिस क्रम में बताया जाता है वह अहम होता है. Android, हर नियम की जांच क्रम से करता है. जब तक उसे कोई मैच नहीं मिल जाता, तब तक वह जांच करता रहता है.

यहां दिए गए उदाहरण में बताया गया है कि ऑर्डर करने से, हैंडलिंग पर क्या असर पड़ता है. पहला नियम, सभी पाथ ("*") से मेल खाता है, लेकिन इसमें मैच शामिल नहीं हैं (exclude: true). इसका मतलब है कि यह ऐप्लिकेशन को खोलने के लिए सभी यूआरएल को शामिल नहीं करता है. इस मामले में, "/path1" की अनुमति देने वाले दूसरे नियम का कभी आकलन नहीं किया जाएगा.

dynamic_app_link_components: [
  {"/": "*", "exclude": true},
  {"/": "/path1"}
]

हालांकि, अगले उदाहरण में "/path1" नियम को पहले तय किया गया है. इसलिए, इसका आकलन सबसे पहले किया जाएगा. साथ ही, यह "/path1" से मेल खाने वाले यूआरएल के लिए ऐप्लिकेशन खोलेगा. दूसरा नियम, ऐप्लिकेशन खोलने से सभी यूआरएल को बाहर रखता है. इसका आकलन दूसरे नंबर पर किया जाएगा. हालांकि, ऐसा सिर्फ़ तब होगा, जब पहला नियम मैच नहीं होता है.

dynamic_app_link_components: [
  {"/": "/path1"},
  {"/": "*", "exclude": true}
]

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

dynamic_app_link_components: [
  {"/": "/path1"},
  {"/": "/path2"}
]

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

dynamic_app_link_components: [
  {"/": "/path1", "exclude": true},
  {"/": "*"}
]

डाइनैमिक नियमों का दायरा सही तरीके से तय करना

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

assetlinks.json फ़ाइल में बताए गए डाइनैमिक नियम, सिर्फ़ उन होस्ट के लिए नियम तय कर सकते हैं जिन्हें आपने अपने ऐप्लिकेशन की AndroidManifest.xml फ़ाइल में बताया है. डाइनैमिक नियमों की मदद से, यूआरएल के उन नियमों का दायरा नहीं बढ़ाया जा सकता जिन्हें आपने अपने ऐप्लिकेशन मेनिफ़ेस्ट में स्टैटिक तौर पर तय किया है.

इसलिए, हमारा सुझाव है कि आप डाइनैमिक और स्टैटिक नियमों में इस तरीके का इस्तेमाल करें:

  • अपने ऐप्लिकेशन मेनिफ़ेस्ट में, ज़्यादा से ज़्यादा स्कोप वाले नियम सेट करें. जैसे, सिर्फ़ स्कीम और डोमेन का एलान करके
  • सर्वर-साइड डाइनैमिक नियमों का इस्तेमाल करके, रूटिंग को और बेहतर बनाएं. जैसे, पाथ-लेवल रूटिंग.

इस कॉन्फ़िगरेशन की मदद से, ज़रूरत के मुताबिक assetlinks.json फ़ाइल में नए ऐप्लिकेशन लिंक के पाथ डाइनैमिक तरीके से जोड़े जा सकेंगे. साथ ही, आपको यह पता होगा कि वे ऐप्लिकेशन मेनिफ़ेस्ट में सेट किए गए बड़े स्कोप के हिसाब से काम करेंगे.

अपने नियमों को सही तरीके से मैनेज करने के लिए, किसी साइट, संबंध, और ऐप्लिकेशन के लिए, सभी स्टेटमेंट में सिर्फ़ एक dynamic_app_link_components ऑब्जेक्ट का एलान करें.

  • एक ही साइट, संबंध, और ऐप्लिकेशन के लिए, एक से ज़्यादा ऐसे स्टेटमेंट ढूंढें जिनमें dynamic_app_link_components ऑब्जेक्ट के बारे में बताया गया हो.
  • एक ही स्टेटमेंट में डाइनैमिक_ऐप्लिकेशन_लिंक_कॉम्पोनेंट के कई ऑब्जेक्ट ढूंढें

ऐसे मामलों में, Android इस बात की गारंटी नहीं देता कि डाइनैमिक नियमों के किस कॉन्फ़िगरेशन का इस्तेमाल किया जाएगा.

डाइनैमिक नियमों के साथ, ऐप्लिकेशन लिंक के पुराने कॉन्फ़िगरेशन का इस्तेमाल किया जा सकता है

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

Android 14 (एपीआई लेवल 34 या इससे पहले का वर्शन) पर चलने वाले Android डिवाइस, डाइनैमिक नियमों के लिए नए रिलेशन एक्सटेंशन फ़ील्ड को अनदेखा करते हैं. वहीं, Android 15 और इसके बाद के वर्शन पर चलने वाले डिवाइस, उन नियमों को मेनिफ़ेस्ट में तय किए गए नियमों के साथ मर्ज कर देंगे.

पुष्टि करने के लिए इस्तेमाल होने वाली JSON फ़ाइल पब्लिश करना

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

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

पक्का करें कि:

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

इससे जुड़ी ये गाइड देखें: