הגדרת תאימות ל-Android 2.1

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

1. מבוא

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

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

במסמך הזה, "מפעיל מכשיר" או "מפעיל" הוא אדם או ארגון שמפתחים פתרון חומרה/תוכנה שפועל עם Android 2.1. 'הטמעה במכשיר' או 'הטמעה' היא הפתרון לחומרה או לתוכנה שפותח.

כדי להיחשב כתואם ל-Android 2.1, הטמעות במכשירים צריכות:

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

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

2. משאבים

  1. רמות הדרישה של IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
  2. סקירה כללית על תוכנית התאימות של Android: http://source.android.com/compatibility/index.html
  3. פרויקט קוד פתוח של Android: http://source.android.com/
  4. הגדרות ומסמכי עזרה של ממשקי API: http://developer.android.com/reference/packages.html
  5. מידע על ההרשאות ב-Android: 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.1: http://source.android.com/docs/compatibility/2.1/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. מפרט המכונה הווירטואלית של Dalvik: זמין בקוד המקור של Android, בכתובת dalvik/docs
  11. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  12. התראות: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
  13. משאבי אפליקציה: http://code.google.com/android/reference/available-resources.html
  14. מדריך סגנון לסמלי שורת הסטטוס: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
  15. Search Manager: http://developer.android.com/reference/android/app/SearchManager.html
  16. הודעות Toast: http://developer.android.com/reference/android/widget/Toast.html
  17. טפטים מונפשים: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  18. אפליקציות ל-Android: http://code.google.com/p/apps-for-android
  19. מסמכי תיעוד של הכלים (ל-adb,‏ aapt ו-ddms): http://developer.android.com/guide/developing/tools/index.html
  20. תיאור של קובץ apk ל-Android: http://developer.android.com/guide/topics/fundamentals.html
  21. קובצי מניפסט: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  22. כלי הבדיקה Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey
  23. תמיכה במספר מסכים: http://developer.android.com/guide/practices/screens_support.html
  24. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
  25. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  26. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
  27. מרחב קואורדינטות של חיישן: http://developer.android.com/reference/android/hardware/SensorEvent.html
  28. מידע על אבטחה והרשאות ב-Android: http://developer.android.com/guide/topics/security/security.html
  29. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

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

3. תוכנות

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

3.1. תאימות של ממשקי API מנוהלים

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

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

3.2. תאימות ל-Soft API

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

3.2.1. הרשאות

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

3.2.2. פרמטרים של build

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

פרמטר תגובות
android.os.Build.VERSION.RELEASE הגרסה של מערכת Android שפועלת כרגע, בפורמט קריא לבני אדם. השדה הזה חייב לכלול אחד מערכי המחרוזות שמוגדרים בקטע [Resources, 7].
android.os.Build.VERSION.SDK הגרסה של מערכת Android שפועלת כרגע, בפורמט שקוד של אפליקציות של צד שלישי יכול לגשת אליו. לגרסה Android 2.1, השדה הזה חייב לכלול את הערך השלם 7.
android.os.Build.VERSION.INCREMENTAL ערך שנבחר על ידי מי שמטמיע את המכשיר, שמציין את ה-build הספציפי של מערכת Android שפועלת כרגע, בפורמט שקריא לבני אדם. אסור להשתמש שוב בערך הזה לגרסאות build שונות שנשלחות למשתמשי קצה. שימוש נפוץ בשדה הזה הוא לציין את מספר ה-build או את מזהה השינוי במערכת בקרת הגרסאות ששימשו ליצירת ה-build. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
android.os.Build.BOARD ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את החומרה הפנימית הספציפית שבה המכשיר משתמש, בפורמט שקריא לבני אדם. אפשר להשתמש בשדה הזה כדי לציין את הגרסה הספציפית של הלוח שמפעיל את המכשיר. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
android.os.Build.BRAND ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את שם החברה, הארגון, האדם וכו' שייצרו את המכשיר, בפורמט שאפשר לקרוא על ידי בני אדם. אפשר להשתמש בשדה הזה כדי לציין את יצרן הציוד המקורי ו/או את הספק שמוכר את המכשיר. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או מחרוזת ריקה ("").
android.os.Build.DEVICE ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את ההגדרה הספציפית או את הגרסה של המארז (שנקרא לפעמים 'עיצוב תעשייתי') של המכשיר. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
android.os.Build.FINGERPRINT מחרוזת שמזהה באופן ייחודי את ה-build הזה. הוא אמור להיות קריא למדי לאדם. היא חייבת לפעול לפי התבנית הבאה:
$(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 מחרוזת שמזהה באופן ייחודי את המארח שבו נוצר ה-build, בפורמט שאפשר לקרוא אותו. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
android.os.Build.ID מזהה שנבחר על ידי מי שמטמיע את המכשיר כדי להפנות למהדורה ספציפית, בפורמט קריא לבני אדם. השדה הזה יכול להיות זהה ל-android.os.Build.VERSION.INCREMENTAL, אבל כדאי להגדיר בו ערך משמעותי מספיק כדי שמשתמשי הקצה יוכלו להבחין בין גרסאות build של תוכנה. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד האיסור להגדיר אותו כ-null או כמחרוזת ריקה ("").
android.os.Build.MODEL ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם המכשיר כפי שהוא ידוע למשתמש הקצה. השם הזה אמור להיות זהה לשם שתחתיו המכשיר משווק ונמכר למשתמשי קצה. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או מחרוזת ריקה ("").
android.os.Build.PRODUCT ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם הפיתוח או שם הקוד של המכשיר. חובה שיהיו קריאים לבני אדם, אבל הם לא מיועדים בהכרח לצפייה על ידי משתמשי קצה. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או מחרוזת ריקה ("").
android.os.Build.TAGS רשימה של תגים מופרדים בפסיקים שנבחרו על ידי מי שמטמיע את המכשיר, שמאפשרת להבדיל בין גרסאות build שונות. לדוגמה, ‎"unsigned,debug"‎. השדה הזה חייב להיות לא null או מחרוזת ריקה (""), אבל תג יחיד (כמו 'release') יתקבל בברכה.
android.os.Build.TIME ערך שמייצג את חותמת הזמן של מועד ה-build.
android.os.Build.TYPE ערך שנבחר על ידי מי שמטמיע את המכשיר, שמציין את הגדרת סביבת זמן הריצה של ה-build. השדה הזה צריך לכלול אחד מהערכים שתואמים לשלושת ההגדרות הנפוצות של Android בסביבת זמן הריצה: 'user',‏ 'userdebug' או 'eng'.
android.os.Build.USER שם או מזהה משתמש של המשתמש (או המשתמש האוטומטי) שיצר את ה-build. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").

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

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

3.2.3.1. כוונות ליבה של אפליקציות

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

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

האפליקציות הבאות נחשבות לאפליקציות ליבה של מערכת Android:

  • שעון שולחני
  • דפדפן
  • יומן
  • מחשבון
  • מצלמה
  • אנשי הקשר
  • אימייל
  • גלריה
  • GlobalSearch
  • מרכז האפליקציות
  • LivePicker (כלומר, האפליקציה לבחירת טפטים מונפשים. אפשר להשמיט אותה אם המכשיר לא תומך בטפטים מונפשים, בהתאם לקטע 3.8.5).
  • הודעות (נקראות גם 'MMS')
  • מוזיקה
  • טלפון
  • הגדרות
  • SoundRecorder

אפליקציות הליבה של מערכת Android כוללות רכיבי Activity או Service שונים שנחשבים 'ציבוריים'. כלומר, המאפיין android:exported יכול להיות חסר או שיהיה לו הערך true.

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

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

3.2.3.2. שינויים מברירת המחדל של Intent

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

הערה: הקטע הזה שונה על ידי Erratum EX6580.

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

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

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

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

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

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

קוד מנוהל שפועל ב-Dalvik יכול להפעיל קוד מקומי שסופק בקובץ ה-APK של האפליקציה כקובץ ELF עם סיומת ‎.so שעבר הידור לארכיטקטורת החומרה המתאימה של המכשיר. הטמעות במכשירים חייבות לכלול תמיכה בקוד שפועל בסביבה המנוהלת כדי לבצע קריאה לקוד מקומי, באמצעות סמנטיקה רגילה של Java Native Interface‏ (JNI). ממשקי ה-API הבאים חייבים להיות זמינים לקוד מקורי:

  • 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, אם החומרה מסוגלת לספק ביצועים סבירים בממשקי ה-API האלה.

הספריות האלה חייבות להיות תואמות למקור (כלומר תואמות לכותרות) ותואמות לבינארי (לארכיטקטורת מעבד נתונה) לגרסאות שסופקו ב-Bionic על ידי פרויקט Android Open Source. מאחר שהטמעות Bionic לא תואמות באופן מלא להטמעות אחרות כמו ספריית GNU C, הטמענים של המכשירים צריכים להשתמש בהטמעה של Android. אם מי שמטמיע את המכשיר משתמש בהטמעה אחרת של הספריות האלה, הוא חייב לוודא שהן תואמות מבחינת כותרות, קבצים בינאריים והתנהגות.

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

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

3.4. תאימות ל-Web API

מפתחים ואפליקציות רבים מסתמכים על ההתנהגות של הכיתה android.webkit.WebView [Resources, 8] בממשקי המשתמש שלהם, ולכן ההטמעה של WebView צריכה להיות תואמת להטמעות השונות של Android. בהטמעה של Android Open Source נעשה שימוש במנוע הרינדור של WebKit כדי להטמיע את WebView.

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

  • ב-WebView חייבים להשתמש ב-WebKit build בגרסה 530.17 מהעץ של Android Open Source למקור (upstream) עבור 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

אפשר לשלוח מחרוזת של סוכן משתמש בהתאמה אישית באפליקציית הדפדפן העצמאית. בנוסף, הדפדפן העצמאי עשוי להתבסס על טכנולוגיית דפדפן חלופית (כמו Firefox,‏ Opera וכו'). עם זאת, גם אם תישלח אפליקציית דפדפן חלופית, רכיב ה-WebView שסופק לאפליקציות של צד שלישי חייב להתבסס על WebKit, כפי שמתואר למעלה.

ההגדרה של WebView חייבת לכלול תמיכה במסד הנתונים של HTML5, במטמון האפליקציה ובממשקי ה-API למיקום גיאוגרפי [מקורות מידע, 9]. WebView חייב לכלול תמיכה בתג <video> של HTML5 בצורה כלשהי. אפליקציית הדפדפן העצמאית (בין שהיא מבוססת על אפליקציית הדפדפן WebKit למקור (upstream) ובין שהיא החלפה של צד שלישי) חייבת לכלול תמיכה באותן תכונות HTML5 שצוינו למעלה לגבי WebView.

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

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

  • אסור למכשירים לשנות את ההתנהגות או את המשמעות של כוונה רגילה
  • אסור למכשירים לשנות את מחזור החיים או את סמנטיקה של מחזור החיים של סוג מסוים של רכיב מערכת (כמו Service,‏ Activity,‏ ContentProvider וכו').
  • אסור למכשירים לשנות את הסמנטיקה של הרשאה מסוימת

הרשימה שלמעלה היא חלקית, והאחריות על תאימות ההתנהגות היא של מי שמטמיע את המכשיר. לכן, למטמיעים של מכשירים מומלץ להשתמש בקוד המקור שזמין דרך Android Open Source Project, במידת האפשר, במקום להטמיע מחדש חלקים משמעותיים במערכת.

חבילה לבדיקות תאימות (CTS) בודקת חלקים משמעותיים בפלטפורמה כדי לבדוק את התאימות ההתנהגותית, אבל לא את כולם. באחריות המטמיע לוודא תאימות התנהגותית לפרויקט Android Open Source.

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

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

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

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

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

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

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

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

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

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

הטמעות במכשירים חייבות לתמוך במפרט המלא של קוד בייט של Dalvik Executable ‏ (DEX) ובסמנטיקה של מכונה וירטואלית של Dalvik‏ [משאבים, 10].

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

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

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

3.8.1. ווידג'טים

ב-Android מוגדר סוג רכיב, API ומחזור חיים תואמים שמאפשרים לאפליקציות לחשוף 'AppWidget' למשתמש הקצה [משאבים, 11]. הגרסה של Android Open Source כוללת אפליקציית Launcher עם רכיבי ממשק משתמש שמאפשרים להוסיף, להציג ולהסיר ווידג'טים של אפליקציות ממסך הבית.

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

3.8.2. התראות

מערכת Android כוללת ממשקי API שמאפשרים למפתחים להודיע למשתמשים על אירועים משמעותיים [מקורות מידע, 12]. מי שמטמיע את המכשיר חייב לספק תמיכה בכל סוג של התראה כפי שהוגדר, ובפרט: צלילים, רטט, תאורה וסרגל סטטוס.

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

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

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

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

3.8.4. הודעות קופצות

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

3.8.5. טפטים מונפשים

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

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

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

4. תאימות של תוכנות לימוד ומידע

מחשבי המכשיר חייבים לבדוק את תאימות ההטמעה באמצעות האפליקציות הבאות בקוד פתוח:

  • מחשבון (כלול ב-SDK)
  • Lunar Lander (כלול ב-SDK)
  • האפליקציות 'אפליקציות ל-Android' [משאבים, 18].

כדי שההטמעה תחשב כתואמת, כל האפליקציות שלמעלה חייבות להיפתח ולפעול בצורה תקינה בהטמעה.

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

  • ApiDemos (כלול ב-SDK)
  • בדיקות ManualSmokeTests (כלולות ב-CTS)

כל תרחיש בדיקה באפליקציות שלמעלה חייב לפעול בצורה תקינה בהטמעה במכשיר.

5. תאימות של אריזת אפליקציות

הטמעות במכשירים חייבות להתקין ולהריץ קובצי 'apk.‎' של Android שנוצרו באמצעות הכלי 'aapt' שכלול ב-Android SDK הרשמי [מקורות מידע, 19].

אסור להרחיב את הטמעות המכשירים בפורמטים של קובצי APK‏ [Resources, 20], Android Manifest‏ [Resources, 21] או קוד בייט של Dalvik‏ [Resources, 10] באופן שימנע את ההתקנה וההפעלה הנכונה של הקבצים האלה במכשירים תואמים אחרים. מי שמטמיע מכשירים צריך להשתמש בהטמעה של Dalvik במקור, ובמערכת ניהול החבילות של ההטמעה.

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

חובה שתהיה תמיכה בקודקים הבאים של מדיה במכשירים. כל הקודקים האלה זמינים כמימושי תוכנה בהטמעת Android המועדפת מפרויקט Android Open Source.

לתשומת ליבכם: Google ו-Open Handset Alliance לא מצהירות שהקודקים האלה לא כפופים לפטנטים של צד שלישי. מי שמתכוון להשתמש בקוד המקור הזה במוצרי חומרה או תוכנה, צריך לדעת שיכול להיות שיהיו צורך ברישיונות פטנט מבעלי הפטנט הרלוונטיים כדי להטמיע את הקוד הזה, כולל בתוכנות קוד פתוח או בתוכנות שיתופיות.

אודיו
שם מקודד פענוח פרטים פורמט הקובץ/אמצעי האחסון
AAC LC/LTP   X תוכן מונו/סטריאו בכל שילוב של שיעורי ביט רגילים של עד 160kbps ותדירות דגימה של 8 עד 48kHz 3GPP‏ (‎.3gp) ו-MPEG-4‏ (‎.mp4,‏ ‎.m4a). אין תמיכה ב-AAC גולמי (‎.aac)
HE-AACv1‏ (AAC+)   X
HE-AACv2‏ (enhanced AAC+)   X
AMR-NB X X 4.75 עד 12.2kbps דגימה ב-8kHz 3GPP‏ (‎.3gp)
AMR-WB   X 9 שיעורי דגימה מ-6.60kbit/s עד 23.85kbit/s, בתדירות דגימה של 16kHz 3GPP‏ (‎.3gp)
MP3   X מונו/סטריאו 8-320Kbps קבוע (CBR) או קצב העברת נתונים משתנה (VBR) MP3‏ (‎.mp3)
MIDI   X MIDI מסוג 0 ו-1. DLS גרסה 1 ו-2. XMF ו-Mobile XMF. תמיכה בפורמטים של רינגטונים RTTTL/RTX,‏ OTA ו-iMelody סוגים 0 ו-1 (‎.mid,‏ ‎.xmf,‏ ‎.mxmf). גם RTTTL/RTX‏ (‎.rtttl,‏ ‎.rtx),‏ OTA‏ (‎.ota) ו-iMelody‏ (‎.imy)
Ogg Vorbis   X   Ogg‏ (‎.ogg)
PCM   X PCM לינאריים של 8 ו-16 ביט (שיעורים עד למגבלה של החומרה) WAVE‏ (‎.wav)
תמונה
JPEG X X base+progressive  
GIF   X    
PNG X X    
BMP   X    
סרטון
H.263 X X   קובצי 3GPP‏ (‎.3gp)
H.264   X   קובצי 3GPP‏ (‎.3gp) ו-MPEG-4‏ (‎.mp4)
MPEG4 Simple Profile   X   קובץ 3GPP‏ (‎.3gp)

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

7. תאימות של כלים למפתחים

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

  • Android Debug Bridge (נקרא גם adb) [מקורות מידע, 19]
    הטמעות במכשירים חייבות לתמוך בכל הפונקציות של adb כפי שמתואר ב-Android SDK. הדימון adb בצד המכשיר אמור להיות לא פעיל כברירת מחדל, אבל חייב להיות מנגנון שזמין למשתמשים כדי להפעיל את Android Debug Bridge.
  • Dalvik Debug Monitor Service‏ (נקרא גם ddms) [מקורות מידע, 19]
    הטמעות במכשירים חייבות לתמוך בכל התכונות של ddms כפי שמפורט ב-Android SDK. מכיוון ש-ddms משתמש ב-adb, התמיכה ב-ddms אמורה להיות לא פעילה כברירת מחדל, אבל חובה לספק תמיכה בכל פעם שהמשתמש הפעיל את Android Debug Bridge, כפי שמתואר למעלה.
  • Monkey [משאבים, 22]
    הטמעות במכשירים חייבות לכלול את מסגרת Monkey ולהפוך אותה לזמינה לשימוש באפליקציות.

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

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

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

  • חובה לכלול הגדרות של כיתות לממשקי ה-API של הרכיב
  • חובה להטמיע את התנהגויות ה-API כ-no-ops באופן סביר כלשהו
  • שיטות API חייבות להחזיר ערכי null במקרים שבהם הדבר מותאם לתיעוד של ה-SDK
  • שיטות API חייבות להחזיר הטמעות של no-op של כיתות שבהן ערכים null אסורים לפי מסמכי ה-SDK

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

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

8.1. תצוגה

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

ב-Android 2.1, אלה הגדרות התצוגה הנפוצות ביותר:

סוג מסך רוחב (פיקסלים) גובה (פיקסלים) טווח אורך האלכסון (אינץ') קבוצת גודל מסך קבוצת צפיפות מסך
QVGA 240 320 2.6 – 3.0 קטן נמוכה
WQVGA 240 400 3.2 עד 3.5 רגיל נמוכה
FWQVGA 240 432 3.5 עד 3.8 רגיל נמוכה
HVGA 320 480 3.0 עד 3.5 רגיל בינוני
WVGA 480 800 3.3 עד 4.0 רגיל רחב
FWVGA 480 854 3.5 עד 4.0 רגיל רחב
WVGA 480 800 4.8 עד 5.5 גדול בינוני
FWVGA 480 854 5.0 עד 5.8 גדול בינוני

הטמעות של מכשירים שתואמות לאחת מההגדרות הסטנדרטיות שלמעלה חייבות להיות מוגדרות לדיווח על גודל המסך שצוין לאפליקציות באמצעות הכיתה android.content.res.Configuration‏ [Resources,‏ 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 [משאבים, 25].

8.2. מקלדת

הטמעות במכשירים:

  • חובה לכלול תמיכה ב-Input Management Framework (שמאפשר למפתחים של צד שלישי ליצור מנועי ניהול קלט – כלומר מקלדת וירטואלית), כפי שמפורט בכתובת developer.android.com
  • חובה לספק לפחות הטמעה אחת של מקלדת וירטואלית (ללא קשר לכך שיש מקלדת פיזית)
  • יכולות לכלול הטמעות נוספות של מקלדות וירטואליות
  • יכול להיות שתכלול מקלדת חומרה
  • אסור לכלול מקלדת חומרה שלא תואמת לאחד מהפורמטים שצוינו בקובץ android.content.res.Configuration.keyboard‏[Resources, 24] (כלומר, QWERTY או 12 מפתחות)

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

הטמעות במכשירים:

  • יכול להיות שיוחמצו אפשרויות ניווט ללא מגע (כלומר, יכול להיות שיוחמצו טרקר-בול, משטח D או גלגלת)
  • חובה לדווח על הערך הנכון של android.content.res.Configuration.navigation‏ [Resources, 24]

8.4. כיוון מסך

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

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

8.5. קלט במסך מגע

הטמעות במכשירים:

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

8.6. USB

הטמעות במכשירים:

  • חובה להטמיע לקוח USB שניתן לחבר למארח USB באמצעות יציאת USB-A רגילה
  • חובה להטמיע את Android Debug Bridge דרך USB (כפי שמתואר בקטע 7)
  • חובה להטמיע את מפרט האחסון בנפח גדול של USB, כדי לאפשר למארח שמחובר למכשיר לגשת לתוכן של נפח האחסון ‎ /sdcard
  • צריך להשתמש בפורמט micro USB בצד המכשיר
  • יכול להיות שיכלול יציאה לא סטנדרטית בצד המכשיר, אבל אם כן, חובה לשלוח אותו עם כבל שיכול לחבר את היציאה בהתאמה אישית ליציאת USB-A רגילה

8.7. מקשי ניווט

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

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

8.8. Wireless Data Networking

הטמעות של מכשירים חייבות לכלול תמיכה ברשתות נתונים אלחוטיות במהירות גבוהה. באופן ספציפי, הטמעות של מכשירים חייבות לכלול תמיכה לפחות בתקן נתונים אלחוטי אחד עם קצב העברה של 200Kbit/sec או יותר. דוגמאות לטכנולוגיות שעומדות בדרישות האלה כוללות EDGE,‏ HSPA,‏ EV-DO,‏ 802.11g וכו'.

אם הטמעה של מכשיר כוללת מודל מסוים ש-Android SDK כולל עבורו ממשק API (כלומר, WiFi,‏ GSM או CDMA), ההטמעה חייבת לתמוך ב-API.

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

8.9. מצלמה

הטמעות של מכשירים חייבות לכלול מצלמה. המצלמה הכלולה:

  • חייבת להיות לה רזולוציה של לפחות 2 מגה-פיקסלים
  • צריכה להיות הטמעה של התכונה 'מיקוד אוטומטי בחומרה' או 'מיקוד אוטומטי בתוכנה' במנהל המצלמה (שקופה לתוכנת האפליקציה)
  • יכול להיות שיש להם חומרה עם מיקוד קבוע או חומרה עם EDOF (עומק שדה מורחב)
  • יכול להיות שיכלול הבזק. אם המצלמה כוללת פלאש, אסור שהנורה של הפלאש תידלק בזמן שמופיעה מופע של android.hardware.Camera.PreviewCallback על פני השטח של תצוגה מקדימה של המצלמה, אלא אם האפליקציה הפעלה את הפלאש באופן מפורש על ידי הפעלת המאפיינים FLASH_MODE_AUTO או FLASH_MODE_ON של אובייקט Camera.Parameters. חשוב לדעת שהאילוץ הזה לא חל על אפליקציית המצלמה המובנית של המכשיר, אלא רק על אפליקציות צד שלישי שמשתמשות ב-Camera.PreviewCallback.

הטמעות של מכשירים חייבות ליישם את ההתנהגויות הבאות לממשקי ה-API שקשורים למצלמה:

  1. אם אפליקציה אף פעם לא התקשרה ל-android.hardware.Camera.Parameters.setPreviewFormat(int), המכשיר חייב להשתמש ב-android.hardware.PixelFormat.YCbCr_420_SP לנתוני התצוגה המקדימה שסופקו ל-callbacks של האפליקציה.
  2. אם אפליקציה רושמת מופע של android.hardware.Camera.PreviewCallback והמערכת קוראת ל-method onPreviewFrame() כשפורמט התצוגה המקדימה הוא YCbCr_420_SP, הנתונים ב-byte[] ‎ שמועברים ל-onPreviewFrame()‎ חייבים להיות בפורמט הקידוד NV21. (זהו הפורמט שבו נעשה שימוש באופן מקורי במשפחת החומרה 7k). כלומר, NV21 חייב להיות ברירת המחדל.

הטמעות במכשירים חייבות ליישם את Camera API המלא שכלול במסמכי התיעוד של Android 2.1 SDK‏ [משאבים, 26], ללא קשר לכך שהמכשיר כולל פוקוס אוטומטי בחומרה או יכולות אחרות. לדוגמה, מצלמות ללא מיקוד אוטומטי עדיין חייבות לקרוא לכל המכונות הרשמות של android.hardware.Camera.AutoFocusCallback (למרות שאין לכך רלוונטיות למצלמה ללא מיקוד אוטומטי).

הטמעות של מכשירים חייבות לזהות כל שם פרמטר שמוגדר כקבוע במחלקה android.hardware.Camera.Parameters ולכבד אותו, אם החומרה הבסיסית תומכת בתכונה. אם חומרת המכשיר לא תומכת בתכונה מסוימת, ה-API צריך לפעול כפי שמתואר במסמכים. לעומת זאת, בהטמעות של מכשירים אסור לכבד או לזהות ערכי קבועים של מחרוזות שמועברים לשיטה android.hardware.Camera.setParameters(), מלבד אלה שתועדו כקבועים ב-android.hardware.Camera.Parameters, אלא אם מופיעה לפני הקבועים מחרוזת שמציינת את שם המטמיע של המכשיר. כלומר, הטמעות של מכשירים חייבות לתמוך בכל הפרמטרים הרגילים של המצלמה אם החומרה מאפשרת זאת, אסור להן לתמוך בסוגי פרמטרים מותאמים אישית של מצלמה, אלא אם שמות הפרמטרים מצוינים בבירור באמצעות קידומת מחרוזת כפרמטרים לא רגילים.

8.10. מד תאוצה

הטמעות במכשירים חייבות לכלול תאוצה תלת-ציונית, והן חייבות להיות מסוגלות לשלוח אירועים בתדר של 50Hz או יותר. מערכת הקואורדינטות שבה נעשה שימוש ב-accelerometer חייבת להיות תואמת למערכת הקואורדינטות של חיישן Android כפי שמפורט בממשקי ה-API של Android (ראו [מקורות מידע, 27]).

8.11. מצפן

הטמעות במכשירים חייבות לכלול מצפן 3-צירי, והן חייבות להיות מסוגלות לשלוח אירועים בתדירות של 10Hz או יותר. מערכת הקואורדינטות שבה משתמש מצפן חייבת להיות תואמת למערכת הקואורדינטות של חיישן Android כפי שהוגדרה ב-Android API (ראו [מקורות מידע, 27]).

8.12. GPS

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

8.13. טלפוניה

אפשר להשתמש ב-Android 2.1 במכשירים שלא כוללים חומרה של טלפוניה. כלומר, Android 2.1 תואם למכשירים שאינם טלפונים. עם זאת, אם הטמעת המכשיר כוללת טלפון GSM או CDMA, חובה להטמיע את התמיכה המלאה ב-API של הטכנולוגיה הזו. הטמעות במכשירים שלא כוללות חומרה של טלפוניה חייבות ליישם את ממשקי ה-API המלאים כ-no-ops.

אפשר לעיין גם בקטע 8.8, 'רשתות נתונים אלחוטיות'.

8.14. זיכרון ואחסון

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

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

הערה: הקטע הזה שונה על ידי Erratum EX6580.

8.15. אחסון משותף של אפליקציות

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

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

בהטמעות של מכשירים חובה לאכוף את ההרשאה android.permission.WRITE_EXTERNAL_STORAGE באחסון המשותף הזה, כפי שמופיע במסמכים. אחרת, כל אפליקציה שתקבל את ההרשאה הזו תוכל לכתוב באחסון המשותף.

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

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

כדאי להביא שתי דוגמאות נפוצות. אם הטמעת המכשיר כוללת חריץ לכרטיס SD כדי לעמוד בדרישת האחסון המשותף, חובה לכלול במכשיר כרטיס SD בנפח 2GB או יותר בפורמט FAT, כפי שהוא נמכר למשתמשים, וחובה לחבר אותו כברירת מחדל. לחלופין, אם הטמעת המכשיר משתמשת באחסון פנימי קבוע כדי לעמוד בדרישות האלה, נפח האחסון חייב להיות 2GB או יותר, והוא חייב להיות מותקן ב-/sdcard (או ש-/sdcard חייב להיות קישור סמלי למיקום הפיזי אם הוא מותקן במקום אחר).

הערה: הקטע הזה נוסף על ידי תיקון שגיאה EX6580.

8.16. Bluetooth

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

הערה: הקטע הזה נוסף על ידי תיקון שגיאה EX6580.

9. תאימות לביצועים

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

מדד סף ביצועים תגובות
שעת ההשקה של האפליקציה האפליקציות הבאות אמורות להשיק בזמן שצוין.
  • דפדפן: פחות מ-1,300 אלפיות שנייה
  • MMS/SMS: פחות מ-700 אלפיות השנייה
  • AlarmClock: פחות מ-650 אלפיות השנייה
 זמן ההפעלה נמדד כזמן הכולל לטעינת פעילות ברירת המחדל של האפליקציה, כולל הזמן שנדרש להפעלת תהליך Linux, לטעינת חבילת Android במכונה הווירטואלית של Dalvik ולקריאה ל-onCreate.
בקשות בו-זמניות כשמפעילים כמה אפליקציות, הפעלה מחדש של אפליקציה שכבר פועלת צריכה להימשך פחות מזמן ההפעלה המקורי.  

10. תאימות של מודל האבטחה

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

10.1. הרשאות

הטמעות במכשירים חייבות לתמוך במודל ההרשאות של Android כפי שמוגדר במסמכי התיעוד למפתחים של Android‏ [משאבים, 28]. באופן ספציפי, ההטמעות חייבות לאכוף כל הרשאה שמוגדרת כפי שמתואר במסמכי התיעוד של ה-SDK. אסור להשמיט, לשנות או להתעלם מהרשאות. אפשר להוסיף הרשאות נוספות להטמעות, בתנאי שמחרוזות מזהה ההרשאה החדשות לא נמצאות במרחב השמות android.*.

10.2. בידוד של UID ותהליכים

הטמעות במכשירים חייבות לתמוך במודל של ארגז החול לאפליקציות ב-Android, שבו כל אפליקציה פועלת בתור UID ייחודי בסגנון Unix ובתהליך נפרד. הטמעות של מכשירים חייבות לתמוך בהפעלת כמה אפליקציות באותו מזהה משתמש ב-Linux, בתנאי שהאפליקציות נוצרו ונחתמו כראוי, כפי שמוגדר במסמך העזרה בנושא אבטחה והרשאות [משאבים, 28].

10.3. הרשאות למערכת הקבצים

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

11. חבילה לבדיקות תאימות (CTS)

הטמעות של מכשירים חייבות לעבור את Android Compatibility Test Suite‏ (CTS)‏[מקורות מידע, 2] שזמין בפרויקט Android Open Source, באמצעות תוכנת האספקה הסופית במכשיר. בנוסף, למטמיעים של מכשירים מומלץ להשתמש בהטמעת העזר ב-Android Open Source Tree ככל האפשר, וחובה להבטיח תאימות במקרים של עמימות ב-CTS ובכל הטמעה מחדש של חלקים מקוד המקור של העזר.

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

12. תוכנה שניתן לעדכן

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

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

  • הורדות Over-the-air (OTA) עם עדכון אופליין באמצעות הפעלה מחדש
  • עדכונים 'מחוברים' בחיבור USB ממחשב מארח
  • עדכונים 'אופליין' באמצעות הפעלה מחדש ועדכון מקובץ באחסון נשלף

מנגנון העדכון שבו נעשה שימוש חייב לתמוך בעדכונים בלי למחוק את נתוני המשתמשים. שימו לב שתוכנת Android ב-upstream כוללת מנגנון עדכון שעומד בדרישות האלה.

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

13. יצירת קשר

אפשר לפנות למחברים של המסמך בכתובת compatibility@android.com כדי לקבל הבהרות ולדווח על בעיות שלא מופיעות במסמך.