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

כדי להיחשב כתואם ל-Android 6.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‏ [משאבים, 4].

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

חובה להצהיר על התכונה android.hardware.type.automotive.
חובה לתמוך ב-uiMode‏ = UI_MODE_TYPE_CAR‏ [Resources,‏ 5].

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

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

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

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

3. תוכנות

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

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

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

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

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

פרמטר	פרטים
VERSION.RELEASE	הגרסה של מערכת Android שפועלת כרגע, בפורמט קריא לבני אדם. השדה הזה חייב לכלול אחד מערכי המחרוזות שמוגדרים בקטע [Resources, 9].
VERSION.SDK	הגרסה של מערכת Android שפועלת כרגע, בפורמט שגלוי לקוד של אפליקציות של צד שלישי. ב-Android 6.0, השדה הזה חייב לכלול את הערך המלא 23.
VERSION.SDK_INT	הגרסה של מערכת Android שפועלת כרגע, בפורמט שגלוי לקוד של אפליקציות של צד שלישי. ב-Android 6.0, השדה הזה חייב לכלול את הערך המלא 23.
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:6.0/LMYXX/3359:userdebug/test-keys האצבעית אסור שתכלול תווים של רווח לבן. אם יש תווים של רווח לבן בשדות אחרים שכלולים בתבנית שלמעלה, חובה להחליף אותם במזהה האצבע של ה-build בתווים אחרים, כמו קו תחתון (‎'_'). הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט.
חומרה	שם החומרה (משורת הפקודה של הליבה או מ-/proc). הוא אמור להיות קריא לאנשים באופן סביר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי ‎“^[a-zA-Z0-9_-]+$‎”.
HOST	מחרוזת שמזהה באופן ייחודי את המארח שבו נוצר ה-build, בפורמט שאפשר לקרוא אותו. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
מזהה	מזהה שבחר המטמיע של המכשיר כדי להפנות למהדורה ספציפית, בפורמט קריא לבני אדם. השדה הזה יכול להיות זהה ל-android.os.Build.VERSION.INCREMENTAL, אבל כדאי להגדיר בו ערך משמעותי מספיק כדי שמשתמשי הקצה יוכלו להבחין בין גרסאות build של תוכנה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי ‎“^[a-zA-Z0-9._-]+$‎”.
יצרן	השם המסחרי של יצרן הציוד המקורי (OEM) של המוצר. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
דגם	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם המכשיר כפי שהוא ידוע למשתמש הקצה. השם הזה אמור להיות זהה לשם שתחתיו המכשיר משווק ונמכר למשתמשי הקצה. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או מחרוזת ריקה ("").
מוצר	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם הפיתוח או שם הקוד של המוצר הספציפי (מק"ט), וחובה שהוא יהיה ייחודי באותה מותג. חייב להיות קריא לבני אדם, אבל לא בהכרח מיועד לצפייה על ידי משתמשי קצה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי ‎“^[a-zA-Z0-9_-]+$‎”.
SERIAL	מספר סידורי של חומרה, שחייב להיות זמין וייחודי במכשירים עם אותו דגם ויצרן. הערך של השדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי ‎“^([a-zA-Z0-9]{6,20})$‎”.
תגים	רשימה של תגים מופרדים בפסיקים שנבחרו על ידי מי שמטמיע את המכשיר, שמבדילה עוד יותר את ה-build. השדה הזה חייב לכלול אחד מהערכים שתואמים לשלושת ההגדרות האופייניות לחתימה בפלטפורמת Android: release-keys,‏ dev-keys ו-test-keys.
שעה	ערך שמייצג את חותמת הזמן של מועד ה-build.
סוג	ערך שנבחר על ידי מי שמטמיע את המכשיר, ומציין את הגדרת זמן הריצה של ה-build. השדה הזה חייב לכלול אחד מהערכים התואמים לשלושת ההגדרות הנפוצות של Android בסביבת זמן ריצה: user,‏ userdebug או eng.
משתמש	שם או מזהה משתמש של המשתמש (או המשתמש האוטומטי) שיצר את ה-build. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
SECURITY_PATCH	ערך שמציין את רמת תיקון האבטחה של גרסה זמינה ל-build. חובה לציין שה-build כולל את כל תיקוני האבטחה שהונפקו עד לעדכון הבא של חדשות האבטחה הציבוריות של Android. התאריך חייב להיות בפורמט [YYYY-MM-DD] ותואם לאחת מהמחרוזות של רמת תיקון האבטחה ב-Android שמופיעות ב עדכוני האבטחה הציבוריים, לדוגמה '2015-11-01'.
BASE_OS	ערך שמייצג את הפרמטר FINGERPRINT של ה-build, שהוא זהה ל-build הזה מלבד התיקונים שסופקו בעדכון האבטחה הציבורי של Android. חובה לדווח על הערך הנכון, ואם לא קיים build כזה, צריך לדווח על מחרוזת ריקה ("").

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. פתרון של כוונה

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

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

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

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

חובה לנסות לאמת את כל מסנני הכוונה על ידי ביצוע שלבי האימות שמוגדרים במפרט של Digital Asset Links‏ [משאבים, 141] כפי שהם מיושמים על ידי מנהל החבילות בפרויקט הקוד הפתוח של Android ב-upstream.
חובה לנסות לאמת את מסנני הכוונה במהלך התקנת האפליקציה ולהגדיר את כל מסנני הכוונה של ה-UIR שאומתו כמפעילי אפליקציה שמוגדרים כברירת מחדל ל-UIR שלהם.
יכולים להגדיר מסנני כוונה ספציפיים של URI כמפעילי אפליקציה שמוגדרים כברירת מחדל למזהי ה-URI שלהם, אם הם מאומתים בהצלחה אבל מסנני URI אחרים לא עוברים את תהליך האימות. אם הטמעה במכשיר עושה זאת, היא חייבת לספק למשתמש אפשרויות שינוי הולמות לדפוסים ספציפיים לכל URI בתפריט ההגדרות.
חובה לספק למשתמש אמצעי בקרה על קישורי אפליקציות לכל אפליקציה בהגדרות, באופן הבא:
- המשתמש חייב להיות מסוגל לשנות באופן מקיף את התנהגות ברירת המחדל של קישורים לאפליקציות, כך שהאפליקציה תמיד תיפתח, תמיד תשאל או אף פעם לא תיפתח. המדיניות הזו חייבת לחול באופן שווה על כל מסנני הכוונה של URI מועמדים.
- המשתמש חייב להיות מסוגל לראות רשימה של מסנני הכוונה ל-URI המועמדים.
- הטמעת המכשיר עשויה לספק למשתמש את היכולת לשנות את ההגדרות של מסנני הכוונה ספציפיים של URI שהתקבלו בהצלחה, על בסיס מסנן כוונה לכל אחד.
- אם הטמעת המכשיר מאפשרת לחלק ממסנני הכוונה של URI מועמדים לעבור את האימות, בעוד שחלק אחר מהם לא עוברים, חובה שהטמעת המכשיר תספק למשתמשים את היכולת להציג ולשנות את ההגדרות של מסנני הכוונה של URI מועמדים ספציפיים.

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, כפי שמתואר בהמשך.

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

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

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

3.3.1. ממשקי Application Binary Interface

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

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

חובה לכלול תמיכה בקוד שפועל בסביבה המנוהלת כדי לבצע קריאה לקוד מקומי, באמצעות הסמנטיקה הרגילה של Java Native Interface‏ (JNI)
חייבת להיות תואמת למקור (כלומר תואמת לכותרת) ותואמת לבינארי (ל-ABI) לכל ספרייה נדרשת ברשימה שבהמשך
חובה לתמוך ב-ABI המקביל ל-32 ביט אם יש תמיכה ב-ABI כלשהו ל-64 ביט
חובה לדווח בצורה מדויקת על ממשק ה-ABI (Application Binary Interface) המקורי שנתמך במכשיר, באמצעות הפרמטרים android.os.Build.SUPPORTED_ABIS,‏ android.os.Build.SUPPORTED_32_BIT_ABIS ו-android.os.Build.SUPPORTED_64_BIT_ABIS. כל אחד מהפרמטרים האלה הוא רשימה מופרדת בפסיקים של ממשקי ABI, שממוינים מהמועדף ביותר לפחות מועדף.
חובה לדווח, באמצעות הפרמטרים שלמעלה, רק על ממשקי ABI שמתועדים ומתווארים בגרסה האחרונה של המסמכים בנושא ניהול ABI ב-Android NDK‏ [מקורות מידע, 12], וחובה לכלול תמיכה בתוסף Advanced SIMD‏ (נקרא גם NEON)‏ [מקורות מידע, 13]
צריך לבנות אותו באמצעות קוד המקור וקובצי הכותרת שזמינים ב-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, 14] כפי שמוגדרים במהדורת NDK android-21. כל הסמלים חייבים להופיע, אבל רק הפונקציות התואמות לגרסאות ולתוספים של OpenGL ES שנתמכים בפועל במכשיר צריכות להיות מוטמעות באופן מלא.

הטמעות במכשירים, אם הן כוללות ספרייה מקומית בשם libvulkan.so, חייבות לייצא סמלי פונקציות ולספק הטמעה של Vulkan 1.0 API והתוספים VK_KHR_surface, ‏ VK_KHR_swapchain ו-VK_KHR_android_surface כפי שהוגדרו על ידי קבוצת Khronos, וגם לעבור את בדיקות התאימות של Khronos.

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

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

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

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

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

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

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

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

3.4.1. תאימות ל-WebView

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

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

הטמעות של android.webkit.WebView במכשירים חייבות להתבסס על ה-build של Chromium מפרויקט Android Open Source Project למקור (upstream) של Android 6.0. הגרסה הזו כוללת קבוצה ספציפית של תיקוני אבטחה ופונקציות ל-WebView‏ [משאבים, 16].
מחרוזת סוכן המשתמש שמדווחת על ידי WebView חייבת להיות בפורמט הזה:
Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) 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 [משאבים, 17].

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

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

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

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

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

מטמון של אפליקציה/פעולה אופליין [משאבים, 18]
התג <video>‏ [משאבים, 19]
geolocation [Resources, 20]

בנוסף, הטמעות במכשירים חייבות לתמוך ב-HTML5/W3C webstorage API‏ [מקורות מידע, 21], ורצוי שתתמוך ב-HTML5/W3C IndexedDB API‏ [מקורות מידע, 22]. חשוב לזכור שגופי התקנים של פיתוח האינטרנט עוברים להעדיף את 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, כך שרק אפליקציות שמשתמשות בהם באופן מפורש (באמצעות מנגנון lt;uses-librarygt;) יושפעו מהשימוש המוגבר בזיכרון של ממשקי ה-API האלה.

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

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

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

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

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

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

פריסת המסך	דחיסות מסך	נפח זיכרון מינימלי לאפליקציה
Android Watch	120 dpi (ldpi)	32MB
	160dpi‏ (mdpi)
	213dpi‏ (tvdpi)
	240 dpi (hdpi)	36MB
	280 dpi (280dpi)	36MB
	320 dpi‏ (xhdpi)	48MB
	360 dpi (360dpi)	48MB
	400 dpi (400dpi)	56MB
	420 dpi (420dpi)	64MB
	480dpi‏ (xxhdpi)	88MB
	560 dpi (560dpi)	112MB
	640dpi‏ (xxxhdpi)	154MB
קטן/רגיל	120 dpi (ldpi)	32MB
	160dpi‏ (mdpi)	32MB
	213dpi‏ (tvdpi)	48MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi‏ (xhdpi)	80MB
	360 dpi (360dpi)	80MB
	400 dpi (400dpi)	96MB
	420 dpi (420dpi)	112MB
	480dpi‏ (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640dpi‏ (xxxhdpi)	256MB
גדולה	120 dpi (ldpi)	32MB
	160dpi‏ (mdpi)	48MB
	213dpi‏ (tvdpi)	80MB
	240 dpi (hdpi)	80MB
	280 dpi (280dpi)	96MB
	320 dpi‏ (xhdpi)	128MB
	360 dpi (360dpi)	160MB
	400 dpi (400dpi)	192MB
	420 dpi (420dpi)	228MB
	480dpi‏ (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640dpi‏ (xxxhdpi)	512MB
xlarge	120 dpi (ldpi)	48MB
	160dpi‏ (mdpi)	80MB
	213dpi‏ (tvdpi)	96MB
	240 dpi (hdpi)	96MB
	280 dpi (280dpi)	144MB
	320 dpi‏ (xhdpi)	192MB
	360 dpi (360dpi)	240MB
	400 dpi (400dpi)	288MB
	420 dpi (420dpi)	336MB
	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' למשתמש הקצה [משאבים, 24]. מומלץ מאוד לתמוך בתכונה הזו בהטמעות במכשירים ניידים. הטמעות במכשירים שתומכות בהטמעת ווידג'טים במסך הבית חייבות לעמוד בדרישות הבאות ולהצהיר על תמיכה בתכונה android.software.app_widgets בפלטפורמה.

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

3.8.3. התראות

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

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

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

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

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

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

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

3.8.4. חיפוש

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

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

בהטמעות של מכשירי Android, צריך להטמיע עוזרת במכשיר כדי לטפל בפעולה Assist‏ [מקורות מידע, 30].

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

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

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

3.8.6. עיצובים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.9. ניהול קלט

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

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

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

החל מגרסה 5.0 של Android, Remote Control Client API הוצא משימוש והוחלף בתבנית של התראות מדיה שמאפשרת לאפליקציות מדיה להתמזג עם אמצעי הבקרה של ההפעלה שמוצגים במסך הנעילה [משאבים, 40] בתור התראות במסך הנעילה. בהטמעות במכשירים, חובה להציג את התבנית של התראות המדיה בצורה תקינה כחלק מההתראות במסך הנעילה שמתוארות בקטע 3.8.3.

3.8.11. חלומות

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

3.8.12. מיקום

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

3.8.13. Unicode וגופן

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

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

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

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

3.9.1 הקצאת מכשיר (Provisioning)

3.9.1.1 הקצאה לבעלי המכשיר

אם הטמעת המכשיר מצהירה על התכונה android.software.device_admin, תהליך ההגדרה מחוץ לקופסה חייב לאפשר להירשם אפליקציית אמצעי בקרה של מדיניות המכשיר (DPC) כאפליקציית הבעלים של המכשיר [ מקורות מידע, 46]. יכול להיות שבהטמעות של מכשירים תהיה אפליקציה מותקנת מראש שמבצעת פונקציות של ניהול המכשיר, אבל אסור להגדיר את האפליקציה הזו כאפליקציית הבעלים של המכשיר ללא הסכמה מפורשת או פעולה מצד המשתמש או האדמין של המכשיר.

חוויית המשתמש בתהליך ההקצאה של הבעלים של המכשיר (התהליך שמופעל על ידי android.app.action.PROVISION_MANAGED_DEVICE‏ [ מקורות מידע, 47]) חייבת להיות תואמת ליישום AOSP.

אם הטמעת המכשיר מדווחת על android.hardware.nfc, צריך להפעיל את NFC גם במהלך תהליך ההגדרה מחוץ לקופסה, כדי לאפשר הקצאת NFC לבעלים של המכשיר [משאבים, 48].

3.9.1.2 הקצאת פרופילים מנוהלים

אם הטמעה של מכשיר מצהירה על android.software.managed_users, חייב להיות אפשר לרשום אפליקציית Device Policy Controller ‏ (DPC) כבעלים של פרופיל מנוהל חדש [ מקורות מידע, 49]

חוויית המשתמש בתהליך הקצאת הפרופיל המנוהל (התהליך שמופעל על ידי android.app.action.PROVISION_MANAGED_PROFILE‏ [ Resources, 50]) חייבת להיות תואמת ליישום AOSP

3.9.2 תמיכה בפרופיל מנוהל

מכשירים עם תמיכה בפרופיל מנוהל הם מכשירים שבהם:

הצהרה על android.software.device_admin (ראו סעיף 3.9 ניהול מכשירים)
לא מכשירים עם זיכרון RAM נמוך (ראו קטע 7.6.1
הקצאת אחסון פנימי (לא נשלף) כאחסון משותף (ראו קטע 7.6.2)

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

מגדירים את דגל התכונה של הפלטפורמה android.software.managed_users.
תמיכה בפרופילים מנוהלים באמצעות ממשקי ה-API של android.app.admin.DevicePolicyManager
מתן הרשאה ליצירת פרופיל מנוהל אחד בלבד [Resources, 50]
שימוש בתג סמל (בדומה לתג העבודה של AOSP upstream) כדי לייצג את האפליקציות והווידג'טים המנוהלים ורכיבי ממשק משתמש אחרים עם תגים, כמו 'מהזמן האחרון' ו'התראות'
הצגת סמל התראה (בדומה לתג העבודה של AOSP upstream) כדי לציין מתי המשתמש נמצא באפליקציה בפרופיל מנוהל
הצגת הודעה קופצת על כך שהמשתמש נמצא בפרופיל המנוהל, אם והפעם שהמכשיר מתעורר (ACTION_USER_PRESENT) והאפליקציה שבחזית נמצאת בפרופיל המנוהל
אם יש פרופיל מנוהל, צריך להציג תכונה חזותית ב'בורר' של הכוונה כדי לאפשר למשתמש להעביר את הכוונה מהפרופיל המנוהל למשתמש הראשי או להפך, אם האפשרות הזו מופעלת על ידי הכלי לבקרת מדיניות המכשיר.
אם קיים פרופיל מנוהל, צריך לחשוף את האפשרויות הבאות למשתמשים, גם למשתמש הראשי וגם לפרופיל המנוהל:
- ניהול נפרד של נתוני השימוש בסוללה, במיקום, בחבילת הגלישה ובאחסון של המשתמש הראשי ושל הפרופיל המנוהל.
- ניהול עצמאי של אפליקציות VPN שמותקנות בפרופיל המנוהל או בפרופיל הראשי של המשתמש.
- ניהול עצמאי של אפליקציות שמותקנות בפרופיל המנוהל או בפרופיל המשתמש הראשי.
- ניהול עצמאי של חשבונות בתוך המשתמש הראשי או בפרופיל המנוהל.
מוודאים שהמספרן שמוגדר כברירת מחדל יכול לחפש את פרטי מבצע הקריאה מהפרופיל המנוהל (אם קיים כזה) לצד הפרטים מהפרופיל הראשי, אם בקר מדיניות המכשיר מאפשר זאת.
חייבים לוודא שהוא עומד בכל דרישות האבטחה שחלות על מכשיר עם כמה משתמשים מופעלים (ראו קטע 9.5), גם אם הפרופיל המנוהל לא נספר כמשתמש נוסף בנוסף למשתמש הראשי.

3.10. נגישות

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

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

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

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

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

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

הטמעות של Android Automotive:

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

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

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

3.12. TV Input Framework

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

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

3.12.1. אפליקציית הטלוויזיה

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

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

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

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

3.12.1.1. מדריך תוכניות אלקטרוני

בהטמעות של מכשירי Android Television חייב להופיע שכבת-על אינפורמטיבית ואינטראקטיבית, שחייבת לכלול מדריך תוכניות אלקטרוני (EPG) שנוצר מהערכים בשדות TvContract.Programs‏ [משאבים, 59]. ה-EPG חייב לעמוד בדרישות הבאות:

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

3.12.1.2. ניווט

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

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

3.12.1.3. קישור של אפליקציית קלט טלוויזיה

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

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

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

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

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

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

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

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

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

פורמט/קודק	במקודד	מפענח	פרטים	סוגי קבצים/פורמטים של קובצי מאגר נתמכים
MPEG-4 AAC Profile (AAC LC)	חובה¹	חובה	תמיכה בתוכן מונו/סטריאו/5.0/5.1² עם תדירות דגימה רגילה של 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+)	חובה¹ (Android 4.1 ואילך)	חובה	תמיכה בתוכן מונו/סטריאו/5.0/5.1² עם תדירויות דגימה רגילות של 16 עד 48kHz.
MPEG-4 HE AACv2 פרופיל (enhanced AAC+)		חובה	תמיכה בתוכן מונו/סטריאו/5.0/5.1² עם תדירויות דגימה רגילות של 16 עד 48kHz.
AAC ELD (AAC משופר עם זמן אחזור נמוך)	חובה¹ (Android 4.1 ואילך)	חובה (Android 4.1 ואילך)	תמיכה בתוכן מונו/סטריאו עם תדירויות דגימה רגילות של 16 עד 48kHz.
AMR-NB	חובה³	חובה³	4.75 עד 12.2kbps דגימה ב-8kHz	3GPP‏ (‎.3gp)
AMR-WB	חובה³	חובה³	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	חובה⁴ (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. קודיקים של וידאו

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

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

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

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

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

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

6 ההגדרה הזו רלוונטית רק להטמעות במכשירי Android Television.

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

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

הטמעות של מכשירי Android עם מקודדי H.263 חייבות לתמוך בפרופיל הבסיסי ברמה 45.

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

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p¹	HD 1080p¹
רזולוציית וידאו	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 720p¹	HD 1080p¹
רזולוציית וידאו	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.

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

הטמעות של מכשירי Android עם מקודדים של H.263 חייבות לתמוך בפרופיל Baseline ברמה 30.

הטמעות של מכשירי Android עם מקודדים של MPEG-4 חייבות לתמוך בפרופיל פשוט ברמה 3.

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

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

1 נדרש כאשר הגובה שמדווח על ידי השיטה Display.getSupportedModes() שווה לרזולוציית הסרטון או גדול ממנה.

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

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

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

1 נדרש כאשר הגובה שמדווח על ידי השיטה Display.getSupportedModes() שווה לרזולוציית הסרטון או גדול ממנה.

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

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

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

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

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

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

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p¹	HD 1080p²	UHD²
רזולוציית וידאו	352 x 288 פיקסלים	640 x 360 פיקסלים	‎1280 x 720 פיקסלים	‎1,920 x 1,080 פיקסלים	3840 x 2160 פיקסלים
קצב מסגרות של סרטון	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	60 fps²	60 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
ערוצים: סטריאו

אם יש תמיכה בצילומים בתדירויות הדגימה שלמעלה, חובה לבצע את הצילום ללא דגימה מחדש ביחס גבוה מ-16000:22050 או 44100:48000. כל דגימה למעלה או למטה חייבת לכלול מסנן מתאים לביטול רעשי aliasing.

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

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

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

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

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

RTSP‏ (RTP, ‏ SDP)
HTTP(S) progressive streaming
טיוטת פרוטוקול של HTTP(S) Live Streaming, גרסה 3 [משאבים, 71]

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) שעומדים בדרישות האלה.

5.9. ממשק דיגיטלי לכלים מוזיקליים (MIDI)

אם הטמעת המכשיר תומכת בהעברת נתוני MIDI בתוכנה בין אפליקציות (מכשירי MIDI וירטואליים), וגם תומכת ב-MIDI דרך כל אמצעי ההעברה הבאים של חומרה עם תמיכה ב-MIDI, שבהם היא מספקת קישוריות גנרית שאינה MIDI, מומלץ מאוד לדווח על תמיכה בתכונה android.software.midi באמצעות הכיתה android.content.pm.PackageManager‏ [Resources, 70].

אמצעי התעבורה של חומרה עם תמיכה ב-MIDI הם:

מצב מארח USB (קטע 7.7 USB)
מצב ציוד היקפי בחיבור USB (קטע 7.7 USB)

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

MIDI over Bluetooth LE בתפקיד מרכזי (קטע 7.4.3 Bluetooth) נמצא בסטטוס שימוש לניסיון. הטמעה של מכשיר שמדווחת על התכונה android.software.midi ומספקת קישוריות גנרית שאינה MIDI דרך Bluetooth LE, אמורה לתמוך ב-MIDI דרך Bluetooth LE.

5.10. אודיו מקצועי

אם הטמעת המכשיר עומדת בכל הדרישות הבאות, מומלץ מאוד לדווח על תמיכה בתכונה android.hardware.audio.pro באמצעות הכיתה android.content.pm.PackageManager‏ [Resources, 70].

ההטמעה במכשיר חייבת לדווח על תמיכה בתכונה android.hardware.audio.low_latency.
זמן האחזור של אודיו הלוך ושוב ברציפות, כפי שמוגדר בקטע 5.6 זמן אחזור של אודיו, חייב להיות 20 אלפיות השנייה או פחות, ומומלץ שהוא יהיה 10 אלפיות השנייה או פחות בנתיב נתמך אחד לפחות.
אם המכשיר כולל שקע אודיו 3.5 מ"מ עם 4 מוליכים, זמן האחזור של האודיו במסלול הלוך ושוב חייב להיות 20 אלפיות השנייה או פחות במסלול של שקע האודיו, ורצוי שיהיה 10 אלפיות השנייה או פחות במסלול של שקע האודיו.
הטמעת המכשיר חייבת לכלול יציאות USB שתומכות במצב מארח USB ובמצב ציוד היקפי USB.
מצב המארח ב-USB חייב ליישם את מחלקת האודיו ב-USB.
אם המכשיר כולל יציאת HDMI, הטמעת המכשיר חייבת לתמוך בפלט בסטריאו ובשמונה ערוצים בעומק 20 ביט או 24 ביט ובתדר 192kHz, ללא אובדן עומק ביט או דגימה מחדש.
ההטמעה של המכשיר חייבת לדווח על תמיכה בתכונה android.software.midi.
אם המכשיר כולל שקע אודיו 3.5 מ"מ עם 4 מוליכים, מומלץ מאוד שההטמעה של המכשיר תהיה תואמת לקטע Mobile device (jack) specifications (מפרטים של מכשיר נייד (שקע)) במפרט Wired Audio Headset Specification (v1.1) (מפרט אוזניות אודיו קוויות, גרסה 1.1).

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

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

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

ממשק הגישור של Android‏ (adb) [משאבים, 72]

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

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

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

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

Monkey [Resources, 75]

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

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

הטמעות במכשירים חייבות לתמוך בכלי 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 10 גם בגרסת 32 ביט וגם בגרסת 64 ביט.

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

ב-Android יש תמיכה למפתחים שמאפשרת להם להגדיר הגדרות שקשורות לפיתוח אפליקציות. הטמעות במכשירים חייבות לפעול בהתאם ל-Intent‏ android.settings.APPLICATION_DEVELOPMENT_SETTINGS כדי להציג הגדרות שקשורות לפיתוח אפליקציות [מקורות מידע, 77]. בהטמעה של 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, 70]

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

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

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

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

7.1.1. הגדרת מסך

7.1.1.1. גודל מסך

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

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

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

בנוסף,

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

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

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

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

יחס הגובה-רוחב של מכשירי 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)
280 dpi (280dpi)
320 dpi‏ (xhdpi)
360 dpi (360dpi)
400 dpi (400dpi)
420 dpi (420dpi)
480dpi‏ (xxhdpi)
560 dpi (560dpi)
640dpi‏ (xxxhdpi)

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

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

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

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‏ [משאבים, 80].

הטמעות של מכשירים חייבות גם לזהות את עצמן בצורה נכונה כאלה שתומכות ב-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‏ [משאבים, 81] ותמיכה מקומית בפונקציונליות גרפית מתקדמת כמו טיסרציה ופורמט דחיסת הטקסטורות ASTC. יכול להיות שאפשר יהיה להטמיע את חבילת התוספים הזו במכשירי Android, ורק אם ההטמעה תתבצע באופן מלא, חובה לזהות את התמיכה באמצעות דגל התכונה android.hardware.opengles.aep.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.2. התקני קלט

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

7.2.1. מקלדת

בהטמעות של Android Watch ו-Android Automotive יכולה להיות מקלדת וירטואלית. בכל הטמעות המכשירים האחרות חובה להטמיע מקלדת וירטואלית, וכן:

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

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

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

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

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

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

7.2.3. מקשי ניווט

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

לחצן	שימוש ב-HID²	Android Button
A¹	0x09 0x0001	KEYCODE_BUTTON_A‏ (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B‏ (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X‏ (99)
Y¹	0x09 0x0005	KEYCODE_BUTTON_Y‏ (100)
לוח החיוג למעלה¹ לוח החיוג למטה¹	0x01 0x0039³	AXIS_HAT_Y⁴
מקשי החיצים (D-pad) שמאלה1 מקשי החיצים (D-pad) ימינה¹	0x01 0x0039³	AXIS_HAT_X⁴
לחצן הכתף השמאלי¹	0x09 0x0007	KEYCODE_BUTTON_L1‏ (102)
לחצן הכתף הימני¹	0x09 0x0008	KEYCODE_BUTTON_R1‏ (103)
לחיצה על מקש הלחצן הימני¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL‏ (106)
לחיצה על מקש ה-D-Pad הימני¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR‏ (107)
דף הבית¹	0x0c 0x0223	KEYCODE_HOME‏ (3)
הקודם¹	0x0c 0x0224	KEYCODE_BACK‏ (4)

1 [Resources, 88]

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

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

4 [Resources, 87]

אמצעי בקרה אנלוגיים¹	שימוש ב-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, 87]

7.2.7. שלט רחוק

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

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

7.3. חיישנים

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

חובה לדווח במדויק על נוכחות או על היעדר של חיישנים בהתאם לכיתה android.content.pm.PackageManager‏ [Resources, 70].
חייב להחזיר רשימה מדויקת של חיישנים נתמכים באמצעות ה-method‏ SensorManager.getSensorList() ושיטות דומות.
חייב לפעול באופן סביר בכל ממשקי ה-API האחרים של החיישנים (לדוגמה, על ידי החזרת הערך true או false בהתאם כשאפליקציות מנסים לרשום מאזינים, לא להפעיל מאזינים של חיישנים כשהחיישנים המתאימים לא נמצאים וכו').
חובה לדווח על כל מדידות החיישן באמצעות הערכים הרלוונטיים של המערכת הבינלאומית של יחידות (metric) לכל סוג חיישן, כפי שמוגדר במסמכי העזרה של Android SDK‏ [משאבים, 90].
צריך לדווח על שעת האירוע בננו-שניות, כפי שמוגדר במסמכי התיעוד של Android SDK. השעה הזו מייצגת את השעה שבה האירוע התרחש, והיא מסונכרנת עם השעון SystemClock.elapsedRealtimeNano(). מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה, כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה, שבהן יכול להיות שהרכיב הזה יהיה נדרש. שגיאת הסנכרון אמורה להיות קצרה מ-100 אלפיות השנייה [Resources, 91].
חובה לדווח על נתוני חיישן עם זמן אחזור מקסימלי של 100 אלפיות שנייה + 2 * sample_time במקרה של שידור בזמן אמת של חיישן, עם זמן אחזור נדרש מינימלי של 5 אלפיות שנייה + 2 * sample_time כשמעבד האפליקציה פעיל. העיכוב הזה לא כולל עיכובים בסינון.
חובה לדווח על הדגימה הראשונה של החיישן תוך 400 אלפיות השנייה + 2 * sample_time של החיישן שהופעל. מותר שהדיוק של המדגם הזה יהיה 0.

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

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

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

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

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

7.3.1. מד תאוצה

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

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

7.3.2. מגנטומטר

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

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

7.3.3. GPS

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

7.3.4. ג'ירוסקופ

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

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

7.3.5. ברומטר

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

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

7.3.6. מדחום

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

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

7.3.7. פוטומטר

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

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

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

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

7.3.9. חיישנים באיכות גבוהה

הטמעות של מכשירים שתומכות בקבוצה של חיישנים באיכות גבוהה יותר שיכולים לעמוד בכל הדרישות שמפורטות בקטע הזה חייבות לזהות את התמיכה באמצעות דגל התכונה android.hardware.sensor.hifi_sensors.

מכשיר שמצהיר על android.hardware.sensor.hifi_sensors חייב לתמוך בכל סוגי החיישנים הבאים שעומדים בדרישות האיכות הבאות:

SENSOR_TYPE_ACCELEROMETER
- חייב להיות טווח מדידה של לפחות -8g עד +8g
- חייבת להיות רזולוציית מדידה של לפחות 1,024 LSB/G
- תדר המדידה המינימלי חייב להיות 12.5Hz או פחות
- תדירות המדידה המקסימלית חייבת להיות 200 הרץ ומעלה
- רעש המדידה חייב להיות לא יותר מ-400uG/√Hz
- חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון זמני של לפחות 3,000 אירועי חיישן
- צריכת החשמל של האצווה חייבת להיות לא יותר מ-3mW
SENSOR_TYPE_GYROSCOPE
- טווח המדידה חייב להיות לפחות -1,000 עד +1,000 דפיקות לשנייה
- חייבת להיות רזולוציית מדידה של לפחות 16 LSB/dps
- תדר המדידה המינימלי חייב להיות 12.5Hz או פחות
- תדירות המדידה המקסימלית חייבת להיות 200 הרץ ומעלה
- רעש המדידה חייב להיות לא יותר מ-0.014°/s/√Hz
SENSOR_TYPE_GYROSCOPE_UNCALIBRATED עם אותן דרישות איכות כמו SENSOR_TYPE_GYROSCOPE
SENSOR_TYPE_GEOMAGNETIC_FIELD
- טווח המדידה חייב להיות לפחות בין -900 ל-900 uT
- חייבת להיות רזולוציית מדידה של לפחות 5 LSB/uT
- תדר המדידה המינימלי חייב להיות 5Hz או פחות
- תדירות המדידה המקסימלית חייבת להיות 50 הרץ ומעלה
- רעש המדידה חייב להיות לא יותר מ-0.5 uT
SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED עם אותן דרישות איכות כמו SENSOR_TYPE_GEOMAGNETIC_FIELD, ובנוסף:
- חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון זמני של לפחות 600 אירועי חיישן
SENSOR_TYPE_PRESSURE
- חייב להיות טווח מדידה של לפחות 300 עד 1,100 hPa
- חייבת להיות רזולוציית מדידה של לפחות 80 LSB/hPa
- תדירות המדידה המינימלית חייבת להיות 1Hz או פחות
- תדירות המדידה המקסימלית חייבת להיות 10 הרץ ומעלה
- רעש המדידה חייב להיות לא יותר מ-2 Pa/√Hz
- חובה להטמיע את החיישן הזה בצורה ללא התעוררות עם יכולת אחסון זמני של לפחות 300 אירועי חיישן
- צריכת החשמל של האצווה חייבת להיות לא יותר מ-2mW
TYPE_GAME_ROTATION_VECTOR
- חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון זמני של לפחות 300 אירועי חיישן.
- צריכת החשמל של האצווה חייבת להיות לא יותר מ-4mW.
SENSOR_TYPE_SIGNIFICANT_MOTION
- צריכת האנרגיה חייבת להיות לא יותר מ-0.5mW כשהמכשיר נייח, ו-1.5mW כשהמכשיר בתנועה
SENSOR_TYPE_STEP_DETECTOR
- חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון זמני של לפחות 100 אירועי חיישן
- צריכת האנרגיה חייבת להיות לא יותר מ-0.5mW כשהמכשיר נייח, ו-1.5mW כשהמכשיר בתנועה
- צריכת החשמל של האצווה חייבת להיות לא יותר מ-4mW
SENSOR_TYPE_STEP_COUNTER
- צריכת האנרגיה חייבת להיות לא יותר מ-0.5mW כשהמכשיר נייח, ו-1.5mW כשהמכשיר בתנועה
SENSOR_TILT_DETECTOR
- צריכת האנרגיה חייבת להיות לא יותר מ-0.5mW כשהמכשיר נייח, ו-1.5mW כשהמכשיר בתנועה

בנוסף, המכשיר חייב לעמוד בדרישות הבאות של מערכת המשנה של החיישן:

חותמת הזמן של אותו אירוע פיזי שדווח על ידי חיישן ה-Accelerometer, חיישן ה-Gyroscope וחיישן המגנטומטר חייבת להיות בטווח של 2.5 אלפיות השנייה.
חותמות הזמן של אירועי חיישן הגירוסקופ חייבות להיות באותה בסיס זמן כמו מערכת המשנה של המצלמה, ובטווח שגיאה של מיליסיקון אחד.
זמן האחזור של העברת הדגימות ל-HAL צריך להיות פחות מ-5 אלפיות השנייה מהרגע שבו הנתונים זמינים בחומרה הפיזית של החיישן.
צריכת החשמל לא יכולה להיות גבוהה מ-0.5mW כשהמכשיר נייח, ומ-2.0mW כשהמכשיר בתנועה, כשכל שילוב של החיישנים הבאים מופעל:
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS

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

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

SENSOR_TYPE_PROXIMITY: 100 אירועי חיישן

7.3.10. חיישן טביעות אצבע

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

חובה להצהיר על תמיכה בתכונה android.hardware.fingerprint.
חובה להטמיע באופן מלא את ה-API התואם כפי שמתואר במסמכי התיעוד של Android SDK‏ [משאבים, 95].
שיעור הקבלה השגוי חייב להיות לא יותר מ-0.002%.
מומלץ מאוד שהשיעור של דחייה שגויה יהיה פחות מ-10%, כפי שנמדד במכשיר
מומלץ מאוד שהזמן להצגת התוצאה יהיה פחות משנייה אחת, נמדד מהרגע שבו נוגעים בחיישני טביעות האצבע ועד שהמסך נפתח, לאצבע אחת שרשומה.
חובה להגביל את מספר הניסיונות למשך 30 שניות לפחות אחרי 5 ניסיונות כושלים לאימות באמצעות טביעת אצבע.
חובה שתהיה הטמעה של מאגר מפתחות שמגובת בחומרה, וביצוע ההתאמה של טביעות האצבע בסביבת מחשוב אמינה (TEE) או בשבב עם ערוץ מאובטח ל-TEE.
כל נתוני טביעת האצבע המזהים חייבים להיות מוצפנים ומאומתים באופן קריפטוגרפי, כך שלא ניתן יהיה לקבל אותם, לקרוא או לשנות אותם מחוץ לסביבת המחשוב המאובטחת (TEE), כפי שמתואר בהנחיות להטמעה באתר של Android Open Source Project‏ [משאבים, 96].
חובה למנוע הוספה של טביעת אצבע בלי ליצור קו אמון מראש, על ידי כך שהמשתמש יאשר פרטי כניסה קיימים למכשיר או יוסיף פרטי כניסה חדשים (קוד אימות/דפוס/סיסמה) שמאובטחים על ידי TEE. ההטמעה של Android Open Source Project מספקת את המנגנון במסגרת כדי לעשות זאת.
אסור לאפשר לאפליקציות של צד שלישי להבדיל בין טביעות אצבע ספציפיות.
חובה לפעול בהתאם לדגל DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
כשמתבצעת שדרוג מגרסה ישנה יותר מ-Android 6.0, חובה להעביר את נתוני טביעת האצבע באופן מאובטח כדי לעמוד בדרישות שלמעלה, או להסיר אותם.
צריך להשתמש בסמל טביעת האצבע של Android שזמין בפרויקט הקוד הפתוח של Android.

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

7.4.1. טלפוניה

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

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

7.4.2. IEEE 802.11‏ (Wi-Fi)

הטמעות של מכשירי Android Television חייבות לכלול תמיכה ב-Wi-Fi.

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

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

7.4.2.1. Wi-Fi ישיר

הטמעות במכשירים צריכות לכלול תמיכה ב-Wi-Fi Direct (Wi-Fi peer-to-peer). אם הטמעת המכשיר כוללת תמיכה ב-Wi-Fi Direct, חובה להטמיע את Android API התואם כפי שמתואר במסמכי התיעוד של ה-SDK [מקורות מידע, 98]. אם הטמעה של מכשיר כוללת תמיכה ב-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, 99]. אם ההטמעה של המכשיר כוללת תמיכה ב-TDLS ו-TDLS מופעל על ידי WiFiManager API, המכשיר:

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

7.4.3. Bluetooth

בהטמעות של Android Watch ו-Android Automotive חייבת להיות תמיכה ב-Bluetooth. הטמעות של Android Television חייבות לתמוך ב-Bluetooth וב-Bluetooth LE.

ב-Android יש תמיכה ב-Bluetooth וב-Bluetooth עם צריכת אנרגיה נמוכה [מקורות מידע, 100]. הטמעות של מכשירים שכוללות תמיכה ב-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 ובמקורות מידע, 100.
מומלץ מאוד להטמיע זמן קצוב לתפוגה של כתובת פרטית שניתן לפתור (RPA) שלא יהיה ארוך מ-15 דקות, ולבצע רוטציה של הכתובת בתום הזמן הקצוב לתפוגה כדי להגן על פרטיות המשתמשים.
צריכה לתמוך בהעברת הלוגיקה של הסינון לצ'יפסט של ה-Bluetooth כשמטמיעים את ScanFilter API‏ [מקורות מידע, 101], וחובה לדווח על הערך הנכון של המיקום שבו הלוגיקה של הסינון מוטמעת בכל פעם שמתבצעת שאילתה באמצעות השיטה 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()‏ [משאבים, 70].
חייבת להיות לו אפשרות לקרוא ולכתוב הודעות NDEF באמצעות תקני ה-NFC הבאים:
- חייב להיות מסוגל לפעול כקורא/כותב של NFC Forum (כפי שמוגדר במפרט הטכני של NFC Forum‏ NFCForum-TS-DigitalProtocol-1.0) באמצעות תקני ה-NFC הבאים:
  - NfcA‏ (ISO14443-3A)
  - NfcB‏ (ISO14443-3B)
  - NfcF‏ (JIS X 6319-4)
  - IsoDep‏ (ISO 14443-4)
  - סוגי תגים של NFC Forum מס' 1, 2, 3, 4 (מוגדרים על ידי NFC Forum)
- מומלץ מאוד שיהיו יכולות לקרוא ולכתוב הודעות NDEF וגם נתונים גולמיים באמצעות תקני ה-NFC הבאים. חשוב לזכור שתקני ה-NFC שמפורטים בהמשך מומלצים מאוד, אבל בהגדרת התאימות של גרסה עתידית הם צפויים להשתנות ל'חובה'. התקנים האלה הם אופציונליים בגרסה הזו, אבל יהיו נדרשים בגרסאות עתידיות. מומלץ מאוד למכשירים קיימים וחדשים עם גרסת Android הזו לעמוד בדרישות האלה כבר עכשיו, כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה.
  - NfcV‏ (ISO 15693)
- אמורה להיות מסוגלת לקרוא את הברקוד ואת כתובת ה-URL (אם היא מקודדת) של מוצרים עם ברקוד NFC דק [משאבים, 102].
- חייבת להיות מסוגלת לשדר ולקבל נתונים באמצעות הפרוטוקולים והסטנדרטים הבאים של רשתות עמיתים לעמיתים:
  - ISO 18092
  - LLCP 1.2 (הוגדר על ידי NFC Forum)
  - SDP 1.0 (הוגדר על ידי NFC Forum)
  - פרוטוקול NDEF Push [מקורות מידע, 103]
  - SNEP 1.0 (הוגדר על ידי NFC Forum)
- חובה לכלול תמיכה ב-Android Beam‏ [משאבים, 104]:
  - חובה להטמיע את שרת ברירת המחדל של SNEP. הודעות NDEF תקינות שהתקבלו על ידי שרת SNEP שמוגדר כברירת מחדל חייבות להישלח לאפליקציות באמצעות ה-intent android.nfc.ACTION_NDEF_DISCOVERED. השבתת Android Beam בהגדרות לא מורידה את ההודעה הנכנסת מסוג NDEF.
  - חובה לפעול בהתאם לכוונה android.settings.NFCSHARING_SETTINGS כדי להציג את הגדרות השיתוף ב-NFC [משאבים, 105].
  - חובה להטמיע את שרת ה-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' [מקורות מידע, 106] ו'התאמה פשוטה ומאובטחת של Bluetooth באמצעות NFC גרסה 1.0' [מקורות מידע, 107] מ-NFC Forum. בהטמעה כזו חייבים להטמיע את שירות LLCP להעברה עם שם השירות urn:nfc:sn:handover לצורך החלפת הבקשה להעברה או בחירת הרשומות דרך NFC, וצריך להשתמש בפרופיל Bluetooth Object Push להעברת הנתונים בפועל ב-Bluetooth. מטעמי תאימות לעבר (כדי לשמור על תאימות למכשירי Android מגרסה 4.1), ההטמעה עדיין אמורה לקבל בקשות SNEP GET להחלפת בקשת ההעברה או רשומות נבחרות באמצעות NFC. עם זאת, לא מומלץ שההטמעה עצמה תשלח בקשות SNEP GET לביצוע העברת חיבור.
- חובה לבצע סקירה של כל הטכנולוגיות הנתמכות במצב NFC discovery.
- צריך להיות במצב חשיפת NFC כשהמכשיר פעיל, המסך פעיל ומסך הנעילה לא נעול.

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

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

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

בנוסף, הטמעות של מכשירים עשויות לכלול תמיכה בקורא/בכותב בטכנולוגיות 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, 70]. חשוב לזכור שזו לא תכונה רגילה של Android, ולכן היא לא מופיעה כקבועה בכיתה android.content.pm.PackageManager.
אסור להטמיע את ממשקי ה-API התואמים של Android או לדווח על התכונה com.nxp.mifare, אלא אם האפליקציה מטמיעה גם תמיכה כללית ב-NFC כפי שמתואר בקטע הזה.

אם הטמעת המכשיר לא כוללת חומרה של NFC, אסור להצהיר על התכונה android.hardware.nfc מהשיטה android.content.pm.PackageManager.hasSystemFeature()‏ [Resources, 70], וצריך להטמיע את 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).

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

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

מכשירי Wi-Fi חייבים לתמוך בשכבת ניתוב כפולה ובפעולה ב-IPv6 בלבד ב-Wi-Fi.
במכשירים שתומכים ברשתות Ethernet חייבת להיות תמיכה בפעולה בשכבת שתי סטאקים ב-Ethernet.
מכשירים שתומכים בחבילת גלישה אמורים לתמוך בפעולה של IPv6 (IPv6 בלבד, ואולי גם סטאק כפול) בחבילת גלישה.
כשמכשיר מחובר בו-זמנית ליותר מרשת אחת (למשל, Wi-Fi וחבילת גלישה), הוא חייב לעמוד בדרישות האלה בו-זמנית בכל רשת שאליה הוא מחובר.

חובה להפעיל את IPv6 כברירת מחדל.

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

חובה לשמור על קישוריות IPv6 במצב שינה.

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

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

7.5. מצלמות

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

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

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

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

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

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

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

חובה לדווח על דגל התכונה android.hardware.camera.any ועל android.hardware.camera.front.
חייבת להיות רזולוציה של לפחות VGA‏ (640x480 פיקסלים).
אסור להשתמש במצלמה קדמית כברירת מחדל ל-Camera API. ל-Camera API ב-Android יש תמיכה ספציפית במצלמות קדמיות, ואסור להגדיר את ה-API בהטמעות של מכשירים כך שיתייחס למצלמה הקדמית כמצלמה האחורית שמוגדרת כברירת מחדל, גם אם היא המצלמה היחידה במכשיר.
יכולות לכלול תכונות (כמו פוקוס אוטומטי, פלאש וכו') שזמינות למצלמות הפונות לאחור, כפי שמתואר בקטע 7.5.1.
חייב לשקף אופקית (כלומר לשקף) את הסטרימינג שמוצג על ידי אפליקציה ב-CameraPreview, באופן הבא:
- אם אפשר לסובב את הטלפון על ידי המשתמש (למשל באופן אוטומטי באמצעות תאוצה או באופן ידני באמצעות קלט מהמשתמש), התצוגה המקדימה של המצלמה חייבת להיות מוחזרת (mirrored) באופן אופקי ביחס לכיוון הנוכחי של המכשיר.
- אם האפליקציה הנוכחית ביקשה במפורש שמסך המצלמה יוזז באמצעות קריאה ל-method‏ android.hardware.Camera.setDisplayOrientation()[Resources, 110], התצוגה המקדימה של המצלמה חייבת להיות מוחזרת בפריסה אופקית ביחס לכיוון שצוין באפליקציה.
- אחרת, התצוגה המקדימה חייבת להיות מוחזרת על ציר האופק של המכשיר שמוגדר כברירת מחדל.
חייבת לשקף את התמונה שמוצגת על ידי התצוגה המקדימה באותו אופן שבו מופיע מקור התמונות של התצוגה המקדימה במצלמה. אם ההטמעה במכשיר לא תומכת ב-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‏ [משאבים, 111], ללא קשר לכך שהמכשיר כולל פוקוס אוטומטי בחומרה או יכולות אחרות. לדוגמה, מצלמות ללא מיקוד אוטומטי עדיין חייבות לקרוא לכל המופעים הרשומים של android.hardware.Camera.AutoFocusCallback (למרות שאין לכך רלוונטיות למצלמה ללא מיקוד אוטומטי). שימו לב שההנחה הזו רלוונטית גם למצלמות קדמיות. לדוגמה, למרות שרוב המצלמות הקדמיות לא תומכות בפוקוס אוטומטי, עדיין צריך "לזייף" את קריאות החזרה של ה-API כפי שמתואר.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.6.3. אחסון שניתן להתאמה

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

הטמעות של מכשירים כמו טלוויזיה עשויות לאפשר אימוץ דרך יציאות 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‏ [משאבים, 118].
- חובה לתמוך בהקמת תקשורת מבוססת פרוטוקול AOA במהלך החיבור הראשון למכונה מארחת USB שפועלת כאבזר, בלי שהמשתמש יצטרך לשנות את מצב ה-USB שמוגדר כברירת מחדל.
- חובה להטמיע את הכיתה USB audio כפי שמתואר במסמכי התיעוד של Android SDK‏ [משאבים, 119].
- בנוסף, בכיתה של אחסון בנפח גדול ב-USB חייבת להופיע המחרוזת 'android' בסוף המחרוזת iInterface של תיאור הממשק של אחסון בנפח גדול ב-USB.
צריך להטמיע תמיכה בזרם של 1.5A במהלך תנועה וצפצוף HS, כפי שמפורט במפרט הטעינה של סוללות USB, גרסה 1.2 [מקורות מידע, 120]. מומלץ מאוד שמכשירי 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, 119].
חובה להטמיע את Android USB host API כפי שמתואר ב-Android SDK, וחובה להצהיר על תמיכה בתכונת החומרה android.hardware.usb.host‏ [משאבים, 121].
צריך לתמוך בטעינה של המכשיר במצב מארח, לפרסם זרם מקור של לפחות 1.5A כפי שמפורט בקטע 'פרמטרים של סיום' במפרט של כבל USB Type-C ומחבר USB Type-C, גרסה 1.2 [] למחברים מסוג USB Type-C, או להשתמש בטווח זרם הפלט של יציאת טעינה במורד הזרם(CDP) כפי שמפורט במפרט של טעינה של סוללות USB, גרסה 1.2 [מקורות מידע, 120] למחברים מסוג Micro-AB.

7.8. אודיו

7.8.1. מיקרופון

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

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

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

7.8.2. יעד השמע

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

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

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

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

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

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

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

7.8.3. אולטרסאונד קרוב

אודיו קרוב לאולטרה-סאונד הוא התדר 18.5kHz עד 20kHz. הטמעות של מכשירים חייבות לדווח בצורה נכונה על התמיכה באודיו בתדרים של אולטרסאונד באמצעות ממשק ה-API AudioManager.getProperty באופן הבא:

אם הערך של PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND הוא true, אז
- תגובת הכוח הממוצעת של המיקרופון בתחום התדרים 18.5kHz עד 20kHz חייבת להיות נמוכה ב-15dB לכל היותר מהתגובה בתדר 2kHz.
- יחס האות לרעש (SNR) ללא משקל של המיקרופון בטווח של 18.5kHz עד 20kHz, עבור צלצול של 19kHz ב-26dBFS חייב להיות לפחות 50dB.
אם הערך של PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND הוא 'true', תגובת הממוצע של הרמקול בתחום התדרים 18.5kHz עד 20kHz חייבת להיות לפחות 40dB מתחת לתגובה בתדר 2kHz.

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.

8.3. מצבי חיסכון בסוללה

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

8.4. ניהול חשבונות של צריכת חשמל

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

חובה להיות מסוגלים לעקוב אחרי צריכת החשמל של רכיבי החומרה ולשייך את צריכת החשמל הזו לאפליקציות ספציפיות. באופן ספציפי, הטמעות:
- חובה לספק פרופיל צריכת אנרגיה לכל רכיב, שמגדיר את ערך הצריכה הנוכחי של כל רכיב חומרה ואת הירידה המשוערת בנפח הסוללה שנגרמת על ידי הרכיבים לאורך זמן, כפי שמופיע באתר של Android Open Source Project‏ [משאבים, 123].
- חובה לדווח על כל ערכי צריכת החשמל בשעות מיליאמפר (mAh)
- צריך לשייך לרכיב החומרה עצמו אם אי אפשר לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.
- חובה לדווח על צריכת האנרגיה של המעבד (CPU) לכל מזהה UID של תהליך. פרויקט הקוד הפתוח של Android עומד בדרישות באמצעות הטמעת מודול הליבה uid_cputime.
חובה להפוך את צריכת האנרגיה הזו לזמינה למפתח האפליקציה באמצעות פקודת המעטפת adb shell dumpsys batterystats [משאבים, 124].
חובה לפעול בהתאם לכוונה android.intent.action.POWER_USAGE_SUMMARY ולהציג תפריט הגדרות שבו מוצג צריכת האנרגיה הזו [מקורות מידע, 125].

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

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

9.1. הרשאות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ב-Android יש תמיכה במספר משתמשים ותמיכה בבידוד מלא של משתמשים [משאבים, 127]. אפשר להפעיל במכשירים תמיכה בכמה משתמשים, אבל כשהיא מופעלת, היא חייבת לעמוד בדרישות הבאות שקשורות לתמיכה בכמה משתמשים [משאבים, 128]:

הטמעות של מכשירים שלא מגדירות את דגל התכונה android.hardware.telephony חייבות לתמוך בפרופילים מוגבלים. זוהי תכונה שמאפשרת לבעלי המכשיר לנהל משתמשים נוספים ואת היכולות שלהם במכשיר. באמצעות פרופילים מוגבלים, בעלי המכשירים יכולים להגדיר במהירות סביבות נפרדות למשתמשים נוספים, ולנהל הגבלות מפורטות יותר על האפליקציות שזמינות בסביבות האלה.
לעומת זאת, הטמעות של מכשירים שמצהירות על דגל התכונה android.hardware.telephony חייבות להתאים להטמעה של אמצעי הבקרה ב-AOSP כדי לאפשר או להשבית למשתמשים אחרים גישה לשיחות הקוליות ולהודעות ה-SMS.
בהטמעות של מכשירים, לכל משתמש חייב להיות מודל אבטחה שתואם למודל האבטחה של פלטפורמת Android, כפי שמוגדר במסמך העזרה בנושא אבטחה והרשאות ב-API‏ [משאבים, 126].
לכל מופע משתמש במכשיר Android חייבות להיות ספריות אחסון חיצוניות נפרדות ומבודדות. הטמעות במכשירים עשויות לאחסן נתונים של כמה משתמשים באותו נפח אחסון או באותה מערכת קבצים. עם זאת, ההטמעה במכשיר חייבת לוודא שאפליקציות שנמצאות בבעלות משתמש מסוים ופועלות בשם המשתמש הזה לא יכולות להציג רשימה של נתונים שנמצאים בבעלות משתמש אחר, לקרוא אותם או לכתוב בהם. חשוב לזכור שמדיה נשלפת, כמו חריצי כרטיסי SD, יכולה לאפשר למשתמש אחד לגשת לנתונים של משתמש אחר באמצעות מחשב מארח. לכן, הטמעות של מכשירים שמשתמשות במדיה נשלפת ל-APIs הראשיים של האחסון החיצוני חייבות להצפין את התוכן של כרטיס ה-SD אם התכונה 'שימוש בכמה משתמשים' מופעלת, באמצעות מפתח שנשמר רק במדיה לא נשלפת שרק למערכת יש גישה אליה. מכיוון שהשינוי הזה ימנע ממחשבים מארחים לקרוא את המדיה, הטמעות של מכשירים יצטרכו לעבור ל-MTP או למערכת דומה כדי לספק למחשבים מארחים גישה לנתונים של המשתמש הנוכחי. בהתאם, אפשר להפעיל את התכונה 'שימוש בכמה משתמשים' בהטמעות של מכשירים, אבל לא מומלץ לעשות זאת אם הם משתמשים במדיה נשלפת [משאבים, 129] לאחסון חיצוני ראשי.

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

ב-Android יש תמיכה באזהרה למשתמשים על כל הודעת SMS פרימיום יוצאת [מקורות מידע, 130]. הודעות 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 ב-Android Open Source Project, ולהוסיף לה רק את ההגדרות הספציפיות למכשיר. הטמעות במכשירים חייבות להיות תואמות ל-Android Open Source Project (פרויקט הקוד הפתוח של Android) ב-upstream.

9.8. פרטיות

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

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

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

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

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

אם ההטמעה במכשיר תומכת במסך נעילה מאובטח שמדווח על הערך true עבור KeyguardManager.isDeviceSecure()‏ [מקורות מידע, 131], והמכשיר לא כולל זיכרון מוגבל כפי שמדווח על ידי השיטה ActivityManager.isLowRamDevice(), המכשיר חייב לתמוך בהצפנת דיסק מלאה [מקורות מידע, 132] של הנתונים הפרטיים של האפליקציה (מחיצה /data), וגם של המחיצה של האחסון המשותף של האפליקציה (מחיצה /sdcard) אם היא חלק קבוע ולא ניתן להסיר אותה מהמכשיר.

בהטמעות של מכשירים שתומכים בהצפנת דיסק מלאה ובביצועי הצפנה של Advanced Encryption Standard‏ (AES) מעל 50MiB/sec, חובה להפעיל את ההצפנה של הדיסק המלא כברירת מחדל ברגע שהמשתמש משלים את חוויית ההגדרה מחוץ לקופסה. אם הטמעת המכשיר כבר הושקתה בגרסה קודמת של Android עם הצפנה מלאה של הדיסק מושבתת כברירת מחדל, המכשיר לא יכול לעמוד בדרישות באמצעות עדכון של תוכנת המערכת, ולכן יכול להיות שהוא יהיה פטור.

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

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

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

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

ב-Android Open Source Project (פרויקט הקוד הפתוח של Android) יש הטמעה מועדפת של התכונה הזו, שמבוססת על התכונה dm-verity בליבה של Linux.

החל מגרסה 6.0 של Android, הטמעות של מכשירי הצפנה עם Advanced Encryption Standard‏ (AES) שמספקות ביצועי הצפנה של יותר מ-50MiB/שנייה חייבות לתמוך בהפעלה מאומתת כדי לשמור על תקינות המכשיר. אם הטמעת מכשיר כבר הושקתה בלי תמיכה באתחול מאומת בגרסה קודמת של Android, לא ניתן להוסיף תמיכה בתכונה הזו באמצעות עדכון של תוכנת המערכת, ולכן המכשיר הזה פטור מהדרישה.

9.11. מפתחות ופרטי כניסה

מערכת Android Keystore‏[משאבים, 133] מאפשרת למפתחי אפליקציות לאחסן מפתחות קריפטוגרפיים בקונטיינר ולהשתמש בהם בפעולות קריפטוגרפיות באמצעות KeyChain API‏[משאבים, 134] או Keystore API‏[משאבים, 135].

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

לא מומלץ להגביל את מספר המפתחות שאפשר ליצור, וצריך לאפשר לייבא לפחות 8,192 מפתחות.
האימות במסך הנעילה חייב להגביל את מספר הניסיונות, ורצוי שתהיה לו אלגוריתם חזרה מעריכית (backoff) כפי שהוטמע בפרויקט הקוד הפתוח של Android.
כשהטמעת המכשיר תומכת במסך נעילה מאובטח ויש לו חומרה מאובטחת, כמו רכיב מאובטח (SE) שבו אפשר להטמיע סביבת מחשוב אמינה (TEE), המכשיר:
- מומלץ מאוד לגבות את הטמעת מאגר המפתחות באמצעות החומרה המאובטחת. בפרויקט Android Open Source Project (upstream) יש הטמעה של שכבת האובייקטים המצומצמים לחומרה (HAL) של Keymaster, שאפשר להשתמש בה כדי לעמוד בדרישות האלה.
- חובה לבצע את האימות של מסך הנעילה בחומרה המאובטחת אם במכשיר יש הטמעה של מאגר מפתחות שמבוסס על חומרה, ורק אם האימות מצליח, לאפשר שימוש במפתחות שמקושרים לאימות. בפרויקט הקוד הפתוח של Android ב-upstream יש את שכבת האובייקטים המצומצמים (HAL) של החומרה של Gatekeeper, שאפשר להשתמש בה כדי לעמוד בדרישות האלה [Resources, 136].

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

9.12. מחיקת נתונים

המכשירים חייבים לספק למשתמשים מנגנון לביצוע 'איפוס לנתוני היצרן' שמאפשר מחיקה לוגית ופיזית של כל הנתונים, מלבד קובץ האימג' של המערכת ונתונים במחיצות אחרות שאפשר להתייחס אליהן כחלק מקובץ האימג' של המערכת. הנתונים האלה חייבים לעמוד בתקנים הרלוונטיים בתחום למחיקת נתונים, כמו NIST SP800-88. חובה להשתמש בזה להטמעת ה-API של wipeData()‏ (חלק מ-Android Device Administration API) שמתואר בקטע 3.9 Device Administration.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מערכת Android כוללת תכונות שמאפשרות לאפליקציית הבעלים של המכשיר (אם היא קיימת) לשלוט בהתקנה של עדכוני המערכת. כדי לאפשר זאת, תת-המערכת של עדכון המערכת במכשירים שמדווחים על android.software.device_admin חייבת להטמיע את ההתנהגות שמתוארת בכיתה SystemUpdatePolicy‏ [ מקורות מידע, 138].

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

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

קטע	סיכום השינויים
מחברים שונים	מופעים של המונח 'מומלץ' הוחלפו במופעים של המונח 'מומלץ'
2. סוגי מכשירים	עדכון להטמעות של Android Automotive
3.2.2. פרמטרים של build	תוספות למספר הסידורי של החומרה ולרמת תיקון האבטחה של גרסה זמנית
3.2.3.2. פתרון של כוונה	שם הקטע שונה מ-Intent Overrides (שינוי של כוונת השימוש) ל-Intent Resolution (פתרון כוונת השימוש), עם דרישות חדשות שקשורות לקישור מהימן של אפליקציית ברירת המחדל
3.3.1. ממשקי Application Binary Interface	תוספות לתמיכה ב-ABI ל-Android; שינוי שקשור לשם הספרייה של Vulkan
3.4.1. תאימות ל-WebView	שינוי במחרוזת של סוכן המשתמש שדווחה על ידי WebView
3.7. תאימות בסביבת זמן הריצה	עדכונים בטבלת הקצאת הזיכרון
3.8.4. חיפוש	עדכונים לגבי הדרישות ל-Assistant
3.8.6. עיצובים	נוספה דרישה לתמוך בסמלי מערכת שחורים כשהדגל SYSTEM_UI_FLAG_LIGHT_STATUS_BAR מופעל
3.8.8. מעבר בין פעילויות	הוספת כותרות לסקירה הכללית ללא הגבלה.
3.8.10. שליטה במדיה במסך הנעילה	'בקרת מדיה במסך הנעילה' כדי לעיין בפירוט בקטע 3.8.3.
3.9.1. הקצאת מכשיר (Provisioning)	מכיל קטעים חדשים להקצאה של בעלים של מכשיר ולהקצאה של פרופיל מנוהל
3.9.2. תמיכה בפרופיל מנוהל	קטע חדש עם דרישות לתמיכה במכשירים בפונקציונליות של פרופיל מנוהל
3.12.1. אפליקציית הטלוויזיה	הוספנו קטע להבהרת הדרישות של אפליקציות הטלוויזיה למכשירי Android Television
3.12.1.1. מדריך תוכניות אלקטרוני	הוסף קטע להבהרת הדרישות ל-EPG במכשירי Android Television
3.12.1.2. ניווט	הוספנו קטע כדי להבהיר את דרישות הניווט באפליקציית הטלוויזיה במכשירי Android Television
3.12.1.3. קישור של אפליקציית קלט טלוויזיה	נוסף קטע להבהרת דרישות התמיכה בקישור של אפליקציות קלט לטלוויזיה במכשירי Android Television
5.1. קודקים של מדיה	עדכונים לגבי תמיכה בפורמטים מרכזיים של מדיה ובפענוח.
5.1.3. קודיקים של וידאו	שינויים ותוספות שקשורים לטלוויזיות Android
5.2. קידוד וידאו	שינויים בקודקים
5.3. פענוח וידאו	שינויים במפענחים, כולל תמיכה ברזולוציית וידאו דינמית, החלפת קצב פריימים ועוד
5.4. הקלטת אודיו	תוספות שקשורות לצילום אודיו
5.6. זמן אחזור אודיו (audio latency)	עדכון לגבי דיווח על תמיכה באודיו עם זמן אחזור קצר
5.10. אודיו מקצועי	עדכונים כלליים לתמיכה באודיו מקצועי, עדכונים למפרטים של מכשירים ניידים (שקע), מצב מארח אודיו ב-USB ועדכונים נוספים
5.9. ממשק דיגיטלי לכלים מוזיקליים (MIDI)	נוספ קטע חדש בנושא תמיכה אופציונלית בממשק דיגיטלי לכלים מוזיקליים (MIDI)
6.1. כלים למפתחים	עדכון למנהלי התקנים שתומכים ב-Windows 10
7.1.1.3. דחיסות מסך	עדכונים לגבי דחיסות המסך, למשל עדכונים שקשורים לשעון Android
7.2.3. מקשי ניווט	דרישות מעודכנות להטמעות במכשירים שכוללות את הפעולה 'עזרה'
7.3. חיישנים (ותת-קטעים)	דרישות חדשות לסוגים מסוימים של חיישנים
7.3.9. חיישנים באיכות גבוהה	קטע חדש עם דרישות למכשירים שתומכים בחיישנים ברמת דיוק גבוהה
7.3.10. חיישן טביעות אצבע	קטע חדש על דרישות שקשורות לחיישנים של טביעות אצבע
7.4.2. IEEE 802.11‏ (Wi-Fi)	עדכונים לגבי תמיכה ב-Multicast DNS‏ (mDNS)
7.4.3. Bluetooth	תוספת שקשורה לכתובת פרטית שניתן לפתור (RPA) ל-Bluetooth עם צריכת אנרגיה נמוכה (BLE)
7.4.4. תקשורת מטווח קצר	תוספות לדרישות של תקשורת מטווח קצר (NFC)
7.4.5. יכולת רשת מינימלית	הוספנו דרישות לתמיכה ב-IPv6
7.6.3. אחסון שניתן להתאמה	קטע חדש להטמעת אחסון שניתן להתאמה
7.7. USB	דרישה שקשורה להטמעת מפרט AOA
7.8.3. אולטרסאונד קרוב	תוספות שקשורות להקלטה, להפעלה ולאודיו בתדרים של אולטרסאונד	הקלה בדרישות של יחס אות/רעש (SNR) של מיקרופון ליד אולטרסאונד.
8.3. מצבי חיסכון בסוללה	קטע חדש עם דרישות לגבי המצבים 'המתנה לאפליקציה' ו'שינה עמוקה'
8.4. ניהול חשבונות של צריכת חשמל	קטע חדש עם דרישות למעקב אחר צריכת החשמל של רכיבי החומרה ושיוך של צריכת החשמל הזו לאפליקציות ספציפיות
9.1. הרשאות	הוספה לדרישות של Permissions
9.7. תכונות אבטחה בליבה	עדכוני SE Linux
9.8. פרטיות	תוספת לגבי הסכמת המשתמש לגישה לאחסון משותף דרך יציאת USB
9.9. הצפנת דיסק מלאה	דרישות שקשורות להצפנת דיסק מלאה
9.10. אתחול מאומת	דרישה נוספת לאתחול מאומת
9.11. מפתחות ופרטי כניסה	קטע חדש של דרישות שקשורות למפתחות ולפרטי כניסה
9.12. מחיקת נתונים	קטע חדש ל'איפוס לנתוני היצרן'
11. תוכנה שניתן לעדכן	דרישה שקשורה למדיניות עדכון המערכת שהוגדרה על ידי בעלי המכשיר

13. יצירת קשר

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

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. Android UI_MODE_TYPE_CAR API: ‏ http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR

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

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

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

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

10. הגדרות למפתחי Android: http://developer.android.com/reference/android/provider/Settings.html

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

12. ניהול ABI ב-Android NDK: https://developer.android.com/ndk/guides/abis.html

13. ארכיטקטורת SIMD מתקדמת: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

31. ממשקי Android Assist API: https://developer.android.com/reference/android/app/assist/package-summary.html

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

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

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

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

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

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

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

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

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

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

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

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

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

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

46. אפליקציית הבעלים של המכשיר: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

47. תהליך ההקצאה של הבעלים של מכשיר Android: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE

48. הקצאה לבעלי המכשיר באמצעות NFC: /devices/tech/admin/provision.html#device_owner_provisioning_via_nfc

49. אפליקציה של הבעלים של פרופיל Android:http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProfileOwnerApp(java.lang.String)

50. תהליך הקצאת הרשאות לפרופיל מנוהל ב-Android: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE

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

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

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

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

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

56. ערוצים של אפליקציות טלוויזיה: http://developer.android.com/reference/android/media/tv/TvContract.Channels.html

57. מקורות קלט של טלוויזיות של צד שלישי: /devices/tv/index.html#third-party_input_example

58. מקורות קלט בטלוויזיה: /devices/tv/index.html#tv_inputs

59. שדות EPG של ערוץ טלוויזיה: https://developer.android.com/reference/android/media/tv/TvContract.Programs.html

60. קישור אפליקציות קלט לטלוויזיה: http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI

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

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

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

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

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

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

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

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

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

70. הכיתה android.content.pm.PackageManager של Android ורשימת תכונות החומרה: http://developer.android.com/reference/android/content/pm/PackageManager.html

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

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

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

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

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

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

77. הגדרות שקשורות לפיתוח אפליקציות ל-Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

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

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

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

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

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

83. תוסף EGL‏ – EGL_ANDROID_RECORDABLE: ‏ http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

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

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

86. הגדרת קלט מגע: http://source.android.com/docs/core/interaction/input/touch-devices

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

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

89. חיישנים בקוד פתוח של Android: http://source.android.com/docs/core/interaction/sensors

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

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

92. חיישנים מורכבים בקוד פתוח של Android: /docs/core/interaction/sensors/sensor-types#composite_sensor_type_summary

93. מצב הפעלה רציף: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER

95. Android Fingerprint API: ‏ https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html

96. Android Fingerprint HAL: ‏ /devices/tech/security/authentication/fingerprint-hal.html

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

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

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

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

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

102. קוד QR ל-NFC: http://developer.android.com/reference/android/nfc/tech/NfcBarcode.html

103. פרוטוקול דחיפה של NDEF: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

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

105. הגדרות שיתוף NFC ב-Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

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

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

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

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

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

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

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

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

114. תמיכה בגרסאות של מצלמות: http://source.android.com/docs/core/camera/versioning

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

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

117. אחסון שניתן להתאמה: http://source.android.com/docs/core/storage/adoptable

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

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

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

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

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

123. רכיבים של פרופיל צריכת החשמל: http://source.android.com/docs/core/power/values

124. Batterystats: ‏ https://developer.android.com/tools/dumpsys#battery

125. סיכום של צריכת החשמל: http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY

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

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

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

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

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

131. דיווח על מסך נעילה מאובטח: http://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure()

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

133. מערכת Android Keystore: https://developer.android.com/training/articles/keystore.html

134. KeyChain API: ‏ https://developer.android.com/reference/android/security/KeyChain.html

135. Keystore API: ‏ https://developer.android.com/reference/java/security/KeyStore.html

136. Gatekeeper HAL: ‏ http://source.android.com/docs/security/features/authentication/gatekeeper

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

138. הכיתה SystemUpdatePolicy: http://developer.android.com/reference/android/app/admin/SystemUpdatePolicy.html

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

140. טיפול בקישורים לאפליקציות: https://developer.android.com/training/app-links/index.html

141. קישורי נכסים דיגיטליים של Google: https://developers.google.com/digital-asset-links

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