ภาพรวมรันไทม์ของ SDK

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

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

ใน Android 14 เราได้เพิ่มความสามารถใหม่ของแพลตฟอร์มที่อนุญาตให้ SDK ของบุคคลที่สาม ทํางานในสภาพแวดล้อมรันไทม์เฉพาะที่เรียกว่ารันไทม์ของ SDK รันไทม์ของ SDK ช่วยเสริมเกราะป้องกันและการรับประกันที่มากขึ้นต่อไปนี้ในการเก็บรวบรวมและแชร์ข้อมูลผู้ใช้

• สภาพแวดล้อมการดำเนินการที่แก้ไขแล้ว
• การอนุญาตและสิทธิ์เข้าถึงข้อมูลที่กำหนดมาอย่างดีสำหรับ SDK

เรากำลังรวบรวมความคิดเห็นจากชุมชนโฆษณาแอปบนอุปกรณ์เคลื่อนที่เกี่ยวกับ การออกแบบนี้ นอกจากนี้ เรายังยินดีรับฟังความคิดเห็นจากชุมชนนักพัฒนาแอปในวงกว้างเพื่อ ช่วยกำหนดการทำซ้ำในอนาคตของ SDK Runtime รวมถึงการรองรับ กรณีการใช้งานเพิ่มเติม

เป้าหมาย

ข้อเสนอนี้มีเป้าหมายเพื่อบรรลุเป้าหมายต่อไปนี้

• ลดการเข้าถึงและการแชร์ข้อมูลแอปของผู้ใช้โดย SDK ของบุคคลที่สามโดยไม่เปิดเผย ผ่านการแยกกระบวนการ รวมถึง API และการควบคุมการเข้าถึงข้อมูลที่กำหนดไว้อย่างชัดเจน ดูข้อมูลเพิ่มเติมเกี่ยวกับการแยกกระบวนการในส่วนแยก ของเอกสารนี้
• ลดการติดตามการใช้งานแอปของผู้ใช้โดย SDK ของบุคคลที่สามซึ่งไม่ได้เปิดเผยโดย จำกัดไม่ให้ SDK เข้าถึงตัวระบุที่ไม่ซ้ำกันและถาวร
• เร่งการเผยแพร่การอัปเดต SDK ไปยังแอปอย่างปลอดภัยด้วยการลดภาระของนักพัฒนาแอปและผู้ใช้ปลายทาง ดูข้อมูลเพิ่มเติมเกี่ยวกับรูปแบบการจัดจำหน่าย SDK ที่เชื่อถือได้ที่เสนอในส่วนอื่น ของเอกสารนี้
• ช่วยให้นักพัฒนาแอปพิจารณาแนวทางปฏิบัติในการเข้าถึงและแชร์ข้อมูลของแอปได้ดียิ่งขึ้น
• ช่วยให้นักพัฒนา SDK ป้องกันการดัดแปลงโดย SDK อื่นๆ ผ่านการจำกัดโครงสร้างภาษาที่ไม่ปลอดภัยบางอย่าง เช่น โค้ด JNI
• ช่วยให้ SDK โฆษณาสามารถตรวจจับและป้องกันการเข้าชมที่ไม่ถูกต้องและการฉ้อโกงผ่านโฆษณาด้วยการควบคุมอย่างเต็มที่ เกี่ยวกับมุมมองระยะไกลที่แสดงสื่อ
• ลดผลกระทบที่ไม่เหมาะสมต่อนักพัฒนาแอปและ SDK ให้ได้มากที่สุด

SDK จะทำงานในกระบวนการที่แยกต่างหาก

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

---

รูปแบบการจัดจำหน่ายที่เชื่อถือได้ใหม่สำหรับ SDK

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

กลไกนี้ช่วยปกป้องผู้ใช้และนักพัฒนาแอปจากการโหลด SDK ที่ไม่ถูกต้อง ขณะเดียวกันก็ช่วยให้ App Store ลดภาระ ในการเผยแพร่ SDK จากนักพัฒนาแอปได้อย่างมาก

SDK ไม่จำเป็นต้องลิงก์แบบคงที่และแพ็กเกจร่วมกับแอป ก่อนที่จะอัปโหลดไปยัง App Store เพื่อการจัดจำหน่ายอีกต่อไป

กระบวนการนี้มีขั้นตอนดังนี้

1. นักพัฒนาซอฟต์แวร์ SDK จะอัปโหลด SDK ที่มีการกำหนดเวอร์ชันไปยัง App Store แยกต่างหากจากแอป
2. นักพัฒนาแอปจะระบุทรัพยากร Dependency ของ SDK ตาม เวอร์ชัน บิลด์ และอัปโหลดรุ่นของแอปที่ไม่มีทรัพยากร Dependency ของ SDK จริง
3. เมื่อผู้ใช้ดาวน์โหลดแอปนี้ กระบวนการติดตั้งจะใช้ทรัพยากร Dependency ของ SDK ที่ระบุไว้ในแอปเพื่อดาวน์โหลดจาก App Store

กลไกการเผยแพร่ใหม่นี้ช่วยให้สามารถอัปเดต SDK แยกกันได้ภายใต้เงื่อนไขต่อไปนี้

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

การติดตั้งใช้งานความสามารถเหล่านี้จะขึ้นอยู่กับร้านค้า

แผนภาพต่อไปนี้แสดงการเปลี่ยนแปลงที่เสนอในการเผยแพร่ SDK

---

การเปลี่ยนแปลงวิธีสร้าง เรียกใช้ และเผยแพร่ SDK และแอป

นี่คือข้อเสนอเบื้องต้นสำหรับรันไทม์และการจัดจำหน่าย SDK แบบยืดหยุ่น ส่วนต่อไปนี้จะเสนอชุดการเปลี่ยนแปลงใน หมวดหมู่กว้างๆ ต่อไปนี้

• การเข้าถึง: สิทธิ์ หน่วยความจำ พื้นที่เก็บข้อมูล
• การดำเนินการ: ภาษา การเปลี่ยนแปลงรันไทม์ วงจร Media Rendering
• การสื่อสาร: แอปกับ SDK และ SDK กับ SDK
• การพัฒนา: วิธีสร้าง แก้ไขข้อบกพร่อง และทดสอบใน โมเดลนี้
• การเผยแพร่: วิธีเผยแพร่ อัปเดต ย้อนกลับใน Android, แอป และ SDK เวอร์ชันต่างๆ

นอกจากนี้ เอกสารนี้ยังมีคำถามที่พบบ่อยเพื่อช่วยตอบคำถามทั่วไป

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

การเข้าถึง

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

สิทธิ์ของ SDK

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

• INTERNET: สิทธิ์เข้าถึงอินเทอร์เน็ตเพื่อสื่อสารกับเว็บเซอร์วิส
• ACCESS_NETWORK_STATE: เข้าถึงข้อมูลเกี่ยวกับเครือข่าย
• READ_BASIC_PHONE_STATE: เข้าถึงข้อมูลเกี่ยวกับสถานะโทรศัพท์ เช่น ประเภทเครือข่ายมือถือ
• สิทธิ์ในการเข้าถึง API ที่รักษาความเป็นส่วนตัว ซึ่งมีฟีเจอร์หลัก ด้านการโฆษณาโดยไม่ต้องมีสิทธิ์เข้าถึงตัวระบุข้ามแอป
• AD_ID: ความสามารถในการขอรหัสโฆษณา ซึ่งจะขึ้นอยู่กับการเข้าถึงสิทธิ์นี้ของแอปด้วย

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

หน่วยความจำ

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

พื้นที่เก็บข้อมูล

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

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

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

การลงมือปฏิบัติ

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

รหัส

โค้ด Android (แอปและ SDK) ส่วนใหญ่จะได้รับการตีความโดย Android Runtime (ART) ไม่ว่าโค้ดจะเขียนด้วย Kotlin หรือ Java ความสมบูรณ์ของ ART และโครงสร้างภาษาที่ ART มีให้ รวมถึงความสามารถในการตรวจสอบที่ ART มีให้ เมื่อเทียบกับทางเลือกอื่นๆ โดยเฉพาะโค้ดที่มาพร้อมเครื่อง ดูเหมือนว่าจะ สร้างสมดุลระหว่างฟังก์ชันการทำงานและความเป็นส่วนตัวได้อย่างเหมาะสม เราขอเสนอให้โค้ด SDK ที่เปิดใช้รันไทม์ ประกอบด้วยไบต์โค้ด Dex เท่านั้น แทนที่จะรองรับการเข้าถึง JNI

เราทราบว่ามี Use Case บางอย่าง เช่น การใช้ SQLite ที่แพ็กเกจที่กำหนดเอง ซึ่งจะต้องแทนที่ด้วยทางเลือกอื่น เช่น SQLite เวอร์ชันในตัวของ Android SDK เนื่องจากมีการใช้โค้ดเนทีฟ

SELinux

ใน Android แต่ละกระบวนการ (รวมถึงกระบวนการที่ทำงานในฐานะรูท) จะทำงานด้วยบริบท SELinux ที่เฉพาะเจาะจง ซึ่งช่วยให้เคอร์เนลจัดการการควบคุมการเข้าถึงบริการของระบบ ไฟล์ อุปกรณ์ และกระบวนการอื่นๆ ได้ เราพยายามที่จะรักษา Use Case ส่วนใหญ่ของ SDK ไว้พร้อมกับลดการหลบเลี่ยงการคุ้มครองความเป็นส่วนตัวที่เราพยายามจะดำเนินการต่อไป จึงขอเสนอการอัปเดตต่อไปนี้จากบริบท SELinux ของแอปที่ไม่ใช่ระบบสำหรับ SDK Runtime

• คุณจะเข้าถึงชุดบริการของระบบได้แบบจำกัด (อยู่ระหว่างการออกแบบ)
• SDK จะโหลดและเรียกใช้โค้ดใน APK ของตนเองได้เท่านั้น
• คุณจะเข้าถึงพร็อพเพอร์ตี้ของระบบได้เพียงบางส่วน (อยู่ระหว่างการออกแบบ)

API

อนุญาตให้ใช้การสะท้อนและการเรียกใช้ API ภายในรันไทม์ของ SDK อย่างไรก็ตาม SDK จะไม่ได้รับอนุญาตให้ใช้การสะท้อนหรือเรียกใช้ API ใน SDK อื่นที่เปิดใช้รันไทม์ เราจะแชร์ข้อเสนอทั้งหมดของ API ที่ไม่อนุญาตในการอัปเดตในอนาคต

นอกจากนี้ การเปิดตัวแพลตฟอร์ม Android ล่าสุดยังจำกัด การเข้าถึงตัวระบุแบบถาวรมากขึ้นเรื่อยๆ เพื่อปรับปรุงความเป็นส่วนตัว สำหรับ SDK Runtime เราขอเสนอให้จำกัดการเข้าถึงตัวระบุเพิ่มเติมซึ่งอาจใช้ สำหรับการติดตามข้ามแอป

API รันไทม์ของ SDK จะเข้าถึงได้จากแอปที่ทำงานอยู่เบื้องหน้าเท่านั้น การพยายามเข้าถึง SdkSandboxManager API จากแอปในเบื้องหลังจะทำให้เกิดข้อผิดพลาด SecurityException

สุดท้ายนี้ RE-SDK จะใช้ Notifications API เพื่อส่งการแจ้งเตือนให้ผู้ใช้ไม่ได้ ไม่ว่าเวลาใดก็ตาม

อายุการใช้งาน

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

• ผู้ใช้หรือระบบปฏิบัติการสามารถสิ้นสุดการทำงานของแอปได้ รันไทม์ของ SDK จะสิ้นสุดโดยอัตโนมัติทันทีหลังจากนั้น

• ระบบปฏิบัติการสามารถสิ้นสุดรันไทม์ SDK ได้เนื่องจากหน่วยความจำ มีแรงกดดัน หรือมีข้อยกเว้นที่ไม่ได้จัดการใน SDK เป็นต้น

  สำหรับ Android 14 เมื่อแอปทำงานอยู่เบื้องหน้า รันไทม์ของ SDK จะทำงานใน ลำดับความสำคัญสูงและไม่น่าจะถูกสิ้นสุด เมื่อแอปเข้าสู่ เบื้องหลัง ลำดับความสำคัญของกระบวนการรันไทม์ของ SDK จะลดลงและ มีสิทธิ์ถูกสิ้นสุด ลำดับความสำคัญของกระบวนการรันไทม์ของ SDK จะยังคง ต่ำแม้ว่าแอปจะกลับมาที่เบื้องหน้าก็ตาม ดังนั้นจึงมีแนวโน้มสูงมากที่ระบบจะปิดแอปเนื่องจากหน่วยความจำใกล้จะเต็มเมื่อเทียบกับแอป

  สำหรับ Android 14 ขึ้นไป ระบบจะจัดลำดับความสำคัญของกระบวนการของแอปและ SDK Runtime ให้สอดคล้องกัน ลำดับความสำคัญของกระบวนการสำหรับ ActivityManager.RunningAppProcessInfo.importance สำหรับแอปและ รันไทม์ของ SDK ควรใกล้เคียงกัน

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

  • ข้อเสนอมีเมธอดเรียกกลับของวงจรที่เกี่ยวข้องสำหรับนักพัฒนาแอป เพื่อตรวจหาเมื่อมีการสิ้นสุดรันไทม์ของ SDK
  • หาก SDK Runtime สิ้นสุดในขณะที่โฆษณากำลังแสดง โฆษณาอาจไม่ทำงานตามที่คาดไว้ เช่น ยอดดูอาจค้างอยู่บนหน้าจอและไม่ สามารถโต้ตอบได้อีก แอปสามารถนำมุมมองโฆษณาออกได้หากไม่ส่งผลต่อ ประสบการณ์ของผู้ใช้
  • แอปสามารถลองโหลด SDK และขอโฆษณาอีกครั้งได้
  • สำหรับ Android 14 หากรันไทม์ของ SDK สิ้นสุดลงขณะที่โหลด SDK อยู่ และหากนักพัฒนาแอปไม่ได้ลงทะเบียนวิธีการเรียกกลับของวงจรดังกล่าวข้างต้น แอปจะสิ้นสุดลงโดยค่าเริ่มต้น เฉพาะกระบวนการของแอป ที่โหลด SDK เท่านั้นที่จะสิ้นสุดและออกตามปกติ
  • ออบเจ็กต์ Binder ที่ SDK ส่งกลับมาเพื่อสื่อสารกับ SDK (เช่น SandboxedSdk) จะแสดง DeadObjectException หากแอปใช้งาน

  รูปแบบวงจรนี้อาจมีการเปลี่ยนแปลงในการอัปเดตในอนาคต

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

SDK ที่ไม่ใช่ RE จะใช้ Primitive ของระบบปฏิบัติการมาตรฐานที่พร้อมใช้งานสำหรับแอปที่ฝังไว้ต่อไปได้ ซึ่งรวมถึงบริการ กิจกรรม และการออกอากาศ ในขณะที่ SDK ของ RE จะใช้ไม่ได้

กรณีพิเศษ

ระบบไม่รองรับกรณีต่อไปนี้และอาจทำให้เกิดลักษณะการทำงานที่ไม่คาดคิด

• หากแอปหลายแอปใช้ UID เดียวกัน รันไทม์ SDK อาจทำงานได้ไม่ถูกต้อง เราอาจเพิ่มการรองรับ UID ที่แชร์ในอนาคต
• สำหรับแอปที่มีหลายกระบวนการ ควรโหลด SDK ในกระบวนการหลัก

การแสดงผลสื่อ

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

โฆษณาเนทีฟที่ไม่ได้แสดงผลโดย SDK แต่แสดงผลโดยแอปจะได้รับการรองรับจาก SDK ในรันไทม์ของ SDK กระบวนการรวบรวมสัญญาณและดึงข้อมูลครีเอทีฟโฆษณา จะเกิดขึ้นอย่างสม่ำเสมอเช่นเดียวกับโฆษณาที่ไม่ใช่เนทีฟ เรากำลัง ตรวจสอบเรื่องนี้อยู่

โฆษณาวิดีโอในสตรีมคือโฆษณาที่แสดงในสตรีมพร้อมกับวิดีโอ โดยจะแสดงในเพลเยอร์ ภายในแอป เนื่องจากวิดีโอเล่นภายในเพลเยอร์ในแอป ไม่ใช่เพลเยอร์หรือมุมมองใน SDK รูปแบบการแสดงผลจึงแตกต่างจากรูปแบบโฆษณาอื่นๆ เรากำลังพิจารณากลไกต่างๆ เพื่อรองรับทั้งการแทรกโฆษณาฝั่งเซิร์ฟเวอร์ และการแทรกโฆษณาที่อิงตาม SDK

สถานะของระบบ

เราพยายามลดผลกระทบต่อความสมบูรณ์ของระบบที่รันไทม์ของ SDK มีต่ออุปกรณ์ของผู้ใช้ปลายทาง และกำลังออกแบบวิธีดำเนินการดังกล่าว อย่างไรก็ตาม มีแนวโน้มว่าอุปกรณ์ Android 14 ระดับเริ่มต้นบางรุ่น ที่มีทรัพยากรระบบจำกัดมาก เช่น Android (Go edition) จะไม่รองรับรันไทม์ของ SDK เนื่องจากผลกระทบต่อความสมบูรณ์ของระบบ เราจะแชร์ข้อกำหนดขั้นต่ำที่จำเป็นต่อการใช้ SDK Runtime ให้สำเร็จในเร็วๆ นี้

การสื่อสาร

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

แอปไปยัง SDK

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

เนื่องจากโครงสร้างขอบเขตกระบวนการของ SDK Runtime เราจึงขอเสนอให้ สร้างเลเยอร์การมาร์ชัลที่เข้าถึงได้ภายในแอปเพื่อส่งการเรียก API และ การตอบกลับหรือการเรียกกลับข้ามขอบเขตนี้ระหว่างแอปกับ SDK เรา ขอเสนอให้ผู้พัฒนา SDK เป็นผู้กำหนดอินเทอร์เฟซของเลเยอร์การมาร์ชัลนี้ และใช้เครื่องมือสร้างแบบโอเพนซอร์สอย่างเป็นทางการที่เราจะ พัฒนาขึ้นเป็นตัวสร้าง

ข้อเสนอนี้มีจุดประสงค์เพื่อลดภาระงานในการจัดเรียงข้อมูลจากแอป และนักพัฒนา SDK ในขณะเดียวกันก็มอบความยืดหยุ่นแก่นักพัฒนา SDK และรับประกัน ว่าโค้ด SDK จะทํางานในรันไทม์ของ SDK เพื่อให้บรรลุเป้าหมายด้านความเป็นส่วนตัวของเรา หากเรา เลือกเส้นทางนี้ ภาษาคำจำกัดความของ API และเครื่องมือจะต้อง ได้รับการออกแบบโดยอิงตามความคิดเห็นของคุณ

รูปแบบการโต้ตอบทั่วไปจะเป็นดังนี้

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

ผลที่ตามมาของโครงสร้างแบบข้ามกระบวนการใหม่ของข้อเสนอนี้คือ จะมีวงจรการทำงานของกระบวนการ 2 อย่างที่ต้องจัดการ ได้แก่ วงจรการทำงานของแอป เองและวงจรการทำงานของรันไทม์ของ SDK ข้อเสนอของเรามุ่งเน้นการทำงานอัตโนมัติให้ได้มากที่สุด เพื่อลดผลกระทบต่อนักพัฒนาแอปและ SDK แผนภาพต่อไปนี้แสดงแนวทางที่เรากำลังพิจารณา

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

กราฟในรูปก่อนหน้าแสดงการสื่อสารระหว่างแอปกับ SDK ที่ระดับล่างกว่าโดยไม่มีเลเยอร์การจัดรูปแบบ

แอปจะสื่อสารกับ SDK ที่ทํางานในกระบวนการรันไทม์ของ SDK ผ่านขั้นตอนต่อไปนี้

1. ก่อนที่แอปจะโต้ตอบกับ SDK ได้ แอปจะต้องขอให้แพลตฟอร์มโหลด SDK เพื่อให้มั่นใจในความสมบูรณ์ของระบบ แอปจะต้องระบุ SDK ที่ต้องการโหลดในไฟล์ Manifest และ SDK เหล่านี้จะเป็น SDK เดียวที่ได้รับอนุญาตให้โหลด

   ข้อมูลโค้ดต่อไปนี้แสดงตัวอย่าง API

   SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor,
       OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)
   

2. SDK จะได้รับการแจ้งเตือนว่ามีการโหลดแล้วและจะแสดงอินเทอร์เฟซของตัวเอง อินเทอร์เฟซนี้มีไว้สำหรับใช้โดยกระบวนการของแอป หากต้องการแชร์อินเทอร์เฟซ นอกขอบเขตของกระบวนการ คุณต้องส่งคืนเป็นออบเจ็กต์ IBinder

   คู่มือบริการที่เชื่อมโยงจะอธิบายวิธีต่างๆ ในการให้บริการ IBinder ไม่ว่าคุณจะเลือกวิธีใดก็ตาม วิธีนั้นจะต้องสอดคล้องกันระหว่าง SDK กับ แอปที่เรียกใช้ ไดอะแกรมใช้ AIDL เป็นตัวอย่าง

3. SdkSandboxManager จะรับอินเทอร์เฟซ IBinder และส่งคืนไปยัง แอป

4. แอปจะรับ IBinder และแคสต์ลงในอินเทอร์เฟซ SDK โดยเรียกใช้ฟังก์ชันต่อไปนี้

   IBinder binder = sandboxSdk.getInterface();
   ISdkInterface mySdkInterface = ISdkInterface.Stub.asInterface(binder);
   mySdkInterface.something();
   

แอปยังแสดงผลสื่อจาก SDK ได้ด้วยโดยทำตามขั้นตอนต่อไปนี้

1. ดังที่อธิบายไว้ในส่วนการแสดงผลสื่อของเอกสารนี้ เพื่อให้แอปได้รับ SDK เพื่อแสดงผลสื่อในมุมมอง แอป สามารถเรียกใช้ requestSurfacePackage() และดึงข้อมูลที่เหมาะสม SurfaceControlViewHost.SurfacePackage

   ข้อมูลโค้ดต่อไปนี้แสดงตัวอย่าง API

   SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams,
           Executor executor,
           OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)
   

2. จากนั้นแอปจะฝัง SurfacePackage ที่ส่งคืนลงใน SurfaceView ผ่าน setChildSurfacePackage API ใน SurfaceView ได้

   ข้อมูลโค้ดต่อไปนี้แสดงตัวอย่าง API

   SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
   

ข้อเสนอของเราคือ API IBinder และ requestSurfacePackage() ควรเป็น แบบทั่วไปและไม่ได้มีไว้ให้แอปเรียกใช้โดยตรง แต่ API เหล่านี้จะเรียกใช้โดยข้อมูลอ้างอิง API ที่สร้างขึ้นตามที่กล่าวไว้ข้างต้นในเลเยอร์ "Shim" เพื่อลดภาระของนักพัฒนาแอป

SDK-to-SDK

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

กรณีสำคัญ 2 กรณีที่ควรพิจารณามีดังนี้

• เมื่อ SDK ทั้ง 2 รายการเปิดใช้รันไทม์ ในกรณีนี้ SDK ทั้ง 2 รายการจะทํางานใน รันไทม์ของ SDK พร้อมการป้องกันทั้งหมด SDK ไม่สามารถสื่อสารได้เหมือนที่ทำภายในแอปในปัจจุบัน ดังนั้น เราจึงเพิ่ม API ใน SdkSandboxController เพื่อให้ดึงข้อมูลออบเจ็กต์ SandboxedSdk สำหรับ RE-SDK ทั้งหมดที่โหลดได้ ซึ่งช่วยให้ RE-SDK สื่อสารกับ SDK อื่นๆ ที่โหลดในรันไทม์ของ SDK ได้
• เมื่อมี SDK ที่เปิดใช้รันไทม์เพียงรายการเดียว
  • หาก SDK การโทรทำงานในแอป การทำงานนี้จะไม่มีความแตกต่างจาก แอปที่เรียกใช้ SDK ที่ 2 ภายในรันไทม์ของ SDK
  • หาก SDK ที่เรียกใช้ทำงานภายในรันไทม์ของ SDK ข้อเสนอนี้ แนะนําให้แสดงเมธอดโดยใช้ IBinder ที่อธิบายไว้ในส่วนแอปไปยัง SDK ซึ่งโค้ดในแอปจะรอฟัง ประมวลผล และตอบกลับด้วย การเรียกกลับที่ระบุ
  • SDK โฆษณาที่ไม่ได้เปิดใช้รันไทม์อาจลงทะเบียนด้วยตนเองไม่ได้ เราจึงขอเสนอการสร้าง SDK ตัวกลางซึ่งรวม SDK ของพาร์ทเนอร์หรือแอป เป็นทรัพยากร Dependency โดยตรงของแอปและจัดการการลงทะเบียน SDK ตัวกลางนี้สร้างการสื่อสารระหว่าง SDK ที่ไม่ได้เปิดใช้รันไทม์ หรือทรัพยากร Dependency ของแอปอื่นๆ กับตัวกลางที่เปิดใช้รันไทม์ซึ่งทำหน้าที่เป็น อแดปเตอร์

ชุดฟีเจอร์สำหรับการสื่อสารระหว่าง SDK กับ SDK แบ่งออกเป็นหมวดหมู่ต่อไปนี้

• การสื่อสารระหว่าง SDK กับ SDK ภายในรันไทม์ของ SDK (พร้อมใช้งานใน Developer Preview ล่าสุด )
• การสื่อสารระหว่าง SDK กับ SDK ระหว่างแอปกับรันไทม์ของ SDK (พร้อมใช้งานใน เวอร์ชันตัวอย่างสำหรับนักพัฒนาล่าสุด)
• วิธีการทำงานของยอดดูและการแสดงผลระยะไกลสำหรับสื่อกลาง (ข้อเสนออยู่ระหว่างการพัฒนา)

เรากำลังพิจารณากรณีการใช้งานต่อไปนี้ขณะออกแบบองค์ประกอบพื้นฐาน

1. สื่อกลางและการเสนอราคา SDK โฆษณาจำนวนมากมีฟีเจอร์สื่อกลางหรือการเสนอราคา ซึ่ง SDK จะเรียก SDK อื่นๆ เพื่อการแสดงโฆษณา (สื่อกลาง) หรือเพื่อรวบรวมสัญญาณเพื่อทำการประมูล (การเสนอราคา) โดยปกติแล้ว SDK ที่ประสานงานจะเรียก SDK อื่นๆ ผ่านอะแดปเตอร์ที่จัดหาโดย SDK ที่ประสานงาน เมื่อพิจารณาจากองค์ประกอบพื้นฐานข้างต้น SDK ที่ประสานงาน ไม่ว่าจะเป็น RE หรือไม่ก็ตาม ควรจะเข้าถึง SDK ทั้งหมดที่เป็น RE และไม่ใช่ RE เพื่อการทำงานตามปกติได้ การแสดงผลในบริบทนี้เป็นประเด็นที่ยังมีการตรวจสอบกันอย่างต่อเนื่อง
2. การค้นพบฟีเจอร์ ผลิตภัณฑ์ SDK บางอย่างประกอบด้วย SDK ขนาดเล็กกว่า ซึ่งจะกำหนดชุดฟีเจอร์ขั้นสุดท้าย ที่แสดงต่อนักพัฒนาแอปผ่านกระบวนการค้นพบระหว่าง SDK คาดว่าการลงทะเบียนและองค์ประกอบพื้นฐานของการค้นพบ จะช่วยให้ใช้กรณีการใช้งานนี้ได้
3. รูปแบบการสมัครใช้บริการของผู้เผยแพร่โฆษณา SDK บางตัวได้รับการออกแบบมาให้มีผู้เผยแพร่เหตุการณ์ส่วนกลาง ซึ่ง SDK หรือแอปอื่นๆ สามารถสมัครรับข้อมูลเพื่อรับ การแจ้งเตือนผ่านการเรียกกลับ Primitive ด้านบนควรสนับสนุนกรณีการใช้งานนี้

แอปต่อแอป

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

• SDK ไม่สามารถกำหนดคอมโพเนนต์ เช่น <service>, <contentprovider> หรือ <activity> ในไฟล์ Manifest
• SDK เผยแพร่ ContentProvider หรือส่งการออกอากาศไม่ได้
• SDK สามารถเปิดใช้กิจกรรมที่เป็นของแอปอื่นได้ แต่มีข้อจำกัดเกี่ยวกับ สิ่งที่ส่งใน Intent เช่น คุณจะเพิ่มการดำเนินการพิเศษหรือการดำเนินการที่กำหนดเองลงใน Intent นี้ไม่ได้
• SDK จะเริ่มหรือเชื่อมโยงกับรายการที่อนุญาตของบริการได้เท่านั้น
• SDK จะเข้าถึงได้เฉพาะชุดย่อยของระบบ ContentProvider (เช่น com.android.providers.settings.SettingsProvider) ซึ่งข้อมูลที่ได้รับ จะไม่มีตัวระบุและใช้สร้างลายนิ้วมือของผู้ใช้ไม่ได้ การตรวจสอบเหล่านี้มีผลกับการเข้าถึง ContentProvider โดยใช้ ContentResolver ด้วย
• SDK จะเข้าถึงได้เฉพาะชุดย่อยของ Broadcast Receiver ที่ได้รับการปกป้อง (เช่น android.intent.action.AIRPLANE_MODE)

แท็กไฟล์ Manifest

เมื่อติดตั้ง SDK แล้ว PackageManager จะแยกวิเคราะห์ไฟล์ Manifest ของ SDK และติดตั้ง SDK ไม่สําเร็จ หากมีแท็ก Manifest ที่ถูกแบน เช่น SDK อาจ ไม่ได้กำหนดคอมโพเนนต์อย่าง <service>, <activity>, <provider> หรือ <receiver> และอาจไม่ได้ประกาศ <permission> ในไฟล์ Manifest ระบบไม่รองรับแท็กที่ติดตั้งไม่สำเร็จในรันไทม์ SDK แท็กที่ติดตั้งได้สำเร็จแต่ระบบเพิกเฉยโดยไม่มีการแจ้งเตือนอาจได้รับการรองรับใน Android เวอร์ชันในอนาคต

เครื่องมือเวลาบิลด์ที่ SDK ใช้เพื่อ สร้างชุด SDK และเวลาที่อัปโหลดไปยัง App Store อาจใช้การตรวจสอบเหล่านี้ด้วย

การสนับสนุนกิจกรรม

SDK ในสภาพแวดล้อมรันไทม์ของ SDK จะเพิ่มแท็กกิจกรรมลงในไฟล์ Manifest ไม่ได้ และจะเริ่มกิจกรรมของตนเองโดยใช้ Context.startActivity ไม่ได้ แต่แพลตฟอร์มจะสร้างกิจกรรมสำหรับ SDK เมื่อมีการร้องขอและ แชร์กิจกรรมเหล่านั้นกับ SDK

กิจกรรมในแพลตฟอร์มเป็นประเภท android.app.Activity กิจกรรมของแพลตฟอร์ม เริ่มต้นจากกิจกรรมอย่างใดอย่างหนึ่งของแอปและเป็นส่วนหนึ่งของงานของแอป ไม่รองรับ FLAG_ACTIVITY_NEW_TASK

หากต้องการให้ SDK เริ่มกิจกรรม SDK ควรลงทะเบียนอินสแตนซ์ประเภท SdkSandboxActivityHandler ซึ่งใช้เพื่อแจ้งเตือนเกี่ยวกับการสร้างกิจกรรมเมื่อ แอปเรียกใช้ SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) เพื่อ เริ่มกิจกรรม

ขั้นตอนการขอใช้กิจกรรมแสดงอยู่ในกราฟต่อไปนี้

การพัฒนา

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

การเขียนโปรแกรม

เราจะอัปเดต Android Studio และเครื่องมือที่เกี่ยวข้องให้รองรับรันไทม์ของ SDK เพื่อช่วยให้นักพัฒนาแอปกำหนดค่าแอป RE และ SDK ของตนได้อย่างถูกต้อง รวมถึงอัปเดตการเรียกที่เลิกใช้งานแล้วหรือไม่รองรับให้เป็น ทางเลือกใหม่ที่เกี่ยวข้อง ในระหว่างขั้นตอนการเขียน เรามีขั้นตอนบางอย่าง ที่ข้อเสนอของเรากำหนดให้นักพัฒนาแอปต้องดำเนินการ

นักพัฒนาแอป

แอปจะต้องระบุการอ้างอิง RE SDK และใบรับรอง SDK ในไฟล์ Manifest ของแอป ในข้อเสนอของเรา เราถือว่าสิ่งนี้เป็นแหล่งข้อมูลที่เชื่อถือได้จากนักพัฒนาแอปตลอดข้อเสนอนี้ เช่น

• ชื่อ: ชื่อแพ็กเกจของ SDK หรือไลบรารี
• เวอร์ชันหลัก: รหัสเวอร์ชันหลักของ SDK
• ข้อมูลสรุปของใบรับรอง: ข้อมูลสรุปของใบรับรองของบิลด์ SDK สำหรับ บิลด์ที่ระบุ เราขอแนะนำให้นักพัฒนาแอป SDK ขอรับและลงทะเบียนค่านี้ผ่าน App Store ที่เกี่ยวข้อง

โดยจะมีผลกับ SDK ที่เผยแพร่ใน App Store เท่านั้น ไม่ว่าจะเป็น RE หรือไม่ก็ตาม แอปที่ลิงก์ SDK แบบคงที่จะใช้กลไกการขึ้นต่อกันในปัจจุบัน

เนื่องจากเป้าหมายของเราคือการสร้างผลกระทบต่อผู้พัฒนาน้อยที่สุด เมื่อระบุ ระดับ API เป้าหมายที่รองรับ SDK Runtime แล้ว นักพัฒนาแอปจึง จำเป็นต้องมีบิลด์เดียวเท่านั้น ไม่ว่าบิลด์นั้นจะทำงานบนอุปกรณ์ที่รองรับ SDK Runtime หรือไม่ก็ตาม

นักพัฒนาซอฟต์แวร์ SDK

ในการออกแบบที่เราเสนอ นักพัฒนา RE SDK ต้องประกาศองค์ประกอบใหม่ที่แสดงถึงเอนทิตี SDK หรือไลบรารีในไฟล์ Manifest อย่างชัดแจ้ง นอกจากนี้ คุณจะต้องระบุชุดค่าที่คล้ายกันกับค่าการอ้างอิง รวมถึงเวอร์ชันย่อยด้วย

• ชื่อ: ชื่อแพ็กเกจของ SDK หรือไลบรารี
• เวอร์ชันหลัก: รหัสเวอร์ชันหลักของ SDK
• เวอร์ชันรอง: รหัสเวอร์ชันรองของ SDK

หากนักพัฒนา RE SDK มี RE SDK อื่นเป็นทรัพยากร Dependency ในเวลาบิลด์ นักพัฒนาเหล่านั้น อาจต้องประกาศทรัพยากร Dependency ในลักษณะเดียวกับที่นักพัฒนาแอป ประกาศทรัพยากร Dependency เดียวกัน SDK ของ RE ที่ขึ้นอยู่กับ SDK ที่ไม่ใช่ RE จะ ลิงก์แบบคงที่ ซึ่งอาจทำให้เกิดปัญหาที่ตรวจพบในเวลาสร้างหรือระหว่างการทดสอบ หาก SDK ที่ไม่ใช่ RE ต้องใช้ฟังก์ชันการทำงานที่รันไทม์ SDK ไม่รองรับ หรือหากต้องเรียกใช้ในกระบวนการของแอป

นักพัฒนาซอฟต์แวร์ RE SDK อาจต้องการรองรับอุปกรณ์ที่ไม่ได้เปิดใช้ RE ต่อไป เช่น Android 12 หรือต่ำกว่า และตามที่ระบุไว้ในส่วนสุขภาพของระบบของเอกสาร อุปกรณ์ Android 14 ระดับเริ่มต้นที่มีทรัพยากรระบบจำกัดมาก เรากำลังพิจารณาวิธีการต่างๆ เพื่อให้มั่นใจว่านักพัฒนา SDK สามารถคงฐานโค้ดเดียวไว้เพื่อรองรับสภาพแวดล้อม RE และสภาพแวดล้อมที่ไม่ใช่ RE

บิวด์

นักพัฒนาแอป

เราคาดว่านักพัฒนาแอปจะพบการเปลี่ยนแปลงเพียงเล็กน้อยในขั้นตอนการสร้าง ทรัพยากร Dependency ของ SDK ไม่ว่าจะกระจายในเครื่องหรือกระจายใน App Store (RE หรือไม่) จะต้องอยู่ในเครื่องสำหรับการ Lint, การคอมไพล์ และการสร้าง เราขอเสนอให้ Android Studio แยกรายละเอียดเหล่านี้ออกจากนักพัฒนาแอปด้วยการใช้งานปกติและทำให้กระบวนการนี้โปร่งใสที่สุดเท่าที่จะเป็นไปได้

แม้ว่าเราจะคาดหวังว่าบิลด์ DEBUG จะต้องมีโค้ดและสัญลักษณ์ทั้งหมด ในบิลด์ DEBUG เพื่อให้ดีบักได้ แต่บิลด์ RELEASE อาจ เลือกที่จะนำ SDK ทั้งหมดที่จัดจำหน่ายใน App Store (RE หรือไม่) ออกจาก อาร์ติแฟกต์สุดท้ายได้

เราอยู่ในช่วงแรกๆ ของการออกแบบและจะแชร์ข้อมูลเพิ่มเติมเมื่อมีความคืบหน้า

นักพัฒนาซอฟต์แวร์ SDK

เรากำลังหาวิธีเพื่อให้มั่นใจว่า SDK เวอร์ชันที่ไม่ใช่ RE และ RE สามารถสร้างเป็นอาร์ติแฟกต์เดียวเพื่อการจัดจำหน่ายได้ ซึ่งจะช่วย ให้นักพัฒนาแอปไม่ต้องรองรับบิลด์แยกต่างหากสำหรับ SDK เวอร์ชัน RE และ เวอร์ชันที่ไม่ใช่ RE

เช่นเดียวกับแอป SDK ของทรัพยากร Dependency ที่เผยแพร่ใน App Store จะต้อง อยู่ในเครื่องเพื่อใช้ในการ Lint, การคอมไพล์ และการสร้าง และเราคาดหวังว่า Android Studio จะช่วยให้กระบวนการนี้เป็นไปอย่างราบรื่น

การทดสอบ

นักพัฒนาแอป

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

นักพัฒนาซอฟต์แวร์ SDK

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

การจัดจำหน่าย

การแยกแอปออกจาก SDK ทำให้เกิดความเป็นไปได้ในการเผยแพร่ SDK ใน App Store ฟีเจอร์นี้เป็นฟีเจอร์ของแพลตฟอร์ม ไม่ได้เจาะจงช่องทางการจัดจำหน่ายใดๆ

ซึ่งมีประโยชน์ดังต่อไปนี้

• รักษาคุณภาพและความสอดคล้องของ SDK
• ปรับปรุงการเผยแพร่สำหรับนักพัฒนา SDK
• เร่งการเปิดตัวการอัปเดตแพตช์ที่สำคัญของ SDK ไปยังแอปที่ติดตั้ง

หากต้องการรองรับการเผยแพร่ SDK ช่องทางการเผยแพร่จะต้องรองรับความสามารถต่อไปนี้

• นักพัฒนา SDK สามารถเผยแพร่ SDK ของตนไปยัง Store หรือแพลตฟอร์ม และดำเนินการบำรุงรักษาได้
• ตรวจสอบความสมบูรณ์ของ SDK, แอป และแก้ไขการอ้างอิง
• ติดตั้ง SDK ลงในอุปกรณ์อย่างสม่ำเสมอและเชื่อถือได้ รวมถึงมีประสิทธิภาพ

การเปลี่ยนแปลงข้อจำกัดเมื่อเวลาผ่านไป

เราคาดว่าข้อจำกัดที่โค้ดในรันไทม์ของ SDK ต้องเผชิญจะพัฒนาไปพร้อมกับ Android เวอร์ชันต่อๆ ไป เราจะไม่เปลี่ยนแปลงข้อจำกัดเหล่านี้เมื่อมีการอัปเดตโมดูล Mainline สำหรับระดับ SDK ที่กำหนด เพื่อให้มั่นใจว่าแอปพลิเคชันจะเข้ากันได้ ระบบจะเก็บรักษาลักษณะการทำงาน ที่เชื่อมโยงกับ targetSdkVersion ที่ระบุไว้จนกว่าจะเลิกใช้งานการรองรับtargetSdkVersion นั้นผ่านนโยบาย App Store และ การเลิกใช้งาน targetSdkVersion อาจเกิดขึ้นเร็วกว่าการเลิกใช้งานแอป คาดว่าข้อจํากัดจะมีการเปลี่ยนแปลงบ่อยใน SDK ของ Android ทุกเวอร์ชัน โดยเฉพาะ ในช่วง 2-3 รุ่นแรก

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

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

1. SDK ที่เกี่ยวข้องกับการโฆษณาคืออะไร

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

2. SDK ใดบ้างที่สามารถทำงานในรันไทม์ของ SDK

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

3. เหตุใดจึงควรเลือกการแยกกระบวนการแทนการแยกภายในรันไทม์ที่ใช้ Java ของกระบวนการ

   ปัจจุบัน รันไทม์ที่ใช้ Java ไม่ได้อำนวยความสะดวกด้านขอบเขตความปลอดภัยที่จำเป็นสำหรับการรับประกันความเป็นส่วนตัวที่ต้องการสำหรับผู้ใช้ Android การพยายามนำสิ่งนี้ไปใช้จะต้องใช้ความพยายามหลายปีโดยไม่มีการรับประกันความสำเร็จ ดังนั้น Privacy Sandbox จึงใช้ขอบเขตกระบวนการใช้งาน ซึ่งเป็นเทคโนโลยีที่ได้รับการพิสูจน์แล้วและเป็นที่เข้าใจกันดี

4. การย้าย SDK ไปยังกระบวนการรันไทม์ของ SDK จะช่วยประหยัดขนาดการดาวน์โหลด หรือพื้นที่เก็บข้อมูลได้ไหม

   หากผสานรวมแอปหลายแอปกับ SDK ที่เปิดใช้รันไทม์เวอร์ชันเดียวกัน การดำเนินการนี้จะช่วยลดขนาดการดาวน์โหลดและพื้นที่ดิสก์ได้

5. เหตุการณ์วงจรการใช้งานแอปประเภทใด เช่น เมื่อแอปเข้าสู่ เบื้องหลัง SDK จะมีสิทธิ์เข้าถึงในรันไทม์ของ SDK

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

แนะนำสำหรับคุณ

• หมายเหตุ: ข้อความลิงก์จะแสดงเมื่อ JavaScript ปิดอยู่
• คู่มือนักพัฒนาซอฟต์แวร์ SDK Runtime