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

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

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

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

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

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

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

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

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

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

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

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

मान लें कि https://xyz.com डोमेन से जुड़ा कोई ऐप्लिकेशन (com.example.xyzapp) है. यह ऐप्लिकेशन, 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 पाथ प्रीफ़िक्स से शुरू होने वाले यूआरएल को ब्लॉक करता है.
  • पहला नियम (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 को हैंडल करने से बाहर रखा गया है. इससे सिस्टम, ब्राउज़र पर वापस चला जाता है या एक डिसैंबिग्युएशन डायलॉग दिखाता है.