החל מ-27 במרץ 2025, מומלץ להשתמש ב-android-latest-release במקום ב-aosp-main כדי ליצור תרומות ל-AOSP. מידע נוסף זמין במאמר שינויים ב-AOSP.

דף זה תורגם על ידי Cloud Translation API.

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

הגדרת תאימות ל-Android: Android 1.6
Android 1.6 r2
Google Inc.
compatibility@android.com

1. מבוא
במסמך הזה מפורטות הדרישות שצריך לעמוד בהן כדי שטלפונים ניידים יהיו
תואמים ל-Android 1.6. ההגדרה הזו מבוססת על היכרות עם תוכנית התאימות של Android
[מקורות מידע, 1].
השימוש במילים 'חובה', 'אסור', 'נדרש', 'חייב', 'אסור', 'צריך', 'לא צריך', 'מומלץ',
'יכול' ו'אופציונלי' הוא בהתאם לתקן IETF שמוגדר ב-RFC2119 [מקורות מידע, 2].
במסמך הזה, "מפתח מכשיר" או "מפתח" הוא אדם או ארגון שמפתחים
פתרון חומרה/תוכנה שפועל עם Android 1.6. 'הטמעה במכשיר' או 'הטמעה' היא
הפתרון לחומרה או לתוכנה שפותח.
כדי להיחשב כתואם ל-Android 1.6, הטמעות במכשירים:
1. חייבים לעמוד בדרישות שמפורטות בהגדרת התאימות הזו, כולל מסמכים
שמשולבים באמצעות הפניה.
2. חובה לעבור את Android Compatibility Test Suite‏ (CTS) שזמין כחלק מפרויקט הקוד הפתוח של Android
[משאבים, 3]. ב-CTS נבדקים רוב הרכיבים שמפורטים במסמך הזה, אבל לא כולם.

אם ההגדרה הזו או ה-CTS לא כוללים מידע, אם הם מעורפלים או חלקיים, האחריות של מממש המכשיר
היא לוודא תאימות להטמעות קיימות. לכן, פרויקט קוד
הפתוח של Android [מקורות, 4] הוא גם ההטמעה המומלצת וגם ההטמעה המקובלת של Android. אנחנו ממליצים מאוד למפתחי
מכשירים לבסס את ההטמעות שלהם על קוד המקור 'במעלה הזרם'
שזמין בפרויקט Android Open Source. תיאורטית, אפשר להחליף רכיבים מסוימים
ביישומים חלופיים, אבל לא מומלץ לעשות זאת כי יהיה קשה יותר
לעבור את בדיקות CTS. באחריות המטמיע להבטיח תאימות התנהגות מלאה ל
הטמעה הרגילה של Android, כולל חבילה לבדיקות תאימות (CTS) ומעבר לה.
2. מקורות מידע
הגדרת התאימות הזו מפנה למספר מקורות מידע שאפשר למצוא כאן.
1. סקירה כללית על תוכנית התאימות של Android: https://sites.google.com/a/android.com/compatibility/
how-it-works
2. רמות הדרישה של IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
3. חבילה לבדיקות תאימות (CTS): http://sites.google.com/a/android.com/compatibility/compatibility-test-
suite--cts
4. פרויקט קוד פתוח של Android: http://source.android.com/
5. הגדרות ומסמכי עזרה של ממשקי API: http://developer.android.com/reference/packages.html
6. ספקי תוכן: http://code.google.com/android/reference/android/provider/package-
summary.html
7. מקורות מידע זמינים: http://code.google.com/android/reference/available-resources.html
8. קבצי מניפסט של Android: http://code.google.com/android/devel/bblocks-manifest.html
9. מידע על הרשאות Android: http://developer.android.com/reference/android/
Manifest.permission.html
10. קבועי build: http://developer.android.com/reference/android/os/Build.html
11. WebView: ‏ http://developer.android.com/reference/android/webkit/WebView.html
12. תוספים לדפדפנים של Gears: http://code.google.com/apis/gears/

13. מפרט של מכונה וירטואלית של Dalvik, שנמצא בספרייה dalvik/docs של קוד מקור
ב-checkout. אפשר למצוא אותו גם בכתובת http://android.git.kernel.org/?p=platform/
dalvik.git;a=tree;f=docs;h=3e2ddbcaf7f370246246f9f03620a7caccbfcb12;hb=HEAD
14. AppWidgets: ‏ http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
15. התראות: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
16. מדריך הסגנון של סמלי שורת הסטטוס: http://developer.android.com/guide/practices/ui_guideline
/icon_design.html#statusbarstructure
17. Search Manager: ‏ http://developer.android.com/reference/android/app/SearchManager.html
18. Toast: ‏ http://developer.android.com/reference/android/widget/Toast.html
19. Apps For Android‏: http://code.google.com/p/apps-for-android
20. תיאור של קובץ APK ל-Android: http://developer.android.com/guide/topics/fundamentals.html
21. ממשק הגישור של Android‏ (adb): http://code.google.com/android/reference/adb.html
22. Dalvik Debug Monitor Service‏ (ddms): http://code.google.com/android/reference/ddms.html
23. Monkey: ‏ http://developer.android.com/guide/developing/tools/monkey.html
24. מסמכי תיעוד בנושא עצמאות מהמסך:
25. קבועי תצורה: http://developer.android.com/reference/android/content/res/
Configuration.html
26. מדדי תצוגה: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. מצלמה: 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
מקורות מידע רבים האלה נגזרים באופן ישיר או עקיף מ-Android 1.6 SDK, והם יהיו
פונקציונלית זהים למידע שמופיע במסמכי התיעוד של ה-SDK הזה. במקרים שבהם
הגדרת התאימות הזו לא תואמת למסמכי התיעוד של ה-SDK, מסמכי התיעוד של ה-SDK נחשבים
למסמכים המהימנים. כל הפרטים הטכניים שסופקו במקורות המידע שצוינו למעלה נחשבים
כחלק מההגדרה הזו של תאימות.
3. תוכנה
פלטפורמת Android כוללת גם קבוצה של ממשקי API מנוהלים ('קשים') וגם גוף של ממשקי API שנקראים 'רכים'
, כמו מערכת Intent, ממשקי API בקוד מקורי וממשקי API לאפליקציות אינטרנט. בקטע הזה מפורטים ממשקי ה-API הקשיחים והרכים
שקשורים באופן אינטגרלי לתאימות, וכן התנהגויות טכניות והתנהגויות אחרות רלוונטיות
בממשק המשתמש. הטמעות של מכשירים חייבות לעמוד בכל הדרישות שמפורטות בקטע הזה.
3.1. תאימות ל-API מנוהל
סביבת הביצוע המנוהלת (מבוססת Dalvik) היא הכלי העיקרי לאפליקציות ל-Android.
ממשק תכנות האפליקציות (API) של Android הוא קבוצת הממשקים של פלטפורמת Android שנחשפים לאפליקציות
שפועלות בסביבת ה-VM המנוהלת. יש לספק ב-Device implementations
יישומים מלאים, כולל כל ההתנהגויות המתועדות, של כל ממשק API מתועד שחשוף על ידי Android
1.6 SDK, כמו:
1. ממשקי API ליבה של Android בשפת Java [Resources, 5].
2. ספקי תוכן [Resources, 6].
3. מקורות מידע [Resources, 7].
4. מאפיינים ואלמנטים של AndroidManifest.xml [משאבים, 8].

אסור להחמיץ הטמעות של ממשקי API מנוהלים, לשנות ממשקי API או חתימות שלהם, לסטות
מההתנהגות המתועדת או לכלול פעולות no-op, אלא אם צוין במפורש אחרת בהגדרת
התאימות הזו.
3.2. תאימות ל-API 'רך'
בנוסף לממשקי ה-API המנוהלים בקטע 3.1, Android כולל גם ממשק API 'רך'
משמעותי שזמין רק בסביבת זמן הריצה, בדמות דברים כמו כוונות (Intents), הרשאות והיבטים דומים של אפליקציות Android
, שלא ניתן לאכוף בזמן הידור האפליקציה. בקטע הזה מפורטים ממשקי ה-API 'הרכים' והתנהגויות המערכת
הנדרשים לתאימות ל-Android 1.6. הטמעות של מכשירים חייבות לעמוד בכל
הדרישות שמפורטות בקטע הזה.
3.2.1. הרשאות
מפתחי המכשירים חייבים לתמוך בכל קבועי ההרשאות ולאכוף אותם, כפי שמתואר ב
דף העזרה בנושא הרשאות [מקורות מידע, 9]. שימו לב שבסעיף 10 מפורטות דרישות נוספות שקשורות
למודל האבטחה של Android.
3.2.2. פרמטרים של build
ממשקי ה-API של Android כוללים מספר קבועים בכיתה android.os.Build‏ [Resources, 10] ש
מיועדים לתאר את המכשיר הנוכחי. כדי לספק ערכים עקביים ומשמעותיים בכל הטמעות
המכשיר, בטבלה הבאה מפורטות הגבלות נוספות על הפורמטים של הערכים האלה, שכל הטמעות
המכשיר חייבות לעמוד בהן.
פרמטר
הערות
הגרסה של מערכת Android שפועלת כרגע, בפורמט שאפשר לקרוא
android.os.Build.VERSION.RELEASE
בני אדם. לגרסה Android 1.6, השדה הזה חייב לכלול את הערך של המחרוזת
"1.6".
גרסת מערכת Android שפועלת כרגע, בפורמט
android.os.Build.VERSION.SDK
שגלוי לקוד של אפליקציות של צד שלישי. ב-Android 1.6, השדה הזה
חייב לכלול את הערך השלם 4.
ערך שנבחר על ידי מי שמטמיע את המכשיר, ומציין את הגרסה הספציפית
של מערכת Android שפועלת כרגע, בפורמט שקריא לבני אדם.
אסור להשתמש שוב בערך הזה לגרסאות build שונות שנשלחות למשתמשי הקצה
android.os.Build.VERSION.INCREMENTAL. השימוש הנפוץ בשדה הזה הוא לציין את מספר ה-build או את מזהה השינוי במערכת בקרת הגרסאות
ששימשו ליצירת ה-build. אין
דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה
שאסור שיהיה null או המחרוזת הריקה ("").
ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את החומרה הפנימית
הספציפית שבה המכשיר משתמש, בפורמט שקריא לבני אדם. אפשר להשתמש בשדה הזה כדי לציין את הגרסה הספציפית של הלוח שמפעיל את המכשיר.
android.os.Build.BOARD

אין דרישות לגבי הפורמט הספציפי של השדה הזה,
חוץ מכך שאסור שהוא יהיה null או מחרוזת ריקה ("").
ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את השם של
android.os.Build.BRAND
החברה, הארגון, האדם הפרטי וכו' שייצרו את המכשיר, ב
פורמט שקריא לבני אדם. אפשר להשתמש בשדה הזה כדי לציין את יצרן הציוד המקורי

ו/או את הספק שמוכר את המכשיר. אין דרישות לגבי
הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת
הריקה ("").
ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את ההגדרה
הספציפית או את הגרסה של הגוף (לפעמים נקרא "עיצוב
android.os.Build.DEVICE
תעשייתי") של המכשיר. אין דרישות לגבי הפורמט הספציפי
של השדה הזה, מלבד העובדה שהוא לא יכול להיות null או המחרוזת הריקה ("").
מחרוזת שמזהה באופן ייחודי את ה-build הזה. הוא אמור להיות
קריא לאנשים. הוא חייב לפעול לפי התבנית הבאה:
$(PRODUCT_BRAND)/$(PRODUCT_NAME)/$(PRODUCT_DEVICE)/
$(TARGET_BOOTLOADER_BOARD_NAME):$(PLATFORM_VERSION)/
$(BUILD_ID)/$(BUILD_NUMBER):$(TARGET_BUILD_VARIANT)/
android.os.Build.FINGERPRINT
$(BUILD_VERSION_TAGS)
לדוגמה: acme/mydevicel/generic/generic:Donut/ERC77/
3359:userdebug/test-keys
אסור לכלול רווחים ב-fingerprint. אם יש רווחים בשדות אחרים שכלולים ב
תבנית שלמעלה, צריך להחליף אותם בתווית הקו התחתון (‎'_') של ASCII
בטביעת האצבע.
מחרוזת שמזהה באופן ייחודי את המארח שבו נוצר ה-build, בפורמט
android.os.Build.HOST
קריא לבני אדם. אין דרישות לגבי הפורמט הספציפי של השדה הזה
, מלבד הדרישה שהוא לא יכול להיות null או מחרוזת ריקה ("").
מזהה שנבחר על ידי מי שמטמיע את המכשיר כדי להפנות למהדורה ספציפית
, בפורמט קריא לבני אדם. השדה הזה יכול להיות זהה ל-
android.os.Build.VERSION.INCREMENTAL, אבל צריך להיות ערך
android.os.Build.ID
שמיועד להיות בעל משמעות מסוימת למשתמשי הקצה. אין
דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא
לא יכול להיות null או מחרוזת ריקה ("").
ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם
המכשיר כפי שהוא ידוע למשתמש הקצה. השם הזה אמור להיות זהה לשם
android.os.Build.MODEL
שמשמש לשיווק המכשיר ולמכירה שלו למשתמשי קצה. אין
דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד העובדה שהוא
אסור להיות null או המחרוזת הריקה ("").
ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם הפיתוח
או שם הקוד של המכשיר. חייב להיות קריא לבני אדם, אבל לא
android.os.Build.PRODUCT
הוא בהכרח מיועד לצפייה על ידי משתמשי קצה. אין דרישות
לגבי הפורמט הספציפי של השדה הזה, מלבד העובדה שהוא לא יכול להיות null או
המחרוזת הריקה ("").
רשימה של תגים מופרדים בפסיקים שנבחרו על ידי מי שמטמיע את המכשיר,
שמאפשרת להבדיל בין גרסאות build שונות. לדוגמה, ‎"unsigned,debug"‎. השדה הזה
android.os.Build.TAGS
אסור שיהיה null או מחרוזת ריקה (""), אבל תג יחיד (כמו
"release") בסדר.
android.os.Build.TIME
ערך שמייצג את חותמת הזמן של מועד ה-build.
ערך שנבחר על ידי מי שמטמיע את המכשיר, שמציין את הגדרת זמן הריצה
של ה-build. בשדה הזה צריך להופיע אחד מהערכים
android.os.Build.TYPE
שתואם לשלוש ההגדרות הנפוצות של סביבת זמן הריצה של Android: "user",
"userdebug" או "eng".
שם או מזהה משתמש של המשתמש (או המשתמש האוטומטי) שיצר את הגרסה המבוססת על
android.os.Build.USER
. אין דרישות לגבי הפורמט הספציפי של השדה הזה,
אלא שאסור שהוא יהיה null או המחרוזת הריקה ("").

3.2.3. תאימות ל-Intent
ב-Android נעשה שימוש ב-Intents כדי להשיג שילוב רופף בין אפליקציות. בקטע הזה מתוארות
הדרישות שקשורות לדפוסי הכוונה, שחייבים לפעול בהתאם להן בהטמעות במכשירים. הכוונה בביטוי
"התגובה תואמת" היא שהמפתח של המכשיר חייב לספק פעילות, שירות או רכיב
אחר ב-Android שמציין מסנן Intent תואם ומקשר להתנהגות הנכונה לכל
דפוס Intent שצוין, ומטמיע אותה.
3.2.3.1. כוונות ליבה של אפליקציות
בפרויקט Android upstream מוגדרות כמה אפליקציות ליבה, כמו חייגן טלפון, יומן,
ספר אנשי קשר, נגן מוזיקה וכו'. למטמיעים של מכשירים מותר להחליף את האפליקציות האלה ב
גרסאות חלופיות.
עם זאת, כל גרסה חלופית כזו חייבת לפעול בהתאם לאותם דפוסי הכוונה שסופקו על ידי הפרויקט
ב-upstream. (לדוגמה, אם מכשיר מכיל נגן מוזיקה חלופי, הוא עדיין צריך לפעול בהתאם לדפוס ה-Intent
שהונפק על ידי אפליקציות של צד שלישי כדי לבחור שיר). הטמעות במכשירים חייבות לתמוך בכל דפוסי הכוונה
שמפורטים בנספח א'.
3.2.3.2. שינוי ברירת המחדל של כוונה
Android היא פלטפורמה ניתנת להרחבה, ולכן למטמיעים של מכשירים חובה לאפשר לאפליקציות צד שלישי לשנות את ברירת המחדל של כל דפוס כוונה שמתואר ב
נספח א'. בפרויקט הקוד הפתוח של Android
מותר לעשות זאת כברירת מחדל. אלה שמטמיעים את המכשירים אסור להם לצרף הרשאות מיוחדות לשימוש של אפליקציות המערכת
בדוגמאות ה-Intent האלה, או למנוע מאפליקציות צד שלישי לקשר את עצמן לדוגמאות האלה ולשלוט בהן
. האיסור הזה כולל באופן ספציפי השבתה של ממשק המשתמש 'בורר', שמאפשר
למשתמש לבחור בין כמה אפליקציות, שכולן מטפלות באותו דפוס Intent.
3.2.3.3. מרחבי שמות של כוונות
מפתחי מכשירים חייבים לא לכלול רכיבי Android שמכבדים דפוסים חדשים של כוונות או
של כוונות שידור באמצעות ACTION,‏ CATEGORY או מחרוזת מפתח אחרת במרחב השמות android.*.
מפתחי מכשירים חייבים לא לכלול רכיבי Android שמכבדים דפוסים חדשים של כוונות או
של כוונות שידור באמצעות ACTION,‏ CATEGORY או מחרוזת מפתח אחרת במרחב חבילה
ששייך לארגון אחר. אסור למטמיעים של מכשירים לשנות או להרחיב אף אחד מהדפוסים של Intent
שמפורטים בנספח א' או ב'.
האיסור הזה דומה לאיסור שצוין לגבי כיתות בשפת 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 ES 1.1
הספריות האלה חייבות להיות תואמות למקור (כלומר תואמות לכותרת) ותואמות לבינארי (לצורך ארכיטקטורת מעבד נתונה) עם הגרסאות שסופקו ב-Bionic על ידי פרויקט Android Open Source.
מכיוון
שהטמעות Bionic לא תואמות באופן מלא להטמעות אחרות, כמו ספריית GNU C
, למטמיעים של מכשירים מומלץ להשתמש בהטמעה של Android. אם מי שמטמיע את המכשיר משתמש ב
הטמעה שונה של הספריות האלה, הוא צריך לוודא את התאימות של הכותרות והקובץ הבינארי.
התאמה לקוד מקורי היא אתגר. לכן, אנחנו רוצים לחזור על ההמלצה
שאנחנו ממליצים מאוד למטמיעים של מכשירים להשתמש בהטמעות של מקורות הקוד של הספריות שצוינו למעלה, כדי
להבטיח תאימות.
3.4. תאימות ל-Web API
מפתחים ואפליקציות רבים מסתמכים על ההתנהגות של הכיתה android.webkit.WebView‏ [מקורות מידע,
11] בממשקי המשתמש שלהם, לכן הטמעת WebView צריכה להיות תואמת לכל הטמעות Android
. בגרסה של Android Open Source נעשה שימוש בגרסה של מנוע הרינדור של WebKit כדי
להטמיע את WebView.
לא ניתן לפתח חבילת בדיקות מקיפה לדפדפן אינטרנט, ולכן למטמיעים של מכשירים
חובה להשתמש ב-build הספציפי של WebKit ב-upstream בהטמעת WebView. באופן ספציפי:
• ב-WebView חייבת להיות גרסה 528.5 ואילך של WebKit מהעץ של Android Open Source ב-upstream עבור
Android 1.6. הגרסה הזו כוללת קבוצה ספציפית של תיקוני פונקציונליות ואבטחה ל-WebView.
• המחרוזת של סוכן המשתמש שמדווחת על ידי WebView חייבת להיות בפורמט הזה:
Mozilla/5.0 (Linux; U; Android 1.6; <language>-<country>; <device
name>; Build/<build ID>) AppleWebKit/528.5+ (KHTML, like Gecko)
Version/3.1.2 Mobile Safari/525.20.1

◦ המחרוזת "<device name>" חייבת להיות זהה לערך של
android.os.Build.MODEL
◦ המחרוזת "<build ID>" חייבת להיות זהה לערך של android.os.Build.ID.
◦ המחרוזות "<language>" ו-"<country>" צריכות לפעול לפי המוסכמות הרגילות של
קוד המדינה והשפה, והן צריכות להתייחס לאזור הגיאוגרפי הנוכחי של המכשיר בזמן
הבקשה.
יכול להיות שהטמעות ישלחו מחרוזת של סוכן משתמש בהתאמה אישית באפליקציית הדפדפן הנפרדת. בנוסף,
הדפדפן העצמאי עשוי להתבסס על טכנולוגיית דפדפן חלופית (כמו Firefox,‏
Opera וכו'). עם זאת, גם אם נשלחת אפליקציית דפדפן חלופית, רכיב ה-WebView
שסופק לאפליקציות של צד שלישי חייב להתבסס על WebKit, כפי שמתואר למעלה.
אפליקציית הדפדפן העצמאית אמורה לכלול תמיכה ב-Gears‏ [מקורות מידע, 12] ויכולה
לכלול תמיכה בחלק מ-HTML5 או בכלו.
3.5. תאימות התנהגות של ממשקי API
התנהגויות של כל אחד מסוגי ה-API (מנוהל, רך, מקומי ואינטרנט) חייבות להיות עקביות עם
ההטמעה המועדפת של Android שזמינה בפרויקט Android Open Source.
תחומי תאימות ספציפיים מסוימים הם:
• אסור למכשירים לשנות את ההתנהגות או את המשמעות של Intent סטנדרטי
• אסור למכשירים לשנות את מחזור החיים או את סמנטיקה של מחזור החיים של סוג מסוים של רכיב
מערכת (כמו Service,‏ Activity,‏ ContentProvider וכו')
• אסור לשנות את הסמנטיקה של הרשאה מסוימת במכשירים
הרשימה שלמעלה לא מקיפה, והאחריות על תאימות ההתנהגות
היא של מי שמטמיע את המכשיר. לכן, כשהדבר אפשרי, למטמיעים של מכשירים מומלץ להשתמש בקוד המקור שזמין דרך
פרויקט Android Open Source, במקום להטמיע מחדש חלקים משמעותיים במערכת.
חבילה לבדיקות תאימות (CTS) בודקת חלקים משמעותיים בפלטפורמה כדי לבדוק את התאימות ההתנהגותית,
אבל לא את כולם. באחריות המטמיע לוודא תאימות התנהגותית לפרויקט הקוד הפתוח של Android
.
3.6. מרחבי שמות של ממשקי API
ב-Android פועלים לפי המוסכמות של מרחבי השמות של החבילות והכיתות שמוגדרות בשפת התכנות Java
. כדי להבטיח תאימות לאפליקציות של צד שלישי, מחשבי המכשיר חייבים לא לבצע
שינויים אסורים (ראו בהמשך) במרחבי השמות של החבילות הבאות:
• java.*
• javax.*
• sun.*
• android.*
• com.android.*
בין השינויים האסורים:
• אסור לבצע שינויים בממשקי ה-API שגלויים לכולם בפלטפורמת Android
באמצעות שינוי חתימות של שיטות או כיתות, או הסרה של כיתות או שדות של כיתות, בהטמעות של מכשירים.

• מפתחי מכשירים יכולים לשנות את ההטמעה הבסיסית של ממשקי ה-API, אבל
שינויים כאלה לא יכולים להשפיע על ההתנהגות המוצהרת ועל החתימה בשפת Java של כל
ממשק API שחשוף לכולם.
• מפתחי המכשירים חייבים לא להוסיף לאינטראקציות ה-API שלמעלה רכיבים שגלויים לכולם (כמו שיעורים או
ממשקים, או שדות או שיטות לשיעורים או לממשקים קיימים).
'אלמנט שחשוף לכולם' הוא כל מבנה שלא מעוטר בסמן '‎@hide' בקובץ המקור של Android
ב-upstream. כלומר, למטמיעים של מכשירים אסור לחשוף ממשקי API חדשים או
לשנות ממשקי API קיימים במרחבי השמות שצוינו למעלה. מפתחי מכשירים יכולים לבצע שינויים פנימיים בלבד
, אבל אסור לפרסם את השינויים האלה או לחשוף אותם למפתחים בדרכים אחרות.
מפתחי מכשירים יכולים להוסיף ממשקי API מותאמים אישית, אבל כל ממשק API כזה אסור שיהיה במרחב שמות שבבעלות
ארגון אחר או שמפנה לארגון אחר. לדוגמה, אסור למטמיעים של מכשירים להוסיף ממשקי API למרחב השמות
com.google.* או למרחב שמות דומה. רק Google רשאית לעשות זאת. באופן דומה, אסור ל-Google להוסיף ממשקי API למרחבי שמות של
חברות אחרות.
אם מי שמטמיע את המכשיר מציע לשפר אחד ממרחב השמות של החבילות שלמעלה (למשל,
הוספת פונקציונליות חדשה ומועילה ל-API קיים או הוספת API חדש), הוא צריך להיכנס לאתר
source.android.com ולהתחיל בתהליך של הוספת שינויים וקוד, בהתאם
למידע באתר הזה.
לתשומת ליבכם: המגבלות שלמעלה תואמות למוסכמות הסטנדרטיות למתן שמות לממשקי API בשפת התכנות Java
. המטרה של הקטע הזה היא פשוט לחזק את המוסכמות האלה ולהפוך אותן למחייבות
באמצעות הכללה בהגדרת התאימות הזו.
3.7. תאימות למכונה וירטואלית
מכשיר Android תואם חייב לתמוך במפרט המלא של קוד בייט של Dalvik Executable‏ (DEX) ובסמנטיקה של
מכונה וירטואלית של Dalvik [מקורות מידע, 13].
3.8. תאימות לממשק המשתמש
פלטפורמת Android כוללת כמה ממשקי API למפתחים שמאפשרים למפתחים להתחבר לממשק המשתמש
של המערכת. הטמעות במכשירים חייבות לכלול את ממשקי ה-API הרגילים האלה לממשקי משתמש בממשקי המשתמש המותאמים אישית
שהם מפתחים, כפי שמוסבר בהמשך.
3.8.1. ווידג'טים
ב-Android מוגדר סוג רכיב, ממשק API ומחזור חיים תואמים שמאפשרים לאפליקציות לחשוף
'AppWidget' למשתמש הקצה [מקורות מידע, 14]. מהדורת העזר של Android Open Source כוללת
אפליקציית מרכז אפליקציות שכוללת רכיבים של ממשק המשתמש שמאפשרים למשתמש להוסיף, להציג ולהסיר
ווידג'טים של אפליקציות ממסך הבית.
מפתחי מכשירים יכולים להחליף את מרכז האפליקציות של הדוגמה (כלומר מסך הבית) במרכז אפליקציות חלופי.
מרכזי אפליקציות חלופיים צריכים לכלול תמיכה מובנית ב-AppWidget, ולהציג רכיבים של ממשק המשתמש
כדי להוסיף, להציג ולהסיר AppWidget ישירות מתוך מרכז האפליקציות. אפשר
להשמיט את רכיבי ממשק המשתמש האלה במרכזי תוכנה חלופיים. עם זאת, אם הם יושמטו, מי שמטמיע את המכשיר חייב לספק
אפליקציה נפרדת שאפשר לגשת אליה ממרכז האפליקציות, ומאפשרת למשתמשים להוסיף, להציג ולהסיר
ווידג'טים של אפליקציות.

3.8.2. התראות
מערכת Android כוללת ממשקי API שמאפשרים למפתחים להודיע למשתמשים על אירועים משמעותיים [מקורות מידע, 15]. מפתחי
מכשירים חייבים לספק תמיכה בכל סוג של התראה כפי שהוגדר, ובפרט: צלילים,
רטט, תאורה וסרגל סטטוס.
בנוסף, ההטמעה חייבת לכלול את כל המשאבים (סמלים, קובצי אודיו וכו')
שסופקו בממשקי ה-API [מקורות מידע, 7], או במדריך הסגנון של סמלי שורת הסטטוס [מקורות מידע, 16]. מפתחי
מכשירים יכולים לספק חוויית משתמש חלופית להתראות, ששונה מזו שסופקת על ידי
ההטמעה של Android Open Source. עם זאת, מערכות התראות חלופיות כאלה חייבות
לתמוך במשאבי התראות קיימים, כפי שמתואר למעלה.
3.8.3. חיפוש
מערכת Android כוללת ממשקי API [מקורות מידע, 17] שמאפשרים למפתחים לשלב חיפוש באפליקציות שלהם,
ולחשוף את נתוני האפליקציה שלהם בחיפוש המערכת הגלובלי. באופן כללי, הפונקציונליות הזו
מורכבת מממשק משתמש יחיד ברמת המערכת שמאפשר למשתמשים להזין שאילתות, מציג הצעות
בזמן שהמשתמשים מקלידים ומציג תוצאות. ממשקי ה-API של Android מאפשרים למפתחים לעשות שימוש חוזר בממשק הזה כדי לספק
חיפוש בתוך האפליקציות שלהם, ומאפשרים למפתחים לספק תוצאות לממשק
המשתמש המשותף של החיפוש הגלובלי.
הטמעות במכשירים חייבות לכלול ממשק משתמש יחיד, משותף וחיפוש ברמת המערכת, שיכול לספק
הצעות בזמן אמת בתגובה לקלט של המשתמש. בהטמעות במכשירים חייבים להטמיע את ממשקי ה-API שמאפשרים למפתחים לעשות שימוש חוזר בממשק המשתמש הזה כדי לספק חיפוש בתוך האפליקציות שלהם.

בהטמעות במכשירים חייבים להטמיע את ממשקי ה-API שמאפשרים לאפליקציות צד שלישי להוסיף הצעות
לתיבת החיפוש כשהיא פועלת במצב חיפוש גלובלי. אם לא מותקנות אפליקציות של צד שלישי
שמשתמשות בפונקציונליות הזו, התנהגות ברירת המחדל אמורה להיות הצגת תוצאות
והצעות של מנוע חיפוש אינטרנט.
יכול להיות שבהטמעות של מכשירים יהיו ממשקי משתמש חלופיים לחיפוש, אבל הן צריכות לכלול לחצן חיפוש ייעודי
פיזי או וירטואלי, שאפשר להשתמש בו בכל שלב באפליקציה כלשהי כדי להפעיל את מסגרת החיפוש,
עם ההתנהגות שמפורטת במסמכי התיעוד של ה-API.
3.8.4. הודעות 'טוסט'
אפליקציות יכולות להשתמש ב-API של 'טוסט' (שמוגדר בקטע [משאבים, 18]) כדי להציג למשתמש
הסופי מחרוזות קצרות לא מודאליות, שנעלמות אחרי פרק זמן קצר. הטמעות במכשירים חייבות להציג הודעות Toast מ
אפליקציות למשתמשים קצה באופן בולט.
4. תאימות של תוכנות עזר
מפתחי המכשירים חייבים לבדוק את תאימות ההטמעה באמצעות האפליקציות הבאות בקוד פתוח:
• מחשבון (כלול ב-SDK)
• Lunar Lander (כלול ב-SDK)
• ApiDemos (כלול ב-SDK)
• האפליקציות של Apps for Android‏ [מקורות מידע, 19]
כל אחת מהאפליקציות שלמעלה חייבת להפעיל ולהתנהג בצורה תקינה בהטמעה, כדי שההטמעה תחשב

כמתאימה.

5. תאימות של אריזת אפליקציות
הטמעות במכשירים חייבות להתקין ולהריץ קובצי ‎.apk של Android כפי שנוצרו על ידי הכלי 'aapt'
שכלול ב-Android SDK הרשמי [מקורות מידע, 20].
אסור להרחיב את ההטמעות במכשירים של הפורמטים ‎ .apk,‏ Android Manifest או קוד בייט של Dalvik
באופן שימנע את ההתקנה וההפעלה הנכונים של הקבצים האלה במכשירים
תואמים אחרים. מי שמטמיע מכשירים צריך להשתמש בהטמעת הערוץ הראשי של Dalvik
ובמערכת ניהול החבילות של ההטמעה לדוגמה.
6. תאימות למולטימדיה
מכשיר Android תואם חייב לתמוך בקודקים הבאים של מולטימדיה. כל הקודקים האלה
זמינים כטמעות תוכנה בהטמעה המועדפת של Android מפרויקט הקוד הפתוח של Android
[מקורות מידע, 4].
לתשומת ליבך, Google ו-Open Handset Alliance לא מצהירות שהקודקים האלה
לא כפופים לפטנטים של צד שלישי. אנשים שמתכוונים להשתמש בקוד המקור הזה בחומרה או
במוצרי תוכנה צריכים לדעת שיכול להיות שיהיו להם צורך ברישיונות פטנטים מבעלי הפטנטים הרלוונטיים כדי להטמיע את הקוד הזה, כולל בתוכנות קוד פתוח או
בתוכנות שיתופיות.
שם
האודיו
פרטי המקודד המפענח
קבצים נתמכים
תוכן מונו/סטריאו בכל
קובץ 3GPP‏ (‎.3gp) ו
שילוב של שיעורי ביט רגילים
MPEG-4‏ (‎.mp4, ‎.m4a)
AAC LC/LTP
X
קבצים עם שיעורי דגימה של עד 160kbps. אין תמיכה בקבצים גולמיים
בין 8 ל-48kHz
AAC (‎.aac)
תוכן מונו/סטריאו בכל
3GPP (‎.3gp) ו
HE-AACv1
שילוב של שיעורי ביט רגילים
MPEG-4 (‎.mp4, ‎.m4a)
X
(AAC+)
עד 96kbps ושיעורי דגימה קבצים. אין תמיכה בקבצים גולמיים
בין 8 ל-48kHz
AAC (‎.aac)
תוכן מונו/סטריאו בכל
HE-AACv2
3GPP (‎.3gp) ו
שילוב של שיעורי ביט רגילים
(משופר
MPEG-4 (‎.mp4, ‎.m4a)
X
עד 96kbps ושיעורי דגימה
AAC+)
קבצים. אין תמיכה בקבצים גולמיים
בין 8 ל-48kHz
AAC‏ (‎.aac)
AMR-NB
4.75 עד 12.2kbps שנדגמו ב-
קבצי 3GPP‏ (‎.3gp)
X
X
8kHz
AMR-WB
9 שיעורי קצב נתונים מ-6.60kbit/s עד 23.85
קבצי 3GPP‏ (‎.3gp)
X
kbit/s שנדגמו ב-16kHz
MP3
קבצי MP3 (‎.mp3) מונו/סטריאו בקצב קבוע של 8 עד 320Kbps
X
(CBR) או קצב נתונים משתנה (VBR)
סוג 0 ו-1 (‎.mid,‏ ‎.xmf,
MIDI סוג 0 ו-1. DLS גרסה 1
MIDI
X
‎.mxmf). גם RTTTL/RTX
ו-2. XMF ו-Mobile XMF.
(‎.rtttl, ‎.rtx), OTA‏ (‎.ota),

תמיכה בפורמטים של רינגטונים
ו-iMelody‏ (‎.imy)
RTTTL/RTX,‏ OTA ו-iMelody
Ogg Vorbis
‎.ogg
X
PCM ליניארי של 8 ו-16 ביט (שיעורים עד
PCM
X
WAVE
לגבול החומרה)
תמונה
קבצים
שם
פרטי המקודד המפענח
נתמכים
JPEG
X
X
base+progressive
GIF
X
PNG
X
X
BMP
X
וידאו
קבצים
שם
פרטי המקודד המפענח
נתמכים
3GPP‏ (‎.3gp)
H.263
X
X
קבצים
3GPP‏ (‎.3gp)
H.264
X
ו-MPEG-4
(‎.mp4)
MPEG4
X
קובץ 3GPP‏ (‎.3gp)
SP
7. תאימות לכלים למפתחים
הטמעות של מכשירים חייבות לתמוך בכלים למפתחים של Android שכלולים ב-Android SDK.
בפרט, מכשירים תואמים ל-Android חייבים להיות תואמים ל:
• Android Debug Bridge או adb [מקורות מידע, 21]
הטמעות של מכשירים חייבות לתמוך בכל הפונקציות של adb כפי שמפורט ב-Android
SDK. הדימון של adb בצד המכשיר אמור להיות לא פעיל כברירת מחדל, אבל חייב להיות מנגנון ש
נגיש למשתמשים כדי להפעיל את Android Debug Bridge.
• Dalvik Debug Monitor Service או ddms [מקורות מידע, 22]
הטמעות של מכשירים חייבות לתמוך בכל התכונות של ddms כפי שמתואר ב-Android SDK.
מכיוון ש-ddms משתמש ב-adb, התמיכה ב-ddms אמורה להיות לא פעילה כברירת מחדל, אבל חייבת להיות תמיכה
בכל פעם שהמשתמש הפעיל את Android Debug Bridge, כפי שמתואר למעלה.

• Monkey [Resources, 23]
הטמעות במכשירים חייבות לכלול את מסגרת Monkey ולהפוך אותה לזמינה לשימוש של
אפליקציות.
8. תאימות לחומרה
מערכת Android נועדה לתמוך במטמיעים של מכשירים שיוצרים פורמטים והגדרות חדשניים.
עם זאת, מפתחי Android מצפים לחומרה, לחיישנים ולממשקי API מסוימים בכל מכשירי Android
. בקטע הזה מפורטות תכונות החומרה שכל המכשירים התואמים ל-Android 1.6 חייבים לתמוך בהן. ב-
Android 1.6, נדרש שימוש ברוב תכונות החומרה (כמו Wi-Fi, מצפן ו-accelerometer).
אם מכשיר כולל רכיב חומרה מסוים שיש לו ממשק API תואם למפתחים

של צד שלישי, ההטמעה של המכשיר חייבת ליישם את ממשק ה-API הזה כפי שמוגדר במסמכי העזרה של Android SDK.
8.1. תצוגה
גרסת Android 1.6 כוללת תכונות שמבצעות פעולות מסוימות של שינוי ושינוי קנה מידה באופן אוטומטי בנסיבות
מסוימות, כדי להבטיח שאפליקציות של צד שלישי יפעלו בצורה טובה למדי בהגדרות
חומרה שלא בהכרח תוכננו במיוחד עבורן [מקורות מידע, 24]. חובה
להטמיע את ההתנהגויות האלה במכשירים בצורה תקינה, כפי שמתואר בקטע הזה.
8.1.1. הגדרות סטנדרטיות של מסכים
בטבלה הבאה מפורטות הגדרות המסך הסטנדרטיות שנחשבות תואמות ל-Android:
רוחב אנכי
גודל מסך
צפיפות המסך
סוג המסך
רוחב (פיקסלים)
גובה (פיקסלים)
טווח אורך
קבוצה
קבוצה
(אינץ')
QVGA
240
320
2.6 – 3.0
קטן
נמוך
WQVGA
240
400
3.2 – 3.5
רגיל
נמוך
FWQVGA
240
432
3.5 – 3.8
רגיל
נמוך
HVGA
320
480
3.0 – 3.5
רגיל
בינוני
WVGA
480
800
3.3 – 4.0
רגיל
גבוה
FWVGA
480
854
3.5 – 4.0
רגיל
גבוה
WVGA
480
800
4.8 – 5.5
גדול
בינוני
FWVGA
480
854
5.0 – 5.8
גדול
בינוני
הטמעות של מכשירים שתואמות לאחת מההגדרות הסטנדרטיות שלמעלה חייבות להיות מוגדרות
כך שידווחו על גודל המסך שצוין לאפליקציות באמצעות הכיתה android.content.res.Configuration‏ [Resources,
25].
בחלק מחבילות ה-‎ .apk יש מניפסט שלא מזהה אותן כתומכות בטווח צפיפות ספציפי.
כשמריצים אפליקציות כאלה, חלות המגבלות הבאות:

• הטמעות במכשירים חייבות לפרש את כל המשאבים הקיימים כמשאבים שמוגדרים כברירת מחדל ל-
'בינוני' (נקרא 'mdpi' במסמכי התיעוד של ה-SDK).
• כשעובדים במסך עם צפיפות 'נמוכה', בהטמעות במכשירים חובה להקטין את הנכסים בגודל בינוני/
mdpi ביחס של 0.75.
• כשעובדים במסך עם דחיסות 'גבוהה', בהטמעות במכשירים חובה להגדיל את הנכסים בגודל בינוני/
mdpi פי 1.5.
• אסור לשנות את הגודל של נכסים בטווח צפיפות, וחייבים לשנות את הגודל של
נכסים לפי הגורמים האלה בדיוק בין טווחי הצפיפות.
8.1.2. הגדרות מסך לא סטנדרטיות
הגדרות מסך שלא תואמות לאחת מההגדרות הסטנדרטיות שמפורטות בקטע 8.2.1 מחייבות
השקעה נוספת של זמן ומאמצים כדי להבטיח תאימות. כדי לקבל סיווגים של קטגוריות של גודל מסך, דחיסות מסך וגורם התאמה,צוות התאימות של Android
חייב ליצור קשר עם מפתחי המכשירים כפי שמתואר בקטע 12.
כשמקבלים את המידע הזה, חייבים להטמיע אותו במכשירים
כפי שצוין.
לתשומת ליבכם: הגדרות תצוגה מסוימות (כמו מסכים גדולים מאוד או קטנים מאוד, ויחסי גובה-רוחב מסוימים)
לא תואמות באופן מהותי ל-Android 1.6. לכן, אנחנו ממליצים למטמיעים של מכשירים
לפנות לצוות התאימות של Android כמה שיותר מוקדם בתהליך הפיתוח.
8.1.3. מדדי תצוגה
הטמעות במכשירים חייבות לדווח על ערכים נכונים לכל מדדי התצוגה שמוגדרים ב-
android.util.DisplayMetrics [מקורות מידע, 26].
8.2. מקלדת
הטמעות במכשיר:
• חובה לכלול תמיכה ב-Input Management Framework (שמאפשר למפתחים של צד שלישי
ליצור מנועי ניהול קלט – כלומר מקלדת וירטואלית) כפי שמפורט בכתובת
developer.android.com
• חובה לספק לפחות הטמעה אחת של מקלדת וירטואלית (ללא קשר לכך שיש מקלדת
פיזית)
• מותר לכלול הטמעות נוספות של מקלדת וירטואלית
• מותר לכלול מקלדת חומרה
• אסור לכלול מקלדת חומרה שלא תואמת לאחד מהפורמטים שצוינו
ב-android.content.res.Configuration [Resources, 25] (כלומר QWERTY או 12 מפתחות)
8.3. ניווט ללא מגע
הטמעות במכשירים:
• אפשר להשמיט אפשרויות ניווט ללא מגע (כלומר, אפשר להשמיט טרקר-בול, משטח כיוון בן 5 כיוונים או
גלגל)
• חובה לדווח דרך android.content.res.Configuration [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 עבור האחסון הנשלף/אחסון המדיה שנמצא במכשיר
• מומלץ להשתמש בפורמט micro USB בצד המכשיר
• מומלץ להטמיע תמיכה במפרט של אחסון בנפח גדול ב-USB (כדי שניתן יהיה לגשת לאחסון הנשלף
או לאחסון הקבוע במכשיר ממחשב מארח)
• אפשר לכלול יציאה לא סטנדרטית בצד המכשיר, אבל אם כן, חובה לשלוח עם המכשיר כבל שיכול
לחבר את החיבורים המותאמים אישית ליציאת USB-A רגילה
8.7.
מקשי ניווט
הפונקציות 'דף הבית', 'תפריט' ו'חזרה' הן חיוניות לתפיסה של הניווט ב-Android. הטמעות
במכשירים חייבות להפוך את הפונקציות האלה לזמינות למשתמש בכל זמן, ללא קשר למצב
של האפליקציה. יש להטמיע את הפונקציות האלה באמצעות לחצנים ייעודיים. אפשר להטמיע אותם
באמצעות תוכנה, תנועות, לוח מגע וכו', אבל אם כן, הם חייבים להיות נגישים תמיד ולא
להסתיר או
להפריע לאזור התצוגה הזמין של האפליקציה.
מפתחי המכשירים צריכים לספק גם מפתח חיפוש ייעודי. מפתחי המכשירים יכולים גם
לספק מפתחות שליחה וסיום לשיחות טלפון.
8.8. Wi-Fi
הטמעות של מכשירים חייבות לתמוך ב-802.11b וב-802.11g, ויכול להיות שתהיה תמיכה גם ב-802.11a.

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

הטמעות במכשירים חייבות ליישם את ההתנהגויות הבאות בממשקי ה-API שקשורים למצלמה
[Resources, 27]:
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 חייב להיות ברירת המחדל.
8.9.1. מצלמות ללא פוקוס אוטומטי
אם במכשיר אין מצלמה עם פוקוס אוטומטי, מי שמטמיע את המכשיר חייב לעמוד בדרישות הנוספות שמפורטות
בקטע הזה. בהטמעות של מכשירים חובה להטמיע את Camera API המלאה שכלולה במסמכי התיעוד של ערכת ה-SDK של Android 1.6
באופן סביר, ללא קשר ליכולות של חומרת המצלמה בפועל.
ב-Android 1.6, אם המצלמה לא כוללת פוקוס אוטומטי, הטמעת המכשיר חייבת לעמוד בדרישות הבאות:
1. המערכת חייבת לכלול מאפיין מערכת לקריאה בלבד בשם "ro.workaround.noautofocus"
עם הערך '1'. הערך הזה מיועד לאפליקציות כמו Android Market כדי
לזהות באופן סלקטיבי את יכולות המכשיר, והוא יוחלף בגרסת Android עתידית ב-
API חזק.
2. אם אפליקציה קוראת ל-android.hardware.Camera.autoFocus(), המערכת חייבת לקרוא לשיטה
onAutoFocus() של כל המופעים הרשומים של
android.hardware.Camera.AutoFocusCallback, גם אם לא התרחשה
אף פעולת מיקוד. המטרה היא למנוע מצב שבו אפליקציות קיימות יקרסו בגלל שהן מחכות לנצח לקריאה חוזרת (callback) של התמקדות אוטומטית
שלא תגיע אף פעם.
3. הקריאה ל-method AutoFocusCallback.onAutoFocus() חייבת להיות מופעלת על ידי הנהג או
המסגרת באירוע חדש בשרשור ה-Looper הראשי של המסגרת. כלומר, אסור ל-Camera.autoFocus()
להפעיל ישירות את AutoFocusCallback.onAutoFocus()‎ כי הפעולה הזו מפירה את מודל השרשור של Android
framework ותגרום לשיבושים באפליקציות.
8.10. תאוצה
הטמעות במכשירים חייבות לכלול תאוצה עם 3 צירים, והן חייבות להיות מסוגלות לשלוח אירועים
לפחות ב-50Hz. מערכת הקואורדינטות שבה נעשה שימוש בתאוצה חייבת להיות תואמת למערכת הקואורדינטות של חיישן
Android כפי שמפורט ב-Android API‏[מקורות מידע, 28].

8.11. מצפן
הטמעות במכשירים חייבות לכלול מצפן 3-צירי, והן חייבות להיות מסוגלות לשלוח אירועים בערך
10Hz. מערכת הקואורדינטות שבה נעשה שימוש במצפן חייבת להיות תואמת למערכת הקואורדינטות של חיישן Android
כפי שמוגדרת ב-Android API [מקורות מידע, 28].
8.12. GPS
הטמעות של מכשירים חייבות לכלול GPS, ורצוי לכלול גם שיטה כלשהי של 'GPS משופר'
כדי לקצר את זמן הנעילה של ה-GPS.
8.13. טלפוניה
הטמעות במכשירים:
• חובה לכלול טכנולוגיית טלפוניה מסוג GSM או CDMA
• חובה להטמיע את ממשקי ה-API המתאימים כפי שמפורט במסמכי התיעוד של Android SDK בכתובת
developer.android.com
לתשומת ליבכם: הדרישה הזו מובילה למסקנה שמכשירים שאינם טלפונים לא תואמים ל-Android 1.6. מכשירי Android
1.6 חייבים לכלול חומרה של טלפוניה. מידע על מכשירים
שאינם טלפונים זמין בנספח ג'.
8.14. אמצעי בקרה על עוצמת הקול
מכשירים תואמים ל-Android חייבים לכלול מנגנון שמאפשר למשתמש להגדיל ולהקטין את
עוצמת האודיו. הטמעות במכשירים חייבות להפוך את הפונקציות האלה לזמינות למשתמש בכל זמן,
ללא קשר למצב האפליקציה. אפשר להטמיע את הפונקציות האלה באמצעות מפתחות חומרה פיזיים,
תוכנה, תנועות, לוח מגע וכו', אבל הן תמיד חייבות להיות נגישות ולא להסתיר או להפריע
לאזור התצוגה הזמין של האפליקציה (ראו 'תצוגה' למעלה).
כשמשתמשים בלחצנים האלה, חובה ליצור את האירועים המרכזיים התואמים ולשלוח אותם לאפליקציה
שבחזית. אם האפליקציה לא תירשם את האירוע ולא תטפל בו, ההטמעה של device
חייבת לטפל באירוע כבקרת עוצמת קול במערכת.
9. תאימות לביצועים
אחד מהיעדים של תוכנית התאימות ל-Android הוא להבטיח חוויית שימוש עקבית באפליקציות ל
צרכנים. הטמעות תואמות חייבות לוודא לא רק שהאפליקציות פועלות בצורה תקינה
במכשיר, אלא גם שהן עושות זאת עם ביצועים סבירים וחוויית משתמש טובה באופן כללי.
הטמעות של מכשירים חייבות לעמוד במדדי הביצועים העיקריים של מכשיר תואם ל-Android 1.6,
כפי שמפורט בטבלה הבאה:
מדד
סף הביצועים
הערות

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

AlarmClock: פחות מ-650ms
יותר אפליקציות יושקעו.
הבדיקה מתבצעת על ידי CTS.
הפעלה מחדש של
האפליקציה הראשונה במקביל
לאפליקציות
צריכה להימשך פחות
משעת ההפעלה המקורית.
10. תאימות של מודל האבטחה
הטמעות במכשירים חייבות ליישם מודל אבטחה שתואם למודל האבטחה של פלטפורמת Android
, כפי שמוגדר במסמך העזרה בנושא אבטחה והרשאות בממשקי ה-API‏ [משאבים, 29] בתיעוד למפתחים של
Android. הטמעות של מכשירים חייבות לתמוך בהתקנה של אפליקציות
בחתימה עצמית, בלי צורך בהרשאות או בתעודות נוספות מצדדים שלישיים או מרשויות.
במיוחד, מכשירי התאימות חייבים לתמוך במנגנוני האבטחה הבאים:
10.1. הרשאות
הטמעות במכשירים חייבות לתמוך במודל ההרשאות של Android כפי שמוגדר במסמכי התיעוד למפתחים של Android
[משאבים, 9]. באופן ספציפי, ההטמעות חייבות לאכוף כל הרשאה
שמוגדרת כפי שמתואר במסמכי התיעוד של ה-SDK. אסור להשמיט, לשנות או להתעלם מהרשאות.
ההטמעות יכולות להוסיף הרשאות נוספות, בתנאי שמחרוזות מזהי ההרשאות החדשות לא נמצאות במרחב השמות
android.*.
10.2. בידוד משתמשים ותהליכים
הטמעות במכשירים חייבות לתמוך במודל של ארגז חול לאפליקציות ב-Android, שבו כל אפליקציה
פועלת כ-UID ייחודי בסגנון Unix ובתהליך נפרד.
הטמעות במכשירים חייבות לתמוך בהפעלת כמה אפליקציות באותו מזהה משתמש ב-Linux, בתנאי
שהאפליקציות נחתמות ונוצרות כראוי, כפי שמוגדר במסמך העזרה בנושא אבטחה והרשאות
[מקורות מידע, 29].

10.3. הרשאות של מערכת הקבצים
הטמעות במכשירים חייבות לתמוך במודל ההרשאות של Android לגישה לקבצים, כפי שמוגדר
במאמר העזרה בנושא אבטחה והרשאות [Resources, 29].
11. חבילת בדיקות תאימות
הטמעות של מכשירים חייבות לעבור את חבילת בדיקות התאימות של Android‏ (CTS) [מקורות מידע, 3] שזמינה
בפרויקט Android Open Source, באמצעות תוכנת האריזה הסופית במכשיר. בנוסף,
מפתחי המכשירים צריכים להשתמש בהטמעת העזר ב-Android Open Source tree ככל האפשר,
וצריך לוודא תאימות במקרים של אי-בהירות ב-CTS ובכל
הטמעה מחדש של חלקים מקוד המקור של העזר.
ה-CTS מיועד להפעלה במכשיר בפועל. כמו כל תוכנה, גם ה-CTS עשוי להכיל באגים.
ה-CTS יקבל גרסאות בנפרד מהגדרת התאימות הזו, וייתכן שיושקו כמה גרסאות של
CTS ל-Android 1.6. עם זאת, גרסאות כאלה יתקנו רק באגים התנהגותיים בבדיקות CTS
, ולא יכללו בדיקות, התנהגויות או ממשקי API חדשים לגרסה מסוימת של הפלטפורמה.
12. יצירת קשר
אפשר לפנות לצוות התאימות של Android בכתובת compatibility@android.com לקבלת הבהרות לגבי
הגדרת התאימות הזו ולשלוח משוב לגבי ההגדרה הזו.

משתמשים ב-
EXTRA_CREATE_DESCRIPTION
עם SHOW_OR_CREATE_CONTACT כדי
לציין תיאור מדויק ש

יוצג כשהמשתמש יתבקש
ליצור איש קשר חדש.
משמש
עם SHOW_OR_CREATE_CONTACT כדי
EXTRA_FORCE_CREATE
לאלץ יצירת איש קשר חדש אם לא נמצא
איש קשר תואם.
זהו הכוונה שמופיעה כש
מקישים על הצעה לחיפוש
.
זהו הכוונה שמופיעה כשמקישים על
SEARCH_SUGGESTION_CREATE_CONTACT_CLICKED הצעה לחיפוש ליצירת
איש קשר.
זהו הכוונה שמופיעה כש
לחצו על SEARCH_SUGGESTION_DIAL_NUMBER_CLICKED
הצעה לחיפוש של מספר לחיוג
.
הפרמטר מקבל כקלט URI של נתונים עם mailto:‎
SHOW_OR_CREATE_CONTACT
או סכימת tel: ‎.

נספח ב': כוונות השידור הנדרשותהערה: הרשימה הזו היא רשימה זמנית
ותתעדכן בעתיד.
פעולת הכוונה
תיאור
פעולת שידור: הפעולה הזו משודרת פעם אחת, אחרי
ACTION_BOOT_COMPLETED
שהמערכת סיימה את האתחול.
פעולת שידור: הפעולה הזו משודרת פעם אחת, כשמתקבלת שיחה מסוג
ACTION_CALL_BUTTON
.
פעולת שידור: הלחצן 'מצלמה'
ACTION_CAMERA_BUTTON
נדחף.
פעולת שידור: הגדרת
המכשיר(כיוון, אזור זמן וכו')
ACTION_CONFIGURATION_CHANGED
שונה.
ACTION_DATE_CHANGED
פעולת שידור: התאריך השתנה.
פעולת שידור: מציינת מצב של זיכרון נמוך
ACTION_DEVICE_STORAGE_LOW
במכשיר
פעולת שידור: מציינת מצב של זיכרון נמוך
ACTION_DEVICE_STORAGE_OK
במכשיר כבר לא קיים
פעולת שידור: אוזניות קוויות מחוברות או
ACTION_HEADSET_PLUG
לא מחוברות.
פעולת שידור: שיטת קלט
ACTION_INPUT_METHOD_CHANGED
שונתה.
פעולת שידור: מדיה חיצונית הוסרה
ACTION_MEDIA_BAD_REMOVAL
מחריצי כרטיס ה-SD, אבל נקודת הטעינה לא
הוסרתה.
פעולת שידור: הלחצן 'Media Button'
ACTION_MEDIA_BUTTON
נדחף.
פעולת שידור: יש מדיה חיצונית, ו
היא נבדקת בדיסק. הנתיב לנקודת הטעינה של
ACTION_MEDIA_CHECKING
המדיה שנבדקת נמצא בשדה
Intent.mData.
פעולת שידור: המשתמש הביע רצון
ACTION_MEDIA_EJECT
להוציא את אמצעי האחסון החיצוני.
פעולת שידור: יש מדיה חיצונית ו
ACTION_MEDIA_MOUNTED
מוטמעת בנקודת הטעינה שלה.
פעולת שידור: מדיה חיצונית קיימת, אבל
היא משתמשת ב-fs לא תואם (או שהיא ריקה) הנתיב אל
ACTION_MEDIA_NOFS
נקודת הטעינה של המדיה לבדיקה
נמצאת בשדה Intent.mData.
פעולת שידור: מדיה חיצונית
ACTION_MEDIA_REMOVED
הוסר.
פעולת שידור: סורק המדיה סיים
ACTION_MEDIA_SCANNER_FINISHED
לסרוק ספרייה.
פעולת שידור: בקשה למסוף הסריקה של המדיה
ACTION_MEDIA_SCANNER_SCAN_FILE
לסרוק קובץ ולהוסיף אותו למסד הנתונים של המדיה.

פעולת שידור: סורק המדיה התחיל
ACTION_MEDIA_SCANNER_STARTED
לסרוק ספרייה.
פעולת שידור: המדיה החיצונית הוסרה
ACTION_MEDIA_SHARED
כי היא משותפת דרך אחסון בנפח גדול מסוג USB.
פעולת שידור: יש מדיה חיצונית אבל
לא ניתן לטעון את ACTION_MEDIA_UNMOUNTABLE
.
פעולת שידור: יש מדיה חיצונית, אבל
ACTION_MEDIA_UNMOUNTED
לא מותקנת בנקודת ההתקנה שלה.
פעולת שידור: שיחה יוצאת עומדת להתבצע
ACTION_NEW_OUTGOING_CALL
.
פעולת שידור: חבילה חדשה של אפליקציה
ACTION_PACKAGE_ADDED
הותקנה במכשיר.
פעולת שידור: חבילת אפליקציה קיימת
ACTION_PACKAGE_CHANGED
שונה (למשל, רכיב
הופעל או הושבת.
פעולת שידור: המשתמש ניקה את הנתונים של
חבילה. לפני ההודעה הזו צריכה להופיע
ההודעה ACTION_PACKAGE_RESTARTED, ואחריה
ACTION_PACKAGE_DATA_CLEARED
כל הנתונים הקבועים שלה נמחקים וההודעה
הזו נשלחת. שימו לב שהחבילה המאושרת
לא מקבלת את השידור הזה. הנתונים מכילים את
שם החבילה.
פעולת השידור: חבילת אפליקציה קיימת
הוסר מהמכשיר. הנתונים
ACTION_PACKAGE_REMOVED
מכילים את שם החבילה. החבילה
שמותקנת לא מקבלת את ה-Intent הזה.
פעולת שידור: הותקנה גרסה חדשה של חבילת
ACTION_PACKAGE_REPLACED
האפליקציה, והיא מחליפה גרסה
קיימת שהותקנה בעבר.
פעולת שידור: המשתמש הפעיל מחדש
חבילת תוכנה וכל התהליכים שלה הושמדו.
יש להסיר את כל המצבים בסביבת זמן הריצה שמשויכים אליה (תהליכים,
ACTION_PACKAGE_RESTARTED
התראות, התראות וכו'). שימו לב
שהחבילה שהפעלתם מחדש לא מקבלת את השידור הזה
. הנתונים מכילים את שם החבילה
.
פעולת שידור: לחלק מספקי התוכן יש
חלקים במרחב השמות שלהם שבהם הם מפרסמים
אירועים חדשים מסוגACTION_PROVIDER_CHANGED
או פריטים שהמשתמש עשוי להתעניין בהם במיוחד.

ACTION_SCREEN_OFF
פעולת שידור: נשלחת אחרי שהמסך נכבה.
ACTION_SCREEN_ON
פעולת שידור: נשלחת אחרי שהמסך מופעל.
פעולת שידור: מזהה משתמש הוסר
ACTION_UID_REMOVED
מהמערכת.
פעולת שידור: המכשיר עבר למצב
ACTION_UMS_CONNECTED
אחסון בנפח גדול.

פעולת שידור: המכשיר יצא ממצב אחסון בנפח גדול
ACTION_UMS_DISCONNECTED
דרך USB.
פעולת שידור: נשלחת כשהמשתמש נמצא
ACTION_USER_PRESENT
אחרי שהמכשיר מתעורר (למשל כשמסך
הנעילה נעלם).
פעולת שידור: שינוי של תמונת הרקע הנוכחית של המערכת
ACTION_WALLPAPER_CHANGED
.
ACTION_TIME_CHANGED
פעולת שידור: הזמן הוגדר.
ACTION_TIME_TICK
פעולת שידור: השעה הנוכחית השתנתה.
ACTION_TIMEZONE_CHANGED
פעולת שידור: אזור הזמן השתנה.
פעולת שידור: סטטוס הטעינה או
רמת הטעינה
ACTION_BATTERY_CHANGED
של הסוללה השתנו.
פעולת שידור: מציינת מצב של סוללה חלשה
ACTION_BATTERY_LOW
במכשיר. השידור הזה תואם לתיבת הדו-שיח של המערכת
'התראה על סוללה חלשה'.
פעולת שידור: מציינת שהסוללה שוב תקינה
אחרי שהיא הייתה חלשה. המערכת תשלח את ההודעה
ACTION_BATTERY_OKAY
אחרי ACTION_BATTERY_LOW כשהסוללה
תחזור למצב תקין.
Network State
פעולת Intent
תיאור
פעולת Intent להעברה (broadcast) שמציינת שהמצב
NETWORK_STATE_CHANGED_ACTION
של הקישוריות ל-Wi-Fi השתנה.
פעולת כוונה להעברה (broadcast) שמציינת שהערך של
RSSI_CHANGED_ACTION
RSSI (עוצמת האות) השתנה.
פעולת כוונה להעברה (broadcast) שמציינת שהתרחשה
SUPPLICANT_STATE_CHANGED_ACTION
התחברות למבקש
או ניתוק ממנו.
פעולת ה-Intent להעברה (broadcast) שמציינת שהתכונה Wi-Fi
WIFI_STATE_CHANGED_ACTION
הופעל, הושבתה, הופעלה
הושבתה או שהסטטוס שלה לא ידוע.
יכול להיות שמזהי הרשתות שהוגדרו
NETWORK_IDS_CHANGED_ACTION
שינו.
פעולת שידור של כוונה (intent) שמציינת שהערכים של ההגדרה
ACTION_BACKGROUND_DATA_SETTING_CHANGED לשינוי השימוש בנתוני רקע
שינו.
שידור כוונה לציון שחל שינוי בקישוריות הרשת של
CONNECTIVITY_ACTION
.
פעולת שידור: המשתמש הפעיל או השבית את
ACTION_AIRPLANE_MODE_CHANGED
המצב 'מצב טיסה' בטלפון.

נספח ג': שיקולים עתידיים הנספח הזה מבהיר חלקים מסוימים מההגדרה של תאימות ל-Android
1.6, ובמקרים מסוימים מתייחס לשינויים צפויים או מתוכננים שמיועדים לגרסת
עתידית של פלטפורמת Android. נספח זה מיועד למטרות מידע ותכנון בלבד,
והוא לא חלק מההגדרה של תאימות ל-Android 1.6.
1. מכשירים שאינם טלפונים
גרסת Android 1.6 מיועדת אך ורק לטלפונים. פונקציונליות הטלפוניה היא חובה. בגרסאות עתידיות
של פלטפורמת Android, התכונה 'טלפוניה' תהיה אופציונלית (כך שיהיה אפשר להשתמש במכשירי Android
שאינם טלפונים), אבל רק טלפונים תואמים ל-Android 1.6.
2. תאימות ל-Bluetooth
בגרסה 1.6 של Android אין תמיכה ב-Bluetooth API, כך ש
מבחינת תאימות, אין שום שיקולים לגבי Bluetooth בגרסה הזו של הפלטפורמה. עם זאת, בגרסה עתידית
של Android יוצגו ממשקי API של Bluetooth. בשלב הזה, תמיכה ב-Bluetooth תהיה חובה לצורך
תאימות.
לכן, מומלץ מאוד שמכשירי Android מגרסה 1.6 יכללו Bluetooth, כדי שהם יהיו
תואמים לגרסאות עתידיות של Android שדורשות Bluetooth.
3. רכיבי החומרה הנדרשים
כל רכיבי החומרה שמפורטים בקטע 8 (כולל Wi-Fi, מגנטומטר/מצפן, תאוצה וכו')
נדרשים ואי אפשר להשמיט אותם. בגרסאות עתידיות של Android, חלק (אבל לא כולם)
מהרכיבים האלה צפויים להיות אופציונליים, יחד עם כלים תואמים למפתחים של צד שלישי כדי לטפל
בשינויים האלה.
4. אפליקציות לדוגמה
מסמך הגדרת התאימות לגרסה עתידית של Android יכלול רשימה מקיפה יותר של אפליקציות
שמייצגות את כל האפליקציות, בהשוואה לאפליקציות שמפורטות בקטע 4 שלמעלה. לגרסה 1.6 של Android, צריך לבדוק את
האפליקציות שמפורטות בקטע 4.
5. מסכי מגע
יכול להיות שבגרסאות עתידיות של הגדרת התאימות יהיה אפשר להשמיט מסכי מגע ממכשירים, ויכול להיות שלא.
עם זאת, כרגע חלק גדול מההטמעה של מסגרת Android מבוססת על קיומו של
מסך מגע. השמטה של מסך מגע תגרום לשיבושים משמעותיים בכל האפליקציות הנוכחיות של צד שלישי ל-Android,
לכן ב-Android 1.6 נדרש מסך מגע לצורך תאימות.

6. ביצועים
בגרסאות עתידיות של CTS נמדוד גם את ניצול המעבד ואת הביצועים של
הרכיבים הבאים בהטמעה:
• גרפיקה 2D
• גרפיקה 3D
• הפעלת וידאו
• הפעלת אודיו
• הפעלת Bluetooth A2DP

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

מתאר המסמך

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