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

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

1. הקדמה

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

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

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

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

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

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

2. משאבים

  • רמות הדרישה של IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
  • סקירה כללית של תוכנית תאימות אנדרואיד: http://source.android.com/compatibility/index.html
  • פרויקט קוד פתוח של אנדרואיד: http: //source.android.com/
  • הגדרות API ותיעוד: http://developer.android.com/reference/packages.html
  • הפניה להרשאות אנדרואיד: http://developer.android.com/reference/android/Manifest.permission. html
  • android.os.Build הפניה: http://developer.android.com/reference/android/os/Build.html
  • מחרוזות גרסה מותרות של Android 2.1: http://source.android.com/docs/compatibility/2.1/versions ‎.html
  • android.webkit.WebView class: http://developer.android.com/reference/android/webkit/WebView.html
  • HTML5: http://www.whatwg.org/specs/web-apps/current-work/ multipage/
  • מפרט מכונה וירטואלית של Dalvik: זמין בקוד המקור של Android, בכתובת dalvik/docs
  • AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  • התראות: http://developer.android.com /guide/topics/ui/notifiers/notifications.html
  • משאבי יישומים: http://code.google.com/android/reference/available-resources.html
  • מדריך סגנון סמל שורת המצב: http://developer.android.com/ guide/practices/ui_guideline /icon_design.html#statusbarstructure
  • מנהל חיפוש: http://developer.android.com/reference/android/app/SearchManager.html
  • טוסט: http://developer.android.com/reference/android/widget /Toast.html
  • רקעים חיים: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  • אפליקציות לאנדרואיד: http://code.google.com/p/apps-for-android
  • Reference תיעוד כלי (עבור adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
  • תיאור קובץ apk של Android: http://developer.android.com/guide/topics/fundamentals .html
  • קובצי מניפסט: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  • כלי בדיקת קופים: https://developer.android.com/studio/test/other-testing-tools/ Monkey
  • תומך במספר מסכים: http://developer.android.com/guide/practices/screens_support.html
  • android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration. html
  • android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  • android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera. html
  • מרחב קואורדינטת חיישן: http://developer.android.com/reference/android/hardware/SensorEvent.html
  • אבטחה והרשאות אנדרואיד: http://developer.android.com/guide/topics/security/security.html
  • Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html
  • רבים ממשאבים אלה נגזרים ישירות או בעקיפין מ-Android 2.1 SDK, ויהיו זהים מבחינה תפקודית למידע בתיעוד של SDK זה . בכל המקרים שבהם הגדרת התאימות הזו או חבילת בדיקת התאימות לא מסכימה עם תיעוד ה-SDK, תיעוד ה-SDK נחשב סמכותי. כל פרט טכני המסופק בהפניות הכלולות לעיל נחשב בהכללה כחלק מהגדרת תאימות זו.

    3. תוכנה

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

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

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

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

    3.2. תאימות API רך

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

    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 הגרסה של מערכת אנדרואיד הפועלת כעת, בפורמט נגיש לקוד אפליקציה של צד שלישי. עבור אנדרואיד 2.1, שדה זה חייב לכלול את הערך השלם 7.
    android.os.Build.VERSION.INCREMENTAL ערך שנבחר על ידי מיישם המכשיר ומייעד את המבנה הספציפי של מערכת Android הפועלת כעת, בפורמט הניתן לקריאה אנושית. אין לעשות שימוש חוזר בערך זה עבור מבנים שונים הנשלחים למשתמשי קצה. שימוש טיפוסי בשדה זה הוא לציין באיזה מספר 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.1-update1/ERC77/3359:userdebug/test-keys
    טביעת האצבע לא חייבת לכלול רווחים. אם בשדות אחרים הכלולים בתבנית לעיל יש רווחים, הם צריכים להיות מוחלפים בקו התחתון של ASCII ("_") בטביעת האצבע.
    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 רשימה מופרדת בפסיקים של תגיות שנבחרו על ידי מיישם המכשיר ומבדילות עוד יותר את ה-build. לדוגמה, "לא חתום, ניפוי באגים". שדה זה לא חייב להיות 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
    • Launcher
    • LivePicker (כלומר, אפליקציית בורר הטפטים החיים; ניתן להשמיט אם המכשיר אינו תומך בטפטים חיים, לפי סעיף 3.8.5. )
    • הודעות (AKA "Mms")
    • הגדרות
    • טלפון
    • מוזיקה
    • SoundRecorder

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

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

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

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

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

    הערה: סעיף זה שונה על ידי Erratum EX6580.

    3.2.3.3.

    מרחבי

    שמות של Intent

    לא חייבים לכלול רכיבי Android המכבדים כל דפוסי 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. Native API Compatibility

    קוד מנוהל הפועל ב-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. תאימות לממשק API של אינטרנט

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

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

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

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

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

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

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

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

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

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

    3.6. API Namespaces

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

    • java.*
    • javax.*
    • sun.*
    • android.*
    • 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 [ משאבים, 10 ].

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

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

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

    3.8.1. ווידג'טים

    אנדרואיד מגדיר סוג רכיב ו-API מתאים ומחזור חיים המאפשר לאפליקציות לחשוף "AppWidget" למשתמש הקצה [ משאבים, 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.

    אפליקציות

    Toasts

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

    3.8.5. טפטים חיים

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

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

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

    4. התייחסות

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

    • מחשבון (כלול ב-SDK)
    • Lunar Lander (כלול ב-SDK)
    • יישומי "אפליקציות לאנדרואיד" [ משאבים, 18 ].

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

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

    • ApiDemos (כלול ב-SDK)
    • ManualSmokeTests (כלול ב-CTS)

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

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

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

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

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

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

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

    שם קצב
    שמע
    מקודד מפענח פרטי קובץ /פורמט מיכל
    AAC LC/LTP   X תוכן מונו/סטריאו בכל שילוב של קצבי סיביות סטנדרטיים של עד 160 kbps וקצבי דגימה בין 8 ל-48kHz 3GPP (.3gp) ו-MPEG-4 (.mp4, .m4a). אין תמיכה ב-AAC גולמי (.aac)
    HE-AACv1 (AAC+)   X
    HE-AACv2 (AAC+ משופר)   X
    AMR-NB X X 4.75 עד 12.2 kbps בדגימה @ 8kHz 3GPP (.3gp)
    AMR-WB  X 9 מ-6.60 kbit/s ל-23.85 kbit/s בדגימה @ 16kHz 3GPP (.3gp)
    MP3   X מונו/סטריאו 8-320Kbps קבוע (CBR) או קצב סיביות משתנה (VBR) MP3 (.mp3)
    MIDI   X MIDI סוג 0 ו- 1. DLS גרסה 1 ו- 2. XMF ו- XMF נייד. תמיכה בפורמטים של רינגטון RTTTL/RTX, OTA ו- IMELODY מסוג 0 ו- 1 (.MID, .XMF, .MXMF). גם rtttl/rtx (.rtttl, .rtx), ota (.ota), ו- imelody (.imy)
    ogg vorbis   איקס   OGG (.OGG)
    PCM   X 8- ו- 16 סיביות PCM ליניאריות (שיעורים עד גבול החומרה) גל (.WAV)
    תמונה
    JPEG X X BASE+פרוגרסיבית  
    GIF   איקס   
    Png x x   
    BMP   איקס   
    וידאו
    H.263 x x   קבצי 3GPP (.3GP) קבצים
    H.264   איקס   3GPP (.3GP) ו- MPEG-4 (.MP4) קבצים
    MPEG4 פרופיל פשוט   איקס   קובץ 3GPP (.3GP)

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

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

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

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

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

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

    8.1. תצוגת

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

    עבור אנדרואיד 2.1, מדובר בתצורות התצוגה הנפוצות ביותר:

    רוחב קטן נמוך נמוך
    סוג מסך (פיקסלים) גובה (פיקסלים) טווח אורך אלכסוני (אינץ ') גודל מסך גודל קבוצת צפיפות מסך קבוצת
    QVGA 240 320 2.6 - 3.0
    WQVGA240 400 3.2 - 3.5 נמוך נמוך
    FWQVGA 240 432 3.5 - 3.8
    HVGA320 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 בינוני גדול FWVVA 480 854

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

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

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

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

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

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

    8.1.3.

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

    מדדים לתצוגה

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

    8.2.

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

    מקלדת

    :

    • חייבים לכלול תמיכה במסגרת ניהול הקלט (המאפשרת למפתחי צד ג 'ליצור מנועי ניהול קלט - כלומר מקלדת רכה) כמפורט ב- Fescener.Android.com
    • חייבים לספק לפחות יישום מקלדת רכה אחת (ללא קשר לשאלה אם A מקלדת קשה קיימת)
    • עשויה לכלול יישומי מקלדת רכים נוספים
    • עשויה לכלול מקלדת חומרה
    • אסור לכלול מקלדת חומרה שאינה תואמת את אחד הפורמטים המפורטים ב- android.content.res.Configuration.keyboard [ משאבים, 24 ] (כלומר, Qwerty, או 12-Key)

    8.3.

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

    ניווט שאינם מגעים

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

    8.4.

    מכשירים תואמים

    לאוריינטציה של מסך

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

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

    8.5.

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

    קלט של מסך מגע

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

    8.6.

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

    USB

    :

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

    8.7. מקשי ניווט פונקציות

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

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

    8.8.

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

    רשת רשתות אלחוטיות

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

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

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

    8.9.

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

    המצלמה

    חייבים לכלול מצלמה. המצלמה הכלולה:

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

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

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

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

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

    8.10.

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

    Accelerometer

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

    8.11.

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

    מצפן

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

    8.12.

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

    GPS

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

    8.13.

    ניתן להשתמש

    בטלפוניה

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

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

    8.14.

    יישומי התקני

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

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

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

    הערה: פרק זה שונה על ידי Erratum EX6580.

    8.15. יישומי התקני אחסון משותפים

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

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

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

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

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

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

    הערה : קטע זה נוסף על ידי Erratum EX6580.

    8.16.

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

    Bluetooth

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

    הערה: פרק זה נוסף על ידי Erratum EX6580.

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

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

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

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

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

    10.1.

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

    הרשאות

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

    10.2.

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

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

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

    10.3.

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

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

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

    11. יישומי מכשירי תאימות לבדיקת תאימות

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

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

    12.

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

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

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

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

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

    13. צור איתנו קשר

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