Assetlinks JSON Generator: สร้าง Android App Links ที่น่าเชื่อถือในไม่กี่นาที

ลองแตะลิงก์ไปหน้าสินค้าดูสิ — แทนที่ browser จะเปิดแท็บขึ้นมา แอปบนมือถือกลับเปิดตรงไปที่สินค้านั้นทันที นั่นคือ Android App Links ที่ทำงานอยู่เบื้องหลัง และกลไกทั้งหมดนี้พิงไฟล์ JSON ไฟล์เดียวบนเว็บไซต์ของคุณ เพราะ Android จะไม่ยอมส่งผู้ใช้เข้าแอป ถ้าโดเมนของคุณไม่ยืนยันความสัมพันธ์แบบเข้ารหัสไว้ และ "ใบรับรอง" ตัวนั้นก็คือไฟล์ assetlinks.json

ปัญหาคือการทำไฟล์นี้ให้ถูกต้องไม่ใช่เรื่องสนุกเลย SHA-256 fingerprint ของ signing certificate เป็นเลขฐานสิบหก 64 ตัวจัดเป็นคู่คั่นด้วยจุดคู่ โครงสร้างเพี้ยนแค่จุดเดียว Android ก็เงียบๆ เปิดลิงก์ใน browser ให้กลับไปเลย Assetlinks JSON Generator ช่วยตัดความเสี่ยงนี้ออก: ใส่ package name วาง fingerprint เปิด credential sharing ถ้าต้องการ แล้ว copy ไฟล์ Digital Asset Links ที่ถูกต้องออกมา — generate ทั้งหมดใน browser ของคุณ ไม่ส่งข้อมูลออกไปไหน

บทความนี้จะพาไปดูว่าทำไมไฟล์นี้สำคัญ วิธี generate ทีละขั้น หลักการ verify ของ Android และเทคนิค debug ที่ช่วยประหยัดเวลาหลายชั่วโมงตอนลิงก์ดื้อไม่ยอมเปิดในแอป

ทำไมต้องใช้ Assetlinks JSON Generator?

• พิมพ์ผิดจุดเดียว ทั้ง flow พัง — วงเล็บหายหรือ fingerprint ผิดรูปแบบ ทำให้ statement ใช้ไม่ได้ทันที เครื่องมือนี้ emit JSON ที่ถูกโครงสร้างทุกครั้ง
• พิมพ์ fingerprint เองแล้วพลาดง่าย — SHA-256 แต่ละค่าถูกเทียบแบบ exact match สลับคู่ตัวอักษรก็ fail เงียบๆ วางครั้งเดียวเครื่องมือจัดรูปแบบให้ถูกต้อง
• หลายแอป ไฟล์เดียว — เวอร์ชัน free/pro, build สำหรับแท็บเล็ต หรือแอปคู่สาย ใส่รวมใน assetlinks.json ไฟล์เดียวได้
• debug กับ release อยู่ด้วยกันได้ — ใส่ทั้ง debug keystore และ release signing key ไว้ในไฟล์เดียว เครื่อง QA กับผู้ใช้จริงก็ verify ผ่านหมด
• เปิด credential sharing ได้ง่าย — relation แบบ share_target เชื่อมแอปเข้ากับ Credential Manager ของ Android ด้วยการกดสวิตช์ ไม่ต้องจำ relation string เอง
• ทำงานฝั่ง client ล้วนๆ — package name และ fingerprint ไม่หลุดออกจาก browser ปลอดภัยแม้กับแอปที่ยังไม่เปิดตัว

ฟีเจอร์หลักของ Assetlinks JSON Generator

สองจุดที่ควรเน้น: namespace ต้องเป็น android_app เป๊ะๆ ค่าอื่นทำให้ verification ล่มเงียบๆ เครื่องมือตั้งให้เอง และการรองรับ หลาย fingerprint ทำให้ rollout จริงเป็นไปได้ — ตอน rotate key หรือย้ายไป Play App Signing จะมีช่วงที่ certificate ที่ valid มีสองตัวพร้อมกัน

วิธีใช้งาน Assetlinks JSON Generator

1. หา SHA-256 fingerprint ของ signing certificate — ถ้าเก็บ keystore เอง รันคำสั่ง:

   keytool -list -v -keystore release-key.jks -alias my-key-alias
   

   แล้ว copy บรรทัด SHA-256 ถ้าใช้ Google Play App Signing ให้เอาค่าจาก App signing key certificate ใน Play Console

2. ใส่ package name — เปิด Assetlinks JSON Generator แล้วกรอก application ID ให้ตรงกับใน build configuration เช่น com.example.shop ค่านี้ case-sensitive และต้องตรงกับในสโตร์

3. วาง fingerprint — ใส่ release fingerprint และ debug keystore fingerprint ด้วย เพื่อให้ build ของทีม QA verify ผ่านด้วย เครื่องมือจัดรูปแบบให้เป็นแบบคั่นจุดคู่ที่ Android ต้องการเอง

4. เปิด credential sharing (ถ้าต้องการ) — ถ้าเว็บกับแอปใช้ login ร่วมกัน ให้เปิด relation แบบ share_target เพื่อให้ Credential Manager มองทั้งคู่เป็น identity เดียวกัน

5. Copy JSON ไป host — เอาไฟล์ไปวางที่ https://yourdomain.com/.well-known/assetlinks.json ผ่าน HTTPS ไม่มี redirect แล้วลองแตะลิงก์บนเครื่องจริงดูว่าแอปเปิดแทน browser

Trust Chain เบื้องหลังไฟล์เดียว

Digital Asset Links คือโปรโตคอลที่ให้ origin หนึ่งประกาศความสัมพันธ์ที่เครื่องตรวจสอบได้กับอีกฝ่าย — ในที่นี้คือเว็บไซต์ประกาศว่าแอป Android ตัวใดพูดในนามของมันได้ ตัว verifier ของ Android จะดึง statement มาเช็กทั้งโครงสร้าง identity ของแพ็กเกจ และ identity ของลายเซ็น:

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example.shop",
    "sha256_cert_fingerprints": [
      "9F:2C:48:B3:6E:5A:D1:7F:0C:22:E9:84:1B:66:3D:AB:C4:07:52:E1"
    ]
  }
}]

relation ประกาศสิทธิ์ที่ให้ — common.handle_all_urls คือสิทธิ์ของ App Links, namespace แบบ android_app ระบุว่าเป้าหมายเป็นแอป Android, package_name ระบุ application ID เป๊ะๆ และ sha256_cert_fingerprints คือรายการ certificate ที่อนุญาตให้เซ็นแอปนี้ ตอนติดตั้ง Android จะเทียบ fingerprint ของ certificate ที่เซ็น APK จริงกับลิสต์นี้ — ตรงเท่านั้นถึงจะได้ deep link แบบ verified

fingerprint มาจากไหน — เป็นค่า SHA-256 ของ signing certificate: ใช้ keytool ดูได้ถ้าจัดการ keystore เอง หรือดูใน Play Console ถ้าใช้ Play App Signing นี่คือจุดพลาดที่พบบ่อยที่สุด — developer copy fingerprint ของ upload key ในเครื่องมาใส่ แต่ APK ที่ผู้ใช้ติดตั้งถูกเซ็นด้วย App signing key ที่ Play เป็นผู้ดูแล เลยเปิดลิงก์ใน browser ต่อไป

หลายแอป ทั้ง debug และ release — ไฟล์นี้เป็น array หลาย fingerprint ใต้ package เดียวจึงครอบคลุมทุก certificate ที่เซ็นแอปได้ และแยก statement หลายอันเพื่อให้แอปทั้งตระกูล claim โดเมนเดียวกันได้

share_target กับ credential — relation ตัวที่สอง delegate_permission/common.get_login_creds คือสิ่งที่ Credential Manager อ่าน: passkey ที่เซฟไว้บนเว็บจะถูกเสนอในแอป และกลับกันก็เช่นกัน

Debug: 404 กับ mismatch ต่างกันไง — เจอ 404 แปลว่า verifier ไปไม่ถึงไฟล์: path ผิด, ไม่มี route .well-known, host ที่ไม่มี HTTPS หรือมี redirect ส่วนไฟล์เข้าถึงได้แต่ verify ไม่ผ่านแปลว่า mismatch — fingerprint ผิด, package name ผิด หรือ JSON ไม่ valid ผล verification ถูก cache ไว้ Google Statement List tester จะบอกได้ว่าเช็กจุดไหนพัง

Use Case จริง

Deep Link สำหรับ E-commerce

แคมเปญกระจายลิงก์สินค้าไปทุกช่องทาง เมื่อ statement ผ่านการ verify ลิงก์ shop.example.com/p/12345 จะเปิดแอปตรงหน้าสินค้า รักษาตะกร้าและตัดขั้นตอนออกจาก funnel — โดย URL เดิมยังเปิดในเว็บได้ปกติสำหรับคนที่ไม่มีแอป

แชร์ credential กับ Password Manager

บริการที่มีทั้ง web console และแอป Android เปิด share_target ผู้ใช้เซฟ password หรือ passkey ครั้งเดียว Credential Manager ก็เสนอให้ทั้งสองฝั่ง — และโดเมนปลอมแอบอ้างสิทธิ์ไม่ได้ เพราะความเชื่อใจมาจาก fingerprint

Single Sign-On Flow

องค์กรที่มีชุดแอปหลายตัวใช้ความสัมพันธ์กับเว็บที่ verified เป็นจุดยึดของ identity: แอปพี่น้องจากโดเมนเดียวกันเข้าร่วม credential flow ร่วมกันโดยไม่ถามซ้ำ

QA release build

ทีมที่ใส่ทั้ง debug และ release fingerprint ตอนพัฒนา จะให้ QA ทดสอบ deep link บน debug build ก่อน release ทุกรอบ — จับ key ที่ถูก rotate หรือ package ที่ถูกเปลี่ยนชื่อได้ตั้งแต่เนิ่นๆ

Best Practices

• ใส่ทั้ง debug และ release fingerprint ตอนพัฒนา — statement เดียวครอบทั้งสอง keystore ทำให้ QA กับ production ผ่านด้วยไฟล์เดียวกัน
• Verify ด้วย Statement List tester — เครื่องมือ Digital Asset Links ของ Google จะ query URL จริงและชี้ว่าเช็กจุดไหนพัง ใช้หลังแก้ไฟล์ทุกครั้ง
• อย่า serve ไฟล์ผ่าน HTTP เด็ดขาด — ต้องเป็น HTTPS ที่ host ถูกต้อง path /.well-known/assetlinks.json เป๊ะ ไม่มี redirect และเป็น JSON ที่ valid พร้อม content type application/json
• Re-verify หลังเปลี่ยน signing — การ rotate key หรือเพิ่ม build flavor เปลี่ยน fingerprint เสมอ อัปเดต statement แล้วเผื่อเวลาให้ cache หมดอายุ
• ครอบคลุมทุก host ที่ใช้ลิงก์ — statement เป็นราย hostname example.com กับ www.example.com ต้องมีไฟล์ verified ของใครของมัน

เริ่มสร้าง App Links ที่ verify ผ่านวันนี้

ไฟล์เล็กๆ ไฟล์เดียวแบ่งระหว่าง "ลิงก์ที่เปิดแท็บ browser" กับ "ลิงก์ที่เปิดแอปของคุณ" Assetlinks JSON Generator สร้างไฟล์นี้ให้ถูกต้องในไม่ถึงนาที ทำงานใน browser ล้วนๆ generate statement ของคุณ เอาไปวางใน /.well-known/ แล้วให้ Android เริ่มเชื่อลิงก์ของคุณได้เลย

Related Tools You Might Like:

• Hash Type Identifier — ตรวจว่า hash string แบบไหน เช่น SHA-256
• JSON Formatter — validate และจัดรูป JSON ก่อนเอาขึ้นใช้งาน
• URL Parser — แยก deep link เป็น scheme, host และ path

ขอให้ทุกลิงก์ verify ผ่านหมดครับ!

คำถามที่พบบ่อย

ถ: ต้องวางไฟล์ assetlinks.json ไว้ที่ไหน?

ตอบ: ที่ path /.well-known/assetlinks.json เป๊ะๆ บนทุก hostname ที่ใช้ deep link ผ่าน HTTPS และไม่มี redirect ถ้าวางในโฟลเดอร์อื่น มี query string หรือให้เข้าผ่าน HTTP จะไม่ผ่าน verification

ถ: ถ้าใช้ Google Play App Signing ต้องใช้ SHA-256 ตัวไหน?

ตอบ: ใช้ fingerprint ของ App signing key certificate ที่ Play เป็นผู้ดูแล ดูได้ใน Play Console upload key ในเครื่องของคุณไม่ตรงกับ certificate ที่เซ็น APK ที่ผู้ใช้ติดตั้ง ลิงก์จึงไม่ verify ด้วยค่านั้น

ถ: SHA-256 fingerprint เป็นข้อมูลลับหรือเปล่า?

ตอบ: ไม่ใช่ เป็น public digest ที่ใครก็คำนวณจากแอปที่เผยแพร่แล้วได้ และมันทำหน้าที่เป็น trust anchor ได้เพราะเป็นค่าสาธารณะที่ตรวจสอบได้

ถ: Android ยังเปิดลิงก์ใน browser อยู่ ควรเช็กอะไรก่อน?

ตอบ: เช็กว่าไฟล์ตอบ 200 ผ่าน HTTPS ที่ path ถูกต้อง แล้วเทียบ package name กับ fingerprint กับ build ที่ติดตั้งจริง ผล verification ถูก cache ไว้ ให้ใช้ Statement List tester และเผื่อเวลาตรวจซ้ำ