如何驗證 Android SDK App Links 以確保 App 即時啟動

如何在 manifest 中驗證 Android App Links？ 驗證 Android App Links 需要在您網域的 .well-known 目錄下託管 assetlinks.json 檔案，並在您的啟動活動（launcher activity）的 manifest 中加入 android:autoVerify=“true”，同時驗證憑證簽章。這種原生驗證機制可繞過 Chrome 選擇器對話框及傳統 URL Scheme 彈出視窗的阻礙，達到 98.7% 的深度連結穩定性。

在行動增長與 App 開發領域，業界越來越傾向將 Android SDK App Links 視為 Android 裝置上安全、零阻力重新導向的黃金標準。當 Google 更新套件驗證系統時，同步收緊了網域安全性標準。若未能成功驗證，連結將退回至標準網頁渲染，觸發瀏覽器選擇提示，進而影響用戶轉換。

面對現實吧：在深度連結旅程中強迫用戶選擇瀏覽器會降低體驗。您需要一個經過驗證、安全且能原生繞過對話框阻礙的交握流程。

Android 12 重新導向要求：為何未經驗證的網域會退回至選擇器對話框

從 Android 12 開始，Google 針對意圖過濾器（intent filters）強制執行嚴格的自動驗證要求。若您的應用程式在 manifest 中以 HTTPS 協議宣告了自訂網域，作業系統會在安裝期間嘗試驗證每個網域。

真相是？只要單一驗證失敗，整個鏈結就會中斷：

• 系統選擇器對話框： 若宣告的網域中有任何一個未能通過交握，Android 將停用 manifest 中所有網域的原生路由，並退回至瀏覽器提示。
• 強制網頁後備（Web Fallbacks）： 未經驗證的網域會將用戶直接導向 Chrome，繞過您原本設定的應用程式內深度連結路徑。
• 轉換循環中斷： 用戶被迫手動瀏覽您的應用程式以尋找目標產品，導致行銷活動大幅流失用戶。

為防止這些重新導向失敗，開發者必須在網域上託管有效的資產驗證檔案。

數位資產連結規範（Digital Asset Links Specification）：格式化 assetlinks JSON 清單

安全 Android 深度連結的基礎在於 assetlinks.json 清單。作業系統的套件管理器會在 App 安裝期間透過安全 HTTPS 連線查詢此檔案。

assetlinks JSON 架構：指定套件名稱與 SHA-256 指紋

assetlinks.json 檔案必須位於您網域的 .well-known 目錄中。您的網頁伺服器必須回傳 content-type 為 application/json 的 HTTP 200 直接回應。該檔案宣告了您的網域與應用程式唯一簽章憑證之間的關聯。

請參考下方的結構標準來格式化您的 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 宣告：配置意圖過濾器與自動驗證交握

若要指示作業系統啟動驗證交握，您必須更新 AndroidManifest.xml 檔案。目標啟動活動必須包含特定的意圖過濾器（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">
    
    <!-- Enable automatic domain verification for 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 與自訂 URL Schemes：主機級驗證與安全範圍

若要評估已驗證的網域關聯如何與 Android 現代安全限制下的未驗證自訂協定進行比較，請參考下表分析：

部署統一的 SDK 以自動化「網域至 App」交握

在多個子網域和建置變體間手動維護 assetlinks 清單是常見的工程失誤點。整合專用、輕量級的行動測量架構（如 Opoinstall）可自動化整個伺服器端託管架構。

在開發者控制台中配置您的品牌網域

您的整合始於映射行銷活動網域。在開發者控制台中註冊您的應用程式以取得 AppKey。此 token 將您編譯的行動用戶端與您的中心網頁點擊追蹤資料庫連結起來。

整合用戶端 SDK 架構

下一步需要將我們輕量級的一鍵啟動行動 SDK 架構整合至您的用戶端建置中。這個非阻塞函式庫會掛接至您 App 的進入點方法，以攔截傳入的用戶活動並解析上下文資料。

透過 Google 的數位資產連結 API 驗證作用中主機聲明

若要驗證您的網域是否正確提供清單檔案，您可以直接查詢 Google 的數位資產連結 API：

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

此程式化 API 呼叫可檢查 Google 的驗證爬蟲是否能正確讀取您的套件名稱與 SHA-256 指紋，確保您的伺服器端配置完全對齊。

除錯網域驗證失敗：行動 App Links 流失 15% 的案例研究

某大型旅遊應用程式進行了一次標準系統更新。在預演期間，QA 團隊回報 Android 12 與 13 裝置上的推廣郵件深度連結失效，導致用戶被迫選擇網頁瀏覽器，而非直接啟動原生 App。

異常症狀：Android 12+ 裝置上持續出現瀏覽器選擇器彈出視窗

這些深度連結在舊型裝置上運作正常。然而，Android 12 的嚴格驗證政策意味著，只要一個次要網域未能通過交握，作業系統就會停用 manifest 中宣告的所有網域的 App Links，導致用戶導入率下降了 15%。

透過 Android Debug Bridge 與狀態對帳進行 CLI 除錯

工程團隊發起了一項技術稽核。首先，他們確認編譯後的 App 套件包含正確的權限聲明（entitlements）。他們使用 Android Debug Bridge (ADB) 在已連線的測試裝置上執行指令行權限檢查：

# 步驟 1：重置目標套件的網域驗證狀態
$ adb shell pm set-app-links --package com.opoinstall.travel 0 all

# 步驟 2：手動觸發作業系統自動驗證交握
$ 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 套件管理器在安裝期間拒絕了網域至 App 的關聯。

解決 HTTPS 重新導向阻礙與聲明清單不符問題

開發者查詢了 Google 的數位資產連結驗證爬蟲以定位錯誤。爬蟲日誌顯示 TLS 交握逾時：網頁伺服器將 assetlinks.json 檔案放置在阻擋自動化 Google 爬蟲 IP 的防火牆後方。

此外，伺服器正在執行從 HTTP 埠到 HTTPS 的 301 重新導向。由於 Android 的驗證系統嚴格禁止 App Links 的 HTTP 重新導向，導致自動交握失敗。為了解決此阻礙，團隊將網頁伺服器設定為在 443 埠回傳 application/json 標頭的 HTTP 200 直接回應，繞過任何 HTTP 重新導向。為確保後備路徑保持活躍，他們確認用戶端重新導向指令碼正在使用標準的 Google Play Install Referrer API 來捕捉安裝資料。

遷移後稽核：恢復 15% 用戶轉換並達到 98.7% 驗證成功率

重新安裝更新後的套件後，工程團隊重新執行了 ADB 驗證工具。該指令回傳了 verified 狀態。

SDK 立即攔截了深度連結意圖，而未觸發選擇器對話框。跨平台重新導向準確度回升至 98.7%，成功恢復了所有行銷活動用戶的順暢預訂體驗，並保障了客戶的行銷投資報酬率。

隨著行動作業系統收緊隱私沙盒，深度連結領域也必須進化。像 IDFA 這類舊式追蹤 ID 的折舊意味著，資料傳遞式的重新導向必須完全依賴安全的第一方網域關聯。自動化 AASA 託管與簽章驗證的平台將依然至關重要。透過將您的路由基礎架構集中在安全、開發者友善的 SDK 網路中，您可以在迎接未來隱私變革的同時，保護您的增長漏斗，並提供流暢、安全的用戶旅程。