יומן שינויים של מסמך הגדרת תאימות ל-Android

Android 14

26 ביוני 2024

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

  • 2.2.1. חומרה:

    הצגת גרסה קודמת

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

    הצגת גרסה קודמת

    התחלה של דרישות חדשות

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

  • 2.4.1. חומרה:

    הצגת גרסה קודמת

    התחלה של דרישות חדשות

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

  • 2.5.1. חומרה:

    הצגת גרסה קודמת

    התחלה של דרישות חדשות

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

3. תוכנה

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

    לפרמטר ODM_SKU:

    הצגת גרסה קודמת

    הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות ולהתאים לביטוי הרגולרי ^([0-9A-Za-z.,_-]+)$.

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

  • 5.1.3. פרטים על רכיבי קודק האודיו:

    נוספו פרטים עבור הפורמט/הקודק של Vorbis:

    הצגת גרסה קודמת

    פענוח: תמיכה בתוכן מונו, סטריאו, 5.0 ו-5.1 עם קצבי דגימה של 8,000, 12,000, 16,000, 24,000 ו-48,000 Hz.
    קידוד: תמיכה בתוכן מונו ו-5.1 עם קצבי דגימה של 8000, 12000, 8000 ו-48,000

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

9. התאימות של דגם האבטחה

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

    מספור מחדש [C-SR-1] עד [C-SR-7] כדי להסיר תוכן כפול והוסר [C-SR-8]:

    הצגת גרסה קודמת

    • [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 Overflow Sanitization (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) בליבה (kernel) כדי למנוע שימוש בהקצאות ערימה שלא בוצעו (CONFIG_INIT_ON_ALLOC_DEFAULT_ON), ולא צריך להניח את הערך שמשמש את הליבה לאתחול ההקצאות האלה.

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

    הצגת גרסה קודמת

    • [C-1-6] חייבת לתמוך באחת מהאפשרויות הבאות:
      • IKeymasterDevice 3.0,
      • IKeymasterDevice 4.0,
      • IKeymasterDevice 4.1,
      • IKeyMintDevice בגרסה 1, או
      • IKeyMintDevice גרסה 2.

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

    הצגת גרסה קודמת

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

    הצגת גרסה קודמת

    • [C-12-4] חובה להתקשר למספר TrustManagerService.revokeTrust()
      • לאחר 24 שעות לכל היותר ממועד הענקת אמון, או
      • לאחר 8 שעות של חוסר פעילות, או
      • אם ההטמעות לא משתמשות בטווח מאובטח מבחינה קריפטוגרפית ומדויקת כפי שמוגדר ב-[C-12-5], החיבור הבסיסי למכשיר הפיזי הקרוב מתנתק.
    • [C-12-5] הטמעות שמסתמכות על טווח מאובטח ומדויק כדי לעמוד בדרישות של [C-12-4] חייבות להשתמש באחד מהפתרונות הבאים:
      • הטמעות באמצעות UWB:
        • האפליקציות צריכות לעמוד בדרישות בנושא תאימות, אישור, דיוק וכיול ל-UWB שמתוארות בסעיף 7.4.9.
        • חייבים להשתמש באחד ממצבי האבטחה של P-STS שמפורטים ב-7.4.9.
      • הטמעות באמצעות Wi-Fi Neighborood Awareness Networking (NAN):
        • חייב לעמוד בדרישות הדיוק ב-2.2.1 [7.4.2.5/H-SR-1], להשתמש ברוחב הפס של 160MHz (או יותר) ולפעול לפי שלבי הגדרת המדידה שמפורטים בכיול הנוכחות.
        • חייבים להשתמש ב-Secure LTF כפי שמוגדר ב-IEEE 802.11az.

8 באפריל 2024

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

  • 2.2.1. חומרה:

    הצגת גרסה קודמת

    התחלה של דרישות חדשות

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

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

  • 2.2.5. מודל האבטחה:

    הצגת גרסה קודמת

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

    • [9.8/H-1-6] אסור לאפשר העברה של יותר מ-100 בייטים של נתונים משירות הזיהוי של מילות ההפעלה בכל תוצאה של מילת הפעלה מוצלחת, פרט לנתוני אודיו שמועברים דרך HotwordAudioStream.

    הצגת גרסה קודמת

    שינוי [9.8/H-1-13] ל:

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

    הצגת גרסה קודמת

    דרישות שהוסרו [9.8.2/H-4-3], [9.8.2/H-4-4], [9.8.2/H-5-3].

  • 2.2.7.2. מצלמה:

    הצגת גרסה קודמת

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

    • [7.5/H-1-3] חייבת לתמוך בנכס android.info.supportedHardwareLevel בתור FULL ומעלה בשביל הראשי הראשי, LIMITED או טובה יותר למצלמה הראשית הקדמית.

  • 2.3.2. מולטימדיה:

    הצגת גרסה קודמת

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

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

3. תוכנה

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

  • 5.3.8. Dolby Vision:

    הצגת גרסה קודמת

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

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

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

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

    הצגת גרסה קודמת

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

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

  • 7.4.3. Bluetooth:

    הצגת גרסה קודמת

    החזרנו את הדרישות הבאות:

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

    • [C-SR-2] מומלץ מאוד למדוד ולפצות על היסט Rx כדי לוודא שה-RSSI החציוני של BLE הוא -60dBm +/-10dB במרחק של 1 מטר ממכשיר עזר שמשדר ב-ADVERTISE_TX_POWER_HIGH, שבו המכשירים מכוונים באופן כזה שהם נמצאים ב 'מישורים מקבילים' עם מסכים שפונים לאותו כיוון.

    • [C-SR-3] מומלץ מאוד למדוד ולפצות על היסט Tx כדי לוודא שה-RSSI החציוני של BLE הוא -60dBm +/-10dB בסריקה ממכשיר עזר שממוקם במרחק של מטר ומשדר ב-ADVERTISE_TX_POWER_HIGH, כך שהמכשירים ממוקמים ב'מישורים מקבילים' עם מסכים הפונים לאותו כיוון.

    הצגת גרסה קודמת

    הדרישות [C-10-3] ו-[C-10-4] הועברו ל-2.2.1. חומרה.

    • [C-10-3] חובה למדוד ולפצות על היסט Rx כדי לוודא שה-RSSI החציוני של BLE הוא -55dBm +/-10dB במרחק של 1 מטר ממכשיר עזר שמשדר ב-ADVERTISE_TX_POWER_HIGH.
    • [C-10-4] חובה למדוד ולפצות על היסט Tx כדי לוודא שה-RSSI החציוני של BLE הוא -55dBm +/-10dB בסריקה ממכשיר עזר שנמצא במרחק של 1 מטר ומשדר ב-ADVERTISE_TX_POWER_HIGH.

20 בנובמבר 2023

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

  • 2.2.1. חומרה:

    הצגת גרסה קודמת

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

  • 2.2.7.2. מצלמה:

    הצגת גרסה קודמת

    • [7.5/H-1-13] במצלמה האחורית הראשית חייבת להיות תמיכה ביכולת LOGICAL_MULTI_CAMERA, אם יש יותר מ-1 מצלמות RGB אחוריות.

  • 2.3.2. מולטימדיה:

    הצגת גרסה קודמת

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

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

  • 2.4.5. מודל האבטחה:

    הצגת גרסה קודמת

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

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

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

    הצגת גרסה קודמת

    • [C-0-12] חובה לכתוב Atom מסוג LMK_KILL_OCCURRED_FIELD_NUMBER

    הצגת גרסה קודמת

    • [C-0-13] חובה להטמיע את פקודת המעטפת dumpsys gpu --gpuwork כדי להציג

9. התאימות של דגם האבטחה

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

    הצגת גרסה קודמת

    אם הטמעות של מכשירים משתמשות בליבה (kernel) של Linux שמסוגלת לתמוך ב-SELinux, הן:

    הצגת גרסה קודמת

    אם הטמעות של מכשירים משתמשות בליבה (kernel) אחרת מלבד Linux או Linux בלי SELinux:

4 באוקטובר 2023

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

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

    הצגת גרסה קודמת

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

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

    התחלה של דרישות חדשות

    • להשתמש בממשק קלט מסך מגע.

  • 2.2.1. חומרה:

    הצגת גרסה קודמת

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

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

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

    • [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 או לפני כן.

    התחלה של דרישות חדשות

    • [7.1.1.1/H-0-3]* חייבים למפות כל מסך UI_MODE_NORMAL שזמין לאפליקציות צד שלישי לאזור תצוגה פיזי ללא הפרעות, בגודל של לפחות 2.2 אינץ' בקצה הקצר ו-3.4 אינץ' בקצה הארוך.

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

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

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

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

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

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

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

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

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

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

  • 2.2.2. מולטימדיה:

    הצגת גרסה קודמת

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

    • [5.2/H-0-3] AV1

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

    • [5.3/H-0-6] AV1

  • 2.2.3. תוכנה:

    הצגת גרסה קודמת

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

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

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

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

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

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

    הצגת גרסה קודמת

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

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

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

  • 2.2.5. מודל האבטחה:

    הצגת גרסה קודמת

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 2.2.7.1. מדיה:

    הצגת גרסה קודמת

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

    התחלה של דרישות חדשות

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

    • [5.1/H-1-1] חייבים לפרסם את המספר המקסימלי של סשנים של מפענח וידאו מהחומרה שאפשר להריץ בו-זמנית בכל שילוב של קודק באמצעות method CodecCapabilities.getMaxSupportedInstances() ו-VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-2] חייבים לתמוך ב-6 מופעים של הפעלות של מפענח וידאו בחומרה של 8 ביט (SDR) (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב קודק שפועל בו-זמנית עם 3 הפעלות ברזולוציית 1080p@30fps ו-3 הפעלות ב-4k Resolution@10fps, אלא אם רכיבי קודק AV1 נדרשים רק כדי לתמוך ברזולוציה של 1080p, אבל עדיין הם נדרשים כדי לתמוך ב-6 מכונות בקצב של 1080p30fps.
    • [5.1/H-1-3] חייבים לפרסם את המספר המקסימלי של סשנים של מקודד וידאו בחומרה שאפשר להריץ בו-זמנית בכל שילוב קודק באמצעות method CodecCapabilities.getMaxSupportedInstances() ו-VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-4] חייב לתמוך ב-6 מופעים של מקודדי וידאו באיכות 8 ביט (SDR) בחומרה (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב קודק שפועל בו-זמנית עם 4 הפעלות ברזולוציית 1080p@30fps ו-2 הפעלות במהירות 4k Resolution@10fps, אלא אם רכיבי קודק AV1 נדרשים רק כדי לתמוך ברזולוציה של 1080p, אבל עדיין הם נדרשים כדי לתמוך ב-6 מכונות בקצב של 1080p30fps.
    • [5.1/H-1-5] חייבים לפרסם את המספר המקסימלי של סשנים של מקודד וידאו ומפענח, שיכולים לפעול בו-זמנית בכל שילוב של קודק באמצעות השיטות CodecCapabilities.getMaxSupportedInstances() ו-VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-6] חייבים לתמוך ב-6 מופעים של מפענח וידאו בחומרה של 8 ביט (SDR) ושל סשנים של מקודד וידאו בחומרה (AVC, HEVC, VP9 ו-AV1 ואילך) בכל שילוב קודק שפועל בו-זמנית עם 3 הפעלות ברזולוציה של 4K@30fps (אלא אם 1, שמתוכם 3 ברזולוציית AV1 לכל היותר) רכיבי קודק AV1 נדרשים רק כדי לתמוך ברזולוציה של 1080p, אבל עדיין הם נדרשים כדי לתמוך ב-6 מכונות בקצב של 1080p30fps.
    • [5.1/H-1-19] חייבים לתמוך ב-3 מופעים של סשנים של מפענח וידאו בחומרה של 10 ביט (HDR) ושל מקודד וידאו עם חומרה (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב קודק שפועל בו-זמנית ברזולוציית 4K@30fps (אלא אם כן AV10fps) אם הקידוד ממשטח ה-GL, אין צורך ליצור מטא-נתונים של HDR על ידי המקודד. סשנים של קודק AV1 נדרשים רק כדי לתמוך ברזולוציה 1080p גם אם לפי הדרישה הזו נדרשת איכות 4K.
    • [5.1/H-1-7] חייבים להיות זמן אחזור של אתחול קודק של 40 אלפיות השנייה או פחות לסשן של קידוד וידאו ברזולוציה של 1080p או פחות בכל מקודדי הווידאו בחומרה כשהם בטעינה. הטעינה כאן מוגדרת כסשן המרת קידוד של וידאו בלבד מרזולוציית 1080p ל-720p בו-זמנית באמצעות קודק וידאו מהחומרה, יחד עם אתחול של הקלטת אודיו-וידאו ברזולוציית 1080p. עבור קודק הראייה של Dolby, זמן האחזור של אתחול הקודק חייב להיות 50 אלפיות השנייה או פחות.
    • [5.1/H-1-8] נדרש זמן אחזור של אתחול קודק של 30 אלפיות השנייה או פחות לסשן של קידוד אודיו עם קצב העברת נתונים של 128kbps או פחות בשביל כל מקודדי האודיו בזמן טעינה. הטעינה כאן מוגדרת כסשן המרת קידוד של וידאו בלבד מרזולוציית 1080p ל-720p בו-זמנית באמצעות קודק וידאו מהחומרה, יחד עם אתחול של הקלטת אודיו-וידאו ברזולוציית 1080p.
    • [5.1/H-1-9] חייבת לתמוך בשני מופעים של הפעלות של מפענח וידאו מאובטח באמצעות חומרה (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב קודק שפועל בו-זמנית ב-4k ברזולוציה של 30FPS (אלא אם כן AV1) בתוכן של 8 ביט (SDR) ובתוכן HDR באיכות 10 ביט. סשנים של קודק AV1 נדרשים רק כדי לתמוך ברזולוציה 1080p גם אם לפי הדרישה הזו נדרשת איכות 4K.
    • [5.1/H-1-10] חייבת להיות תמיכה ב-3 מופעים של סשנים לא מאובטחים של מפענח וידאו בחומרה 1-0FPS, יחד עם מכונה אחת של סשן של מפענח וידאו מאובטח באמצעות חומרה (4 מופעים בסך הכול) (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב קודק שפועלים בו-זמנית עם 3 סשנים בקצב 4K@30fps עם רזולוציה של 4K@0fps, וסשן אחד של AV1 סשנים של קודק AV1 נדרשים רק כדי לתמוך ברזולוציה 1080p גם אם לפי הדרישה הזו נדרשת איכות 4K.
    • [5.1/H-1-11] חייב לתמוך במפענח מאובטח בכל מפענח חומרה מסוג AVC, HEVC, VP9 או AV1 במכשיר.
    • [5.1/H-1-12] זמן האחזור לאתחול קודק חייב להיות 40 אלפיות השנייה או פחות לסשן של פענוח וידאו ברזולוציה של 1080p או פחות בכל מפענחי הווידאו בחומרה כשהם בטעינה. הטעינה כאן מוגדרת כסשן המרת קידוד של וידאו בלבד מ-1080p ל-720p באמצעות קודק וידאו מהחומרה יחד עם אתחול של הפעלת אודיו-וידאו ב-1080p. עבור קודק הראייה של Dolby, זמן האחזור של אתחול הקודק חייב להיות 50 אלפיות השנייה או פחות.
    • [5.1/H-1-13] לכל מקודדי האודיו בזמן טעינה חייב להיות זמן אחזור של אתחול קודק של 30 אלפיות השנייה או פחות לפעילות של פענוח אודיו של 128kbps או פחות. הטעינה כאן מוגדרת כסשן המרת קידוד של וידאו בלבד מרזולוציית 1080p ל-720p בו-זמנית באמצעות קודק וידאו מהחומרה, יחד עם אתחול של הפעלת אודיו-וידאו ב-1080p.
    • [5.1/H-1-14] חייבת להיות תמיכה במפענח חומרה AV1 ראשי 10, רמה 4.1 וגרעינית סרט.
    • [5.1/H-1-15] חייב להיות לפחות מפענח חומרה אחד לפענוח וידאו שתומך ב-4K60.
    • [5.1/H-1-16] חייב להיות לפחות מקודד אחד של חומרה של וידאו שתומך ב-4K60.
    • [5.3/H-1-1] אסור לשחרר יותר מפריים אחד ב-10 שניות (כלומר פחות מ-0.167 אחוז פריים) בהפעלה של וידאו באיכות 4K 60fps.
    • [5.3/H-1-2] אסור להנמיך יותר מפריים אחד ב-10 שניות במהלך שינוי רזולוציה של סרטון בסשן של וידאו בקצב של 60fps בסשן של 4K.
    • [5.6/H-1-1] זמן האחזור של הקשה לטון חייב להיות של 80 אלפיות השנייה או פחות באמצעות בדיקת ההקשה לטון של CTS Verifier.
    • [5.6/H-1-2] זמן האחזור של האודיו הלוך ושוב הוא 80 אלפיות השנייה או פחות מנתיב נתונים נתמך אחד לפחות.
    • [5.6/H-1-3] חייבת תמיכה באודיו של 24 ביט לפחות בפלט סטריאו עם שקעי אודיו של 3.5 מ "מ ומעלה, אם יש כאלה, ובחיבור אודיו ב-USB אם קיימת תמיכה כזו לאורך כל נתיב הנתונים, בשביל הגדרות של זמן אחזור קצר וסטרימינג. לצורך הגדרת זמן אחזור קצר, האפליקציה צריכה להשתמש באודיו במצב קריאה חוזרת (callback) עם זמן אחזור קצר. בהגדרות של הסטרימינג, האפליקציה צריכה להשתמש ב-Java AudioTrack. גם בהגדרות של זמן אחזור נמוך וגם בהגדרות של סטרימינג, ה-sink של פלט HAL צריך לקבל AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT או AUDIO_FORMAT_PCM_FLOAT בשביל פורמט הפלט של היעד.
    • [5.6/H-1-4] חייבת להיות תמיכה ביותר מ-4 ערוצים של התקני אודיו בחיבור USB (לבקרים של די-ג'יי כדי להאזין לקטע קצר של שירים).
    • [5.6/H-1-5] חייבת להיות תמיכה במכשירי MIDI שתואמים למחלקות, ולהצהיר על דגל הפיצ'ר של MIDI.
    • [5.6/H-1-9] חייבת לתמוך לפחות ב-12 ערוצים במיקס. זה כולל את היכולת לפתוח AudioTrack עם מסכת ערוצים של 7.1.4, ולבצע התאמה מרחבית או שילובים מתאימים של כל הערוצים לסטריאו.
    • [5.6/H-SR] מומלץ מאוד לתמוך בתמהיל של 24 ערוצים עם תמיכה לפחות במסכות של 9.1.6 ו-22.2 ערוצים.
    • [5.7/H-1-2] חייבת להיות תמיכה ב-MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL עם יכולות פענוח התוכן שבהמשך.
    גודל דגימה מינימלי 4 MiB
    מספר מינימלי של תתי-דגימות – H264 או HEVC 32
    מספר מינימלי של דוגמאות משנה – VP9 9
    מספר מינימלי של תתי-דגימות – AV1 288
    גודל מינימלי של מאגר נתונים זמני של תת-דגימה MiB1
    גודל כללי מינימלי למאגר הנתונים הזמני של מטבעות וירטואליים 500 KiB
    המספר המינימלי של סשנים בו-זמנית 30
    מספר מפתחות מינימלי לכל סשן 22
    מספר כולל מינימלי של מפתחות (כל הסשנים) 80
    מספר כולל מינימלי של מפתחות DRM (כל הסשנים) 6
    גודל ההודעה 16 KiB
    פענוח פריימים לשנייה (FPS) 60 fps
    • [5.1/H-1-17] חייב להיות לפחות מפענח אחד של תמונת חומרה של מקודד שתומך ב-AVIF Baseline Profile.
    • [5.1/H-1-18] חייב לתמוך במקודד AV1 שיכול לקודד ברזולוציה של עד 480p ב- 30fps ו-1Mbps.
    • [5.12/H-1-1] חובה [5.12/H-SR] מומלץ מאוד לתמוך בתכונה Feature_HdrEditing בכל מקודדי החומרה AV1 ו-HEVC שקיימים במכשיר.
    • [5.12/H-1-2] חייב לתמוך בפורמט הצבע RGBA_1010102 בכל מקודדי החומרה AV1 ו-HEVC שקיימים במכשיר.
    • [5.12/H-1-3] חייבים לפרסם תמיכה בתוסף EXT_YUV_target כדי לדגום טקסטורות של YUV, גם ב-8 וגם ב-10 ביט.
    • [7.1.4/H-1-1] חייבות להיות לפחות 6 שכבות-על של חומרה ברכיב עיבוד הנתונים (DPU) (HWC), ולפחות 2 מתוכן יכולות להציג תוכן וידאו של 10 ביט.

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

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

  • 2.2.7.2. מצלמה:

    הצגת גרסה קודמת

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

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

  • 2.2.7.3. חומרה:

    הצגת גרסה קודמת

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

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

  • 2.2.7.4. ביצועים:

    הצגת גרסה קודמת

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

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

  • 2.3.2. מולטימדיה:

    הצגת גרסה קודמת

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

    • [5.2/T-0-3] AV1

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

  • 2.4.5. מודל האבטחה:

    הצגת גרסה קודמת

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

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

  • 2.5.1. חומרה:

    הצגת גרסה קודמת

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • [7.5/A-3-1] חייב לעמוד בדרישות הליבה לגבי המצלמה בסעיף 7.5.

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

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

    אם בהטמעות של מכשירי כלי רכב יש מצלמה אחת או יותר שאפשר לגשת אליהן באמצעות שירות תצוגה מורחבת (Extended View System) עבור מצלמה כזו:

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

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

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

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

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

  • 2.5.3. תוכנה:

    הצגת גרסה קודמת

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

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

  • 2.5.5. מודל האבטחה:

    הצגת גרסה קודמת

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

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

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

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

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

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

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

3. תוכנה

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

    הצגת גרסה קודמת

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

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

  • 3.2.3.5. אובייקטים מסוג Intent מותנים באפליקציה:

    הצגת גרסה קודמת

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

  • 3.3.1. Application Binary Interfaces:

    הצגת גרסה קודמת

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

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

  • 3.8.6. עיצובים:

    הצגת גרסה קודמת

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

    • [C-1-5] חובה ליצור לוחות צבעים דינמיים של צבעים באמצעות סגנונות של עיצובי צבעים שמפורטים במסמכי התיעוד של Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (ראו android.theme.customization.theme_styles), למשל TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD, ו-MONOCHROMATIC.

  • 3.8.8. שינוי פעילות:

    הצגת גרסה קודמת

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

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

    הצגת גרסה קודמת

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

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

  • 3.9.5 Device Policy Resolution Framework: קטע חדש

    הצגת גרסה קודמת

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

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

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

  • 5.1.4. קידוד התמונה:

    הצגת גרסה קודמת

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

    • [C-0-4] AVIF
      • המכשירים חייבים לתמוך ב-BITRATE_MODE_CQ ובפרופיל Baseline.

  • 5.1.5. פענוח הקוד של התמונה:

    הצגת גרסה קודמת

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

    [C-0-7] AVIF (פרופיל בסיס)

  • 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)
    AVIF (פרופיל הבסיס) תמונה, אוסף תמונות, פרופיל בסיס של רצף תמונות מאגר HEIF (.avif)

  • 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
    AV1 פרטים נוספים זמינים בסעיף 5.2 ובסעיף 5.3
    • MPEG-4 (.mp4)
    • Matroska (.mkv, פענוח בלבד)

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

    הצגת גרסה קודמת

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

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

  • 5.2. קידוד הווידאו:

    הצגת גרסה קודמת

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

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

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

    • [C-5-1] חייב אסור להיות מעל חלון הזזה אחד בקצב של יותר מ-15% בין קצבי העברת נתונים בתוך הפריים (I-frame).
    • [C-5-2] חייב לא להיות יותר מ-100% מקצב העברת הנתונים במהלך חלון הזזה של שנייה אחת.

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

    • [C-6-1] חייב [C-SR-2] מומלץ מאוד לא להיות יותר מ-15% מקצב העברת הנתונים שהוגדר במהלך חלון הזזה של שנייה אחת.

  • 5.2.1. H.263:

    הצגת גרסה קודמת

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

    • [C-1-1] חייבת לתמוך ברזולוציית QCIF (176 x 144) באמצעות פרופיל בסיס ברמה 45. רזולוציית SQCIF היא אופציונלית.
    • צריכה לתמוך בקצבי העברת נתונים שאפשר להגדיר באופן דינמי למקודד הנתמך.

  • 5.2.5. H.265:

    הצגת גרסה קודמת

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

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

  • 5.2.6. AV1: קטע חדש

    הצגת גרסה קודמת

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

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

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

    • [C-1-3] חובה לקבל מטא-נתונים של HDR ופלט אותם ב-bitstream

    אם המקודד AV1 מואץ באמצעות חומרה, הוא:

    • [C-2-1] חייבת לתמוך בפרופיל קידוד HD1080p לכל היותר (כולל) מהטבלה הבאה:
    SD HD 720p HD 1080p UHD
    רזולוציית וידאו 720 x 480 פיקסלים 720 x 1280 פיקסלים 1920 x 1080 פיקסלים 3840 x 2160 פיקסלים
    קצב הפריימים של הסרטון 30 fps 30 fps 30 fps 30 fps
    קצב העברת נתונים של וידאו ‎5Mbps 8Mbps 16Mbps 50 Mbps

  • 5.3.2. H.263:

    הצגת גרסה קודמת

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

    • [C-1-1] חייבת להיות תמיכה ברמה של פרופיל הבסיס ברמה 30 (רזולוציות CIF, QCIF ו-SQCIF @ 30fps) ורמה 45 (רזולוציות QCIF ו-SQCIF תוך 128kbps).

  • 5.3.9. AV1:

    הצגת גרסה קודמת

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

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

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

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

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

    • [C-2-1] חייבת להיות אפשרות לפענח פרופילים של פענוח וידאו באיכות HD 720p לפחות מהטבלה למטה, כשהגובה שמדווח באמצעות method Display.getSupportedModes() שווה ל-720p או גדול ממנו.
    • [C-2-2] חייבת להיות אפשרות לפענח פרופילים של פענוח וידאו באיכות HD 1080p לפחות מהטבלה למטה, כשהגובה שמדווח באמצעות method Display.getSupportedModes() שווה ל- 1080p או גדול ממנו.
    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
    קצב העברת נתונים של וידאו ‎5Mbps 8Mbps 16Mbps 50 Mbps

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

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

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

    הצגת גרסה קודמת

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

    • יש להגדיר את הרגישות לקלט האודיו BOUd 3 עד 1,000 Hz לכל דגימות קול סינוסואידיאליות ב- 1,000 Hz עד 30 Hz. הושמעו ב-SPL (SPL) רמת לחץ של 90 dB (נמדדת במרחק של 30 ס"מ מ- ליד המיקרופון) ותקבלו תגובה אידיאלית של RMS 2500 בטווח של RMS 2500

  • 5.5.2. אפקטים אודיו:

    הצגת גרסה קודמת

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

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

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

    הצגת גרסה קודמת

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

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

    • [C-SR-4] זמן האחזור הלוך ושוב המחושב על סמך חותמות הזמן של הקלט והפלט שהוחזרו על ידי AAudioStream_getTimestamp מומלץ מאוד להיות בטווח של 30 אלפיות השנייה מזמן האחזור שנמדד בנסיעה הלוך ושוב של AAUDIO_PERFORMANCE_MODE_NONE ו-AAUDIO_PERFORMANCE_MODE_LOW_LATENCY ברמקולים, באוזניות חוטיות ובאוזניות אלחוטיות.

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

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

    הצגת גרסה קודמת

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

    התחלה של דרישות חדשות

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

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

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

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

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

    הצגת גרסה קודמת

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

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

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

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

    התחלה של דרישות חדשות

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

    • [C-4-1] גודל הפריסה חייב להיות לפחות 596 dp x 384 dp, לא כולל גזירים במסך.

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

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

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

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

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

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

  • 7.1.1.3. דחיסות המסך:

    הצגת גרסה קודמת

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

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

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

    התחלה של דרישות חדשות

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

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

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

  • 7.1.4.2 Vulkan:

    הצגת גרסה קודמת

    אם הטמעות המכשירים כוללות תמיכה ב-Vulkan 1.0 ואילך:

    • [C-1-3] חובה להטמיע באופן מלא את ממשקי ה-API של Vulkan 1.0 Vulkan 1.1 בכל ספירה שלVkPhysicalDevice.

    • [C-1-5] אסור לספור את השכבות שמסופקות על ידי ספריות מחוץ לחבילת האפליקציה, או לספק דרכים אחרות למעקב או ליירוט של Vulkan API, אלא אם האפליקציה android:debuggable מוגדרת כ-true או שהמטא-נתונים com.android.graphics.injectLayers.enable מוגדרים ל-true .

    • היא צריכה לתמוך ב-VkPhysicalDeviceProtectedMemoryFeatures וב-VK_EXT_global_priority.

    • [C-SR-5] מומלץ מאוד לתמוך ב-VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory וב-VK_EXT_global_priority.

    • [C-SR-6] מומלץ מאוד להשתמש ב-SkiaVk עם HWUI.

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

    • [C-SR-7] מומלץ מאוד להפוך את התוסף VK_KHR_external_fence_fd לזמין לאפליקציות של צד שלישי ולאפשר לאפליקציה לייצא מטען ייעודי (payload) של גדר ולייבא מטען ייעודי (payload) של גדרות מתיאורי קבצים של POSIX, כפי שמתואר כאן.

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

    הצגת גרסה קודמת

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

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

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

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

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

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

    • [C-SR-13] מומלץ מאוד ששיעור הקבלה של זיופים ושל מתחזה לא יעלה על 30% לכל סוג של כלי תקיפה מסוג מצגת (PAI), כפי שנמדד על ידי פרוטוקולים לבדיקת ביומטריה של Android.

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

    • [C-SR-17] מומלץ מאוד להטמיע את ממשקי AIDL החדשים (כמו IFace.aidl ו-IFingerprint.aidl).

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

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

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

  • 7.3.13. IEEE 802.1.15.4 (UWB):

    הצגת גרסה קודמת

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

    • [C-1-2] חובה לדווח על הדגל של תכונת החומרה android.hardware.uwb.
    • [C-1-3] חייבת לתמוך בכל קבוצות ההגדרות הבאות (שילובים מוגדרים מראש של פרמטרים של FIRA UCI) שמוגדרות בהטמעה של AOSP.
      • CONFIG_ID_1: טווח STATIC STS DS-TWR של Unicode בהגדרת FiRa, מצב דחוי, טווח של 240 אלפיות השנייה.
      • CONFIG_ID_2: הגדרת FiRa של אחד לרבים, עם טווח STATIC STS DS-TWR, מצב דחוי, טווח של 200 אלפיות השנייה. תרחיש אופייני: טלפון חכם יוצר אינטראקציה עם הרבה מכשירים חכמים.
      • CONFIG_ID_3: זהה ל-CONFIG_ID_1, אבל לא מדווחים נתונים על זווית ההגעה (AoA).
      • CONFIG_ID_4: זהה ל-CONFIG_ID_1, אבל מצב האבטחה P-STS מופעל.
      • CONFIG_ID_5: זהה ל-CONFIG_ID_2, אבל מצב האבטחה P-STS מופעל.
      • CONFIG_ID_6: זהה ל-CONFIG_ID_3, אבל מצב האבטחה P-STS מופעל.
      • CONFIG_ID_7: כמו ב-CONFIG_ID_2, אבל מצב של מפתח בקרה נפרד ל-P-STS מופעל.
    • [C-1-4] חובה לאפשר למשתמש להפעיל או להשבית את מצב ההפעלה והכיבוי של רדיו UWB.
    • [C-1-5] חובה לאכוף באפליקציות שמשתמשות ברדיו UWB את ההרשאה UWB_RANGING (מתחת לקבוצת ההרשאות NEARBY_DEVICES).

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

  • 7.4.1. טלפוניה:

    הצגת גרסה קודמת

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

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

  • 7.4.2. IEEE 802.11 (Wi-Fi):

    הצגת גרסה קודמת

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

    • [C-1-4] חובה לתמוך ב-Multicast DNS (mDNS) ואסור לסנן חבילות mDNS (224.0.0.251 או ff02::fb) בכל זמן ההפעלה, כולל כשהמסך לא במצב פעיל, אלא אם צריך לשחרר או לסנן את החבילות האלה כדי להישאר בטווחי היעד הרגולטוריים הנדרשים כדי לעמוד בדרישות צריכת החשמל. להטמעות של מכשירי Android TV, גם במצב המתנה.

  • 7.4.3. Bluetooth:

    הצגת גרסה קודמת

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

    • [C-SR-2] מומלץ מאוד למדוד ולפצות על היסט Rx כדי לוודא שה-RSSI החציוני של BLE הוא -60dBm +/-10dB במרחק של 1 מטר ממכשיר עזר שמשדר ב-ADVERTISE_TX_POWER_HIGH, שבו המכשירים מכוונים כך שהם נמצאים ב 'מישורים מקבילים' עם מסכים שפונים לאותו כיוון.
    • [C-SR-3] מומלץ מאוד למדוד ולפצות על היסט Tx כדי לוודא שה-RSSI החציוני של BLE הוא -60dBm +/-10dB בסריקה ממכשיר עזר שממוקם במרחק של 1 מטר ומעבירים שידור ב-ADVERTISE_TX_POWER_HIGH, שם המכשירים מכוונים באופן כזה שהם ב'מישורים מקבילים' עם מסכים הפונים לאותו כיוון.

    • [C-10-3] חובה למדוד ולפצות על היסט Rx כדי לוודא שה-RSSI החציוני של BLE הוא -55dBm +/-10dB במרחק של 1 מטר ממכשיר עזר שמשדר ב-ADVERTISE_TX_POWER_HIGH.
    • [C-10-4] חובה למדוד ולפצות על היסט Tx כדי לוודא שה-RSSI החציוני של BLE הוא -55dBm +/-10dB בסריקה ממכשיר עזר שנמצא במרחק של 1 מטר ומשדר ב-ADVERTISE_TX_POWER_HIGH.

    אם הטמעות המכשיר תומכות בגרסה 5.0 של Bluetooth:

    • [C-SR-4] מומלץ מאוד לספק תמיכה לגבי:
    • LE 2M PHY
    • LE Codec PHY
    • תוסף LE Advertising
    • פרסום תקופתי
    • לפחות 10 קבוצות מודעות
    • לפחות 8 חיבורי LE בו-זמנית. כל חיבור יכול להיות בכל אחד מהתפקידים בטופולוגיה של החיבור.
    • הפרטיות של שכבת הקישור של LE
    • גודל של 'רשימה לפתרון' של 8 ערכים לפחות

  • 7.4.9. UWB:

    הצגת גרסה קודמת

    • [C-1-7] חייבים לוודא שהחציון של מדידות המרחק של 1 מ' ממכשיר העזר הוא בטווח של [0.75 מ', 1.25 מטר], ומרחק אמת הקרקע נמדד מהקצה העליון של ה-DUT. כאשר החציון מופנה כלפי מעלה ומוטה בזווית של 45 מעלות.

  • 7.5.1. מצלמה אחורית:

    הצגת גרסה קודמת

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

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

  • 7.5.2. מצלמה קדמית:

    הצגת גרסה קודמת

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

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

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

    הצגת גרסה קודמת

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

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

    הצגת גרסה קודמת

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

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

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

    הצגת גרסה קודמת

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

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

  • 7.10. משוב פיזי:

    הצגת גרסה קודמת

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

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

    • [7.10/C] חייבת להחזיר FALSE עבור Vibrator.hasVibrator().

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

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

    דרישות ספציפיות למכשיר מופיעות בסעיף 2.2.1.

9. התאימות של דגם האבטחה

  • 9.1. הרשאות:

    הצגת גרסה קודמת

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

    • [C-0-4] ממשק משתמש אחד חייב להיות הטמעה אחת בלבד של שני ממשקי המשתמש.

    אם המכשיר מטמיע מראש חבילות שמכילות את אחד מהתפקידים 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 Content הקלטת תוכן' '9.8.6 נתונים ברמת מערכת ההפעלה ונתונים ברקע ו-9.8.15 הטמעות API בארגז חול'.

    • [C-4-2] אסור להשתמש בהרשאה android.permission.INTERNET. הדרישה הזו מחמירה יותר מהמומלץ מאוד שמפורטת בסעיף 9.8.6.
    • [C-4-3] אסור לקשר לאפליקציות אחרות, מלבד לאפליקציות המערכת הבאות: Bluetooth, 'אנשי קשר', מדיה, טלפוניה, SystemUI ורכיבים שמספקים ממשקי API לאינטרנט. זו הנחיה מחמירה יותר מהמומלץ מאוד שמפורטת בסעיף 9.8.6.

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

    • [C-5-1] אסור לתת את ACCESS_FINE_LOCATION כברירת המחדל לאפליקציה הזו.

  • 9.5. תמיכה במשתמשים מרובים:

    הצגת גרסה קודמת

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

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

    • [C-4-1] חובה לאפשר לאפליקציות של המשתמש הראשי במכשיר לטפל באובייקטים הבאים, שמקורם בפרופיל הנוסף:

      • Intent.ACTION_VIEW
      • Intent.ACTION_SENDTO
      • Intent.ACTION_SEND
      • Intent.ACTION_EDIT
      • Intent.ACTION_INSERT
      • Intent.ACTION_INSERT_OR_EDIT
      • Intent.ACTION_SEND_MULTIPLE
      • Intent.ACTION_PICK
      • Intent.ACTION_GET_CONTENT
      • MediaStore.ACTION_IMAGE_CAPTURE
      • MediaStore.ACTION_VIDEO_CAPTURE

    • [C-4-2] פרופיל המשתמש הנוסף הזה חייב לרשת את כל הגבלות מדיניות המכשירים ואת כל ההגבלות שנבחרו על משתמשים שאינם משתמשים(רשימה למטה) שחלות על המשתמש הראשי במכשיר.

    • [C-4-3] חובה לאפשר כתיבת אנשי קשר מהפרופיל הנוסף הזה רק באמצעות הכוונות הבאות:

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

    • [C-4-14] חייבים להיות הרשאות נפרדות וניהול אחסון של אפליקציות שפועלות בפרופיל הנוסף הזה

    • [C-4-5] חובה לאפשר רק לאפליקציות בפרופיל הנוסף שיש להן פעילות של מרכז האפליקציות לגשת לאנשי קשר שכבר נגישים לפרופיל המשתמש של ההורה.

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

    הצגת גרסה קודמת

    טכנולוגיית 'בטיחות זיכרון' היא טכנולוגיה שמפחיתה לפחות את סוגי הבאגים הבאים עם סבירות גבוהה (יותר מ-90%) באפליקציות שמשתמשות באפשרות המניפסט android:memtagMode:

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

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

    • [C-SR-15] מומלץ מאוד להגדיר את ro.arm64.memtag.bootctl_supported.

    אם הטמעות המכשירים מגדירות את מאפיין המערכת ro.arm64.memtag.bootctl_supported כ-True, הן:

    • [C-3-1] צריך לאפשר למאפיין המערכת arm64.memtag.bootctl לקבל רשימה מופרדת בפסיקים של הערכים הבאים, עם ההשפעה הרצויה של ההפעלה מחדש הבאה:

      • memtag: מופעלת טכנולוגיה לשמירה על בטיחות הזיכרון כפי שהוגדרה למעלה
      • memtag-once: טכנולוגיית בטיחות זיכרון כפי שהוגדרה למעלה מופעלת באופן זמני ומושבתת באופן אוטומטי לאחר ההפעלה מחדש הבאה
      • memtag-off: טכנולוגיה לשמירה על בטיחות הזיכרון כפי שהוגדרה למעלה מושבתת

    • [C-3-2] חייבים לאפשר למשתמש במעטפת להגדיר את arm64.memtag.bootctl.

    • [C-3-3] חובה לאפשר לכל תהליך לקרוא את arm64.memtag.bootctl.

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

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

    • [C-SR-17] מומלץ מאוד להציג הגדרה בתפריט 'הגדרות אבטחה' שמאפשרת למשתמש להפעיל את memtag.

  • 9.8.2. הקלטה:

    הצגת גרסה קודמת

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

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

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

    • [C-0-4] אסור לספק למשתמשים אפשרות להשבית בקשות עתידיות של המשתמש כך שהוא יצלם את המסך, אלא אם הסשן מתחיל על ידי אפליקציית מערכת שהמשתמש אישר ל-associate() עם פרופיל המכשיר android.app.role.COMPANION_DEVICE_APP_STREAMING או android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING.

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

    הצגת גרסה קודמת

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

    • כל מסך או נתונים אחרים שנשלחים למערכת באמצעות AugmentedAutofillService.
    • כל מסך או נתונים אחרים שאפשר לגשת אליהם דרך API של Content Capture.
    • כל מסך או נתונים אחרים שניתן לגשת אליהם דרך API של FieldClassificationService
    • כל נתוני האפליקציה שמועברים למערכת דרך API של AppSearchManager ונגישים דרך AppSearchGlobalManager.query.

    • כל אירוע אחר שהאפליקציה מספקת למערכת דרך ה-API Content Capture או ה-API של AppSearchManager, של Android וממשק API קנייני עם יכולות דומות.

    • נתוני אודיו שהושגו כתוצאה מהשימוש ב-SpeechRecognizer#onDeviceSpeechRecognizer() על ידי ההטמעה של מזהה הדיבור.
    • נתוני אודיו שמתקבלים ברקע (באופן רציף) דרך AudioRecord, SoundTrigger או ממשקי API אחרים של אודיו, ולא מובילים לאינדיקטור גלוי למשתמש
    • נתוני המצלמה שמתקבלים ברקע (באופן רציף) דרך CameraManager או באמצעות ממשקי API אחרים של Camera, ואינם יוצרים אינדיקטור גלוי למשתמש

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

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

    • [C-1-5] אסור לשתף נתונים כאלה עם רכיבי מערכת הפעלה אחרים שלא עומדים בדרישות שמפורטות בסעיף הנוכחי (9.8.6 Content Recording ברמת מערכת ההפעלה ונתוני אווירה), אלא אם מתקבלת הסכמה מפורשת מהמשתמש בכל פעם שהנתונים האלה משותפים. אלא אם פונקציונליות כזו מיועדת ל-Android SDK API (AmbientContext, HotwordDetectionService).

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

    • [C-SR-3] מומלץ מאוד להטמיע אותן באמצעות Android SDK API או באמצעות מאגר קוד פתוח דומה בבעלות ה-OEM; ו / או לבצע הטמעה בארגז חול (ראו 9.8.15 הטמעות API ב-Sandbox).

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

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

    הצגת גרסה קודמת

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

    • [C-1-4] דוחות שנוצרו באמצעות BUGREPORT_MODE_TELEPHONY חייבים להכיל לפחות את המידע הבא:
      • קובץ dump של SubscriptionManagerService

  • 9.8.14. מנהל פרטי הכניסה: הוסר

  • 9.8.15. Sandboxed API הטמעות: קטע חדש

    הצגת גרסה קודמת

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

    כל הטמעה של API ב-Sandbox:

    • [C-0-1] אסור לבקש הרשאת INTERNET.
    • [C-0-2] חובה לגשת לאינטרנט רק דרך ממשקי API מובנים שמגובים על ידי הטמעות של קוד פתוח שזמינות לציבור באמצעות מנגנונים לשמירה על הפרטיות, או באופן עקיף דרך ממשקי API של Android SDK. המנגנון לשמירה על הפרטיות מוגדר כ "אלה שמאפשרים ניתוח מצטבר בלבד ומניעת התאמה של אירועים שנרשמו ביומן או תוצאות נגזרות למשתמשים ספציפיים", כדי למנוע ספק של הנתונים לפי משתמש (למשל, הטמעת באמצעות טכנולוגיה של פרטיות דיפרנציאלית כמו RAPPOR).
    • [C-0-3] חובה לשמור את השירותים בנפרד מרכיבי מערכת אחרים (למשל, לא לקשר את השירות או מזהים של תהליכי שיתוף), למעט במקרים הבאים:
      • טלפוניה, אנשי קשר, ממשק משתמש של המערכת ומדיה
    • [C-0-4] אסור לאפשר למשתמשים להחליף את השירותים באפליקציה או בשירות שניתנים להתקנה
    • [C-0-5] חובה לאפשר רק לשירותים שהותקנו מראש לתעד נתונים כאלה. אלא אם יכולת ההחלפה מובנית ב-AOSP (למשל, באפליקציות של Digital Assistant).
    • [C-0-6] אסור לאפשר לאפליקציות לאסוף נתונים כאלה, מלבד מנגנון השירותים המותקנים מראש. אלא אם יכולת צילום כזו מוטמעת באמצעות Android SDK API.
    • [C-0-7] חובה לספק למשתמשים מספיק כסף כדי להשבית את השירותים.
    • [C-0-8] אסור להשמיט את יכולת המשתמשים לנהל הרשאות Android שבבעלות השירותים, ולפעול בהתאם למודל ההרשאות של Android כפי שמתואר בסעיף 9.1. הרשאה.

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

    הצגת גרסה קודמת

    בנוסף לדרישות שמפורטות בסעיף 9.8.2 הקלטה, נתונים ברמת מערכת ההפעלה 9.8.6 והטמעות API ב-9.8.15, הטמעות שמשתמשות בנתוני אודיו שמתקבלים ברקע (רציף) דרך AudioRecord, SoundTrigger או נתוני מצלמה אחרים, או נתוני מצלמה, שהושגו ברקע (רציף) באמצעות CameraManager או ממשקי API אחרים של המצלמה:

    • [C-0-1] חובה לאכוף אינדיקטור מתאים (מצלמה ו/או מיקרופון בהתאם לסעיף 9.8.2 הקלטה), אלא אם:
    • [C-SR-1] מומלץ מאוד לדרוש הסכמה מהמשתמש לכל פונקציונליות שמשתמשת בנתונים כאלה, ושהמשתמש יושבת כברירת מחדל.
    • [C-SR-2] מומלץ מאוד להחיל את אותו טיפול (כלומר, לפעול בהתאם להגבלות שמפורטות בסעיף 9.8.2 הקלטה, נתוני אווירה ו-9.8.6 ברמת מערכת ההפעלה, 9.8.15 הטמעות של ממשק API בארגז חול (9.8.16) ונתוני מצלמה ואודיו רציפים) על נתוני המצלמה שמגיעים ממכשיר לביש מרחוק.

    אם נתוני המצלמה מגיעים ממכשיר לביש מרחוק וניגשים אליהם בצורה לא מוצפנת מחוץ ל-Android OS, בהטמעה בארגז חול (sandbox) או בפונקציונליות בארגז חול (Sandbox) שפותחה על ידי WearableSensingManager:

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

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

    • [C-2-1] חייבים לוודא שהטמעה כזו מסופקת על ידי חבילה עם התפקיד android.app.role.ASSISTANT.
    • [C-2-2] חובה לוודא שהטמעה כזו תשתמש בממשקי API של Android HotwordDetectionService ו/או VisualQueryDetectionService.

  • 9.8.17. טלמטריה: קטע חדש

    הצגת גרסה קודמת

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

    בנוסף, ב-StatManager אפשר לאסוף ממכשירים עם מנגנון לשמירה על הפרטיות נתונים שמסווגים כרגישים לפרטיות. באופן ספציפי, ה-API של StatsManager::query מאפשר להריץ שאילתות על קטגוריות מדדים מוגבלות המוגדרות ב-StatLog.

    כל הטמעה של שאילתה ואיסוף מדדים מוגבלים מ-StatsManager:

    • [C-0-1] האפליקציה או ההטמעה חייבים להיות היחידים במכשיר ולכלול את ההרשאה READ_RESTRICTED_STATS.
    • [C-0-2] חובה לשלוח את נתוני הטלמטריה ואת היומן של המכשיר רק באמצעות מנגנון לשמירה על הפרטיות. המנגנון לשמירה על הפרטיות מוגדר כ'אמצעים שמאפשרים רק ניתוח נתונים מצטבר ומונעים התאמה של אירועים מתועדים או תוצאות נגזרות למשתמשים ספציפיים', כדי למנוע ספק של הנתונים לכל משתמש (למשל, הטמעת באמצעות טכנולוגיה של פרטיות דיפרנציאלית כמו RAPPOR).
    • [C-0-3] אסור לשייך את הנתונים האלה לזהות משתמש כלשהי (למשל חשבון) במכשיר.
    • [C-0-4] אסור לשתף את הנתונים האלה עם רכיבים אחרים של מערכת הפעלה שלא עומדים בדרישות שמפורטות בסעיף הנוכחי (9.8.17 טלמטריה לשמירה על הפרטיות).
    • [C-0-5] חובה לאפשר למשתמשים להפעיל או להשבית את האיסוף, השימוש והשיתוף של נתוני טלמטריה לשמירה על הפרטיות.
    • [C-0-6] חובה לאפשר למשתמשים למחוק באופן מלא נתונים שההטמעה אוספת אם הם מאוחסנים במכשיר בצורה כלשהי. אם המשתמש בחר למחוק את הנתונים, הוא חייב להסיר את כל הנתונים שמאוחסנים כרגע במכשיר.
    • [C-0-7] חובה לחשוף את ההטמעה הבסיסית של פרוטוקול לשמירה על הפרטיות במאגר בקוד פתוח.
    • [C-0-8 ]חובה לאכוף את המדיניות בנושא תעבורת נתונים יוצאת (egress) בקטע הזה כדי להגביל את איסוף הנתונים בקטגוריות מדדים מוגבלות, כפי שהן מופיעות ב-StatLog.

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

    הצגת גרסה קודמת

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

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

    • [C-0-3 C-2-1] תומך באימות קריפטוגרפי של תוכן קובץ מול מפתח מהימן בלי לקרוא את הקובץ כולו.

    • [C-0-4 C-2-2] אסור שבקשות קריאה בקובץ מוגן יכשלו כשתוכן הקריאה לא מאומת מול מפתח מהימן לא מאומת לפי [C-2-1] שלמעלה.

    • [C-2-4] חובה להחזיר סיכום ביקורת (checksum) של קובץ ב-O(1) לקבצים שהופעלו.

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

    הצגת גרסה קודמת

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

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

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

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

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

    הצגת גרסה קודמת

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

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

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

    • [C-SR-6] מומלץ מאוד להשתמש בקוד אימות שמכיל לפחות 6 ספרות, או שווה ערך לאנטרופיה של 20 ביט.
    • [C-SR-7] מומלץ מאוד לא להזין קוד אימות באורך של פחות מ-6 ספרות כדי למנוע חשיפה של אורך קוד האימות.

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

    [C-7-8] חובה לבקש מהמשתמש אישור להשתמש באחת משיטות האימות הראשי המומלצות (למשל: קוד אימות, קו ביטול נעילה, סיסמה) לפחות פעם ב-72 שעות או פחות, אלא אם יש חשש בנוגע לבטיחות המשתמש (למשל, הסחות דעת של הנהג).

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

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

  • 9.17. Virtualization Framework של Android:

    הצגת גרסה קודמת

    אם במכשיר מותקנת תמיכה בממשקי ה-API של Android Virtualization Framework (android.system.virtualmachine.*), המארח של Android:

    • [C-1-1] חייבת לתמוך בכל ממשקי ה-API שהוגדרו על ידי חבילת android.system.virtualmachine.
    • [C-1-2] אסור לשנות את ה-SELinux של Android ואת מודל ההרשאות לניהול מכונות וירטואליות מוגנות (pVM).

    • [C-1-3] אסור לשנות, להשמיט או להחליף את כללי אף פעם שלא קיימים במערכת או בפלטפורמה שצוינו בפרויקט קוד פתוח של Android (AOSP)

    • [C-1-4] חייבים לאפשר רק קוד חתום של פלטפורמה ואפליקציות מוגבלותאסור לאפשר קוד לא מהימן (למשל, אפליקציות של צד שלישי) כדי ליצור ולהפעיל pVM Protected Virtual Machine . הערה: האפשרות הזו עשויה להשתנות בגרסאות עתידיות של Android.

    • [C-1-5] אסור לאפשר ל-Protected Virtual Machine pVM להפעיל קוד שלא הוא חלק מתמונת היצרן או העדכונים שלו. אסור להפעיל במכונה וירטואלית מוגנת כל מה שלא נכלל ב'הפעלה מאומתת של Android' (למשל, קבצים שהורדו מהאינטרנט או מהתקנה ממקור לא ידוע).

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

    אם במכשיר מוצעת תמיכה בממשקי API של Android Virtualization Framework (android.system.virtualmachine.*), כל מופע של Protected Virtual Machine pVM :

    • [C-2-1] חייבת להיות אפשרות להריץ את כל מערכות ההפעלה הזמינות בווירטואליזציה APEX ב-Protected Virtual Machine pVM .
    • [C-2-2] אסור לאפשר ל-Protected Virtual Machine pVM להריץ מערכת הפעלה שלא חתומה על ידי הכלי להטמעת מכשירים או ספק מערכת ההפעלה.
    • [C-2-3] אסור לאפשר ל-Protected Virtual Machine pVM להפעיל נתונים כקוד (למשל SELinux אף פעם לא מאפשר execmem).

    • [C-2-4] אסור לשנות, להשמיט או להחליף את כללי אף פעם שקיימים במערכת/sepolicy/microdroid שכלולים בפרויקט הקוד הפתוח של Android (AOSP).

    • [C-2-5] חובה להטמיע Protected Virtual Machine pVM מנגנוני הגנה לעומק (למשל, SELinux למכונות pVM) גם במערכות הפעלה שאינן Microdroid.
    • [C-2-6] חייבים לוודא ש המכונה הווירטואלית תיכשל הקושחה מסרבת להפעיל את המכשיר אם אי אפשר לאמת את התמונות הראשוניות שאי אפשר לאמת את המכונה הווירטואלית. האימות חייב להתבצע בתוך המכונה הווירטואלית.
    • [C-2-7] חייבים לוודא ש ה-pVM תיכשל הקושחה מסרבת להפעיל את המכשיר אם התקינות של המכונה נפגעה.

    אם במכשיר מותקנת תמיכה בממשקי ה-API של Android Virtualization Framework (android.system.virtualmachine.*), אז hypervisor:

    • [C-3-1] חייבים לוודא שדפי זיכרון שנמצאים בבעלות בלעדית של מכונה וירטואלית (pVM או VM המארח) נגישים רק למכונה הווירטואלית עצמה או ל-hypervisor, ולא למכונות וירטואליות אחרות – מוגנות או לא מוגנות. אסור לתת ל-pVM גישה לדף ששייך לישות אחרת (כלומר pVM או hypervisor אחרים), אלא אם בעל הדף שיתף זאת באופן מפורש. זה כולל את המכונה הווירטואלית של המארח. זה רלוונטי גם לגישה למעבד (CPU) וגם ל-DMA.
    • [C-3-2] חובה לאפס את נתוני הדף אחרי שנעשה בו שימוש ב-pVM ולפני שהוא מוחזר למארח (למשל, ה-pVM מושמד).
    • [C-3-3SR-1] מומלץ מאוד לוודא שחייבים לוודא שהקושחה של ה-pVM נטענת ומתבצעת לפני כל קוד ב-pVM.
    • [C-3-4] חייבים לוודא שכל מכונה וירטואלית מפיקה סוד לכל מכונה וירטואלית, אשר {Boot Certificate Certificate (BCC) ובמזהה המכשיר המורכב (CDI) שסופקו למכונת pVM יכול להיווצר רק על ידי מכונת ה-VM הספציפית הזו ושינויים במקרה של איפוס להגדרות המקוריות ו-OTA.

    אם במכשיר מוטמע תמיכה בממשקי ה-API של Android Virtualization Framework, אז בכל האזורים:

    • [C-4-1] אסור לספק פונקציונליות ל-pVM שמאפשרת לעקוף את מודל האבטחה של Android.

    אם המכשיר מוטמע תמיכה בממשקי ה-API של Android Virtualization Framework:

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

    אם במכשיר מותקנת תמיכה בממשקי ה-API של Android Virtualization Framework, אז עבור ניהול מפתחות:

    • [C-6-1] שרשרת DICE חייבת להיות ברמה הבסיסית שהמשתמשים לא יכולים לשנות, גם במכשירים שלא נעולים. (כדי לוודא שלא ניתן יהיה לזייף אותו).

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

חזרה למעלה