הגדרת תאימות אנדרואיד 2.3

זכויות יוצרים © 2010, Google Inc. כל הזכויות שמורות.
compatibility@android.com

תוכן העניינים

1. הקדמה

מסמך זה מונה את הדרישות שיש לעמוד בהן כדי שטלפונים ניידים יהיו תואמים לאנדרואיד 2.3.

השימוש ב"חייב", "אסור", "נדרש", "יהיה", "לא", "צריך", "לא צריך", "מומלץ", "רשאי" ו"אופציונלי" הוא לפי תקן IETF מוגדר ב-RFC2119 [ משאבים, 1 ].

כפי שמשמש במסמך זה, "מיישם מכשירים" או "מיישם" הוא אדם או ארגון המפתחים פתרון חומרה/תוכנה המריץ אנדרואיד 2.3. "יישום מכשיר" או "יישום" הוא פתרון החומרה/תוכנה שפותח כך.

כדי להיחשב תואם ל-Android 2.3, יישומי מכשירים חייבים לעמוד בדרישות המוצגות בהגדרת תאימות זו, כולל כל מסמך המשולב באמצעות הפניה.

כאשר הגדרה זו או בדיקות התוכנה המתוארות בסעיף 10 הן שקטות, מעורפלות או לא שלמות, באחריות מיישם ההתקן להבטיח תאימות עם יישומים קיימים. מסיבה זו, פרויקט הקוד הפתוח של אנדרואיד [ משאבים, 3 ] הוא גם ההתייחסות וגם היישום המועדף של אנדרואיד. ממליצים מאוד על מיישמי מכשירים לבסס את ההטמעות שלהם במידה המרבית האפשרית על קוד המקור "במעלה הזרם" הזמין מפרויקט הקוד הפתוח של Android. בעוד שחלק מהרכיבים ניתנים להחלפה היפותטית ביישומים חלופיים תרגול זה מומלץ מאוד, שכן מעבר מבחני התוכנה יהפוך לקשה יותר באופן משמעותי. באחריות המיישם להבטיח תאימות התנהגותית מלאה ליישום הסטנדרטי של אנדרואיד, כולל ומעבר לחבילת בדיקת התאימות. לבסוף, שים לב שהחלפות ושינויים מסוימים של רכיבים אסורים במפורש במסמך זה.

שים לב שהגדרת תאימות זו מונפקת כדי להתאים לעדכון 2.3.3 לאנדרואיד, שהוא רמת API 10. הגדרה זו מיישנת ומחליפה את הגדרת התאימות עבור אנדרואיד 2.3 גרסאות לפני 2.3.3. (כלומר, גרסאות 2.3.1 ו-2.3.2 מיושנות.) מכשירים עתידיים תואמי אנדרואיד המריצים אנדרואיד 2.3 חייבים להישלח עם גרסה 2.3.3 ואילך.

2. משאבים

1. רמות הדרישה של IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
2. סקירה כללית של תוכנית התאימות ל-Android: http://source.android.com/docs/compatibility/index.html
3. פרויקט קוד פתוח של אנדרואיד: http://source.android.com/
4. הגדרות API ותיעוד: http://developer.android.com/reference/packages.html
5. הפניה להרשאות אנדרואיד: http://developer.android.com/reference/android/Manifest.permission.html
6. הפניה ל-android.os.Build: http://developer.android.com/reference/android/os/Build.html
7. מחרוזות גרסה מותרות של Android 2.3: http://source.android.com/docs/compatibility/2.3/versions.html
8. כיתת android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
10. יכולות HTML5 לא מקוונות: http://dev.w3.org/html5/spec/Overview.html#offline
11. תג וידאו HTML5: http://dev.w3.org/html5/spec/Overview.html#video
12. HTML5/W3C geolocation API: http://www.w3.org/TR/geolocation-API/
13. HTML5/W3C webdatabase API: http://www.w3.org/TR/webdatabase/
14. HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/
15. מפרט מכונה וירטואלית של Dalvik: זמין בקוד המקור של אנדרואיד, בכתובת dalvik/docs
16. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
17. התראות: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
18. משאבי יישומים: http://code.google.com/android/reference/available-resources.html
19. מדריך סגנון סמל שורת המצב: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
20. מנהל החיפוש: http://developer.android.com/reference/android/app/SearchManager.html
21. טוסטים: http://developer.android.com/reference/android/widget/Toast.html
22. רקעים חיים: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
23. תיעוד כלי עזר (עבור adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
24. תיאור קובץ ה-apk של Android: http://developer.android.com/guide/topics/fundamentals.html
25. קובצי מניפסט: http://developer.android.com/guide/topics/manifest/manifest-intro.html
26. כלי לבדיקת קופים: https://developer.android.com/studio/test/other-testing-tools/monkey
27. רשימת תכונות החומרה של אנדרואיד: http://developer.android.com/reference/android/content/pm/PackageManager.html
28. תמיכה במספר מסכים: http://developer.android.com/guide/practices/screens_support.html
29. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
30. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
31. מרחב קואורדינטות חיישן: http://developer.android.com/reference/android/hardware/SensorEvent.html
32. ממשק API של Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html
33. NDEF Push Protocol: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
34. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
35. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
36. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
37. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
38. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
39. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
40. API לכיוון מצלמה: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
41. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
42. הפניה לאבטחה והרשאות אנדרואיד: http://developer.android.com/guide/topics/security/security.html
43. אפליקציות לאנדרואיד: http://code.google.com/p/apps-for-android

רבים ממשאבים אלה נגזרים ישירות או בעקיפין מ-Android 2.3 SDK, ויהיו זהים מבחינה פונקציונלית למידע בתיעוד של SDK זה. בכל המקרים שבהם הגדרת התאימות הזו או חבילת בדיקת התאימות לא מסכימה עם תיעוד ה-SDK, תיעוד ה-SDK נחשב סמכותי. כל פרט טכני המסופק בהפניות הכלולות לעיל נחשב בהכללה כחלק מהגדרת תאימות זו.

3. תוכנה

פלטפורמת אנדרואיד כוללת סט של ממשקי API מנוהלים, סט של ממשקי API מקוריים וגוף של ממשקי API כביכול "רך" כגון מערכת Intent ו-API של אפליקציות אינטרנט. סעיף זה מפרט את ממשקי ה-API הקשיחים והרכים שהם חלק בלתי נפרד מהתאימות, כמו גם התנהגויות טכניות וממשק משתמש מסוימות רלוונטיות אחרות. יישומי מכשירים חייבים לעמוד בכל הדרישות בסעיף זה.

3.1. תאימות API מנוהלת

סביבת הביצוע המנוהלת (מבוססת דאלוויק) היא הכלי העיקרי עבור יישומי אנדרואיד. ממשק תכנות יישומי אנדרואיד (API) הוא קבוצת ממשקי פלטפורמת אנדרואיד החשופים ליישומים הפועלים בסביבת ה-VM המנוהלת. יישומי מכשיר חייבים לספק יישומים מלאים, כולל כל ההתנהגויות המתועדות, של כל API מתועד שנחשף על ידי Android 2.3 SDK [ משאבים, 4 ].

אין להטמיע במכשיר להשמיט כל ממשקי API מנוהלים, לשנות ממשקי API או חתימות, לסטות מההתנהגות המתועדת או לכלול פעולות ללא פעולות, למעט היכן שמותר במפורש בהגדרת תאימות זו.

הגדרת תאימות זו מאפשרת להשמיט סוגים מסוימים של חומרה שעבורן Android כולל ממשקי API להישמט על ידי יישומי מכשירים. במקרים כאלה, ממשקי ה-API עדיין חייבים להיות נוכחים ולהתנהג בצורה סבירה. ראה סעיף 7 לדרישות ספציפיות לתרחיש זה.

3.2. תאימות API רכה

בנוסף לממשקי ה-API המנוהלים מ-Section 3.1, אנדרואיד כולל גם API "רך" משמעותי לזמן ריצה בלבד, בצורה של דברים כגון Intents, Permissions והיבטים דומים של אפליקציות אנדרואיד שלא ניתן לאכוף בזמן הידור של אפליקציות. סעיף זה מפרט את ממשקי ה-API "הרכים" והתנהגויות המערכת הנדרשות להתאמה לאנדרואיד 2.3. יישומי מכשיר חייבים לעמוד בכל הדרישות המוצגות בסעיף זה.

3.2.1. הרשאות

מיישמי מכשירים חייבים לתמוך ולאכוף את כל קבועי ההרשאה כפי שמתועדים בדף ההפניה להרשאות [ משאבים, 5 ]. שים לב שסעיף 10 מפרט דרישות נוספות הקשורות למודל האבטחה של Android.

3.2.2. בניית פרמטרים

ממשקי ה-API של Android כוללים מספר קבועים במחלקה android.os.Build [ משאבים, 6 ] שנועדו לתאר את המכשיר הנוכחי. כדי לספק ערכים עקביים ומשמעותיים על פני יישומי מכשירים, הטבלה שלהלן כוללת הגבלות נוספות על הפורמטים של ערכים אלה שאליהם יישומי מכשירים חייבים להתאים.

3.2.3. תאימות כוונות

אנדרואיד משתמשת ב-Intents כדי להשיג אינטגרציה רופפת בין יישומים. סעיף זה מתאר דרישות הקשורות לדפוסי הכוונה שחייבים להיות מכובד על ידי יישומי מכשירים. ב"כבוד", הכוונה היא שמיישם המכשיר חייב לספק פעילות או שירות אנדרואיד המציינים מסנן Intent תואם ומתחבר ומיישם התנהגות נכונה עבור כל דפוס Intent שצוין.

3.2.3.1. כוונות יישום ליבה

פרויקט אנדרואיד במעלה הזרם מגדיר מספר יישומי ליבה, כגון חייגן טלפון, לוח שנה, ספר אנשי קשר, נגן מוזיקה וכן הלאה. מיישמי התקנים עשויים להחליף יישומים אלה בגרסאות חלופיות.

עם זאת, כל גרסה חלופית כזו חייבת לכבד את אותם דפוסי Intent שסופקו על ידי הפרויקט במעלה הזרם. לדוגמה, אם מכשיר מכיל נגן מוזיקה חלופי, הוא עדיין חייב לכבד את תבנית Intent שהונפקה על ידי יישומי צד שלישי כדי לבחור שיר.

היישומים הבאים נחשבים ליישומי ליבה של מערכת אנדרואיד:

• שעון שולחן
• דפדפן
• לוּחַ שָׁנָה
• מַחשְׁבוֹן
• אנשי קשר
• אימייל
• גלריה
• GlobalSearch
• מַשׁגֵר
• מוּסִיקָה
• הגדרות

יישומי הליבה של מערכת אנדרואיד כוללים רכיבי פעילות או שירות שונים הנחשבים "ציבוריים". כלומר, התכונה "android:exported" עשויה להיות נעדרת, או עשויה להיות בעלת הערך "true".

עבור כל פעילות או שירות המוגדרים באחת מיישומי הליבה של מערכת אנדרואיד, שאינם מסומנים כלא-ציבוריים באמצעות מאפיין android:exported עם הערך "false", הטמעות במכשיר חייבות לכלול רכיב מאותו סוג המטמיע את אותו מסנן Intent דפוסים כאפליקציית הליבה של מערכת אנדרואיד.

במילים אחרות, יישום מכשיר עשוי להחליף אפליקציות ליבה של מערכת אנדרואיד; עם זאת, אם כן, יישום המכשיר חייב לתמוך בכל דפוסי Intent שהוגדרו על ידי כל אפליקציית ליבה של מערכת אנדרואיד שמוחלפת.

3.2.3.2. עקיפות כוונות

מכיוון ש-Android היא פלטפורמה הניתנת להרחבה, מיישמים של מכשירים חייבים לאפשר לעקוף כל תבנית Intent המוזכרת בסעיף 3.2.3.1 על ידי יישומי צד שלישי. פרויקט הקוד הפתוח של אנדרואיד במעלה הזרם מאפשר זאת כברירת מחדל; אין ליישומי מכשירים לצרף הרשאות מיוחדות לשימוש של יישומי מערכת בדפוסי Intent אלה, או למנוע מיישומי צד שלישי להיקשר לתבניות אלה ולקבל שליטה עליהן. איסור זה כולל באופן ספציפי אך אינו מוגבל לנטרול ממשק המשתמש "בוחר" המאפשר למשתמש לבחור בין מספר יישומים שכולם מטפלים באותה דפוס Intent.

3.2.3.3. מרחבי שמות של כוונות

מיישמי מכשיר אינם חייבים לכלול כל רכיב אנדרואיד שמכבד כל דפוסי Intent או Broadcast Intent חדשים באמצעות ACTION, CATEGORY או מחרוזת מפתח אחרת במרחב השמות של Android.*. מיישמי מכשירים אינם חייבים לכלול רכיבי אנדרואיד המכבדים כל דפוסי Intent או Broadcast Intent באמצעות ACTION, CATEGORY או מחרוזת מפתח אחרת בחלל חבילה השייך לארגון אחר. מיישמי מכשירים אינם רשאים לשנות או להרחיב אף אחת מדפוסי הכוונות המשמשים את יישומי הליבה המפורטים בסעיף 3.2.3.1.

איסור זה מקביל לזה שצוין עבור שיעורי שפת Java בסעיף 3.6.

3.2.3.4. כוונות שידור

יישומי צד שלישי מסתמכים על הפלטפורמה כדי לשדר כוונות מסוימות כדי להודיע ​​להם על שינויים בסביבת החומרה או התוכנה. מכשירים תואמי אנדרואיד חייבים לשדר את כוונות השידור הציבוריות בתגובה לאירועי מערכת מתאימים. כוונות השידור מתוארות בתיעוד ה-SDK.

3.3. תאימות API מקורית

קוד מנוהל הפועל ב-Dalvik יכול להתקשר לקוד מקורי המסופק בקובץ .apk של האפליקציה כקובץ ELF .so הידור עבור ארכיטקטורת החומרה המתאימה של המכשיר. מכיוון שקוד מקורי תלוי מאוד בטכנולוגיית המעבד הבסיסית, אנדרואיד מגדירה מספר ממשקי יישומים בינאריים (ABIs) ב-Android NDK, בקובץ docs/CPU-ARCH-ABIS.txt . אם יישום מכשיר תואם ל-ABI מוגדר אחד או יותר, עליו ליישם תאימות ל-Android NDK, כמפורט להלן.

אם הטמעת מכשיר כוללת תמיכה ב-Android ABI, זה:

• חייב לכלול תמיכה בקוד הפועל בסביבה המנוהלת כדי להתקשר לקוד מקורי, תוך שימוש בסמנטיקה הסטנדרטית של Java Native Interface (JNI).
• חייב להיות תואם מקור (כלומר תואם כותרת) ותואם בינארי (עבור ABI) עם כל ספרייה נדרשת ברשימה למטה
• יש לדווח במדויק על ממשק היישומים הבינארי המקורי (ABI) הנתמך על ידי המכשיר, דרך ה-API של android.os.Build.CPU_ABI
• יש לדווח רק על אותם ABIs המתועדים בגרסה העדכנית ביותר של Android NDK, בקובץ docs/CPU-ARCH-ABIS.txt
• צריך להיבנות באמצעות קוד המקור וקובצי הכותרת הזמינים בפרויקט הקוד הפתוח של אנדרואיד במעלה הזרם

ממשקי ה-API של הקוד המקוריים הבאים חייבים להיות זמינים לאפליקציות הכוללות קוד מקורי:

• libc (ספריית C)
• libm (ספריית מתמטיקה)
• תמיכה מינימלית עבור C++
• ממשק JNI
• liblog (רישום אנדרואיד)
• libz (דחיסה של Zlib)
• libdl (מקשר דינמי)
• libGLESv1_CM.so (OpenGL ES 1.0)
• libGLESv2.so (OpenGL ES 2.0)
• libEGL.so (ניהול משטח מקורי של OpenGL)
• libjnigraphics.so
• libOpenSLES.so (תמיכה באודיו של ספריית סאונד פתוחה)
• libandroid.so (תמיכה בפעילות אנדרואיד מקורית)
• תמיכה ב-OpenGL, כמתואר להלן

שים לב כי מהדורות עתידיות של Android NDK עשויות להציג תמיכה עבור ABIs נוספים. אם יישום התקן אינו תואם ל-ABI מוגדר מראש, אסור לו לדווח על תמיכה בשום ABI כלל.

תאימות קוד מקורי היא מאתגרת. מסיבה זו, יש לחזור על כך שמיישמים מכשירים מעודדים מאוד להשתמש ביישומים במעלה הזרם של הספריות המפורטות לעיל כדי להבטיח תאימות.

3.4. תאימות אינטרנט

מפתחים ויישומים רבים מסתמכים על ההתנהגות של מחלקת android.webkit.WebView [ משאבים, 8 ] עבור ממשקי המשתמש שלהם, כך שהיישום של WebView חייב להיות תואם בכל יישומי Android. באופן דומה, דפדפן אינטרנט שלם ומודרני הוא מרכזי בחוויית המשתמש באנדרואיד. יישומי מכשיר חייבים לכלול גרסה של android.webkit.WebView התואמת את תוכנת אנדרואיד במעלה הזרם, וחייבים לכלול דפדפן מודרני עם יכולת HTML5, כמתואר להלן.

3.4.1. תאימות WebView

יישום הקוד הפתוח של Android משתמש במנוע העיבוד של WebKit כדי ליישם את android.webkit.WebView . מכיוון שלא ניתן לפתח חבילת בדיקה מקיפה עבור מערכת עיבוד אינטרנט, מיישמים של מכשירים חייבים להשתמש ב-build הספציפי במעלה הזרם של WebKit בהטמעת WebView. באופן ספציפי:

• יישומי android.webkit.WebView של יישומי מכשירים חייבים להיות מבוססים על בניית 533.1 WebKit מעץ הקוד הפתוח של Android במעלה הזרם עבור אנדרואיד 2.3. מבנה זה כולל סט ספציפי של פונקציונליות ותיקוני אבטחה עבור ה-WebView. מיישמי מכשירים עשויים לכלול התאמות אישיות למימוש WebKit; עם זאת, כל התאמות אישיות כאלה לא חייבות לשנות את התנהגות ה-WebView, כולל התנהגות עיבוד.
• מחרוזת סוכן המשתמש שדווחה על ידי WebView חייבת להיות בפורמט הזה:
  Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
  • הערך של המחרוזת $(VERSION) חייב להיות זהה לערך עבור android.os.Build.VERSION.RELEASE
  • הערך של המחרוזת $(LOCALE) צריך לעקוב אחר מוסכמות ISO עבור קוד מדינה ושפה, וצריך להתייחס למקום המוגדר הנוכחי של המכשיר
  • הערך של המחרוזת $(MODEL) חייב להיות זהה לערך עבור android.os.Build.MODEL
  • הערך של המחרוזת $(BUILD) חייב להיות זהה לערך עבור android.os.Build.ID

רכיב ה-WebView צריך לכלול תמיכה בכמה שיותר HTML5 [ משאבים, 9 ]. לכל הפחות, יישומי מכשירים חייבים לתמוך בכל אחד מממשקי ה-API האלה המשויכים ל-HTML5 ב-WebView:

• מטמון יישומים/פעולה לא מקוונת [ משאבים, 10 ]
• התג <video> [ משאבים, 11 ]
• מיקום גיאוגרפי [ משאבים, 12 ]

בנוסף, יישומי מכשירים חייבים לתמוך ב-HTML5/W3C webstorage API [ Resources, 13 ], וצריך לתמוך ב-HTML5/W3C IndexedDB API [ Resources, 14 ]. שימו לב שכאשר גופי הסטנדרטים לפיתוח אתרים עוברים להעדיף את IndexedDB על פני אחסון אתרים, IndexedDB צפוי להפוך לרכיב נדרש בגרסה עתידית של אנדרואיד.

ממשקי API של HTML5, כמו כל ממשקי API של JavaScript, חייבים להיות מושבתים כברירת מחדל ב-WebView, אלא אם המפתח מאפשר אותם במפורש באמצעות ממשקי API הרגילים של אנדרואיד.

3.4.2. תאימות דפדפן

יישומי מכשיר חייבים לכלול יישום דפדפן עצמאי לגלישה כללית באינטרנט של משתמשים. הדפדפן העצמאי עשוי להיות מבוסס על טכנולוגיית דפדפן שאינה WebKit. עם זאת, גם אם נעשה שימוש ביישום דפדפן חלופי, רכיב android.webkit.WebView המסופק ליישומי צד שלישי חייב להיות מבוסס על WebKit, כמתואר בסעיף 3.4.1.

יישום עשוי לשלוח מחרוזת סוכן משתמש מותאמת אישית ביישום הדפדפן העצמאי.

אפליקציית הדפדפן העצמאית (בין אם מבוססת על אפליקציית דפדפן WebKit במעלה הזרם או תחליף של צד שלישי) צריכה לכלול תמיכה בכמה שיותר HTML5 [ משאבים, 9 ]. לכל הפחות, יישומי מכשירים חייבים לתמוך בכל אחד מממשקי ה-API האלה המשויכים ל-HTML5:

• מטמון יישומים/פעולה לא מקוונת [ משאבים, 10 ]
• התג <video> [ משאבים, 11 ]
• מיקום גיאוגרפי [ משאבים, 12 ]

בנוסף, יישומי מכשירים חייבים לתמוך ב-HTML5/W3C webstorage API [ Resources, 13 ], וצריך לתמוך ב-HTML5/W3C IndexedDB API [ Resources, 14 ]. שימו לב שכאשר גופי הסטנדרטים לפיתוח אתרים עוברים להעדיף את IndexedDB על פני אחסון אתרים, IndexedDB צפוי להפוך לרכיב נדרש בגרסה עתידית של אנדרואיד.

3.5. תאימות התנהגותית של API

ההתנהגויות של כל אחד מסוגי ה-API (מנוהלים, רכים, מקוריים ואינטרנט) חייבות להיות עקביות עם היישום המועדף של פרויקט הקוד הפתוח של אנדרואיד במעלה הזרם [ משאבים, 3 ]. כמה תחומים ספציפיים של תאימות הם:

• אסור להתקנים לשנות את ההתנהגות או הסמנטיקה של כוונה סטנדרטית
• אסור למכשירים לשנות את מחזור החיים או סמנטיקה של מחזור החיים של סוג מסוים של רכיבי מערכת (כגון שירות, פעילות, ספק תוכן וכו')
• אסור למכשירים לשנות את הסמנטיקה של הרשאה סטנדרטית

הרשימה לעיל אינה מקיפה. Suite Test Compatibility (CTS) בודק חלקים משמעותיים מהפלטפורמה להתאמה התנהגותית, אך לא את כולם. באחריות המיישם להבטיח תאימות התנהגותית לפרויקט הקוד הפתוח של אנדרואיד. מסיבה זו, מיישמי מכשירים צריכים להשתמש בקוד המקור הזמין דרך פרויקט הקוד הפתוח של Android במידת האפשר, במקום להטמיע מחדש חלקים משמעותיים מהמערכת.

3.6. מרחבי שמות של API

אנדרואיד פועלת בהתאם למוסכמות מרחב השמות של החבילה והכיתה שהוגדרה על ידי שפת התכנות Java. כדי להבטיח תאימות עם יישומי צד שלישי, מיישמי מכשירים אינם חייבים לבצע שינויים אסורים (ראה להלן) במרחבי השמות של החבילות האלה:

• java.*
• javax.*
• שמש.*
• דְמוּי אָדָם.*
• com.android.*

שינויים אסורים כוללים:

• אין להטמיע מכשיר לשנות את ממשקי ה-API החשופים לציבור בפלטפורמת אנדרואיד על ידי שינוי כל שיטה או חתימות מחלקות, או על ידי הסרת מחלקות או שדות מחלקות.
• מיישמי מכשירים עשויים לשנות את היישום הבסיסי של ממשקי ה-API, אך אסור ששינויים כאלה ישפיעו על ההתנהגות המוצהרת ועל חתימת שפת ה-Java של ממשקי API שנחשפו לציבור.
• למיישמים של מכשירים אסור להוסיף אלמנטים שנחשפו לציבור (כגון מחלקות או ממשקים, או שדות או שיטות למחלקות או ממשקים קיימים) לממשקי ה-API שלמעלה.

"אלמנט חשוף לציבור" הוא כל מבנה שאינו מעוטר בסמן "@hide" כפי שנעשה בו שימוש בקוד המקור של Android במעלה הזרם. במילים אחרות, מיישמי מכשירים אינם חייבים לחשוף ממשקי API חדשים או לשנות ממשקי API קיימים במרחבי השמות שצוינו לעיל. מיישמי מכשירים עשויים לבצע שינויים פנימיים בלבד, אך אסור לפרסם שינויים אלה או להיחשף בדרך אחרת למפתחים.

מיישמי מכשירים עשויים להוסיף ממשקי API מותאמים אישית, אך אסור שכל ממשקי API כאלה יהיו במרחב שמות בבעלות ארגון אחר או מתייחס אליו. לדוגמה, מיישמי מכשירים אינם חייבים להוסיף ממשקי API למרחב השמות com.google.* או דומה; רק Google רשאית לעשות זאת. באופן דומה, אסור לגוגל להוסיף ממשקי API למרחבי השמות של חברות אחרות. בנוסף, אם הטמעת מכשיר כוללת ממשקי API מותאמים אישית מחוץ למרחב השמות הסטנדרטי של אנדרואיד, ממשקי API אלה חייבים להיות ארוזים בספרייה משותפת של אנדרואיד כך שרק אפליקציות שמשתמשות בהן במפורש (באמצעות מנגנון <uses-library> ) יושפעו מהשימוש המוגבר בזיכרון של ממשקי API כאלה.

אם מיישם מכשיר מציע לשפר את אחד ממרחבי השמות של החבילות לעיל (כגון על ידי הוספת פונקציונליות חדשה ושימושית לממשק API קיים, או הוספת ממשק API חדש), המיישם צריך לבקר בsource.android.com ולהתחיל בתהליך לתרומה של שינויים ו קוד, לפי המידע באתר זה.

שימו לב שההגבלות לעיל תואמות למוסכמות הסטנדרטיות למתן שמות לממשקי API בשפת התכנות Java; סעיף זה פשוט נועד לחזק את המוסכמות הללו ולהפוך אותן למחייבות באמצעות הכללה בהגדרת תאימות זו.

3.7. תאימות למכונות וירטואליות

יישומי מכשיר חייבים לתמוך במפרט ה-Bytecode המלא של Dalvik Executable (DEX) ובסמנטיקה של Dalvik Virtual Machine [ Resources, 15 ].

יישומי מכשיר עם מסכים מסווגים בצפיפות בינונית או נמוכה חייבים להגדיר את Dalvik להקצות לפחות 16MB של זיכרון לכל יישום. יישומי מכשיר עם מסכים מסווגים בצפיפות גבוהה או בצפיפות גבוהה במיוחד חייבים להגדיר את Dalvik להקצות לפחות 24MB של זיכרון לכל יישום. שים לב שיישומי מכשירים עשויים להקצות יותר זיכרון מהנתונים האלה.

3.8. תאימות ממשק משתמש

פלטפורמת אנדרואיד כוללת כמה ממשקי API למפתחים המאפשרים למפתחים להתחבר לממשק המשתמש של המערכת. יישומי מכשירים חייבים לשלב ממשקי משתמש UI סטנדרטיים אלה בממשקי משתמש מותאמים אישית שהם מפתחים, כפי שמוסבר להלן.

3.8.1. ווידג'טים

אנדרואיד מגדירה סוג רכיב ו-API ומחזור חיים תואמים המאפשרים ליישומים לחשוף "AppWidget" למשתמש הקצה [ Resources, 16 ]. מהדורת ההפניה של Android Open Source כוללת יישום Launcher הכולל רכיבי ממשק משתמש המאפשרים למשתמש להוסיף, להציג ולהסיר AppWidgets ממסך הבית.

מיישמי התקנים עשויים להחליף חלופה ל-Reference Launcher (כלומר מסך הבית). משגרים אלטרנטיביים צריכים לכלול תמיכה מובנית ב-AppWidgets, ולחשוף רכיבי ממשק משתמש כדי להוסיף, להגדיר, להציג ולהסיר AppWidgets ישירות בתוך ה-Launcher. משגרים אלטרנטיביים עשויים להשמיט את רכיבי ממשק המשתמש הללו; עם זאת, אם הם מושמטים, מיישם המכשיר חייב לספק אפליקציה נפרדת הנגישה מה-Launcher המאפשרת למשתמשים להוסיף, להגדיר, להציג ולהסיר AppWidgets.

3.8.2. התראות

אנדרואיד כולל ממשקי API המאפשרים למפתחים להודיע ​​למשתמשים על אירועים בולטים [ משאבים, 17 ]. מיישמי התקנים חייבים לספק תמיכה עבור כל סוג הודעה שהוגדר כך; במיוחד: צלילים, רטט, אור ושורת מצב.

בנוסף, ההטמעה חייבת להציג כהלכה את כל המשאבים (סמלים, קבצי קול וכו') הניתנים בממשקי ה-API [ משאבים, 18 ], או במדריך הסגנון של סמל שורת המצב [ משאבים, 19 ]. מיישמי מכשירים עשויים לספק חווית משתמש חלופית להודעות מזו שמסופקת על ידי יישום הקוד הפתוח של Android; עם זאת, מערכות הודעות חלופיות כאלה חייבות לתמוך במשאבי הודעות קיימים, כאמור לעיל.

3.8.3. לחפש

אנדרואיד כולל ממשקי API [ משאבים, 20 ] המאפשרים למפתחים לשלב חיפוש באפליקציות שלהם, ולחשוף את נתוני האפליקציה שלהם בחיפוש המערכת הגלובלי. באופן כללי, פונקציונליות זו מורכבת מממשק משתמש יחיד, כלל-מערכתי, המאפשר למשתמשים להזין שאילתות, מציג הצעות תוך כדי הקלדת המשתמשים ומציג תוצאות. ממשקי ה-API של אנדרואיד מאפשרים למפתחים לעשות שימוש חוזר בממשק זה כדי לספק חיפוש בתוך האפליקציות שלהם, ומאפשרים למפתחים לספק תוצאות לממשק המשתמש של החיפוש הגלובלי הנפוץ.

יישומי מכשיר חייבים לכלול ממשק משתמש חיפוש יחיד, משותף, מערכת רחב המסוגל להציע הצעות בזמן אמת בתגובה לקלט המשתמש. יישומי מכשירים חייבים ליישם את ממשקי ה-API המאפשרים למפתחים לעשות שימוש חוזר בממשק משתמש זה כדי לספק חיפוש בתוך האפליקציות שלהם. יישומי מכשירים חייבים ליישם את ממשקי ה-API המאפשרים ליישומי צד שלישי להוסיף הצעות לתיבת החיפוש כאשר היא מופעלת במצב חיפוש גלובלי. אם לא מותקנים יישומי צד שלישי שעושים שימוש בפונקציונליות זו, התנהגות ברירת המחדל צריכה להיות הצגת תוצאות והצעות של מנוע החיפוש באינטרנט.

יישומי מכשירים עשויים לשלוח ממשקי משתמש חלופיים בחיפוש, אך עליהם לכלול כפתור חיפוש ייעודי קשה או רך, שניתן להשתמש בו בכל עת בתוך כל אפליקציה כדי להפעיל את מסגרת החיפוש, כאשר ההתנהגות הניתנת בתיעוד ה- API.

3.8.4. טוסטים

יישומים יכולים להשתמש בממשק ה- API "טוסט" (מוגדר ב- [ משאבים, 21 ]) כדי להציג מיתרים קצרים שאינם מודלים למשתמש הקצה, שנעלמים לאחר פרק זמן קצר. יישומי מכשירים חייבים להציג טוסטים מיישומים למשתמשי קצה באופן כלשהו בעל ראות גבוהה.

3.8.5. רקעים חיים

אנדרואיד מגדיר סוג רכיב וממשק API ומחזור חיים תואמים המאפשרים ליישומים לחשוף "טפטים חיים" אחד או יותר למשתמש הקצה [ משאבים, 22 ]. טפטים חיים הם אנימציות, דפוסים או תמונות דומות עם יכולות קלט מוגבלות המציגות כטפט, מאחורי יישומים אחרים.

חומרה נחשבת מסוגלת להפעיל טפטים חיים באופן אמין אם היא יכולה להריץ את כל הטפטים החיים, ללא מגבלות על הפונקציונליות, במסגרת סבירה ללא השפעות לרעה על יישומים אחרים. אם מגבלות בחומרה גורמות לטפטים ו/או יישומים להתרסק, תקלה, צורכים מעבד מוגזם או כוח סוללה, או הפעל בשיעורי מסגרת נמוכים באופן בלתי מתקבל על הדעת, החומרה אינה מסוגלת להריץ טפטים בשידור חי. כדוגמה, חלק מהטפטים החיים עשויים להשתמש בהקשר של GL 1.0 או 2.0 פתוח כדי להפוך את התוכן שלהם. טפט חי לא יפעל באופן אמין על חומרה שאינה תומכת בהקשרים מרובים של OpenGL מכיוון שהשימוש בטפטים חי בהקשר של OpenGL עשוי להתנגש עם יישומים אחרים המשתמשים גם בהקשר של OpenGL.

יישומי מכשירים המסוגלים להפעיל טפטים חיים באופן אמין כמתואר לעיל, אמורים ליישם טפטים חיים. יישומי מכשירים נחושים לא להפעיל טפטים חיים באופן אמין כמתואר לעיל אסור ליישם טפטים חיים.

4. תאימות אריזת יישומים

על יישומי מכשירים להתקין ולהפעיל קבצי "Android" .APK כפי שנוצר על ידי הכלי "AAPT" הכלול ב- Android SDK הרשמי [ משאבים, 23 ].

יישומי מכשירים אסור להרחיב את ה- .APK [ משאבים, 24 ], אנדרואיד ביטוי [ משאבים, 25 ], או דאלוויק בייטודוד [ משאבים, 15 ] בצורה כזו שתמנע מהתקנת קבצים אלה ולהפעיל נכון במכשירים תואמים אחרים . על יישומי מכשירים להשתמש ביישום ההתייחסות במעלה הזרם של דלוויק ובמערכת ניהול החבילות של יישום ההתייחסות.

5. תאימות מולטימדיה

יישומי מכשירים חייבים ליישם באופן מלא את כל ממשקי ה- API של המולטימדיה. על יישומי מכשירים לכלול תמיכה בכל קודקי המולטימדיה המתוארים להלן, ועליהם לעמוד בהנחיות עיבוד הקול המתוארות להלן. יישומי מכשירים חייבים לכלול לפחות צורה אחת של פלט שמע, כגון רמקולים, שקע אוזניות, חיבור רמקול חיצוני וכו '.

5.1. קודקים של מדיה

יישומי מכשירים חייבים לתמוך בקודקי המולטימדיה כמפורט בסעיפים הבאים. כל קודקים אלה ניתנים כישורי תוכנה ביישום אנדרואיד המועדף מפרויקט הקוד הפתוח של אנדרואיד.

שימו לב כי לא גוגל ולא ברית המכשירים הפתוחים הופכים כל ייצוג שהקודקים הללו אינם פועלים על ידי פטנטים של צד שלישי. מי שמתכוון להשתמש בקוד מקור זה במוצרי חומרה או תוכנה מומלץ כי יישום קוד זה, כולל בתוכנת קוד פתוח או Shareware, עשוי לדרוש רישיונות פטנטים מבעלי הפטנטים הרלוונטיים.

הטבלאות שלהלן אינן מפרטות דרישות שיעור סיביות ספציפיות עבור מרבית קודקי הווידיאו. הסיבה לכך היא שבפועל, חומרת המכשירים הנוכחית אינה בהכרח תומכת בעלות סיביות הממפות בדיוק למעטורות הנדרשות שצוינו על ידי הסטנדרטים הרלוונטיים. במקום זאת, יישומי מכשירים צריכים לתמוך במעשי הקצב הגבוה ביותר בחומרה, עד למגבלות שהוגדרו על ידי המפרט.

5.1.1. מפענחי מדיה

על יישומי מכשירים לכלול יישום של מפענח עבור כל קודקוד ופורמט המתואר בטבלה שלהלן. שימו לב כי מפענחים לכל אחד מסוגי המדיה הללו ניתנים על ידי פרויקט הקוד הפתוח של אנדרואיד במעלה הזרם.

5.1.2. מקודדי מדיה

יישומי מכשירים צריכים לכלול מקודדים עבור רבים מהפורמטים המדיה המפורטים בסעיף 5.1.1. ככל האפשר. עם זאת, מקודדים מסוימים אינם הגיוניים למכשירים חסרי חומרה אופציונלית מסוימת; לדוגמה, מקודד לסרטון H.263 אינו הגיוני, אם המכשיר חסר מצלמות כלשהן. יישומי מכשירים חייבים אפוא ליישם מקודדי מדיה בהתאם לתנאים המתוארים בטבלה שלהלן.

עיין בסעיף 7 לפרטים על התנאים שבהם ניתן להשמיט חומרה על ידי יישומי מכשירים.

בנוסף למקודדים המפורטים לעיל, יישומי המכשירים צריכים לכלול מקודד H.264. שים לב כי הגדרת התאימות לגרסה עתידית מתוכננת לשנות דרישה זו ל"חובה ". כלומר, קידוד H.264 הוא אופציונלי באנדרואיד 2.3 אך יידרש על ידי גרסה עתידית. מכשירים קיימים וחדשים המריצים את אנדרואיד 2.3 מעודדים מאוד לעמוד בדרישה זו באנדרואיד 2.3 , או שהם לא יוכלו להשיג תאימות אנדרואיד כאשר ישודרגו לגירסת העתיד.

5.2. הקלטת שמע

כאשר יישום השתמש ב- android.media.AudioRecord ממשק API כדי להתחיל להקליט זרם שמע, יישומי מכשירים צריכים לדגום ולהקליט שמע עם כל אחת מההתנהגויות הללו:

• יש להשבית עיבוד הפחתת רעש, אם קיים,.
• בקרת רווח אוטומטית, אם קיימת, צריכה להיות מושבתת.
• המכשיר אמור להציג בערך משרעת שטוחה לעומת מאפייני תדר; באופן ספציפי, ± 3 dB, מ- 100 הרץ ל- 4000 הרץ
• יש להגדיר רגישות לקלט שמע כך שמקור רמת הספק של 90 dB (SPL) במהירות של 1000 הרץ מניב RMS של 5000 לדגימות של 16 סיביות.
• רמות משרעת PCM צריכות לעקוב באופן לינארי לעקוב אחר שינויים ב- SPL קלט על פני טווח של 30 dB לפחות בין -18 dB ל- +12 dB Re 90 dB SPL במיקרופון.
• העיוות ההרמוני הכולל צריך להיות פחות מ- 1% מ- 100 הרץ ל- 4000 הרץ ברמת קלט של 90 dB SPL.

הערה: בעוד שהדרישות המפורטות לעיל מצוינות כ"אמור "עבור אנדרואיד 2.3, הגדרת התאימות לגרסה עתידית מתוכננת לשנות את אלה ל"חובה". כלומר, דרישות אלה הן אופציונליות באנדרואיד 2.3 אך יידרשו על ידי גרסה עתידית. מכשירים קיימים וחדשים המריצים אנדרואיד 2.3 מעודדים מאוד את הדרישות הללו באנדרואיד 2.3 , או שהם לא יוכלו להשיג תאימות אנדרואיד בעת שדרוג לגירסת העתיד.

5.3. השהיית אודיו

חביון שמע מוגדר באופן נרחב כמרווח שבין יישום מבקש הפעלת שמע או פעולת רשומות, וכאשר יישום המכשיר מתחיל בפועל את הפעולה. סוגים רבים של יישומים מסתמכים על חביון קצר, כדי להשיג אפקטים בזמן אמת אפקטים קוליים כאלה או תקשורת VoIP. יישומי מכשירים הכוללים חומרת מיקרופון ומכריזים android.hardware.microphone . עיין בסעיף 7 לפרטים על התנאים שבהם ניתן להשמיט חומרת מיקרופון על ידי יישומי מכשירים.

לעניין סעיף זה:

• "חביון פלט קר" מוגדר כמרווח בין כאשר אפליקציה מבקשת השמעת שמע וכאשר הצליל מתחיל לנגן, כאשר מערכת השמע הייתה סרק ונופלת לפני הבקשה
• "חביון פלט חם" מוגדר כמרווח שבין היישום מבקש הפעלת שמע לבין כאשר הצליל מתחיל לנגן, כאשר מערכת השמע נעשה שימוש לאחרונה אך כרגע סרק (כלומר שקט)
• "חביון פלט רציף" מוגדר כמרווח שבין כאשר יישום מוציא מדגם שיש לנגן וכאשר הרמקול מנגן פיזית את הצליל המתאים, בעוד שהמכשיר מנגן כרגע בשמע
• "חביון קלט קר" מוגדר כמרווח שבין היישום מבקש הקלטת שמע ומתי הדגימה הראשונה מועברת ליישום באמצעות התקשרותו, כאשר מערכת השמע והמיקרופון היו סרק ונופלים לפני הבקשה
• "חביון קלט רציף" מוגדר כאשר הוא מתרחש צליל אווירה וכאשר המדגם המתאים לצליל זה מועבר ליישום הקלטה באמצעות התקשרותו, בעוד שהמכשיר נמצא במצב הקלטה

באמצעות ההגדרות לעיל, יישומי המכשירים צריכים להציג כל אחד מהמאפיינים הללו:

• חביון תפוקה קר של 100 אלפיות השנייה או פחות
• חביון פלט חם של 10 אלפיות השנייה או פחות
• חביון פלט רציף של 45 אלפיות השנייה או פחות
• חביון קלט קר של 100 אלפיות השנייה או פחות
• חביון קלט רציף של 50 אלפיות השנייה או פחות

הערה: בעוד שהדרישות המפורטות לעיל מצוינות כ"אמור "עבור אנדרואיד 2.3, הגדרת התאימות לגרסה עתידית מתוכננת לשנות את אלה ל"חובה". כלומר, דרישות אלה הן אופציונליות באנדרואיד 2.3 אך יידרשו על ידי גרסה עתידית. מכשירים קיימים וחדשים המריצים אנדרואיד 2.3 מעודדים מאוד את הדרישות הללו באנדרואיד 2.3 , או שהם לא יוכלו להשיג תאימות אנדרואיד בעת שדרוג לגירסת העתיד.

אם יישום מכשירים עומד בדרישות של סעיף זה, הוא עשוי לדווח על תמיכה באודיו לאחצן נמוך, על ידי דיווח על התכונה "Android.hardware.audio.low-latency" באמצעות כיתת android.content.pm.PackageManager . [ משאבים, 27 ] לעומת זאת, אם יישום המכשיר אינו עומד בדרישות אלה אסור לדווח על תמיכה באודיו באגודה נמוכה.

6. תאימות כלי המפתחים

יישומי מכשירים חייבים לתמוך בכלי המפתחים של אנדרואיד המסופקים ב- Android SDK. באופן ספציפי, מכשירים תואמים אנדרואיד חייבים להיות תואמים ל:

• Bridge Debug Debug (המכונה ADB) [ משאבים, 23 ]
  יישומי מכשירים חייבים לתמוך בכל פונקציות adb כפי שתועדו ב- Android SDK. דמון adb בצד המכשיר צריך להיות לא פעיל כברירת מחדל, אך חייב להיות מנגנון נגיש למשתמש כדי להפעיל את גשר ה- Debug Android.
• שירות צג Dalvik Debug Monitor (המכונה DDMS) [ משאבים, 23 ]
  יישומי מכשירים חייבים לתמוך בכל תכונות ddms כפי שתועדו ב- Android SDK. מכיוון ש- ddms משתמש adb , התמיכה ב- ddms צריכה להיות לא פעילה כברירת מחדל, אך יש לתמוך בה בכל פעם שהמשתמש הפעיל את גשר Debug Android, כנ"ל.
• קוף [ משאבים, 26 ]
  יישומי המכשירים חייבים לכלול את מסגרת הקופים, ולהפוך אותה לזמינה ליישומים לשימוש.

רוב המערכות מבוססות לינוקס ומערכות Apple Macintosh מזהות מכשירי אנדרואיד באמצעות כלי SDK הסטנדרטיים של אנדרואיד, ללא תמיכה נוספת; עם זאת מערכות Windows של Microsoft בדרך כלל דורשות מנהל התקן למכשירי אנדרואיד חדשים. (לדוגמה, מזהי ספקים חדשים ולעיתים מזהי התקנים חדשים דורשים מנהלי התקנים USB מותאמים אישית למערכות Windows.) אם יישום מכשירים אינו מזוהה על ידי כלי adb כמפורט באנדרואיד SDK הסטנדרטי, על יישומי המכשירים לספק למנהלי Windows המאפשרים למפתחים להתחבר ל המכשיר באמצעות פרוטוקול adb . יש לספק מנהלי התקנים אלה עבור Windows XP, Windows Vista ו- Windows 7, הן בגרסאות 32 סיביות והן ב -64 סיביות.

7. תאימות חומרה

אנדרואיד נועד לאפשר למיישמי מכשירים ליצור גורמי צורה חדשניים ותצורות. במקביל מפתחי אנדרואיד כותבים יישומים חדשניים המסתמכים על החומרה והתכונות השונות הזמינות באמצעות ממשקי ה- API של אנדרואיד. הדרישות בסעיף זה מציבות איזון בין חידושים העומדים לרשות יישומי המכשירים, לבין צרכיהם של מפתחים כדי להבטיח שהאפליקציות שלהם יהיו זמינות רק למכשירים שבהם הם יפעלו כראוי.

אם מכשיר כולל רכיב חומרה מסוים שיש לו ממשק API מקביל למפתחי צד ג ', על יישום המכשיר ליישם את ה- API כמתואר בתיעוד SDK של אנדרואיד. אם ממשק API ב- SDK מקיים אינטראקציה עם רכיב חומרה שצוין כאופציונלי ויישום המכשיר אינו בעל רכיב זה:

• הגדרות הכיתה המלאות (כפי שתועד על ידי ה- SDK) עבור ממשקי ה- API של הרכיב עדיין חייבים להיות נוכחים
• יש ליישם את התנהגויות ה- API כ- NO-OPS באופן סביר
• שיטות API חייבות להחזיר ערכי null כאשר מותרות בתיעוד SDK
• שיטות API חייבות להחזיר יישומים ללא- OP של כיתות בהן ערכי NULL אינם מורשים על ידי תיעוד SDK
• אסור ששיטות API צריכות לזרוק חריגים שלא תועדו על ידי תיעוד SDK

דוגמה אופיינית לתרחיש בו דרישות אלה חלות היא ממשק ה- API של הטלפוניה: אפילו במכשירים שאינם טלפון, יש ליישם ממשקי API אלה כלא-אופים סבירים.

יישומי מכשירים חייבים לדווח במדויק על מידע על תצורת חומרה מדויקת באמצעות שיטות getSystemAvailableFeatures() ו- hasSystemFeature(String) בשיטות android.content.pm.PackageManager . [ משאבים, 27 ]

7.1. תצוגה וגרפיקה

Android 2.3 כולל מתקנים המתאימים אוטומטית נכסי יישומים ופריסות ממשק משתמש כראוי עבור המכשיר, כדי להבטיח כי יישומי צד ג 'פועלים היטב במגוון תצורות חומרה [ משאבים, 28 ]. על מכשירים ליישם כראוי ממשקי API והתנהגויות אלה, כמפורט בסעיף זה.

7.1.1. תצורות מסך

יישומי מכשירים רשאים להשתמש במסכים מכל מידות פיקסל, בתנאי שהם עומדים בדרישות הבאות:

• המסכים חייבים להיות לפחות 2.5 אינץ 'בגודל אלכסוני פיזי
• צפיפות חייבת להיות לפחות 100 dpi
• יחס הגובה המבט חייב להיות בין 1.333 (4: 3) ל- 1.779 (16: 9)
• טכנולוגיית התצוגה המשמשת מורכבת מפיקסלים מרובעים

יישומי מכשירים עם מסך העומד בדרישות לעיל נחשבים תואמים, ואין צורך בפעולה נוספת. יישום מסגרת אנדרואיד מחשב אוטומטית מאפייני תצוגה כמו דלי גודל המסך ודלי צפיפות. ברוב המקרים החלטות המסגרת הן הנכונות. אם משתמשים בחישובי מסגרת ברירת המחדל, אין צורך בפעולה נוספת. יישומי מכשירים המעוניינים לשנות את ברירות המחדל, או להשתמש במסך שאינו עומד בדרישות לעיל חייבים לפנות לצוות התאימות של אנדרואיד לקבלת הנחיות, כאמור בסעיף 12.

היחידות המשמשות את הדרישות לעיל מוגדרות כדלקמן:

• "גודל אלכסוני פיזי" הוא המרחק בסנטימטרים בין שתי פינות מנוגדות של החלק המואר של התצוגה.
• "DPI" (כלומר "נקודות לאינץ '") הוא מספר הפיקסלים המקיפים על ידי טווח אופקי או אנכי ליניארי של 1 ". שם רשומים ערכי DPI, DPI אופקי ואנכי חייבים ליפול בטווח.
• "יחס גובה -רוחב" הוא היחס בין הממד הארוך יותר של המסך למימד הקצר יותר. לדוגמה, תצוגה של 480x854 פיקסלים תהיה 854 /480 = 1.779, או בערך "16: 9".

על יישומי מכשירים להשתמש רק בתצוגות עם תצורה סטטית יחידה. כלומר, אסור ליישומי מכשירים לאפשר תצורות מסך מרובות. לדוגמה, מכיוון שטלוויזיה טיפוסית תומכת ברזולוציות מרובות כמו 1080p, 720p וכן הלאה, תצורה זו אינה תואמת לאנדרואיד 2.3. (עם זאת, התמיכה בתצורות כאלה נמצאת בחקירה ומתוכננת לגרסה עתידית של אנדרואיד.)

7.1.2. מדדי תצוגה

על יישומי מכשירים לדווח על ערכים נכונים עבור כל מדדי התצוגה המוגדרים ב- android.util.DisplayMetrics [ משאבים, 29 ].

7.1.3. תמיכה מסך מוצהרת

יישומים אופציונליים מציינים באילו גדלי מסך הם תומכים באמצעות התכונה <supports-screens> בקובץ AndroidManifest.xml. על יישומי מכשירים לכבד נכון את התמיכה המוצהרת של יישומים במסכים קטנים, בינוניים וגדולים, כמתואר בתיעוד SDK של אנדרואיד.

7.1.4. כיוון מסך

על מכשירים תואמים לתמוך באוריינטציה דינאמית על ידי יישומים לדיוקן או אוריינטציה של מסך נוף. כלומר, על המכשיר לכבד את בקשת היישום להתמצאות מסך ספציפית. יישומי מכשירים עשויים לבחור בכיוון דיוקן או נוף כברירת מחדל. מכשירים שלא ניתן לסובב פיזית עשויים לעמוד בדרישה זו על ידי יישומים "תיבות מכתבים" המבקשים מצב דיוקן, תוך שימוש רק בחלק מהתצוגה הזמינה.

על התקנים לדווח על הערך הנכון עבור האוריינטציה הנוכחית של המכשיר, בכל פעם שנשאל באמצעות Android.content.res.Configuration.orientation, android.view.display.getorientation () או ממשקי API אחרים.

7.1.5. תאוצה גרפית תלת מימדית

יישומי מכשירים חייבים לתמוך ב- OpenGL ES 1.0, כנדרש על ידי API אנדרואיד 2.3. עבור מכשירים חסרי חומרת תאוצה תלת-ממדית, יישום תוכנה של OpenGL ES 1.0 מסופק על ידי פרויקט הקוד הפתוח של אנדרואיד במעלה הזרם. יישומי מכשירים צריכים לתמוך ב- OpenGL ES 2.0.

יישומים עשויים להשמיט תמיכה פתוחה GL ES 2.0; עם זאת, אם מושמטים תמיכה, אסור ליישומי מכשירים לדווח כתומך ב- OpenGL ES 2.0. באופן ספציפי, אם יישומי מכשיר חסר תמיכה ב- OpenGl ES 2.0:

• APIs המנוהלים (כגון דרך שיטת GLES10.getString() אסור לדווח על תמיכה ב- OpenGL ES 2.0
• APIs המקורי C/C ++ OpenGL (כלומר, אלה הזמינים לאפליקציות באמצעות Libgles_V1CM.SO, Libgles_V2.SO, או LibeGl.SO) אסור לדווח על תמיכה ב- OpenGL ES 2.0.

לעומת זאת, אם יישום מכשיר אכן תומך ב- OpenGL ES 2.0, עליו לדווח במדויק על התמיכה דרך המסלולים שרק רשומים.

שים לב שאנדרואיד 2.3 כולל תמיכה ביישומים כדי לציין באופן אופציונלי כי הם דורשים פורמטים ספציפיים לדחיסת טקסטורה של OpenGL. פורמטים אלה הם בדרך כלל ספציפיים לספק. יישומי מכשירים אינם נדרשים על ידי Android 2.3 ליישום כל פורמט דחיסת מרקם ספציפי. עם זאת, עליהם לדווח במדויק על כל פורמטים של דחיסת מרקם שהם תומכים בהם, באמצעות שיטת getString() בממשק ה- API של OpenGL.

7.2. התקני קלט

Android 2.3 תומך במספר מצבים עבור קלט משתמשים. יישומי מכשירים חייבים לתמוך במכשירי קלט משתמשים כמפורט בסעיף זה.

7.2.1. מקלדת

יישומי מכשיר:

• חייבים לכלול תמיכה במסגרת ניהול הקלט (המאפשרת למפתחי צד ג 'ליצור מנועי ניהול קלט - כלומר מקלדת רכה) כמפורט באתר המפתח.
• חייב לספק לפחות יישום מקלדת רכה אחת (ללא קשר אם קיימת מקלדת קשה)
• עשוי לכלול יישומי מקלדת רכים נוספים
• עשוי לכלול מקלדת חומרה
• אסור לכלול מקלדת חומרה שאינה תואמת את אחד הפורמטים המפורטים ב- android.content.res.Configuration.keyboard

7.2.2. ניווט ללא מגע

יישומי מכשיר:

• רשאי להשמיט אפשרות ניווט שאינה מגע (כלומר, רשאי להשמיט כדור מסלול, D-PAD או גלגל)
• חייב לדווח על הערך הנכון עבור android.content.res.Configuration.navigation [ משאבים, 30 ]
• חייב לספק מנגנון ממשק משתמש אלטרנטיבי סביר לבחירה ועריכה של טקסט, התואם למנועי ניהול קלט. קוד הקוד הפתוח של אנדרואיד במעלה הזרם כולל מנגנון בחירה המתאים לשימוש במכשירים חסרי תשומות ניווט שאינן מגע.

7.2.3. מפתחות ניווט

פונקציות הבית, התפריט והגב חיוניות לפרדיגמת ניווט אנדרואיד. יישומי מכשירים חייבים להנגיש פונקציות אלה למשתמש בכל עת, ללא קשר למצב היישום. יש ליישם פונקציות אלה באמצעות כפתורים ייעודיים. הם עשויים להיות מיושמים באמצעות תוכנה, מחוות, לוח מגע וכו ', אך אם כן עליהם להיות תמיד נגישים ולא מעורפלים או להפריע לאזור תצוגת היישום הזמין.

על מיישמי מכשירים לספק גם מפתח חיפוש ייעודי. מיישמי מכשירים עשויים לספק גם מפתחות שליחה וקצה לשיחות טלפון.

7.2.4. קלט מסך מגע

יישומי מכשיר:

• חייב להיות מסך מגע
• יכול להיות שיש מסך מגע קיבולי או התנגדות
• חייב לדווח על הערך של android.content.res.Configuration [ משאבים, 30 ] המשקף תואם לסוג מסך המגע הספציפי במכשיר
• צריך לתמוך באופן מלא במעקב באופן עצמאי, אם מסך המגע תומך במספר עצות

7.3. חיישנים

אנדרואיד 2.3 כולל ממשקי API לגישה למגוון סוגי חיישנים. יישומי מכשירים בדרך כלל עשויים להשמיט חיישנים אלה, כאמור בסעיפי המשנה הבאים. אם מכשיר כולל סוג חיישן מסוים שיש לו ממשק API מקביל למפתחי צד ג ', על יישום המכשיר ליישם את ה- API כמתואר בתיעוד SDK של אנדרואיד. לדוגמה, יישומי מכשירים:

• חייב לדווח במדויק על נוכחותם או היעדר חיישנים לפי android.content.pm.PackageManager . [ משאבים, 27 ]
• חייבים להחזיר רשימה מדויקת של חיישנים נתמכים באמצעות SensorManager.getSensorList() ושיטות דומות
• חייבים להתנהג באופן סביר עבור כל APIs שאר חיישנים (לדוגמה, על ידי החזרת אמת או כוזבת לפי הצורך כאשר יישומים מנסים לרשום מאזינים, לא להתקשר למאזיני חיישנים כאשר החיישנים המתאימים אינם קיימים; וכו ')

הרשימה שלמעלה אינה מקיפה; ההתנהגות המתועדת של אנדרואיד SDK אמורה להיחשב סמכותית.

סוגי חיישנים מסוימים הם סינתטיים, כלומר הם יכולים להיות נגזרים מנתונים המסופקים על ידי חיישן אחד או יותר. (דוגמאות כוללות את חיישן האוריינטציה, וחיישן ההאצה הליניארית.) יישומי מכשירים צריכים ליישם סוגי חיישנים אלה, כאשר הם כוללים את החיישנים הפיזיים המוקדמים.

ממשקי ה- API של אנדרואיד 2.3 מציגים מושג של חיישן "זורם", שהוא כזה שמחזיר נתונים ברציפות, ולא רק כאשר הנתונים משתנים. יישומי מכשירים חייבים לספק ברציפות דגימות נתונים תקופתיות עבור כל API המצוין על ידי תיעוד SDK Android 2.3 להיות חיישן סטרימינג.

7.3.1. מד תאוצה

יישומי מכשירים צריכים לכלול תאוצה של 3 צירים. אם יישום מכשיר אכן כולל תאוצה של 3 צירים, זה: זה:

• חייב להיות מסוגל לספק אירועים במהירות של 50 הרץ ומעלה
• חייב לעמוד במערכת הקואורדינטות של חיישן אנדרואיד כמפורט בממשקי ה- API של אנדרואיד (ראה [ משאבים, 31 ])
• חייב להיות מסוגל למדוד מנפילה חופשית עד פעמיים כוח משיכה (2 גרם) ומעלה על כל וקטור תלת ממדי
• חייב להיות בעל 8 פיסות דיוק או יותר
• חייב להיות סטיית תקן לא גדולה מ- 0.05 מ '/ש' 2

7.3.2. מגנומטר

יישומי מכשירים צריכים לכלול מגנטומטר של 3 צירים (כלומר מצפן.) אם מכשיר אכן כולל מגנטומטר 3 צירים, IT:

• חייב להיות מסוגל לספק אירועים במהירות של 10 הרץ ומעלה
• חייב לעמוד במערכת הקואורדינטות של חיישן אנדרואיד כמפורט בממשקי ה- API של אנדרואיד (ראה [ משאבים, 31 ]).
• חייב להיות מסוגל לדגום מגוון של חוזקות שדה הולם לכיסוי השדה הגיאומגנטי
• חייב להיות בעל 8 פיסות דיוק או יותר
• חייב להיות סטיית תקן לא גדולה מ- 0.5 μT

7.3.3. ג'י.פי. אס

יישומי מכשירים צריכים לכלול מקלט GPS. אם יישום מכשיר אכן כולל מקלט GPS, עליו לכלול סוג כלשהו של טכניקת "GPS בסיוע" כדי למזער את זמן נעילת ה- GPS.

7.3.4. ג'ִירוֹסקוֹפּ

יישומי מכשירים צריכים לכלול גירוסקופ (IE חיישן שינוי זוויתי.) מכשירים לא צריכים לכלול חיישן גירוסקופ אלא אם כן כלול גם מד תאוצה של 3 צירים. אם יישום מכשיר כולל גירוסקופ, זה: הוא:

• חייב להיות מסוגל למדוד שינויים באוריינטציה של עד 5.5*רדיאנים/שנייה (כלומר, בערך 1,000 מעלות לשנייה)
• חייב להיות מסוגל לספק אירועים במהירות של 100 הרץ ומעלה
• חייב להיות בעל 8 פיסות דיוק או יותר

7.3.5. בָּרוֹמֶטֶר

יישומי מכשירים עשויים לכלול ברומטר (כלומר חיישן לחץ אוויר אווירה.) אם יישום מכשיר כולל ברומטר, IT:

• חייב להיות מסוגל לספק אירועים במהירות של 5 הרץ ומעלה
• חייב להיות דיוק הולם כדי לאפשר הערכת גובה

7.3.7. מד חום

יישומי מכשירים עשויים להיות אמורים לכלול מדחום (IE חיישן טמפרטורה.) אם יישום מכשיר אכן כולל מדחום, עליו למדוד את הטמפרטורה של מעבד המכשיר. אסור לה למדוד טמפרטורה אחרת. (שימו לב שסוג חיישן זה מיושם בממשקי API של אנדרואיד 2.3.)

7.3.7. פוֹטוֹמֶטֶר

יישומי מכשירים עשויים לכלול פוטומטר (כלומר חיישן תאורת הסביבה.)

7.3.8. חיישן קרבה

יישומי מכשירים עשויים לכלול חיישן קרבה. אם יישום מכשיר אכן כולל חיישן קרבה, עליו למדוד את הקרבה של אובייקט באותו כיוון כמו המסך. כלומר, חיישן הקרבה חייב להיות מכוון לאיתור אובייקטים הקרובים למסך, שכן הכוונה העיקרית של סוג חיישן זה היא לאתר טלפון בשימוש על ידי המשתמש. אם יישום מכשיר כולל חיישן קרבה עם אוריינטציה אחרת, אסור לו להיות נגיש באמצעות ממשק API זה. אם ליישום מכשיר יש חיישן קרבה, עליו להיות בעל דיוק של 1 סיביות או יותר.

7.4. קישוריות נתונים

קישוריות רשת וגישה לאינטרנט הם תכונות חיוניות של אנדרואיד. בינתיים, אינטראקציה בין מכשיר למכשיר מוסיפה ערך משמעותי למכשירי אנדרואיד ויישומים. יישומי מכשירים חייבים לעמוד בדרישות קישוריות הנתונים בסעיף זה.

7.4.1. טלפוניה

"טלפוניה" כפי שמשמשת ממשקי ה- API של אנדרואיד 2.3 ומסמך זה מתייחס ספציפית לחומרה הקשורה להצבת שיחות קוליות ושליחת הודעות SMS באמצעות רשת GSM או CDMA. אמנם שיחות קוליות אלה עשויות להיות מנות מנות, אך הן למטרות אנדרואיד 2.3 נחשבות ללא תלות בכל קישוריות נתונים שעשויה להיות מיושמת באמצעות אותה רשת. במילים אחרות, הפונקציונליות של אנדרואיד "טלפוניה" וממשקי API מתייחסים באופן ספציפי לשיחות קוליות ו- SMS; לדוגמה, יישומי מכשירים שאינם יכולים לבצע שיחות או לשלוח/לקבל הודעות SMS אסור לדווח על התכונה "Android.hardware.telephony" או על כל תכונות משנה, ללא קשר אם הם משתמשים ברשת סלולרית לקישוריות נתונים.

ניתן להשתמש באנדרואיד 2.3 במכשירים שאינם כוללים חומרת טלפוניה. כלומר, אנדרואיד 2.3 תואם למכשירים שאינם טלפונים. עם זאת, אם יישום מכשיר אכן כולל טלפוניה של GSM או CDMA, עליו ליישם תמיכה מלאה ב- API עבור אותה טכנולוגיה. יישומי מכשירים שאינם כוללים חומרת טלפוניה חייבים ליישם את ממשקי ה- API המלאים כ- NO-OPS.

7.4.2. IEEE 802.11 (wifi)

יישומי מכשירים אנדרואיד 2.3 צריכים לכלול תמיכה בצורה אחת או יותר של 802.11 (B/G/A/N וכו ') אם יישום מכשיר אכן כולל תמיכה ב- 802.11, עליו ליישם את ה- API של אנדרואיד המתאים.

7.4.3. בלוטות

יישומי מכשירים צריכים לכלול משדר Bluetooth. יישומי מכשירים הכוללים משדר Bluetooth חייבים לאפשר ממשק API מבוסס Bluetooth מבוסס RFCOMM כמתואר בתיעוד SDK [ משאבים, 32 ]. יישומי מכשירים צריכים ליישם פרופילי Bluetooth רלוונטיים, כגון A2DP, AVRCP, OBEX וכו 'לפי הצורך למכשיר.

חבילת מבחן התאימות כוללת מקרים המכסים פעולה בסיסית של ANDROID RFCOMM Bluetooth API. עם זאת, מכיוון ש- Bluetooth הוא פרוטוקול תקשורת בין מכשירים, לא ניתן לבדוק אותו באופן מלא על ידי בדיקות יחידות הפועלות במכשיר יחיד. כתוצאה מכך, על יישומי מכשירים להעביר גם את נוהל בדיקת Bluetooth מונע אנושי המתואר בנספח A.

7.4.4. תקשורת כמעט בשדה

יישומי מכשירים צריכים לכלול משדר וחומרה קשורה לתקשורת כמעט שדה (NFC). אם יישום מכשיר אכן כולל חומרת NFC, אז הוא:

• חייב לדווח על תכונת Android.hardware.nfc מהשיטה android.content.pm.PackageManager.hasSystemFeature() . [ משאבים, 27 ]
• חייב להיות מסוגל לקרוא ולכתוב הודעות NDEF באמצעות תקני NFC הבאים:
  • חייב להיות מסוגל לפעול כקורא/כותב פורום NFC (כהגדרתה על ידי המפרט הטכני של פורום NFC NFCFORUM-TS-DigitalProtocol-1.0) באמצעות תקני NFC הבאים:
    • NFCA (ISO14443-3A)
    • NFCB (ISO14443-3B)
    • NFCF (JIS 6319-4)
    • NFCV (ISO 15693)
    • ISODEP (ISO 14443-4)
    • תגי פורום NFC סוגים 1, 2, 3, 4 (מוגדרים על ידי פורום NFC)
  • חייב להיות מסוגל להעביר ולקבל נתונים באמצעות הסטנדרטים והפרוטוקולים הבאים של עמיתים לעמית:
    • ISO 18092
    • LLCP 1.0 (מוגדר על ידי פורום NFC)
    • SDP 1.0 (מוגדר על ידי פורום NFC)
    • פרוטוקול הדחיפה של NDEF [ משאבים, 33 ]
  • חייבים לסרוק את כל הטכנולוגיות הנתמכות בזמן שהם במצב גילוי NFC.
  • צריך להיות במצב גילוי NFC בזמן שהמכשיר ער כאשר המסך פעיל.

  (שימו לב כי קישורים זמינים לציבור אינם זמינים למפרטי הפורום של JIS, ISO ו- NFC שהובאו לעיל.)

  בנוסף, יישומי מכשירים צריכים לתמוך בטכנולוגיות MiFare המופעלות באופן נרחב.

  • Mifare Classic (NXP MF1S503X [ משאבים, 34 ], MF1S703X [ משאבים, 35 ])
  • Mifare Ultralight (NXP MF0ICU1 [ משאבים, 36 ], MF0ICU2 [ משאבים, 37 ])
  • Ndef ב- Mifare Classic (NXP AN130511 [ משאבים, 38 ], AN130411 [ משאבים, 39 ])

  שימו לב שאנדרואיד 2.3.3 כולל ממשקי API עבור סוגי Mifare אלה. אם יישום מכשיר תומך ב- MiFare, IT:

  • חייב ליישם את ממשקי ה- API של אנדרואיד המתאימים כפי שתועד על ידי אנדרואיד SDK
  • חייב לדווח על התכונה com.nxp.mifare מהשיטה של android.content.pm.PackageManager.hasSystemFeature() . [ משאבים, 27 ] שים לב שזו אינה תכונה אנדרואיד סטנדרטית, וככזו אינה מופיעה כקבוע בכיתה של PackageManager .
  • אסור ליישם את ממשקי ה- API של אנדרואיד המתאימים ולא לדווח על תכונת com.nxp.mifare אלא אם כן היא מיישמת גם את התמיכה הכללית של NFC כמתואר בסעיף זה

  אם יישום מכשיר אינו כולל חומרת NFC, אסור להצהיר על התכונה Android.hardware.nfc מה- android.content.pm.PackageManager.hasSystemFeature() שיטה [ משאבים, 27 ], ועליו ליישם את API של אנדרואיד 2.3 NFC כ- API כ- API כ- NFC כ- NFC כ- NFC כ- NFC כ- NFC 2.3 NFC 2.3 NFC 2.3 NFC 2.3 NFC 2.3 NFC 2.3 NFC 2.3 NFC. ללא אופ.

  מכיוון שהשיעורים android.nfc.NdefMessage ו- android.nfc.NdefRecord מייצגים פורמט ייצוג נתונים עצמאי פרוטוקול, על יישומי מכשירים ליישם ממשקי API אלה גם אם הם אינם כוללים תמיכה ב- NFC או להכריז על תכונת Android.hardware.nfc.

  7.4.5. יכולת רשת מינימלית

  יישומי מכשירים חייבים לכלול תמיכה בצורה אחת או יותר של רשת נתונים. Specifically, device implementations MUST include support for at least one data standard capable of 200Kbit/sec or greater. Examples of technologies that satisfy this requirement include EDGE, HSPA, EV-DO, 802.11g, Ethernet, etc.

  Device implementations where a physical networking standard (such as Ethernet) is the primary data connection SHOULD also include support for at least one common wireless data standard, such as 802.11 (WiFi).

  Devices MAY implement more than one form of data connectivity.

  7.5. מצלמות

  Device implementations SHOULD include a rear-facing camera, and MAY include a front-facing camera. A rear-facing camera is a camera located on the side of the device opposite the display; that is, it images scenes on the far side of the device, like a traditional camera. A front-facing camera is a camera located on the same side of the device as the display; that is, a camera typically used to image the user, such as for video conferencing and similar applications.

  7.5.1. מצלמה אחורית

  Device implementations SHOULD include a rear-facing camera. If a device implementation includes a rear-facing camera, it:

  • MUST have a resolution of at least 2 megapixels
  • SHOULD have either hardware auto-focus, or software auto-focus implemented in the camera driver (transparent to application software)
  • MAY have fixed-focus or EDOF (extended depth of field) hardware
  • MAY include a flash. If the Camera includes a flash, the flash lamp MUST NOT be lit while an android.hardware.Camera.PreviewCallback instance has been registered on a Camera preview surface, unless the application has explicitly enabled the flash by enabling the FLASH_MODE_AUTO or FLASH_MODE_ON attributes of a Camera.Parameters object. Note that this constraint does not apply to the device's built-in system camera application, but only to third-party applications using Camera.PreviewCallback .

  7.5.2. מצלמה קדמית

  Device implementations MAY include a front-facing camera. If a device implementation includes a front-facing camera, it:

  • MUST have a resolution of at least VGA (that is, 640x480 pixels)
  • MUST NOT use a front-facing camera as the default for the Camera API. That is, the camera API in Android 2.3 has specific support for front-facing cameras, and device implementations MUST NOT configure the API to to treat a front-facing camera as the default rear-facing camera, even if it is the only camera on המכשיר.
  • MAY include features (such as auto-focus, flash, etc.) available to rear-facing cameras as described in Section 7.5.1.
  • MUST horizontally reflect (ie mirror) the stream displayed by an app in a CameraPreview, as follows:
  • If the device implementation is capable of being rotated by user (such as automatically via an accelerometer or manually via user input), the camera preview MUST be mirrored horizontally relative to the device's current orientation.
  • If the current application has explicitly requested that the Camera display be rotated via a call to the android.hardware.Camera.setDisplayOrientation() [ Resources, 40 ] method, the camera preview MUST be mirrored horizontally relative to the orientation specified by the application.
  • Otherwise, the preview MUST be mirrored along the device's default horizontal axis.
  • MUST mirror the image data returned to any "postview" camera callback handlers, in the same manner as the camera preview image stream. (If the device implementation does not support postview callbacks, this requirement obviously does not apply.)
  • MUST NOT mirror the final captured still image or video streams returned to application callbacks or committed to media storage

  7.5.3. התנהגות API של מצלמה

  Device implementations MUST implement the following behaviors for the camera-related APIs, for both front- and rear-facing cameras:

  1. If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int), then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to application callbacks.
  2. If an application registers an android.hardware.Camera.PreviewCallback instance and the system calls the onPreviewFrame() method when the preview format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame() must further be in the NV21 encoding format. That is, NV21 MUST be the default.
  3. Device implementations SHOULD support the YV12 format (as denoted by the android.graphics.ImageFormat.YV12 constant) for camera previews for both front- and rear-facing cameras. Note that the Compatibility Definition for a future version is planned to change this requirement to "MUST". That is, YV12 support is optional in Android 2.3 but will be required by a future version. Existing and new devices that run Android 2.3 are very strongly encouraged to meet this requirement in Android 2.3 , or they will not be able to attain Android compatibility when upgraded to the future version.

  Device implementations MUST implement the full Camera API included in the Android 2.3 SDK documentation [ Resources, 41 ]), regardless of whether the device includes hardware autofocus or other capabilities. For instance, cameras that lack autofocus MUST still call any registered android.hardware.Camera.AutoFocusCallback instances (even though this has no relevance to a non-autofocus camera.) Note that this does apply to front-facing cameras; for instance, even though most front-facing cameras do not support autofocus, the API callbacks must still be "faked" as described.

  Device implementations MUST recognize and honor each parameter name defined as a constant on the android.hardware.Camera.Parameters class, if the underlying hardware supports the feature. If the device hardware does not support a feature, the API must behave as documented. Conversely, Device implementations MUST NOT honor or recognize string constants passed to the android.hardware.Camera.setParameters() method other than those documented as constants on the android.hardware.Camera.Parameters . That is, device implementations MUST support all standard Camera parameters if the hardware allows, and MUST NOT support custom Camera parameter types.

  7.5.4. כיוון מצלמה

  Both front- and rear-facing cameras, if present, MUST be oriented so that the long dimension of the camera aligns with the screen's long dimension. That is, when the device is held in the landscape orientation, a cameras MUST capture images in the landscape orientation. This applies regardless of the device's natural orientation; that is, it applies to landscape-primary devices as well as portrait-primary devices.

  7.6. Memory and Storage

  The fundamental function of Android 2.3 is to run applications. Device implementations MUST the requirements of this section, to ensure adequate storage and memory for applications to run properly.

  7.6.1. Minimum Memory and Storage

  Device implementations MUST have at least 128MB of memory available to the kernel and userspace. The 128MB MUST be in addition to any memory dedicated to hardware components such as radio, memory, and so on that is not under the kernel's control.

  Device implementations MUST have at least 150MB of non-volatile storage available for user data. That is, the /data partition MUST be at least 150MB.

  Beyond the requirements above, device implementations SHOULD have at least 1GB of non-volatile storage available for user data. Note that this higher requirement is planned to become a hard minimum in a future version of Android. Device implementations are strongly encouraged to meet these requirements now, or else they may not be eligible for compatibility for a future version of Android.

  The Android APIs include a Download Manager that applications may use to download data files. The Download Manager implementation MUST be capable of downloading individual files 55MB in size, or larger. The Download Manager implementation SHOULD be capable of downloading files 100MB in size, or larger.

  7.6.2. Application Shared Storage

  Device implementations MUST offer shared storage for applications. The shared storage provided MUST be at least 1GB in size.

  Device implementations MUST be configured with shared storage mounted by default, "out of the box". If the shared storage is not mounted on the Linux path /sdcard , then the device MUST include a Linux symbolic link from /sdcard to the actual mount point.

  Device implementations MUST enforce as documented the android.permission.WRITE_EXTERNAL_STORAGE permission on this shared storage. Shared storage MUST otherwise be writable by any application that obtains that permission.

  Device implementations MAY have hardware for user-accessible removable storage, such as a Secure Digital card. Alternatively, device implementations MAY allocate internal (non-removable) storage as shared storage for apps.

  Regardless of the form of shared storage used, device implementations MUST provide some mechanism to access the contents of shared storage from a host computer, such as USB mass storage or Media Transfer Protocol.

  It is illustrative to consider two common examples. If a device implementation includes an SD card slot to satisfy the shared storage requirement, a FAT-formatted SD card 1GB in size or larger MUST be included with the device as sold to users, and MUST be mounted by default. Alternatively, if a device implementation uses internal fixed storage to satisfy this requirement, that storage MUST be 1GB in size or larger and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted elsewhere.)

  Device implementations that include multiple shared storage paths (such as both an SD card slot and shared internal storage) SHOULD modify the core applications such as the media scanner and ContentProvider to transparently support files placed in both locations.

  7.7. יו אס בי

  יישומי מכשיר:

  • MUST implement a USB client, connectable to a USB host with a standard USB-A port
  • MUST implement the Android Debug Bridge over USB (as described in Section 7)
  • MUST implement the USB mass storage specification, to allow a host connected to the device to access the contents of the /sdcard volume
  • SHOULD use the micro USB form factor on the device side
  • MAY include a non-standard port on the device side, but if so MUST ship with a cable capable of connecting the custom pinout to standard USB-A port

  8. תאימות ביצועים

  Compatible implementations must ensure not only that applications simply run correctly on the device, but that they do so with reasonable performance and overall good user experience. Device implementations MUST meet the key performance metrics of an Android 2.3 compatible device defined in the table below:

  מֶטרִי	Performance Threshold	הערות
  Application Launch Time	The following applications should launch within the specified time. Browser: less than 1300ms MMS/SMS: less than 700ms AlarmClock: less than 650ms	The launch time is measured as the total time to complete loading the default activity for the application, including the time it takes to start the Linux process, load the Android package into the Dalvik VM, and call onCreate.
  Simultaneous Applications	When multiple applications have been launched, re-launching an already-running application after it has been launched must take less than the original launch time.

  9. Security Model Compatibility

  Device implementations MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 42 ] in the Android developer documentation. Device implementations MUST support installation of self-signed applications without requiring any additional permissions/certificates from any third parties/authorities. Specifically, compatible devices MUST support the security mechanisms described in the follow sub-sections.

  9.1. הרשאות

  Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 42 ]. Specifically, implementations MUST enforce each permission defined as described in the SDK documentation; no permissions may be omitted, altered, or ignored. Implementations MAY add additional permissions, provided the new permission ID strings are not in the android.* namespace.

  9.2. UID and Process Isolation

  Device implementations MUST support the Android application sandbox model, in which each application runs as a unique Unix-style UID and in a separate process. Device implementations MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the Security and Permissions reference [ Resources, 42 ].

  9.3. Filesystem Permissions

  Device implementations MUST support the Android file access permissions model as defined in as defined in the Security and Permissions reference [ Resources, 42 ].

  9.4. Alternate Execution Environments

  Device implementations MAY include runtime environments that execute applications using some other software or technology than the Dalvik virtual machine or native code. However, such alternate execution environments MUST NOT compromise the Android security model or the security of installed Android applications, as described in this section.

  Alternate runtimes MUST themselves be Android applications, and abide by the standard Android security model, as described elsewhere in Section 9.

  Alternate runtimes MUST NOT be granted access to resources protected by permissions not requested in the runtime's AndroidManifest.xml file via the <uses-permission> mechanism.

  Alternate runtimes MUST NOT permit applications to make use of features protected by Android permissions restricted to system applications.

  Alternate runtimes MUST abide by the Android sandbox model. באופן ספציפי:

  • Alternate runtimes SHOULD install apps via the PackageManager into separate Android sandboxes (that is, Linux user IDs, etc.)
  • Alternate runtimes MAY provide a single Android sandbox shared by all applications using the alternate runtime.
  • Alternate runtimes and installed applications using an alternate runtime MUST NOT reuse the sandbox of any other app installed on the device, except through the standard Android mechanisms of shared user ID and signing certificate
  • Alternate runtimes MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications.

  Alternate runtimes MUST NOT be launched with, be granted, or grant to other applications any privileges of the superuser (root), or of any other user ID.

  The .apk files of alternate runtimes MAY be included in the system image of a device implementation, but MUST be signed with a key distinct from the key used to sign other applications included with the device implementation.

  When installing applications, alternate runtimes MUST obtain user consent for the Android permissions used by the application. That is, if an application needs to make use of a device resource for which there is a corresponding Android permission (such as Camera, GPS, etc.), the alternate runtime MUST inform the user that the application will be able to access that resource . If the runtime environment does not record application capabilities in this manner, the runtime environment MUST list all permissions held by the runtime itself when installing any application using that runtime.

  10. Software Compatibility Testing

  The Android Open-Source Project includes various testing tools to verify that device implementations are compatible. Device implementations MUST pass all tests described in this section.

  However, note that no software test package is fully comprehensive. For this reason, device implementers are very strongly encouraged to make the minimum number of changes as possible to the reference and preferred implementation of Android 2.3 available from the Android Open-Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

  10.1. Compatibility Test Suite

  Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 2 ] available from the Android Open Source Project, using the final shipping software on the device. Additionally, device implementers SHOULD use the reference implementation in the Android Open Source tree as much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and for any reimplementations of parts of the reference source code.

  The CTS is designed to be run on an actual device. Like any software, the CTS may itself contain bugs. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 2.3. Device implementations MUST pass the latest CTS version available at the time the device software is completed.

  MUST pass the most recent version of the Android Compatibility Test Suite (CTS) available at the time of the device implementation's software is completed. (The CTS is available as part of the Android Open Source Project [ Resources, 2 ].) The CTS tests many, but not all, of the components outlined in this document.

  10.2. מאמת CTS

  Device implementations MUST correctly execute all applicable cases in the CTS Verifier. The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that cannot be tested by an automated system, such as correct functioning of a camera and sensors.

  The CTS Verifier has tests for many kinds of hardware, including some hardware that is optional. Device implementations MUST pass all tests for hardware which they possess; for instance, if a device possesses an accelerometer, it MUST correctly execute the Accelerometer test case in the CTS Verifier. Test cases for features noted as optional by this Compatibility Definition Document MAY be skipped or omitted.

  Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier on builds that differ only in trivial ways. Specifically, device implementations that differ from an implementation that has passed the CTS Verfier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

  10.3. Reference Applications

  Device implementers MUST test implementation compatibility using the following open-source applications:

  • The "Apps for Android" applications [ Resources, 43 ].
  • Replica Island (available in Android Market; only required for device implementations that support with OpenGL ES 2.0)

  Each app above MUST launch and behave correctly on the implementation, for the implementation to be considered compatible.

  11. Updatable Software

  Device implementations MUST include a mechanism to replace the entirety of the system software. The mechanism need not perform "live" upgrades -- that is, a device restart MAY be required.

  Any method can be used, provided that it can replace the entirety of the software preinstalled on the device. For instance, any of the following approaches will satisfy this requirement:

  • Over-the-air (OTA) downloads with offline update via reboot
  • "Tethered" updates over USB from a host PC
  • "Offline" updates via a reboot and update from a file on removable storage

  The update mechanism used MUST support updates without wiping user data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

  If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, the device implementer MUST correct the error via a software update available that can be applied per the mechanism just described.

  12. Contact Us

  You can contact the document authors at compatibility@android.com for clarifications and to bring up any issues that you think the document does not cover.

  Appendix A - Bluetooth Test Procedure

  The Compatibility Test Suite includes cases that cover basic operation of the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications protocol between devices, it cannot be fully tested by unit tests running on a single device. Consequently, device implementations MUST also pass the human-operated Bluetooth test procedure described below.

  The test procedure is based on the BluetoothChat sample app included in the Android open-source project tree. The procedure requires two devices:

  • a candidate device implementation running the software build to be tested
  • a separate device implementation already known to be compatible, and of a model from the device implementation being tested -- that is, a "known good" device implementation

  The test procedure below refers to these devices as the "candidate" and "known good" devices, respectively.

  Setup and Installation

  1. Build BluetoothChat.apk via 'make samples' from an Android source code tree.
  2. Install BluetoothChat.apk on the known-good device.
  3. Install BluetoothChat.apk on the candidate device.

  Test Bluetooth Control by Apps

  1. Launch BluetoothChat on the candidate device, while Bluetooth is disabled.
  2. Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth.

  Test Pairing and Communication

  1. Launch the Bluetooth Chat app on both devices.
  2. Make the known-good device discoverable from within BluetoothChat (using the Menu).
  3. On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device.
  4. Send 10 or more messages from each device, and verify that the other device receives them correctly.
  5. Close the BluetoothChat app on both devices by pressing Home .
  6. Unpair each device from the other, using the device Settings app.

  Test Pairing and Communication in the Reverse Direction

  1. Launch the Bluetooth Chat app on both devices.
  2. Make the candidate device discoverable from within BluetoothChat (using the Menu).
  3. On the known-good device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the candidate device.
  4. Send 10 or messages from each device, and verify that the other device receives them correctly.
  5. Close the Bluetooth Chat app on both devices by pressing Back repeatedly to get to the Launcher.

  Test Re-Launches

  1. Re-launch the Bluetooth Chat app on both devices.
  2. Send 10 or messages from each device, and verify that the other device receives them correctly.

  Note: the above tests have some cases which end a test section by using Home, and some using Back. These tests are not redundant and are not optional: the objective is to verify that the Bluetooth API and stack works correctly both when Activities are explicitly terminated (via the user pressing Back, which calls finish()), and implicitly sent to background (via the user pressing Home.) Each test sequence MUST be performed as described.