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

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

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

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

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

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

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

การเปลี่ยนแปลงวิธีสร้าง เรียกใช้ และจัดจำหน่าย SDK และแอป

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

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

รหัส

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

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

SELinux

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

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

API

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

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

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

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

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

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

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

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

    สำหรับ Android 13 เมื่อแอปอยู่เบื้องหน้า รันไทม์ของ 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 ยังสามารถใช้ระบบปฏิบัติการมาตรฐานพื้นฐานที่มีให้ใช้งานสำหรับ แอปแบบฝัง รวมถึงบริการ กิจกรรม และการออกอากาศ ในขณะที่ RE SDK ไม่ได้

กรณีพิเศษ

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

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

การแสดงภาพสื่อ

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

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

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

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

เราพยายามลดผลกระทบด้านประสิทธิภาพของระบบที่รันไทม์ SDK มีต่ออุปกรณ์ของผู้ใช้ปลายทาง และกำลังออกแบบวิธีต่างๆ ในการลดผลกระทบดังกล่าว อย่างไรก็ตาม อุปกรณ์ Android 13 ระดับเริ่มต้นบางรุ่นที่มีทรัพยากรระบบจํากัดมาก เช่น Android (รุ่น Go) อาจไม่รองรับรันไทม์ 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)

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

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

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

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

จากแอปไปยังแอป

การสื่อสารระหว่างแอปคือการสื่อสารระหว่าง 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 ใช้เพื่อดำเนินการ สร้าง Bundle SDK และขณะอัปโหลดไปยัง App Store

การรองรับกิจกรรม

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

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

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

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

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

การพัฒนา

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

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

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

นักพัฒนาแอป

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

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

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

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

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

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

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

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

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

บิวด์

นักพัฒนาแอป

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

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

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

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

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

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

การทดสอบ

นักพัฒนาแอป

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

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

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

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

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

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

เพื่อให้รองรับการเผยแพร่ SDK ได้ App Store จะต้อง มีความสามารถส่วนใหญ่ดังต่อไปนี้

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

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

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

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

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

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

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