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

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

אם ההגדרה הזו או בדיקות התוכנה המתוארות בקטע 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‏ [Resources, 4]

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

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

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

קטגוריה	תכונה	Section	נייד	טלוויזיה	לצפות	אחר
קלט	לחצני החיצים (D-pad)	7.2.2. ניווט ללא מגע		MUST
	מסך מגע	7.2.4. קלט במסך מגע	MUST		MUST	צריך
	מיקרופון	7.8.1. מיקרופון	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	צריך
	Bluetooth עם צריכת אנרגיה נמוכה (BLE)	7.4.3. Bluetooth	צריך	MUST	צריך	צריך
	מצב ציוד היקפי/ מארח ב-USB	7.7. USB	צריך			צריך
פלט	יציאות של רמקולים ו/או אודיו	7.8.2. פלט אודיו	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.0, השדה הזה חייב לכלול את הערך המלא של 21.
VERSION.SDK_INT	הגרסה של מערכת Android שפועלת כרגע, בפורמט שגלוי לקוד של אפליקציות של צד שלישי. ב-Android 5.0, השדה הזה חייב לכלול את הערך המלא 21.
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.0/LRWXX/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 של הנתונים. לדוגמה, מסנן Intent שצוין בו ה-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

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

3.4.1. תאימות ל-WebView

אפשר לספק את ההטמעה המלאה של android.webkit.Webview API במכשירי Android Watch, אבל חובה לספק אותה בכל סוגי ההטמעות האחרות במכשירים.

חובה לדווח על תכונת הפלטפורמה 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.0. הגרסה הזו כוללת קבוצה ספציפית של תיקוני פונקציונליות ואבטחה ל-WebView [מקורות מידע, 13].
מחרוזת סוכן המשתמש שמדווחת על ידי WebView חייבת להיות בפורמט הזה:

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

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

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

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

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

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

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

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

מטמון של אפליקציה/פעולה אופליין [משאבים, 15]
התג
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, כך שרק אפליקציות שמשתמשות בהם באופן מפורש (דרך המנגנון) יושפעו מהשימוש המוגבר בזיכרון של ממשקי ה-API האלה.

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

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

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

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

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

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

פריסת המסך	צפיפות המסך	זיכרון מינימלי של אפליקציה
קטן / רגיל	120 dpi (ldpi)	16MB
	160dpi‏ (mdpi)
	213dpi‏ (tvdpi)	32MB
	240 dpi (hdpi)
	320 dpi‏ (xhdpi)	64MB
	400 dpi (400dpi)	96MB
	480dpi‏ (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640dpi‏ (xxxhdpi)	256MB
גדולה	120 dpi (ldpi)	16MB
	160dpi‏ (mdpi)	32MB
	213dpi‏ (tvdpi)	64MB
	240 dpi (hdpi)
	320 dpi‏ (xhdpi)	128MB
	400 dpi (400dpi)	192MB
	480dpi‏ (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640dpi‏ (xxxhdpi)	512MB
xlarge	160dpi‏ (mdpi)	64MB
	213dpi‏ (tvdpi)	96MB
	240 dpi (hdpi)
	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, אבל אמורה להיות תמיכה בהם במכשירי Android ניידים.

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

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

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

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

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

3.8.4. חיפוש

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

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

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

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

3.8.6. עיצובים

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

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

מערכת Android 5.0 כוללת משפחת עיצובים מסוג 'חומר', כקבוצה של סגנונות מוגדרים שמפתחי אפליקציות יכולים להשתמש בהם כדי להתאים את המראה והתחושה של עיצוב העיצוב למגוון הרחב של סוגי המכשירים השונים של 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 Television ובמכשירי Android Watch.

קוד המקור של 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]. הטמעות במכשירים שתומכות במסך נעילה במכשיר חייבות לתמוך בתבנית ההתראות של מדיה לצד התראות אחרות.

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 5.0 יש תמיכה בגופן 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 בהתאם להטמעה שמוגדרת כברירת מחדל ב-Android. הטמעות של מכשירים חייבות לעמוד בדרישות הבאות:

חובה לתמוך בהטמעות של שירותי נגישות של צד שלישי באמצעות ממשקי ה-API של android.accessibilityservice‏ [משאבים, 43]
חייבים ליצור אירועי AccessibilityEvents ולשלוח את האירועים האלה לכל ההטמעות הרשמות של AccessibilityService באופן שתואם להטמעה שמוגדרת כברירת מחדל ב-Android
אלא אם מדובר במכשיר 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.

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

חובה לתמוך ב-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], למעט במקרים שבהם צוין במפורש במסמך הזה שאפשר להשתמש בפורמטים אחרים. באופן ספציפי, הטמעות של מכשירים חייבות לתמוך בפורמטים של מדיה, בקודקים, בפענוחים, בסוגי קבצים ובפורמטים של קונטיינרים שמוגדרים בטבלאות שבהמשך. כל הקודקים האלה זמינים כהטמעות תוכנה בהטמעה המועדפת של Android מ-Android Open Source Project.

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

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

פורמט / קודק	מקודד	פענוח	פרטים	סוגי קבצים או פורמטים של קונטיינרים נתמכים
פרופיל MPEG-4 AAC (AAC LC)	REQUIRED1	חובה	תמיכה בתוכן מונו/סטריאו/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+)	REQUIRED1 (Android 4.1 ואילך)	חובה	תמיכה בתוכן מונו/סטריאו/5.0/5.12 עם תדירויות דגימה סטנדרטיות של 16 עד 48kHz.
MPEG-4 HE AACv2 פרופיל (enhanced AAC+)		חובה	תמיכה בתוכן מונו/סטריאו/5.0/5.12 עם תדירויות דגימה סטנדרטיות של 16 עד 48kHz.
AAC ELD (AAC משופר עם זמן אחזור נמוך)	REQUIRED1 (Android 4.1 ואילך)	חובה (Android 4.1 ואילך)	תמיכה בתוכן מונו/סטריאו עם תדירויות דגימה רגילות של 16 עד 48kHz.
AMR-NB	REQUIRED3	REQUIRED3	4.75 עד 12.2kbps דגימה ב-8kHz	3GPP‏ (‎.3gp)
AMR-WB	REQUIRED3	REQUIRED3	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	REQUIRED4 (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	REQUIRED1	REQUIRED2		• 3GPP‏ (‎.3gp) • MPEG-4‏ (‎.mp4)
H.264 AVC	REQUIRED2	REQUIRED2	פרטים נוספים זמינים בקטע 5.2 ובקטע 5.3.	• 3GPP‏ (‎.3gp) • MPEG-4‏ (‎.mp4) • MPEG-TS‏ (‎.ts, אודיו AAC בלבד, לא ניתן לדלג, Android 3.0 ואילך)
H.265 HEVC		REQUIRED2	פרטים נוספים זמינים בקטע 5.3	MPEG-4‏ (‎.mp4)
MPEG-4 SP		REQUIRED2		3GPP‏ (‎.3gp)
VP83	REQUIRED2 (Android 4.3 ואילך)	REQUIRED2 (Android 2.3.3 ואילך)	פרטים נוספים זמינים בקטע 5.2 ו5.3	• WebM‏ (‎.webm) [מקורות מידע, 110] • Matroska‏ (‎.mkv, Android 4.0 ואילך)4
VP9		REQUIRED2 (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.2. קידוד וידאו

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

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

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

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

הטמעות של מכשירי 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 Television חייבים לתמוך בפרופיל Main ברמה 4.1 ברמה הראשית ובפרופיל הפענוח של HD‏ 1080p, ורצוי שתהיה להם תמיכה בפרופיל Main10 ברמה 5 ברמה הראשית ובפרופיל הפענוח של UHD.

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p 1	HD 1080p 1	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, גם הערך האופקי וגם הערך האנכי חייבים להיות בטווח.
יחס גובה-רוחב – היחס בין המידה הארוכה של המסך למידה הקצרה. לדוגמה, במסך בגודל 480x854 פיקסלים, היחס יהיה 854 / 480 = 1.779, או בערך '16:9'.
פיקסל שלא תלוי בדחיסות (dp) – יחידת הפיקסלים הווירטואלית שמותאמת למסך של 160dpi, ומחושבת לפי הנוסחה: pixels = dps * (density / 160).

7.1.1. הגדרת מסך

7.1.1.1. גודל מסך

יכול להיות שמכשירי Android Watch (המפורטים בקטע 2) יהיו עם מסכים קטנים יותר, כפי שמתואר בקטע הזה.

מסגרת ממשק המשתמש של 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.
במכשירים שמדווחים על גודל מסך 'גדול במיוחד', גודל המסך חייב להיות לפחות 960‎ dp x 720‎ dp.

בנוסף,

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

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

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

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

יחס הגובה-רוחב של מכשירי Android Watch יכול להיות 1.0 (1:1).

יחס גובה-רוחב המסך חייב להיות ערך בין 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)
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 במקור. כלומר, בהטמעות במכשירים אסור לשנות את הטריגרים או את ערכי הסף שבהם מופעל מצב התאימות, ואסור לשנות את ההתנהגות של מצב התאימות עצמו.

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.1. מקלדת

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

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

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

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

מכשירי Android Television חייבים לתמוך בלחצן D-pad.

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

אפשר להשמיט אפשרות ניווט ללא מגע (טראקבול, 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 תומכת בשתי השיטות. כשהן גלויות, חייבת להיות גישה לכל הפונקציות האלה באמצעות פעולה אחת (למשל הקשה, לחיצה כפולה או מחווה).

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

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

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

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

כדי לשמור על תאימות לאחור, בהטמעות של מכשירים חייבת להיות גישה לפונקציית התפריט באפליקציות כש-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 ניידים ומכשירי Android Watch חייבים לתמוך בקלט במסך מגע.

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

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

מערכת Android כוללת תמיכה במגוון מסכי מגע, משטחי מגע ומכשירים מזויפים להזנת קלט במגע. הטמעות של מכשירים עם מסך מגע משויכות למסך [מקורות מידע, 70] כך שהמשתמש מרגיש שהוא מבצע פעולות ישירות על הפריטים במסך. מכיוון שהמשתמש נוגע ישירות במסך, המערכת לא זקוקה לאמצעי עזר נוספים כדי לציין את האובייקטים שבהם מבצעים פעולות. לעומת זאת, ממשק מגע מזויף מספק מערכת קלט של משתמש שמתקרבת לקבוצת משנה של יכולות של מסך מגע. לדוגמה, עכבר או שלט רחוק שמניעים סמן במסך דומים למגע, אבל המשתמש צריך קודם להצביע או להתמקד ואז ללחוץ. מכשירים רבים לקליטת נתונים, כמו עכבר, משטח מגע, עכבר אוויר מבוסס-ג'ירו, סמן ג'ירו, ג'ויסטיק ולוח מגע עם תמיכה במספר נקודות מגע, יכולים לתמוך באינטראקציות מגע מזויפות. Android 5.0 כולל את המאפיין הקבוע 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 חייבות לתמוך במיפויי המפתחות הבאים:

Button	שימוש ב-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)
לחצן החיצים למעלה1 לחצן החיצים למטה1	0x01 0x00393	AXIS_HAT_Y4
מקש החץ שמאלה1 לחצן ימני ב-Dpad1	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]
חייבת להיות אפשרות לדווח על אירועים בתדירות של 100Hz לפחות, ורצוי לדווח על אירועים בתדירות של 200Hz לפחות
חייבים לפעול בהתאם למערכת הקואורדינטות של חיישן Android כפי שמפורט בממשקי ה-API של Android‏ [מקורות מידע, 74]
חייב להיות מסוגל למדוד מירידה חופשית עד פי ארבעה מכוח הכבידה (4g) או יותר בכל ציר
חייבת להיות רזולוציה של לפחות 8 ביט, ומומלץ שתהיה רזולוציה של לפחות 16 ביט
צריך לבצע כיול במהלך השימוש אם המאפיינים משתנים במהלך מחזור החיים, ולשמור את פרמטרים הפיצוי בין הפעלות מחדש של המכשיר
צריך לבצע פיצוי טמפרטורה
סטיית התקן חייבת להיות לא יותר מ-0.05 מ/שנייה, כאשר סטיית התקן צריכה להיות מחושבת על בסיס ציר על סמך דגימות שנאספו במשך תקופה של לפחות 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 מיקרו טסלה או יותר, ומומלצת רזולוציה של 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 מעלות לשנייה
חייבת להיות אפשרות לדווח על אירועים בתדירות של 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 הן נחשבות כבלתי תלויות בחיבור נתונים שעשוי להיות מיושם באמצעות אותה רשת. במילים אחרות, הפונקציונליות של 'טלפוניה' ב-Android וממשקי ה-API שלה מתייחסים באופן ספציפי לשיחות קוליות ולהודעות SMS. לדוגמה, הטמעות של מכשירים שלא יכולות להתקשר או לשלוח/לקבל הודעות SMS אסור לדווח על התכונה android.hardware.telephony או על תכונות משנה שלה, גם אם הן משתמשות ברשת סלולרית לחיבור לנתונים.

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

7.4.2. IEEE 802.11‏ (Wi-Fi)

הטמעות של מכשירי Android Television חייבות לכלול תמיכה ב-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 Direct Link Setup (TDLS) במנהרה.

הטמעות של מכשירי 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 Television חייבות לתמוך ב-Bluetooth וב-Bluetooth LE, וטמעות של מכשירי Android Watch חייבות לתמוך ב-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 ובמסמך [Resources, 82]
צריכה לתמוך בהעברת הלוגיקה של הסינון לצ'יפסט של ה-Bluetooth כשמטמיעים את ScanFilter API‏ [מקורות מידע, 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.
  - חובה לפעול לפי הכוונה 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 5.0 יש תמיכה במצב 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, באופן הבא:
- אם אפשר לסובב את הטלפון במהלך ההטמעה במכשיר (למשל באופן אוטומטי באמצעות תאוצה או באופן ידני באמצעות קלט של המשתמש), חובה להציג את התצוגה המקדימה של המצלמה במראה אופקי ביחס לכיוון הנוכחי של המכשיר.
- אם האפליקציה הנוכחית ביקשה במפורש שמסך המצלמה יוזז באמצעות קריאה ל-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. נפח זיכרון ואחסון מינימלי

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

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

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

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

במכשירי 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 לכתוב באחסון החיצוני המשני, מלבד הספריות הספציפיות לחבילה באחסון החיצוני המשני. עם זאת, מומלץ לחשוף תוכן משני הנתיבים לאחסון באופן שקוף באמצעות שירות הסורק של המדיה של Android ו-android.provider.MediaStore.

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

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

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

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‏ [Resources, 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 חייבים לכלול מיקרופון.

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

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

7.8.2. יעד השמע

יכול להיות שמכשירי Android Watch יכללו פלט אודיו.

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

חובה לדווח על קבוע התכונה 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 של סביבת זמן הריצה באמצעות המנגנון.

אסור שסביבות זמן ריצה חלופיות יאפשרו לאפליקציות להשתמש בתכונות שמוגנות על ידי הרשאות 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 יאפשר הגדרות שמשביתות את התאימות.

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

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

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

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

9.8. פרטיות

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

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

אופציונלי להטמעות במכשירי Android ללא מסך נעילה.

אם להטמעה במכשיר יש מסך נעילה, המכשיר חייב לתמוך בהצפנת דיסק מלאה של הנתונים הפרטיים של האפליקציה (מחיצה /data), וגם של המחיצה של כרטיס ה-SD אם הוא חלק קבוע ולא ניתן להסרה מהמכשיר [Resources, 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. אמנם הדרישות האלה מוצגות כ'מומלץ' לגרסה הזו של פלטפורמת 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.0. הטמעות של מכשירים חייבות לעבור את גרסת CTS האחרונה שזמינה בזמן השלמת תוכנת המכשיר.

10.2. CTS Verifier

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

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

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

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

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

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

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

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

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

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

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

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

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

קטעים	סיכום השינויים
1. מבוא	דרישות מעודכנות להפניה למסמכי התיעוד של ה-SDK כמקור המידע האמין.
2. סוגי מכשירים	הגדרות של סוגי מכשירים ניידים, טלוויזיות ושעונים.
2.1 הגדרת המכשיר	נוספה רשימה חלקית כדי להמחיש את ההבדלים בהגדרות החומרה במכשירים השונים.
3.1. תאימות של ממשקי API מנוהלים	חובה גם לספק הטמעות מלאות של ממשקי API עם הסמן ‎ "@SystemApi" בקוד המקור של Android במקור.
3.2.2. פרמטרים של build	נוספו הפרמטרים SUPPORTED_ABIS,‏ SUPPORTED_32_BIT_ABIS ו-SUPPORTED_64_BIT_ABIS לרשימה, עודכן הפרמטר PRODUCT כך שיחייב מק"טים ייחודיים של מוצרים, ועודכנו התגים.
3.2.3.1. כוונות ליבה של אפליקציות	הבהרה של השפה לגבי דרישת התאימות, שמתייחסת בעיקר לדפוס הכוונה
3.2.3.5. הגדרות ברירת המחדל של האפליקציות	נוספו דרישות חדשות למסך הבית, ל-NFC ולאפליקציות ברירת המחדל לשליחת הודעות SMS.
3.3.1 ממשקי Application Binary	הוספנו דרישות לתמיכה ב-ABI מקביל של 32 ביט, אם יש תמיכה ב-ABI כלשהו של 64 ביט. הפרמטרים עודכנו כך שישקפו את השינוי הזה.
3.4.1. תאימות ל-WebView	נדרשת תאימות ל-Webview בכל המכשירים, מלבד מכשירי Android Watch. הוסרה הדרישה למחרוזת של אזור גיאוגרפי.
3.4.2. תאימות לדפדפנים	במכשירי Android Television ו-Android Watch יכול להיות שלא תהיה אפליקציית דפדפן, אבל בכל סוגי ההטמעות האחרים של מכשירים חייבת להיות אפליקציית דפדפן.
3.7. תאימות בסביבת זמן הריצה	עדכון הדרישות המינימליות לזיכרון של אפליקציות
3.8.2. ווידג'טים	תמיכה בווידג'טים היא אופציונלית לכל סוגי המכשירים, אבל מומלצת למכשירים ניידים.
3.8.3. התראות	הגדרות מורחבות לסוגים של התראות נתמכות.
3.8.4. חיפוש	מכשירי Android Television חייבים לכלול חיפוש גלובלי. כל סוגי המכשירים האחרים אמורים.
3.8.6. עיצובים	המכשירים חייבים לתמוך בעיצוב Material.
3.8.7. טפטים מונפשים	במכשירים שכוללים טפטים חיים, חובה לדווח על הדגל של תכונת הפלטפורמה android.software.live_wallpaper.
3.8.8. מעבר בין פעילויות	מומלץ לתמוך בממשק המשתמש החדש של 'מהזמן האחרון'. צריך להציג לפחות את השם של 4 פעילויות בכל פעם.
3.8.10. שלט רחוק למדיה במסך הנעילה	Remote Control Client API יצא משימוש לטובת התבנית של התראות מדיה
3.8.11. חלומות	אופציונלי למכשירי Android Watch. חובה לכל סוגי המכשירים האחרים.
3.8.13 Unicode וגופן	חובה לתמוך ב-Roboto 2 בנוסף לדרישות הקיימות.
3.12. TV Input Framework	הטמעות של מכשירי Android Television חייבות לתמוך ב-Television Input Framework.
5.1. קודקים של מדיה	נוספו 3 קטעים לקודקים של אודיו, תמונות ווידאו.
5.4 הקלטת אודיו	מחולקים לקטעים
5.4.1. הקלטת אודיו גולמי	מאפיינים מוגדרים לצילום אודיו גולמי במכשירים שמצהירים על android.hardware.microphone
5.5. הפעלת האודיו	נוסף קטע 5.5. הפעלת אודיו עם 2 קטעים משניים: 5.5.1 אפקטים של אודיו ו-5.5.2. עוצמת הקול של פלט האודיו
5.6 זמן אחזור אודיו (audio latency)	נוספו הגדרות ודרישות לגבי תנודות חדות בפלט במצב קר, תנודות חדות בקלט במצב קר וזמן אחזור הלוך ושוב רציף.
5.8 מדיה מאובטחת	דרישות של מדיה מאובטחת שנוספו מגרסה 7.1.8. מסכים חיצוניים ודרישות נוספות ל-Android Television.
6.1. כלים למפתחים	משאבים מעודכנים.
6.2.1. ניסיוני	הקטע הוסר
7. תאימות חומרה	העדכון משקף את העובדה ש-Device implementations חייב לדווח באופן עקבי על הגדרות חומרה מדויקות לאותה טביעת אצבע של build.
7.1.1.1. גודל מסך	עודכן כך שישקף את גודל המסך של מכשירי Android Watch, ושהערך לא יכול להשתנות
7.1.1.2. יחס הגובה-רוחב של המסך	העדכון משקף את יחס הגובה-רוחב של המסך במכשירי Android Watch (1:1).
7.1.3. כיוון מסך	העדכון משקף את העובדה שמכשירים עם מסך ניצב קבוע בכיוון לרוחב צריכים לדווח רק על הכיוון הזה.
7.1.4. האצת גרפיקה 2D ו-3D	נוספה הערה שיכול להיות שמכשירי Android תומכים בחבילת התוספים ל-Android.
(ישנה) 7.1.6. סוגי מסכים	הקטע הוסר
7.1.6. טכנולוגיית המסך	יחס הגובה-רוחב של הפיקסלים (PAR) עודכן ל-0.9 עד 1.15. (סבילות של כ-15%)
7.1.7. מסכים חיצוניים	חלק מהקטע הועבר לקטע 5.8. Secure Media.
7.2.2. ניווט ללא מגע	מכשירי Android Television חייבים לתמוך בלחצן D-pad.
7.2.3. מקשי ניווט	שפה שכלולה בתמיכה בסוגים שונים של מכשירים.
7.2.4. קלט במסך מגע	מכשירי Android Watch חייבים לתמוך בקלט במסך מגע.
7.2.6. תמיכה בבקרי משחקים	נוסף קטע עם הדרישות ל-Android Television.
7.2.7. שלט רחוק	נוסף קטע עם הדרישות ל-Android Television.
7.3. חיישנים	הגדרנו מחדש חיישנים סינתטיים כחיישנים מורכבים וחיששני סטרימינג כחיישנים רציפים. חיישנים צריכים לדווח על זמן האירוע בננו-שניות.
7.3.1. מד תאוצה	הבהרה לגבי סוגי החיישנים הנדרשים ושינוי של ערכי הסף הנדרשים.
7.3.2. מגנטומטר	הבהרה לגבי סוגי החיישנים הנדרשים ושינוי של ערכי הסף הנדרשים.
7.3.4. ג'ירוסקופ	הבהרה לגבי סוגי החיישנים הנדרשים ושינוי של ערכי הסף הנדרשים.
7.3.5. ברומטר	שינוי מ'יכול להיות' ל'צריך' להטמיע מדד לחץ האוויר. חובה להטמיע ולדווח על חיישן TYPE_PRESSURE.
7.3.6. מדחום	המכשירים עשויים לכלול מדחום של טמפרטורת הסביבה. יכול לכלול מדחום מעבד, אבל לא צריך.
7.3.8. חיישן קירבה	מכשירים שיכולים לבצע שיחת קול ולציין ערך כלשהו מלבד PHONE_TYPE_NONE ב-getPhoneType צריכים לכלול חיישן קרבה.
7.4.2. IEEE 802.11‏ (Wi-Fi)	מכשירי Android Television חייבים לכלול תמיכה ב-Wi-Fi. מכשירים שתומכים בחיבור WiFi חייבים לדווח על android.hardware.wifi.
7.4.2.1. Wi-Fi ישיר	חובה לדווח על תכונת החומרה android.hardware.wifi.direct.
7.4.2.2. הגדרת קישור ישיר ב-Wi-Fi דרך מנהרה	מכשירים של Android Television חייבים לכלול תמיכה ב-Wi-Fi TDLS.
7.5. מצלמות	אם הטמעת המכשיר כוללת מצלמה אחת לפחות, אמורה להיות לאפליקציה אפשרות להקצות בו-זמנית 3 בימפטים בגודל התמונות שנוצרות על ידי חיישן המצלמה ברזולוציה הגבוהה ביותר במכשיר.
7.5.3. מצלמות חיצוניות	נוספו דרישות לכך שהטמעות של מכשירים במצב מארח USB עשויות לכלול תמיכה במצלמה חיצונית.
7.5.5. תכונות של מערכת המצלמה	הוספנו רשימה של תכונות המצלמה ומתי צריך להגדיר אותן.
7.6.1. נפח זיכרון ואחסון מינימלי	עדכנו את הדרישות למכשירים של 32 ו-64 ביט. דרישת הזיכרון של SVELTE הוסרה. חובה שיהיה במכשירים נפח אחסון לא נדיף בנפח 1.5GB לפחות
7.6.2. אחסון משותף של אפליקציות	עדכנו את הדרישות לגבי אמצעי אחסון נשלפים שזמינים למשתמשים
7.6.2. אחסון משותף של אפליקציות	דרישות מעודכנות לאפליקציות מערכת שמותקנות מראש, שמאפשרות להן לכתוב באחסון חיצוני משני.
7.7. USB	הוסרו הדרישות ליציאות ללא טעינה שנמצאות באותו קצה כמו יציאת ה-micro-USB. עדכנו את הדרישות למצב Host ולמצב Peripheral.
7.7. USB	תיקון שגיאות הקלדה בקטע USB.
7.8.1. אודיו	העברנו את הקטע של המיקרופון לכאן. נוספו דרישות ליציאות אודיו וליציאות אודיו אנלוגיות.
8. תאימות לביצועים	נוספו דרישות לגבי עקביות של ממשק המשתמש.
9.5. תמיכה בכמה משתמשים	התכונה 'תמיכה בכמה משתמשים' היא אופציונלית לכל סוגי המכשירים. דרישות מפורטות לפי סוג מכשיר בקטע.
9.5. תמיכה בכמה משתמשים	הצפנת כרטיס ה-SD נדרשת לאחסון החיצוני הראשי.
9.7. תכונות אבטחה בליבה	יכול להיות שיש לו ממשק משתמש גלוי כשמתרחשת הפרת אבטחה שלא נחסמה, וכתוצאה מכך מתבצעת ניצול לרעה. אסור להשתמש בדומיינים במצב הרשאות רחבות.
9.9. הצפנת דיסק מלאה	מכשירים עם נעילת מסך אמורים לתמוך בהצפנת דיסק מלאה. במכשירים חדשים, הצפנת הדיסק המלאה צריכה להיות מופעלת כברירת מחדל.
9.10 אתחול מאומת	נוסף קטע עם המלצה להטמעות של מכשירים שתומכות בהפעלה מאומתת לשמירה על תקינות המכשיר.
10.3. אפליקציות עזר	הקטע הוסר מ-CDD.
11. תוכנה שניתן לעדכן	אם המכשיר תומך בפרופיל 802.11 או בפרופיל Bluetooth PAN (רשת אזורית אישית), הוא חייב לתמוך בהורדה אלחוטית עם עדכון אופליין באמצעות הפעלה מחדש.
14. משאבים	משאבים שהועברו מקטע 2 לקטע 14

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.0: http://source.android.com//docs/compatibility/5.0/versions

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://www.whatwg.org/specs/web-apps/current-work/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/guide/developing/tools/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: ‏ https://developer.android.com/studio/command-line/dumpsys.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/docs/core/interaction/input/touch-devices

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/docs/core/interaction/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: http://source.android.com/devices/sensors/composite_sensors.html

77. מצב טריגר רציף: http://source.android.com/devices/sensors/base_triggers.html#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: http://source.android.com/docs/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://www.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/docs/core/camera/versioning

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/usb/accessory.html

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

99. מפרט טעינה של סוללות USB, גרסה 1.2: http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip

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

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

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/devices/tech/encryption/index.html

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

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

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

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

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

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

1. מבוא

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

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

3. תוכנות

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

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

3.2.1. הרשאות

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

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

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

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

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

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

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

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

3.3.1 ממשקי Application Binary

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

3.4.1. תאימות ל-WebView

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

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

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

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

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

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

3.8.2. ווידג'טים

3.8.3. התראות

3.8.4. חיפוש

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

3.8.6. עיצובים

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

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

3.8.9. ניהול קלט

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

3.8.11. חלומות

3.8.12. מיקום

3.8.13. Unicode וגופן

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

3.10. נגישות

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

3.12. TV Input Framework

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.8. Secure Media

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

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

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

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

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

7.1.1. הגדרת מסך

7.1.1.1. גודל מסך

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

7.1.1.3. דחיסות מסך

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

7.1.3. כיוון מסך

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

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

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

7.1.7. מסכים חיצוניים

7.2. התקני קלט

7.2.1. מקלדת

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

7.2.3. מקשי ניווט

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