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

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

1. מבוא

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

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

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

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

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

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

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

2. סוגי מכשירים

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

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

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

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

• חייב להיות לו מסך מוטמע או יציאת וידאו, כמו VGA,‏ HDMI או יציאה אלחוטית להצגה.
• חובה להצהיר על התכונות android.software.leanback ו-android.hardware.type.television [משאבים, 3].

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

• חובה שיהיה לו מסך עם אורך אלכסוני פיזי בטווח של 1.1 עד 2.5 אינץ'.
• חובה להצהיר על התכונה android.hardware.type.watch.
• חובה לתמוך ב-uiMode = UI_MODE_TYPE_WATCH‏ [משאבים, 4].

הטמעת Android Automotive מתייחסת ליחידת ראש של רכב שפועלת ב-Android כמערכת הפעלה לחלק מהפונקציונליות של המערכת ו/או של מערכת המידע והבידור, או לכל הפונקציונליות הזו. הטמעות של Android Automotive חייבות לתמוך ב-uiMode = UI_MODE_TYPE_CAR‏ [Resources, 111].

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

2.1 הגדרות המכשיר

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

קטגוריה	תכונה	קטע	מוחזקת ביד	טלוויזיה	צפייה	Automotive	אחר
קלט	לחצני החיצים (D-pad)	7.2.2. ניווט ללא מגע		MUST
	מסך מגע	7.2.4. קלט במסך מגע	MUST		MUST		צריך
	מיקרופון	7.8.1. מיקרופון	MUST	צריך	MUST	MUST	צריך
חיישנים	מד תאוצה	7.3.1 תאוצה	צריך		צריך		צריך
	GPS	7.3.3. GPS	צריך			צריך
קישוריות	Wi-Fi	7.4.2. IEEE 802.11	צריך	MUST		צריך	צריך
	Wi-Fi ישיר	7.4.2.1. Wi-Fi ישיר	צריך	צריך			צריך
	Bluetooth	7.4.3. Bluetooth	צריך	MUST	MUST	MUST	צריך
	Bluetooth עם צריכת אנרגיה נמוכה (BLE)	7.4.3. Bluetooth	צריך	MUST	צריך	צריך	צריך
	מצב ציוד היקפי/מארח ב-USB	7.7. USB	צריך			צריך	צריך
פלט	יציאות של רמקולים ו/או אודיו	7.8.2. פלט אודיו	MUST	MUST		MUST	MUST

3. תוכנות

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

סביבת הביצוע המנוהלת של בייטקוד Dalvik היא הכלי העיקרי להרצת אפליקציות Android. ממשק תכנות האפליקציות (API) של Android הוא קבוצת הממשקים של פלטפורמת Android שנחשפים לאפליקציות שפועלות בסביבת זמן הריצה המנוהלת. הטמעות במכשירים חייבות לספק הטמעות מלאות, כולל כל ההתנהגויות המתועדות, של כל ממשק API מתועד שחשוף על ידי Android SDK‏ [מקורות מידע, 5] או כל ממשק API שמסומן בסימן '‎@SystemApi' בקוד המקור של Android במקור.

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

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

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

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

3.2.1. הרשאות

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

3.2.2. פרמטרים של build

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

פרמטר	פרטים
VERSION.RELEASE	הגרסה של מערכת Android שפועלת כרגע, בפורמט קריא לבני אדם. השדה הזה חייב לכלול אחד מערכי המחרוזות שמוגדרים בקטע [Resources, 8].
VERSION.SDK	הגרסה של מערכת Android שפועלת כרגע, בפורמט שגלוי לקוד של אפליקציות של צד שלישי. ב-Android 5.1, השדה הזה חייב לכלול את הערך המלא 22.
VERSION.SDK_INT	הגרסה של מערכת Android שפועלת כרגע, בפורמט שגלוי לקוד של אפליקציות של צד שלישי. ב-Android 5.1, השדה הזה חייב לכלול את הערך המלא 22.
VERSION.INCREMENTAL	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמציין את ה-build הספציפי של מערכת Android שפועלת כרגע, בפורמט שקריא לבני אדם. אסור להשתמש שוב בערך הזה לגרסאות build שונות שזמינות למשתמשי הקצה. שימוש נפוץ בשדה הזה הוא לציין את מספר ה-build או את מזהה השינוי במערכת בקרת הגרסאות ששימשו ליצירת ה-build. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
משחקי לוח	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את החומרה הפנימית הספציפית שבה המכשיר משתמש, בפורמט שקריא לבני אדם. אפשר להשתמש בשדה הזה כדי לציין את הגרסה הספציפית של הלוח שמפעיל את המכשיר. הערך של השדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי ‎^[a-zA-Z0-9_-]+$‎.
BRAND	ערך שמשקף את שם המותג שמשויך למכשיר כפי שהוא ידוע למשתמשי הקצה. חייב להיות בפורמט שאפשר לקרוא אותו, וצריך לייצג את היצרן של המכשיר או את מותג החברה שדרכו המכשיר משווק. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי ‎“^[a-zA-Z0-9_-]+$‎”.
SUPPORTED_ABIS	השם של קבוצת ההוראות (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי.
SUPPORTED_32_BIT_ABIS	השם של קבוצת ההוראות (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי.
SUPPORTED_64_BIT_ABIS	השם של קבוצת ההוראות השנייה (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי.
CPU_ABI	השם של קבוצת ההוראות (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי.
CPU_ABI2	השם של קבוצת ההוראות השנייה (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי.
מכשיר	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם הפיתוח או שם הקוד שמזהה את ההגדרה של מאפייני החומרה ואת העיצוב התעשייתי של המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי ‎“^[a-zA-Z0-9_-]+$‎”.
FINGERPRINT	מחרוזת שמזהה באופן ייחודי את ה-build הזה. הוא אמור להיות קריא למדי לאדם. היא חייבת לפעול לפי התבנית הבאה: $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) לדוגמה: acme/myproduct/mydevice:5.1/LMYXX/3359:userdebug/test-keys האצבעית אסור שתכלול תווים של רווח לבן. אם יש תווים של רווח לבן בשדות אחרים שכלולים בתבנית שלמעלה, חובה להחליף אותם במזהה האצבע של ה-build בתווים אחרים, כמו קו תחתון (‎'_'). הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט.
חומרה	שם החומרה (משורת הפקודה של הליבה או מ-/proc). הוא אמור להיות קריא לאנשים באופן סביר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי ‎“^[a-zA-Z0-9_-]+$‎”.
HOST	מחרוזת שמזהה באופן ייחודי את המארח שבו נוצר ה-build, בפורמט שאפשר לקרוא אותו. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
מזהה	מזהה שבחר המטמיע של המכשיר כדי להפנות למהדורה ספציפית, בפורמט קריא לבני אדם. השדה הזה יכול להיות זהה ל-android.os.Build.VERSION.INCREMENTAL, אבל כדאי להגדיר בו ערך משמעותי מספיק כדי שמשתמשי הקצה יוכלו להבחין בין גרסאות build של תוכנה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי ‎“^[a-zA-Z0-9._-]+$‎”.
יצרן	השם המסחרי של יצרן הציוד המקורי (OEM) של המוצר. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
דגם	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם המכשיר כפי שהוא ידוע למשתמש הקצה. השם הזה אמור להיות זהה לשם שתחתיו המכשיר משווק ונמכר למשתמשי הקצה. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או מחרוזת ריקה ("").
מוצר	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם הפיתוח או שם הקוד של המוצר הספציפי (מק"ט), וחובה שהוא יהיה ייחודי באותה מותג. חייב להיות קריא לבני אדם, אבל לא בהכרח מיועד לצפייה על ידי משתמשי קצה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי ‎“^[a-zA-Z0-9_-]+$‎”.
SERIAL	מספר סידורי של חומרה, שחייב להיות זמין. הערך של השדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי ‎“^([a-zA-Z0-9]{6,20})$‎”.
תגים	רשימה של תגים מופרדים בפסיקים שנבחרו על ידי מי שמטמיע את המכשיר, שמבדילה עוד יותר את ה-build. השדה הזה חייב לכלול אחד מהערכים שתואמים לשלושת ההגדרות האופייניות לחתימה בפלטפורמת Android: release-keys,‏ dev-keys ו-test-keys.
שעה	ערך שמייצג את חותמת הזמן של מועד ה-build.
סוג	ערך שנבחר על ידי מי שמטמיע את המכשיר, ומציין את הגדרת זמן הריצה של ה-build. השדה הזה חייב לכלול אחד מהערכים התואמים לשלושת ההגדרות הנפוצות של Android בסביבת זמן ריצה: user,‏ userdebug או eng.
משתמש	שם או מזהה משתמש של המשתמש (או המשתמש האוטומטי) שיצר את ה-build. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").

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

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

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

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

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

הטמעות במכשירים אמורות לכלול את אפליקציות הליבה של Android בהתאם לצורך, אבל הן חייבות לכלול רכיב שמטמיע את אותם דפוסי Intent שמוגדרים בכל הרכיבים של השירותים או הפעילויות 'הציבוריים' של אפליקציות הליבה של Android. חשוב לזכור שרכיבי Activity או Service נחשבים 'ציבוריים' כשהמאפיין android:exported חסר או שהערך שלו הוא true.

3.2.3.2. שינויים מברירת המחדל של Intent

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

עם זאת, הטמעות במכשירים עשויות לספק פעילויות ברירת מחדל לדפוסי URI ספציפיים (למשל http://play.google.com), אם פעילות ברירת המחדל מספקת מסנן ספציפי יותר ל-URI של הנתונים. לדוגמה, מסנן כוונה שמציין את URI הנתונים "http://www.android.com" ספציפי יותר מסנן הדפדפן עבור "http://". הטמעות במכשירים חייבות לספק ממשק משתמש שמאפשר למשתמשים לשנות את פעילות ברירת המחדל של הכוונות.

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

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

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

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

3.2.3.5. הגדרות ברירת המחדל של האפליקציות

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

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

• חובה לפעול לפי ה-Intent android.settings.HOME_SETTINGS כדי להציג תפריט הגדרות ברירת מחדל של אפליקציה למסך הבית, אם ההטמעה במכשיר מדווחת על android.software.home_screen‏ [Resources, 10]
• חובה לספק תפריט הגדרות שיפעיל את ה-intent‏ android.provider.Telephony.ACTION_CHANGE_DEFAULT כדי להציג תיבת דו-שיח לשינוי אפליקציית ה-SMS שמוגדרת כברירת מחדל, אם ההטמעה במכשיר מדווחת על android.hardware.telephony‏ [מקורות מידע, 9]
• חובה לפעול לפי הכוונה android.settings.NFC_PAYMENT_SETTINGS כדי להציג תפריט הגדרות ברירת מחדל של האפליקציה ל'מצמידים ומשלמים', אם ההטמעה במכשיר מדווחת על android.hardware.nfc.hce‏ [מקורות מידע, 10]

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

3.3.1. ממשקי Application Binary Interface

קוד בייט של Dalvik המנוהל יכול להפעיל קוד מקומי שסופק בקובץ ה-APK של האפליקציה כקובץ ELF עם סיומת ‎.so שעבר הידור לארכיטקטורת החומרה המתאימה של המכשיר. מאחר שקוד מקורי תלוי מאוד בטכנולוגיית המעבד הבסיסית, מערכת Android מגדירה מספר ממשקי Application Binary Interface ‏ (ABI) ב-Android NDK. ההטמעות במכשירים חייבות להיות תואמות ל-ABI אחד או יותר שהוגדרו, וחובה להטמיע תאימות ל-Android NDK, כפי שמתואר בהמשך.

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

• חובה לכלול תמיכה בקוד שפועל בסביבה המנוהלת כדי לבצע קריאה לקוד מקומי, באמצעות הסמנטיקה הרגילה של Java Native Interface‏ (JNI)
• חייבת להיות תואמת למקור (כלומר תואמת לכותרת) ותואמת לבינארי (ל-ABI) לכל ספרייה נדרשת ברשימה שבהמשך
• חובה לתמוך ב-ABI המקביל ל-32 ביט אם יש תמיכה ב-ABI כלשהו ל-64 ביט
• חובה לדווח בצורה מדויקת על ממשק ה-ABI (Application Binary Interface) המקורי שנתמך במכשיר, באמצעות הפרמטרים android.os.Build.SUPPORTED_ABIS,‏ android.os.Build.SUPPORTED_32_BIT_ABIS ו-android.os.Build.SUPPORTED_64_BIT_ABIS. כל אחד מהפרמטרים האלה הוא רשימה מופרדת בפסיקים של ממשקי ABI, שממוינים מהמועדף ביותר לפחות מועדף.
• חובה לדווח, באמצעות הפרמטרים שלמעלה, רק על ממשקי ABI שמתועדים בגרסה האחרונה של Android NDK, במאמר 'מדריך למתכנת NDK | ניהול ABI' בספרייה docs/‎.
• צריך לבנות אותו באמצעות קוד המקור וקובצי הכותרת שזמינים ב-Android Open Source Project

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

• libc (ספריית C)
• libm (ספריית מתמטיקה)
• תמיכה מינימלית ב-C++‎
• ממשק JNI
• liblog (רישום ביומן ב-Android)
• libz (דחיסת Zlib)
• libdl (מקשר דינמי)
• libGLESv1_CM.so‏ (OpenGL ES 1.x)
• libGLESv2.so‏ (OpenGL ES 2.0)
• libGLESv3.so‏ (OpenGL ES 3.x)
• libEGL.so‏ (ניהול פלטפורמה מקורי של OpenGL)
• libjnigraphics.so
• libOpenSLES.so (תמיכה באודיו של OpenSL ES 1.0.1)
• libOpenMAXAL.so (תמיכה ב-OpenMAX AL 1.0.1)
• libandroid.so (תמיכה בפעילות Native ב-Android)
• libmediandk.so (תמיכה בממשקי API מקומיים של מדיה)
• תמיכה ב-OpenGL, כפי שמתואר בהמשך

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

חשוב לזכור שהטמעות במכשירים חייבות לכלול את libGLESv3.so, וחייבת להיות להן קישור סימלי (symbolic link) אל libGLESv2.so. בנוסף, חייבים לייצא את כל סמלי הפונקציות של OpenGL ES 3.1 ושל Android Extension Pack‏ [Resources, 11] כפי שמוגדרים במהדורת NDK android-21. כל הסמלים חייבים להופיע, אבל רק הפונקציות התואמות לגרסאות ולתוספים של OpenGL ES שנתמכים בפועל במכשיר צריכות להיות מוטמעות באופן מלא.

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

3.3.2. תאימות לקוד מקורי של ARM ב-32 ביט

בארכיטקטורה ARMv8 יש הוצאה משימוש של כמה פעולות של מעבדים, כולל פעולות מסוימות שמשמשות בקוד מקורי קיים. במכשירי ARM של 64 ביט, הפעולות הלא נתמכות הבאות חייבות להישאר זמינות לקוד ARM מקורי של 32 ביט, באמצעות תמיכה במעבד מקורי או באמצעות הדמיה של תוכנה:

• הוראות ל-SWP ול-SWPB
• הוראה SETEND
• פעולות חסימה של CP15ISB,‏ CP15DSB ו-CP15DMB

בגרסאות הקודמות של Android NDK, המערכת השתמשה ב-/proc/cpuinfo כדי לזהות את מאפייני המעבד מקוד ARM מקומי של 32 ביט. כדי לאפשר תאימות לאפליקציות שנוצרו באמצעות ה-NDK הזה, המכשירים חייבים לכלול את השורות הבאות ב-/proc/cpuinfo כשהן נקראות על ידי אפליקציות ARM של 32 ביט:

• 'תכונות: ', ואחריה רשימה של כל התכונות האופציונליות של מעבד ARMv7 שנתמכות במכשיר
• 'ארכיטקטורת המעבד (CPU): ', ואחריה מספר שלם שמתאר את ארכיטקטורת ה-ARM הנתמכת הגבוהה ביותר של המכשיר (למשל, 8 במכשירי ARMv8).

הדרישות האלה חלות רק כשאפליקציות ARM של 32 ביט קוראות את /proc/cpuinfo. במכשירים לא אמורים לבצע שינויים ב-/proc/cpuinfo כשאפליקציות ARM של 64 ביט או אפליקציות שאינן ARM קוראות אותו.

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

3.4.1. תאימות ל-WebView

חובה לדווח על תכונת הפלטפורמה android.software.webview בכל מכשיר שמספק הטמעה מלאה של android.webkit.WebView API, אסור לדווח עליה במכשירים ללא הטמעה מלאה של ה-API. ההטמעה של קוד פתוח של Android משתמשת בקוד מפרויקט Chromium כדי להטמיע את android.webkit.WebView‏ [מקורות מידע, 12]. לא ניתן לפתח חבילת בדיקות מקיפה למערכת עיבוד גרפיקה לאינטרנט, ולכן מי שמטמיע את הרכיב במכשיר חייב להשתמש בגרסה הספציפית של Chromium ב-upstream בהטמעת WebView. פרטים נוספים:

• הטמעות של android.webkit.WebView במכשירים חייבות להתבסס על ה-build של Chromium מפרויקט Android Open Source Project למקור (upstream) של Android 5.1. הגרסה הזו כוללת קבוצה ספציפית של תיקוני פונקציונליות ואבטחה ל-WebView [מקורות מידע, 13].
• מחרוזת סוכן המשתמש שמדווחת על ידי WebView חייבת להיות בפורמט הזה:

  Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD)$(WEBVIEW)) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • הערך של המחרוזת $(VERSION) חייב להיות זהה לערך של android.os.Build.VERSION.RELEASE.
  • אפשר להשמיט את המחרוזת $(WEBVIEW), אבל אם היא כלולה, היא חייבת להיות "‎; wv" כדי לציין שמדובר ב-webview
  • הערך של המחרוזת $(MODEL) חייב להיות זהה לערך של android.os.Build.MODEL.
  • הערך של המחרוזת $(BUILD) חייב להיות זהה לערך של android.os.Build.ID.
  • הערך של המחרוזת $(CHROMIUM_VER) חייב להיות הגרסה של Chromium בפרויקט הקוד הפתוח של Android ב-upstream.
  • הטמעות של מכשירים עשויות להשמיט את 'נייד' במחרוזת של סוכן המשתמש.

רכיב WebView צריך לכלול תמיכה בכמה שיותר תכונות HTML5, ואם הוא תומך בתכונה, הוא צריך לעמוד במפרט HTML5 [משאבים, 14].

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

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

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

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

• מטמון של אפליקציה/פעולה אופליין [משאבים, 15]
• התג <video> [מקורות מידע, 16]
• geolocation [Resources, 17]

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

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

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

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

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

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

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

• java.*
• javax.*
• sun.‎*
• android.*‎
• com.android.*

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

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

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

למטמיעים של מכשירים מותר להוסיף ממשקי API בהתאמה אישית, אבל אסור שממשקי ה-API האלה יהיו במרחב שמות שנמצא בבעלות של ארגון אחר או מפנה לארגון אחר. לדוגמה, אסור למטמיעים של מכשירים להוסיף ממשקי API למרחב השמות com.google.* או למרחב שמות דומה. רק Google רשאית לעשות זאת. באופן דומה, אסור ל-Google להוסיף ממשקי API למרחבי שמות של חברות אחרות. בנוסף, אם הטמעה של מכשיר כוללת ממשקי API מותאמים אישית מחוץ למרחב השמות הרגיל של Android, חובה לארוז את ממשקי ה-API האלה בספרייה משותפת של Android, כך שרק אפליקציות שמשתמשות בהם באופן מפורש (באמצעות מנגנון <uses-library>) יושפעו מהשימוש המוגבר בזיכרון של ממשקי ה-API האלה.

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

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

3.7. תאימות בסביבת זמן הריצה

הטמעות במכשירים חייבות לתמוך בפורמט המלא של קובץ Dalvik הפעלה (DEX) ובסמנטיקה ובמפרט של קוד בייט של Dalvik‏ [Resources, 20]. מי שמטמיע מכשירים צריך להשתמש ב-ART, בהטמעה של פורמט Dalvik Executable ב-upstream ובמערכת לניהול חבילות של ההטמעה של העזר.

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

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

פריסת המסך	דחיסות מסך	נפח זיכרון מינימלי לאפליקציה
קטן/רגיל	120 dpi (ldpi)	32MB
	160dpi‏ (mdpi)
	213dpi‏ (tvdpi)	48MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi‏ (xhdpi)	80MB
	400 dpi (400dpi)	96MB
	480dpi‏ (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640dpi‏ (xxxhdpi)	256MB
גדולה	120 dpi (ldpi)	32MB
	160dpi‏ (mdpi)	48MB
	213dpi‏ (tvdpi)	80MB
	240 dpi (hdpi)
	280 dpi (280dpi)	96MB
	320 dpi‏ (xhdpi)	128MB
	400 dpi (400dpi)	192MB
	480dpi‏ (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640dpi‏ (xxxhdpi)	512MB
xlarge	120 dpi (ldpi)	48MB
	160dpi‏ (mdpi)	80MB
	213dpi‏ (tvdpi)	96MB
	240 dpi (hdpi)
	280 dpi (280dpi)	144MB
	320 dpi‏ (xhdpi)	192MB
	400 dpi (400dpi)	288MB
	480dpi‏ (xxhdpi)	384MB
	560 dpi (560dpi)	576MB
	640dpi‏ (xxxhdpi)	768MB

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

3.8.1. מרכז האפליקציות (מסך הבית)

מערכת Android כוללת אפליקציית מרכז אפליקציות (מסך הבית) ותמיכה באפליקציות צד שלישי שיכולות להחליף את מרכז האפליקציות של המכשיר (מסך הבית). הטמעות במכשירים שמאפשרות לאפליקציות של צד שלישי להחליף את מסך הבית של המכשיר חייבות להצהיר על תכונת הפלטפורמה android.software.home_screen.

3.8.2. ווידג'טים

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

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

3.8.3. התראות

Android כולל ממשקי API שמאפשרים למפתחים להודיע למשתמשים על אירועים משמעותיים [מקורות מידע, 22], באמצעות תכונות החומרה והתוכנה של המכשיר.

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

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

ב-Android יש תמיכה בהתראות שונות, כמו:

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

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

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

3.8.4. חיפוש

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

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

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

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

3.8.6. עיצובים

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

מערכת Android כוללת משפחת עיצובים בשם 'Holo', שמכילה קבוצה של סגנונות מוגדרים שמפתחי אפליקציות יכולים להשתמש בהם כדי להתאים את המראה והתחושה של העיצוב ל-Holo כפי שהם מוגדרים ב-Android SDK‏ [Resources, 28]. בהטמעות במכשירים אסור לשנות אף אחד מהמאפיינים של עיצוב Holo שנחשפים לאפליקציות [מקורות מידע, 29].

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

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

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

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

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

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

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

3.8.8. מעבר בין פעילויות

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

• חובה להציג את התמונות והסרטונים האחרונים שמשויכים לחשבון כקבוצה שזזה יחד.
• חובה לתמוך בעד 20 פעילויות מוצגות.
• צריך להציג לפחות את השם של 4 פעילויות בכל פעם.
• צריך להציג את צבע ההדגשה, הסמל וכותרת המסך ב'מהזמן האחרון'.
• חובה להטמיע את ההתנהגות של הצמדת המסך [משאבים, 33] ולספק למשתמש תפריט הגדרות כדי להפעיל או להשבית את התכונה.
• צריך להציג אמצעי סגירה ('x'), אבל אפשר להשהות את הצגת האפשרות הזו עד שהמשתמש יתקשר עם המסכים.

מומלץ מאוד להשתמש בממשק המשתמש של Android (או בממשק דומה שמבוסס על תמונות ממוזערות) במסך הסקירה הכללית כשמטמיעים את הקוד במכשיר.

3.8.9. ניהול קלט

Android כולל תמיכה בניהול קלט ותמיכה בעורכי שיטות קלט של צד שלישי [משאבים, 34]. הטמעות במכשירים שמאפשרות למשתמשים להשתמש בשיטות קלט של צד שלישי במכשיר חייבות להצהיר על תכונת הפלטפורמה android.software.input_methods ולתמוך בממשקי IME API כפי שמוגדר במסמכי התיעוד של Android SDK.

הטמעות של מכשירים שמצהירות על התכונה android.software.input_methods חייבות לספק מנגנון שגלוי למשתמשים כדי להוסיף שיטות קלט של צד שלישי ולהגדיר אותן. בהטמעות במכשירים חובה להציג את ממשק ההגדרות בתגובה ל-intent‏ android.settings.INPUT_METHOD_SETTINGS.

3.8.10. שליטה במדיה במסך הנעילה

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

3.8.11. חלומות

מערכת Android כוללת תמיכה בשומרי מסך אינטראקטיביים שנקראים Dreams‏ [מקורות מידע, 36]. Dreams מאפשר למשתמשים לקיים אינטראקציה עם אפליקציות כשהמכשיר מחובר למקור חשמל, לא פעיל או מחובר למטען שולחני. אפשר להטמיע את Dreams במכשירי Android Watch, אבל סוגים אחרים של הטמעות במכשירים צריכים לכלול תמיכה ב-Dreams ולספק אפשרות הגדרות למשתמשים כדי להגדיר את Dreams בתגובה ל-Intent android.settings.DREAM_SETTINGS.

3.8.12. מיקום

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

3.8.13. Unicode וגופן

ב-Android יש תמיכה בתווי אמוג'י צבעוניים. כשהטמעות במכשירי Android כוללות IME, המכשירים אמורים לספק למשתמש שיטת קלט לסמלי האמוג'י שמוגדרים ב-Unicode 6.1‏ [מקורות מידע, 38]. כל המכשירים חייבים להיות מסוגלים להציג את תווים האמוג'י האלה כגליפים צבעוניים.

מערכת Android כוללת תמיכה בגופן Roboto 2 בצבעים שונים – sans-serif-thin,‏ sans-serif-light,‏ sans-serif-medium,‏ sans-serif-black,‏ sans-serif-condensed,‏ sans-serif-condensed-light – וכל הגופנים האלה חייבים להיכלל בשפות הזמינות במכשיר, ובכיסוי המלא של Unicode 7.0 בשפות הלטינית, היוונית והקירילית, כולל טווחי A,‏ B,‏ C ו-D של הלטינית המורחבת, וכל הגליפים בבלוק של סמלי המטבעות ב-Unicode 7.0.

3.9. ניהול מכשירים

מערכת Android כוללת תכונות שמאפשרות לאפליקציות עם תמיכה באבטחה לבצע פונקציות של ניהול המכשיר ברמת המערכת, כמו אכיפת מדיניות סיסמאות או ביצוע מחיקה מרחוק, באמצעות Android Device Administration API‏ [משאבים, 39]. בהטמעות של מכשירים חייבת להיות הטמעה של המחלקה DevicePolicyManager‏ [Resources, 40]. הטמעות של מכשירים שכוללות תמיכה במסכי נעילה שמבוססים על קוד אימות (מספרי) או על סיסמה (אלפאנומריים) חייבות לתמוך במגוון המלא של כללי המדיניות לניהול המכשיר שמוגדרים במסמכי התיעוד של Android SDK‏ [משאבים, 39] ולדווח על תכונת הפלטפורמה android.software.device_admin.

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

3.10. נגישות

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

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

• הטמעות של Android Automotive אמורות לספק הטמעה של מסגרת הנגישות של Android בהתאם להטמעה שמוגדרת כברירת מחדל ב-Android.
• הטמעות במכשירים (לא כולל Android Automotive) חייבות לספק הטמעה של מסגרת הנגישות של Android בהתאם להטמעה שמוגדרת כברירת מחדל ב-Android.
• הטמעות במכשירים (לא כולל Android Automotive) חייבות לתמוך בהטמעות של שירותי נגישות של צד שלישי באמצעות ממשקי ה-API של android.accessibilityservice‏[מקורות מידע, 43]
• הטמעות במכשירים (לא כולל Android Automotive) חייבות ליצור אירועי AccessibilityEvents ולשלוח את האירועים האלה לכל הטמעות AccessibilityService הרשומים באופן שתואם להטמעה שמוגדרת כברירת מחדל ב-Android.
• הטמעות במכשירים (לא כולל מכשירי Android Automotive ו-Android Watch ללא יציאת אודיו) חייבות לספק מנגנון שזמין למשתמשים להפעלה ולהשבתה של שירותי הנגישות, וחייבות להציג את הממשק הזה בתגובה לכוונה android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.

בנוסף, הטמעות במכשירים אמורות לספק הטמעה של שירות נגישות במכשיר, וכן מנגנון שמאפשר למשתמשים להפעיל את שירות הנגישות במהלך הגדרת המכשיר. אפשר למצוא הטמעה של שירות נגישות בקוד פתוח בפרויקט Eyes Free‏ [משאבים, 44].

3.11. המרת טקסט לדיבור (TTS)

Android כולל ממשקי API שמאפשרים לאפליקציות להשתמש בשירותי המרה של טקסט לדיבור (TTS), ומאפשרים לספקי שירותים לספק הטמעות של שירותי TTS [מקורות מידע, 45]. הטמעות של מכשירים שמדווחות על התכונה android.hardware.audio.output חייבות לעמוד בדרישות הבאות שקשורות למסגרת ה-TTS של Android.

הטמעות של Android Automotive:

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

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

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

3.12. TV Input Framework

Android Television Input Framework‏ (TIF) מפשט את העברת התוכן בשידור חי למכשירי Android Television. TIF מספק ממשק API סטנדרטי ליצירת מודולי קלט ששולטים במכשירי Android Television. הטמעות של מכשירי Android Television חייבות לתמוך ב-Television Input Framework‏ [Resources, 46].

הטמעות של מכשירים שתומכות ב-TIF חייבות להצהיר על תכונת הפלטפורמה android.software.live_tv.

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

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

אסור להרחיב את הטמעות המכשירים בפורמטים של קובצי APK‏ [משאבים, 48], Android Manifest‏ [משאבים, 49], קוד בינארי של Dalvik‏ [משאבים, 20] או קוד בינארי של RenderScript, באופן שימנע את ההתקנה וההפעלה הנכונה של הקבצים האלה במכשירים תואמים אחרים.

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

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

הטמעות במכשירים חייבות לתמוך בפורמטים המרכזיים של המדיה שצוינו במסמכי התיעוד של Android SDK‏ [משאבים, 50], למעט במקרים שבהם צוין במפורש במסמך הזה שאפשר להשתמש בפורמטים אחרים. באופן ספציפי, הטמעות במכשירים חייבות לתמוך בפורמטים של מדיה, בקודקים, בפענוחים, בסוגי קבצים ובפורמטים של קונטיינרים שמוגדרים בטבלאות שבהמשך, ודווחים באמצעות MediaCodecList‏ [Resources,112]. הטמעות במכשירים חייבות גם להיות מסוגלות לפענח את כל הפרופילים שדווחו ב-CamcorderProfile‏[משאבים, 113]. כל הקודקים האלה זמינים כהטמעות תוכנה בהטמעה המועדפת של Android מ-Android Open Source Project.

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

5.1.1. קודקי אודיו

פורמט/קודק	במקודד	מפענח	פרטים	סוגי קבצים/פורמטים של קובצי מאגר נתמכים
פרופיל MPEG-4 AAC (AAC LC)	חובה1	חובה	תמיכה בתוכן מונו/סטריאו/5.0/5.12 עם תדירות דגימה רגילה של 8 עד 48kHz.	3GPP‏ (‎.3gp) MPEG-4‏ (‎.mp4,‏ ‎.m4a) AAC גולמי ADTS‏ (‎.aac, ‏ פענוח ב-Android 3.1 ואילך, קידוד ב-Android 4.0 ואילך, לא תומך ב-ADIF) MPEG-TS‏ (‎.ts, לא ניתן לדלג, Android 3.0 ואילך)
פרופיל MPEG-4 HE AAC‏ (AAC+)	חובה1 (Android 4.1 ואילך)	חובה	תמיכה בתוכן מונו/סטריאו/5.0/5.12 עם תדירויות דגימה רגילות של 16 עד 48kHz.
MPEG-4 HE AACv2 פרופיל (enhanced AAC+)		חובה	תמיכה בתוכן מונו/סטריאו/5.0/5.12 עם תדירויות דגימה רגילות של 16 עד 48kHz.
AAC ELD (AAC משופר עם זמן אחזור נמוך)	חובה1 (Android 4.1 ואילך)	חובה (Android 4.1 ואילך)	תמיכה בתוכן מונו/סטריאו עם תדירויות דגימה רגילות של 16 עד 48kHz.
AMR-NB	חובה3	חובה3	4.75 עד 12.2kbps דגימה ב-8kHz	3GPP‏ (‎.3gp)
AMR-WB	חובה3	חובה3	9 שיעורי דגימה מ-6.60kbit/s עד 23.85kbit/s, בתדירות דגימה של 16kHz
FLAC		חובה (Android 3.1 ואילך)	מונו/סטריאו (ללא ערוצים מרובים). תדירויות דגימה של עד 48kHz (אבל מומלץ להשתמש בתדירויות של עד 44.1kHz במכשירים עם פלט של 44.1kHz, כי המכשיר להקטנת תדירות הדגימה מ-48kHz ל-44.1kHz לא כולל מסנן מסוג 'מסנן מסנן נמוך'). מומלץ 16 ביט. לא חל דיטיר על 24 ביט.	FLAC‏ (‎.flac) בלבד
MP3		חובה	מונו/סטריאו 8-320Kbps קבוע (CBR) או קצב העברת נתונים משתנה (VBR)	MP3‏ (‎.mp3)
MIDI		חובה	MIDI מסוג 0 ו-1. DLS גרסה 1 ו-2. XMF ו-Mobile XMF. תמיכה בפורמטים של רינגטונים RTTTL/RTX,‏ OTA ו-iMelody	סוג 0 ו-1 (‎.mid,‏ ‎.xmf,‏ ‎.mxmf) RTTTL/RTX‏ (‎.rtttl, ‎.rtx) OTA‏ (‎.ota) iMelody‏ (‎.imy)
Vorbis		חובה		Ogg‏ (‎.ogg) Matroska‏ (‎.mkv, Android 4.0 ואילך)
PCM/WAVE	חובה4 (Android 4.1 ואילך)	חובה	PCM לינאריים של 16 ביט (שיעורים עד למגבלת החומרה). המכשירים חייבים לתמוך בשיעורי דגימה להקלטה של PCM גולמי בתדרים של 8,000,‏ 11,025,‏ 16,000 ו-44,100Hz.	WAVE‏ (‎.wav)
Opus		חובה (Android 5.0 ואילך)		Matroska‏ (‎.mkv)

1 חובה להטמעות במכשירים שמגדירות את android.hardware.microphone, אבל אופציונלי להטמעות במכשירי Android Watch.

2 נדרש רק דאונמיקס של תוכן 5.0/5.1. הקלטה או עיבוד של יותר מ-2 ערוצים הם אופציונליים.

3 נדרש להטמעות במכשירי Android ניידים.

4 נדרשת להטמעות במכשירים שמגדירות את android.hardware.microphone, כולל הטמעות במכשירי Android Watch.

5.1.2. קודיקים של תמונות

פורמט/קודק	במקודד	מפענח	פרטים	סוגי קבצים/פורמטים של קובצי מאגר נתמכים
JPEG	חובה	חובה	Base+progressive	JPEG‏ (‎.jpg)
GIF		חובה		GIF ‏(‎.gif)
PNG	חובה	חובה		PNG ‏(‎.png)
BMP		חובה		BMP ‏(‎.bmp)
WebP	חובה	חובה		WebP ‏(‎.webp)

5.1.3. קודיקים של וידאו

קודיקים של וידאו הם אופציונליים להטמעות במכשירי Android Watch.

פורמט/קודק	במקודד	מפענח	פרטים	סוגי קבצים נתמכים/ פורמטים של קובצי מאגר
H.263	חובה1	חובה2		3GPP‏ (‎.3gp) MPEG-4‏ (‎.mp4)
H.264 AVC	חובה2	חובה2	פרטים נוספים זמינים בקטע 5.2 ובקטע 5.3.	3GPP‏ (‎.3gp) MPEG-4‏ (‎.mp4) MPEG-TS‏ (‎.ts, אודיו AAC בלבד, לא ניתן לדלג, Android 3.0 ואילך)
H.265 HEVC		חובה5	פרטים נוספים זמינים בקטע 5.3	MPEG-4‏ (‎.mp4)
MPEG-4 SP		חובה2		3GPP‏ (‎.3gp)
VP83	חובה2 (Android 4.3 ואילך)	חובה2 (Android 2.3.3 ואילך)	פרטים נוספים זמינים בקטע 5.2 ו5.3	WebM‏ (‎.webm) [Resources, 110 Matroska‏ (‎.mkv, Android 4.0 ואילך)4
VP9		חובה2 (Android 4.4 ואילך)	פרטים נוספים זמינים בקטע 5.3	WebM‏ (‎.webm) [מקורות מידע, 110] Matroska‏ (‎.mkv, Android 4.0 ואילך)4

1 נדרש להטמעות במכשירים שכוללות חומרת מצלמה ומגדירות את android.hardware.camera או את android.hardware.camera.front.

2 נדרשת להטמעות במכשירים, מלבד מכשירי Android Watch.

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

4 הטמעות במכשירים אמורות לתמוך בכתיבת קובצי Matroska WebM.

5 מומלץ מאוד ל-Android Automotive, אופציונלי ל-Android Watch וחובה לכל סוגי המכשירים האחרים.

5.2. קידוד וידאו

הטמעות של מכשירי Android עם תמיכה בקודק H.264 חייבות לתמוך בפרופיל הבסיסי ברמה 3 ובפרופילים הבאים של קידוד וידאו באיכות SD (Standard Definition). מומלץ שתהיה תמיכה בפרופיל הראשי ברמה 4 ובפרופילים הבאים של קידוד וידאו באיכות HD (High Definition). מומלץ מאוד להשתמש במכשירי Android TV כדי לקידוד סרטונים באיכות HD 1080p בקצב של 30fps.

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p1	HD 1080p1
רזולוציית וידאו	320 x 240 פיקסלים	720 x 480 פיקסלים	‎1280 x 720 פיקסלים	‎1,920 x 1,080 פיקסלים
קצב מסגרות של סרטון	20 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)
קצב העברת נתונים של וידאו	384 Kbps	2 Mbps	4Mbps	10Mbps

1 כשיש תמיכה בחומרה, אבל מומלץ מאוד במכשירי Android Television.

הטמעות של מכשירי Android עם תמיכה בקודק VP8 חייבות לתמוך בפרופילים של קידוד וידאו ב-SD, ורצוי שתתמוך בפרופילים הבאים של קידוד וידאו באיכות HD (High Definition).

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p1	HD 1080p1
רזולוציית וידאו	320 x 180 פיקסלים	640 x 360 פיקסלים	‎1280 x 720 פיקסלים	‎1,920 x 1,080 פיקסלים
קצב מסגרות של סרטון	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)
קצב העברת נתונים של וידאו	800 Kbps	2 Mbps	4Mbps	10Mbps

1 כשיש תמיכה בחומרה.

5.3. פענוח וידאו

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

הטמעות של מכשירי Android עם מקודדים של H.264 חייבות לתמוך בפרופיל Baseline ברמה 3 ובפרופילים הבאים של פענוח וידאו ב-SD, ורצוי שתתמוך בפרופילים של פענוח וידאו ב-HD. מכשירי Android Television חייבים לתמוך בפרופיל ברמה 4.2 ובפרופיל הפענוח של HD 1080p.

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p1	HD 1080p1
רזולוציית וידאו	320 x 240 פיקסלים	720 x 480 פיקסלים	‎1280 x 720 פיקסלים	‎1,920 x 1,080 פיקסלים
קצב מסגרות של סרטון	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 fps / 60 fps2	30 fps / 60 fps2
קצב העברת נתונים של וידאו	800 Kbps	2 Mbps	8Mbps	‎20 Mbps

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

2 נדרש להטמעות במכשירי Android Television.

הטמעות של מכשירי Android שתומכות בקודק VP8 כפי שמתואר בקטע 5.1.3, חייבות לתמוך בפרופילים הבאים של פענוח SD, ומומלץ שתתמוך בפרופילים של פענוח HD. מכשירי Android Television חייבים לתמוך בפרופיל הפענוח של HD 1080p.

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p1	HD 1080p1
רזולוציית וידאו	320 x 180 פיקסלים	640 x 360 פיקסלים	‎1280 x 720 פיקסלים	‎1,920 x 1,080 פיקסלים
קצב מסגרות של סרטון	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 fps / 60 fps2	30 / 60 fps2
קצב העברת נתונים של וידאו	800 Kbps	2 Mbps	8Mbps	‎20 Mbps

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

2 נדרש להטמעות במכשירי Android Television.

הטמעות של מכשירי Android, כשהן תומכות בקודק VP9 כפי שמתואר בקטע 5.1.3, חייבות לתמוך בפרופילים הבאים של פענוח וידאו ב-SD, ורצוי שתתמוך בפרופילים של פענוח וידאו ב-HD. מומלץ מאוד שמכשירי Android Television יתמכו בפרופיל הפענוח של HD 1080p, ורצוי שיתמכו בפרופיל הפענוח של UHD. כשיש תמיכה בפרופיל של פענוח סרטוני UHD, הוא חייב לתמוך בעומק צבע של 8 ביט.

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p 1	HD 1080p 2	UHD 2
רזולוציית וידאו	320 x 180 פיקסלים	640 x 360 פיקסלים	‎1280 x 720 פיקסלים	‎1,920 x 1,080 פיקסלים	3840 x 2160 פיקסלים
קצב מסגרות של סרטון	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)
קצב העברת נתונים של וידאו	600 Kbps	1.6 Mbps	4Mbps	10Mbps	‎20 Mbps

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

2 מומלץ מאוד להטמעות במכשירי Android Television כשהחומרה תומכת בכך.

הטמעות של מכשירי Android, כשהן תומכות בקודק H.265 כפי שמתואר בקטע 5.1.3, חייבות לתמוך ברמה הראשית של פרופיל Main ברמה 3 ובפרופילים הבאים של פענוח וידאו ב-SD, ורצוי שתתמוך בפרופילים של פענוח וידאו ב-HD. מכשירי Android TV אמורים לתמוך בפרופיל Main10 ברמה 5 ברמה הראשית ובפרופיל הפענוח של UHD. מומלץ מאוד שמכשירי Android Television יתמכו בפרופיל הפענוח של HD 1080p. אם יש תמיכה בפרופיל הפענוח של HD 1080p, חובה שתהיה תמיכה ברמה 4.1 של פרופיל Main

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p 1	HD 1080p 2	UHD 2
רזולוציית וידאו	352 x 288 פיקסלים	640 x 360 פיקסלים	‎1280 x 720 פיקסלים	‎1,920 x 1,080 פיקסלים	3840 x 2160 פיקסלים
קצב מסגרות של סרטון	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)
קצב העברת נתונים של וידאו	600 Kbps	1.6 Mbps	4Mbps	10Mbps	‎20 Mbps

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

2 מומלץ מאוד להטמעות במכשירי Android Television כשיש תמיכה בחומרה.

5.4. הקלטת אודיו

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

5.4.1. הקלטת אודיו בפורמט RAW

הטמעות של מכשירים שמצהירות על android.hardware.microphone חייבות לאפשר תיעוד של תוכן אודיו גולמי עם המאפיינים הבאים:

• פורמט: PCM לינארי, 16 ביט
• קצבי דגימה: 8000, ‏ 11025, ‏ 16000, ‏ 44100
• ערוצים: מונו

הטמעות של מכשירים שמצהירות על android.hardware.microphone אמורות לאפשר תיעוד של תוכן אודיו גולמי עם המאפיינים הבאים:

• פורמט: PCM לינארי, 16 ביט
• תדירות דגימה: 22050, ‏ 48000
• ערוצים: סטריאו

5.4.2. הקלטה לצורך זיהוי קולי

בנוסף למפרטי ההקלטה שלמעלה, כשאפליקציה מתחילה להקליט זרם אודיו באמצעות מקור האודיו android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:

• המכשיר אמור להציג מאפייני אמפליטודה יחסית לתחום התדרים שתואמים לקו ישר, כלומר ±3 dB, מ-100Hz עד 4,000Hz.
• יש להגדיר את רגישות הקלט של האודיו כך שמקור של רמת הספק (SPL) של 90dB בתדר 1,000Hz יניב ערך RMS של 2,500 לדגימות של 16 ביט.
• רמות האמפליטודה של PCM אמורות לעקוב באופן לינארי אחרי השינויים ב-SPL של הקלט בטווח של לפחות 30dB, מ-18dB ל-12dB ביחס ל-90dB SPL במיקרופון.
• העיוות ההרמוני הכולל צריך להיות קטן מ-1% עבור 1kHz ברמת קלט של 90dB SPL במיקרופון.
• אם יש עיבוד להפחתת רעש, חובה להשבית אותו.
• אם יש בקרת רווח אוטומטית, חובה להשבית אותה

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

5.4.3. תיעוד לצורך ניתוב מחדש של ההפעלה

המחלקה android.media.MediaRecorder.AudioSource כוללת את מקור האודיו REMOTE_SUBMIX. מכשירים שמצהירים על android.hardware.audio.output חייבים להטמיע בצורה תקינה את מקור האודיו REMOTE_SUBMIX, כך שכאשר אפליקציה משתמשת ב-android.media.AudioRecord API כדי להקליט ממקור האודיו הזה, היא יכולה לתעד תערובת של כל שידורי האודיו, מלבד:

• STREAM_RING
• STREAM_ALARM
• STREAM_NOTIFICATION

5.5. הפעלת האודיו

הטמעות של מכשירים שמצהירות על android.hardware.audio.output חייבות לעמוד בדרישות שמפורטות בקטע הזה.

5.5.1. הפעלת אודיו גולמי

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

• פורמט: PCM לינארי, 16 ביט
• קצבי דגימה: 8000, ‏ 11025, ‏ 16000, ‏ 22050, ‏ 32000, ‏ 44100
• ערוצים: מונו, סטריאו

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

• תדירות דגימה: 24000, ‏ 48000

5.5.2. אפקטים קוליים

Android מספק ממשק API להטמעת אפקטים של אודיו במכשירים [מקורות מידע, 52]. הטמעות של מכשירים שמצהירות על התכונה android.hardware.audio.output:

• חובה לתמוך בהטמעות של EFFECT_TYPE_EQUALIZER ו-EFFECT_TYPE_LOUDNESS_ENHANCER שניתן לשלוט בהן באמצעות תתי-הסוגים של AudioEffect‏, Equalizer ו-LoudnessEnhancer.
• חובה לתמוך בהטמעת ה-API של הוויזואליzer, שניתן לשלוט בו באמצעות הכיתה Visualizer.
• צריך לתמוך בהטמעות של EFFECT_TYPE_BASS_BOOST,‏ EFFECT_TYPE_ENV_REVERB,‏ EFFECT_TYPE_PRESET_REVERB ו-EFFECT_TYPE_VIRTUALIZER שניתן לשלוט בהן באמצעות תתי-הסוגים של AudioEffect:‏ BassBoost,‏ EnvironmentalReverb,‏ PresetReverb ו-Virtualizer.

5.5.3. עוצמת הקול של פלט האודיו

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

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

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

לצורך סעיף זה, נעשה שימוש בהגדרות הבאות:

• זמן אחזור של הפלט. מרווח הזמן בין הזמן שבו אפליקציה כותבת פריים של נתונים בקידוד PCM לבין הזמן שבו המאזין החיצוני יכול לשמוע את הצליל התואם או שהמתמר יכול לזהות אותו.
• זמן האחזור של פלט קר. זמן האחזור של הפלט לפריים הראשון, כשמערכת הפלט של האודיו הייתה במצב חוסר פעילות ומושבתת לפני הבקשה.
• זמן אחזור רציף של פלט. זמן האחזור של הפלט לפריימים הבאים, אחרי שהמכשיר מפעיל אודיו.
• זמן אחזור של קלט. מרווח הזמן בין הצגת אודיו חיצוני במכשיר לבין הזמן שבו אפליקציה קוראת את המסגרת התואמת של נתונים בקידוד PCM.
• זמן אחזור של קלט במצב קר. הסכום של זמן הקלט שאבד וזמן האחזור של הקלט לפריים הראשון, כשמערכת הקלט של האודיו הייתה במצב חוסר פעילות ומושבתת לפני הבקשה.
• זמן אחזור רציף של קלט. זמן האחזור של הקלט בפריימים הבאים, בזמן שהמכשיר מקליט אודיו.
• תנודות בפלטו של יציאה קרה. השונות בין מדידות נפרדות של ערכי זמן האחזור של פלט במצב מנומנם.
• תנודות קלט בזמן הפעלה ראשונית. השונות בין מדידות נפרדות של ערכי זמן האחזור של קלט במצב מנוחה.
• זמן אחזור רציף הלוך ושוב. הסכום של זמן האחזור הרציף של הקלט וזמן האחזור הרציף של הפלט, בתוספת 5 אלפיות השנייה.
• OpenSL ES PCM buffer queue API. קבוצת ממשקי ה-API של OpenSL ES שקשורים ל-PCM ב-Android NDK. אפשר לעיין במאמר NDK_root/docs/opensles/index.html.

הטמעות של מכשירים שמצהירות על android.hardware.audio.output צריכות לעמוד בדרישות הבאות לפלט אודיו או לעלות עליהן:

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

אם הטמעת המכשיר עומדת בדרישות הקטע הזה אחרי כל תהליך כיול ראשוני בשימוש ב-OpenSL ES PCM buffer queue API, לגבי זמן אחזור קבוע של פלט וזמן אחזור של פלט קר במכשיר אחד לפחות שתומך בפלט אודיו, יכול להיות שהיא תדווח על תמיכה באודיו עם זמן אחזור נמוך. לשם כך, היא תדווח על התכונה android.hardware.audio.low_latency באמצעות הכיתה android.content.pm.PackageManager‏ [Resources, 53]. לעומת זאת, אם ההטמעה במכשיר לא עומדת בדרישות האלה, אסור לדווח על תמיכה באודיו עם זמן אחזור קצר.

הטמעות של מכשירים שכוללות את android.hardware.microphone צריכות לעמוד בדרישות הבאות לגבי קלט אודיו:

• זמן אחזור של קלט קר של 100 אלפיות השנייה או פחות
• זמן אחזור רציף של קלט של 30 אלפיות השנייה או פחות
• זמן אחזור הלוך ושוב רציף של 50 אלפיות השנייה או פחות
• צמצום התנודות (jitter) של הקלט הקר

5.7. פרוטוקולי רשת

המכשירים חייבים לתמוך בפרוטוקולים של רשתות המדיה להפעלת אודיו ווידאו, כפי שמפורט במסמכי התיעוד של Android SDK‏ [מקורות מידע, 50]. באופן ספציפי, המכשירים חייבים לתמוך בפרוטוקולים הבאים של רשתות מדיה:

• RTSP‏ (RTP, ‏ SDP)
• HTTP(S) progressive streaming
• טיוטת פרוטוקול של HTTP(S) Live Streaming, גרסה 3 [מקורות מידע, 54]

5.8. Secure Media

הטמעות של מכשירים שתומכות בפלט וידאו מאובטח ויכולות לתמוך במשטחים מאובטחים חייבות להצהיר על תמיכה ב-Display.FLAG_SECURE. הטמעות של מכשירים שמצהירות על תמיכה ב-Display.FLAG_SECURE, אם הן תומכות בפרוטוקול של מסך אלחוטי, חייבות לאבטח את הקישור באמצעות מנגנון קריפטוגרפית חזק, כמו HDCP 2.x ואילך למסכים אלחוטיים של Miracast. באופן דומה, אם הם תומכים במסך חיצוני עם חיבור קווי, ההטמעות של המכשירים חייבות לתמוך ב-HDCP 1.2 ואילך. הטמעות של מכשירי Android Television חייבות לתמוך ב-HDCP 2.2 במכשירים שתומכים ברזולוציית 4K, וב-HDCP 1.4 ואילך במכשירים שתומכים ברזולוציות נמוכות יותר. ההטמעה של קוד המקור של Android במקור כוללת תמיכה במסכים אלחוטיים (Miracast) ומסוגים עם חיבור קווי (HDMI) שעומדים בדרישות האלה.

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

6.1. כלים למפתחים

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

• ממשק הגישור של Android‏ (adb) [מקורות מידע, 55]

הטמעות במכשירים חייבות לתמוך בכל הפונקציות של adb כפי שמתואר ב-Android SDK, כולל dumpsys‏ [Resources, 56]. הדימון adb בצד המכשיר חייב להיות לא פעיל כברירת מחדל, וחובה שיהיה מנגנון שזמין למשתמש כדי להפעיל את Android Debug Bridge. אם הטמעת המכשיר משמיטה את המצב 'ציוד היקפי USB', חובה להטמיע את Android Debug Bridge דרך רשת מקומית (למשל Ethernet או 802.11).

Android כולל תמיכה ב-adb מאובטח. Secure adb מאפשר להשתמש ב-adb במארחים מוכרים ומאומתים. הטמעות במכשירים חייבות לתמוך ב-adb מאובטח.

• Dalvik Debug Monitor Service‏ (ddms) [Resources, 57]

הטמעות במכשירים חייבות לתמוך בכל התכונות של DDMS כפי שמתואר ב-Android SDK. מכיוון ש-ddms משתמש ב-adb, התמיכה ב-ddms אמורה להיות לא פעילה כברירת מחדל, אבל חובה שתהיה תמיכה בכל פעם שהמשתמש מפעיל את Android Debug Bridge, כפי שמתואר למעלה.

• Monkey [Resources, 58]

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

• SysTrace [מקורות מידע, 59]

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

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

6.2. אפשרויות למפתחים

ב-Android יש תמיכה למפתחים שמאפשרת להם להגדיר הגדרות שקשורות לפיתוח אפליקציות. הטמעות במכשירים חייבות לפעול בהתאם ל-Intent‏ android.settings.APPLICATION_DEVELOPMENT_SETTINGS כדי להציג הגדרות שקשורות לפיתוח אפליקציות [משאבים, 60]. בהטמעה של Android במקור, תפריט האפשרויות למפתחים מוסתר כברירת מחדל, והמשתמשים יכולים להפעיל את האפשרויות למפתחים אחרי שלוחצים שבע (7) פעמים על הפריט בתפריט הגדרות > מידע על המכשיר > מספר Build. הטמעות במכשירים חייבות לספק חוויה עקבית של אפשרויות למפתחים. באופן ספציפי, בהטמעות במכשירים חובה להסתיר את האפשרויות למפתחים כברירת מחדל, וחובה לספק מנגנון להפעלת האפשרויות למפתחים שתואמת להטמעה של Android במקור.

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

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

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

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

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

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

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

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

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

7.1.1. הגדרת מסך

7.1.1.1. גודל מסך

מסגרת ממשק המשתמש של Android תומכת במגוון גדלים שונים של מסכים, ומאפשרת לאפליקציות לשלוח שאילתה לגבי גודל המסך של המכשיר (נקרא גם 'פריסת המסך') דרך android.content.res.Configuration.screenLayout עם SCREENLAYOUT_SIZE_MASK. הטמעות של מכשירים חייבות לדווח על גודל המסך הנכון כפי שמוגדר במסמכי התיעוד של Android SDK‏ [משאבים, 61] ומוכתב על ידי פלטפורמת Android במקור. באופן ספציפי, הטמעות במכשירים חייבות לדווח על גודל המסך הנכון בהתאם למאפייני המסך הלוגיים הבאים בפיקסלים שלא תלויים בדחיסות (dp).

• המסכים של המכשירים חייבים להיות בגודל של 426dp x 320dp לפחות ('קטן'), אלא אם מדובר במכשיר Android Watch.
• במכשירים שמדווחים על גודל מסך 'רגיל', גודל המסך חייב להיות לפחות 480‎ dp x 320‎ dp.
• במכשירים שמדווחים על גודל מסך 'גדול', גודל המסך חייב להיות לפחות 640‎ dp x 480‎ dp.
• במכשירים שמדווחים על גודל מסך 'xlarge', גודל המסך חייב להיות לפחות 960‎ dp x 720‎ dp.

בנוסף,

• למכשירי Android Watch חייב להיות מסך עם גודל פיזי של 1.1 עד 2.5 אינץ' באלכסון.
• בסוגים אחרים של הטמעות של מכשירי Android עם מסך משולב פיזית, המסך חייב להיות בגודל פיזי של לפחות 2.5 אינץ' באלכסון.

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

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

7.1.1.2. יחס הגובה-רוחב של המסך

יחס גובה-רוחב המסך חייב להיות ערך בין 1.3333‏ (4:3) ל-1.86 (כ-16:9), אבל למכשירי Android Watch יכול להיות יחס גובה-רוחב של 1.0‏ (1:1), כי בהטמעה של מכשיר כזה נעשה שימוש ב-UI_MODE_TYPE_WATCH בתור android.content.res.Configuration.uiMode.

7.1.1.3. דחיסות מסך

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

• 120 dpi (ldpi)
• 160dpi‏ (mdpi)
• 213dpi‏ (tvdpi)
• 240 dpi (hdpi)
• 280 dpi (280dpi)
• 320 dpi‏ (xhdpi)
• 400 dpi (400dpi)
• 480dpi‏ (xxhdpi)
• 560 dpi (560dpi)
• 640dpi‏ (xxxhdpi)

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

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

הטמעות במכשירים חייבות לדווח על ערכים נכונים לכל מדדי המסך שמוגדרים ב-android.util.DisplayMetrics‏ [Resources, 62], ועל אותם ערכים ללא קשר לשימוש במסך המובנה או במסך החיצוני בתור מסך ברירת המחדל.

7.1.3. כיוון מסך

המכשירים חייבים לדווח על כיווני המסך שנתמכים בהם (android.hardware.screen.portrait ו/או android.hardware.screen.landscape), ועליהם לדווח על כיוון אחד לפחות שנתמך. לדוגמה, מכשיר עם מסך אופקי קבוע, כמו טלוויזיה או מחשב נייד, צריך לדווח רק על android.hardware.screen.landscape.

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

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

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

7.1.4. האצת גרפיקה 2D ו-3D

הטמעות במכשירים חייבות לתמוך ב-OpenGL ES 1.0 וגם ב-2.0, כפי שמתואר בפירוט במסמכי התיעוד של Android SDK. יש להטמיע במכשירים תמיכה ב-OpenGL ES 3.0 או 3.1 במכשירים שיכולים לתמוך בה. הטמעות במכשירים חייבות לתמוך גם ב-Android RenderScript, כפי שמפורט במסמכי התיעוד של Android SDK‏ [Resources, 63].

הטמעות של מכשירים חייבות גם לזהות את עצמן בצורה נכונה כאלה שתומכות ב-OpenGL ES 1.0, ב-OpenGL ES 2.0, ב-OpenGL ES 3.0 או ב-OpenGL 3.1. כלומר:

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

בנוסף ל-OpenGL ES 3.1, Android מספק חבילת תוספים עם ממשקי Java‏ [Resources, 64] ותמיכה מקומית בפונקציות גרפיקה מתקדמות כמו טיסרציה ופורמט דחיסת הטקסטורות ASTC. יכול להיות שאפשר יהיה להטמיע את חבילת התוספים הזו במכשירי Android, ורק אם ההטמעה תתבצע באופן מלא, חובה לזהות את התמיכה באמצעות דגל התכונה android.hardware.opengles.aep.

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

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

מערכת Android כוללת מנגנון שמאפשר לאפליקציות להצהיר שהן רוצות להפעיל האצת חומרה לגרפיקה 2D ברמת האפליקציה, הפעילות, החלון או התצוגה באמצעות תג המניפסט android:hardwareAccelerated או קריאות ישירות ל-API [מקורות מידע, 65].

בהטמעות במכשירים חובה להפעיל את שיפור המהירות באמצעות חומרה כברירת מחדל, וחובה להשבית את שיפור המהירות באמצעות חומרה אם המפתח מבקש זאת. לשם כך, מגדירים את הערך android:hardwareAccelerated="false" או משביתים את שיפור המהירות באמצעות חומרה ישירות דרך ממשקי ה-API של Android View.

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

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

Android כולל תמיכה ב-EGL_ANDROID_RECORDABLE, מאפיין של EGLConfig שמציין אם EGLConfig תומך ברינדור ל-ANativeWindow שמקליט תמונות לסרטון. הטמעות במכשירים חייבות לתמוך בתוסף EGL_ANDROID_RECORDABLE‏ [מקורות מידע, 66].

7.1.5. מצב תאימות לאפליקציות מדור קודם

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

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

7.1.6. טכנולוגיית המסך

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

• המכשירים חייבים לתמוך במסכים שיכולים לבצע רינדור של גרפיקה צבעונית ב-16 ביט, ורצוי שתהיה תמיכה במסכים שיכולים לבצע רינדור של גרפיקה צבעונית ב-24 ביט.
• המכשירים חייבים לתמוך במסכים שיכולים לבצע רינדור של אנימציות.
• יחס הגובה-רוחב של הפיקסלים (PAR) בטכנולוגיית התצוגה שבה נעשה שימוש חייב להיות בין 0.9 ל-1.15. כלומר, יחס הגובה-רוחב של הפיקסלים חייב להיות קרוב לריבוע (1.0) עם טווח סטייה של 10% עד 15%.

7.1.7. מסכים משניים

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

7.2. התקני קלט

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

7.2.1. מקלדת

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

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

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

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

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

7.2.3. מקשי ניווט

הפונקציות 'דף הבית', 'אפליקציות אחרונות' ו'חזרה' (שמופעלות על ידי אירועי המפתחות KEYCODE_HOME,‏ KEYCODE_APP_SWITCH ו-KEYCODE_BACK, בהתאמה) הן חיוניות לתפיסה של הניווט ב-Android, ולכן:

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

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

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

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

פונקציית התפריט הוצאה משימוש לטובת סרגל הפעולות החל מגרסה 4.0 של Android. לכן, במכשירים חדשים עם Android מגרסה 5.0 ואילך אסור להטמיע לחצן פיזי ייעודי לפונקציית התפריט. לא מומלץ להטמיע במכשירים ישנים לחצן פיזי ייעודי לפונקציית התפריט, אבל אם לחצן התפריט הפיזי מוטמע במכשיר שבו פועלות אפליקציות עם targetSdkVersion‏ > 10, ההטמעה במכשיר:

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

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

Android תומך בפעולה של Assist‏ [משאבים, 69]. בהטמעות של מכשירי Android, מלבד מכשירי Android Watch, חייבת להיות למשתמש גישה לפעולה של Assistant בכל שלב במהלך הפעלת האפליקציות. מומלץ להטמיע את הפעולה 'עזרה' כלחיצה ארוכה על הלחצן הראשי או כמחווה של החלקה למעלה על מקש הבית הווירטואלי. אפשר להטמיע את הפונקציה הזו באמצעות לחצן פיזי אחר, מקש תוכנה או מחווה, אבל חובה שאפשר יהיה לגשת אליה באמצעות פעולה אחת (למשל הקשה, לחיצה כפולה או מחווה) כשמקשוני הניווט האחרים גלויים.

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

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

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

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

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

מערכת Android כוללת תמיכה במגוון מסכי מגע, משטחי מגע ומכשירים מזויפים להזנת קלט במגע. הטמעות של מכשירים עם מסך מגע משויכות למסך [מקורות מידע, 70] כך שהמשתמש מרגיש שהוא מבצע פעולות ישירות על הפריטים במסך. מכיוון שהמשתמש נוגע ישירות במסך, המערכת לא זקוקה לאמצעי עזר נוספים כדי לציין את האובייקטים שבהם מבצעים פעולות. לעומת זאת, ממשק מגע מזויף מספק מערכת קלט של משתמש שמתקרבת לקבוצת משנה של יכולות של מסך מגע. לדוגמה, עכבר או שלט רחוק שמניעים סמן במסך דומים למגע, אבל המשתמש צריך קודם להצביע או להתמקד ואז ללחוץ. מכשירים רבים לקליטת נתונים, כמו עכבר, משטח מגע, עכבר אוויר מבוסס-ג'ירו, סמן ג'ירו, ג'ויסטיק ולוח מגע עם תמיכה במספר נקודות מגע, יכולים לתמוך באינטראקציות מגע מזויפות. Android כולל את המאפיין הקבוע android.hardware.faketouch, שמתאים למכשיר קלט לא מגע (מבוסס-סמן) באיכות גבוהה, כמו עכבר או משטח מגע, שיכול לדמות בצורה הולמת קלט מבוסס-מגע (כולל תמיכה בתנועות בסיסיות), ומציין שהמכשיר תומך בקבוצת משנה של פונקציונליות של מסך מגע. הטמעות במכשירים שמצהירות על תכונת המגע המזויף חייבות לעמוד בדרישות לגבי מגע מזויף שמפורטות בסעיף 7.2.5.

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

7.2.5. קלט מגע מזויף

הטמעות של מכשירים שמצהירות על תמיכה ב-android.hardware.faketouch:

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

מכשירים שמצהירים על תמיכה ב-android.hardware.faketouch.multitouch.distinct חייבים לעמוד בדרישות של faketouch שמפורטות למעלה, וגם חייבים לתמוך במעקב נפרד אחרי שני מקורות קלט או יותר של מצביע עצמאי.

7.2.6. תמיכה בבקרי משחקים

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

7.2.6.1. מיפויים של לחצנים

הטמעות של מכשירי Android Television חייבות לתמוך במיפויי המפתחות הבאים:

לחצן	שימוש ב-HID2	Android Button
A1	0x09 0x0001	KEYCODE_BUTTON_A‏ (96)
B1	0x09 0x0002	KEYCODE_BUTTON_B‏ (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X‏ (99)
Y1	0x09 0x0005	KEYCODE_BUTTON_Y‏ (100)
D-pad up1 D-pad למטה1	0x01 0x00393	AXIS_HAT_Y4
מקש החץ שמאלה1 מקשי החיצים (D-pad) ימינה1	0x01 0x00393	AXIS_HAT_X4
לחצן הכתף השמאלי1	0x09 0x0007	KEYCODE_BUTTON_L1‏ (102)
לחצן הכתף הימני1	0x09 0x0008	KEYCODE_BUTTON_R1‏ (103)
לחיצה על מקש הלחצן הימני1	0x09 0x000E	KEYCODE_BUTTON_THUMBL‏ (106)
לחיצה על מקש ה-D-Pad הימני1	0x09 0x000F	KEYCODE_BUTTON_THUMBR‏ (107)
דף הבית1	0x0c 0x0223	KEYCODE_HOME‏ (3)
הקודם1	0x0c 0x0224	KEYCODE_BACK‏ (4)

1 [Resources, 72]

2 יש להצהיר על שימושי ה-HID שלמעלה בתוך אישור CA של משחקייה (0x01 0x0005).

3 השימוש הזה חייב לכלול ערך מינימלי לוגי של 0, ערך מקסימלי לוגי של 7, ערך מינימלי פיזי של 0, ערך מקסימלי פיזי של 315, יחידות ב-Degrees ורזולוציית דוח של 4. הערך הלוגי מוגדר כסיבוב בכיוון השעון, הרחק מהציר האנכי. לדוגמה, ערך לוגי של 0 מייצג סיבוב ללא לחיצה על לחצן למעלה, ואילו ערך לוגי של 1 מייצג סיבוב של 45 מעלות ולחיצה על שני המקשים למעלה ולשמאל.

4 [Resources, 71]

אמצעי בקרה אנלוגיים1	שימוש ב-HID	Android Button
טריגר שמאל	0x02 0x00C5	AXIS_LTRIGGER
טריגר ימני	0x02 0x00C4	AXIS_RTRIGGER
ג'ויסטיק שמאלי	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
ג'ויסטיק ימני	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 [Resources, 71]

7.2.7. שלט רחוק

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

• Search affordance (הנחיה לחיפוש). הטמעות במכשירים חייבות להפעיל את האירוע KEYCODE_SEARCH כשהמשתמש מפעיל חיפוש קולי בשלט הרחוק הפיזי או מבוסס-התוכנה.
• ניווט. כל השלטים הרחוקים של Android Television חייבים לכלול את הלחצנים 'הקודם', 'דף הבית' ו'בחירה', ותמיכה באירועים של D-pad [מקורות מידע, 72].

7.3. חיישנים

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

• חובה לדווח במדויק על נוכחות או על היעדר של חיישנים בהתאם לכיתה android.content.pm.PackageManager‏ [Resources, 53].
• חייב להחזיר רשימה מדויקת של חיישנים נתמכים באמצעות ה-method‏ SensorManager.getSensorList() ושיטות דומות.
• חייב לפעול באופן סביר בכל ממשקי ה-API האחרים של החיישנים (לדוגמה, על ידי החזרת הערך true או false בהתאם כשאפליקציות מנסים לרשום מאזינים, לא להפעיל מאזינים של חיישנים כשהחיישנים המתאימים לא נמצאים וכו').
• חובה לדווח על כל מדידות החיישן באמצעות הערכים הרלוונטיים של המערכת הבינלאומית של יחידות (metric) לכל סוג חיישן, כפי שהם מוגדרים במסמכי התיעוד של Android SDK‏ [Resources, 74].
• צריך לדווח על שעת האירוע בננו-שניות, כפי שמוגדר במסמכי התיעוד של Android SDK. השעה הזו מייצגת את השעה שבה האירוע התרחש, והיא מסונכרנת עם השעון SystemClock.elapsedRealtimeNano(). אנחנו ממליצים מאוד למכשירי Android קיימים וחדשים לעמוד בדרישות האלה, כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה, שבהן יכול להיות שהרכיב הזה יהיה נדרש. שגיאת הסנכרון אמורה להיות קצרה מ-100 אלפיות השנייה [Resources, 75].

הרשימה שלמעלה לא מקיפה. יש להתייחס להתנהגות המתועדת של Android SDK ולמסמכי התיעוד של Android Open Source בנושא חיישנים [מקורות מידע, 73] כמקור מידע מהימן.

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

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

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

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

7.3.1. מד תאוצה

מומלץ לכלול בהטמעות במכשירים מד תאוצה ב-3 צירים. מומלץ מאוד לכלול את החיישן הזה במכשירי Android Handheld ובמכשירי Android Watch. אם הטמעת המכשיר כוללת מד תאוצה ב-3 צירים, היא:

• חובה להטמיע ולדווח על חיישן TYPE_ACCELEROMETER [מקורות מידע, 78].
• חייב להיות אפשרות לדווח על אירועים בתדירות של לפחות 50Hz במכשירי Android Watch, כי למכשירים כאלה יש מגבלת צריכת חשמל מחמירה יותר, ו-100Hz בכל שאר סוגי המכשירים.
• צריך לדווח על אירועים עד 200Hz לפחות.
• חייב להיות תואם למערכת הקואורדינטות של חיישן Android כפי שמפורט בממשקי ה-API של Android‏ [מקורות מידע, 74].
• חייב להיות מסוגל למדוד מירידה חופשית עד פי ארבעה מכוח הכבידה (4g) או יותר בכל ציר.
• חייבת להיות להם רזולוציה של 8 ביט לפחות, ומומלץ שהרזולוציה שלהם תהיה 16 ביט לפחות.
• צריך לבצע כיול במהלך השימוש אם המאפיינים משתנים במהלך מחזור החיים, ולשמור את פרמטרים הפיצוי בין הפעלות מחדש של המכשיר.
• צריך לבצע פיצוי טמפרטורה.
• סטיית התקן חייבת להיות לא יותר מ-0.05 m/s^, כאשר סטיית התקן צריכה להיות מחושבת על בסיס ציר על מדגמים שנאספו במשך תקופה של לפחות 3 שניות בקצב הדגימה המהיר ביותר.
• צריך להטמיע את החיישנים המשולבים TYPE_SIGNIFICANT_MOTION,‏ TYPE_TILT_DETECTOR,‏ TYPE_STEP_DETECTOR ו-TYPE_STEP_COUNTER כפי שמתואר במסמך Android SDK. אנחנו ממליצים מאוד ליישם את החיישן המשולב TYPE_SIGNIFICANT_MOTION במכשירי Android קיימים וחדשים. אם מיישמים את אחד מהחיישנים האלה, סכום צריכת החשמל שלהם תמיד חייב להיות קטן מ-4mW, וכל אחד מהם צריך להיות קטן מ-2mW ו-0.5mW כשהמכשיר במצב דינמי או סטטי.
• אם חיישן גירוסקופ כלול, חובה להטמיע את החיישנים המשולבים TYPE_GRAVITY ו-TYPE_LINEAR_ACCELERATION, ורצוי להטמיע את החיישן המשולב TYPE_GAME_ROTATION_VECTOR. מומלץ מאוד להטמיע את החיישן TYPE_GAME_ROTATION_VECTOR במכשירי Android קיימים וחדשים.
• צריך להטמיע חיישן מורכב מסוג TYPE_ROTATION_VECTOR, אם כלול גם חיישן גירוסקופ וחיישן מגנטומטר.

7.3.2. מגנטומטר

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

• חובה להטמיע את החיישן TYPE_MAGNETIC_FIELD, ורצוי להטמיע גם את החיישן TYPE_MAGNETIC_FIELD_UNCALIBRATED. מומלץ מאוד להטמיע את החיישן TYPE_MAGNETIC_FIELD_UNCALIBRATED במכשירי Android קיימים וחדשים.
• חייבת להיות אפשרות לדווח על אירועים בתדירות של 10Hz לפחות, ומומלץ לדווח על אירועים בתדירות של 50Hz לפחות.
• חייב להיות תואם למערכת הקואורדינטות של חיישן Android כפי שמפורט בממשקי ה-API של Android‏ [מקורות מידע, 74].
• חייב להיות מסוגל למדוד בין -900 µT ל-900 µT בכל ציר לפני שהוא מגיע לרוויה.
• הערך של ההיסט של ברזל קשה חייב להיות קטן מ-700 µT, והערך צריך להיות קטן מ-200 µT. לשם כך, צריך למקם את המגנטומטר הרחק משדות מגנטיים דינמיים (שנגרמים על ידי זרם) וסטטיים (שנגרמים על ידי מגנט).
• הרזולוציה חייבת להיות שווה ל-0.6 µT או צפופה יותר, ומומלץ שהרזולוציה תהיה שווה ל-0.2 µ או צפופה יותר.
• צריך לבצע פיצוי טמפרטורה.
• חובה לתמוך בכיול אונליין ובתגמול של הטיה של חומרה קשיחה, ולשמור על פרמטרי התגמול בין אתחולים מחדש של המכשיר.
• חובה להחיל את הפיצוי של ברזל רך – אפשר לבצע את ההתאמה בזמן השימוש או במהלך ייצור המכשיר.
• סטיית התקן, מחושבת על בסיס ציר על מדגמים שנאספו במשך תקופה של לפחות 3 שניות בקצב הדגימה המהיר ביותר, לא צריכה להיות גדולה מ-0.5 µT.
• מומלץ להטמיע חיישן מורכב מסוג TYPE_ROTATION_VECTOR, אם כלול גם חיישן תאוצה וחיישן ג'ירוסקופ.
• מותר להטמיע את החיישן TYPE_GEOMAGNETIC_ROTATION_VECTOR אם מוטמע גם חיישן תאוצה. עם זאת, אם הוא מוטמע, צריך להיות לו צריכת אנרגיה של פחות מ-10mW, ורצוי שצריכת האנרגיה שלו תהיה פחות מ-3mW כשהחיישן רשום למצב באצ'ט ב-10Hz.

7.3.3. GPS

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

7.3.4. ג'ירוסקופ

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

• חובה להטמיע את החיישן TYPE_GYROSCOPE, ורצוי להטמיע גם את החיישן TYPE_GYROSCOPE_UNCALIBRATED. מומלץ מאוד להטמיע את החיישן SENSOR_TYPE_GYROSCOPE_UNCALIBRATED במכשירי Android קיימים וחדשים.
• חייב להיות מסוגל למדוד שינויים בכיוון עד 1,000 מעלות לשנייה.
• חייב להיות אפשרות לדווח על אירועים בתדירות של לפחות 50Hz במכשירי Android Watch, כי למכשירים כאלה יש מגבלת צריכת חשמל מחמירה יותר, ו-100Hz בכל שאר סוגי המכשירים.
• צריך לדווח על אירועים עד 200Hz לפחות.
• חייבת להיות רזולוציה של 12 ביט או יותר, ומומלצת רזולוציה של 16 ביט או יותר.
• חייב להיות פיצוי טמפרטורה.
• חייבים לבצע כיול ותיקון בזמן השימוש, ולשמור על הפרמטרים של התיקון בין הפעלות מחדש של המכשיר.
• סטיית התקן חייבת להיות קטנה מ-1e-7 rad^2 / s^2 לכל Hz (סטיית התקן לכל Hz, או rad^2 / s). ניתן לשנות את סטיית התקן בהתאם לשיעור הדגימה, אבל היא חייבת להיות מוגבלת בערך הזה. במילים אחרות, אם מודדים את השונות של הגירוסקופ בקצב דגימה של 1Hz, היא לא אמורה להיות גבוהה מ-1e-7 rad^2/s^2.
• צריך להטמיע חיישן מורכב מסוג TYPE_ROTATION_VECTOR, אם יש גם חיישן תאוצה וחיישן מגנטומטר.
• אם חיישן תאוצה כלול, חובה להטמיע את החיישנים המשולבים TYPE_GRAVITY ו-TYPE_LINEAR_ACCELERATION, ורצוי להטמיע את החיישן המשולב TYPE_GAME_ROTATION_VECTOR. מומלץ מאוד להטמיע את החיישן TYPE_GAME_ROTATION_VECTOR במכשירי Android קיימים וחדשים.

7.3.5. ברומטר

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

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

7.3.6. מדחום

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

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

7.3.7. פוטומטר

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

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

הטמעות במכשירים עשויות לכלול חיישן קירבה. במכשירים שיכולים לבצע שיחת וידאו ולציין ערך כלשהו מלבד PHONE_TYPE_NONE ב-getPhoneType, צריך לכלול חיישן קירבה. אם הטמעת המכשיר כוללת חיישן קירבה, היא:

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

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

7.4.1. טלפוניה

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

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

7.4.2. IEEE 802.11‏ (Wi-Fi)

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

• חובה לדווח על הדגל של תכונת החומרה android.hardware.wifi.
• חובה להטמיע את ה-API של ה-multicast כפי שמתואר במסמכי התיעוד של ה-SDK [משאבים, 79].
• חובה לתמוך ב-multicast DNS‏ (mDNS) אסור לסנן חבילות mDNS‏ (224.0.0.251) בכל שלב של הפעולה, כולל כשהמסך לא במצב פעיל.

7.4.2.1. Wi-Fi ישיר

הטמעות במכשירים צריכות לכלול תמיכה ב-Wi-Fi Direct (Wi-Fi peer-to-peer). אם הטמעת המכשיר כוללת תמיכה ב-Wi-Fi Direct, חובה להטמיע את Android API התואם כפי שמתואר במסמכי התיעוד של ה-SDK‏ [מקורות מידע, 80]. אם הטמעה של מכשיר כוללת תמיכה ב-Wi-Fi Direct, היא:

• חובה לדווח על תכונת החומרה android.hardware.wifi.direct.
• חובה שתהיה תמיכה בפעולה רגילה של Wi-Fi.
• צריכה להיות תמיכה בו-זמנית ב-Wi-Fi וב-Wi-Fi Direct.

7.4.2.2. הגדרת קישור ישיר ב-Wi-Fi דרך מנהרה

הטמעות של מכשירי Android Television חייבות לכלול תמיכה ב-Wi-Fi TDLS (Tunneled Direct Link Setup), וסוגים אחרים של הטמעות של מכשירי Android צריכים לכלול תמיכה ב-Wi-Fi TDLS כפי שמתואר במסמכי התיעוד של Android SDK‏ [Resources, 81]. אם ההטמעה של המכשיר כוללת תמיכה ב-TDLS ו-TDLS מופעל על ידי WiFiManager API, המכשיר:

• מומלץ להשתמש ב-TDLS רק כשהדבר אפשרי ומועיל.
• צריך להיות שימוש בהיגוריית כלשהי ולא להשתמש ב-TDLS כשהביצועים שלו עשויים להיות גרועים יותר מאשר דרך נקודת הגישה ל-Wi-Fi.

7.4.3. Bluetooth

ב-Android יש תמיכה ב-Bluetooth וב-Bluetooth עם צריכת אנרגיה נמוכה [מקורות מידע, 82]. הטמעות של מכשירים שכוללות תמיכה ב-Bluetooth וב-Bluetooth עם צריכת אנרגיה נמוכה חייבות להצהיר על תכונות הפלטפורמה הרלוונטיות (android.hardware.bluetooth ו-android.hardware.bluetooth_le, בהתאמה) ולהטמיע את ממשקי ה-API של הפלטפורמה. בהטמעות של מכשירים, צריך להטמיע פרופילים רלוונטיים של Bluetooth, כמו A2DP,‏ AVCP,‏ OBEX וכו', בהתאם למכשיר. הטמעות של מכשירי Android Television חייבות לכלול תמיכה ב-Bluetooth וב-Bluetooth LE.

הטמעות במכשירים שכוללות תמיכה ב-Bluetooth עם צריכת אנרגיה נמוכה:

• חובה להצהיר על תכונת החומרה android.hardware.bluetooth_le.
• חובה להפעיל את ממשקי ה-API של Bluetooth המבוססים על GATT (פרופיל מאפיין גנרי) כפי שמתואר במסמכי העזרה של ה-SDK ובמאמר [משאבים, 82].
• צריכה להיות תמיכה בהעברת הלוגיקה של הסינון לצ'יפסט של Bluetooth כשמטמיעים את API של ScanFilter‏ [מקורות מידע, 83], וחובה לדווח על הערך הנכון של המיקום שבו הלוגיקה של הסינון מוטמעת בכל פעם שמתבצעת שאילתה באמצעות השיטה android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported().
• צריכה להיות תמיכה בהעברת הסריקה האצווה לצ'יפסט של ה-Bluetooth, אבל אם אין תמיכה, חובה לדווח על 'false' בכל פעם שמתבצעת שאילתה באמצעות השיטה android.bluetooth.BluetoothAdapater.isOffloadedScanBatchingSupported().
• צריכה להיות תמיכה בפרסום מרובה עם לפחות 4 משבצות, אבל אם אין תמיכה, חייבים לדווח על 'false' בכל פעם שמתבצעת שאילתה באמצעות השיטה android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported().

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

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

• חובה לדווח על התכונה android.hardware.nfc מהשיטה android.content.pm.PackageManager.hasSystemFeature()‏ [Resources, 53].
• חייבת להיות לו אפשרות לקרוא ולכתוב הודעות NDEF באמצעות תקני ה-NFC הבאים:
  • חייב להיות מסוגל לפעול כקורא/כותב של NFC Forum (כפי שמוגדר במפרט הטכני של NFC Forum‏ NFCForum-TS-DigitalProtocol-1.0) באמצעות תקני ה-NFC הבאים:
    • NfcA‏ (ISO14443-3A)
    • NfcB‏ (ISO14443-3B)
    • NfcF‏ (JIS 6319-4)
    • IsoDep‏ (ISO 14443-4)
    • סוגי תגים של NFC Forum מס' 1, 2, 3, 4 (מוגדרים על ידי NFC Forum)
  • צריכה להיות לו אפשרות לקרוא ולכתוב הודעות NDEF באמצעות תקני ה-NFC הבאים. חשוב לזכור שתקני ה-NFC שמפורטים בהמשך מופיעים כ'מומלץ', אבל בהגדרת התאימות של גרסה עתידית הם צפויים להופיע כ'חובה'. התקנים האלה הם אופציונליים בגרסה הזו, אבל הם יהיו חובה בגרסאות עתידיות. אנחנו ממליצים מאוד למכשירים קיימים וחדשים עם גרסת Android הזו לעמוד בדרישות האלה כבר עכשיו, כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה.
  • NfcV‏ (ISO 15693)
  • חייבת להיות מסוגלת לשדר ולקבל נתונים באמצעות הפרוטוקולים והסטנדרטים הבאים של רשתות עמיתים לעמיתים:
    • ISO 18092
    • LLCP 1.0 (הוגדר על ידי NFC Forum)
    • SDP 1.0 (הוגדר על ידי NFC Forum)
    • פרוטוקול NDEF Push [משאבים, 84]
    • SNEP 1.0 (הוגדר על ידי NFC Forum)
  • חובה לכלול תמיכה ב-Android Beam‏ [משאבים, 85]:
    • חובה להטמיע את שרת ברירת המחדל של SNEP. הודעות NDEF תקינות שהתקבלו על ידי שרת SNEP שמוגדר כברירת מחדל חייבות להישלח לאפליקציות באמצעות ה-intent android.nfc.ACTION_NDEF_DISCOVERED. השבתת Android Beam בהגדרות לא מורידה את ההודעה הנכנסת מסוג NDEF.
    • חובה לפעול בהתאם ל-intent של android.settings.NFCSHARING_SETTINGS כדי להציג את ההגדרות של שיתוף ה-NFC [מקורות מידע, 86].
    • חובה להטמיע את שרת ה-NPP. הודעות שמתקבלות בשרת ה-NPP חייבות לעבור עיבוד באותו אופן שבו הן עוברות עיבוד בשרת ברירת המחדל של SNEP.
    • חובה להטמיע לקוח SNEP ולנסות לשלוח P2P NDEF יוצא לשרת SNEP שמוגדר כברירת מחדל כש-Android Beam מופעל. אם לא נמצא שרת SNEP שמוגדר כברירת מחדל, הלקוח חייב לנסות לשלוח לשרת NPP.
    • חובה לאפשר לפעילויות בחזית להגדיר את הודעת ה-NDEF היוצאת מסוג P2P באמצעות ‎android.nfc.NfcAdapter.setNdefPushMessage,‏ ‎android.nfc.NfcAdapter.setNdefPushMessageCallback ו-‎android.nfc.NfcAdapter.enableForegroundNdefPush.
    • צריך להשתמש בתנועה או באישור במסך, כמו 'מצמידים כדי להעביר', לפני שליחת הודעות NDEF יוצאות מסוג P2P.
    • צריך להפעיל את Android Beam כברירת מחדל, וצריך להיות אפשרות לשלוח ולקבל באמצעות Android Beam, גם כשמצב P2P אחר של NFC קנייני מופעל.
    • חובה לתמוך בהעברת חיבור NFC ל-Bluetooth כשהמכשיר תומך בפרופיל Bluetooth Object Push. הטמעות של מכשירים חייבות לתמוך בהעברת חיבור ל-Bluetooth כשמשתמשים ב-android.nfc.NfcAdapter.setBeamPushUris, על ידי הטמעת המפרטים 'העברת חיבור גרסה 1.2' [מקורות מידע, 87] ו'התאמה פשוטה ומאובטחת של Bluetooth באמצעות NFC גרסה 1.0' [מקורות מידע, 88] מ-NFC Forum. בהטמעה כזו חייבים להטמיע את שירות LLCP להעברה עם שם השירות urn:nfc:sn:handover לצורך החלפת הבקשה להעברה או בחירת הרשומות דרך NFC, וצריך להשתמש בפרופיל Bluetooth Object Push להעברת הנתונים בפועל ב-Bluetooth. מטעמי תאימות לעבר (כדי לשמור על תאימות למכשירי Android מגרסה 4.1), ההטמעה עדיין אמורה לקבל בקשות SNEP GET להחלפת בקשת ההעברה או רשומות נבחרות באמצעות NFC. עם זאת, לא מומלץ שההטמעה עצמה תשלח בקשות SNEP GET לביצוע העברת חיבור.
  • חובה לבצע סקירה של כל הטכנולוגיות הנתמכות במצב NFC discovery.
  • צריך להיות במצב חשיפת NFC כשהמכשיר פעיל, המסך פעיל ומסך הנעילה לא נעול.

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

מערכת Android כוללת תמיכה במצב NFC Host Card Emulation ‏ (HCE). אם הטמעת המכשיר כוללת שבב של בקר NFC שיכול לבצע HCE וניתוב של מזהה אפליקציה (AID), אז:

• חובה לדווח על הערך הקבוע של התכונה android.hardware.nfc.hce.
• חובה לתמוך בממשקי API של NFC HCE כפי שמוגדרים ב-Android SDK‏ [מקורות מידע, 10].

בנוסף, הטמעות של מכשירים עשויות לכלול תמיכה בקורא/בכותב בטכנולוגיות MIFARE הבאות.

• MIFARE Classic
• MIFARE Ultralight
• NDEF ב-MIFARE Classic

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

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

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

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

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

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

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

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

7.4.6. הגדרות סנכרון

בהטמעות במכשירים, ההגדרה של הסנכרון האוטומטי הראשי חייבת להיות מופעלת כברירת מחדל, כך שה-method‏ getMasterSyncAutomatically() מחזיר את הערך 'true' [Resources, 89].

7.5. מצלמות

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

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

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

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

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

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

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

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

7.5.3. מצלמה חיצונית

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

• חובה להצהיר על תכונת הפלטפורמה android.hardware.camera.external ועל התכונה android.hardware camera.any.
• חייבת להיות תמיכה ב-USB Video Class‏ (UVC 1.0 ואילך).
• יכול להיות שתהיה תמיכה במספר מצלמות.

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

7.5.4. התנהגות Camera API

Android כולל שתי חבילות API לגישה למצלמה. ה-API החדש יותר, android.hardware.camera2, חושף לאפליקציה אמצעי בקרה ברמה נמוכה יותר של המצלמה, כולל תהליכי סטרימינג או התפרצות יעילים ללא העתקה (zero-copy) ואמצעי בקרה לכל פריים של חשיפת התמונה, הגברה, שיפור של איזון הלבן, המרת צבעים, הסרת רעשי רקע, חידוד ועוד.

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

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

• אם אפליקציה אף פעם לא התקשרה ל-android.hardware.Camera.Parameters.setPreviewFormat(int), המכשיר חייב להשתמש ב-android.hardware.PixelFormat.YCbCr_420_SP לנתוני התצוגה המקדימה שסופקו ל-callbacks של האפליקציה.
• אם אפליקציה רושמת מופע של android.hardware.Camera.PreviewCallback והמערכת קוראת ל-method onPreviewFrame() כשפורמט התצוגה המקדימה הוא YCbCr_420_SP, הנתונים ב-byte[] ‎ שמועברים ל-onPreviewFrame()‎ חייבים להיות בפורמט הקידוד NV21. כלומר, NV21 חייב להיות ברירת המחדל.
• ב-android.hardware.Camera, הטמעות במכשירים חייבות לתמוך בפורמט YV12 (כפי שמצוין בערך הקבוע android.graphics.ImageFormat.YV12) בתצוגות המקדימות של המצלמה, גם במצלמה הקדמית וגם במצלמה האחורית. (המצלמה והקודק של הווידאו בחומרה יכולים להשתמש בכל פורמט פיקסלים מקורי, אבל ההטמעה במכשיר חייבת לתמוך בהמרה ל-YV12).
• עבור android.hardware.camera2, הטמעות במכשירים חייבות לתמוך בפורמטים android.hardware.ImageFormat.YUV_420_888 ו-android.hardware.ImageFormat.JPEG כפלט באמצעות android.media.ImageReader API.

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

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

מאחר שלא כל הטמעות המכשירים יכולות לתמוך באופן מלא בכל התכונות של android.hardware.camera2 API, הטמעות המכשירים חייבות לדווח על רמת התמיכה המתאימה באמצעות המאפיין android.info.supportedHardwareLevel, כפי שמתואר ב-Android SDK‏ [מקורות מידע, 93], ולדווח על דגלים מתאימים של תכונות מסגרת [מקורות מידע, 94].

הטמעות של מכשירים חייבות גם להצהיר על יכולות המצלמה הייחודיות שלהן ב-android.hardware.camera2 דרך המאפיין android.request.availableCapabilities ולהצהיר על דגלים מתאימים של תכונות [Resources, 94]. מכשיר חייב להגדיר את דגל התכונה אם אחד ממכשירי המצלמה המצורפים תומך בתכונה.

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

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

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

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

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

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

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

צפיפות וגודל מסך	מכשיר 32-bit	מכשיר 64-ביט
מכשירי Android Watch (בגלל מסכים קטנים יותר)	416MB	לא רלוונטי
280dpi או פחות במסכים קטנים או רגילים mdpi או פחות במסכים גדולים ldpi או פחות במסכים גדולים במיוחד	424MB	704MB
xhdpi ומעלה במסכים קטנים או רגילים hdpi ומעלה במסכים גדולים mdpi ומעלה במסכים גדולים במיוחד	512MB	832MB
400dpi או יותר במסכים קטנים/רגילים xhdpi ומעלה במסכים גדולים tvdpi ומעלה במסכים גדולים במיוחד	896MB	1,280MB
560dpi או יותר במסכים קטנים/רגילים 400dpi או יותר במסכים גדולים xhdpi ומעלה במסכים גדולים במיוחד	1,344MB	1824MB

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

הטמעות של מכשירים עם פחות מ-512MB של זיכרון שזמין לליבה ולמרחב המשתמש, אלא אם מדובר ב-Android Watch, חייבות להחזיר את הערך 'true' עבור ActivityManager.isLowRamDevice().

במכשירי Android Television חייב להיות נפח אחסון בנפח של 5GB לפחות, ובמכשירים אחרים חייב להיות נפח אחסון לא נדיף בנפח של 1.5GB לפחות לנתונים הפרטיים של האפליקציה. כלומר, מחיצה /data חייבת להיות בנפח של 5GB לפחות במכשירי Android Television, ובנפח של 1.5GB לפחות בהטמעות אחרות של המכשיר. אנחנו מומלצים מאוד להשתמש במכשירים עם Android עם נפח אחסון לא נדיף של לפחות 3GB לנתונים הפרטיים של האפליקציות, כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה.

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

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

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

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

הטמעות של מכשירים עשויות לכלול חומרה לאחסון נשלף שזמין למשתמשים, כמו חריץ לכרטיס Secure Digital ‏ (SD). אם משתמשים בחריץ הזה כדי לעמוד בדרישות של נפח האחסון המשותף, ההטמעה במכשיר:

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

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

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

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

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

ללא קשר לאחסון המשותף שבו נעשה שימוש, אם להטמעת המכשיר יש יציאת USB עם תמיכה במצב USB היקפי, היא חייבת לספק מנגנון כלשהו לגישה לתוכן של האחסון המשותף ממחשב מארח. אפשר להשתמש באחסון בנפח גדול ב-USB בהטמעות של מכשירים, אבל מומלץ להשתמש ב-Media Transfer Protocol כדי לעמוד בדרישות האלה. אם ההטמעה במכשיר תומכת בפרוטוקול העברת מדיה, היא:

• צריכה להיות תואמת למארח ה-MTP של Android, Android File Transfer‏ [Resources, 96].
• צריך לדווח על סוג מכשיר USB של 0x00.
• צריך לדווח על שם ממשק USB של 'MTP'.

7.7. USB

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

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

• חובה שאפשר יהיה לחבר את היציאה למארח USB עם יציאת USB רגילה מסוג A או מסוג C.
• היציאה אמורה להיות בפורמט USB micro-B, ‏ micro-AB או Type-C. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה, כדי שיוכלו לשדרג לגרסאות עתידיות של הפלטפורמה.
• היציאה אמורה להיות ממוקמת בחלק התחתון של המכשיר (בהתאם לכיוון הטבעי) או לאפשר סיבוב מסך תוכנה בכל האפליקציות (כולל מסך הבית), כדי שהתצוגה תתאר בצורה נכונה כשהמכשיר בכיוון שבו היציאה נמצאת בחלק התחתון. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה, כדי שיוכלו לשדרג לגרסאות עתידיות של הפלטפורמה.
• צריך להטמיע את המפרט ואת ממשק ה-API של Android Open Accessory‏ (AOA) כפי שמתואר במסמכי התיעוד של Android SDK. אם מדובר במכשיר Android לנשיאה, חובה להטמיע את ממשק ה-API של AOA. הטמעות של מכשירים שמטמיעות את מפרט AOA:
  • חובה להצהיר על תמיכה בתכונה החומרה android.hardware.usb.accessory‏ [משאבים, 97].
  • חובה להטמיע את ה-USB audio class כפי שמתואר במסמכי התיעוד של Android SDK‏ [משאבים, 98].
• צריך להטמיע תמיכה בזרימת זרם של 1.5A במהלך תנועה וצפצוף HS, כפי שמפורט במפרט הטעינה של סוללות USB, גרסה 1.2 [מקורות מידע, 99]. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה.
• הערך של iSerialNumber בתיאור המכשיר הסטנדרטי של USB חייב להיות שווה לערך של android.os.Build.SERIAL.

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

• צריך להשתמש ביציאת USB מסוג C, אם הטמעת המכשיר תומכת ב-USB 3.1.
• מותר להשתמש בפורמט יציאה לא סטנדרטי, אבל אם עושים זאת, חובה לשלוח את המכשיר עם כבל או מספר כבלים שמתאימים את היציאה ליציאת USB רגילה מסוג A או מסוג C.
• אפשר להשתמש ביציאת USB מסוג micro-AB, אבל אם כן, צריך לשלוח את המכשיר עם כבל או כבלים שמתאימים את היציאה ליציאת USB רגילה מסוג A או C.
• מומלץ מאוד להטמיע את ה-USB audio class כפי שמתואר במסמכי התיעוד של Android SDK‏ [מקורות מידע, 98].
• חובה להטמיע את Android USB host API כפי שמתואר ב-Android SDK, וחובה להצהיר על תמיכה בתכונת החומרה android.hardware.usb.host‏ [משאבים, 100].
• צריך לתמוך בטווח זרם הפלט של יציאת הטעינה במורד הזרם של 1.5A עד 5A, כפי שמפורט במפרט הטעינה של סוללות USB, גרסה 1.2 [מקורות מידע, 99].

7.8. אודיו

7.8.1. מיקרופון

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

• חובה לדווח על הערך הקבוע של התכונה android.hardware.microphone
• חייב לעמוד בדרישות להקלטת אודיו שמפורטות בקטע 5.4
• חובה לעמוד בדרישות לגבי זמן האחזור של האודיו שמפורטות בקטע 5.6

7.8.2. יעד השמע

הטמעות של מכשירים שכוללות רמקול או יציאת אודיו/מדיה למכשיר היקפי של פלט אודיו, כמו אוזניות או רמקול חיצוני:

• חובה לדווח על קבוע התכונה android.hardware.audio.output.
• חובה לעמוד בדרישות להפעלת אודיו שמפורטות בקטע 5.5.
• חייב לעמוד בדרישות לגבי זמן האחזור של האודיו שמפורטות בקטע 5.6.

לעומת זאת, אם הטמעת המכשיר לא כוללת רמקול או יציאת פלט אודיו, אסור לדווח על תכונת הפלט android.hardware.audio, וצריך להטמיע את ממשקי ה-API שקשורים לפלט האודיו לפחות כ-no-ops.

אפשר להטמיע מכשיר Android Watch עם פלט אודיו, אבל לא מומלץ לעשות זאת. לעומת זאת, חובה להטמיע פלט אודיו בסוגי מכשירים אחרים של Android ולהצהיר על android.hardware.audio.output.

7.8.2.1. יציאות אודיו אנלוגיות

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

• חובה שתהיה תמיכה בהפעלת אודיו באוזניות סטריאופוניות ובאוזניות סטריאופוניות עם מיקרופון, ורצוי שתהיה תמיכה בהקלטת אודיו מאוזניות סטריאופוניות עם מיקרופון.
• חובה לתמוך בכבלים עם מחברי אודיו TRRS לפי סדר הפינים של CTIA, ורצוי לתמוך בכבלים עם מחברי אודיו לפי סדר הפינים של OMTP.
• חובה לתמוך בזיהוי המיקרופון באביזר האודיו המחובר, אם ההטמעה במכשיר תומכת במיקרופון, ולהעביר את ההודעה android.intent.action.HEADSET_PLUG עם הערך הנוסף microphone מוגדר כ-1.
• צריך לתמוך בזיהוי ובמיפוי לקודי מפתח של 3 טווחי עכבה מקבילים הבאים בין המיקרופון לבין מוליכי הארקה בתקע האודיו:
  • 70 אוהם או פחות: KEYCODE_HEADSETHOOK
  • 210-290 אוהם: KEYCODE_VOLUME_UP
  • 360-680 אוהם: KEYCODE_VOLUME_DOWN
• צריכה להיות תמיכה בזיהוי ובמיפוי לקוד המפתח בטווח ההתנגדות המקבילה הבא בין המיקרופון לבין מוליכי הארקה בתקע האודיו:
  • 110-180 אוהם: KEYCODE_VOICE_ASSIST
• חובה להפעיל את ACTION_HEADSET_PLUG כשמחברים את המחבר, אבל רק אחרי שכל המגעים במחבר נוגעים בקטעים הרלוונטיים ביציאה.
• חייב להיות מסוגל להפעיל לפחות 150mV +/- 10% מתח יציאה בהתנגדות של 32 אוהם.
• המתח של המיקרופון חייב להיות בין 1.8V ל-2.9V.

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

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

8.1. עקביות בחוויית המשתמש

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

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

8.2. ביצועי הגישה של File I/O

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

• כתיבה רציפה. הטמעות במכשירים חייבות להבטיח ביצועי כתיבה רצופים של לפחות 5MB/s בקובץ בגודל 256MB באמצעות מאגר כתיבה של 10MB.
• כתיבה אקראית. הטמעות במכשירים חייבות להבטיח ביצועי כתיבה אקראיים של לפחות 0.5MB/s לקובץ בנפח 256MB באמצעות מאגר כתיבה של 4KB.
• קריאה רציפה. הטמעות במכשירים חייבות להבטיח ביצועי קריאה רצופים של לפחות 15MB/s בקובץ של 256MB באמצעות מאגר כתיבה של 10MB.
• קריאה אקראית. הטמעות במכשירים חייבות להבטיח ביצועי קריאה אקראית של לפחות 3.5MB/s בקובץ בנפח 256MB באמצעות מאגר כתיבה של 4KB.

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

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

9.1. הרשאות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.5. תמיכה בכמה משתמשים

Android כולל תמיכה בכמה משתמשים ותמיכה בבידוד מלא של משתמשים [מקורות מידע, 103]. אפשר להפעיל מספר משתמשים בהטמעות של מכשירים, אבל כשמפעילים מספר משתמשים, צריך לעמוד בדרישות הבאות שקשורות לתמיכה במספר משתמשים [משאבים, 104]:

• הטמעות של מכשירים שלא מגדירות את דגל התכונה android.hardware.telephony חייבות לתמוך בפרופילים מוגבלים. זוהי תכונה שמאפשרת לבעלי המכשיר לנהל משתמשים נוספים ואת היכולות שלהם במכשיר. באמצעות פרופילים מוגבלים, בעלי המכשירים יכולים להגדיר במהירות סביבות נפרדות למשתמשים נוספים, ולנהל הגבלות מפורטות יותר על האפליקציות שזמינות בסביבות האלה.
• לעומת זאת, הטמעות של מכשירים שמצהירות על דגל התכונה android.hardware.telephony חייבות להתאים להטמעה של אמצעי הבקרה ב-AOSP כדי לאפשר או להשבית למשתמשים אחרים גישה לשיחות הקוליות ולהודעות ה-SMS.
• הטמעות במכשירים חייבות לכלול, לכל משתמש, מודל אבטחה שתואם למודל האבטחה של פלטפורמת Android, כפי שמוגדר במסמך העזרה בנושא אבטחה והרשאות בממשקי ה-API [משאבים, 102].
• הטמעות במכשירים עשויות לתמוך ביצירת משתמשים ופרופילים מנוהלים באמצעות ממשקי ה-API של android.app.admin.DevicePolicyManager, ואם יש תמיכה, חובה להצהיר על דגל התכונה של הפלטפורמה android.software.managed_users.
• הטמעות של מכשירים שמצהירות על דגל התכונה android.software.managed_users חייבות להשתמש בתג הסמל של AOSP במקור כדי לייצג את האפליקציות המנוהלות ואלמנטים אחרים של תגים בממשק המשתמש, כמו 'פריטים אחרונים' ו'התראות'.
• לכל מופע משתמש במכשיר Android חייבות להיות ספריות אחסון חיצוניות נפרדות ומבודדות. הטמעות במכשירים עשויות לאחסן נתונים של כמה משתמשים באותו נפח אחסון או באותה מערכת קבצים. עם זאת, ההטמעה במכשיר חייבת לוודא שאפליקציות שנמצאות בבעלות משתמש מסוים ופועלות בשם המשתמש הזה לא יכולות להציג רשימה של נתונים שנמצאים בבעלות משתמש אחר, לקרוא אותם או לכתוב בהם. חשוב לזכור שמדיה נשלפת, כמו חריצי כרטיסי SD, יכולה לאפשר למשתמש אחד לגשת לנתונים של משתמש אחר באמצעות מחשב מארח. לכן, בהטמעות של מכשירים שמשתמשות במדיה נשלפת ל-APIs הראשיים של האחסון החיצוני, חובה להצפין את התוכן של כרטיס ה-SD אם מופעל תמיכה בכמה משתמשים, באמצעות מפתח שנשמר רק במדיה לא נשלפת שרק למערכת יש גישה אליה. מכיוון שהשינוי הזה ימנע ממחשבים מארחים לקרוא את המדיה, הטמעות של מכשירים יצטרכו לעבור ל-MTP או למערכת דומה כדי לספק למחשבים מארחים גישה לנתונים של המשתמש הנוכחי. בהתאם, אפשר להפעיל את התכונה 'שימוש בכמה משתמשים' בהטמעות של מכשירים, אבל לא מומלץ לעשות זאת אם הם משתמשים במדיה נשלפת [משאבים, 105] לאחסון חיצוני ראשי.

9.6. אזהרה לגבי SMS פרימיום

ב-Android יש תמיכה באזהרה למשתמשים על כל הודעת SMS פרימיום יוצאת [מקורות מידע, 106] . הודעות Premium SMS הן הודעות טקסט שנשלחות לשירות רשום אצל ספק, שעשויות לגרום לחיוב של המשתמש. הטמעות במכשירים שמצהירות על תמיכה ב-android.hardware.telephony חייבות להזהיר את המשתמשים לפני שליחת הודעת SMS למספרים שזוהו באמצעות ביטויים רגולריים שהוגדרו בקובץ /data/misc/sms/codes.xml במכשיר. ב-Android Open Source Project יש הטמעה שעומדת בדרישות האלה.

9.7. תכונות אבטחה בליבה

ארגז החול של Android כולל תכונות שיכולות להשתמש במערכת בקרת הגישה (MAC) של Security-Enhanced Linux‏ (SELinux) ובתכונות אבטחה אחרות בליבה של Linux. SELinux או כל תכונות אבטחה אחרות, אם הן מוטמעות מתחת למסגרת Android:

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

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

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

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

• חובה לתמוך במדיניות SELinux שמאפשרת להגדיר את מצב SELinux לפי דומיין, וחובה להגדיר את כל הדומיינים במצב אכיפה. אסור להשתמש בדומיינים במצב הרשאות רחבות, כולל דומיינים ספציפיים למכשיר או לספק.
• צריך לטעון את המדיניות מקובץ /sepolicy במכשיר.
• אסור לשנות, להשמיט או להחליף את כללי neverallow שנמצאים בקובץ sepolicy שסופק ב-upstream של פרויקט הקוד הפתוח של Android‏ (AOSP). בנוסף, המדיניות חייבת לעבור הידור עם כל כללי neverallow הקיימים, גם לדומיינים של AOSP SELinux וגם לדומיינים ספציפיים למכשיר או לספק.
• חובה לתמוך בעדכונים דינמיים של קובץ המדיניות של SELinux בלי שתידרש עדכון של קובץ האימג' של המערכת.

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

9.8. פרטיות

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

אם להטמעה במכשיר יש מנגנון שמנתב את תעבורת הנתונים ברשת דרך שרת proxy או שער VPN כברירת מחדל (לדוגמה, טעינת שירות VPN מראש עם הרשאה android.permission.CONTROL_VPN), ההטמעה במכשיר חייבת לבקש את הסכמת המשתמש לפני הפעלת המנגנון הזה.

9.9. הצפנת דיסק מלאה

אם הטמעת המכשיר תומכת במסך נעילה עם מספר PIN (מספרי) או סיסמה (אלפאנומרי), המכשיר חייב לתמוך בהצפנת דיסק מלאה של הנתונים הפרטיים של האפליקציה (מחיצה /data), וגם של המחיצה של כרטיס ה-SD אם הוא חלק קבוע ולא ניתן להסרה מהמכשיר [משאבים, 107]. במכשירים שתומכים בהצפנת דיסק מלאה, ההצפנה צריכה להיות מופעלת כל הזמן אחרי שהמשתמש משלים את חוויית השימוש במכשיר. אמנם הדרישות האלה מוצגות כ'מומלץ' לגרסה הזו של פלטפורמת Android, אבל מומלץ מאוד להשתמש בהן כי אנחנו צופים שהן ישתנו ל'חובה' בגרסאות העתידיות של Android. ההצפנה חייבת להשתמש ב-AES עם מפתח של 128 ביט (או יותר) ובמצב שמיועד לאחסון (לדוגמה, AES-XTS, ‏ AES-CBC-ESSIV). אסור לכתוב את מפתח ההצפנה לאחסון ללא הצפנה. מלבד בזמן השימוש הפעיל, מפתח ההצפנה צריך להיות מוצפן ב-AES עם מפתח הגישה של מסך הנעילה שהורחץ באמצעות אלגוריתם מתיחה איטי (למשל PBKDF2 או scrypt). אם המשתמש לא ציין קוד גישה למסך הנעילה או השבית את השימוש בקוד הגישה להצפנה, המערכת אמורה להשתמש בקוד גישה ברירת מחדל כדי לעטוף את מפתח ההצפנה. אם המכשיר מספק מאגר מפתחות שמגובים בחומרה, אלגוריתם מתיחת הסיסמה חייב להיות קשור באופן קריפטוגרפי למאגר המפתחות הזה. אסור לשלוח את מפתח ההצפנה מהמכשיר (גם אם הוא עטוף בקוד הגישה של המשתמש ו/או במפתח המקושר לחומרה). בפרויקט Android Open Source ב-upstream יש הטמעה מועדפת של התכונה הזו, שמבוססת על התכונה dm-crypt בליבה של Linux.

9.10. אתחול מאומת

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

• הצהרה על הדגל של תכונת הפלטפורמה android.software.verified_boot
• ביצוע אימות בכל רצף הפעלה
• מתחילים את האימות ממפתח חומרה שהוא Root of Trust, וממשיכים עד למחיצה של המערכת
• הטמעת כל שלב אימות כדי לבדוק את תקינות ואותנטיות כל הבייטים בשלב הבא, לפני שמריצים את הקוד בשלב הבא
• שימוש באלגוריתמים לאימות חזקים כמו ההמלצות הנוכחיות של NIST לאלגוריתמים של גיבוב (SHA-256) ולגדלים של מפתחות ציבוריים (RSA-2048)

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

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

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

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

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

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

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

10.2. CTS Verifier

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

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

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

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

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

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

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

עם זאת, אם ההטמעה במכשיר כוללת תמיכה בחיבור נתונים ללא חיוב לפי נפח, כמו פרופיל 802.11 או Bluetooth PAN (רשת אזור אישית):

• יש לתמוך בהטמעות של Android Automotive בהורדות OTA עם עדכון אופליין באמצעות הפעלה מחדש.
• כל הטמעות המכשירים האחרות חייבות לתמוך בהורדות OTA עם עדכון אופליין באמצעות הפעלה מחדש.

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

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

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

12. יומן השינויים של המסמך

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

קטע	סיכום השינוי
2. סוגי מכשירים	נוספה הגדרה להטמעה של Android לכלי רכב.
2.1 הגדרות המכשיר	נוספה עמודה להטמעה של Android לכלי רכב.
3.3.2. תאימות לקוד מקורי של ARM ב-32 ביט	נוסף קטע חדש.
3.4.1. תאימות ל-WebView	עדכון הדרישה למחרוזת של סוכן המשתמש ב-WebView כדי להתאים לשינוי בהטמעה ב-upstream.
3.4.2. תאימות לדפדפנים	הוספנו הטמעות של Android Automotive כמקרה נוסף שבו יכול להיות שלא תהיה אפליקציית דפדפן.
3.7. תאימות בסביבת זמן הריצה	עדכנו את גודל האוסף הנדרש בסביבת זמן הריצה למסכים קטנים יותר, והוסיפה דרישות לקטגוריית ה-DPI החדשה (280dpi).
3.8.3. התראות	הבהרה לגבי דרישת ההודעה להטמעות של Android Watch, ‏ Television ו-Automotive.
3.8.8. מעבר בין פעילויות	הוספת כותרות לסקירה הכללית ללא הגבלה.
3.8.10. שליטה במדיה במסך הנעילה	הבהרת הדרישות להטמעות של Android Watch ו-Automotive.
3.8.13. Unicode וגופן	דרישות מופחתות לגבי שיטת הקלט של תווים של אמוג'י.
3.9. ניהול מכשירים	הבהרה לגבי התנאי שבו נדרשת תמיכה במגוון המלא של כללי המדיניות לניהול המכשיר.
3.10. נגישות	נוספו דרישות ל-Android Automotive.
3.11. המרת טקסט לדיבור	נוספו דרישות ל-Android Automotive.
5.1. קודקים של מדיה	תמיכה חובה בפענוחי קודיקים שמדווחים על ידי CamcorderProfile.
5.1.3 קודקי וידאו	נוספו דרישות ל-Android Automotive.
5.4. הקלטת אודיו	הבהרנו את הניסוח בתחילת הקטע כדי לוודא שהדרישות מסוג 'חובה' יקראו כ'נדרש'.
7.1.1.3. דחיסות מסך	נוספה רזולוציית מסך חדשה (280dpi).
7.1.5. מצב תאימות לאפליקציות מדור קודם	נוספו דרישות ל-Android Automotive.
7.2 התקני קלט	נוספה הצהרת מבוא כללית.
7.2.1. מקלדת	נוספו דרישות ל-Android Automotive.
7.2.3. מקשי ניווט	נוספו דרישות ל-Android Automotive.
7.3.1. מד תאוצה	דרישות מקלות יותר לגבי תדירות הדיווח ב-Android Watch.
7.3.4. ג'ירוסקופ	דרישות מקלות יותר לגבי תדירות הדיווח ב-Android Watch.
7.4.3 Bluetooth	נוספו דרישות ל-Android Automotive.
7.4.4. תקשורת מטווח קצר	הבהרה לגבי התנאי שבו נדרשת Host Card Emulation.
7.6.1. נפח זיכרון ואחסון מינימלי	עדכנו את דרישות הזיכרון המינימליות למכשירים עם מסך ברזולוציה נמוכה יותר, והוסיפו את הדרישה למגבלה קבועה isLowRamDevice().
7.6.2. אחסון משותף של אפליקציות	דרישות מעודכנות כשהתמיכה בגישה למכונה המארחת היא חובה.
7.7 USB	תיקון שגיאות הקלדה בקטע USB
7.6.2. אחסון משותף של אפליקציות	דרישות מעודכנות לאפליקציות מערכת שמותקנות מראש, שמאפשרות להן לכתוב באחסון חיצוני משני.
7.6.2. אחסון משותף של אפליקציות	אפליקציות יכולות להשתמש ב-ACTION_OPEN_DOCUMENT_TREE כדי לכתוב לאחסון חיצוני משני
7.6.2. אחסון משותף של אפליקציות	להבהיר ש-‎ /sdcard יכול לשתף אחסון עם ‎ /data
7.7 USB	הסרת דרישה מיותרת ב-UMS/MTP מגרסה 7.7
7.8.1. מיקרופון	נוספו דרישות ל-Android Automotive.
8.2. ביצועי הגישה של File I/O	דרישות בהירות יותר.
9.5. תמיכה בכמה משתמשים	הצפנת כרטיס ה-SD נדרשת לאחסון החיצוני הראשי.
9.8. פרטיות	הוספנו דרישה לפרטיות לרשתות VPN שהוגדרו מראש.
9.9. הצפנת דיסק מלאה	הבהרה לגבי התנאי שבו חובה לתמוך בהצפנת דיסק מלא.
9.10. אתחול מאומת	הגדרה ברורה יותר של הפעלה מאומתת.
11. תוכנה שניתן לעדכן	הבהרה לגבי הדרישה להורדה דרך OTA: היא מותרת אבל לא חובה להטמעות של Android Automotive.

13. יצירת קשר

אתם יכולים להצטרף לפורום התאימות ל-Android [מקורות מידע, 109] ולבקש הבהרות או להעלות בעיות שלא מופיעות במסמך.

14. משאבים

1. רמות הדרישה של IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt

2. פרויקט קוד פתוח של Android: http://source.android.com/

3. תכונות של Android Television: http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK

4. תכונה של Android Watch: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH

5. הגדרות ומסמכי תיעוד של ממשקי API: http://developer.android.com/reference/packages.html

6. מידע על הרשאות ב-Android: http://developer.android.com/reference/android/Manifest.permission.html

7. מסמך העזרה של android.os.Build: http://developer.android.com/reference/android/os/Build.html

8. מחרוזות הגרסאות המותרות של Android 5.1: http://source.android.com/compatibility/5.1/versions.html

9. ספק טלפוניה: http://developer.android.com/reference/android/provider/Telephony.html

10. אמולציה של כרטיסים מבוססי מארח: http://developer.android.com/guide/topics/connectivity/nfc/hce.html

11. חבילת התוספים של Android: http://developer.android.com/guide/topics/graphics/opengl.html#aep

12. הכיתה android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html

13. תאימות ל-WebView: http://www.chromium.org/

14. HTML5: http://html.spec.whatwg.org/multipage/

15. יכולות אופליין של HTML5: http://dev.w3.org/html5/spec/Overview.html#offline

16. תג וידאו ב-HTML5: http://dev.w3.org/html5/spec/Overview.html#video

17. Geolocation API של HTML5/W3C: http://www.w3.org/TR/geolocation-API/

18. HTML5/W3C webstorage API: ‏ http://www.w3.org/TR/webstorage/

19. HTML5/W3C IndexedDB API: ‏ http://www.w3.org/TR/IndexedDB/

20. פורמט Dalvik Executable ופירוט קוד בינארי: זמינים בקוד המקור של Android, בכתובת dalvik/docs

21. AppWidgets: ‏ http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

22. התראות: http://developer.android.com/guide/topics/ui/notifiers/notifications.html

23. משאבי אפליקציה: https://developer.android.com/guide/topics/resources/available-resources.html

24. מדריך הסגנון של סמלי שורת הסטטוס: http://developer.android.com/design/style/iconography.html

25. מקורות מידע בנושא התראות: https://developer.android.com/design/patterns/notifications.html

26. מנהל החיפוש: http://developer.android.com/reference/android/app/SearchManager.html

27. הודעות Toast: http://developer.android.com/reference/android/widget/Toast.html

28. עיצובים: http://developer.android.com/guide/topics/ui/themes.html

29. הכיתה R.style: ‏ http://developer.android.com/reference/android/R.style.html

30. עיצוב חדשני תלת-ממדי: http://developer.android.com/reference/android/R.style.html#Theme_Material

31. טפטים דינמיים: http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html

32. מקורות מידע על מסך הסקירה הכללית: http://developer.android.com/guide/components/recents.html

33. הקפאת מסך: https://developer.android.com/about/versions/android-5.0.html#ScreenPinning

34. שיטות קלט: http://developer.android.com/guide/topics/text/creating-input-method.html

35. התראת מדיה: https://developer.android.com/reference/android/app/Notification.MediaStyle.html

36. Dreams: ‏ http://developer.android.com/reference/android/service/dreams/DreamService.html

37. Settings.Secure LOCATION_MODE:

http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE

38. Unicode 6.1.0: ‏ http://www.unicode.org/versions/Unicode6.1.0/

39. ניהול מכשירי Android: http://developer.android.com/guide/topics/admin/device-admin.html

40. מסמך העזרה של DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

41. אפליקציית הבעלים של מכשיר Android:

http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

42. ממשקי API של Android Accessibility Service: http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html

43. ממשקי API לנגישות ב-Android: http://developer.android.com/reference/android/view/accessibility/package-summary.html

44. פרויקט Eyes Free: http://code.google.com/p/eyes-free

45. ממשקי API להמרת טקסט לדיבור: http://developer.android.com/reference/android/speech/tts/package-summary.html

46. מסגרת קלט לטלוויזיה: ‎/devices/tv/index.html

47. מסמכי עזרה של הכלים (adb, ‏ aapt, ‏ ddms, ‏ systrace): http://developer.android.com/tools/help/index.html

48. תיאור של קובץ APK ל-Android: http://developer.android.com/guide/components/fundamentals.html

49. קובצי מניפסט: http://developer.android.com/guide/topics/manifest/manifest-intro.html

50. פורמטים של מדיה ב-Android: http://developer.android.com/guide/appendix/media-formats.html

51. דרישות לתכנות חומרה של RTC: http://www.webmproject.org/hardware/rtc-coding-requirements/

52. AudioEffect API: ‏ http://developer.android.com/reference/android/media/audiofx/AudioEffect.html

53. הכיתה android.content.pm.PackageManager של Android ורשימת תכונות החומרה:

http://developer.android.com/reference/android/content/pm/PackageManager.html

54. טיוטת פרוטוקול של HTTP Live Streaming: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

55. ADB: ‏ http://developer.android.com/tools/help/adb.html

56. Dumpsys: ‏ /devices/input/diagnostics.html

57. DDMS: ‏ http://developer.android.com/tools/debugging/ddms.html

58. כלי בדיקה של Monkey: http://developer.android.com/tools/help/monkey.html

59. הכלי SysyTrace: http://developer.android.com/tools/help/systrace.html

60. הגדרות שקשורות לפיתוח אפליקציות ל-Android:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

61. תמיכה במספר מסכים: http://developer.android.com/guide/practices/screens_support.html

62. android.util.DisplayMetrics: ‏ http://developer.android.com/reference/android/util/DisplayMetrics.html

63. ‏RenderScript: ‏ http://developer.android.com/guide/topics/renderscript/

64. חבילת התוספים של Android ל-OpenGL ES: https://developer.android.com/reference/android/opengl/GLES31Ext.html

65. שיפור המהירות באמצעות חומרה: http://developer.android.com/guide/topics/graphics/hardware-accel.html

66. תוסף EGL-‏EGL_ANDROID_RECORDABLE:

http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

67. מנהל התצוגה: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

68. android.content.res.Configuration: ‏ http://developer.android.com/reference/android/content/res/Configuration.html

69. Action Assist: ‏ http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

70. הגדרת קלט מגע: http://source.android.com/devices/tech/input/touch-devices.html

71. Motion Event API: ‏ http://developer.android.com/reference/android/view/MotionEvent.html

72. Key Event API: ‏ http://developer.android.com/reference/android/view/KeyEvent.html

73. חיישנים בקוד פתוח של Android: http://source.android.com/devices/sensors

74. android.hardware.SensorEvent: ‏ http://developer.android.com/reference/android/hardware/SensorEvent.html

75. אירוע חיישן עם חותמת זמן: http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp

76. חיישנים מורכבים בקוד פתוח של Android: /devices/sensors/sensor-types.html#composite_sensor_type_summary

77. מצב הפעלה רציף: /docs/core/interaction/sensors/report-modes#continuous

78. חיישן תאוצה: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER

79. Wi-Fi Multicast API: ‏ http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

80. Wi-Fi Direct‏ (Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

81. WifiManager API: ‏ http://developer.android.com/reference/android/net/wifi/WifiManager.html

82. Bluetooth API: ‏ http://developer.android.com/reference/android/bluetooth/package-summary.html

83. Bluetooth ScanFilter API: ‏ https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html

84. פרוטוקול NDEF Push: http://source.android.com/compatibility/ndef-push-protocol.pdf

85. Android Beam: ‏ http://developer.android.com/guide/topics/connectivity/nfc/nfc.html

86. הגדרות שיתוף ב-NFC ב-Android:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

87. העברת חיבור ב-NFC: http://members.nfc-forum.org/specs/spec_list/#conn_handover

88. התאמה פשוטה ומאובטחת של Bluetooth באמצעות NFC: http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf

89. Content Resolver: ‏ http://developer.android.com/reference/android/content/ContentResolver.html

90. Camera orientation API: ‏ http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

91. מצלמה: http://developer.android.com/reference/android/hardware/Camera.html

92. מצלמה: http://developer.android.com/reference/android/hardware/Camera.Parameters.html

93. רמת החומרה של המצלמה: https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL

94. תמיכה בגרסאות מצלמה: http://source.android.com/devices/camera/versioning.html

95. Android DownloadManager: ‏ http://developer.android.com/reference/android/app/DownloadManager.html

96. העברת קבצים ב-Android: ‏ http://www.android.com/filetransfer

97. Android Open Accessories: ‏ http://developer.android.com/guide/topics/connectivity/usb/accessory.html

98. אודיו ב-USB ל-Android: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

99. מפרט הטעינה של USB: http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf

100. USB Host API:‏ http://developer.android.com/guide/topics/connectivity/usb/host.html

101. אוזניות אודיו חוטיות: http://source.android.com//docs/core/interaction/accessories/headset/plug-headset-spec.html

102. מידע על אבטחה והרשאות ב-Android: http://developer.android.com/guide/topics/security/permissions.html

103. מסמך העזרה של UserManager: http://developer.android.com/reference/android/os/UserManager.html

104. מידע על אחסון חיצוני: http://source.android.com/docs/core/storage

105. ממשקי API של אחסון חיצוני: http://developer.android.com/reference/android/os/Environment.html

106. קוד SMS קצר: http://en.wikipedia.org/wiki/Short_code

107. Android Open Source Encryption: ‏ http://source.android.com/docs/security/features/encryption

108. סקירה כללית על תוכנית התאימות של Android: http://source.android.com//docs/compatibility

109. פורום התאימות ל-Android: https://groups.google.com/forum/#!forum/android-compatibility

110. פרויקט WebM: http://www.webmproject.org/

111. Android UI_MODE_TYPE_CAR API: ‏ http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR

112. Android MediaCodecList API: ‏ http://developer.android.com/reference/android/media/MediaCodecList.html

113. Android CamcorderProfile API: ‏ http://developer.android.com/reference/android/media/CamcorderProfile.html

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