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

1. מבוא

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1. חומרה

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

• [7.1.1.1/H-0-1] חייב להיות לפחות צג אחד תואם ל-Android שעומד בכל הדרישות שמפורטות במסמך הזה.
• [7.1.1.3/H-SR] מומלץ מאוד לספק למשתמשים אפשרות לשנות את גודל התצוגה (דחיסות המסך).

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

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

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

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

אם בהטמעות של מכשירים ניידים מצוין שהן תומכות במסכים עם טווח דינמי גבוה (HDR) באמצעות 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 ושל שלבי עיבוד 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-3] חובה לספק את פונקציית דף הבית בכל המסכים התואמים ל-Android שמציגים את מסך הבית.
• [7.2.3/H-0-4] חובה לספק את הפונקציה 'חזרה' בכל המסכים התואמים ל-Android ואת הפונקציה 'פריטים אחרונים' לפחות באחד מהמסכים התואמים ל-Android.
• [7.2.3/H-0-2] חובה לשלוח לאפליקציה שבחזית גם את האירוע הרגיל וגם את האירוע של לחיצה ארוכה על פונקציית החזרה אחורה (KEYCODE_BACK). אסור שהמערכת תשתמש באירועים האלה, והם יכולים להיות מופעלים מחוץ למכשיר Android (למשל, מקלדת חומרה חיצונית שמחוברת למכשיר Android).
• [7.2.4/H-0-1] חובה לתמוך בהזנה במסך מגע.
• [7.2.4/H-SR] מומלץ מאוד להפעיל את אפליקציית העזרה שבחר המשתמש, כלומר האפליקציה שמטמיעה את VoiceInteractionService, או פעילות שמטפלת באירוע ACTION_ASSIST של לחיצה ארוכה על KEYCODE_MEDIA_PLAY_PAUSE או על KEYCODE_HEADSETHOOK אם הפעילות בחזית לא מטפלת באירועים האלה של לחיצה ארוכה.
• [7.3.1/H-SR] מומלץ מאוד לכלול מד תאוצה ב-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] מומלץ לתמוך בחיישני תנוחה עם 6 דרגות חופש.
• [7.4.3/H] צריכה לכלול תמיכה ב-Bluetooth וב-Bluetooth LE.

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

• [7.4.7/H-1-1] חובה לספק את מצב חיסכון בחבילת הגלישה.

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

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

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

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

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

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

• [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 עם התפקיד 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] מומלץ מאוד לבצע ספירה של מתארי USB, לזהות סוגי מסופים ולשדר את ה-Intent ACTION_HEADSET_PLUG תוך פחות מ-1, 000 אלפיות השנייה לאחר חיבור של ציוד אודיו היקפי מסוג USB-C.

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

• [7.10/H-SR]* מומלץ מאוד לא להשתמש במפעיל (רטט) הפיזי של מסה מסתובבת חריגה(ERM).
• [7.10/H]* יש למקם את המפעיל ליד המיקום שבו המכשיר בדרך כלל מוחזק או נגע בו בידיים.
• [7.10/H-SR]* מומלץ מאוד להטמיע את כל הקבועים הציבוריים של החזקות ברורות ב-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-SR]* מומלץ מאוד להטמיע את כל הקבועים הציבוריים של רטט ברור ב-android.os.VibrationEffect, כלומר (EFFECT_TICK,‏ EFFECT_CLICK,‏ EFFECT_HEAVY_CLICK ו-EFFECT_DOUBLE_CLICK), ואת כל הקבועים הציבוריים של רטט עשיר ב-android.os.VibrationEffect.Composition, כלומר (PRIMITIVE_CLICK ו-PRIMITIVE_TICK).
• [7.10/H-SR]* מומלץ מאוד להשתמש במיפויים האלה של קבועים היפטיים מקושרים.
• [7.10/H-SR]* מומלץ מאוד לפעול בהתאם לבדיקת האיכות של ממשקי ה-API createOneShot()‎ ו-createWaveform()‎.
• [7.10/H-SR]* מומלץ מאוד לבדוק את היכולות של התאמת העוצמה על ידי הפעלת android.os.Vibrator.hasAmplitudeControl().

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

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

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

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

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

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

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

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

2.2.3. תוכנות

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

• [3.2.3.1/H-0-1] חובה שתהיה אפליקציה שמטפלת בכוונות ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE ו-ACTION_CREATE_DOCUMENT כפי שמתואר במסמכי ה-SDK, ומספקת למשתמש גישה לנתונים של ספק המסמכים באמצעות ממשק ה-API DocumentsProvider.
• [3.2.3.1/H-0-2]* חובה לטעון מראש אפליקציה אחת או יותר או רכיבי שירות עם בורר כוונות, לכל דפוסי המסננים הציבוריים של הכוונות שמוגדרים על ידי כוונות האפליקציה הבאות שמפורטות כאן.
• [3.2.3.1/H-SR] מומלץ מאוד לטעון מראש אפליקציית אימייל שיכולה לטפל בכוונות 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] מומלץ מאוד להטמיע מרכז אפליקציות שמוגדר כברירת מחדל ותומך בהצמדה של קיצורי דרך, ווידג'טים ו-widgetFeatures בתוך האפליקציה.
• [3.8.1/H-SR] מומלץ מאוד להטמיע מרכז אפליקציות שמספק גישה מהירה לקיצורי הדרך הנוספים שמוצעים על ידי אפליקציות צד שלישי באמצעות ה-API של ShortcutManager.
• [3.8.1/H-SR] מומלץ מאוד לכלול אפליקציית מרכז אפליקציות שמוגדרת כברירת מחדל ומציגה תגים לסמלי האפליקציות.
• [3.8.2/H-SR] מומלץ מאוד לתמוך בווידג'טים של אפליקציות צד שלישי.
• [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] מומלץ מאוד להציג את האפשרות הראשונה שצוינה באמצעות RemoteInput.Builder setChoices() בסרגל ההתראות, ללא אינטראקציה נוספת של המשתמש.
• [3.8.3/H-SR] מומלץ מאוד להציג את כל האפשרויות שמוצגות דרך RemoteInput.Builder setChoices() בלוח ההתראות כשהמשתמש מרחב את כל ההתראות בלוח ההתראות.
• [3.8.3.1/H-SR] מומלץ מאוד להציג פעולות שעבורן Notification.Action.Builder.setContextual מוגדר כ-true בהתאם לתשובות שמוצגות על ידי Notification.Remoteinput.Builder.setChoices.
• [3.8.4/H-SR] מומלץ מאוד להטמיע עוזרת במכשיר כדי לטפל בפעולת העזרה.

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

• [3.8.4/H-SR] מומלץ מאוד להשתמש בלחיצה ארוכה על המקש HOME כאינטראקציה הייעודית להפעלת אפליקציית העזרה, כפי שמתואר בקטע 7.2.3. חובה להפעיל את אפליקציית העזרה שבחר המשתמש, כלומר האפליקציה שמטמיעה את VoiceInteractionService , או פעילות שמטפלת בכוונה 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.
• [3.9/H-1-2] חובה להצהיר על תמיכה בפרופילים מנוהלים באמצעות דגל התכונה android.software.managed_users, אלא אם המכשיר מוגדר כך שהוא ידווח על עצמו כמכשיר עם נפח RAM נמוך או כך שהוא מקצה אחסון פנימי (לא ניתן להסרה) כאחסון משותף.

אם הטמעות של מכשירים ניידים כוללות תמיכה בממשקי ה-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-2-1] חובה לדווח על null לממשקי ה-API של ControlsProviderService ושל Control.
• [3.8.16/H-2-2] חובה להצהיר על דגל התכונה android.software.controls ולהגדיר אותו לערך false.

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

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

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

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

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

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

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

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

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] חובה לדווח על צריכת החשמל של המעבד (CPU) לכל מזהה משתמש (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 ולהציג תפריט הגדרות שבו מוצג השימוש בחשמל.

2.2.5. מודל אבטחה

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

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

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

• [9.11/H-0-2]* חובה לגבות את הטמעת מאגר המפתחות באמצעות סביבת הפעלה מבודדת.
• [9.11/H-0-3]* חייב לכלול הטמעות של אלגוריתמים קריפטוגרפיים מסוג RSA,‏ AES,‏ ECDSA ו-HMAC ופונקציות גיבוב ממשפחת MD5,‏ SHA1 ו-SHA-2, כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בליבה ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד של ליבה או של מרחב משתמש עשוי לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. בפרויקט Android Open Source Project (AOSP) ב-upstream מתקיימים הדרישות האלה באמצעות ההטמעה של Trusty, אבל יש גם אפשרויות חלופיות: פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת של בידוד תקין שמבוסס על hypervisor, שעבר בדיקה על ידי צד שלישי.
• [9.11/H-0-4]* חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק אם הוא מצליח, לאפשר שימוש במפתחות שמקושרים לאימות. חובה לאחסן את פרטי הכניסה של מסך הנעילה באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. בפרויקט הקוד הפתוח של Android שמשמש כמקור (upstream) יש את שכבת האובייקטיפיקציה של החומרה (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 עומדת בדרישות כמצב נעילה.

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

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

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

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

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

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

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

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

• Perfetto
  • [6.1/H-0-2]* חובה לחשוף קובץ בינארי של /system/bin/perfetto למשתמש המעטפת, כאשר cmdline תואם למסמכי התיעוד של 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 traced כברירת מחדל (מאפיין המערכת persist.traced.enable).

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

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

2.2.7.1. מדיה

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

• [5.1/H-1-1] חובה לפרסם את המספר המקסימלי של סשנים של מקודד וידאו לחומרה שאפשר להריץ בו-זמנית בכל שילוב של קודקים באמצעות השיטות CodecCapabilities.getMaxSupportedInstances() ו-VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-2] חובה לתמוך ב-6 מופעים של סשנים של מקודד וידאו בחומרה (AVC או HEVC) בכל שילוב של קודקים שפועלים בו-זמנית ברזולוציה של 720p‏@30fps.
• [5.1/H-1-3] חובה לפרסם את המספר המקסימלי של סשנים של מקודד וידאו לחומרה שאפשר להריץ בו-זמנית בכל שילוב של קודק באמצעות השיטות CodecCapabilities.getMaxSupportedInstances() ו-VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-4] חובה לתמוך ב-6 מופעים של סשנים של מקודד וידאו בחומרה (AVC או HEVC) בכל שילוב של קודקים שפועלים בו-זמנית ברזולוציה של 720p‏@30fps.
• [5.1/H-1-5] חובה לפרסם את המספר המקסימלי של סשנים של מקודד וידאו לחומרה ושל מפענח וידאו לחומרה שאפשר להריץ בו-זמנית בכל שילוב של קודק באמצעות השיטות CodecCapabilities.getMaxSupportedInstances() ו-VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-6] חובה לתמוך ב-6 מופעים של סשנים של פענוח וידאו בחומרה וקידוד וידאו בחומרה (AVC או HEVC) בכל שילוב של קודקים שפועלים בו-זמנית ברזולוציה של 720p‏@30fps.
• [5.1/H-1-7] זמן האחזור להפעלת הקודק חייב להיות 65 אלפיות השנייה או פחות בסשן קידוד וידאו ברזולוציה של 1080p או פחות, לכל מכשירי הקידוד החומריים של וידאו (מלבד קודק Dolby Vision) במצב עומס. כאן, עומס מוגדר כסשן המרה בו-זמנית של וידאו בלבד מ-1080p ל-720p באמצעות רכיבי קודק וידאו בחומרה, יחד עם האתחול של צילום אודיו-וידאו ב-1080p.
• [5.1/H-1-8] זמן האחזור להפעלת הקודק חייב להיות 50 אלפיות שנייה או פחות בסשן קידוד אודיו של 128kbps או פחות לכל המקודדים של האודיו במצב עומס.עומס מוגדר כאן כסשן המרה בו-זמנית של וידאו בלבד מ-1080p ל-720p באמצעות רכיבי קודק וידאו בחומרה, יחד עם ההפעלה של הקלטת האודיו-וידאו ב-1080p.
• [5.3/H-1-1] אסור לאבד יותר מפריים אחד ב-10 שניות (כלומר פחות מ-0.333 אחוז אובדן פריימים) בסשן וידאו באיכות 1080p ובקצב פריימים של 30FPS במצב עומס. עומס מוגדר כסשן המרה בו-זמנית של וידאו בלבד מ-1080p ל-720p באמצעות רכיבי קודק וידאו לחומרה, וכן הפעלת אודיו AAC של 128kbps.
• [5.3/H-1-2] אסור לאבד יותר מפריים אחד ב-10 שניות במהלך שינוי ברזולוציית הווידאו בסשן וידאו של 30fps בזמן עומס. עומס מוגדר בתור סשן המרה בו-זמנית של וידאו בלבד מ-1080p ל-720p באמצעות רכיבי קודק וידאו לחומרה, וכן הפעלת אודיו AAC של 128Kbps.
• [5.6/H-1-1] זמן האחזור של הקשה לצלצול חייב להיות פחות מ-100 אלפיות השנייה באמצעות הבדיקה של הקשה לצלצול ב-OboeTester או הבדיקה של הקשה לצלצול ב-CTS Verifier.

2.2.7.2. מצלמה

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

• [7.5/H-1-1] חייבת להיות מצלמה ראשית אחורית ברזולוציה של לפחות 12 מגה-פיקסלים שתומכת בצילומי וידאו ברזולוציית 4K‏@30fps. המצלמה האחורית הראשית היא המצלמה האחורית עם מזהה המצלמה הנמוך ביותר.
• [7.5/H-1-2] חייבת להיות מצלמה קדמית ראשית ברזולוציה של לפחות 4 מגה-פיקסלים שתומכת בצילומי וידאו ברזולוציית 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 חייב להיות קטן מ-1,000ms ברזולוציה של 1080p, כפי שנמדד על ידי בדיקת הביצועים של מצלמת CTS בתנאים של תאורה ITS (3,000K) בשתי המצלמות הראשיות.
• [7.5/H-1-6] זמן האחזור של הפעלת camera2 (פתיחת המצלמה עד לפריים הראשון בתצוגה המקדימה) חייב להיות קטן מ-600ms, כפי שנמדד על ידי בדיקת הביצועים של מצלמת CTS בתנאים של תאורה ITS (3000K) בשתי המצלמות הראשיות.

2.2.7.3. חומרה

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

• [7.1.1.1/H-1-1] הרזולוציה של המסך חייבת להיות לפחות 1080p.
• [7.1.1.3/H-1-1] צפיפות המסך חייבת להיות לפחות 400 dpi.
• [7.6.1/H-1-1] חייב להיות זיכרון פיזי בנפח 6GB לפחות.

2.2.7.4. ביצועים

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

• [8.2/H-1-1] חובה להבטיח ביצועי כתיבה רצופים של לפחות 100MB/s.
• [8.2/H-1-2] חובה להבטיח ביצועי כתיבה אקראיים של לפחות 10MB/s.
• [8.2/H-1-3] חובה להבטיח ביצועי קריאה רצופים של לפחות 200MB/s.
• [8.2/H-1-4] חובה להבטיח ביצועי קריאה אקראית של לפחות 25MB/s.

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

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

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

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

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

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.2/T-SR] מומלץ מאוד לתמוך בקידוד 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

הטמעות של מכשירי טלוויזיה חייבות לתמוך בפענוחי 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
• [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 פריימים לשנייה עם Main Profile Level 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-2-1] מומלץ מאוד לתמוך בפרופיל הפענוח של UHD בקצב של 60 פריימים לשנייה עם פרופיל 2 (עומק צבע של 10 ביט).

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

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

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

• [5.8/T-0-1] חובה להגדיר את מצב הפלט של HDMI כדי לבחור את הרזולוציה המקסימלית שניתן לתמוך בה עם קצב רענון של 50Hz או 60Hz.
• [5.8/T-SR] מומלץ מאוד לספק בורר של קצב רענון 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] חובה לטעון מראש אפליקציה אחת או יותר או רכיבי שירות עם בורר כוונות, לכל דפוסי המסננים הציבוריים של הכוונות שמוגדרים על ידי כוונות האפליקציה הבאות שמפורטות כאן.
• [3.4.1/T-0-1] חובה לספק הטמעה מלאה של ה-API של android.webkit.Webview.

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

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

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

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

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

• [3.11/T-SR] מומלץ מאוד לכלול מנוע 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.11/T-0-1] חובה לגבות את הטמעת מאגר המפתחות באמצעות סביבת הפעלה מבודדת.
• [9.11/T-0-2] חובה שתהיה הטמעה של אלגוריתמים קריפטוגרפיים מסוג RSA,‏ AES,‏ ECDSA ו-HMAC ופונקציות גיבוב ממשפחת MD5,‏ SHA1 ו-SHA-2 כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בליבה ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד של ליבה או של מרחב משתמש עשוי לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. בפרויקט Android Open Source Project (AOSP) ב-upstream מתקיימים הדרישות האלה באמצעות ההטמעה של Trusty, אבל יש גם אפשרויות חלופיות: פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת של בידוד תקין שמבוסס על hypervisor, שעבר בדיקה על ידי צד שלישי.
• [9.11/T-0-3] חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק אם הוא מצליח, לאפשר שימוש במפתחות שמקושרים לאימות. חובה לאחסן את פרטי הכניסה של מסך הנעילה באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. בפרויקט הקוד הפתוח של Android שמשמש כמקור (upstream) יש את שכבת האובייקטיפיקציה של החומרה (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.

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

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

• Perfetto
  • [6.1/T-0-1] חובה לחשוף למשתמש המעטפת קובץ בינארי של /system/bin/perfetto, ש-cmdline שלו תואם למסמכי התיעוד של 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] מומלץ מאוד לכלול מד תאוצה ב-3 צירים.

אם הטמעות של מכשירי שעון כוללות מקלט 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] מומלץ מאוד להטמיע עוזרת במכשיר כדי לטפל בפעולת העזרה.

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

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

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

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

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

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

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

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

הטמעות של מכשירי 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 כוללות כמה משתמשים ולא מצהירות על דגל התכונה android.hardware.telephony, הן:

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

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

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

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-0-1] יכול לבצע חישוב משוער של מיקום על ידי שילוב של GPS/GNSS עם חיישנים נוספים. אם המיקום נקבע לפי חישוב משוער, מומלץ מאוד להטמיע את סוגי החיישנים המתאימים ו/או את מזהי הנכסים של הרכב שבהם נעשה שימוש ולדווח עליהם.
• [7.3/A-0-2] אסור לבצע התאמה למפה של המיקום המבוקש באמצעות LocationManager#requestLocationUpdates()‎.

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

• [7.3.1/A-1-1] חייב להיות אפשרי לדווח על אירועים עד תדירות של 100Hz לפחות.
• [7.3.1/A-1-2] חייב לעמוד בדרישות של מערכת הקואורדינטות של חיישן הרכב ב-Android.

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

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

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

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

• [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] מומלץ מאוד לתמוך בפרופיל גישה להודעות (MAP).

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

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

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

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

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

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

• [7.5/A-1-1] אסור שיהיו מצלמות חיצוניות שאפשר לגשת אליהן דרך Android Camera APIs, אלא אם הן עומדות בדרישות הליבה של המצלמה.
• [7.5/A-SR] מומלץ מאוד לא לסובב את התצוגה המקדימה של המצלמה או להפוך אותה לרוחב.
• [7.5.5/A-SR] מומלץ מאוד שהצילום יתבצע כך שהציר הארוך של המצלמה יתיישר עם האופק.
• [7.5/A-SR] מומלץ מאוד שהרזולוציה שלהן תהיה לפחות 1.3 מגה-פיקסלים.
• צריכה להיות להם חומרה עם מיקוד קבוע או חומרה עם EDOF (עומק שדה מורחב).
• צריכה להיות תמיכה ב-Android synchronization framework.
• יכול להיות שמיקוד אוטומטי בחומרה או מיקוד אוטומטי בתוכנה יוטמעו במנהל המצלמה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אם הטמעות של מכשירי רכב הן ב-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] 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.3/A-0-1] חובה להציג התראות שמשתמשות ב-API של Notification.CarExtender כשאפליקציות צד שלישי מבקשות זאת.

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

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

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

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

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

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

• [3.14/A-0-1] חובה לכלול מסגרת של ממשק משתמש כדי לתמוך באפליקציות של צד שלישי שמשתמשות בממשקי ה-API של המדיה, כפי שמתואר בקטע 3.14.
• [3.14/A-0-2] חובה לאפשר למשתמש לקיים אינטראקציה בטוחה עם אפליקציות מדיה בזמן נהיגה.
• [3.14/A-0-3] חובה לתמוך בפעולה המשתמעת של כוונה (Intent) מסוג CAR_INTENT_ACTION_MEDIA_TEMPLATE עם הרכיב הנוסף 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] חובה לדווח על צריכת החשמל של המעבד (CPU) לכל מזהה משתמש (UID) של תהליך. פרויקט הקוד הפתוח של Android עומד בדרישות באמצעות הטמעת מודול הליבה uid_cputime.
• [8.4/א] צריך לשייך לרכיב החומרה עצמו אם לא ניתן לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.
• [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] חובה לתמוך באפשרות ליצור משתמש אורח גם אם מספר המשתמשים המקסימלי במכשיר הגיע למכסה.

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

• [9.11/A-0-1] חובה לגבות את הטמעת מאגר המפתחות באמצעות סביבת הפעלה מבודדת.
• [9.11/A-0-2] חובה שתהיה הטמעה של אלגוריתמים קריפטוגרפיים מסוג RSA,‏ AES,‏ ECDSA ו-HMAC ופונקציות גיבוב ממשפחת MD5,‏ SHA1 ו-SHA-2 כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בליבה ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד של ליבה או של מרחב משתמש עשוי לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. בפרויקט Android Open Source Project (AOSP) ב-upstream מתקיימים הדרישות האלה באמצעות ההטמעה של Trusty, אבל יש גם אפשרויות חלופיות: פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת של בידוד תקין שמבוסס על hypervisor, שעבר בדיקה על ידי צד שלישי.
• [9.11/A-0-3] חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק אם הוא מצליח, לאפשר שימוש במפתחות שמקושרים לאימות. חובה לאחסן את פרטי הכניסה של מסך הנעילה באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. בפרויקט הקוד הפתוח של Android שמשמש כמקור (upstream) יש את שכבת האובייקטיפיקציה של החומרה (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 Tablet הוא הטמעה של מכשיר Android שבדרך כלל עומדת בכל הקריטריונים הבאים:

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

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

2.6.1. חומרה

גודל המסך

• [7.1.1.1/Tab-0-1] חייב להיות מסך בגודל של 18 עד 46 ס"מ.

ג'ירוסקופ

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

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

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

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

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

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

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

• [C-SR] מומלץ מאוד לטעון מראש אפליקציה אחת או יותר או רכיבי שירות עם בורר כוונות, לכל דפוסי המסננים הציבוריים של הכוונות שמוגדרים על ידי כוונות האפליקציה הבאות שמפורטות כאן, ולספק השלמה, כלומר לעמוד בציפיות של המפתחות לגבי כוונות האפליקציה הנפוצות האלה כפי שמתואר ב-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 ב-upstream.
• [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 שמכבד דפוסי Intent חדשים או דפוסי Intent של שידור באמצעות 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, הן:

• [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] חובה לפעול בהתאם למנגנוני ה-Intent‏ android.intent.action.SENDTO ו-android.intent.action.VIEW ולספק פעילות לשליחה/להצגה של הודעות SMS.
• [C-SR] מומלץ מאוד לתמוך בכוונות (intents) android.intent.action.ANSWER,‏ android.intent.action.CALL,‏ android.intent.action.CALL_BUTTON,‏ android.intent.action.VIEW ו-android.intent.action.DIAL באמצעות אפליקציית חיוג שהוטענה מראש, שיכולה לטפל בכוונות האלה ולספק את הביצוע כפי שמתואר ב-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.

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

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

אם הטמעות במכשירים מדווחות על 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-1] חובה לכבד את הכוונה android.media.action.STILL_IMAGE_CAMERA ו-android.media.action.STILL_IMAGE_CAMERA_SECURE ולהפעיל את המצלמה במצב צילום תמונה סטילס כפי שמתואר ב-SDK.
• [C-12-2] חובה לכבד את הכוונה של android.media.action.VIDEO_CAMERA להפעיל את המצלמה במצב וידאו כפי שמתואר ב-SDK.
• [C-12-3] חובה לאפשר רק לאפליקציות Android שמותקנות מראש לטפל בכוונות הבאות: MediaStore.ACTION_IMAGE_CAPTURE, ‏ MediaStore.ACTION_IMAGE_CAPTURE_SECURE ו-MediaStore.ACTION_VIDEO_CAPTURE, כפי שמתואר במסמך ה-SDK.

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

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

• [C-13-2] חובה לפעול בהתאם לכוונות (intents) הבאות: android.app.action.ADMIN_POLICY_COMPLIANCE,‏ android.app.action.GET_PROVISIONING_MODE,‏ android.app.action.PROVISIONING_SUCCESSFUL,‏ android.app.action.PROVISION_MANAGED_DEVICE,‏ 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, ולכלול פעילות שמספקת את הטיפול בכוונות האלה כפי שמתואר ב-SDK כאן.

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

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

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

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

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

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

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

• [C-SR] מומלץ מאוד להוסיף פעילות ל-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.

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 מקורי

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

• [SR] מומלץ מאוד להשתמש בהטמעות של הספריות שמפורטות בהמשך מ-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] חובה לדווח, באמצעות הפרמטרים שלמעלה, על קבוצת משנה של רשימת ה-ABIs הבאה, אסור לדווח על 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, וגם של התוספים 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 תהיה תמיכה ב-ABI נוספים.

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

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

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

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

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

• [C-1-1] חובה לספק למשתמש אמצעי גישה שבו הוא יוכל לראות את רשימת האפליקציות המוגבלות.
• [C-1-2] חובה לספק למשתמשים אפשרות להפעיל או להשבית את ההגבלות בכל אפליקציה.
• [C-1-3] אסור להחיל הגבלות באופן אוטומטי ללא הוכחה להתנהגות לא תקינה של בריאות המערכת, אבל מותר להחיל את ההגבלות על אפליקציות לאחר זיהוי של התנהגות לא תקינה של בריאות המערכת, כמו נעילה תקועה של מצב פעילות, שירותים שפועלים זמן רב וקריטריונים אחרים. הקריטריונים עשויים להיקבע על ידי מפתחי המכשירים, אבל הם חייבים להיות קשורים להשפעה של האפליקציה על תקינות המערכת. אסור להשתמש בקריטריונים אחרים שלא קשורים באופן ישיר לבריאות המערכת, כמו חוסר הפופולריות של האפליקציה בשוק.
• [C-1-4] אסור להחיל באופן אוטומטי הגבלות על אפליקציות כשמשתמש השבית את ההגבלות על האפליקציות באופן ידני, ומותר להציע למשתמש להחיל הגבלות על האפליקציות.
• [C-1-5] חובה להודיע למשתמשים אם מגבלות על אפליקציות חלות על אפליקציה באופן אוטומטי. חובה לספק את המידע הזה תוך 24 שעות ממועד החלת ההגבלות.
• [C-1-6] חובה להחזיר את הערך true עבור ActivityManager.isBackgroundRestricted() כשהאפליקציה המוגבלת קוראת ל-API הזה.
• [C-1-7] אסור להגביל את האפליקציה העיקרית שבחזית שמשתמשים בה באופן מפורש.
• [C-1-8] חובה להשעות את ההגבלות על אפליקציה שהופכת לאפליקציה העליונה בחזית כשהמשתמש מתחיל להשתמש באופן מפורש באפליקציה שהייתה מוגבלת.

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

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

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

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

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

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

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

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

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

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 בכל ערוצי ההתראות של האפליקציה, לא מוצגת סמנטיקה חזותית של תגים בסמל האפליקציה.
• יכולות לשנות את התגים של סמל האפליקציה לסכמת תגים קניינית משלהם, אם אפליקציות צד שלישי מציינות תמיכה בסכמת התגים הקניינית באמצעות שימוש ב-APIs קנייניים, אבל צריכות להשתמש במשאבים ובערכים שסופקו דרך ממשקי ה-API של תגי ההתראות שמתוארים בSDK, כמו ה-API של Notification.Builder.setNumber() ושל Notification.Builder.setBadgeIconType().

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

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

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

• [C-SR] מומלץ מאוד לקבץ ולהציג את ההתראות של conversation notifications לפני התראות שלא קשורות לשיחות, מלבד התראות על שירותים שפועלים בחזית והתראות importance:high.

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

• [C-SR] מומלץ מאוד להציג את השיחה הזו כבועה. הטמעת 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. חיפוש

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

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

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

• [C-1-1] חובה להטמיע את ממשקי ה-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 תומכת.

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

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

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

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

• [C-2-1] חובה להשתמש בצבע לבן בסמלי סטטוס המערכת (כמו עוצמת האות ורמת הסוללה) ובהתראות שהמערכת מנפיקה, אלא אם הסמל מציין סטטוס בעייתי או שאפליקציה מבקשת סרגל סטטוס בהיר באמצעות הדגל SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.
• [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'), אבל אפשר לעכב את ההצגה עד שהמשתמש יבצע פעולה במסכים.
• צריך להטמיע קיצור דרך כדי לעבור בקלות לפעילות הקודמת.
• אמורה להפעיל את פעולת המעבר המהיר בין שתי האפליקציות האחרונות שהיו בשימוש, כשמקישים פעמיים על מקש הפונקציה 'אפליקציות אחרונות'.
• לחיצה ארוכה על מקש הפונקציות של האפליקציות האחרונות אמורה להפעיל את מצב החלוקה למספר חלונות, אם הוא נתמך.
• יכול להיות שתמונות וסרטונים שקשורים לתמונות וסרטונים אחרונים יוצגו כקבוצה שזזה יחד.
• [SR] מומלץ מאוד להשתמש בממשק המשתמש של 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.
• צריכה לתמוך בגווני העור ובאמוג'י של משפחות מגוונות כפי שמפורט בדוח הטכני מס' 51 של Unicode.

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

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

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

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

* [C-2-1] MUST render text with Unicode compliant font as default;
  non-Unicode compliant font MUST NOT be set as default font unless the user
  chooses it in the language picker.
* [C-2-2] MUST support a Unicode font and a non-Unicode compliant font if a
  non-Unicode compliant font is supported on the device.  Non-Unicode
  compliant font MUST NOT remove or overwrite the Unicode font.
* [C-2-3] MUST render text with non-Unicode compliant font ONLY IF a
  language code with [script code Qaag](
  http://unicode.org/reports/tr35/#unicode_script_subtag_validity) is
  specified (e.g. my-Qaag). No other ISO language or region codes (whether
  assigned, unassigned, or reserved) can be used to refer to non-Unicode
  compliant font for Myanmar. App developers and web page authors can
  specify my-Qaag as the designated language code as they would for any
  other language.

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-1] חובה לטעון מראש מרכז אפליקציות שאפשר לשנות את הגודל שלו כברירת מחדל.
• [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.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-3] חובה לדווח על true עבור DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-4] חובה לרשום את אפליקציית ה-DPC כאפליקציית הבעלים של המכשיר בתגובה לפעולה של כוונת הפעולה android.app.action.PROVISION_MANAGED_DEVICE.
    • [C-1-5] חובה לרשום את אפליקציית ה-DPC כאפליקציית הבעלים של המכשיר אם המכשיר מצהיר על תמיכה בתקשורת מטווח קצר (NFC) באמצעות דגל התכונה android.hardware.nfc ומקבל הודעת NFC שמכילה רשומה עם סוג MIME‏ MIME_TYPE_PROVISIONING_NFC.
  • כשהטמעת המכשיר כוללת נתוני משתמשים, היא:
    • [C-1-6] חובה לדווח על false עבור DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-7] אסור יותר לרשום אפליקציית DPC כלשהי כאפליקציית הבעלים של המכשיר.
• [C-1-2] חובה לדרוש פעולה יזומה כלשהי לפני או במהלך תהליך ההקצאה כדי להביע הסכמה להגדרת האפליקציה כבעלים של המכשיר. ההסכמה יכולה להתקבל באמצעות פעולה של המשתמש או באמצעים פרוגרמטיים מסוימים, אבל חובה להציג הודעה מתאימה על חשיפת מידע (כפי שמפורט ב-AOSP) לפני שמתחילים את ההקצאה לבעלי המכשיר. בנוסף, מנגנון ההסכמה הפרוגרמטית של בעלי המכשיר שמשמש (ארגונים) להקצאה של בעלי המכשיר, אסור שיפריע לחוויית השימוש מחוץ לקופסה לשימוש שאינו עסקי.
• [C-1-3] אסור להטמיע את ההסכמה בקוד או למנוע את השימוש באפליקציות אחרות של בעלי המכשיר.

אם הטמעות במכשירים מכריזות על android.software.device_admin, אבל כוללות גם פתרון ניהול קנייני של בעלי המכשיר ומספקות מנגנון לקידום אפליקציה שמוגדרת בפתרון שלהן כ'בעלי מכשיר מקביל' ל'בעלי מכשיר' הרגיל, כפי שהוא מוכר בממשקי ה-API הרגילים של Android‏ DevicePolicyManager, הן:

• [C-2-1] חובה להגדיר תהליך לאימות שהאפליקציה הספציפית שמקדמים שייכת לפתרון לגיטימי לניהול מכשירים בארגון, ושהיא כבר מוגדרת בפתרון הקנייני כך שתהיה לה הרשאה שווה ערך ל'בעלי המכשיר'.
• [C-2-2] חובה להציג את אותו גילוי נאות לגבי הסכמה של הבעלים של המכשיר ב-AOSP, כמו בתהליך שהתחיל על ידי android.app.action.PROVISION_MANAGED_DEVICE לפני ההרשמה של אפליקציית ה-DPC כ'בעלים של המכשיר'.
• יכול להיות שיהיו נתוני משתמשים במכשיר לפני ההרשמה של אפליקציית ה-DPC בתור 'בעלי המכשיר'.

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

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

• [C-1-1] חובה להטמיע את ממשקי ה-API שמאפשרים לאפליקציית אמצעי בקרה למדיניות המכשיר (DPC) להיות הבעלים של פרופיל מנוהל חדש.

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

• [C-1-3] חובה לספק את האפשרויות הבאות למשתמש בהגדרות כדי לציין למשתמש מתי פונקציית מערכת מסוימת הושבתה על ידי ה-Device Policy Controller‏ (DPC):

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

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

3.10. נגישות

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

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

• [C-1-1] חובה לספק הטמעה של מסגרת הנגישות של Android כפי שמתואר במסמכי התיעוד של ממשקי ה-API לנגישות.
• [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 שמאפשרים לאפליקציות להשתמש בשירותי המרה של טקסט לדיבור (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] חובה להתייחס להקשה כפולה על KEYCODE_HEADSETHOOK או על KEYCODE_MEDIA_PLAY_PAUSE כאל KEYCODE_MEDIA_NEXT עבור MediaSession.Callback#onMediaButtonEvent.

3.15. אפליקציות ללא התקנה

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

• [C-0-1] חובה להעניק לאפליקציות ללא התקנה רק הרשאות שהערך של android:protectionLevel בהן מוגדר כ-"instant".
• [C-0-2] אסור לאפליקציות ללא התקנה לקיים אינטראקציה עם אפליקציות שמותקנות באמצעות כוונות משתמשים מרומזות, אלא אם מתקיים אחד מהתנאים הבאים:
  • מסנן דפוס ה-Intent של הרכיב חשוף ויש לו את הערך CATEGORY_BROWSABLE
  • הפעולה יכולה להיות אחת מהפעולות הבאות: ACTION_SEND, ‏ ACTION_SENDTO, ‏ ACTION_SEND_MULTIPLE
  • היעד נחשף באופן מפורש באמצעות android:visibleToInstantApps
• [C-0-3] אסור לאפליקציות מיידיות לקיים אינטראקציה מפורשת עם אפליקציות מותקנות, אלא אם הרכיב חשוף באמצעות android:visibleToInstantApps.
• [C-0-4] אסור לאפליקציות מותקנות לראות פרטים על אפליקציות ללא התקנה במכשיר, אלא אם אפליקציית האינסטנט מתחברת באופן מפורש לאפליקציה המותקנת.

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

• [C-1-1] חובה לספק למשתמשים את האפשרויות הבאות ליצירת אינטראקציה עם אפליקציות מיידיות. גרסת AOSP עומדת בדרישות עם ממשק המשתמש, ההגדרות והמרכז להפעלת אפליקציות שמוגדרים כברירת מחדל.
• [C-1-2] חובה לספק למשתמש אפשרות להציג ולמחוק אפליקציות מיידיות שנשמרו במטמון המקומי לכל חבילת אפליקציות בנפרד.
• [C-1-3] חובה לספק התראה קבועה למשתמשים שאפשר לכווץ בזמן שאפליקציה מיידית פועלת בחזית. ההתראה הזו למשתמשים חייבת לכלול את ההודעה שאפליקציות ללא התקנה לא דורשות התקנה, ולספק למשתמש אמצעי ניווט שמפנה אותו למסך פרטי האפליקציה בהגדרות. באפליקציות מיידיות שמופעלות באמצעות כוונות אינטרנט, כפי שמוגדרות באמצעות כוונה עם פעולה שמוגדרת כ-Intent.ACTION_VIEW ועם סכימה של 'http' או 'https', אמצעי עזר נוסף למשתמש אמור לאפשר למשתמש לא להפעיל את האפליקציה המיידית ולהפעיל את הקישור המשויך באמצעות דפדפן האינטרנט המוגדר, אם יש דפדפן זמין במכשיר.
• [C-1-4] חובה לאפשר גישה לאפליקציות מיידיות שפועלות דרך התכונה 'מהזמן האחרון', אם התכונה 'מהזמן האחרון' זמינה במכשיר.
• [C-1-5] חובה לטעון מראש אפליקציה אחת או יותר או רכיב שירות אחד או יותר עם בורר כוונות (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] מומלץ מאוד לא ליצור חשבונות מקומיים מותאמים אישית.

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

• [C-1-1] ContactsContract.RawContacts.getLocalAccountName חייב להחזיר את ACCOUNT_NAME של החשבון המקומי המותאם אישית
• [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 , ‏ 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] חובה שתהיה פעילות שמטפלת בכוונה 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.

• אם הטמעות של מכשירים כבר הושקו בגרסה קודמת של Android ולא ניתן לעמוד בדרישות [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 Project.

לתשומת ליבך: 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 כדי להגדיר את ההתנהגויות שקשורות לטווח הדינמי של מקודד האודיו. מפתחות ה-AAC DRC הוצגו ב-API 21, והם: KEY_AAC_DRC_ATTENUATION_FACTOR, ‏ KEY_AAC_DRC_BOOST_FACTOR, ‏ KEY_AAC_DRC_HEAVY_COMPRESSION, ‏ KEY_AAC_DRC_TARGET_REFERENCE_LEVEL ו-KEY_AAC_ENCODED_TARGET_LEVEL.
• [SR] מומלץ מאוד שכל מקודדי האודיו מסוג AAC יעמדו בדרישות C-2-1 ו-C-2-2 שלמעלה.

כשמפענחים אודיו מסוג USAC, MPEG-D‏ (ISO/IEC 23003-4):

• [C-3-1] חובה לפרש את המטא-נתונים של עוצמת הקול ושל בקרת הדינמיקה (DRC) ולהחיל אותם בהתאם לפרופיל בקרת הדינמיקה (DRC) ברמה 1 של MPEG-D.
• [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.

5.1.3. פרטי מקודדי האודיו

5.1.4. קידוד תמונות

פרטים נוספים זמינים בקטע 5.1.6. פרטי קודקים של תמונות.

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

• [C-0-1] JPEG
• [C-0-2] PNG
• [C-0-3] WebP

אם הטמעות במכשירים תומכות בקידוד HEIC דרך android.media.MediaCodec לסוג המדיה MIMETYPE_IMAGE_ANDROID_HEIC, הן:

• [C-1-1] חובה לספק קודק מקודד HEVC שמואץ בחומרה שתומך במצב בקרת קצב העברת הנתונים BITRATE_MODE_CQ, בפרופיל HEVCProfileMainStill ובגודל פריים של 512 x 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] גולמי

אם הטמעות במכשירים תומכות בפענוח וידאו HEVC, הן: * [C-1-1] חייבות לתמוך בפענוח תמונות HEIF‏ (HEIC).

מקודדי תמונות שתומכים בפורמט עם עומק סיביות גבוה (9 סיביות ומעלה לכל ערוץ):

• [C-2-1] חובה לתמוך בהפקת פלט בפורמט מקביל של 8 ביט אם הבקשה מגיעה מהאפליקציה, למשל דרך ההגדרה ARGB_8888 של android.graphics.Bitmap.

5.1.6. פרטי קודקים של תמונות

מקודדים ומפענחים של תמונות שחשופים דרך ממשק ה-API של MediaCodec

• [C-1-1] חובה לתמוך בפורמט צבע גמיש YUV420 8:8:8‏ (COLOR_FormatYUV420Flexible) דרך CodecCapabilities.

• [SR] מומלץ מאוד לתמוך בפורמט צבע 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). מומלץ מאוד לתמוך בשניהם.

• [SR] מומלץ מאוד שמקודדי וידאו ומפענחי וידאו יתמכו לפחות באחד מפורמטים צבעיים של 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. רשימת קודיקי וידאו

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] מומלץ מאוד לכלול תמיכה ב-Codec 2.0 API.

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

• [C-2-1] חובה לכלול את קודק התוכנה OMX התואם מפרויקט Android Open Source (אם הוא זמין) לכל פורמט מדיה וסוג (מקודד או מפענח) שנתמכים במכשיר.
• [C-2-2] קודיקים עם שמות שמתחילים ב-'OMX.google.‎' חייב להיות מבוסס על קוד המקור של פרויקט הקוד הפתוח של Android.
• [C-SR] מומלץ מאוד שהקודקים של תוכנת OMX יפעלו בתהליך של קודק שאין לו גישה למנהלי חומרה מלבד ממיפויי זיכרון.

אם הטמעות במכשירים תומכות ב-Codec 2.0 API, הן:

• [C-3-1] חובה לכלול את קודק התוכנה התואם של Codec 2.0 מפרויקט Android Open Source (אם הוא זמין) לכל סוג פורמט מדיה (מקודד או מפענח) שנתמך במכשיר.
• [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] כל רכיבי הקודק של הווידאו חייבים לפרסם נתונים של קצב פריימים שאפשר להשיג בגדלים הבאים, אם הקודק תומך בהם:

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

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

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

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

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

5.2.1. H.263

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

• [C-1-1] חובה לתמוך בפרופיל Baseline ברמה 45.
• צריכה להיות תמיכה בקצב נתונים שניתן להגדיר באופן דינמי בתוך המקודד הנתמך.

5.2.2. H.264

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

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

אם הטמעות במכשירים מדווחות על תמיכה בקידוד H.264 בסרטונים ברזולוציה של 720p או 1080p דרך ממשקי ה-API של המדיה, הן:

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

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

5.2.4. VP9

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

• [C-1-2] חובה לתמוך בפרופיל 0 ברמה 3.
• [C-1-1] חובה לתמוך בכתיבת קובצי Matroska WebM.
• [C-1-3] חובה ליצור נתונים מסוג CodecPrivate.
• צריך לתמוך בפרופילים של פענוח HD כפי שמצוין בטבלה הבאה.
• [SR] מומלץ מאוד לתמוך בפרופילים של פענוח HD כפי שמצוין בטבלה הבאה, אם יש מקודד חומרה.

אם הטמעות במכשירים טוענות שהן תומכות בפרופיל 2 או בפרופיל 3 דרך Media APIs:

• התמיכה בפורמט 12 ביט היא אופציונלית.

5.2.5. H.265

אם הטמעות המכשירים תומכות בקודק H.265, הן:

• [C-1-1] חובה לתמוך בפרופיל הראשי ברמה 3.
• צריך לתמוך בפרופילי הקידוד של HD כפי שמצוין בטבלה הבאה.
• [SR] מומלץ מאוד לתמוך בפרופילים של קידוד HD כפי שמצוין בטבלה הבאה, אם יש מקודד חומרה.

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] חובה לתמוך בפרופיל Baseline ברמה 30 וברמה 45.

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

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

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

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.

אם ההטמעות במכשירים טוענות שהן תומכות בפרופיל HDR דרך Media APIs:

• [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 שמפורטים בטבלה הבאה.

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.

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

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

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

5.4.1. הקלטת אודיו גולמי ומידע על המיקרופון

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

• [C-1-1] חייב לאפשר צילום של תוכן אודיו גולמי עם המאפיינים הבאים:

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

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

  • פורמט: 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(), ועל המיקרופונים הפעילים כרגע שזמינים לאפליקציות של הצד השלישי דרך ממשקי ה-API AudioRecord.getActiveMicrophones() ו-MediaRecorder.getActiveMicrophones(). אם הטמעות במכשירים מאפשרות תיעוד של תוכן אודיו גולמי באיכות רדיו 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.
• צריך להקליט את מקור האודיו של זיהוי הדיבור עם מאפייני תדרים ואמפליטודות יחסית שטוחים: באופן ספציפי, ±3 dB, מ-100Hz עד 4,000Hz.
• צריך להקליט את מקור האודיו של זיהוי הדיבור עם רגישות קלט מוגדרת כך שמקור של רמת הספק קול (SPL) של 90dB ב-1,000Hz יניב ערך RMS של 2,500 לדגימות של 16 ביט.
• צריך להקליט את מקור האודיו לזיהוי הקול כך שרמות המשרעת של 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] מומלץ מאוד להצהיר על כך באמצעות שיטת ה-API של AcousticEchoCanceler‏ AcousticEchoCanceler.isAvailable()
• [C-SR] מומלץ מאוד לאפשר שליטה באפקט האודיו הזה באמצעות ה-API של AcousticEchoCanceler.
• [C-SR] מומלץ מאוד לזהות באופן ייחודי כל הטמעה של טכנולוגיית 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.4.6. רמות הגברה של המיקרופון

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

• צריכות להיות מאפייני אמפליטודה לעומת תדר שטוחים בטווח התדרים הבינוני: באופן ספציפי, ±3dB מ-100Hz עד 4,000Hz לכל מיקרופון שמשמש להקלטת מקור האודיו לזיהוי הקול.
• צריך להגדיר את רגישות הקלט של האודיו כך שמקור קול סינוסואידלי של 1,000Hz שיופעל ברמת לחץ קול (SPL) של 90dB יניב תגובה עם RMS של 2,500 לדגימות של 16 ביט (או -22.35dB Full Scale לדגימות של נקודת צפה/דיוק כפול) לכל מיקרופון שמשמש להקלטה של מקור האודיו לזיהוי הקול.
• [C-SR] מומלץ מאוד להציג רמות אמפליטודה בטווח התדרים הנמוכים: באופן ספציפי, מ-±20dB מ-5Hz עד 100Hz בהשוואה לטווח התדרים הבינוני בכל מיקרופון שמשמש להקלטת מקור האודיו לזיהוי הקול.
• [C-SR] מומלץ מאוד להציג רמות אמפליטודה בטווח התדרים הגבוהים: באופן ספציפי, מ-±30dB מ-4,000Hz עד 22KHz בהשוואה לטווח התדרים הבינוני בכל מיקרופון שמשמש להקלטת מקור האודיו לזיהוי הקול.

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, ‏ 32000, ‏ 44100, ‏ 48000 בהגדרות הערוץ שמפורטות למעלה
    • 96,000 במונו ובסטריאו

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

  • תדירות דגימה: 24000, ‏ 48000

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.
• צריך לתמוך בהטמעות של EFFECT_TYPE_BASS_BOOST,‏ EFFECT_TYPE_ENV_REVERB,‏ EFFECT_TYPE_PRESET_REVERB ו-EFFECT_TYPE_VIRTUALIZER שניתן לשלוט בהן באמצעות תתי-הסוגים של AudioEffect: BassBoost,‏ EnvironmentalReverb,‏ PresetReverb ו-Virtualizer.
• [C-SR] מומלץ מאוד לתמוך באפקטים בספרות עשרוניות ובערוצים מרובים.

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

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

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

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] זמן אחזור של 500 אלפיות השנייה או פחות להפעלה ראשונית של פלט.

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

• [C-SR] זמן אחזור של 100 אלפיות השנייה או פחות בפלט קר. מומלץ מאוד למכשירים קיימים וחדשים עם גרסת Android הזו לעמוד בדרישות האלה כבר עכשיו. במהדורה עתידית של הפלטפורמה בשנת 2021, נדרוש זמן אחזור של 200 אלפיות השנייה או פחות כחובה.
• [C-SR] זמן אחזור רציף של פלט של 45 אלפיות השנייה או פחות.
• [C-SR] צמצום התנודות בזמן היציאה במצב התחלה קר (cold start).
• [C-SR] חותמת הזמן של הפלט שמוחזרת על ידי AudioTrack.getTimestamp ו-AAudioStream_getTimestamp מדויקת ברמת 1 אלפיית השנייה +/-.

אם הטמעות המכשיר עומדות בדרישות שלמעלה, אחרי כיול ראשוני, כשמשתמשים גם בתור המאגר של OpenSL ES PCM וגם ב-AAudio native audio APIs, זמן האחזור של הפלט הרציף וזמן האחזור של הפלט לאחר הפעלה מחדש במכשיר אחד לפחות שתומך בפלט אודיו, הם:

• [C-SR] STRONGLY RECOMMENDED to report low-latency audio by declaring android.hardware.audio.low_latency feature flag.
• [C-SR] מומלץ מאוד לעמוד בדרישות לשימוש באודיו עם זמן אחזור נמוך באמצעות AAudio API.
• [C-SR] מומלץ מאוד לוודא שבזרמים שמחזירים את הערך AAUDIO_PERFORMANCE_MODE_LOW_LATENCY מ-AAudioStream_getPerformanceMode(), הערך שמוחזר על ידי AAudioStream_getFramesPerBurst() קטן מהערך שמוחזר על ידי android.media.AudioManager.getProperty(String) למפתח המאפיין AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER או שווה לו.

אם הטמעות במכשירים לא עומדות בדרישות לאודיו עם זמן אחזור קצר באמצעות תור המאגר של OpenSL ES PCM וממשקי ה-API של אודיו מקומי של AAudio, הן:

• [C-2-1] אסור לדווח על תמיכה באודיו עם זמן אחזור קצר.

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

• [C-3-1] מגבילים את השגיאה בחותמות הזמן של הקלט, כפי שהן מוחזרות על ידי AudioRecord.getTimestamp או AAudioStream_getTimestamp, ל-±2 אלפיות השנייה. 'שגיאה' כאן פירושה סטייה מהערך הנכון.
• [C-3-2] זמן אחזור של קלט קר של 500 אלפיות השנייה או פחות.

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

• [C-SR] זמן אחזור של קלט קר של 100 אלפיות השנייה או פחות. מומלץ מאוד למכשירים קיימים וחדשים עם גרסת Android הזו לעמוד בדרישות האלה כבר עכשיו. במהדורה עתידית של הפלטפורמה ב-2021, נדרוש זמן אחזור קלט קר (Cold) של 200 אלפיות השנייה או פחות.
• [C-SR] זמן אחזור קלט רציף של 30 אלפיות השנייה או פחות.
• [C-SR] זמן אחזור הלוך ושוב רציף של 50 אלפיות השנייה או פחות.
• [C-SR] צמצום התנודות (jitter) של הקלט הקר.
• [C-SR] הגבלת השגיאה בחותמות הזמן של הקלט, כפי שהן מוחזרות על ידי AudioRecord.getTimestamp או AAudioStream_getTimestamp, ל-±1ms.

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

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

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

• [C-1-1] חובה לתמוך בכל הקודקים ובכל הפורמטים הנדרשים של קונטיינרים שמפורטים בקטע 5.1 באמצעות HTTP(S).

• [C-1-2] חובה לתמוך בפורמטים של קטעי המדיה שמפורטים בטבלה 'פורמטים של קטעי מדיה' בהמשך, באמצעות טיוטת פרוטוקול HTTP Live Streaming, גרסה 7.

• [C-1-3] חובה לתמוך בפרופיל הווידאו והאודיו הבא של RTP ובקודקים הקשורים בטבלת ה-RTSP שבהמשך. החרגות מפורטות בהערות השוליים בטבלה שמפורטת בקטע 5.1.

פורמטים של קטעי מדיה

RTSP‏ (RTP, ‏ SDP)

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 זמן אחזור של אודיו, חייב להיות 20 אלפיות השנייה או פחות, ומומלץ שיהיה 10 אלפיות השנייה או פחות במסלול נתמך אחד לפחות.
• [C-1-3] חייב לכלול יציאות USB שתומכות במצב מארח USB ובמצב ציוד היקפי USB.
• [C-1-4] חובה לדווח על תמיכה בתכונה android.software.midi.
• [C-1-5] חובה לעמוד בדרישות העיכובים ובדרישות האודיו של USB באמצעות ממשק ה-API של תור מאגר ה-PCM ב-OpenSL ES ודרך אחת לפחות של ממשק ה-API של אודיו מקורי של AAudio.
• [SR] מומלץ מאוד לעמוד בדרישות לגבי זמני אחזור ודרישות האודיו ב-USB באמצעות ה-API של אודיו מקורי של AAudio דרך נתיב MMAP.
• [C-1-6] זמן האחזור של הפלט בסטטוס 'לא בשימוש' חייב להיות 200 אלפיות שנייה או פחות.
• [C-1-7] זמן האחזור של קלט קר חייב להיות 200 אלפיות השנייה או פחות.
• [SR] מומלץ מאוד לספק רמה עקבית של ביצועי מעבד בזמן שהאודיו פעיל ועומס המעבד משתנה. צריך לבדוק את זה באמצעות גרסת האפליקציה ל-Android של מזהה השמירה SynthMark 09b13c6f49ea089f8c31e5d035f912cc405b7ab8. ב-SynthMark נעשה שימוש בסינתיסייזר תוכנה שפועל על מסגרת אודיו מדומה למדידת ביצועי המערכת. צריך להפעיל את אפליקציית SynthMark באמצעות האפשרות 'בדיקה אוטומטית' ולקבל את התוצאות הבאות:
  • voicemark.90 >= 32 voices
  • latencymark.fixed.little <= 15 msec
  • latencymark.dynamic.little <= 50 msec

הסבר על מדדי ההשוואה זמין במסמכי העזרה של SynthMark.

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

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

• [SR] מומלץ מאוד לדווח על תמיכה בתכונה android.hardware.audio.pro באמצעות הכיתה android.content.pm.PackageManager.

אם הטמעות המכשירים כוללות שקע אודיו 3.5 מ"מ עם 4 מוליכים, הן:

• [C-2-1] זמן האחזור של האודיו במסלול הלוך ושוב חייב להיות 20 אלפיות השנייה או פחות דרך שקע האודיו.
• [SR] מומלץ מאוד לציית לקטע מפרטים של מכשיר נייד (שקע) במפרט של אוזניות אודיו חוטיות (גרסה 1.1).
• זמן האחזור הרציף של הלוך ושוב של האודיו צריך להיות 10 אלפיות השנייה או פחות לאורך נתיב שקע האודיו.

אם הטמעות של מכשירים משמיטים שקע אודיו בגודל 3.5 מ"מ עם 4 מוליכים וכוללות יציאות USB שתומכות במצב מארח USB, הן:

• [C-3-1] חובה להטמיע את מחלקת האודיו של USB.
• [C-3-2] זמן האחזור של האודיו במסלול הלוך ושוב חייב להיות 20 אלפיות השנייה או פחות דרך יציאת מצב המארח של ה-USB באמצעות סיווג אודיו USB.
• זמן האחזור של אודיו הלוך ושוב ברציפות צריך להיות 10 אלפיות השנייה או פחות ביציאה במצב מארח USB באמצעות סיווג אודיו USB.
• [C-SR] מומלץ מאוד לתמוך ב-I/O בו-זמני של עד 8 ערוצים בכל כיוון, בקצב דגימה של 96kHz ובעומק של 24 או 32 ביט, כשמשתמשים בציוד היקפי של אודיו USB שתומך גם בדרישות האלה.

אם הטמעות המכשירים כוללות יציאת 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] חייב להיות בעל מאפייני אמפליטודה לעומת תדר שטוחים בטווח התדרים הבינוני: באופן ספציפי, ±10dB מ-100Hz עד 7,000Hz לכל מיקרופון שמשמש להקלטה של מקור האודיו הלא מעובד.

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

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

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

• [C-1-6] חובה שיחס האות לרעש (SNR) יהיה 60dB או יותר בכל מיקרופון שמשמש להקלטה של מקור האודיו הלא מעובד. (לעומת זאת, SNR נמדד כהפרש בין 94dB SPL לבין SPL שווה ערך של רעש עצמי, משוקלל לפי A).

• [C-1-7] עיוות הרמוני כולל (THD) חייב להיות קטן מ-1% עבור 1kHz ברמת קלט של 90dB SPL בכל מיקרופון שמשמש להקלטה של מקור האודיו הלא מעובד.

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

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

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

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

• [C-2-1] חובה להחזיר את הערך null לשיטת ה-API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), כדי לציין בצורה נכונה את חוסר התמיכה.
• [SR] עדיין מומלץ מאוד לעמוד בכמה שיותר מהדרישות של נתיב האות של מקור ההקלטה הלא מעובד.

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 דרך רשת מקומית (כמו אתרנט או 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, כפי שמתואר למעלה.
• Monkey
  • [C-0-8] חובה לכלול את מסגרת Monkey ולהפוך אותה לזמינה לשימוש באפליקציות.
• SysTrace
  • [C-0-9] חובה לתמוך בכלי systrace כפי שמתואר ב-Android SDK. Systrace חייב להיות לא פעיל כברירת מחדל, וחייבת להיות מנגנון שזמין למשתמשים כדי להפעיל את Systrace.
• Perfetto
  • [C-SR] מומלץ מאוד לחשוף למשתמש המעטפת קובץ בינארי של /system/bin/perfetto, ש-cmdline שלו עומד בדרישות של מסמכי התיעוד של perfetto.
  • [C-SR] מומלץ מאוד שהקובץ הבינארי של perfetto יקבל כקלט קובץ תצורה של protobuf שתואם להסכימה שמוגדרת במסמכי התיעוד של perfetto.
  • [C-SR] מומלץ מאוד לכתוב את הקובץ הבינארי של perfetto כפלט של פרוטוקול protobuf שתואם לסכימה שמוגדרת במסמכי התיעוד של perfetto.
  • [C-SR] מומלץ מאוד לספק, באמצעות הקובץ הבינארי של perfetto, לפחות את מקורות הנתונים שמתוארים במסמכי התיעוד של perfetto.
• Low Memory Killer
  • [C-0-10] חובה לכתוב LMK_KILL_OCCURRED_FIELD_NUMBER Atom ביומן statsd כשאפליקציה מסתיימת על ידי Low Memory Killer.
• מצב מסגרת בדיקה אם הטמעות המכשיר תומכות בפקודת המעטפת cmd testharness ומריצות את cmd testharness enable, הן:
  • [C-2-1] חובה להחזיר את הערך true עבור ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] חובה להטמיע את מצב 'מסגרת בדיקה' כפי שמתואר במסמכי התיעוד של מצב 'מסגרת בדיקה'.

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

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

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

7.1.1. הגדרת מסך

7.1.1.1. גודל המסך וצורת המסך

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

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

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

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

• [C-2-1] חובה להטמיע את הגרסה היציבה האחרונה שזמינה של extensions API או את הגרסה היציבה של sidecar API לשימוש בספרייה Window Manager Jetpack.

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

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

פרטים על הטמעה נכונה של ממשקי ה-API של התוסף או הצדדים הנלווים מופיעים במסמכי העזרה הציבוריים של Window Manager Jetpack.

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

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

• [C-0-1] בהטמעות במכשירים שבהן הערך של Configuration.uiMode מוגדר כ-UI_MODE_TYPE_NORMAL, ערך יחס הגובה-רוחב חייב להיות קטן מ-1.86 או שווה לו (כ-16:9), אלא אם האפליקציה עומדת באחד מהתנאים הבאים:

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

• [C-0-2] בהטמעות במכשירים שבהן הערך של Configuration.uiMode מוגדר כ-UI_MODE_TYPE_NORMAL, ערך יחס הגובה-רוחב חייב להיות שווה ל-1.3333 (4:3) או גדול ממנו, אלא אם ניתן למתוח את האפליקציה לרוחב על ידי עמידה באחד מהתנאים הבאים:

  • האפליקציה מצהירה שהיא ניתנת לשינוי גודל באמצעות המאפיין android:resizeableActivity.
  • האפליקציה מצהירה על android:minAspectRatio שיגביל את יחס הגובה-רוחב המותר.

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

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

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

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

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] מומלץ מאוד לתמוך ב-OpenGL ES 3.1.
• צריך לתמוך ב-OpenGL ES 3.2.

אם הטמעות במכשירים תומכות באחת מגרסאות 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-SR] מומלץ מאוד לתמוך בתוספים EGL_KHR_partial_update ו-OES_EGL_image_external.
• צריך לדווח בצורה מדויקת באמצעות השיטה getString() על כל פורמט דחיסת טקסטורה שבו יש תמיכה, בדרך כלל ספציפי לספק.

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

• [C-3-1] חובה לייצא את סמלי הפונקציות התואמים לגרסאות האלה, בנוסף לסמלי הפונקציות של OpenGL ES 2.0 בספרייה libGLESv2.so.
• [SR] מומלץ מאוד לתמוך בתוסף 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, הן:

• [SR] מומלץ מאוד לכלול תמיכה ב-Vulkan 1.1.

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

• צריכה לכלול תמיכה ב-Vulkan 1.1.

בדיקות Vulkan dEQP מחולקות למספר רשימות בדיקות, לכל אחת מהן תאריך או גרסה משויכים. הם נמצאים בעץ המקור של Android בכתובת external/deqp/android/cts/main/vk-master-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 לכל VkPhysicalDevice שמפורטים.
• [C-1-4] חובה למנות שכבות שמכילות ספריות מקוריות בשם libVkLayer*.so בספריית הספריות המקוריות של חבילת האפליקציה, באמצעות ממשקי ה-API המקומיים של Vulkan‏ vkEnumerateInstanceLayerProperties() ו-vkEnumerateDeviceLayerProperties() .
• [C-1-5] אסור למנות שכבות שסופקו על ידי ספריות מחוץ לחבילת האפליקציה, או לספק דרכים אחרות למעקב אחרי Vulkan API או ליירט אותו, אלא אם מאפיין android:debuggable מוגדר באפליקציה כ-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-SR] מומלץ מאוד לתמוך בתוספים VK_KHR_driver_properties ו-VK_GOOGLE_display_timing.

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

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

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

• [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] מומלץ מאוד לתמוך ב-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] חובה להצהיר על דגל התכונה 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 בקוד פתוח ב-upstream כוללת מנגנון בחירה שמתאים לשימוש במכשירים שאין בהם מקורות קלט לניווט ללא מגע.

7.2.3. מקשי ניווט

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

• [C-0-1] חובה לספק למשתמש אפשרות להפעיל אפליקציות מותקנות שיש להן פעילות עם <intent-filter> שמוגדר עם ACTION=MAIN ו-CATEGORY=LAUNCHER או CATEGORY=LEANBACK_LAUNCHER להטמעות במכשירי טלוויזיה. הפונקציה 'דף הבית' אמורה להיות המנגנון של האפשרות הזו למשתמש.
• צריך לספק לחצנים לפונקציות 'פריטים אחרונים' ו'חזרה'.

אם הפונקציות 'דף הבית', 'פריטים אחרונים' או 'חזרה' זמינות, הן:

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

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

• [SR] מומלץ מאוד לא לספק את מנגנון הקלט של פונקציית התפריט, כי הוא הוצא משימוש לטובת שורת הפעולות מאז Android 4.0.

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

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

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

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

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

• [C-4-1] חובה להפוך את פונקציית Assist לנגישה באמצעות פעולה אחת (למשל הקשה, לחיצה כפולה או תנועה) כשמפתחות ניווט אחרים נגישים.
• [SR] STRONGLY RECOMMENDED to use long press on HOME function as this designated interaction.

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

• [C-5-1] לחצני הניווט חייבים להשתמש בחלק נפרד מהמסך, שלא זמין לאפליקציות, ואסור שהם יטשטשו או יפריעו בדרך אחרת לחלק מהמסך שזמין לאפליקציות.
• [C-5-2] חובה להקצות חלק מהמסך לאפליקציות שעומדות בדרישות המפורטות בסעיף 7.1.1.
• [C-5-3] חובה לכבד את הדגלים שהוגדרו על ידי האפליקציה באמצעות שיטת ה-API View.setSystemUiVisibility(), כדי שהחלק הייחודי הזה במסך (שנקרא גם סרגל הניווט) יהיה מוסתר כראוי, כפי שמתואר ב-SDK.

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

• [C-6-1] אסור להשתמש ב-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() לא אמורות להיות מושפעות מקטעי ה-rect להחרגה שסופקו על ידי האפליקציה שבחזית דרך View#setSystemGestureExclusionRects().

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

• [C-7-1] פונקציית הניווט חייבת להיות 'חזרה', והיא צריכה להתבצע באמצעות החלקה מהקצה השמאלי ומהקצה הימני של המסך בכיוון הנוכחי שלו.
• [C-7-2] אם יש חלוניות מערכת בהתאמה אישית שאפשר להחליק עליהן בקצוות השמאלי או הימני, הן חייבות להיות ממוקמות בשליש העליון של המסך, עם אינדיקציה חזותית ברורה ועקבית לכך שגרירה פנימה תפעיל את החלוניות שצוינו למעלה, ולא את 'הקודם'. משתמש יכול להגדיר חלונית מערכת כך שתופיע מתחת לשליש העליון של שולי המסך, אבל אסור שחלונית המערכת תשתמש ביותר מ-1/3 מהשוליים.
• [C-7-3] כשהאפליקציה שבחזית מוגדרים לה הדגלים View.SYSTEM_UI_FLAG_IMMERSIVE או View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, מחיקה מהקצוות חייבת להתנהג כפי שהיא מוטמעת ב-AOSP, כפי שמתואר בSDK.
• [C-7-4] כשהאפליקציה שבחזית מוגדרים לה הדגלים View.SYSTEM_UI_FLAG_IMMERSIVE או View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, לוחות מערכת מותאמים אישית שניתן להחליק אותם חייבים להיות מוסתרים עד שהמשתמש מציג את סרחי המערכת (המכונים גם סרגל הניווט וסרגל הסטטוס) כפי שהם מוטמעים ב-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

1 KeyEvent

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

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

4 MotionEvent

אירוע MotionEvent אחד

7.2.7. שלט רחוק

הדרישות הספציפיות למכשיר מפורטות בקטע 2.3.1.

7.3. חיישנים

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

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

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

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

7.3.1. מד תאוצה

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

• [C-SR] מומלץ מאוד לכלול מד תאוצה ב-3 צירים.

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

• [C-1-1] חייב להיות מסוגל לדווח על אירועים בתדירות של לפחות 50Hz.
• [C-1-2] חובה להטמיע את החיישן TYPE_ACCELEROMETER ולדווח עליו.
• [C-1-3] חייב להיות תואם למערכת הקואורדינטות של חיישן Android כפי שמפורט בממשקי ה-API של Android.
• [C-1-4] חייב להיות מסוגל למדוד מירידה חופשית עד פי ארבעה מכוח הכבידה(4g) או יותר בכל ציר.
• [C-1-5] חייבת להיות רזולוציה של לפחות 12 ביט.
• [C-1-6] חייבת להיות סטיית תקן של 0.05 m/s^‏‎ לכל היותר, כאשר סטיית התקן צריכה להיות מחושבת על בסיס ציר על דגימות שנאספו במשך תקופה של לפחות 3 שניות בקצב הדגימה המהיר ביותר.
• [SR] מומלץ מאוד להטמיע את החיישן המשולב TYPE_SIGNIFICANT_MOTION.
• [SR] מומלץ מאוד להטמיע את החיישן TYPE_ACCELEROMETER_UNCALIBRATED ולדווח עליו. מומלץ מאוד שמכשירי Android יעמדו בדרישות האלה כדי שיוכלו לשדרג לגרסה העתידית של הפלטפורמה, שבה יכול להיות שהדרישה הזו תהיה חובה.
• צריך להטמיע את החיישנים המשולבים TYPE_SIGNIFICANT_MOTION, ‏ TYPE_TILT_DETECTOR, ‏ TYPE_STEP_DETECTOR, ‏ TYPE_STEP_COUNTER כפי שמתואר במסמך Android SDK.
• צריך לדווח על אירועים עד 200Hz לפחות.
• צריכה להיות להם רזולוציה של 16 ביט לפחות.
• צריך לבצע כיול במהלך השימוש אם המאפיינים משתנים במהלך מחזור החיים של המכשיר ומבוצעת תיקון, ולשמור את פרמטרים התיקון בין הפעלות מחדש של המכשיר.
• צריך לבצע פיצוי טמפרטורה.

אם הטמעות במכשיר כוללות תאוצה תלת-ציונית, וגם חיישנים מורכבים מסוג TYPE_SIGNIFICANT_MOTION, ‏ TYPE_TILT_DETECTOR, ‏ TYPE_STEP_DETECTOR ו-TYPE_STEP_COUNTER:

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

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

• [C-3-1] חובה להטמיע את החיישנים המשולבים TYPE_GRAVITY ו-TYPE_LINEAR_ACCELERATION.
• [C-SR] מומלץ מאוד להטמיע את החיישן המשולב TYPE_GAME_ROTATION_VECTOR.

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

• [C-4-1] חובה להטמיע חיישן משולב מסוג TYPE_ROTATION_VECTOR.

7.3.2. מגנטומטר

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

• [C-SR] מומלץ מאוד לכלול מגנטומטר (מצפן) ב-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 מיקרו-טסלה. מומלץ שסטיית התקן תהיה לא יותר מ-0.5 מיקרו-טסלה.
• [C-SR] מומלץ מאוד להטמיע את החיישן 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] מומלץ מאוד לכלול מקלט 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] מומלץ מאוד להמשיך לספק פלט נתוני מיקום רגילים של GPS/GNSS דרך ממשקי ה-API של ספקי מיקום GNSS במהלך שיחת טלפון למקרה חירום.
  • [C-SR] מומלץ מאוד לדווח על מדידות GNSS מכל המערכות שבמעקב (כפי שמדווח בהודעות GnssStatus), מלבד SBAS.
  • [C-SR] מומלץ מאוד לדווח על AGC ועל תדירות המדידה של GNSS.
  • [C-SR] מומלץ מאוד לדווח על כל אומדני הדיוק (כולל כיוון, מהירות ונתונים אנכיים) כחלק מכל מיקום GPS/GNSS.
  • [C-SR] מומלץ מאוד לדווח על מדידות GNSS ברגע שהן מתגלות, גם אם מיקום שמחושב מ-GPS/GNSS עדיין לא דווח.
  • [C-SR] מומלץ מאוד לדווח על טווחי פסאודו וקצבי פסאודו של GNSS, שבתנאי שדה פתוח אחרי שנקבע המיקום, בזמן שהמכשיר נייח או נע במהירות של פחות מ-0.2 מטר לשנייה בריבוע, מספיקים כדי לחשב מיקום בטווח של 20 מטרים ומהירות בטווח של 0.2 מטר לשנייה, לפחות ב-95% מהמקרים.

7.3.4. ג'ירוסקופ

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

• [C-SR] מומלץ מאוד לכלול חיישן ג'ירוסקופ.

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

• [C-1-1] חייב להיות מסוגל לדווח על אירועים בתדירות של לפחות 50Hz.
• [C-1-2] חובה להטמיע את החיישן TYPE_GYROSCOPE, ומומלץ מאוד להטמיע גם את החיישן TYPE_GYROSCOPE_UNCALIBRATED.
• [C-1-4] חייבת להיות רזולוציה של 12 ביט או יותר, ומומלצת רזולוציה של 16 ביט או יותר.
• [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.
• [SR] מומלץ מאוד שהשגיאה בכיול תהיה פחות מ-0.01 rad/s כשהמכשיר נייח בטמפרטורת החדר.
• צריך לדווח על אירועים עד 200Hz לפחות.

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

• [C-2-1] חובה להטמיע חיישן TYPE_ROTATION_VECTOR מורכב.

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

• [C-3-1] חובה להטמיע את החיישנים המשולבים TYPE_GRAVITY ו-TYPE_LINEAR_ACCELERATION.
• [C-SR] מומלץ מאוד להטמיע את החיישן המשולב TYPE_GAME_ROTATION_VECTOR.

7.3.5. ברומטר

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

• [C-SR] מומלץ מאוד לכלול ברומטר (חיישן לחץ אוויר סביבתי).

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

• [C-1-1] חובה להטמיע את החיישן TYPE_PRESSURE ולדווח עליו.
• [C-1-2] חובה שאפשר יהיה לשלוח אירועים בתדר של 5Hz או יותר.
• [C-1-3] חייב להיות פיצוי טמפרטורה.
• [SR] מומלץ מאוד לדווח על מדידות לחץ בטווח 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 לחיישן הטמפרטורה.

7.3.7. פוטומטר

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

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

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

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

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

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

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

• [C-1-1] חובה לזהות את היכולת באמצעות דגל התכונה android.hardware.sensor.hifi_sensors.

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

• [C-2-1] חייב להיות חיישן TYPE_ACCELEROMETER ש:

  • חייב להיות טווח מדידה של לפחות -8g עד +8g, ומומלץ מאוד שטווח המדידה יהיה לפחות -16g עד +16g.
  • חייבת להיות רזולוציית מדידה של לפחות 2048 LSB/g.
  • תדר המדידה המינימלי חייב להיות 12.5Hz או פחות.
  • חובה שתהיה תדירות מדידה מקסימלית של 400Hz ומעלה. מומלץ שתהיה תמיכה ב-SensorDirectChannel‏ RATE_VERY_FAST.
  • רעש המדידה חייב להיות לא יותר מ-400 μg/√Hz.
  • חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון זמני של לפחות 3,000 אירועי חיישן.
  • צריכת החשמל של האצווה חייבת להיות לא יותר מ-3mW.
  • [C-SR] מומלץ מאוד שרוחב הפס למדידת 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 dps.
  • חייבת להיות רזולוציית מדידה של לפחות 16 LSB/dps.
  • תדר המדידה המינימלי חייב להיות 12.5Hz או פחות.
  • חובה שתהיה תדירות מדידה מקסימלית של 400Hz ומעלה. מומלץ שתהיה תמיכה ב-SensorDirectChannel‏ RATE_VERY_FAST.
  • רעש המדידה חייב להיות לא יותר מ-0.014°/s/√Hz.
  • [C-SR] מומלץ מאוד שרוחב הפס למדידת 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, ובנוסף:

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

• [C-2-7] חייב להיות חיישן TYPE_PRESSURE ש:

  • טווח המדידה חייב להיות לפחות בין 300 ל-1,100 hPa.
  • חייבת להיות רזולוציית מדידה של לפחות 80 LSB/hPa.
  • תדר המדידה המינימלי חייב להיות 1Hz או פחות.
  • תדירות המדידה המקסימלית חייבת להיות 10 הרץ ומעלה.
  • רעש המדידה חייב להיות לא יותר מ-2 Pa/√Hz.
  • חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון זמני של לפחות 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 ש:
  • חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון זמני של לפחות 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, אבל אם הוא קיים, חייבת להיות לו קיבולת מינימלית של מאגר נתונים זמני של 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] מומלץ מאוד להגדיר אפשרות שמאפשרת למשתמשים לשנות את ההעדפות של האפליקציה, ותמיד לדרוש שלב אישור.
• [C-SR] מומלץ מאוד לאבטח את פעולת האישור כך שלא ניתן יהיה לזייף אותה כתוצאה מפריצה למערכת ההפעלה או לליבה. לדוגמה, המשמעות היא שפעולת האישור שמבוססת על לחצן פיזי מנותבת דרך פין קלט/פלט (GPIO) למטרות כלליות (I/O) של רכיב מאובטח (SE) שלא ניתן להפעיל באמצעים אחרים מלבד לחיצה על לחצן פיזי.
• [C-5-2] חובה להטמיע בנוסף תהליך אימות משתמע (ללא שלב אישור) שתואם ל-setConfirmationRequired(boolean), שאפשר להגדיר באפליקציות כדי להשתמש בו בתהליכי כניסה.

אם יש במכשירים כמה חיישנים ביומטריים, הם:

• [C-SR] מומלץ מאוד לדרוש אישור של רק מאפיין ביומטרי אחד לכל אימות (למשל, אם חיישני טביעות האצבע והפנים זמינים במכשיר, צריך לשלוח את האירוע 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-3] חובה להגביל את קצב הניסיונות למשך 30 שניות לפחות אחרי 5 ניסיונות כושלים לאימות ביומטרי – כאשר ניסיון כושל הוא ניסיון באיכות צילום מספקת (BIOMETRIC_ACQUIRED_GOOD) שלא תואם למאפיין ביומטרי רשום.
• [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 שעות או פחות במכשירים חדשים שהושקעו עם Android מגרסה 10, ופעם ב-72 שעות או פחות במכשירים שעברו שדרוג מגרסה קודמת של Android.

• [C-1-8] חובה לאתגר את המשתמש לאימות ראשי מומלץ (למשל: מספר PIN, דפוס, סיסמה) אחרי אחת מהפעולות הבאות:

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

  ניתן לפטור מ-C-1-8 שדרוג של מכשירים מגרסה קודמת של Android. * [C-SR] מומלץ מאוד להשתמש בלוגיקה במסגרת שסופקה על ידי Android Open Source Project כדי לאכוף את האילוצים שצוינו ב-[C-1-7] וב-[C-1-8] במכשירים חדשים. * [C-SR] מומלץ מאוד שהשיעור של דחיית בקשות לא חוקיות יהיה פחות מ-10%, כפי שנמדד במכשיר. * [C-SR] מומלץ מאוד שהזמן להצגת תוצאה יהיה פחות משנייה, נמדד מרגע זיהוי המאפיין הביומטרי ועד לביטול הנעילה של המסך, לכל מאפיין ביומטרי רשום.

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

• [C-2-1] חובה לעמוד בכל הדרישות של סיווג 1 שמפורטות למעלה.
• [C-2-2] חובה ששיעור הקבלה של זיופים ותרמיות יהיה לא יותר מ-20%, כפי שנמדד לפי פרוטוקולי הבדיקה של Android Biometrics.
• [C-2-3] חובה לבצע את ההתאמה הביומטרית בסביבת מחשוב מבודדת מחוץ למרחב המשתמש או הליבה של Android, כמו סביבת מחשוב אמינה (TEE), או בשבב עם ערוץ מאובטח לסביבת המחשוב המבודדת.
• [C-2-4] חובה להצפין את כל הנתונים המזהים ולבצע להם אימות קריפטוגרפית, כך שלא ניתן יהיה לקבל אותם, לקרוא או לשנות אותם מחוץ לסביבת הביצוע המבודדת או בצ'יפ עם ערוץ מאובטח לסביבת הביצוע המבודדת, כפי שמתואר בהנחיות להטמעה באתר של Android Open Source Project.
• [C-2-5] לנתונים ביומטריים שמבוססים על מצלמה, בזמן שמתבצע אימות או הרשמה מבוססי ביומטריה:
  • חובה להפעיל את המצלמה במצב שמונע קריאה או שינוי של מסגרות המצלמה מחוץ לסביבת הביצוע המבודדת, או שבה יש צ'יפ עם ערוץ מאובטח לסביבת הביצוע המבודדת.
  • בפתרונות RGB עם מצלמה אחת, ניתן לקרוא את הפריימים של המצלמה מחוץ לסביבת הביצועים המבודדת כדי לתמוך בפעולות כמו תצוגה מקדימה לצורך הרשמה, אבל עדיין אסור לשנות אותם.
• [C-2-6] אסור לאפשר לאפליקציות של צד שלישי להבדיל בין הרשמות ביומטריות ספציפיות.
• [C-2-7] אסור לאפשר גישה ללא הצפנה לנתונים ביומטריים מזהים או לנתונים שמקורם בהם (כמו הטמעות) למעבד האפליקציות מחוץ להקשר של TEE.

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

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

• [C-SR] מומלץ מאוד לכלול זיהוי חיים בכל השיטות הביומטריות וזיהוי תשומת לב לזיהוי ביומטרי של פנים.

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

• [C-3-1] חייב לעמוד בכל הדרישות של סיווג 2 שלמעלה, מלבד [C-1-7] ו-[C-1-8]. שדרוג מכשירים מגרסה קודמת של Android לא פטור מ-C-2-7.
• [C-3-2] חובה להטמיע מאגר מפתחות שמגובים בחומרה.
• [C-3-3] שיעור האישור של התחזות וזיופים חייב להיות לא יותר מ-7%, כפי שנמדד לפי פרוטוקולי הבדיקה של Android Biometrics.
• [C-3-4] חובה לאתגר את המשתמש לאימות ראשי מומלץ (למשל, קוד אימות, קו ביטול נעילה, סיסמה) פעם ב-72 שעות או פחות.

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

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

• יכול להיות שתהיה תמיכה בחיישן תנוחה עם 6 דרגות חופש.

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

• [C-1-1] חובה להטמיע את החיישן TYPE_POSE_6DOF ולדווח עליו.
• [C-1-2] חייב להיות מדויק יותר מאשר וקטור הסיבוב בלבד.

7.3.13. חיישן זווית ציר

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

• [C-1-1] חובה להטמיע את TYPE_HINGLE_ANGLE ולדווח עליו.
• [C-1-2] חייב לתמוך לפחות בשתי קריאות בין 0 ל-360 מעלות (כולל, כלומר כולל 0 ו-360 מעלות).
• [C-1-3] חייב להחזיר חיישן התעוררות עבור getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

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

7.4.1. טלפוניה

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

• אפשר להשתמש ב-Android במכשירים שלא כוללים חומרה של טלפוניה. כלומר, Android תואם למכשירים שאינם טלפונים.

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

• [C-1-1] חובה להצהיר על ה-feature flag android.hardware.telephony ועל דגלים נוספים של תכונות משנה בהתאם לטכנולוגיה.
• [C-1-2] חובה להטמיע תמיכה מלאה ב-API של הטכנולוגיה הזו.

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

• [C-2-1] חובה להטמיע את ממשקי ה-API המלאים כ-no-ops.

אם הטמעות במכשירים תומכות ב-eUICC או ב-eSIM/SIM מוטמע, וכוללות מנגנון קנייני שמאפשר למפתחים של צד שלישי להשתמש בפונקציות של eSIM, הן:

• [C-3-1] חובה לספק הטמעה מלאה של EuiccManager API.

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

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

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

7.4.1.2. Telecom API

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

• [C-1-1] חובה לתמוך בממשקי ה-API של ConnectionService שמתוארים ב-SDK.
• [C-1-2] חובה להציג שיחה נכנסת חדשה ולאפשר למשתמש לקבל או לדחות את השיחה הנכנסת כשהמשתמש נמצא בשיחה מתמשכת שמתבצעת דרך אפליקציה של צד שלישי שלא תומכת בתכונה 'השהיה' שצוינה באמצעות CAPABILITY_SUPPORT_HOLD.
• [C-1-3] חובה שתהיה אפליקציה שמטמיעה את InCallService.

• [C-SR] מומלץ מאוד להודיע למשתמש שענות לשיחה נכנסת תגרום לניתוק של שיחה פעילה.

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

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

• [C-SR] מומלץ מאוד לטפל באירועים KEYCODE_MEDIA_PLAY_PAUSE ו-KEYCODE_HEADSETHOOK של אוזניות האודיו עבור ממשקי ה-API של android.telecom באופן הבא:
  • קריאה למספר Connection.onDisconnect() כשזוהתה לחיצה קצרה על האירוע המרכזי במהלך שיחה פעילה.
  • קריאה ל-Connection.onAnswer() כשמתגלה לחיצה קצרה על האירוע המרכזי במהלך שיחה נכנסת.
  • קריאה לפונקציה Connection.onReject() כשזוהתה לחיצה ממושכת על האירוע המרכזי במהלך שיחה נכנסת.
  • משנים את סטטוס ההשתקה של CallAudioState.

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) בכל שלב של הפעולה, כולל:
  • גם כשהמסך לא במצב פעיל.
  • להטמעות של מכשירי Android Television, גם במצבי המתנה.
• [C-1-5] אסור להתייחס לקריאה ל-method של ה-API WifiManager.enableNetwork() כסימן מספיק כדי להחליף את Network הפעיל כרגע, שמשמש כברירת מחדל לתנועת האפליקציה ומוחזר על ידי שיטות ה-API של ConnectivityManager, כמו getActiveNetwork ו-registerDefaultNetworkCallback. במילים אחרות, הם יכולים להשבית את הגישה לאינטרנט שמספקת כל ספק רשת אחר (למשל, חבילת גלישה) רק אם הם מאמתים בהצלחה שרשת ה-Wi-Fi מספקת גישה לאינטרנט.
• [C-1-6] מומלץ מאוד, כשמתבצעת קריאה ל-method API‏ ConnectivityManager.reportNetworkConnectivity(), לבדוק מחדש את הגישה לאינטרנט ב-Network. אם לאחר הבדיקה מתברר שה-Network הנוכחי כבר לא מספק גישה לאינטרנט, צריך לעבור לרשת אחרת שזמינה (למשל, נתונים ניידים) ומספקת גישה לאינטרנט.
• [C-SR] מומלץ מאוד לבצע רנדומיזציה של כתובת ה-MAC של המקור ומספר הרצף של פריים הבקשה לבדיקה, פעם אחת בתחילת כל סריקה, בזמן ש-STA מנותק.
  • בכל קבוצה של מסגרות של בקשות לבדיקה שמרכיבות סריקת רשת אחת, צריך להשתמש בכתובת MAC עקבית אחת (אסור לבחור כתובת MAC באופן אקראי באמצע סריקת רשת).
  • מספר הרצף של בקשת הבדיקה צריך לעבור חזרה (באופן רציף) בין בקשות הבדיקה בסריקת ה-Probe.
  • מספר הרצף של בקשת הבדיקה צריך להיות אקראי בין בקשת הבדיקה האחרונה של הסריקה לבין בקשת הבדיקה הראשונה של הסריקה הבאה.
• [C-SR] מומלץ מאוד, בזמן שה-STA מנותק, לאפשר רק את הרכיבים הבאים בפריימים של בקשות הבדיקה:
  • קבוצת פרמטרים של SSID (0)
  • קבוצת פרמטרים של DS (3)

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

• [C-3-1] חובה להשבית את מצב חיסכון האנרגיה ב-Wi-Fi בכל פעם שאפליקציה מקבלת את הנעילה WIFI_MODE_FULL_HIGH_PERF או את הנעילה WIFI_MODE_FULL_LOW_LATENCY דרך ממשקי ה-API של WifiManager.createWifiLock() ו-WifiManager.WifiLock.acquire(), והנעילה פעילה.
• [C-3-2] זמן האחזור הממוצע הלוך ושוב בין המכשיר לנקודת הגישה בזמן שהמכשיר נמצא במצב Wi-Fi עם נעילה לזמן אחזור נמוך (WIFI_MODE_FULL_LOW_LATENCY) חייב להיות קצר יותר מזמן האחזור במצב Wi-Fi עם נעילה לביצועים גבוהים (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR] מומלץ מאוד לצמצם את זמן האחזור הלוך ושוב ב-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.

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), הן:

• צריכה לכלול תמיכה ב-Wi-Fi Passpoint.

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

• [C-1-2] חובה להטמיע את ממשקי ה-API של WifiManager שקשורים ל-Passpoint, כפי שמתואר במסמכי התיעוד של ה-SDK.
• [C-1-3] חובה לתמוך בתקן IEEE 802.11u, שקשור במיוחד לגילוי ולבחירה של רשתות, כמו שירות מודעות גנרי (GAS) ופרוטוקול שאילתות של רשת גישה (ANQP).

לעומת זאת, אם הטמעות המכשירים לא כוללות תמיכה ב-Wi-Fi Passpoint:

• [C-2-1] ההטמעה של ממשקי ה-API של WifiManager שקשורים ל-Passpoint חייבת להוביל להשלכת UnsupportedOperationException.

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 לא משויך לנקודת גישה.

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 אחת לפחות בחיבור סלולרי.

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

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 מהשיטה 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)

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

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

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

• [SR] מומלץ מאוד לספק את מצב חיסכון בחבילת הגלישה.

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

• [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.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.

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) אופקית ביחס לכיוון שצוין על ידי האפליקציה, אם האפליקציה הנוכחית ביקשה במפורש שמסך המצלמה יתהפך באמצעות קריאה לשיטה android.hardware.Camera.setDisplayOrientation(). לעומת זאת, אם האפליקציה הנוכחית לא מבקשת במפורש לסובב את המסך של המצלמה באמצעות קריאה לשיטה android.hardware.Camera.setDisplayOrientation(), התצוגה המקדימה חייבת להיות מוחזרת על ציר אופקי ברירת המחדל של המכשיר.
• [C-1-5] אסור לשקף את התמונות הסטטיות או את הסטרימינג הסופי של הסרטונים שצולמו, שמוחזרים להודעות החזרה (callbacks) של האפליקציה או מועברים לאחסון מדיה.
• [C-1-6] חובה לשקף את התמונה שמוצגת על ידי התצוגה המקדימה באותו אופן שבו מוצג זרם התמונות של תצוגה המקדימה במצלמה.
• יכולות לכלול תכונות (כמו פוקוס אוטומטי, פלאש וכו') שזמינות למצלמות הפונות לאחור, כפי שמתואר בקטע 7.5.1.

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

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

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

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

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

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

• [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, מסומנת כחבילת API שהוצאה משימוש ב-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. לעומת זאת, בהטמעות של מכשירים אסור להכיר או לכבד קבועות מחרוזת שמועברות לשיטה 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] במכשירים עם כמה מצלמות 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] חובה להגדיר אחסון משותף שמחובר כברירת מחדל, כלומר "מחוץ לקופסה", ללא קשר לאופן שבו האחסון מיושם – ברכיב אחסון פנימי או באמצעי אחסון נשלף (למשל, חריץ לכרטיס Secure Digital).
• [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‏ (AOSP).

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

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

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

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

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

• [C-3-1] חובה לספק מנגנון לגישה לנתונים באחסון המשותף של האפליקציה ממחשב מארח.
• צריך לחשוף תוכן משני נתיבי האחסון באופן שקוף באמצעות שירות הסורק של המדיה ב-Android ו-android.provider.MediaStore.
• אפשר להשתמש באחסון בנפח גדול ב-USB, אבל מומלץ להשתמש בפרוטוקול העברת מדיה כדי לעמוד בדרישות.

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

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

7.6.3. Adoptable Storage

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

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

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

• [SR] מומלץ מאוד להטמיע אחסון שניתן להתאמה.

7.7. 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.
• [SR] The port SHOULD use micro-B, micro-AB or Type-C USB form factor. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה.
• [SR] היציאה אמורה להיות ממוקמת בחלק התחתון של המכשיר (בהתאם לכיוון הטבעי) או לאפשר סיבוב מסך תוכנה בכל האפליקציות (כולל מסך הבית), כדי שהמסך יוצג בצורה נכונה כשהמכשיר מונח כך שהיציאה נמצאת בחלק התחתון. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה כדי שיוכלו לשדרג לגרסאות עתידיות של הפלטפורמה.
• [SR] צריך להטמיע תמיכה בזרימת זרם של 1.5A במהלך תנועה וצפצוף HS, כפי שמפורט במפרט טעינה של סוללות USB, גרסה 1.2. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה.
• [SR] מומלץ מאוד לא לתמוך בשיטות טעינה קנייניות שמשנה את מתח Vbus מעבר לרמות ברירת המחדל, או לשנות את התפקידים של מקור או נקודת קליטה, כי הן עלולות לגרום לבעיות בתאימות עם מטענים או מכשירים שתומכים בשיטות הסטנדרטיות של העברת חשמל ב-USB. אמנם ההמלצה היא 'מומלץ מאוד', אבל בגרסאות עתידיות של Android יכול להיות שנחייב את כל המכשירים עם חיבור Type-C לתמוך בתאימות מלאה לטעינה באמצעות מטענים רגילים עם חיבור Type-C.
• [SR] מומלץ מאוד לתמוך ב-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] מומלץ מאוד להטמיע את USB audio class כפי שמתואר במסמכי התיעוד של Android SDK.
• צריך לתמוך בטעינה של התקן ההיקפי המחובר ב-USB במצב מארח, לפרסם זרם מקור של לפחות 1.5A כפי שמפורט בקטע 'פרמטרים של סיום' במפרט של כבל USB Type-C ומחבר USB Type-C, גרסה 1.2 למחברים מסוג USB Type-C, או להשתמש בטווח זרם הפלט של יציאת טעינה במורד הזרם(CDP) כפי שמפורט במפרטים של טעינה של סוללות USB, גרסה 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).
• [SR] מומלץ מאוד לתמוך ב-DisplayPort, צריכה להיות תמיכה בקצבי נתונים של USB SuperSpeed, ומומלץ מאוד לתמוך ב-Power Delivery להחלפת תפקידים של נתונים וחשמל.
• [SR] מומלץ מאוד לא לתמוך במצב 'אביזרי מתאם אודיו' כפי שמתואר בנספח א' של מפרט הכבל והמחבר מסוג USB-C, גרסה 1.2.
• צריך להטמיע את המודל Try.* שמתאים ביותר לגורם הצורה של המכשיר. לדוגמה, במכשיר נייד צריך להטמיע את המודל Try.SNK.

7.8. אודיו

7.8.1. מיקרופון

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

• [C-1-1] חובה לדווח על קבוע התכונה android.hardware.microphone.
• [C-1-2] חייב לעמוד בדרישות להקלטת אודיו שמפורטות בקטע 5.4.
• [C-1-3] חייב לעמוד בדרישות זמן האחזור של האודיו שמפורטות בסעיף 5.6.
• [SR] מומלץ מאוד לתמוך בהקלטה של אולטרסאונד כפי שמתואר בסעיף 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.
• [SR] מומלץ מאוד לתמוך בהפעלה של אולטרסאונד כמעט, כפי שמתואר בסעיף 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] מומלץ מאוד לכלול לפחות אחד מחיבורי האודיו כתקע אודיו 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] מומלץ מאוד לתמוך בכבלים עם מחברי אודיו לפי סדר הפינים של OMTP.
• [C-SR] מומלץ מאוד לתמוך בהקלטת אודיו מאוזניות סטריאופוניות עם מיקרופון.

אם הטמעות של מכשירים כוללות שקע אודיו 3.5 מ"מ עם 4 מוליכים ותמיכה במיקרופון, ומפיצות את android.intent.action.HEADSET_PLUG עם הערך הנוסף microphone מוגדר כ-1, הן:

• [C-2-1] חובה לתמוך בזיהוי המיקרופון בהתקן האודיו המחובר.

7.8.2.2. שקעי אודיו דיגיטליים

כדי להיות תואם לאוזניות ולאביזרי אודיו אחרים עם מחברי USB-C, ולהטמיע (USB audio class) בסביבת Android כפי שמוגדר במפרט של אוזניות USB ל-Android.

הדרישות הספציפיות למכשיר מפורטות בקטע 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]‏ (https://github.com/google/oboe/tree/master/apps/OboeTester).

הבדיקה דורשת מתאם אודיו ל-loopback, שמשתמשים בו ישירות בחיבור 3.5 מ"מ ו/או בשילוב עם מתאם USB-C ל-3.5 מ"מ. מומלץ לבדוק את כל יציאות הקול.

נכון לעכשיו, OboeTester תומך בנתיבים של AAudio, לכן צריך לבדוק את השילובים הבאים כדי לאתר תקלות באמצעות AAudio:

שידור מהימן אמור לעמוד בקריטריונים הבאים ליחס אות לרעש (SNR) ולעיוות הרמוני כולל (THD) עבור גל סינוס של 2,000Hz.

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] מומלץ מאוד להטמיע את GL_EXT_external_buffer,‏ GL_EXT_EGL_image_array ו-GL_OVR_multiview_multisampled_render_to_texture ולהציג את התוספים ברשימת התוספים הזמינים של GL.
• [C-SR] מומלץ מאוד לתמוך ב-Vulkan 1.1.
• [C-SR] מומלץ מאוד להטמיע את VK_ANDROID_external_memory_android_hardware_buffer,‏ VK_GOOGLE_display_timing,‏ VK_KHR_shared_presentable_image ולהציג אותם ברשימת התוספים הזמינים של Vulkan.
• [C-SR] מומלץ מאוד לחשוף לפחות משפחת תורים אחת של 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] מומלץ מאוד לתמוך בהקצאה של AHardwareBuffer עם יותר משכבה אחת ודגלים ופורמטים שצוינו ב-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] מומלץ מאוד שהרזולוציה של המסך תהיה לפחות 2560 x 1440.
• [C-1-15] התצוגה חייבת להתעדכן במהירות של לפחות 60 הרץ במצב VR.
• [C-1-17] המסך חייב לתמוך במצב של עמידות נמוכה עם עמידות של 5 אלפיות השנייה לכל היותר. העמידות מוגדרת כמשך הזמן שבו פיקסל פולט אור.
• [C-1-18] חובה לתמוך ב-Bluetooth 4.2 וב-Bluetooth LE Data Length Extension קטע 7.4.3.
• [C-1-19] חובה לתמוך ב-Direct Channel Type ולדווח עליו בצורה תקינה לכל סוגי החיישנים הבאים שמוגדרים כברירת מחדל:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR] מומלץ מאוד לתמוך בסוג הערוץ הישיר TYPE_HARDWARE_BUFFER לכל סוגי הערוצים הישירים שמפורטים למעלה.
• [C-1-21] חייב לעמוד בדרישות שקשורות לג'ירוסקופ, למד התאוצה ולמגנטומטר עבור android.hardware.hifi_sensors, כפי שמפורט בסעיף 7.3.9.
• [C-SR] מומלץ מאוד לתמוך בתכונה android.hardware.sensor.hifi_sensors.
• [C-1-22] זמן האחזור מקצה לקצה של תנועה לפוטון חייב להיות לא יותר מ-28 אלפיות השנייה.
• [C-SR] מומלץ מאוד שהזמן המצטבר מהתנועה ועד לקבלת הפוטון לא יעלה על 20 אלפיות השנייה.
• [C-1-23] חייב להיות יחס של הפריים הראשון, שהוא היחס בין הבהירות של הפיקסלים בפריים הראשון אחרי מעבר משחור ללבן לבין הבהירות של הפיקסלים הלבנים במצב יציב, של לפחות 85%.
• [C-SR] מומלץ מאוד שהיחס של הפריים הראשון יהיה לפחות 90%.
• יכול לספק ליבה בלעדית לאפליקציה בחזית, ויכול לתמוך ב-API ‏Process.getExclusiveCores כדי להחזיר את המספרים של ליבות המעבד שהן בלעדיות לאפליקציה העליונה בחזית.

אם יש תמיכה בליבה בלעדית, הליבה:

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

7.10. מגע

הדרישות הספציפיות למכשיר מפורטות בקטע 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.

הדרישות הספציפיות למכשיר מפורטות בקטע 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 לגבי הטריגרים, התחזוקה, אלגוריתמי ההתעוררות והשימוש בהגדרות המערכת הגלובליות של המצבים 'המתנה לאפליקציות' ו'שינה עמוקה' לחיסכון באנרגיה.
• [C-1-2] אסור לסטות מההטמעה של AOSP לגבי השימוש בהגדרות גלובליות לניהול הצמצום של משימות, התראות ורשתות באפליקציות בכל קטגוריה של מצב המתנה של אפליקציות.
• [C-1-3] אסור לסטות מההטמעה של AOSP לגבי מספר הקטגוריות של סטטוס 'אפליקציה במצב המתנה' שמשמש לסטטוס 'אפליקציה במצב המתנה'.
• [C-1-4] חובה להטמיע קטגוריות של אפליקציות במצב המתנה ו-Doze כפי שמתואר בקטע ניהול צריכת החשמל.
• [C-1-5] חובה להחזיר את הערך true עבור PowerManager.isPowerSaveMode() כשהמכשיר במצב חיסכון בסוללה.
• [C-SR] מומלץ מאוד לספק למשתמשים אפשרות להפעיל ולהשבית את התכונה 'חיסכון בסוללה'.
• [C-SR] מומלץ מאוד לספק למשתמשים אפשרות להציג את כל האפליקציות שפטורות ממצבי חיסכון באנרגיה 'המתנה לאפליקציה' ו'שינה עמוקה'.

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

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

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

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

9.1. הרשאות

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

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

• מותר להוסיף הרשאות נוספות, בתנאי שמחרוזות מזהה ההרשאה החדשות לא נמצאות במרחב השמות android.\*.

• [C-0-2] חובה להעניק הרשאות עם protectionLevel של PROTECTION_FLAG_PRIVILEGED רק לאפליקציות שמותקנות מראש בנתיבים המורשים של קובץ האימג' של המערכת, ובמסגרת קבוצת המשנה של ההרשאות שמופיעות במפורש ברשימת ההיתרים של כל אפליקציה. ההטמעה של AOSP עומדת בדרישות האלה על ידי קריאה של ההרשאות שמופיעות ברשימת ההיתרים של כל אפליקציה מהקבצים שבנתיב etc/permissions/ וביצוע שלהן, ושימוש בנתיב system/priv-app כנתיב המורשה.

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

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

• [C-0-3] חובה להציג ממשק ייעודי למשתמש כדי שהוא יוכל להחליט אם להעניק את הרשאות זמן הריצה המבוקשות, וגם לספק ממשק למשתמש לניהול הרשאות זמן הריצה.
• [C-0-4] חובה שתהיה הטמעה אחת בלבד של שני ממשקי המשתמש.
• [C-0-5] אסור להעניק הרשאות זמן ריצה לאפליקציות שהותקנו מראש, אלא אם:
  • אפשר לקבל את הסכמת המשתמש לפני שהאפליקציה משתמשת בה.
  • ההרשאות בסביבת זמן הריצה משויכות לדפוס של כוונה (intent) שבו האפליקציה שמותקנת מראש מוגדרת כ-handler שמוגדר כברירת מחדל.
• [C-0-6] חובה להעניק את ההרשאה android.permission.RECOVER_KEYSTORE רק לאפליקציות מערכת שמירשמו סוכן שחזור מאובטח כראוי. סוכן שחזור מאובטח מוגדר כסוכן תוכנה במכשיר שמסתנכרן עם אחסון מרוחק מחוץ למכשיר, שמאובזר בחומרה מאובטחת עם הגנה שווה או חזקה יותר מזו שמתוארת בשירות Google Cloud Key Vault, כדי למנוע התקפות כוח גולמי על גורם הידע במסך הנעילה.

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

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

  • המיקום של המכשיר (למשל, קו הרוחב וקו האורך).
  • מידע שאפשר להשתמש בו כדי לקבוע או להעריך את המיקום של המכשיר (למשל SSID,‏ BSSID,‏ Cell ID או המיקום של הרשת שאליה המכשיר מחובר).
  • הפעילות הגופנית של המשתמש או הסיווג של הפעילות הגופנית.

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

• [C-0-8] חובה לקבל את הסכמת המשתמש כדי לאפשר לאפליקציה לגשת לנתוני המיקום או לנתוני הפעילות הגופנית.
• [C-0-9] חובה להקצות הרשאת זמן ריצה רק לאפליקציה שיש לה הרשאה מספקת, כפי שמתואר ב-SDK. לדוגמה, TelephonyManager#getServiceState מחייב את android.permission.ACCESS_FINE_LOCATION.

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

• [C-0-10] אסור להקצות לאפליקציה הרשאות שמסומנות בדגל hardRestricted, אלא אם:

  • קובץ APK של אפליקציה נמצא במחיצה של המערכת.
  • המשתמש מקצה לאפליקציה תפקיד שמשויך להרשאות hardRestricted.
  • מנהל ההתקנה מעניק את hardRestricted לאפליקציה.
  • אפליקציה קיבלה את ההרשאה hardRestricted בגרסה קודמת של Android.

• [C-0-11] אפליקציות עם הרשאת softRestricted חייבות לקבל גישה מוגבלת בלבד, אסור להן לקבל גישה מלאה עד להוספה לרשימת ההיתרים כפי שמתואר ב-SDK, שבו הגדרות הגישה המלאה והמוגבלת מפורטות לכל הרשאת softRestricted (לדוגמה, READ_EXTERNAL_STORAGE).

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-0-4] סביבות זמן ריצה חלופיות חייבות לציית למודל ה-sandbox של Android, ואפליקציות מותקנות שמשתמשות בסביבת זמן ריצה חלופית אסור להשתמש שוב ב-sandbox של אפליקציה אחרת שמותקנת במכשיר, מלבד באמצעות המנגנונים הרגילים של 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 יש תמיכה בריבוי משתמשים ותמיכה בבידוד מלא של משתמשים.

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

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

• [C-1-1] חובה לעמוד בדרישות הבאות שקשורות לתמיכה בכמה משתמשים.
• [C-1-2] חובה להטמיע לכל משתמש מודל אבטחה שתואם למודל האבטחה של פלטפורמת Android, כפי שמוגדר במסמך העזרה בנושא אבטחה והרשאות בממשקי ה-API.
• [C-1-3] חובה שיהיה לכל מכונה של משתמש ספריות נפרדות ומבודדות של אחסון משותף לאפליקציות (נקראות גם /sdcard).
• [C-1-4] חובה לוודא שאפליקציות שבבעלות משתמש מסוים שפועלות בשם המשתמש הזה לא יכולות להכין רשימה של קבצים שבבעלות משתמש אחר, לקרוא אותם או לכתוב בהם, גם אם הנתונים של שני המשתמשים מאוחסנים באותו נפח אחסון או באותה מערכת קבצים.
• [C-1-5] חובה להצפין את התוכן של כרטיס ה-SD כשהאפשרות של משתמשים מרובים מופעלת, באמצעות מפתח שמאוחסן רק במדיה לא נשלפת שרק למערכת יש גישה אליה, אם הטמעות המכשיר משתמשות במדיה נשלפת ל-API של האחסון החיצוני. מכיוון שהשינוי הזה ימנע ממחשבים מארחים לקרוא את המדיה, הטמעות של מכשירים יצטרכו לעבור ל-MTP או למערכת דומה כדי לספק למחשבים מארחים גישה לנתונים של המשתמש הנוכחי.

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

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

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

• [C-1-1] חובה להזהיר את המשתמשים לפני שליחת הודעת SMS למספרים שזוהו באמצעות ביטויים רגולריים שהוגדרו בקובץ /data/misc/sms/codes.xml במכשיר. ב-upstream של פרויקט Android Open Source יש הטמעה שעומדת בדרישות האלה.

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

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

ארגז החול של Android כולל תכונות שמשתמשות במערכת אבטחה משופרת ל-Linux‏ (SELinux) עם בקרת גישה (MAC) חובה, ב-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), כפי שמתואר בקטע 'הגדרת הליבה' באתר 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).
• [SR] מומלץ מאוד לשמור על נתוני הליבה שנכתבים רק במהלך האתחול כנתונים שסומנו לקריאה בלבד אחרי האתחול (למשל __ro_after_init).

• [C-SR] מומלץ מאוד לבצע רנדומיזציה של הפריסה של קוד הליבה והזיכרון, ולהימנע מחשיפות שעלולות לפגוע ברנדומיזציה (למשל, CONFIG_RANDOMIZE_BASE עם אנטרופיה של bootloader דרך /chosen/kaslr-seed Device Tree node או EFI_RNG_PROTOCOL).

• [C-SR] מומלץ מאוד להפעיל את תקינות זרימת הבקרה (CFI) בליבה כדי לספק הגנה נוספת מפני התקפות של שימוש חוזר בקוד (למשל CONFIG_CFI_CLANG ו-CONFIG_SHADOW_CALL_STACK).

• [C-SR] מומלץ מאוד לא להשבית את התכונות Control-Flow Integrity‏ (CFI), ‏ Shadow Call Stack‏ (SCS) או Integer Overflow Sanitization‏ (IntSan) ברכיבים שבהם הן מופעלות.
• [C-SR] מומלץ מאוד להפעיל את CFI, ‏ SCS ו-IntSan בכל רכיב נוסף של מרחב המשתמש שחשוף לאיומי אבטחה, כפי שמוסבר במאמרים CFI ו-IntSan.
• [C-SR] מומלץ מאוד להפעיל את האינטוליזציה של הסטאק בליבה כדי למנוע שימוש במשתנים מקומיים שלא עברו איניטוליזציה (CONFIG_INIT_STACK_ALL או CONFIG_INIT_STACK_ALL_ZERO). כמו כן, לא מומלץ להניח שהערך שבו משתמש המהדרר כדי לאתחל את המשתנים המקומיים הוא הערך שיהיה במכשיר.
• [C-SR] מומלץ מאוד להפעיל את האינטליקציה של אשכול בתוך הליבה כדי למנוע שימוש בהקצאות אשכול ללא איפוס (CONFIG_INIT_ON_ALLOC_DEFAULT_ON), ואסור להניח שהערך שבו הליבה משתמשת כדי לאפס את ההקצאות האלה הוא הערך הנכון.

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

• [C-1-1] חובה להטמיע את SELinux.
• [C-1-2] חובה להגדיר את SELinux למצב אכיפה גלובלי.
• [C-1-3] חובה להגדיר את כל הדומיינים במצב אכיפה. אסור להשתמש בדומיינים במצב הרשאות רחבות, כולל דומיינים ספציפיים למכשיר או לספק.
• [C-1-4] אסור לשנות, להשמיט או להחליף את כללי neverallow שנמצאים בתיקייה system/sepolicy שסופקו ב-upstream של Android Open Source Project‏ (AOSP). בנוסף, המדיניות חייבת לעבור הידור עם כל כללי neverallow הקיימים, גם לדומיינים של AOSP SELinux וגם לדומיינים ספציפיים למכשיר או לספק.
• [C-1-5] חובה להריץ אפליקציות של צד שלישי שמטרגטות API ברמה 28 ואילך בארגזים של חול של SELinux לכל אפליקציה, עם הגבלות SELinux לכל אפליקציה על ספריית הנתונים הפרטית של כל אפליקציה.
• צריך לשמור על מדיניות ברירת המחדל של SELinux שסופקת בתיקייה system/sepolicy של Android Open Source Project ב-upstream, ולהוסיף למדיניות הזו רק את ההגדרות הספציפיות למכשיר.

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

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

• [C-2-1] חובה להשתמש במערכת חובה לבקרת גישה שדומה ל-SELinux.

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

9.8. פרטיות

9.8.1. היסטוריית השימוש

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

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

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

מערכת Android שומרת את אירועי המערכת באמצעות המזהים StatsLog, ומנהלת את ההיסטוריה הזו באמצעות System API של StatsManager ו-IncidentManager.

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

• [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] חובה להציג ולקבל הסכמה מפורשת מהמשתמשים לאפשרות לתעד מידע רגיש שמוצג במסך שלהם בכל פעם שהפעלת העברת המסך או הקלטת המסך מופעלת באמצעות MediaProjection או ממשקי API קנייניים. אסור לספק למשתמשים אפשרות להשבית את הצגת הבקשה להסכמה של המשתמשים בעתיד.
• [C-0-3] חובה להציג התראה מתמשכת למשתמש בזמן שההעברה (cast) או ההקלטה של המסך מופעלות. כדי לעמוד בדרישות האלה, ב-AOSP מוצג סמל של התראה מתמשכת בסרגל הסטטוס.

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

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

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

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

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, על ידי הגדרת המאפיין SERVICE_META_DATA_SUPPORTS_ALWAYS_ON לערך false.

9.8.5. מזהי המכשיר

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

• [C-0-1] חובה למנוע גישה למספר הסידורי של המכשיר, ובמקרים הרלוונטיים, למספר ה-IMEI/MEID, למספר הסידורי של כרטיס ה-SIM ולמזהה המנוי הנייד הבינלאומי (IMSI) מאפליקציה, אלא אם היא עומדת באחת מהדרישות הבאות:
  • היא אפליקציה חתומה של ספק שמאומתת על ידי יצרני המכשירים.
  • קיבלה את ההרשאה READ_PRIVILEGED_PHONE_STATE.
  • יש לו הרשאות ספק כפי שמוגדרות במאמר הרשאות ספק של UICC.
  • הוא בעל מכשיר או בעל פרופיל שקיבלו את ההרשאה READ_PHONE_STATE.
  • (למספר סידורי של כרטיס SIM או ICCID בלבד) קיימת דרישה בתקנות המקומיות שהאפליקציה תזהה שינויים בזהות המנוי.

9.8.6. תיעוד תוכן

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

• טקסט וגרפיקה שעבר רינדור במסך, כולל, בין היתר, התראות ונתוני עזרה דרך AssistStructure API.
• נתוני מדיה, כמו אודיו או וידאו, שהמכשיר הקליט או הפעיל.
• אירועי קלט (למשל מקשים, עכבר, תנועות, קול, וידאו ונגישות).
• כל אירוע אחר שהאפליקציה מספקת למערכת דרך ממשק ה-API של Content Capture או ממשק API ייחודי בעל יכולות דומות.
• כל טקסט או נתונים אחרים שנשלחים דרך TextClassifier API אל System TextClassifier, כלומר לשירות המערכת כדי להבין את משמעות הטקסט, וגם כדי ליצור פעולות צפויות הבאות על סמך הטקסט.

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

• [C-1-1] חובה להצפין את כל הנתונים האלה כשהם מאוחסנים במכשיר. ההצפנה הזו עשויה להתבצע באמצעות הצפנה מבוססת-קובץ של Android, או באמצעות כל אחד מהצפנים שמפורטים כ-API מגרסה 26 ואילך, כפי שמתואר ב-Cipher SDK.
• [C-1-2] אסור לגבות נתונים גולמיים או נתונים מוצפנים באמצעות שיטות הגיבוי של Android או כל שיטת גיבוי אחרת.
• [C-1-3] חובה לשלוח את כל הנתונים האלה ואת היומן של המכשיר רק באמצעות מנגנון לשמירה על פרטיות. המנגנון לשמירה על הפרטיות מוגדר כ'מנגנונים שמאפשרים רק ניתוח מצטבר ומונעים התאמה של אירועים ביומן או תוצאות נגזרות למשתמשים ספציפיים', כדי למנוע ניתוח נתונים לכל משתמש (למשל, הטמעה באמצעות טכנולוגיית פרטיות דיפרנציאלית כמו RAPPOR).
• [C-1-4] אסור לשייך נתונים כאלה לזהות משתמש כלשהי (כמו Account) במכשיר, אלא אם קיבלתם הסכמה מפורשת מהמשתמש בכל פעם שהנתונים משויכים.
• [C-1-5] אסור לשתף נתונים כאלה עם אפליקציות אחרות, אלא אם יש הסכמה מפורשת של המשתמש בכל פעם שהנתונים משותפים.
• [C-1-6] חובה לספק למשתמשים אפשרות למחוק נתונים כאלה שנאספים על ידי ContentCaptureService או על ידי האמצעים הקנייניים, אם הנתונים מאוחסנים במכשיר בצורה כלשהי.

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

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

• [C-SR] מומלץ מאוד להפריד בין רכיבי השירות לתיעוד התוכן לבין רכיבי מערכת אחרים, למשל, לא לקשר את השירות או לשתף את מזהי התהליכים, מלבד הרכיבים הבאים:

  • טלפוניה, אנשי קשר, ממשק המשתמש של המערכת ומדיה

9.8.7. גישה ללוח העריכה

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

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

9.8.8. מיקום

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

• [C-0-1] אסור להפעיל או להשבית את הגדרת המיקום של המכשיר ואת הגדרות הסריקה של Wi-Fi או Bluetooth בלי הסכמה מפורשת של המשתמש או בלי שהמשתמש ייזום זאת.
• [C-0-2] חובה לספק למשתמש גישה למידע שקשור למיקום, כולל בקשות מיקום מהזמן האחרון, הרשאות ברמת האפליקציה ושימוש בסריקה של Wi-Fi או Bluetooth כדי לקבוע את המיקום.
• [C-0-3] חובה לוודא שהאפליקציה שמשתמשת ב-Emergency Location Bypass API‏ [LocationRequest.setLocationSettingsIgnored()] היא סשן חירום ביוזמת המשתמש (למשל, חיוג למספר 911 או שליחת הודעת טקסט למספר 911). עם זאת, ברכב יכול להתבצע התחלה של סשן חירום ללא אינטראקציה פעילה של המשתמש במקרה של זיהוי של תאונה (למשל, כדי לעמוד בדרישות של 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 מותאמים אישית שנוספו על ידי מי שמטמיע את המכשיר, או פרטים שאפשר לגשת אליהם דרך מערכת הקבצים.

9.8.10. דוח על באג בקישוריות

אם הטמעות במכשירים יוצרות דוחות באגים באמצעות System API‏ BUGREPORT_MODE_TELEPHONY עם BugreportManager, הן:

• [C-1-1] חובה לקבל הסכמה מהמשתמש בכל פעם שמפעילים את System API‏ BUGREPORT_MODE_TELEPHONY כדי ליצור דוח, אסור לבקש מהמשתמש להביע הסכמה לכל הבקשות העתידיות מהאפליקציה.
• [C-1-2] חובה להציג ולקבל הסכמה מפורשת מהמשתמשים כשהדוחות מתחילים להיווצר, אסור להחזיר את הדוח שנוצר לאפליקציה המבקשת ללא הסכמה מפורשת מהמשתמשים.
• [C-1-3] חובה ליצור את הדוחות המבוקשים, שכוללים לפחות את הפרטים הבאים:
  • Dump של TelephonyDebugService
  • Dump של TelephonyRegistry
  • WifiService dump
  • יצירת dump של ConnectivityService
  • דמפ של מופע CarrierService של החבילה הקוראת (אם הוא מקושר)
  • מאגר נתונים זמני של יומן הרדיו
• [C-1-4] אסור לכלול את הפרטים הבאים בדוחות שנוצרים:
  • כל מידע שלא קשור לניפוי באגים של קישוריות.
  • כל סוג של יומני תנועה של אפליקציות שהותקנו על ידי משתמשים או פרופילים מפורטים של אפליקציות או חבילות שהותקנו על ידי משתמשים (אפשר להשתמש במזהי משתמש, אבל לא בשמות של חבילות).
• יכול לכלול מידע נוסף שלא משויך לזהות של משתמש כלשהו. (למשל יומני ספקים).

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

• [C-SR] מומלץ מאוד להגדיר כברירת מחדל שההגדרה של המפתח תהיה מושבתת. כדי לעמוד בדרישות האלה, ב-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.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) שמיקומי האחסון של נתוני הכניסה המוצפנים (CE) ושל נתוני המכשיר המוצפנים (DE) זמינים למשתמש.

9.9.2. דרישות הצפנה

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

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

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

  • הצפנה מבוססת-קובץ (FBE) והצפנת מטא-נתונים כפי שמתואר בקטע 9.9.3.1.
  • הצפנה ברמת הבלוק לכל משתמש, כפי שמתואר בקטע 9.9.3.2.

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

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

• צריך להפוך אפליקציות חיוניות שהותקנו מראש (למשל, 'שעון מעורר', 'טלפון', 'Messenger') למודעות לטעינה ישירה.

בפרויקט Android Open Source ב-upstream יש הטמעה מועדפת של הצפנה מבוססת-קבצים שמבוססת על תכונת ההצפנה 'fscrypt' של ליבה של Linux, והטמעה מועדפת של הצפנת מטא-נתונים שמבוססת על התכונה 'dm-default-key' של ליבה של Linux.

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

• [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] אם יש במכשיר כמה צ'יפים נפרדים (למשל, רדיו, מעבד תמונות מיוחד), מומלץ מאוד לאמת כל שלב בתהליך האתחול של כל אחד מהצ'יפים האלה.
• [C-1-8] חובה להשתמש באחסון עם תכונה למניעת פגיעה: לאחסון הנתונים לגבי הנעילה של מנהל האתחול. אחסון עם תכונה למניעת פגיעה (tamper-evident) פירושו שה-bootloader יכול לזהות אם בוצעה פגיעה באחסון מתוך Android.
• [C-1-9] חובה להציג למשתמש הודעה בזמן השימוש במכשיר ולחייב אישור פיזי לפני שמאפשרים מעבר ממצב נעילה של תוכנת האתחול למצב ביטול נעילה של תוכנת האתחול.
• [C-1-10] חובה להטמיע הגנה מפני חזרה לאחור למחיצות שבהן Android משתמש (למשל, מחיצות אתחול, מחיצות מערכת) ולהשתמש באחסון עם אימות נגד זיוף לאחסון המטא-נתונים שמשמשים לקביעת גרסת מערכת ההפעלה המינימלית המותרת.
• [C-SR] מומלץ מאוד לאמת את כל קובצי ה-APK של האפליקציות עם הרשאות באמצעות שרשרת אמון שמקורה במחיצות שמוגנות על ידי Verified Boot.
• [C-SR] מומלץ מאוד לאמת את כל הארטיפקטים ההפעלה שאפליקציה בעלת הרשאות טוענת מחוץ לקובץ ה-APK שלה (כמו קוד שנטען באופן דינמי או קוד שעבר הידור) לפני שמפעילים אותם, או מומלץ מאוד לא להפעיל אותם בכלל.
• צריך להטמיע הגנה מפני חזרה לאחור בכל רכיב עם קושחת קבועה (למשל, מודם, מצלמה) ולהשתמש באחסון עם תכונה למניעת פגיעה כדי לאחסן את המטא-נתונים שמשמשים לקביעת הגרסה המינימלית המותרת.

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

ב-upstream של פרויקט הקוד הפתוח של Android יש הטמעה מועדפת של התכונה הזו במאגר external/avb/, שאפשר לשלב ב-bootloader שמשמש לטעינת Android.

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

• [C-0-3] חובה לתמוך באימות קריפטוגרפית של תוכן הקובץ באמצעות מפתח מהימן, בלי לקרוא את הקובץ כולו.
• [C-0-4] אסור לאפשר לבקשות הקריאה בקובץ מוגן להצליח אם תוכן הקריאה לא מאומת באמצעות מפתח מהימן.

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

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

• [C-R] מומלץ לתמוך ב-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] באימות של מסך הנעילה חייב להיות הגבלת קצב ניסיונות, וחייבת להיות לו אלגוריתם חזרה איטית (backoff) מעריכי. אחרי 150 ניסיונות כושלים, זמן ההשהיה חייב להיות לפחות 24 שעות לכל ניסיון.
• לא צריך להגביל את מספר המפתחות שאפשר ליצור

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

• [C-1-1] חובה לגבות את הטמעת מאגר המפתחות באמצעות סביבת הפעלה מבודדת.
• [C-1-2] חובה שתהיה הטמעה של אלגוריתמים קריפטוגרפיים מסוג RSA,‏ AES,‏ ECDSA ו-HMAC ופונקציות גיבוב ממשפחת MD5,‏ SHA1 ו-SHA-2 כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בליבה ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד הליבה או קוד מרחב המשתמש עשויים לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. בפרויקט Android Open Source Project (AOSP) ב-upstream מתקיימים הדרישות האלה באמצעות ההטמעה של 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 שניות. במכשירים לרכב, שמנעלים את המסך בכל פעם שהיחידה הראשית מושבתת או שהמשתמש עובר, יכול להיות שלא תהיה הגדרה של זמן קצוב ליציאה ממצב שינה.

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

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

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

• [C-SR] מומלץ מאוד להגדיר רק אחת מהשיטות הבאות כשיטת האימות הראשית:
  • קוד אימות מספרי
  • סיסמה אלפאנומרית
  • דפוס החלקה ברשת של 9 נקודות בדיוק, בסידור 3x3

שימו לב: שיטות האימות שלמעלה נקראות במסמך הזה שיטות האימות הראשיות המומלצות.

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

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

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

• [C-3-1] האנטרופיה של האורך הקצר ביותר של קלט מותר חייבת להיות גדולה מ-10 ביט.
• [C-3-2] ההאנטרופיה המקסימלית של כל ערכי הקלט האפשריים חייבת להיות גדולה מ-18 ביט.
• [C-3-3] שיטת האימות החדשה אסור שתחליף אף אחת משיטות האימות הראשיות המומלצות (כלומר, קוד אימות, קו ביטול נעילה, סיסמה) שמוטמעות ומסופקות ב-AOSP.
• [C-3-4] חובה להשבית את שיטת האימות החדשה כשאפליקציית Device Policy Controller‏ (DPC) מגדירה את מדיניות האיכות של הסיסמאות באמצעות השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_SOMETHING.
• [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.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_UNSPECIFIED.
• [C-6-3] חובה לבצע אצל המשתמש אתגר לאחת משיטות האימות הראשיות המומלצות (למשל, קוד אימות, קו ביטול נעילה, סיסמה) לפחות פעם אחת בכל 4 שעות או פחות.
• [C-6-4] אסור להתייחס לשיטה החדשה כמסך נעילה מאובטח, וצריך לפעול לפי האילוצים שמפורטים בקטע C-8 בהמשך.

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

• [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 באותו מכשיר שבו נעשה שימוש במפתח. לדוגמה, מותר למפתח שמאוחסן בטלפון לבטל את הנעילה של חשבון משתמש בטלוויזיה. במכשירים לכלי רכב, אסור לאחסן את אסימון ה-escrow באף חלק ברכב.
• [C-7-6] חובה להודיע למשתמש על ההשלכות של האבטחה לפני שמפעילים את אסימון ההתחייבות להחזקה לצורך פירעון כדי לפענח את אחסון הנתונים.
• [C-7-7] חובה שיהיה מנגנון חלופי לשימוש באחת משיטות האימות הראשיות המומלצות.
• [C-7-8] חובה לבקש מהמשתמש לבצע אחת מהשיטות המומלצות לאימות ראשוני (למשל: קוד אימות, קו ביטול נעילה, סיסמה) לפחות פעם אחת בכל 72 שעות או פחות, אלא אם יש חשש לגבי בטיחות המשתמש (למשל: הסחת דעת של הנהג).
• [C-7-9] חובה לבקש מהמשתמש לבצע אחת משיטות האימות הראשיות המומלצות (למשל: קוד אימות, דפוס, סיסמה) כפי שמתואר ב-[C-1-7] וב-[C-1-8] בקטע 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_UNSPECIFIED.
• [C-8-2] אסור לאפס את הטיימר לתפוגת התוקף של הסיסמה שהוגדר על ידי DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] אסור לחשוף ממשק API לשימוש באפליקציות צד שלישי כדי לשנות את מצב הנעילה.

9.11.2. StrongBox

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

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

• [C-SR] מומלץ מאוד לתמוך ב-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] מומלץ מאוד לכלול את החומרה שנבדקה באמצעות יעד אבטחה, רמת הבטחת הערכה (EAL) 5, עם תוספת של AVA_VAN.5. סביר להניח שהאישור EAL 5 יהפוך לדרישה בגרסה עתידית.

• מומלץ מאוד להשתמש ב-[C-SR] כדי לספק עמידות בפני התקפות מבפנים (IAR). המשמעות היא שגורם פנימי עם גישה למפתחות החתימה של הקושחה לא יכול ליצור קושחה שגורמת לדליפה של סודות מ-StrongBox, לעקוף את דרישות האבטחה הפונקציונליות או לאפשר גישה לנתוני משתמשים רגישים בדרכים אחרות. הדרך המומלצת להטמיע את IAR היא לאפשר עדכוני קושחה רק כשסיסמת המשתמש הראשי מסופקת דרך ה-HAL של IAuthSecret.

9.11.3. המסמך לאימות הזהות

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

• [C-SR] מומלץ מאוד להטמיע את מערכת פרטי הכניסה לזיהוי.

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

• [C-0-1] חובה להחזיר ערך שאינו null בשיטה IdentityCredentialStore#getInstance()‎.

• [C-0-2] חובה להטמיע את מערכת פרטי הכניסה לזיהוי (למשל ממשקי ה-API של android.security.identity.*) באמצעות קוד שמתקשר עם אפליקציה מהימנה באזור שמבודד בצורה מאובטחת מהקוד שפועל בליבה ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד של ליבה או של מרחב משתמש עשוי לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA.

• [C-0-3] הפעולות הקריפטוגרפיות הנדרשות להטמעת מערכת פרטי הכניסה לזהות (למשל ממשקי ה-API של android.security.identity.*) חייבות להתבצע באופן מלא באפליקציה המהימנה, וחומר המפתח הפרטי לעולם לא יכול לצאת מסביבת הביצוע המבודדת, אלא אם נדרש באופן ספציפי על ידי ממשקי API ברמה גבוהה יותר (למשל, השיטה createEphemeralKeyPair()‎).

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

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

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

• [SR] 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 framework כדי למנוע אינטראקציה זדונית או לא מכוונת עם תת-המערכות האלה.

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

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

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

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

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

• [C-0-1] חובה לעבור את Android Compatibility Test Suite‏ (CTS) שזמין בפרויקט Android Open Source, באמצעות תוכנת האריזה הסופית במכשיר.

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

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

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

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

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

• [C-SR] מומלץ מאוד שמנגנון החתימה יבצע גיבוב (hash) של העדכון באמצעות SHA-256 ויאמת את הגיבוב באמצעות המפתח הציבורי באמצעות ECDSA NIST P-256.

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

• [C-1-1] חובה לתמוך בהורדות OTA עם עדכון אופליין באמצעות הפעלה מחדש.

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

בנוסף, הטמעות במכשירים אמורות לתמוך בעדכוני מערכת מסוג A/B. התכונה הזו מיושמת ב-AOSP באמצעות HAL לבקרת אתחול.

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

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

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

• [C-3-1] חובה להטמיע את ההתנהגות שמתוארת בכיתה SystemUpdatePolicy.

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

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

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

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

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

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

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

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

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

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

13. יצירת קשר

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