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

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

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

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

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

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

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

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

اهداف

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

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

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

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

قبل از اضافه شدن به زمان اجرای SDK، کد فراخوانی SDK، همراه با SDKهایی که تماس‌ها را از این کد دریافت می‌کنند، همه در فرآیند برنامه قرار دارند.

---

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

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

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

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

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

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

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

قبل از معرفی SDK Runtime، توسعه دهندگان SDK های خود را مستقیماً به برنامه ها ارسال می کنند.

---

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

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

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

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

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

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

دسترسی داشته باشید

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

مجوزهای SDK

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

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

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

حافظه

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

ذخیره سازی

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

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

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

اعدام

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

کد

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

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

SELinux

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

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

API ها

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

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

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

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

چرخه زندگی

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

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

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

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

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

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

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

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

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

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

موارد خاص

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

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

رندر رسانه ای

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

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

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

سلامت سیستم

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

ارتباطات

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

برنامه به SDK

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

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

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

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

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

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

نمودار ترتیبی که تعاملات برنامه به SDK را در حین راه اندازی برنامه و SDK نشان می دهد.

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

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

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

1. قبل از اینکه یک برنامه بتواند با یک 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 برگشتی را از طریق setChildSurfacePackage API در SurfaceView در SurfaceView جاسازی کند.

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

   SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
   

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

SDK به SDK

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

دو مورد کلیدی برای بررسی وجود دارد:

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

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

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

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

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

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

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

• SDK نمی‌تواند مؤلفه‌هایی مانند <service> ، <contentprovider> ، یا <activity> را در مانیفست خود تعریف کند.
• SDK نمی‌تواند یک ContentProvider منتشر کند یا یک پخش ارسال کند.
• 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 پشتیبانی نمی شود.

توجه: شیء Activity ارسال شده توسط پلتفرم از نوع android.app.Activity است که با androidx مانند appcompat یا Compose عناصر سازگار نیست.

توجه: Context Activity ارائه شده نباید توسط SDK ها استفاده شود، و در عوض SDK باید از SandboxedSdkProvider#getContext() برای واکشی Context مناسب استفاده کند.

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

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

نمودار توالی که جریان شروع یک فعالیت را نشان می دهد.

توسعه

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

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

تالیف

Android Studio و ابزارهای مربوطه به‌روزرسانی می‌شوند تا SDK Runtime-aware باشند و به توسعه‌دهندگان کمک می‌کنند تا برنامه‌ها و SDK‌های RE خود را به درستی پیکربندی کرده‌اند و اطمینان حاصل شود که تماس‌های قدیمی یا پشتیبانی‌نشده به جایگزین‌های جدیدتر در صورت لزوم به‌روزرسانی می‌شوند. در طول مرحله نگارش، مراحلی وجود دارد که پیشنهاد ما به توسعه دهندگان نیاز دارد.

توسعه دهندگان برنامه

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

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

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

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

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

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

• نام: نام بسته SDK یا کتابخانه.
• نسخه اصلی: کد نسخه اصلی SDK.
• نسخه کوچک: کد نسخه کوچک SDK.

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

توسعه‌دهندگان RE SDK احتمالاً می‌خواهند به پشتیبانی از دستگاه‌های غیرفعال RE، مانند Android 12 یا پایین‌تر و همانطور که در بخش System Health سند اشاره شد، دستگاه‌های Android 14 سطح مبتدی با منابع سیستمی بسیار محدود، ادامه دهند. ما از طریق رویکردهایی کار می کنیم تا اطمینان حاصل کنیم که توسعه دهندگان SDK می توانند یک پایه کد واحد را برای پشتیبانی از محیط های RE و غیر RE حفظ کنند.

می سازد

توسعه دهندگان برنامه

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

اگرچه ما انتظار داریم ساخت اشکال زدایی شامل تمام کد و نمادها برای ایجاد اشکال زدایی برای اشکال زدایی باشد ، اما ساختهای انتشار به صورت اختیاری تمام SDK های توزیع شده در فروشگاه (دوباره یا نه) را از آثار نهایی حذف می کنند.

ما در مرحله طراحی خود در اینجا هستیم و همانطور که تحقق می یابد ، بیشتر به اشتراک خواهیم گذاشت.

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

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

تقریباً مانند برنامه ها ، هر SDK وابستگی توزیع شده در فروشگاه برنامه لازم است که برای لینت ، تدوین و ساخت در دستگاه وجود داشته باشد ، و انتظار داریم استودیو اندرویدی باید این یکپارچه را تسهیل کند.

تست کردن

توسعه دهندگان برنامه

همانطور که در پیشنهاد ما توضیح داده شده است ، توسعه دهندگان برنامه می توانند برنامه های خود را بر روی دستگاه هایی که Android 14 را اجرا می کنند ، آزمایش کنند. پس از ساخت برنامه خود ، برنامه می تواند بر روی دستگاه RE یا شبیه ساز نصب شود. این فرآیند نصب باعث می شود SDK های صحیح در زمان اجرا SDK برای دستگاه یا شبیه ساز نصب شوند ، خواه SDK ها از یک مخزن SDK از راه دور یا حافظه نهان از سیستم ساخت خارج شوند.

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

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

توزیع

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

• از کیفیت و قوام SDK ها اطمینان حاصل کنید.
• انتشار ساده برای توسعه دهندگان SDK.
• Expedite Rollout از به روزرسانی های نسخه جزئی SDK به برنامه های نصب شده.

به منظور پشتیبانی از توزیع SDK ، یک فروشگاه App به احتمال زیاد باید بیشتر قابلیت های زیر را ارائه دهد:

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

محدودیت های در حال تحول در طول زمان

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

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

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

1. SDK مربوط به تبلیغات چیست؟

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

2. آیا هر SDK می تواند در زمان اجرا SDK اجرا شود؟

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

3. چرا به جای انزوا در زمان اجرا مبتنی بر جاوا ، انزوای فرآیند را انتخاب کنید؟

   در حال حاضر ، زمان اجرا مبتنی بر جاوا به راحتی مرزهای امنیتی لازم برای اطمینان از حریم خصوصی را که برای کاربران Android مورد نظر است ، تسهیل نمی کند. تلاش برای اجرای چیزی از این دست ، بدون ضمانت موفقیت ، نیاز به تلاش چند ساله دارد. بنابراین ، ماسهبازی حریم خصوصی از مرزهای فرآیند ، یک فناوری آزمایش شده و به خوبی فهمیده استفاده می کند.

4. آیا انتقال SDK ها به فرآیند زمان اجرا SDK اندازه بارگیری یا صرفه جویی در فضا را ارائه می دهد؟

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

5. چه نوع رویدادهای چرخه عمر برنامه مانند وقتی برنامه به پس زمینه می رود ، آیا SDK ها در زمان اجرا SDK به آن دسترسی دارند؟

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

{٪ کلمه ٪} {٪ EndverBatim ٪} ،

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

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

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

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

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

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

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

اهداف

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

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

SDK ها در یک فرآیند جدا شده اجرا می شوند

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

قبل از اضافه شدن به زمان اجرا SDK ، کد CALLING SDK ، به همراه SDK هایی که تماس های این کد را دریافت می کنند ، همه در فرایند برنامه ساکن هستند

---

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

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

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

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

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

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

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

قبل از معرفی زمان اجرا SDK ، توسعه دهندگان SDK های خود را مستقیماً به برنامه ها ارسال می کنند.

---

پس از معرفی SDK Runtime ، D ، توسعه دهندگان SDK از UI بارگذاری SDK برای انتشار SDK های خود در یک فروشگاه App استفاده می کنند. فروشگاه App سپس توزیع برنامه ها ، به همراه هرگونه وابستگی SDK ، به دستگاه های کاربر نهایی را اداره می کند.

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

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

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

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

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

دسترسی داشته باشید

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

مجوزهای SDK

به عنوان یک فرآیند جداگانه ، زمان اجرا SDK مجموعه مجوزهای تعریف شده خود را به جای اینکه مواردی را که کاربر به برنامه اعطا کرده است به ارث می برد. بر اساس تحقیقات اولیه در مورد مجوزهای مورد استفاده SDK های مربوط به ADS ، ما پیشنهاد می کنیم که مجوزهای زیر به طور پیش فرض در زمان اجرا 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 (برنامه ها و SDK ها) عمدتاً توسط Android Runtime (ART) تفسیر می شود ، خواه کد در کوتلین یا جاوا نوشته شده باشد. غنای هنر و ساختارهای زبانی که ارائه می دهد ، همراه با تأییدیه ای که در مقایسه با گزینه های جایگزین - در کد خاص بومی - به نظر می رسد مناسب باشد تا بتواند عملکرد و حریم خصوصی را به طور مناسب تعادل برقرار کند. ما پیشنهاد می کنیم که کد SDK با قابلیت اجرا به طور انحصاری از Bytecode DEX تشکیل شود ، نه اینکه از دسترسی JNI پشتیبانی کند.

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

SELinux

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

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

API ها

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

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

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

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

چرخه زندگی

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

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

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

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

  برای اندروید 14 و بعد ، اولویت های فرآیند برنامه و زمان اجرا SDK تراز شده است. اولویت های فرآیند برای ActivityManager.RunningAppProcessInfo.importance برای برنامه و زمان اجرا SDK باید تقریباً یکسان باشد.

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

  • این پیشنهاد روشهای مربوط به پاسخ به چرخه عمر مربوط به برنامه نویسان را برای تشخیص زمان خاتمه زمان اجرای SDK ارائه می دهد.
  • اگر زمان اجرا SDK هنگام نمایش تبلیغات خاتمه یابد ، ممکن است تبلیغات مطابق آنچه انتظار می رود کار نکنند. به عنوان مثال ، نمایش ها ممکن است روی صفحه منجمد شوند و دیگر تعاملی نباشند. در صورت عدم تأثیرگذاری بر تجربه کاربر ، برنامه می تواند نمای تبلیغ را حذف کند.
  • برنامه می تواند تلاش دیگری برای بارگیری SDK ها و درخواست تبلیغات انجام دهد.
  • برای Android 14 ، اگر زمان اجرا SDK در حالی که SDK بارگیری شده است خاتمه یابد ، و اگر توسعه دهنده برنامه روشهای پاسخ به پاسخ به چرخه عمر فوق الذکر را ثبت نکرده باشد ، برنامه به طور پیش فرض خاتمه می یابد. فقط فرآیندهای برنامه که SDK ها را بارگیری کرده و به طور عادی از آن خارج می شوند.
  • اشیاء چسبانیده شده توسط 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 در دستگاه های کاربر نهایی هستیم و در حال طراحی راه هایی برای انجام این کار هستیم. به احتمال زیاد ، برخی از دستگاه های اندرویدی 14 سطح ورودی با منابع سیستم بسیار محدود مانند Android (GO Edition) به دلیل تأثیر سلامت سیستم از زمان اجرا SDK پشتیبانی نمی کنند. ما به زودی حداقل نیازهای لازم را برای استفاده موفقیت آمیز از زمان اجرا SDK به اشتراک خواهیم گذاشت.

ارتباطات

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

برنامه به SDK

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

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

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

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

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

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

نمودار توالی که تعامل برنامه به SDK را در طول راه اندازی برنامه و SDK نشان می دهد.

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

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

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

1. قبل از اینکه یک برنامه بتواند با 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 با تمام محافظت های خود در حال اجرا هستند. SDK ها قادر به برقراری ارتباط مانند امروز در یک برنامه نیستند. در نتیجه ، یک API در SdkSandboxController اضافه شده است تا بتواند اشیاء SandboxedSdk را برای همه SDK های بارگذاری شده بارگیری کند. این به یک SDK اجازه می دهد تا با سایر SDK های بارگذاری شده در زمان اجرا SDK ارتباط برقرار کند.
• هنگامی که فقط یک SDK فعال است .
  • اگر SDK Calling در برنامه اجرا شود ، این کار متفاوت از خود برنامه است که به SDK دوم در زمان اجرا SDK می رود.
  • اگر SDK فراخوانی در زمان اجرا SDK در حال اجرا است ، این پیشنهاد توصیه می کند با استفاده از IBinder که در بخش برنامه به SDK شرح داده شده است ، که کد موجود در برنامه را گوش می دهد ، فرایندها را گوش می دهد و با تماس های ارائه شده پاسخ می دهد.
  • SDK های AD که دارای زمان اجرا نیستند ممکن است قادر به ثبت نام خود نباشند ، ما پیشنهاد ایجاد یک SDK واسطه ای را ارائه می دهیم که شامل هر یک از SDK های شریک یا برنامه به عنوان وابستگی مستقیم برنامه و ثبت نام است. این واسطه SDK ارتباط بین SDK های غیر اجرا شده با زمان اجرا یا سایر وابستگی های برنامه و واسطه فعال شده زمان اجرا را به عنوان آداپتور برقرار می کند.

ویژگی تنظیم شده برای ارتباطات SDK-SDK به دسته های زیر تقسیم شده است:

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

موارد استفاده زیر در حالی که بدوی ها طراحی می شوند مورد بررسی قرار می گیرند:

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

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

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

• SDK نمی تواند مؤلفه هایی مانند <service> ، <contentprovider> یا <activity> را در آشکار خود تعریف کند.
• SDK نمی تواند یک ContentProvider منتشر کند یا پخش را ارسال کند.
• SDK می تواند فعالیتی متعلق به برنامه دیگر را آغاز کند ، اما با محدودیت هایی که می تواند در این هدف ارسال شود. به عنوان مثال ، هیچ اقدام اضافی یا سفارشی نمی تواند به این هدف اضافه شود.
• SDK فقط می تواند به لیست اجازه خدمات شروع یا متصل شود.
• The SDK is only able to access a subset of the system ContentProvider (such as com.android.providers.settings.SettingsProvider ), where obtained data lacks identifiers and can't be used to build a fingerprint of the user. These checks also apply to accessing ContentProvider using ContentResolver .
• The SDK is only able to access a subset of protected broadcast receivers (such as android.intent.action.AIRPLANE_MODE ).

Manifest tags

When the SDK is installed, PackageManager parses the SDK's manifest and fails to install the SDK if banned manifest tags are present. For example, the SDK may not define components like <service>, <activity>, <provider> , or <receiver> and may not declare a <permission> in the manifest. Tags that fail installation are not supported in the SDK Runtime. Tags that don't fail installation but are silently ignored may be supported in future Android versions.

These checks might also be applied by any build time tools the SDK uses to create the SDK bundle, and at the time of uploading to the application store.

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

SDKs in the SDK Runtime environment can't add an activity tag to their manifest file and can't start their own activities using Context.startActivity . Instead, the platform creates the activities for the SDKs when requested and shares them with SDKs.

The platform activity is of type android.app.Activity . The platform activity starts from one of the app's activities and is part of the app task. FLAG_ACTIVITY_NEW_TASK is not supported.

Note: The Activity object passed by the platform is of type android.app.Activity which isn't compatible with androidx like appcompat or Compose elements.

Note: The provided Activity 's Context must not be used by SDKs, and instead SDK should use SandboxedSdkProvider#getContext() to fetch the proper Context .

For an SDK to start activity, it should register an instance of type SdkSandboxActivityHandler which is used to notify about activity creation when the app calls SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) to start the activity.

The flow of requesting an activity is shown in the following graph.

Sequence diagram that shows the flow of starting an activity.

توسعه

A key principle in this proposal is minimizing the impact to the developer ecosystem to the extent possible. This proposal offers developers a comprehensive set of development tools to write, build, debug RE apps and SDKs. To ensure the integrity of this proposal, there are some changes to how RE apps and SDKs are configured, authored, and built.

Note: This section is very early in its design phase, so fewer details have been explored and much could change. The goal is to share our intention based on what we currently believe is possible, to get your feedback early.

تالیف

Android Studio and related tooling will be updated to be SDK Runtime-aware, helping ensure that developers have correctly configured their RE apps and SDKs, and ensuring that legacy or unsupported calls are updated to their newer alternatives where relevant. During the authoring phase, there are some steps our proposal would require developers to take.

توسعه دهندگان برنامه

Apps would need to specify their RE SDK and SDK certificate dependencies in their app manifest. In our proposal we treat this as the source of truth from the application developer throughout this proposal. به عنوان مثال:

• Name: Package name of the SDK or library.
• Major version: Major version code of the SDK.
• Certificate digest: The certificate digest of the SDK build. For a given build, we propose the SDK developer obtain and register this value through the relevant app store.

This applies to app store-distributed SDKs only, whether RE or not. Apps statically linking SDKs would use current dependency mechanisms.

Given our goal of minimal impact to developers, it is important that once a target API level supporting the SDK Runtime is specified, app developers only ever need to have a single build whether that build runs on devices that do or do not support the SDK Runtime .

SDK developers

In our proposed design, RE SDK developers need to explicitly declare a new element representing the SDK or library entity in the manifest. Additionally, a similar set of values as the dependency would need to be provided plus a minor version:

• Name: Package name of the SDK or library.
• Major version: Major version code of the SDK.
• Minor version: Minor version code of the SDK.

Should RE SDK developers have other RE SDKs as build-time dependencies, they will likely need to declare them in a manner identical to how an app developer would declare the same dependency. RE SDKs depending on non-RE SDKs would statically link them. This may introduce issues that would be detected at build time or during test passes if the non-RE SDKs require functionality the SDK Runtime does not support, or if it must run in the app's process.

RE SDK developers will likely want to continue support for non-RE-enabled devices, such as Android 12 or lower and as mentioned in the System Health section of the document, entry-level Android 14 devices with very limited system resources. We are working through approaches to ensure SDK developers can retain a single code-base to support RE and non-RE environments.

می سازد

توسعه دهندگان برنامه

We expect app developers would experience little change in the build step. SDK dependencies, whether locally distributed or app store-distributed (RE or not), would need to exist on the machine for linting, compilation, and builds. We are proposing that Android Studio abstract these details from the app developer with normal usage and make this as transparent as possible.

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.

توزیع

Our design proposal for the separation of an app from its SDKs has created the possibility for app store distribution of SDKs. This is a general possibility, not unique to any particular app store. مزایا واضح است:

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

In order to support SDK distribution, an app store would likely need to provide most of the following capabilities:

• A mechanism for SDK developers to upload their app store-distributable SDKs to the store, update them, roll them back and possibly remove them.
• A mechanism to ensure the integrity of an SDK and its provenance, and an app and its provenance, and resolve their dependencies.
• A mechanism to deploy them 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.

{% verbatim %} {% endverbatim %} ,

Note: This document reflects the Privacy Sandbox on Android's current design proposals and is subject to further change. We encourage your feedback and comments to assist in these efforts.

The Android platform uses the concept of app sandboxing to maintain robust execution and security boundaries for app code, along process boundaries. It's a common practice for apps to include third-party code, often in the form of SDKs such as ads SDKs or analytics SDKs. This reuse enables app developers to focus on their app's differentiation while leveraging the work of subject matter experts to scale their execution beyond what they could easily do on their own.

Like most operating systems, in Android SDKs are executed within the host app's sandbox, and inherit the same privileges and permissions of their host app as well as access to the host app's memory and storage. While this architecture enables SDKs and apps to flexibly integrate, it also creates the potential for undisclosed user data collection and sharing. Moreover, app developers may not be fully aware of the extent of a third-party SDK's functionality and the data it accesses, making it challenging to account for the data collection and sharing practices of their app.

In Android 14, we have added a new platform capability that allows third-party SDKs to run in a dedicated runtime environment called the SDK Runtime . The SDK Runtime provides the following stronger safeguards and assurances around user data collection and sharing:

• A modified execution environment
• Well-defined permissions and data access rights for SDKs

Note: For the first version of the SDK Runtime, we are focused on supporting advertising-related SDKs, including SDKs which enable ad serving, ads measurement, ads fraud, and abuse detection. Advertising-related SDKs are described later in this document.

We're actively seeking feedback from the mobile app advertising community on this design. We also welcome feedback from the broader developer community to help shape future iterations of the SDK Runtime, including support for additional use cases.

اهداف

This proposal seeks to achieve the following goals:

• Reduce undisclosed access and sharing of a user's app data by third-party SDKs through process isolation and well-defined API and data access control. Learn more about process isolation in a separate section of this document.
• Reduce undisclosed tracking of a user's app usage by third-party SDKs by limiting unique, persistent identifiers from being accessed by SDKs.
• Securely accelerate the distribution of SDK updates to apps by reducing the burden on app developers and end users. Learn more about the proposed trusted SDK distribution model in another section of this document.
• Help app developers better account for the data access and sharing practices of their app.
• Help SDK developers prevent tampering by other SDKs through the limiting of certain unsafe language constructs such as JNI code.
• Help ads SDKs detect and prevent invalid traffic and ad fraud through full control over the remote views displaying media.
• Minimize undue impact to app and SDK developers as much as possible.

SDKs execute in an isolated process

The proposed SDK Runtime enables compatible SDKs—referred to throughout the remainder of this document as runtime-enabled (RE) SDKs —to operate in a separate process for the app. The platform facilitates bi-directional communication between the app's process and its SDK Runtime. See the communications section of this document for detail. Non-RE SDKs would remain in the app's process as they do today. The following diagrams illustrate these changes:

Before being added to the SDK Runtime the SDK-calling code, along with the SDKs that receive the calls from this code, all reside in the app's process

---

After being added to the SDK Runtime the SDK-calling code, in the app's foreground process, the SDK calling code communicates with SDK interfaces. These interfaces then cross a process boundary into the SDK Runtime process to call into the SDKs themselves.

New trusted distribution model for SDKs

This proposed separation of SDK from app motivates another separation concept, one for SDK and app distribution. Our proposal requires a trusted distribution and installation mechanism, to ensure the correct SDKs are installed in an app's SDK Runtime. This helps protect users and app developers from invalid SDKs being loaded, while enabling app stores to significantly reduce the burden of SDK distribution from app developers.

SDKs would no longer need to be statically linked and packaged together with their apps before being uploaded to an app store for distribution. The following process would occur instead:

1. SDK developers could upload their versioned SDKs to the app stores, separate from the apps themselves.
2. App developers could specify their SDK dependencies by version, build, and upload an app release that doesn't include the actual SDK dependencies.
3. When a user downloads this app, the installation process could use the app's specified SDK dependencies to then download them from the app store.

This novel distribution mechanism would enable SDK developers to make non-breaking changes (that is, no changes to APIs or their semantics) to their SDKs and distribute to devices without any involvement from app developers. These non-breaking SDK changes could be deployed or rolled back, without necessarily needing to wait for app developers to rebuild their apps with the new SDKs, or waiting for end users to update their apps. Breaking changes would still need to be updated by app developers, but SDK developers could get their latest non-breaking changes and fixes out more quickly and more uniformly to more people, ideally minimizing version support.

The following diagrams illustrate the proposed changes in SDK distribution:

Before the introduction of the SDK Runtime, developers send their SDKs directly to apps.

---

After the introduction of the SDK Runtime, d, the SDK developers would use an SDK upload UI to publish their SDKs to an app store. The app store would then handle the distribution of apps, along with any SDK dependencies, to end-user devices.

Changes to how SDKs and apps are built, run, and distributed

This is an initial proposal for a flexible SDK Runtime and distribution technology. The following sections propose a series of changes across the following broad categories:

• Access : Permissions, memory, storage
• Execution : Languages, runtime changes, lifecycle, media rendering
• Communications : App-to-SDK and SDK-to-SDK
• Development : How to build, debug, test in this model
• Distribution : How to distribute, update, roll back across versions of Android, apps and SDKs

This document also includes an FAQ to help address common questions.

This is an initial design proposal, and we understand this may be a meaningful change for some members of the ecosystem. This is why we are actively soliciting your feedback and ask that you do so through the issue tracker .

دسترسی داشته باشید

Managing the privacy of a system implies managing how different parties can access different resources. To meet our privacy value proposition we propose updating the model for accessing apps, SDKs, and user data to follow the principle of least privilege to prevent undisclosed access of potentially sensitive data.

SDK permissions

As a separate process, the SDK Runtime would have its own well-defined set of permissions, rather than inherit those that the user granted the app. Based on preliminary research on the permissions used by ads-related SDKs, we're proposing that the following permissions would be accessible to SDKs in the SDK Runtime by default:

• INTERNET : Access to the internet to be able to communicate with a web service.
• ACCESS_NETWORK_STATE : Access information about networks.
• READ_BASIC_PHONE_STATE : Access information about the phone state, for example mobile network type.
• Permissions to access the privacy-preserving APIs , which provide core advertising capabilities without needing access to cross-app identifiers.
• AD_ID : Ability to request the advertising ID. This would also be gated by the app's access to this permission.

We are currently investigating whether and how to authorize additional permissions, limiting the impact on end users from both a privacy and a usability perspective. We request feedback on any use cases that may not be met by this set of permissions.

حافظه

The SDK Runtime would have its own isolated memory space by virtue of having its own process. This structure by default would deny the SDK access to the app's memory space, and the application would similarly not be able to access the SDK's memory space. We propose keeping this default behavior to keep aligned with the principle of least privilege.

ذخیره سازی

This proposal intends to balance the need for SDKs to access storage for their normal operation and minimize cross-app and across-process tracking using persistent storage. We are proposing the following update to how storage is accessed today:

• An app won't be able to directly access its SDKs storage, and vice versa.
• The device's external storage won't be accessible to SDKs.
• Within each SDK Runtime, there would be both storage accessible to all SDKs, and storage that's private to a given SDK.

Like the current storage model, the storage itself won't have arbitrary limits in size. SDKs can use storage for caching assets. This storage is periodically cleared when the SDK is not actively running.

اعدام

To ensure a private system between apps, SDKs, and users, the execution context itself (code formats, language constructs, accessible APIs, and system data) needs to reinforce these privacy boundaries, or at the very least not introduce opportunities to circumvent them. At the same time, we want to preserve access to the rich platform and the majority of runtime capabilities that SDKs currently have. Here we propose a set of updates to the runtime environment to strike this balance.

کد

Android code (apps and SDKs) is predominantly interpreted by the Android Runtime (ART), whether the code was written in Kotlin or Java. The richness of the ART and the language constructs it offers, coupled with the verifiability it offers when compared with alternatives—in particular native code—seems to appropriately balance functionality and privacy. We propose that runtime-enabled SDK code consist exclusively of Dex bytecode, rather than support JNI access.

We are aware that there are use cases, such as the use of custom packaged SQLite, which, given the use of native code, will need to be replaced with an alternative such as the Android SDK's built-in version of SQLite.

SELinux

On Android, each process (including those running as root) runs with a specific SELinux context, allowing the kernel to manage access control to system services, files, devices, and other processes. In seeking to preserve the majority of SDK use cases while minimizing circumvention of the privacy protections we are trying to move forward, we are proposing the following updates from a non-system app's SELinux context for the SDK Runtime:

• A limited set of system services would be accessible. ( under active design )
• SDKs would only be able to load and execute the code in their APK.
• A limited set of system properties would be accessible. ( under active design )

API ها

The use of reflection and invoking APIs within the SDK runtime is allowed. However, an SDK will not be allowed to use reflection or invoke APIs on another runtime-enabled SDK. We will share a full proposal of prohibited APIs in a future update.

In addition, recent Android platform releases have increasingly restricted access to persistent identifiers in order to improve privacy. For the SDK Runtime we propose further limiting access to identifiers which could be used for cross-app tracking.

SDK Runtime APIs are only accessible from apps running in the foreground. Attempting to access SdkSandboxManager APIs from apps in the background results in a SecurityException being thrown.

Lastly, RE-SDKs can't use the notifications APIs to send user notifications at any point in time.

چرخه زندگی

App SDKs currently follow the lifecycle of their host app, meaning when the app enters or leaves the foreground, shuts down, or gets force-stopped by the operating system due to memory pressure, the app's SDKs do so as well. Our proposal to separate an app's SDKs into a different process implies the following lifecycle changes:

• The app can be terminated by the user or the operating system. The SDK Runtime would automatically terminate immediately after.

• The SDK Runtime can be terminated by the operating system due to memory pressure, or an unhandled exception in an SDK for example.

  For Android 14, when an app is in the foreground, the SDK Runtime runs in a high priority and is unlikely to get terminated. When the app goes to the background, the priority of the SDK Runtime process lowers and it becomes eligible for termination. The priority of the SDK Runtime process remains low even if the app comes back to the foreground. Consequently, it is very likely that it would be terminated under memory pressure compared to the app.

  For Android 14 and later, the process priorities of the app and the SDK Runtime are aligned. Process priorities for ActivityManager.RunningAppProcessInfo.importance for the app and the SDK Runtime should be roughly the same.

  In the case that the SDK Runtime terminates while the app is alive—for example, if there's an unhandled exception in the SDK—the SDK Runtime state, including all previously loaded SDKs and remote views, is lost. The app developer can deal with SDK Runtime termination using any of the following methods:

  • The proposal offers related lifecycle callback methods to app developers to detect when termination of the SDK Runtime has occurred.
  • If the SDK Runtime terminates while ads are being displayed, ads might not work as expected. For example, views might be frozen on screen and be no longer interactive. The app can remove the ad view if it does not affect user experience.
  • The app can make another attempt to load SDKs and request ads.
  • For Android 14, if the SDK Runtime terminates while it has SDKs loaded, and if the app developer has not registered the aforementioned lifecycle callback methods, the app terminates by default. Only the app processes that have loaded SDKs terminate and exit normally.
  • Binder objects returned by the SDK to communicate with it (such as SandboxedSdk ) throw a DeadObjectException if used by the app.

  This lifecycle model is subject to change in future updates.

  In the case of persistent failures, the app developer should plan for graceful degradation without the SDK or notify the user if the SDK is crucial to the app's core functionality. For further detail on this app-to-SDK interaction, see the communications section of this document.

Non-RE SDKs can continue to use standard OS primitives available to their embedded app—including services, activities, and broadcasts—whereas RE SDKs cannot.

موارد خاص

The following cases are unsupported, and might yield unexpected behavior:

• If multiple apps share the same UID, the SDK Runtime might not function properly. Support for shared UIDs might be added in the future.
• For apps with multiple processes, loading the SDK should be done in the main process.

Media rendering

There are SDKs that render content such as text, images, and video in an app-specified view. To accomplish this we propose a remote-rendering approach where the SDK will render the media from within the SDK Runtime, but use the SurfaceControlViewHost API to allow for the media to render in an app-specified view. This offers the SDK the capability to render this media in a manner that is private for the user, while helping prevent and detect invalid or fraudulent user interactions with the rendered media.

Native ads, those that are not rendered by the SDK but instead by the app, would be supported by SDKs in the SDK Runtime. The signal gathering and creative fetching process would happen consistently with non-native ads. This is an active area of investigation.

In-stream video ads are those that run instream with a video, shown in a player within an app. Given that the video plays within a player in the app, rather than a player or view in the SDK, the rendering model differs from other ad formats. We are actively exploring mechanisms to support both server-side ad insertion and SDK-based ad insertion.

سلامت سیستم

We seek to minimize the system health impact the SDK Runtime has on end-user devices, and are designing ways to do so. Most likely however, some entry-level Android 14 devices with very limited system resources, such as Android (Go edition) , will not support the SDK Runtime due to the system health impact. We will soon share the minimum requirements necessary to successfully use the SDK Runtime.

ارتباطات

Since apps and SDKs currently run in the same process, communication between them is uninhibited and unmediated. In addition, Android allows for inter-app communication even if the communication starts and ends with SDKs. This free-flowing communication model enables various use cases while at the same time introducing the possibility for undisclosed data sharing between apps and between SDKs within and between apps. We are proposing the following updates to this communication model seeking to strike a balance between the value of such communication and the realization of our stated goals.

App-to-SDK

The interface between the app and the SDK is the most common communication path to an SDK, and an SDK's API is where much of the user-facing differentiation and innovation reside. We seek to preserve SDKs' ability to innovate and differentiate here. Consequently, our proposal empowers SDKs to expose APIs to apps, and ensure that apps can benefit from all of that innovation.

Given the process boundary structure of the SDK Runtime, we are proposing to build a marshaling layer, accessible within the app, to carry the API calls and responses or callbacks across this boundary between the app and the SDK. We are proposing that the interface to this marshaling layer would be defined by SDK developers, and generated by official open-source build tools that we would develop.

With this proposal we seek to remove the boilerplate marshaling work from app and SDK developers, while providing flexibility for SDK developers and ensuring that SDK code runs in the SDK Runtime to realize our privacy goals. Should we take this path, the API definition language and tooling would need to be designed with your input.

The general interaction model would be as follows:

• App calls the SDK through the interface, passing in callbacks.
• SDK asynchronously satisfies the requests and responds using the callbacks.
• This can be generalized to any publisher-subscriber model, meaning an app can subscribe to events in the SDK with callbacks, and when these events happen, the callbacks would be triggered.

A consequence of the new cross-process structure of this proposal is that there are two process lifecycles that would need to be managed: one for the app itself and the other for the SDK Runtime. Our proposal seeks to automate as much of this as possible, minimizing impact to app and SDK developers. The following diagram shows an approach we're considering:

Sequence diagram that shows the app-to-SDK interactions during app and SDK startup.

The platform would expose new APIs for apps to dynamically load SDKs into the SDK Runtime process, get notified about changes to the state of the process, and interact with SDKs loaded into the SDK Runtime.

The graph in the previous figure demonstrates app-to-SDK communication at a lower level, without the marshaling layer.

The app communicates with SDK running in the SDK Runtime process through the following steps:

1. Before an app could interact with an SDK, the app would request that the platform load the SDK. To ensure the integrity of the system, apps would specify the SDKs they intend to load in their manifest file, and these SDKs would be the only ones allowed to be loaded.

   The following code snippet provides an illustrative API example:

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

2. The SDK gets notified that it's been loaded and it returns its interface. This interface is meant to be used by the app process. To share the interface outside the process boundary, it has to be returned as an IBinder object.

   The bound services guide provides different ways to provide IBinder . Whichever way you choose, it must be consistent between the SDK and the caller app. The diagrams uses AIDL as an example.

3. The SdkSandboxManager receives the IBinder interface and returns it to the app.

4. The app gets the IBinder and casts it into the SDK interface, calling its functions:

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

The app can also render media from the SDK by following these steps:

1. As explained in the media rendering section of this document, in order for an app to get an SDK to render media in a view, the app could make a call to requestSurfacePackage() and fetch the appropriate SurfaceControlViewHost.SurfacePackage .

   The following code snippet provides an illustrative API example:

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

2. The app could then embed the returned SurfacePackage into the SurfaceView via the setChildSurfacePackage API in SurfaceView .

   The following code snippet provides an illustrative API example:

   SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
   

Our proposal is that the IBinder and requestSurfacePackage() APIs be generic and not intended to be called by the apps directly. Instead, these API would be called by the generated API reference discussed above, in a "shim" layer, to reduce the burden on app developers.

SDK-to-SDK

Two SDKs in the same app often need to communicate. This can happen when a given SDK is architected to be composed of constituent SDKs, and can happen when two SDKs from different parties need to collaborate to satisfy a request from the calling app.

There are two key cases to consider:

• When both SDKs are runtime-enabled . In this case, both SDKs are running in the SDK Runtime with all its protections. SDKs are not able to communicate as they do within an app today. Consequently, an API in SdkSandboxController has been added to enable fetching SandboxedSdk objects for all loaded RE-SDKs. This allows a RE-SDK to communicate with other SDKs loaded in the SDK Runtime.
• When only one SDK is runtime-enabled .
  • If the calling SDK is running in the app , this works no differently from the app itself calling into the second SDK within the SDK Runtime.
  • If the calling SDK is running within the SDK Runtime , this proposal recommends exposing a method using the IBinder described in the app-to-SDK section that code in the app listens for, processes, and responds with the provided callbacks.
  • Ad SDKs that are not runtime-enabled may not be able to register themselves, we propose the creation of a mediator SDK which includes any partner or app SDKs as direct dependencies of the app and handles registration. This mediator SDK establishes communication between non runtime-enabled SDKs or other app dependencies and the runtime enabled mediator acting as an adapter.

The feature set for SDK-SDK communication has been split into the following categories:

• SDK-SDK communication within the SDK Runtime (available in the latest Developer Preview)
• SDK-SDK communication between and app and the SDK Runtime (available in the latest Developer Preview)
• How views and remote rendering should work for mediation (proposal in development)

The following use cases are under consideration as the primitives are being designed:

1. Mediation and Bidding . Many advertising SDKs offer a mediation or bidding capability whereby the SDK calls various other SDKs for an ad impression (mediation), or for signal gathering to run an auction (bidding). Typically the coordinating SDK calls other SDKs through an adapter furnished by the coordinating SDK. Given the primitives above, the coordinating SDK, RE or not, should be able to access all RE and non-RE SDKs for normal operation. Rendering in this context is an active area of investigation.
2. Feature discovery . Some SDK products consist of smaller SDKs which, through a process of inter-SDK discovery, determine the ultimate feature set that is exposed to the app developer. Registration and discovery primitives are expected to enable this use case.
3. Publisher-subscription models . Some SDKs are designed to have a central publisher of events that other SDKs or apps can subscribe to for notifications through callbacks. The primitives above should support this use case.

App-to-app

App-to-app communication is where at least one of the two processes communicating is a runtime-enabled SDK, and is a potential vector for undisclosed data sharing. Consequently, the SDK Runtime is unable to establish a direct communication channel with any app other than the client application, or with SDKs in another SDK runtime that is created for another app. This is achieved in the following ways:

• The SDK can't define components like <service> , <contentprovider> , or <activity> in its manifest.
• The SDK can't publish a ContentProvider or send a broadcast.
• The SDK can launch an activity belonging to another app, but with limits on what can be sent in the Intent. For instance, no extras or custom actions can be added to this Intent.
• The SDK can only start or bind to an allowlist of services.
• The SDK is only able to access a subset of the system ContentProvider (such as com.android.providers.settings.SettingsProvider ), where obtained data lacks identifiers and can't be used to build a fingerprint of the user. These checks also apply to accessing ContentProvider using ContentResolver .
• The SDK is only able to access a subset of protected broadcast receivers (such as android.intent.action.AIRPLANE_MODE ).

Manifest tags

When the SDK is installed, PackageManager parses the SDK's manifest and fails to install the SDK if banned manifest tags are present. For example, the SDK may not define components like <service>, <activity>, <provider> , or <receiver> and may not declare a <permission> in the manifest. Tags that fail installation are not supported in the SDK Runtime. Tags that don't fail installation but are silently ignored may be supported in future Android versions.

These checks might also be applied by any build time tools the SDK uses to create the SDK bundle, and at the time of uploading to the application store.

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

SDKs in the SDK Runtime environment can't add an activity tag to their manifest file and can't start their own activities using Context.startActivity . Instead, the platform creates the activities for the SDKs when requested and shares them with SDKs.

The platform activity is of type android.app.Activity . The platform activity starts from one of the app's activities and is part of the app task. FLAG_ACTIVITY_NEW_TASK is not supported.

Note: The Activity object passed by the platform is of type android.app.Activity which isn't compatible with androidx like appcompat or Compose elements.

Note: The provided Activity 's Context must not be used by SDKs, and instead SDK should use SandboxedSdkProvider#getContext() to fetch the proper Context .

For an SDK to start activity, it should register an instance of type SdkSandboxActivityHandler which is used to notify about activity creation when the app calls SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) to start the activity.

The flow of requesting an activity is shown in the following graph.

Sequence diagram that shows the flow of starting an activity.

توسعه

A key principle in this proposal is minimizing the impact to the developer ecosystem to the extent possible. This proposal offers developers a comprehensive set of development tools to write, build, debug RE apps and SDKs. To ensure the integrity of this proposal, there are some changes to how RE apps and SDKs are configured, authored, and built.

Note: This section is very early in its design phase, so fewer details have been explored and much could change. The goal is to share our intention based on what we currently believe is possible, to get your feedback early.

تالیف

Android Studio and related tooling will be updated to be SDK Runtime-aware, helping ensure that developers have correctly configured their RE apps and SDKs, and ensuring that legacy or unsupported calls are updated to their newer alternatives where relevant. During the authoring phase, there are some steps our proposal would require developers to take.

توسعه دهندگان برنامه

Apps would need to specify their RE SDK and SDK certificate dependencies in their app manifest. In our proposal we treat this as the source of truth from the application developer throughout this proposal. به عنوان مثال:

• Name: Package name of the SDK or library.
• Major version: Major version code of the SDK.
• Certificate digest: The certificate digest of the SDK build. For a given build, we propose the SDK developer obtain and register this value through the relevant app store.

This applies to app store-distributed SDKs only, whether RE or not. Apps statically linking SDKs would use current dependency mechanisms.

Given our goal of minimal impact to developers, it is important that once a target API level supporting the SDK Runtime is specified, app developers only ever need to have a single build whether that build runs on devices that do or do not support the SDK Runtime .

SDK developers

In our proposed design, RE SDK developers need to explicitly declare a new element representing the SDK or library entity in the manifest. Additionally, a similar set of values as the dependency would need to be provided plus a minor version:

• Name: Package name of the SDK or library.
• Major version: Major version code of the SDK.
• Minor version: Minor version code of the SDK.

Should RE SDK developers have other RE SDKs as build-time dependencies, they will likely need to declare them in a manner identical to how an app developer would declare the same dependency. RE SDKs depending on non-RE SDKs would statically link them. This may introduce issues that would be detected at build time or during test passes if the non-RE SDKs require functionality the SDK Runtime does not support, or if it must run in the app's process.

RE SDK developers will likely want to continue support for non-RE-enabled devices, such as Android 12 or lower and as mentioned in the System Health section of the document, entry-level Android 14 devices with very limited system resources. We are working through approaches to ensure SDK developers can retain a single code-base to support RE and non-RE environments.

می سازد

توسعه دهندگان برنامه

We expect app developers would experience little change in the build step. SDK dependencies, whether locally distributed or app store-distributed (RE or not), would need to exist on the machine for linting, compilation, and builds. We are proposing that Android Studio abstract these details from the app developer with normal usage and make this as transparent as possible.

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.

توزیع

Our design proposal for the separation of an app from its SDKs has created the possibility for app store distribution of SDKs. This is a general possibility, not unique to any particular app store. مزایا واضح است:

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

In order to support SDK distribution, an app store would likely need to provide most of the following capabilities:

• A mechanism for SDK developers to upload their app store-distributable SDKs to the store, update them, roll them back and possibly remove them.
• A mechanism to ensure the integrity of an SDK and its provenance, and an app and its provenance, and resolve their dependencies.
• A mechanism to deploy them 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.

{% verbatim %} {% endverbatim %} ,

Note: This document reflects the Privacy Sandbox on Android's current design proposals and is subject to further change. We encourage your feedback and comments to assist in these efforts.

The Android platform uses the concept of app sandboxing to maintain robust execution and security boundaries for app code, along process boundaries. It's a common practice for apps to include third-party code, often in the form of SDKs such as ads SDKs or analytics SDKs. This reuse enables app developers to focus on their app's differentiation while leveraging the work of subject matter experts to scale their execution beyond what they could easily do on their own.

Like most operating systems, in Android SDKs are executed within the host app's sandbox, and inherit the same privileges and permissions of their host app as well as access to the host app's memory and storage. While this architecture enables SDKs and apps to flexibly integrate, it also creates the potential for undisclosed user data collection and sharing. Moreover, app developers may not be fully aware of the extent of a third-party SDK's functionality and the data it accesses, making it challenging to account for the data collection and sharing practices of their app.

In Android 14, we have added a new platform capability that allows third-party SDKs to run in a dedicated runtime environment called the SDK Runtime . The SDK Runtime provides the following stronger safeguards and assurances around user data collection and sharing:

• A modified execution environment
• Well-defined permissions and data access rights for SDKs

Note: For the first version of the SDK Runtime, we are focused on supporting advertising-related SDKs, including SDKs which enable ad serving, ads measurement, ads fraud, and abuse detection. Advertising-related SDKs are described later in this document.

We're actively seeking feedback from the mobile app advertising community on this design. We also welcome feedback from the broader developer community to help shape future iterations of the SDK Runtime, including support for additional use cases.

اهداف

This proposal seeks to achieve the following goals:

• Reduce undisclosed access and sharing of a user's app data by third-party SDKs through process isolation and well-defined API and data access control. Learn more about process isolation in a separate section of this document.
• Reduce undisclosed tracking of a user's app usage by third-party SDKs by limiting unique, persistent identifiers from being accessed by SDKs.
• Securely accelerate the distribution of SDK updates to apps by reducing the burden on app developers and end users. Learn more about the proposed trusted SDK distribution model in another section of this document.
• Help app developers better account for the data access and sharing practices of their app.
• Help SDK developers prevent tampering by other SDKs through the limiting of certain unsafe language constructs such as JNI code.
• Help ads SDKs detect and prevent invalid traffic and ad fraud through full control over the remote views displaying media.
• Minimize undue impact to app and SDK developers as much as possible.

SDKs execute in an isolated process

The proposed SDK Runtime enables compatible SDKs—referred to throughout the remainder of this document as runtime-enabled (RE) SDKs —to operate in a separate process for the app. The platform facilitates bi-directional communication between the app's process and its SDK Runtime. See the communications section of this document for detail. Non-RE SDKs would remain in the app's process as they do today. The following diagrams illustrate these changes:

Before being added to the SDK Runtime the SDK-calling code, along with the SDKs that receive the calls from this code, all reside in the app's process

---

After being added to the SDK Runtime the SDK-calling code, in the app's foreground process, the SDK calling code communicates with SDK interfaces. These interfaces then cross a process boundary into the SDK Runtime process to call into the SDKs themselves.

New trusted distribution model for SDKs

This proposed separation of SDK from app motivates another separation concept, one for SDK and app distribution. Our proposal requires a trusted distribution and installation mechanism, to ensure the correct SDKs are installed in an app's SDK Runtime. This helps protect users and app developers from invalid SDKs being loaded, while enabling app stores to significantly reduce the burden of SDK distribution from app developers.

SDKs would no longer need to be statically linked and packaged together with their apps before being uploaded to an app store for distribution. The following process would occur instead:

1. SDK developers could upload their versioned SDKs to the app stores, separate from the apps themselves.
2. App developers could specify their SDK dependencies by version, build, and upload an app release that doesn't include the actual SDK dependencies.
3. When a user downloads this app, the installation process could use the app's specified SDK dependencies to then download them from the app store.

This novel distribution mechanism would enable SDK developers to make non-breaking changes (that is, no changes to APIs or their semantics) to their SDKs and distribute to devices without any involvement from app developers. These non-breaking SDK changes could be deployed or rolled back, without necessarily needing to wait for app developers to rebuild their apps with the new SDKs, or waiting for end users to update their apps. Breaking changes would still need to be updated by app developers, but SDK developers could get their latest non-breaking changes and fixes out more quickly and more uniformly to more people, ideally minimizing version support.

The following diagrams illustrate the proposed changes in SDK distribution:

Before the introduction of the SDK Runtime, developers send their SDKs directly to apps.

---

After the introduction of the SDK Runtime, d, the SDK developers would use an SDK upload UI to publish their SDKs to an app store. The app store would then handle the distribution of apps, along with any SDK dependencies, to end-user devices.

Changes to how SDKs and apps are built, run, and distributed

This is an initial proposal for a flexible SDK Runtime and distribution technology. The following sections propose a series of changes across the following broad categories:

• Access : Permissions, memory, storage
• Execution : Languages, runtime changes, lifecycle, media rendering
• Communications : App-to-SDK and SDK-to-SDK
• Development : How to build, debug, test in this model
• Distribution : How to distribute, update, roll back across versions of Android, apps and SDKs

This document also includes an FAQ to help address common questions.

This is an initial design proposal, and we understand this may be a meaningful change for some members of the ecosystem. This is why we are actively soliciting your feedback and ask that you do so through the issue tracker .

دسترسی داشته باشید

Managing the privacy of a system implies managing how different parties can access different resources. To meet our privacy value proposition we propose updating the model for accessing apps, SDKs, and user data to follow the principle of least privilege to prevent undisclosed access of potentially sensitive data.

SDK permissions

As a separate process, the SDK Runtime would have its own well-defined set of permissions, rather than inherit those that the user granted the app. Based on preliminary research on the permissions used by ads-related SDKs, we're proposing that the following permissions would be accessible to SDKs in the SDK Runtime by default:

• INTERNET : Access to the internet to be able to communicate with a web service.
• ACCESS_NETWORK_STATE : Access information about networks.
• READ_BASIC_PHONE_STATE : Access information about the phone state, for example mobile network type.
• Permissions to access the privacy-preserving APIs , which provide core advertising capabilities without needing access to cross-app identifiers.
• AD_ID : Ability to request the advertising ID. This would also be gated by the app's access to this permission.

We are currently investigating whether and how to authorize additional permissions, limiting the impact on end users from both a privacy and a usability perspective. We request feedback on any use cases that may not be met by this set of permissions.

حافظه

The SDK Runtime would have its own isolated memory space by virtue of having its own process. This structure by default would deny the SDK access to the app's memory space, and the application would similarly not be able to access the SDK's memory space. We propose keeping this default behavior to keep aligned with the principle of least privilege.

ذخیره سازی

This proposal intends to balance the need for SDKs to access storage for their normal operation and minimize cross-app and across-process tracking using persistent storage. We are proposing the following update to how storage is accessed today:

• An app won't be able to directly access its SDKs storage, and vice versa.
• The device's external storage won't be accessible to SDKs.
• Within each SDK Runtime, there would be both storage accessible to all SDKs, and storage that's private to a given SDK.

Like the current storage model, the storage itself won't have arbitrary limits in size. SDKs can use storage for caching assets. This storage is periodically cleared when the SDK is not actively running.

اعدام

To ensure a private system between apps, SDKs, and users, the execution context itself (code formats, language constructs, accessible APIs, and system data) needs to reinforce these privacy boundaries, or at the very least not introduce opportunities to circumvent them. At the same time, we want to preserve access to the rich platform and the majority of runtime capabilities that SDKs currently have. Here we propose a set of updates to the runtime environment to strike this balance.

کد

Android code (apps and SDKs) is predominantly interpreted by the Android Runtime (ART), whether the code was written in Kotlin or Java. The richness of the ART and the language constructs it offers, coupled with the verifiability it offers when compared with alternatives—in particular native code—seems to appropriately balance functionality and privacy. We propose that runtime-enabled SDK code consist exclusively of Dex bytecode, rather than support JNI access.

We are aware that there are use cases, such as the use of custom packaged SQLite, which, given the use of native code, will need to be replaced with an alternative such as the Android SDK's built-in version of SQLite.

SELinux

On Android, each process (including those running as root) runs with a specific SELinux context, allowing the kernel to manage access control to system services, files, devices, and other processes. In seeking to preserve the majority of SDK use cases while minimizing circumvention of the privacy protections we are trying to move forward, we are proposing the following updates from a non-system app's SELinux context for the SDK Runtime:

• A limited set of system services would be accessible. ( under active design )
• SDKs would only be able to load and execute the code in their APK.
• A limited set of system properties would be accessible. ( under active design )

API ها

The use of reflection and invoking APIs within the SDK runtime is allowed. However, an SDK will not be allowed to use reflection or invoke APIs on another runtime-enabled SDK. We will share a full proposal of prohibited APIs in a future update.

In addition, recent Android platform releases have increasingly restricted access to persistent identifiers in order to improve privacy. For the SDK Runtime we propose further limiting access to identifiers which could be used for cross-app tracking.

SDK Runtime APIs are only accessible from apps running in the foreground. Attempting to access SdkSandboxManager APIs from apps in the background results in a SecurityException being thrown.

Lastly, RE-SDKs can't use the notifications APIs to send user notifications at any point in time.

چرخه زندگی

App SDKs currently follow the lifecycle of their host app, meaning when the app enters or leaves the foreground, shuts down, or gets force-stopped by the operating system due to memory pressure, the app's SDKs do so as well. Our proposal to separate an app's SDKs into a different process implies the following lifecycle changes:

• The app can be terminated by the user or the operating system. The SDK Runtime would automatically terminate immediately after.

• The SDK Runtime can be terminated by the operating system due to memory pressure, or an unhandled exception in an SDK for example.

  For Android 14, when an app is in the foreground, the SDK Runtime runs in a high priority and is unlikely to get terminated. When the app goes to the background, the priority of the SDK Runtime process lowers and it becomes eligible for termination. The priority of the SDK Runtime process remains low even if the app comes back to the foreground. Consequently, it is very likely that it would be terminated under memory pressure compared to the app.

  For Android 14 and later, the process priorities of the app and the SDK Runtime are aligned. Process priorities for ActivityManager.RunningAppProcessInfo.importance for the app and the SDK Runtime should be roughly the same.

  In the case that the SDK Runtime terminates while the app is alive—for example, if there's an unhandled exception in the SDK—the SDK Runtime state, including all previously loaded SDKs and remote views, is lost. The app developer can deal with SDK Runtime termination using any of the following methods:

  • The proposal offers related lifecycle callback methods to app developers to detect when termination of the SDK Runtime has occurred.
  • If the SDK Runtime terminates while ads are being displayed, ads might not work as expected. For example, views might be frozen on screen and be no longer interactive. The app can remove the ad view if it does not affect user experience.
  • The app can make another attempt to load SDKs and request ads.
  • For Android 14, if the SDK Runtime terminates while it has SDKs loaded, and if the app developer has not registered the aforementioned lifecycle callback methods, the app terminates by default. Only the app processes that have loaded SDKs terminate and exit normally.
  • Binder objects returned by the SDK to communicate with it (such as SandboxedSdk ) throw a DeadObjectException if used by the app.

  This lifecycle model is subject to change in future updates.

  In the case of persistent failures, the app developer should plan for graceful degradation without the SDK or notify the user if the SDK is crucial to the app's core functionality. For further detail on this app-to-SDK interaction, see the communications section of this document.

Non-RE SDKs can continue to use standard OS primitives available to their embedded app—including services, activities, and broadcasts—whereas RE SDKs cannot.

موارد خاص

The following cases are unsupported, and might yield unexpected behavior:

• If multiple apps share the same UID, the SDK Runtime might not function properly. Support for shared UIDs might be added in the future.
• For apps with multiple processes, loading the SDK should be done in the main process.

Media rendering

There are SDKs that render content such as text, images, and video in an app-specified view. To accomplish this we propose a remote-rendering approach where the SDK will render the media from within the SDK Runtime, but use the SurfaceControlViewHost API to allow for the media to render in an app-specified view. This offers the SDK the capability to render this media in a manner that is private for the user, while helping prevent and detect invalid or fraudulent user interactions with the rendered media.

Native ads, those that are not rendered by the SDK but instead by the app, would be supported by SDKs in the SDK Runtime. The signal gathering and creative fetching process would happen consistently with non-native ads. This is an active area of investigation.

In-stream video ads are those that run instream with a video, shown in a player within an app. Given that the video plays within a player in the app, rather than a player or view in the SDK, the rendering model differs from other ad formats. We are actively exploring mechanisms to support both server-side ad insertion and SDK-based ad insertion.

سلامت سیستم

We seek to minimize the system health impact the SDK Runtime has on end-user devices, and are designing ways to do so. Most likely however, some entry-level Android 14 devices with very limited system resources, such as Android (Go edition) , will not support the SDK Runtime due to the system health impact. We will soon share the minimum requirements necessary to successfully use the SDK Runtime.

ارتباطات

Since apps and SDKs currently run in the same process, communication between them is uninhibited and unmediated. In addition, Android allows for inter-app communication even if the communication starts and ends with SDKs. This free-flowing communication model enables various use cases while at the same time introducing the possibility for undisclosed data sharing between apps and between SDKs within and between apps. We are proposing the following updates to this communication model seeking to strike a balance between the value of such communication and the realization of our stated goals.

App-to-SDK

The interface between the app and the SDK is the most common communication path to an SDK, and an SDK's API is where much of the user-facing differentiation and innovation reside. We seek to preserve SDKs' ability to innovate and differentiate here. Consequently, our proposal empowers SDKs to expose APIs to apps, and ensure that apps can benefit from all of that innovation.

Given the process boundary structure of the SDK Runtime, we are proposing to build a marshaling layer, accessible within the app, to carry the API calls and responses or callbacks across this boundary between the app and the SDK. We are proposing that the interface to this marshaling layer would be defined by SDK developers, and generated by official open-source build tools that we would develop.

With this proposal we seek to remove the boilerplate marshaling work from app and SDK developers, while providing flexibility for SDK developers and ensuring that SDK code runs in the SDK Runtime to realize our privacy goals. Should we take this path, the API definition language and tooling would need to be designed with your input.

The general interaction model would be as follows:

• App calls the SDK through the interface, passing in callbacks.
• SDK asynchronously satisfies the requests and responds using the callbacks.
• This can be generalized to any publisher-subscriber model, meaning an app can subscribe to events in the SDK with callbacks, and when these events happen, the callbacks would be triggered.

A consequence of the new cross-process structure of this proposal is that there are two process lifecycles that would need to be managed: one for the app itself and the other for the SDK Runtime. Our proposal seeks to automate as much of this as possible, minimizing impact to app and SDK developers. The following diagram shows an approach we're considering:

Sequence diagram that shows the app-to-SDK interactions during app and SDK startup.

The platform would expose new APIs for apps to dynamically load SDKs into the SDK Runtime process, get notified about changes to the state of the process, and interact with SDKs loaded into the SDK Runtime.

The graph in the previous figure demonstrates app-to-SDK communication at a lower level, without the marshaling layer.

The app communicates with SDK running in the SDK Runtime process through the following steps:

1. Before an app could interact with an SDK, the app would request that the platform load the SDK. To ensure the integrity of the system, apps would specify the SDKs they intend to load in their manifest file, and these SDKs would be the only ones allowed to be loaded.

   The following code snippet provides an illustrative API example:

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

2. The SDK gets notified that it's been loaded and it returns its interface. This interface is meant to be used by the app process. To share the interface outside the process boundary, it has to be returned as an IBinder object.

   The bound services guide provides different ways to provide IBinder . Whichever way you choose, it must be consistent between the SDK and the caller app. The diagrams uses AIDL as an example.

3. The SdkSandboxManager receives the IBinder interface and returns it to the app.

4. The app gets the IBinder and casts it into the SDK interface, calling its functions:

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

The app can also render media from the SDK by following these steps:

1. As explained in the media rendering section of this document, in order for an app to get an SDK to render media in a view, the app could make a call to requestSurfacePackage() and fetch the appropriate SurfaceControlViewHost.SurfacePackage .

   The following code snippet provides an illustrative API example:

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

2. The app could then embed the returned SurfacePackage into the SurfaceView via the setChildSurfacePackage API in SurfaceView .

   The following code snippet provides an illustrative API example:

   SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
   

Our proposal is that the IBinder and requestSurfacePackage() APIs be generic and not intended to be called by the apps directly. Instead, these API would be called by the generated API reference discussed above, in a "shim" layer, to reduce the burden on app developers.

SDK-to-SDK

Two SDKs in the same app often need to communicate. This can happen when a given SDK is architected to be composed of constituent SDKs, and can happen when two SDKs from different parties need to collaborate to satisfy a request from the calling app.

There are two key cases to consider:

• When both SDKs are runtime-enabled . In this case, both SDKs are running in the SDK Runtime with all its protections. SDKs are not able to communicate as they do within an app today. Consequently, an API in SdkSandboxController has been added to enable fetching SandboxedSdk objects for all loaded RE-SDKs. This allows a RE-SDK to communicate with other SDKs loaded in the SDK Runtime.
• When only one SDK is runtime-enabled .
  • If the calling SDK is running in the app , this works no differently from the app itself calling into the second SDK within the SDK Runtime.
  • If the calling SDK is running within the SDK Runtime , this proposal recommends exposing a method using the IBinder described in the app-to-SDK section that code in the app listens for, processes, and responds with the provided callbacks.
  • Ad SDKs that are not runtime-enabled may not be able to register themselves, we propose the creation of a mediator SDK which includes any partner or app SDKs as direct dependencies of the app and handles registration. This mediator SDK establishes communication between non runtime-enabled SDKs or other app dependencies and the runtime enabled mediator acting as an adapter.

The feature set for SDK-SDK communication has been split into the following categories:

• SDK-SDK communication within the SDK Runtime (available in the latest Developer Preview)
• SDK-SDK communication between and app and the SDK Runtime (available in the latest Developer Preview)
• How views and remote rendering should work for mediation (proposal in development)

The following use cases are under consideration as the primitives are being designed:

1. Mediation and Bidding . Many advertising SDKs offer a mediation or bidding capability whereby the SDK calls various other SDKs for an ad impression (mediation), or for signal gathering to run an auction (bidding). Typically the coordinating SDK calls other SDKs through an adapter furnished by the coordinating SDK. Given the primitives above, the coordinating SDK, RE or not, should be able to access all RE and non-RE SDKs for normal operation. Rendering in this context is an active area of investigation.
2. Feature discovery . Some SDK products consist of smaller SDKs which, through a process of inter-SDK discovery, determine the ultimate feature set that is exposed to the app developer. Registration and discovery primitives are expected to enable this use case.
3. Publisher-subscription models . Some SDKs are designed to have a central publisher of events that other SDKs or apps can subscribe to for notifications through callbacks. The primitives above should support this use case.

App-to-app

App-to-app communication is where at least one of the two processes communicating is a runtime-enabled SDK, and is a potential vector for undisclosed data sharing. Consequently, the SDK Runtime is unable to establish a direct communication channel with any app other than the client application, or with SDKs in another SDK runtime that is created for another app. This is achieved in the following ways:

• The SDK can't define components like <service> , <contentprovider> , or <activity> in its manifest.
• The SDK can't publish a ContentProvider or send a broadcast.
• The SDK can launch an activity belonging to another app, but with limits on what can be sent in the Intent. For instance, no extras or custom actions can be added to this Intent.
• The SDK can only start or bind to an allowlist of services.
• The SDK is only able to access a subset of the system ContentProvider (such as com.android.providers.settings.SettingsProvider ), where obtained data lacks identifiers and can't be used to build a fingerprint of the user. These checks also apply to accessing ContentProvider using ContentResolver .
• The SDK is only able to access a subset of protected broadcast receivers (such as android.intent.action.AIRPLANE_MODE ).

Manifest tags

When the SDK is installed, PackageManager parses the SDK's manifest and fails to install the SDK if banned manifest tags are present. For example, the SDK may not define components like <service>, <activity>, <provider> , or <receiver> and may not declare a <permission> in the manifest. Tags that fail installation are not supported in the SDK Runtime. Tags that don't fail installation but are silently ignored may be supported in future Android versions.

These checks might also be applied by any build time tools the SDK uses to create the SDK bundle, and at the time of uploading to the application store.

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

SDKs in the SDK Runtime environment can't add an activity tag to their manifest file and can't start their own activities using Context.startActivity . Instead, the platform creates the activities for the SDKs when requested and shares them with SDKs.

The platform activity is of type android.app.Activity . The platform activity starts from one of the app's activities and is part of the app task. FLAG_ACTIVITY_NEW_TASK is not supported.

Note: The Activity object passed by the platform is of type android.app.Activity which isn't compatible with androidx like appcompat or Compose elements.

Note: The provided Activity 's Context must not be used by SDKs, and instead SDK should use SandboxedSdkProvider#getContext() to fetch the proper Context .

For an SDK to start activity, it should register an instance of type SdkSandboxActivityHandler which is used to notify about activity creation when the app calls SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) to start the activity.

The flow of requesting an activity is shown in the following graph.

Sequence diagram that shows the flow of starting an activity.

توسعه

A key principle in this proposal is minimizing the impact to the developer ecosystem to the extent possible. This proposal offers developers a comprehensive set of development tools to write, build, debug RE apps and SDKs. To ensure the integrity of this proposal, there are some changes to how RE apps and SDKs are configured, authored, and built.

Note: This section is very early in its design phase, so fewer details have been explored and much could change. The goal is to share our intention based on what we currently believe is possible, to get your feedback early.

تالیف

Android Studio and related tooling will be updated to be SDK Runtime-aware, helping ensure that developers have correctly configured their RE apps and SDKs, and ensuring that legacy or unsupported calls are updated to their newer alternatives where relevant. During the authoring phase, there are some steps our proposal would require developers to take.

توسعه دهندگان برنامه

Apps would need to specify their RE SDK and SDK certificate dependencies in their app manifest. In our proposal we treat this as the source of truth from the application developer throughout this proposal. به عنوان مثال:

• Name: Package name of the SDK or library.
• Major version: Major version code of the SDK.
• Certificate digest: The certificate digest of the SDK build. For a given build, we propose the SDK developer obtain and register this value through the relevant app store.

This applies to app store-distributed SDKs only, whether RE or not. Apps statically linking SDKs would use current dependency mechanisms.

Given our goal of minimal impact to developers, it is important that once a target API level supporting the SDK Runtime is specified, app developers only ever need to have a single build whether that build runs on devices that do or do not support the SDK Runtime .

SDK developers

In our proposed design, RE SDK developers need to explicitly declare a new element representing the SDK or library entity in the manifest. Additionally, a similar set of values as the dependency would need to be provided plus a minor version:

• Name: Package name of the SDK or library.
• Major version: Major version code of the SDK.
• Minor version: Minor version code of the SDK.

Should RE SDK developers have other RE SDKs as build-time dependencies, they will likely need to declare them in a manner identical to how an app developer would declare the same dependency. RE SDKs depending on non-RE SDKs would statically link them. This may introduce issues that would be detected at build time or during test passes if the non-RE SDKs require functionality the SDK Runtime does not support, or if it must run in the app's process.

RE SDK developers will likely want to continue support for non-RE-enabled devices, such as Android 12 or lower and as mentioned in the System Health section of the document, entry-level Android 14 devices with very limited system resources. We are working through approaches to ensure SDK developers can retain a single code-base to support RE and non-RE environments.

می سازد

توسعه دهندگان برنامه

We expect app developers would experience little change in the build step. SDK dependencies, whether locally distributed or app store-distributed (RE or not), would need to exist on the machine for linting, compilation, and builds. We are proposing that Android Studio abstract these details from the app developer with normal usage and make this as transparent as possible.

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.

توزیع

Our design proposal for the separation of an app from its SDKs has created the possibility for app store distribution of SDKs. This is a general possibility, not unique to any particular app store. مزایا واضح است:

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

In order to support SDK distribution, an app store would likely need to provide most of the following capabilities:

• A mechanism for SDK developers to upload their app store-distributable SDKs to the store, update them, roll them back and possibly remove them.
• A mechanism to ensure the integrity of an SDK and its provenance, and an app and its provenance, and resolve their dependencies.
• A mechanism to deploy them 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.

{% verbatim %} {% endverbatim %}