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

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

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

1. הקדמה

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

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

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

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

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

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

2. משאבים

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

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

3. תוכנה

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

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

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

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

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

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

3.2.1. הרשאות

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

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

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

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

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

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

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

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

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

• שעון שולחן
• דפדפן
• לוּחַ שָׁנָה
• מַחשְׁבוֹן
• מַצלֵמָה
• אנשי קשר
• אימייל
• גלריה
• GlobalSearch
• מַשׁגֵר
• LivePicker (כלומר, אפליקציית בורר הטפטים החיים; ניתן להשמיט אם המכשיר אינו תומך בטפטים חיים, לפי סעיף 3.8.5.)
• העברת הודעות (AKA "Mms")
• מוּסִיקָה
• טלפון
• הגדרות
• מקליט קול

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

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

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

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

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

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

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

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

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

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

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

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

• libc (ספריית C)
• libm (ספריית מתמטיקה)
• ממשק JNI
• libz (דחיסה של Zlib)
• liblog (רישום אנדרואיד)
• תמיכה מינימלית עבור C++
• תמיכה ב-OpenGL, כמתואר להלן

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

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

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

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

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

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

3.4.1. תאימות WebView

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.1. ווידג'טים

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

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

3.8.2. התראות

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

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

3.8.3. לחפש

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

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

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

3.8.4. טוסטים

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

3.8.5. רקעים חיים

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

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

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

4. התייחסות לתאימות תוכנה

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

• מחשבון (כלול ב-SDK)
• Lunar Lander (כלול ב-SDK)
• יישומי "אפליקציות לאנדרואיד" [ משאבים, 18 ].
• Replica Island (זמין ב-Android Market; נדרש רק עבור יישומי מכשירים התומכים ב-OpenGL ES 2.0)

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

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

• אפידמוס (כלול ב- SDK)
• Manualsmoketests (כלול ב- CTS)

כל מקרה בדיקה ביישומים שלמעלה חייב לפעול כראוי ביישום המכשיר.

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

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

יישומי מכשירים אסור להרחיב את ה- .APK [ משאבים, 20 ], אנדרואיד ביטוי [ משאבים, 21 ], או Dalvik Bytecode [ משאבים, 10 ] בצורה כזו שתמנע מהתקנת קבצים אלה ולהפעיל נכון במכשירים תואמים אחרים . על יישומי מכשירים להשתמש ביישום ההתייחסות במעלה הזרם של דלוויק ובמערכת ניהול החבילות של יישום ההתייחסות.

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

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

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

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

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

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

6.2. הקלטת שמע

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

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

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

6.3. חביון שמע

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.1. לְהַצִיג

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

עבור אנדרואיד 2.2, אלה הן תצורות התצוגה הנפוצות ביותר:

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

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

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

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

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

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

8.1.3. מדדי תצוגה

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

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

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

8.2. מקלדת

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

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

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

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

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

8.4. כיוון מסך

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

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

8.5. קלט מסך מגע

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

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

8.6. יו אס בי

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

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

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

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

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

8.8. רשת נתונים אלחוטית

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

אם יישום מכשיר כולל אופן מסוים שעבורו SDK אנדרואיד כולל API (כלומר WIFI, GSM או CDMA), על היישום לתמוך ב- API.

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

8.9. מַצלֵמָה

יישומי המכשירים חייבים לכלול מצלמה הפונה לאחור. המצלמה הכלולה הפונה לאחור:

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

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

1. אם יישום מעולם לא התקשר ל- Android.hardware.camera.parameters.setPreviewFormat (int), על המכשיר להשתמש ב- Android.hardware.pixelformat.ycbcr_420_sp לקבלת נתוני תצוגה מקדימה המסופקים להתקשרות יישומים.
2. אם יישום רושם Android.hardware.camera.previewCallback והמערכת מכנה את שיטת OnPreviewFrame () כאשר פורמט התצוגה המקדימה הוא YCBCR_420_SP, הנתונים בתאי [] מועברים ל- OnPreviewFrame () חייבים להיות עוד בתושבת הקידוד NV21. (זהו הפורמט המשמש באופן טבעי על ידי משפחת חומרת 7K.) כלומר, NV21 חייב להיות ברירת המחדל.

על יישומי מכשירים ליישם את ממשק ה- API המלאי המלא הכלול בתיעוד SDK Android 2.2 [ משאבים, 27 ]), ללא קשר אם המכשיר כולל מיקוד אוטומטי לחומרה או יכולות אחרות. לדוגמה, מצלמות שחסרות מיקוד אוטומטי חייבות עדיין להתקשר לכל מקרים רשומים android.hardware.Camera.AutoFocusCallback .

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

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

8.10. מד תאוצה

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

8.11. מצפן

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

8.12. ג'י.פי. אס

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

8.13. טלפוניה

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

ראו גם סעיף 8.8, רשת נתונים אלחוטית.

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

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

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

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

8.15. אחסון משותף ליישום

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

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

יישומי מכשירים חייבים לאכוף כמתועדים ל- android.permission.WRITE_EXTERNAL_STORAGE באחסון משותף זה. אחסון משותף חייב להיות כתוב על ידי כל יישום שמשיג הרשאה זו.

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

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

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

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

8.16. בלוטות

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

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

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

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

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

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

10.1. הרשאות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11. חבילת מבחן תאימות

יישומי מכשירים חייבים להעביר את חבילת בדיקות התאימות של אנדרואיד (CTS) [ משאבים, 2 ] הזמינים מפרויקט הקוד הפתוח של אנדרואיד, תוך שימוש בתוכנת המשלוח הסופית במכשיר. בנוסף, על יישומי המכשירים להשתמש ביישום ההתייחסות בעץ הקוד הפתוח אנדרואיד ככל האפשר, ועליהם להבטיח תאימות במקרים של עמימות ב- CTS ולכל יישום מחדש של חלקים מקוד מקור ההתייחסות.

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

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

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

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

• הורדות מעל אוויר (OTA) עם עדכון לא מקוון באמצעות אתחול מחדש
• עדכונים "קשורים" על USB ממחשב מארח
• עדכונים "לא מקוונים" באמצעות אתחול מחדש ועדכן מקובץ באחסון נשלף

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

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

13. צרו קשר

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

נספח A - נוהל בדיקת Bluetooth

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

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

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

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

Setup and Installation

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

Test Bluetooth Control by Apps

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

Test Pairing and Communication

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

Test Pairing and Communication in the Reverse Direction

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

Test Re-Launches

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

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