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

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

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

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

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

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

الأهداف

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

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

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

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

قبل:


بعد:

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

نموذج توزيع جديد موثوق به لحِزم تطوير البرامج (SDK)

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

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

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

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

يوضّح الشكل 2 التغييرات المقترَحة في توزيع حزمة SDK:

قبل:

قبل الرسم البياني

بعد:

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

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

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

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

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

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

إذن الوصول

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

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

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

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

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 المدمج في حزمة Android SDK.

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" منخفضة حتى إذا عاد التطبيق إلى المقدّمة. وبالتالي، من المحتمل جدًا أن يتم إنهاؤها بسبب ضغط الذاكرة مقارنةً بالتطبيق.

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

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

    • يوفِّر هذا الاقتراح لمطوّري التطبيقات طُرق معاودة الاتصال ذات الصلة بدورة الحياة لاكتشاف وقت إنهاء "وقت تشغيل SDK".
    • في حال انتهاء "وقت تشغيل SDK" أثناء عرض الإعلانات، قد لا تعمل الإعلانات على النحو المتوقّع. على سبيل المثال، قد يتم تجميد عدد المشاهدات على الشاشة ويتوقف عن التفاعل. يمكن للتطبيق إزالة مشاهدة الإعلان إذا لم يكن لذلك تأثير في تجربة المستخدم.
    • يمكن للتطبيق محاولة أخرى لتحميل حِزم SDK وطلب الإعلانات.
    • بالنسبة إلى نظام التشغيل Android 14، إذا أنهى "وقت تشغيل حزمة تطوير البرامج" أثناء تحميل حِزم 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. يوضح الشكل 3 النهج الذي نأخذه في الاعتبار:

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

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

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

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

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

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

    SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor,
        OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)
    
  2. يتم إعلام حزمة تطوير البرامج (SDK) بأنّه تم تحميلها، وتعرض واجهتها. تم تصميم هذه الواجهة لاستخدامها في عملية التطبيق. لمشاركة الواجهة خارج حدود العملية، يجب عرضها ككائن IBinder.

    يوفّر دليل الخدمات المرتبطة طرقًا مختلفة لتوفير IBinder. أيًا كانت الطريقة التي تختارها، يجب أن تكون البيانات متسقة بين حزمة تطوير البرامج (SDK) وتطبيق المتّصل. يستخدم الرسم البياني في الشكل رقم 3 لغة تعريف واجهة برمجة التطبيقات (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 للتنسيق. بالنظر إلى الأساسيات المذكورة أعلاه، يجب أن يكون بإمكان حزمة SDK المنسَّقة، أي RE أو لا، الوصول إلى كل حزم RE SDK وغيرها من حزم SDK للاستخدام العادي. العرض في هذا السياق هو مجال بحث نشط.
  2. اكتشاف الميزات: تتألف بعض منتجات حِزم SDK من حِزم تطوير برامج (SDK) أصغر حجمًا، تحدّد هذه الحزمة مجموعة الميزات الأفضل المتاحة لمطوِّر التطبيق من خلال عملية الاكتشاف البيني لحزمة SDK. من المتوقع أن تؤدي أساسيات التسجيل والاكتشاف إلى تمكين حالة الاستخدام هذه.
  3. نماذج اشتراكات الناشرين: تم تصميم بعض حِزم تطوير البرامج (SDK) للحصول على ناشر مركزي للأحداث التي يمكن لحِزم SDK أو التطبيقات الأخرى الاشتراك فيها لتلقّي الإشعارات من خلال عمليات معاودة الاتصال. ينبغي أن تدعم الأساسيات المذكورة أعلاه حالة الاستخدام هذه.

الانتقال من تطبيق إلى آخر

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

  • لا يمكن لحزمة تطوير البرامج (SDK) تحديد مكوّنات مثل <service> أو <contentprovider> أو <activity> في ملف البيان الخاص بها.
  • لا يمكن لحزمة تطوير البرامج (SDK) نشر ContentProvider أو إرسال بث.
  • يمكن لحزمة تطوير البرامج (SDK) تشغيل نشاط ينتمي إلى تطبيق آخر، ولكن مع فرض قيود على ما يمكن إرساله في Intent. على سبيل المثال، لا يمكن إضافة أي إجراءات إضافية أو إجراءات مخصّصة إلى هذا الهدف.
  • لا يمكن أن تبدأ حزمة تطوير البرامج (SDK) سوى قائمة مسموح بها من الخدمات أو ترتبط بها.
  • لا يمكن لحزمة تطوير البرامج (SDK) سوى الوصول إلى مجموعة فرعية من النظام ContentProvider (مثل com.android.providers.settings.SettingsProvider)، حيث تفتقر البيانات التي تم الحصول عليها إلى المعرّفات ولا يمكن استخدامها لإنشاء بصمة إصبع للمستخدم. تنطبق عمليات التحقّق هذه أيضًا على إمكانية الوصول إلى ContentProvider باستخدام ContentResolver.
  • لا يمكن لحزمة تطوير البرامج (SDK) الوصول إلا إلى مجموعة فرعية من أجهزة استقبال البث المحمية (مثل android.intent.action.AIRPLANE_MODE).

علامات البيان

عند تثبيت حزمة تطوير البرامج (SDK)، يحلّل PackageManager ملف بيان حزمة تطوير البرامج (SDK) ولا يتعذّر تثبيت حزمة تطوير البرامج في حال توفُّر علامات بيان محظورة. على سبيل المثال، قد لا تحدّد حزمة تطوير البرامج (SDK) مكوّنات مثل <service>, <activity>, <provider> أو <receiver>، ولا يجوز لها تعريف السمة <permission> في البيان. العلامات التي يتعذّر عليها التثبيت غير متوافقة في "وقت تشغيل SDK". بالنسبة إلى العلامات التي لا تنجح في التثبيت ولكن يتم تجاهلها بدون إشعارات، يمكن أن تكون متاحة في إصدارات Android المستقبلية.

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

دعم النشاط

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

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

المناسب

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

تظهر عملية طلب النشاط في الرسم البياني التالي.

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

تطوير

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

التأليف

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

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

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

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

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

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

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

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

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

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

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

الإصدارات

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

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

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

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

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

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

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

الاختبار

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

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

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

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

  2. هل يمكن تشغيل أيّ حزمة تطوير برامج (SDK) في وقت تشغيل حزمة تطوير البرامج (SDK)؟

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

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

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

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

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

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

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