وفقًا لمجموعة من الالتزامات في AOSP، قد تبدأ Google في تقييد الوصول إلى واجهات برمجة التطبيقات غير الموثقة أو المخفية في Android P. تستخدم العديد من تطبيقات العلامات التجارية واجهات برمجة التطبيقات المخفية لتعزيز الوظائف، لذلك قد يكون التأثير واسع النطاق.
تحديث 28/2/18: نشرت Google تدوينة اليوم لتأكيد التغييرات. مزيد من التفاصيل في نهاية المقال.
في حين أن بعض عشاق Android كذلك المضاربة ما اسم الحلوى التي سيتم تسمية الإصدار التالي من Android باسمها، هناك بعض التطورات المثيرة للاهتمام التي تحدث خلف الكواليس. لقد رصدنا أ قليلة جديرة بالملاحظة الميزات القادمة في Android P، ولكن الاكتشاف الأحدث في Android Open Source Project (AOSP) أثبت أنه أكثر إثارة للاهتمام. وفقًا لهذه الالتزامات الأخيرة، قد يتم منع التطبيقات من الوصول إلى واجهات برمجة التطبيقات غير الموثقة في Android SDK (مثل واجهات برمجة التطبيقات التي تم تمييزها بواسطة سمة javadoc @hide).
لماذا هذا مهم
توفر مجموعة تطوير برامج Android (SDK) للمطورين مكتبات وأدوات API التي يحتاجونها لاختبار وبناء تطبيقات Android الجديدة. مع كل إصدار جديد من Android يأتي مجموعة كاملة من واجهات برمجة التطبيقات الجديدة المتوفرة للمطورين من خلال Android SDK. تعتمد واجهات برمجة التطبيقات المتاحة للتطبيق على نوع برنامج CompileSDKVersion الذي يحدده المطور. لهذا السبب جوجل
تستضيف جوجل صفحات التوثيق لكل فئة وجميع أساليبها المتوفرة في كل مستوى من مستويات API. هذه هي مجموعة واجهات برمجة التطبيقات الموثقة المتوفرة في Android SDK الرسمي. يمكنك تصفح قائمة الفئات بسهولة باستخدام تطبيق Android مثل تطبيق Android SDK Search الذي تم إصداره مؤخرًا بواسطة Android Engineer جيك وارتون.
مجاني.
4.1.
ومع ذلك، لا يتم توثيق جميع واجهات برمجة التطبيقات المتوفرة في كل إصدار من إصدارات Android بواسطة Google، أو المتوفرة في Android SDK الرسمي. غالبًا ما تكون هناك واجهات برمجة تطبيقات مفيدة غير موثقة، ولكنها مع ذلك مفيدة جدًا. لا يُنصح المطورون ببناء تطبيقاتهم باستخدام واجهات برمجة التطبيقات (APIs) غير الموثقة أو المخفية، ولكن الكثير منهم يفعلون ذلك لأنه ببساطة لا يوجد بديل إذا كانوا يريدون تقديم ميزة معينة. يمكن للمطورين الذين يستخدمون واجهات برمجة التطبيقات المخفية أو غير الموثقة أن يضعوا أنفسهم في ميزة تنافسية أيضًا، نظرًا لأنه يمكنهم تقديم ميزات يتفوق بها منافسوهم، الذين يلتزمون بواجهات برمجة التطبيقات التي يقدمها Android SDK — لا يمكن.
على الرغم من أنني لا أستطيع تقديم قائمة بالتطبيقات التي تستخدم واجهات برمجة التطبيقات غير الموثقة (ربما لا يشاركها المطورون التي يستخدمونها لأنها ستمنح منافسيهم ميزة)، ربما تكون القائمة هي بالأحرى كبير. وبالتالي، أود أن أستنتج أن حظر الوصول إلى واجهات برمجة التطبيقات المخفية سيكون أمرًا مهمًا. مارك ميرفي، مؤسس كومونوير، يوافق:
أتفق مع التقييم القائل بأن الحظر الجماعي للوصول إلى العناصر المشروحة بـ @hide سيكون أمرًا كبيرًا، إذا حدث ذلك. نأمل أن يصل عدد قليل من التطبيقات إلى هذه العناصر كجزء من الوظائف الأساسية. ومع ذلك، أظن أن الكثير من تطبيقات العلامات التجارية تستخدمها في بعض الأحيان، بشكل مباشر أو من خلال المكتبة.
ماذا يحدث في Android P؟
تمت الإشارة إلى هذه التغييرات القادمة لأول مرة بواسطة أحد كبار مطوري XDA المعترف بهم روفو89، مطور إطار Xpose. وأشار إلى التزامين لي، أحدهما أيّ كان اندمجت، والذي يقدم أداة بناء جديدة تسمى "hiddenapi". تقوم هذه الأداة بتعديل إشارات الوصول لجميع أعضاء الفصل داخل ملف DEX إذا تظهر توقيعاتهم في القائمة الرمادية أو القائمة السوداء للإدخال، وإذا كان الأمر كذلك، فسيتم التعامل مع الطرق المميزة على أنها واجهات برمجة التطبيقات الداخلية ذات القيود المقيدة. وصول. يصف الالتزام الآخر كيفية عمل القائمة السوداء لواجهة برمجة التطبيقات؛ يمنع الوصول إليها فئة التمهيد الأساليب والحقول المميزة بـ "hiddenapi" المذكورة أعلاه والتي يمكن للمطورين الوصول إليها عن طريق الارتباط الثابت والانعكاس وJNI.
وفقًا لـ rovo89، فإن النتيجة النهائية لهذين التغييرين في Android P هي كما يلي:
إذا تم دمج هذه الالتزامات، فهذا يعني أن التطبيقات لم يعد بإمكانها استخدام/الوصول إلى واجهات برمجة التطبيقات المخفية الفئات والأساليب والحقول الموضحة بـ @hide في AOSP وبالتالي فهي ليست جزءًا من SDK الرسمي. لن يكون هذا مشكلة بالنسبة لوحدات Xpose حيث يمكنني بسهولة التراجع عن تلك الالتزامات أو السماح للوحدات بذلك أيضًا الوصول إلى واجهات برمجة التطبيقات هذه. ولكن هناك العديد من التطبيقات التي تستفيد من واجهات برمجة التطبيقات المخفية، وقد تفشل تلك التطبيقات في مستقبل.
في الواقع، تظهر الالتزامات الإضافية أن هذا قد يكون ما تخطط له جوجل. هذا يقترف تنص على ما يلي:
على الرغم من أنه لم يتم دمج هذا الالتزام المحدد لأنه تم التخلي عنه لصالح 3 التزامات أصغر، إلا أن رسالة الالتزام تصف الغرض من هذه التغييرات. مجموعة أخرى من يرتكب يُظهر أن Google ستقترح بدائل للمطورين الذين يسعون إلى استخدام واجهات برمجة التطبيقات غير العامة:
ومع ذلك، غالبًا لا توجد بدائل لبعض واجهات برمجة التطبيقات المخفية. نحن في XDA يمكننا التحدث من خلال تجربتنا هنا لسوء الحظ، قد يعني هذا التغيير نهاية بعض التطبيقات المبتكرة، أو قد يتطلب الأمر بعض التطبيقات ذات الأسماء الكبيرة لتقليل حجمها وظائف. يبدو هذا التغيير القادم مشابهًا في روحه للتغيير الأخير حملة على خدمات الوصول (وكان ذلك ولله الحمد متوقف مؤقتا حيث قامت Google بتقييم الاستخدامات المبتكرة). في حين أن معظم التطبيقات التي تستخدم واجهات برمجة التطبيقات غير الموثقة تفعل ذلك لأسباب حميدة، فقد تكون هناك بعض التطبيقات التي أساءت استخدامها لأغراض شائنة.
ولهذا السبب، ربما تقوم Google بإغلاق الوصول إلى جميع واجهات برمجة التطبيقات المخفية في Android P من أجل حماية المستخدمين من القلة التي تسيء استخدامها. من الصعب تحديد مدى التأثير الذي قد يحدثه ذلك على المستخدمين، ولكن إذا كنت مطورًا بالنظر إلى AOSP للعثور على استخدام مبتكر لواجهة برمجة التطبيقات المخفية، فقد ترغب في ذلك إعادة النظر.
التحديث: تؤكد جوجل
في مشاركة مدونة تم نشره اليوم 28 فبراير، وقد أكدت جوجل هذه التغييرات. نقلاً عن مخاطر التعطل للمستخدمين وإجبار المطورين لاحقًا على طرح إصلاحات الطوارئ، Google تنص على أن الشركة تتحول تدريجيًا نحو تثبيط المطورين من الوصول إلى أدوات غير SDK واجهات. بدءًا من Android P، ستتوسع القيود لتشمل واجهات لغة Java الخاصة بمجموعة SDK.
تنص الشركة على أنه "سيتم تقييد بعض الأساليب والحقول غير التابعة لـ SDK"، على الرغم من أنها لم توضح أي منها سيتم تقييده. في البداية، سيركز التقييد على الواجهات التي نادرًا ما يتم استخدامها، ولفترة من الوقت ستسمح الشركة بذلك للمطورين الاستمرار في استخدام الأساليب والحقول غير التابعة لـ SDK حيث يكون الانتقال إلى أسلوب SDK تقنيًا التحدي. ومع ذلك، ستتسع القيود في نهاية المطاف، لذلك يجب على مطوري التطبيقات التي تستخدم طرقًا غير SDK الانتقال في أقرب وقت ممكن استعدادًا لنظام Android P. أما بالنسبة للطرق التي لا تحتوي على بديل SDK، فإن Google تطلب من المطورين النشر على مواقعهم تعقب الأخطاء مع مزيد من المعلومات.
ستسمح المعاينة التالية للمطورين، والتي من المفترض أن تصل قريبًا، للمطورين باختبار التطبيقات الحالية مقابل القائمة السوداء أو القائمة الرمادية قبل الإصدار النهائي.