تستخدم منصة Android مفهوم وضع الحماية للتطبيقات للحفاظ على حدود تنفيذ وأمان قوية لرمز التطبيق، بالإضافة إلى حدود العمليات. من الممارسات الشائعة أن تتضمّن التطبيقات رموزًا برمجية تابعة لجهات خارجية، وغالبًا ما تكون في شكل حِزم تطوير برامج (SDK) مثل حِزم SDK لعرض الإعلانات أو حِزم SDK للإحصاءات. تتيح إعادة الاستخدام هذه للمطوّرين التركيز على الميزات الفريدة في تطبيقاتهم والاستفادة من عمل الخبراء في هذا المجال لتوسيع نطاق تنفيذهم إلى ما هو أبعد مما يمكنهم تنفيذه بسهولة بمفردهم.
كما هو الحال في معظم أنظمة التشغيل، يتم تنفيذ حِزم تطوير البرامج (SDK) في نظام التشغيل Android ضمن بيئة الاختبار المعزولة للتطبيق المضيف، وتكتسب هذه الحِزم الامتيازات والأذونات نفسها التي يملكها التطبيق المضيف، بالإضافة إلى إمكانية الوصول إلى ذاكرة التطبيق المضيف ومساحة تخزينه. مع أنّ هذه البنية تتيح دمج حِزم SDK والتطبيقات بمرونة، إلا أنّها تتيح أيضًا إمكانية جمع بيانات المستخدمين ومشاركتها بدون الإفصاح عن ذلك. علاوةً على ذلك، قد لا يكون مطوّرو التطبيقات على دراية كاملة بمدى وظائف حزمة تطوير البرامج (SDK) التابعة لجهة خارجية والبيانات التي تصل إليها، ما يجعل من الصعب توضيح ممارسات جمع البيانات ومشاركتها في تطبيقاتهم.
في نظام التشغيل Android 14، أضفنا إمكانية جديدة للمنصة تتيح تشغيل حِزم SDK التابعة لجهات خارجية في بيئة وقت تشغيل مخصّصة تُعرف باسم وقت تشغيل حزمة تطوير البرامج (SDK). يوفّر SDK Runtime الضمانات ووسائل الحماية المعززة التالية بشأن جمع البيانات ومشاركتها:
- بيئة تنفيذ معدَّلة
- أذونات وحقوق وصول إلى البيانات محدّدة بشكل دقيق لحِزم SDK
نسعى جاهدين للحصول على ملاحظات من منتدى الإعلان على التطبيقات للأجهزة الجوّالة بشأن هذا التصميم. نرحّب أيضًا بملاحظات منتدى المطوّرين الأوسع نطاقًا للمساعدة في تطوير الإصدارات المستقبلية من SDK Runtime، بما في ذلك توفير الدعم لحالات استخدام إضافية.
الأهداف
يهدف هذا الاقتراح إلى تحقيق الأهداف التالية:
- تقليل إمكانية وصول حِزم SDK التابعة لجهات خارجية إلى بيانات المستخدمين في التطبيقات ومشاركتها بدون إفصاح، وذلك من خلال عزل العمليات وتحديد واجهات برمجة التطبيقات وعناصر التحكّم في الوصول إلى البيانات بشكل واضح. يمكنك الاطّلاع على مزيد من المعلومات حول عزل العمليات في قسم منفصل من هذا المستند.
- تقليل عمليات التتبُّع غير المعلَن عنها لاستخدام المستخدم للتطبيق من خلال حِزم تطوير البرامج (SDK) التابعة لجهات خارجية، وذلك عن طريق فرض قيود على إمكانية وصول حِزم SDK إلى المعرّفات الفريدة والدائمة
- تسريع توزيع تحديثات حِزم SDK على التطبيقات بشكل آمن من خلال تقليل العبء على مطوّري التطبيقات والمستخدمين النهائيين يمكنك الاطّلاع على مزيد من المعلومات حول نموذج توزيع حِزم SDK المُعتمَد المقترَح في قسم آخر من هذا المستند.
- مساعدة مطوّري التطبيقات في توضيح ممارسات الوصول إلى البيانات ومشاركتها في تطبيقاتهم بشكل أفضل
- مساعدة مطوّري حِزم SDK في منع التلاعب بها من خلال حِزم SDK أخرى عن طريق الحدّ من بعض بنى اللغة غير الآمنة، مثل رمز JNI
- مساعدة حِزم SDK لعرض الإعلانات في رصد الزيارات غير الصالحة والاحتيال في الإعلانات ومنعهما من خلال التحكّم الكامل في طرق العرض البعيدة التي تعرض الوسائط
- تقليل التأثير غير المبرّر على مطوّري التطبيقات وحِزم SDK قدر الإمكان
يتم تنفيذ حِزم SDK في عملية معزولة
تتيح حزمة SDK Runtime المقترَحة تشغيل حِزم 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 وتحديثها والرجوع إلى إصدارات سابقة على جميع إصدارات Android
يتضمّن هذا المستند أيضًا أسئلة شائعة للمساعدة في الإجابة عن الأسئلة الشائعة.
هذا مجرد اقتراح أولي للتصميم، ونحن ندرك أنّ هذا التغيير قد يكون مهمًا لبعض أعضاء المنظومة المتكاملة. لهذا السبب، نسعى جاهدين للحصول على ملاحظاتك ونطلب منك إرسالها من خلال أداة تتبُّع المشاكل.
إذن الوصول
تعني إدارة خصوصية النظام إدارة طريقة وصول الجهات المختلفة إلى الموارد المختلفة. ولتحقيق قيمة الخصوصية التي نقترحها، نقترح تعديل نموذج الوصول إلى التطبيقات وحِزم تطوير البرامج (SDK) وبيانات المستخدمين ليتوافق مع مبدأ الامتياز الأقل من أجل منع الوصول غير المعلَن عنه إلى البيانات التي يُحتمل أن تكون حساسة.
أذونات حزمة تطوير البرامج (SDK)
باعتبارها عملية منفصلة، سيكون لوقت تشغيل حزمة تطوير البرامج (SDK) مجموعة خاصة ومحدّدة جيدًا من الأذونات، بدلاً من أن يرث الأذونات التي منحها المستخدم للتطبيق. واستنادًا إلى الأبحاث الأولية حول الأذونات التي تستخدمها حِزم تطوير البرامج (SDK) ذات الصلة بالإعلانات، نقترح أن تكون الأذونات التالية متاحة لحِزم تطوير البرامج (SDK) في وقت تشغيل حزمة تطوير البرامج (SDK) تلقائيًا:
INTERNET: الوصول إلى الإنترنت للتواصل مع خدمة ويب-
ACCESS_NETWORK_STATE: الوصول إلى معلومات حول الشبكات -
READ_BASIC_PHONE_STATE: الوصول إلى معلومات حول حالة الهاتف، مثل نوع شبكة الجوّال - أذونات الوصول إلى واجهات برمجة التطبيقات التي تحافظ على الخصوصية، والتي توفّر إمكانات إعلانية أساسية بدون الحاجة إلى الوصول إلى المعرّفات على مستوى التطبيقات
AD_ID: إمكانية طلب المعرّف الإعلاني سيكون هذا الإجراء مشروطًا أيضًا بحصول التطبيق على إذن الوصول إلى هذه البيانات.
نحن نحقّق حاليًا في إمكانية منح أذونات إضافية وكيفية ذلك، مع الحدّ من التأثير على المستخدمين النهائيين من ناحية الخصوصية وسهولة الاستخدام. نحن نطلب الحصول على ملاحظات بشأن أي حالات استخدام قد لا تستوفيها مجموعة الأذونات هذه.
الذاكرة
سيكون لبيئة SDK Runtime مساحة ذاكرة معزولة خاصة بها بسبب توفّر عملية خاصة بها. سيؤدي هذا الهيكل تلقائيًا إلى منع حزمة SDK من الوصول إلى مساحة ذاكرة التطبيق، ولن يتمكّن التطبيق أيضًا من الوصول إلى مساحة ذاكرة حزمة SDK. نقترح الإبقاء على هذا السلوك التلقائي للحفاظ على التوافق مع مبدأ الحد الأدنى من الامتيازات.
مساحة التخزين
يهدف هذا الاقتراح إلى تحقيق التوازن بين حاجة حِزم SDK إلى الوصول إلى مساحة التخزين لتنفيذ عملياتها العادية والحدّ من التتبُّع على مستوى التطبيقات وعبر العمليات باستخدام مساحة التخزين الثابتة. نقترح إجراء التعديل التالي على طريقة الوصول إلى مساحة التخزين الحالية:
- ولن يتمكّن التطبيق من الوصول مباشرةً إلى مساحة تخزين حِزم SDK، والعكس صحيح.
- لن تتمكّن حِزم تطوير البرامج (SDK) من الوصول إلى وحدة التخزين الخارجية للجهاز.
- في كلّ "وقت تشغيل SDK"، ستتوفّر مساحة تخزين يمكن لجميع حِزم SDK الوصول إليها، ومساحة تخزين خاصة بحزمة SDK معيّنة.
وكما هو الحال في نموذج مساحة التخزين الحالي، لن يكون لمساحة التخزين نفسها حدود عشوائية من حيث الحجم. يمكن أن تستخدم حِزم تطوير البرامج (SDK) مساحة التخزين لتخزين مواد العرض مؤقتًا. ويتم محو مساحة التخزين هذه بشكل دوري عندما لا يكون حِزمة تطوير البرامج (SDK) قيد التشغيل بشكل نشط.
التنفيذ
لضمان توفُّر نظام خاص بين التطبيقات وحِزم تطوير البرامج والمستخدمين، يجب أن يعزّز سياق التنفيذ نفسه (تنسيقات الرموز البرمجية وبِنى اللغة وواجهات برمجة التطبيقات التي يمكن الوصول إليها وبيانات النظام) حدود الخصوصية هذه، أو على الأقل ألا يتيح فرصًا للتحايل عليها. في الوقت نفسه، نريد الحفاظ على إمكانية الوصول إلى المنصة الغنية ومعظم إمكانات وقت التشغيل التي توفّرها حِزم SDK حاليًا. في ما يلي مجموعة من التعديلات المقترَحة على بيئة وقت التشغيل لتحقيق هذا التوازن.
الرمز
يتم تفسير رموز Android البرمجية (التطبيقات وحِزم تطوير البرامج) في الغالب من خلال "وقت تشغيل 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 Runtime، نقترح فرض قيود إضافية على إمكانية الوصول إلى المعرّفات التي يمكن استخدامها في التتبُّع على مستوى التطبيقات.
لا يمكن الوصول إلى واجهات برمجة التطبيقات في "وقت تشغيل حزمة تطوير البرامج (SDK)" إلا من التطبيقات التي تعمل في المقدّمة.
محاولة الوصول إلى واجهات برمجة التطبيقات SdkSandboxManager من التطبيقات
في الخلفية تؤدي إلى ظهور
SecurityException.
أخيرًا، لا يمكن أن تستخدم حِزم SDK الخاصة بالبيئات المقيّدة واجهات برمجة تطبيقات الإشعارات لإرسال إشعارات إلى المستخدمين في أي وقت.
مراحل النشاط
تتّبع حِزم تطوير البرامج (SDK) للتطبيقات حاليًا دورة حياة التطبيق المضيف، ما يعني أنّه عندما يدخل التطبيق إلى المقدّمة أو يخرج منها أو يتم إيقافه أو إيقافه بالقوة من خلال نظام التشغيل بسبب نقص الذاكرة، يحدث ذلك أيضًا مع حِزم تطوير البرامج (SDK) الخاصة بالتطبيق. يشير اقتراحنا بفصل حِزم SDK الخاصة بالتطبيق إلى عملية مختلفة، ما يستتبع تغييرات في دورة الحياة على النحو التالي:
- يمكن للمستخدم أو نظام التشغيل إنهاء التطبيق. سيتم إيقاف SDK Runtime تلقائيًا بعد ذلك مباشرةً.
يمكن أن يوقف نظام التشغيل بيئة SDK Runtime بسبب ضغط الذاكرة أو حدوث استثناء لم تتم معالجته في حزمة SDK، على سبيل المثال.
في نظام التشغيل Android 14، عندما يكون التطبيق في المقدّمة، يعمل "وقت تشغيل حزمة تطوير البرامج" بأولوية عالية ومن غير المحتمل أن يتم إيقافه. عندما ينتقل التطبيق إلى الخلفية، تنخفض أولوية عملية SDK Runtime ويصبح التطبيق مؤهلاً للإغلاق. ستبقى أولوية عملية SDK Runtime منخفضة حتى إذا عاد التطبيق إلى المقدّمة. وبالتالي، من المرجّح جدًا أن يتم إيقافها بسبب ضغط الذاكرة مقارنةً بالتطبيق.
في الإصدار 14 من نظام التشغيل Android والإصدارات الأحدث، تتم مواءمة أولويات العمليات الخاصة بالتطبيق وSDK Runtime. يجب أن تكون أولويات العمليات
ActivityManager.RunningAppProcessInfo.importanceللتطبيق و SDK Runtime متطابقة تقريبًا.في حال إنهاء "وقت تشغيل حزمة تطوير البرامج" أثناء تشغيل التطبيق، مثلاً إذا حدث استثناء لم تتم معالجته في حزمة تطوير البرامج، سيتم فقدان حالة "وقت تشغيل حزمة تطوير البرامج"، بما في ذلك جميع حِزم تطوير البرامج التي تم تحميلها سابقًا وطرق العرض عن بُعد. يمكن لمطوّر التطبيق التعامل مع إنهاء وقت تشغيل حزمة تطوير البرامج (SDK) باستخدام أي من الطرق التالية:
- يقترح هذا الحلّ توفير طرق معاودة الاتصال ذات الصلة بدورة الحياة لمطوّري التطبيقات من أجل رصد حالات إيقاف "وقت تشغيل حزمة SDK".
- إذا تم إيقاف SDK Runtime أثناء عرض الإعلانات، قد لا تعمل الإعلانات على النحو المتوقّع. على سبيل المثال، قد تتوقف المشاهدات عن الظهور على الشاشة ولا تعود تفاعلية. يمكن للتطبيق إزالة عرض الإعلان إذا لم يؤثّر ذلك في تجربة المستخدم.
- يمكن للتطبيق محاولة أخرى لتحميل حِزم SDK وطلب الإعلانات.
- في نظام التشغيل Android 14، إذا تم إيقاف "وقت تشغيل حزمة SDK" أثناء تحميل حِزم SDK، ولم يسجِّل مطوّر التطبيق طرق معاودة الاتصال المذكورة أعلاه الخاصة بدورة الحياة، سيتم إيقاف التطبيق تلقائيًا. سيتم إنهاء عمليات التطبيق التي تم تحميل حِزم SDK فيها والخروج منها بشكل طبيعي فقط.
- تعرض عناصر Binder التي ترسلها حزمة تطوير البرامج (SDK) للتواصل معها (مثل
SandboxedSdk) الخطأDeadObjectExceptionإذا استخدمها التطبيق.
يخضع نموذج مراحل النشاط هذا للتغيير في التحديثات المستقبلية.
في حال حدوث أعطال مستمرة، على مطوّر التطبيق التخطيط لتوفير تجربة استخدام سلسة بدون حزمة SDK أو إرسال إشعار إلى المستخدم إذا كانت حزمة SDK ضرورية للوظيفة الأساسية للتطبيق. لمزيد من التفاصيل حول هذا التفاعل بين التطبيق وحزمة تطوير البرامج (SDK)، يُرجى الاطّلاع على قسم الاتصالات في هذا المستند.
يمكن لحِزم SDK غير المقيدة الاستمرار في استخدام عناصر نظام التشغيل الأساسية العادية المتاحة للتطبيق المضمّن، بما في ذلك الخدمات والأنشطة وعمليات البث، بينما لا يمكن لحِزم SDK المقيدة ذلك.
الحالات الخاصة
الحالات التالية غير متوافقة، وقد تؤدي إلى سلوك غير متوقّع:
- إذا كانت تطبيقات متعددة تشترك في معرّف UID نفسه، قد لا يعمل خيار "وقت تشغيل حزمة تطوير البرامج (SDK)" بشكل سليم. قد تتم إضافة إمكانية استخدام معرّفات فريدة مشتركة في المستقبل.
- بالنسبة إلى التطبيقات التي تتضمّن عمليات متعددة، يجب تحميل حزمة SDK في العملية الرئيسية.
عرض الوسائط
تتوفّر حِزم تطوير برامج (SDK) تعرض المحتوى، مثل النصوص والصور والفيديوهات، في طريقة عرض يحدّدها التطبيق. ولتحقيق ذلك، نقترح اتّباع أسلوب العرض عن بُعد، حيث تعرض حزمة SDK الوسائط من داخل "وقت تشغيل حزمة تطوير البرامج"، ولكنها تستخدم واجهة برمجة التطبيقات SurfaceControlViewHost للسماح بعرض الوسائط في طريقة عرض يحدّدها التطبيق. يتيح ذلك لحزمة SDK عرض هذه الوسائط بطريقة تحافظ على خصوصية المستخدم، مع المساعدة في منع ورصد تفاعلات المستخدمين غير الصالحة أو الاحتيالية مع الوسائط المعروضة.
ستتيح حِزم تطوير البرامج (SDK) في "وقت تشغيل حزمة تطوير البرامج" عرض الإعلانات المدمجة التي لا يتم عرضها من خلال حزمة تطوير البرامج، بل من خلال التطبيق. ستتم عملية جمع الإشارات واسترداد المواد الإبداعية بشكل متّسق مع الإعلانات غير المدمجة مع المحتوى. هذا مجال نشط للتحقيق.
إعلانات الفيديو أثناء عرض الفيديو هي الإعلانات التي يتم عرضها أثناء عرض فيديو في مشغّل داخل تطبيق. وبما أنّ الفيديو يتم تشغيله في مشغّل داخل التطبيق، وليس في مشغّل أو عرض في حزمة تطوير البرامج (SDK)، يختلف نموذج العرض عن أشكال الإعلانات الأخرى. نحن نستكشف حاليًا آليات تتيح إدراج الإعلانات من جهة الخادم وإدراج الإعلانات المستند إلى حِزم تطوير البرامج (SDK).
سلامة النظام
نسعى إلى الحدّ من تأثير SDK Runtime في سلامة النظام على أجهزة المستخدمين النهائيين، ونعمل على تصميم طرق لتحقيق ذلك. ومع ذلك، من المرجّح أنّ بعض أجهزة Android 14 الأساسية التي تتضمّن موارد نظام محدودة جدًا، مثل Android (إصدار Go)، لن تتوافق مع SDK Runtime بسبب تأثيرها في سلامة النظام. سنشارك قريبًا الحد الأدنى من المتطلبات اللازمة لاستخدام SDK Runtime بنجاح.
الاتصالات
بما أنّ التطبيقات وحِزم SDK تعمل حاليًا في العملية نفسها، فإنّ التواصل بينها يكون غير مقيّد وغير خاضع لأي وسيط. بالإضافة إلى ذلك، يتيح نظام التشغيل Android التواصل بين التطبيقات حتى إذا بدأ التواصل وانتهى باستخدام حِزم تطوير البرامج (SDK). يتيح نموذج الاتصال الحر هذا حالات استخدام مختلفة، كما يتيح في الوقت نفسه إمكانية مشاركة البيانات غير المعلَن عنها بين التطبيقات وبين حِزم تطوير البرامج (SDK) داخل التطبيقات وبينها. نقترح إجراء التعديلات التالية على نموذج التواصل هذا سعيًا إلى تحقيق توازن بين قيمة هذا التواصل وتحقيق أهدافنا المحدّدة.
التطبيق إلى حزمة تطوير البرامج (SDK)
تمثّل الواجهة بين التطبيق وحزمة تطوير البرامج (SDK) مسار التواصل الأكثر شيوعًا مع حزمة تطوير البرامج، كما أنّ واجهة برمجة التطبيقات الخاصة بحزمة تطوير البرامج هي المكان الذي تظهر فيه معظم الميزات المبتكرة والمختلفة التي يراها المستخدمون. ونسعى إلى الحفاظ على قدرة حِزم تطوير البرامج (SDK) على الابتكار والتميّز هنا. وبناءً على ذلك، يتيح اقتراحنا لحِزم SDK عرض واجهات برمجة التطبيقات للتطبيقات، ويضمن استفادة التطبيقات من كل هذه الابتكارات.
وبالنظر إلى بنية حدود العملية في SDK Runtime، نقترح إنشاء طبقة تحويل يمكن الوصول إليها داخل التطبيق لنقل طلبات البيانات من واجهة برمجة التطبيقات والردود أو عمليات الرجوع عبر هذه الحدود بين التطبيق وحزمة SDK. ونقترح أن يحدّد مطوّرو حِزم SDK واجهة طبقة التحويل هذه، وأن يتم إنشاؤها باستخدام أدوات إنشاء رسمية مفتوحة المصدر سنعمل على تطويرها.
من خلال هذا الاقتراح، نسعى إلى إزالة العمل الروتيني المتعلق بتنظيم البيانات من مطوّري التطبيقات وحِزم SDK، مع توفير المرونة لمطوّري حِزم SDK وضمان تشغيل رمز حِزمة SDK في "وقت تشغيل حِزمة SDK" لتحقيق أهدافنا المتعلّقة بالخصوصية. وفي حال اتّخاذنا هذا المسار، يجب تصميم لغة تعريف واجهة برمجة التطبيقات والأدوات مع أخذ ملاحظاتك بعين الاعتبار.
سيكون نموذج التفاعل العام على النحو التالي:
- يطلب التطبيق حزمة SDK من خلال الواجهة، مع تمرير عمليات الرجوع.
- تستوفي حزمة تطوير البرامج (SDK) الطلبات بشكل غير متزامن وتستجيب باستخدام عمليات الرجوع.
- ويمكن تعميم ذلك على أي نموذج ناشر-مشترك، ما يعني أنّه يمكن للتطبيق الاشتراك في الأحداث في حزمة SDK باستخدام عمليات الاسترجاع، وعند وقوع هذه الأحداث، يتم تشغيل عمليات الاسترجاع.
من النتائج المترتبة على البنية الجديدة المقترَحة التي تتضمّن عمليات متعددة، أنّه سيكون هناك دورتان لإدارة عمر العمليات: إحداهما للتطبيق نفسه والأخرى لبيئة SDK Runtime. يهدف اقتراحنا إلى إتمام أكبر قدر ممكن من هذه العملية تلقائيًا، ما يقلّل من التأثير على مطوّري التطبيقات وحِزم SDK. يوضّح المخطّط التالي أحد الأساليب التي نفكّر فيها:
ستوفّر المنصة واجهات برمجة تطبيقات جديدة تتيح للتطبيقات تحميل حِزم SDK ديناميكيًا في عملية SDK Runtime، وتلقّي إشعارات بشأن التغييرات في حالة العملية، والتفاعل مع حِزم SDK التي تم تحميلها في SDK Runtime.
يوضّح الرسم البياني في الشكل السابق عملية التواصل بين التطبيق وحزمة تطوير البرامج (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 التواصل مع بعضها البعض كما يحدث داخل التطبيق حاليًا. نتيجةً لذلك، تمت إضافة واجهة برمجة تطبيقات في
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 أخرى متنوّعة عرض مرّة ظهور إعلان (التوسّط)، أو جمع الإشارات لإجراء مزاد (تقديم عروض الأسعار). عادةً، تتصل حزمة SDK المنسِّقة بحِزم SDK أخرى من خلال محوّل توفّره حزمة SDK المنسِّقة. بالنظر إلى العناصر الأساسية المذكورة أعلاه، يجب أن تتمكّن حزمة SDK المنسّقة، سواء كانت متوافقة مع بيئة التنفيذ المحدودة أو لا، من الوصول إلى جميع حِزم SDK المتوافقة وغير المتوافقة مع بيئة التنفيذ المحدودة لتعمل بشكل طبيعي. ويشكّل العرض في هذا السياق مجالاً نشطًا للتحقيق.
- التعرّف على الميزات: تتألف بعض منتجات حِزم SDK من حِزم SDK أصغر حجمًا، وتحدّد هذه الحِزم مجموعة الميزات النهائية التي يتم عرضها لمطوّر التطبيق من خلال عملية اكتشاف مشتركة بين حِزم SDK. من المتوقّع أن تتيح عناصر التسجيل والاكتشاف الأساسية حالة الاستخدام هذه.
- نماذج اشتراك الناشرين: تم تصميم بعض حِزم 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 مكوّنات مثل <service>, <activity>, <provider> أو <receiver>، وقد لا تعرِّف <permission> في البيان. لا تتوافق العلامات التي يتعذّر تثبيتها مع بيئة SDK Runtime. قد تتوافق إصدارات Android المستقبلية مع العلامات التي لا يتعذّر تثبيتها ولكن يتم تجاهلها بدون إشعار.
وقد يتم أيضًا تطبيق عمليات التحقّق هذه من خلال أي أدوات إنشاء تستخدمها حزمة SDK لإنشاء حزمة SDK، وذلك عند تحميلها إلى متجر التطبيقات.
دعم النشاط
لا يمكن لحِزم SDK في بيئة "وقت تشغيل حزمة تطوير البرامج (SDK)" إضافة علامة نشاط إلى ملف البيان الخاص بها، ولا يمكنها بدء أنشطتها الخاصة باستخدام Context.startActivity.
بدلاً من ذلك، تنشئ المنصة الأنشطة لحِزم SDK عند الطلب وتشاركها مع حِزم SDK.
نشاط المنصة من النوع android.app.Activity. يبدأ نشاط النظام الأساسي من أحد أنشطة التطبيق وهو جزء من مهمة التطبيق.
"FLAG_ACTIVITY_NEW_TASK" غير متاح.
لكي تبدأ حزمة SDK نشاطًا، يجب تسجيل مثيل من النوع
SdkSandboxActivityHandler، والذي يُستخدَم لإرسال إشعار بشأن إنشاء النشاط عندما يستدعي التطبيق SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder)
لبدء النشاط.
يظهر مسار طلب نشاط في الرسم البياني التالي.
تطوير
من المبادئ الأساسية في هذا الاقتراح الحدّ من التأثير على منظومة مطوّري التطبيقات قدر الإمكان. يقترح هذا التصميم على المطوّرين مجموعة شاملة من أدوات التطوير لكتابة تطبيقات RE وحِزم SDK وإنشائها وتصحيح أخطائها. لضمان سلامة هذا الاقتراح، سيتم إجراء بعض التغييرات على طريقة إعداد تطبيقات البيئات المحظورة وحِزم تطوير البرامج (SDK) وإنشائها وتصميمها.
التأليف
سيتم تعديل Android Studio والأدوات ذات الصلة لكي تتوافق مع "وقت تشغيل حزمة 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) الخاصة بـ RE سيواصلون توفير الدعم للأجهزة التي لا تتوافق مع RE، مثل الأجهزة التي تعمل بالإصدار 12 من نظام التشغيل Android أو الإصدارات الأقدم، وكما هو موضّح في قسم سلامة النظام من المستند، والأجهزة المنخفضة المواصفات التي تعمل بالإصدار 14 من نظام التشغيل Android والتي تتضمّن موارد نظام محدودة جدًا. نعمل على إيجاد طرق تتيح لمطوّري حِزم SDK الاحتفاظ بقاعدة رموز برمجية واحدة لتوفير الدعم لبيئات RE وغير RE.
الإصدارات
مطوّرو التطبيقات
نتوقّع ألا يواجه مطوّرو التطبيقات أي تغيير يُذكر في خطوة الإنشاء. يجب أن تكون تبعيات حزمة SDK متوفّرة على الجهاز لإجراء عمليات التدقيق والترجمة البرمجية والإنشاء، سواء كانت موزّعة محليًا أو موزّعة على متجر التطبيقات (RE أو غير RE). ونقترح أن يجرّد "استوديو Android" هذه التفاصيل من مطوّر التطبيق عند الاستخدام العادي وأن يوضّحها قدر الإمكان.
على الرغم من أنّنا نتوقّع أن يتضمّن إصدار DEBUG جميع الرموز والرموز البرمجية التي يجب أن تكون متوفرة في إصدار DEBUG لتسهيل تصحيح الأخطاء، يمكن إزالة جميع حِزم SDK الموزَّعة على متجر التطبيقات (RE أو غير RE) من الإصدار النهائي.
نحن في المراحل الأولى من مرحلة التصميم هنا، وسنشارك المزيد من التفاصيل عند توفّرها.
مطوّرو حِزم تطوير البرامج (SDK)
نعمل على توفير مسار يضمن إمكانية إنشاء إصدارات SDK غير مقيَّدة وإصدارات مقيَّدة في عنصر واحد لتوزيعه. سيؤدي ذلك إلى تجنُّب حاجة مطوّري التطبيقات إلى توفير إصدارات منفصلة من حزمة SDK لكل من البيئات المتوافقة مع RE وغير المتوافقة معها.
وكما هو الحال مع التطبيقات، يجب أن تتوفّر على الجهاز أي حِزم SDK تابعة تعتمد عليها التطبيقات الموزَّعة على متاجر التطبيقات، وذلك لإجراء عمليات التدقيق والترجمة البرمجية والإنشاء، ونتوقّع أن يسهّل Android Studio ذلك بسلاسة.
الاختبار
مطوّرو التطبيقات
وكما هو موضّح في اقتراحنا، سيتمكّن مطوّرو التطبيقات من اختبار تطبيقاتهم على الأجهزة التي تعمل بالإصدار 14 من نظام التشغيل Android بالطريقة المعتادة. بعد إنشاء التطبيق، يمكن تثبيته على جهاز أو محاكي يعمل بنظام التشغيل Restricted Environment. تضمن عملية التثبيت هذه تثبيت حِزم SDK الصحيحة في SDK Runtime على الجهاز أو المحاكي، سواء تم جلب حِزم SDK من مستودع حِزم SDK بعيد أو من ذاكرة التخزين المؤقت لنظام الإصدار.
مطوّرو حِزم تطوير البرامج (SDK)
يستخدم مطوّرو حِزم SDK عادةً تطبيقات اختبار داخلية على الأجهزة والمحاكيات لاختبار عملية التطوير. لا يغيّر اقتراحنا ذلك، وستتّبع عملية التحقّق داخل التطبيق الخطوات نفسها الموضّحة أعلاه لمطوّري التطبيقات، مع توفّر عنصر إنشاء واحد لكل من التطبيقات التي تتضمّن ميزة "التجربة بدون تثبيت" والتطبيقات التي لا تتضمّنها. سيتمكّن مطوّرو حِزم SDK من تتبُّع الرمز البرمجي الخاص بهم خطوة بخطوة، سواء كان في SDK Runtime أم لا، مع العلم أنّه قد تكون هناك بعض القيود على أدوات تصحيح الأخطاء المتقدّمة وأدوات إنشاء الملفات الشخصية. هذا مجال نشط للتحقيق.
التوزيع
وقد أتاح فصل التطبيق عن حِزم 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 Runtime. ومع ذلك، لم يتم تصميم SDK Runtime ليكون متوافقًا مع جميع تصاميم حِزم SDK. بالإضافة إلى القيود الموضّحة في المستندات، من المحتمل ألا يكون "وقت تشغيل حزمة تطوير البرامج" مناسبًا لحِزم تطوير البرامج التي تحتاج إلى اتصالات في الوقت الفعلي أو اتصالات ذات معدل نقل بيانات مرتفع مع التطبيق المضيف.
-
لماذا يجب اختيار عزل العمليات بدلاً من العزل ضمن وقت تشغيل مستند إلى Java لإحدى العمليات؟
في الوقت الحالي، لا يوفّر وقت التشغيل المستند إلى Java حدود الأمان اللازمة لضمانات الخصوصية التي يريدها مستخدمو Android. من المحتمل أن يتطلب تنفيذ شيء من هذا القبيل جهدًا لعدة سنوات، بدون ضمان النجاح. لذلك، تستخدم "مبادرة حماية الخصوصية" حدود العمليات، وهي تقنية تم اختبارها على مر الزمن ومعروفة جيدًا.
-
هل يؤدي نقل حِزم SDK إلى عملية وقت تشغيل حزمة SDK إلى توفير مساحة أو تقليل حجم التنزيل؟
إذا تم دمج عدة تطبيقات مع حِزم SDK يتم تفعيلها في وقت التشغيل من الإصدار نفسه، يمكن أن يؤدي ذلك إلى تقليل حجم التنزيل ومساحة التخزين على القرص.
-
ما هي أنواع أحداث دورة حياة التطبيق، مثل وقت انتقال التطبيق إلى الخلفية، التي ستتمكّن حِزم تطوير البرامج (SDK) من الوصول إليها في "وقت تشغيل حزمة تطوير البرامج (SDK)"؟
نعمل حاليًا على توفير دعم التصميم لإرسال إشعارات إلى وقت تشغيل حزمة تطوير البرامج (SDK) بشأن أحداث دورة الحياة على مستوى التطبيق لتطبيق العميل (مثل انتقال التطبيق إلى الخلفية أو إلى المقدمة). ستتم مشاركة التصميم وعيّنة الرمز البرمجي في إصدار معاينة للمطوّرين قادم.
محتوى مُقترَح لك
- ملاحظة: يتم عرض نص الرابط عندما تكون JavaScript غير مفعّلة
- دليل المطوّرين الخاص بـ "وقت تشغيل حزمة تطوير البرامج"