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

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

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

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

  • یک محیط اجرایی اصلاح شده
  • مجوزها و حقوق دسترسی به داده به خوبی تعریف شده برای 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 ارتباط برقرار می کند. سپس این رابط‌ها از یک مرز فرآیند به فرآیند 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 پشتیبانی نمی شود.

برای اینکه یک 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 ٪} {٪ کلمه ٪} {٪ EndverBatim ٪}