نظرة عامة على وقت تشغيل حزمة تطوير البرامج (SDK)

ملاحظة: يعكس هذا المستند اقتراحات التصميم الحالية الخاصة بـ "مبادرة حماية الخصوصية" على Android وهو خاضع للتغيير. ونحن نشجّعك على استخدام ملاحظاتك وتعليقاتك للمساعدة في هذه الجهود.

تقديم ملاحظات

يستخدم نظام Android الأساسي مفهوم وضع الحماية للتطبيقات للحفاظ على قوّة التنفيذ وحدود الأمان لرمز التطبيق، إلى جانب حدود العملية. من الشائع أن يتم تضمين رمز برمجي تابع لجهة خارجية في التطبيقات، وغالبًا ما يكون ذلك في شكل حِزم SDK مثل حِزم SDK لعرض الإعلانات أو حِزم SDK لعرض الإحصاءات. تتيح إعادة الاستخدام هذه لمطوّري التطبيقات التركيز على إبراز محتوى تطبيقاتهم المختلفة، مع الاستفادة في الوقت نفسه من عمل الخبراء المختصين لتوسيع نطاق تنفيذ التطبيقات بطريقة تتجاوز المهام التي يمكنهم تنفيذها بسهولة.

كما هو الحال في معظم أنظمة التشغيل، يتم تنفيذ حزم تطوير البرامج (SDK) لنظام التشغيل Android داخل وضع الحماية للتطبيق المضيف، وتكتسب الامتيازات والأذونات نفسها للتطبيق المضيف بالإضافة إلى إمكانية الوصول إلى ذاكرة التطبيق المضيف وسعة التخزين. وعلى الرغم من أنّ هذه البنية تتيح دمج حِزم SDK والتطبيقات بمرونة، إلا أنّها تتيح أيضًا إمكانية جمع ومشاركة بيانات المستخدمين التي لم يتم الإفصاح عنها. علاوة على ذلك، قد لا يكون مطوّرو التطبيقات على دراية تامة بحجم وظائف حزمة SDK التابعة لجهة خارجية والبيانات التي تصل إليها، مما يصعّب احتساب ممارسات جمع البيانات ومشاركتها في تطبيقاتهم.

في نظام التشغيل Android 13، أضفنا إمكانية جديدة على النظام الأساسي تسمح بتشغيل حِزم SDK التابعة لجهات خارجية في بيئة تشغيل مخصَّصة تُعرف باسم وقت تشغيل SDK. يوفّر "وقت تشغيل SDK" تدابير الوقاية والضمانات المعززة التالية بشأن جمع بيانات المستخدمين ومشاركتها:

• بيئة تنفيذ معدّلة
• أذونات محددة جيدًا وحقوق الوصول إلى البيانات لحِزم SDK

ملاحظة: في الإصدار الأول من "وقت تشغيل SDK"، نركّز على دعم حِزم SDK المتعلّقة بالإعلانات، بما في ذلك حِزم SDK التي تتيح عرض الإعلانات وقياس الإعلانات والاحتيال عليها ورصد إساءة الاستخدام. حِزم تطوير البرامج (SDK) المتعلقة بالإعلانات موضحة لاحقًا في هذا المستند.

نحن نسعى جاهدين للحصول على ملاحظات من مجتمع إعلانات تطبيقات الهاتف المحمول حول هذا التصميم. ونرحّب أيضًا بملاحظات منتدى المطوّرين الأوسع نطاقًا للمساعدة في تطوير الإصدارات المستقبلية من "وقت تشغيل SDK"، بما في ذلك إتاحة حالات الاستخدام الإضافية.

الأهداف

يسعى هذا الاقتراح إلى تحقيق الأهداف التالية:

• يمكنك الحدّ من وصول حِزم تطوير البرامج (SDK) التابعة لجهات خارجية إلى بيانات تطبيقات المستخدم ومشاركتها بدون أن يتم الإفصاح عنها، وذلك من خلال عزل العمليات وواجهة برمجة تطبيقات محدَّدة جيدًا والتحكّم في الوصول إلى البيانات. تعرّف على المزيد من المعلومات حول عزل العمليات في قسم منفصل من هذا المستند.
• يمكنك التقليل من تتبُّع حِزم SDK التابعة لجهات خارجية في ما يتعلّق باستخدام المستخدم للتطبيقات غير المُعلَن عنها، من خلال منع حِزم SDK من الوصول إلى المعرّفات الفريدة والمستمرة.
• يمكنك تسريع وتيرة توزيع تحديثات حِزم تطوير البرامج (SDK) على التطبيقات بشكل آمن من خلال تخفيف أعباء العمل على مطوّري التطبيقات والمستخدمين النهائيين. تعرَّف على المزيد من المعلومات حول نموذج توزيع حزمة SDK الموثوق به المقترَح في قسم آخر من هذا المستند.
• ساعد مطوري التطبيقات في الحساب بشكل أفضل ممارسات الوصول إلى البيانات ومشاركتها في تطبيقاتهم.
• يمكنك مساعدة مطوّري حِزم تطوير البرامج (SDK) على منع التلاعب بحِزم SDK الأخرى من خلال وضع قيود على بعض تركيبات اللغة غير الآمنة، مثل رمز JNI.
• مساعدة حِزم SDK لعرض الإعلانات على رصد ومنع الزيارات غير الصالحة والاحتيال الإعلاني من خلال التحكّم الكامل في المشاهدات عن بُعد التي تعرض الوسائط
• يجب الحدّ قدر الإمكان من التأثير غير الملائم في مطوّري التطبيقات وحِزم تطوير البرامج (SDK).

يتم تنفيذ حِزم SDK في عملية منفصلة

إنّ "وقت تشغيل SDK" المقترَح يتيح لحِزم SDK المتوافقة - المشار إليها في الجزء المتبقي من هذا المستند - حِزم SDK المفعَّلة في وقت التشغيل - للعمل في عملية منفصلة للتطبيق. تسهِّل المنصة التواصل ثنائي الاتجاه بين عملية التطبيق ووقت تشغيل SDK. راجِع قسم الاتصالات بهذا المستند للحصول على التفاصيل. وستبقى حزم SDK التي لا تنتمي إلى فئة RE في عمليات التطبيق كما هي في الوقت الحالي. توضح المخططات التالية هذه التغييرات:

---

وتعبر هذه الواجهات بعد ذلك حدود العملية داخل عملية "وقت تشغيل SDK" لاستدعاء حِزم SDK نفسها.

نموذج توزيع جديد موثوق به لحِزم SDK

هذا الفصل المقترح لحزمة SDK عن التطبيق يحفز مفهوم فصل آخر، أحد مفهوم توزيع SDK والتطبيق. يتطلب عرضنا آلية توزيع وتثبيت موثوق بها لضمان تثبيت حِزم SDK الصحيحة في وقت تشغيل حزمة SDK للتطبيق. يساعد ذلك في حماية المستخدمين ومطوّري التطبيقات من حِزم SDK غير الصالحة التي يتم تحميلها، مع السماح لمتاجر التطبيقات بتخفيف أعباء توزيع حِزم SDK التي يتحمّلها مطوّرو التطبيقات بشكل كبير.

لن تحتاج حِزم SDK إلى ربطها بشكل ثابت وتجميعها مع تطبيقاتها قبل تحميلها إلى متجر التطبيقات لتوزيعها. قد تحدث العملية التالية بدلاً من ذلك:

1. يمكن لمطوّري حزم تطوير البرامج (SDK) تحميل حِزم SDK ذات الإصدارات إلى متاجر التطبيقات، بشكل منفصل عن التطبيقات نفسها.
2. يمكن لمطوّري التطبيقات تحديد تبعيات SDK لديهم حسب الإصدار وإنشاء وتحميل إصدار تطبيق لا يتضمن تبعيات SDK الفعلية.
3. عندما يقوم مستخدم بتنزيل هذا التطبيق، يمكن لعملية التثبيت أن تستخدم تبعيات SDK المحددة الخاصة بالتطبيق، ثم تنزيلها من متجر التطبيقات.

ستمكّن آلية التوزيع الجديدة هذه مطوّري حِزم SDK من إجراء تغييرات غير جذرية (أي عدم إجراء أي تغييرات على واجهات برمجة التطبيقات أو دلالاتها) على حِزم SDK الخاصة بهم وتوزيعها على الأجهزة بدون تدخُّل مطوّري التطبيقات. يمكن نشر هذه التغييرات غير العاجلة في حزمة SDK أو التراجع عنها بدون الحاجة إلى انتظار إعادة إنشاء مطوّري التطبيقات لتطبيقاتهم باستخدام حِزم SDK الجديدة، أو انتظار تحديث المستخدمين لتطبيقاتهم. لا يزال مطوّرو التطبيقات بحاجة إلى إجراء تعديلات على التغييرات العاجلة، إلا أنّ مطوّري حِزم SDK يمكنهم إجراء آخر التغييرات غير العاجلة والإصلاحات بسرعة أكبر وبشكل أكثر اتساقًا للمزيد من المستخدمين، ما يؤدي إلى الحدّ من التوافق مع الإصدارات.

توضّح المخطّطات البيانية التالية التغييرات المقترَحة في توزيع حِزم SDK:

قبل طرح "وقت تشغيل SDK"، يرسل المطوّرون حِزم SDK مباشرةً إلى التطبيقات.

---

بعد طرح "وقت تشغيل SDK"، "د"، كان مطوّرو حِزم SDK يستخدمون واجهة المستخدم لتحميل حِزم SDK في متجر التطبيقات. سيعالج متجر التطبيقات بعد ذلك توزيع التطبيقات إلى أجهزة المستخدمين، وأيّ عناصر تابعة لحزمة SDK.

تغييرات في طريقة إنشاء حِزم SDK والتطبيقات وتشغيلها وتوزيعها

هذا اقتراح أولي بشأن وقت تشغيل حزمة SDK وتقنية توزيع مرنة. تقترح الأقسام التالية سلسلة من التغييرات عبر الفئات الواسعة التالية:

• الوصول: الأذونات والذاكرة ومساحة التخزين
• التنفيذ: اللغات وتغييرات وقت التشغيل ومراحل النشاط وعرض الوسائط
• مراسلات: App-to-SDK وSDK-to-SDK
• التطوير: كيفية إنشاء هذا النموذج وتصحيح الأخطاء فيه واختباره
• التوزيع: كيفية توزيع التطبيقات وحِزم تطوير البرامج (SDK) وتحديثها والعودة إلى الإصدارات السابقة

يتضمّن هذا المستند أيضًا الأسئلة الشائعة للمساعدة في الإجابة عن الأسئلة الشائعة.

هذا اقتراح تصميم أولي، ونتفهم أن هذا قد يكون تغييرًا مهمًا لبعض أعضاء النظام الشامل. لهذا السبب، نسعى جاهدين إلى طلب ملاحظاتك من خلال أداة تتبّع المشاكل.

إمكانية الوصول

تشير إدارة خصوصية أي نظام إلى إدارة كيفية وصول الأطراف المختلفة إلى الموارد المختلفة. لتلبية عرض قيمة الخصوصية الذي نقدّمه، نقترح تعديل النموذج المخصّص للوصول إلى التطبيقات وحِزم SDK وبيانات المستخدمين لاتّباع مبدأ الحدّ الأدنى من الأذونات لمنع الوصول غير المعلَن عنه إلى البيانات التي يُحتمل أن تكون حسّاسة.

أذونات حِزم تطوير البرامج (SDK)

كعملية منفصلة، سيكون لوقت تشغيل SDK مجموعة محددة من الأذونات، بدلاً من اكتساب الأذونات التي منحها المستخدم للتطبيق. وبناءً على الأبحاث الأولية حول الأذونات التي تستخدمها حِزم SDK المرتبطة بالإعلانات، نقترح أن تكون الأذونات التالية متاحة لحِزم SDK في وقت التشغيل تلقائيًا:

• INTERNET: اتصال بالإنترنت لتتمكن من الاتصال بأي خدمة ويب.
• ACCESS_NETWORK_STATE: الوصول إلى معلومات حول الشبكات
• أذونات الوصول إلى واجهات برمجة التطبيقات للحفاظ على الخصوصية التي توفِّر إمكانات الإعلانات الأساسية بدون الحاجة إلى الوصول إلى المعرّفات على مستوى التطبيقات
• AD_ID: إمكانية طلب المعرّف الإعلاني. سيتم تقييد هذا الإذن أيضًا من خلال وصول التطبيق إلى هذا الإذن.
• BIND_GET_INSTALL_REFERRER_SERVICE: إمكانية استخدام واجهة برمجة تطبيقات مُحيل Google Play التثبيت لتحديد مصدر تثبيت التطبيق

نحقِّق حاليًا في ما إذا كان سيتم منح إذن بأذونات إضافية وكيفية إجراء ذلك، ما يحدّ من تأثيرها على المستخدمين النهائيين من منظور الخصوصية وسهولة الاستخدام. نطلب ملاحظات حول أي حالات استخدام قد لا تستوفيها مجموعة الأذونات هذه.

Memory

سيكون لوقت تشغيل SDK مساحة ذاكرة معزولة خاصة به نظرًا لوجود عملية خاصة به. تمنع هذه البنية افتراضيًا وصول SDK إلى مساحة ذاكرة التطبيق، وبالمثل لن يتمكن التطبيق من الوصول إلى مساحة ذاكرة SDK. ونقترح الحفاظ على هذا السلوك الافتراضي ليتماشى مع مبدأ الحدّ الأدنى من الأذونات المميّزة.

مساحة التخزين

يهدف هذا الاقتراح إلى تحقيق التوازن بين الحاجة إلى وصول حِزم تطوير البرامج (SDK) إلى مساحة التخزين لاستخدامها في العمل العادي والحد من التتبُّع على مستوى التطبيقات وفي جميع العمليات باستخدام مساحة التخزين الدائمة. نقترح التعديل التالي حول كيفية الوصول إلى مساحة التخزين اليوم:

• لن يتمكن التطبيق من الوصول مباشرةً إلى مساحة التخزين في حِزم SDK، والعكس صحيح.
• لن تتمكن حزم تطوير البرامج (SDK) من الوصول إلى وحدة التخزين الخارجية للجهاز.
• في كل "وقت تشغيل SDK"، تتوفّر مساحة تخزين يمكن الوصول إليها من خلال كل حِزم SDK، ومساحة تخزين خاصة بحزمة SDK معيّنة.

مثل نموذج التخزين الحالي، لن يكون للتخزين نفسه حدود عشوائية في الحجم. ويمكن أن تستخدم حِزم SDK مساحة تخزين لمواد العرض في ذاكرة التخزين المؤقت. ويتم مسح وحدة التخزين هذه بشكل دوري عند عدم تشغيل SDK بشكل نشط.

التنفيذ

لضمان توفُّر نظام خاص بين التطبيقات وحِزم تطوير البرامج (SDK) والمستخدمين، يحتاج سياق التنفيذ نفسه (تنسيقات الرموز وتركيبات اللغة وواجهات برمجة التطبيقات التي يمكن الوصول إليها وبيانات النظام) إلى تعزيز حدود الخصوصية هذه، أو على الأقل عدم توفير فرص للتحايل عليها. وفي الوقت نفسه، نهدف إلى الحفاظ على إمكانية الوصول إلى النظام الأساسي المفيد وإتاحة معظم إمكانات وقت التشغيل المتاحة لحِزم SDK حاليًا. نقترح هنا مجموعة من التحديثات على بيئة وقت التشغيل لتحقيق هذا التوازن.

الرمز

يفسر وقت تشغيل Android (ART) بشكل أساسي رمز Android (التطبيقات وحِزم SDK)، سواء كان الرمز مكتوبًا بلغة Kotlin أو Java. إنّ ثراء تقنية ART وتركيبها اللغوي، بالإضافة إلى إمكانية التحقّق من صحتها، عند مقارنتها بالبدائل، لا سيّما الرموز البرمجية الأصلية، تعمل على تحقيق التوازن بشكل مناسب بين الوظائف والخصوصية. نقترح أن يكون رمز SDK الذي يتم تفعيل وقت التشغيل به مؤلفًا حصريًا من رمز بايت Dex، بدلاً من إتاحة وصول JNI.

ندرك أنّ هناك حالات استخدام، مثل استخدام لغة SQLite (المجمّعة) المخصّصة، والتي يجب استبدالها بحل بديل مثل إصدار SQLite المدمج في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

SELinux

على نظام Android، يتم تشغيل كل عملية (بما فيها تلك التي يتم تشغيلها كجذر) بسياق SELinux المحدد، مما يسمح للنواة بإدارة التحكم في الوصول إلى خدمات النظام والملفات والأجهزة والعمليات الأخرى. وفي إطار سعينا إلى الحفاظ على غالبية حالات استخدام حِزم SDK مع الحدّ من التحايل على إجراءات حماية الخصوصية التي نحاول المضيّ قدمًا فيها، نقترح إجراء التحديثات التالية من سياق SELinux الخاص بتطبيق غير قائم على نظام التشغيل، وذلك من أجل "وقت تشغيل SDK":

• يمكن الوصول إلى مجموعة محدودة من خدمات النظام. (ضمن التصميم النشط)
• لن يكون بإمكان حِزم SDK تحميل وتنفيذ الرمز في حزمة APK.
• ويمكن الوصول إلى مجموعة محدودة من خصائص النظام. (ضمن التصميم النشط)

واجهات برمجة التطبيقات

يُسمح باستخدام واجهات برمجة التطبيقات للانعكاس والاستدعاء ضمن وقت تشغيل حزمة تطوير البرامج (SDK). ومع ذلك، لن يُسمح لحزمة تطوير البرامج (SDK) باستخدام انعكاس أو استدعاء واجهات برمجة التطبيقات في حزمة SDK أخرى يتم تفعيلها في وقت التشغيل. وسنشارك في تحديث مستقبلي اقتراحًا كاملاً لواجهات برمجة التطبيقات المحظورة.

بالإضافة إلى ذلك، فرضت إصدارات نظام Android الأساسية الأخيرة قيودًا متزايدة على الوصول إلى المعرّفات الثابتة لتحسين الخصوصية. بالنسبة إلى "وقت تشغيل SDK"، نقترح مزيدًا من تقييد الوصول إلى المعرّفات التي يمكن استخدامها للتتبُّع عبر التطبيقات.

لا يمكن الوصول إلى واجهات برمجة تطبيقات وقت تشغيل SDK إلا من التطبيقات التي تعمل في المقدّمة. إذا حاولت الوصول إلى واجهات برمجة تطبيقات SdkSandboxManager من التطبيقات في الخلفية، يتم إيقاف SecurityException.

أخيرًا، لا يمكن لحِزم RE-SDK استخدام واجهات برمجة التطبيقات للإشعارات لإرسال إشعارات إلى المستخدمين في أي وقت.

دورة الحياة

تتبع حِزم تطوير البرامج (SDK) للتطبيقات حاليًا دورة حياة التطبيق المضيف، بمعنى أنه عندما يدخل التطبيق إلى المقدّمة أو يغادره أو يتوقف عن العمل أو يوقفه نظام التشغيل بسبب ضغط الذاكرة، فإنّ حِزم SDK الخاصة بالتطبيقات تفعل ذلك أيضًا. إن اقتراحنا لفصل حزم SDK الخاصة بالتطبيق في عملية مختلفة يتضمن التغييرات التالية في مراحل النشاط:

• يمكن للمستخدم أو نظام التشغيل إغلاق التطبيق. سيتم تلقائيًا إنهاء "وقت تشغيل SDK" بعد ذلك مباشرةً.

• يمكن إنهاء "وقت تشغيل SDK" من قِبل نظام التشغيل بسبب ضغط الذاكرة أو استثناء غير معالج في إحدى حزم SDK على سبيل المثال.

  بالنسبة إلى نظام التشغيل Android 13، عندما يكون التطبيق في المقدّمة، يتم تشغيل "وقت تشغيل SDK" بأولوية عالية ومن غير المرجّح أن يتم إنهاؤه. عندما ينتقل التطبيق إلى الخلفية، تقل أولوية عملية تشغيل SDK ويصبح مؤهلاً للإنهاء. تظل أولوية عملية "وقت تشغيل SDK" منخفضة حتى إذا عاد التطبيق إلى المقدّمة. وبالتالي، من المحتمل جدًا أن يتم إنهاؤها بسبب ضغط الذاكرة مقارنةً بالتطبيق.

  بالنسبة إلى الإصدار 14 من نظام التشغيل Android والإصدارات الأحدث، تكون أولويات عمل التطبيق ووقت تشغيل حزمة تطوير البرامج (SDK) متوافقة. ينبغي أن تكون أولويات معالجة ActivityManager.RunningAppProcessInfo.importance للتطبيق مماثلة لوقت تشغيل SDK تقريبًا.

  في حال إنهاء "وقت تشغيل SDK" عندما يكون التطبيق نشطًا، على سبيل المثال، إذا كان هناك استثناء لم تتم معالجته في حزمة SDK، ستفقد حالة "وقت تشغيل SDK"، بما في ذلك جميع حِزم SDK التي تم تحميلها في وقت سابق وطرق العرض عن بُعد. يمكن لمطوِّر التطبيق التعامل مع إنهاء "وقت تشغيل SDK" باستخدام إحدى الطرق التالية:

  • يوفِّر الاقتراح طرق معاودة الاتصال ذات الصلة بدورة حياة لمطوّري التطبيقات ليتمكّنوا من رصد وقت إنهاء "وقت تشغيل SDK".
  • وفي حال انتهاء "وقت تشغيل SDK" أثناء عرض الإعلانات، قد لا تعمل الإعلانات على النحو المتوقَّع. على سبيل المثال، قد يتم تجميد عدد المشاهدات على الشاشة وتوقف عن التفاعل مع المحتوى. يمكن للتطبيق إزالة عرض الإعلان إذا لم يؤثر ذلك في تجربة المستخدم.
  • يمكن للتطبيق إجراء محاولة أخرى لتحميل حِزم SDK وطلب الإعلانات.
  • بالنسبة إلى نظام التشغيل Android 14، إذا تم إنهاء "وقت تشغيل SDK" أثناء تحميل حِزم SDK، وإذا لم يسجِّل مطوّر التطبيق طرق معاودة الاتصال المذكورة أعلاه وسيتم إنهاء التطبيق تلقائيًا. يتم فقط إنهاء عمليات التطبيق التي تم تحميل حِزم تطوير البرامج (SDK) والخروج منها بشكل طبيعي.
  • يؤدي استخدام كائنات الصنف Binder التي تعرضها حزمة SDK للتواصل معها (مثل SandboxedSdk) إلى عرض الخطأ DeadObjectException إذا استخدمه التطبيق.

  إنّ نموذج دورة الحياة هذا عرضة للتغيير في التحديثات المستقبلية.

  في حال استمرار حالات العطل، على مطوّر التطبيقات التخطيط للتقليص السلس بدون حزمة تطوير البرامج (SDK) أو إبلاغ المستخدم إذا كانت حزمة SDK أساسية في الوظائف الأساسية للتطبيق. للحصول على مزيد من التفاصيل حول التفاعل بين التطبيق وحزمة تطوير البرامج (SDK)، يُرجى الاطّلاع على قسم الاتصالات في هذه الوثيقة.

يمكن لحِزم تطوير البرامج (SDK) غير التابعة لتكنولوجيا المعلومات الجديدة مواصلة استخدام إصدارات RE SDK الأساسية المتاحة للتطبيقات المضمّنة، بما في ذلك الخدمات والأنشطة وعمليات البث، بينما لا يمكن لحِزم RE SDK ذلك.

الحالات الخاصة

الحالات التالية غير متوافقة، وقد تؤدي إلى سلوك غير متوقع:

• إذا تشترك عدة تطبيقات في المعرّف الفريد نفسه، قد لا يعمل "وقت تشغيل SDK" بشكل صحيح. ويمكن إتاحة المعرّفات الفريدة المشتركة في المستقبل.
• بالنسبة إلى التطبيقات التي تتضمّن عمليات متعددة، يجب تحميل حزمة SDK في العملية الرئيسية.

عرض الوسائط

تتوفر حِزم تطوير برامج (SDK) تعرض محتوى مثل النصوص والصور والفيديوهات في طريقة عرض محدَّدة للتطبيق. لتحقيق ذلك، نقترح طريقة العرض عن بُعد التي ستعرض فيها حزمة SDK الوسائط من داخل "وقت تشغيل SDK"، ولكن تستخدم واجهة برمجة التطبيقات SurfaceControlViewHost API للسماح بعرض الوسائط في عرض محدد للتطبيق. ويوفّر ذلك لحزمة تطوير البرامج (SDK) إمكانية عرض هذه الوسائط بطريقة خاصة للمستخدم، مع المساعدة في منع ورصد تفاعلات المستخدم غير الصالحة أو الاحتيالية مع الوسائط المعروضة.

ستكون الإعلانات المدمجة مع المحتوى، وهي الإعلانات التي لا تعرضها حزمة SDK ولكن بدلاً من ذلك من خلال التطبيق، متوافقة مع حِزم SDK في وقت تشغيل SDK. ستحدث عملية جمع الإشارات وجلب المواد الإبداعية بشكل متوافق مع الإعلانات غير المدمجة مع المحتوى. هذا مجال تحقيق نشط.

"الإعلانات أثناء عرض الفيديو" هي تلك التي يتم عرضها في مشغِّل فيديو، ويتم عرضها في مشغّل داخل تطبيق. وبما أنّه يتم تشغيل الفيديو ضمن مشغّل في التطبيق، وليس في مشغّل أو في حزمة تطوير البرامج (SDK)، يختلف نموذج العرض عن أشكال الإعلانات الأخرى. ونعمل جاهدين على استكشاف آليات لدعم كلّ من إدراج الإعلانات من جهة الخادم وإدراج الإعلانات المستند إلى حزمة تطوير البرامج (SDK).

حالة النظام

نسعى إلى تقليل التأثير الذي يحدثه "وقت تشغيل SDK" على أجهزة المستخدمين للحدّ من تأثيره على أجهزة المستخدمين، ونسعى إلى ذلك في طُرق لتنفيذ ذلك، ولكن على الأرجح أنّ بعض أجهزة Android 13 المبتدئة والتي لها موارد نظام محدودة للغاية، مثل Android (إصدار Go)، لن تتوافق مع "وقت تشغيل SDK" بسبب التأثير على سلامة النظام. سنشارك قريبًا الحدّ الأدنى من المتطلبات اللازمة لاستخدام "وقت تشغيل SDK" بنجاح.

الاتصالات

وبما أنّ التطبيقات وحِزم SDK تعمل حاليًا في العملية نفسها، فإن التواصل بينها ليس محظورًا وبدون وسيط. بالإضافة إلى ذلك، يسمح Android بالتواصل بين التطبيقات حتى إذا بدأ التواصل وانتهى بحزم SDK. يتيح نموذج التواصل المجاني هذا حالات استخدام مختلفة مع توفير إمكانية مشاركة البيانات بدون الكشف عن المعلومات بين التطبيقات وبين حِزم SDK داخلها وبينها. نقترح التحديثات التالية لنموذج التواصل هذا سعيًا إلى تحقيق التوازن بين قيمة مثل هذا التواصل وتحقيق أهدافنا المعلنة.

تحويل التطبيقات إلى حزمة تطوير البرامج (SDK)

إنّ الواجهة بين التطبيق وحزمة تطوير البرامج (SDK) هي مسار التواصل الأكثر شيوعًا لحزمة SDK، بينما يكمن الكثير من التميّز والابتكار المواجهَين للمستخدم في واجهة برمجة التطبيقات الخاصة بحزمة SDK. ونسعى إلى الحفاظ على قدرة حِزم SDK على الابتكار والتميّز هنا. وبالتالي، يعزز اقتراحنا حِزم تطوير البرامج (SDK) لعرض واجهات برمجة التطبيقات للتطبيقات، والتأكّد من أن التطبيقات يمكنها الاستفادة من كل هذا الابتكار.

وبالنظر إلى بنية حدود العملية في "وقت تشغيل SDK"، نقترح إنشاء طبقة تنظيم يمكن الوصول إليها داخل التطبيق لنقل طلبات البيانات من واجهة برمجة التطبيقات والردود أو عمليات معاودة الاتصال عبر هذه الحدود بين التطبيق وحزمة تطوير البرامج (SDK). نقترح أن يتم تحديد واجهة طبقة تنظيم البيانات هذه من قِبل مطوري SDK، وأن يتم إنشاؤها بواسطة أدوات إنشاء رسمية مفتوحة المصدر سنطوّرها.

من خلال هذا الاقتراح، نسعى إلى إزالة العمل النموذجي من مطوّري التطبيقات وحِزم SDK، مع توفير المرونة في الوقت نفسه لمطوّري حِزم SDK وضمان تشغيل رمز SDK في "وقت تشغيل SDK" لتحقيق أهداف الخصوصية لدينا. وإذا اتّبعنا هذا الإجراء، يجب أن تكون لغة تعريف واجهة برمجة التطبيقات وأدواتها مصمّمة باستخدام البيانات التي تُدخلها.

سيكون نموذج التفاعل العام على النحو التالي:

• يستدعي التطبيق حزمة SDK من خلال الواجهة، ويمرر طلبات معاودة الاتصال.
• تلبّي حزمة تطوير البرامج (SDK) الطلبات بشكل غير متزامن وتستجيب باستخدام عمليات معاودة الاتصال.
• ويمكن تعميم هذا النموذج على أي نموذج مشترك مع الناشرين، ما يعني أنه يمكن للتطبيق الاشتراك في الأحداث في حزمة تطوير البرامج (SDK) باستخدام عمليات معاودة الاتصال، وعند حدوثها، سيتم تفعيل عمليات معاودة الاتصال.

نتيجةً للبنية الجديدة المتعدّدة العمليات لهذا الاقتراح، يجب أن تتم إدارة دورتَين من مراحل العمليات: إحداهما للتطبيق نفسه والأخرى لوقت تشغيل SDK. ويهدف اقتراحنا إلى أتمتة أكبر قدر ممكن من هذه العملية، مع تقليل التأثير على مطوّري التطبيقات وحزم تطوير البرامج (SDK). يوضح الرسم البياني التالي النهج الذي نراعيه:

مخطط التسلسل الذي يعرض التفاعلات بين التطبيقات وحزمة تطوير البرامج (SDK) أثناء بدء تشغيل التطبيق وحزمة تطوير البرامج (SDK).

ستعرض المنصة واجهات برمجة تطبيقات جديدة للتطبيقات لتحميل حِزم SDK ديناميكيًا في عملية "وقت تشغيل SDK"، وتلقّي إشعارات بشأن التغييرات التي تطرأ على حالة العملية، والتفاعل مع حِزم SDK التي يتم تحميلها في "وقت تشغيل SDK".

يوضح الرسم البياني في الشكل السابق الاتصال من تطبيق إلى حزمة SDK على مستوى أقل، بدون طبقة تنظيم.

يتواصل التطبيق مع حزمة SDK التي تعمل في عملية "وقت تشغيل SDK" من خلال الخطوات التالية:

1. قبل أن يتفاعل التطبيق مع SDK، يطلب التطبيق من النظام الأساسي تحميل SDK. ولضمان سلامة النظام، ستحدِّد التطبيقات حِزم SDK التي تنوي تحميلها في ملف البيان، وستكون حِزم SDK هذه هي الحِزم الوحيدة المسموح بتحميلها.

   يقدم مقتطف الرمز التالي مثالاً توضيحيًا لواجهة برمجة التطبيقات:

   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 المناسب.

   يقدم مقتطف الرمز التالي مثالاً توضيحيًا لواجهة برمجة التطبيقات:

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

2. يمكن للتطبيق بعد ذلك تضمين علامة SurfacePackage المعروضة في SurfaceView من خلال واجهة برمجة تطبيقات setChildSurfacePackage في SurfaceView.

   يقدم مقتطف الرمز التالي مثالاً توضيحيًا لواجهة برمجة التطبيقات:

   SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
   

نقترح أن تكون واجهتا برمجة التطبيقات IBinder وrequestSurfacePackage() عامةً وألا تطلب التطبيقات مباشرةً من التطبيقات. وبدلاً من ذلك، سيتم استدعاء واجهة برمجة التطبيقات هذه باستخدام مرجع واجهة برمجة التطبيقات الذي تم إنشاؤه والمناقش أعلاه، في طبقة "واجهة"، لتقليل العبء الواقع على مطوري التطبيقات.

تحويل البيانات من حزمة SDK إلى حزمة تطوير البرامج (SDK)

غالبًا ما تحتاج حزمتا SDK في التطبيق نفسه إلى التواصل. يمكن أن يحدث هذا عندما يتم تصميم حزمة SDK معينة لتتألف من حِزم SDK، أو عندما يتعاون حِزمتا SDK من أطراف مختلفة لتلبية طلب من تطبيق الاتصال.

وثمة حالتان رئيسيتان يجب مراعاتهما:

• عند تفعيل حزمتَي تطوير البرامج (SDK) في وقت التشغيل: في هذه الحالة، يتم تشغيل حزمتَي تطوير البرامج (SDK) في وقت تشغيل SDK مع جميع إجراءات الحماية الخاصة بها. لا تتمكن حزم SDK من التواصل كما هي الحال داخل التطبيق اليوم. وبالتالي، تمت إضافة واجهة برمجة تطبيقات في SdkSandboxController لتفعيل جلب عناصر SandboxedSdk لكل حزم RE-SDK التي تم تحميلها. يسمح هذا الإجراء لـ RE-SDK بالتواصل مع حِزم SDK الأخرى التي يتم تحميلها في "وقت تشغيل SDK".
• عندما يتم تفعيل حزمة تطوير برامج (SDK) واحدة فقط في وقت التشغيل:
  • إذا كانت حزمة تطوير البرامج (SDK) للاتصال تعمل في التطبيق، لا يختلف ذلك عن التطبيق نفسه الذي يستدعي حزمة SDK الثانية ضمن "وقت تشغيل SDK".
  • إذا كانت حزمة تطوير البرامج (SDK) للاتصال تعمل ضمن وقت تشغيل SDK، يقترح هذا الاقتراح عرض طريقة باستخدام IBinder الموضحة في قسم "تحويل التطبيقات إلى حزمة SDK" وأنّ الرمز في التطبيق ينتظر معاودة الاتصال المقدَّمة ويعالجها ويستجيب لها.
  • قد لا تتمكّن حِزم SDK الإعلانية التي لم يتم تفعيلها في وقت التشغيل من تسجيل نفسها، لذا نقترح إنشاء حزمة SDK وسيطة تتضمّن أي حِزم تطوير برامج (SDK) خاصة بشريك أو تطبيق كملحقات مباشرة للتطبيق وتعالج التسجيل. ينشئ حزمة SDK الوسيطة هذه اتصالاً بين حِزم SDK التي لا يتم تفعيلها في وقت التشغيل أو غيرها من تبعيات التطبيقات، والوسيط المفعَّل في وقت التشغيل الذي يعمل كمُعدِّل.

تم تقسيم مجموعة الميزات للاتصال بحزمة SDK-SDK إلى الفئات التالية:

• إرسال رسالة بين حزمة SDK وحزمة تطوير البرامج (SDK) ضمن "وقت تشغيل SDK" (متاح في أحدث إصدار من "معاينة المطوِّر")
• اتصال حزمة SDK وحزمة تطوير البرامج (SDK) بين تطبيق "وقت تشغيل SDK" والتطبيق (متوفّر في أحدث إصدار من "معاينة المطوِّر")
• الطريقة التي يجب أن تعمل بها طرق العرض والعرض عن بُعد من أجل التوسط (اقتراح في مرحلة التطوير)

يتم وضع حالات الاستخدام التالية في الاعتبار أثناء تصميم المبادئ الأساسية:

1. التوسّط وعروض الأسعار: توفِّر العديد من حِزم SDK لعرض الإعلانات إمكانية التوسّط أو عروض الأسعار، وتطلب الحزمة بموجبها حِزم تطوير برامج (SDK) أخرى متنوعة لتسجيل مرة ظهور للإعلان (توسّط)، أو لجمع الإشارات لإجراء مزاد (عروض الأسعار). عادةً ما تستدعي حزمة SDK المنسَّقة حزم تطوير البرامج (SDK) الأخرى من خلال محوّل يوفّره حزمة تطوير البرامج (SDK) للتنسيق. بناءً على العناصر الأساسية المذكورة أعلاه، يجب أن يكون بإمكان حزمة تطوير البرامج (SDK) المنسَّقة، أو RE أو لا، الوصول إلى جميع حِزم تطوير البرامج (SDK) الخاصة بRE وغير ذلك من أجل التشغيل العادي. العرض في هذا السياق مجال نشط للتحقيق.
2. اكتشاف الميزات: تتكوّن بعض منتجات حِزم SDK من حِزم تطوير برامج (SDK) أصغر حجمًا يتم تحديد مجموعة الميزات النهائية التي تظهر لمطوِّر التطبيق من خلال عملية اكتشاف حِزم SDK. ومن المتوقع أن تؤدي أساسيات التسجيل والاكتشاف إلى تمكين حالة الاستخدام هذه.
3. نماذج اشتراكات الناشرين: تم تصميم بعض حِزم SDK لتكون ناشرًا مركزيًا للأحداث التي يمكن لحِزم SDK أو التطبيقات الأخرى الاشتراك فيها لتلقّي الإشعارات من خلال طلبات معاودة الاتصال. يجب أن تدعم الأساسيات المذكورة أعلاه حالة الاستخدام هذه.

التطبيقات

التواصل من تطبيق إلى تطبيق هو عندما تكون إحدى العمليتَين على الأقل للتواصل عبارة عن حزمة تطوير برامج (SDK) يتم تفعيلها في وقت التشغيل، وهي عبارة عن موجّه محتمل لمشاركة البيانات غير المعلَن عنها. وبالتالي، لا يمكن لـ "وقت تشغيل SDK" إنشاء قناة اتصال مباشر مع أي تطبيق غير تطبيق العميل أو من خلال حزم 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". بالنسبة إلى العلامات التي لا تنجح في التثبيت ولكن يتم تجاهلها بدون تنبيه، قد تتم إتاحة هذه العلامات في إصدارات Android المستقبلية.

ويمكن تطبيق عمليات التحقّق هذه أيضًا من خلال أيّ من أدوات وقت الإصدار التي تستخدمها حزمة SDK لإنشاء حزمة SDK، وعند التحميل إلى متجر التطبيقات.

دعم النشاط

لا يمكن لحِزم SDK في بيئة "وقت تشغيل SDK" إضافة علامة نشاط إلى ملف البيان الخاصة بها ولا يمكنها بدء أنشطتها الخاصة باستخدام Context.startActivity. وبدلاً من ذلك، تنشئ المنصة الأنشطة لحِزم SDK عند طلبها وتشاركها مع حِزم SDK.

نشاط المنصة من النوع android.app.Activity. يبدأ نشاط النظام الأساسي من أحد أنشطة التطبيق وهو جزء من مهمة التطبيق. "FLAG_ACTIVITY_NEW_TASK" غير متاح

ملاحظة: العنصر Activity الذي تم تمريره من خلال النظام الأساسي من النوع android.app.Activity، وهو غير متوافق مع عناصر androidx مثل عناصر appcompat أو Compose.

ملاحظة: يجب ألا تستخدم حِزم SDK Context لنظام Activity المقدَّم، وبدلاً من ذلك، يجب أن تستخدم حزمة تطوير البرامج SandboxedSdkProvider#getContext() لاسترجاع Context المناسب.

لكي تبدأ حزمة SDK النشاط، يجب أن تسجِّل مثيلاً من النوع SdkSandboxActivityHandler الذي يُستخدم لإرسال إشعار حول إنشاء النشاط عندما يستدعي التطبيق SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) لبدء النشاط.

يتم عرض مسار طلب النشاط في الرسم البياني التالي.

مخطّط تسلسلي يوضّح مسار بدء نشاط.

تطوير

أحد المبادئ الرئيسية في هذا الاقتراح هو تقليل التأثير على المنظومة المتكاملة للمطوّرين قدر الإمكان. ويوفّر هذا الاقتراح للمطوّرين مجموعة شاملة من أدوات التطوير المخصّصة لكتابة وإنشاء وتصحيح الأخطاء في تطبيقات RE وحُزم تطوير البرامج (SDK). لضمان نزاهة هذا الاقتراح، هناك بعض التغييرات على كيفية إعداد التطبيقات وحِزم تطوير البرامج (SDK) في RE، وكتابتها وإنشاءها.

ملاحظة: هذا القسم في وقت مبكر جدًا من مرحلة التصميم، لذلك تم استكشاف عدد أقل من التفاصيل ويمكن أن يتغير الكثير. وهدفنا من ذلك هو مشاركة هدفنا من خلال الحصول على الملاحظات في مرحلة مبكرة استنادًا إلى ما نؤمن به في الوقت الحالي.

التأليف

سيتم تحديث "استوديو Android" والأدوات ذات الصلة به لتصبح متوافقة مع "وقت تشغيل SDK"، ما يضمن ضبط المطوّرين وحِزم تطوير البرامج (SDK) الخاصة بهم بشكل صحيح، وضمان تعديل الطلبات القديمة أو غير المتوافقة باستخدام البدائل الأحدث عند الاقتضاء. أثناء مرحلة الكتابة، هناك بعض الخطوات التي يتطلب اقتراحنا من المطورين اتخاذها.

مطوّرو التطبيقات

يجب أن تحدّد التطبيقات تبعيات شهادات RE SDK وSDK في بيان التطبيق. في عرضنا، نتعامل مع هذا على أنه مصدر الحقيقة من مطور التطبيقات خلال هذا العرض. مثال:

• الاسم: اسم حزمة حزمة تطوير البرامج (SDK) أو المكتبة.
• الإصدار الرئيسي: هو رمز الإصدار الرئيسي لحزمة تطوير البرامج (SDK).
• ملخص الشهادة: يعرض ملخص الشهادة لإصدار حزمة تطوير البرامج (SDK). ونقترح في إصدار معيّن لمطوِّر حزمة SDK الحصول على هذه القيمة وتسجيلها من خلال متجر التطبيقات ذي الصلة.

ينطبق ذلك على حِزم تطوير البرامج (SDK) التي يتم توزيعها من خلال متجر التطبيقات فقط، سواء كانت RE أو لا. ستستخدم التطبيقات التي تربط بشكل ثابت حِزم SDK آليات التبعية الحالية.

بما أنّ هدفنا هو الحدّ الأدنى من التأثير على المطوّرين، من المهم أنّه بعد تحديد مستوى واجهة برمجة تطبيقات مستهدَف متوافق مع وقت تشغيل SDK، لن يحتاج مطوِّرو التطبيقات إلّا إلى إصدار واحد، سواء كان هذا الإصدار يعمل على أجهزة تتوافق مع "وقت تشغيل SDK" أم لا.

مطوّرو حِزم تطوير البرامج (SDK)

في التصميم الذي اقترحناه، يحتاج مطوّرو RE SDK إلى الإعلان صراحةً عن عنصر جديد يمثّل كيان المكتبة أو SDK في ملف البيان. بالإضافة إلى ذلك، يجب تقديم مجموعة مماثلة من القيم مثل التبعية بالإضافة إلى إصدار ثانوي:

• الاسم: اسم حزمة حزمة تطوير البرامج (SDK) أو المكتبة.
• الإصدار الرئيسي: هو رمز الإصدار الرئيسي لحزمة تطوير البرامج (SDK).
• الإصدار الثانوي: هو رمز إصدار حزمة تطوير البرامج (SDK) الثانوي.

إذا كان لدى مطوّري حزمة RE SDK حِزم RE SDK أخرى كتبعيات وقت الإصدار، سيحتاجون على الأرجح إلى تعريفها بطريقة مماثلة للطريقة التي يوضّح بها مطوِّر التطبيق التبعية نفسها. تعتمد حِزم تطوير البرامج (RE SDK) التي تعتمد على حِزم تطوير البرامج (RE SDK) غير المرتبطة بـ RE، ستؤدي إلى ربطها بشكل ثابت. قد يؤدي ذلك إلى ظهور مشاكل يمكن رصدها في وقت الإصدار أو أثناء اجتياز الاختبار إذا كانت حِزم SDK غير RE-S تتطلب وظائف لا تتوافق معها في "وقت تشغيل SDK"، أو إذا كان يجب تشغيلها في عملية تشغيل التطبيق.

على الأرجح أنّ مطوّري حزمة RE SDK يريدون مواصلة دعم الأجهزة التي لم تتم إعادة تفعيل إعادةها، مثل Android 12 أو الإصدارات الأقدم وكما هو مذكور في قسم "سلامة النظام" في المستند، على أجهزة Android المبتدئة بنظام التشغيل Android 13 وموارد النظام محدودة جدًا. ونعمل من خلال أساليب لضمان قدرة مطوّري حزم تطوير البرامج (SDK) على الاحتفاظ بقاعدة رموز برمجية واحدة للتوافق مع بيئات RE وغير ذلك.

الإصدارات

مطوّرو التطبيقات

نتوقع أن يواجه مطورو التطبيقات تغييرًا بسيطًا في خطوة الإنشاء. يجب أن تكون العناصر الاعتمادية لحزمة تطوير البرامج (SDK)، سواء كانت موزَّعة محليًا أو موزَّعة في متجر التطبيقات (RE أو لا)، موجودة على الجهاز من أجل التغطية والتجميع والإنشاء. نقترح أن يلخص Android Studio هذه التفاصيل من مطوّر التطبيق في حال الاستخدام العادي ويجعلها واضحة قدر الإمكان.

على الرغم من أنّنا نتوقّع أن يتضمّن إصدار "تصحيح الأخطاء" جميع الكود والرموز لكي يكون متوفرًا في إصدار "تصحيح الأخطاء" لتصحيح الأخطاء، إلا أنّه ستتم إزالة جميع حِزم SDK الموزَّعة في متجر التطبيقات (RE أو لا) من العنصر النهائي.

نحن في مرحلة سابقة من مرحلة التصميم هنا وسنشارك المزيد عند حدوثها.

مطوّرو حِزم تطوير البرامج (SDK)

نحن نعمل على إيجاد طريقة لضمان توفير أداة واحدة للتوزيع ضمن أداة واحدة، ما يعني إمكانية تضمين الإصدارات غير RE وRE (RE) من حزمة SDK. وسيمنع ذلك مطوّري التطبيقات من الحاجة إلى دعم إصدارات منفصلة لإصدارات RE وإصدارات أخرى من حزمة SDK.

كما هو الحال بالنسبة إلى التطبيقات، يجب أن تتوفّر أي حِزم SDK تابعة لهذا المتجر يتم توزيعها من خلال متجر التطبيقات على الجهاز من أجل إجراء البيانات غير المرغوب فيها والتجميع والإنشاء، ونتوقّع أن يعمل "استوديو Android" على تسهيل هذه العملية.

الاختبار

مطوّرو التطبيقات

كما هو موضّح في اقتراحنا، سيتمكّن مطوّرو التطبيقات من اختبار تطبيقاتهم على الأجهزة التي تعمل بنظام Android 13 بالطريقة المعتادة. بعد إنشاء التطبيق، سيكون من الممكن تثبيته على جهاز RE أو محاكي. ستضمن عملية التثبيت هذه تثبيت حِزم SDK الصحيحة في وقت تشغيل SDK للجهاز أو المحاكي، سواء تم سحب حِزم SDK من مستودع حِزم SDK بعيد أو من ذاكرة التخزين المؤقت من نظام الإصدار.

مطوّرو حِزم تطوير البرامج (SDK)

يستخدم مطورو حزم SDK بشكل عام تطبيقات الاختبار داخليًا على الأجهزة ومحاكيات لاختبار تطورهم. لا يغيّر اقتراحنا ذلك، وستتبع عملية التحقق داخل التطبيق الخطوات نفسها الموضحة أعلاه لمطوّري التطبيقات أعلاه، مع أداة إصدار واحدة لكل من تطبيقات RE وغير ذلك. سيتمكن مطوّرو حزم تطوير البرامج (SDK) من الاطّلاع على التعليمات البرمجية الخاصة بهم سواء كانت في "وقت تشغيل SDK" أم لا، ولكن قد تكون هناك بعض القيود المفروضة على الأدوات المتقدّمة لتصحيح الأخطاء وإنشاء الملفات التعريفية. هذا مجال تحقيق نشط.

التوزيع

أتاح اقتراح التصميم الذي طرحناه لفصل التطبيق عن حِزم SDK الخاصة به إمكانية توزيع حِزم SDK في متجر التطبيقات. هذا احتمال عام، وليس فريدًا لأي متجر تطبيقات معين. والمزايا واضحة:

• ضمان جودة حِزم SDK واتّساقها
• سهِّل عملية النشر لمطوّري حِزم SDK.
• تسريع عملية طرح تحديثات الإصدار الثانوي لحزمة تطوير البرامج (SDK) على التطبيقات المثبَّتة

لإتاحة إمكانية توزيع حِزم SDK، يحتاج متجر التطبيقات إلى توفير معظم الإمكانات التالية:

• آلية تتيح لمطوّري حِزم SDK تحميل حِزم SDK القابلة للتوزيع من متجر التطبيقات إلى المتجر، وتحديثها، وإعادة نشرها، وربما إزالتها.
• آلية لضمان سلامة حزمة SDK وأصلها وتطبيق ما ومصدره وحلّ التبعيات المتعلّقة بها.
• آلية لنشرها على الأجهزة بطريقة موثوقة وأداء مُتسق

القيود المتغيّرة بمرور الوقت

ونتوقّع أن تتطوّر القيود المفروضة على الرموز البرمجية في وقت تشغيل SDK لتتلاءم مع الإصدارات الأحدث من Android. ولضمان توافق التطبيقات، لن نغيّر هذه القيود عند إجراء تحديثات على الوحدات الأساسية لمستوى معيّن من حزمة تطوير البرامج (SDK). يتم الاحتفاظ بالسلوك المرتبط بـ targetSdkVersion محدّد إلى أن يتم إيقاف إتاحة ذلك targetSdkVersion من خلال سياسة متجر التطبيقات، وقد يتم إيقاف targetSdkVersion مؤقتًا بوتيرة أسرع مقارنةً بالتطبيقات. من المتوقّع أن تتغيّر القيود بشكل متكرّر في إصدارات Android SDK، لا سيّما في الإصدارات القليلة الأولى.

بالإضافة إلى ذلك، نحن نبني آلية إصدار Canary للسماح للاختبارات الخارجية والداخلية بالانضمام إلى مجموعة تحصل على مجموعة القيود المقترحة للإصدار التالي من Android. سيساعدنا ذلك في الحصول على الملاحظات والثقة بالتغييرات المقترحة على مجموعة القيود.

الأسئلة الشائعة

1. ما هي حزمة تطوير البرامج (SDK) المتعلقة بالإعلانات؟

   حِزم تطوير البرامج (SDK) المرتبطة بالإعلانات هي حزمة تسهِّل أي جزء من استهداف المستخدمين من خلال رسائل ذات أغراض تجارية، على التطبيقات التي لا يملكها المعلِن. ويتضمّن ذلك، على سبيل المثال لا الحصر، حِزم تطوير البرامج (SDK) الخاصة بالإحصاءات التي يمكن إنشاء مجموعات مستخدمين فيها للاستهداف اللاحق، وحِزم تطوير البرامج (SDK) لعرض الإعلانات، وحِزم تطوير البرامج (SDK) المخصصة لمكافحة إساءة الاستخدام ومكافحة الاحتيال للإعلانات، وحِزم تطوير البرامج (SDK) للتفاعل، وحِزم تحديد المصدر.

2. هل يمكن تشغيل أيّ حزمة SDK في "وقت تشغيل SDK"؟

   ورغم أنّ التركيز الأوّل على حِزم SDK المرتبطة بالإعلانات، فإنّ مطوّري حِزم SDK غير المرتبطة بالإعلانات والتي يسعون إلى الحفاظ على الخصوصية ويريدون العمل وفقًا للشروط الموضّحة أعلاه يمكنهم مشاركة ملاحظات حول حِزم SDK التي تعمل في "وقت تشغيل SDK". مع ذلك، لم يتم تصميم "وقت تشغيل SDK" ليتوافق مع جميع تصميمات حِزم SDK. وبالإضافة إلى القيود الموثَّقة، من المرجّح ألا يكون "وقت تشغيل SDK" مناسبًا لحِزم SDK التي تحتاج إلى اتصالات في الوقت الفعلي أو بسرعة معالجة عالية مع تطبيق الاستضافة.

3. لماذا يتم اختيار عزل العملية بدلاً من العزلة في وقت التشغيل المستند إلى Java للعملية؟

   في الوقت الحالي، لا يسهّل وقت التشغيل المستند إلى Java حدود الأمان اللازمة لضمانات الخصوصية المطلوبة لمستخدمي Android. وتتطلّب محاولة تنفيذ مثل هذا الأسلوب جهدًا لعدّة سنوات، بدون ضمان النجاح. لذلك، تستخدم "مبادرة حماية الخصوصية" حدود الاستخدام، وهي تقنية تم اختبارها بمرور الوقت وتفهمها جيدًا.

4. هل يمكن أن يؤدي نقل حِزم SDK إلى عملية "وقت تشغيل SDK" إلى توفير حجم التنزيل أم توفير المساحة؟

   في حال دمج عدة تطبيقات مع حِزم تطوير البرامج (SDK) التي يتم تفعيلها في وقت التشغيل من الإصدار نفسه، قد يؤدي ذلك إلى تقليل حجم التنزيل ومساحة القرص.

5. ما هو نوع أحداث مراحل نشاط التطبيق، مثل انتقال التطبيق إلى الخلفية، هل يمكن لحِزم SDK الوصول إليه في "وقت تشغيل SDK"؟

   ونسعى جاهدين إلى تقديم الدعم للتصميم من أجل إرسال إشعارات بشأن وقت تشغيل حزمة SDK في مراحل نشاط التطبيق على مستوى التطبيق (على سبيل المثال، انتقال التطبيق إلى الخلفية أو ظهور تطبيق في المقدّمة). وستتم مشاركة التصميم ونموذج الرمز في معاينة قادمة للمطوِّرين.