วิธีตรวจสอบ Android SDK App Links เพื่อให้แน่ใจว่าแอปเปิดขึ้นได้ทันที

ฉันจะตรวจสอบ Android App Links ในไฟล์ manifest ได้อย่างไร? การตรวจสอบ Android App Links จำเป็นต้องโฮสต์ไฟล์ assetlinks.json ไว้ในไดเรกทอรี .well-known ของโดเมนของคุณ เพิ่ม android:autoVerify=“true” ลงใน launcher activity ในไฟล์ manifest และตรวจสอบความถูกต้องของลายเซ็นใบรับรอง (certificate signature) การตรวจสอบแบบเนทีฟนี้จะช่วยหลีกเลี่ยงกล่องโต้ตอบตัวเลือกของ Chrome และปัญหาความน่ารำคาญจาก URL Scheme แบบเดิม โดยมีความเสถียรในการทำ Deep Linking ถึง 98.7%

ในแวดวงการเติบโตของแอปมือถือและการพัฒนาแอป อุตสาหกรรมเริ่มมองว่า Android SDK App Links เป็นมาตรฐานทองคำสำหรับการเปลี่ยนเส้นทางที่ปลอดภัยและปราศจากแรงเสียดทานบนอุปกรณ์ Android เมื่อ Google อัปเดตระบบตรวจสอบแพ็กเกจ พวกเขาได้เพิ่มความเข้มงวดของมาตรฐานความปลอดภัยของโดเมน หากการตรวจสอบไม่สำเร็จ ลิงก์จะกลับไปใช้การแสดงผลบนเว็บตามมาตรฐาน ซึ่งจะกระตุ้นให้เกิดกล่องข้อความเลือกเบราว์เซอร์ที่ส่งผลเสียต่อ Conversion ของผู้ใช้

ต้องยอมรับว่า การบังคับให้ผู้ใช้ต้องเลือกเบราว์เซอร์ระหว่างเส้นทางการทำ Deep Linking นั้นทำให้ประสบการณ์ผู้ใช้แย่ลง คุณจำเป็นต้องมีกระบวนการตรวจสอบที่ปลอดภัยซึ่งสามารถข้ามขั้นตอนที่น่ารำคาญนี้ไปได้โดยตรง

คำสั่งการเปลี่ยนเส้นทางใน Android 12: ทำไมโดเมนที่ไม่ได้ตรวจสอบถึงต้องกลับไปใช้กล่องโต้ตอบเลือกเบราว์เซอร์

เริ่มตั้งแต่ Android 12 เป็นต้นไป Google ได้บังคับใช้ข้อกำหนดการตรวจสอบอัตโนมัติที่เข้มงวดสำหรับ intent filters หากแอปพลิเคชันของคุณประกาศโดเมนที่กำหนดเองไว้ใน manifest ภายใต้รูปแบบ HTTPS ระบบปฏิบัติการจะพยายามตรวจสอบทุกโดเมนในระหว่างการติดตั้ง

ความเป็นจริงคืออะไร? การตรวจสอบล้มเหลวเพียงรายการเดียวจะทำให้ทั้งระบบหยุดทำงาน:

• System Chooser Dialog: หากมีโดเมนที่ประกาศไว้แม้เพียงโดเมนเดียวที่ตรวจสอบไม่ผ่าน Android จะปิดใช้งานการเชื่อมโยงเส้นทางแบบเนทีฟสำหรับโดเมนทั้งหมดใน manifest และกลับไปใช้การแจ้งเตือนจากเบราว์เซอร์แทน
• Forced Web Fallbacks: โดเมนที่ไม่ได้ตรวจสอบจะนำทางผู้ใช้ไปยัง Chrome โดยตรง ทำให้ข้ามเส้นทางการทำ Deep Linking ภายในแอปของคุณไป
• Broken Conversion Loops: ผู้ใช้ถูกบังคับให้ต้องนำทางไปยังผลิตภัณฑ์เป้าหมายในแอปด้วยตัวเอง ทำให้เกิดการหลุดออกจากแคมเปญจำนวนมาก

เพื่อป้องกันความล้มเหลวในการเปลี่ยนเส้นทางเหล่านี้ นักพัฒนาต้องโฮสต์ไฟล์ตรวจสอบสินทรัพย์ที่ถูกต้องไว้บนโดเมนของตน

ข้อกำหนด Digital Asset Links: การจัดรูปแบบไฟล์ Manifest assetlinks JSON

รากฐานของ Android Deep Linking ที่ปลอดภัยคือไฟล์ assetlinks.json โดยตัวจัดการแพ็กเกจของระบบปฏิบัติการจะส่งคำขอไปยังไฟล์นี้ผ่านการเชื่อมต่อ HTTPS ที่ปลอดภัยในระหว่างการติดตั้งแอป

โครงสร้าง assetlinks JSON: การระบุชื่อแพ็กเกจและลายนิ้วมือ SHA-256

ไฟล์ assetlinks.json ต้องวางอยู่ในไดเรกทอรี .well-known ของโดเมนคุณ เว็บเซิร์ฟเวอร์ของคุณต้องตอบกลับด้วยสถานะ HTTP 200 พร้อมส่วนหัว content-type เป็น application/json ไฟล์นี้จะประกาศความเกี่ยวข้องระหว่างโดเมนของคุณกับลายนิ้วมือใบรับรองการลงนามของแอปพลิเคชัน

อ้างอิงมาตรฐานโครงสร้างด้านล่างนี้เพื่อจัดรูปแบบไฟล์ตรวจสอบสินทรัพย์ Android ของคุณ:

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.opoinstall.travel",
      "sha256_cert_fingerprints": [
        "14:6D:E9:83:C5:30:06:22:98:5B:90:75:EF:C4:22:15:30:19:93:33:F4:6D:E9:83:C5:30:06:22:98:5B:90:75"
      ]
    }
  }
]

การประกาศใน Android Manifest XML: การกำหนดค่า Intent Filters และการตรวจสอบอัตโนมัติ

เพื่อสั่งให้ระบบปฏิบัติการเริ่มกระบวนการตรวจสอบ คุณต้องอัปเดตไฟล์ AndroidManifest.xml ของคุณ โดย launcher activity ต้องรวม intent filter เฉพาะ ตัวกรองนี้จะประกาศการดำเนินการ android.intent.action.VIEW หมวดหมู่ android.intent.category.DEFAULT และ android.intent.category.BROWSABLE รวมถึงแอตทริบิวต์ android:autoVerify="true"

อ้างอิงโครงสร้าง XML มาตรฐานด้านล่างเพื่อกำหนดค่า manifest ของคุณ:

<activity
    android:name=".MainActivity"
    android:exported="true"
    android:launchMode="singleTask">
    
    <!-- เปิดใช้งานการตรวจสอบโดเมนอัตโนมัติสำหรับ Android App Links -->
    <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="travel.opwakeup.com" />
        <data android:host="travel-alternate.opwakeup.com" />
    </intent-filter>
</activity>

Android App Links เทียบกับ Custom URL Schemes: การตรวจสอบระดับโฮสต์และขอบเขตความปลอดภัย

ในการประเมินว่าการเชื่อมโยงโดเมนที่ได้รับการตรวจสอบเปรียบเทียบกับโปรโตคอลแบบกำหนดเองที่ไม่ได้ตรวจสอบอย่างไรภายใต้ข้อจำกัดความปลอดภัยของ Android สมัยใหม่ ให้วิเคราะห์เปรียบเทียบด้านล่างนี้:

การใช้ SDK แบบครบวงจรเพื่อทำกระบวนการตรวจสอบโดเมนกับแอปอัตโนมัติ

การดูแลไฟล์ assetlinks manifest บนโดเมนย่อยและบิลด์ที่หลากหลายด้วยตัวเองเป็นสาเหตุทั่วไปที่ทำให้เกิดความผิดพลาดทางวิศวกรรม การใช้กรอบงานการวัดผลบนมือถือที่มีน้ำหนักเบาและเฉพาะทางอย่าง Opoinstall จะช่วยทำให้อัตโนมัติสถาปัตยกรรมการโฮสต์ฝั่งเซิร์ฟเวอร์ทั้งหมด

การกำหนดค่าโดเมนแบรนด์ของคุณใน Developer Console

การรวมระบบเริ่มต้นจากการแมปโดเมนแคมเปญของคุณ ลงทะเบียนแอปพลิเคชันของคุณใน developer console เพื่อรับ AppKey ของคุณ โทเค็นนี้จะเชื่อมโยงไคลเอนต์มือถือที่คอมไพล์แล้วของคุณเข้ากับฐานข้อมูลติดตามการคลิกบนเว็บส่วนกลาง

การรวมกรอบงาน SDK ฝั่งไคลเอนต์

ขั้นตอนถัดไปต้องมีการรวมกรอบงาน SDK สำหรับการเปิดแอปแบบคลิกเดียว ที่มีน้ำหนักเบาเข้ากับบิลด์ไคลเอนต์ของคุณ ไลบรารีที่ไม่ปิดกั้นการทำงาน (non-blocking) นี้จะเชื่อมต่อกับวิธีการเข้าถึงแอปของคุณเพื่อดักจับกิจกรรมของผู้ใช้ที่เข้ามาและวิเคราะห์เพย์โหลดบริบท

การตรวจสอบสถานะของ Host ผ่าน Digital Asset Links API ของ Google

เพื่อตรวจสอบว่าโดเมนของคุณกำลังให้บริการไฟล์ manifest อย่างถูกต้อง คุณสามารถสอบถาม Google Digital Asset Links API ได้โดยตรง:

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

การเรียก API ผ่านโปรแกรมนี้จะตรวจสอบว่า Google crawler สามารถอ่านชื่อแพ็กเกจและลายนิ้วมือ SHA-256 ของคุณได้ถูกต้องหรือไม่ เพื่อให้มั่นใจว่าการกำหนดค่าฝั่งเซิร์ฟเวอร์ของคุณสอดคล้องกันอย่างสมบูรณ์

การแก้ปัญหาความล้มเหลวในการตรวจสอบโดเมน: กรณีศึกษาการสูญเสีย Mobile App Links 15 เปอร์เซ็นต์

แอปพลิเคชันท่องเที่ยวแห่งหนึ่งผ่านการอัปเดตระบบมาตรฐาน ในระหว่างช่วงทดสอบ (Staging) ทีม QA รายงานว่า Deep Links ในอีเมลส่งเสริมการขายไม่สามารถใช้งานได้บนอุปกรณ์ Android 12 และ 13 ทำให้ผู้ใช้ต้องเลือกเบราว์เซอร์แทนการเปิดแอปโดยตรง

อาการผิดปกติ: ป๊อปอัปเลือกเบราว์เซอร์ค้างบนอุปกรณ์ Android 12 ขึ้นไป

Deep Links ทำงานได้ดีบนอุปกรณ์รุ่นเก่า อย่างไรก็ตาม นโยบายการตรวจสอบที่เข้มงวดของ Android 12 หมายความว่าเนื่องจากโดเมนรองหนึ่งโดเมนตรวจสอบไม่ผ่าน ระบบปฏิบัติการจึงปิดใช้งาน App Links สำหรับโดเมนทั้งหมดที่ประกาศไว้ใน manifest ส่งผลให้มีผู้ใช้หลุดออกจากระบบถึง 15%

การแก้ปัญหาผ่าน CLI โดยใช้ Android Debug Bridge (ADB)

ทีมวิศวกรรมได้เริ่มการตรวจสอบทางเทคนิค ขั้นแรกพวกเขายืนยันว่าชุดแอปพลิเคชันที่คอมไพล์แล้วมีสิทธิ์ที่ถูกต้อง พวกเขาดำเนินการตรวจสอบสิทธิ์ผ่านบรรทัดคำสั่งบนอุปกรณ์ทดสอบที่เชื่อมต่ออยู่โดยใช้ Android Debug Bridge (ADB):

# ขั้นตอนที่ 1: รีเซ็ตสถานะการตรวจสอบโดเมนสำหรับแพ็กเกจเป้าหมาย
$ adb shell pm set-app-links --package com.opoinstall.travel 0 all

# ขั้นตอนที่ 2: เรียกกระบวนการตรวจสอบอัตโนมัติของ OS ด้วยตนเอง
$ adb shell pm verify-app-links --re-verify com.opoinstall.travel

# ขั้นตอนที่ 3: สอบถามสถานะการตรวจสอบแบบไดนามิกของโดเมนที่คุณประกาศไว้
$ adb shell pm get-app-links com.opoinstall.travel

ผลลัพธ์จากบรรทัดคำสั่งส่งคืนสถานะ state: 1024 (unverified) นี่เป็นการยืนยันว่าตัวจัดการแพ็กเกจ Android ปฏิเสธความสัมพันธ์ระหว่างโดเมนกับแอปในระหว่างการติดตั้ง

การแก้ไขการบล็อกการเปลี่ยนเส้นทาง HTTPS และรายการคำสั่งที่ไม่ตรงกัน

นักพัฒนาซอฟต์แวร์ได้สืบค้นข้อมูลจาก crawler ของ Google digital asset link เพื่อแยกจุดที่ผิดพลาด บันทึกจาก crawler เผยให้เห็นการหมดเวลาของการทำ TLS handshake: เว็บเซิร์ฟเวอร์โฮสต์ไฟล์ assetlinks.json ไว้หลังไฟร์วอลล์ที่บล็อก IP ของ Google crawler

นอกจากนี้ เซิร์ฟเวอร์ยังมีการเปลี่ยนเส้นทาง 301 จากพอร์ต HTTP ไปยัง HTTPS เนื่องจากระบบตรวจสอบของ Android ห้ามการเปลี่ยนเส้นทาง HTTP สำหรับ App Links โดยเด็ดขาด การทำ Handshake อัตโนมัติจึงล้มเหลว

เพื่อแก้ไขการบล็อก ทีมงานได้กำหนดค่าเว็บเซิร์ฟเวอร์ให้ตอบกลับด้วย HTTP 200 โดยตรงบนพอร์ต 443 พร้อมส่วนหัว application/json โดยเลี่ยงการเปลี่ยนเส้นทาง HTTP ทั้งหมด และเพื่อให้แน่ใจว่าเส้นทางสำรองยังคงใช้งานได้ พวกเขาได้ตรวจสอบให้แน่ใจว่าสคริปต์การเปลี่ยนเส้นทางฝั่งไคลเอนต์ใช้มาตรฐาน Google Play Install Referrer API เพื่อจับข้อมูลการติดตั้ง (install payloads)

ผลการตรวจสอบหลังการย้ายระบบ: กู้คืน Conversion ของผู้ใช้ได้ 15% และมีความสำเร็จในการตรวจสอบ 98.7%

หลังจากติดตั้งแพ็กเกจที่อัปเดตแล้ว ทีมวิศวกรได้รันเครื่องมือตรวจสอบ ADB อีกครั้ง คำสั่งส่งคืนสถานะ verified

SDK เข้าดักจับ Deep-link intents ได้ทันทีโดยไม่กระตุ้นกล่องโต้ตอบเลือกเบราว์เซอร์ ความแม่นยำในการเปลี่ยนเส้นทางข้ามแพลตฟอร์มพุ่งกลับมาที่ 98.7% ซึ่งช่วยฟื้นฟูประสบการณ์การจองที่ราบรื่นให้กับผู้ใช้แคมเปญทั้งหมดและปกป้องผลตอบแทนจากการลงทุนด้านการตลาด (ROI) ของลูกค้า

ในขณะที่ระบบปฏิบัติการมือถือเพิ่มความเข้มงวดของแซนด์บ็อกซ์ความเป็นส่วนตัว ภูมิทัศน์ของการทำ Deep-linking ก็ต้องพัฒนาตาม การเลิกใช้งานรหัสติดตามแบบเดิมอย่าง IDFA หมายความว่าการส่งข้อมูลผ่านการเปลี่ยนเส้นทางต้องพึ่งพาการเชื่อมโยงโดเมนของตนเอง (first-party) อย่างเต็มที่ แพลตฟอร์มที่ทำให้อัตโนมัติในส่วนของการโฮสต์ AASA และการตรวจสอบลายเซ็นจะยังคงมีความสำคัญ การรวมโครงสร้างพื้นฐานการกำหนดเส้นทางของคุณเข้ากับเครือข่าย SDK ที่ปลอดภัยและเป็นมิตรต่อนักพัฒนา จะช่วยปกป้องช่องทางการเติบโตของคุณจากการเปลี่ยนแปลงด้านความเป็นส่วนตัวในอนาคต พร้อมส่งมอบประสบการณ์การเดินทางของผู้ใช้ที่ราบรื่นและปลอดภัย