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

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

זכויות יוצרים © 2010, Google Inc. כל הזכויות שמורות.
[email protected]

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

1. מבוא

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

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

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

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

• חייבים לעמוד בדרישות שמפורטות בהגדרת התאימות הזו, כולל מסמכים שמשולבים באמצעות הפניה.
• חייב לעבור את הגרסה האחרונה של 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/docs/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.2: http://source.android.com/docs/compatibility/2.2/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. מנהל החיפוש: 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. רשימת תכונות החומרה של Android: http://developer.android.com/reference/android/content/pm/PackageManager.html
24. תמיכה במספר מסכים: http://developer.android.com/guide/practices/screens_support.html
25. android.content.res.Configuration: ‏ http://developer.android.com/reference/android/content/res/Configuration.html
26. android.util.DisplayMetrics: ‏ http://developer.android.com/reference/android/util/DisplayMetrics.html
27. android.hardware.Camera: ‏ http://developer.android.com/reference/android/hardware/Camera.html
28. מרחב קואורדינטות של חיישן: http://developer.android.com/reference/android/hardware/SensorEvent.html
29. מידע על אבטחה והרשאות ב-Android: http://developer.android.com/guide/topics/security/security.html
30. Bluetooth API: ‏ http://developer.android.com/reference/android/bluetooth/package-summary.html

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

3. תוכנות

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

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

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

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

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

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

3.2.1. הרשאות

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

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

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

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 שמצוין בקטע 3.2.3.1. הפרויקט של Android בקוד פתוח מאפשר זאת כברירת מחדל. אלה שמטמיעים את המכשיר אסור להם לצרף הרשאות מיוחדות לשימוש של אפליקציות המערכת בדפוסי ה-Intent האלה, או למנוע מאפליקציות צד שלישי לקשר את הדפוסים האלה ולשלוט בהם. האיסור הזה כולל, בין היתר, השבתה של ממשק המשתמש 'בורר' שמאפשר למשתמש לבחור בין כמה אפליקציות שמטפלות באותו דפוס Intent.

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 נוספים.

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

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

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

3.4.1. תאימות ל-WebView

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

• הטמעות android.webkit.WebView של מכשירים חייבות להתבסס על גרסה 533.1 של WebKit מהעץ של Android Open Source ב-upstream עבור Android 2.2. הגרסה הזו כוללת קבוצה ספציפית של תיקוני אבטחה ופונקציות ל-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, במטמון האפליקציה ובממשקי ה-API למיקום גיאוגרפי [מקורות מידע, 9]. WebView חייב לכלול תמיכה בתג <video> של HTML5. ממשקי API של HTML5, כמו כל ממשקי ה-API של JavaScript, חייבים להיות מושבתים כברירת מחדל ב-WebView, אלא אם המפתח מפעיל אותם במפורש באמצעות ממשקי ה-API הרגילים של Android.

3.4.2. תאימות לדפדפנים

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

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

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

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. עם זאת, מערכות התראות חלופיות כאלה חייבות לתמוך במשאבי התראות קיימים, כפי שמתואר למעלה.

3.8.3. חיפוש

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].
• Replica Island (זמין ב-Android Market, נדרש רק להטמעות במכשירים שתומכים ב-OpenGL ES 2.0)

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

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

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

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

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

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

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

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

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

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

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

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

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

6.2. הקלטת אודיו

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

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

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

6.3. זמן אחזור אודיו (audio latency)

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

למטרות הקטע הזה:

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

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

• זמן אחזור של פלט במצב התחלתי (cold) של 100 אלפיות השנייה או פחות
• זמן אחזור של פלט במצב ביניים (warm) של 10 אלפיות השנייה או פחות
• זמן אחזור רציף של הפלט של 45 אלפיות השנייה או פחות
• זמן אחזור של קלט קר של 100 אלפיות השנייה או פחות
• זמן אחזור רציף של קלט של 50 אלפיות השנייה או פחות

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

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.2 חייבים לתמוך בהן.

אם מכשיר כולל רכיב חומרה מסוים שיש לו ממשק 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. [Resources, 23]

8.1. תצוגה

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

ב-Android 2.2, אלה הגדרות המסך הנפוצות ביותר:

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

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

• בהטמעות של מכשירים, חייבים לפרש משאבים בקובץ APK ללא מגדיר צפיפות כ'בינוני' כברירת מחדל (נקרא 'mdpi' במסמכי התיעוד של ה-SDK).
• כשעובדים במסך עם צפיפות 'נמוכה', בהטמעות במכשירים חובה לשנות את הגודל של נכסים בגודל בינוני/mdpi לפי גורם של 0.75.
• כשעובדים במסך עם דחיסות 'גבוהה', בהטמעות במכשירים חובה להגדיל את הנכסים בגודל בינוני/mdpi פי 1.5.
• אסור לשנות את קנה המידה של נכסים בטווח צפיפות, וצריך לשנות את קנה המידה של נכסים לפי הגורמים האלה בדיוק בין טווחי הצפיפות.

8.1.2. הגדרות תצוגה לא סטנדרטיות

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

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

8.1.3. מדדי רשת המדיה

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

8.1.4. תמיכה בפורמט מסך שצוין

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

8.2. מקלדת

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

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

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

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

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

8.4. כיוון מסך

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

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

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

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

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

8.6. USB

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

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

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.2 SDK‏ [משאבים, 27], ללא קשר לכך שהמכשיר כולל פוקוס אוטומטי בחומרה או יכולות אחרות. לדוגמה, מצלמות ללא מיקוד אוטומטי עדיין חייבות לקרוא לכל המכונות הרשמות של android.hardware.Camera.AutoFocusCallback (למרות שאין לכך רלוונטיות למצלמה ללא מיקוד אוטומטי).

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

הטמעות של מכשירים עשויות לכלול מצלמה קדמית. עם זאת, אם הטמעה של מכשיר כוללת מצלמה קדמית, אסור ש-API המצלמה כפי שהוא מוטמע במכשיר ישתמש במצלמה הקדמית כברירת מחדל. כלומר, ממשק ה-API של המצלמה ב-Android 2.2 מיועד למצלמות אחוריות בלבד, ואי אפשר להשתמש בו שוב או להעמיס עליו עומס כדי לפעול במצלמה קדמית, אם יש כזו. לתשומת ליבכם: כל ממשקי ה-API בהתאמה אישית שנוספו על ידי מפתחי המכשירים כדי לתמוך במצלמות קדמיות חייבים לעמוד בדרישות שמפורטות בסעיפים 3.5 ו-3.6. לדוגמה, אם סיפקו תת-סוג android.hardware.Camera או Camera.Parameters בהתאמה אישית כדי לתמוך במצלמות קדמיות, אסור שהוא יהיה ממוקם במרחב שמות קיים, כפי שמתואר בסעיפים 3.5 ו-3.6. חשוב לזכור ששילוב מצלמה קדמית לא עומד בדרישות של מכשירי טלפוניה שכוללים מצלמה אחורית.

8.10. מד תאוצה

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

8.11. מצפן

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

8.12. GPS

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

8.13. טלפוניה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.16. Bluetooth

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

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

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

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

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

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

10.1. הרשאות

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

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

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

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

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

10.4. סביבות הפעלה חלופיות

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

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

אסור להעניק לממשקי זמן ריצה חלופיים גישה למשאבים שמוגנים באמצעות הרשאות שלא נשלחו בבקשה בקובץ AndroidManifest.xml של סביבת זמן הריצה, באמצעות המנגנון <uses-permission>.

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

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

• בסביבות זמן ריצה חלופיות, צריך להתקין אפליקציות דרך PackageManager בסביבות חול נפרדות של Android (כלומר, מזהי משתמשים ב-Linux וכו').
• סביבות זמן ריצה חלופיות עשויות לספק ארגז חול אחד של Android שכל האפליקציות שמשתמשות בסביבת זמן הריצה החלופית משתתפות בו.
• אסור להשתמש שוב ב-sandbox של אפליקציה אחרת שמותקנת במכשיר, אלא באמצעות המנגנונים הרגילים של Android לזיהוי משתמש משותף ולאישור חתימה, בזמן ריצה חלופי ובאפליקציות שמותקנות באמצעות זמן ריצה חלופי.
• אסור להפעיל סביבות זמן ריצה חלופיות עם גישה לקופסאות החול התואמות לאפליקציות אחרות של Android, או להעניק להן גישה לקופסאות החול האלה, או לקבל גישה מהן.

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

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

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

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

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

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

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

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

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

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

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

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

13. יצירת קשר

אפשר לפנות למחברים של המסמך בכתובת [email protected] כדי לקבל הבהרות ולדווח על בעיות שלא מופיעות במסמך.

נספח א' – תהליך הבדיקה של Bluetooth

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

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

• הטמעה של מכשיר מתאים שבו פועל build התוכנה שרוצים לבדוק
• הטמעה נפרדת של מכשיר שכבר ידוע שהיא תואמת, ודגם שונה מהטמעת המכשיר שנבדקת – כלומר, הטמעת מכשיר 'מוכרת ותקינה'

בתהליך הבדיקה שמתואר בהמשך, המכשירים האלה נקראים 'מכשיר נבדק' ו'מכשיר תקין', בהתאמה.

הגדרה והתקנה

1. יצירת BluetoothChat.apk באמצעות 'make samples' מעץ של קוד מקור של Android.
2. מתקינים את BluetoothChat.apk במכשיר שפועל כמו שצריך.
3. מתקינים את BluetoothChat.apk במכשיר הנבחר.

בדיקת השליטה ב-Bluetooth באמצעות אפליקציות

1. מריצים את BluetoothChat במכשיר הרצוי, כש-Bluetooth מושבת.
2. מוודאים שהמכשיר המועמד מפעיל את ה-Bluetooth או מציג למשתמש תיבת דו-שיח עם בקשה להפעיל את ה-Bluetooth.

בדיקת ההתאמה והתקשורת

1. מפעילים את אפליקציית Bluetooth Chat בשני המכשירים.
2. מגדירים את המכשיר הידוע כתקין כגלוי מתוך BluetoothChat (באמצעות התפריט).
3. במכשיר הרצוי, סורקים מכשירי Bluetooth מתוך BluetoothChat (באמצעות התפריט) ומתאימים אותו למכשיר הידוע כתקין.
4. שולחים 10 הודעות או יותר מכל מכשיר ומוודאים שהמכשיר השני מקבל אותן בצורה תקינה.
5. סוגרים את אפליקציית BluetoothChat בשני המכשירים על ידי לחיצה על דף הבית.
6. מבטלים את ההתאמה של כל מכשיר למכשיר השני באמצעות אפליקציית ההגדרות של המכשיר.

בדיקת ההתאמה והתקשורת בכיוון ההפוך

1. מפעילים את אפליקציית Bluetooth Chat בשני המכשירים.
2. מגדירים את המכשיר הרצוי כגלוי מתוך BluetoothChat (באמצעות התפריט).
3. במכשיר הידוע כתקין, סורקים מכשירי Bluetooth מתוך BluetoothChat (באמצעות התפריט) ומתאימים את המכשיר הרצוי.
4. שולחים 10 הודעות מכל מכשיר ומוודאים שהמכשיר השני מקבל אותן בצורה תקינה.
5. סוגרים את אפליקציית Bluetooth Chat בשני המכשירים על ידי לחיצה חוזרת על לחצן החזרה אחורה עד שמגיעים למרכז האפליקציות.

בדיקת השקות מחדש

1. מפעילים מחדש את אפליקציית Bluetooth Chat בשני המכשירים.
2. שולחים 10 הודעות מכל מכשיר ומוודאים שהמכשיר השני מקבל אותן בצורה תקינה.

הערה: בבדיקות שלמעלה יש מקרים שבהם הקטע מסתיים באמצעות לחיצה על 'דף הבית', ובמקרים אחרים באמצעות לחיצה על 'הקודם'. הבדיקות האלה לא הן מיותרות או אופציונליות: המטרה היא לוודא ש-Bluetooth API והמקבץ פועלים בצורה תקינה גם כשפעילויות מסתיימות באופן מפורש (כשהמשתמש לוחץ על 'הקודם', שמפעיל את finish()) וגם כשהן נשלחות באופן משתמע לרקע (כשהמשתמש לוחץ על 'דף הבית'). חובה לבצע כל רצף בדיקות כפי שמתואר.