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

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

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

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

1. מבוא

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

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

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

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

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

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

2. משאבים

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

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

3. תוכנות

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

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

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

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

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

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

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

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.3, השדה הזה חייב לכלול את הערך המספרי 9.
android.os.Build.VERSION.INCREMENTAL	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמציין את ה-build הספציפי של מערכת Android שפועלת כרגע, בפורמט שקריא לבני אדם. אסור להשתמש שוב בערך הזה לגרסאות build שונות שזמינות למשתמשי הקצה. שימוש נפוץ בשדה הזה הוא לציין את מספר ה-build או את מזהה השינוי במערכת בקרת הגרסאות ששימשו ליצירת ה-build. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
android.os.Build.BOARD	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את החומרה הפנימית הספציפית שבה המכשיר משתמש, בפורמט שקריא לבני אדם. אפשר להשתמש בשדה הזה כדי לציין את הגרסה הספציפית של הלוח שמפעיל את המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי "^[a-zA-Z0-9.,_-]+$".
android.os.Build.BRAND	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את שם החברה, הארגון, האדם וכו' שייצרו את המכשיר, בפורמט שאפשר לקרוא על ידי בני אדם. אפשר להשתמש בשדה הזה כדי לציין את יצרן הציוד המקורי ו/או את הספק שמוכר את המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי "^[a-zA-Z0-9.,_-]+$".
android.os.Build.DEVICE	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את ההגדרה הספציפית או את הגרסה של המארז (שנקרא לפעמים 'עיצוב תעשייתי') של המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט, ולהתאים לביטוי הרגולרי "^[a-zA-Z0-9.,_-]+$".
android.os.Build.FINGERPRINT	מחרוזת שמזהה באופן ייחודי את ה-build הזה. הוא אמור להיות קריא למדי לאדם. הוא חייב לפעול לפי התבנית הבאה: $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) לדוגמה: acme/mydevice/generic/generic:2.3/ERC77/3359:userdebug/test-keys אסור לטביעת האצבע לכלול תווים של רווח לבן. אם יש תווים של רווח לבן בשדות אחרים שכלולים בתבנית שלמעלה, חובה להחליף אותם באצבע המזהה של ה-build בתווית אחרת, כמו קו תחתון (‎'_'). הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט.
android.os.Build.HOST	מחרוזת שמזהה באופן ייחודי את המארח שבו נוצר ה-build, בפורמט שאפשר לקרוא אותו. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
android.os.Build.ID	מזהה שנבחר על ידי מי שמטמיע את המכשיר כדי להפנות למהדורה ספציפית, בפורמט קריא לבני אדם. השדה הזה יכול להיות זהה ל-android.os.Build.VERSION.INCREMENTAL, אבל כדאי להגדיר בו ערך משמעותי מספיק כדי שמשתמשי הקצה יוכלו להבחין בין גרסאות build של תוכנה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי "^[a-zA-Z0-9.,_-]+$".
android.os.Build.MODEL	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם המכשיר כפי שהוא ידוע למשתמש הקצה. השם הזה אמור להיות זהה לשם שתחתיו המכשיר משווק ונמכר למשתמשי קצה. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או מחרוזת ריקה ("").
android.os.Build.PRODUCT	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם הפיתוח או שם הקוד של המכשיר. חובה שיהיו קריאים לבני אדם, אבל הם לא מיועדים בהכרח לצפייה על ידי משתמשי קצה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי "^[a-zA-Z0-9.,_-]+$".
android.os.Build.TAGS	רשימה של תגים מופרדים בפסיקים שנבחרו על ידי מי שמטמיע את המכשיר, שמאפשרת להבדיל בין גרסאות build שונות. לדוגמה, ‎"unsigned,debug"‎. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי "^[a-zA-Z0-9.,_-]+$".
android.os.Build.TIME	ערך שמייצג את חותמת הזמן של מועד ה-build.
android.os.Build.TYPE	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמציין את הגדרת סביבת זמן הריצה של ה-build. השדה הזה צריך לכלול אחד מהערכים שתואמים לשלושת ההגדרות הנפוצות של Android בסביבת זמן הריצה: 'user',‏ 'userdebug' או 'eng'. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי "^[a-zA-Z0-9.,_-]+$".
android.os.Build.USER	שם או מזהה משתמש של המשתמש (או המשתמש האוטומטי) שיצר את ה-build. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").

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

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

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

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

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

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

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

אפליקציות הליבה של מערכת 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 שעבר הידור לארכיטקטורת החומרה המתאימה של המכשיר. מאחר שקוד Native תלוי מאוד בטכנולוגיית המעבד הבסיסית, מערכת Android מגדירה מספר ממשקי Application Binary Interface ‏ (ABI) ב-Android NDK, בקובץ docs/CPU-ARCH-ABIS.txt. אם הטמעה של מכשיר תואמת ל-ABI אחד או יותר שהוגדרו, צריך להטמיע תאימות ל-Android NDK, כפי שמתואר בהמשך.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 מותאמים אישית מחוץ למרחב השמות הרגיל של Android, חובה לארוז את ממשקי ה-API האלה בספרייה משותפת של Android, כך שרק אפליקציות שמשתמשות בהם באופן מפורש (באמצעות המנגנון <uses-library>) יושפעו מהשימוש המוגבר בזיכרון של ממשקי ה-API האלה.

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

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

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

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

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

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

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

3.8.1. ווידג'טים

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

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

3.8.2. התראות

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

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

3.8.3. חיפוש

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אודיו
	שם	פרטים	פורמט הקובץ/אמצעי האחסון
	AAC LC/LTP	תוכן מונו/סטריאו בכל שילוב של שיעורי ביט רגילים של עד 160kbps ותדירות דגימה של 8 עד 48kHz	3GPP‏ (‎.3gp) ו-MPEG-4‏ (‎.mp4,‏ ‎.m4a). אין תמיכה ב-AAC גולמי (‎.aac)
	HE-AACv1‏ (AAC+)
	HE-AACv2‏ (enhanced AAC+)
	AMR-NB	4.75 עד 12.2kbps דגימה ב-8kHz	3GPP‏ (‎.3gp)
	AMR-WB	9 שיעורי דגימה מ-6.60kbit/s עד 23.85kbit/s, בתדירות דגימה של 16kHz	3GPP‏ (‎.3gp)
	MP3	מונו/סטריאו 8-320Kbps קבוע (CBR) או קצב העברת נתונים משתנה (VBR)	MP3‏ (‎.mp3)
	MIDI	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		Ogg‏ (‎.ogg)
	PCM	PCM לינאריים של 8 ו-16 ביט (שיעורים עד למגבלה של החומרה)	WAVE‏ (‎.wav)
תמונה
	JPEG	base+progressive
	GIF
	PNG
	BMP
סרטון
	H.263		קובצי 3GPP‏ (‎.3gp)
	H.264		קובצי 3GPP‏ (‎.3gp) ו-MPEG-4‏ (‎.mp4)
	MPEG4 Simple Profile		קובץ 3GPP‏ (‎.3gp)

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

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

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

אודיו
	שם	פרטים	פורמט הקובץ/אמצעי האחסון	תנאים
	AMR-NB	4.75 עד 12.2kbps דגימה ב-8kHz	3GPP‏ (‎.3gp)	הטמעות של מכשירים שכוללות חומרת מיקרופון ומגדירות את android.hardware.microphone חייבות לכלול מקודדים לפורמטים האלה של אודיו.
	AMR-WB	9 שיעורי דגימה מ-6.60kbit/s עד 23.85kbit/s, בתדירות דגימה של 16kHz	3GPP‏ (‎.3gp)
	AAC LC/LTP	תוכן מונו/סטריאו בכל שילוב של שיעורי ביט רגילים של עד 160kbps ותדירות דגימה של 8 עד 48kHz	3GPP‏ (‎.3gp) ו-MPEG-4‏ (‎.mp4,‏ ‎.m4a).
תמונה	JPEG	base+progressive		כל הטמעות המכשירים חייבות לכלול מקודדים לפורמטים האלה של תמונות, כי גרסת Android 2.3 כוללת ממשקי API שבהם אפליקציות יכולות להשתמש כדי ליצור באופן פרוגרמטי קבצים מהסוגים האלה.
	PNG
סרטון	H.263		קובצי 3GPP‏ (‎.3gp)	הטמעות של מכשירים שכוללות חומרה של מצלמה ומגדירות את android.hardware.camera או את android.hardware.camera.front חייבות לכלול מקודדים לפורמטים האלה של וידאו.

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

5.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.3, אבל בהגדרת התאימות לגרסה עתידית אנחנו מתכננים לשנות אותן ל'חובה'. כלומר, הדרישות האלה הן אופציונליות ב-Android 2.3, אבל יהיו חובה בגרסה עתידית. אנחנו ממליצים מאוד למכשירים קיימים וחדשים עם Android מגרסה 2.3 לעמוד בדרישות האלה ב-Android 2.3, אחרת לא תהיה להם תאימות ל-Android כשהם ישודרגו לגרסה העתידית.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.1.1. הגדרות מסך

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

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

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

היחידות שבהן נעשה שימוש בדרישות שלמעלה מוגדרות כך:

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

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

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

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

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

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

7.1.4. כיוון מסך

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

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

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

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

אפשר להשמיט את התמיכה ב-Open GL ES 2.0 מההטמעות, אבל אם התמיכה מושמטת, אסור להצהיר שההטמעות במכשירים תומכות ב-OpenGL ES 2.0. באופן ספציפי, אם בהטמעות של המכשיר אין תמיכה ב-OpenGL ES 2.0:

• אסור לממשקי ה-API המנוהלים (למשל באמצעות השיטה GLES10.getString()) לדווח על תמיכה ב-OpenGL ES 2.0
• אסור לממשקי ה-API של OpenGL C/C++ (כלומר, אלה שזמינים לאפליקציות דרך libGLES_v1CM.so,‏ libGLES_v2.so או libEGL.so) לדווח על תמיכה ב-OpenGL ES 2.0.

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

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

7.2. התקני קלט

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

7.2.1. מקלדת

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

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

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

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

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

7.2.3. מקשי ניווט

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

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

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

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

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

7.3. חיישנים

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

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

הרשימה שלמעלה לא מקיפה. ההתנהגות המתועדת של Android SDK היא המקור המהימן.

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

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

7.3.1. מד תאוצה

מומלץ לכלול בהטמעות במכשירים מד תאוצה ב-3 צירים. אם הטמעת המכשיר כוללת מד תאוצה ב-3 צירים, הוא:

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

7.3.2. מגנטומטר

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

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

7.3.3. GPS

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

7.3.4. ג'ירוסקופ

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

• חייב להיות מסוגל למדוד שינויים בכיוון עד 5.5*Pi רדיאנים לשנייה (כלומר, כ-1,000 מעלות לשנייה)
• חייבת להיות אפשרות לשלוח אירועים בתדר של 100Hz ומעלה
• חייב להיות דיוק של 8 ביט או יותר

7.3.5. ברומטר

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

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

7.3.7. מדחום

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

7.3.7. פוטומטר

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

7.3.8. חיישן קירבה

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

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

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

7.4.1. טלפוניה

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

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

7.4.2. IEEE 802.11‏ (Wi-Fi)

הטמעות של מכשירי Android מגרסה 2.3 אמורות לכלול תמיכה בפורמט אחד או יותר של 802.11‏ (b/g/a/n וכו') אם הטמעת המכשיר כוללת תמיכה ב-802.11, חובה להטמיע את Android API התואם.

7.4.3. Bluetooth

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

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

7.4.4. תקשורת מטווח קצר

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

• חובה לדווח על התכונה android.hardware.nfc מהשיטה android.content.pm.PackageManager.hasSystemFeature(). [משאבים, 27]
• חייבת להיות לו אפשרות לקרוא ולכתוב הודעות NDEF באמצעות תקני ה-NFC הבאים:
  • חייב להיות מסוגל לפעול כקורא/כותב של NFC Forum (כפי שמוגדר במפרט הטכני של NFC Forum,‏ NFCForum-TS-DigitalProtocol-1.0) באמצעות תקני ה-NFC הבאים:
    • NfcA‏ (ISO14443-3A)
    • NfcB‏ (ISO14443-3B)
    • NfcF‏ (JIS 6319-4)
    • NfcV‏ (ISO 15693)
    • IsoDep‏ (ISO 14443-4)
    • סוגי תגים של NFC Forum מס' 1, 2, 3, 4 (מוגדרים על ידי NFC Forum)
  • חייבת להיות מסוגלת לשדר ולקבל נתונים באמצעות הפרוטוקולים והסטנדרטים הבאים של רשתות עמיתים לעמיתים:
    • ISO 18092
    • LLCP 1.0 (הוגדר על ידי NFC Forum)
    • SDP 1.0 (הוגדר על ידי NFC Forum)
    • פרוטוקול NDEF Push [משאבים, 33]
  • חובה לסרוק את כל הטכנולוגיות הנתמכות במצב גילוי NFC.
  • המכשיר אמור להיות במצב חשיפת NFC כשהמסך פעיל והמכשיר פעיל.

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

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

  • MIFARE Classic‏ (NXP MF1S503x‏ [Resources, 34], ‏ MF1S703x‏ [Resources, 35])
  • MIFARE Ultralight‏ (NXP MF0ICU1‏ [Resources, 36], ‏ MF0ICU2‏ [Resources, 37])
  • NDEF ב-MIFARE Classic‏ (NXP AN130511‏ [מקורות מידע, 38], AN130411‏ [מקורות מידע, 39])

  שימו לב שגרסת Android 2.3.3 כוללת ממשקי API לסוגי MIFARE האלה. אם הטמעת המכשיר תומכת ב-MIFARE, היא:

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

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

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

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

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

  הטמעות של מכשירים שבהם תקן רשת פיזי (כמו Ethernet) הוא חיבור הנתונים הראשי, צריכות לכלול גם תמיכה לפחות בתקן נתונים אלחוטי נפוץ אחד, כמו 802.11‏ (Wi-Fi).

  במכשירים יכולות להיות יותר מסוג אחד של קישוריות נתונים.

  7.5. מצלמות

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

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

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

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

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

  הטמעות של מכשירים עשויות לכלול מצלמה קדמית. אם הטמעה של מכשיר כוללת מצלמה קדמית, היא:

  • חייבת להיות לה רזולוציה של לפחות VGA (כלומר, 640x480 פיקסלים)
  • אסור להשתמש במצלמה קדמית כברירת מחדל ל-Camera API. כלומר, ל-Camera API ב-Android 2.3 יש תמיכה ספציפית במצלמות קדמיות, ואסור להגדיר את ה-API בהטמעות של מכשירים כך שיתייחס למצלמה הקדמית כמצלמה האחורית שמוגדרת כברירת מחדל, גם אם היא המצלמה היחידה במכשיר.
  • יכולות לכלול תכונות (כמו פוקוס אוטומטי, פלאש וכו') שזמינות למצלמות הפונות לאחור, כפי שמתואר בקטע 7.5.1.
  • חובה לשקף אופקית (כלומר להציג בתמונת מראה) את השידור שמוצג באפליקציה ב-CameraPreview, באופן הבא:
  • אם אפשר לסובב את הטלפון במהלך ההטמעה במכשיר (למשל באופן אוטומטי באמצעות תאוצה או באופן ידני באמצעות קלט של המשתמש), חובה להציג את התצוגה המקדימה של המצלמה במראה אופקי ביחס לכיוון הנוכחי של המכשיר.
  • אם האפליקציה הנוכחית ביקשה במפורש שמסך המצלמה יוזז באמצעות קריאה לשיטה android.hardware.Camera.setDisplayOrientation() [Resources, 40], חובה להציג את התצוגה המקדימה של המצלמה במראה אופקי ביחס לכיוון שצוין באפליקציה.
  • אחרת, חובה לשקף את התצוגה המקדימה לאורך הציר האופקי שמוגדר כברירת מחדל במכשיר.
  • חייבים לשקף את נתוני התמונה שמוחזרים לכל פונקציית החזרה (callback) של 'צפייה לאחר מכן' במצלמה, באותו אופן שבו מתבצע שידור התמונה בתצוגה המקדימה של המצלמה. (אם ההטמעה במכשיר לא תומכת בקריאות חזרה לאחר צפייה, ברור שהדרישה הזו לא חלה).
  • אסור לשקף את התמונות הסטטיות או את הסטרימינג של הסרטונים הסופיים שצולמו, שמוחזרים להודעות החזרה (callbacks) של האפליקציה או מועברים לאחסון מדיה

  7.5.3. התנהגות Camera API

  הטמעות של מכשירים חייבות ליישם את ההתנהגויות הבאות לממשקי ה-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. כלומר, NV21 חייב להיות ברירת המחדל.
  3. הטמעות במכשירים אמורות לתמוך בפורמט YV12 (כפי שמצוין בערך הקבוע android.graphics.ImageFormat.YV12) לקליפים מקדמת של המצלמה, גם במצלמה הקדמית וגם במצלמה האחורית. שימו לב שבגרסה עתידית של הגדרת התאימות, הדרישה הזו צפויה להשתנות ל'חובה'. כלומר, תמיכה ב-YV12 היא אופציונלית ב-Android 2.3, אבל תהיה חובה בגרסה עתידית. במכשירים קיימים וחדשים עם Android מגרסה 2.3, מומלץ מאוד לעמוד בדרישות האלה ב-Android 2.3, אחרת לא תהיה אפשרות להשיג תאימות ל-Android כשהם ישודרגו לגרסה העתידית.

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

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

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

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

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

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

  7.6.1. נפח זיכרון ואחסון מינימלי

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

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

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

  ממשקי ה-API של Android כוללים מנהל הורדות שאפליקציות יכולות להשתמש בו כדי להוריד קובצי נתונים. ההטמעה של מנהל ההורדות חייבת לאפשר להוריד קבצים בודדים בגודל 55MB או יותר. ההטמעה של מנהל ההורדות אמורה לאפשר להוריד קבצים בגודל של 100MB או יותר.

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

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

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

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

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

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

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

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

  7.7. USB

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

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

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

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

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

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

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

  9.1. הרשאות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  10. בדיקת תאימות של תוכנות

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

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

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

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

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

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

  10.2. CTS Verifier

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

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

  כל מכשיר וכל גרסה של build חייבים להריץ בצורה תקינה את CTS Verifier, כפי שצוין למעלה. עם זאת, מאחר שגרסאות build רבות דומות מאוד, לא צפוי שמטמיעים של מכשירים יפעלו באופן מפורש את CTS Verifier על גרסאות build ששונות רק בדרכים טריוויאליות. באופן ספציפי, הטמעות של מכשירים ששונות מהטמעה שעברה את CTS Verfier רק במיקומים שונים, בברנדינג וכו', יכולות להשמיט את הבדיקה של CTS Verfier.

  10.3. אפליקציות עזר

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

  • האפליקציות 'אפליקציות ל-Android' [משאבים, 43].
  • Replica Island (זמין ב-Android Market, נדרש רק להטמעות במכשירים שתומכים ב-OpenGL ES 2.0)

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

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

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

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

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

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

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

  12. יצירת קשר

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

  נספח א' – תהליך הבדיקה של 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()) וגם כשהן נשלחות באופן משתמע לרקע (כשהמשתמש לוחץ על 'דף הבית'). חובה לבצע כל רצף בדיקות כפי שמתואר.