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

‫1. הקדמה

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

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

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

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

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

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

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

1.1 מבנה המסמך

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

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

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

1.1.2. מזהה דרישה

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

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

כל מזהה מוגדר כך:

  • מזהה סוג המכשיר (מידע נוסף זמין ב-2. סוגי מכשירים)
    • ג: ליבה (דרישות שחלות על כל ההטמעות של מכשירי Android)
    • H: מכשיר נייד עם Android
    • T: מכשיר Android TV
    • תשובה: הטמעת 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]* חייב להיות שהמסך הלוגי שזמין לאפליקציות צד שלישי יהיה באורך של 2 אינץ' לפחות בקצה הקצר ו-2.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 ב-upstream. כלומר אסור להטמיע במכשירים שונים את הטריגרים או את ערכי הסף שבהם יופעל מצב התאימות, ואסור להם לשנות את ההתנהגות של מצב התאימות עצמו.
  • [7.2.1/H-0-1] חייבת לכלול תמיכה באפליקציות של עורך שיטות קלט (IME) של צד שלישי.
  • [7.2.3/H-0-3] חייבים לספק את פונקציית Home בכל המסכים שתואמים ל-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] חובה לדווח על ערכים פסאודו-טווח (pseudoranges) של GNSS, כלומר, בתנאי שמיים פתוחים אחרי קביעת המיקום, בזמן תחנה או תנועה של פחות מ-0.2 מטר לשנייה בריבוע של תאוצה, מספיקים כדי לחשב את המיקום בטווח של 20 מטרים לפחות, והמהירות בטווח של 0.9 מטרים לפחות בטווח של 0.9 מטרים

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

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

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

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

אם הטמעות במכשירים ניידים מוצהרות על תמיכה בכל ממשק ABI של 64 ביט (עם או בלי ממשק ABI של 32 ביט):

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

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

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

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

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

אם הטמעות במכשירים ניידים כוללות נפח זיכרון של 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 או שווה ל-2GB ופחות מ-4GB מהזיכרון שזמין לליבה ולמרחב המשתמש, הם:

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

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

  • [7.6.1/H-1-1] חייבת לתמוך רק בממשקי ABI של 32 ביט.

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

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

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

  • [7.7.1/H-1-1] חייבים להטמיע את Android Open Accessory API (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] חובה להצהיר על דגל הפיצ'ר android.hardware.vr.high_performance.
  • [7.9.1/H-1-2] חייבת לכלול אפליקציה שמטמיעה את android.service.vr.VrListenerService, שאפשר להפעיל באפליקציות VR דרך android.app.Activity#setVrModeEnabled.

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

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

כשהמערכת מזהה את טרמינל האודיו 0x0302 של USB, הוא:

  • [7.8.2.2/H-2-1] חייב לשדר את ה-Intent ACTION_HEADSET_PLUG עם תוספת של 'מיקרופון' ל-0.

כשהמערכת מזהה את טרמינל האודיו 0x0402 של USB, הוא:

  • [7.8.2.2/H-3-1] חובה לשדר את ה-Intent ACTION_HEADSET_PLUG עם תוספת של 'מיקרופון' ל-1.

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

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

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

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

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

  • [7.8.2.2/H-4-5] חובה לרשום מכשיר מסוג AudioDeviceInfo.TYPE_USB_DEVICE והתפקיד isSource() אם שדה הסוג של טרמינל אודיו ב-USB הוא 0x604.

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

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

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

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

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

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

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

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

  • [7.10/H]* צריך להזיז את האקטואטור הפיזי בציר ה-X בפריסה לאורך.

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

  • [7.10/H]* צריכה להיות תדר התהודה של ציר ה-X LRA הוא פחות מ-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] חייבת להיות אפליקציה שמטפלת באובייקטים ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE ושל ACTION_CREATE_DOCUMENT כפי שמתואר במסמכי ה-SDK, ולספק למשתמש גישה לנתונים של ספק המסמך בתשלום באמצעות ה-API של {15.}DocumentsProvider
  • [3.2.3.1/H-0-2]* חייבים לטעון מראש אפליקציה או רכיב שירות אחד או יותר עם handler של 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] מומלץ מאוד להטמיע Assistant במכשיר כדי לטפל בפעולת Assist.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [8.4/H-0-1] חייב לספק פרופיל חשמל לכל רכיב שמגדיר את ערך הצריכה הנוכחית לכל רכיב חומרה ואת התרוקנות הסוללה המשוערת שנגרמה על ידי הרכיבים לאורך זמן, כפי שמתואר באתר של פרויקט הקוד הפתוח של Android.
  • [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 HMAC, בנוסף לפונקציות הגיבוב (hash) המשפחתיות MD5, SHA1 ו-SHA-2 כדי לתמוך בצורה תקינה באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד באופן מאובטח מהקוד שפועל בליבה (kernel) ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד ליבה או מרחב משתמשים יכול לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. פרויקט הקוד הפתוח של Android (AOSP) ב-upstream עומד בדרישה הזו באמצעות ההטמעה של Trusty, אבל אפשרויות אחרות מבוססות על פתרון מבוסס ARM TrustZone או הטמעה מאובטחת של צד שלישי עם בידוד מתאים שמבוסס על hypervisor.
  • [9.11/H-0-4] חייבים לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק כשהפעולה מבוצעת בהצלחה, לאפשר שימוש במפתחות שקשורים לאימות. חובה לאחסן את פרטי הכניסה של מסך הנעילה כך שרק סביבת הביצוע המבודדת תוכל לבצע אימות של מסך הנעילה. פרויקט הקוד הפתוח של Android ב-upstream מספק את Gatekeeper Hardware Abstraction Layer (HAL) ואת Trusty, ואפשר להשתמש בהם כדי לעמוד בדרישה הזו.
  • [9.11/H-0-5] חייבת לתמוך באימות (attestation) של מפתחות כאשר חתימת האימות מוגן באמצעות חומרה מאובטחת, והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה לאימות (attestation) בין מספר גדול מספיק של מכשירים, כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת הדרכים לעמוד בדרישה הזו היא לשתף את אותו מפתח אימות, אלא אם יוצרים לפחות 100,000 יחידות ממק"ט נתון. אם מפיקים יותר מ-100,000 יחידות של מק"ט, ייתכן להשתמש במפתח שונה לכל 100,000 יחידות.
  • [9/H-0-1] חובה להצהיר על התכונה android.hardware.security.model.תואם.

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

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

  • [9.11/H-1-1] חייבים לאפשר למשתמש לבחור את הזמן הקצר ביותר לשינה, שהוא זמן מעבר ממצב הנעילה למצב הנעילה, באורך 15 שניות או פחות.
  • [9.11/H-1-2] חובה לאפשר למשתמשים להסתיר התראות ולהשבית את כל אמצעי האימות, למעט האימות הראשי שמתואר ב9.11.1 Secure Lock Screen. ה-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] חובה לוודא שהשירות לזיהוי מילות הפעלה יכול להעביר לשרת המערכת רק נתוני אודיו או נתונים שנגזרים ממנו באמצעות מיקרופון של 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(), יחד עם כל הודעות השיוך (Attribution) שמשויכות אליהן.
  • [9.8.2/H-4-3] אסור להסתיר את האינדיקטור של המיקרופון לאפליקציות מערכת עם ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמש.
  • [9.8.2/H-4-4] חייבת להציג את הרשימה של האפליקציות האחרונות והאפליקציות הפעילות שמשתמשות במיקרופון כמו שהוחזר מ-PermissionManager.getIndicatorAppOpUsageData(), יחד עם כל הודעות השיוך (Attribution) שמשויכות אליהן.

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

  • [9.8.2/H-5-1] חייבים להציג את האינדיקטור של המצלמה כשאפליקציה ניגשת לנתוני מצלמה בשידור חי, אבל לא כשאפליקציות ניגשות אל המצלמה רק אפליקציות שמנהלות את התפקידים שצוינו בסעיף 9.1 עם מזהה CDD [C-4-X].
  • [9.8.2/H-5-2] חובה להציג את האפליקציות 'אחרונים' ואפליקציות הפעילות באמצעות המצלמה כפי שהוחזרו אחרי PermissionManager.getIndicatorAppOpUsageData(), יחד עם כל הודעות השיוך (Attribution) שמשויכות אליהן.
  • [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 למשתמש המעטפת, ש-cmdline עומד במסמכי התיעוד של Perfetto.
    • [6.1/H-0-3]* הקובץ הבינארי perfetto חייב לקבל כקלט הגדרת Protobuf שתואמת לסכימה שמוגדרת במסמכי התיעוד של Perfetto.
    • [6.1/H-0-4]* הקובץ הבינארי הקבוע חייב לכתוב כפלט דוח מעקב של Protobuf שתואם לסכימה שמוגדרת במסמכי התיעוד המפורטים.
    • [6.1/H-0-5]* חייבים לספק, דרך הקובץ הבינארי, לפחות את מקורות הנתונים שמתוארים במסמכי התיעוד של Perfetto.
    • [6.1/H-0-6]* הדימון (daemon) שעבר מעקב חייב להיות מופעל כברירת מחדל (מאפיין המערכת 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, אז:

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

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

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

  • המצלמה חייבת לעמוד בדרישות שמפורטות ב-Android 11 CDD סעיף 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] זמן האחזור של הפעלת המצלמה2 (ממצלמה פתוחה לפריים הראשון בתצוגה מקדימה) חייב להיות קטן מ-600 אלפיות השנייה, כפי שנמדד על ידי בדיקת הביצועים של מצלמת CTS בתנאי התאורה של ה-ITS (3,000K) בשתי המצלמות הראשיות.
  • [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, הן:

  • חייב לעמוד בדרישות החומרה שמפורטות ב-Android 11 CDD סעיף 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, אז:

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

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

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

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

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

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

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

    • 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 (משופר עם השהיה נמוכה 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 FPS.

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

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

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

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

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

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

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

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

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

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

  • [5.3.6/T-1-1] פרופיל פענוח באיכות HD 1080p בקצב של 60FPS

בהטמעות של מכשירי טלוויזיה עם מפענחי חומרה 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 בקצב של 60FPS, בפרופיל 0 (עומק צבעים של 8 ביט).
  • [5.3.7/T-2-1] מומלץ מאוד לתמיכה בפרופיל פענוח UHD בקצב של 60 פריימים לשנייה, עם פרופיל 2 (עומק צבעים של 10 ביט).

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

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

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

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

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

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

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

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

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

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

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

  • [3.12/T-0-1] חייב לתמוך במסגרת של קלט טלוויזיה.

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

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

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

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

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

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

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

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

  • [8.4/T-0-1] חייב לספק פרופיל חשמל לכל רכיב שמגדיר את ערך הצריכה הנוכחית לכל רכיב חומרה ואת התרוקנות הסוללה המשוערת שנגרמה על ידי הרכיבים לאורך זמן, כפי שמתואר באתר של פרויקט הקוד הפתוח של Android.
  • [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 HMAC ופונקציות הגיבוב (hash) המשפחתיות MD5, SHA1 ו-SHA-2 כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד באופן מאובטח מהקוד שפועל בליבה (kernel) ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד ליבה או מרחב משתמשים יכול לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. פרויקט הקוד הפתוח של Android (AOSP) ב-upstream עומד בדרישה הזו באמצעות ההטמעה של Trusty, אבל אפשרויות אחרות מבוססות על פתרון מבוסס ARM TrustZone או הטמעה מאובטחת של צד שלישי עם בידוד מתאים שמבוסס על hypervisor.
  • [9.11/T-0-3] חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק כשהפעולה מבוצעת בהצלחה, צריך לאפשר שימוש במפתחות שקשורים לאימות. חובה לאחסן את פרטי הכניסה של מסך הנעילה כך שרק סביבת הביצוע המבודדת תוכל לבצע אימות של מסך הנעילה. פרויקט הקוד הפתוח של Android ב-upstream מספק את Gatekeeper Hardware Abstraction Layer (HAL) ואת Trusty, ואפשר להשתמש בהם כדי לעמוד בדרישה הזו.
  • [9.11/T-0-4] חייבת להיות תמיכה באימות עם מפתחות כאשר חתימת האימות מוגן באמצעות חומרה מאובטחת, והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה לאימות (attestation) בין מספר גדול מספיק של מכשירים, כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת הדרכים לעמוד בדרישה הזו היא לשתף את אותו מפתח אימות, אלא אם יוצרים לפחות 100,000 יחידות ממק"ט נתון. אם מפיקים יותר מ-100,000 יחידות של מק"ט, ייתכן להשתמש במפתח שונה לכל 100,000 יחידות.
  • [9/T-0-1] חובה להצהיר על התכונה android.hardware.security.model.תואם.

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

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

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

2.4.1. חומרה

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

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

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

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

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

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

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

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

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

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

  • [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. תוכנה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הטמעה של Android Automotive מתייחס ליחידה הראשית (HU) של הרכב שפועלת בו מערכת 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] חייבים לספק את הפונקציה Home ו-MAY לאפשר פונקציות 'הקודם' ו'אחרונים'.

  • [7.2.3/A-0-2] חייבים לשלוח לאפליקציה בחזית גם את האירוע הרגיל וגם את האירוע לחיצה ארוכה של פונקציית Back (KEYCODE_BACK).

  • [7.3/A-0-1] חובה להטמיע את GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED ו-PARKING_BRAKE_ON.

  • [7.3/A-0-2] הערך של הדגל NIGHT_MODE חייב להיות עקבי עם מצב יום/לילה במרכז הבקרה והוא צריך להתבסס על הקלט מחיישן האור בסביבה. יכול להיות שחיישן תאורת הסביבה הבסיסי יהיה זהה לחיישן PhotoMeter.

  • [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 loader ולייצא את כל הסמלים.

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

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

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

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

  • [7.4.5/A] אמורה לכלול תמיכה בקישוריות נתונים המבוססת על רשת סלולרית.

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

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

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

  • צריכה לכלול מצלמה אחת או יותר לצפייה מבחוץ.

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

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

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

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

  • [7.6.1/A] צריך לפרמט את מחיצת הנתונים כדי להציע ביצועים משופרים ואורך חיים משופר באחסון Flash, למשל באמצעות מערכת הקבצים 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] הזיכרון שזמין לליבה ולמרחב המשתמשים חייב להיות לפחות 1344MB אם אחת בדחיסות הבאות נמצאת בשימוש:

    • 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] הזיכרון הזמין לליבה ולמרחב המשתמשים חייב להיות לפחות 1280MB אם משתמשים בצפיפות:

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

  • [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] מומלץ מאוד להטמיע Assistant במכשיר כדי לטפל בפעולת Assist.

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

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

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

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

אם בהטמעות של מכשירי רכב יש תמיכה בנכסי 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.
  • [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 HMAC ופונקציות הגיבוב (hash) המשפחתיות MD5, SHA1 ו-SHA-2 כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד באופן מאובטח מהקוד שפועל בליבה (kernel) ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד ליבה או מרחב משתמשים יכול לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. פרויקט הקוד הפתוח של Android (AOSP) ב-upstream עומד בדרישה הזו באמצעות ההטמעה של Trusty, אבל אפשרויות אחרות מבוססות על פתרון מבוסס ARM TrustZone או הטמעה מאובטחת של צד שלישי עם בידוד מתאים שמבוסס על hypervisor.
  • [9.11/A-0-3] חייבים לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק כשהפעולה מבוצעת בהצלחה, לאפשר שימוש במפתחות שקשורים לאימות. חובה לאחסן את פרטי הכניסה של מסך הנעילה כך שרק סביבת הביצוע המבודדת תוכל לבצע אימות של מסך הנעילה. פרויקט הקוד הפתוח של Android ב-upstream מספק את Gatekeeper Hardware Abstraction Layer (HAL) ואת Trusty, ואפשר להשתמש בהם כדי לעמוד בדרישה הזו.
  • [9.11/A-0-4] חייבת להיות תמיכה באימות עם מפתחות כאשר חתימת האימות מוגן באמצעות חומרה מאובטחת, והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה לאימות (attestation) בין מספר גדול מספיק של מכשירים, כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת הדרכים לעמוד בדרישה הזו היא לשתף את אותו מפתח אימות, אלא אם יוצרים לפחות 100,000 יחידות ממק"ט נתון. אם מפיקים יותר מ-100,000 יחידות של מק"ט, ייתכן להשתמש במפתח שונה לכל 100,000 יחידות.
  • [9/A-0-1] חובה להצהיר על התכונה android.hardware.security.model.תואם.

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

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

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

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

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

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

מכשיר Android Tablet הוא הטמעה של מכשיר 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] יכול להיות שה-API של Android Open Accessory (AOA) יוטמע.

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

3. תוכנה

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

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

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

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

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

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

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

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

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

  • [C-0-7] חייבת לתמוך במנגנון העדכון הדינמי של תצורה חתומה, כדי להסיר ממשקים שאינם 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 בנתיב האתחול.
  • [C-0-2] חובה להוסיף את הספרייה org.apache.http.legacy לנתיב הכיתה של האפליקציה רק כשהאפליקציה עומדת באחד מהתנאים הבאים:
    • מוגדר טירגוט לרמת API 28 ומטה.
    • במניפסט הוא מצהיר שנדרשת הספרייה על ידי הגדרת המאפיין android:name של <uses-library> ל-org.apache.http.legacy.

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

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

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

3.2.1. הרשאות

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

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

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

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

$(BRAND)/$(PRODUCT)/
$(DEVICE):$(VERSION.VERSION)/$(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) של המוצר. בפורמט הספציפי של השדה הזה אין דרישות, והוא לא יכול להיות ריק או מחרוזת ריקה (""). אסור שהשדה הזה ישתנה במהלך כל משך החיים של המוצר.
SOC_MANUFACTURER השם המסחרי של היצרן של המערכת הראשית על הצ'יפ (SOC) שבה נעשה שימוש במוצר. מכשירים עם אותו יצרן SOC צריכים להשתמש באותו ערך קבוע. צריך לבקש מיצרן ה-SOC את הקבוע הנכון להשתמש בו. הערך של השדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט, חייב להתאים לביטוי הרגולרי "^([0-9A-Za-z ]+) ", אסור להתחיל או להסתיים ברווח לבן, ואסור שהוא יהיה שווה ל-"לא ידוע". אסור שהשדה הזה ישתנה במהלך חיי המוצר.
SOC_MODEL שם הדגם של המערכת הראשית על שבב (SOC) שמשמש במוצר. מכשירים עם אותו מודל SOC צריכים להשתמש באותו ערך קבוע. צריך לבקש מיצרן ה-SOC לקבל את הקבוע הנכון לשימוש. הערך בשדה הזה חייב להיות אפשר לקידוד כ-ASCII של 7 ביט והוא צריך להיות תואם לביטוי הרגולרי ^([0-9A-Za-z ._/+-]+)$ , אסור להתחיל או להסתיים ברווח לבן, ואסור שהוא יהיה שווה ל-'unknown'. השדה הזה לא ישתנה במהלך חיי המוצר.
דגם ערך שנבחר על ידי הטמעת המכשיר, שמכיל את שם המכשיר כידוע למשתמש הקצה. זה אמור להיות אותו השם שתחתיו המכשיר משווק ונמכר למשתמשי הקצה. אין דרישות לגבי הפורמט הספציפי של השדה הזה, אבל אסור שהוא יהיה null או מחרוזת ריקה (""). אסור שהשדה הזה ישתנה במהלך משך החיים של המוצר.
מוצר ערך שנבחר על ידי מטמיע המכשיר שמכיל את שם הפיתוח או את שם הקוד של המוצר הספציפי (מק"ט) שחייב להיות ייחודי באותו מותג. התוכן חייב להיות קריא לאנשים, אבל הוא לא מיועד בהכרח לתצוגה של משתמשי הקצה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט והוא צריך להיות תואם לביטוי הרגולרי ^[a-zA-Z0-9_-]+$ . אסור ששם המוצר ישתנה במהלך כל משך החיים של המוצר.
ODM_SKU ערך אופציונלי שנבחר על ידי הטמעה של המכשיר, שמכיל מק"ט (Stock Keeping Unit) שמשמש למעקב אחרי הגדרות ספציפיות של המכשיר. למשל, כל ציוד היקפי שכלול במכשיר כשהוא נמכר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט והוא תואם לביטוי הרגולרי " [0-9A-Za-z.,_-])"
סידורי חייבת להיות 'UNKNOWN'.
תגים רשימת תגים מופרדים בפסיקים שנבחרו על ידי הטמעה של המכשיר, שמפרידה עוד יותר את ה-build. חובה שניתן לקודד את התגים כ-ASCII בגרסת 7 ביט והם זהים לביטוי הרגולרי " ^[a-zA-Z0-9._-]+" וחייבים להיות באחד מהערכים המתאימים לשלוש התצורות הטיפוסיות של חתימת בפלטפורמת Android: מפתחות הפצה, מפתחות פיתוח ומפתחות בדיקה.
שעות ערך שמייצג את חותמת הזמן של מועד ה-build.
סוג ערך שנבחר על ידי ההטמעה של המכשיר, שמציין את התצורה של סביבת זמן הריצה של ה-build. השדה הזה חייב להכיל אחד מהערכים שתואמים לשלוש ההגדרות הטיפוסיות של זמן ריצה ב-Android: משתמש, userdebug או eng.
משתמש השם או מזהה המשתמש של המשתמש (או המשתמש האוטומטי) שיצר את ה-build. אין דרישות לגבי הפורמט הספציפי של השדה הזה, אבל הוא לא חייב להיות null או מחרוזת ריקה ("").
security_PATCH ערך שמציין את רמת תיקון האבטחה של ה-build. היא חייבת לציין שה-build לא חשוף בשום צורה לבעיות שמתוארות ברשימת עדכוני האבטחה הציבוריים הייעודיים של Android. היא חייבת להיות בפורמט [YYYY-MM-DD], שתואם למחרוזת מוגדרת שמתועדת בעדכון האבטחה הציבורי של Android או ב התראת האבטחה של Android, למשל '2015-11-01'.
BASE_OS ערך שמייצג את הפרמטר FINGERprint של ה-build, שזהה בדרך אחרת ל-build הזה, מלבד התיקונים שסופקו ב-Bulletin של Android Public Security. חובה לדווח על הערך הנכון. אם לא קיים build כזה, צריך לדווח על מחרוזת ריקה ("").
BOOTLOADER ערך שנבחר על ידי הטמעת המכשיר, שמזהה את גרסת תוכנת האתחול הפנימית הספציפית שבה נעשה שימוש במכשיר, בפורמט קריא לאנשים. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט והוא תואם לביטוי הרגולרי ^[a-zA-Z0-9._-]+$ ".
getRadioVersion() חייב להיות (להיות או להחזיר) ערך שנבחר על ידי כלי ההטמעה של המכשיר, שמזהה את גרסת הרדיו או המודם הפנימית הספציפית שבה נעשה שימוש במכשיר, בפורמט קריא לאנשים. אם אין במכשיר רדיו או מודם פנימיים, הוא חייב להחזיר NULL. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בגרסת 7 ביט והוא תואם לביטוי הרגולרי ^[a-zA-Z0-9._-,]+$ ".
getENTER() חייב (להיות או להחזיר) מספר סידורי של חומרה, חייב להיות זמין וייחודי בכל המכשירים עם אותם MODEL ו-MANUFACTURER. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בגרסת 7 ביט והוא תואם לביטוי הרגולרי ^[a-zA-Z0-9._-,]+$ ".

3.2.3. תאימות של Intent

3.2.3.1. אובייקטים נפוצים של Intent באפליקציות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-SR-3] מומלץ מאוד לכבד את android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA ו-android.speech.tts.engine.GET_Sample_TEXT לאובייקטים של Intent שהמטרה שלהם היא לספק מילוי של הכוונות האלה, כפי שמתואר כאן ב-SDK.

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

  • צריך לכלול תמיכה בשומרי מסך ולספק למשתמשים אפשרות להגדרות, כך שהם יוכלו להגדיר את שומרי המסך בתגובה ל-Intent 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. תאימות ל-Native API

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

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

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

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

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

  • [C-0-1] חייבת להיות תאימות לממשק ABI אחד או יותר של Android NDK.
  • [C-0-2] חייבת לכלול תמיכה בקוד שרץ בסביבה המנוהלת כדי לקרוא לקוד נייטיב, באמצעות סמנטיקה סטנדרטית של Java Native Interface (JNI).
  • [C-0-3] חייב להיות תואם למקור (כלומר תואם לכותרת) ותואם לבינארי (ל-ABI) לכל ספרייה נדרשת ברשימה שלמטה.
  • [C-0-5] חובה לדווח באופן מדויק על ממשק Application Binary Interface (ABI) המקורי שנתמך במכשיר, באמצעות הפרמטרים 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] כל הספריות הבאות חייבות להיות זמינות לאפליקציות שכוללות קוד נייטיב:

    • libaaudio.so (תמיכה באודיו מקורי של AAudio)
    • libamidi.so (תמיכה ב-MIDI מקורית, אם הוצהרה בעלות על התכונה android.software.midi כפי שמתואר בסעיף 5.9)
    • libandroid.so (תמיכה בפעילות מובנית ב-Android)
    • libc (ספריית C)
    • libcamera2ndk.so
    • libdl (קישור דינמי)
    • libEGL.so (ניהול פלטפורמות של OpenGL נייטיב)
    • libGLESv1_CM.so (OpenGL ES 1.x)
    • libGLESv2.so (OpenGL ES 2.0)
    • libGLESv3.so (OpenGL ES 3.x)
    • libicui18n.so
    • libicuuc.so
    • libjnigraphics.so
    • liblog (רישום ביומן Android)
    • libmediandk.so (תמיכה בממשקי API של מדיה מותאמת)
    • libm (ספריית מתמטיקה)
    • 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] אסור להוסיף או להסיר את הפונקציות הציבוריות של ספריות ה-Native שרשומות למעלה.

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

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

  • [C-0-11] חובה לייצא את כל סמלי הפונקציה OpenGL ES 3.1 וחבילת תוספים של Android, כפי שמוגדרים ב-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 ב-upstream

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

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

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

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

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

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

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

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

    • הוראות ל-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] חובה להשתמש בגרסת ה-build של 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) גרסה/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

    • הערך של המחרוזת $(VERSION) חייב להיות זהה לערך של android.os.Build.VERSION.Version.
    • יכול להיות שהמחרוזת $(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. הטמעת ה-AOSP של WebView עומדת בדרישה הזו.

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

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

  • [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. יש כמה תחומים ספציפיים של תאימות:

  • [C-0-1] אסור למכשירים לשנות את ההתנהגות או את הסמנטיקה של Intent רגיל.
  • [C-0-2] אסור למכשירים לשנות את הסמנטיקה של מחזור החיים או של מחזור החיים בסוג מסוים של רכיב מערכת (למשל: Service, Activity, ContentProvider וכו').
  • [C-0-3] אסור לשנות במכשירים את הסמנטיקה של הרשאות רגילות.
  • אסור שהמכשירים ישנו את המגבלות שנאכפות על אפליקציות ברקע. באופן ספציפי יותר, באפליקציות שפועלות ברקע:
    • [C-0-4] הם חייבים להפסיק לבצע קריאות חוזרות (callback) שרשומות על ידי האפליקציה כדי לקבל פלטים מה-GnssMeasurement ומה-GnssNavigationMessage.
    • [C-0-5] חובה להגביל את תדירות העדכונים שמסופקים לאפליקציה באמצעות מחלקת ה-API LocationManager או השיטה WifiManager.startScan().
    • [C-0-6] אם האפליקציה מטרגטת רמת API 25 ומעלה, אסור שהיא תאפשר לרשום מקלטי שידורים עבור שידורים מרומזים של מנגנונים רגילים של Android במניפסט של האפליקציה, אלא אם Intent השידור דורש הרשאה "signature" או "signatureOrSystem" protectionLevel או שהם נמצאים ברשימת הפטור.
    • [C-0-7] אם האפליקציה מטרגטת את רמת ה-API ברמה 25 ואילך, האפליקציה חייבת להפסיק את שירותי הרקע של האפליקציה, בדיוק כאילו האפליקציה הייתה קריאה לשיטה 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, במקום להטמיע מחדש חלקים משמעותיים במערכת.

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

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

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

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

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

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

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

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

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

כלומר, הן:

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

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

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

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

  • [C-0-5] אסור להיות במרחב שמות בבעלות ארגון אחר או הפניה אליו. לדוגמה, למטמיעי מכשירים אסור להוסיף ממשקי API למרחב השמות com.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 Executable (DEX) ובמפרט ובסמנטיקה של בייטקוד של Davik.

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

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

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

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

פריסת מסך דחיסות מסך זיכרון מינימלי של האפליקציה
שעון Android 120 dpi (ldpi) 32MB
140 dpi (140dpi)
160 dpi (mdpi)
180 dpi (180dpi)
200 dpi (200dpi)
213 dpi (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
480 dpi (xxhdpi) 88MB
560 dpi (560dpi) 112MB
640 dpi (xxxhdpi) 154MB
קטן/רגיל 120 dpi (ldpi) 32MB
140 dpi (140dpi)
160 dpi (mdpi)
180 dpi (180dpi) 48MB
200 dpi (200dpi)
213 dpi (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
480 dpi (xxhdpi) 128MB
560 dpi (560dpi) 192MB
640 dpi (xxxhdpi) 256MB
גדולה 120 dpi (ldpi) 32MB
140 dpi (140dpi) 48MB
160 dpi (mdpi)
180 dpi (180dpi) 80MB
200 dpi (200dpi)
213 dpi (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
480 dpi (xxhdpi) 256MB
560 dpi (560dpi) 384MB
640 dpi (xxxhdpi) 512MB
xlarge 120 dpi (ldpi) 48MB
140 dpi (140dpi) 80MB
160 dpi (mdpi)
180 dpi (180dpi) 96MB
200 dpi (200dpi)
213 dpi (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
480 dpi (xxhdpi) 384MB
560 dpi (560dpi) 576MB
640 dpi (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] חובה לפעול בהתאם ל-method של ה-API NotificationChannel.setShowBadge(). במילים אחרות, צריך להציג עלות ויזואלית שמשויכת לסמל האפליקציה אם הערך מוגדר כ-true, ולא להציג סכמת תגים של סמלי האפליקציה אם כל ערוצי ההתראות של האפליקציה הגדירו את הערך כ-false.
  • הם עשויים לבטל את התגים של סמל האפליקציה בסכמת התגים הקניינית שלהם כשאפליקציות של צד שלישי מציינות שיש תמיכה בסכימת התגים הקניינית באמצעות ממשקי API קנייניים, אבל הן יצטרכו להשתמש במשאבים ובערכים שסופקו דרך ממשקי ה-API של תגי ההתראות שמתוארים ב-SDK, כמו Notification.Builder.setNumber() וה-API Notification.Builder.setBadgeIconType().

3.8.2. ווידג'טים

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

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

  • [C-1-1] חובה להצהיר על תמיכה בתכונה 'פלטפורמה' android.software.app_widgets.
  • [C-1-2] חובה לכלול תמיכה מובנית ב-AppWidgets ולחשוף את העלויות בממשק המשתמש להוספה, להגדרה, להצגה ולהסרה של AppWidgets ישירות במרכז האפליקציות.
  • [C-1-3] חייבת להיות אפשרות להציג ווידג'טים בגודל רשת בגודל 4x4 בגודל הרשת הרגיל. לפרטים נוספים, אפשר לעיין ב-App Widget DesignGuidelines במסמכי התיעוד של Android SDK.
  • ייתכן שתתמוך בווידג'טים של אפליקציות במסך הנעילה.

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

3.8.3. התראות

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

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

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

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

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

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

3.8.4. ממשקי API של Assist

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

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

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

3.8.5. התראות והודעות קוליות

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

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

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

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

3.8.6. עיצובים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.9. ניהול קלט

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

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

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

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

גרסת Android 5.0 של Remote Control Client הוצאה משימוש ומתאימה ל-Media Notification Template, שמאפשרת לאפליקציות מדיה להשתלב עם פקדי הפעלה שמוצגים במסך הנעילה.

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

למידע על הגדרות כוונה להתאים את שומרי המסך, ראו סעיף 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, San-serif-light, sans-serif-medium, San-serif-black, San-serif- להיעזר בריכוז, sans-serif-Con העזרהd-light בשפות הזמינות במכשיר.
    • כיסוי מלא של Unicode 7.0 לאותיות לטיניות, יווניות וקיריליות, כולל הטווחים הלטיניים המורחבים A, B, C ו-D וכל הגליפים בבלוק סמלי המטבע של Unicode 7.0.
  • [C-1-3] אסור להסיר או לשנות את NotoColorEmoji.tff בתמונת המערכת. (ניתן להוסיף גופן חדש לאמוג'י כדי לשנות את האמוג'י ב-NotoColorEmoji.tff)
  • צריכה לתמוך בגוון העור ובסמלי אמוג'י משפחתיים מגוונים, כפי שמצוין בדוח הטכני של Unicode מס' 51.

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

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_מצב לאחר הפעלת ההקצאה של בעלי המכשיר, כדי שאפליקציית ה-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 הרגילים של DevicePolicyManager ל-Android, הן:

  • [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 שמאפשרים לאפליקציה Device Policy Controller (DPC) להפוך לבעלים של פרופיל מנוהל חדש.

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

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

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

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

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

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

  • [C-1-7] חובה לשלוח את כוונת ACTION_ADMIN_POLICY_COMPLIANCE לפרופיל העבודה כשנוצר בעלים של פרופיל במהלך ההקצאה, ללא קשר לשיטת ההקצאה שבה נעשה שימוש, מלבד במקרים שבהם ההקצאה מופעלת על ידי ה-Intent 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] חובה להשתמש בתג סמל (בדומה לתג של עבודה ב-upstream ב-AOSP) כדי לייצג את האפליקציות והווידג'טים המנוהלים ורכיבי ממשק משתמש אחרים עם תגים, כמו 'אחרונים והתראות'.
  • [C-1-4] חובה להציג סמל התראה (בדומה לתג עבודה ב-upstream ב-AOSP) כדי לציין מתי המשתמש נמצא באפליקציית פרופיל מנוהל.
  • [C-1-6] כאשר קיים פרופיל מנוהל, חובה להציג עלות ויזואלית ב-Intent Chooser, כדי לאפשר למשתמש להעביר את הכוונה מהפרופיל המנוהל אל המשתמש הראשי או להיפך, אם הוא הופעל על ידי 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.
    • מדיניות הסיסמאות של בקר 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 של הפלטפורמה שמאפשרים להטמעות של שירותי נגישות לקבל קריאות חוזרות לגבי אירועי משתמש ומערכת וליצור מנגנוני משוב חלופיים, כמו המרת טקסט לדיבור (TTS), משוב פיזי וניווט באמצעות משטח (trackball/d-pad).

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

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

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

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

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

ב-Android יש ממשקי API שמאפשרים לאפליקציות להשתמש בשירותי המרת טקסט לדיבור (TTS) ומאפשרים לספקי שירותים לספק הטמעות של שירותי TTS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-1-5] חובה להקיש הקשה כפולה על KEYCODE_HEADSETHOOK או על KEYCODE_MEDIA_PLAY_PAUSE בתור KEYCODE_MEDIA_NEXT עבור MediaSession.Callback#onMediaButtonEvent.

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

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

  • [C-1-1] אפליקציות ללא התקנה חייבות לקבל רק הרשאות שבהן android:protectionLevel מוגדר ל-"instant".
  • [C-1-2] אסור שאפליקציות ללא התקנה יקיימו אינטראקציה עם אפליקציות מותקנות באמצעות Intent מרומז, אלא אם מתקיים אחד מהתנאים הבאים:
    • מסנן דפוס 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] חייבת לספק התראה קבועה למשתמש שאפשר לכווץ בזמן שאפליקציה ללא התקנה פועלת בחזית. ההתראה הזו למשתמש חייבת לכלול את העובדה שאפליקציות ללא התקנה לא דורשות התקנה, ומספקות למשתמש אפשרות להפנות את המשתמשים למסך המידע של האפליקציה ב'הגדרות'. באפליקציות ללא התקנה שמופעלות דרך Intents באינטרנט, כפי שמוגדר על ידי שימוש ב-Intent עם פעולה שהוגדרה ל-Intent.ACTION_VIEW, עם סכמה של "http" או "https", עלות נוספת למשתמש לא תאפשר למשתמש להפעיל את האפליקציה ללא התקנה ולהפעיל את הקישור המשויך לדפדפן האינטרנט שהוגדר, אם יש דפדפן זמין במכשיר.
    • [C-1-7] חובה לאפשר גישה לאפליקציות ללא התקנה מהפונקציה 'אחרונים' אם הפונקציה 'לאחרונה' זמינה במכשיר.

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

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

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

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

3.18. אנשי קשר

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

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

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

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

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

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

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

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

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

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

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

  • [C-0-8] חובה להטמיע תמיכה ב-Inremental File System (מערכת קבצים מצטברת), כפי שמצוין כאן.

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

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

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

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

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

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

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

שימו לב: 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] אופוס

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

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

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

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

בעת פענוח אודיו של USAC, MPEG-D (ISO/IEC 23003-4):

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

מפענחי פרופיל MPEG-4 AAC, HE AAC ו-HE AACv2:

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

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

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

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

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

5.1.3. פרטי רכיבי הקודק של האודיו

פורמט/קודק פרטים סוגי קבצים/פורמטים של קונטיינרים שנתמכים
MPEG-4 AAC פרופיל
(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 Profile (AAC+) תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם קצב דגימה רגיל של 16 עד 48kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2
פרופיל (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.35 עד 48kHz. MPEG-4 (.mp4, .m4a)
AMR-NB 4.75 עד 12.2 kbps נדגם ב- 8 kHz 3GPP (.3gp)
AMR-WB 9 קצבים מ- 6.60 kbit/s עד 23.85 kbit/s שנדגמו ב- 16 kHz, כפי שמוגדר ב- AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec 3GPP (.3gp)
FLAC גם המקודד וגם המפענח: במצבי מונו ובמצב סטריאו חייבים להיות תמיכה. חייבת להיות תמיכה בקצבי דגימה של עד 192 kHz. חייבת להיות תמיכה ברזולוציה של 16 ביט ו-24 ביט. הטיפול בנתוני אודיו בפורמט FLAC 24 ביט חייב להיות זמין עם הגדרת אודיו בנקודה צפה (floating-point).
  • 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)
וורביס
  • Ogg (.ogg)
  • MPEG-4 (.mp4, .m4a, פענוח בלבד)
  • Matroska (.mkv)
  • Webm (.webm)
PCM/גל קודק ה-PCM חייב לתמוך ב-PCM ליניארי של 16 ביט ובציפה (float) של 16 ביט. מחלץ WAVE צריך לתמוך ב-PCM לינארי של 16 ביט, 24 ביט, 32 ביט וב-float של 32 ביט (קצב העברת נתונים עד למגבלת החומרה). תדירות הדגימה חייבת להיות בין 8kHz עד 192kHz. WAVE (.wav)
Opus פענוח: תמיכה בתוכן מונו, סטריאו, 5.0 ו-5.1 עם קצבי דגימה של 8,000, 12000, 16,000, 24,000 ו-48,000 Hz.
קידוד: תמיכה בקצבי מונו ו-1200, 8000, 12000, 16,000 ו-Hz 48,000
  • 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, הן:

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 בסיס+מתקדם 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)

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

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

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

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

5.1.7. רכיבי קודק של וידאו

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

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

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

  • [C-1-2] מקודדים ומפענחים של וידאו חייבים לתמוך בפורמטים גמישים של צבעים גמישים ביחס גובה-רוחב של 8:8:8 YUV420 (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] אם מוגדר שלא להשתמש בפלט Surface, ברירת המחדל היא YUV420 בפורמט צבע 8:8:8 שעבר אופטימיזציה לקריאת מעבד (CPU).

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

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

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

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

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

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

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

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

ובפרט:

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

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

  • [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)
  • 720 x 1280 פיקסלים (אחר)
 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] חייבת לתמוך ברמה 45 בפרופיל הבסיס.
  • המקודד הנתמך צריך לתמוך בקצבי העברת נתונים שאפשר להגדיר באופן דינמי.

5.2.2. H.264

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

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

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

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

5.2.3. VP8

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

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

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

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

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 פיקסלים 720 x 1280 פיקסלים 1920 x 1080 פיקסלים 3840 x 2160 פיקסלים
קצב הפריימים של הסרטון 30 fps 30 fps 30 fps 30 fps
קצב העברת נתונים של וידאו 1.6 Mbps 4Mbps ‎5Mbps 20Mbps

אם בהטמעות במכשירים שונים יש תמיכה בפרופיל 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 פיקסלים 720 x 1280 פיקסלים 1920 x 1080 פיקסלים 3840 x 2160 פיקסלים
קצב הפריימים של הסרטון 30 fps 30 fps 30 fps 30 fps
קצב העברת נתונים של וידאו 1.6 Mbps 4Mbps ‎5Mbps 20Mbps

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

אם בהטמעות של המכשיר יש תמיכה בקודקים מסוג VP8, VP9, H.264 או H.265:

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

5.3.1. MPEG-2

אם בהטמעות במכשירים יש תמיכה במפענחי MPEG-2:

  • [C-1-1] חייבת לתמוך ברמה הגבוהה של הפרופיל הראשי.

5.3.2. H.263

אם בהטמעות במכשירים יש תמיכה במפענחי H.263:

  • [C-1-1] חובה לתמוך בפרופיל הבסיס ברמה 30 וברמה 45.

5.3.3. MPEG-4

בהטמעות במכשירים עם מפענחי MPEG-4:

  • [C-1-1] חייבת לתמוך ב-Simple Profile Level 3.

5.3.4. H.264

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

  • [C-1-1] חובה לתמוך בפרופיל הראשי ברמה 3.1 ובפרופיל Baseline. לא חובה לספק תמיכה ב-ASO (סידור פרוסות שרירותי), ב-FMO (סידור גמיש של Macroblock) וב-RS (פרוסות יתירות).
  • [C-1-2] חייבת להיות אפשרות לפענח סרטונים עם פרופילים באיכות SD (Standard Definition) המפורטים בטבלה הבאה ומקודדים באמצעות פרופיל Baseline Profile ו-Main Profile Level 3.1 (כולל 720p30).
  • אמורה להיות אפשרות לפענח סרטונים עם פרופילים ב-HD (איכות HD) כפי שמצוין בטבלה הבאה.

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

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

5.3.5. H.265 (‏HEVC)

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

  • [C-1-1] חייבת לתמוך ברמה הראשית של רמת הפרופיל הראשית 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 פיקסלים 720 x 1280 פיקסלים 1920 x 1080 פיקסלים 3840 x 2160 פיקסלים
קצב הפריימים של הסרטון 30 fps 30 fps 30 fps 30/60fps (60fpsטלוויזיה עם פענוח באמצעות חומרת H.265) 60 fps
קצב העברת נתונים של וידאו 600 Kbps 1.6 Mbps 4Mbps ‎5Mbps 20Mbps

אם במכשיר נטען שהוא תומך בפרופיל 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
רזולוציית וידאו 180 x 320 פיקסלים 640 x 360 פיקסלים 720 x 1280 פיקסלים 1920 x 1080 פיקסלים
קצב הפריימים של הסרטון 30 fps 30 fps 30 FPS (60fpsטלוויזיה) 30 (60 fpsטלוויזיה)
קצב העברת נתונים של וידאו 800 Kbps 2 Mbps 8Mbps 20Mbps

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
רזולוציית וידאו 180 x 320 פיקסלים 640 x 360 פיקסלים 720 x 1280 פיקסלים 1920 x 1080 פיקסלים 3840 x 2160 פיקסלים
קצב הפריימים של הסרטון 30 fps 30 fps 30 fps 30FPS (60fpsטלוויזיה עם פענוח חומרה מסוג VP9) 60 fps
קצב העברת נתונים של וידאו 600 Kbps 1.6 Mbps 4Mbps ‎5Mbps 20Mbps

אם בהטמעות של מכשירים נטען שהם תומכים ב-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 מה-bitstream ו/או מהקונטיינר.
  • [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 ביט
    • קצבי דגימה: 8,000, 11,025, 16,000, 44100, 48,000 Hz
    • ערוצים: מונו

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

    • פורמט: PCM לינארי, 16 ביט ו-24 ביט
    • קצבי דגימה: 8,000, 11,025, 16000, 22050, 24000, 32000, 44100, 48,000 Hz
    • ערוצים: מספר המיקרופונים במכשיר מספר הערוצים

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

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

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

    • פורמט: PCM לינארי, 16 ביט
    • קצב דגימה: 22,050, 48,000 Hz
    • ערוצים: סטריאו

  • [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] חייב לכלול מסנן מתאים למניעת חיפוי דם.

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

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

  • [C-1-1] חובה להקליט את מקור האודיו android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION באחד מקצב הדגימה, 44100 ו-48,000.
  • [C-1-2] חובה להשבית כברירת מחדל את עיבוד האודיו של הפחתת רעשי רקע כשמקליטים שידור אודיו ממקור האודיו של AudioSource.VOICE_RECOGNITION.
  • [C-1-3] חובה להשבית כברירת מחדל כל בקרת היגיון אוטומטית בזמן הקלטה של שידור אודיו ממקור האודיו AudioSource.VOICE_RECOGNITION.
  • צריכה להקליט את זרם האודיו של זיהוי הקול עם משרעת שטוחה בערך לעומת מאפייני התדר: באופן ספציפי, ±3dB, מ-100Hz עד 4,000Hz.
  • צריך להקליט את שידור האודיו לזיהוי הקול עם הגדרת רגישות הקלט, כמו שמקור עוצמת קול של 90 דציבלים (SPL) ב- 1,000 Hz יוביל לתדר RMS של 2,500 לדגימות של 16 ביט.
  • צריך להקליט את שידור האודיו לזיהוי הקול כך שרמות משרעת ה-PCM עוקבות באופן לינארי ב-SPL של קלט בטווח של לפחות 30 דציבלים בין -18dB ל- +12 re 90 dB 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.35 dB) לזיהוי מלא של מיקרופון, להקלטה מדויקת של כל נקודה/כפול)
  • [C-SR-1] מומלץ מאוד להציג רמות משרעת בטווח התדרים הנמוכים: במיוחד מ-±20dB מ-5 Hz עד 100 Hz בהשוואה לטווח התדרים האמצעי של כל מיקרופון שמשמש להקלטת מקור האודיו של זיהוי הקול.
  • [C-SR-2] מומלץ מאוד להציג רמות משרעת בטווח התדרים הגבוה: במיוחד מ-±30dB מ-4,000Hz עד 22KHz בהשוואה לטווח התדרים האמצעי של כל מיקרופון שמשמש להקלטת מקור האודיו של זיהוי הקול.

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

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

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

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

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

    • פורמטים של המקור: PCM לינארי, 16 ביט, 8 ביט, מספר ממשי (float)
    • ערוצים: מונו, סטריאו, הגדרות חוקיות מרובות ערוצים עם עד 8 ערוצים
    • קצבי דגימה (ב-Hz):
      • 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 בהגדרות הערוצים שצוינו למעלה
      • 96000 במונו ובסטריאו

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

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

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

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

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

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

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

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

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

  • [C-SR-1] מומלץ מאוד לחתוך את תוכן האודיו שמופעל ללא פערים, כשזה מצוין ב-AudioTrack gamless API ובמאגר המדיה של MediaPlayer.

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

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

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

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

אם בהטמעות במכשירים מוצהר על 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, לעמוד בדרישות האלה עכשיו. בהשקה עתידית של הפלטפורמה, נדרוש זמן אחזור של פלט במצב התחלתי (cold) של 200 אלפיות השנייה או פחות כחובה.
  • [C-SR-2] זמן אחזור של 80 אלפיות שנייה או פחות מהקשה לטון.
  • [C-SR-3] צמצום הרעידות בפלט הקר.
  • [C-SR-4] חותמת הזמן של הפלט שהוחזרה על ידי AudioTrack.getTimestamp ו-AAudioStream_getTimestamp היא מדויקת ל- +/- 1 אלפיות השנייה.

אם ההטמעות של המכשירים עומדות בדרישות שלמעלה, אחרי כל כיול ראשוני, במהלך השימוש ב-AAudio Native Audio API, בשביל זמן אחזור רציף של פלט וזמן אחזור של פלט קר במכשיר אחד לפחות שנתמך בפלט אודיו:

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

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

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

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

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

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

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

  • [C-SR-12] מומלץ מאוד עם זמן אחזור רציף (continuous delivery) ממוצע של 50 אלפיות השנייה או פחות מ-5 מדידות, עם סטייה אבסולוטית ממוצעת של פחות מ-10 מילי-שניות, לאורך נתיב נתמך אחד לפחות.

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

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

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

  • [C-1-1] חייב לתמוך ב-Codec או בקונטיינר הזה ב-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
פרטים נוספים זמינים בסעיף 5.1.8 על H264 AVC, MPEG2-4 SP
ו-MPEG-2.

קודק האודיו:

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

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

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

  • [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 audio audio דרך נתיב MMAP.
  • [C-SR-3] מומלץ מאוד לספק רמה עקבית של ביצועי המעבד (CPU) כשהאודיו פעיל והעומס על המעבד (CPU) משתנה. כדאי לבדוק זאת באמצעות האפליקציה SynthMark ל-Android. SynthMark משתמש בסינתיסייזר תוכנה שרץ על פריים סימולציה של אודיו שמודד את ביצועי המערכת. צריך להריץ את אפליקציית SynthMark באמצעות האפשרות 'בדיקה אוטומטית' ולהשיג את התוצאות הבאות:
    • voicemark.90 >= 32 קולות
    • durationmark.fixed.little <= 15 מילי-שניות
    • durationmark.dynamic.little <= 50 מילי-שניות

להסבר על נקודות ההשוואה, ראו מאמרי העזרה של SynthMark.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-2-1] חייבים להחזיר את הערך null ל-method AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) של ה-API, כדי לציין שאין תמיכה.
  • [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 , disstats, טביעת אצבע, Graphicsstats, netstats, Notification, Procstats) שתועדו באמצעות הפקודה dumpsys.
    • [C-0-10] חובה לתעד ללא השמטת נתונים, והאירועים הבאים צריכים להיות נגישים וזמינים לפקודת המעטפת cmd stats ולמחלקה StatsManager System API.
      • הפעילות בחזית שונתה
      • זוהתה חריגה
      • נשלח דיווח על נתיבי ניווט ב-AppB
      • AppCrashOccurred
      • AppStartOccurred
      • רמת הסוללה שונתה
      • הסוללהSaverModeStateChanged
      • BleScanresultReceived
      • BleScanStateChanged
      • ChargingStateChanged
      • DeviceIdleModeStateChanged
      • ForegroundServiceStateChanged
      • GpsScanStateChanged
      • JobStateChanged (שינוי מצב המשימה)
      • PluggedStateChanged
      • משימות מתוזמנות
      • ScreenState השתנה
      • SyncStateChanged
      • זמן אמת ב-SystemElapse
      • UidProcessStateChanged
      • מצב WakelockState השתנה
      • מעורר התעוררות
      • מצב Wi-FiLockState השתנה
      • WifiMulticastLockStateChange
      • מצב WifiScanState השתנה
    • [C-0-4] דימון (daemon) בצד המכשיר חייב להיות לא פעיל כברירת מחדל, וחייב להיות מנגנון נגיש למשתמש כדי להפעיל את גשר ניפוי הבאגים ב-Android.
    • [C-0-5] חייבת לתמוך ב-adb מאובטח. Android כולל תמיכה ב-adb מאובטח. פרוטוקול adb מאובטח מאפשר הפעלה של adb במארחים מאומתים מוכרים.
    • [C-0-6] חייב לספק מנגנון שמאפשר לחבר את adb ממכונה מארחת. פרטים נוספים:

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

    • [C-3-1] חובה להטמיע adb דרך רשת מקומית (כמו אתרנט או Wi-Fi).
    • [C-3-2] חובה לספק מנהלי התקנים ל-Windows 7, 8 ו-10, כדי לאפשר למפתחים להתחבר למכשיר באמצעות פרוטוקול adb.

    אם הטמעות של מכשירים תומכות בחיבורי adb למכונה מארחת באמצעות Wi-Fi:

    • [C-4-1] חייבת להיות שיטת AdbManager#isAdbWifiSupported() שמחזירה true.

    אם בהטמעות של מכשירים יש תמיכה בחיבורי adb למכונה מארחת באמצעות Wi-Fi, והיא כוללת לפחות מצלמה אחת:

    • [C-5-1] חייבת להיות שיטת AdbManager#isAdbWifiQrSupported() שמחזירה true.

  • Dalvik Debug Monitor Service (ddms)

    • [C-0-7] חייבת להיות תמיכה בכל תכונות ה-ddms כפי שמתואר ב-Android SDK. מכיוון ש-ddms משתמשים ב-adb, התמיכה ב-ddms אמורה להיות לא פעילה כברירת מחדל, אבל חייבת להיות תמיכה בכל פעם שהמשתמש הפעיל את גשר ניפוי הבאגים של Android, כמו שמתואר למעלה.

  • קוף

    • [C-0-8] חייבים לכלול את מסגרת Monkey framework ולאפשר לאפליקציות להשתמש בה.

  • SysTrace

    • [C-0-9] חייבת לתמוך בכלי ה-systrace כפי שתועד ב-Android SDK. Systrace חייבת להיות לא פעילה כברירת מחדל, וחייב להיות מנגנון נגיש למשתמש כדי להפעיל את Systrace.

  • Perfetto

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

  • עומק זיכרון נמוך

    • [C-0-10] חובה לכתוב עדכון Atom של LMK_KILL_OCCURRED_FIELD_NUMBER ביומן הנתונים הסטטיסטיים כשאפליקציה מסתיימת על ידי 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 ב-upstream מסתירה את תפריט האפשרויות למפתחים כברירת מחדל ומאפשרת למשתמשים להפעיל את האפשרויות למפתחים אחרי לחיצה שבע (7) פעמים בתפריט הגדרות > מידע על המכשיר > מספר Build.
  • [C-0-2] חובה להסתיר את 'אפשרויות למפתחים' כברירת מחדל.
  • [C-0-3] חייב לספק מנגנון ברור שלא מעניק יחס מועדף לאפליקציה אחת של צד שלישי, ולא לאפליקציה אחרת כדי להפעיל אפשרויות למפתחים. חייבים לספק מסמך או אתר גלויים לכולם שמתארים איך להפעיל את האפשרויות למפתחים. חובה לאפשר קישור של המסמך או האתר הזה ממסמכי Android SDK.
  • צריכה להיות התראה ויזואלית שוטפת למשתמש כשאפשרויות למפתחים מופעלות, וחשוב לשמור על בטיחות המשתמש.
  • ייתכן שנגביל באופן זמני את הגישה לתפריט האפשרויות למפתחים על ידי הסתרה או השבתה של התפריט, כדי למנוע הסחות דעת בתרחישים שבהם יש חשש לבטיחות המשתמש.

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

אם המכשיר כולל רכיב חומרה מסוים שיש לו API תואם למפתחים של צד שלישי:

  • [C-0-1] ההטמעה של המכשיר חייבת להטמיע את ה-API הזה, כפי שמתואר במאמרי העזרה של Android SDK.

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

  • [C-0-2] עדיין חובה להציג את הגדרות הכיתה (כפי שמתואר על ידי ה-SDK) של ממשקי ה-API של הרכיבים.
  • [C-0-3] בצורה סבירה, חייבים להטמיע את ההתנהגויות של ה-API כפעולות ללא תפעול.
  • [C-0-4] שיטות ה-API חייבות להחזיר ערכי null כאשר הדבר מותר במסמכי התיעוד של ה-SDK.
  • [C-0-5] שיטות API חייבות להחזיר הטמעות ללא תפעול של מחלקות שבהן ערכי ה-null אינם מורשים במסמכי התיעוד של ה-SDK.
  • [C-0-6] שיטות API לא יכולות להקפיץ חריגות שלא תועדו במסמכי התיעוד של ה-SDK.
  • [C-0-7] הטמעות של מכשירים חייבות לדווח באופן עקבי על פרטי הגדרת חומרה מדויקים באמצעות השיטות getSystemAvailableFeatures() ו-hasSystemFeature(String) במחלקה android.content.pm.PackageManager, בשביל אותה טביעת אצבע של גרסת build.

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

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

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

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

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

7.1.1. הגדרת המסך

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

ה-framework של ממשק המשתמש של Android תומך במגוון גדלים שונים של פריסת מסך לוגית, ומאפשר לאפליקציות להריץ שאילתות על גודל המסך של התצורה הנוכחית באמצעות Configuration.screenLayout באמצעות SCREENLAYOUT_SIZE_MASK ו-Configuration.smallestScreenWidthDp.

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

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

    • במכשירים שבהם ה-Configuration.uiMode מוגדר בתור כל ערך מלבד UI_מצב_TYPE_Watch, ומדווחים על גודל small בשביל Configuration.screenLayout, חייבים להיות לפחות 426 dp x 320 dp.
    • במכשירים שמדווחים על גודל normal בשביל Configuration.screenLayout, הרזולוציה שלהם צריכה להיות לפחות 480 dp x 320 dp.
    • במכשירים שמדווחים על גודל large בשביל Configuration.screenLayout, הרזולוציה שלהם צריכה להיות לפחות 640 dp x 480 dp.
    • במכשירים שמדווחים על גודל xlarge בשביל Configuration.screenLayout, הרזולוציה שלהם צריכה להיות לפחות 960 dp x 720 dp.

  • [C-0-2] חובה ליישם כראוי את התמיכה של האפליקציות בגדלים של מסכים באמצעות המאפיין <supports-screens> בקובץ AndroidManifest.xml, כמו שמתואר במסמכי התיעוד של Android SDK.

  • ב-MAY יש מסכים שתואמים ל-Android עם פינות מעוגלות.

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-0-3] בהטמעות במכשירים שבהם האפשרות Configuration.uiMode מוגדרת UI_MODE_TYPE_WATCH, יחס הגובה-רוחב חייב להיות מוגדר כ-1.0 (1:1).

7.1.1.3. דחיסות מסך

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

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

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

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

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

7.1.2. מדדי פרסום ברשת המדיה

אם הטמעות המכשירים כוללות מסכים או פלט וידאו שתואמים ל-Android למסכי התצוגה שתואמים ל-Android:

  • [C-1-1] חובה לדווח על הערכים הנכונים לכל מדדי התצוגה שתואמים ל-Android שהוגדרו ב-API android.util.DisplayMetrics.

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

  • [C-2-1] חובה לדווח על הערכים הנכונים של המסך התואם ל-Android, כפי שמוגדר ב-API android.util.DisplayMetrics של ברירת המחדל view.Display.

7.1.3. כיוון מסך

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

  • [C-0-1] חובה לדווח על כיווני מסך מסוימים שנתמכים (android.hardware.screen.portrait ו/או android.hardware.screen.landscape) וחשוב לקבל דיווח על לפחות כיוון נתמך אחד. לדוגמה, מכשיר עם מסך לרוחב בכיוון קבוע, כמו טלוויזיה או מחשב נייד, צריך לדווח רק על android.hardware.screen.landscape.
  • [C-0-2] חובה לדווח על הערך הנכון לכיוון הנוכחי של המכשיר, כשנשלחת שאילתה דרך android.content.res.Configuration.orientation, android.view.Display.getOrientation() או ממשקי API אחרים.

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

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

7.1.4. האצת גרפיקה דו-ממדית ותלת-ממדית

7.1.4.1 OpenGL ES

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

  • [C-0-1] חייבת לזהות בצורה נכונה את הגרסאות הנתמכות של OpenGL ES (1.1, 2.0, 3.0, 3.1, 3.2) באמצעות ממשקי ה-API המנוהלים (למשל באמצעות ה-method 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.

בדיקות dEQP של OpenGL ES מחולקות למחיצות למספר רשימות של בדיקות, ולכל אחת מהן משויך מספר תאריך וגרסה. הקבצים האלה נמצאים בעץ המקור של 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] חייבים לעבור את כל בדיקות OpenGL ES dEQP ברשימות הבדיקה בין גרסה 132383489 לגרסה שצוינה בדגל התכונה android.software.opengles.deqp.level, בכל גרסה נתמכת של OpenGL ES.
  • [C-SR-2] מומלץ מאוד לתמוך בתוספים EGL_KHR_partial_update ו-OES_EGL_image_external.
  • צריכים לדווח בצורה מדויקת באמצעות ה-method 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] חייבת לתמוך בחבילת התוספים ל-Android של OpenGL ES ל-Android בשלמותה.

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

בדיקות dEQP של Vulkan מחולקות למחיצות למספר רשימות של בדיקות, ולכל אחת מהן משויך תאריך/גרסה. הקבצים האלה נמצאים בעץ המקור של 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] חובה להטמיע באופן מלא את ממשקי Vulkan 1.0 API לכל ערך של 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] חובה לדווח על הגרסה המקסימלית של בדיקות dEQP של Vulkan שנתמכות באמצעות דגל התכונה android.software.vulkan.deqp.level.
  • [C-1-9] חייבת להיות תמיכה לפחות בגרסה 132317953 (החל מ-1 במרץ 2019), כפי שדווח בדגל התכונה android.software.vulkan.deqp.level.
  • [C-1-10] חובה לעבור את כל בדיקות ה-dEQP של Vulkan ברשימות הבדיקה בין גרסה 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 האצת גרפיקה דו-ממדית

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

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

  • [C-0-1] צריך להפעיל את שיפור המהירות באמצעות חומרה כברירת מחדל. בנוסף, אם המפתח מבקש להשבית את האצת החומרה, צריך להגדיר את android:hardwareAccelerated="false" או להשבית את שיפור המהירות באמצעות חומרה ישירות דרך ממשקי ה-API של Android View.
  • [C-0-2] התנהגות חייבת להיות תואמת למסמכי התיעוד של Android SDK בנושא שיפור המהירות באמצעות חומרה.

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

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

  • [C-0-3] חייבת לתמוך ב-TextureView API, והוא חייב להראות התנהגות עקבית עם ההטמעה של Android ב-upstream.
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-key).
  • אמורות לכלול הטמעות נוספות של מקלדת רכה.
  • עשויים לכלול מקלדת חומרה.

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

מערכת Android כוללת תמיכה בלחצני החיצים (d-pad), כדור עקיבה וגלגל מגע כמנגנונים לניווט ללא מגע.

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

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

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

7.2.3. מקשי ניווט

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

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

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

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

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

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

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

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

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

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

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

  • [C-4-1] חובה לאפשר גישה לפונקציית Assist באמצעות פעולה אחת (למשל: הקשה, לחיצה כפולה או תנועה) כאשר יש גישה למקשי ניווט אחרים.
  • [C-SR-2] מומלץ מאוד ללחוץ לחיצה ארוכה על הפונקציה Home כאינטראקציה שנקבעה.

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

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

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

  • [C-6-1] WindowInsets#getMandatorySystemGestureInsets() חייב לשמש רק לדיווח על האזור של זיהוי תנועה בבית.
  • [C-6-2] תנועות שמתחילות ברכיב 'החרגה' שסופקה על ידי האפליקציה שפועלת בחזית דרך View#setSystemGestureExclusionRects(), אבל מחוץ ל-WindowInsets#getMandatorySystemGestureInsets(), אסור ליירט את התנועות שמתחילות ברכיב ההחרגה של פונקציית הניווט, כל עוד ההחרגה מותרת במגבלת ההחרגה המקסימלית שצוינה במסמך של View#setSystemGestureExclusionRects().
  • [C-6-3] חובה לשלוח לאפליקציה בחזית אירוע MotionEvent.ACTION_CANCEL ברגע שנגיעות מתחילות ליירט בגלל תנועה במערכת, אם האפליקציה בחזית נשלחה בעבר אירוע MotionEvent.ACTION_DOWN.
  • [C-6-4] למשתמש צריכה להיות אפשרות לעבור לניווט מבוסס-לחצנים במסך (לדוגמה, בהגדרות).
  • אמורה לספק את פונקציית Home כהחלקה למעלה מהקצה התחתון של הכיוון הנוכחי של המסך.
  • התכונה 'אחרונים' אמורה לאפשר את הפונקציה של החלקה למעלה ואחיזה לפני השחרור, מאותו אזור כמו התנועה 'מסך הבית'.
  • תנועות שמתחילות בתוך 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_BARSping_documents, שמוגדר
  • [C-7-4] כשבאפליקציה בחזית יש את View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT או WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BYUNSUM, רכיבי הדגל של המערכת הטמיעים את סרגלי הניווט מסוג View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT או WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BYs.

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] אסור לדווח על דגל feature flag שמתחיל ב-android.hardware.touchscreen.
  • [C-3-2] חובה לדווח רק על android.hardware.faketouch.
  • [C-3-3] חובה ליצור דוח TOUCHSCREEN_NOTOUCH לשדה Configuration.touchscreen API.

7.2.5. קלט מגע מזויף

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

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

  • צריך להצהיר על תמיכה בדגל הפיצ'ר 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 ב-upstream עומדת בדרישה הזו.

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

  • [C-2-1] חובה להצהיר על דגל הפיצ'ר android.hardware.gamepad
לחצן שימוש במכשיר ממשק אנושי (HID)2 לחצן Android
א1 0x09 0x0001 KEYCODE_button_A (96)
ב1 0x09 0x0002 KEYCODE_button_B (97)
X1 0x09 0x0004 KEYCODE_button_X (99)
כן1 0x09 0x0005 KEYCODE_button_Y (100)
לחצני החיצים (D-pad)1
לחיצה על לחצני החיצים (D-pad)1		 0x01 0x00393 AXIS_HAT_Y4
D-pad left1
D-pad right1		 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)
לחיצה על הלחצן הימני1 0x09 0x000F KEYCODE_button_THUMBR (107)
לדף הקודם1 0x0c 0x0224 KEYCODE_BACK (4)

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

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

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

4 MotionEvent

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

MotionEvent אחד

7.2.7. שלט רחוק

ראו סעיף 2.3.1 לדרישות ספציפיות למכשיר.

7.3. חיישנים

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

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

  • [C-0-1] חובה לדווח בצורה מדויקת על נוכחות או היעדר של חיישנים בכל סיווג android.content.pm.PackageManager.
  • [C-0-2] חובה להחזיר רשימה מדויקת של חיישנים נתמכים באמצעות SensorManager.getSensorList() ושיטות דומות.
  • [C-0-3] חובה להתנהג באופן סביר בכל ממשקי ה-API של החיישנים האחרים (לדוגמה, על ידי החזרת true או false בהתאם לצורך כשהאפליקציות מנסות לרשום מאזינים, ולא קוראות למאזינים של חיישנים כשהחיישנים המתאימים לא נמצאים וכו').

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

  • [C-1-1] חובה לדווח על כל מדידות החיישנים באמצעות הערכים הרלוונטיים של מערכת היחידות הבינלאומיות (מדד) לכל סוג חיישן, כפי שמוגדר במסמכי התיעוד של Android SDK.
  • [C-1-2] חובה לדווח על נתוני חיישנים עם זמן אחזור מקסימלי של 100 אלפיות השנייה + זמן דגימה של 2 * למקרים של סטרימינג מחיישן עם זמן אחזור מבוקש מקסימלי של 0 אלפיות השנייה כשמעבד האפליקציות פעיל. העיכוב הזה לא כולל עיכובים בסינון.
  • [C-1-3] חובה לדווח על דגימת החיישן הראשונה תוך 400 אלפיות השנייה + 2 * זמן הדגימה של החיישן שמופעל. מקובל שהמדגם הזה יהיה בעל רמת הדיוק 0.
  • [C-1-4] בכל API שצוין בתיעוד של Android SDK שהוא חיישן רציף, הטמעות של מכשירים חייבות לספק באופן רציף דגימות נתונים תקופתיות, שאמורות להיות רעידות מתחת ל-3%, שבהן רעידות מוגדרות כסטיית התקן של ההפרש בין ערכי חותמת הזמן המדווחים בין אירועים רצופים.
  • [C-1-5] חובה לוודא שזרם האירועים של החיישן אסור למנוע מהמעבד של המכשיר להיכנס למצב השעיה או להתעורר ממצב השעיה.
  • [C-1-6] חובה לדווח על זמן האירוע בננו-שניות כפי שמוגדר במסמכי התיעוד של Android SDK, שמייצג את הזמן שבו האירוע התרחש והסתנכרן עם השעון SystemClock.elapsed RealNano() .
  • [C-SR-1] מומלץ מאוד שתהיה שגיאה בסנכרון של חותמת הזמן בפחות מ-100 אלפיות השנייה, ושהשגיאה בסנכרון של חותמת הזמן צריכה להיות פחות מאלפית שנייה.
  • כשמפעילים כמה חיישנים, צריכת החשמל לא צריכה להיות גבוהה יותר מהסכום של צריכת החשמל המדווחת בחיישן הספציפי.

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

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

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

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

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

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

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

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

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

  • [C-3-1] חייבים להגדיר את הרזולוציה של החיישן ל-1 ולדווח על הערך באמצעות method Sensor.getResolution() API.

אם ההטמעות במכשירים כוללות חיישן מסוג מסוים שתומך ב-SensorAdditionalInfo#TYPE_VEC3_CALIBRATION והחיישן חשוף למפתחים של צד שלישי:

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

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

  • [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] חייבת להיות מסוגלת למדוד מצניחה חופשית עד פי ארבעה מכוח הכבידה(4 ג') או יותר בכל ציר.
  • [C-1-5] חייבת להיות ברזולוציה של 12 ביט לפחות.
  • [C-1-6] חייבת להיות סטיית תקן של לא יותר מ-0.05 מטרים לשנייה, שבה צריך לחשב את סטיית התקן על בסיס כל ציר על סמך דגימות שנאספו לאורך תקופה של 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 כמו שמתואר במסמך ה-SDK של Android.
  • צריך לדווח על אירועים עד 200 Hz לפחות.
  • הרזולוציה צריכה להיות לפחות 16 סיביות.
  • צריך לכייל אותו בזמן השימוש אם המאפיינים משתנים במהלך מחזור החיים ומתגמלים, ושומרים את הפרמטרים של הפיצוי בין הפעלות מחדש של המכשיר.
  • הטמפרטורה אמורה לפצות על הטמפרטורה.

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

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

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

7.3.3. GPS

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

  • [C-SR-1] מומלץ מאוד לכלול מקלט GPS/GNSS.

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

  • [C-1-1] חייבת לתמוך בפלט של המיקום בקצב של 1 Hz לפחות כשמבקשים אותו דרך LocationManager#requestLocationUpdate.
  • [C-1-2] חייבת להיות אפשרות לקבוע את המיקום בתנאים של שמיים פתוחים (אותות חזקים, מרובה נתיבים זניחים, HDOP < 2) תוך 10 שניות (זמן מהיר לתיקון הראשון), כשיש חיבור לאינטרנט במהירות של 0.5Mbps או מהירות נתונים גבוהה יותר. בדרך כלל יש לעמוד בדרישה הזו על ידי שימוש בשיטה כלשהי של GPS/GNSS בסיוע או GPS חזויים כדי למזער את זמן הנעילה של ה-GPS/GNSS (נתוני העזרה כוללים את זמן ההפניה, מיקום ההפניה ותקופת הזמן הלוויינית/שעון).
    • [C-1-6] אחרי ביצוע חישוב מיקום כזה, הטמעות של מכשירים חייבות לקבוע את המיקום שלו, בשמיים פתוחים, תוך 5 שניות, כשבקשות המיקום מופעלות מחדש, עד שעה אחרי חישוב המיקום הראשוני, גם אם הבקשה הבאה נשלחת ללא חבילת גלישה ו/או אחרי מחזור חשמל.

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

    • [C-1-3] חייבת להיות אפשרות לקבוע את המיקום בטווח של 20 מטר, והמהירות היא בטווח של 0.5 מטר לשנייה, לפחות ב-95% מהזמן.
    • [C-1-4] חובה לעקוב בו-זמנית ולדווח עליהן באמצעות GnssStatus.Callback לפחות 8 לוויינים מקבוצת כוכבים אחת.
    • אמורה להיות אפשרות לעקוב בו-זמנית אחרי לפחות 24 לוויינים, ממספר קבוצות כוכבים (למשל, GPS ולפחות לוויין אחד, בייטו, גלילאו).

  • [C-SR-2] מומלץ מאוד להמשיך לספק פלט מיקום רגיל של GPS או GNSS דרך GNSS Location Provider API במהלך שיחת טלפון במקרה חירום.

  • [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% לשנייה לפחות.

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

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

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

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

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] חובה לזהות את היכולת באמצעות דגל התכונה android.hardware.sensor.hifi_sensors.

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

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

    • טווח המדידה חייב להיות בין 8G- ל-8G+, ומומלץ מאוד שטווח המדידה יהיה בין 16G- ל-16G.
    • רזולוציית המדידה חייבת להיות לפחות 2048 LSB/g.
    • תדירות המדידה המינימלית חייבת להיות 12.5Hz או נמוכה יותר.
    • תדירות המדידה המקסימלית חייבת להיות 400Hz ומעלה. היא צריכה לתמוך ב-SensorDirectChannel RATE_VERY_FAST.
    • הרעש במדידה חייב להיות נמוך מ-400 μg/לצאת.
    • החיישן הזה חייב להשתמש בצורתו ללא התעוררות, עם יכולת אגירת נתונים של 3,000 אירועי חיישן לפחות.
    • צריכת החשמל באצווה חייבת להיות נמוכה מ-3 מגה-ואט.
    • [C-SR-1] מומלץ מאוד שרוחב הפס למדידה 3dB יהיה לפחות 80% מתדר ה-Nyquist וספקטרום רעש לבן בתוך רוחב הפס הזה.
    • אמורה להיות האצה אקראית של הליכה אקראית של פחות מ-30 μg תמצאו נבדק בטמפרטורת החדר.
    • אמור להיות שינוי בהטיה לעומת טמפרטורה של ≤ +/- 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 שמאפשר:

    • טווח המדידה חייב להיות בין -1000 ל- +1000 dps.
    • רזולוציית המדידה חייבת להיות לפחות 16 LSB/dps.
    • תדירות המדידה המינימלית חייבת להיות 12.5Hz או נמוכה יותר.
    • תדירות המדידה המקסימלית חייבת להיות 400Hz ומעלה. היא צריכה לתמוך ב-SensorDirectChannel RATE_VERY_FAST.
    • הרעש במדידה חייב להיות נמוך מ-0.014°/s/לצאת.
    • [C-SR-2] מומלץ מאוד שרוחב הפס למדידה 3dB יהיה לפחות 80% מתדר ה-Nyquist וספקטרום רעש לבן בתוך רוחב הפס הזה.
    • צריכה להיות הליכה אקראית של קצב של פחות מ- 0.001 °/s שיר Hz שנבדק בטמפרטורת החדר.
    • אמור להיות שינוי בהטיה לעומת טמפרטורה של ≤ +/- 0.05 °C/ s / °C.
    • צריך להיות שינוי ברגישות לעומת הטמפרטורה של 0.02% / °C.
    • הקו המתאים ביותר צריך להיות לא ליניארי, כלומר 0.2% או פחות.
    • צפיפות הרעש אמורה להיות ≤ 0.007 °/s/COLUMNHz.
    • כשהמכשיר במצב נייח, שגיאת כיול אמורה להופיע בטווח טמפרטורה של 10 ~ 40°C בפחות מ-0.002 rad/s.
    • הרגישות ל-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 או נמוכה יותר.
    • תדירות המדידה המקסימלית חייבת להיות 50Hz או יותר.
    • הרעש במדידה חייב להיות נמוך מ-0.5 UT.

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

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

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

    • טווח המדידה חייב להיות בין 300 ל-1100 hPa.
    • רזולוציית המדידה חייבת להיות לפחות 80 LSB/hPa.
    • תדירות המדידה המינימלית חייבת להיות 1 Hz או נמוכה יותר.
    • תדירות המדידה המקסימלית חייבת להיות 10Hz או יותר.
    • הרעש במדידה חייב להיות נמוך מ-2 Pa/😂.
    • החיישן הזה חייב להטמיע צורה שאינה במצב שינה, עם יכולת אגירת נתונים של 300 אירועי חיישן לפחות.
    • צריכת החשמל באצווה חייבת להיות נמוכה מ-2 מגה-ואט.

  • [C-2-8] חייב להיות חיישן TYPE_GAME_ROTATION_VECTOR.

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

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

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

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

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

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

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

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

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

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

  • [C-2-15] חובה לשלוח דגימות לאפליקציות תוך 5 אלפיות שנייה מהמועד שבו הנתונים זמינים לאפליקציה בכל אחד מהחיישנים הפיזיים שלמעלה.

  • [C-2-16] אסור שצריכת החשמל תהיה גבוהה מ-0.5 מגה-ואט כשהמכשיר סטטי ו-2.0 מגה-ואט כשהמכשיר בתנועה כאשר שילוב כלשהו של החיישנים הבאים מופעל:

    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS

  • [C-2-17] אולי יש חיישן TYPE_PROXIMITY, אבל אם יש כזה, חייבת להיות יכולת מאגר נתונים זמני מינימלית של 100 אירועי חיישן.

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

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

  • [C-3-1] חובה להצהיר בצורה נכונה על תמיכה בסוגי ערוצים ישירים ושיעורי דיווח ישירים דרך ה-API של isDirectChannelTypeSupported ושל getHighestDirectReportRateLevel.
  • [C-3-2] חייבת לתמוך לפחות באחד משני סוגי הערוצים הישירים של חיישנים בכל החיישנים שמצהירים על תמיכה בערוץ ישיר של חיישנים.
  • צריכה לתמוך בדיווח על אירועים דרך ערוץ ישיר של חיישן לחיישן ראשי (גרסה שלא נמצאת במצב שינה) מהסוגים הבאים:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. חיישנים ביומטריים

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

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

  • צריכה לכלול חיישן ביומטרי

אפשר לסווג חיישנים ביומטריים בתור Class 3 (לשעבר Strong), Class 2 (לשעבר חלשה) או Class 1 (לשעבר נוחות) על סמך שיעורי הזיוף וההתחזות שלהם ואבטחת צינור עיבוד הנתונים הביומטרי. הסיווג הזה קובע את היכולות של החיישן הביומטרי להתממשק עם הפלטפורמה ועם אפליקציות צד שלישי. החיישנים מסווגים כברירת מחדל בתור Class 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] חובה לזהות ולכבד כל שם של פרמטר שמוגדר כקבוע בסיווג מאמתי נתונים וכל שילוב שלו. לעומת זאת, אסור לכבד או לזהות קבועים של מספרים שלמים שמועברים לשיטות canAuthenticate(int) ו-setAllowedAuthenticator(int) שונות מאלה שמתועדות כקבועים ציבוריים ב-Authenticator ובכל השילובים שלהן.
  • [C-4-3] חובה להטמיע את הפעולה ACTION_BIOMETRIC_ENROLL במכשירים עם מידע ביומטרי ברמה Class 3 או Class 2. הפעולה הזו חייבת להציג רק את נקודות הכניסה להרשמה לנתונים ביומטריים של רמה 3 או של רמה 2.

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

  • [C-5-1] כברירת מחדל, חובה לבצע שלב אישור נוסף (למשל, לחיצה על לחצן).
  • [C-SR-1] מומלץ מאוד לקבוע הגדרה שמאפשרת למשתמשים לבטל את העדפת הבקשה ותמיד לדרוש שלב אישור נלווה.
  • [C-SR-2] מומלץ מאוד שפעולת האישור תהיה מאובטחת כדי שמערכת ההפעלה או פגיעה בליבה (kernel) לא יוכלו לזייף אותה. לדוגמה, המשמעות היא שפעולת האישור שמבוססת על לחצן פיזי מנותבת דרך סיכת קלט/פלט (GPIO) לשימוש כללי בלבד (GPIO) של רכיב מאובטח (SE), שלא ניתן להזיז בכל אמצעי אחר מלבד לחיצה על לחצן פיזי.
  • [C-5-2] חובה להטמיע גם תהליך אימות מרומז (ללא שלב אישור) שתואם ל-setConfirmationrequired(בוליאני), שבו האפליקציות יכולות להשתמש בתהליכי הכניסה.

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

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

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

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

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

  • [C-1-1] שיעור קבלה שגוי חייב להיות נמוך מ-0.002%.
  • [C-1-2] חובה לחשוף שהמצב הזה עלול להיות פחות מאובטח מקוד אימות, מקו ביטול נעילה או סיסמה חזקים, ולפרט באופן ברור את הסיכונים להפעלתו, אם שיעורי האישור של הזיוף וההתחזות גבוהים מ-7%, כפי שנמדד על ידי פרוטוקולים לבדיקת ביומטריה של Android.
  • [C-1-9] חובה לאלץ את המשתמש לבקש את האימות הראשי המומלץ (למשל, קוד אימות, קו ביטול נעילה, סיסמה) לאחר עשרים ניסיונות כושלים ולא פחות מתשעים שניות לפני ניסיון חוזר (backoff) של אימות ביומטרי - במקרה שניסוי שווא הוא עם איכות צילום הולמת (BIOMETRIC_ACQUIRED_GOOD) שלא תואם לערך ביומטרי רשום.
  • [C-SR-4] מומלץ מאוד להקטין את המספר הכולל של המדידות השקריות לאימות ביומטרי שצוין בסעיף [C-1-9], אם שיעורי הקבלה של הזיוף וההתחזות גבוהים מ-7% כפי שנמדדו על ידי פרוטוקולי הבדיקה של ביומטריה של Android.
  • [C-1-3] חובה להגביל את מספר הניסיונות לאימות ביומטרי – במקרים שבהם ניסוי שקרי הוא בעל איכות צילום הולמת (BIOMETRIC_ACQUIRED_GOOD) שלא תואמת למידע ביומטרי רשום.
  • [C-SR-5] מומלץ מאוד להגביל ניסיונות להגבלת קצב של יצירת הבקשות למשך 30 שניות לפחות, לאחר חמש ניסיונות כושלים לאימות ביומטרי למספר המקסימלי של מקרי שווא לכל [C-1-9] – במקרה שניסוי שווא הוא תוצאה של איכות צילום הולמת (BIOMETRIC_ACQUIRED_GOOD) שלא תואמת לנתונים ביומטריים מושלמים.
  • [C-SR-6] מומלץ מאוד להפעיל את כל הלוגיקה של הגבלת קצב של יצירת בקשות ב-TEE.
  • [C-1-10] חובה להשבית את המידע הביומטרי אחרי ההפעלה של ההשהיה לפני ניסיון חוזר של האימות הראשי, כפי שמתואר בסעיף [C-0-2] של סעיף 9.11.
  • [C-1-4] חובה למנוע הוספה של מידע ביומטרי חדש בלי ליצור קודם שרשרת אמון, באמצעות דרישה מהמשתמש לאשר פרטי כניסה קיימים או להוסיף פרטי כניסה חדשים למכשיר (קוד אימות/תבנית/סיסמה) שמאובטחים על ידי TEE. ההטמעה של פרויקט קוד פתוח של Android מספקת את המנגנון בתוך המסגרת כדי לעשות זאת.
  • [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 (STRONG) לאחר אחת מהאפשרויות הבאות:

    • פרק זמן של 4 שעות ללא פעילות, או

    • 3 ניסיונות לאימות ביומטרי שנכשלו.

  • [C-SR-7] מומלץ מאוד להשתמש בלוגיקה ב-framework של פרויקט הקוד הפתוח של Android כדי לאכוף את המגבלות שצוינו ב-[C-1-7] וב-[C-1-8] במכשירים חדשים.

  • [C-SR-8] מומלץ מאוד ששיעור דחייה שקרי של פחות מ-10% יהיה נמוך מ-10%, כפי שנמדד במכשיר.

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

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

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

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

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

  • [C-2-9] החיישן הביומטרי חייב להיות זמין לאפליקציות של צד שלישי.

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

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

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

  • [C-SR-11] מומלץ מאוד כדי שהאזור שאפשר לגעת בו ב-UDFPS יפריע לניווט ב-3 לחצנים( חלק מהמשתמשים עשויים להזדקק מטעמי נגישות).

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

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

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

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

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

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

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

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

7.4.1. טלפוניה

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

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

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

  • [C-1-1] חובה להצהיר על דגל הפיצ'ר android.hardware.telephony ועל סימונים של תכונות משנה אחרות בהתאם לטכנולוגיה.
  • [C-1-2] חייבים להטמיע תמיכה מלאה ב-API בטכנולוגיה הזו.
  • צריכה לאפשר את כל סוגי השירותים הסלולריים הזמינים (2G, 3G, 4G, 5G וכו') במהלך שיחות חירום (ללא קשר לסוגי הרשתות שהוגדרו על ידי SetAllowedNetworkTypeBitmap()).

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

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

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

אם יישומי המכשיר לא מגדירים את מאפיין המערכת ro.telephony.iwlan\_operation\_mode כ'מדור קודם', הם:

אם בהטמעות של המכשיר יש תמיכה ברישום למערכת משנה יחידה של מולטימדיה (IMS) לתכונות של שירות טלפוניה טלפונית (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] חובה להטמיע ממשק משתמש חסום לניהול מספרים, שנפתח באמצעות Intent שמוחזרת באמצעות השיטה TelecomManager.createManageBlockedNumbersIntent().
  • [C-1-7] אסור לאפשר למשתמשים משניים לראות או לערוך את המספרים החסומים במכשיר, כי פלטפורמת Android מניחה שלמשתמש הראשי יש שליטה מלאה בשירותי הטלפוניה, אירוע אחד, במכשיר. כל ממשק המשתמש הקשור לחסימה חייב להיות מוסתר אצל משתמשים משניים, והרשימה החסומה עדיין חייבת להתבצע.
  • המכשיר אמור להעביר את המספרים החסומים לספק לאחר עדכון המכשיר ל-Android 7.0.
7.4.1.2. API של Telecom

אם הטמעות המכשירים ידווחו על 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] חובה לתמוך ב-Multicast DNS (mDNS) ואסור לסנן חבילות mDNS (224.0.0.251) בכל זמן פעולה, כולל:
    • גם כשהמסך לא במצב פעיל.
    • בהטמעות של מכשירי Android TV, גם במצב המתנה.
  • [C-1-5] אסור להתייחס לקריאה ל-method של ה-API WifiManager.enableNetwork() בתור אינדיקציה מספקת לשינוי של ה-Network הפעיל, שמשמש כברירת מחדל לתנועת גולשים באפליקציות, שמוחזרת באמצעות ConnectivityManager שיטות API כמו getActiveNetwork ו-registerDefaultNetworkCallback. במילים אחרות, יכול להיות שהם משביתים את הגישה לאינטרנט של ספק רשת אחר (למשל, חבילת גלישה) רק אם הם מאמתים שרשת ה-Wi-Fi מספקת גישה לאינטרנט.
  • [C-1-6] מומלץ מאוד לבצע הערכה מחדש של הגישה לאינטרנט דרך Network כשמתבצעת קריאה ל-method של ConnectivityManager.reportNetworkConnectivity(), וכשההערכה תקבע שה-Network הנוכחי לא מספק יותר גישה לאינטרנט, צריך לעבור לרשת זמינה אחרת (למשל, חבילת גלישה) שמספקת גישה לאינטרנט.
  • [C-1-7] חובה לבצע רנדומיזציה של כתובת ה-MAC של המקור ומספר הרצף של פריימים של בקשות הבדיקה, פעם אחת בתחילת כל סריקה, בזמן שה-STA מנותק.
  • [C-1-8] חובה להשתמש בכתובת MAC עקבית אחת (לא צריכה להיות רנדומיזציה של כתובת MAC באמצע הסריקה).
  • [C-1-9] חובה לחזור על מספר הרצף של בקשת הליך הבדיקה כרגיל (ברציפות) בין בקשות גשול בסריקה.
  • [C-1-10] מספר הרצף של בקשת Probe צריך להיות אקראי בין בקשת גשושית האחרונה בסריקה לבין בקשת הממצאים הראשונה בסריקה הבאה.
  • [C-SR-1] מומלץ מאוד לבצע רנדומיזציה של כתובת ה-MAC של המקור שמשמשת לכל תקשורת STA אל נקודת גישה (AP) בזמן שיוך ושיוך.
    • המכשיר חייב להשתמש בכתובת MAC אקראית שונה לכל SSID (FQDN for Passpoint) שהוא מתקשר איתו.
    • המכשיר חייב לספק למשתמש אפשרות לשלוט ברנדומיזציה לפי SSID (FQDN ל-Passpoint) באמצעות אפשרויות לא אקראיות ואקראיות. כמו כן, הוא חייב להגדיר את מצב ברירת המחדל כדי לקבוע הגדרות Wi-Fi חדשות שייקבעו באופן אקראי.
  • [C-SR-2] מומלץ מאוד להשתמש ב-BSSID אקראי לכל AP שהם יוצרים.
    • כתובת ה-MAC חייבת להיות אקראית ותישמר בהתאם ל-SSID שמשמש את AP.
    • ייתכן שה-DEVICE יכול לספק למשתמש אפשרות להשבית את התכונה הזו. אם קיימת אפשרות כזו, הרנדומיזציה חייבת להיות מופעלת כברירת מחדל.

אם הטמעות המכשיר כוללות תמיכה במצב חיסכון בסוללה ב-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 (WIFI_MODE_FULL_LOW_LATENCY) חייב להיות קטן יותר מזמן האחזור במהלך מצב 'נעילת ביצועים גבוהים ב-Wi-Fi' (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 ישיר (Wi-Fi מקצה לקצה).

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

  • [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 ישיר בו-זמנית.
  • [C-SR-1] מומלץ מאוד להגדיר באקראי את כתובת ה-MAC של המקור לכל חיבורי ה-Wi-Fi הישירים החדשים שנוצרו.

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

אם הטמעות המכשירים כוללות תמיכה ב-TDLS וב-TDLS מופעל באמצעות ה-API של Wi-FiManager:

  • [C-1-1] חובה להצהיר על תמיכה ב-TDLS עד WifiManager.isTdlsSupported.
  • יש להשתמש ב-TDLS רק כאשר זה אפשרי ומועיל.
  • אמורה להיות מערכת היוריסטיקה מסוימת ולא להשתמש ב-TDLS אם הביצועים שלה עשויים להיות פחות טובים מאשר מעבר דרך נקודת הגישה ל-Wi-Fi.
7.4.2.3. עם חיבור ל-Wi-Fi

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

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

אם הטמעות המכשיר כוללות תמיכה ב-Wi-Fi Aware ובמיקום Wi-Fi, כפי שמתואר בסעיף 7.4.2.5 וחושף את הפונקציות האלה לאפליקציות צד שלישי:

7.4.2.4. Passpoint ל-Wi-Fi

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

  • [C-1-1] חייבת לכלול תמיכה ב-Wi-Fi Passpoint.
  • [C-1-2] חובה להטמיע את ממשקי ה-API WifiManager שקשורים ל-Passpoint כפי שמתואר במסמכי התיעוד של ה-SDK.
  • [C-1-3] חייבת לתמוך בתקן IEEE 802.11u, שקשור ספציפית לגילוי ולבחירה של רשת, כמו שירות פרסום כללי (GAS) ופרוטוקול Access Network Query Protocol (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 כפי שמתואר במפרט הנקודה לשיתוף אינטרנט 2.0 R3.
  • [C-1-8] חובה לתמוך בשליטה על הקצאת ההרשאות של המשתמשים באמצעות בורר ה-Wi-Fi.
  • [C-1-9] חובה לשמור על הגדרות אישיות של Passpoint בכל הפעלה מחדש.
  • [C-SR-1] מומלץ מאוד לתמוך בתכונה שמאפשרת לאשר את התנאים וההגבלות.
  • [C-SR-2] אנחנו ממליצים מאוד לתמוך בפיצ'ר המידע על המקום.

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

  • [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. הסרה של Keepalive ב-Wi-Fi

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

  • צריכה לכלול תמיכה בהורדה של עומסי Keepalive ב-Wi-Fi.

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

  • [C-1-1] חייבת לתמוך ב-API של SocketKeepAlive.

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

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

  • צריכה לתמוך ברכיבי קודק אודיו מתקדמים ובקודקי אודיו של Bluetooth (למשל LDAC).

אם בהטמעות במכשירים יש תמיכה ב-HFP, ב-A2DP וב-AVRCP:

  • צריכה לתמוך בלפחות 5 מכשירים מחוברים בסך הכול.

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

  • [C-1-1] חייבת להיות תמיכה ב-Bluetooth 4.2 ובתוסף אורך נתונים LE של Bluetooth LE.

ב-Android יש תמיכה ב-Bluetooth וב-Bluetooth עם צריכת אנרגיה נמוכה.

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

  • [C-2-1] חובה להצהיר על תכונות הפלטפורמה הרלוונטיות (android.hardware.bluetooth ו-android.hardware.bluetooth_le בהתאמה) ולהטמיע את ממשקי ה-API של הפלטפורמה.
  • עליך להטמיע פרופילים רלוונטיים של Bluetooth כמו A2DP, AVRCP, OBEX, HFP וכו', בהתאם למכשיר.

אם הטמעות במכשירים כוללות תמיכה ב‐Bluetooth Low Energy (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 עם צריכת אנרגיה נמוכה:

  • [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 (כפי שמוגדר במפרט הטכני של NFC Forum NFCForum-TS-DigitalProtocol-1.0) באמצעות תקני NFC הבאים:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • סוגי התגים של פורום NFC 1, 2, 3, 4, 5 (הוגדרו על ידי פורום NFC)

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

  • [C-1-13] חובה לבצע סקר לכל הטכנולוגיות הנתמכות במצב גילוי NFC.

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

  • צריכה להיות יכולת לקרוא את הברקוד ואת כתובת ה-URL (אם מקודדים) של מוצרי ברקוד Thinfilm NFC.

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

מערכת 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 on MIFARE Classic) בתפקיד הקורא/הכתיבה:

  • [C-4-1] חובה להטמיע את ממשקי ה-API התואמים של Android כפי שתועד על ידי Android SDK.
  • [C-4-2] חובה לדווח על התכונה com.nxp.mifare מה-method android.content.pm.PackageManager.hasSystemFeature(). שימו לב שזו לא תכונה רגילה של Android, ולכן היא לא מופיעה כקבוע במחלקה android.content.pm.PackageManager.

7.4.5. פרוטוקולים וממשקי API של רשתות

7.4.5.1. קיבולת רשת מינימלית

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

  • [C-0-1] חייבת לכלול תמיכה בסוג אחד או יותר של רשתות נתונים. באופן ספציפי, הטמעות במכשירים חייבות לכלול תמיכה בתקן נתונים אחד לפחות עם מהירות של 200 Kbit לשנייה או יותר. דוגמאות לטכנולוגיות שעומדות בדרישה הזו: EDGE, HSPA, EV-DO, 802.11g, אתרנט ו-Bluetooth PAN.
  • היא אמורה לכלול גם תמיכה בתקן נפוץ אחד לפחות של נתונים אלחוטיים, כמו 802.11 (Wi-Fi), כאשר תקן הרשת הפיזית (כמו אתרנט) הוא חיבור הנתונים הראשי.
  • ייתכן שתטמיעו יותר מצורה אחת של קישוריות נתונים.
7.4.5.2. IPv6

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

  • [C-0-2] חייבת לכלול סטאק רשתות של IPv6 ולתמוך בתקשורת IPv6 באמצעות ממשקי ה-API המנוהלים, כמו java.net.Socket ו-java.net.URLConnection, וגם בממשקי ה-API המקוריים, כמו שקעי AF_INET6.
  • [C-0-3] חייבים להפעיל את IPv6 כברירת מחדל.
    • חייבים לוודא שתקשורת IPv6 אמינה כמו IPv4, לדוגמה:
      • [C-0-4] חייבים לשמור על קישוריות IPv6 במצב 'נמנום'.
      • [C-0-5] אסור שהגבלת קצב של יצירת הבקשות תגרום לאבדן של קישוריות IPv6 במכשיר בכל רשת תואמת IPv6 שמשתמשת משך חיים של RA באורך 180 שניות לפחות.
  • [C-0-6] חובה לספק אפליקציות של צד שלישי עם קישוריות IPv6 ישירה לרשת כשהם מחוברים לרשת IPv6, בלי שום צורה של כתובת או תרגום יציאות באופן מקומי במכשיר. גם ממשקי ה-API המנוהלים כמו Socket#getLocalAddress או Socket#getLocalPort) וגם ממשקי NDK כמו getsockname() או IPV6_PKTINFO, חייבים להחזיר את כתובת ה-IP והיציאה שמשמשים בפועל לשליחה ולקבלה של חבילות ברשת.

הרמה הנדרשת של תמיכה ב-IPv6 תלויה בסוג הרשת, כפי שמוצג בדרישות הבאות.

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

  • [C-1-1] חייבת לתמוך בפעולה כפולה בסטאק וב-IPv6 בלבד ב-Wi-Fi.

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

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

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

  • [C-3-1] חייבת לתמוך בפעולת IPv6 (IPv6 בלבד ואולי גם סטאק כפול) ברשת סלולרית.

אם הטמעות במכשירים תומכים ביותר מסוג רשת אחד (למשל, ב-Wi-Fi ובחבילת הגלישה), הן:

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

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

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

  • [C-1-1] חובה לספק אפליקציית פורטל שבוי לטיפול ב-Intent ACTION_CAPTIVE_PORTAL_SIGN_IN ולהציג את דף ההתחברות לפורטל שבוי, על ידי שליחת הכוונה הזו, בזמן קריאה ל-System API ConnectivityManager#startCaptivePortalApp(Network, Bundle).
  • [C-1-2] חובה לבצע זיהוי של פורטלים שבויים ולאפשר התחברות לתמיכה באמצעות אפליקציית הפורטל שבוי כשהמכשיר מחובר לכל סוג רשת, כולל רשת סלולרית/ניידת, Wi-Fi, אתרנט או Bluetooth.
  • [C-1-3] חייבת לתמוך בהתחברות לפורטלים שבויים באמצעות DNS ללא טקסט ללא הצפנה, כשהמכשיר מוגדר לשימוש במצב 'DNS מחמיר' פרטי.
  • [C-1-4] חובה להשתמש ב-DNS מוצפן בהתאם למסמכי התיעוד של ה-SDK של android.net.LinkProperties.getPrivateDnsServerName ושל android.net.LinkProperties.isPrivateDnsActive לכל תעבורת הנתונים ברשת שלא מתקשרת באופן מפורש לפורטל שבוי.
  • [C-1-5] חייבים לוודא שבזמן שהמשתמש מתחבר לפורטל שבוי, רשת ברירת המחדל שמשמשת את האפליקציות (כפי שמוחזרת על ידי ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback, ושהיא משמשת כברירת מחדל בממשקי API של רשת Java כמו Java.net.Socket וממשקי API מקוריים כמו Connect() ) היא כל רשת זמינה אחרת שמספקת גישה לאינטרנט, אם היא זמינה.

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

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

  • [C-0-1] הגדרת הסנכרון האוטומטי הראשי חייבת להיות מופעלת כברירת מחדל, כדי שהשיטה getMasterSyncAutomatically() תחזיר את הערך 'true'.

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

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

  • [C-SR-1] מומלץ מאוד לספק את מצב חוסך הנתונים (Data Saver).

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

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

7.4.8. רכיבים מאובטחים

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

7.5. מצלמות

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

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

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

חבילת ה-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 לתצוגה מקדימה של נתוני קריאה חוזרת (callback) של אפליקציה אם היא לא התקשרה אף פעם ל-android.hardware.Camera.Parameters.setPreviewFormat(int).
  • [C-0-2] חייב להיות בפורמט הקידוד NV21 כשאפליקציה רושמת מכונת android.hardware.Camera.PreviewCallback והמערכת קוראת ל-method onPreviewFrame(). פורמט התצוגה המקדימה הוא YCbCr_420_SP, הנתונים בבייט[] שמועברים אל 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] עדיין חובה להטמיע את ה-API המלא של המצלמה שכלול במסמכי התיעוד של Android SDK, גם אם המכשיר כולל מיקוד אוטומטי בחומרה או יכולות אחרות. למשל, מצלמות ללא מיקוד אוטומטי עדיין חייבות לקרוא למופעים רשומים של android.hardware.Camera.AutoFocusCallback (למרות שאין קשר למצלמה ללא מיקוד אוטומטי). שימו לב: זה כן חל על מצלמות קדמיות. לדוגמה, למרות שרוב המצלמות הקדמית לא תומכות במיקוד אוטומטי, הקריאות החוזרות של ה-API עדיין צריכות להיות "מזויפות", כפי שמתואר.
  • [C-0-6] חובה לזהות ולכבד כל שם של פרמטר שמוגדר כקבוע במחלקה android.hardware.Camera.Parameters ובמחלקה android.hardware.camera2.CaptureRequest. לעומת זאת, אסור שהטמעות במכשירים לא יצייתו לקבועים של מחרוזות שמועברים לשיטה android.hardware.Camera.setParameters() אחרת, ולא יתועדו כקבועים ב-android.hardware.Camera.Parameters. כלומר, אפליקציות של מכשירים חייבות לתמוך בכל הפרמטרים הרגילים של המצלמה, אם החומרה מאפשרת זאת, ואסור שהן תומכות בסוגי פרמטרים מותאמים אישית של מצלמה. לדוגמה, הטמעות של מכשירים שתומכות בצילום תמונות באמצעות שיטות צילום בטווח דינמי גבוה (HDR) חייבות לתמוך בפרמטר Camera.SCENE_MODE_HDR של המצלמה.
  • [C-0-7] חובה לדווח על רמת התמיכה המתאימה באמצעות המאפיין android.info.supportedHardwareLevel כמו שמתואר ב-Android SDK, ולדווח על הסימונים המתאימים של framework.
  • [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] חובה להציע נפח אחסון שישותף על ידי אפליקציות, מה שידוע גם כ'אחסון חיצוני משותף', 'אחסון משותף של אפליקציות' או בנתיב "/sdcard" של Linux.
  • [C-0-2] חייב להיות מוגדר עם אחסון משותף שמותקן כברירת מחדל, במילים אחרות "מחוץ לקופסה", בין אם האחסון מוטמע על רכיב אחסון פנימי או על אמצעי אחסון נשלף (למשל, חריץ לכרטיס Secure Digital).
  • [C-0-3] חובה לטעון את האחסון המשותף של האפליקציה ישירות בנתיב של Linux sdcard או לכלול קישור סימבולי של Linux מ-sdcard לנקודת הטעינה בפועל.
  • [C-0-4] חובה להפעיל היקף אחסון כברירת מחדל לכל האפליקציות שמטרגטות לרמת API 29 ומעלה, חוץ מאשר במצב הבא:
    • מתי האפליקציה ביקשה android:requestLegacyExternalStorage="true" במניפסט.
  • [C-0-5] חובה לצנזר את המטא-נתונים של המיקום, כמו תגי Exif של GPS, ששמורים בקובצי מדיה כשניגשים לקבצים האלה דרך MediaStore, חוץ מאשר כשאפליקציית השיחות מחזיקה בהרשאה ACCESS_MEDIA_LOCATION.

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

  • אחסון נשלף שנגיש למשתמש, כמו חריץ לכרטיס Secure Digital (SD).
  • חלק מהאחסון הפנימי (שלא ניתן להסרה) כפי שמוטמע בפרויקט קוד פתוח (AOSP) של Android.

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

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

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

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

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

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

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

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

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

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

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

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

7.7. USB

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

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

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

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

  • [C-1-1] היציאה חייבת להיות מחוברת למארח USB שיש לו יציאת USB סטנדרטית מסוג A או type-C.
  • [C-1-2] חובה לדווח על הערך הנכון של iSerialNumber במתאר של מכשיר USB סטנדרטי עד android.os.Build.SERIAL.
  • [C-1-3] חייבים לזהות מטענים עם הספק 1.5A ו-3.0A בהתאם לתקן של נגד Type-C. בנוסף, הם חייבים לזהות שינויים במודעה אם הם תומכים ב-USB מסוג C.
  • [C-SR-1] היציאה צריכה להשתמש בגורם צורה של USB מסוג מיקרו-B, מיקרו-AB או Type-C. מכשירי Android קיימים וחדשים מומלץ מאוד לעמוד בדרישות האלה, כדי שאפשר יהיה לשדרג אותם לגרסאות עתידיות של הפלטפורמה.
  • [C-SR-2] היציאה צריכה להיות ממוקמת בחלק התחתון של המכשיר (בהתאם לכיוון הטבעי) או להפעיל סיבוב מסך של התוכנה בכל האפליקציות (כולל מסך הבית), כדי שהתצוגה תופיע כראוי כשהמכשיר מכוון ליציאה בתחתית המסך. מכשירי Android קיימים וחדשים מומלץ מאוד לעמוד בדרישות האלה, כדי שאפשר יהיה לשדרג אותם לגרסאות עתידיות של הפלטפורמה.
  • [C-SR-3] צריך להטמיע תמיכה כדי לצייר זרם 1.5 A בזמן ציפצוף ותנועה ב-HS כפי שמצוין במפרט של טעינת סוללה בחיבור USB, גרסה 1.2. מכשירי Android קיימים וחדשים מומלץ מאוד לעמוד בדרישות האלה, כדי שאפשר יהיה לשדרג אותם לגרסאות עתידיות של הפלטפורמה.
  • [C-SR-4] מומלץ מאוד לא לתמוך בשיטות טעינה קנייניות שמשנות את מתח ה-Vbus מעבר לרמות ברירת המחדל, או לשנות את תפקידי ה-sink/מקור, כי הדבר עלול לגרום לבעיות ביכולת הפעולה ההדדית עם המטענים או עם המכשירים שתומכים בשיטות הסטנדרטיות של העברת חשמל ב-USB. התכונה הזו נקראת 'מומלץ מאוד', אבל בגרסאות עתידיות של Android ייתכן שנדרוש מכל המכשירים מסוג C יתמכו ביכולת פעולה הדדית מלאה עם מטענים סטנדרטיים מסוג C.
  • [C-SR-5] מומלץ מאוד לתמוך ב-Power Delivery להעברת נתונים והחלפת תפקידי כוח כאשר הם תומכים במצב מארח USB-C ו-USB.
  • אמורה להיות תמיכה באספקת חשמל לטעינה במתח גבוה ותמיכה במצבים חלופיים, כמו מסך חוץ.
  • צריך להטמיע את ה-API והמפרט של Android Open Accessory (AOA), כפי שמתואר במאמרי העזרה של Android SDK.

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

  • [C-2-1] חובה להצהיר על תמיכה בתכונת החומרה android.hardware.usb.accessory.
  • [C-2-2] סוג האחסון בנפח USB חייב לכלול את המחרוזת 'android' בסוף תיאור הממשק iInterface של אחסון בנפח גדול ב-USB.
  • לא צריך להטמיע אודיו AOAv2 שמתועד בתיעוד של Android Open Accessory Protocol 2.0. אודיו AOAv2 הוצא משימוש החל מגרסה 8.0 של Android (רמת API 26).

7.7.2. מצב אירוח USB

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

  • [C-1-1] חובה להטמיע את ממשק ה-API של מארח ה-USB ל-Android כפי שמתואר ב-Android SDK, וחובה להצהיר על תמיכה בתכונת החומרה android.hardware.usb.host.
  • [C-1-2] חובה להטמיע תמיכה כדי לחבר ציוד היקפי סטנדרטי בחיבור USB. כלומר, הוא חייב:
    • צריכה להיות יציאה במכשיר מסוג C או משלוח עם כבלים, כדי להתאים יציאה קניינית במכשיר ליציאת USB מסוג C רגילה (מכשיר USB Type-C).
    • הוא צריך להיות מסוג A במכשיר או משלוח עם כבלים, כדי להתאים יציאה קניינית במכשיר ליציאת USB רגילה מסוג A.
    • צריכה להיות בהם יציאת מיקרו-AB במכשיר, שאמורה להישלח עם כבל שמתאים ליציאה סטנדרטית מסוג A.
  • [C-1-3] אסור לשלוח עם מתאם שממיר את ההמרה מיציאות USB מסוג A או מיציאות מיקרו-AB לשקע מסוג C (שקע).
  • [C-SR-1] מומלץ מאוד להטמיע את סיווג האודיו USB, כפי שמתועד במסמכי התיעוד של Android SDK.
  • צריכה לתמוך בטעינת ציוד היקפי בחיבור USB מחובר במצב מארח; פרסום מקור עם זרם של לפחות 1.5A כמפורט בקטע 'פרמטרים של סיום' במפרט 1.2 של כבל USB-C ומחבר מסוג USB-C עבור מחברים מסוג USB-C, או באמצעות טעינה של יציאת USB-C(CDP) בטווח הנוכחי של פלט כלפי מטה, כפי שצוין במפרטים של מחבר USB-1.1 לטעון.
  • עליכם להטמיע ולתמוך בתקני USB Type-C.

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

  • [C-2-1] חייב לתמוך בסיווג USB HID.
  • [C-2-2] חייבת לתמוך בזיהוי ובמיפוי של שדות נתוני ממשק המשתמש הבאים שצוינו ב-USB HID Usage Tables ובבקשה לשימוש בפקודות קוליות לקבועים הבאים של 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 (פרוטוקול העברת מדיה) שמחוברים מרחוק, ולאפשר גישה לתוכן שלהם באמצעות ה-Intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT ו-ACTION_CREATE_DOCUMENT. .

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

  • [C-4-1] חובה להטמיע את הפונקציונליות של יציאת תפקיד כפול כפי שהוגדרה במפרט USB-C (סעיף 4.5.1.3.3).
  • [C-SR-2] מומלץ מאוד לתמיכה ב-DisplayPort, צריכה לתמוך בקצבי נתונים של USB Superspeed, ומומלץ מאוד לתמיכה באספקת חשמל באספקת נתונים והחלפת תפקידי כוח.
  • [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 של הקלטת האודיו לפחות כפעולות ללא תפעול, לפי סעיף 7.

7.8.2. יעד השמע

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

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

למטרות הסעיף הזה, 'יציאת פלט' היא ממשק פיזי כמו שקע אודיו 3.5 מ"מ, HDMI או יציאה במצב מארח USB עם סיווג אודיו ב-USB. תמיכה בפלט אודיו בפרוטוקולים מבוססי רדיו כמו Bluetooth, Wi-Fi או רשת סלולרית לא כוללת "יציאת פלט".

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

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

  • [C-SR-1] מומלץ מאוד לכלול לפחות אחת מיציאות האודיו כשקע אודיו עם 4 מוליכים 3.5 מ"מ.

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

  • [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.8 וולט כ-2.9 וולט.
  • [C-1-7] חייבים לזהות את קוד המפתח ולמפות אותו לטווח הבא של העכבה המקבילה בין המיקרופון למוליכי הקרקע בתקע האודיו:
    • 110-180 אוהם: KEYCODE_VOICE_ASSIST
  • [C-SR-2] מומלץ מאוד לתמוך במחבר של האודיו עם אישור OMTP של הניתוק.
  • [C-SR-3] מומלץ מאוד לתמוך בהקלטת אודיו מאוזניות סטריאו עם מיקרופון.

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

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

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

דרישות ספציפיות למכשיר מופיעות בסעיף 2.2.1.

7.8.3. קרוב לאולטרסאונד

אודיו Near-Ultrasound הוא תדר של 18.5kHz עד 20kHz.

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

  • חייבים לדווח בצורה נכונה על התמיכה ביכולת אודיו בקרבת מקום באמצעות AudioManager.getProperty API, באופן הבא:

אם הערך PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND הוא 'true', מקורות האודיו VOICE_RECOGNITION ו-UNPROCESSED חייבים לעמוד בדרישות הבאות:

  • [C-1-1] תגובת ההספק הממוצעת של המיקרופון בתדר 18.5 kHz עד 20 kHz חייבת להיות לא יותר מ-15dB מתחת לתגובה ב- 2 kHz.
  • [C-1-2] יחס האות הלא משוקלל לרעש של המיקרופון מעל 18.5 kHz עד 20 kHz לטון של 19kHz ב- -26dBFS חייב להיות לא פחות מ-50dB

אם הערך של PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND הוא 'true':

  • [C-2-1] התגובה הממוצעת של הרמקול בתדרים 18.5 kHz עד 20 kHz חייבת להיות לא נמוכה מ- 40 dB מתחת לתגובה ב- 2 kHz.

7.8.4. תקינות האות

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

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

בבדיקה נדרש מתאם אודיו בלופ, שמשתמשים בו ישירות בשקע 3.5 מ"מ או בשילוב עם מתאם USB-C עד 3.5 מ"מ. כל היציאות של פלט האודיו צריכות להיבדק.

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

מצב ביצועים שיתוף תדירות הדגימה יוצאת בצ'אנס צ'אן אאוט
LOW_LATENCY בלעדי לא מסומן 1 2
LOW_LATENCY בלעדי לא מסומן 2 1
LOW_LATENCY משותף לא מסומן 1 2
LOW_LATENCY משותף לא מסומן 2 1
ללא משותף 48000 1 2
ללא משותף 48000 2 1
ללא משותף 44100 1 2
ללא משותף 44100 2 1
ללא משותף 16000 1 2
ללא משותף 16000 2 1

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

מתמר THD חיישן SNR
רמקול מובנה ראשי, שנמדד באמצעות מיקרופון חיצוני להתייחסות < 3.0% >= 50 dB
מיקרופון מובנה ראשי, שנמדד באמצעות רמקול עזר חיצוני < 3.0% >= 50 dB
שקעים אנלוגיים מובנים בגודל 3.5 מ"מ, נבדקים באמצעות מתאם לולאה חוזרת פחות מ-1% >= 60 dB
מתאמי USB שסופקו עם הטלפון, נבדקו באמצעות מתאם לולאה חוזרת < 1.0% >= 60 dB

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, ולחשוף את התוספים הזמינים ברשימת התוספים.
  • [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 AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA ו-AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT, כפי שמתואר ב-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] מומלץ מאוד לתמוך בהקצאה של רכיבי AHardwareBuffer עם יותר משכבה אחת ודגלים ופורמטים שצוינו ב-C-1-10.
  • [C-1-11] חייבת לתמוך בפענוח H.264 בקידוד H.264 לפחות ב- 3840 x 2160 בקצב של 30fps, דחוסה עד לממוצע של 40Mbps (שווה ל-4 מופעים של 1920 x1080 ב- 30fps-10Mbps) או שני מופעים של 1920 x 10Mbps.
  • [C-1-12] חייבת לתמוך ב-HEVC וב-VP9. היא חייבת להיות מסוגלת לפענח לפחות 1920x1080 x 1920 ב- 30fps, דחוסה עד 10Mbps.
  • [C-1-13] חייבת לתמוך ב-API של HardwarePropertiesManager.getDeviceTemperatures ולהחזיר ערכים מדויקים של טמפרטורת העור.
  • [C-1-14] חייב להיות מסך מוטמע, והרזולוציה שלו חייבת להיות לפחות 1920 x 1080.
  • [C-SR-6] מומלץ מאוד שרזולוציית המסך תהיה לפחות 2560x1440.
  • [C-1-15] המסך חייב להתעדכן לפחות 60 Hz במצב VR.
  • [C-1-17] המסך חייב לתמוך במצב של התמדה נמוכה עם התמדה של לא יותר מ-5 אלפיות השנייה. משך הזמן שמוגדר לפיקסל הוא משך הזמן שבו פיקסל פולט אור.
  • [C-1-18] חייבת להיות תמיכה ב-Bluetooth 4.2 ובהרחבה של אורך נתוני 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% לפחות.
  • MAY מספק ליבה בלעדית לאפליקציה בחזית, ו-MAY תומך ב-API Process.getExclusiveCores כדי להחזיר את הנתונים של ליבות המעבד (CPU) שבלעדיות לאפליקציה העליונה בחזית.

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

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

7.10. מגע

דרישות ספציפיות למכשיר מופיעות בסעיף 2.2.1.

7.11. שיעור ביצועי מדיה

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

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

  • ביצועי כתיבה ברצף. המדידה מתבצעת על ידי כתיבת קובץ של 256MB באמצעות מאגר נתונים זמני של 10MB.
  • ביצועי כתיבה אקראיים. המדידה מתבצעת על ידי כתיבת קובץ של 256MB באמצעות מאגר נתונים זמני של 4KB.
  • ביצועי קריאה ברצף. המדידה מתבצעת על ידי קריאת קובץ של 256MB באמצעות מאגר נתונים זמני של 10MB.
  • ביצועי קריאה אקראיים. המדידה מתבצעת על ידי קריאת קובץ של 256MB באמצעות מאגר נתונים זמני של 4KB.

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

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

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

    לעומת זאת, חייבים לצאת ממצב S3 כשאפליקציות של צד שלישי צריכות את משאבי המערכת, כפי שמתואר ב-SDK הזה.

    לדוגמה, בזמן שאפליקציות של צד שלישי מבקשים להשאיר את המסך במצב פעיל עד FLAG_KEEP_SCREEN_ON או להשאיר את המעבד (CPU) פועל דרך PARTIAL_WAKE_LOCK, המכשיר לא יכול לעבור למצב S3 אלא אם, כפי שמתואר ב-C-1-1, המשתמש ביצע פעולה מפורשת כדי להעביר את המכשיר למצב לא פעיל. לעומת זאת, בזמן שמופעלת משימה שאפליקציות של צד שלישי מטמיעות דרך JobScheduler או העברת הודעות בענן ב-Firebase לאפליקציות צד שלישי, המכשיר חייב לצאת ממצב S3, אלא אם המשתמש שינה את המכשיר במצב לא פעיל. אלו לא דוגמאות מקיפות, ו-AOSP מיישם אותות נרחבים של יציאה ממצב שינה כדי לגרום להתעוררות מהמצב הזה.

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

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

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

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

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

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

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

  • [C-0-1] חובה לדווח על התמיכה במצב Sustained Performance (ביצועים קבועים) באופן מדויק באמצעות ה-method PowerManager.isSustainedPerformanceModeSupported() של ה-API.

  • אמורה לתמוך במצב ביצועים קבועים.

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

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

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

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

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

  • [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-force על גורם הידע במסך הנעילה.

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

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

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

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

  • [C-0-8] חובה לקבל הסכמה מהמשתמשים כדי לאפשר לאפליקציה לגשת לנתוני המיקום או לנתוני הפעילות הגופנית.
  • [C-0-9] חייבת לתת הרשאה בתחילת ההפעלה רק לאפליקציה שיש לה את ההרשאות הנדרשות, כמו שמתואר ב-SDK. לדוגמה, בשביל טלפוניהManager#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 של setAuthorPolicy ו-setAuthorGrantState.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-0-1] חייבת לשמור על תאימות לאפליקציות קיימות, גם אם SELinux או תכונות אבטחה אחרות מוטמעות מתחת ל-framework של Android.
  • [C-0-2] ממשק משתמש לא גלוי כשתזוהה הפרת אבטחה ונחסם בהצלחה על ידי תכונת האבטחה שמוטמעת מתחת ל-framework של Android, אבל יכול להיות שממשק המשתמש יהיה גלוי כשמתרחשת הפרת אבטחה שהחסימה שלה בוטלה שמובילה לניצול מוצלח.
  • [C-0-3] אסור להפעיל את SELinux או כל תכונת אבטחה אחרת שמוטמעת מתחת למסגרת של Android, שאפשר להגדיר למשתמש או למפתח האפליקציה.
  • [C-0-4] אסור לאפשר לאפליקציה שעשויה להשפיע על אפליקציה אחרת באמצעות API (כמו Device Administration API) להגדיר מדיניות שמפרה את התאימות.
  • [C-0-5] חייבים לפצל את מסגרת המדיה למספר תהליכים, כדי שאפשר יהיה להעניק גישה בצורה מצומצמת יותר לכל תהליך כפי שמתואר באתר של פרויקט הקוד הפתוח של Android.
  • [C-0-6] חובה להטמיע מנגנון ארגז חול (Sandbox) של אפליקציית ליבה, שמאפשר לסנן קריאות מערכת באמצעות מדיניות שניתנת להגדרה מתוכנות עם שרשורים מרובים. פרויקט הקוד הפתוח של Android ב-upstream עומד בדרישה הזו באמצעות הפעלת seccomp-BPF עם סנכרון קבוצת שרשורים (TSYNC), כפי שמתואר בקטע Kernel Configuration של source.android.com.

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

  • [C-0-7] חובה להטמיע מנגנוני הגנה על גלישת מאגר נתונים זמני של ליבה (kernel). דוגמאות למנגנונים כאלה: CC_STACKPROTECTOR_REGULAR ו-CONFIG_CC_STACKPROTECTOR_STRONG.
  • [C-0-8] חובה להטמיע אמצעי הגנה מחמירים על זיכרון ליבה (kernel) כשקוד ההפעלה הוא לקריאה בלבד, נתונים לקריאה בלבד לא ניתנים להרצה ולא לכתיבה, ואי אפשר להפעיל אותם (למשל, CONFIG_DEBUG_RODATA או CONFIG_STRICT_KERNEL_RWX).
  • [C-0-9] חובה להטמיע גבולות גודל של אובייקטים סטטיים ודינמיים בבדיקת עותקים בין מרחב המשתמש ומרחב ליבה (למשל, CONFIG_HARDENED_USERCOPY) במכשירים שנשלחו במקור עם רמת API 28 ומעלה.
  • [C-0-10] אסור להפעיל זיכרון-מרחב משתמש כשמפעילים מצב ליבה (kernel) (למשל, PXN של חומרה או אמולציה דרך CONFIG_CPU_SW_DOMAIN_PAN או CONFIG_ARM64_SW_TTBR0_PAN) במכשירים שנשלחו במקור עם API ברמה 28 ומעלה.
  • [C-0-11] אסור לקרוא או לכתוב זיכרון-מרחב משתמש בליבה (kernel) מחוץ לממשקי API רגילים לגישה לעותק משתמש (למשל, מספר חשבון קבוע (PAN) בחומרה, או אמולציה דרך CONFIG_CPU_SW_DOMAIN_PAN או CONFIG_ARM64_SW_TTBR0_PAN, במכשירים שנשלחו במקור עם רמת API 28 ומעלה.
  • [C-0-12] חובה להטמיע בידוד של טבלת דפי ליבה (kernel) אם החומרה חשופה ל-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 עם אנטרופיה של תוכנת האתחול דרך /chosen/kaslr-seed Device Tree node או EFI_RNG_PROTOCOL).

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

  • [C-SR-4] מומלץ מאוד לא להשבית את Control-Flow Integrity (CFI), Shadow Call Stack (SCS) או Integer אופטימיזציית גלישה (IntSan) ברכיבים שבהם היא מופעלת.

  • [C-SR-5] מומלץ מאוד להפעיל את CFI, SCS ו-IntSan ברכיבים נוספים של מרחב משתמשים רגיש מבחינת אבטחה, כפי שמוסבר ב-CFI וב-IntSan.

  • [C-SR-6] מומלץ מאוד לאפשר אתחול סטאק בליבה (kernel) כדי למנוע שימוש במשתנים מקומיים לא מאותחלים (CONFIG_INIT_STACK_ALL או CONFIG_INIT_STACK_ALL_ZERO). בנוסף, בהטמעות של מכשירים אסור להניח שהערך שמשמש את המהדר לאתחל את התושבים המקומיים.

  • [C-SR-7] מומלץ מאוד לאפשר אתחול ערימה בליבה (heap), למניעת שימושים בהקצאות ערימה (heap allocation) לא מאותחלות (CONFIG_INIT_ON_ALLOC_DEFAULT_ON), ולא כדאי להניח שהערך שמשמש את הליבה לאתחול ההקצאות האלה.

אם הטמעות של מכשירים משתמשות בליבה (kernel) של Linux שמסוגלת לתמוך ב-SELinux, הן:

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

אם הטמעות של מכשירים משתמשות בליבה (kernel) אחרת מלבד Linux או Linux בלי SELinux:

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

אם הטמעות של מכשירים עושות שימוש במכשירי קלט/פלט (I/O) שתומכים ב-DMA:

  • [C-SR-8] מומלץ מאוד לבודד כל מכשיר קלט/פלט (I/O) שיכול DMA, באמצעות IOMMU (למשל SMMU של ARM).

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

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

  • [C-SR-9] מומלץ מאוד לבדוק אותם באמצעות כלים לזיהוי שגיאות זיכרון במרחב המשתמש, כמו MTE למכשירי ARMv9, HWASan למכשירי ARMv8+ או ASan לגבי סוגי מכשירים אחרים.
  • [C-SR-10] מומלץ מאוד לבדוק אותם באמצעות כלים לזיהוי שגיאות זיכרון בליבה (kernel) כמו KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS למכשירי ARMv9, CONFIG_KASAN_SW_TAGS למכשירי ARMv8 או CONFIG_KASAN_GENER לסוגים אחרים של מכשירים).
  • [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 צריכה לאכוף זאת.

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. אם נרשמים עוד אירועי מערכת, יכול להיות שהם ישתמשו במזהה Atom שונה בטווח שבין 100,000 ל-200,000.

9.8.2. מתבצעת הקלטה

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

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

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

  • [C-SR-4] מומלץ מאוד להציג אינדיקטור של המצלמה כשאפליקציה ניגשת לנתוני מצלמה בשידור חי, אבל לא כשהאפליקציה ניגשת למצלמה רק לאפליקציות שמופיעות בסעיף 9.1 בהרשאות עם מזהה CDD [C-3-X].
  • [C-SR-5] מומלץ מאוד להציג אפליקציות פעילות ואפליקציות אחרונות באמצעות המצלמה כפי שהוחזרו מ-PermissionManager.getIndicatorAppOpUsageData(), יחד עם הודעות שיוך (Attribution) שמשויכות אליהן.
  • [C-SR-6] מומלץ מאוד לא להסתיר את האינדיקטור של המצלמה באפליקציות מערכת עם ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמש.

9.8.3. קישוריות

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

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

9.8.4. תנועה ברשת

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

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

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

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

אם להטמעות של מכשירים יש מנגנון שמופעל מחוץ לאריזה כברירת מחדל, שמנתב את תעבורת הנתונים ברשת דרך שרת proxy או שער VPN (למשל, טעינה מראש של שירות VPN עם הענקת android.permission.CONTROL_VPN), הן:

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

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

  • [C-3-1] חובה להשבית בקובץ AndroidManifest.xml את העלויות של המשתמש הזה לאפליקציות שלא תומכות בשירות VPN שפועל כל הזמן, באמצעות הגדרת המאפיין SERVICE_META_DATA_SUPPORTS_ALWAYS_ON ל-false.

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

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

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

9.8.6. תיעוד תוכן וחיפוש אפליקציות

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

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

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

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

המיקום כולל מידע מסיווג המיקום ב-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] חובה לוודא שהאפליקציה שמשתמשת בממשק ה-API של עקיפת מיקום במצב חירום [LocationRequest.setLocationSettingsSettingsignored()] היא פעילות חירום ביוזמת המשתמש (למשל: מחייגים ל-911 או שולחים הודעת טקסט ל-911). עם זאת, בכלי רכב עשויים להתחיל סשן חירום ללא אינטראקציה פעילה של המשתמש במקרה שמזוהה תאונה או תאונה (למשל כדי לעמוד בדרישות של שיחת eCall).
  • [C-0-4] חובה לשמר את היכולת של ממשק ה-API למעקף של מיקום החירום לעקוף את הגדרות המיקום של המכשיר בלי לשנות את ההגדרות.
  • [C-0-5] חובה לתזמן התראה שתזכיר למשתמש אחרי שאפליקציה ברקע ניגשה למיקום שלו באמצעות ההרשאה [ACCESS_BACKGROUND_LOCATION].

9.8.9. אפליקציות מותקנות

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

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

  • [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
    • פלט של TelephonyRegistry
    • פלט של WifiService
    • פלט של ConnectivityService
    • קובץ dump של המכונה של CarrierService של חבילת השיחות (אם רלוונטי)
    • מאגר נתונים זמני של רדיו
  • [C-1-5] אסור לכלול את הפרטים הבאים בדוחות שנוצרו:
    • כל סוג של מידע שלא קשור ישירות לניפוי באגים בקישוריות.
    • כל סוג של יומני תנועה של אפליקציות שהותקנו על ידי המשתמשים או פרופילים מפורטים של אפליקציות/חבילות שהותקנו על ידי המשתמשים (מזהי UID מותר, אסור שמות של חבילות).
  • עשויים לכלול מידע נוסף שלא משויך לזהות משתמש כלשהי. (למשל, יומנים של ספקים).

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

  • [C-SR-1] מומלץ מאוד להשבית הגדרת מפתח כברירת מחדל. כדי לעשות זאת, צריך לספק את האפשרות Enable verbose vendor logging בהגדרות למפתחים, כדי לכלול בדוחות על הבאגים יומני ספקים נוספים שספציפיים למכשיר.

9.8.11. שיתוף blobs נתונים

ב-Android, באמצעות BlobStoreManager, אפשר לאפליקציות לתרום blobs של נתונים למערכת ולשתף אותם עם קבוצת אפליקציות נבחרת.

אם בהטמעות במכשירים יש תמיכה ב-blobs משותפים כפי שמתואר במסמכי התיעוד של ה-SDK:

  • [C-1-1] אסור לשתף blobs של נתונים ששייכים לאפליקציות מעבר למה שהם התכוונו לאפשר (כלומר, את היקף גישת ברירת המחדל ומצבי גישה אחרים שאפשר לציין באמצעות BlobStoreManager.session#allowPackageAccess(), BlobStore.session#allowUSSignatureAccess() , או BlobStorePrivacyAccess() , או BlobStorePublic.allowAccess() ההטמעה של קובצי העזר של AOSP עומדת בדרישות הבאות.
  • [C-1-2] אסור לשלוח מהמכשיר או לשתף עם אפליקציות אחרות את הגיבובים המאובטחים של אובייקטי נתונים (blobs) שמשמשים לשליטה בגישה.

9.8.12. זיהוי מוזיקה

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

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

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

  • [C-1-1] חייבת להחזיר את הערך 'true' באופן מדויק ל-method של ה-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. הפעלה ישירה

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

  • [C-0-1] חייבים להטמיע את ממשקי ה-API של מצב אתחול ישיר, גם אם הם לא תומכים ב-Storage Encryption.

  • [C-0-2] ה-Intents ACTION_LOCKED_BOOT_COMPLETED ו-ACTION_USER_UNLOCKED עדיין חייבים להיות משודרים כדי לאותת לאפליקציות עם מודעות לאתחול ישיר שמיקומי האחסון בהצפנת מכשיר (DE) ובהצפנת פרטי כניסה (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 הוא תקן Advanced Encryption Standard עם אורך מפתח להצפנה של 256 ביט, שמופעל במצב XTS. האורך המלא של המפתח הוא 512 ביט. Adiantum מתייחס ל-Adiantum-XChaCha12-AES, כפי שמצוין בכתובת https://github.com/google/adiantum. המטא-נתונים של מערכת הקבצים הם נתונים כמו גודל הקבצים, בעלות, מצבים ומאפיינים מורחבים (xattrs).
  • [C-1-6] חובה להצפין את שמות הקבצים באמצעות AES-256-CBC-CTS או Adiantum.
  • [C-1-12] אם למכשיר יש הוראות לגבי תקן הצפנה מתקדם (AES) (כמו תוספי קריפטוגרפיה ARMv8 במכשירים מבוססי 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 שמגובה על ידי חומרה. מאגר המפתחות הזה חייב להיות מקושר ל'הפעלה מאומתת' ול-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 ב-upstream מספק הטמעה מועדפת של הצפנה מבוססת קבצים, שמבוססת על תכונת ההצפנה fscrypt בליבה של Linux, והצפנת מטא-נתונים שמבוססת על תכונת הליבה 'dm-default-key'.

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 שמגובה על ידי חומרה. מאגר המפתחות הזה חייב להיות מקושר ל'הפעלה מאומתת' ול-Root of Trust של החומרה.
    • [C-1-6] חייבים להיות כפופים לפרטי הכניסה של המשתמש המתאים במסך הנעילה.

אפשר להטמיע הצפנה ברמת הבלוק לפי משתמש באמצעות תכונת הליבה 'dm-crypt' של Linux, במחיצות לפי משתמש.

9.9.4. המשך לאחר ההפעלה מחדש

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

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

פרטים נוספים:

  • [C-0-1] אסור שאחסון ל-CE לא יהיה קריא גם לתוקפים שיש להם מכשירים פיזיים במכשיר, ולאחר מכן יש להם את היכולות ומגבלות הבאות:

    • יכולים להשתמש במפתח החתימה של כל ספק או חברה כדי לחתום על הודעות שרירותיות.
    • עלול לגרום לקבלת OTA במכשיר.
    • ניתן לשנות את הפעולה של כל חומרה (AP, Flash וכו') מלבד כפי שמפורט בהמשך, אבל שינוי כזה כרוך בעיכוב של שעה לפחות ומחזור הפעלה שמשמיד את תוכן ה-RAM.
    • לא ניתן לשנות את הפעולה של חומרה עמידה בפני שינויים (לדוגמה, Titan M).
    • לא ניתן לקרוא את זיכרון ה-RAM של המכשיר בשידור חי.
    • לא ניתן לקבל את פרטי הכניסה של המשתמש (קוד אימות, קו ביטול נעילה, סיסמה) או לגרום לכך להזין אותם.

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

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

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

  • [C-0-1] חובה לדווח בצורה נכונה באמצעות method API PersistentDataBlockManager.getFlashLockState() אם מצב תוכנת האתחול מאפשר להבהב של תמונת המערכת.

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

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

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

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

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

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

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

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

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

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

אם הטמעות המכשירים תומכות ב-Android Protected Certificate 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 HMAC ופונקציות הגיבוב המשפחתי MD5, SHA1 ו-SHA-2 כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד באופן מאובטח מהקוד שפועל בליבה (kernel) ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד ליבה או מרחב משתמשים יכול לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. פרויקט קוד פתוח של Android (AOSP) ב-upstream עומד בדרישה הזו באמצעות ההטמעה של Trusty, אבל אפשרויות אחרות מבוססות על פתרון ARM TrustZone או הטמעה מאובטחת של צד שלישי של בידוד מתאים שמבוסס על hypervisor.
  • [C-1-3] חובה לבצע את האימות של מסך הנעילה בסביבת ההפעלה המבודדת ולאפשר שימוש במפתחות שקשורים לאימות רק אחרי שהאימות בוצע בהצלחה. חובה לאחסן את פרטי הכניסה במסך הנעילה באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. פרויקט הקוד הפתוח של Android ב-upstream מספק את ה-Gatekeeper Hardware Abstraction Layer (HAL) ואת Trusty, ואפשר להשתמש בהם כדי לעמוד בדרישה הזו.
  • [C-1-4] חייבת להיות תמיכה באימות עם מפתחות כאשר חתימת האימות מוגן על ידי חומרה מאובטחת, והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות חתימת האימות בין מספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת הדרכים לעמוד בדרישה הזו היא לשתף את אותו מפתח אימות, אלא אם נוצרות לפחות 100,000 יחידות מהמק"ט הנתון. אם מפיקים יותר מ-100,000 יחידות של מק"ט, ייתכן להשתמש במפתח שונה לכל 100,000 יחידות.

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

  • [C-1-5] חובה לאפשר למשתמש לבחור את הזמן הקצוב לתפוגה של מצב שינה לצורך מעבר ממצב נעילה למצב נעול, עם זמן מינימלי מותר של עד 15 שניות. במכשירי כלי רכב, שבהם המסך נועל בכל פעם שהיחידה הראשית מושבתת או כשמתבצעת החלפה של המשתמש, יכול להיות שההגדרה 'הזמן הקצוב לתפוגה של מצב שינה' לא זמינה.
  • [C-1-6] חייבת להיות תמיכה ב-IKeymasterDevice 4.0, ב-IKeymasterDevice 4.1 או ב-IKeyMintDevice בגרסה 1.
  • [C-SR-1] מומלץ מאוד לתמוך ב-IKeyMintDevice בגרסה 1.

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

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

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

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

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

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

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

  • [C-3-1] האנטרופיה של ערכי הקלט הקצרים ביותר המותרים חייבת להיות גדולה מ-10 ביטים.
  • [C-3-2] האנטרופיה המקסימלית של כל ערכי הקלט האפשריים חייבת להיות גדולה מ-18 ביטים.
  • [C-3-3] שיטת האימות החדשה לא תחליף את שיטות האימות הראשיות המומלצות (למשל, קוד אימות, קו ביטול נעילה, סיסמה) שהוטמעו וסיפקו ב-AOSP.
  • [C-3-4] שיטת האימות החדשה MUST תושבת אם האפליקציה Device Policy Controller (DPC) קבעה את המדיניות בנושא דרישות סיסמה באמצעות DevicePolicyManager.setrequiredPasswordComplexity() עם מורכבות מגבילה יותר מאשר password_COMPLY_NONE או דרך המתודה DevicePolicyManager.setSettingsWALtITY() המגבילה יותר מזו של השיטה DevicePolicyManager.setSettingsWALtITY
  • [C-3-5] שיטות אימות חדשות חייבות לחזור לשיטות האימות הראשיות המומלצות (למשל, קוד אימות, קו ביטול נעילה, סיסמה) פעם ב-72 שעות או פחות, או לחשוף בפני המשתמש שחלק מהנתונים לא יגובו כדי לשמור על הפרטיות של הנתונים שלו.

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

  • [C-4-1] חייבת לעמוד בכל הדרישות שמתוארות בסעיף 7.3.10 של Class 1 (לשעבר נוחות).
  • [C-4-2] חייב להיות מנגנון של חזרה למצב הקודם כדי להשתמש באחת משיטות האימות הראשיות המומלצות המבוססות על סוד ידוע.
  • [C-4-3] חובה להשבית ולאפשר לאימות הראשי המומלץ רק ביטול של נעילת המסך כשהאפליקציה Device Policy Controller (DPC) מגדירה את המדיניות בנושא תכונת מגן המקשים באמצעות קריאה ל-method DevicePolicyManager.setKeyguardDisabledFeatures()) , יחד עם כל אחד מהדגלים הביומטריים המשויכים (למשל: KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE או KEYGUARD_DISABLE_IRIS).

אם שיטות האימות הביומטרי לא עומדות בדרישות של רמה 3 (לשעבר Strong), כפי שמתואר בסעיף 7.3.10:

  • [C-5-1] השיטות חייבות להיות מושבתות אם האפליקציה Device Policy Controller (DPC) הגדירה את מדיניות האיכות לגבי דרישות הסיסמה באמצעות DevicePolicyManager.setrequiredPasswordComplexity() עם קטגוריית מורכבות יותר מגבילה יותר מאשר PASSWORD_COMPLEXITY_LOW, או משתמשת במתודה DevicePolicyManager.setPassword Quality() עם קבוע איכות מגביל יותר מאשר ב-PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • [C-5-2] חובה לחייב את המשתמש לבצע את האימות הראשי המומלץ (למשל: קוד אימות, קו ביטול נעילה, סיסמה) כפי שמתואר בסעיפים [C-1-7] ו-[C-1-8] בסעיף 7.3.10.
  • [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 TV או מכשיר Automotive).
  • [C-7-4] חובה להצפין את כל האסימונים המאוחסנים שנוספו על ידי TrustAgentService.addEscrowToken().
  • [C-7-5] אסור לאחסן את מפתח ההצפנה או את אסימון הנאמנות באותו מכשיר שבו משתמשים במפתח. לדוגמה, מותר למפתח ששמור בטלפון לבטל את הנעילה של חשבון משתמש בטלוויזיה. אסור לאחסן את אסימון הנאמנות באף חלק של הרכב במכשירים עם כלי רכב.
  • [C-7-6] חובה להודיע למשתמש על השלכות האבטחה לפני שמפעילים את אסימון הנאמנות כדי לפענח את אחסון הנתונים.
  • [C-7-7] כדי להשתמש באחת משיטות האימות הראשיות המומלצות, חייב להיות מנגנון של חזרה למצב הקודם.
  • [C-7-8] חובה לחייב את המשתמש להשתמש באחת מהשיטות המומלצות לאימות ראשי (למשל: קוד אימות, קו ביטול נעילה, סיסמה) לפחות פעם אחת בכל 72 שעות או פחות, אלא אם יש חשש בנוגע לבטיחות המשתמש (למשל, הסחות דעת של הנהג).
  • [C-7-9] חובה לחייב את המשתמש להשתמש באחת מהשיטות המומלצות לאימות ראשי (למשל: קוד אימות, קו ביטול נעילה, סיסמה), כפי שמתואר ב-[C-1-7] ו-[C-1-8] בסעיף 7.3.10, אלא אם יש חשש בנוגע לבטיחות המשתמש (למשל, הסחת דעת של הנהג).
  • [C-7-10] אסור להתייחס אל כמסך נעילה מאובטח, והוא חייב לפעול בהתאם למגבלות שמפורטות ב-C-8 בהמשך.
  • [C-7-11] אסור לאפשר לסוכנים מהימנים במכשירים ראשיים אישיים (למשל: להחזקה ביד) לבטל את הנעילה של המכשיר, והם יכולים להשתמש בהם רק כדי להשאיר מכשיר שכבר לא נעול במצב ביטול הנעילה למשך 4 שעות לכל היותר. הטמעת ברירת המחדל של TrustManagerService ב-AOSP עומדת בדרישה הזו.
  • [C-7-12] חובה להשתמש בערוץ תקשורת מאובטח מבחינה קריפטוגרפית (למשל UKEY2) כדי להעביר את אסימון הנאמנות ממכשיר האחסון למכשיר היעד.

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

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

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

  • [C-1-5] חייב להיות שעון פנימי בעל רמת דיוק סבירה (מעל 10%), חסין מפני מניפולציות על ידי AP.

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

  • [C-1-7] חייבת להיות עמידות בפני זיוף, כולל עמידות בפני חדירה פיזית ותקלות.

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

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

  • כדי לאמת תאימות ל-[C-1-3] עד [C-1-9], הטמעות במכשירים:

    • [C-1-10] חייבת לכלול את החומרה שאושרה בהתאם ל-Secure IC Protection Profile BSI-CC-PP-0084-2014, או שנבדקה על ידי מעבדת בדיקות בעלת הסמכה לאומית שמשלבת הערכה של נקודות חולשה פוטנציאליות בעוצמה גבוהה בהתאם לקריטריונים נפוצים של פוטנציאל התקפה ל-Smartcards.
    • [C-1-11] חייבת לכלול את הקושחה שנבדקת על ידי מעבדת בדיקות בעלת הסמכה לאומית, שכוללת גם הערכה של נקודות חולשה הפוטנציאליות למתקפה גבוהה, בהתאם לקריטריונים נפוצים ליישום פוטנציאל התקפה על כרטיסי Smartcards.
    • [C-SR-2] מומלץ מאוד לכלול את החומרה שנבדקת באמצעות יעד אבטחה, Evaluation Assurance Level (EAL) 5, בתוספת על ידי AVA_VAN.5. סביר להניח שאישור EAL 5 יהפוך לדרישה בגרסה עתידית.

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

9.11.3. פרטי כניסה לזהות

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

  • [C-SR-1] מומלץ מאוד להטמיע את המערכת לאימות זהות (IDV).

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

  • [C-1-1] חייבים להחזיר ערך שאינו null במתודה IdentityCredentialStore#getInstance().

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

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

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

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

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

  • [C-0-1] חובה לספק למשתמשים מנגנון לביצוע 'איפוס לנתוני היצרן'.
  • [C-0-2] חובה למחוק את כל הנתונים במערכת הקבצים של נתוני המשתמש כשמבצעים "איפוס לנתוני היצרן".
  • [C-0-3] חובה למחוק את הנתונים באופן שעומד בתקנים רלוונטיים בתחום, כמו NIST SP800-88 כשמבצעים איפוס לנתוני היצרן.
  • [C-0-4] התהליך חייב להפעיל את תהליך איפוס נתוני היצרן שצוין למעלה כשאפליקציית Device Policy Controller של המשתמש הראשי מופעלת ל-API DevicePolicyManager.wipeData().
  • עשויה לספק אפשרות מהירה למחיקת נתונים שמבצעת רק מחיקה לוגית של נתונים.

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

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

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

  • [C-SR-1] מומלץ מאוד להטמיע את מצב ההפעלה הבטוחה.

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

  • [C-1-1] חייבת לספק למשתמש אפשרות להיכנס למצב הפעלה בטוחה באופן שלא יהיה הפרעה לאפליקציות צד שלישי שמותקנות במכשיר, למעט במקרים שבהם האפליקציה של הצד השלישי היא Device Policy Controller, והיא מגדירה את הדגל UserManager.DISALLOW_SAFE_BOOT כ-true.

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

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

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

מכשירי Android Automotive צפויים לשתף נתונים עם מערכות משנה קריטיות לרכב באמצעות HAL של הרכב כדי לשלוח ולקבל הודעות ברשתות של רכבים כמו CAN bus.

אפשר לאבטח את בורסת הנתונים על ידי הטמעת תכונות אבטחה מתחת לשכבות ה-framework של 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 Secure Lock Screen ואימות.
  • [C-1-2] חובה לאשר באופן מאובטח את האימות הראשי במכשיר המקור, ולאשר בכוונת המשתמש להעתיק את הנתונים למכשיר המקור לפני העברת הנתונים.
  • [C-1-3] חובה להשתמש באימות (attestation) של מפתח אבטחה כדי לוודא שמכשיר המקור ומכשיר היעד בהעברה ממכשיר למכשיר הם מכשירי Android לגיטימיים ושיש בהם תוכנת אתחול נעולה.
  • [C-1-4] חייבים להעביר נתוני אפליקציה רק לאותה אפליקציה במכשיר היעד, עם אותו שם חבילה ואישור החתימה.
  • [C-1-5] חייב להראות בתפריט ההגדרות אינדיקציה לכך שנתונים הועברו מהמכשיר המקורי באמצעות העברת נתונים ממכשיר למכשיר. משתמשים לא אמורים להסיר את האינדיקציה הזו.

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

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

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

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

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

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

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

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

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

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

10.2. מאמת CTS

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

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

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

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

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

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

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

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

11. תוכנות Updatable

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

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

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

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

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

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

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

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

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

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

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

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

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

12. יומן שינויים במסמך

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

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

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

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

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

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

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

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

13. יצירת קשר

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