الروبوت android
لمعرفة كيفية عمل التطبيقات، ابدأ باستخدام أساسيات التطبيقات .
لبدء الترميز على الفور، اقرأ بناء التطبيق الأول .
تكتب تطبيقات أندرويد بلغة برمجة جافا. أدوات سك الروبوت تجميع التعليمات البرمجية الخاصة بك جنبا إلى جنب مع أي بيانات وملفات الموارد إلى أبك، حزمة الروبوت ، وهو ملف أرشيف مع لاحقة. .apk . يحتوي ملف أبك واحد على كافة محتويات تطبيق أندرويد وهو الملف الذي تستخدمه الأجهزة التي تعمل بنظام التشغيل أندرويد لتثبيت التطبيق.
كل التطبيق الروبوت يعيش في رمل الأمن الخاصة بها، والمحمية من قبل ميزات الأمان الروبوت التالية:
نظام التشغيل أندرويد هو نظام متعدد المستخدمين لينوكس حيث كل التطبيق هو مستخدم مختلف.
بشكل افتراضي، يقوم النظام بتعيين كل تطبيق معرف مستخدم لينوكس فريد (يتم استخدام المعرف فقط من قبل النظام وغير معروف للتطبيق). يحدد النظام أذونات لجميع الملفات في أحد التطبيقات بحيث لا يتمكن سوى معرف المستخدم المخصص لهذا التطبيق من الدخول إليها.
كل عملية لديها الجهاز الظاهري الخاص بها (فم)، لذلك يعمل رمز التطبيق بمعزل عن التطبيقات الأخرى.
افتراضيا، كل التطبيق يعمل في عملية لينكس الخاصة بها. نظام أندرويد يبدأ العملية عند أي من مكونات التطبيق تحتاج إلى تنفيذها، ثم إيقاف العملية عندما لم تعد هناك حاجة أو عندما يجب على النظام استعادة الذاكرة لتطبيقات أخرى.
نظام أندرويد ينفذ مبدأ أقل امتياز . وهذا هو، كل التطبيق، افتراضيا، لديه حق الوصول فقط إلى المكونات التي يتطلبها للقيام بعملها وليس أكثر من ذلك. هذا يخلق بيئة آمنة جدا حيث التطبيق لا يمكن الوصول إلى أجزاء من النظام الذي لا يعطى الإذن. ومع ذلك، هناك طرق لتطبيق ما لمشاركة البيانات مع التطبيقات الأخرى وللتطبيق للوصول إلى خدمات النظام:
من الممكن ترتيب تطبيقين لمشاركة نفس معرف مستخدم لينوكس، وفي هذه الحالة يتمكنون من الوصول إلى ملفات بعضهم البعض. للحفاظ على موارد النظام، يمكن للتطبيقات التي لها نفس معرف المستخدم أيضا الترتيب للتشغيل في نفس عملية لينوكس ومشاركة نفس فم. يجب أيضا أن يتم توقيع التطبيقات بنفس الشهادة.
يمكن أن يطلب التطبيق إذنا للدخول إلى بيانات الجهاز مثل جهات اتصال المستخدم ورسائل سمز والتخزين القابل للتخزين (بطاقة سد) والكاميرا وبلوتوث. يجب على المستخدم منح هذه الأذونات صراحة. لمزيد من المعلومات، راجع العمل مع أذونات النظام .
وتقدم بقية هذه الوثيقة المفاهيم التالية:
مكونات الإطار الأساسية التي تحدد التطبيق الخاص بك.
ملف البيان الذي تعلن فيه المكونات وعناصر الجهاز المطلوبة لتطبيقك.
الموارد المنفصلة عن شفرة التطبيق والتي تسمح لتطبيقك بتحسين سلوكه بشكل سلس لمجموعة متنوعة من عمليات تهيئة الجهاز.
مكونات التطبيق
مكونات التطبيق هي اللبنات الأساسية لتطبيق أندرويد. كل مكون هو نقطة دخول من خلالها النظام أو يمكن للمستخدم إدخال التطبيق الخاص بك. بعض المكونات تعتمد على الآخرين.
هناك أربعة أنواع مختلفة من مكونات التطبيق:
- أنشطة.
- خدمات.
- أجهزة استقبال البث.
- موفري المحتوى.
كل نوع يخدم غرضا متميزا ولديه دورة حياة متميزة تحدد كيفية إنشاء المكون وتدميره. تصف الأقسام التالية الأنواع الأربعة من مكونات التطبيق.
أنشطة
النشاط هو نقطة الدخول للتفاعل مع المستخدم. وهو يمثل شاشة واحدة مع واجهة المستخدم. على سبيل المثال، قد يكون لتطبيق البريد الإلكتروني نشاط واحد يعرض قائمة برسائل البريد الإلكتروني الجديدة، ونشاطا آخر لإنشاء رسالة إلكترونية، ونشاط آخر لقراءة رسائل البريد الإلكتروني. على الرغم من أن الأنشطة تعمل معا لتشكيل تجربة المستخدم متماسكة في التطبيق البريد الإلكتروني، كل واحد مستقل عن الآخرين. على هذا النحو، والتطبيق مختلفة يمكن أن تبدأ أي واحد من هذه الأنشطة إذا كان التطبيق البريد الإلكتروني يسمح بذلك. على سبيل المثال، يمكن لتطبيق الكاميرا بدء النشاط في تطبيق البريد الإلكتروني الذي ينشئ بريدا جديدا للسماح للمستخدم بمشاركة صورة. نشاط يسهل التفاعلات الرئيسية التالية بين النظام والتطبيق:
تتبع ما يهتم به المستخدم حاليا (ما هو على الشاشة) للتأكد من أن النظام يحتفظ تشغيل العملية التي تستضيف النشاط.
معرفة أن العمليات المستخدمة سابقا تحتوي على الأشياء التي قد يعود المستخدم إلى (الأنشطة توقف)، وبالتالي أكثر أولوية للغاية حفظ تلك العمليات حولها.
مساعدة مقبض التطبيق وجود عملية قتلها حتى يمكن للمستخدم العودة إلى الأنشطة مع الدولة السابقة استعادتها.
توفير وسيلة لتطبيقات لتدفق المستخدم بين بعضها البعض، والنظام لتنسيق هذه التدفقات. (المثال الأكثر كلاسيكية هنا يجري المشاركة.)
يمكنك تنفيذ نشاط كفئة فرعية من فئة Activity . لمزيد من المعلومات حول فئة Activity ، راجع دليل مطوري الأنشطة .
خدمات
الخدمة هي نقطة دخول للأغراض العامة لحفظ التطبيق قيد التشغيل في الخلفية لجميع أنواع الأسباب. وهو مكون يعمل في الخلفية لتنفيذ عمليات طويلة المدى أو لأداء العمل لعمليات بعيدة. لا توفر الخدمة واجهة مستخدم. على سبيل المثال، قد تلعب إحدى الخدمات موسيقى في الخلفية أثناء وجود المستخدم في تطبيق مختلف، أو قد تجلب البيانات عبر الشبكة دون حظر تفاعل المستخدم مع أحد الأنشطة. عنصر آخر، مثل النشاط، يمكن أن تبدأ الخدمة والسماح لها بتشغيل أو ربط إليها من أجل التفاعل معها. هناك في الواقع اثنين من خدمات دلالات متميزة جدا تخبر النظام حول كيفية إدارة التطبيق: تبدأ الخدمات اقول النظام للحفاظ على تشغيلها حتى اكتمال عملهم. هذا يمكن أن يكون لمزامنة بعض البيانات في الخلفية أو تشغيل الموسيقى حتى بعد مغادرة المستخدم التطبيق. يمثل مزامنة البيانات في الخلفية أو تشغيل الموسيقى أيضا نوعين مختلفين من الخدمات التي تقوم بتعديل كيفية تعامل النظام معهما:
تشغيل الموسيقى هو شيء المستخدم هو على علم مباشرة، وبالتالي فإن التطبيق يروي النظام هذا بالقول انها تريد أن تكون المقدمة مع إخطار ليقول للمستخدم عن ذلك؛ في هذه الحالة يعرف النظام أنه يجب أن تحاول من الصعب حقا للحفاظ على عملية تلك الخدمة قيد التشغيل، لأن المستخدم سوف يكون غير راض إذا كان يذهب بعيدا.
خدمة الخلفية العادية ليست شيئا يدرك المستخدم مباشرة على التوالي، وبالتالي فإن النظام لديه المزيد من الحرية في إدارة عمليتها. قد يسمح لها أن تقتل (ومن ثم إعادة تشغيل الخدمة في وقت لاحق) إذا كان يحتاج ذاكرة الوصول العشوائي للأشياء التي هي مصدر قلق أكثر إلحاحا للمستخدم.
خدمات ملزمة تشغيل لأن بعض التطبيقات الأخرى (أو النظام) وقال أنه يريد الاستفادة من الخدمة. هذه هي أساسا خدمة توفير واجهة برمجة التطبيقات لعملية أخرى. وبالتالي فإن النظام يعرف أن هناك تبعية بين هذه العمليات، لذلك إذا كانت العملية A ملزمة بخدمة في العملية B، فإنها تعرف أنها تحتاج إلى إبقاء العملية B (وخدمتها) التي تعمل على A. وعلاوة على ذلك، إذا كانت العملية A شيء يهتم المستخدم، ثم فإنه يعرف أيضا لعلاج عملية B كما شيء يهتم المستخدم أيضا. وبسبب مرونتها (لأفضل أو أسوأ)، اتضح أن الخدمات هي لبنة مفيدة حقا لجميع أنواع مفاهيم النظام الأعلى مستوى. خلفيات حية، مستمعي الإخطار، وحافظات الشاشة، وأساليب الإدخال، وخدمات إمكانية الوصول، والعديد من الميزات الأخرى للنظام الأساسي كلها مبنية على الخدمات التي التطبيقات تنفيذها ويرتبط النظام إلى متى يجب تشغيل.
يتم تنفيذ الخدمة كفئة فرعية من Service . لمزيد من المعلومات حول فئة Service ، راجع دليل مطوري الخدمات .
ملاحظة: إذا كان تطبيقك يستهدف أندرويد 5.0 (مستوى واجهة برمجة التطبيقات 21) أو أحدث، JobScheduler فئة JobScheduler لجدولة الإجراءات. جوبشيدولر لديه ميزة الحفاظ على البطارية عن طريق جدولة الوظائف على النحو الأمثل للحد من استهلاك الطاقة، والعمل مع أبي دوز . لمزيد من المعلومات حول استخدام هذه الفئة، راجع الوثائق المرجعية JobScheduler .
أجهزة استقبال البث
جهاز استقبال البث هو أحد المكونات التي تمكن النظام من تسليم الأحداث إلى التطبيق خارج تدفق المستخدم العادي، مما يسمح التطبيق للرد على الإعلانات البث على نطاق المنظومة. لأن مستقبلات البث هي مدخل آخر محدد جيدا في التطبيق، يمكن للنظام تقديم البث حتى إلى التطبيقات التي لا تعمل حاليا. لذلك، على سبيل المثال، يمكن التطبيق جدولة إنذار لنشر إخطار ليقول للمستخدم عن حدث قادم ... ومن خلال تقديم هذا التنبيه إلى بروادكاسترسيفر من التطبيق، ليست هناك حاجة للتطبيق أن تبقى قيد التشغيل حتى يطفيء المنبه. العديد من البرامج الإذاعية تنبع من النظام - على سبيل المثال، إذاعة تعلن أن الشاشة قد توقفت، أو البطارية منخفضة، أو تم التقاط صورة. يمكن للتطبيقات أيضا بدء البث - على سبيل المثال، للسماح للتطبيقات الأخرى بمعرفة أن بعض البيانات قد تم تنزيلها على الجهاز وهي متاحة لاستخدامها. على الرغم من أن مستقبلات البث لا تعرض واجهة مستخدم، فإنها قد تنشئ إشعار شريط الحالة لتنبيه المستخدم عند حدوث حدث بث. على الرغم من ذلك، على الرغم من أن جهاز البث الإذاعي هو مجرد بوابة إلى مكونات أخرى، ويهدف إلى القيام بقدر ضئيل جدا من العمل. على سبيل المثال، قد جدولة JobService لتنفيذ بعض الأعمال بناء على الحدث مع JobScheduler
ويتم تنفيذ مستقبل البث كفئة فرعية من BroadcastReceiver جهاز الاستقبال ويتم تسليم كل بث ككائن Intent . لمزيد من المعلومات، راجع فئة BroadcastReceiver .
موفري المحتوى
يدير موفر المحتوى مجموعة مشتركة من بيانات التطبيقات التي يمكنك تخزينها في نظام الملفات أو في قاعدة بيانات سكليت أو على الويب أو على أي موقع تخزين آخر ثابت يمكن للتطبيق الدخول إليه. من خلال موفر المحتوى، يمكن للتطبيقات الأخرى الاستعلام أو تعديل البيانات إذا كان مزود المحتوى يسمح بذلك. على سبيل المثال، يوفر نظام أندرويد موفر المحتوى الذي يدير معلومات الاتصال الخاصة بالمستخدم. على هذا النحو، أي التطبيق مع الأذونات المناسبة يمكن الاستعلام عن مزود المحتوى، مثل ContactsContract.Data ، لقراءة وكتابة المعلومات حول شخص معين. ومن المغري التفكير في موفر المحتوى كتجريد على قاعدة بيانات، لأن هناك الكثير من أبي والدعم المدمج في لهم لهذه الحالة المشتركة. ومع ذلك، فإن لها غرضا أساسيا مختلفا من منظور تصميم النظام. بالنسبة إلى النظام، فإن موفر المحتوى هو نقطة دخول إلى تطبيق لنشر عناصر البيانات المسماة، والتي يتم تحديدها بواسطة مخطط أوري. وبالتالي يمكن للتطبيق أن يقرر كيف يريد تعيين البيانات التي يحتوي على مساحة اسم أوري، مع تسليم تلك أوريس إلى الكيانات الأخرى التي يمكن بدورها استخدامها للوصول إلى البيانات. هناك عدد قليل من الأشياء الخاصة التي تسمح للنظام بتنفيذها في إدارة التطبيق:
لا يتطلب تعيين عنوان أوري أن يظل التطبيق قيد التشغيل، لذا يمكن أن تستمر عناوين ورل بعد الخروج من تطبيقات امتلاكها. يحتاج النظام فقط للتأكد من أن التطبيق امتلاك لا يزال قيد التشغيل عندما يكون لديك لاسترداد بيانات التطبيق من أوري المقابلة.
كما توفر عناوين ورل هذه نموذجا أمنيا هاما على شكل غرامة. على سبيل المثال، يمكن للتطبيق وضع معرف الموارد المنتظم (أوري) لصورة لديه في الحافظة، ولكن ترك موفر المحتوى محجوزا بحيث لا يمكن للتطبيقات الأخرى الدخول إليه بحرية. عندما يحاول التطبيق الثاني للوصول إلى هذا أوري على الحافظة، يمكن للنظام السماح لهذا التطبيق للوصول إلى البيانات عبر منحة إذن أوري مؤقتة بحيث يسمح له بالوصول إلى البيانات فقط وراء هذا أوري، ولكن لا شيء آخر في التطبيق الثاني .
مزودي المحتوى هي أيضا مفيدة لقراءة وكتابة البيانات التي هي خاصة إلى التطبيق الخاص بك وليس المشتركة. على سبيل المثال، يستخدم التطبيق ملاحظة وسادة الوسادة مزود المحتوى لحفظ الملاحظات.
يتم تنفيذ موفر المحتوى كفئة فرعية من ContentProvider ويجب تنفيذ مجموعة قياسية من واجهات برمجة التطبيقات التي تمكن التطبيقات الأخرى من تنفيذ المعاملات. لمزيد من المعلومات، راجع دليل مطوري برامج المحتوى .
وهناك جانب فريد من تصميم نظام أندرويد هو أن أي تطبيق يمكن أن يبدأ مكون التطبيق آخر. على سبيل المثال، إذا كنت تريد من المستخدم التقاط صورة باستخدام كاميرا الجهاز، فربما يكون هناك تطبيق آخر يقوم بذلك ويمكن لتطبيقك استخدامه بدلا من تطوير نشاط لالتقاط صورة بنفسك. أنت لا تحتاج إلى دمج أو حتى ربط إلى رمز من التطبيق الكاميرا. بدلا من ذلك، يمكنك ببساطة بدء النشاط في التطبيق الكاميرا التي تلتقط صورة. عند اكتمالها، يتم إرجاع الصورة إلى تطبيقك حتى تتمكن من استخدامها. بالنسبة للمستخدم، يبدو كما لو كانت الكاميرا هي في الواقع جزء من التطبيق الخاص بك.
عندما يبدأ النظام مكونا، فإنه يبدأ عملية لهذا التطبيق إذا لم يكن قيد التشغيل بالفعل ويخلق الطبقات المطلوبة للمكون. على سبيل المثال، إذا بدأ تطبيقك النشاط في تطبيق الكاميرا الذي يلتقط صورة، فسيتم تشغيل هذا النشاط في العملية التي تنتمي إلى تطبيق الكاميرا، وليس في عملية تطبيقك. لذلك، على عكس التطبيقات على معظم الأنظمة الأخرى، تطبيقات الروبوت ليس لديها نقطة دخول واحدة (لا يوجد وظيفة main() ).
نظرا لأن النظام يعمل على تشغيل كل تطبيق في عملية منفصلة تتضمن أذونات الملفات التي تقيد الدخول إلى تطبيقات أخرى، فإن تطبيقك لا يمكنه تنشيط مكون من تطبيق آخر مباشرة. ومع ذلك، يمكن لنظام أندرويد. لتنشيط مكون في تطبيق آخر، قم بتسليم رسالة إلى النظام الذي يحدد نيتك لبدء مكون معين. ثم يقوم النظام بتنشيط المكون لك.
تنشيط المكونات
ويتم تنشيط ثلاثة من أنواع المكونات الأربعة - الأنشطة والخدمات وأجهزة الاستقبال الإذاعية - بواسطة رسالة غير متزامنة تسمى النية . النوايا ربط المكونات الفردية لبعضها البعض في وقت التشغيل. يمكنك التفكير بها كرسلين يطلبون إجراء من مكونات أخرى، سواء كان العنصر ينتمي إلى التطبيق الخاص بك أو آخر.
يتم إنشاء Intent مع كائن Intent ، الذي يحدد رسالة لتنشيط إما مكون معين (القصد الصريح) أو نوع معين من المكون (القصد الضمني).
بالنسبة للأنشطة والخدمات، تحدد النية الإجراء المطلوب القيام به (على سبيل المثال، لعرض شيء ما أو إرساله ) وقد تحدد معرف الموارد المنتظم (أوري) للبيانات التي يجب اتخاذ إجراء بشأنها، من بين أمور أخرى قد يحتاج المكون الذي بدأ تشغيله إلى معرفته. على سبيل المثال، قد ينقل نية طلب نشاط لعرض صورة أو لفتح صفحة ويب. في بعض الحالات، يمكنك بدء نشاط لتلقي نتيجة، وفي هذه الحالة النشاط أيضا بإرجاع النتيجة في Intent . على سبيل المثال، يمكنك إصدار نية للسماح للمستخدم باختيار جهة اتصال شخصية وإعادتها إليك. تتضمن نية الإرجاع عنوان أوري يشير إلى جهة الاتصال التي تم اختيارها.
وبالنسبة لمستقبلات البث، فإن القصد من ذلك هو ببساطة تعريف الإعلان الذي يجري بثه. على سبيل المثال، يتضمن البث للإشارة إلى أن بطارية الجهاز منخفضة فقط سلسلة عمل معروفة تشير إلى أن البطارية منخفضة .
وخلافا للأنشطة والخدمات والمستقبلات الإذاعية، لا يتم تنشيط مزودي المحتوى عن طريق النوايا. بدلا من ذلك، يتم تنشيطها عند استهدافها من قبل طلب من ContentResolver . يتعامل محلل المحتوى مع كافة المعاملات المباشرة مع موفر المحتوى بحيث لا يحتاج المكون الذي يقوم بتنفيذ المعاملات مع الموفر وبدلا من ذلك باستدعاء أساليب على عنصر ContentResolver . هذا يترك طبقة من التجريد بين موفر المحتوى والمعلومات طلب المكون (للأمن).
هناك طرق منفصلة لتفعيل كل نوع من المكونات:
يمكنك بدء نشاط أو إعطاءه شيئا جديدا للقيام به عن طريق تمرير Intent startActivity() أو startActivityForResult() (عندما تريد النشاط لإرجاع نتيجة).
مع الروبوت 5.0 (مستوى أبي 21) وبعد ذلك، يمكنك استخدام فئة JobScheduler لجدولة الإجراءات. بالنسبة إلى إصدارات أندرويد السابقة، يمكنك بدء تشغيل خدمة (أو إعطاء تعليمات جديدة لخدمة مستمرة) عن طريق تمرير Intent إلى startService() . يمكنك ربط الخدمة عن طريق تمرير Intent إلى bindService() .
يمكنك بدء بث عن طريق تمرير Intent لطرق مثل sendBroadcast() ، sendOrderedBroadcast() ، أو sendStickyBroadcast() .
يمكنك تنفيذ استعلام لموفر محتوى عن طريق استدعاء query() على ContentResolver .
لمزيد من المعلومات حول استخدام النوايا، راجع وثيقة إنتنتس و إنتنت فيلترس . توفر الوثائق التالية المزيد من المعلومات حول تنشيط مكونات سبيسيفك: الأنشطة ، BroadcastReceiver سيسيفر ، ومزودي المحتوى .
ملف البيان
قبل أن يتمكن نظام أندرويد من بدء مكون التطبيق، يجب أن يعرف النظام أن المكون موجود من خلال قراءة ملف البيان الخاص بالتطبيق، AndroidManifest.xml . يجب أن يعلن التطبيق جميع مكوناته في هذا الملف، والتي يجب أن تكون في جذر دليل مشروع التطبيق.
البيان يفعل عددا من الأشياء بالإضافة إلى إعلان مكونات التطبيق، مثل ما يلي:
يحدد أي أذونات المستخدم يتطلب التطبيق، مثل الوصول إلى الإنترنت أو الوصول للقراءة إلى جهات اتصال المستخدم.
يعلن الحد الأدنى لمستوى أبي المطلوب من قبل التطبيق، استنادا إلى واجهات برمجة التطبيقات التي يستخدمها التطبيق.
يعلن ميزات الأجهزة والبرمجيات المستخدمة أو المطلوبة من قبل التطبيق، مثل الكاميرا، خدمات بلوتوث، أو شاشة اللمس المتعدد.
تعلن مكتبات أبي يحتاج التطبيق إلى ربط ضد (بخلاف واجهات برمجة التطبيقات إطار الروبوت)، مثل مكتبة خرائط جوجل .
إعلان المكونات
المهمة الأساسية للبيان هو إبلاغ النظام حول مكونات التطبيق. على سبيل المثال، يمكن لملف البيان أن يعلن نشاطا كما يلي:
<manifest ... >
...
<application ... >
<activity android:name="com.example.project.ComposeEmailActivity">
<intent-filter>
<action android:name="android.intent.action.SEND" />
<data android:type="*/*" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
</application>
</manifest>
إذا كان التطبيق آخر يخلق نية مع الإجراء ACTION_SEND ويمر عليه startActivity() ، قد يبدأ النظام نشاطك بحيث يمكن للمستخدم صياغة وإرسال بريد إلكتروني.
لمزيد من المعلومات حول إنشاء فلاتر القصد، راجع مستند فلاتر النوايا و إنتنت .
إعلان متطلبات التطبيق
هناك مجموعة متنوعة من الأجهزة مدعوم من الروبوت وليس كل منهم توفير نفس الميزات والقدرات. لمنع تثبيت تطبيقك على الأجهزة التي تفتقر إلى الميزات التي يحتاجها تطبيقك، من المهم أن تحدد بوضوح ملفا شخصيا لأنواع الأجهزة التي يدعمها تطبيقك من خلال إعلان متطلبات الجهاز والبرامج في ملف البيان. ومعظم هذه الإعلانات معلوماتية فقط ولا يقرأها النظام، ولكن الخدمات الخارجية مثل غوغل بلاي تقرأها من أجل توفير تصفية للمستخدمين عند البحث عن تطبيقات من أجهزتهم.
على سبيل المثال، إذا كان تطبيقك يتطلب كاميرا ويستخدم واجهات برمجة التطبيقات التي تم إدخالها في أندرويد 2.1 ( مستوى واجهة برمجة التطبيقات ( أبي ))، فيجب أن تعلن هذه المتطلبات كمتطلبات في ملف البيان كما هو موضح في المثال التالي:
<manifest ... >
<uses-feature android:name="android.hardware.camera.any"
android:required="true" />
<uses-sdk android:minSdkVersion="7" android:targetSdkVersion="19" />
...
</manifest>
مع الإعلانات الموضحة في المثال، الأجهزة التي ليس لديها كاميرا أو لديك نسخة أندرويد أقل من 2.1 لا يمكن تثبيت التطبيق الخاص بك من غوغل بلاي. ومع ذلك، يمكنك أن تعلن أن التطبيق الخاص بك يستخدم الكاميرا، ولكن لا يتطلب ذلك. وفي هذه الحالة، يجب أن يحدد التطبيق السمة required إلى false وأن يتحقق في وقت التشغيل ما إذا كان الجهاز يحتوي على كاميرا وتعطيل أية ميزات للكاميرا حسب الاقتضاء.
يتم توفير مزيد من المعلومات حول كيفية إدارة توافق تطبيقك مع أجهزة مختلفة في مستند توافق الجهاز .
موارد التطبيق
ويتكون التطبيق الروبوت أكثر من مجرد التعليمات البرمجية، فإنه يتطلب موارد منفصلة عن شفرة المصدر، مثل الصور والملفات الصوتية، وأي شيء يتعلق العرض المرئي من التطبيق. على سبيل المثال، يمكنك تعريف الرسوم المتحركة، والقوائم، والأنماط، والألوان، وتخطيط واجهات المستخدم النشاط مع ملفات شمل. يؤدي استخدام موارد التطبيق إلى سهولة تحديث الخصائص المختلفة لتطبيقك دون تعديل الشفرة. يتيح لك توفير مجموعات من الموارد البديلة تحسين تطبيقك لمجموعة متنوعة من عمليات تهيئة الأجهزة، مثل اللغات المختلفة وأحجام الشاشة.
لكل مورد تقوم بتضمينه في مشروع أندرويد الخاص بك، تقوم أدوات إنشاء سك بتعريف معرف صحيح فريد، يمكنك استخدامه للإشارة إلى المورد من شفرة التطبيق أو من الموارد الأخرى المعرفة في شمل. على سبيل المثال، إذا كان تطبيقك يحتوي على ملف صورة باسم logo.png (محفوظ في الدليل res/drawable/ )، فإن أدوات سك تولد معرف موارد باسم R.drawable.logo . هذا معرف الهوية إلى عدد صحيح التطبيق محددة، والتي يمكنك استخدامها للإشارة إلى الصورة وإدراجه في واجهة المستخدم.
أحد أهم جوانب توفير الموارد منفصلة عن شفرة المصدر الخاص بك هو القدرة على توفير موارد بديلة لتكوينات الجهاز المختلفة. على سبيل المثال، من خلال تحديد سلاسل واجهة المستخدم في شمل، يمكنك ترجمة السلاسل إلى لغات أخرى وحفظ تلك السلاسل في ملفات منفصلة. ثم يقوم أندرويد بتطبيق السلاسل اللغوية المناسبة على واجهة المستخدم استنادا إلى مؤهل اللغة الذي تلحقه باسم دليل المورد (مثل res/values-fr/ فور فرينش سترينغ فالويس) وإعداد لغة المستخدم.
الروبوت يدعم العديد من التصفيات المختلفة للموارد البديلة الخاصة بك. المؤهل عبارة عن سلسلة قصيرة تقوم بتضمينها في اسم دلائل المصادر الخاصة بك من أجل تعريف تكوين الجهاز الذي يجب استخدام تلك الموارد له. على سبيل المثال، يجب إنشاء تخطيطات مختلفة لأنشطتك، اعتمادا على اتجاه الشاشة وحجم الجهاز. عندما تكون شاشة الجهاز في اتجاه عمودي (طويل القامة)، قد تحتاج إلى تخطيط مع أزرار لتكون عمودية، ولكن عندما تكون الشاشة في اتجاه أفقي (واسعة)، يمكن محاذاة الأزرار أفقيا. لتغيير التخطيط اعتمادا على الاتجاه، يمكنك تحديد تخطيطين مختلفين وتطبيق المؤهل المناسب لكل اسم دليل تخطيط. ثم يقوم النظام تلقائيا بتطبيق التخطيط المناسب اعتمادا على اتجاه الجهاز الحالي.
لمزيد من المعلومات عن أنواع الموارد المختلفة التي يمكنك تضمينها في تطبيقك وكيفية إنشاء موارد بديلة لتكوينات الأجهزة المختلفة، اطلع على توفير الموارد . لمزيد من المعلومات عن أفضل الممارسات وتصميم تطبيقات قوية ذات جودة إنتاجية، اطلع على دليل لتطبيقات التطبيقات ..
توافق الجهاز
تم تصميم الروبوت لتشغيل على العديد من أنواع مختلفة من الأجهزة، من الهواتف إلى أقراص وأجهزة التلفزيون. كمطور، توفر مجموعة الأجهزة جمهورا محتملا كبيرا لتطبيقك. لكي يكون تطبيقك ناجحا على كل هذه الأجهزة، يجب أن يتسامح مع بعض ميزة التقلب ويوفر واجهة مستخدم مرنة تتكيف مع تكوينات الشاشة المختلفة.
لتسهيل جهودكم نحو تحقيق هذا الهدف، الروبوت يوفر إطار التطبيق الديناميكي الذي يمكنك توفير موارد التطبيق التكوين محددة في ملفات ثابتة (مثل تخطيطات شمل مختلفة لأحجام الشاشة المختلفة). ثم يقوم الروبوت بتحميل الموارد المناسبة استنادا إلى تكوين الجهاز الحالي. حتى مع بعض التفكير لتصميم التطبيق الخاص بك وبعض موارد التطبيق إضافية، يمكنك نشر حزمة تطبيق واحد (أبك) التي توفر تجربة المستخدم الأمثل على مجموعة متنوعة من الأجهزة.
ولكن إذا لزم الأمر، يمكنك تحديد متطلبات ميزة تطبيقك والتحكم في أنواع الأجهزة التي يمكنها تثبيت تطبيقك من متجر غوغل بلاي. توضح هذه الصفحة كيفية التحكم في الأجهزة التي يمكنها الدخول إلى تطبيقاتك، وكيفية إعداد تطبيقاتك للتأكد من وصولها إلى الجمهور المناسب. لمزيد من المعلومات حول كيفية جعل تطبيقك يتكيف مع أجهزة مختلفة، اقرأ دعم الأجهزة المختلفة .
ماذا يعني "التوافق"؟
كما تقرأ المزيد عن تطوير الروبوت، وربما كنت تواجه مصطلح "التوافق" في حالات مختلفة. هناك نوعان من التوافق: التوافق الجهاز والتطبيق التوافق .
لأن الروبوت هو مشروع مفتوح المصدر، يمكن لأي شركة تصنيع الأجهزة بناء جهاز يعمل بنظام التشغيل أندرويد. ومع ذلك، فإن الجهاز هو "متوافق الروبوت" إلا إذا كان يمكن تشغيل التطبيقات بشكل صحيح مكتوبة لبيئة التنفيذ الروبوت . يتم تعريف التفاصيل الدقيقة لبيئة تنفيذ أندرويد بواسطة برنامج توافق أندرويد ويجب على كل جهاز اجتياز جناح اختبار التوافق (كتس) لكي يعتبر متوافقا.
كمطور تطبيقات، لا داعي للقلق بشأن ما إذا كان الجهاز متوافق مع أندرويد، وذلك لأن الأجهزة المتوافقة مع نظام التشغيل أندرويد هي فقط غوغل بلاي ستور. لذلك يمكنك أن تطمئن إلى أن المستخدمين الذين تثبيت التطبيق الخاص بك من متجر غوغل بلاي تستخدم جهاز متوافق مع الروبوت.
ومع ذلك، تحتاج إلى النظر فيما إذا كان تطبيقك متوافقا مع كل تهيئة محتملة للجهاز. لأن الروبوت يعمل على مجموعة واسعة من تكوينات الجهاز، بعض الميزات غير متوفرة على جميع الأجهزة. على سبيل المثال، قد لا تتضمن بعض الأجهزة مستشعر بوصلة. إذا كانت الوظيفة الأساسية لتطبيقك تتطلب استخدام جهاز استشعار بوصلة، فإن تطبيقك متوافق فقط مع الأجهزة التي تتضمن مستشعر بوصلة.
التحكم في توفر تطبيقك للأجهزة
الروبوت يدعم مجموعة متنوعة من الميزات التطبيق الخاص بك يمكن الاستفادة من خلال واجهات برمجة التطبيقات منصة. بعض الميزات تعتمد على الأجهزة (مثل جهاز استشعار البوصلة)، وبعضها القائم على البرمجيات (مثل الحاجيات التطبيق)، وبعضها يعتمد على إصدار المنصة. لا يدعم كل جهاز كل ميزة، لذا قد تحتاج إلى التحكم في توفر تطبيقك للأجهزة استنادا إلى الميزات المطلوبة لتطبيقك.
لتحقيق أكبر قاعدة مستخدم ممكنة لتطبيقك، يجب أن تسعى إلى دعم أكبر عدد ممكن من عمليات تهيئة الجهاز باستخدام ملف أبك واحد. في معظم الحالات، يمكنك القيام بذلك عن طريق تعطيل الميزات الاختيارية في وقت التشغيل وتوفير موارد التطبيق مع بدائل لتكوينات مختلفة (مثل تخطيطات مختلفة لأحجام الشاشة المختلفة). إذا لزم الأمر، ومع ذلك، يمكنك تقييد توافر التطبيق الخاص بك إلى الأجهزة من خلال متجر غوغل بلاي على أساس خصائص الجهاز التالية:
- ميزات الجهاز
- إصدار منصة
- تكوين الشاشة
- ميزات الجهاز
لكي تتمكن من إدارة توفر تطبيقك استنادا إلى ميزات الجهاز، يعرف أندرويد المعرفات الخاصة بالأجهزة لأي ميزة من أجهزة أو برامج قد لا تكون متاحة على جميع الأجهزة. على سبيل المثال، رقم تعريف الميزة لمستشعر البوصلة هو FEATURE_SENSOR_COMPASS ويكون معرف الميزة لأدوات تطبيق التطبيق FEATURE_APP_WIDGETS .
إذا لزم الأمر، يمكنك منع المستخدمين من تثبيت تطبيقك عندما لا توفر أجهزتهم ميزة معينة من خلال إعلانها باستخدام عنصر <uses-feature> في ملف بيان التطبيق.
على سبيل المثال، إذا كان التطبيق الخاص بك لا معنى له على الجهاز الذي يفتقر إلى جهاز استشعار البوصلة، يمكنك إعلان استشعار البوصلة كما هو مطلوب مع علامة البيان التالي:
<manifest ... >
<uses-feature android:name="android.hardware.sensor.compass"
android:required="true" />
...
</manifest>
يقارن متجر غوغل بلاي الميزات التي يتطلبها تطبيقك للميزات المتوفرة على جهاز كل مستخدم لتحديد ما إذا كان تطبيقك متوافقا مع كل جهاز. إذا لم يوفر الجهاز جميع الميزات التي يتطلبها تطبيقك، فلن يتمكن المستخدم من تثبيت تطبيقك.
ومع ذلك، إذا كانت الوظيفة الأساسية لتطبيقك لا تتطلب ميزة جهاز، فيجب تعيين السمة required إلى "false" والتحقق من وجود ميزة الجهاز في وقت التشغيل. إذا كانت ميزة التطبيق غير متوفرة على الجهاز الحالي، تتحلل بأمان ميزة التطبيق المقابلة. على سبيل المثال، يمكنك الاستعلام عما إذا كانت الميزة متاحة عن طريق استدعاء hasSystemFeature() مثل هذا:
PackageManager pm = getPackageManager();
if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
// This device does not have a compass, turn off the compass feature
disableCompassFeature();
}
للحصول على معلومات حول جميع الفلاتر التي يمكنك استخدامها للتحكم في مدى توفر التطبيق للمستخدمين من خلال متجر غوغل بلاي، اطلع على الفلاتر على مستند غوغل بلاي .
ملاحظة: تتطلب بعض أذونات النظام ضمنا توفر ميزة الجهاز. على سبيل المثال، إذا طلب تطبيقك إذنا بالدخول إلى BLUETOOTH ، فهذا يتطلب ضمنا ميزة جهاز FEATURE_BLUETOOTH . يمكنك تعطيل التصفية استنادا إلى هذه الميزة وجعل تطبيقك متاحا للأجهزة بدون البلوتوث عن طريق تعيين السمة required إلى "false" في علامة <uses-feature> . لمزيد من المعلومات حول ميزات الجهاز المطلوبة ضمنيا، اقرأ الأذونات التي تتضمن متطلبات الميزة .
إصدار منصة
قد تعمل الأجهزة المختلفة على تشغيل إصدارات مختلفة من نظام التشغيل أندرويد، مثل أندرويد 4.0 أو أندرويد 4.4. كل إصدار منصة متعاقبة غالبا ما يضيف واجهات برمجة تطبيقات جديدة غير متوفرة في الإصدار السابق. للإشارة إلى مجموعة من واجهات برمجة التطبيقات ( أبي) المتاحة، يحدد كل إصدار من إصدارات النظام الأساسي مستوى واجهة برمجة التطبيقات (أبي) . على سبيل المثال، أندرويد 1.0 هو أبي ليفيل 1 أند أندرويد 4.4 هو أبي ليفيل 19.
يسمح لك مستوى واجهة برمجة التطبيقات بإعلان الحد الأدنى من الإصدار الذي يتوافق فيه تطبيقك، باستخدام علامة <uses-sdk> minSdkVersion <uses-sdk> minSdkVersion .
على سبيل المثال، تمت إضافة واجهات برمجة تطبيقات مزود التقويم في أندرويد 4.0 (مستوى واجهة برمجة التطبيقات 14). إذا كان التطبيق الخاص بك لا يمكن أن تعمل دون هذه واجهات برمجة التطبيقات، يجب أن تعلن مستوى أبي 14 كما الحد الأدنى من النسخة المعتمدة التطبيق الخاص بك مثل هذا:
<manifest ... >
<uses-sdk android:minSdkVersion="14" android:targetSdkVersion="19" />
...
</manifest>
minSdkVersion السمة minSdkVersion الحد الأدنى من الإصدار الذي يتوافق فيه targetSdkVersion وتعلن السمة targetSdkVersion أعلى إصدار تم تحسين تطبيقك عليه.
توفر كل نسخة متعاقبة من أندرويد التوافق للتطبيقات التي تم إنشاؤها باستخدام واجهات برمجة التطبيقات من إصدارات الأنظمة الأساسية السابقة، لذا يجب أن يكون تطبيقك متوافقا دائما مع الإصدارات المستقبلية من أندرويد أثناء استخدام واجهات برمجة تطبيقات أندرويد الموثقة.
ملاحظة: لا يمنع السمة targetSdkVersion التطبيق الخاص بك من تثبيت على إصدارات المنصة التي هي أعلى من القيمة المحددة، ولكن من المهم لأنه يشير إلى النظام ما إذا كان التطبيق الخاص بك يجب أن ترث تغييرات السلوك في الإصدارات الأحدث. إذا لم تقم بتحديث targetSdkVersion إلى أحدث إصدار، يفترض النظام أن التطبيق يتطلب بعض السلوكيات التوافق مع الخلف عند تشغيل على أحدث إصدار. على سبيل المثال، من بين التغييرات السلوك في الروبوت 4.4 ، وأجهزة الإنذار التي تم إنشاؤها باستخدام واجهات برمجة التطبيقات AlarmManager غير الآن غير دقيقة افتراضيا حتى يمكن للنظام دفعة التنبيهات التطبيق والحفاظ على قوة النظام، ولكن النظام سوف يحتفظ السلوك أبي السابق لتطبيقك إذا أبي الهدف الخاص بك مستوى أقل من "19".
ومع ذلك، إذا كان تطبيقك يستخدم واجهات برمجة التطبيقات التي تمت إضافتها في إصدار نظام أساسي أحدث، ولكنه لا يتطلبها لوظيفته الأساسية، فيجب عليك التحقق من مستوى واجهة برمجة التطبيقات عند وقت التشغيل وتقليل الميزات المقابلة بشكل سليم عندما يكون مستوى واجهة برمجة التطبيقات منخفضا للغاية. في هذه الحالة، minSdkVersion إلى أدنى قيمة ممكنة للوظيفة الأساسية لتطبيقك، ثم قارن إصدار النظام الحالي، SDK_INT ، إلى ثوابت الرمز Build.VERSION_CODES في Build.VERSION_CODES التي تتوافق مع مستوى واجهة برمجة التطبيقات الذي تريد التحقق منه. فمثلا:
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
// Running on something older than API level 11, so disable
// the drag/drop features that use ClipboardManager APIs
disableDragAndDrop();
}
تكوين الشاشة
الروبوت يعمل على أجهزة من مختلف الأحجام، من الهواتف إلى أقراص وأجهزة التلفاز. من أجل تصنيف الأجهزة حسب نوع الشاشة الخاصة بهم، الروبوت يعرف اثنين من الخصائص لكل جهاز: حجم الشاشة (الحجم المادي للشاشة) وكثافة الشاشة (الكثافة المادية للبكسل على الشاشة، والمعروفة باسم دبي ). لتبسيط التهيئات المختلفة، يعمل نظام التشغيل أندرويد على تعميم هذه المتغيرات في مجموعات تسهل استهدافها:
أربعة أحجام معممة: صغيرة، عادية، كبيرة، و زلارج.
والعديد من الكثافات المعممة: مدبي (متوسطة)، هدبي (هدبي)، شدبي (عالية جدا)، زسهدبي (اضافية اضافية عالية)، وغيرها.
بشكل افتراضي، يتوافق تطبيقك مع جميع أحجام الشاشة وكثافاتها، لأن النظام يقوم بإجراء التعديلات المناسبة على تخطيط واجهة المستخدم وموارد الصور حسب الضرورة لكل شاشة. ومع ذلك، يجب تحسين تجربة المستخدم لكل تهيئة شاشة من خلال إضافة تخطيطات متخصصة لأحجام مختلفة للشاشة وصور نقطية محسنة لكثافات الشاشة الشائعة.
للحصول على معلومات حول كيفية إنشاء موارد بديلة لشاشات مختلفة وكيفية تقييد تطبيقك على أحجام معينة للشاشة عند الضرورة، اقرأ دعم شاشات مختلفة .
التحكم في توفر تطبيقك لأسباب تجارية
بالإضافة إلى تقييد توفر تطبيقك استنادا إلى خصائص الجهاز، فمن الممكن أنك قد تحتاج إلى تقييد توفر التطبيق لأسباب تجارية أو قانونية. على سبيل المثال، من غير المحتمل أن يكون التطبيق الذي يعرض جداول القطار لمترو الأنفاق في لندن مفيدا للمستخدمين خارج المملكة المتحدة. لهذا النوع من الحالات، يوفر متجر غوغل بلاي خيارات التصفية في وحدة تحكم بلاي التي تسمح لك بالتحكم في توفر تطبيقك لأسباب غير فنية مثل لغة المستخدم أو مشغل شبكة الجوال اللاسلكي.
وتستند تصفية التوافق التقني (مثل مكونات الأجهزة المطلوبة) دائما إلى المعلومات المضمنة في ملف أبك. ولكن تتم معالجة التصفية لأسباب غير تقنية (مثل اللغة الجغرافية) دائما في وحدة تحكم غوغل بلاي.
أعرف أكثر:
توافق الجهاز
نظرة عامة على الموارد
نظرة عامة على واجهة المستخدم
أعرف أكثر:
أساسيات التطبيق
النوايا والنوايا مرشحات
أنشطة
