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

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

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

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

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

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

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

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

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

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

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

डाइनैमिक ऐप्लिकेशन लिंक के लिए, रिलेशन एक्सटेंशन की भी जांच की जा सकती है.

https://digitalassetlinks.googleapis.com/v1/statements:list?source.web.site=https://www.example.com&relation=delegate_permission/common.handle_all_urls&return_relation_extensions=true

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

adb shell dumpsys package domain-preferred-apps

यह कमांड भी वही काम करती है:

adb shell dumpsys package d

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

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 सिस्टम के उस रिकॉर्ड से जुड़ा होता है जिसमें उपयोगकर्ता की ऐप्लिकेशन लिंकिंग की सेटिंग शामिल होती हैं. इस वैल्यू से यह पता नहीं चलता कि पुष्टि की प्रोसेस पूरी हुई है या नहीं.

जांच का उदाहरण

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

<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 17 से, किसी खास यूआरएल को सिस्टम कैसे हल करता है, यह जानने के लिए, ऐक्टिविटी मैनेजर (am start) कमांड के साथ --debug-link फ़्लैग का इस्तेमाल किया जा सकता है. यह टूल, इंटेंट से मैच करने वाले उम्मीदवार ऐप्लिकेशन की पूरी जानकारी देता है. साथ ही, ऐप्लिकेशन मेनिफ़ेस्ट और assetlinks.json फ़ाइल (डाइनैमिक ऐप्लिकेशन लिंक के लिए) के उन खास नियमों की जानकारी देता है जिनका आकलन, रिज़ॉल्यूशन के दौरान किया गया था.

किसी खास यूआरएल के लिए, लिंक रिज़ॉल्यूशन की जांच करने के लिए, टर्मिनल विंडो में यह कमांड चलाएं:

adb shell am start --debug-link -a android.intent.action.VIEW -d "https://xyz.com/foo"

डाइग्नोस्टिक आउटपुट, App Link Resolution Debug हेडर के तहत प्रिंट होता है. इसमें, रिज़ॉल्यूशन की प्रोसेस को समझने में आपकी मदद करने के लिए, ये सेक्शन शामिल होते हैं:

  • Target details: मैच करने वाले हर उम्मीदवार ऐप्लिकेशन की पहचान, उसके पैकेज के नाम और टारगेट ऐक्टिविटी से होती है.
  • इंटेंट फ़िल्टर मिलान (AndroidManifest.xml): दिखाता है कि मेनिफ़ेस्ट इंटेंट फ़िल्टर में मौजूद किन स्टैटिक एट्रिब्यूट (जैसे, scheme, host, path, pathPrefix या pathPattern) का मिलान यूआरआई से हुआ.
  • ऐप्लिकेशन लिंक की पुष्टि: डोमेन की पुष्टि की मौजूदा स्थिति दिखाता है. जैसे, STATE_SUCCESS.
  • Dynamic App Links: अगर ऐप्लिकेशन, अपनी assetlinks.json फ़ाइल में डाइनैमिक ऐप्लिकेशन लिंक के मैचिंग के नियमों का इस्तेमाल करता है, तो इस सेक्शन में हर उस नियम की सूची दिखती है जिसका आकलन यूआरआई के हिसाब से किया गया था. हर नियम में, मैच किए गए यूआरआई फ़िल्टर (जैसे, पाथ प्रीफ़िक्स या पैटर्न) और allow फ़ील्ड की जानकारी दिखती है:
    • allow = 0: यह अनुमति/शामिल करने का नियम है (allow: true). अगर यह नियम मैच करता है, तो ऐप्लिकेशन को यूआरआई खोलने की अनुमति मिलती है.
    • allow = 1: यह ब्लॉक/एक्सक्लूज़न का नियम है (allow: false / exclude: true). अगर यह नियम मैच करता है, तो ऐप्लिकेशन को यूआरआई खोलने से रोका जाता है.
    • ध्यान दें: खाली फ़िल्टर स्ट्रिंग (filter =) का मतलब है कि पाथ प्रीफ़िक्स खाली है. यह डोमेन के सभी पाथ से मैच करता है. यह वाइल्डकार्ड या कैच-ऑल की तरह काम करता है.

डीबग आउटपुट का उदाहरण

मान लें कि com.example.xyzapp नाम का कोई ऐप्लिकेशन, https://xyz.com डोमेन से जुड़ा है. इस ऐप्लिकेशन की assetlinks.json फ़ाइल में, डाइनैमिक नियम तय किए गए हैं. इन नियमों के मुताबिक, /foo* को छोड़कर बाकी सभी पाथ के लिए अनुमति दी गई है:

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.xyzapp",
      "sha256_cert_fingerprints": ["..."]
    },
    "relation_extensions": {
      "delegate_permission/common.handle_all_urls": {
        "dynamic_app_link_components": [
          {"/": "/foo*", "exclude": true},
          {"/": "*"}
        ]
      }
    }
  }
]

--debug-link का इस्तेमाल करके, https://xyz.com/foo यूआरएल की समस्या का पता लगाने पर:

adb shell am start --debug-link -a android.intent.action.VIEW -d "https://xyz.com/foo"

कमांड, डाइग्नोस्टिक की यह जानकारी आउटपुट करती है:

--- App Link Resolution Debug ---

URI: https://xyz.com/foo
Resolution: Ambiguous (Multiple apps or Browser fallback)
This usually happens when multiple apps can handle the link and no default is set.

All Matching Candidates:

Target:
  Package: com.example.xyzapp
  Activity: com.example.xyzapp.MainActivity

  Intent Filter Match (AndroidManifest.xml)
    Scheme: 'https' matched android:scheme="https"
    Host: 'xyz.com' matched android:host="xyz.com"

App Link Verification:
  Verification status: STATE_SUCCESS
  Dynamic App Links:
    -> Matched Rule 0: UriRelativeFilterGroup { allow = 1, uri_filters = {UriRelativeFilter { uriPart = PATH, patternType = PREFIX, filter = /foo }},  }
    -> Matched Rule 1: UriRelativeFilterGroup { allow = 0, uri_filters = {UriRelativeFilter { uriPart = PATH, patternType = PREFIX, filter =  }},  }

Target:
  Package: org.chromium.webview_shell
  Activity: org.chromium.webview_shell.WebViewBrowserActivity

  Intent Filter Match (AndroidManifest.xml)
    Scheme: 'https' matched android:scheme="https"

---------------------------------

Starting: Intent { act=android.intent.action.VIEW dat=https://xyz.com/foo }

इस उदाहरण में, सिस्टम ने assetlinks.json से, डाइनैमिक ऐप्लिकेशन लिंक के दो नियमों का आकलन किया:

  • नियम 0 (allow = 1, filter = /foo): यह {"/": "/foo*", "exclude": true} से जनरेट हुआ है. यह एक्सक्लूज़न का नियम (allow: false) है. इसके तहत, /foo पाथ प्रीफ़िक्स से शुरू होने वाले यूआरएल को ब्लॉक किया जाता है.
  • नियम 1 (allow = 0, filter =): यह {"/": "*"} से जनरेट हुआ है. यह इन्क्लूज़न का नियम (allow: true) है. इसमें पाथ प्रीफ़िक्स खाली है (filter =). यह xyz.com के सभी पाथ से मैच करता है (कैच-ऑल).

इस स्थिति में, रिज़ॉल्यूशन कैसे काम करता है:

  1. नियम 0 और नियम 1, दोनों ही यूआरएल https://xyz.com/foo से मैच करते हैं.
  2. डाइनैमिक ऐप्लिकेशन लिंक के नियमों का आकलन, क्रम से ऊपर से नीचे की ओर किया जाता है. जो नियम सबसे पहले मैच करता है उसे लागू किया जाता है.
  3. स्टेटमेंट की सूची में नियम 0 सबसे पहले दिखता है और यह एक्सक्लूज़न का नियम है (allow = 1). इसलिए, इसे अनुमति के सामान्य नियम (नियम 1) से ज़्यादा प्राथमिकता मिलती है.
  4. इसलिए, ऐप्लिकेशन को https://xyz.com/foo को हैंडल करने से रोका जाता है. इस वजह से, सिस्टम ब्राउज़र पर वापस चला जाता है या एक से ज़्यादा विकल्पों की जानकारी देने वाला डायलॉग दिखाता है.