הגדרת תאימות ב-Android 14

1. מבוא

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

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

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

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

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

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

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

1.1 מבנה המסמך

1.1.1. דרישות לפי סוג מכשיר

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

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

1.1.2. מזהה הדרישה

מזהה הדרישה מוקצה לדרישות חובה.

• המזהה מוקצה לדרישות חובה בלבד.
• דרישות מומלצות מאוד מסומנות בתווית [SR], אבל לא מוקצה להן מזהה.
• המזהה מורכב מ : מזהה סוג המכשיר – מזהה התנאי – מזהה הדרישה (למשל, C-0-1).

כל מזהה מוגדר באופן הבא:

• מזהה סוג המכשיר (מידע נוסף זמין בקטע 2. סוגי מכשירים)
  • C: ליבה (דרישות שחלות על כל ההטמעות במכשירי Android)
  • H: מכשיר Android נייד
  • T: מכשיר Android Television
  • תשובה: הטמעה של Android Automotive
  • W: הטמעה ב-Android Watch
  • כרטיסייה: הטמעה בטאבלט Android
• מזהה תנאי
  • כשהדרישה היא ללא תנאי, המזהה הזה מוגדר כ-0.
  • כשהדרישה היא מותנית, המערכת מקצה את הערך 1 לתנאי הראשון, והמספר עולה ב-1 באותו קטע ובאותו סוג מכשיר.
• מזהה הדרישה
  • המזהה הזה מתחיל ב-1 וגדל ב-1 באותו קטע ובאותו תנאי.

1.1.3. מזהה הדרישה בקטע 2

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

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

• המזהה בקטע 2 מורכב מ: מזהה הקטע / מזהה סוג המכשיר – מזהה התנאי – מזהה הדרישה (למשל, 7.4.3/A-0-1).

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

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

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

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

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

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

2.2. דרישות למכשירים ניידים

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

הטמעות של מכשירי Android מסווגות כמכשירים ניידים אם הן עומדות בכל הקריטריונים הבאים:

• מקור כוח נייד, כמו סוללה.
• המסך צריך להיות בגודל פיזי של 4 אינץ' 3.3 אינץ' (או 2.5 אינץ' להטמעות במכשירים ששווקו עם API ברמה 29 ואילך) עד 8 אינץ'.
• יש לו ממשק קלט של מסך מגע.

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

הערה: דרישות שלא חלות על מכשירי Android Tablet מסומנות ב *.

2.2.1. חומרה

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

• [7.1.1.1/H-0-1] חייב להיות לפחות מסך אחד תואם ל-Android שעומד בכל הדרישות שמפורטות במסמך הזה. מסך שגודלו לפחות 2.2" בצד הקצר ו-3.4" בצד הארוך.

• [7.1.1.3/H-SR-1] מומלץ מאוד לספק למשתמשים אפשרות לשנות את גודל המסך (דחיסות המסך).

• [7.1.1.1/H-0-2] חובה לתמוך בהרכבה של GPU של מאגרי גרפיקה בגודל של לפחות הרזולוציה הגבוהה ביותר של כל מסך מובנה.

יצירת דרישות חדשות

• [7.1.1.1/H-0-3]* חובה למפות כל מסך UI_MODE_NORMAL שזמין לאפליקציות של צד שלישי לאזור תצוגה פיזי ללא הפרעה, בגודל של לפחות 5.6 ס"מ בצד הקצר ו-8.6 ס"מ בצד הארוך.

• [7.1.1.3/H-0-1]* חובה להגדיר את הערך של DENSITY_DEVICE_STABLE כך שיהיה 92% או יותר מהצפיפות הפיזית בפועל של המסך התואם.

סיום הדרישות החדשות

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

• [7.1.1.1/H-1-1]* חובה שהמסך הלוגי שזמין לאפליקציות של צד שלישי יהיה לפחות 5 ס"מ בצדדים הקצרים ו-7 ס"מ בצדדים הארוכים. יכול להיות שמכשירים ששווקו עם Android API ברמה 29 ואילך יהיו פטורים מהדרישה הזו.

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

• [7.1.1.1/H-2-1]* חובה שהמסך הלוגי שזמין לאפליקציות של צד שלישי יהיה לפחות 2.7 אינץ' בצדדים הקצרים. יכול להיות שמכשירים ששווקו עם Android API ברמה 29 ואילך יהיו פטורים מהדרישה הזו.

יצירת דרישות חדשות

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

• [7.1.4.2/H-1-1] חייב לעמוד בדרישות שמפורטות בפרופיל Android Baseline 2021.

סיום הדרישות החדשות

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

• [7.1.4.5/H-1-1] חובה לפרסם תמיכה בתוספים EGL_EXT_gl_colorspace_bt2020_pq,‏ EGL_EXT_surface_SMPTE2086_metadata,‏ EGL_EXT_surface_CTA861_3_metadata,‏ VK_EXT_swapchain_colorspace ו-VK_EXT_hdr_metadata.

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

• [7.1.4.6/H-0-1] חובה לדווח אם המכשיר תומך ביכולת ליצירת פרופילים של GPU באמצעות מאפיין מערכת graphics.gpu.profiler.support.

אם הטמעות של מכשירים ניידים מכריזות על תמיכה באמצעות מאפיין מערכת graphics.gpu.profiler.support, הן:

• [7.1.4.6/H-1-1] חובה לדווח כפלט על מעקב protobuf שתואם לסכימה של ספירות GPU ושל שלבי עיבוד (renderstages) של GPU שמוגדרים במסמכי העזרה של Perfetto.
• [7.1.4.6/H-1-2] חובה לדווח על ערכים תואמים למונה ה-GPU של המכשיר בהתאם ל-gpu counter trace packet proto.
• [7.1.4.6/H-1-3] חובה לדווח על ערכים תואמים של שלבי ה-Render של ה-GPU במכשיר בהתאם ל-proto של חבילות המעקב של שלבי ה-render.
• [7.1.4.6/H-1-4] חובה לדווח על נקודת מעקב של תדר GPU לפי הפורמט הבא: power/gpu_frequency.

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

• [7.1.5/H-0-1] חובה לכלול תמיכה במצב תאימות לאפליקציות מדור קודם כפי שהוטמע בקוד המקור הפתוח של Android במקור. כלומר, בהטמעות של מכשירים אסור לשנות את הטריגרים או את הסף שבו מופעל מצב התאימות, ואסור לשנות את ההתנהגות של מצב התאימות עצמו.
• [7.2.1/H-0-1] חובה לכלול תמיכה באפליקציות של צד שלישי של עורכי שיטות קלט (IME).
• [7.2.3/H-0-2] חובה לשלוח לאפליקציה שבחזית גם את האירוע הרגיל וגם את האירוע של לחיצה ארוכה על פונקציית החזרה (KEYCODE_BACK). אסור למערכת להשתמש באירועים האלה, והם יכולים להיות מופעלים מחוץ למכשיר Android (למשל, מקלדת חומרה חיצונית שמחוברת למכשיר Android).
• [7.2.3/H-0-3] חובה לספק את פונקציית דף הבית בכל המסכים התואמים ל-Android שמציגים את מסך הבית.
• [7.2.3/H-0-4] חובה לספק את הפונקציה 'הקודם' בכל המסכים התואמים ל-Android ואת הפונקציה 'פריטים אחרונים' לפחות באחד מהמסכים התואמים ל-Android.
• [7.2.4/H-0-1] חובה לתמוך בקלט במסך מגע.
• [7.2.4/H-SR-1] מומלץ מאוד להפעיל את אפליקציית העזרה שבחר המשתמש, כלומר האפליקציה שמטמיעה את VoiceInteractionService, או פעילות שמטפלת באירוע ACTION_ASSIST של לחיצה ארוכה על KEYCODE_MEDIA_PLAY_PAUSE או על KEYCODE_HEADSETHOOK, אם הפעילות בחזית לא מטפלת באירועים האלה של לחיצה ארוכה.
• [7.3.1/H-SR-1] מומלץ מאוד לכלול מד תאוצה ב-3 צירים.

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

• [7.3.1/H-1-1] חייב להיות מסוגל לדווח על אירועים עד תדירות של לפחות 100Hz.

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

• [7.3.3/H-2-1] חובה לדווח על מדידות GNSS ברגע שהן מתקבלות, גם אם עדיין לא דווח על מיקום שמחושב מ-GPS/GNSS.
• [7.3.3/H-2-2] חובה לדווח על טווחי פסאודו וקצבי פסאודו של GNSS, שבתנאי שדה פתוח אחרי שנקבע המיקום, במצב נייח או בתנועה עם פחות מ-0.2 מטר לשנייה בריבוע של תאוצה, מספיקים כדי לחשב מיקום בטווח של 20 מטרים ומהירות בטווח של 0.2 מטר לשנייה, לפחות ב-95% מהמקרים.

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

• [7.3.4/H-3-1] חייב להיות מסוגל לדווח על אירועים עד תדירות של לפחות 100Hz.
• [7.3.4/H-3-2] חייב להיות מסוגל למדוד שינויים בכיוון עד 1,000 מעלות לשנייה.

הטמעות של מכשירים ניידים שיכולים לבצע שיחה קולית ולהציג כל ערך מלבד PHONE_TYPE_NONE ב-getPhoneType:

• [7.3.8/H] צריך לכלול חיישן קרבה.

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

• [7.3.11/H-SR-1] מומלץ מאוד לתמוך בחיישני תנוחה עם 6 דרגות חופש.
• [7.4.3/H] צריכה לכלול תמיכה ב-Bluetooth וב-Bluetooth LE.

אם המכשירים תומכים בפרוטוקול WiFi Neighbor Awareness Networking ‏ (NAN) באמצעות הצהרה על PackageManager.FEATURE_WIFI_AWARE ובמיקום Wi-Fi (זמן הנסיעה הלוך ושוב ב-Wi-Fi – RTT) באמצעות הצהרה על PackageManager.FEATURE_WIFI_RTT, הם:

• [7.4.2.5/H-1-1] חובה לדווח על הטווח באופן מדויק בטווח של +/-1 מטר ברוחב פס של 160 מגה-הרץ ב-68% (כפי שמחושב באמצעות פונקציית התפלגות מצטברת), +/-2 מטר ברוחב פס של 80 מגה-הרץ ב-68%, +/-4 מטר ברוחב פס של 40 מגה-הרץ ב-68% ו-+/-8 מטר ברוחב פס של 20 מגה-הרץ ב-68% במרחקים של 10 ס"מ, 1 מטר, 3 מטר ו-5 מטר, כפי שנצפה באמצעות WifiRttManager#startRanging Android API.

• [7.4.2.5/H-SR-1] מומלץ מאוד לדווח על טווח מדויק בטווח של +/-1 מטר ברוחב פס של 160MHz ב-90% (כפי שמחושב באמצעות פונקציית התפלגות מצטברת), +/-2 מטר ברוחב פס של 80MHz ב-90%, +/-4 מטר ברוחב פס של 40MHz ב-90% ו-+/-8 מטר ברוחב פס של 20MHz ב-90% במרחק של 10 ס"מ, כפי שנצפה באמצעות WifiRttManager#startRanging Android API.

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

יצירת דרישות חדשות

אם הטמעות של מכשירים ניידים מגדירות את FEATURE_BLUETOOTH_LE, הן:

• [7.4.3/H-1-3] חובה למדוד את ההיסט של Rx ולבצע תיקון שלו כדי לוודא שהערך החציוני של RSSI ב-BLE הוא -50dBm +/-15 dB במרחק של 1 מ' ממכשיר העזרה שמשדר ב-ADVERTISE_TX_POWER_HIGH.
• [7.4.3/H-1-4] חובה למדוד את ההיסט של ה-Tx ולבצע תיקון שלו כדי לוודא שהערך החציוני של ה-RSSI ב-BLE הוא -50dBm +/-15 dB כשמבצעים סריקה ממכשיר עזר שנמצא במרחק 1 מ' ומעביר במהירות ADVERTISE_TX_POWER_HIGH.

סיום הדרישות החדשות

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

• ל-[7.5.4/H-1-1] חייב להיות שדה ראייה (FOV) רגיל כברירת מחדל, והוא חייב להיות בין 50 ל-90 מעלות.

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

• [7.6.1/H-0-1] חייב להיות לפחות 4GB של אחסון לא נדיף שזמין לנתונים הפרטיים של האפליקציה (כלומר, מחיצה '/data').
• [7.6.1/H-0-2] חובה להחזיר את הערך 'true' עבור ActivityManager.isLowRamDevice() כשיש פחות מ-1GB של זיכרון שזמין לליבה ולמרחב המשתמש.

אם הטמעות של מכשירים ניידים מכריזות על תמיכה רק ב-ABI של 32 ביט:

• [7.6.1/H-1-1] אם ברזולוציות של מסך ברירת המחדל נעשה שימוש ב-framebuffer עד qHD (למשל FWVGA), נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 416MB.

• [7.6.1/H-2-1] אם ברזולוציות של מסך ברירת המחדל נעשה שימוש ב-framebuffer עד HD+ (למשל, HD,‏ WSVGA), נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 592MB.

• [7.6.1/H-3-1] אם ברזולוציות של framebuffer של צג ברירת המחדל נעשה שימוש עד FHD (למשל, WSXGA+), נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 896MB.

• [7.6.1/H-4-1] אם ברזולוציית המסך שמוגדרת כברירת מחדל נעשה שימוש ברזולוציות של framebuffer עד QHD (למשל QWXGA), נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 1,344MB.

אם הטמעות של מכשירי כף יד מכריזות על תמיכה ב-ABI כלשהו של 64 ביט (עם או בלי ABI של 32 ביט):

• [7.6.1/H-5-1] אם ברזולוציית ברירת המחדל של המסך נעשה שימוש ברזולוציות של framebuffer עד qHD (למשל FWVGA), נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 816MB.

• [7.6.1/H-6-1] אם ברזולוציות של מסך ברירת המחדל נעשה שימוש ב-framebuffer עד HD+‏ (למשל, HD,‏ WSVGA), נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 944MB.

• [7.6.1/H-7-1] אם ברזולוציות של framebuffer של צג ברירת המחדל נעשה שימוש ברזולוציות של עד FHD (למשל, WSXGA+), נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 1,280MB.

• [7.6.1/H-8-1] אם ברזולוציות של מסך ברירת המחדל נעשה שימוש ברזולוציות של framebuffer עד QHD (למשל QWXGA), נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 1,824MB.

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

אם הטמעות במכשירים ניידים כוללות פחות מ-1GB של זיכרון שזמין לליבה ולמרחב המשתמש, הן:

• [7.6.1/H-9-1] חובה להצהיר על דגל התכונה android.hardware.ram.low.
• [7.6.1/H-9-2] חייב להיות לפחות 1.1GB של אחסון לא נדיף לנתונים פרטיים של האפליקציה (המכונה גם מחיצה '/data').

אם הטמעות של מכשירים ניידים כוללות יותר מ-1GB של זיכרון שזמין לליבה ולמרחב המשתמש, הן:

• [7.6.1/H-10-1] חייב להיות לפחות 4GB של אחסון לא נדיף שזמין לנתונים הפרטיים של האפליקציה (נקרא גם מחיצה '/data').
• צריך להצהיר על דגל התכונה android.hardware.ram.normal.

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

• [7.6.1/H-SR-1] מומלץ מאוד לתמוך רק במרחב משתמש של 32 ביט (גם אפליקציות וגם קוד מערכת)

אם הטמעות במכשירים ניידים כוללות פחות מ-2GB של זיכרון שזמין לליבה ולמרחב המשתמש, הן:

• [7.6.1/H-1-1] חובה לתמוך רק בממשק ABI אחד (64 ביט בלבד או 32 ביט בלבד).

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

• [7.6.2/H-0-1] אסור לספק לאפליקציה אחסון משותף בנפח קטן מ-1GB.
• [7.7.1/H] צריכה לכלול יציאת USB שתומכת במצב ציוד היקפי.

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

• [7.7.1/H-1-1] חובה להטמיע את ה-API של Android Open Accessory‏ (AOA).

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

• [7.7.2/H-1-1] חובה להטמיע את הקלאס של אודיו USB כפי שמתואר במסמכים של Android SDK.

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

• [7.8.1/H-0-1] חובה לכלול מיקרופון.
• [7.8.2/H-0-1] חייב לכלול פלט אודיו ולהצהיר על android.hardware.audio.output.

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

• [7.9.1/H-1-1] חובה להצהיר על ה-feature flag‏ android.hardware.vr.high_performance.
• [7.9.1/H-1-2] חובה לכלול אפליקציה שמטמיעה את android.service.vr.VrListenerService, שאפשר להפעיל אותה באמצעות אפליקציות VR דרך android.app.Activity#setVrModeEnabled.

אם הטמעות של מכשירים ניידים כוללות יציאת USB-C אחת או יותר במצב מארח ומטמיעות (USB audio class), בנוסף לדרישות שמפורטות בקטע 7.7.2, הן:

• [7.8.2.2/H-1-1] חובה לספק את המיפוי הבא של קודי HID בתוכנה:

פעולה	מיפויים	הקשר	התנהגות
A	דף השימוש ב-HID: 0x0C שימוש ב-HID: 0x0CD מפתח הליבה: KEY_PLAYPAUSE מפתח Android: KEYCODE_MEDIA_PLAY_PAUSE	הפעלת מדיה	קלט: לחיצה קצרה פלט: הפעלה או השהיה
			קלט: לחיצה ארוכה פלט: הפעלת פקודה קולית שליחה:android.speech.action.VOICE_SEARCH_HANDS_FREE אם המכשיר נעול או שהמסך שלו כבוי. אחרת, android.speech.RecognizerIntent.ACTION_WEB_SEARCH
		שיחה נכנסת	קלט: לחיצה קצרה פלט: קבלת שיחה
			קלט: לחיצה ארוכה פלט: דחייה של שיחה
		שיחה פעילה	קלט: לחיצה קצרה פלט: סיום השיחה
			קלט: לחיצה ארוכה פלט: השתקה או ביטול השתקה של המיקרופון
B	דף השימוש ב-HID: 0x0C שימוש ב-HID: 0x0E9 מפתח הליבה: KEY_VOLUMEUP מפתח Android: VOLUME_UP	הפעלת מדיה, שיחה פעילה	קלט: לחיצה קצרה או לחיצה ארוכה פלט: הגברת עוצמת הקול של המערכת או של אוזניות
C	דף השימוש ב-HID: 0x0C שימוש ב-HID: 0x0EA מפתח הליבה: KEY_VOLUMEDOWN מפתח Android: VOLUME_DOWN	הפעלת מדיה, שיחה פעילה	קלט: לחיצה קצרה או לחיצה ארוכה פלט: הפחתת עוצמת הקול במערכת או באוזניות
D	דף השימוש ב-HID: 0x0C שימוש ב-HID: 0x0CF מפתח הליבה: KEY_VOICECOMMAND מפתח Android: KEYCODE_VOICE_ASSIST	כל ההתראות. אפשר להפעיל אותו בכל מכונה.	קלט: לחיצה קצרה או לחיצה ארוכה פלט: הפעלת פקודה קולית

• [7.8.2.2/H-1-2] חובה להפעיל את ACTION_HEADSET_PLUG כשמחברים את המחבר, אבל רק אחרי שמספרים את ממשקי האודיו והקצוות הנקודתיים של ה-USB בצורה נכונה כדי לזהות את סוג המסוף המחובר.

כשמזוהה מסוף אודיו מסוג USB עם הקוד 0x0302, הם:

• [7.8.2.2/H-2-1] חובה לשדר את ה-Intent ACTION_HEADSET_PLUG עם הערך הנוסף 'microphone' מוגדר ל-0.

כשמתבצעת זיהוי של מסוף אודיו מסוג USB‏ 0x0402, הוא:

• [7.8.2.2/H-3-1] חובה לשדר את ה-Intent‏ ACTION_HEADSET_PLUG עם הערך הנוסף 'microphone' שמוגדר כ-1.

כשמתבצעת קריאה ל-API AudioManager.getDevices() בזמן שהציוד ההיקפי של ה-USB מחובר, מתבצעות הפעולות הבאות:

• [7.8.2.2/H-4-1] חובה לציין מכשיר מסוג AudioDeviceInfo.TYPE_USB_HEADSET ותפקיד isSink() אם השדה של סוג מסוף האודיו ב-USB הוא 0x0302.

• [7.8.2.2/H-4-2] חובה לציין מכשיר מסוג AudioDeviceInfo.TYPE_USB_HEADSET עם התפקיד isSink() אם השדה של סוג מסוף האודיו ב-USB הוא 0x0402.

• [7.8.2.2/H-4-3] חובה לציין מכשיר מסוג AudioDeviceInfo.TYPE_USB_HEADSET עם התפקיד isSource() אם השדה של סוג מסוף האודיו ב-USB הוא 0x0402.

• [7.8.2.2/H-4-4] חובה לציין מכשיר מסוג AudioDeviceInfo.TYPE_USB_DEVICE ותפקיד isSink() אם השדה של סוג מסוף האודיו ב-USB הוא 0x603.

• [7.8.2.2/H-4-5] חובה לציין מכשיר מסוג AudioDeviceInfo.TYPE_USB_DEVICE ו-role isSource() אם השדה של סוג מסוף האודיו ב-USB הוא 0x604.

• [7.8.2.2/H-4-6] חובה לציין מכשיר מסוג AudioDeviceInfo.TYPE_USB_DEVICE עם התפקיד isSink() אם השדה של סוג מסוף האודיו ב-USB הוא 0x400.

• [7.8.2.2/H-4-7] חובה לציין מכשיר מסוג AudioDeviceInfo.TYPE_USB_DEVICE עם התפקיד isSource() אם השדה של סוג מסוף האודיו ב-USB הוא 0x400.

• [7.8.2.2/H-SR-1] מומלץ מאוד לבצע ספירה של מתארי USB, לזהות סוגי מסופים ולשדר את ה-Intent ACTION_HEADSET_PLUG תוך פחות מ-1, 000 אלפיות שנייה כשמחברים ציוד היקפי של אודיו מסוג USB-C.

אם הטמעות של מכשירי כף יד מגדירות את android.hardware.audio.output ו-android.hardware.microphone, הן:

• [5.6/H-1-1] זמן האחזור הממוצע הרציף של נתונים הלוך ושוב חייב להיות 300 אלפיות השנייה או פחות ב-5 מדידות, עם סטייה ממוצעת אבסולוטית של פחות מ-30 אלפיות השנייה, בנתיבי הנתונים הבאים: 'רמקול למיקרופון', מתאם לולאה חוזרת 3.5 מ"מ (אם יש תמיכה) ולולאה חוזרת USB (אם יש תמיכה).

• [5.6/H-1-2] זמן האחזור הממוצע של הקשה ליצירת צליל חייב להיות 300 אלפיות שנייה או פחות ב-5 מדידות לפחות בנתיב הנתונים מהרמקול למיקרופון.

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

• [7.10/H]* אסור להשתמש במפעיל (רטט) חאפטיק מסוג מסה מסתובבת חריגה (ERM).
• [7.10/H]* צריך להטמיע את כל הקבועים הציבוריים של רטט ברור ב-android.view.HapticFeedbackConstants, כלומר (CLOCK_TICK,‏ CONTEXT_CLICK,‏ KEYBOARD_PRESS,‏ KEYBOARD_RELEASE,‏ KEYBOARD_TAP,‏ LONG_PRESS,‏ TEXT_HANDLE_MOVE,‏ VIRTUAL_KEY,‏ VIRTUAL_KEY_RELEASE,‏ CONFIRM,‏ REJECT,‏ GESTURE_START ו-GESTURE_END).
• [7.10/H]* צריך להטמיע את כל הקבועים הציבוריים של רטט ברור ב-android.os.VibrationEffect, כלומר (EFFECT_TICK,‏ EFFECT_CLICK,‏ EFFECT_HEAVY_CLICK ו-EFFECT_DOUBLE_CLICK), ואת כל הקבועים הציבוריים האפשריים של PRIMITIVE_* לרטט עשיר ב-android.os.VibrationEffect.Composition, כלומר (CLICK,‏ TICK,‏ LOW_TICK,‏ QUICK_FALL,‏ QUICK_RISE,‏ SLOW_RISE,‏ SPIN ו-THUD). חלק מהפעולות הבסיסיות האלה, כמו LOW_TICK ו-SPIN, יכולות להתבצע רק אם הוויברטור יכול לתמוך בתדרים נמוכים יחסית.
• [7.10/H]* צריך לפעול לפי ההנחיות למיפוי של קבועים ציבוריים ב-android.view.HapticFeedbackConstants לקבועים המומלצים של android.os.VibrationEffect, עם יחסי האמפליטודה המתאימים.
• [7.10/H]* צריך לפעול בהתאם לבדיקת האיכות של ממשקי ה-API createOneShot()‎ ו-createWaveform()‎.
• [7.10/H]* צריך לוודא שהתוצאה של ממשק ה-API הציבורי android.os.Vibrator.hasAmplitudeControl() משקפת בצורה נכונה את היכולות של הוויברטור.
• [7.10/H]* צריך למקם את המפעיל ליד המיקום שבו המכשיר בדרך כלל מוחזק או נגע בו בידיים.

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

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

יצירת דרישות חדשות

• [7.10/H] מומלץ למקם את המפעיל ליד המיקום שבו המכשיר בדרך כלל מוחזק או נגע בו בידיים.

סיום הדרישות החדשות

• [7.10/H] יש להזיז את המפעיל החשמלי של האפקט הרטט בציר X (שמאל-ימין) של הכיוון הטבעי לאורך של המכשיר.

אם להטמעות של מכשירים ניידים יש מפעיל חישה כללי שהוא מפעיל תהוד לינארי בציר X (LRA), הן:

• [7.10/H] התדר הרטט של LRA בציר X צריך להיות מתחת ל-200Hz.

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

• [7.10/H]* צריך לאמת את סטטוס ההטמעה על ידי הפעלת ממשקי ה-API‏ android.os.Vibrator.areAllEffectsSupported() ו-android.os.Vibrator.arePrimitivesSupported().

• [7.10/H]* צריך לבצע בדיקת איכות של קבועים של משוב מישוש.

• [7.10/H]* צריך לאמת ולעדכן, אם צריך, את הגדרת ברירת המחדל לפרימיטיבים שלא נתמכים, כפי שמתואר בהנחיות להטמעה של קבועים.

2.2.2. מולטימדיה

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

• [5.1/H-0-1] AMR-NB
• [5.1/H-0-2] AMR-WB
• [5.1/H-0-3] MPEG-4 AAC Profile‏ (AAC LC)
• [5.1/H-0-4] MPEG-4 HE AAC Profile‏ (AAC+)
• [5.1/H-0-5] AAC ELD (‏AAC משופר עם זמן אחזור קצר)

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

• [5.2/H-0-1] H.264 AVC
• [5.2/H-0-2] VP8

יצירת דרישות חדשות

• [5.2/H-0-3] AV1

סיום הדרישות החדשות

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

• [5.3/H-0-1] H.264 AVC
• [5.3/H-0-2] H.265 HEVC
• [5.3/H-0-3] MPEG-4 SP
• [5.3/H-0-4] VP8
• [5.3/H-0-5] VP9

יצירת דרישות חדשות

• [5.3/H-0-6] AV1

סיום הדרישות החדשות

2.2.3. תוכנות

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

• [3.2.3.1/H-0-1] חובה שתהיה אפליקציה שמטפלת בכוונות (intents) ACTION_GET_CONTENT,‏ ACTION_OPEN_DOCUMENT,‏ ACTION_OPEN_DOCUMENT_TREE ו-ACTION_CREATE_DOCUMENT כפי שמתואר במסמכי ה-SDK, ומספקת למשתמש אפשרות לגשת לנתונים של ספק המסמכים באמצעות ה-API של DocumentsProvider.
• [3.2.3.1/H-0-2]* חובה לטעון מראש אפליקציה אחת או יותר או רכיבי שירות עם טיפול ב-Intent, לכל דפוסי המסננים הציבוריים של ה-Intent שמוגדרים על ידי כוונות האפליקציה הבאות שמפורטות כאן.
• [3.2.3.1/H-SR-1] מומלץ מאוד לטעון מראש אפליקציית אימייל שיכולה לטפל בכוונות ACTION_SENDTO או ACTION_SEND או ACTION_SEND_MULTIPLE לשליחת אימייל.
• [3.4.1/H-0-1] חובה לספק הטמעה מלאה של ה-API של android.webkit.Webview.
• [3.4.2/H-0-1] חובה לכלול אפליקציית דפדפן נפרדת לגלישה באינטרנט של משתמשים רגילים.
• [3.8.1/H-SR-1] מומלץ מאוד להטמיע מרכז אפליקציות שמוגדר כברירת מחדל ותומך בהצמדה של קיצורי דרך, ווידג'טים ו-widgetFeatures בתוך האפליקציה.
• [3.8.1/H-SR-2] מומלץ מאוד להטמיע מרכז אפליקציות שמספק גישה מהירה למקשי הקיצור הנוספים שסופקו על ידי אפליקציות צד שלישי באמצעות ה-API של ShortcutManager.
• [3.8.1/H-SR-3] מומלץ מאוד לכלול אפליקציית מרכז אפליקציות שמוגדרת כברירת מחדל ומציגה תגים לסמלי האפליקציות.
• [3.8.2/H-SR-1] מומלץ מאוד לתמוך בווידג'טים של אפליקציות צד שלישי.
• [3.8.3/H-0-1] חובה לאפשר לאפליקציות צד שלישי להודיע למשתמשים על אירועים משמעותיים באמצעות כיתות ה-API Notification ו-NotificationManager.
• [3.8.3/H-0-2] חובה לתמוך בהתראות עשירות.
• [3.8.3/H-0-3] חובה לתמוך בהתראות מראש.
• [3.8.3/H-0-4] חובה לכלול חלונית התראות, שמאפשרת למשתמש לשלוט ישירות בהתראות (למשל, להשיב, לדחות לזמן מה, לסגור או לחסום) באמצעות רכיבי ממשק משתמש כמו לחצני פעולה או לוח הבקרה כפי שהוטמע ב-AOSP.
• [3.8.3/H-0-5] חובה להציג את האפשרויות שסופקו דרך RemoteInput.Builder setChoices() בחלונית ההתראות.
• [3.8.3/H-SR-1] מומלץ מאוד להציג את האפשרות הראשונה שצוינה באמצעות RemoteInput.Builder setChoices() בחלונית ההתראות, ללא אינטראקציה נוספת של המשתמש.
• [3.8.3/H-SR-2] מומלץ מאוד להציג את כל האפשרויות שמוצגות דרך RemoteInput.Builder setChoices() בלוח ההתראות כשהמשתמש מרחב את כל ההתראות בלוח ההתראות.
• [3.8.3.1/H-SR-1] מומלץ מאוד להציג פעולות ש-Notification.Action.Builder.setContextual מוגדר בהן כ-true, בהתאם לתשובות שמוצגות על ידי Notification.Remoteinput.Builder.setChoices.
• [3.8.4/H-SR-1] מומלץ מאוד להטמיע עוזרת במכשיר כדי לטפל בפעולת העזרה.

אם הטמעות במכשירים ניידים תומכות בהתראות בסגנון MediaStyle, הן:

• [3.8.3.1/H-SR-2] מומלץ מאוד לספק למשתמשים אמצעי נוח (למשל, מתג פלט) שניתן לגשת אליו דרך ממשק המשתמש של המערכת, שמאפשר למשתמשים לעבור בין מסלולי מדיה זמינים מתאימים (למשל, מכשירי Bluetooth ומסלולים שסופקו ל-MediaRouter2Manager) כשאפליקציה מפרסמת התראה MediaStyle עם אסימון MediaSession.

יצירת דרישות חדשות

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

• [3.8.3/H-1-1] חובה להטמיע את ההתנהגות של הקפאת המסך ולספק למשתמש תפריט הגדרות כדי להפעיל או להשבית את התכונה.

סיום הדרישות החדשות

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

• [3.8.4/H-SR-2] מומלץ מאוד להשתמש בהקשה ארוכה על המקש HOME כאינטראקציה הייעודית להפעלת אפליקציית העזרה, כפי שמתואר בקטע 7.2.3. חייבת להפעיל את אפליקציית העזרה שבחר המשתמש, כלומר האפליקציה שמטמיעה את VoiceInteractionService, או פעילות שמטפלת ב-Intent‏ ACTION_ASSIST.

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

• [3.8.4/H-1-1]* חובה להציג התראות על שיחות לפני התראות אחרות, מלבד התראות על שירותים שפועלים בחזית והתראות importance:high.

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

• [3.8.10/H-1-1] חובה להציג את ההתראות במסך הנעילה, כולל תבנית ההתראות של המדיה.

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

• [3.9/H-1-1] חובה להטמיע את כל המדיניות של ניהול המכשיר שמוגדרת במסמכי התיעוד של Android SDK.

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

• [3.8.16/H-1-1] חובה להצהיר על דגל התכונה android.software.controls ולהגדיר אותו כ-true.
• [3.8.16/H-1-2] חובה לספק למשתמש אפשרות להוסיף, לערוך, לבחור ולהפעיל את אמצעי הבקרה המועדפים עליו במכשיר, מתוך אמצעי הבקרה שרשומים באפליקציות של צד שלישי דרך ממשקי ה-API ControlsProviderService ו-Control.
• [3.8.16/H-1-3] חובה לספק גישה לאפשרות הזו של המשתמש תוך שלוש אינטראקציות ממרכז האפליקציות שמוגדר כברירת מחדל.

• [3.8.16/H-1-4] חובה להציג בצורה מדויקת בממשק המשתמש הזה את השם והסמל של כל אפליקציית צד שלישי שמספקת אמצעי בקרה דרך ה-API של ControlsProviderService, וכן את כל השדות שצוינו על ידי ממשקי ה-API של Control.

• [3.8.16/H-1-5] חובה לספק למשתמש אפשרות לבטל את ההסכמה לשימוש באמצעי בקרה על מכשירים שנועדו לאימות טריוויאלי של אפליקציות, מתוך אמצעי הבקרה שנרשמו על ידי אפליקציות הצד השלישי דרך ControlsProviderService ו-Control.isAuthRequired API של Control.

יצירת דרישות חדשות

• [3.8.16/H-1-6] הטמעות במכשירים חייבות להציג את היכולת של המשתמש בצורה מדויקת באופן הבא:
  • אם במכשיר מוגדר config_supportsMultiWindow=true והאפליקציה מצהירה על המטא-נתונים META_DATA_PANEL_ACTIVITY בהצהרה ControlsProviderService, כולל ComponentName של פעילות חוקית (כפי שמוגדרת ב-API), האפליקציה חייבת להטמיע את הפעילות הזו בממשק המשתמש הזה.
  • אם האפליקציה לא מצהירה על מטא-נתונים META_DATA_PANEL_ACTIVITY, היא חייבת להציג את השדות שצוינו כפי שסופקו על ידי ממשק ה-API ControlsProviderService, וגם את כל השדות שצוינו כפי שסופקו על ידי ממשקי ה-API של Control.
• [3.8.16/H-1-7] אם האפליקציה מצהירה על המטא-נתונים META_DATA_PANEL_ACTIVITY, היא חייבת להעביר את הערך של ההגדרה שמוגדרת בקטע [3.8.16/H-1-5] באמצעות EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS כשמפעילים את הפעילות המוטמעת.

סיום הדרישות החדשות

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

• [3.8.16/H-2-1] חובה לדווח על null עבור ממשקי ה-API של ControlsProviderService ושל Control.
• [3.8.16/H-2-2] חובה להצהיר על דגל התכונה android.software.controls ולהגדיר אותו ל-false.

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

• [3.8.17/H-1-1] חובה להציג למשתמש אישור על כך שהנתונים הועתקו ללוח העריכה (למשל, תמונה ממוזערת או התראה עם הכיתוב 'התוכן הועתק'). בנוסף, יש לציין כאן אם נתוני הלוח יסונכרנו בין מכשירים.

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

• [3.10/H-0-1] חובה לתמוך בשירותי נגישות של צד שלישי.
• [3.10/H-SR-1] מומלץ מאוד לטעון מראש במכשיר שירותי נגישות שדומים לשירותי הנגישות של TalkBack ו'גישה באמצעות מתג' (בשפות שנתמכות במנוע ההמרה מראש של טקסט לדיבור), או שירותי נגישות עם פונקציונליות טובה יותר, כפי שמפורט בפרויקט הקוד הפתוח של TalkBack.
• [3.11/H-0-1] חובה לתמוך בהתקנה של מנועי TTS של צד שלישי.
• [3.11/H-SR-1] מומלץ מאוד לכלול מנוע TTS שתומך בשפות הזמינות במכשיר.
• [3.13/H-SR-1] מומלץ מאוד לכלול רכיב של ממשק משתמש של הגדרות מהירות.

אם הטמעות של מכשירי Android ניידים מכריזות על תמיכה ב-FEATURE_BLUETOOTH או ב-FEATURE_WIFI, הן:

• [3.16/H-1-1] חובה לתמוך בתכונה של התאמת מכשיר נלווה.

אם פונקציית הניווט מוצגת כפעולה מבוססת-תנועה במסך:

• [7.2.3/H] אזור זיהוי התנועות של הפונקציה 'דף הבית' צריך להיות בגובה של עד 32dp מתחת לתחתית המסך.

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

• [7.2.3/H-0-1] רוחב אזור התנועות של פונקציית הניווט חייב להיות פחות מ-40dp בכל צד. כברירת מחדל, רוחב אזור התנועות צריך להיות 24dp.

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

• [3.9/H-1-2] חובה להצהיר על תמיכה בפרופילים מנוהלים באמצעות דגל התכונה android.software.managed_users.

אם הטמעות של מכשירי Android ניידים מכריזות על תמיכה במצלמה באמצעות android.hardware.camera.any, הן:

• [7.5.4/H-1-1] חובה לפעול בהתאם לכוונה android.media.action.STILL_IMAGE_CAMERA וandroid.media.action.STILL_IMAGE_CAMERA_SECURE ולהפעיל את המצלמה במצב תמונה סטילס כפי שמתואר ב-SDK.
• [7.5.4/H-1-2] חובה לפעול בהתאם לכוונה של android.media.action.VIDEO_CAMERA להפעיל את המצלמה במצב וידאו, כפי שמתואר ב-SDK.

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

• [3.2.3.1/ H-1-1] חייבת להיות פעילות שמטפלת בכוונה Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY כשפונקציונליות הפיצול מופעלת. חובה להגן על הפעילות באמצעות android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK, והיא חייבת להפעיל את הפעילות של ה-Intent שעבר ניתוח מ-Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.

יצירת דרישות חדשות

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

• [7.4.1.2/H-0-1] חובה להצהיר על דגל התכונה android.software.telecom.
• [7.4.1.2/H-0-2] חובה להטמיע את מסגרת התקשורת.

סיום הדרישות החדשות

2.2.4. ביצועים וצריכת חשמל

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

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

• [8.2/H-0-1] חובה להבטיח ביצועי כתיבה רצופים של לפחות 5MB/s.
• [8.2/H-0-2] חובה להבטיח ביצועי כתיבה אקראיים של לפחות 0.5MB/s.
• [8.2/H-0-3] חובה להבטיח ביצועי קריאה רציפים של לפחות 15MB/s.
• [8.2/H-0-4] חובה להבטיח ביצועי קריאה אקראית של לפחות 3.5MB/s.

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

• [8.3/H-1-1] חובה לספק למשתמש אפשרות להפעיל ולהשבית את התכונה 'חיסכון בסוללה'.
• [8.3/H-1-2] חובה לספק למשתמשים אפשרות להציג את כל האפליקציות שפטורות ממצבי חיסכון באנרגיה 'המתנה לאפליקציה' ו'שינה עמוקה'.

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

• [8.4/H-0-1] חובה לספק פרופיל צריכת אנרגיה לכל רכיב, שמגדיר את ערך הצריכה הנוכחית של כל רכיב חומרה ואת הירידה המשוערת בנפח הסוללה שנגרמת על ידי הרכיבים לאורך זמן, כפי שמופיע באתר של Android Open Source Project.
• [8.4/H-0-2] חובה לדווח על כל ערכי צריכת האנרגיה בשעות מיליאמפר (mAh).
• [8.4/H-0-3] חובה לדווח על צריכת החשמל של המעבד לכל מזהה משתמש (UID) של תהליך. פרויקט הקוד הפתוח של Android עומד בדרישות באמצעות הטמעת מודול הליבה uid_cputime.
• [8.4/H-0-4] חייבים להפוך את צריכת האנרגיה הזו לזמינה למפתח האפליקציה באמצעות הפקודה adb shell dumpsys batterystats במעטפת.
• [8.4/H] צריך לשייך לרכיב החומרה עצמו אם לא ניתן לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.

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

• [8.4/H-1-1] חובה לפעול בהתאם לכוונה של android.intent.action.POWER_USAGE_SUMMARY ולהציג תפריט הגדרות שבו מוצג השימוש בחשמל.

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

• [8.5/H-0-1] חובה לספק למשתמש בתפריט ההגדרות אפשרות לראות את כל האפליקציות עם שירותי חזית פעילים או משימות שהמשתמש יזם, כולל משך הזמן של כל אחד מהשירותים האלה מאז שהתחיל, כפי שמתואר במסמך ה-SDK. וגם את היכולת להפסיק אפליקציה שמפעילה שירות חזית ולהציג את כל האפליקציות עם שירותי חזית פעילים ואת משך הזמן של כל אחד מהשירותים האלה מאז שהתחיל, כפי שמתואר במסמך ה-SDK.
  • יכול להיות שחלק מהאפליקציות לא יושהו או יופיעו באפשרות כזו של משתמש, כפי שמתואר במסמך ה-SDK.

יצירת דרישות חדשות

• [8.5/H-0-2]חובה לספק למשתמשים אפשרות להפסיק אפליקציה שמפעילה שירות שפועל בחזית או משימה שהמשתמש יזם.

סיום הדרישות החדשות

2.2.5. מודל אבטחה

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

• [9/H-0-1] חובה להצהיר על התכונה android.hardware.security.model.compatible.
• [9.1/H-0-1] חובה לאפשר לאפליקציות צד שלישי לגשת לנתונים הסטטיסטיים של השימוש באמצעות ההרשאה android.permission.PACKAGE_USAGE_STATS, ולספק מנגנון שזמין למשתמשים כדי להעניק או לבטל גישה לאפליקציות כאלה בתגובה לכוונה android.settings.ACTION_USAGE_ACCESS_SETTINGS.

יצירת דרישות חדשות

אם הטמעות במכשירים מצהירות על תמיכה ב-android.hardware.telephony, הן:

• [9.5/H-1-1] אסור להגדיר את UserManager.isHeadlessSystemUserMode כ-true.

סיום הדרישות החדשות

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

• [9.11/H-0-2] חובה לגבות את הטמעת מאגר המפתחות באמצעות סביבת הפעלה מבודדת.
• [9.11/H-0-3] חובה שתהיה הטמעה של אלגוריתמים קריפטוגרפיים מסוג RSA,‏ AES,‏ ECDSA ו-HMAC ופונקציות גיבוב ממשפחת MD5,‏ SHA1 ו-SHA-2 כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בליבה ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד הליבה או קוד מרחב המשתמש עשוי לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. בפרויקט Android Open Source (AOSP) ב-upstream מתקיימים הדרישות האלה באמצעות ההטמעה של Trusty, אבל יש גם אפשרויות חלופיות: פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת של בידוד תקין שמבוסס על hypervisor, שעבר בדיקה על ידי צד שלישי.
• [9.11/H-0-4] חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק אם הוא מצליח, לאפשר שימוש במפתחות שמקושרים לאימות. חובה לאחסן את פרטי הכניסה של מסך הנעילה באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. בפרויקט הקוד הפתוח של Android תוכלו למצוא את שכבת האובייקטים המצומצמים לחומרה (HAL) של Gatekeeper ו-Trusty, שאפשר להשתמש בהם כדי לעמוד בדרישות האלה.
• [9.11/H-0-5] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה לאימות מוגן על ידי חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה לאימות במספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת מהדרכים לעמוד בדרישות האלה היא לשתף את אותו מפתח אימות, אלא אם מיוצרות לפחות 100,000 יחידות של מק"ט נתון. אם מיוצרות יותר מ-100,000 יחידות של מק"ט מסוים, יכול להיות שייעשה שימוש במפתח שונה לכל 100,000 יחידות.

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

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

• [9.11/H-1-1] חובה לאפשר למשתמש לבחור את זמן הקצוב הקצר ביותר למצב שינה, כלומר זמן המעבר ממצב פתוח למצב נעול, של 15 שניות או פחות.
• [9.11/H-1-2] חובה לספק למשתמש אפשרות להסתיר התראות ולהשבית את כל סוגי האימות, מלבד האימות הראשי שמתואר בקטע 9.11.1 מסך נעילה מאובטח. גרסת AOSP עומדת בדרישות כמצב נעילה.

יצירת דרישות חדשות

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

• [9.11.1/H-1-1] חובה לאתגר את המשתמש באחת משיטות האימות הראשיות המומלצות (למשל: קוד אימות, קו ביטול נעילה, סיסמה) בתדירות גבוהה יותר מפעם ב-72 שעות.

סיום הדרישות החדשות

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

• [9.5/H-2-1] חובה לתמוך בפרופילים מוגבלים, תכונה שמאפשרת לבעלי המכשיר לנהל משתמשים נוספים ואת היכולות שלהם במכשיר. בעזרת פרופילים מוגבלים, בעלי המכשירים יכולים להגדיר במהירות סביבות נפרדות למשתמשים נוספים, ולנהל הגבלות מפורטות יותר על האפליקציות שזמינות בסביבות האלה.

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

• [9.5/H-3-1] אסור לתמוך בפרופילים מוגבלים, אבל חובה להתאים את ההטמעה של אמצעי הבקרה ב-AOSP כדי לאפשר או להשבית למשתמשים אחרים גישה לשיחות הקוליות ולהודעות ה-SMS.

יצירת דרישות חדשות

אם בהטמעות של מכשירים ניידים מוגדר הערך UserManager.isHeadlessSystemUserMode ל-true,

• [9.5/H-4-1] אסור לכלול תמיכה בכרטיסי eUICC או בכרטיסי eSIM עם יכולת להתקשר.
• [9.5/H-4-2] אסור להצהיר על תמיכה ב-android.hardware.telephony.

סיום הדרישות החדשות

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

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

• [9.8/H-1-1] חובה לוודא ששירות זיהוי מילות המפתח יכול להעביר נתונים רק למערכת, ל-ContentCaptureService, או לשירות זיהוי הדיבור במכשיר שנוצר על ידי SpeechRecognizer#createOnDeviceSpeechRecognizer().
• [9.8/H-1-2] חובה לוודא ששירות זיהוי מילות המפתח יכול להעביר לשרת המערכת רק נתוני אודיו מהמיקרופ או נתונים שמבוססים עליהם, דרך API של HotwordDetectionService, או ל-ContentCaptureService דרך API של ContentCaptureManager.
• [9.8/H-1-3] אסור לספק אודיו מהמיקרופ שנמשך יותר מ-30 שניות לבקשת שירות בודדת לזיהוי מילות מפתח שמופעל על ידי חומרה.
• [9.8/H-1-4] אסור לספק אודיו ממיקרופ שנשמר במטמון ומכיל יותר מ-8 שניות לבקשת שירות בודדת לשירות זיהוי מילת הפעלה.
• [9.8/H-1-5] אסור לספק לשירות האינטראקציה הקולית או לישות דומה אודיו מהמיקרופ שנשמר במטמון ומעלה מ-30 שניות.
• [9.8/H-1-6] אסור לאפשר להעביר יותר מ-100 בייטים של נתונים משירות זיהוי מילות המפתח החמות בכל תוצאה מוצלחת של מילות מפתח חמות למעט נתוני אודיו שמועברים דרך HotwordAudioStream.
• [9.8/H-1-7] אסור לאפשר להעביר יותר מ-5 ביט של נתונים משירות זיהוי מילות המפתח החמות בכל תוצאה שלילית של מילות מפתח חמות.
• [9.8/H-1-8] חובה לאפשר העברת נתונים משירות זיהוי המילות המפתחות רק בתגובה לבקשת אימות של מילת מפתח מהשרת המערכת.
• [9.8/H-1-9] אסור לאפשר לאפליקציה שאפשר להתקין על ידי משתמשים לספק את שירות זיהוי מילות המפתח.
• [9.8/H-1-10] אסור להציג בממשק המשתמש נתונים כמותיים על השימוש במיקרופון על ידי שירות זיהוי מילות המפתח.
• [9.8/H-1-11] חובה לתעד ביומן את מספר הבייטים שכלולים בכל שידור משירות זיהוי מילות המפתח החמות, כדי לאפשר לחוקרי אבטחה לבדוק את הנתונים.
• [9.8/H-1-12] חובה לתמוך במצב ניפוי באגים שמתעדה ביומן את התוכן הגולמי של כל שידור משירות זיהוי מילת הפעלה, כדי לאפשר לחוקרי אבטחה לבדוק אותו.
• [9.8/H-1-14] חובה להציג את אינדיקטור המיקרופון, כפי שמתואר בקטע 9.8.2, כשתוצאה של מילות מפתח מופעלת מועברת לשירות האינטראקציה הקולית או לישות דומה.

יצירת דרישות חדשות

• [9.8/H-1-15] חובה לוודא שזרמי האודיו שסופקו בתוצאות של זיהוי מילת הפעלה מועברים בכיוון אחד משירות זיהוי מילת הפעלה לשירות האינטראקציה הקולית.

סיום הדרישות החדשות

• [9.8/H-SR-1] מומלץ מאוד להודיע למשתמשים לפני שמגדירים אפליקציה כספק של שירות זיהוי מילות מפתח.
• [9.8/H-SR-2] מומלץ מאוד לא לאפשר העברה של נתונים לא מובְנים משירות זיהוי מילות המפתח.
• [9.8/H-SR-3] מומלץ מאוד להפעיל מחדש את התהליך שמארח את שירות זיהוי מילות המפתח החמות לפחות פעם בשעה או בכל 30 אירועים שמופעל בהם הטריגר החומרה, המוקדם מביניהם.

אם הטמעות במכשירים כוללות אפליקציה שמשתמשת ב-System API‏HotwordDetectionService או במנגנון דומה לזיהוי מילת הפעלה ללא אינדיקציה לשימוש במיקרופון, האפליקציה:

• [9.8/H-2-1] חובה לספק למשתמש הודעה מפורשת לגבי כל ביטוי מפתח נתמך.
• [9.8/H-2-2] אסור לשמור נתוני אודיו גולמיים או נתונים שמבוססים עליהם באמצעות שירות זיהוי מילות המפתח.
• [9.8/H-2-3] אסור להעביר משירות זיהוי מילות המפתח נתוני אודיו, נתונים שאפשר להשתמש בהם כדי לשחזר (בחלקו או במלואו) את האודיו, או תוכן אודיו שלא קשור למילות המפתח עצמן, מלבד ל-ContentCaptureService או לשירות זיהוי הדיבור במכשיר.

יצירת דרישות חדשות

אם הטמעות של מכשירים ניידים תומכות ב-System API‏ VisualQueryDetectionService או במנגנון אחר לזיהוי שאילתות בלי אינדיקציה לגישה למיקרופון ו/או למצלמה, הן:

• [9.8/H-3-1] חובה לוודא ששירות זיהוי השאילתות יכול להעביר נתונים רק למערכת, ל-ContentCaptureService או לשירות זיהוי הדיבור במכשיר (שנוצר על ידי SpeechRecognizer#createOnDeviceSpeechRecognizer()).
• [9.8/H-3-2] אסור לאפשר העברה של מידע אודיו או וידאו מ-VisualQueryDetectionService, מלבד ל-ContentCaptureService או לשירות זיהוי הדיבור במכשיר.
• [9.8/H-3-3] חובה להציג הודעה למשתמש בממשק המשתמש של המערכת כשהמכשיר מזהה את הכוונה של המשתמש לקיים אינטראקציה עם אפליקציית העוזר הדיגיטלי (למשל, על ידי זיהוי נוכחות המשתמש באמצעות המצלמה).
• [9.8/H-3-4] חובה להציג אינדיקטור של מיקרופון ולהציג את שאילתת המשתמש שזוהתה בממשק המשתמש מיד אחרי זיהוי שאילתת המשתמש.
• [9.8/H-3-5] אסור לאפשר לאפליקציה שניתן להתקין על ידי משתמשים לספק את השירות לזיהוי שאילתות חזותיות.

סיום הדרישות החדשות

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

• [9.8.2/H-4-1] חובה להציג את האינדיקטור של המיקרופון כשאפליקציה ניגשת לנתוני אודיו מהמיקרופון, אבל לא כשHotwordDetectionService,‏ SOURCE_HOTWORD,‏ ContentCaptureService או אפליקציות עם התפקידים שמפורטים בקטע 9.1 עם מזהה CDD‏ [C-4-X] ניגשים למיקרופון.
• [9.8.2/H-4-2] חובה להציג את רשימת האפליקציות האחרונות והאפליקציות הפעילות שמשתמשות במיקרופון, כפי שהיא מוחזרת מ-PermissionManager.getIndicatorAppOpUsageData(), יחד עם הודעות שיוך שמשויכות אליהן.

אם הטמעות של מכשירים ניידים מגדירות את android.hardware.camera.any, הן:

• [9.8.2/H-5-1] חובה להציג את אינדיקטור המצלמה כשאפליקציה ניגשת לנתוני מצלמה בשידור חי, אבל לא כשאפליקציות עם התפקידים שמפורטים בקטע 9.1 עם מזהה CDD‏ [C-4-X] ניגשות למצלמה בלבד.
• [9.8.2/H-5-2] חובה להציג את האפליקציות האחרונות והפעילות באמצעות המצלמה, כפי שהן מופיעות ב-PermissionManager.getIndicatorAppOpUsageData(), יחד עם הודעות שיוך שמשויכות אליהן.

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

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

• [6.1/H-0-1]* חייב לתמוך בפקודת המעטפת cmd testharness.

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

• Perfetto
  • [6.1/H-0-2]* חובה לחשוף למשתמש המעטפת קובץ בינארי של /system/bin/perfetto, שבו שורת הפקודה תואמת למסמכי התיעוד של perfetto.
  • [6.1/H-0-3]* קובץ הבינארי של perfetto חייב לקבל כקלט קובץ תצורה של protobuf שתואם לסכימה שמוגדרת במסמכי התיעוד של perfetto.
  • [6.1/H-0-4]* קובץ הבינארי של perfetto חייב לכתוב כפלט מעקב protobuf שתואם לסכימה שמוגדרת במסמכי התיעוד של perfetto.
  • [6.1/H-0-5]* חובה לספק, באמצעות הקובץ הבינארי של perfetto, לפחות את מקורות הנתונים שמתוארים במסמכי התיעוד של perfetto.
  • [6.1/H-0-6]* צריך להפעיל את הדימון של מעקב ה-perfetto כברירת מחדל (מאפיין המערכת persist.traced.enable).

2.2.7. סיווג הביצועים של מדיה בנייד

ההגדרה של סיווג הביצועים של מדיה מפורטת בקטע 7.11.

2.2.7.1. מדיה

אם הטמעות של מכשירי כף יד מחזירות את הערך android.os.Build.VERSION_CODES.T עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, המשמעות היא שהן:

• חייבת לעמוד בדרישות המדיה המפורטות בסעיף 2.2.7.1 ב-CDD של Android 13.

יצירת דרישות חדשות

אם הטמעות של מכשירי כף יד מחזירות את הערך android.os.Build.VERSION_CODES.U עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, המשמעות היא שהן:

• [5.1/H-1-1] חובה לפרסם את המספר המקסימלי של סשנים של מקודד וידאו לחומרה שאפשר להריץ בו-זמנית בכל שילוב של קודק באמצעות השיטות CodecCapabilities.getMaxSupportedInstances() ו-VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-2] חובה לתמוך ב-6 מופעים של סשנים של מקודד וידאו לחומרה של 8 ביט (SDR) (AVC,‏ HEVC,‏ VP9,‏ AV1 או גרסאות מתקדמות יותר) בכל שילוב של קודקים שפועלים בו-זמנית עם 3 סשנים ברזולוציה של 1080p‏@30fps ו-3 סשנים ברזולוציה של 4K‏@30fps. קודקים של AV1 נדרשים לתמוך רק ברזולוציה של 1080p, אבל עדיין נדרשים לתמוך ב-6 מופעים בקצב פריימים של 1080p30.
• [5.1/H-1-3] חובה לפרסם את המספר המקסימלי של סשנים של מקודד וידאו לחומרה שאפשר להריץ בו-זמנית בכל שילוב של קודק באמצעות השיטות CodecCapabilities.getMaxSupportedInstances() ו-VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-4] חובה לתמוך ב-6 מופעים של סשנים של קודק וידאו לחומרה של 8 ביט (SDR) (AVC,‏ HEVC,‏ VP9,‏ AV1 או גרסאות מתקדמות יותר) בכל שילוב של קודקים שפועלים בו-זמנית עם 4 סשנים ברזולוציה 1080p‏@30fps ו-2 סשנים ברזולוציה 4K‏@30fps. קודקים של AV1 נדרשים לתמוך רק ברזולוציה של 1080p, אבל עדיין נדרשים לתמוך ב-6 מופעים בקצב פריימים של 1080p30.
• [5.1/H-1-5] חובה לפרסם את המספר המקסימלי של סשנים של מקודד וידאו לחומרה ושל מפענח וידאו לחומרה שאפשר להריץ בו-זמנית בכל שילוב של קודק באמצעות השיטות CodecCapabilities.getMaxSupportedInstances() ו-VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-6] חובה לתמוך ב-6 מופעים של ממיר וידאו לחומרה של 8 ביט (SDR) ובסשנים של מקודד וידאו לחומרה (AVC,‏ HEVC,‏ VP9,‏ AV1 ואילך) בכל שילוב של קודקים שפועלים בו-זמנית עם 3 סשנים ברזולוציה 4K‏@30fps, מתוכם לכל היותר 2 סשנים של מקודד ו-3 סשנים ברזולוציה 1080p. קודקים של AV1 נדרשים לתמוך רק ברזולוציה של 1080p, אבל עדיין נדרשים לתמוך ב-6 מופעים בקצב פריימים של 1080p30.
• [5.1/H-1-19] חובה לתמוך ב-3 מופעים של ממיר וידאו לחומרה באיכות 10 ביט (HDR) ובסשנים של מקודד וידאו לחומרה (AVC, ‏ HEVC, ‏ VP9, ‏ AV1 או גרסאות מתקדמות יותר) בכל שילוב של קודקים שפועלים בו-זמנית ברזולוציה של 4K‏@30fps, מתוכם מקסימום סשן אחד של מקודד, שניתן להגדיר בפורמט קלט RGBA_1010102 דרך משטח GL. אין צורך ביצירת מטא-נתונים של HDR על ידי המקודד אם מבצעים קידוד מפני השטח של GL. סשנים של קודק AV1 נדרשים לתמוך רק ברזולוציה של 1080p, גם אם הדרישה היא 4K.
• [5.1/H-1-7] זמן האחזור להפעלת הקודק חייב להיות 40 אלפיות השנייה או פחות בסשן קידוד וידאו ברזולוציה של 1080p או פחות, לכל מקודדי הווידאו בחומרה במצב עומס. העומס מוגדר כאן כסשן המרה בו-זמנית של וידאו בלבד מ-1080p ל-720p באמצעות רכיבי קודק וידאו בחומרה, יחד עם האתחול של ההקלטה של אודיו ווידאו ב-1080p. בקודק Dolby Vision, זמן האחזור להפעלת הקודק חייב להיות 50 אלפיות השנייה או פחות.
• [5.1/H-1-8] זמן האחזור להפעלת הקודק חייב להיות 30 אלפיות השנייה או פחות בסשן קידוד אודיו בקצב העברת נתונים של 128kbps או פחות, לכל מקודדי האודיו במצב עומס. העומס מוגדר כאן כסשן המרה בו-זמנית של וידאו בלבד מ-1080p ל-720p באמצעות רכיבי קודק וידאו בחומרה, יחד עם האתחול של ההקלטה של אודיו ווידאו ב-1080p.
• [5.1/H-1-9] חייב לתמוך ב-2 מופעים של סשנים מאובטחים של מקודד וידאו בחומרה (AVC, ‏ HEVC, ‏ VP9, ‏ AV1 או גרסאות מתקדמות יותר) בכל שילוב של קודקים שפועלים בו-זמנית ברזולוציה של 1080p‏@30fps, גם לתוכן 8-bit (SDR) וגם לתוכן HDR 10-bit.
• [5.1/H-1-10] חובה לתמוך ב-3 מופעים של סשנים של מפענח וידאו בחומרה לא מאובטח יחד עם מופע אחד של סשן של מפענח וידאו מאובטח בחומרה (סה"כ 4 מופעים) (AVC,‏ HEVC,‏ VP9,‏ AV1 או גרסאות מתקדמות יותר) בכל שילוב של קודקים שפועלים בו-זמנית עם 3 סשנים ברזולוציית 4K‏@30fps, כולל סשן אחד של מפענח מאובטח וסשן אחד של מפענח לא מאובטח ברזולוציית 1080p‏@30fps, כאשר עד 2 סשנים יכולים להיות ב-HDR של 10 ביט. סשנים של קודק AV1 נדרשים לתמוך רק ברזולוציה של 1080p, גם אם הדרישה היא 4K.
• [5.1/H-1-11] חובה לתמוך במפענח מאובטח לכל מפענח חומרה של AVC, ‏ HEVC,‏ VP9 או AV1 במכשיר.
• [5.1/H-1-12] זמן האחזור לטעינה של הקודק חייב להיות 40 אלפיות השנייה או פחות בסשן של פענוח וידאו ברזולוציה של 1080p או פחות, לכל מפענחי הווידאו בחומרה במצב עומס. העומס מוגדר כאן כסשן המרה בו-זמנית של וידאו בלבד מ-1080p ל-720p באמצעות רכיבי קודק וידאו בחומרה, יחד עם אתחול ההפעלה של אודיו ווידאו ב-1080p. בקודק Dolby Vision, זמן האחזור להפעלת הקודק חייב להיות 50 אלפיות השנייה או פחות.
• [5.1/H-1-13] זמן האחזור להפעלת הקודק חייב להיות 30 אלפיות השנייה או פחות בסשן של פענוח אודיו בקצב העברת נתונים של 128kbps או פחות, לכל מפענח האודיו במצב עומס. העומס מוגדר כאן כסשן המרה בו-זמנית של וידאו בלבד מ-1080p ל-720p באמצעות רכיבי קודק וידאו בחומרה, יחד עם האתחול של ההפעלה של אודיו ווידאו ב-1080p.
• [5.1/H-1-14] חובה לתמוך בפענח חומרה של AV1 Main 10, ברמה 4.1 ובגרעין של סרט.
• [5.1/H-1-15] חובה שיהיה לפחות ממיר וידאו אחד לחומרה שתומך ב-4K60.
• [5.1/H-1-16] חובה שיהיה לפחות מקודד וידאו אחד לחומרה שתומך ב-4K60.
• [5.3/H-1-1] אסור שיהיו יותר מפריים אחד שנופל ב-10 שניות (כלומר פחות מ-0.167 אחוז ירידה בפריימים) בסשן וידאו של 4K ב-60fps במצב עומס.
• [5.3/H-1-2] אסור להחמיץ יותר מפריים אחד ב-10 שניות במהלך שינוי ברזולוציית הווידאו בסשן וידאו של 60fps בעומס, עבור סשן 4K.
• [5.6/H-1-1] זמן האחזור של הקשה לצלצול חייב להיות 80 אלפיות השנייה או פחות באמצעות בדיקת הקשה לצלצול של CTS Verifier.
• [5.6/H-1-2] זמן האחזור של האודיו הלוך ושוב חייב להיות 80 אלפיות השנייה או פחות, דרך לפחות נתיב נתונים נתמך אחד.
• [5.6/H-1-3] חובה לתמוך באודיו של 24 ביט לפחות עבור פלט סטריאו דרך שקעי אודיו בגודל 3.5 מ "מ, אם יש כאלה, דרך אודיו USB, אם יש תמיכה לאורך כל נתיב הנתונים, עבור הגדרות סטרימינג וזמן אחזור קצר. בתצורה של זמן אחזור קצר, האפליקציה צריכה להשתמש ב-AAudio במצב קריאה חוזרת (callback) עם זמן אחזור קצר. בהגדרת הסטרימינג, האפליקציה צריכה להשתמש ב-Java AudioTrack. גם בהגדרה של זמן אחזור קצר וגם בהגדרת הסטרימינג, בורר הפלט של HAL צריך לקבל את AUDIO_FORMAT_PCM_24_BIT,‏ AUDIO_FORMAT_PCM_24_BIT_PACKED, ‏ AUDIO_FORMAT_PCM_32_BIT או AUDIO_FORMAT_PCM_FLOAT כפורמט הפלט היעד שלו.
• [5.6/H-1-4] חובה לתמוך במכשירי אודיו USB עם 4 ערוצים לפחות (הדבר משמש את ה-DJ כדי להציג תצוגה מקדימה של שירים).
• [5.6/H-1-5] חובה לתמוך במכשירי MIDI שתואמים לסיווג ולהצהיר על דגל התכונה של MIDI.
• [5.6/H-1-9] חובה לתמוך בערבוב של לפחות 12 ערוצים. המשמעות היא שאפשר לפתוח AudioTrack עם מסכת ערוצים 7.1.4 ולבצע עיבוד מרחבי או דאונמיקס של כל הערוצים לסטריאו בצורה תקינה.
• [5.6/H-SR] מומלץ מאוד לתמוך בחיבור של 24 ערוצים, עם תמיכה לפחות במסכות של 9.1.6 ו-22.2 ערוצים.
• [5.7/H-1-2] חובה לתמוך ב-MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL עם יכולות הפענוח הבאות של תוכן.

גודל מינימלי של דגימה	4MB
מספר מינימלי של דגימות משנה – H264 או HEVC	32
מספר מינימלי של דגימות משנה – VP9	9
מספר מינימלי של דגימות משנה – AV1	288
גודל שטח האחסון הזמני המינימלי של תמונת המשנה	1MB
גודל מינימלי של מאגר קריפטוגרפיה גנרי	500 KiB
מספר מינימלי של סשנים בו-זמניים	30
מספר מפתחות מינימלי לכל סשן	20
מספר מפתחות מינימלי כולל (כל הסשנים)	80
המספר הכולל המינימלי של מפתחות DRM (כל הסשנים)	6
גודל ההודעה	16 KiB
פריימים מוצפנים לשנייה	60 פריימים לשנייה (fps)

• [5.1/H-1-17] חייב להיות לפחות מפענח תמונות חומרה אחד שתומך בפרופיל הבסיסי של AVIF.
• [5.1/H-1-18] חובה לתמוך בקודק AV1 שיכול לקודד ברזולוציה של עד 480p‏, בקצב של 30fps ובמהירות 1Mbps.
• [5.12/H-1-1] חובה [5.12/H-SR] מומלץ מאוד לתמוך בתכונה Feature_HdrEditing לכל מקודדי החומרה של AV1 ו-HEVC שנמצאים במכשיר.
• [5.12/H-1-2] חובה לתמוך בפורמט הצבע RGBA_1010102 לכל מקודדי החומרה של AV1 ו-HEVC שנמצאים במכשיר.
• [5.12/H-1-3] חובה לפרסם תמיכה בתוסף EXT_YUV_target כדי לדגום מטקסטורות YUV ב-8 ביט וב-10 ביט.
• [7.1.4/H-1-1] חייב להיות לפחות 6 שכבות-על של חומרה ביחידה לעיבוד תצוגה (DPU), ולפחות 2 מהן צריכות להיות מסוגלות להציג תוכן וידאו של 10 ביט.

אם הטמעות של מכשירים ניידים מחזירות את הערך android.os.Build.VERSION_CODES.U עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS וכוללות תמיכה במקודד חומרה של AVC או HEVC, הן:

• [5.2/H-2-1] חייב לעמוד ביעד האיכות המינימלי שמוגדר על ידי עקומות ההפרעה-קצב הקידוד של מכשיר הקידוד של הווידאו, עבור קודיקים של חומרה מסוג AVC ו-HEVC, כפי שמוגדר בבדיקות של סיווג הביצועים 14 (PC14) – איכות קידוד הווידאו (VEQ).

סיום הדרישות החדשות

2.2.7.2. מצלמה

אם הטמעות של מכשירי כף יד מחזירות את הערך android.os.Build.VERSION_CODES.T עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, המשמעות היא שהן:

• חייבת לעמוד בדרישות המדיה המפורטות בסעיף 2.2.7.2 ב-CDD של Android 13.

יצירת דרישות חדשות

אם הטמעות של מכשירי כף יד מחזירות את הערך android.os.Build.VERSION_CODES.U עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, המשמעות היא שהן:

• [7.5/H-1-1] חייבת להיות מצלמה ראשית אחורית ברזולוציה של לפחות 12 מגה-פיקסלים שתומכת בצילומי וידאו ברזולוציית 4K‏@30fps. המצלמה האחורית הראשית היא המצלמה האחורית עם מזהה המצלמה הנמוך ביותר.
• [7.5/H-1-2] חייבת להיות מצלמה קדמית ראשית ברזולוציה של לפחות 6 מגה-פיקסלים שתומכת בצילומי וידאו ברזולוציה 1080p‏@30fps. המצלמה הקדמית הראשית היא המצלמה הקדמית עם מזהה המצלמה הנמוך ביותר.
• [7.5/H-1-3] חובה לתמוך במאפיין android.info.supportedHardwareLevel כ-FULL או יותר טוב במצלמה הראשית האחורית, וכ-LIMITED או יותר טוב במצלמה הראשית הקדמית.
• [7.5/H-1-4] חובה לתמוך ב-CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME בשתי המצלמות הראשיות.
• [7.5/H-1-5] זמן האחזור לצילום JPEG במצלמה 2 חייב להיות קטן מ-1000 900 אלפיות השנייה ברזולוציה של 1080p, כפי שנמדד על ידי בדיקת הביצועים של המצלמה ב-CTS בתנאים של תאורה ITS (3000K) בשתי המצלמות הראשיות.
• [7.5/H-1-6] זמן האחזור של הפעלת המצלמה השנייה (פתיחת המצלמה עד לפריים הראשון בתצוגה המקדימה) חייב להיות קטן מ-500 אלפיות השנייה, כפי שנמדד על ידי בדיקת הביצועים של מצלמת CTS בתנאים של תאורה ITS (3000K) בשתי המצלמות הראשיות.
• [7.5/H-1-8] חובה שתהיה תמיכה ב-CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW וב-android.graphics.ImageFormat.RAW_SENSOR במצלמה האחורית הראשית.
• [7.5/H-1-9] חייבת להיות מצלמה ראשית אחורית שתומכת ברזולוציה של 720p או 1080p‏ @ 240fps.
• [7.5/H-1-10] חובה ש-ZOOM_RATIO המינימלי יהיה קטן מ-1.0 במצלמות הראשיות אם יש מצלמת RGB רחבה במיוחד הפונה לאותו כיוון.
• [7.5/H-1-11] חובה להטמיע סטרימינג בו-זמנית מקדימה ומאחור במצלמות הראשיות.
• [7.5/H-1-12] חובה לתמוך ב-CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION גם במצלמה הקדמית הראשית וגם במצלמה האחורית הראשית.
• [7.5/H-1-13] חובה לתמוך ביכולת LOGICAL_MULTI_CAMERA במצלמה האחורית הראשית אם יש יותר ממצלמה אחורית אחת מסוג RGB.
• [7.5/H-1-14] חובה לתמוך ביכולת STREAM_USE_CASE גם במצלמה הקדמית הראשית וגם במצלמה האחורית הראשית.
• [7.5/H-1-15] חובה לתמוך בתוספים של מצב לילה ו-Bokeh במצלמות הראשיות, דרך התוספים של CameraX ו-Camera2.
• [7.5/H-1-16] חובה לתמוך ביכולת DYNAMIC_RANGE_TEN_BIT במצלמות הראשיות.
• [7.5/H-1-17] חובה לתמוך ב-CONTROL_SCENE_MODE_FACE_PRIORITY ובזיהוי פנים (STATISTICS_FACE_DETECT_MODE_SIMPLE או STATISTICS_FACE_DETECT_MODE_FULL) במצלמות הראשיות.

סיום הדרישות החדשות

2.2.7.3. חומרה

אם הטמעות של מכשירי כף יד מחזירות את הערך android.os.Build.VERSION_CODES.T עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, המשמעות היא שהן:

• חייבת לעמוד בדרישות המדיה המפורטות בקטע 2.2.7.3 ב-CDD של Android 13.

יצירת דרישות חדשות

אם הטמעות של מכשירי כף יד מחזירות את הערך android.os.Build.VERSION_CODES.U עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, המשמעות היא שהן:

• [7.1.1.1/H-2-1] הרזולוציה של המסך חייבת להיות לפחות 1080p.
• [7.1.1.3/H-2-1] צפיפות המסך חייבת להיות לפחות 400 dpi.
• [7.1.1.3/H-3-1] חייב להיות מסך HDR שתומך ב-1,000 ניטים בממוצע לפחות.
• [7.6.1/H-2-1] חייב להיות זיכרון פיזי בנפח 8GB לפחות.

סיום הדרישות החדשות

2.2.7.4. ביצועים

אם הטמעות של מכשירי כף יד מחזירות את הערך android.os.Build.VERSION_CODES.T עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, המשמעות היא שהן:

• חובה לעמוד בדרישות הביצועים המפורטות בסעיף 2.2.7.4 ב-CDD של Android 13.

יצירת דרישות חדשות

אם הטמעות של מכשירי כף יד מחזירות את הערך android.os.Build.VERSION_CODES.U עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, המשמעות היא שהן:

• [8.2/H-1-1] חובה להבטיח ביצועי כתיבה רציפה של לפחות 150MB/s.
• [8.2/H-1-2] חובה להבטיח ביצועי כתיבה אקראיים של לפחות 10MB/s.
• [8.2/H-1-3] חובה להבטיח ביצועי קריאה רצופים של לפחות 250MB/s.
• [8.2/H-1-4] חובה להבטיח ביצועי קריאה אקראית של לפחות 100MB/s.
• [8.2/H-1-5] חובה להבטיח ביצועי קריאה וכתיבה סדרתיים במקביל, עם ביצועי קריאה כפולים וביצועי כתיבה יחידים של לפחות 50MB/s.

סיום הדרישות החדשות

2.3. דרישות לטלוויזיה

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

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

• לספק מנגנון לשלוט מרחוק בממשק המשתמש שעבר רינדור במסך שעשוי להיות במרחק של שלושה מטרים מהמשתמש.
• מכיל מסך מובנה בגודל 24 אינץ' או יותר, או יציאת וידאו, כמו VGA, ‏ HDMI, ‏ DisplayPort או יציאה אלחוטית להצגה.

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

2.3.1. חומרה

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

• [7.2.2/T-0-1] חובה לתמוך בD-pad.
• [7.2.3/T-0-1] חובה לספק את הפונקציות 'דף הבית' ו'הקודם'.
• [7.2.3/T-0-2] חובה לשלוח לאפליקציה שבחזית גם את האירוע הרגיל וגם את האירוע של לחיצה ארוכה על פונקציית החזרה אחורה (KEYCODE_BACK).
• [7.2.6.1/T-0-1] חובה לכלול תמיכה בפקדים למשחקים ולהצהיר על דגל התכונה android.hardware.gamepad.
• [7.2.7/T] צריך לספק שלט רחוק שממנו המשתמשים יכולים לגשת לניווט ללא מגע ולקלידות של ניווט ליבה.

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

• [7.3.4/T-1-1] חייב להיות מסוגל לדווח על אירועים עד לתדירות של לפחות 100Hz.
• [7.3.4/T-1-2] חייב להיות מסוגל למדוד שינויים בכיוון עד 1,000 מעלות לשנייה.

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

• [7.4.3/T-0-1] חובה לתמוך ב-Bluetooth וב-Bluetooth LE.
• [7.6.1/T-0-1] חייב להיות לפחות 4GB של אחסון לא נדיף שזמין לנתונים הפרטיים של האפליקציה (נקרא גם מחיצה '/data').

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

• [7.5.3/T-1-1] חובה לכלול תמיכה במצלמה חיצונית שמתחבר דרך יציאת ה-USB הזו, אבל לא בהכרח תמיד מחוברת.

אם הטמעות של מכשירי טלוויזיה הן 32 ביט:

• [7.6.1/T-1-1] אם משתמשים באחת מהצפיפויות הבאות, נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 896MB:

  • 400dpi או יותר במסכים קטנים/רגילים
  • xhdpi ומעלה במסכים גדולים
  • tvdpi ומעלה במסכים גדולים במיוחד

אם הטמעות במכשירי טלוויזיה הן של 64 ביט:

• [7.6.1/T-2-1] אם משתמשים באחת מהצפיפויות הבאות, נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 1,280MB:

  • 400dpi או יותר במסכים קטנים/רגילים
  • xhdpi ומעלה במסכים גדולים
  • tvdpi ומעלה במסכים גדולים במיוחד

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

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

• [7.8.1/T] צריך לכלול מיקרופון.
• [7.8.2/T-0-1] חייב להיות פלט אודיו ולהצהיר על android.hardware.audio.output.

2.3.2. מולטימדיה

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

• [5.1/T-0-1] MPEG-4 AAC Profile‏ (AAC LC)
• [5.1/T-0-2] MPEG-4 HE AAC Profile‏ (AAC+)
• [5.1/T-0-3] AAC ELD (enhanced low delay AAC)

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

• [5.2/T-0-1] H.264
• [5.2/T-0-2] VP8

יצירת דרישות חדשות

• [5.2/T-0-3] AV1

סיום הדרישות החדשות

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

• [5.2.2/T-SR-1] מומלץ מאוד לתמוך בקידוד H.264 של סרטונים ברזולוציה 720p ו-1080p ב-30 פריימים לשנייה.

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

• [5.3.3/T-0-1] MPEG-4 SP
• [5.3.4/T-0-2] H.264 AVC
• [5.3.5/T-0-3] H.265 HEVC
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9
• [5.3.1/T-0-6] MPEG-2

יצירת דרישות חדשות

• [5.3.2/T-0-7] AV1

סיום הדרישות החדשות

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

• [5.3.1/T-1-1] HD 1080p בקצב של 29.97 פריימים לשנייה עם רמה גבוהה של פרופיל ראשי.
• [5.3.1/T-1-2] HD 1080i‏ במהירות 59.94 פריימים לשנייה עם רמה גבוהה של פרופיל ראשי. חובה לבטל את המעבר בין השורות של סרטון MPEG-2 שמשולב, ולהפוך אותו לזמין לאפליקציות של צד שלישי.

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

• [5.3.4/T-1-1] HD 1080p בקצב של 60 פריימים לשנייה עם Baseline Profile
• [5.3.4/T-1-2] HD 1080p בקצב של 60 פריימים לשנייה עם פרופיל ראשי
• [5.3.4/T-1-3] HD 1080p בקצב של 60 פריימים לשנייה עם High Profile Level 4.2

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

• [5.3.5/T-1-1] HD 1080p בקצב של 60 פריימים לשנייה עם פרופיל ראשי ברמה 4.1

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

• [5.3.5/T-2-1] חובה לתמוך בפרופיל הפענוח של UHD במהירות 60 פריימים לשנייה עם פרופיל Main10 ברמה 5 ברמה הראשית

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

• [5.3.6/T-1-1] פרופיל פענוח של HD 1080p בקצב של 60 פריימים לשנייה

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

• [5.3.7/T-1-1] HD 1080p בקצב של 60 פריימים לשנייה עם פרופיל 0 (עומק צבע של 8 ביט)

אם הטמעות של מכשירי טלוויזיה עם מפענחים לחומרה של VP9 תומכות בפענוח VP9 ובפרופיל הפענוח של UHD, הן:

• [5.3.7/T-2-1] חובה לתמוך בפרופיל הפענוח של UHD במהירות 60 פריימים לשנייה עם פרופיל 0 (עומק צבע של 8 ביט).
• [5.3.7/T-SR1] מומלץ מאוד לתמוך בפרופיל הפענוח של UHD בקצב של 60 פריימים לשנייה עם פרופיל 2 (עומק צבע של 10 ביט).

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

• [5.5/T-0-1] חובה לכלול תמיכה בעוצמת הקול הראשית של המערכת ובהפחתת עוצמת הקול של יציאת האודיו הדיגיטלי בממשקי יציאה נתמכים, מלבד יציאת אודיו דחוסה ללא תיקון שגיאות (passthrough) (שבה לא מתבצע פענוח אודיו במכשיר).

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

• [5.8/T-0-1] חובה להגדיר את מצב הפלט של HDMI לרזולוציה הגבוהה ביותר של פורמט הפיקסלים שנבחר, שפועל עם קצב רענון של 50Hz או 60Hz במסך החיצוני, בהתאם לקצב הרענון של הווידאו באזור שבו המכשיר נמכר. חובה להגדיר את מצב הפלט של HDMI כדי לבחור את הרזולוציה המקסימלית שניתן לתמוך בה בקצב רענון של 50Hz או 60Hz.
• [5.8/T-SR-1] מומלץ מאוד לספק בורר של קצב רענון HDMI שניתן להגדרה על ידי המשתמש.
• [5.8] צריך להגדיר את קצב הרענון של מצב הפלט של HDMI ל-50Hz או ל-60Hz, בהתאם לקצב הרענון של הסרטון באזור שבו המכשיר נמכר.

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

• [5.8/T-1-1] חובה שתהיה תמיכה ב-HDCP 2.2.

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

• [5.8/T-2-1] חובה לתמוך ב-HDCP 1.4

2.3.3. תוכנות

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

• [3/T-0-1] חובה להצהיר על התכונות android.software.leanback ו-android.hardware.type.television.
• [3.2.3.1/T-0-1] חובה לטעון מראש אפליקציה אחת או יותר או רכיבי שירות עם טיפול בכוונה (intent), לכל דפוסי המסננים הציבוריים של הכוונה שהוגדרו על ידי כוונות האפליקציה הבאות שמפורטות כאן.
• [3.4.1/T-0-1] חובה לספק הטמעה מלאה של ה-API של android.webkit.Webview.

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

• [3.8.10/T-1-1] חובה להציג את ההתראות במסך הנעילה, כולל תבנית ההתראות של המדיה.

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

• [3.8.14/T-SR-1] מומלץ מאוד לתמוך במצב 'תמונה בתוך תמונה' (PIP) במספר חלונות.
• [3.10/T-0-1] חובה לתמוך בשירותי נגישות של צד שלישי.
• [3.10/T-SR-1] מומלץ מאוד לטעון מראש את שירותי הנגישות במכשיר, עם פונקציונליות דומה או טובה יותר מזו של שירותי הנגישות 'גישה באמצעות מתג' ו-TalkBack (עבור שפות שנתמכות במנוע ההמרה מ-Text ל-Speech שמותקן מראש), כפי שמפורט בפרויקט הקוד הפתוח של TalkBack.

אם הטמעות של מכשירי טלוויזיה מדווחות על התכונה android.hardware.audio.output, הן:

• [3.11/T-SR-1] מומלץ מאוד לכלול מנוע TTS שתומך בשפות הזמינות במכשיר.
• [3.11/T-1-1] חובה לתמוך בהתקנה של מנועי TTS של צד שלישי.

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

• [3.12/T-0-1] חובה לתמוך ב-TV Input Framework.

2.3.4. ביצועים וצריכת חשמל

• [8.1/T-0-1] זמן אחזור עקבי של פריימים. זמן אחזור לא עקבי של פריימים או עיכוב ברינדור של פריימים אסור לקרות בתדירות של יותר מ-5 פריימים לשנייה, וצריך להיות נמוך מפריים אחד לשנייה.
• [8.2/T-0-1] חובה להבטיח ביצועי כתיבה רצופים של לפחות 5MB/s.
• [8.2/T-0-2] חובה להבטיח ביצועי כתיבה אקראיים של לפחות 0.5MB/s.
• [8.2/T-0-3] חובה להבטיח ביצועי קריאה רציפים של לפחות 15MB/s.
• [8.2/T-0-4] חובה להבטיח ביצועי קריאה אקראית של לפחות 3.5MB/s.

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

• [8.3/T-1-1] חובה לספק למשתמש אפשרות להפעיל ולהשבית את התכונה 'חיסכון בסוללה'.

אם למכשירי טלוויזיה אין סוללה, הם:

• [8.3/T-1-2] חובה לרשום את המכשיר כמכשיר ללא סוללה, כפי שמתואר בקטע תמיכה במכשירים ללא סוללה.

אם למכשירי טלוויזיה יש סוללה, הם:

• [8.3/T-1-3] חובה לספק למשתמשים אפשרות להציג את כל האפליקציות שפטורות ממצבי חיסכון האנרגיה 'המתנה לאפליקציה' ו'דוז'.

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

• [8.4/T-0-1] חובה לספק פרופיל צריכת אנרגיה לכל רכיב, שמגדיר את ערך הצריכה הנוכחית של כל רכיב חומרה ואת הירידה המשוערת בנפח הסוללה שנגרמת על ידי הרכיבים לאורך זמן, כפי שמופיע באתר של Android Open Source Project.
• [8.4/T-0-2] חובה לדווח על כל ערכי צריכת האנרגיה במיליאמפר-שעה (mAh).
• [8.4/T-0-3] חובה לדווח על צריכת החשמל של המעבד לכל מזהה משתמש (UID) של תהליך. פרויקט הקוד הפתוח של Android עומד בדרישות באמצעות הטמעת מודול הליבה uid_cputime.
• [8.4/T] צריך לשייך לרכיב החומרה עצמו אם לא ניתן לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.
• [8.4/T-0-4] חובה להפוך את צריכת האנרגיה הזו לזמינה למפתח האפליקציה באמצעות הפקודה adb shell dumpsys batterystats.

2.3.5. מודל אבטחה

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

• [9/T-0-1] חובה להצהיר על התכונה android.hardware.security.model.compatible.
• [9.11/T-0-1] חובה לגבות את הטמעת מאגר המפתחות באמצעות סביבת הפעלה מבודדת.
• [9.11/T-0-2] חובה שתהיה הטמעה של אלגוריתמים קריפטוגרפיים מסוג RSA, ‏ AES,‏ ECDSA ו-HMAC ופונקציות גיבוב ממשפחת MD5, ‏ SHA1 ו-SHA-2, כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בליבה ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד הליבה או קוד מרחב המשתמש עשוי לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. בפרויקט Android Open Source (AOSP) ב-upstream מתקיימים הדרישות האלה באמצעות ההטמעה של Trusty, אבל יש גם אפשרויות חלופיות: פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת של בידוד תקין שמבוסס על hypervisor, שעבר בדיקה על ידי צד שלישי.
• [9.11/T-0-3] חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק אם הוא מצליח, לאפשר שימוש במפתחות שמקושרים לאימות. חובה לאחסן את פרטי הכניסה של מסך הנעילה באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. בפרויקט הקוד הפתוח של Android תוכלו למצוא את שכבת האובייקטים המצומצמים לחומרה (HAL) של Gatekeeper ו-Trusty, שאפשר להשתמש בהם כדי לעמוד בדרישות האלה.
• [9.11/T-0-4] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה לאימות מוגן על ידי חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה לאימות במספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת מהדרכים לעמוד בדרישות האלה היא לשתף את אותו מפתח אימות, אלא אם מיוצרות לפחות 100,000 יחידות של מק"ט נתון. אם מיוצרות יותר מ-100,000 יחידות של מק"ט מסוים, יכול להיות שייעשה שימוש במפתח שונה לכל 100,000 יחידות.

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

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

• [9.11/T-1-1] חובה לאפשר למשתמש לבחור את זמן הקצוב לתפוגה במצב שינה כדי לעבור ממצב פתוח למצב נעול, כאשר זמן הקצוב לתפוגה המינימלי המותר הוא עד 15 שניות או פחות.

אם הטמעות של מכשירי טלוויזיה כוללות כמה משתמשים ולא מצהירות על דגל התכונה android.hardware.telephony, הן:

• [9.5/T-2-1] חובה לתמוך בפרופילים מוגבלים, תכונה שמאפשרת לבעלי המכשיר לנהל משתמשים נוספים ואת היכולות שלהם במכשיר. בעזרת פרופילים מוגבלים, בעלי המכשירים יכולים להגדיר במהירות סביבות נפרדות למשתמשים נוספים, ולנהל הגבלות מפורטות יותר על האפליקציות שזמינות בסביבות האלה.

אם הטמעות של מכשירי טלוויזיה כוללות כמה משתמשים ומצהירות על דגל התכונה android.hardware.telephony, הן:

• [9.5/T-3-1] אסור לתמוך בפרופילים מוגבלים, אבל חובה להתאים את ההטמעה של אמצעי הבקרה ב-AOSP כדי לאפשר או להשבית למשתמשים אחרים גישה לשיחות הקוליות ול-SMS.

אם הטמעות של מכשירי טלוויזיה מכריזות על android.hardware.microphone, הן:

• [9.8.2/T-4-1] חובה להציג את האינדיקטור של המיקרופון כשאפליקציה ניגשת לנתוני אודיו מהמיקרופון, אבל לא כשהגישה למיקרופון היא רק על ידי HotwordDetectionService‏, SOURCE_HOTWORD‏, ContentCaptureService או אפליקציות עם התפקידים שמפורטים בקטע 9.1 בנושא הרשאות עם מזהה CDD‏ C-3-X].
• [9.8.2/T-4-2] אסור להסתיר את האינדיקטור של המיקרופון באפליקציות מערכת שיש להן ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמש.

אם הטמעות של מכשירי טלוויזיה מכריזות על android.hardware.camera.any, הן:

• [9.8.2/T-5-1] חובה להציג את סמל המצלמה כשאפליקציה ניגשת לנתוני המצלמה בשידור חי, אבל לא כשאפליקציות עם התפקידים שמפורטים בקטע 9.1 הרשאות עם מזהה CDD [C-3-X] ניגשות למצלמה בלבד.
• [9.8.2/T-5-2] אסור להסתיר את האינדיקטור של המצלמה באפליקציות מערכת שיש להן ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמש.

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

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

• Perfetto
  • [6.1/T-0-1] חובה לחשוף למשתמש המעטפת קובץ בינארי של /system/bin/perfetto, שבו שורת הפקודה תואמת למסמכי התיעוד של perfetto.
  • [6.1/T-0-2] קובץ הבינארי של perfetto חייב לקבל כקלט קובץ תצורה של protobuf שתואם לסכימה שמוגדרת במסמכי התיעוד של perfetto.
  • [6.1/T-0-3] קובץ הבינארי של perfetto חייב לכתוב כפלט נתיב protobuf שתואם לסכימה שמוגדרת במסמכי התיעוד של perfetto.
  • [6.1/T-0-4] חובה לספק, באמצעות הקובץ הבינארי של perfetto, לפחות את מקורות הנתונים שמתוארים במסמכי התיעוד של perfetto.

2.4. דרישות לשעון

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

הטמעות של מכשירי Android מסווגות כשעון אם הן עומדות בכל הקריטריונים הבאים:

• המסך צריך להיות בגודל פיזי של 1.1 עד 2.5 אינץ' באלכסון.
• מכשיר עם מנגנון ללבישה על הגוף.

הדרישות הנוספות שמפורטות בהמשך הסעיף הזה ספציפיות להטמעות במכשירי Android Watch.

2.4.1. חומרה

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

• [7.1.1.1/W-0-1] חייב לכלול מסך בגודל פיזי באלכסון של 1.1 עד 2.5 אינץ'.

• [7.2.3/W-0-1] חובה שפונקציית הבית תהיה זמינה למשתמש, וגם פונקציית החזרה אחורה, מלבד כשהמכשיר נמצא ב-UI_MODE_TYPE_WATCH.

• [7.2.4/W-0-1] חובה לתמוך בקלט במסך מגע.

• [7.3.1/W-SR-1] מומלץ מאוד לכלול תאוצה משולש-צירי.

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

• [7.3.3/W-1-1] חובה לדווח על מדידות GNSS ברגע שהן מתקבלות, גם אם עדיין לא דווח על מיקום שמחושב מ-GPS/GNSS.
• [7.3.3/W-1-2] חובה לדווח על טווחי פסאודו וקצבי פסאודו של GNSS, שבתנאי שדה פתוח אחרי שנקבע המיקום, במצב נייח או בתנועה עם פחות מ-0.2 מטר לשנייה בריבוע של תאוצה, מספיקים כדי לחשב מיקום בטווח של 20 מטרים ומהירות בטווח של 0.2 מטר לשנייה, לפחות ב-95% מהמקרים.

אם הטמעות של מכשירי Watch כוללות ג'ירוסקופ ב-3 צירים, הן:

• [7.3.4/W-2-1] חייב להיות מסוגל למדוד שינויים בכיוון עד 1,000 מעלות לשנייה.

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

• [7.4.3/W-0-1] חובה שתהיה תמיכה ב-Bluetooth.

• [7.6.1/W-0-1] חייב להיות לפחות 1GB של אחסון לא נדיף שזמין לנתונים הפרטיים של האפליקציה (נקרא גם מחיצה '/data').

• [7.6.1/W-0-2] חייבת להיות לפחות 416MB של זיכרון שזמין לליבה ולמרחב המשתמש.

• [7.8.1/W-0-1] חייב לכלול מיקרופון.

• [7.8.2/W] יכול להיות שיש לו פלט אודיו.

2.4.2. מולטימדיה

אין דרישות נוספות.

2.4.3. תוכנות

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

• [3/W-0-1] חובה להצהיר על התכונה android.hardware.type.watch.
• [3/W-0-2] חובה לתמוך ב-uiMode‏ = UI_MODE_TYPE_WATCH.
• [3.2.3.1/W-0-1] חובה לטעון מראש אפליקציה אחת או יותר או רכיבי שירות עם טיפול בכוונה, לכל דפוסי המסננים הציבוריים של הכוונה שהוגדרו על ידי כוונות האפליקציה הבאות שמפורטות כאן.

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

• [3.8.4/W-SR-1] מומלץ מאוד להטמיע במכשיר עוזרת כדי לטפל בפעולת העזרה.

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

• [3.10/W-1-1] חובה לתמוך בשירותי נגישות של צד שלישי.
• [3.10/W-SR-1] מומלץ מאוד לטעון מראש במכשיר שירותי נגישות שדומים לשירותי הנגישות של Switch Access ו-TalkBack (לשפות שנתמכות במנוע ההמרה מ-Text ל-Speech שמותקן מראש) או שעדיפים עליהם, כפי שמפורט בפרויקט הקוד הפתוח של TalkBack.

אם הטמעות של מכשירי Watch מדווחות על התכונה android.hardware.audio.output, הן:

• [3.11/W-SR-1] מומלץ מאוד לכלול מנוע TTS שתומך בשפות הזמינות במכשיר.

• [3.11/W-0-1] חובה לתמוך בהתקנה של מנועי TTS של צד שלישי.

2.4.4. ביצועים וצריכת חשמל

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

• [8.3/W-SR-1] מומלץ מאוד לספק למשתמש אפשרות להציג את כל האפליקציות שפטורות ממצבי חיסכון האנרגיה 'המתנה לאפליקציה' ו'שינה עמוקה'.
• [8.3/W-SR-2] מומלץ מאוד לספק למשתמש אפשרות להפעיל ולהשבית את התכונה 'חיסכון בסוללה'.

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

• [8.4/W-0-1] חובה לספק פרופיל צריכת אנרגיה לכל רכיב, שמגדיר את ערך הצריכה הנוכחית של כל רכיב חומרה ואת הירידה המשוערת בנפח הסוללה שנגרמת על ידי הרכיבים לאורך זמן, כפי שמופיע באתר של Android Open Source Project.
• [8.4/W-0-2] חובה לדווח על כל ערכי צריכת האנרגיה בשעות מיליאמפר (mAh).
• [8.4/W-0-3] חובה לדווח על צריכת החשמל של המעבד לכל מזהה משתמש (UID) של תהליך. פרויקט הקוד הפתוח של Android עומד בדרישות באמצעות הטמעת מודול הליבה uid_cputime.
• [8.4/W-0-4] חייבים להפוך את צריכת האנרגיה הזו לזמינה למפתח האפליקציה באמצעות הפקודה adb shell dumpsys batterystats במעטפת.
• [8.4/W] צריך לשייך לרכיב החומרה עצמו אם אי אפשר לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.

2.4.5. מודל אבטחה

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

• [9/W-0-1] חובה להצהיר על התכונה android.hardware.security.model.compatible.

אם הטמעות של מכשירי Watch כוללות כמה משתמשים ולא מצהירות על דגל התכונה android.hardware.telephony, הן:

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

אם הטמעות של מכשירי Watch כוללות כמה משתמשים ומצהירות על דגל התכונה android.hardware.telephony, הן:

• [9.5/W-2-1] אסור לתמוך בפרופילים מוגבלים, אבל חובה להתאים את ההטמעה של אמצעי הבקרה ב-AOSP כדי לאפשר או להשבית למשתמשים אחרים גישה לשיחות הקוליות ול-SMS.

יצירת דרישות חדשות

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

• [9.11.1/W-1-1] חובה לאתגר את המשתמש באחת משיטות האימות הראשיות המומלצות (למשל: קוד אימות, קו ביטול נעילה, סיסמה) בתדירות גבוהה יותר מפעם ב-72 שעות.

סיום הדרישות החדשות

2.5. דרישות לכלי רכב

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

הטמעות של מכשירי Android מסווגות כ-Automotive אם הן מצהירות על התכונה android.hardware.type.automotive או עומדות בכל הקריטריונים הבאים.

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

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

2.5.1. חומרה

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

• [7.1.1.1/A-0-1] חייב להיות מסך בגודל פיזי של לפחות 6 אינץ' באלכסון.
• [7.1.1.1/A-0-2] חובה להגדיר פריסה בגודל מסך של לפחות 750dp x 480dp.
• [7.2.3/A-0-1] חובה לספק את הפונקציה 'דף הבית', וניתן לספק את הפונקציות 'חזרה' ו'פריטים אחרונים'.
• [7.2.3/A-0-2] חובה לשלוח לאפליקציה שבחזית גם את האירוע הרגיל וגם את האירוע של לחיצה ארוכה על פונקציית החזרה אחורה (KEYCODE_BACK).
• [7.3/A-0-1] חובה להטמיע ולדווח על GEAR_SELECTION,‏ NIGHT_MODE,‏ PERF_VEHICLE_SPEED ו-PARKING_BRAKE_ON.
• [7.3/A-0-2] הערך של הדגל NIGHT_MODE חייב להיות עקבי עם מצב היום/לילה בלוח הבקרה, וצריך להתבסס על הקלט של חיישן התאורה הסביבתית. חיישן האור הרגיש לסביבה שמשמש כבסיס עשוי להיות זהה לפוטומטר.
• [7.3/A-0-3] חובה לספק שדה מידע נוסף של חיישן TYPE_SENSOR_PLACEMENT כחלק מ-SensorAdditionalInfo לכל חיישן שצוין.
• [7.3/A-SR1] יכול לבצע חישוב משוער של מיקום על ידי שילוב של GPS/GNSS עם חיישנים נוספים. אם המיקום מחושב לפי ניווט משוער, מומלץ מאוד להטמיע ולדווח על סוגי החיישנים המתאימים ו/או על מזהי הנכסים של הרכב שבהם נעשה שימוש.

• [7.3/A-0-4] אסור לבצע התאמה למפה של המיקום המבוקש באמצעות LocationManager#requestLocationUpdates().

• [7.3.1/A-0-4] חייב לעמוד בדרישות של מערכת הקואורדינטות של חיישן הרכב ב-Android.

• [7.3/A-SR-1] מומלץ מאוד לכלול מד תאוצה עם 3 צירים וג'ירוסקופ עם 3 צירים.

• [7.3/A-SR-2] מומלץ מאוד להטמיע ולדווח על חיישן TYPE_HEADING.

אם הטמעות של מכשירים לכלי רכב תומכות ב-OpenGL ES 3.1, הן:

• [7.1.4.1/A-0-1] חובה להצהיר על OpenGL ES 3.1 ואילך.
• [7.1.4.1/A-0-2] חובה לתמוך ב-Vulkan 1.1.
• [7.1.4.1/A-0-3] חובה לכלול את מערך הטעינה של Vulkan ולייצא את כל הסמלים.

אם ההטמעות של מכשירי Automotive כוללות תאוצה, הן:

• [7.3.1/A-1-1] חייב להיות אפשרי לדווח על אירועים עד תדירות של לפחות 100Hz.

אם ההטמעות במכשירים כוללות מד תאוצה ב-3 צירים, הן:

• [7.3.1/A-SR-1] מומלץ מאוד להטמיע את החיישן המשולב למד תאוצה עם צירים מוגבלים.

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

• [7.3.1/A-1-3] חובה להטמיע ולדווח על חיישן TYPE_ACCELEROMETER_LIMITED_AXES.
• [7.3.1/A-1-4] חובה להטמיע ולדווח על חיישן TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

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

• [7.3.4/A-2-1] חייב להיות אפשרי לדווח על אירועים בתדירות של לפחות 100Hz.
• [7.3.4/A-2-3] חייב להיות מסוגל למדוד שינויים בכיוון עד 250 מעלות לשנייה.
• [7.3.4/A-SR-1] מומלץ מאוד להגדיר את טווח המדידה של הגירוסקופ ל-+/-250dps כדי למקסם את הרזולוציה האפשרית.

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

• [7.3.4/A-SR-2] מומלץ מאוד להטמיע את החיישן המשולב לחיישן ג'ירוסקופ עם צירים מוגבלים.

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

• [7.3.4/A-4-1] חובה להטמיע ולדווח על חיישן TYPE_GYROSCOPE_LIMITED_AXES.
• [7.3.4/A-4-2] חובה להטמיע ולדווח על חיישן TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

אם הטמעות של מכשירי רכב כוללות מקלט GPS/GNSS, אבל לא כוללות קישוריות נתונים מבוססת-רשת סלולרית, הן:

• [7.3.3/A-3-1] חובה לקבוע את המיקום בפעם הראשונה שמפעילים את מקלט ה-GPS/GNSS או אחרי 4 ימים או יותר, תוך 60 שניות.
• [7.3.3/A-3-2] חייב לעמוד בקריטריונים של זמן התיקון הראשון כפי שמתואר ב7.3.3/C-1-2 וב-7.3.3/C-1-6 לכל שאר בקשות המיקום (כלומר בקשות שהן לא בפעם הראשונה או לאחר 4 ימים ומעלה). בדרך כלל, הדרישה 7.3.3/C-1-2 מתקיימת בכלי רכב ללא קישוריות נתונים מבוססת-רשת סלולרית, באמצעות חיזויים של מסלול GNSS שמחושבים במקלט, או באמצעות המיקום האחרון הידוע של הרכב בשילוב עם היכולת לבצע חישוב משוער של המיקום (dead reckoning) למשך לפחות 60 שניות, עם דיוק מיקום שעומד בדרישות של 7.3.3/C-1-3, או בשילוב של שניהם.

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

• [7.3.4/A-4-3] חייב להיות אפשרי לדווח על אירועים בתדירות של לפחות 1Hz.
• [7.3.4/A-SR-3] מומלץ מאוד לדווח על אירועים בתדירות של לפחות 10Hz.
• צריך להתייחס לצפון מוחלט.
• האפשרות הזו אמורה להיות זמינה גם כשהרכב עומד.
• צריכה להיות רזולוציה של לפחות מעלה אחת.

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

• [7.4.3/A-0-1] חובה שתהיה תמיכה ב-Bluetooth, ומומלץ שתהיה תמיכה ב-Bluetooth LE.
• [7.4.3/A-0-2] יש לכלול בהטמעות של Android Automotive תמיכה בפרופילים הבאים של Bluetooth:
  • שיחות טלפון באמצעות פרופיל דיבורית (HFP).
  • הפעלת מדיה באמצעות פרופיל להפצת אודיו (A2DP).
  • שליטה בהפעלת מדיה באמצעות פרופיל שלט רחוק (AVRCP).
  • שיתוף אנשי קשר באמצעות פרופיל הגישה לספר הטלפונים (PBAP).

• [7.4.3/A-SR-1] מומלץ מאוד לתמוך בפרופיל גישה להודעות (MAP).

• [7.4.5/A] צריך לכלול תמיכה בחיבור נתונים מבוסס-רשת סלולרית.

• [7.4.5/A] יכול להשתמש בערך הקבוע NetworkCapabilities#NET_CAPABILITY_OEM_PAID של System API לרשתות שצריכות להיות זמינות לאפליקציות המערכת.

יצירת דרישות חדשות

אם הטמעות במכשירים כוללות תמיכה ברדיו שידור AM/FM ומציגות את הפונקציונליות לכל אפליקציה, הן:

• [7.4.10/A-0-1] חובה להצהיר על תמיכה ב-FEATURE_BROADCAST_RADIO.

סיום הדרישות החדשות

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

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

• צריך לכלול מצלמה אחת או יותר עם תצוגה חיצונית.

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

• [7.5/A-1-1] אסור שיהיו מצלמות חיצוניות שאפשר לגשת אליהן דרך Android Camera APIs, אלא אם הן עומדות בדרישות הליבה של המצלמה.

• [7.5/A-SR-1] מומלץ מאוד לא לסובב את התצוגה המקדימה של המצלמה או להציג אותה במראה אופקית.

• [7.5/A-SR-2] מומלץ מאוד שהרזולוציה שלהן תהיה לפחות 1.3 מגה-פיקסלים.

• צריכה להיות להם חומרה עם מיקוד קבוע או חומרה עם EDOF (עומק שדה מורחב).

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

אם הטמעות של מכשירים לכלי רכב כוללות מצלמה אחת או יותר של תצוגה חיצונית, ומטענות את השירות של מערכת התצוגה החיצונית (EVS), אז במצלמה כזו:

• [7.5/A-2-1] אסור לסובב או להציג בתמונת המראה של המצלמה בכיוון אופקי.

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

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

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

• [7.5/A-3-1] חובה לדווח על ה-feature flag‏ android.hardware.camera.any.
• [7.5/A-3-2] אסור להצהיר על המצלמה כמצלמת מערכת.
• יכול להיות שתהיה תמיכה במצלמות חיצוניות כפי שמתואר בסעיף 7.5.3.
• יכולות לכלול תכונות (כמו פוקוס אוטומטי וכו') שזמינות למצלמות שתואמות לסעיף 7.5.1.

יצירת דרישות חדשות

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

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

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

• [7.5/A-SR-1] מומלץ מאוד לכלול מצלמה אחת או יותר עם כיוון קדימה.
• יכול להיות שיהיו בו מצלמה אחת או יותר שמכוונת למשתמש.
• [7.5/A-SR-2] מומלץ מאוד לתמוך בסטרימינג בו-זמני של כמה מצלמות.

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

• [7.5/A-1-1] חייב להיות בכיוון שבו הממד הארוך של המצלמה יהיה באותו מישור X-Y של צירי החיישן של Android Automotive.
• [7.5/A-SR-3] מומלץ מאוד להשתמש בחומרה עם מוקד קבוע או עם EDOF (עומק שדה מורחב).
• [7.5/A-1-2] חובה שהמצלמה הראשית הפונה לעולם תהיה המצלמה הפונה לעולם עם מזהה המצלמה הנמוך ביותר.

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

• [7.5/A-2-1] המצלמה הראשית הפונה למשתמש חייבת להיות המצלמה הפונה למשתמש עם מזהה המצלמה הנמוך ביותר.
• אפשר להציב אותה כך שהמימד הארוך של המצלמה יתיישר עם מישור X-Y של צירי החיישנים של Android Automotive.

אם הטמעות של מכשירים לכלי רכב כוללות מצלמה שאפשר לגשת אליה דרך API של android.hardware.Camera או android.hardware.camera2, הן:

• [7.5/A-3-1] חובה לעמוד בדרישות המרכזיות למצלמה שמפורטות בקטע 7.5.

אם הטמעות של מכשירי רכב כוללות מצלמה שאין גישה אליה דרך android.hardware.Camera API או android.hardware.camera2 API, הן:

• [7.5/A-4-1] חובה שאפשר יהיה לגשת אליו דרך שירות המערכת של תצוגה מורחבת.

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

• [7.5/A-5-1] אסור לסובב או להפוך את התצוגה המקדימה של המצלמה.
• [7.5/A-SR-4] מומלץ מאוד שהרזולוציה שלהן תהיה לפחות 1.3 מגה-פיקסל.

אם הטמעות של מכשירים לכלי רכב כוללות מצלמה אחת או יותר שאפשר לגשת אליהן גם דרך שירות המערכת של תצוגה מורחבת וגם דרך android.hardware.Camera או android.hardware.Camera2 API, אז למצלמה כזו:

• [7.5/A-6-1] חובה לדווח על אותו מזהה מצלמה.

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

• [7.5/A-7-1] חובה להטמיע ממשק API כזה של מצלמה באמצעות API של android.hardware.camera2 או API של מערכת תצוגה מורחבת.

סיום הדרישות החדשות

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

• [7.6.1/A-0-1] חייב להיות לפחות 4GB של אחסון לא נדיף שזמין לנתונים הפרטיים של האפליקציה (המכונה גם מחיצה '/data').

• [7.6.1/A] צריך לעצב את מחיצה הנתונים כדי לשפר את הביצועים ואת משך החיים של האחסון בזיכרון פלאש, למשל באמצעות מערכת הקבצים f2fs.

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

• [7.6.1/A-SR-1] מומלץ מאוד לצמצם את התקורה של הקלט/פלט (I/O) בפעולות שמבוצעות באחסון החיצוני, למשל באמצעות SDCardFS.

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

• [7.6.1/A-2-1] אם משתמשים באחת מהצפיפויות הבאות, נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 816MB:

  • 280dpi או פחות במסכים קטנים או רגילים
  • ldpi או פחות במסכים גדולים במיוחד
  • mdpi או פחות במסכים גדולים

• [7.6.1/A-2-2] אם משתמשים באחת מהצפיפויות הבאות, נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 944MB:

  • xhdpi ומעלה במסכים קטנים/רגילים
  • hdpi ומעלה במסכים גדולים
  • mdpi ומעלה במסכים גדולים במיוחד

• [7.6.1/A-2-3] אם משתמשים באחת מהצפיפויות הבאות, נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 1,280MB:

  • 400dpi או יותר במסכים קטנים/רגילים
  • xhdpi ומעלה במסכים גדולים
  • tvdpi ומעלה במסכים גדולים במיוחד

• [7.6.1/A-2-4] אם משתמשים באחת מהצפיפויות הבאות, נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 1,824MB:

  • 560dpi או יותר במסכים קטנים או רגילים
  • 400dpi או יותר במסכים גדולים
  • xhdpi ומעלה במסכים גדולים במיוחד

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

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

• [7.7.1/A] צריכה לכלול יציאת USB שתומכת במצב ציוד היקפי.

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

• [7.8.1/A-0-1] חובה לכלול מיקרופון.

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

• [7.8.2/A-0-1] חובה שיהיה פלט אודיו ויש להצהיר על android.hardware.audio.output.

2.5.2. מולטימדיה

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

• [5.1/A-0-1] MPEG-4 AAC Profile‏ (AAC LC)
• [5.1/A-0-2] MPEG-4 HE AAC Profile‏ (AAC+)
• [5.1/A-0-3] AAC ELD (‏AAC משופר עם זמן אחזור קצר)

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

• [5.2/A-0-1] H.264 AVC
• [5.2/A-0-2] VP8

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

• [5.3/A-0-1] H.264 AVC
• [5.3/A-0-2] MPEG-4 SP
• [5.3/A-0-3] VP8
• [5.3/A-0-4] VP9

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

• [5.3/A-SR-1] H.265 HEVC

2.5.3. תוכנות

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

• [3/A-0-1] חובה להצהיר על התכונה android.hardware.type.automotive.

• [3/A-0-2] חובה לתמוך ב-uiMode = UI_MODE_TYPE_CAR.

• [3/A-0-3] חובה לתמוך בכל ממשקי ה-API הציבוריים במרחב השמות android.car.*.

אם הטמעות של מכשירי רכב מספקות API קנייני באמצעות android.car.CarPropertyManager עם android.car.VehiclePropertyIds, הן:

• [3/A-1-1] אסור לצרף הרשאות מיוחדות לשימוש של אפליקציית המערכת במאפיינים האלה, או למנוע מאפליקציות של צד שלישי להשתמש במאפיינים האלה.
• [3/A-1-2] אסור לשכפל נכס רכב שכבר קיים ב-SDK.

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

• [3.2.1/A-0-1] חובה לתמוך בכל המשתנים הקבועים של ההרשאות ולאכוף אותם, כפי שמתואר בדף העזרה בנושא הרשאות לכלי רכב.

• [3.2.3.1/A-0-1] חובה לטעון מראש אפליקציה אחת או יותר או רכיבי שירות עם טיפול בכוונה, לכל דפוסי המסננים הציבוריים של הכוונה שהוגדרו על ידי כוונות האפליקציה הבאות שמפורטות כאן.

• [3.4.1/A-0-1] חובה לספק הטמעה מלאה של ה-API android.webkit.Webview.

יצירת דרישות חדשות

• [3.8/A-0-1] אסור לאפשר למשתמשים משניים מלאים שאינם המשתמש הנוכחי בחזית להפעיל פעילויות ולקבל גישה לממשק המשתמש בכל המסכים.

סיום הדרישות החדשות

• [3.8.3/A-0-1] חובה להציג התראות שמשתמשות ב-API של Notification.CarExtender כשאפליקציות צד שלישי מבקשות זאת.

• [3.8.4/A-SR-1] מומלץ מאוד להטמיע עוזר במכשיר כדי לטפל בפעולת Assist.

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

• [3.8.4/A-1-1] חובה להשתמש בלחיצה קצרה על לחצן הלחיצה-לדיבור כאינטראקציה הייעודית להפעלת אפליקציית העזרה שבחר המשתמש, כלומר האפליקציה שמטמיעה את VoiceInteractionService.

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

• [3.8.3.1/A-0-1] חובה להציג משאבים בצורה נכונה כפי שמתואר במסמכי התיעוד של Notifications on Automotive OS SDK.
• [3.8.3.1/A-0-2] חובה להציג את הלחצנים 'הפעלה' ו'השתקה' לפעולות התראות במקום הלחצנים שסופקו דרך Notification.Builder.addAction()
• [3.8.3.1/A] צריך להגביל את השימוש במשימות ניהול מתקדמות, כמו אמצעי בקרה לכל ערוץ התראות. מותר להשתמש בתכונות של ממשק המשתמש לכל אפליקציה כדי לצמצם את אמצעי הבקרה.

אם הטמעות של מכשירים לכלי רכב תומכות במאפייני HAL של משתמשים, הן:

• [3.9.3/A-1-1] חובה להטמיע את כל המאפיינים של מחזור החיים של המשתמש
  • INITIAL_USER_INFO, SWITCH_USER, CREATE_USER, REMOVE_USER.

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

• [3.14/A-0-1] חובה לכלול מסגרת של ממשק משתמש כדי לתמוך באפליקציות צד שלישי שמשתמשות בממשקי ה-API של המדיה, כפי שמתואר בקטע 3.14.
• [3.14/A-0-2] חובה לאפשר למשתמש לבצע אינטראקציה בטוחה עם אפליקציות מדיה בזמן נהיגה.
• [3.14/A-0-3] חובה לתמוך בפעולה המשתמעת של CAR_INTENT_ACTION_MEDIA_TEMPLATE ב-Intent עם הרכיב הנוסף CAR_EXTRA_MEDIA_PACKAGE.
• [3.14/A-0-4] חובה לספק אפשרות לניווט לפעילות ההעדפות של אפליקציית המדיה, אבל חובה להפעיל אותה רק כשההגבלות על חוויית המשתמש ברכב לא בתוקף.
• [3.14/A-0-5] חובה להציג הודעות שגיאה שהוגדרו על ידי Media Applications, וחובה לתמוך בתוספים האופציונליים ERROR_RESOLUTION_ACTION_LABEL ו-ERROR_RESOLUTION_ACTION_INTENT.
• [3.14/A-0-6] חובה לתמוך בתכונה לחיפוש באפליקציה לאפליקציות שתומכות בחיפוש.
• [3.14/A-0-7] חובה לפעול בהתאם להגדרות של CONTENT_STYLE_BROWSABLE_HINT ושל CONTENT_STYLE_PLAYABLE_HINT כשמציגים את ההיררכיה של MediaBrowser.

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

• [3.14/A-1-1] חובה לכלול שירותי מדיה ולפתוח אותם באמצעות הכוונה CAR_INTENT_ACTION_MEDIA_TEMPLATE.

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

• [3.8/A] יכול להגביל את הבקשות של האפליקציה לעבור למצב מסך מלא כפי שמתואר בקטע immersive documentation.
• [3.8/A] יכול להיות ששורת הסטטוס וסרגל הניווט יהיו גלויים תמיד.
• [3.8/A] יכול להגביל את הבקשות של האפליקציה לשינוי הצבעים שמאחורי רכיבי ממשק המשתמש של המערכת, כדי לוודא שהרכיבים האלה גלויים תמיד בבירור.

2.5.4. ביצועים וצריכת חשמל

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

• [8.2/A-0-1] חובה לדווח על מספר הבייטים שנקראים ונכתבים באחסון לא נדיף לכל מזהה UID של תהליך, כדי שהנתונים הסטטיסטיים יהיו זמינים למפתחים דרך System API‏ android.car.storagemonitoring.CarStorageMonitoringManager. פרויקט הקוד הפתוח של Android עומד בדרישות באמצעות מודול הליבה uid_sys_stats.
• [8.3/A-1-3] חובה לתמוך במצב מוסך.
• [8.3/A] צריך להיות במצב 'חניה' למשך לפחות 15 דקות אחרי כל נסיעה, אלא אם:
  • הסוללה ריקה.
  • לא מתבצעת תזמון של משימות במצב חוסר פעילות.
  • הנהג יוצא ממצב 'חניה'.
• [8.4/A-0-1] חובה לספק פרופיל צריכת אנרגיה לכל רכיב, שמגדיר את ערך הצריכה הנוכחית של כל רכיב חומרה ואת הירידה המשוערת בנפח הסוללה שנגרמת על ידי הרכיבים לאורך זמן, כפי שמופיע באתר של Android Open Source Project.
• [8.4/A-0-2] חובה לדווח על כל ערכי צריכת האנרגיה בשעות מיליאמפר (mAh).
• [8.4/A-0-3] חובה לדווח על צריכת החשמל של המעבד לכל מזהה משתמש (UID) של תהליך. פרויקט הקוד הפתוח של Android עומד בדרישות באמצעות הטמעת מודול הליבה uid_cputime.
• [8.4/A] צריך לשייך לרכיב החומרה עצמו אם לא ניתן לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.
• [8.4/A-0-4] חובה להפוך את צריכת האנרגיה הזו לזמינה למפתח האפליקציה באמצעות הפקודה adb shell dumpsys batterystats.

2.5.5. מודל אבטחה

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

• [9.5/A-1-1] אסור לאפשר למשתמשים לקיים אינטראקציה עם משתמש המערכת ללא ראש או לעבור אליו, מלבד הקצאת מכשיר.
• [9.5/A-1-2] חובה לעבור למשתמש משני לפני BOOT_COMPLETED.
• [9.5/A-1-3] חובה לתמוך באפשרות ליצור משתמש אורח גם אם מספר המשתמשים המקסימלי במכשיר הושג.

יצירת דרישות חדשות

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

• [9.8.2/A-1-1] חובה להציג את סמל המיקרופון כשאפליקציה ניגשת לנתוני אודיו מהמיקרופון, אבל לא כשHotwordDetectionService, ‏ SOURCE_HOTWORD,‏ ContentCaptureService או אפליקציות עם התפקידים שמפורטים בקטע 9.1 עם מזהה CDD‏ [C-4-X] ניגשים למיקרופון.
• [9.8.2/A-1-2] אסור להסתיר את האינדיקטור של המיקרופון באפליקציות מערכת שיש להן ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמש.
• [9.8.2/A-1-3] חובה לספק למשתמש אפשרות להפעיל או להשבית את המיקרופון באפליקציית ההגדרות.

סיום הדרישות החדשות

אם הטמעות של מכשירי רכב מצהירות על android.hardware.camera.any, הן:

• [9.8.2/A-2-1] חובה להציג את סמל המצלמה כשאפליקציה ניגשת לנתוני מצלמה בשידור חי, אבל לא כשאפליקציות עם התפקידים שמוגדרים שצוינו בקטע 9.1 הרשאות עם מזהה CDD‏ [C-4-X][C-3-X] ניגשות למצלמה בלבד.
• [9.8.2/A-2-2] אסור להסתיר את האינדיקטור של המצלמה באפליקציות מערכת שיש להן ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמש.

יצירת דרישות חדשות

• [9.8.2/A-2-3] חובה לספק למשתמש אפשרות להפעיל או להשבית את המצלמה באפליקציית ההגדרות.
• [9.8.2/A-2-4] חובה להציג את האפליקציות האחרונות והפעילות באמצעות המצלמה, כפי שהן מופיעות ב-PermissionManager.getIndicatorAppOpUsageData(), יחד עם הודעות שיוך שמשויכות אליהן.

סיום הדרישות החדשות

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

• [9/A-0-1] חובה להצהיר על התכונה android.hardware.security.model.compatible.
• [9.11/A-0-1] חובה לגבות את הטמעת מאגר המפתחות באמצעות סביבת הפעלה מבודדת.
• [9.11/A-0-2] חובה שתהיה הטמעה של אלגוריתמים קריפטוגרפיים מסוג RSA, ‏ AES,‏ ECDSA ו-HMAC ופונקציות גיבוב ממשפחת MD5, ‏ SHA1 ו-SHA-2, כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בליבה ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד הליבה או קוד מרחב המשתמש עשוי לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. בפרויקט Android Open Source (AOSP) ב-upstream מתקיימים הדרישות האלה באמצעות ההטמעה של Trusty, אבל יש גם אפשרויות חלופיות: פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת של בידוד תקין שמבוסס על hypervisor, שעבר בדיקה על ידי צד שלישי.
• [9.11/A-0-3] חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק אם הוא מצליח, לאפשר שימוש במפתחות שמקושרים לאימות. חובה לאחסן את פרטי הכניסה של מסך הנעילה באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. בפרויקט הקוד הפתוח של Android תוכלו למצוא את שכבת האובייקטים המצומצמים לחומרה (HAL) של Gatekeeper ו-Trusty, שאפשר להשתמש בהם כדי לעמוד בדרישות האלה.
• [9.11/A-0-4] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה לאימות מוגן על ידי חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה לאימות במספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת מהדרכים לעמוד בדרישות האלה היא לשתף את אותו מפתח אימות, אלא אם מיוצרות לפחות 100,000 יחידות של מק"ט נתון. אם מיוצרות יותר מ-100,000 יחידות של מק"ט מסוים, יכול להיות שייעשה שימוש במפתח שונה לכל 100,000 יחידות.

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

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

• [9.14/A-0-1] חובה לנהל את ההודעות שמגיעות ממערכי המשנה של הרכב במסגרת Android, למשל, הוספה לרשימת ההיתרים של סוגי ההודעות ומקורות ההודעות המותרים.
• [9.14/A-0-2] חובה להפעיל מעקב אחר התקפות מניעת שירות (DoS) מהמסגרת של Android או מאפליקציות של צד שלישי. כך אפשר למנוע מתוכנות זדוניות להציף את הרשת של הרכב בתנועה, דבר שעלול לגרום לפעולה לא תקינה של תת-מערכות ברכב.

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

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

• Perfetto
  • [6.1/A-0-1] חובה לחשוף למשתמש המעטפת קובץ בינארי של /system/bin/perfetto, שבו שורת הפקודה תואמת למסמכי התיעוד של perfetto.
  • [6.1/A-0-2] קובץ הבינארי של perfetto חייב לקבל כקלט קובץ תצורה של protobuf שתואם לסכימה שמוגדרת במסמכי התיעוד של perfetto.
  • [6.1/A-0-3] קובץ הבינארי של perfetto חייב לכתוב כפלט נתיב protobuf שתואם לסכימה שמוגדרת במסמכי התיעוד של perfetto.
  • [6.1/A-0-4] חובה לספק, באמצעות הקובץ הבינארי של perfetto, לפחות את מקורות הנתונים שמתוארים במסמכי התיעוד של perfetto.

2.6. דרישות לגבי טאבלטים

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

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

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

• המסך צריך להיות בגודל של יותר מ-7" ופחות מ-18", נמדד באלכסון.

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

2.6.1. חומרה

ג'ירוסקופ

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

• [7.3.4/Tab-1-1] חייב להיות מסוגל למדוד שינויים בכיוון עד 1,000 מעלות לשנייה.

זיכרון ואחסון מינימלי (סעיף 7.6.1)

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

מצב ציוד היקפי USB (סעיף 7.7.1)

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

• [7.7.1/Tab] יכולים להטמיע את Android Open Accessory (AOA) API.

מצב מציאות מדומה (סעיף 7.9.1)

ביצועים גבוהים במציאות מדומה (סעיף 7.9.2)

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

2.6.2. מודל אבטחה

מפתחות ופרטי כניסה (סעיף 9.11)

אפשר לעיין בקטע [9.11].

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

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

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

• [9.5/T-2-1] אסור לתמוך בפרופילים מוגבלים, אבל חובה להתאים את ההטמעה של אמצעי הבקרה ב-AOSP כדי לאפשר או להשבית למשתמשים אחרים גישה לשיחות הקוליות ול-SMS.

2.6.2. תוכנות

• [3.2.3.1/Tab-0-1] חובה לטעון מראש אפליקציה אחת או יותר או רכיבי שירות עם טיפול בכוונה (intent), לכל דפוסי המסננים הציבוריים של הכוונה שהוגדרו על ידי כוונות האפליקציה הבאות שמפורטות כאן.

3. תוכנות

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

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

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

• [C-0-1] חובה לספק הטמעות מלאות, כולל כל ההתנהגויות המתועדות, של כל ממשק API מתועד שחשוף על ידי Android SDK או כל ממשק API שמעוטר בסמן ‎@SystemApi בקוד המקור של Android במקור.

• [C-0-2] חובה לתמוך בכל הכיתות, השיטות והרכיבים המשויכים שמסומנים בהערה TestApi‏ (@TestApi).

• [C-0-3] אסור להשמיט ממשקי API מנוהלים, לשנות ממשקי API או חתימות שלהם, לסטות מההתנהגות המתועדת או לכלול פעולות ללא פעולה (no-ops), אלא אם מותר לעשות זאת במפורש בהגדרת התאימות הזו.

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

• [C-0-5] אסור לאפשר לאפליקציות צד שלישי להשתמש בממשקים שאינם SDK, שמוגדרים כשיטות ושדות בחבילות של שפת Java שנמצאות בנתיב הטעינה של AOSP, ולא נכללות ב-SDK הציבורי. הרשאות הגישה האלה כוללות ממשקי API עם ההערה @hide, אבל לא עם @SystemAPI, כפי שמתואר במסמכים של ה-SDK, וגם חברי כיתות פרטיים וחברי כיתות שהגישה אליהם מוגבלת לחבילה.

• [C-0-6] חובה לשלוח כל ממשק שאינו SDK עם אותן רשימות מוגבלות שסופקו באמצעות הדגלים הזמניים והדגלים של רשימת הדחייה בנתיב prebuilts/runtime/appcompat/hiddenapi-flags.csv להסתעפות המתאימה ברמת ה-API ב-AOSP.

• [C-0-7] חובה לתמוך במנגנון העדכון הדינמי של signed config כדי להסיר ממשקים שאינם SDK מרשימת מכשירים מוגבלת, על ידי הטמעת תצורה חתומה בכל חבילת APK, באמצעות המפתחות הציבוריים הקיימים ב-AOSP.

  עם זאת, הם:

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

יצירת דרישות חדשות

• [C-0-8] אסור לתמוך בהתקנה של אפליקציות שמטרגטות לרמת API נמוכה מ-23.

סיום הדרישות החדשות

3.1.1. תוספים ל-Android

ב-Android יש תמיכה בהרחבת ממשק ה-API המנוהל של רמת API מסוימת על ידי עדכון גרסת התוסף של רמת ה-API הזו. ה-API של android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) מחזיר את גרסת התוסף של apiLevel שסופק, אם יש תוספים לרמת ה-API הזו.

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

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

• [C-0-2] חובה להחזיר רק מספר גרסה תקין של התוסף שהוגדר על ידי AOSP.

• [C-0-3] חובה לתמוך בכל ממשקי ה-API שמוגדרים בגרסאות התוסף שמוחזרות על ידי android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) באותה דרך שבה יש תמיכה בממשקי API מנוהלים אחרים, בהתאם לדרישות שמפורטות בקטע 3.1.

3.1.2. ספריית Android

עקב הוצאה משימוש של לקוח ה-HTTP של Apache, בהטמעות במכשירים:

• [C-0-1] אסור להציב את הספרייה org.apache.http.legacy ב-bootclasspath.
• [C-0-2] חובה להוסיף את הספרייה org.apache.http.legacy ל-classpath של האפליקציה רק אם האפליקציה עומדת באחד מהתנאים הבאים:
  • הטירגוט הוא לרמת API 28 ומטה.
  • מצהירה ב-manifest שלה שהיא זקוקה לספרייה על ידי הגדרת המאפיין android:name של <uses-library> לערך org.apache.http.legacy.

ההטמעה של AOSP עומדת בדרישות האלה.

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

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

3.2.1. הרשאות

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

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

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

• [C-0-1] כדי לספק ערכים עקביים ומשמעותיים בכל הטמעות המכשירים, בטבלה הבאה מפורטות הגבלות נוספות על הפורמטים של הערכים האלה, שאליהם הטמעות המכשירים חייבות לעמוד.

פרמטר	פרטים
VERSION.RELEASE	הגרסה של מערכת Android שפועלת כרגע, בפורמט קריא לבני אדם. השדה הזה חייב לכלול אחד מערכי המחרוזות שמוגדרים בקטע מחרוזות גרסאות מותרות ל-Android 14.
VERSION.SDK	הגרסה של מערכת Android שפועלת כרגע, בפורמט שגלוי לקוד של אפליקציות של צד שלישי. לגבי Android 14, השדה הזה חייב לכלול את הערך השלם 14_INT.
VERSION.SDK_INT	הגרסה של מערכת Android שפועלת כרגע, בפורמט שגלוי לקוד של אפליקציות של צד שלישי. לגבי Android 14, השדה הזה חייב לכלול את הערך השלם 14_INT.
VERSION.INCREMENTAL	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמציין את גרסת ה-build הספציפית של מערכת Android שפועלת כרגע, בפורמט שקריא לבני אדם. אסור להשתמש שוב בערך הזה לגרסאות build שונות שזמינות למשתמשי קצה. השימוש הנפוץ בשדה הזה הוא לציין את מספר ה-build או את מזהה השינוי במערכת בקרת הגרסאות ששימשו ליצירת ה-build. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט שאפשר להדפיס, ולהתאים לביטוי הרגולרי ‎^[^ :\/~]+$‎.
משחקי לוח	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את החומרה הפנימית הספציפית שבה המכשיר משתמש, בפורמט שקריא לבני אדם. אפשר להשתמש בשדה הזה כדי לציין את הגרסה הספציפית של הלוח שמפעיל את המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי ‎“^[a-zA-Z0-9_-]+$‎”.
BRAND	ערך שמשקף את שם המותג שמשויך למכשיר כפי שהוא ידוע למשתמשי הקצה. חייב להיות בפורמט שאפשר לקרוא אותו, וצריך לייצג את היצרן של המכשיר או את מותג החברה שדרכו המכשיר משווק. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי ‎“^[a-zA-Z0-9_-]+$‎”.
SUPPORTED_ABIS	השם של קבוצת ההוראות (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי.
SUPPORTED_32_BIT_ABIS	השם של קבוצת ההוראות (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי.
SUPPORTED_64_BIT_ABIS	השם של קבוצת ההוראות השנייה (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי.
CPU_ABI	השם של קבוצת ההוראות (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי.
CPU_ABI2	השם של קבוצת ההוראות השנייה (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי.
מכשיר	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם הפיתוח או שם הקוד שמזהה את ההגדרה של תכונות החומרה ואת העיצוב התעשייתי של המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד בתור ASCII של 7 ביט ולהתאים לביטוי הרגולרי '^[a-zA-Z0-9_-]+$'. אסור לשנות את שם המכשיר במהלך משך החיים של המוצר.
FINGERPRINT	מחרוזת שמזהה באופן ייחודי את ה-build הזה. הוא אמור להיות קריא לאנשים באופן סביר. היא חייבת לפעול לפי התבנית הבאה: $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) לדוגמה: acme/myproduct/     mydevice:14/LMYXX/3359:userdebug/test-keys האצבעית אסור שתכלול תווים של רווח לבן. הערך בשדה הזה חייב להיות ניתן לקידוד כ-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 או כמחרוזת ריקה (""). אסור לשנות את השדה הזה במהלך מחזור החיים של המוצר.
SOC_MANUFACTURER	השם המסחרי של היצרן של מערכת ה-SOC הראשית שמשמשת במוצר. במכשירים עם אותו יצרן של SoC צריך להשתמש באותו ערך קבוע. יש לפנות ליצרן ה-SOC כדי לקבל את הקבוע הנכון לשימוש. הערך בשדה הזה חייב להיות ניתן לקידוד בתור ASCII של 7 ביט, חייב להתאים לביטוי הרגולרי ‎"^([0-9A-Za-z ]+)", אסור שיתחיל או יסתיים ברווחים ואסור שיהיה שווה ל-'unknown'. השדה הזה אסור שישתנה במהלך משך החיים של המוצר.
SOC_MODEL	שם הדגם של המערכת הראשית על שבב (SoC) שמשמשת במוצר. במכשירים עם אותו מודל SOC צריך להשתמש באותו ערך קבוע. יש לפנות ליצרן ה-SOC כדי לקבל את הקבוע הנכון לשימוש. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי ‎“^([0-9A-Za-z ._/+-]+)$‎”, אסור שהוא יתחיל או יסתיים במרווחים אסור שהוא יהיה שווה ל-'unknown'. השדה הזה אסור שישתנה במהלך משך החיים של המוצר.
דגם	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם המכשיר כפי שהוא ידוע למשתמש הקצה. השם הזה צריך להיות זהה לשם שתחתיו המכשיר משווק ונמכר למשתמשי הקצה. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או מחרוזת ריקה (""). אסור לשנות את השדה הזה במהלך מחזור החיים של המוצר.
מוצר	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם הפיתוח או שם הקוד של המוצר הספציפי (מק"ט), שחובה שיהיה ייחודי באותו מותג. חייב להיות קריא לבני אדם, אבל לא בהכרח מיועד לצפייה על ידי משתמשי קצה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט, ולהתאים לביטוי הרגולרי '^‎[a-zA-Z0-9_-]+$‎'. אסור לשנות את שם המוצר במהלך כל משך החיים שלו.
ODM_SKU	ערך אופציונלי שנבחר על ידי מי שמטמיע את המכשיר, שמכיל מק"ט (מספר קטלוגי) המשמש למעקב אחרי הגדרות ספציפיות של המכשיר, למשל ציוד היקפי כלשהו שכלול במכשיר כשהוא נמכר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי ^([0-9A-Za-z.,_-]+)$.
SERIAL	חובה להחזיר את הערך 'UNKNOWN'.
תגים	רשימה של תגים מופרדים בפסיקים שנבחרו על ידי מי שמטמיע את המכשיר, שמבדילה עוד יותר את ה-build. חובה שאפשר יהיה לקודד את התגים כ-ASCII של 7 ביט, שתהיה התאמה לביטוי הרגולרי ‎“^[a-zA-Z0-9._-]+‎” ושיהיו להם אחד מהערכים התואמים לשלושת הגדרות החתימה הטיפוסיות של פלטפורמת Android: release-keys, ‏ dev-keys ו-test-keys.
שעה	ערך שמייצג את חותמת הזמן של מועד ה-build.
סוג	ערך שנבחר על ידי מי שמטמיע את המכשיר, ומציין את הגדרת סביבת זמן הריצה של ה-build. השדה הזה חייב לכלול אחד מהערכים שתואמים לשלושת ההגדרות הנפוצות של Android בסביבת זמן ריצה: user,‏ userdebug או eng.
משתמש	שם או מזהה משתמש של המשתמש (או המשתמש האוטומטי) שיצר את ה-build. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
SECURITY_PATCH	ערך שמציין את רמת תיקון האבטחה של גרסה זמינה ל-build. חובה לציין שה-build לא חשוף בשום צורה לאף אחת מהבעיות המתוארות בעדכון האבטחה הציבורי הייעודי של Android. הוא חייב להיות בפורמט [YYYY-MM-DD] ותואם למחרוזת מוגדרת שמופיעה בעדכון האבטחה הציבורי של Android או ב עדכון האבטחה של Android, לדוגמה '2015-11-01'.
BASE_OS	ערך שמייצג את הפרמטר FINGERPRINT של ה-build, שהוא זהה ל-build הזה מלבד התיקונים שסופקו בעדכון האבטחה הציבורי של Android. חובה לדווח על הערך הנכון, ואם לא קיים build כזה, צריך לדווח על מחרוזת ריקה ("").
BOOTLOADER	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את גרסת האתחול הפנימית הספציפית שמשמשת במכשיר, בפורמט שקריא לבני אדם. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי ‎^[a-zA-Z0-9._-]+$‎.
getRadioVersion()	הערך חייב להיות (או להחזיר) ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את גרסת הרדיו/המודם הפנימית הספציפית שמשמשת במכשיר, בפורמט שקריא לבני אדם. אם למכשיר אין רדיו/מודם פנימיים, חובה להחזיר את הערך NULL. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי ‎“^[a-zA-Z0-9._-,]+$”.
getSerial()	חובה (להיות או להחזיר) מספר סידורי של חומרה, שחייב להיות זמין וייחודי במכשירים עם אותו דגם ויצרן. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי ‎^[a-zA-Z0-9]+$‎.

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

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

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

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

• [C-SR-1] מומלץ מאוד לטעון מראש אפליקציה אחת או יותר או רכיבי שירות עם בורר כוונות, לכל דפוסי המסנן הציבוריים של הכוונות שמוגדרים על ידי כוונות האפליקציה הבאות שמפורטות כאן, ולספק השלמה, כלומר לעמוד בציפיות של המפתח לגבי כוונות האפליקציה הנפוצות האלה כפי שמתואר ב-SDK.

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

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

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

• [C-0-2] אסור למטמיעים של מכשירים לצרף הרשאות מיוחדות לשימוש של אפליקציות המערכת בדפוסי הכוונה האלה, או למנוע מאפליקציות צד שלישי לקשר את עצמן לדפוסים האלה ולשלוט בהם. האיסור הזה כולל, בין היתר, השבתה של ממשק המשתמש 'בורר' שמאפשר למשתמש לבחור בין כמה אפליקציות שמטפלות באותו דפוס כוונה.

• [C-0-3] הטמעות במכשירים חייבות לספק ממשק משתמש שמאפשר למשתמשים לשנות את פעילות ברירת המחדל של הכוונות.

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

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

• [C-0-4] חובה לנסות לאמת מסנני Intent על ידי ביצוע שלבי האימות שמוגדרים במפרט של Digital Asset Links, כפי שהם מיושמים על ידי מנהל החבילות ב-Android Open Source Project (פרויקט Android בקוד פתוח) במקור.
• [C-0-5] חובה לנסות לאמת את מסנני הכוונה במהלך התקנת האפליקציה ולהגדיר את כל מסנני הכוונה של URI שאומתו כמטפלי אפליקציה שמוגדרים כברירת מחדל למזהי ה-URI שלהם.
• יכולים להגדיר מסנני כוונה ספציפיים של URI כמפעילי אפליקציה שמוגדרים כברירת מחדל למזהי ה-URI שלהם, אם הם אומתו בהצלחה אבל מסנני URI אחרים לא עברו את תהליך האימות. אם הטמעה במכשיר עושה זאת, היא חייבת לספק למשתמש את השינויים המתאימים לדפוס לכל URI בתפריט ההגדרות.
• חובה לספק למשתמש אמצעי בקרה לכל אפליקציה של קישורי אפליקציות בהגדרות, באופן הבא:
  • [C-0-6] המשתמש חייב להיות מסוגל לשנות באופן מקיף את ברירת המחדל של התנהגות הקישורים לאפליקציה, כך שהיא תהיה: תמיד פתיחה, תמיד שאלה או אף פעם לא פתיחה. המדיניות הזו חייבת לחול באופן שווה על כל מסנני הכוונה של URI מועמדים.
  • [C-0-7] המשתמש חייב להיות מסוגל לראות רשימה של מסנני הכוונה ל-URI שעומדים בקריטריונים.
  • הטמעת המכשיר עשויה לספק למשתמש את היכולת לשנות את ההגדרות של מסנני הכוונה ספציפיים של URI שהתקבלו ואשר אומתו, על בסיס מסנן כוונה לכל אחד מהם.
  • [C-0-8] אם ההטמעה במכשיר מאפשרת לחלק ממסנני הכוונה של כתובות URI מועמדות לעבור אימות, בעוד שחלק אחר לא עובר, ההטמעה במכשיר חייבת לספק למשתמשים את היכולת להציג ולשנות את ההגדרות של מסנני הכוונה הספציפיים של כתובות URI מועמדות.

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

• [C-0-1] אסור שרכיבי הטמעה של המכשיר יכללו רכיב Android שמתייחס לתבניות חדשות של כוונות או כוונות שידור באמצעות ACTION,‏ CATEGORY או מחרוזת מפתח אחרת במרחב השמות android.* או com.android.*.
• [C-0-2] אסור למטמיעים של מכשירים לכלול רכיבי Android שמכבדים דפוסי כוונה חדשים או דפוסי כוונה לשידור באמצעות ACTION,‏ CATEGORY או מחרוזת מפתח אחרת במרחב החבילה ששייך לארגון אחר.
• [C-0-3] אסור למטמיעים של מכשירים לשנות או להרחיב אף אחד מדפוסי הכוונה שמפורטים בסעיף 3.2.3.1.
• הטמעות במכשירים יכולות לכלול דפוסי כוונה שמשתמשים במרחבי שמות שמשויכים בבירור לארגון שלהם. האיסור הזה דומה לאיסור שצוין לגבי כיתות בשפת Java בסעיף 3.6.

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

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

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

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

3.2.3.5. כוונות מותנות של אפליקציות

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

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

אם הטמעות של מכשירים מדווחות על android.software.home_screen, הן:

• [C-1-1] חובה לפעול בהתאם לכוונה של android.settings.HOME_SETTINGS להציג תפריט של הגדרות ברירת מחדל של אפליקציות במסך הבית.

אם הטמעות של מכשירים מדווחות על android.hardware.telephony.calling, הן:

• [C-2-1] חובה לספק תפריט הגדרות שיפעיל את הכוונה android.provider.Telephony.ACTION_CHANGE_DEFAULT כדי להציג תיבת דו-שיח לשינוי אפליקציית ברירת המחדל ל-SMS.

• [C-2-2] חובה לפעול בהתאם לכוונה של android.telecom.action.CHANGE_DEFAULT_DIALER להציג תיבת דו-שיח כדי לאפשר למשתמש לשנות את אפליקציית ברירת המחדל של הטלפון.

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

• [C-2-3] חובה לפעול בהתאם לכוונה של android.telecom.action.CHANGE_PHONE_ACCOUNTS כדי לספק למשתמש אפשרות להגדיר את ConnectionServices שמשויך ל-PhoneAccounts, וגם PhoneAccount שמוגדר כברירת מחדל ומשמש את ספק שירותי התקשורת לביצוע שיחות יוצאות. ההטמעה ב-AOSP עומדת בדרישות האלה על ידי הכללת תפריט 'אפשרויות של חשבונות לשיחות' בתפריט ההגדרות 'שיחות'.

• [C-2-4] חובה לאפשר את android.telecom.CallRedirectionService לאפליקציה שיש לה את התפקיד android.app.role.CALL_REDIRECTION.

• [C-2-5] חובה לספק למשתמש אפשרות לבחור אפליקציה עם התפקיד android.app.role.CALL_REDIRECTION.

• [C-2-6] חובה לפעול בהתאם ל-Intents‏ android.intent.action.SENDTO ו-android.intent.action.VIEW ולספק פעילות לשליחה/להצגה של הודעות SMS.

• [C-SR-1] מומלץ מאוד לתמוך ב-Intents‏ android.intent.action.ANSWER,‏ android.intent.action.CALL,‏ android.intent.action.CALL_BUTTON,‏ android.intent.action.VIEW ו-android.intent.action.DIAL באמצעות אפליקציית חיוג שהוטענה מראש, שיכולה לטפל ב-Intents האלה ולספק את הביצוע כפי שמתואר ב-SDK.

אם הטמעות של מכשירים מדווחות על android.hardware.nfc.hce, הן:

• [C-3-1] חובה לפעול בהתאם לכוונה של android.settings.NFC_PAYMENT_SETTINGS כדי להציג תפריט הגדרות ברירת מחדל של אפליקציה לתשלום ללא מגע.
• [C-3-2] חובה לכבד את הכוונה android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT כדי להציג פעילות שפותחת תיבת דו-שיח שבה המשתמש מתבקש לשנות את שירות ברירת המחדל של הדמיית הכרטיס לקטגוריה מסוימת, כפי שמתואר ב-SDK.

אם הטמעות של מכשירים מדווחות על android.hardware.nfc, הן:

• [C-4-1] חובה לפעול בהתאם למטרות האלה: android.nfc.action.NDEF_DISCOVERED,‏ android.nfc.action.TAG_DISCOVERED ו-android.nfc.action.TECH_DISCOVERED, כדי להציג פעילות שעומדת בציפיות של המפתחים לגבי המטרות האלה, כפי שמתואר ב-SDK.

אם הטמעות של מכשירים מדווחות על android.hardware.bluetooth, הן:

• [C-5-1] חובה לפעול בהתאם לכוונה android.bluetooth.adapter.action.REQUEST_ENABLE ולהציג פעילות מערכת כדי לאפשר למשתמש להפעיל את ה-Bluetooth.
• [C-5-2] חובה לפעול בהתאם לכוונה android.bluetooth.adapter.action.REQUEST_DISCOVERABLE ולהציג פעילות מערכת שמבקשת מצב גלוי.

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

• [C-6-1] חובה להטמיע פעילות שתגיב ל-intent‏ ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS. כשמשתמשים ב-UI_MODE_TYPE_NORMAL, הפעילות הזו חייבת להיות פעילות שבה המשתמש יכול להעניק או לדחות לאפליקציה גישה להגדרות של מדיניות ההתראות.

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

• [C-7-1] חובה לספק מנגנון שגלוי למשתמשים כדי להוסיף ולהגדיר שיטות קלט של צד שלישי בתגובה לכוונה android.settings.INPUT_METHOD_SETTINGS.

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

• [C-8-1] חובה לפעול בהתאם לכוונה של android.settings.ACCESSIBILITY_SETTINGS לספק מנגנון שזמין למשתמשים כדי להפעיל ולהשבית את שירותי הנגישות של הצד השלישי לצד שירותי הנגישות שהועלו מראש.

אם הטמעות במכשירים כוללות תמיכה ב-Wi-Fi Easy Connect ומאפשרות גישה לפונקציונליות באפליקציות של צד שלישי, הן:

• [C-9-1] חובה להטמיע את ממשקי ה-API של ה-Intent‏ Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI כפי שמתואר במסמכי התיעוד של ה-SDK.

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

• [C-10-1] חובה לספק ממשק משתמש בהגדרות, שמטפל בכוונה Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS ומאפשר למשתמשים להוסיף אפליקציות לרשימת ההיתרים או להסיר אותן ממנה.

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

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

אם הטמעות של מכשירים מכריזות על תמיכה במצלמה באמצעות android.hardware.camera.any, הן:

• [C-12-3] חובה לטפל בכוונות הבאות MediaStore.ACTION_IMAGE_CAPTURE,‏ MediaStore.ACTION_IMAGE_CAPTURE_SECURE ו-MediaStore.ACTION_VIDEO_CAPTURE באפליקציות Android מותקנות מראש, ורק להן לאפשר לטפל בהן, כפי שמתואר במסמך ה-SDK.

אם הטמעות של מכשירים מדווחות על android.software.device_admin, הן:

• [C-13-1] חובה לפעול בהתאם לכוונה android.app.action.ADD_DEVICE_ADMIN להפעיל ממשק משתמש כדי להנחות את המשתמש להוסיף את האדמין של המכשיר למערכת (או לאפשר לו לדחות אותו).

• [C-13-2] חובה לפעול בהתאם ל-intents‏ android.app.action.PROVISION_MANAGED_PROFILE,‏ android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD,‏ android.app.action.SET_NEW_PASSWORD ו-android.app.action.START_ENCRYPTION, ולכלול פעילות שמספקת את הטיפול ב-intents האלה כפי שמתואר ב-SDK כאן.

אם הטמעות במכשירים מכריזות על דגל התכונה android.software.autofill, הן:

• [C-14-1] חובה להטמיע באופן מלא את ממשקי ה-API של AutofillService ושל AutofillManager, ולפעול בהתאם לכוונה של android.settings.REQUEST_SET_AUTOFILL_SERVICE להציג תפריט הגדרות ברירת מחדל של האפליקציה כדי להפעיל ולהשבית את המילוי האוטומטי ולשנות את שירות המילוי האוטומטי שמוגדר כברירת מחדל עבור המשתמש.

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

• [C-SR-2] מומלץ מאוד לספק מנגנון שגלוי למשתמשים כדי להעניק או לבטל גישה לנתוני השימוש בתגובה ל-intent‏ android.settings.ACTION_USAGE_ACCESS_SETTINGS לאפליקציות שמצהירות על ההרשאה android.permission.PACKAGE_USAGE_STATS.

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

• [C-15-1] עדיין חייבת להיות פעילות שמטפלת בדפוס ה-intent‏ android.settings.ACTION_USAGE_ACCESS_SETTINGS, אבל חובה להטמיע אותו כפעולה ללא תוצאה (no-op), כלומר עם התנהגות זהה לזו שמתרחשת כשהמשתמש נדחה לקבלת גישה.

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

• [C-16-1] חובה להציג קישורים כאלה לכל שירותי המילוי האוטומטי המותקנים.

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

• [C-18-1] חובה לפעול בהתאם לכוונה של android.settings.ACTION_VOICE_INPUT_SETTINGS להציג תפריט הגדרות ברירת מחדל של אפליקציה לקלט קולי ולעזרה.

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

• [C-SR-3] מומלץ מאוד להוסיף פעילות כדי לספק השלמה ל-intents‏ android.intent.action.TTS_SERVICE,‏ android.speech.tts.engine.INSTALL_TTS_DATA ו-android.speech.tts.engine.GET_SAMPLE_TEXT, כפי שמתואר ב-SDK כאן.

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

• צריך לכלול תמיכה בשומרי מסך ולספק אפשרות להגדרות שמאפשרת למשתמשים להגדיר שומרי מסך בתגובה לכוונה android.settings.DREAM_SETTINGS.

יצירת דרישות חדשות

אם הטמעות במכשירים מדווחות על android.hardware.nfc.uicc או על android.hardware.nfc.ese, הן:

• [C-19-1] חובה להטמיע את ה-Intent API‏ NfcAdapter.ACTION_TRANSACTION_DETECTED (כמו 'EVT_TRANSACTION' שמוגדר במפרט הטכני TS.26 של GSM Association – דרישות למכשירי NFC).

סיום הדרישות החדשות

3.2.4. פעילויות במסך משני או במספר מסכים

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

• [C-1-1] חובה להגדיר את הדגל android.software.activities_on_secondary_displays.
• [C-1-2] חובה להבטיח תאימות ל-API דומה לפעילות שפועלת במסך הראשי.
• [C-1-3] חובה להציג את הפעילות החדשה באותו מסך שבו הוצגה הפעילות שהפעילה אותה, כשהפעילות החדשה מופעלת בלי לציין מסך יעד באמצעות ה-API של ActivityOptions.setLaunchDisplayId().
• [C-1-4] חובה להשמיד את כל הפעילויות כשמסירים תצוגה עם הדגל Display.FLAG_PRIVATE.
• [C-1-5] חובה להסתיר את התוכן באופן מאובטח בכל המסכים כשהמכשיר נעול באמצעות מסך נעילה מאובטח, אלא אם האפליקציה בוחרת להופיע מעל מסך הנעילה באמצעות ה-API של Activity#setShowWhenLocked().
• צריך להגדיר את הערך android.content.res.Configuration שמתאים לתצוגה הזו כדי שהיא תוצג, תפעל בצורה תקינה ותשמור על תאימות אם פעילות מסוימת תושק בתצוגה המשנית.

אם הטמעות במכשירים מאפשרות להפעיל פעילויות Android רגילות במסכים משניים, ובמסך משני מוגדר הדגל android.view.Display.FLAG_PRIVATE:

• [C-3-1] רק הבעלים של המסך, המערכת והפעילויות שכבר מוצגות במסך הזה חייבים להיות מסוגלים להפעיל אותו. כל אחד יכול להפעיל את האפליקציה במסך עם הדגל android.view.Display.FLAG_PUBLIC.

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

תאימות לקוד מקורי היא אתגר. לכן, למטמיעים של המכשירים יש:

• [C-SR-1] מומלץ מאוד להשתמש בהטמעות של הספריות שמפורטות בהמשך מפרויקט Android Open Source Project.

3.3.1. ממשקי Application Binary Interface

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

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

• [C-0-1] חייב להיות תואם ל-Android NDK ABI אחד או יותר.
• [C-0-2] חובה לכלול תמיכה בקוד שפועל בסביבה המנוהלת כדי לבצע קריאה לקוד מקומי, באמצעות סמנטיקה רגילה של Java Native Interface‏ (JNI).
• [C-0-3] חייב להיות תואם למקור (כלומר תואם לכותרת) ולקובץ הבינארי (עבור ה-ABI) של כל ספרייה נדרשת ברשימה שבהמשך.
• [C-0-5] חובה לדווח במדויק על ממשק ה-ABI (Application Binary Interface) המקורי שנתמך במכשיר, באמצעות הפרמטרים android.os.Build.SUPPORTED_ABIS,‏ android.os.Build.SUPPORTED_32_BIT_ABIS ו-android.os.Build.SUPPORTED_64_BIT_ABIS. כל אחד מהפרמטרים הוא רשימה של ממשקי ABI מופרדים בפסיקים, שממוינים מהמועדף ביותר לפחות מועדף.

• [C-0-6] חובה לדווח, באמצעות הפרמטרים שלמעלה, על קבוצת משנה של רשימת ה-ABI הבאה, אסור לדווח על ABI שלא מופיע ברשימה.

  • armeabi (ה-NDK כבר לא תומך ב-target הזה)
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

• [C-0-7] חובה להפוך את כל הספריות הבאות, שמספקות ממשקי API מקומיים, לזמינות לאפליקציות שכוללות קוד מקומי:

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

• [C-0-8] אסור להוסיף או להסיר את הפונקציות הציבוריות של הספריות הילידיות שמפורטות למעלה.

• [C-0-9] חובה לציין ב-/vendor/etc/public.libraries.txt ספריות נוספות שאינן AOSP שחשופות ישירות לאפליקציות של צד שלישי.

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

• [C-0-11] חובה לייצא את כל סמלי הפונקציות של OpenGL ES 3.1 ו-Android Extension Pack, כפי שמוגדרים ב-NDK, דרך הספרייה libGLESv3.so. שימו לב: חובה לכלול את כל הסמלים, אבל בקטע 7.1.4.1 מתוארים בפירוט רב יותר הדרישות לגבי המועד שבו צפויה ההטמעה המלאה של כל אחת מהפונקציות התואמות.

• [C-0-12] חובה לייצא סמלי פונקציות של הליבה של סמלי הפונקציות של Vulkan 1.0 ו-Vulkan 1.1, וגם של התוספים VK_KHR_surface,‏ VK_KHR_android_surface,‏ VK_KHR_swapchain,‏ VK_KHR_maintenance1 ו-VK_KHR_get_physical_device_properties2 דרך הספרייה libvulkan.so. חשוב לזכור שכל הסמלים חייבים להופיע, אבל בקטע 7.1.4.2 מתוארות בפירוט רב יותר הדרישות לגבי המועד שבו צפויה ההטמעה המלאה של כל אחת מהפונקציות התואמות.

• צריך לבנות אותו באמצעות קוד המקור וקובצי הכותרת שזמינים ב-Android Open Source Project.

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

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

אם הטמעות במכשירים מדווחות על תמיכה ב-ABI של armeabi, הן:

• [C-3-1] חייב גם לתמוך ב-armeabi-v7a ולדווח על התמיכה, כי armeabi מיועד רק לתאימות לאחור עם אפליקציות ישנות יותר.

אם הטמעות במכשירים מדווחות על תמיכה ב-ABI‏ armeabi-v7a, באפליקציות שמשתמשות ב-ABI הזה:

• [C-2-1] חובה לכלול את השורות הבאות ב-/proc/cpuinfo, ואסור לשנות את הערכים באותו מכשיר, גם אם הם נקראו על ידי ABI אחרים.

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

• [C-2-2] תמיד צריך לוודא שהפעולות הבאות זמינות, גם במקרה שה-ABI מוטמע בארכיטקטורה של ARMv8, באמצעות תמיכה במעבד מקורי או באמצעות הדמיה של תוכנה:

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

• [C-2-3] חובה לכלול תמיכה בתוסף Advanced SIMD (נקרא גם NEON).

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

3.4.1. תאימות ל-WebView

אם ההטמעות במכשירים מספקות הטמעה מלאה של API ‏android.webkit.Webview, הן:

• [C-1-1] חובה לדווח על android.software.webview.
• [C-1-2] חובה להשתמש בגרסה המאוחדת של פרויקט Chromium מהפרויקט של Android בקוד פתוח (upstream) בהסתעפות Android 14, כדי להטמיע את ה-API של android.webkit.WebView.

• [C-1-3] מחרוזת סוכן המשתמש שמדווחת על ידי WebView חייבת להיות בפורמט הזה:

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

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

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

• [C-1-4] חובה להציג את התוכן שסופק או את התוכן של כתובת ה-URL המרוחקת בתהליך שונה מהאפליקציה שיוצרת את מופע ה-WebView. באופן ספציפי, לתהליך המפרסם הנפרד חייבות להיות הרשאות נמוכות יותר, הוא צריך לפעול בתור מזהה משתמש נפרד, אין לו גישה לספריית הנתונים של האפליקציה, אין לו גישה ישירה לרשת ויש לו גישה רק לשירותי המערכת הנדרשים למינימום דרך Binder. ההטמעה של WebView ב-AOSP עומדת בדרישות האלה.

הערה: אם הטמעות המכשיר הן של 32 ביט או שהן מכריזות על דגל התכונה android.hardware.ram.low, הן פטורות מ-C-1-3.

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

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

• [C-1-1] חובה לתמוך בכל אחד מממשקי ה-API האלה שמשויכים ל-HTML5:
  • מטמון האפליקציה/פעולה אופליין
  • תג<video>
  • geolocation
• [C-1-2] חובה לתמוך ב-webstorage API של HTML5/W3C, ומומלץ לתמוך ב-IndexedDB API של HTML5/W3C. חשוב לזכור שגופי התקנים לפיתוח אינטרנט עוברים להעדיף את IndexedDB על פני webstorage, ולכן IndexedDB צפוי להפוך לרכיב נדרש בגרסה עתידית של Android.
• מותר לשלוח מחרוזת של סוכן משתמש בהתאמה אישית באפליקציית הדפדפן העצמאית.
• צריך להטמיע תמיכה בחלקים רבים ככל האפשר של HTML5 באפליקציית הדפדפן העצמאית (בין אם היא מבוססת על אפליקציית הדפדפן WebKit במקור ובין אם היא החלפה של צד שלישי).

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

• [C-2-1] חובה להמשיך לתמוך בדפוסי הכוונה הציבוריים כפי שמתואר בקטע 3.2.3.1.

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

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

• [C-0-9] חובה לוודא שתוחל תאימות התנהגות של API בכל האפליקציות המותקנות, אלא אם הן מוגבלות כפי שמתואר בקטע 3.5.1.
• [C-0-10] אסור להטמיע את הגישה של רשימת ההיתרים שמבטיחה תאימות התנהגות של API רק לאפליקציות שנבחרו על ידי מפתחי המכשירים.

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

• [C-0-1] אסור למכשירים לשנות את ההתנהגות או את הסמנטיקה של כוונה רגילה.
• [C-0-2] אסור לשנות במכשירים את מחזור החיים או את סמנטיקה של מחזור החיים של סוג מסוים של רכיב מערכת (כמו Service,‏ Activity,‏ ContentProvider וכו').
• [C-0-3] אסור למכשירים לשנות את הסמנטיקה של הרשאה רגילה.
• אסור למכשירים לשנות את המגבלות שחלות על אפליקציות שפועלות ברקע. באופן ספציפי יותר, לגבי אפליקציות ברקע:
  • [C-0-4] חובה להפסיק את ביצוע הפונקציות החוזרות (callbacks) שנרשמו על ידי האפליקציה כדי לקבל את הפלט מ-GnssMeasurement ו-GnssNavigationMessage.
  • [C-0-5] חובה להגביל את התדירות של העדכונים שסופקו לאפליקציה באמצעות סיווג ה-API LocationManager או השיטה WifiManager.startScan().
  • [C-0-6] אם האפליקציה מטרגטת רמת API ‏25 ואילך, אסור לאפשר לה לרשום מקבלי שידור (broadcast receivers) לשידורים המשתמעים של כוונות סטנדרטיות ל-Android במניפסט של האפליקציה, אלא אם הכוונה לשידור דורשת הרשאה "signature" או "signatureOrSystem" protectionLevel או שהיא נכללת ברשימת ההחרגות.
  • [C-0-7] אם האפליקציה מטרגטת רמת API ‏25 ואילך, היא חייבת להפסיק את שירותי הרקע של האפליקציה, בדיוק כמו שהאפליקציה הייתה מפעילה את ה-method‏ stopSelf() של השירותים, אלא אם האפליקציה מופיעה ברשימת ההיתרים הזמנית כדי לטפל במשימה שגלויה למשתמש.
  • [C-0-8] אם האפליקציה מטרגטת לרמת API 25 ואילך, חובה לשחרר את ה-wakelocks שהאפליקציה מחזיקה.
• [C-0-11] מכשירים חייבים להחזיר את ספקי האבטחה הבאים בתור שבעת ערכי המערך הראשונים מהשיטה Security.getProviders(), בסדר הנתון ובשמות ובכיתות הנתונים (כפי שהם מוחזרים על ידי Provider.getName()), אלא אם האפליקציה שינתה את הרשימה באמצעות insertProviderAt() או removeProvider(). יכול להיות שמכשירים יחזירו ספקים נוספים אחרי רשימת הספקים שמפורטת בהמשך.
  1. AndroidNSSP – android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL – com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider – sun.security.provider.CertPathProvider
  4. AndroidKeyStoreBCWorkaround – android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC – com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE – com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore – android.security.keystore.AndroidKeyStoreProvider

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

3.5.1. הגבלת אפליקציות

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

• [C-1-1] חובה לאפשר למשתמש לראות את רשימת האפליקציות המוגבלות.
• [C-1-2] חובה לספק למשתמשים אפשרות להפעיל או להשבית את כל המגבלות הקנייניות האלה בכל אפליקציה.

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

• [C-1-4] אסור להחיל באופן אוטומטי את ההגבלות הקנייניות האלה על אפליקציות כשמשתמש משבית את ההגבלות על האפליקציות באופן ידני, ומותר להציע למשתמש להחיל את ההגבלות הקנייניות האלה.

• [C-1-5] חובה להודיע למשתמשים אם ההגבלות הקנייניות האלה חלות על אפליקציה באופן אוטומטי. חובה לספק את המידע הזה במהלך 24 השעות שלפני החלת ההגבלות הקנייניות האלה.

• [C-1-6] חובה להחזיר את הערך true ל-method‏ ActivityManager.isBackgroundRestricted()‎ לכל קריאות ה-API מאפליקציה.

• [C-1-7] אסור להגביל את האפליקציה העיקרית בחזית שבה המשתמש משתמש באופן מפורש.

• [C-1-8] חובה להשעות את ההגבלות הקנייניות האלה על אפליקציה בכל פעם שמשתמש מתחיל להשתמש באפליקציה באופן מפורש, כך שהיא תהפוך לאפליקציה העליונה בחזית.

• [C-1-10] חובה לספק מסמך או אתר ציבוריים וברורים שמתארים את אופן החלת ההגבלות הקנייניות. המסמך או אתר האינטרנט חייבים להיות ניתנים לקישור מהמסמכים של Android SDK, וחייבים לכלול את הפרטים הבאים:

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

אם אפליקציה מותקנת מראש במכשיר ומשתמש אף פעם לא השתמש בה באופן מפורש במשך יותר מ-30 יום, [C-1-3] [C-1-5] פטורים.

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

• [C-2-1]חובה לפעול לפי ההטמעה שמתוארת במסמך הזה.

3.5.2. מצב תנומה של אפליקציות

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

• [C-1-1] חייב לעמוד בכל הדרישות שמפורטות בקטע 3.5.1, מלבד [C-1-6] ו-[C-1-3].
• [C-1-2] חובה להחיל את ההגבלה על האפליקציה למשתמש רק אם יש ראיות לכך שהמשתמש לא השתמש באפליקציה במשך תקופה מסוימת. מומלץ מאוד שהמשך הזמן יהיה חודש אחד או יותר. השימוש חייב להיות מוגדר על ידי אינטראקציה מפורשת של משתמש דרך ה-API UsageStats#getLastTimeVisible() או על ידי כל דבר שגורם לאפליקציה לצאת ממצב העצירה הכפויה, כולל קישורי שירות, קישורי ספקי תוכן, שידורים מפורשים וכו'. המעקב אחר האירועים האלה יתבצע באמצעות ה-API החדש UsageStats#getLastTimeAnyComponentUsed().
• [C-1-3] חובה להחיל הגבלות שמשפיעות על כל המשתמשים במכשיר רק אם יש הוכחה שאף משתמש לא השתמש בחבילה במשך תקופה מסוימת. מומלץ מאוד שהמשך הזמן יהיה חודש אחד או יותר.
• [C-1-4] אסור שהאפליקציה לא תוכל להגיב לכוונות של פעילויות, לקישור שירותים, לבקשות של ספקי תוכן או לשידורים מפורשים.

התכונה 'השבתה של אפליקציות' ב-AOSP עומדת בדרישות שלמעלה.

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

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

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

כלומר:

• [C-0-1] אסור לשנות את ממשקי ה-API שגלויים לכולם בפלטפורמת Android על ידי שינוי חתימות של שיטות או כיתות, או על ידי הסרת כיתות או שדות של כיתות.
• [C-0-2] אסור להוסיף לממשקי ה-API במרחבי השמות שלמעלה רכיבים שגלויים לכולם (כמו שיעורים או ממשקים, או שדות או שיטות לשיעורים או לממשקים קיימים) או ממשקי API לבדיקה או למערכת. 'רכיב שחשוף לכולם' הוא כל מבנה שלא מעוטר בסמן '‎@hide' כפי שמשתמשים בו בקוד המקור של Android במקור.

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

• [C-0-3] אסור להשפיע על ההתנהגות המוצהרת ועל החתימה בשפת Java של כל ממשק API שחשוף לכולם.
• [C-0-4] אסור לפרסם או לחשוף למפתחים בדרך אחרת.

עם זאת, למטמיעים של מכשירים מותר להוסיף ממשקי API מותאמים אישית מחוץ למרחב השמות הסטנדרטי של Android, אבל ממשקי ה-API המותאמים אישית:

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

למטמיעים של מכשירים מותר להוסיף ממשקי API מותאמים אישית בשפות מקומיות, מחוץ לממשקי ה-API של NDK, אבל ממשקי ה-API המותאמים אישית:

• [C-1-1] אסור שהקוד יהיה בספריית NDK או בספרייה שבבעלות ארגון אחר, כפי שמתואר כאן.

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

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

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

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

• [C-0-1] חובה לתמוך בפורמט המלא של קובץ Dalvik הפעלה (DEX) ובסמנטיקה ומפרט של קוד בינארי של Dalvik.

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

• צריך להשתמש ב-Android RunTime‏ (ART), בהטמעה של פורמט Dalvik Executable Format ב-upstream ובמערכת ניהול החבילות של ההטמעה.

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

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

פריסת המסך	דחיסות מסך	נפח זיכרון מינימלי לאפליקציה
Android Watch	120 dpi (ldpi)	32MB
	140 dpi (140dpi)
	160dpi‏ (mdpi)
	180 dpi (180dpi)
	200 dpi (200dpi)
	213dpi‏ (tvdpi)
	220 dpi (220dpi)	36MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi‏ (xhdpi)	48MB
	360 dpi (360dpi)
	400 dpi (400dpi)	56MB
	420 dpi (420dpi)	64MB
	480dpi‏ (xxhdpi)	88MB
	560 dpi (560dpi)	112MB
	640dpi‏ (xxxhdpi)	154MB
קטן/רגיל	120 dpi (ldpi)	32MB
	140 dpi (140dpi)
	160dpi‏ (mdpi)
	180 dpi (180dpi)	48MB
	200 dpi (200dpi)
	213dpi‏ (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi‏ (xhdpi)	80MB
	360 dpi (360dpi)
	400 dpi (400dpi)	96MB
	420 dpi (420dpi)	112MB
	480dpi‏ (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640dpi‏ (xxxhdpi)	256MB
גדולה	120 dpi (ldpi)	32MB
	140 dpi (140dpi)	48MB
	160dpi‏ (mdpi)
	180 dpi (180dpi)	80MB
	200 dpi (200dpi)
	213dpi‏ (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)	96MB
	320 dpi‏ (xhdpi)	128MB
	360 dpi (360dpi)	160MB
	400 dpi (400dpi)	192MB
	420 dpi (420dpi)	228MB
	480dpi‏ (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640dpi‏ (xxxhdpi)	512MB
xlarge	120 dpi (ldpi)	48MB
	140 dpi (140dpi)	80MB
	160dpi‏ (mdpi)
	180 dpi (180dpi)	96MB
	200 dpi (200dpi)
	213dpi‏ (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)	144MB
	320 dpi‏ (xhdpi)	192MB
	360 dpi (360dpi)	240MB
	400 dpi (400dpi)	288MB
	420 dpi (420dpi)	336MB
	480dpi‏ (xxhdpi)	384MB
	560 dpi (560dpi)	576MB
	640dpi‏ (xxxhdpi)	768MB

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

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

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

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

• [C-1-1] חובה להצהיר על תכונת הפלטפורמה android.software.home_screen.
• [C-1-2] חובה להחזיר את האובייקט AdaptiveIconDrawable כשאפליקציית הצד השלישי משתמשת בתג <adaptive-icon> כדי לספק את הסמל שלה, והשיטות PackageManager נקראות כדי לאחזר סמלים.

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

• [C-2-1] חובה לדווח על true עבור ShortcutManager.isRequestPinShortcutSupported().
• [C-2-2] חובה להציג למשתמש בקשה לפני שמוסיפים קיצור דרך שנבקש על ידי אפליקציות באמצעות שיטת ה-API‏ ShortcutManager.requestPinShortcut().
• [C-2-3] חובה לתמוך בקיצורי דרך מוצמדים ובקיצורי דרך דינמיים וסטטיים, כפי שמתואר בדף קיצורי הדרך לאפליקציות.

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

• [C-3-1] חובה לדווח על false עבור ShortcutManager.isRequestPinShortcutSupported().

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

• [C-4-1] חובה לתמוך בכל תכונות קיצור הדרך המתועדות (למשל, קיצורי דרך סטטיים ודינמיים, קיצורי דרך מוצמדים) ולהטמיע באופן מלא את ממשקי ה-API של סוג ה-API ShortcutManager.

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

• [C-5-1] חובה לפעול בהתאם לשיטת ה-API NotificationChannel.setShowBadge(). במילים אחרות, אם הערך מוגדר כ-true, מוצגת סמנטיקה חזותית שמשויכת לסמל האפליקציה. אם הערך מוגדר כ-false בכל ערוצי ההתראות של האפליקציה, לא מוצגת סמנטיקה חזותית של תגים בסמל האפליקציה.
• יכולים לשנות את התגים של סמל האפליקציה לתוכנית התגים הקניינית שלהם, אם אפליקציות של צד שלישי מציינות תמיכה בתוכנית התגים הקניינית באמצעות שימוש בממשקי API קנייניים, אבל צריכים להשתמש במשאבים ובערכים שסופקו באמצעות ממשקי ה-API של תגי ההתראות שמתוארים בSDK, כמו ה-API של Notification.Builder.setNumber() ושל Notification.Builder.setBadgeIconType().

אם הטמעות במכשירים תומכות בסמלים מונוכרומטיים, הסמלים האלה:

• [C-6-1] חובה להשתמש בהם רק כשהמשתמש מפעיל אותם במפורש (למשל דרך ההגדרות או תפריט הבחירה של הטפט).

3.8.2. ווידג'טים

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

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

• [C-1-1] חובה להצהיר על תמיכה בתכונה android.software.app_widgets של הפלטפורמה.

• [C-1-2] חובה לכלול תמיכה מובנית ב-AppWidgets ולהציג אפשרויות בממשק המשתמש להוספה, להגדרה, להצגה ולהסרה של AppWidgets

• [C-1-3] חובה שאפשר יהיה להציג ב-widget בגודל רשת סטנדרטי 4 x 4. פרטים נוספים זמינים בהנחיות לעיצוב של ווידג'טים של אפליקציות במסמכי התיעוד של Android SDK.

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

אם הטמעות במכשירים תומכות בווידג'טים של אפליקציות צד שלישי ובהצמדה של קיצורי דרך באפליקציות, הן:

• [C-2-1] חובה לדווח על true עבור AppWidgetManager.html.isRequestPinAppWidgetSupported().
• [C-2-2] חובה להציג למשתמש בקשה לפני שמוסיפים קיצור דרך שנבקש על ידי אפליקציות באמצעות שיטת ה-API‏ AppWidgetManager.requestPinAppWidget().

3.8.3. התראות

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

3.8.3.1. הצגת ההתראות

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

• [C-1-1] חובה לתמוך בהתראות שמשתמשות בתכונות חומרה, כפי שמתואר במסמכי התיעוד של ה-SDK, ובמידת האפשר עם חומרת ההטמעה של המכשיר. לדוגמה, אם הטמעת המכשיר כוללת ויברטור, חובה להטמיע בצורה נכונה את ממשקי ה-API של הרטט. אם הטמעה של מכשיר חסרה חומרה, צריך להטמיע את ממשקי ה-API התואמים כ-no-ops. התנהגות זו מפורטת בהרחבה בקטע 7.
• [C-1-2] חובה להציג בצורה נכונה את כל המשאבים (סמלים, קובצי אנימציה וכו') שסופקו ב-API או במדריך הסגנון של הסמלים בסרגל הסטטוס או בסרגל המערכת, למרות שאפשר לספק חוויית משתמש חלופית להתראות מזו שסופקה בהטמעת העזר של Android Open Source.
• [C-1-3] חובה לפעול בהתאם להתנהגויות המתוארות בממשקי ה-API ולהטמיע אותן בצורה תקינה כדי לעדכן, להסיר ולקבץ התראות.
• [C-1-4] חובה לספק את כל ההתנהגות של ה-API NotificationChannel שמתועדת ב-SDK.
• [C-1-5] חובה לספק למשתמש אפשרות לחסום ולשנות התראה מסוימת של אפליקציה של צד שלישי לכל ערוץ וחבילת אפליקציות.
• [C-1-6] חובה גם לספק למשתמש אפשרות להציג ערוצי התראות שנמחקו.

• [C-1-7] חובה להציג בצורה נכונה את כל המשאבים (תמונות, סטיקרים, סמלים וכו') שסופקו באמצעות Notification.MessagingStyle לצד טקסט ההתראה, ללא אינטראקציה נוספת של המשתמש. לדוגמה, חובה להציג את כל המשאבים, כולל הסמלים שסופקו באמצעות android.app.Person, בשיחה קבוצתית שמוגדרת באמצעות setGroupConversation.

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

• [C-SR-2] מומלץ מאוד לספק למשתמשים אפשרות לציין אפליקציות שלא יקבלו התראות ממאזין התראות ספציפי.

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

• צריכה להיות תמיכה בהתראות עשירות.

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

• צריכה להיות למשתמש אפשרות להשהות התראות.

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

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

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

• [C-SR-4] מומלץ מאוד לקבץ ולהציג את ההתראות של conversation notifications לפני התראות שלא קשורות לשיחות, למעט התראות על שירותים שפועלים בחזית והתראות של importance:high.

אם ההטמעות במכשירים תומכות ב-conversation notifications והאפליקציה מספקת את הנתונים הנדרשים ל-bubbles, הן:

• [C-SR-5] מומלץ מאוד להציג את השיחה הזו כבועה. הטמעת AOSP עומדת בדרישות האלה באמצעות ממשק המשתמש, ההגדרות והמרכז להפעלת אפליקציות שמוגדרים כברירת מחדל.

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

• [C-2-1] חובה להשתמש במשאבים המדויקים שסופקו באמצעות סיווג ה-API Notification.Style ותת-הסיווגים שלו עבור רכיבי המשאבים המוצגים.
• צריך להציג כל רכיב משאב (למשל, סמל, כותרת וטקסט סיכום) שמוגדר בכיתה של ה-API Notification.Style ובכיתות המשנה שלה.

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

• [C-3-1] חובה להשתמש בתצוגה ובמשאבים של התראות מראש כפי שמתואר בכיתה של ה-API Notification.Builder כשמוצגות התראות מראש.
• [C-3-2] חובה להציג את הפעולות שסופקו דרך Notification.Builder.addAction() יחד עם תוכן ההתראה, ללא אינטראקציה נוספת של המשתמש, כפי שמתואר בSDK.

3.8.3.2. שירות מאזין להתראות

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

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

• [C-0-1] חייב לעדכן את ההתראות במלואן בצורה נכונה ומידית לכל שירותי המאזינים המותקנים והמופעלים על ידי משתמשים, כולל כל המטא-נתונים שמצורפים לאובייקט ההתראה.
• [C-0-2] חייבת לפעול בהתאם לקריאת ה-API של snoozeNotification(), לסגור את ההתראה ולבצע שיחה חוזרת אחרי משך ההשהיה שהוגדר בקריאת ה-API.

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

• [C-1-1] חייב לשקף בצורה נכונה את סטטוס ההתראה שהושהתה באמצעות ממשקי ה-API הרגילים, כמו NotificationListenerService.getSnoozedNotifications().
• [C-1-2] חובה להפוך את האפשרות הזו לזמינה למשתמשים כדי לדחות התראות מכל אפליקציה של צד שלישי שמותקנת, אלא אם הן מגיעות משירותים מתמידים או משירותים שפועלים בחזית.

3.8.3.3. מצב 'נא לא להפריע' / מצב עדיפות

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

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

3.8.4. ממשקי Assist API

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

אם ההטמעות במכשירים תומכות בפעולה 'עזרה', הן:

• [C-2-1] חובה לציין בבירור למשתמש הקצה מתי מתבצע שיתוף של ההקשר, באחת מהדרכים הבאות:
  • בכל פעם שאפליקציית העזרה ניגשת להקשר, מוצגת תאורה לבנה סביב שולי המסך שתואמת או עולה על משך הזמן והבהירות של ההטמעה ב-Android Open Source Project.
  • באפליקציית העזרה המותקנת מראש, לספק למשתמש אפשרות להיכנס לתפריט ההגדרות של הקלט הקולי והאפליקציה לסיוע תוך פחות משתי פעולות ניווט, ולשתף את ההקשר רק כשהמשתמש מפעיל את אפליקציית העזרה באופן מפורש באמצעות מילה מפתח או הקשה על מקש ניווט של אפליקציית העזרה.
• [C-2-2] האינטראקציה הייעודית להפעלת אפליקציית העזרה כפי שמתואר בקטע 7.2.3 חייבת להפעיל את אפליקציית העזרה שבחר המשתמש, כלומר האפליקציה שמטמיעה את VoiceInteractionService, או פעילות שמטפלת בכוונה ACTION_ASSIST.

3.8.5. התראות והודעות קצרות

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

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

• [C-1-1] חובה לספק למשתמש אפשרות לחסום אפליקציה כך שלא תציג חלונות התראה שמשתמשים ב-TYPE_APPLICATION_OVERLAY. ההטמעה של AOSP עומדת בדרישות האלה באמצעות אמצעי בקרה בסרגל ההתראות.

• [C-1-2] חובה לפעול בהתאם ל-Toast API ולהציג הודעות Toast מאפליקציות למשתמשים קצה באופן בולט.

3.8.6. עיצובים

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

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

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

• [C-1-1] אסור לשנות אף אחד ממאפייני העיצוב של Holo שנחשפים לאפליקציות.
• [C-1-2] חובה לתמוך במשפחת העיצובים 'Material' אסור לשנות אף אחד ממאפייני העיצוב של Material או את הנכסים שלהם שגלויים לאפליקציות.

• [C-1-3] חובה להגדיר את משפחת הגופנים 'sans-serif' ל-Roboto גרסה 2.x בשפות שבהן Roboto תומכת, או לספק למשתמש אפשרות לשנות את הגופן שמשמש את משפחת הגופנים 'sans-serif' ל-Roboto גרסה 2.x בשפות שבהן Roboto תומכת.

• [C-1-4] חובה ליצור לוחות צבעים דינמיים של גוונים, כפי שמפורט במסמכי העזרה של AOSP בנושא Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (ראו android.theme.customization.system_palette ו-android.theme.customization.theme_style).

• [C-1-5] חובה ליצור צבעים דינמיים של צבעים כהים באמצעות סגנונות של נושאי צבעים שמפורטים במסמכי העזרה של Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (ראו android.theme.customization.theme_styles), כלומר TONAL_SPOT, ‏ VIBRANT, ‏ EXPRESSIVE, ‏ SPRITZ, ‏ RAINBOW,‏ FRUIT_SALAD, ‏ ו-MONOCHROMATIC.

  'צבע המקור' משמש ליצירת לוחות צבעים דינמיים בגוונים כששולחים את הערך android.theme.customization.system_palette (כפי שמתואר בקטע Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).

• [C-1-6] חייב להיות ערך chroma של CAM16 שווה ל-5 או גדול ממנו.

  • צריך להפיק אותו מהטפט באמצעות com.android.systemui.monet.ColorScheme#getSeedColors, שמספק כמה צבעים תקינים של מקור לבחירה.

  • צריך להשתמש בערך 0xFF1B6EF3 אם אף אחד מהצבעים שצוינו לא עומד בדרישות של צבע המקור שמפורטות למעלה.

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

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

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

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

• [C-2-1] חובה להשתמש בצבע לבן בסמלי סטטוס המערכת (כמו עוצמת האות ורמת הסוללה) ובהתראות שהמערכת מנפיקה, אלא אם הסמל מציין סטטוס בעייתי או שאפליקציה מבקשת סטטוס קל באמצעות הדגל WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.
• [C-2-2] כשאפליקציה מבקשת סרגל סטטוס בהיר, יש לשנות את הצבע של סמלי הסטטוס של המערכת לשחור (פרטים נוספים זמינים במאמר R.style) בהטמעות של מכשירי Android.

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

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

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

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

אם הטמעות במכשירים מטמיעות טפטים מונפשים, הן:

• [C-1-1] חובה לדווח על דגל התכונה של הפלטפורמה android.software.live_wallpaper.

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

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

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

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

• [C-1-1] חובה לתמוך בעד 7 פעילויות מוצגות.
• צריך להציג לפחות את השם של 4 פעילויות בכל פעם.

• [C-1-2] חובה להטמיע את ההתנהגות של הצמדת המסך ולספק למשתמש תפריט הגדרות כדי להפעיל או להשבית את התכונה.

• צריך להציג את צבע ההדגשה, הסמל וכותרת המסך ב'מהזמן האחרון'.
• צריך להציג אמצעי סגירה ('x'), אבל אפשר לעכב את הצגת האפשרות הזו עד שהמשתמש יבצע פעולה במסכים.
• צריך להטמיע קיצור דרך כדי לעבור בקלות לפעילות הקודמת.
• אמורה להפעיל את פעולת המעבר המהיר בין שתי האפליקציות האחרונות שהיו בשימוש, כשמקישים פעמיים על מקש הפונקציה של האפליקציות האחרונות.
• לחיצה ארוכה על מקש הפונקציות של האפליקציות האחרונות אמורה להפעיל את מצב החלוקה למספר חלונות, אם הוא נתמך.
• יכול להיות שתמונות וסרטונים שקשורים לתמונות וסרטונים אחרונים יוצגו כקבוצה שזזה יחד.
• [C-SR-1] מומלץ מאוד להשתמש בממשק המשתמש של Android במקור (או בממשק דומה שמבוסס על תמונות ממוזערות) במסך הסקירה הכללית.

3.8.9. ניהול קלט

ב-Android יש תמיכה בניהול קלט ובתמיכה בעורכי שיטות קלט של צד שלישי.

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

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

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

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

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

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

3.8.12. מיקום

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

• [C-1-2] חובה להציג את הסטטוס הנוכחי של המיקום בתפריט המיקום שב'הגדרות'.
• [C-1-3] אסור להציג מצבי מיקום בתפריט המיקום שב'הגדרות'.

3.8.13. Unicode וגופן

מערכת Android כוללת תמיכה בתווי האמוג'י שמוגדרים ב-Unicode 10.0.

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

• [C-1-1] חייב להיות מסוגל להציג את תווי האמוג'י האלה כגליף צבעוני.
• [C-1-2] חובה לכלול תמיכה ב:
  • גופן Roboto 2 בעוביים שונים – sans-serif-thin, ‏ sans-serif-light,‏ sans-serif-medium, ‏ sans-serif-black, ‏ sans-serif-condensed,‏ sans-serif-condensed-light – בשפות הזמינות במכשיר.
  • כיסוי מלא של Unicode 7.0 של לטינית, יוונית וקירילית, כולל הטווחים A,‏ B,‏ C ו-D של לטינית מורחבת, וכל הגליפים בבלוק של סמלי המטבעות ב-Unicode 7.0.
• [C-1-3] אסור להסיר או לשנות את קובץ NotoColorEmoji.tff בתמונת המערכת. (אפשר להוסיף גופן אמוג'י חדש כדי לשנות את האמוג'י בקובץ NotoColorEmoji.tff).
• צריכה לתמוך בגווני עור ובאמוג'י של משפחות מגוונות, כפי שמפורט בדוח הטכני מס' 51 של Unicode.

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

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

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

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

• [C-2-1] חובה להציג טקסט בגופן שתומך ב-Unicode כברירת מחדל. אסור להגדיר גופן שלא תומך ב-Unicode כברירת מחדל, אלא אם המשתמש בוחר בו בבורר השפות.
• [C-2-2] חובה לתמוך בגופן Unicode ובגופן שאינו תואם ל-Unicode, אם יש תמיכה בגופן שאינו תואם ל-Unicode במכשיר. אסור שגופן שלא תואם ל-Unicode יסיר או יחליף את הגופן של Unicode.
• [C-2-3] חובה להציג טקסט בגופן שלא תואם ל-Unicode רק אם צוין קוד שפה עם קוד סקריפט Qaag (למשל my-Qaag). אי אפשר להשתמש בקודים אחרים של שפות או אזורים לפי תקן ISO (מקצים, לא מקצים או שמורים) כדי להפנות לגופן לא תואם Unicode במיאנמר. מפתחי אפליקציות ומחברי דפי אינטרנט יכולים לציין את my-Qaag כקוד השפה הייעודי, כמו בכל שפה אחרת.

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

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

• [C-1-1] חובה להטמיע מצבי ריבוי חלונות כאלה בהתאם להתנהגויות האפליקציה ולממשקי ה-API שמתוארים במסמכי התיעוד של Android SDK בנושא תמיכה במצב ריבוי חלונות, ותואמים לדרישות הבאות:
• [C-1-2] חובה לכבד את android:resizeableActivity שהוגדר על ידי אפליקציה בקובץ AndroidManifest.xml, כפי שמתואר בSDK הזה.
• [C-1-3] אסור להציע מצב מסך מפוצל או מצב פורמט חופשי אם גובה המסך קטן מ-440dp ורוחבו קטן מ-440dp.
• [C-1-4] אסור לשנות את הגודל של פעילות לגודל קטן מ-220dp במצבים של חלונות מרובים, מלבד 'תמונה בתוך תמונה'.
• הטמעות של מכשירים עם גודל מסך xlarge אמורות לתמוך במצב 'טקסט חופשי'.

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

• [C-2-2] חובה לחתוך את הפעילות במצב עגינה של כמה חלונות במסך מפוצל, אבל צריך להציג חלק מהתוכן שלה, אם חלון מרכז האפליקציות הוא החלון הממוקד.
• [C-2-3] חובה לפעול בהתאם לערכי AndroidManifestLayout_minWidth ו-AndroidManifestLayout_minHeight שצוינו באפליקציית מרכז האפליקציות של הצד השלישי, ולא לשנות את הערכים האלה במהלך הצגת תוכן כלשהו של הפעילות במעגן.

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

• [C-3-1] חובה להפעיל פעילויות במצב 'תמונה בתוך תמונה' עם כמה חלונות כשהאפליקציה: * מטרגטת לרמת API 26 ומעלה ומצהירה על android:supportsPictureInPicture * מטרגטת לרמת API 25 ומטה ומצהירה גם על android:resizeableActivity וגם על android:supportsPictureInPicture.
• [C-3-2] חובה לחשוף את הפעולות ב-SystemUI שלהן, כפי שמצוין בפעילות ה-PIP הנוכחית, דרך ה-API setActions().
• [C-3-3] חובה לתמוך ביחסי גובה-רוחב שגדולים מ-1:2.39 או שווים לו, וקטנים מ-2.39:1 או שווים לו, כפי שצוין בפעילות ה-PIP דרך ה-API של setAspectRatio().
• [C-3-4] חובה להשתמש ב-KeyEvent.KEYCODE_WINDOW כדי לשלוט בחלון ה-PIP. אם מצב PIP לא מוטמע, המפתח חייב להיות זמין לפעילות שבחזית.
• [C-3-5] חובה לספק למשתמש אפשרות לחסום את הצגת האפליקציה במצב PIP. ההטמעה של AOSP עומדת בדרישות האלה באמצעות אמצעי בקרה בסרגל ההתראות.

• [C-3-6] חובה להקצות את הרוחב והגובה המינימליים הבאים לחלון ה-PIP כשאפליקציה לא מצהירה על ערך כלשהו עבור AndroidManifestLayout_minWidth ו-AndroidManifestLayout_minHeight:

  • במכשירים שבהם ההגדרה של Configuration.uiMode היא לא UI_MODE_TYPE_TELEVISION, חייבים להקצות רוחב וגובה מינימלי של 108dp.
  • במכשירים שבהם הערך של Configuration.uiMode מוגדר ל-UI_MODE_TYPE_TELEVISION, חייבים להקצות רוחב מינימלי של 240dp וגובה מינימלי של 135dp.

3.8.15. מגרעת במסך

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

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

• [C-1-5] אסור לכלול קטעי חיתוך אם יחס הגובה-רוחב של המכשיר הוא 1.0‏ (1:1).
• [C-1-2] אסור לכלול יותר מחור אחד לכל קצה.
• [C-1-3] חובה לפעול בהתאם לסימונים של חתך המסך שהוגדרו על ידי האפליקציה דרך ה-API של WindowManager.LayoutParams, כפי שמתואר ב-SDK.
• [C-1-4] חובה לדווח על ערכים נכונים לכל מדדי החיתוך שמוגדרים ב-API של DisplayCutout.

3.8.16. ממשק השליטה במכשירים

מערכת Android כוללת ממשקי API של ControlsProviderService ושל Control, שמאפשרים לאפליקציות צד שלישי לפרסם אמצעי בקרה על המכשיר כדי שהמשתמשים יוכלו לבדוק במהירות את הסטטוס ולבצע פעולות.

הדרישות הספציפיות למכשיר מפורטות בקטע 2_2_3.

3.8.17. לוח

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

• [C-0-1] אסור לשלוח נתוני הלוח לכלים, לפעילויות, לשירותים או לחיבורי רשת, ללא פעולה מפורשת של המשתמש (למשל, לחיצה על לחצן בשכבת-העל) או אינדיקציה לכך שהתוכן נשלח, מלבד לשירותים שמפורטים בקטע 9.8.6 תיעוד תוכן וחיפוש אפליקציות.

אם הטמעות במכשירים יוצרות תצוגה מקדימה שגלויה למשתמש כשתוכן מועתק ללוח העריכה לכל פריט ClipData שבו ClipData.getDescription().getExtras() מכיל android.content.extra.IS_SENSITIVE, הן:

• [C-1-1] חובה לצנזר את התצוגה המקדימה שגלויה למשתמשים

ההטמעה של AOSP עומדת בדרישות האלה לגבי הלוח.

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

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

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

• [C-1-1] חובה להצהיר על android.software.device_admin.
• [C-1-2] חובה לתמוך בהקצאה של הבעלים של המכשיר כפי שמתואר בסעיף 3.9.1 ובסעיף 3.9.1.1.

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

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

אם הטמעות של מכשירים מגדירות את android.software.device_admin, הן:

• [C-1-1] חובה לתמוך ברישום של לקוח מדיניות המכשיר (DPC) בתור אפליקציית הבעלים של המכשיר, כפי שמתואר בהמשך:
  • כשמשתמשים ונתוני משתמשים לא מוגדרים בהטמעה במכשיר, היא:
    • [C-1-5] חובה לרשום את אפליקציית ה-DPC כאפליקציית 'בעלי המכשיר' או לאפשר לאפליקציית ה-DPC לבחור אם להפוך ל'בעלי המכשיר' או ל'בעלי הפרופיל', אם המכשיר מצהיר על תמיכה בתקשורת מטווח קצר (NFC) באמצעות דגל התכונה android.hardware.nfc ומקבל הודעת NFC שמכילה רשומה עם סוג MIME‏ MIME_TYPE_PROVISIONING_NFC.
    • [C-1-8] חובה לשלוח את הכוונה ACTION_GET_PROVISIONING_MODE אחרי שההקצאה של הבעלים של המכשיר מופעלת, כדי שאפליקציית ה-DPC תוכל לבחור אם להפוך לבעלים של המכשיר או לבעלים של הפרופיל, בהתאם לערכים של android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, אלא אם ניתן לקבוע מההקשר שיש רק אפשרות תקפה אחת.
    • [C-1-9] חובה לשלוח את הכוונה ACTION_ADMIN_POLICY_COMPLIANCE לאפליקציית הבעלים של המכשיר אם הבעלים של המכשיר נוצר במהלך ההקצאה, ללא קשר לשיטת ההקצאה שבה נעשה שימוש. המשתמש לא יכול להמשיך באשף ההגדרה עד שהאפליקציה 'בעלי המכשיר' מסתיימת.
  • כשהטמעת המכשיר כוללת משתמשים או נתוני משתמשים, היא:
    • [C-1-7] אסור יותר לרשום אפליקציית DPC כלשהי כאפליקציית הבעלים של המכשיר.

• [C-1-2] חובה להציג הודעה מתאימה בנושא גילוי נאות (כמו ההודעה שמופיעה ב-AOSP) ולקבל הסכמה מפורשת ממשתמש הקצה לפני שמגדירים אפליקציה כבעלים של המכשיר, אלא אם המכשיר מוגדר באופן פרוגרמטי למצב הדגמה בחנות הפיזית לפני האינטראקציה של משתמש הקצה במסך. אם הטמעות במכשירים מכריזות על android.software.device_admin, אבל כוללות גם פתרון ניהול מכשירים קנייני ומספקות מנגנון לקידום אפליקציה שמוגדרת בפתרון שלהן כ'בעלים של מכשיר' שזהה ל'בעלים של מכשיר' הרגיל, כפי שהוא מוכר בממשקי ה-API הרגילים של Android‏ DevicePolicyManager, הן:

• [C-2-1] חובה להגדיר תהליך לאימות שהאפליקציה הספציפית שמקדמים שייכת לפתרון לגיטימי לניהול מכשירים ארגוניים, ושהיא מוגדרת בפתרון הקנייני כך שתהיה לה הרשאה שווה ערך ל'בעלי המכשיר'.

• [C-2-2] חובה להציג את אותו גילוי נאות בנושא הסכמה של הבעלים של המכשיר ב-AOSP, כמו בתהליך שהתחיל על ידי android.app.action.PROVISION_MANAGED_DEVICE, לפני ההרשמה של אפליקציית ה-DPC בתור 'בעלים של המכשיר'.

• [C-2-3] אסור להטמיע את ההסכמה בקוד או למנוע את השימוש באפליקציות אחרות של בעלי המכשיר.

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

אם הטמעות של מכשירים מגדירות את android.software.managed_users, הן:

• [C-1-1] חובה להטמיע את ממשקי ה-API שמאפשרים לאפליקציית אמצעי בקרה למדיניות המכשיר (DPC) להיות הבעלים של פרופיל מנוהל חדש.

• [C-1-2] תהליך הקצאת הפרופיל המנוהל (התהליך שמופעל על ידי ה-DPC באמצעות android.app.action.PROVISION_MANAGED_PROFILE או על ידי הפלטפורמה), מסך ההסכמה וחוויית המשתמש חייבים להיות תואמים ליישום AOSP.

• [C-1-3] חובה לספק את האפשרויות הבאות למשתמשים בהגדרות כדי להצביע למשתמש על כך שפונקציית מערכת מסוימת הושבתה על ידי ה-Device Policy Controller‏ (DPC):

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

• [C-1-4] חובה להפעיל את הטיפולן של ה-intent‏ ACTION_PROVISIONING_SUCCESSFUL בפרופיל העבודה אם הוגדר בעלים של פרופיל כשה-intent‏ android.app.action.PROVISION_MANAGED_PROFILE הפעיל את ההקצאה, וה-DPC הטמיע את הטיפולן.

• [C-1-5] חובה לשלוח את השידור ACTION_PROFILE_PROVISIONING_COMPLETE ל-DPC של פרופיל העבודה כשההקצאה מופעלת על ידי הכוונה android.app.action.PROVISION_MANAGED_PROFILE.

• [C-1-6] חובה לשלוח את הכוונה ACTION_GET_PROVISIONING_MODE אחרי שההקצאה של הבעלים של הפרופיל מופעלת, כדי שאפליקציית ה-DPC תוכל לבחור אם להפוך לבעלים של המכשיר או לבעלים של הפרופיל, למעט במקרים שבהם ההקצאה מופעלת על ידי הכוונה android.app.action.PROVISION_MANAGED_PROFILE.

• [C-1-7] חובה לשלוח את הכוונה ACTION_ADMIN_POLICY_COMPLIANCE לפרופיל העבודה כשבעל פרופיל מוגדר במהלך ההקצאה, ללא קשר לשיטת ההקצאה שבה נעשה שימוש, אלא אם ההקצאה מופעלת על ידי הכוונה android.app.action.PROVISION_MANAGED_PROFILE. המשתמש לא יכול להמשיך באשף ההגדרה עד שהאפליקציה של הבעלים של הפרופיל תסתיים.

• [C-1-8] חובה לשלוח את השידור ACTION_MANAGED_PROFILE_PROVISIONED ל-DPC של הפרופיל האישי כשמגדירים בעל פרופיל, ללא קשר לשיטת הקצאת המשאבים שבה נעשה שימוש.

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

אם הטמעות של מכשירים מגדירות את android.software.managed_users, הן:

• [C-1-1] חובה לתמוך בפרופילים מנוהלים באמצעות ממשקי ה-API של android.app.admin.DevicePolicyManager.
• [C-1-2] חובה לאפשר ליצור פרופיל מנוהל אחד בלבד.
• [C-1-3] חובה להשתמש בתג סמל (בדומה לתג העבודה של AOSP upstream) כדי לייצג את האפליקציות והווידג'טים המנוהלים ואת רכיבי ממשק המשתמש האחרים עם תגים, כמו 'מהזמן האחרון' ו'התראות'.
• [C-1-4] חובה להציג סמל התראה (בדומה לתג העבודה של AOSP upstream) כדי לציין מתי המשתמש נמצא באפליקציה של פרופיל מנוהל.
• [C-1-5] חובה להציג הודעה קופצת שמציינת שהמשתמש נמצא בפרופיל המנוהל אם והפעם שהמכשיר מתעורר (ACTION_USER_PRESENT) והאפליקציה שבחזית נמצאת בפרופיל המנוהל.
• [C-1-6] אם קיים פרופיל מנוהל, חובה להציג תכונה חזותית ב 'בורר' של הכוונה כדי לאפשר למשתמש להעביר את הכוונה מהפרופיל המנוהל למשתמש הראשי או להפך, אם האפשרות הזו מופעלת על ידי ה-Device Policy Controller.
• [C-1-7] כשקיים פרופיל מנוהל, חובה לחשוף את האפשרויות הבאות למשתמש גם למשתמש הראשי וגם לפרופיל המנוהל:
  • ניהול נפרד של השימוש בסוללה, במיקום, בחבילת הגלישה ובאחסון של המשתמש הראשי ושל הפרופיל המנוהל.
  • ניהול עצמאי של אפליקציות VPN שמותקנות בפרופיל המשתמש הראשי או בפרופיל המנוהל.
  • ניהול עצמאי של אפליקציות שמותקנות בפרופיל המשתמש הראשי או בפרופיל המנוהל.
  • ניהול עצמאי של חשבונות בתוך המשתמש הראשי או בפרופיל המנוהל.
• [C-1-8] חובה לוודא שאפליקציות החיוג, אנשי הקשר וההודעות המותקנות מראש יכולות לחפש ולחפש מידע על מבצעי השיחות מהפרופיל המנוהל (אם קיים) לצד המידע מהפרופיל הראשי, אם אמצעי הבקרה של מדיניות המכשיר מאפשר זאת.
• [C-1-9] חובה לוודא שהוא עומד בכל דרישות האבטחה שחלות על מכשיר עם כמה משתמשים מופעלים (ראו קטע 9.5), גם אם הפרופיל המנוהל לא נספר כמשתמש נוסף בנוסף למשתמש הראשי.

יצירת דרישות חדשות

• [C-1-10] חובה לוודא שנתוני צילום המסך נשמרים באחסון של פרופיל העבודה כשצילום המסך מתבצע באמצעות חלון topActivity שמוגדר כמוקד (החלון האחרון שבו המשתמש קיים אינטראקציה מבין כל הפעילויות) וששייך לאפליקציה בפרופיל העבודה.
• [C-1-11] אסור לצלם תוכן מסך אחר (סרגל המערכת, התראות או תוכן אישי בפרופיל) מלבד חלון/חלונות של האפליקציה בפרופיל העבודה כששומרים צילום מסך בפרופיל העבודה (כדי לוודא שנתוני הפרופיל האישי לא נשמרים בפרופיל העבודה).

סיום הדרישות החדשות

אם הטמעות של מכשירים מגדירות את android.software.managed_users ו-android.software.secure_lock_screen, הן:

• [C-2-1] חובה לתמוך באפשרות לציין מסך נעילה נפרד שעומד בדרישות הבאות כדי להעניק גישה לאפליקציות שפועלות בפרופיל מנוהל בלבד.
  • הטמעות במכשירים חייבות לפעול בהתאם לכוונה של DevicePolicyManager.ACTION_SET_NEW_PASSWORD ולהציג ממשק להגדרת פרטי כניסה נפרדים למסך הנעילה של הפרופיל המנוהל.
  • פרטי הכניסה של מסך הנעילה בפרופיל המנוהל חייבים להשתמש באותם מנגנונים לאחסון ולניהול של פרטי הכניסה כמו בפרופיל ההורה, כפי שמתואר באתר של פרויקט Android Open Source.
  • מדיניות הסיסמאות של DPC חייבת לחול רק על פרטי הכניסה של מסך הנעילה של הפרופיל המנוהל, אלא אם נקרא למכונה DevicePolicyManager שמוחזרת על ידי getParentProfileInstance.
• כשאנשי קשר מהפרופיל המנוהל מוצגים ביומן השיחות המובנה, בממשק המשתמש במהלך שיחה, בהתראות על שיחות מתמשכות ועל שיחות שלא נענו, באפליקציות של אנשי קשר ובאפליקציות של הודעות, צריך להציג להם את אותו תג שמשמש לציון אפליקציות בפרופיל המנוהל.

3.9.3 תמיכה בחשבונות מנוהלים

אם הטמעות של מכשירים מגדירות את android.software.managed_users, הן:

• [C-1-1] חובה לספק למשתמש אפשרות להתחבר מהמשתמש הנוכחי ולחזור למשתמש הראשי בסשן של כמה משתמשים, כאשר הערך המוחזר מ-isLogoutEnabled הוא true. חובה שאפשר יהיה לגשת לאפשרות הזו של המשתמש ממסך הנעילה בלי לבטל את נעילת המכשיר.

אם הטמעות במכשיר מכריזות על android.software.device_admin ומספקות למשתמש במכשיר אפשרות להוסיף משתמשים משניים, הן:

• [C-SR-1] מומלץ מאוד להציג את אותן הודעות גילוי נאות בנושא הסכמה של בעלי המכשיר ב-AOSP, שהוצגו בתהליך שהתחיל ב-android.app.action.PROVISION_MANAGED_DEVICE, לפני שמאפשרים להוסיף חשבונות למשתמש המשני החדש, כדי שהמשתמשים יבינו שהמכשיר מנוהל.

3.9.4 דרישות התפקיד 'ניהול מדיניות המכשיר'

אם הטמעות של מכשירים מדווחות על הערך android.software.device_admin או על הערך android.software.managed_users, המשמעות היא שהן:

• [C-1-1] חובה לתמוך בתפקיד ניהול מדיניות המכשיר כפי שמוגדר בקטע 9.1. אפשר להגדיר את האפליקציה שמחזיקה בתפקיד ניהול מדיניות המכשיר על ידי הגדרת config_devicePolicyManagement לשם החבילה. אחרי שם החבילה חייב להופיע הערך : ואישור החתימה, אלא אם האפליקציה נטענת מראש.

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

• [C-2-1] יש להטמיע במכשירים תמיכה בהקצאה ללא אפליקציה של בעל תפקיד לניהול מדיניות המכשיר (AOSP מספק הטמעת עזר).

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

• [C-3-1] האפליקציה חייבת להיות מותקנת בכל הפרופילים של המשתמש.
• [C-3-2] בהטמעות של מכשירים, אפשר להגדיר אפליקציה שמעדכנת את בעל התפקיד לניהול מדיניות המכשיר לפני ההקצאה באמצעות ההגדרה config_devicePolicyManagementUpdater.

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

• [C-4-1] האפליקציה חייבת להיות מותקנת מראש במכשיר.
• [C-4-2] האפליקציה חייבת להטמיע מסנן כוונה (intent) שממיר את הערך android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER.

יצירת דרישות חדשות

3.9.5 מסגרת פתרון בעיות במדיניות המכשיר

אם הטמעות של מכשירים מדווחות על הערך android.software.device_admin או על הערך android.software.managed_users, המשמעות היא שהן:

• [C-1-1] חובה לפתור התנגשויות במדיניות המכשיר כפי שמתואר במסגרת לפתרון בעיות במדיניות המכשיר.

סיום הדרישות החדשות

3.10. נגישות

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

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

• [C-1-1] חובה לספק הטמעה של מסגרת הנגישות של Android כפי שמתואר במסמכי התיעוד של ממשקי ה-API לנגישות ב-SDK.
• [C-1-2] חובה ליצור אירועי נגישות ולשלוח את הערך המתאים של AccessibilityEvent לכל ההטמעות הרשמות של AccessibilityService, כפי שמתואר ב-SDK.
• [C-1-4] חובה לספק למשתמש אמצעי בקרה על שירותי הנגישות שמצהירים על AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. לתשומת ליבכם: בהטמעות במכשירים עם סרגל ניווט של מערכת, צריך לאפשר למשתמש להשתמש בלחצן בסרגל הניווט של המערכת כדי לשלוט בשירותים האלה.

אם הטמעות במכשירים כוללות שירותי נגישות שהותקנו מראש, הן:

• [C-2-1] חובה להטמיע את שירותי הנגישות המותקנים מראש כאפליקציות Direct Boot Aware כשאחסון הנתונים מוצפן באמצעות הצפנה מבוססת-קובץ (FBE).
• צריך לספק מנגנון בתהליך ההגדרה מחוץ לקופסה כדי לאפשר למשתמשים להפעיל שירותי נגישות רלוונטיים, וגם אפשרויות לשינוי גודל הגופן, גודל המסך וביצוע תנועות להגדלה.

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

Android כולל ממשקי API שמאפשרים לאפליקציות להשתמש בשירותי Text-to-Speech ‏(TTS), ומאפשרים לספקי שירותים לספק הטמעות של שירותי TTS.

אם הטמעות של מכשירים מדווחות על התכונה android.hardware.audio.output, הן:

• [C-1-1] חובה לתמוך בממשקי ה-API של Android TTS framework.

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

• [C-2-1] חובה לספק למשתמש אפשרות לבחור מנוע TTS לשימוש ברמת המערכת.

3.12. TV Input Framework

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

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

• [C-1-1] חובה להצהיר על תכונת הפלטפורמה android.software.live_tv.
• [C-1-2] חובה לתמוך בכל ממשקי ה-API של TIF, כך שאפשר יהיה להתקין אפליקציה שמשתמשת בממשקי ה-API האלה ובשירות הקלט של צד שלישי שמבוסס על TIF ולהשתמש בה במכשיר.

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

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

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

• [C-1-1] חובה לאפשר למשתמש להוסיף או להסיר את המשבצות שסופקו דרך ממשקי ה-API של quicksettings מאפליקציה של צד שלישי.
• [C-1-2] אסור להוסיף באופן אוטומטי משבצת מאפליקציה של צד שלישי ישירות להגדרות המהירות.
• [C-1-3] חובה להציג את כל המשבצות שהמשתמשים הוסיפו מאפליקציות של צד שלישי, לצד המשבצות של ההגדרות המהירות שסופקו על ידי המערכת.

3.14. ממשק המשתמש של המדיה

אם הטמעות במכשירים כוללות אפליקציות שלא מופעלות באמצעות קול (האפליקציות) שמקיימות אינטראקציה עם אפליקציות של צד שלישי דרך MediaBrowser או MediaSession, האפליקציות:

• [C-1-2] חובה להציג בבירור סמלים שהתקבלו דרך getIconBitmap() או getIconUri() וכותרות שהתקבלו דרך getTitle(), כפי שמתואר בקטע MediaDescription. יכול להיות שנקצר את השמות כדי לעמוד בתקנות הבטיחות (למשל, הסחת דעת של הנהג).

• [C-1-3] חובה להציג את סמל האפליקציה של הצד השלישי בכל פעם שמוצג תוכן שמסופק על ידי האפליקציה הזו של הצד השלישי.

• [C-1-4] חובה לאפשר למשתמש לקיים אינטראקציה עם כל היררכיית MediaBrowser. יכולים להגביל את הגישה לחלק מההיררכיה כדי לעמוד בתקנות הבטיחות (למשל, הסחת דעת של הנהג), אבל אסור להעניק יחס מועדף על סמך תוכן או ספק תוכן.

• [C-1-5] MUST consider double tap of KEYCODE_HEADSETHOOK or KEYCODE_MEDIA_PLAY_PAUSE as KEYCODE_MEDIA_NEXT for MediaSession.Callback#onMediaButtonEvent.

3.15. אפליקציות ללא התקנה

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

• [C-1-1] אסור להקצות לאפליקציות ללא התקנה הרשאות שהערך של android:protectionLevel הוא "instant".
• [C-1-2] אסור לאפליקציות ללא התקנה לקיים אינטראקציה עם אפליקציות מותקנות באמצעות כוונות משתמשים מרומזות, אלא אם מתקיים אחד מהתנאים הבאים:
  • מסנן דפוס ה-Intent של הרכיב חשוף ויש לו את הערך CATEGORY_BROWSABLE
  • הפעולה יכולה להיות אחת מהפעולות הבאות: ACTION_SEND, ‏ ACTION_SENDTO, ‏ ACTION_SEND_MULTIPLE
  • היעד נחשף באופן מפורש באמצעות android:visibleToInstantApps
• [C-1-3] אסור לאפליקציות ללא התקנה לקיים אינטראקציה מפורשת עם אפליקציות מותקנות, אלא אם הרכיב נחשף באמצעות android:visibleToInstantApps.
• [C-1-4] אסור לאפליקציות מותקנות לראות פרטים על אפליקציות ללא התקנה במכשיר, אלא אם האפליקציה ללא התקנה מתחברת במפורש לאפליקציה המותקנת.

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

  • [C-1-5] חובה לספק למשתמש אפשרות להציג ולמחוק אפליקציות מיידיות שנשמרו במטמון באופן מקומי לכל חבילת אפליקציות בנפרד.
  • [C-1-6] חובה לספק התראה קבועה למשתמשים שאפשר לכווץ בזמן שאפליקציית Instant פועלת בחזית. ההודעה הזו חייבת לכלול את ההודעה שאפליקציות מיידיות לא דורשות התקנה, ולספק למשתמש אמצעי ניווט שמפנה אותו למסך פרטי האפליקציה בהגדרות. באפליקציות מיידיות שמופעלות באמצעות כוונות אינטרנט, כפי שהן מוגדרות באמצעות כוונה עם פעולה Intent.ACTION_VIEW וסכימת http או https, צריכה להיות אפשרות נוספת למשתמש שלא להפעיל את האפליקציה המיידית ולהפעיל את הקישור המשויך באמצעות דפדפן האינטרנט המוגדר, אם יש דפדפן זמין במכשיר.
  • [C-1-7] חובה לאפשר גישה לאפליקציות מיידיות שפועלות דרך התכונה 'מהזמן האחרון', אם התכונה 'מהזמן האחרון' זמינה במכשיר.

• [C-1-8] חובה לטעון מראש אפליקציה אחת או יותר או רכיבי שירות אחד או יותר עם בורר כוונות (intent handler) לכוונות שמפורטות ב-SDK כאן, ולהפוך את הכוונות לגלויות לאפליקציות מיידיות.

3.16. התאמת מכשירים נלווים

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

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

• [C-1-1] חובה להצהיר על דגל התכונה FEATURE_COMPANION_DEVICE_SETUP .
• [C-1-2] חובה לוודא שהממשקי ה-API בחבילה android.companion הווטמעו באופן מלא.
• [C-1-3] חובה לספק למשתמש אמצעי עזר כדי לאפשר לו לבחור או לאשר שמכשיר נלווה נמצא ופועל.

3.17. אפליקציות כבדות

אם הטמעות במכשירים מכריזות על התכונה FEATURE_CANT_SAVE_STATE, הן:

• [C-1-1] חייבת להיות מותקנת רק אפליקציה אחת שמציינת את cantSaveState שפועלת במערכת בכל רגע נתון. אם המשתמש יוצא מאפליקציה כזו בלי לצאת ממנה באופן מפורש (לדוגמה, על ידי לחיצה על לחצן הבית בזמן שהוא יוצא מפעילות פעילה במערכת, במקום לחיצה על לחצן החזרה אחורה כשאין פעילויות פעילות שנותרו במערכת), ההטמעות במכשיר חייבות לתת לאפליקציה הזו עדיפות ב-RAM, כמו שהן עושות לדברים אחרים שצפויים להמשיך לפעול, כמו שירותים בחזית. כשאפליקציה כזו פועלת ברקע, המערכת עדיין יכולה להחיל עליה תכונות של ניהול צריכת החשמל, כמו הגבלת המעבד והגישה לרשת.
• [C-1-2] חובה לספק אפשרות בממשק המשתמש לבחור את האפליקציה שלא תשתתף במנגנון הרגיל לשמירת המצב או לשחזור שלו אחרי שהמשתמש יפעיל אפליקציה שנייה שהוגדרה באמצעות המאפיין cantSaveState.
• [C-1-3] אסור להחיל שינויים אחרים במדיניות על אפליקציות שמציינות את הערך cantSaveState, כמו שינוי ביצועי המעבד או שינוי תעדוף התזמון.

אם הטמעות במכשירים לא מכריזות על התכונה FEATURE_CANT_SAVE_STATE, הן:

• [C-1-1] חובה להתעלם מהמאפיין cantSaveState שהוגדר על ידי אפליקציות, ואסור לשנות את התנהגות האפליקציה על סמך המאפיין הזה.

3.18. אנשי הקשר

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

RawContacts "משויכים" או "מאוחסנים" בחשבון כשהעמודות ACCOUNT_NAME ו-ACCOUNT_TYPE של אנשי הקשר הגולמיים תואמות לשדות Account.name ו-Account.type של החשבון.

חשבון מקומי שמוגדר כברירת מחדל: חשבון של אנשי קשר גולמיים שנשמרים רק במכשיר ולא משויכים לחשבון ב-AccountManager. אנשי הקשר האלה נוצרים עם ערכים של null בעמודות ACCOUNT_NAME ו-ACCOUNT_TYPE.

חשבון מקומי בהתאמה אישית: חשבון של אנשי קשר גולמיים שנשמרים רק במכשיר ולא משויכים לחשבון ב-AccountManager, שנוצרים עם ערך אחד לפחות שאינו null בעמודות ACCOUNT_NAME ו-ACCOUNT_TYPE.

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

• [C-SR-1] מומלץ מאוד לא ליצור חשבונות מקומיים בהתאמה אישית.

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

• [C-1-1] ה-ACCOUNT_NAME של החשבון המקומי המותאם אישית חייב להוחזר על ידי ContactsContract.RawContacts.getLocalAccountName
• [C-1-2] ה-ACCOUNT_TYPE של החשבון המקומי המותאם אישית חייב להוחזר על ידי ContactsContract.RawContacts.getLocalAccountType
• [C-1-3] חובה להוסיף אנשי קשר גולמיים שמוטמעים על ידי אפליקציות צד שלישי באמצעות החשבון המקומי שמוגדר כברירת מחדל (כלומר, על ידי הגדרת ערכים null עבור ACCOUNT_NAME ו-ACCOUNT_TYPE) לחשבון המקומי המותאם אישית.
• [C-1-4] אסור להסיר אנשי קשר גולמיים שהוכנסו לחשבון המקומי המותאם אישית כשמוסיפים או מסירים חשבונות.
• [C-1-5] פעולות מחיקה שמבוצעות בחשבון המקומי המותאם אישית חייבות להוביל למחיקה מיידית של אנשי הקשר הגולמיים (כאילו הפרמטר CALLER_IS_SYNCADAPTER הוגדר כ-true), גם אם הפרמטר CALLER\_IS\_SYNCADAPTER הוגדר כ-false או לא צוין.

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

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

• [C-0-1] חייב להיות מסוגל להתקין ולהריץ קבצים מסוג ‎ ".apk" של Android שנוצרו באמצעות הכלי ‎ "aapt" שכלול ב-Android SDK הרשמי.

  • מאחר שהדרישה שלמעלה עשויה להיות מאתגרת, מומלץ להשתמש במערכת ניהול החבילות של הטמעת העזר של AOSP בהטמעות במכשירים.

• [C-0-2] חובה לתמוך באימות של קבצים מסוג ‎ ".apk" באמצעות APK Signature Scheme v3.1,‏ APK Signature Scheme v3,‏ APK Signature Scheme v2 וחתימת JAR.

• [C-0-3] אסור להרחיב את הפורמטים של ‎.apk,‏ Android Manifest,‏ קוד בינארי של Dalvik או קוד בינארי של RenderScript באופן שימנע את ההתקנה וההפעלה הנכונים של הקבצים האלה במכשירים תואמים אחרים.

• [C-0-4] אסור לאפשר לאפליקציות אחרות מלבד 'מתקין הרשומה' הנוכחי של החבילה להסיר את האפליקציה בשקט, ללא אישור מהמשתמש, כפי שמתואר ב-SDK לגבי ההרשאה DELETE_PACKAGE. החריגים היחידים הם האפליקציה לאימות חבילות המערכת שמטפלת ב-intent‏ PACKAGE_NEEDS_VERIFICATION, והאפליקציה לניהול האחסון שמטפלת ב-intent‏ ACTION_MANAGE_STORAGE.

• [C-0-5] חובה שתהיה פעילות שמטפלת ב-intent‏ android.settings.MANAGE_UNKNOWN_APP_SOURCES.

• [C-0-6] אסור להתקין חבילות אפליקציה ממקורות לא מוכרים, אלא אם האפליקציה שמבקשת את ההתקנה עומדת בכל הדרישות הבאות:

  • חובה להצהיר על ההרשאה REQUEST_INSTALL_PACKAGES או להגדיר את android:targetSdkVersion ל-24 או פחות.
  • המשתמש חייב להעניק הרשאה להתקנת אפליקציות ממקורות לא מוכרים.

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

• [C-0-7] חובה להציג למשתמש תיבת דו-שיח עם מחרוזת האזהרה שסופקה באמצעות ממשק ה-API של המערכת PackageManager.setHarmfulAppWarning לפני שמפעילים פעילות באפליקציה שסומנה על ידי אותו ממשק API של המערכת PackageManager.setHarmfulAppWarning כפעילות שעלולה להזיק.

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

• [C-0-8] חובה להטמיע תמיכה ב-Incremental File System כפי שמתואר כאן.

• [C-0-9] חובה לתמוך באימות של קובצי APK באמצעות APK Signature Scheme v4 ו-APK Signature Scheme v4.1.

הערה: יכול להיות שתוכלו לפטור מהדרישות האלה הטמעות של מכשירים ששווקו עם Android מגרסה 10 ואילך, ולא ניתן לעמוד בדרישות [C-0-8] ו-[C-0-9] באמצעות עדכון של תוכנת המערכת.

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

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

• [C-0-1] חובה לתמוך בפורמטים של המדיה, בקודקים, במפענחים, בסוגי הקבצים ובפורמטים של הקונטיינרים שמוגדרים בקטע 5.1 לכל קודק שמוצהר על ידי MediaCodecList.
• [C-0-2] חובה להצהיר ולדווח על תמיכה במקודדים ובמקודדים הזמינים לאפליקציות של צד שלישי דרך MediaCodecList.
• [C-0-3] חייב להיות מסוגל לפענח כראוי את כל הפורמטים שהוא יכול לקודד ולהפוך אותם לזמינים לאפליקציות של צד שלישי. הנתונים האלה כוללים את כל זרמי הביט שהקודקים שלו יוצרים ואת הפרופילים שמדווחים ב-CamcorderProfile.

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

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

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

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

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

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

פרטים נוספים זמינים בקטע 5.1.3. פרטי קודקי האודיו.

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

• [C-1-1] PCM/WAVE
• [C-1-2] FLAC
• [C-1-3] Opus

כל מקודדי האודיו חייבים לתמוך באפשרויות הבאות:

• [C-3-1] פריימים של אודיו ב-PCM 16 ביט בסדר בייטים מקורי באמצעות ה-API של android.media.MediaCodec.

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

פרטים נוספים זמינים בקטע 5.1.3. פרטי קודקי האודיו.

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

• [C-1-1] MPEG-4 AAC Profile‏ (AAC LC)
• [C-1-2] MPEG-4 HE AAC Profile‏ (AAC+)
• [C-1-3] פרופיל MPEG-4 HE AACv2‏ (enhanced AAC+)
• [C-1-4] AAC ELD‏ (AAC משופר עם זמן השהיה קצר)
• [C-1-11] xHE-AAC (פרופיל HE AAC מורחב ISO/IEC 23003-3, שכולל את פרופיל הבסיס USAC ופרופיל בקרת טווח דינמי ISO/IEC 23003-4)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE, כולל פורמטים של אודיו ברזולוציה גבוהה עד 24 ביט, תדירות דגימה של 192kHz ו-8 ערוצים. חשוב לזכור שהדרישה הזו היא לצורך פענוח בלבד, ושמותר למכשיר לבצע דגימה לאחור (downsampling) ומייקס לאחור (downmix) במהלך שלב ההפעלה.
• [C-1-10] Opus

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

• [C-2-1] חובה לבצע את פענוח הנתונים ללא ערבוב למטה (למשל, צריך לבצע פענוח של שידור AAC 5.0 לחמישה ערוצים של PCM, ושל שידור AAC 5.1 לשישה ערוצים של PCM).
• [C-2-2] המטא-נתונים של הטווח הדינמי חייבים להיות כפי שמוגדרים ב'בקרת טווח דינמי (DRC)' ב-ISO/IEC 14496-3, ומפתחות ה-DRC מסוג android.media.MediaFormat כדי להגדיר את ההתנהגויות שקשורות לטווח הדינמי של מקודד האודיו. מפתחות ה-DRC של AAC הוצגו ב-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.
• [C-SR-1] מומלץ מאוד שכל מקודדי האודיו מסוג AAC יעמדו בדרישות C-2-1 ו-C-2-2 שלמעלה.

כשמפענחים אודיו מסוג USAC, MPEG-D‏ (ISO/IEC 23003-4):

• [C-3-1] חובה לפרש את המטא-נתונים של עוצמת הקול ושל בקרת עוצמת הקול הדינמית ולהחיל אותם בהתאם לפרופיל בקרת עוצמת הקול הדינמית של MPEG-D DRC ברמה 1.
• [C-3-2] המפענח חייב לפעול בהתאם להגדרות שהוגדרו באמצעות מפתחות android.media.MediaFormat הבאים: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL ו-KEY_AAC_DRC_EFFECT_TYPE.

מקודדים של פרופילים MPEG-4 AAC,‏ HE AAC ו-HE AACv2:

• יכול להיות שתהיה תמיכה בשליטה בעוצמת הקול ובטווח הדינמי באמצעות פרופיל הבקרה של טווח הדינמי ISO/IEC 23003-4.

אם יש תמיכה ב-ISO/IEC 23003-4, וגם המטא-נתונים של ISO/IEC 23003-4 וגם המטא-נתונים של ISO/IEC 14496-3 נמצאים בזרם ביטים מפוענח, אז:

• המטא-נתונים של ISO/IEC 23003-4 יהיו בעלי עדיפות.

כל מקודדי האודיו חייבים לתמוך בפלט של:

• [C-6-1] פריימים של אודיו ב-PCM 16 ביט בסדר בייטים מקורי דרך ה-API של android.media.MediaCodec.

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

• [C-7-1] האפליקציה חייבת להיות מסוגלת להגדיר את הערך באמצעות פענוח עם המפתח KEY_MAX_OUTPUT_CHANNEL_COUNT כדי לקבוע אם התוכן יתבצע ערבוב למטה לסטריאו (כשמשתמשים בערך 2) או שתתבצע הפלט באמצעות מספר הערוצים המקורי (כשמשתמשים בערך שווה או גדול יותר מהמספר הזה). לדוגמה, ערך של 6 או יותר מגדיר ממקוד ליצירת פלט של 6 ערוצים כשמזינים לו תוכן 5.1.
• [C-7-2] במהלך פענוח, המפענח חייב לפרסם את מסכת הערוץ שבה נעשה שימוש בפורמט הפלט באמצעות המפתח KEY_CHANNEL_MASK, באמצעות הקבועים android.media.AudioFormat (לדוגמה: CHANNEL_OUT_5POINT1).

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

• [C-SR-2] מומלץ מאוד שהפענוח יהיה ניתן להגדרה על ידי האפליקציה באמצעות פענוח עם המפתח KEY_MAX_OUTPUT_CHANNEL_COUNT כדי לקבוע אם התוכן יתבצע דאונמיקס לסטריאו (כשמשתמשים בערך 2) או שתתבצע פלט באמצעות מספר הערוצים המקורי (כשמשתמשים בערך שווה או גדול יותר מהמספר הזה). לדוגמה, ערך של 6 או יותר מגדיר ממקוד ליצירת פלט של 6 ערוצים כשמזינים לו תוכן 5.1.
• [C-SR-3] במהלך פענוח, מומלץ מאוד שהמפענח יציג את מסכת הערוץ שבה נעשה שימוש בפורמט הפלט באמצעות המפתח KEY_CHANNEL_MASK, באמצעות הקבועים של android.media.AudioFormat (לדוגמה: CHANNEL_OUT_5POINT1).

5.1.3. פרטי מקודקי האודיו

פורמט/קודק	פרטים	סוגי הקבצים או הפורמטים של הקונטיינרים שנתמכים
MPEG-4 AAC Profile ‏(AAC LC)	תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם תדירויות דגימה רגילות של 8 עד 48kHz.	3GPP‏ (‎.3gp) MPEG-4‏ (‎.mp4,‏ ‎.m4a) AAC גולמי של ADTS (‎.aac, ‏ ADIF לא נתמכים) MPEG-TS‏ (‎.ts, לא ניתן לדלג, פענוח בלבד) Matroska‏ (‎.mkv, פענוח בלבד)
פרופיל MPEG-4 HE AAC‏ (AAC+)	תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם תדירויות דגימה רגילות של 16 עד 48kHz.	3GPP‏ (‎.3gp) MPEG-4‏ (‎.mp4,‏ ‎.m4a)
MPEG-4 HE AACv2 פרופיל (enhanced AAC+)	תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם תדירויות דגימה רגילות של 16 עד 48kHz.	3GPP‏ (‎.3gp) MPEG-4‏ (‎.mp4,‏ ‎.m4a)
AAC ELD (AAC משופר עם זמן אחזור נמוך)	תמיכה בתוכן מונו/סטריאו עם תדירויות דגימה רגילות של 16 עד 48kHz.	3GPP‏ (‎.3gp) MPEG-4‏ (‎.mp4,‏ ‎.m4a)
USAC	תמיכה בתוכן מונו/סטריאו עם תדירויות דגימה רגילות של 7.35kHz עד 48kHz.	MPEG-4‏ (‎.mp4,‏ ‎.m4a)
AMR-NB	4.75 עד 12.2kbps דגימה ב-8kHz	3GPP‏ (‎.3gp)
AMR-WB	9 שיעורים מ-6.60kbit/s עד 23.85kbit/s שנדגמו ב-16kHz, כפי שמוגדר ב- AMR-WB, ‏ Adaptive Multi-Rate – Wideband Speech Codec	3GPP‏ (‎.3gp)
FLAC	גם למקודד וגם למפענח: חובה שתהיה תמיכה לפחות במצבים Mono ו-Stereo. חובה שתהיה תמיכה בתדירויות דגימה של עד 192kHz, וברזולוציות של 16 ו-24 ביט. עיבוד נתוני אודיו של FLAC 24 ביט חייב להיות זמין עם הגדרת אודיו של נקודה צפה.	FLAC‏ (‎.flac) MPEG-4‏ (‎.mp4,‏ ‎.m4a, ‏ פענוח בלבד) Matroska‏ (‎.mkv, פענוח בלבד)
MP3	מונו/סטריאו 8-320Kbps קבוע (CBR) או קצב העברת נתונים משתנה (VBR)	MP3‏ (‎.mp3) MPEG-4‏ (‎.mp4,‏ ‎.m4a, ‏ פענוח בלבד) Matroska‏ (‎.mkv, פענוח בלבד)
MIDI	MIDI מסוג 0 ו-1. DLS גרסה 1 ו-2. XMF ו-Mobile XMF. תמיכה בפורמטים של רינגטונים RTTTL/RTX,‏ OTA ו-iMelody	סוג 0 ו-1 (‎.mid,‏ ‎.xmf,‏ ‎.mxmf) RTTTL/RTX‏ (‎.rtttl, ‎.rtx) iMelody‏ (‎.imy)
Vorbis	פענוח: תמיכה בתוכן מונו, סטריאו, 5.0 ו-5.1 עם שיעורי דגימה של 8,000,‏ 12,000,‏ 16,000,‏ 24,000 ו-48,000Hz. קידוד: תמיכה בתוכן מונו וסטריאו עם שיעורי דגימה של 8,000,‏ 12,000,‏ 16,000,‏ 24,000 ו-48,000Hz.	Ogg‏ (‎.ogg) MPEG-4‏ (‎.mp4,‏ ‎.m4a, ‏ פענוח בלבד) Matroska‏ (‎.mkv) Webm ‏(‎.webm)
PCM/WAVE	קודק PCM חייב לתמוך ב-PCM ליניארי של 16 ביט וב-float של 16 ביט. הכלי לחילוץ קובצי WAVE חייב לתמוך ב-PCM לינאריים של 16 ביט, 24 ביט ו-32 ביט וב-float של 32 ביט (בתדירויות עד למגבלה של החומרה). חובה לתמוך בתדירויות דגימה של 8kHz עד 192kHz.	WAVE‏ (‎.wav)
Opus	פענוח: תמיכה בתוכן מונו, סטריאו, 5.0 ו-5.1 עם שיעורי דגימה של 8,000,‏ 12,000,‏ 16,000,‏ 24,000 ו-48,000Hz. קידוד: תמיכה בתוכן מונו וסטריאו עם שיעורי דגימה של 8,000,‏ 12,000,‏ 16,000,‏ 24,000 ו-48,000Hz.	Ogg‏ (‎.ogg) MPEG-4‏ (‎.mp4,‏ ‎.m4a, ‏ פענוח בלבד) Matroska‏ (‎.mkv) Webm ‏(‎.webm)

5.1.4. קידוד תמונות

פרטים נוספים זמינים בקטע 5.1.6. פרטי קודקים של תמונות.

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

• [C-0-1] JPEG
• [C-0-2] PNG
• [C-0-3] WebP

יצירת דרישות חדשות

• [C-0-4] AVIF
  • המכשירים חייבים לתמוך ב-BITRATE_MODE_CQ ובפרופיל הבסיס.

סיום הדרישות החדשות

אם הטמעות במכשירים תומכות בקידוד HEIC דרך android.media.MediaCodec לסוג המדיה MIMETYPE_IMAGE_ANDROID_HEIC, הן:

• [C-1-1] חובה לספק קודק מקודד HEVC שמואץ בחומרה שתומך במצב בקרת קצב העברת הנתונים BITRATE_MODE_CQ, בפרופיל HEVCProfileMainStill ובגודל פריים של 512 על 512 פיקסלים.

5.1.5. פענוח הקוד של התמונה

פרטים נוספים זמינים בקטע 5.1.6. פרטי קודקים של תמונות.

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

• [C-0-1] JPEG
• [C-0-2] קובץ GIF
• [C-0-3] PNG
• [C-0-4] BMP
• [C-0-5] WebP
• [C-0-6] גולמי
• [C-0-7] AVIF (פרופיל בסיס)

אם הטמעות במכשירים תומכות בפענוח וידאו HEVC, הן: * [C-1-1] חייבות לתמוך בפענוח תמונות HEIF‏ (HEIC).

מקודדי תמונות שתומכים בפורמט עם עומק סיביות גבוה (9 סיביות ומעלה לכל ערוץ):

• [C-2-1] חובה לתמוך בהוצאה של פורמט מקביל של 8 ביט אם הבקשה מגיעה מהאפליקציה, למשל דרך ההגדרה ARGB_8888 של android.graphics.Bitmap.

5.1.6. פרטי קודקים של תמונות

פורמט/קודק	פרטים	סוגי קבצים/פורמטים של קובצי מאגר נתמכים
JPEG	Base+progressive	JPEG‏ (‎.jpg)
GIF		GIF ‏(‎.gif)
PNG		PNG ‏(‎.png)
BMP		BMP ‏(‎.bmp)
WebP		WebP ‏(‎.webp)
גולמי		ARW‏ (‎.arw), ‏ CR2‏ (‎.cr2), ‏ DNG‏ (‎.dng), ‏ NEF‏ (‎.nef), ‏ NRW‏ (‎.nrw), ‏ ORF‏ (‎.orf),‏ PEF‏ (‎.pef), ‏ RAF‏ (‎.raf), ‏ RW2‏ (‎.rw2), ‏ SRW‏ (‎.srw)
HEIF	תמונה, אוסף תמונות, רצף תמונות	HEIF‏ (‎.heif), ‏ HEIC‏ (‎.heic)
AVIF (פרופיל בסיס)	פרופיל Baseline של תמונה, אוסף תמונות או רצף תמונות	קונטיינר HEIF‏ (‎.avif)

מקודדים ומפענחים של תמונות שחשופים דרך ממשק ה-API של MediaCodec

• [C-1-1] חובה לתמוך בפורמט צבע גמיש YUV420 8:8:8 (COLOR_FormatYUV420Flexible) דרך CodecCapabilities.

• [C-SR-1] מומלץ מאוד לתמוך בפורמט צבע RGB888 למצב Surface של הקלט.

• [C-1-3] חובה לתמוך לפחות באחד מפורמטים של צבע YUV420 8:8:8 שטוח או חצי-שטוח: COLOR_FormatYUV420PackedPlanar (שווה ל-COLOR_FormatYUV420Planar) או COLOR_FormatYUV420PackedSemiPlanar (שווה ל-COLOR_FormatYUV420SemiPlanar). מומלץ מאוד לתמוך בשניהם.

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

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

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

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

• [C-1-2] מכשירי קידוד ופענוח וידאו חייבים לתמוך בפורמטים גמישים של צבע YUV420 8:8:8 (COLOR_FormatYUV420Flexible) עד CodecCapabilities.

• [C-1-3] מקודדי וידאו ומפענחי וידאו חייבים לתמוך לפחות באחד מפורמטים צבעיים של YUV420 8:8:8 שטוח או חצי-שטוח: COLOR_FormatYUV420PackedPlanar (שווה ערך ל-COLOR_FormatYUV420Planar) או COLOR_FormatYUV420PackedSemiPlanar (שווה ערך ל-COLOR_FormatYUV420SemiPlanar). מומלץ מאוד לתמוך בשניהם.

• [C-SR-1] מומלץ מאוד שמקודדי וידאו ומפענחי וידאו יתמכו לפחות באחד מפורמטים צבעיים שטוחים או חצי-שטוחים של YUV420 8:8:8 שעברו אופטימיזציה לחומרה (YV12, ‏ NV12, ‏ NV21 או פורמט מקביל שעובר אופטימיזציה על ידי ספק).

• [C-1-5] ממירי וידאו שתומכים בפורמט עם עומק סיביות גבוה (9 סיביות ומעלה לכל ערוץ) חייבים לתמוך בהפקת פורמט מקביל של 8 סיביות, אם הבקשה הזו מתקבלת מהאפליקציה. כדי לשקף את העובדה הזו, צריך לתמוך בפורמט צבע YUV420 8:8:8 דרך android.media.MediaCodecInfo.

אם הטמעות של מכשירים מפרסמות תמיכה בפרופיל HDR דרך Display.HdrCapabilities, הן:

• [C-2-1] חובה לתמוך בניתוח ובטיפול של מטא-נתונים סטטיים של HDR.

אם הטמעות של מכשירים מכריזות על תמיכה ברענון תוך-פריים באמצעות FEATURE_IntraRefresh בכיתה MediaCodecInfo.CodecCapabilities, הן:

• [C-3-1] חובה לתמוך בתקופתי רענון בטווח של 10 עד 60 פריימים, ולפעול בצורה מדויקת בטווח של 20% מתקופת הרענון שהוגדרה.

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

• [C-4-1] אם ההגדרה מתבצעת באמצעות פלט Surface, ברירת המחדל חייבת להיות פורמט הצבע המותאם בצורה אופטימלית לתצוגת החומרה.
• [C-4-2] צריך להגדיר כברירת מחדל פורמט צבע YUV420 8:8:8 שמותאם לקריאה של מעבד אם לא מגדירים שימוש בפלט Surface.

5.1.8. רשימת קודיקי וידאו

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

5.1.9. אבטחה של קודק מדיה

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

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

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

• [C-1-1] חובה לספק תמיכה בקודקים של מדיה באמצעות ממשקי OMX או Codec 2.0 API (או שניהם) כמו בפרויקט הקוד הפתוח של Android, ולא להשבית או לעקוף את אמצעי האבטחה. המשמעות היא לא שכל קודק חייב להשתמש ב-OMX או ב-Codec 2.0 API, אלא שחייבת להיות תמיכה לפחות באחד מה-API האלה, ותמיכה ב-API הזמינים חייבת לכלול את אמצעי האבטחה הקיימים.
• [C-SR-1] מומלץ מאוד לכלול תמיכה ב-Codec 2.0 API.

אם הטמעות המכשיר לא תומכות ב-Codec 2.0 API, הן:

• [C-2-1] חובה לכלול את קודק התוכנה OMX התואם מפרויקט Android Open Source (אם הוא זמין) לכל פורמט מדיה וסוג (מקודד או מפענח) שנתמכים במכשיר.
• [C-2-2] קודיקים עם שמות שמתחילים ב-'OMX.google.‎' חייב להתבסס על קוד המקור של פרויקט הקוד הפתוח של Android.
• [C-SR-2] מומלץ מאוד להריץ את קודקי התוכנה של OMX בתהליך קודק שאין לו גישה למנהלי חומרה מלבד ממיפויי זיכרון.

אם הטמעות במכשירים תומכות ב-Codec 2.0 API, הן:

• [C-3-1] חובה לכלול את קודק התוכנה התואם של Codec 2.0 מ-Android Open Source Project (אם הוא זמין) לכל פורמט מדיה וסוג (מקודד או מפענח) שנתמכים במכשיר.
• [C-3-2] חובה לאכלס את קודקי התוכנה של Codec 2.0 בתהליך של קודק התוכנה, כפי שמפורט בפרויקט Android Open Source, כדי לאפשר מתן גישה מצומצמת יותר לקודקי תוכנה.
• [C-3-3] קודיקים ששמותיהם מתחילים ב-'c2.android.‎' חייב להתבסס על קוד המקור של פרויקט הקוד הפתוח של Android.

5.1.10. אפיון של קודק מדיה

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

• [C-1-1] חובה להחזיר ערכים נכונים של מאפייני הקודק של המדיה באמצעות ה-API של MediaCodecInfo.

ובפרט:

• [C-1-2] קודיקים עם שמות שמתחילים ב-'OMX'. חובה להשתמש בממשקי ה-API של OMX, והשמות חייבים לעמוד בהנחיות למתן שמות של OMX IL.
• [C-1-3] קודיקים עם שמות שמתחילים ב-'c2.‎' חובה להשתמש ב-Codec 2.0 API, והשמות צריכים לעמוד בהנחיות למתן שמות של Codec 2.0 ל-Android.
• [C-1-4] קודיקים עם שמות שמתחילים ב-'OMX.google.‎' או ב-'c2.android.‎' אסור לאפיין אותו כספק או כמואץ בחומרה.
• [C-1-5] אסור להגדיר כתוכנה בלבד קודקים שפועלים בתהליך קודק (של ספק או של מערכת) שיש להם גישה למנהלי חומרה מלבד מקצאי זיכרון וממפים.
• [C-1-6] קודיקס שלא נמצאים בפרויקט Android Open Source Project או שלא מבוססים על קוד המקור בפרויקט הזה חייבים להיות מסווגים כספק.
• [C-1-7] קודיקים שמשתמשים בהאצת חומרה חייבים להיות מסווגים ככאלה.
• [C-1-8] אסור ששמות הקודקים יהיו מטעים. לדוגמה, קודיקים בשם 'decoders' חייבים לתמוך בפענוח, וקודיקים בשם 'encoders' חייבים לתמוך בקידוד. קודיקים עם שמות שמכילים פורמטים של מדיה חייבים לתמוך בפורמטים האלה.

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

• [C-2-1] כל קודיקי הווידאו חייבים לפרסם נתונים על קצב הפריימים שאפשר להשיג בגדלים הבאים, אם הקודק תומך בהם:

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p	HD 1080p	UHD
רזולוציית וידאו	176 x 144 פיקסלים (H263, ‏ MPEG2, ‏ MPEG4) 352 x 288 פיקסלים (מקודד MPEG4, ‏ H263, ‏ MPEG2) 320 x 180 פיקסלים (VP8, ‏ VP8) 320 x 240 פיקסלים (אחר)	704 x 576 פיקסלים (H263) 640 x 360 פיקסלים (VP8, ‏ VP9) 640 x 480 פיקסלים (מקודד MPEG4) 720 x 480 פיקסלים (אחר, AV1)	1408 x 1152 פיקסלים (H263) 1280 x 720 פיקסלים (אחר, AV1)	1920 x 1080 פיקסלים (לא MPEG4, ‏ AV1)	3840 x 2160 פיקסלים (HEVC, ‏ VP9, ‏ AV1)

• [C-2-2] קודיקים של וידאו שמאופיינים כקודקים עם שיפור מהירות באמצעות חומרה חייבים לפרסם מידע על נקודות ביצועים. בכל אחת מהן חייבים להופיע כל נקודות הביצועים הרגילות הנתמכות (שמופיעות ב-API של PerformancePoint), אלא אם הן מכוסות בנקודת ביצועים רגילה אחרת שנתמכת.
• בנוסף, הם צריכים לפרסם נקודות ביצועים מורחבות אם הם תומכים בביצועי וידאו עקביים שאינם אחד מהנתונים הסטנדרטיים שצוינו.

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

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

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

יצירת דרישות חדשות

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

• [C-5-1] חייב להיות לא יותר מ-15% מעל קצב העברת הנתונים בין מרווחי הזמן של פריימים פנימיים (פרימי I) בחלון הזזה אחד.
• [C-5-2] חובה לא צריך לחרוג מ-100% מעל קצב הנתונים בחלון הזזה של שנייה אחת.

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

• [C-6-1] חייב [C-SR-2] מומלץ מאוד לא לחרוג מ-15% מעל קצב העברת הנתונים היעד בחלון הזזה של שנייה אחת.

סיום הדרישות החדשות

אם הטמעות של מכשירים כוללות מסך מובנה בגודל אלכסוני של 2.5 אינץ' לפחות, או כוללות יציאת וידאו או מצהירות על תמיכה במצלמה באמצעות דגל התכונה android.hardware.camera.any, הן:

• [C-1-1] חובה לכלול תמיכה באחד לפחות מקודקי הווידאו VP8 או H.264, ולהפוך אותו לזמין לאפליקציות של צד שלישי.
• צריך לתמוך גם במקודדי וידאו מסוג VP8 וגם במקודדי וידאו מסוג H.264, ולהפוך אותו לזמין לאפליקציות של צד שלישי.

אם הטמעות במכשירים תומכות באחד מקודקי הווידאו H.264, ‏ VP8, ‏ VP9 או HEVC ומאפשרות לאפליקציות של צד שלישי להשתמש בהם, הן:

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

אם הטמעות במכשירים תומכות במקודד הווידאו MPEG-4 SP ומאפשרות לאפליקציות של צד שלישי להשתמש בו, הן:

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

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

• [C-4-1] כל מקודדי הווידאו והתמונות שמשתמשים בהאצת חומרה חייבים לתמוך בקידוד של פריימים מהמצלמות החומריות.
• צריך לתמוך בקידוד של פריימים מהמצלמות החומריות דרך כל מקודדי הווידאו או התמונות.

אם הטמעות במכשירים מספקות קידוד HDR, הן:

• [C-SR-1] מומלץ מאוד לספק פלאגין לממשק ה-API להמרת קידוד חלקה כדי להמיר מפורמט HDR לפורמט SDR.

5.2.1. H.263

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

• [C-1-1] חובה לתמוך ברזולוציית QCIF‏ (176 x 144) באמצעות פרופיל בסיס ברמה 45. רזולוציית SQCIF היא אופציונלית.
• צריכה להיות תמיכה בקצב העברת נתונים (bitrate) שניתן להגדיר באופן דינמי במקודד הנתמך.

5.2.2. H.264

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

• [C-1-1] חובה לתמוך בפרופיל Baseline ברמה 3. עם זאת, התמיכה ב-ASO (סידור שרירותי של פרוסות), ב-FMO (סידור גמיש של מק"טים) וב-RS (פרוסות יתירות) היא אופציונלית. בנוסף, כדי לשמור על תאימות למכשירי Android אחרים, מומלץ שלא להשתמש ב-ASO, ב-FMO וב-RS בפרופיל הבסיסי על ידי מקודדים.
• [C-1-2] חייב לתמוך בפרופילים של קידוד וידאו באיכות SD (רזולוציה רגילה) שמפורטים בטבלה הבאה.
• צריכה להיות תמיכה ברמת 4 בפרופיל הראשי.
• צריך לתמוך בפרופילים של קידוד וידאו באיכות HD (High Definition) כפי שמפורט בטבלה הבאה.

אם הטמעות במכשירים מדווחות על תמיכה בקידוד H.264 לסרטונים ברזולוציה של 720p או 1080p דרך ממשקי ה-API של המדיה, הן:

• [C-2-1] חובה לתמוך בפרופילי הקידוד שמפורטים בטבלה הבאה.

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

5.2.3. VP8

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

• [C-1-1] חובה לתמוך בפרופילים של קידוד וידאו ב-SD.
• צריכה להיות תמיכה בפרופילים הבאים של קידוד וידאו באיכות HD (High Definition).
• [C-1-2] חובה לתמוך בכתיבת קובצי Matroska WebM.
• צריך לספק קודק VP8 לחומרה שעומד בדרישות הקידוד של חומרת RTC בפרויקט WebM, כדי להבטיח איכות סבירה של סטרימינג של וידאו באינטרנט ושל שירותי ועידות וידאו.

אם הטמעות במכשירים מדווחות על תמיכה בקידוד VP8 בסרטונים ברזולוציה של 720p או 1080p דרך ממשקי ה-API של המדיה, הן:

• [C-2-1] חובה לתמוך בפרופילי הקידוד שמפורטים בטבלה הבאה.

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

5.2.4. VP9

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

• [C-1-2] חובה לתמוך בפרופיל 0 ברמה 3.
• [C-1-1] חובה לתמוך בכתיבת קובצי Matroska WebM.
• [C-1-3] חובה ליצור נתונים מסוג CodecPrivate.
• צריך לתמוך בפרופילים של פענוח HD כפי שמצוין בטבלה הבאה.
• [C-SR-1] מומלץ מאוד לתמוך בפרופילים של פענוח HD כפי שמצוין בטבלה הבאה, אם יש מקודד חומרה.

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

אם הטמעות במכשירים טוענות שהן תומכות בפרופיל 2 או בפרופיל 3 דרך ממשקי ה-Media API:

• התמיכה בפורמט 12 ביט היא אופציונלית.

5.2.5. H.265

אם הטמעות המכשירים תומכות בקודק H.265, הן:

• [C-1-1] חובה לתמוך בפרופיל הראשי ברמה 3 ברזולוציה של עד 512x512.
• צריך לתמוך בפרופילים של קידוד HD כפי שמצוין בטבלה הבאה.
• [C-SR-1] מומלץ מאוד לתמוך בפרופיל SD‏ 720 x 480 ובפרופילים של קידוד HD כפי שמצוין בטבלה הבאה, אם יש מקודד חומרה.

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

יצירת דרישות חדשות

5.2.6. AV1

אם הטמעות המכשירים תומכות בקודק AV1, הן:

• [C-1-1] חובה לתמוך בפרופיל ראשי, כולל תוכן 8 ביט ו-10 ביט.

• [C-1-2] חובה לפרסם נתוני ביצועים, כלומר לדווח על נתוני הביצועים באמצעות ממשקי ה-API של getSupportedFrameRatesFor() או getSupportedPerformancePoints() ברזולוציות הנתמכות שמפורטות בטבלה שבהמשך.

• [C-1-3] חובה לקבל מטא-נתונים של HDR ולהעביר אותם לפלט של מקור הנתונים (bitstream)

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

• [C-2-1] חובה לתמוך בפרופיל קידוד HD1080p לכל היותר, כולל, מהטבלה הבאה:

	SD	HD 720p	HD 1080p	UHD
רזולוציית וידאו	720 x 480 פיקסלים	‎1280 x 720 פיקסלים	‎1,920 x 1,080 פיקסלים	3840 x 2160 פיקסלים
קצב המסגרות של הסרטון	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)
קצב העברת נתונים של וידאו	‎5 Mbps	8Mbps	16Mbps	50 Mbps

סיום הדרישות החדשות

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

אם הטמעות במכשירים תומכות בקודקים VP8,‏ VP9,‏ H.264 או H.265, הן:

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

5.3.1. MPEG-2

אם הטמעות במכשירים תומכות במפענחי MPEG-2, הן:

• [C-1-1] חובה לתמוך ברמה הגבוהה של הפרופיל הראשי.

5.3.2. H.263

אם הטמעות במכשירים תומכות במפענחי H.263, הן:

• [C-1-1] חובה לתמוך בפרופיל בסיס ברמה 30 (רזולוציות CIF, ‏ QCIF ו-SQCIF‏ @ 30fps 384kbps) וברמה 45 (רזולוציות QCIF ו-SQCIF‏ @ 30fps 128kbps).

5.3.3. MPEG-4

אם מדובר בהטמעות במכשירים עם מקודדים של MPEG-4, הן:

• [C-1-1] חובה לתמוך בפרופיל פשוט ברמה 3.

5.3.4. H.264

אם הטמעות המכשירים תומכות במפענחי H.264, הן:

• [C-1-1] חובה לתמוך בפרופיל הראשי ברמה 3.1 ובפרופיל Baseline. התמיכה ב-ASO‏ (סידור שרירותי של פרוסות), ב-FMO (סידור גמיש של קטעי מקרו) וב-RS (פרוסות יתירות) היא אופציונלית.
• [C-1-2] חייב להיות מסוגל לפענח סרטונים עם הפרופילים של SD (רזולוציה רגילה) שמפורטים בטבלה הבאה, וקידוד שלהם בוצע באמצעות Baseline Profile ו-Main Profile ברמה 3.1 (כולל 720p30).
• צריכה להיות מסוגלת לפענח סרטונים עם פרופילים של HD (רזולוציה גבוהה) כפי שמצוין בטבלה הבאה.

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

• [C-2-1] חובה לתמוך בפרופילים של פענוח וידאו באיכות HD 720p שמפורטים בטבלה הבאה.
• [C-2-2] חובה לתמוך בפרופילים של פענוח וידאו באיכות HD 1080p שמפורטים בטבלה הבאה.

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

5.3.5. H.265 (‏HEVC)

אם הטמעות המכשירים תומכות בקודק H.265, הן:

• [C-1-1] חייב לתמוך ברמה הראשית של פרופיל Main ברמה 3 ובפרופילים של פענוח וידאו ברזולוציית SD, כפי שמפורט בטבלה הבאה.
• צריך לתמוך בפרופילים של פענוח HD כפי שמצוין בטבלה הבאה.
• [C-1-2] חובה לתמוך בפרופילי הפענוח של HD כפי שמצוין בטבלה הבאה, אם יש ממיר חומרה.

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

• [C-2-1] הטמעות במכשירים חייבות לתמוך לפחות באחת מהאפשרויות הבאות: פענוח H.265 או פענוח VP9 של פרופילים 720, ‏ 1080 ו-UHD.

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

אם הטמעות במכשירים טוענות שהן תומכות בפרופיל HDR דרך ממשקי ה-Media API:

• [C-3-1] הטמעות במכשירים חייבות לקבל את המטא-נתונים הנדרשים של HDR מהאפליקציה, וגם לתמוך בחילוץ ובפלט של המטא-נתונים הנדרשים של HDR מזרם הביטים ו/או מהמאגר.
• [C-3-2] הטמעות במכשירים חייבות להציג תוכן HDR כראוי במסך המכשיר או ביציאת וידאו רגילה (למשל, HDMI).

5.3.6. VP8

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

• [C-1-1] חובה לתמוך בפרופילים של פענוח SD שמפורטים בטבלה הבאה.
• מומלץ להשתמש בקודק VP8 לחומרה שעומד בדרישות.
• צריכה להיות תמיכה בפרופילים של פענוח HD שמפורטים בטבלה הבאה.

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

• [C-2-1] הטמעות של מכשירים חייבות לתמוך בפרופילים של 720p שמפורטים בטבלה הבאה.
• [C-2-2] הטמעות במכשירים חייבות לתמוך בפרופילים של 1080p שמפורטים בטבלה הבאה.

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

5.3.7. VP9

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

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

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

• [C-2-1] חייב לתמוך בפרופילים של פענוח HD כפי שמצוין בטבלה הבאה.

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

• [C-3-1] הטמעות במכשירים חייבות לתמוך לפחות באחת מהאפשרויות הבאות: פענוח VP9 או פענוח H.265 של הפרופילים 720, ‏ 1080 ו-UHD.

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

אם הטמעות במכשירים טוענות לתמיכה ב-VP9Profile2 או ב-VP9Profile3 דרך ממשקי ה-API של המדיה 'CodecProfileLevel':

• התמיכה בפורמט 12 ביט היא אופציונלית.

אם הטמעות של מכשירים טוענות שהן תומכות בפרופיל HDR (VP9Profile2HDR,‏ VP9Profile2HDR10Plus, ‏ VP9Profile3HDR, ‏ VP9Profile3HDR10Plus) דרך ממשקי ה-API של המדיה:

• [C-4-1] הטמעות במכשירים חייבות לקבל מהאפליקציה את המטא-נתונים הנדרשים של HDR (KEY_HDR_STATIC_INFO לכל פרופילי ה-HDR, וגם 'KEY_HDR10_PLUS_INFO' לפרופילים של HDR10Plus). הם חייבים גם לתמוך בחילוץ ובפלט של המטא-נתונים הנדרשים של HDR מזרם הביטים ו/או מהמאגר.
• [C-4-2] הטמעות במכשירים חייבות להציג תוכן HDR כראוי במסך המכשיר או ביציאת וידאו רגילה (למשל, HDMI).

5.3.8. Dolby Vision

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

• [C-1-1] חובה לספק חילוץ עם תמיכה ב-Dolby Vision.
• [C-1-2] חובה להציג תוכן Dolby Vision בצורה תקינה במסך המכשיר או ביציאת וידאו רגילה (למשל, HDMI).
• [C-1-3] חובה להגדיר את מזהה הטראק של שכבות הבסיס התואמות לאחור (אם קיימות) כך שיהיה זהה למזהה הטראק של שכבת Dolby Vision המשולבת.

5.3.9. AV1

אם הטמעות במכשירים תומכות בקודק AV1, הן:

• [C-1-1] חובה לתמוך בפרופיל 0, כולל תוכן של 10 ביט.

יצירת דרישות חדשות

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

• [C-1-1] חובה לתמוך בפרופיל ראשי, כולל תוכן 8 ביט ו-10 ביט.

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

• [C-2-1] חובה שאפשר יהיה לפענח לפחות פרופילים של פענוח וידאו באיכות HD 720p מהטבלה שבהמשך, כשהגובה שמדווח על ידי השיטה Display.getSupportedModes() שווה ל-720p או גבוה ממנו.
• [C-2-2] חובה שאפשר יהיה לפענח לפחות פרופילים של פענוח וידאו ברזולוציית HD 1080p מהטבלה שבהמשך, כשהגובה שמדווח על ידי השיטה Display.getSupportedModes() שווה ל-1080p או גבוה ממנו.

	SD	HD 720p	HD 1080p	UHD
רזולוציית וידאו	720 x 480 פיקסלים	‎1280 x 720 פיקסלים	‎1,920 x 1,080 פיקסלים	3840 x 2160 פיקסלים
קצב המסגרות של הסרטון	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)
קצב העברת נתונים של וידאו	‎5 Mbps	8Mbps	16Mbps	50 Mbps

אם הטמעות במכשירים תומכות בפרופיל HDR דרך ממשקי ה-API של מדיה, הן:

• [C-3-1] חובה לתמוך בחילוץ ובפלט של מטא-נתונים של HDR מזרם הביט או מהמאגר.
• [C-3-2] חובה להציג תוכן HDR כראוי במסך המכשיר או ביציאת וידאו רגילה (למשל, HDMI).

סיום הדרישות החדשות

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

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

5.4.1. הקלטת אודיו גולמי ומידע על המיקרופון

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

• [C-1-1] חובה לאפשר תיעוד של תוכן אודיו גולמי לכל מקור נתונים (input) מסוג AudioRecord או AAudio שנפתח בהצלחה. חובה שתהיה תמיכה לפחות במאפיינים הבאים:

  • פורמט: Linear PCM, ‏ 16-ביט
  • תדירות דגימה: 8000, ‏ 11025, ‏ 16000, ‏ 44100, ‏ 48000Hz
  • ערוצים: מונו
  • מקורות אודיו: DEFAULT,‏ MIC,‏ CAMCORDER,‏ VOICE_RECOGNITION,‏ VOICE_COMMUNICATION,‏ UNPROCESSED או VOICE_PERFORMANCE. הדבר נכון גם להגדרות הקלט המוגדרות מראש המקבילות ב-AAudio, למשל AAUDIO_INPUT_PRESET_CAMCORDER.

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

  • פורמט: Linear PCM, ‏ 16 ביט ו-24 ביט
  • תדירות דגימה: 8000, ‏ 11025, ‏ 16000, ‏ 22050, ‏ 24000, ‏ 32000, ‏ 44100,‏ 48000 הרץ
  • ערוצים: מספר הערוצים שווה למספר המיקרופונים במכשיר

• [C-1-2] חובה לצלם בתדירויות דגימה גבוהות יותר ללא דגימה מחדש.

• [C-1-3] חובה לכלול מסנן מתאים לביטול רעשי aliasing כשקצב הדגימה שצוין למעלה מתועד באמצעות דגימה לאחור.

• צריכה לאפשר הקלטה של תוכן אודיו גולמי באיכות רדיו AM ו-DVD, כלומר:

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

• [C-1-4] חובה לפעול בהתאם ל-API של MicrophoneInfo ולמלא כראוי את המידע על המיקרופונים הזמינים במכשיר שזמינים לאפליקציות של הצד השלישי דרך ה-API של AudioManager.getMicrophones(), עבור AudioRecord פעיל באמצעות MediaRecorder.AudioSources DEFAULT,‏ MIC,‏ CAMCORDER,‏ VOICE_RECOGNITION,‏ VOICE_COMMUNICATION,‏ UNPROCESSED או VOICE_PERFORMANCE. אם הטמעות במכשירים מאפשרות תיעוד של תוכן אודיו גולמי באיכות רדיו AM ואיכות DVD, הן:

• [C-2-1] חובה לצלם ללא דגימה מחדש ביחס גבוה מ-16000:22050 או 44100:48000.

• [C-2-2] חובה לכלול מסנן מתאים לביטול רעשי aliasing לכל דגימה למעלה או למטה.

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

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

• [C-1-1] חובה לתעד את מקור האודיו android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION באחת מתדירויות הדגימה, 44100 ו-48000.
• [C-1-2] חובה להשבית כברירת מחדל כל עיבוד אודיו של הפחתת רעש כשמצלמים שידור אודיו ממקור האודיו AudioSource.VOICE_RECOGNITION.

• [C-1-3] חובה להשבית כברירת מחדל כל בקרת הגברה אוטומטית כשמצלמים שידור אודיו ממקור האודיו AudioSource.VOICE_RECOGNITION.

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

• [C-SR-1] מומלץ מאוד להציג רמות אמפליטודה בטווח התדרים הנמוך: באופן ספציפי, מ-±20dB מ-30Hz עד 100Hz בהשוואה לטווח התדרים הבינוני לכל מיקרופון שמשמש להקלטת מקור האודיו לזיהוי הקול.

• [C-SR-2] מומלץ מאוד להציג רמות אמפליטודה בטווח התדרים הגבוהים: באופן ספציפי, מ-±30dB מ-4,000Hz עד 22KHz בהשוואה לטווח התדרים הבינוני בכל מיקרופון שמשמש להקלטת מקור האודיו לזיהוי הקול.

• צריך להגדיר את רגישות הקלט של האודיו כך שמקור של צליל סינוסואידלי של 1,000Hz שיופעל ברמת לחץ קול (SPL) של 90dB (נמדד במרחק של 30 ס"מ מ לצד המיקרופון) יניב תגובה אידיאלית של RMS 2,500 בטווח של 1,770 עד 3,530 לדגימות של 16 ביט (או -22.35dB ±3dB Full Scale לדגימות של נקודת צפה/דיוק כפול) לכל מיקרופון שמשמש להקלטה של מקור האודיו לזיהוי הקול.

• צריך להקליט את מקור האודיו לזיהוי הקול כך שרמות האמפליטודה של PCM יעקבו באופן לינארי אחרי השינויים ב-SPL של הקלט בטווח של לפחות 30dB, מ-18dB ל-12dB ביחס ל-90dB SPL במיקרופון.

• צריך להקליט את שידור האודיו של זיהוי הדיבור עם עיוות הרמוני כולל (THD) של פחות מ-1% עבור 1kHz ברמת קלט של 90dB SPL במיקרופון.

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

• [C-2-1] חובה לאפשר שליטה באפקט האודיו הזה באמצעות API של android.media.audiofx.NoiseSuppressor.
• [C-2-2] חובה לזהות באופן ייחודי כל הטמעה של טכנולוגיית סינון רעשים באמצעות השדה AudioEffect.Descriptor.uuid.

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

המחלקה android.media.MediaRecorder.AudioSource כוללת את מקור האודיו REMOTE_SUBMIX.

אם הטמעות של מכשירים מגדירות גם את android.hardware.audio.output וגם את android.hardware.microphone, הן:

• [C-1-1] חובה להטמיע כראוי את מקור האודיו REMOTE_SUBMIX, כך שכאשר אפליקציה משתמשת ב-API של android.media.AudioRecord כדי להקליט ממקור האודיו הזה, היא מתעדת שילוב של כל מקורות האודיו, מלבד המקורות הבאים:

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4. ביטול הד אקוסטי

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

• צריך להטמיע טכנולוגיית ביטול הד אקוסטי (AEC) שמותאמת לתקשורת קולית שחלה על נתיב הצילום כשמצלמים באמצעות AudioSource.VOICE_COMMUNICATION.

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

• [C-SR-1] מומלץ מאוד להצהיר על כך באמצעות שיטת ה-API של AcousticEchoCanceler‏ AcousticEchoCanceler.isAvailable()
• [C-SR-2] מומלץ מאוד לאפשר שליטה באפקט האודיו הזה באמצעות ה-API של AcousticEchoCanceler.
• [C-SR-3] מומלץ מאוד לזהות באופן ייחודי כל הטמעה של טכנולוגיית AEC באמצעות השדה AudioEffect.Descriptor.uuid.

5.4.5. צילום בו-זמנית

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

• [C-1-1] חובה לאפשר גישה בו-זמנית למיקרופון על ידי שירות נגישות שמתבצעת בו הקלטה באמצעות AudioSource.VOICE_RECOGNITION ועל ידי אפליקציה אחת לפחות שמתבצעת בה הקלטה באמצעות כל AudioSource.
• [C-1-2] חובה לאפשר גישה בו-זמנית למיקרופון לאפליקציה מותקנת מראש עם תפקיד Assistant ולאפליקציה אחת לפחות שמצלמת באמצעות AudioSource כלשהו, מלבד AudioSource.VOICE_COMMUNICATION או AudioSource.CAMCORDER.
• [C-1-3] חובה להשתיק את הקלטת האודיו של כל אפליקציה אחרת, מלבד שירות נגישות, בזמן שאפליקציה מקליטה באמצעות AudioSource.VOICE_COMMUNICATION או AudioSource.CAMCORDER. עם זאת, אם אפליקציה מתעדת באמצעות AudioSource.VOICE_COMMUNICATION, אפליקציה אחרת יכולה לתעד את השיחה הקולית אם היא אפליקציה בעלת הרשאות (שהותקנה מראש) עם ההרשאה CAPTURE_AUDIO_OUTPUT.
• [C-1-4] אם שתי אפליקציות או יותר מתעדות בו-זמנית ואף אחת מהן לא מציגה ממשק משתמש בחלק העליון של המסך, האפליקציה שהתחילה את הצילום לאחרונה תקבל את האודיו.

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

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

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

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

• [C-1-1] חייב לאפשר הפעלה של תוכן אודיו גולמי עם המאפיינים הבאים:

  • פורמטים של מקורות: PCM לינארי, 16 ביט, 8 ביט, מספר ממשי (float)
  • ערוצים: מונו, סטריאו, הגדרות תקינות של ערוצים מרובים עם עד 8 ערוצים
  • קצבי דגימה (בהרץ):
    • 8000, ‏ 11025, ‏ 16000, ‏ 22050, ‏ 24000, ‏ 32000, ‏ 44100, ‏ 48000 בהגדרות הערוץ שמפורטות למעלה
    • 96,000 במונו ובסטריאו

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

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

אם הטמעות במכשירים מכריזות על התכונה android.hardware.audio.output, הן:

• [C-1-1] חובה לתמוך בהטמעות של EFFECT_TYPE_EQUALIZER ו-EFFECT_TYPE_LOUDNESS_ENHANCER שניתן לשלוט בהן באמצעות תתי-הסוגים של AudioEffect‏ Equalizer ו-LoudnessEnhancer.
• [C-1-2] חובה לתמוך בהטמעת API של ויזואליzer, שניתן לשלוט בו באמצעות הכיתה Visualizer.
• [C-1-3] חובה לתמוך בהטמעה של EFFECT_TYPE_DYNAMICS_PROCESSING שניתן לשלוט בה באמצעות צאצא משנה של AudioEffect‏ DynamicsProcessing.

יצירת דרישות חדשות

• [C-1-4] חובה לתמוך באפקטים קוליים עם קלט ופלט של נקודה צפה.
• [C-1-5] חובה לוודא שאפקטים קוליים תומכים במספר ערוצים, עד למספר הערוצים במיקסר שנקרא גם FCC_LIMIT.

סיום הדרישות החדשות

• צריכה לתמוך בהטמעות של EFFECT_TYPE_BASS_BOOST,‏ EFFECT_TYPE_ENV_REVERB,‏ EFFECT_TYPE_PRESET_REVERB ו-EFFECT_TYPE_VIRTUALIZER שניתן לשלוט בהן באמצעות תתי-הסוגים של AudioEffect,‏ BassBoost,‏ EnvironmentalReverb,‏ PresetReverb ו-Virtualizer.
• [C-SR-1] מומלץ מאוד לתמוך באפקטים בספרות עשרוניות ובמספר ערוצים.

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

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

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

5.5.4. העברת אודיו

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

• [C-SR-1] מומלץ מאוד לחתוך את תוכן האודיו ללא הפסקות (gapless) שמשוחק בין שני קליפים באותו פורמט, כפי שצוין על ידי AudioTrack gapless API ומיכל המדיה של MediaPlayer.

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

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

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

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

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

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

• OpenSL ES PCM buffer queue API. קבוצת ממשקי ה-API של OpenSL ES שקשורים ל-PCM ב-Android NDK.

• AAudio native audio API. קבוצת ממשקי ה-API של AAudio ב-Android NDK.

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

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

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

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

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

• [C-1-1] חותמת הזמן של הפלט שמוחזרת על ידי AudioTrack.getTimestamp ו-AAudioStream_getTimestamp מדויקת בטווח של +/- 2 אלפיות השנייה.

• [C-1-2] זמן אחזור של פלט במצב התחלה קר (cold start) של 500 אלפיות שנייה או פחות.

• [C-1-3] פתיחת פלט של מקור נתונים באמצעות AAudioStreamBuilder_openStream() חייבת להימשך פחות מ-1,000 אלפיות שנייה.

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

• [C-SR-1] זמן אחזור של פלט קר של 100 אלפיות השנייה או פחות לאורך נתיב הנתונים של הרמקול.
• [C-SR-2] זמן אחזור של הקשה לצלצול של 80 אלפיות השנייה או פחות.

• [C-SR-4] חותמת הזמן של הפלט שמוחזרת על ידי AudioTrack.getTimestamp ו-AAudioStream_getTimestamp מדויקת ל-+/- 1ms.

יצירת דרישות חדשות

• [C-SR-4] מומלץ מאוד שהזמן המשוער להעברה הלוך ושוב (RTT) המחושב על סמך חותמות הזמן של הקלט והפלט שמוחזרות על ידי AAudioStream_getTimestamp יהיה בטווח של 30 אלפיות השנייה מהזמן המשוער להעברה הלוך ושוב שנמדד עבור AAUDIO_PERFORMANCE_MODE_NONE ו-AAUDIO_PERFORMANCE_MODE_LOW_LATENCY ברמקולים, באוזניות קוויות ובאוזניות אלחוטיות.

סיום הדרישות החדשות

אם הטמעות המכשירים עומדות בדרישות שלמעלה, אחרי כיול ראשוני, כשמשתמשים ב-AAudio native audio API, זמן האחזור של הפלט הרציף וזמן האחזור של הפלט לאחר הפעלה מחדש במכשיר אחד לפחות שתומך בפלט אודיו הם:

• [C-SR-5] STRONGLY RECOMMENDED to report low-latency audio by declaring android.hardware.audio.low_latency feature flag.
• [C-SR-6] מומלץ מאוד לעמוד בדרישות לשימוש באודיו עם זמן אחזור קצר באמצעות AAudio API.
• [C-SR-7] מומלץ מאוד לוודא שבזרמים שמחזירים את הערך AAUDIO_PERFORMANCE_MODE_LOW_LATENCY מ-AAudioStream_getPerformanceMode(), הערך שמוחזר על ידי AAudioStream_getFramesPerBurst() קטן או שווה לערך שמוחזר על ידי android.media.AudioManager.getProperty(String) למפתח המאפיין AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

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

• [C-2-1] אסור לדווח על תמיכה באודיו עם זמן אחזור קצר.

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

• [C-3-1] מגבילים את השגיאה בחותמות הזמן של הקלט, כפי שהן מוחזרות על ידי AudioRecord.getTimestamp או AAudioStream_getTimestamp, ל-2 אלפיות השנייה +/-. 'שגיאה' כאן פירושה סטייה מהערך הנכון.
• [C-3-2] זמן אחזור של קלט קר של 500 אלפיות שנייה או פחות.
• [C-3-3] פתיחת מקור קלט באמצעות AAudioStreamBuilder_openStream() חייבת להימשך פחות מ-1,000 אלפיות שנייה.

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

• [C-SR-8] זמן אחזור של קלט קר של 100 אלפיות השנייה או פחות דרך נתיב הנתונים של המיקרופון.

• [C-SR-11] הגבלת השגיאה בחותמות הזמן של הקלט, כפי שהן מוחזרות על ידי AudioRecord.getTimestamp או AAudioStream_getTimestamp, ל-±1ms.

אם הטמעות של מכשירים מגדירות את android.hardware.audio.output ו-android.hardware.microphone, הן:

• [C-SR-12] מומלץ מאוד שזמן האחזור הממוצע הלוך ושוב יהיה 50 אלפיות השנייה או פחות ב-5 מדידות, עם סטייה ממוצעת אבסולוטית של פחות מ-10 אלפיות השנייה, לפחות בנתיב נתמך אחד.

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

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

לכל קודק ופורמט קונטיינר שהטמעה במכשיר נדרשת לתמוך בהם, ההטמעה במכשיר:

• [C-1-1] חובה לתמוך בקודק או בקונטיינר הזה באמצעות HTTP ו-HTTPS.

• [C-1-2] חובה לתמוך בפורמטים התואמים של קטעי המדיה, כפי שמתואר בטבלה של פורמטים של קטעי מדיה בהמשך, באמצעות טיוטת פרוטוקול HTTP Live Streaming, גרסה 7.

• [C-1-3] חובה לתמוך בפורמטים התואמים של עומסי נתונים (payload) ב-RTSP, כפי שמופיע בטבלה של RTSP בהמשך. לחריגים, ראו הערות השוליים בטבלה בקטע 5.1.

פורמטים של קטעי מדיה

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

RTSP‏ (RTP, ‏ SDP)

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

5.8. Secure Media

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

• [C-1-1] חובה להצהיר על תמיכה ב-Display.FLAG_SECURE.

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

• [C-2-1] חובה לאבטח את הקישור באמצעות מנגנון קריפטוגרפית חזק, כמו HDCP 2.x ואילך, למסכים שמחוברים באמצעות פרוטוקולים אלחוטיים כמו Miracast.

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

• [C-3-1] חובה לתמוך ב-HDCP 1.2 ואילך לכל המסכים החיצוניים שמחוברים באמצעות יציאה קווית שזמינה למשתמשים.

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

אם הטמעות של מכשירים מדווחות על תמיכה בתכונה android.software.midi באמצעות הכיתה android.content.pm.PackageManager, הן:

• [C-1-1] חובה לתמוך ב-MIDI דרך כל התעבורות בחומרה שתומכות ב-MIDI, שבהן הן מספקות קישוריות גנרית שאינה MIDI. התעבורות האלה הן:

  • מצב מארח USB, סעיף 7.7
  • MIDI over Bluetooth LE בתפקיד מרכזי, סעיף 7.4.3

• [C-1-2] חובה לתמוך בהעברת תוכנת MIDI בין אפליקציות (מכשירי MIDI וירטואליים)

• [C-1-3] חובה לכלול את libamidi.so (תמיכה מקומית ב-MIDI)

• צריכה לתמוך ב-MIDI במצב ציוד היקפי ב-USB, סעיף 7.7

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

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

• [C-1-1] חובה לדווח על תמיכה בתכונה android.hardware.audio.low_latency.
• [C-1-2] זמן האחזור של האודיו במסלול הלוך ושוב, כפי שמוגדר בקטע 5.6 זמן אחזור של אודיו, חייב להיות 25 אלפיות השנייה או פחות במסלול נתמך אחד לפחות.
• [C-1-3] חייב לכלול יציאות USB שתומכות במצב מארח USB ובמצב ציוד היקפי USB.
• [C-1-4] חובה לדווח על תמיכה בתכונה android.software.midi.
• [C-1-5] חובה לעמוד בזמני האחזור ובדרישות האודיו של USB באמצעות ה-API של אודיו מקורי של AAudio ו-AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
• [C-1-6] זמן האחזור של הפלט בסטטוס 'לא בשימוש' חייב להיות 200 אלפיות שנייה או פחות.
• [C-1-7] זמן האחזור של קלט קר חייב להיות 200 אלפיות השנייה או פחות.

• [C-1-8] זמן האחזור הממוצע של הקשה ליצירת צליל חייב להיות 80 אלפיות השנייה או פחות, ב-5 מדידות לפחות לאורך נתיב הנתונים מהרמקול למיקרופון.

• [C-SR-1] מומלץ מאוד לעמוד בזמני האחזור כפי שהם מוגדרים בקטע 5.6 זמן אחזור של אודיו, של 20 אלפיות השנייה או פחות, ב-5 מדידות עם סטייה ממוצעת אבסולוטית של פחות מ-5 אלפיות השנייה במסלול מהרמקול למיקרופון.

• [C-SR-2] מומלץ מאוד לעמוד בדרישות של Pro Audio לגבי זמן אחזור אודיו רציף הלוך ושוב, זמן אחזור קלט קר וזמן אחזור פלט קר, ודרישות האודיו ב-USB באמצעות ה-API של אודיו מקורי של AAudio לאורך הנתיב MMAP.

• [C-SR-3] מומלץ מאוד לספק רמה עקבית של ביצועי מעבד בזמן שהאודיו פעיל ועומס המעבד משתנה. צריך לבדוק את זה באמצעות האפליקציה ל-Android‏ SynthMark. ב-SynthMark נעשה שימוש בסינתיסייזר תוכנה שפועל על מסגרת אודיו מדומה למדידת ביצועי המערכת. הסבר על מדדי ההשוואה מופיע במסמכי התיעוד של SynthMark. צריך להפעיל את אפליקציית SynthMark באמצעות האפשרות 'בדיקה אוטומטית' ולקבל את התוצאות הבאות:

  • voicemark.90 >= 32 voices
  • latencymark.fixed.little <= 15 msec
  • latencymark.dynamic.little <= 50 msec

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

• צריך לצמצם את ההבדל בין השעון של האודיו לבין השעון של המעבד (CPU) CLOCK_MONOTONIC כששניהם פעילים.

• צריך לצמצם את זמן האחזור של האודיו באמצעות מתמרים במכשיר.

• צריך לצמצם את זמן האחזור של האודיו דרך אודיו דיגיטלי ב-USB.

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

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

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

• צריך להיות אפס הבדל בזמן האחזור בין הערוצים.

• צריך לצמצם את זמן האחזור הממוצע של MIDI בכל אמצעי התעבורה.

• צריך לצמצם את התנודות בזמן האחזור של MIDI במהלך עומס (Jitter) בכל אמצעי התחבורה.

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

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

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

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

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

• צריך למזער את זמן האחזור של המגע.

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

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

• [C-SR-4] מומלץ מאוד לדווח על תמיכה בתכונה android.hardware.audio.pro באמצעות הכיתה android.content.pm.PackageManager.

אם הטמעות המכשירים כוללות שקע אודיו 3.5 מ"מ עם 4 מוליכים, הן:

• [C-2-1] זמן האחזור הממוצע של אודיו במסלול הלוך ושוב, כפי שמוגדר בקטע 5.6 זמן אחזור של אודיו, חייב להיות 20 אלפיות השנייה או פחות, על פני 5 מדידות עם סטייה ממוצעת של פחות מ-5 אלפיות השנייה במסלול של שקע האודיו באמצעות Audio Loopback Dongle.

• [C-SR-5] מומלץ מאוד לציית לקטע Mobile device (jack) specifications (מפרטים של שקע למכשיר נייד) שמופיע בWired Audio Headset Specification (v1.1) (מפרט של אוזניות אודיו חוטיות, גרסה 1.1).

אם הטמעות של מכשירים משמיטים שקע אודיו עם 4 מוליכים בגודל 3.5 מ"מ וכוללות יציאות USB שתומכות במצב מארח USB, הן:

• [C-3-1] חובה להטמיע את מחלקת האודיו של USB.
• [C-3-2] זמן האחזור הממוצע של אודיו במסלול הלוך ושוב חייב להיות 25 אלפיות השנייה או פחות, על פני 5 מדידות עם סטייה ממוצעת אבסולוטית של פחות מ-5 אלפיות השנייה ביציאת מצב המארח של USB באמצעות סיווג אודיו USB. (אפשר למדוד את זה באמצעות מתאם USB-3.5mm ו-Audio Loopback Dongle, או באמצעות ממשק אודיו USB עם כבלים לחיבור בין מקורות הקלט לבין יציאות הקלט).
• [C-SR-6] מומלץ מאוד שתהיה תמיכה בו-זמנית ב-I/O עד 8 ערוצים בכל כיוון, בקצב דגימה של 96kHz ובעומק של 24 או 32 ביט, כשמשתמשים בציוד היקפי של אודיו USB שתומך גם בדרישות האלה.
• [C-SR-7] מומלץ מאוד לעמוד בקבוצת הדרישות הזו באמצעות ממשק ה-API המקורי של אודיו ב-AAudio דרך הנתיב MMAP.

אם הטמעות המכשירים כוללות יציאת HDMI, הן:

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

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

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

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

• [C-1-1] חובה לדווח על התמיכה באמצעות המאפיין android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

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

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

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

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

• [C-1-6] חובה שיחס האות לרעש (SNR) יהיה 60 dB או יותר בכל מיקרופון שמשמש להקלטה של מקור האודיו הלא מעובד. (לעומת זאת, SNR נמדד כהפרש בין 94 dB SPL לבין SPL שווה ערך של רעש עצמי, משוקל A).

• [C-1-7] המערכת חייבת לכלול עיוות הרמוני כולל (THD) של פחות מ-1% עבור 1kHz ברמת קלט של 90dB SPL בכל מיקרופון שמשמש להקלטה של מקור האודיו הלא מעובד.

• [C-1-8] אסור שתהיה עיבוד אותות אחר (למשל, בקרת רווח אוטומטית, מסנן מסוג High Pass או ביטול הדהוד) בנתיבים, מלבד מכפיל רמה כדי להביא את הרמה לטווח הרצוי. במילים אחרות:

  • [C-1-9] אם יש עיבוד אותות בארכיטקטורה מסיבה כלשהי, חובה להשבית אותו ולהוסיף לנתיב האות אפס עיכוב או זמן אחזור נוסף.
  • [C-1-10] מותר להוסיף את מכפיל הרמה למסלול, אבל אסור שהוא יביא לעיכוב או לזמן אחזור במסלול האות.

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

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

• [C-2-1] חובה להחזיר את הערך null לשיטת ה-API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) כדי לציין בצורה נכונה את חוסר התמיכה.
• [C-SR-1] עדיין מומלץ מאוד לעמוד בכמה שיותר מהדרישות של נתיב האות למקור ההקלטה הלא מעובד.

5.12. וידאו HDR

Android 13 תומך בטכנולוגיות HDR כפי שמתואר במסמך שיתפרסם בקרוב.

פורמט פיקסלים

אם מפענח וידאו מצהיר על תמיכה ב-COLOR_FormatYUVP010, אז:

• [C-1-1] חובה לתמוך בפורמט P010 לקריאה במעבד (ImageReader, ‏ MediaImage,‏ ByteBuffer). ב-Android 13, הקריטריונים של P010 הופכים להיות רגועים יותר כדי לאפשר צעד שרירותי למישורי Y ו-UV.

• [C-1-2] ה-GPU חייב להיות מסוגל לדגום את מאגר הפלט של P010 (כשהוא מוקצה לשימוש ב-GPU_SAMPLING). כך אפשר להשתמש ב-GPU ליצירת קומפוזיציות ולמיפוי גוונים בהתאמה אישית באפליקציות.

אם מפענח וידאו מצהיר על תמיכה ב-COLOR_Format32bitABGR2101010, הוא:

• [C-2-1] חובה לתמוך בפורמט RGBA_1010102 למשטח הפלט ולפורמט שניתנים לקריאה על ידי המעבד (פלט של ByteBuffer).

אם רכיב קודק של וידאו מצהיר על תמיכה ב-COLOR_FormatYUVP010, הוא:

• [C-3-1] חובה לתמוך בפורמט P010 עבור פלטפורמת הקלט וקלט שניתנים לכתיבה על ידי המעבד (ImageWriter, ‏ MediaImage, ‏ ByteBuffer).

הערה: ב-Android 13, הקריטריונים של P010 הופכים להיות פחות מחמירים כדי לאפשר צעד שרירותי לשכבות Y ו-UV. (יכול להיות שהפורמט P010 הזה עבר אופטימיזציה ויהיה שונה מהפורמט P010 של Camera2).

אם מקודד וידאו מצהיר על תמיכה ב-COLOR_Format32bitABGR2101010, הוא:

• [C-4-1] חובה לתמוך בפורמט RGBA_1010102 למשטח הקלט ולקלט שאפשר לכתוב בו ב-CPU‏ (ImageWriter, ‏ ByteBuffer). הערה: לא נדרשת המרה בין עקומות העברה שונות למקודדים.

הדרישות לצילום HDR

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

• [C-5-1] אסור להניח שהמטא-נתונים של HDR מדויקים. לדוגמה, יכול להיות שבפריים המקודד יש פיקסלים מעבר לרמת הלחות המקסימלית, או שההיסטוגרמה לא מייצגת את הפריים.

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

אם הטמעות במכשירים תומכות בצילום HDR באמצעות ממשקי ה-API של CamcorderProfile, הן:

• [C-6-1] חובה לתמוך גם בצילום HDR דרך ממשקי ה-API של Camera2.

• [C-6-2] חובה לתמוך במקודד וידאו אחד לפחות עם האצה בחומרה לכל טכנולוגיית HDR נתמכת.

• [C-6-3] חובה לתמוך (לפחות) בצילומי HLG.

• [C-6-4] חובה לתמוך בכתיבת המטא-נתונים של HDR (אם רלוונטי לטכנולוגיית ה-HDR) בקובץ הסרטון שצולם. ב-AV1, ב-HEVC וב-DolbyVision, המשמעות היא שצריך לכלול את המטא-נתונים בזרם הביטים המקודד.

• [C-6-5] חובה לתמוך ב-P010 וב-COLOR_FormatYUVP010.

• [C-6-6] חובה לתמוך במיפוי גוונים מ-HDR ל-SDR במפענח המהיר המוגדר כברירת מחדל לחומרה של הפרופיל שצולם. במילים אחרות, אם מכשיר יכול לצלם HDR10+ HEVC, מפענח HEVC שמוגדר כברירת מחדל חייב להיות מסוגל לפענח את הסטרימינג שצולם באיכות SDR.

הדרישות לעריכת HDR

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

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

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

• [C-7-1] חובה לתמוך בפרופיל HDR אחד לפחות.

• [C-7-2] חובה לתמוך ב-FEATURE_HdrEditing לכל פרופילי ה-HDR שמקודק זה מפרסם. במילים אחרות, חובה לתמוך ביצירת מטא-נתונים של HDR כשהם לא נמצאים בכל פרופילי ה-HDR הנתמכים שמשתמשים במטא-נתונים של HDR.

• [C-7-3] חובה לתמוך בפורמטים הבאים של קלט מקודד הווידאו, שמשמרים באופן מלא את האות המקודד של HDR:

  • RGBA_1010102 (כבר בקורב העברת היעד) גם ל-surface של הקלט וגם ל-ByteBuffer, וחובה לפרסם תמיכה ב-COLOR_Format32bitABGR2101010.

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

• [C-7-4] חובה לפרסם תמיכה בתוסף OpenGL‏ EXT_YUV_target.

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

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

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

• [C-0-1] חובה לתמוך בכלים של Android למפתחים שכלולים ב-Android SDK.

• ממשק הגישור של Android‏ (adb)

  • [C-0-2] חובה לתמוך ב-adb כפי שמתואר ב-Android SDK ובפקודות המעטפת שסופקו ב-AOSP, שבהן מפתחי אפליקציות יכולים להשתמש, כולל dumpsys cmd stats
  • [C-0-11] חייבת לתמוך בפקודת המעטפת cmd testharness. יכול להיות ששדרוג הטמעות במכשירים מגרסה קודמת של Android ללא בלוק נתונים מתמיד יהיה פטור מהדרישה של C-0-11.
  • [C-0-3] אסור לשנות את הפורמט או את התוכן של אירועי המערכת במכשיר (batterystats‏ , diskstats‏, fingerprint‏, graphicsstats‏, netstats‏, notification‏, procstats) שמתועדים ביומן באמצעות הפקודה dumpsys.
  • [C-0-10] חובה לתעד את האירועים הבאים, בלי להשמיט אף אחד מהם, ולאפשר גישה אליהם ולאפשר אותם לפקודת המעטפת cmd stats ולכיתה StatsManager System API.
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] הדימון של adb בצד המכשיר חייב להיות לא פעיל כברירת מחדל, וחייבת להיות מנגנון שזמין למשתמשים כדי להפעיל את Android Debug Bridge.
  • [C-0-5] חובה לתמוך ב-adb מאובטח. ב-Android יש תמיכה ב-adb מאובטח. Secure adb מאפשר להפעיל את adb במארחים מוכרים ומאומתים.
  • [C-0-6] חובה לספק מנגנון שמאפשר להתחבר ל-adb ממכונת מארח. פרטים נוספים:

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

  • [C-3-1] חובה להטמיע את adb דרך רשת מקומית (כמו Ethernet או Wi-Fi).
  • [C-3-2] חובה לספק מנהלי התקנים ל-Windows 7, ‏ 8 ו-10, שמאפשרים למפתחים להתחבר למכשיר באמצעות פרוטוקול adb.

  אם הטמעות המכשירים תומכות בחיבורי adb למכונה המארחת דרך Wi-Fi או אתרנט, הן:

  • [C-4-1] השיטה AdbManager#isAdbWifiSupported() חייבת להחזיר את הערך true.

  אם הטמעות המכשירים תומכות בחיבורי adb למכונה מארחת דרך Wi-Fi או אתרנט, וכוללות לפחות מצלמה אחת, הן:

  • [C-5-1] השיטה AdbManager#isAdbWifiQrSupported() חייבת להחזיר את הערך true.

• Dalvik Debug Monitor Service‏ (ddms)

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

• SysTrace

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

• Perfetto

  • [C-SR-1] מומלץ מאוד לחשוף למשתמש המעטפת קובץ בינארי של /system/bin/perfetto, ש-cmdline שלו עומד בדרישות של מסמכי התיעוד של perfetto.
  • [C-SR-2] מומלץ מאוד שהקובץ הבינארי של perfetto יקבל כקלט קובץ תצורה של protobuf שתואם להסכימה שמוגדרת במסמכי התיעוד של perfetto.
  • [C-SR-3] מומלץ מאוד לכתוב את הקובץ הבינארי של perfetto כמעקב protobuf כפלט, בהתאם לסכימה שמוגדרת במסמכי התיעוד של perfetto.
  • [C-SR-4] מומלץ מאוד לספק, באמצעות הקובץ הבינארי של perfetto, לפחות את מקורות הנתונים שמתוארים במסמכי התיעוד של perfetto.

• Low Memory Killer

  • [C-0-12] חובה לכתוב LMK_KILL_OCCURRED_FIELD_NUMBER Atom ביומן statsd כשאפליקציה מסתיימת על ידי Low Memory Killer.

• מצב מסגרת בדיקה אם הטמעות המכשיר תומכות בפקודת המעטפת cmd testharness ומריצות את cmd testharness enable, הן:

  • [C-2-1] חובה להחזיר את הערך true עבור ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] חובה להטמיע את מצב 'מסגרת בדיקה' כפי שמתואר במסמכי התיעוד של מצב 'מסגרת בדיקה'.

• מידע על משימות GPU

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

  • [C-0-13] חובה להטמיע את פקודת המעטפת dumpsys gpu --gpuwork כדי להציג את נתוני העבודה המצטברים של ה-GPU שמוחזרים על ידי נקודת המעקב power/gpu_work_period בליבה, או לא להציג נתונים אם נקודת המעקב לא נתמכת. ההטמעה ב-AOSP היא frameworks/native/services/gpuservice/gpuwork/.

אם הטמעות במכשירים מדווחות על תמיכה ב-Vulkan 1.0 ואילך באמצעות דגלים של תכונות android.hardware.vulkan.version, הן:

• [C-1-1] חובה לספק למפתח האפליקציה אפשרות להפעיל או להשבית שכבות לניפוי באגים ב-GPU.
• [C-1-2] כששכבות ניפוי הבאגים של ה-GPU מופעלות, חובה למנות שכבות בספריות שסופקו על ידי כלים חיצוניים (כלומר, לא חלק מהפלטפורמה או מחבילת האפליקציה) שנמצאות בספריית הבסיס של אפליקציות שניתן לנפות באגים בהן, כדי לתמוך בשיטות ה-API vkEnumerateInstanceLayerProperties()‎ ו-vkCreateInstance()‎.

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

Android כולל תמיכה למפתחים להגדרת הגדרות שקשורות לפיתוח אפליקציות.

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

• [C-0-1] חובה לפעול בהתאם לכוונה של android.settings.APPLICATION_DEVELOPMENT_SETTINGS כדי להציג הגדרות שקשורות לפיתוח אפליקציות. בהטמעה של Android במקור, תפריט האפשרויות למפתחים מוסתר כברירת מחדל, והמשתמשים יכולים להפעיל אותו אחרי שלוחצים שבע (7) פעמים על הפריט בתפריט הגדרות > מידע על המכשיר > מספר Build.
• [C-0-2] חובה להסתיר את האפשרויות למפתחים כברירת מחדל.
• [C-0-3] חובה לספק מנגנון ברור שלא נותן עדיפות לאפליקציה אחת של צד שלישי על פני אפליקציה אחרת כדי להפעיל את Developer Options. חובה לספק מסמך או אתר גלוי לכולם שמתארים איך מפעילים את אפשרויות הפיתוח. חובה שאפשר יהיה לקשר את המסמך או את אתר האינטרנט הזה למסמכים של Android SDK.
• צריכה להיות התראה חזותית מתמשכת למשתמש כשהאפשרויות למפתחים מופעלות ויש חשש לגבי בטיחות המשתמש.
• יכולים להגביל באופן זמני את הגישה לתפריט 'אפשרויות למפתחים', על ידי הסתרה חזותית או השבתה של התפריט, כדי למנוע הסחות דעת בתרחישים שבהם יש חשש לגבי בטיחות המשתמש.

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

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

• [C-0-1] ההטמעה במכשיר חייבת לכלול את ממשק ה-API הזה כפי שמתואר במסמכי התיעוד של Android SDK.

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

• [C-0-2] עדיין צריך להציג הגדרות מלאות של כיתות (כפי שמתועד ב-SDK) לממשקי ה-API של הרכיבים.
• [C-0-3] חובה להטמיע את ההתנהגויות של ה-API כ-no-ops באופן סביר כלשהו.
• [C-0-4] שיטות API חייבות להחזיר ערכים null במקרים שבהם מותר לעשות זאת במסמכי התיעוד של ה-SDK.
• [C-0-5] שיטות API חייבות להחזיר הטמעות של no-op של כיתות שבהן ערכים null לא מותרים לפי מסמכי ה-SDK.
• [C-0-6] אסור לשיטות API להוציא חריגות שלא מתועדות במסמכי התיעוד של ה-SDK.
• [C-0-7] הטמעות של מכשירים חייבות לדווח באופן עקבי על פרטי הגדרת חומרה מדויקים באמצעות השיטות getSystemAvailableFeatures() ו-hasSystemFeature(String) בכיתה android.content.pm.PackageManager לאותו טביעת אצבע של build.

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

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

מערכת Android כוללת תכונות שמתאמות באופן אוטומטי את נכסי האפליקציה ואת הפריסות של ממשק המשתמש בהתאם למכשיר, כדי להבטיח שאפליקציות של צד שלישי יפעלו בצורה תקינה במגוון תצורות חומרה ובמגוון תצוגות ותצורות חומרה. מסך תואם ל-Android הוא מסך שמטמיע את כל ההתנהגויות והממשקי ה-API שמתוארים במאמר Android Developers – Screen compatibility overview, בקטע הזה (7.1) ובקטעים המשניים שלו, וכן כל התנהגות נוספת ספציפית לסוג המכשיר שמתועדת בקטע 2 של ה-CDD הזה. במסכים התואמים ל-Android שבהם אפשר להריץ את כל האפליקציות של צד שלישי שתואמות ל-Android, חייבים להטמיע את ממשקי ה-API ואת ההתנהגויות האלה במכשירים בצורה תקינה, כפי שמפורט בקטע הזה.

יצירת דרישות חדשות

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

• [C-0-1] חובה, כברירת מחדל, ליצור עיבוד (רנדור) של אפליקציות צד שלישי רק במסכים שתואמים ל-Android.

סיום הדרישות החדשות

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

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

7.1.1. הגדרת מסך

7.1.1.1. גודל המסך וצורת המסך

מסגרת ממשק המשתמש של Android תומכת במגוון גדלים לוגיים שונים של פריסות מסך, ומאפשרת לאפליקציות לשלוח שאילתה לגבי גודל פריסת המסך של ההגדרה הנוכחית דרך Configuration.screenLayout באמצעות SCREENLAYOUT_SIZE_MASK ו-Configuration.smallestScreenWidthDp.

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

• [C-0-1] חובה לדווח על גודל הפריסה הנכון של Configuration.screenLayout כפי שמוגדר במסמכי התיעוד של Android SDK. באופן ספציפי, הטמעות של מכשירים חייבות לדווח על מידות המסך הנכונות של הפיקסלים (dp) לוגיים שאינם תלויים בדחיסות, כפי שמפורט בהמשך:

  • במכשירים שבהם הערך של Configuration.uiMode מוגדר כערך שאינו UI_MODE_TYPE_WATCH, ושהמערכת מדווחת על גודל small עבור Configuration.screenLayout, חייבת להיות רזולוציה של לפחות 426dp x 320dp.
  • במכשירים שמדווחים על גודל normal של Configuration.screenLayout, חייב להיות לפחות 480dp x 320dp.
  • במכשירים שמדווחים על גודל large של Configuration.screenLayout, חייבת להיות רזולוציה של לפחות 640dp x 480dp.
  • מכשירים שמדווחים על גודל xlarge של Configuration.screenLayout חייבים להיות בגודל של 960dp x 720dp לפחות.

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

• יכול להיות שיש להם מסכים תואמי Android עם פינות מעוגלות.

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

• [C-1-1] חובה לוודא שלכל תצוגה כזו מתקיימת לפחות אחת מהדרישות הבאות:

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

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

יצירת דרישות חדשות

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

• [C-4-1] גודל הפריסה, לא כולל חתכים בתצוגה, חייב להיות לפחות 596dp x 384dp או יותר.

סיום הדרישות החדשות

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

• [C-2-1] חובה להטמיע את הגרסה היציבה האחרונה שזמינה של extensions API או את הגרסה היציבה של sidecar API לשימוש בספרייה Window Manager Jetpack.

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

• [C-3-1] חובה לדווח לאפליקציה על המיקום, הגבולות והמצב של הציר או הקיפול באמצעות תוספים או ממשקי API נלווים.

פרטים על הטמעה נכונה של ממשקי ה-API של התוסף או הצדדים הנלווים מופיעים במסמכי העזרה הציבוריים של Window Manager Jetpack.

יצירת דרישות חדשות

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

• [C-4-1] חובה להטמיע את הגרסה הנכונה של Window Manager Extensions ברמת ה-API, כפי שמתואר במאמר WindowManager Extensions.

סיום הדרישות החדשות

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

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

• [C-0-1] בהטמעות במכשירים שבהן הערך של Configuration.uiMode מוגדר כ-UI_MODE_TYPE_NORMAL, ערך יחס הגובה-רוחב חייב להיות קטן מ-1.86 או שווה לו (כ-16:9), אלא אם האפליקציה עומדת באחד מהתנאים הבאים:

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

• [C-0-3] בהטמעות של מכשירים עם הערך Configuration.uiMode שמוגדר בתור UI_MODE_TYPE_WATCH, חובה להגדיר את הערך של יחס הגובה-רוחב כ-1.0‏ (1:1).

7.1.1.3. דחיסות מסך

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

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

• [C-0-1] כברירת מחדל, הטמעות במכשירים חייבות לדווח על רק אחת מהצפיפויות של מסגרת Android שמפורטות ב-DisplayMetrics דרך DENSITY_DEVICE_STABLE API, והערך הזה חייב להיות ערך סטטי לכל מסך פיזי. אסור לשנות את הערך הזה בשום שלב. עם זאת, עם זאת יכול להיות שהמכשיר ידווח על צפיפות שרירותית DisplayMetrics.density שונה, בהתאם לשינויים שהמשתמש ביצע בהגדרות התצוגה (לדוגמה, גודל המסך) אחרי ההפעלה הראשונית.

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

יצירת דרישות חדשות

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

סיום הדרישות החדשות

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

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

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

אם הטמעות המכשירים כוללות את המסכים התואמים ל-Android או את פלט הווידאו למסכים התואמים ל-Android, הן:

• [C-1-1] חובה לדווח על ערכים נכונים לכל מדדי התצוגה שתואמים ל-Android שמוגדרים ב-API של android.util.DisplayMetrics.

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

• [C-2-1] חובה לדווח על ערכים נכונים של המסך התואם ל-Android, כפי שהם מוגדרים ב-API של android.util.DisplayMetrics עבור view.Display ברירת המחדל המאומלל.

7.1.3. כיוון מסך

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

• [C-0-1] חובה לדווח על כיווני המסך שנתמכים (android.hardware.screen.portrait ו/או android.hardware.screen.landscape) ועל כיוון אחד לפחות שנתמך. לדוגמה, מכשיר עם מסך אופקי קבוע, כמו טלוויזיה או מחשב נייד, צריך לדווח רק על android.hardware.screen.landscape.
• [C-0-2] חובה לדווח על הערך הנכון של כיוון המכשיר הנוכחי בכל פעם שמתבצעת שאילתה דרך android.content.res.Configuration.orientation,‏ android.view.Display.getOrientation() או ממשקי API אחרים.

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

• [C-1-1] חובה לתמוך בכיוון דינמי של אפליקציות, לכיוון אנכי או לרוחב. כלומר, המכשיר חייב לפעול בהתאם לבקשת האפליקציה לכיוון מסך ספציפי.
• [C-1-2] אסור לשנות את גודל המסך או את הצפיפות שמדווחים כשמשנים את הכיוון.
• אפשר לבחור כיוון לאורך או לרוחב כברירת מחדל.

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

7.1.4.1 OpenGL ES

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

• [C-0-1] חובה לזהות בצורה נכונה את הגרסאות הנתמכות של OpenGL ES‏ (1.1,‏ 2.0,‏ 3.0,‏ 3.1,‏ 3.2) באמצעות ממשקי ה-API המנוהלים (למשל, באמצעות השיטה GLES10.getString()) וממשקי ה-API המקומיים.
• [C-0-2] חובה לכלול את התמיכה בכל ממשקי ה-API המנוהלים ובכל ממשקי ה-API הנתמכים לכל גרסאות OpenGL ES שזוהו.

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

• [C-1-1] חובה לתמוך ב-OpenGL ES 1.1 וגם ב-2.0, כפי שמתואר בפירוט במסמכי התיעוד של Android SDK.
• [C-SR-1] מומלץ מאוד לתמוך ב-OpenGL ES 3.1.
• צריך לתמוך ב-OpenGL ES 3.2.

בדיקות OpenGL ES dEQP מחולקות למספר רשימות בדיקות, לכל אחת מהן משויך תאריך או מספר גרסת. הם נמצאים בעץ המקור של Android בכתובת external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt. מכשיר שתומך ב-OpenGL ES ברמה שדווחה על ידו מציין שהוא יכול לעבור את בדיקות dEQP בכל רשימות הבדיקות מהרמה הזו ואילך.

אם הטמעות במכשירים תומכות באחת מגרסאות OpenGL ES, הן:

• [C-2-1] חובה לדווח באמצעות ממשקי ה-API המנוהלים של OpenGL ES וממשקי ה-API הנתמכים על כל התוספים האחרים של OpenGL ES שהוטמעו, ולהפך, אסור לדווח על מחרוזות של תוספים שהם לא תומכים בהם.
• [C-2-2] חובה לתמוך בתוספים EGL_KHR_image,‏ EGL_KHR_image_base,‏ EGL_ANDROID_image_native_buffer,‏ EGL_ANDROID_get_native_client_buffer,‏ EGL_KHR_wait_sync,‏ EGL_KHR_get_all_proc_addresses,‏ EGL_ANDROID_presentation_time,‏ EGL_KHR_swap_buffers_with_damage,‏ EGL_ANDROID_recordable ו-EGL_ANDROID_GLES_layers.
• [C-2-3] חובה לדווח על הגרסה המקסימלית של בדיקות dEQP של OpenGL ES שנתמכות באמצעות דגל התכונה android.software.opengles.deqp.level.
• [C-2-4] חובה לתמוך לפחות בגרסה 132383489 (החל מ-1 במרץ 2020) כפי שצוין בדגל התכונה android.software.opengles.deqp.level.
• [C-2-5] חובה לעבור את כל בדיקות dEQP של OpenGL ES ברשימות הבדיקות בין הגרסה 132383489 לבין הגרסה שצוינה בדגל התכונה android.software.opengles.deqp.level, לכל גרסה נתמכת של OpenGL ES.
• [C-SR-2] מומלץ מאוד לתמוך בתוספים EGL_KHR_partial_update ו-OES_EGL_image_external.

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

• צריך לתמוך בתוספים EGL_IMG_context_priority ו-EGL_EXT_protected_content.

אם הטמעות במכשירים מכריזות על תמיכה ב-OpenGL ES 3.0, 3.1 או 3.2, הן:

• [C-3-1] חובה לייצא את סמלי הפונקציות התואמים לגרסאות האלה, בנוסף לסמלי הפונקציות של OpenGL ES 2.0 בספרייה libGLESv2.so.
• [C-SR-3] מומלץ מאוד לתמוך בתוסף OES_EGL_image_external_essl3.

אם הטמעות במכשירים תומכות ב-OpenGL ES 3.2, הן:

• [C-4-1] חובה לתמוך בחבילת התוספים של OpenGL ES ל-Android במלואה.

אם הטמעות המכשירים תומכות ב-Android Extension Pack של OpenGL ES במלואו, הן:

• [C-5-1] חובה לציין את התמיכה באמצעות דגל התכונה android.hardware.opengles.aep.

אם הטמעות במכשירים חושפות תמיכה בתוסף EGL_KHR_mutable_render_buffer, הן:

• [C-6-1] חייבת להיות תמיכה גם בתוסף EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 Vulkan

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

אם הטמעות במכשירים תומכות ב-OpenGL ES 3.1, הן:

• [C-SR-1] מומלץ מאוד לכלול תמיכה ב-Vulkan 1.3.
• [C-4-1] אסור שתהיה תמיכה בגרסה משתנה של Vulkan (כלומר, החלק של הגרסה המשתנה של הליבה של Vulkan חייב להיות אפס).

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

• [C-SR-2] מומלץ מאוד לכלול תמיכה ב-Vulkan 1.3.

בדיקות Vulkan dEQP מחולקות למספר רשימות בדיקות, לכל אחת מהן תאריך או גרסה משויכים. הם נמצאים בעץ המקור של Android בכתובת external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt. מכשיר שתומך ב-Vulkan ברמה שדווחה על ידו מציין שהוא יכול לעבור את בדיקות dEQP בכל רשימות הבדיקות מהרמה הזו ואילך.

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

• [C-1-1] חובה לדווח על הערך השלם הנכון באמצעות דגלים של תכונות android.hardware.vulkan.level ו-android.hardware.vulkan.version.
• [C-1-2] חובה למנות לפחות VkPhysicalDevice אחד לממשק ה-API המקורי של Vulkan‏ vkEnumeratePhysicalDevices().
• [C-1-3] חובה להטמיע באופן מלא את ממשקי ה-API של Vulkan 1.0 Vulkan 1.1 לכל VkPhysicalDevice שמפורטים.
• [C-1-4] חובה למנות שכבות שמכילות ספריות מקומיות בשם libVkLayer*.so בספריית הספריות המקומיות של חבילת האפליקציה, באמצעות ממשקי ה-API המקומיים של Vulkan‏ vkEnumerateInstanceLayerProperties() ו-vkEnumerateDeviceLayerProperties().
• [C-1-5] אסור למנות שכבות שסופקו על ידי ספריות מחוץ לחבילת האפליקציה, או לספק דרכים אחרות למעקב אחרי Vulkan API או ליירט אותו, אלא אם המאפיין android:debuggable מוגדר באפליקציה כ-true או שהמטא-נתונים com.android.graphics.injectLayers.enable מוגדרים כ-true .
• [C-1-6] חובה לדווח על כל מחרוזות התוספים שבהן יש תמיכה באמצעות ממשקי ה-API המקומיים של Vulkan, ולהפך, אסור לדווח על מחרוזות תוספים שבהן אין תמיכה תקינה.
• [C-1-7] חובה לתמוך בתוספים VK_KHR_surface,‏ VK_KHR_android_surface,‏ VK_KHR_swapchain ו-VK_KHR_incremental_present.
• [C-1-8] חובה לדווח על הגרסה המקסימלית של בדיקות Vulkan dEQP שנתמכות באמצעות דגל התכונה android.software.vulkan.deqp.level.
• [C-1-9] חייב לתמוך לפחות בגרסה 132317953 (החל מ-1 במרץ 2019) כפי שצוין בדגל התכונה android.software.vulkan.deqp.level.
• [C-1-10] חובה לעבור את כל בדיקות Vulkan dEQP ברשימות הבדיקות בין הגרסה 132317953 לבין הגרסה שצוינה בדגל התכונה android.software.vulkan.deqp.level.
• [C-1-11] אסור לפרוס את התמיכה בתוספים VK_KHR_video_queue,‏ VK_KHR_video_decode_queue או VK_KHR_video_encode_queue.
• [C-SR-3] מומלץ מאוד לתמוך בתוספים VK_KHR_driver_properties ו-VK_GOOGLE_display_timing.

• צריך לתמוך ב-VkPhysicalDeviceProtectedMemoryFeatures וב-VK_EXT_global_priority.

• [C-1-12] אסור לפרוס את התמיכה בתוסף VK_KHR_performance_query.

• [C-1-13] חובה לעמוד בדרישות שצוינו בפרופיל Android Baseline 2021.

• [C-SR-4] מומלץ מאוד לעמוד בדרישות שצוינו בפרופיל Android Baseline 2022.

יצירת דרישות חדשות

• [C-SR-5] מומלץ מאוד לתמוך ב-VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory וב-VK_EXT_global_priority.

• [C-SR-6] מומלץ מאוד להשתמש ב-SkiaVk עם HWUI.

סיום הדרישות החדשות

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

• [C-2-1] אסור להצהיר על אף אחד מסימוני התכונות של Vulkan (למשל android.hardware.vulkan.level, ‏ android.hardware.vulkan.version).
• [C-2-2] אסור למנות VkPhysicalDevice כלשהו עבור ה-API המקורי של Vulkan vkEnumeratePhysicalDevices().

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

• [C-3-1] חובה להציג תמיכה בסמפור החיצוני SYNC_FD, בסוגי הטיפול ובתוסף VK_ANDROID_external_memory_android_hardware_buffer.

יצירת דרישות חדשות

• [C-SR-7] מומלץ מאוד להפוך את התוסף VK_KHR_external_fence_fd לזמין לאפליקציות של צד שלישי ולאפשר לאפליקציה לייצא מטען ייעודי (payload) של גדר ולייבא מטען ייעודי (payload) של גדרות מתיאורי קבצים של POSIX, כפי שמתואר כאן.

סיום הדרישות החדשות

7.1.4.3 RenderScript

• [C-0-1] ההטמעות במכשירים חייבות לתמוך ב-Android RenderScript, כפי שמפורט במסמכי התיעוד של Android SDK.

7.1.4.4 האצת גרפיקה 2D

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

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

• [C-0-1] חובה להפעיל את שיפור המהירות באמצעות חומרה כברירת מחדל, וחובה להשבית את שיפור המהירות באמצעות חומרה אם המפתח מבקש זאת, על ידי הגדרת android:hardwareAccelerated="false" או השבתת שיפור המהירות באמצעות חומרה ישירות דרך Android View APIs.
• [C-0-2] חובה להציג התנהגות עקבית עם המסמכים של Android SDK בנושא שיפור מהירות באמצעות חומרה.

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

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

• [C-0-3] חובה לתמוך ב-TextureView API, וחובה להציג התנהגות עקבית עם ההטמעה של Android במקור.

7.1.4.5 מסכים עם מגוון רחב של צבעים

אם הטמעות במכשירים מצהירות על תמיכה בצגים עם מגוון רחב של צבעים באמצעות Configuration.isScreenWideColorGamut() , הן:

• [C-1-1] חובה שיהיה מסך עם כיול צבע.
• [C-1-2] חובה שיהיה צג שהספקטרום שלו מכסה את ספקטרום הצבעים של sRGB במלואו במרחב CIE 1931 xyY.
• [C-1-3] חייב להיות צג ששטח המגוון שלו הוא לפחות 90% מ-DCI-P3 במרחב CIE 1931 xyY.
• [C-1-4] חובה לתמוך ב-OpenGL ES 3.1 או 3.2 ולדווח על כך בצורה תקינה.
• [C-1-5] חובה לפרסם תמיכה בתוספים EGL_KHR_no_config_context,‏ EGL_EXT_pixel_format_float,‏ EGL_KHR_gl_colorspace,‏ EGL_EXT_gl_colorspace_scrgb,‏ EGL_EXT_gl_colorspace_scrgb_linear,‏ EGL_EXT_gl_colorspace_display_p3,‏ EGL_EXT_gl_colorspace_display_p3_linear ו-EGL_EXT_gl_colorspace_display_p3_passthrough.
• [C-SR-1] מומלץ מאוד לתמוך ב-GL_EXT_sRGB.

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

• [C-2-1] צריך לכסות 100% או יותר מ-sRGB במרחב CIE 1931 xyY, למרות שסולם הצבעים של המסך לא מוגדר.

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

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

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

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

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

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

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

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

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

• [C-1-1] חובה להטמיע את השירות וה-API של המערכת DisplayManager כפי שמתואר במסמכי התיעוד של Android SDK.

7.2. התקני קלט

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

• [C-0-1] חובה לכלול מנגנון קלט, כמו מסך מגע או ניווט ללא מגע, כדי לנווט בין רכיבי ממשק המשתמש.

7.2.1. מקלדת

אם ההטמעות במכשירים כוללות תמיכה באפליקציות של צד שלישי של עורך שיטות קלט (IME), הן:

• [C-1-1] חובה להצהיר על ה-feature flag‏ android.software.input_methods.
• [C-1-2] חובה להטמיע באופן מלא את Input Management Framework
• [C-1-3] חייבת להיות מקלדת תוכנה מותקנת מראש.

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

• [C-0-1] אסור לכלול מקלדת חומרה שלא תואמת לאחד מהפורמטים שצוינו ב-android.content.res.Configuration.keyboard (QWERTY או 12 מפתחות).
• צריך לכלול הטמעות נוספות של מקלדות וירטואליות.
• יכול להיות שיכלול מקלדת חומרה.

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

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

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

• [C-0-1] חובה לדווח על הערך הנכון של android.content.res.Configuration.navigation.

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

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

7.2.3. מקשי ניווט

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

• [C-0-1] חובה לספק למשתמש אפשרות להפעיל אפליקציות מותקנות שיש להן פעילות עם <intent-filter> שמוגדר כ-ACTION=MAIN ו-CATEGORY=LAUNCHER או CATEGORY=LEANBACK_LAUNCHER להטמעות במכשירי טלוויזיה. הפונקציה 'דף הבית' אמורה להיות המנגנון של האפשרות הזו למשתמש.
• צריך לספק לחצנים לפונקציות 'פריטים אחרונים' ו'חזרה'.

אם הפונקציות 'דף הבית', 'פריטים אחרונים' או 'חזרה' זמינות, הן:

• [C-1-1] חובה שאפשר יהיה לגשת אליהם באמצעות פעולה אחת (למשל הקשה, לחיצה כפולה או מחווה) כשכל אחת מהן נגישה.
• [C-1-2] חובה לציין בבירור איזו פעולה יחידה תפעיל כל פונקציה. דוגמאות לאותות כאלה הן הדפסת סמל גלוי על הלחצן, הצגת סמל תוכנה בחלק של סרגל הניווט במסך או הדרכה של המשתמש בתהליך הדגמה מפורט ומדריך במהלך חוויית ההגדרה מחוץ לקופסה.

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

• [C-SR-1] מומלץ מאוד לא לספק את מנגנון הקלט של פונקציית התפריט, כי הוא הוצא משימוש לטובת סרגל הפעולות החל מגרסה 4.0 של Android.

• [C-SR-2] מומלץ מאוד לספק את כל פונקציות הניווט כפונקציות שניתן לבטל. 'ניתן לבטל' מוגדר כיכולת של המשתמש למנוע את הפעלת פונקציית הניווט (למשל, חזרה למסך הבית, חזרה אחורה וכו') אם הוא לא משחרר את החלקת האצבע אחרי ערך סף מסוים.

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

• [C-2-1] חובה להציג את לחצן האפשרויות הנוספות של הפעולות בכל פעם שתפריט האפשרויות הנוספות של הפעולות לא ריק וסרגל הפעולות גלוי.
• [C-2-2] אסור לשנות את המיקום של חלון הקופץ של האפשרויות הנוספות של הפעולות שמוצג כשבוחרים בלחצן האפשרויות הנוספות בסרגל הפעולות, אבל מותר להציג את חלון הקופץ של האפשרויות הנוספות של הפעולות במיקום שונה במסך כשבוחרים בפונקציית התפריט.

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

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

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

• [C-4-1] חובה להפוך את פונקציית Assist לנגישה באמצעות פעולה אחת (למשל הקשה, לחיצה כפולה או תנועה) כשמפתחות ניווט אחרים נגישים.
• [C-SR-3] מומלץ מאוד להשתמש בלחיצה ארוכה על לחצן הבית בתור האינטראקציה הייעודית הזו.

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

• [C-5-1] לחצני הניווט חייבים להשתמש בחלק נפרד מהמסך, שלא זמין לאפליקציות, אסור שהם יחסמו או יפריעו באופן אחר לחלק מהמסך שזמין לאפליקציות.
• [C-5-2] חובה להקצות חלק מהמסך לאפליקציות שעומדות בדרישות שמפורטות בסעיף 7.1.1.
• [C-5-3] חובה לכבד את הדגלים שהוגדרו על ידי האפליקציה באמצעות שיטת ה-API View.setSystemUiVisibility(), כדי שהחלק הייחודי הזה במסך (שנקרא גם סרגל הניווט) יהיה מוסתר כראוי, כפי שמתואר ב-SDK.

אם פונקציית הניווט מוצגת כפעולה מבוססת-תנועה במסך:

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() אסור להשתמש ב-WindowInsets#getMandatorySystemGestureInsets() אלא כדי לדווח על אזור זיהוי התנועות להפעלת דף הבית.
• [C-6-2] אסור ליירט תנועות שמתחילות בתוך מלבון החרגה שסופק על ידי האפליקציה שבחזית באמצעות View#setSystemGestureExclusionRects(), אבל מחוץ לWindowInsets#getMandatorySystemGestureInsets(), עבור פונקציית הניווט, כל עוד מלבון החרגה מותר בתוך מגבלת החרגה המקסימלית כפי שצוין במסמכי העזרה של View#setSystemGestureExclusionRects().
• [C-6-3] חובה לשלוח לאפליקציה שבחזית את האירוע MotionEvent.ACTION_CANCEL ברגע שהמערכת מתחילה ליירט מגע כדי לזהות תנועה, אם לאפליקציה שבחזית נשלח בעבר האירוע MotionEvent.ACTION_DOWN.
• [C-6-4] חובה לספק למשתמש אפשרות לעבור לניווט במסך שמבוסס על לחצנים (לדוגמה, בהגדרות).
• צריך לספק את תכונת 'דף הבית' באמצעות החלקה למעלה מהקצה התחתון של המסך בכיוון הנוכחי.
• צריך לספק את התכונה 'פריטים אחרונים' באמצעות החלקה למעלה והחזקה לפני שמשחררים, מאותה אזור שבו מבצעים את התנועה 'דף הבית'.
• תנועות שמתחילות ב-WindowInsets#getMandatorySystemGestureInsets() לא אמורות להיות מושפעות מריבוע החרגה שסופק על ידי האפליקציה שבחזית דרך View#setSystemGestureExclusionRects().

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

• [C-7-1] פונקציית הניווט חייבת להיות 'חזרה', והיא צריכה להתבצע באמצעות החלקה מהקצה השמאלי ומהקצה הימני של המסך במצב הנוכחי שלו.
• [C-7-2] אם יש חלוניות מערכת בהתאמה אישית שאפשר להחליק עליהן בקצוות הימניים או הימניים, הן חייבות להיות ממוקמות בשליש העליון של המסך, עם אינדיקציה חזותית ברורה ועקבית לכך שגרירה פנימה תפעיל את החלוניות שצוינו למעלה, ולא את 'הקודם'. משתמש יכול להגדיר את חלונית המערכת כך שתופיע מתחת לשליש העליון של הקצוות של המסך, אבל אסור שחלונית המערכת תשתמש ביותר מ-1/3 מהקצוות.
• [C-7-3] כשהאפליקציה שבחזית מוגדרים לה הדגלים View.SYSTEM_UI_FLAG_IMMERSIVE,‏ View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY,‏ WindowInsetsController.BEHAVIOR_DEFAULT או WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, מחיקה מהקצוות חייבת להתנהג כפי שהיא מיושמת ב-AOSP, כפי שמתואר ב-SDK.
• [C-7-4] כשהאפליקציה שבחזית מוגדרים לה הדגלים View.SYSTEM_UI_FLAG_IMMERSIVE, ‏ View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY,‏ WindowInsetsController.BEHAVIOR_DEFAULT או WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, חובה להסתיר את לוחות המערכת בהתאמה אישית שניתן להחליק עד שהמשתמש יביא אותם קדימה או יבטל את האפלה של סרחי המערכת (המכונים גם סרגל הניווט וסרגל הסטטוס), כפי שהם מוטמעים ב-AOSP.

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

• [C-8-1] חובה להפעיל את OnBackInvokedCallback.onBackCancelled().
• [C-8-2] אסור לקרוא ל-OnBackInvokedCallback.onBackInvoked().
• [C-8-3] אסור לשלוח את האירוע KEYCODE_BACK.

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

• המערכת אמורה לספק אנימציה לאפליקציה שבחזית, שמרמזת שהמשתמש חוזר אחורה, כפי שמתואר ב-AOSP.

אם הטמעות במכשירים מספקות תמיכה ב-System API‏ setNavBarMode כדי לאפשר לכל אפליקציית מערכת עם ההרשאה android.permission.STATUS_BAR להגדיר את המצב של סרגל הניווט, הן:

• [C-9-1] חובה לספק תמיכה בסמלים ידידותיים לילדים או בניווט מבוסס-לחצנים, כפי שמפורט בקוד AOSP.

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

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

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

• צריכה להיות מערכת קלט של סמן כלשהו (כמו עכבר או מגע).
• צריכה להיות תמיכה בסמנים עם מעקב עצמאי מלא.

אם הטמעות במכשירים כוללות מסך מגע (מסך מגע עם לחיצה אחת או יותר) בצג ראשי תואם ל-Android, הן:

• [C-1-1] חובה לדווח על TOUCHSCREEN_FINGER בשדה ה-API Configuration.touchscreen.
• [C-1-2] חובה לדווח על דגלי התכונות android.hardware.touchscreen ו-android.hardware.faketouch.

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

• [C-2-1] חובה לדווח על דגלי התכונות המתאימים android.hardware.touchscreen.multitouch,‏ android.hardware.touchscreen.multitouch.distinct,‏ android.hardware.touchscreen.multitouch.jazzhand, בהתאם לסוג מסך המגע הספציפי במכשיר.

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

• [C-3-1] אסור לדווח על דגל תכונה שמתחיל ב-android.hardware.touchscreen.
• [C-3-2] חובה לדווח רק על android.hardware.faketouch.
• [C-3-3] חובה לדווח על TOUCHSCREEN_NOTOUCH בשדה ה-API Configuration.touchscreen.

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

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

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

• צריך להצהיר על תמיכה ב-feature flag‏ android.hardware.faketouch.

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

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

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

• [C-2-1] חובה להצהיר על תמיכה ב-android.hardware.faketouch.
• [C-2-2] חובה לתמוך במעקב נפרד אחרי שני מקורות קלט או יותר של מצבעים עצמאיים.

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

• [C-3-1] חובה להצהיר על תמיכה ב-android.hardware.faketouch.
• [C-3-2] חובה לתמוך במעקב נפרד אחרי 5 מקורות קלט של סמן (מעקב אחרי יד עם אצבעות) או יותר, באופן עצמאי לחלוטין.

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

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

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

• [C-1-1] חייב להיות מסוגל למפות אירועי HID לקבועים התואמים של InputEvent, כפי שמפורטים בטבלאות הבאות. ההטמעה של Android במקור עומדת בדרישה הזו.

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

• [C-2-1] חובה להצהיר על דגל התכונה android.hardware.gamepad

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

1 KeyEvent

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

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

4 MotionEvent

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

אירוע MotionEvent אחד

7.2.7. שלט רחוק

הדרישות הספציפיות למכשיר מפורטות בקטע 2.3.1.

7.3. חיישנים

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

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

• [C-0-1] חובה לדווח במדויק על נוכחות או על היעדר של חיישנים בהתאם ל-class‏ android.content.pm.PackageManager.
• [C-0-2] חובה להחזיר רשימה מדויקת של חיישנים נתמכים באמצעות השיטה SensorManager.getSensorList() ושיטות דומות.
• [C-0-3] חובה לפעול באופן סביר בכל ממשקי ה-API האחרים של החיישנים (לדוגמה, על ידי החזרת הערך true או false בהתאם כשאפליקציות מנסים לרשום מאזינים, לא להפעיל מאזינים של חיישנים כשהחיישנים המתאימים לא נמצאים וכו').

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

• [C-1-1] חובה לדווח על כל מדידות החיישן באמצעות הערכים הרלוונטיים של המערכת הבינלאומית של יחידות (מטריות) לכל סוג חיישן, כפי שמוגדר במסמכי התיעוד של Android SDK.
• [C-1-2] חובה לדווח על נתוני חיישנים עם זמן אחזור מקסימלי של 100 אלפיות שנייה + 2 * sample_time במקרה של שידור חיישנים עם זמן אחזור מבוקש מקסימלי של 0 אלפיות שנייה כשמעבד האפליקציה פעיל. העיכוב הזה לא כולל עיכובים בסינון.
• [C-1-3] חובה לדווח על הדגימה הראשונה של החיישן תוך 400 אלפיות שנייה + 2 * sample_time מהפעלת החיישן. מותר לדגימה הזו להיות עם רמת דיוק של 0.
• [C-1-4] כל ממשק API שמסומן במסמכי התיעוד של Android SDK בתור חיישן רציף חייב לספק באופן קבוע דגימות נתונים תקופתיות, שצריך להיות להן רמת רעידות (jitter) נמוכה מ-3%. רעידות מוגדרות כסטיית התקן של ההבדל בין ערכי חותמות הזמן שדווחו בין אירועים רצופים.
• [C-1-5] חובה לוודא שזרם האירועים של החיישן לא ימנע ממעבד המכשיר לעבור למצב השהיה או להתעורר ממצב השהיה.
• [C-1-6] חובה לדווח על שעת האירוע בננו-שניות כפי שמוגדר במסמכי התיעוד של Android SDK, שמייצגת את השעה שבה האירוע התרחש ומתואמת עם השעון SystemClock.elapsedRealtimeNano().
• [C-SR-1] מומלץ מאוד שהשגיאה בסנכרון של חותמת הזמן תהיה פחות מ-100 אלפיות השנייה, ורצוי שהיא תהיה פחות מ-1 אלפית השנייה.
• כשמפעילים כמה חיישנים, צריכת החשמל לא אמורה לחרוג מסך צריכת החשמל שדווחה על ידי כל חיישן בנפרד.

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

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

• [C-1-6] חובה להגדיר רזולוציה שאינה אפס לכל החיישנים ולדווח על הערך באמצעות שיטת ה-API Sensor.getResolution().

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

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

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

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

• [C-2-1] חובה להטמיע את החיישן כפי שמתואר במסמכי התיעוד של Android Open Source בנושא חיישנים מורכבים.

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

• [C-3-1] חובה להגדיר את הרזולוציה ל-1 עבור החיישן ולדווח על הערך באמצעות שיטת ה-API Sensor.getResolution().

אם הטמעות במכשיר כוללות סוג חיישן מסוים שתומך ב-SensorAdditionalInfo#TYPE_VEC3_CALIBRATION והחיישן חשוף למפתחים של צד שלישי, הם:

• [C-4-1] אסור לכלול בנתונים שסופקו פרמטרים קבועים של כיול שהוגדרו במפעל.

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

• [C-SR-2] מומלץ מאוד לוודא שלמד תאוצה, לג'ירוסקופ ולמגנטומטר יש מיקום יחסי קבוע, כך שאם המכשיר ניתן לשינוי (למשל, מתקפל), צירי החיישנים יישארו מותאמים ועקביים למערכת הקואורדינטות של החיישן בכל מצבי השינוי האפשריים של המכשיר.

7.3.1. מד תאוצה

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

• [C-SR-1] מומלץ מאוד לכלול מד תאוצה ב-3 צירים.

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

• [C-1-1] חייב להיות מסוגל לדווח על אירועים בתדירות של לפחות 50Hz.
• [C-1-3] חייב להיות תואם למערכת הקואורדינטות של חיישן Android כפי שמפורט בממשקי ה-API של Android.
• [C-1-4] חייב להיות מסוגל למדוד מירידה חופשית עד פי ארבעה מכוח הכבידה(4g) או יותר בכל ציר.
• [C-1-5] חייבת להיות רזולוציה של לפחות 12 ביט.
• [C-1-6] סטיית התקן חייבת להיות לא יותר מ-0.05 m/s^, כאשר סטיית התקן צריכה להיות מחושבת על בסיס ציר לפי דגימות שנאספו במשך תקופה של לפחות 3 שניות בקצב הדגימה המהיר ביותר.
• צריך לדווח על אירועים עד 200Hz לפחות.
• צריכה להיות להם רזולוציה של 16 ביט לפחות.
• צריך לבצע כיול במהלך השימוש אם המאפיינים משתנים במהלך מחזור החיים ומבוצעת תיקון, ולשמור את פרמטרים התיקון בין הפעלות מחדש של המכשיר.
• צריך לבצע פיצוי טמפרטורה.

אם ההטמעות במכשירים כוללות מד תאוצה ב-3 צירים, הן:

• [C-2-1] חובה להטמיע חיישן TYPE_ACCELEROMETER ולדווח עליו.
• [C-SR-4] מומלץ מאוד להטמיע את החיישן המשולב TYPE_SIGNIFICANT_MOTION.
• [C-SR-5] מומלץ מאוד להטמיע ולדווח על חיישן TYPE_ACCELEROMETER_UNCALIBRATED. מומלץ מאוד שמכשירי Android יעמדו בדרישות האלה כדי שיוכלו לשדרג לגרסה העתידית של הפלטפורמה, שבה ייתכן שהדרישה הזו תהיה חובה.
• מומלץ להטמיע את החיישנים המשולבים TYPE_SIGNIFICANT_MOTION,‏ TYPE_TILT_DETECTOR,‏ TYPE_STEP_DETECTOR ו-TYPE_STEP_COUNTER כפי שמתואר במסמך Android SDK.

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

• [C-3-1] חובה להטמיע חיישן TYPE_ACCELEROMETER_LIMITED_AXES ולדווח עליו.
• [C-SR-6] מומלץ מאוד להטמיע את החיישן TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED ולדווח עליו.

אם הטמעות במכשיר כוללות תאוצה תלת-ציונית וכל אחד מהחיישנים המשולבים TYPE_SIGNIFICANT_MOTION, ‏ TYPE_TILT_DETECTOR, ‏ TYPE_STEP_DETECTOR,‏ TYPE_STEP_COUNTER מוטמע:

• [C-4-1] הסכום של צריכת האנרגיה שלהם תמיד חייב להיות פחות מ-4mW.
• כל אחת מהן צריכה להיות מתחת ל-2mW ו-0.5mW כשהמכשיר נמצא במצב דינמי או סטטי.

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

• [C-5-1] חובה להטמיע את החיישנים המשולבים TYPE_GRAVITY ו-TYPE_LINEAR_ACCELERATION.
• [C-SR-7] מומלץ מאוד להטמיע את החיישן המשולב TYPE_GAME_ROTATION_VECTOR.

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

• [C-6-1] חובה להטמיע חיישן משולב מסוג TYPE_ROTATION_VECTOR.

7.3.2. מגנטומטר

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

• [C-SR-1] מומלץ מאוד לכלול מגנטומטר (מצפן) ב-3 צירים.

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

• [C-1-1] חובה להטמיע את החיישן TYPE_MAGNETIC_FIELD.
• [C-1-2] חייב להיות מסוגל לדווח על אירועים בתדירות של לפחות 10Hz, ומומלץ לדווח על אירועים בתדירות של לפחות 50Hz.
• [C-1-3] חייב להיות תואם למערכת הקואורדינטות של חיישן Android כפי שמפורט בממשקי ה-API של Android.
• [C-1-4] חייב להיות מסוגל למדוד בין -900 µT ל-‎+900 µT בכל ציר לפני שהוא מגיע לרוויה.
• [C-1-5] הערך של ההיסט של ברזל קשה חייב להיות קטן מ-700 µT, והערך צריך להיות קטן מ-200 µT. לשם כך, צריך למקם את המגנטומטר הרחק משדות מגנטיים דינמיים (שנגרמים על ידי זרם) וסטטיים (שנגרמים על ידי מגנט).
• [C-1-6] הרזולוציה חייבת להיות שווה ל-0.6 µT או צפופה יותר.
• [C-1-7] חובה לתמוך בניפוי ובתיקון אונליין של הטיה של חומרה קשיחה, ולשמור את פרמטרי התיקון בין הפעלות מחדש של המכשיר.
• [C-1-8] חובה להחיל את הפיצוי של ברזל רך – אפשר לבצע את ההתאמה בזמן השימוש או במהלך ייצור המכשיר.
• [C-1-9] סטיית התקן, המחושבת על בסיס ציר לכל דגימה שנאספה במשך תקופה של 3 שניות לפחות בקצב הדגימה המהיר ביותר, חייבת להיות לא יותר מ-1.5 µT. מומלץ שסטיית התקן תהיה לא יותר מ-0.5 µT.
• [C-1-10] חובה להטמיע את החיישן TYPE_MAGNETIC_FIELD_UNCALIBRATED.

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

• [C-2-1] חובה להטמיע חיישן משולב מסוג TYPE_ROTATION_VECTOR.

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

• יכולים להטמיע את החיישן TYPE_GEOMAGNETIC_ROTATION_VECTOR.

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

• [C-3-1] צריך להיות צריכת אנרגיה של פחות מ-10mW.
• צריכת האנרגיה אמורה להיות פחות מ-3mW כשהחיישן רשום במצב באצ'ט ב-10Hz.

7.3.3. GPS

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

• [C-SR-1] מומלץ מאוד לכלול מקלט GPS/GNSS.

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

• [C-1-1] חובה לתמוך במיקומי פלט בקצב של לפחות 1Hz כשמבקשים דרך LocationManager#requestLocationUpdate.
• [C-1-2] חייב להיות אפשרי לקבוע את המיקום בתנאים של שדה פתוח (אותות חזקים, נתיב מרובים זניח, HDOP‏ < 2) תוך 10 שניות (זמן קצר לחישוב המיקום הראשון), כשמחוברים לחיבור אינטרנט במהירות נתונים של 0.5Mbps או יותר. בדרך כלל, הדרישה הזו מתקיימת באמצעות שימוש בשיטה כלשהי של GPS/GNSS מסייע או צפוי כדי למזער את זמן הנעילה של GPS/GNSS (נתוני העזרה כוללים את זמן העזרה, מיקום העזרה ואת השעון/האפומריס של הלוויין).
  • [C-1-6] אחרי חישוב מיקום כזה, הטמעות של מכשירים חייבות לקבוע את המיקום שלהן, בשמיים פתוחים, תוך 5 שניות, כשבקשות המיקום מופעלות מחדש, עד שעה אחרי חישוב המיקום הראשוני, גם אם הבקשה הבאה נשלחת ללא חיבור נתונים ו/או אחרי מחזור הפעלה/כיבוי.

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

  • [C-1-3] חייב להיות מסוגל לקבוע את המיקום בטווח של 20 מטר ואת המהירות בטווח של 0.5 מטר לשנייה, לפחות ב-95% מהמקרים.
  • [C-1-4] חובה לעקוב בו-זמנית אחרי לפחות 8 לוויינים מקבוצת לוויינים אחת ולדווח עליהם באמצעות GnssStatus.Callback.
  • צריך להיות אפשרי לעקוב בו-זמנית אחרי לפחות 24 לוויינים, מכמה קבוצות של לוויינים (למשל, GPS + לפחות אחד מ-Glonass,‏ Beidou,‏ Galileo).

• [C-SR-2] מומלץ מאוד להמשיך לספק פלט נתוני מיקום רגילים של GPS/GNSS דרך ממשקי ה-API של ספקי מיקום GNSS במהלך שיחת טלפון למקרה חירום.

• [C-SR-3] מומלץ מאוד לדווח על מדידות GNSS מכל קבוצות הכוכבים שבמעקב (כפי שמדווח בהודעות GnssStatus), מלבד SBAS.

• [C-SR-4] מומלץ מאוד לדווח על AGC ועל תדירות המדידה של GNSS.

• [C-SR-5] מומלץ מאוד לדווח על כל אומדני הדיוק (כולל כיוון, מהירות ונתונים אנכיים) כחלק מכל מיקום GPS/GNSS.

• [C-SR-6] מומלץ מאוד לדווח על מדידות GNSS ברגע שהן מתגלות, גם אם עדיין לא דווח על מיקום שמחושב מ-GPS/GNSS.

• [C-SR-7] מומלץ מאוד לדווח על טווחי פסאודו וקצבי פסאודו של GNSS, שבתנאי שדה פתוח אחרי שנקבע המיקום, בזמן שהמכשיר נייח או נע במהירות של פחות מ-0.2 מטר לשנייה בריבוע, מספיקים כדי לחשב מיקום בטווח של 20 מטרים ומהירות בטווח של 0.2 מטר לשנייה, לפחות ב-95% מהמקרים.

7.3.4. ג'ירוסקופ

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

• [C-SR-1] מומלץ מאוד לכלול חיישן ג'ירוסקופ.

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

• [C-1-1] חייב להיות מסוגל לדווח על אירועים בתדירות של לפחות 50Hz.
• [C-1-4] חייבת להיות רזולוציה של 12 ביט או יותר.
• [C-1-5] חייב להיות עם פיצוי טמפרטורה.
• [C-1-6] חייבים לבצע כיול ותיקון בזמן השימוש, ולשמור על פרמטרי התיקון בין הפעלות מחדש של המכשיר.
• [C-1-7] ההפרש בין הממוצעים חייב להיות קטן מ-1e-7 rad^2 / s^2 לכל הרץ (הפרש לכל הרץ, או rad^2 / s). ניתן לשנות את סטיית התקן בהתאם לשיעור הדגימה, אבל היא חייבת להיות מוגבלת בערך הזה. במילים אחרות, אם מודדים את השונות של הגירוסקופ בקצב דגימה של 1Hz, היא לא אמורה להיות גבוהה מ-1e-7 rad^2/s^2.
• [C-SR-2] מומלץ מאוד שהשגיאה בכיול תהיה פחות מ-0.01 rad/s כשהמכשיר נייח בטמפרטורת החדר.
• [C-SR-3] מומלץ מאוד להשתמש ברזולוציה של 16 ביט או יותר.
• צריך לדווח על אירועים עד 200Hz לפחות.

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

• [C-2-1] חובה להטמיע את החיישן TYPE_GYROSCOPE.
• [C-SR-4] מומלץ מאוד להטמיע את החיישן TYPE_GYROSCOPE_UNCALIBRATED.

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

• [C-3-1] חובה להטמיע חיישן TYPE_GYROSCOPE_LIMITED_AXES ולדווח עליו.
• [C-SR-5] מומלץ מאוד להטמיע את החיישן TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED ולדווח עליו.

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

• [C-4-1] חובה להטמיע חיישן משולב מסוג TYPE_ROTATION_VECTOR.

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

• [C-5-1] חובה להטמיע את החיישנים המשולבים TYPE_GRAVITY ו-TYPE_LINEAR_ACCELERATION.
• [C-SR-6] מומלץ מאוד להטמיע את החיישן המשולב TYPE_GAME_ROTATION_VECTOR.

7.3.5. ברומטר

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

• [C-SR-1] מומלץ מאוד לכלול ברומטר (חיישן לחץ אוויר סביבתי).

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

• [C-1-1] חובה להטמיע את החיישן TYPE_PRESSURE ולדווח עליו.
• [C-1-2] חובה שאפשר יהיה לשלוח אירועים בתדירות של 5Hz או יותר.
• [C-1-3] חייב להיות פיצוי טמפרטורה.
• [C-SR-2] מומלץ מאוד לדווח על מדידות לחץ בטווח של 300hPa עד 1100hPa.
• צריכה להיות דיוק מוחלט של 1hPa.
• רמת הדיוק היחסי צריכה להיות 0.12hPa בטווח של 20hPa (שווה ערך לדיוק של כ-1 מ' בשינוי של כ-200 מ' בגובה פני הים).

7.3.6. מדחום

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

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

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

• [C-2-1] אסור להגדיר את SENSOR_TYPE_AMBIENT_TEMPERATURE לחיישן הטמפרטורה.

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

• [C-SR-1] מומלץ מאוד לתמוך בממשק ה-API‏ PowerManager.getThermalHeadroom.

7.3.7. פוטומטר

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

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

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

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

• [C-1-1] חובה למדוד את הקרבה של אובייקט באותו כיוון של המסך. כלומר, חיישן הקרבה חייב להיות מכוון לזיהוי אובייקטים שנמצאים קרוב למסך, כי המטרה העיקרית של סוג החיישן הזה היא לזהות טלפון שהמשתמש משתמש בו. אם הטמעות במכשירים כוללות חיישן קרבה בכיוון אחר, אסור שאפשר יהיה לגשת אליו דרך ה-API הזה.
• [C-1-2] חייב להיות דיוק של ביט אחד או יותר.
• [C-1-3] חובה להשתמש ב-0 סנטימטרים כמדידה בטווח הקצר וב-5 סנטימטרים כמדידה בטווח הרחוק.
• [C-1-4] חובה לדווח על טווח ורזולוציה מקסימליים של 5.

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

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

• [C-1-1] חובה לזהות את היכולת באמצעות ה-feature flag‏ android.hardware.sensor.hifi_sensors.

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

• [C-2-1] חייב להיות חיישן TYPE_ACCELEROMETER ש:

  • טווח המדידה חייב להיות לפחות בין -8g ל-8g, ומומלץ מאוד שהטווח יהיה לפחות בין -16g ל-16g.
  • חייבת להיות רזולוציית מדידה של לפחות 2048 LSB/g.
  • תדר המדידה המינימלי חייב להיות 12.5Hz או פחות.
  • חייבת להיות תדירות מדידה מקסימלית של 400 הרץ ומעלה. מומלץ לתמוך ב-SensorDirectChannel‏ RATE_VERY_FAST.
  • רעש המדידה חייב להיות לא יותר מ-400 μg/√Hz.
  • חובה להטמיע את החיישן הזה בצורה ללא התעוררות עם יכולת אחסון ב-buffer של לפחות 3,000 אירועי חיישן.
  • צריכת החשמל של האצווה חייבת להיות לא יותר מ-3mW.
  • [C-SR-1] מומלץ מאוד שרוחב הפס למדידת 3dB יהיה לפחות 80% מתדירות Nyquist, וספקטרום של רעש לבן בתוך רוחב הפס הזה.
  • צריך להיות תנועה אקראית של תאוצה קטנה מ-30 μg √Hz שנבדקה בטמפרטורת החדר.
  • השינוי בסטייה לעומת הטמפרטורה צריך להיות ≤ +/- 1 mg/°C.
  • צריכה להיות לקו ההתאמה הטובה ביותר חריגה ליניאריות של ≤ 0.5%, ושינוי הרגישות לטמפרטורה של ≤ 0.03%/°C.
  • צריכה להיות רגישות ציר-לציר של פחות מ-2.5 % ותנודות ברגישות ציר-לציר של פחות מ-0.2% בטווח הטמפרטורות שבו המכשיר פועל.

• [C-2-2] חייב להיות TYPE_ACCELEROMETER_UNCALIBRATED עם אותן דרישות איכות כמו TYPE_ACCELEROMETER.

• [C-2-3] חייב להיות חיישן TYPE_GYROSCOPE ש:

  • טווח המדידה חייב להיות לפחות -1,000 עד +1,000 דפיקות לשנייה.
  • חייבת להיות רזולוציית מדידה של לפחות 16 LSB/dps.
  • תדר המדידה המינימלי חייב להיות 12.5Hz או פחות.
  • חייבת להיות תדירות מדידה מקסימלית של 400 הרץ ומעלה. מומלץ לתמוך ב-SensorDirectChannel‏ RATE_VERY_FAST.
  • רעש המדידה חייב להיות לא יותר מ-0.014°/s/√Hz.
  • [C-SR-2] מומלץ מאוד שרוחב הפס למדידת 3dB יהיה לפחות 80% מתדירות Nyquist, וספקטרום של רעש לבן בתוך רוחב הפס הזה.
  • צריך להיות תנועה אקראית של קצב קטן מ-0.001°/s √Hz שנבדקה בטמפרטורת החדר.
  • השינוי בסטייה לעומת הטמפרטורה צריך להיות ≤ +/- 0.05 °/ s / °C.
  • השינוי ברגישות כתוצאה מטמפרטורה צריך להיות ≤ 0.02% / °C.
  • יש להיות קו בעל התאמה הטובה ביותר עם סטייה לא לינארית של ≤ 0.2%.
  • צפיפות הרעש צריכה להיות ≤ 0.007 °/s/√Hz.
  • שגיאת העיבוד צריכה להיות קטנה מ-0.002 rad/s בטווח הטמפרטורות 10 עד 40 מעלות צלזיוס כשהמכשיר נייח.
  • רגישות ה-g צריכה להיות פחות מ-0.1°/s/g.
  • צריכה להיות רגישות לציר רוחבי של פחות מ-4.0 % ותנודות ברגישות לציר רוחבי של פחות מ-0.3% בטווח הטמפרטורות שבו המכשיר פועל.

• [C-2-4] חייב להיות TYPE_GYROSCOPE_UNCALIBRATED עם אותן דרישות איכות כמו TYPE_GYROSCOPE.

• [C-2-5] חייב להיות חיישן TYPE_GEOMAGNETIC_FIELD ש:

  • חייב להיות טווח מדידה של לפחות -900 עד +900 μT.
  • חייבת להיות רזולוציית מדידה של לפחות 5 LSB/uT.
  • תדר המדידה המינימלי חייב להיות 5Hz או פחות.
  • תדירות המדידה המקסימלית חייבת להיות 50 הרץ ומעלה.
  • רעש המדידה חייב להיות לא יותר מ-0.5 uT.

• [C-2-6] חייב להיות TYPE_MAGNETIC_FIELD_UNCALIBRATED עם אותן דרישות איכות כמו TYPE_GEOMAGNETIC_FIELD, ובנוסף:

  • חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון ב-buffer של לפחות 600 אירועי חיישן.
  • [C-SR-3] מומלץ מאוד להשתמש בספקטרום של רעש לבן מ-1Hz ל-10Hz לפחות כשקצב הדיווח הוא 50Hz ומעלה.

• [C-2-7] חייב להיות חיישן TYPE_PRESSURE ש:

  • טווח המדידה חייב להיות לפחות 300 עד 1,100 hPa.
  • חייבת להיות רזולוציית מדידה של לפחות 80 LSB/hPa.
  • תדר המדידה המינימלי חייב להיות 1Hz או פחות.
  • תדירות המדידה המקסימלית חייבת להיות 10 הרץ ומעלה.
  • רעש המדידה חייב להיות לא יותר מ-2 Pa/√Hz.
  • חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון ב-buffer של לפחות 300 אירועי חיישן.
  • צריכת החשמל של האצווה חייבת להיות לא יותר מ-2mW.

• [C-2-8] חייב להיות חיישן TYPE_GAME_ROTATION_VECTOR.

• [C-2-9] חייב להיות חיישן TYPE_SIGNIFICANT_MOTION ש:

  • צריכת האנרגיה חייבת להיות לא יותר מ-0.5mW כשהמכשיר נייח, ו-1.5mW כשהמכשיר בתנועה.

• [C-2-10] חייב להיות חיישן TYPE_STEP_DETECTOR ש:

  • חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון ב-buffer של לפחות 100 אירועי חיישן.
  • צריכת האנרגיה חייבת להיות לא יותר מ-0.5mW כשהמכשיר נייח, ו-1.5mW כשהמכשיר בתנועה.
  • צריכת החשמל של האצווה חייבת להיות לא יותר מ-4mW.

• [C-2-11] חייב להיות חיישן TYPE_STEP_COUNTER ש:

  • צריכת האנרגיה חייבת להיות לא יותר מ-0.5mW כשהמכשיר נייח, ו-1.5mW כשהמכשיר בתנועה.

• [C-2-12] חייב להיות חיישן TILT_DETECTOR ש:

  • צריכת האנרגיה חייבת להיות לא יותר מ-0.5mW כשהמכשיר נייח, ו-1.5mW כשהמכשיר בתנועה.

• [C-2-13] חותמת הזמן של אותו אירוע פיזי שדווח על ידי ה-Accelerometer, ה-Gyroscope וה-Magnetometer חייבת להיות בטווח של 2.5 אלפיות השנייה זו מזו. חותמת הזמן של אותו אירוע פיזי שדווח על ידי ה-Accelerometer וה-Gyroscope אמורה להיות בטווח של 0.25 אלפיות השנייה אחת מהשנייה.

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

• [C-2-15] חובה לספק דגימות לאפליקציות תוך 5 אלפיות השנייה ממועד זמינות הנתונים באפליקציה דרך אחד מהחיישנים הפיזיים שלמעלה.

• [C-2-16] צריך להיות צריכת אנרגיה של פחות מ-0.5mW כשהמכשיר נייח ו-2.0mW כשהמכשיר בתנועה, כשכל שילוב של החיישנים הבאים מופעל:

  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

• [C-2-17] יכול להיות חיישן TYPE_PROXIMITY, אבל אם הוא קיים, חייבת להיות לו יכולת מאגר נתונים זמנית (buffer) של 100 אירועי חיישן לפחות.

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

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

• [C-3-1] חובה להצהיר בצורה נכונה על תמיכה בסוגים של ערוצי דיווח ישיר ועל רמת הדיווחים הישירה באמצעות ממשקי ה-API isDirectChannelTypeSupported ו-getHighestDirectReportRateLevel.
• [C-3-2] חייבת להיות תמיכה לפחות באחד משני סוגי הערוצים הישירים של החיישן לכל החיישנים שמצהירים על תמיכה בערוץ ישיר של חיישן.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• צריך לתמוך בדיווח על אירועים דרך ערוץ ישיר של חיישן עבור חיישן ראשי (לא וריאנט של התעוררות) מהסוגים הבאים:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. חיישנים ביומטריים

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

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

• צריך לכלול חיישן ביומטרי

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

אם הטמעות במכשיר מאפשרות לחיישן ביומטרי להיות זמין לאפליקציות צד שלישי דרך android.hardware.biometrics.BiometricManager,‏ android.hardware.biometrics.BiometricPrompt ו-android.provider.Settings.ACTION_BIOMETRIC_ENROLL, הן:

• [C-4-1] חייב לעמוד בדרישות למזהה ביומטרי מסוג Class 3 או Class 2 כפי שהן מוגדרות במסמך הזה.
• [C-4-2] חובה לזהות ולכבד כל שם פרמטר שמוגדר כקבוע במחלקה Authenticators וכל שילוב שלהם. לעומת זאת, אסור להכיר או לכבד קבועים שלמים שמועברים לשיטות canAuthenticate(int) ו-setAllowedAuthenticators(int) מלבד אלה שמתועדים כקבועים ציבוריים ב-Authenticators וכל שילוב שלהם.
• [C-4-3] חובה להטמיע את הפעולה ACTION_BIOMETRIC_ENROLL במכשירים עם מידע ביומטרי מסוג Class 3 או Class 2. הפעולה הזו חייבת להציג רק את נקודות הכניסה להרשמה לזיהוי ביומטרי מסוג Class 3 או Class 2.

אם הטמעות במכשירים תומכות בביומטריה פסיבית, הן:

• [C-5-1] חובה לדרוש כברירת מחדל שלב אישור נוסף (למשל, לחיצה על לחצן).
• [C-SR-1] מומלץ מאוד להגדיר אפשרות שמאפשרת למשתמשים לשנות את ההעדפות של האפליקציה, ותמיד לדרוש שלב אישור.
• [C-SR-2] מומלץ מאוד לאבטח את פעולת האישור כך שלא ניתן יהיה לזייף אותה כתוצאה מפריצה למערכת ההפעלה או לליבה. לדוגמה, המשמעות היא שפעולת האישור שמבוססת על לחצן פיזי מנותבת דרך פין קלט/פלט (GPIO) למטרות כלליות (I/O) של רכיב מאובטח (SE) שלא ניתן להפעיל באמצעים אחרים מלבד לחיצה על לחצן פיזי.
• [C-5-2] חובה להטמיע בנוסף תהליך אימות משתמע (ללא שלב אישור) שתואם ל-setConfirmationRequired(boolean), שאפשר להגדיר באפליקציות כדי להשתמש בו בתהליכי כניסה.

אם יש במכשירים כמה חיישנים ביומטריים, הם:

יצירת דרישות חדשות

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

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

• [C-7-2] חובה לאתגר את המשתמש לאימות ראשי מומלץ (למשל: קוד אימות, דפוס, סיסמה) כדי לאפס את מונה הנעילה של נתונים ביומטריים שננעלו. יכול להיות שנתונים ביומטריים ברמה 3 יורשו לאפס את מונה החסימה של נתונים ביומטריים נעולים באותה רמה או ברמה נמוכה יותר. אסור לאפשר למידע ביומטרי ברמה 2 או ברמה 1 להשלים פעולת איפוס של נעילת אמצעי אימות ביומטרי.

סיום הדרישות החדשות

• [C-SR-3] מומלץ מאוד לדרוש אישור של רק מאפיין ביומטרי אחד לכל אימות (למשל, אם חיישני טביעות האצבע וזיהוי הפנים זמינים במכשיר, צריך לשלוח את onAuthenticationSucceeded אחרי אישור של אחד מהם).

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

• [C-6-1] חייב לעמוד בדרישות של Class 3 כפי שמוגדרות בקטע הזה בהמשך.
• [C-6-2] חובה להציג רק מידע ביומטרי מסוג Class 3 כשהאימות מחייב BIOMETRIC_STRONG, או כשהאימות מופעל באמצעות CryptoObject.

אם רוצים להתייחס לחיישן ביומטרי כסוג 1 (לשעבר נוחות) בהטמעות של המכשיר, צריך:

• [C-1-1] שיעור האישור השגוי חייב להיות קטן מ-0.002%.
• [C-1-2] חובה לציין שהמצב הזה עשוי להיות פחות מאובטח מקוד אימות, מקו ביטול נעילה או מסיסמה חזקה, ולפרט בבירור את הסיכונים שבהפעלה שלו, אם שיעורי הקבלה של התחזות וזיופים גבוהים מ-7%, כפי שנמדד לפי פרוטוקולי הבדיקה של Android Biometrics.
• [C-1-9] חובה לבקש מהמשתמש לבצע את האימות הראשי המומלץ (למשל, קוד אימות, דפוס, סיסמה) אחרי לא יותר מ-20 ניסיונות כושלים ולא פחות מ-90 שניות של זמן המתנה לאימות ביומטרי – כאשר ניסיון כוש הוא ניסיון באיכות צילום מספקת (BIOMETRIC_ACQUIRED_GOOD) שלא תואם למידע הביומטרי הרשום.
• [C-SR-4] מומלץ מאוד להקטין את המספר הכולל של ניסיונות כוזבים לאימות ביומטרי שצוין בקטע [C-1-9] אם שיעורי הקבלה של התחזות וזיופים גבוהים מ-7%, כפי שנמדד לפי פרוטוקולי הבדיקה של Android Biometrics.
• [C-1-3] חובה להגביל את מספר הניסיונות לאימות ביומטרי – ניסיון שקרי הוא ניסיון באיכות צילום מספקת (BIOMETRIC_ACQUIRED_GOOD) שלא תואם לנתונים הביומטריים הרשומים.
• [C-SR-5] מומלץ מאוד להגביל את מספר הניסיונות ל-30 שניות לפחות אחרי 5 ניסיונות כושלים לאימות ביומטרי, עד למספר המקסימלי של ניסיונות כושלים לכל [C-1-9] – כאשר ניסיון כושל הוא ניסיון באיכות צילום מספקת (BIOMETRIC_ACQUIRED_GOOD) שלא תואם לנתונים הביומטריים הרשומים.
• [C-SR-6] מומלץ מאוד להעביר את כל הלוגיקה של הגבלת הקצב ל-TEE.

• [C-1-10] חובה להשבית את האימות הביומטרי אחרי שההשהיה של האימות הראשי מופעלת בפעם הראשונה, כפי שמתואר בקטע [C-0-2] בקטע 9.11.

• [C-1-11] חובה ששיעור הקבלה של התחזות וזיופים לא יעלה על 30%, כאשר (1) שיעור הקבלה של התחזות וזיופים של כלי התקפת הצגה (PAI) ברמה A לא יעלה על 30%, ו-(2) שיעור הקבלה של התחזות וזיופים של כלי PAI ברמה B לא יעלה על 40%, כפי שנמדד לפי פרוטוקולי הבדיקה של Android Biometrics.

• [C-1-4] חובה למנוע הוספה של מידע ביומטרי חדש בלי ליצור קודם שרשרת אמון, על ידי כך שהמשתמש יאשר פרטי כניסה קיימים או יוסיף פרטי כניסה חדשים למכשיר (קוד אימות/דפוס/סיסמה) שמאובטחים על ידי TEE. ההטמעה של Android Open Source Project מספקת את המנגנון במסגרת כדי לעשות זאת.

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

• [C-1-6] חובה לכבד את הדגל הספציפי של המידע הביומטרי הזה (כלומר DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT,‏ DevicePolicymanager.KEYGUARD_DISABLE_FACE או DevicePolicymanager.KEYGUARD_DISABLE_IRIS).

• [C-1-7] חובה לאתגר את המשתמש לבצע את האימות הראשי המומלץ (למשל, קוד אימות, קו ביטול נעילה, סיסמה) פעם ב-24 שעות או פחות. הערה: במכשירים ששודרגו מגרסה 9 ואילך של Android, חובה לבקש מהמשתמש להזין את פרטי האימות הראשי המומלצים (למשל, קוד אימות, קו ביטול נעילה או סיסמה) פעם ב-72 שעות או פחות.

• [C-1-8] חובה לבקש מהמשתמש לבצע את האימות הראשי המומלץ (למשל: קוד אימות, קו ביטול נעילה, סיסמה) או אימות ביומטרי מסוג 3 (חזק) לאחר אחד מהאירועים הבאים:

  • זמן קצוב לתפוגה של 4 שעות לפעילות לא פעילה, או
  • 3 ניסיונות כושלים לביצוע אימות ביומטרי.
  • פרק הזמן של הזמן הקצוב לפעילות וספירת ניסיונות האימות שנכשלו מתאפסים אחרי אישור מוצלח של פרטי הכניסה של המכשיר. הערה: יכול להיות שמכשירים ששודרגו מגרסה 9 ואילך של Android יהיו פטורים מ-C-1-8.

• [C-SR-7] מומלץ מאוד להשתמש בלוגיקה של המסגרת שסופקו על ידי Android Open Source Project כדי לאכוף את האילוצים שצוינו ב-[C-1-7] וב-[C-1-8] במכשירים חדשים.

• [C-SR-8] מומלץ מאוד שהשיעור של דחייה שגויה יהיה קטן מ-10%, כפי שנמדד במכשיר.

• [C-SR-9] מומלץ מאוד שהזמן עד לתגובה (latency) יהיה פחות משנייה, נמדד מהרגע שבו מתבצע זיהוי הביומטרי ועד שהמסך נפתח, לכל שיטה ביומטרית רשומה.

יצירת דרישות חדשות

• [C-1-12] חובה ששיעור הקבלה של זיוף ותחזות לא יעלה על 40% לכל סוג של כלי התקפת הצגה (PAI), כפי שנמדד לפי פרוטוקולים של בדיקות ביומטריה ל-Android.

• [C-SR-13] מומלץ מאוד שהשיעור של אישור זיוף וזיופים לא יהיה גבוה מ-30% לכל סוג של כלי התקפת הצגה (PAI), כפי שנמדד לפי פרוטוקולי הבדיקה של Android Biometrics.

• [C-SR-14] מומלץ מאוד לחשוף את הסיווג הביומטרי של החיישן הביומטרי ואת הסיכונים המתאימים להפעלה שלו.

• [C-SR-17] מומלץ מאוד להטמיע את ממשקי ה-AIDL החדשים (כמו IFace.aidl ו-IFingerprint.aidl).

סיום הדרישות החדשות

אם רוצים להתייחס לחיישן ביומטרי כסוג 2 (לשעבר חלש) בהטמעות במכשירים, צריך:

• [C-2-1] חובה לעמוד בכל הדרישות של סיווג 1 שמפורטות למעלה.

• [C-2-2] חובה ששיעור הקבלה של התחזות וזיופים לא יעלה על 20%, כאשר (1) שיעור הקבלה של התחזות וזיופים של כלי התקפה מסוג 'הצגה' (PAI) ברמה A לא יעלה על 20%, ו-(2) שיעור הקבלה של התחזות וזיופים של כלי התקפה מסוג PAI ברמה B לא יעלה על 30%, כפי שנמדד לפי פרוטוקולי הבדיקה של Android Biometrics.

יצירת דרישות חדשות

• [C-SR-15] מומלץ מאוד שהשיעור של אישור זיופים ותרמיות לא יהיה גבוה מ-20% לכל סוג של כלי התקפת הצגה (PAI), כפי שנמדד לפי פרוטוקולי הבדיקה של Android Biometrics.

סיום הדרישות החדשות

• [C-2-3] חובה לבצע את ההתאמה הביומטרית בסביבת מחשוב מבודדת מחוץ למרחב המשתמש או הליבה של Android, כמו סביבת מחשוב אמינה (TEE), או בשבב עם ערוץ מאובטח לסביבת המחשוב המבודדת או במכונה וירטואלית מוגנת שעומדת בדרישות שמפורטות בקטע 9.17.
• [C-2-4] חובה להצפין את כל הנתונים המזהים ולאמת אותם באופן קריפטוגרפי, כך שלא ניתן יהיה לקבל אותם, לקרוא אותם או לשנות אותם מחוץ לסביבת הביצועים המבודדת, או להשתמש בשבב עם ערוץ מאובטח לסביבת הביצועים המבודדת, כפי שמתואר בהנחיות להטמעה באתר של Android Open Source Project, או במכונה וירטואלית מוגנת שבשליטת hypervisor שעומדת בדרישות שמפורטות בקטע 9.17.
• [C-2-5] לזיהוי ביומטרי שמבוסס על מצלמה, בזמן שמתבצע אימות או הרשמה מבוססי ביומטריה:
  • חובה להפעיל את המצלמה במצב שמונע קריאה או שינוי של הפריימים של המצלמה מחוץ לסביבת הביצועים המבודדת, או שבמכשיר יש צ'יפ עם ערוץ מאובטח לסביבת הביצועים המבודדת או מכונה וירטואלית מוגנת שבשליטת hypervisor שעומדת בדרישות שמפורטות בקטע 9.17.
  • בפתרונות עם מצלמת RGB אחת, אפשר לקרוא את הפריימים של המצלמה מחוץ לסביבת הביצועים המבודדת כדי לתמוך בפעולות כמו תצוגה מקדימה לצורך הרשמה, אבל עדיין אסור לשנות אותם.
• [C-2-6] אסור לאפשר לאפליקציות של צד שלישי להבדיל בין הרשמות ביומטריות ספציפיות.
• [C-2-7] אסור לאפשר גישה ללא הצפנה לנתונים ביומטריים מזהים או לכל נתון שמבוסס עליהם (כמו הטמעות) למעבד האפליקציות מחוץ להקשר של TEE או של המכונה הווירטואלית המוגנת שבשליטת hypervisor שעומדת בדרישות שמפורטות בסעיף 9.17. מכשירים ששודרגו מגרסה 9 ואילך של Android לא פטורים מ-C-2-7.

• [C-2-8] חייב להיות צינור עיבוד נתונים מאובטח, כך שפגיעה במערכת ההפעלה או בליבה לא תאפשר להחדיר נתונים ישירות כדי לבצע אימות כוזב של המשתמש. הערה: אם הטמעות של מכשירים כבר הושקו ב-Android בגרסה 9 ואילך, ולא ניתן לעמוד בדרישות של C-2-8 באמצעות עדכון של תוכנת המערכת, יכול להיות שהן יקבלו פטור מהדרישה.

• [C-SR-10] מומלץ מאוד לכלול זיהוי חיים בכל שיטות הזיהוי הביומטרי וזיהוי תשומת לב לזיהוי ביומטרי של פנים.

• [C-2-9] חובה להפוך את החיישן הביומטרי לזמין לאפליקציות של צד שלישי.

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

• [C-3-1] חייב לעמוד בכל הדרישות של סיווג 2 שמפורטות למעלה, מלבד [C-1-7] ו-[C-1-8].
• [C-3-2] חובה להטמיע מאגר מפתחות שמגובים בחומרה.
• [C-3-3] חובה ששיעור הקבלה של התחזות ושימוש בזיוף יהיה לא יותר מ-7%, כאשר (1) שיעור הקבלה של התחזות ושימוש בזיוף של כלי התקפה מסוג 'הצגה' (PAI) ברמה A הוא לא יותר מ-7%, ו-(2) שיעור הקבלה של התחזות ושימוש בזיוף של כלי התקפה מסוג PAI ברמה B הוא לא יותר מ-20%, כפי שנמדד לפי פרוטוקולי הבדיקה של Android Biometrics.
• [C-3-4] חובה לאתגר את המשתמש לבצע את האימות הראשי המומלץ (למשל, קוד אימות, קו ביטול נעילה, סיסמה) פעם ב-72 שעות או פחות.
• [C-3-5] חובה ליצור מחדש את מזהה המאמת לכל אמצעי אימות ביומטרי מסוג 3 שנתמכים במכשיר, אם אחד מהם נרשם מחדש.
• [C-3-6] חובה להפעיל מפתחות של מאגר מפתחות שמגובים בביומטריה לאפליקציות של צד שלישי.

יצירת דרישות חדשות

• [C-SR-16] מומלץ מאוד שהשיעור של אישור זיוף וזיופים לא יהיה גבוה מ-7% לכל סוג של כלי להתקפת הצגה (PAI), כפי שנמדד לפי פרוטוקולי הבדיקה של Android Biometrics.

סיום הדרישות החדשות

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

• [C-SR-11] מומלץ מאוד למנוע מהאזור הניתן למגע של UDFPS להפריע לניווט באמצעות 3 לחצנים (שחלק מהמשתמשים עשויים להזדקק לו למטרות נגישות).

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

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

• יכול להיות שתהיה תמיכה בחיישן תנוחה עם 6 דרגות חופש.

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

• [C-1-1] חובה להטמיע את החיישן TYPE_POSE_6DOF ולדווח עליו.
• [C-1-2] חייב להיות מדויק יותר מאשר וקטור הסיבוב בלבד.

7.3.12. חיישן זווית ציר

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

• [C-1-1] חובה להטמיע את TYPE_HINGLE_ANGLE ולדווח עליו.
• [C-1-2] חייב לתמוך לפחות בשתי קריאות בין 0 ל-360 מעלות (כולל, כלומר כולל 0 ו-360 מעלות).
• [C-1-3] חייב להחזיר חיישן התעוררות עבור getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.3.13. IEEE 802.1.15.4‏ (UWB)

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

יצירת דרישות חדשות

• [C-1-2] חובה לדווח על הדגל של תכונת החומרה android.hardware.uwb.
• [C-1-3] חובה לתמוך בכל קבוצות התצורה הבאות (שילובים מוגדרים מראש של פרמטרים של FIRA UCI) שהוגדרו בהטמעה של AOSP.
  • CONFIG_ID_1: מדידת טווח של unicast STATIC STS DS-TWR שהוגדרה על ידי FiRa, במצב מושהה, מרווח מדידת טווח של 240 אלפיות שנייה.
  • CONFIG_ID_2: מדידת מרחק STATIC STS DS-TWR מאחד למספר מכשירים שמוגדרת על ידי FiRa, במצב מושהה, מרווח מדידת מרחק של 200 אלפיות השנייה. תרחיש לדוגמה: טלפון חכם מקיים אינטראקציה עם הרבה מכשירים חכמים.
  • CONFIG_ID_3: זהה ל-CONFIG_ID_1, מלבד העובדה שלא מתבצע דיווח על נתוני זווית הגעה (AoA).
  • CONFIG_ID_4: זהה ל-CONFIG_ID_1, מלבד שהמצב האבטחה של P-STS מופעל.
  • CONFIG_ID_5: זהה ל-CONFIG_ID_2, מלבד שהמצב האבטחה של P-STS מופעל.
  • CONFIG_ID_6: זהה ל-CONFIG_ID_3, מלבד שהמצב האבטחה של P-STS מופעל.
  • CONFIG_ID_7: זהה ל-CONFIG_ID_2, מלבד מצב המפתח של הגורם המנוהל היחיד ב-P-STS שמופעל.
• [C-1-4] חובה לספק למשתמש אמצעי להפעלה או להשבתה של הרדיו ב-UWB.
• [C-1-5] חובה לאכוף שאפליקציות שמשתמשות ברדיו UWB יקבלו את ההרשאה UWB_RANGING (בקבוצת ההרשאות NEARBY_DEVICES).

כדי לוודא ש-802.1.15.4 פועל כמו שצריך, צריך לעבור את בדיקות התאימות והאישור הרלוונטיות שמוגדרות על ידי ארגוני התקנים, כולל FIRA,‏ CCC ו-CSA.

סיום הדרישות החדשות

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

7.4.1. טלפוניה

המונח 'טלפוניה', כפי שהוא מופיע בממשקי ה-API של Android ובמסמך הזה, מתייחס באופן ספציפי לחומרה שקשורה לביצוע שיחות קוליות ושליחת הודעות SMS , או ליצירת חיבור לאינטרנט בנייד באמצעות רשת סלולרית (למשל GSM,‏ CDMA,‏ LTE,‏ NR)‏ GSM או CDMA. במכשיר שתומך ב'טלפוניה' יכול להיות שיוצעו חלק משירותי השיחות, ההודעות והנתונים או כולם, בהתאם למוצר.

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

• אפשר להשתמש ב-Android במכשירים שלא כוללים חומרה של טלפוניה. כלומר, Android תואם למכשירים שאינם טלפונים.

אם הטמעות המכשירים כוללות טלפון GSM או CDMA, הן:

• [C-1-1] חובה להצהיר על ה-feature flag android.hardware.telephony ועל סמנים אחרים של תכונות משנה בהתאם לטכנולוגיה.
• [C-1-2] חובה להטמיע תמיכה מלאה ב-API של הטכנולוגיה הזו.
• צריך לאפשר את כל סוגי השירות הסלולרי הזמינים (2G,‏ 3G,‏ 4G,‏ 5G וכו') במהלך שיחות חירום (ללא קשר לסוגים של הרשתות שמוגדרים על ידי SetAllowedNetworkTypeBitmap()).

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

• [C-2-1] חובה להטמיע את ממשקי ה-API המלאים כ-no-ops.

אם הטמעות במכשירים תומכות ב-eUICC או ב-eSIM/SIM מוטמע, וכוללות מנגנון קנייני שמאפשר למפתחים של צד שלישי להשתמש בפונקציות של eSIM, הן:

• [C-3-1] חובה להצהיר על ה-feature flag‏ android.hardware.telephony.euicc.

אם הטמעות במכשירים לא מגדירות את מאפיין המערכת ro.telephony.iwlan\_operation\_mode לערך 'קודם', הן:

• [C-4-1] אסור לדווח על 'NETWORK_TYPE_IWLAN' דרך NetworkRegistrationInfo#getAccessNetworkTechnology() כשהערך של NetworkRegistrationInfo#getTransportType() הוא 'TRANSPORT_TYPE_WWAN' לאותה מופע של NetworkRegistrationInfo.

אם הטמעות המכשירים תומכות ברישום יחיד של IMS (מערכות משנה של מולטימדיה ב-IP) גם לשירותי טלפוניה מולטימדיה (MMTEL) וגם לתכונות של שירותי תקשורת מגוונים (RCS), והן צפויות לעמוד בדרישות של ספק הסלולר בנוגע לשימוש ברישום יחיד של IMS לכל תעבורת האותות של IMS, הן:

• [C-5-1] חובה להצהיר על דגל התכונה android.hardware.telephony.ims ולספק הטמעה מלאה של ImsService API גם ל-MMTEL וגם ל-RCS User Capability Exchange API.
• [C-5-2] חובה להצהיר על דגל התכונה android.hardware.telephony.ims.singlereg ולספק הטמעה מלאה של SipTransport API,‏ GbaService API,‏ אינדיקציות ייעודיות לשולח באמצעות HAL של IRadio 1.6, והקצאה באמצעות Auto Configuration Server‏ (ACS) או מנגנון הקצאה קנייני אחר באמצעות IMS Configuration API.

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

• [C-6-1] הקריאות ל-SmsManager#sendTextMessage ול-SmsManager#sendMultipartTextMessage חייבות להוביל לקריאות תואמות ל-CarrierMessagingService כדי לספק את הפונקציונליות של שליחת הודעות טקסט. SmsManager#sendMultimediaMessage ו-SmsManager#downloadMultimediaMessage חייבים להוביל לקריאות תואמות ל-CarrierMessagingService כדי לספק את הפונקציונליות של שליחת הודעות מולטימדיה.
• [C-6-2] האפליקציה שצוינה על ידי android.provider.Telephony.Sms#getDefaultSmsPackage חייבת להשתמש בממשקי ה-API של SmsManager כששולחים ומקבלים הודעות SMS ו-MMS. ההטמעה של AOSP במארזים/באפליקציות/ב-Messaging עומדת בדרישות האלה.
• [C-6-3] האפליקציה שמגיבה ל-Intent#ACTION_DIAL חייבת לתמוך בהזנת קודי חיוג שרירותיים בפורמט *#*#CODE#*#* ולהפעיל שידור TelephonyManager#ACTION_SECRET_CODE תואם.
• [C-6-4] אם האפליקציה מגיבה להודעה Intent#ACTION_DIAL, היא חייבת להשתמש ב-VoicemailContract.Voicemails#TRANSCRIPTION כדי להציג למשתמשים תמלול של דואר קולי ויזואלי, אם היא תומכת בתמלולים של דואר קולי ויזואלי.
• [C-6-5] חובה לייצג את כל SubscriptionInfo עם מזהי UUID של קבוצה זהים כמינויים יחידים בכל האפשרויות הגלויות למשתמש להצגה ולשליטה במידע של כרטיס ה-SIM. דוגמאות לאפשרויות כאלה הן ממשקי הגדרות שתואמים ל-Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS או ל-EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.
• [C-6-6] אסור להציג או לאפשר שליטה ב-SubscriptionInfo עם group UUID שאינו null וbit אופורטוניסטי בכל אמצעי גישה שגלוי למשתמשים ומאפשר הגדרה או שליטה בהגדרות של כרטיס ה-SIM.

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

• [C-7-1] חובה לבחור מינוי פעיל מייצג לgroup UUID נתון כדי להציג למשתמש בכל אמצעי העזרה שמספקים מידע על סטטוס ה-SIM. דוגמאות לאפשרויות כאלה הן סמל האות הסלולרי בסרגל הסטטוס או המשבצת של ההגדרות המהירות.
• [C-SR-1] מומלץ מאוד לבחור את המינוי שמייצג בתור המינוי הפעיל לנתונים, אלא אם המכשיר נמצא בשיחה קולית, שבמהלכה מומלץ מאוד לבחור את המינוי הפעיל לשיחות קוליות בתור המינוי שמייצג.

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

• [C-6-7] חייב להיות מסוגל לפתוח את המספר המקסימלי של ערוצים לוגיים (20 בסך הכול) לכל UICC ולהשתמש בהם בו-זמנית, בהתאם ל-ETSI TS 102 221.
• [C-6-8] אסור להחיל באופן אוטומטי או ללא אישור מפורש מהמשתמש אף אחד מהדפוסים הבאים על אפליקציות פעילות של ספקי סלולר (כפי שמצוין ב-TelephonyManager#getCarrierServicePackageName):
  • ביטול או הגבלה של הגישה לרשת
  • ביטול הרשאות
  • הגבלת הפעלת אפליקציות ברקע או בחזית מעבר לתכונות הקיימות של ניהול צריכת החשמל שכלולות ב-AOSP
  • השבתה או הסרה של האפליקציה

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

• [C-8-1] חובה להשבית באופן אוטומטי את כל המינויים הפעילים הנותרים מסוג אופורטוניסטי באותה קבוצה.

אם הטמעות במכשירים כוללות טלפון GSM אבל לא טלפון CDMA, הן:

• [C-9-1] אסור להצהיר על PackageManager#FEATURE_TELEPHONY_CDMA.
• [C-9-2] חובה להפעיל IllegalArgumentException בניסיונות להגדיר סוגי רשתות 3GPP2 במסכות הבייט של סוגי הרשתות המועדפים או המותרים.
• [C-9-3] חובה להחזיר מחרוזת ריקה מ-TelephonyManager#getMeid.

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

• [C-10-1] חובה להצהיר על ה-feature flag‏ android.hardware.telephony.euicc.mep.

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

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

• [C-1-1] חובה לכלול תמיכה בחסימת מספרים
• [C-1-2] חובה להטמיע באופן מלא את BlockedNumberContract ואת ממשק ה-API התואם, כפי שמתואר במסמכי התיעוד של ה-SDK.

• [C-1-3] חובה לחסום את כל השיחות וההודעות ממספר טלפון ב-'BlockedNumberProvider' ללא אינטראקציה עם אפליקציות. היוצא מן הכלל היחיד הוא כשהחסימת מספרים מוסרת באופן זמני, כפי שמתואר במסמכי התיעוד של ה-SDK.

• [C-1-4] חובה לכתוב לספק יומן השיחות של הפלטפורמה על שיחה חסומה, וחובה לסנן שיחות עם BLOCKED_TYPE מהתצוגה של יומן השיחות שמוגדרת כברירת מחדל באפליקציית החיוג שמותקנת מראש.

• [C-1-5] אסור לכתוב לספק הטלפוניה לגבי הודעה חסומה.

• [C-1-6] חובה להטמיע ממשק משתמש לניהול מספרים חסומים, שנפתח באמצעות הכוונה שמוחזרת על ידי השיטה TelecomManager.createManageBlockedNumbersIntent().

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

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

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

7.4.1.2. Telecom API

אם הטמעות של מכשירים מדווחות על android.hardware.telephony.calling, הן:

• [C-1-1] חובה לתמוך בממשקי ה-API של ConnectionService שמתוארים ב-SDK.
• [C-1-2] חובה להציג שיחה נכנסת חדשה ולאפשר למשתמש לקבל או לדחות את השיחה הנכנסת כשהמשתמש נמצא בשיחה פעילה שמתבצעת דרך אפליקציה של צד שלישי שלא תומכת בתכונה 'השהיה' שצוינה דרך CAPABILITY_SUPPORT_HOLD.
• [C-1-3] חייבת להיות אפליקציה שמטמיעה את InCallService.

• [C-SR-1] מומלץ מאוד להודיע למשתמש שהשיחה הנוכחית תבוטל אם יענה לשיחה נכנסת.

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

• [C-SR-2] מומלץ מאוד לטעון מראש את אפליקציית החיוג שמוגדרת כברירת מחדל, שמציגה רשומה ביומן השיחות ואת השם של אפליקציה של צד שלישי ביומן השיחות שלה, כשהאפליקציה של הצד השלישי מגדירה את המפתח הנוסף EXTRA_LOG_SELF_MANAGED_CALLS ב-PhoneAccount שלה כ-true.

• [C-SR-3] מומלץ מאוד לטפל באירועים KEYCODE_MEDIA_PLAY_PAUSE ו-KEYCODE_HEADSETHOOK של אוזניות האודיו עבור ממשקי ה-API של android.telecom באופן הבא:

  • קריאה למספר Connection.onDisconnect() כשזוהתה לחיצה קצרה על האירוע המרכזי במהלך שיחה פעילה.
  • קריאה ל-Connection.onAnswer() כשמתגלה הקשה קצרה על האירוע המרכזי במהלך שיחה נכנסת.
  • קריאה לפונקציה Connection.onReject() כשזוהתה לחיצה ממושכת על האירוע המרכזי במהלך שיחה נכנסת.
  • משנים את סטטוס ההשתקה של CallAudioState.

7.4.1.3. העברת הודעות Keepalive של NAT-T לנייד

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

• צריכה לכלול תמיכה בהעברת נתונים (offload) של keepalive לרשת הסלולרית.

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

• [C-1-1] חובה לתמוך ב-SocketKeepAlive API.
• [C-1-2] חובה לתמוך בחריץ אחד לפחות של keepalive בו-זמנית דרך רשת סלולרית.
• [C-1-3] חובה לתמוך במספר הסלוטים של keepalive הסלולריים בו-זמנית שנתמכים על ידי HAL של הרדיו הסלולרי.
• [C-SR-1] מומלץ מאוד לתמוך בלפחות שלושה משבצות של keepalive סלולרי לכל מכשיר רדיו.

אם הטמעות המכשירים לא כוללות תמיכה בהעברת עומס של keepalive הסלולר, הן:

• [C-2-1] חובה להחזיר את הערך ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11‏ (Wi-Fi)

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

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

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

• [C-1-1] חובה להטמיע את Android API התואם.
• [C-1-2] חובה לדווח על הדגל של תכונת החומרה android.hardware.wifi.
• [C-1-3] חובה להטמיע את multicast API כפי שמתואר במסמכי התיעוד של ה-SDK.
• [C-1-4] חובה לתמוך ב-DNS של קבוצת מרובים (mDNS) אסור לסנן חבילות mDNS (224.0.0.251 או ff02::fb) בכל שלב של הפעולה, כולל כשהמסך לא במצב פעיל, אלא אם דרוש ביטול או סינון של החבילות האלה כדי להישאר בטווח צריכת החשמל הנדרש בהתאם לדרישות הרגולטוריות שחלות על שוק היעד. בהטמעות של מכשירי Android Television, גם במצבי המתנה.
• [C-1-5] אסור להתייחס לקריאה ל-method של ה-API‏ WifiManager.enableNetwork() כסימן מספיק כדי להחליף את ה-Network הפעיל כרגע, שמשמש כברירת מחדל לתנועת האפליקציה ומוחזר על ידי methods של ה-API‏ ConnectivityManager כמו getActiveNetwork ו-registerDefaultNetworkCallback. במילים אחרות, הם עשויים להשבית את הגישה לאינטרנט שמספקת כל ספק רשת אחר (למשל, חבילת גלישה) רק אם הם מצליחים לאמת שרשת ה-Wi-Fi מספקת גישה לאינטרנט.
• [C-1-6] מומלץ מאוד, כשמתבצעת קריאה לשיטת ה-API‏ ConnectivityManager.reportNetworkConnectivity(), לבדוק מחדש את הגישה לאינטרנט ב-Network. אם לאחר הבדיקה מתברר שה-Network הנוכחי כבר לא מספק גישה לאינטרנט, צריך לעבור לרשת אחרת שזמינה (למשל, נתונים סלולריים) ומספקת גישה לאינטרנט.
• [C-1-7] חובה ליצור כתובת MAC אקראית של המקור ומספר רצף של מסגרות של בקשות בדיקה, פעם אחת בתחילת כל סריקה, בזמן ש-STA מנותק.
• [C-1-8] חובה להשתמש בכתובת MAC עקבית אחת (לא צריך לבחור כתובת MAC באופן אקראי באמצע הסריקה).
• [C-1-9] חובה להפעיל חזרה את מספר הרצף של בקשת הבדיקה באופן רגיל (באופן רציף) בין בקשות הבדיקה בסריקת.
• [C-1-10] חובה לבצע רנדומיזציה של מספר הרצף של בקשת הבדיקה בין בקשת הבדיקה האחרונה של הסריקה לבין בקשת הבדיקה הראשונה של הסריקה הבאה.
• [C-SR-1] מומלץ מאוד ליצור כתובת MAC אקראית של המקור שתשמש לכל התקשורת של STA לנקודת גישה (AP) במהלך ההתאמה והשימוש בה.
  • המכשיר חייב להשתמש בכתובת MAC רנדומלית שונה לכל SSID (FQDN ל-Passpoint) שהוא מתקשר איתו.
  • המכשיר חייב לספק למשתמש אפשרות לשלוט בבחירה האקראית לכל SSID (FQDN ל-Passpoint) עם אפשרויות לא אקראיות ואקראיות, וחייב להגדיר את מצב ברירת המחדל של הגדרות Wi-Fi חדשות כבחירה אקראית.
• [C-SR-2] מומלץ מאוד להשתמש ב-BSSID אקראי לכל נקודת גישה שיוצרים.
  • כתובת ה-MAC חייבת להיות אקראית וקבועה לכל SSID שבו משתמש ה-AP.
  • יכול להיות שהמכשיר יספק למשתמש אפשרות להשבית את התכונה הזו. אם האפשרות הזו קיימת, הרשאה אקראית חייבת להיות מופעלת כברירת מחדל.

אם הטמעות המכשירים כוללות תמיכה במצב חיסכון בחשמל של Wi-Fi כפי שמוגדר בתקן IEEE 802.11, הן:

• צריך להשבית את מצב חיסכון האנרגיה ב-Wi-Fi בכל פעם שאפליקציה מקבלת את המנעול WIFI_MODE_FULL_HIGH_PERF או את המנעול WIFI_MODE_FULL_LOW_LATENCY דרך ממשקי ה-API של WifiManager.createWifiLock() ו-WifiManager.WifiLock.acquire(), והנעילה פעילה.
• [C-3-2] זמן האחזור הממוצע הלוך ושוב בין המכשיר לנקודת הגישה כשהמכשיר נמצא במצב Wi-Fi Low Latency Lock‏ (WIFI_MODE_FULL_LOW_LATENCY) חייב להיות קצר יותר מזמן האחזור במצב Wi-Fi High Perf Lock‏ (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR-3] מומלץ מאוד לצמצם את זמן האחזור הלוך ושוב ב-Wi-Fi בכל פעם שמתבצע נעילה עם זמן אחזור קצר (WIFI_MODE_FULL_LOW_LATENCY) והיא נכנסת לתוקף.

אם הטמעות במכשירים תומכות ב-Wi-Fi ומשתמשות ב-Wi-Fi לסריקה של מיקום, הן:

• [C-2-1] חובה לספק למשתמש אפשרות להפעיל או להשבית את קריאת הערך באמצעות שיטת ה-API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi ישיר

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

• צריכה לכלול תמיכה ב-Wi-Fi Direct (Wi-Fi מקצה לקצה).

אם הטמעות המכשירים כוללות תמיכה ב-Wi-Fi Direct, הן:

• [C-1-1] חובה להטמיע את Android API התואם כפי שמתואר במסמכי התיעוד של ה-SDK.
• [C-1-2] חובה לדווח על תכונת החומרה android.hardware.wifi.direct.
• [C-1-3] חובה לתמוך בתפעול רגיל של Wi-Fi.
• [C-1-4] חובה לתמוך בו-זמנית בפעולות Wi-Fi ו-Wi-Fi Direct.
• [C-SR-1] מומלץ מאוד ליצור כתובת MAC אקראית של המקור לכל החיבורים החדשים שנוצרים ב-Wi-Fi Direct.

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

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

• צריכה לכלול תמיכה ב-Wi-Fi Tunneled Direct Link Setup ‏ (TDLS) כפי שמתואר במסמכי התיעוד של Android SDK.

אם הטמעות המכשירים כוללות תמיכה ב-TDLS ו-TDLS מופעל על ידי WiFiManager API, הן:

• [C-1-1] חובה להצהיר על תמיכה ב-TDLS דרך WifiManager.isTdlsSupported.
• מומלץ להשתמש ב-TDLS רק כשהדבר אפשרי ומועיל.
• צריך להיות שימוש בהיגוריית כלשהי ולא להשתמש ב-TDLS כשהביצועים שלו עשויים להיות גרועים יותר מאשר דרך נקודת הגישה ל-Wi-Fi.

7.4.2.3. Wi-Fi Aware

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

• צריכה לכלול תמיכה ב-Wi-Fi Aware.

אם הטמעות במכשירים כוללות תמיכה ב-Wi-Fi Aware ומאפשרות לחשוף את הפונקציונליות לאפליקציות של צד שלישי, הן:

• [C-1-1] חובה להטמיע את ממשקי ה-API של WifiAwareManager כפי שמתואר במסמכי התיעוד של ה-SDK.
• [C-1-2] חובה להצהיר על דגל התכונה android.hardware.wifi.aware.
• [C-1-3] חובה לתמוך בו-זמנית בפעולות Wi-Fi ובפעולות של Wi-Fi Aware.
• [C-1-4] חובה לבצע רנדומיזציה של כתובת ממשק הניהול של Wi-Fi Aware במרווחי זמן של עד 30 דקות ובכל פעם ש-Wi-Fi Aware מופעל, אלא אם מתבצעת פעולת טווח של Aware או שנתיב הנתונים של Aware פעיל (לא צפויה רנדומיזציה כל עוד נתיב הנתונים פעיל).

אם הטמעות במכשירים כוללות תמיכה ב-Wi-Fi Aware וב-Wi-Fi Location כפי שמתואר בקטע 7.4.2.5, ומאפשרות גישה לפונקציונליות הזו לאפליקציות של צד שלישי, הן:

• [C-2-1] חובה להטמיע את ממשקי ה-API לחיפוש מבוסס-מיקום: setRangingEnabled,‏ setMinDistanceMm,‏ setMaxDistanceMm ו-onServiceDiscoveredWithinRange.

7.4.2.4. Wi-Fi Passpoint

אם הטמעות המכשירים כוללות תמיכה ב-802.11‏ (Wi-Fi), הן:

• [C-1-1] חובה לכלול תמיכה ב-Wi-Fi Passpoint.
• [C-1-2] חובה להטמיע את ממשקי ה-API של WifiManager שקשורים ל-Passpoint כפי שמתואר במסמכי התיעוד של ה-SDK.
• [C-1-3] חובה לתמוך בתקן IEEE 802.11u, שקשור במיוחד לגילוי ולבחירה של רשתות, כמו שירות המודעות הגנריות (GAS) ופרוטוקול השאילתות של רשת הגישה (ANQP).
• [C-1-4] חובה להצהיר על סימון התכונה android.hardware.wifi.passpoint.
• [C-1-5] חובה לפעול בהתאם להטמעה של AOSP כדי לזהות רשתות Passpoint, להתאים אליהן ולשייך אותן.
• [C-1-6] חובה לתמוך לפחות בקבוצת המשנה הבאה של פרוטוקולים להקצאת מכשירים, כפי שהם מוגדרים ב-Wi-Fi Alliance Passpoint R2: אימות EAP-TTLS ו-SOAP-XML.
• [C-1-7] חובה לעבד את אישור שרת ה-AAA כפי שמתואר במפרט Hotspot 2.0 R3.
• [C-1-8] חובה לתמוך בשליטת המשתמש בהקצאה דרך הכלי לבחירת רשת Wi-Fi.
• [C-1-9] חובה לשמור על עקביות בהגדרות של Passpoint במהלך הפעלות מחדש.
• [C-SR-1] מומלץ מאוד לתמוך בתכונה של אישור התנאים וההגבלות.
• [C-SR-2] מומלץ מאוד לתמוך בתכונה 'פרטי המקום'.

אם יש מתג בקרה גלובלי של משתמש להשבתת Passpoint, ההטמעות:

• [C-3-1] חובה להפעיל את Passpoint כברירת מחדל.

7.4.2.5. מיקום Wi-Fi (זמן הלוך ושוב ב-Wi-Fi – RTT)

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

• צריכה לכלול תמיכה במיקום לפי Wi-Fi.

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

• [C-1-1] חובה להטמיע את ממשקי ה-API של WifiRttManager כפי שמתואר במסמכי התיעוד של ה-SDK.
• [C-1-2] חובה להצהיר על דגל התכונה android.hardware.wifi.rtt.
• [C-1-3] חובה ליצור כתובת MAC אקראית של המקור לכל רצף של הודעות RTT שמתבצע בזמן שממשק ה-Wi-Fi שבו מתבצע ה-RTT לא משויך לנקודת גישה.
• [C-1-4] חייב להיות מדויק בטווח של 2 מטרים ברוחב פס של 80MHz ב-68% העליון (כפי שמחושב באמצעות פונקציית ההתפלגות המצטברת).
• [C-SR-1] מומלץ מאוד לדווח על כך בצורה מדויקת בטווח של 1.5 מטר, ברוחב פס של 80MHz באחוזון ה-68 (כפי שמחושב באמצעות פונקציית ההתפלגות המצטברת).

7.4.2.6. העברת נתוני Wi-Fi Keepalive

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

• צריכה לכלול תמיכה בהעברת עומס של keepalive ב-Wi-Fi.

אם הטמעות במכשירים כוללות תמיכה בהעברת עומס של keepalive ב-Wi-Fi ומציגות את הפונקציונליות לאפליקציות של צד שלישי, הן:

• [C-1-1] חובה לתמוך ב-API של SocketKeepAlive.
• [C-1-2] חובה לתמוך ב-3 משבצות keepalive בו-זמנית לפחות דרך Wi-Fi

אם הטמעות המכשירים לא כוללות תמיכה בהעברת עומס של keepalive ב-Wi-Fi, הן:

• [C-2-1] חייב להחזיר את הערך ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (פרוטוקול להקצאת מכשיר)

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

• צריכה לכלול תמיכה ב-Wi-Fi Easy Connect‏ (DPP).

אם הטמעות במכשירים כוללות תמיכה ב-Wi-Fi Easy Connect ומאפשרות גישה לפונקציונליות באפליקציות של צד שלישי, הן:

• [C-1-1] השיטה WifiManager#isEasyConnectSupported() חייבת להחזיר את הערך true.

7.4.2.8. אימות אישור שרת Wi-Fi לארגון

אם אישור השרת של Wi-Fi לא מאומת או ששם הדומיין של שרת ה-Wi-Fi לא מוגדר, הטמעות המכשיר:

• [C-SR-1] מומלץ מאוד לא לספק למשתמש אפשרות להוסיף באופן ידני רשת Wi-Fi ארגונית באפליקציית ההגדרות.

7.4.2.9. סימון כרשת מהימנה בשימוש הראשון (TOFU)

אם הטמעות במכשירים תומכות ב-Trust on first usage (TOFU) ומאפשרות למשתמש להגדיר הגדרות של WPA/WPA2/WPA3-Enterprise, הן:

• [C-4-1] חובה לספק למשתמש אפשרות לבחור בשימוש ב-TOFU.

7.4.3. ‫Bluetooth

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

• צריכה להיות תמיכה בקודקי אודיו מתקדמים ובקודקי אודיו ל-Bluetooth (למשל LDAC)

אם הטמעות המכשירים תומכות ב-HFP, ב-A2DP וב-AVRCP, הן:

• צריך לתמוך ב-5 מכשירים מחוברים לפחות.

אם הטמעות במכשירים מכריזות על התכונה android.hardware.vr.high_performance, הן:

• [C-1-1] חובה לתמוך ב-Bluetooth 4.2 וב-Bluetooth LE Data Length Extension.

ב-Android יש תמיכה ב-Bluetooth וב-Bluetooth עם צריכת אנרגיה נמוכה.

אם הטמעות במכשירים כוללות תמיכה ב-Bluetooth וב-Bluetooth Low Energy, הן:

• [C-2-1] חובה להצהיר על תכונות הפלטפורמה הרלוונטיות (android.hardware.bluetooth ו-android.hardware.bluetooth_le, בהתאמה) ולהטמיע את ממשקי ה-API של הפלטפורמה.
• צריך להטמיע פרופילים רלוונטיים של Bluetooth, כמו A2DP,‏ AVRCP,‏ OBEX,‏ HFP וכו', בהתאם למכשיר.

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

• [C-3-1] חובה להצהיר על תכונת החומרה android.hardware.bluetooth_le.
• [C-3-2] חובה להפעיל את ממשקי ה-API של Bluetooth שמבוססים על GATT (פרופיל מאפיינים גנרי) כפי שמתואר במסמכי התיעוד של ה-SDK וב-android.bluetooth.
• [C-3-3] חובה לדווח על הערך הנכון של BluetoothAdapter.isOffloadedFilteringSupported() כדי לציין אם לוגיק הסינון של כיתות ה-API של ScanFilter מיושם.
• [C-3-4] חובה לדווח על הערך הנכון של BluetoothAdapter.isMultipleAdvertisementSupported() כדי לציין אם יש תמיכה בפרסום באנרגיה נמוכה.

• [C-3-5] חובה להטמיע זמן קצוב לתפוגה של כתובת פרטית שניתן לפתור (RPA) שלא יהיה ארוך מ-15 דקות, ולבצע רוטציה של הכתובת בתום הזמן הקצוב לתפוגה כדי להגן על פרטיות המשתמשים כשהמכשיר משתמש באופן פעיל ב-BLE לצורך סריקה או פרסום. כדי למנוע התקפות תזמון, גם מרווחי הזמן לתפוגה חייבים להיות אקראיים בין 5 ל-15 דקות.

• צריכה להיות תמיכה בהעברת הלוגיקה של הסינון לצ'יפסט של ה-Bluetooth כשמטמיעים את ScanFilter API.

• צריכה להיות תמיכה בהעברת סריקות באצווה לצ'יפסט של ה-Bluetooth.

• צריכה להיות תמיכה במודעות מרובות עם לפחות 4 משבצות.

אם הטמעות המכשירים תומכות ב-Bluetooth LE ומשתמשות ב-Bluetooth LE לסריקת מיקום, הן:

• [C-4-1] חובה לספק למשתמש אפשרות להפעיל או להשבית את הערך שנקרא דרך System API‏ BluetoothAdapter.isBleScanAlwaysAvailable().

אם הטמעות המכשירים כוללות תמיכה ב-Bluetooth LE ובפרופיל מכשירי שמיעה, כפי שמתואר במאמר תמיכה באודיו של מכשירי שמיעה באמצעות Bluetooth LE, הן:

• [C-5-1] חובה להחזיר את הערך true עבור BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

אם הטמעות המכשירים כוללות תמיכה ב-Bluetooth או ב-Bluetooth Low Energy, הן:

• [C-6-1] חובה להגביל את הגישה לכל מטא-נתונים של Bluetooth (כמו תוצאות סריקות) שאפשר להשתמש בהם כדי להסיק את המיקום של המכשיר, אלא אם האפליקציה המבקשת עוברת בהצלחה בדיקת הרשאות android.permission.ACCESS_FINE_LOCATION על סמך המצב הנוכחי שלה בחזית או ברקע.

אם הטמעות במכשירים כוללות תמיכה ב-Bluetooth או ב-Bluetooth Low Energy, והמניפסט של האפליקציה לא כולל הצהרה מהמפתח/ת על כך שהם לא מפיקים מיקום באמצעות Bluetooth, הם:

• [C-6-2] חובה לפקח על הגישה ל-Bluetooth מאחורי android.permission.ACCESS_FINE_LOCATION.

אם הטמעות במכשירים מחזירות את הערך true עבור ה-API BluetoothAdapter.isLeAudioSupported(), הן:

• [C-7-1] חובה לתמוך בלקוח של שידור unicast.
• [C-7-2] חובה לתמוך ב-PHY של 2M.
• [C-7-3] חובה לתמוך בפרסום מורחב של LE.
• [C-7-4] חובה לתמוך לפחות בשני חיבורי CIS ב-CIG.
• [C-7-5] חובה להפעיל בו-זמנית את לקוח ה-unicast של BAP, את רכז הקבוצות של CSIP, את שרת ה-MCP, את הבקר של VCP ואת שרת ה-CCP.
• [C-SR-1] מומלץ מאוד להפעיל לקוח unicast של HAP.

אם הטמעות במכשירים מחזירות את הערך true עבור ה-API BluetoothAdapter.isLeAudioBroadcastSourceSupported(), הן:

• [C-8-1] חובה לתמוך לפחות בשני קישורי BIS ב-BIG.
• [C-8-2] חובה להפעיל בו-זמנית את מקור השידור של BAP ואת הכלי לעזרה בשידור של BAP.
• [C-8-3] חובה לתמוך בפרסום תקופתי של LE.

אם הטמעות במכשירים מחזירות את הערך true עבור ה-API BluetoothAdapter.isLeAudioBroadcastAssistantSupported(), הן:

• [C-9-1] חובה לתמוך ב-PAST (Periodic Advertising Sync Transfer).
• [C-9-2] חובה לתמוך בפרסום תקופתי של LE.

אם הטמעות של מכשירים מכריזות על FEATURE_BLUETOOTH_LE, הן:

• [C-10-1] מדידות ה-RSSI חייבות להיות בטווח של +/-9dB ב-95% מהמדידות במרחק של מטר אחד ממכשיר ייחוס שמעביר בתדר ADVERTISE_TX_POWER_HIGH בסביבה עם קו ראייה ישיר.

• [C-10-2] חובה לכלול תיקוני Rx/Tx כדי לצמצם את הסטיות בכל ערוץ, כך שהמדידות בכל אחד מ-3 הערוצים, בכל אחת מהאנטנות (אם נעשה שימוש בכמה אנטנות), יהיו בטווח של +/-3dB זו מזו ב-95% מהמדידות.

• [C-SR-2] מומלץ מאוד למדוד את ההיסט של Rx ולבצע תיקון שלו כדי לוודא שהערך החציוני של RSSI ב-BLE הוא -60dBm +/-10 dB במרחק של 1 מ' ממכשיר העזרה שמשדר ב-ADVERTISE_TX_POWER_HIGH, כאשר המכשירים מכוונים כך שהם נמצאים ב'מישורים מקבילים' והמסכים פונים לאותו כיוון.

• [C-SR-3] מומלץ מאוד למדוד את ההיסט של ה-Tx ולבצע תיקון שלו כדי לוודא שה-RSSI הממוצע של ה-BLE הוא -60dBm +/-10 dB בזמן הסריקה ממכשיר עזר שנמצא במרחק 1 מ' ומעביר ב-ADVERTISE_TX_POWER_HIGH, כאשר המכשירים מכוונים כך שהם נמצאים ב'מישורים מקבילים' והמסכים פונים לאותו כיוון.

  העברנו את הדרישות [C-10-3] ו-[C-10-4] לקטע 2.2.1. חומרה.

• [C-10-3] חובה למדוד את ההיסט של Rx ולבצע תיקון כדי לוודא שהערך החציוני של RSSI ב-BLE הוא -55dBm +/-10 dB במרחק של 1 מ' ממכשיר עזר שמשדר ב-ADVERTISE_TX_POWER_HIGH.
• [C-10-4] חובה למדוד את ההיסט של ה-Tx ולבצע התאמה כדי לוודא שה-RSSI הממוצע של ה-BLE הוא -55dBm +/-10 dB במהלך הסריקה ממכשיר עזר שנמצא במרחק 1 מ' ומשדר ב-ADVERTISE_TX_POWER_HIGH.

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

אם הטמעות המכשירים תומכות ב-Bluetooth בגרסה 5.0, הן:

• [C-SR-4] מומלץ מאוד לספק תמיכה בנושאים הבאים:
  • LE 2M PHY
  • LE Codec PHY
  • תוסף פרסום של LE
  • פרסום תקופתי
  • לפחות 10 קבוצות של מודעות
  • לפחות 8 חיבורים בו-זמניים ל-LE. כל חיבור יכול להיות באחד משני התפקידים של טופולוגיית החיבור.
  • פרטיות בשכבת הקישור של LE
  • רשימת 'פתרון' בגודל של לפחות 8 רשומות

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

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

• צריך לכלול משדר-מקלט וחומרה קשורה לתקשורת מטווח קצר (NFC).
• [C-0-1] חובה להטמיע את ממשקי ה-API android.nfc.NdefMessage ו-android.nfc.NdefRecord גם אם הם לא כוללים תמיכה ב-NFC, או להצהיר על התכונה android.hardware.nfc כי הכיתות מייצגות פורמט של ייצוג נתונים שלא תלוי בפרוטוקול.

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

• [C-1-1] חובה לדווח על התכונה android.hardware.nfc מה-method‏ android.content.pm.PackageManager.hasSystemFeature().
• חייבת להיות לו אפשרות לקרוא ולכתוב הודעות NDEF באמצעות תקני ה-NFC הבאים, כפי שמפורט בהמשך:
• [C-1-2] חייב להיות מסוגל לפעול כקורא/כותב של NFC Forum (כפי שמוגדר במפרט הטכני של NFC Forum,‏ NFCForum-TS-DigitalProtocol-1.0) באמצעות תקני ה-NFC הבאים:
  • NfcA‏ (ISO14443-3A)
  • NfcB‏ (ISO14443-3B)
  • NfcF‏ (JIS X 6319-4)
  • IsoDep‏ (ISO 14443-4)
  • סוגי תגים של NFC Forum‏ 1, 2, 3, 4, 5 (מוגדרים על ידי NFC Forum)

• [C-SR-1] מומלץ מאוד שיהיו יכולות לקרוא ולכתוב הודעות NDEF וגם נתונים גולמיים באמצעות תקני ה-NFC הבאים. חשוב לזכור שתקני ה-NFC מוגדרים כ'מומלצים מאוד', אבל בהגדרת התאימות של גרסה עתידית הם צפויים להשתנות ל'חובה'. התקנים האלה הם אופציונליים בגרסה הזו, אבל יהיו נדרשים בגרסאות עתידיות. מומלץ מאוד למכשירים קיימים וחדשים עם גרסת Android הזו לעמוד בדרישות האלה כבר עכשיו, כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה.

• [C-1-13] חובה לבצע סקירה של כל הטכנולוגיות הנתמכות במצב חיפוש של NFC.

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

• אמורה להיות מסוגלת לקרוא את הברקוד ואת כתובת ה-URL (אם היא מקודדת) של מוצרים עם ברקוד NFC דק.

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

מערכת Android כוללת תמיכה במצב NFC Host Card Emulation ‏ (HCE).

אם הטמעות המכשיר כוללות שבב של בקר NFC שיכול לבצע HCE (ל-NfcA ו/או ל-NfcB) ותומך ניתוב של מזהה אפליקציה (AID), הן:

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

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

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

אם הטמעות המכשיר כוללות תמיכה כללית ב-NFC כפי שמתואר בקטע הזה, ותמיכה בטכנולוגיות MIFARE‏ (MIFARE Classic,‏ MIFARE Ultralight,‏ NDEF ב-MIFARE Classic) בתפקיד הקורא/הסופר, הן:

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

7.4.5. פרוטוקולים וממשקי API של רשתות

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

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

• [C-0-1] חובה לכלול תמיכה באחת או יותר מהצורות של רשתות נתונים. באופן ספציפי, הטמעות במכשירים חייבות לכלול תמיכה לפחות בתקן נתונים אחד שיכול להגיע לקצב של 200Kbit/sec או יותר. דוגמאות לטכנולוגיות שעומדות בדרישות האלה כוללות את EDGE, ‏ HSPA, ‏ EV-DO,‏ 802.11g, ‏ Ethernet ו-Bluetooth PAN.
• צריכה לכלול גם תמיכה בתקן אחד לפחות של נתונים אלחוטיים נפוצים, כמו 802.11‏ (Wi-Fi), כשתקן הרשתות הפיזי (כמו Ethernet) הוא חיבור הנתונים הראשי.
• יכולים להטמיע יותר מסוג אחד של קישוריות נתונים.

7.4.5.2. IPv6

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

• [C-0-2] חובה לכלול סטאק של רשתות IPv6 ולתמוך בתקשורת IPv6 באמצעות ממשקי ה-API המנוהלים, כמו java.net.Socket ו-java.net.URLConnection, וגם באמצעות ממשקי ה-API המקומיים, כמו שקעים של AF_INET6.
• [C-0-3] חובה להפעיל את IPv6 כברירת מחדל.
  • חובה לוודא שתקשורת IPv6 אמינה כמו IPv4, לדוגמה:
    • [C-0-4] חובה לשמור על קישוריות IPv6 במצב שינה.
    • [C-0-5] הגבלת הקצב לא מורשית לגרום לאובדן הקישוריות של המכשיר ל-IPv6 בכל רשת שתואמת ל-IPv6 ומשתמשת בטווח חיים של RA של לפחות 180 שניות.
• [C-0-6] חובה לספק לאפליקציות של צד שלישי קישוריות IPv6 ישירה לרשת כשהן מחוברות לרשת IPv6, ללא כל סוג של תרגום כתובות או יציאות שמתרחש באופן מקומי במכשיר. גם ממשקי API מנוהלים כמו Socket#getLocalAddress או Socket#getLocalPort וגם ממשקי API של NDK כמו getsockname() או IPV6_PKTINFO חייבים להחזיר את כתובת ה-IP והיציאה שבהן נעשה שימוש בפועל לשליחה ולקבלה של חבילות ברשת, וגלויות ככתובת ה-IP והיציאה של המקור בשרתי אינטרנט (אינטרנט).

רמת התמיכה הנדרשת ב-IPv6 תלויה בסוג הרשת, כפי שמפורט בדרישות הבאות.

אם הטמעות המכשירים תומכות ב-Wi-Fi, הן:

• [C-1-1] חובה לתמוך ב-dual-stack ובפעולה ב-IPv6 בלבד ב-Wi-Fi.

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

• [C-2-1] חובה לתמוך ב-dual-stack ובפעולה ב-IPv6 בלבד ב-Ethernet.

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

• [C-3-1] חובה לתמוך בפעולה של IPv6 (IPv6 בלבד ואולי גם שתי שכבות) בנייד.

אם הטמעות במכשירים תומכות ביותר מסוג רשת אחד (למשל, Wi-Fi וחבילת גלישה), הם:

• [C-4-1] חייב לעמוד בו-זמנית בדרישות שלמעלה בכל רשת, כשהמכשיר מחובר בו-זמנית ליותר מסוג רשת אחד.

7.4.5.3. פורטלים שבויים

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

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

• [C-1-1] חובה לספק אפליקציית פורטל חובה כדי לטפל בכוונה ACTION_CAPTIVE_PORTAL_SIGN_IN ולהציג את דף ההתחברות לפורטל החובה, על ידי שליחת הכוונה הזו בקריאה ל-System API‏ ConnectivityManager#startCaptivePortalApp(Network, Bundle).
• [C-1-2] חובה לבצע זיהוי של פורטלים שבהם נדרש אישור כניסה (captive portal) ולתמוך בכניסה דרך אפליקציית הפורטל שבהם נדרש אישור כניסה כשהמכשיר מחובר לכל סוג רשת, כולל רשת סלולרית/ניידת, Wi-Fi, ‏ Ethernet או Bluetooth.
• [C-1-3] חובה לתמוך בכניסה לפורטלים שבהם נדרש אישור כדי להשתמש ב-DNS בטקסט ללא הצפנה, כשהמכשיר מוגדר לשימוש במצב קפדני של DNS פרטי.
• [C-1-4] חובה להשתמש ב-DNS מוצפן בהתאם למסמכי התיעוד של ה-SDK עבור android.net.LinkProperties.getPrivateDnsServerName ו-android.net.LinkProperties.isPrivateDnsActive לכל תעבורת הנתונים ברשת שלא מתקשרת באופן מפורש עם הפורטל השבוי.
• [C-1-5] חובה לוודא שבזמן שהמשתמש מתחבר לפורטל שבוי, רשת ברירת המחדל שבה משתמשות האפליקציות (כפי שמוחזרת על ידי ConnectivityManager.getActiveNetwork,‏ ConnectivityManager.registerDefaultNetworkCallback, ושיושמת כברירת מחדל על ידי ממשקי API של רשתות Java כמו java.net.Socket וממשקי API מקומיים כמו connect()) היא כל רשת זמינה אחרת שמספקת גישה לאינטרנט, אם יש כזו.

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

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

• [C-0-1] ההגדרה של הסנכרון האוטומטי הראשי חייבת להיות מופעלת כברירת מחדל, כדי שהשיטה getMasterSyncAutomatically() תחזיר את הערך 'true'.

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

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

• [C-SR-1] מומלץ מאוד לספק את מצב חיסכון בחבילת הגלישה.

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

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

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

• [C-2-1] חובה להחזיר את הערך RESTRICT_BACKGROUND_STATUS_DISABLED עבור ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] אסור לשדר את ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. רכיבים מאובטחים

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

• [C-1-1] חובה למנות את הקוראים הזמינים של רכיבים מאובטחים באמצעות API של android.se.omapi.SEService.getReaders().

• [C-1-2] חובה להצהיר על דגלים נכונים של תכונות באמצעות android.hardware.se.omapi.uicc למכשיר עם רכיבים מאובטחים מבוססי UICC, android.hardware.se.omapi.ese למכשיר עם רכיבים מאובטחים מבוססי eSE ו-android.hardware.se.omapi.sd למכשיר עם רכיבים מאובטחים מבוססי SD.

7.4.9. UWB

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

• [C-1-1] חובה להטמיע את Android API התואם ב-android.uwb.
• [C-1-2] חובה לדווח על הדגל של תכונת החומרה android.hardware.uwb.
• [C-1-3] חובה לתמוך בכל הפרופילים הרלוונטיים של UWB שמוגדרים בהטמעה של Android.
• [C-1-4] חובה לספק למשתמש אמצעי להפעלה או להשבתה של הרדיו ב-UWB.
• [C-1-5] חובה לאכוף שאפליקציות שמשתמשות ברדיו UWB יקבלו את ההרשאה UWB_RANGING (בקבוצת ההרשאות NEARBY_DEVICES).
• [C-SR-1] מומלץ מאוד לעבור את בדיקות התאימות והאישור הרלוונטיות שהוגדרו על ידי ארגוני התקנים, כולל FIRA, ‏ CCC ו-CSA.
• [C-1-6] חובה לוודא שמדידות המרחק נמצאות בטווח של +/-15 ס"מ ב-95% מהמדידות בסביבת קו הראייה במרחק של 1 מ' בתא לא רפלקטיבי.
• [C-1-7] חובה לוודא שהחציון של מדידות המרחק במרחק של 1 מ' ממכשיר העזר נמצא בטווח [0.75 מ', 1.25 מ'], כאשר המרחק הממשי נמדד מהקצה העליון של ה-DUT. המכשיר מוחזק עם הפנים כלפי מעלה ומשופע ב-45 מעלות.
• [C-SR-2] מומלץ מאוד לפעול לפי שלבי הגדרת המדידה שמפורטים בדרישות לכיול נוכחות.

7.5. מצלמות

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

• [C-1-1] חובה להצהיר על דגל התכונה android.hardware.camera.any.
• [C-1-2] חייבת להיות לאפליקציה אפשרות להקצות בו-זמנית 3 מפות ביטים מסוג RGBA_8888 בגודל התמונות שנוצרות על ידי חיישן המצלמה ברזולוציה הגבוהה ביותר במכשיר, בזמן שהמצלמה פתוחה לצורך תצוגה מקדימה בסיסית וצילום סטילס.
• [C-1-3] חובה לוודא שאפליקציית המצלמה שמותקנת כברירת מחדל ומטפלת בכוונות MediaStore.ACTION_IMAGE_CAPTURE,‏ MediaStore.ACTION_IMAGE_CAPTURE_SECURE או MediaStore.ACTION_VIDEO_CAPTURE אחראית להסרת המיקום של המשתמש מהמטא-נתונים של התמונה לפני השליחה שלה לאפליקציה המקבלת, אם לאפליקציה המקבלת אין את הרשאת ACCESS_FINE_LOCATION.

אם הטמעות במכשירים תומכות ביכולת פלט של HDR 10 ביט, הן:

• [C-2-1] חובה לתמוך לפחות בפרופיל HLG HDR בכל מכשיר מצלמה שתומך בפלט של 10 ביט.
• [C-2-2] חובה לתמוך בפלט של 10 ביט במצלמה הראשית האחורית או במצלמה הראשית הקדמית.
• [C-SR-1] מומלץ מאוד לתמוך בפלט של 10 ביט בשתי המצלמות הראשיות.
• [C-2-3] חייבת להיות תמיכה באותם פרופילי HDR לכל המצלמות הפיזיות המשניות של המצלמה הלוגי, וגם במצלמה הלוגי עצמה, עם תמיכה ב-BACKWARD_COMPATIBLE.

במכשירי מצלמה לוגיים שתומכים ב-HDR באיכות 10 ביט ומטמיעים את API ‏android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO:

• [C-3-1] חובה לתמוך במעבר בין כל המצלמות הפיזיות התואמות לאחור באמצעות אמצעי הבקרה CONTROL_ZOOM_RATIO במצלמה הלוגית.

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

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

יצירת דרישות חדשות

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

סיום הדרישות החדשות

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

• צריכה לכלול מצלמה אחורית.

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

• [C-1-1] חובה לדווח על דגל התכונה android.hardware.camera ועל android.hardware.camera.any.
• [C-1-2] חייבת להיות רזולוציה של לפחות 2 מגה-פיקסלים.
• צריך להטמיע התמקדות אוטומטית בחומרה או התמקדות אוטומטית בתוכנה במנהל המצלמה (שקוף לתוכנת האפליקציה).
• יכול להיות שיש בהם חומרה עם מיקוד קבוע או חומרה עם עומק שדה מורחב (EDOF).
• יכול להיות שיכלול הבזק.

אם המצלמה כוללת פלאש:

• [C-2-1] אסור שהנורה של הפלאש תידלק בזמן שמופיעה מופע android.hardware.Camera.PreviewCallback על משטח תצוגה מקדימה של מצלמה, אלא אם האפליקציה הפעלה את הפלאש באופן מפורש על ידי הפעלת המאפיינים FLASH_MODE_AUTO או FLASH_MODE_ON של אובייקט Camera.Parameters. חשוב לזכור שהאילוץ הזה לא חל על אפליקציית המצלמה המובנית של המכשיר, אלא רק על אפליקציות צד שלישי שמשתמשות ב-Camera.PreviewCallback.

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

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

יצירת דרישות חדשות

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

סיום הדרישות החדשות

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

• יכולה לכלול מצלמה קדמית.

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

• [C-1-1] חובה לדווח על דגל התכונה android.hardware.camera.any ועל android.hardware.camera.front.
• [C-1-2] חייבת להיות רזולוציה של לפחות VGA‏ (640x480 פיקסלים).
• [C-1-3] אסור להשתמש במצלמה קדמית כברירת מחדל ל-Camera API, ואסור להגדיר את ה-API כך שיתייחס למצלמה קדמית כמצלמה אחורית שמוגדרת כברירת מחדל, גם אם זו המצלמה היחידה במכשיר.
• [C-1-4] התצוגה המקדימה של המצלמה חייבת להיות מוחזרת (mirrored) אופקית ביחס לכיוון שצוין על ידי האפליקציה, אם האפליקציה הנוכחית ביקשה במפורש שצילום המצלמה יוזז באמצעות קריאה ל-method‏ android.hardware.Camera.setDisplayOrientation(). לעומת זאת, אם האפליקציה הנוכחית לא מבקשת במפורש לבצע סיבוב של מסך המצלמה באמצעות קריאה ל-method‏ android.hardware.Camera.setDisplayOrientation(), חובה לבצע היפוך מראה של התצוגה המקדימה לפי ציר האופק שמוגדר כברירת מחדל במכשיר.
• [C-1-5] אסור לשקף את התמונות הסטטיות או את הסטרימינג הסופי של הסרטונים שצולמו, שמוחזרים להודעות החזרה (callbacks) של האפליקציה או מועברים לאחסון מדיה.
• [C-1-6] חובה לשקף את התמונה שמוצגת על ידי התצוגה המקדימה באותו אופן שבו מוצג זרם התמונות של תצוגה המקדימה במצלמה.
• יכולות לכלול תכונות (כמו פוקוס אוטומטי, פלאש וכו') שזמינות למצלמות הפונות לאחור, כפי שמתואר בסעיף 7.5.1.

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

• [C-2-1] חובה להציג את התצוגה המקדימה של המצלמה בהיפוך אופקית ביחס לכיוון הנוכחי של המכשיר.

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

יצירת דרישות חדשות

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

סיום הדרישות החדשות

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

• יכול להיות שתהיה תמיכה במצלמה חיצונית שלא תמיד מחוברת.

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

• [C-1-1] חובה להצהיר על דגל התכונה של הפלטפורמה android.hardware.camera.external ו-android.hardware camera.any.
• [C-1-2] חובה לתמוך ב-USB Video Class‏ (UVC 1.0 ואילך) אם המצלמה החיצונית מחוברת דרך יציאת המארח של ה-USB.
• [C-1-3] חובה לעבור את בדיקות ה-CTS של המצלמה עם מצלמה חיצונית פיזית מחוברת. פרטים על בדיקות CTS של מצלמות זמינים בכתובת source.android.com.
• צריך לתמוך בדחיסת וידאו כמו MJPEG כדי לאפשר העברה של שידורים באיכות גבוהה ללא קידוד (כלומר שידורי תמונות גולמיים או דחוסים בנפרד).
• יכול להיות שתהיה תמיכה במספר מצלמות.
• יכול להיות שתהיה תמיכה בקידוד וידאו מבוסס-מצלמה.

אם יש תמיכה בקידוד וידאו מבוסס-מצלמה:

• [C-2-1] חייבת להיות גישה להזרמה בו-זמנית של MJPEG או של וידאו ללא קידוד (ברזולוציה QVGA ומעלה) להטמעה במכשיר.

7.5.4. התנהגות Camera API

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

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

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

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

• [C-0-1] חובה להשתמש ב-android.hardware.PixelFormat.YCbCr_420_SP לנתוני תצוגה מקדימה שסופקו להחזרות קריאה (callbacks) של אפליקציות, כשאף אפליקציה לא התקשרה ל-android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] בנוסף, הנתונים חייבים להיות בפורמט הקידוד NV21 כשאפליקציה רושמת מופע android.hardware.Camera.PreviewCallback והמערכת קוראת לשיטה onPreviewFrame() ופורמט התצוגה המקדימה הוא YCbCr_420_SP, הנתונים ב-byte[] מועברים אל onPreviewFrame(). כלומר, NV21 חייב להיות ברירת המחדל.
• [C-0-3] חובה לתמוך בפורמט YV12 (כפי שמצוין בערך הקבוע android.graphics.ImageFormat.YV12) לתצוגות המקדימה של המצלמה, גם במצלמה הקדמית וגם במצלמה האחורית של android.hardware.Camera. (קודק הווידאו והמצלמה של החומרה יכולים להשתמש בכל פורמט פיקסלים מקורי, אבל ההטמעה במכשיר חייבת לתמוך בהמרה ל-YV12).
• [C-0-4] חובה לתמוך בפורמטים android.hardware.ImageFormat.YUV_420_888 ו-android.hardware.ImageFormat.JPEG כפלט באמצעות ה-API של android.media.ImageReader במכשירי android.hardware.camera2 שמפרסמים את היכולת REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE ב-android.request.availableCapabilities.
• [C-0-5] חובה להטמיע את Camera API המלא שכלול במסמכי התיעוד של Android SDK, גם אם המכשיר כולל פוקוס אוטומטי בחומרה או יכולות אחרות. לדוגמה, מצלמות ללא פוקוס אוטומטי עדיין חייבות לקרוא לכל המכונות הרשמות של android.hardware.Camera.AutoFocusCallback (למרות שאין לכך רלוונטיות למצלמה ללא פוקוס אוטומטי). שימו לב שהדבר רלוונטי גם למצלמות קדמיות. לדוגמה, למרות שרוב המצלמות הקדמיות לא תומכות בפוקוס אוטומטי, עדיין צריך 'לזייף' את קריאות החזרה (callbacks) של ה-API כפי שמתואר.
• [C-0-6] חובה לזהות ולכבד כל שם פרמטר שמוגדר כקבוע בכיתה android.hardware.Camera.Parameters ובכיתה android.hardware.camera2.CaptureRequest. לעומת זאת, בהטמעות של מכשירים אסור להכיר או לכבד קבועים של מחרוזות שמועברים ל-method‏ android.hardware.Camera.setParameters(), מלבד אלה שמתועדים כקבועים ב-android.hardware.Camera.Parameters. כלומר, הטמעות במכשירים חייבות לתמוך בכל הפרמטרים הרגילים של המצלמה, אם החומרה מאפשרת זאת, ואסור להן לתמוך בסוגי פרמטרים מותאמים אישית של מצלמה. לדוגמה, הטמעות של מכשירים שתומכות בצילומי תמונות באמצעות שיטות צילום עם טווח דינמי גבוה (HDR) חייבות לתמוך בפרמטר המצלמה Camera.SCENE_MODE_HDR.
• [C-0-7] חובה לדווח על רמת התמיכה המתאימה באמצעות המאפיין android.info.supportedHardwareLevel כפי שמתואר ב-Android SDK, ולדווח על דגלים מתאימים של תכונות מסגרת.
• [C-0-8] חובה גם להצהיר על יכולות המצלמה הנפרדות של android.hardware.camera2 באמצעות המאפיין android.request.availableCapabilities ולהצהיר על דגלים מתאימים של תכונות. חובה להגדיר את דגל התכונה אם אחד ממכשירי המצלמה המצורפים תומך בתכונה.
• [C-0-9] חובה לשדר את הכוונה Camera.ACTION_NEW_PICTURE בכל פעם שצולמת תמונה חדשה במצלמה והרשומה של התמונה נוספה למאגר המדיה.
• [C-0-10] חובה לשדר את הכוונה Camera.ACTION_NEW_VIDEO בכל פעם שמצלמים סרטון חדש במצלמה והתמונה נוספה למאגר המדיה.
• [C-0-11] חובה שכל המצלמות יהיו נגישות דרך ממשק ה-API הישן android.hardware.Camera, וגם דרך ממשק ה-API android.hardware.camera2.
• [C-0-12] חובה לוודא שלא מתבצע שינוי במראה הפנים, כולל, בין היתר, שינוי בגיאומטריה של הפנים, בגוון העור של הפנים או בשיפור העור של הפנים בכל ממשק API של android.hardware.camera2 או של android.hardware.Camera.
• [C-SR-1] במכשירים עם כמה מצלמות RGB בקרבת מקום שמכוונות לאותו כיוון, מומלץ מאוד לתמוך במכשיר מצלמה לוגי שמציג את היכולות CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, שמורכב מכל מצלמות ה-RGB שמכוונות לאותו כיוון כמכשירי משנה פיזיים.

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

• [C-1-1] חובה להטמיע ממשק API כזה של מצלמה באמצעות API של android.hardware.camera2.
• יכולים לספק תגים ו/או תוספי ספקים ל-API של android.hardware.camera2.

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

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

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

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

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

יצירת דרישות חדשות

• הטמעות של מכשירים שהמשתמשים לא יכולים לסובב אותם, כמו מכשירים לכלי רכב.

סיום הדרישות החדשות

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

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

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

• [C-0-1] חובה לכלול מנהל הורדות שאפליקציות יכולות להשתמש בו כדי להוריד קבצי נתונים, והוא חייב להיות מסוגל להוריד קבצים נפרדים בגודל של לפחות 100MB למיקום ברירת המחדל 'מטמון'.

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

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

• [C-0-1] חובה להציע אחסון שאפשר לשתף עם אפליקציות, שנקרא גם "אחסון חיצוני משותף", "אחסון משותף של אפליקציות" או לפי הנתיב ב-Linux‏ ‎ "/sdcard" שאליו הוא מחובר.
• [C-0-2] חובה להגדיר אחסון משותף שמחובר כברירת מחדל, כלומר "מחוץ לקופסה", ללא קשר לאופן שבו האחסון מיושם – ברכיב אחסון פנימי או באמצעי אחסון נשלף (למשל, חריץ לכרטיס דיגיטלי מאובטח).
• [C-0-3] חובה לחבר את האחסון המשותף של האפליקציה ישירות לנתיב Linux‏ sdcard או לכלול קישור סימבולי של Linux מ-sdcard לנקודת החיבור בפועל.
• [C-0-4] חובה להפעיל את אחסון מוגבל כברירת מחדל בכל האפליקציות שמטרגטות רמת API 29 ואילך, מלבד במצב הבא:
  • כשהאפליקציה ביקשה את android:requestLegacyExternalStorage="true" במניפסט שלה.
• [C-0-5] חובה לצנזר מטא-נתונים של מיקום, כמו תגי Exif של GPS, שמאוחסנים בקובצי מדיה כשמתבצעת גישה לקבצים האלה דרך MediaStore, אלא אם לאפליקציה הקוראת יש את ההרשאה ACCESS_MEDIA_LOCATION.

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

• אחסון נשלף שזמין למשתמש, כמו חריץ לכרטיס Secure Digital‏ (SD).
• חלק מהאחסון הפנימי (לא ניתן להסרה) כפי שהוא מיושם בפרויקט Android Open Source Project‏ (AOSP).

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

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

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

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

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

• [C-3-1] חובה לספק מנגנון לגישה לנתונים באחסון המשותף של האפליקציה ממחשב מארח.
• צריך לחשוף תוכן משני נתיבי האחסון באופן שקוף באמצעות שירות סורק המדיה של Android ו-android.provider.MediaStore.
• אפשר להשתמש באחסון בנפח גדול ב-USB, אבל מומלץ להשתמש בפרוטוקול העברת מדיה כדי לעמוד בדרישות.

אם להטמעות של המכשירים יש יציאת USB במצב USB ציוד היקפי ותמיכה ב-Media Transfer Protocol, הן:

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

7.6.3. Adoptable Storage

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

• [C-SR-1] מומלץ מאוד להטמיע את האחסון שניתן לאמץ במיקום יציב לטווח ארוך, כי ניתוק בטעות עלול לגרום לאובדן או לפגיעה בנתונים.

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

• [C-SR-2] מומלץ מאוד להטמיע אחסון שניתן להתאמה.

7.7. USB

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

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

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

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

• [C-1-1] חובה שאפשר יהיה לחבר את היציאה למארח USB עם יציאת USB רגילה מסוג A או מסוג C.
• [C-1-2] חובה לדווח על הערך הנכון של iSerialNumber בתיאור ההתקן הסטנדרטי של USB דרך android.os.Build.SERIAL.
• [C-1-3] חובה לזהות מטענים של 1.5A ו-3.0A בהתאם לתקן הנגדים של Type-C, וחובה לזהות שינויים במודעה אם הם תומכים ב-USB Type-C.
• [C-SR-1] היציאה אמורה להיות בפורמט USB מסוג micro-B, ‏ micro-AB או Type-C. מומלץ מאוד שכל מכשירי Android הקיימים והחדשים יעמדו בדרישות האלה כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה.
• [C-SR-2] היציאה אמורה להיות ממוקמת בחלק התחתון של המכשיר (בהתאם לכיוון הטבעי) או להפעיל סיבוב מסך בתוכנה לכל האפליקציות (כולל מסך הבית), כדי שהמסך יוצג בצורה נכונה כשהמכשיר מונח כך שהיציאה נמצאת בחלק התחתון. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה, כדי שיוכלו לשדרג לגרסאות עתידיות של הפלטפורמה.
• [C-SR-3] צריך להטמיע תמיכה בזרם של 1.5A במהלך תנועה וצפצוף HS, כפי שמפורט במפרט טעינה של סוללות USB, גרסה 1.2. מומלץ מאוד שכל מכשירי Android הקיימים והחדשים יעמדו בדרישות האלה כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה.
• [C-SR-4] מומלץ מאוד לא לתמוך בשיטות טעינה קנייניות שמשנה את המתח של Vbus מעבר לרמות ברירת המחדל, או לשנות את התפקידים של מקור או נקודת קצה, כי הן עלולות לגרום לבעיות בתאימות עם מטענים או מכשירים שתומכים בשיטות הסטנדרטיות של USB Power Delivery. אמנם ההמלצה היא 'מומלץ מאוד', אבל בגרסאות עתידיות של Android יכול להיות שנדרוש שכל המכשירים עם חיבור Type-C יתמכו בתאימות מלאה לטעינה באמצעות מטענים רגילים עם חיבור Type-C.
• [C-SR-5] מומלץ מאוד לתמוך ב-Power Delivery לנתונים ולהחלפת תפקידים של מתח כשיש תמיכה ב-USB Type-C ובמצב מארח USB.
• צריכה להיות תמיכה ב-Power Delivery לטעינה במתח גבוה ותמיכה במצבים חלופיים, כמו Display Out.
• צריך להטמיע את המפרט ואת ה-API של Android Open Accessory‏ (AOA) כפי שמתואר במסמכי התיעוד של Android SDK.

אם הטמעות של מכשירים כוללות יציאת USB ומטמיעות את מפרט AOA, הן:

• [C-2-1] חובה להצהיר על תמיכה בתכונה החומרה android.hardware.usb.accessory.
• [C-2-2] הכיתה של אחסון בנפח גדול ב-USB חייבת לכלול את המחרוזת 'android' בסוף המחרוזת iInterface של תיאור הממשק של אחסון בנפח גדול ב-USB

7.7.2. מצב מארח USB

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

• [C-1-1] חובה להטמיע את Android USB host API כפי שמתואר ב-Android SDK, וצריך להצהיר על תמיכה בתכונה החומרה android.hardware.usb.host.
• [C-1-2] חובה להטמיע תמיכה לחיבור ציוד היקפי סטנדרטי מסוג USB. במילים אחרות, חובה:
  • יש יציאת Type-C במכשיר או שסופקו כבלים שמתאימים יציאה קניינית במכשיר ליציאת USB Type-C רגילה (מכשיר USB Type-C).
  • יש יציאת USB מסוג A במכשיר או שצריך לשלוח כבל שמתאים יציאה קניינית במכשיר ליציאת USB רגילה מסוג A.
  • יש יציאת micro-AB במכשיר, שאמורה להגיע עם כבל עם מתאם ליציאת Type-A רגילה.
• [C-1-3] אסור לשלוח את המכשיר עם מתאם שממיר מיציאות USB מסוג A או מיציאות micro-AB ליציאת Type-C (שקע).
• [C-SR-1] מומלץ מאוד להטמיע את USB audio class כפי שמתואר במסמכי התיעוד של Android SDK.
• צריך לתמוך בטעינה של התקן ההיקפי המחובר מסוג USB במצב מארח, לפרסם זרם מקור של לפחות 1.5A כפי שמפורט בקטע 'פרמטרים של סיום' במפרט USB Type-C Cable and Connector Specification Revision 1.2 למחברים מסוג USB Type-C, או להשתמש בטווח זרם הפלט של יציאת טעינה במורד הזרם (CDP) כפי שמפורט במפרט USB Battery Charging specifications, revision 1.2 למחברים מסוג Micro-AB.
• צריך להטמיע ולתמוך בתקני USB Type-C.

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

• [C-2-1] חובה לתמוך בממשק ה-HID של USB.
• [C-2-2] חובה לתמוך בזיהוי ובמיפוי של שדות הנתונים הבאים של HID, שצוינו בטבלאות השימוש של USB HID ובבקשת השימוש בפקודות קוליות, לקבועות KeyEvent, כפי שמפורט בהמשך:
  • דף שימוש (0xC) מזהה שימוש (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • דף שימוש (0xC) מזהה שימוש (0x0E9): KEYCODE_VOLUME_UP
  • דף שימוש (0xC) מזהה שימוש (0x0EA): KEYCODE_VOLUME_DOWN
  • דף שימוש (0xC) מזהה שימוש (0x0CF): KEYCODE_VOICE_ASSIST

אם הטמעות המכשירים כוללות יציאת USB שתומכת במצב מארח וב-Storage Access Framework‏ (SAF), הן:

• [C-3-1] חובה לזהות כל מכשיר MTP (פרוטוקול העברת מדיה) שמחובר מרחוק, ולאפשר גישה לתוכן שלו באמצעות הכוונות ACTION_GET_CONTENT, ‏ ACTION_OPEN_DOCUMENT ו-ACTION_CREATE_DOCUMENT. .

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

• [C-4-1] חובה להטמיע את הפונקציונליות של יציאה עם תפקיד כפול כפי שמוגדרת במפרט USB Type-C (קטע 4.5.1.3.3). ביציאות עם תפקיד כפול, במכשירים שכוללים שקע אודיו בגודל 3.5 מ"מ, יכול להיות שהזיהוי של שקע USB (מצב מארח) יהיה מושבת כברירת מחדל, אבל המשתמש חייב להיות מסוגל להפעיל אותו.
• [C-SR-2] מומלץ מאוד לתמוך ב-DisplayPort, צריך לתמוך בקצבי נתונים של USB SuperSpeed, ומומלץ מאוד לתמוך ב-Power Delivery להחלפת תפקידים של נתונים וחשמל.
• [C-SR-3] מומלץ מאוד לא לתמוך במצב 'מתאם אודיו' כפי שמתואר בנספח א' של גרסה 1.2 של מפרט הכבל והמחבר מסוג USB Type-C.
• צריך להטמיע את המודל Try.* שמתאים ביותר לגורם הצורה של המכשיר. לדוגמה, במכשיר נייד צריך להטמיע את המודל Try.SNK.

7.8. אודיו

7.8.1. מיקרופון

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

• [C-1-1] חובה לדווח על קבוע התכונה android.hardware.microphone.
• [C-1-2] חייב לעמוד בדרישות להקלטת אודיו שמפורטות בקטע 5.4.
• [C-1-3] חייב לעמוד בדרישות של זמן האחזור של האודיו שמפורטות בקטע 5.6.
• [C-SR-1] מומלץ מאוד לתמוך בהקלטה של אולטרסאונד קרוב כפי שמתואר בסעיף 7.8.3.

אם הטמעות של מכשירים לא כוללות מיקרופון, הן:

• [C-2-1] אסור לדווח על קבוע התכונה android.hardware.microphone.
• [C-2-2] חובה להטמיע את ממשק ה-API להקלטת אודיו לפחות כ-no-ops, בהתאם לקטע 7.

7.8.2. יעד השמע

אם הטמעות של מכשירים כוללות רמקול או יציאת פלט אודיו/מולטימדיה למכשיר היקפי של פלט אודיו, כמו שקע אודיו בגודל 3.5 מ"מ עם 4 מוליכים או יציאה במצב מארח USB באמצעות USB audio class, הן:

• [C-1-1] חובה לדווח על קבוע התכונה android.hardware.audio.output.
• [C-1-2] חייב לעמוד בדרישות להפעלת אודיו שמפורטות בקטע 5.5.
• [C-1-3] חייב לעמוד בדרישות של זמן האחזור של האודיו שמפורטות בקטע 5.6.
• [C-SR-1] מומלץ מאוד לתמוך בהפעלה של אולטרסאונד כמעט, כפי שמתואר בקטע 7.8.3.

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

• [C-2-1] אסור לדווח על התכונה android.hardware.audio.output.
• [C-2-2] חובה להטמיע את ממשקי ה-API שקשורים לפלט האודיו כ-no-ops לפחות.

לצורכי הקטע הזה, 'יציאת פלט' היא ממשק פיזי, כמו שקע אודיו בגודל 3.5 מ"מ, HDMI או יציאת USB במצב מארח עם אודיו מסוג USB. תמיכה בפלט אודיו באמצעות פרוטוקולים מבוססי רדיו כמו Bluetooth,‏ Wi-Fi או רשת סלולרית לא נחשבת ככוללת 'יציאת פלט'.

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

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

• [C-SR-1] מומלץ מאוד לכלול לפחות אחד משקעי האודיו כתקע אודיו 3.5 מ"מ עם 4 מוליכים.

אם להטמעות של המכשירים יש שקע אודיו 3.5 מ"מ עם 4 מוליכים, הן:

• [C-1-1] חובה לתמוך בהפעלת אודיו באוזניות סטריאופוניות ובאוזניות סטריאופוניות עם מיקרופון.
• [C-1-2] חובה לתמוך בתקע אודיו TRRS עם סדר הפינים של CTIA.
• [C-1-3] חובה לתמוך בזיהוי ובמיפוי לקודי המפתחות של 3 טווחי ההתנגדות השקולה הבאים בין המיקרופון לבין מוליכי הארקה בתקע האודיו:
  • 70 אוהם או פחות: KEYCODE_HEADSETHOOK
  • 210-290 אוהם: KEYCODE_VOLUME_UP
  • 360-680 אוהם: KEYCODE_VOLUME_DOWN
• [C-1-4] חובה להפעיל את ACTION_HEADSET_PLUG כשמחברים את המחבר, אבל רק אחרי שכל המגעים במחבר נוגעים בקטעים הרלוונטיים בתקע.
• [C-1-5] חייב להיות מסוגל להפעיל לפחות 150mV ± 10% מתח יציאה בהתנגדות של רמקול 32 אוהם.
• [C-1-6] המתח של המיקרופון חייב להיות בין 1.8V ל-2.9V.
• [C-1-7] חובה לזהות את הטווח הבא של עכבה שווה ערך בין המיקרופון לבין מוליכי הארקה בתקע האודיו ולמפות אותו לקוד המפתח:
  • 110-180 אוהם: KEYCODE_VOICE_ASSIST
• [C-SR-2] מומלץ מאוד לתמוך בכבלים עם מחברי אודיו לפי הסדר של OMTP.
• [C-SR-3] מומלץ מאוד לתמוך בהקלטת אודיו מאוזניות סטריאופוניות עם מיקרופון.

אם הטמעות של מכשירים כוללות שקע אודיו עם 4 מוליכים בגודל 3.5 מ"מ ותומכות במיקרופון, ומפיצות את ה-android.intent.action.HEADSET_PLUG עם הערך הנוסף microphone מוגדר כ-1, הן:

• [C-2-1] חובה לתמוך בזיהוי המיקרופון באביזר האודיו המחובר.

7.8.2.2. שקעי אודיו דיגיטליים

הדרישות הספציפיות למכשיר מפורטות בקטע 2.2.1.

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

אודיו קרוב לאולטרה-סאונד הוא התדר 18.5kHz עד 20kHz.

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

• חובה לדווח בצורה נכונה על התמיכה ביכולת אודיו ליד אולטרסאונד באמצעות ה-API‏ AudioManager.getProperty באופן הבא:

אם הערך של PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND הוא 'true', מקורות האודיו VOICE_RECOGNITION ו-UNPROCESSED חייבים לעמוד בדרישות הבאות:

• [C-1-1] תגובת הכוח הממוצעת של המיקרופון בתחום התדרים 18.5kHz עד 20kHz חייבת להיות נמוכה ב-15dB לכל היותר מהתגובה בתדר 2kHz.
• [C-1-2] יחס האות לרעש ללא משקל של המיקרופון בטווח של 18.5kHz עד 20kHz, עבור צליל של 19kHz ב-26dBFS, חייב להיות לפחות 50dB.

אם הערך של PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND הוא 'true':

• [C-2-1] התגובה הממוצעת של הרמקול בתחום התדרים 18.5kHz עד 20kHz חייבת להיות גבוהה מ-40dB מתחת לתגובה בתדר 2kHz.

7.8.4. תקינות האות

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

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

הבדיקה דורשת מתאם אודיו ל-loopback, שמחובר ישירות לתקע 3.5 מ"מ ו/או בשילוב עם מתאם USB-C ל-3.5 מ"מ. מומלץ לבדוק את כל יציאות הקול.

נכון לעכשיו, OboeTester תומך בנתיבים של AAudio, לכן צריך לבדוק את השילובים הבאים כדי לאתר באגים באמצעות AAudio:

מצב Perf	שיתוף	תדירות דגימה של פלט	ב-Chans	Out Chans
LOW_LATENCY	בלעדי	UNSPECIFIED	1	2
LOW_LATENCY	בלעדי	UNSPECIFIED	2	1
LOW_LATENCY	משותף	UNSPECIFIED	1	2
LOW_LATENCY	משותף	UNSPECIFIED	2	1
ללא	משותף	48000	1	2
ללא	משותף	48000	2	1
ללא	משותף	44100	1	2
ללא	משותף	44100	2	1
ללא	משותף	16000	1	2
ללא	משותף	16000	2	1

שידור מהימן אמור לעמוד בקריטריונים הבאים ליחס אות לרעש (SNR) ולעיוות הרמוני כולל (THD) עבור גל סינוס של 2,000Hz.

מתמר	THD	SNR
הרמקול המובנה הראשי, שנמדד באמצעות מיקרופון חיצוני	פחות מ-3.0%	50dB או יותר
המיקרופון המובנה הראשי, שנמדד באמצעות רמקול חיצוני למטרות השוואה	פחות מ-3.0%	50dB או יותר
שקעים אנלוגיים מובנים בגודל 3.5 מ"מ, שנבדקו באמצעות מתאם לולאה חוזרת	פחות מ-1%	60dB או יותר
מתאמי USB שסופקו עם הטלפון, נבדקו באמצעות מתאם לולאה חוזרת	< 1.0%	60dB או יותר

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

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

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

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

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

אם הטמעות המכשירים תומכות במצב VR, הן:

• [C-1-1] חייב להיות עם לפחות 2 ליבות פיזיות.
• [C-1-2] חובה להצהיר על התכונה android.hardware.vr.high_performance.
• [C-1-3] חובה לתמוך במצב ביצועים יציבים.
• [C-1-4] חובה שתהיה תמיכה ב-OpenGL ES 3.2.
• [C-1-5] חובה לתמוך ב-android.hardware.vulkan.level 0.
• המערכת אמורה לתמוך ב-android.hardware.vulkan.level 1 ואילך.
• [C-1-6] חובה להטמיע את התוספים EGL_KHR_mutable_render_buffer,‏ EGL_ANDROID_front_buffer_auto_refresh,‏ EGL_ANDROID_get_native_client_buffer,‏ EGL_KHR_fence_sync,‏ EGL_KHR_wait_sync,‏ EGL_IMG_context_priority,‏ EGL_EXT_protected_content,‏ EGL_EXT_image_gl_colorspace ולהציג אותם ברשימה של תוספי EGL הזמינים.
• [C-1-8] חובה להטמיע את התוספים GL_EXT_multisampled_render_to_texture2,‏ GL_OVR_multiview,‏ GL_OVR_multiview2,‏ GL_EXT_protected_textures ולהציג אותם ברשימת התוספים הזמינים של GL.
• [C-SR-1] מומלץ מאוד להטמיע את GL_EXT_external_buffer,‏ GL_EXT_EGL_image_array ו-GL_OVR_multiview_multisampled_render_to_texture, ולהציג את התוספים ברשימת התוספים הזמינים של GL.
• [C-SR-2] מומלץ מאוד לתמוך ב-Vulkan 1.1.
• [C-SR-3] מומלץ מאוד להטמיע את VK_ANDROID_external_memory_android_hardware_buffer,‏ VK_GOOGLE_display_timing ו-VK_KHR_shared_presentable_image ולהציג אותם ברשימת התוספים הזמינים של Vulkan.
• [C-SR-4] מומלץ מאוד לחשוף לפחות משפחת תורים אחת של Vulkan, שבה flags מכילה גם את VK_QUEUE_GRAPHICS_BIT וגם את VK_QUEUE_COMPUTE_BIT, ו-queueCount הוא לפחות 2.
• [C-1-7] חייבים להיות ל-GPU ולמסך אפשרות לסנכרן את הגישה למאגר הקדמי המשותף, כך שאפשר יהיה להציג עיבוד לסירוגין של תוכן VR בשתי סביבות עיבוד ב-60fps לכל עין, ללא פגמים גלויים של קריעה.
• [C-1-9] חובה להטמיע תמיכה בדגלים AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER,‏ AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA ו-AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT של AHardwareBuffer כפי שמתואר ב-NDK.
• [C-1-10] חובה להטמיע תמיכה ב-AHardwareBuffer עם כל שילוב של דגלי השימוש AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT,‏ AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE,‏ AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT לפחות בפורמטים הבאים: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM,‏ AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM,‏ AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM,‏ AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR-5] מומלץ מאוד לתמוך בהקצאה של AHardwareBuffers עם יותר משכבה אחת, ודגלים ופורמטים כפי שמפורטים ב-C-1-10.
• [C-1-11] חובה לתמוך בפענוח H.264 ברזולוציה של לפחות 3840 x 2160 ב-30fps, דחוסה במהירות ממוצעת של 40Mbps (שווה ערך ל-4 מופעים של 1920 x 1080 ב-30fps-10Mbps או ל-2 מופעים של 1920 x 1080 ב-60fps-20Mbps).
• [C-1-12] חובה שתהיה תמיכה ב-HEVC וב-VP9, חובה שתהיה יכולת לפענח לפחות ‎1920 x 1080 בקצב 30fps באיכות דחוסה של ‎10Mbps בממוצע, ומומלץ שתהיה יכולת לפענח ‎3840 x 2160 בקצב 30fps-20Mbps (שווה ערך ל-4 מופעים של ‎1920 x 1080 בקצב 30fps-5Mbps).
• [C-1-13] חובה לתמוך ב-HardwarePropertiesManager.getDeviceTemperatures API ולהחזיר ערכים מדויקים של טמפרטורת העור.
• [C-1-14] חייב לכלול מסך מוטמע, והרזולוציה שלו חייבת להיות לפחות ‎1920 x 1080.
• [C-SR-6] מומלץ מאוד שהרזולוציה של המסך תהיה לפחות 2560 x 1440.
• [C-1-15] התצוגה חייבת להתעדכן במהירות של לפחות 60 הרץ במצב VR.
• [C-1-17] המסך חייב לתמוך במצב של עמידות נמוכה עם עמידות של 5 אלפיות שנייה לכל היותר. העמידות מוגדרת כמשך הזמן שבו פיקסל פולט אור.
• [C-1-18] חובה לתמוך ב-Bluetooth 4.2 וב-Bluetooth LE Data Length Extension (הארכת אורך הנתונים של Bluetooth LE) קטע 7.4.3.
• [C-1-19] חובה לתמוך בסוג הערוץ הישיר ולדווח עליו בצורה תקינה לכל סוגי החיישנים הבאים שמוגדרים כברירת מחדל:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR-7] מומלץ מאוד לתמוך בסוג הערוץ הישיר TYPE_HARDWARE_BUFFER לכל סוגי הערוצים הישירים שמפורטים למעלה.
• [C-1-21] חייב לעמוד בדרישות לגבי הג'ירוסקופ, מד התאוצה והמגנטומטר של android.hardware.hifi_sensors, כפי שמפורט בקטע 7.3.9.
• [C-SR-8] מומלץ מאוד לתמוך בתכונה android.hardware.sensor.hifi_sensors.
• [C-1-22] זמן האחזור מקצה לקצה של תנועה לפוטון חייב להיות לא יותר מ-28 אלפיות השנייה.
• [C-SR-9] מומלץ מאוד שהזמן המצטבר מהתנועה ועד ליצירת הפוטון לא יעלה על 20 אלפיות השנייה.
• [C-1-23] חייב להיות יחס של הפריים הראשון, שהוא היחס בין הבהירות של הפיקסלים בפריים הראשון אחרי המעבר משחור ללבן לבין הבהירות של הפיקסלים הלבנים במצב יציב, של לפחות 85%.
• [C-SR-10] מומלץ מאוד שהיחס של הפריים הראשון יהיה לפחות 90%.
• יכול להיות שהמעבד יספק ליבה בלעדית לאפליקציה שבחזית, ויכול להיות שהוא יתמוך ב-API ‏Process.getExclusiveCores כדי להחזיר את המספרים של ליבות המעבד שהן בלעדיות לאפליקציה העליונה שבחזית.

אם יש תמיכה בליבה בלעדית, הליבה:

• [C-2-1] אסור לאפשר להריץ בה תהליכים אחרים במרחב המשתמש (למעט מנהלי התקנים שבהם האפליקציה משתמשת), אבל מותר לאפשר להריץ בה תהליכים מסוימים בליבה לפי הצורך.

7.10. מגע

יצירת דרישות חדשות

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

אם הטמעות המכשירים לא כוללות מפעיל חישה (actuator) כזה למטרות כלליות, הן:

• [7.10/C] חובה להחזיר את הערך false עבור Vibrator.hasVibrator().

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

• [C-1-1] חייב להחזיר את הערך true עבור Vibrator.hasVibrator().
• אסור להשתמש במפעיל (רטט) היפטי מסוג מסה מסתובבת חריגה (ERM).
• צריך להטמיע את כל הקבועים הציבוריים של רטט ברור ב-android.view.HapticFeedbackConstants, כלומר (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START ו-GESTURE_END).
• צריך להטמיע את כל הקבועים הציבוריים של רטט ברור ב-android.os.VibrationEffect, כלומר (EFFECT_TICK,‏ EFFECT_CLICK,‏ EFFECT_HEAVY_CLICK ו-EFFECT_DOUBLE_CLICK), ואת כל הקבועים הציבוריים האפשריים של PRIMITIVE_* לרטט עשיר ב-android.os.VibrationEffect.Composition, כלומר (CLICK,‏ TICK,‏ LOW_TICK,‏ QUICK_FALL,‏ QUICK_RISE,‏ SLOW_RISE,‏ SPIN,‏ THUD). יכול להיות שחלק מהפרימיטיבים האלה, כמו LOW_TICK ו-SPIN, יהיו אפשריים רק אם הרטט יכול לתמוך בתדרים נמוכים יחסית.
• צריך לפעול לפי ההנחיות למיפוי של קבועים ציבוריים ב-android.view.HapticFeedbackConstants לקבועים המומלצים של android.os.VibrationEffect, עם יחסי האמפליטודה המתאימים.
• צריך להשתמש במיפויים האלה של קבועים הקטיפטיים המקושרים.
• צריך לפעול לפי הערכת האיכות של ממשקי ה-API של createOneShot() ושל createWaveform().
• צריך לוודא שהתוצאה של ממשק ה-API הציבורי android.os.Vibrator.hasAmplitudeControl() משקפת בצורה נכונה את היכולות של הוויברטור.
• צריך לאמת את היכולות של התאמת העוצמה לעומס על ידי הפעלת android.os.Vibrator.hasAmplitudeControl().

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

• צריך לאמת את סטטוס ההטמעה על ידי הפעלת ממשקי ה-API android.os.Vibrator.areAllEffectsSupported() ו-android.os.Vibrator.arePrimitivesSupported().
• צריך לבצע בדיקת איכות של קבועים של משוב מישוש.
• צריך לאמת את הגדרת ברירת המחדל לפרימיטיבים שלא נתמכים ולעדכן אותה לפי הצורך, כפי שמתואר בהנחיות להטמעה של קבועים.
• צריך לספק תמיכה חלופית כדי לצמצם את הסיכון לכשל, כפי שמתואר כאן.

סיום הדרישות החדשות

הדרישות הספציפיות למכשיר מפורטות בקטע 2.2.1.

7.11. Media Performance Class

אפשר לקבל את סיווג הביצועים של המדיה בהטמעה במכשיר מ-android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS API. הדרישות לסיווג ביצועי המדיה מוגדרות לכל גרסת Android, החל מ-R‏ (גרסה 30). הערך המיוחד 0 מציין שהמכשיר לא שייך לסוג של ביצועי מדיה.

אם הטמעות במכשירים מחזירות ערך שאינו אפס עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, הן:

• [C-1-1] חייב להחזיר ערך של android.os.Build.VERSION_CODES.R לפחות.

• [C-1-2] חובה להטמיע במכשיר נייד.

• [C-1-3] חייב לעמוד בכל הדרישות ל'רמת ביצועים של מדיה' שמתוארות בקטע 2.2.7.

במילים אחרות, סיווג הביצועים של מדיה ב-Android T מוגדר רק למכשירים ניידים בגרסה T, ‏ S או R.

דרישות ספציפיות למכשירים מפורטות בקטע 2.2.7.

8. ביצועים וצריכת חשמל

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

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

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

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

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

• ביצועי כתיבת רצף. נמדד על ידי כתיבת קובץ בגודל 256MB באמצעות מאגר כתיבה של 10MB.
• ביצועי כתיבה אקראיים. נמדד על ידי כתיבת קובץ בגודל 256MB באמצעות מאגר כתיבה של 4KB.
• ביצועי קריאה רציפים. נמדד על ידי קריאת קובץ בגודל 256MB באמצעות מאגר כתיבה של 10MB.
• ביצועי קריאה אקראית. נמדד על ידי קריאת קובץ בגודל 256MB באמצעות מאגר כתיבה של 4KB.

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

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

• [C-1-1] אסור לסטות מההטמעה של AOSP לגבי ההפעלה, התחזוקה, אלגוריתמי ההתעוררות והשימוש בהגדרות המערכת הגלובליות או ב-DeviceConfig של המצבים לחיסכון באנרגיה 'המתנה לאפליקציה' ו'דוז'.
• [C-1-2] אסור לסטות מההטמעה של AOSP לגבי השימוש בהגדרות גלובליות או ב-DeviceConfig לניהול הצמצום של משימות, התראות ורשתות באפליקציות בכל קטגוריה של מצב המתנה של אפליקציות.
• [C-1-3] אסור לסטות מההטמעה של AOSP לגבי מספר הקטגוריות של סטטוס 'אפליקציה במצב המתנה' שמשמש לסטטוס 'אפליקציה במצב המתנה'.
• [C-1-4] חובה להטמיע קטגוריות של אפליקציות במצב המתנה ו-Doze כפי שמתואר בקטע ניהול צריכת החשמל.
• [C-1-5] חובה להחזיר את הערך true עבור PowerManager.isPowerSaveMode() כשהמכשיר במצב חיסכון בסוללה.
• [C-1-6] חובה לספק למשתמשים אפשרות להציג את כל האפליקציות שמוחרגו ממצבי חיסכון באנרגיה 'המתנה לאפליקציה' ו'דוז', או מכל אופטימיזציות הסוללה, וחובה להטמיע את הכוונה ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS כדי לבקש מהמשתמשים לאפשר לאפליקציה להתעלם מאופטימיזציות הסוללה.
• [C-SR-1] מומלץ מאוד לספק למשתמשים אפשרות להפעיל ולהשבית את התכונה 'חיסכון בסוללה'.
• [C-SR-2] מומלץ מאוד לספק למשתמש אפשרות להציג את כל האפליקציות שפטורות ממצבי חיסכון באנרגיה 'המתנה לאפליקציה' ו'דוז'.

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

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

אם הטמעות של מכשירים מטמיעות מצבי צריכת אנרגיה מסוג S4 כפי שמוגדרים ב-ACPI, הן:

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

אם הטמעות של מכשירים מטמיעות מצבי צריכת אנרגיה של S3 כפי שמוגדרים ב-ACPI, הן:

• [C-2-1] חובה לעמוד בתנאי של C-1-1 שלמעלה, או חובה להיכנס למצב S3 רק כשאפליקציות של צד שלישי לא זקוקות למשאבי המערכת (למשל המסך, המעבד).

  לעומת זאת, חייבים לצאת ממצב S3 כשאפליקציות של צד שלישי זקוקות למשאבי המערכת, כפי שמתואר ב-SDK הזה.

  לדוגמה, כשאפליקציות של צד שלישי מבקשות להשאיר את המסך דלוק דרך FLAG_KEEP_SCREEN_ON או להפעיל את המעבד דרך PARTIAL_WAKE_LOCK, אסור שהמכשיר יעבור למצב S3, אלא אם המשתמש ביצע פעולה מפורשת כדי להעביר את המכשיר למצב לא פעיל, כפי שמתואר בקטע C-1-1. לעומת זאת, כשמשימה שאפליקציות צד שלישי מטמיעות דרך JobScheduler מופעלת או כשהודעות מ-Firebase Cloud Messaging מועברות לאפליקציות צד שלישי, המכשיר חייב לצאת ממצב S3, אלא אם המשתמש העביר את המכשיר למצב לא פעיל. אלה לא דוגמאות מקיפות, ו-AOSP מטמיע אותות התעוררות נרחבים שמפעילים התעוררות מהמצב הזה.

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

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

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

• [C-SR-1] מומלץ מאוד לספק פרופיל צריכת אנרגיה לכל רכיב, שמגדיר את ערך הצריכה הנוכחית של כל רכיב חומרה ואת הירידה המשוערת בנפח הסוללה שנגרמת על ידי הרכיבים לאורך זמן, כפי שמופיע באתר של Android Open Source Project.
• [C-SR-2] מומלץ מאוד לדווח על כל ערכי צריכת החשמל במיליאמפר-שעה (mAh).
• [C-SR-3] מומלץ מאוד לדווח על צריכת האנרגיה של המעבד (CPU) לכל מזהה משתמש (UID) של תהליך. פרויקט הקוד הפתוח של Android עומד בדרישות באמצעות הטמעת מודול הליבה uid_cputime.
• [C-SR-4] מומלץ מאוד להפוך את צריכת החשמל הזו לזמינה למפתח האפליקציה באמצעות הפקודה adb shell dumpsys batterystats של מעטפת.
• צריך לשייך לרכיב החומרה עצמו אם אי אפשר לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.

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

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

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

• [C-0-1] חובה לדווח בצורה מדויקת על התמיכה במצב ביצועים יציבים באמצעות שיטת ה-API‏ PowerManager.isSustainedPerformanceModeSupported().

• צריכה להיות תמיכה במצב 'ביצועים יציבים'.

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

• [C-1-1] חובה לספק לאפליקציה העיקרית בחזית רמת ביצועים עקבית למשך 30 דקות לפחות, כשהאפליקציה מבקשת זאת.
• [C-1-2] חובה לפעול בהתאם לממשק ה-API של Window.setSustainedPerformanceMode() ולממשקי API קשורים אחרים.

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

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

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

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

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

• [C-3-1] חובה להחזיר רשימה ריקה באמצעות שיטת ה-API Process.getExclusiveCores().

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

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

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

• [C-0-2] חובה לתמוך בהתקנה של אפליקציות בחתימה עצמית בלי צורך בהרשאות או באישורים נוספים מצדדים שלישיים או מרשויות.

אם הטמעות במכשירים מכריזות על התכונה android.hardware.security.model.compatible, הן:

• [C-1-1] חייב לתמוך בדרישות שמפורטות בקטעים הבאים.

9.1. הרשאות

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

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

• מותר להוסיף הרשאות נוספות, בתנאי שמחרוזות מזהי ההרשאות החדשות לא נמצאות במרחב השמות android.\*.

• [C-0-2] הרשאות עם protectionLevel של PROTECTION_FLAG_PRIVILEGED חייבות להינתן רק לאפליקציות שמותקנות מראש בנתיבים המורשים של קובץ האימג' של המערכת (וגם לקבצי APEX), והן חייבות להיכלל בקבוצת המשנה של ההרשאות שמופיעות ברשימת ההיתרים המפורשת של כל אפליקציה. ההטמעה של AOSP עומדת בדרישות האלה על ידי קריאה של ההרשאות שמופיעות ברשימת ההיתרים של כל אפליקציה מהקבצים שבנתיב etc/permissions/ וביצוע שלהן, ושימוש בנתיב system/priv-app כנתיב המורשה.

הרשאות עם רמת הגנה מסוכנת הן הרשאות בזמן ריצה. אפליקציות עם targetSdkVersion > 22 מבקשות אותן בסביבת זמן הריצה.

הטמעות במכשירים:

• [C-0-3] חובה להציג ממשק ייעודי למשתמש כדי שהוא יוכל להחליט אם להעניק את הרשאות זמן הריצה המבוקשות, וגם לספק ממשק למשתמש לניהול הרשאות זמן הריצה.

• [C-0-4] חובה שתהיה הטמעה אחת בלבד של שני ממשקי המשתמש.

• [C-0-5] אסור להעניק לאפליקציות הרשאות זמן ריצה, אלא אם:

  • הן מותקנות בזמן שליחת המכשיר, וגם

  • אפשר לקבל את הסכמת המשתמש לפני שהאפליקציה משתמשת בהרשאה,

    או

  • הרשאות בסביבת זמן הריצה מוענקות על ידי מדיניות ברירת המחדל להקצאת הרשאות או על ידי החזקה בתפקיד בפלטפורמה.

• [C-0-6] חובה להעניק את ההרשאה android.permission.RECOVER_KEYSTORE רק לאפליקציות מערכת שמירשמו סוכן שחזור מאובטח כראוי. סוכן שחזור מאובטח מוגדר כסוכן תוכנה במכשיר שמסתנכרן עם אחסון מרוחק מחוץ למכשיר, שמאובזר בחומרה מאובטחת עם הגנה שווה או חזקה יותר מזו שמתוארת בשירות Google Cloud Key Vault, כדי למנוע התקפות כוח brute על גורם הידע במסך הנעילה.

הטמעות במכשירים:

• [C-0-7] חובה לפעול בהתאם למאפיינים של הרשאת המיקום ב-Android כשאפליקציה מבקשת את נתוני המיקום או הפעילות הפיזית דרך Android API רגיל או מנגנון קנייני. הנתונים האלה כוללים, בין היתר:

  • המיקום של המכשיר (למשל, קו הרוחב וקו האורך) כפי שמתואר בקטע 9.8.8.
  • מידע שאפשר להשתמש בו כדי לקבוע או להעריך את המיקום של המכשיר (למשל SSID,‏ BSSID,‏ Cell ID או המיקום של הרשת שאליה המכשיר מחובר).
  • הפעילות הגופנית של המשתמש או הסיווג של הפעילות הגופנית.

באופן ספציפי יותר, הטמעות של מכשירים:

• [C-0-8] חובה לקבל הסכמה מהמשתמשים כדי לאפשר לאפליקציה לגשת לנתוני המיקום או לנתוני הפעילות הגופנית.
• [C-0-9] חובה להעניק הרשאת זמן ריצה רק לאפליקציה שיש לה הרשאה מספקת, כפי שמתואר ב-SDK. לדוגמה, TelephonyManager#getServiceState מחייב את android.permission.ACCESS_FINE_LOCATION).

החריגים היחידים לנכסי הרשאות המיקום של Android שמפורטים למעלה הם לאפליקציות שלא ניגשות למיקום כדי להסיק או לזהות את מיקום המשתמש. באופן ספציפי:

• כשאפליקציות מקבלות את ההרשאה RADIO_SCAN_WITHOUT_LOCATION.
• לצורכי הגדרה והגדרה אישית של המכשיר, כשאפליקציות מערכת מחזיקות בהרשאה NETWORK_SETTINGS או NETWORK_SETUP_WIZARD.

אפשר לסמן הרשאות כמוגבלות כדי לשנות את ההתנהגות שלהן.

• [C-0-10] אסור להקצות לאפליקציה הרשאות שמסומנות בדגל hardRestricted, אלא אם:

  • קובץ APK של אפליקציה נמצא במחיצה של המערכת.
  • המשתמש מקצה לאפליקציה תפקיד שמשויך להרשאות hardRestricted.
  • מנהל ההתקנה מעניק את hardRestricted לאפליקציה.
  • אפליקציה קיבלה את ההרשאה hardRestricted בגרסה קודמת של Android.

• [C-0-11] אפליקציות עם הרשאת softRestricted חייבות לקבל גישה מוגבלת בלבד, אסור להן לקבל גישה מלאה עד להוספה לרשימת ההיתרים כפי שמתואר ב-SDK, שבו הגדרת הגישה המלאה והמוגבלת לכל הרשאת softRestricted (לדוגמה, READ_EXTERNAL_STORAGE).

• [C-0-12] אסור לספק פונקציות מותאמות אישית או ממשקי API כדי לעקוף את הגבלות ההרשאות שמוגדרות בממשקי ה-API setPermissionPolicy ו-setPermissionGrantState.

• [C-0-13] חובה להשתמש בממשקי ה-API של AppOpsManager כדי לתעד ולעקוב אחרי כל גישה פרוגרמטית לנתונים שמוגנים על ידי הרשאות מסוכנות מפעילויות ושירותים של Android.

• [C-0-14] חובה להקצות תפקידים רק לאפליקציות עם פונקציות שעומדות בדרישות התפקיד.

• [C-0-15] אסור להגדיר תפקידים שהם כפילויות או פונקציונליות של קבוצת-על של תפקידים שהוגדרו על ידי הפלטפורמה.

אם המכשירים מדווחים על android.software.managed_users, הם:

• [C-1-1] אסור שהאדמין יעניק את ההרשאות הבאות באופן אוטומטי:
  • מיקום (ACCESS_BACKGROUND_LOCATION, ‏ ACCESS_COARSE_LOCATION,‏ ACCESS_FINE_LOCATION).
  • מצלמה (CAMERA)
  • מיקרופון (RECORD_AUDIO)
  • חיישן גוף (BODY_SENSORS)
  • פעילות גופנית (ACTIVITY_RECOGNITION)

אם הטמעות במכשירים מספקות למשתמש אפשרות לבחור אילו אפליקציות יוכלו לצייר מעל אפליקציות אחרות באמצעות פעילות שמטפלת בכוונה ACTION_MANAGE_OVERLAY_PERMISSION, הן:

• [C-2-1] חובה לוודא שלכל הפעילויות עם מסנני כוונה לכוונה ACTION_MANAGE_OVERLAY_PERMISSION יש את אותו מסך ממשק משתמש, ללא קשר לאפליקציה המפעילה או למידע שהיא מספקת.

אם הטמעות במכשירים מדווחות על android.software.device_admin, הן:

• [C-3-1] חובה להציג כתב ויתור במהלך הגדרת המכשיר המנוהל באופן מלא (הגדרה על ידי בעלי המכשיר) שמציין שלאדמין ה-IT תהיה אפשרות לאפשר לאפליקציות לשלוט בהגדרות בטלפון, כולל המיקום, המיקרופון והמצלמה, עם אפשרויות למשתמש להמשיך בהגדרה או לצאת מההגדרה, אלא אם האדמין ביטל את ההסכמה לשלוט בהרשאות במכשיר.

אם הטמעות במכשירים מתקינות מראש חבילות שמכילות את התפקידים System UI Intelligence,‏ System Ambient Audio Intelligence,‏ System Audio Intelligence,‏ System Notification Intelligence,‏ System Text Intelligence או System Visual Intelligence, החבילות:

• [C-4-1] חובה לעמוד בכל הדרישות שמפורטות להטמעות במכשירים בקטעים 9.8.6 תיעוד תוכן 9.8.6 נתונים ברמת מערכת ההפעלה ונתונים סביבתיים ו-9.8.15 הטמעות API ב-Sandbox.

• [C-4-2] אסור שתהיה לאפליקציה הרשאה android.permission.INTERNET. ההמלצה הזו מחמירה יותר מההמלצה 'מומלץ בחום' שמפורטת בקטע 9.8.6.
• [C-4-3] אסור לשייך לאפליקציות אחרות, מלבד אפליקציות המערכת הבאות: Bluetooth,‏ Contacts,‏ Media,‏ Telephony,‏ SystemUI ורכיבים שמספקים ממשקי API לאינטרנט. הדרישה הזו מחמירה יותר מהדרישה 'מומלץ מאוד' שמפורטת בקטע 9.8.6.

יצירת דרישות חדשות

אם הטמעות המכשירים כוללות אפליקציית ברירת מחדל שתומכת ב-VoiceInteractionService, הן:

• [C-5-1] אסור להקצות את ACCESS_FINE_LOCATION כברירת המחדל לאפליקציה הזו.

סיום הדרישות החדשות

9.2. בידוד של UID ותהליכים

הטמעות במכשירים:

• [C-0-1] חובה לתמוך במודל ארגז החול של אפליקציות Android, שבו כל אפליקציה פועלת בתור UID ייחודי בסגנון Unix ובתהליך נפרד.
• [C-0-2] חובה לתמוך בהרצה של כמה אפליקציות בתור אותו מזהה משתמש ב-Linux, בתנאי שהאפליקציות נוצרו ונחתמו כראוי, כפי שמוגדר בחומר העזר בנושא אבטחה והרשאות.

9.3. הרשאות למערכת הקבצים

הטמעות במכשירים:

• [C-0-1] חובה לתמוך במודל ההרשאות של Android לגישה לקבצים, כפי שמוגדר בחומר העזר בנושא אבטחה והרשאות.

9.4. סביבות הפעלה חלופיות

הטמעות במכשירים חייבות לשמור על עקביות של מודל האבטחה וההרשאות של Android, גם אם הן כוללות סביבות זמן ריצה שמריצות אפליקציות באמצעות תוכנה או טכנולוגיה אחרת מלבד פורמט Dalvik Executable או קוד מקורי. במילים אחרות:

• [C-0-1] סביבות זמן ריצה חלופיות חייבות להיות אפליקציות ל-Android, ולעמוד במודל האבטחה הרגיל של Android, כפי שמתואר במקום אחר בסעיף 9.

• [C-0-2] אסור להעניק לסביבות זמן ריצה חלופיות גישה למשאבים שמוגנים באמצעות הרשאות שלא נשלחו בבקשה בקובץ AndroidManifest.xml של סביבת זמן הריצה, באמצעות המנגנון <uses-permission>.

• [C-0-3] אסור לסביבות זמן ריצה חלופיות לאפשר לאפליקציות להשתמש בתכונות שמוגנות על ידי הרשאות Android המוגבלות לאפליקציות מערכת.

• [C-0-4] סביבות זמן ריצה חלופיות חייבות לפעול בהתאם למודל של ארגז החול של Android, ואפליקציות שמותקנות באמצעות סביבת זמן ריצה חלופית אסור להשתמש שוב בארגז החול של אפליקציה אחרת שמותקנת במכשיר, מלבד באמצעות המנגנונים הרגילים של Android למזהה משתמש משותף ולאימות באמצעות אישור חתימה.

• [C-0-5] אסור להפעיל סביבות זמן ריצה חלופיות עם גישה לקופסאות החול התואמות לאפליקציות אחרות ל-Android, או להעניק להן גישה לקופסאות החול האלה, או לקבל גישה מהן.

• [C-0-6] אסור להפעיל סביבות זמן ריצה חלופיות עם הרשאות של סופר-משתמש (root) או של מזהה משתמש אחר, או להעניק להן הרשאות כאלה, או להעניק אותן לאפליקציות אחרות.

• [C-0-7] כשקבצי .apk של סביבות זמן ריצה חלופיות נכללים בתמונת המערכת של הטמעות המכשיר, חובה לחתום עליה באמצעות מפתח שונה מהמפתח שמשמש לחתימה על אפליקציות אחרות שכלולות בהטמעות המכשיר.

• [C-0-8] כשמתקינים אפליקציות, סביבות זמן ריצה חלופיות חייבות לקבל הסכמה מהמשתמשים להרשאות Android שבהן האפליקציה משתמשת.

• [C-0-9] כשאפליקציה צריכה להשתמש במשאב של מכשיר שיש לו הרשאה תואמת ב-Android (כמו מצלמה, GPS וכו'), סביבת זמן הריצה החלופית חייבת להודיע למשתמש שהאפליקציה תהיה מסוגלת לגשת למשאב הזה.

• [C-0-10] כשסביבת זמן הריצה לא מתעדת את יכולות האפליקציה באופן הזה, סביבת זמן הריצה חייבת לרשום את כל ההרשאות שבהן זמן הריצה עצמו מחזיק בזמן התקנת כל אפליקציה באמצעות זמן הריצה הזה.

• בסביבות זמן ריצה חלופיות, צריך להתקין אפליקציות דרך PackageManager בסביבות חול נפרדות ל-Android (מזהי משתמשים ב-Linux וכו').

• סביבות זמן ריצה חלופיות עשויות לספק ארגז חול אחד של Android שכל האפליקציות שמשתמשות בסביבת זמן הריצה החלופית משתפות.

9.5. תמיכה בכמה משתמשים

ב-Android יש תמיכה במספר משתמשים, ותמיכה בבידוד מלא של משתמשים וביצירת עותקים משובטים של פרופילי משתמשים עם בידוד חלקי(כלומר פרופיל משתמש נוסף אחד מסוג android.os.usertype.profile.CLONE).

• אפשר להפעיל את התכונה 'שימוש בכמה משתמשים' בהטמעות של מכשירים, אבל לא מומלץ לעשות זאת אם הם משתמשים במדיה נשלפת לאחסון חיצוני ראשי.

אם הטמעות במכשירים כוללות תמיכה בכמה משתמשים, הן:

• [C-1-2] חובה להטמיע לכל משתמש מודל אבטחה שתואם למודל האבטחה של פלטפורמת Android, כפי שמוגדר במסמך העזרה בנושא אבטחה והרשאות בממשקי ה-API.
• [C-1-3] חובה שיהיה לכל מכונה של משתמש ספריות נפרדות ומבודדות של אחסון משותף לאפליקציות (נקראות גם /sdcard).
• [C-1-4] חובה לוודא שאפליקציות שבבעלות משתמש מסוים שפועלות בשם המשתמש הזה לא יכולות להציג רשימה של קבצים שבבעלות משתמש אחר, לקרוא אותם או לכתוב בהם, גם אם הנתונים של שני המשתמשים מאוחסנים באותו נפח אחסון או באותה מערכת קבצים.
• [C-1-5] חובה להצפין את התוכן של כרטיס ה-SD כשהאפשרות של משתמשים מרובים מופעלת באמצעות מפתח שמאוחסן רק במדיה לא נשלפת שרק למערכת יש גישה אליה, אם הטמעות המכשיר משתמשות במדיה נשלפת לממשקי ה-API של האחסון החיצוני. מכיוון שהשינוי הזה ימנע ממחשבים מארחים לקרוא את המדיה, תצטרכו להעביר את הטמעות המכשירים ל-MTP או למערכת דומה כדי לספק למחשבים מארחים גישה לנתונים של המשתמש הנוכחי.

אם הטמעות במכשירים כוללות תמיכה בכמה משתמשים, כל המשתמשים, מלבד משתמשים שנוצרו במיוחד להפעלת שתי מכונות של אותה אפליקציה, יכולים:

• [C-2-1] חובה שיהיה לכל מכונה של משתמש ספריות נפרדות ומבודדות של אחסון משותף לאפליקציות (נקראות גם ‎/sdcard).
• [C-2-2] חובה לוודא שאפליקציות שבבעלות משתמש מסוים שפועלות בשם המשתמש הזה לא יכולות להכין רשימה של קבצים שבבעלות משתמש אחר, לקרוא אותם או לכתוב בהם, גם אם הנתונים של שני המשתמשים מאוחסנים באותו נפח אחסון או באותה מערכת קבצים.

הטמעות במכשירים עשויות ליצור פרופיל משתמש נוסף אחד מסוג android.os.usertype.profile.CLONE מול המשתמש הראשי (ובאופן בלעדי מול המשתמש הראשי) לצורך הפעלת שתי מכונות של אותה אפליקציה. שתי המכונות האלה משתפות אחסון מבודד חלקית, מוצגות למשתמש הקצה במרכז האפליקציות בו-זמנית ומופיעות באותה תצוגה של הפריטים האחרונים. לדוגמה, אפשר להשתמש באפשרות הזו כדי לתמוך במשתמש שמתקין שני מופעים נפרדים של אפליקציה אחת במכשיר עם שני כרטיסי SIM.

אם הטמעות במכשירים יוצרות את פרופיל המשתמש הנוסף שתואר למעלה, הן:

• [C-3-1] חובה לספק גישה רק לאחסון או לנתונים שכבר יש גישה אליהם בפרופיל המשתמש הראשי, או שבבעלות ישירה של פרופיל המשתמש הנוסף.
• [C-3-2] אסור להגדיר את זה כפרופיל עבודה.
• [C-3-3] חובה להפריד בין ספריות של נתונים פרטיים של אפליקציות לבין חשבון המשתמש הראשי.
• [C-3-4] אסור לאפשר ליצור את פרופיל המשתמש הנוסף אם כבר הוקצה בעל מכשיר (ראו סעיף 3.9.1), או לאפשר הקצאה של בעל מכשיר בלי להסיר קודם את פרופיל המשתמש הנוסף.

יצירת דרישות חדשות

אם הטמעות במכשירים יוצרות את פרופיל המשתמש הנוסף שתואר למעלה, הן:

• [C-4-5] חובה להבדיל באופן חזותי בין סמלי האפליקציות של שתי המופעים כשהסמלים מוצגים למשתמשים.
• [C-4-6] חובה לספק למשתמשים אפשרות למחוק את כל נתוני הפרופיל של העותק המשויך.
• [C-4-7] חובה להסיר את כל האפליקציות המשובצות, למחוק את הספריות של נתוני האפליקציות הפרטיות ואת התוכן שלהן, ולמחוק את נתוני הפרופיל המשובץ כשהמשתמש בוחר למחוק את כל נתוני הפרופיל המשובץ.
• צריך להציג למשתמש הודעה עם בקשה למחוק את כל הנתונים של פרופיל ההעתקה כשמוחקים את אפליקציית ההעתקה האחרונה.
• [C-4-8] חובה להודיע למשתמש שנתוני האפליקציה יימחקו כשאפליקציית העותקים תוסר, או לספק למשתמשים אפשרות לשמור את נתוני האפליקציה כשהאפליקציה תוסר מהמכשיר.
• [C-4-9] חובה למחוק את הספריות של נתוני האפליקציה הפרטיים ואת התוכן שלהן, כשהמשתמש בוחר למחוק את הנתונים במהלך הסרת האפליקציה.

• [C-4-1] חובה לאפשר לאפליקציות של המשתמש הראשי במכשיר לטפל בכוונות הבאות שמקורן בפרופיל הנוסף:

  • Intent.ACTION_VIEW
  • Intent.ACTION_SENDTO
  • Intent.ACTION_SEND
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT
  • Intent.ACTION_INSERT_OR_EDIT
  • Intent.ACTION_SEND_MULTIPLE
  • Intent.ACTION_PICK
  • Intent.ACTION_GET_CONTENT
  • MediaStore.ACTION_IMAGE_CAPTURE
  • MediaStore.ACTION_VIDEO_CAPTURE

• [C-4-2] חובה להעביר בירושה את כל ההגבלות על משתמשים במדיניות המכשיר ואת ההגבלות שנבחרו שלא על משתמשים(הרשימה מופיעה בהמשך) שחלות על המשתמש הראשי במכשיר לפרופיל המשתמש הנוסף הזה.

  • setScreenCaptureDisabled
  • setAccountManagementDisabled
  • setCameraDisabled
  • setPermittedInputMethods
  • setApplicationHidden
  • setPersonalAppsSuspended

• [C-4-3] חובה לאפשר כתיבת אנשי קשר מהפרופיל הנוסף הזה רק באמצעות הכוונות הבאות:

  • ContactsContract.Intents.Insert.ACTION
  • Intent.ACTION_PICK
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT_OR_EDIT

• [C-4-4] אסור להפעיל סנכרון של אנשי קשר באפליקציות שפועלות בפרופיל המשתמש הנוסף הזה.

• [C-4-14] חובה להגדיר הרשאות נפרדות לניהול האחסון של האפליקציות שפועלות בפרופיל הנוסף הזה

• [C-4-5] חובה לאפשר לאפליקציות בפרופיל הנוסף שיש להן פעילות במרכז האפליקציות לגשת רק לאנשי קשר שכבר יש להם גישה לפרופיל ההורה של המשתמש.

סיום הדרישות החדשות

9.6. אזהרה לגבי SMS פרימיום

ב-Android יש תמיכה באזהרה למשתמשים על כל הודעת SMS בתשלום שיוצאת. הודעות Premium SMS הן הודעות טקסט שנשלחות לשירות רשום אצל ספק, שעשויות לגרום לחיוב של המשתמש.

אם הטמעות במכשירים מצהירות על תמיכה ב-android.hardware.telephony, הן:

• [C-1-1] חובה להזהיר את המשתמשים לפני שליחת הודעת SMS למספרים שזוהו באמצעות ביטויים רגולריים שהוגדרו בקובץ /data/misc/sms/codes.xml במכשיר. ב-Android Open Source Project (פרויקט קוד פתוח של Android) יש הטמעה שעומדת בדרישות האלה.

9.7. תכונות אבטחה

הטמעות במכשירים חייבות להבטיח תאימות לתכונות האבטחה גם בליבה וגם בפלטפורמה, כפי שמתואר בהמשך.

ארגז החול של Android כולל תכונות שמשתמשות במערכת בקרת הגישה (MAC) של Security-Enhanced Linux‏ (SELinux), ב-seccomp sandboxing ובתכונות אבטחה אחרות בליבה של Linux. הטמעות במכשירים:

• [C-0-1] חובה לשמור על תאימות לאפליקציות קיימות, גם אם SELinux או תכונות אבטחה אחרות מוטמעות מתחת למסגרת Android.
• [C-0-2] אסור שיהיה לממשק המשתמש של האפליקציה מראה גלוי כשמתגלה הפרת אבטחה ונחסמת בהצלחה על ידי תכונת האבטחה שמוטמעת מתחת למסגרת של Android, אבל יכול להיות שיהיה לממשק המשתמש מראה גלוי כשמתרחשת הפרת אבטחה שלא נחסמה וכתוצאה מכך מתרחשת ניצול לרעה מוצלח.
• [C-0-3] אסור לאפשר למשתמש או למפתח האפליקציה להגדיר את SELinux או תכונות אבטחה אחרות שמוטמעות מתחת למסגרת של Android.
• [C-0-4] אסור לאפשר לאפליקציה שיכולה להשפיע על אפליקציה אחרת דרך ממשק API (כמו Device Administration API) להגדיר מדיניות שמפרה את התאימות.
• [C-0-5] חובה לפצל את מסגרת המדיה למספר תהליכים כדי שניתן יהיה להעניק גישה מצומצמת יותר לכל תהליך, כפי שמתואר באתר של Android Open Source Project.
• [C-0-6] חובה להטמיע מנגנון של ארגז חול לאפליקציות בליבה שמאפשר סינון של קריאות למערכת באמצעות מדיניות שניתן להגדיר מתוכניות עם מספר רב של שרשורים. הפרויקט של Android Open Source עומד בדרישות האלה באמצעות הפעלת seccomp-BPF עם סנכרון של קבוצת חוטים (TSYNC), כפי שמתואר בקטע Kernel Configuration באתר source.android.com.

תכונות שלמות הליבה והגנה עצמית הן חלק בלתי נפרד מאבטחת Android. הטמעות במכשירים:

• [C-0-7] חובה להטמיע מנגנוני הגנה מפני גלישת חוצץ במחסנית הליבה. דוגמאות למנגנונים כאלה הן CC_STACKPROTECTOR_REGULAR ו-CONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] חובה להטמיע הגנות מחמירות על זיכרון הליבה, כך שקוד שניתן להריץ יהיה לקריאה בלבד, נתונים לקריאה בלבד לא ניתנים להריצה ולא ניתן לשנות אותם, ונתונים שניתן לשנות לא ניתנים להריצה (למשל CONFIG_DEBUG_RODATA או CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] חובה להטמיע בדיקה של גבולות גודל אובייקטים סטטיים ודינמיים של עותקים בין מרחב המשתמש למרחב הליבה (למשל CONFIG_HARDENED_USERCOPY) במכשירים ששווקו במקור עם רמת API 28 ואילך.
• [C-0-10] אסור להריץ זיכרון במרחב המשתמש כשמפעילים במצב הליבה (למשל, PXN בחומרה או זיכרון ממולא באמצעות CONFIG_CPU_SW_DOMAIN_PAN או CONFIG_ARM64_SW_TTBR0_PAN) במכשירים ששווקו במקור עם רמת API 28 ואילך.
• [C-0-11] אסור לקרוא או לכתוב בזיכרון של מרחב המשתמש בליבה, מחוץ לממשקי API רגילים של גישה להעתקת משתמש (למשל, PAN של חומרה או זיכרון שמומר באמצעות CONFIG_CPU_SW_DOMAIN_PAN או CONFIG_ARM64_SW_TTBR0_PAN) במכשירים ששווקו במקור עם API ברמה 28 ואילך.
• [C-0-12] חובה להטמיע בידוד של טבלת דפי הליבה אם החומרה חשופה לנקודת החולשה CVE-2017-5754 בכל המכשירים ששווקו במקור עם רמת API 28 ואילך (למשל CONFIG_PAGE_TABLE_ISOLATION או CONFIG_UNMAP_KERNEL_AT_EL0).

• [C-0-13] חובה להטמיע הקשחת חיזוי הסתעפויות אם החומרה חשופה ל-CVE-2017-5715 בכל המכשירים ששווקו במקור עם רמת API‏ 28 ואילך (למשל, CONFIG_HARDEN_BRANCH_PREDICTOR).

• [C-SR-1] מומלץ מאוד לסמן את נתוני הליבה שנכתבים רק במהלך האתחול כקריאה בלבד אחרי האתחול (למשל __ro_after_init).

• [C-SR-2] מומלץ מאוד לבצע רנדומיזציה של הפריסה של קוד הליבה והזיכרון, ולהימנע מחשיפות שעלולות לפגוע ברנדומיזציה (למשל, CONFIG_RANDOMIZE_BASE עם אנטרופיה של bootloader דרך /chosen/kaslr-seed Device Tree node או EFI_RNG_PROTOCOL).

• [C-SR-3] מומלץ מאוד להפעיל את תקינות זרימת הבקרה (CFI) בליבה כדי לספק הגנה נוספת מפני התקפות של שימוש חוזר בקוד (למשל CONFIG_CFI_CLANG ו-CONFIG_SHADOW_CALL_STACK).

• [C-SR-4] מומלץ מאוד לא להשבית את התכונות Control-Flow Integrity‏ (CFI),‏ Shadow Call Stack‏ (SCS) או Integer Overflow Sanitization‏ (IntSan) ברכיבים שבהם הן מופעלות.

• [C-SR-5] מומלץ מאוד להפעיל את CFI, ‏ SCS ו-IntSan לכל רכיב נוסף במרחב המשתמש שחשוף לאיומי אבטחה, כפי שמוסבר במאמרים CFI ו-IntSan.

• [C-SR-6] מומלץ מאוד להפעיל את האיניציאליזציה של הסטאק בליבה כדי למנוע שימוש במשתנים מקומיים שלא עברו את תהליך האיניציאליזציה (CONFIG_INIT_STACK_ALL או CONFIG_INIT_STACK_ALL_ZERO). בנוסף, לא מומלץ להניח שהערך שבו משתמש המהדר הוא הערך שבו משתמשים המשתנים המקומיים.

• [C-SR-7] מומלץ מאוד להפעיל את האינטליקציה של אשכול בתוך הליבה כדי למנוע שימוש בהקצאות של אשכול ללא אינטליקציה (CONFIG_INIT_ON_ALLOC_DEFAULT_ON), ואסור להניח שהערך שבו הליבה משתמשת כדי לאתחל את ההקצאות האלה הוא הערך הנכון.

אם הטמעות במכשירים משתמשות בליבה של Linux שיכולה לתמוך ב-SELinux, הן:

• [C-1-1] חובה להטמיע את SELinux.
• [C-1-2] חובה להגדיר את SELinux למצב אכיפה גלובלי.
• [C-1-3] חובה להגדיר את כל הדומיינים במצב אכיפה. אסור להשתמש בדומיינים במצב הרשאות רחבות, כולל דומיינים ספציפיים למכשיר או לספק.
• [C-1-4] אסור לשנות, להשמיט או להחליף את כללי neverallow שנמצאים בתיקייה system/sepolicy שסופקו ב-Android Open Source Project (AOSP) ב-upstream, וצריך לבצע הידור של המדיניות עם כל כללי neverallow הקיימים, גם לדומיינים של AOSP SELinux וגם לדומיינים ספציפיים למכשיר או לספק.
• [C-1-5] חובה להריץ אפליקציות של צד שלישי שמטרגטות API ברמה 28 ואילך בארגזות חול של SELinux לכל אפליקציה, עם הגבלות SELinux לכל אפליקציה על ספריית הנתונים הפרטית של כל אפליקציה.
• צריך לשמור על מדיניות ברירת המחדל של SELinux שסופקת בתיקייה system/sepolicy של Android Open Source Project ב-upstream, ולהוסיף למדיניות הזו רק את ההגדרות הספציפיות למכשיר.

אם בהטמעות במכשירים נעשה שימוש בליבה שאינה Linux או ב-Linux ללא SELinux, הן:

• [C-2-1] חובה להשתמש במערכת חובה לבקרת גישה ששווה ערך ל-SELinux.

אם הטמעות של מכשירים משתמשות במכשירי קלט/פלט שיכולים לבצע DMA, הן:

• [C-SR-9] מומלץ מאוד לבודד כל מכשיר קלט/פלט שיכול לבצע DMA באמצעות IOMMU (למשל ARM SMMU).

מערכת Android מכילה כמה תכונות של הגנה לעומק, שהן חלק בלתי נפרד מאבטחת המכשיר. בנוסף, אנחנו מתמקדים ב-Android בהפחתת קבוצות מפתח של באגים נפוצים שתורמים לאיכות ולבטיחות ירודות.

כדי לצמצם את מספר הבאגים בזיכרון, הטמעות במכשירים:

• [C-SR-10] מומלץ מאוד לבדוק את הקוד באמצעות כלים לזיהוי שגיאות בזיכרון במרחב המשתמש, כמו MTE למכשירי ARMv9,‏ HWASan למכשירי ARMv8+ או ASan לסוגים אחרים של מכשירים.
• [C-SR-11] מומלץ מאוד לבדוק אותם באמצעות כלים לזיהוי שגיאות בזיכרון הליבה, כמו KASAN‏ (CONFIG_KASAN,‏ CONFIG_KASAN_HW_TAGS למכשירי ARMv9,‏ CONFIG_KASAN_SW_TAGS למכשירי ARMv8 או CONFIG_KASAN_GENERIC לסוגים אחרים של מכשירים).
• [C-SR-12] מומלץ מאוד להשתמש בכלים לזיהוי שגיאות זיכרון בסביבת הייצור, כמו MTE,‏ GWP-ASan ו-KFENCE.

אם הטמעות במכשירים משתמשות ב-TEE שמבוסס על Arm TrustZone, הן:

• [C-SR-13] מומלץ מאוד להשתמש בפרוטוקול סטנדרטי לשיתוף זיכרון בין Android ל-TEE, כמו Arm Firmware Framework for Armv8-A‏ (FF-A).
• [C-SR-14] מומלץ מאוד להגביל אפליקציות מהימנות לגישה רק לזיכרון ששותף איתן באופן מפורש באמצעות הפרוטוקול שלמעלה. אם המכשיר תומך ברמת החריגה Arm S-EL2, מנהל המחיצות המאובטח אמור לאכוף אותה. אחרת, המערכת של TEE OS צריכה לאכוף את זה.

יצירת דרישות חדשות

טכנולוגיית Memory Safety היא טכנולוגיה שמפחיתה לפחות את סוגי הבאגים הבאים עם סבירות גבוהה (מעל 90%) באפליקציות שמשתמשות באפשרות המניפסט android:memtagMode:

• חריגה ממאגר הנתונים הזמני של אשכול
• שימוש אחרי תקופת הניסיון
• double free
• wild free (ללא מצביע שאינו malloc)

הטמעות במכשירים:

• [C-SR-15] מומלץ מאוד להגדיר את ro.arm64.memtag.bootctl_supported.

אם הטמעות של מכשירים מגדירות את מאפיין המערכת ro.arm64.memtag.bootctl_supported כ-true, הן:

• [C-3-1] חובה לאפשר למאפיין המערכת arm64.memtag.bootctl לקבל רשימה מופרדת בפסיקים של הערכים הבאים, כך שהאפקט הרצוי יחול בהפעלה מחדש הבאה:

  • memtag: טכנולוגיית Memory Safety כפי שהוגדרה למעלה מופעלת
  • memtag-once: טכנולוגיית Memory Safety כפי שהוגדרה למעלה מופעלת באופן זמני ומושבתת באופן אוטומטי בהפעלה מחדש הבאה
  • memtag-off: טכנולוגיית Memory Safety כפי שהוגדרה למעלה מושבתת

• [C-3-2] חובה לאפשר למשתמש המעטפת להגדיר את arm64.memtag.bootctl.

• [C-3-3] חובה לאפשר לכל תהליך לקרוא את arm64.memtag.bootctl.

• [C-3-4] חובה להגדיר את arm64.memtag.bootctl למצב המבוקש הנוכחי במהלך האתחול, וגם לעדכן את המאפיין, אם ההטמעה במכשיר מאפשרת לשנות את המצב בלי לשנות את מאפיין המערכת.

• [C-SR-16] מומלץ מאוד להציג הגדרת פיתוח שמגדירה את memtag-once ומפעילה מחדש את המכשיר. באמצעות מנהל אתחול תואם, Android Open Source Project עומד בדרישות שלמעלה באמצעות פרוטוקול מנהל האתחול של MTE.

• [C-SR-17] מומלץ מאוד להציג הגדרה בתפריט ההגדרות של האבטחה שמאפשרת למשתמש להפעיל את memtag.

סיום הדרישות החדשות

9.8. פרטיות

9.8.1. היסטוריית השימוש

מערכת Android שומרת את היסטוריית הבחירות של המשתמש ומנהלת את ההיסטוריה הזו באמצעות UsageStatsManager.

הטמעות במכשירים:

• [C-0-1] חובה לשמור תקופת שמירה סבירה של היסטוריית המשתמש הזו.
• [C-SR-1] מומלץ מאוד לשמור על תקופת השמירה של 14 ימים כפי שמוגדרת כברירת מחדל בהטמעת AOSP.

מערכת Android שומרת את אירועי המערכת באמצעות המזהים StatsLog, ומנהלת את ההיסטוריה הזו באמצעות StatsManager ו-IncidentManager System API.

הטמעות במכשירים:

• [C-0-2] חובה לכלול רק את השדות שמסומנים ב-DEST_AUTOMATIC בדוח התקרית שנוצר על ידי הכיתה System API‏ IncidentManager.
• [C-0-3] אסור להשתמש במזהי האירועים של המערכת כדי לתעד ביומן אירועים אחרים מלבד אלה שמפורטים במסמכי ה-SDK של StatsLog. אם אירועי מערכת נוספים מתועדים ביומן, יכול להיות שייעשה בהם שימוש במזהה אטום אחר בטווח שבין 100,000 ל-200,000.

9.8.2. מתבצעת הקלטה

הטמעות במכשירים:

• [C-0-1] אסור לטעון מראש או להפיץ רכיבי תוכנה מוכנים לשימוש ששולחים את המידע הפרטי של המשתמש (למשל, הקשות על המקלדת, טקסט שמוצג במסך, דוח באג) מהמכשיר ללא הסכמת המשתמש או לנקות התראות מתמשכות.
• [C-0-2] חובה להציג אזהרה למשתמש ולקבל הסכמה מפורשת מהמשתמש לצילום של מידע אישי רגיש שמוצג במסך של המשתמשהפעלה שכוללת בדיוק את אותה ההודעה כמו ב-AOSP בכל פעם שנפתחת סשן לצילום המסך העברה או הקלטת מסך מופעלת באמצעות MediaProjection.createVirtualDisplay(),‏ VirtualDeviceManager.createVirtualDisplay() או ממשקי API קנייניים. אסור לספק למשתמשים אפשרות להשבית את הצגת הסכמת המשתמש בעתיד.
• [C-0-3] חובה להציג התראה מתמשכת למשתמש בזמן שההעברה (cast) של המסך או הקלטת המסך מופעלות. כדי לעמוד בדרישות האלה, ב-AOSP מוצג סמל של התראה מתמשכת בשורת הסטטוס.

יצירת דרישות חדשות

• [C-SR-1] מומלץ מאוד להציג אזהרה למשתמשים. ההודעה צריכה להיות זהה להודעה שמופעלת ב-AOSP, אבל אפשר לשנות אותה כל עוד ההודעה מזהירה בבירור את המשתמש שכל מידע אישי רגיש במסך שלו מתועד.

• [C-0-4] אסור לספק למשתמשים אפשרות להשבית בקשות עתידיות לקבלת הסכמה של המשתמשים לצילום המסך, אלא אם הסשן התחיל על ידי אפליקציית מערכת שהמשתמש העניק לה הרשאה associate() באמצעות android.app.role.COMPANION_DEVICE_APP_STREAMING או באמצעות פרופיל המכשיר android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING.

  סיום הדרישות החדשות

אם הטמעות במכשירים כוללות פונקציונליות במערכת שמצלמת את התוכן שמוצג במסך ו/או מתעדת את מקור האודיו שמוצג במכשיר, ולא באמצעות System API‏ ContentCaptureService או אמצעים קנייניים אחרים שמתוארים בקטע 9.8.6 נתונים ברמת מערכת וסביבה, הן:

• [C-1-1] חובה להציג למשתמש התראה מתמשכת בכל פעם שהפונקציונליות הזו מופעלת ומתבצעת צילום או הקלטה.

אם הטמעות במכשירים כוללות רכיב מופעל מראש שיכול להקליט אודיו סביבתי ו/או להקליט את האודיו שמופעל במכשיר כדי להסיק מידע שימושי על ההקשר של המשתמש, הן:

• [C-2-1] אסור לאחסן באחסון קבוע במכשיר או לשדר מהמכשיר את האודיו הגולמי המוקלט או כל פורמט שאפשר להמיר בחזרה לאודיו המקורי או לעותק כמעט זהה, אלא בהסכמה מפורשת של המשתמש.

'אינדיקטור מיקרופון' הוא תצוגה במסך שגלויה למשתמש כל הזמן ולא ניתן להסתיר אותה, ומאפשרת למשתמשים להבין שהמיקרופון פועל(באמצעות טקסט, צבע, סמל או שילוב ייחודי כלשהו).

'חיווי מצלמה' מתייחס לתצוגה במסך שגלויה תמיד למשתמש ולא ניתן להסתיר אותה, ומאפשרת למשתמשים להבין שהמצלמה פועלת (באמצעות טקסט, צבע, סמל או שילוב ייחודי כלשהו).

אחרי השנייה הראשונה שבה הוא מוצג, האינדיקטור יכול להשתנות מבחינה חזותית, למשל להפוך לקטן יותר, ולא חייב להופיע כפי שהוצג במקור והובן.

אפשר למזג את האינדיקטור של המיקרופון עם אינדיקטור של מצלמה מוצגת באופן פעיל, בתנאי שטקסט, סמלים או צבעים מציינים למשתמש שהשימוש במיקרופון התחיל.

אפשר למזג את האינדיקטור של המצלמה עם אינדיקטור של מיקרופון פעיל, בתנאי שטקסט, סמלים או צבעים יציינו למשתמש שהשימוש במצלמה התחיל.

אם הטמעות של מכשירים מכריזות על android.hardware.microphone, הן:

• [C-SR-1] מומלץ מאוד להציג אינדיקטור של מיקרופון כשאפליקציה ניגשת לנתוני אודיו מהמיקרופון, אבל לא כשרק HotwordDetectionService,‏ SOURCE_HOTWORD,‏ ContentCaptureService או אפליקציות עם התפקידים שמפורטים בקטע 9.1 הרשאות עם מזהה CDD [C-3-X] ניגשים למיקרופון. .
• [C-SR-2] מומלץ מאוד להציג את רשימת האפליקציות האחרונות והפעילות באמצעות המיקרופון, כפי שהיא מוחזרת מ-PermissionManager.getIndicatorAppOpUsageData(), יחד עם הודעות שיוך שמשויכות אליהן.
• [C-SR-3] מומלץ מאוד לא להסתיר את האינדיקטור של המיקרופון באפליקציות מערכת שיש להן ממשקי משתמש גלויים או אינטראקציה ישירה עם משתמשים.

אם הטמעות של מכשירים מכריזות על android.hardware.camera.any, הן:

• [C-SR-4] מומלץ מאוד להציג אינדיקטור מצלמה כשאפליקציה ניגשת לנתוני מצלמה בשידור חי, אבל לא כשהגישה למצלמה היא רק על ידי אפליקציות עם התפקידים שמפורטים בקטע 9.1 הרשאות עם מזהה CDD‏ [C-3-X].
• [C-SR-5] מומלץ מאוד להציג את האפליקציות האחרונות והאפליקציות הפעילות באמצעות המצלמה, כפי שהיא מוחזרת מ-PermissionManager.getIndicatorAppOpUsageData(), יחד עם הודעות שיוך שמשויכות אליהן.
• [C-SR-6] מומלץ מאוד לא להסתיר את האינדיקטור של המצלמה באפליקציות מערכת שיש להן ממשקי משתמש גלויים או אינטראקציה ישירה עם משתמשים.

9.8.3. קישוריות

אם להטמעות של המכשירים יש יציאת USB עם תמיכה במצב USB ציוד היקפי, הן:

• [C-1-1] חובה להציג ממשק משתמש עם בקשה לקבלת הסכמה מהמשתמש לפני שמאפשרים גישה לתוכן של האחסון המשותף דרך יציאת ה-USB.

9.8.4. תנועה ברשת

הטמעות במכשירים:

• [C-0-1] חובה להתקין מראש את אותם אישורי Root של מאגר רשות האישורים (CA) המהימן במערכת, כפי שסופקו ב-upstream של פרויקט הקוד הפתוח של Android.
• [C-0-2] חובה לשלוח עם חנות ריקה של רשות אישורים ברמה הבסיסית של משתמש.
• [C-0-3] חובה להציג אזהרה למשתמש על כך שעשוי להיות מעקב אחרי תעבורת הרשת, כשמוסיפים רשות אישור ברמה הבסיסית של משתמש.

אם התנועה במכשיר מנותבת דרך VPN, הטמעות במכשירים:

• [C-1-1] חובה להציג למשתמש אזהרה שמציינת את אחד מהפרטים הבאים:
  • יכול להיות שהתנועה ברשת הזו תהיה במעקב.
  • התנועה ברשת מנותבת דרך אפליקציית ה-VPN הספציפית שמספקת את ה-VPN.

אם להטמעות במכשירים יש מנגנון שמופעל כברירת מחדל ומנתב את תעבורת הנתונים ברשת דרך שרת proxy או שער VPN (לדוגמה, טעינת שירות VPN מראש עם הרשאת android.permission.CONTROL_VPN), הן:

• [C-2-1] חובה לבקש את הסכמת המשתמש לפני הפעלת המנגנון הזה, אלא אם ה-VPN מופעל על ידי בקר מדיניות המכשיר דרך DevicePolicyManager.setAlwaysOnVpnPackage(). במקרה כזה, המשתמש לא צריך לספק הסכמה נפרדת, אבל חובה להודיע לו על כך.

אם הטמעות במכשירים מטמיעות אמצעי להפעלה/השבתה של המשתמשים לפונקציה 'חיבור קבוע ל-VPN' באפליקציית VPN של צד שלישי, הן:

• [C-3-1] חובה להשבית את האפשרות הזו למשתמשים באפליקציות שלא תומכות בשירות VPN שפועל כל הזמן בקובץ AndroidManifest.xml, על ידי הגדרת הערך false למאפיין SERVICE_META_DATA_SUPPORTS_ALWAYS_ON.

9.8.5. מזהי המכשיר

הטמעות במכשירים:

• [C-0-1] חובה למנוע מאפליקציה גישה למספר הסידורי של המכשיר, ובמקרים הרלוונטיים, למספר ה-IMEI/MEID, למספר הסידורי של כרטיס ה-SIM ולמזהה המנוי הבינלאומי לנייד (IMSI), אלא אם היא עומדת באחת מהדרישות הבאות:
  • היא אפליקציה חתומה של ספק שמאומתת על ידי יצרני המכשירים.
  • קיבלה את ההרשאה READ_PRIVILEGED_PHONE_STATE.
  • יש לו הרשאות ספק כפי שמוגדרות במאמר הרשאות ספק של UICC.
  • הוא בעל מכשיר או בעל פרופיל שקיבלו את ההרשאה READ_PHONE_STATE.
  • (למספר סידורי של SIM או ICCID בלבד) קיימת דרישה בתקנות המקומיות שהאפליקציה תזהה שינויים בזהות המנוי.

9.8.6. תיעוד תוכן וחיפוש אפליקציותנתונים ברמת מערכת ההפעלה ונתונים סביבתיים

מערכת Android, באמצעות ממשקי ה-API למערכת ContentCaptureService,‏ AugmentedAutofillService,‏ AppSearchGlobalManager.query או באמצעים קנייניים אחרים, תומכת במנגנון להטמעות במכשירים שמאפשר לתעד את האינטראקציות של נתוני האפליקציות בין האפליקציות למשתמש מידע אישי רגיש:

• טקסט וגרפיקה שעבר רינדור במסך, כולל, בין היתר, התראות ונתוני עזרה דרך AssistStructure API.
• נתוני מדיה, כמו אודיו או וידאו, שהמכשיר הקליט או הפעיל.
• אירועי קלט (למשל מקשים, עכבר, תנועות, קול, וידאו ונגישות).

יצירת דרישות חדשות

• כל מסך או נתונים אחרים שנשלחים למערכת דרך AugmentedAutofillService.
• כל מסך או נתונים אחרים שזמינים דרך API של Content Capture.
• כל מסך או נתונים אחרים שזמינים דרך ה-API של FieldClassificationService
• כל נתוני האפליקציה שהועברו למערכת דרך ה-API של AppSearchManager ואפשר לגשת אליהם דרך AppSearchGlobalManager.query.

סיום הדרישות החדשות

• כל אירוע אחר שהאפליקציה מספקת למערכת דרך API‏ Content Capture או API‏ AppSearchManager, ממשק API ייעודי ל-Android עם יכולות דומות.

• כל טקסט או נתונים אחרים שנשלחים דרך TextClassifier API ל-System TextClassifier, כלומר לשירות המערכת, כדי להבין את משמעות הטקסט וגם כדי ליצור פעולות צפויות הבאות על סמך הטקסט.
• נתונים שנוספו לאינדקס על ידי הטמעת AppSearch בפלטפורמה, כולל, בין היתר, טקסט, גרפיקה, נתוני מדיה או נתונים דומים אחרים.

יצירת דרישות חדשות

• נתוני אודיו שהתקבלו כתוצאה משימוש ב-SpeechRecognizer#onDeviceSpeechRecognizer() על ידי הטמעת Speech Recognizer.
• נתוני אודיו שנאספים ברקע (באופן רציף) דרך AudioRecord,‏ SoundTrigger או ממשקי API אחרים של אודיו, ולא גורמים להצגת אינדיקטור גלוי למשתמש
• נתוני מצלמה שנאספים ברקע (באופן רציף) דרך CameraManager או ממשקי API אחרים של מצלמה, ולא גורמים להצגת אינדיקטור גלוי למשתמש

סיום הדרישות החדשות

אם הטמעות במכשירים מתעדות את הנתונים שלמעלה, הן:

• [C-1-1] חובה להצפין את כל הנתונים האלה כשהם מאוחסנים במכשיר. ההצפנה הזו עשויה להתבצע באמצעות הצפנה מבוססת-קובץ של Android, או באמצעות כל אחד מהצפנים שמפורטים כ-API מגרסה 26 ואילך, כפי שמתואר ב-Cipher SDK.
• [C-1-2] אסור לגבות נתונים גולמיים או נתונים מוצפנים באמצעות שיטות הגיבוי של Android או כל שיטת גיבוי אחרת.
• [C-1-3] חובה לשלוח את כל הנתונים האלה ואת היומן מהמכשיר רק באמצעות מנגנון לשמירה על הפרטיות, אלא אם יש הסכמה מפורשת של המשתמש בכל פעם שהנתונים משותפים. המנגנון לשמירה על הפרטיות מוגדר כ'מנגנונים שמאפשרים רק ניתוח מצטבר ומונעים התאמה של אירועים ביומן או תוצאות נגזרות למשתמשים ספציפיים', כדי למנוע ניתוח של נתונים לכל משתמש (למשל, הטמעה באמצעות טכנולוגיית פרטיות דיפרנציאלית כמו RAPPOR).
• [C-1-4] אסור לשייך נתונים כאלה לזהות משתמש כלשהי (למשל Account) במכשיר, אלא אם קיבלתם הסכמה מפורשת מהמשתמש בכל פעם שהנתונים משויכים.
• [C-1-5] אסור לשתף נתונים כאלה עם רכיבים אחרים של מערכת ההפעלה שלא עומדים בדרישות שמפורטות בקטע הנוכחי (9.8.6 תיעוד תוכן נתונים ברמת מערכת ההפעלה ונתוני סביבה), אלא בהסכמה מפורשת של המשתמש בכל פעם שהנתונים משותפים. אלא אם הפונקציות האלה נוצרות כ-Android SDK API‏ (AmbientContext,‏ HotwordDetectionService).
• [C-1-6] חובה לספק למשתמשים אפשרות למחוק נתונים כאלה שנאספים על ידי ContentCaptureService בהטמעה או באמצעים הקנייניים אם כש הנתונים מאוחסנים במכשיר בצורה כלשהי. אם המשתמש בוחר למחוק את הנתונים, חובה להסיר את כל הנתונים ההיסטוריים שנאספו.
• [C-1-7] חובה לספק למשתמשים אפשרות לבטל את ההסכמה להצגת הנתונים שנאספו דרך AppSearch או באמצעים קנייניים בפלטפורמת Android, למשל במרכז האפליקציות.
• [C-SR-1] Are STRONGLY RECOMMENDED NOT to request the INTERNET permission.
• [C-SR-2] מומלץ מאוד לגשת לאינטרנט רק דרך ממשקי API מובְנים שמגובים בהטמעות קוד פתוח שזמינות לכולם.

יצירת דרישות חדשות

• [C-SR-4] מומלץ מאוד להטמיע אותם באמצעות Android SDK API או מאגר קוד פתוח דומה בבעלות יצרן ציוד מקורי, ו / או לבצע אותם בהטמעה ב-Sandbox (ראו 9.8.15 הטמעות API ב-Sandbox).

סיום הדרישות החדשות

אם הטמעות במכשירים כוללות שירות שמטמיע את System API‏ ContentCaptureService או AppSearchManager.index, או כל שירות קנייני שמתעד את הנתונים כפי שמתואר למעלה, הן:

• [C-2-1] אסור לאפשר למשתמשים להחליף את השירותים באפליקציה או בשירות שאפשר להתקין, וצריך לאפשר רק לשירותים המותקנים מראש לתעד נתונים כאלה.
• [C-2-2] אסור לאפשר לאף אפליקציה, מלבד מנגנון השירותים המובנים, לתעד נתונים כאלה.
• [C-2-3] חובה לספק למשתמש אפשרות להשבית את השירותים.
• [C-2-4] אסור להשמיט את האפשרות של המשתמשים לנהל את ההרשאות ל-Android שנמצאות בידי השירותים, ועליהם לפעול בהתאם למודל ההרשאות של Android כפי שמתואר בקטע 9.1. הרשאה.

• [C-SR-3] מומלץ מאוד להפריד בין השירותים לבין רכיבי מערכת אחרים(למשל, לא לקשר את השירות או לשתף מזהי תהליכים), מלבד במקרים הבאים:

  • טלפוניה, אנשי קשר, ממשק המשתמש של המערכת ומדיה

Android, באמצעות SpeechRecognizer#onDeviceSpeechRecognizer(), מספק את היכולת לבצע זיהוי דיבור במכשיר, בלי מעורבות של הרשת. כל הטמעה של SpeechRecognizer במכשיר חייבת לציית לכללי המדיניות שמפורטים בקטע הזה.

9.8.7. גישה ללוח העריכה

הטמעות במכשירים:

• [C-0-1] אסור להחזיר נתונים חתוכים מהלוח (למשל דרך ה-API‏ ClipboardManager), אלא אם אפליקציית הצד השלישי היא IME ברירת המחדל או שהיא האפליקציה שבה מוקדשת כרגע תשומת הלב.

• [C-0-2] חובה לנקות את נתוני הלוח בתוך 60 דקות לכל היותר ממועד הוספת הנתונים האחרונה ללוח או קריאת הנתונים האחרונה מהלוח.

9.8.8. מיקום

המיקום כולל מידע מהקלאס Location ב-Android( כמו קו רוחב, קו אורך וגובה), וגם מזהים שאפשר להמיר למיקום. המיקום יכול להיות מדויק כמו DGPS (מערכת מיקום גלובלית מדויקת) או פחות מדויק כמו מיקומים ברמת המדינה (כמו המיקום לפי קוד המדינה – MCC – קוד המדינה בנייד).

בהמשך מופיעה רשימה של סוגי מיקומים שמתקבלים ישירות מהמיקום של המשתמש או שאפשר להמיר אותם למיקום של המשתמש. זו לא רשימה מקיפה, אבל היא יכולה לשמש כדוגמה למה שאפשר להסיק מהמיקום באופן ישיר או עקיף:

• GPS/‏GNSS/‏DGPS/‏PPP
  • פתרון למיקום גלובלי, מערכת לוויינים למיקום גלובלי או פתרון דיפרנציאלי למיקום גלובלי
  • הנתונים האלה כוללים גם מדידות GNSS גולמיות וסטטוס GNSS
    • המיקום המדויק יכול להיגזר מהמדידות הגולמיות של GNSS
• טכנולוגיות אלחוטיות עם מזהים ייחודיים, כמו:
  • נקודות גישה ל-Wi-Fi (MAC,‏ BSSID, שם או SSID)
  • Bluetooth/BLE‏ (MAC,‏ BSSID,‏ שם או SSID)
  • UWB‏ (MAC,‏ BSSID,‏ שם או SSID)
  • מזהה של תורן סלולרי (3G, ‏ 4G, ‏ 5G… כולל כל הטכנולוגיות העתידיות של מודם סלולרי שיש להן מזהים ייחודיים)

מקור מידע ראשי הוא ממשקי ה-API של Android שדורשים את ההרשאות ACCESS_FINE_Location או ACCESS_COARSE_Location.

הטמעות במכשירים:

• [C-0-1] אסור להפעיל או להשבית את הגדרת המיקום של המכשיר ואת הגדרות הסריקה של Wi-Fi או Bluetooth ללא הסכמה מפורשת של המשתמש או ללא יזום של המשתמש.
• [C-0-2] חובה לספק למשתמש גישה למידע שקשור למיקום, כולל בקשות מיקום אחרונות, הרשאות ברמת האפליקציה ושימוש בסריקה של Wi-Fi או Bluetooth כדי לקבוע את המיקום.
• [C-0-3] חובה לוודא שהאפליקציה שמשתמשת ב-Emergency Location Bypass API‏ [LocationRequest.setLocationSettingsIgnored()] היא סשן חירום ביוזמת המשתמש (למשל, חיוג למספר חירום או שליחת הודעת טקסט למספר חירום). עם זאת, ברכב יכול להתבצע התחלה של סשן חירום ללא אינטראקציה פעילה של המשתמש במקרה של זיהוי תאונה (למשל, כדי לעמוד בדרישות של eCall).
• [C-0-4] חובה לשמור על היכולת של Emergency Location Bypass API לעקוף את הגדרות המיקום של המכשיר בלי לשנות את ההגדרות.
• [C-0-5] חובה לתזמן התראה שמזכירה למשתמש אחרי שאפליקציה שפועלת ברקע ניגשת למיקום שלו באמצעות ההרשאה [ACCESS_BACKGROUND_LOCATION].

9.8.9. אפליקציות מותקנות

אפליקציות ל-Android שמטרגטות לרמת API 30 ואילך לא יכולות לראות פרטים על אפליקציות מותקנות אחרות כברירת מחדל (מידע נוסף זמין במאמר חשיפת החבילה במסמכי התיעוד של Android SDK).

הטמעות במכשירים:

• [C-0-1] אסור לחשוף לאף אפליקציה שמטרגטת רמת API 30 ומעלה פרטים על אפליקציה אחרת שמותקנת במכשיר, אלא אם האפליקציה כבר יכולה לראות פרטים על האפליקציה האחרת שמותקנת במכשיר דרך ממשקי ה-API המנוהלים. זה כולל, בין היתר, פרטים שנחשפו על ידי ממשקי API מותאמים אישית שנוספו על ידי מי שמטמיע את המכשיר, או פרטים שאפשר לגשת אליהם דרך מערכת הקבצים.
• [C-0-2] אסור לתת לאף אפליקציה גישה לקריאה או לכתיבה של קבצים בספרייה הייעודית והספציפית לאפליקציה באחסון החיצוני. היוצאים מן הכלל היחיד הם:
  • הרשות של ספק האחסון החיצוני (למשל, אפליקציות כמו DocumentsUI).
  • ספק הורדות שמשתמש בסמכויות הספק 'הורדות' כדי להוריד קבצים לאחסון של האפליקציה.
  • אפליקציות פרוטוקול העברת מדיה (MTP) בחתימה של פלטפורמה שמשתמשות בהרשאה בעלת ההרשאות ACCESS_MTP כדי לאפשר העברת קבצים למכשיר אחר.
  • אפליקציות שמתקינות אפליקציות אחרות ויש להן את ההרשאה INSTALL_PACKAGES יכולות לגשת רק לספריות 'obb' לצורך ניהול קובצי ההרחבה של APK.

9.8.10. דוח על באג בקישוריות

אם הטמעות במכשירים מכריזות על דגל התכונה android.hardware.telephony, הן:

• [C-1-1] חובה לתמוך ביצירת דוחות על באגים שקשורים לקישוריות דרך BUGREPORT_MODE_TELEPHONY באמצעות BugreportManager.
• [C-1-2] חובה לקבל הסכמה מהמשתמשים בכל פעם שמשתמשים ב-BUGREPORT_MODE_TELEPHONY כדי ליצור דוח, אסור לבקש מהמשתמשים להביע הסכמה לכל הבקשות העתידיות מהאפליקציה.
• [C-1-3] אסור להחזיר את הדוח שנוצר לאפליקציה המבקשת ללא הסכמה מפורשת של המשתמש.
• [C-1-4] דוחות שנוצרים באמצעות BUGREPORT_MODE_TELEPHONY חייבים לכלול לפחות את הפרטים הבאים:
  • TelephonyDebugService dump
  • TelephonyRegistry dump
  • WifiService dump
  • ConnectivityService dump
  • דמפ של מופע CarrierService של החבילה הקוראת (אם הוא מקושר)
  • מאגר נתונים זמני של יומן הרדיו
  • SubscriptionManagerService dump
• [C-1-5] אסור לכלול את הפרטים הבאים בדוחות שנוצרים:
  • כל מידע שלא קשור ישירות לניפוי באגים שקשור לקישוריות.
  • כל סוג של יומני תנועה של אפליקציות שהותקנו על ידי משתמשים או פרופילים מפורטים של אפליקציות או חבילות שהותקנו על ידי משתמשים (אפשר להשתמש במזהי משתמש, אבל אסור להשתמש בשמות חבילות).
• יכול לכלול מידע נוסף שלא משויך לזהות של משתמש כלשהו. (למשל, יומני ספקים).

אם הטמעות של מכשירים כוללות מידע נוסף (למשל יומני ספקים) בדוחות על באגים, והמידע הזה משפיע על הפרטיות, האבטחה, הסוללה, האחסון או הזיכרון, הן:

• [C-SR-1] מומלץ מאוד להגדיר את ברירת המחדל של הגדרת הפיתוח כ'מושבתת'. כדי לעמוד בדרישות האלה, הטמעת העזר של AOSP כוללת את האפשרות Enable verbose vendor logging בהגדרות הפיתוח, שמאפשרת לכלול בדוחות הבאגים יומני ספקים נוספים שספציפיים למכשיר.

9.8.11. שיתוף של blobs של נתונים

מערכת Android, באמצעות BlobStoreManager, מאפשרת לאפליקציות לתרום blobs של נתונים למערכת כדי לשתף אותם עם קבוצה נבחרת של אפליקציות.

אם הטמעות במכשירים תומכות ב-blobs של נתונים משותפים כפי שמתואר במסמכי התיעוד של ה-SDK, הן:

• [C-1-1] אסור לשתף blobs של נתונים ששייכים לאפליקציות מעבר למה שהן התכוונו לאפשר (כלומר, אסור לשנות את היקף הגישה שמוגדרת כברירת מחדל ואת שאר מצבי הגישה שאפשר לציין באמצעות BlobStoreManager.session#allowPackageAccess(),‏ BlobStoreManager.session#allowSameSignatureAccess() או BlobStoreManager.session#allowPublicAccess()). ההטמעה של AOSP עומדת בדרישות האלה.
• [C-1-2] אסור לשלוח מהמכשיר או לשתף עם אפליקציות אחרות את הגיבוב המאובטח של נתוני ה-blob (שמשמש לבקרת הגישה).

9.8.12. זיהוי מוזיקה

מערכת Android, באמצעות System API MusicRecognitionManager, תומכת במנגנון שמאפשר להטמיע במכשירים בקשות לזיהוי מוזיקה, על סמך הקלטת אודיו, ולהעביר את זיהוי המוזיקה לאפליקציה בעלת הרשאות שמטמיעה את MusicRecognitionService API.

אם הטמעות במכשירים כוללות שירות שמטמיע את System API‏ MusicRecognitionManager או כל שירות קנייני שמעביר נתוני אודיו בסטרימינג כפי שמתואר למעלה, הן:

• [C-1-1] חובה לאכוף שהמבצע של MusicRecognitionManager מחזיק בהרשאה MANAGE_MUSIC_RECOGNITION
• [C-1-2] חובה לאכוף שרק אפליקציה אחת לזיהוי מוזיקה שמותקנת מראש תטמיע את MusicRecognitionService.
• [C-1-3] אסור לאפשר למשתמשים להחליף את MusicRecognitionManagerService או את MusicRecognitionService באפליקציה או בשירות שניתן להתקנה על ידי משתמשים.
• [C-1-4] חובה לוודא שכאשר MusicRecognitionManagerService ניגשת להקלטת האודיו ומעבירה אותה לאפליקציה שמטמיעה את MusicRecognitionService, מתבצע מעקב אחר הגישה לאודיו באמצעות קריאות ל-AppOpsManager.noteOp / startOp.

אם הטמעות של MusicRecognitionManagerService או MusicRecognitionService במכשיר שומרות נתוני אודיו שהוקלטו, הן:

• [C-2-1] אסור לאחסן אודיו גולמי או טביעות אצבע של אודיו בדיסק או בזיכרון למשך יותר מ-14 יום.
• [C-2-2] אסור לשתף נתונים כאלה מחוץ ל-MusicRecognitionService, אלא עם הסכמה מפורשת של המשתמש בכל פעם שהם משותפים.

9.8.13. SensorPrivacyManager

אם הטמעות במכשירים מספקות למשתמש אפשרות תוכנה להשבית את הקלט של המצלמה ו/או המיקרופון בהטמעה במכשיר, הן:

• [C-1-1] חובה להחזיר 'true' בצורה מדויקת בשיטת ה-API הרלוונטית supportsSensorToggle()‎.
• [C-1-2] כשאפליקציה מנסה לגשת למיקרופון או למצלמה חסומים, היא חייבת להציג למשתמש רכיב ממשק משתמש שלא ניתן לסגור, שמציין בבירור שהחיישן חסום ומבקש מהמשתמש לבחור אם להמשיך לחסום אותו או לבטל את החסימה, בהתאם להטמעה של AOSP שעומדת בדרישות האלה.
• [C-1-3] חייב להעביר לאפליקציות רק נתוני מצלמה וקול ריקים (או מזויפים), ולא לדווח על קוד שגיאה בגלל שהמשתמש לא הפעיל את המצלמה או את המיקרופון באמצעות אמצעי ההפעלה שמוצגים למשתמש בהתאם ל-[C-1-2] שלמעלה.

יצירת דרישות חדשות

9.8.14. מנהל פרטי הכניסה

הנושא הוסר.

9.8.15. הטמעות של ממשקי API בארגז חול

Android, באמצעות קבוצה של ממשקי API למעקב אחר משימות, מספק מנגנון לעיבוד נתונים מאובטחים ברמת מערכת ההפעלה ונתוני סביבה. אפשר להקצות עיבוד כזה ל-apk שהותקן מראש עם הרשאות גישה ויכולות תקשורת מוגבלות, שנקרא הטמעת API בארגז חול.

כל הטמעה של API בארגז חול:

• [C-0-1] אסור לבקש את ההרשאה INTERNET.
• [C-0-2] חובה לגשת לאינטרנט רק דרך ממשקי API מובְנים שמגובים בהטמעות קוד פתוח שזמינות לכולם באמצעות מנגנונים לשמירה על הפרטיות, או באופן עקיף דרך ממשקי API של Android SDK. המנגנון לשמירה על הפרטיות מוגדר כ'מנגנונים שמאפשרים רק ניתוח מצטבר ומונעים התאמה של אירועים ביומן או תוצאות נגזרות למשתמשים ספציפיים', כדי למנוע ניתוח נתונים לכל משתמש (למשל, הטמעה באמצעות טכנולוגיית פרטיות דיפרנציאלית כמו RAPPOR).
• [C-0-3] חובה להפריד בין השירותים לבין רכיבי מערכת אחרים (למשל, לא לקשר את השירות או לשתף מזהי תהליכים), מלבד:
  • טלפוניה, אנשי קשר, ממשק המשתמש של המערכת ומדיה
• [C-0-4] אסור לאפשר למשתמשים להחליף את השירותים באפליקציה או בשירות שאפשר להתקין
• [C-0-5] חובה לאפשר רק לשירותים המותקנים מראש לתעד נתונים כאלה. אלא אם יכולת ההחלפה מובנית ב-AOSP (למשל, לאפליקציות של עוזרים דיגיטליים).
• [C-0-6] אסור לאפשר לאפליקציות אחרות מלבד מנגנון השירותים המובנים לקלוט נתונים כאלה. אלא אם יכולת הצילום הזו מוטמעת באמצעות Android SDK API.
• [C-0-7] חובה לספק למשתמש אפשרות להשבית את השירותים.
• [C-0-8] אסור להשמיט את האפשרות של המשתמשים לנהל את ההרשאות ל-Android שנמצאות בידי השירותים, ועליך לפעול בהתאם למודל ההרשאות של Android כפי שמתואר בסעיף 9.1. הרשאה.

9.8.16. נתוני אודיו ומצלמה רציפים

בנוסף לדרישות שמפורטות בקטע 9.8.2 הקלטה, בקטע 9.8.6 נתונים ברמת מערכת ההפעלה ונתונים סביבתיים ובקטע 9.8.15 הטמעות של ממשקי API ב-Sandbox, הטמעות שמשתמשות בנתוני אודיו שנאספים ברקע (באופן רציף) דרך AudioRecord, ‏ SoundTrigger או ממשקי API אחרים של אודיו, או בנתוני מצלמה שנאספים ברקע (באופן רציף) דרך CameraManager או ממשקי API אחרים של מצלמה:

• [C-0-1] חובה לאכוף אינדיקטור תואם (מצלמה ו/או מיקרופון, בהתאם לקטע 9.8.2 הקלטה), אלא אם:
  • הגישה הזו מתבצעת בהטמעה ב-Sandbox (ראו 9.8.15 הטמעת API ב-Sandbox), דרך חבילה שמכילה אחד או יותר מהתפקידים הבאים: System UI Intelligence,‏ System Ambient Audio Intelligence,‏ System Audio Intelligence,‏ System Notification Intelligence,‏ System Text Intelligence או System Visual Intelligence.
  • הגישה מתבצעת דרך ארגז חול, שמוטמע ומאוכח באמצעות מנגנונים ב-AOSP‏ (HotwordDetectionService,‏ WearableSensingService, ‏ VisualQueryDetector).
  • אפליקציית העוזר הדיגיטלי מספקת את SOURCE_HOTWORD כמקור אודיו לצורכי עזרה.
  • הגישה מתבצעת על ידי המערכת ומוטמעת באמצעות קוד פתוח.
• [C-SR-1] מומלץ מאוד לדרוש הסכמה מהמשתמשים לכל פונקציונליות שמשתמשת בנתונים כאלה, ולהשבית אותה כברירת מחדל.
• [C-SR-2] מומלץ מאוד להחיל את אותה טיפול (כלומר לפעול בהתאם להגבלות שמפורטות בקטע 9.8.2 הקלטה, בקטע 9.8.6 נתונים ברמת מערכת ההפעלה ונתוני סביבה, בקטע 9.8.15 הטמעות API ב-Sandbox ובקטע 9.8.16 נתוני אודיו ונתוני מצלמה רציפים) על נתוני מצלמה שמגיעים ממכשיר נייד מרוחק.

אם נתוני המצלמה מסופקים ממכשיר נייד מרחוק, והגישה אליהם מתבצעת בצורה לא מוצפנת מחוץ ל-Android OS, להטמעה ב-sandbox או לפונקציה ב-sandbox שנוצרה על ידי WearableSensingManager, אז:

• [C-1-1] חייב להורות למכשיר הלבישה המרוחק להציג שם אינדיקטור נוסף.

אם המכשירים מספקים יכולת לתקשר עם אפליקציית עוזרת דיגיטלית בלי מילת המפתח שהוקצה לה (טיפול בשאילתות כלליות של משתמשים או ניתוח נוכחות המשתמשים באמצעות המצלמה):

• [C-2-1] חובה לוודא שההטמעה הזו מסופקת על ידי חבילת קוד עם התפקיד android.app.role.ASSISTANT.
• [C-2-2] חובה לוודא שההטמעה הזו משתמשת ב-HotwordDetectionService וגם ב-VisualQueryDetectionService Android APIs.

9.8.17. Telemetry

Android שומר יומני מערכת ויומני אפליקציות באמצעות ממשקי StatsLog API. היומנים האלה מנוהלים באמצעות ממשקי StatsManager API, שבהם אפליקציות מערכת בעלות הרשאות יכולות להשתמש.

בנוסף, StatsManager מספק דרך לאסוף נתונים שמסווגים כנתונים רגישים לפרטיות ממכשירים עם מנגנון לשמירה על הפרטיות. באופן ספציפי, API ‏StatsManager::query מאפשר להריץ שאילתות לגבי קטגוריות מוגבלות של מדדים שמוגדרות ב-StatsLog.

כל הטמעה שמבצעת שאילתות ומאגרת מדדים מוגבלים מ-StatsManager:

• [C-0-1] חייבת להיות האפליקציה/ההטמעה היחידה במכשיר, ולהחזיק בהרשאה READ_RESTRICTED_STATS.
• [C-0-2] חובה לשלוח רק נתוני טלמטריה ויומן של המכשיר באמצעות מנגנון לשמירה על הפרטיות. המנגנון לשמירה על הפרטיות מוגדר בתור "מנגנונים שמאפשרים רק ניתוח מצטבר ומונעים התאמה של אירועים ביומן או תוצאות נגזרות למשתמשים ספציפיים", כדי למנוע ניתוח נתונים לכל משתמש (למשל, הטמעה באמצעות טכנולוגיית פרטיות דיפרנציאלית כמו RAPPOR).
• [C-0-3] אסור לשייך נתונים כאלה לזהות משתמש כלשהי (למשל חשבון) במכשיר.
• [C-0-4] אסור לשתף נתונים כאלה עם רכיבים אחרים של מערכת ההפעלה שלא עומדים בדרישות שמפורטות בקטע הנוכחי (9.8.17 טלמטריה לשמירה על הפרטיות).
• [C-0-5] חובה לספק למשתמשים אפשרות להפעיל או להשבית את האיסוף, השימוש והשיתוף של נתוני טלמטריה לשמירה על הפרטיות.
• [C-0-6] חובה לספק למשתמשים אפשרות למחוק נתונים כאלה שנאספים במסגרת ההטמעה, אם הנתונים מאוחסנים במכשיר בצורה כלשהי. אם המשתמש בחר למחוק את הנתונים, חובה להסיר את כל הנתונים ששמורים כרגע במכשיר.
• [C-0-7] חובה לחשוף את ההטמעה הבסיסית של הפרוטוקול לשמירה על הפרטיות במאגר בקוד פתוח.
• [C-0-8 ]חובה לאכוף את כללי המדיניות לגבי תעבורת נתונים יוצאת בקטע הזה כדי לפקח על איסוף הנתונים בקטגוריות של מדדים מוגבלים שמוגדרות ב-StatsLog.

סיום הדרישות החדשות

9.9. הצפנת אחסון נתונים

כל המכשירים חייבים לעמוד בדרישות שמפורטות בקטע 9.9.1. מכשירים שהושקו ברמת API מוקדמת יותר מזו שמפורטת במסמך הזה פטורים מהדרישות שמפורטות בקטעים 9.9.2 ו-9.9.3. במקום זאת, הם חייבים לעמוד בדרישות שמפורטות בקטע 9.9 במסמך הגדרת התאימות ל-Android, בהתאם לרמת ה-API שבה המכשיר הושק.

9.9.1. Direct Boot

הטמעות במכשירים:

• [C-0-1] חובה להטמיע את ממשקי ה-API של מצב הפעלה ישיר גם אם הם לא תומכים בהצפנת אחסון.

• [C-0-2] עדיין צריך לשדר את ה-Intents‏ ACTION_LOCKED_BOOT_COMPLETED ו-ACTION_USER_UNLOCKED כדי לאותת לאפליקציות שתומכות ב-Direct Boot שמיקומי האחסון של Device Encrypted‏ (DE) ושל Credential Encrypted‏ (CE) זמינים למשתמש.

9.9.2. דרישות הצפנה

הטמעות במכשירים:

• [C-0-1] חובה להצפין את הנתונים הפרטיים של האפליקציה (מחיצה /data), וגם את המחיצה של האחסון המשותף של האפליקציה (מחיצה /sdcard) אם היא חלק קבוע ולא ניתן להסיר אותה מהמכשיר.
• [C-0-2] חובה להפעיל את ההצפנה של אחסון הנתונים כברירת מחדל ברגע שהמשתמש משלים את חוויית ההגדרה של המכשיר החדש.

• [C-0-3] חובה לעמוד בדרישת ההצפנה של אחסון הנתונים שלמעלה באמצעות הטמעה של אחת משתי שיטות ההצפנה הבאות:

  • הצפנה מבוססת-קובץ (FBE) והצפנת מטא-נתונים כפי שמתואר בקטע 9.9.3.1.
  • הצפנה ברמת הבלוק לכל משתמש, כפי שמתואר בקטע 9.9.3.2.

הערה: הטמעות של מכשירים ששווקו עם רמת API 28 ואילך ולא עומדות בדרישות שמפורטות בקטע 9.9.2 באמצעות עדכון של תוכנת המערכת, חייבות לעמוד בדרישות שמפורטות בקטע 9.9 במסמך הגדרת התאימות ל-Android, בהתאם לרמת ה-API שבה המכשיר שווק.

9.9.3. שיטות הצפנה

אם הטמעות במכשירים מוצפנות, הן:

• [C-1-1] חייב להפעיל את המכשיר בלי לבקש מהמשתמש להזין פרטי כניסה, ולאפשר לאפליקציות שתומכות בהפעלה ישירה לגשת לאחסון המוצפן של המכשיר (DE) אחרי שהודעת ACTION_LOCKED_BOOT_COMPLETED תשודר.
• [C-1-2] חובה לאפשר גישה לאחסון של פרטי הכניסה המוצפנים (CE) רק אחרי שהמשתמש מבטל את הנעילה של המכשיר על ידי מסירת פרטי הכניסה שלו (למשל, קוד גישה, קוד אימות, דפוס או טביעת אצבע) והודעת ACTION_USER_UNLOCKED משודרת.
• [C-1-13] אסור להציע שום שיטה לביטול הנעילה של האחסון המוגן ב-CE בלי פרטי הכניסה שהמשתמש סיפק, מפתח נאמן רשום או הטמעה של 'המשך לאחר הפעלה מחדש' שעומדת בדרישות שמפורטות בסעיף 9.9.4.
• [C-1-4] חובה להשתמש בהפעלה מאומתת.

9.9.3.1. הצפנה מבוססת-קבצים עם הצפנת מטא-נתונים

אם בהטמעות במכשירים נעשה שימוש בהצפנה מבוססת-קבצים עם הצפנת מטא-נתונים, הן:

• [C-1-5] חובה להצפין את תוכן הקבצים ואת המטא-נתונים של מערכת הקבצים באמצעות AES-256-XTS או Adiantum. AES-256-XTS מתייחס לתקן הצפנה מתקדם (AES) עם מפתח הצפנה באורך 256 ביט, שפועל במצב XTS. האורך המלא של המפתח הוא 512 ביט. Adiantum מתייחס ל-Adiantum-XChaCha12-AES, כפי שמפורט בכתובת https://github.com/google/adiantum. מטא-נתונים של מערכת קבצים הם נתונים כמו גדלים של קבצים, בעלות, מצבים ומאפיינים מורחבים (xattrs).
• [C-1-6] חובה להצפין את שמות הקבצים באמצעות AES-256-CBC-CTS,‏ AES-256-HCTR2 או Adiantum.
• [C-1-12] אם במכשיר יש הוראות של Advanced Encryption Standard‏ (AES) (כמו ARMv8 Cryptography Extensions במכשירים מבוססי ARM, או AES-NI במכשירים מבוססי x86), חובה להשתמש באפשרויות שמבוססות על AES שמפורטות למעלה להצפנת שם הקובץ, תוכן הקובץ ומטא-נתונים של מערכת הקבצים, ולא ב-Adiantum.
• [C-1-13] חובה להשתמש בפונקציית הפקת מפתחות חזקה מבחינה קריפטוגרפית ולא הפיכה (למשל HKDF-SHA512) כדי להפיק מפתחות משנה נדרשים (למשל מפתחות לכל קובץ) ממפתחות CE ו-DE. 'קריפטוגרפית חזקה ולא הפיך' פירושו שלפונקציית הפקת המפתח יש חוזק אבטחה של לפחות 256 ביט, והיא מתנהגת כמשפחה של פונקציות פסאודו-אקראיות על הקלט שלה.
• [C-1-14] אסור להשתמש באותם מפתחות או מפתחות משנה של הצפנה מבוססת-קובץ (FBE) למטרות קריפטוגרפיות שונות (למשל, גם להצפנה וגם להספק מפתחות, או בשני אלגוריתמים שונים של הצפנה).
• [C-1-15] חובה לוודא שכל הקטעים שלא נמחקו של תוכן קבצים מוצפנים באחסון מתמיד הוצפנו באמצעות שילובים של מפתח הצפנה ווקטור איפוס (IV) שתלויים גם בקובץ וגם בהיסט בקובץ. בנוסף, כל השילובים האלה חייבים להיות ייחודיים, אלא אם ההצפנה מתבצעת באמצעות חומרה של הצפנה מוטמעת שתומכת רק באורך IV של 32 ביט.
• [C-1-16] חובה לוודא שכל שמות הקבצים המוצפנים שלא נמחקו באחסון המתמיד בתיקיות נפרדות הוצפנו באמצעות שילובים נפרדים של מפתח הצפנה ווקטור אתחול (IV).

• [C-1-17] חובה לוודא שכל הבלוקים של המטא-נתונים של מערכת הקבצים המוצפנים באחסון המתמיד הוצפנו באמצעות שילובים נפרדים של מפתח הצפנה ווקטור אתחול (IV).

• מפתחות שמגינים על אזורי האחסון של CE ו-DE ועל המטא-נתונים של מערכת הקבצים:

  • [C-1-7] חובה לקשר באופן קריפטוגרפי ל-Keystore שמגובל בחומרה. מאגר המפתחות הזה חייב להיות קשור ל-Verified Boot ול-Root of Trust של החומרה במכשיר.
  • [C-1-8] חובה לשייך מפתחות CE לפרטי הכניסה של המשתמש במסך הנעילה.
  • [C-1-9] מפתחות CE חייבים להיות מקושרים לקוד גישה שמוגדר כברירת מחדל כשהמשתמש לא ציין פרטי כניסה למסך הנעילה.
  • [C-1-10] חייב להיות ייחודי ומובהק, כלומר, לאף מפתח CE או DE של משתמש לא יכול להיות התאמה למפתחות CE או DE של משתמש אחר.
  • [C-1-11] חובה להשתמש במודים, באורכי המפתחות ובצפנים הנתמכים באופן מחייב.
  • [C-1-12] חייב להימחק באופן מאובטח במהלך ביטול הנעילה והנעילה של תוכנת האתחול, כפי שמתואר כאן.

• צריך להפוך אפליקציות חיוניות שהותקנו מראש (למשל: שעון מעורר, טלפון, Messenger) למודעות לטעינה ישירה.

בפרויקט Android Open Source ב-upstream יש הטמעה מועדפת של הצפנה מבוססת-קובץ שמבוססת על תכונת ההצפנה 'fscrypt' של ליבה של Linux, והטמעה של הצפנת מטא-נתונים שמבוססת על התכונה 'dm-default-key' של ליבה של Linux.

הערה: הטמעות של מכשירים ששווקו עם רמת API 28 ואילך ולא עומדות בדרישות שמפורטות בקטע 9.9.3 באמצעות עדכון של תוכנת המערכת, חייבות לעמוד בדרישות שמפורטות בקטע 9.9 במסמך ההגדרה של תאימות Android, בהתאם לרמת ה-API שבה המכשיר שווק.

9.9.3.2. הצפנה ברמת הבלוק לכל משתמש

אם בהטמעות במכשירים נעשה שימוש בהצפנה ברמת הבלוק לכל משתמש, הן:

• [C-1-1] חובה להפעיל תמיכה במספר משתמשים כפי שמתואר בקטע 9.5.
• [C-1-2] חובה לספק מחיצות לכל משתמש, באמצעות מחיצות גולמיות או באמצעות נפחים לוגיים.
• [C-1-3] חובה להשתמש במפתחות הצפנה ייחודיים לכל משתמש להצפנת מכשירי הבלוק הבסיסיים.

• [C-1-4] חובה להשתמש ב-AES-256-XTS להצפנה ברמת הבלוק של המחיצות של המשתמש.

• המפתחות שמגינים על המכשירים המוצפנים ברמת הבלוק לכל משתמש:

  • [C-1-5] חייב להיות קשור באופן קריפטוגרפי ל-Keystore מגובה-חומרה. מאגר המפתחות הזה חייב להיות קשור ל-Verified Boot ול-Root of Trust של החומרה במכשיר.
  • [C-1-6] חייב להיות מקושר לפרטי הכניסה של משתמש מסוים במסך הנעילה.

אפשר להטמיע הצפנה ברמת הבלוקים לכל משתמש באמצעות התכונה 'dm-crypt' בליבה של Linux במחיצות לכל משתמש.

9.9.4. המשך לאחר הפעלה מחדש

התכונה 'המשך לאחר הפעלה מחדש' מאפשרת לבטל את נעילת האחסון ב-CE של כל האפליקציות, כולל אלה שעדיין לא תומכות בהפעלה ישירה (Direct Boot), אחרי הפעלה מחדש שהופעל על ידי עדכון OTA. התכונה הזו מאפשרת למשתמשים לקבל התראות מאפליקציות מותקנות אחרי ההפעלה מחדש.

הטמעה של 'המשך הפעלה לאחר הפעלה מחדש' צריכה להמשיך להבטיח שאם מכשיר נופל לידי תוקף, יהיה לו קשה מאוד לשחזר את הנתונים של המשתמש שמוצפנים ב-CE, גם אם המכשיר מופעל, האחסון ב-CE נעול והמשתמש ביטל את הנעילה של המכשיר אחרי קבלת עדכון OTA. כדי להתנגד להתקפות מבפנים, אנחנו גם מניחים שהתוקף מקבל גישה להעברה של מפתחות קריפטוגרפיים לחתימה.

פרטים נוספים:

• [C-0-1] האחסון של CE לא יכול להיות קריא גם לתוקף שיש לו פיזית את המכשיר, ויש לו את היכולות והמגבלות הבאות:

  • יכולים להשתמש במפתח החתימה של כל ספק או חברה כדי לחתום על הודעות שרירותיות.
  • יכולה לגרום לקבלת עדכון OTA במכשיר.
  • יכולים לשנות את הפעולה של כל חומרה (AP, ‏ Flash וכו') מלבד כפי שמפורט בהמשך, אבל שינוי כזה כרוך בהשהיה של שעה לפחות ובמחזור הפעלה שמחסל את תוכן ה-RAM.
  • לא ניתן לשנות את הפעולה של חומרה עמידת-זיוף (למשל Titan M).
  • לא ניתן לקרוא את ה-RAM של המכשיר הפעיל.
  • לא ניתן לקבל את פרטי הכניסה של המשתמש (קוד אימות, קו ביטול נעילה או סיסמה) או לגרום לו להזין אותם בדרך אחרת.

לדוגמה, הטמעה של מכשיר שמטמיעה את כל התיאורים שמופיעים כאן ועומדת בדרישות שלהם תהיה תואמת ל-[C-0-1].

9.10. תקינות המכשיר

הדרישות הבאות מבטיחות שקיפות לגבי סטטוס תקינות המכשיר. הטמעות במכשירים:

• [C-0-1] חובה לדווח בצורה נכונה באמצעות שיטת System API‏ PersistentDataBlockManager.getFlashLockState() אם מצב האתחול מאפשר את ה-flashing של קובץ האימג' של המערכת.

• [C-0-2] חובה לתמוך בהפעלה מאומתת לשמירה על תקינות המכשיר.

אם הטמעות של מכשירים כבר הושקו ללא תמיכה ב-Verified Boot בגרסה קודמת של Android, ולא ניתן להוסיף תמיכה בתכונה הזו באמצעות עדכון תוכנת מערכת, יכול להיות שהן יהיו פטורות מהדרישה.

הפעלה מאומתת היא תכונה שמבטיחה את תקינות התוכנה במכשיר. אם הטמעות המכשיר תומכות בתכונה, הן:

• [C-1-1] חובה להצהיר על ה-feature flag של הפלטפורמה android.software.verified_boot.
• [C-1-2] חובה לבצע אימות בכל רצף הפעלה.
• [C-1-3] חובה להתחיל את האימות ממפתח חומרה בלתי ניתן לשינוי שהוא הבסיס לאמון, ולהמשיך עד למחיצה של המערכת.
• [C-1-4] חובה להטמיע כל שלב של אימות כדי לבדוק את השלמות והאותנטיות של כל הבייטים בשלב הבא, לפני שמריצים את הקוד בשלב הבא.
• [C-1-5] חובה להשתמש באלגוריתמים לאימות חזקים כמו ההמלצות הנוכחיות של NIST לאלגוריתמי גיבוב (SHA-256) ולגדלים של מפתחות ציבוריים (RSA-2048).
• [C-1-6] אסור לאפשר את השלמת האתחול אם אימות המערכת נכשל, אלא אם המשתמש מסכים לנסות את האתחול בכל מקרה. במקרה כזה, אסור להשתמש בנתונים מכל בלוקים של אחסון שלא אומתו.
• [C-1-7] אסור לאפשר שינוי של מחיצות מאומתות במכשיר, אלא אם המשתמש פתח את נעילת האתחול באופן מפורש.
• [C-SR-1] אם יש במכשיר כמה צ'יפים נפרדים (למשל, רדיו, מעבד תמונה יעודי), מומלץ מאוד לאמת כל שלב בתהליך האתחול של כל אחד מהצ'יפים האלה.
• [C-1-8] חובה להשתמש באחסון עם תכונה למניעת פגיעה: לאחסון המידע לגבי הנעילה של מנהל האתחול. אחסון עם תכונה למניעת פגיעה (tamper-evident) מאפשר למחולל האתחול לזהות אם בוצעה פגיעה באחסון מתוך Android.
• [C-1-9] חובה להציג למשתמש הודעה בזמן השימוש במכשיר ולדרוש אישור פיזי לפני שמאפשרים מעבר ממצב נעילה של תוכנת האתחול למצב ביטול נעילה של תוכנת האתחול.
• [C-1-10] חובה להטמיע הגנה מפני חזרה לאחור למחיצות שבהן Android משתמש (למשל, מחיצות אתחול, מחיצות מערכת) ולהשתמש באחסון עם אימות מפני פגיעה כדי לאחסן את המטא-נתונים שמשמשים לקביעת גרסת מערכת ההפעלה המינימלית המותרת.
• [C-1-11] חובה למחוק בצורה מאובטחת את כל נתוני המשתמש במהלך הנעילה והביטול של תוכנת האתחול, בהתאם ל-9.12. מחיקה של נתונים (כולל המחיצה של userdata ואת כל המרחבים של NVRAM).
• [C-SR-2] מומלץ מאוד לאמת את כל קובצי ה-APK של האפליקציות עם הרשאות באמצעות שרשרת אמון שמקורה במחיצות שמוגנות על ידי Verified Boot.
• [C-SR-3] מומלץ מאוד לאמת את כל הארטיפקטים ההפעלה שאפליקציה בעלת הרשאות טוענת מחוץ לקובץ ה-APK שלה (כמו קוד שנטען באופן דינמי או קוד שעבר הידור) לפני שמפעילים אותם, או מומלץ מאוד לא להפעיל אותם בכלל.
• צריך להטמיע הגנה מפני החזרה לגרסה קודמת בכל רכיב עם קושחת תוכנה קבועה (למשל, מודם, מצלמה) ולהשתמש באחסון עם אימות מפני פגיעה כדי לאחסן את המטא-נתונים שמשמשים לקביעת הגרסה המינימלית המותרת.

אם הטמעות של מכשירים כבר הושקו בלי תמיכה בדרישות C-1-8 עד C-1-11 בגרסה קודמת של Android, ולא ניתן להוסיף תמיכה בדרישות האלה באמצעות עדכון תוכנת המערכת, יכול להיות שהן יקבלו פטור מהדרישות.

ב-Android Open Source Project (פרויקט קוד פתוח של Android) יש הטמעה מועדפת של התכונה הזו במאגר external/avb/, שאפשר לשלב ב-bootloader שמשמש לטעינת Android.

הטמעות במכשירים

אם להטמעות במכשירים יש אפשרות לאמת את תוכן הקובץ לפי דף, הן:

• [C-0-3 C-2-1] תומכים באימות קריפטוגרפית של תוכן הקובץ לעומת מפתח מהימן בלי לקרוא את כל הקובץ.

• [C-0-4 C-2-2] אסור לאפשר לבקשות הקריאה בקובץ מוגן להצליח כשתוכן הקריאה לא מאומת באמצעות מפתח מהימן לא מאומת לפי [C-2-1] למעלה.

יצירת דרישות חדשות

• [C-2-4] חובה להחזיר את סיכום הביקורת של הקובץ ב-O(1) עבור קבצים מופעלים.

סיום הדרישות החדשות

אם הטמעות במכשירים כבר הושקו בגרסה קודמת של Android ללא היכולת לאמת את תוכן הקובץ באמצעות מפתח מהימן, ולא ניתן להוסיף תמיכה בתכונה הזו באמצעות עדכון תוכנת המערכת, יכול להיות שהן יהיו פטורות מהדרישה. בפרויקט Android Open Source ב-upstream יש הטמעה מועדפת של התכונה הזו, שמבוססת על התכונה fs-verity בליבה של Linux.

הטמעות במכשירים:

• [C-SR-4] מומלץ מאוד לתמוך ב-Android Protected Confirmation API.

אם הטמעות במכשירים תומכות ב-Android Protected Confirmation API, הן:

• [C-3-1] חובה לדווח על true ב-API של ConfirmationPrompt.isSupported().

• [C-3-2] חובה לוודא שקוד שפועל במערכת ההפעלה Android, כולל הליבה שלה, זדוני או אחר, לא יכול ליצור תגובה חיובית ללא אינטראקציה של משתמש.

• [C-3-3] חובה לוודא שהמשתמש יכול לבדוק ולאשר את ההודעה שהוצגה, גם אם מערכת ההפעלה של Android, כולל הליבה שלה, נפרצה.

9.11. מפתחות ופרטי כניסה

מערכת Android Keystore מאפשרת למפתחי אפליקציות לאחסן מפתחות קריפטוגרפיים בקונטיינר ולהשתמש בהם בפעולות קריפטוגרפיות באמצעות KeyChain API או Keystore API. הטמעות במכשירים:

• [C-0-1] חובה לאפשר ייבוא או יצירה של לפחות 8,192 מפתחות.
• [C-0-2] האימות במסך הנעילה חייב לכלול מרווח זמן בין ניסיונות כושלים. כש-n הוא מספר הניסיונות הכושלים, מרווח הזמן חייב להיות לפחות 30 שניות עבור 9 < n < 30. אם n > 29, הערך של מרווח הזמן חייב להיות לפחות 30*2^floor((n-30)/10)) שניות או לפחות 24 שעות, לפי הערך הנמוך מביניהם.
• לא צריך להגביל את מספר המפתחות שאפשר ליצור

יצירת דרישות חדשות

• [C-0-3] חובה להגביל את מספר ניסיונות האימות הראשי שנכשלו.
• [C-SR-2] מומלץ מאוד להטמיע מגבלה עליונה של 20 ניסיונות אימות ראשוניים שנכשלו. אם המשתמשים נותנים הסכמה ומביעים הסכמה לשימוש בתכונה, צריך לבצע איפוס לנתוני היצרן אחרי שמגיעים למגבלה של ניסיונות אימות ראשוניים שנכשלו.

אם הטמעות במכשירים מוסיפות או משנות את שיטות האימות כדי לבטל את נעילת המסך אם הוא מבוסס על סוד ידוע, ומשתמשות בשיטת אימות חדשה כדי להיחשב כדרך מאובטחת לנעילת המסך, אז:

• [C-SR-3] מומלץ מאוד שקוד האימות יכלול לפחות 6 ספרות, או אנטרופי של 20 ביט.
• [C-2-1] קוד אימות באורך של פחות מ-6 ספרות אסור לאפשר כניסה אוטומטית ללא אינטראקציה של המשתמש, כדי למנוע חשיפת אורך קוד האימות.

סיום הדרישות החדשות

כשהטמעת המכשיר תומכת במסך נעילה מאובטח, היא:

• [C-1-1] חובה לגבות את הטמעת מאגר המפתחות באמצעות סביבת הפעלה מבודדת.
• [C-1-2] חובה שתהיה הטמעה של אלגוריתמים קריפטוגרפיים מסוג RSA, ‏ AES, ‏ ECDSA,‏ ECDH (אם IKeyMintDevice נתמך), ‏ 3DES ו-HMAC, ופונקציות גיבוב ממשפחת MD5, ‏ SHA1 ו-SHA-2, כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בליבה ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד הליבה או קוד מרחב המשתמש עשוי לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. כדי לעמוד בדרישות האלה, בפרויקט Android Open Source (AOSP) נעשה שימוש בהטמעה של Trusty. אפשרויות חלופיות הן פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת של בידוד תקין שמבוסס על hypervisor, שעבר בדיקה על ידי צד שלישי.
• [C-1-3] חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק אם הוא מצליח, לאפשר שימוש במפתחות שמקושרים לאימות. חובה לאחסן את פרטי הכניסה של מסך הנעילה באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. בפרויקט הקוד הפתוח של Android שמשמש כמקור (upstream) יש את שכבת האובייקטיפיקציה של החומרה (HAL) של Gatekeeper ואת Trusty, שאפשר להשתמש בהם כדי לעמוד בדרישות האלה.
• [C-1-4] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה לאימות מוגן בחומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה לאימות במספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת מהדרכים לעמוד בדרישות האלה היא לשתף את אותו מפתח אימות, אלא אם מיוצרות לפחות 100,000 יחידות של מק"ט נתון. אם מיוצרות יותר מ-100,000 יחידות של מק"ט מסוים, יכול להיות שייעשה שימוש במפתח שונה לכל 100,000 יחידות.

הערה: אם הטמעת מכשיר כבר הופעלה בגרסה קודמת של Android, המכשיר הזה פטור מהדרישה לכלול מאגר מפתחות שמגודר על ידי סביבת הפעלה מבודדת ולתמוך באימות המפתחות, אלא אם הוא מצהיר על התכונה android.hardware.fingerprint, שדורשת מאגר מפתחות שמגודר על ידי סביבת הפעלה מבודדת.

• [C-1-5] חובה לאפשר למשתמש לבחור את זמן הקצוב לתפוגה במצב שינה כדי לעבור ממצב 'לא נעול' למצב 'נעול', עם זמן קצוב לתפוגה מינימלי של עד 15 שניות. במכשירים לרכב, שמנעלים את המסך בכל פעם שהיחידה הראשית מושבתת או שהמשתמש עובר, יכול להיות שלא תהיה הגדרה של זמן קצוב ליציאה ממצב שינה.
• [C-1-6] חובה לתמוך באחת מהאפשרויות הבאות:
  • IKeymasterDevice 3.0,
  • IKeymasterDevice 4.0,
  • IKeymasterDevice 4.1,
  • IKeyMintDevice גרסה 1, או
  • IKeyMintDevice גרסה 2.
• [C-SR-1] מומלץ מאוד לתמוך בגרסה 1 של IKeyMintDevice.

9.11.1. אבטחת מסך הנעילה, אימות ומכשירים וירטואליים

ההטמעה ב-AOSP מבוססת על מודל אימות מדורג, שבו אימות ראשי שמבוסס על מפעל ידע יכול להיות מגובה באימות ביומטרי משני חזק או במודלים משניים חלשים יותר.

הטמעות במכשירים:

• [C-SR-1] מומלץ מאוד להגדיר רק אחת מהשיטות הבאות כשיטת האימות הראשית:

  • קוד אימות מספרי
  • סיסמה אלפאנומרית

  • דפוס החלקה ברשת של 9 נקודות בדיוק (3x3)

    שימו לב שבמסמך הזה הן נקראות שיטות האימות הראשיות המומלצות.

יצירת דרישות חדשות

• [C-0-1] חובה להגביל את מספר ניסיונות האימות הראשי שנכשלו.
• [C-SR-5] מומלץ מאוד להטמיע מגבלה עליונה של 20 ניסיונות אימות ראשוניים שנכשלו. אם המשתמשים נותנים הסכמה ומביעים הסכמה לשימוש בתכונה, צריך לבצע 'איפוס לנתוני היצרן' אחרי שמגיעים למגבלה של ניסיונות אימות ראשוניים שנכשלו.

אם בהטמעות של המכשירים מוגדר קוד מספרי כשיטת האימות הראשית המומלצת, אז:

• [C-SR-6] מומלץ מאוד שקוד האימות יכלול לפחות 6 ספרות, או אנטרופי של 20 ביט.
• [C-SR-7] מומלץ מאוד לא לאפשר כניסה אוטומטית ללא אינטראקציה של המשתמש כשקוד האימות קצר מ-6 ספרות, כדי לא לחשוף את אורך קוד האימות.

סיום הדרישות החדשות

אם הטמעות במכשירים מוסיפות או משנות את שיטות האימות הראשיות המומלצות ומשתמשות בשיטת אימות חדשה כדרך מאובטחת לנעילת המסך, שיטת האימות החדשה:

• [C-2-1] חייבת להיות שיטת אימות המשתמש כפי שמתואר בקטע דרישה לאימות משתמש לשימוש במפתח.

אם הטמעות במכשירים מוסיפות או משנות את שיטות האימות כדי לבטל את נעילת מסך הנעילה אם הוא מבוסס על סוד ידוע, ומשתמשות בשיטת אימות חדשה כדי להתייחס אליה כאל דרך מאובטחת לנעילת המסך:

• [C-3-1] האנטרופיה של האורך הקצר ביותר של קלט מותר חייבת להיות גדולה מ-10 ביט.
• [C-3-2] ההאנטרופיה המקסימלית של כל ערכי הקלט האפשריים חייבת להיות גדולה מ-18 ביט.
• [C-3-3] שיטת האימות החדשה אסור שתחליף אף אחת משיטות האימות הראשיות המומלצות (כלומר, קוד אימות, קו ביטול נעילה, סיסמה) שמוטמעות ומסופקות ב-AOSP.
• [C-3-4] חובה להשבית את שיטת האימות החדשה כשאפליקציית Device Policy Controller‏ (DPC) מגדירה את מדיניות הדרישות לסיסמה באמצעות DevicePolicyManager.setRequiredPasswordComplexity()‎ עם קבוע מורכבות מגביל יותר מ-PASSWORD_COMPLEXITY_NONE, או באמצעות השיטה DevicePolicyManager.setPasswordQuality()‎ עם קבוע מגביל יותר מ-PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-3-5] שיטות אימות חדשות חייבות לחזור לשיטות האימות הראשיות המומלצות (למשל, מספר PIN, דפוס או סיסמה) פעם ב-72 שעות או פחות, או לחשוף בבירור למשתמש שחלק מהנתונים לא יגובו כדי לשמור על פרטיות הנתונים שלו.

אם הטמעות במכשירים מוסיפות או משנות את שיטות האימות הראשיות המומלצות לביטול הנעילה של מסך הנעילה, ומשתמשות בשיטת אימות חדשה שמבוססת על מידע ביומטרי כדי להתייחס אליה כאל דרך מאובטחת לנעילת המסך, השיטה החדשה:

• [C-4-1] חייב לעמוד בכל הדרישות שמפורטות בקטע 7.3.10 לסיווג 1 (לשעבר נוחות).
• [C-4-2] חובה שיהיה מנגנון חלופי לשימוש באחת משיטות האימות הראשיות המומלצות שמבוססות על סוד ידוע.
• [C-4-3] חובה להשבית ולאפשר רק לאימות הראשי המומלץ לבטל את נעילת המסך, אחרי שאפליקציית Device Policy Controller‏ (DPC) מגדירה את מדיניות התכונה של מסך הנעילה באמצעות קריאה לשיטה DevicePolicyManager.setKeyguardDisabledFeatures() עם אחד מהדגלים הביומטריים המשויכים (כלומר KEYGUARD_DISABLE_BIOMETRICS,‏ KEYGUARD_DISABLE_FINGERPRINT,‏ KEYGUARD_DISABLE_FACE או KEYGUARD_DISABLE_IRIS).

אם שיטות האימות הביומטרי לא עומדות בדרישות של סיווג 3 (לשעבר חזק) כפי שמתואר בסעיף 7.3.10:

• [C-5-1] חובה להשבית את השיטות אם באפליקציית Device Policy Controller‏ (DPC) הוגדרה מדיניות האיכות של דרישות הסיסמה באמצעות DevicePolicyManager.setRequiredPasswordComplexity()‎ עם קטגוריית מורכבות מגבילה יותר מ-PASSWORD_COMPLEXITY_LOW, או באמצעות השיטה DevicePolicyManager.setPasswordQuality()‎ עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] חובה להציג למשתמש אתגר לאימות הראשי המומלץ (למשל: מספר PIN, דפוס, סיסמה) כפי שמתואר בסעיף 7.3.10 בקטע [C-1-7] ובקטע [C-1-8].
• [C-5-3] אסור להתייחס לשיטות כמסך נעילה מאובטח, והן חייבות לעמוד בדרישות שמתחילות ב-C-8 בקטע הזה בהמשך.

אם הטמעות במכשירים מוסיפות או משנות את שיטות האימות כדי לבטל את נעילת מסך הנעילה, ושיטת אימות חדשה מבוססת על אסימון פיזי או על המיקום:

• [C-6-1] חובה שיהיה להם מנגנון חלופי לשימוש באחת משיטות האימות הראשיות המומלצות שמבוססות על סוד ידוע ועומדות בדרישות לטיפול כמסך נעילה מאובטח.
• [C-6-2] חובה להשבית את השיטה החדשה ולאפשר רק לאחת משיטות האימות הראשיות המומלצות לבטל את נעילת המסך, כשאפליקציית Device Policy Controller (DPC) מגדירה את המדיניות באמצעות:
  • השיטה DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)
  • השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_NONE.
  • השיטה DevicePolicyManager.setRequiredPasswordComplexity() עם קטגוריית מורכבות מגבילה יותר מ-PASSWORD_COMPLEXITY_NONE.
• [C-6-3] חובה לבצע אצל המשתמש אתגר לאימות באמצעות אחת משיטות האימות הראשיות המומלצות (למשל, קוד אימות, קו ביטול נעילה או סיסמה) לפחות פעם ב-4 שעות או פחות. כשאסימון פיזי עומד בדרישות להטמעות של TrustAgent ב-C-X, חלות במקום זאת הגבלות הזמן הקצוב לתפוגה שהוגדרו ב-C-9-5.
• [C-6-4] אסור להתייחס לשיטה החדשה כמסך נעילה מאובטח, וצריך לפעול לפי האילוצים שמפורטים בקטע C-8 בהמשך.

אם למכשירים יש נעילת מסך מאובטחת והם כוללים סוכן אמון אחד או יותר שמטמיע את TrustAgentService System API, הם:

• [C-7-1] חובה להציג אינדיקציה ברורה בתפריט ההגדרות ובמסך הנעילה כשנעילת המכשיר מושהית או שאפשר לבטל את הנעילה באמצעות סוכני אמון. לדוגמה, ב-AOSP מתקיים הדרישה הזו באמצעות הצגת תיאור טקסט של ההגדרות 'נעילה אוטומטית' ו'לחצן ההפעלה נועל באופן מיידי' בתפריט ההגדרות וכן סמל בולט במסך הנעילה.
• [C-7-2] חובה לכבד ולהטמיע באופן מלא את כל ממשקי ה-API של סוכני האמון בכיתה DevicePolicyManager, כמו הקבועה KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] אסור להטמיע באופן מלא את הפונקציה TrustAgentService.addEscrowToken() במכשיר שמשמש כמכשיר אישי ראשי (למשל, מכשיר נייד), אבל מותר להטמיע את הפונקציה באופן מלא בהטמעות של מכשירי שיתוף (למשל, Android Television או מכשיר לכלי רכב).
• [C-7-4] חובה להצפין את כל הטוקנים המאוחסנים שנוספו על ידי TrustAgentService.addEscrowToken().
• [C-7-5] אסור לאחסן את מפתח ההצפנה או את אסימון ההתחייבות להחזקה באותו מכשיר שבו נעשה שימוש במפתח. לדוגמה, מותר למפתח שמאוחסן בטלפון לפתוח את נעילת חשבון המשתמש בטלוויזיה. במכשירים לכלי רכב, אסור לאחסן את אסימון ה-escrow באף חלק ברכב.
• [C-7-6] חובה להודיע למשתמש על ההשלכות של האבטחה לפני שמפעילים את אסימון ה-Escrow כדי לפענח את אחסון הנתונים.
• [C-7-7] חובה שיהיה מנגנון חלופי לשימוש באחת משיטות האימות הראשיות המומלצות.
• [C-7-8] חובה לבקש מהמשתמש להזין את אחת משיטות האימות הראשיות המומלצות (למשל: קוד אימות, קו ביטול נעילה, סיסמה) לפחות פעם אחת בכל 72 שעות או פחות, אלא אם יש חשש לגבי הבטיחות של המשתמש (למשל: הסחת דעת של הנהג).
• [C-7-9] חובה לבקש מהמשתמש לבצע אחת משיטות האימות הראשיות המומלצות (למשל: קוד אימות, דפוס, סיסמה) כפי שמתואר בקטע 7.3.10, אלא אם יש חשש לבטיחות המשתמש (למשל, הסחת דעת של הנהג).
• [C-7-10] אסור להתייחס אליו כמסך נעילה מאובטח, וצריך לפעול בהתאם למגבלות שמפורטות בקטע C-8 בהמשך.
• [C-7-11] אסור לאפשר ל-TrustAgents במכשירים אישיים ראשיים (למשל: מכשירים ניידים) לבטל את הנעילה של המכשיר, וניתן להשתמש בהם רק כדי לשמור על מצב ביטול הנעילה של מכשיר שכבר נעול למשך עד 4 שעות לכל היותר. ההטמעה שמוגדרת כברירת מחדל של TrustManagerService ב-AOSP עומדת בדרישות האלה.
• [C-7-12] חובה להשתמש בערוץ תקשורת מאובטח מבחינה קריפטוגרפית (למשל UKEY2) כדי להעביר את אסימון ההתחייבות להחזקה לצורך העברה (escrow) ממכשיר האחסון למכשיר היעד.

אם הטמעות במכשירים מוסיפות או משנות את שיטות האימות כדי לבטל את נעילת מסך הנעילה שאינו מסך נעילה מאובטח כפי שמתואר למעלה, ומשתמשות בשיטת אימות חדשה כדי לבטל את נעילת מסך הנעילה:

• [C-8-1] חובה להשבית את השיטה החדשה כשאפליקציית Device Policy Controller‏ (DPC) מגדירה את מדיניות איכות הסיסמאות באמצעות השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_NONE, או באמצעות השיטה DevicePolicyManager.setRequiredPasswordComplexity() עם קבוע מורכבות מגביל יותר מ-'PASSWORD_COMPLEXITY_NONE'.
• [C-8-2] אסור לאפס את הטיימר לתפוגת התוקף של הסיסמאות שהוגדר על ידי DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] אסור לחשוף ממשק API לשימוש באפליקציות צד שלישי כדי לשנות את מצב הנעילה.

אם הטמעות במכשירים מאפשרות לאפליקציות ליצור מסכים וירטואליים משניים ולא תומכות באירועי קלט משויכים, כמו דרך VirtualDeviceManager, הן:

• [C-9-1] חובה לנעול את המסכים הווירטואליים המשניים האלה כשמסך ברירת המחדל של המכשיר נעול, ולבטל את הנעילה שלהם כשמסך ברירת המחדל של המכשיר לא נעול.

אם הטמעות במכשירים מאפשרות לאפליקציות ליצור מסכים וירטואליים משניים ולתמוך באירועי קלט משויכים, למשל באמצעות VirtualDeviceManager, הן:

• [C-10-1] חובה לתמוך במצבי נעילה נפרדים לכל מכשיר וירטואלי
• [C-10-2] חובה לנתק את כל המכשירים הווירטואליים לאחר זמן קצוב לפעילות ללא תגובה
• [C-10-3] חובה להגדיר זמן קצוב לתפוגה של מצב חוסר פעילות
• [C-10-4] חובה לנעול את כל המסכים כשהמשתמש מפעיל נעילה, כולל באמצעות אמצעי הנוחות למשתמש שנדרש לנעילה במכשירים ניידים (ראו קטע 2.2.5[9.11/H-1-2])
• [C-10-5] חובה שיהיה מכשיר וירטואלי נפרד לכל משתמש
• [C-10-6] חובה להשבית את היצירה של אירועי קלט משויכים באמצעות VirtualDeviceManager כאשר DevicePolicyManager.setNearbyAppStreamingPolicy מציין זאת
• [C-10-7] חובה להשתמש בלוח נפרד לכל מכשיר וירטואלי בלבד (או להשבית את הלוח במכשירים וירטואליים)
• [C-10-11] חובה להשבית את ממשק המשתמש של האימות במכשירים וירטואליים, כולל הוספת גורם ידע והנחיה לביצוע אימות ביומטרי
• [C-10-12] חובה להגביל את המודעות שמתקבלות ממכשיר וירטואלי כך שיוצגו רק באותו מכשיר וירטואלי
• [C-10-13] אסור להשתמש במצב נעילת מכשיר וירטואלי כאישור לאימות המשתמש באמצעות מערכת Android Keystore. ראו KeyGenParameterSpec.Builder.setUserAuthentication*.

כשהטמעות במכשירים מאפשרות למשתמש להעביר את גורם האימות הראשי שמבוסס על ידע ממכשיר מקור למכשיר יעד, למשל במהלך ההגדרה הראשונית של מכשיר היעד, הן:

• [C-11-1] חובה להצפין את גורם הידע עם הבטחות הגנה דומות לאלה שמתוארות במסמך העזרה בנושא אבטחה של Google Cloud Key Vault Service כשמעבירים את גורם הידע מהמכשיר המקור למכשיר היעד, כך שלא ניתן יהיה לפענח את גורם הידע מרחוק או להשתמש בו כדי לבטל את הנעילה של כל אחד מהמכשירים מרחוק.
• [C-11-2] חובה לבקש מהמשתמש לאשר את גורם הידע במכשיר המקור לפני העברת גורם הידע למכשיר היעד.
• [C-11-3] חובה, במכשיר יעד שבו לא מוגדר גורם מידע ראשי לאימות, לבקש מהמשתמש לאשר גורם מידע שהוענק במכשיר היעד לפני שמגדירים את גורם המידע הזה כגורם המידע הראשי לאימות במכשיר היעד, וגם לפני שמאפשרים גישה לנתונים שהועברו ממכשיר מקור.

אם להטמעות במכשירים יש נעילת מסך מאובטחת וכוללות סוכן אמון אחד או יותר, שמפעילים את System API‏ TrustAgentService.grantTrust() עם הדגל FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, הם:

• [C-12-1] חייבים להפעיל את grantTrust() עם הדגל רק כשמחוברים למכשיר פיזי קרוב עם מסך נעילה משלו, וכשהמשתמש אימת את הזהות שלו מול מסך הנעילה הזה. מכשירים בקרבת מקום יכולים להשתמש במנגנוני זיהוי על פרק כף היד או על הגוף אחרי ביטול נעילה חד-פעמי של המשתמש, כדי לעמוד בדרישת אימות המשתמש.
• [C-12-2] חובה להעביר את הטמעת המכשיר למצב TrustState.TRUSTABLE כשהמסך כבוי (למשל, באמצעות לחיצה על לחצן או זמן קצוב להצגה) ו-TrustAgent לא ביטל את האמון. AOSP עומד בדרישות האלה.
• [C-12-3] חובה להעביר את המכשיר ממצב TrustState.TRUSTABLE למצב TrustState.TRUSTED רק אם ה-TrustAgent עדיין מעניק אמון על סמך הדרישות שמפורטות בקטע C-12-1.
• [C-12-4] MUST call TrustManagerService.revokeTrust()
  • אחרי 24 שעות לכל היותר ממתן האמון, או
  • אחרי חלון חוסר פעילות של 8 שעות, או
  • אם ההטמעות לא משתמשות בטווח מדויק ומאובטח מבחינה קריפטוגרפית, כפי שמוגדר ב-[C-12-5], כשהחיבור הבסיסי למכשיר הפיזי הקרוב אבד.
• [C-12-5] כדי לעמוד בדרישות של [C-12-4], יש להשתמש באחד מהפתרונות הבאים בהטמעות שמסתמכות על מדידת מרחק מאובטחת ומדויקת:
  • הטמעות באמצעות UWB:
    • חייבים לעמוד בדרישות התאימות, ההסמכה, הדיוק והכיול של UWB שמתוארות בקטע 7.4.9.
    • חובה להשתמש באחד ממצבי האבטחה של P-STS שמפורטים בקטע 7.4.9.
  • הטמעות באמצעות רשתות Wi-Fi Neighborhood Awareness Networking‏ (NAN):
    • חייבים לעמוד בדרישות הדיוק שמפורטות בקטע 2.2.1 [7.4.2.5/H-SR-1], להשתמש ברוחב הפס של 160MHz (או יותר) ולפעול לפי שלבי הגדרת המדידה שמפורטים בקטע כיול נוכחות.
    • חובה להשתמש ב-Secure LTF כפי שמוגדר ב-IEEE 802.11az.

אם הטמעות במכשירים מאפשרות לאפליקציות ליצור מסכים וירטואליים משניים ולתמוך באירועי קלט משויכים, כמו דרך VirtualDeviceManager, והמסכים לא מסומנים ב-VIRTUAL_DISPLAY_FLAG_SECURE, הם:

• [C-13-8] חובה לחסום את ההפעלה של פעילויות עם המאפיין android:canDisplayOnRemoteDevices או המטא-נתונים android.activity.can_display_on_remote_devices שמוגדרים כ-false במכשיר הווירטואלי.
• [C-13-9] חובה לחסום את ההפעלה של פעילויות במכשיר הווירטואלי שלא מאפשרות סטרימינג באופן מפורש ומציינות שהן מציגות תוכן רגיש, כולל באמצעות SurfaceView#setSecure,‏ FLAG_SECURE או SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS.
• [C-13-10] חובה להשבית את ההתקנה של אפליקציות שמתחילות במכשירים וירטואליים.

אם הטמעות במכשירים תומכות במצבי צריכת אנרגיה נפרדים של המסך דרך DeviceStateManager וגם תומכות במצבי נעילת מסך נפרדים דרך KeyguardDisplayManager, הן:

• [C-SR-2] מומלץ מאוד להשתמש בפרטי כניסה שעומדים בדרישות שמפורטות בקטע 9.11.1, או בפרטי כניסה ביומטריים שעומדים לפחות במפרט של סיווג 1 שמפורט בקטע 7.3.10, כדי לאפשר ביטול נעילה עצמאי מהמסך של המכשיר שמוגדר כברירת מחדל.
• [C-SR-3] מומלץ מאוד להגביל את הנעילה של מסך נפרד באמצעות זמן קצוב לתפוגת התצוגה.
• [C-SR-4] מומלץ מאוד לאפשר למשתמש לנעול את כל המסכים באופן גלובלי באמצעות נעילת המכשיר הנייד הראשי.

9.11.2. StrongBox

מערכת Android Keystore מאפשרת למפתחי אפליקציות לאחסן מפתחות קריפטוגרפיים במעבד מאובטח ייעודי, וגם בסביבת ההפעלה המבודדת שמתוארת למעלה. מעבד מאובטח ייעודי כזה נקרא 'StrongBox'. הדרישות שמפורטות בהמשך, מ-C-1-3 ועד C-1-11, מגדירות את הדרישות שהמכשיר צריך לעמוד בהן כדי להיחשב כ-StrongBox.

הטמעות במכשירים עם מעבד מאובטח ייעודי:

• [C-SR-1] מומלץ מאוד לתמוך ב-StrongBox. סביר להניח ש-StrongBox יהפוך לדרישה בגרסה עתידית.

אם הטמעות במכשירים תומכות ב-StrongBox, הן:

• [C-1-1] חובה להצהיר על FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] חובה לספק חומרה מאובטחת ייעודית שמשמשת לגיבוי של מאגר המפתחות ולאימות מאובטח של משתמשים. אפשר להשתמש בחומרה המאובטחת הייעודית גם למטרות אחרות.

• [C-1-3] חובה שיהיה מעבד נפרד שלא משתף מטמון, זיכרון DRAM, מעבדי משנה או משאבי ליבה אחרים עם מעבד האפליקציות (AP).

• [C-1-4] חובה לוודא שציוד היקפי שמשותף עם נקודת הגישה לא יכול לשנות את העיבוד של StrongBox בשום צורה, או לקבל מידע כלשהו מ-StrongBox. שרת ה-AP עשוי להשבית או לחסום את הגישה ל-StrongBox.

• [C-1-5] חייב להיות שעון פנימי עם דיוק סביר (+-10%) שלא ניתן לזייף על ידי נקודת הגישה.

• [C-1-6] חייב להיות גנרטור של מספרים אקראיים אמיתיים שמייצר פלט שמופץ באופן אחיד ולא ניתן לחיזוי.

• [C-1-7] חייב להיות עמיד בפני פגיעה, כולל עמידות בפני חדירה פיזית ופגיעה בתוכנה.

• [C-1-8] חייבת להיות עמידות בערוצים צדדיים, כולל עמידות נגד זליגת מידע דרך כוח, תזמון, קרינה אלקטרומגנטית וערוצים צדדיים של קרינה תרמית.

• [C-1-9] חובה שיהיה אחסון מאובטח שמבטיח את הסודיות, התקינות, האותנטיות, העקביות והעדכניות של התוכן. אסור שאפשר יהיה לקרוא את האחסון או לשנות אותו, אלא אם הדבר מותאם ל-StrongBox APIs.

• כדי לאמת תאימות ל-[C-1-3] עד [C-1-9], הטמעות במכשירים:

  • [C-1-10] חובה לכלול את החומרה שקיבלה אישור בהתאם לפרופיל ההגנה של מעגלים משולבים מאובטחים BSI-CC-PP-0084-2014 או שעבר הערכה במעבדת בדיקה מוסמכת ברמה לאומית, שכוללת הערכה של נקודות חולשה עם פוטנציאל תקיפה גבוה בהתאם ל-Common Criteria Application of Attack Potential to Smartcards.
  • [C-1-11] חובה לכלול את הקושחה שעברה הערכה במעבדת בדיקה מוסמכת ברמה לאומית, שכוללת הערכה של נקודות חולשה פוטנציאליות ברמה גבוהה של התקפה בהתאם ל-Common Criteria Application of Attack Potential to Smartcards.
  • [C-SR-2] מומלץ מאוד לכלול את החומרה שנבדקה באמצעות יעד אבטחה, רמת אמון בבדיקות (EAL) 5, עם תוספת של AVA_VAN.5. סביר להניח שאישור EAL 5 יהפוך לדרישה בגרסה עתידית.
  • [C-SR-3] מומלץ מאוד לספק עמידות בפני התקפות מבפנים (IAR). המשמעות היא שגורם פנימי עם גישה למפתחות החתימה של הקושחה לא יכול ליצור קושחה שגורמת לדליפה של סודות מ-StrongBox, לעקוף את דרישות האבטחה הפונקציונליות או לאפשר גישה לנתוני משתמשים רגישים בדרכים אחרות. הדרך המומלצת להטמיע את IAR היא לאפשר עדכוני קושחה רק כשסיסמת המשתמש הראשית מסופקת דרך ה-HAL של IAuthSecret.

9.11.3. המסמך לאימות הזהות

כדי להגדיר את מערכת פרטי הכניסה לזהות ולהשתמש בה, צריך להטמיע את כל ממשקי ה-API בחבילה android.security.identity.*. ממשקי ה-API האלה מאפשרים למפתחי אפליקציות לאחסן ולשלוף מסמכים של זהות משתמשים. הטמעות במכשירים:

• [C-SR-1] מומלץ מאוד להטמיע את מערכת פרטי הכניסה לזיהוי.

אם הטמעות במכשירים מטמיעות את מערכת פרטי הכניסה לזיהוי, הן:

• [C-1-1] חובה להחזיר ערך שאינו null בשיטה IdentityCredentialStore#getInstance().

• [C-1-2] חובה להטמיע את מערכת פרטי הכניסה לזהות (למשל ממשקי ה-API של android.security.identity.*) באמצעות קוד שמתקשר עם אפליקציה מהימנה באזור שמבודד בצורה מאובטחת מהקוד שפועל בליבה ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד הליבה או קוד מרחב המשתמש עשוי לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA.

• [C-1-3] הפעולות הקריפטוגרפיות הנדרשות להטמעת מערכת פרטי הכניסה לזיהוי (למשל, ממשקי ה-API של android.security.identity.*) חייבות להתבצע באופן מלא באפליקציה המהימנה, וחומר המפתח הפרטי לעולם לא יכול לצאת מסביבת הביצוע המבודדת, אלא אם נדרש באופן ספציפי על ידי ממשקי API ברמה גבוהה יותר (למשל, השיטה createEphemeralKeyPair()‎).

• [C-1-4] חובה להטמיע את האפליקציה המהימנה באופן שלא ישפיע על מאפייני האבטחה שלה (למשל, נתוני פרטי הכניסה לא יפורסמו אלא אם התנאים של בקרת הגישה מתקיימים, לא ניתן ליצור MAC לנתונים שרירותיים), גם אם מערכת Android פועלת באופן שגוי או נפרצה.

בפרויקט הקוד הפתוח של Android יש הטמעת עזר של אפליקציה מהימנה (libeic) שאפשר להשתמש בה כדי להטמיע את מערכת פרטי הכניסה לזיהוי.

9.12. מחיקת נתונים

כל הטמעות המכשירים:

• [C-0-1] חובה לספק למשתמשים מנגנון לביצוע 'איפוס לנתוני היצרן'.
• [C-0-2] חובה למחוק את כל הנתונים במערכת הקבצים של userdata כשמבצעים 'איפוס לנתוני היצרן'.
• [C-0-3] חובה למחוק את הנתונים באופן שיעמוד בתקני התעשייה הרלוונטיים, כמו NIST SP800-88, כשמעבירים את המכשיר ל'איפוס לנתוני היצרן'.
• [C-0-4] חובה להפעיל את התהליך 'איפוס להגדרות המקוריות' שמתואר למעלה כשאפליקציית הבקר לניהול מדיניות המכשירים (DPC) של המשתמש הראשי קוראת ל-API‏ DevicePolicyManager.wipeData().
• יכול להיות שתהיה אפשרות למחיקת נתונים מהירה שמתבצעת רק מחיקה לוגית של הנתונים.

9.13. מצב הפעלה בטוח

ב-Android יש מצב אתחול בטוח שמאפשר למשתמשים להפעיל את המכשיר במצב שבו רק אפליקציות מערכת מותקנות מראש יכולות לפעול, וכל האפליקציות של צד שלישי מושבתות. המצב הזה, שנקרא 'מצב הפעלה בטוח', מאפשר למשתמש להסיר אפליקציות צד שלישי שעלולות להזיק.

הטמעות במכשירים הן:

• [C-SR-1] STRONGLY RECOMMENDED to implement Safe Boot Mode

אם הטמעות במכשירים מיישמות את מצב ההפעלה הבטוח, הן:

• [C-1-1] חובה לספק למשתמש אפשרות להיכנס למצב הפעלה בטוח באופן שלא ניתן להפרעה מאפליקציות צד שלישי שמותקנות במכשיר, אלא אם אפליקציית הצד השלישי היא 'בקר מדיניות של מכשיר' והגדירה את הדגל UserManager.DISALLOW_SAFE_BOOT כ-true.

• [C-1-2] חובה לספק למשתמש את היכולת להסיר כל אפליקציה של צד שלישי במצב בטוח.

• צריך לספק למשתמש אפשרות להיכנס למצב הפעלה בטוח מתפריט האתחול באמצעות תהליך עבודה שונה מזה של הפעלה רגילה.

9.14. בידוד של מערכת הרכב

מכשירי Android Automotive צפויים להחליף נתונים עם תת-מערכות קריטיות ברכב באמצעות HAL של הרכב כדי לשלוח ולקבל הודעות ברשתות הרכב, כמו CAN bus.

כדי לאבטח את חילופי הנתונים, אפשר להטמיע תכונות אבטחה מתחת לשכבות המסגרת של Android כדי למנוע אינטראקציה זדונית או לא מכוונת עם המערכות המשניות האלה.

9.15. תוכניות מינויים

'תוכניות מינויים' מתייחסות לפרטי התוכנית של יחסי החיוב שספק הסלולר מספק דרך SubscriptionManager.setSubscriptionPlans().

כל הטמעות המכשירים:

• [C-0-1] חובה להחזיר תוכניות מינויים רק לאפליקציה של ספק הסלולר שממנה הן סופקו במקור.
• [C-0-2] אסור לגבות או להעלות מרחוק תוכניות מינויים.
• [C-0-3] חובה לאפשר רק שינויים מברירת המחדל, כמו SubscriptionManager.setSubscriptionOverrideCongested(), מאפליקציית ספק הסלולר שמספקת כרגע תוכניות מינויים תקפות.

9.16. העברת נתוני אפליקציות

אם הטמעות במכשירים כוללות יכולת להעביר נתונים ממכשיר למכשיר אחר ולא מגבילות את נתוני האפליקציה שהיא מעתיקה לנתונים שהוגדרו על ידי מפתח האפליקציה במניפסט באמצעות המאפיין android:fullBackupContent, הן:

• [C-1-1] אסור להתחיל העברות של נתוני אפליקציות ממכשירים שבהם המשתמש לא הגדיר אימות ראשי, כפי שמתואר בקטע 9.11.1 מסך נעילה מאובטח ואימות.
• [C-1-2] חובה לאשר באופן מאובטח את האימות הראשי במכשיר המקור, ולאשר עם המשתמש את הכוונה להעתיק את הנתונים במכשיר המקור לפני העברת הנתונים.
• [C-1-3] חובה להשתמש באימות של מפתח אבטחה כדי לוודא שגם מכשיר המקור וגם מכשיר היעד בהעברה בין מכשירים הם מכשירי Android חוקיים ושהתוכנה שלהם לאתחול נעולה.
• [C-1-4] חובה להעביר את נתוני האפליקציה רק לאותה אפליקציה במכשיר היעד, עם אותו שם חבילה ואותו אישור חתימה.
• [C-1-5] חובה להציג בתפריט ההגדרות אינדיקציה לכך שהנתונים הועברו למכשיר המקור באמצעות מיגרציית נתונים בין מכשירים. המשתמש לא אמור להיות מסוגל להסיר את ההנחיה הזו.

9.17. Android Virtualization Framework

אם המכשיר מטמיע תמיכה בממשקי ה-API של Android Virtualization Framework‏ (android.system.virtualmachine.*), המארח של Android:

• [C-1-1] חובה לתמוך בכל ממשקי ה-API שמוגדרים בחבילה android.system.virtualmachine.
• [C-1-2] אסור לשנות את Android SELinux ואת מודל ההרשאות לניהול של מכונות וירטואליות מוגנות (pVM).

• [C-1-3] אסור לשנות, להשמיט או להחליף את כללי neverallow שנמצאים ב-system/sepolicy שסופק ב-upstream של Android Open Source Project‏ (AOSP), ויש להקפיץ את המדיניות עם כל כללי neverallow הקיימים.

• [C-1-4] חובה לאפשר רק קוד חתום בפלטפורמה ואפליקציות עם הרשאותאסור לאפשר לקוד לא מהימן (למשל אפליקציות של צד שלישי) ליצור ולהריץ מכונה וירטואלית מוגנתpVM. הערה: יכול להיות שהדבר ישתנה בגרסאות עתידיות של Android.

• [C-1-5] אסור לאפשר למכונה וירטואלית מוגנת pVM להריץ קוד שלא נכלל בתמונת המפעל או בעדכונים שלה. אסור לאפשר להריץ במכונה וירטואלית מוגנת (Protected Virtual Machine) כל דבר שלא מכוסה על ידי Android Verified Boot (למשל, קבצים שהורדתם מהאינטרנט או קבצים שהעברתם להתקנה צדדית) .

יצירת דרישות חדשות

• [C-1-5] אסור לאפשר ל-pVM שלא ניתן לנפות באגים להריץ קוד מהקובץ הסטטי של היצרן או מעדכוני הפלטפורמה שלו, כולל עדכונים לאפליקציות בעלות הרשאות.

סיום הדרישות החדשות

אם המכשיר מטמיע תמיכה בממשקי ה-API של Android Virtualization Framework (android.system.virtualmachine.*), כל מכונה וירטואלית מוגנת (Protected Virtual Machine)‏ pVM :

• [C-2-1] חובה שאפשר יהיה להריץ את כל מערכות ההפעלה הזמינות ב-APEX של הווירטואליזציה במכונה וירטואלית מוגנת pVM .
• [C-2-2] אסור לאפשר למכונה וירטואלית מוגנת pVM להפעיל מערכת הפעלה שלא חתומה על ידי מי שמטמיע את המכשיר או על ידי ספק מערכת ההפעלה.
• [C-2-3] אסור לאפשר למכונה וירטואלית מוגנת pVM להריץ נתונים כקוד (למשל, SELinux neverallow execmem).

• [C-2-4] אסור לשנות, להשמיט או להחליף את כללי neverallow שנמצאים ב-system/sepolicy/microdroid שסופקו ב-upstream Android Open Source Project‏ (AOSP).

• [C-2-5] חובה להטמיע מנגנוני הגנה לעומק של מכונה וירטואלית מוגנת pVM (למשל SELinux למכונות pVM), גם במערכות הפעלה שאינן Microdroid.
• [C-2-6] חובה לוודא ש pVM נכשל קושחת הקצרה מסרבת להפעיל אם לא ניתן לאמת את התמונות הראשוניות שהמכונה הווירטואלית תפעל. חובה לבצע את האימות בתוך המכונה הווירטואלית.
• [C-2-7] חובה לוודא ש ה-pVM נכשל הקושחה מסרבת להפעיל את המכונה אם תקינות הקובץ instance.img נפגעת.

אם המכשיר מטמיע תמיכה בממשקי ה-API של Android Virtualization Framework (android.system.virtualmachine.*), אז hypervisor:

• [C-3-1] חובה לוודא שרק למכונה הווירטואלית עצמה או ל-hypervisor יש גישה לדפי הזיכרון שבבעלות בלעדית של מכונה וירטואלית (pVM או מכונה וירטואלית מארחת), ולא למכונות וירטואליות אחרות – מוגנות או לא מוגנות. אסור לאפשר למכונה וירטואלית לתפוס את המצב של pVM ולקבל גישה לדף ששייך לישות אחרת (כלומר, למכונה וירטואלית אחרת או למכונה וירטואלית להרצת מכונות וירטואליות אחרת), אלא אם הבעלים של הדף משתף אותו באופן מפורש. כולל את המכונה הווירטואלית המארחת. הכלל הזה חל גם על גישה של מעבד וגם על גישה של DMA.
• [C-3-2] חובה למחוק דף אחרי שpVM משתמש בו, ולפני שהוא מוחזר למארח (למשל, ה-pVM נהרס).
• [C-3-3SR-1] מומלץ מאוד לוודא חובה לוודא שהקושחה של ה-pVM נטענת ומופעלת לפני כל קוד ב-pVM.
• [C-3-4] חובה לוודא שכל מכונה וירטואלית יוצרת סוד לכל מכונה וירטואלית, {Boot Certificate Chain (BCC) and Compound Device Identifier (CDIs) provided to a pVM instance שרק המכונת הווירטואלית הספציפית הזו יכולה ליצור והוא משתנה לאחר איפוס להגדרות המקוריות (factory reset) ו-OTA.

אם המכשיר מטמיע תמיכה בממשקי ה-API של Android Virtualization Framework, אז בכל האזורים:

• [C-4-1] אסור לספק ל-pVM פונקציונליות שמאפשרת לעקוף את מודל האבטחה של Android.

אם המכשיר מטמיע תמיכה בממשקי ה-API של Android Virtualization Framework, אז:

• [C-5-1] חובה לתמוך ב-Isolated Compilation אבל אפשר להשבית את התכונה Isolated Compilation במכשיר שנשלח במהלך עדכון של סביבת זמן הריצה של ART.

אם המכשיר מטמיע תמיכה ב-API של Android Virtualization Framework, אז לניהול מפתחות:

• [C-6-1] חובה לבצע רוט של שרשרת DICE בנקודה שהמשתמש לא יכול לשנות, גם במכשירים שלא ננעלו. (כדי לוודא שלא ניתן יהיה לזייף אותה).

• [C-SR-26-2] מומלץ מאוד להשתמש ב-DICE כמנגנון להסקת סודות לכל מכונה וירטואלית. חובה לבצע את DICE בצורה נכונה, כלומר לספק את הערכים הנכונים.

10. בדיקת תאימות של תוכנות

הטמעות של מכשירים חייבות לעבור את כל הבדיקות שמתוארות בקטע הזה. עם זאת, חשוב לזכור שאף חבילת בדיקות תוכנה לא מקיפה לחלוטין. לכן, מומלץ מאוד למטמיעים של מכשירים לבצע את המספר המינימלי האפשרי של שינויים בהטמעה המועדפת והמומלצת של Android שזמינה בפרויקט Android Open Source. כך תוכלו לצמצם את הסיכון להוספת באגים שיוצרים אי-תאימות, שדורשים עבודה מחדש ועדכוני מכשירים פוטנציאליים.

10.1. חבילה לבדיקות תאימות (CTS)

הטמעות במכשירים:

• [C-0-1] חובה לעבור את Android Compatibility Test Suite‏ (CTS) שזמין ב-Android Open Source Project, באמצעות תוכנת האספקה הסופית במכשיר.

• [C-0-2] חובה לוודא תאימות במקרים של עמימות ב-CTS ובכל הטמעה מחדש של חלקים מקוד המקור של ההפניה.

ה-CTS מיועד להרצה במכשיר בפועל. כמו כל תוכנה, גם CTS יכול להכיל באגים. הגרסה של CTS תהיה עצמאית מהגדרת התאימות הזו, ויכול להיות שיושקו כמה גרסאות של CTS ל-Android 14.

הטמעות במכשירים:

• [C-0-3] חובה לעבור את גרסת CTS העדכנית ביותר שזמינה בזמן השלמת תוכנת המכשיר.

• מומלץ להשתמש בהטמעת העזר ב-Android Open Source Tree כמה שיותר.

10.2. CTS Verifier

CTS Verifier נכלל בחבילת בדיקות התאימות, והוא מיועד להפעלה על ידי מפעיל אנושי כדי לבדוק פונקציונליות שלא ניתן לבדוק באמצעות מערכת אוטומטית, כמו הפעולה הנכונה של מצלמה וחיישנים.

הטמעות במכשירים:

• [C-0-1] חובה להריץ בצורה נכונה את כל התרחישים הרלוונטיים באימות CTS.

ב-CTS Verifier יש בדיקות לסוגים רבים של חומרה, כולל חומרה חלקית שהיא אופציונלית.

הטמעות במכשירים:

• [C-0-2] חובה לעבור את כל הבדיקות של החומרה שיש במכשיר. לדוגמה, אם במכשיר יש תאוצה, חובה להריץ בצורה נכונה את תרחיש הבדיקה של התאוצה ב-CTS Verifier.

מותר לדלג על תרחישי בדיקה של תכונות שצוינו כאופציונליות במסמך הגדרת התאימות הזה, או להשמיט אותן.

• [C-0-2] כל מכשיר וכל גרסה של build חייבים להריץ בצורה תקינה את CTS Verifier, כפי שצוין למעלה. עם זאת, מאחר שגרסאות build רבות דומות מאוד, לא צפוי שמטמיעים של מכשירים ירוצו במפורש את CTS Verifier על גרסאות build ששונות רק בדרכים טריוויאליות. באופן ספציפי, הטמעות של מכשירים ששונות מהטמעה שעברה את CTS Verifier רק במיקומים שונים, בסמלי מותג וכו', יכולות להשמיט את הבדיקה של CTS Verifier.

11. תוכנה שניתן לעדכן

• [C-0-1] הטמעות של מכשירים חייבות לכלול מנגנון להחלפת כל תוכנת המערכת. המנגנון לא חייב לבצע שדרוגים 'בזמן אמת', כלומר יכול להיות שיהיה צורך בהפעלה מחדש של המכשיר. אפשר להשתמש בכל שיטה, בתנאי שהיא יכולה להחליף את כל התוכנות שמותקנות מראש במכשיר. לדוגמה, כל אחת מהגישות הבאות תעמוד בדרישות האלה:

  • הורדות 'Over-the-air (OTA)' עם עדכון אופליין באמצעות הפעלה מחדש.
  • עדכונים 'מחוברים' בחיבור USB ממחשב מארח.
  • עדכונים 'לא מקוונים' באמצעות הפעלה מחדש ועדכון מקובץ באחסון נשלף.

• [C-0-2] מנגנון העדכון שבו נעשה שימוש חייב לתמוך בעדכונים בלי למחוק את נתוני המשתמשים. כלומר, מנגנון העדכון חייב לשמור על נתונים פרטיים של האפליקציה ועל נתונים משותפים של האפליקציה. שימו לב שתוכנת Android ב-upstream כוללת מנגנון עדכון שעומד בדרישות האלה.

• [C-0-3] חובה לחתום על כל העדכון, ומנגנון העדכון במכשיר חייב לאמת את העדכון והחתימה באמצעות מפתח ציבורי שנשמר במכשיר.

• [C-SR-1] מומלץ מאוד שמנגנון החתימה יבצע גיבוב של העדכון באמצעות SHA-256 ויאמת את הגיבוב באמצעות המפתח הציבורי באמצעות ECDSA NIST P-256.

אם הטמעות המכשיר כוללות תמיכה בחיבור נתונים ללא חיוב לפי שימוש, כמו פרופיל 802.11 או Bluetooth PAN (רשת אזור אישית), הן:

• [C-1-1] חובה לתמוך בהורדות OTA עם עדכון אופליין באמצעות הפעלה מחדש.

בהטמעות של מכשירים, צריך לוודא שתמונת המערכת זהה לקוד הבינארי של התוצאה הצפויה לאחר עדכון OTA. ההטמעה של OTA שמבוססת על בלוקים ב-Android Open Source Project, שנוספה מאז Android 5.1, עומדת בדרישות האלה.

בנוסף, הטמעות במכשירים אמורות לתמוך בעדכוני מערכת מסוג A/B. התכונה הזו מיושמת ב-AOSP באמצעות HAL לבקרת אתחול.

אם נמצאת שגיאה בהטמעת מכשיר אחרי שהמכשיר שוחרר, אבל במהלך משך החיים הסביר של המוצר, שנקבע בהתייעצות עם צוות התאימות של Android, והיא משפיעה על התאימות של אפליקציות של צד שלישי, אז:

• [C-2-1] מי שמטמיע את המכשיר חייב לתקן את השגיאה באמצעות עדכון תוכנה זמין שאפשר להחיל בהתאם למנגנון שמתואר למעלה.

מערכת Android כוללת תכונות שמאפשרות לאפליקציית הבעלים של המכשיר (אם היא קיימת) לשלוט בהתקנה של עדכוני המערכת. אם מערכת המשנה של עדכוני המערכת למכשירים מדווחת על android.software.device_admin, המשמעות היא שהמכשירים:

• [C-3-1] חובה להטמיע את ההתנהגות שמתוארת בכיתה SystemUpdatePolicy.

12. יומן השינויים של המסמך

סיכום של השינויים בהגדרת התאימות בגרסה הזו:

• תיעוד של יומן השינויים

13. יצירת קשר

אתם יכולים להצטרף לפורום התאימות ל-Android ולבקש הבהרות או להעלות בעיות שלדעתכם לא מפורטות במסמך.