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

แพลตฟอร์ม Android ใช้แนวคิดแซนด์บ็อกซ์ของแอปเพื่อรักษาขอบเขตการประมวลผลที่มีประสิทธิภาพและขอบเขตความปลอดภัยสำหรับโค้ดแอป รวมถึงขอบเขตกระบวนการ เป็นเรื่องปกติที่แอปจะมีโค้ดของบุคคลที่สาม ซึ่งมักจะอยู่ในรูปแบบ 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 จะสื่อสารกับอินเทอร์เฟซ SDK ในกระบวนการที่ทำงานอยู่เบื้องหน้าของแอป จากนั้นอินเทอร์เฟซเหล่านี้จะข้ามขอบเขตกระบวนการไปยังกระบวนการรันไทม์ของ SDK เพื่อเรียกใช้ SDK เอง

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

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

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

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

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

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

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

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

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

รหัส

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

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

SELinux

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

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

API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

กรณีพิเศษ

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

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

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

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

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

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

ประสิทธิภาพของระบบ

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

การสื่อสาร

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

แอปกับ SDK

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

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

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

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

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

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

แผนภาพ
ผังลำดับภาพที่แสดงการโต้ตอบระหว่างแอปกับ 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 จะได้รับแจ้งว่าระบบโหลด 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)

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

SDK กับ SDK

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

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

  • เมื่อทั้ง 2 SDK เปิดใช้รันไทม์ ในกรณีนี้ 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 ระหว่างแอปกับรันไทม์ของ SDK (มีให้บริการในรุ่นตัวอย่างสำหรับนักพัฒนาแอปล่าสุด)
  • วิธีที่วิวและการเรนเดอร์จากระยะไกลควรทํางานสําหรับสื่อกลาง (ข้อเสนออยู่ระหว่างการพัฒนา)

กรณีการใช้งานต่อไปนี้อยู่ระหว่างการพิจารณาขณะที่กําลังออกแบบพรอมิเตอ

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

แอปต่อแอป

การสื่อสารระหว่างแอปคือการสื่อสารระหว่าง 2 กระบวนการโดยอย่างน้อย 1 กระบวนการเป็น 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 จะเข้าถึงได้เฉพาะตัวรับสัญญาณออกอากาศที่ได้รับการคุ้มครองบางส่วนเท่านั้น (เช่น 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 เริ่มกิจกรรม ก็ควรลงทะเบียนอินสแตนซ์ประเภท SdkSandboxActivityHandler ซึ่งใช้เพื่อแจ้งเตือนเกี่ยวกับการสร้างกิจกรรมเมื่อแอปเรียกใช้ SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) เพื่อเริ่มกิจกรรม

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

แผนภาพ
ผังลำดับขั้นตอน ที่แสดงขั้นตอนของการเริ่มกิจกรรม

การพัฒนา

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

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

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

นักพัฒนาแอป

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

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

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

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

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

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

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

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

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

บิวด์

นักพัฒนาแอป

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

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

เรายังอยู่ในระยะเริ่มต้นของการออกแบบ และจะแชร์ข้อมูลเพิ่มเติมเมื่อโครงการเป็นรูปเป็นร่าง

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

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

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

การทดสอบ

นักพัฒนาแอป

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

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

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

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

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

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

หากต้องการรองรับการจัดจำหน่าย SDK แอปสโตร์อาจต้องให้บริการความสามารถส่วนใหญ่ต่อไปนี้

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

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

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

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