أسرار API لأجهزة Android. تقرير ياندكس

أحد التحديات الرئيسية لتطوير Android هو التجزئة. تقريبا كل مصنع يغير أندرويد حسب احتياجاته. قام المطور Andrey Makeev بسرد الاختلافات بين تطبيقات البائعين ومشروع Android Open Source الأصلي. من التقرير ، يمكنك معرفة كيفية الاستفادة من الميزات الفردية للبرنامج الثابت على أجهزة مختلفة.


- أمارس البرمجة منذ المدرسة ، وأنا أطورها على نظام أندرويد منذ ثلاث سنوات. من هؤلاء ، قضيت سنة في ياندكس ، وشاركت في مشاريع مثل Launcher و Phone.



أريد أن أتحدث عن كيف يبدو تجزئة واجهة برمجة تطبيقات أجهزة Android - من الخارج ، ومن جانب مطوري التطبيقات ، ومن الداخل ، من وجهة نظر مطوري النظام الأساسي والهواتف.

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

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





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

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

كيف نعمل مع هذا؟ نستخدم أيضًا المكتبات وسعداء جدًا عندما نرفض دعم الإصدارات القديمة. أعتقد أنه في حياة كل شخص يقوم بذلك منذ أكثر من عام ، كانت هناك لحظة كهذه. هذه مجرد سعادة. هذا خيار تجزئة واضح وبسيط. يصل المقبل هو تجزئة نوع أندرويد. هناك العديد منهم. يتحدث Android TV عن نفسه ، فإن Android Auto مخصص بشكل أساسي لأجهزة راديو السيارة و Android Things - من أجل إنترنت الأشياء والأجهزة المدمجة المماثلة. W هو Wear OS ، ساعة Android السابقة ، شاهد لنظام Android. سنحاول النظر في كيفية ظهور ذلك من جانب المطور. والأكثر إثارة للاهتمام ، دعونا نحاول النظر في الشكل الذي تبدو عليه من الداخل.



خذ مثالين من developer.android.com. الأول هو ارتداء OS. ماذا نحتاج لتقديم طلب؟ نضيف تبعية برنامج compileOnly إلى build.gradle وكتابة سطرين إضافيين في البيان: use-feature android.hardware.type.watch و use-library ، وهو ما يتوافق مع نفس اسم الحزمة التي تتصل بها المكتبة.



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



Android Things API لا يختلف عمليا. نحن لا نصف استخدامات الميزة ، فقط يستخدم مكتبة ، ترجمة الاعتماد فقط.



نقوم بإنشاء نشاط ، في هذه الحالة ، يكون فريدًا بالنسبة لـ Android Things API ، فئة PeripheralManager. نحن نستطلع GPIO ونحاول التعهد.



كيف سيتصرف مثل هذا التطبيق على هاتفك؟ هناك خياران.



إذا أشرنا إلى استخدامات android android: required = "true" ، فلن نفي بالمتطلبات الإلزامية لـ PackageManager لتثبيت التطبيق ، وترفض تثبيته بشكل أساسي. إذا حددنا android: required = "false" ، فسيتم تثبيت التطبيق ، ولكن عندما نحاول الوصول إلى فئة PeripheralManager ، نحصل على NoClassDefFoundError ، لأنه لا يوجد مثل هذه الفئة في Android القياسية.

ما هي الاستنتاجات؟ نحن نقوم بتوصيل التبعية compileOnly فقط من أجل التواصل معها أثناء التجميع ، والفئات التي نستخدمها تنتظرنا على الجهاز ، وهي متصلة باستخدام خطوط معينة في البيان. في بعض الأحيان نصف ميزة تكون في أغلب الأحيان ضرورية للتمييز على Google Play ، وهو الجهاز الذي يمكن أو لا يمكن توزيع هذا التطبيق عليه.

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

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

النوع التالي الأقل دراسة من التجزئة هو تجزئة المنتج. تقوم كل شركة مصنّعة ، بعد أن حصلت على الكود المصدري - في حالات نادرة ، بـ AOSP ، وفي كثير من الأحيان يتم تعديلها بطريقة ما بواسطة مطوري الأجهزة - تقوم بإجراء تغييرات عليها. كقاعدة عامة ، نتعرف على الآثار السلبية لهذا النوع من التجزئة من أفضل القنوات - من المراجعات السلبية على Google Play ، لأن شخصًا ما قد كسر شيئًا ما. أو نتعلم هذا من تحليلات الأعطال ، عندما يتعطل شيء ما بشكل مفاجئ بطريقة غير مفهومة ، فقط على بعض الأجهزة المحددة. في أفضل الأحوال ، نتعلم ذلك من خلال ضمان الجودة ، عندما يحدث شيء أثناء الاختبار على جهاز معين.



حول هذا الموضوع ، لدي قصة رائعة من قاذفة التطوير لدينا. لقد حصلنا على تقرير بالأخطاء حيث لم يمتد النشاط إلى ملء الشاشة ، ولم يتم عرض خلفية الشاشة الافتراضية المفضلة على الإطلاق. وأظهرت نافذة فارغة. ليس لدينا حتى أجهزة لإعادة إنتاجه. من خلال التمدد على الشاشة ، ما زلنا قادرين على العثور على جهاز منخفض لا يعمل عليه ، وإصلاح كل شيء بسهولة باستخدام android: resizeableActivity = "true" في البيان. مع خلفية ، تحول كل شيء أكثر تعقيدا. حوالي يومين حاولنا الوصول والحصول على مزيد من المعلومات التفصيلية. في النهاية ، اكتشفوا أنه على عدد من الأجهزة ، تم تنفيذ برنامج الترميز لفك تشفير jpeg التدريجي مع الأخطاء ، عندما تم استخدام عدة خوارزميات ضغط على نتائج بعضها البعض. في هذه الحالة ، لقد كتبنا للتو اختبار الوبر ، والذي فشل في الإنشاء عند إنشاء التطبيق ، إذا وضعنا ورق الحائط المشفر بطريقة تقدمية في apk نفسه. إعادة ترميز جميع خلفيات ، كرر الوضع على الخلفية ، والذي يوزع بقية مجموعات ورق الجدران ، وكل شيء يعمل بشكل رائع. لكنه كلفنا حوالي يومين من الإجراءات.



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



ما الضمانات التي تقدمها Google لنا للتأكد من أن واجهة برمجة التطبيقات (API) لم يتم كسرها كثيرًا حتى لا تعمل التطبيقات من حيث المبدأ؟ بادئ ذي بدء ، هناك CDD ، الذي يصف ما هو ممكن وما لا يمكن تغييره ، وما هو متوافق مع الإصدارات السابقة وما هو غير ذلك. هذه وثيقة من عشرات الصفحات مع توصيات عامة ، والتي ، بالطبع ، لن تغطي جميع الحالات. لتغطية المزيد من الحالات ، هناك CTS ، والتي يجب أن تكتمل من أجل حصول الهاتف على شهادة من Google ويمكن استخدام خدمات Google منه. هذا هو مجموعة من حوالي 350،000 الاختبارات الآلية. هناك أيضًا CTS Verifier ، APK عادي يمكنك وضعه على هاتفك لإجراء سلسلة من الاختبارات. بالمناسبة ، إذا قمت بشراء هاتف بيديك ، فيمكنك التحقق من ذلك.

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

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

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

وبالتالي ، يمكن لأي واحد منكم الاستفادة من بعض من هذا النوع من التجزئة. ماذا نفعل بهذا؟ لا تتردد مطلقًا في الإبلاغ عن الأخطاء وإرسال تقارير الأخطاء إلى مطوري الأجهزة وحتى مطوري Android. لأنه إذا تم كسر أي واجهات برمجة التطبيقات (API) التي تستحق الكتابة ، فإن اختبار CTS قد تم كتابته ، ثم سيتم كتابته - وكانت هناك سوابق من هذا القبيل - وبعد ذلك أصبحت API أكثر موثوقية.

تعلم Android ، وتعرف على ما تقدمه الشركات المصنعة ، ولا تقسم معهم - اعمل معهم.

كيف تبدو من الداخل؟ كيف يمكنني تطبيق بعض الميزات التي ستكون فريدة لهاتفنا واستخدام واجهة برمجة التطبيقات هذه من تطبيق Android العادي؟



قليلا من الناحية النظرية. كيف يصف مطورو Android أنفسهم جهاز AOSP الداخلي؟ الطبقة العليا هي تطبيق تمت كتابته بواسطتك أو بواسطة مطوري الهاتف نفسه ، والذي لا يتمتع بأي حقوق عالية ، يستخدم واجهات برمجة التطبيقات القياسية فقط. هذا إطار عمل ، هذه فئات ليست جزءًا من التطبيق الخاص بك ، مثل Activity ، و Parcelable ، و Bundle - فهي جزء من النظام ، ويشار إليها كإطار عمل. الفئات المتاحة لك على الجهاز. التالي هي خدمات النظام. هذا هو ما يوصلك بالنظام: ActivityManagerService ، WindowManagerService ، PackageManagerService ، والتي تنفذ الجانب الداخلي للتفاعل مع النظام.

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



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



كيف نكتب ميزة لدينا؟ الخطة بسيطة: تحتاج إلى كتابة إطار لا يختلف تمامًا عن المكتبات التي كتبها معظم مطوري Android ، وأعتقد أنكم جميعًا يعرفون ذلك. تحتاج إلى كتابة خدمة نظام ، وهو تطبيق عادي ، فقط مع وجود مجموعة غير عادية تمامًا من الحقوق في النظام. وإذا لزم الأمر ، يمكنك كتابة HAL ، لكننا نحذف هذا. يمكنك كتابة برامج التشغيل الخاصة بك على مستوى kernel ، لكننا لن نفكر فيها الآن. واكتب تطبيق عميل يستخدم كل هذا.



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



بعد ذلك ، نكتب إطار عمل ، مكتبتنا ، التي تتولى تنفيذ هذه الواجهة ، وتعرض جميع المكالمات إليها. إذا كنت مهتمًا ، فإن ActivityManager و PackageManager و WindowManager يعملان بنفس الطريقة تقريبًا. هناك منطق أكثر بقليل مما طبقناه هنا ، ولكن الجوهر هو ذلك.



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



علاوة على ذلك ، لكي تكون خدمة النظام هذه متوفرة ، يجب أن نسجلها في مدير خدمة النظام ، وفي هذه الحالة هي نفس الفئة التي لا تتوفر للتطبيقات العادية. وهو متاح بالتحديد لأولئك الموجودين في النظام الأساسي في أقسام النظام. نقوم بتسجيل الخدمة ببساطة في Application.onCreate () ، وجعلها متاحة تحت اسم الفئة التي أنشأناها.

ما الذي نحتاجه لبدء onCreate () أساسًا ولتحميل خدماتنا في الذاكرة؟ نكتب في البيان في تطبيق android: persistent = "true". هذا يعني أن هذه عملية مستمرة ، يجب أن تكون في الذاكرة باستمرار ، لأنها تؤدي وظائف النظام.



أيضًا في البيان نفسه ، يمكننا تحديد android: sharedUserId ، في نظام الحالة هذا ، لكن يمكن أن يكون نطاقًا واسعًا من معرفات مختلفة ، فهي تسمح للتطبيق بالحصول على حقوق أوسع في النظام ، والتفاعل مع واجهات برمجة التطبيقات والخدمات المختلفة التي لا تتوفر للتطبيقات العادية.

في هذه الحالة ، على سبيل المثال ، لم نستخدم أي شيء مثل هذا.



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

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

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



نكتب تطبيق بسيط. بطريقة مألوفة ، نقوم بتوصيل التبعية compileOnly ، فقط الآن هي مكتبتنا. نحن نصف استخدامات المكتبة التي كتبناها والتي وضعت على الجهاز. نكتب النشاط ، والوصول إلى هذه الفئات ، والتفاعل مع النظام. لذلك سيكون من الممكن تطبيق أي ميزات على الإطلاق: نقل البيانات إلى بعض الأجهزة الإضافية ، وميزات الأجهزة الإضافية ، إلخ.

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

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

Source: https://habr.com/ru/post/ar448126/


All Articles