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

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

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

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

1. הקדמה
2. משאבים
3. תוכנה
4. התייחסות לתאימות תוכנה
5. תאימות אריזות יישומים
6. תאימות מולטימדיה
7. תאימות לכלי מפתחים
8. תאימות חומרה
9. תאימות ביצועים
10. תאימות מודל אבטחה
11. חבילת בדיקת תאימות
12. תוכנה הניתנת לעדכון
13. צור קשר
נספח א' - נוהל בדיקת בלוטות'

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/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/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. רקעים חיים: http://developer.android.com/resources/articles/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. כלי לבדיקת קופים: http://developer.android.com/guide/developing/tools/monkey.html
  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 ] שנועדו לתאר את המכשיר הנוכחי. כדי לספק ערכים עקביים ומשמעותיים על פני יישומי מכשירים, הטבלה שלהלן כוללת הגבלות נוספות על הפורמטים של ערכים אלה שאליהם יישומי מכשירים חייבים להתאים.

פָּרָמֶטֶר הערות
android.os.Build.VERSION.RELEASE הגרסה של מערכת אנדרואיד הפועלת כעת, בפורמט קריא אנושי. שדה זה חייב לכלול אחד מערכי המחרוזת המוגדרים ב-[ משאבים, 7 ].
android.os.Build.VERSION.SDK הגרסה של מערכת אנדרואיד הפועלת כעת, בפורמט נגיש לקוד אפליקציה של צד שלישי. עבור Android 2.2, שדה זה חייב לכלול את הערך השלם 8.
android.os.Build.VERSION.INCREMENTAL ערך שנבחר על ידי מיישם המכשיר המייעד את המבנה הספציפי של מערכת אנדרואיד הפועלת כעת, בפורמט קריא אנושי. אין לעשות שימוש חוזר בערך זה עבור מבנים שונים שזמינים למשתמשי קצה. שימוש טיפוסי בשדה זה הוא לציין באיזה מספר build או מזהה שינוי בקרת מקור נעשה שימוש ליצירת ה-build. אין דרישות לגבי הפורמט הספציפי של שדה זה, מלבד שאסור שהוא יהיה null או המחרוזת הריקה ("").
android.os.Build.BOARD ערך שנבחר על ידי מיישם המכשיר המזהה את החומרה הפנימית הספציפית המשמשת את המכשיר, בפורמט קריא אנושי. שימוש אפשרי בשדה זה הוא לציין את הגרסה הספציפית של הלוח המחזק את המכשיר. אין דרישות לגבי הפורמט הספציפי של שדה זה, מלבד שאסור שהוא יהיה null או המחרוזת הריקה ("").
android.os.Build.BRAND ערך שנבחר על ידי מיישם המכשיר המזהה את שם החברה, הארגון, הפרט וכו' שייצר את המכשיר, בפורמט קריא אנושי. שימוש אפשרי בשדה זה הוא לציין את ה-OEM ו/או הספק שמכר את המכשיר. אין דרישות לגבי הפורמט הספציפי של שדה זה, מלבד שאסור שהוא יהיה null או המחרוזת הריקה ("").
android.os.Build.DEVICE ערך שנבחר על ידי מיישם המכשיר המזהה את התצורה או הגרסה הספציפית של הגוף (המכונה לפעמים "עיצוב תעשייתי") של המכשיר. אין דרישות לגבי הפורמט הספציפי של שדה זה, מלבד שאסור שהוא יהיה null או המחרוזת הריקה ("").
android.os.Build.FINGERPRINT מחרוזת המזהה באופן ייחודי את המבנה הזה. זה אמור להיות קריא אנושי באופן סביר. זה חייב לעקוב אחר התבנית הזו:
$(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
לדוגמה:
acme/mydevice/generic/generic:2.2/ERC77/3359:userdebug/test-keys
אסור לטביעת האצבע לכלול תווי רווח לבן. אם בשדות אחרים הכלולים בתבנית שלמעלה יש תווי רווח לבן, יש להחליף אותם בטביעת האצבע של המבנה בתו אחר, כגון הקו התחתון ("_").
android.os.Build.HOST מחרוזת המזהה באופן ייחודי את המארח שעליו נבנה ה-build, בפורמט קריא אנושי. אין דרישות לגבי הפורמט הספציפי של שדה זה, מלבד שאסור שהוא יהיה null או המחרוזת הריקה ("").
android.os.Build.ID מזהה שנבחר על ידי מיישם המכשיר להתייחס למהדורה ספציפית, בפורמט קריא אנושי. שדה זה יכול להיות זהה ל-android.os.Build.VERSION.INCREMENTAL, אבל צריך להיות ערך בעל משמעות מספיקה למשתמשי קצה כדי להבחין בין תוכנות לבנות. אין דרישות לגבי הפורמט הספציפי של שדה זה, מלבד שאסור שהוא יהיה null או המחרוזת הריקה ("").
android.os.Build.MODEL ערך שנבחר על ידי מיישם המכשיר המכיל את שם המכשיר כפי שידוע למשתמש הקצה. זה צריך להיות אותו שם שבו המכשיר משווק ונמכר למשתמשי קצה. אין דרישות לגבי הפורמט הספציפי של שדה זה, מלבד שאסור שהוא יהיה null או המחרוזת הריקה ("").
android.os.Build.PRODUCT ערך שנבחר על ידי מיישם המכשיר המכיל את שם הפיתוח או שם הקוד של המכשיר. חייב להיות קריא על ידי אדם, אך אינו מיועד בהכרח לצפייה על ידי משתמשי קצה. אין דרישות לגבי הפורמט הספציפי של שדה זה, מלבד שאסור שהוא יהיה null או המחרוזת הריקה ("").
android.os.Build.TAGS רשימה מופרדת בפסיקים של תגים שנבחרו על ידי מיישם ההתקן שמייחדים עוד יותר את המבנה. לדוגמה, "לא חתום, ניפוי באגים". שדה זה לא חייב להיות null או המחרוזת הריקה (""), אבל תג בודד (כגון "שחרור") הוא בסדר.
android.os.Build.TIME ערך המייצג את חותמת הזמן של מועד הבנייה.
android.os.Build.TYPE ערך שנבחר על ידי מיישם ההתקן המציין את תצורת זמן הריצה של ה-build. שדה זה צריך לכלול אחד מהערכים התואמים לשלוש תצורות זמן הריצה האופייניות ל-Android: "user", "userdebug" או "eng".
android.os.Build.USER שם או מזהה משתמש של המשתמש (או המשתמש האוטומטי) שיצר את ה-build. אין דרישות לגבי הפורמט הספציפי של שדה זה, מלבד שאסור שהוא יהיה null או המחרוזת הריקה ("").

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

אנדרואיד כולל ממשקי 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)

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

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

  • ApiDemos (כלול ב-SDK)
  • בדיקות עשן ידניות (כלולות ב-CTS)

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

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

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

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

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

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

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

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

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

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

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

6.2. הקלטת שמע

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

  • עיבוד הפחתת רעש, אם קיים, צריך להיות מושבת.
  • בקרת רווח אוטומטי, אם קיימת, צריכה להיות מושבתת.
  • ההתקן אמור להציג מאפייני משרעת שטוחה לעומת תדר בקירוב; במיוחד, ±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 הרץ ברמת קלט SPL של 90 dB.

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

6.3. השהיית אודיו

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

למטרות סעיף זה:

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

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

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

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

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

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

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

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

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

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

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

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

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

8.1. לְהַצִיג

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

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

סוג מסך רוחב (פיקסלים) גובה (פיקסלים) טווח אורך אלכסוני (אינץ') קבוצת גודל מסך קבוצת צפיפות מסך
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 [ משאבים, 24 ].

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

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

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

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

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

8.1.3. מדדי תצוגה

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

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

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

8.2. מקלדת

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

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

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 רגילה
  • חייבים ליישם את Android Debug Bridge על USB (כמתואר בסעיף 7)
  • חייבים ליישם את מפרט האחסון המוני USB, כדי לאפשר למארח המחובר למכשיר לגשת לתוכן של אמצעי האחסון /sdcard
  • צריך להשתמש ב-micro USB form factor בצד המכשיר
  • עשוי לכלול יציאה לא סטנדרטית בצד המכשיר, אך אם כן יש לשלוח עם כבל המסוגל לחבר את ה-Pinout המותאם אישית ליציאת USB-A רגילה
  • צריך ליישם תמיכה במפרט ה-USB Storage Mass (כך שניתן לגשת לאחסון נשלף או קבוע במכשיר ממחשב מארח)

8.7. מקשי ניווט

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

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

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

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

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

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

8.9. מַצלֵמָה

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

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

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

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

יישומי מכשירים חייבים ליישם את ה-API המלא של המצלמה הכלול בתיעוד Android 2.2 SDK [ משאבים, 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 הרץ או יותר. מערכת הקואורדינטות המשמשת את המצפן חייבת להתאים למערכת הקואורדינטות של חיישני אנדרואיד כפי שהוגדרה ב-Android API (ראה [ משאבים, 28 ]).

8.12. ג'י.פי. אס

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

8.13. טלפוניה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.16. בלוטות

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

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

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

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

מֶטרִי סף ביצועים הערות
זמן הפעלת האפליקציה היישומים הבאים אמורים להפעיל בתוך הזמן שצוין.
  • דפדפן: פחות מ-1300ms
  • MMS/SMS: פחות מ-700ms
  • שעון מעורר: פחות מ-650ms
זמן ההשקה נמדד כזמן הכולל להשלמת הטעינה של פעילות ברירת המחדל של האפליקציה, כולל הזמן שלוקח להפעיל את תהליך לינוקס, לטעון את חבילת האנדרואיד ל-Dalvik VM ולהתקשר ל-onCreate.
יישומים סימולטניים כאשר מספר יישומים הושקו, הפעלה מחדש של אפליקציה שכבר פועלת לאחר ההפעלה חייבת לקחת פחות מזמן ההשקה המקורי.

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

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

10.1. הרשאות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11. חבילת בדיקת תאימות

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

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

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

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

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

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

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

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

13. צור קשר

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

נספח א' - נוהל בדיקת בלוטות'

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

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.