1. מבוא

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• חייב להיות מסך עם אורך אלכסון פיזי שווה ל-6 אינץ' או יותר.
• חובה להצהיר על התכונה android.hardware.type.automotive.
• חובה לתמוך ב-uiMode = UI_MODE_TYPE_CAR.
• הטמעות של Android Automotive חייבות לתמוך בכל ממשקי ה-API הציבוריים במרחב השמות android.car.*.

כל הטמעות המכשירים עם Android שלא מתאימות לאף אחד מסוגי המכשירים שלמעלה עדיין חייבות לעמוד בכל הדרישות שמפורטות במסמך הזה כדי להיות תואמות ל-Android 7.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	צריך	צריך		צריך	צריך
	Wi-Fi ישיר	7.4.2.1. Wi-Fi ישיר	צריך	צריך			צריך
	Bluetooth	7.4.3. Bluetooth	צריך	MUST	MUST	MUST	צריך
	Bluetooth עם צריכת אנרגיה נמוכה (BLE)	7.4.3. Bluetooth	צריך	MUST	צריך	צריך	צריך
	רדיו סלולרי	7.4.5. יכולת רשת מינימלית				צריך
	מצב ציוד היקפי/מארח ב-USB	7.7. USB	צריך			צריך	צריך
פלט	יציאות של רמקולים ו/או אודיו	7.8.2. פלט אודיו	MUST	MUST		MUST	MUST

3. תוכנות

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

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

הטמעות במכשירים חייבות לתמוך בכל הכיתות, השיטות והרכיבים המשויכים שמסומנים בהערה TestApi‏ (@TestApi).

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

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

3.1.1. תוספים ל-Android

ב-Android יש תמיכה בהרחבת ממשקי ה-API המנוהלים תוך שמירה על אותה גרסה ברמת ה-API. הטמעות של מכשירי Android חייבות לטעון מראש את הטמעת AOSP של הספרייה המשותפת ExtShared ושל השירותים ExtServices בגרסאות שגדולות או שוות לגרסאות המינימליות המותרות לכל רמת API. לדוגמה, הטמעות במכשירי Android 7.0 שפועלות ברמת API 24 חייבות לכלול לפחות גרסה 1.

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

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

3.2.1. הרשאות

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

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

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

פרמטר	פרטים
VERSION.RELEASE	הגרסה של מערכת Android שפועלת כרגע, בפורמט קריא לבני אדם. השדה הזה חייב לכלול אחד מערכי המחרוזות שהוגדרו ב-7.0.
VERSION.SDK	הגרסה של מערכת Android שפועלת כרגע, בפורמט שגלוי לקוד של אפליקציות של צד שלישי. ב-Android 7.0, השדה הזה חייב לכלול את הערך השלם 7.0_INT.
VERSION.SDK_INT	הגרסה של מערכת Android שפועלת כרגע, בפורמט שגלוי לקוד של אפליקציות של צד שלישי. ב-Android 7.0, השדה הזה חייב לכלול את הערך השלם 7.0_INT.
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:7.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 או בעדכון האבטחה של Android, לדוגמה '2015-11-01'.
BASE_OS	ערך שמייצג את הפרמטר FINGERPRINT של ה-build, שהוא זהה ל-build הזה מלבד התיקונים שסופקו בעדכון האבטחה הציבורי של Android. חובה לדווח על הערך הנכון, ואם לא קיים build כזה, צריך לדווח על מחרוזת ריקה ("").

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

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

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

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

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

3.2.3.2. פתרון של כוונה

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

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

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

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

• חובה לנסות לאמת מסנני Intent על ידי ביצוע שלבי האימות שמוגדרים במפרט של קישורי נכסים דיגיטליים, כפי שהם מיושמים על ידי מנהל החבילות ב-Android Open Source Project (פרויקט Android בקוד פתוח) ב-upstream.
• חובה לנסות לאמת את מסנני הכוונה במהלך התקנת האפליקציה ולהגדיר את כל מסנני הכוונה של UIR שאומתו בהצלחה כמפעילי אפליקציה שמוגדרים כברירת מחדל ל-UIR שלהם.
• יכולים להגדיר מסנני כוונה ספציפיים של URI כמפעילי אפליקציות ברירת מחדל למזהי ה-URI שלהם, אם הם אומתו בהצלחה אבל מסנני URI אחרים לא עברו את תהליך האימות. אם הטמעה של מכשיר עושה זאת, היא חייבת לספק למשתמש שינויים מתאימים לדפוס לכל URI בתפריט ההגדרות.
• חובה לספק למשתמש אמצעי בקרה על קישורי האפליקציות לכל אפליקציה בהגדרות, באופן הבא:
  • המשתמש חייב להיות מסוגל לשנות באופן מקיף את התנהגות ברירת המחדל של קישורים לאפליקציות, כך שהאפליקציה תמיד תיפתח, תמיד תשאל או אף פעם לא תיפתח. המדיניות הזו חייבת לחול באופן שווה על כל מסנני הכוונה של URI מועמדים.
  • המשתמש חייב להיות מסוגל לראות רשימה של מסנני הכוונה ל-URI המועמדים.
  • הטמעת המכשיר עשויה לספק למשתמש את היכולת לשנות מסנני כוונה ספציפיים של URI שהיו מועמדים לאימות ואשר אומתו בהצלחה, על בסיס מסנן כוונה לכל אחד.
  • אם הטמעת המכשיר מאפשרת לחלק ממסנני הכוונה של URI מועמדים לעבור את האימות, בעוד שחלק אחר לא יכולים לעבור אותו, הטמעת המכשיר חייבת לספק למשתמשים את היכולת להציג ולשנות מסנני כוונה ספציפיים של URI מועמדים.

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

אסור שהטמעות במכשירים יכללו רכיב Android שמתייחס לתבניות חדשות של כוונות או כוונות שידור באמצעות ACTION,‏ CATEGORY או מחרוזת מפתח אחרת במרחב השמות android. ‏ או com.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.
• חובה לספק תפריט הגדרות שיפעיל את הכוונה android.provider.Telephony.ACTION_CHANGE_DEFAULT כדי להציג תיבת דו-שיח לשינוי אפליקציית ברירת המחדל ל-SMS, אם ההטמעה במכשיר מדווחת על android.hardware.telephony.
• חובה לפעול לפי הכוונה של android.settings.NFC_PAYMENT_SETTINGS כדי להציג תפריט הגדרות ברירת מחדל של אפליקציה ל'מצמידים ומשלמים', אם ההטמעה במכשיר מדווחת על android.hardware.nfc.hce.
• חובה לפעול לפי הכוונה android.telecom.action.CHANGE_DEFAULT_DIALER כדי להציג תיבת דו-שיח שמאפשרת למשתמש לשנות את אפליקציית ברירת המחדל של הטלפון, אם ההטמעה במכשיר מדווחת על android.hardware.telephony .

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

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

3.3.1. ממשקי Application Binary Interface

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

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

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

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

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

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

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

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

הטמעות במכשירים יכולות להוסיף ספריות שאינן AOSP ולהציג אותן ישירות כ-API לאפליקציות של צד שלישי, אבל הספריות הנוספות צריכות להיות ב-/vendor/lib או ב-/vendor/lib64 וחובה לרשום אותן ב-/vendor/etc/public.libraries.txt .

חשוב לזכור שהטמעות במכשירים חייבות לכלול את libGLESv3.so, ובתגובה, חייבות לייצא את כל סמלי הפונקציות של OpenGL ES 3.1 ושל Android Extension Pack כפי שהם מוגדרים במהדורת NDK android-24. כל הסמלים חייבים להופיע, אבל רק הפונקציות התואמות לגרסאות ולתוספים של OpenGL ES שנתמכים בפועל במכשיר צריכות להיות מוטמעות באופן מלא.

3.3.1.1. ספריות גרפיקה

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

• תמיד צריך לספק ספרייה מקומית בשם libvulkan.so שמייצא סמלי פונקציות לממשק ה-API של Vulkan 1.0 , וגם את התוספים VK_KHR_surface , ‏ VK_KHR_android_surface ו-VK_KHR_swapchain.

הטמעות במכשירים, אם הן כוללות תמיכה ב-Vulkan APIs:

• חובה לדווח על VkPhysicalDevices אחד או יותר באמצעות הקריאה ל-vkEnumeratePhysicalDevices.
• כל VkPhysicalDevices שמפורטים חייבים ליישם באופן מלא את Vulkan 1.0 API.
• חובה לדווח על דגלי התכונות הנכונים PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL ו-PackageManager#FEATURE_VULKAN_HARDWARE_VERSION.
• חובה למנות שכבות שמכילות ספריות מקוריות בשם libVkLayer*.so בספריית הספריות המקוריות של חבילת האפליקציה, באמצעות הפונקציות vkEnumerateInstanceLayerProperties ו-vkEnumerateDeviceLayerProperties ב-libvulkan.so
• אסור למנות שכבות שסופקו על ידי ספריות מחוץ לחבילת האפליקציה, או לספק דרכים אחרות למעקב אחרי Vulkan API או ליירט אותו, אלא אם לאפליקציה יש את המאפיין android:debuggable=”true”.

הטמעות במכשירים, אם הן לא כוללות תמיכה ב-Vulkan APIs:

• חובה לדווח על 0 VkPhysicalDevices באמצעות הקריאה vkEnumeratePhysicalDevices.
• אסור להצהיר על אף אחד מדגלי התכונות של Vulkan‏ PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL ו-PackageManager#FEATURE_VULKAN_HARDWARE_VERSION.

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).

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

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

3.4.1. תאימות ל-WebView

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

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

• מחרוזת סוכן המשתמש שמדווחת על ידי 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.
  • הטמעות של מכשירים עשויות להשמיט את 'נייד' במחרוזת של סוכן המשתמש.

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

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

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

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

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

• מטמון האפליקציה/פעולה אופליין
• תג<video>
• geolocation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.3. התראות

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

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

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

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

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

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

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

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

• חובה להטמיע פעילות שתגיב לכוונה ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS. בהטמעות עם UI_MODE_TYPE_NORMAL, הפעילות הזו חייבת להיות פעילות שבה המשתמש יכול להעניק או לדחות לאפליקציה גישה להגדרות של מדיניות ההתראות.
• חובה, במקרים שבהם ההטמעה במכשיר מספקת למשתמש אמצעי להעניק או לדחות לאפליקציות צד שלישי גישה להגדרת מדיניות ההתראות, להציג כללים אוטומטיים של התראות שנוצרו על ידי אפליקציות לצד הכללים שנוצרו על ידי המשתמש וכללים מוגדרים מראש.
• חייבת לפעול בהתאם לערכים של suppressedVisualEffects שמועברים דרך NotificationManager.Policy. אם אפליקציה מגדירה את הדגלים SUPPRESSED_EFFECT_SCREEN_OFF או SUPPRESSED_EFFECT_SCREEN_ON, היא אמורה להציג למשתמש בתפריט ההגדרות של 'נא לא להפריע' שהאפקטים החזותיים מושבתים.

3.8.4. חיפוש

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

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

יש להטמיע עוזרת במכשיר במערכות Android, ויש להטמיע אותה במערכות Android Automotive כדי לטפל בפעולת העזרה.

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

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

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

3.8.6. עיצובים

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.9. ניהול קלט

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

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

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

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

3.8.11. שומרי מסך (לשעבר 'חלומות')

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

3.8.12. מיקום

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

3.8.13. Unicode וגופן

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

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

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.8.14. ריבוי חלונות

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

• אפליקציות יכולות לציין בקובץ AndroidManifest.xml אם הן מסוגלות לפעול במצב של חלונות מרובים, באופן מפורש באמצעות המאפיין android:resizeableActivity או באופן משתמע על ידי הגדרת targetSdkVersion > 24. אסור להפעיל אפליקציות שהגדירו את המאפיין הזה כ-false במפורש במניפסט שלהן במצב של חלונות מרובים. אפשר להפעיל אפליקציות שלא מגדירות את המאפיין בקובץ המניפסט שלהן (targetSdkVersion < 24) במצב ריבוי חלונות, אבל המערכת חייבת להציג אזהרה על כך שייתכן שהאפליקציה לא תפעל כצפוי במצב ריבוי חלונות.
• אסור להציע במכשירים מצב מסך מפוצל או מצב פורמט חופשי אם גובה המסך והרוחב שלו קטנים מ-440dp.
• הטמעות של מכשירים עם גודל מסך xlarge אמורות לתמוך במצב 'טקסט חופשי'.
• הטמעות של מכשירי Android Television חייבות לתמוך במצב 'תמונה בתוך תמונה' (PIP) עם כמה חלונות, ולהציב את החלונות הרבים של PIP בפינה השמאלית העליונה כשה-PIP מופעל.
• בהטמעות במכשירים עם תמיכה בריבוי חלונות במצב 'תמונה בתוך תמונה', חובה להקצות לפחות 240x135dp לחלון 'תמונה בתוך תמונה'.
• אם יש תמיכה במצב ריבוי חלונות ב-PIP, חובה להשתמש במקש KeyEvent.KEYCODE_WINDOW כדי לשלוט בחלון ה-PIP. אחרת, המפתח חייב להיות זמין לפעילות שבחזית.

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

מערכת Android כוללת תכונות שמאפשרות לאפליקציות עם תמיכה באבטחה לבצע פונקציות של ניהול מכשירים ברמת המערכת, כמו אכיפה של מדיניות סיסמאות או ביצוע מחיקה מרחוק, באמצעות Android Device Administration API. הטמעות של מכשירים חייבות לספק הטמעה של המחלקה DevicePolicyManager. הטמעות של מכשירים שתומכים במסך נעילה מאובטח חייבות ליישם את כל המדיניות של ניהול המכשיר שמוגדרת במסמכי התיעוד של Android SDK, ולדווח על תכונת הפלטפורמה android.software.device_admin.

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

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

אם הטמעה של מכשיר מצהירה על התכונה android.software.device_admin, חובה להטמיע את הקצאת אפליקציית הבעלים של המכשיר של אפליקציית לקוח של מדיניות המכשיר (DPC) כפי שמפורט בהמשך:

• כשעדיין לא הוגדרו נתוני משתמשים בהטמעה במכשיר, הוא:
  • חובה לדווח על true עבור DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
  • חובה לרשום את אפליקציית ה-DPC כאפליקציית הבעלים של המכשיר בתגובה לפעולה של כוונת הפעולה android.app.action.PROVISION_MANAGED_DEVICE.
  • חובה לרשום את אפליקציית ה-DPC כאפליקציית הבעלים של המכשיר אם המכשיר מצהיר על תמיכה בתקשורת מטווח קצר (NFC) באמצעות דגל התכונה android.hardware.nfc ומקבל הודעת NFC שמכילה רשומה עם סוג MIME‏ MIME_TYPE_PROVISIONING_NFC.
• כשהטמעת המכשיר כוללת נתוני משתמשים, היא:
  • חובה לדווח על false עבור DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
  • אסור יותר לרשום אפליקציית DPC כלשהי כאפליקציית הבעלים של המכשיר.

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

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

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

חוויית המשתמש בתהליך הקצאת הפרופיל המנוהל (התהליך שמופעל על ידי android.app.action.PROVISION_MANAGED_PROFILE) חייבת להיות תואמת ליישום ב-AOSP.

הטמעות במכשירים חייבות לספק את האפשרויות הבאות למשתמש בממשק המשתמש של ההגדרות, כדי לציין למשתמש מתי פונקציית מערכת מסוימת הושבתה על ידי ה-Device Policy Controller‏ (DPC):

• סמל עקבי או תכונה נגישה אחרת למשתמש (לדוגמה, סמל המידע של AOSP במקור) שמייצג מצב שבו אדמין של מכשיר הגביל הגדרה מסוימת.
• הודעת הסבר קצרה, כפי שסיפק מנהל המכשיר דרך setShortSupportMessage.
• הסמל של אפליקציית ה-DPC.

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.
• לאפשר ליצור פרופיל מנוהל אחד בלבד.
• משתמשים בתג סמל (בדומה לתג העבודה של AOSP upstream) כדי לייצג את האפליקציות והווידג'טים המנוהלים ורכיבי ממשק משתמש אחרים עם תגים, כמו 'מהזמן האחרון' ו'התראות'.
• הצגת סמל התראה (בדומה לתג העבודה של AOSP upstream) כדי לציין מתי המשתמש נמצא באפליקציה של פרופיל מנוהל.
• הצגת הודעה קופצת שמציינת שהמשתמש נמצא בפרופיל המנוהל אם והפעם שהמכשיר מתעורר (ACTION_USER_PRESENT) והאפליקציה שבחזית נמצאת בפרופיל המנוהל.
• אם קיים פרופיל מנוהל, מוצגת אפשרות חזותית ב'בורר' של הכוונה כדי לאפשר למשתמש להעביר את הכוונה מהפרופיל המנוהל למשתמש הראשי או להפך, אם האפשרות הזו מופעלת על ידי 'בקר מדיניות המכשיר'.
• כשיש פרופיל מנוהל, צריך לחשוף את האפשרויות הבאות למשתמשים, גם למשתמש הראשי וגם לפרופיל המנוהל:
  • ניהול נפרד של נתוני השימוש בסוללה, במיקום, בחבילת הגלישה ובאחסון של המשתמש הראשי והפרופיל המנוהל.
  • ניהול עצמאי של אפליקציות VPN שמותקנות בפרופיל המנוהל או בפרופיל הראשי של המשתמש.
  • ניהול עצמאי של אפליקציות שמותקנות בפרופיל הראשי או בפרופיל המנוהל.
  • ניהול עצמאי של חשבונות בתוך המשתמש הראשי או בפרופיל המנוהל.
• מוודאים שאפליקציות החיוג, אנשי הקשר וההודעות המותקנות מראש יכולות לחפש ולחפש מידע על מבצעי השיחות מהפרופיל המנוהל (אם יש כזה) לצד המידע מהפרופיל הראשי, אם הרשאת אמצעי הבקרה של מדיניות המכשיר מאפשרת זאת. כשאנשי קשר מהפרופיל המנוהל מוצגים ביומן השיחות המובנה, בממשק המשתמש במהלך שיחה, בהתראות על שיחות מתמשכות ועל שיחות שלא נענו, באפליקציות של אנשי קשר ובאפליקציות של הודעות, הם אמורים להיות מסומנים באותו תג שמשמש לסימון אפליקציות בפרופיל המנוהל.
• חייבים לוודא שהוא עומד בכל דרישות האבטחה שחלות על מכשיר שבו מופעלים כמה משתמשים (ראו קטע 9.5), גם אם הפרופיל המנוהל לא נספר כמשתמש נוסף בנוסף למשתמש הראשי.
• תמיכה באפשרות לציין מסך נעילה נפרד שעומד בדרישות הבאות כדי להעניק גישה לאפליקציות שפועלות בפרופיל מנוהל.
  • הטמעות במכשירים חייבות לפעול בהתאם לכוונה של DevicePolicyManager.ACTION_SET_NEW_PASSWORD ולהציג ממשק להגדרת פרטי כניסה נפרדים לנעילה של המסך עבור הפרופיל המנוהל.
  • פרטי הכניסה של מסך הנעילה בפרופיל המנוהל חייבים להשתמש באותם מנגנוני אחסון וניהול של פרטי הכניסה כמו בפרופיל ההורה, כפי שמתואר באתר של פרויקט Android Open Source.
  • מדיניות הסיסמאות של DPC חייבת לחול רק על פרטי הכניסה של מסך הנעילה של הפרופיל המנוהל, אלא אם נקרא למכונה DevicePolicyManager שמוחזרת על ידי getParentProfileInstance.

3.10. נגישות

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

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

• הטמעות של Android Automotive אמורות לספק הטמעה של מסגרת הנגישות של Android בהתאם להטמעה שמוגדרת כברירת מחדל ב-Android.
• הטמעות במכשירים (לא כולל Android Automotive) חייבות לספק הטמעה של מסגרת הנגישות של Android בהתאם להטמעה שמוגדרת כברירת מחדל ב-Android.
• הטמעות במכשירים (לא כולל Android Automotive) חייבות לתמוך בהטמעות של שירותי נגישות של צד שלישי באמצעות ממשקי ה-API של android.accessibilityservice.
• הטמעות במכשירים (לא כולל Android Automotive) חייבות ליצור אירועי AccessibilityEvents ולשלוח את האירועים האלה לכל הטמעות AccessibilityService הרשומים באופן שתואם להטמעה שמוגדרת כברירת מחדל ב-Android.

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

• מומלץ מאוד להטמיע במכשירי Android עם פלט אודיו שירותי נגישות במכשיר שתפקודתם דומה לזו של שירותי הנגישות TalkBack** ו'גישה באמצעות מתג' או שתפקודתם עולה עליה (https://github.com/google/talkback).

• במכשירי Android Watch עם פלט אודיו, צריכה להיות הטמעה של שירות נגישות במכשיר שתואם לפונקציונליות של שירות הנגישות TalkBack (https://github.com/google/talkback) או שפונקציונליות השירות הזה גבוהה יותר.
• הטמעות במכשירים אמורות לספק מנגנון בתהליך ההגדרה מחוץ לקופסה, שמאפשר למשתמשים להפעיל שירותי נגישות רלוונטיים, וגם אפשרויות לשינוי גודל הגופן, גודל המסך וביצוע תנועות הגדלה.

** בשפות שנתמכות בהמרת טקסט לדיבור.

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

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

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

הטמעות של 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.

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

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

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

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

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

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

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

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

3.12.1.2. ניווט

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

• שינוי ערוצי הטלוויזיה
• פתיחת EPG
• הגדרה של קלט מבוסס-TIF של צד שלישי והתאמה אישית שלו
• פתיחת תפריט ההגדרות

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

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

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

3.12.1.4. שינוי מועד השידור

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

3.12.1.5. הקלטת טלוויזיה

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

3.13. הגדרות מהירות

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

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

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

3.14. ממשקי API לממשק המשתמש של הרכב

3.14.1. ממשק המשתמש של המדיה ברכב

כל הטמעה של מכשיר שמצהירה על תמיכה ברכב חייבת לכלול מסגרת של ממשק משתמש כדי לתמוך באפליקציות צד שלישי שמשתמשות בממשקי ה-API MediaBrowser ו-MediaSession.

למסגרת ממשק המשתמש שתומכת באפליקציות צד שלישי שתלויות ב-MediaBrowser וב-MediaSession יש את הדרישות החזוניות הבאות:

• חובה להציג סמלי MediaItem וסמלי התראות ללא שינוי.
• חובה להציג את הפריטים האלה כפי שמתואר ב-MediaSession, למשל: מטא-נתונים, סמלים, תמונות.
• חובה להציג את שם האפליקציה.
• חובה לכלול מגירה להצגת היררכיית MediaBrowser.

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

הטמעות במכשירים חייבות להתקין ולהריץ קובצי Android‏ ‎.apk שנוצרו באמצעות הכלי ‎aapt שכלול ב-Android SDK הרשמי. לכן, בהטמעות של מכשירים צריך להשתמש במערכת ניהול החבילות של ההטמעה לדוגמה.

מנהל החבילות חייב לתמוך באימות של קבצים מסוג ‎".apk" באמצעות APK Signature Scheme v2 וחתימת JAR.

אסור להרחיב את הטמעות המכשירים בפורמטים של ‎.apk, Android Manifest, קוד בייט של Dalvik או קוד בייט של RenderScript באופן שימנע את ההתקנה וההפעלה הנכונות של הקבצים האלה במכשירים תואמים אחרים.

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

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

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

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

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

• חייב גם להיות מסוגל לפענח את כל הפרופילים שדווחו ב-CamcorderProfile

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

קודקים צריכים לשאוף לזמן אחזור מינימלי של קודק. במילים אחרות, קודקים –

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

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

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

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

פורמט/קודק	במקודד	מפענח	פרטים	סוגי קבצים/פורמטים של קובצי מאגר נתמכים
MPEG-4 AAC Profile (AAC LC)	חובה 1	חובה	תמיכה בתוכן 2 מונו/סטריאו/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+)	חובה 1 (Android 4.1 ואילך)	חובה	תמיכה בתוכן מונופוני/סטריאופוני/5.0/5.1 2 עם תדירויות דגימה רגילות של 16 עד 48kHz.
פרופיל MPEG-4 HE AACv2 (enhanced AAC+)		חובה	תמיכה בתוכן מונופוני/סטריאופוני/5.0/5.1 2 עם תדירויות דגימה רגילות של 16 עד 48kHz.
AAC ELD (AAC משופר עם זמן אחזור נמוך)	חובה 1 (Android 4.1 ואילך)	חובה (Android 4.1 ואילך)	תמיכה בתוכן מונו/סטריאו עם תדירויות דגימה רגילות של 16 עד 48kHz.
AMR-NB	חובה 3	חובה 3	4.75 עד 12.2kbps דגימה ב-8kHz	3GPP‏ (‎.3gp)
AMR-WB	חובה 3	חובה 3	9 שיעורי דגימה מ-6.60kbit/s עד 23.85kbit/s, בתדירות דגימה של 16kHz
FLAC		חובה (Android 3.1 ואילך)	מונו/סטריאו (ללא ערוצים מרובים). תדירויות דגימה של עד 48kHz (אבל מומלץ להשתמש בתדירויות של עד 44.1kHz במכשירים עם פלט של 44.1kHz, כי המכשיר להקטנת תדירות הדגימה מ-48kHz ל-44.1kHz לא כולל מסנן מסנן תדר נמוך). מומלץ 16 ביט. לא חל רעש דיגיטלי (dither) על 24 ביט.	FLAC‏ (‎.flac) בלבד
MP3		חובה	מונו/סטריאו 8-320Kbps קבוע (CBR) או קצב העברת נתונים משתנה (VBR)	MP3‏ (‎.mp3)
MIDI		חובה	MIDI מסוג 0 ו-1. DLS גרסה 1 ו-2. XMF ו-Mobile XMF. תמיכה בפורמטים של רינגטונים RTTTL/RTX,‏ OTA ו-iMelody	סוג 0 ו-1 (‎.mid,‏ ‎.xmf,‏ ‎.mxmf) RTTTL/RTX‏ (‎.rtttl, ‎.rtx) OTA‏ (‎.ota) iMelody‏ (‎.imy)
Vorbis		חובה		Ogg‏ (‎.ogg) Matroska‏ (‎.mkv, Android 4.0 ואילך)
PCM/WAVE	חובה 4 (Android 4.1 ואילך)	חובה	PCM לינאריים של 16 ביט (שיעורים עד למגבלת החומרה). המכשירים חייבים לתמוך בתדירויות דגימה של הקלטת PCM גולמי בתדרים של 8000,‏ 11025,‏ 16000 ו-44100Hz.	WAVE‏ (‎.wav)
Opus		חובה (Android 5.0 ואילך)		Matroska‏ (‎.mkv), ‏ Ogg‏ (‎.ogg)

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

2 ההקלטה או ההפעלה יכולות להתבצע במונו או בסטריאו, אבל פענוח מאגרי הקלט של AAC של שידורים מרובי-ערוצים (כלומר יותר משני ערוצים) ל-PCM באמצעות מפענח האודיו AAC שמוגדר כברירת מחדל ב-android.media.MediaCodec API, חייב לכלול את התכונות הבאות:

• פענוח מתבצע ללא ערבוב למטה (למשל, סטרימינג AAC 5.0 צריך לעבור פענוח לחמישה ערוצים של PCM, וסטרימינג AAC 5.1 צריך לעבור פענוח לשישה ערוצים של PCM).
• מטא-נתונים של טווח דינמי, כפי שמוגדר ב-'Dynamic Range Control (DRC)' ב-ISO/IEC 14496-3, ומפתחות ה-DRC של android.media.MediaFormat כדי להגדיר את ההתנהגויות שקשורות לטווח הדינמי של מקודד האודיו. מפתחות ה-AAC DRC הוצגו ב-API 21,והם: KEY_AAC_DRC_ATTENUATION_FACTOR, ‏ KEY_AAC_DRC_BOOST_FACTOR, ‏ KEY_AAC_DRC_HEAVY_COMPRESSION, ‏ KEY_AAC_DRC_TARGET_REFERENCE_LEVEL ו-KEY_AAC_ENCODED_TARGET_LEVEL.

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)
גולמי		חובה		ARW‏ (‎.arw), ‏ CR2‏ (‎.cr2), ‏ DNG‏ (‎.dng), ‏ NEF‏ (‎.nef), ‏ NRW‏ (‎.nrw), ‏ ORF‏ (‎.orf), ‏ PEF‏ (‎.pef), ‏ RAF‏ (‎.raf), ‏ RW2‏ (‎.rw2), ‏ SRW‏ (‎.srw)

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

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

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

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

• מקודדי וידאו ומפענחי וידאו חייבים לתמוך בפורמט צבע גמיש YUV420‏ (COLOR_FormatYUV420Flexible).

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

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

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

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

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

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

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

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

מקודדי וידאו מסוג H.264, ‏ VP8, ‏ VP9 ו-HEVC –

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

קודק הווידאו H.263 ו-MPEG-4 צריך לתמוך בקצב סיביות שניתן להגדיר באופן דינמי.

כל מקודדי הווידאו צריכים לעמוד ביעדים הבאים של קצב נתונים (bitrate) בשני חלונות הזזה:

• הערך צריך להיות גבוה ב-15% לכל היותר מקצב העברת הנתונים בין מרווחי הזמן של פריימים פנימיים (פרימי I).
• הוא לא אמור לחרוג מ-100% בערך מעל קצב הנתונים בחלון הזזה של שנייה אחת.

5.2.1. H.263

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

5.2.2. H-264

הטמעות במכשירי Android עם תמיכה בקודק H.264:

• חובה לתמוך בפרופיל Baseline ברמה 3.
  עם זאת, התמיכה ב-ASO‏ (Arbitrary Slice Ordering), ב-FMO‏ (Flexible Macroblock Ordering) וב-RS‏ (Redundant Slices) היא אופציונלית. בנוסף, כדי לשמור על תאימות למכשירי Android אחרים, מומלץ שלא להשתמש ב-ASO, ב-FMO וב-RS לפרופיל הבסיסי על ידי מקודדים.
• חובה לתמוך בפרופילים של קידוד וידאו באיכות SD (רזולוציה רגילה) שמפורטים בטבלה הבאה.
• צריכה להיות תמיכה ברמת 4 בפרופיל הראשי.
• צריך לתמוך בפרופילים של קידוד וידאו באיכות HD (High Definition) כפי שמצוין בטבלה הבאה.
• בנוסף, מומלץ מאוד להשתמש בקידוד של וידאו באיכות HD 1080p בקצב של 30fps במכשירי Android Television.

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

5.2.3. VP8

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

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

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

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

• הטמעות שתומכות במפענח Dolby Vision –

• חובה לספק חילוץ (extractor) שתומך ב-Dolby Vision.

• חייב להציג תוכן Dolby Vision כראוי במסך המכשיר או ביציאת וידאו רגילה (למשל, HDMI).

• בהטמעות שמספקות חילוץ תואם ל-Dolby Vision, חובה להגדיר את מדד הטראק של שכבות הבסיס התואמות לאחור (אם קיימות) כך שיהיה זהה למדד הטראק של השכבה המשולבת של Dolby Vision.

5.3.1. MPEG-2

הטמעות של מכשירי Android עם מקודדים של MPEG-2 חייבות לתמוך ברמה Main Profile High.

5.3.2. H.263

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

5.3.3. MPEG-4

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

5.3.4. H.264

הטמעות במכשירי Android עם מקודדים של H.264:

• חובה לתמוך בפרופיל הראשי ברמה 3.1 ובפרופיל Baseline.
  התמיכה ב-ASO‏ (סידור שרירותי של פרוסות), ב-FMO‏ (סידור גמיש של מק"טים) וב-RS‏ (פרוסות יתירות) היא אופציונלית.
• חייב להיות מסוגל לפענח סרטונים עם פרופילים של SD (רזולוציה רגילה) שמפורטים בטבלה הבאה, שקודדו באמצעות פרופיל Baseline ופרופיל Main ברמה 3.1 (כולל 720p30).
• צריכה להיות מסוגלת לפענח סרטונים עם פרופילי HD (רזולוציה גבוהה) כפי שמצוין בטבלה הבאה.
• בנוסף, מכשירי Android Television –
  • חובה לתמוך ברמה 4.2 של High Profile ובפרופיל הפענוח HD 1080p60.
  • חייב להיות מסוגל לפענח סרטונים עם שני הפרופילים של HD כפי שמצוין בטבלה הבאה, וקודדים באמצעות פרופיל הבסיס, פרופיל הראשי או פרופיל ברמה גבוהה 4.2

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

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

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

5.3.5. H.265 (‏HEVC)

הטמעות של מכשירי Android, כשיש תמיכה בקודק H.265 כפי שמתואר בסעיף 5.1.3:

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

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

1 נדרש להטמעות של מכשירי Android Television עם פענוח חומרה של H.265.

5.3.6. VP8

הטמעות במכשירי Android, כשהן תומכות בקודק VP8 כפי שמתואר בקטע 5.1.3:

• חובה לתמוך בפרופילים של פענוח SD שמפורטים בטבלה הבאה.
• צריכה להיות תמיכה בפרופילים של פענוח HD שמפורטים בטבלה הבאה.
• מכשירי Android Television חייבים לתמוך בפרופיל הפענוח HD 1080p60.

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

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

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

5.3.7. VP9

הטמעות במכשירי Android, כשהן תומכות בקודק VP9 כפי שמתואר בקטע 5.1.3:

• חייבים לתמוך בפרופילים של פענוח וידאו SD כפי שמצוין בטבלה הבאה.
• צריך לתמוך בפרופילים של פענוח HD כפי שמצוין בטבלה הבאה.
• חובה לתמוך בפרופילים של פענוח HD כפי שמצוין בטבלה הבאה, אם יש ממיר חומרה.

• בנוסף, במכשירי Android Television:

  • חובה לתמוך בפרופיל הפענוח של HD 720p.
  • מומלץ מאוד לתמוך בפרופיל הפענוח של 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)	30 פריימים לשנייה (60 פריימים לשנייה 1 )	60 fps
קצב העברת נתונים של וידאו	600 Kbps	1.6 Mbps	4Mbps	‎5 Mbps	‎20 Mbps

1 נדרש להטמעות של מכשירי Android Television עם פענוח חומרה של VP9.

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

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

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

• המכשיר אמור להציג מאפייני אמפליטודה שטוחיים יחסית לעומת תדירות: באופן ספציפי, ±3 dB, מ-100Hz עד 4000Hz.
• יש להגדיר את רגישות הקלט של האודיו כך שמקור של רמת הספק קול (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, כך שכאשר אפליקציה משתמשת ב-API android.media.AudioRecord כדי להקליט ממקור האודיו הזה, היא יכולה לתעד תערובת של כל שידורי האודיו, מלבד:

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

הטמעות של מכשירי Android Automotive אמורות לאפשר לשנות את עוצמת הקול בנפרד לכל סטרימינג אודיו לפי סוג התוכן או השימוש, כפי שהוגדר ב-AudioAttributes ושימוש באודיו ברכב כפי שהוגדר באופן ציבורי ב-android.car.CarAudioManager .

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

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

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

• זמן אחזור של הפלט . מרווח הזמן בין הזמן שבו אפליקציה כותבת פריים של נתונים בקידוד PCM לבין הזמן שבו הצליל התואם מוצג לסביבה במתמר במכשיר, או שהאות יוצא מהמכשיר דרך יציאה וניתן לצפות בו באופן חיצוני.
• זמן האחזור של הפלט במצב קר . זמן האחזור של הפלט לפריים הראשון, כשמערכת הפלט של האודיו הייתה במצב חוסר פעילות ומושבתת לפני הבקשה.
• זמן אחזור רציף של פלט . זמן האחזור של הפלט לפריימים הבאים, אחרי שהמכשיר מפעיל אודיו.
• זמן אחזור של קלט . מרווח הזמן בין המועד שבו צליל מוצג על ידי הסביבה למכשיר בטרנסדוסר במכשיר או שהאות נכנס למכשיר דרך יציאה, לבין המועד שבו אפליקציה קוראת את המסגרת התואמת של נתונים בקידוד PCM.
• קלט אבד . החלק הראשוני של אות קלט שלא ניתן להשתמש בו או שהוא לא זמין.
• זמן אחזור של קלט במצב קר . הסכום של זמן הקלט שהלך לאיבוד וזמן האחזור של הקלט לפריים הראשון, כשמערכת קלט האודיו הייתה במצב חוסר פעילות ומושבתת לפני הבקשה.
• זמן אחזור רציף של קלט . זמן האחזור של הקלט בפריימים הבאים, בזמן שהמכשיר מקליט אודיו.
• תנודות בזמן יצירת האות (jitter) במצב 'קר' . התנודתיות בין מדידות נפרדות של ערכי זמן האחזור של פלט במצב מנומנם.
• תנודות קלט בזמן הפעלה ראשונית . התנודתיות בין מדידות נפרדות של ערכי זמן האחזור של קלט במצב מנומנם.
• זמן אחזור רציף הלוך ושוב . הסכום של זמן האחזור הרציף של הקלט, זמן האחזור הרציף של הפלט ותקופת מאגר אחת. תקופת האחסון הזמני מאפשרת לאפליקציה לעבד את האות ולצמצם את ההפרש בפאזה בין מקורות הקלט והפלט.
• OpenSL ES PCM buffer queue API . קבוצת ממשקי ה-API של OpenSL ES שקשורים ל-PCM ב-Android NDK.

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

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

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

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

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

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

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

• סטרימינג פרוגרסיבי ב-HTTP(S)
  חובה לתמוך בכל הקודקים ובכל הפורמטים הנדרשים של קונטיינרים שמפורטים בקטע 5.1 דרך HTTP(S)

• טיוטת פרוטוקול HTTP Live Streaming, גרסה 7
  חובה לתמוך בפורמטים הבאים של קטעי מדיה:

פורמטים של פלחים	מקורות מידע	תמיכה בקודקים הנדרשים
MPEG-2 Transport Stream	ISO 13818	קודיקים של וידאו: H264 AVC MPEG-4 SP MPEG-2 בקטע 5.1.3 מפורט מידע על H264 AVC,‏ MPEG2-4 SP ו-MPEG-2. קודיקים של אודיו: קובץ AAC פרטים על AAC ועל הווריאציות שלו מופיעים בקטע 5.1.1.
AAC עם מסגרת ADTS ותגי ID3	ISO 13818-7	פרטים על AAC ועל הווריאציות שלו מופיעים בקטע 5.1.1.
WebVTT	WebVTT

• RTSP‏ (RTP, ‏ SDP)

  חובה לתמוך בפרופיל הווידאו והאודיו הבא של RTP ובקודקים הקשורים. החרגות מפורטות בהערות השוליים בטבלה שמפורטת בקטע 5.1.

השם בפרופיל	מקורות מידע	תמיכה בקודקים הנדרשים
H264 AVC	RFC 6184	פרטים על H264 AVC מופיעים בקטע 5.1.3
MP4A-LATM	RFC 6416	פרטים על AAC ועל הווריאציות שלו מופיעים בקטע 5.1.1.
H263-1998	RFC 3551 RFC 4629 RFC 2190	פרטים על H263 מופיעים בקטע 5.1.3
H263-2000	RFC 4629	פרטים על H263 מופיעים בקטע 5.1.3
AMR	RFC 4867	פרטים על AMR-NB מופיעים בקטע 5.1.1
AMR-WB	RFC 4867	פרטים על AMR-WB מופיעים בקטע 5.1.1
MP4V-ES	RFC 6416	פרטים על MPEG-4 SP זמינים בקטע 5.1.3
mpeg4-generic	RFC 3640	פרטים על AAC ועל הווריאציות שלו מופיעים בקטע 5.1.1.
MP2T	RFC 2250	פרטים נוספים זמינים בקטע MPEG-2 Transport Stream בקטע 'סטרימינג בשידור חי ב-HTTP'.

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 בקוד פתוח ב-upstream כוללת תמיכה במסכים אלחוטיים (Miracast) ומחוברים (HDMI) שעומדים בדרישות האלה.

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

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

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

• מצב מארח USB (קטע 7.7 USB)
• מצב ציוד היקפי בחיבור USB (קטע 7.7 USB)
• MIDI ב-Bluetooth LE בתפקיד מרכזי (קטע 7.4.3 Bluetooth)

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

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

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

• ההטמעה במכשיר חייבת לדווח על תמיכה בתכונה 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 מוליכים, מומלץ מאוד שההטמעה של המכשיר תהיה תואמת לקטע מפרטים של מכשיר נייד (שקע) במפרט של אוזניות אודיו חוטיות (v1.1).

חובה לעמוד בזמני האחזור ובדרישות האודיו של USB באמצעות ה-API של תור מאגר ה-PCM ב-OpenSL ES.

בנוסף, הטמעה של מכשיר שמדווחת על תמיכה בתכונה הזו צריכה:

• לספק רמה יציבה של ביצועי מעבד בזמן שהאודיו פעיל.
• צמצום אי-הדיוק והסטייה של שעון האודיו ביחס לשעון הרגיל.
• צמצום ההבדל בין שעון האודיו לבין המעבד (CPU) CLOCK_MONOTONIC כששניהם פעילים.
• צמצום זמן האחזור של האודיו באמצעות מתמרים במכשיר.
• צמצום זמן האחזור של האודיו דרך אודיו דיגיטלי ב-USB.
• מתעדים את מדידות זמן האחזור של האודיו בכל המסלולים.
• כדאי למזער את התנודות בזמני הכניסה של קריאה חוזרת (Callback) להשלמת מאגר אודיו, כי הן משפיעות על האחוז הזמין של רוחב הפס המלא של המעבד (CPU) בקריאה החוזרת.
• אין חריגות של זמן אחזור (latency) בזמן שימוש רגיל, למשל חריגות של זמן אחזור קצר מדי (פלט) או ארוך מדי (קלט).
• לספק אפס הבדל בזמן האחזור בין הערוצים.
• צמצום זמן האחזור הממוצע של MIDI בכל אמצעי התעבורה.
• צמצום התנודות בזמן האחזור של MIDI במהלך עומס (Jitter) בכל אמצעי התעבורה.
• לספק חותמות זמן מדויקות של MIDI בכל אמצעי התעבורה.
• צמצום הרעש של אותות האודיו במכשירים, כולל בתקופה שלאחר ההפעלה במצב התחלתי.
• לספק אפס הבדל בשעון האודיו בין הצדדים של הקלט והפלט של נקודות הקצה התואמות, כששניהם פעילים. דוגמאות לנקודות קצה תואמות הן המיקרופון והרמקול במכשיר, או הקלט והפלט של שקע האודיו.
• טיפול בקריאות חזרה (callbacks) להשלמת מאגר אודיו בצד הקלט ובצד הפלט של נקודות הקצה התואמות באותו חוט כששתיהן פעילות, והכניסה לקריאת החזרה (callback) של הפלט מיד אחרי החזרה מקריאת החזרה (callback) של הקלט. לחלופין, אם לא ניתן לטפל בקריאות החזרה באותו חוט, צריך להיכנס לקריאת החזרה של הפלט זמן קצר אחרי שמזינים את קריאת החזרה של הקלט, כדי לאפשר לאפליקציה תזמון עקבי של צידי הקלט והפלט.
• צמצום ההפרש בפאזה בין האחסון במטמון של אודיו ב-HAL בצד הקלט ובצד הפלט של נקודות הקצה התואמות.
• צמצום זמן האחזור של המגע.
• צמצום התנודות בזמן האחזור למגע במהלך עומס (Jitter).

5.11. צילום ללא עיבוד

החל מגרסה 7.0 של Android, נוסף מקור הקלטה חדש. אפשר לגשת אליו באמצעות מקור האודיו android.media.MediaRecorder.AudioSource.UNPROCESSED. ב-OpenSL ES, אפשר לגשת אליו באמצעות ההגדרה המוגדרת מראש להקלטה SL_ANDROID_RECORDING_PRESET_UNPROCESSED .

כדי לדווח על תמיכה במקור האודיו הלא מעובד באמצעות המאפיין android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED, המכשיר חייב לעמוד בכל הדרישות הבאות:

• המכשיר חייב להציג מאפייני אמפליטודה לעומת תדר שטוחים בטווח התדרים הבינוני: באופן ספציפי, ±10dB מ-100Hz עד 7,000Hz.

• המכשיר חייב להציג רמות אמפליטודה בטווח התדרים הנמוך: באופן ספציפי, מ-±20dB מ-5Hz עד 100Hz בהשוואה לטווח התדרים הבינוני.

• המכשיר חייב להציג רמות אמפליטודה בטווח התדרים הגבוהים: באופן ספציפי, מ-±30dB מ-7,000Hz עד 22KHz בהשוואה לטווח התדרים הבינוני.

• חובה להגדיר את רגישות הקלט של האודיו כך שמקור של צליל סינוסואידלי של 1,000Hz שיופעל ברמת לחץ קול (SPL) של 94dB יניב תגובה עם RMS של 520 לדגימות של 16 ביט (או -36dB Full Scale לדגימות של נקודת צפה/דיוק כפול).

• SNR > 60 dB (ההבדל בין 94 dB SPL לבין SPL שווה ערך של רעש עצמי, משוקלל A).

• העיוות ההרמוני הכולל חייב להיות קטן מ-1% עבור 1kHz ברמת קלט של 90dB SPL במיקרופון.

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

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

כל מדידות ה-SPL מתבצעות ישירות ליד המיקרופון שנבדק.

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

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

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

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

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

• ממשק הגישור של Android‏ (adb)
  • הטמעות במכשירים חייבות לתמוך בכל הפונקציות של adb כפי שמתואר ב-Android SDK, כולל dumpsys.
  • הדימון adb בצד המכשיר חייב להיות לא פעיל כברירת מחדל, וחייבת להיות מנגנון שזמין למשתמשים כדי להפעיל את Android Debug Bridge. אם הטמעת המכשיר שוללת את מצב ההתקן ההיקפי של USB, חובה להטמיע את Android Debug Bridge דרך רשת מקומית (כמו Ethernet או 802.11).
  • Android כולל תמיכה ב-adb מאובטח. Secure adb מאפשר להשתמש ב-adb במארחים מוכרים ומאומתים. הטמעות במכשירים חייבות לתמוך ב-adb מאובטח.
• Dalvik Debug Monitor Service‏ (ddms)
  • הטמעות במכשירים חייבות לתמוך בכל התכונות של DDMS כפי שמתואר ב-Android SDK.
  • מכיוון ש-ddms משתמש ב-adb, התמיכה ב-ddms אמורה להיות לא פעילה כברירת מחדל, אבל חובה שתהיה תמיכה בכל פעם שהמשתמש הפעיל את Android Debug Bridge, כפי שמתואר למעלה.
• הטמעות של Monkey במכשירים חייבות לכלול את מסגרת Monkey ולהפוך אותה לזמינה לשימוש באפליקציות.
• SysTrace
  • הטמעות במכשירים חייבות לתמוך בכלי 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 יש תמיכה למפתחים שמאפשרת להם להגדיר הגדרות שקשורות לפיתוח אפליקציות. הטמעות במכשירים חייבות לפעול בהתאם לכוונה של android.settings.APPLICATION_DEVELOPMENT_SETTINGS כדי להציג הגדרות שקשורות לפיתוח אפליקציות. הטמעת 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.

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

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

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

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

7.1.1. הגדרת מסך

7.1.1.1. גודל מסך

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

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

בנוסף:

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

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

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

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

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

• אם uiMode מוגדר כ-UI_MODE_TYPE_WATCH, הערך של יחס הגובה-רוחב יכול להיות מוגדר כ-1.0‏ (1:1).
• אם אפליקציית הצד השלישי מציינת שאפשר לשנות את הגודל שלה באמצעות המאפיין android:resizeableActivity, אין הגבלות על ערך יחס הגובה-רוחב.
• בכל שאר המקרים, יחס הגובה-רוחב חייב להיות ערך בין 1.3333 (4:3) ל-1.86 (כ-16:9), אלא אם האפליקציה ציינה במפורש שהיא תומכת ביחס גובה-רוחב גבוה יותר של המסך באמצעות ערך המטא-נתונים maxAspectRatio.

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

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

• אסור לשנות את גודל המסך ליותר מפי 1.5 מהצפיפות המקורית, או ליצור מימד מסך מינימלי יעיל קטן מ-320dp (שווה ערך למאפיין המשאב sw320dp), לפי התנאי שמתרחש קודם.
• אסור לשנות את גודל התצוגה לגודל קטן יותר מ-0.85 פי הצפיפות המקורית.
• כדי להבטיח נוחות שימוש וגדלים עקביים של גופנים, מומלץ לספק את האפשרויות הבאות של שינוי קנה המידה של תצוגה מקורית (תוך ציות למגבלות שצוינו למעלה)
• קטן: 0.85x
• ברירת מחדל: 1x (קנה מידה של תצוגה מקורית)
• גדולה: 1.15x
• גדול יותר: 1.3x
• הגדול ביותר 1.45x

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

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

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

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

• ממשקי ה-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 או 3.2 חייבות לתמוך בממשקי ה-API המנוהלים התואמים ולכלול תמיכה בממשקי API מקומיים של C/C++. בהטמעות במכשירים שמצהירות על תמיכה ב-OpenGL ES 3.0, ‏ 3.1 או 3.2, קובץ libGLESv2.so חייב לייצא את סמלי הפונקציות התואמים בנוסף לסמלי הפונקציות של OpenGL ES 2.0.

Android מספק חבילת תוספים של OpenGL ES עם ממשקי Java ותמיכה מקורית בפונקציונליות גרפית מתקדמת, כמו טיסרציה ופורמט דחיסת הטקסטורות ASTC. הטמעות של מכשירי Android חייבות לתמוך בחבילת התוספים אם המכשיר תומך ב-OpenGL ES 3.2, ויכול להיות שתהיה תמיכה גם במקרים אחרים. אם יש תמיכה בחבילת התוספים במלואה, המכשיר חייב לזהות את התמיכה באמצעות דגל התכונה android.hardware.opengles.aep.

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

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

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

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

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

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

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

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

7.2. התקני קלט

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

7.2.1. מקלדת

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

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

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

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

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

7.2.3. מקשי ניווט

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

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

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

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

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

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

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

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

הטמעות של מכשירי Android שתומכות בפעולת Assist ו/או ב-VoiceInteractionService חייבות לאפשר להפעיל אפליקציית Assist באינטראקציה אחת (למשל, הקשה, לחיצה כפולה או תנועה) כשמקשי ניווט אחרים גלויים. מומלץ מאוד להשתמש בלחיצה ארוכה על לחצן הבית כאינטראקציה הזו. האינטראקציה הייעודית חייבת להפעיל את אפליקציית העזרה שבחר המשתמש, כלומר האפליקציה שמטמיעה את VoiceInteractionService, או פעילות שמטפלת בכוונה ה-ACTION_ASSIST.

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

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

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

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

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

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

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

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

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

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

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

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

1 KeyEvent

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

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

4 MotionEvent

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

אירוע MotionEvent אחד

7.2.7. שלט רחוק

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

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

7.3. חיישנים

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

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

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

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

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

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

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

7.3.1. מד תאוצה

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

• חובה להטמיע ולדווח על חיישן TYPE_ACCELEROMETER.
• חייב להיות אפשרות לדווח על אירועים בתדירות של 50Hz לפחות במכשירי Android Watch, כי למכשירים כאלה יש מגבלת צריכת חשמל מחמירה יותר, ועל 100Hz בכל שאר סוגי המכשירים.
• צריך לדווח על אירועים עד 200Hz לפחות.
• חייבים לעמוד בדרישות של מערכת הקואורדינטות של חיישן Android כפי שמפורט בממשקי ה-API של Android. הטמעות של Android Automotive חייבות לעמוד בדרישות של מערכת הקואורדינטות של חיישני הרכב של Android.
• חייב להיות מסוגל למדוד מירידה חופשית עד פי ארבעה מכוח הכבידה (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.
• חייב להיות מסוגל למדוד בין -900 µT ל-+900 µT בכל ציר לפני שהוא מגיע לרוויה.
• הערך של ההיסט של ברזל קשה חייב להיות קטן מ-700 µT, והערך שלו צריך להיות קטן מ-200 µT. לשם כך, צריך למקם את המגנטומטר הרחק משדות מגנטיים דינמיים (שנגרמים על ידי זרם) וסטטיים (שנגרמים על ידי מגנט).
• הרזולוציה חייבת להיות שווה ל-0.6 µT או צפופה יותר, ומומלץ שהרזולוציה תהיה שווה ל-0.2 µT או צפופה יותר.
• צריך לבצע פיצוי טמפרטורה.
• חובה לתמוך בכיול אונליין ובתיקון של הטיה של חומרה קשיחה, ולשמור את פרמטרי התיקון בין הפעלות מחדש של המכשיר.
• חובה להחיל את הפיצוי של ברזל רך – אפשר לבצע את ההתאמה בזמן השימוש או במהלך ייצור המכשיר.
• סטיית התקן, מחושבת על בסיס ציר על מדגמים שנאספו במשך תקופה של לפחות 3 שניות בקצב הדגימה המהיר ביותר, לא צריכה להיות גבוהה מ-0.5 µT.
• חובה להטמיע חיישן מורכב מסוג TYPE_ROTATION_VECTOR, אם כלול גם חיישן תאוצה וחיישן ג'ירוסקופ.
• מותר להטמיע את החיישן TYPE_GEOMAGNETIC_ROTATION_VECTOR אם מוטמע גם חיישן מד תאוצה. עם זאת, אם הוא מוטמע, צריך להיות לו צריכת אנרגיה של פחות מ-10mW, ורצוי שצריכת האנרגיה שלו תהיה פחות מ-3mW כשהחיישן רשום למצב באצ'ט ב-10Hz.

7.3.3. GPS

הטמעות במכשירים אמורות לכלול מקלט GPS/GNSS. אם הטמעת המכשיר כוללת מקלט GPS/GNSS ומדווחת על היכולת הזו לאפליקציות באמצעות דגל התכונה android.hardware.location.gps:

• מומלץ מאוד שהמכשיר ימשיך לספק לאפליקציות פלטים רגילים של GPS/GNSS במהלך שיחת טלפון למקרה חירום, ושפלט המיקום לא ייחסם במהלך שיחת טלפון למקרה חירום.
• הוא חייב לתמוך בפלט מיקום בקצב של לפחות 1Hz כשמבקשים אותו דרך LocationManager#requestLocationUpdate .
• המכשיר חייב להיות מסוגל לקבוע את המיקום בתנאים של שדה פתוח (אותות חזקים, נתיב רב משמעותי, HDOP < 2) תוך 10 שניות (זמן קצר לקבלת תיקון ראשון), כשהוא מחובר לחיבור אינטרנט במהירות נתונים של 0.5Mbps או יותר. בדרך כלל, הדרישה הזו מתקיימת באמצעות שימוש בשיטה כלשהי של GPS/GNSS מסייע או צפוי כדי למזער את זמן הנעילה של GPS/GNSS (נתוני העזרה כוללים זמן ייחוס, מיקום ייחוס ושעון/אפומריס של לוויין).
  • אחרי חישוב מיקום כזה, מומלץ מאוד שהמכשיר יוכל לקבוע את המיקום שלו, בשמיים פתוחים, תוך 10 שניות, כשבקשות המיקום מופעלות מחדש, עד שעה לאחר חישוב המיקום הראשוני, גם אם הבקשה הבאה נשלחת ללא חיבור נתונים ו/או אחרי מחזור הפעלה מחדש.
• בתנאים של שמים פתוחים אחרי שנקבע המיקום, במצב נייח או בתנועה עם תאוצה של פחות ממטר אחד לשנייה בריבוע:
  • המכשיר חייב להיות מסוגל לקבוע את המיקום בטווח של 20 מטר ואת המהירות בטווח של 0.5 מטר לשנייה, לפחות ב-95% מהמקרים.
  • חייב להיות מעקב בו-זמני אחרי לפחות 8 לוויינים מקבוצת לוויינים אחת, ודיווח עליהם באמצעות GnssStatus.Callback.
  • המכשיר אמור להיות מסוגל לעקוב בו-זמנית אחרי לפחות 24 לוויינים, מכמה קבוצות של לוויינים (למשל, GPS + לפחות אחד מ-Glonass,‏ Beidou,‏ Galileo).
• חובה לדווח על דור הטכנולוגיה של GNSS דרך ה-API לבדיקה 'getGnssYearOfHardware'.
• מומלץ מאוד לעמוד בכל הדרישות הבאות, וחובה לעמוד בהן אם דור הטכנולוגיה של GNSS מדווח כשנה '2016' ואילך.
  • חובה לדווח על מדידות GPS ברגע שהן מתקבלות, גם אם מיקום שמחושב מ-GPS/GNSS עדיין לא דווח.
  • חובה לדווח על טווחי פסאודו-GPS ועל שיעורי פסאודו-טווח, שבתנאי שדה פתוח אחרי שנקבע המיקום, במצב נייח או בתנועה עם פחות מ-0.2 מטר לשנייה בריבוע של תאוצה, מספיקים כדי לחשב מיקום בטווח של 20 מטר ומהירות בטווח של 0.2 מטר לשנייה, לפחות ב-95% מהמקרים.

שימו לב: חלק מדרישות ה-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 או פחות.
  • תדירות המדידה המקסימלית חייבת להיות 400 הרץ ומעלה.
  • רעש המדידה חייב להיות לא יותר מ-400 uG/√Hz.
  • חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון זמני של לפחות 3,000 אירועי חיישן.
  • צריכת החשמל של האצווה חייבת להיות לא יותר מ-3mW.
  • צריכה להיות יציבות של הטיה סטטית של רעש של פחות מ-15 μg √Hz ממערך נתונים סטטי של 24 שעות.
  • השינוי בסטייה לעומת הטמפרטורה צריך להיות ≤ +/- 1mg / °C.
  • יש להיות לקו ההתאמה הטובה ביותר סטייה לא לינארית של ≤ 0.5%, ושינויים ברגישות לעומת הטמפרטורה של ≤ 0.03%/°C.

• SENSOR_TYPE_GYROSCOPE

  • טווח המדידה חייב להיות לפחות -1,000 עד +1,000 דפיקות לשנייה.
  • חייבת להיות רזולוציית מדידה של לפחות 16 LSB/dps.
  • תדר המדידה המינימלי חייב להיות 12.5Hz או פחות.
  • תדירות המדידה המקסימלית חייבת להיות 400 הרץ ומעלה.
  • רעש המדידה חייב להיות קטן מ-0.014°/s/√Hz.
  • צריכה להיות יציבות של הטיה סטטית של פחות מ-0.0002°/s √Hz ממערך נתונים סטטי של 24 שעות.
  • השינוי בסטייה לעומת הטמפרטורה צריך להיות ≤ +/- 0.05 °/ s / °C.
  • השינוי ברגישות כתוצאה מטמפרטורה צריך להיות ≤ 0.02% / °C.
  • יש להיות קו בעל התאמה הטובה ביותר עם סטייה לא לינארית של ≤ 0.2%.
  • צפיפות הרעש צריכה להיות ≤ 0.007°/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.
• SENSOR_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, חיישן הגירוסקופ וחיישן המגנטומטר חייבת להיות בטווח של 2.5 אלפיות השנייה זו מזו.
• חותמות הזמן של אירועי חיישן הגירוסקופ חייבות להיות על אותה בסיס זמן כמו של מערכת המשנה של המצלמה, ובטווח שגיאה של אלפיית שנייה אחת.
• חיישנים באיכות גבוהה חייבים לספק דגימות לאפליקציות תוך 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.
• שיעור הקבלה השגוי חייב להיות לא יותר מ-0.002%.
• מומלץ מאוד שהשיעור של דחייה שגויה יהיה פחות מ-10%, כפי שנמדד במכשיר
• מומלץ מאוד שהזמן להצגת תגובה (latency) יהיה פחות משנייה אחת, נמדד מהרגע שבו נוגעים בחיישן טביעות האצבע ועד שהמסך נפתח, לאצבע אחת שמוגדרת.
• חובה להגביל את קצב הניסיונות למשך 30 שניות לפחות אחרי 5 ניסיונות כושלים לאימות באמצעות טביעת אצבע.
• חובה שתהיה הטמעה של מאגר מפתחות שמבוססת על חומרה, ושהתאמת טביעות האצבע תתבצע בסביבת מחשוב אמינה (TEE) או בשבב עם ערוץ מאובטח ל-TEE.
• חובה להצפין את כל נתוני טביעת האצבע המזהים ולאמת אותם באופן קריפטוגרפי, כך שלא ניתן יהיה לקבל אותם, לקרוא או לשנות אותם מחוץ לסביבת המחשוב המאובטחת (TEE), כפי שמתואר בהנחיות להטמעה באתר של Android Open Source Project.
• חובה למנוע הוספה של טביעת אצבע בלי ליצור קודם שרשרת אמון, על ידי כך שהמשתמש יאשר פרטי כניסה קיימים למכשיר או יוסיף פרטי כניסה חדשים למכשיר (קוד אימות/קו ביטול נעילה/סיסמה) שמאובטחים על ידי TEE. ההטמעה של Android Open Source Project מספקת את המנגנון במסגרת כדי לעשות זאת.
• אסור לאפשר לאפליקציות של צד שלישי להבדיל בין טביעות אצבע ספציפיות.
• חובה לפעול בהתאם לדגל DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
• כשמשדרגים מגרסה ישנה יותר מ-Android 6.0, חובה להעביר את נתוני טביעת האצבע באופן מאובטח כדי לעמוד בדרישות שלמעלה, או להסיר אותם.
• צריך להשתמש בסמל טביעת האצבע של Android שזמין בפרויקט הקוד הפתוח של Android.

7.3.11. חיישנים ל-Android Automotive בלבד

חיישנים ספציפיים לכלי רכב מוגדרים ב-android.car.CarSensorManager API .

7.3.11.1. הילוך נוכחי

הטמעות של Android Automotive אמורות לספק את ההילוך הנוכחי כ-SENSOR_TYPE_GEAR.

7.3.11.2. מצב יום/לילה

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

7.3.11.3. סטטוס הנהיגה

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

7.3.11.4. מהירות הגלגלים

הטמעות של Android Automotive חייבות לספק את מהירות הרכב שמוגדרת כ-SENSOR_TYPE_CAR_SPEED.

7.3.12. חיישן תנוחה

הטמעות במכשירים עשויות לתמוך בחיישן תנוחה עם 6 דרגות חופש. מומלץ להשתמש במכשירים ניידים עם Android שתומכים בחיישני האלה. אם הטמעת המכשיר תומכת בחיישן תנוחה עם 6 דרגות חופש, היא:

• חובה להטמיע את החיישן TYPE_POSE_6DOF ולדווח עליו.
• חייב להיות מדויק יותר מאשר וקטור הסיבוב בלבד.

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

7.4.1. טלפוניה

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

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

7.4.1.1. תאימות לחסימת מספרים

הטמעות של מכשירי Android Telephony חייבות לכלול תמיכה בחסימת מספרים, וגם:

• חובה להטמיע באופן מלא את BlockedNumberContract ואת ממשק ה-API התואם, כפי שמתואר במסמכי התיעוד של ה-SDK.
• חובה לחסום את כל השיחות וההודעות ממספר טלפון ב-'BlockedNumberProvider' בלי אינטראקציה עם אפליקציות. היוצא מן הכלל היחיד הוא כאשר החסימה של מספרים מבוטלת באופן זמני, כפי שמתואר במסמכי התיעוד של ה-SDK.
• אסור לכתוב לספק יומן השיחות של הפלטפורמה לגבי שיחה חסומה.
• אסור לכתוב לספק הטלפוניה לגבי הודעה חסומה.
• חובה להטמיע ממשק משתמש לניהול מספרים חסומים, שנפתח באמצעות הכוונה שמוחזרת על ידי השיטה TelecomManager.createManageBlockedNumbersIntent().
• אסור לאפשר למשתמשים משניים להציג או לערוך את המספרים החסומים במכשיר, כי פלטפורמת Android מניחה שלמשתמש הראשי יש שליטה מלאה על שירותי הטלפון, במופע יחיד, במכשיר. כל ממשק המשתמש שקשור לחסימה חייב להיות מוסתר למשתמשים משניים, ורשימת החסימה חייבת להישאר בתוקף.
• צריך להעביר את המספרים החסומים לספק כשמתבצע עדכון של המכשיר ל-Android 7.0.

7.4.2. IEEE 802.11‏ (Wi-Fi)

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

• חובה לדווח על הדגל של תכונת החומרה android.hardware.wifi.
• חובה להטמיע את multicast API כפי שמתואר במסמכי התיעוד של ה-SDK.
• חובה לתמוך ב-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. אם הטמעה של מכשיר כוללת תמיכה ב-Wi-Fi Direct, היא:

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

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

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

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

7.4.3. Bluetooth

הטמעות של מכשירים שתומכות בתכונה android.hardware.vr.high_performance חייבות לתמוך ב-Bluetooth 4.2 וב-Bluetooth LE Data Length Extension.

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

יש ליישם את Android Automotive כך שיתמוך בפרופיל גישה להודעה (MAP). בהטמעות של Android Automotive חייבת להיות תמיכה בפרופילים הבאים של Bluetooth:

• שיחות טלפון באמצעות פרופיל דיבורית (HFP).
• הפעלת מדיה באמצעות פרופיל להפצת אודיו (A2DP).
• שליטה בהפעלת מדיה באמצעות פרופיל שלט רחוק (AVRCP).
• שיתוף אנשי קשר באמצעות פרופיל הגישה לספר הטלפונים (PBAP).

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

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

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

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

• חובה לדווח על התכונה android.hardware.nfc באמצעות השיטה android.content.pm.PackageManager.hasSystemFeature()‎.
• חייבת להיות לה אפשרות לקרוא ולכתוב הודעות 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 דק.
  • חייבת להיות מסוגלת להעביר ולקבל נתונים באמצעות הפרוטוקולים והסטנדרטים הבאים של רשתות עמיתים לעמיתים:
    • ISO 18092
    • LLCP 1.2 (הוגדר על ידי NFC Forum)
    • SDP 1.0 (הוגדר על ידי NFC Forum)
    • פרוטוקול NDEF Push
    • SNEP 1.0 (הוגדר על ידי NFC Forum)
  • חובה לכלול תמיכה ב-Android Beam.
  • חובה להטמיע את שרת ברירת המחדל של SNEP. הודעות NDEF תקינות שהתקבלו על ידי שרת SNEP שמוגדר כברירת מחדל חייבות להישלח לאפליקציות באמצעות ה-intent android.nfc.ACTION_NDEF_DISCOVERED. השבתת Android Beam בהגדרות לא מורשית להשבית את השליחה של הודעת NDEF נכנסת.
  • חובה לפעול לפי הכוונה android.settings.NFCSHARING_SETTINGS כדי להציג את הגדרות שיתוף ה-NFC.
  • חובה להטמיע את שרת ה-NPP. הודעות שמתקבלות בשרת ה-NPP חייבות לעבור עיבוד באותו אופן שבו הן עוברות עיבוד בשרת ברירת המחדל של SNEP.
  • חובה להטמיע לקוח SNEP ולנסות לשלוח הודעות NDEF ב-P2P יוצאות לשרת 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, על ידי הטמעת המפרטים Connection Handover version 1.2 ו-Bluetooth Secure Simple Pairing Using NFC version 1.0 מ-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 (עבור NfcA ו/או NfcB) ותומך בחיבור של מזהה אפליקציה (AID), אז:

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

אם הטמעה של מכשיר כוללת שבב של בקר NFC שיכול לתמוך ב-HCE ל-NfcF, והיא מטמיעה את התכונה לאפליקציות של צד שלישי, אז:

• חובה לדווח על קבוע התכונה android.hardware.nfc.hcef.
• חובה להטמיע את ממשקי ה-API של NfcF Card Emulation כפי שהם מוגדרים ב-Android SDK.

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

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

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

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

אם הטמעת המכשיר לא כוללת חומרת NFC, אסור להצהיר על התכונה android.hardware.nfc מהשיטה android.content.pm.PackageManager.hasSystemFeature()‎, וצריך להטמיע את 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, אסור להפסיק את שליחת חבילות ה-unicast של IPv6 למכשיר, גם כשהמסך לא במצב פעיל. יכול להיות שחבילות IPv6 מרובות-כתובת יתירות, כמו מודעות חוזרות זהות של נתב, יוגבלו בקצב שלהן בחומרה או בקושחה אם הדבר נדרש כדי לחסוך באנרגיה. במקרים כאלה, הגבלת הקצב לא יכולה לגרום לכך שהמכשיר יאבד את הקישוריות ל-IPv6 בכל רשת שתואמת ל-IPv6 ומשתמשת בטווח חיים של RA של לפחות 180 שניות.

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

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

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

7.4.7. חסכונית בנתונים

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

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

• חובה לתמוך בכל ממשקי ה-API בכיתה ConnectivityManager כפי שמתואר במסמכי התיעוד של ה-SDK

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

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

• חובה להחזיר את הערך RESTRICT_BACKGROUND_STATUS_DISABLED עבור ConnectivityManager.getRestrictBackgroundStatus()

• אסור לשדר את ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED

• חייבת להיות פעילות שמטפלת ב-Intent‏ Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, אבל אפשר להטמיע אותה כפעולה ללא פעולה (no-op).

7.5. מצלמות

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

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

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

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

• חובה לדווח על דגל התכונה android.hardware.camera ו-android.hardware.camera.any.
• חייבת להיות להם רזולוציה של לפחות 2 מגה-פיקסלים.
• צריך להטמיע בחיישן המצלמה מיקוד אוטומטי בחומרה או מיקוד אוטומטי בתוכנה (שקוף לתוכנת האפליקציה).
• יכול להיות שיש בהם חומרה עם מיקוד קבוע או חומרה עם עומק שדה מורחב (EDOF).
• יכול להיות שיכלול הבזק. אם המצלמה כוללת פלאש, אסור למנורת פלאש חשוב לציין שהאילוץ הזה לא חל על אפליקציית המצלמה המובנית של המכשיר, אלא רק על אפליקציות צד שלישי שמשתמשות ב-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) באופן אופקי ביחס לכיוון הנוכחי של המכשיר.
  • אם האפליקציה הנוכחית ביקשה במפורש שמסך המצלמה יתהפך באמצעות קריאה לשיטה android.hardware.Camera.setDisplayOrientation()‎, חובה לשקף את התצוגה המקדימה של המצלמה באופן אופקי ביחס לכיוון שצוין באפליקציה.
  • אחרת, התצוגה המקדימה חייבת להיות מוחזרת על ציר האופק של המכשיר שמוגדר כברירת מחדל.
• חייבת לשקף את התמונה שמוצגת על ידי התצוגה המקדימה באותו אופן שבו מוצג זרם התמונות של התצוגה המקדימה במצלמה. אם הטמעת המכשיר לא תומכת ב-postview, ברור שהדרישה הזו לא רלוונטית.
• אסור לשקף את התמונות הסטטיות או את הסטרימינג של הסרטונים הסופיים שצולמו, שמוחזרים לקריאות חזרה (callbacks) של האפליקציה או מועברים לאחסון מדיה.

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

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

• חובה להצהיר על דגל התכונה של הפלטפורמה android.hardware.camera.external ו-android.hardware camera.any .
• יכול להיות שתהיה תמיכה במספר מצלמות.
• חובה לתמוך ב-USB Video Class‏ (UVC 1.0 ואילך) אם המצלמה החיצונית מחוברת דרך יציאת ה-USB.
• צריך לתמוך בדחיסת וידאו כמו 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, גם אם המכשיר כולל פוקוס אוטומטי בחומרה או יכולות אחרות. לדוגמה, מצלמות ללא פוקוס אוטומטי עדיין חייבות לקרוא לכל המופעים הרשומים של android.hardware.Camera.AutoFocusCallback (למרות שאין לכך רלוונטיות למצלמה ללא פוקוס אוטומטי). שימו לב שההנחה הזו רלוונטית גם למצלמות קדמיות. לדוגמה, למרות שרוב המצלמות הקדמיות לא תומכות בפוקוס אוטומטי, עדיין צריך 'לזייף' את קריאות החזרה (callbacks) של ה-API כפי שמתואר.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

לחלופין, הטמעות של מכשירים יכולות להקצות אחסון פנימי (לא ניתן להסרה) כאחסון משותף לאפליקציות, כפי שמפורט ב-Android Open Source Project (פרויקט קוד פתוח של Android). מומלץ להשתמש בהגדרה הזו ובהטמעת התוכנה הזו בהטמעות של מכשירים. אם הטמעה של מכשיר משתמשת באחסון פנימי (לא ניתן להסרה) כדי לעמוד בדרישות לגבי אחסון משותף, והאחסון הזה עשוי לשתף מקום עם הנתונים הפרטיים של האפליקציה, הוא חייב להיות בנפח של לפחות 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.
• צריך לדווח על סוג מכשיר USB של 0x00.
• צריך לדווח על שם ממשק USB של 'MTP'.

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

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

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

7.7. USB

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

7.7.1. מצב ציוד היקפי ב-USB

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

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

7.7.2. מצב מארח USB

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

• צריך להשתמש ביציאת USB מסוג C, אם הטמעת המכשיר תומכת ב-USB 3.1.
• מותר להשתמש בפורמט יציאה לא סטנדרטי, אבל אם כן, חובה לשלוח את המכשיר עם כבל או כבלים שמתאימים את היציאה ליציאת USB רגילה מסוג A או מסוג C.
• מותר להשתמש ביציאת USB מסוג micro-AB, אבל אם כן, צריך לשלוח את המכשיר עם כבל או כבלים שמתאימים את היציאה ליציאת USB רגילה מסוג A או C.
• מומלץ מאוד להטמיע את הקלאס של אודיו USB כפי שמתואר במסמכי התיעוד של Android SDK.
• חובה להטמיע את Android USB host API כפי שמתואר ב-Android SDK, וחובה להצהיר על תמיכה בתכונת החומרה android.hardware.usb.host.
• צריך לתמוך בטעינה של המכשיר במצב מארח, לפרסם זרם מקור של לפחות 1.5A כפי שמפורט בקטע 'פרמטרים של סיום' במפרט [USB Type-C Cable and Connector Specification Revision 1.2] (http://www.usb.org/developers/docs/usb_31_021517.zip) למחברים מסוג USB Type-C, או להשתמש בטווח זרם הפלט של יציאת טעינה במורד הזרם(CDP) כפי שמפורט במפרטים של טעינה של סוללות USB, גרסה 1.2 למחברים מסוג Micro-AB.
• מומלץ מאוד שמכשירי USB Type-C יתמכו ב-DisplayPort, שיהיו תומכים בקצב העברת נתונים של USB SuperSpeed, ומומלץ מאוד שתהיה להם תמיכה ב-Power Delivery להחלפת תפקידים של נתונים וחשמל.
• אסור לשלוח מכשירי USB עם יציאות מסוג A או AB עם מתאם שממיר את היציאה הזו לשקע מסוג C.
• חובה לזהות כל מכשיר MTP (פרוטוקול העברת מדיה) שמחובר מרחוק , ולאפשר גישה לתוכן שלו באמצעות הכוונות ACTION_GET_CONTENT‏ , ACTION_OPEN_DOCUMENT ו-ACTION_CREATE_DOCUMENT, אם יש תמיכה ב-Storage Access Framework‏ (SAF).
• חובה, אם משתמשים ביציאת USB מסוג Type-C וכוללים תמיכה במצב ציוד היקפי, להטמיע את הפונקציונליות של יציאה עם תפקיד כפול כפי שמוגדרת במפרט USB Type-C (קטע 4.5.1.3.3).
• אם יש תמיכה בפונקציות של יציאה עם תפקיד כפול, צריך להטמיע את המודל Try.* שמתאים ביותר לפורמט המכשיר. לדוגמה, במכשיר נייד צריך להטמיע את המודל Try.SNK.

7.8. אודיו

7.8.1. מיקרופון

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

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

7.8.2. יעד השמע

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

• חובה לדווח על קבוע התכונה 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, אם הטמעת המכשיר כוללת שקע אודיו אנלוגי אחד או יותר, לפחות אחד משקעי האודיו צריך להיות שקע אודיו בגודל 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', מקורות האודיו VOICE_RECOGNITION ו-UNPROCESSED צריכים לעמוד בדרישות הבאות:
  • תגובת הכוח הממוצעת של המיקרופון בתחום התדרים 18.5kHz עד 20kHz חייבת להיות נמוכה ב-15dB לכל היותר מהתגובה בתדר 2kHz.
  • יחס האות לרעש ללא משקל של המיקרופון בטווח של 18.5kHz עד 20kHz עבור צליל של 19kHz ב-26dBFS חייב להיות לפחות 50dB.
• אם הערך של PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND הוא 'true', תגובת הממוצע של הרמקול בתחום התדרים 18.5kHz עד 20kHz חייבת להיות גבוהה מ-40dB מתחת לתגובה בתדר 2kHz.

7.9. מציאות מדומה

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

7.9.1. מצב מציאות מדומה

הטמעות של מכשירי Android ניידים שתומכות במצב לאפליקציות VR שמטפלות ברינדור סטריאוסקופי של התראות ומשביתות רכיבי ממשק משתמש מונוכולי של המערכת בזמן שאפליקציית VR נמצאת במוקד המשתמש חייבות להצהיר על התכונה android.software.vr.mode. במכשירים שמצהירים על התכונה הזו חייבת להיות אפליקציה שמטמיעה את android.service.vr.VrListenerService, שאפשר להפעיל אותה באמצעות אפליקציות VR דרך android.app.Activity#setVrModeEnabled .

7.9.2. מציאות מדומה עתיר ביצועים

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

• בהטמעות במכשירים חייבות להיות לפחות 2 ליבות פיזיות.
• בהטמעות של מכשירים חובה להצהיר על התכונה android.software.vr.mode.
• הטמעות במכשירים עשויות לספק ליבה בלעדית לאפליקציה שבחזית, ועשויות לתמוך ב-API Process.getExclusiveCores כדי להחזיר את המספרים של ליבות המעבד שהן בלעדיות לאפליקציה העליונה שבחזית. אם יש תמיכה בליבה בלעדית, הליבה חייבת לא לאפשר להריץ בה תהליכים אחרים במרחב המשתמש (למעט מנהלי התקנים שבהם האפליקציה משתמשת), אבל כן יכולה לאפשר להריץ תהליכים מסוימים בליבה לפי הצורך.
• הטמעות במכשירים חייבות לתמוך במצב ביצועים יציבים.
• הטמעות במכשירים חייבות לתמוך ב-OpenGL ES 3.2.
• הטמעות במכשירים חייבות לתמוך ברמת החומרה 0 של Vulkan, ומומלץ שתתמוך ברמת החומרה 1 של Vulkan.
• הטמעות של מכשירים חייבות ליישם את EGL_KHR_mutable_render_buffer ו-EGL_ANDROID_front_buffer_auto_refresh, ‏ EGL_ANDROID_create_native_client_buffer, ‏ EGL_KHR_fence_sync ו-EGL_KHR_wait_sync כדי שניתן יהיה להשתמש בהן במצב של מאגר משותף, ולהציג את התוספים ברשימה של תוספי ה-EGL הזמינים.
• חייבים להיות ל-GPU ולמסך אפשרות לסנכרן את הגישה למאגר הקדמי המשותף, כך שתוכן VR ייגרם לסירוגין בשתי העיניים ב-60fps עם שני הקשרי רינדור, בלי שיהיו בו שיבושים גלויים של קריעה.
• הטמעות במכשירים חייבות ליישם את EGL_IMG_context_priority ולהציג את התוסף ברשימת התוספים הזמינים של EGL.
• הטמעות במכשירים חייבות ליישם את GL_EXT_multisampled_render_to_texture, ‏ GL_OVR_multiview, ‏ GL_OVR_multiview2 ו-GL_OVR_multiview_multisampled_render_to_texture, ולהציג את התוספים ברשימת התוספים הזמינים של GL.
• הטמעות במכשירים חייבות ליישם את EGL_EXT_protected_content ואת GL_EXT_protected_textures כדי שניתן יהיה להשתמש בהן להפעלת סרטונים עם טקסטורות מאובטחות, ולהציג את התוספים ברשימת התוספים הזמינים של EGL ו-GL.
• הטמעות במכשירים חייבות לתמוך בפענוח H.264 של לפחות 3840x2160@30fps-40Mbps (שווה ערך ל-4 מופעים של 1920x1080@30fps-10Mbps או ל-2 מופעים של 1920x1080@60fps-20Mbps).
• הטמעות במכשירים חייבות לתמוך ב-HEVC וב-VP9, חייבות להיות מסוגלות לפענח לפחות 1920x1080@30fps-10Mbps וצריך שהן יהיו מסוגלות לפענח 3840x2160@30fps-20Mbps (שווה ערך ל-4 מופעים של 1920x1080@30fps-5Mbps).
• מומלץ מאוד שתמיכת הטמעת המכשיר תהיה בתכונה android.hardware.sensor.hifi_sensors, והיא חייבת לעמוד בדרישות שקשורות לחיישן הגירוסקופ, לחיישן ה-accelerometer ולחיישן המגנטומטר של android.hardware.hifi_sensors.
• הטמעות במכשירים חייבות לתמוך ב-HardwarePropertiesManager.getDeviceTemperatures API ולהחזיר ערכים מדויקים של טמפרטורת העור.
• בהטמעת המכשיר חייב להיות מסך מוטמע, והרזולוציה שלו חייבת להיות לפחות FullHD‏(1080p). מומלץ מאוד שהרזולוציה תהיה QuadHD‏ (1440p) ומעלה.
• המסך חייב להיות בגודל של 12 ס"מ עד 15.2 ס"מ באלכסון.
• התצוגה חייבת להתעדכן במהירות של לפחות 60Hz במצב VR.
• זמן האחזור של המסך במעבר מאפור לאפור, מלבן לשחור ומשחור ללבן חייב להיות ≤ 3 אלפיות השנייה.
• המסך חייב לתמוך במצב עמידות נמוכה עם עמידות של 5 אלפיות שנייה לכל היותר. עמידות מוגדרת כמשך הזמן שבו פיקסל פולט אור.
• הטמעות של מכשירים חייבות לתמוך ב-Bluetooth 4.2 וב-Bluetooth LE Data Length Extension (קטע 7.4.3).

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

בנוסף למצבי חיסכון באנרגיה, הטמעות של מכשירי Android עשויות ליישם כל אחד מ-4 מצבי השינה או את כולם, כפי שהם מוגדרים על ידי Advanced Configuration and Power Interface‏ (ACPI). עם זאת, אם הטמעה מיישמת את מצבי ההפעלה S3 ו-S4, המכשיר יכול להיכנס למצבים האלה רק כשסוגרים את המכסה שהוא חלק פיזי מהמכשיר.

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

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

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

8.5. ביצועים עקביים

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

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

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

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

אם הטמעה של מכשיר לא תומכת בליבה בלעדית, היא חייבת להחזיר רשימה ריקה דרך שיטת ה-API Process.getExclusiveCores().

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

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

9.1. הרשאות

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

חובה להעניק הרשאות עם protectionLevel של 'PROTECTION_FLAG_PRIVILEGED' רק לאפליקציות שהועמסו מראש בנתיבים המורשים עם הרשאות של קובץ האימג' של המערכת, כמו הנתיב system/priv-app בהטמעת AOSP.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

במכשירים חייב להיות מוטמע מנגנון של ארגז חול לאפליקציות בליבה, שמאפשר סינון של קריאות מערכת באמצעות מדיניות שניתן להגדיר מתוכניות עם מספר רב של שרשורים. הפרויקט של Android Open Source עומד בדרישות האלה על ידי הפעלת seccomp-BPF עם סנכרון של קבוצת חוטים (TSYNC), כפי שמתואר בקטע 'הגדרת הליבה' באתר source.android.com.

9.8. פרטיות

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

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

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

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

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

9.9. הצפנת אחסון נתונים

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

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

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

9.9.1. Direct Boot

כל המכשירים חייבים ליישם את ממשקי ה-API של מצב הפעלה ישיר, גם אם הם לא תומכים בהצפנת אחסון. באופן ספציפי, עדיין צריך לשדר את כוונות ה-Intent‏ LOCKED_BOOT_COMPLETED ו-ACTION_USER_UNLOCKED כדי לסמן לאפליקציות שתומכות בהפעלה ישירה שהמיקומים של האחסון של נתוני ה-Device Encrypted (DE) ושל נתוני ה-Credential Encrypted (CE) זמינים למשתמש.

9.9.2. הצפנה מבוססת-קבצים

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

• חייב להתאפס בלי לבקש מהמשתמש פרטי כניסה, ולאפשר לאפליקציות שתומכות בהפעלה ישירה לגשת לאחסון המוצפן של המכשיר (DE) אחרי שההודעה LOCKED_BOOT_COMPLETED תשודר.
• חובה לאפשר גישה לאחסון של פרטי הכניסה המוצפנים (CE) רק אחרי שהמשתמש פותח את נעילת המכשיר על ידי מסירת פרטי הכניסה שלו (למשל קוד גישה, מספר PIN, דפוס או טביעת אצבע) והודעת ACTION_USER_UNLOCKED משודרת. בהטמעות במכשירים אסור להציע שום שיטה לביטול הנעילה של האחסון המוגן ב-CE ללא פרטי הכניסה שהמשתמש סיפק.
• חובה לתמוך ב-Verified Boot ולוודא שמפתחות DE מקושרים באופן קריפטוגרפי ל-Root of Trust של החומרה של המכשיר.
• חובה לתמוך בהצפנת תוכן הקבצים באמצעות AES באורך מפתח של 256 ביט במצב XTS.
• חובה לתמוך בהצפנת שם הקובץ באמצעות AES באורך מפתח של 256 ביט במצב CBC-CTS.
• יכול לתמוך במצפינים, באורך מפתחות ובמצבים חלופיים להצפנת תוכן הקובץ ושמות הקבצים, אבל חייב להשתמש כברירת מחדל במצפינים, באורך מפתחות ובמצבים הנתמכים באופן מחייב.
• צריך להפוך אפליקציות חיוניות שהוגדרו מראש (למשל: שעון מעורר, טלפון, Messenger) למודעות לטעינה ישירה.

המפתחות שמגינים על אזורי האחסון של CE ו-DE:

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

בפרויקט Android Open Source ב-upstream יש הטמעה מועדפת של התכונה הזו שמבוססת על תכונת ההצפנה ext4 של ליבה של Linux.

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

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

9.10. תקינות המכשיר

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

הטמעות של מכשירים חייבות לדווח בצורה נכונה באמצעות שיטת System API‏ PersistentDataBlockManager.getFlashLockState() אם מצב האתחול שלהן מאפשר ביצוע הפעלה מחדש (flashing) של קובץ האימג' של המערכת. המצב FLASH_LOCK_UNKNOWN שמור להטמעות במכשירים שעברו שדרוג מגרסה קודמת של Android שבה שיטת ה-API החדשה הזו למערכת לא הייתה קיימת.

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

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

ב-upstream של פרויקט הקוד הפתוח של Android יש הטמעה מועדפת של התכונה הזו שמבוססת על התכונה dm-verity בליבה של Linux.

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

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

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

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

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

• לא מומלץ להגביל את מספר המפתחות שאפשר ליצור, וצריך לאפשר לייבא לפחות 8,192 מפתחות.
• האימות במסך הנעילה חייב להגביל את מספר הניסיונות, וחייב לכלול אלגוריתם חזרה איטרטיבי (backoff) מעריכי. אחרי 150 ניסיונות כושלים, זמן ההשהיה חייב להיות לפחות 24 שעות לכל ניסיון.
• כשהטמעת המכשיר תומכת בנעילת מסך מאובטחת, חובה לגבות את הטמעת מאגר המפתחות בחומרה מאובטחת ולעמוד בדרישות הבאות:
  • חובה שתהיה תמיכה ב-hardware באלגוריתם הקריפטוגרפיים RSA, ‏ AES, ‏ ECDSA ו-HMAC ובפונקציות הגיבוב של משפחת MD5, ‏ SHA1 ו-SHA-2, כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore.
  • חובה לבצע את האימות של מסך הנעילה בחומרה המאובטחת, ורק אם הוא מצליח, לאפשר שימוש במפתחות שמקושרים לאימות. בפרויקט הקוד הפתוח של Android שמשמש כמקור (upstream) זמין שכבת ההפשטה של החומרה (HAL) של Gatekeeper שאפשר להשתמש בה כדי לעמוד בדרישות האלה.

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

9.11.1. מסך נעילה מאובטח

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

• אם שיטת האימות מבוססת על סוד ידוע, אסור להתייחס אליה כאל מסך נעילה מאובטח, אלא אם היא עומדת בכל הדרישות הבאות:
  • האנטרופיה של אורך הקלט הקצר ביותר המותר חייבת להיות גדולה מ-10 ביט.
  • האנטרופיה המקסימלית של כל ערכי הקלט האפשריים חייבת להיות גדולה מ-18 ביט.
  • אסור להחליף אף אחת משיטות האימות הקיימות (קוד אימות, קו ביטול נעילה, סיסמה) שמוטמעות ומסופקות ב-AOSP.
  • חובה להשבית את האפשרות הזו כשאפליקציית Device Policy Controller‏ (DPC) מגדירה את מדיניות איכות הסיסמה באמצעות השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_SOMETHING .
• אם שיטת האימות מבוססת על אסימון פיזי או על המיקום, אסור להתייחס אליה כאל מסך נעילה מאובטח אלא אם היא עומדת בכל הדרישות הבאות:
  • חובה שיהיה לו מנגנון חלופי לשימוש באחת משיטות האימות הראשיות שמבוססת על סוד ידוע ועומדת בדרישות לטיפול כמסך נעילה מאובטח.
  • חובה להשבית אותו ולאפשר רק לאימות הראשי לבטל את נעילת המסך כשאפליקציית Device Policy Controller‏ (DPC) מגדירה את המדיניות באמצעות השיטה DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) או השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_UNSPECIFIED .
• אם שיטת האימות מבוססת על מידע ביומטרי, אסור להתייחס אליה כנעילת מסך מאובטחת אלא אם היא עומדת בכל הדרישות הבאות:
  • חובה שיהיה לו מנגנון חלופי לשימוש באחת משיטות האימות הראשיות שמבוססת על סוד ידוע ועומדת בדרישות לטיפול כמסך נעילה מאובטח.
  • חובה להשבית אותו ולאפשר רק לאימות הראשי לבטל את הנעילה של המסך כשאפליקציית Device Policy Controller‏ (DPC) מגדירה את מדיניות התכונה של keguard באמצעות קריאה לשיטה DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
  • שיעור הקבלה השגוי חייב להיות שווה או חזק יותר מזה שנדרש לחיישן טביעת אצבע, כפי שמתואר בקטע 7.3.10. לחלופין, הוא חייב להיות מושבת ולאפשר רק לאימות הראשי לבטל את נעילת המסך כשאפליקציית Device Policy Controller‏ (DPC) מגדירה את מדיניות איכות הסיסמה באמצעות השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_BIOMETRIC_WEAK.
• אם אי אפשר להתייחס לשיטת האימות כמסך נעילה מאובטח, היא:
  • חובה להחזיר את הערך false בשתי השיטות KeyguardManager.isKeyguardSecure() ו-KeyguardManager.isDeviceSecure().
  • חובה להשבית את האפשרות הזו כשאפליקציית Device Policy Controller‏ (DPC) מגדירה את מדיניות איכות הסיסמה באמצעות השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_UNSPECIFIED .
  • אסור לאפס את הטיימר לתפוגת התוקף של הסיסמה שהוגדר על ידי DevicePolicyManager.setPasswordExpirationTimeout().
  • אסור לבצע אימות של גישה למאגרי מפתחות אם האפליקציה התקשרה ל-KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)).
• אם שיטת האימות מבוססת על אסימון פיזי, המיקום או נתונים ביומטריים שיש להם שיעור אישור שגוי גבוה יותר מזה שנדרש לחיישנים של טביעות אצבע, כפי שמתואר בסעיף 7.3.10, אז:
  • אסור לאפס את הטיימר לתפוגת התוקף של הסיסמה שהוגדר על ידי DevicePolicyManager.setPasswordExpirationTimeout().
  • אסור לאמת את הגישה למאגרי המפתחות אם האפליקציה התקשרה ל-KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true).

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

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

• קובץ האימג' של המערכת
• כל קובץ מערכת הפעלה שנדרש לקובץ האימג' של המערכת

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

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

9.13. מצב הפעלה בטוח

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

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

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

• הטמעות במכשירים חייבות לספק למשתמש אפשרות להיכנס למצב הפעלה בטוח באופן שלא ניתן להפרעה מאפליקציות צד שלישי שמותקנות במכשיר, למעט במקרים שבהם אפליקציית הצד השלישי היא 'בקר מדיניות של מכשיר' והיא הגדרה את הדגל UserManager.DISALLOW_SAFE_BOOT כ-true.

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

9.14. בידוד של מערכת הרכב

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

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

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

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

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

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

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

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

10.2. CTS Verifier

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• תיעוד של יומן השינויים

סיכום של השינויים בקטעים של אנשים פרטיים:

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

12.1. טיפים לצפייה ביומן השינויים

השינויים מסומנים באופן הבא:

• CDD
  שינויים מהותיים בדרישות התאימות.

• מסמכים
  שינויים קוסמטיים או שינויים שקשורים ל-build.

כדי שהתצוגה תהיה הכי טובה, מוסיפים את הפרמטרים של כתובות ה-URL pretty=full ו-no-merges לכתובות ה-URL של יומני השינויים.

13. יצירת קשר

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