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

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

  1. अपने ऐप्लिकेशन मेनिफ़ेस्ट में एक या उससे ज़्यादा इंटेंट फ़िल्टर जोड़ें. इनमें अपनी वेबसाइट के डोमेन या यूआरएल की जानकारी दें.
  2. इंटेंट फ़िल्टर एलिमेंट में autoVerify="true"attribute जोड़ें. इससे सिस्टम को यह सिग्नल मिलता है कि उसे आपकी वेबसाइट की assetlinks.json कॉन्फ़िगरेशन के हिसाब से, स्कीम और होस्ट डोमेन की पुष्टि करनी चाहिए.
  3. वेबसाइट के असोसिएशन के बारे में जानकारी दें.

यहां स्कीम, होस्ट, और 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> एलिमेंट शामिल होने चाहिए. ये एलिमेंट, उन स्कीम और होस्ट फ़ॉर्मैट के बारे में बताते हैं जो पुष्टि किए जा सकने वाले आपकी वेबसाइट के डोमेन से मेल खाते हैं.
  • स्कीम: इंटेंट फ़िल्टर में, http और https, दोनों स्कीम के लिए <data> एलिमेंट शामिल होने चाहिए.

  • होस्ट: एक या उससे ज़्यादा होस्ट से मैच करने के लिए, <data> एलिमेंट जोड़े जा सकते हैं. हालांकि, यह ज़रूरी नहीं है. एक से ज़्यादा सबडोमेन (जैसे, *.example.com) से मेल खाने के लिए, वाइल्डकार्ड (*) का इस्तेमाल करें. सिस्टम, आपकी वेबसाइट पर मौजूद assetlinks.json फ़ाइल के हिसाब से, हर होस्ट की पुष्टि करने की कोशिश करेगा. ध्यान दें कि पाथ-लेवल की किसी भी राउटिंग को assetlinks.json फ़ाइल से मैनेज किया जाना चाहिए. इसके बारे में जानने के लिए, यहां दिए गए सबसे सही तरीके वाला सेक्शन देखें.

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

  • एक से ज़्यादा इंटेंट फ़िल्टर: जब आपको यूनीक यूआरएल (जैसे कि स्कीम और होस्ट का कोई खास कॉम्बिनेशन) का एलान करना हो, तब अलग-अलग फ़िल्टर बनाना ज़रूरी होता है. ऐसा इसलिए, क्योंकि एक ही इंटेंट फ़िल्टर में मौजूद कई <data> एलिमेंट को एक साथ मर्ज कर दिया जाता है, ताकि उनके कंबाइंड एट्रिब्यूट के सभी वेरिएशन का हिसाब रखा जा सके.

मेनिफ़ेस्ट फ़ाइल के फ़िल्टर के नियमों से जुड़ी ज़रूरी बातें

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

इसलिए, हमारा सुझाव है कि आप यह तरीका अपनाएं:

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

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

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

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

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

<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) के साथ अपने होस्टनेम का एलान किया है, तो आपको अपनी 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 को कॉल करने के नतीजे शामिल हों. उपयोगकर्ता, डायलॉग बॉक्स में दिखने वाले मिलते-जुलते ऐप्लिकेशन की सूची से, अपनी पसंद का ऐप्लिकेशन चुन सकता है.

डाइनैमिक ऐप्लिकेशन लिंक की सुविधाएं, सिर्फ़ Android 15 (एपीआई लेवल 35) और इसके बाद के वर्शन पर पूरी तरह से काम करती हैं. इनमें assetlinks.json में मौजूद मैचिंग के बेहतर नियम और <uri-relative-filter-group> का इस्तेमाल शामिल है.

Android 14 (एपीआई लेवल 34) और इससे पहले के वर्शन पर, सिस्टम सिर्फ़ आपके मेनिफ़ेस्ट के <data> एलिमेंट में बताए गए scheme और host पर विचार करता है. ऐसा ऐप्लिकेशन लिंक की पुष्टि करने के लिए किया जाता है. पाथ के हिसाब से तय किए गए नियम, एक्सक्लूज़न, और assetlinks.json से मिलने वाले डाइनैमिक अपडेट लागू नहीं होते.

इसका मतलब है कि अगर आपके मेनिफ़ेस्ट में सिर्फ़ scheme और host शामिल हैं, तो हो सकता है कि आपका ऐप्लिकेशन, Android 14 और इससे पुराने वर्शन पर पुष्टि किए गए डोमेन के सभी पाथ को अनजाने में कैप्चर कर ले. भले ही, आपने Android 15 और इससे नए वर्शन के लिए, assetlinks.json में पाथ के हिसाब से नियम तय किए हों.

अगर आपको 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 और इसके बाद के वर्शन में, "mixed" कॉन्फ़िगरेशन का आकलन कैसे किया जाता है:

  • दो लेयर वाली फ़िल्टरिंग: 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>