ऐप्लिकेशन लिंक, डीप लिंक होते हैं. ये एचटीटीपी या एचटीटीपीएस स्कीम का इस्तेमाल करते हैं. Android इनकी पुष्टि करता है, ताकि यह पता चल सके कि ये आपकी वेबसाइट से जुड़े हैं या नहीं. ऐप्लिकेशन लिंक को हैंडल करने के लिए रजिस्टर करने का तरीका यहां दिया गया है:
- अपने ऐप्लिकेशन मेनिफ़ेस्ट में एक या उससे ज़्यादा इंटेंट फ़िल्टर जोड़ें. इनमें आपकी वेबसाइट का डोमेन या यूआरएल शामिल होने चाहिए.
- इंटेंट फ़िल्टर के एलिमेंट में,
autoVerify="true"attributeजोड़ें. इससे सिस्टम को यह सिग्नल मिलता है कि उसे आपकी वेबसाइट केassetlinks.jsonकॉन्फ़िगरेशन के हिसाब से, स्कीम और होस्ट डोमेन की पुष्टि करनी चाहिए. - वेबसाइट के असोसिएशन का एलान करें.
यहां, स्कीम और होस्ट के साथ-साथ autoVerify="true" वाले ऐप्लिकेशन लिंक के एलान का एक उदाहरण दिया गया है:
<activity
android:name=".MainActivity"
android:exported="true"
...>
<!-- 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 link that uses the "http" scheme, your
app should be able to delegate that traffic to "https". -->
<!-- Do not include other schemes, as this will prevent verification. -->
<data android:scheme="http" />
<data android:scheme="https" />
<!-- Include one or more domains that should be verified. -->
<data android:host="www.example.com" />
<data android:host="*.example.com" />
</intent-filter>
</activity>
कोड के बारे में अहम बातें
- AutoVerify: ऐप्लिकेशन
लिंक के लिए,
android:autoVerify="true" एट्रिब्यूट ज़रूरी है. इससे सिस्टम को यह सिग्नल मिलता है कि उसे आपके ऐप्लिकेशन और टैग में बताई गई स्कीम और डोमेन के बीच तालमेल की पुष्टि करनी चाहिए.<data>हमारा सुझाव है कि पुष्टि किए जा सकने वाले हर इंटेंट फ़िल्टर में,autoVerify="true" जोड़ें. - डेटा एलिमेंट: हर ऐप्लिकेशन लिंक इंटेंट फ़िल्टर में, एक या उससे ज़्यादा
<data>एलिमेंट शामिल होने चाहिए. इनमें, स्कीम और होस्ट के ऐसे फ़ॉर्मैट शामिल होने चाहिए जो पुष्टि किए जा सकने वाले आपकी वेबसाइट के डोमेन से मेल खाते हों. - स्कीम: इंटेंट फ़िल्टर में,
<data>एलिमेंट शामिल होने चाहिए, दोनोंhttpऔरhttpsस्कीम के लिए. होस्ट: एक या उससे ज़्यादा होस्ट से मेल खाने के लिए,
<data>एलिमेंट जोड़े जा सकते हैं. हालांकि, यह ज़रूरी नहीं है. एक से ज़्यादा सबडोमेन (जैसे,*.example.com) से मेल खाने के लिए, वाइल्डकार्ड (*) का इस्तेमाल करें. सिस्टम, आपकी वेबसाइट पर मौजूद आपके assetlinks.json फ़ाइल के हिसाब से, हर होस्ट की पुष्टि करने की कोशिश करेगा. ध्यान दें कि पाथ-लेवल की राउटिंग को assetlinks.json फ़ाइल से हैंडल किया जाना चाहिए. इसके बारे में, यहां दिए गए सबसे सही तरीके वाले सेक्शन में बताया गया है.एक से ज़्यादा होस्ट: अगर एक से ज़्यादा होस्ट डोमेन का एलान किया जाता है, तो Android 12 और इसके बाद के वर्शन पर, सिस्टम हर डोमेन की पुष्टि करने की कोशिश करता है. अगर किसी होस्ट की पुष्टि हो जाती है, तो ऐप्लिकेशन, पुष्टि किए गए उस होस्ट से मिले लिंक के लिए डिफ़ॉल्ट हैंडलर बन जाता है. Android 11 और इससे पहले के वर्शन पर, अगर किसी एक होस्ट की भी पुष्टि नहीं हो पाती है, तो पुष्टि नहीं की जा सकती.
एक से ज़्यादा इंटेंट फ़िल्टर: अगर आपको यूनीक यूआरएल (जैसे, स्कीम और होस्ट का कोई खास कॉम्बिनेशन) का एलान करना है, तो अलग-अलग फ़िल्टर बनाना ज़रूरी है. ऐसा इसलिए, क्योंकि एक ही इंटेंट फ़िल्टर में मौजूद एक से ज़्यादा
<data>एलिमेंट को एक साथ मर्ज कर दिया जाता है, ताकि उनके कंबाइन किए गए एट्रिब्यूट के सभी वैरिएंट शामिल किए जा सकें.
मेनिफ़ेस्ट फ़िल्टर के नियमों से जुड़ी ज़रूरी बातें
अगर Android 15 और इसके बाद के वर्शन में, डाइनैमिक ऐप्लिकेशन लिंक के साथ इस्तेमाल करने के लिए फ़िल्टर सेट अप किए जा रहे हैं, तो यह याद रखना ज़रूरी है कि सर्वर-साइड assetlinks.json फ़ाइल में एलान किए गए डाइनैमिक नियम, यूआरएल के उन नियमों के स्कोप को नहीं बढ़ा सकते जिन्हें आपने अपने ऐप्लिकेशन मेनिफ़ेस्ट में स्टैटिक तौर पर एलान किया है.
इसलिए, हमारा सुझाव है कि यह तरीका अपनाएं:
- अपने ऐप्लिकेशन मेनिफ़ेस्ट में, ज़्यादा से ज़्यादा स्कोप सेट करें. जैसे, सिर्फ़ स्कीम और डोमेन का एलान करके
- बेहतर बनाने के लिए, सर्वर-साइड assetlinks.json के नियमों पर भरोसा करें. जैसे, पाथ-लेवल की राउटिंग.
इस सही कॉन्फ़िगरेशन की मदद से, ज़रूरत के हिसाब से assetlinks.json फ़ाइल में, नए ऐप्लिकेशन लिंक पाथ डाइनैमिक तरीके से जोड़े जा सकेंगे. साथ ही, आपको यह पता होगा कि ये पाथ, ऐप्लिकेशन मेनिफ़ेस्ट में सेट किए गए बड़े स्कोप के अंदर ही होंगे.
एक से ज़्यादा होस्ट के लिए ऐप्लिकेशन लिंक की सुविधा
सिस्टम को, ऐप्लिकेशन के यूआरएल इंटेंट फ़िल्टर के डेटा एलिमेंट में बताए गए होस्ट की पुष्टि करनी होगी. इसके लिए, उसे उस इंटेंट फ़िल्टर में मौजूद, संबंधित वेब डोमेन पर होस्ट की गई डिजिटल ऐसेट लिंक फ़ाइलों का इस्तेमाल करना होगा. अगर पुष्टि नहीं हो पाती है, तो सिस्टम, इंटेंट को हल करने के लिए अपने स्टैंडर्ड तरीके का इस्तेमाल करता है. इसके बारे में, ऐप्लिकेशन के कॉन्टेंट के लिए डीप लिंक बनाना लेख में बताया गया है. हालांकि, ऐप्लिकेशन के अन्य इंटेंट फ़िल्टर में तय किए गए किसी भी यूआरएल पैटर्न के लिए, ऐप्लिकेशन की पुष्टि डिफ़ॉल्ट हैंडलर के तौर पर की जा सकती है.
उदाहरण के लिए, नीचे दिए गए इंटेंट फ़िल्टर वाले ऐप्लिकेशन की पुष्टि सिर्फ़ 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>
एक से ज़्यादा सबडोमेन के लिए ऐप्लिकेशन लिंक करने की सुविधा
डिजिटल ऐसेट लिंक प्रोटोकॉल, आपके इंटेंट फ़िल्टर में मौजूद सबडोमेन को यूनीक और अलग-अलग होस्ट के तौर पर मानता है. इसलिए, अगर आपके इंटेंट फ़िल्टर में अलग-अलग सबडोमेन वाले एक से ज़्यादा होस्ट शामिल हैं, तो आपको हर डोमेन पर एक मान्य 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) के साथ अपना होस्टनेम एलान किया है, तो आपको रूट
होस्टनेम (example.com) पर अपनी assetlinks.json फ़ाइल पब्लिश करनी होगी. उदाहरण के लिए, नीचे दिए गए इंटेंट फ़िल्टर
वाले ऐप्लिकेशन की पुष्टि, 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 को कॉल करने पर मिले नतीजे शामिल हों. उपयोगकर्ता, डायलॉग में दिखने वाले मिलते-जुलते ऐप्लिकेशन की सूची में से अपना पसंदीदा ऐप्लिकेशन चुन सकता है.
Android 14 और इससे पहले के वर्शन के लिए, डाइनैमिक ऐप्लिकेशन लिंक की बैकवर्ड कंपैटिबिलिटी
डाइनैमिक ऐप्लिकेशन लिंक की सुविधाएं, जैसे कि
assetlinks.json में शामिल, मैचिंग के बेहतर नियम और <uri-relative-filter-group> का इस्तेमाल, सिर्फ़ पूरी तरह से
Android 15 (एपीआई लेवल 35) और इसके बाद के वर्शन पर काम करती हैं.
Android 14 (एपीआई लेवल 34) और इससे पहले के वर्शन पर, सिस्टम, ऐप्लिकेशन लिंक की पुष्टि के लिए, आपके मेनिफ़ेस्ट के <data> एलिमेंट में एलान की गई सिर्फ़ scheme
और host को ही ध्यान में रखता है. assetlinks.json से, पाथ के हिसाब से तय किए गए नियम, एक्सक्लूज़न, और डाइनैमिक अपडेट लागू नहीं किए जाते.
इसका मतलब है कि अगर आपके मेनिफ़ेस्ट में सिर्फ़ scheme और host की जानकारी दी गई है, तो Android 14 और इससे पहले के वर्शन पर, आपका ऐप्लिकेशन, पुष्टि किए गए डोमेन के सभी पाथ को कैप्चर कर सकता है. भले ही, Android 15 और इसके बाद के वर्शन के लिए, आपके assetlinks.json में पाथ के हिसाब से नियम तय किए गए हों.
Android के पुराने वर्शन के लिए फ़ॉलबैक की रणनीति को डीप लिंक के बिना कॉन्फ़िगर करना
अगर आपको Android 15 और इसके बाद के वर्शन पर, ज़्यादा सटीक पाथ के लिए डाइनैमिक ऐप्लिकेशन लिंक का इस्तेमाल करना है, तो Android 14 और इससे पहले के वर्शन पर, अपने ऐप्लिकेशन को किसी डोमेन के सभी लिंक को हैंडल करने से रोकने के लिए, अपने मेनिफ़ेस्ट के इंटेंट फ़िल्टर में ऐसा पाथ शामिल करें जो मेल न खाता हो.
एक <data> एलिमेंट जोड़ें जिसमें एक android:path एट्रिब्यूट हो, जो आपके लिंक के लिए कभी भी मान्य पाथ न हो. इससे यह पक्का होता है कि इंटेंट फ़िल्टर, पुराने वर्शन पर सभी पाथ से मेल नहीं खाता.
उदाहरण:
<activity
android:name=".MainActivity"
android:exported="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" />
<data android:scheme="http" />
<data android:scheme="https" />
<data android:host="www.example.com" />
<!-- Add a non-matching path for backward compatibility -->
<data android:path="/no_match_for_older_android_versions" />
<uri-relative-filter-group android:allow="true">
<data android:pathPattern="/.*"/>
</uri-relative-filter-group>
</intent-filter>
</activity>
<data android:path="/no_match_for_older_android_versions" /> जोड़ने से, यह पक्का होता है कि Android 14 और इससे पहले के वर्शन पर, यह इंटेंट फ़िल्टर, आने वाले किसी भी लिंक से मेल नहीं खाता. साथ ही, Android 15 और इसके बाद के वर्शन पर, डाइनैमिक ऐप्लिकेशन लिंक के साथ इस्तेमाल करने के लिए, डोमेन की पुष्टि की जा सकती है. इसके लिए, आपके assetlinks.json के नियमों में शामिल, मैचिंग के बेहतर नियमों का इस्तेमाल किया जाता है.
मौजूदा ऐप्लिकेशन लिंक माइग्रेट करना
अगर आपके मेनिफ़ेस्ट में, पाथ के खास नियमों (जैसे
android:pathPrefix) वाले ऐप्लिकेशन लिंक पहले से मौजूद हैं और आपको Android 15 और इसके बाद के वर्शन पर, डाइनैमिक ऐप्लिकेशन लिंक
का इस्तेमाल करना है, तो अपने मौजूदा इंटेंट फ़िल्टर में सीधे तौर पर <uri-relative-filter-group>
एलिमेंट जोड़ा जा सकता है.
Android 14 और इससे पहले के वर्शन, <uri-relative-filter-group> एलिमेंट को अनदेखा कर देते हैं.
इसलिए, आपके मौजूदा ऐप्लिकेशन लिंक, Android के पुराने वर्शन वाले डिवाइसों पर,
अब की तरह ही काम करते रहेंगे.
हालांकि, आपको इस बात पर ध्यान देना होगा कि Android 15 और इसके बाद के वर्शन, "मिक्स" कॉन्फ़िगरेशन का आकलन कैसे करते हैं:
- दो-लेयर फ़िल्टरिंग: Android 15 और इसके बाद के वर्शन पर, सिस्टम, इंटेंट फ़िल्टर का आकलन यूनियन के तौर पर करता है. अगर कोई यूआरएल, आपके लेगसी स्टैटिक
<data>टैग या आपके<uri-relative-filter-group>में मौजूद सामान्य नियमों को पूरा करता है, तो वह मेनिफ़ेस्ट की जांच में पास हो जाता है. यूआरएल के मेनिफ़ेस्ट की शुरुआती जांच में पास होने के बाद, सिस्टम, आपकेassetlinks.jsonफ़ाइल में तय किए गए डाइनैमिक नियमों को, फ़ाइन-ग्रेन फ़िल्टरिंग की दूसरी लेयर के तौर पर लागू करता है. इसका मतलब है कि सर्वर-साइड JSON के नियम, यह तय करते हैं कि मैच किए गए किन यूआरएल से ऐप्लिकेशन खुलेगा.
हाइब्रिड कॉन्फ़िगरेशन का उदाहरण:
<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="www.example.com" />
<!-- Legacy rule: Android 14 and lower use this. Android 15 and higher
also use this. -->
<data android:pathPrefix="/store" />
<!--
Dynamic rule: Android 14 and lower ignore this. Android 15 and higher
evaluate this as a union between all paths and the configuration
specified in the assetlinks.json file. Make sure to apply further
refinements in the assetlinks.json file to prevent all URL paths from
opening in the app.
-->
<uri-relative-filter-group android:allow="true">
<data android:pathPrefix="/" />
</uri-relative-filter-group>
</intent-filter>