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

1. מבוא

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

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

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

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

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

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

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

1.1 מבנה המסמך

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1. חומרה

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

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

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

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

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

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

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

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

אם ההטמעות של מכשירים ניידים מצהירות על תמיכה במסכים עם טווח דינמי גבוה באמצעות 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.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-1] מומלץ מאוד להפעיל את אפליקציית העזרה שבחר המשתמש, כלומר האפליקציה שמטמיעה את VoiceInteractionService, או פעילות שמטפלת באירוע ACTION_ASSIST של לחיצה ארוכה על KEYCODE_MEDIA_PLAY_PAUSE או על KEYCODE_HEADSETHOOK, אם הפעילות בחזית לא מטפלת באירועים האלה של לחיצה ארוכה.
  • [7.3.1/H-SR-1] מומלץ מאוד לכלול מד תאוצה ב-3 צירים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • הערך של [5.6(#56_audio-latency)/H-1-1] חייב להיות זמן אחזור ממוצע רציף הלוך ושוב של 800 אלפיות השנייה או פחות ב-5 מדידות, עם סטייה ממוצעת אבסולוטית של פחות מ-100 אלפיות השנייה, לפחות במסלול נתמך אחד.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 (AOSP) ב-upstream מתקיימים הדרישות האלה באמצעות ההטמעה של Trusty, אבל יש גם אפשרויות חלופיות: פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת של בידוד תקין שמבוסס על hypervisor, שעבר בדיקה על ידי צד שלישי.
  • [9.11/H-0-4] חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק אם הוא מצליח, לאפשר שימוש במפתחות שמקושרים לאימות. חובה לאחסן את פרטי הכניסה של מסך הנעילה באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. בפרויקט הקוד הפתוח של Android תוכלו למצוא את שכבת האובייקטים המצומצמים לחומרה (HAL) של Gatekeeper ו-Trusty, שאפשר להשתמש בהם כדי לעמוד בדרישות האלה.
  • [9.11/H-0-5] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה לאימות מוגן על ידי חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה לאימות במספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת מהדרכים לעמוד בדרישות האלה היא לשתף את אותו מפתח אימות, אלא אם מיוצרות לפחות 100,000 יחידות של מק"ט נתון. אם מיוצרות יותר מ-100,000 יחידות של מק"ט מסוים, יכול להיות שייעשה שימוש במפתח שונה לכל 100,000 יחידות.
  • [9/H-0-1] חובה להצהיר על התכונה 'android.hardware.security.model.compatible'.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.7.1. מדיה

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

  • חובה לעמוד בדרישות המדיה המפורטות ב-CDD של Android 11 בקטע 2.2.7.1

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

  • [5.1/H-1-1] חובה לפרסם את המספר המקסימלי של סשנים של מקודד וידאו לחומרה שאפשר להריץ בו-זמנית בכל שילוב של קודק באמצעות השיטות CodecCapabilities.getMaxSupportedInstances() ו-VideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-2] חובה לתמוך ב-6 מופעים של סשנים של מקודד וידאו בחומרה (AVC, ‏ HEVC, ‏ VP9* ואילך) בכל שילוב של קודקים שפועלים בו-זמנית ברזולוציה של 720p‏@30fps. *נדרשות רק 2 מכונות אם קודק VP9 נמצא.
  • [5.1/H-1-3] חובה לפרסם את המספר המקסימלי של סשנים של מקודד וידאו לחומרה שאפשר להריץ בו-זמנית בכל שילוב של קודק באמצעות השיטות CodecCapabilities.getMaxSupportedInstances() ו-VideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-4] חובה לתמוך ב-6 מופעים של סשנים של מקודד וידאו בחומרה (AVC, ‏ HEVC, ‏ VP9* ואילך) בכל שילוב של קודקים שפועלים בו-זמנית ברזולוציה של 720p‏@30fps. *נדרשות רק 2 מכונות אם יש קודיק VP9.
  • [5.1/H-1-5] חובה לפרסם את המספר המקסימלי של סשנים של מקודד וידאו לחומרה ושל מפענח וידאו לחומרה שאפשר להריץ בו-זמנית בכל שילוב של קודק באמצעות השיטות CodecCapabilities.getMaxSupportedInstances() ו-VideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-6] חובה לתמוך ב-6 מופעים של סשנים של מקודד וידאו בחומרה ושל מפענח וידאו בחומרה (AVC, ‏ HEVC, ‏ VP9* ואילך) בכל שילוב של קודקים שפועלים בו-זמנית ברזולוציה של 720p‏@30fps. *נדרשות רק 2 מכונות אם קודק VP9 נמצא.
  • [5.1/H-1-7] זמן האחזור להפעלת הקודק חייב להיות 50 אלפיות השנייה או פחות בסשן קידוד וידאו ברזולוציה של 1080p או פחות, לכל מכשירי הקידוד של וידאו בחומרה (מלבד קודק Dolby Vision) במצב עומס. העומס מוגדר כאן כסשן המרה בו-זמנית של וידאו בלבד מ-1080p ל-720p באמצעות קודקים של וידאו בחומרה, יחד עם האתחול של הקלטת האודיו-ווידאו ב-1080p.
  • [5.1/H-1-8] זמן האחזור להפעלת הקודק חייב להיות 40 אלפיות השנייה או פחות בסשן קידוד אודיו בקצב העברת נתונים של 128kbps או פחות, לכל מקודדי האודיו במצב עומס. העומס מוגדר כאן כסשן המרה בו-זמנית של וידאו בלבד מ-1080p ל-720p באמצעות רכיבי קודק וידאו בחומרה, יחד עם האתחול של ההקלטה של אודיו ווידאו ב-1080p.
  • [5.3/H-1-1] אסור שיהיו יותר מ-2 פריימים חסרים ב-10 שניות (כלומר פחות מ-0.333 אחוז פריימים חסרים) בסשן וידאו באיכות 1080p בקצב 60fps במצב עומס. עומס מוגדר כסשן המרה בו-זמנית של וידאו בלבד מ-1080p ל-720p באמצעות קודקי וידאו לחומרה, וכן הפעלת אודיו AAC של 128kbps.
  • [5.3/H-1-2] אסור להחמיץ יותר מ-2 פריימים ב-10 שניות במהלך שינוי ברזולוציית הווידאו בסשן וידאו של 60fps בעומס. העומס מוגדר כסשן המרה בו-זמנית של וידאו בלבד מ-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.MEDIA_PERFORMANCE_CLASS, המשמעות היא שהן:

  • חובה לעמוד בדרישות המצלמה שמפורטות ב-CDD של Android 11 בקטע 2.2.7.2

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

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

2.2.7.3. חומרה

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

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

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

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

2.2.7.4. ביצועים

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

  • חובה לעמוד בדרישות הביצועים המפורטות ב-CDD של Android 11 בקטע 2.2.7.4

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

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

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

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

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

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

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

2.3.1. חומרה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.2. מולטימדיה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.3. תוכנות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [8.3/T-1-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 (AOSP) ב-upstream מתקיימים הדרישות האלה באמצעות ההטמעה של Trusty, אבל יש גם אפשרויות חלופיות: פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת של בידוד תקין שמבוסס על hypervisor, שעבר בדיקה על ידי צד שלישי.
  • [9.11/T-0-3] חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק אם הוא מצליח, לאפשר שימוש במפתחות שמקושרים לאימות. חובה לאחסן את פרטי הכניסה של מסך הנעילה באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. בפרויקט הקוד הפתוח של Android תוכלו למצוא את שכבת האובייקטים המצומצמים לחומרה (HAL) של Gatekeeper ו-Trusty, שאפשר להשתמש בהם כדי לעמוד בדרישות האלה.
  • [9.11/T-0-4] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה לאימות מוגן על ידי חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה לאימות במספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת מהדרכים לעמוד בדרישות האלה היא לשתף את אותו מפתח אימות, אלא אם מיוצרות לפחות 100,000 יחידות של מק"ט נתון. אם מיוצרות יותר מ-100,000 יחידות של מק"ט מסוים, יכול להיות שייעשה שימוש במפתח שונה לכל 100,000 יחידות.
  • [9/T-0-1] חובה להצהיר על התכונה 'android.hardware.security.model.compatible'.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.1. חומרה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.2. מולטימדיה

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

2.4.3. תוכנות

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.5. מודל אבטחה

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

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

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

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

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

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

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

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

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

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

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

  • [7.3.4/A-2-1] חייב להיות מסוגל לדווח על אירועים עד תדירות של לפחות 100Hz.
  • [7.3.4/A-2-3] חייב להיות מסוגל למדוד שינויים בכיוון עד 250 מעלות לשנייה.
  • [7.3.4/A-SR-1] מומלץ מאוד להגדיר את טווח המדידה של הגירוסקופ ל-‎+/-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-1] מומלץ מאוד לתמוך בפרופיל גישה להודעות (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-1] מומלץ מאוד לא לסובב את התצוגה המקדימה של המצלמה או להציג אותה במראה אופקית.
  • [7.5.5/A-SR-1] מומלץ מאוד שהצילום יהיה כך שהמימד הארוך של המצלמה יהיה בקו ישר עם האופק.
  • [7.5/A-SR-2] מומלץ מאוד שהרזולוציה שלהן תהיה לפחות 1.3 מגה-פיקסלים.
  • צריכה להיות להם חומרה עם מיקוד קבוע או חומרה עם EDOF (עומק שדה מורחב).
  • צריכה להיות תמיכה במסגרת הסנכרון של Android.
  • יכול להיות שהמיקוד האוטומטי של החומרה או התוכנה מוטמעים במנהל המצלמה.

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

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

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

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

  • [7.6.1/A-SR-1] מומלץ מאוד לצמצם את התקורה של הקלט/פלט (I/O) בפעולות שמבוצעות באחסון החיצוני, למשל באמצעות 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-1] H.265 HEVC

2.5.3. תוכנות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.5. מודל אבטחה

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

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

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

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

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

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

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

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

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

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

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

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

2.6.1. חומרה

ג'ירוסקופ

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

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

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

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

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

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

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

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

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

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

2.6.2. מודל אבטחה

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

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

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

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

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

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

2.6.2. תוכנות

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

3. תוכנות

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

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

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

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

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

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

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

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

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

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

    עם זאת, הם:

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

3.1.1. תוספים ל-Android

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

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

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

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

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

3.1.2. ספריית Android

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

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

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

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

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

3.2.1. הרשאות

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

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

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

  • [C-0-1] כדי לספק ערכים עקביים ומשמעותיים בכל הטמעות המכשירים, בטבלה הבאה מפורטות הגבלות נוספות על הפורמטים של הערכים האלה, שאליהם הטמעות המכשירים חייבות לעמוד.
פרמטר פרטים
VERSION.RELEASE הגרסה של מערכת Android שפועלת כרגע, בפורמט קריא לבני אדם. השדה הזה חייב לכלול אחד מערכי המחרוזות שמוגדרים בקטע מחרוזות גרסאות מותרות ל-Android 12.
VERSION.SDK הגרסה של מערכת Android שפועלת כרגע, בפורמט שגלוי לקוד של אפליקציות של צד שלישי. לגבי Android 12, בשדה הזה חייב להופיע הערך השלם 12_INT.
VERSION.SDK_INT הגרסה של מערכת Android שפועלת כרגע, בפורמט שגלוי לקוד של אפליקציות של צד שלישי. לגבי Android 12, בשדה הזה חייב להופיע הערך השלם 12_INT.
VERSION.INCREMENTAL ערך שנבחר על ידי מי שמטמיע את המכשיר, שמציין את גרסת ה-build הספציפית של מערכת Android שפועלת כרגע, בפורמט שקריא לבני אדם. אסור להשתמש שוב בערך הזה לגרסאות build שונות שזמינות למשתמשי קצה. השימוש הנפוץ בשדה הזה הוא לציין את מספר ה-build או את מזהה השינוי במערכת בקרת הגרסאות ששימשו ליצירת ה-build. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט שאפשר להדפיס, ולהתאים לביטוי הרגולרי ‎^[^ :\/~]+$‎.
משחקי לוח ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את החומרה הפנימית הספציפית שבה המכשיר משתמש, בפורמט שקריא לבני אדם. אפשר להשתמש בשדה הזה כדי לציין את הגרסה הספציפית של הלוח שמפעיל את המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי ‎“^[a-zA-Z0-9_-]+$‎”.
BRAND ערך שמשקף את שם המותג שמשויך למכשיר כפי שהוא ידוע למשתמשי הקצה. חייב להיות בפורמט שאפשר לקרוא אותו, וצריך לייצג את היצרן של המכשיר או את מותג החברה שדרכו המכשיר משווק. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי ‎“^[a-zA-Z0-9_-]+$‎”.
SUPPORTED_ABIS השם של קבוצת ההוראות (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי.
SUPPORTED_32_BIT_ABIS השם של קבוצת ההוראות (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי.
SUPPORTED_64_BIT_ABIS השם של קבוצת ההוראות השנייה (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי.
CPU_ABI השם של קבוצת ההוראות (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי.
CPU_ABI2 השם של קבוצת ההוראות השנייה (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי.
מכשיר ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם הפיתוח או שם הקוד שמזהה את ההגדרה של תכונות החומרה ואת העיצוב התעשייתי של המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד בתור ASCII של 7 ביט ולהתאים לביטוי הרגולרי '^[a-zA-Z0-9_-]+$'. אסור לשנות את שם המכשיר במהלך משך החיים של המוצר.
FINGERPRINT מחרוזת שמזהה באופן ייחודי את ה-build הזה. הוא אמור להיות קריא לאנשים באופן סביר. היא חייבת לפעול לפי התבנית הבאה:

$(BRAND)/$(PRODUCT)/
    $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

לדוגמה:

acme/myproduct/
    mydevice:12/LMYXX/3359:userdebug/test-keys

האצבעית אסור שתכלול תווים של רווח לבן. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט.
חומרה שם החומרה (משורת הפקודה של הליבה או מ-/proc). הוא צריך להיות קריא באופן סביר לבני אדם. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי ‎^[a-zA-Z0-9_-]+$‎.
מארח מחרוזת שמזהה באופן ייחודי את המארח שבו נוצר ה-build, בפורמט שקריא לבני אדם. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
מזהה מזהה שנבחר על ידי מי שמטמיע את המכשיר כדי להפנות למהדורה ספציפית, בפורמט קריא לבני אדם. השדה הזה יכול להיות זהה ל-android.os.Build.VERSION.INCREMENTAL, אבל צריך להיות לו ערך בעל משמעות מספקת כדי שמשתמשי הקצה יוכלו להבחין בין גרסאות build של תוכנה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי ‎^[a-zA-Z0-9._-]+$‎.
יצרן השם המסחרי של יצרן הציוד המקורי (OEM) של המוצר. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד האיסור להגדיר אותו כ-null או כמחרוזת ריקה (""). אסור לשנות את השדה הזה במהלך מחזור החיים של המוצר.
SOC_MANUFACTURER השם המסחרי של היצרן של מערכת ה-SOC הראשית שמשמשת במוצר. במכשירים עם אותו יצרן של SoC צריך להשתמש באותו ערך קבוע. יש לפנות ליצרן ה-SOC כדי לקבל את הקבוע הנכון לשימוש. הערך בשדה הזה חייב להיות ניתן לקידוד בתור ASCII של 7 ביט, חייב להתאים לביטוי הרגולרי ‎"^([0-9A-Za-z ]+)", אסור שיתחיל או יסתיים ברווחים ואסור שיהיה שווה ל-'unknown'. השדה הזה אסור שישתנה במהלך משך החיים של המוצר.
SOC_MODEL שם הדגם של המערכת הראשית על שבב (SoC) שמשמשת במוצר. במכשירים עם אותו מודל SOC צריך להשתמש באותו ערך קבוע. יש לפנות ליצרן ה-SOC כדי לקבל את הקבוע הנכון לשימוש. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי ‎“^([0-9A-Za-z ._/+-]+)$‎”, אסור שהוא יתחיל או יסתיים במרווחים אסור שהוא יהיה שווה ל-'unknown'. השדה הזה אסור שישתנה במהלך משך החיים של המוצר.
דגם ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם המכשיר כפי שהוא ידוע למשתמש הקצה. השם הזה צריך להיות זהה לשם שתחתיו המכשיר משווק ונמכר למשתמשי הקצה. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או מחרוזת ריקה (""). אסור לשנות את השדה הזה במהלך מחזור החיים של המוצר.
מוצר ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם הפיתוח או שם הקוד של המוצר הספציפי (מק"ט), שחובה שיהיה ייחודי באותו מותג. חייב להיות קריא לבני אדם, אבל לא בהכרח מיועד לצפייה על ידי משתמשי קצה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט, ולהתאים לביטוי הרגולרי '^‎[a-zA-Z0-9_-]+$‎'. אסור לשנות את שם המוצר במהלך כל משך החיים שלו.
ODM_SKU ערך אופציונלי שנבחר על ידי מי שמטמיע את המכשיר, שמכיל מק"ט (מספר קטלוגי) המשמש למעקב אחרי הגדרות ספציפיות של המכשיר, למשל ציוד היקפי כלשהו שכלול במכשיר כשהוא נמכר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי ^([0-9A-Za-z.,_-]+)$.
SERIAL חובה להחזיר את הערך 'UNKNOWN'.
תגים רשימה של תגים מופרדים בפסיקים שנבחרו על ידי מי שמטמיע את המכשיר, שמבדילה עוד יותר את ה-build. חובה שאפשר יהיה לקודד את התגים כ-ASCII של 7 ביט, שתהיה התאמה לביטוי הרגולרי ‎“^[a-zA-Z0-9._-]+‎” ושיהיו להם אחד מהערכים התואמים לשלושת הגדרות החתימה הטיפוסיות של פלטפורמת Android: release-keys, ‏ dev-keys ו-test-keys.
שעה ערך שמייצג את חותמת הזמן של מועד ה-build.
סוג ערך שנבחר על ידי מי שמטמיע את המכשיר, ומציין את הגדרת סביבת זמן הריצה של ה-build. השדה הזה חייב לכלול אחד מהערכים שתואמים לשלושת ההגדרות הנפוצות של Android בסביבת זמן ריצה: user,‏ userdebug או eng.
משתמש שם או מזהה משתמש של המשתמש (או המשתמש האוטומטי) שיצר את ה-build. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
SECURITY_PATCH ערך שמציין את רמת תיקון האבטחה של גרסה זמינה ל-build. חובה לציין שה-build לא חשוף בשום צורה לאף אחת מהבעיות המתוארות בעדכון האבטחה הציבורי הייעודי של Android. הוא חייב להיות בפורמט [YYYY-MM-DD] ותואם למחרוזת מוגדרת שמופיעה בעדכון האבטחה הציבורי של Android או ב עדכון האבטחה של Android, לדוגמה '2015-11-01'.
BASE_OS ערך שמייצג את הפרמטר FINGERPRINT של ה-build, שהוא זהה ל-build הזה מלבד התיקונים שסופקו בעדכון האבטחה הציבורי של Android. חובה לדווח על הערך הנכון, ואם לא קיים build כזה, צריך לדווח על מחרוזת ריקה ("").
BOOTLOADER ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את גרסת האתחול הפנימית הספציפית שמשמשת במכשיר, בפורמט שקריא לבני אדם. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי ‎^[a-zA-Z0-9._-]+$‎.
getRadioVersion() הערך חייב להיות (או להחזיר) ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את גרסת הרדיו/המודם הפנימית הספציפית שמשמשת במכשיר, בפורמט שקריא לבני אדם. אם למכשיר אין רדיו/מודם פנימיים, חובה להחזיר את הערך NULL. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי ‎“^[a-zA-Z0-9._-,]+$”.
getSerial() חובה (להיות או להחזיר) מספר סידורי של חומרה, שחייב להיות זמין וייחודי במכשירים עם אותו דגם ויצרן. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי ‎^[a-zA-Z0-9._-,]+$‎.

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-0-4] חובה לנסות לאמת מסנני Intent על ידי ביצוע שלבי האימות שמוגדרים במפרט של Digital Asset Links, כפי שהם מיושמים על ידי מנהל החבילות ב-Android Open Source Project (פרויקט Android בקוד פתוח) במקור.
  • [C-0-5] חובה לנסות לאמת את מסנני הכוונה במהלך התקנת האפליקציה ולהגדיר את כל מסנני הכוונה של URI שאומתו כמטפלי אפליקציה שמוגדרים כברירת מחדל למזהי ה-URI שלהם.
  • יכולים להגדיר מסנני כוונה ספציפיים של URI כמפעילי אפליקציה שמוגדרים כברירת מחדל למזהי ה-URI שלהם, אם הם אומתו בהצלחה אבל מסנני URI אחרים לא עברו את תהליך האימות. אם הטמעה במכשיר עושה זאת, היא חייבת לספק למשתמש את השינויים המתאימים לדפוס לכל URI בתפריט ההגדרות.
  • חובה לספק למשתמש אמצעי בקרה לכל אפליקציה של קישורי אפליקציות בהגדרות, באופן הבא:
    • [C-0-6] המשתמש חייב להיות מסוגל לשנות באופן מקיף את ברירת המחדל של התנהגות הקישורים לאפליקציה, כך שהיא תהיה: תמיד פתיחה, תמיד שאלה או אף פעם לא פתיחה. המדיניות הזו חייבת לחול באופן שווה על כל מסנני הכוונה של URI מועמדים.
    • [C-0-7] המשתמש חייב להיות מסוגל לראות רשימה של מסנני הכוונה ל-URI שעומדים בקריטריונים.
    • הטמעת המכשיר עשויה לספק למשתמש את היכולת לשנות את ההגדרות של מסנני הכוונה ספציפיים של URI שהתקבלו ואשר אומתו, על בסיס מסנן כוונה לכל אחד מהם.
    • [C-0-8] אם ההטמעה במכשיר מאפשרת לחלק ממסנני הכוונה של כתובות URI מועמדות לעבור אימות, בעוד שחלק אחר לא עובר, ההטמעה במכשיר חייבת לספק למשתמשים את היכולת להציג ולשנות את ההגדרות של מסנני הכוונה הספציפיים של כתובות URI מועמדות.
3.2.3.3. מרחבי שמות של כוונות
  • [C-0-1] אסור שרכיבי הטמעה של המכשיר יכללו רכיב Android שמתייחס לתבניות חדשות של כוונות או כוונות שידור באמצעות ACTION,‏ CATEGORY או מחרוזת מפתח אחרת במרחב השמות android.* או com.android.*.
  • [C-0-2] אסור למטמיעים של מכשירים לכלול רכיבי Android שמכבדים דפוסי כוונה חדשים או דפוסי כוונה לשידור באמצעות ACTION,‏ CATEGORY או מחרוזת מפתח אחרת במרחב החבילה ששייך לארגון אחר.
  • [C-0-3] אסור למטמיעים של מכשירים לשנות או להרחיב אף אחד מדפוסי הכוונה שמפורטים בסעיף 3.2.3.1.
  • הטמעות במכשירים יכולות לכלול דפוסי כוונה שמשתמשים במרחבי שמות שמשויכים בבירור לארגון שלהם. האיסור הזה דומה לאיסור שצוין לגבי כיתות בשפת Java בסעיף 3.6.
3.2.3.4. כוונות לשידור

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

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

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

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

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

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

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

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

אם הטמעות של מכשירים מדווחות על 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, הן:

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

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

  • [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 ומאפשרות גישה לפונקציונליות באפליקציות של צד שלישי, הן:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3.1. ממשקי Application Binary Interface

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

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

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

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

  • [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 תהיה תמיכה ב-ABIs נוספים.

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

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

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

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

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

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

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

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

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

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

3.4.1. תאימות ל-WebView

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כלומר:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-5-1] חובה לפעול בהתאם לשיטת ה-API NotificationChannel.setShowBadge(). במילים אחרות, אם הערך מוגדר כ-true, מוצגת סמנטיקה חזותית שמשויכת לסמל האפליקציה. אם הערך מוגדר כ-false בכל ערוצי ההתראות של האפליקציה, לא מוצגת סמנטיקה חזותית של תגים בסמל האפליקציה.
  • יכולים לשנות את התגים של סמל האפליקציה לסכמת תגים קניינית משלהם, אם אפליקציות של צד שלישי מציינות תמיכה בסכמת התגים הקניינית באמצעות ממשקי API קנייניים, אבל צריכים להשתמש במשאבים ובערכים שסופקו באמצעות ממשקי ה-API של תגי ההתראות שמתוארים בSDK, כמו ה-API של Notification.Builder.setNumber() ושל Notification.Builder.setBadgeIconType().

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

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

3.8.3. התראות

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

3.8.3.1. הצגת ההתראות

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

  • [C-1-1] חובה לתמוך בהתראות שמשתמשות בתכונות חומרה, כפי שמתואר במסמכי התיעוד של ה-SDK, ובמידת האפשר עם חומרת ההטמעה של המכשיר. לדוגמה, אם הטמעת המכשיר כוללת ויברטור, חובה להטמיע בצורה נכונה את ממשקי ה-API של הרטט. אם הטמעה של מכשיר חסרה חומרה, צריך להטמיע את ממשקי ה-API התואמים כ-no-ops. התנהגות זו מפורטת בהרחבה בקטע 7.
  • [C-1-2] חובה להציג בצורה נכונה את כל המשאבים (סמלים, קובצי אנימציה וכו') שסופקו ב-API או במדריך הסגנון של הסמלים בסרגל הסטטוס או בסרגל המערכת, למרות שאפשר לספק חוויית משתמש חלופית להתראות מזו שסופקה בהטמעת העזר של Android Open Source.
  • [C-1-3] חובה לפעול בהתאם להתנהגויות המתוארות בממשקי ה-API ולהטמיע אותן בצורה תקינה כדי לעדכן, להסיר ולקבץ התראות.
  • [C-1-4] חובה לספק את כל ההתנהגות של ה-API NotificationChannel שמתועדת ב-SDK.
  • [C-1-5] חובה לספק למשתמש אפשרות לחסום ולשנות התראה מסוימת של אפליקציה של צד שלישי לכל ערוץ וחבילת אפליקציות.
  • [C-1-6] חובה גם לספק למשתמש אפשרות להציג ערוצי התראות שנמחקו.
  • [C-1-7] חובה להציג בצורה נכונה את כל המשאבים (תמונות, סטיקרים, סמלים וכו') שסופקו באמצעות Notification.MessagingStyle לצד טקסט ההתראה, ללא אינטראקציה נוספת של המשתמש. לדוגמה, חובה להציג את כל המשאבים, כולל הסמלים שסופקו באמצעות android.app.Person, בשיחה קבוצתית שמוגדרת באמצעות setGroupConversation.
  • [C-SR-1] מומלץ מאוד להציג באופן אוטומטי למשתמש אפשרות לחסום התראה של אפליקציית צד שלישי מסוימת לכל ערוץ ולרמת חבילת האפליקציות, אחרי שהמשתמש סוגר את ההתראה הזו כמה פעמים.
  • [C-SR-2] מומלץ מאוד לספק למשתמש אפשרות לשלוט בהתראות שנחשפות לאפליקציות שקיבלו את ההרשאה 'האזנה להתראות'. רמת הפירוט חייבת להיות כזו שמאפשרת למשתמש לקבוע לכל מאזין התראות כזה אילו סוגי התראות יתקבלו דרכו. הסוגים חייבים לכלול התראות מסוג 'שיחות', 'התראות', 'שקטות' ו'התראות פעילות חשובות'.
  • [C-SR-3] מומלץ מאוד לספק למשתמשים אפשרות לציין אפליקציות שלא יוצגו להן התראות מכל מאזין התראות ספציפי.
  • צריכה להיות תמיכה בהתראות עשירות.
  • צריך להציג חלק מההתראות בעדיפות גבוהה יותר כ'התראות 'שימו לב''.
  • צריכה להיות למשתמש אפשרות להשהות התראות.
  • יכולים לנהל רק את החשיפה ואת התזמון של הזמנים שבהם אפליקציות צד שלישי יכולות להודיע למשתמשים על אירועים משמעותיים, כדי לצמצם בעיות בטיחות כמו הסחת דעת של הנהג.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.4. ממשקי Assist API

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

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

  • [C-2-1] חובה לציין בבירור למשתמש הקצה מתי מתבצע שיתוף של ההקשר, באחת מהדרכים הבאות:
    • בכל פעם שאפליקציית העזרה ניגשת להקשר, מוצגת תאורה לבנה סביב שולי המסך שתואמת או עולה על משך הזמן והבהירות של ההטמעה ב-Android Open Source Project.
    • באפליקציית העזרה המותקנת מראש, לספק למשתמש אפשרות להיכנס לתפריט ההגדרות של הקלט הקולי והאפליקציה לסיוע תוך פחות משתי פעולות ניווט, ולשתף את ההקשר רק כשהמשתמש מפעיל את אפליקציית העזרה באופן מפורש באמצעות מילה מפתח או הקשה על מקש ניווט של אפליקציית העזרה.
  • [C-2-2] האינטראקציה הייעודית להפעלת אפליקציית העזרה כפי שמתואר בקטע 7.2.3 חייבת להפעיל את אפליקציית העזרה שבחר המשתמש, כלומר האפליקציה שמטמיעה את VoiceInteractionService, או פעילות שמטפלת בכוונה ACTION_ASSIST.

3.8.5. התראות והודעות קצרות

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

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

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

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

3.8.6. עיצובים

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

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

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

  • [C-1-1] אסור לשנות אף אחד ממאפייני העיצוב של Holo שנחשפים לאפליקציות.
  • [C-1-2] חובה לתמוך במשפחת העיצובים 'Material' אסור לשנות אף אחד ממאפייני העיצוב של Material או את הנכסים שלהם שגלויים לאפליקציות.
  • [C-1-3] חובה להגדיר את משפחת הגופנים 'sans-serif' ל-Roboto גרסה 2.x בשפות שבהן Roboto תומכת, או לספק למשתמש אפשרות לשנות את הגופן שמשמש את משפחת הגופנים 'sans-serif' ל-Roboto גרסה 2.x בשפות שבהן Roboto תומכת.

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

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

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

  • [C-2-1] חובה להשתמש בצבע לבן בסמלי סטטוס המערכת (כמו עוצמת האות ורמת הסוללה) ובהתראות שהמערכת מנפיקה, אלא אם הסמל מציין סטטוס בעייתי או שאפליקציה מבקשת סטטוס קל באמצעות הדגל WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.
  • [C-2-2] כשאפליקציה מבקשת סרגל סטטוס בהיר, יש לשנות את הצבע של סמלי הסטטוס של המערכת לשחור (פרטים נוספים זמינים במאמר R.style) בהטמעות של מכשירי Android.

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

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

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

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

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

  • [C-1-1] חובה לדווח על דגל התכונה של הפלטפורמה android.software.live_wallpaper.

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

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

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

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

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

3.8.9. ניהול קלט

ב-Android יש תמיכה בניהול קלט ובתמיכה בעורכי שיטות קלט של צד שלישי.

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

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

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

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

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

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

3.8.12. מיקום

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

3.8.13. Unicode וגופן

מערכת Android כוללת תמיכה בתווי האמוג'י שמוגדרים ב-Unicode 10.0.

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

  • [C-1-1] חייב להיות מסוגל להציג את תווי האמוג'י האלה כגליף צבעוני.
  • [C-1-2] חובה לכלול תמיכה ב:
    • גופן Roboto 2 בעוביים שונים – sans-serif-thin, ‏ sans-serif-light,‏ sans-serif-medium, ‏ sans-serif-black, ‏ sans-serif-condensed,‏ sans-serif-condensed-light – בשפות הזמינות במכשיר.
    • כיסוי מלא של Unicode 7.0 של לטינית, יוונית וקירילית, כולל הטווחים A,‏ B,‏ C ו-D של לטינית מורחבת, וכל הגליפים בבלוק של סמלי המטבעות ב-Unicode 7.0.
  • [C-1-3] אסור להסיר או לשנות את קובץ NotoColorEmoji.tff בתמונת המערכת. (אפשר להוסיף גופן אמוג'י חדש כדי לשנות את האמוג'י בקובץ NotoColorEmoji.tff).
  • צריכה לתמוך בגווני עור ובאמוג'י של משפחות מגוונות, כפי שמפורט בדוח הטכני מס' 51 של Unicode.

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

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

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

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

  • [C-2-1] חובה להציג טקסט בגופן שתומך ב-Unicode כברירת מחדל. אסור להגדיר גופן שלא תומך ב-Unicode כברירת מחדל, אלא אם המשתמש בוחר בו בבורר השפות.
  • [C-2-2] חובה לתמוך בגופן Unicode ובגופן שאינו תואם ל-Unicode, אם יש תמיכה בגופן שאינו תואם ל-Unicode במכשיר. אסור שגופן שלא תואם ל-Unicode יסיר או יחליף את הגופן של Unicode.
  • [C-2-3] חובה להציג טקסט בגופן שלא תואם ל-Unicode רק אם צוין קוד שפה עם קוד סקריפט Qaag (למשל my-Qaag). אי אפשר להשתמש בקודים אחרים של שפות או אזורים לפי תקן ISO (מקצים, לא מקצים או שמורים) כדי להפנות לגופן לא תואם Unicode במיאנמר. מפתחי אפליקציות ומחברי דפי אינטרנט יכולים לציין את my-Qaag כקוד השפה הייעודי, כמו בכל שפה אחרת.

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

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

  • [C-1-1] חובה להטמיע מצבי ריבוי חלונות כאלה בהתאם להתנהגויות האפליקציה ולממשקי ה-API שמתוארים במסמכי התיעוד של Android SDK בנושא תמיכה במצב ריבוי חלונות, ותואמים לדרישות הבאות:
  • [C-1-2] חובה לכבד את android:resizeableActivity שהוגדר על ידי אפליקציה בקובץ AndroidManifest.xml, כפי שמתואר בSDK הזה.
  • [C-1-3] אסור להציע מצב מסך מפוצל או מצב פורמט חופשי אם גובה המסך קטן מ-440dp ורוחבו קטן מ-440dp.
  • [C-1-4] אסור לשנות את הגודל של פעילות לגודל קטן מ-220dp במצבים של חלונות מרובים, מלבד 'תמונה בתוך תמונה'.
  • הטמעות של מכשירים עם גודל מסך xlarge אמורות לתמוך במצב 'טקסט חופשי'.

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

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

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

  • [C-3-1] חובה להפעיל פעילויות במצב 'תמונה בתוך תמונה' עם חלונות מרובים כשהאפליקציה:

  • [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-5] חובה לרשום את אפליקציית ה-DPC כאפליקציית הבעלים של המכשיר אם המכשיר מצהיר על תמיכה בתקשורת מטווח קצר (NFC) באמצעות דגל התכונה android.hardware.nfc ומקבל הודעת NFC שמכילה רשומה עם סוג MIME‏ MIME_TYPE_PROVISIONING_NFC.
      • [C-1-8] חובה לשלוח את הכוונה ACTION_GET_PROVISIONING_MODE אחרי שההקצאה של הבעלים של המכשיר מופעלת, כדי שאפליקציית ה-DPC תוכל לבחור אם להפוך לבעלים של המכשיר או לבעלים של הפרופיל, אלא אם ניתן לקבוע מההקשר שיש רק אפשרות תקפה אחת (למשל, להקצאה שמבוססת על NFC שבה לא נתמכת הקצאה לבעלים של פרופיל).
      • [C-1-9] חובה לשלוח את הכוונה ACTION_ADMIN_POLICY_COMPLIANCE לאפליקציית הבעלים של המכשיר אם הבעלים של המכשיר נוצר במהלך ההקצאה, ללא קשר לשיטת ההקצאה שבה נעשה שימוש. המשתמש לא יכול להמשיך באשף ההגדרה עד שהאפליקציה 'בעלי המכשיר' מסתיימת.
    • כשהטמעת המכשיר כוללת נתוני משתמשים, היא:
      • [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] תהליך הקצאת הפרופיל המנוהל (התהליך שמופעל על ידי ה-DPC באמצעות android.app.action.PROVISION_MANAGED_PROFILE או על ידי הפלטפורמה), מסך ההסכמה וחוויית המשתמש חייבים להיות תואמים ליישום AOSP.

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

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

  • [C-1-4] חובה להפעיל את הטיפולן של ה-intent‏ ACTION_PROVISIONING_SUCCESSFUL בפרופיל העבודה אם הוגדר בעלים של פרופיל כשה-intent‏ android.app.action.PROVISION_MANAGED_PROFILE הפעיל את ההקצאה, וה-DPC הטמיע את הטיפולן.

  • [C-1-5] חובה לשלוח את השידור ACTION_PROFILE_PROVISIONING_COMPLETE ל-DPC של פרופיל העבודה כשההקצאה מופעלת על ידי הכוונה android.app.action.PROVISION_MANAGED_PROFILE.

  • [C-1-6] חובה לשלוח את הכוונה ACTION_GET_PROVISIONING_MODE אחרי שההקצאה של הבעלים של הפרופיל מופעלת, כדי שאפליקציית ה-DPC תוכל לבחור אם להפוך לבעלים של המכשיר או לבעלים של הפרופיל, מלבד במקרים שבהם ההקצאה מופעלת על ידי הכוונה android.app.action.PROVISION_MANAGED_PROFILE.

  • [C-1-7] חובה לשלוח את הכוונה ACTION_ADMIN_POLICY_COMPLIANCE לפרופיל העבודה כשבעל פרופיל מוגדר במהלך ההקצאה, ללא קשר לשיטת ההקצאה שבה נעשה שימוש, אלא אם ההקצאה מופעלת על ידי הכוונה android.app.action.PROVISION_MANAGED_PROFILE. המשתמש לא יכול להמשיך באשף ההגדרה עד שהאפליקציה של הבעלים של הפרופיל תסתיים.

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

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

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

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

אם הטמעות במכשיר מכריזות על android.software.device_admin ומספקות למשתמש במכשיר אפשרות להוסיף משתמשים משניים, הן:

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

3.10. נגישות

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

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

  • [C-1-1] חובה לספק הטמעה של מסגרת הנגישות של Android כפי שמתואר במסמכי התיעוד של ממשקי ה-API לנגישות ב-SDK.
  • [C-1-2] חובה ליצור אירועי נגישות ולשלוח את הערך המתאים של AccessibilityEvent לכל ההטמעות הרשמות של AccessibilityService, כפי שמתואר ב-SDK.
  • [C-1-4] חובה לספק למשתמש אמצעי בקרה על שירותי הנגישות שמצהירים על AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. לתשומת ליבכם: בהטמעות במכשירים עם סרגל ניווט של מערכת, צריך לאפשר למשתמש להשתמש בלחצן בסרגל הניווט של המערכת כדי לשלוט בשירותים האלה.

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

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

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

Android כולל ממשקי API שמאפשרים לאפליקציות להשתמש בשירותי Text-to-Speech ‏(TTS), ומאפשרים לספקי שירותים לספק הטמעות של שירותי TTS.

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

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

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

3.12. TV Input Framework

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

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

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

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

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

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

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

3.14. ממשק המשתמש של המדיה

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

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

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

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

  • [C-1-5] MUST consider double tap of KEYCODE_HEADSETHOOK or KEYCODE_MEDIA_PLAY_PAUSE as KEYCODE_MEDIA_NEXT for MediaSession.Callback#onMediaButtonEvent.

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

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

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

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

    • [C-1-5] חובה לספק למשתמש אפשרות להציג ולמחוק אפליקציות מיידיות שנשמרו במטמון באופן מקומי לכל חבילת אפליקציות בנפרד.
    • [C-1-6] חובה לספק התראה קבועה למשתמשים שאפשר לכווץ בזמן שאפליקציית Instant פועלת בחזית. ההודעה הזו חייבת לכלול את ההודעה שאפליקציות מיידיות לא דורשות התקנה, ולספק למשתמש אמצעי ניווט שמפנה אותו למסך פרטי האפליקציה בהגדרות. באפליקציות מיידיות שמופעלות באמצעות כוונות אינטרנט, כפי שהן מוגדרות באמצעות כוונה עם פעולה Intent.ACTION_VIEW וסכימת http או https, צריכה להיות אפשרות נוספת למשתמש שלא להפעיל את האפליקציה המיידית ולהפעיל את הקישור המשויך באמצעות דפדפן האינטרנט המוגדר, אם יש דפדפן זמין במכשיר.
    • [C-1-7] חובה לאפשר גישה לאפליקציות מיידיות שפועלות דרך התכונה 'מהזמן האחרון', אם התכונה 'מהזמן האחרון' זמינה במכשיר.

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

3.16. התאמת מכשירים נלווים

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

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

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

3.17. אפליקציות כבדות

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

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

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

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

3.18. אנשי הקשר

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

RawContacts "משויכים" או "מאוחסנים" בחשבון כשהעמודות ACCOUNT_NAME ו-ACCOUNT_TYPE של אנשי הקשר הגולמיים תואמות לשדות Account.name ו-Account.type של החשבון.

חשבון מקומי שמוגדר כברירת מחדל: חשבון לאנשי קשר גולמיים שנשמרים רק במכשיר ולא משויכים לחשבון ב-AccountManager. אנשי הקשר האלה נוצרים עם ערכים של null בעמודות ACCOUNT_NAME ו-ACCOUNT_TYPE.

חשבון מקומי בהתאמה אישית: חשבון של אנשי קשר גולמיים שנשמרים רק במכשיר ולא משויכים לחשבון ב-AccountManager, שנוצרים עם ערך אחד לפחות שאינו null בעמודות ACCOUNT_NAME ו-ACCOUNT_TYPE.

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

  • [C-SR-1] מומלץ מאוד לא ליצור חשבונות מקומיים בהתאמה אישית.

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

  • [C-1-1] ה-ACCOUNT_NAME של החשבון המקומי המותאם אישית חייב להוחזר על ידי ContactsContract.RawContacts.getLocalAccountName
  • [C-1-2] ה-ACCOUNT_TYPE של החשבון המקומי המותאם אישית חייב להוחזר על ידי ContactsContract.RawContacts.getLocalAccountType
  • [C-1-3] חובה להוסיף אנשי קשר גולמיים שמוטמעים על ידי אפליקציות צד שלישי באמצעות החשבון המקומי שמוגדר כברירת מחדל (כלומר, על ידי הגדרת ערכים null עבור ACCOUNT_NAME ו-ACCOUNT_TYPE) לחשבון המקומי המותאם אישית.
  • [C-1-4] אסור להסיר אנשי קשר גולמיים שהוכנסו לחשבון המקומי המותאם אישית כשמוסיפים או מסירים חשבונות.
  • [C-1-5] פעולות מחיקה שמבוצעות בחשבון המקומי המותאם אישית חייבות להוביל למחיקה מיידית של אנשי הקשר הגולמיים (כאילו הפרמטר CALLER_IS_SYNCADAPTER הוגדר כ-true), גם אם הפרמטר CALLER\_IS\_SYNCADAPTER הוגדר כ-false או לא צוין.

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

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

  • [C-0-1] חייבת להיות אפשרות להתקין ולהריץ קובצי ‎.apk של Android שנוצרו באמצעות הכלי ‎aapt שכלול בAndroid SDK הרשמי.
    • מאחר שהדרישה שלמעלה עשויה להיות מאתגרת, מומלץ להשתמש במערכת ניהול החבילות של הטמעת העזר של AOSP בהטמעות במכשירים.

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

  • [C-0-2] חובה לתמוך באימות של קובצי ‎".apk" באמצעות APK Signature Scheme v3,‏ APK Signature Scheme v2 וחתימת JAR.
  • [C-0-3] אסור להרחיב את הפורמטים של ‎.apk,‏ Android Manifest,‏ קוד בינארי של Dalvik או קוד בינארי של RenderScript באופן שימנע את ההתקנה וההפעלה הנכונים של הקבצים האלה במכשירים תואמים אחרים.

  • [C-0-4] אסור לאפשר לאפליקציות אחרות מלבד 'המתקין הרשום' הנוכחי של החבילה להסיר את האפליקציה בשקט, ללא אישור מהמשתמש, כפי שמתואר ב-SDK לגבי ההרשאה DELETE_PACKAGE. החריגים היחידים הם האפליקציה לאימות חבילות המערכת שמטפלת ב-intent‏ PACKAGE_NEEDS_VERIFICATION, והאפליקציה לניהול האחסון שמטפלת ב-intent‏ ACTION_MANAGE_STORAGE.

  • [C-0-5] חובה שתהיה פעילות שמטפלת ב-intent‏ android.settings.MANAGE_UNKNOWN_APP_SOURCES.

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

    • חובה להצהיר על ההרשאה REQUEST_INSTALL_PACKAGES או להגדיר את android:targetSdkVersion ל-24 או פחות.
    • המשתמש חייב להעניק הרשאה להתקנת אפליקציות ממקורות לא מוכרים.

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

  • [C-0-7] חובה להציג למשתמש תיבת דו-שיח עם מחרוזת האזהרה שסופקה באמצעות ממשק ה-API של המערכת PackageManager.setHarmfulAppWarning לפני שמפעילים פעילות באפליקציה שסומנה על ידי אותו ממשק API של המערכת PackageManager.setHarmfulAppWarning כפעילות שעלולה להזיק.

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

  • [C-0-8] חובה להטמיע תמיכה ב-Incremental File System כפי שמתואר כאן.

  • [C-0-9] חובה לתמוך באימות של קובצי APK באמצעות APK Signature Scheme v4.

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

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

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

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

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

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

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

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

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

פרטים נוספים זמינים בקטע 5.1.3. פרטי קודקי האודיו.

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

  • [C-1-1] PCM/WAVE
  • [C-1-2] FLAC
  • [C-1-3] Opus

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

  • [C-3-1] פריימים של אודיו ב-PCM 16 ביט בסדר בייטים מקורי באמצעות ה-API של android.media.MediaCodec.

5.1.2. פענוח אודיו

פרטים נוספים זמינים בקטע 5.1.3. פרטי קודקי האודיו.

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

  • [C-1-1] MPEG-4 AAC Profile‏ (AAC LC)
  • [C-1-2] MPEG-4 HE AAC Profile‏ (AAC+)
  • [C-1-3] פרופיל MPEG-4 HE AACv2‏ (enhanced AAC+)
  • [C-1-4] AAC ELD‏ (AAC משופר עם זמן השהיה קצר)
  • [C-1-11] xHE-AAC (פרופיל HE AAC מורחב ISO/IEC 23003-3, שכולל את פרופיל הבסיס USAC ופרופיל בקרת טווח דינמי ISO/IEC 23003-4)
  • [C-1-5] FLAC
  • [C-1-6] MP3
  • [C-1-7] MIDI
  • [C-1-8] Vorbis
  • [C-1-9] PCM/WAVE, כולל פורמטים של אודיו ברזולוציה גבוהה עד 24 ביט, תדירות דגימה של 192kHz ו-8 ערוצים. חשוב לזכור שהדרישה הזו היא לצורך פענוח בלבד, ושמותר למכשיר לבצע דגימה לאחור (downsampling) ומייקס לאחור (downmix) במהלך שלב ההפעלה.
  • [C-1-10] Opus

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

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

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

  • [C-3-1] חובה לפרש את המטא-נתונים של עוצמת הקול ושל בקרת עוצמת הקול הדינמית ולהחיל אותם בהתאם לפרופיל בקרת עוצמת הקול הדינמית של MPEG-D DRC ברמה 1.
  • [C-3-2] המפענח חייב לפעול בהתאם להגדרות שהוגדרו באמצעות מפתחות android.media.MediaFormat הבאים: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL ו-KEY_AAC_DRC_EFFECT_TYPE.

מקודדים של פרופילים MPEG-4 AAC,‏ HE AAC ו-HE AACv2:

  • יכול להיות שתהיה תמיכה בשליטה בעוצמת הקול ובטווח הדינמי באמצעות פרופיל הבקרה של טווח הדינמי ISO/IEC 23003-4.

אם יש תמיכה ב-ISO/IEC 23003-4, וגם המטא-נתונים של ISO/IEC 23003-4 וגם המטא-נתונים של ISO/IEC 14496-3 נמצאים בזרם ביטים מפוענח, אז:

  • המטא-נתונים של ISO/IEC 23003-4 יהיו בעלי עדיפות.

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

  • [C-6-1] פריימים של אודיו ב-PCM 16 ביט בסדר בייטים מקורי דרך ה-API של android.media.MediaCodec.

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

פורמט/קודק פרטים סוגי הקבצים או הפורמטים של הקונטיינרים שנתמכים
MPEG-4 AAC Profile
‏(AAC LC)		 תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם תדירויות דגימה רגילות של 8 עד 48kHz.
  • 3GPP‏ (‎.3gp)
  • MPEG-4‏ (‎.mp4,‏ ‎.m4a)
  • AAC גולמי של ADTS (‎.aac, ‏ ADIF לא נתמכים)
  • MPEG-TS‏ (‎.ts, לא ניתן לדלג, פענוח בלבד)
  • Matroska‏ (‎.mkv, פענוח בלבד)
פרופיל MPEG-4 HE AAC‏ (AAC+) תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם תדירויות דגימה רגילות של 16 עד 48kHz.
  • 3GPP‏ (‎.3gp)
  • MPEG-4‏ (‎.mp4,‏ ‎.m4a)
MPEG-4 HE AACv2
פרופיל (enhanced AAC+)		 תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם תדירויות דגימה רגילות של 16 עד 48kHz.
  • 3GPP‏ (‎.3gp)
  • MPEG-4‏ (‎.mp4,‏ ‎.m4a)
AAC ELD (AAC משופר עם זמן אחזור נמוך) תמיכה בתוכן מונו/סטריאו עם תדירויות דגימה רגילות של 16 עד 48kHz.
  • 3GPP‏ (‎.3gp)
  • MPEG-4‏ (‎.mp4,‏ ‎.m4a)
USAC תמיכה בתוכן מונו/סטריאו עם תדירויות דגימה רגילות של 7.35kHz עד 48kHz. MPEG-4‏ (‎.mp4,‏ ‎.m4a)
AMR-NB 4.75 עד 12.2kbps דגימה ב-8kHz 3GPP‏ (‎.3gp)
AMR-WB 9 שיעורים מ-6.60kbit/s עד 23.85kbit/s שנדגמו ב-16kHz, כפי שמוגדר ב- AMR-WB, ‏ Adaptive Multi-Rate – Wideband Speech Codec 3GPP‏ (‎.3gp)
FLAC גם למקודד וגם למפענח: חובה שתהיה תמיכה לפחות במצבים Mono ו-Stereo. חובה שתהיה תמיכה בתדירויות דגימה של עד 192kHz, וברזולוציות של 16 ו-24 ביט. עיבוד נתוני אודיו של FLAC 24 ביט חייב להיות זמין עם הגדרת אודיו של נקודה צפה.
  • FLAC‏ (‎.flac)
  • MPEG-4‏ (‎.mp4,‏ ‎.m4a, ‏ פענוח בלבד)
  • Matroska‏ (‎.mkv, פענוח בלבד)
MP3 מונו/סטריאו 8-320Kbps קבוע (CBR) או קצב העברת נתונים משתנה (VBR)
  • MP3‏ (‎.mp3)
  • MPEG-4‏ (‎.mp4,‏ ‎.m4a, ‏ פענוח בלבד)
  • Matroska‏ (‎.mkv, פענוח בלבד)
MIDI MIDI מסוג 0 ו-1. DLS גרסה 1 ו-2. XMF ו-Mobile XMF. תמיכה בפורמטים של רינגטונים RTTTL/RTX,‏ OTA ו-iMelody
  • סוג 0 ו-1 (‎.mid,‏ ‎.xmf,‏ ‎.mxmf)
  • RTTTL/RTX‏ (‎.rtttl, ‎.rtx)
  • iMelody‏ (‎.imy)
Vorbis
  • Ogg‏ (‎.ogg)
  • MPEG-4‏ (‎.mp4,‏ ‎.m4a, ‏ פענוח בלבד)
  • Matroska‏ (‎.mkv)
  • Webm ‏(‎.webm)
PCM/WAVE קודק PCM חייב לתמוך ב-PCM ליניארי של 16 ביט וב-float של 16 ביט. הכלי לחילוץ קובצי WAVE חייב לתמוך ב-PCM לינאריים של 16 ביט, 24 ביט ו-32 ביט וב-float של 32 ביט (בתדירויות עד למגבלה של החומרה). חובה לתמוך בתדירויות דגימה של 8kHz עד 192kHz. WAVE‏ (‎.wav)
Opus פענוח: תמיכה בתוכן מונו, סטריאו, 5.0 ו-5.1 עם שיעורי דגימה של 8,000,‏ 12,000,‏ 16,000,‏ 24,000 ו-48,000Hz.
קידוד: תמיכה בתוכן מונו וסטריאו עם שיעורי דגימה של 8,000,‏ 12,000,‏ 16,000,‏ 24,000 ו-48,000Hz.
  • Ogg‏ (‎.ogg)
  • MPEG-4‏ (‎.mp4,‏ ‎.m4a, ‏ פענוח בלבד)
  • Matroska‏ (‎.mkv)
  • Webm ‏(‎.webm)

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

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

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

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

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

פורמט/קודק פרטים סוגי קבצים/פורמטים של קובצי מאגר נתמכים
JPEG Base+progressive JPEG‏ (‎.jpg)
GIF GIF ‏(‎.gif)
PNG PNG ‏(‎.png)
BMP BMP ‏(‎.bmp)
WebP WebP ‏(‎.webp)
גולמי ARW‏ (‎.arw), ‏ CR2‏ (‎.cr2), ‏ DNG‏ (‎.dng), ‏ NEF‏ (‎.nef), ‏ NRW‏ (‎.nrw), ‏ ORF‏ (‎.orf),‏ PEF‏ (‎.pef), ‏ RAF‏ (‎.raf), ‏ RW2‏ (‎.rw2), ‏ SRW‏ (‎.srw)
HEIF תמונה, אוסף תמונות, רצף תמונות HEIF‏ (‎.heif), ‏ HEIC‏ (‎.heic)

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

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

  • [SR-1] מומלץ מאוד לתמוך בפורמט צבע RGB888 למצב Surface של הקלט.

  • [C-1-3] חובה לתמוך לפחות באחד מפורמטים של צבע YUV420 8:8:8 שטוח או חצי-שטוח: COLOR_FormatYUV420PackedPlanar (שווה ל-COLOR_FormatYUV420Planar) או COLOR_FormatYUV420PackedSemiPlanar (שווה ל-COLOR_FormatYUV420SemiPlanar). מומלץ מאוד לתמוך בשניהם.

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

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

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

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

  • [C-1-2] מכשירי קידוד ופענוח וידאו חייבים לתמוך בפורמטים גמישים של צבע YUV420 8:8:8 (COLOR_FormatYUV420Flexible) עד CodecCapabilities.

  • [C-1-3] מקודדי וידאו ומפענחי וידאו חייבים לתמוך לפחות באחד מפורמטים צבעיים של YUV420 8:8:8 שטוח או חצי-שטוח: COLOR_FormatYUV420PackedPlanar (שווה ערך ל-COLOR_FormatYUV420Planar) או COLOR_FormatYUV420PackedSemiPlanar (שווה ערך ל-COLOR_FormatYUV420SemiPlanar). מומלץ מאוד לתמוך בשניהם.

  • [SR-1] מומלץ מאוד שמקודדי וידאו ומפענחי וידאו יתמכו לפחות באחד מפורמטים צבעוניים של YUV420 8:8:8 שטוח או חצי-שטוח שעברו אופטימיזציה לחומרה (YV12, ‏ NV12, ‏ NV21 או פורמט מקביל שעובר אופטימיזציה על ידי ספק).

  • [C-1-5] ממירי וידאו שתומכים בפורמט עם עומק סיביות גבוה (9 סיביות ומעלה לכל ערוץ) חייבים לתמוך בהפקת פורמט מקביל של 8 סיביות, אם הבקשה הזו מתקבלת מהאפליקציה. כדי לשקף את העובדה הזו, צריך לתמוך בפורמט צבע YUV420 8:8:8 דרך android.media.MediaCodecInfo.

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

  • [C-2-1] חובה לתמוך בניתוח ובטיפול של מטא-נתונים סטטיים של HDR.

אם הטמעות של מכשירים מכריזות על תמיכה ברענון תוך-פריים באמצעות FEATURE_IntraRefresh בכיתה MediaCodecInfo.CodecCapabilities, הן:

  • [C-3-1] חובה לתמוך בתקופתי רענון בטווח של 10 עד 60 פריימים, ולפעול בצורה מדויקת בטווח של 20% מתקופת הרענון שהוגדרה.

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

  • [C-4-1] אם ההגדרה מתבצעת באמצעות פלט Surface, ברירת המחדל חייבת להיות פורמט הצבע המותאם בצורה אופטימלית לתצוגת החומרה.
  • [C-4-2] צריך להגדיר כברירת מחדל פורמט צבע YUV420 8:8:8 שמותאם לקריאה של מעבד אם לא מגדירים שימוש בפלט Surface.

5.1.8. רשימת קודיקי וידאו

פורמט/קודק פרטים סוגי הקבצים או הפורמטים של הקונטיינרים שנתמכים
H.263
  • 3GPP‏ (‎.3gp)
  • MPEG-4‏ (‎.mp4)
  • Matroska‏ (‎.mkv, פענוח בלבד)
H.264 AVC פרטים נוספים זמינים בקטע 5.2 ובקטע 5.3
  • 3GPP‏ (‎.3gp)
  • MPEG-4‏ (‎.mp4)
  • MPEG-2 TS ‏(‎.ts, לא ניתן לדלג)
  • Matroska‏ (‎.mkv, פענוח בלבד)
H.265 HEVC פרטים נוספים זמינים בקטע 5.3
  • MPEG-4‏ (‎.mp4)
  • Matroska‏ (‎.mkv, פענוח בלבד)
MPEG-2 פרופיל ראשי
  • MPEG2-TS‏ (‎.ts, לא ניתן לדלג)
  • MPEG-4‏ (‎.mp4, ‏ פענוח בלבד)
  • Matroska‏ (‎.mkv, פענוח בלבד)
MPEG-4 SP
  • 3GPP‏ (‎.3gp)
  • MPEG-4‏ (‎.mp4)
  • Matroska‏ (‎.mkv, פענוח בלבד)
VP8 פרטים נוספים זמינים בקטע 5.2 ו5.3
VP9 פרטים נוספים זמינים בקטע 5.3

5.1.9. אבטחה של קודק מדיה

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

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

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

  • [C-1-1] חובה לספק תמיכה בקודקים של מדיה באמצעות ממשקי OMX או Codec 2.0 API (או שניהם) כמו בפרויקט הקוד הפתוח של Android, ולא להשבית או לעקוף את אמצעי האבטחה. המשמעות היא לא שכל קודק חייב להשתמש ב-OMX או ב-Codec 2.0 API, אלא שחייבת להיות תמיכה לפחות באחד מה-API האלה, ותמיכה ב-API הזמינים חייבת לכלול את אמצעי האבטחה הקיימים.
  • [C-SR-1] מומלץ מאוד לכלול תמיכה ב-Codec 2.0 API.

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

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

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

  • [C-3-1] חובה לכלול את קודק התוכנה התואם של Codec 2.0 מ-Android Open Source Project (אם הוא זמין) לכל פורמט מדיה וסוג (מקודד או מפענח) שנתמכים במכשיר.
  • [C-3-2] חובה לאכלס את קודקי התוכנה של Codec 2.0 בתהליך של קודק התוכנה, כפי שמפורט בפרויקט Android Open Source, כדי לאפשר מתן גישה מצומצמת יותר לקודקי תוכנה.
  • [C-3-3] קודיקים ששמותיהם מתחילים ב-'c2.android.‎' חייב להתבסס על קוד המקור של פרויקט הקוד הפתוח של Android.

5.1.10. אפיון של קודק מדיה

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

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

ובפרט:

  • [C-1-2] קודיקים עם שמות שמתחילים ב-'OMX'. חובה להשתמש בממשקי ה-API של OMX, והשמות חייבים לעמוד בהנחיות למתן שמות של OMX IL.
  • [C-1-3] קודיקים עם שמות שמתחילים ב-'c2.‎' חובה להשתמש ב-Codec 2.0 API, והשמות צריכים לעמוד בהנחיות למתן שמות של Codec 2.0 ל-Android.
  • [C-1-4] קודיקים עם שמות שמתחילים ב-'OMX.google.‎' או ב-'c2.android.‎' אסור לאפיין אותו כספק או כמואץ בחומרה.
  • [C-1-5] אסור להגדיר כתוכנה בלבד קודקים שפועלים בתהליך קודק (של ספק או של מערכת) שיש להם גישה למנהלי חומרה מלבד מקצאי זיכרון וממפים.
  • [C-1-6] קודיקס שלא נמצאים בפרויקט Android Open Source Project או שלא מבוססים על קוד המקור בפרויקט הזה חייבים להיות מסווגים כספק.
  • [C-1-7] קודיקים שמשתמשים בהאצת חומרה חייבים להיות מסווגים ככאלה.
  • [C-1-8] אסור ששמות הקודקים יהיו מטעים. לדוגמה, קודיקים בשם 'decoders' חייבים לתמוך בפענוח, וקודיקים בשם 'encoders' חייבים לתמוך בקידוד. קודיקים עם שמות שמכילים פורמטים של מדיה חייבים לתמוך בפורמטים האלה.

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

  • [C-2-1] כל קודיקי הווידאו חייבים לפרסם נתונים על קצב הפריימים שאפשר להשיג בגדלים הבאים, אם הקודק תומך בהם:
SD (איכות נמוכה) SD (איכות גבוהה) HD 720p HD 1080p UHD
רזולוציית וידאו
  • 176 x 144 פיקסלים (H263, ‏ MPEG2, ‏ MPEG4)
  • 352 x 288 פיקסלים (מקודד MPEG4, ‏ H263, ‏ MPEG2)
  • 320 x 180 פיקסלים (VP8, ‏ VP8)
  • 320 x 240 פיקסלים (אחר)
  • 704 x 576 פיקסלים (H263)
  • 640 x 360 פיקסלים (VP8, ‏ VP9)
  • 640 x 480 פיקסלים (מקודד MPEG4)
  • 720 x 480 פיקסלים (אחר)
  • 1408 x 1152 פיקסלים (H263)
  • 1280 x 720 פיקסלים (אחר)
 ‎1920 x 1080 פיקסלים (לא MPEG4) 3840 x 2160 פיקסלים (HEVC, ‏ VP9)
  • [C-2-2] קודיקים של וידאו שמאופיינים כקודקים עם שיפור מהירות באמצעות חומרה חייבים לפרסם מידע על נקודות ביצועים. בכל אחת מהן חייבים להופיע כל נקודות הביצועים הרגילות הנתמכות (שמופיעות ב-API של PerformancePoint), אלא אם הן מכוסות בנקודת ביצועים רגילה אחרת שנתמכת.
  • בנוסף, הם צריכים לפרסם נקודות ביצועים מורחבות אם הם תומכים בביצועי וידאו עקביים שאינם אחד מהנתונים הסטנדרטיים שצוינו.

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

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

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

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

  • [C-SR-1] מומלץ מאוד לספק פלאגין לממשק ה-API להמרת קידוד חלקה כדי להמיר מפורמט HDR לפורמט SDR.

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 (סידור שרירותי של פרוסות), ב-FMO (סידור גמיש של מק"טים) וב-RS (פרוסות יתירות) היא אופציונלית. בנוסף, כדי לשמור על תאימות למכשירי Android אחרים, מומלץ שלא להשתמש ב-ASO, ב-FMO וב-RS בפרופיל הבסיסי על ידי מקודדים.
  • [C-1-2] חייב לתמוך בפרופילים של קידוד וידאו באיכות SD (רזולוציה רגילה) שמפורטים בטבלה הבאה.
  • צריכה להיות תמיכה ברמת 4 בפרופיל הראשי.
  • צריך לתמוך בפרופילים של קידוד וידאו באיכות HD (High Definition) כפי שמפורט בטבלה הבאה.

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

  • [C-2-1] חובה לתמוך בפרופילי הקידוד שמפורטים בטבלה הבאה.
SD (איכות נמוכה) SD (איכות גבוהה) HD 720p HD 1080p
רזולוציית וידאו 320 x 240 פיקסלים 720 x 480 פיקסלים ‎1280 x 720 פיקסלים ‎1,920 x 1,080 פיקסלים
קצב מסגרות של סרטון 20 פריימים לשנייה (FPS) 30 פריימים לשנייה (FPS) 30 פריימים לשנייה (FPS) 30 פריימים לשנייה (FPS)
קצב העברת נתונים של וידאו 384 Kbps 2 Mbps 4Mbps 10Mbps

5.2.3. VP8

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

  • [C-1-1] חובה לתמוך בפרופילים של קידוד וידאו ב-SD.
  • צריכה להיות תמיכה בפרופילים הבאים של קידוד וידאו באיכות HD (High Definition).
  • [C-1-2] חובה לתמוך בכתיבת קובצי Matroska WebM.
  • צריך לספק קודק VP8 לחומרה שעומד בדרישות הקידוד של חומרת RTC בפרויקט WebM, כדי להבטיח איכות סבירה של סטרימינג של וידאו באינטרנט ושל שירותי ועידות וידאו.

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

  • [C-2-1] חובה לתמוך בפרופילי הקידוד שמפורטים בטבלה הבאה.
SD (איכות נמוכה) SD (איכות גבוהה) HD 720p HD 1080p
רזולוציית וידאו 320 x 180 פיקסלים 640 x 360 פיקסלים ‎1280 x 720 פיקסלים ‎1,920 x 1,080 פיקסלים
קצב המסגרות של הסרטון 30 פריימים לשנייה (FPS) 30 פריימים לשנייה (FPS) 30 פריימים לשנייה (FPS) 30 פריימים לשנייה (FPS)
קצב העברת נתונים של וידאו 800 Kbps 2 Mbps 4Mbps 10Mbps

5.2.4. VP9

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

  • [C-1-2] חובה לתמוך בפרופיל 0 ברמה 3.
  • [C-1-1] חובה לתמוך בכתיבת קובצי Matroska WebM.
  • [C-1-3] חובה ליצור נתונים מסוג CodecPrivate.
  • צריך לתמוך בפרופילים של פענוח HD כפי שמצוין בטבלה הבאה.
  • [C-SR-1] מומלץ מאוד לתמוך בפרופילים של פענוח HD כפי שמצוין בטבלה הבאה, אם יש מקודד חומרה.
SD HD 720p HD 1080p UHD
רזולוציית וידאו 720 x 480 פיקסלים ‎1280 x 720 פיקסלים ‎1,920 x 1,080 פיקסלים 3840 x 2160 פיקסלים
קצב המסגרות של הסרטון 30 פריימים לשנייה (FPS) 30 פריימים לשנייה (FPS) 30 פריימים לשנייה (FPS) 30 פריימים לשנייה (FPS)
קצב העברת נתונים של וידאו 1.6 Mbps 4Mbps ‎5 Mbps ‎20 Mbps

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

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

5.2.5. H.265

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

  • [C-1-1] חובה לתמוך בפרופיל הראשי ברמה 3.
  • צריך לתמוך בפרופילי הקידוד של HD כפי שמצוין בטבלה הבאה.
  • [C-SR-1] מומלץ מאוד לתמוך בפרופילים של קידוד HD כפי שמצוין בטבלה הבאה, אם יש מקודד חומרה.
SD HD 720p HD 1080p UHD
רזולוציית וידאו 720 x 480 פיקסלים ‎1280 x 720 פיקסלים ‎1,920 x 1,080 פיקסלים 3840 x 2160 פיקסלים
קצב המסגרות של הסרטון 30 פריימים לשנייה (FPS) 30 פריימים לשנייה (FPS) 30 פריימים לשנייה (FPS) 30 פריימים לשנייה (FPS)
קצב העברת נתונים של וידאו 1.6 Mbps 4Mbps ‎5 Mbps ‎20 Mbps

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

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

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

5.3.5. H.265 (‏HEVC)

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

  • [C-1-1] חייב לתמוך ברמה הראשית של פרופיל Main ברמה 3 ובפרופילים של פענוח וידאו ברזולוציית SD, כפי שמפורט בטבלה הבאה.
  • צריך לתמוך בפרופילים של פענוח HD כפי שמצוין בטבלה הבאה.
  • [C-1-2] חובה לתמוך בפרופילי הפענוח של HD כפי שמצוין בטבלה הבאה, אם יש ממיר חומרה.

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

  • [C-2-1] הטמעות במכשירים חייבות לתמוך לפחות באחת מהאפשרויות הבאות: פענוח H.265 או פענוח VP9 של פרופילים 720, ‏ 1080 ו-UHD.
SD (איכות נמוכה) SD (איכות גבוהה) HD 720p HD 1080p UHD
רזולוציית וידאו 352 x 288 פיקסלים 720 x 480 פיקסלים ‎1280 x 720 פיקסלים ‎1,920 x 1,080 פיקסלים 3840 x 2160 פיקסלים
קצב המסגרות של הסרטון 30 פריימים לשנייה (FPS) 30 פריימים לשנייה (FPS) 30 פריימים לשנייה (FPS) 30/60‎ FPS (60‎ FPSטלוויזיה עם פענוח חומרה של H.265) 60 fps
קצב העברת נתונים של וידאו 600 Kbps 1.6 Mbps 4Mbps ‎5 Mbps ‎20 Mbps

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

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

5.3.6. VP8

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

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

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

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

5.3.7. VP9

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

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

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

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

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

  • [C-3-1] הטמעות במכשירים חייבות לתמוך לפחות באחת מהאפשרויות הבאות: פענוח VP9 או פענוח H.265 של הפרופילים 720, ‏ 1080 ו-UHD.
SD (איכות נמוכה) SD (איכות גבוהה) HD 720p HD 1080p UHD
רזולוציית וידאו 320 x 180 פיקסלים 640 x 360 פיקסלים ‎1280 x 720 פיקסלים ‎1,920 x 1,080 פיקסלים 3840 x 2160 פיקסלים
קצב המסגרות של הסרטון 30 פריימים לשנייה (FPS) 30 פריימים לשנייה (FPS) 30 פריימים לשנייה (FPS) 30fps (60fpsטלוויזיה עם פענוח חומרה של VP9) 60 fps
קצב העברת נתונים של וידאו 600 Kbps 1.6 Mbps 4Mbps ‎5 Mbps ‎20 Mbps

אם הטמעות במכשירים טוענות לתמיכה ב-VP9Profile2 או ב-VP9Profile3 דרך ממשקי ה-API של המדיה 'CodecProfileLevel':

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

אם הטמעות של מכשירים טוענות שהן תומכות בפרופיל HDR (VP9Profile2HDR,‏ VP9Profile2HDR10Plus, ‏ VP9Profile3HDR, ‏ VP9Profile3HDR10Plus) דרך ממשקי ה-API של המדיה:

  • [C-4-1] הטמעות במכשירים חייבות לקבל מהאפליקציה את המטא-נתונים הנדרשים של HDR (KEY_HDR_STATIC_INFO לכל פרופילי ה-HDR, וגם 'KEY_HDR10_PLUS_INFO' לפרופילים של HDR10Plus). הם חייבים גם לתמוך בחילוץ ובפלט של המטא-נתונים הנדרשים של HDR מזרם הביטים ו/או מהמאגר.
  • [C-4-2] הטמעות במכשירים חייבות להציג תוכן HDR כראוי במסך המכשיר או ביציאת וידאו רגילה (למשל, HDMI).

5.3.8. Dolby Vision

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

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

5.3.9. AV1

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

  • [C-1-1] חובה לתמוך בפרופיל 0, כולל תוכן של 10 ביט.

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

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

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

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

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

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

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

    • פורמט: Linear PCM, ‏ 16 ביט ו-24 ביט
    • תדירות דגימה: 8000, ‏ 11025, ‏ 16000, ‏ 22050, ‏ 24000, ‏ 32000, ‏ 44100,‏ 48000 הרץ
    • ערוצים: מספר הערוצים שווה למספר המיקרופונים במכשיר

  • [C-1-2] חובה לצלם בתדירויות דגימה גבוהות יותר ללא דגימה מחדש.

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

  • צריכה לאפשר הקלטה של תוכן אודיו גולמי באיכות רדיו AM ו-DVD, כלומר:

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

  • [C-1-4] חובה לפעול בהתאם לממשק ה-API MicrophoneInfo ולמלא כראוי את המידע על המיקרופונים הזמינים במכשיר שזמינים לאפליקציות של צד שלישי דרך ממשק ה-API AudioManager.getMicrophones(), ועל המיקרופונים הפעילים כרגע שזמינים לאפליקציות של צד שלישי דרך ממשקי ה-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, הן:

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 שיופעל בעוצמת קול של 90dB (SPL) יניב תגובה עם RMS של 2,500 לדגימות של 16 ביט (או -22.35dB Full Scale לדגימות של נקודת צפה/דיוק כפול) לכל מיקרופון שמשמש להקלטה של מקור האודיו לזיהוי הקול.
  • [C-SR-1] מומלץ מאוד להציג רמות אמפליטודה בטווח התדרים הנמוך: באופן ספציפי, מ-±20dB מ-5Hz עד 100Hz בהשוואה לטווח התדרים הבינוני לכל מיקרופון שמשמש להקלטת מקור האודיו לזיהוי הקול.
  • [C-SR-2] מומלץ מאוד להציג רמות אמפליטודה בטווח התדרים הגבוהים: במיוחד מ-±30 dB מ-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, ‏ 24000, ‏ 32000, ‏ 44100, ‏ 48000 בהגדרות הערוץ שמפורטות למעלה
      • 96,000 במונו ובסטריאו

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

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

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

  • [C-1-1] חובה לתמוך בהטמעות של EFFECT_TYPE_EQUALIZER ו-EFFECT_TYPE_LOUDNESS_ENHANCER שניתן לשלוט בהן באמצעות תתי-הסוגים של AudioEffect‏ Equalizer ו-LoudnessEnhancer.
  • [C-1-2] חובה לתמוך בהטמעת API של ויזואליzer, שניתן לשלוט בו באמצעות הכיתה Visualizer.
  • [C-1-3] חובה לתמוך בהטמעה של EFFECT_TYPE_DYNAMICS_PROCESSING שניתן לשלוט בה באמצעות צאצא משנה של AudioEffect‏ DynamicsProcessing.
  • צריכה לתמוך בהטמעות של EFFECT_TYPE_BASS_BOOST,‏ EFFECT_TYPE_ENV_REVERB,‏ EFFECT_TYPE_PRESET_REVERB ו-EFFECT_TYPE_VIRTUALIZER שניתן לשלוט בהן באמצעות תתי-הסוגים של AudioEffect,‏ BassBoost,‏ EnvironmentalReverb,‏ PresetReverb ו-Virtualizer.
  • [C-SR-1] מומלץ מאוד לתמוך באפקטים בספרות עשרוניות ובמספר ערוצים.

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

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

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

5.5.4. העברת אודיו

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

  • [C-SR-1] מומלץ מאוד לחתוך את תוכן האודיו שמושמע ללא הפסקות, כפי שמצוין ב-AudioTrack gapless API ובקונטיינר המדיה של MediaPlayer.

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

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

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

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

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

  • [C-1-1] חותמת הזמן של הפלט שמוחזרת על ידי AudioTrack.getTimestamp ו-AAudioStream_getTimestamp מדויקת בטווח של +/- 2 אלפיות השנייה.
  • [C-1-2] זמן אחזור של 500 אלפיות השנייה או פחות להפעלה ראשונית של פלט.

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

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

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

אם הטמעות במכשירים לא עומדות בדרישות לאודיו עם זמן אחזור קצר באמצעות ממשק ה-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-8] זמן אחזור של קלט קר של 100 אלפיות השנייה או פחות דרך נתיב הנתונים של המיקרופון. מומלץ מאוד למכשירים קיימים וחדשים עם גרסת Android הזו לעמוד בדרישות האלה כבר עכשיו. בגרסה עתידית של הפלטפורמה נדרוש זמן אחזור קלט קר (Cold) של 200 אלפיות השנייה או פחות.
  • [C-SR-9] זמן אחזור קלט רציף של 30 אלפיות השנייה או פחות.
  • [C-SR-10] צמצום התנודות (jitter) של הקלט הקר.
  • [C-SR-11] הגבלת השגיאה בחותמות הזמן של הקלט, כפי שהן מוחזרות על ידי AudioRecord.getTimestamp או AAudioStream_getTimestamp, ל-±1ms.

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

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

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

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

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

  • [C-1-1] חובה לתמוך בקודק או בקונטיינר הזה באמצעות HTTP ו-HTTPS.

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

  • [C-1-3] חובה לתמוך בפורמטים התואמים של עומסי נתונים (payload) ב-RTSP, כפי שמופיע בטבלה של RTSP בהמשך. לחריגים, ראו הערות השוליים בטבלה בקטע 5.1.

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

פורמטים של פלחים מקורות מידע תמיכה בקודקים הנדרשים
MPEG-2 Transport Stream ISO 13818 קודיקים של וידאו:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
פרטים על H264 AVC,‏ MPEG2-4 SP
ו-MPEG-2 מופיעים בקטע 5.1.8.

קודיקים של אודיו:

  • קובץ AAC
פרטים על AAC ועל הווריאציות שלו מופיעים בקטע 5.1.3.
AAC עם מסגרת ADTS ותגי ID3 ISO 13818-7 פרטים על AAC ועל הווריאציות שלו מופיעים בקטע 5.1.1 .
WebVTT WebVTT

RTSP‏ (RTP, ‏ SDP)

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

5.8. Secure Media

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

  • [C-1-1] חובה להצהיר על תמיכה ב-Display.FLAG_SECURE.

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

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

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

  • [C-3-1] חובה לתמוך ב-HDCP 1.2 ואילך לכל המסכים החיצוניים שמחוברים באמצעות יציאה קווית שזמינה למשתמשים.

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

אם הטמעות של מכשירים מדווחות על תמיכה בתכונה android.software.midi באמצעות הכיתה android.content.pm.PackageManager, הן:

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

  • [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 של אודיו מקורי של AAudio.
  • [C-1-6] זמן האחזור של הפלט בסטטוס 'לא בשימוש' חייב להיות 200 אלפיות שנייה או פחות.
  • [C-1-7] זמן האחזור של קלט קר חייב להיות 200 אלפיות השנייה או פחות.
  • [C-SR-1] מומלץ מאוד לעמוד בזמני האחזור כפי שהם מוגדרים בקטע 5.6 זמן אחזור של אודיו, של 20 אלפיות השנייה או פחות, ב-5 מדידות עם סטייה ממוצעת אבסולוטית של פחות מ-5 אלפיות השנייה במסלול מהרמקול למיקרופון.
  • [C-SR-2] מומלץ מאוד לעמוד בדרישות של Pro Audio לגבי זמן אחזור אודיו רציף הלוך ושוב, זמן אחזור קלט קר וזמן אחזור פלט קר, ודרישות האודיו ב-USB באמצעות ה-API של אודיו מקורי של AAudio לאורך הנתיב MMAP.
  • [C-SR-3] מומלץ מאוד לספק רמה עקבית של ביצועי מעבד בזמן שהאודיו פעיל ועומס המעבד משתנה. צריך לבדוק את זה באמצעות האפליקציה ל-Android‏ SynthMark. ב-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) של הקלט. לחלופין, אם לא ניתן לטפל בקריאות החזרה באותו חוט, צריך להיכנס לקריאת החזרה של הפלט זמן קצר אחרי שמזינים את קריאת החזרה של הקלט, כדי לאפשר לאפליקציה תזמון עקבי של צידי הקלט והפלט.
  • צריך למזער את הפרש הפאזה בין האחסון במטמון של אודיו ב-HAL בצד הקלט ובצד הפלט של נקודות הקצה התואמות.
  • צריך למזער את זמן האחזור של המגע.
  • צריך לצמצם את השונות של זמן האחזור למגע במהלך עומס (רעידה).
  • זמן האחזור מהקלט של המגע לפלט האודיו צריך להיות פחות מ-40 אלפיות השנייה או שווה לו.

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

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

  • [C-2-1] זמן האחזור הממוצע של אודיו במסלול הלוך ושוב, כפי שמוגדר בקטע 5.6 זמן אחזור של אודיו, חייב להיות 20 אלפיות השנייה או פחות, על פני 5 מדידות עם סטייה ממוצעת אבסולוטית של פחות מ-5 אלפיות השנייה במסלול של שקע האודיו.
  • [C-SR-5] מומלץ מאוד לציית לקטע Mobile device (jack) specifications (מפרטים של שקע למכשיר נייד) שמופיע בWired Audio Headset Specification (v1.1) (מפרט של אוזניות אודיו חוטיות, גרסה 1.1).

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

  • [C-3-1] חובה להטמיע את מחלקת האודיו של USB.
  • [C-3-2] זמן האחזור הממוצע של אודיו במסלול הלוך ושוב חייב להיות 25 אלפיות השנייה או פחות, על פני 5 מדידות עם סטייה ממוצעת אבסולוטית של פחות מ-5 אלפיות השנייה ביציאת מצב המארח של USB באמצעות סיווג אודיו USB. (אפשר למדוד את זה באמצעות מתאם USB-3.5mm ו-Audio Loopback Dongle, או באמצעות ממשק אודיו USB עם כבלים לחיבור בין מקורות הקלט לבין יציאות הקלט).
  • [C-SR-6] מומלץ מאוד שתהיה תמיכה בו-זמנית ב-I/O עד 8 ערוצים בכל כיוון, בקצב דגימה של 96kHz ובעומק של 24 או 32 ביט, כשמשתמשים בציוד היקפי של אודיו USB שתומך גם בדרישות האלה.
  • [C-SR-7] מומלץ מאוד לעמוד בקבוצת הדרישות הזו באמצעות ממשק ה-API המקורי של אודיו ב-AAudio דרך הנתיב MMAP.

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

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

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

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

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

  • [C-1-1] חובה לדווח על התמיכה באמצעות המאפיין android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-0-1] חובה לתמוך בכלים של Android למפתחים שכלולים ב-Android SDK.

  • ממשק הגישור של Android‏ (adb)

    • [C-0-2] חובה לתמוך ב-adb כפי שמתואר ב-Android SDK ובפקודות המעטפת שסופקו ב-AOSP, שבהן מפתחי אפליקציות יכולים להשתמש, כולל dumpsys cmd stats
    • [C-0-11] חייבת לתמוך בפקודת המעטפת cmd testharness. יכול להיות ששדרוג הטמעות במכשירים מגרסה קודמת של Android ללא בלוק נתונים מתמיד יהיה פטור מהדרישה של C-0-11.
    • [C-0-3] אסור לשנות את הפורמט או את התוכן של אירועי המערכת במכשיר (batterystats‏ , diskstats‏, fingerprint‏, graphicsstats‏, netstats‏, notification‏, procstats) שמתועדים ביומן באמצעות הפקודה dumpsys.
    • [C-0-10] חובה לתעד את האירועים הבאים, בלי להשמיט אף אחד מהם, ולאפשר גישה אליהם ולאפשר אותם לפקודת המעטפת cmd stats ולכיתה StatsManager System API.
      • ActivityForegroundStateChanged
      • AnomalyDetected
      • AppBreadcrumbReported
      • AppCrashOccurred
      • AppStartOccurred
      • BatteryLevelChanged
      • BatterySaverModeStateChanged
      • BleScanResultReceived
      • BleScanStateChanged
      • ChargingStateChanged
      • DeviceIdleModeStateChanged
      • ForegroundServiceStateChanged
      • GpsScanStateChanged
      • JobStateChanged
      • PluggedStateChanged
      • ScheduledJobStateChanged
      • ScreenStateChanged
      • SyncStateChanged
      • SystemElapsedRealtime
      • UidProcessStateChanged
      • WakelockStateChanged
      • WakeupAlarmOccurred
      • WifiLockStateChanged
      • WifiMulticastLockStateChanged
      • WifiScanStateChanged
    • [C-0-4] הדימון של adb בצד המכשיר חייב להיות לא פעיל כברירת מחדל, וחייבת להיות מנגנון שזמין למשתמשים כדי להפעיל את Android Debug Bridge.
    • [C-0-5] חובה לתמוך ב-adb מאובטח. ב-Android יש תמיכה ב-adb מאובטח. Secure adb מאפשר להפעיל את adb במארחים מוכרים ומאומתים.
    • [C-0-6] חובה לספק מנגנון שמאפשר להתחבר ל-adb ממכונת מארח. פרטים נוספים:

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

    • [C-3-1] חובה להטמיע את adb דרך רשת מקומית (כמו Ethernet או Wi-Fi).
    • [C-3-2] חובה לספק מנהלי התקנים ל-Windows 7, ‏ 8 ו-10, שמאפשרים למפתחים להתחבר למכשיר באמצעות פרוטוקול adb.

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

    • [C-4-1] השיטה AdbManager#isAdbWifiSupported() חייבת להחזיר את הערך true.

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

    • [C-5-1] השיטה AdbManager#isAdbWifiQrSupported() חייבת להחזיר את הערך true.

  • Dalvik Debug Monitor Service‏ (ddms)

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

  • Monkey

    • [C-0-8] חובה לכלול את מסגרת Monkey ולהפוך אותה לזמינה לאפליקציות.

  • SysTrace

    • [C-0-9] חובה לתמוך בכלי systrace כפי שמתואר ב-Android SDK. Systrace חייב להיות לא פעיל כברירת מחדל, וחייבת להיות מנגנון שזמין למשתמשים כדי להפעיל את Systrace.

  • Perfetto

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

  • Low Memory Killer

    • [C-0-10] חובה לכתוב LMK_KILL_OCCURRED_FIELD_NUMBER Atom ביומן statsd כשאפליקציה מסתיימת על ידי Low Memory Killer.

  • מצב מסגרת בדיקה אם הטמעות המכשיר תומכות בפקודת המעטפת cmd testharness ומריצות את cmd testharness enable, הן:

אם הטמעות במכשירים מדווחות על תמיכה ב-Vulkan 1.0 ואילך באמצעות דגלים של תכונות android.hardware.vulkan.version, הן:

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

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

Android כולל תמיכה למפתחים להגדרת הגדרות שקשורות לפיתוח אפליקציות.

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

  • [C-0-1] חובה לפעול בהתאם לכוונה של android.settings.APPLICATION_DEVELOPMENT_SETTINGS כדי להציג הגדרות שקשורות לפיתוח אפליקציות. בהטמעה של Android במקור, תפריט האפשרויות למפתחים מוסתר כברירת מחדל, והמשתמשים יכולים להפעיל אותו אחרי שלוחצים שבע (7) פעמים על הפריט בתפריט הגדרות > מידע על המכשיר > מספר Build.
  • [C-0-2] חובה להסתיר את האפשרויות למפתחים כברירת מחדל.
  • [C-0-3] חובה לספק מנגנון ברור שלא נותן עדיפות לאפליקציה אחת של צד שלישי על פני אפליקציה אחרת כדי להפעיל את Developer Options. חובה לספק מסמך או אתר גלוי לכולם שמתארים איך מפעילים את אפשרויות הפיתוח. חובה שאפשר יהיה לקשר את המסמך או את אתר האינטרנט הזה למסמכים של Android SDK.
  • צריכה להיות התראה חזותית מתמשכת למשתמש כשהאפשרויות למפתחים מופעלות ויש חשש לגבי בטיחות המשתמש.
  • יכולים להגביל באופן זמני את הגישה לתפריט 'אפשרויות למפתחים', על ידי הסתרה חזותית או השבתה של התפריט, כדי למנוע הסחות דעת בתרחישים שבהם יש חשש לגבי בטיחות המשתמש.

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

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

  • [C-0-1] ההטמעה במכשיר חייבת לכלול את ממשק ה-API הזה כפי שמתואר במסמכי התיעוד של Android SDK.

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

  • [C-0-2] עדיין צריך להציג הגדרות מלאות של כיתות (כפי שמתועד ב-SDK) לממשקי ה-API של הרכיבים.
  • [C-0-3] חובה להטמיע את ההתנהגויות של ה-API כ-no-ops באופן סביר כלשהו.
  • [C-0-4] שיטות API חייבות להחזיר ערכים null במקרים שבהם מותר לעשות זאת במסמכי התיעוד של ה-SDK.
  • [C-0-5] שיטות API חייבות להחזיר הטמעות של no-op של כיתות שבהן ערכים null לא מותרים לפי מסמכי ה-SDK.
  • [C-0-6] אסור לשיטות API להוציא חריגות שלא מתועדות במסמכי התיעוד של ה-SDK.
  • [C-0-7] הטמעות של מכשירים חייבות לדווח באופן עקבי על פרטי הגדרת חומרה מדויקים באמצעות השיטות getSystemAvailableFeatures() ו-hasSystemFeature(String) בכיתה android.content.pm.PackageManager לאותו טביעת אצבע של build.

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

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

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

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

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

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

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

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

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

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

  • [C-0-3] בהטמעות של מכשירים עם הערך Configuration.uiMode שמוגדר בתור UI_MODE_TYPE_WATCH, חובה להגדיר את הערך של יחס הגובה-רוחב כ-1.0‏ (1:1).

7.1.1.3. דחיסות מסך

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

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

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

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

  • [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. האצת גרפיקה 2D ו-3D

7.1.4.1 OpenGL ES

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

  • [C-0-1] חובה לזהות בצורה נכונה את הגרסאות הנתמכות של OpenGL ES‏ (1.1, ‏ 2.0,‏ 3.0, ‏ 3.1, ‏ 3.2) באמצעות ממשקי ה-API המנוהלים (למשל באמצעות השיטה GLES10.getString()) וממשקי ה-API המקומיים.
  • [C-0-2] חובה לכלול את התמיכה בכל ממשקי ה-API המנוהלים ובכל ממשקי ה-API הנתמכים לכל גרסאות OpenGL ES שזוהו.

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

  • [C-1-1] חובה לתמוך ב-OpenGL ES 1.1 וגם ב-2.0, כפי שמתואר בפירוט במסמכי התיעוד של Android SDK.
  • [C-SR-1] מומלץ מאוד לתמוך ב-OpenGL ES 3.1.
  • צריך לתמוך ב-OpenGL ES 3.2.

בדיקות OpenGL ES dEQP מחולקות למספר רשימות בדיקות, לכל אחת מהן משויך תאריך או מספר גרסת. הם נמצאים בעץ המקור של Android בכתובת external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt. מכשיר שתומך ב-OpenGL ES ברמה שדווחה על ידו מציין שהוא יכול לעבור את בדיקות dEQP בכל רשימות הבדיקות מהרמה הזו ואילך.

אם הטמעות במכשירים תומכות באחת מגרסאות OpenGL ES, הן:

  • [C-2-1] חובה לדווח באמצעות ממשקי ה-API המנוהלים של OpenGL ES וממשקי ה-API הנתמכים על כל התוספים האחרים של OpenGL ES שהוטמעו, ולהפך, אסור לדווח על מחרוזות של תוספים שהם לא תומכים בהם.
  • [C-2-2] חובה לתמוך בתוספים EGL_KHR_image,‏ EGL_KHR_image_base,‏ EGL_ANDROID_image_native_buffer,‏ EGL_ANDROID_get_native_client_buffer,‏ EGL_KHR_wait_sync,‏ EGL_KHR_get_all_proc_addresses,‏ EGL_ANDROID_presentation_time,‏ EGL_KHR_swap_buffers_with_damage,‏ EGL_ANDROID_recordable ו-EGL_ANDROID_GLES_layers.
  • [C-2-3] חובה לדווח על הגרסה המקסימלית של בדיקות dEQP של OpenGL ES שנתמכות באמצעות דגל התכונה android.software.opengles.deqp.level.
  • [C-2-4] חובה לתמוך לפחות בגרסה 132383489 (החל מ-1 במרץ 2020) כפי שצוין בדגל התכונה android.software.opengles.deqp.level.
  • [C-2-5] חובה לעבור את כל בדיקות dEQP של OpenGL ES ברשימות הבדיקות בין הגרסה 132383489 לבין הגרסה שצוינה בדגל התכונה android.software.opengles.deqp.level, לכל גרסה נתמכת של OpenGL ES.
  • [C-SR-2] מומלץ מאוד לתמוך בתוספים EGL_KHR_partial_update ו-OES_EGL_image_external.
  • צריך לדווח בצורה מדויקת באמצעות השיטה getString() על כל פורמט של דחיסת טקסטורה שנתמך, בדרך כלל ספציפי לספק.

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

  • [C-3-1] חובה לייצא את סמלי הפונקציות התואמים לגרסאות האלה, בנוסף לסמלי הפונקציות של OpenGL ES 2.0 בספרייה libGLESv2.so.
  • [C-SR-3] מומלץ מאוד לתמוך בתוסף OES_EGL_image_external_essl3.

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

  • [C-4-1] חובה לתמוך בחבילת התוספים של OpenGL ES ל-Android במלואה.

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

  • [C-5-1] חובה לציין את התמיכה באמצעות דגל התכונה android.hardware.opengles.aep.

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

  • [C-6-1] חייבת להיות תמיכה גם בתוסף EGL_ANDROID_front_buffer_auto_refresh.
7.1.4.2 Vulkan

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

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

  • [C-SR-1] מומלץ מאוד לכלול תמיכה ב-Vulkan 1.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-1-11] אסור לפרוס את התמיכה בתוספים VK_KHR_video_queue,‏ VK_KHR_video_decode_queue או VK_KHR_video_encode_queue.
  • [C-SR-2] מומלץ מאוד לתמוך בתוספים 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 שמואצות בחומרה כיעדים לעיבוד (render) בהיררכיית ממשק המשתמש.

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

  • [C-0-3] חובה לתמוך ב-TextureView API, וחובה להציג התנהגות עקבית עם ההטמעה של Android במקור.
7.1.4.5 מסכים עם מגוון רחב של צבעים

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

  • [C-1-1] חובה שיהיה מסך עם כיול צבע.
  • [C-1-2] חובה שיהיה צג שהספקטרום שלו מכסה את ספקטרום הצבעים של sRGB במלואו במרחב CIE 1931 xyY.
  • [C-1-3] חייב להיות צג ששטח המגוון שלו הוא לפחות 90% מ-DCI-P3 במרחב CIE 1931 xyY.
  • [C-1-4] חובה לתמוך ב-OpenGL ES 3.1 או 3.2 ולדווח על כך בצורה תקינה.
  • [C-1-5] חובה לפרסם תמיכה בתוספים EGL_KHR_no_config_context,‏ EGL_EXT_pixel_format_float,‏ EGL_KHR_gl_colorspace,‏ EGL_EXT_gl_colorspace_scrgb,‏ EGL_EXT_gl_colorspace_scrgb_linear,‏ EGL_EXT_gl_colorspace_display_p3,‏ EGL_EXT_gl_colorspace_display_p3_linear ו-EGL_EXT_gl_colorspace_display_p3_passthrough.
  • [C-SR-1] מומלץ מאוד לתמוך ב-GL_EXT_sRGB.

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

  • [C-2-1] צריך לכסות 100% או יותר מ-sRGB במרחב CIE 1931 xyY, למרות שסולם הצבעים של המסך לא מוגדר.

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

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

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

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

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

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

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

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

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

  • [C-1-1] חובה להטמיע את השירות וה-API של המערכת DisplayManager כפי שמתואר במסמכי התיעוד של Android SDK.

7.2. התקני קלט

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

7.2.1. מקלדת

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

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

  • [C-0-1] אסור לכלול מקלדת חומרה שלא תואמת לאחד מהפורמטים שצוינו ב-android.content.res.Configuration.keyboard (QWERTY או 12 מפתחות).
  • צריך לכלול הטמעות נוספות של מקלדות וירטואליות.
  • יכול להיות שיכלול מקלדת חומרה.

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

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

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

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

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

7.2.3. מקשי ניווט

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-6-1] WindowInsets#getMandatorySystemGestureInsets() אסור להשתמש ב-WindowInsets#getMandatorySystemGestureInsets() אלא כדי לדווח על אזור זיהוי התנועות להפעלת דף הבית.
  • [C-6-2] אסור ליירט תנועות שמתחילות בתוך מלבון החרגה שסופק על ידי האפליקציה שבחזית באמצעות View#setSystemGestureExclusionRects(), אבל מחוץ לWindowInsets#getMandatorySystemGestureInsets(), עבור פונקציית הניווט, כל עוד מלבון החרגה מותר בתוך מגבלת החרגה המקסימלית כפי שצוין במסמכי העזרה של View#setSystemGestureExclusionRects().
  • [C-6-3] חובה לשלוח לאפליקציה שבחזית את האירוע MotionEvent.ACTION_CANCEL ברגע שהמערכת מתחילה ליירט מגע כדי לזהות תנועה, אם לאפליקציה שבחזית נשלח בעבר האירוע MotionEvent.ACTION_DOWN.
  • [C-6-4] חובה לספק למשתמש אפשרות לעבור לניווט במסך שמבוסס על לחצנים (לדוגמה, בהגדרות).
  • צריך לספק את תפקיד דף הבית כהחלקה למעלה מהקצה התחתון של המסך בכיוון הנוכחי.
  • צריך לספק את התכונה 'פריטים אחרונים' באמצעות החלקה למעלה והחזקה לפני שמשחררים, מאותה אזור שבו מבצעים את התנועה 'דף הבית'.
  • תנועות שמתחילות ב-WindowInsets#getMandatorySystemGestureInsets() לא אמורות להיות מושפעות מריבוע החרגה שסופק על ידי האפליקציה שבחזית דרך View#setSystemGestureExclusionRects().

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

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

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
לחצן שימוש ב-HID2 Android Button
A1 0x09 0x0001 KEYCODE_BUTTON_A‏ (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B‏ (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X‏ (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y‏ (100)
לוח החיוג למעלה1
לוח החיוג למטה1		 0x01 0x00393 AXIS_HAT_Y4
מקשי החיצים (D-pad) שמאלה1
מקשי החיצים (D-pad) ימינה1		 0x01 0x00393 AXIS_HAT_X4
לחצן הכתף השמאלי1 0x09 0x0007 KEYCODE_BUTTON_L1‏ (102)
לחצן הכתף הימני1 0x09 0x0008 KEYCODE_BUTTON_R1‏ (103)
לחיצה על מקש הלחצן הימני1 0x09 0x000E KEYCODE_BUTTON_THUMBL‏ (106)
לחיצה על מקש ה-D-pad הימני1 0x09 0x000F KEYCODE_BUTTON_THUMBR‏ (107)
הקודם1 0x0c 0x0224 KEYCODE_BACK‏ (4)

1 KeyEvent

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

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

4 MotionEvent

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

אירוע MotionEvent אחד

7.2.7. שלט רחוק

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

7.3. חיישנים

אם הטמעות במכשירים כוללות סוג חיישן מסוים שיש לו ממשק API תואם למפתחים של צד שלישי, הטמעת המכשיר חייבת ליישם את ממשק ה-API הזה כפי שמתואר במסמכי התיעוד של Android SDK ובמסמכי התיעוד של Android Open Source בנושא חיישנים.

הטמעות במכשירים:

  • [C-0-1] חובה לדווח במדויק על נוכחות או על היעדר של חיישנים בהתאם ל-class‏ android.content.pm.PackageManager.
  • [C-0-2] חובה להחזיר רשימה מדויקת של חיישנים נתמכים באמצעות השיטה SensorManager.getSensorList() ושיטות דומות.
  • [C-0-3] חובה לפעול באופן סביר בכל ממשקי ה-API האחרים של החיישנים (לדוגמה, על ידי החזרת הערך true או false בהתאם כשאפליקציות מנסים לרשום מאזינים, לא להפעיל מאזינים של חיישנים כשהחיישנים המתאימים לא נמצאים וכו').

אם הטמעות במכשירים כוללות סוג חיישן מסוים שיש לו ממשק API תואם למפתחים של צד שלישי, הן:

  • [C-1-1] חובה לדווח על כל מדידות החיישן באמצעות הערכים הרלוונטיים של המערכת הבינלאומית של יחידות (מטריות) לכל סוג חיישן, כפי שמוגדר במסמכי התיעוד של Android SDK.
  • [C-1-2] חובה לדווח על נתוני חיישנים עם זמן אחזור מקסימלי של 100 אלפיות שנייה + 2 * sample_time במקרה של שידור חיישנים עם זמן אחזור מבוקש מקסימלי של 0 אלפיות שנייה כשמעבד האפליקציה פעיל. העיכוב הזה לא כולל עיכובים בסינון.
  • [C-1-3] חובה לדווח על הדגימה הראשונה של החיישן תוך 400 אלפיות שנייה + 2 * sample_time מהפעלת החיישן. מותר לדגימה הזו להיות עם רמת דיוק של 0.
  • [C-1-4] כל ממשק API שמסומן במסמכי התיעוד של Android SDK בתור חיישן רציף חייב לספק באופן קבוע דגימות נתונים תקופתיות, שצריך להיות להן רמת רעידות (jitter) נמוכה מ-3%. רעידות מוגדרות כסטיית התקן של ההבדל בין ערכי חותמות הזמן שדווחו בין אירועים רצופים.
  • [C-1-5] חובה לוודא שזרם האירועים של החיישן לא ימנע ממעבד המכשיר לעבור למצב השהיה או להתעורר ממצב השהיה.
  • [C-1-6] חובה לדווח על שעת האירוע בננו-שניות כפי שמוגדר במסמכי התיעוד של Android SDK, שמייצגת את השעה שבה האירוע התרחש ומתואמת עם השעון SystemClock.elapsedRealtimeNano().
  • [C-SR-1] מומלץ מאוד שהשגיאה בסנכרון של חותמת הזמן תהיה פחות מ-100 אלפיות השנייה, ורצוי שהיא תהיה פחות מ-1 אלפית השנייה.
  • כשמפעילים כמה חיישנים, צריכת החשמל לא אמורה לחרוג מסך צריכת החשמל שדווחה על ידי כל חיישן בנפרד.

הרשימה שלמעלה לא מקיפה. יש להתייחס להתנהגות המתועדת של Android SDK ולמסמכי התיעוד של Android Open Source בנושא חיישנים כמקור מידע מהימן.

אם הטמעות במכשירים כוללות סוג חיישן מסוים שיש לו ממשק API תואם למפתחים של צד שלישי, הן:

  • [C-1-6] חובה להגדיר רזולוציה שאינה אפס לכל החיישנים ולדווח על הערך באמצעות שיטת ה-API Sensor.getResolution().

יש סוגים של חיישנים שהם מורכבים, כלומר אפשר להסיק אותם מנתונים שמספקים חיישן אחד או יותר. (דוגמאות: חיישן הכיוון וחישן התאוצה הלינארית).

הטמעות במכשירים:

  • מומלץ להטמיע את סוגי החיישנים האלה, אם הם כוללים את החיישנים הפיזיים הנדרשים כפי שמתואר בקטע סוגי חיישנים.

אם הטמעות במכשירים כוללות חיישן מורכב, הן:

  • [C-2-1] חובה להטמיע את החיישן כפי שמתואר במסמכי התיעוד של Android Open Source בנושא חיישנים מורכבים.

אם הטמעות במכשירים כוללות סוג חיישן מסוים שיש לו ממשק API תואם למפתחים של צד שלישי, והחיישן מדווח רק על ערך אחד, הטמעות במכשירים:

  • [C-3-1] חובה להגדיר את הרזולוציה ל-1 עבור החיישן ולדווח על הערך באמצעות שיטת ה-API Sensor.getResolution().

אם הטמעות במכשיר כוללות סוג חיישן מסוים שתומך ב-SensorAdditionalInfo#TYPE_VEC3_CALIBRATION והחיישן חשוף למפתחים של צד שלישי, הם:

  • [C-4-1] אסור לכלול בנתונים שסופקו פרמטרים קבועים של כיול שהוגדרו במפעל.

אם הטמעות במכשירים כוללות שילוב של מד תאוצה משולש-צירים, חיישן ג'ירוסקופ משולש-צירים או חיישן מגנטומטר, הן:

  • [C-SR-2] מומלץ מאוד לוודא שלמד תאוצה, לג'ירוסקופ ולמגנטומטר יש מיקום יחסי קבוע, כך שאם המכשיר ניתן לשינוי (למשל, מתקפל), צירי החיישנים יישארו מותאמים ועקביים למערכת הקואורדינטות של החיישן בכל מצבי השינוי האפשריים של המכשיר.

7.3.1. מד תאוצה

הטמעות במכשירים:

  • [C-SR-1] מומלץ מאוד לכלול מד תאוצה ב-3 צירים.

אם ההטמעות במכשירים כוללות מד תאוצה ב-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 שניות בקצב הדגימה המהיר ביותר.
  • [C-SR-2] מומלץ מאוד להטמיע את החיישן המשולב TYPE_SIGNIFICANT_MOTION.
  • [C-SR-3] מומלץ מאוד להטמיע את החיישן 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-4] מומלץ מאוד להטמיע את החיישן המשולב TYPE_GAME_ROTATION_VECTOR.

אם הטמעות במכשירים כוללות מד תאוצה עם 3 צירים, חיישן ג'ירוסקופ עם 3 צירים וחיישן מגנטומטר, הן:

  • [C-4-1] חובה להטמיע חיישן משולב מסוג TYPE_ROTATION_VECTOR.

7.3.2. מגנטומטר

הטמעות במכשירים:

  • [C-SR-1] מומלץ מאוד לכלול מגנטומטר (מצפן) ב-3 צירים.

אם הטמעות במכשירים כוללות מגנטומטר 3-צירי, הן:

  • [C-1-1] חובה להטמיע את החיישן TYPE_MAGNETIC_FIELD.
  • [C-1-2] חייב להיות מסוגל לדווח על אירועים בתדירות של לפחות 10Hz, ומומלץ לדווח על אירועים בתדירות של לפחות 50Hz.
  • [C-1-3] חייב להיות תואם למערכת הקואורדינטות של חיישן Android כפי שמפורט בממשקי ה-API של Android.
  • [C-1-4] חייב להיות מסוגל למדוד בין -900 µT ל-‎+900 µT בכל ציר לפני שהוא מגיע לרוויה.
  • [C-1-5] הערך של ההיסט של ברזל קשה חייב להיות קטן מ-700 µT, והערך צריך להיות קטן מ-200 µT. לשם כך, צריך למקם את המגנטומטר הרחק משדות מגנטיים דינמיים (שנגרמים על ידי זרם) וסטטיים (שנגרמים על ידי מגנט).
  • [C-1-6] הרזולוציה חייבת להיות שווה ל-0.6 µT או צפופה יותר.
  • [C-1-7] חובה לתמוך בניפוי ובתיקון אונליין של הטיה של חומרה קשיחה, ולשמור את פרמטרי התיקון בין הפעלות מחדש של המכשיר.
  • [C-1-8] חובה להחיל את הפיצוי של ברזל רך – אפשר לבצע את ההתאמה בזמן השימוש או במהלך ייצור המכשיר.
  • [C-1-9] סטיית התקן, המחושבת על בסיס ציר לכל דגימה שנאספה במשך תקופה של 3 שניות לפחות בקצב הדגימה המהיר ביותר, חייבת להיות לא יותר מ-1.5 µT. מומלץ שסטיית התקן תהיה לא יותר מ-0.5 µT.
  • [C-1-10] חובה להטמיע את החיישן TYPE_MAGNETIC_FIELD_UNCALIBRATED.

אם הטמעות במכשיר כוללות מגנטומטר 3-צירי, חיישן מד תאוצה וחיישן ג'ירוסקופ 3-צירי, הן:

  • [C-2-1] חובה להטמיע חיישן משולב מסוג TYPE_ROTATION_VECTOR.

אם הטמעות במכשירים כוללות מגנטומטר ב-3 צירים, מד תאוצה, הן:

  • יכולים להטמיע את החיישן TYPE_GEOMAGNETIC_ROTATION_VECTOR.

אם הטמעות במכשירים כוללות מגנטומטר ב-3 צירים, מד תאוצה וחיישן TYPE_GEOMAGNETIC_ROTATION_VECTOR, הן:

  • [C-3-1] צריך להיות צריכת אנרגיה של פחות מ-10mW.
  • צריכת האנרגיה אמורה להיות פחות מ-3mW כשהחיישן רשום במצב באצ'ט ב-10Hz.

7.3.3. GPS

הטמעות במכשירים:

  • [C-SR-1] מומלץ מאוד לכלול מקלט GPS/GNSS.

אם הטמעות במכשירים כוללות מקלט GPS/GNSS ומדווחות על היכולת לאפליקציות באמצעות דגל התכונה android.hardware.location.gps, הן:

  • [C-1-1] חובה לתמוך במיקומי פלט בקצב של לפחות 1Hz כשמבקשים דרך LocationManager#requestLocationUpdate.
  • [C-1-2] חייב להיות אפשרי לקבוע את המיקום בתנאים של שדה פתוח (אותות חזקים, נתיב מרובים זניח, HDOP‏ < 2) תוך 10 שניות (זמן קצר לחישוב המיקום הראשון), כשמחוברים לחיבור אינטרנט במהירות נתונים של 0.5Mbps או יותר. בדרך כלל, הדרישה הזו מתקיימת באמצעות שימוש בשיטה כלשהי של GPS/GNSS מסייע או צפוי כדי למזער את זמן הנעילה של GPS/GNSS (נתוני העזרה כוללים את זמן העזרה, מיקום העזרה ואת השעון/האפומריס של הלוויין).
    • [C-1-6] אחרי חישוב מיקום כזה, הטמעות של מכשירים חייבות לקבוע את המיקום שלהן, בשמיים פתוחים, תוך 5 שניות, כשבקשות המיקום מופעלות מחדש, עד שעה אחרי חישוב המיקום הראשוני, גם אם הבקשה הבאה נשלחת ללא חיבור נתונים ו/או אחרי מחזור הפעלה/כיבוי.

  • בשמיים פתוחים, אחרי שנקבע המיקום, במצב נייח או בתנועה עם תאוצה של פחות ממטר אחד לשנייה בריבוע:

    • [C-1-3] חייב להיות מסוגל לקבוע את המיקום בטווח של 20 מטר ואת המהירות בטווח של 0.5 מטר לשנייה, לפחות ב-95% מהמקרים.
    • [C-1-4] חובה לעקוב בו-זמנית אחרי לפחות 8 לוויינים מקבוצת לוויינים אחת ולדווח עליהם באמצעות GnssStatus.Callback.
    • צריך להיות אפשרי לעקוב בו-זמנית אחרי לפחות 24 לוויינים, מכמה קבוצות של לוויינים (למשל, GPS + לפחות אחד מ-Glonass,‏ Beidou,‏ Galileo).

  • [C-SR-2] מומלץ מאוד להמשיך לספק פלט נתוני מיקום רגילים של GPS/GNSS דרך ממשקי ה-API של ספקי מיקום GNSS במהלך שיחת טלפון למקרה חירום.

  • [C-SR-3] מומלץ מאוד לדווח על מדידות GNSS מכל קבוצות הכוכבים שבמעקב (כפי שמדווח בהודעות GnssStatus), מלבד SBAS.

  • [C-SR-4] מומלץ מאוד לדווח על AGC ועל תדירות המדידה של GNSS.

  • [C-SR-5] מומלץ מאוד לדווח על כל אומדני הדיוק (כולל כיוון, מהירות ונתונים אנכיים) כחלק מכל מיקום GPS/GNSS.

  • [C-SR-6] מומלץ מאוד לדווח על מדידות GNSS ברגע שהן מתגלות, גם אם עדיין לא דווח על מיקום שמחושב מ-GPS/GNSS.

  • [C-SR-7] מומלץ מאוד לדווח על טווחי פסאודו וקצבי פסאודו של GNSS, שבתנאי שדה פתוח אחרי שנקבע המיקום, בזמן שהמכשיר נייח או נע במהירות של פחות מ-0.2 מטר לשנייה בריבוע, מספיקים כדי לחשב מיקום בטווח של 20 מטרים ומהירות בטווח של 0.2 מטר לשנייה, לפחות ב-95% מהמקרים.

7.3.4. ג'ירוסקופ

הטמעות במכשירים:

  • [C-SR-1] מומלץ מאוד לכלול חיישן ג'ירוסקופ.

אם ההטמעות במכשירים כוללות ג'ירוסקופ ב-3 צירים, הן:

  • [C-1-1] חייב להיות מסוגל לדווח על אירועים בתדירות של לפחות 50Hz.
  • [C-1-2] חובה להטמיע את החיישן TYPE_GYROSCOPE.
  • [C-1-4] חייבת להיות רזולוציה של 12 ביט או יותר.
  • [C-1-5] חייב להיות עם פיצוי טמפרטורה.
  • [C-1-6] חייב לעבור כיול ותיקון במהלך השימוש, ולשמור על פרמטרי התיקון בין הפעלות מחדש של המכשיר.
  • [C-1-7] ההפרש בין הממוצעים חייב להיות קטן מ-1e-7 rad^2 / s^2 לכל הרץ (הפרש לכל הרץ, או rad^2 / s). ניתן לשנות את סטיית התקן בהתאם לשיעור הדגימה, אבל היא חייבת להיות מוגבלת בערך הזה. במילים אחרות, אם מודדים את השונות של הגירוסקופ בקצב דגימה של 1Hz, היא לא אמורה להיות גבוהה מ-1e-7 rad^2/s^2.
  • [C-SR-2] מומלץ מאוד שהשגיאה בכיול תהיה פחות מ-0.01 rad/s כשהמכשיר נייח בטמפרטורת החדר.
  • [C-SR-3] מומלץ מאוד להטמיע את החיישן TYPE_GYROSCOPE_UNCALIBRATED.
  • [C-SR-4] מומלץ מאוד להשתמש ברזולוציה של 16 ביט או יותר.
  • צריך לדווח על אירועים עד 200Hz לפחות.

אם הטמעות במכשירים כוללות ג'ירוסקופ עם 3 צירים, חיישן מד תאוצה וחיישן מגנטומטר, הן:

  • [C-2-1] חובה להטמיע חיישן משולב מסוג TYPE_ROTATION_VECTOR.

אם הטמעות במכשירים כוללות מד תאוצה ב-3 צירים וחיישן ג'ירוסקופ ב-3 צירים, הן:

  • [C-3-1] חובה להטמיע את החיישנים המשולבים TYPE_GRAVITY ו-TYPE_LINEAR_ACCELERATION.
  • [C-SR-5] מומלץ מאוד להטמיע את החיישן המשולב TYPE_GAME_ROTATION_VECTOR.

7.3.5. ברומטר

הטמעות במכשירים:

  • [C-SR-1] מומלץ מאוד לכלול ברומטר (חיישן לחץ אוויר סביבתי).

אם הטמעות במכשירים כוללות ברומטר, הן:

  • [C-1-1] חובה להטמיע את החיישן TYPE_PRESSURE ולדווח עליו.
  • [C-1-2] חובה שאפשר יהיה לשלוח אירועים בתדירות של 5Hz או יותר.
  • [C-1-3] חייב להיות פיצוי טמפרטורה.
  • [C-SR-2] מומלץ מאוד לדווח על מדידות לחץ בטווח של 300hPa עד 1100hPa.
  • צריכה להיות דיוק מוחלט של 1hPa.
  • רמת הדיוק היחסי צריכה להיות 0.12hPa בטווח של 20hPa (שווה ערך לדיוק של כ-1 מ' בשינוי של כ-200 מ' בגובה פני הים).

7.3.6. מדחום

אם הטמעות המכשירים כוללות מדחום סביבתי (חיישן טמפרטורה), הן:

  • [C-1-1] חייבים להגדיר את SENSOR_TYPE_AMBIENT_TEMPERATURE לחישן הטמפרטורה הסביבתית, והחיישן חייב למדוד את הטמפרטורה הסביבתית (החדר או תא הרכב) שממנה המשתמש מבצע אינטראקציה עם המכשיר, במדד צלזיוס.

אם הטמעות במכשירים כוללות חיישן מדחום שמודד טמפרטורה שונה מטמפרטורת הסביבה, כמו טמפרטורת המעבד, הן:

אם הטמעות המכשירים כוללות חיישן למעקב אחרי טמפרטורת העור, הן:

7.3.7. פוטומטר

  • הטמעות במכשירים עשויות לכלול פוטומטרים (חיישן אור רגיש לסביבה).

7.3.8. חיישן קירבה

  • הטמעות במכשירים עשויות לכלול חיישן קירבה.

אם הטמעות במכשירים כוללות חיישן קירבה ומדווחות רק על קריאה בינארית של 'קרוב' או 'רחוק', הן:

  • [C-1-1] חובה למדוד את הקרבה של אובייקט באותו כיוון של המסך. כלומר, חיישן הקרבה חייב להיות מכוון לזיהוי אובייקטים שנמצאים קרוב למסך, כי המטרה העיקרית של סוג החיישן הזה היא לזהות טלפון שהמשתמש משתמש בו. אם הטמעות במכשירים כוללות חיישן קרבה בכיוון אחר, אסור שאפשר יהיה לגשת אליו דרך ה-API הזה.
  • [C-1-2] חייב להיות דיוק של ביט אחד או יותר.
  • [C-1-3] חובה להשתמש ב-0 סנטימטרים כמדידה בטווח הקצר וב-5 סנטימטרים כמדידה בטווח הרחוק.
  • [C-1-4] חובה לדווח על טווח ורזולוציה מקסימליים של 5.

7.3.9. חיישנים באיכות גבוהה

אם הטמעות במכשירים כוללות קבוצה של חיישנים באיכות גבוהה יותר כפי שמוגדר בקטע הזה, ומאפשרות לאפליקציות של צד שלישי לגשת אליהם, הן:

  • [C-1-1] חובה לזהות את היכולת באמצעות ה-feature flag‏ android.hardware.sensor.hifi_sensors.

אם הטמעות של מכשירים מגדירות את android.hardware.sensor.hifi_sensors, הן:

  • [C-2-1] חייב להיות חיישן TYPE_ACCELEROMETER ש:

    • טווח המדידה חייב להיות לפחות בין -8g ל-8g, ומומלץ מאוד שהטווח יהיה לפחות בין -16g ל-16g.
    • חייבת להיות רזולוציית מדידה של לפחות 2048 LSB/g.
    • תדר המדידה המינימלי חייב להיות 12.5Hz או פחות.
    • חייבת להיות תדירות מדידה מקסימלית של 400 הרץ ומעלה. מומלץ לתמוך ב-SensorDirectChannel‏ RATE_VERY_FAST.
    • רעש המדידה חייב להיות לא יותר מ-400 μg/√Hz.
    • חובה להטמיע את החיישן הזה בצורה ללא התעוררות עם יכולת אחסון ב-buffer של לפחות 3,000 אירועי חיישן.
    • צריכת החשמל של האצווה חייבת להיות לא יותר מ-3mW.
    • [C-SR-1] מומלץ מאוד שרוחב הפס למדידת 3dB יהיה לפחות 80% מתדירות Nyquist, וספקטרום של רעש לבן בתוך רוחב הפס הזה.
    • צריך להיות תנועה אקראית של תאוצה קטנה מ-30 μg √Hz שנבדקה בטמפרטורת החדר.
    • השינוי בסטייה לעומת הטמפרטורה צריך להיות ≤ +/- 1 mg/°C.
    • צריכה להיות לקו ההתאמה הטובה ביותר חריגה ליניאריות של ≤ 0.5%, ושינוי הרגישות לטמפרטורה של ≤ 0.03%/°C.
    • צריכה להיות רגישות ציר-לציר של פחות מ-2.5 % ותנודות ברגישות ציר-לציר של פחות מ-0.2% בטווח הטמפרטורות שבו המכשיר פועל.

  • [C-2-2] חייב להיות TYPE_ACCELEROMETER_UNCALIBRATED עם אותן דרישות איכות כמו TYPE_ACCELEROMETER.

  • [C-2-3] חייב להיות חיישן TYPE_GYROSCOPE ש:

    • טווח המדידה חייב להיות לפחות -1,000 עד +1,000 דפיקות לשנייה.
    • חייבת להיות רזולוציית מדידה של לפחות 16 LSB/dps.
    • תדר המדידה המינימלי חייב להיות 12.5Hz או פחות.
    • חייבת להיות תדירות מדידה מקסימלית של 400 הרץ ומעלה. מומלץ לתמוך ב-SensorDirectChannel‏ RATE_VERY_FAST.
    • רעש המדידה חייב להיות לא יותר מ-0.014°/s/√Hz.
    • [C-SR-2] מומלץ מאוד שרוחב הפס למדידת 3dB יהיה לפחות 80% מתדירות Nyquist, וספקטרום של רעש לבן בתוך רוחב הפס הזה.
    • צריך להיות תנועה אקראית של קצב קטן מ-0.001°/s √Hz שנבדקה בטמפרטורת החדר.
    • השינוי בסטייה לעומת הטמפרטורה צריך להיות ≤ +/- 0.05 °/ s / °C.
    • השינוי ברגישות כתוצאה מטמפרטורה צריך להיות ≤ 0.02% / °C.
    • יש להיות קו בעל התאמה הטובה ביותר עם סטייה לא לינארית של ≤ 0.2%.
    • צפיפות הרעש צריכה להיות ≤ 0.007 °/s/√Hz.
    • שגיאת העיבוד צריכה להיות קטנה מ-0.002 rad/s בטווח הטמפרטורות 10 עד 40 מעלות צלזיוס כשהמכשיר נייח.
    • רגישות ה-g צריכה להיות פחות מ-0.1°/s/g.
    • צריכה להיות רגישות לציר רוחבי של פחות מ-4.0 % ותנודות ברגישות לציר רוחבי של פחות מ-0.3% בטווח הטמפרטורות שבו המכשיר פועל.

  • [C-2-4] חייב להיות TYPE_GYROSCOPE_UNCALIBRATED עם אותן דרישות איכות כמו TYPE_GYROSCOPE.

  • [C-2-5] חייב להיות חיישן TYPE_GEOMAGNETIC_FIELD ש:

    • חייב להיות טווח מדידה של לפחות -900 עד +900 μT.
    • חייבת להיות רזולוציית מדידה של לפחות 5 LSB/uT.
    • תדר המדידה המינימלי חייב להיות 5Hz או פחות.
    • תדירות המדידה המקסימלית חייבת להיות 50 הרץ ומעלה.
    • רעש המדידה חייב להיות לא יותר מ-0.5 uT.

  • [C-2-6] חייב להיות TYPE_MAGNETIC_FIELD_UNCALIBRATED עם אותן דרישות איכות כמו TYPE_GEOMAGNETIC_FIELD, ובנוסף:

    • חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון ב-buffer של לפחות 600 אירועי חיישן.
    • [C-SR-3] מומלץ מאוד להשתמש בספקטרום של רעש לבן מ-1Hz ל-10Hz לפחות כשקצב הדיווח הוא 50Hz ומעלה.

  • [C-2-7] חייב להיות חיישן TYPE_PRESSURE ש:

    • טווח המדידה חייב להיות לפחות 300 עד 1,100 hPa.
    • חייבת להיות רזולוציית מדידה של לפחות 80 LSB/hPa.
    • תדר המדידה המינימלי חייב להיות 1Hz או פחות.
    • תדירות המדידה המקסימלית חייבת להיות 10 הרץ ומעלה.
    • רעש המדידה חייב להיות לא יותר מ-2 Pa/√Hz.
    • חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון ב-buffer של לפחות 300 אירועי חיישן.
    • צריכת החשמל של האצווה חייבת להיות לא יותר מ-2mW.

  • [C-2-8] חייב להיות חיישן TYPE_GAME_ROTATION_VECTOR.

  • [C-2-9] חייב להיות חיישן TYPE_SIGNIFICANT_MOTION ש:

    • צריכת האנרגיה חייבת להיות לא יותר מ-0.5mW כשהמכשיר נייח, ו-1.5mW כשהמכשיר בתנועה.

  • [C-2-10] חייב להיות חיישן TYPE_STEP_DETECTOR ש:

    • חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון ב-buffer של לפחות 100 אירועי חיישן.
    • צריכת האנרגיה חייבת להיות לא יותר מ-0.5mW כשהמכשיר נייח, ו-1.5mW כשהמכשיר בתנועה.
    • צריכת החשמל של האצווה חייבת להיות לא יותר מ-4mW.

  • [C-2-11] חייב להיות חיישן TYPE_STEP_COUNTER ש:

    • צריכת האנרגיה חייבת להיות לא יותר מ-0.5mW כשהמכשיר נייח, ו-1.5mW כשהמכשיר בתנועה.

  • [C-2-12] חייב להיות חיישן TILT_DETECTOR ש:

    • צריכת האנרגיה חייבת להיות לא יותר מ-0.5mW כשהמכשיר נייח, ו-1.5mW כשהמכשיר בתנועה.

  • [C-2-13] חותמת הזמן של אותו אירוע פיזי שדווח על ידי ה-Accelerometer, ה-Gyroscope וה-Magnetometer חייבת להיות בטווח של 2.5 אלפיות השנייה זו מזו. חותמת הזמן של אותו אירוע פיזי שדווח על ידי ה-Accelerometer וה-Gyroscope אמורה להיות בטווח של 0.25 אלפיות השנייה אחת מהשנייה.

  • [C-2-14] חובה שתהיה חותמת זמן לאירועים של חיישן הגירוסקופ באותה בסיס זמן כמו למערכת המשנית של המצלמה, ובטווח שגיאה של מיליסיקון אחד.

  • [C-2-15] חובה לספק דגימות לאפליקציות תוך 5 אלפיות השנייה ממועד זמינות הנתונים באפליקציה דרך אחד מהחיישנים הפיזיים שלמעלה.

  • [C-2-16] צריך להיות צריכת אנרגיה של פחות מ-0.5mW כשהמכשיר נייח ו-2.0mW כשהמכשיר בתנועה, כשכל שילוב של החיישנים הבאים מופעל:

    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS

  • [C-2-17] יכול להיות חיישן TYPE_PROXIMITY, אבל אם הוא קיים, חייבת להיות לו יכולת מאגר נתונים זמנית (buffer) של 100 אירועי חיישן לפחות.

חשוב לדעת שכל הדרישות לגבי צריכת החשמל בקטע הזה לא כוללות את צריכת החשמל של מעבד האפליקציות. הוא כולל את כל צריכת החשמל של שרשרת החיישנים כולה – החיישן, כל מעגל התמיכה, כל מערכת עיבוד נתונים ייעודית של חיישנים וכו'.

אם הטמעות המכשירים כוללות תמיכה ישירה בחיישנים, הן:

  • [C-3-1] חובה להצהיר בצורה נכונה על תמיכה בסוגים של ערוצי דיווח ישיר ועל רמת הדיווחים הישירה באמצעות ממשקי ה-API isDirectChannelTypeSupported ו-getHighestDirectReportRateLevel.
  • [C-3-2] חייבת להיות תמיכה לפחות באחד משני סוגי הערוצים הישירים של החיישן לכל החיישנים שמצהירים על תמיכה בערוץ ישיר של חיישן.
  • צריך לתמוך בדיווח על אירועים דרך ערוץ ישיר של חיישן עבור חיישן ראשי (לא וריאנט של התעוררות) מהסוגים הבאים:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. חיישנים ביומטריים

מידע נוסף על מדידת האבטחה של ביטול הנעילה הביומטרי זמין במאמר המסמכים בנושא מדידת האבטחה הביומטרית.

אם הטמעות במכשירים כוללות מסך נעילה מאובטח, הן:

  • צריך לכלול חיישן ביומטרי

חיישנים ביומטריים יכולים להיות מסווגים כרמה 3 (לשעבר חזק), רמה 2 (לשעבר חלש) או רמה 1 (לשעבר נוחות) על סמך שיעורי הקבלה שלהם לזיוף ולהתחזות, ועל סמך האבטחה של צינור עיבוד הנתונים הביומטרי. הסיווג הזה קובע את היכולות של החיישן הביומטרי ליצירת ממשק עם הפלטפורמה ועם אפליקציות של צד שלישי. חיישנים מסווגים כברירת מחדל כסוג 1, וצריך לעמוד בדרישות נוספות שמפורטות בהמשך כדי לסווג אותם כסוג 2 או כסוג 3. למידע ביומטרי ברמה 2 ולמידע ביומטרי ברמה 3 יש יכולות נוספות, כפי שמפורט בהמשך.

אם הטמעות במכשיר מאפשרות לחיישן ביומטרי להיות זמין לאפליקציות צד שלישי דרך android.hardware.biometrics.BiometricManager,‏ android.hardware.biometrics.BiometricPrompt ו-android.provider.Settings.ACTION_BIOMETRIC_ENROLL, הן:

  • [C-4-1] חייב לעמוד בדרישות למזהה ביומטרי מסוג Class 3 או Class 2 כפי שהן מוגדרות במסמך הזה.
  • [C-4-2] חובה לזהות ולכבד כל שם פרמטר שמוגדר כקבוע במחלקה Authenticators וכל שילוב שלהם. לעומת זאת, אסור להכיר או לכבד קבועים שלמים שמועברים לשיטות canAuthenticate(int) ו-setAllowedAuthenticators(int) מלבד אלה שמתועדים כקבועים ציבוריים ב-Authenticators וכל שילוב שלהם.
  • [C-4-3] חובה להטמיע את הפעולה ACTION_BIOMETRIC_ENROLL במכשירים עם מידע ביומטרי מסוג Class 3 או Class 2. הפעולה הזו חייבת להציג רק את נקודות הכניסה להרשמה לזיהוי ביומטרי מסוג Class 3 או Class 2.

אם הטמעות במכשירים תומכות בביומטריה פסיבית, הן:

  • [C-5-1] חובה לדרוש כברירת מחדל שלב אישור נוסף (למשל, לחיצה על לחצן).
  • [C-SR-1] מומלץ מאוד להגדיר אפשרות שמאפשרת למשתמשים לשנות את ההעדפות של האפליקציה, ותמיד לדרוש שלב אישור.
  • [C-SR-2] מומלץ מאוד לאבטח את פעולת האישור כך שלא ניתן יהיה לזייף אותה כתוצאה מפריצה למערכת ההפעלה או לליבה. לדוגמה, המשמעות היא שפעולת האישור שמבוססת על לחצן פיזי מנותבת דרך פין קלט/פלט (GPIO) למטרות כלליות (I/O) של רכיב מאובטח (SE) שלא ניתן להפעיל באמצעים אחרים מלבד לחיצה על לחצן פיזי.
  • [C-5-2] חובה להטמיע בנוסף תהליך אימות משתמע (ללא שלב אישור) שתואם ל-setConfirmationRequired(boolean), שאפשר להגדיר באפליקציות כדי להשתמש בו בתהליכי כניסה.

אם יש במכשירים כמה חיישנים ביומטריים, הם:

  • [C-SR-3] מומלץ מאוד לדרוש אישור של רק מאפיין ביומטרי אחד לכל אימות (למשל, אם חיישני טביעות האצבע וזיהוי הפנים זמינים במכשיר, צריך לשלוח את onAuthenticationSucceeded אחרי אישור של אחד מהם).

כדי שהטמעות במכשירים יאפשרו לאפליקציות של צד שלישי לגשת למפתחות של מאגר המפתחות, הן צריכות:

  • [C-6-1] חייב לעמוד בדרישות של Class 3 כפי שמוגדרות בקטע הזה בהמשך.
  • [C-6-2] חובה להציג רק מידע ביומטרי מסוג Class 3 כשהאימות מחייב BIOMETRIC_STRONG, או כשהאימות מופעל באמצעות CryptoObject.

אם רוצים להתייחס לחיישן ביומטרי כסוג 1 (לשעבר נוחות) בהטמעות של המכשיר, צריך:

  • [C-1-1] שיעור האישור השגוי חייב להיות קטן מ-0.002%.
  • [C-1-2] חובה לציין שהמצב הזה עשוי להיות פחות מאובטח מקוד אימות, מקו ביטול נעילה או מסיסמה חזקה, ולפרט בבירור את הסיכונים שבהפעלה שלו, אם שיעורי הקבלה של התחזות וזיופים גבוהים מ-7%, כפי שנמדד לפי פרוטוקולי הבדיקה של Android Biometrics.
  • [C-1-9] חובה לבקש מהמשתמש לבצע את האימות הראשי המומלץ (למשל, קוד אימות, דפוס, סיסמה) אחרי לא יותר מ-20 ניסיונות כושלים ולא פחות מ-90 שניות של זמן המתנה לאימות ביומטרי – כאשר ניסיון כוש הוא ניסיון באיכות צילום מספקת (BIOMETRIC_ACQUIRED_GOOD) שלא תואם למידע הביומטרי הרשום.
  • [C-SR-4] מומלץ מאוד להקטין את המספר הכולל של ניסיונות כוזבים לאימות ביומטרי שצוין בקטע [C-1-9] אם שיעורי הקבלה של התחזות וזיופים גבוהים מ-7%, כפי שנמדד לפי פרוטוקולי הבדיקה של Android Biometrics.
  • [C-1-3] חובה להגביל את מספר הניסיונות לאימות ביומטרי – ניסיון שקרי הוא ניסיון באיכות צילום מספקת (BIOMETRIC_ACQUIRED_GOOD) שלא תואם לנתונים הביומטריים הרשומים.
  • [C-SR-5] מומלץ מאוד להגביל את מספר הניסיונות ל-30 שניות לפחות אחרי 5 ניסיונות כושלים לאימות ביומטרי, עד למספר המקסימלי של ניסיונות כושלים לכל [C-1-9] – כאשר ניסיון כושל הוא ניסיון באיכות צילום מספקת (BIOMETRIC_ACQUIRED_GOOD) שלא תואם לנתונים הביומטריים הרשומים.
  • [C-SR-6] מומלץ מאוד להעביר את כל הלוגיקה של הגבלת הקצב ל-TEE.
  • [C-1-10] חובה להשבית את האימות הביומטרי אחרי שההשהיה של האימות הראשי מופעלת בפעם הראשונה, כפי שמתואר בקטע [C-0-2] בקטע 9.11.
  • [C-1-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 מגרסה 9 ואילך, או ב) פעם ב-72 שעות או פחות במכשירים ששודרגו מ-Android מגרסה 8 ואילך.

  • [C-1-8] חובה לבקש מהמשתמש לבצע את האימות הראשי המומלץ (למשל: קוד אימות, קו ביטול נעילה, סיסמה) או אימות ביומטרי ברמה 3 (חזק) לאחר אחד מהאירועים הבאים:

    • זמן קצוב לתפוגה של 4 שעות לפעילות לא פעילה, או

    • 3 ניסיונות כושלים לביצוע אימות ביומטרי.

  • [C-SR-7] מומלץ מאוד להשתמש בלוגיקה של המסגרת שסופקו על ידי Android Open Source Project כדי לאכוף את האילוצים שצוינו ב-[C-1-7] וב-[C-1-8] במכשירים חדשים.

  • [C-SR-8] מומלץ מאוד שהשיעור של דחייה שגויה יהיה קטן מ-10%, כפי שנמדד במכשיר.

  • [C-SR-9] מומלץ מאוד שהזמן עד לתגובה (latency) יהיה פחות משנייה, נמדד מהרגע שבו מתבצע זיהוי הביומטרי ועד שהמסך נפתח, לכל שיטה ביומטרית רשומה.

אם רוצים להתייחס לחיישן ביומטרי כסוג 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. מכשירים ששודרגו מגרסה 9 ואילך של Android לא פטורים מ-C-2-7.

  • [C-2-8] חייב להיות צינור עיבוד נתונים מאובטח, כך שפגיעה במערכת ההפעלה או בליבה לא תאפשר להחדיר נתונים ישירות כדי לבצע אימות כוזב של המשתמש.

  • [C-SR-10] מומלץ מאוד לכלול זיהוי חיים בכל שיטות הזיהוי הביומטרי וזיהוי תשומת לב לזיהוי ביומטרי של פנים.

  • [C-2-9] חובה להפוך את החיישן הביומטרי לזמין לאפליקציות של צד שלישי.

אם רוצים להתייחס לחישן ביומטרי כסוג 3 (לשעבר חזק) בהטמעות של המכשיר, צריך:

  • [C-3-1] חייב לעמוד בכל הדרישות של סיווג 2 שלמעלה, מלבד [C-1-7] ו-[C-1-8].
  • [C-3-2] חובה להטמיע מאגר מפתחות שמגובים בחומרה.
  • [C-3-3] שיעור האישור של התחזות וזיופים חייב להיות לא יותר מ-7%, כפי שנמדד לפי פרוטוקולי הבדיקה של Android Biometrics.
  • [C-3-4] חובה לאתגר את המשתמש לבצע את האימות הראשי המומלץ (למשל, קוד אימות, קו ביטול נעילה, סיסמה) פעם ב-72 שעות או פחות.
  • [C-3-5] חובה ליצור מחדש את מזהה המאמת לכל אמצעי אימות ביומטרי מסוג 3 שנתמכים במכשיר, אם אחד מהם נרשם מחדש.
  • [C-3-6] חובה להפעיל מפתחות של מאגר מפתחות שמגובים בביומטריה לאפליקציות של צד שלישי.

אם הטמעות במכשירים מכילות חיישן טביעות אצבע שמתחת למסך (UDFPS), הן:

  • [C-SR-11] מומלץ מאוד למנוע מהאזור הניתן למגע של UDFPS להפריע לניווט באמצעות 3 לחצנים (שחלק מהמשתמשים עשויים להזדקק לו למטרות נגישות).

7.3.12. חיישן תנוחה

הטמעות במכשירים:

  • יכול להיות שתהיה תמיכה בחיישן תנוחה עם 6 דרגות חופש.

אם הטמעות במכשירים תומכות בחיישן תנוחה עם 6 דרגות חופש, הן:

  • [C-1-1] חובה להטמיע את החיישן TYPE_POSE_6DOF ולדווח עליו.
  • [C-1-2] חייב להיות מדויק יותר מאשר וקטור הסיבוב בלבד.

7.3.13. חיישן זווית ציר

אם הטמעות במכשירים תומכות בחיישן של זווית ציר, הן:

7.4. קישוריות נתונים

7.4.1. טלפוניה

המונח 'טלפוניה', כפי שהוא מופיע בממשקי ה-API של Android ובמסמך הזה, מתייחס באופן ספציפי לחומרה שקשורה לביצוע שיחות קוליות ושליחת הודעות SMS דרך רשת GSM או CDMA. יכול להיות שהשיחות הקוליות האלה יתבצעו באמצעות מעבר חבילות (packet-switched) ויכול להיות שלא, אבל לצורכי Android הן נחשבות כבלתי תלויות בחיבור נתונים שעשוי להיות מיושם באמצעות אותה רשת. במילים אחרות, הפונקציות וממשקי ה-API של 'טלפוניה' ב-Android מתייחסים באופן ספציפי לשיחות קוליות ולהודעות SMS. לדוגמה, הטמעות של מכשירים שלא ניתן לבצע בהן שיחות או לשלוח/לקבל הודעות SMS לא נחשבות למכשירי טלפוניה, גם אם הן משתמשות ברשת סלולרית לחיבור נתונים.

  • אפשר להשתמש ב-Android במכשירים שלא כוללים חומרה של טלפוניה. כלומר, Android תואם למכשירים שאינם טלפונים.

אם הטמעות המכשירים כוללות טלפון GSM או CDMA, הן:

  • [C-1-1] חובה להצהיר על ה-feature flag android.hardware.telephony ועל סמנים אחרים של תכונות משנה בהתאם לטכנולוגיה.
  • [C-1-2] חובה להטמיע תמיכה מלאה ב-API של הטכנולוגיה הזו.
  • צריך לאפשר את כל סוגי השירות הסלולרי הזמינים (2G,‏ 3G,‏ 4G,‏ 5G וכו') במהלך שיחות חירום (ללא קשר לסוגים של הרשתות שמוגדרים על ידי SetAllowedNetworkTypeBitmap()).

אם הטמעות במכשירים לא כוללות חומרה של טלפוניה, הן:

  • [C-2-1] חובה להטמיע את ממשקי ה-API המלאים כ-no-ops.

אם הטמעות במכשירים תומכות ב-eUICC או ב-eSIM/SIM מוטמע, וכוללות מנגנון קנייני שמאפשר למפתחים של צד שלישי להשתמש בפונקציות של eSIM, הן:

אם הטמעות במכשירים לא מגדירות את מאפיין המערכת ro.telephony.iwlan\_operation\_mode לערך 'קודם', הן:

אם הטמעות המכשירים תומכות ברישום יחיד של IMS (מערכות משנה של מולטימדיה ב-IP) גם לשירותי טלפוניה מולטימדיה (MMTEL) וגם לתכונות של שירותי תקשורת מגוונים (RCS), והן צפויות לעמוד בדרישות של ספק הסלולר בנוגע לשימוש ברישום יחיד של IMS לכל תעבורת האותות של IMS, הן:

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-1] מומלץ מאוד להודיע למשתמש שהשיחה הנוכחית תבוטל אם יענה לשיחה נכנסת.

    ההטמעה ב-AOSP עומדת בדרישות האלה באמצעות התראה מראש שמציינת למשתמש שהשיחה הנכנסת תגרום לניתוק השיחה השנייה.

  • [C-SR-1] מומלץ מאוד לטעון מראש את אפליקציית החיוג שמוגדרת כברירת מחדל, שמציגה רשומה ביומן השיחות ואת השם של אפליקציה של צד שלישי ביומן השיחות שלה, כשהאפליקציה של הצד השלישי מגדירה את המפתח הנוסף EXTRA_LOG_SELF_MANAGED_CALLS ב-PhoneAccount ל-true.

  • [C-SR-2] מומלץ מאוד לטפל באירועים 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 הפעיל כרגע, שמשמש כברירת מחדל לתנועת האפליקציה ומוחזר על ידי methods של ה-API‏ ConnectivityManager כמו getActiveNetwork ו-registerDefaultNetworkCallback. במילים אחרות, הם עשויים להשבית את הגישה לאינטרנט שמספקת כל ספק רשת אחר (למשל, חבילת גלישה) רק אם הם מצליחים לאמת שרשת ה-Wi-Fi מספקת גישה לאינטרנט.
  • [C-1-6] מומלץ מאוד, כשמתבצעת קריאה לשיטת ה-API‏ ConnectivityManager.reportNetworkConnectivity(), לבדוק מחדש את הגישה לאינטרנט ב-Network. אם לאחר הבדיקה מתברר שה-Network הנוכחי כבר לא מספק גישה לאינטרנט, צריך לעבור לרשת אחרת שזמינה (למשל, נתונים סלולריים) ומספקת גישה לאינטרנט.
  • [C-1-7] חובה ליצור כתובת MAC אקראית של המקור ומספר רצף של מסגרות של בקשות בדיקה, פעם אחת בתחילת כל סריקה, בזמן ש-STA מנותק.
  • [C-1-8] חובה להשתמש בכתובת MAC עקבית אחת (לא צריך לבחור כתובת MAC באופן אקראי באמצע הסריקה).
  • [C-1-9] חובה להפעיל חזרה את מספר הרצף של בקשת הבדיקה באופן רגיל (באופן רציף) בין בקשות הבדיקה בסריקת.
  • [C-1-10] חובה לבצע רנדומיזציה של מספר הרצף של בקשת הבדיקה בין בקשת הבדיקה האחרונה של הסריקה לבין בקשת הבדיקה הראשונה של הסריקה הבאה.
  • [C-SR-1] מומלץ מאוד ליצור כתובת MAC אקראית של המקור שתשמש לכל התקשורת של STA לנקודת גישה (AP) במהלך ההתאמה והשימוש בה.
    • המכשיר חייב להשתמש בכתובת MAC רנדומלית שונה לכל SSID (FQDN ל-Passpoint) שהוא מתקשר איתו.
    • המכשיר חייב לספק למשתמש אפשרות לשלוט בבחירה האקראית לכל SSID (FQDN ל-Passpoint) עם אפשרויות לא אקראיות ואקראיות, וחייב להגדיר את מצב ברירת המחדל של הגדרות Wi-Fi חדשות כבחירה אקראית.
  • [C-SR-2] מומלץ מאוד להשתמש ב-BSSID אקראי לכל נקודת גישה שיוצרים.
    • כתובת ה-MAC חייבת להיות אקראית וקבועה לכל SSID שבו משתמש ה-AP.
    • יכול להיות שהמכשיר יספק למשתמש אפשרות להשבית את התכונה הזו. אם האפשרות הזו קיימת, הרשאה אקראית חייבת להיות מופעלת כברירת מחדל.

אם הטמעות המכשירים כוללות תמיכה במצב חיסכון בחשמל של Wi-Fi כפי שמוגדר בתקן IEEE 802.11, הן:

  • צריך להשבית את מצב חיסכון האנרגיה ב-Wi-Fi בכל פעם שאפליקציה מקבלת את המנעול WIFI_MODE_FULL_HIGH_PERF או את המנעול WIFI_MODE_FULL_LOW_LATENCY דרך ממשקי ה-API של WifiManager.createWifiLock() ו-WifiManager.WifiLock.acquire(), והנעילה פעילה.
  • [C-3-2] זמן האחזור הממוצע הלוך ושוב בין המכשיר לנקודת הגישה כשהמכשיר נמצא במצב Wi-Fi Low Latency Lock‏ (WIFI_MODE_FULL_LOW_LATENCY) חייב להיות קצר יותר מזמן האחזור במצב Wi-Fi High Perf Lock‏ (WIFI_MODE_FULL_HIGH_PERF).
  • [C-SR-3] מומלץ מאוד לצמצם את זמן האחזור הלוך ושוב ב-Wi-Fi בכל פעם שמתבצע נעילה עם זמן אחזור קצר (WIFI_MODE_FULL_LOW_LATENCY) והיא נכנסת לתוקף.

אם הטמעות במכשירים תומכות ב-Wi-Fi ומשתמשות ב-Wi-Fi לסריקה של מיקום, הן:

  • [C-2-1] חובה לספק למשתמש אפשרות להפעיל או להשבית את קריאת הערך באמצעות שיטת ה-API WifiManager.isScanAlwaysAvailable.
7.4.2.1. Wi-Fi ישיר

הטמעות במכשירים:

  • צריכה לכלול תמיכה ב-Wi-Fi Direct (Wi-Fi מקצה לקצה).

אם הטמעות המכשירים כוללות תמיכה ב-Wi-Fi Direct, הן:

  • [C-1-1] חובה להטמיע את Android API התואם כפי שמתואר במסמכי התיעוד של ה-SDK.
  • [C-1-2] חובה לדווח על תכונת החומרה android.hardware.wifi.direct.
  • [C-1-3] חובה לתמוך בתפעול רגיל של Wi-Fi.
  • [C-1-4] חובה לתמוך בו-זמנית בפעולות Wi-Fi ו-Wi-Fi Direct.
  • [C-SR-1] מומלץ מאוד ליצור כתובת MAC אקראית של המקור לכל החיבורים החדשים שנוצרים ב-Wi-Fi Direct.

הטמעות במכשירים:

אם הטמעות המכשירים כוללות תמיכה ב-TDLS ו-TDLS מופעל על ידי WiFiManager API, הן:

  • [C-1-1] חובה להצהיר על תמיכה ב-TDLS דרך WifiManager.isTdlsSupported.
  • מומלץ להשתמש ב-TDLS רק כשהדבר אפשרי ומועיל.
  • צריך להיות שימוש בהיגוריית כלשהי ולא להשתמש ב-TDLS כשהביצועים שלו עשויים להיות גרועים יותר מאשר דרך נקודת הגישה ל-Wi-Fi.
7.4.2.3. 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, ומאפשרות גישה לפונקציונליות הזו לאפליקציות של צד שלישי, הן:

7.4.2.4. Wi-Fi Passpoint

אם הטמעות המכשירים כוללות תמיכה ב-802.11‏ (Wi-Fi), הן:

  • [C-1-1] חובה לכלול תמיכה ב-Wi-Fi Passpoint.
  • [C-1-2] חובה להטמיע את ממשקי ה-API של WifiManager שקשורים ל-Passpoint כפי שמתואר במסמכי התיעוד של ה-SDK.
  • [C-1-3] חובה לתמוך בתקן IEEE 802.11u, שקשור במיוחד לגילוי ולבחירה של רשתות, כמו שירות המודעות הגנריות (GAS) ופרוטוקול השאילתות של רשת הגישה (ANQP).
  • [C-1-4] חובה להצהיר על סימון התכונה android.hardware.wifi.passpoint.
  • [C-1-5] חובה לפעול בהתאם להטמעה של AOSP כדי לזהות רשתות Passpoint, להתאים אליהן ולשייך אותן.
  • [C-1-6] חובה לתמוך לפחות בקבוצת המשנה הבאה של פרוטוקולים להקצאת מכשירים, כפי שהם מוגדרים ב-Wi-Fi Alliance Passpoint R2: אימות EAP-TTLS ו-SOAP-XML.
  • [C-1-7] חובה לעבד את אישור שרת ה-AAA כפי שמתואר במפרט Hotspot 2.0 R3.
  • [C-1-8] חובה לתמוך בשליטת המשתמש בהקצאה דרך הכלי לבחירת רשת Wi-Fi.
  • [C-1-9] חובה לשמור על עקביות בהגדרות של Passpoint במהלך הפעלות מחדש.
  • [C-SR-1] מומלץ מאוד לתמוך בתכונה של אישור התנאים וההגבלות.
  • [C-SR-2] מומלץ מאוד לתמוך בתכונה 'פרטי המקום'.

לעומת זאת, אם הטמעות המכשירים לא כוללות תמיכה ב-Wi-Fi Passpoint:

  • [C-2-1] ההטמעה של ממשקי ה-API של WifiManager שקשורים ל-Passpoint חייבת להוביל להשלכת UnsupportedOperationException.

אם יש מתג בקרה גלובלי של משתמש להשבתת Passpoint, ההטמעות:

  • [C-3-1] חובה להפעיל את Passpoint כברירת מחדל.
7.4.2.5. מיקום Wi-Fi (זמן הלוך ושוב ב-Wi-Fi – RTT)

הטמעות במכשירים:

אם הטמעות במכשירים כוללות תמיכה במיקום לפי Wi-Fi ומציגות את הפונקציונליות לאפליקציות של צד שלישי, הן:

  • [C-1-1] חובה להטמיע את ממשקי ה-API של WifiRttManager כפי שמתואר במסמכי התיעוד של ה-SDK.
  • [C-1-2] חובה להצהיר על דגל התכונה android.hardware.wifi.rtt.
  • [C-1-3] חובה ליצור כתובת MAC אקראית של המקור לכל רצף של הודעות RTT שמתבצע בזמן שממשק ה-Wi-Fi שבו מתבצע ה-RTT לא משויך לנקודת גישה.
  • [C-1-4] חייב להיות מדויק בטווח של 2 מטרים ברוחב פס של 80MHz באחוזון ה-68 (כפי שמחושב באמצעות פונקציית ההתפלגות המצטברת).
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, הן:

7.4.2.7. Wi-Fi Easy Connect (פרוטוקול להקצאת מכשיר)

הטמעות במכשירים:

אם הטמעות במכשירים כוללות תמיכה ב-Wi-Fi Easy Connect ומאפשרות גישה לפונקציונליות באפליקציות של צד שלישי, הן:

7.4.2.8. אימות אישור שרת Wi-Fi לארגון

אם אישור השרת של Wi-Fi לא מאומת או ששם הדומיין של שרת ה-Wi-Fi לא מוגדר, הטמעות המכשיר:

  • [C-SR-1] מומלץ מאוד לא לספק למשתמש אפשרות להוסיף רשת Wi-Fi ארגונית באופן ידני באפליקציית ההגדרות.

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, הן:

אם הטמעות המכשירים כוללות תמיכה ב-Bluetooth או ב-Bluetooth Low Energy, הן:

  • [C-6-1] חובה להגביל את הגישה לכל מטא-נתונים של Bluetooth (כמו תוצאות סריקות) שאפשר להשתמש בהם כדי להסיק את המיקום של המכשיר, אלא אם האפליקציה המבקשת עוברת בהצלחה בדיקת הרשאות android.permission.ACCESS_FINE_LOCATION על סמך המצב הנוכחי שלה בחזית או ברקע.

אם הטמעות במכשירים כוללות תמיכה ב-Bluetooth או ב-Bluetooth Low Energy, והמניפסט של האפליקציה לא כולל הצהרה מהמפתח/ת על כך שהם לא מפיקים מיקום באמצעות Bluetooth, הם:

7.4.4. תקשורת מטווח קצר

הטמעות במכשירים:

  • צריך לכלול משדר-מקלט וחומרה קשורה לתקשורת מטווח קצר (NFC).
  • [C-0-1] חובה להטמיע את ממשקי ה-API android.nfc.NdefMessage ו-android.nfc.NdefRecord גם אם הם לא כוללים תמיכה ב-NFC, או להצהיר על התכונה android.hardware.nfc כי הכיתות מייצגות פורמט של ייצוג נתונים שלא תלוי בפרוטוקול.

אם הטמעות במכשירים כוללות חומרה של NFC ויש כוונה להפוך אותה לזמינה לאפליקציות צד שלישי, צריך:

  • [C-1-1] חובה לדווח על התכונה android.hardware.nfc מה-method‏ android.content.pm.PackageManager.hasSystemFeature().
  • חייבת להיות לו אפשרות לקרוא ולכתוב הודעות NDEF באמצעות תקני ה-NFC הבאים, כפי שמפורט בהמשך:
  • [C-1-2] חייב להיות מסוגל לפעול כקורא/כותב של NFC Forum (כפי שמוגדר במפרט הטכני של NFC Forum,‏ NFCForum-TS-DigitalProtocol-1.0) באמצעות תקני ה-NFC הבאים:
    • NfcA‏ (ISO14443-3A)
    • NfcB‏ (ISO14443-3B)
    • NfcF‏ (JIS X 6319-4)
    • IsoDep‏ (ISO 14443-4)
    • סוגי תגים של NFC Forum‏ 1, 2, 3, 4, 5 (מוגדרים על ידי NFC Forum)

  • [C-SR-1] מומלץ מאוד שיהיו יכולות לקרוא ולכתוב הודעות NDEF וגם נתונים גולמיים באמצעות תקני ה-NFC הבאים. חשוב לזכור שתקני ה-NFC מוגדרים כ'מומלצים מאוד', אבל בהגדרת התאימות של גרסה עתידית הם צפויים להשתנות ל'חובה'. התקנים האלה הם אופציונליים בגרסה הזו, אבל יהיו נדרשים בגרסאות עתידיות. מומלץ מאוד למכשירים קיימים וחדשים עם גרסת Android הזו לעמוד בדרישות האלה כבר עכשיו, כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה.

  • [C-1-13] חובה לבצע סקירה של כל הטכנולוגיות הנתמכות במצב חיפוש של NFC.

  • צריך להיות במצב חשיפת NFC כשהמכשיר פעיל, המסך פעיל ומסך הנעילה לא נעול.

  • אמורה להיות מסוגלת לקרוא את הברקוד ואת כתובת ה-URL (אם היא מקודדת) של מוצרים עם ברקוד NFC דק.

חשוב לדעת: אין קישורים זמינים לכולם למפרטים של JIS,‏ ISO ו-NFC Forum שצוינו למעלה.

מערכת Android כוללת תמיכה במצב NFC Host Card Emulation ‏ (HCE).

אם הטמעות המכשיר כוללות שבב של בקר NFC שיכול לבצע HCE (ל-NfcA ו/או ל-NfcB) ותומך ניתוב של מזהה אפליקציה (AID), הן:

  • [C-2-1] חובה לדווח על קבוע התכונה android.hardware.nfc.hce.
  • [C-2-2] חובה לתמוך בממשקי API של NFC HCE כפי שמוגדרים ב-Android SDK.

אם הטמעות במכשירים כוללות שבב של בקר NFC שיכול להשתמש ב-HCE ל-NfcF, והן מטמיעות את התכונה לאפליקציות של צד שלישי, הן:

אם הטמעות המכשיר כוללות תמיכה כללית ב-NFC כפי שמתואר בקטע הזה, ותמיכה בטכנולוגיות MIFARE‏ (MIFARE Classic,‏ MIFARE Ultralight,‏ NDEF ב-MIFARE Classic) בתפקיד הקורא/הסופר, הן:

  • [C-4-1] חובה להטמיע את ממשקי ה-API התואמים ל-Android כפי שמתואר ב-Android SDK.
  • [C-4-2] חובה לדווח על התכונה com.nxp.mifare מהשיטה android.content.pm.PackageManager.hasSystemFeature(). חשוב לזכור שזו לא תכונה רגילה של Android, ולכן היא לא מופיעה כקבועה בכיתה android.content.pm.PackageManager.

7.4.5. פרוטוקולים וממשקי API של רשתות

7.4.5.1. יכולת רשת מינימלית

הטמעות במכשירים:

  • [C-0-1] חובה לכלול תמיכה באחת או יותר מהצורות של רשתות נתונים. באופן ספציפי, הטמעות במכשירים חייבות לכלול תמיכה לפחות בתקן נתונים אחד שיכול להגיע לקצב של 200Kbit/sec או יותר. דוגמאות לטכנולוגיות שעומדות בדרישות האלה כוללות את EDGE, ‏ HSPA, ‏ EV-DO,‏ 802.11g, ‏ Ethernet ו-Bluetooth PAN.
  • צריכה לכלול גם תמיכה בתקן אחד לפחות של נתונים אלחוטיים נפוצים, כמו 802.11‏ (Wi-Fi), כשתקן הרשתות הפיזי (כמו Ethernet) הוא חיבור הנתונים הראשי.
  • יכולים להטמיע יותר מסוג אחד של קישוריות נתונים.
7.4.5.2. IPv6

הטמעות במכשירים:

  • [C-0-2] חובה לכלול סטאק של רשתות IPv6 ולתמוך בתקשורת IPv6 באמצעות ממשקי ה-API המנוהלים, כמו java.net.Socket ו-java.net.URLConnection, וגם באמצעות ממשקי ה-API המקומיים, כמו שקעים של AF_INET6.
  • [C-0-3] חובה להפעיל את IPv6 כברירת מחדל.
    • חובה לוודא שתקשורת IPv6 אמינה כמו IPv4, לדוגמה:
      • [C-0-4] חובה לשמור על קישוריות IPv6 במצב שינה.
      • [C-0-5] הגבלת הקצב לא מורשית לגרום לאובדן הקישוריות של המכשיר ל-IPv6 בכל רשת שתואמת ל-IPv6 ומשתמשת בטווח חיים של RA של לפחות 180 שניות.
  • [C-0-6] חובה לספק לאפליקציות של צד שלישי קישוריות IPv6 ישירה לרשת כשהן מחוברות לרשת IPv6, ללא כל סוג של תרגום כתובות או יציאות שמתרחש באופן מקומי במכשיר. גם ממשקי API מנוהלים כמו Socket#getLocalAddress או Socket#getLocalPort וגם ממשקי API של NDK כמו getsockname() או IPV6_PKTINFO חייבים להחזיר את כתובת ה-IP והיציאה שבהן נעשה שימוש בפועל לשליחה ולקבלה של חבילות ברשת, וגלויות ככתובת ה-IP והיציאה של המקור בשרתי אינטרנט (אינטרנט).

רמת התמיכה הנדרשת ב-IPv6 תלויה בסוג הרשת, כפי שמפורט בדרישות הבאות.

אם הטמעות המכשירים תומכות ב-Wi-Fi, הן:

  • [C-1-1] חובה לתמוך ב-dual-stack ובפעולה ב-IPv6 בלבד ב-Wi-Fi.

אם הטמעות המכשירים תומכות ב-Ethernet, הן:

  • [C-2-1] חובה לתמוך ב-dual-stack ובפעולה ב-IPv6 בלבד ב-Ethernet.

אם הטמעות במכשירים תומכות בנתונים סלולריים, הן:

  • [C-3-1] חובה לתמוך בפעולה של IPv6 (IPv6 בלבד ואולי גם שתי שכבות) בנייד.

אם הטמעות במכשירים תומכות ביותר מסוג רשת אחד (למשל, Wi-Fi וחבילת גלישה), הם:

  • [C-4-1] חייב לעמוד בו-זמנית בדרישות שלמעלה בכל רשת, כשהמכשיר מחובר בו-זמנית ליותר מסוג רשת אחד.
7.4.5.3. פורטלים שבויים

פורטל שבוי הוא רשת שדרושה בה כניסה לחשבון כדי לקבל גישה לאינטרנט.

אם הטמעות במכשירים מספקות הטמעה מלאה של android.webkit.Webview API, הן:

  • [C-1-1] חובה לספק אפליקציית פורטל חובה כדי לטפל בכוונה ACTION_CAPTIVE_PORTAL_SIGN_IN ולהציג את דף ההתחברות לפורטל החובה, על ידי שליחת הכוונה הזו בקריאה ל-System API‏ ConnectivityManager#startCaptivePortalApp(Network, Bundle).
  • [C-1-2] חובה לבצע זיהוי של פורטלים שבהם נדרש אישור כניסה (captive portal) ולתמוך בכניסה דרך אפליקציית הפורטל שבהם נדרש אישור כניסה כשהמכשיר מחובר לכל סוג רשת, כולל רשת סלולרית/ניידת, Wi-Fi, ‏ Ethernet או Bluetooth.
  • [C-1-3] חובה לתמוך בכניסה לפורטלים שבהם נדרש אישור כדי להשתמש ב-DNS בטקסט ללא הצפנה, כשהמכשיר מוגדר לשימוש במצב קפדני של DNS פרטי.
  • [C-1-4] חובה להשתמש ב-DNS מוצפן בהתאם למסמכי התיעוד של ה-SDK עבור android.net.LinkProperties.getPrivateDnsServerName ו-android.net.LinkProperties.isPrivateDnsActive לכל תעבורת הנתונים ברשת שלא מתקשרת באופן מפורש עם הפורטל השבוי.
  • [C-1-5] חובה לוודא שבזמן שהמשתמש מתחבר לפורטל שבוי, רשת ברירת המחדל שבה משתמשות האפליקציות (כפי שמוחזרת על ידי ConnectivityManager.getActiveNetwork,‏ ConnectivityManager.registerDefaultNetworkCallback, ושיושמת כברירת מחדל על ידי ממשקי API של רשתות Java כמו java.net.Socket וממשקי API מקומיים כמו connect()) היא כל רשת זמינה אחרת שמספקת גישה לאינטרנט, אם יש כזו.

7.4.6. הגדרות סנכרון

הטמעות במכשירים:

  • [C-0-1] ההגדרה של הסנכרון האוטומטי הראשי חייבת להיות מופעלת כברירת מחדל, כדי שהשיטה getMasterSyncAutomatically() תחזיר את הערך 'true'.

7.4.7. חסכונית בנתונים

אם הטמעות במכשירים כוללות חיבור למדוד, הן:

  • [C-SR-1] מומלץ מאוד לספק את מצב חיסכון בחבילת הגלישה.

אם הטמעות במכשירים מספקות את מצב חיסכון הנתונים, הן:

אם הטמעות במכשירים לא מספקות את מצב חיסכון הנתונים, הן:

7.4.8. רכיבים מאובטחים

אם הטמעות במכשירים תומכות ברכיבים מאובטחים שתואמים ל-Open Mobile API ומאפשרות להשתמש בהם באפליקציות של צד שלישי, הן:

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) אופקית ביחס לכיוון שצוין על ידי האפליקציה, אם האפליקציה הנוכחית ביקשה במפורש שצילום המצלמה יוזז באמצעות קריאה ל-method‏ android.hardware.Camera.setDisplayOrientation(). לעומת זאת, אם האפליקציה הנוכחית לא מבקשת במפורש לבצע סיבוב של מסך המצלמה באמצעות קריאה ל-method‏ android.hardware.Camera.setDisplayOrientation(), חובה לבצע היפוך מראה של התצוגה המקדימה לפי ציר האופק שמוגדר כברירת מחדל במכשיר.
  • [C-1-5] אסור לשקף את התמונות הסטטיות או את הסטרימינג הסופי של הסרטונים שצולמו, שמוחזרים להודעות החזרה (callbacks) של האפליקציה או מועברים לאחסון מדיה.
  • [C-1-6] חובה לשקף את התמונה שמוצגת על ידי התצוגה המקדימה באותו אופן שבו מוצג זרם התמונות של תצוגה המקדימה במצלמה.
  • יכולות לכלול תכונות (כמו פוקוס אוטומטי, פלאש וכו') שזמינות למצלמות הפונות לאחור, כפי שמתואר בסעיף 7.5.1.

אם הטמעות במכשירים יכולות להסתובב על ידי המשתמש (למשל באופן אוטומטי באמצעות תאוצה או באופן ידני באמצעות קלט של המשתמש):

  • [C-2-1] חובה להציג את התצוגה המקדימה של המצלמה בהיפוך אופקית ביחס לכיוון הנוכחי של המכשיר.

7.5.3. מצלמה חיצונית

הטמעות במכשירים:

  • יכול להיות שתהיה תמיכה במצלמה חיצונית שלא תמיד מחוברת.

אם הטמעות במכשירים כוללות תמיכה במצלמה חיצונית, הן:

  • [C-1-1] חובה להצהיר על דגל התכונה של הפלטפורמה android.hardware.camera.external ו-android.hardware camera.any.
  • [C-1-2] חובה לתמוך ב-USB Video Class‏ (UVC 1.0 ואילך) אם המצלמה החיצונית מחוברת דרך יציאת המארח של ה-USB.
  • [C-1-3] חובה לעבור את בדיקות ה-CTS של המצלמה עם מצלמה חיצונית פיזית מחוברת. פרטים על בדיקות CTS של מצלמות זמינים בכתובת source.android.com.
  • צריך לתמוך בדחיסת וידאו כמו MJPEG כדי לאפשר העברה של שידורים באיכות גבוהה ללא קידוד (כלומר שידורי תמונות גולמיים או דחוסים בנפרד).
  • יכול להיות שתהיה תמיכה במספר מצלמות.
  • יכול להיות שתהיה תמיכה בקידוד וידאו מבוסס-מצלמה.

אם יש תמיכה בקידוד וידאו מבוסס-מצלמה:

  • [C-2-1] חייבת להיות גישה להזרמה בו-זמנית של MJPEG או של וידאו ללא קידוד (ברזולוציה QVGA ומעלה) להטמעה במכשיר.

7.5.4. התנהגות Camera API

Android כולל שתי חבילות API לגישה למצלמה. ה-API החדש יותר, android.hardware.camera2, חושף לאפליקציה אמצעי בקרה ברמה נמוכה יותר של המצלמה, כולל תהליכי סטרימינג או התפרצות יעילים ללא העתקה (zero-copy) ואמצעי בקרה לכל פריים של חשיפת התמונה, הגברה, שיפור של איזון הלבן, המרת צבעים, הסרת רעשי רקע, חידוד ועוד.

חבילת ה-API הישנה יותר, android.hardware.Camera, מסומנת כמיושנת ב-Android 5.0, אבל היא עדיין אמורה להיות זמינה לשימוש באפליקציות. בהטמעות של מכשירי Android, חובה להבטיח את התמיכה המתמשכת ב-API כפי שמתואר בקטע הזה וב-Android SDK.

לכל התכונות המשותפות בין הכיתה android.hardware.Camera שנמצאת בשימוש מצומצם לבין החבילה החדשה יותר android.hardware.camera2, חייבים להיות ביצועים ואיכות זהים בשני ממשקי ה-API. לדוגמה, בהגדרות מקבילות, המהירות והדיוק של המיקוד האוטומטי חייבים להיות זהים, ואיכות התמונות שצולמו חייבת להיות זהה. אין דרישה שהתכונות שתלויות בסמינטיקה השונה של שני ממשקי ה-API יהיו בעלות מהירות או איכות זהות, אבל הן צריכות להיות דומות ככל האפשר.

הטמעות של מכשירים חייבות ליישם את ההתנהגויות הבאות לממשקי ה-API שקשורים למצלמה, לכל המצלמות הזמינות. הטמעות במכשירים:

  • [C-0-1] חובה להשתמש ב-android.hardware.PixelFormat.YCbCr_420_SP לנתוני תצוגה מקדימה שסופקו להחזרות קריאה (callbacks) של אפליקציות, כשאף אפליקציה לא התקשרה ל-android.hardware.Camera.Parameters.setPreviewFormat(int).
  • [C-0-2] בנוסף, הנתונים חייבים להיות בפורמט הקידוד NV21 כשאפליקציה רושמת מופע android.hardware.Camera.PreviewCallback והמערכת קוראת לשיטה onPreviewFrame() ופורמט התצוגה המקדימה הוא YCbCr_420_SP, הנתונים ב-byte[] מועברים אל onPreviewFrame(). כלומר, NV21 חייב להיות ברירת המחדל.
  • [C-0-3] חובה לתמוך בפורמט YV12 (כפי שמצוין בערך הקבוע android.graphics.ImageFormat.YV12) לתצוגות המקדימה של המצלמה, גם במצלמה הקדמית וגם במצלמה האחורית של android.hardware.Camera. (קודק הווידאו והמצלמה של החומרה יכולים להשתמש בכל פורמט פיקסלים מקורי, אבל ההטמעה במכשיר חייבת לתמוך בהמרה ל-YV12).
  • [C-0-4] חובה לתמוך בפורמטים android.hardware.ImageFormat.YUV_420_888 ו-android.hardware.ImageFormat.JPEG כפלט באמצעות ה-API של android.media.ImageReader במכשירי android.hardware.camera2 שמפרסמים את היכולת REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE ב-android.request.availableCapabilities.
  • [C-0-5] חובה להטמיע את Camera API המלא שכלול במסמכי התיעוד של Android SDK, גם אם המכשיר כולל פוקוס אוטומטי בחומרה או יכולות אחרות. לדוגמה, מצלמות ללא פוקוס אוטומטי עדיין חייבות לקרוא לכל המכונות הרשמות של android.hardware.Camera.AutoFocusCallback (למרות שאין לכך רלוונטיות למצלמה ללא פוקוס אוטומטי). שימו לב שהדבר רלוונטי גם למצלמות קדמיות. לדוגמה, למרות שרוב המצלמות הקדמיות לא תומכות בפוקוס אוטומטי, עדיין צריך 'לזייף' את קריאות החזרה (callbacks) של ה-API כפי שמתואר.
  • [C-0-6] חובה לזהות ולכבד כל שם פרמטר שמוגדר כקבוע בכיתה android.hardware.Camera.Parameters ובכיתה android.hardware.camera2.CaptureRequest. לעומת זאת, בהטמעות של מכשירים אסור להכיר או לכבד קבועים של מחרוזות שמועברים ל-method‏ android.hardware.Camera.setParameters(), מלבד אלה שמתועדים כקבועים ב-android.hardware.Camera.Parameters. כלומר, הטמעות במכשירים חייבות לתמוך בכל הפרמטרים הרגילים של המצלמה, אם החומרה מאפשרת זאת, ואסור להן לתמוך בסוגי פרמטרים מותאמים אישית של מצלמה. לדוגמה, הטמעות של מכשירים שתומכות בצילומי תמונות באמצעות שיטות צילום עם טווח דינמי גבוה (HDR) חייבות לתמוך בפרמטר המצלמה Camera.SCENE_MODE_HDR.
  • [C-0-7] חובה לדווח על רמת התמיכה המתאימה באמצעות המאפיין android.info.supportedHardwareLevel כפי שמתואר ב-Android SDK, ולדווח על דגלים מתאימים של תכונות מסגרת.
  • [C-0-8] חובה גם להצהיר על יכולות המצלמה הנפרדות של android.hardware.camera2 באמצעות המאפיין android.request.availableCapabilities ולהצהיר על דגלים מתאימים של תכונות. חובה להגדיר את דגל התכונה אם אחד ממכשירי המצלמה המצורפים תומך בתכונה.
  • [C-0-9] חובה לשדר את הכוונה Camera.ACTION_NEW_PICTURE בכל פעם שצולמת תמונה חדשה במצלמה והרשומה של התמונה נוספה למאגר המדיה.
  • [C-0-10] חובה לשדר את הכוונה Camera.ACTION_NEW_VIDEO בכל פעם שמצלמים סרטון חדש במצלמה והתמונה נוספה למאגר המדיה.
  • [C-0-11] חובה שכל המצלמות יהיו נגישות דרך ממשק ה-API הישן android.hardware.Camera, וגם דרך ממשק ה-API android.hardware.camera2.
  • [C-0-12] חובה לוודא שלא מתבצע שינוי במראה הפנים, כולל, בין היתר, שינוי בגיאומטריה של הפנים, בגוון העור של הפנים או בשיפור העור של הפנים בכל ממשק API של android.hardware.camera2 או של android.hardware.Camera.
  • [C-SR-1] במכשירים עם כמה מצלמות RGB הפונות לאותו כיוון, מומלץ מאוד לתמוך במכשיר מצלמה לוגי שמציג את היכולת CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, שמורכב מכל מצלמות ה-RGB הפונות לאותו כיוון כמכשירי משנה פיזיים.

אם הטמעות במכשירים מספקות ממשק API למצלמה קנייני לאפליקציות של צד שלישי, הן:

7.5.5. כיוון המצלמה

אם להטמעות במכשירים יש מצלמה קדמית או אחורית, המצלמות האלה:

  • [C-1-1] חייבת להיות בכיוון שבו המידה הארוכה של המצלמה תואמת למידה הארוכה של המסך. כלומר, כשהמכשיר מוחזק בפריסה לרוחב, המצלמות חייבות לצלם תמונות בפריסה לרוחב. הכלל הזה חל ללא קשר לכיוון הטבעי של המכשיר, כלומר הוא חל גם על מכשירים עם כיוון אופקי ראשי וגם על מכשירים עם כיוון אנכי ראשי.

מכשירי טלוויזיה שעומדים בכל הקריטריונים הבאים פטורים מהדרישה שלמעלה:

  • המכשיר כולל מסכים עם גיאומטריה משתנה, כמו מסכים מתקפלים או מסכים עם ציר.
  • כשמצב הצירוף או ציר המכשיר משתנה, המכשיר עובר בין המצבים 'לאורך' ל'לרוחב' (או להפך).

7.6. זיכרון ואחסון

7.6.1. נפח זיכרון ואחסון מינימלי

הטמעות במכשירים:

  • [C-0-1] חובה לכלול מנהל הורדות שאפליקציות יכולות להשתמש בו כדי להוריד קבצי נתונים, והוא חייב להיות מסוגל להוריד קבצים נפרדים בגודל של לפחות 100MB למיקום ברירת המחדל 'מטמון'.

7.6.2. אחסון משותף של אפליקציות

הטמעות במכשירים:

  • [C-0-1] חובה להציע אחסון שאפשר לשתף עם אפליקציות, שנקרא גם "אחסון חיצוני משותף", "אחסון משותף של אפליקציות" או לפי הנתיב ב-Linux‏ ‎ "/sdcard" שאליו הוא מחובר.
  • [C-0-2] חובה להגדיר אחסון משותף שמחובר כברירת מחדל, כלומר "מחוץ לקופסה", ללא קשר לאופן שבו האחסון מיושם – ברכיב אחסון פנימי או באמצעי אחסון נשלף (למשל, חריץ לכרטיס דיגיטלי מאובטח).
  • [C-0-3] חובה לחבר את האחסון המשותף של האפליקציה ישירות לנתיב Linux‏ sdcard או לכלול קישור סימבולי של Linux מ-sdcard לנקודת החיבור בפועל.
  • [C-0-4] חובה להפעיל את אחסון מוגבל כברירת מחדל בכל האפליקציות שמטרגטות רמת API 29 ואילך, מלבד במצב הבא:
    • כשהאפליקציה ביקשה את android:requestLegacyExternalStorage="true" במניפסט שלה.
  • [C-0-5] חובה לצנזר מטא-נתונים של מיקום, כמו תגי Exif של GPS, שמאוחסנים בקובצי מדיה כשמתבצעת גישה לקבצים האלה דרך MediaStore, אלא אם לאפליקציה הקוראת יש את ההרשאה ACCESS_MEDIA_LOCATION.

הטמעות של מכשירים יכולות לעמוד בדרישות שלמעלה באמצעות אחת מהאפשרויות הבאות:

  • אחסון נשלף שזמין למשתמש, כמו חריץ לכרטיס Secure Digital‏ (SD).
  • חלק מהאחסון הפנימי (לא ניתן להסרה) כפי שהוא מיושם בפרויקט Android Open Source Project‏ (AOSP).

אם הטמעות במכשירים משתמשות באחסון נשלף כדי לעמוד בדרישות שלמעלה, הן:

  • [C-1-1] חובה להטמיע ממשק משתמש של הודעה קופצת או הודעה קבועה (toast) כדי להזהיר את המשתמש כשאין אמצעי אחסון מוכנס לחריץ.
  • [C-1-2] חובה לכלול אמצעי אחסון בפורמט FAT (למשל כרטיס SD) או לציין על הקופסה ועל חומרים אחרים שזמינים בזמן הרכישה שצריך לרכוש את אמצעי האחסון בנפרד.

אם הטמעות במכשירים משתמשות בחלק מהאחסון שאינו ניתן להסרה כדי לעמוד בדרישות שלמעלה, הן:

  • צריך להשתמש בהטמעה של AOSP לאחסון המשותף של האפליקציה הפנימית.
  • יכולה לשתף את נפח האחסון עם הנתונים הפרטיים של האפליקציה.

אם להטמעות של המכשירים יש יציאת USB עם תמיכה במצב USB ציוד היקפי, הן:

  • [C-3-1] חובה לספק מנגנון לגישה לנתונים באחסון המשותף של האפליקציה ממחשב מארח.
  • צריך לחשוף תוכן משני נתיבי האחסון באופן שקוף באמצעות שירות סורק המדיה של Android ו-android.provider.MediaStore.
  • אפשר להשתמש באחסון בנפח גדול ב-USB, אבל מומלץ להשתמש בפרוטוקול העברת מדיה כדי לעמוד בדרישות.

אם להטמעות של המכשירים יש יציאת USB במצב USB ציוד היקפי ותמיכה ב-Media Transfer Protocol, הן:

  • צריכה להיות תואמת למארח ה-MTP של Android לדוגמה, Android File Transfer.
  • צריך לדווח על סוג מכשיר USB של 0x00.
  • צריך לדווח על שם ממשק USB של 'MTP'.

7.6.3. Adoptable Storage

אם המכשיר צפוי להיות נייד, בניגוד לטלוויזיה, הטמעות המכשיר הן:

  • [C-SR-1] מומלץ מאוד להטמיע את האחסון שניתן לאמץ במיקום יציב לטווח ארוך, כי ניתוק בטעות עלול לגרום לאובדן או לפגיעה בנתונים.

אם היציאה של מכשיר האחסון הנשלף נמצאת במיקום יציב לטווח ארוך, למשל בתא הסוללה או במכסה מגן אחר, הטמעות המכשיר הן:

7.7. USB

אם להטמעות של המכשירים יש יציאת USB, הן:

  • צריכה להיות תמיכה במצב ציוד היקפי USB ובמצב מארח USB.
  • צריכה להיות תמיכה בהשבתה של איתות נתונים דרך USB.

7.7.1. מצב ציוד היקפי ב-USB

אם הטמעות המכשירים כוללות יציאת USB שתומכת במצב ציוד היקפי:

  • [C-1-1] חובה שאפשר יהיה לחבר את היציאה למארח USB עם יציאת USB רגילה מסוג A או מסוג C.
  • [C-1-2] חובה לדווח על הערך הנכון של iSerialNumber בתיאור ההתקן הסטנדרטי של USB דרך android.os.Build.SERIAL.
  • [C-1-3] חובה לזהות מטענים של 1.5A ו-3.0A בהתאם לתקן הנגדים של Type-C, וחובה לזהות שינויים במודעה אם הם תומכים ב-USB Type-C.
  • [C-SR-1] היציאה אמורה להיות בפורמט USB מסוג micro-B, ‏ micro-AB או Type-C. מומלץ מאוד שכל מכשירי Android הקיימים והחדשים יעמדו בדרישות האלה כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה.
  • [C-SR-2] היציאה אמורה להיות ממוקמת בחלק התחתון של המכשיר (בהתאם לכיוון הטבעי) או להפעיל סיבוב מסך בתוכנה לכל האפליקציות (כולל מסך הבית), כדי שהמסך יוצג בצורה נכונה כשהמכשיר מונח כך שהיציאה נמצאת בחלק התחתון. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה, כדי שיוכלו לשדרג לגרסאות עתידיות של הפלטפורמה.
  • [C-SR-3] צריך להטמיע תמיכה בזרם של 1.5A במהלך תנועה וצפצוף HS, כפי שמפורט במפרט טעינה של סוללות USB, גרסה 1.2. מומלץ מאוד שכל מכשירי Android הקיימים והחדשים יעמדו בדרישות האלה כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה.
  • [C-SR-4] מומלץ מאוד לא לתמוך בשיטות טעינה קנייניות שמשנה את המתח של Vbus מעבר לרמות ברירת המחדל, או לשנות את התפקידים של מקור או נקודת קצה, כי הן עלולות לגרום לבעיות בתאימות עם מטענים או מכשירים שתומכים בשיטות הסטנדרטיות של USB Power Delivery. אמנם ההמלצה היא 'מומלץ מאוד', אבל בגרסאות עתידיות של Android יכול להיות שנדרוש שכל המכשירים עם חיבור Type-C יתמכו בתאימות מלאה לטעינה באמצעות מטענים רגילים עם חיבור Type-C.
  • [C-SR-5] מומלץ מאוד לתמוך ב-Power Delivery לנתונים ולהחלפת תפקידים של מתח כשיש תמיכה ב-USB Type-C ובמצב מארח USB.
  • צריכה להיות תמיכה ב-Power Delivery לטעינה במתח גבוה ותמיכה במצבים חלופיים, כמו Display Out.
  • צריך להטמיע את המפרט ואת ה-API של Android Open Accessory‏ (AOA) כפי שמתואר במסמכי התיעוד של Android SDK.

אם הטמעות של מכשירים כוללות יציאת USB ומטמיעות את מפרט AOA, הן:

  • [C-2-1] חובה להצהיר על תמיכה בתכונה החומרה android.hardware.usb.accessory.
  • [C-2-2] הכיתה של אחסון בנפח גדול ב-USB חייבת לכלול את המחרוזת 'android' בסוף המחרוזת iInterface של תיאור הממשק של אחסון בנפח גדול ב-USB

7.7.2. מצב מארח USB

אם הטמעות המכשירים כוללות יציאת USB שתומכת במצב מארח, הן:

  • [C-1-1] חובה להטמיע את Android USB host API כפי שמתואר ב-Android SDK, וצריך להצהיר על תמיכה בתכונה החומרה android.hardware.usb.host.
  • [C-1-2] חובה להטמיע תמיכה לחיבור ציוד היקפי סטנדרטי מסוג USB. במילים אחרות, חובה:
    • יש יציאת Type-C במכשיר או שסופקו כבלים שמתאימים יציאה קניינית במכשיר ליציאת USB Type-C רגילה (מכשיר USB Type-C).
    • יש יציאת USB מסוג A במכשיר או שצריך לשלוח כבל שמתאים יציאה קניינית במכשיר ליציאת USB רגילה מסוג A.
    • יש יציאת micro-AB במכשיר, שאמורה להגיע עם כבל עם מתאם ליציאת Type-A רגילה.
  • [C-1-3] אסור לשלוח את המכשיר עם מתאם שממיר בין יציאות USB מסוג A או יציאות micro-AB ליציאת Type-C (שקע).
  • [C-SR-1] מומלץ מאוד להטמיע את הקלאס של אודיו USB כפי שמתואר במסמכי התיעוד של Android SDK.
  • צריך לתמוך בטעינה של התקן ההיקפי המחובר מסוג USB במצב מארח, לפרסם זרם מקור של לפחות 1.5A כפי שמפורט בקטע 'פרמטרים של סיום' במפרט USB Type-C Cable and Connector Specification Revision 1.2 למחברים מסוג USB Type-C, או להשתמש בטווח זרם הפלט של Charging Downstream Port‏(CDP) כפי שמפורט במפרט USB Battery Charging specifications, revision 1.2 למחברים מסוג Micro-AB.
  • צריך להטמיע ולתמוך בתקני USB Type-C.

אם הטמעות של מכשירים כוללות יציאת USB שתומכת במצב מארח ובסיווג האודיו של USB, הן:

  • [C-2-1] חובה לתמוך בממשק ה-HID של USB.
  • [C-2-2] חובה לתמוך בזיהוי ובמיפוי של שדות הנתונים הבאים של HID, שצוינו בטבלאות השימוש של USB HID ובבקשת השימוש בפקודות קוליות, לקבועות KeyEvent, כפי שמפורט בהמשך:
    • דף שימוש (0xC) מזהה שימוש (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
    • דף שימוש (0xC) מזהה שימוש (0x0E9): KEYCODE_VOLUME_UP
    • דף שימוש (0xC) מזהה שימוש (0x0EA): KEYCODE_VOLUME_DOWN
    • דף שימוש (0xC) מזהה שימוש (0x0CF): KEYCODE_VOICE_ASSIST

אם הטמעות המכשירים כוללות יציאת USB שתומכת במצב מארח וב-Storage Access Framework‏ (SAF), הן:

  • [C-3-1] חובה לזהות כל מכשיר MTP (פרוטוקול העברת מדיה) שמחובר מרחוק, ולאפשר גישה לתוכן שלו באמצעות הכוונות ACTION_GET_CONTENT, ‏ ACTION_OPEN_DOCUMENT ו-ACTION_CREATE_DOCUMENT. .

אם הטמעות המכשירים כוללות יציאת USB שתומכת במצב מארח וב-USB Type-C, הן:

  • [C-4-1] חובה להטמיע את הפונקציונליות של יציאה עם תפקיד כפול כפי שמוגדרת במפרט USB Type-C (קטע 4.5.1.3.3).
  • [C-SR-2] מומלץ מאוד לתמוך ב-DisplayPort, צריך לתמוך בקצבי נתונים של USB SuperSpeed, ומומלץ מאוד לתמוך ב-Power Delivery להחלפת תפקידים של נתונים וחשמל.
  • [C-SR-3] מומלץ מאוד לא לתמוך במצב 'מתאם אודיו' כפי שמתואר בנספח א' של גרסה 1.2 של מפרט הכבל והמחבר מסוג USB Type-C.
  • צריך להטמיע את המודל Try.* שמתאים ביותר לגורם הצורה של המכשיר. לדוגמה, במכשיר נייד צריך להטמיע את המודל Try.SNK.

7.8. אודיו

7.8.1. מיקרופון

אם הטמעות במכשירים כוללות מיקרופון, הן:

  • [C-1-1] חובה לדווח על קבוע התכונה android.hardware.microphone.
  • [C-1-2] חייב לעמוד בדרישות להקלטת אודיו שמפורטות בקטע 5.4.
  • [C-1-3] חייב לעמוד בדרישות של זמן האחזור של האודיו שמפורטות בקטע 5.6.
  • [C-SR-1] מומלץ מאוד לתמוך בהקלטה של אולטרסאונד קרוב כפי שמתואר בסעיף 7.8.3.

אם הטמעות של מכשירים לא כוללות מיקרופון, הן:

  • [C-2-1] אסור לדווח על קבוע התכונה android.hardware.microphone.
  • [C-2-2] חובה להטמיע את ממשק ה-API להקלטת אודיו לפחות כ-no-ops, בהתאם לקטע 7.

7.8.2. יעד השמע

אם הטמעות של מכשירים כוללות רמקול או יציאת פלט אודיו/מולטימדיה למכשיר היקפי של פלט אודיו, כמו שקע אודיו בגודל 3.5 מ"מ עם 4 מוליכים או יציאה במצב מארח USB באמצעות USB audio class, הן:

  • [C-1-1] חובה לדווח על קבוע התכונה android.hardware.audio.output.
  • [C-1-2] חייב לעמוד בדרישות להפעלת אודיו שמפורטות בקטע 5.5.
  • [C-1-3] חייב לעמוד בדרישות של זמן האחזור של האודיו שמפורטות בקטע 5.6.
  • [C-SR-1] מומלץ מאוד לתמוך בהפעלה של אולטרסאונד כמעט, כפי שמתואר בקטע 7.8.3.

אם הטמעות המכשירים לא כוללות רמקול או יציאת פלט אודיו, הן:

  • [C-2-1] אסור לדווח על התכונה android.hardware.audio.output.
  • [C-2-2] חובה להטמיע את ממשקי ה-API שקשורים לפלט האודיו כ-no-ops לפחות.

לצורכי הקטע הזה, 'יציאת פלט' היא ממשק פיזי, כמו שקע אודיו בגודל 3.5 מ"מ, HDMI או יציאת USB במצב מארח עם אודיו מסוג USB. תמיכה בפלט אודיו באמצעות פרוטוקולים מבוססי רדיו כמו Bluetooth,‏ Wi-Fi או רשת סלולרית לא נחשבת ככוללת 'יציאת פלט'.

7.8.2.1. יציאות אודיו אנלוגיות

כדי להיות תואמים לאוזניות ולאביזרי אודיו אחרים שמשתמשים בחיבור אודיו בגודל 3.5 מ"מ בסביבת Android, אם הטמעות המכשירים כוללות שקע אודיו אנלוגי אחד או יותר, הן:

  • [C-SR-1] מומלץ מאוד לכלול לפחות אחד משקעי האודיו כתקע אודיו 3.5 מ"מ עם 4 מוליכים.

אם להטמעות של המכשירים יש שקע אודיו 3.5 מ"מ עם 4 מוליכים, הן:

  • [C-1-1] חובה לתמוך בהפעלת אודיו באוזניות סטריאופוניות ובאוזניות סטריאופוניות עם מיקרופון.
  • [C-1-2] חובה לתמוך בתקע אודיו TRRS עם סדר הפינים של CTIA.
  • [C-1-3] חובה לתמוך בזיהוי ובמיפוי לקודי המפתחות של 3 טווחי ההתנגדות השקולה הבאים בין המיקרופון לבין מוליכי הארקה בתקע האודיו:
    • 70 אוהם או פחות: KEYCODE_HEADSETHOOK
    • 210-290 אוהם: KEYCODE_VOLUME_UP
    • 360-680 אוהם: KEYCODE_VOLUME_DOWN
  • [C-1-4] חובה להפעיל את ACTION_HEADSET_PLUG כשמחברים את המחבר, אבל רק אחרי שכל המגעים במחבר נוגעים בקטעים הרלוונטיים בתקע.
  • [C-1-5] חייב להיות מסוגל להפעיל לפחות 150mV ± 10% מתח יציאה בהתנגדות של רמקול 32 אוהם.
  • [C-1-6] המתח של המיקרופון חייב להיות בין 1.8V ל-2.9V.
  • [C-1-7] חובה לזהות את הטווח הבא של עכבה שווה ערך בין המיקרופון לבין מוליכי הארקה בתקע האודיו ולמפות אותו לקוד המפתח:
    • 110-180 אוהם: KEYCODE_VOICE_ASSIST
  • [C-SR-2] מומלץ מאוד לתמוך בכבלים עם מחברי אודיו לפי הסדר של OMTP.
  • [C-SR-3] מומלץ מאוד לתמוך בהקלטת אודיו מאוזניות סטריאופוניות עם מיקרופון.

אם הטמעות של מכשירים כוללות שקע אודיו עם 4 מוליכים בגודל 3.5 מ"מ ותומכות במיקרופון, ומפיצות את ה-android.intent.action.HEADSET_PLUG עם הערך הנוסף microphone מוגדר כ-1, הן:

  • [C-2-1] חובה לתמוך בזיהוי המיקרופון באביזר האודיו המחובר.
7.8.2.2. שקעי אודיו דיגיטליים

כדי להיות תואם לאוזניות ולאביזרי אודיו אחרים עם מחברי 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: 'בדיקת תקלה אוטומטית'.

הבדיקה דורשת מתאם אודיו ל-loopback, שמחובר ישירות לתקע 3.5 מ"מ ו/או בשילוב עם מתאם USB-C ל-3.5 מ"מ. מומלץ לבדוק את כל יציאות הקול.

נכון לעכשיו, OboeTester תומך בנתיבים של AAudio, לכן צריך לבדוק את השילובים הבאים כדי לאתר באגים באמצעות AAudio:

מצב Perf שיתוף תדירות דגימה של פלט ב-Chans Out Chans
LOW_LATENCY בלעדי UNSPECIFIED 1 2
LOW_LATENCY בלעדי UNSPECIFIED 2 1
LOW_LATENCY משותף UNSPECIFIED 1 2
LOW_LATENCY משותף UNSPECIFIED 2 1
ללא משותף 48000 1 2
ללא משותף 48000 2 1
ללא משותף 44100 1 2
ללא משותף 44100 2 1
ללא משותף 16000 1 2
ללא משותף 16000 2 1

שידור מהימן אמור לעמוד בקריטריונים הבאים ליחס אות לרעש (SNR) ולעיוות הרמוני כולל (THD) עבור גל סינוס של 2,000Hz.

מתמר THD SNR
הרמקול המובנה הראשי, שנמדד באמצעות מיקרופון חיצוני פחות מ-3.0% 50dB או יותר
המיקרופון המובנה הראשי, שנמדד באמצעות רמקול חיצוני למטרות השוואה פחות מ-3.0% 50dB או יותר
שקעים אנלוגיים מובנים בגודל 3.5 מ"מ, שנבדקו באמצעות מתאם לולאה חוזרת פחות מ-1% 60dB או יותר
מתאמי USB שסופקו עם הטלפון, נבדקו באמצעות מתאם לולאה חוזרת < 1.0% 60dB או יותר

7.9. מציאות מדומה

Android כולל ממשקי API וכלים לפיתוח אפליקציות 'מציאות מדומה' (VR), כולל חוויות VR לנייד באיכות גבוהה. בהטמעות במכשירים חייבים להטמיע את ממשקי ה-API וההתנהגויות האלה בצורה תקינה, כפי שמתואר בקטע הזה.

7.9.1. מצב מציאות מדומה

Android כולל תמיכה במצב VR, תכונה שמטפלת ברינדור סטריאופוני של התראות ומשביתה רכיבים של ממשק המשתמש של המערכת עם מונוקול כאשר אפליקציית VR נמצאת במוקד המשתמשים.

7.9.2. מצב מציאות מדומה – ביצועים גבוהים

אם הטמעות המכשירים תומכות במצב VR, הן:

  • [C-1-1] חייב להיות עם לפחות 2 ליבות פיזיות.
  • [C-1-2] חובה להצהיר על התכונה android.hardware.vr.high_performance.
  • [C-1-3] חובה לתמוך במצב ביצועים יציבים.
  • [C-1-4] חובה שתהיה תמיכה ב-OpenGL ES 3.2.
  • [C-1-5] חובה לתמוך ב-android.hardware.vulkan.level 0.
  • המערכת אמורה לתמוך ב-android.hardware.vulkan.level 1 ואילך.
  • [C-1-6] חובה להטמיע את התוספים EGL_KHR_mutable_render_buffer,‏ EGL_ANDROID_front_buffer_auto_refresh,‏ EGL_ANDROID_get_native_client_buffer,‏ EGL_KHR_fence_sync,‏ EGL_KHR_wait_sync,‏ EGL_IMG_context_priority,‏ EGL_EXT_protected_content,‏ EGL_EXT_image_gl_colorspace ולהציג אותם ברשימה של תוספי EGL הזמינים.
  • [C-1-8] חובה להטמיע את התוספים GL_EXT_multisampled_render_to_texture2,‏ GL_OVR_multiview,‏ GL_OVR_multiview2,‏ GL_EXT_protected_textures ולהציג אותם ברשימת התוספים הזמינים של GL.
  • [C-SR-1] מומלץ מאוד להטמיע את GL_EXT_external_buffer,‏ GL_EXT_EGL_image_array ו-GL_OVR_multiview_multisampled_render_to_texture, ולהציג את התוספים ברשימת התוספים הזמינים של GL.
  • [C-SR-2] מומלץ מאוד לתמוך ב-Vulkan 1.1.
  • [C-SR-3] מומלץ מאוד להטמיע את VK_ANDROID_external_memory_android_hardware_buffer,‏ VK_GOOGLE_display_timing ו-VK_KHR_shared_presentable_image ולהציג אותם ברשימת התוספים הזמינים של Vulkan.
  • [C-SR-4] מומלץ מאוד לחשוף לפחות משפחת תורים אחת של Vulkan, שבה flags מכילה גם את VK_QUEUE_GRAPHICS_BIT וגם את VK_QUEUE_COMPUTE_BIT, ו-queueCount הוא לפחות 2.
  • [C-1-7] חייבים להיות ל-GPU ולמסך אפשרות לסנכרן את הגישה למאגר הקדמי המשותף, כך שאפשר יהיה להציג עיבוד לסירוגין של תוכן VR בשתי סביבות עיבוד ב-60fps לכל עין, ללא פגמים גלויים של קריעה.
  • [C-1-9] חובה להטמיע תמיכה בדגלים AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER,‏ AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA ו-AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT של AHardwareBuffer כפי שמתואר ב-NDK.
  • [C-1-10] חובה להטמיע תמיכה ב-AHardwareBuffer עם כל שילוב של דגלי השימוש AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT,‏ AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE,‏ AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT לפחות בפורמטים הבאים: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM,‏ AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM,‏ AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM,‏ AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
  • [C-SR-5] מומלץ מאוד לתמוך בהקצאה של AHardwareBuffers עם יותר משכבה אחת, ודגלים ופורמטים כפי שמפורטים ב-C-1-10.
  • [C-1-11] חובה לתמוך בפענוח H.264 ברזולוציה של לפחות 3840 x 2160 ב-30fps, דחוסה במהירות ממוצעת של 40Mbps (שווה ערך ל-4 מופעים של 1920 x 1080 ב-30fps-10Mbps או ל-2 מופעים של 1920 x 1080 ב-60fps-20Mbps).
  • [C-1-12] חובה שתהיה תמיכה ב-HEVC וב-VP9, חובה שתהיה יכולת לפענח לפחות ‎1920 x 1080 בקצב 30fps באיכות דחוסה של ‎10Mbps בממוצע, ומומלץ שתהיה יכולת לפענח ‎3840 x 2160 בקצב 30fps-20Mbps (שווה ערך ל-4 מופעים של ‎1920 x 1080 בקצב 30fps-5Mbps).
  • [C-1-13] חובה לתמוך ב-HardwarePropertiesManager.getDeviceTemperatures API ולהחזיר ערכים מדויקים של טמפרטורת העור.
  • [C-1-14] חייב לכלול מסך מוטמע, והרזולוציה שלו חייבת להיות לפחות ‎1920 x 1080.
  • [C-SR-6] מומלץ מאוד שהרזולוציה של המסך תהיה לפחות 2560 x 1440.
  • [C-1-15] התצוגה חייבת להתעדכן במהירות של לפחות 60 הרץ במצב VR.
  • [C-1-17] המסך חייב לתמוך במצב של עמידות נמוכה עם עמידות של 5 אלפיות שנייה לכל היותר. העמידות מוגדרת כמשך הזמן שבו פיקסל פולט אור.
  • [C-1-18] חובה לתמוך ב-Bluetooth 4.2 וב-Bluetooth LE Data Length Extension (הארכת אורך הנתונים של Bluetooth LE) קטע 7.4.3.
  • [C-1-19] חובה לתמוך בסוג הערוץ הישיר ולדווח עליו בצורה תקינה לכל סוגי החיישנים הבאים שמוגדרים כברירת מחדל:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR-7] מומלץ מאוד לתמוך בסוג הערוץ הישיר TYPE_HARDWARE_BUFFER לכל סוגי הערוצים הישירים שמפורטים למעלה.
  • [C-1-21] חייב לעמוד בדרישות לגבי הג'ירוסקופ, מד התאוצה והמגנטומטר של android.hardware.hifi_sensors, כפי שמפורט בקטע 7.3.9.
  • [C-SR-8] מומלץ מאוד לתמוך בתכונה android.hardware.sensor.hifi_sensors.
  • [C-1-22] זמן האחזור מקצה לקצה של תנועה לפוטון חייב להיות לא יותר מ-28 אלפיות השנייה.
  • [C-SR-9] מומלץ מאוד שהזמן המצטבר מהתנועה ועד ליצירת הפוטון לא יעלה על 20 אלפיות השנייה.
  • [C-1-23] חייב להיות יחס של הפריים הראשון, שהוא היחס בין הבהירות של הפיקסלים בפריים הראשון אחרי המעבר משחור ללבן לבין הבהירות של הפיקסלים הלבנים במצב יציב, של לפחות 85%.
  • [C-SR-10] מומלץ מאוד שהיחס של הפריים הראשון יהיה לפחות 90%.
  • יכול להיות שהמעבד יספק ליבה בלעדית לאפליקציה שבחזית, ויכול להיות שהוא יתמוך ב-API ‏Process.getExclusiveCores כדי להחזיר את המספרים של ליבות המעבד שהן בלעדיות לאפליקציה העליונה שבחזית.

אם יש תמיכה בליבה בלעדית, הליבה:

  • [C-2-1] אסור לאפשר להריץ בה תהליכים אחרים במרחב המשתמש (למעט מנהלי התקנים שבהם האפליקציה משתמשת), אבל מותר לאפשר להריץ בה תהליכים מסוימים בליבה לפי הצורך.

7.10. מגע

הדרישות הספציפיות למכשיר מפורטות בקטע 2.2.1.

7.11. Media Performance Class

אפשר לקבל את סיווג הביצועים של המדיה בהטמעת המכשיר מה-android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS. הדרישות לסיווג הביצועים של המדיה מוגדרות לכל גרסת Android, החל מגרסה R‏ (30). הערך המיוחד 0 מציין שהמכשיר לא שייך לסוג של ביצועי מדיה.

אם הטמעות במכשירים מחזירות ערך שאינו אפס עבור android.os.Build.VERSION.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 לגבי ההפעלה, התחזוקה, אלגוריתמי ההתעוררות והשימוש בהגדרות המערכת הגלובליות או ב-DeviceConfig של המצבים לחיסכון באנרגיה 'המתנה לאפליקציה' ו'דוז'.
  • [C-1-2] אסור לסטות מההטמעה של AOSP לגבי השימוש בהגדרות גלובליות או ב-DeviceConfig לניהול הצמצום של משימות, התראות ורשתות באפליקציות בכל קטגוריה של מצב המתנה של אפליקציות.
  • [C-1-3] אסור לסטות מההטמעה של AOSP לגבי מספר הקטגוריות של סטטוס 'האפליקציה במצב המתנה' שמשמש לסטטוס 'האפליקציה במצב המתנה'.
  • [C-1-4] חובה להטמיע קטגוריות של אפליקציות במצב המתנה ו-Doze כפי שמתואר בקטע ניהול צריכת החשמל.
  • [C-1-5] חובה להחזיר את הערך true עבור PowerManager.isPowerSaveMode() כשהמכשיר במצב חיסכון בסוללה.
  • [C-1-6] חובה לספק למשתמשים אפשרות להציג את כל האפליקציות שמוחרגו ממצבי חיסכון באנרגיה 'המתנה לאפליקציה' ו'דוז', או מכל אופטימיזציות הסוללה, וחובה להטמיע את הכוונה ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS כדי לבקש מהמשתמשים לאפשר לאפליקציה להתעלם מאופטימיזציות הסוללה.
  • [C-SR-1] מומלץ מאוד לספק למשתמשים אפשרות להפעיל ולהשבית את התכונה 'חיסכון בסוללה'.
  • [C-SR-2] מומלץ מאוד לספק למשתמש אפשרות להציג את כל האפליקציות שפטורות ממצבי חיסכון באנרגיה 'המתנה לאפליקציה' ו'דוז'.

אם הטמעות במכשירים מרחיבות את תכונות ניהול צריכת האנרגיה שכלולות ב-AOSP, והתוסף הזה מחיל הגבלות מחמירות יותר מאשר הקטגוריה 'אפליקציות נדירות במצב המתנה', יש לעיין בקטע 3.5.1.

בנוסף למצבי חיסכון באנרגיה, הטמעות של מכשירי Android עשויות ליישם כל אחד מ-4 מצבי השינה או את כולם, כפי שהוגדרו על ידי Advanced Configuration and Power Interface‏ (ACPI).

אם הטמעות של מכשירים מטמיעות מצבי צריכת אנרגיה מסוג S4 כפי שמוגדרים ב-ACPI, הן:

  • [C-1-1] המכשיר חייב לעבור למצב הזה רק אחרי שהמשתמש ביצע פעולה מפורשת כדי להעביר את המכשיר למצב לא פעיל (למשל, סגירת מכסה שהוא חלק פיזי מהמכשיר או כיבוי רכב או טלוויזיה) ולפני שהמשתמש מפעיל מחדש את המכשיר (למשל, פתיחת המכסה או הפעלה מחדש של הרכב או הטלוויזיה).

אם הטמעות של מכשירים מטמיעות מצבי צריכת אנרגיה של S3 כפי שמוגדרים ב-ACPI, הן:

  • [C-2-1] חובה לעמוד בתנאי של C-1-1 שלמעלה, או חובה להיכנס למצב S3 רק כשאפליקציות של צד שלישי לא זקוקות למשאבי המערכת (למשל המסך, המעבד).

    לעומת זאת, חייבים לצאת ממצב S3 כשאפליקציות של צד שלישי זקוקות למשאבי המערכת, כפי שמתואר ב-SDK הזה.

    לדוגמה, כשאפליקציות של צד שלישי מבקשות להשאיר את המסך דלוק דרך FLAG_KEEP_SCREEN_ON או להפעיל את המעבד דרך PARTIAL_WAKE_LOCK, אסור שהמכשיר יעבור למצב S3, אלא אם המשתמש ביצע פעולה מפורשת כדי להעביר את המכשיר למצב לא פעיל, כפי שמתואר בקטע C-1-1. לעומת זאת, כשמשימה שאפליקציות צד שלישי מטמיעות דרך JobScheduler מופעלת או כשהודעות מ-Firebase Cloud Messaging מועברות לאפליקציות צד שלישי, המכשיר חייב לצאת ממצב S3, אלא אם המשתמש העביר את המכשיר למצב לא פעיל. אלה לא דוגמאות מקיפות, ו-AOSP מטמיע אותות התעוררות נרחבים שמפעילים התעוררות מהמצב הזה.

8.4. ניהול חשבונות של צריכת חשמל

דיווח וניהול חשבונות מדויקים יותר של צריכת החשמל מספקים למפתחי האפליקציות את התמריצים והכלים לביצוע אופטימיזציה של דפוס צריכת החשמל באפליקציה.

הטמעות במכשירים:

  • [C-SR-1] מומלץ מאוד לספק פרופיל צריכת אנרגיה לכל רכיב, שמגדיר את ערך הצריכה הנוכחית של כל רכיב חומרה ואת הירידה המשוערת בנפח הסוללה שנגרמת על ידי הרכיבים לאורך זמן, כפי שמופיע באתר של Android Open Source Project.
  • [C-SR-2] מומלץ מאוד לדווח על כל ערכי צריכת החשמל במיליאמפר-שעה (mAh).
  • [C-SR-3] מומלץ מאוד לדווח על צריכת האנרגיה של המעבד (CPU) לכל מזהה משתמש (UID) של תהליך. פרויקט הקוד הפתוח של Android עומד בדרישות באמצעות הטמעת מודול הליבה uid_cputime.
  • [C-SR-4] מומלץ מאוד להפוך את צריכת החשמל הזו לזמינה למפתח האפליקציה באמצעות הפקודה adb shell dumpsys batterystats של מעטפת.
  • צריך לשייך לרכיב החומרה עצמו אם אי אפשר לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.

8.5. ביצועים עקביים

הביצועים עשויים להשתנות באופן משמעותי באפליקציות עם ביצועים גבוהים שפועלות לאורך זמן, בין שבגלל האפליקציות האחרות שפועלות ברקע ובין שבגלל צמצום המהירות של המעבד עקב מגבלות טמפרטורה. מערכת Android כוללת ממשקים פרוגרמטיים, כך שאם המכשיר מסוגל, האפליקציה העיקרית בחזית יכולה לבקש מהמערכת לבצע אופטימיזציה של הקצאת המשאבים כדי להתמודד עם תנודות כאלה.

הטמעות במכשירים:

  • [C-0-1] חובה לדווח בצורה מדויקת על התמיכה במצב ביצועים יציבים באמצעות שיטת ה-API‏ PowerManager.isSustainedPerformanceModeSupported().

  • צריכה להיות תמיכה במצב 'ביצועים יציבים'.

אם הטמעות במכשירים מדווחות על תמיכה במצב ביצועים יציבים, הן:

  • [C-1-1] חובה לספק לאפליקציה העיקרית בחזית רמת ביצועים עקבית למשך 30 דקות לפחות, כשהאפליקציה מבקשת זאת.
  • [C-1-2] חובה לפעול בהתאם לממשק ה-API של Window.setSustainedPerformanceMode() ולממשקי API קשורים אחרים.

אם הטמעות במכשירים כוללות שני ליבות מעבד או יותר, הן:

  • צריך לספק לפחות ליבה אחת בלעדית שאפשר לשמור לשימוש של האפליקציה העיקרית בחזית.

אם הטמעות במכשירים תומכות בהקצאת ליבה אחת בלעדית לאפליקציה העיקרית בחזית, הן:

  • [C-2-1] חובה לדווח באמצעות שיטת ה-API‏ Process.getExclusiveCores() על מספרי המזהים של הליבות הייעודיות שאפשר להקצות לאפליקציה העיקרית שבחזית.
  • [C-2-2] אסור לאפשר תהליכים במרחב המשתמש, מלבד מנהלי ההתקנים שבהם האפליקציה משתמשת כדי לפעול בליבות הבלעדיות, אבל מותר לאפשר להפעיל תהליכים מסוימים בליבה לפי הצורך.

אם הטמעות במכשירים לא תומכות בליבה בלעדית, הן:

9. תאימות של מודל האבטחה

הטמעות במכשירים:

  • [C-0-1] חובה להטמיע מודל אבטחה שתואם למודל האבטחה של פלטפורמת Android, כפי שמוגדר במסמך העזרה בנושא אבטחה והרשאות בממשקי ה-API במסמכי התיעוד למפתחים של Android.

  • [C-0-2] חובה לתמוך בהתקנה של אפליקציות בחתימה עצמית בלי צורך בהרשאות או באישורים נוספים מצדדים שלישיים או מרשויות.

אם הטמעות במכשירים מכריזות על התכונה android.hardware.security.model.compatible, הן:

  • [C-1-1] חייב לתמוך בדרישות שמפורטות בקטעים הבאים.

9.1. הרשאות

הטמעות במכשירים:

  • [C-0-1] חובה לתמוך במודל ההרשאות של Android ובמודל התפקידים של Android כפי שהם מוגדרים במסמכים למפתחים של Android. באופן ספציפי, הם חייבים לאכוף כל הרשאה ותפקיד שמוגדרים כפי שמתואר במסמכי העזרה של ה-SDK. אסור להשמיט, לשנות או להתעלם מהרשאות ומתפקידים.

  • מותר להוסיף הרשאות נוספות, בתנאי שמחרוזות מזהי ההרשאות החדשות לא נמצאות במרחב השמות android.\*.

  • [C-0-2] הרשאות עם protectionLevel של PROTECTION_FLAG_PRIVILEGED חייבות להינתן רק לאפליקציות שמותקנות מראש בנתיבים המורשים של קובץ האימג' של המערכת, ובמסגרת קבוצת המשנה של ההרשאות שמופיעות ברשימת ההיתרים של כל אפליקציה. ההטמעה של 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, כדי למנוע התקפות כוח brute על גורם הידע במסך הנעילה.

הטמעות במכשירים:

  • [C-0-7] חובה לפעול בהתאם למאפיינים של הרשאת המיקום ב-Android כשאפליקציה מבקשת את נתוני המיקום או הפעילות הפיזית דרך Android API רגיל או מנגנון קנייני. הנתונים האלה כוללים, בין היתר:

    • המיקום של המכשיר (למשל, קו הרוחב וקו האורך) כפי שמתואר בקטע 9.8.8.
    • מידע שאפשר להשתמש בו כדי לקבוע או להעריך את המיקום של המכשיר (למשל SSID,‏ BSSID,‏ Cell ID או המיקום של הרשת שאליה המכשיר מחובר).
    • הפעילות הגופנית של המשתמש או הסיווג של הפעילות הגופנית.

באופן ספציפי יותר, הטמעות של מכשירים:

  • [C-0-8] חובה לקבל הסכמה מהמשתמשים כדי לאפשר לאפליקציה לגשת לנתוני המיקום או לנתוני הפעילות הגופנית.
  • [C-0-9] חובה להעניק הרשאת זמן ריצה רק לאפליקציה שיש לה הרשאה מספקת, כפי שמתואר ב-SDK. לדוגמה, הקריאה TelephonyManager#getServiceState דורשת את ההרשאה android.permission.ACCESS_FINE_LOCATION.

החריגים היחידים לנכסי הרשאות המיקום של Android שמפורטים למעלה הם לאפליקציות שלא ניגשות למיקום כדי להסיק או לזהות את המיקום של המשתמש. באופן ספציפי:

  • כשאפליקציות מקבלות את ההרשאה RADIO_SCAN_WITHOUT_LOCATION.
  • לצורכי הגדרה והגדרה אישית של המכשיר, כשאפליקציות מערכת מחזיקות בהרשאה NETWORK_SETTINGS או NETWORK_SETUP_WIZARD.

אפשר לסמן הרשאות כמוגבלות כדי לשנות את ההתנהגות שלהן.

  • [C-0-10] אסור להקצות לאפליקציה הרשאות שמסומנות בדגל hardRestricted, אלא אם:

    • קובץ APK של אפליקציה נמצא במחיצה של המערכת.
    • המשתמש מקצה לאפליקציה תפקיד שמשויך להרשאות hardRestricted.
    • מנהל ההתקנה מעניק את hardRestricted לאפליקציה.
    • אפליקציה קיבלה את ההרשאה hardRestricted בגרסה קודמת של Android.

  • [C-0-11] אפליקציות עם הרשאת softRestricted חייבות לקבל גישה מוגבלת בלבד, אסור להן לקבל גישה מלאה עד להוספה לרשימת ההיתרים כפי שמתואר ב-SDK, שבו הגדרת הגישה המלאה והמוגבלת לכל הרשאת softRestricted (לדוגמה, READ_EXTERNAL_STORAGE).

  • [C-0-12] אסור לספק פונקציות מותאמות אישית או ממשקי API כדי לעקוף את הגבלות ההרשאות שמוגדרות בממשקי ה-API setPermissionPolicy ו-setPermissionGrantState.

  • [C-0-13] חובה להשתמש בממשקי ה-API של AppOpsManager כדי לתעד ולעקוב אחרי כל גישה פרוגרמטית לנתונים שמוגנים על ידי הרשאות מסוכנות מפעילויות ושירותים של Android.

  • [C-0-14] חובה להקצות תפקידים רק לאפליקציות עם פונקציות שעומדות בדרישות התפקיד.

  • [C-0-15] אסור להגדיר תפקידים שהם כפילויות או פונקציונליות של קבוצת-על של תפקידים שהוגדרו על ידי הפלטפורמה.

אם המכשירים מדווחים על android.software.managed_users, הם:

  • [C-1-1] אסור שהאדמין יעניק את ההרשאות הבאות באופן אוטומטי:
    • מיקום (ACCESS_BACKGROUND_LOCATION, ‏ ACCESS_COARSE_LOCATION,‏ ACCESS_FINE_LOCATION).
    • מצלמה (CAMERA)
    • מיקרופון (RECORD_AUDIO)
    • חיישן גוף (BODY_SENSORS)
    • פעילות גופנית (ACTIVITY_RECOGNITION)

אם הטמעות במכשירים מספקות למשתמש אפשרות לבחור אילו אפליקציות יוכלו לצייר מעל אפליקציות אחרות באמצעות פעילות שמטפלת בכוונה ACTION_MANAGE_OVERLAY_PERMISSION, הן:

  • [C-2-1] חובה לוודא שלכל הפעילויות עם מסנני כוונה לכוונה ACTION_MANAGE_OVERLAY_PERMISSION יש את אותו מסך ממשק משתמש, ללא קשר לאפליקציה המפעילה או למידע שהיא מספקת.

אם הטמעות במכשירים מדווחות על android.software.device_admin, הן:

  • [C-3-1] חובה להציג כתב ויתור במהלך הגדרת המכשיר המנוהל באופן מלא (הגדרה על ידי בעלי המכשיר) שמציין שלאדמין ה-IT תהיה אפשרות לאפשר לאפליקציות לשלוט בהגדרות בטלפון, כולל המיקום, המיקרופון והמצלמה, עם אפשרויות למשתמש להמשיך בהגדרה או לצאת מההגדרה, אלא אם האדמין ביטל את ההסכמה לשלוט בהרשאות במכשיר.

אם הטמעות במכשירים מתקינות מראש חבילות שמכילות את התפקידים System UI Intelligence,‏ System Ambient Audio Intelligence,‏ System Audio Intelligence,‏ System Notification Intelligence,‏ System Text Intelligence או System Visual Intelligence, החבילות:

  • [C-4-1] חייב לעמוד בכל הדרישות שמפורטות להטמעות במכשירים בקטע '9.8.6 צילום תוכן'.
  • [C-4-2] אסור שתהיה לאפליקציה הרשאה android.permission.INTERNET. ההמלצה הזו מחמירה יותר מההמלצה 'מומלץ בחום' שמופיעה בקטע 9.8.6.
  • [C-4-3] אסור לשייך לאפליקציות אחרות, מלבד אפליקציות המערכת הבאות: Bluetooth,‏ אנשי קשר, מדיה, טלפוניה, SystemUI ורכיבים שמספקים ממשקי API לאינטרנט.הדרישה הזו מחמירה יותר מההמלצה החזקה שמפורטת בקטע 9.8.6.

9.2. בידוד של UID ותהליכים

הטמעות במכשירים:

  • [C-0-1] חובה לתמוך במודל ארגז החול של אפליקציות Android, שבו כל אפליקציה פועלת בתור UID ייחודי בסגנון Unix ובתהליך נפרד.
  • [C-0-2] חובה לתמוך בהרצה של כמה אפליקציות בתור אותו מזהה משתמש ב-Linux, בתנאי שהאפליקציות נוצרו ונחתמו כראוי, כפי שמוגדר בחומר העזר בנושא אבטחה והרשאות.

9.3. הרשאות למערכת הקבצים

הטמעות במכשירים:

9.4. סביבות הפעלה חלופיות

הטמעות במכשירים חייבות לשמור על עקביות של מודל האבטחה וההרשאות של Android, גם אם הן כוללות סביבות זמן ריצה שמריצות אפליקציות באמצעות תוכנה או טכנולוגיה אחרת מלבד פורמט Dalvik Executable או קוד מקורי. במילים אחרות:

  • [C-0-1] סביבות זמן ריצה חלופיות חייבות להיות אפליקציות ל-Android, ולעמוד במודל האבטחה הרגיל של Android, כפי שמתואר במקום אחר בסעיף 9.

  • [C-0-2] אסור להעניק לסביבות זמן ריצה חלופיות גישה למשאבים שמוגנים באמצעות הרשאות שלא נשלחו בבקשה בקובץ AndroidManifest.xml של סביבת זמן הריצה, באמצעות המנגנון <uses-permission>.

  • [C-0-3] אסור לסביבות זמן ריצה חלופיות לאפשר לאפליקציות להשתמש בתכונות שמוגנות על ידי הרשאות Android המוגבלות לאפליקציות מערכת.

  • [C-0-4] סביבות זמן ריצה חלופיות חייבות לפעול בהתאם למודל של ארגז החול של Android, ואפליקציות שמותקנות באמצעות סביבת זמן ריצה חלופית אסור להשתמש שוב בארגז החול של אפליקציה אחרת שמותקנת במכשיר, מלבד באמצעות המנגנונים הרגילים של Android למזהה משתמש משותף ולאימות באמצעות אישור חתימה.

  • [C-0-5] אסור להפעיל סביבות זמן ריצה חלופיות עם גישה לקופסאות החול התואמות לאפליקציות אחרות ל-Android, או להעניק להן גישה לקופסאות החול האלה, או לקבל גישה מהן.

  • [C-0-6] אסור להפעיל סביבות זמן ריצה חלופיות עם הרשאות של סופר-משתמש (root) או של מזהה משתמש אחר, או להעניק להן הרשאות כאלה, או להעניק אותן לאפליקציות אחרות.

  • [C-0-7] כשקבצי .apk של סביבות זמן ריצה חלופיות נכללים בתמונת המערכת של הטמעות המכשיר, חובה לחתום עליה באמצעות מפתח שונה מהמפתח שמשמש לחתימה על אפליקציות אחרות שכלולות בהטמעות המכשיר.

  • [C-0-8] כשמתקינים אפליקציות, סביבות זמן ריצה חלופיות חייבות לקבל הסכמה מהמשתמשים להרשאות Android שבהן האפליקציה משתמשת.

  • [C-0-9] כשאפליקציה צריכה להשתמש במשאב של מכשיר שיש לו הרשאה תואמת ב-Android (כמו מצלמה, GPS וכו'), סביבת זמן הריצה החלופית חייבת להודיע למשתמש שהאפליקציה תהיה מסוגלת לגשת למשאב הזה.

  • [C-0-10] כשסביבת זמן הריצה לא מתעדת את יכולות האפליקציה באופן הזה, סביבת זמן הריצה חייבת לרשום את כל ההרשאות שבהן זמן הריצה עצמו מחזיק בזמן התקנת כל אפליקציה באמצעות זמן הריצה הזה.

  • בסביבות זמן ריצה חלופיות, צריך להתקין אפליקציות דרך PackageManager בסביבות חול נפרדות ל-Android (מזהי משתמשים ב-Linux וכו').

  • סביבות זמן ריצה חלופיות עשויות לספק ארגז חול אחד של Android שכל האפליקציות שמשתמשות בסביבת זמן הריצה החלופית משתפות.

9.5. תמיכה בכמה משתמשים

ב-Android יש תמיכה במספר משתמשים, ותמיכה בבידוד מלא של משתמשים וביצירת עותקים משובטים של פרופילי משתמשים עם בידוד חלקי(כלומר פרופיל משתמש נוסף אחד מסוג android.os.usertype.profile.CLONE).

  • אפשר להפעיל את התכונה 'שימוש בכמה משתמשים' בהטמעות של מכשירים, אבל לא מומלץ לעשות זאת אם הם משתמשים במדיה נשלפת לאחסון חיצוני ראשי.

אם הטמעות במכשירים כוללות תמיכה בכמה משתמשים, הן:

  • [C-1-2] חובה להטמיע לכל משתמש מודל אבטחה שתואם למודל האבטחה של פלטפורמת Android, כפי שמוגדר במסמך העזרה בנושא אבטחה והרשאות בממשקי ה-API.
  • [C-1-3] חובה שיהיה לכל מכונה של משתמש ספריות נפרדות ומבודדות של אחסון משותף לאפליקציות (נקראות גם /sdcard).
  • [C-1-4] חובה לוודא שאפליקציות שבבעלות משתמש מסוים שפועלות בשם המשתמש הזה לא יכולות להציג רשימה של קבצים שבבעלות משתמש אחר, לקרוא אותם או לכתוב בהם, גם אם הנתונים של שני המשתמשים מאוחסנים באותו נפח אחסון או באותה מערכת קבצים.
  • [C-1-5] חובה להצפין את התוכן של כרטיס ה-SD כשהאפשרות של משתמשים מרובים מופעלת באמצעות מפתח שמאוחסן רק במדיה לא נשלפת שרק למערכת יש גישה אליה, אם הטמעות המכשיר משתמשות במדיה נשלפת לממשקי ה-API של האחסון החיצוני. מכיוון שהשינוי הזה ימנע ממחשבים מארחים לקרוא את המדיה, תצטרכו להעביר את הטמעות המכשירים ל-MTP או למערכת דומה כדי לספק למחשבים מארחים גישה לנתונים של המשתמש הנוכחי.

אם הטמעות במכשירים כוללות תמיכה בכמה משתמשים, כל המשתמשים, מלבד משתמשים שנוצרו במיוחד להפעלת שתי מכונות של אותה אפליקציה, יכולים:

  • [C-2-1] חובה שיהיה לכל מכונה של משתמש ספריות נפרדות ומבודדות של אחסון משותף לאפליקציות (נקראות גם ‎/sdcard).
  • [C-2-2] חובה לוודא שאפליקציות שבבעלות משתמש מסוים שפועלות בשם המשתמש הזה לא יכולות להכין רשימה של קבצים שבבעלות משתמש אחר, לקרוא אותם או לכתוב בהם, גם אם הנתונים של שני המשתמשים מאוחסנים באותו נפח אחסון או באותה מערכת קבצים.

הטמעות במכשירים עשויות ליצור פרופיל משתמש נוסף אחד מסוג android.os.usertype.profile.CLONE מול המשתמש הראשי (ובאופן בלעדי מול המשתמש הראשי) לצורך הפעלת שתי מכונות של אותה אפליקציה. שתי המכונות האלה משתפות אחסון מבודד חלקית, מוצגות למשתמש הקצה במרכז האפליקציות בו-זמנית ומופיעות באותה תצוגה של הפריטים האחרונים. לדוגמה, אפשר להשתמש באפשרות הזו כדי לתמוך במשתמש שמתקין שני מופעים נפרדים של אפליקציה אחת במכשיר עם שני כרטיסי SIM.

אם הטמעות במכשירים יוצרות את פרופיל המשתמש הנוסף שתואר למעלה, הן:

  • [C-3-1] חובה לספק גישה רק לאחסון או לנתונים שכבר יש גישה אליהם בפרופיל המשתמש הראשי, או שבבעלות ישירה של פרופיל המשתמש הנוסף.
  • [C-3-2] אסור להגדיר את זה כפרופיל עבודה.
  • [C-3-3] חובה להפריד בין ספריות של נתונים פרטיים של אפליקציות לבין חשבון המשתמש הראשי.
  • [C-3-4] אסור לאפשר ליצור את פרופיל המשתמש הנוסף אם כבר הוקצה בעל מכשיר (ראו סעיף 3.9.1), או לאפשר הקצאה של בעל מכשיר בלי להסיר קודם את פרופיל המשתמש הנוסף.

9.6. אזהרה לגבי SMS פרימיום

ב-Android יש תמיכה באזהרה למשתמשים על כל הודעת SMS בתשלום שיוצאת. הודעות Premium SMS הן הודעות טקסט שנשלחות לשירות רשום אצל ספק, שעשויות לגרום לחיוב של המשתמש.

אם הטמעות במכשירים מצהירות על תמיכה ב-android.hardware.telephony, הן:

  • [C-1-1] חובה להזהיר את המשתמשים לפני שליחת הודעת SMS למספרים שזוהו באמצעות ביטויים רגולריים שהוגדרו בקובץ /data/misc/sms/codes.xml במכשיר. ב-Android Open Source Project (פרויקט קוד פתוח של Android) יש הטמעה שעומדת בדרישות האלה.

9.7. תכונות אבטחה

הטמעות במכשירים חייבות להבטיח תאימות לתכונות האבטחה גם בליבה וגם בפלטפורמה, כפי שמתואר בהמשך.

ארגז החול של Android כולל תכונות שמשתמשות במערכת בקרת הגישה (MAC) של Security-Enhanced Linux‏ (SELinux), ב-seccomp sandboxing ובתכונות אבטחה אחרות בליבה של Linux. הטמעות במכשירים:

  • [C-0-1] חובה לשמור על תאימות לאפליקציות קיימות, גם אם SELinux או תכונות אבטחה אחרות מוטמעות מתחת למסגרת Android.
  • [C-0-2] אסור שיהיה לממשק המשתמש של האפליקציה מראה גלוי כשמתגלה הפרת אבטחה ונחסמת בהצלחה על ידי תכונת האבטחה שמוטמעת מתחת למסגרת של Android, אבל יכול להיות שיהיה לממשק המשתמש מראה גלוי כשמתרחשת הפרת אבטחה שלא נחסמה וכתוצאה מכך מתרחשת ניצול לרעה מוצלח.
  • [C-0-3] אסור לאפשר למשתמש או למפתח האפליקציה להגדיר את SELinux או תכונות אבטחה אחרות שמוטמעות מתחת למסגרת של Android.
  • [C-0-4] אסור לאפשר לאפליקציה שיכולה להשפיע על אפליקציה אחרת דרך ממשק API (כמו Device Administration API) להגדיר מדיניות שמפרה את התאימות.
  • [C-0-5] חובה לפצל את מסגרת המדיה למספר תהליכים כדי שניתן יהיה להעניק גישה מצומצמת יותר לכל תהליך, כפי שמתואר באתר של Android Open Source Project.
  • [C-0-6] חובה להטמיע מנגנון של ארגז חול לאפליקציות בליבה שמאפשר סינון של קריאות למערכת באמצעות מדיניות שניתן להגדיר מתוכניות עם מספר רב של שרשורים. הפרויקט של Android Open Source עומד בדרישות האלה באמצעות הפעלת seccomp-BPF עם סנכרון של קבוצת חוטים (TSYNC), כפי שמתואר בקטע Kernel Configuration באתר source.android.com.

תכונות שלמות הליבה והגנה עצמית הן חלק בלתי נפרד מאבטחת Android. הטמעות במכשירים:

  • [C-0-7] חובה להטמיע מנגנוני הגנה מפני גלישת חוצץ במחסנית הליבה. דוגמאות למנגנונים כאלה הן CC_STACKPROTECTOR_REGULAR ו-CONFIG_CC_STACKPROTECTOR_STRONG.
  • [C-0-8] חובה להטמיע הגנות מחמירות על זיכרון הליבה, כך שקוד שניתן להריץ יהיה לקריאה בלבד, נתונים לקריאה בלבד לא ניתנים להריצה ולא ניתן לשנות אותם, ונתונים שניתן לשנות לא ניתנים להריצה (למשל CONFIG_DEBUG_RODATA או CONFIG_STRICT_KERNEL_RWX).
  • [C-0-9] חובה להטמיע בדיקה של גבולות גודל אובייקטים סטטיים ודינמיים של עותקים בין מרחב המשתמש למרחב הליבה (למשל CONFIG_HARDENED_USERCOPY) במכשירים ששווקו במקור עם רמת API 28 ואילך.
  • [C-0-10] אסור להריץ זיכרון במרחב המשתמש כשמפעילים במצב הליבה (למשל, PXN בחומרה או זיכרון ממולא באמצעות CONFIG_CPU_SW_DOMAIN_PAN או CONFIG_ARM64_SW_TTBR0_PAN) במכשירים ששווקו במקור עם רמת API 28 ואילך.
  • [C-0-11] אסור לקרוא או לכתוב בזיכרון של מרחב המשתמש בליבה, מחוץ לממשקי API רגילים של גישה להעתקת משתמש (למשל, PAN של חומרה או זיכרון שמומר באמצעות CONFIG_CPU_SW_DOMAIN_PAN או CONFIG_ARM64_SW_TTBR0_PAN) במכשירים ששווקו במקור עם API ברמה 28 ואילך.
  • [C-0-12] חובה להטמיע בידוד של טבלת דפי הליבה אם החומרה חשופה לנקודת החולשה CVE-2017-5754 בכל המכשירים ששווקו במקור עם רמת API 28 ואילך (למשל CONFIG_PAGE_TABLE_ISOLATION או CONFIG_UNMAP_KERNEL_AT_EL0).
  • [C-0-13] חובה להטמיע הקשחת חיזוי הסתעפויות אם החומרה חשופה ל-CVE-2017-5715 בכל המכשירים ששווקו במקור עם רמת API‏ 28 ואילך (למשל, CONFIG_HARDEN_BRANCH_PREDICTOR).
  • [C-SR-1] מומלץ מאוד לסמן את נתוני הליבה שנכתבים רק במהלך האתחול כקריאה בלבד אחרי האתחול (למשל __ro_after_init).

  • [C-SR-2] מומלץ מאוד לבצע רנדומיזציה של הפריסה של קוד הליבה והזיכרון, ולהימנע מחשיפות שעלולות לפגוע ברנדומיזציה (למשל, CONFIG_RANDOMIZE_BASE עם אנטרופיה של bootloader דרך /chosen/kaslr-seed Device Tree node או EFI_RNG_PROTOCOL).

  • [C-SR-3] מומלץ מאוד להפעיל את תקינות זרימת הבקרה (CFI) בליבה כדי לספק הגנה נוספת מפני התקפות של שימוש חוזר בקוד (למשל CONFIG_CFI_CLANG ו-CONFIG_SHADOW_CALL_STACK).

  • [C-SR-4] מומלץ מאוד לא להשבית את התכונות Control-Flow Integrity‏ (CFI),‏ Shadow Call Stack‏ (SCS) או Integer Overflow Sanitization‏ (IntSan) ברכיבים שבהם הן מופעלות.

  • [C-SR-5] מומלץ מאוד להפעיל את CFI, ‏ SCS ו-IntSan לכל רכיב נוסף במרחב המשתמש שחשוף לאיומי אבטחה, כפי שמוסבר במאמרים CFI ו-IntSan.

  • [C-SR-6] מומלץ מאוד להפעיל את האיניציאליזציה של הסטאק בליבה כדי למנוע שימוש במשתנים מקומיים שלא עברו את תהליך האיניציאליזציה (CONFIG_INIT_STACK_ALL או CONFIG_INIT_STACK_ALL_ZERO). בנוסף, לא מומלץ להניח שהערך שבו משתמש המהדר הוא הערך שבו משתמשים המשתנים המקומיים.

  • [C-SR-7] מומלץ מאוד להפעיל את האינטליקציה של אשכול בתוך הליבה כדי למנוע שימוש בהקצאות של אשכול ללא אינטליקציה (CONFIG_INIT_ON_ALLOC_DEFAULT_ON), ואסור להניח שהערך שבו הליבה משתמשת כדי לאתחל את ההקצאות האלה הוא הערך הנכון.

אם הטמעות במכשירים משתמשות בליבה של Linux שיכולה לתמוך ב-SELinux, הן:

  • [C-1-1] חובה להטמיע את SELinux.
  • [C-1-2] חובה להגדיר את SELinux למצב אכיפה גלובלי.
  • [C-1-3] חובה להגדיר את כל הדומיינים במצב אכיפה. אסור להשתמש בדומיינים במצב הרשאות רחבות, כולל דומיינים ספציפיים למכשיר או לספק.
  • [C-1-4] אסור לשנות, להשמיט או להחליף את כללי neverallow שנמצאים בתיקייה system/sepolicy שסופקו ב-Android Open Source Project (AOSP) ב-upstream, וצריך לבצע הידור של המדיניות עם כל כללי neverallow הקיימים, גם לדומיינים של AOSP SELinux וגם לדומיינים ספציפיים למכשיר או לספק.
  • [C-1-5] חובה להריץ אפליקציות של צד שלישי שמטרגטות API ברמה 28 ואילך בארגזות חול של SELinux לכל אפליקציה, עם הגבלות SELinux לכל אפליקציה על ספריית הנתונים הפרטית של כל אפליקציה.
  • צריך לשמור על מדיניות ברירת המחדל של SELinux שסופקת בתיקייה system/sepolicy של Android Open Source Project ב-upstream, ולהוסיף למדיניות הזו רק את ההגדרות הספציפיות למכשיר.

אם בהטמעות במכשירים נעשה שימוש בליבה שאינה Linux או ב-Linux ללא SELinux, הן:

  • [C-2-1] חובה להשתמש במערכת חובה לבקרת גישה ששווה ערך ל-SELinux.

אם הטמעות של מכשירים משתמשות במכשירי קלט/פלט שיכולים לבצע DMA, הן:

  • [C-SR-8] מומלץ מאוד לבודד כל מכשיר קלט/פלט שיכול לבצע DMA באמצעות IOMMU (למשל ARM SMMU).

מערכת Android מכילה כמה תכונות של הגנה לעומק, שהן חלק בלתי נפרד מאבטחת המכשיר. בנוסף, אנחנו מתמקדים ב-Android בהפחתת קבוצות מפתח של באגים נפוצים שתורמים לאיכות ולבטיחות ירודות.

כדי לצמצם את מספר הבאגים בזיכרון, הטמעות במכשירים:

  • [C-SR-9] מומלץ מאוד לבדוק את המכשירים האלה באמצעות כלים לזיהוי שגיאות בזיכרון במרחב המשתמש, כמו MTE למכשירי ARMv9,‏ HWASan למכשירי ARMv8+ או ASan לסוגי מכשירים אחרים.
  • [C-SR-10] מומלץ מאוד לבדוק את המכשירים האלה באמצעות כלים לזיהוי שגיאות בזיכרון הליבה, כמו KASAN‏ (CONFIG_KASAN,‏ CONFIG_KASAN_HW_TAGS למכשירי ARMv9,‏ CONFIG_KASAN_SW_TAGS למכשירי ARMv8 או CONFIG_KASAN_GENERIC לסוגים אחרים של מכשירים).
  • [C-SR-11] מומלץ מאוד להשתמש בכלים לזיהוי שגיאות זיכרון בסביבת הייצור, כמו MTE,‏ GWP-ASan ו-KFENCE.

אם הטמעות במכשירים משתמשות ב-TEE שמבוסס על Arm TrustZone, הן:

  • [C-SR-12] מומלץ מאוד להשתמש בפרוטוקול סטנדרטי לשיתוף זיכרון בין Android ל-TEE, כמו Arm Firmware Framework for Armv8-A‏ (FF-A).
  • [C-SR-13] מומלץ מאוד להגביל אפליקציות מהימנות לגישה רק לזיכרון ששותף איתן באופן מפורש באמצעות הפרוטוקול שלמעלה. אם המכשיר תומך ברמת החריגה Arm S-EL2, מנהל המחיצות המאובטח אמור לאכוף אותה. אחרת, המערכת של TEE OS צריכה לאכוף את זה.

9.8. פרטיות

9.8.1. היסטוריית השימוש

מערכת Android שומרת את היסטוריית הבחירות של המשתמש ומנהלת את ההיסטוריה הזו באמצעות UsageStatsManager.

הטמעות במכשירים:

  • [C-0-1] חובה לשמור תקופת שמירה סבירה של היסטוריית המשתמש הזו.
  • [C-SR-1] מומלץ מאוד לשמור על תקופת השמירה של 14 ימים כפי שמוגדרת כברירת מחדל בהטמעת AOSP.

מערכת Android שומרת את אירועי המערכת באמצעות המזהים StatsLog, ומנהלת את ההיסטוריה הזו באמצעות StatsManager ו-IncidentManager System API.

הטמעות במכשירים:

  • [C-0-2] חובה לכלול רק את השדות שמסומנים ב-DEST_AUTOMATIC בדוח התקרית שנוצר על ידי הכיתה System API‏ IncidentManager.
  • [C-0-3] אסור להשתמש במזהי האירועים של המערכת כדי לתעד ביומן אירועים אחרים מלבד אלה שמפורטים במסמכי ה-SDK של StatsLog. אם אירועי מערכת נוספים מתועדים ביומן, יכול להיות שייעשה בהם שימוש במזהה אטום אחר בטווח שבין 100,000 ל-200,000.

9.8.2. מתבצעת הקלטה

הטמעות במכשירים:

  • [C-0-1] אסור לטעון מראש או להפיץ רכיבי תוכנה מוכנים לשימוש ששולחים את המידע הפרטי של המשתמש (למשל, הקשות על המקלדת, טקסט שמוצג במסך, דוח באג) מהמכשיר ללא הסכמת המשתמש או לנקות התראות מתמשכות.
  • [C-0-2] חובה להציג ולקבל הסכמה מפורשת מהמשתמשים לאפשרות לתעד מידע רגיש שמוצג במסך שלהם בכל פעם שהפעלת העברת מסך או הקלטת מסך מתבצעת באמצעות MediaProjection או ממשקי API קנייניים. אסור לספק למשתמשים אפשרות להשבית את הצגת הבקשה להסכמה של המשתמש בעתיד.
  • [C-0-3] חובה להציג התראה מתמשכת למשתמש בזמן שההעברה (cast) של המסך או הקלטת המסך מופעלות. כדי לעמוד בדרישות האלה, ב-AOSP מוצג סמל של התראה מתמשכת בשורת הסטטוס.

אם הטמעות במכשירים כוללות פונקציונליות במערכת שמצלמת את התוכן שמוצג במסך ו/או מתעדת את מקור האודיו שמופעל במכשיר, ולא באמצעות System API‏ ContentCaptureService או באמצעים קנייניים אחרים שמתוארים בקטע 9.8.6 תיעוד תוכן, הן:

  • [C-1-1] חובה להציג למשתמש התראה מתמשכת בכל פעם שהפונקציונליות הזו מופעלת ומתבצעת צילום או הקלטה.

אם הטמעות במכשירים כוללות רכיב מופעל מראש שיכול להקליט אודיו סביבתי ו/או להקליט את האודיו שמופעל במכשיר כדי להסיק מידע שימושי על ההקשר של המשתמש, הן:

  • [C-2-1] אסור לאחסן באחסון קבוע במכשיר או לשדר מהמכשיר את האודיו הגולמי המוקלט או כל פורמט שאפשר להמיר בחזרה לאודיו המקורי או לעותק כמעט זהה, אלא בהסכמה מפורשת של המשתמש.

'אינדיקטור מיקרופון' הוא תצוגה במסך שגלויה למשתמש כל הזמן ולא ניתן להסתיר אותה, ומאפשרת למשתמשים להבין שהמיקרופון פועל(באמצעות טקסט, צבע, סמל או שילוב ייחודי כלשהו).

'חיווי מצלמה' מתייחס לתצוגה במסך שגלויה תמיד למשתמש ולא ניתן להסתיר אותה, ומאפשרת למשתמשים להבין שהמצלמה פועלת (באמצעות טקסט, צבע, סמל או שילוב ייחודי כלשהו).

אחרי השנייה הראשונה שבה הוא מוצג, האינדיקטור יכול להשתנות מבחינה חזותית, למשל להפוך לקטן יותר, ולא חייב להופיע כפי שהוצג במקור והובן.

אפשר למזג את האינדיקטור של המיקרופון עם אינדיקטור של מצלמה מוצגת באופן פעיל, בתנאי שטקסט, סמלים או צבעים מציינים למשתמש שהשימוש במיקרופון התחיל.

אפשר למזג את האינדיקטור של המצלמה עם אינדיקטור של מיקרופון פעיל, בתנאי שטקסט, סמלים או צבעים יציינו למשתמש שהשימוש במצלמה התחיל.

אם הטמעות של מכשירים מכריזות על android.hardware.microphone, הן:

  • [C-SR-1] מומלץ מאוד להציג אינדיקטור של מיקרופון כשאפליקציה ניגשת לנתוני אודיו מהמיקרופון, אבל לא כשרק HotwordDetectionService,‏ SOURCE_HOTWORD,‏ ContentCaptureService או אפליקציות עם התפקידים שמפורטים בקטע 9.1 הרשאות עם מזהה CDD [C-3-X] ניגשים למיקרופון. .
  • [C-SR-2] מומלץ מאוד להציג את רשימת האפליקציות האחרונות והפעילות באמצעות המיקרופון, כפי שהיא מוחזרת מ-PermissionManager.getIndicatorAppOpUsageData(), יחד עם הודעות שיוך שמשויכות אליהן.
  • [C-SR-3] מומלץ מאוד לא להסתיר את האינדיקטור של המיקרופון באפליקציות מערכת שיש להן ממשקי משתמש גלויים או אינטראקציה ישירה עם משתמשים.

אם הטמעות של מכשירים מכריזות על android.hardware.camera.any, הן:

  • [C-SR-4] מומלץ מאוד להציג אינדיקטור מצלמה כשאפליקציה ניגשת לנתוני מצלמה בשידור חי, אבל לא כשהגישה למצלמה היא רק על ידי אפליקציות עם התפקידים שמפורטים בקטע 9.1 הרשאות עם מזהה CDD‏ [C-3-X].
  • [C-SR-5] מומלץ מאוד להציג את האפליקציות האחרונות והאפליקציות הפעילות באמצעות המצלמה, כפי שהיא מוחזרת מ-PermissionManager.getIndicatorAppOpUsageData(), יחד עם הודעות שיוך שמשויכות אליהן.
  • [C-SR-6] מומלץ מאוד לא להסתיר את האינדיקטור של המצלמה באפליקציות מערכת שיש להן ממשקי משתמש גלויים או אינטראקציה ישירה עם משתמשים.

9.8.3. קישוריות

אם להטמעות של המכשירים יש יציאת USB עם תמיכה במצב USB היקפי, הן:

  • [C-1-1] חובה להציג ממשק משתמש עם בקשה לקבלת הסכמה מהמשתמש לפני שמאפשרים גישה לתוכן של האחסון המשותף דרך יציאת ה-USB.

9.8.4. תנועה ברשת

הטמעות במכשירים:

  • [C-0-1] חובה להתקין מראש את אותם אישורי Root של מאגר רשות האישורים (CA) המהימן במערכת, כפי שסופקו ב-upstream של פרויקט הקוד הפתוח של Android.
  • [C-0-2] חובה לשלוח עם חנות ריקה של רשות אישורים ברמה הבסיסית של משתמש.
  • [C-0-3] חובה להציג אזהרה למשתמש על כך שעשוי להיות מעקב אחרי תעבורת הרשת, כשמוסיפים רשות אישור ברמה הבסיסית של משתמש.

אם התנועה במכשיר מנותבת דרך VPN, הטמעות במכשירים:

  • [C-1-1] חובה להציג למשתמש אזהרה שמציינת את אחד מהפרטים הבאים:
    • יכול להיות שהתנועה ברשת הזו תהיה במעקב.
    • התנועה ברשת מנותבת דרך אפליקציית ה-VPN הספציפית שמספקת את ה-VPN.

אם להטמעות במכשירים יש מנגנון שמופעל כברירת מחדל ומנתב את תעבורת הנתונים ברשת דרך שרת proxy או שער VPN (לדוגמה, טעינת שירות VPN מראש עם הרשאת android.permission.CONTROL_VPN), הן:

  • [C-2-1] חובה לבקש את הסכמת המשתמש לפני הפעלת המנגנון הזה, אלא אם ה-VPN מופעל על ידי בקר מדיניות המכשיר דרך DevicePolicyManager.setAlwaysOnVpnPackage(). במקרה כזה, המשתמש לא צריך לספק הסכמה נפרדת, אבל חובה להודיע לו על כך.

אם הטמעות במכשירים מטמיעות אמצעי להפעלה/השבתה של המשתמשים לפונקציה 'חיבור קבוע ל-VPN' באפליקציית VPN של צד שלישי, הן:

  • [C-3-1] חובה להשבית את האפשרות הזו למשתמשים באפליקציות שלא תומכות בשירות VPN שפועל כל הזמן בקובץ AndroidManifest.xml, על ידי הגדרת הערך false למאפיין SERVICE_META_DATA_SUPPORTS_ALWAYS_ON.

9.8.5. מזהי המכשיר

הטמעות במכשירים:

  • [C-0-1] חובה למנוע מאפליקציה גישה למספר הסידורי של המכשיר, ובמקרים הרלוונטיים, למספר ה-IMEI/MEID, למספר הסידורי של כרטיס ה-SIM ולמזהה המנוי הבינלאומי לנייד (IMSI), אלא אם היא עומדת באחת מהדרישות הבאות:
    • היא אפליקציה חתומה של ספק שמאומתת על ידי יצרני המכשירים.
    • קיבלה את ההרשאה READ_PRIVILEGED_PHONE_STATE.
    • יש לו הרשאות ספק כפי שמוגדרות במאמר הרשאות ספק של UICC.
    • הוא בעל מכשיר או בעל פרופיל שקיבלו את ההרשאה READ_PHONE_STATE.
    • (למספר סידורי של SIM או ICCID בלבד) קיימת דרישה בתקנות המקומיות שהאפליקציה תזהה שינויים בזהות המנוי.

9.8.6. תיעוד תוכן וחיפוש אפליקציות

Android, באמצעות System API‏ ContentCaptureService,‏ AugmentedAutofillService,‏ AppSearchGlobalManager.query או באמצעים קנייניים אחרים, תומך במנגנון להטמעות במכשירים שמאפשר לתעד את האינטראקציות הבאות של נתוני האפליקציות בין האפליקציות לבין המשתמש:

  • טקסט וגרפיקה שעבר רינדור במסך, כולל, בין היתר, התראות ונתוני עזרה דרך AssistStructure API.
  • נתוני מדיה, כמו אודיו או וידאו, שהמכשיר הקליט או הפעיל.
  • אירועי קלט (למשל מקשים, עכבר, תנועות, קול, וידאו ונגישות).
  • כל אירוע אחר שהאפליקציה מספקת למערכת דרך API‏ Content Capture או API‏ AppSearchManager, ממשק API ייעודי ל-Android עם יכולות דומות.
  • כל טקסט או נתונים אחרים שנשלחים דרך TextClassifier API ל-System TextClassifier, כלומר לשירות המערכת, כדי להבין את משמעות הטקסט וגם כדי ליצור פעולות צפויות הבאות על סמך הטקסט.
  • נתונים שנוספו לאינדקס על ידי הטמעת AppSearch בפלטפורמה, כולל, בין היתר, טקסט, גרפיקה, נתוני מדיה או נתונים דומים אחרים.

אם הטמעות במכשירים מתעדות את הנתונים שלמעלה, הן:

  • [C-1-1] חובה להצפין את כל הנתונים האלה כשהם מאוחסנים במכשיר. ההצפנה הזו עשויה להתבצע באמצעות הצפנה מבוססת-קובץ של Android, או באמצעות כל אחד מהצפנים שמפורטים כ-API מגרסה 26 ואילך, כפי שמתואר ב-Cipher SDK.
  • [C-1-2] אסור לגבות נתונים גולמיים או נתונים מוצפנים באמצעות שיטות הגיבוי של Android או כל שיטת גיבוי אחרת.
  • [C-1-3] חובה לשלוח את כל הנתונים האלה ואת היומן של המכשיר רק באמצעות מנגנון לשמירה על הפרטיות. המנגנון לשמירה על הפרטיות מוגדר כ'מנגנונים שמאפשרים רק ניתוח מצטבר ומונעים התאמה של אירועים ביומן או תוצאות נגזרות למשתמשים ספציפיים', כדי למנוע ניתוח של נתונים לכל משתמש (למשל, הטמעה באמצעות טכנולוגיית פרטיות דיפרנציאלית כמו RAPPOR).
  • [C-1-4] אסור לשייך נתונים כאלה לזהות משתמש כלשהי (למשל Account) במכשיר, אלא אם קיבלתם הסכמה מפורשת מהמשתמש בכל פעם שהנתונים משויכים.
  • [C-1-5] אסור לשתף נתונים כאלה עם רכיבים אחרים של מערכת ההפעלה שלא עומדים בדרישות שמפורטות בקטע הנוכחי (9.8.6 תיעוד תוכן), אלא בהסכמה מפורשת של המשתמש בכל פעם שמשתפים אותם.
  • [C-1-6] חובה לספק למשתמשים אפשרות למחוק נתונים כאלה שנאספים על ידי ContentCaptureService או על ידי האמצעים הקנייניים, אם הנתונים מאוחסנים במכשיר בצורה כלשהי.
  • [C-1-7] חובה לספק למשתמשים אפשרות לבטל את ההסכמה להצגת הנתונים שנאספו דרך AppSearch או באמצעים קנייניים בפלטפורמת Android, למשל במרכז האפליקציות.
  • [C-SR-1] Are STRONGLY RECOMMENDED NOT to request the INTERNET permission.
  • [C-SR-2] מומלץ מאוד לגשת לאינטרנט רק דרך ממשקי API מובְנים שמגובים בהטמעות קוד פתוח שזמינות לכולם.

אם הטמעות במכשירים כוללות שירות שמטמיע את System API‏ ContentCaptureService או AppSearchManager.index, או כל שירות קנייני שמתעד את הנתונים כפי שמתואר למעלה, הן:

  • [C-2-1] אסור לאפשר למשתמשים להחליף את השירותים באפליקציה או בשירות שאפשר להתקין, וצריך לאפשר רק לשירותים המותקנים מראש לתעד נתונים כאלה.
  • [C-2-2] אסור לאפשר לאף אפליקציה, מלבד מנגנון השירותים המובנים, לתעד נתונים כאלה.
  • [C-2-3] חובה לספק למשתמש אפשרות להשבית את השירותים.
  • [C-2-4] אסור להשמיט את האפשרות של המשתמשים לנהל את ההרשאות ל-Android שנמצאות בידי השירותים, ועליהם לפעול בהתאם למודל ההרשאות של Android כפי שמתואר בקטע 9.1. הרשאה.

  • [C-SR-3] מומלץ מאוד להפריד בין השירותים לבין רכיבי מערכת אחרים(למשל, לא לקשר את השירות או לשתף מזהי תהליכים), מלבד במקרים הבאים:

    • טלפוניה, אנשי קשר, ממשק המשתמש של המערכת ומדיה

Android, באמצעות SpeechRecognizer#onDeviceSpeechRecognizer(), מספק את היכולת לבצע זיהוי דיבור במכשיר, בלי מעורבות של הרשת. כל הטמעה של SpeechRecognizer במכשיר חייבת לציית לכללי המדיניות שמפורטים בקטע הזה.

9.8.7. גישה ללוח העריכה

הטמעות במכשירים:

  • [C-0-1] אסור להחזיר נתונים חתוכים בלוח (למשל דרך ה-API‏ ClipboardManager), אלא אם האפליקציה היא IME ברירת המחדל או שהיא האפליקציה שבה מופיע המיקוד כרגע.

9.8.8. מיקום

המיקום כולל מידע מהקלאס Location ב-Android( כמו קו רוחב, קו אורך וגובה), וגם מזהים שאפשר להמיר למיקום. המיקום יכול להיות מדויק כמו DGPS (מערכת מיקום גלובלית מדויקת) או פחות מדויק כמו מיקומים ברמת המדינה (כמו המיקום לפי קוד המדינה – MCC – קוד המדינה בנייד).

בהמשך מופיעה רשימה של סוגי מיקומים שמתקבלים ישירות מהמיקום של המשתמש או שאפשר להמיר אותם למיקום של המשתמש. זו לא רשימה מקיפה, אבל היא יכולה לשמש כדוגמה למה שאפשר להסיק מהמיקום באופן ישיר או עקיף:

  • GPS/‏GNSS/‏DGPS/‏PPP
    • פתרון למיקום גלובלי, מערכת לוויינים למיקום גלובלי או פתרון דיפרנציאלי למיקום גלובלי
    • הנתונים האלה כוללים גם מדידות GNSS גולמיות וסטטוס GNSS
      • המיקום המדויק יכול להיגזר מהמדידות הגולמיות של GNSS
  • טכנולוגיות אלחוטיות עם מזהים ייחודיים, כמו:
    • נקודות גישה ל-Wi-Fi (MAC,‏ BSSID, שם או SSID)
    • Bluetooth/BLE‏ (MAC,‏ BSSID,‏ שם או SSID)
    • UWB‏ (MAC,‏ BSSID,‏ שם או SSID)
    • מזהה של תורן סלולרי (3G, ‏ 4G, ‏ 5G… כולל כל הטכנולוגיות העתידיות של מודם סלולרי שיש להן מזהים ייחודיים)

מקור מידע ראשי הוא ממשקי ה-API של Android שדורשים את ההרשאות ACCESS_FINE_Location או ACCESS_COARSE_Location.

הטמעות במכשירים:

  • [C-0-1] אסור להפעיל או להשבית את הגדרת המיקום של המכשיר ואת הגדרות הסריקה של Wi-Fi או Bluetooth ללא הסכמה מפורשת של המשתמש או ללא יזום של המשתמש.
  • [C-0-2] חובה לספק למשתמש גישה למידע שקשור למיקום, כולל בקשות מיקום אחרונות, הרשאות ברמת האפליקציה ושימוש בסריקה של Wi-Fi או Bluetooth כדי לקבוע את המיקום.
  • [C-0-3] חובה לוודא שהאפליקציה שמשתמשת ב-Emergency Location Bypass API‏ [LocationRequest.setLocationSettingsIgnored()] היא סשן חירום ביוזמת המשתמש (למשל, חיוג למספר חירום או שליחת הודעת טקסט למספר חירום). עם זאת, ברכב יכול להתבצע התחלה של סשן חירום ללא אינטראקציה פעילה של המשתמש במקרה של זיהוי תאונה (למשל, כדי לעמוד בדרישות של eCall).
  • [C-0-4] חובה לשמור על היכולת של Emergency Location Bypass API לעקוף את הגדרות המיקום של המכשיר בלי לשנות את ההגדרות.
  • [C-0-5] חובה לתזמן התראה שמזכירה למשתמש אחרי שאפליקציה שפועלת ברקע ניגשת למיקום שלו באמצעות ההרשאה [ACCESS_BACKGROUND_LOCATION].

9.8.9. אפליקציות מותקנות

אפליקציות ל-Android שמטרגטות לרמת API 30 ואילך לא יכולות לראות פרטים על אפליקציות מותקנות אחרות כברירת מחדל (מידע נוסף זמין במאמר חשיפת החבילה במסמכי התיעוד של Android SDK).

הטמעות במכשירים:

  • [C-0-1] אסור לחשוף לאף אפליקציה שמטרגטת רמת API 30 ומעלה פרטים על אפליקציה אחרת שמותקנת במכשיר, אלא אם האפליקציה כבר יכולה לראות פרטים על האפליקציה האחרת שמותקנת במכשיר דרך ממשקי ה-API המנוהלים. זה כולל, בין היתר, פרטים שנחשפו על ידי ממשקי API מותאמים אישית שנוספו על ידי מי שמטמיע את המכשיר, או פרטים שאפשר לגשת אליהם דרך מערכת הקבצים.
  • [C-0-2] אסור לתת לאף אפליקציה גישה לקריאה או לכתיבה של קבצים בספרייה הייעודית והספציפית לאפליקציה באחסון החיצוני. היוצאים מן הכלל היחיד הם:
    • הרשות של ספק האחסון החיצוני (למשל, אפליקציות כמו DocumentsUI).
    • ספק הורדות שמשתמש בסמכויות הספק 'הורדות' כדי להוריד קבצים לאחסון של האפליקציה.
    • אפליקציות פרוטוקול העברת מדיה (MTP) בחתימה של פלטפורמה שמשתמשות בהרשאה בעלת ההרשאות ACCESS_MTP כדי לאפשר העברת קבצים למכשיר אחר.
    • אפליקציות שמתקינות אפליקציות אחרות ויש להן את ההרשאה INSTALL_PACKAGES יכולות לגשת רק לספריות 'obb' לצורך ניהול קובצי ההרחבה של APK.

9.8.10. דוח על באג בקישוריות

אם הטמעות במכשירים מכריזות על דגל התכונה android.hardware.telephony, הן:

  • [C-1-1] חובה לתמוך ביצירת דוחות על באגים שקשורים לקישוריות דרך BUGREPORT_MODE_TELEPHONY באמצעות BugreportManager.
  • [C-1-2] חובה לקבל הסכמה מהמשתמשים בכל פעם שמשתמשים ב-BUGREPORT_MODE_TELEPHONY כדי ליצור דוח, אסור לבקש מהמשתמשים להביע הסכמה לכל הבקשות העתידיות מהאפליקציה.
  • [C-1-3] אסור להחזיר את הדוח שנוצר לאפליקציה המבקשת ללא הסכמה מפורשת של המשתמש.
  • [C-1-4] דוחות שנוצרים באמצעות BUGREPORT_MODE_TELEPHONY חייבים לכלול לפחות את הפרטים הבאים:
    • TelephonyDebugService dump
    • TelephonyRegistry dump
    • WifiService dump
    • ConnectivityService dump
    • דמפ של מופע CarrierService של החבילה הקוראת (אם הוא מקושר)
    • מאגר נתונים זמני של יומן הרדיו
  • [C-1-5] אסור לכלול את הפרטים הבאים בדוחות שנוצרים:
    • כל מידע שלא קשור ישירות לניפוי באגים שקשור לקישוריות.
    • כל סוג של יומני תנועה של אפליקציות שהותקנו על ידי משתמשים או פרופילים מפורטים של אפליקציות או חבילות שהותקנו על ידי משתמשים (אפשר להשתמש במזהי משתמש, אבל אסור להשתמש בשמות חבילות).
  • יכול לכלול מידע נוסף שלא משויך לזהות של משתמש כלשהו. (למשל, יומני ספקים).

אם הטמעות של מכשירים כוללות מידע נוסף (למשל יומני ספקים) בדוחות על באגים, והמידע הזה משפיע על הפרטיות, האבטחה, הסוללה, האחסון או הזיכרון, הן:

  • [C-SR-1] מומלץ מאוד להגדיר את ברירת המחדל של הגדרת הפיתוח כ'מושבתת'. כדי לעמוד בדרישות האלה, הטמעת העזר של AOSP כוללת את האפשרות Enable verbose vendor logging בהגדרות הפיתוח, שמאפשרת לכלול בדוחות הבאגים יומני ספקים נוספים שספציפיים למכשיר.

9.8.11. שיתוף של blobs של נתונים

מערכת Android, באמצעות BlobStoreManager, מאפשרת לאפליקציות לתרום blobs של נתונים למערכת כדי לשתף אותם עם קבוצה נבחרת של אפליקציות.

אם הטמעות במכשירים תומכות ב-blobs של נתונים משותפים כפי שמתואר במסמכי התיעוד של ה-SDK, הן:

  • [C-1-1] אסור לשתף blobs של נתונים ששייכים לאפליקציות מעבר למה שהן התכוונו לאפשר (כלומר, אסור לשנות את היקף הגישה שמוגדרת כברירת מחדל ואת שאר מצבי הגישה שאפשר לציין באמצעות BlobStoreManager.session#allowPackageAccess(),‏ BlobStoreManager.session#allowSameSignatureAccess() או BlobStoreManager.session#allowPublicAccess()). ההטמעה של AOSP עומדת בדרישות האלה.
  • [C-1-2] אסור לשלוח מהמכשיר או לשתף עם אפליקציות אחרות את הגיבוב המאובטח של נתוני ה-blob (שמשמש לבקרת הגישה).

9.8.12. זיהוי מוזיקה

מערכת Android, באמצעות System API MusicRecognitionManager, תומכת במנגנון שמאפשר להטמיע במכשירים בקשות לזיהוי מוזיקה, על סמך הקלטת אודיו, ולהעביר את זיהוי המוזיקה לאפליקציה בעלת הרשאות שמטמיעה את MusicRecognitionService API.

אם הטמעות במכשירים כוללות שירות שמטמיע את System API‏ MusicRecognitionManager או כל שירות קנייני שמעביר נתוני אודיו בסטרימינג כפי שמתואר למעלה, הן:

  • [C-1-1] חובה לאכוף שהמבצע של MusicRecognitionManager מחזיק בהרשאה MANAGE_MUSIC_RECOGNITION
  • [C-1-2] חובה לאכוף שרק אפליקציה אחת לזיהוי מוזיקה שמותקנת מראש תטמיע את MusicRecognitionService.
  • [C-1-3] אסור לאפשר למשתמשים להחליף את MusicRecognitionManagerService או את MusicRecognitionService באפליקציה או בשירות שניתן להתקנה על ידי משתמשים.
  • [C-1-4] חובה לוודא שכאשר MusicRecognitionManagerService ניגשת להקלטת האודיו ומעבירה אותה לאפליקציה שמטמיעה את MusicRecognitionService, מתבצע מעקב אחר הגישה לאודיו באמצעות קריאות ל-AppOpsManager.noteOp / startOp.

אם הטמעות של MusicRecognitionManagerService או MusicRecognitionService במכשיר שומרות נתוני אודיו שהוקלטו, הן:

  • [C-2-1] אסור לאחסן אודיו גולמי או טביעות אצבע של אודיו בכלל בדיסק, או בזיכרון למשך יותר מ-14 יום.
  • [C-2-2] אסור לשתף נתונים כאלה מחוץ ל-MusicRecognitionService, אלא עם הסכמה מפורשת של המשתמש בכל פעם שהם משותפים.

9.8.13. SensorPrivacyManager

אם הטמעות במכשירים מספקות למשתמש אפשרות תוכנה להשבית את הקלט של המצלמה ו/או המיקרופון בהטמעה במכשיר, הן:

  • [C-1-1] חובה להחזיר 'true' בצורה מדויקת בשיטת ה-API הרלוונטית supportsSensorToggle()‎.
  • [C-1-2] כשאפליקציה מנסה לגשת למיקרופון או למצלמה חסומים, היא חייבת להציג למשתמש רכיב ממשק משתמש שלא ניתן לסגור, שמציין בבירור שהחיישן חסום ומבקש מהמשתמש לבחור אם להמשיך לחסום אותו או לבטל את החסימה, בהתאם להטמעה של AOSP שעומדת בדרישות האלה.
  • [C-1-3] חייב להעביר לאפליקציות רק נתוני מצלמה וקול ריקים (או מזויפים), ולא לדווח על קוד שגיאה בגלל שהמשתמש לא הפעיל את המצלמה או את המיקרופון באמצעות אמצעי ההפעלה שמוצגים למשתמש בהתאם ל-[C-1-2] שלמעלה.

9.9. הצפנת אחסון נתונים

כל המכשירים חייבים לעמוד בדרישות שמפורטות בקטע 9.9.1. מכשירים שהושקו ברמת API מוקדמת יותר מזו שמפורטת במסמך הזה פטורים מהדרישות שמפורטות בקטעים 9.9.2 ו-9.9.3. במקום זאת, הם חייבים לעמוד בדרישות שמפורטות בקטע 9.9 במסמך הגדרת התאימות ל-Android, בהתאם לרמת ה-API שבה המכשיר הושק.

9.9.1. Direct Boot

הטמעות במכשירים:

  • [C-0-1] חובה להטמיע את ממשקי ה-API של מצב הפעלה ישיר גם אם הם לא תומכים בהצפנת אחסון.

  • [C-0-2] עדיין צריך לשדר את ה-Intents‏ ACTION_LOCKED_BOOT_COMPLETED ו-ACTION_USER_UNLOCKED כדי לאותת לאפליקציות שתומכות ב-Direct Boot שמיקומי האחסון של Device Encrypted‏ (DE) ושל Credential Encrypted‏ (CE) זמינים למשתמש.

9.9.2. דרישות הצפנה

הטמעות במכשירים:

  • [C-0-1] חובה להצפין את הנתונים הפרטיים של האפליקציה (מחיצה /data), וגם את המחיצה של האחסון המשותף של האפליקציה (מחיצה /sdcard) אם היא חלק קבוע ולא ניתן להסיר אותה מהמכשיר.
  • [C-0-2] חובה להפעיל את ההצפנה של אחסון הנתונים כברירת מחדל ברגע שהמשתמש משלים את חוויית ההגדרה של המכשיר החדש.

  • [C-0-3] חובה לעמוד בדרישת ההצפנה של אחסון הנתונים שלמעלה באמצעות הטמעה של אחת משתי שיטות ההצפנה הבאות:

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) למטרות קריפטוגרפיות שונות (למשל, גם להצפנה וגם להספק מפתחות, או בשני אלגוריתמים שונים של הצפנה).
  • [C-1-15] חובה לוודא שכל הקטעים שלא נמחקו של תוכן קבצים מוצפנים באחסון מתמיד הוצפנו באמצעות שילובים של מפתח הצפנה ווקטור איפוס (IV) שתלויים גם בקובץ וגם בהיסט בקובץ. בנוסף, כל השילובים האלה חייבים להיות ייחודיים, אלא אם ההצפנה מתבצעת באמצעות חומרה של הצפנה מוטמעת שתומכת רק באורך IV של 32 ביט.
  • [C-1-16] חובה לוודא שכל שמות הקבצים המוצפנים שלא נמחקו באחסון המתמיד בתיקיות נפרדות הוצפנו באמצעות שילובים נפרדים של מפתח הצפנה ווקטור אתחול (IV).

  • [C-1-17] חובה לוודא שכל הבלוקים של המטא-נתונים של מערכת הקבצים המוצפנים באחסון המתמיד הוצפנו באמצעות שילובים נפרדים של מפתח הצפנה ווקטור אתחול (IV).

  • מפתחות שמגינים על אזורי האחסון של CE ו-DE ועל המטא-נתונים של מערכת הקבצים:

    • [C-1-7] חובה לקשר באופן קריפטוגרפי ל-Keystore שמגובל בחומרה. מאגר המפתחות הזה חייב להיות קשור ל-Verified Boot ול-Root of Trust של החומרה במכשיר.
    • [C-1-8] חובה לשייך מפתחות CE לפרטי הכניסה של המשתמש במסך הנעילה.
    • [C-1-9] מפתחות CE חייבים להיות מקושרים לקוד גישה שמוגדר כברירת מחדל כשהמשתמש לא ציין פרטי כניסה למסך הנעילה.
    • [C-1-10] חייב להיות ייחודי ומובהק, כלומר, לאף מפתח CE או DE של משתמש לא יכול להיות התאמה למפתחות CE או DE של משתמש אחר.
    • [C-1-11] חובה להשתמש במודים, באורכי המפתחות ובצפנים הנתמכים באופן מחייב.
    • [C-1-12] חייב להימחק באופן מאובטח במהלך ביטול הנעילה והנעילה של תוכנת האתחול, כפי שמתואר כאן.

  • צריך להפוך אפליקציות חיוניות שהותקנו מראש (למשל: שעון מעורר, טלפון, Messenger) למודעות לטעינה ישירה.

בפרויקט Android Open Source ב-upstream יש הטמעה מועדפת של הצפנה מבוססת-קובץ שמבוססת על תכונת ההצפנה 'fscrypt' של ליבה של Linux, והטמעה של הצפנת מטא-נתונים שמבוססת על התכונה 'dm-default-key' של ליבה של Linux.

9.9.3.2. הצפנה ברמת הבלוק לכל משתמש

אם בהטמעות במכשירים נעשה שימוש בהצפנה ברמת הבלוק לכל משתמש, הן:

  • [C-1-1] חובה להפעיל תמיכה במספר משתמשים כפי שמתואר בקטע 9.5.
  • [C-1-2] חובה לספק מחיצות לכל משתמש, באמצעות מחיצות גולמיות או באמצעות נפחים לוגיים.
  • [C-1-3] חובה להשתמש במפתחות הצפנה ייחודיים לכל משתמש להצפנת מכשירי הבלוק הבסיסיים.

  • [C-1-4] חובה להשתמש ב-AES-256-XTS להצפנה ברמת הבלוק של המחיצות של המשתמש.

  • המפתחות שמגינים על המכשירים המוצפנים ברמת הבלוק לכל משתמש:

    • [C-1-5] חייב להיות קשור באופן קריפטוגרפי ל-Keystore מגובה-חומרה. מאגר המפתחות הזה חייב להיות קשור ל-Verified Boot ול-Root of Trust של החומרה במכשיר.
    • [C-1-6] חייב להיות מקושר לפרטי הכניסה של משתמש מסוים במסך הנעילה.

אפשר להטמיע הצפנה ברמת הבלוקים לכל משתמש באמצעות התכונה 'dm-crypt' בליבה של Linux במחיצות לכל משתמש.

9.9.4. המשך לאחר הפעלה מחדש

התכונה 'המשך לאחר הפעלה מחדש' מאפשרת לבטל את נעילת האחסון ב-CE של כל האפליקציות, כולל אלה שעדיין לא תומכות בהפעלה ישירה (Direct Boot), אחרי הפעלה מחדש שהופעל על ידי עדכון OTA. התכונה הזו מאפשרת למשתמשים לקבל התראות מאפליקציות מותקנות אחרי ההפעלה מחדש.

הטמעה של 'המשך הפעלה לאחר הפעלה מחדש' צריכה להמשיך להבטיח שאם מכשיר נופל לידי תוקף, יהיה לו קשה מאוד לשחזר את הנתונים של המשתמש שמוצפנים ב-CE, גם אם המכשיר מופעל, האחסון ב-CE נעול והמשתמש ביטל את הנעילה של המכשיר אחרי קבלת עדכון OTA. כדי להתנגד להתקפות מבפנים, אנחנו גם מניחים שהתוקף מקבל גישה להעברה של מפתחות קריפטוגרפיים לחתימה.

פרטים נוספים:

  • [C-0-1] האחסון של CE לא יכול להיות קריא גם לתוקף שיש לו פיזית את המכשיר, ויש לו את היכולות והמגבלות הבאות:

    • יכולים להשתמש במפתח החתימה של כל ספק או חברה כדי לחתום על הודעות שרירותיות.
    • יכולה לגרום לקבלת עדכון OTA במכשיר.
    • יכולים לשנות את הפעולה של כל חומרה (AP, ‏ Flash וכו') מלבד כפי שמפורט בהמשך, אבל שינוי כזה כרוך בהשהיה של שעה לפחות ובמחזור הפעלה שמחסל את תוכן ה-RAM.
    • לא ניתן לשנות את הפעולה של חומרה עמידת-זיוף (למשל Titan M).
    • לא ניתן לקרוא את ה-RAM של המכשיר הפעיל.
    • לא ניתן לקבל את פרטי הכניסה של המשתמש (קוד אימות, קו ביטול נעילה או סיסמה) או לגרום לו להזין אותם בדרך אחרת.

לדוגמה, הטמעה של מכשיר שמטמיעה את כל התיאורים שמופיעים כאן ועומדת בדרישות שלהם תהיה תואמת ל-[C-0-1].

9.10. תקינות המכשיר

הדרישות הבאות מבטיחות שקיפות לגבי סטטוס תקינות המכשיר. הטמעות במכשירים:

  • [C-0-1] חובה לדווח בצורה נכונה באמצעות שיטת System API‏ PersistentDataBlockManager.getFlashLockState() אם מצב האתחול מאפשר את ה-flashing של קובץ האימג' של המערכת.

  • [C-0-2] חובה לתמוך בהפעלה מאומתת לשמירה על תקינות המכשיר.

אם הטמעות של מכשירים כבר הושקו ללא תמיכה ב-Verified Boot בגרסה קודמת של Android, ולא ניתן להוסיף תמיכה בתכונה הזו באמצעות עדכון תוכנת מערכת, יכול להיות שהן יהיו פטורות מהדרישה.

הפעלה מאומתת היא תכונה שמבטיחה את תקינות התוכנה במכשיר. אם הטמעות המכשיר תומכות בתכונה, הן:

  • [C-1-1] חובה להצהיר על ה-feature flag של הפלטפורמה android.software.verified_boot.
  • [C-1-2] חובה לבצע אימות בכל רצף הפעלה.
  • [C-1-3] חובה להתחיל את האימות ממפתח חומרה בלתי ניתן לשינוי שהוא הבסיס לאמון, ולהמשיך עד למחיצה של המערכת.
  • [C-1-4] חובה להטמיע כל שלב של אימות כדי לבדוק את השלמות והאותנטיות של כל הבייטים בשלב הבא, לפני שמריצים את הקוד בשלב הבא.
  • [C-1-5] חובה להשתמש באלגוריתמים לאימות חזקים כמו ההמלצות הנוכחיות של NIST לאלגוריתמי גיבוב (SHA-256) ולגדלים של מפתחות ציבוריים (RSA-2048).
  • [C-1-6] אסור לאפשר את השלמת האתחול אם אימות המערכת נכשל, אלא אם המשתמש מסכים לנסות את האתחול בכל מקרה. במקרה כזה, אסור להשתמש בנתונים מכל בלוקים של אחסון שלא אומתו.
  • [C-1-7] אסור לאפשר שינוי של מחיצות מאומתות במכשיר, אלא אם המשתמש פתח את נעילת האתחול באופן מפורש.
  • [C-SR-1] אם יש במכשיר כמה צ'יפים נפרדים (למשל, רדיו, מעבד תמונה יעודי), מומלץ מאוד לאמת כל שלב בתהליך האתחול של כל אחד מהצ'יפים האלה.
  • [C-1-8] חובה להשתמש באחסון עם תכונה למניעת פגיעה: לאחסון המידע לגבי הנעילה של מנהל האתחול. אחסון עם תכונה למניעת פגיעה (tamper-evident) מאפשר למחולל האתחול לזהות אם בוצעה פגיעה באחסון מתוך Android.
  • [C-1-9] חובה להציג למשתמש הודעה בזמן השימוש במכשיר ולדרוש אישור פיזי לפני שמאפשרים מעבר ממצב נעילה של תוכנת האתחול למצב ביטול נעילה של תוכנת האתחול.
  • [C-1-10] חובה להטמיע הגנה מפני חזרה לאחור למחיצות שבהן Android משתמש (למשל, מחיצות אתחול, מחיצות מערכת) ולהשתמש באחסון עם אימות מפני פגיעה כדי לאחסן את המטא-נתונים שמשמשים לקביעת גרסת מערכת ההפעלה המינימלית המותרת.
  • [C-1-11] חובה למחוק בצורה מאובטחת את כל נתוני המשתמש במהלך הנעילה והביטול של תוכנת האתחול, בהתאם ל-9.12. מחיקה של נתונים (כולל המחיצה של userdata ואת כל המרחבים של NVRAM).
  • [C-SR-2] מומלץ מאוד לאמת את כל קובצי ה-APK של האפליקציות עם הרשאות באמצעות שרשרת אמון שמקורה במחיצות שמוגנות על ידי Verified Boot.
  • [C-SR-3] מומלץ מאוד לאמת את כל הארטיפקטים ההפעלה שאפליקציה בעלת הרשאות טוענת מחוץ לקובץ ה-APK שלה (כמו קוד שנטען באופן דינמי או קוד שעבר הידור) לפני שמפעילים אותם, או מומלץ מאוד לא להפעיל אותם בכלל.
  • צריך להטמיע הגנה מפני החזרה לגרסה קודמת בכל רכיב עם קושחת תוכנה קבועה (למשל, מודם, מצלמה) ולהשתמש באחסון עם אימות מפני פגיעה כדי לאחסן את המטא-נתונים שמשמשים לקביעת הגרסה המינימלית המותרת.

אם הטמעות של מכשירים כבר הושקו בלי תמיכה בדרישות C-1-8 עד C-1-11 בגרסה קודמת של Android, ולא ניתן להוסיף תמיכה בדרישות האלה באמצעות עדכון תוכנת המערכת, יכול להיות שהן יקבלו פטור מהדרישות.

ב-Android Open Source Project (פרויקט קוד פתוח של Android) יש הטמעה מועדפת של התכונה הזו במאגר external/avb/, שאפשר לשלב ב-bootloader שמשמש לטעינת Android.

הטמעות במכשירים:

  • [C-0-3] חובה לתמוך באימות קריפטוגרפית של תוכן הקובץ באמצעות מפתח מהימן, בלי לקרוא את הקובץ כולו.
  • [C-0-4] אסור לאפשר לבקשות הקריאה בקובץ מוגן להצליח כשתוכן הקריאה לא מאומת באמצעות מפתח מהימן.

אם הטמעות במכשירים כבר הושקו בגרסה קודמת של Android ללא היכולת לאמת את תוכן הקובץ באמצעות מפתח מהימן, ולא ניתן להוסיף תמיכה בתכונה הזו באמצעות עדכון תוכנת המערכת, יכול להיות שהן יהיו פטורות מהדרישה. בפרויקט Android Open Source ב-upstream יש הטמעה מועדפת של התכונה הזו, שמבוססת על התכונה fs-verity בליבה של Linux.

הטמעות במכשירים:

אם הטמעות במכשירים תומכות ב-Android Protected Confirmation API, הן:

  • [C-3-1] חובה לדווח על true ב-API של ConfirmationPrompt.isSupported().

  • [C-3-2] חובה לוודא שקוד שפועל במערכת ההפעלה Android, כולל הליבה שלה, זדוני או אחר, לא יכול ליצור תגובה חיובית ללא אינטראקציה של משתמש.

  • [C-3-3] חובה לוודא שהמשתמש יכול לבדוק ולאשר את ההודעה שהוצגה, גם אם מערכת ההפעלה של Android, כולל הליבה שלה, נפרצה.

9.11. מפתחות ופרטי כניסה

מערכת Android Keystore מאפשרת למפתחי אפליקציות לאחסן מפתחות קריפטוגרפיים בקונטיינר ולהשתמש בהם בפעולות קריפטוגרפיות באמצעות KeyChain API או Keystore API. הטמעות במכשירים:

  • [C-0-1] חובה לאפשר ייבוא או יצירה של לפחות 8,192 מפתחות.
  • [C-0-2] האימות במסך הנעילה חייב לכלול מרווח זמן בין ניסיונות כושלים. כש-n הוא מספר הניסיונות הכושלים, מרווח הזמן חייב להיות לפחות 30 שניות עבור 9 < n < 30. אם n > 29, הערך של מרווח הזמן חייב להיות לפחות 30*2^floor((n-30)/10)) שניות או לפחות 24 שעות, לפי הערך הנמוך מביניהם.
  • לא צריך להגביל את מספר המפתחות שאפשר ליצור

כשהטמעת המכשיר תומכת במסך נעילה מאובטח, היא:

  • [C-1-1] חובה לגבות את הטמעת מאגר המפתחות באמצעות סביבת הפעלה מבודדת.
  • [C-1-2] חובה שתהיה הטמעה של אלגוריתמים קריפטוגרפיים מסוג RSA,‏ AES,‏ ECDSA ו-HMAC, ופונקציות גיבוב ממשפחת MD5,‏ SHA1 ו-SHA-2, כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בליבה ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד הליבה או קוד מרחב המשתמש עשוי לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. הפרויקט של Android בקוד פתוח (AOSP) עומד בדרישות האלה באמצעות ההטמעה של Trusty, אבל יש גם אפשרויות חלופיות: פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת של בידוד תקין שמבוסס על hypervisor, שעבר בדיקה על ידי צד שלישי.
  • [C-1-3] חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ולאפשר שימוש במפתחות שמקושרים לאימות רק אחרי אימות מוצלח. חובה לאחסן את פרטי הכניסה של מסך הנעילה באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. בפרויקט הקוד הפתוח של Android שמשמש כמקור (upstream) יש את שכבת האובייקטיפיקציה של החומרה (HAL) של Gatekeeper ואת Trusty, שאפשר להשתמש בהם כדי לעמוד בדרישות האלה.
  • [C-1-4] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה לאימות מוגן בחומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה לאימות עם מספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת מהדרכים לעמוד בדרישות האלה היא לשתף את אותו מפתח אימות, אלא אם מיוצרות לפחות 100,000 יחידות של מק"ט נתון. אם מיוצרות יותר מ-100,000 יחידות של מק"ט מסוים, יכול להיות שייעשה שימוש במפתח אחר לכל 100,000 יחידות.

הערה: אם הטמעת מכשיר כבר הופעלה בגרסה קודמת של Android, המכשיר הזה פטור מהדרישה לכלול מאגר מפתחות שמגודר על ידי סביבת הפעלה מבודדת ולתמוך באימות המפתחות, אלא אם הוא מצהיר על התכונה android.hardware.fingerprint, שדורשת מאגר מפתחות שמגודר על ידי סביבת הפעלה מבודדת.

  • [C-1-5] חובה לאפשר למשתמש לבחור את זמן הקצוב לתפוגה במצב שינה כדי לעבור ממצב 'לא נעול' למצב 'נעול', עם זמן קצוב לתפוגה מינימלי של עד 15 שניות. במכשירים לרכב, שמנעלים את המסך בכל פעם שהיחידה הראשית מושבתת או שהמשתמש עובר, יכול להיות שלא תהיה הגדרה של זמן קצוב ליציאה ממצב שינה.
  • [C-1-6] חובה לתמוך באחת מהאפשרויות הבאות:
    • IKeymasterDevice 3.0,
    • IKeymasterDevice 4.0,
    • IKeymasterDevice 4.1, או
    • IKeyMintDevice גרסה 1.
  • [C-SR-1] מומלץ מאוד לתמוך בגרסה 1 של IKeyMintDevice.

9.11.1. אימות ומסך נעילה מאובטחים

ההטמעה ב-AOSP מבוססת על מודל אימות מדורג, שבו אימות ראשי שמבוסס על מפעל ידע יכול להיות מגובה באימות ביומטרי משני חזק או במודלים משניים חלשים יותר.

הטמעות במכשירים:

  • [C-SR-1] מומלץ מאוד להגדיר רק אחת מהשיטות הבאות כשיטת האימות הראשית:
    • קוד אימות מספרי
    • סיסמה אלפאנומרית
    • דפוס החלקה ברשת של 9 נקודות בדיוק (3x3)

שימו לב שבמסמך הזה הן נקראות שיטות האימות הראשיות המומלצות.

אם הטמעות במכשירים מוסיפות או משנות את שיטות האימות הראשיות המומלצות ומשתמשות בשיטת אימות חדשה כדרך מאובטחת לנעילת המסך, שיטת האימות החדשה:

אם הטמעות במכשירים מוסיפות או משנות את שיטות האימות כדי לבטל את נעילת מסך הנעילה אם הוא מבוסס על סוד ידוע, ומשתמשות בשיטת אימות חדשה כדי להתייחס אליה כאל דרך מאובטחת לנעילת המסך:

  • [C-3-1] האנטרופיה של האורך הקצר ביותר של קלט מותר חייבת להיות גדולה מ-10 ביט.
  • [C-3-2] ההאנטרופיה המקסימלית של כל ערכי הקלט האפשריים חייבת להיות גדולה מ-18 ביט.
  • [C-3-3] שיטת האימות החדשה אסור שתחליף אף אחת משיטות האימות הראשיות המומלצות (כלומר, קוד אימות, קו ביטול נעילה, סיסמה) שמוטמעות ומסופקות ב-AOSP.
  • [C-3-4] חובה להשבית את שיטת האימות החדשה כשאפליקציית Device Policy Controller‏ (DPC) מגדירה את מדיניות הדרישות לסיסמה באמצעות DevicePolicyManager.setRequiredPasswordComplexity()‎ עם קבוע מורכבות מגביל יותר מ-PASSWORD_COMPLEXITY_NONE, או באמצעות השיטה DevicePolicyManager.setPasswordQuality()‎ עם קבוע מגביל יותר מ-PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • [C-3-5] שיטות אימות חדשות חייבות לחזור לשיטות האימות הראשיות המומלצות (למשל, מספר PIN, דפוס או סיסמה) פעם ב-72 שעות או פחות, או לחשוף בבירור למשתמש שחלק מהנתונים לא יגובו כדי לשמור על פרטיות הנתונים שלו.

אם הטמעות במכשירים מוסיפות או משנות את שיטות האימות הראשיות המומלצות לביטול הנעילה של מסך הנעילה, ומשתמשות בשיטת אימות חדשה שמבוססת על מידע ביומטרי כדי להתייחס אליה כאל דרך מאובטחת לנעילת המסך, השיטה החדשה:

  • [C-4-1] חייב לעמוד בכל הדרישות שמפורטות בקטע 7.3.10 לסיווג 1 (לשעבר נוחות).
  • [C-4-2] חובה שיהיה מנגנון חלופי לשימוש באחת משיטות האימות הראשיות המומלצות שמבוססות על סוד ידוע.
  • [C-4-3] חובה להשבית ולאפשר רק לאימות הראשי המומלץ לבטל את נעילת המסך, אחרי שאפליקציית Device Policy Controller‏ (DPC) מגדירה את מדיניות התכונה של מגן המסך באמצעות קריאה לשיטה DevicePolicyManager.setKeyguardDisabledFeatures() עם כל אחד מהדגלים הביומטריים המשויכים (כלומר KEYGUARD_DISABLE_BIOMETRICS,‏ KEYGUARD_DISABLE_FINGERPRINT,‏ KEYGUARD_DISABLE_FACE או KEYGUARD_DISABLE_IRIS).

אם שיטות האימות הביומטרי לא עומדות בדרישות של סיווג 3 (לשעבר חזק) כפי שמתואר בסעיף 7.3.10:

  • [C-5-1] חובה להשבית את השיטות אם באפליקציית Device Policy Controller‏ (DPC) הוגדרה מדיניות האיכות של דרישות הסיסמה באמצעות DevicePolicyManager.setRequiredPasswordComplexity()‎ עם קטגוריית מורכבות מגבילה יותר מ-PASSWORD_COMPLEXITY_LOW, או באמצעות השיטה DevicePolicyManager.setPasswordQuality()‎ עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • [C-5-2] חובה להציג למשתמש אתגר לאימות הראשי המומלץ (למשל: מספר PIN, דפוס, סיסמה) כפי שמתואר בסעיף 7.3.10 בקטע [C-1-7] ובקטע [C-1-8].
  • [C-5-3] אסור להתייחס לשיטות כמסך נעילה מאובטח, והן חייבות לעמוד בדרישות שמתחילות ב-C-8 בקטע הזה בהמשך.

אם הטמעות במכשירים מוסיפות או משנות את שיטות האימות כדי לבטל את נעילת מסך הנעילה, ושיטת אימות חדשה מבוססת על אסימון פיזי או על המיקום:

  • [C-6-1] חובה שיהיה להם מנגנון חלופי לשימוש באחת משיטות האימות הראשיות המומלצות שמבוססות על סוד ידוע ועומדות בדרישות לטיפול כמסך נעילה מאובטח.
  • [C-6-2] חובה להשבית את השיטה החדשה ולאפשר רק לאחת משיטות האימות הראשיות המומלצות לבטל את נעילת המסך, כשאפליקציית Device Policy Controller (DPC) מגדירה את המדיניות באמצעות:
  • [C-6-3] חובה לבצע אצל המשתמש אתגר לאימות באמצעות אחת משיטות האימות הראשיות המומלצות (למשל, קוד אימות, קו ביטול נעילה או סיסמה) לפחות פעם ב-4 שעות.
  • [C-6-4] אסור להתייחס לשיטה החדשה כמסך נעילה מאובטח, וצריך לפעול לפי האילוצים שמפורטים בקטע C-8 בהמשך.

אם למכשירים יש נעילת מסך מאובטחת והם כוללים סוכן אמון אחד או יותר שמטמיע את TrustAgentService System API, הם:

  • [C-7-1] חובה להציג אינדיקציה ברורה בתפריט ההגדרות ובמסך הנעילה כשנעילת המכשיר מושהית או שאפשר לבטל את הנעילה באמצעות סוכני אמון. לדוגמה, ב-AOSP מתקיים הדרישה הזו באמצעות הצגת תיאור טקסט של ההגדרות 'נעילה אוטומטית' ו'לחצן ההפעלה נועל באופן מיידי' בתפריט ההגדרות וכן סמל בולט במסך הנעילה.
  • [C-7-2] חובה לכבד ולהטמיע באופן מלא את כל ממשקי ה-API של סוכני האמון בכיתה DevicePolicyManager, כמו הקבועה KEYGUARD_DISABLE_TRUST_AGENTS.
  • [C-7-3] אסור להטמיע באופן מלא את הפונקציה TrustAgentService.addEscrowToken() במכשיר שמשמש כמכשיר אישי ראשי (למשל, מכשיר נייד), אבל מותר להטמיע את הפונקציה באופן מלא בהטמעות של מכשירי שיתוף (למשל, Android Television או מכשיר לכלי רכב).
  • [C-7-4] חובה להצפין את כל הטוקנים המאוחסנים שנוספו על ידי TrustAgentService.addEscrowToken().
  • [C-7-5] אסור לאחסן את מפתח ההצפנה או את אסימון ההתחייבות להחזקה באותו מכשיר שבו נעשה שימוש במפתח. לדוגמה, מותר למפתח שמאוחסן בטלפון לפתוח את נעילת חשבון המשתמש בטלוויזיה. במכשירים לכלי רכב, אסור לאחסן את אסימון ה-escrow באף חלק ברכב.
  • [C-7-6] חובה להודיע למשתמש על ההשלכות של האבטחה לפני שמפעילים את אסימון ה-Escrow כדי לפענח את אחסון הנתונים.
  • [C-7-7] חובה שיהיה מנגנון חלופי לשימוש באחת משיטות האימות הראשיות המומלצות.
  • [C-7-8] חובה לבצע אחת מהשיטות המומלצות לאימות ראשוני (למשל: קוד אימות, קו ביטול נעילה, סיסמה) לפחות פעם אחת בכל 72 שעות או פחות, אלא אם יש חשש לגבי בטיחות המשתמש (למשל: הסחת דעת של הנהג).
  • [C-7-9] חובה לבקש מהמשתמש לבצע אחת משיטות האימות הראשיות המומלצות (למשל: קוד אימות, דפוס, סיסמה) כפי שמתואר בקטע 7.3.10, אלא אם יש חשש לבטיחות המשתמש (למשל, הסחת דעת של הנהג).
  • [C-7-10] אסור להתייחס אליו כמסך נעילה מאובטח, וצריך לפעול בהתאם למגבלות שמפורטות בקטע C-8 בהמשך.
  • [C-7-11] אסור לאפשר ל-TrustAgents במכשירים אישיים ראשיים (למשל: מכשירים ניידים) לבטל את הנעילה של המכשיר, וניתן להשתמש בהם רק כדי לשמור על מצב ביטול הנעילה של מכשיר שכבר נעול למשך עד 4 שעות לכל היותר. ההטמעה שמוגדרת כברירת מחדל של TrustManagerService ב-AOSP עומדת בדרישות האלה.
  • [C-7-12] חובה להשתמש בערוץ תקשורת מאובטח מבחינה קריפטוגרפית (למשל UKEY2) כדי להעביר את אסימון ההתחייבות להחזקה לצורך העברה (escrow) ממכשיר האחסון למכשיר היעד.

אם הטמעות במכשירים מוסיפות או משנות את שיטות האימות כדי לבטל את נעילת מסך הנעילה שאינו מסך נעילה מאובטח כפי שמתואר למעלה, ומשתמשות בשיטת אימות חדשה כדי לבטל את נעילת מסך הנעילה:

  • [C-8-1] חובה להשבית את השיטה החדשה כשאפליקציית Device Policy Controller‏ (DPC) מגדירה את מדיניות איכות הסיסמאות באמצעות השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_NONE, או באמצעות השיטה DevicePolicyManager.setRequiredPasswordComplexity() עם קבוע מורכבות מגביל יותר מ-'PASSWORD_COMPLEXITY_NONE'.
  • [C-8-2] אסור לאפס את הטיימר לתפוגת התוקף של הסיסמאות שהוגדר על ידי DevicePolicyManager.setPasswordExpirationTimeout().
  • [C-8-3] אסור לחשוף ממשק API לשימוש באפליקציות צד שלישי כדי לשנות את מצב הנעילה.

אם הטמעות במכשירים תומכות במצבי צריכת אנרגיה נפרדים של המסך דרך DeviceStateManager וגם תומכות במצבי נעילת מסך נפרדים דרך KeyguardDisplayManager, הן:

  • [C-SR-2] מומלץ מאוד להשתמש בפרטי כניסה שעומדים בדרישות שמפורטות בקטע 9.11.1, או בפרטי כניסה ביומטריים שעומדים לפחות במפרט של סיווג 1 שמפורט בקטע 7.3.10, כדי לאפשר ביטול נעילה עצמאי מהמסך של המכשיר שמוגדר כברירת מחדל.
  • [C-SR-3] מומלץ מאוד להגביל את הנעילה של מסך נפרד באמצעות זמן קצוב לתפוגת התצוגה.
  • [C-SR-4] מומלץ מאוד לאפשר למשתמש לנעול את כל המסכים באופן גלובלי באמצעות נעילת המכשיר הנייד הראשי.

9.11.2. StrongBox

מערכת Android Keystore מאפשרת למפתחי אפליקציות לאחסן מפתחות קריפטוגרפיים במעבד מאובטח ייעודי, וגם בסביבת ההפעלה המבודדת שמתוארת למעלה. מעבד מאובטח ייעודי כזה נקרא 'StrongBox'. הדרישות שמפורטות בהמשך, מ-C-1-3 ועד C-1-11, מגדירות את הדרישות שהמכשיר צריך לעמוד בהן כדי להיחשב כ-StrongBox.

הטמעות במכשירים עם מעבד מאובטח ייעודי:

  • [C-SR-1] מומלץ מאוד לתמוך ב-StrongBox. סביר להניח ש-StrongBox יהפוך לדרישה בגרסה עתידית.

אם הטמעות במכשירים תומכות ב-StrongBox, הן:

  • [C-1-1] חובה להצהיר על FEATURE_STRONGBOX_KEYSTORE.

  • [C-1-2] חובה לספק חומרה מאובטחת ייעודית שמשמשת לגיבוי של מאגר המפתחות ולאימות מאובטח של משתמשים. אפשר להשתמש בחומרה המאובטחת הייעודית גם למטרות אחרות.

  • [C-1-3] חובה שיהיה מעבד נפרד שלא משתף מטמון, זיכרון DRAM, מעבדי משנה או משאבי ליבה אחרים עם מעבד האפליקציות (AP).

  • [C-1-4] חובה לוודא שציוד היקפי שמשותף עם נקודת הגישה לא יכול לשנות את העיבוד של StrongBox בשום צורה, או לקבל מידע כלשהו מ-StrongBox. שרת ה-AP עשוי להשבית או לחסום את הגישה ל-StrongBox.

  • [C-1-5] חייב להיות שעון פנימי עם דיוק סביר (+-10%) שלא ניתן לזייף על ידי נקודת הגישה.

  • [C-1-6] חייב להיות גנרטור של מספרים אקראיים אמיתיים שמייצר פלט שמופץ באופן אחיד ולא ניתן לחיזוי.

  • [C-1-7] חייב להיות עמיד בפני פגיעה, כולל עמידות בפני חדירה פיזית ופגיעה בתוכנה.

  • [C-1-8] חייבת להיות עמידות בערוצים צדדיים, כולל עמידות נגד זליגת מידע דרך כוח, תזמון, קרינה אלקטרומגנטית וערוצים צדדיים של קרינה תרמית.

  • [C-1-9] חובה שיהיה אחסון מאובטח שמבטיח את הסודיות, התקינות, האותנטיות, העקביות והעדכניות של התוכן. אסור שאפשר יהיה לקרוא את האחסון או לשנות אותו, אלא אם הדבר מותאם ל-StrongBox APIs.

  • כדי לאמת תאימות ל-[C-1-3] עד [C-1-9], הטמעות במכשירים:

    • [C-1-10] חובה לכלול את החומרה שקיבלה אישור בהתאם לפרופיל ההגנה של מעגלים משולבים מאובטחים BSI-CC-PP-0084-2014 או שעבר הערכה במעבדת בדיקות מוסמכת ברמה לאומית, שכוללת הערכה של נקודות חולשה עם פוטנציאל תקיפה גבוה בהתאם ל-Common Criteria Application of Attack Potential to Smartcards.
    • [C-1-11] חובה לכלול את הקושחה שעברה הערכה במעבדת בדיקה מוסמכת ברמה לאומית, שכוללת הערכה של נקודות חולשה פוטנציאליות להתקפה ברמה גבוהה בהתאם ל-Common Criteria Application of Attack Potential to Smartcards.
    • [C-SR-2] מומלץ מאוד לכלול את החומרה שנבדקה באמצעות יעד אבטחה, רמת אמון הערכה (EAL) 5, עם תוספת של AVA_VAN.5. סביר להניח שהאישור EAL 5 יהפוך לדרישה בגרסה עתידית.

  • מומלץ מאוד להשתמש ב-[C-SR-3] כדי לספק עמידות בפני התקפות מבפנים (IAR). המשמעות היא שגורם פנימי עם גישה למפתחות החתימה של הקושחה לא יכול ליצור קושחה שגורמת לדליפה של סודות מ-StrongBox, לעקוף את דרישות האבטחה הפונקציונליות או לאפשר גישה אחרת לנתוני משתמשים רגישים. הדרך המומלצת להטמיע את IAR היא לאפשר עדכוני קושחה רק כשסיסמת המשתמש הראשית מסופקת דרך ה-HAL של IAuthSecret.

9.11.3. המסמך לאימות הזהות

כדי להגדיר את מערכת פרטי הכניסה לזהות ולהשתמש בה, צריך להטמיע את כל ממשקי ה-API בחבילה android.security.identity.*. ממשקי ה-API האלה מאפשרים למפתחי אפליקציות לאחסן ולשלוף מסמכים של זהות משתמשים. הטמעות במכשירים:

  • [C-SR-1] מומלץ מאוד להטמיע את מערכת פרטי הכניסה לזיהוי.

אם הטמעות במכשירים מטמיעות את מערכת פרטי הכניסה לזיהוי, הן:

  • [C-1-1] חובה להחזיר ערך שאינו null בשיטה IdentityCredentialStore#getInstance().

  • [C-1-2] חובה להטמיע את מערכת פרטי הכניסה לזהות (למשל ממשקי ה-API של android.security.identity.*) באמצעות קוד שמתקשר עם אפליקציה מהימנה באזור שמבודד בצורה מאובטחת מהקוד שפועל בליבה ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד הליבה או קוד מרחב המשתמש עשוי לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA.

  • [C-1-3] הפעולות הקריפטוגרפיות הנדרשות להטמעת מערכת פרטי הכניסה לזיהוי (למשל, ממשקי ה-API של android.security.identity.*) חייבות להתבצע באופן מלא באפליקציה המהימנה, וחומר המפתח הפרטי לעולם לא יכול לצאת מסביבת הביצוע המבודדת, אלא אם נדרש באופן ספציפי על ידי ממשקי API ברמה גבוהה יותר (למשל, השיטה createEphemeralKeyPair()‎).

  • [C-1-4] חובה להטמיע את האפליקציה המהימנה באופן שלא ישפיע על מאפייני האבטחה שלה (למשל, נתוני פרטי הכניסה לא יפורסמו אלא אם התנאים לבקרת הגישה מתקיימים, לא ניתן ליצור MAC לנתונים שרירותיים), גם אם מערכת Android פועלת באופן שגוי או נפרצה.

9.12. מחיקת נתונים

כל הטמעות המכשירים:

  • [C-0-1] חובה לספק למשתמשים מנגנון לביצוע 'איפוס לנתוני היצרן'.
  • [C-0-2] חובה למחוק את כל הנתונים במערכת הקבצים של userdata כשמבצעים 'איפוס לנתוני היצרן'.
  • [C-0-3] חובה למחוק את הנתונים באופן שיעמוד בתקני התעשייה הרלוונטיים, כמו NIST SP800-88, כשמעבירים את המכשיר ל'איפוס לנתוני היצרן'.
  • [C-0-4] חובה להפעיל את התהליך 'איפוס להגדרות המקוריות' שמתואר למעלה כשאפליקציית הבקר לניהול מדיניות המכשירים (DPC) של המשתמש הראשי קוראת ל-API‏ DevicePolicyManager.wipeData().
  • יכול להיות שתהיה אפשרות למחיקת נתונים מהירה שמתבצעת רק מחיקה לוגית של הנתונים.

9.13. מצב הפעלה בטוח

ב-Android יש מצב אתחול בטוח שמאפשר למשתמשים להפעיל את המכשיר במצב שבו רק אפליקציות מערכת מותקנות מראש יכולות לפעול, וכל האפליקציות של צד שלישי מושבתות. המצב הזה, שנקרא 'מצב הפעלה בטוח', מאפשר למשתמש להסיר אפליקציות צד שלישי שעלולות להזיק.

הטמעות במכשירים הן:

  • [C-SR-1] STRONGLY RECOMMENDED to implement Safe Boot Mode

אם הטמעות במכשירים מיישמות את מצב ההפעלה הבטוח, הן:

  • [C-1-1] חובה לספק למשתמש אפשרות להיכנס למצב הפעלה בטוח באופן שלא ניתן להפרעה מאפליקציות צד שלישי שמותקנות במכשיר, אלא אם אפליקציית הצד השלישי היא 'בקר מדיניות של מכשיר' והגדירה את הדגל UserManager.DISALLOW_SAFE_BOOT כ-true.

  • [C-1-2] חובה לספק למשתמש את היכולת להסיר כל אפליקציה של צד שלישי במצב בטוח.

  • צריך לספק למשתמש אפשרות להיכנס למצב הפעלה בטוח מתפריט האתחול באמצעות תהליך עבודה שונה מזה של הפעלה רגילה.

9.14. בידוד של מערכת הרכב

מכשירי Android Automotive צפויים להחליף נתונים עם תת-מערכות קריטיות ברכב באמצעות HAL של הרכב כדי לשלוח ולקבל הודעות ברשתות הרכב, כמו CAN bus.

כדי לאבטח את חילופי הנתונים, אפשר להטמיע תכונות אבטחה מתחת לשכבות המסגרת של Android כדי למנוע אינטראקציה זדונית או לא מכוונת עם המערכות המשניות האלה.

9.15. תוכניות מינויים

'תוכניות מינויים' מתייחסות לפרטי התוכנית של יחסי החיוב שספק הסלולר מספק דרך SubscriptionManager.setSubscriptionPlans().

כל הטמעות המכשירים:

  • [C-0-1] חובה להחזיר תוכניות מינויים רק לאפליקציה של ספק הסלולר שממנה הן סופקו במקור.
  • [C-0-2] אסור לגבות או להעלות מרחוק תוכניות מינויים.
  • [C-0-3] חובה לאפשר רק שינויים מברירת המחדל, כמו SubscriptionManager.setSubscriptionOverrideCongested(), מאפליקציית ספק הסלולר שמספקת כרגע תוכניות מינויים תקפות.

9.16. העברת נתוני אפליקציות

אם הטמעות במכשירים כוללות יכולת להעביר נתונים ממכשיר למכשיר אחר ולא מגבילות את נתוני האפליקציה שהיא מעתיקה לנתונים שהוגדרו על ידי מפתח האפליקציה במניפסט באמצעות המאפיין android:fullBackupContent, הן:

  • [C-1-1] אסור להתחיל העברות של נתוני אפליקציות ממכשירים שבהם המשתמש לא הגדיר אימות ראשי, כפי שמתואר בקטע 9.11.1 מסך נעילה מאובטח ואימות.
  • [C-1-2] חובה לאשר באופן מאובטח את האימות הראשי במכשיר המקור, ולאשר עם המשתמש את הכוונה להעתיק את הנתונים במכשיר המקור לפני העברת הנתונים.
  • [C-1-3] חובה להשתמש באימות של מפתח אבטחה כדי לוודא שגם מכשיר המקור וגם מכשיר היעד בהעברה בין מכשירים הם מכשירי Android חוקיים ושהתוכנה שלהם לאתחול נעולה.
  • [C-1-4] חובה להעביר את נתוני האפליקציה רק לאותה אפליקציה במכשיר היעד, עם אותו שם חבילה ואותו אישור חתימה.
  • [C-1-5] חובה להציג בתפריט ההגדרות אינדיקציה לכך שהנתונים הועברו למכשיר המקור באמצעות מיגרציית נתונים בין מכשירים. המשתמש לא אמור להיות מסוגל להסיר את ההנחיה הזו.

10. בדיקת תאימות של תוכנות

הטמעות של מכשירים חייבות לעבור את כל הבדיקות שמתוארות בקטע הזה. עם זאת, חשוב לזכור שאף חבילת בדיקות תוכנה לא מקיפה לחלוטין. לכן, מומלץ מאוד למטמיעים של מכשירים לבצע את המספר המינימלי האפשרי של שינויים בהטמעה המועדפת והמומלצת של Android שזמינה בפרויקט Android Open Source. כך תוכלו לצמצם את הסיכון להוספת באגים שיוצרים אי-תאימות, שדורשים עבודה מחדש ועדכוני מכשירים פוטנציאליים.

10.1. חבילה לבדיקות תאימות (CTS)

הטמעות במכשירים:

  • [C-0-1] חובה לעבור את Android Compatibility Test Suite‏ (CTS) שזמין ב-Android Open Source Project, באמצעות תוכנת האספקה הסופית במכשיר.

  • [C-0-2] חובה לוודא תאימות במקרים של עמימות ב-CTS ובכל הטמעה מחדש של חלקים מקוד המקור של ההפניה.

ה-CTS מיועד להרצה במכשיר בפועל. כמו כל תוכנה, גם CTS יכול להכיל באגים. הגרסאות של CTS יהיו נפרדות מהגדרת התאימות הזו, ויכול להיות שיושקו כמה גרסאות של CTS ל-Android 12.

הטמעות במכשירים:

  • [C-0-3] חובה לעבור את גרסת CTS העדכנית ביותר שזמינה בזמן השלמת תוכנת המכשיר.

  • מומלץ להשתמש בהטמעת העזר ב-Android Open Source Tree כמה שיותר.

10.2. CTS Verifier

CTS Verifier נכלל בחבילת בדיקות התאימות, והוא מיועד להפעלה על ידי מפעיל אנושי כדי לבדוק פונקציונליות שלא ניתן לבדוק באמצעות מערכת אוטומטית, כמו הפעולה הנכונה של מצלמה וחיישנים.

הטמעות במכשירים:

  • [C-0-1] חובה להריץ בצורה נכונה את כל התרחישים הרלוונטיים באימות CTS.

ב-CTS Verifier יש בדיקות לסוגים רבים של חומרה, כולל חומרה חלקית שהיא אופציונלית.

הטמעות במכשירים:

  • [C-0-2] חובה לעבור את כל הבדיקות של החומרה שיש במכשיר. לדוגמה, אם במכשיר יש תאוצה, חובה להריץ בצורה נכונה את תרחיש הבדיקה של התאוצה ב-CTS Verifier.

מותר לדלג על תרחישי בדיקה של תכונות שצוינו כאופציונליות במסמך הגדרת התאימות הזה, או להשמיט אותן.

  • [C-0-2] כל מכשיר וכל גרסה של build חייבים להריץ בצורה תקינה את CTS Verifier, כפי שצוין למעלה. עם זאת, מאחר שגרסאות build רבות דומות מאוד, לא צפוי שמטמיעים של מכשירים ירוצו במפורש את CTS Verifier על גרסאות build ששונות רק בדרכים טריוויאליות. באופן ספציפי, הטמעות של מכשירים ששונות מהטמעה שעברה את CTS Verifier רק במיקומים שונים, בסמלי מותג וכו', יכולות להשמיט את הבדיקה של CTS Verifier.

11. תוכנה שניתן לעדכן

  • [C-0-1] הטמעות של מכשירים חייבות לכלול מנגנון להחלפת כל תוכנת המערכת. המנגנון לא חייב לבצע שדרוגים 'בזמן אמת', כלומר יכול להיות שיהיה צורך בהפעלה מחדש של המכשיר. אפשר להשתמש בכל שיטה, בתנאי שהיא יכולה להחליף את כל התוכנות שמותקנות מראש במכשיר. לדוגמה, כל אחת מהגישות הבאות תעמוד בדרישות האלה:

    • הורדות 'Over-the-air (OTA)' עם עדכון אופליין באמצעות הפעלה מחדש.
    • עדכונים 'מחוברים' בחיבור USB ממחשב מארח.
    • עדכונים 'לא מקוונים' באמצעות הפעלה מחדש ועדכון מקובץ באחסון נשלף.

  • [C-0-2] מנגנון העדכון שבו נעשה שימוש חייב לתמוך בעדכונים בלי למחוק את נתוני המשתמשים. כלומר, מנגנון העדכון חייב לשמור על נתונים פרטיים של האפליקציה ועל נתונים משותפים של האפליקציה. שימו לב שתוכנת Android ב-upstream כוללת מנגנון עדכון שעומד בדרישות האלה.

  • [C-0-3] חובה לחתום על כל העדכון, ומנגנון העדכון במכשיר חייב לאמת את העדכון והחתימה באמצעות מפתח ציבורי שנשמר במכשיר.

  • [C-SR-1] מומלץ מאוד שמנגנון החתימה יבצע גיבוב של העדכון באמצעות SHA-256 ויאמת את הגיבוב באמצעות המפתח הציבורי באמצעות ECDSA NIST P-256.

אם הטמעות המכשיר כוללות תמיכה בחיבור נתונים ללא חיוב לפי שימוש, כמו פרופיל 802.11 או Bluetooth PAN (רשת אזור אישית), הן:

  • [C-1-1] חובה לתמוך בהורדות OTA עם עדכון אופליין באמצעות הפעלה מחדש.

בהטמעות של מכשירים, צריך לוודא שתמונת המערכת זהה לקוד הבינארי של התוצאה הצפויה לאחר עדכון OTA. ההטמעה של OTA שמבוססת על בלוקים ב-Android Open Source Project, שנוספה מאז Android 5.1, עומדת בדרישות האלה.

בנוסף, הטמעות במכשירים אמורות לתמוך בעדכוני מערכת מסוג A/B. התכונה הזו מיושמת ב-AOSP באמצעות HAL לבקרת אתחול.

אם נמצאת שגיאה בהטמעת מכשיר אחרי שהמכשיר שוחרר, אבל במהלך משך החיים הסביר של המוצר, שנקבע בהתייעצות עם צוות התאימות של Android, והיא משפיעה על התאימות של אפליקציות של צד שלישי, אז:

  • [C-2-1] מי שמטמיע את המכשיר חייב לתקן את השגיאה באמצעות עדכון תוכנה זמין שאפשר להחיל בהתאם למנגנון שמתואר למעלה.

מערכת Android כוללת תכונות שמאפשרות לאפליקציית הבעלים של המכשיר (אם היא קיימת) לשלוט בהתקנה של עדכוני המערכת. אם מערכת המשנה של עדכוני המערכת למכשירים מדווחת על android.software.device_admin, המשמעות היא שהמכשירים:

  • [C-3-1] חובה להטמיע את ההתנהגות שמתוארת בכיתה SystemUpdatePolicy.

12. יומן השינויים של המסמך

סיכום של השינויים בהגדרת התאימות בגרסה הזו:

סיכום של השינויים בקטעים של אנשים פרטיים:

  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 ולבקש הבהרות או להעלות בעיות שלדעתכם לא מפורטות במסמך.