การเพิ่มการยืนยันใบอนุญาตฝั่งไคลเอ็นต์ลงในแอปของคุณ

หลังจากที่คุณตั้งค่าบัญชีผู้เผยแพร่โฆษณาและสภาพแวดล้อมการพัฒนาแล้ว (ดูการตั้งค่าการให้สัญญาอนุญาต) คุณก็พร้อมที่จะเพิ่มการยืนยันใบอนุญาตลงใน แอปของคุณที่มีไลบรารีการยืนยันใบอนุญาต (LVL)

การเพิ่มการยืนยันใบอนุญาตด้วย LVL เกี่ยวข้องกับงานต่อไปนี้

1. การเพิ่มสิทธิ์การให้สัญญาอนุญาตไฟล์ Manifest ของแอปพลิเคชัน
2. การใช้นโยบาย - คุณจะเลือกการติดตั้งใช้งานแบบเต็มที่มีให้ใน LVL หรือสร้างเองก็ได้
3. กำลังติดตั้ง Obfuscator หาก Policy จะแคช ข้อมูลการตอบกลับเกี่ยวกับใบอนุญาต
4. การเพิ่มโค้ดเพื่อตรวจสอบใบอนุญาตในหน้าหลักของแอปพลิเคชัน กิจกรรม
5. การใช้ DeviceLimiter (ไม่บังคับและไม่แนะนำสำหรับ แอปพลิเคชันส่วนใหญ่)

ส่วนด้านล่างจะอธิบายงานดังกล่าว เมื่อคุณใช้ คุณควรสามารถคอมไพล์แอปพลิเคชันได้สําเร็จ และคุณ สามารถเริ่มต้นการทดสอบได้ ดังที่อธิบายไว้ใน การตั้งค่าการทดสอบ สภาพแวดล้อม

โปรดดูภาพรวมของไฟล์ต้นฉบับชุดเต็มที่รวมอยู่ใน LVL ได้ที่สรุปคลาสของ LVL และอินเทอร์เฟซ

การเพิ่มสิทธิ์การให้สัญญาอนุญาต

หากต้องการใช้แอปพลิเคชัน Google Play เพื่อส่งการตรวจสอบใบอนุญาตไปยัง แอปพลิเคชันของคุณต้องขอสิทธิ์ที่เหมาะสม com.android.vending.CHECK_LICENSE หากแอปพลิเคชันของคุณ ไม่ประกาศสิทธิ์การให้สัญญาอนุญาต แต่พยายามที่จะเริ่มการตรวจสอบใบอนุญาต LVL มีข้อยกเว้นด้านความปลอดภัย

หากต้องการขอสิทธิ์การอนุญาตให้ใช้สิทธิในแอปพลิเคชัน ให้ประกาศ <uses-permission> เป็นองค์ประกอบย่อยของ <manifest> ดังนี้

<uses-permission android:name="com.android.vending.CHECK_LICENSE" />

ตัวอย่างเช่น แอปพลิเคชัน LVL ตัวอย่างประกาศสิทธิ์โดยทำดังนี้

<?xml version="1.0" encoding="utf-8"?>

<manifest xmlns:android="http://schemas.android.com/apk/res/android" ...">
    <!-- Devices >= 3 have version of Google Play that supports licensing. -->
    <uses-sdk android:minSdkVersion="3" />
    <!-- Required permission to check licensing. -->
    <uses-permission android:name="com.android.vending.CHECK_LICENSE" />
    ...
</manifest>

หมายเหตุ: ปัจจุบันคุณไม่สามารถประกาศฟิลด์ CHECK_LICENSE ในไฟล์ Manifest ของโปรเจ็กต์ไลบรารี LVL เนื่องจากเครื่องมือ SDK จะไม่ผสานเครื่องมือนี้ เข้ากับไฟล์ Manifest ของ แอปพลิเคชัน แต่คุณต้องประกาศสิทธิ์ในทรัพยากร Dependency แต่ละรายการแทน ไฟล์ Manifest ของแอปพลิเคชัน

การใช้นโยบาย

บริการการให้สัญญาอนุญาตของ Google Play ไม่ได้เป็นตัวกำหนดว่า ผู้ใช้ที่มีใบอนุญาตหนึ่งๆ ควรได้รับสิทธิ์เข้าถึงแอปพลิเคชันของคุณ แต่จะส่งผลต่อการใช้งาน Policy ที่คุณมอบให้ ในแอปพลิเคชันของคุณ

นโยบายคืออินเทอร์เฟซที่ประกาศโดย LVL ซึ่งออกแบบมาเพื่อช่วย ตรรกะของแอปพลิเคชันในการอนุญาตหรือไม่อนุญาตการเข้าถึงของผู้ใช้ โดยพิจารณาจากผลลัพธ์ ของการตรวจสอบใบอนุญาต หากต้องการใช้ LVL แอปพลิเคชันของคุณต้องระบุ การใช้งาน Policy

อินเทอร์เฟซ Policy มีการประกาศ 2 เมธอด ได้แก่ allowAccess() และ processServerResponse() ซึ่งเรียกโดย LicenseChecker อินสแตนซ์เมื่อประมวลผลการตอบกลับจากเซิร์ฟเวอร์ใบอนุญาต และยังประกาศ enum ที่ชื่อ LicenseResponse ซึ่งระบุการตอบกลับของใบอนุญาต มูลค่าที่ส่งผ่านในการเรียกไปยัง processServerResponse()

• processServerResponse() ให้คุณประมวลผลคำตอบดิบล่วงหน้าได้ ข้อมูลที่ได้รับจากเซิร์ฟเวอร์การให้สัญญาอนุญาต ก่อนที่จะตัดสินใจว่าจะให้สิทธิ์หรือไม่ สิทธิ์การเข้าถึง

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

  เมื่อจัดเก็บข้อมูลการตอบกลับไว้ในเครื่อง Policy ต้องตรวจสอบว่าข้อมูลดังกล่าว มีการปรับให้ยากต่อการอ่าน (Obfuscate) (ดูการใช้ Obfuscator ที่ด้านล่าง)

• allowAccess() จะกำหนดว่าจะให้สิทธิ์เข้าถึงแก่ผู้ใช้หรือไม่ แอปพลิเคชันของคุณ โดยพิจารณาจากข้อมูลการตอบกลับเกี่ยวกับใบอนุญาตที่มีอยู่ (จาก เซิร์ฟเวอร์การให้สัญญาอนุญาตหรือจากแคช) หรือข้อมูลอื่นๆ เฉพาะแอปพลิเคชัน สำหรับ ตัวอย่างเช่น การใช้งาน allowAccess() อาจ เกณฑ์เพิ่มเติมของบัญชี เช่น การใช้งานหรือข้อมูลอื่นๆ ที่ดึงมาจาก เซิร์ฟเวอร์แบ็กเอนด์ ในทุกกรณี การใช้ allowAccess() ควรแสดงผล true หากผู้ใช้ได้รับอนุญาตให้ใช้ ตามที่เซิร์ฟเวอร์การให้สัญญาอนุญาตทราบ หรือหากมี ปัญหาของเครือข่ายหรือระบบที่ทำให้การตรวจสอบใบอนุญาตไม่เสร็จสมบูรณ์ ใน ในกรณีเช่นนี้ การติดตั้งของคุณจะสามารถรักษาจำนวนการลองตอบ อนุญาตให้เข้าถึงได้ชั่วคราวจนกว่าการตรวจสอบใบอนุญาตครั้งถัดไปจะเสร็จสมบูรณ์

เพื่อให้กระบวนการเพิ่มใบอนุญาตลงในแอปพลิเคชันและ ให้ภาพเกี่ยวกับวิธีออกแบบ Policy โดย LVL ประกอบด้วย การใช้งาน Policy ที่สมบูรณ์ 2 รายการที่คุณสามารถใช้ได้โดยไม่ต้องแก้ไข หรือ ให้ตรงตามความต้องการของคุณ

• ServerManagedPolicy ซึ่งเป็น Policy ที่ยืดหยุ่น ซึ่งใช้การตั้งค่าที่กำหนดโดยเซิร์ฟเวอร์และการตอบกลับที่แคชไว้เพื่อจัดการการเข้าถึง เงื่อนไขของเครือข่ายที่หลากหลาย และ
• StrictPolicy ซึ่งไม่แคชการตอบกลับใดๆ และอนุญาตการเข้าถึงก็ต่อเมื่อเซิร์ฟเวอร์แสดงผล คำตอบ

สำหรับแอปพลิเคชันส่วนใหญ่ การใช้ ServerManagedPolicy มีประสิทธิภาพสูง แนะนำ ServerManagedPolicy เป็นค่าเริ่มต้น LVL และผสานรวมกับ แอปพลิเคชัน LVL ตัวอย่าง

หลักเกณฑ์สำหรับนโยบายที่กำหนดเอง

ในการนำใบอนุญาตไปใช้ คุณสามารถใช้นโยบายฉบับใดนโยบายหนึ่งที่ครบถ้วนสมบูรณ์ ซึ่งมีอยู่ใน LVL (ServerManagedPolicy หรือ StrictPolicy) หรือคุณสามารถสร้าง นโยบายที่กำหนดเอง นโยบายที่กำหนดเองทุกประเภทมีการออกแบบที่สำคัญหลายอย่าง ที่จะต้องทำความเข้าใจและพิจารณาในการติดตั้งใช้งาน

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

หากคุณออกแบบนโยบายที่กำหนดเอง เราขอแนะนำ Policy ดังนี้

1. แคช (และสร้างความสับสนอย่างเหมาะสม) การตอบกลับใบอนุญาตที่สำเร็จล่าสุด ในพื้นที่เก็บข้อมูลถาวรในเครื่อง
2. ส่งคืนการตอบกลับที่แคชไว้สำหรับการตรวจสอบใบอนุญาตทั้งหมดตราบใดที่ฟังก์ชัน การตอบกลับที่แคชไว้นั้นถูกต้อง แทนที่จะส่งคำขอไปยังเซิร์ฟเวอร์การให้สัญญาอนุญาต การตั้งค่าความถูกต้องของการตอบกลับตาม VT ที่เซิร์ฟเวอร์ระบุ ขอแนะนำเป็นอย่างยิ่งให้เพิ่ม โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับการตอบกลับของเซิร์ฟเวอร์ เพื่อดูข้อมูลเพิ่มเติม
3. ใช้ระยะเวลาย้อนกลับแบบเอ็กซ์โปเนนเชียล หากลองส่งคำขออีกครั้งแล้วผลลัพธ์ที่ได้ โปรดทราบว่าไคลเอ็นต์ Google Play จะดำเนินการซ้ำโดยอัตโนมัติไม่สำเร็จ ดังนั้น ในกรณีส่วนใหญ่ Policyจึงไม่ต้องส่งคำขอซ้ำ
4. ระบุสำหรับ "ระยะเวลาผ่อนผัน" ที่ช่วยให้ผู้ใช้สามารถเข้าถึง ได้โดยจำกัดระยะเวลาหรือจำนวนครั้ง ขณะที่มีการตรวจสอบใบอนุญาต ลองอีกครั้งแล้ว ระยะเวลาผ่อนผันจะมีประโยชน์ต่อผู้ใช้โดยการอนุญาตให้เข้าถึงได้จนถึงวันที่ การตรวจสอบใบอนุญาตจะเสร็จสมบูรณ์และเป็นประโยชน์กับคุณโดยวาง จำกัดในการเข้าถึงแอปพลิเคชันของคุณอย่างเคร่งครัดเมื่อไม่มีการตอบกลับเกี่ยวกับใบอนุญาตที่ถูกต้อง พร้อมใช้งาน

การออกแบบ Policy ตามหลักเกณฑ์ที่ระบุไว้ข้างต้นเป็นเรื่องสำคัญ เพราะช่วยให้มั่นใจได้ว่าผู้ใช้จะได้รับประสบการณ์ที่ดีที่สุด ขณะเดียวกันก็มอบ ควบคุมแอปพลิเคชันได้อย่างมีประสิทธิภาพ แม้ในสภาวะที่ผิดพลาด

โปรดทราบว่า Policy สามารถใช้การตั้งค่าที่ได้รับจากเซิร์ฟเวอร์การให้สัญญาอนุญาตเพื่อ ช่วยจัดการความถูกต้องและการแคช ระยะเวลาผ่อนผันอีกครั้ง และอื่นๆ การดึงข้อมูล การตั้งค่าที่เซิร์ฟเวอร์มีให้นั้นไม่ซับซ้อนและมีประโยชน์มาก แนะนำ ดูการใช้งาน ServerManagedPolicy สำหรับตัวอย่างวิธีการ แยกและใช้ส่วนเพิ่มเติม สำหรับรายการการตั้งค่าเซิร์ฟเวอร์และข้อมูลเกี่ยวกับ วิธีใช้ โปรดดู การตอบสนองของเซิร์ฟเวอร์ พิเศษ

นโยบายที่จัดการโดยเซิร์ฟเวอร์

LVL มีการใช้ Policy อย่างเต็มรูปแบบและแนะนำ อินเทอร์เฟซที่เรียกว่า ServerManagedPolicy การติดตั้งใช้งานจะผสานรวมกับ คลาส LVL ทำหน้าที่เป็น Policy เริ่มต้นในคลัง

ServerManagedPolicy จะจัดการใบอนุญาตทั้งหมดและการลองอีกครั้ง คำตอบ แคชข้อมูลการตอบกลับทั้งหมดไว้ในเครื่อง SharedPreferences ปรับให้ยากต่อการอ่าน (Obfuscate) ด้วย การใช้งาน Obfuscator ของแอปพลิเคชัน การดำเนินการนี้จะทำให้การตอบกลับเกี่ยวกับใบอนุญาต ข้อมูลจะปลอดภัยและคงอยู่ตลอดรอบการทำงานของอุปกรณ์ นโยบายที่จัดการโดยเซิร์ฟเวอร์ นำเสนอการนำวิธีการติดต่อต่างๆ ที่เป็นรูปธรรมมาใช้งาน processServerResponse() และ allowAccess() และ ประกอบด้วยชุดวิธีการสนับสนุนและประเภทสำหรับการจัดการใบอนุญาต คำตอบ

ที่สำคัญ คุณลักษณะหลักของ ServerManagedPolicy คือการใช้ การตั้งค่าที่เซิร์ฟเวอร์จัดหาเป็นพื้นฐานในการจัดการการให้สัญญาอนุญาตใน ระยะเวลาการคืนเงินของแอปพลิเคชัน ตลอดจนผ่านเครือข่ายและสภาวะข้อผิดพลาดที่แตกต่างกัน เมื่อแอปพลิเคชันติดต่อเซิร์ฟเวอร์ Google Play เพื่อตรวจสอบใบอนุญาต เซิร์ฟเวอร์จะเพิ่มการตั้งค่าหลายรายการเป็นคู่คีย์-ค่าในฟิลด์เพิ่มเติมของ ประเภทการตอบกลับเกี่ยวกับใบอนุญาต ตัวอย่างเช่น เซิร์ฟเวอร์จะแสดงค่าที่แนะนำสำหรับแอตทริบิวต์ ระยะเวลาความถูกต้องของใบอนุญาตของแอปพลิเคชัน ระยะเวลาผ่อนผันอีกครั้ง และการอนุญาตสูงสุดที่ใช้ได้ นับรวมถึงจำนวนการลองอีกครั้ง ServerManagedPolicy จะแยกค่าจาก การตอบกลับใบอนุญาตในเมธอด processServerResponse() และการตรวจสอบ ในเมธอด allowAccess() สำหรับรายการของเซิร์ฟเวอร์ การตั้งค่าที่ใช้โดย ServerManagedPolicy โปรดดูการตอบกลับของเซิร์ฟเวอร์ พิเศษ

เพื่อความสะดวก ประสิทธิภาพที่ดีที่สุด และประโยชน์ของการใช้การตั้งค่าใบอนุญาต จากเซิร์ฟเวอร์ Google Playโดยใช้ ServerManagedPolicy เป็น ขอแนะนำให้ออกใบอนุญาต Policy

หากคุณกังวลเกี่ยวกับความปลอดภัยของข้อมูลการตอบกลับเกี่ยวกับใบอนุญาตที่ ซึ่งจัดเก็บไว้ในเครื่อง SharedPreferences คุณจะสามารถใช้การปรับให้ยากต่อการอ่าน (Obfuscation) ที่รัดกุมยิ่งขึ้น หรือออกแบบ Policy ที่เข้มงวดขึ้นซึ่งไม่จัดเก็บข้อมูลใบอนุญาต ระดับ LVL มีตัวอย่างของ Policy ดังกล่าว โปรดดูข้อมูลเพิ่มเติมที่ StrictPolicy

หากต้องการใช้ ServerManagedPolicy เพียงแค่นำเข้านโยบายดังกล่าวไปยังกิจกรรมของคุณ แล้วสร้าง และส่งการอ้างอิงไปยังอินสแตนซ์เมื่อสร้าง LicenseChecker โปรดดู Instantiate LicenseChecker และ LicenseCheckerCallback เพื่อขอข้อมูลเพิ่มเติม

นโยบายที่เข้มงวด

LVL มีตัวเลือกการใช้งานอินเทอร์เฟซ Policy อย่างเต็มรูปแบบ ที่เรียกว่า StrictPolicy การใช้ StrictPolicy มีข้อจำกัดมากกว่า นโยบายที่นอกเหนือจาก ServerManagedPolicy ในแง่ที่ไม่อนุญาตให้ผู้ใช้เข้าถึง แอปพลิเคชัน เว้นแต่จะได้รับการตอบกลับเกี่ยวกับใบอนุญาตจากเซิร์ฟเวอร์ที่ เวลาของการเข้าถึงที่บ่งชี้ว่าผู้ใช้มีสัญญาอนุญาต

ฟีเจอร์หลักของ StrictPolicy คือระบบจะไม่เก็บข้อมูลใดๆ ข้อมูลการตอบกลับเกี่ยวกับใบอนุญาตในเครื่องใน Store ถาวร เพราะไม่มีการจัดเก็บข้อมูล ไม่สามารถติดตามคำขอลองอีกครั้ง และการตอบกลับที่แคชไว้จะใช้เพื่อดำเนินการให้เสร็จสิ้นไม่ได้ การตรวจสอบใบอนุญาต Policy อนุญาตให้เข้าถึงได้ในกรณีต่อไปนี้เท่านั้น

• การตอบกลับเกี่ยวกับใบอนุญาตจะส่งมาจากเซิร์ฟเวอร์การให้สัญญาอนุญาต และ
• การตอบกลับเกี่ยวกับใบอนุญาตระบุว่าผู้ใช้ได้รับอนุญาตให้เข้าถึง แอปพลิเคชัน

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

ในขณะเดียวกัน Policy นี้ก็มีความท้าทายสำหรับผู้ใช้ทั่วไป เนื่องจาก หมายความว่าผู้ใช้จะไม่สามารถเข้าถึงแอปพลิเคชันได้เมื่อไม่มีเครือข่าย มีการเชื่อมต่อ (เครือข่ายมือถือหรือ Wi-Fi) ที่ใช้งานได้ อีกผลกระทบข้างเคียงคือ จะส่งคำขอการตรวจสอบใบอนุญาตเพิ่มเติมไปยังเซิร์ฟเวอร์ เนื่องจาก ตอบกลับที่แคชไว้ไม่ได้

โดยรวมแล้ว นโยบายนี้ส่งผลต่อความสะดวกสบายของผู้ใช้ในระดับหนึ่ง เพื่อความปลอดภัยและควบคุมการเข้าถึง โปรดพิจารณาข้อดีข้อเสียอย่างรอบคอบ ก่อนใช้ Policy นี้

หากต้องการใช้ StrictPolicy เพียงนำเข้านโยบายไปยังกิจกรรม สร้างอินสแตนซ์ และส่งการอ้างอิงไปยังไฟล์ดังกล่าวเมื่อสร้าง LicenseChecker โปรดดู Instantiate LicenseChecker และ LicenseCheckerCallback เพื่อดูข้อมูลเพิ่มเติม

การใช้งาน Policy โดยทั่วไปจะต้องบันทึกข้อมูลการตอบกลับเกี่ยวกับใบอนุญาตสำหรับ ไปยังร้านค้าถาวร เพื่อให้สามารถเข้าถึงได้ คำขอแอปพลิเคชันและรอบพลังงานของอุปกรณ์ ตัวอย่างเช่น Policy จะ จะคงการประทับเวลาของการตรวจสอบใบอนุญาตที่สำเร็จครั้งล่าสุด จำนวนครั้งของการลองใหม่ ระยะเวลาที่ใช้งานได้ของใบอนุญาต และข้อมูลที่คล้ายกันใน Store ถาวร แทนที่จะรีเซ็ตค่าทุกครั้งที่เปิดใช้งานแอปพลิเคชัน ค่าเริ่มต้น Policy รวมอยู่ใน LVL, ServerManagedPolicy, จัดเก็บการตอบกลับใบอนุญาต ในอินสแตนซ์ SharedPreferences เพื่อให้มั่นใจได้ว่า ข้อมูลจะคงอยู่ถาวร

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

LVL ช่วยแอปพลิเคชันในการจัดเก็บข้อมูลการตอบกลับเกี่ยวกับใบอนุญาตใน มีความปลอดภัยและยั่งยืน ประเภทแรกคือ Obfuscator ที่ช่วยให้แอปพลิเคชันของคุณสามารถจัดหาอัลกอริทึมการปรับให้ยากต่อการอ่าน (Obfuscation) สำหรับข้อมูลที่จัดเก็บไว้ เมื่อต่อยอดแล้ว LVL ก็มีคลาสตัวช่วย PreferenceObfuscator ซึ่งจะจัดการงานส่วนใหญ่เกี่ยวกับการเรียกฟังก์ชัน Obfuscator ของแอปพลิเคชัน รวมถึงการอ่านและการเขียนข้อมูลที่ปรับให้ยากต่อการอ่าน (Obfuscate) ใน SharedPreferences

LVL จะแสดงการติดตั้งใช้งาน Obfuscator อย่างเต็มรูปแบบที่ชื่อว่า AESObfuscator ที่ใช้การเข้ารหัส AES เพื่อสร้างความสับสนเกี่ยวกับข้อมูล คุณสามารถ ใช้ AESObfuscator ในแอปพลิเคชันของคุณโดยไม่ต้องแก้ไข หรือ ปรับให้เหมาะกับความต้องการของคุณได้ หากคุณใช้ Policy (เช่น ServerManagedPolicy) ที่แคชข้อมูลการตอบกลับใบอนุญาตโดยใช้ AESObfuscator พื้นฐานสำหรับการติดตั้งใช้งาน Obfuscator ดูข้อมูลเพิ่มเติมได้ในส่วนถัดไป

รหัส AESObfuscator

LVL มีการใช้ Obfuscator อย่างเต็มรูปแบบและแนะนำ อินเทอร์เฟซที่เรียกว่า AESObfuscator การติดตั้งใช้งานจะผสานรวมกับ LVL ตัวอย่างแอปพลิเคชันและทำหน้าที่เป็น Obfuscator เริ่มต้นในคลัง

AESObfuscator สร้างความสับสนให้กับข้อมูลอย่างปลอดภัยโดยใช้ AES เพื่อ เข้ารหัสและถอดรหัสข้อมูลขณะเขียนหรืออ่านจากพื้นที่เก็บข้อมูล Obfuscator ตั้งต้นการเข้ารหัสโดยใช้ฟิลด์ข้อมูล 3 ฟิลด์ที่ระบุ ตามแอปพลิเคชัน

1. Salt - อาร์เรย์ของไบต์แบบสุ่มที่จะใช้ในการสร้างความสับสน (ยกเลิก)
2. สตริงตัวระบุแอปพลิเคชัน ซึ่งโดยปกติแล้วจะเป็นชื่อแพ็กเกจของแอปพลิเคชัน
3. สตริงตัวระบุอุปกรณ์ ซึ่งได้มาจากแหล่งที่มาเฉพาะอุปกรณ์หลายรายการ ให้มากที่สุด เพื่อทำให้โมเดลไม่เหมือนใคร

หากต้องการใช้ AESObfuscator ให้นําเข้าไปยังกิจกรรมของคุณก่อน ประกาศความเป็นส่วนตัว อาร์เรย์สุดท้ายแบบคงที่เพื่อเก็บไบต์ Salt และเริ่มต้นเป็น 20 แบบสุ่ม ไบต์ที่สร้างขึ้น

// Generate 20 random bytes, and put them here.
private val SALT = byteArrayOf(
        -46, 65, 30, -128, -103, -57, 74, -64, 51, 88,
        -95, -45, 77, -117, -36, -113, -11, 32, -64, 89
)

...
    // Generate 20 random bytes, and put them here.
    private static final byte[] SALT = new byte[] {
     -46, 65, 30, -128, -103, -57, 74, -64, 51, 88, -95,
     -45, 77, -117, -36, -113, -11, 32, -64, 89
     };
    ...

ถัดไป ให้ประกาศตัวแปรเพื่อเก็บตัวระบุอุปกรณ์และสร้างค่าสำหรับ ตามความจำเป็น ตัวอย่างเช่น ตัวอย่างแอปพลิเคชันที่รวมอยู่ใน LVL จะค้นหาการตั้งค่าระบบสำหรับ android.Settings.Secure.ANDROID_ID ซึ่งจะไม่ซ้ำกันในอุปกรณ์แต่ละเครื่อง

โปรดทราบว่าแอปพลิเคชันอาจต้องทำดังนี้ ทั้งนี้ขึ้นอยู่กับ API ที่คุณใช้ ขอสิทธิ์เพิ่มเติมเพื่อให้ได้รับข้อมูลเฉพาะอุปกรณ์ เช่น หากต้องการค้นหา TelephonyManager เพื่อรับ IMEI ของอุปกรณ์หรือข้อมูลที่เกี่ยวข้อง แอปพลิเคชันจะต้องส่งคำขอ android.permission.READ_PHONE_STATE ในไฟล์ Manifest

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

สุดท้าย สร้างอินสแตนซ์ของ AESObfuscator เพื่อส่งเกลือ ตัวระบุแอปพลิเคชัน และตัวระบุอุปกรณ์ คุณสร้างอินสแตนซ์ได้ โดยตรง ขณะสร้าง Policy และ LicenseChecker เช่น

    ...
    // Construct the LicenseChecker with a Policy.
    private val checker = LicenseChecker(
            this,
            ServerManagedPolicy(this, AESObfuscator(SALT, packageName, deviceId)),
            BASE64_PUBLIC_KEY
    )
    ...

    ...
    // Construct the LicenseChecker with a Policy.
    checker = new LicenseChecker(
        this, new ServerManagedPolicy(this,
            new AESObfuscator(SALT, getPackageName(), deviceId)),
        BASE64_PUBLIC_KEY // Your public licensing key.
        );
    ...

สำหรับตัวอย่างที่สมบูรณ์ โปรดดู MainActivity ในแอปพลิเคชันตัวอย่าง LVL

การตรวจสอบใบอนุญาตจากกิจกรรม

เมื่อคุณใช้ Policy สำหรับจัดการการเข้าถึงแอปพลิเคชันแล้ว ขั้นตอนถัดไปคือการเพิ่มการตรวจสอบใบอนุญาตลงในแอปพลิเคชันของคุณ ซึ่งจะเริ่มต้นการค้นหา ไปยังเซิร์ฟเวอร์การให้สัญญาอนุญาตหากจำเป็น และจัดการการเข้าถึงแอปพลิเคชันตาม การตอบกลับเกี่ยวกับใบอนุญาต การดำเนินการทั้งหมดในการเพิ่มการตรวจสอบและการจัดการใบอนุญาต การตอบกลับจะเกิดขึ้นในไฟล์ต้นฉบับ Activity หลักของคุณ

หากต้องการเพิ่มการตรวจสอบใบอนุญาตและจัดการการตอบกลับ คุณต้องทำดังนี้

1. เพิ่มการนำเข้า
2. ใช้ LicenseCheckerCallback เป็นคลาสส่วนตัวภายใน
3. สร้างเครื่องจัดการสำหรับการโพสต์จาก LicenseCheckerCallback ไปยังชุดข้อความ UI
4. Instantiate LicenseChecker และ LicenseCheckerCallback
5. เรียกใช้ checkAccess() เพื่อเริ่มต้นการตรวจสอบใบอนุญาต
6. ฝังคีย์สาธารณะเพื่อออกใบอนุญาต
7. เรียกใช้เมธอด onDestroy() ของ LicenseChecker เพื่อปิดการเชื่อมต่อ IPC

ส่วนด้านล่างจะอธิบายงานดังกล่าว

ภาพรวมของการตรวจสอบและการตอบกลับใบอนุญาต

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

การตรวจสอบใบอนุญาตประกอบด้วยการดำเนินการหลัก 2 อย่าง ดังนี้

• การเรียกเมธอดเพื่อเริ่มต้นการตรวจสอบใบอนุญาต ใน LVL นี่คือ การเรียกเมธอด checkAccess() ของออบเจ็กต์ LicenseChecker ที่ ที่คุณสร้างขึ้น
• Callback ที่ส่งคืนผลการตรวจสอบใบอนุญาต ใน LVL นี่เป็น อินเทอร์เฟซ LicenseCheckerCallback ที่คุณใช้ อินเทอร์เฟซมีการประกาศ 2 วิธี ได้แก่ allow() และ dontAllow() ซึ่งเรียกใช้โดยไลบรารีตาม ของการตรวจสอบใบอนุญาต คุณนำ 2 วิธีนี้ไปใช้ด้วยตรรกะแบบใดก็ได้ เพื่ออนุญาตหรือไม่อนุญาตให้ผู้ใช้เข้าถึงแอปพลิเคชันของคุณ โปรดทราบว่า วิธีการเหล่านี้ไม่ได้เป็นตัวกำหนดว่าจะอนุญาตให้เข้าถึงหรือไม่ การพิจารณาเป็นความรับผิดชอบของการติดตั้งใช้งาน Policy แต่เป็น เพียงแสดงลักษณะการทำงานของแอปพลิเคชันสำหรับวิธีอนุญาตและ ไม่อนุญาตให้เข้าถึง (และจัดการกับข้อผิดพลาดของแอปพลิเคชัน)

  เมธอด allow() และ dontAllow() ให้ "เหตุผล" สำหรับคำตอบ ซึ่งอาจเป็นค่า Policy, LICENSED, NOT_LICENSED หรือ RETRY โดยเฉพาะอย่างยิ่ง คุณควรจัดการกรณีที่ เมธอดจะได้รับการตอบกลับ RETRY สำหรับ dontAllow() และให้ "ลองอีกครั้ง" ซึ่งอาจเกิดขึ้นเนื่องจากบริการไม่พร้อมใช้งานในระหว่าง อีกครั้ง

รูปที่ 1 ภาพรวมของ การโต้ตอบทั่วไปในการตรวจสอบใบอนุญาต

แผนภาพด้านบนแสดงวิธีการตรวจสอบใบอนุญาตทั่วไป

1. โค้ดในกิจกรรมหลักของแอปพลิเคชันจะสร้างอินสแตนซ์ LicenseCheckerCallback และออบเจ็กต์ LicenseChecker รายการ เมื่อสร้าง LicenseChecker รหัสจะส่งผ่าน Context การติดตั้งใช้งาน Policy ที่จะใช้ และ คีย์สาธารณะของบัญชีผู้เผยแพร่โฆษณาสำหรับการอนุญาตให้ใช้สิทธิเป็นพารามิเตอร์
2. จากนั้นโค้ดจะเรียกเมธอด checkAccess() ใน LicenseChecker ออบเจ็กต์ การใช้งานเมธอดจะเรียก Policy เพื่อระบุ มีการแคชการตอบกลับใบอนุญาตที่ถูกต้องไว้ในเครื่องหรือไม่ SharedPreferences
   • หากเป็นเช่นนั้น checkAccess() จะเรียกใช้การใช้งาน allow()
   • มิฉะนั้น LicenseChecker จะเริ่มต้นคำขอตรวจสอบใบอนุญาตที่ส่งไป ไปยังเซิร์ฟเวอร์การให้สัญญาอนุญาต

   หมายเหตุ: เซิร์ฟเวอร์การให้สัญญาอนุญาตจะส่งคืนเสมอ LICENSEDเมื่อคุณตรวจสอบใบอนุญาตของแอปพลิเคชันฉบับร่าง

3. เมื่อได้รับการตอบกลับ LicenseChecker จะสร้าง LicenseValidator ที่ ตรวจสอบข้อมูลใบอนุญาตที่ลงนามและแยกช่องของการตอบกลับแล้วออก ส่งไปยัง Policy เพื่อรับการประเมินเพิ่มเติม
   • หากใบอนุญาตถูกต้อง Policy จะแคชการตอบกลับใน SharedPreferences และแจ้งโปรแกรมตรวจสอบ ซึ่งจะเรียกฟังก์ชัน allow() ในออบเจ็กต์ LicenseCheckerCallback
   • หากใบอนุญาตไม่ถูกต้อง Policy จะแจ้งโปรแกรมตรวจสอบ ซึ่งจะเรียกใช้ เมธอด dontAllow() ใน LicenseCheckerCallback
4. ในกรณีข้อผิดพลาดในเครื่องหรือเซิร์ฟเวอร์ที่กู้คืนได้ เช่น เมื่อเครือข่าย ไม่มีสิทธิ์ส่งคำขอ LicenseChecker ส่งการตอบกลับ RETRY ไปยัง เมธอด processServerResponse() ของออบเจ็กต์ Policy

   นอกจากนี้ ทั้งเมธอด Callback allow() และ dontAllow() จะได้รับเมธอด อาร์กิวเมนต์ reason เหตุผลของเมธอด allow() ซึ่งมักจะเป็น Policy.LICENSED หรือ Policy.RETRY และเหตุผลของ dontAllow() มักจะเป็น Policy.NOT_LICENSED หรือ Policy.RETRY ค่าการตอบกลับเหล่านี้มีประโยชน์เพื่อให้คุณแสดง การตอบสนองที่เหมาะสมสำหรับผู้ใช้ เช่น ด้วยการ "ลองอีกครั้ง" ปุ่มเมื่อ dontAllow() ตอบกลับด้วย Policy.RETRY ซึ่งอาจเป็นเพราะบริการมีการ ไม่พร้อมใช้งาน

5. ในกรณีที่แอปพลิเคชันเกิดข้อผิดพลาด เช่น เมื่อแอปพลิเคชันพยายามดำเนินการ ตรวจสอบใบอนุญาตของชื่อแพ็กเกจที่ไม่ถูกต้อง LicenseChecker ผ่านข้อผิดพลาด การตอบกลับ applicationError() ของ LicenseCheckerCallback

โปรดทราบว่านอกจากการเริ่มตรวจสอบใบอนุญาตและจัดการ ซึ่งอธิบายไว้ในส่วนด้านล่างนี้ ใบสมัครของคุณก็ต้องมี เพื่อระบุการใช้นโยบาย และหากPolicy จัดเก็บข้อมูลการตอบกลับ (เช่น ServerManagedPolicy) การใช้งาน Obfuscator

เพิ่มการนำเข้า

ขั้นแรก ให้เปิดไฟล์คลาสของกิจกรรมหลักของแอปพลิเคชัน แล้วนำเข้า LicenseChecker และ LicenseCheckerCallback จากแพ็กเกจ LVL

import com.google.android.vending.licensing.LicenseChecker
import com.google.android.vending.licensing.LicenseCheckerCallback

import com.google.android.vending.licensing.LicenseChecker;
import com.google.android.vending.licensing.LicenseCheckerCallback;

หากคุณใช้การติดตั้งใช้งาน Policy เริ่มต้นที่มาพร้อมกับ LVL ServerManagedPolicy ให้นำเข้าพร้อมกับ AESObfuscator หากคุณ โดยใช้ Policy หรือ Obfuscator ที่กำหนดเอง ให้นำเข้ารายการเหล่านี้แทน

import com.google.android.vending.licensing.ServerManagedPolicy
import com.google.android.vending.licensing.AESObfuscator

import com.google.android.vending.licensing.ServerManagedPolicy;
import com.google.android.vending.licensing.AESObfuscator;

ใช้ LicenseCheckerCallback เป็นคลาสส่วนตัวภายใน

LicenseCheckerCallback คืออินเทอร์เฟซจาก LVL สำหรับการจัดการ ของการตรวจสอบใบอนุญาต หากต้องการสนับสนุนการให้สัญญาอนุญาตโดยใช้ LVL คุณต้อง ใช้ LicenseCheckerCallback และ เพื่ออนุญาตหรือไม่อนุญาตให้เข้าถึงแอปพลิเคชัน

ผลการตรวจสอบใบอนุญาตจะเป็นการเรียกไปยัง LicenseCheckerCallback วิธี ซึ่งสร้างขึ้นตามการตรวจสอบความถูกต้องของคำตอบ เพย์โหลด โค้ดตอบกลับของเซิร์ฟเวอร์ และการประมวลผลเพิ่มเติมที่มีให้ โดย Policy แอปพลิเคชันของคุณนำวิธีการไปใช้ได้ตามต้องการ ใน โดยทั่วไปแล้ว ควรทำให้วิธีการนั้นเรียบง่าย โดยจำกัดไว้แค่การจัดการ UI สถานะและการเข้าถึงแอปพลิเคชัน หากต้องการเพิ่มการดำเนินการอื่นๆ เกี่ยวกับใบอนุญาต การตอบกลับ เช่น ด้วยการติดต่อเซิร์ฟเวอร์แบ็กเอนด์ หรือใช้ข้อจำกัดที่กำหนดเอง คุณควรพิจารณารวมโค้ดนั้นไว้ใน Policy แทน ไว้ในเมธอด LicenseCheckerCallback

ในกรณีส่วนใหญ่ คุณควรประกาศการติดตั้งใช้งาน LicenseCheckerCallback เป็นชั้นเรียนส่วนตัวภายในชั้นเรียนหลักของแอปพลิเคชัน ชั้นเรียนกิจกรรม

ใช้เมธอด allow() และ dontAllow() เป็น ที่จำเป็น ในการเริ่มต้น คุณสามารถใช้ลักษณะการจัดการผลลัพธ์อย่างง่ายใน เช่น การแสดงผลใบอนุญาตในกล่องโต้ตอบ ซึ่งจะช่วยให้คุณ แอปพลิเคชันของคุณจะทำงานได้เร็วขึ้นและช่วยแก้ไขข้อบกพร่องได้ ภายหลัง หลังจากที่คุณ กำหนดการทำงานที่แน่นอนที่คุณต้องการ คุณสามารถเพิ่มการจัดการที่ซับซ้อนมากขึ้นได้

คำแนะนำบางอย่างสำหรับการจัดการคำตอบที่ไม่ได้รับอนุญาตใน dontAllow() ประกอบด้วย:

• แสดงข้อความ "ลองอีกครั้ง" กล่องโต้ตอบให้กับผู้ใช้ รวมถึงปุ่มเพื่อเริ่มต้น การตรวจสอบใบอนุญาตใหม่ว่า reason ที่ระบุคือ Policy.RETRY หรือไม่
• แสดง "ซื้อแอปพลิเคชันนี้" กล่องโต้ตอบ ซึ่งรวมถึงปุ่ม จะเชื่อมโยงผู้ใช้กับหน้ารายละเอียดของแอปพลิเคชันบน Google Play ซึ่ง สามารถซื้อแอปพลิเคชันได้ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีตั้งค่า โปรดดูลิงก์ไปยังผลิตภัณฑ์ของคุณ
• แสดงการแจ้งเตือนของข้อความโทสต์ที่ระบุว่าฟีเจอร์ของ ถูกจำกัดเนื่องจากไม่มีใบอนุญาต

ตัวอย่างด้านล่างแสดงวิธีการนำแอปพลิเคชัน LVL ตัวอย่างไปใช้ LicenseCheckerCallback พร้อมกับเมธอดที่แสดงผลลัพธ์การตรวจสอบใบอนุญาตใน กล่องโต้ตอบ

private inner class MyLicenseCheckerCallback : LicenseCheckerCallback {

    override fun allow(reason: Int) {
        if (isFinishing) {
            // Don't update UI if Activity is finishing.
            return
        }
        // Should allow user access.
        displayResult(getString(R.string.allow))
    }

    override fun dontAllow(reason: Int) {
        if (isFinishing) {
            // Don't update UI if Activity is finishing.
            return
        }
        displayResult(getString(R.string.dont_allow))

        if (reason == Policy.RETRY) {
            // If the reason received from the policy is RETRY, it was probably
            // due to a loss of connection with the service, so we should give the
            // user a chance to retry. So show a dialog to retry.
            showDialog(DIALOG_RETRY)
        } else {
            // Otherwise, the user isn't licensed to use this app.
            // Your response should always inform the user that the application
            // isn't licensed, but your behavior at that point can vary. You might
            // provide the user a limited access version of your app or you can
            // take them to Google Play to purchase the app.
            showDialog(DIALOG_GOTOMARKET)
        }
    }
}

private class MyLicenseCheckerCallback implements LicenseCheckerCallback {
    public void allow(int reason) {
        if (isFinishing()) {
            // Don't update UI if Activity is finishing.
            return;
        }
        // Should allow user access.
        displayResult(getString(R.string.allow));
    }

    public void dontAllow(int reason) {
        if (isFinishing()) {
            // Don't update UI if Activity is finishing.
            return;
        }
        displayResult(getString(R.string.dont_allow));

        if (reason == Policy.RETRY) {
            // If the reason received from the policy is RETRY, it was probably
            // due to a loss of connection with the service, so we should give the
            // user a chance to retry. So show a dialog to retry.
            showDialog(DIALOG_RETRY);
        } else {
            // Otherwise, the user isn't licensed to use this app.
            // Your response should always inform the user that the application
            // isn't licensed, but your behavior at that point can vary. You might
            // provide the user a limited access version of your app or you can
            // take them to Google Play to purchase the app.
            showDialog(DIALOG_GOTOMARKET);
        }
    }
}

นอกจากนี้ คุณควรใช้ applicationError() ซึ่ง LVL เรียกใช้เพื่อทำให้แอปพลิเคชันของคุณจัดการกับข้อผิดพลาดที่ไม่ได้ สามารถลองอีกครั้งได้ สำหรับรายการข้อผิดพลาดดังกล่าว โปรดดูที่ เซิร์ฟเวอร์ โค้ดตอบกลับในข้อมูลอ้างอิงการอนุญาตให้ใช้สิทธิ คุณติดตั้งใช้งานได้ วิธีการใดๆ ที่จำเป็น ในกรณีส่วนใหญ่ พารามิเตอร์ ควรบันทึกรหัสข้อผิดพลาดและเรียก dontAllow()

สร้างเครื่องจัดการสำหรับการโพสต์จาก LicenseCheckerCallback ไปยังเธรด UI

ในระหว่างการตรวจสอบใบอนุญาต LVL จะส่งผ่านคำขอไปยัง Google Play ซึ่งจะจัดการการสื่อสารกับเซิร์ฟเวอร์การให้สัญญาอนุญาต ระดับ LVL ส่งคำขอผ่าน IPC แบบไม่พร้อมกัน (โดยใช้ Binder) ดังนั้น การประมวลผลและการสื่อสารเครือข่ายที่แท้จริงจะไม่เกิดขึ้นในชุดข้อความ ที่จัดการโดยแอปพลิเคชันของคุณ ในทำนองเดียวกัน เมื่อแอปพลิเคชัน Google Play จะได้รับผลลัพธ์ ก็จะเรียกใช้เมธอด Callback ผ่าน IPC ซึ่งในทางกลับกัน ดำเนินการใน Thread Pool ของ IPC ในกระบวนการของแอปพลิเคชัน

คลาส LicenseChecker จะจัดการการสื่อสาร IPC ของแอปพลิเคชันของคุณกับ แอปพลิเคชัน Google Play ซึ่งรวมถึงการโทรที่ส่งคำขอและ Callback ที่รับการตอบกลับ LicenseChecker ติดตามใบอนุญาตแบบเปิดด้วย และจัดการการหมดเวลาได้

เพื่อให้จัดการระยะหมดเวลาได้อย่างเหมาะสมและประมวลผลคำตอบที่เข้ามาใหม่ได้ด้วย โดย LicenseChecker สร้าง เทรดเบื้องหลังขณะสร้างอินสแตนซ์ ในชุดข้อความ ระบบจะดำเนินการประมวลผลทั้งหมด ผลการตรวจสอบใบอนุญาต ไม่ว่าผลลัพธ์จะเป็นการตอบกลับที่ได้รับจากเซิร์ฟเวอร์ หรือข้อผิดพลาดการหมดเวลา เมื่อสิ้นสุดการประมวลผล LVL จะเรียก LicenseCheckerCallback เมธอดจากชุดข้อความเบื้องหลัง

สำหรับแอปพลิเคชันของคุณ หมายความดังต่อไปนี้

1. ในหลายกรณี ระบบจะเรียกใช้เมธอด LicenseCheckerCallback จาก เทรดพื้นหลัง
2. วิธีการเหล่านี้จะไม่สามารถอัปเดตสถานะหรือเรียกใช้การประมวลผลใน เทรด UI เว้นแต่คุณจะสร้างตัวแฮนเดิลในเทรด UI และให้ Callback ของคุณ โพสต์ไปยังเครื่องจัดการ

หากคุณต้องการให้เมธอด LicenseCheckerCallback ของคุณอัปเดตชุดข้อความ UI สร้างอินสแตนซ์ Handler ใน "กิจกรรมหลัก" onCreate() วิธี ดังที่แสดงด้านล่าง ในตัวอย่างนี้ แอปพลิเคชัน LVL ตัวอย่าง LicenseCheckerCallback เมธอด (ดูด้านบน) เรียก displayResult() ไปยัง อัปเดตชุดข้อความ UI ผ่านเครื่องจัดการ post() วิธี

    private lateinit var handler: Handler

    override fun onCreate(savedInstanceState: Bundle?) {
        ...
        handler = Handler()
    }

    private Handler handler;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        ...
        handler = new Handler();
    }

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

private fun displayResult(result: String) {
    handler.post {
        statusText.text = result
        setProgressBarIndeterminateVisibility(false)
        checkLicenseButton.isEnabled = true
    }
}

private void displayResult(final String result) {
        handler.post(new Runnable() {
            public void run() {
                statusText.setText(result);
                setProgressBarIndeterminateVisibility(false);
                checkLicenseButton.setEnabled(true);
            }
        });
    }

สร้างอินสแตนซ์ LicenseChecker และ LicenseChecker Callback

ในคอลัมน์ "กิจกรรมหลัก" onCreate() วิธี สร้างอินสแตนซ์ส่วนตัวของ LicenseCheckerCallback และ LicenseChecker คุณต้อง สร้างอินสแตนซ์ LicenseCheckerCallback ก่อน เพราะคุณต้องส่งข้อมูลอ้างอิง ลงในอินสแตนซ์นั้นเมื่อคุณเรียกตัวสร้างสำหรับ LicenseChecker

เมื่อสร้างอินสแตนซ์ LicenseChecker คุณจะต้องส่งผ่านในพารามิเตอร์เหล่านี้

• แอปพลิเคชัน Context
• ข้อมูลอ้างอิงเกี่ยวกับการใช้งาน Policy ที่ใช้สำหรับการตรวจสอบใบอนุญาต ใน ในกรณีส่วนใหญ่ คุณจะใช้การติดตั้งใช้งาน Policy เริ่มต้นที่ LVL กำหนด ServerManagedPolicy
• ตัวแปรสตริงที่เก็บคีย์สาธารณะของบัญชีผู้เผยแพร่โฆษณาสำหรับ การอนุญาตให้ใช้สิทธิ

หากใช้ ServerManagedPolicy คุณไม่จำเป็นต้องเข้าถึงชั้นเรียน โดยตรง เพื่อให้คุณสามารถสร้างอินสแตนซ์ใน LicenseChecker ตัวสร้าง ดังที่แสดงในตัวอย่างด้านล่าง โปรดทราบว่าคุณต้องส่งการอ้างอิงไปยัง อินสแตนซ์ Obfuscator เมื่อคุณสร้าง ServerManagedPolicy

ตัวอย่างด้านล่างแสดงการสร้าง LicenseChecker และ LicenseCheckerCallback จากวิธีการ onCreate() ของกิจกรรม

class MainActivity : AppCompatActivity() {
    ...
    private lateinit var licenseCheckerCallback: LicenseCheckerCallback
    private lateinit var checker: LicenseChecker

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        ...
        // Construct the LicenseCheckerCallback. The library calls this when done.
        licenseCheckerCallback = MyLicenseCheckerCallback()

        // Construct the LicenseChecker with a Policy.
        checker = LicenseChecker(
                this,
                ServerManagedPolicy(this, AESObfuscator(SALT, packageName, deviceId)),
                BASE64_PUBLIC_KEY // Your public licensing key.
        )
        ...
    }
}

public class MainActivity extends Activity {
    ...
    private LicenseCheckerCallback licenseCheckerCallback;
    private LicenseChecker checker;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        ...
        // Construct the LicenseCheckerCallback. The library calls this when done.
        licenseCheckerCallback = new MyLicenseCheckerCallback();

        // Construct the LicenseChecker with a Policy.
        checker = new LicenseChecker(
            this, new ServerManagedPolicy(this,
                new AESObfuscator(SALT, getPackageName(), deviceId)),
            BASE64_PUBLIC_KEY // Your public licensing key.
            );
        ...
    }
}

โปรดทราบว่า LicenseChecker จะเรียกใช้เมธอด LicenseCheckerCallback จาก UI เทรดเท่านั้นเมื่อมีการแคชการตอบกลับเกี่ยวกับใบอนุญาตที่ถูกต้องไว้ในเครื่อง หาก ระบบจะส่งการตรวจสอบสัญญาอนุญาตไปยังเซิร์ฟเวอร์ การเรียกกลับจะมาจาก เทรดพื้นหลัง แม้ว่าจะเป็นข้อผิดพลาดเกี่ยวกับเครือข่ายก็ตาม

เรียกใช้ checkAccess() เพื่อเริ่มการตรวจสอบใบอนุญาต

ในกิจกรรมหลัก ให้เพิ่มการโทรไปยังเมธอด checkAccess() ของ LicenseChecker ขณะอยู่ในสาย ให้ส่งข้อมูลอ้างอิงถึง LicenseCheckerCallback เป็นพารามิเตอร์ หากคุณจำเป็นต้องจัดการ เอฟเฟกต์ UI พิเศษ หรือการจัดการสถานะก่อนการโทร ที่อาจมีประโยชน์สำหรับคุณ เพื่อเรียก checkAccess() จากเมธอด Wrapper เช่น LVL ตัวอย่างการเรียกแอปพลิเคชัน checkAccess() จาก เมธอด Wrapper doCheck():

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        ...
        // Call a wrapper method that initiates the license check
        doCheck()
        ...
    }
    ...
    private fun doCheck() {
        checkLicenseButton.isEnabled = false
        setProgressBarIndeterminateVisibility(true)
        statusText.setText(R.string.checking_license)
        checker.checkAccess(licenseCheckerCallback)
    }

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        ...
        // Call a wrapper method that initiates the license check
        doCheck();
        ...
    }
    ...
    private void doCheck() {
        checkLicenseButton.setEnabled(false);
        setProgressBarIndeterminateVisibility(true);
        statusText.setText(R.string.checking_license);
        checker.checkAccess(licenseCheckerCallback);
    }

ฝังคีย์สาธารณะเพื่อการอนุญาตให้ใช้สิทธิ

สำหรับแต่ละแอปพลิเคชัน บริการ Google Play จะ จะสร้างคู่คีย์สาธารณะ/คีย์ส่วนตัว RSA 2048 บิตที่ใช้สำหรับ การอนุญาตให้ใช้สิทธิและการเรียกเก็บเงินในแอป คู่คีย์มีการเชื่อมโยงแบบไม่ซ้ำกันกับ แอปพลิเคชัน แม้ว่าจะเชื่อมโยงกับแอปพลิเคชัน แต่คู่คีย์คือ ไม่เหมือนกับคีย์ที่คุณใช้รับรองแอปพลิเคชันของคุณ (หรือได้มาจากคีย์)

Google Play Console จะแสดงคีย์สาธารณะสำหรับการอนุญาตให้ใช้สิทธิแก่ผู้ใช้ นักพัฒนาซอฟต์แวร์ลงชื่อเข้าใช้ Play Console แต่เก็บคีย์ส่วนตัวไว้ ไม่ให้ผู้ใช้ทุกคนเห็นในตำแหน่งที่ปลอดภัย เมื่อแอปพลิเคชันขอ การตรวจสอบสัญญาอนุญาตสำหรับแอปพลิเคชันที่เผยแพร่ในบัญชีของคุณ เซิร์ฟเวอร์การให้สัญญาอนุญาต ลงนามในการตอบกลับใบอนุญาตโดยใช้คีย์ส่วนตัวของคู่คีย์ของแอปพลิเคชัน เมื่อ LVL ได้รับการตอบกลับ ระบบจะใช้คีย์สาธารณะที่ให้ไว้โดย เพื่อยืนยันลายเซ็นของการตอบกลับใบอนุญาต

หากต้องการเพิ่มการให้สัญญาอนุญาตกับแอปพลิเคชัน คุณจะต้องขอรับ คีย์สาธารณะสำหรับการอนุญาตให้ใช้สิทธิและคัดลอกลงในแอปพลิเคชันของคุณ ต่อไปนี้เป็นวิธีค้นหา คีย์สาธารณะของแอปพลิเคชันสำหรับการอนุญาตให้ใช้สิทธิ

1. ไปที่ Google Play Console และลงชื่อเข้าใช้ โปรดตรวจสอบว่าคุณลงชื่อเข้าใช้บัญชีที่ใช้แอปพลิเคชันของคุณ มีการออกใบอนุญาตแล้ว (หรือจะเผยแพร่)
2. ในหน้ารายละเอียดแอปพลิเคชัน ให้ค้นหาบริการและ API แล้วคลิกลิงก์
3. ในส่วนบริการและ API ให้ค้นหา การอนุญาตให้ใช้สิทธิและ การเรียกเก็บเงินสำหรับการซื้อในแอป คีย์สาธารณะสำหรับ จะมีการออกใบอนุญาตใน ช่องรหัสใบอนุญาตของคุณสำหรับแอปพลิเคชันนี้

เพียงคัดลอก/วางสตริงคีย์เพื่อเพิ่มคีย์สาธารณะไปยังแอปพลิเคชัน จากฟิลด์นี้ลงในแอปพลิเคชันให้เป็นค่าของตัวแปรสตริง BASE64_PUBLIC_KEY เมื่อคุณกำลังคัดลอก ต้องแน่ใจว่า เลือกสตริงคีย์ทั้งหมด โดยไม่ละอักขระใดๆ

ตัวอย่างจากแอปพลิเคชัน LVL ตัวอย่างมีดังนี้

private const val BASE64_PUBLIC_KEY = "MIIBIjANBgkqhkiG ... " //truncated for this example
class LicensingActivity : AppCompatActivity() {
    ...
}

public class MainActivity extends Activity {
    private static final String BASE64_PUBLIC_KEY = "MIIBIjANBgkqhkiG ... "; //truncated for this example
    ...
}

เรียกใช้เมธอด onDestroy() ของ LicenseChecker เพื่อปิดการเชื่อมต่อ IPC

สุดท้าย เพื่อให้ LVL ล้างออกก่อนการสมัคร เปลี่ยนแปลง Context รายการ เพิ่มการโทรไปยังLicenseChecker เมธอด onDestroy() จากกิจกรรม การใช้งาน onDestroy() การโทรนี้ทำให้เกิด LicenseCheckerเพื่อปิดการเชื่อมต่อ IPC ที่เปิดอยู่กับ Google Play อย่างถูกต้อง ILicensingService ของแอปพลิเคชัน และนำการอ้างอิงบริการในเครื่องออก และเครื่องจัดการ

ไม่สามารถเรียกใช้เมธอด onDestroy() ของ LicenseChecker อาจทำให้เกิดปัญหาตลอดวงจรชีวิตของแอปพลิเคชัน ตัวอย่างเช่น หาก ผู้ใช้เปลี่ยนการวางแนวหน้าจอขณะที่การตรวจสอบใบอนุญาตทำงานอยู่ Context ถูกทำลายแล้ว หากแอปพลิเคชันของคุณไม่ ปิดการเชื่อมต่อ IPC ของ LicenseChecker อย่างถูกต้อง แอปพลิเคชันของคุณจะขัดข้อง เมื่อได้รับคำตอบ ในทำนองเดียวกัน หากผู้ใช้ออกจากแอปพลิเคชันของคุณ ขณะที่การตรวจสอบใบอนุญาตอยู่ระหว่างดำเนินการ แอปพลิเคชันของคุณจะขัดข้องเมื่อ ได้รับการตอบสนอง เว้นแต่จะเรียกฟังก์ชัน วิธีการ onDestroy() ของ LicenseChecker ในการยกเลิกการเชื่อมต่อจากบริการ

นี่คือตัวอย่างจากแอปพลิเคชันตัวอย่างที่รวมอยู่ใน LVL โดย mChecker เป็นอินสแตนซ์ LicenseChecker:

    override fun onDestroy() {
        super.onDestroy()
        checker.onDestroy()
        ...
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        checker.onDestroy();
        ...
    }

หากคุณขยายหรือแก้ไข LicenseChecker คุณอาจต้องเรียกใช้ เมธอด finishCheck() ของ LicenseChecker เพื่อล้าง IPC ที่เปิดอยู่ การเชื่อมต่อ

การใช้งาน DeviceLimiter

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

LVL สนับสนุนการอนุญาตให้ใช้สิทธิต่ออุปกรณ์ด้วยการมอบ DeviceLimiter ซึ่งมีการประกาศเมธอดเดียว allowDeviceAccess() เมื่อ LicenseValidator จัดการกับการตอบกลับ จากเซิร์ฟเวอร์การให้สัญญาอนุญาต จะเรียก allowDeviceAccess() โดยผ่าน สตริง User-ID ที่ดึงมาจากการตอบกลับ

หากไม่ต้องการรองรับการจํากัดอุปกรณ์ จะไม่มีการดำเนินการ ต้องระบุ — คลาส LicenseChecker จะใช้ค่าเริ่มต้นโดยอัตโนมัติ ที่เรียกว่า NullDeviceLimiter ตามที่ชื่อแนะนำ NullDeviceLimiter เป็น "ไม่มีการดำเนินการ" คลาสที่เมธอด allowDeviceAccess() จะแสดงผล การตอบกลับ LICENSED สำหรับผู้ใช้และอุปกรณ์ทั้งหมด

การสร้างโค้ดให้ยากต่อการอ่าน (Obfuscate)

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

มีโปรแกรมปรับให้ยากต่อการอ่าน (Obfuscator) หลายโปรแกรมสำหรับแอปพลิเคชัน Android รวมถึง ProGuard ซึ่งมี ฟีเจอร์การเพิ่มประสิทธิภาพโค้ด การใช้ ProGuard หรือโปรแกรมที่คล้ายกันเพื่อสร้างความสับสน โค้ดของคุณขอแนะนำอย่างยิ่งสำหรับแอปพลิเคชันทั้งหมดที่ใช้ Google เปิดการอนุญาตให้ใช้สิทธิ

การเผยแพร่แอปพลิเคชันที่ได้รับอนุญาต

เมื่อคุณทดสอบการใช้งานใบอนุญาตเสร็จแล้ว คุณพร้อม เผยแพร่แอปพลิเคชันบน Google Play ทำตามขั้นตอนปกติเพื่อจัดเตรียม ลงนาม แล้วเผยแพร่แอปพลิเคชัน

จะรับการสนับสนุนได้จากที่ใด

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

ตาราง 2 แหล่งข้อมูลสนับสนุนสำหรับนักพัฒนาซอฟต์แวร์ สำหรับบริการการให้สัญญาอนุญาตของ Google Play

สำหรับข้อมูลทั่วไปเกี่ยวกับวิธีโพสต์ไปยังกลุ่มที่ระบุไว้ข้างต้น โปรดดูที่ส่วนแหล่งข้อมูลของชุมชน ในหน้าแหล่งข้อมูลการสนับสนุนนักพัฒนา

แหล่งข้อมูลเพิ่มเติม

ตัวอย่างแอปพลิเคชันที่มาพร้อม LVL จะแสดงตัวอย่างทั้งหมดเกี่ยวกับ เริ่มการตรวจสอบใบอนุญาตและจัดการผลลัพธ์ใน MainActivity ชั้นเรียน