Debugging deep links with adb

# 1. What does the system think about your domains?
adb shell pm get-app-links com.example.shop

# 2. Re-run verification after fixing assetlinks.json (no reinstall needed)
adb shell pm verify-app-links --re-verify com.example.shop

# 3. What would actually happen to a real tap? No package name, so the
#    system resolves it the way a browser would.
adb shell am start -W -a android.intent.action.VIEW \
  -c android.intent.category.BROWSABLE \
  -d "https://example.com/products/42"

# Per-domain verification state for one package
adb shell pm get-app-links com.example.shop

# Every app on the device that claims domains — useful when another app
# is competing for yours
adb shell pm get-app-links

# Force re-verification (Android 12+)
adb shell pm verify-app-links --re-verify com.example.shop

# Simulate the user approving your app for a domain, bypassing verification.
# Confirms your routing works while you fix the fingerprint.
adb shell pm set-app-links-user-selection --user 0 \
  --package com.example.shop true example.com

# Reset link handling for the package back to defaults
adb shell pm set-app-links --package com.example.shop 0 all

# Pre-Android 12 devices used a different subsystem entirely
adb shell dumpsys package domain-preferred-apps

# Honest test — no package, browsable category, like a real tap
adb shell am start -W -a android.intent.action.VIEW \
  -c android.intent.category.BROWSABLE \
  -d "https://example.com/products/42"

# Routing test only — explicit package, always opens the app
adb shell am start -W -a android.intent.action.VIEW \
  -d "https://example.com/products/42" com.example.shop

# Custom scheme
adb shell am start -W -a android.intent.action.VIEW -d "myapp://products/42"

# Which activity WOULD handle it, without launching anything
adb shell pm resolve-activity --brief \
  -a android.intent.action.VIEW \
  -c android.intent.category.BROWSABLE \
  -d "https://example.com/products/42"

# Every activity that could handle it, in priority order
adb shell pm query-activities \
  -a android.intent.action.VIEW \
  -c android.intent.category.BROWSABLE \
  -d "https://example.com/products/42"

# URLs with query strings and fragments need quoting, and & must be escaped
adb shell am start -W -a android.intent.action.VIEW \
  -d "https://example.com/p/42?utm_source=test\&ref=abc#reviews"

# Full manifest data: intent filters, permissions, signatures
adb shell dumpsys package com.example.shop

# Just the intent filters — confirms what the INSTALLED build declares,
# which is not always what your source says
adb shell dumpsys package com.example.shop | grep -A 30 "android.intent.action.VIEW"

# Domain verification section
adb shell dumpsys package com.example.shop | grep -A 20 -i "domain"

# Installed version — confirm the device is running the build you think
adb shell dumpsys package com.example.shop | grep -E "versionName|versionCode"

# Which installer put it there. "com.android.vending" means Play, which
# means Play App Signing, which decides the fingerprint you need.
adb shell pm list packages -i com.example.shop

# Pull the APK off the device and read the actual signing certificate
adb shell pm path com.example.shop
adb pull /data/app/.../base.apk
keytool -printcert -jarfile base.apk

# Watch intent resolution and your app's handling in real time
adb logcat | grep -iE "intent|applink|deeplink|verif"

# Just your app's output
adb logcat --pid=$(adb shell pidof -s com.example.shop)

# Clear the buffer first so you only see this attempt
adb logcat -c && adb shell am start -W -a android.intent.action.VIEW \
  -c android.intent.category.BROWSABLE -d "https://example.com/p/42"

# Send a synthetic install referrer to test YOUR PARSER.
# The real broadcast was removed from Play in 2020 — this exercises your
# handling logic, not whether the referrer actually arrives.
adb shell am broadcast \
  -a com.android.vending.INSTALL_REFERRER \
  -n com.example.shop/.InstallReferrerReceiver \
  --es "referrer" "utm_source=test&utm_campaign=debug&dl=%2Fproducts%2F42"