يستخدم نظام Android الأساسي مفهوم وضع التطبيقات في بيئة معزولة للحفاظ على حدود تنفيذ وأمان فعّالة لرمز التطبيق، إلى جانب حدود العمليات. من الشائع أن تتضمّن التطبيقات رموزًا برمجية تابعة لجهات خارجية، وغالبًا ما يكون ذلك في شكل حِزم تطوير برامج (SDK)، مثل حِزم SDK لعرض الإعلانات أو حِزم SDK للإحصاءات. ويتيح هذا إعادة الاستخدام لمطوّري التطبيقات التركيز على ما يميز تطبيقاتهم مع الاستفادة من عمل الخبراء في المجال لتوسيع نطاق تنفيذهم إلى ما هو أبعد مما يمكنهم فعله بسهولة بأنفسهم.
مثل معظم أنظمة التشغيل، يتم تنفيذ حِزم تطوير البرامج (SDK) لنظام التشغيل Android في بيئة اختبار محمية للتطبيق المضيف، كما أنها تكتسب الامتيازات والأذونات نفسها التي يحصل عليها التطبيق المضيف، بالإضافة إلى إمكانية الوصول إلى ذاكرة التطبيق المضيف ومساحة تخزينه. على الرغم من أنّ هذه البنية تسمح بدمج حِزم SDK والتطبيقات بشكلٍ مرن، إلا أنّها تُتيح أيضًا جمع بيانات المستخدمين ومشاركتها بدون الإفصاح عنها. بالإضافة إلى ذلك، قد لا يكون مطوّرو التطبيقات على دراية كاملة بمدى وظائف حزمة SDK التابعة لجهة خارجية والبيانات التي تصل إليها، ما يجعل من الصعب توضيح ممارسات جمع البيانات ومشاركتها في تطبيقاتهم.
في الإصدار 14 من Android، أضفنا ميزة جديدة في النظام الأساسي تتيح تشغيل حِزم SDK التابعة لجهات خارجية في بيئة وقت تشغيل مخصّصة تُعرف باسم وقت تشغيل حزمة SDK. يوفّر "وقت تشغيل حزمة تطوير البرامج (SDK)" الضمانات ووسائل الحماية المعزّزة التالية بشأن جمع بيانات المستخدمين ومشاركتها:
- بيئة تنفيذ معدَّلة
- أذونات وحقوق وصول إلى البيانات محددة بدقة لحِزم SDK
نسعى جاهدين للحصول على ملاحظات من منتدى الإعلانات على تطبيقات الأجهزة الجوّالة بشأن هذا التصميم. ونرحّب أيضًا بملاحظات من منتدى المطوّرين الأوسع نطاقًا للمساعدة في وضع النُسخ المستقبلية من SDK Runtime، بما في ذلك إتاحة حالات استخدام إضافية.
الأهداف
يهدف هذا الاقتراح إلى تحقيق الأهداف التالية:
- الحد من الوصول غير المُعلَن إليه ومشاركة بيانات تطبيقات المستخدمين من خلال حِزم SDK التابعة لجهات خارجية من خلال عزل العمليات والتحكّم الواضح في الوصول إلى البيانات وواجهات برمجة التطبيقات يمكنك الاطّلاع على مزيد من المعلومات حول عزل العمليات في قسم منفصل من هذا المستند.
- الحدّ من التتبّع غير المُعلَن لاستخدام المستخدم للتطبيق من خلال حِزم SDK التابعة لجهات خارجية، وذلك من خلال حظر وصول حِزم SDK إلى المعرّفات الفريدة والدائمة
- تسريع توزيع تحديثات حِزم تطوير البرامج (SDK) على التطبيقات بأمان من خلال تقليل الصعوبات التي تواجه مطوّري التطبيقات والمستخدمين النهائيين يمكنك الاطّلاع على مزيد من المعلومات حول نموذج التوزيع المُعتمَد لحِزم SDK المقترَح في قسم آخر من هذا المستند.
- مساعدة مطوّري التطبيقات في تقديم حسابات أفضل حول ممارسات الوصول إلى البيانات ومشاركتها في تطبيقاتهم
- مساعدة مطوّري حِزم SDK في منع التلاعب بها من خلال حِزم SDK أخرى من خلال الحدّ من استخدام بعض بنى اللغة غير الآمنة، مثل رمز JNI
- مساعدة حِزم SDK لعرض الإعلانات في رصد الزيارات غير الصالحة والاحتيال الإعلاني ومنعها من خلال التحكّم الكامل في المشاهدات البعيدة التي تعرض الوسائط
- تقليل التأثير غير المقصود على مطوّري التطبيقات وحِزم SDK قدر الإمكان
تنفيذ حِزم SDK في عملية معزولة
تتيح ميزة "وقت تشغيل حزمة تطوير البرامج (SDK)" المقترَحة إمكانية تشغيل حِزم SDK المتوافقة، والتي يُشار إليها في باقي هذا المستند باسم حِزم SDK المفعَّلة في وقت التشغيل (RE)، في عملية منفصلة للتطبيق. وتسهِّل المنصة عملية التبادل المتبادل للرسائل بين عملية التطبيق وميزة "وقت تشغيل حزمة تطوير البرامج (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 وأخرى
- التطوير: كيفية إنشاء نماذج اختبارها وتصحيح أخطاءها في هذا النموذج
- التوزيع: كيفية توزيع التطبيقات وتعديلها والرجوع إلى إصدارات سابقة من Android وحِزم SDK
يتضمّن هذا المستند أيضًا أسئلة شائعة للمساعدة في الإجابة عن الأسئلة الشائعة.
هذا اقتراح تصميم أولي، وندرك أنّه قد يكون هناك أثر مهم لتغييره على بعض أعضاء المنظومة المتكاملة. لهذا السبب، نطلب منك مشاركة ملاحظاتك من خلال تتبُّع معالجة المشاكل.
إذن الوصول
تشير إدارة خصوصية النظام إلى إدارة كيفية وصول الجهات المختلفة إلى الموارد المختلفة. للالتزام بقيمة الخصوصية التي نقدّمها، نقترح تعديل نموذج الوصول إلى التطبيقات وحِزم تطوير البرامج (SDK) وبيانات المستخدمين بما يتوافق مع مبدأ الامتياز الأقل لمنع الوصول غير المُعلَن عنه إلى البيانات التي يُحتمل أن تكون حساسة.
أذونات حزمة تطوير البرامج (SDK)
بما أنّ وقت تشغيل حزمة SDK هو عملية منفصلة، سيكون له مجموعة محدّدة من الأذونات بدلاً من اكتساب الأذونات التي منحها المستخدم للتطبيق. استنادًا إلى البحث التمهيدي حول الأذونات التي تستخدمها حِزم SDK ذات الصلة بالإعلانات، نقترح أن تكون الأذونات التالية متاحة لحِزم SDK في وقت تشغيل حزمة SDK تلقائيًا:
INTERNET: الوصول إلى الإنترنت للتواصل مع خدمة ويبACCESS_NETWORK_STATE: الوصول إلى معلومات عن الشبكات-
READ_BASIC_PHONE_STATE: الوصول إلى معلومات عن حالة الهاتف، مثل نوع شبكة الجوّال - أذونات الوصول إلى واجهات برمجة التطبيقات التي تحافظ على الخصوصية، والتي توفّر قدرات أساسية للإعلان بدون الحاجة إلى الوصول إلى المعرّفات على مستوى جميع التطبيقات
AD_ID: إمكانية طلب المعرّف الإعلاني وسيعتمد ذلك أيضًا على إذن التطبيق للقيام بذلك.
نحن نحقّق حاليًا ممّا إذا كان من الممكن منح أذونات إضافية وكيفية منح هذه الأذونات، مع الحدّ من التأثير على المستخدمين النهائيين من منظور الخصوصية وسهولة الاستخدام. ونطلب منك ملاحظاتك حول أي حالات استخدام قد لا تستوفي هذه المجموعة من الأذونات.
الذاكرة
سيكون لدى "وقت تشغيل حزمة تطوير البرامج (SDK)" مساحة ذاكرة معزولة بفضل امتلاكه لعملية خاصة به. ستؤدي هذه البنية تلقائيًا إلى منع حزمة SDK من الوصول إلى مساحة ذاكرة التطبيق، ولن يتمكّن التطبيق بالمثل من الوصول إلى مساحة ذاكرة حزمة SDK. نقترح الاحتفاظ بهذا السلوك default للحفاظ على التوافق مع مبدأ الحد الأدنى من الامتيازات.
مساحة التخزين
يهدف هذا الاقتراح إلى موازنة الحاجة إلى وصول حِزم SDK إلى مساحة التخزين لكي تعمل بشكلٍ عادي والحدّ من التتبّع على مستوى التطبيقات والعمليات باستخدام مساحة التخزين الدائمة. نقترح إجراء التعديل التالي على كيفية الوصول إلى مساحة التخزين المتوفّرة حاليًا:
- لن يتمكّن التطبيق من الوصول مباشرةً إلى مساحة تخزين حِزم SDK الخاصة به والعكس صحيح.
- لن تتمكّن حِزم تطوير البرامج (SDK) من الوصول إلى مساحة التخزين الخارجية للجهاز.
- ضمن كلّ "وقت تشغيل حزمة تطوير البرامج (SDK)"، ستكون هناك مساحة تخزين يمكن لجميع حِزم SDK الوصول إليها، ومساحة تخزين خاصة بحزمة SDK معيّنة.
مثل نموذج مساحة التخزين الحالي، لن تفرض مساحة التخزين نفسها حدودًا مفروضة على الحجم. يمكن لحِزم تطوير البرامج (SDK) استخدام مساحة التخزين لتخزين مواد العرض مؤقتًا. ويتم محو مساحة التخزين هذه بشكل دوري عندما لا يكون حِزم تطوير البرامج (SDK) قيد التشغيل بشكل نشط.
التنفيذ
لضمان توفير نظام خاص بين التطبيقات وحِزم SDK والمستخدمين، يجب أن يعزّز سياق التنفيذ نفسه (تنسيقات الرموز البرمجية وعناصر اللغة وواجهات برمجة التطبيقات التي يمكن الوصول إليها وبيانات النظام) حدود الخصوصية هذه، أو على الأقل لا يقدّم فرصًا للالتفاف حولها. في الوقت نفسه، نريد الاحتفاظ بالوصول إلى المنصة الغنية ومعظم إمكانات وقت التشغيل التي توفّرها حِزم SDK حاليًا. نقترح هنا مجموعة من التعديلات على بيئة التشغيل لتحقيق التوازن بين هذين المقياسَين.
الرمز
يتم تفسير رمز Android (التطبيقات وحِزم تطوير البرامج (SDK)) بشكل أساسي من خلال "وقت تشغيل Android" (ART)، سواء كانت الرموز مكتوبة بلغة 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 Runtime تلقائيًا بعد ذلك مباشرةً.
يمكن أن يُنهي نظام التشغيل بيئة تشغيل حِزم تطوير البرامج (SDK) بسبب ازدحام ذاكرة التخزين أو استثناء لم تتم معالجته في حِزمة تطوير برامج (SDK) على سبيل المثال.
في نظام التشغيل Android 14، عندما يكون التطبيق في المقدّمة، يتم تشغيل "وقت تشغيل حزمة SDK" بأولوية عالية ومن غير المرجّح أن يتم إنهاء تشغيله. عندما ينتقل التطبيق إلى الخلفية، تنخفض أولوية عملية SDK Runtime ويصبح مؤهلاً للإنهاء. تظل أولوية عملية SDK Runtime منخفضة حتى إذا عاد التطبيق إلى المقدّمة. ونتيجةً لذلك، من المرجّح جدًا أن يتم إنهاء تشغيله بسبب الضغط على الذاكرة مقارنةً بالتطبيق.
في الإصدار 14 من نظام التشغيل Android والإصدارات الأحدث، تكون أولويات عمليات التطبيق وحزمة SDK Runtime متطابقة. يجب أن تكون أولويات العمليات الخاصة بملف برمجي
ActivityManager.RunningAppProcessInfo.importanceللتطبيق وملف IDE SDK Runtime متطابقة تقريبًا.في حال إنهاء وقت تشغيل حزمة SDK أثناء تشغيل التطبيق، مثلاً في حال حدوث استثناء لم تتم معالجته في حزمة SDK، يتم فقدان حالة وقت تشغيل حزمة SDK، بما في ذلك جميع حِزم SDK التي تم تحميلها سابقًا وعروض البيانات البعيدة. يمكن لصنّاع التطبيقات التعامل مع عملية إنهاء وقت تشغيل حزمة SDK باستخدام أيّ من الطرق التالية:
- يقدّم الاقتراح لمطوّري التطبيقات طرقًا ذات صلة لطلب استدعاء دورة الحياة بهدف رصد حالات انتهاء وقت تشغيل حزمة SDK.
- إذا تم إنهاء وقت تشغيل حزمة تطوير البرامج (SDK) أثناء عرض الإعلانات، قد لا تعمل الإعلانات على النحو المتوقّع. على سبيل المثال، قد يتم تجميد العروض على الشاشة وعدم التفاعل معها بعد ذلك. يمكن للتطبيق إزالة عرض الإعلان إذا لم يؤثّر في تجربة المستخدم.
- يمكن للتطبيق إجراء محاولة أخرى لتحميل حِزم تطوير البرامج (SDK) وطلب الإعلانات.
- في نظام التشغيل Android 14، إذا تم إنهاء وقت تشغيل حزمة SDK أثناء تحميل حِزم SDK، وإذا لم يسجِّل مطوِّر التطبيق طُرق callback الخاصة بالمراحل المُشار إليها أعلاه، يتم إنهاء تشغيل التطبيق تلقائيًا. لا يتم إنهاء سوى العمليات التابعة للتطبيق التي حمّلت حِزم SDK والخروج منها بشكلٍ طبيعي.
- تُعرِض عناصر Binder التي تعرضها حزمة SDK للتواصل معها (مثل
SandboxedSdk) خطأDeadObjectExceptionإذا استخدمها التطبيق.
يخضع نموذج رحلة المستخدِم هذا للتغيير في التحديثات المستقبلية.
في حال حدوث أعطال متكررة، على مطوّر التطبيق التخطيط لحال بدء التطبيقات بالعمل بدون حزمة SDK أو إبلاغ المستخدم إذا كانت حزمة SDK مهمة لعمل الوظائف الأساسية للتطبيق. لمزيد من التفاصيل حول هذا التفاعل بين التطبيق وحزمة SDK، يُرجى الاطّلاع على قسم الاتصالات في هذا المستند.
يمكن لحِزم SDK غير المخصّصة لتطبيقات الواقع المعزّز مواصلة استخدام العناصر الأساسية العادية لنظام التشغيل المتاحة لتطبيقهم المضمّن، بما في ذلك الخدمات والأنشطة وعمليات البث، في حين لا يمكن لحِزم SDK المخصّصة لتطبيقات الواقع المعزّز استخدام هذه العناصر.
الحالات الخاصة
الحالات التالية غير متوافقة وقد تؤدي إلى سلوك غير متوقّع:
- إذا كانت تطبيقات متعددة تشترك في المعرّف الفريد نفسه، قد لا يعمل "وقت تشغيل حزمة تطوير البرامج (SDK)" بشكل سليم. قد تتم إضافة إمكانية استخدام أرقام تعريف المستخدمين المشتركة في المستقبل.
- بالنسبة إلى التطبيقات التي تتضمّن عمليات متعددة، يجب تحميل حزمة SDK في العملية الرئيسية.
عرض الوسائط
هناك حِزم تطوير برامج (SDK) تُعرِض محتوى مثل النصوص والصور والفيديوهات في ملف شخصي يحدّده التطبيق. لتحقيق ذلك، نقترح نهجًا للعرض عن بُعد
حيث ستعرض حزمة SDK الوسائط من داخل "وقت تشغيل حزمة تطوير البرامج (SDK)"، ولكن باستخدام واجهة برمجة التطبيقات
SurfaceControlViewHost
للسماح بعرض الوسائط في عرض يحدّده التطبيق. يمنح ذلك حزمة تطوير البرامج (SDK)
إمكانية عرض هذه الوسائط بطريقة خاصة للمستخدم،
بينما يساعد في منع تفاعلات المستخدم غير الصالحة أو المخادعة مع
الوسائط المعروضة ورصدها.
إنّ الإعلانات المدمجة، وهي الإعلانات التي لا تعرِضها حزمة SDK بل يعرِضها التطبيق، ستتوافق مع حِزم SDK في "وقت تشغيل حِزم SDK". ستتم عملية جمع الإشارات و retrieving المواد الإبداعية بشكلٍ متسق مع الإعلانات غير المدمجة مع المحتوى. هذه منطقة نشطة للتحقيق.
الإعلانات أثناء عرض الفيديو هي الإعلانات التي يتم عرضها أثناء عرض الفيديو في مشغل داخل التطبيق. وبما أنّ الفيديو يتم تشغيله داخل مشغل في التطبيق بدلاً من مشغل أو عرض في حزمة تطوير البرامج (SDK)، يختلف نموذج العرض عن نماذج عرض الإعلانات الأخرى. نحن نستكشف بنشاط آليات تتيح استخدام كلّ من إدراج الإعلانات من جهة الخادم وإدراج الإعلانات المستنِد إلى حِزم تطوير البرامج (SDK).
حالة النظام
نسعى إلى الحدّ من تأثير "وقت تشغيل حزمة تطوير البرامج (SDK)" في صحة النظام على أجهزة المستخدم النهائي، ونحن بصدد تصميم طرق لتحقيق ذلك. من المرجّح مع ذلك أنّ بعض أجهزة Android 14 المنخفضة المستوى التي تتضمّن موارد نظام محدودة جدًا، مثل 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 ديناميكيًا في عملية IDE SDK، والحصول على إشعارات بشأن التغييرات في حالة العملية، والتفاعل مع حِزم SDK المحمَّلة في IDE SDK.
يوضّح الرسم البياني في الشكل السابق عملية التواصل بين التطبيق ومجموعة تطوير البرامج (SDK) على مستوى أدنى، بدون طبقة الربط.
يتواصل التطبيق مع حزمة SDK التي تعمل في عملية "وقت تشغيل حزمة SDK" من خلال الخطوات التالية:
قبل أن يتفاعل التطبيق مع حزمة SDK، سيطلب من الطور تحميل حزمة SDK. لضمان سلامة النظام، تحدّد التطبيقات حِزم SDK التي تريد تحميلها في ملف البيان، وستكون هذه الحِزم هي الحِزم الوحيدة المسموح بتحميلها.
يقدّم مقتطف الرمز التالي مثالاً توضيحيًا لواجهة برمجة التطبيقات:
SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor, OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)يتم إعلام حزمة SDK بأنّه تم تحميلها، وتعرض واجهتها. هذه الواجهة مخصّصة لاستخدامها في عملية التطبيق. لمشاركة الواجهة خارج حدود العملية، يجب إرجاعها كعنصر
IBinder.يقدّم دليل الخدمات المرتبطة طرقًا مختلفة لتقديم
IBinder. يجب أن تكون الطريقة التي تختارها متسقة بين حِزم تطوير البرامج (SDK) و التطبيق المُرسِل. تستخدِم المخطّطات البيانية واجهة برمجة التطبيقات AIDL كمثال.يتلقّى
SdkSandboxManagerواجهةIBinderويعيدها إلى التطبيق.يحصل التطبيق على
IBinderويحوّله إلى واجهة حزمة SDK، ويُطلِق وظائفها:IBinder binder = sandboxSdk.getInterface(); ISdkInterface mySdkInterface = ISdkInterface.Stub.asInterface(binder); mySdkInterface.something();
يمكن للتطبيق أيضًا عرض الوسائط من حزمة SDK باتّباع الخطوات التالية:
كما هو موضّح في قسم عرض الوسائط من هذا المستند، لكي يحصل التطبيق على حزمة SDK لعرض الوسائط في عرض، يمكن للتطبيق إجراء طلب إلى
requestSurfacePackage()واستردادSurfaceControlViewHost.SurfacePackageالمناسب.يقدّم مقتطف الرمز التالي مثالاً توضيحيًا لواجهة برمجة التطبيقات:
SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams, Executor executor, OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)يمكن للتطبيق بعد ذلك تضمين
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 ، والذي يستمع إلى الرموز البرمجية في التطبيق ويعالجها ويستجيب باستخدام callbacks التي تم توفيرها. - قد لا تتمكّن حِزم تطوير البرامج (SDK) لعرض الإعلانات التي لم يتم تفعيلها في وقت التشغيل من تسجيل نفسها، لذلك، ننصحك بإنشاء حزمة SDK وسيطة تتضمّن أي حِزم SDK لشركاء أو تطبيقات كملحقات مباشرة للتطبيق وتتولى عملية التسجيل. تُنشئ "حزمة SDK" الوسيطة هذه تواصلًا بين "حِزم SDK" التي لا يتم تفعيلها في وقت التشغيل أو بين ملحقَات التطبيق الأخرى والوسيط الذي يتم تفعيله في وقت التشغيل والذي يعمل كمحوِّل.
تم تقسيم مجموعة الميزات الخاصة بالتواصل بين حِزم SDK إلى الفئات التالية:
- تواصل حِزم SDK مع بعضها ضمن "وقت تشغيل حِزم SDK" (متاح في أحدث إصدار من معاينة المطوّرين)
- تواصل حِزم SDK مع بعضها البعض بين التطبيق ووقت تشغيل حزمة SDK (متاح في أحدث إصدار من "معاينة المطوّرين")
- آلية عمل طرق العرض والعرض عن بُعد في التوسّط (الاقتراح قيد تطوير)
يتم النظر في حالات الاستخدام التالية أثناء تطوير العناصر الأساسية:
- التوسّط وعروض الأسعار: توفّر العديد من حِزم SDK الإعلانية إمكانية التوسّط أو عروض الأسعار، ما يؤدي إلى استدعاء حِزم SDK أخرى مختلفة من أجل مرّة ظهور إعلان (توسّط) أو من أجل جمع الإشارات لإجراء مزاد (عروض الأسعار). وعادةً ما تُطلِق حزمة SDK التنسيقية حِزم SDK أخرى من خلال محوِّل تقدّمه حزمة SDK التنسيقية. استنادًا إلى العناصر الأساسية أعلاه، يجب أن تكون حزمة SDK التنسيقية، سواء كانت حزمة RE أو غير ذلك، قادرة على الوصول إلى جميع حِزم SDK التي تستخدم RE وغير ذلك من أجل التشغيل العادي. يُعدّ التقديم في هذا السياق مجالًا نشطًا للتحقيق.
- التعرّف على الميزات: تتألف بعض منتجات حِزم SDK من حِزم SDK أصغر حجمًا، والتي تحدّد من خلال عملية اكتشاف بين حِزم SDK مجموعة الميزات النهائية التي يتم عرضها لمطوّر التطبيق. من المتوقّع أن تتيح عناصر التسجيل والاكتشاف هذه الحالة الاستخدام.
- نماذج الاشتراكات التي يقدّمها الناشرون: تم تصميم بعض حِزم SDK لتوفير ناشر central للأحداث يمكن لحِزم SDK أو التطبيقات الأخرى الاشتراك فيه للحصول على إشعارات من خلال عمليات الاستدعاء. من المفترض أن تتوافق العناصر الأساسية أعلاه مع حالة الاستخدام هذه.
من تطبيق إلى آخر
ينطوي التواصل بين التطبيقات على عملية واحدة على الأقل من بين العمليتين المعنيّتَين بالتواصل، وهي حزمة تطوير برامج (SDK) مفعّلة في وقت التشغيل، وهي وسيط محتمل لمشاركة البيانات التي لم يتم الإفصاح عنها. ونتيجةً لذلك، لا يمكن لوقت تشغيل حزمة SDK إنشاء قناة تواصل مباشرة مع أي تطبيق آخر غير تطبيق العميل، أو مع حِزم SDK في وقت تشغيل حزمة SDK آخر تم إنشاؤه لتطبيق آخر. ويتم تحقيق ذلك بالطُرق التالية:
- لا يمكن لحزمة SDK تحديد مكونات مثل
<service>أو<contentprovider>أو<activity>في ملف البيان. - لا يمكن لحزمة تطوير البرامج (SDK) نشر
ContentProviderأو إرسال بث. - يمكن لحزمة تطوير البرامج (SDK) تشغيل نشاط ينتمي إلى تطبيق آخر، ولكن مع وضع حدود على ما يمكن إرساله في Intent. على سبيل المثال، لا يمكن إضافة أي إجراءات إضافية أو مخصّصة إلى هذا الإجراء.
- لا يمكن بدء حزمة تطوير البرامج (SDK) أو ربطها بقائمة مسموح بها من الخدمات إلا.
- لا يمكن لحزمة SDK الوصول إلا إلى مجموعة فرعية من
ContentProviderالنظام (مثلcom.android.providers.settings.SettingsProvider)، حيث تفتقر data التي تم الحصول عليها إلى المعرّفات ولا يمكن استخدامها لإنشاء بصمة مستخدم. تنطبق عمليات التحقّق هذه أيضًا على الوصول إلى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 غير متاح.
لكي تبدأ حزمة SDK النشاط، يجب أن تسجِّل مثيلًا من النوع
SdkSandboxActivityHandler الذي يُستخدَم لإرسال إشعارات بشأن إنشاء النشاط عندما
يطلب التطبيق SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) لبدء النشاط.
يظهر تسلسل طلب نشاط في الرسم البياني التالي.
تطوير
ومن المبادئ الرئيسية في هذا الاقتراح الحدّ من التأثير على منظومة المطوّرين بقدر الإمكان. يوفّر هذا الاقتراح للمطوّرين مجموعة شاملة من أدوات التطوير لكتابة تطبيقات RE وحِزم SDK وإنشاءها وتصحيح أخطاءها. لضمان سلامة هذا الاقتراح، تم إجراء بعض التغييرات على طريقة ضبط تطبيقات RE وحِزم SDK وإنشاءها وكتابتها.
التأليف
سيتم تعديل Android Studio والأدوات ذات الصلة لتصبح على دراية بوقت تشغيل حزمة SDK، مما يساعد في التأكّد من أنّ المطوّرين قد ضبطوا إعدادات تطبيقات RE وحِزم SDK بشكلٍ صحيح، كما يساعد في التأكّد من تحديث طلبات البيانات القديمة أو غير المتوافقة إلى بدائلها الجديدة عند الاقتضاء. خلال مرحلة التأليف، هناك بعض الخطوات التي يتطلّب اقتراحنا من المطوّرين اتّخاذها.
مطوّرو التطبيقات
على التطبيقات تحديد تبعية حزمة SDK لإعادة الإصدار وشهادة حزمة SDK في بيان التطبيق. في هذا الاقتراح، نتعامل مع هذا المصدر باعتباره مصدر الحقيقة من مطوّر التطبيق. على سبيل المثال:
- الاسم: اسم حزمة حزمة SDK أو المكتبة.
- الإصدار الرئيسي: رمز الإصدار الرئيسي لحزمة SDK
- ملخّص الشهادة: ملخّص شهادة حزمة SDK. بالنسبة إلى إصدار معيّن، نقترح على مطوّر حزمة SDK الحصول على هذه القيمة وتسجيلها من خلال متجر التطبيقات ذي الصلة.
ينطبق ذلك على حِزم تطوير البرامج (SDK) الموزَّعة من خلال متجر التطبيقات فقط، سواء كانت حِزم تطوير تطبيقات إعادة التوجيه أم لا. ستستخدم التطبيقات التي تربط حِزم SDK بشكلٍ ثابت آليات الاعتماد الحالية.
وبما أنّ هدفنا هو الحدّ من التأثير على المطوّرين، من المهمّ أن يحدّد مطوّرو التطبيقات مستوى واجهة برمجة التطبيقات المستهدَف المتوافق مع "وقت تشغيل حزمة تطوير البرامج (SDK)"، ثم ينشئوا إصدارًا واحدًا فقط سواء كان هذا الإصدار يعمل على الأجهزة التي تتوافق مع "وقت تشغيل حزمة تطوير البرامج (SDK)" أو لا تتوافق معه.
مطوّرو حِزم تطوير البرامج (SDK)
في التصميم المقترَح، على مطوّري حِزم RE SDK تحديد عنصر جديد يمثّل حزمة SDK أو عنصر المكتبة في البيان بشكل صريح. بالإضافة إلى ذلك، يجب تقديم مجموعة قيم مشابهة للتبعية بالإضافة إلى إصدار ثانوي:
- الاسم: اسم حزمة حزمة SDK أو المكتبة.
- الإصدار الرئيسي: رمز الإصدار الرئيسي لحزمة SDK
- الإصدار الثانوي: رمز الإصدار الثانوي لحزمة SDK
إذا كان لدى مطوّري حِزم تطوير البرامج (SDK) لتطبيقات الواقع المعزّز حِزم أخرى من هذا النوع كعناصر تابعة في وقت الإنشاء، قد يحتاجون على الأرجح إلى الإفصاح عنها بطريقة مطابقة للطريقة التي سيستخدمها مطوّر التطبيقات للإفصاح عن العنصر التابع نفسه. إنّ حِزم SDK لإعادة الإصدار التي تعتمد على حِزم SDK غير المخصّصة لإعادة الإصدار ستربِطها بشكلٍ ثابت. وقد يؤدي ذلك إلى حدوث مشاكل سيتم رصدها في وقت الإنشاء أو أثناء عمليات الاختبار إذا كانت حِزم SDK غير المتوافقة مع RE تتطلّب وظائف لا تتيحها بيئة تشغيل حِزم SDK، أو إذا كان يجب تشغيلها في عملية التطبيق.
من المحتمل أن يريد مطوّرو حِزم تطوير البرامج (SDK) لنظام التشغيل RE مواصلة توفير الدعم للأجهزة التي لا تتيح استخدام نظام التشغيل RE، مثل أجهزة Android 12 أو الإصدارات الأقدم، وكما هو موضّح في قسم "صحة النظام" من المستند، أجهزة Android 14 من المستوى الأساسي التي تتضمّن موارد نظام محدودة جدًا. نحن نعمل على تطوير طرق لضمان أن يتمكّن مطوّرو حِزم تطوير البرامج (SDK) من الاحتفاظ بقاعدة بيانات برمجية واحدة لتتوافق مع بيئات إعادة المعالجة وغير إعادة المعالجة.
الإصدارات
مطوّرو التطبيقات
نتوقع أن يلاحظ مطوّرو التطبيقات تغييرًا بسيطًا في مرحلة الإنشاء. يجب أن تكون ملفات حزمة SDK التي تعتمد عليها حزمة SDK متوفّرة على الجهاز لإجراء عمليات التدقيق والتجميع والإنشاء، سواء كانت ملفات حزمة SDK هذه موزّعة محليًا أو موزّعة من خلال "متجر التطبيقات" (باستخدام أدوات إعادة الإصدار أو بدونها). نقترح أن يُنشئ "استوديو Android" خلاصة عن هذه التفاصيل من مطوّر التطبيق عند الاستخدام العادي، وأن يُجري ذلك بأكبر قدر ممكن من الشفافية.
على الرغم من أنّنا نتوقع أن يتضمّن إصدار DEBUG جميع الرموز البرمجية والرموز التعريفية لتكون متوفّرة في إصدار DEBUG لتسهيل تصحيح الأخطاء، سيتم اختياريًا إزالة جميع حِزم SDK الموزّعة من خلال متجر التطبيقات (سواء كانت مزوّدة برمز RE أو لا) من العنصر النهائي في إصدار RELEASE.
نحن في مرحلة مبكرة من التصميم، وسنشارك المزيد من المعلومات عندما تصبح متاحة.
مطوّرو حِزم SDK
نحن نعمل على ضمان إمكانية دمج إصدارات حزمة SDK التي لا تتضمّن رمزًا قابلاً لإعادة الاستخدام وإصداراتها التي تتضمّن رمزًا قابلاً لإعادة الاستخدام في عنصر واحد للتوزيع. سيؤدي ذلك إلى تجنُّب حاجة مطوّري التطبيقات إلى توفير إصدارات منفصلة لحِزم SDK متوافقة مع الأجهزة القابلة للتشغيل (RE) وإصدارات غير متوافقة مع الأجهزة القابلة للتشغيل.
تمامًا مثل التطبيقات، يجب أن تكون أي حِزم SDK للتبعيات التي يتم توزيعها على متجر التطبيقات متوفرة على الجهاز لإجراء عمليات التدقيق والترجمة والإنشاء، ونتوقع أن يسهّل Android IDE ذلك بسلاسة.
الاختبار
مطوّرو التطبيقات
وكما هو موضّح في اقتراحنا، سيتمكّن مطوّرو التطبيقات من اختبار تطبيقاتهم على الأجهزة التي تعمل بنظام التشغيل Android 14 بالطريقة المعتادة. بعد إنشاء تطبيقه، يمكن تثبيت التطبيق على جهاز RE أو محاكي. تضمن عملية التثبيت هذه تثبيت حِزم SDK الصحيحة في IDE SDK Runtime للجهاز أو المحاكي، سواء تم جلب حِزم SDK من مستودع SDK عن بُعد أو من ذاكرة التخزين المؤقت من نظام الإنشاء.
مطوّرو حِزم SDK
يستخدم مطوّرو حِزم SDK بشكل عام تطبيقات اختبارية داخلية على الأجهزة و المحاكيات لاختبار عمليات التطوير. لا يغيّر اقتراحنا هذا الإجراء، وسيكون التحقّق داخل التطبيق على النحو نفسه الموضّح لمطوّري التطبيقات أعلاه، مع عنصر إنشاء واحد لكل من تطبيقات RE وغير RE. سيتمكّن مطوّرو SDK من مراجعة الرمز البرمجي سواء كان في SDK Runtime أم لا، إلا أنّه قد تكون هناك بعض القيود المفروضة على أدوات تصحيح الأخطاء المتقدمة وأدوات تحليل الأداء. هذا مجال نشط للتحقيق.
التوزيع
أدى اقتراح التصميم الخاص بنا لفصل التطبيق عن حِزم SDK إلى إتاحة إمكانية توزيع حِزم SDK في متجر التطبيقات. وهذا احتمال عام، وليس حصريًا لأي متجر تطبيقات معيّن. تتضح المزايا على النحو التالي:
- ضمان جودة حِزم تطوير البرامج (SDK) واتساقها
- تسهيل عملية النشر لمطوّري حِزم SDK
- تسريع طرح تحديثات الإصدارات الثانوية لحزمة SDK في التطبيقات المثبّتة
لكي يتيح متجر التطبيقات توزيع حِزم SDK، من المرجّح أن يحتاج إلى توفير معظم الإمكانات التالية:
- آلية تتيح لمطوّري حِزم SDK تحميل حِزم SDK القابلة للتوزيع في متجر التطبيقات إلى المتجر وتحديثها وإعادتها إلى إصدار سابق وربما إزالتها
- آلية لضمان سلامة حزمة SDK ومصدرها، وسلامة التطبيق ومصدره، وحلّ تبعيتهما
- آلية لنشرها على الأجهزة بطريقة موثوقة باستمرار وبأداء جيد
القيود المتغيّرة بمرور الوقت
نتوقع أن تتطوّر القيود التي تواجهها الرموز البرمجية في وقت تشغيل حزمة SDK مع الإصدارات اللاحقة
من Android. لضمان توافق التطبيق، لن نغيّر هذه
القيود عند تحديث الوحدات الرئيسية لمستوى معيّن من حزمة SDK. يتم الاحتفاظ بالسلوك
المرتبط بtargetSdkVersion معيّن إلى أن يتم إيقاف targetSdkVersion نهائيًا من خلال سياسة متجر التطبيقات، وقد يتم إيقاف targetSdkVersion نهائيًا بوتيرة أسرع من التطبيقات.
من المتوقّع أن تتغيّر القيود بشكل متكرّر في جميع إصدارات حزمة تطوير البرامج (SDK) لنظام التشغيل Android، خاصةً في الإصدارات القليلة الأولى.
بالإضافة إلى ذلك، نعمل على إنشاء آلية اختبار تجريبي للسماح للمختبِرين الداخليين والخارجيين بالانضمام إلى مجموعة تحصل على المجموعة المقترَحة من القيود في الإصدار التالي من Android. سيساعدنا ذلك في الحصول على ملاحظات وآراء بشأن التغييرات المقترَحة على مجموعة القيود.
الأسئلة الشائعة
-
ما هي حزمة SDK ذات الصلة بالإعلانات؟
حزمة تطوير البرامج (SDK) ذات الصلة بالإعلانات هي حزمة تسهّل أي جزء من استهداف المستخدِمين من خلال الرسائل لأغراض تجارية، وذلك في التطبيقات التي لا يملكها المعلِن. ويشمل ذلك، على سبيل المثال لا الحصر، حِزم تطوير البرامج (SDK) للإحصاءات التي يمكن من خلالها إنشاء مجموعات مستخدمين لاستهدافهم لاحقًا، وحِزم تطوير البرامج (SDK) لعرض الإعلانات، وحِزم تطوير البرامج (SDK) لمكافحة إساءة الاستخدام ومكافحة الاحتيال في الإعلانات، وحِزم تطوير البرامج (SDK) للتفاعل، وحِزم تطوير البرامج (SDK) لتحديد المصدر.
-
هل يمكن تشغيل أي حزمة SDK في "وقت تشغيل حزمة SDK"؟
على الرغم من أنّ التركيز الأولي ينصبّ على حِزم SDK ذات الصلة بالإعلانات، يمكن لمطوّري حِزم SDK غير ذات الصلة بالإعلانات التي تسعى إلى اتّخاذ موقف إيجابي بشأن الخصوصية وتعتقد أنّه يمكنها العمل بموجب الشروط الموضّحة أعلاه مشاركة ملاحظاتهم حول حِزم SDK التي تديرها "وحدة تشغيل حِزم SDK". ومع ذلك، لم يتم تصميم "وقت تشغيل حزمة تطوير البرامج (SDK)" ليتوافق مع جميع تصميمات حِزم SDK. بالإضافة إلى القيود الموثَّقة، من المحتمل أنّ "وقت تشغيل حزمة SDK" غير مناسب لحِزم SDK التي تحتاج إلى اتصالات في الوقت الفعلي أو معدل نقل بياناتٍ مرتفع مع التطبيق المستضيف.
-
لماذا يجب اختيار عزل العملية بدلاً من العزل ضمن بيئة التشغيل المستندة إلى Java الخاصة بالعملية؟
في الوقت الحالي، لا يسهّل وقت التشغيل المستنِد إلى Java بسهولة حدود الأمان اللازمة لضمانات الخصوصية المطلوبة لمستخدمي Android إنّ محاولة تنفيذ إجراء مماثل قد تتطلّب جهدًا لعدة سنوات، بدون ضمان تحقيق النجاح. لذلك، تستخدِم "مبادرة حماية الخصوصية" حدود عملية الاستخدام، وهي تقنية تم اختبارها على مدار الوقت وفهمها جيدًا.
-
هل سيؤدي نقل حِزم SDK إلى عملية "وقت تشغيل حزمة SDK" إلى تقليل حجم التنزيل أو توفير مساحة؟
إذا تم دمج عدة تطبيقات مع حِزم SDK مفعَّلة في وقت التشغيل من الإصدار نفسه، يمكن أن يؤدي ذلك إلى تقليل حجم التنزيل ومساحة القرص.
-
ما هو نوع أحداث دورة حياة التطبيق، مثل الحالات التي ينتقل فيها التطبيق إلى الخلفية، التي ستتمكّن حِزم SDK من الوصول إليها في "وقت تشغيل حِزم SDK"؟
نحن نعمل جاهدين على إتاحة إمكانية إرسال إشعارات إلى وقت تشغيل حزمة SDK على مستوى التطبيق بشأن أحداث دورة الحياة في تطبيق العميل (مثل انتقال التطبيق إلى الخلفية أو انتقال التطبيق إلى المقدّمة). سيتم مشاركة التصميم ونموذج الرمز البرمجي في إصدار قادم من "معاينة المطوّر".
محتوى مُقترَح لك
- ملاحظة: يتم عرض نص الرابط عندما تكون لغة JavaScript غير مفعّلة.
- دليل المطوّر لاستخدام "وقت تشغيل حزمة تطوير البرامج (SDK)"