1. מבוא

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

קטגוריה	תכונה	קטע	מוחזקת ביד	טלוויזיה	צפייה	Automotive	אחר
קלט	לחצני החיצים (D-pad)	7.2.2. ניווט ללא מגע		חובה
	מסך מגע	7.2.4. קלט מסך המגע	חובה		חובה		אמור
	מיקרופון	7.8.1. מיקרופון	חובה	אמור	חובה	חובה	אמור
חיישנים	מד תאוצה	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	אמור	חובה	חובה	חובה	אמור
	Bluetooth עם צריכת אנרגיה נמוכה (BLE)	7.4.3. Bluetooth	אמור	חובה	אמור	אמור	אמור
	רדיו סלולרי	7.4.5. קיבולת רשת מינימלית				אמור
	ציוד היקפי בחיבור USB/מצב מארח	7.7. USB	אמור			אמור	אמור
פלט	יציאות של רמקול ו/או פלט אודיו	7.8.2. יעד השמע	חובה	חובה		חובה	חובה

3. תוכנות

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

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

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

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

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

3.2.1. הרשאות

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

3.2.2. בניית פרמטרים

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

פרמטר	פרטים
גרסה.גרסה	הגרסה של מערכת Android שפועלת כרגע, בפורמט קריא לאנשים. השדה הזה חייב להכיל אחד מערכי המחרוזת שמוגדרים ב-7.0.
VERSION.SDK	הגרסה של מערכת Android שפועלת כרגע, בפורמט שאפשר לגשת אליו לפי קוד של אפליקציה של צד שלישי. ב-Android 7.0, ערך המספר השלם בשדה הזה חייב להיות 7.0_INT.
VERSION.SDK_INT	הגרסה של מערכת Android שפועלת כרגע, בפורמט שאפשר לגשת אליו לפי קוד של אפליקציה של צד שלישי. ב-Android 7.0, ערך המספר השלם בשדה הזה חייב להיות 7.0_INT.
גרסה.INCREMENTAL	ערך שנבחר על ידי מכשיר ההטמעה, שמגדיר את ה-build הספציפי של מערכת Android שרצה כרגע, בפורמט קריא לאנשים. אסור לעשות שימוש חוזר בערך הזה לגרסאות build שונות שזמינות למשתמשי הקצה. בדרך כלל משתמשים בשדה הזה כדי לציין איזה מספר build או מזהה שינוי של בקרת מקור שימש ליצירת ה-build. בפורמט הספציפי של השדה הזה אין דרישות, אבל הוא לא חייב להיות null או מחרוזת ריקה ("").
משחקי לוח	ערך שנבחר על ידי יישום ההטמעה של המכשיר, שמזהה את החומרה הפנימית הספציפית שבה המכשיר משתמש, בפורמט קריא לאנשים. אפשר להשתמש בשדה הזה כדי לציין את הגרסה הספציפית של הלוח שמפעיל את המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות ולהתאים לביטוי הרגולרי "^[a-zA-Z0-9_-]+$".
מותג	ערך שמשקף את שם המותג המשויך למכשיר כידוע למשתמשי הקצה. התוכן חייב להיות בפורמט קריא לאנשים, והוא צריך לייצג את יצרן המכשיר או את מותג החברה שתחתיו המכשיר משווק. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות ולהתאים לביטוי הרגולרי "^[a-zA-Z0-9_-]+$".
SUPPORTED_ABIS	השם של קבוצת ההוראות (סוג המעבד (CPU) + מוסכמות ABI) של קוד נייטיב. ראו סעיף 3.3. תאימות ל-Native API.
SUPPORTED_32_BIT_ABIS	השם של קבוצת ההוראות (סוג המעבד (CPU) + מוסכמות ABI) של קוד נייטיב. ראו סעיף 3.3. תאימות ל-Native API.
SUPPORTED_64_BIT_ABIS	השם של קבוצת ההוראה השנייה (סוג מעבד (CPU) + מוסכמות ABI) של קוד נייטיב. ראו סעיף 3.3. תאימות ל-Native API.
מעבד [CPU_ABI]	השם של קבוצת ההוראות (סוג המעבד (CPU) + מוסכמות ABI) של קוד נייטיב. ראו סעיף 3.3. תאימות ל-Native API.
מעבד CPU_ABI2	השם של קבוצת ההוראה השנייה (סוג מעבד (CPU) + מוסכמות ABI) של קוד נייטיב. ראו סעיף 3.3. תאימות ל-Native API.
מכשיר	ערך שנבחר על ידי מטמיע המכשיר שמכיל את שם הפיתוח או את שם הקוד המזהה את התצורה של תכונות החומרה והעיצוב התעשייתי של המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות ולהתאים לביטוי הרגולרי "^[a-zA-Z0-9_-]+$". אסור לשנות את שם המכשיר הזה במהלך כל משך החיים של המוצר.
טביעת אצבע	מחרוזת שמשמשת לזיהוי ייחודי של ה-build הזה. הוא אמור להיות קריא לאנשים באופן סביר. היא חייבת להיות בתבנית הבאה: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.VERSION)/$(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_-]+$".
מארח	מחרוזת שמזהה באופן ייחודי את המארח שעליו נבנה ה-build, בפורמט קריא לאנשים. בפורמט הספציפי של השדה הזה אין דרישות, אבל הוא לא חייב להיות null או מחרוזת ריקה ("").
מזהה	מזהה שנבחר על ידי מכשיר ההטמעה כדי להתייחס לגרסה ספציפית, בפורמט קריא לאנשים. השדה הזה יכול להיות זהה ל-android.os.Build.VERSION.INCREMENTAL, אבל עליו להיות ערך משמעותי מספיק כדי שמשתמשי הקצה יוכלו להבחין בין גרסאות ה-build של התוכנה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות ולהתאים לביטוי הרגולרי "^[a-zA-Z0-9._-]+$".
יצרנים	השם המסחרי של יצרן הציוד המקורי (OEM) של המוצר. בפורמט הספציפי של השדה הזה אין דרישות, אבל הוא לא חייב להיות null או מחרוזת ריקה ("").
דגם	ערך שנבחר על ידי יישום ההטמעה של המכשיר, שמכיל את שם המכשיר כידוע למשתמש הקצה. זה אמור להיות אותו השם שתחתיו המכשיר משווק ונמכר למשתמשי הקצה. בפורמט הספציפי של השדה הזה אין דרישות, אבל הוא לא חייב להיות null או מחרוזת ריקה ("").
מוצר	ערך שנבחר על ידי מטמיע המכשיר שמכיל את שם הפיתוח או את שם הקוד של המוצר הספציפי (מק"ט) שחייב להיות ייחודי באותו מותג. התוכן חייב להיות קריא לאנשים, אבל הוא לא מיועד בהכרח לתצוגה של משתמשי הקצה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות ולהתאים לביטוי הרגולרי "^[a-zA-Z0-9_-]+$". אסור לשנות את שם המוצר הזה במהלך כל משך החיים של המוצר.
סידורי	מספר סידורי של חומרה, חייב להיות זמין וייחודי בכל המכשירים עם אותו MODEL ו-MANUFACTURER. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי "^([a-zA-Z0-9]{6,20})$".
תגים	רשימת תגים מופרדים בפסיקים שנבחרו על ידי כלי ההטמעה של המכשיר, כדי להבדיל עוד יותר בין ה-build. השדה הזה חייב להכיל אחד מהערכים שתואמים לשלוש התצורות הטיפוסיות של חתימות בפלטפורמת Android: מפתחות הפצה, מפתחות פיתוח ומפתחות בדיקה.
שעה	ערך שמייצג את חותמת הזמן של מועד ה-build.
סוג	ערך שנבחר על ידי ההטמעה של המכשיר, שמציין את התצורה של זמן הריצה של ה-build. השדה הזה חייב להכיל אחד מהערכים שתואמים לשלוש התצורות הטיפוסיות של זמן ריצה ב-Android: משתמש, userdebug או eng.
משתמש	השם או מזהה המשתמש של המשתמש (או המשתמש האוטומטי) שיצר את ה-build. בפורמט הספציפי של השדה הזה אין דרישות, אבל הוא לא חייב להיות null או מחרוזת ריקה ("").
security_PATCH	ערך שמציין את רמת תיקון האבטחה של ה-build. הוא חייב לציין שה-build לא חשוף בשום צורה לבעיות שתוארו דרך העדכון הייעודי של Android לגבי אבטחה ציבורית. היא חייבת להיות בפורמט [YYYY-MM-DD], שתואם למחרוזת מוגדרת שמתועדת בעדכון האבטחה הציבורי של Android או בהתראת האבטחה של Android, לדוגמה '2015-11-01'.
BASE_OS	ערך שמייצג את הפרמטר FINGERPrint של ה-build, שהיה זהה בדרך כלל ל-build הזה, מלבד התיקונים שסופקו ב-Bulletin של Android Public Security. חובה לדווח על הערך הנכון. אם גרסת ה-build הזו לא קיימת, צריך לדווח על מחרוזת ריקה ("").

3.2.3. תאימות של Intent

3.2.3.1. אובייקטים מרכזיים של Intent של אפליקציה

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

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

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

3.2.3.2. יישוב כוונות

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

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

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

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

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

3.2.3.3. מרחבי שמות של Intent

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

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

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

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

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

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

• חובה לפעול בהתאם ל-Intent של android.settings.HOME_SETTINGS כדי להציג תפריט ברירת מחדל של הגדרות האפליקציה במסך הבית, אם הדיווח על הטמעת המכשיר מדווח על android.software.home_screen.
• חובה לספק תפריט הגדרות שיקרא ל-Intent android.provider.טלפוני.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. תאימות ל-Native API

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

3.3.1. ממשקים בינאריים של אפליקציות

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

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

• חייבת לכלול תמיכה בקוד שפועל בסביבה המנוהלת כדי לקרוא לקוד נייטיב, באמצעות סמנטיקה סטנדרטית של Java Native Interface (JNI).
• חייבת להיות תאימות למקור (כלומר, תאימות לכותרת) ותאימות בינארית (ל-ABI) לכל ספרייה נדרשת ברשימה שלמטה.
• אם יש תמיכה ב-ABI של 64 ביט, היא חייבת לתמוך ב-ABI מקביל של 32 ביט.
• חובה לדווח באופן מדויק על Application Binary Interface (ABI) המקורי שנתמך במכשיר, באמצעות 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 ב-upstream

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

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

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

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

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

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

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

• חובה לדווח, 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”.

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

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

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

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

• הוראות ל-SWP ול-SWPB
• הוראה להגדרה
• פעולות מחסום של CP15ISB, CP15DSB ו-CP15DMB

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

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

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

3.4. תאימות לאתרים

3.4.1. תאימות ל-WebView

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

• ההטמעות של android.webkit.WebView במכשיר חייבות להתבסס על גרסת ה-build של Chromium מפרויקט הקוד הפתוח של Android ל-Android 7.0. ה-build הזה כולל קבוצה ספציפית של פונקציונליות ותיקוני אבטחה ל-WebView.

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

  Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, like Gecko) גרסה/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • הערך של המחרוזת $(VERSION) חייב להיות זהה לערך של android.os.Build.VERSION.VERSION.
  • הערך של המחרוזת $(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 ב-upstream או החלפה של צד שלישי) צריכה לכלול תמיכה בכמה שיותר שימוש ב-HTML5. באופן מינימלי, הטמעות מכשירים חייבות לתמוך בכל אחד מממשקי ה-API הבאים המשויכים ל-HTML5:

• פעולה במטמון/במצב אופליין של אפליקציה
• <video> תג
• מיקום גיאוגרפי

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

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

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

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

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

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

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

• Java.*
• Javax.*
• שמש.*
• android.*
• com.android.*

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

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

'אלמנט שנחשף באופן ציבורי' הוא כל מבנה שלא מקושט בסמן ' @הסתרה', כפי שנעשה בו שימוש בקוד המקור של Android ב-upstream. במילים אחרות, למטמיעי מכשירים אסור לחשוף ממשקי 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 Executable (DEX) ובמפרט ובסמנטיקה של Dalvik bytecode. מטמיעי המכשירים צריכים להשתמש ב-ART, בהפניית upstream ב-upstream של Dalvik Executable Format, ובמערכת ניהול החבילות של הטמעת ההפניה.

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

פריסת מסך	דחיסות מסך	זיכרון מינימלי של האפליקציה
שעון Android	120 dpi (ldpi)	32MB
	160 dpi (mdpi)
	213 dpi (tvdpi)
	240 dpi (hdpi)	36MB
	280 dpi (280dpi)
	320 dpi (xhdpi)	48MB
	360 dpi (360dpi)
	400 dpi (400dpi)	56MB
	420 dpi (420dpi)	64MB
	480 dpi (xxhdpi)	88MB
	560 dpi (560dpi)	112MB
	640 dpi (xxxhdpi)	154MB
קטן/רגיל	120 dpi (ldpi)	32MB
	160 dpi (mdpi)
	213 dpi (tvdpi)	48MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80MB
	360 dpi (360dpi)
	400 dpi (400dpi)	96MB
	420 dpi (420dpi)	112MB
	480 dpi (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256MB
גדולה	120 dpi (ldpi)	32MB
	160 dpi (mdpi)	48MB
	213 dpi (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
	480 dpi (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640 dpi (xxxhdpi)	512MB
xlarge	120 dpi (ldpi)	48MB
	160 dpi (mdpi)	80MB
	213 dpi (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
	480 dpi (xxhdpi)	384MB
	560 dpi (560dpi)	576MB
	640 dpi (xxxhdpi)	768MB

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

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

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

3.8.2. ווידג'טים

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

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

3.8.3. התראות

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

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

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

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

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

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

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

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

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

3.8.4. חיפוש

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

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

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

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

3.8.5. טוסטים

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

3.8.6. עיצובים

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

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

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

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

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

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

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

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

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

3.8.8. החלפת פעילות

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

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

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

3.8.9. ניהול קלט

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

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

3.8.10. בקרת מדיה במסך הנעילה

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

3.8.11. שומרי מסך (לשעבר Dreams)

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

3.8.12. מיקום

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

3.8.13. Unicode וגופן

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

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

מערכת Android כוללת תמיכה בטווחים של Roboto 2 במשקלים שונים –sans-serif-thin , San-serif-light , San-serif-medium , San-serif-black , San-serif- להיעזר ב-San-serif- להיעזר ב-Google .

3.8.14. חלונות מרובים

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

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

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

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

3.9.1 הקצאת מכשיר

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

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

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

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

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

3.10. נגישות

ב-Android יש שכבת נגישות שעוזרת למשתמשים עם מוגבלויות לנווט במכשירים שלהם בקלות רבה יותר. בנוסף, ב-Android יש ממשקי API של פלטפורמה שמאפשרים הטמעות של שירותי נגישות כדי לקבל קריאות חוזרות לגבי אירועי משתמש ומערכת, וליצור מנגנוני משוב חלופיים, כמו המרת טקסט לדיבור (TTS), משוב פיזי וניווט באמצעות משטח (trackball/d-pad).

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

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

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

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

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

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

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

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

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

הטמעות של Android Automotive:

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

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

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

3.12. מסגרת של קלט טלוויזיה

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

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

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

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

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

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

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

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

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

3.12.1.2. ניווט

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

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

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

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

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

3.12.1.4. הקלטה תוך כדי צפייה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מנהל החבילות חייב לתמוך באימות קובצי .APK באמצעות גרסה 2 של APK Signature Scheme וחתימת JAR.

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

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

5.1. רכיבי קודק של מדיה

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

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

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

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

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

המטרה של רכיבי קודק צריכה להיות זמן אחזור מינימלי של קודק, כלומר, קודק

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

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

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

5.1.1. רכיבי קודק אודיו

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

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

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

• מבוצע פענוח ללא רמיקס (לדוגמה: יש לפענח זרם 5.0 AAC לחמישה ערוצים של PCM, זרם AAC מסוג 5.1 חייב להיות מפוענח לשישה ערוצים של PCM)
• מטא-נתונים של טווח דינמי, כפי שמוגדר ב"בקרת טווח דינמי (DRC)" בתקן ISO/IEC 14496-3 ובמפתחות android.media.MediaFormat DRC, כדי להגדיר את ההתנהגות הדינמית שקשורה לטווח של מפענח האודיו. מפתחות ה-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	חובה?	חובה?	בסיס+מתקדם	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 חייבת לתמוך בניתוח ובטיפול של מטא-נתונים סטטיים ב-HDR.

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

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

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

פורמט/קודק	במקודד	מפענח	פרטים	סוגי קבצים נתמכים/ פורמטים של קונטיינרים
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 TV.

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

מקודדי וידאו H.264, VP8, VP9 ו-HEVC —

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

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

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

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

5.2.1. H.263

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

5.2.2. H-264

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

• חייבת להיות תמיכה ברמה 3 של פרופיל הבסיס.
  עם זאת, התמיכה ב-ASO (סידור פרוסות שרירותי), FMO (סידור גמיש של Macroblock) ו-RS (פרוסות מיותרות) היא אופציונלית. בנוסף, כדי לשמור על תאימות למכשירי Android אחרים, מומלץ שהמקודדים לא ישתמשו ב-ASO, ב-FMO וב-RS בפרופיל Baseline.
• חייבים לתמוך בפרופילי קידוד וידאו באיכות SD (Standard Definition) שבטבלה הבאה.
• צריכה לתמוך ברמה 4 של הפרופיל הראשי.
• הנתונים האלה אמורים לתמוך בפרופילי קידוד הווידאו באיכות HD (איכות HD), כפי שמצוין בטבלה הבאה.
• בנוסף, במכשירי Android TV מומלץ מאוד לקודד וידאו באיכות HD ברזולוציית 1080p בקצב של 30FPS.

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

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

5.2.3. VP8

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

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

1 כאשר נתמך על ידי החומרה.

5.3. פענוח הקוד של הווידאו

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

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

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

• חובה לספק מחלץ עם תמיכה ב-Dolby Vision.

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

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

5.3.1. MPEG-2

הטמעות של מכשירי Android עם מפענחי MPEG-2 חייבות לתמוך ברמה גבוהה של הפרופיל הראשי.

5.3.2. H.263

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

5.3.3. MPEG-4

בהטמעות של מכשירי Android עם מפענחי MPEG-4, חייבת להיות תמיכה ב-Simple Profile Level 3.

5.3.4. H.264

הטמעות של מכשירי Android עם מפענחי H.264:

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

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

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

2 חובה בהטמעות של מכשירי Android TV.

5.3.5. H.265 (‏HEVC)

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

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

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

1 חובה להטמעות של מכשירי Android TV עם פענוח באמצעות חומרה בפורמט H.265.

5.3.6. VP8

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

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

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p 1	HD 1080p 1
רזולוציית וידאו	180 x 320 פיקסלים	640 x 360 פיקסלים	720 x 1280 פיקסלים	1920 x 1080 פיקסלים
קצב הפריימים של הסרטון	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 TV.

5.3.7. VP9

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

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

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

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

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

1 חובה להטמעות של מכשירי Android TV עם פענוח חומרה מסוג VP9.

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

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

5.4.1. הקלטת אודיו גולמי

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

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

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

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

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

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

5.4.2. צילום לזיהוי קולי

מקור האודיו android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION חייב לתמוך בהקלטה באחד מקצבי הדגימה, 44100 ו-48,000.

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

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

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

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

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

• STREAM_RING
• STREAM_ALARM
• STREAM_NOTIFICATION

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

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

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

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

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

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

• שיעורי דגימה : 24000, 48000

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

ב-Android יש API לאפקטים קוליים בהטמעות במכשירים. יישומי מכשירים שבהם מוצהר על התכונה android.hardware.audio.output:

• חייבת לתמוך בהטמעות EFFECT_TYPE_EQUALIZER ו-EFFECT_TYPE_LOUDness_ENHANCER שאפשר לשלוט בהן באמצעות אקוולייזר למחלקות המשנה Audio Effects, LoudnessEnhancer.
• חייבת לתמוך בהטמעת API של Visualizer, שאפשר לשלוט בה באמצעות המחלקה Visualizer.
• SHOULD תומך בהטמעות EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB ו-EFFECT_TYPE_VIRTUALIZER שניתנות לשליטה באמצעות מחלקות המשנה Audioנקט BassBoost, EnvironmentalReverb, PresetReverbB ו-Virtualizer.

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

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

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

5.6. זמן אחזור של אודיו

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

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

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

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

• זמן אחזור של פלט במצב קר של 100 אלפיות השנייה לכל היותר
• זמן אחזור של פלט רציף של 45 אלפיות השנייה לכל היותר
• מזעור רעידות הפלט במצב התחלתי

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

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

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

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

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

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

• פרוטוקול טיוטה של HTTP בשידור חי, גרסה 7
  צריכה להיות תמיכה בפורמטים הבאים של פלחי מדיה:

פורמטים של פלחים	הפניות	נדרשת תמיכה בקודק
MPEG-2 Transport Stream	ISO 13818	קודק הווידאו: H264 AVC MPEG-4 SP MPEG-2 פרטים נוספים על H264 AVC, MPEG2-4 SP ו-MPEG2-4 SP זמינים בסעיף 5.1.3 ו-MPEG-2. קודק האודיו: קובץ AAC מידע נוסף על AAC ועל הווריאציות שלו זמין בסעיף 5.1.1.
AAC עם תגי פריים ו-ID3 של ADTS	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-גנרי	RFC 3640	מידע נוסף על קובץ AAC ועל הווריאציות שלו זמין בסעיף 5.1.1.
MP2T	RFC 2250	לפרטים נוספים, ראו MPEG-2 Transport Stream מתחת ל-HTTP Live Streaming

5.8. מדיה מאובטחת

בהטמעות של מכשירים שתומכים בפלט וידאו מאובטח ומסוגלים לתמוך בפלטפורמות מאובטחות, חובה להצהיר על תמיכה ב-Display.FLAG_SECURE. יישומים של מכשירים שבהם מוצהר על תמיכה ב-Display.FLAG_SECURE. אם הם תומכים בפרוטוקול תצוגה אלחוטי, יש לאבטח את הקישור באמצעות מנגנון קריפטוגרפי חזק כמו HDCP 2.x ואילך למסכים אלחוטיים של Miracast. בדומה לכך, אם המכשירים תומכים במסך חיצוני עם חיבור קווי, בהטמעות המכשירים חייבים לתמוך ב-HDCP 1.2 ואילך. הטמעות של מכשירי Android TV חייבים לתמוך ב-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.
• אם המכשיר כולל שקע אודיו עם 4 מוליך 3.5 מ"מ, מומלץ מאוד להטמיע את המכשיר כדי לעמוד בדרישות של סעיף מפרטי מכשירים ניידים (שקע) של מפרט אוזניות אודיו חוטיות (גרסה 1.1).

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

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

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

5.11. צילום למכשירים לא מעובדים

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

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

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

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

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

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

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

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

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

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

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

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

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

• גשר לניפוי באגים ב-Android (adb)
  • בהטמעות של מכשירים חייבת להיות תמיכה בכל פונקציות adb כפי שמתואר ב-Android SDK, כולל dumpsys.
  • ה-daemon של adb בצד המכשיר חייב להיות לא פעיל כברירת מחדל, וכדי להפעיל את הגשר לניפוי באגים ב-Android חייב להיות מנגנון נגיש למשתמש. אם הטמעת המכשיר לא כוללת את מצב הציוד ההיקפי בחיבור USB, היא חייבת להטמיע את גשר ניפוי הבאגים של Android דרך רשת אזורית (כמו אתרנט או 802.11).
  • Android כולל תמיכה ב-adb מאובטח. פרוטוקול adb מאובטח מאפשר הפעלה של adb במארחים מאומתים מוכרים. הטמעות של מכשירים חייבות לתמוך ב-adb מאובטח.
• Dalvik Debug Monitor Service (ddms)
  • הטמעת מכשירים חייבת לתמוך בכל התכונות של ddms כפי שמתואר ב-Android SDK.
  • מכיוון ש-ddms משתמשים ב-adb, התמיכה ב-ddms אמורה להיות לא פעילה כברירת מחדל, אבל חייבת להיות תמיכה בכל פעם שהמשתמשים מפעילים את הכלי 'גשר ניפוי באגים ב-Android', כפי שמתואר למעלה.
• Monkey הטמעות מכשירים חייבות לכלול את Monkey framework ולאפשר לאפליקציות להשתמש בו.
• 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 ב-upstream מסתירה את תפריט האפשרויות למפתחים כברירת מחדל ומאפשרת למשתמשים להפעיל את האפשרויות למפתחים לאחר לחיצה שבע (7) פעמים בקטע הגדרות > מידע על המכשיר > האפשרות מספר Build בתפריט. הטמעת מכשירים חייבת לספק חוויה עקבית לאפשרויות למפתחים. באופן ספציפי, בהטמעות במכשירים צריך להסתיר את האפשרויות למפתחים כברירת מחדל, והן חייבות לספק מנגנון להפעלת 'אפשרויות למפתחים' שתואם להטמעה של Android ב-upstream.

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

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

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

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

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

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

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

היחידות שמוזכרות בדרישות בסעיף הזה מוגדרות כך:

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

7.1.1. הגדרת המסך

7.1.1.1. גודל מסך

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

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

כמו כן:

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

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

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

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

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

• אם ה-uiMode מוגדר כ-UI_מצב_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)
• 160 dpi (mdpi)
• 213 dpi (tvdpi)
• 240 dpi (hdpi)
• 280 dpi (280dpi)
• 320 dpi (xhdpi)
• 360 dpi (360dpi)
• 400 dpi (400dpi)
• 420 dpi (420dpi)
• 480 dpi (xxhdpi)
• 560 dpi (560dpi)
• 640 dpi (xxxhdpi)

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

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

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

הטמעות של מכשירים חייבות לתמוך גם ב-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 המקוריים של C/C++ OpenGL (ממשקי 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 ותמיכה מובנית בפונקציונליות גרפיקה מתקדמת, כמו פונקציית גלישה (tessellation) ופורמט דחיסת המרקם של ASTC. הטמעות של מכשירי Android חייבות לתמוך בחבילת התוספים אם המכשיר תומך ב-OpenGL ES 3.2 ו-MAY תומך בה אחרת. אם חבילת התוספים נתמכת במלואה, המכשיר חייב לזהות את התמיכה באמצעות התכונה הניסיונית android.hardware.opengles.aep.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.2.3. מקשי ניווט

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

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

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

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

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

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

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

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

בהטמעות של מכשירי Android שתומכות ב-Assist action (פעולת סיוע) ו/או VoiceInteractionService, חייבת להיות אפשרות להפעיל אפליקציית עזרה באינטראקציה אחת (למשל: הקשה, לחיצה כפולה או תנועה) כשניתן לראות מקשי ניווט אחרים. מומלץ מאוד ללחוץ לחיצה ארוכה על הבית בתור האינטראקציה הזו. האינטראקציה הייעודית חייבת להפעיל את אפליקציית העזרה שנבחרו על ידי המשתמש. במילים אחרות, האפליקציה שמטמיעה שירות VoiceInteractionService או פעילות שמטפלת ב-Intent 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 TV חייבים לתמוך במיפויי לחצנים לבקרי משחקים, כמפורט בהמשך. ההטמעה של Android ב-upstream כוללת הטמעה לבקרי משחקים שעומדים בדרישה הזו.

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

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

לחצן	שימוש במכשיר ממשק אנושי (HID) 2	לחצן Android
א 1	0x09 0x0001	KEYCODE_button_A (96)
ב 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)
לחיצה על הלחצן הימני 1	0x09 0x000F	KEYCODE_button_THUMBR (107)
דף הבית 1	0x0c 0x0223	KEYCODE_HOME (3)
חזרה 1	0x0c 0x0224	KEYCODE_BACK (4)

אירוע מרכזי אחד

2 יש להצהיר על השימוש ב-HID שלמעלה ב-Game pad CA (0x01 0x0005).

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

4 MotionEvent

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

• עלות בחיפוש Google . יישומים של מכשירים חייבים להפעיל את KEYCODE_SEARCH כאשר המשתמש מפעיל חיפוש קולי בשלט הרחוק הפיזי או בשלט הרחוק מבוסס התוכנה.
• ניווט . כל השלטים הרחוקים של Android TV חייבים לכלול את הלחצנים 'חזרה', 'בית' ו'בחירה' ותמיכה באירועי D-pad.

7.3. חיישנים

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

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

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

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

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

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

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

7.3.1. מד תאוצה

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

• חובה להטמיע חיישן TYPE_ACCELEROMETER ולדווח עליו.
• חייבת להיות אפשרות לדווח על אירועים בתדירות של עד 50 Hz לפחות במכשירי Android Watch, כי במכשירים כאלה יש מגבלת כוח מחמירה יותר ו-100Hz לכל סוגי המכשירים האחרים.
• צריך לדווח על אירועים עד 200 Hz לפחות.
• חייב לעמוד בדרישות של מערכת הקואורדינטות של החיישנים של Android, כמפורט בממשקי ה-API של Android. ההטמעה של Android Automotive חייבת לעמוד בדרישות של מערכת הקואורדינטות של חיישנים לרכב של Android.
• חייבת להיות מסוגלת למדוד מצניחה חופשית עד פי ארבעה מכוח הכבידה (4 ג') או יותר בכל ציר.
• חייבת להיות ברזולוציה של 12 סיביות לפחות והרזולוציה צריכה להיות 16 סיביות לפחות.
• צריך לכייל את המכשיר בזמן השימוש אם המאפיינים משתנים במהלך מחזור החיים ומתגמלים אותם, ושומרים את הפרמטרים של הפיצוי בין הפעלה מחדש של המכשיר.
• הטמפרטורה אמורה לפצות על הטמפרטורה.
• סטיית התקן חייבת להיות באורך של לא יותר מ-0.05 מטרים לשנייה, שבה יש לחשב את סטיית התקן על בסיס כל ציר על סמך דגימות שנאספו לאורך תקופה של 3 שניות לפחות בקצב הדגימה המהיר ביותר.
• יש להטמיע את החיישנים המורכבים TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR ו-TYPE_STEP_COUNTER, כפי שמתואר במסמך של Android SDK. מכשירי Android קיימים וחדשים מומלץ מאוד להטמיע את החיישן המורכב TYPE_SIGNIFICANT_MOTION. אם אחד מהחיישנים האלה מוטמע, סכום צריכת החשמל הכוללת שלהם תמיד צריך להיות קטן מ-4 מגה-ואט, וכל אחד מהם צריך להיות נמוך מ-2 מגה-ואט, וגם 0.5 מגה-ואט כשהמכשיר במצב דינמי או סטטי.
• אם כלול חיישן ג'ירוסקופ, יש להטמיע את החיישנים המורכבים TYPE_GRAVITY ו-TYPE_LINEAR_ACCELERATION ולהטמיע את החיישן המרוכב TYPE_GAME_ROTATION_VECTOR. מומלץ מאוד להטמיע את החיישן TYPE_GAME_ROTATION_VECTOR במכשירי Android קיימים וחדשים.
• חייבים להטמיע חיישן מרוכב TYPE_ROTATION_VECTOR, אם כלולים גם חיישן ג'ירוסקופ וחיישן מגנטומטר.

7.3.2. מגנטומטר

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

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

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 כדי למזער את זמן הנעילה של ה-GPS/GNSS (נתוני הסיוע כוללים את זמן ההפניה, מיקום ההפניה והזמן/שעון הלוויין).
  • אחרי חישוב מיקום כזה, מומלץ מאוד שהמכשיר יוכל לקבוע את המיקום שלו בשמיים, בתוך 10 שניות כשבקשות המיקום מופעלות מחדש, עד שעה אחרי חישוב המיקום הראשוני, גם אם הבקשה הבאה נשלחת ללא חבילת גלישה ו/או אחרי מחזור חשמל.
• בתנאים של שמיים פתוחים לאחר קביעת המיקום, בזמן תנועה של פחות ממטר לשנייה בריבוע תאוצה:
  • היא חייבת להיות מסוגלת לקבוע את המיקום בטווח של 20 מטר, והמהירות היא בטווח של 0.5 מטר לשנייה, לפחות 95% מהזמן.
  • היא חייבת לעקוב בו-זמנית אחר 8 לוויינים לפחות מקבוצת כוכבים אחת ולדווח עליהם באמצעות GnssStatus.Callback.
  • היא צריכה להיות מסוגלת לעקוב בו-זמנית אחרי לפחות 24 לוויינים, ממספר קבוצות כוכבים (למשל, GPS + לפחות אחד מהדגמים הבאים: Glonass, Beidou, גליליאו).
• הוא חייב לדווח על יצירת הטכנולוגיה של 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. מומלץ מאוד להשתמש במכשירי Android קיימים וחדשים כדי להטמיע את החיישן SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
• חייבת להיות מסוגלת למדוד שינויי כיוון של עד 1,000 מעלות לשנייה.
• חייבת להיות אפשרות לדווח על אירועים בתדירות של עד 50 Hz לפחות במכשירי Android Watch, כי במכשירים כאלה יש מגבלת כוח מחמירה יותר ו-100Hz לכל סוגי המכשירים האחרים.
• צריך לדווח על אירועים עד 200 Hz לפחות.
• הרזולוציה צריכה להיות 12 סיביות או יותר, והרזולוציה צריכה להיות 16 סיביות או יותר.
• חייב להיות פיצוי על הטמפרטורה.
• חובה לבצע כיול ותגמול בזמן השימוש. יש לשמור את הפרמטרים של הפיצוי בין הפעלות מחדש של המכשיר.
• השונות חייבת להיות גדולה מ- 1e-7 rad^2 / s^2 לכל Hz (הבדלים ל-Hz או rad^2 / s). השונות יכולה להשתנות בהתאם לתדירות הדגימה, אבל חייבת להיות מוגבלת על ידי הערך הזה. במילים אחרות, אם מודדים את השונות של הג'יירו בקצב דגימה של 1 Hz הוא לא צריך להיות גדול מ-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_מפטר וגם חייב להיות למדוד את טמפרטורת הסביבה (חדר) במעלות צלזיוס.

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

7.3.7. פוטומטר

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

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

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

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

• SENSOR_TYPE_GYROSCOPE

  • טווח המדידה חייב להיות בין -1000 ל- +1000 dps.
  • רזולוציית המדידה חייבת להיות לפחות 16 LSB/dps.
  • תדירות המדידה המינימלית חייבת להיות 12.5Hz או נמוכה יותר.
  • תדירות המדידה המקסימלית חייבת להיות 400 Hz או יותר.
  • הרעש במדידה חייב להיות נמוך מ-0.014°/s/לצאת.
  • אמורה להיות הטיה נייחתית של < 0.0002 °/s מוגבלת Hz ממערך נתונים סטטי של 24 שעות.
  • אמור להיות שינוי בהטיה לעומת טמפרטורה של ≤ +/- 0.05 °C/ s / °C.
  • צריך להיות שינוי ברגישות לעומת הטמפרטורה של 0.02% / °C.
  • הקו המתאים ביותר צריך להיות לא ליניארי, כלומר 0.2% או פחות.
  • צפיפות הרעש אמורה להיות ≤ 0.007 °/s/COLUMNHz.

• SENSOR_TYPE_GYROSCOPE_UNCALIBRATED עם אותן דרישות איכות כמו SENSOR_TYPE_GYROSCOPE.

• SENSOR_TYPE_geoMAGNETIC_FIELD
  • טווח המדידה חייב להיות בין -900 ל- +900 uT.
  • רזולוציית המדידה חייבת להיות לפחות 5 LSB/uT.
  • תדירות המדידה המינימלית חייבת להיות 5Hz או נמוכה יותר.
  • תדירות המדידה המקסימלית חייבת להיות 50Hz או יותר.
  • הרעש במדידה חייב להיות נמוך מ-0.5 UT.
• SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED עם אותן דרישות איכות כמו SENSOR_TYPE_geoMAGNETIC_FIELD וגם:
  • החיישן הזה חייב להטמיע צורה שאינה במצב שינה, עם יכולת אגירת נתונים של 600 אירועי חיישן לפחות.
• SENSOR_TYPE_PRESSURE
  • טווח המדידה חייב להיות בין 300 ל-1100 hPa.
  • רזולוציית המדידה חייבת להיות לפחות 80 LSB/hPa.
  • תדירות המדידה המינימלית חייבת להיות 1 Hz או נמוכה יותר.
  • תדירות המדידה המקסימלית חייבת להיות 10Hz או יותר.
  • הרעש במדידה חייב להיות נמוך מ-2 Pa/😂.
  • החיישן הזה חייב להטמיע צורה שאינה במצב שינה, עם יכולת אגירת נתונים של 300 אירועי חיישן לפחות.
  • צריכת החשמל באצווה חייבת להיות נמוכה מ-2 מגה-ואט.
• SENSOR_TYPE_GAME_ROTATION_VECTOR
  • החיישן הזה חייב להטמיע צורה שאינה במצב שינה, עם יכולת אגירת נתונים של 300 אירועי חיישן לפחות.
  • צריכת החשמל באצווה חייבת להיות נמוכה מ-4 מגה-ואט.
• SENSOR_TYPE_SIGNIFICANT_MOTION
  • צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי, ו-1.5 מגה-ואט כשהמכשיר נמצא בתנועה.
• SENSOR_TYPE_STEP_DETECTOR
  • החיישן הזה חייב להטמיע צורה שאינה במצב שינה, עם יכולת אגירת נתונים של 100 אירועי חיישן לפחות.
  • צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי, ו-1.5 מגה-ואט כשהמכשיר נמצא בתנועה.
  • צריכת החשמל באצווה חייבת להיות נמוכה מ-4 מגה-ואט.
• SENSOR_TYPE_STEP_COUNTER
  • צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי, ו-1.5 מגה-ואט כשהמכשיר נמצא בתנועה.
• SENSOR_TILT_DETECTOR
  • צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי, ו-1.5 מגה-ואט כשהמכשיר נמצא בתנועה.

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

• חותמת הזמן של האירוע הפיזי של אותו אירוע פיזי שדווחה על ידי מד התאוצה, חיישן הג'יירוסקופ והמגנטומטר חייבים להיות בטווח של 2.5 אלפיות השנייה זה מזה.
• חותמות הזמן של האירועים של חיישן הג'ירוסקופ חייבות להיות באותו בסיס זמן כמו מערכת המשנה של המצלמה, ותוך אלפיות שנייה אחת משגיאה.
• חיישנים באיכות גבוהה חייבים לשלוח דגימות לאפליקציות תוך 5 אלפיות שנייה מהמועד שבו הנתונים זמינים בחיישן הפיזי לאפליקציה.
• צריכת החשמל לא יכולה להיות גבוהה מ-0.5 מגה-ואט כשהמכשיר סטטי ו-2.0 מגה-ואט כשהמכשיר בתנועה, כל שילוב של החיישנים הבאים מופעל:
  • 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%, כפי שנמדד במכשיר
• מומלץ מאוד שזמן האחזור יהיה פחות משנייה אחת, שנמדד מהנגיעה בחיישן טביעות האצבע עד לביטול נעילת המסך, עבור אצבע רשומה אחת.
• חובה להגביל את הקצב של יצירת הבקשות למשך 30 שניות לפחות לאחר חמש ניסיונות שווא לאימות באמצעות טביעת אצבע.
• האפליקציה חייבת להטמיע מאגר מפתחות שמגובה על ידי חומרה, ולבצע את ההתאמה של טביעת האצבע בסביבת ביצוע מהימנה (TEE) או על שבב עם ערוץ מאובטח לסביבת TEE.
• כל הנתונים של טביעות האצבע שניתן לזהות חייבים להיות מוצפנים, שעברו אימות קריפטוגרפי, כך שלא ניתן יהיה לרכוש אותם, לקרוא אותם או לשנות אותם מחוץ לסביבת הביצוע המהימנה (TEE), כפי שמתואר בהנחיות להטמעה באתר הפרויקט של קוד פתוח של Android.
• חובה למנוע הוספה של טביעת אצבע בלי ליצור קודם שרשרת אמון, באמצעות דרישה של המשתמש לאשר קיים או להוסיף פרטי כניסה חדשים למכשיר (קוד אימות/קו ביטול נעילה/סיסמה) שמאבטחים על ידי TEE. הטמעת פרויקט קוד פתוח של Android מספקת בתוך המסגרת את המנגנון לביצוע פעולה זו.
• אסור לאפשר לאפליקציות של צד שלישי להבחין בין טביעות אצבע נפרדות.
• חובה לפעול בהתאם לסימון 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_UNLIMITED כשהרכב בעצירה מלאה וחנה. יצרני המכשירים אחראים להגדיר את 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. השיחות הקוליות האלה לא בהכרח יעברו בין חבילות, אבל הן מיועדות ל-Android שנחשבות לבלתי תלויות בקישוריות נתונים שעשויות להיות מוטמעות באמצעות אותה רשת. במילים אחרות, הפונקציונליות וממשקי ה-API של Android ב-Android מתייחסים באופן ספציפי לשיחות קוליות ול-SMS. לדוגמה, באפליקציות של מכשירים שלא יכולים לבצע שיחות או לשלוח או לקבל הודעות SMS, אסור לדווח על התכונה android.hardware.telephony או על תכונות משנה כלשהן, גם אם הם משתמשים ברשת סלולרית לקישוריות נתונים.

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

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

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

• חובה להטמיע באופן מלא את BlockNumberContract ואת ה-API התואם, כפי שמתואר במסמכי התיעוד של ה-SDK.
• חובה לחסום את כל השיחות וההודעות ממספר טלפון שנמצא ב-'BlockedNumberProvider' ללא אינטראקציה עם האפליקציות. יוצא הדופן היחיד הוא כאשר חסימת המספרים מבוטלת באופן זמני, כפי שמתואר במסמכי התיעוד של ה-SDK.
• אסור לכתוב לספק יומן השיחות בפלטפורמה על שיחה שנחסמה.
• אסור לכתוב לספק הטלפוניה על הודעה חסומה.
• חובה להטמיע ממשק משתמש חסום לניהול מספרים, שנפתח באמצעות Intent שהוחזר על ידי שיטת 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 TV, גם במצב המתנה.

7.4.2.1. Wi-Fi ישיר

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

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

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

הטמעת מכשירים אמורה לכלול תמיכה בהגדרת קישור ישיר ל-Wi-Fi (TDLS), כפי שמתואר בתיעוד של Android SDK. אם הטמעת מכשיר כוללת תמיכה ב-TDLS וב-TDLS הופעל ה-API של מנהל ה-Wi-Fi, המכשיר:

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

7.4.3. ‫Bluetooth

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

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

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

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

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

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

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

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

• חובה לדווח על התכונה android.hardware.nfc באמצעות השיטה android.content.pm.PackageManager.hasSystemFeature().
• חייבת להיות יכולת לקרוא ולכתוב הודעות NDEF באמצעות תקני NFC הבאים:
  • חייבת להיות מסוגלת לפעול כקורא/כותב בפורום NFC (כפי שמוגדר במפרט הטכני NFCForum-TS-DigitalProtocol-1.0) באמצעות תקני NFC הבאים:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • סוגי התגים של פורום NFC 1, 2, 3, 4 (מוגדרים על ידי פורום NFC)
  • מומלץ מאוד להיות מסוגל לקרוא ולכתוב הודעות NDEF וכן נתונים גולמיים באמצעות תקני NFC הבאים. לתשומת ליבכם: בעוד שתקני ה-NFC הבאים מפורטים כ'מומלץ מאוד', הגדרת התאימות לגרסה עתידית מתוכננת לשנות אותם ל'חובה'. בגרסה הזו התקנים האלה הם אופציונליים, אבל הם יידרשו בגרסאות עתידיות. אנחנו ממליצים מאוד שמכשירים קיימים וחדשים שבהם פועלת הגרסה הזו של Android יעמדו בדרישות האלה עכשיו, כדי שניתן יהיה לשדרג לגרסאות עתידיות של הפלטפורמה.
    • NfcV (ISO 15693)
  • צריכה להיות יכולת לקרוא את הברקוד ואת כתובת ה-URL (אם מקודדים) של מוצרי ברקוד Thinfilm NFC.
  • חייבת להיות יכולת להעביר ולקבל נתונים באמצעות התקנים והפרוטוקולים הבאים מקצה לקצה:
    • ISO 18092
    • LLCP 1.2 (מוגדר על ידי פורום NFC)
    • SDP 1.0 (מוגדר על ידי פורום NFC)
    • פרוטוקול דחיפה מסוג NDEF
    • SNEP 1.0 (מוגדר על ידי פורום NFC)
  • חייבת לכלול תמיכה ב-Android Beam.
  • חייבים להטמיע את שרת ברירת המחדל של SNEP. הודעות NDEF חוקיות שהתקבלו בשרת SNEP כברירת מחדל חייבות להישלח לאפליקציות באמצעות ה-Intent android.nfc.ACTION_NDEF_DISCOVERED. כשמשביתים את Android Beam בהגדרות, אסור להשבית את השליחה של הודעת NDEF נכנסת.
  • חובה לפעול בהתאם לכוונה android.settings.NFCSHARING_SETTINGS להציג הגדרות שיתוף NFC.
  • חייבים להטמיע את שרת ה-NPP. העיבוד של הודעות שהתקבלו דרך שרת ה-NPP חייב להיות זהה לעיבוד של שרת ברירת המחדל של SNEP.
  • חובה להטמיע לקוח SNEP ולנסות לשלוח P2P NDEF יוצא לשרת ה-SNEP שמוגדר כברירת מחדל כש-Android Beam מופעל. אם לא נמצא שרת SNEP שמוגדר כברירת מחדל, הלקוח חייב לנסות לשלוח לשרת NPP.
  • חובה לאפשר לפעילויות בחזית להגדיר את הודעת P2P NDEF היוצאת באמצעות android.nfc.NfcAdapter.setNdefPushMessage, וגם android.nfc.NfcAdapter.setNdefPushMessageCallback ו-android.nfc.NfcAdapter.enableForegroundNdefPush.
  • צריך להשתמש בתנועה או באישור במסך, כמו 'Touch to Beam', לפני שליחה של הודעות P2P NDEF יוצאות.
  • Android Beam אמור להפעיל כברירת מחדל, ויכול להיות שתהיה לו אפשרות לשלוח ולקבל באמצעות Android Beam, גם כשמצב NFC P2p קנייני אחר מופעל.
  • חייבת לתמוך בהעברה של חיבור NFC ל-Bluetooth כאשר המכשיר תומך בפרופיל Bluetooth Object Push. הטמעת מכשירים חייבת לתמוך בהעברת החיבור ל-Bluetooth כשמשתמשים ב-android.nfc.NfcAdapter.setBeamPushUris, על ידי הטמעת המפרטים של "Connection Handover גרסה 1.2 " ו-"Bluetooth Secure Simple Pairing using NFC גרסה 1.0" מהפורום של NFC. יישום כזה חייב להטמיע את שירות LLCP המסירה עם שם השירות “urn:nfc:sn:handover” לצורך החלפה של בקשת ההעברה/בחירת רשומות ב-NFC, ועליו להשתמש בפרופיל הדחיפה לאובייקט Bluetooth כדי לבצע בפועל את העברת הנתונים מ-Bluetooth. מסיבות מדור קודם (כדי לשמור על תאימות למכשירי Android 4.1), ההטמעה עדיין אמורה לקבל בקשות SNEP GET לצורך החלפת בקשת ההעברה או הרשומות שנבחרו ב-NFC. עם זאת, היישום עצמו לא אמור לשלוח בקשות SNEP GET לביצוע מסירת חיבור.
  • חובה לבצע סקר לכל הטכנולוגיות הנתמכות במצב גילוי NFC.
  • המכשיר צריך להיות במצב גילוי NFC בזמן שהמכשיר לא במצב שינה, כשהמסך פעיל ומסך הנעילה לא נעול.

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

מערכת 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 כפי שהם מוגדרים ב-Android SDK.

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

• MIFARE קלאסי
• 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 לשנייה או יותר. דוגמאות לטכנולוגיות שעומדות בדרישה הזו: EDGE, HSPA, EV-DO, 802.11g, Ethernet, Bluetooth PAN וכו'.

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

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

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

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

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

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

הקישוריות של IPv6 חייבת להישאר במצב 'נמנום'.

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

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

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

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

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

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

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

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

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

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

• חייבת להיות פעילות שמטפלת ב-Intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, אבל יכול להיות שהיא תיושם כפעילות ללא תפעול.

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. ל-API של המצלמה ב-Android יש תמיכה ספציפית במצלמות קדמיות ובהטמעות במכשירים, אסור להגדיר את ה-API כך שיטפל במצלמה קדמית כמצלמה האחורית שמוגדרת כברירת מחדל, גם אם זו המצלמה היחידה במכשיר.
• ייתכן שיכללו תכונות (כמו מיקוד אוטומטי, פלאש וכו') הזמינות למצלמות אחוריות, כפי שמתואר בסעיף 7.5.1.
• חייבים לשקף לרוחב (כלומר, לשקף) את השידור שמוצג על ידי האפליקציה ב- CameraPreview באופן הבא:
  • אם המשתמש יכול לסובב את המכשיר שהטמעתם (למשל באופן אוטומטי באמצעות מד תאוצה או באופן ידני באמצעות קלט של משתמש), התצוגה המקדימה של המצלמה חייבת להיות משוכפלת לרוחבה ביחס לכיוון הנוכחי של המכשיר.
  • אם האפליקציה הנוכחית ביקשה באופן מפורש לבצע רוטציה של מסך המצלמה באמצעות קריאה לשיטה android.hardware.camera.setDisplayOrientation(), התצוגה המקדימה של המצלמה חייבת להיות משוכפלת לרוחב ביחס לכיוון שצוין באפליקציה.
  • אחרת, התצוגה המקדימה חייבת להיות משוכפלת לאורך הציר האופקי שמוגדר כברירת מחדל במכשיר.
• חייבת לשקף את התמונה שמופיעה ב-postview בדיוק כמו התמונה שמוצגת בתצוגה המקדימה של המצלמה. אם הטמעת המכשיר לא תומכת בתצוגה לאחר הצפייה, הדרישה הזו כמובן לא רלוונטית.
• אסור לשקף את הסטרימינג הסופי של תמונת סטילס או וידאו שחוזרים מהקריאה החוזרת לאפליקציה או שהוא התחייב לאחסון של מדיה.

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

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

• חובה להצהיר על דגל הפיצ'ר android.hardware.camera.external ו-android.hardware camera.any של הפלטפורמה .
• יכול להיות שתומכות במספר מצלמות.
• אם המצלמה החיצונית מתחברת דרך יציאת ה-USB, היא חייבת לתמוך ב-USB Video Class (UVC 1.0 ואילך).
• צריכה לתמוך בדחיסות וידאו כמו MJPEG כדי לאפשר העברה של שידורים לא מקודדים באיכות גבוהה (כלומר, סטרימינג של תמונה גולמית או שידור דחוס בנפרד).
• ייתכן שתומכת בקידוד וידאו מבוסס מצלמה. אם יש תמיכה בשידור, שאינו מקודד / MJPEG בו-זמנית (רזולוציית QVGA או יותר) חייב להיות נגיש להטמעת המכשיר.

7.5.4. התנהגות ה-API של המצלמה

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

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

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

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

בהטמעות של מכשירים עדיין חובה להטמיע את ה-מצלמה API המלא שמופיע בתיעוד של Android SDK, גם אם המכשיר כולל מיקוד אוטומטי בחומרה או יכולות אחרות. למשל, מצלמות ללא מיקוד אוטומטי חייבות עדיין לקרוא למופעים רשומים של android.hardware.camera.AutoFocusCallback (למרות שאין להם רלוונטיות למצלמה ללא מיקוד אוטומטי). חשוב לשים לב שההנחיה הזו כן חלה על מצלמות קדמיות. למשל, למרות שרוב המצלמות הקדמית לא תומכות במיקוד אוטומטי, הקריאות החוזרות של ה-API עדיין צריכות להיות "מזויפות", כפי שמתואר.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• אמורה להיות תואמת למארח MTP של Android, העברת קבצים ב-Android.
• אמור לדווח על סוג התקן USB 0x00.
• יש לדווח על שם ממשק ה-USB 'MTP'.

7.6.3. אחסון מותאם

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

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

7.7. USB

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

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

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

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

7.7.2. מצב אירוח USB

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

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

7.8. אודיו

7.8.1. מיקרופון

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

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

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

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

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

• חייבת לתמוך בהפעלת אודיו באוזניות סטריאו ובאוזניות סטריאו עם מיקרופון. בנוסף, התכונה צריכה לתמוך בהקלטת אודיו מאוזניות סטריאו עם מיקרופון.
• חייבת לתמוך בשקעי אודיו ב-TRRS עם סדר היציאה של CTIA, והיא צריכה לתמוך במחברי האודיו לפי סדר היציאה של OMTP.
• חייבת לתמוך בזיהוי מיקרופון באביזר האודיו המחובר, אם הטמעת המכשיר תומכת במיקרופון, ולשדר את android.intent.action.HEADSET_PLUG כאשר הערך הנוסף של מיקרופון מוגדר כ-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. קרוב לאולטרסאונד

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

• אם הערך של PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND הוא 'true', מקורות האודיו VOICE_RECOGNITION ו-UNProcessED צריכים לעמוד בדרישות הבאות:
  • תגובת ההספק הממוצעת של המיקרופון בתדר 18.5 kHz עד 20 kHz חייבת להיות לא יותר מ-15dB מתחת לתגובה ב- 2 kHz.
  • יחס האות הלא משוקלל לרעש של המיקרופון מעל 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.
• ייתכן שהטמעות מכשירים מספקות ליבה בלעדית לאפליקציה בחזית, ו-MAY תומכות ב-Process.getExclusiveCores API כדי להחזיר את הנתונים של ליבות המעבד (CPU) שבלעדיות לאפליקציה העליונה בחזית. אם יש תמיכה בליבה בלעדית, אסור שתהליכים אחרים במרחב המשתמשים יוכלו לפעול עליה (למעט מנהלי התקנים של מכשירים שהאפליקציה משתמשת בהם), אבל יכול להיות שהיא תאפשר הרצה של תהליכי ליבה מסוימים לפי הצורך.
• הטמעות המכשירים חייבות לתמוך במצב ביצועים טובים.
• הטמעות של מכשירים חייבות לתמוך ב-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_JPG_context_עדיפותity, ולחשוף את התוסף ברשימת תוספי ה-EGL הזמינים.
• בהטמעות של מכשירים צריך להטמיע את GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2 וגם GL_OVR_multiview_multisampled_render_to_texture ולחשוף את התוספים ברשימת התוספים הזמינים.
• בהטמעות במכשירים צריך להטמיע EGL_EXT_protect_content ו-GL_EXT_ protection_textures כדי שאפשר יהיה להשתמש בהם להפעלת וידאו עם מרקם מאובטח, ולחשוף את התוספים ברשימת התוספים הזמינים של EGL ו-GL.
• הטמעות המכשירים חייבות לתמוך בפענוח H.264 של לפחות 3840x2160@30fps-40Mbps (מקביל ל-4 מופעים של 1920x1080@30fps-10Mbps או שני מופעים של 1920x1080@60fps-20Mbps).
• הטמעות המכשיר חייבות לתמוך ב-HEVC וב-VP9. חייבות להיות מסוגלות לפענח לפחות 1920x1080@30fps-10Mbps.
• יישומי המכשיר מומלצים מאוד כדי לתמוך בתכונה android.hardware.sensor.hifi_sensors, והם חייבים לעמוד בדרישות שקשורות לג'ירוסקופ, מד התאוצה והמגנטומטר עבור android.hardware.hifi_sensors.
• הטמעות המכשירים חייבות לתמוך ב-HarwarePropertiesManager.getDeviceTemperatures API ומחזירים ערכים מדויקים של טמפרטורת העור.
• בהטמעת המכשיר חייב להיות מסך מוטמע, והרזולוציה שלו חייבת להיות לפחות FullHD(1080p) ומומלץ מאוד להיות באיכות QuadHD (1440p) ומעלה.
• המסך חייב להיות בגודל של 4.7 אינץ' ו-6 אינץ' באלכסון.
• המסך חייב להתעדכן לפחות 60 Hz במצב VR.
• זמן האחזור של התצוגה בצבעי אפור-אפור, לבן לשחור ושחור-לבן חייב להיות 3 אלפיות השנייה או פחות.
• המסך חייב לתמוך במצב של רמת התמדה נמוכה עם עקביות של 5 אלפיות השנייה או פחות. התמדה מוגדרת כמשך הזמן שבו פיקסל פולט אור.
• הטמעות של מכשירים חייבות לתמוך בהרחבה של אורך נתונים ב-Bluetooth 4.2 וב-Bluetooth LE סעיף 7.4.3.

8. ביצועים ועוצמה

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

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

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

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

8.2. ביצועים של גישת קלט/פלט לקובץ

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

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

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

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

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

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

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

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

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

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

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

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

• ההטמעות חייבות לדווח דרך שיטת ה-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 ובידוד של תהליכים

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

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

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

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

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

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

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

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

זמני ריצה חלופיים חייבים להיות תואמים למודל של ארגז החול (Sandbox) של Android. ספציפית, מדובר על זמני ריצה חלופיים:

• יש להתקין אפליקציות דרך PackageManager בארגזי חול נפרדים של Android (מזהי משתמש של Linux וכו').
• MAY תספק ארגז חול אחד של Android לכל האפליקציות שמשתמשות בסביבת זמן הריצה החלופית.
• אסור שאפליקציות שהותקנו באמצעות סביבת זמן ריצה חלופית ישתמשו שוב בארגז החול של אפליקציות אחרות שמותקנות במכשיר, אלא באמצעות המנגנונים הרגילים של 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 פרימיום יוצאות. הודעות SMS פרימיום הן הודעות טקסט שנשלחות לשירות שרשום אצל ספק סלולר והן עשויות לחייב את המשתמש. באפליקציות של מכשירים שבהן מוצהר על תמיכה ב-android.hardware.telephony חייבים להזהיר משתמשים לפני שליחה של הודעת SMS למספרים שמזוהים באמצעות ביטויים רגולריים שמוגדרים בקובץ /data/misc/sms/codes.xml במכשיר. פרויקט הקוד הפתוח של Android ב-upstream מספק הטמעה שעומדת בדרישה הזו.

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

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

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

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

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

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

• חובה להגדיר את SELinux למצב אכיפה גלובלי.
• חייבים להגדיר את כל הדומיינים במצב אכיפה. אסור להשתמש בדומיינים של מצב מתירנות, כולל דומיינים ספציפיים למכשיר או לספק.
• אסור לשנות, להשמיט או להחליף את כללי ההרשאה אף פעם שלא נמצאים בתיקיית המערכת/בתיקייה Sepolicy שהוגדרה בפרויקט קוד פתוח של Android (AOSP)
• חייבים לפצל את מסגרת המדיה למספר תהליכים, כדי שאפשר יהיה להעניק גישה לכל תהליך בצורה מצומצמת יותר כפי שמתואר באתר של פרויקט הקוד הפתוח של Android.

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

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

9.8. פרטיות

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

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

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

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

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

9.9. הצפנה של מאגר הנתונים

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

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

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

9.9.1. הפעלה ישירה

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

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

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

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

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

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

פרויקט הקוד הפתוח של Android ב-upstream מספק הטמעה מועדפת של התכונה הזו, על סמך תכונת ההצפנה בליבה (kernel) ext4 של Linux.

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

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

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

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

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

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

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

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

החל מ-Android 6.0, בהטמעות במכשירים עם תקן הצפנה מתקדם (AES), ביצועי הצפנה מעל 50MiB לשנייה חייבים לתמוך בהפעלה מאומתת לצורך שמירה על תקינות המכשיר.

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

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

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

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

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

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

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

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

• אין להתייחס לשיטת האימות כמסך נעילה מאובטח, אם היא מבוססת על סוד ידוע, אלא אם היא עומדת בכל הדרישות הבאות:
  • האנטרופיה של אורך הקלט הקצר ביותר המותר חייבת להיות גדולה מ-10 ביטים.
  • האנטרופיה המקסימלית של כל ערכי הקלט האפשריים חייבת להיות גדולה מ-18 סיביות.
  • אסור להחליף אף אחת משיטות האימות הקיימות (קוד אימות, קו ביטול נעילה, סיסמה) שהוטמעו וסופקו ב-AOSP.
  • חובה להשבית אם האפליקציה Device Policy Controller (DPC) הגדירה את המדיניות בנושא איכות סיסמאות באמצעות השיטה DevicePolicyManager.setPasswordQuality() עם איכות קבועה יותר מ-PASSWORD_QUALITY_SOMETHING .
• אין להתייחס לשיטת האימות, אם היא מבוססת על אסימון פיזי או על המיקום, כמסך נעילה מאובטח, אלא אם היא עומדת בכל הדרישות הבאות:
  • חייב להיות לו מנגנון של חזרה למצב הקודם כדי להשתמש באחת משיטות האימות הראשיות שמבוססות על סוד ידוע ועומדת בדרישות כדי להתייחס אליה כמסך נעילה מאובטח.
  • חובה להשבית אותה ולאפשר לאימות הראשי לבטל את נעילת המסך רק כשהאפליקציה 'בקר מדיניות מכשירים (DPC)' הגדירה את המדיניות באמצעות ה-method DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) או השיטה DevicePolicyManager.setPasswordQuality() שהאיכות המוגבלת שלה קבועה יותר מ-PASSWORD_QUALITY_UNSPECIFIED .
• אין להתייחס לשיטת האימות כמסך נעילה מאובטח, אם היא מבוססת על מידע ביומטרי, אלא אם היא עומדת בכל הדרישות הבאות:
  • חייב להיות לו מנגנון של חזרה למצב הקודם כדי להשתמש באחת משיטות האימות הראשיות שמבוססות על סוד ידוע ועומדת בדרישות כדי להתייחס אליה כמסך נעילה מאובטח.
  • יש להשבית אותו ולאפשר לאימות הראשי לבטל את נעילת המסך רק כאשר האפליקציה 'בקר מדיניות מכשירים (DPC)' הגדיר את מדיניות תכונת המגן על ידי קריאה לשיטה 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 (deleteData() ) (חלק מ- Android Device Administration API ) שמתואר בסעיף 3.9 Device Administration (ניהול מכשירים).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.2. מאמת CTS

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

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

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

11. תוכנות Updatable

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

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

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

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

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

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

• Docs
  שינויים קוסמטיים או שינויים שקשורים לפיתוח.

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

13. יצירת קשר

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