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

Android 15

‫2 במאי 2025

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

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

    הצגת הגרסה

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

    מכשיר והצהרות RTL (מילישניות) MAD (מילישניות) נתיבי לולאה חוזרת
    מוחזקת ביד 250 30 רמקול/מיקרופון, אנלוגי 3.5 מ"מ (אם נתמך), USB (אם נתמך)
    ‫>= MPC_T (14) MPC_T (13) 80 15 נתיב אחד לפחות
    FEATURE_AUDIO_LOW_LATENCY 50 10 נתיב אחד לפחות
    FEATURE_AUDIO_PRO 25 5 נתיב אחד לפחות
    FEATURE_AUDIO_PRO 20 5 אנלוגי (אם נתמך)
    FEATURE_AUDIO_PRO 25 5 USB (אם לא נתמכת אנלוגיה)

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

    מכשיר והצהרות TTL (מילישניות)
    מוחזקת ביד 250
    ‫>= MPC_T (14) MPC_T (13) 80
    MPC_S (13) MPC_S (12) 100
    FEATURE_AUDIO_PRO 80

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

  • 9.9.3. שיטות הצפנה:

    הצגת הגרסה

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

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

      • המשתמש מבטל את נעילת המכשיר באמצעות שיטת אימות ראשונית (כמו סיסמה, קו ביטול נעילה או קוד אימות).
      • ההודעה ACTION_USER_UNLOCKED משודרת.

‫2 בדצמבר 2024

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

  • 2.2.7.1. חומרה:

    הצגת הגרסה

    • ‫[5.1/H-1-2] חובה לתמוך ב-6 מקרים של מפגשי פענוח וידאו בחומרה (SDR) של 8 ביט (AVC,‏ HEVC,‏ VP9,‏ AV1 או גרסה מאוחרת יותר) בכל שילוב של קודקים שפועלים בו-זמנית עם 3 מפגשים ברזולוציה של 1080p בקצב של 30 פריימים לשנייה ו-3 מפגשים ברזולוציה של 4K בקצב של 30 פריימים לשנייה. בכל הסשנים, לא יכולות להיות יותר מ-1 מסגרות שנשמטו בכל שנייה. נדרשים קודקים של AV1 רק כדי לתמוך ברזולוציית 1080p, אבל עדיין נדרשת תמיכה ב-6 מופעים ברזולוציה של 1080p בקצב פריימים של 30fps.

    • ‫[5.1/H-1-4] חובה לתמוך ב-6 מקרים של מפגשי קידוד וידאו בחומרה (SDR) של 8 ביט (AVC,‏ HEVC,‏ VP9,‏ AV1 או גרסה מאוחרת יותר) בכל שילוב של קודקים שפועלים בו-זמנית עם 4 מפגשים ברזולוציה של 1080p ב-30fps ו-2 מפגשים ברזולוציה של 4K ב-30fps. בכל הסשנים, לא יכולות להיות יותר מ-1 מסגרות שנשמטו בכל שנייה. נדרשת תמיכה ברזולוציה של 1080p בלבד עבור קודקים של AV1, אבל עדיין נדרשת תמיכה ב-6 מופעים ברזולוציה של 1080p בקצב של 30fps.

    • ‫[5.1/H-1-6] המכשיר חייב לתמוך ב-6 מופעים של מפענח וידאו (SDR) בחומרה ב-8 ביט ובסשנים של מקודד וידאו בחומרה (AVC,‏ HEVC,‏ VP9,‏ AV1 או גרסאות מאוחרות יותר) בכל שילוב של קודקים שפועלים בו-זמנית עם 3 סשנים ברזולוציה של 4K@30fps , מתוכם לכל היותר 2 סשנים של מקודד ו-3 סשנים ברזולוציה של 1080p. בכל הסשנים, לא יכולות להיות יותר מ-1 מסגרות שנשמטו בכל שנייה. נדרשת תמיכה ברזולוציה של 1080p בלבד עבור קודקים של AV1, אבל עדיין נדרשת תמיכה ב-6 מופעים ברזולוציה של 1080p בקצב של 30fps.

    • ‫[5.1/H-1-19] המכשיר חייב לתמוך ב-3 מקרים של מפענח וידאו (HDR) בחומרה של 10 ביט ובסשנים של מקודד וידאו בחומרה (AVC,‏ HEVC,‏ VP9,‏ AV1 או גרסה מאוחרת יותר) בכל שילוב של קודקים שפועלים בו-זמנית ברזולוציה של ‎4K@30fps מתוכם לכל היותר סשן אחד של מקודד, שאפשר להגדיר בפורמט קלט RGBA_1010102 דרך משטח GL. בכל הסשנים, לא יכול להיות יותר מפריים אחד שהושמט בכל שנייה. אם הקידוד מתבצע מפני השטח של GL, לא נדרש קידוד של מטא-נתונים של HDR על ידי המקודד. נדרשים רק סשנים של קודק AV1 כדי לתמוך ברזולוציית 1080p, גם אם הדרישה היא ל-4K.

    • ‫[5.1/H-1-9] חובה לתמוך ב-2 מקרים של מפגשי פענוח מאובטחים של וידאו בחומרה (AVC, ‏ HEVC, ‏ VP9, ‏ AV1 או גרסה מאוחרת יותר) בכל שילוב של קודקים שפועלים בו-זמנית ברזולוציה של 1080p בקצב של 30 פריימים לשנייה, גם עבור תוכן באיכות 8 ביט (SDR) וגם עבור תוכן באיכות 10 ביט (HDR). בכל הסשנים, לא יכול להיות יותר מפרים אחד שהושמט בכל שנייה.

    • ‫[5.1/H-1-10] המכשיר חייב לתמוך ב-3 מופעים של מפוענח וידאו לא מאובטח בחומרה במקביל למופע אחד של מפוענח וידאו מאובטח בחומרה (4 מופעים בסך הכול) (AVC, ‏ HEVC, ‏ VP9, ‏ AV1 או גרסאות מאוחרות יותר) בכל שילוב של קודקים שפועלים במקביל ל-3 סשנים ברזולוציית 4K ב-30fps כולל סשן אחד של מפוענח מאובטח וסשן אחד לא מאובטח ברזולוציית 1080p ב-30fps, כאשר לכל היותר 2 סשנים יכולים להיות ב-HDR של 10 ביט. בכל הסשנים, לא יכולות להיות יותר מ-1 מסגרות שנשמטו בכל שנייה. נדרשת תמיכה בקידוד AV1 רק ברזולוציית 1080p, גם אם הדרישה היא 4K.

  • 2.5.1. חומרה:

    הצגת הגרסה

    • ‫[7.2.3/A-0-1] חובה לספק את הפונקציה 'דף הבית' ואפשר לספק את הפונקציות 'הקודם' ו'אחרונים'.

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

  • 7.4.2. ‫IEEE 802.11 (Wi-Fi):

    הצגת הגרסה

    • ‫[C-1-4] המכשיר חייב לתמוך ב-mDNS ואסור לו לסנן חבילות mDNS ‏(224.0.0.251 או ff02::fb) בכל זמן פעולה, כולל כשהמסך לא במצב פעיל, אלא אם נעילת ה-multicast לא מוחזקת והחבילות מסוננות על ידי APF. החבילות לא נדרשות כדי לספק פעולות mDNS שמוגדרות כרגע על ידי אפליקציות דרך ממשקי ה-API של NsdManager. עם זאת, המכשיר עשוי לסנן חבילות mDNS אם הסינון נדרש כדי לעמוד בטווחים של צריכת החשמל שנדרשים לפי הדרישות הרגולטוריות שחלות על שוק היעד.

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

‫3 בספטמבר 2024

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

  • 2.2.1. חומרה:

    הצגת הגרסה

    • ‫[7.4.3/H] צריך לכלול תמיכה ב-Bluetooth וב-Bluetooth LE.

    Start new requirements for 15

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

    • ‫[7.4.3/H-SR-1] מומלץ מאוד לתמוך בהרחבת אורך מנות הנתונים של Bluetooth LE.

    דרישות חדשות

    הצגת הגרסה

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

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

    הצגת הגרסה

    אם במכשירים ניידים שמוצהרים android.hardware.audio.output ו-android.hardware.microphone, הם: עומדים בדרישות ה-RTL וה-TTL שמפורטות בקטע 5.6.

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

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

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

    הצגת הגרסה

    הטמעות של מכשירים חייבות להצהיר על תמיכה ב-android.software.credentials וגם:

    • ‫[9/H-0-2] חובה לכבד את android.settings.CREDENTIAL_PROVIDERהכוונה לאפשר בחירה של ספק מועדף עבור מרכז האישורים. הספק הזה יופעל למילוי אוטומטי, והוא גם יהיה המיקום שמוגדר כברירת מחדל לשמירת פרטי כניסה חדשים שמוזנים דרך Credential Manager.

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

    דרישות חדשות

    הצגת הגרסה

    • ‫[9.11/H-0-5] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה של האימות מוגן על ידי חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. מפתחות החתימה של האימות צריכים להיות משותפים למספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות בתור מזהי מכשירים קבועים. דרך אחת לעמוד בדרישה הזו היא לשתף את אותו מפתח אישור, אלא אם מיוצרות לפחות 100,000 יחידות של מק"ט מסוים. אם מיוצרים יותר מ-100,000 יחידות של מק"ט מסוים, אפשר להשתמש במפתח אחר לכל 100,000 יחידות.

    הצגת הגרסה

    הגדרות מוגבלות

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

    • האפליקציה מותקנת אחרי שהיא הורדה דרך אפליקציה (לדוגמה, אפליקציית הודעות או דפדפן) שאינה אפליקציית 'חנות אפליקציות' שמזוהה על ידי PackageManager בתור PACKAGE_DOWNLOADED_FILE.
    • האפליקציה מותקנת מקובץ מקומי (לדוגמה, האפליקציה הועברה למכשיר בשיטת Sideloading) ומזוהה על ידי PackageManager כ-PACKAGE_SOURCE_LOCAL_FILE.

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

    • התראות ותזכורות: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
    • גישה לכל הקבצים: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
    • הצגה מעל אפליקציות אחרות: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
    • התקנת אפליקציות ממקורות לא מוכרים: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
    • ניהול מדיה: AppOpsManager.OPSTR_MANAGE_MEDIA
    • שינוי הגדרות המערכת: AppOpsManager.OPSTR_WRITE_SETTINGS
    • תמונה בתוך תמונה: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
    • הפעלת המסך: AppOpsManager.OPSTR_TURN_SCREEN_ON
    • התראות במסך מלא: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
    • שליטה ב-Wi-Fi: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
    • נגישות: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
    • מאזין להתראות: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
    • גישה לנתוני השימוש: AppOpsManager.OPSTR_GET_USAGE_STATS
    • אדמין של המכשיר: Manifest.permission.BIND_DEVICE_ADMIN
    • נא לא להפריע: Manifest.permission.MANAGE_NOTIFICATIONS

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

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

    • ‫[9.8/H-0-1] חובה להטמיע הגדרות מוגבלות כמו שמתואר למעלה עבור:

      • הרשאות מיוחדות
        • נגישות (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
        • מאזין להתראות (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
        • אפליקציות לניהול מכשירים (Manifest.permission.BIND_DEVICE_ADMIN)
        • הצגה מעל אפליקציות אחרות (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
        • גישה לשימוש (AppOpsManager.OPSTR_GET_USAGE_STATS)
      • תפקידים (אפליקציות ברירת מחדל)
        • ‫Dialer (RoleManager.ROLE_DIALER)
        • SMS (RoleManager.ROLE_SMS)
      • הרשאות בזמן ריצה
        • זמן הריצה של ה-SMS‏ (Manifest.permission_group.SMS)

    • ‫[9.8/H-0-2] חובה להפעיל את ההגדרה 'הגדרות מוגבלות' כברירת מחדל, ומומלץ מאוד לא לאפשר למשתמשים להשבית את ההגדרה 'הגדרות מוגבלות' לכל האפליקציות.

    • ‫[9.8/H-0-3] חובה לוודא שמתקבל אישור מהמשתמש לכל אפליקציה שחלה עליה מדיניות לפני שניתן להעניק הרשאות כלשהן שמוחלות על האפליקציה.

    • ‫[9.8/H-0-4] חובה לאפשר רק אישור משתמש כדי להפעיל הגדרות מוגבלות שניתן להשיג מדף פרטי האפליקציה של האפליקציה הרלוונטית, באמצעות API של EnhancedConfirmationManager.

    • ‫[9.8/H-0-5] מומלץ מאוד לשלב את EnhancedConfirmationManager ולקרוא לו לכל ההרשאות המיוחדות, כדי לקבוע באופן דינמי אם מדובר בהגדרה מוגבלת.

      • התראות ותזכורות: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
      • גישה לכל הקבצים: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
      • הצגה מעל אפליקציות אחרות: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
      • התקנת אפליקציות ממקורות לא מוכרים: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
      • ניהול מדיה: AppOpsManager.OPSTR_MANAGE_MEDIA
      • שינוי הגדרות המערכת: AppOpsManager.OPSTR_WRITE_SETTINGS
      • תמונה בתוך תמונה: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
      • הפעלת המסך: AppOpsManager.OPSTR_TURN_SCREEN_ON
      • התראות במסך מלא: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
      • שליטה ב-Wi-Fi: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
      • נגישות: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
      • מאזין להתראות: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
      • גישה לנתוני השימוש: AppOpsManager.OPSTR_GET_USAGE_STATS
      • אדמין של המכשיר: Manifest.permission.BIND_DEVICE_ADMIN
      • נא לא להפריע: Manifest.permission.MANAGE_NOTIFICATIONS

    דרישות חדשות

    הצגת הגרסה

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

    • ‫[9.10/H-1-1] חובה לאמת את כל המחיצות לקריאה בלבד שמועלות במהלך רצף האתחול של Android, וסיכום ה-VBMeta חייב לכלול בחישוב שלו את כל המחיצות המאומתות האלה.

    דרישות חדשות

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

    הצגת הגרסה

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

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

  • 2.2.7.1. מדיה:

    הצגת הגרסה

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

    הצגת הגרסה

    • ‫[5.1/H-1-2] חובה לתמוך ב-6 מופעים של מפוענח וידאו (SDR) בחומרה של 8 ביט (AVC,‏ HEVC,‏ VP9,‏ AV1 או גרסה מאוחרת יותר) בכל שילוב של קודקים שפועלים בו-זמנית עם 3 סשנים ברזולוציה של 1080p ב-30fps ו-3 סשנים ברזולוציה של 4k ב-30fps, אלא אם מדובר ב-AV1. בכל הסשנים, לא יכולות להיות יותר מ-1 מסגרות שנשמטו בכל שנייה. נדרשת תמיכה ברזולוציית 1080p רק עבור קודקים של AV1, אבל עדיין נדרשת תמיכה ב-6 מופעים ברזולוציה של 1080p בקצב של 30 פריימים לשנייה.

    הצגת הגרסה

    • ‫[5.1/H-1-4] המכשיר חייב לתמוך ב-6 מופעים של מפעילי וידאו (SDR) של 8 ביט (AVC,‏ HEVC,‏ VP9,‏ AV1 או גרסאות מאוחרות יותר) בכל שילוב של קודקים שפועלים בו-זמנית עם 4 סשנים ברזולוציית 1080p ב-30fps ו-2 סשנים ברזולוציית 4k ב-30fps, אלא אם מדובר ב-AV1. בכל הסשנים, לא יכולות להיות יותר מ-1 מסגרות שנשמטו בכל שנייה. נדרשת תמיכה ברזולוציה של 1080p בלבד עבור קודקים של AV1, אבל עדיין נדרשת תמיכה ב-6 מופעים ברזולוציה של 1080p בקצב של 30fps.

    הצגת הגרסה

    • ‫[5.1/H-1-6] המכשיר חייב לתמוך ב-6 מופעים של מפענח וידאו (SDR) בחומרה של 8 ביט ובסשנים של מקודד וידאו בחומרה (AVC,‏ HEVC,‏ VP9,‏ AV1 או גרסה מאוחרת יותר) בכל שילוב של קודקים שפועלים בו-זמנית עם 3 סשנים ברזולוציה של ‎4K@30fps (אלא אם מדובר ב-AV1), מתוכם לכל היותר 2 הם סשנים של מקודד ו-3 סשנים ברזולוציה של 1080p. בכל הסשנים, לא יכולות להיות יותר מ-1 מסגרות שנשמטו בכל שנייה. נדרשת תמיכה ברזולוציה של 1080p בלבד עבור קודקים של AV1, אבל עדיין נדרשת תמיכה ב-6 מופעים ברזולוציה של 1080p בקצב של 30fps.

    הצגת הגרסה

    • ‫[5.1/H-1-19] המכשיר חייב לתמוך ב-3 מופעים של מפענח וידאו (HDR) בחומרה באיכות 10 ביט ובסשנים של מקודד וידאו בחומרה (AVC,‏ HEVC,‏ VP9,‏ AV1 או גרסה מתקדמת יותר) בכל שילוב של קודקים שפועלים בו-זמנית ברזולוציה של ‎4K@30fps (אלא אם מדובר ב-AV1) שמתוכם לכל היותר אחד הוא סשן של מקודד, שאפשר להגדיר אותו בפורמט קלט RGBA_1010102 דרך משטח GL. בכל הסשנים, לא יכול להיות יותר מפריים אחד שהושמט בכל שנייה. אם הקידוד מתבצע מפני השטח של GL, לא נדרש קידוד של מטא-נתונים של HDR על ידי המקודד. נדרשים רק סשנים של קודק AV1 כדי לתמוך ברזולוציית 1080p, גם אם הדרישה היא ל-4K.

    הצגת הגרסה

    • ‫[5.1/H-1-9] המכשיר חייב לתמוך ב-2 מופעים של סשנים מאובטחים של מפענח וידאו בחומרה (AVC,‏ HEVC,‏ VP9,‏ AV1 או גרסאות מאוחרות יותר) בכל שילוב של קודקים שפועלים בו-זמנית ברזולוציית 4k ב-30fps (אלא אם מדובר ב-AV1) עבור תוכן SDR (8 ביט) ו-HDR (10 ביט). בכל הסשנים, לא יכולות להיות יותר מ-1 מסגרות שנשמטו בכל שנייה. נדרשת תמיכה בקידוד AV1 רק ברזולוציית 1080p, גם אם הדרישה היא 4K.

    הצגת הגרסה

    • ‫[5.1/H-1-10] המכשיר חייב לתמוך ב-3 מופעים של מפגשי פענוח וידאו בחומרה לא מאובטחת יחד עם מופע אחד של מפגש פענוח וידאו בחומרה מאובטחת (4 מופעים בסך הכול) (AVC, ‏ HEVC, ‏ VP9, ‏ AV1 או גרסאות מאוחרות יותר) בכל שילוב של קודקים שפועלים בו-זמנית עם 3 מפגשים ברזולוציית 4K ב-30fps (אלא אם מדובר ב-AV1) כולל מפגש פענוח מאובטח אחד ומפגש לא מאובטח אחד ברזולוציית 1080p ב-30fps, כאשר לכל היותר 2 מפגשים יכולים להיות ב-HDR של 10 ביט. בכל הסשנים, לא יכולות להיות יותר מ-1 מסגרות שנשמטו בכל שנייה. נדרשת תמיכה בקידוד AV1 רק ברזולוציית 1080p, גם אם הדרישה היא 4K.

    הצגת הגרסה

    • ‫[5.1/H-1-14] חובה לתמוך בפיענוח חומרה של AV1 Main 10, רמה 4.1 ובגרעיניות של סרט עם אפקט גרעיניות של סרט על גבי קומפוזיציה של מעבד גרפי.

    הצגת הגרסה

    • ‫[5.1/H-1-21] חובה לתמוך ב-FEATURE_DynamicColorAspect בכל מפענחי הווידאו בחומרה (AVC,‏ HEVC,‏ VP9,‏ AV1 או גרסאות מאוחרות יותר). הערה: המשמעות היא שאפליקציות יכולות לעדכן את היבטי הצבע של תוכן הווידאו במהלך סשן הפענוח. מפענחים שתומכים בתוכן של 10 ביט ו-8 ביט חייבים לתמוך במעבר דינמי בין תוכן של 8 ביט לתוכן של 10 ביט במצב Surface. מפענחים שתומכים בפונקציית העברה ל-HDR חייבים לתמוך במעבר דינמי בין תוכן SDR לתוכן HDR.

    דרישות חדשות

    הצגת הגרסה

    • ‫[5.1/H-1-22] חובה לתמוך בקידוד, בפענוח, בעריכה באמצעות GPU ובהצגת תוכן וידאו ביחס גובה-רוחב לאורך, ללא קשר למטא-נתונים של הסיבוב, ברזולוציה הגדולה ביותר שנתמכת במצלמה או ב-4K, הנמוכה מביניהן. הערה: זה כולל פרופילי HDR אם הקודק תומך ב-HDR. נדרש רק תמיכה ברזולוציה של 1080p בפורמט AV1. הדרישה הזו רלוונטית רק לקודקים של חומרה, ל-GPU ול-DPU.

    דרישות חדשות

    הצגת הגרסה

    • ‫[5.6/H-1-4] המכשיר חייב לתמוך במכשירי אודיו USB עם 4 ערוצים ומעלה. (האפשרות הזו משמשת בבקרים של תקליטנים להאזנה מקדימה לשירים).

    הצגת הגרסה

    • ‫[5.1/H-1-20] חובה לתמוך בתכונה Feature_HdrEditing בכל מקודדי החומרה AV1 ו-HEVC שקיימים במכשיר ברזולוציית 4K או ברזולוציה הגדולה ביותר שנתמכת במצלמה, לפי הנמוך מביניהם.

    דרישות חדשות

    הצגת הגרסה

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

  • 2.2.7.2. מצלמה:

    הצגת הגרסה

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

    הצגת הגרסה

    • ‫[7.5/H-1-1] חובה שתהיה מצלמה ראשית עם עדשה אחורית ברזולוציה של לפחות 12 מגה-פיקסל, שתומכת בצילום וידאו באיכות 4k@30fps, ‏ 1080p@60fps ו-720p@60fps. המצלמה האחורית הראשית היא המצלמה האחורית עם מזהה המצלמה הנמוך ביותר.

    הצגת הגרסה

    • ‫[7.5/H-1-18] חובה לתמוך ב-JPEG_R במצלמות האחוריות והקדמיות הראשיות.
    • ‫[7.5/H-1-19] חובה לתמוך ב-CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION בתצוגה מקדימה של 1080p HLG10 עם JPEG ביחס גובה-רוחב של 16:9 בגודל מקסימלי, ובתצוגה מקדימה של 720p HLG10 עם שילובים של JPEG ביחס גובה-רוחב של 16:9 בגודל מקסימלי בזרם של המצלמה האחורית הראשית.
    • ‫[7.5/H-1-20] חובה להגדיר כברירת מחדל את הפלט JPEG_R למצלמה האחורית הראשית ולמצלמה הקדמית הראשית באפליקציית המצלמה המקורית.

    דרישות חדשות

  • 2.2.7.3. חומרה:

    הצגת הגרסה

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

    הצגת הגרסה

    • ‫[7.1.1.3/H-2-1] חובה שצפיפות המסך תהיה לפחות 400 dpi אם רוחב המסך של המכשיר הוא פחות מ-600dp.

    הצגת הגרסה

    • ‫[7.6.1/H-2-1] חובה שיהיה זיכרון פיזי בנפח של 8 GB לפחות, עם נפח של 6.64 GB לפחות שזמין לליבת המערכת, כפי שמדווח על ידי android.app.ActivityManager.MemoryInfo.totalMem.

  • 2.2.7.4. ביצועים:

    הצגת הגרסה

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

  • 2.2.7.5. גרפיקה:

    הצגת הגרסה

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

    דרישות חדשות

  • 2.3.3. תוכנה:

    הצגת הגרסה

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

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

    הצגת הגרסה

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

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

    • ‫[3/T-0-2] חובה להצהיר על תכונת הפלטפורמה android.software.live_tv.
    • ‫[3/T-0-3] המכשיר חייב לתמוך בכל ממשקי ה-API של TIF, כך שאפשר יהיה להתקין ולהשתמש במכשיר באפליקציה שמשתמשת בממשקי ה-API האלה ובשירות third-party TIF-based inputs.

    ‫Android Television Tuner Framework ‏ (TF) מאחד את הטיפול בתוכן בשידור חי מ-Tuner עם תוכן בסטרימינג מ-IP במכשירי Android TV. ‫Turner Framework מספק API סטנדרטי ליצירת שירותי קלט שמשתמשים בטיונר של Android TV.

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

    • ‫[3/T-1-1] המכשיר חייב לתמוך בכל ממשקי ה-API של Tuner Framework, כך שאפשר יהיה להתקין ולהשתמש במכשיר באפליקציה שמשתמשת בממשקי ה-API האלה.

    דרישות חדשות

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

    הצגת הגרסה

    • ‫[9.11/T-0-4] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה של האימות מוגן על ידי חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. מפתחות החתימה של האימות צריכים להיות משותפים למספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות בתור מזהי מכשירים קבועים. דרך אחת לעמוד בדרישה הזו היא לשתף את אותו מפתח אישור, אלא אם מיוצרות לפחות 100,000 יחידות של מק"ט מסוים. אם מיוצרים יותר מ-100,000 יחידות של מק"ט מסוים, אפשר להשתמש במפתח אחר לכל 100,000 יחידות.

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

    הצגת הגרסה

    • ‫[6.1/T-0-5] שירות ה-daemon של perfetto traced חייב להיות מופעל כברירת מחדל (מאפיין המערכת persist.traced.enable).

    דרישות חדשות

  • 2.5.1. חומרה:

    הצגת הגרסה

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

    • ‫[7.1.1.1/A-1-1] חייב להיות מסך נפרד בגודל של לפחות 6 אינץ' באלכסון פיזי לכל אזור תפוס לתצוגה הראשית. צריך לתייג את זה כ-CarOccupantZoneManager.DISPLAY_TYPE_MAIN לכל אזור תפוס.
    • ‫[7.1.1.1/A-1-2] לכל מסך ראשי חייב להיות פריסת גודל מסך של לפחות ‎750 dp x 480 dp.

    דרישות חדשות

    הצגת הגרסה

    דרישות חדשות

    הצגת הגרסה

    • ‫[7.2.3/A-0-1] חובה לספק את הפונקציות 'דף הבית' ו'הקודם', ואפשר לספק את הפונקציות 'הקודם' ו 'אפליקציות אחרונות'.

    הצגת הגרסה

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

    • ‫[7.3/A-1-1] חובה להגדיר את ערך הדגל NIGHT_MODE באופן עקבי עם מצב יום/לילה בלוח הבקרה בכל המסכים, כולל המסכים במושב האחורי.

    דרישות חדשות

    הצגת הגרסה

    • ‫[7.4.3/A-SR-1] מומלץ מאוד לתמוך ב-Message Access Profile (פרופיל גישה להודעות, MAP) אם במכשיר יש אזור נהג.

    הצגת הגרסה

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

    • ‫[7.4.3/A-1-1] חובה שהמערכת תהיה עצמאית ולא תפריע לחוויית השימוש של משתמשי BT אחרים.

    דרישות חדשות

    הצגת הגרסה

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

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

    דרישות חדשות

    הצגת הגרסה

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

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

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

      • ‫xhdpi או יותר במסכים קטנים או רגילים
      • hdpi או יותר במסכים גדולים
      • ‫mdpi או יותר במסכים גדולים במיוחד

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

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

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

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

    הצגת הגרסה

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

    • ‫[7.8.2/A-1-1] חייב להיות מכשיר פלט אודיו לכל מסך ראשי במערכות מרובות משתמשים בו-זמנית.
    • ‫[7.8.2/A-1-2] חובה להגדיר אזור אודיו לנהג שיכסה את הרמקול הכללי בתא הנוסעים. באזור של הנוסע שליד הנהג אפשר לשתף את אזור האודיו של הנהג או להגדיר פלט אודיו משלו.

    דרישות חדשות

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

    הצגת הגרסה

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

    • ‫[5.5.3/A-1-1] חובה להגדיר עקומות עוצמת קול זהות לכל זרמי פלט האודיו שממופים לאותה קבוצת עוצמת קול, כפי שמוגדר בקובץ ההגדרות של האודיו ברכב.

    דרישות חדשות

  • 2.5.3. תוכנה:

    הצגת הגרסה

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

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

    • ‫[3.8/A-1-1] חובה להטמיע את רשימת UserRestrictions המוגדרת מראש הבאה:

    • ‫[3.8/A-1-2] אסור לאפשר למשתמש לשנות את ההגדרות הבאות של משתמשים אחרים, באמצעות ההגדרות או API:

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

    דרישות חדשות

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

    הצגת הגרסה

    • ‫[9.11/A-0-4] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה של האימות מוגן על ידי חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. מפתחות החתימה של האימות צריכים להיות משותפים למספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות בתור מזהי מכשירים קבועים. דרך אחת לעמוד בדרישה הזו היא לשתף את אותו מפתח אישור, אלא אם מיוצרות לפחות 100,000 יחידות של מק"ט מסוים. אם מיוצרים יותר מ-100,000 יחידות של מק"ט מסוים, אפשר להשתמש במפתח אחר לכל 100,000 יחידות.

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

    הצגת הגרסה

    • ‫[6.1/A-0-5] שירות ה-daemon של perfetto traced חייב להיות מופעל כברירת מחדל (מאפיין המערכת persist.traced.enable).

    דרישות חדשות

  • 2.6.1. חומרה:

    הצגת הגרסה

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

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

    • ‫[7.7.1/Tab] יכול ליישם את Android Open Accessory (AOA) API.

3. תוכנה

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

    הצגת הגרסה

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

  • 3.3.1. Application Binary Interfaces:

    הצגת הגרסה

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

  • 3.8.3.4. הגנה על התראות רגישות:

    הצגת הגרסה

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

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

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

      • אפליקציות מערכת חתומות עם uid < 10000
      • ממשק משתמש של המערכת
      • קונכייה
      • אפליקציה ייעודית למכשיר נלווה (מוגדרת על ידי CompanionDeviceManager)
      • תפקיד (SYSTEM_AUTOMOTIVE_PROJECTION)
      • תפקיד (SYSTEM_NOTIFICATION_INTELLIGENCE)
      • תפקיד HOME

    ההטמעה של NotificationAssistantServices ב-AOSP מדגימה את הדרישות האלה ועומדת בהן. android.ext.services.notification לדוגמה.

    דרישות חדשות

  • 3.8.14. חלונות מרובים:

    הצגת הגרסה

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

    • ‫[C-4-1] חובה לתמוך במצב ריבוי חלונות.

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

    • ‫[C-5-1] חובה להטמיע את הגרסה הנכונה של Window Manager Extensions API level כפי שמתואר בWindowManager Extensions.

    דרישות חדשות

  • 3.9. ניהול מכשירים:

    הצגת הגרסה

    ‫Android כולל תכונות שמאפשרות לאפליקציות עם מודעות לאבטחה להפעיל אפליקציות של בקרי מדיניות מכשירים כדי לבצע פונקציות ניהול מכשירים ברמת המערכת, כמו אכיפה של מדיניות סיסמאות או ביצוע איפוס נתוני מכשיר מרחוק, באמצעות Android Device Administration API Device Policy Manager APIs.

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

    • ‫[C-1-1] חובה להצהיר על android.software.device_admin.
    • ‫[C-1-2] המכשיר חייב לתמוך בהקצאת הרשאות לבעלי המכשיר, כפי שמתואר בסעיף 3.9.1 ובסעיף 3.9.1.1.

  • 3.9.1.1. הקצאת הרשאות לבעלי המכשיר:

    הצגת הגרסה

    • ‫[C-1-2] חובה להציג הודעת גילוי נאות מתאימה (כמו זו שמופיעה ב-AOSP) ולקבל הסכמה מפורשת ממשתמש הקצה לפני הגדרת אפליקציה כבעלים של המכשיר, אלא אם המכשיר מוגדר באופן אוטומטי למצב הדגמה קמעונאית לפני האינטראקציה של משתמש הקצה עם המסך. אם הטמעות של מכשירים מצהירות על android.software.device_admin, אבל כוללות גם פתרון קנייני לניהול מכשירים ומספקות מנגנון לקידום אפליקציה שהוגדרה בפתרון שלהן כ'מקבילה לבעלות על המכשיר' ל'בעלות על המכשיר' הרגילה כפי שמזוהה על ידי ממשקי ה-API הרגילים של DevicePolicyManager ב-Android, הן:

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

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

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

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

    הצגת הגרסה

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

  • 3.12. TV Input Framework:

    הצגת הגרסה

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

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

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

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

    הצגת הגרסה

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

  • 3.19. הגדרות שפה:

    הצגת הגרסה

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

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

    דרישות חדשות

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

  • 5.3.8. ‫Dolby Vision:

    הצגת הגרסה

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

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

    הצגת הגרסה

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

    הצגת הגרסה

    • ‫[C-1-5] חובה לוודא שאפקטים של אודיו תומכים בכמה ערוצים עד למספר הערוצים של המיקסר, שנקרא גם FCC_LIMIT, כשתוצאות האפקט מוחזרות לצנרת האודיו של המסגרת. הכוונה היא לאפקטים רגילים של הוספה או עזר, אבל לא לאפקטים מיוחדים כמו downmix,‏ upmix ואפקטים של מרחב שמשנים את מספר הערוצים. מומלץ להשתמש בהתנהגות שוות ערך כשאי אפשר לראות את האפקטים דרך צינור האודיו של המסגרת (למשל, אפקטים של עיבוד אחרי או אפקטים שהועברו למיקום אחר).

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

    הצגת הגרסה

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

    הצגת הגרסה

    • ‫[C-1-4] ערכי השהייה (latency) הלוך ושוב שמחושבים על סמך חותמות הזמן של הקלט והפלט שמוחזרים על ידי AAudioStream_getTimestamp צריכים להיות בטווח של 200 אלפיות השנייה מערכי השהייה הלוך ושוב שנמדדים עבור AAUDIO_PERFORMANCE_MODE_NONE ו-AAUDIO_PERFORMANCE_MODE_LOW_LATENCY ברמקולים ובאוזניות קוויות ואלחוטיות.

    דרישות חדשות

    הצגת הגרסה

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

    • ‫[C-SR-1] זמן האחזור של הפלט הקולי הוא 100 מילי-שניות או פחות בנתיב הנתונים של הרמקול.

    • ‫[C-SR-2] זמן האחזור של הקשה להשמעת צליל הוא 80 אלפיות השנייה או פחות.

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

    הצגת הגרסה

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

    הצגת הגרסה

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

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

    הצגת הגרסה

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

    הצגת הגרסה

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

    • ‫[C-SR-8] זמן האחזור של קלט קר של 100 מילישניות או פחות בנתיב הנתונים של המיקרופון.
    • ‫[C-SR-11] השגיאה בחותמות הזמן של הקלט, שמוחזרות על ידי AudioRecord.getTimestamp או AAudioStream_getTimestamp, מוגבלת ל-‎+/- 1 ms.

    הצגת הגרסה

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

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

    הצגת הגרסה

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

    מכשיר והצהרות RTL (מילישניות) MAD (מילישניות) נתיבי לולאה חוזרת
    מוחזקת ביד 250 30 רמקול/מיקרופון, אנלוגי 3.5 מ"מ (אם נתמך), USB (אם נתמך)
    ‫>= MPC_T ‏ (14) 80 15 נתיב אחד לפחות
    FEATURE_AUDIO_LOW_LATENCY 50 10 נתיב אחד לפחות
    FEATURE_AUDIO_PRO 25 5 נתיב אחד לפחות
    FEATURE_AUDIO_PRO 20 5 אנלוגי (אם נתמך)
    FEATURE_AUDIO_PRO 25 5 USB (אם לא נתמכת אנלוגיה)

    דרישות חדשות

    הצגת הגרסה

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

    מכשיר והצהרות TTL (מילישניות)
    מוחזקת ביד 250
    ‫>= MPC_T ‏ (14) 80
    MPC_S (13) 100
    FEATURE_AUDIO_PRO 80

    דרישות חדשות

    הצגת הגרסה

    אם הטמעות של מכשירים כוללות תמיכה ב-spatial audio עם מעקב אחרי תנועות הראש ומצהירות על הדגל PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY, הן:

    • ‫[C-4-1] זמן האחזור בין מעקב הראש לבין עדכון האודיו חייב להיות 300ms לכל היותר.

    דרישות חדשות

  • 5.10. אודיו מקצועי:

    הצגת הגרסה

    • ‫[C-1-2] חובה שזמן האחזור הרציף של האודיו הלוך ושוב, יעמוד בדרישות זמן האחזור של FEATURE_AUDIO_PRO כפי שמוגדרות בסעיף 5.6 זמן אחזור של אודיו של 25 אלפיות השנייה או פחות לפחות בנתיב נתמך אחד.

    הצגת הגרסה

    • ‫[C-1-5] חובה לעמוד בדרישות של זמני האחזור של אודיו ב-USB זמן האחזור באמצעות AAudio native audio API ו-AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.

    הצגת הגרסה

    • ‫[C-1-8] זמן האחזור הממוצע מהקשה ועד להשמעת הטון חייב להיות 80 מילי-שניות או פחות במהלך לפחות 5 מדידות בנתיב הנתונים מהרמקול למיקרופון.
    • ‫[C-SR-1] מומלץ מאוד לעמוד בדרישות של זמן האחזור שמוגדרות בסעיף 5.6 זמן אחזור של אודיו, של 20 אלפיות השנייה או פחות, ב-5 מדידות עם סטיית תקן ממוצעת של פחות מ-5 אלפיות השנייה בנתיב מהרמקול למיקרופון.
    • ‫[C-SR-2] מומלץ מאוד לעמוד בדרישות של Pro Audio לגבי השהיית אודיו רציפה בהלוך ושוב, השהיית קלט קרה והשהיית פלט קרה, ודרישות אודיו ב-USB באמצעות AAudio native audio API בנתיב MMAP.
    • ‫[C-SR-3] מומלץ מאוד לספק רמה עקבית של ביצועי CPU בזמן שהשמע פעיל ועומס ה-CPU משתנה. צריך לבדוק את זה באמצעות אפליקציית Android‏ SynthMark. ‫SynthMark משתמשת בסינתיסייזר תוכנה שפועל במסגרת אודיו מדומה כדי למדוד את ביצועי המערכת. במסמכי התיעוד של SynthMark מוסבר על המדדים. צריך להפעיל את אפליקציית SynthMark באמצעות האפשרות 'בדיקה אוטומטית' ולהשיג את התוצאות הבאות:
      • voicemark.90 >= 32 voices
      • latencymark.fixed.little <= 15 msec
      • latencymark.dynamic.little <= 50 msec
    • מומלץ לצמצם את אי הדיוק והסחיפה של שעון האודיו ביחס לזמן הרגיל.
    • צריך לצמצם את הסחף של שעון האודיו ביחס למעבד CLOCK_MONOTONIC כשהשניים פעילים.
    • מומלץ לצמצם את השהיית האודיו במתמרים במכשיר.
    • מומלץ לצמצם את זמן האחזור של האודיו ב-USB דיגיטלי.
    • מומלץ לתעד את מדידות זמן האחזור של האודיו בכל הנתיבים.
    • מומלץ למזער את הג'יטר בזמני הכניסה של קריאות חוזרות להשלמת מאגר שמע, כי זה משפיע על אחוז רוחב הפס המלא של יחידת העיבוד המרכזית (CPU) שזמין לקריאה החוזרת.
    • צריך לספק אפס תקלות באודיו בשימוש רגיל בערך השהיה שדווח.
    • צריך לספק אפס הבדלים בזמן האחזור בין הערוצים.
    • צריך למזער את זמן האחזור הממוצע של MIDI בכל אמצעי התקשורת.
    • צריך למזער את השונות בזמן האחזור של MIDI בעומס (jitter) בכל אמצעי התקשורת.
    • צריך לספק חותמות זמן מדויקות של MIDI בכל אמצעי התקשורת.
    • צריך לצמצם את הרעשים באות האודיו במתמרים במכשיר, כולל התקופה מיד אחרי הפעלה במצב התחלתי.
    • צריך לספק אפס הבדלים בשעון האודיו בין הצדדים של הקלט והפלט של נקודות קצה תואמות, כששניהם פעילים. דוגמאות לנקודות קצה תואמות כוללות את המיקרופון והרמקול במכשיר, או את הכניסה והיציאה של שקע האודיו.
    • צריך לטפל בקריאות חוזרות להשלמת מאגר האודיו בצדדי הקלט והפלט של נקודות קצה תואמות באותו השרשור, כששניהם פעילים, ולהיכנס לקריאה החוזרת של הפלט מיד אחרי החזרה מהקריאה החוזרת של הקלט. או אם אי אפשר לטפל בקריאות החוזרות באותו השרשור, צריך להזין את הקריאה החוזרת של הפלט זמן קצר אחרי שמזינים את הקריאה החוזרת של הקלט, כדי לאפשר לאפליקציה תזמון עקבי של צד הקלט וצד הפלט.
    • צריך למזער את הפרש הפאזה בין אחסון האודיו ב-HAL בצד הקלט ובצד הפלט של נקודות קצה תואמות.
    • צריך למזער את זמן הטעינה של המגע.
    • צריך למזער את השונות בזמן האחזור של המגע בעומס (ג'יטר).

    הצגת הגרסה

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

    הצגת הגרסה

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

    הצגת הגרסה

    הצגת הגרסה

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

    הצגת הגרסה

    אם יישומי המכשירים כוללים יציאת HDMI, הם:

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

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

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

    הצגת הגרסה

    • ‫[C-0-2] חובה לתמוך ב-adb כפי שמתואר ב-Android SDK ובפקודות של מעטפת הפקודות (shell) שמופיעות ב-AOSP, שבהן יכולים להשתמש מפתחי אפליקציות, כולל dumpsys,‏ cmd stats ו-Simpleperf.

    הצגת הגרסה

    • ‫[C-0-10] חובה לתעד, ללא השמטה, ולהפוך את האירועים הבאים לנגישים ולזמינים לפקודת ה-Shell‏ cmd stats ולמחלקת System API‏ StatsManager.
      • ActivityForegroundStateChanged
      • AnomalyDetected
      • AppBreadcrumbReported
      • AppCrashOccurred
      • AppStartOccurred
      • BatteryLevelChanged
      • BatterySaverModeStateChanged
      • BleScanResultReceived
      • BleScanStateChanged
      • ChargingStateChanged
      • DeviceIdleModeStateChanged
      • ForegroundServiceStateChanged
      • GpsScanStateChanged
      • InputDeviceUsageReported
      • JobStateChanged
      • KeyboardConfigured
      • KeyboardSystemsEventReported
      • PluggedStateChanged
      • ScheduledJobStateChanged
      • ScreenStateChanged
      • SyncStateChanged
      • SystemElapsedRealtime
      • TouchpadUsage
      • UidProcessStateChanged
      • WakelockStateChanged
      • WakeupAlarmOccurred
      • WifiLockStateChanged
      • WifiMulticastLockStateChanged
      • WifiScanStateChanged

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

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

    הצגת הגרסה

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

    • ‫[C-4-1] חובה להטמיע את הגרסה הנכונה של Window Manager Extensions API level כפי שמתואר ב-WindowManager Extensions.

  • 7.1.4.1. ‫OpenGL ES:

    הצגת הגרסה

    • ‫[C-1-1] המכשיר חייב לתמוך ב-גם OpenGL ES 1.1, וגם 2.0, 3.0 ו-3.1, כפי שמתואר ומפורט במסמכי Android SDK.

    הצגת הגרסה

    • ‫[C-SR-1] מומלץ מאוד לתמוך ב-OpenGL ES 3.1.

  • 7.1.4.2. ‫Vulkan:

    הצגת הגרסה

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

    • ‫[C-SR-8] מומלץ מאוד לא לשנות את טוען Vulkan.
    • ‫[C-1-14] אסור למנות תוספים של מכשיר Vulkan מהסוגים KHR,‏ GOOGLE או ANDROID, אלא אם התוספים האלה נכללים בדגל התכונה android.software.vulkan.deqp.level.

    דרישות חדשות

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

    הצגת הגרסה

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

    דרישות חדשות

    הצגת הגרסה

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

    הצגת הגרסה

    • ‫[C-1-7] חובה לדרוש מהמשתמש אימות ראשי מומלץ (כמו קוד אימות, קו ביטול נעילה או סיסמה) פעם ב-24 שעות או פחות. הערה: כשמשדרגים מכשירים שהושקו עם Android בגרסה 9 או בגרסה מוקדמת יותר, המערכת חייבת לדרוש מהמשתמש אימות ראשי מומלץ (למשל, קוד אימות, קו ביטול נעילה או סיסמה) פעם אחת בכל 72 שעות או פחות.

    הצגת הגרסה

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

    הצגת הגרסה

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

    דרישות חדשות

  • 7.4.2. ‫IEEE 802.11 (Wi-Fi):

    הצגת הגרסה

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

    הצגת הגרסה

    • ‫[C-1-4] המכשיר חייב לתמוך ב-mDNS ואסור לו לסנן חבילות mDNS ‏(224.0.0.251 או ff02::fb) בכל זמן פעולה, כולל כשהמסך לא במצב פעיל, אלא אם נעילת ה-multicast לא מוחזקת והחבילות מסוננות על ידי APF. החבילות לא נדרשות כדי לספק פעולות mDNS שמוגדרות כרגע על ידי אפליקציות דרך ממשקי ה-API של NsdManager. עם זאת, המכשיר עשוי לסנן חבילות mDNS אם הסינון נדרש כדי לעמוד בטווחים של צריכת החשמל שנדרשים לפי הדרישות הרגולטוריות שחלות על שוק היעד.

    דרישות חדשות

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

  • 9.1. הרשאות:

    הצגת הגרסה

    • ‫[C-SR-1] מומלץ מאוד להעניק הרשאות עם protectionLevel של PROTECTION_SIGNATURE רק לאחת מהאפשרויות הבאות:

      • אפליקציות שהותקנו מראש בתמונת המערכת (וגם קובצי APEX).
      • אפליקציות שנוספו לרשימת ההיתרים עם הרשאות מותרות אם הן לא נכללות בתמונת המערכת.

    דרישות חדשות

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

    הצגת הגרסה

    אם מכשיר מצהיר על android.hardware.telephony, תומך ביכולת הרדיו CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK וכולל מודם סלולרי שתומך בחיבורי 2G, הטמעת המכשיר:

    • ‫[C-SR-17] מומלץ מאוד לספק למשתמשים אפשרות להשבית ולהפעיל את 2G.

    • ‫[C-SR-18] מומלץ מאוד לא לבטל את האפשרות למשתמש להשבית ולהפעיל את רשת 2G דרך ישות אחרת במכשיר, אלא רק דרך אדמין במכשיר באמצעות UserManager.DISALLOW_CELLULAR_2G.

    • ‫[C-SR-19] מומלץ מאוד להתקשר אל TelephonyManager.setAllowedNetworkTypesForReason עם הסיבה ALLOWED_NETWORK_TYPES_REASON_ENABLE_2G כדי לעמוד בדרישה הזו.

    • [C-SR-20] מומלץ מאוד לקבוע את התמיכה במודם סלולרי עבור 2G על ידי התקשרות אל TelephonyManager.getSupportedRadioAccessFamily. פרטים נוספים זמינים במאמר בנושא השבתת רשת 2G.

    דרישות חדשות

  • 9.8.2. הקלטה:

    הצגת הגרסה

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

    • ‫[C-0-7] אסור להקליט, להקרין או להפעיל Cast של מידע רגיש כמו:
      • תוכן רגיש בהתראה שמופיע בסעיף 3.8.3.4 Sensitive Notification Protection
      • חלונות של פעילות באפליקציות שמכילים סיסמאות חד-פעמיות
      • תוכן רגיש כמו שם משתמש, סיסמה ופרטי כרטיס אשראי

    דרישות חדשות

  • 9.8.16. נתוני אודיו ונתונים מהמצלמה באופן רציף:

    הצגת הגרסה

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

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

    דרישות חדשות

    הצגת הגרסה

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

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

    דרישות חדשות

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

    הצגת הגרסה

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

    • ‫[C-1-14] חובה לאמת את החתימה לפחות פעם אחת בכל אתחול של חבילות שנכללות ברשימת ההיתרים ומפורטות כ-require-strict-signature בהגדרת המערכת.

    דרישות חדשות

    הצגת הגרסה

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

    הצגת הגרסה

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

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

    • ‫[C-3-1] חובה לדווח על true עבור ConfirmationPrompt.isSupported() API.

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

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

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

    הצגת הגרסה

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

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

    הצגת הגרסה

    • ‫[C-10-6] חובה להשבית את היצירה של אירועי קלט משויכים באמצעות VirtualDeviceManager כשמצוין סטרימינג של אפליקציות כפי שמצוין על ידי DevicePolicyManager.setNearbyAppStreamingPolicy.

    הצגת הגרסה

    • ‫[C-10-7] חובה לבצע אחת מהפעולות הבאות:
      • השבתת השימוש בלוח
      • הפעלת לוח עריכה נפרד לכל מכשיר שתומך בלוחות עריכה

    דרישות חדשות

    • ‫[C-10-7] חובה להשתמש בלוח נפרד רק לכל מכשיר וירטואלי (או להשבית את לוח העריכה למכשירים וירטואליים)

    הצגת הגרסה

    • ‫[C-10-12] חובה להגביל כוונות שהופעלו ממכשיר וירטואלי כך שיוצגו רק באותו מכשיר וירטואלי

    הצגת הגרסה

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

    דרישות חדשות

    הצגת הגרסה

    • ‫[C-13-9] חובה לחסום פעילויות שלא מופעל בהן סטרימינג באופן מפורש ושמצוין בהן שהן מציגות תוכן רגיש, כולל באמצעות SurfaceView#setSecure, ו-FLAG_SECURE, או SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, מלפעול במכשיר הווירטואלי.

  • 9.11.2. ‫StrongBox:

    הצגת הגרסה

  • 9.17. ‫Android Virtualization Framework:

    הצגת הגרסה

    עיינו בסעיף 9.17. ‫Android Virtualization Framework.

חזרה למעלה