نمای کلی زمان اجرا SDK

پلتفرم اندروید از مفهوم سندباکسینگ برنامه برای حفظ مرزهای اجرایی و امنیتی قوی برای کد برنامه، در امتداد مرزهای فرآیند، استفاده می‌کند. این یک رویه رایج برای برنامه‌ها است که کد شخص ثالث را، اغلب به شکل SDKهایی مانند SDKهای تبلیغاتی یا SDKهای تحلیلی، در خود جای دهند. این استفاده مجدد، توسعه‌دهندگان برنامه را قادر می‌سازد تا بر تمایز برنامه خود تمرکز کنند و در عین حال از کار متخصصان موضوع برای مقیاس‌بندی اجرای خود فراتر از آنچه که به راحتی می‌توانستند به تنهایی انجام دهند، بهره ببرند.

مانند اکثر سیستم‌های عامل، در اندروید، SDKها در محیط سندباکس برنامه میزبان اجرا می‌شوند و همان امتیازات و مجوزهای برنامه میزبان خود و همچنین دسترسی به حافظه و فضای ذخیره‌سازی برنامه میزبان را به ارث می‌برند. اگرچه این معماری SDKها و برنامه‌ها را قادر می‌سازد تا به طور انعطاف‌پذیری ادغام شوند، اما پتانسیل جمع‌آوری و اشتراک‌گذاری داده‌های کاربر را نیز ایجاد می‌کند. علاوه بر این، توسعه‌دهندگان برنامه ممکن است به طور کامل از میزان عملکرد SDK شخص ثالث و داده‌هایی که به آنها دسترسی دارد، آگاه نباشند و این امر، توجیه شیوه‌های جمع‌آوری و اشتراک‌گذاری داده‌ها در برنامه آنها را چالش‌برانگیز می‌کند.

در اندروید ۱۴، ما یک قابلیت پلتفرم جدید اضافه کرده‌ایم که به SDK های شخص ثالث اجازه می‌دهد در یک محیط زمان اجرای اختصاصی به نام SDK Runtime اجرا شوند. SDK Runtime محافظت‌ها و اطمینان‌های قوی‌تری را در مورد جمع‌آوری و اشتراک‌گذاری داده‌های کاربر ارائه می‌دهد:

• یک محیط اجرایی اصلاح‌شده
• مجوزها و حقوق دسترسی به داده‌ها به خوبی تعریف شده برای SDKها

ما به طور فعال به دنبال بازخورد از جامعه تبلیغات برنامه‌های تلفن همراه در مورد این طراحی هستیم. ما همچنین از بازخورد جامعه توسعه‌دهندگان گسترده‌تر برای کمک به شکل‌دهی نسخه‌های آینده SDK Runtime، از جمله پشتیبانی از موارد استفاده بیشتر، استقبال می‌کنیم.

اهداف

این پیشنهاد در پی دستیابی به اهداف زیر است:

• کاهش دسترسی و اشتراک‌گذاری نامشخص داده‌های برنامه کاربر توسط SDKهای شخص ثالث از طریق ایزوله‌سازی فرآیند و API و کنترل دسترسی به داده‌ها با تعریف مناسب. برای کسب اطلاعات بیشتر در مورد ایزوله‌سازی فرآیند ، به بخش جداگانه‌ای از این سند مراجعه کنید.
• با محدود کردن دسترسی SDKها به شناسه‌های منحصر به فرد و پایدار، ردیابی نامشخص استفاده کاربر از برنامه را توسط SDKهای شخص ثالث کاهش دهید.
• با کاهش بار توسعه‌دهندگان برنامه و کاربران نهایی، توزیع به‌روزرسانی‌های SDK به برنامه‌ها را به طور ایمن تسریع کنید. در بخش دیگری از این سند، درباره مدل توزیع SDK قابل اعتماد پیشنهادی بیشتر بدانید.
• به توسعه‌دهندگان برنامه کمک کنید تا شیوه‌های دسترسی به داده‌ها و اشتراک‌گذاری برنامه خود را بهتر توضیح دهند.
• به توسعه‌دهندگان SDK کمک کنید تا از طریق محدود کردن برخی از ساختارهای زبانی ناامن مانند کد JNI، از دستکاری توسط سایر SDKها جلوگیری کنند.
• به SDKهای تبلیغاتی کمک کنید تا از طریق کنترل کامل بر نمایش رسانه از راه دور، ترافیک نامعتبر و کلاهبرداری تبلیغاتی را شناسایی و از آن جلوگیری کنند.
• تا حد امکان، تأثیرات نامطلوب بر توسعه‌دهندگان برنامه و SDK را به حداقل برسانید.

SDK ها در یک فرآیند ایزوله اجرا می‌شوند.

SDK Runtime پیشنهادی، SDKهای سازگار - که در ادامه این سند به عنوان SDKهای فعال‌شده در زمان اجرا (RE) به آنها اشاره می‌شود - را قادر می‌سازد تا در یک فرآیند جداگانه برای برنامه عمل کنند. این پلتفرم ارتباط دو طرفه بین فرآیند برنامه و SDK Runtime آن را تسهیل می‌کند. برای جزئیات بیشتر به بخش ارتباطات این سند مراجعه کنید. SDKهای غیر RE مانند امروز در فرآیند برنامه باقی می‌مانند. نمودارهای زیر این تغییرات را نشان می‌دهند:

مدل توزیع قابل اعتماد جدید برای SDKها

این جداسازی پیشنهادی SDK از برنامه، مفهوم جداسازی دیگری را ایجاد می‌کند، مفهومی برای توزیع SDK و برنامه. این امر مستلزم یک مکانیسم توزیع و نصب قابل اعتماد است تا اطمینان حاصل شود که SDK های صحیح در زمان اجرای SDK برنامه نصب شده‌اند.

این مکانیزم به محافظت از کاربران و توسعه‌دهندگان برنامه در برابر بارگذاری SDKهای نامعتبر کمک می‌کند، ضمن اینکه به فروشگاه‌های برنامه این امکان را می‌دهد که بار توزیع SDK را از دوش توسعه‌دهندگان برنامه به میزان قابل توجهی کاهش دهند.

دیگر نیازی نیست که SDKها قبل از آپلود شدن در اپ استور برای توزیع، به صورت ایستا به برنامه‌هایشان لینک و بسته‌بندی شوند.

این فرآیند شامل مراحل زیر است:

1. توسعه‌دهندگان SDK، SDKهای نسخه‌بندی‌شده‌ی خود را جدا از خود برنامه‌ها، در اپ‌استورها آپلود می‌کنند.
2. توسعه‌دهندگان برنامه، وابستگی‌های SDK خود را بر اساس نسخه، ساخت و آپلود نسخه‌ای از برنامه که شامل وابستگی‌های واقعی SDK نمی‌شود، مشخص می‌کنند.
3. وقتی کاربری این برنامه را دانلود می‌کند، فرآیند نصب از وابستگی‌های SDK مشخص‌شده‌ی برنامه برای دانلود آنها از اپ استور استفاده می‌کند.

این مکانیزم توزیع جدید، به‌روزرسانی‌های مستقل SDK را تحت شرایط زیر امکان‌پذیر می‌کند:

• رفع اشکالات سازگار با نسخه‌های قبلی که هیچ قابلیت جدید، API جدید، تغییری در API های موجود یا تغییرات رفتاری ایجاد نمی‌کنند.
• بهبودهای سازگار با نسخه‌های قبلی در قابلیت‌های تشخیص یا ارزیابی تقلب.

پیاده‌سازی این قابلیت‌ها وابسته به فروشگاه است.

نمودارهای زیر تغییرات پیشنهادی در توزیع SDK را نشان می‌دهند:

تغییرات در نحوه ساخت، اجرا و توزیع SDKها و برنامه‌ها

این یک پیشنهاد اولیه برای یک فناوری انعطاف‌پذیر در زمان اجرا و توزیع SDK است. بخش‌های زیر مجموعه‌ای از تغییرات را در دسته‌بندی‌های کلی زیر پیشنهاد می‌دهند:

• دسترسی : مجوزها، حافظه، ذخیره‌سازی
• اجرا : زبان‌ها، تغییرات زمان اجرا، چرخه حیات، رندر رسانه
• ارتباطات : برنامه به SDK و SDK به SDK
• توسعه : نحوه ساخت، اشکال‌زدایی و آزمایش در این مدل
• توزیع : نحوه توزیع، به‌روزرسانی و بازگرداندن نسخه‌های مختلف اندروید، برنامه‌ها و SDKها

این سند همچنین شامل سوالات متداول برای کمک به پاسخگویی به سوالات رایج است.

این یک پیشنهاد طراحی اولیه است و ما درک می‌کنیم که این ممکن است برای برخی از اعضای اکوسیستم یک تغییر معنادار باشد. به همین دلیل است که ما به طور فعال از شما بازخورد می‌خواهیم و از شما می‌خواهیم که این کار را از طریق ردیاب مشکلات انجام دهید.

دسترسی

مدیریت حریم خصوصی یک سیستم به معنای مدیریت نحوه دسترسی طرف‌های مختلف به منابع مختلف است. برای برآورده کردن ارزش پیشنهادی حریم خصوصی خود، پیشنهاد می‌کنیم مدل دسترسی به برنامه‌ها، SDKها و داده‌های کاربر را به‌روزرسانی کنید تا از اصل حداقل امتیاز پیروی شود تا از دسترسی نامشخص به داده‌های بالقوه حساس جلوگیری شود.

مجوزهای SDK

به عنوان یک فرآیند جداگانه، SDK Runtime مجموعه مجوزهای تعریف‌شده‌ی خود را خواهد داشت، نه مجوزهایی که کاربر به برنامه اعطا کرده است. بر اساس تحقیقات اولیه در مورد مجوزهای مورد استفاده توسط SDK های مرتبط با تبلیغات، پیشنهاد می‌کنیم مجوزهای زیر به طور پیش‌فرض برای SDK های موجود در SDK Runtime قابل دسترسی باشند:

• INTERNET : دسترسی به اینترنت برای برقراری ارتباط با یک سرویس وب.
• ACCESS_NETWORK_STATE : به اطلاعات مربوط به شبکه‌ها دسترسی پیدا کنید.
• READ_BASIC_PHONE_STATE : به اطلاعات مربوط به وضعیت تلفن، برای مثال نوع شبکه تلفن همراه، دسترسی پیدا می‌کند.
• مجوزهای دسترسی به APIهای حافظ حریم خصوصی ، که قابلیت‌های اصلی تبلیغات را بدون نیاز به دسترسی به شناسه‌های بین‌برنامه‌ای ارائه می‌دهند.
• AD_ID : قابلیت درخواست شناسه تبلیغاتی. این مورد نیز توسط دسترسی برنامه به این مجوز مسدود می‌شود.

ما در حال حاضر در حال بررسی این موضوع هستیم که آیا و چگونه مجوزهای اضافی را مجاز کنیم، و تأثیر آن را بر کاربران نهایی از هر دو منظر حریم خصوصی و قابلیت استفاده محدود کنیم. ما درخواست بازخورد در مورد هر مورد استفاده‌ای را داریم که ممکن است با این مجموعه مجوزها برآورده نشود.

حافظه

SDK Runtime به دلیل داشتن فرآیند خاص خود، فضای حافظه ایزوله شده خود را خواهد داشت. این ساختار به طور پیش‌فرض دسترسی SDK به فضای حافظه برنامه را مسدود می‌کند و برنامه نیز به طور مشابه قادر به دسترسی به فضای حافظه SDK نخواهد بود. ما پیشنهاد می‌کنیم این رفتار پیش‌فرض را حفظ کنید تا با اصل حداقل امتیاز همسو باشد.

ذخیره‌سازی

این پیشنهاد قصد دارد نیاز SDKها به دسترسی به فضای ذخیره‌سازی برای عملکرد عادی خود را متعادل کند و ردیابی بین برنامه‌ها و فرآیندها را با استفاده از فضای ذخیره‌سازی پایدار به حداقل برساند. ما به‌روزرسانی زیر را برای نحوه دسترسی به فضای ذخیره‌سازی امروز پیشنهاد می‌کنیم:

• یک برنامه قادر نخواهد بود مستقیماً به حافظه SDK های خود دسترسی پیدا کند و برعکس.
• حافظه خارجی دستگاه برای SDKها قابل دسترسی نخواهد بود.
• در هر SDK Runtime، هم فضای ذخیره‌سازی قابل دسترسی برای همه SDKها و هم فضای ذخیره‌سازی خصوصی برای یک SDK خاص وجود خواهد داشت.

مانند مدل ذخیره‌سازی فعلی، خودِ فضای ذخیره‌سازی محدودیت‌های دلخواهی در اندازه نخواهد داشت. SDKها می‌توانند از فضای ذخیره‌سازی برای ذخیره‌سازی داده‌ها استفاده کنند. این فضای ذخیره‌سازی به صورت دوره‌ای و زمانی که SDK به طور فعال در حال اجرا نیست، پاک می‌شود.

اعدام

برای اطمینان از وجود یک سیستم خصوصی بین برنامه‌ها، SDKها و کاربران، خودِ زمینه اجرا (قالب‌های کد، ساختارهای زبان، APIهای قابل دسترسی و داده‌های سیستم) باید این مرزهای حریم خصوصی را تقویت کند، یا حداقل فرصت‌هایی برای دور زدن آنها ایجاد نکند. در عین حال، ما می‌خواهیم دسترسی به پلتفرم غنی و اکثر قابلیت‌های زمان اجرا که SDKها در حال حاضر دارند را حفظ کنیم. در اینجا مجموعه‌ای از به‌روزرسانی‌ها را برای محیط زمان اجرا پیشنهاد می‌کنیم تا این تعادل برقرار شود.

کد

کد اندروید (اپلیکیشن‌ها و SDKها) عمدتاً توسط Android Runtime (ART) تفسیر می‌شود، چه کد با کاتلین نوشته شده باشد و چه با جاوا. غنای ART و ساختارهای زبانی که ارائه می‌دهد، همراه با قابلیت تأییدپذیری که در مقایسه با جایگزین‌ها - به ویژه کد بومی - ارائه می‌دهد، به نظر می‌رسد که به طور مناسبی بین عملکرد و حریم خصوصی تعادل برقرار می‌کند. ما پیشنهاد می‌کنیم که کد SDK با قابلیت اجرا، منحصراً از بایت‌کد Dex تشکیل شده باشد، نه اینکه از دسترسی JNI پشتیبانی کند.

ما می‌دانیم که موارد استفاده‌ای مانند استفاده از SQLite بسته‌بندی‌شده‌ی سفارشی وجود دارد که با توجه به استفاده از کد بومی، باید با جایگزینی مانند نسخه داخلی SQLite در Android SDK جایگزین شود.

SELinux

در اندروید، هر فرآیند (از جمله آن‌هایی که به عنوان root اجرا می‌شوند) با یک زمینه SELinux خاص اجرا می‌شود و به هسته اجازه می‌دهد تا کنترل دسترسی به سرویس‌های سیستم، فایل‌ها، دستگاه‌ها و سایر فرآیندها را مدیریت کند. در تلاش برای حفظ اکثر موارد استفاده SDK و در عین حال به حداقل رساندن دور زدن محافظت از حریم خصوصی که سعی در پیشبرد آن داریم، به‌روزرسانی‌های زیر را از زمینه SELinux یک برنامه غیرسیستمی برای زمان اجرای SDK پیشنهاد می‌کنیم:

• مجموعه محدودی از سرویس‌های سیستم قابل دسترسی خواهند بود. ( در طراحی فعال )
• SDKها فقط می‌توانند کد موجود در APK خود را بارگذاری و اجرا کنند.
• مجموعه محدودی از ویژگی‌های سیستم قابل دسترسی خواهد بود. ( تحت طراحی فعال )

رابط‌های برنامه‌نویسی کاربردی (API)

استفاده از بازتاب و فراخوانی APIها در زمان اجرای SDK مجاز است. با این حال، یک SDK مجاز به استفاده از بازتاب یا فراخوانی APIها در SDK دیگری که در زمان اجرا فعال است، نخواهد بود. ما در به‌روزرسانی‌های آینده، پیشنهاد کاملی از APIهای ممنوعه را به اشتراک خواهیم گذاشت.

علاوه بر این، نسخه‌های اخیر پلتفرم اندروید به منظور بهبود حریم خصوصی، دسترسی به شناسه‌های پایدار را به طور فزاینده‌ای محدود کرده‌اند. برای زمان اجرای SDK، پیشنهاد می‌کنیم دسترسی به شناسه‌هایی که می‌توانند برای ردیابی بین برنامه‌ای استفاده شوند، بیشتر محدود شود.

APIهای زمان اجرای SDK فقط از طریق برنامه‌هایی که در پس‌زمینه اجرا می‌شوند قابل دسترسی هستند. تلاش برای دسترسی به APIهای SdkSandboxManager از طریق برنامه‌هایی که در پس‌زمینه اجرا می‌شوند، منجر به صدور خطای SecurityException می‌شود.

در نهایت، RE-SDK ها نمی‌توانند از APIهای اعلان‌ها برای ارسال اعلان‌های کاربر در هر نقطه از زمان استفاده کنند.

چرخه حیات

SDK های برنامه در حال حاضر چرخه عمر برنامه میزبان خود را دنبال می‌کنند، به این معنی که وقتی برنامه وارد یا از پیش‌زمینه خارج می‌شود، خاموش می‌شود یا به دلیل فشار حافظه توسط سیستم عامل به زور متوقف می‌شود، SDK های برنامه نیز همین کار را انجام می‌دهند. پیشنهاد ما برای جداسازی SDK های یک برنامه به یک فرآیند متفاوت، تغییرات چرخه عمر زیر را نشان می‌دهد:

• این برنامه می‌تواند توسط کاربر یا سیستم عامل خاتمه یابد. SDK Runtime بلافاصله پس از آن به طور خودکار خاتمه می‌یابد.

• زمان اجرای SDK می‌تواند توسط سیستم عامل به دلیل فشار بر حافظه یا مثلاً یک استثنای مدیریت نشده در یک SDK خاتمه یابد.

  برای اندروید ۱۴، وقتی یک برنامه در پیش‌زمینه است، SDK Runtime با اولویت بالایی اجرا می‌شود و بعید است که خاتمه یابد. وقتی برنامه به پس‌زمینه می‌رود، اولویت فرآیند SDK Runtime کاهش می‌یابد و واجد شرایط خاتمه می‌شود. اولویت فرآیند SDK Runtime حتی اگر برنامه به پیش‌زمینه برگردد، پایین می‌ماند. در نتیجه، احتمال زیادی وجود دارد که در مقایسه با برنامه اصلی، تحت فشار حافظه خاتمه یابد.

  برای اندروید ۱۴ و بالاتر، اولویت‌های فرآیند برنامه و SDK Runtime همسو هستند. اولویت‌های فرآیند برای ActivityManager.RunningAppProcessInfo.importance برای برنامه و SDK Runtime باید تقریباً یکسان باشند.

  در صورتی که SDK Runtime در حین اجرای برنامه خاتمه یابد - برای مثال، اگر یک استثنای مدیریت نشده در SDK وجود داشته باشد - وضعیت SDK Runtime، شامل تمام SDK های بارگذاری شده قبلی و نماهای از راه دور، از بین می‌رود. توسعه دهنده برنامه می‌تواند با استفاده از هر یک از روش‌های زیر، خاتمه SDK Runtime را مدیریت کند:

  • این پیشنهاد، روش‌های فراخوانی چرخه حیات مرتبط را به توسعه‌دهندگان برنامه ارائه می‌دهد تا زمان خاتمه SDK Runtime را تشخیص دهند.
  • اگر زمان اجرای SDK در حین نمایش تبلیغات متوقف شود، ممکن است تبلیغات آنطور که انتظار می‌رود کار نکنند. برای مثال، ممکن است نمایش‌ها روی صفحه ثابت بمانند و دیگر تعاملی نباشند. اگر نمایش تبلیغات روی تجربه کاربر تأثیری نداشته باشد، برنامه می‌تواند آن را حذف کند.
  • این برنامه می‌تواند تلاش دیگری برای بارگیری SDKها و درخواست تبلیغات انجام دهد.
  • برای اندروید ۱۴، اگر زمان اجرای SDK در حالی که SDKها بارگذاری شده‌اند خاتمه یابد، و اگر توسعه‌دهنده برنامه، متدهای فراخوانی چرخه عمر فوق‌الذکر را ثبت نکرده باشد، برنامه به طور پیش‌فرض خاتمه می‌یابد. فقط فرآیندهای برنامه‌ای که SDKها را بارگذاری کرده‌اند، به طور عادی خاتمه یافته و خارج می‌شوند.
  • اشیاء Binder که توسط SDK برای ارتباط با آن بازگردانده می‌شوند (مانند SandboxedSdk )، در صورت استفاده توسط برنامه، DeadObjectException را صادر می‌کنند.

  این مدل چرخه عمر در به‌روزرسانی‌های آینده ممکن است تغییر کند.

  در صورت بروز خرابی‌های مداوم، توسعه‌دهنده برنامه باید برای تخریب تدریجی بدون SDK برنامه‌ریزی کند یا در صورتی که SDK برای عملکرد اصلی برنامه حیاتی است، به کاربر اطلاع دهد. برای جزئیات بیشتر در مورد این تعامل بین برنامه و SDK، به بخش ارتباطات این سند مراجعه کنید.

SDK های غیر RE می‌توانند به استفاده از اجزای اولیه استاندارد سیستم عامل موجود در برنامه تعبیه شده خود - از جمله سرویس‌ها، فعالیت‌ها و پخش‌ها - ادامه دهند، در حالی که SDK های RE نمی‌توانند.

موارد خاص

موارد زیر پشتیبانی نمی‌شوند و ممکن است رفتار غیرمنتظره‌ای ایجاد کنند:

• اگر چندین برنامه از یک UID مشترک استفاده کنند، ممکن است SDK Runtime به درستی کار نکند. پشتیبانی از UID های مشترک ممکن است در آینده اضافه شود.
• برای برنامه‌هایی که چندین فرآیند دارند، بارگذاری SDK باید در فرآیند اصلی انجام شود.

رندر رسانه‌ای

SDKهایی وجود دارند که محتوایی مانند متن، تصاویر و ویدیو را در یک نمای مشخص‌شده توسط برنامه رندر می‌کنند. برای دستیابی به این هدف، ما یک رویکرد رندر از راه دور را پیشنهاد می‌کنیم که در آن SDK رسانه را از درون SDK Runtime رندر می‌کند، اما از API SurfaceControlViewHost برای رندر رسانه در یک نمای مشخص‌شده توسط برنامه استفاده می‌کند. این امر به SDK این قابلیت را می‌دهد که این رسانه را به شیوه‌ای که برای کاربر خصوصی است رندر کند، در حالی که به جلوگیری و شناسایی تعاملات نامعتبر یا جعلی کاربر با رسانه رندر شده کمک می‌کند.

تبلیغات بومی، آن‌هایی که توسط SDK رندر نمی‌شوند و توسط برنامه نمایش داده می‌شوند، توسط SDKها در زمان اجرای SDK پشتیبانی می‌شوند. فرآیند جمع‌آوری سیگنال و دریافت خلاقانه به طور مداوم با تبلیغات غیربومی اتفاق می‌افتد. این یک حوزه فعال برای بررسی است.

تبلیغات ویدیویی درون استریم، تبلیغاتی هستند که به صورت درون استریم با یک ویدیو اجرا می‌شوند و در یک پخش‌کننده درون یک برنامه نمایش داده می‌شوند. با توجه به اینکه ویدیو درون یک پخش‌کننده درون برنامه پخش می‌شود، نه یک پخش‌کننده یا نما در SDK، مدل رندر آن با سایر قالب‌های تبلیغاتی متفاوت است. ما به طور فعال در حال بررسی مکانیسم‌هایی برای پشتیبانی از درج تبلیغ در سمت سرور و درج تبلیغ مبتنی بر SDK هستیم.

سلامت سیستم

ما به دنبال به حداقل رساندن تأثیر SDK Runtime بر سلامت سیستم بر روی دستگاه‌های کاربر نهایی هستیم و در حال طراحی روش‌هایی برای انجام این کار هستیم. با این حال، به احتمال زیاد، برخی از دستگاه‌های اندروید ۱۴ سطح پایین با منابع سیستمی بسیار محدود، مانند اندروید (نسخه Go) ، به دلیل تأثیر بر سلامت سیستم، از SDK Runtime پشتیبانی نخواهند کرد. به زودی حداقل الزامات لازم برای استفاده موفقیت‌آمیز از SDK Runtime را به اشتراک خواهیم گذاشت.

ارتباطات

از آنجایی که برنامه‌ها و SDKها در حال حاضر در یک فرآیند اجرا می‌شوند، ارتباط بین آنها بدون مانع و واسطه است. علاوه بر این، اندروید امکان ارتباط بین برنامه‌ها را حتی اگر ارتباط با SDKها شروع و پایان یابد، فراهم می‌کند. این مدل ارتباطی آزاد، موارد استفاده مختلفی را امکان‌پذیر می‌کند و در عین حال امکان اشتراک‌گذاری داده‌های فاش نشده بین برنامه‌ها و بین SDKها در داخل و بین برنامه‌ها را فراهم می‌کند. ما به‌روزرسانی‌های زیر را برای این مدل ارتباطی پیشنهاد می‌کنیم تا تعادلی بین ارزش چنین ارتباطی و تحقق اهداف تعیین‌شده خود برقرار کنیم.

تبدیل برنامه به SDK

رابط کاربری بین اپلیکیشن و SDK رایج‌ترین مسیر ارتباطی به SDK است و API یک SDK جایی است که بخش زیادی از تمایز و نوآوری در مواجهه با کاربر در آن قرار دارد. ما به دنبال حفظ توانایی SDKها برای نوآوری و تمایز در اینجا هستیم. در نتیجه، پیشنهاد ما به SDKها این قدرت را می‌دهد که APIها را در اختیار اپلیکیشن‌ها قرار دهند و اطمینان حاصل کنند که اپلیکیشن‌ها می‌توانند از تمام آن نوآوری‌ها بهره‌مند شوند.

با توجه به ساختار مرزی فرآیند SDK Runtime، پیشنهاد ما ساخت یک لایه مارشالینگ است که درون برنامه قابل دسترسی باشد تا فراخوانی‌ها و پاسخ‌ها یا فراخوانی‌های API را از این مرز بین برنامه و SDK عبور دهد. پیشنهاد ما این است که رابط کاربری این لایه مارشالینگ توسط توسعه‌دهندگان SDK تعریف و توسط ابزارهای ساخت متن‌باز رسمی که ما توسعه می‌دهیم، تولید شود.

با این پیشنهاد، ما به دنبال حذف کارهای تکراری و خسته‌کننده از دوش توسعه‌دهندگان برنامه و SDK هستیم، در حالی که انعطاف‌پذیری را برای توسعه‌دهندگان SDK فراهم می‌کنیم و اطمینان حاصل می‌کنیم که کد SDK در زمان اجرای SDK اجرا می‌شود تا اهداف حریم خصوصی ما محقق شود. اگر این مسیر را در پیش بگیریم، زبان تعریف API و ابزار آن باید با نظر شما طراحی شود.

مدل کلی تعامل به شرح زیر خواهد بود:

• برنامه از طریق رابط، SDK را فراخوانی می‌کند و callbackها را ارسال می‌کند.
• SDK به صورت ناهمگام درخواست‌ها را برآورده کرده و با استفاده از callbackها پاسخ می‌دهد.
• این را می‌توان به هر مدل ناشر-مشترک تعمیم داد، به این معنی که یک برنامه می‌تواند با فراخوانی‌های برگشتی در رویدادهای SDK مشترک شود و هنگامی که این رویدادها اتفاق می‌افتند، فراخوانی‌های برگشتی فعال می‌شوند.

یکی از پیامدهای ساختار جدید بین‌فرآیندی این پیشنهاد این است که دو چرخه حیات فرآیند وجود دارد که باید مدیریت شوند: یکی برای خود برنامه و دیگری برای زمان اجرای SDK. پیشنهاد ما به دنبال خودکارسازی هرچه بیشتر این فرآیند و به حداقل رساندن تأثیر بر توسعه‌دهندگان برنامه و SDK است. نمودار زیر رویکردی را که در نظر داریم نشان می‌دهد:

این پلتفرم APIهای جدیدی را در اختیار برنامه‌ها قرار می‌دهد تا SDKها را به صورت پویا در فرآیند SDK Runtime بارگذاری کنند، از تغییرات در وضعیت فرآیند مطلع شوند و با SDKهای بارگذاری شده در SDK Runtime تعامل داشته باشند.

نمودار شکل قبلی، ارتباط برنامه با SDK را در سطح پایین‌تری، بدون لایه مارشالینگ، نشان می‌دهد.

این برنامه از طریق مراحل زیر با SDK در حال اجرا در فرآیند SDK Runtime ارتباط برقرار می‌کند:

1. قبل از اینکه یک برنامه بتواند با یک SDK تعامل داشته باشد، برنامه از پلتفرم درخواست می‌کند که SDK را بارگذاری کند. برای اطمینان از یکپارچگی سیستم، برنامه‌ها SDKهایی را که قصد بارگذاری آنها را دارند در فایل مانیفست خود مشخص می‌کنند و این 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 برگردانده شده را از طریق API setChildSurfacePackage در SurfaceView در SurfaceView جاسازی کند.

   قطعه کد زیر یک مثال API گویا ارائه می‌دهد:

   SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
   

پیشنهاد ما این است که APIهای IBinder و requestSurfacePackage() عمومی باشند و قرار نباشد مستقیماً توسط برنامه‌ها فراخوانی شوند. در عوض، این APIها توسط مرجع API تولید شده که در بالا مورد بحث قرار گرفت، در یک لایه "shim" فراخوانی شوند تا بار توسعه‌دهندگان برنامه کاهش یابد.

SDK به SDK

دو SDK در یک برنامه اغلب نیاز به برقراری ارتباط دارند. این می‌تواند زمانی اتفاق بیفتد که یک SDK مشخص به گونه‌ای معماری شده باشد که از SDK های تشکیل دهنده تشکیل شده باشد، و می‌تواند زمانی اتفاق بیفتد که دو SDK از طرف‌های مختلف برای برآورده کردن درخواستی از برنامه فراخوانی کننده نیاز به همکاری داشته باشند.

دو مورد کلیدی وجود دارد که باید در نظر گرفته شوند:

• وقتی هر دو SDK در زمان اجرا فعال باشند . در این حالت، هر دو SDK با تمام محافظت‌های آن در SDK Runtime اجرا می‌شوند. SDKها قادر به برقراری ارتباط مانند آنچه امروزه در یک برنامه انجام می‌دهند، نیستند. در نتیجه، یک API در SdkSandboxController اضافه شده است تا امکان دریافت اشیاء SandboxedSdk را برای همه RE-SDKهای بارگذاری شده فراهم کند. این به RE-SDK اجازه می‌دهد تا با سایر SDKهای بارگذاری شده در SDK Runtime ارتباط برقرار کند.
• وقتی فقط یک SDK در زمان اجرا فعال باشد .
  • اگر SDK فراخوانی‌شده در برنامه در حال اجرا باشد، این کار تفاوتی با فراخوانی SDK دوم توسط خود برنامه در زمان اجرای SDK ندارد.
  • اگر SDK فراخوانی‌شده در زمان اجرای SDK در حال اجرا باشد، این پیشنهاد پیشنهاد می‌کند که با استفاده از IBinder که در بخش app-to-SDK توضیح داده شده است، روشی را ارائه دهید که کد موجود در برنامه به فراخوانی‌های ارائه‌شده گوش دهد، پردازش کند و پاسخ دهد.
  • SDK های تبلیغاتی که در زمان اجرا فعال نیستند، ممکن است نتوانند خود را ثبت کنند، ما ایجاد یک SDK واسطه را پیشنهاد می‌کنیم که شامل هرگونه SDK شریک یا برنامه به عنوان وابستگی‌های مستقیم برنامه باشد و ثبت را مدیریت کند. این SDK واسطه، ارتباط بین SDK های غیر فعال در زمان اجرا یا سایر وابستگی‌های برنامه و واسطه فعال در زمان اجرا را که به عنوان یک آداپتور عمل می‌کند، برقرار می‌کند.

مجموعه ویژگی‌های ارتباط SDK-SDK به دسته‌های زیر تقسیم شده است:

• ارتباط SDK-SDK در زمان اجرای SDK (در آخرین پیش‌نمایش توسعه‌دهندگان موجود است)
• ارتباط SDK-SDK بین برنامه و SDK Runtime (در آخرین پیش‌نمایش توسعه‌دهندگان موجود است)
• نحوه عملکرد نماها و رندر از راه دور برای میانجیگری (پیشنهاد در حال توسعه)

موارد استفاده زیر در حین طراحی اولیه‌ها در دست بررسی هستند:

1. میانجیگری و مناقصه . بسیاری از SDK های تبلیغاتی قابلیت میانجیگری یا مناقصه را ارائه می‌دهند که به موجب آن SDK، SDK های مختلف دیگری را برای نمایش تبلیغ (میانجیگری) یا برای جمع‌آوری سیگنال برای اجرای حراج (مناقصه) فراخوانی می‌کند. معمولاً SDK هماهنگ‌کننده، SDK های دیگر را از طریق آداپتوری که توسط SDK هماهنگ‌کننده ارائه می‌شود، فراخوانی می‌کند. با توجه به موارد اولیه فوق، SDK هماهنگ‌کننده، چه RE باشد چه نباشد، باید بتواند برای عملکرد عادی به همه SDK های RE و غیر RE دسترسی داشته باشد. رندر کردن در این زمینه، یک حوزه فعال برای بررسی است.
2. کشف ویژگی . برخی از محصولات SDK از SDKهای کوچک‌تری تشکیل شده‌اند که از طریق فرآیند کشف بین SDK، مجموعه ویژگی‌های نهایی را که در معرض توسعه‌دهنده برنامه قرار می‌گیرد، تعیین می‌کنند. انتظار می‌رود که ثبت و کشف اولیه، این مورد استفاده را فعال کند.
3. مدل‌های اشتراک ناشر . برخی از SDKها طوری طراحی شده‌اند که یک ناشر مرکزی برای رویدادها داشته باشند که SDKها یا برنامه‌های دیگر می‌توانند از طریق فراخوانی‌های برگشتی برای دریافت اعلان‌ها در آن مشترک شوند. موارد اولیه فوق باید از این مورد استفاده پشتیبانی کنند.

برنامه به برنامه

ارتباط برنامه به برنامه زمانی است که حداقل یکی از دو فرآیند در حال ارتباط، یک SDK با قابلیت اجرا در زمان اجرا باشد و یک مسیر بالقوه برای اشتراک‌گذاری داده‌های ناشناخته باشد. در نتیجه، SDK Runtime قادر به ایجاد کانال ارتباطی مستقیم با هیچ برنامه‌ای غیر از برنامه کلاینت یا با SDKهای موجود در SDK Runtime دیگری که برای برنامه دیگری ایجاد شده است، نیست. این امر به روش‌های زیر محقق می‌شود:

• SDK نمی‌تواند کامپوننت‌هایی مانند <service> ، <contentprovider> یا <activity> را در مانیفست خود تعریف کند.
• SDK نمی‌تواند یک ContentProvider منتشر کند یا یک broadcast ارسال کند.
• SDK می‌تواند یک اکتیویتی متعلق به یک برنامه‌ی دیگر را اجرا کند، اما با محدودیت‌هایی در مورد آنچه می‌تواند در Intent ارسال شود. به عنوان مثال، هیچ اقدام اضافی یا سفارشی نمی‌تواند به این Intent اضافه شود.
• SDK فقط می‌تواند یک لیست مجاز از سرویس‌ها را شروع یا به آنها متصل شود.
• SDK فقط قادر به دسترسی به زیرمجموعه‌ای از ContentProvider سیستم (مانند com.android.providers.settings.SettingsProvider ) است، که در آن داده‌های به‌دست‌آمده فاقد شناسه هستند و نمی‌توان از آن‌ها برای ساخت اثر انگشت کاربر استفاده کرد. این بررسی‌ها همچنین برای دسترسی به ContentProvider با استفاده از ContentResolver اعمال می‌شوند.
• SDK فقط قادر به دسترسی به زیرمجموعه‌ای از دریافت‌کننده‌های پخش محافظت‌شده (مانند android.intent.action.AIRPLANE_MODE ) است.

برچسب‌های مانیفست

وقتی SDK نصب می‌شود، PackageManager مانیفست SDK را تجزیه می‌کند و در صورت وجود تگ‌های مانیفست ممنوعه، نصب SDK را با شکست مواجه می‌کند. برای مثال، SDK ممکن است کامپوننت‌هایی مانند <service>, <activity>, <provider> یا <receiver> را تعریف نکند و ممکن است در مانیفست <permission> را اعلام نکند. تگ‌هایی که نصب را با شکست مواجه می‌کنند، در زمان اجرای SDK پشتیبانی نمی‌شوند. تگ‌هایی که نصب را با شکست مواجه نمی‌کنند اما به طور خاموش نادیده گرفته می‌شوند، ممکن است در نسخه‌های آینده اندروید پشتیبانی شوند.

این بررسی‌ها همچنین ممکن است توسط هر ابزار زمان ساختی که SDK برای ایجاد بسته SDK استفاده می‌کند و در زمان آپلود در فروشگاه برنامه اعمال شوند.

پشتیبانی فعالیت

SDK های موجود در محیط SDK Runtime نمی‌توانند تگ فعالیت را به فایل مانیفست خود اضافه کنند و نمی‌توانند فعالیت‌های خود را با استفاده از Context.startActivity شروع کنند. در عوض، پلتفرم در صورت درخواست، فعالیت‌های مربوط به SDK ها را ایجاد کرده و آنها را با SDK ها به اشتراک می‌گذارد.

فعالیت پلتفرم از نوع android.app.Activity است. فعالیت پلتفرم از یکی از فعالیت‌های برنامه شروع می‌شود و بخشی از وظیفه برنامه است. FLAG_ACTIVITY_NEW_TASK پشتیبانی نمی‌شود.

برای اینکه یک SDK بتواند فعالیتی را شروع کند، باید یک نمونه از نوع SdkSandboxActivityHandler ثبت کند که برای اطلاع‌رسانی در مورد ایجاد فعالیت، زمانی که برنامه SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) برای شروع فعالیت فراخوانی می‌کند، استفاده می‌شود.

روند درخواست یک فعالیت در نمودار زیر نشان داده شده است.

توسعه

یک اصل کلیدی در این پیشنهاد، به حداقل رساندن تأثیر بر اکوسیستم توسعه‌دهندگان تا حد امکان است. این پیشنهاد، مجموعه‌ای جامع از ابزارهای توسعه را برای نوشتن، ساخت و اشکال‌زدایی برنامه‌ها و SDKهای RE در اختیار توسعه‌دهندگان قرار می‌دهد. برای اطمینان از یکپارچگی این پیشنهاد، تغییراتی در نحوه پیکربندی، تألیف و ساخت برنامه‌ها و SDKهای RE ایجاد شده است.

تألیف

اندروید استودیو و ابزارهای مرتبط با آن به‌روزرسانی خواهند شد تا از SDK Runtime آگاه باشند و به توسعه‌دهندگان کمک می‌کنند تا مطمئن شوند که برنامه‌های RE و SDKهای خود را به درستی پیکربندی کرده‌اند و در صورت لزوم، فراخوانی‌های قدیمی یا پشتیبانی‌نشده به جایگزین‌های جدیدتر به‌روزرسانی می‌شوند. در طول مرحله‌ی تألیف، مراحلی وجود دارد که پیشنهاد ما از توسعه‌دهندگان می‌خواهد آنها را انجام دهند.

توسعه‌دهندگان اپلیکیشن

برنامه‌ها باید وابستگی‌های گواهی RE SDK و SDK خود را در مانیفست برنامه مشخص کنند. در پیشنهاد ما، این موضوع به عنوان منبع حقیقت از توسعه‌دهنده برنامه در سراسر این پیشنهاد در نظر گرفته شده است. به عنوان مثال:

• نام: نام بسته‌ی SDK یا کتابخانه.
• نسخه اصلی: کد نسخه اصلی SDK.
• خلاصه گواهی: خلاصه گواهی نسخه SDK. برای یک نسخه مشخص، پیشنهاد می‌کنیم توسعه‌دهنده SDK این مقدار را از طریق فروشگاه برنامه مربوطه دریافت و ثبت کند.

این فقط در مورد SDK های توزیع شده در فروشگاه برنامه، چه RE باشند و چه نباشند، صدق می‌کند. برنامه‌هایی که SDK ها را به صورت ایستا پیوند می‌دهند، از مکانیسم‌های وابستگی فعلی استفاده می‌کنند.

با توجه به هدف ما که حداقل تأثیر بر توسعه‌دهندگان است، مهم است که به محض مشخص شدن سطح API هدف که از SDK Runtime پشتیبانی می‌کند، توسعه‌دهندگان برنامه فقط به یک نسخه واحد نیاز داشته باشند، چه آن نسخه روی دستگاه‌هایی اجرا شود که از SDK Runtime پشتیبانی می‌کنند و چه نکنند.

توسعه‌دهندگان SDK

در طرح پیشنهادی ما، توسعه‌دهندگان کیت توسعه نرم‌افزار RE باید صریحاً یک عنصر جدید را که نشان‌دهنده SDK یا موجودیت کتابخانه است، در مانیفست اعلام کنند. علاوه بر این، مجموعه‌ای مشابه از مقادیر وابستگی به همراه یک نسخه فرعی باید ارائه شود:

• نام: نام بسته‌ی SDK یا کتابخانه.
• نسخه اصلی: کد نسخه اصلی SDK.
• نسخه فرعی: کد نسخه فرعی SDK.

اگر توسعه‌دهندگان RE SDK، SDKهای RE دیگری را به عنوان وابستگی‌های زمان ساخت داشته باشند، احتمالاً باید آنها را به روشی مشابه با نحوه اعلام وابستگی توسط یک توسعه‌دهنده برنامه، اعلام کنند. SDKهای RE که به SDKهای غیر RE وابسته هستند، آنها را به صورت ایستا به هم پیوند می‌دهند. این امر ممکن است مشکلاتی را ایجاد کند که در زمان ساخت یا در طول مراحل تست شناسایی می‌شوند، اگر SDKهای غیر RE به عملکردی نیاز داشته باشند که SDK Runtime از آن پشتیبانی نمی‌کند، یا اگر باید در فرآیند برنامه اجرا شود.

توسعه‌دهندگان کیت توسعه نرم‌افزار RE احتمالاً می‌خواهند پشتیبانی از دستگاه‌هایی که RE در آن‌ها فعال نیست، مانند اندروید ۱۲ یا پایین‌تر، و همانطور که در بخش سلامت سیستم سند ذکر شده است، دستگاه‌های اندروید ۱۴ سطح پایین با منابع سیستم بسیار محدود، را ادامه دهند. ما در حال بررسی رویکردهایی هستیم تا اطمینان حاصل کنیم که توسعه‌دهندگان SDK می‌توانند یک کد پایه واحد را برای پشتیبانی از محیط‌های RE و غیر RE حفظ کنند.

ساخت‌ها

توسعه‌دهندگان اپلیکیشن

ما انتظار داریم توسعه‌دهندگان برنامه در مرحله ساخت، تغییر کمی را تجربه کنند. وابستگی‌های SDK، چه به صورت محلی توزیع شده باشند و چه در فروشگاه برنامه (RE یا غیر آن)، برای linting، کامپایل و ساخت، باید روی دستگاه وجود داشته باشند. ما پیشنهاد می‌کنیم که اندروید استودیو این جزئیات را از توسعه‌دهنده برنامه در استفاده عادی جدا کند و این موضوع را تا حد امکان شفاف سازد.

Although we expect a DEBUG build would need to include all the code and symbols to be present in the DEBUG build for debuggability, RELEASE builds would optionally have all the app store-distributed SDKs (RE or not) removed from the final artifact.

We are earlier in our design phase here and will share more as it materializes.

SDK developers

We are working on a path to ensure that non-RE and RE versions of an SDK can be built into a single artifact for distribution. This would prevent app developers from needing to support separate builds for RE and non-RE versions of an SDK.

Much like for apps, any app store-distributed dependency SDKs would need to exist on the machine for linting, compilation, and builds, and we expect Android Studio should facilitate this seamlessly.

آزمایش

توسعه‌دهندگان اپلیکیشن

As described in our proposal, app developers would be able to test their apps on devices running Android 14 how they normally would. After they've built their app, the app would be able to be installed on an RE device or emulator. This installation process would ensure the correct SDKs get installed into the SDK Runtime for the device or emulator, whether the SDKs were pulled from a remote SDK repository or cache from the build system.

SDK developers

SDK developers generally use in-house test apps on devices and emulators to test their development. Our proposal doesn't change this, and in-app validation would follow the same steps as outlined for app developers above, with a single build artifact for both RE and non-RE apps. SDK developers will be able to step through their code whether it's in the SDK Runtime or not, though there may be some limitations on advanced debugging and profiling tools. This is an active area of investigation.

توزیع

The separation of an app from its SDKs has created the possibility for app store distribution of SDKs. This is a platform feature, not specific to any distribution channel.

This offers the following benefits:

• Ensure the quality and consistency of SDKs.
• Streamline publication for SDK developers.
• Expedite rollout of SDK critical patch updates to installed apps.

To support SDK distribution, a distribution channel would need to support the following capabilities:

• SDK developers can publish their SDKs to the store or platform, and perform maintenance operations.
• Ensure the integrity of SDKs, apps, and resolve their dependencies.
• Deploy SDKs onto devices in a consistently reliable and performant manner.

Evolving restrictions over time

We expect the restrictions faced by code in the SDK runtime to evolve with later versions of Android. To ensure application compatibility, we won't change these restrictions with mainline module updates for a given SDK level. Behavior associated with a given targetSdkVersion is preserved until support for that targetSdkVersion is deprecated through app store policy, and targetSdkVersion deprecation might happen at a faster cadence than for apps. Expect restrictions to change frequently across Android SDK versions, especially in the first few releases.

Additionally, we're building a canary mechanism to allow external and internal testers to join a group that gets the proposed set of restrictions for the next version of Android. This will help us get feedback and confidence on the proposed changes to the set of restrictions.

سوالات متداول

1. What is an advertising-related SDK?

   An ad-related SDK is one that facilitates any part of the targeting of users with messages for commercial ends, on apps that are not owned by the advertiser. This includes, but is not limited to, analytics SDKs where user groups can be created for subsequent targeting, ad serving SDKs, anti-abuse and anti-fraud SDKs for ads, engagement SDKs, and attribution SDKs.

2. Can any SDK run in the SDK Runtime?

   Although the initial focus is for ad-related SDKs, developers of non-ad-related SDKs that seek a pro-privacy posture and believe they can operate under the conditions outlined above can share feedback about their SDKs running in the SDK Runtime. The SDK Runtime isn't designed to be compatible with all SDK designs, however. Beyond the documented limitations, the SDK Runtime is likely unsuitable for SDKs that need real-time or high throughput communications with the hosting app.

3. Why choose process isolation instead of isolation within a process's Java-based runtime?

   Currently, the Java-based runtime doesn't readily facilitate the security boundaries necessary for the privacy assurances that are desired for Android users. Attempting to implement something like this would likely require a multi-year effort, without a guarantee of success. Therefore, the Privacy Sandbox uses use process boundaries, a time-tested and well-understood technology.

4. Would moving SDKs into the SDK Runtime process provide download size or space savings?

   If multiple apps are integrated with runtime-enabled SDKs of the same version, then this can reduce download size and disk space.

5. What kind of app lifecycle events such as when the app goes to the background, will SDKs have access to in the SDK Runtime?

   We are actively working on design support for notifying SDK runtime on app-level lifecycle events of its client application (eg app going into background, app going into foreground). Design and sample code will be shared in an upcoming developer preview.