تعريف التوافق مع Android 2.1

حقوق الطبع والنشر © 2010، شركة Google Inc. جميع الحقوق محفوظة.
التوافق@android.com

1 المقدمة

يعدد هذا المستند المتطلبات التي يجب استيفاؤها حتى تكون الهواتف المحمولة متوافقة مع Android 2.1.

إن استخدام "يجب" و"يجب ألا" و"مطلوب" و"يجب" و"لا يجوز" و"ينبغي" و"لا ينبغي" و"موصى به" و"يجوز" و"اختياري" يتوافق مع معيار IETF تم تعريفه في RFC2119 [ الموارد، 1 ].

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

لكي يتم اعتباره متوافقًا مع Android 2.1، فإن تطبيقات الأجهزة:

  • يجب أن تستوفي المتطلبات الواردة في تعريف التوافق هذا، بما في ذلك أي مستندات مدمجة عبر المرجع.
  • يجب اجتياز أحدث إصدار من مجموعة اختبار توافق Android (CTS) المتوفرة في وقت اكتمال برنامج تنفيذ الجهاز. (يتوفر CTS كجزء من مشروع Android مفتوح المصدر [ الموارد، 2 ].) يختبر CTS العديد من المكونات الموضحة في هذا المستند، ولكن ليس كلها.

عندما يكون هذا التعريف أو CTS صامتًا أو غامضًا أو غير مكتمل، تقع على عاتق منفذ الجهاز مسؤولية ضمان التوافق مع التطبيقات الحالية. لهذا السبب، يعد مشروع Android مفتوح المصدر [ الموارد، 3 ] هو المرجع والتنفيذ المفضل لنظام Android. يتم تشجيع منفذي الأجهزة بشدة على تأسيس عمليات التنفيذ الخاصة بهم على كود المصدر "المنبع" المتوفر من مشروع Android مفتوح المصدر. في حين أنه يمكن استبدال بعض المكونات افتراضيًا بتطبيقات بديلة، إلا أنه لا يتم تشجيع هذه الممارسة بشدة، حيث أن اجتياز اختبارات CTS سيصبح أكثر صعوبة إلى حد كبير. تقع على عاتق المُنفِّذ مسؤولية ضمان التوافق السلوكي الكامل مع تطبيق Android القياسي، بما في ذلك مجموعة اختبار التوافق وما بعدها. أخيرًا، لاحظ أن بعض بدائل وتعديلات المكونات محظورة صراحةً بموجب هذه الوثيقة.

2.
  • مستويات متطلبات موارد IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
  • نظرة عامة على برنامج توافق Android: http://source.android.com/compatibility/index.html
  • مشروع Android مفتوح المصدر: http: //source.android.com/
  • تعريفات ووثائق واجهة برمجة التطبيقات: http://developer.android.com/reference/packages.html
  • مرجع أذونات Android: http://developer.android.com/reference/android/Manifest.permission. html
  • android.os.Build مرجع: http://developer.android.com/reference/android/os/Build.html
  • Android 2.1 سلاسل الإصدار المسموح بها: http://source.android.com/docs/compatibility/2.1/versions .html
  • فئة android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
  • HTML5: http://www.whatwg.org/specs/web-apps/current-work/ multipage/
  • مواصفات Dalvik Virtual Machine: متوفرة في كود مصدر Android، على dalvik/docs
    •
  • AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  • الإخطارات: http://developer.android.com /guide/topics/ui/notifiers/notifications.html
  • موارد التطبيق: http://code.google.com/android/reference/available-resources.html
  • دليل نمط رمز شريط الحالة: http://developer.android.com/ Guide/practices/ui_guideline /icon_design.html#statusbarstructure
  • مدير البحث: http://developer.android.com/reference/android/app/SearchManager.html
  • الخبز المحمص: http://developer.android.com/reference/android/widget /Toast.html
  • خلفيات حية: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  • تطبيقات لنظام Android: http://code.google.com/p/apps-for-android
  • مرجع وثائق الأداة (لـ adb وaapt وddms): http://developer.android.com/guide/developing/tools/index.html
  • وصف ملف Android apk: http://developer.android.com/guide/topics/fundamentals .html
  • ملفات البيان: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  • أداة اختبار القرد: https://developer.android.com/studio/test/other-testing-tools/ قرد
  • يدعم شاشات متعددة: http://developer.android.com/guide/practices/screens_support.html
  • android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration. html
  • android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  • android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera. html
  • مساحة تنسيق المستشعر: http://developer.android.com/reference/android/hardware/SensorEvent.html
  • مرجع أمان Android والأذونات: http://developer.android.com/guide/topics/security/security.html
  • Bluetooth واجهة برمجة التطبيقات: http://developer.android.com/reference/android/bluetooth/package-summary.html

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

    3. البرمجيات

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

    3.1. توافق واجهة برمجة التطبيقات المُدارة (API

    ) تعد بيئة التنفيذ المُدارة (المعتمدة على Dalvik) هي الوسيلة الأساسية لتطبيقات Android. واجهة برمجة تطبيقات Android (API) هي مجموعة واجهات نظام Android الأساسي المعرضة للتطبيقات التي تعمل في بيئة VM المُدارة. يجب أن توفر تطبيقات الأجهزة تطبيقات كاملة، بما في ذلك جميع السلوكيات الموثقة، لأي واجهة برمجة تطبيقات موثقة تم الكشف عنها بواسطة Android 2.1 SDK [ الموارد، 4 ].

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

    3.2. توافق واجهة برمجة التطبيقات الناعمة

    بالإضافة إلى واجهات برمجة التطبيقات المُدارة من القسم 3.1، يشتمل Android أيضًا على واجهة برمجة تطبيقات "ناعمة" مهمة لوقت التشغيل فقط، في شكل أشياء مثل المقاصد والأذونات والجوانب المماثلة لتطبيقات Android التي لا يمكن تنفيذها في التطبيق وقت الترجمة. يعرض هذا القسم تفاصيل واجهات برمجة التطبيقات "الناعمة" وسلوكيات النظام المطلوبة للتوافق مع Android 2.1. يجب أن تستوفي تطبيقات الأجهزة جميع المتطلبات الواردة في هذا القسم.

    3.2.1.

    يجب على

    منفذي

    الأجهزة دعم وتنفيذ جميع ثوابت الأذونات كما هو موثق في الصفحة المرجعية للأذونات [ الموارد، 5 ]. لاحظ أن القسم 10 يسرد المتطلبات الإضافية المتعلقة بنموذج أمان Android.

    3.2.2. معلمات البناء

    تتضمن واجهات برمجة تطبيقات Android عددًا من الثوابت في فئة android.os.Build [ Resources, 6 ] التي تهدف إلى وصف الجهاز الحالي. لتوفير قيم متسقة وذات معنى عبر تطبيقات الأجهزة، يتضمن الجدول أدناه قيودًا إضافية على تنسيقات هذه القيم التي يجب أن تتوافق معها تطبيقات الأجهزة.

    تعليقات المعلمة
    android.os.Build.VERSION.RELEASE إصدار نظام Android الذي يتم تنفيذه حاليًا، بتنسيق يمكن قراءته بواسطة الإنسان. يجب أن يحتوي هذا الحقل على إحدى قيم السلسلة المحددة في [ الموارد، 7 ].
    android.os.Build.VERSION.SDK إصدار نظام Android الذي يتم تنفيذه حاليًا، بتنسيق يمكن الوصول إليه بواسطة كود تطبيق الطرف الثالث. بالنسبة إلى Android 2.1، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 7.
    android.os.Build.VERSION.INCREMENTAL قيمة يتم اختيارها بواسطة منفذ الجهاز الذي يحدد البنية المحددة لنظام Android الذي يتم تنفيذه حاليًا، بتنسيق يمكن قراءته بواسطة الإنسان. يجب عدم إعادة استخدام هذه القيمة للإصدارات المختلفة التي يتم شحنها إلى المستخدمين النهائيين. الاستخدام النموذجي لهذا الحقل هو الإشارة إلى رقم الإصدار أو معرف تغيير التحكم بالمصدر الذي تم استخدامه لإنشاء الإصدار. لا توجد متطلبات بشأن التنسيق المحدد لهذا الحقل، باستثناء أنه يجب ألا يكون فارغًا أو سلسلة فارغة ("").
    android.os.Build.BOARD قيمة يختارها منفذ الجهاز لتحديد الأجهزة الداخلية المحددة التي يستخدمها الجهاز، بتنسيق يمكن قراءته بواسطة الإنسان. الاستخدام المحتمل لهذا الحقل هو الإشارة إلى المراجعة المحددة للوحة التي تعمل على تشغيل الجهاز. لا توجد متطلبات بشأن التنسيق المحدد لهذا الحقل، باستثناء أنه يجب ألا يكون فارغًا أو سلسلة فارغة ("").
    android.os.Build.BRAND قيمة يختارها منفذ الجهاز لتحديد اسم الشركة أو المؤسسة أو الفرد وما إلى ذلك الذي أنتج الجهاز، بتنسيق يمكن قراءته بواسطة الإنسان. الاستخدام المحتمل لهذا الحقل هو الإشارة إلى الشركة المصنعة و/أو شركة الاتصالات التي باعت الجهاز. لا توجد متطلبات بشأن التنسيق المحدد لهذا الحقل، باستثناء أنه يجب ألا يكون فارغًا أو سلسلة فارغة ("").
    android.os.Build.DEVICE قيمة يختارها منفذ الجهاز لتحديد التكوين أو المراجعة المحددة لجسم الجهاز (يسمى أحيانًا "التصميم الصناعي") للجهاز. لا توجد متطلبات بشأن التنسيق المحدد لهذا الحقل، باستثناء أنه يجب ألا يكون فارغًا أو سلسلة فارغة ("").
    android.os.Build.FINGERPRINT سلسلة تحدد هذا الإصدار بشكل فريد. يجب أن تكون قابلة للقراءة بشكل معقول من قبل الإنسان. يجب أن يتبع هذا القالب:
    $(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
    على سبيل المثال:
    acme/mydevice/generic/generic:2.1-update1/ERC77/3359:userdebug/test-keys
    يجب ألا تتضمن بصمة الإصبع مسافات. إذا كانت الحقول الأخرى المضمنة في القالب أعلاه تحتوي على مسافات، فيجب استبدالها بحرف ASCII الشرطة السفلية ("_") في بصمة الإصبع.
    android.os.Build.HOST سلسلة تحدد بشكل فريد المضيف الذي تم بناء البنية عليه، بتنسيق يمكن قراءته بواسطة الإنسان. لا توجد متطلبات بشأن التنسيق المحدد لهذا الحقل، باستثناء أنه يجب ألا يكون فارغًا أو سلسلة فارغة ("").
    android.os.Build.ID معرف يتم اختياره بواسطة منفذ الجهاز للإشارة إلى إصدار محدد، بتنسيق يمكن قراءته بواسطة الإنسان. يمكن أن يكون هذا الحقل هو نفسه android.os.Build.VERSION.INCREMENTAL، ولكن يجب أن تكون قيمة ذات معنى بما فيه الكفاية للمستخدمين النهائيين للتمييز بين إصدارات البرامج. لا توجد متطلبات بشأن التنسيق المحدد لهذا الحقل، باستثناء أنه يجب ألا يكون فارغًا أو سلسلة فارغة ("").
    android.os.Build.MODEL قيمة يتم اختيارها بواسطة منفذ تنفيذ الجهاز وتحتوي على اسم الجهاز كما هو معروف للمستخدم النهائي. يجب أن يكون هذا هو الاسم نفسه الذي يتم بموجبه تسويق الجهاز وبيعه للمستخدمين النهائيين. لا توجد متطلبات بشأن التنسيق المحدد لهذا الحقل، باستثناء أنه يجب ألا يكون فارغًا أو سلسلة فارغة ("").
    android.os.Build.PRODUCT قيمة يختارها منفذ الجهاز وتحتوي على اسم التطوير أو الاسم الرمزي للجهاز. يجب أن تكون قابلة للقراءة من قبل الإنسان، ولكن ليس بالضرورة أن تكون مخصصة للعرض من قبل المستخدمين النهائيين. لا توجد متطلبات بشأن التنسيق المحدد لهذا الحقل، باستثناء أنه يجب ألا يكون فارغًا أو سلسلة فارغة ("").
    android.os.Build.TAGS قائمة مفصولة بفواصل من العلامات التي اختارها منفذ الجهاز والتي تميز البنية بشكل أكبر. على سبيل المثال، "غير موقع، تصحيح". يجب ألا يكون هذا الحقل فارغًا أو سلسلة فارغة ("")، ولكن لا بأس باستخدام علامة واحدة (مثل "release").
    android.os.Build.TIME قيمة تمثل الطابع الزمني لوقت حدوث الإنشاء.
    android.os.Build.TYPE قيمة يتم اختيارها بواسطة منفذ الجهاز لتحديد تكوين وقت التشغيل للبنية. يجب أن يحتوي هذا الحقل على إحدى القيم المقابلة لتكوينات وقت تشغيل Android الثلاثة النموذجية: "user" أو "userdebug" أو "eng".
    android.os.Build.USER اسم أو معرف المستخدم للمستخدم (أو المستخدم الآلي) الذي قام بإنشاء الإصدار. لا توجد متطلبات بشأن التنسيق المحدد لهذا الحقل، باستثناء أنه يجب ألا يكون فارغًا أو سلسلة فارغة ("").

    3.2.3. توافق النوايا

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

    3.2.3.1. نوايا التطبيق الأساسية

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

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

    تعتبر التطبيقات التالية تطبيقات أساسية لنظام Android:

    • ساعة المكتب
    • ، المتصفح،
    • التقويم،
    • الحاسبة،
    • جهات الاتصال،
    • الكاميرا
    • ، معرض
    • البريد الإلكتروني
      • ،
    • GlobalSearch
    • Launcher
    • LivePicker (أي تطبيق منتقي Live Wallpaper؛ قد يتم حذفه إذا كان الجهاز لا يدعم Live Wallpapers، وفقًا للقسم 3.8.5. )
    • المراسلة (AKA "Mms")
    • الموسيقى
    • إعدادات
    • الهاتف
    • مسجل الصوت

    تتضمن تطبيقات نظام Android الأساسية العديد من مكونات الأنشطة أو الخدمة التي تعتبر "عامة". أي أن السمة "android:exported" قد تكون غائبة، أو قد تكون قيمتها "صحيح".

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

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

    3.2.3.2. تجاوزات النية

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

    ملحوظة: تم تعديل هذا القسم بواسطة Erratum EX6580.

    3.2.3.3.

    يجب ألا يتضمن منفذو الأجهزة

    Intent Namespaces

    أي مكون Android يحترم أي أنماط Intent أو Broadcast Intent جديدة باستخدام ACTION أو CATEGORY أو سلسلة مفاتيح أخرى في مساحة الاسم android.*. يجب ألا يقوم منفذو الأجهزة بتضمين أي مكونات Android تحترم أي نوايا جديدة أو أنماط نوايا البث باستخدام ACTION أو CATEGORY أو سلسلة مفاتيح أخرى في مساحة الحزمة التي تنتمي إلى مؤسسة أخرى. يجب على منفذي الأجهزة عدم تغيير أو توسيع أي من أنماط النوايا التي تستخدمها التطبيقات الأساسية المدرجة في القسم 3.2.3.1.

    يشبه هذا الحظر الحظر المحدد لفئات لغة Java في القسم 3.6.

    3.2.3.4. نوايا البث

    تعتمد تطبيقات الطرف الثالث على النظام الأساسي لبث نوايا معينة لإعلامها بالتغييرات في بيئة الأجهزة أو البرامج. يجب على الأجهزة المتوافقة مع Android بث نوايا البث العامة استجابةً لأحداث النظام المناسبة. تم توضيح نوايا البث في وثائق SDK.

    3.3. توافق واجهة برمجة التطبيقات الأصلية (API)

    يمكن للتعليمات البرمجية المُدارة التي يتم تشغيلها في Dalvik استدعاء التعليمات البرمجية الأصلية المتوفرة في ملف .apk للتطبيق كملف ELF .so تم تجميعه لبنية أجهزة الجهاز المناسبة. يجب أن تتضمن تطبيقات الأجهزة دعمًا للتعليمات البرمجية التي يتم تشغيلها في البيئة المُدارة لاستدعاء التعليمات البرمجية الأصلية، باستخدام دلالات Java Native Interface (JNI) القياسية. يجب أن تكون واجهات برمجة التطبيقات التالية متاحة للتعليمات البرمجية الأصلية:

    • libc (مكتبة C)
    • libm (مكتبة الرياضيات)
    • واجهة JNI
    • libz (ضغط Zlib)
    • liblog (تسجيل Android)
    • الحد الأدنى من الدعم لـ C++
    • دعم OpenGL، كما هو موضح أدناه
      • يجب أن

    تدعم تطبيقات الأجهزة OpenGL ES 1.0 . يجب على الأجهزة التي تفتقر إلى تسريع الأجهزة أن تقوم بتطبيق OpenGL ES 1.0 باستخدام جهاز عرض البرامج. يجب أن تنفذ تطبيقات الأجهزة قدرًا كبيرًا من OpenGL ES 1.1 الذي تدعمه أجهزة الجهاز. يجب أن توفر تطبيقات الأجهزة تطبيقًا لـ OpenGL ES 2.0، إذا كان الجهاز قادرًا على تقديم أداء معقول على واجهات برمجة التطبيقات هذه.

    يجب أن تكون هذه المكتبات متوافقة مع المصدر (أي متوافقة مع الرأس) ومتوافقة مع الثنائي (لبنية معالج معينة) مع الإصدارات المتوفرة في Bionic بواسطة مشروع Android Open Source. نظرًا لأن تطبيقات Bionic غير متوافقة تمامًا مع التطبيقات الأخرى مثل مكتبة GNU C، فيجب على منفذي الأجهزة استخدام تطبيق Android. إذا كان منفذو الأجهزة يستخدمون تطبيقًا مختلفًا لهذه المكتبات، فيجب عليهم التأكد من التوافق الرأسي والثنائي والسلوكي.

    يجب أن تبلغ عمليات تنفيذ الجهاز بدقة عن الواجهة الثنائية للتطبيقات (ABI) الأصلية التي يدعمها الجهاز، عبر android.os.Build.CPU_ABI API. يجب أن يكون ABI أحد الإدخالات الموثقة في أحدث إصدار من Android NDK، في الملف docs/CPU-ARCH-ABIS.txt . لاحظ أن الإصدارات الإضافية من Android NDK قد تقدم دعمًا لواجهات ABI الإضافية.

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

    3.4. توافق واجهة برمجة تطبيقات الويب

    يعتمد العديد من المطورين والتطبيقات على سلوك فئة android.webkit.WebView [ الموارد، 8 ] في واجهات المستخدم الخاصة بهم، لذلك يجب أن يكون تطبيق WebView متوافقًا عبر تطبيقات Android. يستخدم تطبيق Android Open Source محرك عرض WebKit لتنفيذ WebView.

    نظرًا لأنه ليس من الممكن تطوير مجموعة اختبار شاملة لمتصفح الويب، يجب على منفذي الأجهزة استخدام البنية الأولية المحددة لـ WebKit في تطبيق WebView. على وجه التحديد:

    • يجب أن يستخدم WebView الإصدار 530.17 WebKit من شجرة Android مفتوحة المصدر لنظام Android 2.1. يتضمن هذا الإصدار مجموعة محددة من إصلاحات الوظائف والأمان لـ WebView.
    • يجب أن تكون سلسلة وكيل المستخدم التي أبلغ عنها WebView بهذا التنسيق:
      Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17
      • قيمة يجب أن تكون سلسلة $(VERSION) هي نفس قيمة android.os.Build.VERSION.RELEASE
      • يجب أن تتبع قيمة سلسلة $(LOCALE) اصطلاحات ISO لرمز البلد واللغة، ويجب أن تشير إلى اللغة المحلية التي تم تكوينها حاليًا للجهاز
      • يجب أن تكون قيمة سلسلة $(MODEL) هي نفس قيمة android.os.Build.MODEL
      • يجب أن تكون قيمة سلسلة $(BUILD) هي نفس قيمة android.os.Build.ID
    قد تقوم عمليات تنفيذ
      • android.os.Build.ID

    بشحن سلسلة وكيل مستخدم مخصصة في تطبيق المتصفح المستقل. علاوة على ذلك، قد يعتمد المتصفح المستقل على تقنية متصفح بديلة (مثل Firefox وOpera وما إلى ذلك). ومع ذلك، حتى إذا تم شحن تطبيق متصفح بديل، فإن مكون WebView المقدم لتطبيقات الطرف الثالث يجب أن يعتمد على WebKit، على النحو الوارد أعلاه.

    يجب أن يتضمن تكوين WebView دعمًا لقاعدة بيانات HTML5 وذاكرة التخزين المؤقت للتطبيق وواجهات برمجة التطبيقات لتحديد الموقع الجغرافي [ الموارد، 9 ]. يجب أن يتضمن WebView دعمًا لعلامة HTML5 <video> بشكل ما. يجب أن يتضمن تطبيق المتصفح المستقل (سواء كان يعتمد على تطبيق WebKit Browser الرئيسي أو بديل لجهة خارجية) دعمًا لنفس ميزات HTML5 المدرجة للتو في WebView.

    3.5. التوافق السلوكي لواجهة برمجة التطبيقات (API)

    يجب أن تكون سلوكيات كل نوع من أنواع واجهة برمجة التطبيقات (المُدارة، واللينة، والمحلية، والويب) متوافقة مع التنفيذ المفضل لمشروع Android مفتوح المصدر [ الموارد، 3 ]. بعض مجالات التوافق المحددة هي:

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

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

    تقوم مجموعة اختبار التوافق (CTS) باختبار أجزاء كبيرة من النظام الأساسي للتأكد من التوافق السلوكي، ولكن ليس كلها. تقع على عاتق المُنفِّذ مسؤولية ضمان التوافق السلوكي مع مشروع Android مفتوح المصدر.

    3.6. API Namespaces

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

    • java.*
    • javax.*
    • sun.*
    • android.*
    • com.android.*

    تتضمن التعديلات المحظورة ما يلي:

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

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

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

    إذا اقترح أحد مُنفِّذي الجهاز تحسين إحدى مساحات أسماء الحزمة أعلاه (مثل إضافة وظائف جديدة مفيدة إلى واجهة برمجة تطبيقات موجودة، أو إضافة واجهة برمجة تطبيقات جديدة)، فيجب على المُنفِّذ زيارة source.android.com وبدء عملية المساهمة بالتغييرات و الكود، وفقا للمعلومات الموجودة على هذا الموقع.

    لاحظ أن القيود المذكورة أعلاه تتوافق مع الاصطلاحات القياسية لتسمية واجهات برمجة التطبيقات في لغة برمجة Java؛ ويهدف هذا القسم ببساطة إلى تعزيز تلك الاتفاقيات وجعلها ملزمة من خلال إدراجها في تعريف التوافق هذا.

    3.7.

    يجب أن تدعم تطبيقات الأجهزة

    المتوافقة مع الآلة الافتراضية

    مواصفات الرمز الثانوي الكامل لـ Dalvik Executable (DEX) ودلالات Dalvik Virtual Machine [ الموارد، 10 ].

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

    3.8. توافق واجهة المستخدم

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

    3.8.1.

    تحدد

    Widgets

    Android نوع المكون وواجهة برمجة التطبيقات (API) المقابلة ودورة الحياة التي تسمح للتطبيقات بكشف "AppWidget" للمستخدم النهائي [ الموارد، 11 ]. يتضمن الإصدار المرجعي لنظام Android مفتوح المصدر تطبيق Launcher يتضمن عناصر واجهة المستخدم التي تسمح للمستخدم بإضافة AppWidgets وعرضها وإزالتها من الشاشة الرئيسية.

    يجوز لمنفذي الأجهزة استبدال بديل للمشغل المرجعي (أي الشاشة الرئيسية). يجب أن تتضمن المشغلات البديلة دعمًا مدمجًا لـ AppWidgets، وتكشف عن عناصر واجهة المستخدم لإضافة AppWidgets وتكوينها وعرضها وإزالتها مباشرة داخل Launcher. قد تحذف المشغلات البديلة عناصر واجهة المستخدم هذه؛ ومع ذلك، إذا تم حذفها، فيجب على منفذ الجهاز توفير تطبيق منفصل يمكن الوصول إليه من Launcher والذي يسمح للمستخدمين بإضافة AppWidgets وتكوينها وعرضها وإزالتها.

    3.8.2.

    تتضمن

    إشعارات

    Android واجهات برمجة التطبيقات (APIs) التي تسمح للمطورين بإخطار المستخدمين بالأحداث البارزة [ الموارد، 12 ]. يجب على منفذي الأجهزة تقديم الدعم لكل فئة من الإشعارات المحددة على هذا النحو؛ على وجه التحديد: الأصوات والاهتزاز والضوء وشريط الحالة.

    بالإضافة إلى ذلك، يجب أن يعرض التنفيذ جميع الموارد (الأيقونات وملفات الصوت وما إلى ذلك) بشكل صحيح المنصوص عليها في واجهات برمجة التطبيقات [ الموارد، 13 ]، أو في دليل نمط أيقونة شريط الحالة [ الموارد، 14 ]. قد يوفر منفذو الأجهزة تجربة مستخدم بديلة للإشعارات عن تلك التي يوفرها تطبيق Android Open Source المرجعي؛ ومع ذلك، يجب أن تدعم أنظمة الإشعارات البديلة موارد الإشعارات الحالية، كما هو مذكور أعلاه.

    يتضمن

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

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

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

    3.8.4.

    يمكن لتطبيقات

    Toasts

    استخدام واجهة برمجة التطبيقات "Toast" (المحددة في [ الموارد، 16 ]) لعرض سلاسل قصيرة غير مشروطة للمستخدم النهائي، والتي تختفي بعد فترة زمنية قصيرة. يجب أن تعرض تطبيقات الأجهزة الخبز المحمص من التطبيقات إلى المستخدمين النهائيين بطريقة عالية الوضوح.

    3.8.5.

    يحدد

    Live Wallpapers

    Android نوع المكون وواجهة برمجة التطبيقات (API) المقابلة ودورة الحياة التي تسمح للتطبيقات بعرض واحدة أو أكثر من "الخلفيات الحية" للمستخدم النهائي [ الموارد، 17 ]. الخلفيات الحية هي رسوم متحركة أو أنماط أو صور مشابهة ذات إمكانيات إدخال محدودة يتم عرضها كخلفية خلف التطبيقات الأخرى.

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

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

    4. توافق البرامج المرجعية

    يجب على منفذي الأجهزة اختبار توافق التنفيذ باستخدام التطبيقات مفتوحة المصدر التالية:

    • الآلة الحاسبة (المضمنة في SDK)
    • Lunar Lander (المضمنة في SDK)
    • تطبيقات "Apps for Android" [ الموارد، 18 ].

    يجب أن يتم تشغيل كل تطبيق أعلاه وأن يتصرف بشكل صحيح عند التنفيذ، حتى يعتبر التنفيذ متوافقًا.

    بالإضافة إلى ذلك، يجب أن تختبر تطبيقات الجهاز كل عنصر قائمة (بما في ذلك جميع القوائم الفرعية) لكل من تطبيقات اختبار الدخان هذه:

    • ApiDemos (المضمنة في SDK)
    • ManualSmokeTests (المضمنة في CTS)

    يجب أن تعمل كل حالة اختبار في التطبيقات أعلاه بشكل صحيح على الجهاز تطبيق.

    5. توافق حزم التطبيقات،

    يجب أن تقوم تطبيقات الأجهزة بتثبيت وتشغيل ملفات Android ".apk" كما تم إنشاؤها بواسطة أداة "aapt" المضمنة في Android SDK الرسمي [ الموارد، 19 ].

    يجب ألا تقوم تطبيقات الأجهزة بتوسيع تنسيقات ‎.apk [ Resources, 20 ] أو Android Manifest [ Resources, 21 ] أو Dalvik bytecode [ Resources, 10 ] بطريقة تمنع تثبيت هذه الملفات وتشغيلها بشكل صحيح على الأجهزة المتوافقة الأخرى . يجب على منفذي الأجهزة استخدام التنفيذ المرجعي الأولي لـ Dalvik، ونظام إدارة الحزم الخاص بالتنفيذ المرجعي.

    6. توافق الوسائط المتعددة

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

    يرجى ملاحظة أنه لا Google ولا Open Handset Alliance يقدمان أي تأكيد بأن برامج الترميز هذه غير مرتبطة ببراءات اختراع تابعة لجهات خارجية. يُنصح أولئك الذين يعتزمون استخدام كود المصدر هذا في الأجهزة أو منتجات البرامج بأن تطبيقات هذا الكود، بما في ذلك البرامج مفتوحة المصدر أو البرامج التجريبية، قد تتطلب تراخيص براءة اختراع من أصحاب براءات الاختراع المعنيين.

    تفاصيل وحدة تشفير اسم محتوى معدلات
    الصوت
    ووحدة فك الترميز وتنسيق الملف/الحاوية
    AAC LC/LTP  X Mono/Stereo في أي مجموعة من معدلات البت القياسية التي تصل إلى 160 كيلوبت في الثانية ومعدلات أخذ العينات بين 8 إلى 48 كيلوهرتز 3GPP (.3gp) وMPEG-4 (.mp4، .m4a). لا يوجد دعم لـ AAC الخام (.aac)
    HE-AACv1 (AAC+)   X
    HE-AACv2 (AAC+ المحسّن)   X
    AMR-NB X X 4.75 إلى 12.2 كيلوبت في الثانية تم أخذ عينات منها عند 8 كيلو هرتز 3GPP (.3gp)
    AMR-WB  X 9 من 6.60 كيلوبت/ثانية إلى 23.85 كيلوبت/ثانية عند 16 كيلو هرتز 3GPP (.3gp)
    MP3   X أحادي/ستيريو 8-320 كيلوبت في الثانية ثابت (CBR) أو معدل بت متغير (VBR) MP3 (.mp3)
    MIDI   X MIDI النوع 0 و1. DLS الإصدار 1 و2. XMF وMobile XMF. دعم تنسيقات نغمات الرنين RTTTL/RTX وOTA وiMelody Type 0 و1 (.mid و.xmf و.mxmf). أيضا RTTTL/RTX (.rtttl ، .rtx) ، OTA (.OTA) ، و imelody (.IMY)
    OGG VORBIS   X   OGG (.ogg)
    PCM   X 8- و 16 بت PCM (معدلات أعلى إلى الحد من الأجهزة) موجة (.wav)
    صورة
    JPEG X X BASE+تقدمية  
    GIF   X   
    PNG x x   
    BMP   X   
    فيديو
    H.263 x x   ملفات 3GPP (.3GP)
    H.264   X   3GPP (.3gp) و MPEG-4 (.mp4) ملفات
    mpeg4 ملف تعريف بسيط   X   ملف 3GPP (.3GP)

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

    7. يجب أن تدعم تطبيقات توافق أداة المطورين

    أدوات مطور Android المتوفرة في Android SDK. على وجه التحديد ، يجب أن تكون الأجهزة المتوافقة مع Android متوافقة مع:

    • Android Debug Bridge (المعروف باسم ADB) [ الموارد ، 19 ]
      يجب أن تدعم تطبيقات الجهاز جميع وظائف adb كما هو موثق في Android SDK. يجب أن يكون الخفي من جانب الجهاز adb غير نشط بشكل افتراضي ، ولكن يجب أن تكون هناك آلية يمكن الوصول إليها من قبل المستخدم لتشغيل جسر Debug Android.
    • خدمة Dalvik Debug Monitor (المعروفة باسم DDMS) [ الموارد ، 19 ]
      يجب أن تدعم تطبيقات الجهاز جميع ميزات ddms كما هو موثق في Android SDK. مع استخدام ddms adb ، يجب أن يكون دعم ddms غير نشط افتراضيًا ، ولكن يجب دعمه كلما قام المستخدم بتنشيط جسر Debug Android ، على النحو الوارد أعلاه.
    • قرد [ الموارد ، 22 ]
      يجب أن تتضمن تطبيقات الأجهزة إطار Monkey ، وجعله متاحًا للتطبيقات لاستخدامها.

    8. توافق الأجهزة التي

    يهدف Android إلى دعم منفذي الأجهزة إنشاء عوامل وتكوينات نموذج مبتكرة. في الوقت نفسه ، يتوقع مطورو Android أجهزة وأجهزة استشعار وواجهة برمجة التطبيقات في جميع أجهزة Android. يسرد هذا القسم ميزات الأجهزة التي يجب أن تدعمها جميع أجهزة Android 2.1 المتوافقة.

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

    • تكون تعريفات الفئة لواجهة
    • برمجة التطبيقات للمكون موجودة.
    • يجب أن تُرجع أساليب API قيمًا فارغة حيث يجب أن تعيد طرق واجهة برمجة تطبيقات الوثائق SDK
    • إلى إرجاع تطبيقات عدم وجود فئات حيث لا يُسمح بالقيم الفارغة من خلال وثائق SDK

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

    يجب أن تقوم تطبيقات الجهاز بالإبلاغ الدقيق عن معلومات تكوين الأجهزة الدقيقة عبر طرق getSystemAvailableFeatures() و hasSystemFeature(String) على فصل android.content.pm.PackageManager .

    8.1.

    يشتمل

    Display

    Android 2.1 على التسهيلات التي تؤدي بعض عمليات التحجيم والتحول التلقائي في بعض الظروف ، لضمان أن تطبيقات الطرف الثالث تعمل بشكل جيد على مجموعة متنوعة من تكوينات الأجهزة [ الموارد ، 23 ]. يجب أن تنفذ الأجهزة هذه السلوكيات بشكل صحيح ، كما هو مفصل في هذا القسم.

    لنظام Android 2.1 ، هذه هي أكثر تكوينات العرض شيوعًا:

    عرض Low Low Low Normal
    نوع الشاشة (Pixels) ارتفاع (البكسل) نطاق الطول القطري (بوصة) مجموعة شاشة الشاشة مجموعة شاشة
    QVGA 240 320 2.6 - 3.0 Small Low
    WQVGA 240 400 3.2 - 3.5 NormalLow Low Normal
    FWQVGA 240 432 3.5 - 3.8
    NORMAL LOW HVGA 320 480 3.0
    - 3.5 متوسط ​​WVGA 480 800
    - 4.0 _ _ _ _
    _ _ _ _ _ _
    _ _ _ _ _ _

    _ يجب تكوين أحد التكوينات القياسية أعلاه للإبلاغ عن حجم الشاشة المشار إليه للتطبيقات عبر الفئة android.content.res.Configuration [ الموارد ، 24 ].

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

    • يجب أن تفسر تطبيقات الأجهزة الموارد في .APK تفتقر إلى مؤهل الكثافة على أنها "متوسطة" (المعروفة باسم "MDPI" في وثائق SDK.)
    • عند التشغيل على كثافة "منخفضة" الشاشة ، يجب أن تخفض تطبيقات الأجهزة أصول متوسطة/MDPI بعامل 0.75.
    • عند التشغيل على شاشة "عالية الكثافة عالية" ، يجب أن تزيد تطبيقات الأجهزة من الأصول المتوسطة/MDPI بعامل 1.5.
    • يجب ألا تقوم تطبيقات الأجهزة بتوسيع نطاق الأصول ضمن نطاق الكثافة ، ويجب أن تقوم بتوسيع نطاق الأصول بواسطة هذه العوامل بالضبط بين نطاقات الكثافة.

    8.1.2. تكوينات عرض العرض غير القياسي

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

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

    8.1.3.

    يجب أن android.util.DisplayMetrics تطبيقات

    Display Metrics

    بإبلاغ عن القيم الصحيحة لجميع مقاييس العرض المحددة في Android.Util.DisplayMetrics [الموارد ، 25].

    8.2.

    تطبيقات جهاز

    لوحة المفاتيح

    :

    • يجب أن تتضمن دعمًا لإطار إدارة الإدخال (الذي يسمح لمطوري الطرف الثالث بإنشاء محركات إدارة المدخلات - أي لوحة المفاتيح اللينة) كما هو مفصل في Developer.android.com
    • يجب أن يوفر تطبيق لوحة مفاتيح واحد على الأقل (بغض النظر عما إذا كان أ قد تتضمن لوحة المفاتيح الصلبة)
    • أن تتضمن تطبيقات لوحة المفاتيح اللينة الإضافية
    • قد تتضمن لوحة مفاتيح الأجهزة
    • لا يجب أن تتضمن لوحة مفاتيح الأجهزة التي لا تتطابق مع أحد التنسيقات المحددة في android.content.res.Configuration.keyboard [ الموارد ، 24 ] (وهذا هو ، QWERTY ، أو 12-مفتاح)

    8.3.

    تطبيقات أجهزة

    التنقل غير اللمسة

    :
    • قد تجنب خيارات التنقل غير الملمس (أي ، يجوز لها حذف كرة التتبع أو D-pad أو
    • android.content.res.Configuration.navigation ) ]

    8.4.

    يجب أن تدعم الأجهزة المتوافقة مع

    اتجاه الشاشة

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

    يجب أن تقوم الأجهزة بالإبلاغ عن القيمة الصحيحة للاتجاه الحالي للجهاز ، كلما تم الاستعلام عنها عبر Android.content.res.configuration.orientation ، Android.view.display.getorientation () ، أو واجهات برمجة التطبيقات الأخرى.

    8.5.

    تطبيقات أجهزة

    الإدخال التي تعمل باللمس

      :
    • يجب أن يكون لدى شاشة تعمل باللمس
    • إما شاشة تعمل باللمس أو مقاومة
    • يجب أن تقوم بالإبلاغ عن قيمة android.content.res.Configuration [ الموارد ، 24 ] والتي تعكس نوع الشاشة التي تعمل باللمس المحددة على الجهاز

    8.6.

    تطبيقات جهاز

    USB

      :
    • يجب تنفيذ عميل USB ، قابل للاتصال بمضيف USB مع منفذ USB-A قياسي
    • يجب أن ينفذ
    • جسر Debug Android على USB (كما هو موضح في القسم 7) ،
    • إلى الجهاز للوصول إلى محتويات وحدة التخزين /sdcard
    • يجب أن تستخدم عامل نموذج USB الصغير على جانب الجهاز
    • قد يتضمن منفذًا غير قياسي على جانب الجهاز ، ولكن إذا كان الأمر كذلك ، فيجب شحن كابل قادر على توصيل pinout المخصص بـ قياسي USB-A Port

    8.7. مفاتيح التنقل

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

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

    8.8.

    يجب أن تتضمن تطبيقات

    شبكات شبكات البيانات اللاسلكية

    دعمًا لشبكات البيانات اللاسلكية عالية السرعة. على وجه التحديد ، يجب أن تتضمن تطبيقات الأجهزة دعمًا لمعيار بيانات لاسلكي واحد على الأقل قادر على 200 كيلو بايت/ثانية أو أكثر. تتضمن أمثلة على التقنيات التي تلبي هذا الشرط Edge و HSPA أو EV-DO و 802.11g ، وما إلى ذلك

    . يجب أن يدعم التنفيذ واجهة برمجة التطبيقات.

    قد تنفذ الأجهزة أكثر من شكل واحد من أشكال اتصال البيانات اللاسلكية. يجوز للأجهزة تنفيذ اتصال البيانات السلكية (مثل Ethernet) ، ولكن يجب أن تتضمن مع ذلك شكل واحد على الأقل من أشكال الاتصال اللاسلكي ، على النحو الوارد أعلاه.

    8.9.

    يجب أن تتضمن تطبيقات جهاز

    الكاميرا

    كاميرا. الكاميرا المضمّنة:

    • يجب أن يكون لها دقة ما لا يقل عن 2 ميجابكسل
    • إما التركيز تلقائيًا للأجهزة ، أو
    • قد يكون للتكييف التلقائي للبرامج المنفذة في برنامج تشغيل الكاميرا (شفاف إلى برنامج التطبيق) تركيزًا ثابتًا أو EDOF (عمق الحقل الموسع)
      • قد تتضمن
    • الأجهزة
    • فلاش. إذا كانت الكاميرا تتضمن فلاشًا ، فلا يجب إضاءة مصباح الفلاش أثناء وجود جهاز Android.hardware.camera.previewCallback على سطح معاينة الكاميرا ، ما لم يمكّن التطبيق بشكل صريح الفلاش عن طريق تمكين سمات FLASH_MODE_AUTO أو FLASH_MODE_ON . Camera.Parameters parameters. لاحظ أن هذا القيد لا ينطبق على تطبيق كاميرا النظام المدمج في الجهاز ، ولكن فقط على تطبيقات الطرف الثالث باستخدام Camera.PreviewCallback .

    يجب أن تنفذ تطبيقات الجهاز السلوكيات التالية لواجهة برمجة التطبيقات المتعلقة بالكاميرا:

    1. إذا لم يطلق تطبيقًا على Android.hardware.camera.parameters.setpreviewformat (int) ، فيجب على الجهاز استخدام Android.hardware.pixelformat.ycbcr_420_sp لبيانات المعاينة المقدمة لبيانات المعاينة المقدمة لبيانات التظاهر المقدمة عوائد الطلبات.
    2. إذا قام أحد التطبيقات بتسجيل مثيل Android.hardware.camera.previewCallback ويقوم النظام باستدعاء طريقة OnPreviewFrame () عندما يكون تنسيق المعاينة YCBCR_420_SP ، يجب أن تكون البيانات الموجودة في البايت [] تم تمريرها إلى OnPreviewFrame () في شكل ترميز NV21. (هذا هو التنسيق الذي يستخدمه عائلة أجهزة 7K.) أي NV21 يجب أن يكون الافتراضي.

    يجب أن تنفذ تطبيقات الأجهزة واجهة برمجة تطبيقات الكاميرا الكاملة المضمنة في وثائق Android 2.1 SDK [ الموارد ، 26 ]) ، بغض النظر عما إذا كان الجهاز يتضمن ضبطًا تلقائيًا للأجهزة أو غيرها من القدرات.

    على سبيل المثال ، لا يزال يتعين على الكاميرات التي تفتقر إلى التركيز التلقائيات الاتصال بأي مثيلات مسجلة على Android.hardware.camera.autofocuscallback (على الرغم من أن هذا ليس له

    صلة

    android.hardware.Camera.AutoFocusCallback غير Autofocus.)

    android.hardware.Camera.Parameters فئة ، إذا كانت الأجهزة الأساسية تدعم الميزة. إذا لم يدعم أجهزة الجهاز ميزة ، فيجب أن تتصرف واجهة برمجة التطبيقات كما هو موثق. على العكس من ذلك ، يجب ألا تكريم تطبيقات الأجهزة أو التعرف على ثوابت السلسلة التي تم تمريرها إلى android.hardware.Camera.setParameters() غير تلك الموثقة على أنها ثوابت على android.hardware.Camera.Parameters ، ما لم يتم تسبق الثوابت مع سلسلة تشير إلى اسم تطبيق الجهاز. أي ، يجب أن تدعم تطبيقات الجهاز جميع معلمات الكاميرا القياسية إذا سمحت الجهاز ، ويجب ألا تدعم أنواع معلمات الكاميرا المخصصة ما لم يتم الإشارة إلى أسماء المعلمات بوضوح عبر بادئة السلسلة لتكون غير قياسية.

    8.10.

    يجب أن تتضمن تطبيقات جهاز

    التسارع

    مقياس تسارع 3 محاور ويجب أن تكون قادرة على تقديم الأحداث عند 50 هرتز أو أكبر. يجب أن يتوافق نظام الإحداثيات المستخدمة بواسطة مقياس التسارع مع نظام إحداثيات Android على النحو المفصل في واجهات برمجة التطبيقات Android (انظر [ الموارد ، 27 ]).

    8.11.

    يجب أن تتضمن تطبيقات أجهزة

    Compass

    بوصلة 3 محاور ويجب أن تكون قادرة على تقديم الأحداث 10 هرتز أو أكبر. يجب أن يتوافق نظام الإحداثيات المستخدمة من قبل البوصلة مع نظام الإحداثيات المستشعر Android على النحو المحدد في API Android (انظر [ الموارد ، 27 ]).

    8.12.

    يجب أن تتضمن تطبيقات أجهزة

    GPS

    GPS ، ويجب أن تتضمن شكلاً من أشكال تقنية "GPS المساعدة" لتقليل وقت قفل GPS.

    8.13.

    يمكن استخدام

    Telephony

    Android 2.1 على الأجهزة التي لا تتضمن الأجهزة الهاتفية. وهذا هو ، Android 2.1 متوافق مع الأجهزة التي ليست هواتف. ومع ذلك ، إذا كان تطبيق الجهاز يتضمن GSM أو CDMA Telephony ، فيجب عليه تنفيذ الدعم الكامل لواجهة برمجة التطبيقات لتلك التكنولوجيا. يجب أن تنفذ تطبيقات الأجهزة التي لا تتضمن أجهزة الاتصالات الهاتفية واجهات برمجة التطبيقات الكاملة على أنها لا توجد.

    انظر أيضًا القسم 8.8 ، شبكات البيانات اللاسلكية.

    8.14.

    يجب أن يكون لدى تطبيقات

    الذاكرة وأجهزة التخزين

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

    يجب أن يكون لدى تطبيقات الأجهزة ما لا يقل عن 150 ميغابايت من التخزين غير المتقلبة المتاحة لبيانات المستخدم. وهذا هو ، يجب أن يكون قسم /data 150 ميجابايت على الأقل.

    ملاحظة: تم تعديل هذا القسم بواسطة erratum ex6580.

    8.15.

    يجب أن توفر تطبيقات جهاز

    التخزين المشترك للتطبيق

    تخزينًا مشتركًا للتطبيقات. يجب أن يكون حجم التخزين المشترك المقدم على الأقل 2 جيجابايت.

    يجب تكوين تطبيقات الجهاز من خلال التخزين المشترك المثبت بشكل افتراضي ، "Out Of the Box". إذا لم يتم تركيب التخزين المشترك على مسار Linux /sdcard ، فيجب أن يتضمن الجهاز ارتباطًا رمزيًا Linux من /sdcard إلى نقطة التثبيت الفعلية.

    يجب أن تنفذ تطبيقات الجهاز على النحو الموثق للإذن android.permission.WRITE_EXTERNAL_STORAGE على هذا التخزين المشترك. يجب أن يكون التخزين المشترك قابلاً للكتابة بواسطة أي تطبيق يحصل على هذا الإذن.

    قد تحتوي تطبيقات الأجهزة على أجهزة للتخزين القابل للإزالة الذي يمكن الوصول إليه من قبل المستخدم ، مثل البطاقة الرقمية الآمنة. بدلاً من ذلك ، قد تخصص تطبيقات الأجهزة التخزين الداخلي (غير القابل للإزالة) كتخزين مشترك للتطبيقات.

    بغض النظر عن شكل التخزين المشترك المستخدم ، يجب أن تنفذ التخزين المشترك تخزين USB الكتلي ، كما هو موضح في القسم 8.6. كما يتم شحنها خارج الصندوق ، يجب تركيب التخزين المشترك مع نظام ملفات الدهون.

    من التوضيح النظر في مثالين شائعين. إذا كان تطبيق الجهاز يتضمن فتحة بطاقة SD لتلبية متطلبات التخزين المشتركة ، فيجب تضمين بطاقة SD التي يتم تنسيقها 2 جيجا بايت أو أكبر مع الجهاز كمستخدم للمستخدمين ، ويجب تثبيتها افتراضيًا. بدلاً من ذلك ، إذا كان تطبيق الجهاز يستخدم تخزينًا ثابتًا داخليًا لتلبية هذا المتطلبات ، فيجب أن يكون حجم التخزين 2 جيجابايت أو أكبر ومثبت على /sdcard (أو /sdcard يجب أن يكون رابطًا رمزيًا للموقع المادي إذا تم تركيبه في مكان آخر.)

    لاحظ : تمت إضافة هذا القسم بواسطة erratum ex6580.

    8.16.

    يجب أن تتضمن تطبيقات جهاز

    Bluetooth

    جهاز جهاز إرسال استقبال Bluetooth.

    يجب أن تتيح تطبيقات الأجهزة واجهة برمجة تطبيقات Bluetooth المستندة إلى RFCOMM كما هو موضح في وثائق SDK [ الموارد ، 29 ]. يجب أن تنفذ تطبيقات الأجهزة ملفات تعريف Bluetooth ذات الصلة ، مثل A2DP و AVRCP و OBEX وما إلى ذلك حسب الاقتضاء للجهاز.

    ملاحظة: تمت إضافة هذا القسم بواسطة Erratum ex6580.

    9. توافق الأداء

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

    ،
    تعليقات عتبة الأداء المتري
    يجب تشغيل التطبيقات التالية في الوقت المحدد.
    • المتصفح: أقل من 1300 مللي ثانية
    • MMS/SMS: أقل من 700 مللي ثانية
    • منبه: أقل من 650 مللي ثانية ،
    		 يتم قياس وقت الإطلاق كوقت إجمالي لإكمال النشاط الافتراضي للتطبيق ، بما في ذلك الوقت الذي يستغرقه لبدء عملية Linux ، وتحميل Android حزمة في Dalvik VM ، واتصل onCreate.
    التطبيقات المتزامنة عند إطلاق تطبيقات متعددة ، لإعادة إطلاق تطبيق التشغيل بالفعل بعد إطلاقه ، يجب أن يستغرق أقل من وقت الإطلاق الأصلي.  

    10. يجب أن تنفذ تطبيقات توافق نموذج نموذج الأمان

    نموذج أمان يتوافق مع نموذج أمان نظام Android على النحو المحدد في المستند المرجعي للأمان والأذونات في واجهات برمجة التطبيقات ، 28 ] في وثائق مطور Android. يجب أن تدعم تطبيقات الأجهزة تثبيت التطبيقات الموقعة ذاتيا دون الحاجة إلى أي أذونات/شهادات إضافية من أي أطراف/سلطات ثالثة. على وجه التحديد ، يجب أن تدعم الأجهزة المتوافقة آليات الأمان الموضحة في الأقسام الفرعية التالية.

    10.1.

    يجب أن تدعم تطبيقات أجهزة

    الأذونات

    نموذج أذونات Android على النحو المحدد في وثائق مطور Android [ Resources ، 28 ]. على وجه التحديد ، يجب أن تنفذ التطبيقات كل إذن محدد كما هو موضح في وثائق SDK ؛ لا يجوز حذف أذونات أو تغييرها أو تجاهلها. قد تضيف التطبيقات أذونات إضافية ، شريطة أن تكون سلاسل معرف الإذن الجديدة ليست في مساحة الاسم.* مساحة الاسم.

    10.2.

    يجب أن تدعم تطبيقات أجهزة

    عزل UID و Process

    نموذج صندوق الرمل Android ، حيث يتم تشغيل كل تطبيق باعتباره UID فريد من نوع UNIX وفي عملية منفصلة. يجب أن تدعم تطبيقات الجهاز تشغيل تطبيقات متعددة مثل معرف مستخدم Linux نفسه ، شريطة أن يتم توقيع التطبيقات وبناءها بشكل صحيح ، على النحو المحدد في مرجع الأمن والأذونات [ الموارد ، 28 ].

    10.3.

    يجب أن تدعم تطبيقات

    أذونات نظام الملفات

    نموذج أذونات الوصول إلى ملف Android على النحو المحدد في مرجع الأمان والأذونات [ الموارد ، 28 ].

    11. يجب أن تمر تطبيقات جهاز اختبار التوافق مع

    مجموعة اختبار توافق Android (CTS) [ الموارد ، 2 ] المتاحة من مشروع Android Open Source ، باستخدام برنامج الشحن النهائي على الجهاز. بالإضافة إلى ذلك ، يجب على منفذي الأجهزة استخدام التنفيذ المرجعي في شجرة Android مفتوح المصدر قدر الإمكان ، ويجب أن يضمن التوافق في حالات الغموض في CTS ولأي إعادة تنفيذ أجزاء من رمز المصدر المرجعي.

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

    12. يجب أن تتضمن تطبيقات جهاز البرمجيات القابلة للتحديث

    آلية لاستبدال برنامج النظام بالكامل. لا تحتاج الآلية إلى إجراء ترقيات "Live" - ​​أي قد تكون هناك حاجة إلى إعادة تشغيل الجهاز.

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

    • التنزيلات عبر الهواء (OTA) مع تحديث غير متصل عبر التحديثات
    • "المربوطة" على تحديثات USB من جهاز كمبيوتر مضيف
    • "غير متصل بالإنترنت" عبر إعادة تشغيل وتحديث من ملف ON التخزين القابل للإزالة

    يجب أن تدعم آلية التحديث المستخدمة التحديثات دون مسح بيانات المستخدم. لاحظ أن برنامج Android المنبع يتضمن آلية تحديث يفي بهذا المطلب.

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

    13. اتصل بنا

    يمكنك الاتصال بمؤلفي المستندات على compatibility@android.com للحصول على توضيحات ولإظهار أي مشكلات تعتقد أن المستند لا يغطيه.