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

1. מבוא

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

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

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

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

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

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

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

1.1 מבנה המסמך

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

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

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

1.1.2. מזהה דרישה

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

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

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

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

1.1.3. מזהה דרישה בסעיף 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1. חומרה

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

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

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

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

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

• [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% או יותר מהצפיפות הפיזית בפועל של המסך המתאים.

סיום הדרישות החדשות

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

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

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

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

• [7.1.4.2/H-1-1] חייב לעמוד בדרישות שצוינו בפרופיל Android Baseline 2021.

סיום הדרישות החדשות

אם בהטמעות של מכשירים ניידים יש תמיכה בטווח דינמי גבוה מוצג באמצעות Configuration.isScreenHdr() , הם:

• [7.1.4.5/H-1-1] חובה לפרסם תמיכה EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace וגם VK_EXT_hdr_metadata תוספים.

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

• [7.1.4.6/H-0-1] חובה לדווח אם המכשיר תומך ביכולת הפרופיילינג של ה-GPU דרך מאפיין מערכת graphics.gpu.profiler.support.

אם הטמעות של מכשירים ניידים מוצהרות על תמיכה דרך מאפיין מערכת graphics.gpu.profiler.support, הן:

• [7.1.4.6/H-1-1] חובה לדווח כפלט מעקב ב-protobuf תואם לסכימה של מוני GPU ו-GPU שלבי העיבוד (re אונלייןs) שמוגדרים במסמכי התיעוד של Perfetto.
• [7.1.4.6/H-1-2] חובה לדווח על ערכים תואמים למוני ה-GPU במכשיר אחרי פרוטו של חבילת מעקב נגדי gpu.
• [7.1.4.6/H-1-3] חובה לדווח על ערכים תואמים ל-GPU RenderStages של המכשיר אחרי עיבוד של אובייקט מנות למעקב אחרי שלב.
• [7.1.4.6/H-1-4] חובה לדווח על תדירות GPU trackpoint כפי שצוין בפורמט: power/gpu_frequency.

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

• [7.1.5/H-0-1] חייבת לכלול תמיכה במכשירים מדור קודם מצב תאימות של אפליקציה כפי שמוטמע על ידי ה-upstream הפתוחה של Android קוד המקור. כלומר, אסור שהטמעות במכשירים ישנו את הטריגרים שבהם מופעל מצב תאימות, ואסור לשנות את של מצב התאימות עצמו.
• [7.2.1/H-0-1] חייבת לכלול תמיכה בצדדים שלישיים אפליקציות לעריכת שיטות קלט (IME).
• [7.2.3/H-0-2] חייבים לשלוח גם בלחיצה רגילה וגם בלחיצה ארוכה אירוע של פונקציית 'הקודם' (KEYCODE_BACK) לאפליקציה בחזית. המערכת לא יכולה להשתמש באירועים האלה יכול להיות מופעל על ידי מחוץ למכשיר Android (למשל חומרה חיצונית). המקלדת המחוברת למכשיר Android).
• [7.2.3/H-0-3] חייבים לספק את הפונקציה 'בית' ב- כל המסכים התואמים ל-Android שמספקים את מסך הבית.
• [7.2.3/H-0-4] חייבים לספק את פונקציית החזרה בכל המכשירים המסכים התואמים ל-Android והפונקציה 'אחרונים' לפחות במכשיר אחד במסכים שתואמים ל-Android.
• [7.2.4/H-0-1] חייב לתמוך בקלט מסך מגע.
• [7.2.4/H-SR-1] מומלץ מאוד להפעיל את אפליקציית עזרה שהמשתמש בוחר. כלומר, האפליקציה שמטמיעה VoiceInteractionService או פעילות המטפלת ב-ACTION_ASSIST בלחיצה ארוכה על KEYCODE_MEDIA_PLAY_PAUSE או KEYCODE_HEADSETHOOK אם הפעילות בחזית לא מטפלת באירועים האלה בלחיצה ארוכה.
• [7.3.1/H-SR-1] מומלץ מאוד לכלול תמונה עם 3 צירים מד תאוצה.

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

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

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

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

אם מוטמעים במכשיר נייד ג'ירוסקופ עם 3 צירים:

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

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

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

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

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

אם המכשירים תומכים בפרוטוקול Wi-Fi Neighbor Awareness Networking (NAN) על ידי הצהרה על PackageManager.FEATURE_WIFI_AWARE ועל מיקום Wi-Fi (עגול Wi-Fi זמן נסיעה – RTT) על ידי הצהרה על PackageManager.FEATURE_WIFI_RTT, ואז:

• [7.4.2.5/H-1-1] חובה לדווח על הטווח באופן מדויק: בטווח של +/-1 מטר ברוחב פס של 160MHz באחוזון ה-68 (כפי מחושב באמצעות פונקציית ההפצה המצטברת), +/-2 מטרים ברוחב פס של 80MHz האחוזון ה-68, +/-4 מטרים ברוחב פס של 40MHz במאון ה-68, ו- +/-8 מטרים ברוחב פס של 20MHz באחוזון ה-68 במרחקים של 10 MHz ס"מ, 1 מ', 3 מ' ו-5 מ', כפי שניתן לראות ב- Wi-FiRttManager#startRanging Android API.

• [7.4.2.5/H-SR-1] מומלץ מאוד לדווח על טווח מדויק בטווח של +/-1 מטר ברוחב פס של 160MHz ב-90 אחוזון (כפי שחושב באמצעות פונקציית ההתפלגות המצטברת), +/-2 מטרים ברוחב פס של 80MHz באחוזון 90, +/-4 מטרים ב-40MHz רוחב פס באחוזון ה-90, ו-+/-8 מטרים ברוחב פס של 20 מגה-הרץ האחוזון ה-90 במרחקים של 10 ס"מ, כפי שניתן לראות בעזרת Wi-FiRttManager#startRanging Android API.

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

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

אם מוצהר על 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.

סיום הדרישות החדשות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [7.8.2.2/H-1-1] חייב לספק את מיפוי התוכנה הבא של קודי ממשק אנושי:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [7.10/H]* לא צריכה להשתמש במסה מסתובבת אקסצנטרית (ERM) אקטואטור פיזי (רטט).
• [7.10/H]* צריך להטמיע את כל הקבועים הציבוריים עבור משוב פיזי ברור ב-android.view.HapticFeedbackConstants כלומר (CLOCK_TICK, CONTEXT_CLICK, KEYboard_PRESS, KEYMODEL_CONFIRM, KEYboard_TAP, long_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_הרחבה, אישור, REJECT, GESTURE_START ו-GESTURE_END).
• [7.10/H]* צריך להטמיע את כל הקבועים הציבוריים עבור משוב פיזי ברור ב-android.os.Vibration המטרות כלומר (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK וגם EFFECT_DOUBLE_CLICK) וכל האפשרויות הגלויות לציבור PRIMITIVE_* קבועים עבור משוב פיזי עשיר ב-android.os.Vibration sense.Composition כלומר (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). חלק מהפרימיטיביים האלה, ייתכן שניתן להשתמש ב-LOW_TICK וב-SPIN רק אם הרטט יכול לתמוך תדרים נמוכים יחסית.
• [7.10/H]* צריך לפעול בהתאם להנחיות למיפוי של קבועים ציבוריים ב-android.view.HapticFeedbackConstants לקבועים המומלצים של android.os.VibrationImpact, בקשרי המשרעת התואמים.
• [7.10/H]* צריך לעקוב הערכת איכות בשביל createOneShot() ו-createWaveform() ממשקי API.
• [7.10/H]* צריך לאמת שהתוצאה של הפונקציה android.os.Vibrator.hasAmplitudeControl() הציבורית ה-API משקף כראוי את היכולות של הרטט.
• [7.10/H]* צריך למקם את המיקום של האקטואטור ליד המיקום שבו בדרך כלל מחזיקים את המכשיר או נוגעים בו.

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

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

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

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

סיום הדרישות החדשות

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

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

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

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

• [7.10/H]* צריך לאמת את סטטוס ההטמעה על ידי הרצה של android.os.Vibrator.areAllמיקוםsSupported() ו-android.os.Vibrator.arePrimitivesSupported() ממשקי API.

• [7.10/H]* צריכה לבצע הערכת איכות קבועים פיזיים.

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

2.2.2. מולטימדיה

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

• [5.1/H-0-1] AMR-NB
• [5.1/H-0-2] AMR-WB
• [5.1/H-0-3] MPEG-4 AAC Profile (AAC LC)
• [5.1/H-0-4] MPEG-4 HE AAC Profile (AAC+)
• [5.1/H-0-5] AAC ELD (משופר עבור השהיה נמוכה AAC)

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

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

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

• [5.2/H-0-3] AV1

סיום הדרישות החדשות

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

• [5.3/H-0-1] H.264 AVC
• [5.3/H-0-2] H.265 HEVC
• [5.3/H-0-3] MPEG-4 SP
• [5.3/H-0-4] VP8
• [5.3/H-0-5] VP9

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

• [5.3/H-0-6] AV1

סיום הדרישות החדשות

2.2.3. תוכנות

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

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

אם יישומים של מכשירים ניידים תומכים בהתראות MediaStyle הם:

• [3.8.3.1/H-SR-2] מומלץ מאוד כדי לספק למשתמש אפשרות למחיר מסוים (לדוגמה, מתג להחלפת פלט) שמתבצעת אליו גישה ממשק המשתמש של המערכת שמאפשר למשתמשים לעבור בין המדיה הזמינה המתאימה מסלולים (לדוגמה, מכשירי Bluetooth ומסלולים שסופקו ל- MediaRouter2Manager) כשאפליקציה מפרסמת התראת MediaStyle עם אסימון MediaSession.

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

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

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

סיום הדרישות החדשות

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

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

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

• [3.8.4/H-1-1]* חייב להיות מסך התראות על שיחות לפני התראות על הודעות שאינן שיחה עם למעט התראות מתמשכות בנוגע לשירות שפועל בחזית חשיבות:high התראות.

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

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

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

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

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

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

• [3.8.16/H-1-4] חייב להיות רינדור מדויק למשתמש הזה מבחינת השם והסמל של כל אפליקציית צד שלישי מספק אמצעי בקרה דרך ControlsProviderService וכל השדות שצוינו על ידי Control ממשקי API.

• [3.8.16/H-1-5] חובה לספק משתמש אפשרות לבטל את ההסכמה לשימוש בפקדי מכשירים שמשמשים לאימות לצורך אימות את אמצעי הבקרה שנרשמו על ידי אפליקציות צד שלישי ControlsProviderService וגם Control API של Control.isAuthRequired.

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

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

סיום הדרישות החדשות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [7.5.4/H-1-1] חייב להיענות ל-android.media.action.STILL_IMAGE_CAMERA וגם android.media.action.STILL_IMAGE_CAMERA_SECURE Intent ומפעילים את המצלמה במצב תמונת סטילס, כפי שמתואר ב-SDK.
• [7.5.4/H-1-2] חייבים לכבד את android.media.action.VIDEO_CAMERA כוונה להפעיל את המצלמה במצב וידאו, כפי שמתואר ב-SDK.

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

• [3.2.3.1/ H-1-1] חייבת להיות פעילות שמטפלת Settings#ACTION_SETTINGS_CHANNEL_DEEP_LINK_ACTIVITY Intent כשפונקציונליות הפיצול מופעלת. הפעילות חייבת להיות מוגנת על ידי android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK, והיא חייבת להתחיל את הפעילות של ה-Intent שנותחה מ- הגדרות#חוץ_Settings_CHANNELDED_DEEP_LINK_INTENT_URI.

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

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

• [7.4.1.2/H-0-1] חובה להצהיר על דגל התכונה android.software.telecom.
• [7.4.1.2/H-0-2] חובה להטמיע את מסגרת הטלוויזיה.

סיום הדרישות החדשות

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

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

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

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

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

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

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

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

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

• [8.4/H-1-1] חייבים לכבד את android.intent.action.POWER_USAGE_SUMMARY Intent ומציג תפריט הגדרות שמציג את צריכת החשמל הזו.

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

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

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

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

סיום הדרישות החדשות

2.2.5. דגם אבטחה

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

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

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

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

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

סיום הדרישות החדשות

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

• [9.11/H-0-2] חייבים לגבות את ההטמעה של מאגר המפתחות עם סביבת הפעלה מבודדת.
• [9.11/H-0-3] חייבות להיות הטמעות של RSA, AES, אלגוריתמים קריפטוגרפיים מסוג ECDSA ו-HMAC, MD5, SHA1 ו-SHA-2 פונקציות גיבוב (hash) כדי שיתמכו בצורה תקינה בתכונות הנתמכות של מערכת Android Keystore באזור המבודד באופן מאובטח מהקוד שפועל הליבה (kernel) ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים קוד ליבה או מרחב משתמש שיכול לגשת למצב הפנימי של בסביבה מבודדת, כולל DMA. קוד פתוח של Android ב-upstream פרויקט (AOSP) עומד בדרישה הזו באמצעות ההטמעה של Trusty, אבל פתרון מבוסס ARM TrustZone או פתרון מאובטח על ידי צד שלישי או להטמיע בידוד מתאים שמבוסס על hypervisor אפשרויות.
• [9.11/H-0-4] חייבים לבצע את מסך הנעילה בסביבת ההפעלה המבודדת ורק כאשר בוצעה בהצלחה, תאפשר את השימוש במפתחות שקשורים לאימות. מסך הנעילה חייבים לאחסן את פרטי הכניסה באופן שמאפשר רק ביצוע מבודד כדי לבצע אימות של מסך הנעילה. Android בהמשך הדרך פרויקט קוד פתוח מספק Gatekeeper Hardware Layer Abstraction Layer (HAL) ו-Trusty, שיכולים לשמש כדי למלא את הדרישה הזו.
• [9.11/H-0-5] חייבת לתמוך באימות עם מפתחות כאשר מפתח חתימת אימות (attestation) מוגן באמצעות חומרה מאובטחת, והחתימה מבוצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה לאימות מספיק גדול של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשיר. אחת הדרכים לעמידה בדרישה הזו היא לשתף אותו מפתח אימות, אלא אם לפחות 100,000 יחידות של מק"ט נתון שהופק. אם מפיקים יותר מ-100,000 יחידות של מק"ט, ניתן להשתמש במפתח עבור כל 100,000 יחידות.

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

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

• [9.11/H-1-1] המשתמשים חייבים לבחור את האפשרות הכי קצרה הזמן הקצוב לתפוגה של שינה, כלומר זמן המעבר מביטול הנעילה למצב הנעילה באורך 15 שניות או פחות.
• [9.11/H-1-2] המשתמשים חייבים לאפשר למשתמשים להסתיר אותם ומשביתים את כל סוגי האימות, מלבד האימות הראשי שמתואר במאמר 9.11.1 Secure Lock Screen. ה-AOSP עומד דרישה למצב 'ללא 'ביטול נעילה עם טביעת אצבע''.

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

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

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

סיום הדרישות החדשות

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

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

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

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

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

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

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

סיום הדרישות החדשות

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

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

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

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

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

סיום הדרישות החדשות

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

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

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

סיום הדרישות החדשות

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

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

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

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

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

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

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

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

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

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

אפשר לעיין בסעיף 7.11 להגדרה של שיעור ביצועי המדיה.

2.2.7.1. מדיה

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

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

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

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

• [5.1/H-1-1] חובה לפרסם את המספר המקסימלי של מפענח וידאו באמצעות חומרה. סשנים שיכולים לפעול בו-זמנית בכל שילוב קודק באמצעות CodecCapabilities.getMaxSupportedInstances() והקבוצה VideoCapabilities.getSupportedPerformancePoints() אמצעי תשלום.
• [5.1/H-1-2] חייבת להיות תמיכה ב-6 מופעים של מפענח וידאו בחומרה של 8 ביט (SDR) סשנים (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב קודק שפועל בו-זמנית עם 3 הפעלות ב-1080p resolution@30fps ו-3 הפעלות ב-4K הרזולוציה@30fps, אלא אם כן AV1. רכיבי קודק AV1 נדרשים רק כדי לתמוך ברזולוציה של 1080p, אבל עדיין נדרשת לתמיכה ב-6 מכונות בקצב של 1080p30fps.
• [5.1/H-1-3] חובה לפרסם את המספר המקסימלי של מקודדי וידאו כחומרה סשנים שיכולים לפעול בו-זמנית בכל שילוב קודק באמצעות CodecCapabilities.getMaxSupportedInstances() והקבוצה VideoCapabilities.getSupportedPerformancePoints() אמצעי תשלום.
• [5.1/H-1-4] חייב לתמוך ב-6 מופעים של מקודד וידאו עם חומרת 8 ביט (SDR) סשנים (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב קודק שפועל בו-זמנית עם 4 הפעלות ב-1080p resolution@30 fps ו-2 הפעלות ב-4K הרזולוציה@30fps, אלא אם כן AV1. רכיבי קודק 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 רזולוציה (אלא אם AV1), שמתוכם 2 לכל היותר הם סשנים של מקודד ו-3 פעילויות באתר ברזולוציה של 1080p. רכיבי קודק AV1 נדרשים רק כדי לתמוך ברזולוציה של 1080p, אבל עדיין נדרשת לתמיכה ב-6 מכונות בקצב של 1080p30fps.
• [5.1/H-1-19] חייבת להיות תמיכה בשלושה מופעים של מפענח וידאו בחומרת 10 ביט (HDR) ומקודדים של וידאו חומרה (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב קודק שפועל בו-זמנית ברזולוציה של 4K@30fps (אלא אם הוא AV1) שמתוכם 1 הוא סשן מקודד, ואפשר להגדיר אותו פורמט קלט RGBA_1010102 דרך משטח GL. יצירת מטא-נתונים של HDR על ידי אין צורך במקודד אם הקידוד הוא משטח ה-GL. סשנים של קודק AV1 נדרשים רק כדי לתמוך ברזולוציה של 1080p גם דרישה זו מחייבת איכות 4K.
• [5.1/H-1-7] זמן האחזור לאתחול קודק חייב להיות 40 אלפיות השנייה או פחות עבור קידוד וידאו של 1080p או פחות עבור כל מקודדי הווידאו בחומרה כאשר עוד לא טעונה. הטעינה כאן מוגדרת כסרטון ברזולוציית 1080p עד 720p בו-זמנית מבצע המרת קידוד באמצעות קודק וידאו בחומרה יחד עם רזולוציה של 1080p אתחול הקלטת אודיו-וידאו. ב-Dolby vision Codec, הקודק זמן האחזור של האתחול חייב להיות 50 אלפיות השנייה או פחות.
• [5.1/H-1-8] זמן האחזור לאתחול קודק חייב להיות 30 אלפיות השנייה או פחות עבור סשן של קידוד אודיו בקצב העברת נתונים של 128kbps או קצב נמוך יותר לכל מקודדי האודיו כאשר עוד לא טעונה. הטעינה כאן מוגדרת כסרטון ברזולוציית 1080p עד 720p בו-זמנית מבצע המרת קידוד באמצעות קודק וידאו בחומרה יחד עם רזולוציה של 1080p אתחול הקלטת אודיו-וידאו.
• [5.1/H-1-9] חייבת להיות תמיכה בשני מופעים של מפענח וידאו עם חומרה מאובטחת סשנים (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב קודק שפועל בו-זמנית ב- 4k resolution@30 fps (אלא אם AV1) גם 8-bit (SDR) וגם תוכן באיכות HDR באיכות 10 ביט. סשנים של קודק AV1 נדרשים רק כדי לתמוך ברזולוציה של 1080p גם דרישה זו מחייבת איכות 4K.
• [5.1/H-1-10] חייבת להיות תמיכה בשלושה מופעים של מפענח וידאו לא מאובטח בחומרה יחד עם מופע אחד של סשן של מפענח וידאו עם חומרה מאובטחת (סה"כ 4 מכונות) (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב של קודק שפועלים בו-זמנית עם 3 הפעלות ברזולוציית 4K ברזולוציה של 30FPS (אלא אם כן AV1) שכולל סשן אחד של מפענח מאובטח וסשן אחד של nn-Secure ב-1080p. הרזולוציה@30fps, כאשר 2 סשנים יכולים להיות ב-HDR באיכות 10 ביט לכל היותר. סשנים של קודק AV1 נדרשים רק כדי לתמוך ברזולוציה של 1080p גם דרישה זו מחייבת איכות 4K.
• [5.1/H-1-11] חייב לתמוך במפענח מאובטח בכל חומרה של AVC, HEVC, ממפענח VP9 או AV1 במכשיר.
• [5.1/H-1-12] זמן האחזור לאתחול קודק חייב להיות 40 אלפיות השנייה או פחות עבור סשן של פענוח וידאו ברזולוציה של 1080p או פחות לכל מפענחי הווידאו בחומרה כשיש עומס. הטעינה כאן מוגדרת כטמפרטורה בו-זמנית בין 1080p ל-720p של המרת קידוד של וידאו בלבד באמצעות קודקי וידאו של חומרה יחד עם אתחול הפעלת אודיו-וידאו ברזולוציה של 1080p. ב-Dolby vision Codec, הקודק זמן האחזור של האתחול חייב להיות 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 שניות במהלך סרטון שינוי רזולוציה בסשן וידאו של 60 fps בסשן של 4K.
• [5.6/H-1-1] חייב להיות זמן אחזור של 'הקשה לגוון' של 80 אלפיות שנייה או פחות באמצעות בדיקת ההקשה לכוונון CTS של ה-CTS.
• [5.6/H-1-2] זמן האחזור של האודיו הלוך ושוב הוא 80 אלפיות שנייה או לפחות בנתיב נתונים נתמך אחד.
• [ 5.6/H-1-3] חייבת תמיכה באודיו >=24 ביט לפלט סטריאו של 3.5 מ"מ או יותר אם יש חיבור ליציאת אודיו ב-USB, אם הוא נתמך בכל הנתונים לתצורות של סטרימינג וזמן אחזור קצר. לזמן אחזור קצר הגדרה אישית, האפליקציה צריכה להשתמש באודיו במסגרת קריאה חוזרת (callback) עם זמן אחזור קצר במצב תצוגה. להגדרת הסטרימינג, יש להשתמש ב-Java AudioTrack באמצעות את האפליקציה. בתצורה של זמן אחזור קצר וגם בתצורה של סטרימינג, טכנולוגיית HAL sink הפלט צריך לקבל 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 פרופיל בסיס.
• [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), כאשר לפחות שניים מהם יכולים להציג תוכן וידאו של 10 ביט.

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

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

סיום הדרישות החדשות

2.2.7.2. מצלמה

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

• חייבת לעמוד בדרישות המדיה שמפורטות ב-Android 13 CDD סעיף 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 בתור FULL ומעלה לראשי תיבות של חזרה ו-LIMITED ומעלה לשחקנים ראשיים ראשוניים. מצלמה.
• [7.5/H-1-4] חייבת תמיכה CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME לשתי הראשיות מצלמות.
• [7.5/H-1-5] חייב להיות זמן אחזור של צילום JPEG עם Camera2 < 1,000 900 ms לרזולוציה של 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_מצב_SIMPLE או StatISTICS_FACE_DETECT_מצב_FULL) למצלמות הראשיות.

סיום הדרישות החדשות

2.2.7.3. חומרה

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

• המדיה חייבת לעמוד בדרישות המדיה שמפורטות ב-Android 13 CDD בסעיף 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.T למשך android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, ואז:

• חייבת לעמוד בדרישות הביצועים שמפורטות ב-Android 13 CDD בסעיף 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. דרישות לטלוויזיה

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

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

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

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

2.3.1. חומרה

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

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

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

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

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

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

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

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

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

• [7.6.1/T-1-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות בגודל של 896MB לפחות, אם נעשה שימוש באחת מהדחיסות הבאות:

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

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

• [7.6.1/T-2-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות בגודל של 1280MB לפחות, אם אחת מהדחיסות הבאה היא בשימוש:

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

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

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

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

2.3.2. מולטימדיה

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

• [5.1/T-0-1] MPEG-4 AAC Profile (AAC LC)
• [5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
• [5.1/T-0-3] AAC ELD (משופר עם השהיה נמוכה AAC)

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

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

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

• [5.2/T-0-3] AV1

סיום הדרישות החדשות

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

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

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

• [5.3.3/T-0-1] MPEG-4 SP
• [5.3.4/T-0-2] H.264 AVC
• [5.3.5/T-0-3] H.265 HEVC
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9
• [5.3.1/T-0-6] MPEG-2

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

• [5.3.2/T-0-7] AV1

סיום הדרישות החדשות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [5.8/T-1-1] חייב לתמוך ב-HDCP 2.2.

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

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

2.3.3. תוכנות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.5. דגם אבטחה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.1. חומרה

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

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

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

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

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

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

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

• [7.1.4.2/W-1-1] חייב לעמוד בדרישות שצוינו בפרופיל Android Baseline 2021.

סיום הדרישות החדשות

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

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

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

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

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

• [7.4.3/W-0-1] חייב לתמוך ב-Bluetooth.

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

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

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

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

2.4.2. מולטימדיה

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

2.4.3. תוכנות

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

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

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

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

אפליקציות בשעון שבהן מוצהר על android.hardware.audio.output דגל פיצ'ר:

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

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

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

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

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

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

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

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

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

2.4.5. דגם אבטחה

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

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

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

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

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

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

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

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

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

סיום הדרישות החדשות

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

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

הטמעות של מכשירי Android מסווגים ככלי רכב אם מוצהר על כך את התכונה android.hardware.type.automotive או לענות על כל הקריטריונים הבאים קריטריונים.

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

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

2.5.1. חומרה

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

• [7.1.1.1/A-0-1] חייב להיות מסך 6 לפחות אינץ' בגודל אלכסון פיזי.
• [7.1.1.1/A-0-2] חייבת להיות פריסה של גודל מסך לפחות 750 dp x 480 dp
• [7.2.3/A-0-1] חובה לספק את הפונקציה 'דף הבית' וגם MAY מאפשר פונקציות חזרה ופונקציות אחרונות.
• [7.2.3/A-0-2] חייבים לשלוח גם בלחיצה רגילה וגם בלחיצה ארוכה אירוע של פונקציית 'הקודם' (KEYCODE_BACK) לאפליקציה בחזית.
• [7.3/A-0-1] חובה להטמיע את התוכן ולדווח עליו GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED וגם PARKING_BRAKE_ON.
• [7.3/A-0-2] הערך של NIGHT_MODE הדגל חייב להיות תואם למצב היום/הלילה של מרכז הבקרה והוא צריך להתבסס על קלט מחיישן אור הסביבה. יכול להיות שחיישן אור הסביבה הבסיסי יהיה זהה בתור PhotoMeter.
• [7.3/A-0-3] חובה לספק שדה מידע נוסף לחיישן TYPE_SENSOR_PLACEMENT כחלק מ-SensorAdditionalInfo לכל חיישן שמסופק.
• [7.3/A-SR1] תמונת השער מיקום באמצעות שילוב של GPS/GNSS עם חיישנים נוספים. אם בוחרים במיקום לדעתך, מומלץ מאוד ליישם ולדווח החיישן התואם סוגים שונים ו/או מזהי נכסי רכב בשימוש.

• [7.3/A-0-4] המיקום נשלחה בקשה דרך LocationManager#requestLocationUpdates() אסור שתהיה התאמה למפה.

• [7.3.1/A-0-4] חייב לעמוד בדרישות של Android מערכת הקואורדינטות של חיישן הרכב.

• [7.3/A-SR-1] מומלץ מאוד להוסיף תמונה עם 3 צירים מד תאוצה וג'ירוסקופ עם 3 צירים.

• [7.3/A-SR-2] מומלץ מאוד ליישם את ההמלצה ולדווח עליה חיישן TYPE_HEADING.

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

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

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

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

• [7.1.4.2/A-1-1] חייב לעמוד בדרישות שצוינו בפרופיל Android Baseline 2021.

סיום הדרישות החדשות

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

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

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

• [7.3.1/A-SR-1] מומלץ מאוד להטמיע את חיישן מורכב למד תאוצה עם צירים מוגבלים.

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

• [7.3.1/A-1-3] חובה להטמיע את התוכן ולדווח עליו חיישן TYPE_ACCELEROMETER_LIMITED_AXES.
• [7.3.1/A-1-4] חובה להטמיע את התוכן ולדווח עליו חיישן TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

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

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

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

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

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

• [7.3.4/A-4-1] חובה להטמיע את התוכן ולדווח עליו חיישן TYPE_GYROSCOPE_LIMITED_AXES.
• [7.3.4/A-4-2] חובה להטמיע את התוכן ולדווח עליו חיישן TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

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

• [7.3.3/A-3-1] יש לקבוע את המיקום בפעם הראשונה מקלט ה-GPS/GNSS מופעל או לאחר יותר מ-4 ימים בתוך 60 שניות.
• [7.3.3/A-3-2] חייב לעמוד בקריטריונים של 'זמן עד לתיקון הראשון' כפי כמתואר בסעיפים 7.3.3/C-1-2 ו-7.3.3/C-1-6 לגבי כל שאר בקשות המיקום (כלומר בקשות שזו לא הפעם הראשונה) או אחרי 4 ימים ומעלה). הדרישה 7.3.3/C-1-2 היא בדרך כלל נפגשים בכלי רכב ללא קישוריות נתונים לרשת סלולרית, באמצעות חיזוי מסלול GNSS שחושב על המקלט, או באמצעות את המיקום הידוע האחרון של הרכב, יחד עם היכולת להביא בחשבון למשך 60 שניות לפחות, עם דיוק מיקום שמספק 7.3.3/C-1-3, או שילוב של שניהם.

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

• [7.3.4/A-4-3] חייבת להיות אפשרות לדווח על אירועים עד לתדירות מסוימת של לפחות 1Hz.
• [7.3.4/A-SR-3] STRONGLY_recommended לדיווח על אירועים עד של לפחות 10Hz.
• הוא צריך להיות מתייחס לצפון אמיתי.
• השירותים אמורים להיות זמינים גם כשהרכב יציב.
• צריכה להיות רזולוציה של מעלה אחת לפחות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סיום הדרישות החדשות

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

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

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

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

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

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

• [7.6.1/A-2-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות בגודל של 816MB לפחות, אם נעשה שימוש באחת מהדחיסות הבאות:

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

• [7.6.1/A-2-2] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות בגודל של 944MB לפחות אם אחת מהדחיסות הבאה מתבצעת:

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

• [7.6.1/A-2-3] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות בגודל של 1280MB לפחות אם אחת מהדחיסות הבאה מתבצעת:

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

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

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

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

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

• [7.7.1/A] צריכה לכלול יציאת USB שתומכת במצב היקפי.

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

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

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

• [7.8.2/A-0-1] חובה לכלול פלט אודיו וצריך להצהיר עליו android.hardware.audio.output.

2.5.2. מולטימדיה

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

• [5.1/A-0-1] MPEG-4 AAC Profile (AAC LC)
• [5.1/A-0-2] MPEG-4 HE AAC Profile (AAC+)
• [5.1/A-0-3] AAC ELD (משופר עם השהיה נמוכה AAC)

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

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

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

• [5.3/A-0-1] H.264 AVC
• [5.3/A-0-2] MPEG-4 SP
• [5.3/A-0-3] VP8
• [5.3/A-0-4] VP9

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

• [5.3/A-SR-1] H.265 HEVC

2.5.3. תוכנות

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

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

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

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

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

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

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

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

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

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

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

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

סיום הדרישות החדשות

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

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

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

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

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

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

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

• [3.9.3/A-1-1] חובה להטמיע את כל מאפיינים של מחזור החיים של משתמש
  • INITIAL_USER_INFO, SWITCH_USER, CREATE_USER, REMOVE_USER.

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

• [3.14/A-0-1] חייב לכלול מסגרת של ממשק משתמש לתמיכה אפליקציות צד שלישי שמשתמשות בממשקי API של מדיה, כפי שמתואר בסעיף 3.14.
• [3.14/A-0-2] חייב לאפשר למשתמש לבצע אינטראקציה באופן בטוח עם אפליקציות מדיה בזמן הנהיגה.
• [3.14/A-0-3] חייב לתמוך ב CAR_INTENT_ACTION_MEDIA_TEMPLATE פעולת Intent מרומזת עם CAR_EXTRA_MEDIA_PACKAGE נוסף.
• [3.14/A-0-4] חייבת להיות אפשרות לנווט אל אפליקציית מדיה העדפה activity, אבל חייבים להפעיל אותה רק כשההגבלות על חוויית המשתמש ברכב לא בתוקף.
• [3.14/A-0-5] חייב להופיע במסך הודעות שגיאה שהוגדרו על ידי אפליקציות מדיה, וחייב לתמוך בתוספות האופציונליות ERROR_RESOLUTION_ACTION_LABEL ו-ERROR_RESOLUTION_ACTION_INTENT.
• [3.14/A-0-6] חייבת לתמוך במחיר של חיפוש בתוך האפליקציה עבור אפליקציות שתומכות בחיפוש.
• [3.14/A-0-7] חייב לכבד CONTENT_STYLE_BROWSABLE_HINT וגם CONTENT_STYLE_PLAYABLE_HINT הגדרות בזמן הצגת MediaBrowser ההיררכיה.

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

• [3.14/A-1-1] חובה לכלול שירותי מדיה ולפתוח אותם עם CAR_INTENT_ACTION_MEDIA_TEMPLATE בכוונה טובה.

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

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

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

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

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

2.5.5. דגם אבטחה

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

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

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

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

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

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

סיום הדרישות החדשות

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

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

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

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

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

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

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

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

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

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

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

• כולל מקור כוח שמספק ניידות, כמו סוללה.

• מסך בגודל של יותר מ-7 אינץ' וקטן מ-18 אינץ', במדידה באלכסון.

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

2.6.1. חומרה

ג'ירוסקופ

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

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

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

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

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

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

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

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

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

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

2.6.2. דגם אבטחה

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

למידע נוסף, כדאי לעיין בסעיף [9.11].

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

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

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

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

2.6.2. תוכנות

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

3. תוכנות

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

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

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

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

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

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

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

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

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

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

  עם זאת:

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

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

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

סיום הדרישות החדשות

3.1.1. תוספים ל-Android

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

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

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

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

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

3.1.2. ספריית Android

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

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

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

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

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

3.2.1. הרשאות

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

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

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

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

פרמטר	פרטים
גרסה.גרסה	הגרסה של מערכת Android שפועלת כרגע, בפורמט קריא לאנשים הפורמט. אחד מערכי המחרוזת של השדה הזה חייב להיות מוגדר ב מחרוזות הגרסאות המותרות ל-Android 14.
VERSION.SDK	הגרסה של מערכת Android שפועלת כרגע, בפורמט לקוד של אפליקציה של צד שלישי. ב-Android 14, בשדה זה חייב להיות ערך המספר השלם 14_INT.
VERSION.SDK_INT	הגרסה של מערכת Android שפועלת כרגע, בפורמט לקוד של אפליקציה של צד שלישי. ב-Android 14, בשדה זה חייב להיות ערך המספר השלם 14_INT.
גרסה.INCREMENTAL	ערך שנבחר על ידי מכשיר ההטמעה שמגדיר את ה-build הספציפי של מערכת Android שפועלת כרגע, בפורמט קריא לאנשים. הזה אסור לעשות שימוש חוזר בערך הזה לגרסאות build שונות שזמינות למשתמשי הקצה. א' השימוש הטיפוסי בשדה הזה הוא לציין את מספר ה-Build בתהליך יצירת ה-build נעשה שימוש במזהה שינוי של בקרת מקור. הערך חייב להיות ניתן לקידוד כ-ASCII בפורמט 7 סיביות שניתן להדפסה ולהתאים לקידוד ביטוי רגולרי ' ^[^ :\/~]+$ ".
משחקי לוח	ערך שנבחר על ידי מכשיר ההטמעה שמזהה את חומרה פנימית שבה נעשה שימוש במכשיר, בפורמט קריא לאנשים. אפשרית בשדה הזה צריך לציין את הגרסה הספציפית של במכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות תואמים לביטוי הרגולרי "^[a-zA-Z0-9_-]+$".
מותג	ערך שמשקף את שם המותג המשויך למכשיר, כפי שהוא נקרא משתמשי הקצה. חייב להיות בפורמט קריא לאנשים, והוא צריך לייצג את יצרן המכשיר או מותג החברה שמתחתיו שמשווקות. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים אותו הביטוי הרגולרי "^[a-zA-Z0-9_-]+$".
SUPPORTED_ABIS	השם של קבוצת ההוראות (סוג מעבד (CPU) + מוסכמות ABI) של נייטיב ראו סעיף 3.3. ממשק API מקורי תאימות.
SUPPORTED_32_BIT_ABIS	השם של קבוצת ההוראות (סוג מעבד (CPU) + מוסכמות ABI) של נייטיב ראו סעיף 3.3. ממשק API מקורי תאימות.
SUPPORTED_64_BIT_ABIS	השם של קבוצת ההוראה השנייה (סוג מעבד (CPU) + מוסכמות ABI) של את הקוד המקורי. ראו סעיף 3.3. מודעות מותאמות תאימות ל-API.
מעבד [CPU_ABI]	השם של קבוצת ההוראות (סוג מעבד (CPU) + מוסכמות ABI) של נייטיב ראו סעיף 3.3. ממשק API מקורי תאימות.
מעבד CPU_ABI2	השם של קבוצת ההוראה השנייה (סוג מעבד (CPU) + מוסכמות ABI) של את הקוד המקורי. ראו סעיף 3.3. מודעות מותאמות תאימות ל-API.
מכשיר	ערך שנבחר על ידי מטמיע המכשיר שמכיל את שם הפיתוח או שם קוד המזהה את התצורה של תכונות החומרה לעיצוב התעשייתי של המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בגרסת 7 סיביות ותואמים לביטוי הרגולרי “^[a-zA-Z0-9_-]+$”. אסור לשנות את שם המכשיר הזה במהלך כל משך החיים של המוצר.
טביעת אצבע	מחרוזת שמשמשת לזיהוי ייחודי של ה-build הזה. היא צריכה להיות סבירה קריא לאנשים. היא חייבת להיות בתבנית הבאה: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.VERSION)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) לדוגמה: acme/myproduct/ mydevice:14/LMYXX/3359:userdebug/test-keys אסור שטביעת האצבע תכלול רווחים לבנים. הערך של חייב להיות מקודד בשדה הזה כ-ASCII של 7 ביט.
חומרה	שם החומרה (משורת הפקודה של הליבה או /proc). הוא הנכסים צריכים להיות קריאים באופן סביר לאנשים. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בגרסת 7 סיביות ולהתאים את הביטוי הרגולרי “^[a-zA-Z0-9_-]+$”.
מארח	מחרוזת שמשמשת לזיהוי ייחודי של המארח שעליו נבנה ה-build, ב- בפורמט קריא לאנשים. אין דרישות לגבי הפורמט הספציפי של שדה זה, מלבד שהוא לא יכול להיות null או מחרוזת ריקה ("").
מזהה	מזהה שנבחר על ידי מטמיע המכשיר כדי להתייחס למאפיין ספציפי בפורמט קריא לאנשים. השדה הזה יכול להיות זהה לערך android.os.Build.VERSION.INCREMENTAL, אבל אמור להיות ערך מספיק שעוזר למשתמשי קצה להבחין בין גרסאות build של תוכנות. הערך חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות ולהתאים ביטוי “^[a-zA-Z0-9._-]+$”.
יצרנים	השם המסחרי של יצרן הציוד המקורי (OEM) של המוצר. אין דרישות לגבי הפורמט הספציפי של השדה הזה, למעט שהוא לא יכול להיות null או מחרוזת ריקה (""). השדה הזה אסור לשנות את המדיניות במהלך כל משך החיים של המוצר.
SOC_MANUFACTURER	השם המסחרי של היצרן של המערכת הראשית ב- שבב (SOC) שנעשה בו שימוש במוצר. מכשירים עם אותו יצרן SOC צריך להשתמש באותו ערך קבוע. יש לבקש מיצרן ה-SOC את הקבוע הנכון שבו צריך להשתמש. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בגרסת 7 סיביות, חייב להתאים לביטוי הרגולרי '^([0-9A-Za-z ]+)' , אסור להתחיל או לסיים ברווח לבן, ואסור שהוא יהיה שווה ל-'לא ידוע'. אסור לשנות את השדה הזה במהלך כל משך החיים של המוצר.
SOC_MODEL	שם הדגם של המערכת הראשית על שבב (SOC) שבו נעשה שימוש את המוצר. מכשירים עם אותו מודל SOC צריכים להשתמש באותו ערך קבוע עם ערך מסוים. צריך לבקש מיצרן ה-SOC לקבל את הקבוע הנכון לשימוש. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות ולהתאים בביטוי הרגולרי "^([0-9A-Za-z ._/+-]+)$", אסור להתחיל או מסתיים ברווח לבן, ואסור שהוא יהיה שווה ל-'unknown'. השדה הזה אסור לשנות את המדיניות במהלך כל משך החיים של המוצר.
דגם	ערך שנבחר על ידי יישום ההטמעה של המכשיר, שמכיל את השם של כפי שמוכר למשתמש הקצה. הוא אמור להיות אותו השם שבו המכשיר משווק ונמכר למשתמשי הקצה. אין דרישות לגבי של השדה הזה, מלבד העובדה שהוא לא יכול להיות null או מחרוזת ריקה (""). אסור לשנות את השדה הזה במהלך כל משך החיים של המוצר.
מוצר	ערך שנבחר על ידי מטמיע המכשיר שמכיל את שם הפיתוח או שם הקוד של המוצר הספציפי (מק"ט) חייב להיות ייחודי אותו מותג. התוכן חייב להיות קריא לאנשים, אבל הוא לא מיועד בהכרח לתצוגה על ידי משתמשי קצה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות תואמים לביטוי הרגולרי "^[a-zA-Z0-9_-]+$". המוצר הזה אסור לשנות את שם המוצר במהלך כל משך החיים של המוצר.
ODM_SKU	ערך אופציונלי שנבחר על ידי מטמיע המכשיר שמכיל מק"ט (Stock Keeping Unit) שמשמש למעקב אחרי תצורות ספציפיות של המכשיר, לדוגמה, כל ציוד היקפי שכלול במכשיר כשהוא נמכר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות ולהתאים הביטוי הרגולרי ^([0-9A-Za-z.,_-]+)$.
סידורי	חייבת להיות 'UNKNOWN'.
תגים	רשימה מופרדת בפסיקים של התגים שנבחרו על ידי הכלי להטמעת מכשירים שעושה הבחנה נוספת בין ה-build. ניתן לקידוד את התגים כ-ASCII של 7 ביט ומתאימים את הביטוי הרגולרי "^[a-zA-Z0-9._-]+" וחייבים הם כוללים אחד מהערכים שתואמים לשלושת הפלטפורמות הטיפוסיות של Android בתצורת חתימה: מפתחות הפצה, מפתחות פיתוח ומפתחות בדיקה.
שעה	ערך שמייצג את חותמת הזמן של מועד ה-build.
סוג	ערך שנבחר על ידי ההטמעה של המכשיר, שמציין את זמן הריצה של ה-build. שדה זה חייב להכיל אחד מהערכים שתואם לשלוש הגדרות אופייניות של זמן ריצה ב-Android: משתמש, userdebug או eng.
משתמש	שם או מזהה משתמש של המשתמש (או המשתמש האוטומטי) שיצר את build. אין דרישות לגבי הפורמט הספציפי של השדה הזה, למעט שהוא לא יכול להיות null או מחרוזת ריקה ("").
security_PATCH	ערך שמציין את רמת תיקון האבטחה של ה-build. חובה לציין שה-build לא חשוף בשום צורה לבעיות שתוארו באמצעות 'מבזקי אבטחה ציבוריים' הייעודיים של Android. ההזמנה חייבת להיות בתוך בפורמט [YYYY-MM-DD], שתואם למחרוזת מוגדרת שמתועדת האבטחה הציבורית של Android תקציר או ב התראת אבטחה של Android, לדוגמה "2015-11-01".
BASE_OS	ערך שמייצג את הפרמטר FINGERprint של ה-build אחרת תהיה זהה ל-build הזה, למעט התיקונים שסופקו מבזקי אבטחה ציבוריים של Android. חייבים לדווח על הערך הנכון, ואם build כזה לא קיים. צריך לדווח על מחרוזת ריקה ("").
BOOTLOADER	ערך שנבחר על ידי מכשיר ההטמעה שמזהה את גרסת תוכנת האתחול הפנימית שמותקנת במכשיר, בפורמט קריא לאנשים. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות ולהתאים ביטוי רגולרי '^[a-zA-Z0-9._-]+$'.
getRadioVersion()	חייב (להיות או להחזיר) ערך שנבחר על ידי מטמיע המכשיר זיהוי גרסת הרדיו/המודם הפנימית הספציפית שבה נעשה שימוש במכשיר, בפורמט קריא לאנשים. אם למכשיר אין רדיו/modem חייב להחזיר NULL. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בגרסת 7 סיביות ולהתאים את הביטוי הרגולרי “^[a-zA-Z0-9._-,]+$”.
getENTER()	חייב (להיות או להחזיר) מספר סידורי של חומרה, חייב להיות זמין וייחודיים בכל המכשירים עם אותו MODEL ו-MANUFACTURER. הערך של חייב להיות ניתן לקידוד שדה זה כ-ASCII של 7 סיביות ולהתאים לביטוי הרגולרי “^[a-zA-Z0-9]+$”.

3.2.3. תאימות של Intent

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

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

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

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

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

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

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

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

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

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

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

• [C-0-4] חובה לנסות לאמת מסנני Intent על ידי ביצוע של שלבי האימות שמוגדרים במפרט של קישורים לנכסים דיגיטליים כפי שהוטמע על ידי מנהל החבילות ב-upstream בקוד פתוח של Android פרויקט.
• [C-0-5] חובה לנסות לאמת את מסנני Intent במהלך ההתקנה של את האפליקציה ולהגדיר את כל מסנני Intent של URI שאומתו בהצלחה בתור ברירת המחדל של הגורמים המטפלים באפליקציות עבור מזהי ה-URI שלהם.
• ב-MAY ניתן להגדיר מסנני Intent ספציפיים של URI כרכיבי handler שמוגדרים כברירת מחדל לאפליקציות עבור מזהי ה-URI שלהם, אם הם אומתו בהצלחה, אך מסנני URI של מועמדים אחרים נכשלים אימות. אם מכשיר כלשהו מבצע את הפעולה הזו, הוא חייב לספק את משתמש לשנות את תבנית ה-URI המתאימה בתפריט ההגדרות.
• חייבים לספק למשתמש אמצעי בקרה של קישורים לאפליקציה לכל אפליקציה בהגדרות בתור ככה:
  • [C-0-6] המשתמש חייב להיות מסוגל לשנות את כל אפליקציית ברירת המחדל. ההתנהגות של קישורים לאפליקציה: תמיד פתוחה, שואלת תמיד או אף פעם לא נפתחת. שחייב לחול על כל מסנני ה-Intent של ה-URI של המועמדים באופן שווה.
  • [C-0-7] המשתמש חייב לראות רשימה של כוונות ה-URI האפשריות מסננים.
  • הטמעת המכשיר עשויה לספק למשתמש את היכולת לשנות מסנני Intent ספציפיים של URI אפשריים שעברו בהצלחה לפי סינון לפי כוונת המשתמש.
  • [C-0-8] הטמעת המכשיר חייבת לספק למשתמשים את היכולת הצגה וביטול של מסנני Intent ספציפיים של URI אפשריים, אם המכשיר מאפשר לחלק ממסנני ה-Intent של ה-URI של המועמדים להצליח בעוד שאחרים עלולים להיכשל.

3.2.3.3. מרחבי שמות של Intent

• [C-0-1] אסור לכלול במכשירים רכיבי Android שמטמיעים פועל לפי כל דפוס חדש של כוונות או כוונות שידור באמצעות ACTION, CATEGORY או מחרוזת מפתח אחרת במרחב השמות android.* או com.android.* .
• [C-0-2] אסור לכלול בהטמעות של מכשירים רכיבי Android לפעול בהתאם לכל דפוס חדש של כוונת רכישה או של כוונות שידור באמצעות הפעולות ACTION, CATEGORY או מחרוזת מפתח אחרת במרחב חבילה ששייך לארגון אחר.
• [C-0-3] אסור למטמיעי מכשירים לשנות או להרחיב אף אחת מכוונות הרכישה הדפוסים המפורטים בסעיף 3.2.3.1.
• ייתכן שהטמעות מכשירים כוללות דפוסי כוונה שמשתמשים במרחבי שמות באופן ברור ומשויכים בבירור לארגון שלהם. האיסור הזה מקבילה לזו שצוינה במחלקות שפת Java בקטע 3.6.

3.2.3.4. כוונה לשידור

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

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

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

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

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

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

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

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

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

• [C-2-1] חובה לספק תפריט הגדרות שיקרא android.provider.Telephony.ACTION_CHANGE_DEFAULT כוונה להציג תיבת דו-שיח לשינוי אפליקציית ברירת המחדל ל-SMS.

• [C-2-2] חייבים לכבד את android.telecom.action.CHANGE_DEFAULT_DIALER Intent להציג תיבת דו-שיח כדי לאפשר למשתמש לשנות את ברירת המחדל של טלפון תרגום מכונה.

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

• [C-2-3] חובה לפעול בהתאם ל-android.telecom.action.CHANGE_PHONE_ACCOUNTS כוונה לספק למשתמשים אפשרות להגדיר את ConnectionServices המשויך ל-PhoneAccounts, מכיוון וגם PhoneAccount ברירת מחדל שספק שירותי הטלקומוניקציה יקבל משמשים לביצוע שיחות יוצאות. הטמעת ה-AOSP עומדת בדרישה הזו עד כולל 'אפשרות לשיחות-חשבונות' בתפריט "שיחות" תפריט ההגדרות

• [C-2-4] חובה לאפשר android.telecom.CallRedirectionService לאפליקציה שמכילה את android.app.role.CALL_REDIRECTION תפקיד.

• [C-2-5] חובה לספק למשתמש אפשרות לבחור אפליקציה שמכילה את android.app.role.CALL_REDIRECTION תפקיד.

• [C-2-6] חובה לפעול בהתאם ל-android.intent.action.SENDTO ו-android.intent.action.VIEW כוונות ולספק פעילות לשליחה/הצגה של הודעות SMS.

• [C-SR-1] מומלץ מאוד לכבד את android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_button, android.intent.action.VIEW &amp; android.intent.action.DIAL עם אפליקציית חייגן בטעינה מראש, שיכולה לטפל בכוונות האלה לספק מילוי הזמנות כפי שמתואר ב-SDK.

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

• [C-3-1] חובה לפעול בהתאם לandroid.settings.NFC_PAYMENT_SETTINGS כוונה להציג תפריט של הגדרות האפליקציה כברירת מחדל לתשלום בשיטת 'מצמידים ומשלמים'.
• [C-3-2] חובה לפעול בהתאם ל-android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT כוונה להציג פעילות שבה נפתחת תיבת דו-שיח שבה מבקשים מהמשתמש לשנות שירות הדמיית כרטיס שמוגדר כברירת מחדל לקטגוריה מסוימת, כפי שמתואר ב-SDK.

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

• [C-4-1] חובה לכבד את הכוונות האלה android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED &amp; android.nfc.action.TECH_DISCOVERED, כדי להציג פעילות שעומדת בציפיות של המפתחים ביחס לכוונות האלה שמתוארים ב-SDK.

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

• [C-5-1] חובה ליישם את הכללים של ‘android.bluetooth.adapter.action.REQUEST_ENABLE’ כוונה ולהציג פעילות מערכת כדי לאפשר למשתמש להפעיל Bluetooth.
• [C-5-2] חייבים לכבד את 'android.bluetooth.adapter.action.REQUEST_DISCOVERABLE' Intent ולהציג פעילות מערכת שמבקשת מצב גלוי.

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

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

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

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

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

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

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

• [C-9-1] חובה להטמיע את Settings#ACTION_processing_WIFI_EASY_CONNECT_URI ממשקי API של Intent כפי שמתואר במסמכי התיעוד של ה-SDK.

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

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

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

• [C-11-1] חייבת להיות פעילות שמטפלת Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS בכוונה טובה, אבל יכול להיות שבכוונתך ליישם את זה כפעולה מלכתחילה.

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

• [C-12-3] נקודת אחיזה חייבת, וחייבת לאפשר רק אפליקציות ל-Android שהותקנו מראש לטפל בכוונות הבאות MediaStore.ACTION_IMAGE_CAPTURE MediaStore.ACTION_IMAGE_CAPTURE_SECURE, ו-MediaStore.ACTION_VIDEO_CAPTURE כפי שמתואר במסמך ה-SDK.

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

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

• [C-13-2] חובה לכבד את הכוונות android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_רון, android.app.action.SET_NEW_password &amp; android.app.action.START_ENCRYPTION ויש להם פעילות למילוי הכוונות האלה, כפי שמתואר ב-SDK כאן.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-19-1] חובה להטמיע את הפרמטר NfcAdapter.ACTION_TRANSACTION_DETECTED Intent API (כ-"EVT_TRANSACTION" שמוגדר על ידי המפרט הטכני GSM Association TS.26 – דרישות מכשיר NFC).

סיום הדרישות החדשות

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

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

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

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

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

3.3. תאימות ל-Native API

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

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

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

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

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

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

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

  • armeabi (כבר לא נתמך כיעד על ידי ה-NDK)
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

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

  • libaaudio.so (תמיכה באודיו מקורי של AAudio)
  • libamidi.so (תמיכה ב-MIDI מקורית, אם התכונה android.software.midi זמינה? הוא נתבע כפי שמתואר בסעיף 5.9)
  • libandroid.so (תמיכה בפעילות מובנית ב-Android)
  • libc (ספריית C)
  • libcamera2ndk.so
  • libdl (קישור דינמי)
  • libEGL.so (ניהול פלטפורמות של OpenGL נייטיב)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (רישום ביומן Android)
  • libmediandk.so (תמיכה בממשקי API של מדיה מותאמת)
  • libm (ספריית מתמטיקה)
  • libneuralnetworks.so (Neural Networks API)
  • libOpenMAXAL.so (תמיכה ב-OpenMAX AL 1.0.1)
  • libOpenSLES.so (תמיכה באודיו מסוג OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (תמיכה מינימלית עבור C++ )
  • libvulkan.so (Vulkan)
  • libz (דחיסת Zlib)
  • ממשק JNI

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

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

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

• [C-0-11] חובה לייצא את כל רכיבי OpenGL ES 3.1 וחבילת התוספים ל-Android סמלי פונקציות, כפי שמוגדרים ב-NDK, דרך הספרייה libGLESv3.so. לתשומת ליבכם: חייבים לציין את כל הסמלים, אבל סעיף 7.1.4.1 מתאר בפירוט רב יותר על הדרישות בנוגע להטמעה המלאה של כל אחד מהרכיבים האלה את הפונקציות התואמות.

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

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

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

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

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

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

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

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

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

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

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

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

3.4. תאימות לאתרים

3.4.1. תאימות ל-WebView

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

• [C-1-1] חובה לדווח על android.software.webview.
• [C-1-2] חובה להשתמש ב-build של פרויקט Chromium מפרויקט הקוד הפתוח של Android ב-Android ב-14 הסתעפות ליישום android.webkit.WebView API.

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

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

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

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

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

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

3.4.2. תאימות דפדפן

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-1-6] חובה להחזיר את הערך true עבור ActivityManager.isBackgroundRestricted() עבור כל הקריאות ל-API מאפליקציה.

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

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

• [C-1-10] חובה לספק מסמך או אתר ציבורי וברור שמתארים האופן שבו חלות הגבלות קנייניות. המסמך או האתר הזה חייבים להיות שניתן לקשר ממסמכי Android SDK והוא חייב לכלול:

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

אם אפליקציה הותקנה מראש במכשיר ומעולם לא הייתה בשימוש מפורש משתמש במשך יותר מ-30 יום, פטור [C-1-3] [C-1-5].

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

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

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

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

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

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

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

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

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

כלומר, הן:

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

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

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

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

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

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

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

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

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

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

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

• [C-0-1] חייבת להיות תמיכה בפורמט המלא של Dalvik Executable (DEX) ו-Dalvik bytecode לרשימה and semantics.

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

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

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

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

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

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

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

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

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

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

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

• [C-2-1] חובה לדווח על true עבור ShortcutManager.isRequestPinShortcutSupported().
• [C-2-2] המשתמש צריך לעמוד בתנאים כדי לשאול את המשתמש לפני הוספת קיצור דרך בבקשה באמצעות אפליקציות דרך ShortcutManager.requestPinShortcut() שיטת ה-API.
• [C-2-3] חייבת לתמוך במקשי קיצור מוצמדים ובמקשי קיצור דינמיים וסטטיים קיצורי הדרך כפי שמתואר בדף קיצורי הדרך של האפליקציות.

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

• [C-3-1] חובה לדווח על false עבור ShortcutManager.isRequestPinShortcutSupported().

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

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

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

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

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

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

3.8.2. ווידג'טים

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

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

• [C-1-1] חובה להצהיר על תמיכה בתכונה 'פלטפורמה' android.software.app_widgets

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

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

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

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

• [C-2-1] חובה לדווח על true עבור AppWidgetManager.html.isRequestPinAppWidgetSupported().
• [C-2-2] המשתמש צריך לעמוד בתנאים כדי לשאול את המשתמש לפני הוספת קיצור דרך בבקשה באמצעות אפליקציות דרך AppWidgetManager.requestPinAppWidget() שיטת ה-API.

3.8.3. התראות

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

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

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

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

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

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

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

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

• אמורות לתמוך בהתראות מתקדמות.

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

• צריכה להיות למשתמש אפשרות להשהות התראות.

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

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

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

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

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

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

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

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

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

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

3.8.3.2. שירות האזנה להתראות

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

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

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

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

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

3.8.3.3. נא לא להפריע (נא לא להפריע) / מצב עדיפות

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

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

3.8.4. ממשקי API של Assist

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

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

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

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

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

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

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

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

3.8.6. עיצובים

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

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

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

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

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

• [C-1-4] חובה ליצור לוחות צבעים דינמיים של צבעים כפי שצוין ב-AOSP תיעוד של Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (מידע נוסף זמין כאן android.theme.customization.system_palette והקבוצה android.theme.customization.theme_style).

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

  צבע המקור משמש ליצירת לוחות צבעים דינמיים של צבעים כאשר נשלחים android.theme.customization.system_palette (כפי שמתועד ב- Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).

• [C-1-6] ערך chroma CAM16 חייב להיות גבוה מ-5.

  • אמור להיגזר מהטפט דרך com.android.systemui.monet.ColorScheme#getSeedColors, שמספק מספר צבעי מקור חוקיים לבחירה אחד.

  • צריך להשתמש בערך 0xFF1B6EF3 אם אף אחד מהצבעים שצוינו לא מתאים את דרישת צבע המקור שצוינה למעלה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-1-1] חייבת לתמוך לפחות ב-7 פעילויות מוצגות.
• צריכה להציג לפחות כותרת של 4 פעילויות בכל פעם.

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

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

3.8.9. ניהול קלט

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

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

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

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

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

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

להגדרות, יש לעיין בסעיף 3.2.3.5 בכוונה לצרף את שומרי המסך.

3.8.12. מיקום

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

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

3.8.13. Unicode וגופן

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

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

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

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

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

ב-Android יש תמיכה בעיבוד גופנים במיאנמר. במיאנמר יש כמה גופנים שאינם תואמים ל-Unicode, המוכרים בשם "Zawgyi", לעיבוד מיאנמר בשפות שונות.

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

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

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

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

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

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

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

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

• [C-3-1] חובה להפעיל פעילויות במצב 'תמונה בתוך תמונה' בכמה חלונות כשהאפליקציה: * טירגוט לרמת API 26 ומעלה וההצהרה מוצהרת android:supportsPictureInPicture * טירגוט לרמת API 25 ומטה והצהרה על שתיהן android:resizeableActivity וandroid:supportsPictureInPicture.
• [C-3-2] חייבים לחשוף את הפעולות ב-SystemUI בתור מצוין על ידי הפעילות הנוכחית של התמונה בתוך התמונה (PIP) באמצעות setActions() API.
• [C-3-3] חייב לתמוך ביחסי גובה-רוחב שגדולים מ- או שווים לו 1:2.39 וקטן מ-2.39:1 או שווה לו, כפי שצוין בפעילות PIP דרך setAspectRatio() API.
• [C-3-4] חובה להשתמש ב-KeyEvent.KEYCODE_WINDOW כדי לשלוט בחלון 'תמונה בתוך תמונה'; אם מצב PIP לא מוטמע, המפתח חייב להיות זמינים לפעילות בחזית.
• [C-3-5] חובה לספק למשתמשים מספיק כסף כדי לחסום את הצגת האפליקציה מצב PIP; שהטמעת ה-AOSP עומדת בדרישה הזו. הפקדים בלוח ההתראות.

• [C-3-6] חובה להקצות את הרוחב והגובה המינימליים הבאים בשביל התמונה בתוך התמונה (PIP) חלון זמן שבו האפליקציה לא מצהירה על ערך כלשהו של AndroidManifestLayout_minWidth וגם AndroidManifestLayout_minHeight:

  • מכשירים שהמצב Configuration.uiMode שלהם מוגדר מלבד UI_MODE_TYPE_TELEVISION רוחב וגובה מינימליים חייבים להיות 108dp.
  • מכשירים שהמצב Configuration.uiMode שלהם מוגדר לערך UI_MODE_TYPE_TELEVISION חובה להקצות רוחב מינימלי של 240dp וגובה מינימלי של 135dp.

3.8.15. גזירה במסך

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

אם הטמעתם במכשירים את המגרעת במסך, המכשיר:

• [C-1-5] אסור שיהיו גזירים אם יחס הגובה-רוחב של המכשיר הוא 1.0(1:1).
• [C-1-2] אסור לכלול יותר מגזיר אחד בכל קצה.
• [C-1-3] חובה לפעול בהתאם לסימוני המגרעת במסך שהוגדרו על ידי האפליקציה דרך WindowManager.LayoutParams API כפי שמתואר ב-SDK.
• [C-1-4] חובה לדווח על הערכים הנכונים לכל מדדי המגרעת שמוגדרים DisplayCutout API.

3.8.16. ממשק השליטה במכשירים

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

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

3.8.17. לוח

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

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

אם בזמן העתקת התוכן מתבצעת הפעלה של הטמעות המכשירים, והתצוגה המקדימה שלו גלויה למשתמש. ללוח של כל פריט ClipData שבו ClipData.getDescription().getExtras() מכיל android.content.extra.IS_SENSITIVE, הן:

• [C-1-1] חובה לצנזר את התצוגה המקדימה הגלויה למשתמש

הטמעת קובץ העזר של AOSP עומדת בדרישות הבאות לגבי הלוח.

3.9. ניהול המכשיר

מערכת Android כוללת תכונות שמאפשרות לאפליקציות מבוססות אבטחה לפעול פונקציות ניהול המכשיר ברמת המערכת, כמו אכיפת סיסמה או לבצע מחיקה מרחוק, באמצעות Android Device Administration API

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

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

3.9.1 הקצאת מכשיר

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

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

• [C-1-1] חייבת לתמוך ברישום של Device Policy (DPC) בתור האפליקציה של בעלי המכשיר כפי שמתואר בהמשך:
  • כאשר הטמעת המכשיר כוללת לא משתמשים ולא של נתוני המשתמש, הוא:
    • [C-1-5] חובה לרשום את אפליקציית DPC כאפליקציה של בעלי המכשיר או להפעיל את אפליקציית ה-DPC כדי לבחור אם להפוך לבעלי מכשיר או לבעלים של פרופיל, אם המכשיר מצהיר על תמיכה בתקשורת מטווח קצר (NFC) דרך דגל התכונה android.hardware.nfc ומקבל הודעת NFC שמכיל רשומה עם סוג MIME MIME_TYPE_PROVISIONING_NFC.
    • [C-1-8] חובה לשלוח את ACTION_GET_PROVISIONING_מצב Intent אחרי שההקצאה של בעלי המכשיר מופעלת, כך ש אפליקציית DPC יכולה לבחור אם להפוך לבעלים של המכשיר או לפרופיל בעלים, בהתאם לערכים של android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, אלא אם ניתן לקבוע לכך שיש רק אפשרות חוקית אחת.
    • [C-1-9] חייבים לשלוח את ACTION_ADMIN_POLICY_COMPLIANCE כוונה לאפליקציה של בעלי המכשיר אם הוגדר בעל מכשיר במהלך ההקצאה, ללא קשר לשיטת ההקצאה שבה נעשה שימוש. לא תהיה למשתמש אפשרות להמשיך באשף ההגדרה עד האפליקציה של בעלי המכשיר הסתיימה.
  • כאשר הטמעת המכשיר כוללת משתמשים או כך:
    • [C-1-7] אסור לרשום אפליקציית DPC בתור האפליקציה של בעלי המכשיר עוד.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-1-1] חייבת לתמוך בפרופילים מנוהלים דרך android.app.admin.DevicePolicyManager ממשקי API.
• [C-1-2] חובה לאפשר יצירה של פרופיל מנוהל אחד בלבד.
• [C-1-3] חובה להשתמש בתג סמל (בדומה לתג העבודה ב-AOSP) כדי לייצג את האפליקציות והווידג'טים המנוהלים ורכיבים אחרים בממשק המשתמש עם תגים כמו 'אחרונים' ו- התראות.
• [C-1-4] חייב להציג סמל התראה (בדומה לפעולת upstream של AOSP כדי לציין מתי המשתמש נמצא באפליקציית פרופיל מנוהל.
• [C-1-5] חייב להציג הודעה קופצת שמציינת שהמשתמש נמצא בחשבון מנוהל פרופיל אם וכאשר המכשיר יתעורר (ACTION_USER_PRESENT) האפליקציה בחזית נמצאת בפרופיל המנוהל.
• [C-1-6] במקומות שבהם קיים פרופיל מנוהל, חייב להיות מציגים תועלת ויזואלית 'בורר' של Intent כדי לאפשר למשתמש להעביר את הכוונה מהחשבון המנוהל למשתמש הראשי או להפך, אם הוא מופעל באמצעות מדיניות המכשיר בקר.
• [C-1-7] במקרים שבהם קיים פרופיל מנוהל, חובה לחשוף את המשתמש הבא מחירים נוחים גם למשתמש הראשי וגם לפרופיל המנוהל:
  • התייחסות נפרדת לשימוש בסוללה, במיקום, בחבילת הגלישה ובנפח האחסון של המשתמש הראשי והפרופיל המנוהל.
  • ניהול עצמאי של אפליקציות VPN שמותקנות בתוך האפליקציה הראשית או פרופיל מנוהל.
  • ניהול עצמאי של אפליקציות שמותקנות בתוך המשתמש הראשי או פרופיל מנוהל.
  • ניהול עצמאי של חשבונות בתוך המשתמש הראשי או בחשבון המנוהל פרופיל.
• [C-1-8] חובה לוודא שהחייגן, אנשי הקשר והודעות הטקסט מותקנים מראש אפליקציות יכולות לחפש ולחפש מידע על מתקשרים (אם קיים) לצד הפרופילים מהפרופיל הראשי, אם המכשיר לבקרת מדיניות המכשירים מתיר זאת.
• [C-1-9] חייב לוודא שהוא עומד בכל דרישות האבטחה רלוונטי למכשיר שבו מופעלים משתמשים מרובים (ראו סעיף 9.5), למרות שהפרופיל המנוהל לא נספר כמשתמש אחר בנוסף למשתמש הראשי.

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

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

סיום הדרישות החדשות

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

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

3.9.3 תמיכה במשתמשים מנוהלים

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

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

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

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

3.9.4 דרישות התפקידים לניהול מדיניות מכשירים

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

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

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

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

אם שם חבילה מוגדר ל-config_devicePolicyManagement כפי שמתואר למעלה:

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

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

• [C-4-1] האפליקציה חייבת להיות מותקנת מראש במכשיר.
• [C-4-2] האפליקציה חייבת להטמיע מסנן Intent שפותר את הבעיה android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER

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

3.9.5 מסגרת של רזולוציית מדיניות מכשיר

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

• [C-1-1] חובה לפתור את ההתנגשויות של מדיניות המכשיר כפי שמתועד ב Device Policy Resolution Framework

סיום הדרישות החדשות

3.10. נגישות

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

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

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

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

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

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

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

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

• [C-1-1] חייבת לתמוך מסגרת Android TTS ממשקי API.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.18. אנשי קשר

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

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

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

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

הטמעות מכשירים:

• [C-SR-1] מומלץ מאוד לא ליצור חשבונות מקומיים בהתאמה אישית.

אם בהטמעות במכשירים נעשה שימוש בחשבון מקומי מותאם אישית:

• [C-1-1] ACCOUNT_NAME של החשבון המקומי המותאם אישית חייב להיות מוחזר על ידי ContactsContract.RawContacts.getLocalAccountName
• [C-1-2] ACCOUNT_TYPE של החשבון המקומי המותאם אישית חייב להיות מוחזר על ידי ContactsContract.RawContacts.getLocalAccountType
• [C-1-3] אנשי קשר גולמיים שנוספו על ידי אפליקציות של צד שלישי עם חשבון מקומי שמוגדר כברירת מחדל (כלומר, על ידי הגדרת ערכי null עבור ACCOUNT_NAME ו-ACCOUNT_TYPE) חייבים להוסיף אל המקומים המותאמים אישית חשבון.
• [C-1-4] אנשי קשר גולמיים שנוספו לחשבון המקומי המותאם אישית לא חייבים להיות מוסרים כשמוסיפים או מסירים חשבונות.
• [C-1-5] פעולות מחיקה שבוצעו בחשבון מקומי מותאם אישית חייבים לגרום לכך שאנשי הקשר הגולמיים יימחקו באופן מיידי (כאילו CALLER_IS_SYNCADAPTER הפרמטר הוגדר כ-True, גם אם הפרמטר CALLER\_IS\_SYNCADAPTER הוגדר ל-false או לא צוין.

4. תאימות לאריזת אפליקציות

הטמעות של מכשירים:

• [C-0-1] חייבת להיות יכולת להתקין ולהפעיל את Android "APK " קבצים בתור שנוצר על ידי ה-aapt שכלול SDK רשמי של Android.

  • מאחר שהדרישה שלמעלה עשויה להיות מאתגרת, הטמעת מכשירים מומלץ להשתמש בניהול החבילות של קובץ העזר של AOSP המערכת.

• [C-0-2] חייבת להיות תמיכה באימות ' .APK' באמצעות חבילת APK Signature Scheme v3.1 גרסה 3 של חתימת APK, גרסה 2 של חתימת APK וחתימת JAR.

• [C-0-3] אסור להאריך .APK, מניפסט ל-Android, Dalvik bytecode, או רינדור פורמטים של בייטקוד (bytecode) באופן שימנע מקבצים כאלה מותקנים ופועלים בצורה תקינה במכשירים תואמים אחרים.

• [C-0-4] אסור לאפשר שימוש באפליקציות מלבד האפליקציה הנוכחית 'המתקין הרשום' כדי שהחבילה תסיר את האפליקציה בלי להציג אישור משתמש, כפי שמתועד ב-SDK עבור DELETE_PACKAGE הרשאה. החריגים היחידים הם הטיפול באפליקציות של מאמת חבילות מערכת PACKAGE_NEEDS_Authentication כוונת הרכישה והטיפול באפליקציות של מנהל האחסון ACTION_MANAGE_STORAGE בכוונה טובה.

• [C-0-5] חייבת להיות פעילות שמטפלת android.settings.MANAGE_UNKNOWN_APP_SOURCES בכוונה טובה.

• [C-0-6] אסור להתקין חבילות של אפליקציות ממקורות לא ידועים מקורות, אלא אם האפליקציה שביקשה את ההתקנה עומד בכל הדרישות הבאות:

  • חובה להצהיר על REQUEST_INSTALL_PACKAGES או להגדיר את android:targetSdkVersion ל-24 ומטה.
  • המשתמש חייב לקבל הרשאה להתקין אפליקציות מ- מקורות לא ידועים.

• צריכה לספק למשתמש אפשרות להעניק/לבטל את ההרשאה להתקין אפליקציות ממקורות לא ידועים לכל אפליקציה, אבל ייתכן שבוחרים להטמיע הפעולה הזו מושבתת ולהחזיר RESULT_CANCELED למשך startActivityForResult(), אם הטמעת המכשיר לא רוצה לאפשר למשתמשים את האפשרות הזו. עם זאת, גם במקרים כאלו, הן חייבות לציין למשתמש מדוע בחירה באפשרות הזאת.

• [C-0-7] חייבת להופיע תיבת דו-שיח עם אזהרה עם מחרוזת האזהרה סופק באמצעות ממשק API של המערכת PackageManager.setHarmfulAppWarning למשתמש לפני הפעלה של פעילות באפליקציה שסומנה באמצעות אותו API של המערכת PackageManager.setHarmfulAppWarning, מזיקה.

• אמורה לספק למשתמש אפשרות לבחור להסיר או להפעיל בתיבת הדו-שיח של האזהרה.

• [C-0-8] חובה להטמיע תמיכה במערכת קבצים מצטברת כפי שמתועד כאן.

• [C-0-9] חייבת להיות תמיכה באימות קובצי .APK באמצעות APK Signature Scheme v4 וגם APK Signature Scheme v4.1

הערה: הטמעות של מכשירים שנשלחו ב-Android גרסה 10 או גרסאות קודמות, לא יכול לעמוד בדרישות [C-0-8] ו-[C-0-9] באמצעות תוכנת מערכת ייתכן שהעדכונים יהיו פטורים מהדרישות האלה.

5. תאימות למולטימדיה

הטמעות מכשירים:

• [C-0-1] חייב לתמוך בפורמטים של מדיה, מקודדים, מפענחים, סוגי קבצים ופורמטים של מאגרי תגים שמוגדרים בסעיף 5.1 לכל קודק שהוצהר על ידי MediaCodecList.
• [C-0-2] חובה להצהיר על תמיכה במקודדים ובמפענחים הזמינים ולדווח עליהם לאפליקציות צד שלישי MediaCodecList
• [C-0-3] חייבת להיות אפשרות לפענח את הקוד בצורה נכונה ולהפוך אותו לזמין לצד שלישי אפליקציות לכל הפורמטים שהוא יכול לקודד. זה כולל את כל ה-Bitstreams שהמקודדים יוצרים, והפרופילים שמדווחים CamcorderProfile

הטמעות מכשירים:

• המטרה צריכה להיות זמן אחזור מינימלי של קודק, במילים אחרות,
  • אין לצרוך ולאחסן אגי נתונים זמניים של קלט ולהחזיר רק מאגרי נתונים זמניים לאחר עיבוד.
  • אין להחזיק במאגרי נתונים מפוענחים למשך זמן ארוך יותר מכפי שצוין על ידי (למשל, SPS).
  • אסור להחזיק במאגרי נתונים מקודדים למשך זמן ארוך יותר מהנדרש על ידי ה-GOP שלנו.

כל רכיבי הקודק שמפורטים בקטע שבהמשך מסופקים כתוכנה בהטמעה המועדפת של Android מ-Android Open פרויקט מקור.

לתשומת ליבך, Google ו-Open Handset Alliance לא מבצעים הצהרה כי רכיבי הקודק האלה נטולי פטנטים של צד שלישי. האלה מומלץ להשתמש בקוד המקור הזה במוצרי חומרה או תוכנה בהטמעות של הקוד הזה, כולל בתוכנות קוד פתוח, תוכנת שיתוף, עשויה לחייב רישיונות פטנטים מבעלי הפטנטים הרלוונטיים.

5.1. רכיבי קודק של מדיה

5.1.1. קידוד אודיו

לפרטים נוספים קראו את הקטע 5.1.3. פרטי רכיבי הקודק של האודיו.

אם בהטמעות המכשירים מוצהר על android.hardware.microphone, הם חייבים לתמוך בקידוד של פורמטי האודיו הבאים ולהפוך אותם לזמינים לאפליקציות צד שלישי:

• [C-1-1] PCM/WAVE
• [C-1-2] קובץ FLAC
• [C-1-3] אופוס

כל מקודדי האודיו חייבים לתמוך:

• [C-3-1] הזמנת פריימים של אודיו בבייט מקורי של 16 ביט PCM דרך android.media.MediaCodec API.

5.1.2. פענוח הקוד של האודיו

לפרטים נוספים קראו את הקטע 5.1.3. פרטי רכיבי הקודק של האודיו.

אם בהטמעות המכשירים מוצהר על תמיכה android.hardware.audio.output, חייבת לתמוך בפענוח בפורמטים הבאים של אודיו:

• [C-1-1] פרופיל MPEG-4 AAC (AAC LC)
• [C-1-2] פרופיל MPEG-4 HE AAC (AAC+ )
• [C-1-3] פרופיל MPEG-4 HE AACv2 (משופר עבור AAC+ )
• [C-1-4] AAC ELD (AAC מושהה עם השהיה נמוכה)
• [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, כולל פרופיל הבסיס של USAC והטווח הדינמי של ISO/IEC 23003-4 פרופיל בקרה)
• [C-1-5] קובץ FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] ורביס
• [C-1-9] PCM/WAVE כולל אודיו ברזולוציה גבוהה פורמטים של עד 24 ביט, תדירות דגימה של 192 kHz ו-8 ערוצים. שימו לב שהדרישה הזו מיועדת לפענוח בלבד, ושמכשיר מותר לבצע הפחתת דגימה ו החלשת מיקסים במהלך שלב ההפעלה.
• [C-1-10] אופוס

אם יישומי המכשיר תומכים בפענוח של מאגרי קלט מסוג AAC סטרימינג מרובה-ערוצים (כלומר יותר משני ערוצים) ל-PCM דרך ברירת המחדל במפענח אודיו AAC ב-API android.media.MediaCodec, הקוד הבא חייב להיות נתמך:

• [C-2-1] חובה לבצע פענוח קוד ללא הפחתת מיקס (לדוגמה: AAC 5.0 יש לפענח זרם לחמישה ערוצים של PCM, זרם AAC מסוג 5.1 חייב להיות מפוענח לשישה ערוצים של PCM).
• [C-2-2] המטא-נתונים של טווח דינמי חייבים להיות מוגדרים כפי שמוגדר ב'בקרת טווח דינמי' (הרפובליקה הדמוקרטית של קונגו)" ב-ISO/IEC 14496-3, ומפתחות ה-DRC של android.media.MediaFormat כדי להגדיר את ההתנהגות של מפענח האודיו עם הטווח הדינמי. מפתחות AAC DRC הושקו ב-API 21 והם: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL וגם KEY_AAC_ENCODED_TARGET_LEVEL
• [C-SR-1] מומלץ מאוד שהדרישות C-2-1 ו-C-2-2 שמפורטות למעלה יהיו כל מפענחי האודיו מסוג AAC עומדים בדרישות.

בעת פענוח אודיו של USAC, MPEG-D (ISO/IEC 23003-4):

• [C-3-1] חובה לפרש ולהחיל מטא-נתונים של עוצמת קול וה-DRC בהתאם ל-MPEG-D DRC Dynamic Range Control Profile Level 1.
• [C-3-2] המפענח חייב להתנהג בהתאם להגדרות מוגדר באמצעות המקשים android.media.MediaFormat הבאים: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL וגם KEY_AAC_DRC_EFFECT_TYPE

מפענחי פרופיל MPEG-4 AAC, HE AAC ו-HE AACv2:

• עשויה לתמוך בעוצמה ובשליטה בטווח דינמי באמצעות ISO/IEC 23003-4 פרופיל של בקרת טווח דינמי.

אם תקן ISO/IEC 23003-4 נתמך ואם גם ISO/IEC 23003-4 וגם מטא-נתונים של ISO/IEC 14496-3 נמצאים ב-bitstream מפוענח, ואז:

• המטא-נתונים של ISO/IEC 23003-4 יקבלו עדיפות.

כל מפענחי האודיו חייבים לתמוך בפלט:

• [C-6-1] הזמנת פריימים של אודיו בבייט מקורי של 16 ביט PCM דרך android.media.MediaCodec API.

אם יישומי המכשיר תומכים בפענוח של מאגרי קלט מסוג AAC סטרימינג מרובה-ערוצים (כלומר יותר משני ערוצים) ל-PCM דרך ברירת המחדל מפענח אודיו AAC ב-API android.media.MediaCodec, אז הקוד הבא חייב להיות שבהן יש תמיכה:

• [C-7-1] האפליקציה חייבת להיות מוגדרת באמצעות פונקציית הפענוח עם המפתח KEY_MAX_OUTPUT_CHANNEL_COUNT כדי לקבוע אם התוכן יעבור רמיקס לסטריאו (כשמשתמשים בערך של 2) או מתקבל באמצעות מספר הערוצים המקורי (בעת שימוש בערך שווה או גדול ממספר זה). לדוגמה, ערך של 6 ומעלה יגדיר ממפענח, שמפיק פלט של 6 ערוצים כשמזינים תוכן 5.1.
• [C-7-2] במהלך הפענוח, המפענח חייב לפרסם את מסיכת הערוץ בפורמט הפלט עם הפונקציה KEY_CHANNEL_MASK מקש, באמצעות הקבועים android.media.AudioFormat (לדוגמה: CHANNEL_OUT_5POINT1).

אם בהטמעות של המכשיר יש תמיכה במפענחי אודיו שאינם ה-AAC שמוגדר כברירת מחדל ומסוגל להפיק פלט של אודיו מרובה-ערוצים (כלומר 2 ערוצים) כשמזינים תוכן דחוס בערוצים מרובים, ואז:

• [C-SR-2] מומלץ מאוד להגדיר את המפענח באמצעות הפענוח באמצעות המפתח KEY_MAX_OUTPUT_CHANNEL_COUNT כדי לקבוע אם התוכן יעבור רמיקס לסטריאו (כשמשתמשים בערך של 2) או מתקבל באמצעות מספר הערוצים המקורי (בעת שימוש בערך שווה או גדול ממספר זה). לדוגמה, ערך של 6 ומעלה יגדיר ממפענח, שמפיק פלט של 6 ערוצים כשמזינים תוכן 5.1.
• [C-SR-3] בזמן הפענוח מומלץ מאוד למפענח לפרסם נעשה שימוש במסכת ערוצים בפורמט הפלט עם הפונקציה KEY_CHANNEL_MASK מקש, באמצעות קבועים של android.media.AudioFormat (לדוגמה: CHANNEL_OUT_5POINT1).

5.1.3. פרטי רכיבי הקודק של האודיו

פורמט/קודק	פרטים	סוגי קבצים/פורמטים של קונטיינרים שנתמכים
MPEG-4 AAC פרופיל (AAC LC)	תמיכה בתוכן מונו/סטריאו/5.0/5.1 לפי תקן תדירות הדגימה של 8 עד 48kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) קובץ AAC גולמי של ADTS (.aac, ADIF לא נתמך) MPEG-TS (.ts, לא ניתן לחיפוש, פענוח בלבד) Matroska (.mkv, פענוח בלבד)
MPEG-4 HE AAC Profile (AAC+)	תמיכה בתוכן מונו/סטריאו/5.0/5.1 לפי תקן תדירות הדגימה של 16 עד 48kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 פרופיל (AAC+ משופר)	תמיכה בתוכן מונו/סטריאו/5.0/5.1 לפי תקן תדירות הדגימה של 16 עד 48kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (יעזור עם השהיה נמוכה של AAC)	תמיכה בתוכן מונו/סטריאו עם קצב דגימה רגיל מ-16 עד 48 קילו-הרץ.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC	תמיכה בתוכן מונו/סטריאו עם קצב דגימה רגיל החל מ-7.35 עד 48kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4.75 עד 12.2 kbps נדגם ב- 8 kHz	3GPP (.3gp)
AMR-WB	9 קצבים מ-6.60 קילו-ביט לשנייה עד 23.85 קילו-ביט לשנייה שנדגמו ב-16 קילו-הרץ, כפי שמוגדר ב- AMR-WB, Adaptive Multi-Rate – קודק דיבור בפס רחב	3GPP (.3gp)
FLAC	גם במקודד וגם במפענח: מצבי מונו וסטריאו לפחות חייבים להיות נתמך. חייבים לתמוך בתהליכי דגימה של עד 192 kHz. 16 סיביות ו-24 סיביות חייבת להיות תמיכה ברזולוציה הזו. הטיפול בנתוני אודיו של FLAC 24 ביט חייב להיות זמין עם הגדרת אודיו מנקודה צפה (floating-point).	FLAC‏ (‎.flac) MPEG-4 (.mp4, .m4a, פענוח בלבד) Matroska (.mkv, פענוח בלבד)
MP3	מונו/סטריאו 8-320Kbps קבוע (CBR) או קצב העברת נתונים משתנה (VBR)	MP3‏ (‎.mp3) MPEG-4 (.mp4, .m4a, פענוח בלבד) Matroska (.mkv, פענוח בלבד)
MIDI	MIDI סוג 0 ו-1. DLS גרסה 1 ו-2. XMF ו-Mobile XMF. תמיכה עבור פורמטים של רינגטונים RTTTL/RTX, OTA ו-iMelody	מקלידים 0 ו-1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
וורביס	פענוח: תמיכה בתוכן מונו, סטריאו, 5.0 ו-5.1 עם דגימה 8,000, 12,000, 16,000, 24,000 ו-48,000 Hz. קידוד: תמיכה בתוכן מונו וסטריאו עם קצב דגימה של 8,000, 12,000, 16,000, 24,000 ו-48,000 Hz	Ogg (.ogg) MPEG-4 (.mp4, .m4a, פענוח בלבד) Matroska (.mkv) Webm (.webm)
PCM/גל	קודק ה-PCM חייב לתמוך ב-PCM ליניארי של 16 ביט ובציפה (float) של 16 ביט. גל המחלץ צריך לתמוך ב-PCM ליניארי של 32 ביט, 24 ביט, 32 ביט וצפים של 32 ביט (עד למגבלת החומרה). חובה לספק תמיכה לשיעורי דגימה מתוך 8kHz עד 192kHz.	WAVE (.wav)
Opus	פענוח: תמיכה בתוכן מונו, סטריאו, 5.0 ו-5.1 עם תדירות דגימה של 8,000, 12,000, 16,000, 24,000 ו-48,000 Hz. קידוד: תמיכה בתוכן מונו וסטריאו עם תדירות דגימה של 8,000, 12,000, 16,000, 24,000 ו-48,000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, פענוח בלבד) Matroska (.mkv) Webm (.webm)

5.1.4. קידוד התמונה

לפרטים נוספים קראו את המאמר 5.1.6. פרטי קודק התמונה.

הטמעת מכשירים חייבת לתמוך בקידוד של קידוד התמונות הבא:

• [C-0-1] JPEG
• [C-0-2] PNG
• [C-0-3] WebP

התחלה של דרישות חדשות

• [C-0-4] AVIF
  • המכשירים חייבים לתמוך ב-BITRATE_MODE_CQ ובפרופיל Baseline.

סיום הדרישות החדשות

אם בהטמעות במכשירים יש תמיכה בקידוד HEIC באמצעות android.media.MediaCodec לסוג המדיה MIMETYPE_IMAGE_ANDROID_HEIC, הם:

• [C-1-1] חייב לספק קודק מקודד HEVC עם שיפור חומרה, תומך BITRATE_MODE_CQ במצב השליטה בקצב העברת נתונים, HEVCProfileMainStill וגודל מסגרת של 512 x 512 פיקסלים.

5.1.5. פענוח הקוד של התמונה

לפרטים נוספים קראו את המאמר 5.1.6. פרטי קודק התמונה.

הטמעות של מכשירים חייבות לתמוך בפענוח קידוד התמונה הבא:

• [C-0-1] JPEG
• [C-0-2] GIF
• [C-0-3] PNG
• [C-0-4] BMP
• [C-0-5] WebP
• [C-0-6] גולמי
• [C-0-7] AVIF (פרופיל בסיס)

אם ההטמעות במכשירים תומכים בפענוח וידאו באמצעות HEVC, המכשירים האלה: * [C-1-1] חייבת לתמוך בפענוח תמונה באמצעות HEIF (HEIC).

מפענחי תמונות שתומכים בפורמט בעומק ביט גבוה (9 ביט לכל ערוץ):

• [C-2-1] חייבת לתמוך בפלט בפורמט שווה ערך של 8 ביט אם התבקש על ידי באפליקציה, לדוגמה, דרך ARGB_8888 הגדרה של android.graphics.Bitmap.

5.1.6. פרטי קודק התמונה

פורמט/קודק	פרטים	סוגי קבצים נתמכים/פורמטים נתמכים של קונטיינרים
JPEG	בסיס+מתקדם	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
גולמי		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	תמונה, אוסף תמונות, רצף תמונות	HEIF (.heif), HEIC (.heic)
AVIF (פרופיל הבסיס)	תמונה, אוסף תמונות, פרופיל בסיס של רצף תמונות	מאגר HEIF (.avif)

מקודדים ומפענחים של תמונות שנחשפים דרך MediaCodec API

• [C-1-1] חייב לתמוך ב-YUV420 בצבע גמיש 8:8:8 פורמט (COLOR_FormatYUV420Flexible) עד CodecCapabilities.

• [C-SR-1] מומלץ מאוד לתמוך בפורמט הצבעים RGB888 למשטח הקלט במצב תצוגה.

• [C-1-3] חייבת לתמוך לפחות באחד מישוריים או חצי-מישוריים פורמט צבעים של YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (מקביל ל- COLOR_FormatYUV420Planar) או COLOR_FormatYUV420PackedSemiPlanar (שווה ערך אל COLOR_FormatYUV420SemiPlanar). מומלץ מאוד לתמוך בהם ובשניהם.

5.1.7. רכיבי קודק של וידאו

• לאיכות מקובלת של וידאו בסטרימינג ולווידאו באינטרנט שירותים, יישומים של מכשירים צריכים להשתמש בקודק חומרה VP8 שעומד הדרישות.

אם ההטמעות במכשירים כוללות מקודד או מפענח וידאו:

• [C-1-1] רכיבי קודק הווידאו חייבים לתמוך בגודלי בייט הזמני של קלט ופלט להכיל את המסגרת הדחוסה והלא דחוסה הגדולה ביותר האפשרית, כפי שנקבע לפי הסטנדרטי והתצורה, אבל גם לא באופן כללי.

• [C-1-2] מקודדים ומפענחי וידאו חייבים לתמוך ב-YUV420 בצבע גמיש 8:8:8 פורמטים (COLOR_FormatYUV420Flexible) עד CodecCapabilities.

• [C-1-3] מקודדים ומפענחי וידאו חייבים לתמוך לפחות באחד פורמט צבעים חצי-מישור YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (שווה ערך ל-COLOR_FormatYUV420Planar) או COLOR_FormatYUV420PackedSemiPlanar (שווה ערך ל-COLOR_FormatYUV420SemiPlanar). אנחנו ממליצים מאוד שתומכים בשניהם.

• [C-SR-1] מומלץ מאוד לתמוך במקודדים ובמפענחים של וידאו לפחות אחד ממישורים או ממישורים חצי-מישוריים שעברו אופטימיזציה לחומרה YUV420 ביחס 8:8:8 (YV12, NV12, NV21 או פורמט דומה שעבר אופטימיזציה על ידי הספק).

• [C-1-5] מפענחי וידאו שתומכים בפורמט בעומק ביט גבוה (יותר מ-9 ביט לכל ערוץ) חייב לתמוך בפלט בפורמט שווה ערך של 8 ביט אם שנדרשת על ידי האפליקציה. חייבים לשקף זאת באמצעות תמיכה פורמט צבע YUV420 8:8:8 דרך android.media.MediaCodecInfo.

אם הטמעתם את המכשיר כדי לפרסם תמיכה בפרופיל HDR באמצעות Display.HdrCapabilities הם:

• [C-2-1] חייב לתמוך בניתוח ובטיפול של מטא-נתונים סטטיים ב-HDR.

אם יישומי מכשירים מפרסמות תמיכה ברענון פנימי דרך FEATURE_IntraRefresh ב-MediaCodecInfo.CodecCapabilities בכיתה, הם:

• [C-3-1] חייבת לתמוך בתקופות הרענון בטווח של 10-60 פריימים לפעול באופן מדויק במשך 20% מתקופת הרענון שהוגדרה.

אלא אם צוין אחרת באפליקציה באמצעות המאפיין KEY_COLOR_FORMAT מפתח פורמט, הטמעות של מפענח וידאו:

• [C-4-1] ברירת המחדל של פורמט הצבע חייבת להיות מותאמת לתצוגת חומרה אם הוגדר באמצעות פלט משטח.
• [C-4-2] ברירת המחדל של פורמט הצבעים YUV420 8:8:8 צריכה להיות מותאמת למעבד (CPU) קריאה, אם הוגדר שלא להשתמש בפלט Surface.

5.1.8. רשימת רכיבי קודק של וידאו

פורמט/קודק	פרטים	סוגי קבצים/פורמטים של קונטיינרים שנתמכים
H.263		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, פענוח בלבד)
H.264 AVC	פרטים נוספים זמינים בסעיף 5.2 5.3 לפרטים	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, לא ניתן לחיפוש) Matroska (.mkv, פענוח בלבד)
H.265 HEVC	פרטים נוספים זמינים בסעיף 5.3	MPEG-4 (.mp4) Matroska (.mkv, פענוח בלבד)
MPEG-2	פרופיל ראשי	MPEG2-TS (.ts, לא ניתן לחיפוש) MPEG-4 (.mp4, פענוח בלבד) Matroska (.mkv, פענוח בלבד)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, פענוח בלבד)
VP8	פרטים נוספים זמינים בסעיף 5.2 5.3 לפרטים	WebM (.webm) Matroska (.mkv)
VP9	פרטים נוספים זמינים בסעיף 5.3	WebM (.webm) Matroska (.mkv)
AV1	פרטים נוספים זמינים בסעיף 5.2 ובסעיף 5.3	MPEG-4 (.mp4) Matroska (.mkv, פענוח בלבד)

5.1.9. אבטחה של קודק מדיה

הטמעת מכשירים חייבת להבטיח תאימות עם תכונות האבטחה של קודק מדיה כמתואר בהמשך.

Android כולל תמיכה ב-OMX, ממשק API להאצת מולטימדיה בפלטפורמות שונות, וכן את Codec 2.0, ממשק API להאצת מולטימדיה עם תקורה נמוכה.

אם הטמעות המכשיר תומכות במולטימדיה:

• [C-1-1] חובה לספק תמיכה ברכיבי קודק מדיה באמצעות OMX או Codec 2.0 ממשקי API (או שניהם) כמו בפרויקט הקוד הפתוח של Android ולא משביתים אותם, או לעקוף את הגנות האבטחה. זה לא אומר באופן ספציפי שבכל פעם קודק חייב להשתמש ב-OMX או ב-Codec 2.0 API, רק עם תמיכה של לפחות אחד מממשקי ה-API האלה חייב להיות זמין, והתמיכה בממשקי ה-API הזמינים חייבת להיות זמינה. את אמצעי האבטחה הקיימים.
• [C-SR-1] מומלץ מאוד לכלול תמיכה ב-Codec 2.0 API.

הטמעות של מכשירים לא תומכות ב-Codec 2.0 API:

• [C-2-1] חייב לכלול את קודק התוכנה התואם של OMX מ-Android פרויקט קוד פתוח (אם הוא זמין) לכל פורמט וסוג של מדיה (במקודד או במפענח) שנתמך על ידי המכשיר.
• [C-2-2] רכיבי קודק שהשמות שלהם מתחילים ב-'OMX.google'. חייבת להתבסס על בקוד המקור של פרויקט הקוד הפתוח של Android.
• [C-SR-2] מומלץ מאוד שקודקים של תוכנת OMX יפעלו בקודק שאין לו גישה למנהלי התקנים לחומרה אחרים מלבד ממפי זיכרון.

אם הטמעות במכשירים תומכים ב-Codec 2.0 API:

• [C-3-1] חייב לכלול את קודק התוכנה המתאים מסוג Codec 2.0 מ פרויקט קוד פתוח של Android (אם הוא זמין) לכל פורמט וסוג של מדיה (במקודד או במפענח) שנתמך על ידי המכשיר.
• [C-3-2] חייב לכלול את קודקי התוכנה Codec 2.0 בקודק התוכנה כפי שסופק בפרויקט הקוד הפתוח של Android, כדי לאפשר כדי להעניק גישה צרה יותר לקודקי תוכנה.
• [C-3-3] רכיבי קודק שהשמות שלהם מתחילים ב-c2.android. חייבת להתבסס על בקוד המקור של פרויקט הקוד הפתוח של Android.

5.1.10. אפיון של קודק מדיה

אם הטמעות במכשירים תומכים ברכיבי קודק של מדיה:

• [C-1-1] חייב להחזיר את הערכים הנכונים של אפיון קודק המדיה באמצעות MediaCodecInfo API.

ובפרט:

• [C-1-2] רכיבי קודק שהשמות שלהם מתחילים ב-'OMX'. חייבים להשתמש בממשקי API של OMX הם בעלי שמות שתואמים להנחיות למתן שמות ל-OMX IL.
• [C-1-3] רכיבי קודק שהשמות שלהם מתחילים ב-'c2'. חייבים להשתמש ב-Codec 2.0 API כוללים שמות שתואמים להנחיות למתן שמות של Codec 2.0 ב-Android.
• [C-1-4] רכיבי קודק שהשמות שלהם מתחילים ב-'OMX.google'. או 'c2.android'. חובה לא להיות מוגדר כספק או עם שיפור מהירות באמצעות חומרה.
• [C-1-5] רכיבי קודק שפועלים בתהליך קודק (ספק או מערכת) גישה למנהלי התקנים של חומרה אחרים מלבד הקצאת זיכרון וממפות להיות מאופיינים כתוכנה בלבד.
• [C-1-6] רכיבי קודק שלא קיימים בפרויקט הקוד הפתוח של Android או שאינם מבוססים בקוד המקור שבפרויקט הזה חייב להיות מוגדר כספק.
• [C-1-7] רכיבי קודק שמשתמשים בהאצת חומרה חייבים להיות מאפיינים לשיפור המהירות באמצעות חומרה.
• [C-1-8] שמות של רכיבי קוד לא יכולים להיות מטעים. לדוגמה, קודקים שנקראים 'מפענחים' חייבים לתמוך בפענוח קוד, ובמקודדים שנקראים 'מקודדים' חייבת להיות תמיכה באמצעות הקידוד. רכיבי קודק עם שמות שמכילים פורמטים של מדיה חייבים לתמוך באלה פורמטים.

אם הטמעות המכשיר תומכות ברכיבי קודק וידאו:

• [C-2-1] כל רכיבי קודק הווידאו חייבים לפרסם נתונים על קצב פריימים שניתן להשיג בגדלים הבאים, אם הקודק תומך בהם:

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p	HD 1080p	UHD
רזולוציית וידאו	176 x 144 פיקסלים (H263, MPEG2, MPEG4) 352 x 288 פיקסלים (מקודד MPEG4, H263, MPEG2) 320 x 180 פיקסלים (VP8, VP8) 320 x 240 פיקסלים (אחר)	704 x 576 פיקסלים (H263) 640 x 360 פיקסלים (VP8, VP9) 640 x 480 פיקסלים (מקודד MPEG4) 720 x 480 פיקסלים (אחר, AV1)	1408 x 1152 פיקסלים (H263) 720 x 1280 פיקסלים (אחר, AV1)	1920 x 1080 פיקסלים (חוץ מ-MPEG4, AV1)	3840 x 2160 פיקסלים (HEVC, VP9, AV1)

• [C-2-2] רכיבי קודק של וידאו שמאופיינים כהאצת חומרה חייבים לפרסם מידע על נקודות ביצועים. כל אחת מהרשימות חייבת להיות נתמכת נקודות ביצועים רגילות (מפורטות ב: PerformancePoint API), אלא אם הם כלולים בנקודת ביצועים רגילה אחרת שנתמכת.
• בנוסף, הם היו צריכים לפרסם נקודות ביצועים מורחבות אם הם לתמוך בביצועי וידאו עקביים בהשוואה לביצועים הרגילים שצוינו.

5.2. קידוד וידאו

אם ההטמעות במכשירים תומכים במקודד וידאו כלשהו והופכים אותו לזמין לאפליקציות צד שלישי, הן:

• זה לא אמור להיות, על פני שני חלונות הזזה, מעל 15% על קצב העברת הנתונים בין מרווחים בתוך הפריים (I-frame).
• לא אמור להיות יותר מ-100% מקצב העברת הנתונים בחלון הזזה של שנייה אחת.

התחלה של דרישות חדשות

אם ההטמעות במכשירים תומכים במקודד וידאו כלשהו והופכים אותו לזמין אפליקציות צד שלישי, ולהגדיר את
MediaFormat.KEY_BITRATE_MODE עד BITRATE_MODE_VBR כך שהמקודד יפעל במצב קצב העברת נתונים משתנה, ואז, כל עוד הוא לא משפיע על הסף המינימלי לאיכות, את קצב העברת הנתונים המקודד :

• [C-5-1] חובה לא צריך להיות, מעל 1 חלון הזזה, מעל 15% מקצב העברת הנתונים בין פנים בתוך המסגרת (I-frame) במרווחים.
• [C-5-2] חובה לא צריך להיות יותר מ- 100% יותר מקצב העברת הנתונים בחלון הזזה של שנייה אחת.

אם ההטמעות במכשירים תומכים במקודד וידאו כלשהו והופכים אותו לזמין אפליקציות צד שלישי ולהגדיר MediaFormat.KEY_BITRATE_MODE עד BITRATE_MODE_CBR כך שהמקודד פועל במצב קצב העברת נתונים קבוע, ואז קצב העברת הנתונים המקודד:

• [C-6-1] חובה [C-SR-2] מומלץ מאוד לא יותר מ-15% מקצב העברת הנתונים של יעד ההמרה בחלון הזזה של שנייה אחת.

סיום הדרישות החדשות

אם יישומי המכשיר כוללים תצוגת מסך מוטמע עם אורך אלכסון של 2.5 אינץ' לפחות, או כולל יציאת פלט וידאו או להצהיר על תמיכה במצלמה דרך android.hardware.camera.any דגל תכונה, הם:

• [C-1-1] חייבת לכלול תמיכה בסרטון אחד לפחות בפורמט VP8 או H.264 והופכים אותו לזמין לאפליקציות של צד שלישי.
• צריכה לתמוך גם במקודדי הווידאו VP8 וגם H.264 ולהפוך אותם לזמינים לאפליקציות של צד שלישי.

אם הטמעות המכשיר תומכות בסרטון H.264, VP8, VP9 או HEVC והופכים אותו לזמין לאפליקציות של צד שלישי, הם:

• [C-2-1] חייבת להיות תמיכה בקצבי העברת נתונים שניתנים להגדרה באופן דינמי.
• אמור לתמוך בקצבי פריימים משתנים, כאשר מקודד הווידאו אמור לקבוע משך הפריימים המיידי, על סמך חותמות הזמן של מאגרי קלט, להקצות את קטגוריית הביט שלה על סמך משך הפריים הזה.

אם בהטמעות המכשיר תומכים במקודד הווידאו MPEG-4 SP לאפליקציות צד שלישי הן:

• המקודד הנתמך צריך לתמוך בקצבי העברת נתונים שאפשר להגדיר באופן דינמי.

אם הטמעות המכשירים מספקות מקודדי וידאו או תמונות עם שיפור מהירות באמצעות חומרה, והן תומכות במצלמת חומרה אחת או יותר שמחוברת או מתנתקת דרך ממשקי ה-API של android.camera:

• [C-4-1] כל מקודדי הווידאו והתמונה עם שיפור מהירות באמצעות חומרה חייבים לתמוך לקידוד פריימים ממצלמות החומרה.
• צריכה לתמוך בקידוד פריימים ממצלמות החומרה דרך כל הווידאו או מקודדי תמונות.

אם הטמעות המכשיר מספקות קידוד HDR:

• [C-SR-1] מומלץ מאוד לספק פלאגין ממשק API להמרת קידוד חלקה להמרה מפורמט HDR לפורמט SDR.

5.2.1. H.263

אם בהטמעות של מכשירים יש תמיכה במקודדי H.263 והפיכתם לזמינים לאפליקציות צד שלישי, הן:

• [C-1-1] חייבת להיות תמיכה ברזולוציית QCIF (176 x 144) באמצעות פרופיל הבסיס ברמה 45. רזולוציית SQCIF היא אופציונלית.
• צריכה לתמוך בקצבי העברת נתונים שניתנים להגדרה באופן דינמי עבור במקודד הנתמך.

5.2.2. H.264

אם בהטמעות במכשירים יש תמיכה בקודק H.264:

• [C-1-1] חייבת לתמוך ב-Baseline Profile Level 3. עם זאת, תמיכה ב-ASO (הזמנת פרוסה שרירותית), FMO (גמישה) סדר Macroblock) ו-RS (פרוסות מיותרות) הוא אופציונלי. יתרה על כך, על תאימות למכשירי Android אחרים, מומלץ המקודדים לא משתמשים ב-ASO, ב-FMO וב-RS ליצירת פרופיל Baseline.
• [C-1-2] חייבת לתמוך בפרופילי קידוד וידאו באיכות SD (Standard Definition) בטבלה הבאה.
• צריכה לתמוך ברמה 4 של הפרופיל הראשי.
• צריכה לתמוך בפרופילי קידוד וידאו HD (איכות HD) בתור כפי שמצוין בטבלה הבאה.

אם בהטמעות במכשירים מדווחים על תמיכה בקידוד H.264 לרזולוציה של 720p או 1080p סרטונים ברזולוציה גבוהה באמצעות ממשקי ה-API של המדיה, הם:

• [C-2-1] חייבת לתמוך בפרופילי הקידוד שבטבלה הבאה.

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p	HD 1080p
רזולוציית וידאו	240 x 320 פיקסלים	720 x 480 פיקסלים	720 x 1280 פיקסלים	1920 x 1080 פיקסלים
קצב הפריימים של הסרטון	20 fps	30 fps	30 fps	30 fps
קצב העברת נתונים של וידאו	384 Kbps	2 Mbps	4Mbps	10Mbps

5.2.3. VP8

אם הטמעות במכשירים תומכים בקודק VP8:

• [C-1-1] חייבת לתמוך בפרופילים של קידוד וידאו באיכות SD.
• צריכה לתמוך בפרופילים הבאים של קידוד וידאו באיכות HD (איכות גבוהה).
• [C-1-2] חייבת להיות תמיכה בכתיבת קובצי Matroska WebM.
• אמור לספק קודק חומרה VP8 שעומד דרישות קידוד חומרה של פרויקט RTC, כדי להבטיח איכות סבירה של שירותי סטרימינג של וידאו באינטרנט ושירותי שיחות ועידה בווידאו.

אם יישומים של מכשירים ניידים מדווחים על תמיכה בקידוד VP8 ל-720p או 1080p סרטונים ברזולוציה גבוהה באמצעות ממשקי ה-API של המדיה, הם:

• [C-2-1] חייבת לתמוך בפרופילי הקידוד שבטבלה הבאה.

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p	HD 1080p
רזולוציית וידאו	180 x 320 פיקסלים	640 x 360 פיקסלים	720 x 1280 פיקסלים	1920 x 1080 פיקסלים
קצב הפריימים של הסרטון	30 fps	30 fps	30 fps	30 fps
קצב העברת נתונים של וידאו	800 Kbps	2 Mbps	4Mbps	10Mbps

5.2.4. VP9

אם בהטמעות במכשירים יש תמיכה בקודק VP9:

• [C-1-2] חייבת לתמוך בפרופיל 0 ברמה 3.
• [C-1-1] חייבת להיות תמיכה בכתיבת קובצי Matroska WebM.
• [C-1-3] חייבים ליצור נתוני CodecPrivate ואז
• הנתונים אמורים לתמוך בפרופילים של פענוח HD, כפי שמתואר בטבלה הבאה.
• [C-SR-1] מומלץ מאוד לתמוך בפרופילים של פענוח HD כפי שמצוין בטבלה הבאה, אם יש מקודד חומרה.

	SD	HD 720p	HD 1080p	UHD
רזולוציית וידאו	720 x 480 פיקסלים	720 x 1280 פיקסלים	1920 x 1080 פיקסלים	3840 x 2160 פיקסלים
קצב הפריימים של הסרטון	30 fps	30 fps	30 fps	30 fps
קצב העברת נתונים של וידאו	1.6 Mbps	4Mbps	‎5 Mbps	‎20 Mbps

אם בהטמעות של המכשיר נטען שהוא תומך בפרופיל 2 או בפרופיל 3 דרך ממשקי API של מדיה:

• תמיכה בפורמט 12 ביט היא אופציונלית.

5.2.5. H.265

אם בהטמעות במכשירים יש תמיכה בקודק H.265:

• [C-1-1] חובה לתמוך בפרופיל הראשי ברמה 3 עד רזולוציה של 512 x 512.
• צריכה לתמוך בפרופילי הקידוד באיכות HD כפי שצוין בטבלה הבאה.
• [C-SR-1] מומלץ מאוד לתמוך פרופיל SD ברזולוציית 720 x 480 פרופילי קידוד HD כפי שמצוין בטבלה הבאה, אם יש במקודד חומרה.

	SD	HD 720p	HD 1080p	UHD
רזולוציית וידאו	720 x 480 פיקסלים	720 x 1280 פיקסלים	1920 x 1080 פיקסלים	3840 x 2160 פיקסלים
קצב הפריימים של הסרטון	30 fps	30 fps	30 fps	30 fps
קצב העברת נתונים של וידאו	1.6 Mbps	4Mbps	‎5 Mbps	‎20 Mbps

התחלה של דרישות חדשות

5.2.6. AV1

אם בהטמעות במכשירים יש תמיכה בקודק AV1:

• [C-1-1] חייבת לתמוך בפרופיל הראשי, כולל תוכן של 8 ביט ו-10 ביט.

• [C-1-2] חובה לפרסם נתוני ביצועים, כלומר לדווח על נתוני הביצועים באמצעות getSupportedFrameRatesFor() או getSupportedPerformancePoints() ממשקי API לרזולוציות נתמכות בטבלה שבהמשך.

• [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
קצב העברת נתונים של וידאו	‎5 Mbps	8Mbps	16Mbps	50 Mbps

סיום הדרישות החדשות

5.3. פענוח הקוד של הווידאו

אם בהטמעות של המכשיר יש תמיכה בקודקים מסוג VP8, VP9, H.264 או H.265:

• [C-1-1] חייבת לתמוך ברזולוציה דינמית של וידאו ובשינוי של קצב הפריימים באמצעות ממשקי ה-API הרגילים של Android באותו זרם עבור כל גרסאות VP8 ו-VP9 קודקים H.264 ו-H.265 בזמן אמת ועד לרזולוציה המקסימלית הנתמכת לפי כל קודק במכשיר.

5.3.1. MPEG-2

אם בהטמעות במכשירים יש תמיכה במפענחי MPEG-2:

• [C-1-1] חייבת לתמוך ברמה הגבוהה של הפרופיל הראשי.

5.3.2. H.263

אם בהטמעות במכשירים יש תמיכה במפענחי H.263:

• [C-1-1] חובה לתמוך בפרופיל הבסיס ברמה 30 (רזולוציות CIF, QCIF ו-SQCIF @ 30fps 384kbps) ורמה 45 (רזולוציות QCIF ו-SQCIF @ 30fps 128kbps).

5.3.3. MPEG-4

בהטמעות במכשירים עם מפענחי MPEG-4:

• [C-1-1] חייבת לתמוך ב-Simple Profile Level 3.

5.3.4. H.264

אם בהטמעות במכשירים יש תמיכה במפענחי H.264:

• [C-1-1] חובה לתמוך בפרופיל הראשי ברמה 3.1 ובפרופיל Baseline. תמיכה עבור ASO (סידור פרוסות שרירותי), FMO (סידור גמיש של Macroblock) ו-RS (פרוסות מיותרות) הוא אופציונלי.
• [C-1-2] חייבת להיות אפשרות לפענח סרטונים באיכות SD (Standard Definition) הפרופילים שמפורטים בטבלה הבאה ומקודדים באמצעות פרופיל Baseline ו'פרופיל ראשי' רמת 3.1 (כולל 720p30).
• אמורה להיות אפשרות לפענח סרטונים בפרופילים באיכות HD כפי שמצוין בטבלה הבאה.

אם הגובה שמדווח על ידי השיטה Display.getSupportedModes() הוא שווה לרזולוציית הסרטון או גבוהה ממנה, הטמעות המכשירים:

• [C-2-1] חייב לתמוך בפרופילים של פענוח וידאו באיכות HD 720p, טבלה.
• [C-2-2] חייבים לתמוך בפרופילים של פענוח וידאו באיכות HD 1080p טבלה.

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p	HD 1080p
רזולוציית וידאו	240 x 320 פיקסלים	720 x 480 פיקסלים	720 x 1280 פיקסלים	1920 x 1080 פיקסלים
קצב הפריימים של הסרטון	30 fps	30 fps	60 fps	30 FPS (60fps^טלוויזיה)
קצב העברת נתונים של וידאו	800 Kbps	2 Mbps	8Mbps	‎20 Mbps

5.3.5. H.265 (‏HEVC)

אם בהטמעות במכשירים יש תמיכה בקודק H.265:

• [C-1-1] חייבת לתמוך ברמה הראשית של הרמה 3 בפרופיל הראשי ובסרטון SD של פרופילים לפענוח כפי שמצוין בטבלה הבאה.
• הנתונים אמורים לתמוך בפרופילים של פענוח HD, כפי שמתואר בטבלה הבאה.
• [C-1-2] חייבת לתמוך בפרופילים של פענוח HD, כפי שמצוין בהמשך אם יש מפענח חומרה.

אם הגובה שמדווח על ידי השיטה Display.getSupportedModes() הוא שווה לרזולוציית הסרטון או גדולה ממנה, ואז:

• [C-2-1] הטמעות של מכשירים חייבות לתמוך לפחות בתקן H.265 או VP9 של פרופילים ב-720, 1080 ו-UHD.

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p	HD 1080p	UHD
רזולוציית וידאו	352 x 288 פיקסלים	720 x 480 פיקסלים	720 x 1280 פיקסלים	1920 x 1080 פיקסלים	3840 x 2160 פיקסלים
קצב הפריימים של הסרטון	30 fps	30 fps	30 fps	30/60fps (60fps^טלוויזיה עם פענוח באמצעות חומרת H.265)	60 fps
קצב העברת נתונים של וידאו	600 Kbps	1.6 Mbps	4Mbps	‎5 Mbps	‎20 Mbps

אם המכשיר מיישם הצהרה על תמיכה בפרופיל HDR באמצעות המדיה ממשקי API:

• [C-3-1] הטמעות מכשירים חייבות לקבל את המטא-נתונים הנדרשים של HDR מ- של האפליקציה, וגם תמיכה בחילוץ ובפלט של ה-HDR הנדרש מטא-נתונים מה-bitstream ו/או מהקונטיינר.
• [C-3-2] הטמעות מכשירים חייבות להציג תוכן HDR באופן תקין במסך המכשיר או ביציאת וידאו רגילה (למשל, HDMI).

5.3.6. VP8

אם הטמעות במכשירים תומכים בקודק VP8:

• [C-1-1] חייבת לתמוך בפרופילים של פענוח SD שבטבלה הבאה.
• עליהם להשתמש בקודק חומרה VP8 שעונה על הדרישות.
• הפרופילים אמורים לתמוך בפרופילים של פענוח HD בטבלה הבאה.

אם הגובה כפי שדווח על ידי השיטה Display.getSupportedModes() שווה או גדול מרזולוציית הסרטון, אז:

• [C-2-1] הטמעות מכשירים חייבות לתמוך בפרופילים של 720p מהטבלה הבאה.
• [C-2-2] הטמעות מכשירים חייבות לתמוך בפרופילים של 1080p מהטבלה הבאה.

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p	HD 1080p
רזולוציית וידאו	180 x 320 פיקסלים	640 x 360 פיקסלים	720 x 1280 פיקסלים	1920 x 1080 פיקסלים
קצב הפריימים של הסרטון	30 fps	30 fps	30 FPS (60fps^טלוויזיה)	30 (60 fps^טלוויזיה)
קצב העברת נתונים של וידאו	800 Kbps	2 Mbps	8Mbps	‎20 Mbps

5.3.7. VP9

אם בהטמעות במכשירים יש תמיכה בקודק VP9:

• [C-1-1] חייב לתמוך בפרופילים של פענוח וידאו באיכות SD, כמו שמתואר כאן מהטבלה הבאה.
• הנתונים אמורים לתמוך בפרופילים של פענוח HD, כפי שמתואר בטבלה הבאה.

אם בהטמעות המכשיר תומכים בקודק VP9 ובמפענח חומרה:

• [C-2-1] חייבת לתמוך בפרופילים של פענוח HD, כפי שמצוין בהמשך טבלה.

אם הגובה שמדווח על ידי השיטה Display.getSupportedModes() הוא שווה לרזולוציית הסרטון או גדולה ממנה, ואז:

• [C-3-1] הטמעות של מכשירים חייבות לתמוך לפחות בתקן VP9 או H.265 של פרופילים במידות 720, 1080 ו-UHD.

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p	HD 1080p	UHD
רזולוציית וידאו	180 x 320 פיקסלים	640 x 360 פיקסלים	720 x 1280 פיקסלים	1920 x 1080 פיקסלים	3840 x 2160 פיקסלים
קצב הפריימים של הסרטון	30 fps	30 fps	30 fps	30FPS (60fps^טלוויזיה עם פענוח חומרה מסוג VP9)	60 fps
קצב העברת נתונים של וידאו	600 Kbps	1.6 Mbps	4Mbps	‎5 Mbps	‎20 Mbps

אם בהטמעות של מכשירים יש תמיכה ב-VP9Profile2 או ב-VP9Profile3 דרך 'CodecProfileLevel' ממשקי API למדיה:

• תמיכה בפורמט 12 ביט היא אופציונלית.

אם בהטמעות של המכשיר נטען שהוא תומך בפרופיל HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) דרך ממשקי API למדיה:

• [C-4-1] הטמעות מכשירים חייבות לקבל את המטא-נתונים הנדרשים של HDR (KEY_HDR_STATIC_INFO) עבור כל הפרופילים של HDR, וגם 'KEY_HDR10_PLUS_INFO' לפרופילים של HDR10Plus) מהאפליקציה. הם גם חייבים לתמוך בחילוץ ובפלט של המטא-נתונים הנדרשים של HDR מה-bitstream ו/או מהקונטיינר.
• [C-4-2] הטמעות מכשירים חייבות להציג תוכן HDR באופן תקין במסך המכשיר או ביציאת וידאו רגילה (למשל, HDMI).

5.3.8. Dolby Vision

אם בהטמעות המכשיר מוצהר על תמיכה במפענח Dolby Vision דרך HDR_TYPE_DOLBY_VISION , הם:

• [C-1-1] חובה לספק כלי חילוץ עם תמיכה ב-Dolby Vision.
• [C-1-2] התוכן של Dolby Vision חייב להופיע בצורה תקינה במסך המכשיר או ביציאת וידאו רגילה (למשל, HDMI).
• [C-1-3] חובה להגדיר את מזהה הטראק של שכבות הבסיס שתואמות לאחור (אם קיימות) כך שיהיו זהות שילבנו את מזהה המסלול של שכבת Dolby Vision.

5.3.9. AV1

אם בהטמעות במכשירים יש תמיכה בקודק AV1:

• [C-1-1] חייבת לתמוך בפרופיל 0, כולל תוכן של 10 ביט.

התחלה של דרישות חדשות

אם הטמעות המכשירים תומכים בקודק AV1 והופכים אותו לזמין לאפליקציות של צד שלישי:

• [C-1-1] חייבת לתמוך בפרופיל הראשי, כולל תוכן של 8 ביט ו-10 ביט.

אם הטמעות המכשירים מספקות תמיכה בקודק AV1 עם חומרה ממפענח מהיר יותר, ואז:

• [C-2-1] חייבת להיות אפשרות לפענח פרופילים של פענוח וידאו באיכות HD 720p לפחות מ: הטבלה שבהמשך כאשר הגובה מדווח לפי Display.getSupportedModes() שווה ל-720p או גדול ממנו.
• [C-2-2] חייבת להיות אפשרות לפענח פרופילים של פענוח וידאו באיכות HD 1080p לפחות מהטבלה למטה כשהגובה מדווח לפי 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
קצב העברת נתונים של וידאו	‎5 Mbps	8Mbps	16Mbps	50 Mbps

אם ההטמעות במכשירים תומכים בפרופיל HDR דרך ממשקי Media API, הם:

• [C-3-1] חייבת להיות תמיכה בחילוץ ובפלט של מטא-נתונים של HDR Bitstream ו/או קונטיינר.
• [C-3-2] תוכן HDR חייב להציג כראוי במסך המכשיר או יציאה רגילה של פלט וידאו (לדוגמה, HDMI).

סיום הדרישות החדשות

5.4. הקלטת אודיו

אומנם חלק מהדרישות שמפורטות בקטע הזה מפורטות החל מ-Android 4.3, אנחנו מתכננים את הגדרת התאימות לגרסאות עתידיות כדי לשנות אותן לחובה. מכשירי Android הקיימים והחדשים מוצלחים מאוד מומלץ לעמוד בדרישות שמפורטות בתור 'צריכות', או לא יוכלו להשיג תאימות ל-Android לאחר השדרוג .

5.4.1. הקלטת אודיו גולמית ופרטי מיקרופון

אם הטמעות המכשירים מצהירות על android.hardware.microphone, הן:

• [C-1-1] חובה לאפשר הקלטה של תוכן אודיו גולמי עבור כל שידור של AudioRecord או AAudio INPUT שנפתח בהצלחה. לכל הפחות, המאפיינים הבאים חייבים להיות נתמכים:

  • פורמט: PCM לינארי, 16 ביט
  • קצב דגימה: 8,000, 11,025, 16,000, 44100, 48,000 Hz
  • ערוצים: מונו
  • מקורות אודיו: DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED, או VOICE_PERFORMANCE. זה נכון גם לגבי ההגדרות המקבילות של הקלט הקבועות ב-AAudio, בשביל לדוגמה, AAUDIO_INPUT_PRESET_CAMCORDER.

• אמורה לאפשר הקלטה של תוכן אודיו גולמי עם הרכיבים הבאים: מאפיינים:

  • פורמט: PCM לינארי, 16 ביט ו-24 ביט
  • שיעורי דגימה: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48,000 Hz
  • ערוצים: מספר הערוצים שווה למספר המיקרופונים המכשיר

• [C-1-2] חובה לתעד את קצב הדגימה ברמה גבוהה יותר ללא הגדלת הדגימה.

• [C-1-3] חייב לכלול מסנן מתאים למניעת התמרה כאשר שיעורי הדגימה שתוארו למעלה מתועדים באמצעות שיטת הקטנת נתונים.

• אמור לאפשר הקלטת רדיו AM ו-DVD באיכות של תוכן אודיו גולמי, פירושו את המאפיינים הבאים:

  • פורמט: PCM לינארי, 16 ביט
  • קצב דגימה: 22,050, 48,000 Hz
  • ערוצים: סטריאו

• [C-1-4] חובה לפעול בהתאם ל-API של MicrophoneInfo ולמלא כראוי את המידע על המיקרופונים הזמינים במכשיר לאפליקציות צד שלישי דרך AudioManager.getMicrophones() API, להקלטת אודיו פעילה באמצעות MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED או VOICE_PERFORMANCE. אם הטמעת המכשיר מאפשרת תיעוד באיכות רדיו AM ו-DVD של אודיו גולמי תוכן, הם:

• [C-2-1] חובה לצלם ללא דגימת-על בכל יחס שגבוה מ- 16000:22050 או 44100:48000.

• [C-2-2] חייב לכלול מסנן מתאים למניעת התמרה בכל דגימות או דגימה כלפי מטה.

5.4.2. צילום לזיהוי קולי

אם הטמעות המכשירים מצהירות על android.hardware.microphone, הן:

• [C-1-1] חובה לצלם מקור האודיו android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION הוא אחד מקצבי הדגימה, 44100 ו-48000.
• [C-1-2] חובה להשבית כברירת מחדל כל עיבוד אודיו להפחתת רעש כאשר הקלטת שידור אודיו מהאודיו של AudioSource.VOICE_RECOGNITION מקור.

• [C-1-3] חובה להשבית כברירת מחדל כל בקרת קליטה אוטומטית במהלך ההקלטה שידור אודיו ממקור האודיו AudioSource.VOICE_RECOGNITION.

• אמורה להציג מאפיינים של משרעת (שריר) שטוחה לעומת שכיחות יחסית בטווח התדרים הבינוני: במיוחד ±3dB מ-100Hz עד 4,000Hz לכל וכל מיקרופון שמשמש להקלטת מקור האודיו לזיהוי קולי.

• [C-SR-1] מומלץ מאוד להראות רמות משרעת טווח תדרים: באופן ספציפי מ- ±20dB מ-30Hz עד 100Hz טווח תדרים בינוני לכל מיקרופון שמשמש להקלטת הקול מקור האודיו לזיהוי.

• [C-SR-2] מומלץ מאוד להראות רמות משרעת טווח תדרים: באופן ספציפי מ- ±30dB מ-4000Hz עד 22KHz בהשוואה טווח התדרים הבינוני לכל מיקרופון שמשמש להקלטת הקול מקור האודיו לזיהוי.

• צריך להגדיר את הרגישות לקלט האודיו, כך שמקור הטון סינוסאידי של 1,000 Hz הופעל ב-90dB רמת לחץ קול (SPL) (נמדד במרחק של 30 ס"מ מ- ליד המיקרופון) מניב תגובה אידיאלית של RMS 2,500 בטווח של 1,770 ו-3,530 ל-16 דגימות סיביות (או -22.35 db ±3dB התאמה מלאה לנקודה צפה/דיוק כפול דגימות) עבור כל מיקרופון שמשמש להקלטת הזיהוי הקולי מקור האודיו.

• יש להקליט את שידור האודיו של זיהוי הקול כך שאמפליטודת ה-PCM רמות לינאריות עוקבות באופן לינארי אחר שינויים ב-SPL בטווח של 30 דציבלים לפחות מ-18- דציבלים עד +12dB re 90dB SPL במיקרופון.

• צריך להקליט את שידור האודיו של זיהוי הקול עם הרמוניה עיוות (THD) קטן מ-1% ל-1kHz ברמת קלט של 90dB SPL המיקרופון.

אם בהטמעות המכשיר מוצהר על android.hardware.microphone ורעש טכנולוגיות דיכוי (הפחתה) שמותאמות לזיהוי דיבור:

• [C-2-1] חייבת להיות אפשרות לשלוט באפקט האודיו הזה באמצעות API של android.media.audiofx.NoiseSuppressor.
• [C-2-2] חייבת לזהות באופן ייחודי כל טכנולוגיה לביטול רעש באמצעות השדה AudioEffect.Descriptor.uuid.

5.4.3. צילום לצורך ניתוב מחדש של ההפעלה

המחלקה android.media.MediaRecorder.AudioSource כוללת את REMOTE_SUBMIX מקור האודיו.

אם בהטמעות במכשירים מוצהרות גם android.hardware.audio.output וגם android.hardware.microphone, הן:

• [C-1-1] חייבים להטמיע בצורה תקינה את מקור האודיו REMOTE_SUBMIX כדי כשאפליקציה משתמשת ב-API של android.media.AudioRecord כדי להקליט מקור האודיו, הוא מתעד שילוב של כל שידורי האודיו מלבד הבאים:

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4. מבטל הד אקוסטי

אם הטמעות המכשירים מצהירות על android.hardware.microphone, הן:

• צריך להטמיע כלי לביטול הד אקוסטי (AEC) טכנולוגיה שמכווננת לתקשורת קולית והוחלה על נתיב הצילום בזמן צילום באמצעות AudioSource.VOICE_COMMUNICATION.

אם יישומי המכשיר מספקים ביטול הד אקוסטי, כלומר נוסף לנתיב האודיו להקלטה כאשר AudioSource.VOICE_COMMUNICATION נבחר, הם:

• [C-SR-1] מומלץ להצהיר על כך באמצעות AcousticEchoCanceler שיטת ה-API AcousticEchoCanceler.isAvailable()
• [C-SR-2] מומלץ מאוד כדי לאפשר את אפקט האודיו הזה ניתן לשליטה באמצעות AcousticEchoCanceler API.
• [C-SR-3] מומלץ מאוד לזהות כל טכנולוגיית AEC באופן ייחודי דרך ה-Audio Effects.Descriptor.uuid. השדה הזה.

5.4.5. צילום בו-זמנית

אם בהטמעות במכשירים מוצהר על android.hardware.microphone,חובה להטמיע תיעוד דיגיטלי של בו-זמנית כפי שמתואר במסמך הזה. פרטים נוספים:

• [C-1-1] חובה לאפשר גישה בו-זמנית למיקרופון באמצעות נגישות הקלטת שירות עם AudioSource.VOICE_RECOGNITION ולפחות אחד להקלטת אפליקציות באמצעות כל AudioSource.
• [C-1-2] חובה לאפשר גישה בו-זמנית למיקרופון באמצעות אפליקציה עם תפקיד Assistant ולפחות אפליקציה אחת מצלם באמצעות כל AudioSource מלבד AudioSource.VOICE_COMMUNICATION או AudioSource.CAMCORDER.
• [C-1-3] חובה להשתיק את הקלטת האודיו עבור כל אפליקציה אחרת, מלבד שירות נגישות, והאפליקציה מצלמת באמצעות AudioSource.VOICE_COMMUNICATION או AudioSource.CAMCORDER. אבל, כאשר אפליקציה מצלמת דרך AudioSource.VOICE_COMMUNICATION ואז אפליקציה אחרת יכול להקליט את השיחה הקולית אם זו אפליקציה בעלת הרשאות (מותקנת מראש) עם הרשאה CAPTURE_AUDIO_OUTPUT.
• [C-1-4] אם שתי אפליקציות או יותר מבצעות תיעוד בו-זמנית לאף אחת מהאפליקציות אין ממשק משתמש בחלק העליון, זה שהתחיל לתעד את הגרסה האחרונה מקבל אודיו.

5.5. הפעלת האודיו

ב-Android יש תמיכה כדי לאפשר לאפליקציות להפעיל אודיו באמצעות האודיו ציוד היקפי שמשמש לפלט כפלט כפי שמוגדר בסעיף 7.8.2.

5.5.1. הפעלת אודיו גולמי

אם הטמעות המכשירים מצהירות על android.hardware.audio.output, הן:

• [C-1-1] חובה לאפשר הפעלה של תוכן אודיו גולמי עם הרכיבים הבאים: מאפיינים:

  • פורמטים של המקור: PCM לינארי, 16 ביט, 8 ביט, מספר ממשי (float)
  • ערוצים: מונו, סטריאו, תצורות חוקיות בערוצים מרובים עם עד 8 ערוצים
  • קצבי דגימה (ב-Hz):
    • 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 בערוץ ההגדרות האישיות שצוינו למעלה
    • 96000 במונו ובסטריאו

5.5.2. אפקטים קוליים

ב-Android יש API לאפקטים קוליים להטמעת מכשירים.

אם בהטמעות במכשירים מוצהר על התכונה android.hardware.audio.output, הם:

• [C-1-1] חייבת לתמוך ב-EFFECT_TYPE_EQUALIZER של EFFECT_TYPE_LOUDNESS_ENHANCER שניתן לשלוט בהם באמצעות תתי-מחלקות של אפקט אודיו Equalizer ו-LoudnessEnhancer.
• [C-1-2] חייבת לתמוך בהטמעת API של Visualizer, שאפשר לשלוט בה באמצעות הכיתה Visualizer.
• [C-1-3] חייבת לתמוך בהטמעה של EFFECT_TYPE_DYNAMICS_PROCESSING שניתן לשלוט בהם דרך המחלקה המשנית של AudioImpact DynamicsProcessing.

התחלה של דרישות חדשות

• [C-1-4] חייבת להיות תמיכה באפקטים של אודיו עם הקלט והפלט בנקודה צפה (floating-point).
• [C-1-5] חובה לוודא שאפקטים קוליים תומכים במספר ערוצים עד מספר ערוצי המיקסר שנקרא גם FCC_LIMIT.

סיום הדרישות החדשות

• צריכה לתמוך ב-EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, הטמעות EFFECT_TYPE_PRESET_REVERB ו-EFFECT_TYPE_VIRTUALIZER שניתן לשלוט בו דרך מחלקות המשנה AudioEffect BassBoost, EnvironmentalReverb, PresetReverb, Virtualizer.
• [C-SR-1] מומלץ מאוד להוסיף תמיכה באפקטים בנקודה צפה (floating-point) מרובה-ערוצים.

5.5.3. עוצמת הקול של פלט האודיו

הטמעות של מכשירים בכלי רכב:

• אמורה לאפשר שינוי של עוצמת הקול של האודיו בנפרד לכל שידור אודיו, באמצעות סוג התוכן או השימוש כפי שהוגדרו לפי AudioAttributes ושימוש באודיו ברכב כפי שהוגדר באופן ציבורי בandroid.car.CarAudioManager.

5.5.4. הורדת אודיו

אם בהטמעות במכשירים יש תמיכה בהפעלה של הפחתת אודיו, הן:

• [C-SR-1] מומלץ מאוד לחתוך את תוכן האודיו שהופעל ללא פערים בין שני קליפים באותו פורמט כשהוא מצוין על ידי API ללא פערים של AudioTrack ואת מאגר המדיה של MediaPlayer.

5.6. זמן אחזור של אודיו

זמן האחזור של האודיו הוא הזמן שחולף עד שאות אודיו עובר במערכת. סוגים רבים של אפליקציות מסתמכים על זמני אחזור קצרים כדי להשיג נתונים בזמן אמת אפקטים קוליים.

למטרות הסעיף הזה, צריך להשתמש בהגדרות הבאות:

• זמן אחזור של פלט מרווח הזמן בין המועד שבו האפליקציה כותבת מסגרת של נתונים מקודדים לפי PCM וכשהצליל התואם מוצג במתמר במכשיר או שהאות יוצא מהמכשיר דרך ואפשר לצפות בו באופן חיצוני.
• זמן אחזור של פלט קר הזמן שחולף בין ההפעלה של זרם הפלט לבין זמן ההצגה של הפריים הראשון על סמך חותמות זמן, כשפלט האודיו המערכת לא הייתה פעילה והושבתה לפני הבקשה.
• זמן אחזור רציף של הפלט את זמן האחזור של הפלט במסגרות הבאות, לאחר שהמכשיר משמיע אודיו.
• זמן אחזור של קלט. המרווח בין הזמן שבו צליל מוצג של סביבה למכשיר במתמר במכשיר או אות שנכנס למכשיר דרך יציאה וכשהאפליקציה קוראת את המסגרת המתאימה של נתונים מקודדים לפי PCM.
• קלט שאבד. החלק הראשוני של אות קלט שלא ניתן לשימוש, או לא זמין.
• זמן אחזור של קלט קר משך הזמן שחולף בין התחלת השידור לבין המועד שבו מתקבלת פריים תקין ראשון, כשמערכת קלט האודיו לא פעילה הושבת לפני הבקשה.

• זמן אחזור של קלט רציף. את זמן האחזור של הקלט למסגרות הבאות, כשהמכשיר מקליט אודיו.

• זמן אחזור רציף הלוך ושוב. הסכום של זמן אחזור של קלט רציף ועוד זמן אחזור רציף של הפלט, בתוספת תקופת מאגר נתונים זמני אחת. התקופה של מאגר הנתונים הזמני מאפשרת הזמן שחולף עד שהאפליקציה תעבד את האות והזמן שבו האפליקציה תקצר את השלב ההבדל בין זרמי קלט לזרם פלט.

• OpenSL ES PCM bufferQueue API. קבוצת פריטים שקשורים ל-PCM OpenSL ES ממשקי API ב-Android NDK.

• AAudio Native Audio API. הקבוצה של ממשקי API של AAudio בתוך Android NDK.

• חותמת זמן. צמד שמכיל מיקום של מסגרת יחסי בתוך ואת הזמן המשוער שבו המסגרת נכנסת או יוצאת צינור עיבוד אודיו לעיבוד אודיו בנקודת הקצה המשויכת. עוד באותו הקשר AudioTimestamp.

• תקלה. הפרעה זמנית או ערך דגימה שגוי באות האודיו, נגרמה בדרך כלל על ידי פונקציית חוצץ תחתון לפלט, חריגה ממאגר הנתונים הזמני עבור קלט או כל מקור אחר של רעש דיגיטלי או אנלוגי.

• פירוש סטייה מוחלטת. הממוצע של הערך המוחלט של סטיות מהממוצע של קבוצת ערכים.

• זמן אחזור של נגיעה בנגיעה. משך הזמן בין הקשה על המסך לבין הזמן שבו צליל שנוצר כתוצאה מאותה הקשה שנשמעת ברמקול.

אם בהטמעות במכשירים מוצהר על android.hardware.audio.output, הן חייבים לעמוד בדרישות הבאות או לעבור אותן:

• [C-1-1] חותמת הזמן של הפלט שהוחזרה על ידי AudioTrack.getTimestamp ו-AAudioStream_getTimestamp מדויק ל- +/- 2 אלפיות השנייה.

• [C-1-2] זמן אחזור של פלט קר של 500 אלפיות השנייה או פחות.

• [C-1-3] פתיחת זרם פלט באמצעות AAudioStreamBuilder_openStream() חייבים התהליך נמשך פחות מ-1,000 אלפיות השנייה.

אם בהטמעות המכשירים מוצהר על android.hardware.audio.output הם מומלץ מאוד לעמוד בדרישות הבאות או לעבור אותן:

• [C-SR-1] זמן אחזור של פלט קר של 100 אלפיות השנייה או פחות בנתוני הרמקול נתיב.
• [C-SR-2] זמן אחזור של 80 אלפיות שנייה או פחות מהקשה לטון.

• [C-SR-4] חותמת הזמן של הפלט שהוחזרה על ידי AudioTrack.getTimestamp ו-AAudioStream_getTimestamp מדויק ל- +/- 1 אלפיות השנייה.

התחלה של דרישות חדשות

• [C-SR-4] זמני האחזור המחושבים הלוך ושוב על סמך קלט ופלט מומלץ מאוד להשתמש בחותמות זמן שהוחזרו על ידי AAudioStream_getTimestamp להיות בטווח של 30 אלפיות השנייה מזמן האחזור הנמדד הלוך ושוב עבור AAUDIO_PERFORMANCE_MODE_NONE וגם AAUDIO_PERFORMANCE_MODE_LOW_LATENCY עבור רמקולים, אוזניות חוטיות ואלחוטיות.

סיום הדרישות החדשות

אם יישומים של מכשירים עומדים בדרישות שלמעלה, לאחר כיול, בעת שימוש ב-AAudionative audio API, לפלט רציף זמן אחזור וזמן אחזור של פלט במצב התחלתי (cold start) בלפחות קטע אודיו אחד נתמך של המכשיר להצגת מידע, הם:

• [C-SR-5] מומלץ מאוד לדווח על אודיו עם זמן אחזור קצר סימון תכונה android.hardware.audio.low_latency.
• [C-SR-6] מומלץ מאוד לעמוד בדרישות לגבי זמן אחזור קצר אודיו דרך AAudio API.
• [C-SR-7] מומלץ מאוד לוודא שבשידורים שחוזרים AAUDIO_PERFORMANCE_MODE_LOW_LATENCY החל מ-AAudioStream_getPerformanceMode(), הערך המוחזר על ידי AAudioStream_getFramesPerBurst() קטן מהערך שהוחזר על ידי android.media.AudioManager.getProperty(String) או שווה לו למפתח הנכס AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

אם ההטמעות של המכשיר לא עומדות בדרישות של אודיו עם זמן אחזור קצר באמצעות ממשק ה-API של אודיו מקורי של AAudio, הן:

• [C-2-1] אסור לדווח על תמיכה באודיו עם זמן אחזור קצר.

אם ההטמעות במכשירים כוללות את android.hardware.microphone, הקלט צריך לעמוד בדרישות הבאות לגבי אודיו:

• [C-3-1] הגבלת השגיאה בחותמות הזמן של הקלט, כפי שהוחזר על ידי AudioRecord.getTimestamp או AAudioStream_getTimestamp, ל- +/- 2 ms. "שגיאה" כאן מתייחסת לסטייה מהערך הנכון.
• [C-3-2] זמן אחזור קר input של 500 אלפיות השנייה או פחות.
• [C-3-3] פתיחת זרם קלט באמצעות AAudioStreamBuilder_openStream() חייבת התהליך נמשך פחות מ-1,000 אלפיות השנייה.

אם ההטמעות במכשירים כוללות את 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 אלפיות שנייה, לפחות בנתיב נתמך אחד.

5.7. פרוטוקולי רשת

יישומי מכשירים חייבים לתמוך פרוטוקולים של רשת מדיה להפעלת אודיו ווידאו כפי שצוין במסמכי התיעוד של Android SDK.

לכל פורמט קודק ופורמט קונטיינר שצריך להטמיע במכשיר תמיכה, הטמעת המכשיר:

• [C-1-1] חייב לתמוך ב-Codec או בקונטיינר הזה ב-HTTP וב-HTTPS.

• [C-1-2] חייבת לתמוך בפורמטים המתאימים של פלחי מדיה, כפי שמוצג טבלת הפורמטים של פלחי המדיה שלמטה, פרוטוקול טיוטה של HTTP בשידור חי, גרסה 7.

• [C-1-3] חייבת לתמוך בפורמטים המתאימים של המטען הייעודי (payload) של RTSP, כפי שמוצג טבלת RTSP למטה. למקרים חריגים, מומלץ לעיין בהערות השוליים של הטבלה סעיף 5.1.

פורמטים של פלחי מדיה

פורמטים של פלחים	הפניות	נדרשת תמיכה בקודק
MPEG-2 Transport Stream	ISO 13818	קודק הווידאו: H264 AVC MPEG-4 SP MPEG-2 פרטים נוספים על H264 AVC, MPEG2-4 SP, ו-MPEG-2. קודק האודיו: קובץ AAC מידע נוסף על AAC ועל הווריאציות שלו זמין בסעיף 5.1.3.
AAC עם תגי פריים ו-ID3 של ADTS	ISO 13818-7	ראו סעיף 5.1.1 לפרטים על AAC ועל הווריאציות שלו
WebVTT	WebVTT

RTSP (RTP, SDP)

השם בפרופיל	הפניות	נדרשת תמיכה בקודק
H264 AVC	RFC 6184	ראו סעיף 5.1.8 לפרטים על H264 AVC
MP4A-LATM	RFC 6416	ראו סעיף 5.1.3 לפרטים על AAC ועל הווריאציות שלו
H263-1998	RFC 3551 RFC 4629 RFC 2190	ראו סעיף 5.1.8 לפרטים על H263
H263-2000	RFC 4629	ראו סעיף 5.1.8 לפרטים על H263
AMR	RFC 4867	ראו סעיף 5.1.3 לפרטים על AMR-NB
AMR-WB	RFC 4867	ראו סעיף 5.1.3 לפרטים על AMR-WB
MP4V-ES	RFC 6416	ראו סעיף 5.1.8 לפרטים על MPEG-4 SP
קובץ mpeg4-גנרי	RFC 3640	ראו סעיף 5.1.3 לפרטים על AAC ועל הווריאציות שלו
MP2T	RFC 2250	לפרטים נוספים, ראו MPEG-2 Transport Stream מתחת ל-HTTP Live Streaming

5.8. מדיה מאובטחת

אם בהטמעות במכשירים תומכים בפלט וידאו מאובטח ומסוגלים כלומר:

• [C-1-1] חובה להצהיר על תמיכה ב-Display.FLAG_SECURE.

אם בהטמעות מכשירים מוצהר על תמיכה ב-Display.FLAG_SECURE ותומכות פרוטוקול תצוגה אלחוטית, הם:

• [C-2-1] חייבים לקבע את הקישור באמצעות מנגנון קריפטוגרפי חזק כמו כמו HDCP 2.x ומעלה עבור מסכים שמחוברים באמצעות פרוטוקולים אלחוטיים. כמו Miracast.

אם בהטמעות המכשירים מוצהר על תמיכה ב-Display.FLAG_SECURE וב- תומכים במסך חיצוני עם חיבור קווי, הם:

• [C-3-1] חייב לתמוך ב-HDCP 1.2 ואילך בכל המסכים החיצוניים המחוברים באמצעות יציאה קווית שנגישה למשתמש.

5.9. ממשק דיגיטלי לכלים מוזיקליים (MIDI)

אם הטמעת דיווח על תמיכה בתכונה android.software.midi במכשירים דרך android.content.pm.PackageManager בכיתה, הם:

• [C-1-1] חייבת להיות תמיכה ב-MIDI בכל העברות החומרה שתומכים ב-MIDI עבור מספקות קישוריות גנרית שאינה MIDI, כאשר העברות כאלה:

  • מצב מארח USB, סעיף 7.7
  • MIDI באמצעות Bluetooth LE בתפקיד מרכזי, סעיף 7.4.3

• [C-1-2] חייבת להיות תמיכה בהעברה של תוכנות MIDI בתוך האפליקציה (מכשירי MIDI וירטואליים)

• [C-1-3] חובה לכלול את libamidi.so (תמיכה מובנית ב-MIDI)

• צריכה להיות תמיכה ב-MIDI במצב של ציוד היקפי בחיבור USB, סעיף 7.7

5.10. אודיו מקצועי

אם יישומים של מכשירים מדווחים על תמיכה בתכונה android.hardware.audio.pro דרך android.content.pm.PackageManager בכיתה, הם:

• [C-1-1] חובה לדווח על תמיכה בתכונה android.hardware.audio.low_latency
• [C-1-2] חייב להיות זמן אחזור רציף הלוך ושוב של האודיו, כפי שמוגדר ב- סעיף 5.6 זמן אחזור אודיו של 25 אלפיות השנייה לכל היותר לפחות בנתיב נתמך אחד.
• [C-1-3] חייבות לכלול יציאות USB שתומכות במצב מארח USB וב-USB מצב ציוד היקפי.
• [C-1-4] חובה לדווח על תמיכה בתכונה android.software.midi.
• [C-1-5] חייב לעמוד בדרישות זמן האחזור ובדרישות האודיו ב-USB באמצעות אודיו מותאם לאודיו API ו-AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
• [C-1-6] זמן האחזור של הפלט במצב התחלתי חייב להיות 200 אלפיות השנייה או פחות.
• [C-1-7] זמן האחזור של קלט קר חייב להיות 200 אלפיות השנייה או פחות.

• [C-1-8] זמן האחזור הממוצע של 'הקשה לטון' חייב להיות 80 אלפיות השנייה או פחות לפחות 5 מדידות לאורך נתיב הנתונים של הדובר למיקרופון.

• [C-SR-1] מומלץ מאוד לעמוד בזמני אחזור כפי שהוגדרו בסעיף זמן אחזור של אודיו 5.6, של 20 אלפיות השנייה או פחות, יותר מ-5 מדידות עם סטייה אבסולוטית ממוצעת של פחות מ-5 אלפיות שנייה מעל הנתיב בין הדובר למיקרופון.

• [C-SR-2] מומלץ מאוד לעמוד בדרישות של Pro Audio עבור זמן אחזור אודיו דו-כיווני רציף, זמן אחזור של קלט קר ופלט קר הדרישות לגבי זמן אחזור ואודיו ב-USB באמצעות ה-API של AAudio native audio מעל נתיב ה-MMAP.

• [C-SR-3] מומלץ מאוד לספק רמה עקבית של מעבד (CPU) ביצועים כשהאודיו פעיל והעומס על המעבד (CPU) משתנה. צריך לבדוק את זה באמצעות האפליקציה SynthMark ל-Android. SynthMark משתמש בסינתיסייזר תוכנה שפועל על פריים מדומה של אודיו שמודדים את ביצועי המערכת. לצפייה מסמכי תיעוד של SynthMark כדי לקבל הסבר על נקודות ההשוואה. סימן SynthMark צריך להריץ את האפליקציה באמצעות בוחרים באפשרות 'בדיקה אוטומטית' ומקבלים את התוצאות הבאות:

  • voicemark.90 >= 32 קולות
  • durationmark.fixed.little <= 15 מילי-שניות
  • durationmark.dynamic.little <= 50 מילי-שניות

• אמור לצמצם את אי הדיוק של שעון האודיו וסחף ביחס לזמן הסטנדרטי.

• צריך לצמצם את הסחף של שעון האודיו ביחס למעבד (CPU) CLOCK_MONOTONIC כששניהם פעילים.

• זה אמור לצמצם את זמן האחזור של האודיו במתמרים ששמורים במכשיר.

• יש לצמצם את זמן האחזור של האודיו באודיו דיגיטלי בחיבור USB.

• צריך לתעד את המדידות של זמן האחזור של האודיו בכל הנתיבים.

• אמורה לצמצם את הרעידות בזמני הכניסה של הקריאה החוזרת להשלמת מאגר האודיו של האודיו, כי משפיעה על האחוז השימושי של רוחב הפס המלא במעבד (CPU) על ידי הקריאה החוזרת (callback).

• השימוש הרגיל אמור לספק אפס תקלות אודיו בזמן האחזור המדווח.

• אמורה לספק הפרש בין זמן האחזור בין הערוצים.

• זמן האחזור הממוצע של MIDI אמור לצמצם את זמן האחזור בכל אמצעי התחבורה.

• צריכה לצמצם את השונות של זמן האחזור של MIDI בעומס (רעידות) בכל ההעברות.

• צריכה לספק חותמות זמן מדויקות לשימוש ב-MIDI בכל אמצעי התחבורה.

• צריכה למזער את הרעש של אות האודיו במתמרים במכשיר, כולל מיד לאחר ההפעלה במצב התחלתי (cold start).

• אמור להיות אפס הבדל בשעון האודיו בין צד הקלט לצדדים של הפלט נקודות הקצה התואמות, כששתיהן פעילות. דוגמאות לתאימות נקודות הקצה (endpoints) כוללות את המיקרופון והרמקול במכשיר או את הקלט של שקע האודיו ופלט.

• צריכה לטפל בקריאות חוזרות (callback) של השלמת מאגר הנתונים הזמני של הקלט ופלט נקודות הקצה המקבילות באותו שרשור כששתיהן פעילות, ומזינים הקריאה החוזרת של הפלט מיד אחרי החזרה מהקריאה החוזרת של הקלט. או אם לא ניתן לטפל בקריאות החוזרות (callback) באותו שרשור, יש להזין את פלט קריאה חוזרת (callback) זמן קצר לאחר הזנת הקריאה החוזרת של הקלט כדי לאפשר כך שיהיה תזמון עקבי של צד הקלט והפלט.

• אמור לצמצם את הפרש המופעים בין אגירת אודיו של HAL בקלט ואת צדי הפלט של נקודות הקצה התואמות.

• צריכה למזער את זמן האחזור של המגע.

• צריכה למזער את ההשתנות של זמן האחזור של המגע במקרה של עומס (רעידות).

אם ההטמעות של מכשירים עומדות בכל הדרישות שפורטו למעלה, הן:

• [C-SR-4] מומלץ מאוד לדווח על תמיכה בתכונה android.hardware.audio.pro דרך android.content.pm.PackageManager בכיתה.

אם בהטמעות המכשיר יש שקע אודיו עם 4 מוליכים בגודל 3.5 מ"מ, הן:

• [C-2-1] חייבת להיות זמן אחזור ממוצע של אודיו הלוך ושוב ברציף, כפי שמוגדר ב- קטע 5.6 זמן אחזור אודיו, של 20 אלפיות שנייה או פחות, יותר מ-5 מדידות עם סטייה אבסולוטית ממוצעת של פחות מ-5 אלפיות השנייה את הנתיב של שקע האודיו באמצעות מתאם אודיו בלופ.

• [C-SR-5] מומלץ מאוד לציית לציות קטע בנושא מפרטי מכשיר נייד (שקע) של מפרט אוזניות אודיו חוטיות (גרסה 1.1).

אם בהטמעות המכשיר משמיטים שקע אודיו של 4 מוליך בגודל 3.5 מ"מ וגם כוללות יציאות USB שתומכות במצב מארח USB, והן:

• [C-3-1] חובה להטמיע את סיווג האודיו ב-USB.
• [C-3-2] זמן האחזור הממוצע של אודיו הלוך ושוב ברציפות הוא רציף 25 אלפיות השנייה או פחות, יותר מ-5 מדידות עם סטייה אבסולוטית ממוצעת פחות מ-5 אלפיות השנייה מהיציאה של מצב מארח ב-USB באמצעות סיווג אודיו ב-USB. (ניתן למדוד זאת באמצעות מתאם USB-3.5 מ"מ ורמקול עם לולאה חוזרת (loopback) מתאם או שימוש בממשק אודיו ב-USB עם כבלי תיקון שמחברים את של הקלט לפלט).
• [C-SR-6] מומלץ מאוד לתמוך בקלט/פלט (I/O) בו-זמנית בעד 8 ערוצים כל כיוון, תדירות דגימה של 96kHz ועומק של 24 ביט או 32 ביט עם ציוד היקפי בחיבור USB שתומך גם בדרישות האלה.
• [C-SR-7] מומלץ מאוד לעמוד בקבוצת הדרישות הזו בעזרת ממשק ה-API של אודיו מקורי של אודיו דרך נתיב ה-MMAP.

אם בהטמעות במכשירים יש יציאת HDMI:

• אמורה לתמוך בפלט בסטריאו ובשמונה ערוצים במהירות של 20 סיביות עומק של 24 ביט ו-192kHz ללא אובדן או דגימה מחדש של עומק הסיביות בהגדרה אחת לפחות.

5.11. צילום למכשירים לא מעובדים

Android כולל תמיכה בהקלטת אודיו לא מעובד באמצעות מקור האודיו android.media.MediaRecorder.AudioSource.UNPROCESSED. לחשבון OpenSL ES, ניתן לגשת אליה באמצעות ההגדרה הקבועה מראש של הרשומה SL_ANDROID_RECORDING_PRESET_UNPROCESSED

אם המכשיר מיישם הכוונה לתמוך במקור אודיו לא מעובד ולהבטיח לאפליקציות צד שלישי, הן:

• [C-1-1] חובה לדווח על התמיכה דרך android.media.AudioManager נכס PROPERTY_SUPPORT_AUDIO_SOURCE_UNProcessED.

• [C-1-2] חובה להציג תדירות של משרעת (אמפליטודה) שטוחה (לעומת זאת) בערך מאפיינים בטווח התדרים הבינוני: במיוחד ±10 dB החל 100 Hz עד 7,000 Hz לכל מיקרופון שמשמש להקלטת מקור האודיו.

• [C-1-3] חובה להציג את רמות המשרעת בתדר הנמוך טווח: במיוחד בין ±20dB מ-5 z עד 100 Hz בהשוואה טווח התדרים עבור כל מיקרופון שמשמש להקלטת מקור אודיו שלא עבר עיבוד.

• [C-1-4] חייבים להציג את רמות המשרעת בתדירות גבוהה טווח: במיוחד בין ±30dB מ-7,000 Hz עד 22 KHz, בהשוואה טווח התדרים עבור כל מיקרופון שמשמש להקלטת מקור אודיו שלא עבר עיבוד.

• [C-1-5] חובה להגדיר את הרגישות לקלט האודיו, כך מקור הצליל שמושמע בעוצמה של 94 דציבלים ברמת לחץ הקול (SPL) מניב תגובה עם RMS של 520 לדגימות של 16 ביט (או -36 dB התאמה מלאה לנקודה צפה/כפולה לספק דגימות דיוק) לכל מיקרופון שמשמש להקלטת מקור האודיו.

• [C-1-6] חייב להיות יחס אות לרעש (SNR) ב-60 דציבלים ומעלה עבור כל מיקרופון שמשמש להקלטת מקור האודיו הלא מעובד. (בעוד ש-SNR נמדדת כהפרש בין 94 dB SPL לבין המקבילה SPL של רעש עצמי, שקלול A).

• [C-1-7] הערך של עיוות הרמוני (THD) חייב להיות קטן מ- 1% עבור 1 kHZ ברמת קלט של 90 dB SPL בכל מיקרופון שנעשה בו שימוש להקליט את מקור האודיו הלא מעובד.

• [C-1-8] אסור שיהיה עיבוד אותות אחר (למשל, רווח אוטומטי שליטה, מסנן High Pass או ביטול הד) בנתיב שאינו ברמה הרצויה כדי להעלות את הרמה לטווח הרצוי. במילים אחרות:

  • [C-1-9] אם קיים בארכיטקטורה עיבוד אותות כלשהו מסיבה זו, חייבים להשבית אותו ולהציג באופן אפקטיבי אפס עיכוב זמן אחזור נוסף לנתיב האות.
  • [C-1-10] מכפיל הרמות, אף על פי שהוא מותר בנתיב, אסור הוספת עיכוב או זמן אחזור בנתיב האות.

כל מדידות ה-SPL מתבצעות ישירות ליד המיקרופון בבדיקה. הדרישות האלה חלות על כמה הגדרות מיקרופון בכל מיקרופון.

אם בהטמעות המכשיר מוצהר על android.hardware.microphone אבל לא תומכים במקור אודיו לא מעובד, הם:

• [C-2-1] חייב להחזיר null לAudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API, כדי לציין כראוי את היעדר התמיכה.
• [C-SR-1] עדיין מומלץ מאוד למלא כמה שיותר מהדרישות לנתיב האות של מקור ההקלטה שלא עבר עיבוד.

5.12. סרטון HDR

ב-Android 13 יש תמיכה בטכנולוגיות HDR, כפי שמתואר במסמך שיפורסם בקרוב.

פורמט הפיקסלים

אם מפענח וידאו מפרסם תמיכה ב-color_FormatYUVP010:

• [C-1-1] חייבת לתמוך בפורמט P010 לקריאת מעבד (CPU) (ImageReader, MediaImage, ). ב-Android 13, P010 פועל בצורה רגועה כדי לאפשר צעדים שרירותיים עבור ה-Y ומתקני קרינת UV.

• [C-1-2] חובה לאפשר ל-GPU לדגום את מאגר הפלט של P010 (כאשר שהוקצה עם שימוש ב-GPU_SAMPLING). כך מתאפשרת הרכבה של GPU והתאמה אישית למיפוי טונים של אפליקציות.

אם מפענח וידאו מפרסם תמיכה ב-COLOR_Format32bitABGR2101010, הוא:

• [C-2-1] חייבת לתמוך בפורמט RGBA_1010102 לשטח הפלט קריא למעבד (CPU) (פלט ByteBuffer).

אם מקודד וידאו מפרסם תמיכה ב-COLOR_FormatYUVP010, הוא:

• [C-3-1] חייבת להיות תמיכה בפורמט P010 למשטח קלט ולניתנת לכתיבה באמצעות מעבד (CPU) קלט (ImageWriter, MediaImage, ByteBuffer).

הערה: ב-Android 13, מודל P010 רגוע כדי לאפשר צעדים שרירותיים את מישורי Y ו-UV. (ייתכן שפורמט P010 זה יעבור אופטימיזציה ושונה פורמט Camera2 P010.)

אם מקודד וידאו מפרסם תמיכה ב-COLOR_Format32bitABGR2101010, הוא:

• [C-4-1] חייב לתמוך בפורמט RGBA_1010102 עבור משטח קלט ומעבד (CPU) שניתן לכתיבה קלט (ImageWriter, ByteBuffer). הערה: המרה בין סוגים שונים של העברות במקודדים אין צורך בעקומות.

דרישות לצילום HDR

בכל מקודדי הווידאו שתומכים בפרופילים של HDR:

• [C-5-1] אסור להניח שהמטא-נתונים של HDR מדויקים. לדוגמה, במסגרת המקודדת יכולים להיות פיקסלים מעבר לרמת ההארה המקסימלית, או ייתכן שההיסטוגרמה לא מייצגת את המסגרת.

• צריך לצבור מטא-נתונים דינמיים של HDR כדי ליצור נתונים סטטיים מתאימים של HDR מטא-נתונים עבור שידורים מקודדים, והפלט צריך להיות בסוף כל בהפעלת הקידוד.

אם בהטמעות של המכשיר יש תמיכה בצילום HDR באמצעות ממשקי ה-API של CamcorderProfile ואז:

• [C-6-1] חייבת להיות תמיכה בצילום תמונות HDR גם דרך ממשקי ה-API של Camera2.

• [C-6-2] חייב לתמוך לפחות במקודד וידאו אחד עם שיפור מהירות באמצעות חומרה עבור כל טכנולוגיית HDR שנתמכת.

• [C-6-3] חייבת להיות תמיכה (לכל הפחות) בצילום בפורמט HLG.

• [C-6-4] חייבת להיות תמיכה בכתיבת המטא-נתונים של HDR (אם רלוונטי ל-HDR) טכנולוגית) לקובץ הווידאו שתועד. ל-AV1, ל-HEVC ול-DolbyVision כלומר, כוללים את המטא-נתונים בסטרימינג הביטים המקודד.

• [C-6-5] חייבת לתמוך ב-P010 וב-COLOR_FormatYUVP010.

• [C-6-6] כברירת מחדל חייבת להיות תמיכה ב-HDR למיפוי גוונים של SDR למפענח עם שיפור מהירות באמצעות חומרה לפרופיל שתועד. במילים אחרות, אם מכשיר יכול לצלם HDR10+ HEVC, מפענח HEVC שמוגדר כברירת מחדל חייב להיות מסוגל כדי לפענח את השידור שתועד ב-SDR.

דרישות לעריכת HDR

אם ההטמעות במכשירים כוללים מקודדי וידאו שתומכים בעריכת HDR, הם:

• יש להשתמש בזמן אחזור מינימלי ליצירת מטא-נתונים של HDR כשהם לא נמצאים, והם צריכים לטפל באלגנטיות במצבים שבהם המטא-נתונים קיימים של מודלים אחרים ולא עבור אחרים. המטא-נתונים צריכים להיות מדויקים (לדוגמה, שמייצגים את רמת הבהירות וההיסטוגרמה בפועל של המסגרת).

אם הטמעת המכשיר כוללת רכיבי קודק שתומכים ב-FEATURE_HdrEditing, אז את רכיבי הקודק האלה:

• [C-7-1] חייב לתמוך בפרופיל HDR אחד לפחות.

• [C-7-2] חובה לתמוך ב-FEATURE_HdrEditing בכל פרופילי HDR שפורסמו על ידי את הקודק הזה. במילים אחרות, הם חייבים לתמוך ביצירת מטא-נתונים של HDR לא קיים בכל פרופילי HDR הנתמכים שמשתמשים במטא-נתונים של HDR.

• [C-7-3] חייב לתמוך בפורמטים הבאים של קלט מקודד וידאו, משמרים את האות המפוענח ל-HDR:

  • RGBA_1010102 (כבר בעקומת העברת היעד) לשני הקלט ו-ByteBuffer ו-ByteBuffer חייבות לפרסם תמיכה עבור Color_Format32bitABGR2101010.

אם הטמעת המכשיר כוללת רכיבי קודק שתומכים ב-FEATURE_HdrEditing, אז המכשיר:

• [C-7-4] חובה לפרסם תמיכה לתוסף OpenGL מסוג EXT_YUV_target.

6. תאימות לכלים למפתחים ולאפשרויות

6.1. כלים למפתחים

הטמעות מכשירים:

• [C-0-1] חייבת לתמוך בכלים למפתחי Android שמסופקים ב-Android SDK.

• גשר לניפוי באגים ב-Android (adb)

  • [C-0-2] חייבת לתמוך ב-adb כפי שמתועד ב-Android SDK ובמעטפת ב-AOSP, שיכולות לשמש מפתחי אפליקציות כולל dumpsys cmd stats
  • [C-0-11] חייבת לתמוך בפקודת המעטפת cmd testharness. מתבצע שדרוג במכשירים מגרסה קודמת של Android ללא ייתכן שחסימת נתונים מתמידים תהיה פטורה מקוד C-0-11.
  • [C-0-3] אסור לשנות את הפורמט או את התוכן של מערכת המכשיר אירועים (batterystats , דיסקסטטים, טביעת אצבע, גרפיקה סטטיסטיים, netstats, התראה, Procstats) שתועדה באמצעות הפקודה dumpsys.
  • [C-0-10] חובה להקליט, ללא השמטת נתונים, ולבצע את האירועים הבאים וזמין לפקודת המעטפת cmd stats StatsManager מחלקה של System API.
    • הפעילות בחזית שונתה
    • זוהתה חריגה
    • נשלח דיווח על נתיבי ניווט ב-AppB
    • AppCrashOccurred
    • AppStartOccurred
    • רמת הסוללה שונתה
    • הסוללהSaverModeStateChanged
    • BleScanresultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged (שינוי מצב המשימה)
    • PluggedStateChanged
    • משימות מתוזמנות
    • ScreenState השתנה
    • SyncStateChanged
    • זמן אמת ב-SystemElapse
    • UidProcessStateChanged
    • מצב WakelockState השתנה
    • מעורר התעוררות
    • מצב Wi-FiLockState השתנה
    • WifiMulticastLockStateChange
    • מצב WifiScanState השתנה
  • [C-0-4] דימון (daemon) בצד המכשיר חייב להיות לא פעיל כברירת מחדל כדי להפעיל את ניפוי הבאגים ב-Android חייב להיות מנגנון נגיש למשתמש גשר.
  • [C-0-5] חייבת לתמוך ב-adb מאובטח. Android כולל תמיכה באבטחה adb. פרוטוקול adb מאובטח מאפשר הפעלה של adb במארחים מאומתים מוכרים.
  • [C-0-6] חייב לספק מנגנון שמאפשר לחבר את adb במחשב המארח. פרטים נוספים:

  אם הטמעות של מכשירים ללא יציאת USB תומכות במצב היקפי:

  • [C-3-1] חובה להטמיע adb באמצעות רשת מקומית (כמו אתרנט) או Wi-Fi).
  • [C-3-2] חובה לספק מנהלי התקנים עבור Windows 7, Windows 8 ו-10, כדי לאפשר למפתחים להתחבר למכשיר באמצעות פרוטוקול adb.

  אם בהטמעות של מכשירים יש תמיכה בחיבורי adb למכונה מארחת דרך ב-Wi-Fi או באתרנט, הן:

  • [C-4-1] חייבים להשתמש בשיטה AdbManager#isAdbWifiSupported() החזרה true.

  אם בהטמעות של מכשירים יש תמיכה בחיבורי adb למכונה מארחת דרך Wi-Fi או אתרנט, וכן כולל מצלמה אחת לפחות, הם:

  • [C-5-1] חייבת להשתמש בשיטה AdbManager#isAdbWifiQrSupported() החזרה true.

• Dalvik Debug Monitor Service (ddms)

  • [C-0-7] חייבת להיות תמיכה בכל תכונות ה-ddms כפי שמתואר ב-Android SDK. מכיוון ש-ddms משתמשים ב-adb, התמיכה ב-ddms אמורה להיות לא פעילה כברירת מחדל, אבל חייבת להיות תמיכה בכל פעם שהמשתמש הפעיל את ממשק ה-Fגשר של Android לניפוי באגים, כמתואר למעלה.

• SysTrace

  • [C-0-9] חייבת לתמוך בכלי ה-systrace כפי שתועד ב-Android SDK. Systrace חייבת להיות לא פעילה כברירת מחדל וחייב להיות נגיש למשתמש מנגנון להפעלת Systrace.

• Perfetto

  • [C-SR-1] מומלץ מאוד לחשוף /system/bin/perfetto בינארית למשתמש המעטפת ש-cmdline פועל את התיעוד של Perfetto.
  • [C-SR-2] מומלץ מאוד לקבל את הקובץ הבינארי שמוגדר כקלט תצורת protobuf שתואמת לסכימה שמוגדרת ואת מסמכי התיעוד.
  • [C-SR-3] מומלץ מאוד לכתוב את הקוד הבינארי שמוגדר כפלט מעקב Protobuf התואם לסכימה המוגדרת ואת מסמכי התיעוד.
  • [C-SR-4] מומלץ מאוד לספק באמצעות הקובץ הבינארי Perfetto, לפחות את מקורות הנתונים שמתוארים בתיעוד Perfetto.

• עומק זיכרון נמוך

  • [C-0-12] חובה לכתוב Atom מסוג LMK_KILL_OCCURRED_FIELD_NUMBER רישום נתונים סטטיסטיים כשאפליקציה מסתיימת על ידי Low Memory Killer.

• מצב 'מסגרת בדיקה' אם הטמעות המכשיר תומכות בפקודת המעטפת cmd testharness ו- להריץ את cmd testharness enable,

  • [C-2-1] חייב להחזיר true למשך ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] חובה להטמיע את מצב 'מסגרת בדיקה' כמו שמתואר מסמכי התיעוד של מצב 'מסגרת בדיקה'.

• מידע על העבודה של GPU

  הטמעות מכשירים:

  • [C-0-13] חובה להטמיע את פקודת המעטפת dumpsys gpu --gpuwork כדי להציג נתוני העבודה המצטברים של ה-GPU שהוחזרו על ידי הליבה (kernel) של power/gpu_work_period לעקוב אחרי נקודת המעקב, או שלא להציג נתונים אם נקודת המעקב לא נתמכת. ה-AOSP היא frameworks/native/services/gpuservice/gpuwork/.

אם יישומים של מכשירים ידווחו על תמיכה ב-Vulkan 1.0 ואילך דרך android.hardware.vulkan.version דגלי תכונות, הם:

• [C-1-1] חובה לספק למפתחי האפליקציות אפשרות להפעיל או להשבית את האפליקציה שכבות ניפוי באגים של GPU.
• [C-1-2] חובה, כששכבות ניפוי הבאגים של ה-GPU מופעלות, ספירת השכבות היא ספריות שסופקו על ידי כלים חיצוניים (כלומר, לא חלק מהפלטפורמה או 'חבילת אפליקציה') נמצאה באפליקציות שניתנות לניפוי באגים ליצור ספרייה בסיסית של תמיכה ב-vkEnumerateInstanceLayerProperties() ו-vkCreateInstance() שיטות API.

6.2. אפשרויות למפתחים

Android כולל תמיכה במפתחים להגדרת אפליקציה שקשורות לפיתוח.

הטמעת מכשירים חייבת לספק חוויה עקבית אפשרויות למפתחים:

• [C-0-1] חייבים לכבד את android.settings.APPLICATION_DEVELOPMENT_SETTINGS כוונה להציג הגדרות שקשורות לפיתוח של אפליקציות. Android בהמשך הדרך מסתיר את תפריט 'אפשרויות למפתחים' כברירת מחדל ומאפשר למשתמשים להפעיל את 'אפשרויות למפתחים' אחרי לחיצה שבע (7) פעמים בתפריט Settings (הגדרות) > מידע על המכשיר > האפשרות מספר Build בתפריט.
• [C-0-2] חובה להסתיר את 'אפשרויות למפתחים' כברירת מחדל.
• [C-0-3] חייב לספק מנגנון ברור שלא נותן העדפה טיפול באפליקציה אחת של צד שלישי בניגוד לאפליקציה אחרת כדי לאפשר למפתח אפשרויות. חייבים לספק מסמך או אתר גלויים לכולם שמתארים איך להפעיל את 'אפשרויות למפתחים'. חובה לאפשר קישור למסמך או לאתר הזה מ- מסמכי Android SDK.
• צריכה להיות התראה ויזואלית מתמשכת למשתמש כשהמפתח האפשרויות מופעלות ויש חשש לגבי אבטחת המשתמש.
• ייתכן שנגביל באופן זמני את הגישה לתפריט 'אפשרויות למפתחים', באופן חזותי להסתיר או להשבית את התפריט, כדי למנוע הסחות דעת במקרים שבהם בטיחות המשתמש.

7. תאימות חומרה

אם המכשיר כולל רכיב חומרה מסוים שיש לו API למפתחים של צד שלישי:

• [C-0-1] הטמעת המכשיר חייבת להטמיע API כפי שמתואר בתיעוד של Android SDK.

אם מדובר בממשק API ב-SDK מקיים אינטראקציה עם רכיב חומרה שמצוין לגביו שהוא אופציונלי המכשיר לא כולל את הרכיב הזה:

• [C-0-2] צריך למלא את הגדרות הכיתה (כפי שמתועד על ידי ה-SDK) של הרכיב ממשקי API עדיין חייבים להיות מוצגים.
• [C-0-3] חובה להטמיע את ההתנהגויות של ה-API כפעולות ללא תפעול אופנה.
• [C-0-4] שיטות API חייבות להחזיר ערכי null כאשר ה-SDK מאפשר זאת התיעוד.
• [C-0-5] שיטות API חייבות להחזיר הטמעות ללא תפעול של מחלקות שבהן ערכי null אסורים לשימוש במסמכי התיעוד של ה-SDK.
• [C-0-6] שיטות API לא יכולות להקפיץ חריגות שלא תועדו על ידי ה-SDK התיעוד.
• [C-0-7] הטמעות של מכשירים חייבות לדווח באופן עקבי על חומרה מדויקת הגדרות אישיות דרך getSystemAvailableFeatures() hasSystemFeature(String) ב- android.content.pm.PackageManager לאותה טביעת אצבע של build.

דוגמה אופיינית לתרחיש שבו הדרישות האלה חלות: מערכת טלפוניה API: גם במכשירים שאינם טלפונים, יש להטמיע את ממשקי ה-API באופן סביר אין תפעול.

7.1. תצוגה וגרפיקה

ב-Android יש מתקנים שמתאימים באופן אוטומטי נכסי אפליקציות וממשק משתמש המתאימה למכשיר כדי להבטיח שאפליקציות של צד שלישי פועלות בצורה תקינה במגוון תצורות חומרה. מגוון של צגי חומרה והגדרות אישיות. מסך התואם ל-Android הוא מסך תצוגה שמטמיע את כל התנהגויות וממשקי API שמתוארים במאמר מפתחי Android – תאימות למסכים סקירה כללית, (7.1) וסעיפי המשנה שלו, וגם כל סוג מכשיר נוסף וההתנהגויות הספציפיות שמפורטות בקטע 2 CDD. במסכים התואמים ל-Android שבהם כל המוצרים של צד שלישי תואמים ל-Android אפליקציות יכולות לפעול, הטמעות מכשירים חייבות להטמיע את ממשקי ה-API האלה באופן תקין והתנהגויות, כפי שמפורט בקטע הזה.

התחלה של דרישות חדשות

הטמעות מכשירים:

• [C-0-1] חובה, כברירת מחדל, לעבד אפליקציות של צד שלישי רק מסכים שתואמים ל-Android.

סיום הדרישות החדשות

היחידות שמוזכרות בדרישות בסעיף הזה מוגדרות כך:

• גודל אלכסון פיזי. המרחק באינצ'ים בין שני צבעים מנוגדים הפינות של החלק המואר של המסך.
• נקודות לאינץ' (dpi)צפיפות. מספר הפיקסלים המוקפים על ידי קו ליניארי טווח אופקי או אנכי של 1 אינץ', מבוטא כפיקסלים לאינץ' (PPI או dpi). כאשר dpi מוצגים ערכי PPI ו-DPI, גם DPI אנכי וגם DPI חייבים להיכלל בתוך המפורט טווח.
• יחס גובה-רוחב. היחס בין הפיקסלים של המימד הארוך יותר מידות קצרות יותר של המסך. לדוגמה, תצוגה של 480x854 פיקסלים להיות 854/480 = 1.779, או בערך 16:9.
• פיקסל בלתי תלוי בדחיסות (dp). ה יחידת פיקסל וירטואלי A מנורמל למסך של 160 DPI דחיסות מסך של 160. עבור צפיפות מסוימת של d, ומספר של פיקסלים p, מספר הפיקסלים הבלתי תלויים בדחיסות dp, הוא מחושב כך: pixels = dps * (density/160) dp = (160 / d) * p .

7.1.1. הגדרת המסך

7.1.1.1. הגודל והצורה של המסך

ה-framework של ממשק המשתמש של Android תומך במגוון של פריסת מסך לוגית גדולים, ומאפשר לאפליקציות לשלוח שאילתות על המסך של התצורה הנוכחית גודל הפריסה דרך Configuration.screenLayout עם SCREENLAYOUT_SIZE_MASK ו-Configuration.smallestScreenWidthDp.

הטמעות מכשירים:

• [C-0-1] חובה לדווח על גודל הפריסה הנכון Configuration.screenLayout כפי שמוגדר במסמכי התיעוד של Android SDK. באופן ספציפי, הטמעות במכשירים חייבות לדווח על הלוגיקה הנכונה מידות המסך של פיקסלים שלא תלויים בדחיסות (dp) כפי שמפורט בהמשך:

  • מכשירים שבהם מוגדר Configuration.uiMode בתור כל ערך מלבד UI_מצב_TYPE_WATCH, ודיווח על גודל small עבור Configuration.screenLayout, חייב להיות לפחות 426 dp x 320 dp.
  • מכשירים שמדווחים על גודל של normal עבור Configuration.screenLayout, חייבת להיות לפחות 480 dp x 320 dp.
  • מכשירים שמדווחים על גודל של large עבור Configuration.screenLayout, חייב להיות לפחות 640 dp x 480 dp.
  • מכשירים שמדווחים על גודל של xlarge עבור Configuration.screenLayout, חייב להיות לפחות 960 dp x 720 dp.

• [C-0-2] חובה לציית בצורה נכונה לבקשות מוצהר תמיכה בגדלי מסכים באמצעות <supports-screens> בקובץ AndroidManifest.xml, כפי שמתואר בתיעוד של Android SDK.

• ב-MAY יש מסכים שתואמים ל-Android עם פינות מעוגלות.

אם בהטמעות במכשירים יש תמיכה במסכים שתומכים ב- UI_MODE_TYPE_NORMAL הגדרות גודל וכוללות תאימות ל-Android להשתמש במסכים פיזיים עם פינות מעוגלות כדי לעבד את המסכים האלה, הם:

• [C-1-1] חובה לוודא שלפחות אחת מהדרישות הבאות מתקיים בכל תצוגה כזו:

  • הרדיוס של הפינות המעוגלות קטן מ-38dp או שווה לו.
  • כאשר a 15ואז 18 dp עד 1518 תיבת dp מעוגנת בכל פינה של התצוגה הלוגית, לפחות הפיקסל של כל תיבה מופיע במסך.

• צריכה לכלול את התקציב של המשתמש לעבור למצב תצוגה עם פינות מלבניות.

התחלה של דרישות חדשות

אם אפשר ליישם במכשירים רק אפשרות של הגדרת מקלדת NO_KEYS, והם מתכוונים לדווח על תמיכה במצב ממשק המשתמש של UI_MODE_TYPE_NORMAL שלהם:

• [C-4-1] גודל הפריסה חייב להיות לפחות לא כולל גזירי מסך 596 dp x 384 dp או יותר.

סיום הדרישות החדשות

אם ההטמעות במכשירים כוללים מסכים שתואמים ל-Android מתקפל, או כולל ציר מתקפל בין כמה חלוניות תצוגה במסכים שזמינים לעיבוד אפליקציות צד שלישי:

• [C-2-1] חובה להטמיע את הגרסה היציבה והעדכנית ביותר של ב-extensions API או את הגרסה היציבה של sidecar API לשימוש בספרייה Window Manager Jetpack.

אם ההטמעות במכשירים כוללים מסכים שתואמים ל-Android מתקפל, או כולל ציר מתקפל בין מספר חלוניות תצוגה, שהציר או הקפל חוצה חלון אפליקציה במסך מלא, ואז:

• [C-3-1] חובה לדווח על המיקום, הגבולות והמצב של הציר או הקיפול או ממשקי API חיצוניים לאפליקציה.

לפרטים על הטמעה נכונה של ממשקי ה-API המשניים או של התוספים, קראו את המאמר למסמכי התיעוד הציבוריים של Window Manager Jetpack.

התחלה של דרישות חדשות

אם ההטמעות במכשירים כוללות אזור תצוגה אחד או יותר שתואם ל-Android שניתן לקפל, או לכלול ציר מתקפל בין מכשירים אזורי תצוגה שתואמים ל-Android והפיכת אזורי התצוגה לזמינים עבור אפליקציות, הן:

• [C-4-1] חובה להטמיע את הגרסה הנכונה של התוספים לניהול חלונות רמת ה-API, כפי שמתואר בתוספים של Windows Manager.

סיום הדרישות החדשות

7.1.1.2. יחס גובה-רוחב של המסך

אין הגבלה על יחס הגובה-רוחב של המסך הפיזי מסכים שתואמים ל-Android, יחס הגובה-רוחב של המסך הלוגי שבו מתבצע עיבוד של אפליקציות צד שלישי, שהנגזרה שלהן עשויה להיות נגזרת מהגובה ערכי הרוחב מדווחים באמצעות הפרמטר view.Display ממשקי API והגדרות אישיות ממשקי API חייבים לעמוד בדרישות הבאות:

• [C-0-1] הטמעות במכשירים שבהם Configuration.uiMode מוגדר לערך הערך של יחס הגובה-רוחב של UI_MODE_TYPE_NORMAL חייב להיות קטן או שווה ל-1.86 (בערך 16:9), אלא אם האפליקציה עומדת באחד מהתנאים הבאים תנאים:

  • האפליקציה הצהירה שהיא תומכת ביחס גובה-רוחב של מסך גדול יותר דרך android.max_aspect של מטא-נתונים.
  • האפליקציה מצהירה שניתן לשנות את גודלה דרך android:resizeableActivity .
  • האפליקציה מטרגטת רמת API 24 ומעלה ולא מוצהרת עליה רמה android:maxAspectRatio דבר שיגביל את יחס הגובה-רוחב המותר.

• [C-0-3] הטמעות במכשירים שבהם Configuration.uiMode מוגדר בתור הערך של יחס הגובה-רוחב של UI_MODE_TYPE_WATCH חייב להיות 1.0 (1:1).

7.1.1.3. דחיסות מסך

מסגרת ממשק המשתמש של Android מגדירה קבוצה של דחיסות לוגיות סטנדרטיות כדי לסייע מפתחי אפליקציות מטרגטים משאבי אפליקציות.

הטמעות מכשירים:

• [C-0-1] כברירת מחדל, הטמעות במכשירים חייבים לדווח רק על אחד צפיפות המסגרת של Android שרשומה ברשימה DisplayMetrics באמצעות DENSITY_DEVICE_STABLE API והערך הזה חייב להיות סטטי לכל תצוגה פיזית. אסור לשנות בשום שלב; עם זאת, עם זאת המכשיר עשוי לדווח על צפיפות שרירותית שונה DisplayMetrics.density בהתאם לשינויים בתצורת התצוגה שהמשתמש ביצע (עבור לדוגמה, גודל התצוגה) שהוגדר לאחר האתחול הראשוני.

• יישומים של מכשירים צריכים להגדיר את צפיפות המסגרת הסטנדרטית של Android שהוא הקרוב ביותר מבחינת מספר הצפיפות הפיזית של המסך, אלא אם צפיפות לוגית דוחפת את גודל המסך המדווח מתחת למינימום הנתמך. אם המיקום דחיסות המסגרת הרגילה של Android שהיא הקרובה ביותר מבחינה מספרית הצפיפות הפיזית מובילה לגודל המסך הקטן ביותר מהקטן ביותר גודל מסך תואם נתמך (ברוחב 320dp), יישומי מכשיר צריכים לדווח על צפיפות המסגרת הרגילה הבאה של Android.

התחלה של דרישות חדשות

• צריך להגדיר את צפיפות המסגרת הסטנדרטית של Android, שמבוססת על מספרים הקרוב ביותר לצפיפות הפיזית של המסך, או ערך שניתן למפות אותן מדידות של שדה ראייה שוות ערך למכשיר נישא.

סיום הדרישות החדשות

אם הטמעות מכשירים מספקות יש רכישה משנים את גודל התצוגה של המכשיר , הם:

• [C-1-1] אסור להתאים את גודל המסך בכלל אסור לשנות את גודל המסך גדול מפי 1.5 DENSITY_DEVICE_STABLE צפיפות מקומית או להפיק ממד מסך מינימלי יעיל קטן מ-320dp (שווה ערך) למגדיר המשאבים sw320dp), המוקדם מביניהם.
• [C-1-2] אין להתאים את גודל התצוגה אסור לשנות את גודל המסך קטן מפי 0.85 מהצפיפות המקומיתDENSITY_DEVICE_STABLE.
• כדי להבטיח נוחות שימוש טובה וגודל עקבי של הגופנים, מומלץ לספק את ההתאמה לעומס (scaling) של אפשרויות התצוגה המותאמת (תוך עמידה במגבלות) שצוין למעלה)
  • קטנה: 0.85x
  • ברירת מחדל: 1x (קנה מידה של תצוגה מותאמת)
  • גדול: פי 1.15
  • גדול יותר: פי 1.3
  • הגדול ביותר: 1.45x

7.1.2. מדדי פרסום ברשת המדיה

אם הטמעות המכשירים כוללות מסכים שתואמים ל-Android או פלט וידאו למסכי תצוגה שתואמים ל-Android, הם:

• [C-1-1] חובה לדווח על הערכים הנכונים בכל המסכים שתואמים ל-Android שמוגדרים android.util.DisplayMetrics API.

אם ההטמעות במכשירים לא כוללות מסך מוטמע או פלט וידאו מוטמע, הם:

• [C-2-1] חובה לדווח על הערכים הנכונים במסך התואם ל-Android כפי שמוגדר ב-API android.util.DisplayMetrics לברירת המחדל view.Display של אמולציה.

7.1.3. כיוון מסך

הטמעות מכשירים:

• [C-0-1] חובה לדווח על כיווןי המסך הנתמכים (android.hardware.screen.portrait ו/או android.hardware.screen.landscape) וחובה לדווח על אירוע נתמך אחד לפחות לכיוון מסוים. לדוגמה, מכשיר בכיוון קבוע לרוחב מסך, כמו טלוויזיה או מחשב נייד, לדיווח על android.hardware.screen.landscape.
• [C-0-2] חובה לדווח על הערך הנכון של הערך הנוכחי של המכשיר לכיוון מסוים, בכל פעם שמתקבלת שאילתה דרך android.content.res.Configuration.orientation, android.view.Display.getOrientation() או ממשקי API אחרים.

אם בהטמעות של מכשירים יש תמיכה בשני הכיוונים של המסך:

• [C-1-1] חייבת לתמוך בכיוון דינמי באמצעות אפליקציות במסך לאורך או לרוחב לכיוון מסוים. כלומר, המכשיר חייב להיענות לבקשה של האפליקציה לגבי מסך ספציפי לכיוון מסוים.
• [C-1-2] אסור לשנות את גודל המסך או את הצפיפות שמדווחים כשמשנים את הכיוון.
• ייתכן שברירת המחדל היא 'לאורך' או 'לרוחב'.

7.1.4. האצת גרפיקה דו-ממדית ותלת-ממדית

7.1.4.1 OpenGL ES

הטמעות מכשירים:

• [C-0-1] חייב לזהות בצורה נכונה את הגרסאות הנתמכות של OpenGL ES (1.1, 2.0, 3.0, 3.1, 3.2) באמצעות ממשקי ה-API המנוהלים (למשל באמצעות GLES10.getString()) וממשקי ה-API המקוריים.
• [C-0-2] חייבת לכלול תמיכה בכל ממשקי ה-API המנוהלים המתאימים, וגם ממשקי API מקוריים לכל גרסת OpenGL ES שבה הן זיהו שתומכות.

אם הטמעות במכשירים כוללות פלט מסך או פלט וידאו:

• [C-1-1] חייבת לתמוך ב-OpenGL ES 1.1 ובגרסה 2.0, בצורה מובנית ומפורטת במסמכי התיעוד של Android SDK.
• [C-SR-1] מומלץ מאוד לתמוך ב-OpenGL ES 3.1.
• צריכה לתמוך ב-OpenGL ES 3.2.

בדיקות dEQP של OpenGL ES מחולקות למחיצות למספר רשימות של בדיקות, כל אחת עם תאריך/מספר גרסה משויך. הנתונים האלה נמצאים בעץ המקור של Android ב- external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt מכשיר שיש תמיכה ב-OpenGL ES ברמת דיווח עצמי, מציין שהוא יכול לעבור את ה-dEQP בדיקות בכל רשימות הבדיקה מהרמה הזו ומגרסאות קודמות.

אם בהטמעות של מכשירים יש תמיכה באחת מהגרסאות של OpenGL ES, הן:

• [C-2-1] חובה לדווח על כך באמצעות ממשקי ה-API המנוהלים של OpenGL ES וממשקי API מקוריים תוספי OpenGL ES אחרים שהם הטמיעו, ולהפך חייבים לא לדווח על מחרוזות תוספים שהן לא תומכות בהן.
• [C-2-2] חייבת לתמוך ב-EGL_KHR_image, ב-EGL_KHR_image_base EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable ו-EGL_ANDROID_GLES_layers תוספים.
• [C-2-3] חובה לדווח על הגרסה המקסימלית של בדיקות dEQP של OpenGL ES נתמך באמצעות התכונה הניסיונית android.software.opengles.deqp.level.
• [C-2-4] חייבת להיות תמיכה לפחות בגרסה 132383489 (החל מ-1 במרץ 2020) דווחו בדגל התכונה android.software.opengles.deqp.level.
• [C-2-5] חובה לעבור את כל בדיקות ה-OpenGL ES dEQP ברשימות הבדיקה בין הגרסאות 132383489 והגרסה שצוינה ב סימון תכונה android.software.opengles.deqp.level, לכל אחד מהסוגים הנתמכים גרסת OpenGL ES.
• [C-SR-2] מומלץ מאוד לתמוך ב-EGL_KHR_partial_update OES_EGL_image_external תוספים.

• אמור לדווח באופן מדויק באמצעות השיטה getString(), כל טקסטורה או בפורמט הדחיסה שבו הם תומכים, שהוא בדרך כלל ספציפי לספק.

• צריכה לתמוך ב-EGL_IMG_context_priority וב- EGL_EXT_protected_content תוספים.

אם הטמעות המכשיר מצהירות על תמיכה ב-OpenGL ES בגרסה 3.0, 3.1 או 3.2:

• [C-3-1] חובה לייצא את סמלי הפונקציות התואמים של הגרסה הזו בנוסף לסמלי הפונקציה OpenGL ES 2.0 בספרייה libGLESv2.so.
• [C-SR-3] מומלץ מאוד לתמוך ב-OES_EGL_image_external_essl3 לתוסף.

אם בהטמעות במכשירים תומכים ב-OpenGL ES 3.2, הן:

• [C-4-1] חייבת לתמוך בחבילת התוספים ל-Android של OpenGL ES ל-Android בשלמותה.

אם בהטמעות המכשיר תומכות בחבילת התוספים ל-Android של OpenGL ES כלל, הם:

• [C-5-1] חובה לזהות את התמיכה דרך android.hardware.opengles.aep דגל של פיצ'ר.

אם הטמעות של מכשירים חושפות את התמיכה ב-EGL_KHR_mutable_render_buffer הם:

• [C-6-1] חייבת לתמוך ב-EGL_ANDROID_front_buffer_auto_refresh לתוסף.

7.1.4.2 Vulkan

Android כולל תמיכה ב-Vulkan , ממשק API שדורש תקורה נמוכה בפלטפורמות שונות לגרפיקה תלת-ממדית בעלת ביצועים גבוהים.

אם בהטמעות במכשירים תומכים ב-OpenGL ES 3.1, הן:

• [C-SR-1] מומלץ מאוד לכלול תמיכה בנושא Vulkan 1.3.
• [C-4-1] אסור לתמוך בגרסת וריאנט של Vulkan (כלומר, וריאנט) חלק מגרסת הליבה של Vulkan חייב להיות אפס).

אם הטמעות במכשירים כוללות פלט מסך או פלט וידאו:

• [C-SR-2] מומלץ מאוד לכלול תמיכה בנושא Vulkan 1.3.

בדיקות dEQP של Vulkan מחולקות למחיצות (Partitions) לכמה רשימות של בדיקות, כל אחת עם תאריך/גרסה שמשויכים אליה. הנתונים האלה נמצאים בעץ המקור של Android ב- external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt מכשיר שתומך ב-Vulkan ברמת דיווח עצמי, מציין שהוא יכול לעבור את ה-dEQP בדיקות בכל רשימות הבדיקה מהרמה הזו ומגרסאות קודמות.

אם הטמעות המכשירים כוללות תמיכה ב-Vulkan 1.0 ומעלה:

• [C-1-1] חובה לדווח על הערך הנכון של המספר השלם באמצעות הפונקציה android.hardware.vulkan.level ו-android.hardware.vulkan.version דגלים בפיצ'ר.
• [C-1-2] חובה לספור, לפחות VkPhysicalDevice אחד עבור ה-Vulkan Native API vkEnumeratePhysicalDevices().
• [C-1-3] חובה להטמיע באופן מלא את Vulkan 1.0 ממשקי API של Vulkan 1.1 לכל ספירה VkPhysicalDevice.
• [C-1-4] חובה לספור שכבות, שכלולות בספריות מקוריות שנקראות libVkLayer*.so בספריית הספרייה המקורית של חבילת האפליקציה, דרך ממשקי ה-API המקוריים של Vulkan vkEnumerateInstanceLayerProperties() ו-vkEnumerateDeviceLayerProperties().
• [C-1-5] אסור לספור שכבות שסופקו על ידי ספריות מחוץ של האפליקציה, או לספק דרכים אחרות למעקב או ליירוט של Vulkan API, אלא אם האפליקציה כוללת את המאפיין android:debuggable מוגדר כ-true או כמטא-נתונים com.android.graphics.injectLayers.enable מוגדרת לערך true .
• [C-1-6] חובה לדווח על כל מחרוזות התוספים שהן תומכות בהן דרך ממשקי API מקוריים של Vulkan , ולעומת זאת אסור לדווח על מחרוזות תוסף שהם לא תומכים בהם בצורה נכונה.
• [C-1-7] חייבת לתמוך ב-VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, ו-VK_KHR_incremental_present.
• [C-1-8] חובה לדווח על הגרסה המקסימלית של בדיקות dEQP של Vulkan נתמך באמצעות התכונה הניסיונית android.software.vulkan.deqp.level.
• [C-1-9] חייבת להיות תמיכה לפחות בגרסה 132317953 (החל מ-1 במרץ 2019) בתור דווחו בדגל התכונה android.software.vulkan.deqp.level.
• [C-1-10] חובה לעבור את כל בדיקות ה-dEQP של Vulkan ברשימות הבדיקות בין גרסה 132317953 והגרסה שמצוינת דגל android.software.vulkan.deqp.level של תכונה.
• [C-1-11] אסור לציין תמיכה במימד VK_KHR_video_queue תוספי VK_KHR_video_decode_queue או VK_KHR_video_encode_queue
• [C-SR-3] מומלץ מאוד לתמוך ב-VK_KHR_driver_properties ו-VK_GOOGLE_display_timing תוספים.

• צריכה לתמוך ב-VkPhysicalDeviceProtectedMemoryFeatures וב- VK_EXT_global_priority.

• [C-1-12] אסור לספור תמיכה בתוסף VK_KHR_performance_query.

• [C-1-13] חייבת לעמוד בדרישות שצוינו בפרופיל Android Baseline 2021.

• [C-SR-4] מומלץ מאוד למלא את הדרישות שצוינו על ידי הפרופיל של Android Baseline 2022.

התחלה של דרישות חדשות

• [C-SR-5] מומלץ מאוד לתמוך ב-VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory ו-VK_EXT_global_priority.

• [C-SR-6] מומלץ מאוד להשתמש ב-SkiaVk עם HWUI.

סיום הדרישות החדשות

אם הטמעות במכשירים לא כוללות תמיכה ב-Vulkan 1.0, הן:

• [C-2-1] אסור להצהיר על תכונות ניסיוניות של Vulkan (למשל: android.hardware.vulkan.level, android.hardware.vulkan.version).
• [C-2-2] אסור לספור VkPhysicalDevice ל-API המקורי של Vulkan vkEnumeratePhysicalDevices().

אם הטמעות המכשירים כוללות תמיכה ב-Vulkan 1.1 ומצהירים בהן על אחד או יותר דגלי תכונות של Vulkan שמתוארים כאן , הם:

• [C-3-1] חובה לחשוף את התמיכה בסמפור החיצוני ובכינוי של SYNC_FD והתוסף VK_ANDROID_external_memory_android_hardware_buffer.

התחלה של דרישות חדשות

• [C-SR-7] מומלץ מאוד להכין את VK_KHR_external_fence_fd הזמין לאפליקציות של צד שלישי ולהפעיל את האפליקציה כדי לייצא מטען ייעודי (payload) של גדר ולייבא מטען ייעודי (payload) של גדרות מקובץ POSIX. מתארים, כפי שמתואר כאן.

סיום הדרישות החדשות

7.1.4.3 RenderScript

• [C-0-1] הטמעות מכשירים חייבות לתמוך ב-Android RenderScript, כמפורט בתיעוד של Android SDK.

7.1.4.4 האצת גרפיקה דו-ממדית

Android כולל מנגנון שבו אפליקציות יכולות להצהיר שהן דורשות לאפשר האצת חומרה עבור גרפיקה דו-ממדית באפליקציות, פעילות, רמת חלון או רמת תצוגה מפורטת דרך שימוש בתג מניפסט android:hardwareAccelerated או קריאות ישירות ל-API.

הטמעות מכשירים:

• [C-0-1] חייבים להפעיל שיפור מהירות באמצעות חומרה כברירת מחדל, וחובה להשבית את האצת החומרה אם המפתח מבקש זאת על ידי הגדרה android:hardwareAccelerated="false" או השבתה של האצת חומרה ישירות דרך ממשקי ה-API של Android View.
• [C-0-2] חייבת להראות התנהגות שתואמת מסמכי תיעוד של Android SDK בנושא שיפור המהירות באמצעות חומרה.

Android כולל אובייקט TextureView שמאפשר למפתחים לשלב ישירות טקסטורות של OpenGL ES עם האצת חומרה כיעדי עיבוד בהיררכיית ממשק משתמש.

הטמעות מכשירים:

• [C-0-3] חייבת לתמוך ב-TextureView API, וחייב להופיע התנהגות עקבית עם ההטמעה של Android ב-upstream.

7.1.4.5 מסכים עם טווח רחב

אם בהטמעות במכשירים יש הצהרה על תמיכה במסכים עם טווח רחב דרך Configuration.isScreenWideColorGamut() , הם:

• [C-1-1] מסך מכויל בצבע.
• [C-1-2] חייב להיות מסך שטווח הצבעים שלו מכסה את סולם הצבעים sRGB לגמרי בחלל CIE 1931 xyY.
• [C-1-3] חייב להיות מסך שגודלו של המכלול הוא לפחות 90% DCI-P3 במרחב CIE 1931 xyY.
• [C-1-4] חייבת לתמוך ב-OpenGL ES 3.1 או 3.2 ולדווח עליה כמו שצריך.
• [C-1-5] חובה לפרסם תמיכה בEGL_KHR_no_config_context. EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear, ו-EGL_EXT_gl_colorspace_display_p3_passthrough תוספים.
• [C-SR-1] אנחנו ממליצים מאוד לתמוך ב-GL_EXT_sRGB.

לעומת זאת, אם הטמעות של מכשירים לא תומכות במסכים עם מטווח רחב:

• [C-2-1] אמור לכסות 100% או יותר מה-sRGB במרחב CIE 1931 xyY, למרות סולם צבעי המסך לא מוגדר.

7.1.5. מצב תאימות לאפליקציה מדור קודם

ב-Android מצוין 'מצב תאימות' שבו המסגרת פועלת 'רגיל' מצב שווה ערך לגודל המסך (ברוחב 320dp) לתועלת המודל מדור קודם שלא פותחו לגרסאות ישנות של Android באופן בלתי תלוי בגודל המסך.

7.1.6. טכנולוגיית מסך

פלטפורמת Android כוללת ממשקי API שמאפשרים לאפליקציות לעבד את הגרפיקה לצג תואם Android. המכשירים חייבים לתמוך בכל אלה ממשקי API שהוגדרו על ידי Android SDK, אלא אם הדבר מותר במפורש במסמך הזה.

כל המסכים התואמים ל-Android בהטמעה של מכשיר:

• [C-0-1] חייבת להיות יכולת לעבד גרפיקה צבעונית של 16 ביט.
• אמורה לתמוך במסכים שיכולים להציג גרפיקה צבעונית של 24 ביט.
• [C-0-2] חייבת להיות אפשרות לעבד אנימציות.
• [C-0-3] חייב להיות יחס גובה-רוחב של פיקסל (PAR) בין 0.9 ל-1.15. כלומר, יחס הגובה-רוחב של הפיקסלים חייב להיות קרוב לריבוע (1.0) עם סובלנות של 10 ~ 15%.

7.1.7. מסכים משניים

ב-Android יש תמיכה בהפעלה של מסכים משניים שתואמים ל-Android יכולות שיתוף מדיה וממשקי API למפתחים לגישה למסכים חיצוניים.

אם יישומים של מכשירים תומכים במסך חיצוני באמצעות חיבור קווי, ברשת אלחוטית או בחיבור מסך נוסף מוטמע, הן:

• [C-1-1] חובה להטמיע את DisplayManager שירות מערכת ו-API כפי שמתואר בתיעוד של Android SDK.

7.2. התקני קלט

הטמעות מכשירים:

• [C-0-1] חייב לכלול מנגנון קלט, כמו מסך מגע או ניווט ללא מגע, כדי לנווט בין הרכיבים של ממשק המשתמש.

7.2.1. מקלדת

אם ההטמעות במכשירים כוללות תמיכה באתרים של צדדים שלישיים באמצעות עורך שיטות קלט (IME), הם:

• [C-1-1] חובה להצהיר על android.software.input_methods דגל של פיצ'ר.
• [C-1-2] חובה להטמיע את Input Management Framework באופן מלא
• [C-1-3] חייבת להיות מותקנת מראש מקלדת תוכנה.

הטמעות מכשירים:

• [C-0-1] אסור לכלול מקלדת חומרה שלא תואמת לאחד הפורמטים שצוינו android.content.res.Configuration.keyboard (QWERTY או 12 מקשים).
• אמורות לכלול הטמעות נוספות של מקלדת רכה.
• עשויים לכלול מקלדת חומרה.

7.2.2. ניווט ללא מגע

Android כולל תמיכה בלחצני החיצים (d-pad), כדור עקיבה וגלגל בתור מנגנונים ניווט ללא מגע.

הטמעות מכשירים:

• [C-0-1] חובה לדווח על הערך הנכון עבור android.content.res.Configuration.navigation.

אם בהטמעות במכשירים אין ניווטים ללא מגע, הן:

• [C-1-1] חייב לספק מנגנון סביר של ממשק משתמש חלופי בחירה ועריכה של טקסט, תואמת למנועים לניהול קלט. הטמעת קוד פתוח של Android ב-upstream כוללת מנגנון בחירה מתאים לשימוש במכשירים שאין בהם קלט ניווט ללא מגע.

7.2.3. מקשי ניווט

בדף הבית, תוצאות אחרונות, וחזרה פונקציות שזמינות בדרך כלל באמצעות אינטראקציה עם לחצן פיזי ייעודי או חלק נפרד ממסך המגע, חיוניים פרדיגמת הניווט, ולכן הטמעות מכשירים:

• [C-0-1] חובה לספק למשתמש תקציב להשקת אפליקציות מותקנות הם מכילים פעילות עם הערך <intent-filter> שמוגדר ל-ACTION=MAIN CATEGORY=LAUNCHER או CATEGORY=LEANBACK_LAUNCHER למכשיר טלוויזיה בפועל. הפונקציה 'בית' צריכה להיות המנגנון לתקציב של המשתמש הזה.
• אמורות להיות לחצנים עבור פונקציות 'אחרונים' ו'הקודם'.

אם הפונקציות 'דף הבית', 'אחרונים' או 'חזרה' מסופקות:

• [C-1-1] חייבת להיות נגישות באמצעות פעולה אחת (למשל: הקשה, לחיצה כפולה או תנועה) כשכל אחד מהם נגיש.
• [C-1-2] חייבת לספק אינדיקציה ברורה לגבי הפעולה הבודדת שצריך להפעיל בכל פונקציה. סמל גלוי המוטבע על הלחצן ומוצגת בו תוכנה סמל בסרגל הניווט שמופיע במסך, או מנחה את המשתמש תהליך הגדרה מפורט לסימנים כאלה.

הטמעות מכשירים:

• [C-SR-1] מומלץ מאוד לא לספק את מנגנון הקלט פונקציית התפריט כי הוא הוצא משימוש והוחלף בסרגל הפעולות החל מ-Android 4.0.

• [C-SR-2] מומלץ מאוד לספק את כל פונקציות הניווט כמו שניתן לבטל. 'ביטול' מוגדרת כיכולת של המשתמש למנוע את פונקציית הניווט מהביצוע (למשל, חזרה לדף הבית, חזרה וכו') אם ההחלקה לא משוחררת מעבר לסף מסוים.

אם הטמעות מכשירים מספקות את פונקציית התפריט, הן:

• [C-2-1] חובה להציג את הלחצן 'אפשרויות נוספות' בכל פעם שהפעולה החלון הקופץ של תפריט האפשרויות הנוספות לא ריק וסרגל הפעולות גלוי.
• [C-2-2] אסור לשנות את המיקום של החלון הקופץ של האפשרויות הנוספות מוצגת על ידי לחיצה על לחצן האפשרויות הנוספות בסרגל הפעולות, אבל יכול להיות שהעיבוד החלון הקופץ 'אפשרויות נוספות' של הפעולה במיקום שהשתנה במסך כשהוא שמוצג על ידי בחירה של פונקציית התפריט.

אם הטמעות המכשיר לא מספקות את פונקציית התפריט, תאימות, הן:

• [C-3-1] חובה שפונקציית התפריט תהיה זמינה לאפליקציות targetSdkVersion קטן מ-10, באמצעות לחצן פיזי, מפתח תוכנה, או תנועות. פונקציית התפריט הזו צריכה להיות נגישה, אלא אם היא מוסתרת יחד עם פונקציות ניווט אחרות.

אם ההטמעות של מכשירים מספקות את פונקציית ה-Assist, הם:

• [C-4-1] חובה להפוך את פונקציית Assist לנגישה באמצעות פעולה אחת (למשל: הקשה, לחיצה כפולה או תנועה) כשניתן לגשת למקשי ניווט אחרים.
• [C-SR-3] מומלץ מאוד ללחוץ לחיצה ארוכה על הפונקציה Home לאינטראקציה ייעודית.

אם הטמעות מכשירים משתמשות בחלק נפרד מהמסך כדי להציג במקשי הניווט, הם:

• [C-5-1] מקשי הניווט חייבים להשתמש בחלק נפרד של המסך, ולא זמינים לאפליקציות, ואסור להם להסתיר או לשבש בדרך אחרת את החלק במסך שזמין לאפליקציות.
• [C-5-2] חייב להפוך חלק מהמסך לאפליקציות עומדת בדרישות המוגדרות בסעיף 7.1.1.
• [C-5-3] חובה לפעול בהתאם לסימונים שהאפליקציה קבעה דרך View.setSystemUiVisibility() בשיטת API, כך שהחלק הייחודי הזה במסך (שנקרא גם סרגל הניווט) מוסתר כראוי, כפי שמתועד ערכת ה-SDK.

אם פונקציית הניווט מוצגת כפעולה במסך, שמבוססת על תנועות:

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() חייבים לשמש רק לדיווח על האזור לזיהוי תנועה במסך הבית.
• [C-6-2] תנועות שמתחילות במלבן החרגה כפי שסופק על ידי אפליקציה שפועלת בחזית דרך View#setSystemGestureExclusionRects() אבל מחוץ ל- WindowInsets#getMandatorySystemGestureInsets(), אסור ליירט את הפונקציה של ניווט כל עוד ההחרגה rect מותר במסגרת מגבלת ההחרגה המקסימלית כפי שמצוין תיעוד עבור View#setSystemGestureExclusionRects()
• [C-6-3] חובה לשלוח לאפליקציה בחזית MotionEvent.ACTION_CANCEL אירוע שנוצר בעקבות נגיעות מתחיל ליירט בעקבות תנועה במערכת, אם האפליקציה שפועלת בחזית נשלחה בעבר MotionEvent.ACTION_DOWN אירוע.
• [C-6-4] המשתמש חייב לספק למשתמש מספיק מקום לעבור למסך. לניווט מבוסס-לחצנים (לדוגמה, בהגדרות).
• אמורה לספק את הפונקציה 'דף הבית' כהחלקה למעלה מהקצה התחתון של הכיוון הנוכחי של המסך.
• אמורה לספק את הפונקציה 'אחרונים' כהחלקה למעלה והחזקה לפני השחרור, אותו האזור כמו התנועה במסך הבית.
• תנועות שמתחילות תוך WindowInsets#getMandatorySystemGestureInsets() לא אמורות להיות מושפעות מהגדרות החרגה שזמינות בחזית בקשה דרך View#setSystemGestureExclusionRects()

אם מסופקת פונקציית ניווט מכל מקום בקצה השמאלי והימני של הכיוון הנוכחי של המסך:

• [C-7-1] פונקציית הניווט חייבת להיות חוזרת ומופיעה החל מהקצה השמאלי והימני של הכיוון הנוכחי מסך.
• [C-7-2] אם חלוניות מערכת בהתאמה אישית ניתנות להחלקה זמינות בצד שמאל או הקצוות הימניים, הם חייבים להיות ממוקמים בשליש העליון של המסך באמצעות אינדיקציה חזותית ברורה ועקבית שגרירה פנימה תפעיל שהוזכרו למעלה, ולכן לא חזרה. יכול להיות שחלונית מערכת מוגדר על ידי משתמש כך שהוא יגיע אל מתחת לשליש העליון של המסך קצוות, אבל לוח המערכת לא יכול להשתמש ביותר מ-1/3 מהקצוות.
• [C-7-3] כשבאפליקציה בחזית יש את אחד מהמצבים הבאים: הצגה.SYSTEM_UI_FLAG_IMMERSIVE, תצוגה.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, windowInsetsController.BEHAVIOR_DEFAULT, או הוגדרו דגלים של windowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, החלקה מהקצוות חייבת להתנהג כמו שמוטמעת ב-AOSP, מתועד ב-SDK.
• [C-7-4] כשבאפליקציה בחזית יש הצגה.SYSTEM_UI_FLAG_IMMERSIVE, תצוגה.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, windowInsetsController.BEHAVIOR_DEFAULT, או דגל windowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE הוגדרו, חלוניות מערכת בהתאמה אישית שניתן להחליק חייבות להיות מוסתרות עד שהמשתמש מכניס או ביטול העמעום של סרגלי המערכת (שנקראים גם ניווט ושורת סטטוס) כפי שהוטמע ב-AOSP.

אם סופקה פונקציית הניווט 'הקודם' והמשתמש ביטל את הפעולה 'הקודם' תנועה, ואז:

• [C-8-1] חובה להתקשר אל OnBackInvokedCallback.onBackCancelled().
• [C-8-2] אסור להתקשר אל OnBackInvokedCallback.onBackInvoked().
• [C-8-3] אין לשלוח את האירוע KEYCODE_BACK.

אם פונקציית הניווט האחורית מסופקת, אבל האפליקציה בחזית שאין להם OnBackInvokedCallback רשום, ואז:

• המערכת אמורה לספק אנימציה לאפליקציה בחזית מציעה שהמשתמש חוזר, כפי שמצוין ב-AOSP.

אם הטמעות המכשירים תומכות ב-API של המערכת setNavBarMode כדי אפשר לכל אפליקציית מערכת עם ההרשאה android.permission.STATUS_BAR להגדיר את במצב סרגל הניווט, ואז:

• [C-9-1] חייבת לספק תמיכה בסמלים או בסמלים מבוססי-לחצנים שמתאימים לילדים. ניווט כפי שסופק בקוד ה-AOSP.

7.2.4. קלט מסך מגע

ב-Android יש תמיכה במגוון מערכות קלט של מצביע, כמו מסכי מגע, רפידות מגע ומכשירים מזויפים לקלט מגע. הטמעות מכשירים שמבוססות על מסך מגע משויכות לתצוגה כך שהמשתמש מקבל את החשיפה ישירות לבצע מניפולציות על פריטים במסך. מאחר שהמשתמש נוגע ישירות במסך, המערכת לא דורשת עלויות נוספות כדי לציין את האובייקטים. שעברו מניפולציה.

הטמעות מכשירים:

• אמורה להיות מערכת קלט של מצביע מסוג כלשהו. (כמו בעכבר או במגע).
• צריכה לתמוך בסמנים שנמצאים במעקב בלתי תלוי באופן מלא.

אם יישומי המכשיר כוללים מסך מגע (נגיעה אחת ואילך) במסך ראשי שתואם ל-Android, אפשר:

• [C-1-1] חובה לדווח על TOUCHSCREEN_FINGER עבור Configuration.touchscreen שדה API.
• [C-1-2] חובה לדווח על android.hardware.touchscreen android.hardware.faketouch תכונות ניסיוניות.

אם יישומים של המכשיר כוללים מסך מגע שיכול לעקוב אחר יותר מ- נגיעה אחת במסך ראשי שתואם ל-Android:

• [C-2-1] חובה לדווח על הסימונים המתאימים android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand שתואם לסוג של מסך המגע הספציפי במכשיר.

אם הטמעות המכשיר מסתמכות על מכשיר קלט חיצוני, כמו עכבר או כדור עקיבה (כלומר לא לגעת ישירות במסך) לקלט של מכשיר ראשי מסך תואם ל-Android ועומד בדרישות של מגע מזויף 7.2.5:

• [C-3-1] אסור לדווח על סימון תכונה כלשהו שמתחיל ב- android.hardware.touchscreen
• [C-3-2] חובה לדווח רק על android.hardware.faketouch.
• [C-3-3] חובה לדווח על TOUCHSCREEN_NOTOUCH עבור Configuration.touchscreen שדה API.

7.2.5. קלט מגע מזויף

ממשק מגע מזויף מספק מערכת קלט של משתמש שמתאימות לקבוצת משנה של יכולות של מסך מגע. לדוגמה, עכבר או שלט רחוק סמן במסך מתקרב למגע, אבל דורש מהמשתמש להצביע לראשונה להתמקד וללחוץ. מכשירים שונים לקליטת נתונים, כמו העכבר, משטח מגע, מבוסס ג'ירו עכבר אוויר, ג'ויסטיק, ג'ויסטיק ומשטח מגע מולטי-טאץ' יכולים לתמוך בזיוף אינטראקציות מגע. Android כולל את קבוע התכונה android.hardware.faketouch, תואם לתקן באיכות גבוהה ללא מגע התקן קלט (מבוסס-הצבעה), כמו עכבר או משטח מגע שיכולים להתאים לבצע אמולציה של קלט מבוסס מגע (כולל תמיכה בסיסית בתנועה), ולציין המכשיר תומך בקבוצת משנה אמולמית של פונקציונליות של מסך מגע.

אם ההטמעות במכשיר לא כוללות מסך מגע אלא כוללות מסך מגע אחר את המערכת של קלט המצביע שהם רוצים להעמיד, הם:

• צריך להצהיר על תמיכה בדגל הפיצ'ר android.hardware.faketouch.

אם בהטמעות המכשירים מוצהר על תמיכה ב-android.hardware.faketouch, הם:

• [C-1-1] חובה לדווח על מיקומי המסך המוחלטים X ו-Y של מיקום הסמן ולהציג מצביע חזותי על המסך.
• [C-1-2] חובה לדווח על אירוע המגע עם קוד הפעולה שמציין את שינוי מצב שמתרחש בסמן יורד או עולה במסך.
• [C-1-3] חייבת להיות תמיכה בסמן כלפי מטה ומעלה על גבי אובייקט במסך, מאפשרת למשתמשים לבצע אמולציה של הקשה על אובייקט במסך.
• [C-1-4] חובה לתמוך בסמן כלפי מטה, מצביע למעלה, מצביע למטה ואז מצביע למעלה באותו מקום על אובייקט במסך במסגרת סף זמן, מאפשר למשתמשים לבצע אמולציה של הקשה כפולה על אובייקט במסך.
• [C-1-5] חייבת לתמוך בסמן כלפי מטה בנקודה שרירותית על המסך, של סמן העכבר לכל נקודה שרירותית אחרת במסך, ואחריה מצביע למעלה, שמאפשר למשתמשים לחקות גרירה במגע.
• [C-1-6] חובה לתמוך במצביע תמיכה למטה ואז לאפשר למשתמשים להזיז במהירות את להופיע במיקום אחר במסך ואז מצביע למעלה על המסך. שמאפשר למשתמשים להשליך חפץ על המסך.

אם בהטמעות מכשירים מוצהר על תמיכה ב android.hardware.faketouch.multitouch.distinct, הן:

• [C-2-1] חובה להצהיר על תמיכה ב-android.hardware.faketouch.
• [C-2-2] חייבת להיות תמיכה במעקב ייחודי אחרי שני מצביעים בלתי תלויים או יותר של קלטים.

אם בהטמעות מכשירים מוצהר על תמיכה ב android.hardware.faketouch.multitouch.jazzhand, הן:

• [C-3-1] חובה להצהיר על תמיכה ב-android.hardware.faketouch.
• [C-3-2] חייבת להיות תמיכה במעקב ייחודי של 5 (מעקב אחר יד של אצבעות) או יותר קלט של מצביע באופן מלא באופן עצמאי.

7.2.6. תמיכה לבקרים לגיימינג

7.2.6.1. מיפויי לחצנים

הטמעות מכשירים:

• [C-1-1] חייבת להיות יכולת למפות אירועי HID לקבועים המתאימים של InputEvent כפי שמפורט בטבלאות שבהמשך. ההטמעה של Android ב-upstream עומדת בדרישה הזו.

אם בהטמעות של מכשירים מוטמעים בקר או נשלח עם בקר נפרד בתיבה שמספקים אמצעים לקלט כל האירועים המפורטים בטבלאות הבאות:

• [C-2-1] חובה להצהיר על דגל הפיצ'ר android.hardware.gamepad

לחצן	שימוש במכשיר ממשק אנושי (HID)^2	לחצן Android
א^1	0x09 0x0001	KEYCODE_button_A (96)
ב^1	0x09 0x0002	KEYCODE_button_B (97)
X^1	0x09 0x0004	KEYCODE_button_X (99)
כן^1	0x09 0x0005	KEYCODE_button_Y (100)
לחצני החיצים (D-pad)^1 לחצני החיצים (D-pad)^1	0x01 0x0039^3	AXIS_HAT_Y^4
לחצני החיצים (D-pad) שמאל1 לחצני החיצים (D-pad) מימין^1	0x01 0x0039^3	AXIS_HAT_X^4
לחצן הכתף השמאלי^1	0x09 0x0007	KEYCODE_button_L1 (102)
לחצן כתף ימין^1	0x09 0x0008	KEYCODE_button_R1 (103)
לחיצה על הלחצן השמאלי^1	0x09 0x000E	KEYCODE_button_THUMBL (106)
לחיצה על הלחצן הימני^1	0x09 0x000F	KEYCODE_button_THUMBR (107)
לדף הקודם^1	0x0c 0x0224	KEYCODE_BACK (4)

אירוע מרכזי אחד

2 חובה להצהיר על השימוש במכשיר ממשק אנושי (HID) שלמעלה במשחק pad CA (0x01 0x0005).

3 השימוש הזה חייב להיות בעל ערך לוגי מינימלי של 0, מקסימום לוגי של 7, מינימום 0 פיזי, מקסימום 315, יחידות במעלות וגודל דוח של 4. הערך הלוגי מוגדר סיבוב בכיוון השעון הרחק מהציר האנכי; לדוגמה, ערך לוגי של 0 מייצג ללא סיבוב, ולחיצה על הלחצן למעלה, בעוד ערך לוגי הערך 1 מייצג סיבוב של 45 מעלות, וגם המקשים שמאלה ולמעלה בוצעה לחיצה.

4 MotionEvent

אמצעי בקרה אנלוגיים^1	שימוש במכשיר ממשק אנושי (HID)	לחצן Android
טריגר שמאלי	0x02 0x00C5	AXIS_LTRIGGER
טריגר ימני	0x02 0x00C4	AXIS_RTRIGGER
ג'ויסטיק שמאלי	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
ג'ויסטיק ימני	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

MotionEvent אחד

7.2.7. שלט רחוק

ראו סעיף 2.3.1 לדרישות ספציפיות למכשיר.

7.3. חיישנים

אם ההטמעות במכשירים כוללות חיישן מסוג מסוים ממשק API תואם למפתחים של צד שלישי, הטמעת המכשירים חובה להטמיע את ה-API הזה כפי שמתואר במסמכים של Android SDK. תיעוד הקוד הפתוח של Android בקטע חיישנים.

הטמעות מכשירים:

• [C-0-1] חובה לדווח בצורה מדויקת על נוכחות או היעד של חיישנים android.content.pm.PackageManager בכיתה.
• [C-0-2] חובה להחזיר רשימה מדויקת של חיישנים נתמכים דרך SensorManager.getSensorList() ושיטות דומות.
• [C-0-3] חובה להתנהג באופן סביר בכל ממשקי ה-API של החיישנים האחרים (לדוגמה, החזרת true או false בהתאם לצורך כשאפליקציות מנסות להירשם מאזינים, ללא קריאה למאזינים של חיישנים כשהחיישנים המתאימים לא כיום; וכו').

אם ההטמעות במכשירים כוללות חיישן מסוג מסוים התואם למפתחים של צד שלישי, הם:

• [C-1-1] חובה לדווח על כל מדידות החיישנים באמצעות הערכים הרלוונטיים של מערכת היחידות הבין-לאומית (המדד) לכל אחד מהם סוג החיישן כפי שמוגדר במסמכי התיעוד של Android SDK.
• [C-1-2] חובה לדווח על נתוני החיישנים שזמן האחזור שלהם הוא 100 לכל היותר אלפיות שנייה + 2 * sample_time למקרה של שידור חיישן עם זמן אחזור מבוקש מקסימלי של 0 אלפיות השנייה כאשר מעבד האפליקציות פעיל. העיכוב הזה לא כולל עיכובים בסינון.
• [C-1-3] חובה לדווח על דגימת החיישן הראשונה תוך 400 אלפיות השנייה + 2 * segment_time של החיישן שמופעל. מותר להשתמש בדוגמה הזו לקבל דיוק של 0.
• [C-1-4] כל API שמצוין בתיעוד של Android SDK הוא חיישן רציף, יישומים של מכשירים חייבים לספק באופן רציף בדגימות נתונים תקופתיות שאמורות להיות רעידות מתחת ל-3%, כאשר רעידות מוגדרת כסטיית התקן של ההפרש שידווחו ערכים של חותמת זמן בין אירועים עוקבים.
• [C-1-5] חובה לוודא שהאירוע של החיישן אסור למנוע מהמעבד (CPU) של המכשיר להיכנס למצב השעיה או לצאת ממצב שינה ממצב השעיה.
• [C-1-6] חובה לדווח על מועד האירוע בננו-שניות כפי שמוגדר במסמכי התיעוד של Android SDK, שמייצגים את שהאירוע התרחש וסונכרן עם שעון SystemClock.elapsedRenano() .
• [C-SR-1] מומלץ מאוד שיש שגיאה בסנכרון של חותמת הזמן מתחת ל-100 אלפיות השנייה, ואמורה להיות שגיאת סנכרון חותמת זמן מתחת ל-1 אלפית שנייה.
• כאשר כמה חיישנים מופעלים, צריכת החשמל לא אמורה להיות גבוהה יותר סך צריכת האנרגיה של כל חיישן בנפרד.

הרשימה שלמעלה היא חלקית. ההתנהגות המתועדת של ה-SDK של Android ומסמכי הקוד הפתוח של Android ב- חיישנים מהימן.

אם ההטמעות במכשירים כוללות חיישן מסוג מסוים התואם למפתחים של צד שלישי, הם:

• [C-1-6] חובה להגדיר רזולוציה שהיא לא אפס לכל החיישנים ולדווח על הערך דרך Sensor.getResolution() שיטת ה-API.

חלק מסוגי החיישנים הם מורכבים, כלומר הם נגזרים מנתונים שסופקו חיישן אחד או יותר. (לדוגמה: חיישן הכיוון חיישן תאוצה לינארית).

הטמעות מכשירים:

• יש להטמיע את סוגי החיישנים האלה לכלול את החיישנים הפיזיים הנדרשים, כפי שמתואר בסוגי חיישנים.

אם ההטמעות במכשירים כוללות חיישן מורכב, הן:

• [C-2-1] חובה להטמיע את החיישן כפי שמתואר בקוד הפתוח של Android על חיישנים מורכבים.

אם ההטמעות במכשירים כוללות חיישן מסוג מסוים ממשק API תואם למפתחים של צד שלישי והחיישן מדווח על אחד בלבד ערך, ואז הטמעות מכשירים:

• [C-3-1] חובה להגדיר את הרזולוציה של החיישן ל-1 ולדווח על הערך דרך Sensor.getResolution() שיטת ה-API.

אם ההטמעות במכשירים כוללות סוג חיישן מסוים שתומך SensorAdditionalInfo#TYPE_VEC3_CALIBRATION והחיישן חשוף למפתחים של צד שלישי, הם:

• [C-4-1] אסור לכלול כיול קבוע שנקבע על ידי היצרן בפרמטרים של הנתונים שסופקו.

אם יישומי המכשיר כוללים שילוב של מד תאוצה ב-3 צירים, חיישן ג'ירוסקופ עם 3 צירים או חיישן מגנטומטר:

• [C-SR-2] מומלץ מאוד לבדוק את מד התאוצה, הג'ירוסקופ למגנטומטר יש מיקום יחסי קבוע, כך שאם המכשיר ניתן לטרנספורמציה (למשל, מתקפל), צירי החיישן נשארים מיושרים ועקביים באמצעות מערכת הקואורדינטות של החיישן בכל המכשירים האפשריים של הטרנספורמציה.

7.3.1. מד תאוצה

הטמעות מכשירים:

• [C-SR-1] מומלץ מאוד לכלול מד תאוצה עם 3 צירים.

אם בהטמעות במכשירים נכללים מד תאוצה:

• [C-1-1] חייבת להיות אפשרות לדווח על אירועים בתדירות של עד 50Hz לפחות.
• [C-1-3] חייב לעמוד בדרישות של מערכת קואורדינטות של חיישן Android כפי שמפורט בממשקי ה-API של Android.
• [C-1-4] חייבת להיות מסוגלת למדוד מצניחה חופשית עד פי ארבע כוח משיכה(4 ג') או יותר בכל ציר.
• [C-1-5] חייבת להיות ברזולוציה של 12 ביט לפחות.
• [C-1-6] חייבת להיות סטיית תקן של לא יותר מ-0.05 מטר/s^, כאשר יש לחשב את סטיית התקן על בסיס כל ציר על בסיס דגימות שנאספו במשך פרק זמן של 3 שניות לפחות, בקצב הדגימה המהיר ביותר.
• צריך לדווח על אירועים עד 200 Hz לפחות.
• הרזולוציה צריכה להיות לפחות 16 סיביות.
• צריך לכייל אותו בזמן השימוש אם המאפיינים משתנים במחזור החיים של התגמול, ושומרים על הפרמטרים של הפיצוי בין הפעלות מחדש של המכשיר.
• הטמפרטורה אמורה לפצות על הטמפרטורה.

אם יישומי המכשירים כוללים מד תאוצה ב-3 צירים, הם:

• [C-2-1] חובה להטמיע את החיישן TYPE_ACCELEROMETER ולדווח עליו.
• [C-SR-4] מומלץ מאוד להטמיע את TYPE_SIGNIFICANT_MOTION מרוכב.
• [C-SR-5] מומלץ מאוד להטמיע מודעות ולדווח עליהן חיישן TYPE_ACCELEROMETER_UNCALIBRATED. מכשירי Android הם בשימוש חזק מומלץ לעמוד בדרישה הזו כדי שהם יוכלו לשדרג במהדורה עתידית של פלטפורמה שבה יכול להיות שהדרישה הזו תהיה REQUIRED.
• צריך להטמיע את TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER מחיישנים מורכבים, כפי שמתואר במסמך ה-SDK של Android.

אם בהטמעות המכשירים יש מד תאוצה עם פחות מ-3 צירים:

• [C-3-1] חובה להטמיע את החיישן TYPE_ACCELEROMETER_LIMITED_AXES ולדווח עליו.
• [C-SR-6] מומלץ מאוד ליישם את ההמלצה ולדווח עליה חיישן TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

אם יישומי המכשיר כוללים מד תאוצה ב-3 צירים ואחד TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR הוטמעו חיישנים מורכבים של TYPE_STEP_COUNTER:

• [C-4-1] סכום הערכים צריכת החשמל חייבת להיות תמיד נמוכה מ-4 מגה-ואט.
• כל אחד מהם צריך להיות קטן מ-2 מגה-ואט ו-0.5 מגה-ואט כשהמכשיר במצב דינמי או סטטי.

אם הטמעת המכשיר כוללת מד תאוצה ב-3 צירים וחיישן ג'ירוסקופ עם 3 צירים, הם:

• [C-5-1] חובה להטמיע את TYPE_GRAVITY ואת TYPE_LINEAR_ACCELERATION מחיישנים מורכבים.
• [C-SR-7] מומלץ מאוד ליישם חיישן מורכב TYPE_GAME_ROTATION_VECTOR.

אם יישומי המכשיר כוללים מד תאוצה ב-3 צירים, חיישן ג'ירוסקופ עם 3 צירים וחיישן מגנטומטר, הן:

• [C-6-1] חובה להטמיע חיישן מורכב של TYPE_ROTATION_VECTOR.

7.3.2. מגנטומטר

הטמעות מכשירים:

• [C-SR-1] מומלץ מאוד לכלול מגנטומטר (מצפן) עם 3 צירים.

אם הטמעתם במכשירים שונים מגנטומטר עם 3 צירים:

• [C-1-1] חובה להטמיע את החיישן TYPE_MAGNETIC_FIELD.
• [C-1-2] חייבת להיות אפשרות לדווח על אירועים בתדירות של עד 10 Hz לפחות וצריכים לדווח על אירועים עד 50 Hz לפחות.
• [C-1-3] חייב לעמוד בדרישות של מערכת הקואורדינטות של חיישן Android כפי שמפורט ממשקי API של Android.
• [C-1-4] חייבת להיות יכולת למדוד בין -900 μT ל- +900 μT בכל אחד לפני רוויה.
• [C-1-5] ערך ההיסט של ברזל קשיח נמוך מ- 700 μT והוא צריך להיות ערך נמוך מ- 200 μT, על ידי הצבת המגנטומטר רחוק שדות מגנטיים דינמיים (בגירוי נוכחי) וסטטיים (בהגברת מגנט).
• [C-1-6] הרזולוציה צריכה להיות שווה או צפופה יותר מ-0.6 μT.
• [C-1-7] חובה לתמוך בכיול מקוון ובפיצוי של הברזל הקשיח הטיה ולשמר את הפרמטרים של הפיצוי בין הפעלות מחדש של המכשיר.
• [C-1-8] חובה להחיל את הפיצוי על הברזל הרך – הכיול יכול להיות בזמן השימוש או במהלך הייצור של המכשיר.
• [C-1-9] חייבת להיות סטיית תקן, המחושבת על בסיס לכל ציר דגימות שנאספו במשך פרק זמן של 3 שניות לפחות, בדגימה המהירה ביותר קצב של עד 1.5μT; אמורה להיות סטיית תקן שלא גדולה מ- 0.5 μT.
• [C-1-10] חובה ליישם TYPE_MAGNETIC_FIELD_UNCALIBRATED באמצעות חיישן.

אם הטמעת המכשיר כוללת מגנטומטר ב-3 צירים, מד תאוצה וחיישן ג'ירוסקופ עם 3 צירים, הם:

• [C-2-1] חובה להטמיע חיישן מורכב מסוג TYPE_ROTATION_VECTOR.

אם יישומי המכשיר כוללים מגנטומטר ב-3 צירים ומד תאוצה, הם:

• יכול להיות שהחיישן TYPE_GEOMAGNETIC_ROTATION_VECTOR יוטמע.

אם יישומי המכשיר כוללים מגנטומטר ב-3 צירים, מד תאוצה חיישן TYPE_GEOMAGNETIC_ROTATION_VECTOR, הן:

• [C-3-1] חובה לצרוך פחות מ-10 מגה-ואט.
• צריך לצרוך פחות מ-3 מגה-ואט כשהחיישן רשום במצב אצווה ב-10Hz.

7.3.3. GPS

הטמעות מכשירים:

• [C-SR-1] מומלץ מאוד לכלול מקלט GPS/GNSS.

אם יישומי המכשיר כוללים מקלט GPS/GNSS ומדווחים על היכולת לאפליקציות באמצעות דגל התכונה android.hardware.location.gps, הן:

• [C-1-1] חייבת לתמוך בפלט מיקום בקצב של 1 Hz לפחות כאשר נשלחה בקשה דרך LocationManager#requestLocationUpdate.
• [C-1-2] חייבת להיות אפשרות לקבוע את המיקום בתנאים של שמיים פתוחים (אותות חזקים, מולטי-נתיב זניח, HDOP < 2) בתוך 10 שניות (מהירה זמן לתיקון הראשון), כשמחוברים למהירות נתונים של 0.5Mbps או מהירות יותר חיבור לאינטרנט. כדי לעמוד בדרישה הזו, השימוש בכלים סוג של שיטת 'GPS/GNSS' בסיוע או חזויים כדי למזער את זמן הנעילה של ה-GPS/GNSS (נתוני הסיוע כוללים את זמן ההפניה, מיקום הפניה ותקופת זמן לוויינית/שעון).
  • [C-1-6] לאחר ביצוע חישוב מיקום כזה, המכשיר וההטמעות חייבות לקבוע את המיקום שלהן, בשמיים פתוחים, 5 שניות, כשבקשות המיקום מופעלות מחדש, עד שעה לאחר מכן את חישוב המיקום הראשוני, גם כשהבקשה הבאה נעשה ללא חיבור נתונים ו/או לאחר מחזור חשמל.

• במצב של שמיים פתוחים לאחר קביעת המיקום, כשהוא נייח או נע בפחות ממטר אחד לשנייה, בריבוע תאוצה:

  • [C-1-3] חייבת להיות יכולת לקבוע את המיקום בטווח של 20 מטרים, ומהירות בטווח של 0.5 מטר לשנייה, לפחות ב-95% מהזמן.
  • [C-1-4] חובה לעקוב בו-זמנית ולדווח עליהן באמצעות GnssStatus.Callback לפחות 8 לוויינים מקבוצת כוכבים אחת.
  • אמורה להיות אפשרות לעקוב בו-זמנית אחרי לפחות 24 לוויינים, מספר קבוצות כוכבים (למשל GPS + לפחות אחת של Glonass, ביידו, גליליאו).

• [C-SR-2] מומלץ מאוד להמשיך לספק GPS/GNSS רגילים פלט נתוני מיקום דרך GNSS Location Provider API בזמן שיחת חירום שיחה.

• [C-SR-3] מומלץ מאוד לדווח על מדידות של GNSS מכל הסוגים קבוצות כוכבים שנמצאות במעקב (כפי שדווח בהודעות GnssStatus), למעט של SBAS.

• [C-SR-4] מומלץ מאוד לדווח על AGC ועל תדירות של GNSS מדידה.

• [C-SR-5] מומלץ מאוד לדווח על כל אומדני הדיוק (כולל תמיכה, מהירות ואנכי) כחלק מכל מיקום שמבוסס על GPS/GNSS.

• [C-SR-6] מומלץ מאוד לדווח על מדידות של GNSS בהקדם האפשרי הם נמצאים, גם אם המיקום המחושב מ-GPS/GNSS עדיין לא דווחו.

• [C-SR-7] מומלץ מאוד לדווח על טווחים פסאודוניים של GNSS קצבים פסאודונימים, כלומר, בתנאים של שמיים פתוחים לאחר קביעת המיקום, כאשר עומדת במקום או נעה בטווח של פחות מ-0.2 מטר לשנייה בריבוע תאוצה מספיקה כדי לחשב את המיקום בטווח של 20 מטרים, בטווח של 0.2 מטר לשנייה, לפחות ב-95% מהזמן.

7.3.4. ג'ירוסקופ

הטמעות מכשירים:

• [C-SR-1] מומלץ מאוד לכלול חיישן ג'ירוסקופ.

אם ההטמעות במכשיר כוללות ג'ירוסקופ, הן:

• [C-1-1] חייבת להיות אפשרות לדווח על אירועים בתדירות של עד 50Hz לפחות.
• [C-1-4] חייבת להיות ברזולוציה של 12 ביט או יותר.
• [C-1-5] חובה לפצות על הטמפרטורה.
• [C-1-6] חובה לבצע כיול ותגמול בזמן השימוש, ולשמור את פרמטרים של פיצוי בין הפעלה מחדש של המכשיר.
• [C-1-7] השונות חייבת להיות שונה מ- 1e-7 rad^2 / s^2 לכל Hz (שונות ל-Hz או rad^2 / s). השונות יכולה להשתנות עם קצב הדגימה, אך הערך הזה חייב להיות מוגבל. במילים אחרות, אם מודדים את השונות של הג'יירו בקצב דגימה של 1 Hz שהוא לא אמור להיות גדול יותר מ-1e-7 rad^2/s^2.
• [C-SR-2] מומלץ מאוד ששגיאת כיול תהיה קטנה מ- 0.01 rad/s כשהמכשיר נייח בטמפרטורת החדר.
• [C-SR-3] מומלץ מאוד להשתמש ברזולוציה של 16 ביט או יותר.
• צריך לדווח על אירועים עד 200 Hz לפחות.

אם הטמעת המכשיר כוללת ג'ירוסקופ עם 3 צירים:

• [C-2-1] חובה להטמיע את החיישן TYPE_GYROSCOPE.
• [C-SR-4] מומלץ מאוד להטמיע את TYPE_GYROSCOPE_UNCALIBRATED באמצעות חיישן.

אם ההטמעות במכשירים כוללים ג'ירוסקופ עם פחות מ-3 צירים:

• [C-3-1] חובה להטמיע את החיישן TYPE_GYROSCOPE_LIMITED_AXES ולדווח עליו.
• [C-SR-5] מומלץ מאוד ליישם את ההמלצה ולדווח עליה חיישן TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

אם יישומי המכשיר כוללים ג'ירוסקופ ב-3 צירים, חיישן מד תאוצה וחיישן מגנטומטר, הן:

• [C-4-1] חובה להטמיע חיישן מורכב מסוג TYPE_ROTATION_VECTOR.

אם הטמעת המכשיר כוללת מד תאוצה ב-3 צירים וג'ירוסקופ עם 3 צירים הם:

• [C-5-1] חובה להטמיע את TYPE_GRAVITY ואת TYPE_LINEAR_ACCELERATION מחיישנים מורכבים.
• [C-SR-6] מומלץ מאוד ליישם TYPE_GAME_ROTATION_VECTOR מרוכב.

7.3.5. ברומטר

הטמעות מכשירים:

• [C-SR-1] מומלץ מאוד לכלול ברומטר (לחץ אוויר סביבתי) חיישן).

אם יישומי מכשירים כוללים ברומטר, הם:

• [C-1-1] חובה להטמיע את החיישן TYPE_PRESSURE ולדווח עליו.
• [C-1-2] חייבת להיות אפשרות לספק אירועים בתדירות של 5Hz או יותר.
• [C-1-3] חובה לפצות על הטמפרטורה.
• [C-SR-2] מומלץ מאוד לאפשר דיווח על מדידות לחץ טווח של 300hPa עד 1100hPa.
• הדיוק שלו אמור להיות מוחלט של 1hPa.
• רמת הדיוק היחסית אמורה להיות 0.12hPa על פני טווח של 20hPa (שווה ערך לדיוק של כ-1 מ' לשינוי של כ-200 מ' בגובה פני הים).

7.3.6. מדחום

אם יישומי המכשיר כוללים מדחום סביבתי (חיישן טמפרטורה), הם:

• [C-1-1] חובה להגדיר SENSOR_TYPE_AMBIENT_TEMPERATURE לחיישן טמפרטורת הסביבה ולחיישן חייבים למדוד את הסביבה הטמפרטורה שבה (חדר/תא המטען) מהמקום שבו המשתמש מקיים אינטראקציה עם במעלות צלזיוס.

אם יישומי המכשיר כוללים חיישן מדחום שמודד מלבד טמפרטורת הסביבה, כמו הטמפרטורה של המעבד (CPU), במקרים הבאים:

• [C-2-1] אסור להגדיר SENSOR_TYPE_AMBIENT_TEMPERATURE חיישן הטמפרטורה.

אם הטמעת המכשיר כוללת חיישן לניטור טמפרטורת העור, ואז:

• [C-SR-1] מומלץ מאוד לתמוך PowerManager.getThermalHeadroom API.

7.3.7. פוטומטר

• ייתכן שהטמעות המכשיר כוללות פוטומטר (חיישן אור רגיש לסביבה).

7.3.8. חיישן קירבה

• ייתכן שהטמעות במכשירים כוללות חיישן קירבה.

אם יישומים של מכשירים כוללים חיישן קירבה, והם מדווחים רק על בקריאה בינארית "ליד" או "רחוק", הן:

• [C-1-1] חובה למדוד את הקרבה של עצם באותו כיוון מסך. כלומר, חיישן הקירבה צריך להיות מכוון לזיהוי עצמים קרוב למסך, כי הכוונה העיקרית של סוג החיישן הזה היא זיהוי טלפון שנמצא בשימוש של המשתמש. אם הטמעות המכשיר כוללות חיישן קירבה בכל כיוון אחר, אסור שהוא יהיה נגיש באמצעות ה-API הזה.
• [C-1-2] רמת דיוק של ביט אחד או יותר.
• [C-1-3] חובה להשתמש ב-0 ס"מ בתור הקריאה הקרובה וב-5 ס"מ קריאה רחוקה.
• [C-1-4] חובה לדווח על טווח ורזולוציה מקסימלי של 5.

7.3.9. חיישנים באיכות גבוהה

אם ההטמעות במכשירים כוללות קבוצה של חיישנים באיכות גבוהה יותר, כפי שהוגדר בקטע הזה כדי להפוך אותם לזמינים לאפליקציות צד שלישי, הם:

• [C-1-1] חובה לזהות את היכולת באמצעות סימון תכונה android.hardware.sensor.hifi_sensors.

אם בהטמעות המכשירים מוצהר על android.hardware.sensor.hifi_sensors, הם:

• [C-2-1] חייב להיות חיישן TYPE_ACCELEROMETER שמאפשר:

  • טווח המדידה חייב להיות בין -8G ל-8G+, מומלץ מאוד להגדיר טווח מדידה בין -16G לפחות ו-16G+.
  • רזולוציית המדידה חייבת להיות לפחות 2048 LSB/g.
  • תדירות המדידה המינימלית חייבת להיות 12.5Hz או נמוכה יותר.
  • תדירות המדידה המקסימלית חייבת להיות 400 Hz או יותר. אמור תומכים ב-SensorDirectChannel RATE_VERY_FAST.
  • הרעש במדידה חייב להיות נמוך מ-400 μg/לצאת.
  • חובה להשתמש בחיישן הזה בצורת חיישן שלא נכנס למצב שינה עם אגירת נתונים יכולת של 3,000 אירועי חיישנים לפחות.
  • צריכת החשמל באצווה חייבת להיות נמוכה מ-3 מגה-ואט.
  • [C-SR-1] מומלץ מאוד שרוחב הפס למדידה של 3dB יהיה בגודל של לפחות 80% מתדר ה-Nyquist וספקטרום הרעש הלבן. רוחב פס.
  • אמורה להתבצע הליכה אקראית של האצה בפחות מ-30 μg תמצאו ב- Wi-Fi בטמפרטורת החדר.
  • אמור להיות שינוי בהטיה לעומת טמפרטורה של ≤ +/- 1 mg/°C .
  • אמור להיות קו הכי מתאים של לא ליניאריות של ≤ 0.5%, ושינוי הרגישות לעומת הטמפרטורה הוא ≤ 0.03%/C°.
  • אמורה להיות רגישות חוצה-צירים של < 2.5 % ווריאציה של הרגישות של צירים שונים < 0.2% בטווח טמפרטורת הפעולה של המכשיר.

• [C-2-2] חייב להיות TYPE_ACCELEROMETER_UNCALIBRATED עם אותו ערך דרישות איכות כמו TYPE_ACCELEROMETER.

• [C-2-3] חייב להיות חיישן TYPE_GYROSCOPE שמאפשר:

  • טווח המדידה חייב להיות בין -1000 ל- +1000 dps.
  • רזולוציית המדידה חייבת להיות לפחות 16 LSB/dps.
  • תדירות המדידה המינימלית חייבת להיות 12.5Hz או נמוכה יותר.
  • תדירות המדידה המקסימלית חייבת להיות 400 Hz או יותר. אמור תומכים ב-SensorDirectChannel RATE_VERY_FAST.
  • הרעש במדידה חייב להיות נמוך מ-0.014°/s/לצאת.
  • [C-SR-2] מומלץ מאוד שרוחב הפס למדידה של 3dB יהיה בגודל של לפחות 80% מתדר ה-Nyquist וספקטרום הרעש הלבן. רוחב פס.
  • צריכה להיות הליכה אקראית של קצב של פחות מ- 0.001 °/s תמצאו Hz בחדר לטמפרטורה.
  • אמור להיות שינוי בהטיה לעומת טמפרטורה של ≤ +/- 0.05 °C/ s / °C.
  • צריך להיות שינוי ברגישות לעומת הטמפרטורה של 0.02% / °C.
  • הקו המתאים ביותר צריך להיות לא ליניארי, כלומר 0.2% או פחות.
  • צפיפות הרעש אמורה להיות ≤ 0.007 °/s/COLUMNHz.
  • אמורה להיות שגיאת כיול בגודל של פחות מ-0.002 rad/s טווח טמפרטורות 10 ~ 40°C כשהמכשיר נייח.
  • הרגישות ל-g צריכה להיות נמוכה מ-0.1°/s/g.
  • אמורה להיות רגישות חוצה-צירים של < 4.0 % ורגישות לרוחב צירים וריאציה < 0.3% בטווח טמפרטורת הפעולה של המכשיר.

• [C-2-4] חובה לספק TYPE_GYROSCOPE_UNCALIBRATED באיכות זהה בדרישות האלה, TYPE_GYROSCOPE.

• [C-2-5] חייב להיות חיישן TYPE_GEOMAGNETIC_FIELD שמאפשר:

  • טווח המדידה חייב להיות בין -900 ל- +900 μT.
  • רזולוציית המדידה חייבת להיות לפחות 5 LSB/uT.
  • תדירות המדידה המינימלית חייבת להיות 5Hz או נמוכה יותר.
  • תדירות המדידה המקסימלית חייבת להיות 50Hz או יותר.
  • הרעש במדידה חייב להיות נמוך מ-0.5 UT.

• [C-2-6] חובה לספק TYPE_MAGNETIC_FIELD_UNCALIBRATED באיכות זהה דרישות כמו TYPE_GEOMAGNETIC_FIELD ובנוסף:

  • חובה להשתמש בחיישן הזה בצורת חיישן שלא נכנס למצב שינה עם אגירת נתונים יכולת של 600 אירועי חיישנים לפחות.
  • [C-SR-3] מומלץ מאוד להשתמש בספקטרום של רעש לבן מ-1 הרץ עד לפחות 10 Hz כשקצב הדיווח הוא 50Hz או יותר.

• [C-2-7] חייב להיות חיישן TYPE_PRESSURE שמאפשר:

  • טווח המדידה חייב להיות בין 300 ל-1100 hPa.
  • רזולוציית המדידה חייבת להיות לפחות 80 LSB/hPa.
  • תדירות המדידה המינימלית חייבת להיות 1 Hz או נמוכה יותר.
  • תדירות המדידה המקסימלית חייבת להיות 10Hz או יותר.
  • הרעש במדידה חייב להיות נמוך מ-2 Pa/😂.
  • חובה להשתמש בחיישן הזה בצורת חיישן שלא נכנס למצב שינה עם אגירת נתונים יכולת של 300 אירועי חיישן לפחות.
  • צריכת החשמל באצווה חייבת להיות נמוכה מ-2 מגה-ואט.

• [C-2-8] חייב להיות חיישן TYPE_GAME_ROTATION_VECTOR.

• [C-2-9] חייב להיות חיישן TYPE_SIGNIFICANT_MOTION ש:

  • צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי ו- 1.5 mW כשהמכשיר נמצא בתנועה.

• [C-2-10] חייב להיות חיישן TYPE_STEP_DETECTOR ש:

  • חובה להשתמש בחיישן הזה בצורת חיישן שלא נכנס למצב שינה עם אגירת נתונים יכולת של 100 אירועי חיישן לפחות.
  • צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי ו- 1.5 mW כשהמכשיר נמצא בתנועה.
  • צריכת החשמל באצווה חייבת להיות נמוכה מ-4 מגה-ואט.

• [C-2-11] חייב להיות חיישן TYPE_STEP_COUNTER ש:

  • צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי ו- 1.5 mW כשהמכשיר נמצא בתנועה.

• [C-2-12] חייב להיות חיישן TILT_DETECTOR ש:

  • צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי ו- 1.5 mW כשהמכשיר נמצא בתנועה.

• [C-2-13] חותמת הזמן של האירוע של אותו אירוע פיזי שדווח על ידי מד התאוצה, הג'יירוסקופ והמגנטומטר חייבים להיות בטווח של 2.5 אלפיות השנייה שתי רשתות נוירונים זו מול זו. חותמת הזמן של האירוע של אותו אירוע פיזי שדווח על ידי מד התאוצה והג'ירוסקופ צריכים להיות בטווח של 0.25 אלפיות שנייה מכל אחד אחר.

• [C-2-14] חותמות הזמן של אירועים מחיישן הג'ירוסקופ צריכות להיות מוצגות באותו הזמן בתור מערכת המשנה של המצלמה, ותוך אלפיות שנייה אחת משגיאה.

• [C-2-15] חובה לשלוח דגימות לאפליקציות תוך 5 אלפיות שנייה השעה שבה הנתונים זמינים באחד מהחיישנים הפיזיים שצוינו למעלה לאפליקציה.

• [C-2-16] אסור שצריכת החשמל תהיה גבוהה מ-0.5 מגה-ואט כשהמכשיר סטטי ו- 2.0 mW כשהמכשיר נמצא בתנועה כששילוב של החיישנים הבאים מופעל:

  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

• [C-2-17] עשויים להיות חיישן TYPE_PROXIMITY, אבל אם קיים חיישן כזה עם יכולת מינימלית של מאגר נתונים זמני של 100 אירועי חיישן.

שימו לב שכל הדרישות של צריכת החשמל בקטע הזה לא כוללות את של מעבד האפליקציות. הוא כולל את הכוח נמשך על ידי כל שרשרת החיישנים - החיישן, כל מעגלים תומכים, מערכת ייעודית לעיבוד חיישנים וכו'.

אם ההטמעות במכשירים כוללות תמיכה ישירה בחיישנים:

• [C-3-1] חובה להצהיר בצורה נכונה על תמיכה בסוגי ערוצים ישירים לדווח על רמת המחירים דרך isDirectChannelTypeSupported ו-getHighestDirectReportRateLevel API.
• [C-3-2] חייב לתמוך לפחות באחד משני סוגי הערוצים הישירים של חיישנים לכל החיישנים שמצהירים על תמיכה בערוץ ישיר של חיישן.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• צריכה לתמוך בדיווח על אירועים דרך ערוץ ישיר של חיישן חיישן (וריאנט ללא מצב שינה) מהסוגים הבאים:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. חיישנים ביומטריים

רקע נוסף על מדידת אבטחה ביומטרית לביטול נעילה, אפשר לעיין במאמר מסמכי תיעוד בנושא אבטחה ביומטרית.

אם הטמעתם במכשיר מסך נעילה מאובטח:

• צריכה לכלול חיישן ביומטרי

ניתן לסווג חיישנים ביומטריים כסיווג 3 (לשעבר חזק), Class 2 (לשעבר Weak) או Class 1 (לשעבר Convenience) בהתבסס על שיעורי הזיוף וההתחזות שלהם, ועל האבטחה צינור עיבוד נתונים ביומטרי. הסיווג הזה קובע את היכולות של החיישן הביומטרי צריך להתממשק עם הפלטפורמה ועם צד שלישי תרגום מכונה. החיישנים צריכים לעמוד בדרישות נוספות שמפורטות בהמשך, אם רוצים לסווג אותם כרמה 1, רמה 2 או רמה 3. הנתונים הביומטריים של רמה 2 וגם של סיווג 3 מקבלים יכולות נוספות: כמפורט בהמשך.

אם ההטמעות במכשיר מאפשרות לצד שלישי גישה לחיישן ביומטרי אפליקציות דרך android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt, וגם android.provider.Settings.ACTION_BIOMETRIC_ENROLL, הם:

• [C-4-1] האפליקציה חייבת לעמוד בדרישות לדיווח ביומטרי ברמה Class 3 או Class 2 כפי שמוגדר במסמך הזה.
• [C-4-2] חובה לזהות ולכבד כל שם של פרמטר שמוגדר כקבוע בקטע המאמתים והשילובים שלו. לעומת זאת, אסור להכיר בקבועים של מספרים שלמים שמועברים canAuthenticate(int) ו-setAllowedAuthenticator(int) שיטות אחרות שלא מתועדות כקבועים ציבוריים מאמתי חשבונות וכל שילובים שלהם.
• [C-4-3] חובה להטמיע את ACTION_BIOMETRIC_ENROLL פעולה במכשירים עם מידע ביומטרי מסוג רמה 3 או סיווג 2. הפעולה הזו חייבת להציג רק את נקודות הכניסה לרמה 3. או מידע ביומטרי מסוג רמה 2.

אם הטמעות במכשירים תומכים בזיהוי ביומטרי פסיבית:

• [C-5-1] כברירת מחדל חובה לדרוש שלב אישור נוסף (למשל, לחיצה על לחצן).
• [C-SR-1] מומלץ מאוד לקבוע הגדרה שמאפשרת למשתמשים לבטל את ההעדפה של האפליקציה ותמיד להשתמש בתוספות שלב האישור.
• [C-SR-2] מומלץ מאוד לוודא שפעולת האישור מאובטחת כך שמערכת ההפעלה או התוכנה בליבה לא יוכלו לזייף אותה. לדוגמה, המשמעות היא שפעולת האישור מבוססת על לחצן פיזי עובר דרך סיכת קלט/פלט לשימוש כללי (GPIO) בלבד, רכיב מאובטח (SE) שלא ניתן להפעיל באמצעותו שום אמצעי אחר מלבד לחיצה על הלחצן הפיזי.
• [C-5-2] חובה להטמיע גם תהליך אימות מרומז (ללא שלב אישור) שתואם ל- setConfirmationrequired(boolean), אילו אפליקציות יכולות להשתמש בהן לתהליכי כניסה.

אם בהטמעות במכשירים יש כמה חיישנים ביומטריים:

התחלה של דרישות חדשות

• [C-7-1] חובה כאשר מידע ביומטרי נמצא בנעילה (למשל, המידע הביומטרי מושבת עד שהמשתמש מבטל את הנעילה באמצעות אימות ראשי) או נעילה לזמן מוגבל (כלומר, המידע הביומטרי מושבת באופן זמני עד שהמשתמש ימתין זמן מה עקב יותר מדי ניסיונות כושלים, ננעל גם את כל שאר נתונים ביומטריים של קבוצה ביומטרית נמוכה יותר. במקרה של נעילה לזמן מוגבל, זמן ההשהיה לפני ניסיון חוזר לאימות ביומטרי חייב להיות זמן ההשהיה המקסימלי של כל המידע הביומטרי בנעילה מוגבלת בזמן.

• [C-SR-12] מומלץ מאוד כאשר מידע ביומטרי נמצא בנעילה (למשל, המידע הביומטרי מושבת עד שהמשתמש מבטל את הנעילה באמצעות אימות ראשי) או נעילה לזמן מוגבל (כלומר, המידע הביומטרי מושבת באופן זמני עד המשתמש ממתין לפרק זמן מסוים) עקב יותר מדי ניסיונות כושלים, כדי גם לנעול את כל שאר הנתונים הביומטריים מאותו סיווג ביומטרי. במקרה של נעילה לזמן מוגבל, זמן ההשהיה לפני ניסיון חוזר לאימות ביומטרי מאוד מומלץ להגדיר את משך ההשהיה המקסימלי לפני ניסיון חוזר של כל המידע הביומטרי תלוי בזמן בזמן האחרון.

• [C-7-2] חובה לאתגר את המשתמש לגבי האימות הראשי המומלץ (לדוגמה: קוד אימות, קו ביטול נעילה, סיסמה) כדי לאפס את מונה הנעילה של מידע ביומטרי ננעלת מחוץ למכשיר. ייתכן שנאפשר להשתמש בנתונים ביומטריים ברמה 3 כדי לאפס את הנעילה מונה נעול על מידע ביומטרי נעול של אותה רמה או קבוצה נמוכה יותר. רמה 2 או ברמה 1 אסור לאפשר לנתונים ביומטריים להשלים נעילה של איפוס נתונים ביומטריים כלשהם.

סיום הדרישות החדשות

• [C-SR-3] מומלץ מאוד לדרוש אישור ביומטרי אחד בלבד לכל אימות (למשל, אם יש גישה גם לחיישני טביעות האצבע וגם לחיישן הפנים במכשיר, onAuthenticationSueded יש לשלוח לאחר אישור אחד מהם).

כדי שהטמעות המכשירים יאפשרו גישה למפתחות של מאגר מפתחות אפליקציות צד שלישי:

• [C-6-1] חייבת לעמוד בדרישות של רמה 3, כפי שמוגדר כאן שבהמשך.
• [C-6-2] חובה להציג נתונים ביומטריים של רמה 3 בלבד במהלך האימות מחייב BIOMETRIC_STRONG, או שהאימות מופעל באמצעות CryptoObject.

אם בהטמעות במכשירים רוצים להתייחס לחיישן ביומטרי כמו רמה 1 (לשעבר נוחות), הן:

• [C-1-1] שיעור קבלה שגוי חייב להיות נמוך מ-0.002%.
• [C-1-2] חובה לציין שהמצב הזה עלול להיות פחות מאובטח מקוד אימות חזק. הסיסמה או הדפוס, ולפרט בבירור את הסיכונים שכרוכים בהפעלתו, אם שיעורי האישורים של זיוף והתחזות גבוהים מ-7%, כפי שנמדד על ידי פרוטוקולים לבדיקה של נתונים ביומטריים במערכת Android.
• [C-1-9] חובה לאתגר את המשתמש לגבי האימות הראשי המומלץ (למשל, קוד אימות, קו ביטול נעילה, סיסמה) אחרי עשרים ניסיונות שווא, פחות מתשעים שניות לפני ניסיון חוזר לצורך אימות ביומטרי, כאשר ניסוי שקרי הוא ניסיון עם איכות צילום הולמת (BIOMETRIC_ACQUIRED_GOOD) שלא תואם למידע ביומטרי רשום.
• [C-SR-4] מומלץ מאוד להקטין את המספר הכולל של הניסיונות השגויים לאימות ביומטרי שמצוין בסעיפים [C-1-9], אם הזיוף והמתחזה שיעורי הקבלה גבוהים מ-7% כפי שנמדד על ידי הנתונים הביומטריים של Android פרוטוקולים של בדיקה.
• [C-1-3] חובה לנסות להגבלת קצב של יצירת הבקשות לאימות ביומטרי, כאשר מספר ניסוי שקרי הוא ניסיון עם איכות צילום הולמת (BIOMETRIC_ACQUIRED_GOOD) שלא תואם למידע ביומטרי רשום.
• [C-SR-5] מומלץ מאוד להגביל את מספר הניסיונות להגבלת קצב של יצירת בקשות לפחות 30 שניות לאחר חמש ניסויי שווא לאימות ביומטרי עבור המספר המקסימלי של בדיקות שווא לכל [C-1-9] - כאשר ניסיון שווא הוא אחד איכות צילום הולמת (BIOMETRIC_ACQUIRED_GOOD) שלא תואמת מידע ביומטרי רשום.
• [C-SR-6] מומלץ מאוד להפעיל את כל הלוגיקה של הגבלת קצב של יצירת בקשות ב-TEE.

• [C-1-10] חובה להשבית את המידע הביומטרי לאחר ההשהיה לפני ניסיון חוזר של האימות הראשי מופעלת לראשונה, כפי שמתואר בקטע [C-0-2] של סעיף 9.11.

• [C-1-11] שיעור הבקשות של זיוף ומתחזה חייב להיות נמוך מ-30%, עם (1) שיעור הצטרפות של מתחזה ומתחזה למצגת ברמה א' מין של כלי תקיפה (PAI) שגודלם לא עולה על 30%, ו-(2) זיוף שיעור קבלת המתחזה של מין PAI ברמה B שאינו גבוה מ-40%, כמו שנמדדות על ידי הפרוטוקולים של הבדיקה הביומטרית של Android.

• [C-1-4] חובה למנוע הוספה של מידע ביומטרי חדש בלי לאמת קודם שרשרת אמון, באמצעות בקשה מהמשתמש לאשר קיים או להוסיף מכשיר חדש פרטי כניסה (קוד אימות/דפוס/סיסמה) שמאובטחים על ידי TEE, Android Open הטמעת פרויקט מקור מספקת בתוך המסגרת את המנגנון לביצוע אז.

• [C-1-5] חובה להסיר לחלוטין את כל הנתונים הביומטריים שניתנים לזיהוי של המשתמש כשמסירים את החשבון של המשתמש (כולל באמצעות איפוס להגדרות המקוריות).

• [C-1-6] חובה לכבד את הדגל הספציפי של אותו מידע ביומטרי (למשל, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT DevicePolicymanager.KEYGUARD_DISABLE_FACE , או DevicePolicymanager.KEYGUARD_DISABLE_IRIS ).

• [C-1-7] חובה לאתגר את המשתמש לגבי האימות הראשי המומלץ (למשל, קוד אימות, קו ביטול נעילה, סיסמה) פעם ב-24 שעות או פחות. הערה: שדרוג מכשירים שהושקו ב-Android מגרסה 9 ומטה חייבים לבקש מהמשתמש לבצע את האימות הראשי המומלץ (למשל קוד אימות, קו ביטול נעילה, סיסמה) אחת ל-72 שעות או פחות.

• [C-1-8] חובה לאתגר את המשתמש לתחרות הראשית המומלצת אימות (למשל: קוד אימות, קו ביטול נעילה, סיסמה) או מידע ביומטרי ברמה 3 (חזק) אחרי אחד מהתנאים הבאים:

  • פרק זמן של 4 שעות ללא פעילות, או
  • 3 ניסיונות לאימות ביומטרי שנכשלו.
  • פרק הזמן הקצוב לתפוגה שהוגדר לחוסר פעילות וספירת האימות שנכשלה תאופס אחרי כל אישור של פרטי הכניסה של המכשיר. הערה: שדרוג מכשירים שהושקו ב-Android גרסה 9 או גרסאות קודמות עשוי להיות פטור מ-C-1-8.

• [C-SR-7] מומלץ מאוד להשתמש בלוגיקה במסגרת המסגרת הרעיונית בפרויקט הקוד הפתוח של Android כדי לאכוף את המגבלות שצוינו [C-1-7] ו-[C-1-8] למכשירים חדשים.

• [C-SR-8] מומלץ מאוד ששיעור הדחייה השגוי יהיה נמוך מ- 10%, כפי שנמדד במכשיר.

• [C-SR-9] מומלץ מאוד שזמן האחזור יהיה פחות משנייה אחת, לפי המדידה מרגע הזיהוי של המידע הביומטרי ועד לביטול נעילת המסך, מידע ביומטרי רשום.

התחלה של דרישות חדשות

• [C-1-12] שיעור הבקשות של זיוף והתחזות לא יכול להיות גבוה מ-40% לכל כלי תקיפה של תצוגה (PAI), כפי שנמדד על ידי פרוטוקולים לבדיקה של נתונים ביומטריים ב-Android.

• [C-SR-13] מומלץ מאוד לפרסם זיוף או מתחזה בשיעור של לא יותר מ-30% לכל סוג של כלי תקיפה מסוג מצגת (PAI), כפי שנמדדו על ידי פרוטוקולים לבדיקת נתונים ביומטריים של Android.

• [C-SR-14] מומלץ מאוד לחשוף את הסיווג הביומטרי של מהחיישן הביומטרי והסיכונים הקשורים להפעלתו.

• [C-SR-17] מומלץ מאוד להטמיע את ממשקי AIDL החדשים (למשל: IFace.aidl ו-IFingerprint.aidl).

סיום הדרישות החדשות

אם בהטמעות במכשירים רוצים להתייחס לחיישן ביומטרי כמו רמה 2 (לשעבר חלשות), הן:

• [C-2-1] חייבת לעמוד בכל הדרישות של רמה 1 שמפורטות למעלה.

• [C-2-2] שיעור הבקשות של זיוף ומתחזה חייב להיות נמוך מ-20%, עם (1) שיעור הסכמה של זיוף ומתחזה מין של כלי תקיפה מסוג מצגת ברמה A (PAI) שאינם גבוהים מ-20%, ו-(2) שיעור הבקשות של זיוף ומתחזה של מינים שונים של PAI ברמה B. גבוה מ-30%, כפי שנמדד על ידי פרוטוקולים לבדיקה של נתונים ביומטריים במערכת Android.

התחלה של דרישות חדשות

• [C-SR-15] מומלץ מאוד לפרסם זיוף או מתחזה שיעור שאינו גבוה מ-20% לכל כלי מתקפה מסוג מצגת (PAI) , כפי שנמדד פרוטוקולים לבדיקה של נתונים ביומטריים ב-Android.

סיום הדרישות החדשות

• [C-2-3] חייבים לבצע את התאמה ביומטרית בסביבת ביצוע מבודדת מחוץ ל-Android של המשתמש או של הליבה שלו, למשל סביבת ביצוע מהימנה (TEE), או בצ'יפ עם ערוץ מאובטח לסביבת ההפעלה המבודדת או במכונה וירטואלית מוגנת שעומדת בדרישות שמפורטות בסעיף 9.17.
• [C-2-4] כל הנתונים המזהים צריכים להיות מוצפנים וקריפטוגרפיים. שעברו אימות כך שלא ניתן יהיה לרכוש אותם, לקרוא אותם או לשנות אותם מחוץ ל את סביבת הביצוע המבודדת או צ'יפ עם ערוץ מאובטח סביבת הפעלה מבודדת, כפי שמתועד בהטמעה הנחיות באתר פרויקט הקוד הפתוח של Android או מכונה וירטואלית מוגנת שנשלטת על ידי hypervisor שעומדת בדרישות שמפורטות בסעיף 9.17.
• [C-2-5] למידע ביומטרי שמבוסס על מצלמה, תוך אימות ביומטרי או מתבצע רישום:
  • חובה להפעיל את המצלמה במצב שמונע מפריימים של המצלמה קריאה או שינוי מחוץ לסביבת הביצוע המבודדת או בצ'יפ באמצעות ערוץ מאובטח לסביבת ההפעלה המבודדת או מכונה וירטואלית מוגנת שנשלטת על ידי hypervisor שעומדת בדרישות שמפורטות בסעיף 9.17.
  • בפתרונות RGB למצלמה אחת, ניתן להשתמש בפריימים של המצלמה קריא מחוץ לסביבת הביצוע המבודדת כדי לתמוך בפעולות כמו תצוגה מקדימה להרשמה, אבל עדיין אסור שתהיה אפשרות לשנות אותה.
• [C-2-6] אסור לאפשר לאפליקציות של צד שלישי להבחין בין נתונים ביומטריים אישיים.
• [C-2-7] אסור לאפשר גישה לא מוצפנת לנתונים ביומטריים שניתנים לזיהוי, או את הנתונים הנובעים ממנו (כגון הטמעות) אל מעבד האפליקציות מחוץ להקשר של שעון TEE או המכונה הווירטואלית המוגנת בשליטת hypervisor שעומדת בדרישות שמפורטות בסעיף 9.17. מכשירים משודרגים שהושקו בגרסת Android 9 או גרסאות קודמות לא פטורים מ-C-2-7.

• [C-2-8] חייב להיות צינור עיבוד נתונים מאובטח, כך פגיעה במערכת או בליבה לא יכולה לאפשר להחדיר נתונים ישירות לבצע אימות שקרי כמשתמש. הערה: אם הטמעות המכשיר כבר הושקו ב-Android בגרסה 9 או גרסאות קודמות ולא יכולים לעמוד בדרישה של C-2-8 דרך תוכנת מערכת ייתכן שהם יהיו פטורים מהדרישה הזו.

• [C-SR-10] מומלץ מאוד לכלול זיהוי מצב חיים לכולם שיטות ביומטריות וזיהוי תשומת לב לזיהוי ביומטרי של פנים.

• [C-2-9] החיישן הביומטרי חייב להיות זמין לצד שלישי תרגום מכונה.

אם בהטמעות במכשירים רוצים להתייחס לחיישן ביומטרי כמו רמה 3 (לשעבר Strong), הן:

• [C-3-1] חייב לעמוד בכל הדרישות של סיווג 2 שלמעלה, מלבד [C-1-7] ו-[C-1-8].
• [C-3-2] חייבת להיות הטמעה של מאגר מפתחות שמגובה בחומרה.
• [C-3-3] שיעור הבקשות של זיוף והתחזות לא יכול להיות גבוה מ-7%, עם (1) שיעור הסכמה של זיוף ומתחזה מין של כלי תקיפה מסוג PAI (רמה A) שלא עולה על 7%, ו (2) שיעור הבקשות של זיוף והתחזות למין PAI ברמה B לא גבוה יותר מ-20%, כפי שנמדד על ידי פרוטוקולים לבדיקה של נתונים ביומטריים במערכת Android.
• [C-3-4] חובה לאתגר את המשתמש לתחרות הראשית המומלצת אימות (למשל, קוד אימות, קו ביטול נעילה, סיסמה) פעם אחת בכל 72 שעות או פחות.
• [C-3-5] חובה ליצור מחדש מזהה מאמת לכל המידע הביומטרי ברמה 3 שנתמך במכשיר, אם אחת מהן נרשמו מחדש.
• [C-3-6] חובה להפעיל לצד שלישי מפתחות של מאגר מפתחות עם גיבוי ביומטרי תרגום מכונה.

פנייה לדרישות חדשות

• [C-SR-16] מומלץ מאוד לפרסם זיוף או מתחזה בשיעור של לא יותר מ-7% לכל מין של כלי תקיפה מסוג מצגת (PAI), כפי שנמדדו על ידי פרוטוקולים לבדיקת נתונים ביומטריים של Android.

סיום הדרישות החדשות

אם בהטמעות המכשיר יש חיישן טביעות אצבע מתחת למסך (UDFPS), הם:

• [C-SR-11] מומלץ מאוד למנוע את האזור שאפשר לגעת בו ב-UDFPS מהפרעה לניווט ב-3 לחצנים( חלק מהמשתמשים עשויים להזדקק לו למטרות נגישות).

7.3.11. חיישן תנוחה

הטמעות מכשירים:

• MAY תמיכה בחיישן תנוחה עם 6 דרגות חופש.

אם יישומים של מכשירים תומכים בחיישן תנוחת מיקום עם 6 דרגות חופש:

• [C-1-1] חובה להטמיע את TYPE_POSE_6DOF ולדווח עליו באמצעות חיישן.
• [C-1-2] חייב להיות מדויק יותר מהווקטור הסיבוב לבדו.

7.3.12. חיישן זווית ציר

אם בהטמעות במכשירים יש תמיכה בחיישן זווית של ציר:

• [C-1-1] חובה להטמיע את TYPE_HINGLE_ANGLE ולדווח עליו.
• [C-1-2] חייבת לתמוך לפחות בשתי קריאות בין 0 ל-360 מעלות (כולל, למשל 0 ו-360 מעלות).
• [C-1-3] חייב להחזיר התעוררות החיישן של getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

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 של unicast בהגדרת FiRa, מצב דחוי, טווח של 240 אלפיות השנייה.
  • CONFIG_ID_2: טווח STATIC STS DS-TWR בהגדרת FiRa, אחד לרבים, מצב דחוי, טווח של 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, עותק מוסתר וגם CSA דואגת לכך שהגדרה 802.1.15.4 תפעל בצורה תקינה.

סיום הדרישות החדשות

7.4. קישוריות נתונים

7.4.1. טלפוניה

המונח "טלפוניה" כפי שנעשה בו שימוש בממשקי ה-API של Android, והמסמך הזה מתייחס באופן ספציפי לחומרה שקשורה לביצוע שיחות קוליות ולשליחת הודעות SMS , או ביסוס נתונים סלולריים באמצעות רשת סלולרית (למשל, רשת GSM, CDMA, LTE, NR) או רשת CDMA. מכשיר שתומך ב'טלפוניה' עשוי להציע חלק משירותי השיחה, העברת ההודעות והנתונים, או את כולם, בהתאם למוצר.

דרך רשת GSM או CDMA. למרות שהשיחות הקוליות האלה לא בהכרח יעברו בין חבילות,הן מיועדות ל-Android שנחשבות לבלתי תלויות בקישוריות נתונים שעשויות להיות מוטמעות באמצעות אותה רשת. במילים אחרות,הפונקציונליות וממשקי ה-API של "טלפוניה" ב-Android מתייחסים באופן ספציפי לשיחות קוליות ול-SMS. לדוגמה, יישומים של מכשירים שלא יכולים לבצע שיחות או לשלוח/לקבל הודעות SMS אינם נחשבים למכשיר טלפוניה, גם אם הם משתמשים ברשת סלולרית וגם אם הם משתמשים בחיבור נתונים.

• ניתן להשתמש ב-Android MAY במכשירים שלא כוללים חומרת טלפון. ש Android תואם למכשירים שאינם טלפונים.

אם ההטמעות של המכשירים כוללות טלפוניה מסוג GSM או CDMA, הן:

• [C-1-1] חובה להצהיר על דגל הפיצ'ר android.hardware.telephony סימונים של תכונות משנה אחרות בהתאם לטכנולוגיה.
• [C-1-2] חייבים להטמיע תמיכה מלאה ב-API בטכנולוגיה הזו.
• צריכה לאפשר את כל סוגי השירותים הסלולריים הזמינים (2G, 3G, 4G, 5G וכו') במהלך שיחות חירום (ללא קשר לסוגי הרשתות שהוגדרו SetAllowedNetworkTypeBitmap()).

אם ההטמעות של מכשירים לא כוללות חומרת טלפון:

• [C-2-1] חובה להטמיע את כל ממשקי ה-API כללא תפעול.

אם בהטמעות המכשיר יש תמיכה ב-eUICC, בכרטיסי eSIM או בכרטיסי SIM מוטמעים, וגם מנגנון קנייני להפיכת הפונקציונליות של eSIM לזמינה עבור צדדים שלישיים מפתחים:

• [C-3-1] חובה להצהיר על android.hardware.telephony.euicc דגל של פיצ'ר.

אם יישומי המכשיר לא מגדירים את מאפיין המערכת ro.telephony.iwlan\_operation\_mode כ'מדור קודם', הם:

• [C-4-1] אסור לדווח על NETWORK_TYPE_IWLAN באמצעות NetworkRegistrationInfo#getAccessNetworkTechnology() כאשר NetworkRegistrationInfo#getTransportType() מדווח כ-'TRANSPORT_TYPE_WWAN' עבור אותה מופע NetworkRegistrationInfo.

אם בהטמעות של המכשיר יש תמיכה בתת-מערכת מולטימדיה אחת (IMS) של IP הרשמה לשירות טלפוניה מולטימדיה (MMTEL) וגם תכונות של שירותי תקשורת מגוונים (RCS) וצפויים לעמוד בדרישות עם דרישות של ספק סלולר בנוגע לשימוש רישום IMS לכל תנועת ה-IMS שמצביעה על תנועה, אנשי החברה:

• [C-5-1] חובה להצהיר על android.hardware.telephony.ims ולספק יישום מלא של התכונה ImsService API גם ל-MMTEL וגם ל-RCS User Capability Exchange API.
• [C-5-2] חובה להצהיר על android.hardware.telephony.ims.singlereg סימון תכונה חדשה ולספק הטמעה מלאה של SipTransport API, GbaService API, אינדיקציה למוכ"ז ייעודי באמצעות IRadio 1.6 HAL והקצאה באמצעות שרת הגדרה אוטומטית (ACS) או הקצאה קניינית אחרת באמצעות IMS Configuration API.

אם הטמעות המכשירים מדווחות על התכונה android.hardware.telephony, אז:

• [C-6-1] SmsManager#sendTextMessage ו-SmsManager#sendMultipartTextMessage התוצאות חייבות להוביל לקריאות תואמות אל CarrierMessagingService לצורך אספקת פונקציונליות של העברת הודעות טקסט. SmsManager#sendMultimediaMessage וגם SmsManager#downloadMultimediaMessage התוצאות חייבות להוביל לקריאות תואמות אל CarrierMessagingService לצורך אספקת פונקציונליות של העברת הודעות מולטימדיה.
• [C-6-2] הבקשה שסווגה על ידי android.provider.Telephony.Sms#getDefaultSmsPackage חובה להשתמש SmsManager ממשקי API לשליחה ולקבלה של הודעות SMS ו-MMS. מסמך העזר של AOSP בחבילות/באפליקציות או ב'העברת הודעות', עומדים בדרישה הזו.
• [C-6-3] האפליקציה שמגיבה Intent#ACTION_DIAL חייבת להיות תמיכה בהזנה של קודי חייגן שרירותיים בפורמט *#*#CODE#*#* וכן מפעילה TelephonyManager#ACTION_SECRET_CODE שידור.
• [C-6-4] האפליקציה שמגיבה Intent#ACTION_DIAL חובה להשתמש VoicemailContract.Voicemails#TRANSCRIPTION כדי להציג למשתמשים תמלול של דואר קולי ויזואלי, אם הוא תומך בפיצ'רים חזותיים תמלול ההודעות הקוליות.
• [C-6-5] חייב לייצג את כל SubscriptionInfo עם נתונים שווי ערך מזהי UUID קבוצתיים כמנוי יחיד בכל העלויות הגלויות למשתמשים שמציגים שליטה בפרטי כרטיס ה-SIM. דוגמאות להוצאות כאלה כוללות הגדרות ממשקים שתואמים Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS או EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
• [C-6-6] אסור להציג או לאפשר שליטה ב-SubscriptionInfo עם UUID של קבוצה שאינו null וביט הזדמנויות בכל מחיר שנראה למשתמש לאפשר הגדרה או שליטה בהגדרות של כרטיס SIM.

אם בהטמעות המכשירים מדווחות על התכונה android.hardware.telephony ומספקים שורת סטטוס מערכת, ואז:

• [C-7-1] חובה לבחור מינוי פעיל שמייצג UUID קבוצתי להצגה למשתמש תמורת הטבות שניתנות עבור סטטוס כרטיס ה-SIM. מידע. דוגמאות להוצאות כאלה כוללות את שורת הסטטוס 'סלולרי' סמל האות או לחצן ההגדרות המהירות.
• [C-SR-1] מומלץ מאוד שהמינוי של הנציג נבחר להיות מינוי לנתונים פעילים אלא אם המכשיר הוא בקול שבמהלכה מומלץ מאוד שהנציג המינוי הוא המינוי הפעיל ל-Voice.

אם הטמעות המכשירים מדווחות על התכונה android.hardware.telephony, אז:

• [C-6-7] חייבת להיות יכולת לפתוח ולנצל בו-זמנית את הערך המקסימלי מספר הערוצים הלוגיים (20 בסך הכול) לכל UICC בהתאם לתקן ETSI TS 102 221.
• [C-6-8] אסור להחיל אף אחת מההתנהגויות הבאות על אפליקציות ספק פעילות (כפי שהוגדר על ידי TelephonyManager#getCarrierServicePackageName) באופן אוטומטי או ללא אישור מפורש של המשתמש:
  • ביטול הגישה לרשת או הגבלה שלה
  • ביטול הרשאות
  • הגבלת הביצוע של אפליקציות ברקע או בחזית מעבר לתכונות ניהול צריכת החשמל הקיימות שכלולות ב-AOSP
  • השבתה או הסרה של האפליקציה

אם ההטמעה של המכשירים מדווחת על התכונה android.hardware.telephony וגם כל הפעילות, מינויים לא הזדמנויות שחולקים מזהה ייחודי אוניברסלי (UUID) של קבוצה מושבתים, הוסר פיזית מהמכשיר, או מסומן כיצירתי, אז המכשיר:

• [C-8-1] חובה להשבית באופן אוטומטי את כל שאר הפעילויות הפעילות הזדמנויות למינויים באותה קבוצה.

אם אופן ההטמעה של המכשירים כולל טלפוניה GSM אבל לא טלפוניה מסוג CDMA, הם:

• [C-9-1] אסור להצהיר על PackageManager#FEATURE_TELEPHONY_CDMA.
• [C-9-2] חובה להשליך IllegalArgumentException בניסיון לקבוע סוגי רשתות 3GPP2 במסיכות ביט מסוג רשת מועדף או מותר.
• [C-9-3] חייבת להחזיר מחרוזת ריקה מ: TelephonyManager#getMeid

אם בהטמעות המכשיר תומכות ב-eUICC עם כמה יציאות ופרופילים, הן:

• [C-10-1] חובה להצהיר על android.hardware.telephony.euicc.mep דגל של פיצ'ר.

7.4.1.1. תאימות לחסימת מספרים

אם הטמעות במכשירים ידווחו על התכונה android.hardware.telephony.calling, הן:

• [C-1-1] חייבת לכלול תמיכה בחסימת מספרים
• [C-1-2] חובה להטמיע את BlockedNumberContract באופן מלא וממשק ה-API התואם, כפי שמתואר במסמכי התיעוד של ה-SDK.

• [C-1-3] חובה לחסום את כל השיחות וההודעות ממספר טלפון אחד 'BlockNumberProvider' ללא אינטראקציה עם האפליקציות. יוצא הדופן היחיד היא תופסק כשחסימת המספרים תופסק באופן זמני, כפי שמתואר ב-SDK התיעוד.

• [C-1-4] חובה לכתוב אל ספק יומן השיחות בפלטפורמה עבור שיחה שנחסמה וחובה לסנן שיחות עם BLOCKED_TYPE תצוגת ברירת המחדל של יומן השיחות באפליקציית החייגן שהותקנה מראש.

• [C-1-5] אסור לכתוב לספק הטלפוניה להודעה שנחסמה.

• [C-1-6] חובה להטמיע ממשק משתמש חסום לניהול מספרים, שנפתח עם הכוונה שהוחזרה על ידי TelecomManager.createManageBlockedNumbersIntent() .

• [C-1-7] אסור לאפשר למשתמשים משניים לצפות במספרים החסומים או לערוך אותם במכשיר, כי פלטפורמת Android מניחה שהמשתמש הראשי שליטה בשירותי הטלפוניה, מכונה אחת, במכשיר. הכול ממשק משתמש קשור לחסימה חייב להיות מוסתר אצל משתמשים משניים והרשימה החסומה חייבת להיות מוסתרת עדיין יש לכבד אותם.

• צריך להעביר את המספרים החסומים לספק כשמכשיר מתעדכן ל-Android 7.0.

• האפליקציה צריכה לאפשר למשתמש להציג שיחות חסומות במכשירים שמותקנים מראש אפליקציית חייגן.

7.4.1.2. API של Telecom

אם הטמעות המכשירים ידווחו על android.hardware.telephony.calling, הן:

• [C-1-1] חייבת לתמוך בממשקי ה-API של ConnectionService שמתוארים ב-SDK.
• [C-1-2] חובה להציג שיחה נכנסת חדשה ולספק למשתמש אפשרויות עבור אישור או דחייה של השיחה הנכנסת כשמשתמש בשיחה פעילה נוצר על ידי אפליקציית צד שלישי שלא תומכת בתכונת ההשהיה צוין דרך CAPABILITY_SUPPORT_HOLD
• [C-1-3] חייבת להיות אפליקציה שמממשת InCallService.

• [C-SR-1] מומלץ מאוד להודיע למשתמש שעונה על השיחה הנכנסת תנתק את השיחה הנוכחית.

  הטמעת ה-AOSP עומדת בדרישות האלה בהתראה 'שימו לב' שמציינת למשתמש שמענה לשיחה נכנסת יגרום הקריאה האחרת תושג.

• [C-SR-2] מומלץ מאוד לטעון מראש את אפליקציית החייגן שמוגדרת כברירת מחדל מציגה רשומה ביומן השיחות ואת השם של אפליקציה של צד שלישי ביומן השיחות שלה. כשאפליקציית הצד השלישי מגדירה EXTRA_LOG_SELF_MANAGED_CALLS מקש תוספות בPhoneAccount עד true.

• [C-SR-3] מומלץ מאוד לטפל באוזניות אירועים של KEYCODE_MEDIA_PLAY_PAUSE ו-KEYCODE_HEADSETHOOK עבור android.telecom ממשקי API הבאים:

  • התקשרות אל Connection.onDisconnect() כשמזוהה לחיצה קצרה על האירוע המרכזי במהלך שיחה פעילה.
  • התקשרות אל Connection.onAnswer() כשמזוהה לחיצה קצרה על האירוע המרכזי במהלך שיחה נכנסת.
  • התקשרות אל Connection.onReject() כשמזוהה לחיצה ארוכה על האירוע המרכזי במהלך שיחה נכנסת.
  • החלפת מצב ההשתקה של CallAudioState.

7.4.1.3. העברה ל-Keepalive לרשת סלולרית מסוג NAT-T

הטמעות מכשירים:

• היא צריכה לכלול תמיכה בהפחתה לעומס (Keepalive) ברשת סלולרית.

אם ההטמעות במכשיר כוללות תמיכה בעומס (payalive) לרשת סלולרית, וגם חושפת את הפונקציונליות לאפליקציות צד שלישי, היא:

• [C-1-1] חייבת לתמוך ב-SocketKeepAlive API.
• [C-1-2] חייבת להיות תמיכה בלפחות חריץ מודעה אחד בו-זמנית לפחות ברשת סלולרית.
• [C-1-3] חייבת לתמוך בכמה שיותר משבצות שידור פעילות סלולריות בו-זמנית נתמך על ידי HAL של רדיו סלולרי.
• [C-SR-1] מומלץ מאוד לתמוך בלפחות שלושה חיישנים של רשת סלולרית משבצות לכל מופע רדיו.

אם יישומי המכשיר לא כוללים תמיכה בהורדה של עומסי עבודה ברשת סלולרית, הם:

• [C-2-1] חייב להחזיר ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

הטמעות מכשירים:

• היא צריכה לכלול תמיכה עבור צורה אחת או יותר של 802.11.

אם הטמעות המכשירים כוללות תמיכה ב-802.11 וחושפים את פונקציונליות באפליקציה של צד שלישי:

• [C-1-1] חובה להטמיע את Android API התואם.
• [C-1-2] חובה לדווח על הדגל של תכונת החומרה android.hardware.wifi.
• [C-1-3] חובה להטמיע את multicast API כפי שמתואר במסמכי התיעוד של ה-SDK.
• [C-1-4] חייב לתמוך ב-DNS מרובה-מכשירים (mDNS) ואסור לסנן חבילות mDNS (224.0.0.251 או ff02::fb) בכל זמן הפעלה, כולל כשהמסך אינו במצב פעיל, אלא אם שחרור או סינון המנות האלה נדרשים כדי להישאר בטווחי צריכת החשמל הנדרשים על פי רגולציה בדרישות שרלוונטיות לשוק היעד. בהטמעות עבור מכשירי Android TV, אפילו במצב המתנה.
• [C-1-5] אסור לטפל בWifiManager.enableNetwork() הקריאה לשיטת ה-API כאינדיקציה מספקת לשינוי המצב הפעיל הנוכחי Network שמשמש כברירת מחדל לתנועת אפליקציות, ומוחזר מאת ConnectivityManager שיטות API כמו getActiveNetwork וגם registerDefaultNetworkCallback. במילים אחרות, הם עשויים להשבית רק את הגישה לאינטרנט שמסופקת על ידי מישהו ספק רשת אחר (למשל, חבילת גלישה) אם הוא אימת בהצלחה שרשת ה-Wi-Fi מספקת גישה לאינטרנט.
• [C-1-6] מומלץ מאוד במקרים שבהם ConnectivityManager.reportNetworkConnectivity() נקראת 'שיטת ה-API', בדקו מחדש את הגישה לאינטרנט בNetwork. ברגע שההערכה קובעת שה-Network הנוכחי לא מספק יותר גישה לאינטרנט, מעבר לכל רשת זמינה אחרת (למשל, רשת סלולרית שמספק גישה לאינטרנט.
• [C-1-7] כתובת ה-MAC של המקור ומספר הרצף של גליל המכשיר צריכים להיות אקראיים בקשות למסגרות זמן, פעם אחת בתחילת כל סריקה, בזמן ש-STA מנותק.
• [C-1-8] חובה להשתמש בכתובת MAC עקבית אחת (לא צריכה להיות כתובת MAC אקראית כתובת באמצע הסריקה).
• [C-1-9] מספר הרצף של בקשת הבדיקה חייב לחזור כרגיל (ברציפות) בין בקשות גשושיות בסריקה.
• [C-1-10] מספר הרצף של בקשת גשושית הבדיקה צריך להיות אקראי בין גשוש האחרון לבקשת סריקה ובקשת גשושית הסריקה הראשונה של הסריקה הבאה.
• [C-SR-1] מומלץ מאוד להגדיר באקראי את כתובת ה-MAC של המקור את כל התקשורת מסוג STA לנקודת גישה (AP) בזמן השיוך שמשויכים לכל אחד.
  • המכשיר חייב להשתמש בכתובת MAC אקראית שונה לכל SSID (FQDN ל-Passpoint) היא מתקשרת.
  • המכשיר חייב לספק למשתמש אפשרות לשלוט רנדומיזציה לפי SSID (FQDN ל-Passpoint) ללא אקראיות אפשרויות אקראיות, וחייב להגדיר את מצב ברירת המחדל עבור רשתות Wi-Fi חדשות להגדרות אקראיות.
• [C-SR-2] מומלץ מאוד להשתמש ב-BSSID אקראי לכל AP שהם יוצרים.
  • כתובת ה-MAC חייבת להיות אקראית ותישמר בהתאם ל-SSID שמשמש את AP.
  • ייתכן שה-DEVICE יכול לספק למשתמש אפשרות להשבית את התכונה הזו. אם קיימת אפשרות כזו, הרנדומיזציה חייבת להיות מופעלת כברירת מחדל.

אם הטמעות המכשיר כוללות תמיכה במצב חיסכון בסוללה ב-Wi-Fi, כפי שהוגדר בתקן IEEE 802.11 הן:

• יש להשבית את מצב החיסכון בסוללה ב-Wi-Fi בכל פעם שמתקבלת אפליקציה מנעול אחד (WIFI_MODE_FULL_HIGH_PERF) או מנעול WIFI_MODE_FULL_LOW_LATENCY דרך WifiManager.createWifiLock() ו-WifiManager.WifiLock.acquire() ממשקי ה-API והנעילה פעילים.
• [C-3-2] זמן האחזור הממוצע בין המכשיר הלוך ושוב ונקודת גישה כשהמכשיר נמצא בנעילת Wi-Fi עם זמן אחזור נמוך המצב (WIFI_MODE_FULL_LOW_LATENCY) חייב להיות קטן יותר מהמצב זמן אחזור במהלך מצב 'נעילת ביצועים גבוהה' ב-Wi-Fi (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR-3] מומלץ מאוד למזער את זמן האחזור בנסיעה הלוך ושוב של Wi-Fi בכל פעם שמתקבלת נעילה של זמן אחזור קצר (WIFI_MODE_FULL_LOW_LATENCY) ונכנס לתוקף.

אם הטמעות המכשיר תומכות ב-Wi-Fi ומשתמשים ב-Wi-Fi לסריקת מיקום, הם:

• [C-2-1] חובה לספק למשתמשים אפשרות להפעיל או להשבית את הערך שנקרא דרך WifiManager.isScanAlwaysAvailable שיטת ה-API.

7.4.2.1. Wi-Fi ישיר

הטמעות מכשירים:

• אמורה לכלול תמיכה ב-Wi-Fi ישיר (Wi-Fi מקצה לקצה).

אם הטמעות המכשירים כוללות תמיכה ב-Wi-Fi ישיר:

• [C-1-1] חובה להטמיע את Android API התואם כפי שמתואר במסמכי התיעוד של ה-SDK.
• [C-1-2] חובה לדווח על תכונת החומרה android.hardware.wifi.direct.
• [C-1-3] חייבת להיות תמיכה בפעולת Wi-Fi רגילה.
• [C-1-4] חובה לתמוך בפעולות Wi-Fi ו-Wi-Fi ישיר בו-זמנית.
• [C-SR-1] מומלץ מאוד להגדיר באקראי את כתובת ה-MAC של המקור לכולם חיבורי Wi-Fi ישיר שנוצרו לאחרונה.

7.4.2.2. הגדרת קישור ישיר במנהרת Wi-Fi

הטמעות מכשירים:

• צריכה לכלול תמיכה ב הגדרת קישור ישיר במנהרת Wi-Fi (TDLS) כפי שמתואר בתיעוד של Android SDK.

אם הטמעות המכשירים כוללות תמיכה ב-TDLS וב-TDLS מופעל על ידי ב-WiFiManager API, הם:

• [C-1-1] חובה להצהיר על תמיכה ב-TDLS עד WifiManager.isTdlsSupported.
• יש להשתמש ב-TDLS רק כאשר זה אפשרי ומועיל.
• חייבת להיות עם קצת היוריסטיקה ולא להשתמש ב-TDLS כשהביצועים שלה עשויים להיות יותר גרוע מאשר לעבור דרך נקודת הגישה ל-Wi-Fi.

7.4.2.3. עם חיבור ל-Wi-Fi

הטמעות מכשירים:

• צריכה לכלול תמיכה ב-Wi-Fi Aware.

אם הטמעות המכשירים כוללות תמיכה ב-Wi-Fi Aware וחושפים את פונקציונליות של אפליקציות צד שלישי, ואז:

• [C-1-1] חובה להטמיע את ממשקי ה-API של WifiAwareManager כפי שמתואר מסמכי התיעוד של ה-SDK.
• [C-1-2] חובה להצהיר על דגל התכונה android.hardware.wifi.aware.
• [C-1-3] חובה לתמוך בפעולות Wi-Fi ו-Wi-Fi Aware בו-זמנית.
• [C-1-4] הכתובת של ממשק הניהול עם מודעות ל-Wi-Fi צריכה להיות אקראית במרווחי זמן שונים תוך 30 דקות ובכל פעם ש-Wi-Fi Aware מופעל, אלא אם תג Aware פעולת הטווח מתבצעת או שנתיב נתונים של Aware פעיל (האקראי לא פועל צפוי כל עוד נתיב הנתונים פעיל).

אם ההטמעות במכשירים כוללות תמיכה ב-Wi-Fi Aware וגם מיקום Wi-Fi כפי שמתואר בסעיף 7.4.2.5 חושפת את הפונקציות האלה לאפליקציות צד שלישי, ואז:

• [C-2-1] חובה להטמיע את ממשקי ה-API של גילוי מבוסס-מיקום: setRangingEnabled, setMinDestinationMm, setMaxDestinationMm , וגם onServiceDiscoveredWithinRange.

7.4.2.4. Passpoint ל-Wi-Fi

אם הטמעות המכשירים כוללות תמיכה ברשת Wi-Fi 802.11:

• [C-1-1] חייבת לכלול תמיכה ב-Wi-Fi Passpoint.
• [C-1-2] חובה להטמיע את ממשקי ה-API מסוג WifiManager שקשורים ל-Passpoint, בתור כפי שמתואר במסמכי התיעוד של ה-SDK.
• [C-1-3] חייבת לתמוך בתקן IEEE 802.11u, באופן ספציפי לחיפוש ולבחירה ברשת, למשל בפרסומות כלליות Service (GAS) ו-Access Network Query Protocol (ANQP).
• [C-1-4] חובה להצהיר על דגל הפיצ'ר android.hardware.wifi.passpoint.
• [C-1-5] חובה לפעול לפי הטמעת ה-AOSP כדי לגלות, להתאים ולשייך לרשתות Passpoint.
• [C-1-6] חייבת להיות תמיכה לפחות בקבוצת המשנה הבאה של הקצאת מכשירים פרוטוקולים כפי שמוגדרים ב-Wi-Fi Alliance Passpoint R2: EAP-TTLS ו-SOAP-XML.
• [C-1-7] חובה לעבד את אישור שרת AAA כפי שמתואר ב- מפרט של נקודה לשיתוף אינטרנט 2.0 R3.
• [C-1-8] חובה לתמוך בשליטה על הקצאת ההרשאות של המשתמשים באמצעות בורר ה-Wi-Fi.
• [C-1-9] חובה לשמור על הגדרות אישיות של Passpoint בכל הפעלה מחדש.
• [C-SR-1] מומלץ מאוד לתמוך בתנאים ובהגבלות של תכונת הקבלה.
• [C-SR-2] אנחנו ממליצים מאוד לתמוך בפיצ'ר המידע על המקום.

אם קיים מתג Passpoint גלובלי להשבתה של הרשאות המשתמשים, ההטמעות:

• [C-3-1] חייבים להפעיל את Passpoint כברירת מחדל.

7.4.2.5. מיקום Wi-Fi (שעת הלוך ושוב של Wi-Fi – RTT)

הטמעות מכשירים:

• צריכה לכלול תמיכה במיקום Wi-Fi.

אם הטמעות המכשיר כוללות תמיכה במיקום ה-Wi-Fi וחושפים את פונקציונליות של אפליקציות צד שלישי, ואז:

• [C-1-1] חובה להטמיע את ממשקי ה-API של WifiRttManager כפי שמתואר מסמכי התיעוד של ה-SDK.
• [C-1-2] חובה להצהיר על דגל התכונה android.hardware.wifi.rtt.
• [C-1-3] כתובת ה-MAC של המקור חייבת להיות אקראית לכל רצף RTT שמתבצע כאשר ממשק ה-Wi-Fi שבו ה-RTT מופעל לא משויך לנקודת גישה (APN).
• [C-1-4] חייב להיות מדויק בטווח של 2 מטרים ברוחב פס של 80MHz בשלב ה-68 אחוזון (כפי שחושב באמצעות פונקציית ההתפלגות Cumulative).
• [C-SR-1] מומלץ מאוד לדווח על כך באופן מדויק בטווח של 1.5 מטרים ברוחב פס של 80MHz באחוזון 68 (כפי שמחושב באמצעות פונקציית ההתפלגות המצטברת).

7.4.2.6. הסרה של Keepalive ב-Wi-Fi

הטמעות מכשירים:

• צריכה לכלול תמיכה בהורדה של עומסי Keepalive ב-Wi-Fi.

אם יישומי המכשיר כוללים תמיכה בהורדה של עומסי Keepalive ל-Wi-Fi והם חושפים את הפונקציונליות לאפליקציות צד שלישי:

• [C-1-1] חייבת לתמוך ב-API של SocketKeepAlive.
• [C-1-2] חייבת להיות תמיכה לפחות בשלוש משבצות שידור חי בו-זמנית ב-Wi-Fi

אם יישומי המכשיר לא כוללים תמיכה בהורדה של עומסי חיים ב-Wi-Fi, הם:

• [C-2-1] חייב להחזיר ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (פרוטוקול להקצאת מכשירים)

הטמעות מכשירים:

• צריכה לכלול תמיכה ב-Wi-Fi Easy Connect (DPP).

אם יישומי המכשיר כוללים תמיכה ב-Wi-Fi Easy Connect וחושפים את פונקציונליות של אפליקציות צד שלישי:

• [C-1-1] חובה להוסיף את הפרמטר Wi-Manager#isEasyConnectSupported() השיטה מחזירה true.

7.4.2.8. אימות אישור של שרת Wi-Fi ארגוני

אם האישור של שרת ה-Wi-Fi לא מאומת או אם שרת ה-Wi-Fi לא מאומת שם דומיין לא הוגדר, הטמעות מכשירים:

• [C-SR-1] מומלץ מאוד לא לספק למשתמש אפשרות הוספה ידנית של רשת Wi-Fi ארגונית באפליקציית ההגדרות.

7.4.2.9. אמון בשימוש הראשון (TOFU)

אם בהטמעות במכשירים יש תמיכה במהימנות בשימוש הראשון (TOFU) מאפשרות למשתמש לקבוע הגדרות WPA/WPA2/WPA3-Enterprise, ואז:

• [C-4-1] חובה לספק למשתמש אפשרות לבחור להשתמש ב-TOFU.

7.4.3. ‫Bluetooth

אם בהטמעות של המכשיר יש תמיכה בפרופיל Bluetooth Audio, הן:

• צריכה לתמוך ברכיבי קודק אודיו מתקדמים ובקודקי אודיו של Bluetooth (למשל, LDAC)

אם בהטמעות של המכשיר יש תמיכה ב-HFP, ב-A2DP וב-AVRCP:

• צריכה לתמוך בלפחות 5 מכשירים מחוברים בסך הכול.

אם על הטמעות המכשיר מוצהר על android.hardware.vr.high_performance הם:

• [C-1-1] חייבת להיות תמיכה ב-Bluetooth 4.2 ובתוסף אורך נתונים LE של Bluetooth LE.

ב-Android יש תמיכה ב-Bluetooth וב-Bluetooth עם צריכת אנרגיה נמוכה.

אם ההטמעות של המכשיר כוללות תמיכה ב-Bluetooth וב-Bluetooth עם צריכת אנרגיה נמוכה, הם:

• [C-2-1] חובה להצהיר על תכונות הפלטפורמה הרלוונטיות (android.hardware.bluetooth וגם android.hardware.bluetooth_le בהתאמה) ולהטמיע את ממשקי ה-API של הפלטפורמה.
• צריך להטמיע פרופילים רלוונטיים של Bluetooth כמו A2DP, AVRCP, OBEX, HFP וכו', בהתאם למכשיר.

אם הטמעות במכשירים כוללות תמיכה ב‐Bluetooth Low Energy (BLE), הן:

• [C-3-1] חובה להצהיר על תכונת החומרה android.hardware.bluetooth_le.
• [C-3-2] חובה להפעיל Bluetooth (פרופיל מאפיינים גנרי) שמבוסס על GATT ממשקי API כפי שמתואר במסמכי התיעוד של ה-SDK android.bluetooth
• [C-3-3] חובה לדווח על הערך הנכון עבור BluetoothAdapter.isOffloadedFilteringSupported() כדי לציין אם לוגיקת הסינון של ScanFilter מחלקות API מוטמעות.
• [C-3-4] חובה לדווח על הערך הנכון עבור BluetoothAdapter.isMultipleAdvertisementSupported() כדי לציין אם יש תמיכה בפרסום עם צריכת אנרגיה נמוכה.

• [C-3-5] חובה להטמיע זמן קצוב לתפוגה של כתובת פרטית (RPA) שניתנת לפתרון כדי להגן על פרטיות המשתמש, צריך לבצע רוטציה לכתובת URL במשך יותר מ-15 דקות בזמן הקצוב לתפוגה. כשהמכשיר משתמש ב-BLE באופן פעיל לסריקה או פרסום. כדי למנוע התקפות תזמון, פרקי זמן קצובים לתפוגה חייבים להיות אקראיים גם כן בין 5 ל-15 דקות

• צריכה לתמוך בהסרה של לוגיקת הסינון לערכת השבבים של Bluetooth כשמטמיעים את ScanFilter API.

• אמורה לתמוך בהסרה של הסריקה המקובצת לערכת השבבים של Bluetooth.

• צריכה לתמוך במודעות מרובות עם 4 מיקומים לפחות.

אם בהטמעות המכשיר תומכים ב-Bluetooth LE ומשתמשים ב-Bluetooth LE בשביל סריקת מיקום, הם:

• [C-4-1] חובה לספק למשתמשים אפשרות להפעיל או להשבית את הערך שנקרא באמצעות System API BluetoothAdapter.isBleScanAlwaysAvailable().

אם ההטמעות של המכשיר כוללות תמיכה ב-Bluetooth LE ובמכשירי שמיעה פרופיל, כפי שמתואר ב שירותי תמיכה באודיו למכשירי שמיעה באמצעות Bluetooth LE:

• [C-5-1] חייב להחזיר true למשך BluetoothAdapter.getProfileProxy(context, Listener, BluetoothProfile.HEARING_AID).

אם ההטמעות של המכשיר כוללות תמיכה ב-Bluetooth או ב-Bluetooth עם צריכת אנרגיה נמוכה, הם:

• [C-6-1] חובה להגביל את הגישה למטא-נתונים של Bluetooth (כמו סריקה) תוצאות) שניתן להשתמש בהן כדי להסיק את מיקום המכשיר, אלא אם האפליקציה ששלחה את הבקשה מעבירה בהצלחה android.permission.ACCESS_FINE_LOCATION על סמך המצב הנוכחי של החזית/הרקע.

אם ההטמעות של המכשיר כוללות תמיכה ב-Bluetooth או ב-Bluetooth עם צריכת אנרגיה נמוכה קובץ המניפסט של האפליקציה לא כולל הצהרה מהמפתח, שהם לא מפיקים מיקום מ-Bluetooth, ואז:

• [C-6-2] חובה להוסיף שער לגישת Bluetooth מאחורי android.permission.ACCESS_FINE_LOCATION.

אם הטמעות המכשיר מחזירות את הערך true עבור BluetoothAdapter.isLeAudioSupported() API, ואז:

• [C-7-1] חייבת לתמוך בלקוח unicast.
• [C-7-2] חייבת לתמוך ב-2M PHY.
• [C-7-3] חייבת לתמוך בפרסום LE Extended.
• [C-7-4] חייבת להיות תמיכה לפחות בשני חיבורי CIS ב-CIG.
• [C-7-5] חובה להפעיל לקוח BAP unicast, מתאם הגדרות CSIP, שרת MCP, בקר VCP ושרת CCP בו-זמנית.
• [C-SR-1] מומלץ מאוד להפעיל לקוח HAP בפורמט unicast.

אם הטמעות המכשיר מחזירות את הערך true עבור BluetoothAdapter.isLeAudioBroadcastSourceSupported() API, ואז:

• [C-8-1] חייבת לתמוך לפחות בשני קישורי BIS בנכס BIS.
• [C-8-2] חייבים להפעיל את מקור השידור BAP, עוזר השידור של BAP בו-זמנית.
• [C-8-3] חייבת לתמוך בפרסום תקופתי של LE.

אם הטמעות המכשיר מחזירות את הערך true עבור BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API, ואז:

• [C-9-1] חייבת להיות תמיכה ב-PAST (העברה תקופתית של סנכרון הפרסום).
• [C-9-2] חייבת לתמוך בפרסום תקופתי של LE.

אם הטמעות המכשירים מצהירות על FEATURE_BLUETOOTH_LE, הן:

• [C-10-1] מדידות RSSI צריכות להיות בטווח של +/-9dB עבור 95% מדדים במרחק של מטר ממכשיר עזר שמשודר ADVERTISE_TX_POWER_HIGH בקו הראייה.

• [C-10-2] חובה לכלול תיקונים בפורמט Rx/Tx כדי לצמצם את הסטיות בכל ערוץ כך שהמדידות בכל אחד משלושת הערוצים, בכל אחת מהאנטנות (אם משתמשים מרובים), נמצאים בטווח של +/-3dB אחד מהשני למשך 95% מדידות.

• [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 בסריקה מהפניה המכשיר נמצא במרחק של מטר אחד ומשדר ב: 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.4. תקשורת מטווח קצר

הטמעות מכשירים:

• אמורה לכלול משדר וחומרה קשורה לקלט-טווח קצר תקשורת (NFC).
• [C-0-1] חובה להטמיע את android.nfc.NdefMessage וגם android.nfc.NdefRecord ממשקי API, גם אם הם לא כוללים תמיכה ב-NFC או להצהיר על התכונה android.hardware.nfc כי המחלקות מייצגות פורמט ייצוג נתונים שאינו תלוי בפרוטוקול.

אם ההטמעות של המכשירים כוללות חומרת NFC ומתכננים להפוך אותה לזמינה עבור באפליקציות צד שלישי:

• [C-1-1] חובה לדווח על התכונה android.hardware.nfc android.content.pm.PackageManager.hasSystemFeature() method.
• חייבת להיות יכולת לקרוא ולכתוב הודעות NDEF באמצעות ה-NFC הבא כמו שמפורט בהמשך:
• [C-1-2] צריכה להיות יכולת לפעול כקורא/כותב בפורום NFC (כפי שמוגדר במפרט הטכני של פורום NFC NFCForum-TS-DigitalProtocol-1.0) באמצעות תקני NFC הבאים:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • סוגי התגים של פורום NFC 1, 2, 3, 4, 5 (הוגדרו על ידי פורום NFC)

• [C-SR-1] מומלץ מאוד להיות מסוגל לקרוא ולכתוב NDEF הודעות וגם נתונים גולמיים באמצעות תקני NFC הבאים. שימו לב למרות שתקני ה-NFC מפורטים כמומלץ מאוד, אנחנו מתכננים לשנות את הגדרת התאימות לגרסה עתידית חייבים. הסטנדרטים האלה הם אופציונליים בגרסה הזו, אבל הם נדרשים בגרסאות עתידיות. מכשירים קיימים וחדשים שבהם פועלת הגרסה הזו של אנחנו ממליצים מאוד ל-Android לעמוד בדרישות האלה עכשיו, הם יוכלו לשדרג לגרסאות עתידיות של הפלטפורמה.

• [C-1-13] חובה לבצע סקר לכל הטכנולוגיות הנתמכות בזמן גילוי NFC במצב תצוגה.

• אמור להיות במצב גילוי NFC כשהמכשיר לא במצב שינה עם שהמסך פעיל ונעילת המסך בוטלה.

• צריכה להיות מסוגלת לקרוא את הברקוד ואת כתובת האתר (אם מקודדת) של ברקוד NFC של Thinfilm מוצרים.

לתשומת ליבכם: קישורים שזמינים באופן ציבורי לא זמינים ל-JIS, ל-ISO ול-NFC מפרטי הפורום שהוזכרו למעלה.

מערכת Android כוללת תמיכה במצב NFC Host Card Emulation (HCE).

אם הטמעות המכשיר כוללות ערכת שבבים של בקר NFC שמסוגלת לבצע HCE (עבור NfcA ו/או NfcB) ותומכות בניתוב מזהה אפליקציה (AID), הן:

• [C-2-1] חובה לדווח על קבוע התכונה android.hardware.nfc.hce.
• [C-2-2] חייבת לתמוך בממשקי API של NFC HCE בתור שמוגדר ב-Android SDK.

אם הטמעות המכשיר כוללות ערכת שבבים של בקר NFC שמסוגלת לבצע HCE ב-NfcF, ומטמיעים את התכונה באפליקציות צד שלישי:

• [C-3-1] חובה לדווח על קבוע התכונה android.hardware.nfc.hcef.
• [C-3-2] חובה להטמיע את ממשקי ה-API של האמולציה של כרטיסי NfcF כפי שמוגדר ב-Android SDK.

אם יישומים של מכשירים כוללים תמיכה כללית ב-NFC, כפי שמתואר קטע ותמיכה בטכנולוגיות MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF ב-MIFARE Classic) בתפקיד קורא/כתיבה,

• [C-4-1] חובה להטמיע את ממשקי ה-API התואמים של Android כפי שתועד על ידי ערכת ה-SDK של Android.
• [C-4-2] חובה לדווח על התכונה com.nxp.mifare android.content.pm.PackageManager.hasSystemFeature() . לתשומת ליבך, זוהי לא תכונה רגילה של Android, ולכן אין מופיעים כקבוע במחלקה android.content.pm.PackageManager.

7.4.5. פרוטוקולים וממשקי API של רשתות

7.4.5.1. קיבולת רשת מינימלית

הטמעות מכשירים:

• [C-0-1] חייבת לכלול תמיכה באחד או יותר מסוגי רשת נתונים. באופן ספציפי, הטמעות מכשירים חייבות לכלול תמיכה לפחות תקן נתונים אחד עם מהירות של 200 Kbit לשנייה או יותר. דוגמאות של טכנולוגיות שעומדות בדרישה הזו כוללות את EDGE, HSPA, EV-DO, 802.11g, אתרנט ו-Bluetooth PAN.
• היא צריכה לכלול גם תמיכה בנתונים אלחוטיים נפוצים לפחות רגיל, כמו 802.11 (Wi-Fi), כאשר תקן רשת פיזי (כמו אתרנט) הוא חיבור הנתונים הראשי.
• ייתכן שתטמיעו יותר מצורה אחת של קישוריות נתונים.

7.4.5.2. IPv6

הטמעות מכשירים:

• [C-0-2] חובה לכלול סטאק רשתות של IPv6 ולתמוך ב-IPv6 תקשורת באמצעות ממשקי ה-API המנוהלים, כמו java.net.Socket java.net.URLConnection, וגם ממשקי ה-API המקוריים, כמו AF_INET6 שקעים.
• [C-0-3] חייבים להפעיל את IPv6 כברירת מחדל.
  • חייבים לוודא שתקשורת IPv6 אמינה כמו IPv4, לדוגמה:
    • [C-0-4] חייבים לשמור על קישוריות IPv6 במצב 'נמנום'.
    • [C-0-5] הגבלת הקצב של יצירת הבקשות חייבת לא לגרום למכשיר לאבד את כתובת IPv6 בכל רשת תואמת ל-IPv6 שמשתמשת בטווחי חיים RA באורך של 180 שניות לפחות.
• [C-0-6] חובה לספק אפליקציות של צד שלישי עם קישוריות IPv6 ישירה לרשת כאשר הוא מחובר לרשת IPv6, ללא כתובת או תרגום ליציאה המתרחשת באופן מקומי במכשיר. שני ממשקי API מנוהלים כמו Socket#getLocalAddress או Socket#getLocalPort) ו-NDK API כמו getsockname() או IPV6_PKTINFO חייבים להחזיר את כתובת ה-IP הכתובת והיציאה המשמשים בפועל לשליחה ולקבלה של חבילות, רשת וניתן לראות אותה ככתובת ה-IP המקורית וכיציאה לשרתי אינטרנט (אינטרנט).

הרמה הנדרשת של תמיכה ב-IPv6 תלויה בסוג הרשת, כפי שמוצג ב- בדרישות הבאות.

אם הטמעות במכשירים תומכים ב-Wi-Fi:

• [C-1-1] חייבת לתמוך בפעולה כפולה בסטאק וב-IPv6 בלבד ב-Wi-Fi.

אם בהטמעות במכשירים תומכים באתרנט:

• [C-2-1] חייבת לתמוך ב-Dual-stack וב-IPv6 בלבד ב- אתרנט.

אם הטמעות במכשירים תומכים בחבילת הגלישה, הן:

• [C-3-1] חייבת לתמוך בפעולת IPv6 (IPv6 בלבד ואולי גם סטאק כפול) ב- סלולרי.

אם הטמעות במכשירים תומכים ביותר מסוג רשת אחד (למשל, Wi-Fi וחבילת הגלישה), הן:

• [C-4-1] האפליקציה חייבת לעמוד בו-זמנית בדרישות שצוינו למעלה בכל רשת כשהמכשיר מחובר בו-זמנית ליותר מסוג אחד של רשת.

7.4.5.3. פורטלים שבויים

פורטל שבוי מתייחס לרשת שמחייבת כניסה כדי לקבל גישה לאינטרנט.

אם הטמעות המכשירים מספקות הטמעה מלאה של android.webkit.Webview API, הם:

• [C-1-1] חובה לספק אפליקציית פורטל שבוי כדי לטפל בכוונה ACTION_CAPTIVE_PORTAL_SIGN_IN ולהציג את דף ההתחברות לפורטל שבוי, על ידי שליחת הכוונה הזו, קריאה ל-System API ConnectivityManager#startCaptivePortalApp(Network, Bundle)
• [C-1-2] חובה לבצע זיהוי של פורטלים שבויים והתחברות לתמיכה דרך אפליקציית פורטל שבוי כשהמכשיר מחובר לכל סוג רשת, כולל רשת סלולרית/נייד, Wi-Fi, אתרנט או Bluetooth.
• [C-1-3] חייבת להיות תמיכה בהתחברות לפורטלים שבויים באמצעות DNS ללא טקסט חופשי כשהמכשיר מוגדר לשימוש במצב מחמיר של DNS פרטי.
• [C-1-4] חובה להשתמש ב-DNS מוצפן בהתאם למסמכי התיעוד של ה-SDK עבור android.net.LinkProperties.getPrivateDnsServerName ו-android.net.LinkProperties.isPrivateDnsActive לגבי כל התנועה ברשת שלא מתקשרת במפורש עם הוא פורטל שבוי.
• [C-1-5] חייבים לוודא שבזמן שהמשתמש מתחבר למכשיר שבוי פורטל, רשת ברירת המחדל המשמשת את האפליקציות (כפי שהוחזר על ידי ConnectivityManager.getActiveNetwork ConnectivityManager.registerDefaultNetworkCallback, ומשמשים כברירת מחדל על ידי ממשקי API של רשתות Java כגון java.net.Socket, וממשקי API מקוריים כמו Connect() ) הם כל רשת זמינה אחרת שמספקת גישה לאינטרנט, אם היא זמינה.

7.4.6. הגדרות סנכרון

הטמעות מכשירים:

• [C-0-1] הגדרת הסנכרון האוטומטי הראשי חייבת להיות מופעלת כברירת מחדל, כדי השיטה getMasterSyncAutomatically() הפונקציה מחזירה 'true'.

7.4.7. חסכונית בנתונים

אם הטמעות המכשירים כוללות חיבור עם חיוב לפי שימוש בנתונים:

• [C-SR-1] מומלץ מאוד לספק את מצב חוסך הנתונים (Data Saver).

אם הטמעות במכשירים מספקות את מצב חוסך הנתונים, הן:

• [C-1-1] חייבת לתמוך בכל ממשקי ה-API ב-ConnectivityManager כפי שמתואר בתיעוד ה-SDK

אם הטמעות במכשירים לא מספקות את מצב חוסך הנתונים, הן:

• [C-2-1] חייב להחזיר את הערך RESTRICT_BACKGROUND_STATUS_DISABLED עבור ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] אסור לשדר ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED

7.4.8. רכיבים מאובטחים

אם הטמעות במכשירים תומכים ב-Open Mobile API והפיכתם לזמינים לאפליקציות צד שלישי, הם:

• [C-1-1] חובה לציין את רשימת הקוראים של הרכיבים המאובטחים שזמינים באמצעות android.se.omapi.SEService.getReaders() API.

• [C-1-2] חובה להצהיר על התכונות הניסיוניות הנכונות דרך android.hardware.se.omapi.uicc למכשיר עם רכיבים מאובטחים שמבוססים על UICC. android.hardware.se.omapi.ese עבור המכשיר עם רכיבים מאובטחים מבוססי eSE android.hardware.se.omapi.sd עבור המכשיר באמצעות רכיבים מאובטחים מבוססי SD.

7.4.9. UWB

אם ההטמעות במכשירים כוללות תמיכה לקובץ 802.1.15.4 ולחשוף את הפונקציונליות לאפליקציה של צד שלישי, ואז:

• [C-1-1] חובה להטמיע את ממשק ה-API התואם של Android ב-android.uwb.
• [C-1-2] חובה לדווח על הדגל של תכונת החומרה android.hardware.uwb.
• [C-1-3] חייבת להיות תמיכה בכל פרופילי UWB הרלוונטיים שמוגדרים ב-Android יישום בפועל.
• [C-1-4] חובה לספק למשתמש מחיר כניסה כדי לאפשר לו להחליף מצב של UWB הפעלה/כיבוי של הרדיו.
• [C-1-5] חובה לאכוף את הדרישה שלפיה אפליקציות שמשתמשות ברדיו UWB יחזיקו בהרשאת UWB_RANGING (בקבוצת ההרשאות NEARBY_מכשירים).
• [C-SR-1] מומלץ מאוד לעבור את התאימות הרלוונטית בחינות הסמכה שהוגדרו על ידי ארגונים סטנדרטיים, כולל FIRA, CCC ו-CSA.
• [C-1-6] חובה לוודא שמידות המרחק הן בטווח של 95%-/ + ס"מ מהמדידות בסביבת קו הראייה במרחק של מטר אחד תא מחזיר אור.
• [C-1-7] חובה לוודא שהחציון של מדידות המרחק הוא 1 מטר ממכשיר העזר נמצא בטווח של [0.75 מטר, 1.25 מטר], בזמן אמת קרקע המרחק נמדד מהקצה העליון של ה-DUT. כאשר הפנים למעלה והטיה מוצגים כלפי מעלה ב-45 מעלות.
• [C-SR-2] מומלץ מאוד לבצע את השלבים להגדרת המדידה צוין ב- הדרישות לכיול הנוכחות.

7.5. מצלמות

אם ההטמעות במכשירים כוללות לפחות מצלמה אחת, הן:

• [C-1-1] חובה להצהיר על דגל התכונה android.hardware.camera.any.
• [C-1-2] חובה לאפשר לאפליקציה להקצות בו-זמנית שלוש מיפויי סיביות RGBA_8888 שווים לגודל התמונות שנוצרו על ידי חיישן המצלמה ברזולוציה הגבוהה ביותר במכשיר והמצלמה פתוחה של תצוגה מקדימה בסיסית ועדיין לצלם.
• [C-1-3] חובה לוודא שאפליקציית ברירת המחדל של המצלמה הותקנה מראש טיפול בכוונות MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, או MediaStore.ACTION_VIDEO_CAPTURE, אחראית להסרת מיקום המשתמש במטא-נתונים של התמונה לפני שולחת אותו לאפליקציה המקבלת כאשר האפליקציה המקבלת לא יש ACCESS_FINE_LOCATION.

אם בהטמעות המכשיר תומך ביכולת פלט HDR של 10 ביט:

• [C-2-1] חייבת לתמוך לפחות בפרופיל HLG HDR בכל מכשיר מצלמה שתומך בפלט של 10 ביט.
• [C-2-2] חייבת לתמוך בפלט של 10 ביט גם למצלמה האחורית הראשית מצלמה קדמית ראשית.
• [C-SR-1] מומלץ מאוד לתמוך בפלט של 10 ביט בשני הערכים מצלמות.
• [C-2-3] חייבים לתמוך באותם פרופילי HDR לכולם מצלמות משנה פיזיות עם יכולות BACKWARD_COMPATIBLE של מצלמה לוגית וגם המצלמה הלוגית עצמה.

למכשירי מצלמות לוגיות שתומכים ב-HDR באיכות 10 ביט עם הטמעה של android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API, is:

• [C-3-1] חייבת להיות תמיכה במעבר בין כל המכשירים הפיזיים שתואמים לאחור מצלמות באמצעות הפקד CONTROL_ZOOM_RATIO במצלמה הלוגית.

7.5.1. מצלמה אחורית

מצלמה אחורית היא מצלמה שממוקמת בצד של המכשיר שנמצא מול המסך. כלומר, היא ממחישה סצנות בקצה הרחוק של כמו מצלמה רגילה.

התחלה של דרישות חדשות

מצלמה אחורית היא מצלמה שפונה לכל העולם שמצלמת סצנות בצד הרחוק. של המכשיר, כמו מצלמה רגילה. במכשירים ניידים, זאת מצלמה שנמצא בצד המכשיר מול המסך.

סיום הדרישות החדשות

הטמעות מכשירים:

• צריכה לכלול מצלמה אחורית.

אם ההטמעות במכשירים כוללות לפחות מצלמה אחורית אחת, הן:

• [C-1-1] חובה לדווח על דגל התכונה android.hardware.camera וגם android.hardware.camera.any.
• [C-1-2] חייבת להיות ברזולוציה של 2 מגה-פיקסלים לפחות.
• יש להטמיע מיקוד אוטומטי בחומרה או מיקוד אוטומטי בתוכנה במנהל ההתקן של המצלמה (שקוף לתוכנת האפליקציה).
• ייתכן שיש בהם חומרה עם מיקוד קבוע או EDOF (עומק שדה מורחב).
• עשויים לכלול הבזק.

אם יש במצלמה פלאש:

• [C-2-1] אסור שמנורת הפלאש תהיה מוארת מופע אחד (android.hardware.Camera.PreviewCallback) נרשם במשטח התצוגה המקדימה של המצלמה, אלא אם האפליקציה הופעלה באופן מפורש של הפלאש על ידי הפעלת המאפיינים FLASH_MODE_AUTO או FLASH_MODE_ON של אובייקט Camera.Parameters. שימו לב שהאילוץ הזה לא חל על את אפליקציית המצלמה המובנית במכשיר, אבל רק לצד שלישי אפליקציות שמשתמשות ב-Camera.PreviewCallback.

7.5.2. מצלמה קדמית

מצלמה קדמית היא מצלמה שממוקמת באותו צד של המכשיר בתור התצוגה, כלומר מצלמה שמשמשת בדרך כלל לצילום תמונת המשתמש, כמו שיחות ועידה בווידאו ואפליקציות דומות.

התחלה של דרישות חדשות

מצלמה קדמית היא מצלמה מול המשתמש שמשמשת בדרך כלל לצילום תמונות את המשתמש, למשל לשיחות ועידה בווידאו ואפליקציות דומות; להחזקה ביד מכשירים – מצלמה שממוקמת באותו צד של המכשיר כמו המסך.

סיום הדרישות החדשות

הטמעות מכשירים:

• עשויים לכלול מצלמה קדמית.

אם ההטמעות במכשירים כוללות לפחות מצלמה קדמית אחת:

• [C-1-1] חובה לדווח על דגל התכונה android.hardware.camera.any וגם android.hardware.camera.front.
• [C-1-2] חייבת להיות רזולוציה של VGA לפחות (640x480 פיקסלים).
• [C-1-3] אסור להשתמש במצלמה קדמית כברירת המחדל ממשק API של מצלמה ואסור להגדיר את ה-API לטיפול במצלמה קדמית בתור מצלמת ברירת המחדל האחורית, גם אם היא המצלמה היחידה במכשיר.
• [C-1-4] חובה לשקף את התצוגה המקדימה של המצלמה לרוחב ביחס הכיוון שהוגדר על ידי האפליקציה, כשהאפליקציה הנוכחית כוללת ביקשה באופן מפורש שהמצלמה את התצוגה באמצעות קריאה android.hardware.Camera.setDisplayOrientation() . לעומת זאת, התצוגה המקדימה חייבת להיות משוכפלת לאורך ברירת המחדל של המכשיר. ציר אופקי כאשר האפליקציה הנוכחית לא מבקשת באופן מפורש כדי לסובב את תצוגת המצלמה באמצעות קריאה android.hardware.Camera.setDisplayOrientation() .
• [C-1-5] אסור לשקף את התמונה הסופית של תמונת סטילס או וידאו בסטרימינג חזרו לקריאות חוזרות של אפליקציה או מחויבות לאחסון מדיה.
• [C-1-6] חייבת לשקף את התמונה המוצגת לאחר הצפייה באותו אופן בתור שידור התמונות בתצוגה המקדימה של המצלמה.
• עשויים לכלול תכונות (כגון מיקוד אוטומטי, Flash וכו') שזמינות עבור מצלמות אחוריות, כפי שמתואר בסעיף 7.5.1.

אם יש אפשרות לבצע רוטציה של יישומי המכשיר על ידי המשתמש (כמו באופן אוטומטי באמצעות מד תאוצה או באופן ידני באמצעות קלט של משתמשים):

• [C-2-1] התצוגה המקדימה של המצלמה חייבת להיות משוכפלת לרוחב בכיוון הנוכחי של המכשיר.

7.5.3. מצלמה חיצונית

התחלה של דרישות חדשות

מצלמה חיצונית היא מצלמה שאפשר לחבר או לנתק ממנה פיזית הטמעת המכשיר בכל עת ויכול להיות פנייה לכל כיוון; כמו USB מצלמות.

סיום הדרישות החדשות

הטמעות מכשירים:

• עשויים לכלול תמיכה במצלמה חיצונית, שלא בהכרח תמיד מחובר.

אם הטמעתי מכשירים כוללים תמיכה במצלמה חיצונית, הם:

• [C-1-1] חובה להצהיר על תכונות הדגל של הפלטפורמה android.hardware.camera.external וגם android.hardware camera.any
• [C-1-2] חייבת להיות תמיכה ב-USB Video Class (UVC 1.0 ואילך) אם מחשב חיצוני המצלמה מתחברת דרך יציאת האירוח של ה-USB.
• [C-1-3] חובה לעבור בדיקות CTS של המצלמה עם התקן מצלמה חיצוני פיזי מחובר. פרטים על בדיקת CTS של המצלמה זמינים בכתובת source.android.com.
• צריכה לתמוך בדחיסות וידאו כמו MJPEG כדי לאפשר העברה של סטרימינג לא מקודד באיכות גבוהה (כלומר, תמונה גולמית או תמונה דחוסה באופן עצמאי ).
• יכול להיות שתומכות במספר מצלמות.
• ייתכן שתומכת בקידוד וידאו מבוסס מצלמה.

אם יש תמיכה בקידוד וידאו מבוסס מצלמה:

• [C-2-1] בו-זמנית לא מקודד / זרם MJPEG (רזולוציה QVGA או יותר) חייב להיות נגיש ההטמעה של המכשיר.

7.5.4. התנהגות ה-API של המצלמה

ב-Android יש שתי חבילות API שמאפשרות גישה למצלמה, הגרסה החדשה יותר ממשק ה-API של android.hardware.camera2 חושף את בקרת המצלמה ברמה נמוכה לאפליקציה, כולל תהליכים יעילים של רצף/סטרימינג ללא עותקים ובקרות לכל תמונה חשיפה, רווח, עלייה באיזון לבן, המרת צבעים, הסרת רעשים, חידוד, ועוד.

חבילת ה-API הישנה יותר,android.hardware.Camera, מסומנת כהוצאה משימוש ב- גרסה 5.0 של Android, אבל היא עדיין אמורה להיות זמינה לשימוש באפליקציות. מכשיר Android חייבים להבטיח את המשך התמיכה של ה-API, כפי שמתואר בקטע הזה וב-Android SDK.

כל התכונות המשותפות לסיווג android.hardware.camera שהוצא משימוש ובחבילה החדשה יותר של android.hardware.camera2 חייבת להיות ביצועים זהים והאיכות של שני ממשקי ה-API. לדוגמה, עם הגדרות מקבילות, המהירות והדיוק של המיקוד האוטומטי חייבים להיות זהים, והאיכות של תמונות שמצלמים צריכים להיות זהים. תכונות שתלויות בסמנטיקה השונה של שני ממשקי ה-API לא נדרשות התאמה של מהירות או איכות, אבל הן צריכות להתאים בדיוק ככל האפשר.

בהטמעות של מכשירים צריך ליישם את ההתנהגויות הבאות ממשקי API הקשורים למצלמות, לכל המצלמות הזמינות. הטמעות מכשירים:

• [C-0-1] חובה להשתמש ב-android.hardware.PixelFormat.YCbCr_420_SP לתצוגה מקדימה נתונים שסופקו לקריאות חוזרות של אפליקציה כאשר אפליקציה מעולם לא התקשרה android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] חייב להיות בפורמט הקידוד NV21 כשיישום רושם android.hardware.Camera.PreviewCallback והמערכת קוראת ל-method onPreviewFrame() ול-Preview הוא YCbCr_420_SP, הנתונים בבייט[] שמועברים אל onPreviewFrame(). כלומר, NV21 חייבת להיות ברירת המחדל.
• [C-0-3] חייב לתמוך בפורמט YV12 (כפי שמצוין על ידי קבוע של android.graphics.ImageFormat.YV12) לתצוגה המקדימה של המצלמה בשני המקומות מצלמות קדמיות ואחוריות עבור android.hardware.Camera. (החומרה המצלמה ומקודד הווידאו עשויים להשתמש בכל פורמט של פיקסל מקורי, אבל ההטמעה חייבת לתמוך בהמרה ל-YV12).
• [C-0-4] חייבים לתמוך ב-android.hardware.ImageFormat.YUV_420_888 של android.hardware.ImageFormat.JPEG כפלט באמצעות API של android.media.ImageReader ל-android.hardware.camera2 מכשירים פרסום REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE ב-android.request.availableCapabilities.
• [C-0-5] עדיין צריך להטמיע את ה-API המלא של המצלמה שכלולות במסמכי התיעוד של Android SDK, גם אם המכשיר לא כולל מיקוד אוטומטי בחומרה או יכולות אחרות. לדוגמה, מצלמות ללא מיקוד אוטומטי, עדיין חייב להתקשר android.hardware.Camera.AutoFocusCallback מופעים (למרות שאין להם רלוונטיות למצלמה ללא מיקוד אוטומטי.) לתשומת ליבכם: הכלל הזה חל על מצלמות; למשל, למרות שרוב המצלמות הקדמית לא תומכות המיקוד האוטומטי, גם הקריאות החוזרות של ה-API עדיין צריכות להיות 'מזויפות', כפי שמתואר.
• [C-0-6] חובה לזהות כל שם של פרמטר ולכבד אותו מוגדר כקבוע android.hardware.Camera.Parameters והכיתה android.hardware.camera2.CaptureRequest. לעומת זאת, אסור שהטמעות מכשירים יפעלו בהתאם לקבועים של מחרוזות או יזהו אותם מועבר ל-method android.hardware.Camera.setParameters() מלבד אלה מתועדות כקבועים ב-android.hardware.Camera.Parameters. כלומר, בהטמעות המכשיר חייבות לתמוך בכל הפרמטרים הרגילים של המצלמה, אם מאפשרת חומרה, ואסור שהיא תתמוך בסוגי פרמטרים מותאמים אישית של מצלמה. למשל, הטמעות של מכשירים שתומכים בצילום תמונה באמצעות שיטות הדמיה עם טווח דינמי גבוה (HDR), חייבות לתמוך בפרמטר של המצלמה Camera.SCENE_MODE_HDR
• [C-0-7] חובה לדווח על רמת התמיכה המתאימה באמצעות android.info.supportedHardwareLevel כפי שמתואר ב-Android SDK, ולדווח על דגלים של רכיבי framework.
• [C-0-8] בנוסף, אנחנו חייבים להצהיר על היכולות של המצלמה הנפרדת שלה android.hardware.camera2 דרך נכס אחד (android.request.availableCapabilities) ולהצהיר על דגלי התכונות המתאימים. חובה להגדיר את סימון התכונה אם מכשירי המצלמה המחוברים שלו. תומך בתכונה.
• [C-0-9] חובה לשדר את Camera.ACTION_NEW_PICTURE בכל פעם שתמונה חדשה צולמה על ידי המצלמה התמונה נוספה לחנות המדיה.
• [C-0-10] חובה לשדר את Camera.ACTION_NEW_VIDEO של כוונה בכל פעם שסרטון חדש מצולם על ידי המצלמה התמונה נוספה לחנות המדיה.
• [C-0-11] כל המצלמות חייבות להיות נגישות דרך android.hardware.Camera אפשר לגשת ל-API גם דרך android.hardware.camera2 API.
• [C-0-12] חובה לוודא שמראה הפנים לא ישתנה, כולל אך לא רק שינוי בגיאומטריה של הפנים, גוון העור של הפנים או הפנים החלקת העור בכל סוג של android.hardware.camera2 או android.hardware.Camera API.
• [C-SR-1] עבור מכשירים עם כמה מצלמות RGB במכשירים קרובים מאוד ופונים לאותו כיוון, מומלץ מאוד לתמוך במכשיר מצלמה לוגי שמפרט יכולת CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, שמורכבות מכל מצלמות ה-RGB שפונות לכיוון הזה כמכשירי משנה פיזיים.

אם הטמעות המכשיר מספקות API קנייני של מצלמה לאפליקציות צד שלישי, הם:

• [C-1-1] חובה להטמיע ממשק API של מצלמה כזה באמצעות android.hardware.camera2 API.
• עשויים לספק תגים ו/או תוספים של ספק עבור android.hardware.camera2 API.

7.5.5. כיוון המצלמה

אם בהטמעות המכשיר יש מצלמה קדמית או אחורית, מצלמות כאלה:

• [C-1-1] צריך לכוון את הכיוון של הממד הארוך של המצלמה את המאפיין הארוך של המסך. כלומר, כשמחזיקים את המכשיר בשטח כיוון, המצלמות חייבות לצלם תמונות לרוחב. הזה חל ללא קשר לכיוון הטבעי של המכשיר. כלומר, חלה מכשירים עיקריים בפורמט אופקי וכן מכשירים ראשיים בפריסה לאורך.

מכשירים שעומדים בכל הקריטריונים הבאים פטורים מהדרישה שצוינה למעלה:

• המכשיר מטמיע מסכים עם גיאומטריה משתנה, כמו מסכים מתקפלים או צירים מסכים.
• כשמצב הקיפול או הציר של המכשיר משתנה, המכשיר עובר בין מפורמט לאורך, מהפורמט הראשי לרוחב ומהפך (להפך).

התחלה של דרישות חדשות

• יישומי מכשירים שלא ניתן לבצע בהם רוטציה על ידי המשתמש כמכשירים לכלי רכב.

סיום הדרישות החדשות

7.6. זיכרון ואחסון

7.6.1. נפח זיכרון ואחסון מינימלי

הטמעות מכשירים:

• [C-0-1] חייב לכלול מנהל ההורדות שייתכן שישמשו את האפליקציות להורדת קובצי נתונים, והן חייבות להיות מסוגלות להוריד קבצים בודדים בגודל של 100MB לפחות לברירת המחדל "מטמון" המיקום.

7.6.2. אחסון משותף באפליקציות

הטמעות מכשירים:

• [C-0-1] חובה להציע נפח אחסון משותף לאפליקציות, שלרוב נקראות גם ' כ'אחסון חיצוני משותף', 'אחסון משותף של אפליקציות' או באמצעות Linux נתיב "/sdcard" שאליו הוא מותקן.
• [C-0-2] חובה להגדיר אחסון משותף שמותקן כברירת מחדל, במכשירים אחרים 'הוצאה מהאריזה', ללא קשר אם האחסון מוטמע ב- רכיב אחסון פנימי או אמצעי אחסון נשלף (למשל, חריץ לכרטיס דיגיטלי).
• [C-0-3] חובה לטעון את האחסון המשותף של האפליקציה ישירות בנתיב Linux sdcard או לכלול קישור סימבולי של Linux מ-sdcard לטעינה בפועל לנקודה.
• [C-0-4] חובה להפעיל נפח אחסון בהיקף כברירת מחדל לכל אפליקציות שמטרגטות לרמת API 29 ומעלה, למעט במצבים הבאים:
  • מתי האפליקציה ביקשה android:requestLegacyExternalStorage="true" במניפסט שלהם.
• [C-0-5] חובה לצנזר מטא-נתונים של מיקום, כמו תגי GPS Exif, שמאוחסנים קובצי מדיה כשניגשים לקבצים האלה דרך MediaStore, חוץ מאשר במקרים שבהם אפליקציית השיחות כוללת את ההרשאה ACCESS_MEDIA_LOCATION.

יישומי מכשירים עשויים לעמוד בדרישות שלמעלה באמצעות הבאים:

• אחסון נשלף שנגיש למשתמש, כמו חריץ לכרטיס Secure Digital (SD).
• חלק מהאחסון הפנימי (שלא ניתן להסרה) כפי שמוטמע פרויקט קוד פתוח של Android (AOSP).

אם יישומים של מכשירים משתמשים באחסון נשלף כדי לעמוד בדרישות שלמעלה בדרישות הבאות:

• [C-1-1] חובה להטמיע בממשק משתמש הודעה קופצת או הודעה קופצת שמזהירה את המשתמש כאשר לא הוכנס אמצעי אחסון לחריץ.
• [C-1-2] חייב לכלול אמצעי אחסון בפורמט FAT (למשל, כרטיס SD) או תוכנית על האריזה וחומרים אחרים שזמינים בזמן הרכישה שהאחסון יש לרכוש אמצעי הגעה לאתר בנפרד.

אם יישומים של מכשירים משתמשים בחלק מהאחסון שלא ניתן להסרה כדי לספק בדרישות שפורטו למעלה:

• צריכה להשתמש ביישום AOSP של האפליקציה הפנימית המשותפת אחסון.
• ייתכן שיתוף של נפח האחסון עם האפליקציה הפרטית.

אם בהטמעות המכשיר יש יציאת USB עם תמיכה במצב ציוד היקפי בחיבור USB. הם:

• [C-3-1] חייב לספק מנגנון לגישה לנתונים באפליקציה נפח אחסון משותף ממחשב מארח.
• תוכן משני נתיבי האחסון אמור להופיע בשקיפות שירות סורק המדיה של Android ו-android.provider.MediaStore.
• ייתכן להשתמש באחסון USB בנפח גדול, אבל צריך להשתמש בפרוטוקול Media Transfer Protocol (פרוטוקול העברת מדיה) כדי לעמוד בדרישות בדרישה הזו.

אם בהטמעות המכשיר יש יציאת USB עם מצב היקפי בחיבור USB ותמיכה Media Transfer Protocol (פרוטוקול העברת מדיה):

• אמורה להיות תואמת למארח MTP של Android, העברת קבצים ב-Android.
• אמור לדווח על סוג התקן USB 0x00.
• יש לדווח על שם ממשק ה-USB 'MTP'.

7.6.3. אחסון מותאם

אם המכשיר צפוי להיות נייד בטבע, בשונה מטלוויזיה, דוגמאות להטמעת מכשירים:

• [C-SR-1] מומלץ מאוד להטמיע את האחסון שניתן לאמץ מיקום יציב לטווח ארוך, מכיוון שניתוק שלהם בטעות עלול לגרום לאובדן/פגיעה בנתונים.

אם היציאה של מכשיר האחסון הנשלף נמצאת במיקום יציב לטווח הארוך, למשל, בתוך תא הסוללות או כיסוי מגן אחר, דוגמאות להטמעת מכשירים:

• [C-SR-2] מומלץ מאוד להטמיע אחסון שניתן להתאמה.

7.7. USB

אם בהטמעות של מכשירים יש יציאת USB:

• צריכה לתמוך במצב ציוד היקפי בחיבור USB והוא אמור לתמוך במצב אירוח USB.
• אמורה לתמוך בהשבתה של אותות הנתונים באמצעות USB.

7.7.1. מצב ציוד היקפי בחיבור USB

אם הטמעות המכשיר כוללות יציאת USB שתומכת במצב היקפי:

• [C-1-1] היציאה חייבת להיות ניתנת לחיבור למארח USB שיש לו יציאת USB מסוג A או Type-C.
• [C-1-2] חובה לדווח על הערך הנכון של iSerialNumber בתקן USB שמתאר את המכשיר דרך android.os.Build.SERIAL.
• [C-1-3] חייבים לזהות מטענים של 1.5A ו-3.0A לפי נגד Type-C והם חייבים לזהות שינויים במודעה, אם הם תומכים USB-C.
• [C-SR-1] היציאה צריכה להשתמש בגורם צורה של USB מסוג מיקרו-B, מיקרו-AB או Type-C. מומלץ מאוד להתאים מכשירי Android קיימים וחדשים כדי שניתן יהיה לשדרג לגרסאות עתידיות של הפלטפורמה.
• [C-SR-2] היציאה אמורה להיות ממוקמת בחלק התחתון של המכשיר (בהתאם לכיוון הטבעי) או לאפשר סיבוב מסך בתוכנה כל האפליקציות (כולל מסך הבית), כדי שהתצוגה תופיע כראוי כאשר המכשיר פועל באמצעות היציאה בתחתית המסך. מכשירי Android קיימים וחדשים מומלץ מאוד לעמוד בדרישות האלה, תהיה אפשרות לשדרג לגרסאות עתידיות של הפלטפורמה.
• [C-SR-3] צריך להטמיע תמיכה כדי לצייר זרם של 1.5 אמפר במהלך ציוץ HS ותנועה כפי שמצוין במפרט של טעינת סוללה ב-USB, גרסה 1.2. מומלץ מאוד להתאים מכשירי Android קיימים וחדשים כדי שניתן יהיה לשדרג לגרסאות עתידיות של הפלטפורמה.
• [C-SR-4] מומלץ מאוד לא לתמוך בקניין רוחני שיטות טעינה שמשנות את המתח ב-Vbus מעבר לרמות ברירת המחדל, או משנות את המתח תפקידי sink/מקור כאלה עלולים לגרום לבעיות ביכולת הפעולה ההדדית (interoperability) מטענים או מכשירים שתומכים בשיטות הסטנדרטיות של העברת חשמל ב-USB. בזמן אנחנו קוראים לזה 'מומלץ מאוד', בגרסאות עתידיות של Android ייתכן שיהיה צורך בכל המכשירים מסוג C כדי לתמוך ביכולת פעולה הדדית מלאה עם מטענים מסוג C.
• [C-SR-5] מומלץ מאוד לתמיכה ב-Power Delivery להצגת נתונים החלפת תפקידי כוח כשהם תומכים במצב מארח USB ו-USB מסוג C.
• אמורה להיות תמיכה בתקן אספקת חשמל לטעינה במתח גבוה ותמיכה מצבים חלופיים, כמו מסך חוץ.
• יש להטמיע את ה-API והמפרט של Android Open Accessory (AOA) בתור בתיעוד של ה-SDK של Android.

אם ההטמעות של המכשיר כוללות יציאת USB ומטמיעות את AOA למפרט, הן:

• [C-2-1] חובה להצהיר על תמיכה בתכונת החומרה android.hardware.usb.accessory
• [C-2-2] סוג האחסון בנפח USB חייב לכלול את המחרוזת 'android'. ב סוף תיאור הממשק iInterface מחרוזת של אחסון בנפח גדול ב-USB

7.7.2. מצב אירוח USB

אם הטמעות המכשירים כוללות יציאת USB שתומכת במצב מארח:

• [C-1-1] חובה להטמיע את ממשק ה-API של מארח ה-Android ל-Android, כפי שמתועד ב- Android SDK וחובה להצהיר על תמיכה בתכונת החומרה android.hardware.usb.host
• [C-1-2] חובה להטמיע תמיכה בחיבור ציוד היקפי סטנדרטי בחיבור USB. במילים אחרות, הם חייבים:
  • צריכה להיות במכשיר יציאה מסוג C או משלוח עם כבלים, כדי להתאים את המכשיר למכשיר יציאה קניינית ליציאת USB-C סטנדרטית (מכשיר USB-C).
  • המכשיר צריך להיות מסוג A או שהוא עם כבלים שמתאימים למכשיר יציאה קניינית ליציאת USB-A סטנדרטית.
  • צריכה להיות יציאת מיקרו-AB במכשיר, שאמורה להישלח עם כבל ליציאה רגילה מסוג A.
• [C-1-3] אסור לשלוח עם מתאם שממיר USB מסוג A או יציאות מיקרו-AB ליציאת מסוג C (שקע).
• [C-SR-1] מומלץ מאוד ליישם סיווג אודיו בחיבור USB כפי שמתועד בתיעוד של Android SDK.
• אמורה לתמוך בטעינת הציוד ההיקפי המחובר בחיבור USB בזמן המארח מצב; פרסום מקור נוכחי של 1.5A לפחות כפי שמצוין הקטע 'פרמטרים של סיום' תיקון 1.2 לכבל USB-C ולמחבר ל-USB-C או שימוש בטעינה במורד הזרם (CDP) בפלט של הטווח הנוכחי, מצוין ב מפרטים של טעינת סוללה ב-USB, גרסה 1.2 למחברי Micro-AB.
• עליכם להטמיע ולתמוך בתקני USB Type-C.

אם הטמעות המכשיר כוללות יציאת USB שתומכת במצב מארח וחיבור USB שיעור אודיו, הם:

• [C-2-1] חייב לתמוך בסיווג USB HID.
• [C-2-2] חייבת לתמוך בזיהוי ובמיפוי של נתוני ממשק המשתמש הבאים: השדות שמצוינים בטבלאות השימוש בחיבור USB HID ואת הבקשה לשימוש בפקודות קוליות אל KeyEvent קבועים כמו בהמשך:
  • מזהה השימוש של דף השימוש (0xC) (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • מזהה השימוש של דף השימוש (0xC) (0x0E9): KEYCODE_VOLUME_UP
  • מזהה השימוש של דף השימוש (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
  • מזהה השימוש של דף השימוש (0xC) (0x0CF): KEYCODE_VOICE_ASSIST

אם הטמעות המכשיר כוללות יציאת USB שתומכת במצב מארח וגם במסגרת Storage Access Framework (SAF), הן:

• [C-3-1] חובה לזהות כל MTP (פרוטוקול העברת מדיה) שמחובר מרחוק מכשירים ולהפוך את התוכן שלהם לנגיש דרך ACTION_GET_CONTENT, Intents ACTION_OPEN_DOCUMENT ו-ACTION_CREATE_DOCUMENT. .

אם הטמעות המכשיר כוללות יציאת USB שתומכת במצב מארח וב-USB מסוג ג', הן:

• [C-4-1] חובה להטמיע את הפונקציונליות של יציאת Dual Role כפי שהוגדרה ב-USB מפרט Type-C (סעיף 4.5.1.3.3). לשניים יציאות תפקידים, במכשירים שכוללים שקע אודיו 3.5 מ"מ, הכיור USB ייתכן שהזיהוי (מצב מארח) יהיה מושבת כברירת מחדל, אבל זה חייב להיות אפשרי משתמש כדי להפעיל אותו.
• [C-SR-2] מומלץ מאוד לתמיכה ב-DisplayPort, צריכה לתמוך ב-USB קצבי הנתונים של Superspeed, ומומלץ מאוד לתמיכה באספקת חשמל להחלפת נתונים ותפקידי כוח.
• [C-SR-3] מומלץ מאוד לא לתמוך במצב האביזר של מתאם האודיו שמתוארים בנספח א' של גרסה 1.2 של כבל USB-C ומפרט המחבר.
• כדאי להטמיע את מודל Try.* המתאים ביותר גורם הצורה של המכשיר. לדוגמה, במכשיר נייד יש להטמיע את אפשר לנסות מודל SNK.

7.8. אודיו

7.8.1. מיקרופון

אם ההטמעות במכשירים כוללים מיקרופון:

• [C-1-1] חובה לדווח על קבוע התכונה android.hardware.microphone.
• [C-1-2] חייב לעמוד בדרישות של הקלטת אודיו ב: סעיף 5.4.
• [C-1-3] חייב לעמוד בדרישות זמן האחזור לאודיו סעיף 5.6.
• [C-SR-1] מומלץ מאוד לתמוך בהקלטת אולטרסאונד, כפי שמתואר בסעיף 7.8.3.

אם ההטמעות של המכשיר מושמטות ממיקרופון:

• [C-2-1] אסור לדווח על קבוע התכונה android.hardware.microphone.
• [C-2-2] חובה להטמיע את ה-API של הקלטת האודיו לפחות כפעולות ללא תפעול, לכל סעיף 7.

7.8.2. יעד השמע

אם ההטמעות במכשיר כוללות רמקול או פלט אודיו/מולטימדיה יציאה לציוד היקפי לפלט אודיו כמו שקע אודיו עם 4 מוליך 3.5 מ"מ או במצב מארח USB באמצעות סיווג אודיו USB, הן:

• [C-1-1] חובה לדווח על קבוע התכונה android.hardware.audio.output.
• [C-1-2] חייב לעמוד בדרישות להפעלת אודיו ב: סעיף 5.5.
• [C-1-3] חייב לעמוד בדרישות זמן האחזור לאודיו סעיף 5.6.
• [C-SR-1] מומלץ מאוד לתמוך בהפעלה כמעט באמצעות אולטרסאונד, כפי שמתואר בסעיף 7.8.3.

אם ההטמעות במכשירים לא כוללות רמקול או יציאת אודיו, הן:

• [C-2-1] אסור לדווח על התכונה android.hardware.audio.output.
• [C-2-2] חובה להטמיע לפחות את ממשקי ה-API שקשורים לפלט האודיו כללא תפעול.

למטרות סעיף זה, "יציאת פלט" היא ממשק פיזי לדוגמה, שקע אודיו 3.5 מ"מ, HDMI או יציאה במצב מארח ב-USB עם סיווג אודיו ב-USB. תמיכה בפלט אודיו באמצעות פרוטוקולים מבוססי רדיו כמו Bluetooth, חיבור Wi-Fi או רשת סלולרית לא נחשב כמכיל "יציאת פלט".

7.8.2.1. יציאות אודיו אנלוגיות

כדי לעמוד בדרישות של אוזניות ואביזרי אודיו אחרים באמצעות תקע אודיו 3.5 מ"מ בכל הסביבה העסקית של Android, אם כוללים יציאת אודיו אנלוגית אחת או יותר, כלומר:

• [C-SR-1] מומלץ מאוד לכלול לפחות מאפיין אחד יציאות האודיו שיהיו שקע אודיו של 4 מוליכים 3.5 מ"מ.

אם בהטמעות של מכשירים יש שקע אודיו של 4 מוליך בגודל 3.5 מ"מ, הן:

• [C-1-1] חייבת לתמוך בהפעלת אודיו באוזניות סטריאו ובאוזניות סטריאו עם מיקרופון.
• [C-1-2] חייבת לתמוך במחברי האודיו ב-TRRS עם הזמנת ההצמדה של CTIA.
• [C-1-3] חייבת לתמוך בזיהוי ובמיפוי לקודי מפתחות לאחר 3 טווחים של עכבה מקבילה בין המיקרופון לאדמה מוליכים בשקע האודיו:
  • 70 או פחות או פחות: KEYCODE_HEADSETHOOK
  • 210-290 אוהם: KEYCODE_VOLUME_UP
  • 360-680 אוהם: KEYCODE_VOLUME_DOWN
• [C-1-4] חייבים להפעיל את ACTION_HEADSET_PLUG עם הכנסת התקע, אבל רק לאחר שכל אנשי הקשר על השקע נוגעים בקטעים הרלוונטיים. על השקע.
• [C-1-5] חייבת להיות יכולת להפעיל לפחות 150mV ± 10% ממתח יציאה עכבה של רמקול של 32 אוהם.
• [C-1-6] חייבת להיות הטיית מיקרופון בין 1.8 וולט כ-2.9 וולט.
• [C-1-7] חובה לזהות את קוד המפתח ולמפות אותו בשביל טווח של עכבה מקבילה בין המיקרופון למוליכי הקרקע בשקע האודיו:
  • 110-180 אוהם: KEYCODE_VOICE_ASSIST
• [C-SR-2] מומלץ מאוד לתמוך בתקעי האודיו עם OMTP של ה-OMTP. סדר הצמדה.
• [C-SR-3] מומלץ מאוד לתמוך בהקלטת אודיו מסטריאו של אוזניות עם מיקרופון.

אם בהטמעות של המכשיר יש שקע אודיו של 4 מוליך בגודל 3.5 מ"מ ותומכות מיקרופון, ולשדר את android.intent.action.HEADSET_PLUG באמצעות עבור מיקרופון שהוא 1, הוא:

• [C-2-1] חייבת לתמוך בזיהוי המיקרופון באודיו המחובר אחר.

7.8.2.2. יציאות אודיו דיגיטליות

דרישות ספציפיות למכשיר מופיעות בסעיף 2.2.1.

7.8.3. קרוב לאולטרסאונד

אודיו Near-Ultrasound הוא תדר של 18.5kHz עד 20kHz.

הטמעות מכשירים:

• חייבים לדווח בצורה נכונה על תמיכה ב יכולת אודיו כמעט אולטרסאונד באמצעות AudioManager.getProperty API באופן הבא:

אם PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND הוא 'TRUE', חובה לעמוד בדרישות הבאות מקורות האודיו VOICE_RECOGNITION ו-UNPROCESSED:

• [C-1-1] תגובת ההספק הממוצעת של המיקרופון בתדר של 18.5kHz עד 20kHz חייב להיות לא יותר מ-15 דציבלים מתחת לתגובה ב-2 קילו-הרץ.
• [C-1-2] יחס האות לא משוקלל לרעש של המיקרופון מעל 18.5kHz עד 20kHz לטון של 19 kHz של -26dBFS, צריך להיות לא פחות מ-50dB

אם PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND הוא "true":

• [C-2-1] התגובה הממוצעת של הרמקול בתדרים 18.5 kHz עד 20 kHz חייבת להיות לא נמוכה מ- 40 dB מתחת לתגובה ב- 2 kHz.

7.8.4. תקינות האות

הטמעות מכשירים:

• אמור לספק נתיב אות אודיו ללא תקלות עבור שני הקלט ותזרים פלט במכשירים ניידים, כפי שמוגדר באמצעות אפס תקלות שנמדדת במהלך בדיקה של דקה אחת לכל נתיב. בודקים באמצעות OboeTester 'בדיקת תקלה אוטומטית'.

בבדיקה נדרש מתאם של אודיו בלופ, משמש ישירות בשקע 3.5 מ"מ או בשילוב עם מתאם USB-C ל-3.5 מ"מ. כל היציאות של פלט האודיו צריכות להיבדק.

OboeTester תומך כרגע בנתיבי AAudio, לכן יש לבדוק אם יש תקלות בשילובים הבאים של אודיו:

מצב ביצועים	שיתוף	תדירות הדגימה יוצאת	בצ'אנס	צ'אן אאוט
LOW_LATENCY	בלעדי	לא מסומן	1	2
LOW_LATENCY	בלעדי	לא מסומן	2	1
LOW_LATENCY	משותף	לא מסומן	1	2
LOW_LATENCY	משותף	לא מסומן	2	1
ללא	משותף	48000	1	2
ללא	משותף	48000	2	1
ללא	משותף	44100	1	2
ללא	משותף	44100	2	1
ללא	משותף	16000	1	2
ללא	משותף	16000	2	1

זרם אמין צריך לעמוד בקריטריונים הבאים עבור 'אות לרעש' יחס (SNR) ועיוות הרמוני כולל (THD) ל-2,000 Hz סינוס.

מתמר	THD	חיישן SNR
רמקול מובנה ראשי, שנמדד באמצעות מיקרופון חיצוני להתייחסות	< 3.0%	>= 50 dB
מיקרופון מובנה ראשי, שנמדד באמצעות רמקול עזר חיצוני	< 3.0%	>= 50 dB
שקעים אנלוגיים מובנים בגודל 3.5 מ"מ, נבדקים באמצעות מתאם לולאה חוזרת	< 1%	>= 60 dB
מתאמי USB שסופקו עם הטלפון, נבדקו באמצעות מתאם לולאה חוזרת	< 1.0%	>= 60 dB

7.9. מציאות מדומה

Android כולל ממשקי API ומתקנים לבניית 'מציאות מדומה' (VR) כולל חוויות VR בנייד באיכות גבוהה. Device (מכשיר) חייבים להטמיע בצורה תקינה את ממשקי ה-API וההתנהגויות האלה, כפי שמפורט בקטע הזה.

7.9.1. מצב מציאות מדומה

Android כולל תמיכה ב: מצב VR, תכונה שמטפלת ברינדור סטריאוסקופי של התראות ומשביתה אותן רכיבי ממשק משתמש של מערכת מונוקולרית, בזמן שאפליקציית VR מתמקדת במשתמש.

7.9.2. מצב מציאות מדומה – ביצועים גבוהים

אם ההטמעות במכשירים תומכים במצב VR:

• [C-1-1] חייבות להיות לפחות 2 ליבות פיזיות.
• [C-1-2] חובה להצהיר על התכונה android.hardware.vr.high_performance.
• [C-1-3] חייבת לתמוך במצב של ביצועים טובים לאורך זמן.
• [C-1-4] חייבת לתמוך ב-OpenGL ES 3.2.
• [C-1-5] חייבת לתמוך ב-android.hardware.vulkan.level 0.
• צריכה לתמוך ב-android.hardware.vulkan.level 1 ומעלה.
• [C-1-6] חובה ליישם EGL_KHR_mutable_render_buffer EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace, וחושפים את התוספים ברשימת תוספי ה-EGL הזמינים.
• [C-1-8] חובה ליישם GL_EXT_multisampled_render_to_texture2 GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures, וחושפים את התוספים ברשימת תוספי GL הזמינים.
• [C-SR-1] מומלץ מאוד להטמיע GL_EXT_external_buffer GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture, וחושפים את התוספים ברשימת תוספי GL הזמינים.
• [C-SR-2] אנחנו ממליצים מאוד לתמוך ב-Vulkan 1.1.
• [C-SR-3] מומלץ מאוד להטמיע VK_ANDROID_external_memory_android_hardware_buffer VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image, וחושפים אותו ברשימת התוספים הזמינים של Vulkan.
• [C-SR-4] מומלץ מאוד לחשוף לפחות משפחת תור אחת של Vulkan שבה flags מכילים גם את VK_QUEUE_GRAPHICS_BIT וגם את VK_QUEUE_COMPUTE_BIT, ו-queueCount הוא לפחות 2.
• [C-1-7] ה-GPU והמסך חייבים להיות מסוגלים לסנכרן את הגישה מאגר נתונים זמני בחזית, כך שרינדור תוכן VR מתבצע במהירות של 60fps עם שתי מצלמות מהירות מתחלפות הקשרי עיבוד יוצגו ללא פריטי מידע שנוצרו בתהליך הפיתוח (Artifact)
• [C-1-9] חובה להטמיע תמיכה בAHardwareBuffer דגלים AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA והקבוצה AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT כפי שמתואר ב-NDK.
• [C-1-10] חובה להטמיע תמיכה ב-AHardwareBuffer באמצעות שילוב של דגלי השימוש AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT לפחות בפורמטים הבאים: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR-5] מומלץ מאוד לתמוך בהקצאה של AHardwareBuffers עם יותר משכבה אחת ודגלים ופורמטים שצוינו ב-C-1-10.
• [C-1-11] חייבת לתמוך בפענוח H.264 לפחות ב- 3840 x 2160 בקצב של 30fps, דחוסה לממוצע של 40Mbps (שווה ל-4 מופעים של 1920 x1080 בקצב 30fps-10Mbps, או שני מופעים של 1920 x 1080 בקצב 60fps-20Mbps).
• [C-1-12] חייבת להיות תמיכה ב-HEVC וב-VP9. בנוסף, חייבת להיות יכולת פענוח לפחות 1,920 x 1,080 בקצב של 30fps, דחוסים ל-10Mbps בממוצע, והצריכה להיות יכול לפענח 3840 x 2160 בקצב של 30 Mbps-20 Mbps (שווה ערך ל- ארבעה מופעים של 1920 x 1080 ב- 30fps-5Mbps).
• [C-1-13] חייבת להיות תמיכה ב-API של HardwarePropertiesManager.getDeviceTemperatures ולהחזיר ערכים מדויקים לטמפרטורת העור.
• [C-1-14] חייב להיות מסך מוטמע, והרזולוציה שלו חייבת להיות לפחות 1,920 x 1,080
• [C-SR-6] מומלץ מאוד שרזולוציית המסך תהיה לפחות 2,560 x 1,440.
• [C-1-15] המסך חייב להתעדכן לפחות 60 Hz במצב VR.
• [C-1-17] המסך חייב לתמוך במצב של התמדה נמוכה עם 5 אלפיות השנייה או פחות עקביות, מופיעה הגדרה של 'עקביות' כמשך הזמן שפיקסל פולט אור.
• [C-1-18] חייבת להיות תמיכה ב-Bluetooth 4.2 ובתוסף אורך נתונים של Bluetooth LE סעיף 7.4.3.
• [C-1-19] חובה לספק תמיכה ולדווח בצורה תקינה סוג ערוץ ישיר לכל סוגי החיישנים הבאים שמוגדרים כברירת מחדל:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR-7] מומלץ מאוד לתמוך TYPE_HARDWARE_BUFFER סוג הערוץ הישיר לכל סוגי הערוצים הישירים המפורטים למעלה.
• [C-1-21] חייבים לעמוד בדרישות שקשורות לג'ירוסקופ, למד התאוצה ולמגנטומטר הדרישות עבור android.hardware.hifi_sensors, כפי שמפורט ב- סעיף 7.3.9.
• [C-SR-8] מומלץ מאוד לתמוך תכונה android.hardware.sensor.hifi_sensors.
• [C-1-22] זמן האחזור של פוטון חייב להיות תנועה מקצה לקצה שלא עולה על 28 אלפיות השנייה.
• [C-SR-9] מומלץ מאוד להפעיל תנועה מקצה לקצה לזמן אחזור של פוטון לא יותר מ-20 אלפיות שנייה.
• [C-1-23] חייב להיות יחס פריים ראשון, שהוא היחס בין בהירות הפיקסלים בפריים הראשון לאחר מעבר משחור ל ואת הבהירות של פיקסלים לבנים במצב יציב, של לפחות 85%.
• [C-SR-10] מומלץ מאוד לשמור על יחס פריים ראשון של 90% לפחות.
• MAY מספק ליבה בלעדית לחזית ו-MAY תומכים ב-API של Process.getExclusiveCores כדי להחזיר מספר ליבות המעבד (CPU) הבלעדיות לחזית העליונה תרגום מכונה.

אם יש תמיכה בליבה בלעדית, אז הליבה:

• [C-2-1] אסור לאפשר לתהליכים אחרים במרחב המשתמשים לפעול בו (למעט מנהלי התקנים של מכשירים שהאפליקציה משתמשת בהם), אבל יכול להיות שמותר להשתמש בליבה (kernel) מסוימת כדי לרוץ לפי הצורך.

7.10. מגע

התחלה של דרישות חדשות

מכשירים להחזקה ביד או לענידה עשויים לכלול משוב פיזי לשימוש כללי. אקטואטור, זמין לאפליקציות למטרות שונות, כולל משיכת תשומת לב באמצעות רינגטונים, שעונים מעוררים, התראות ומשוב כללי מגע.

אם יישומים של מכשירים לא כוללים אקטואטור פיזי כזה למטרה כללית, הם:

• [7.10/C] חייבת להחזיר FALSE עבור Vibrator.hasVibrator().

אם הטמעות המכשיר כוללות תיעוד פיזי אחד לפחות לשימוש כללי ב-Actuator, הם:

• [C-1-1] חייב להחזיר true עבור Vibrator.hasVibrator().
• אין להשתמש באקטואטור פיזי (רטט) מסתובב של מסה אקסצנטרית (ERM).
• יש להטמיע את כל הקבועים הציבוריים עבור משוב פיזי ברור ב-android.view.HapticFeedbackConstants כלומר (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START וגם GESTURE_END).
• יש להטמיע את כל הקבועים הציבוריים עבור משוב פיזי ברור ב-android.os.VibrationEffect כלומר (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK וגם EFFECT_DOUBLE_CLICK) וכל הקבועים הציבוריים של PRIMITIVE_* הזמינים עבור משוב פיזי עשיר בandroid.os.VibrationEffect.Composition כלומר (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). חלק מהפרימיטיביים האלה, כמו LOW_TICK ו SPIN יהיה אפשרי רק אם הרטט יכול לתמוך ברמה נמוכה יחסית תדרים מסוימים.
• צריך לפעול בהתאם להנחיות למיפוי של קבועים ציבוריים. ב-android.view.HapticFeedbackConstants לרשימת android.os.VibrationEffect המומלצים קבועים, עם קשרי המשרעת התואמים.
• צריך להשתמש במיפויים של הקבועים הפיזיים המקושרים האלה.
• צריך לפעול בהתאם להערכת האיכות. למשך createOneShot() וגם createWaveform() ממשקי API.
• צריך לאמת שהתוצאה של התוכן הציבורי android.os.Vibrator.hasAmplitudeControl() ה-API משקף כראוי את היכולות של הרטט.
• עליכם לאמת את היכולות של מדרגיות המשרעת באמצעות הרצה של android.os.Vibrator.hasAmplitudeControl().

אם הטמעות המכשירים מבוססות על המיפוי של הקבועים הפיזיים, הן:

• עליכם לאמת את סטטוס ההטמעה באמצעות הרצת הפקודה android.os.Vibrator.areAllEffectsSupported(). ו-android.os.Vibrator.arePrimitivesSupported() ממשקי API.
• צריך לבצע בדיקת איכות. קבועים פיזיים.
• צריך לאמת ולעדכן במקרה הצורך את ההגדרה החלופית של רכיבים ראשוניים שלא נתמכים כפי שמתואר בהנחיות להטמעה קבועים.
• אמורה לספק תמיכה חלופית כדי לצמצם את הסיכון לכשל, כפי שמתואר כאן.

סיום הדרישות החדשות

דרישות ספציפיות למכשיר מופיעות בסעיף 2.2.1.

7.11. שיעור ביצועי מדיה

אפשר לקבל את סיווג ביצועי המדיה של הטמעת המכשיר מתוך API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. הדרישות לסיווג ביצועי המדיה, לכל גרסת Android שמתחילה ב- R (גרסה 30). הערך המיוחד של 0 מציין שהמכשיר לא שיעור ביצועי המדיה.

אם יישומים של מכשירים מחזירות ערך שאינו אפס עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, הן:

• [C-1-1] חייב להחזיר ערך לפחות של android.os.Build.VERSION_CODES.R.

• [C-1-2] ההטמעה של המכשיר הנייד חייבת להיות במכשירים ניידים.

• [C-1-3] חייב לעמוד בכל הדרישות של 'סיווג ביצועי מדיה' תיאור בסעיף 2.2.7.

במילים אחרות, סיווג ביצועי המדיה ב-Android T מוגדר רק עבור מכשירים ניידים בגרסאות T, S או R.

למידע ספציפי למכשיר, יש לעיין בסעיף 2.2.7 בדרישות שלנו.

8. ביצועים ועוצמה

קריטריונים מסוימים של ביצועים ועוצמה מינימליים הם קריטיים לחוויית המשתמש ולהשפיע על הנחות הבסיס שיהיו למפתחים כשמפתחים אפליקציה.

8.1. עקביות בחוויית המשתמש

ניתן לספק ממשק משתמש חלק למשתמשי הקצה אם יש כדי להבטיח שקצב הפריימים וזמני התגובה יהיו עקביים. אפליקציות ומשחקים. הטמעת מכשירים, בהתאם לסוג המכשיר, ייתכן שיהיו דרישות שניתנות למדידה לגבי זמן האחזור והמשימה של ממשק המשתמש שינוי, כפי שמתואר בקטע 2.

8.2. ביצועים של גישת קלט/פלט לקובץ

מתן בסיס משותף לביצועים עקביים של גישה לקובץ אחסון נתונים פרטיים של אפליקציות (מחיצה של /data) מאפשרת למפתחי אפליקציות להגדיר ציפיות שיעזרו להם לתכנן את התוכנה. Device (מכשיר) ייתכן שיש דרישות מסוימות, בהתאם לסוג המכשיר שמתוארים בקטע 2, ופעולות כתיבה:

• ביצועי כתיבה ברצף. נמדד על ידי כתיבת קובץ 256MB באמצעות מאגר אחסון זמני של 10MB.
• ביצועי כתיבה אקראיים. המדידה מתבצעת על ידי כתיבת קובץ בגודל 256MB לפי גודל של 4KB מאגר נתונים זמני.
• ביצועי קריאה ברצף. נמדד על ידי קריאת קובץ בגודל 256MB באמצעות מאגר אחסון זמני של 10MB.
• ביצועי קריאה אקראיים. המדידה מתבצעת על ידי קריאת קובץ בגודל 256MB לפי גודל של 4KB מאגר נתונים זמני.

8.3. מצבי חיסכון בסוללה

אם ההטמעות במכשירים כוללות תכונות לשיפור ניהול צריכת החשמל של המכשיר שכלולים ב-AOSP (למשל, קטגוריית המתנה של אפליקציה, Doze) או מרחיבות את התכונות כדי להחיל הגבלות מחמירות יותר מקטגוריית ההמתנה המוגבלת של אפליקציות, הן:

• [C-1-1] אסור לסטות מהטמעת ה-AOSP לטריגרים פעולות תחזוקה, אלגוריתמים של יציאה ממצב שינה ושימוש בהגדרות מערכת גלובליות הגדרת המכשיר של מצב 'המתנה' ו'נמנום' של חיסכון בסוללה.
• [C-1-2] אסור לסטות מהטמעת ה-AOSP לשימוש או DeviceConfig כדי לנהל את ויסות הנתונים (throttling) של משימות, התראות הרשת לאפליקציות בכל קטגוריה למצב המתנה.
• [C-1-3] אסור לסטות מיישום ה-AOSP עבור מספר קטגוריות בהמתנה של אפליקציות משמש למצב המתנה.
• [C-1-4] חובה להטמיע קטגוריות המתנה של אפליקציות ו'נמנום' כפי שמתואר בניהול צריכת חשמל.
• [C-1-5] חייב להחזיר true למשך PowerManager.isPowerSaveMode() כשהמכשיר נמצא במצב חיסכון בסוללה.
• [C-1-6] חובה לספק למשתמשים אפשרות להציג את כל האפליקציות שפטורות ממצב המתנה ו'נמנום', חיסכון בסוללה או כל אופטימיזציה אחרת של הסוללה וחובה ליישם את הפעולה ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS כוונה לבקש מהמשתמש לאפשר לאפליקציה להתעלם מהסוללה ואופטימיזציות.
• [C-SR-1] מומלץ מאוד לספק למשתמשים מספיק כסף כדי לאפשר להם להשבית את תכונת החיסכון בסוללה.
• [C-SR-2] מומלץ מאוד לספק למשתמשים אפשרות להציג את כל אפליקציות שפטורות ממצבי 'המתנה' ו'נמנום' של חיסכון בסוללה.

אם ההטמעות במכשירים מרחיבות את התכונות של ניהול צריכת החשמל שכלולות ב-AOSP, והתוסף הזה מחילה הגבלות מחמירות יותר The Rare App Standby Bucket, לעיון בסעיף 3.5.1.

בנוסף למצבי החיסכון באנרגיה, הטמעות של מכשירי Android במאי להטמיע אחד או את כל ארבעת מצבי השינה של כוח שינה, כפי שהוגדרו על ידי Configuration ו-Power Interface (ACPI).

אם בהטמעות של מכשירים מיושמות מצבי הפעלה של S4 כפי שהוגדרו על ידי ACPI, הם:

• [C-1-1] חובה להזין את המצב הזה רק אחרי שהמשתמש ביצע פעולה מפורשת כדי להעביר את המכשיר למצב לא פעיל (למשל, על ידי סגירת מכסה שנמצא פיזית חלק מהמכשיר או כיבוי של רכב או טלוויזיה) ולפני משתמש מפעיל מחדש את המכשיר (למשל, על ידי פתיחת המכסה או סיבוב הרכב או להפעיל את הטלוויזיה מחדש).

אם בהטמעות של מכשירים מיושמים מצבי הפעלה של S3 כפי שהוגדרו על ידי ACPI, הם:

• [C-2-1] חובה לעמוד בדרישות C-1-1 שלמעלה, או, חייבים להיכנס למצב S3 רק כשצד שלישי שאפליקציות לא צריכות את משאבי המערכת (למשל המסך, ה-CPU).

  לעומת זאת, חייבים לצאת ממצב S3 כשאפליקציות של צד שלישי צריכות במשאבי המערכת, כפי שמתואר בערכת ה-SDK הזו.

  לדוגמה, בזמן שהאפליקציות של הצד השלישי מבקשות להשאיר את המסך פועל עד FLAG_KEEP_SCREEN_ON, או שהמעבד (CPU) פועל PARTIAL_WAKE_LOCK, אסור שהמכשיר יהיה במצב S3 אלא אם, כפי שמתואר ב-C-1-1, המשתמש נקט פעולה מפורשת כדי להציב את המכשיר במצב לא פעיל. לעומת זאת, כאשר משימה של אפליקציה של צד שלישי שההטמעה שלו מתבצעת דרך JobScheduler, או כאשר שירות העברת ההודעות בענן ב-Firebase מופעל לספקים של צד שלישי, המכשיר חייב לצאת ממצב S3, אלא אם המשתמש העביר את המכשיר למצב לא פעיל. התשובות לא מקיפות לדוגמה, ו-AOSP מטמיע אותות התעוררות נרחבים שעלולים לגרום ליציאה ממצב שינה מהמצב הזה.

8.4. חשבונאות של צריכת הכוח

חשבונאות ודיווח מדויקים יותר לגבי צריכת החשמל מספקים גם את התמריצים וגם את הכלים לאופטימיזציה של צריכת החשמל של האפליקציה.

הטמעות מכשירים:

• [C-SR-1] מומלץ מאוד לספק פרופיל כוח לכל רכיב שמגדיר את ערך הצריכה הנוכחית. לגבי כל רכיב חומרה והתרוקנות משוערת של הסוללה שנגרמה על ידי הרכיבים לאורך זמן, כפי שמתואר באתר פרויקט הקוד הפתוח של Android.
• [C-SR-2] מומלץ מאוד לדווח על כל ערכי צריכת החשמל במיליאמפר שעות (mAh).
• [C-SR-3] מומלץ מאוד לדווח על צריכת החשמל של המעבד (CPU) לפי ה-UID של כל תהליך. פרויקט הקוד הפתוח של Android עומד בדרישה באמצעות הטמעת מודול הליבה של uid_cputime.
• [C-SR-4] מומלץ מאוד להפעיל את השימוש בחשמל הזה adb shell dumpsys batterystats פקודת מעטפת למפתח האפליקציה.
• צריך להיות משויך לרכיב החומרה עצמו אם לא ניתן שיוך של צריכת החשמל של רכיב חומרה לאפליקציה.

8.5. ביצועים עקביים

יכולות להיות תנודות משמעותיות בביצועים של אפליקציות ממושכות, בעלות ביצועים גבוהים, בגלל שאפליקציות אחרות פועלות ברקע או ויסות נתונים (throttle) של המעבד עקב מגבלות הטמפרטורה. ב-Android יש ממשקים פרוגרמטיים, כך שכאשר המכשיר יכול, האפליקציה בחזית יכולה לבקש והמערכת תבצע אופטימיזציה של הקצאת המשאבים כדי לטפל בתנודות כאלה.

הטמעות מכשירים:

• [C-0-1] חובה לדווח על התמיכה במצב 'ביצועים קבועים' באופן מדויק באמצעות PowerManager.isSustainedPerformanceModeSupported() שיטת ה-API.

• אמורה לתמוך במצב ביצועים קבועים.

אם יישומים של מכשירים ידווחו על תמיכה במצב ביצועים עקביים:

• [C-1-1] חובה לספק לאפליקציה בחזית ברמה עקבית של את הביצועים שלה למשך 30 דקות לפחות, כשהאפליקציה מבקשת אותם.
• [C-1-2] חייבים לכבד את Window.setSustainedPerformanceMode() API וממשקי API קשורים אחרים.

אם הטמעות המכשיר כוללות שתי ליבות מעבד (CPU) או יותר:

• צריכה לספק לפחות ליבה בלעדית אחת שניתן להזמין מראש של האפליקציה בחזית.

אם בהטמעות במכשירים יש תמיכה בהזמנת ליבה בלעדית אחת לראש הרשימה באפליקציה בחזית, הן:

• [C-2-1] חובה לדווח על Process.getExclusiveCores() שיטת ה-API משתמשת במספרי הזיהוי של הליבות הבלעדיות שאפשר לשמור לפי האפליקציה בחזית.
• [C-2-2] אסור לאפשר תהליכי מרחב של משתמשים מלבד מנהלי ההתקנים של המכשירים ששימשה את האפליקציה להרצה על ליבות בלעדיות, אבל ייתכן שהיא תאפשר תהליכי ליבה (kernel) שיפעלו לפי הצורך.

אם הטמעות של מכשירים לא תומכות בליבה בלעדית, הן:

• [C-3-1] חייבת להחזיר רשימה ריקה דרך Process.getExclusiveCores() שיטת ה-API.

9. תאימות של דגם אבטחה

הטמעות מכשירים:

• [C-0-1] חובה להטמיע מודל אבטחה עקבי במודל האבטחה של פלטפורמת Android כפי שמוגדר מסמך עזר בנושא אבטחה והרשאות בממשקי ה-API בתיעוד למפתחים של Android.

• [C-0-2] חייבת לתמוך בהתקנה של חתימה עצמית ללא צורך בהרשאות/אישורים נוספים מכל צדדים שלישיים/רשויות.

אם בהטמעות במכשירים מוצהר על android.hardware.security.model.compatible הם:

• [C-1-1] חייבת לתמוך בדרישות שמפורטות בסעיפי המשנה הבאים.

9.1. הרשאות

הטמעות מכשירים:

• [C-0-1] חייבת לתמוך במודל ההרשאות של Android מודל התפקידים ב-Android כפי שמוגדר בתיעוד למפתחים של Android. באופן ספציפי, חובה לאכוף כל הרשאה ותפקיד שמוגדרים כפי שמתואר מסמכי תיעוד בנושא SDK; אי אפשר להשמיט או לשנות תפקידים, או שהמערכת מתעלמת מהם.

• יכול להיות שיתווספו עוד הרשאות, בתנאי שיש מחרוזות חדשות של מזהה ההרשאה אינם במרחב השמות android.\*.

• [C-0-2] הרשאות עם protectionLevel של PROTECTION_FLAG_PRIVILEGED חייבים להעניק את ההרשאה רק לאפליקציות שהותקנו מראש בנתיבים שיש בהם הרשאות של את קובץ האימג' של המערכת, וגם קובצי APEX) בקבוצת המשנה של ההרשאות שנוספו באופן מפורש לרשימת ההיתרים לכל אפליקציה. הטמעת ה-AOSP עומדת בדרישה הזו. לשם כך, היא קוראת את המדיניות ופועלת בהתאם הרשאות שנמצאות ברשימת ההיתרים לכל אפליקציה מהקבצים ב etc/permissions/ ושימוש בנתיב system/priv-app בתור נתיב בעל הרשאות.

הרשאות עם רמת הגנה מסוכנות הן הרשאות בתחילת ההפעלה. אפליקציות עם targetSdkVersion > 22 לבקש אותם בזמן הריצה.

הטמעות מכשירים:

• [C-0-3] חובה להציג ממשק ייעודי למשתמש שיכול להחליט האם להעניק את ההרשאות הנדרשות בתחילת ההפעלה, וגם לספק ממשק שבו המשתמש יכול לנהל הרשאות בתחילת ההפעלה.

• [C-0-4] חובה להטמיע לפחות אחד מהסוגים של שני המשתמשים ממשקים.

• [C-0-5] אסור להעניק הרשאות בזמן ריצה לאפליקציות, אלא אם:

  • הם מותקנים בזמן משלוח המכשיר, וגם

  • ניתן לקבל את הסכמת המשתמש לפני הגשת הבקשה משתמש בהרשאה,

    או

  • ההרשאות בתחילת ההפעלה ניתנות לפי מדיניות ברירת המחדל להענקת הרשאות או עבור תפקיד פלטפורמה.

• [C-0-6] חייבים לתת את ההרשאה android.permission.RECOVER_KEYSTORE רק לאפליקציות מערכת שרושמות סוכן שחזור מאובטח כראוי. א' סוכן שחזור שמאובטח כראוי מוגדר כסוכן תוכנה במכשיר שמסתנכרן עם אחסון מרוחק מחוץ למכשיר, שכולל חומרה מאובטחת עם הגנה מקבילה או חזקה יותר מתואר ב: שירות Google Cloud Key Vault למניעת התקפות brute-Force על גורם הידע במסך הנעילה.

הטמעות מכשירים:

• [C-0-7] האפליקציה חייבת לפעול בהתאם לנכסים של הרשאות מיקום ב-Android מבקשת את נתוני המיקום או הפעילות הפיזית דרך ה-API הרגיל של Android או מנגנון קנייני. נתונים כאלה כוללים, בין היתר:

  • מיקום המכשיר (למשל קו רוחב וקו אורך) כפי שמתואר ב סעיף 9.8.8.
  • מידע שיכול לשמש כדי להעריך או להעריך את הביצועים של המכשיר המיקום (למשל SSID, BSSID, מזהה תא, או מיקום הרשת). שהמכשיר מחובר אליו).
  • הפעילות הגופנית של המשתמש או סיווג הפעילות הגופנית.

באופן ספציפי יותר, הטמעות מכשירים:

• [C-0-8] חובה לקבל הסכמה מהמשתמשים כדי לאפשר לאפליקציה לגשת אל נתוני מיקום או פעילות גופנית.
• [C-0-9] חייבת להעניק הרשאה בתחילת ההפעלה רק לאפליקציה שמכילה את הרשאה מספקת כפי שמתואר ב-SDK. לדוגמה, BrowseManager#getServiceState נדרש android.permission.ACCESS_FINE_LOCATION).

החריגים היחידים למאפיינים של הרשאות המיקום ב-Android שצוינו למעלה הם עבור אפליקציות שלא ניגשות למיקום כדי להסיק או לזהות את מיקום המשתמש; ובאופן ספציפי:

• כשאפליקציות מחזיקות בהרשאה RADIO_SCAN_WITHOUT_LOCATION.
• למטרות הגדרה והגדרה של המכשיר, כאשר אפליקציות המערכת כוללות את הרשאה NETWORK_SETTINGS או NETWORK_SETUP_WIZARD.

אפשר לסמן הרשאות כמוגבלות בשינוי ההתנהגות.

• [C-0-10] הרשאות שמסומנות בדגל hardRestricted לא יכולות להיות מוענק לאפליקציה, אלא אם:

  • קובץ APK של אפליקציה נמצא במחיצת המערכת.
  • המשתמש מקצה תפקיד שמשויך ל-hardRestricted הרשאות לאפליקציה.
  • מנהל ההתקנה מעניק את ההרשאה hardRestricted לאפליקציה.
  • אפליקציה מקבלת את hardRestricted בגרסה קודמת של Android.

• [C-0-11] אפליקציות עם הרשאת softRestricted חייבות להיות מוגבלות בלבד ולא לקבל גישה מלאה עד שהם יופיעו ברשימת ההיתרים, כפי שמתואר SDK, כאשר גישה מלאה ומוגבלת מוגדרת לכל softRestricted (לדוגמה, READ_EXTERNAL_STORAGE).

• [C-0-12] אסור לספק פונקציות מותאמות אישית או ממשקי API כדי לעקוף את הגבלות על הרשאות שהוגדרו ב-setAuthorPolicy ו-setAuthorGrantState ממשקי API.

• [C-0-13] חייבים להשתמש בממשקי ה-API של AppOpsManager כדי לתעד ולעקוב אחרי כל פעילות, כל גישה פרוגרמטית לנתונים המוגנים באמצעות הרשאות מסוכנות פעילויות ושירותים ב-Android.

• [C-0-14] חובה להקצות תפקידים רק לאפליקציות עם פונקציות לעמוד בדרישות התפקיד.

• [C-0-15] אסור להגדיר תפקידים שהם עותקים כפולים או פונקציונליות של קבוצות-על של התפקידים שהפלטפורמה מגדירה.

אם המכשירים מדווחים על android.software.managed_users, הם:

• [C-1-1] אסור לקבל את ההרשאות הבאות באופן שקט מטעם admin:
  • מיקום (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
  • מצלמה (CAMERA)
  • מיקרופון (RECORD_AUDIO)
  • חיישן גוף (BODY_SENSORS)
  • פעילות גופנית (ACTIVITY_RECOGNITION)

אם יישומי מכשירים מאפשרים למשתמש לבחור אילו אפליקציות יוכלו צייר מעל אפליקציות אחרות בפעילות שמטפלת ACTION_MANAGE_OVERLAY_PERMISSION בכוונה טובה, הם:

• [C-2-1] חובה לוודא שכל הפעילויות עם מסנני Intent ACTION_MANAGE_OVERLAY_PERMISSION ל-Intent יש מסך זהה בממשק המשתמש, בלי קשר לאפליקציה שמתחילה את התהליך או שהוא מספק.

אם יישומים של מכשירים מדווחים על android.software.device_admin, הם:

• [C-3-1] חובה להציג כתב ויתור במהלך הגדרת מכשיר מנוהלת באופן מלא (הגדרת בעל המכשיר) שמציינת שהאדמין ב-IT יוכל מאפשר לאפליקציות לשלוט בהגדרות בטלפון, כולל המיקרופון, המצלמה עם אפשרויות נוספות למשתמש להמשיך בהגדרה או לצאת מתהליך ההגדרה, אלא אם האדמין ביטל את השליטה בהרשאות במכשיר.

אם המכשיר מטמיע מראש חבילות שמכילות את אחד מהתפקידים System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence או System Visual Intelligence, החבילות:

• [C-4-1] חובה לעמוד בכל הדרישות שצוינו לגבי הטמעת מכשירים במדינות מדורים "9.8.6 הקלטת תוכן" "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.2. UID ובידוד של תהליכים

הטמעות מכשירים:

• [C-0-1] חייבת לתמוך באפליקציה ל-Android ארגז חול, שבו כל אפליקציה פועלת בתור UID ייחודי של Unixstyle ובתהליך נפרד.
• [C-0-2] חייבת להיות תמיכה בהפעלה של מספר אפליקציות אותו מזהה משתמש ב-Linux, בתנאי שהאפליקציות חתומות כראוי ונבנה, כפי שמוגדר חומר עזר בנושא אבטחה והרשאות.

9.3. הרשאות במערכת הקבצים

הטמעות מכשירים:

• [C-0-1] חייבת לתמוך בגישה לקובץ ב-Android מודל ההרשאות כפי שמוגדר חומר עזר בנושא אבטחה והרשאות.

9.4. סביבות הפעלה חלופיות

אפליקציות המכשירים חייבות לשמור על עקביות באבטחה של Android מודל הרשאות, גם אם הם כוללים סביבות זמן ריצה שכוללות באמצעות תוכנה או טכנולוגיה אחרות מלבד קובץ ההפעלה של Dalvik פורמט או קוד נייטיב. במילים אחרות:

• [C-0-1] זמני ריצה חלופיים חייבים להיות אפליקציות ל-Android, ולפעול בהתאם למודל האבטחה הסטנדרטי של Android, כמו שמתואר במקום אחר בקטע 9.

• [C-0-2] אסור לתת לזמני ריצה חלופיים גישה למשאבים מוגן על ידי הרשאות שלא התבקשו ב-AndroidManifest.xml של סביבת זמן הריצה דרך <uses-permission> על מנגנוני תשומת לב.

• [C-0-3] אסור לאפשר לאפליקציות להשתמש בסביבות זמני ריצה חלופיים תכונות שמוגנות באמצעות הרשאות Android שמוגבלות לאפליקציות מערכת.

• [C-0-4] זמני ריצה חלופיים חייבים לעמוד בדרישות של מודל ארגז החול של Android ואת האפליקציות המותקנות באמצעות סביבת זמן ריצה חלופית, אסור לעשות שימוש חוזר בארגז החול של כל אפליקציה אחרת שמותקנת במכשיר, אלא אם המנגנונים הרגילים של Android של מזהה משתמש משותף ואישור חתימה.

• [C-0-5] אסור להפעיל זמני ריצה חלופיים עם, להעניק או לקבל אישור גישה ל-Sandboxs שמתאימים לאפליקציות אחרות ל-Android.

• [C-0-6] אסור להפעיל סביבות ריצה חלופיות, לקבל אותן או לאשר אותן לאפליקציות אחרות הרשאות כלשהן של משתמש-על (הרמה הבסיסית) או של כל מזהה משתמש.

• [C-0-7] כשקובצי .apk של זמני ריצה חלופיים נכללים תמונת מערכת של יישומי מכשיר, חייב להיות חתום עליו באמצעות מפתח ייחודי מהמפתח שמשמש לחתימה על אפליקציות אחרות שכלולות במכשיר בפועל.

• [C-0-8] במהלך התקנת אפליקציות, זמני ריצה חלופיים חייבים הסכמת המשתמש להרשאות Android שמשמשות את האפליקציה.

• [C-0-9] כשאפליקציה צריכה להשתמש במשאב של המכשיר שקיימת הרשאה תואמת של Android (כמו מצלמה, GPS וכו'), סביבת זמן הריצה החלופית חייבת להודיע למשתמש שהאפליקציה תוכל לגשת למשאב הזה.

• [C-0-10] כשסביבת זמן הריצה לא מתעדת את האפליקציה באופן הזה, סביבת זמן הריצה חייבת להציג רשימה של כל ההרשאות שנמצא בסביבת זמן הריצה עצמה במהלך התקנת אפליקציה כלשהי באמצעות אותו זמן ריצה.

• אם יש זמני ריצה חלופיים, צריך להתקין אפליקציות דרך PackageManager בתוך ארגזי חול (Sandbox) נפרדים של Android (מזהי משתמשים ב-Linux וכו').

• ייתכן שזמני ריצה חלופיים מספקים ארגז חול אחד של Android לכולם שמשותף לכולם באמצעות סביבת זמן הריצה החלופית.

9.5. תמיכה במשתמשים מרובים

Android כולל תמיכה במשתמשים מרובים ומספקת תמיכה לבידוד מלא של משתמשים ולשכפול פרופילי משתמשים עם בידוד חלקי(כלומר פרופיל משתמש אחד נוסף מסוג מסוים) android.os.usertype.profile.CLONE).

• ייתכן שהטמעת מכשירים במכשירים שונים, אבל לא אמורים לאפשר שימוש בריבוי משתמשים אם הם משתמשים מדיה נשלפת לאחסון חיצוני ראשי.

אם הטמעות במכשירים כוללות תמיכה בריבוי משתמשים, הן:

• [C-1-2] חובה להטמיע אמצעי אבטחה לכל משתמש תואם למודל האבטחה של פלטפורמת Android כפי שמוגדר מסמך עזר בנושא אבטחה והרשאות בממשקי ה-API.
• [C-1-3] חייב להיות אחסון משותף נפרד ונפרד של האפליקציה (שנקראות גם /sdcard) ספריות לכל מופע של משתמש.
• [C-1-4] חובה לוודא שאפליקציות שנמצאות בבעלות ובהפעלה של משתמש נתון לא יכול לרשום, לקרוא או לכתוב בקבצים שבבעלות אף משתמש אחר, גם אם הנתונים של שני המשתמשים מאוחסנים באותו נפח אחסון או באותה מערכת קבצים.
• [C-1-5] חובה להצפין את התוכן של כרטיס ה-SD כאשר האפשרות 'ריבוי משתמשים' מופעלת באמצעות מפתח המאוחסן רק במדיה שאינה נשלפת, הנגישה למערכת רק אם יישומים של מכשירים משתמשים במדיה נשלפת עבור ממשקי API של אחסון חיצוני. מאחר שהפעולה הזו תהפוך את המדיה לבלתי קריאה על ידי מחשב מארח, יישומים של מכשירים יידרשו לעבור ל-MTP או למערכת דומה כדי לספק מחשבים מארחים גישה לנתונים של המשתמש הנוכחי.

אם הטמעות המכשירים כוללות תמיכה במשתמשים מרובים, אז עבור כל המשתמשים למעט משתמשים שנוצרו במיוחד להפעלת מופעים כפולים של אותה אפליקציה, הם:

• [C-2-1] חייב להיות אחסון משותף נפרד ונפרד של האפליקציה (שנקרא גם /sdcard) לכל מופע של משתמש.
• [C-2-2] חייבים לוודא שאפליקציות שנמצאות בבעלותם ומופעלות על ידי מטעם משתמש נתון לא יכול לרשום את הקבצים שבבעלותו, לקרוא או לכתוב אותם על ידי כל משתמש אחר, גם אם הנתונים של שני המשתמשים מאוחסנים באותו מכשיר נפח אחסון או מערכת קבצים.

הטמעת מכשירים עשויים ליצור פרופיל משתמש אחד נוסף מסוג מסוים android.os.usertype.profile.CLONE מול המשתמש הראשי (ורק כנגד המשתמש הראשי המשתמש הראשי) כדי להפעיל שני מופעים של אותה האפליקציה. שתי המכונות האלה חולקות נפח אחסון מבודד חלקית, משתמש הקצה במרכז האפליקציות בו-זמנית ויופיעו באותה תצוגת האחרונים. לדוגמה, הוא יכול לשמש כדי לתמוך בהתקנה של של אפליקציה אחת במכשיר עם SIM כפול.

אם הטמעות של מכשירים יוצרות את פרופיל המשתמש הנוסף שמתואר למעלה, ואז:

• [C-3-1] חובה לספק גישה רק לנפח אחסון או לנתונים שכבר נגיש לפרופיל המשתמש ההורה או נמצא בבעלות ישירה שלו פרופיל משתמש נוסף.
• [C-3-2] אסור להגדיר את הפרופיל כפרופיל עבודה.
• [C-3-3] חובה ליצור ספריות נתונים פרטיות של האפליקציה ששייכים להורה חשבון משתמש.
• [C-3-4] אסור לאפשר יצירה של פרופיל משתמש נוסף אם האם הוקצה בעלי מכשיר (ראה סעיף 3.9.1) או אפשר לבעלי מכשיר יוקצה בלי להסיר קודם את פרופיל המשתמש הנוסף.

התחלה של דרישות חדשות

אם הטמעות של מכשירים יוצרות את פרופיל המשתמש הנוסף שמתואר למעלה, ואז:

• [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] חובה לרשת את כל הגבלות המשתמשים של מדיניות המכשירים ואת כל האפשרויות שנבחרו הגבלות על משתמשים שהם לא משתמשים(רשימה למטה) שחלות על המשתמש הראשי במכשיר לפרופיל המשתמש הנוסף הזה.

  • setScreenCaptureDisabled
  • setAccountManagementDisabled
  • setCameraDisabled
  • setPermittedInputMethods
  • setApplicationHidden
  • setPersonalAppsSuspended

• [C-4-3] חובה לאפשר כתיבה של אנשי קשר מהפרופיל הנוסף הזה רק באמצעות את הכוונות הבאות:

  • ContactsContract.Intents.Insert.ACTION
  • Intent.ACTION_PICK
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT_OR_EDIT

• [C-4-4] אסור להפעיל סנכרונים של אנשי קשר עבור אפליקציות שפועלות לפרופיל המשתמש הנוסף הזה.

• [C-4-14] חייבת להיות הרשאה נפרדת וניהול אחסון עבור אפליקציות שפועלות בפרופיל הנוסף הזה

• [C-4-5] חייבים לאפשר רק אפליקציות בפרופיל הנוסף שיש להן סוג של פעילות של מרכז האפליקציות כדי לגשת לאנשי קשר שכבר ניתן לגשת אליהם פרופיל משתמש הורה.

סיום הדרישות החדשות

9.6. אזהרה לגבי SMS פרימיום

ב-Android יש תמיכה באזהרה למשתמשים מפני הודעות יוצאות הודעת SMS פרימיום. הודעות SMS פרימיום הודעות הן הודעות טקסט שנשלחות לשירות שרשום אצל ספק הסלולר נחייב את המשתמש.

אם בהטמעות המכשירים מוצהר על תמיכה ב-android.hardware.telephony, הם:

• [C-1-1] חובה להזהיר משתמשים לפני שליחת הודעת SMS למספרים מזוהה באמצעות ביטויים רגולריים שמוגדרים ב-/data/misc/sms/codes.xml בקובץ במכשיר. פרויקט הקוד הפתוח של Android ב-upstream מספק יישום שעומד בדרישה הזו.

9.7. תכונות אבטחה

הטמעת מכשירים חייבת להבטיח תאימות לתכונות אבטחה הליבה (kernel) והפלטפורמה כפי שמתואר בהמשך.

ה-Sandbox של Android כולל תכונות שמתבססות על טכנולוגיית Linux משופרת (SELinux) מערכת בקרת גישה (MAC), הרצה בארגז חול (sandboxing) ב-seccomp ועוד בתכונות האבטחה בליבה (kernel) של Linux. הטמעות מכשירים:

• [C-0-1] חייבת לשמור על תאימות לאפליקציות קיימות, גם במקרים שבהם SELinux או תכונות אבטחה אחרות מוטמעות מתחת ל-Android .
• [C-0-2] אסור שיהיה ממשק משתמש גלוי כשניתן זוהתה הפרה ונחסמה בהצלחה על ידי תכונת האבטחה שמוטמעות מתחת ל-framework של Android, אבל יכול להיות שממשק משתמש יהיה גלוי כאשר מתרחשת הפרת אבטחה שהחסימה שלה בוטלה וכתוצאה מכך ניצול מוצלח.
• [C-0-3] אסור להטמיע SELinux או תכונות אבטחה אחרות מתחת ל-framework של Android שאפשר להגדיר למשתמש או למפתח האפליקציה.
• [C-0-4] אסור לאפשר אפליקציה שיכולה להשפיע על אפליקציה אחרת באמצעות ממשק API (כמו Device Administration API) כדי להגדיר מדיניות שפוגעת בתאימות.
• [C-0-5] חייבים לפצל את מסגרת המדיה למספר תהליכים כדי אפשרות להעניק גישה לכל תהליך באופן צר יותר תיאור באתר פרויקט הקוד הפתוח של Android.
• [C-0-6] חובה להטמיע מנגנון הרצה בארגז חול (sandboxing) באפליקציית ליבה (kernel) שמאפשר לסנן קריאות מערכת באמצעות מדיניות שניתנת להגדרה, תוכנות מרובות שרשורים. פרויקט הקוד הפתוח של Android ב-upstream עומד בדרישות האלה דרישה באמצעות הפעלת seccomp-BPF עם threadgroup סנכרון (TSYNC) כפי שמתואר בקטע Kernel Configuration של source.android.com.

התכונות של תקינות הליבה וההגנה העצמית הן חלק בלתי נפרד מ-Android אבטחה. הטמעות מכשירים:

• [C-0-7] חובה להטמיע מנגנוני הגנה על גלישת מאגר נתונים זמני של ליבה (kernel). דוגמאות למנגנונים כאלה: CC_STACKPROTECTOR_REGULAR CONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] חובה להטמיע הגנות מחמירות על זיכרון ליבה (kernel) כאשר קובץ הפעלה הוא לקריאה בלבד, נתונים לקריאה בלבד אינם ניתנים להפעלה ולא לכתיבה, לא ניתן להפעיל נתונים לכתיבה (למשל CONFIG_DEBUG_RODATA או CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] חובה להטמיע גודל אובייקט סטטי ודינמי בדיקת גבולות של עותקים בין מרחב המשתמש ומרחב הליבה (למשל CONFIG_HARDENED_USERCOPY) במכשירים שנשלחו במקור ברמת API 28 ומעלה.
• [C-0-10] אסור להפעיל זיכרון-מרחב משתמש במהלך הרצה במצב הליבה (למשל, חומרה PXN או אמולציה דרך CONFIG_CPU_SW_DOMAIN_PAN או CONFIG_ARM64_SW_TTBR0_PAN) במכשירים במקור במשלוח ברמת API 28 ומעלה.
• [C-0-11] אסור לקרוא או לכתוב זיכרון של מרחב משתמש ליבה (kernel) מחוץ לממשקי API רגילים לגישה לעותק משתמש (למשל, מספר PAN של החומרה, או אמולציה באמצעות CONFIG_CPU_SW_DOMAIN_PAN או CONFIG_ARM64_SW_TTBR0_PAN) במכשירים שנשלחו במקור עם API ברמת 28 ומעלה.
• [C-0-12] חובה להטמיע בידוד של טבלת דפי ליבה (kernel) אם החומרה חשופה ל-CVE-2017-5754 בכל המכשירים שנשלחו במקור עם רמת API 28 ומעלה (למשל, CONFIG_PAGE_TABLE_ISOLATION או CONFIG_UNMAP_KERNEL_AT_EL0).

• [C-0-13] חובה להטמיע הקשחת חיזוי הסתעפות אם החומרה חשופה ל-CVE-2017-5715 בכל המכשירים שנשלחו במקור עם רמת API 28 ומעלה (למשל, CONFIG_HARDEN_BRANCH_PREDICTOR).

• [C-SR-1] מומלץ מאוד לשמור נתוני ליבה שנכתב רק במהלך האתחול ומסומן לקריאה בלבד לאחר מכן אתחול (למשל __ro_after_init).

• [C-SR-2] מומלץ מאוד ליצור באופן אקראי את הפריסה של קוד הליבה זיכרון, וכדי להימנע מחשיפות שעלולות לסכן את הרנדומיזציה (לדוגמה, CONFIG_RANDOMIZE_BASE עם אנטרופיה של תוכנת האתחול דרך /chosen/kaslr-seed Device Tree node או EFI_RNG_PROTOCOL).

• [C-SR-3] מומלץ מאוד להפעיל את תקינות הזרימה (CFI) ב- הליבה לספק הגנה נוספת מפני התקפות שימוש חוזר בקוד (למשל CONFIG_CFI_CLANG ו-CONFIG_SHADOW_CALL_STACK).

• [C-SR-4] מומלץ מאוד לא להשבית את שלמות האפליקציה (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] מומלץ מאוד להפעיל אתחול ערימה בליבה (kernel) כדי למנוע שימושים בהקצאות אינסופיות של תמונת מצב של הזיכרון (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) והם לא צריכים להניח את הערך שמשמש את הליבה לאתחול ההקצאות האלה.

אם יישומים של מכשירים משתמשים בליבה (kernel) של Linux שמסוגלת לתמוך SELinux:

• [C-1-1] חובה להטמיע את SELinux.
• [C-1-2] חייבים להגדיר את SELinux למצב אכיפה גלובלי.
• [C-1-3] חובה להגדיר את כל הדומיינים במצב אכיפה. אין מצב מתירנות מותרים דומיינים, כולל דומיינים ספציפיים למכשיר או לספק.
• [C-1-4] אסור לשנות, להשמיט או להחליף את הכללים הקיימים של אף פעם בתיקיית המערכת/sepolicy שסופקה ב-upstream ב-Android Open Source הפרויקט (AOSP) והמדיניות חייבים להיות מורכבים מכל הכללים הקיימים של אף פעם, גם לדומיינים של AOSP SELinux וגם לדומיינים ספציפיים למכשיר/לספק.
• [C-1-5] חייבות להפעיל אפליקציות של צד שלישי שמטרגטות לרמת API 28 ומעלה בארגזי Sandbox של SELinux לכל אפליקציה, עם הגבלות SELinux לכל אפליקציה לספריית המידע הפרטי של האפליקציה.
• מדיניות ברירת המחדל של SELinux אמורה להישאר כפי שהוגדרה במערכת או במדיניות של פרויקט הקוד הפתוח של Android ב-upstream ולהוסיף לו רק המדיניות הספציפית למכשיר שלהם.

אם בהטמעות של מכשירים נעשה שימוש בליבה (kernel) שאינה Linux או Linux ללא SELinux, הם:

• [C-2-1] חובה להשתמש במערכת בקרת גישה הכרחית ל-SELinux.

אם הטמעות של מכשירים עושות שימוש במכשירי קלט/פלט (I/O) שתומכים ב-DMA:

• [C-SR-9] מומלץ מאוד לבודד כל מכשיר קלט/פלט (I/O) שמסוגל להפר חוק ה-DMA, באמצעות IOMMU (למשל ARM SMMU).

ב-Android יש כמה תכונות של הגנה לעומק שהן חלק בלתי נפרד מהמכשיר אבטחה. בנוסף, מערכת Android מתמקדת בצמצום הסוגים העיקריים של באגים נפוצים שתורמים לאיכות נמוכה ולאבטחה נמוכה.

כדי לצמצם באגים בזיכרון, הטמעות במכשירים:

• [C-SR-10] מומלץ מאוד לבדוק אותם באמצעות שגיאת זיכרון במרחב המשתמש כלי זיהוי כמו MTE למכשירי ARMv9, HWASan למכשירי ARMv8+ או ASan. לסוגים אחרים של מכשירים.
• [C-SR-11] מומלץ מאוד לבדוק אותם באמצעות שגיאת זיכרון ליבה (kernel) כלי זיהוי כמו KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS עבור מכשירי ARMv9, CONFIG_KASAN_SW_TAGS למכשירי ARMv8 או CONFIG_KASAN_GENERIC עבור סוגי מכשירים אחרים).
• [C-SR-12] מומלץ מאוד להשתמש בכלים לזיהוי שגיאות זיכרון בסביבת ייצור כמו MTE, GWP-ASan ו-KFENCE.

אם בהטמעות במכשירים נעשה שימוש בסביבת TEE שמבוססת על Arm TrustZone:

• [C-SR-13] מומלץ מאוד להשתמש בפרוטוקול סטנדרטי לזיכרון בין Android לסביבת ה-TEE, כגון Arm Firmware Framework Armv8-A (FF-A).
• [C-SR-14] מומלץ מאוד להגביל אפליקציות מהימנות רק לגשת לזיכרון שכבר שותף איתם באופן מפורש דרך של Google. אם המכשיר תומך ברמת החריגה Arm S-EL2, ייאכף על ידי מנהל המחיצות המאובטחות. אחרת, זה צריך להיות נאכף על ידי מערכת ההפעלה TEE.

התחלה של דרישות חדשות

טכנולוגיה לשמירה על בטיחות הזיכרון היא טכנולוגיה שמפחיתה לפחות את הסיכונים הבאים סוגים של באגים עם סבירות גבוהה (מעל 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. פרטיות

9.8.1. היסטוריית שימוש

מערכת Android שומרת את ההיסטוריה של הבחירות של המשתמש ומנהלת את ההיסטוריה הזו על ידי UsageStatsManager.

הטמעות מכשירים:

• [C-0-1] חובה לשמור על תקופת שמירה סבירה של היסטוריית משתמשים כזו.
• [C-SR-1] מומלץ מאוד לשמור על תקופת השמירה של 14 ימים מוגדר כברירת מחדל בהטמעת ה-AOSP.

אירועי המערכת נשמרים ב-Android באמצעות StatsLog ולנהל היסטוריה כזו באמצעות StatsManager IncidentManager System API.

הטמעות מכשירים:

• [C-0-2] חובה לכלול רק את השדות המסומנים ב-DEST_AUTOMATIC דוח אירוע שנוצר על ידי מחלקת ה-System API IncidentManager.
• [C-0-3] אסור להשתמש במזהי האירועים של המערכת כדי לתעד אירועים אחרים ממה שמתואר במאמר StatsLog מסמכי SDK. אם נרשמים עוד אירועי מערכת, יכול להיות שהם ישתמשו טווח של 100,000 עד 200,000.

9.8.2. מתבצעת הקלטה

הטמעות מכשירים:

• [C-0-1] אסור לטעון מראש או להפיץ רכיבי תוכנה שנמצאים מחוץ לאריזה לשלוח את המידע הפרטי של המשתמש (למשל הקשות, טקסט שמוצג מסך, דוח על באג) מהמכשיר ללא הסכמת המשתמש או מחיקה התראות מתמשכות.
• [C-0-2] חובה להציג אזהרה למשתמש ולקבל הסכמה מפורשת מהמשתמשים המתאפשרת צילום של כל מידע רגיש שמוצג על מסך המשתמששכולל בדיוק אותה הודעה כמו AOSP בכל זמן בכל פעם שהסשן פעיל המסך העברה (cast) או הקלטת מסך מופעלת התחילו דרך MediaProjection.createVirtualDisplay(), VirtualDeviceManager.createVirtualDisplay(), או ממשקי API קנייניים. אסור לספק למשתמשים אפשרות להשבית תצוגה עתידית של הסכמת המשתמש.
• [C-0-3] חייבת להיות התראה מתמשכת למשתמש בזמן הפעלת Cast של התוכן במסך או הקלטת המסך מופעלות. AOSP עומד בדרישה הזו באמצעות הצגת סמל התראה מתמשכת בשורת הסטטוס.

התחלה של דרישות חדשות

• [C-SR-1] מומלץ מאוד להציג אזהרה למשתמש שהיא בדיוק אותה הודעה שמוטמעת ב-AOSP, אבל אפשר לשנות אותה כל עוד ההודעה מזהירה את המשתמש באופן ברור שהמידע הרגיש שמופיע במסך של המשתמש מתועד.

• [C-0-4] אסור לספק למשתמשים אפשרות להשבית הנחיות עתידיות המשתמש הסכים לצלם את המסך, אלא אם הסשן התחיל אפליקציית מערכת שהמשתמש אישר associate() עם android.app.role.COMPANION_DEVICE_APP_STREAMING או android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING פרופיל המכשיר

  סיום הדרישות החדשות

אם הטמעות של מכשירים כוללות פונקציונליות במערכת, מתעד את התוכן שמוצג במסך ו/או מקליט את שידור האודיו יופעלו במכשיר שלא באמצעות ה-System API ContentCaptureService, או אמצעים קנייניים אחרים שמתוארים בסעיף 9.8.6 נתוני אווירה וברמת מערכת ההפעלה, הן:

• [C-1-1] חייבת להיות התראה מתמשכת למשתמש בכל פעם מופעלת ומקליטה/להקליט באופן פעיל.

אם הטמעות המכשיר כוללות רכיב שמופעל מוכן לשימוש, יכול הקלטת צלילי אווירה ו/או הקלטה של האודיו שמופעל במכשיר כדי להסיק מידע מועיל על ההקשר של המשתמש, הם:

• [C-2-1] אסור לאחסן באחסון מתמיד במכשיר או לשדר את האודיו הגולמי שהוקלט או כל פורמט שניתן להמיר בחזרה את האודיו המקורי או קרוב אליו, אלא אם קיבלת הסכמה מפורשת מהמשתמש.

'אינדיקטור של מיקרופון' מתייחס לצפייה במסך שגלוי באופן קבוע למשתמש ולא ניתן לטשטש או להסתיר, כי המשתמשים מבינים כי נמצא בהם מיקרופון להשתמש בו(באמצעות טקסט, צבע, סמל או שילוב אחר).

'אינדיקטור מצלמה' מתייחס לתצוגה על המסך, שגלוית כל הזמן את המשתמש ולא ניתן לטשטש או להסתיר, כי המשתמשים מבינים כי המצלמה נמצאת בשימוש (באמצעות טקסט, צבע, סמל או שילוב אחר).

לאחר הצגת השנייה הראשונה, האינדיקטור יכול להשתנות באופן חזותי, כמו קטן יותר, ואין צורך להציג אותו כפי שהוצג במקור להבין.

יכול להיות שהאינדיקטור של המיקרופון ימוזג עם מצלמה שמוצגת באופן פעיל בתנאי שהטקסט, הסמלים או הצבעים מציינים למשתמש השימוש במיקרופון התחיל.

יכול להיות שהאינדיקטור של המצלמה ימוזג עם מיקרופון שמוצג באופן פעיל בתנאי שהטקסט, הסמלים או הצבעים מציינים למשתמש התחיל השימוש במצלמה.

אם הטמעות המכשירים מצהירות על android.hardware.microphone, הן:

• [C-SR-1] מומלץ מאוד להציג אינדיקטור של מיקרופון כשאפליקציה ניגש לנתוני אודיו מהמיקרופון, אבל לא כשהמיקרופון הגישה מתבצעת רק דרך HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService, או האפליקציות בעלות התפקידים שצוינו בסעיף 9.1 הרשאות עם מזהה CDD [C-3-X]. .
• [C-SR-2] מומלץ מאוד להציג את הרשימה של 'אחרונים' ו'פעילים' אפליקציות שמשתמשות במיקרופון כפי שהוחזר PermissionManager.getIndicatorAppOpUsageData(), יחד עם כל שיוך (Attribution) הודעות שמשויכות אליהם.
• [C-SR-3] מומלץ מאוד לא להסתיר את האינדיקטור של המיקרופון אפליקציות מערכת עם ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמשים.

אם הטמעות המכשירים מצהירות על android.hardware.camera.any, הן:

• [C-SR-4] מומלץ מאוד להציג אינדיקטור של המצלמה כשהאפליקציה גישה לנתוני המצלמה בשידור חי, אבל לא כשניגשים למצלמה בלבד על ידי אפליקציות בעלות התפקידים שצוינו בסעיף 9.1 הרשאות עם CDD מזהה [C-3-X].
• [C-SR-5] מומלץ מאוד להציג אפליקציות פעילות ואפליקציות מהזמן האחרון באמצעות מצלמה כפי שהוחזרה מ-PermissionManager.getIndicatorAppOpUsageData(), יחד עם הודעות השיוך (Attribution) שמשויכות אליהן.
• [C-SR-6] מומלץ מאוד לא להסתיר את האינדיקטור של המצלמה אפליקציות עם ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמשים.

9.8.3. קישוריות

אם בהטמעות המכשיר יש יציאת USB עם תמיכה במצב ציוד היקפי בחיבור USB. הם:

• [C-1-1] חובה להציג ממשק משתמש כדי לבקש את הסכמת המשתמש לפני מאפשרת גישה לתוכן האחסון המשותף דרך יציאת ה-USB.

9.8.4. תנועה ברשת

הטמעות מכשירים:

• [C-0-1] חובה להתקין מראש את אותם אישורי בסיס בשביל המערכת המהימנה אחסון של רשות האישורים (CA) כפי שסיפק בפרויקט קוד פתוח של Android ב-upstream.
• [C-0-2] חובה לשלוח את המוצר עם חנות בסיס ריקה של משתמש שמנפיקה את האישורים (CA).
• [C-0-3] חייבת להופיע אזהרה למשתמש שמציינת את התנועה ברשת עשוי להיות מנוטר, כשמוסיפים רשות אישורים ברמה הבסיסית של משתמש.

אם התנועה במכשירים מנותבת דרך VPN, הטמעות המכשירים:

• [C-1-1] חובה להציג למשתמש אזהרה שמציינת:
  • ייתכן שיש מעקב אחרי התנועה הזו ברשת.
  • התנועה ברשת הזו מנותבת דרך רשת ה-VPN הספציפית אפליקציה שמספקת את ה-VPN.

אם להטמעות של מכשירים יש מנגנון שמוגדר מחוץ לאריזה כברירת מחדל, מנתבת את תעבורת נתוני הרשת דרך שרת proxy או שער VPN (לדוגמה, טוענים מראש שירות VPN עם אישור android.permission.CONTROL_VPN), הם:

• [C-2-1] חובה לבקש את הסכמת המשתמש לפני הפעלת המנגנון הזה. אלא אם ה-VPN מופעל על ידי בקר מדיניות המכשיר דרך DevicePolicyManager.setAlwaysOnVpnPackage() , במקרה כזה המשתמש לא צריך לתת הסכמה נפרדת, אבל חובה לקבל הודעה בלבד.

אם הטמעות המכשירים מביאות בחשבון את היתרונות של המשתמשים כדי להפעיל "VPN שפועל כל הזמן" באפליקציית VPN של צד שלישי:

• [C-3-1] חובה להשבית את הקריטריונים של המשתמש הזה לאפליקציות שאינן תומכות שירות VPN שפועל כל הזמן בקובץ AndroidManifest.xml על ידי הגדרת SERVICE_META_DATA_SUPPORTS_ALWAYS_ON ל-false.

9.8.5. מזהי המכשיר

הטמעות מכשירים:

• [C-0-1] חובה למנוע גישה למספר הסידורי של המכשיר, וגם רלוונטי, IMEI/MEID, מספר סידורי של SIM ונייד בינלאומי זהות המנוי (IMSI) מאפליקציה, אלא אם היא עומדת באחד מהקריטריונים הבאים דרישות:
  • היא אפליקציית ספק חתומה שאומתה על ידי יצרני מכשירים.
  • קיבל את ההרשאה READ_PRIVILEGED_PHONE_STATE.
  • יש הרשאות ספק כפי שמוגדר בהרשאות ספק ב-UICC.
  • הוא בעל מכשיר או בעל פרופיל, שקיבלו את ההרשאה ההרשאה READ_PHONE_STATE.
  • (למספר הסידורי של כרטיס ה-SIM/ל-ICCID בלבד) יש את דרישת התקנות המקומיות שהאפליקציה מזהה שינויים בזהות של המנוי.

9.8.6. תיעוד תוכן וחיפוש אפליקציותנתוני אווירה ברמת מערכת ההפעלה

Android, באמצעות ממשקי ה-API של המערכת ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query או אחר אמצעים קנייניים, תומכים במנגנון וכדי לתעד את האינטראקציות הבאות של נתוני אפליקציות בין האפליקציות המשתמש מידע אישי רגיש:

• טקסט וגרפיקה שמופיעים במסך, כולל, בין היתר, התראות ונתוני סיוע דרך AssistStructure API.
• נתוני מדיה, כמו אודיו או וידאו, מוקלטים או מופעלים על ידי המכשיר.
• אירועי קלט (למשל מקש, עכבר, תנועה, קול, וידאו ונגישות).

התחלה של דרישות חדשות

• כל מסך או נתונים אחרים שנשלחים דרך AugmentedAutofillService אל המערכת.
• כל מסך או נתונים אחרים שניתן לגשת אליהם דרך Content Capture API.
• כל מסך או נתונים אחרים שניתן לגשת אליהם דרך API של FieldClassificationService
• כל נתוני האפליקציה שמועברים למערכת דרך API של AppSearchManager ונגיש דרך AppSearchGlobalManager.query.

סיום הדרישות החדשות

• כל אירוע אחר שאפליקציה מספקת למערכת דרך Content Capture או API של AppSearchManager, ל-Android עם יכולות דומות של ממשק ה-API הקנייניים.

• כל טקסט או נתונים אחרים שנשלחים דרך TextClassifier API ל-System TextClassifier, כלומר לשירות המערכת כדי להבין המשמעות של הטקסט, וגם יצירת פעולות חזויות הבאות על סמך של הטקסט.
• נתונים שנוספו לאינדקס על ידי ההטמעה של AppSearch, כולל, בין היתר מוגבלים לטקסט, גרפיקה, נתוני מדיה או נתונים דומים אחרים.

התחלה של דרישות חדשות

• נתוני אודיו שהושגו כתוצאה מהשימוש SpeechRecognizer#onDeviceSpeechRecognizer() באמצעות מזהה הדיבור הטמעה.
• נתוני אודיו שהתקבלו ברקע (באופן רציף) דרך AudioRecord, SoundTrigger או ממשקי API אחרים של אודיו, ושלא מובילים לתוצאה של אינדיקטור
• נתוני מצלמה שהתקבלו ברקע (באופן רציף) דרך CameraManager או ממשקי API אחרים של המצלמה, ללא אינדיקטור גלוי למשתמש

סיום הדרישות החדשות

אם הטמעות במכשירים מתעדים אחד או יותר מהנתונים שלמעלה, הן:

• [C-1-1] חובה להצפין את כל הנתונים האלה כשהם מאוחסנים במכשיר. הזה עשויה להתבצע באמצעות הצפנה המבוססת על קבצים ב-Android, או מהצופנים שרשומים כ-API בגרסה 26 ואילך שמתוארים ב-Cipher SDK.
• [C-1-2] אסור לגבות נתונים גולמיים או מוצפנים באמצעות שיטות גיבוי ל-Android או כל סוג אחר של גיבוי למעלה.
• [C-1-3] חובה לשלוח רק את כל הנתונים האלה ואת היומן באמצעות מנגנון לשמירה על הפרטיות, עם הסכמה מפורשת של המשתמש בכל פעם שהנתונים משותף. המנגנון לשמירה על הפרטיות מוגדרים בתור 'כלים שמאפשרים ניתוח מצטבר בלבד ומניעת התאמה של אירועים רשומים או תוצאות נגזרות למשתמשים נפרדים", כדי למנוע הצגה של נתונים לכל משתמש באופן פנימי (למשל, הטמעת נתונים טכנולוגיה דיפרנציאלית של פרטיות כמו RAPPOR).
• [C-1-4] אסור לשייך נתונים כאלה לזהות משתמש כלשהי ( בתור Account) במכשיר, אלא אם התקבלה הסכמה מפורשת מהמשתמש בכל פעם שהנתונים שמשויכים לכל אחד.
• [C-1-5] אסור לשתף נתונים כאלה עם רכיבי מערכת הפעלה אחרים שלא לפעול לפי הדרישות המפורטות בקטע הנוכחי (9.8.6 תיעוד תוכן ברמת ה-OS וברמת האווירה נתונים), אלא אם קיבלתם הסכמה מפורשת מהמשתמשים בכל פעם הזמן שבו הוא משותף. אלא אם פונקציונליות כזו שנוצר כ-Android SDK API (AmbientContext, HotwordDetectionService).
• [C-1-6] חובה לספק למשתמשים אפשרות למחוק נתונים כאלה ה ContentCaptureService הטמעה או אמצעים קנייניים נאספים if כאשר מאוחסנים במכשיר בכל צורה שהיא. אם המשתמש בוחר למחוק את הנתונים, חייב להסיר את כל הנתונים ההיסטוריים שנאספו .
• [C-1-7] חובה לספק למשתמש אפשרות לבטל את ההסכמה לשימוש בנתונים שנאספים באמצעות AppSearch או באמצעים קנייניים להצגה בפלטפורמת Android. לדוגמה במרכז האפליקציות.
• [C-SR-1] מומלץ מאוד לא לבקש את הרשאת האינטרנט.
• [C-SR-2] מומלץ מאוד לגשת לאינטרנט רק דרך ממשקי API מובנים המגובים על ידי הטמעות קוד פתוח שזמינות לציבור.

התחלה של דרישות חדשות

• [C-SR-4] מומלץ מאוד להטמיע אותן באמצעות Android SDK API או מאגר דומה של קוד פתוח בבעלות OEM (יצרן ציוד מקורי). ו / או לבצע הטמעה בארגז חול (ראו 9.8.15 הטמעות API בארגז חול).

סיום הדרישות החדשות

אם הטמעות המכשירים כוללות שירות שמטמיע את System API ContentCaptureService, AppSearchManager.index או כל שירות קנייני שלוכלת את הנתונים כפי שמתואר למעלה, היא:

• [C-2-1] אסור לאפשר למשתמשים להחליף את השירותים יישום או שירות שניתנים להתקנה על-ידי המשתמש, וחייבים לאפשר רק שהותקנו מראש כדי לתעד נתונים כאלה.
• [C-2-2] אסור להפעיל אפליקציות מלבד השירותים שהותקנו מראש כדי לאפשר תיעוד של נתונים כאלה.
• [C-2-3] חובה לספק למשתמשים אפשרות להשבית את השירותים כל הזמן.
• [C-2-4] אסור להשמיט את תקציב המשתמשים לניהול הרשאות ב-Android מוחזקים על ידי השירותים ופועלים לפי ההרשאות ב-Android כפי שמתואר בסעיף 9.1. הרשאה.

• [C-SR-3] מומלץ מאוד לשמור על הפרדה בין השירותים השונים רכיבי המערכת(למשל, לא מתבצע קישור של השירות או מזהים של תהליך השיתוף) חוץ מהדברים הבאים:

  • טלפוניה, אנשי קשר, ממשק משתמש של המערכת ומדיה

מערכת Android, דרך SpeechRecognizer#onDeviceSpeechRecognizer(), מאפשרת כדי לבצע זיהוי דיבור במכשיר ללא חיבור לרשת. כל הטמעה של SpeechRecognizer במכשיר חייבת לעמוד בכללי המדיניות שמפורטות בקטע הזה.

9.8.7. גישה ללוח

הטמעות מכשירים:

• [C-0-1] אסור להחזיר נתונים שנחתכו מהלוח (למשל דרך ClipboardManager API), אלא אם הצד השלישי הוא ה-IME שמוגדר כברירת מחדל, או שהאפליקציה שמתמקדת בה כרגע.

• [C-0-2] חובה לנקות נתונים מהלוח 60 דקות לכל היותר אחרי המועד האחרון להיות בלוח או לקרוא מלוח העריכה.

9.8.8. מיקום

המיקום כולל מידע בקטגוריית המיקום של Android( כגון קו רוחב, קו אורך, גובה), וכן מזהים שניתן להמיר למיקום. המיקום יכול להיות מדויק כמו DGPS (מערכת מיקום גלובלית דיפרנציאלית) או משוער כמיקומים ברמת המדינה (כגון מיקום קוד המדינה - חשבון ניהול - נייד קוד מדינה).

בהמשך מופיעה רשימה של סוגי מיקומים שנגזרים באופן ישיר או שניתן להמיר אותו למיקום של משתמש. זה לא מידע מקיף , אבל צריך לשמש כדוגמה לאופן שבו המיקום יכול באופן ישיר או נגזרות באופן עקיף מ:

• GPS/GNSS/DGPS/PPP
  • פתרון מיקום גלובלי או מערכת ניווט לוויינית גלובלית, או פתרון דיפרנציאלי למיקום גלובלי
  • זה כולל גם מדידות של GNSS גולמיות וסטטוס GNSS
    • ניתן לגזור את המיקום המדויק ממדידות GNSS גולמיות
• טכנולוגיות אלחוטיות עם מזהים ייחודיים כמו:
  • נקודות גישה של Wi-Fi (MAC , BSSID , שם או SSID)
  • Bluetooth/BLE (MAC, BSSID, שם או SSID)
  • UWB (MAC, BSSID, שם או SSID)
  • מזהה מגדל תקשורת (3G, 4G, 5G... כולל כל המודם הסלולרי בעתיד טכנולוגיות שיש להן מזהים ייחודיים)

למידע נוסף, כדאי לעיין בממשקי ה-API של Android שמחייבים הרשאות ACCESS_FINE_Location או ACCESS_COARSE_Location.

הטמעות מכשירים:

• [C-0-1] אסור להפעיל או להשבית את הגדרות המיקום של המכשיר ואת החיבור ל-Wi-Fi/Bluetooth של סריקת הגדרות ללא הסכמה מפורשת של המשתמש או יוזמת משתמש.
• [C-0-2] חייבת להיות למשתמשים אפשרות לגשת למיקום רלוונטי מידע כולל בקשות מיקום אחרונות, הרשאות ברמת האפליקציה ושימוש חיפוש נקודות Wi-Fi/Bluetooth לקביעת המיקום.
• [C-0-3] חובה לוודא שהאפליקציה משתמשת בממשק API של עקיפת מיקום במצב חירום [LocationRequest.setLocationSettingsignored()] הוא מצב חירום ביוזמת המשתמש (למשל, חייג 911 או טקסט ל-911). עם זאת, בכלי רכב עשויים להופיע להתחיל סשן חירום ללא אינטראקציה פעילה של המשתמש במקרה זוהתה תאונה/תאונה (למשל, כדי למלא את דרישות eCall).
• [C-0-4] חובה לשמר את היכולת של 'המעקף של מיקום החירום' לעקוף את הגדרות המיקום של המכשיר מבלי לשנות את ההגדרות.
• [C-0-5] חובה לתזמן התראה שתזכיר למשתמש אחרי שהאפליקציה נשלחה הרקע ניגש למיקום שלו באמצעות הרשאה [ACCESS_BACKGROUND_LOCATION].

9.8.9. אפליקציות מותקנות

אפליקציות ל-Android שמטרגטות לרמת API 30 ומעלה לא יכולות לראות פרטים על הגדרות אחרות אפליקציות מותקנות כברירת מחדל (מידע נוסף על הרשאות גישה לחבילה ב-Android מסמכי תיעוד בנושא SDK).

הטמעות מכשירים:

• [C-0-1] אסור לחשוף אפליקציות לאפליקציות שמטורגטות לרמת API 30 ומעלה על אפליקציות מותקנות אחרות, אלא אם האפליקציה כבר יכולה לראות את הפרטים על האפליקציה המותקנת האחרת באמצעות ממשקי ה-API המנוהלים. זה כולל אבל הוא לא מוגבל לפרטים שנחשפים על ידי ממשקי API מותאמים אישית שנוספו על ידי המכשיר. אחר, או לגשת אליו דרך מערכת הקבצים.
• [C-0-2] אסור לתת לאף אפליקציה גישת קריאה או כתיבה לקבצים הספרייה הייעודית שספציפית לאפליקציה של האפליקציה באחסון חיצוני. המקרים החריגים היחידים הם:
  • הרשות של ספק האחסון החיצוני (למשל, אפליקציות כמו DocumentsUI).
  • ספק הורדות שמשתמש בהרשאת הספק של 'הורדות' עבור מורידה קבצים לאחסון של האפליקציה.
  • אפליקציות של פרוטוקול העברת מדיה (MTP) בחתימת פלטפורמה שמשתמשות הרשאה בעלת הרשאות ACCESS_MTP כדי לאפשר העברת קבצים אל במכשיר אחר.
  • אפליקציות שמתקנות אפליקציות אחרות ושיש להן הרשאה INSTALL_PACKAGES יכולים לגשת רק לספריות "obb" לצורך ניהול קובצי הרחבת APK.

9.8.10. דוח על באג בקישוריות

אם בהטמעות המכשירים מוצהר על דגל התכונה android.hardware.telephony, הם:

• [C-1-1] חייבת להיות תמיכה ביצירת דוחות על באגים בקישוריות באמצעות BUGREPORT_MODE_TELEPHONY עם BugreportManager.
• [C-1-2] חובה לקבל הסכמה מהמשתמש בכל פעם ש-BUGREPORT_MODE_TELEPHONY ששימשו ליצירת דוח ואסור להם לבקש מהמשתמש להביע הסכמה בקשות עתידיות מהאפליקציה.
• [C-1-3] אסור להחזיר את הדוח שנוצר לאפליקציה שממנה נשלחה הבקשה את ההסכמה המפורשת של המשתמשים.
• [C-1-4] דוחות שנוצרו באמצעות BUGREPORT_MODE_TELEPHONY חייבים להכיל את הפרטים הבאים, לכל הפחות:
  • פלט של TelephonyDebugService
  • פלט של TelephonyRegistry
  • פלט של WifiService
  • פלט של ConnectivityService
  • קובץ dump של המכונה של CarrierService של חבילת השיחות (אם רלוונטי)
  • מאגר נתונים זמני של רדיו
  • קובץ dump של SubscriptionManagerService
• [C-1-5] אסור לכלול את הפרטים הבאים בדוחות שנוצרו:
  • כל סוג של מידע שלא קשור ישירות לקישוריות ניפוי באגים.
  • כל סוג של יומני תנועה של אפליקציות שהותקנו על ידי המשתמשים או פרופילים מפורטים של האפליקציות/החבילות שהותקנו על ידי המשתמשים (מזהי UID מותר, שמות החבילות הם לא).
• עשויים לכלול מידע נוסף שלא משויך לאף משתמש זהות. (למשל, יומנים של ספקים).

אם ההטמעות במכשירים כוללות מידע נוסף (למשל, יומני ספקים) דיווחים על באגים, והמידע הזה כולל פרטיות/אבטחה/סוללה/אחסון/זיכרון וכך:

• [C-SR-1] מומלץ מאוד להגדיר מפתח כברירת מחדל מושבת. יישום העזר של ה-AOSP תואם לכך על ידי מתן Enable verbose vendor logging אפשרות לכלול בהגדרות המפתח עוד יומני ספקים שספציפיים למכשיר בדוחות איתור באגים.

9.8.11. שיתוף blobs נתונים

Android, באמצעות BlobStoreManager מאפשרת לאפליקציות לתרום blobs של נתונים למערכת ולשתף אותם עם קבוצת אפליקציות.

אם בהטמעות במכשירים יש תמיכה ב-blobs משותפים של נתונים, כפי שמתואר מסמכי התיעוד של ה-SDK, הם:

• [C-1-1] אסור לשתף blobs של נתונים ששייכים לאפליקציות מעבר למה שהם נועד לאפשר (כלומר, היקף גישת ברירת המחדל והגישה האחרת מצבים שאפשר לציין באמצעות BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess(), או BlobStoreManager.session#allowPublicAccess() אין לשנות). הטמעת קובץ העזר של AOSP עומדת בדרישות הבאות: בדרישות שלנו.
• [C-1-2] אסור לשלוח את הגיבובים המאובטחים מהמכשיר או לשתף אותם עם אפליקציות אחרות של blobs של נתונים (המשמשים לשליטה בגישה).

9.8.12. זיהוי מוזיקה

Android, באמצעות System API MusicRecognitionManager, תומך במנגנון במכשירים שונים כדי לבקש זיהוי מוזיקה, בהינתן הקלטת אודיו, להאציל את זיהוי המוזיקה לאפליקציה בעלת הרשאות שמטמיעה את ממשק ה-API של MusicRecognitionService.

אם הטמעות המכשירים כוללות שירות שמטמיע את System API MusicRecognitionManager או כל שירות קנייני שמשדר נתוני אודיו בתור כמתואר לעיל, הן:

• [C-1-1] חובה לאכוף את הדרישה שהקוראים של MusicRecognitionManager מחזיקים את הרשאה מסוג MANAGE_MUSIC_RECOGNITION
• [C-1-2] חובה לאכוף זיהוי מוזיקה אחד שמותקן מראש מטמיעים את MusicRecognitionService.
• [C-1-3] אסור לאפשר למשתמשים להחליף את MusicRecognitionManagerService או MusicRecognitionService עם אפליקציה או שירות שניתנים להתקנה על ידי המשתמש.
• [C-1-4] חובה לוודא שכאשר MusicRecognitionManagerService ניגש אל הקלטת האודיו ומעבירה אותה לאפליקציה שבה מטמיעים MusicRecognitionService, המעקב אחרי הגישה לאודיו על ידי הפעלות של AppOpsManager.noteOp / startOp.

אם יישומים של MusicRecognitionManagerService או של המכשיר MusicRecognitionService מאחסן את כל נתוני האודיו שהוקלטו, למשל:

• [C-2-1] אסור לאחסן בדיסק טביעות אצבע של אודיו או אודיו גולמיים, או בזיכרון למשך יותר מ-14 יום.
• [C-2-2] אסור לשתף נתונים כאלה מעבר ל-MusicRecognitionService, למעט עם הסכמה מפורשת של המשתמש בכל פעם שהוא משותף.

9.8.13. מנהל הפרטיות של החיישנים

אם יישומים של מכשירים מאפשרים למשתמש להשבית את התוכנה בתשלום את קלט המצלמה או המיקרופון להטמעת המכשיר, הם:

• [C-1-1] חובה להחזיר את הערך 'true' באופן מדויק של התשובות הרלוונטיות supportsSensorToggle() שיטת ה-API.
• [C-1-2] חובה, כשאפליקציה מנסה לגשת למיקרופון או למצלמה חסומים, להציג למשתמש מחיר לא ניתן לביטול, שברור מציין שהחיישן חסום ודורש בחירה כדי להמשיך חסימה או ביטול חסימה, בהתאם להטמעה של ה-AOSP שעומדת לדרישה.
• [C-1-3] חובה להעביר לאפליקציות נתוני מצלמה ואודיו ריקים (או מזויפים) ולא לדווח על קוד שגיאה כי המשתמש לא מפעיל את המצלמה או מיקרופון באמצעות תקציב המשתמש שמוצג לפי [C-1-2] למעלה.

התחלה של דרישות חדשות

9.8.14. מנהל פרטי הכניסה

הנושא הוסר.

9.8.15. הטמעות 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 (למשל, לדיגיטל אפליקציות של Assistant).
• [C-0-6] אסור להפעיל אפליקציות מלבד השירותים שהותקנו מראש כדי לאפשר תיעוד של נתונים כאלה. אלא אם יכולת צילום כזו מוטמעות באמצעות API של Android SDK.
• [C-0-7] חובה לספק למשתמשים מספיק כסף כדי להשבית את השירותים.
• [C-0-8] אסור להשמיט את תקציב המשתמשים לניהול הרשאות ב-Android מוחזקים על ידי השירותים ופועלים לפי מודל ההרשאות של Android בתור מתואר ב: סעיף 9.1. הרשאה.

9.8.16. נתונים רציפים של אודיו ומצלמה

בנוסף לדרישות המפורטות בסעיף 9.8.2 הקלטה, 9.8.6 ברמת מערכת ההפעלה נתוני אווירה ו-9.8.15 הטמעות API בארגז חול, הטמעות שימוש בנתוני אודיו שהושגו ברקע (באופן רציף) דרך AudioRecord, SoundTrigger או ממשקי Audio API אחרים או נתוני מצלמה שהושגו ברקע (רציף) באמצעות CameraManager או ממשקי API אחרים של מצלמה:

• [C-0-1] חובה לאכוף את האינדיקטור התואם (מצלמה ו/או מיקרופון כמו בסעיף 9.8.2 הקלטה), אלא אם:
  • הגישה הזו מתבצעת בהטמעה של Sandbox (ראו 9.8.15 הטמעת API בארגז חול (Sandbox), באמצעות חבילה שכוללת רבים יותר מהתפקידים הבאים: System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence, או בינה חזותית של המערכת.
  • הגישה מתבצעת דרך Sandbox, מוטמעת שנאכפים באמצעות מנגנונים ב-AOSP (HotwordDetectionService, WearableSensingService, VisualQueryDetector).
  • הגישה לאודיו מתבצעת למטרות סיוע אפליקציית Assistant שמספקת את SOURCE_HOTWORD כמקור אודיו.
  • הגישה מבוצעת על ידי המערכת ומוטמעת באמצעות בקוד פתוח.
• [C-SR-1] מומלץ מאוד לדרוש הסכמה מהמשתמש בכל פונקציונליות שמשתמשת בנתונים כאלה, והיא מושבתת כברירת מחדל.
• [C-SR-2] מומלץ מאוד ליישם את אותו טיפול (כלומר, לפעול לפי ההגבלות המפורטות בסעיף 9.8.2 הקלטה, 9.8.6 נתוני אווירה ונתוני מערכת הפעלה, 9.8.15 הטמעות API בארגז חול ו-9.8.16 אודיו ומצלמה רציפים נתונים) לנתוני המצלמה שמגיעים ממכשיר לביש מרוחק.

אם נתוני המצלמה סופקו ממכשיר לביש מרחוק ובוצעה גישה אליהם בצורה לא מוצפנת מחוץ ל-Android OS, יישום בארגז חול (sandboxing) או שימוש בארגז חול (sandboxing) פונקציונליות שפותחה על ידי WearableSensingManager, ואז:

• [C-1-1] חובה לציין במכשיר הלביש בשלט הרחוק כדי להציג שם אינדיקטור נוסף.

אם המכשירים מספקים אפשרות לאינטראקציה עם אפליקציה של העוזר הדיגיטלי ללא מילת המפתח שהוקצתה (טיפול בשאילתות משתמש כלליות או ניתוח נוכחות משתמש דרך המצלמה):

• [C-2-1] חובה לוודא שהטמעה כזו מסופקת על ידי חבילה שכוללת את תפקיד android.app.role.ASSISTANT.
• [C-2-2] חובה לוודא שבמסגרת הטמעה כזו ייעשה שימוש בכתובת HotwordDetectionService ו/או VisualQueryDetectionService ממשקי API של Android.

9.8.17. Telemetry

יומני המערכת והאפליקציות מאוחסנים ב-Android באמצעות ממשקי API שלStatLog. היומנים האלה מנוהלים דרך ממשקי API של StatusManager, שבהם יכולים להשתמש אפליקציות מערכת בעלות הרשאות.

DataManager מספק גם דרך לאסוף נתונים שמסווגים כפרטיות רגישים ממכשירים עם מנגנון לשמירה על הפרטיות. באופן ספציפי, ה-API של StatsManager::query מאפשר לשלוח שאילתות על מדד מוגבל קטגוריות מוגדרות ב-StatsLog.

כל תהליך הטמעה ששולח שאילתות ואוסף מדדים מוגבלים מ- StatusManager:

• [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.9. הצפנה של מאגר הנתונים

כל המכשירים חייבים לעמוד בדרישות של סעיף 9.9.1. מכשירים שהופעלו ברמת API מוקדמת יותר מזו של המסמך הזה פטור מהדרישות של הסעיפים 9.9.2 ו-9.9.3; במקום זאת, חייב לעמוד בדרישות המפורטות בסעיף 9.9 של תאימות Android מסמך הגדרה שתואם לרמת ה-API שבה המכשיר הושק.

9.9.1. הפעלה ישירה

הטמעות מכשירים:

• [C-0-1] חובה להטמיע את ממשקי ה-API של מצב הפעלה ישירה גם אם הם לא תומכים בהצפנת אחסון.

• [C-0-2] ACTION_LOCKED_BOOT_COMPLETED ו-ACTION_USER_UNLOCKED עדיין חייבים לשדר אובייקטים מסוג Intent כדי לאותת לאפליקציות שמודעות להפעלה ישירה מיקומי האחסון בהצפנת מכשיר (DE) ובהצפנת פרטי כניסה (CE) הם זמין למשתמש.

9.9.2. דרישות לגבי הצפנה

הטמעות מכשירים:

• [C-0-1] חובה להצפין את האפליקציה באופן פרטי נתונים (מחיצה /data), וגם מחיצת האחסון המשותף של האפליקציה (מחיצה /sdcard) אם זה חלק קבוע שלא ניתן להסרה מהמכשיר.
• [C-0-2] חובה להפעיל את הצפנת אחסון הנתונים כברירת מחדל המשתמש השלים את תהליך ההגדרה הראשוני.

• [C-0-3] חייב לעמוד בדרישות להצפנת אחסון הנתונים שצוינה למעלה על ידי יישום אחת משתי שיטות ההצפנה הבאות:

  • הצפנה מבוססת קבצים (FBE) הצפנת מטא-נתונים כמתואר בסעיף 9.9.3.1.
  • הצפנה לפי משתמש ברמת בלוקים, כפי שמתואר בסעיף 9.9.3.2.

הערה: הטמעות של מכשירים שנשלחו ברמת API 28 ומטה לא לעמוד בדרישות שבגרסה 9.9.2 באמצעות עדכון תוכנת מערכת חייב לעמוד בדרישות הדרישות בסעיף 9.9 של מסמך הגדרת התאימות ל-Android שתואם לרמת ה-API שאליה המכשיר נשלח.

9.9.3. שיטות הצפנה

אם הטמעות המכשירים מוצפנות, הן:

• [C-1-1] חובה להפעיל את המכשיר בלי לאתגר את המשתמש להזין פרטי כניסה אישור לגשת לאחסון המוצפן במכשיר (DE) אחרי שידור ההודעה ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] חובה לאפשר גישה לאחסון עם הצפנה באמצעות פרטי כניסה (CE) רק לאחר המשתמש ביטל את נעילת המכשיר על ידי אספקת פרטי הכניסה שלו (למשל, קוד גישה, קוד אימות, קו ביטול נעילה או טביעת אצבע) וגם ACTION_USER_UNLOCKED ההודעה משודרת.
• [C-1-13] אסור להציע שיטה כלשהי לביטול נעילת האחסון המוגן באמצעות CE ללא פרטי הכניסה שסופקו על ידי המשתמש, מפתח נאמנות רשום או להמשיך בהטמעה של ההפעלה מחדש שעומדת בדרישות סעיף 9.9.4.
• [C-1-4] חובה להשתמש ב'הפעלה מאומתת'.

9.9.3.1. הצפנה מבוססת קבצים עם הצפנת מטא-נתונים

אם בהטמעות במכשירים נעשה שימוש בהצפנה מבוססת קבצים עם הצפנת מטא-נתונים, הם:

• [C-1-5] חובה להצפין את תוכן הקבצים והמטא-נתונים של מערכת הקבצים באמצעות AES-256-XTS או Adiantum. AES-256-XTS מתייחס לתקן ההצפנה המתקדם עם אורך מפתח הצפנה של 256 ביט, שמופעל במצב XTS. לכל אורך המפתח הוא 512 ביטים. Adiantum מתייחס ל-Adiantum-XChaCha12-AES, כפי שמצוין ב- https://github.com/google/adiantum. מטא-נתונים של מערכת קבצים הם נתונים כמו קובץ גדלים, בעלות, מצבים ומאפיינים מורחבים (xattrs).
• [C-1-6] חובה להצפין את שמות הקבצים באמצעות AES-256-CBC-CTS, AES-256-HCTR2, או Adiantum.
• [C-1-12] אם במכשיר יש תקן הצפנה מתקדם (AES) הוראות (כגון תוספי ARMv8 Cryptography במכשירים מבוססי ARM, או AES-NI במכשירים מבוססי x86) ואז באפשרויות שמבוססות על AES למעלה לגבי שם הקובץ. חייבים להשתמש בתוכן של הקבצים ובהצפנת המטא-נתונים של מערכת הקבצים, ולא ב-Adiantum.
• [C-1-13] חובה להשתמש במפתח קריפטוגרפי חזק ולא הפיך פונקציית נגזרת (למשל HKDF-SHA512) כדי להפיק מפתחות משנה נדרשים (למשל לכל קובץ) ממפתחות CE ו-DE. "קריפטוגרפיה חזקה בלתי הפיך" הוא שלפונקציית הנגזרת של המפתח יש חוזק אבטחה של 256 סיביות לפחות ומתנהגת כפונקציה אקראית משפחה מעל מקורות הקלט שלו.
• [C-1-14] אסור להשתמש באותם מפתחות או מפתחות משנה של הצפנה מבוססת-קבצים (FBE) למטרות קריפטוגרפיות שונות (למשל, גם להצפנה וגם למפתח נגזרת נגזרת או לשני אלגוריתמים של הצפנה שונים).
• [C-1-15] חובה לוודא שכל הבלוקים של תוכן קובץ מוצפן שלא נמחקו. באחסון מתמיד הוצפנו באמצעות שילובים של מפתח הצפנה וקטור אתחול (IV) שתלוי גם בקובץ וגם בהיסט בתוך הקובץ את הקובץ. בנוסף, כל השילובים הללו חייבים להיות נפרדים, למעט כאשר ההצפנה מתבצעת באמצעות חומרת הצפנה מוטבעת שתומכת רק אורך IV של 32 ביטים.
• [C-1-16] חובה לוודא שכל שמות הקבצים המוצפנים שלא נמחקו באופן קבוע האחסון בספריות נפרדות הוצפנו באמצעות שילובים נפרדים של מפתח הצפנה וקטור אתחול (IV).

• [C-1-17] חובה לוודא שכל המטא-נתונים של מערכת הקבצים המוצפנים חסומים האחסון המתמיד הוצפן באמצעות שילובים ייחודיים של מפתח הצפנה ואת הווקטור של האתחול (IV).

• מפתחות שמגינים על אזורי האחסון של CE ו-DE ועל המטא-נתונים של מערכת הקבצים:

  • [C-1-7] חייב להיות קשור לקריפטוגרפיה ל-Keystore שמגובה על ידי חומרה. מאגר המפתחות הזה חייב להיות מקושר ל'הפעלה מאומתת' ולחומרת המכשיר Root of Trust.
  • [C-1-8] מפתחות CE חייבים להיות כפופים לפרטי הכניסה של המשתמש במסך הנעילה.
  • [C-1-9] מפתחות CE חייבים להיות מקושרים לקוד סיסמה בברירת מחדל כשהמשתמש לא צוינו פרטי כניסה למסך הנעילה.
  • [C-1-10] חייב להיות ייחודי וייחודי. במילים אחרות, אין צורך ב-CE או ב-DE על ידי המשתמשים. תואם למפתחות CE או DE של משתמש אחר.
  • [C-1-11] חובה להשתמש בהצפנה שנתמכת על ידי המנדטוריות, באורכי המפתחות במצב תצוגה מותאם.
  • [C-1-12] חובה למחוק באופן מאובטח במהלך ביטול הנעילה והנעילה של תוכנת האתחול כפי שמתואר כאן.

• צריך להתקין אפליקציות חיוניות שהותקנו מראש (למשל, אזעקה, טלפון, Messenger) מודעוּת להפעלה ישירה.

פרויקט הקוד הפתוח של Android ב-upstream מספק הטמעה מועדפת של הצפנה מבוססת קבצים על סמך ליבה (kernel) של Linux "fscrypt" תכונת הצפנה, ועל הצפנת מטא-נתונים על סמך ליבה (kernel) של Linux "dm-default-key" .

הערה: הטמעות של מכשירים שנשלחו ברמת API 28 או גרסאות קודמות, לא לעמוד בדרישות שבגרסה 9.9.3 באמצעות עדכון תוכנת מערכת חייב לעמוד בדרישות הדרישות בסעיף 9.9 של מסמך הגדרת התאימות ל-Android שתואם לרמת ה-API שאליה המכשיר נשלח.

9.9.3.2. הצפנה ברמת בלוקים עבור משתמש

אם בהטמעות במכשירים נעשה שימוש בהצפנה ברמת הבלוקים לכל משתמש, הן:

• [C-1-1] חובה להפעיל תמיכה במשתמשים מרובים כפי שמתואר בסעיף 9.5.
• [C-1-2] חובה לספק מחיצות לכל משתמש, באמצעות מחיצות גולמיות או בנפחים לוגיים.
• [C-1-3] חובה להשתמש במפתחות הצפנה ייחודיים וייחודיים לכל משתמש לצורך של המכשירים החסומים הבסיסיים.

• [C-1-4] חובה להשתמש ב-AES-256-XTS להצפנה ברמת הבלוק של המשתמש מחיצות.

• המפתחות שמגינים על המכשירים המוצפנים ברמת הבלוק לכל משתמש:

  • [C-1-5] חייב להיות קשור באופן קריפטוגרפי ל-Keystore שמגובה על ידי חומרה. מאגר המפתחות הזה חייב להיות מקושר ל'הפעלה מאומתת' ולחומרת המכשיר Root of Trust.
  • [C-1-6] חייבים להיות כפופים למסך הנעילה של המשתמש המתאים פרטי הכניסה.

ניתן להטמיע הצפנה ברמת הבלוק לפי משתמש באמצעות הליבה של Linux 'dm-crypt' על פני מחיצות לכל משתמש.

9.9.4. המשך לאחר ההפעלה מחדש

האפשרות 'המשך ההפעלה מחדש' מאפשרת לבטל את הנעילה של אחסון CE של כל האפליקציות, כולל אלה שעדיין לא תומכות בהפעלה ישירה, לאחר הפעלה מחדש שהופעלה על ידי OTA. הזה מאפשרת למשתמשים לקבל התראות מאפליקציות מותקנות לאחר להפעיל מחדש.

הטמעה של 'המשך הפעלה מחדש' חייבת להמשיך להבטיח שכאשר המכשיר נופל לידיים של תוקף, קשה מאוד לעשות זאת תוקף כדי לשחזר נתונים בהצפנת CE של המשתמש, גם אם המכשיר מופעל מופעל, אחסון CE אינו נעול והמשתמש ביטל את נעילת המכשיר לאחר קבלת OTA. להתנגדות למתקפות מבפנים, אנחנו גם מניחים שהתוקף מקבל גישה לשידור מפתחות חתימה קריפטוגרפיים.

פרטים נוספים:

• [C-0-1] אחסון ל-CE אסור לקריאה גם עבור התוקף, במכשיר ולאחר מכן יש לו את היכולות והמגבלות הבאות:

  • יכול להשתמש במפתח החתימה של כל ספק או חברה כדי לחתום על שרירות הודעות.
  • עלול לגרום לקבלת OTA במכשיר.
  • ניתן לשנות את הפעולה של כל חומרה (AP, Flash וכו') מלבד אבל שינוי כזה כרוך בעיכוב של לפחות שעה ומחזור עוצמה שהרוס את התוכן של ה-RAM.
  • לא ניתן לשנות את הפעולה של חומרה עמידה בפני שינויים (לדוגמה, Titan M).
  • לא ניתן לקרוא את זיכרון ה-RAM של המכשיר בשידור חי.
  • לא ניתן לקבל את פרטי הכניסה של המשתמש (קוד אימות, קו ביטול נעילה, סיסמה) או אחרת כדי לגרום לו להזין אותו.

לדוגמה, הטמעה של מכשיר שמטמיעה את כל מהתיאורים שמופיעים כאן לעמוד בדרישות של [C-0-1].

9.10. תקינות המכשיר

הדרישות הבאות מבטיחות שקיפות לגבי הסטטוס של תקינות המכשיר. הטמעות מכשירים:

• [C-0-1] חובה לדווח בצורה נכונה באמצעות method API PersistentDataBlockManager.getFlashLockState() מציין אם תוכנת האתחול מאפשר להבהב של תמונת המערכת.

• [C-0-2] חייבת להיות תמיכה ב'הפעלה מאומתת' לשמירה על תקינות המכשיר.

אם הטמעות המכשיר כבר הופעלו ללא תמיכה ב'הפעלה מאומתת' בגרסה קודמת של Android ולא ניתן להוסיף תמיכה באפשרות הזו עם עדכון תוכנת מערכת, ייתכן שהם יהיו פטורים לדרישה.

'הפעלה מאומתת' היא תכונה שמבטיחה את תקינות המכשיר תוכנה. אם הטמעות במכשירים תומכים בתכונה הזו:

• [C-1-1] חובה להצהיר על תכונות הדגל של הפלטפורמה android.software.verified_boot
• [C-1-2] חובה לבצע אימות בכל רצף אתחול.
• [C-1-3] חובה להתחיל את האימות ממפתח חומרה שלא ניתן לשינוי Root of Trust והמשך עד למחיצת המערכת.
• [C-1-4] חובה להטמיע כל שלב אימות כדי לבדוק את התקינות והאותנטיות של כל הבייטים בשלב הבא לפני הרצת הקוד השלב הבא.
• [C-1-5] חובה להשתמש באלגוריתמים של האימות חזקים כמו הנוכחיים המלצות מ-NIST לאלגוריתמים לגיבוב (SHA-256) ולמפתח ציבורי גדלים (RSA-2048).
• [C-1-6] אסור לאפשר לאתחול להשלים כשאימות המערכת נכשל, אלא אם המשתמש הסכים לנסות לאתחל בכל זאת. במקרה כזה, הנתונים אין להשתמש בבלוקים לא מאומתים של אחסון.
• [C-1-7] אסור לאפשר שינוי של מחיצות מאומתות במכשיר אלא אם המשתמש ביטל את הנעילה של תוכנת האתחול באופן מפורש.
• [C-SR-1] אם יש מספר צ'יפים נפרדים במכשיר (למשל רדיו, מעבד תמונות מיוחד), תהליך האתחול של כל אחד מהצ'יפים האלה מומלץ מאוד לאמת כל שלב לאחר ההפעלה.
• [C-1-8] חובה להשתמש באחסון מסוג tamper-evident: לאחסון תוכנת האתחול לא נעולה. כלומר, תוכנת האתחול יכולה לזהות אם מישהו חיבל באחסון מתוך Android.
• [C-1-9] חובה להציג הודעה למשתמש בזמן השימוש במכשיר. דרישה לאישור פיזי לפני מתן הרשאה למעבר מתוכנת האתחול ממצב נעילה למצב ביטול נעילה של תוכנת האתחול.
• [C-1-10] חובה להטמיע הגנה מפני החזרה למחיצות ב-Android (לדוגמה, אתחול, מחיצות מערכת) ושימוש באחסון מפני זיוף לצורך אחסון מטא-נתונים המשמשים לקביעת הגרסה המינימלית של מערכת ההפעלה המותרת.
• [C-1-11] חובה למחוק באופן מאובטח את כל נתוני המשתמשים במהלך ביטול הנעילה של תוכנת האתחול וגם נעול, בהתאם ל-'9.12'. מחיקת נתונים' (כולל המחיצה של נתוני המשתמש כל רווח של NVRAM).
• [C-SR-2] מומלץ מאוד לאמת את כל קובצי ה-APK של האפליקציות בעלי הרשאות באמצעות שרשרת של אמון שמופעלת במחיצות שמוגנות באמצעות אתחול מאומת.
• [C-SR-3] מומלץ מאוד לאמת פריטי מידע שנוצרו בתהליך הפעלה (Artifact) שנטענו על ידי לאפליקציה בעלת הרשאות מחוץ לקובץ ה-APK שלה (כגון קוד שנטען באופן דינמי או שעבר הידור) לפני הביצוע שלהם, או מומלץ מאוד לא לבצע אותם בכלל.
• צריכה להטמיע הגנה מפני החזרה למצב קודם עבור כל רכיב עם הגדרה קבועה קושחה (לדוגמה, מודם, מצלמה) ויש להשתמש באחסון מפני התעסקות אחסון המטא-נתונים המשמשים לקביעת הגרסה המינימלית המותרת.

אם הטמעות המכשיר כבר הושקו ללא תמיכה ב-C-1-8 עד C-1-11 בגרסה קודמת של Android ולא יכול להוסיף תמיכה עבור מדרישות אלה באמצעות עדכון תוכנת מערכת, ייתכן שהן יהיו פטורות בדרישות שלנו.

פרויקט הקוד הפתוח של Android ב-upstream מספק הטמעה מועדפת של בתכונה הזו בexternal/avb/ שחייב להיות משולב בתוכנת האתחול שמשמשת לטעינה Android.

הטמעות מכשירים

אם בהטמעות במכשירים יש אפשרות לאמת קובץ תוכן לכל דף, ואז:

• [C-0-3 תמיכה ב-C-2-1] אימות קריפטוגרפי של תוכן קובץ מול מפתח מהימן בלי לקרוא את כל הקובץ.

• [C-0-4 C-2-2] אסור לאפשר לקרוא בקשות בקובץ מוגן כדי להצליח כשהתוכן שנקרא לא לבצע אימות מול מפתח מהימן לא מאומת בכל [C-2-1] למעלה.

התחלה של דרישות חדשות

• [C-2-4] חובה להחזיר סיכום ביקורת (checksum) של קובץ ב-O(1) לקבצים שהופעלו.

סיום הדרישות החדשות

אם הטמעות המכשיר כבר הופעלו ללא אפשרות לבצע אימות לשלוח תוכן למפתח מהימן בגרסה קודמת של Android, ולא ניתן להוסיף אותו תמיכה בתכונה הזו עם עדכון תוכנת המערכת, יכול להיות שהן יהיו פטורות מהדרישה. פרויקט הקוד הפתוח של Android ב-upstream מספק את ההטמעה המועדפת של התכונה הזו על סמך תכונת fs-verity הליבה של Linux.

הטמעות מכשירים:

• [C-SR-4] אנחנו ממליצים מאוד לתמוך ב-Android Protected Verification API.

אם יישומי המכשיר תומכים ב'אישור מוגן של Android' הם:

• [C-3-1] חובה לדווח על true עבור ConfirmationPrompt.isSupported() API.

• [C-3-2] חובה לוודא שהקוד שפועל במערכת Android כולל ליבה, זדונית או אחרת, לא יכולה ליצור תשובה חיובית ללא לאינטראקציה של המשתמשים.

• [C-3-3] חובה לוודא שהמשתמש יכול לבדוק ולאשר את גם אם מערכת ההפעלה Android, כולל הליבה שלה, בסיכון.

9.11. מפתחות ופרטי כניסה

מערכת Android Keystore מאפשרת למפתחי אפליקציות לאחסן מפתחות קריפטוגרפיים בקונטיינר ולהשתמש בהם פעולות קריפטוגרפיות באמצעות KeyChain API או Keystore API. הטמעות מכשירים:

• [C-0-1] חובה לאפשר ייבוא או יצירה של לפחות 8,192 מפתחות.
• [C-0-2] חובה להטמיע מרווח זמן באימות של מסך הנעילה בין ניסיונות כושלים. כאשר n הוא מספר הניסיונות הכושלים, השעה המרווח חייב להיות 30 שניות לפחות למשך 9 < n < 30. עבור n > 29, the הערך של מרווח הזמן חייב להיות לפחות 30*2^floor(n-30)/10)) שניות, או לפחות 24 שעות, המוקדם מביניהם.
• אסור להגביל את מספר המפתחות שאפשר ליצור

התחלה של דרישות חדשות

• [C-0-3] חובה להגביל את מספר ניסיונות האימות הראשי שנכשלו.
• [C-SR-2] מומלץ מאוד להגיע לגבול עליון של 20 פעמים ניסיונות אימות ראשי, ואם המשתמשים מביעים הסכמה ומביעים הסכמה לבצע 'איפוס לנתוני היצרן', לאחר חריגה מהמגבלה של ניסיונות אימות ראשי.

אם הטמעות במכשירים מוסיפות או משנות את שיטות האימות כדי לבטל את הנעילה של לנעול את המסך אם הוא מבוסס על סוד ידוע ולהשתמש בשיטת אימות חדשה כדי שיטה מאובטחת לנעילת המסך, ואז:

• [C-SR-3] מומלץ מאוד להזין קוד אימות באורך 6 ספרות לפחות, או שווה ערך לאנטרופיה של 20 ביט.
• [C-2-1] אסור להזין באופן אוטומטי קוד אימות באורך של פחות מ-6 ספרות ללא אינטראקציה של המשתמש, כדי למנוע חשיפה של אורך קוד האימות.

סיום הדרישות החדשות

כשהטמעת המכשיר תומכת במסך נעילה מאובטח, הוא:

• [C-1-1] חייבים לגבות את ההטמעה של מאגר המפתחות באמצעות בסביבת הביצוע.
• [C-1-2] חייבות להיות הטמעות של RSA, AES, ECDSA ECDH (אם יש תמיכה ב-IKeyMintDevice), 3DES, וגם אלגוריתמים קריפטוגרפיים HMAC ו-MD5, SHA1 ו-SHA-2 כדי לתמוך באופן תקין בתכונות הנתמכות של מערכת Android Keystore באזור המבודד באופן מאובטח מהקוד שפועל הליבה (kernel) ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים קוד ליבה או מרחב משתמש שיכול לגשת למצב הפנימי של בסביבה מבודדת, כולל DMA. קוד פתוח של Android ב-upstream פרויקט (AOSP) עומד בדרישה הזו באמצעות הטמעה נמוכה, אבל פתרון אחר מבוסס ARM TrustZone או פתרון מאובטח על ידי צד שלישי או להטמיע בידוד מתאים שמבוסס על hypervisor אפשרויות.
• [C-1-3] חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע ורק כאשר הפעולה מצליחה, לאפשר את לשימושיות. יש לאחסן את פרטי הכניסה של מסך הנעילה במסגרת שמאפשרת רק לסביבת הביצוע המבודדת לבצע את מסך הנעילה אימות. פרויקט הקוד הפתוח של Android ב-upstream מספק Gatekeeper Hardware Layer Abstraction Layer (HAL) ו-Trusty, שיכולים לשמש כדי למלא את הדרישה הזו.
• [C-1-4] חייבת להיות תמיכה באימות עם מפתחות כאשר חתימת האימות מוגן באמצעות חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות חתימת האימות עם מספר גדול מספיק של כדי למנוע שימוש במפתחות כמזהי מכשיר. כיוון אחד לעמוד בדרישה הזו, לשתף את אותו מפתח אימות, אלא אם נוצרות לפחות 100,000 יחידות של מק"ט נתון. אם יותר מ-100,000 יחידות של מק"ט, יכול להיות שייעשה שימוש במפתח שונה לכל 100,000 יחידות.

חשוב לשים לב: אם ההטמעה של המכשיר כבר הופעלה בגרסה קודמת של Android גרסה מסוימת, מכשיר כזה פטור מהדרישה לקיום מאגר מפתחות. שמגובות בסביבת הפעלה מבודדת ותומכת באימות (attestation) של המפתח, אלא אם מוצהר על התכונה android.hardware.fingerprint שדורשת מאגר מפתחות שמגובה על ידי סביבת הפעלה מבודדת.

• [C-1-5] חובה לאפשר למשתמש לבחור את הזמן הקצוב לתפוגה של מצב שינה לצורך מעבר פתוח למצב נעול, עם זמן קצוב מינימלי ככל האפשר עד 15 שניות. מכשירים בכלי רכב, שנועלים את המסך בכל פעם שהיחידה הראשית מושבת או שהמשתמש מוחלף, יכול להיות שהזמן הקצוב לתפוגה של שינה לא מוגבל הגדרה אישית.
• [C-1-6] חייבת לתמוך באחת מהאפשרויות הבאות:
  • IKeymasterDevice 3.0,
  • IKeymasterDevice 4.0,
  • IKeymasterDevice 4.1,
  • IKeyMintDevice בגרסה 1, או
  • IKeyMintDevice גרסה 2.
• [C-SR-1] מומלץ מאוד לתמוך ב-IKeyMintDevice בגרסה 1.

9.11.1. מסך נעילה מאובטח, אימות ומכשירים וירטואליים

הטמעת AOSP מבוססת על מודל אימות רב-שכבתי שבו אימות ראשי המבוסס על מפעל ידע יכול לגבות ביומטרי משני חזק או נתונים שלישוניים חלשים יותר.

הטמעות מכשירים:

• [C-SR-1] מומלץ מאוד להגדיר רק אחד מהערכים הבאים כאימות הראשי method:

  • קוד אימות מספרי
  • סיסמה אלפאנומרית

  • תבנית החלקה על גבי רשת של 3x3 נקודות בדיוק

    חשוב לשים לב ששיטות האימות שצוינו למעלה הן השיטות המומלצות שיטות האימות הראשיות במסמך הזה.

התחלה של דרישות חדשות

• [C-0-1] חובה להגביל את מספר ניסיונות האימות הראשי שנכשלו.
• [C-SR-5] מומלץ מאוד להגיע לגבול עליון של 20 פעמים ניסיונות אימות ראשי, ואם המשתמשים מביעים הסכמה לשימוש בתכונה ומביעים הסכמה לשימוש בה, לבצע 'איפוס לנתוני היצרן'. אחרי שחרגת מהמגבלה של בקשות ראשוניות שנכשלו ניסיונות אימות.

אם בהטמעות המכשיר מוגדר קוד אימות מספרי כקוד הראשי המומלץ שיטת אימות, אז:

• [C-SR-6] מומלץ מאוד להזין קוד אימות באורך 6 ספרות לפחות, או שווה ערך לאנטרופיה של 20 ביט.
• [C-SR-7] מומלץ מאוד לא להשתמש בקוד אימות באורך של פחות מ-6 ספרות כדי לאפשר כניסה אוטומטית ללא אינטראקציה של המשתמש, כדי למנוע חשיפה של קוד האימות האורך.

סיום הדרישות החדשות

אם הטמעות המכשיר מוסיפות או משנות את האימות הראשי המומלץ ולהשתמש בשיטת אימות חדשה כדרך מאובטחת לנעילת המסך, שיטת האימות החדשה:

• [C-2-1] חייבת להיות שיטת אימות המשתמש כפי שמתואר ב דרישת אימות משתמש לשימוש במפתחות.

אם הטמעות במכשירים מוסיפים או משנים את שיטות האימות לביטול הנעילה במסך הנעילה אם הוא מבוסס על סוד ידוע ומשתמשים באימות חדש ולכן יטופל כדרך מאובטחת לנעילת המסך:

• [C-3-1] האנטרופיה של אורך הקלט הקצר ביותר המותר חייבת להיות מ-10 סיביות.
• [C-3-2] האנטרופיה המקסימלית של כל ערכי הקלט האפשריים חייבת להיות גדולה מ- 18 סיביות.
• [C-3-3] שיטת האימות החדשה לא יכולה להחליף אף אחד שיטות האימות הראשיות המומלצות (למשל, קוד אימות, קו ביטול נעילה, סיסמה) הטמענו וסופקו ב-AOSP.
• [C-3-4] שיטת האימות החדשה חייבת להיות מושבתת כאשר האפליקציה Device Policy Controller (DPC) הגדירה את הסיסמה מדיניות הדרישות באמצעות DevicePolicyManager.setrequiredPasswordComplexity() שהמורכבות שלהן מגבילה יותר מ- password_COMPLExitY_NONE או באמצעות הפונקציה DevicePolicyManager.setPassword Quality() עם קבוע מגביל יותר password_QUALITY_BIOMETRIC_WEAK.
• [C-3-5] שיטות אימות חדשות חייבות לחזור שיטות מומלצות לאימות ראשי (למשל קוד אימות, קו ביטול נעילה, אחת ל-72 שעות או פחות) או לחשוף בבירור משתמש שחלק מהנתונים לא יגובו כדי לשמר לשמור על פרטיות הנתונים שלהם.

אם הטמעות המכשיר מוסיפות או משנות את האימות הראשי המומלץ שיטות לביטול נעילת מסך הנעילה ושימוש בשיטת אימות חדשה על סמך מידע ביומטרי יטופל כדרך מאובטחת לנעילת המסך, method:

• [C-4-1] חייב לעמוד בכל הדרישות המתוארות בסעיף 7.3.10 לרמה 1 (לשעבר) נוחות).
• [C-4-2] חייב להיות מנגנון של חזרה למצב הקודם כדי להשתמש באחד מהערכים המומלצים שיטות אימות ראשיות שמבוססות על סוד ידוע.
• [C-4-3] חובה להשבית ולהפעיל רק את השיטה הראשית המומלצת אימות לביטול נעילת המסך כשהבקר לניהול מדיניות המכשירים (DPC) האפליקציה הגדיר/ה את מדיניות התכונה של מגן המקשים על ידי קריאה ל-method DevicePolicyManager.setKeyguardDisabledFeatures() , עם אחד מהדגלים הביומטריים המשויכים אליו (כלומר KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE או KEYGUARD_DISABLE_IRIS).

אם שיטות האימות הביומטרי לא עומדות בדרישות עבור Class 3 (לשעבר Strong), כפי שמתואר במאמר סעיף 7.3.10:

• [C-5-1] חובה להשבית את השיטות אם בקר מדיניות המכשירים (DPC) האפליקציה הגדירה את מדיניות האיכות בנושא דרישות סיסמה באמצעות הפונקציה DevicePolicyManager.setrequiredPasswordComplexity() עם קטגוריית מורכבות מוגבלת יותר מ-PASSWORD_COMPLEXITY_LOW או באמצעות DevicePolicyManager.setPassword Quality() שהאיכות שלהן קבועה יותר מ- PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] חובה לעמוד בדרישות של המשתמש הראשי המומלץ אימות (למשל: קוד אימות, קו ביטול נעילה, סיסמה) כפי שמתואר בסעיפים [C-1-7] [C-1-8] בסעיף 7.3.10.
• [C-5-3] אסור להתייחס לשיטות כמסך נעילה מאובטח, לעמוד בדרישות המתחילות ב-C-8 בסעיף הזה,

אם הטמעות במכשירים מוסיפים או משנים את שיטות האימות לביטול הנעילה מסך הנעילה ושיטת אימות חדשה מבוססות על אסימון פיזי או המיקום:

• [C-6-1] חייב להיות להן מנגנון של חזרה כדי להשתמש באחד מהערכים המומלצים לשיטות אימות ראשיות, שמבוססות על סוד ידוע, את הדרישות להצגה כמסך נעילה מאובטח.
• [C-6-2] השיטה החדשה חייבת להיות מושבתת ואפשר להשתמש בה רק לשיטות אימות ראשיות מומלצות לביטול נעילת המסך כאשר האפליקציה Device Policy Controller (DPC) הגדירה את המדיניות עם אחת מהאפשרויות הבאות:
  • DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) אמצעי תשלום אחד
  • DevicePolicyManager.setPasswordQuality() שהאיכות שלהן קבועה יותר מ- PASSWORD_QUALITY_NONE
  • DevicePolicyManager.setRequiredPasswordComplexity() עם קטגוריית מורכבות מגבילה יותר PASSWORD_COMPLEXITY_NONE
• [C-6-3] המשתמש חייב לעמוד בדרישות להשתתפות באחד מהמשחקים הראשיים המומלצים שיטות אימות (למשל, קוד אימות, קו ביטול נעילה, סיסמה) לפחות פעם אחת בכל 4 שעות לכל היותר. כשאסימון פיזי עומד דרישות להטמעות של סוכן אמינות ב-C-X, הגבלות על זמן קצוב לתפוגה שמוגדרות ב-C-9-5 חלות במקום זאת.
• [C-6-4] אין להתייחס לשיטה החדשה כמסך נעילה מאובטח, פועלים בהתאם למגבלות שמפורטות ב-C-8 בהמשך.

אם בהטמעות של מכשירים יש מסך נעילה מאובטח וכוללים מסך אחד או יותר של סוכן האמון, שמטמיע את TrustAgentService System API, הוא:

• [C-7-1] חייב להופיע סימון ברור בתפריט ההגדרות ובמנעול את המסך כשנעילת המכשיר דחוית או שאפשר לבטל את הנעילה שלו על ידי סביבה אמינה. לדוגמה, AOSP עומד בדרישה הזו על ידי הצגת טקסט תיאור של ההגדרה 'נעילה אוטומטית' ו'לחצן ההפעלה ננעל באופן מיידי' ב תפריט ההגדרות וסמל בולט במסך הנעילה.
• [C-7-2] חובה ליישם באופן מלא את כל ממשקי ה-API של סוכני האמינות במסגרת הכיתה DevicePolicyManager, כמו KEYGUARD_DISABLE_TRUST_AGENTS באופן קבוע.
• [C-7-3] אסור להטמיע באופן מלא את TrustAgentService.addEscrowToken() פועל במכשיר שמשמש כמכשיר אישי ראשי (למשל, החזקה ביד), אבל ייתכן שהפונקציה תיושם באופן מלא במכשיר והטמעות שמשותפות בדרך כלל (למשל, Android TV או מכשיר לכלי רכב).
• [C-7-4] חובה להצפין את כל האסימונים המאוחסנים שנוספו על ידי TrustAgentService.addEscrowToken()
• [C-7-5] אסור לאחסן את מפתח ההצפנה או את אסימון הנאמנות באותו מכשיר שבו משתמשים במפתח. לדוגמה, מותר לפרסם מפתח שמאוחסן בטלפון כדי לבטל את הנעילה של חשבון משתמש בטלוויזיה. במכשירי כלי רכב, אסור לאחסן אסימון בנאמנות בכל חלק של הרכב.
• [C-7-6] חובה להודיע למשתמש על ההשלכות מבחינת אבטחה לפני שמאפשר לאסימון הנאמנות לפענח את אחסון הנתונים.
• [C-7-7] כדי להשתמש באחד מהיעדים המומלצים, חייב להיות מנגנון של חזרה למצב הקודם שיטות אימות ראשיות.
• [C-7-8] חובה לחייב את המשתמש להשתמש באחת מהשיטות המומלצות לאימות ראשי (למשל: קוד אימות, קו ביטול נעילה, סיסמה) לפחות פעם ב-72 שעות או פחות, אלא אם בטיחות המשתמש (למשל, הסחות דעת של הנהג) הוא חשש.
• [C-7-9] חובה לעמוד באתגר של המשתמש באחד מהמשחקים הראשיים המומלצים שיטות אימות (למשל: קוד אימות, קו ביטול נעילה, סיסמה), כפי שמתואר [C-1-7] ו-[C-1-8] בסעיף 7.3.10, אלא אם יש חשש בנוגע לבטיחות המשתמשים (למשל, הסחות דעת של הנהג).
• [C-7-10] אסור להתייחס אל מסך נעילה מאובטח ולפעול לפי המגבלות המפורטות ב-C-8 למטה.
• [C-7-11] אסור לאפשר לנציגים מהימנים במכשירים אישיים ראשיים (למשל: החזקה ביד) כדי לבטל את הנעילה של המכשיר, ויכולים להשתמש בהם רק כדי להשאיר את המכשיר שכבר לא נעול במצב של ביטול הנעילה למשך עד לא יותר מ-4 שעות. הטמעת ברירת המחדל של TrustManagerService ב-AOSP עומד בדרישה הזו.
• [C-7-12] חובה להשתמש בקוד קריפטוגרפי מאובטח (למשל UKEY2) ערוץ תקשורת שנועד להעביר את אסימון הנאמנות ממאגר האחסון מכשיר למכשיר היעד.

אם הטמעות במכשירים מוסיפים או משנים את שיטות האימות לביטול הנעילה את מסך הנעילה שאינו מסך נעילה מאובטח כפי שמתואר למעלה, ויש להשתמש שיטת אימות חדשה לביטול הנעילה של מגן המקשים:

• [C-8-1] השיטה החדשה חייבת להיות מושבתת כאשר הבקר לניהול מדיניות המכשירים (DPC) (DPC) הגדיר את המדיניות בנושא איכות סיסמאות באמצעות DevicePolicyManager.setPasswordQuality() שהאיכות שלהן קבועה יותר מ- PASSWORD_QUALITY_NONE או באמצעות DevicePolicyManager.setRequiredPasswordComplexity() שהמורכבות שלהן מגבילה יותר מ- 'password_COMPLExitY_NONE'.
• [C-8-2] אסור לאפס את הטיימרים לתפוגת הסיסמה שהוגדרו על ידי DevicePolicyManager.setPasswordExpirationTimeout()
• [C-8-3] אסור לחשוף API לשימוש של אפליקציות צד שלישי בפני שינוי מצב הנעילה.

אם ההטמעות במכשירים מאפשרות לאפליקציות ליצור הגדרות משניות תצוגות וירטואליות והם לא תומכים באירועי קלט משויכים, כמו VirtualDeviceManager, הם:

• [C-9-1] חייבים לנעול את המסכים הווירטואליים המשניים האלה כשהמכשיר צג ברירת המחדל נעול, והמסכים הווירטואליים המשניים האלו מבטלים את הנעילה שלהם בוטלה הנעילה של מסך ברירת המחדל של המכשיר.

אם יישומים של מכשירים מאפשרים לאפליקציות ליצור מסכים וירטואליים משניים ולתמוך בקלט המשויך למשל, דרך VirtualDeviceManager, הן:

• [C-10-1] חייבת להיות תמיכה במצבי נעילה נפרדים לכל מכשיר וירטואלי
• [C-10-2] חובה לנתק את כל המכשירים הווירטואליים בסיום הזמן הקצוב לתפוגה שהוגדר לחוסר פעילות
• [C-10-3] חייב להיות זמן קצוב לתפוגה ללא פעילות
• [C-10-4] חובה לנעול את כל המסכים כשהמשתמש יוזם נעילה, כולל על ידי התקציב המינימלי הדרוש לשימוש במכשירים ניידים (ראו סעיף 2.2.5[9.11/H-1-2])
• [C-10-5] חובה ליצור מופעי מכשירים וירטואליים נפרדים לכל משתמש
• [C-10-6] חובה להשבית את היצירה של אירועי קלט משויכים באמצעות VirtualDeviceManager כשמצוין באמצעות DevicePolicyManager.setNearbyAppStreamingPolicy
• [C-10-7] חובה להשתמש בלוח נפרד אך ורק לכל מכשיר וירטואלי (או השבתת הלוח במכשירים וירטואליים)
• [C-10-11] חובה להשבית את ממשק המשתמש לאימות במכשירים וירטואליים, כולל הזנת גורם ידע והנחיה ביומטרית
• [C-10-12] חובה להגביל הצגה של כוונות שהופעלו ממכשיר וירטואלי רק באותו מכשיר וירטואלי
• [C-10-13] אסור להשתמש במצב נעילה של מכשיר וירטואלי בתור אימות משתמש באמצעות מערכת Android Keystore. צפייה KeyGenParameterSpec.Builder.setUserAuthentication*

כאשר הטמעות המכשירים מאפשרות למשתמש להעביר את גורם ידע לאימות ממכשיר מקור למכשיר יעד, כמו בהגדרה הראשונית של מכשיר היעד, הן:

• [C-11-1] חובה להצפין את גורם הידע עם אחריות הגנה כמו שמתוארים שירות Google Cloud Key Vault סקירה מפורטת בנושא אבטחה בזמן ההעברה של של גורם ידע ממכשיר המקור למכשיר היעד, לא ניתן לפענח את גורם הידע או להשתמש בו מרחוק בכל אחד מהמכשירים.
• [C-11-2] חובה לבקש מהמשתמש במכשיר המקור לאשר את הגורם הידע של מכשיר המקור לפני ההעברה של גורם הידע למכשיר היעד.
• [C-11-3] חובה, במכשיר יעד שלא הוגדר בו אימות ראשי גורם ידע, מבקשים מהמשתמש לאשר גורם ידע שהועבר את מכשיר היעד לפני שמגדירים את גורם הידע הזה כגורם הראשי של גורם ידע לאימות במכשיר היעד ולפני שמבצעים זמינים כל הנתונים שהועברו ממכשיר המקור.

אם בהטמעות של מכשירים יש מסך נעילה מאובטח וכוללים מסך אחד או יותר סוכני מהימנות, שקוראים ל-TrustAgentService.grantTrust() System API באמצעות הדגל FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE שהם:

• [C-12-1] חובה לקרוא לפונקציה grantTrust() עם הדגל רק כאשר הוא מחובר אל של מכשיר פיזי קרוב עם מסך נעילה משל עצמו, וכשלמשתמש יש אימתו את הזהות שלהם במסך הנעילה הזה. במכשירים קרובים יכולים להשתמש במנגנונים לזיהוי נשיאה על פרק כף היד או נשיאה על הגוף לאחר ביטול נעילה חד-פעמי של משתמש לעמוד בדרישת האימות של המשתמשים.
• [C-12-2] חובה להכניס את הטמעת המכשיר אל TrustState.TRUSTABLE במצב שבו המסך כבוי (למשל, בלחיצה על לחצן או במסך 'זמן קצוב לתפוגה') והסוכן המהימן לא ביטל את האמון. ה-AOSP מספק בדרישה הזו.
• [C-12-3] חובה להעביר את המכשיר רק מ-TrustState.TRUSTABLE אל המצב TrustState.TRUSTED אם הסוכן המהימן עדיין מעניק אמון על סמך בדרישות שמפורטות ב-C-12-1.
• [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 (או גבוהה יותר), ופועלים לפי השלבים להגדרת המדידה שמפורטים כיול הנוכחות.
    • חובה להשתמש ב-LTF מאובטח כפי שמוגדר ב IEEE 802.11az.

אם יישומים של מכשירים מאפשרים לאפליקציות ליצור מסכים וירטואליים משניים ולתמוך בקלט המשויך אירועים כמו דרך VirtualDeviceManager והתצוגות לא מסומנות באמצעות VIRTUAL_DISPLAY_FLAG_SECURE, הן:

• [C-13-8] חובה לחסום פעילויות באמצעות המאפיין android:canDisplayOnRemoteAddress או המטא-נתונים android.activity.can_display_on_remote_devices שהוגדרו כ-false כדי להפעיל את המדיה הווירטואלית במכשיר.
• [C-13-9] חובה לחסום פעילויות שלא מאפשרים במפורש סטרימינג שמעידים על כך שהם מציגים תוכן רגיש, כולל דרך SurfaceView#setSecure, FLAG_SECURE, או SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, מתאריך שמופעל במכשיר הווירטואלי.
• [C-13-10] חובה להשבית את ההתקנה של אפליקציות שהופעלו ממכשירים וירטואליים.

אם בהטמעות של מכשירים יש תמיכה במצבי טעינה נפרדים של המסך דרך DeviceStateManager וגם תמיכה במצבי נעילה נפרדים של התצוגה דרך KeyguardDisplayManager, הן:

• [C-SR-2] מומלץ מאוד להשתמש בפגישה לאישורי שמוגדרות בסעיף 9.11.1 או פגישה ביומטרית, לפחות מפרטים של סיווג 1 מוגדרים בסעיף 7.3.10 כדי לאפשר מתן קבצים עצמאיים ביטול הנעילה מתצוגת ברירת המחדל של המכשיר.
• [C-SR-3] מומלץ מאוד להגביל את הנעילה של המסך הנפרד באמצעות זמן מוגדר לתפוגה של תצוגה.
• [C-SR-4] מומלץ מאוד לאפשר למשתמשים לנעול את כל המסכים באופן גלובלי באמצעות התכונה 'ללא 'ביטול נעילה עם טביעת אצבע'' מהמכשיר הראשי.

9.11.2. StrongBox

מערכת Android Keystore מאפשרת לאחסן מפתחות קריפטוגרפיים במעבד ייעודי מאובטח, וגם את סביבת ההפעלה המבודדת שמתוארת למעלה. למשל מעבד מאובטח ייעודי נקרא 'StrongBox'. דרישות C-1-3 עד C-1-11 שמפורטות בהמשך, מגדירים את הדרישות שהמכשירים צריכים לעמוד בהן להגדיר בתור StrongBox.

הטמעות של מכשירים עם מעבד מאובטח ייעודי:

• [C-SR-1] מומלץ מאוד לתמוך ב-StrongBox. מערכת StrongBox שסביר להניח שיהפכו לדרישה באחת מהגרסאות הבאות.

אם הטמעות במכשירים תומכים ב-StrongBox:

• [C-1-1] חובה להצהיר על FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] חובה לספק חומרה ייעודית מאובטחת שמשמשת לגיבוי מאגר מפתחות ואימות מאובטח של משתמשים. האבטחה הייעודית ייתכן שייעשה שימוש בחומרה גם למטרות אחרות.

• [C-1-3] חייב להיות מעבד (CPU) נפרד שלא חולק אף מטמון, DRAM ומעבדים-שותפים. או משאבי ליבה אחרים בעזרת מעבד האפליקציות (AP).

• [C-1-4] חובה לוודא שציוד היקפי ששותף עם AP לא יכול לשנות עיבוד StrongBox בכל צורה שהיא, או השגת מידע כלשהו מ-StrongBox. ייתכן ש-AP משביתים או חוסמים את הגישה ל-StrongBox.

• [C-1-5] חייב להיות שעון פנימי ברמת דיוק סבירה (+10%) שחסינה בפני מניפולציה שמבצעת AP.

• [C-1-6] חייב להיות מחולל מספרים אקראיים אמיתי שמייצר תפוקה אחידה ולא צפויה.

• [C-1-7] חייבת להיות עמידות בפני התעסקות, כולל התנגדות חדירה פיזית ותקלה.

• [C-1-8] חייבת להיות התנגדות בערוץ צדדי, כולל התנגדות דליפת מידע באמצעות חשמל, תזמון, קרינה אלקטרומגנטית וקרינה תרמית ערוצי קרינה צדדיים.

• [C-1-9] חייב להיות אחסון מאובטח שמבטיח סודיות, התקינות, האותנטיות, העקביות והעדכניות של תוכן. אסור לקרוא או לשנות את האחסון, אלא בהתאם להרשאה של ממשקי ה-API של StrongBox.

• כדי לאמת את התאימות ל[C-1-3] עד [C-1-9], מכשיר יישומים:

  • [C-1-10] חייבת לכלול את החומרה שאושרה בהתאם פרופיל הגנת IC מאובטח BSI-CC-PP-0084-2014 או מוערכת על ידי מעבדת בדיקות בעלת הסמכה לאומית, והמשלבת הערכת נקודות חולשה פוטנציאליות של התקפה גבוהה לפי יישום קריטריונים נפוצים של פוטנציאל התקפה על כרטיסים חכמים.
  • [C-1-11] חייבת לכלול את הקושחה שנבדקת על ידי מעבדה לביצוע בדיקות המוכרת ברמה הארצית, עם מתקפה ברמה גבוהה להעריך את נקודות החולשה הפוטנציאליות בהתאם יישום של קריטריונים נפוצים של פוטנציאל התקפה על כרטיסים חכמים.
  • [C-SR-2] מומלץ מאוד לכלול את החומרה וגם באמצעות יעד אבטחה, רמת הבטחת הערכה (EAL) 5, הוגדל על ידי AVA_VAN.5. יש סיכוי גבוה לקבל אישור EAL 5 יהפכו לדרישה באחת מהגרסאות הבאות.
  • [C-SR-3] מומלץ מאוד לספק עמידות למתקפות מבפנים (IAR), כלומר גורם פנימי עם גישה לחתימת קושחה מפתחות לא יכולים לייצר קושחה שגורמת ל-StrongBox להדליף סודות, כדי לעקוף דרישות אבטחה פונקציונליות או לאפשר גישה לנתוני משתמש רגישים. הדרך המומלצת להטמעה IAR נועד לאפשר עדכוני קושחה רק כאשר הסיסמה של המשתמש הראשי מסופק באמצעות IAuthSecret HAL.

9.11.3. פרטי כניסה לזהות

מערכת פרטי הכניסה לאימות זהויות מוגדרת ומושגת על ידי הטמעת כל בממשקי API android.security.identity.* חבילה. ממשקי ה-API האלה מאפשרים למפתחי אפליקציות לאחסן ולאחזר את זהות המשתמשים מסמכים. הטמעות מכשירים:

• [C-SR-1] מומלץ מאוד להטמיע את המסמך לאימות הזהות מערכת.

אם הטמעות של מכשירים מטמיעות את מערכת פרטי הכניסה לאימות הזהות:

• [C-1-1] חייב להחזיר ערך שאינו null בשדה IdentityCredentialStore#getInstance() .

• [C-1-2] חובה להטמיע את מערכת פרטי הכניסה לאימות זהויות (למשל, android.security.identity.* ממשקי API) עם קוד שמתקשר עם איש קשר מהימן באזור המבודד באופן מאובטח מהקוד שפועל הליבה (kernel) ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים קוד ליבה או מרחב משתמש שיכול לגשת למצב הפנימי של בסביבה מבודדת, כולל DMA.

• [C-1-3] הפעולות הקריפטוגרפיות שנדרשות להטמעת הזהות מערכת פרטי הכניסה (למשל, ממשקי ה-API של android.security.identity.*) חייבת להיות לביצוע מלא באפליקציה המהימנה ובחומר של מפתח פרטי אף פעם לא יוצאים מסביבת ההפעלה המבודדת, אלא אם צריך באמצעות ממשקי API ברמה גבוהה יותר (למשל createEphemeralKeyPair() ).

• [C-1-4] חובה להטמיע את האפליקציה המהימנה באופן שמאפשר מאפייני האבטחה לא מושפעים (למשל, נתוני פרטי כניסה לא פורסמו אלא אם התנאים של בקרת הגישה מתקיימים, לא ניתן להפיק כתובות MAC נתונים שרירותיים), גם אם מערכת Android לא מתנהגת כראוי או נפגעת.

פרויקט הקוד הפתוח של Android ב-upstream מספק הטמעת אפליקציה מהימנה (libeic) שאפשר להשתמש בהם כדי להטמיע את מערכת פרטי הכניסה לאימות.

9.12. מחיקת נתונים

כל ההטמעות במכשירים:

• [C-0-1] חובה לספק למשתמשים מנגנון לביצוע 'איפוס לנתוני היצרן'.
• [C-0-2] חובה למחוק את כל הנתונים במערכת הקבצים של נתוני המשתמש במהלך ביצוע "איפוס לנתוני היצרן".
• [C-0-3] חובה למחוק את הנתונים באופן שתואם את הרלוונטיות כגון NIST SP800-88 בעת ביצוע "נתוני מפעל" איפוס".
• [C-0-4] חייבת להפעיל את הפעולה שלמעלה לאפשרות 'איפוס לנתוני היצרן' בתהליך DevicePolicyManager.wipeData() ה-API נקרא על ידי אפליקציית Device Policy Controller של המשתמש הראשי.
• עשויה לספק אפשרות מהירה למחיקת נתונים שמבצעת רק מחיקה לוגית של נתונים.

9.13. מצב הפעלה בטוחה

ב-Android יש 'מצב הפעלה בטוחה', שמאפשר למשתמשים לבצע את ההפעלה למצב שבו רק אפליקציות מערכת שהותקנו מראש מורשות לפעול, וכל האפליקציות של צד שלישי האפליקציות מושבתות. המצב הזה, שנקרא 'מצב הפעלה בטוחה', מספק למשתמש יכולת להסיר אפליקציות של צד שלישי שעלולות להזיק.

הטמעות מכשירים הן:

• [C-SR-1] מומלץ מאוד להטמיע את מצב ההפעלה הבטוחה.

אם בהטמעות של מכשירים מוגדר מצב הפעלה בטוח:

• [C-1-1] חובה לספק למשתמש אפשרות להיכנס למצב הפעלה בטוחה באופן שלא יפריע לפעולה של צד שלישי מהאפליקציות המותקנות במכשיר, מלבד במקרים שבהם האפליקציה של הצד השלישי הבקר לניהול מדיניות המכשירים (DPC) והגדיר את UserManager.DISALLOW_SAFE_BOOT סימון כ-true.

• [C-1-2] חייבים לספק למשתמש את היכולת להסיר אפליקציות צד שלישי במצב בטוח.

• אמורה לספק למשתמש אפשרות להיכנס ל'מצב הפעלה בטוחה' את תפריט האתחול באמצעות תהליך עבודה שונה מזה של הפעלה רגילה.

9.14. בידוד של מערכת לכלי רכב

מכשירי Android Automotive צפויים לשתף נתונים עם רכבים חיוניים תת-מערכות באמצעות ה-HAL לרכב כדי לשלוח ולקבל הודעות ברשתות של רכבים כמו CAN bus.

כדי לאבטח את בורסת הנתונים, צריך להטמיע תכונות אבטחה שמפורטות בהמשך שכבות framework של Android למניעת אינטראקציה זדונית או לא מכוונת עם מערכות המשנה האלה.

9.15. תוכניות מנויים

תוכניות מנויים להתייחס לפרטי תוכנית היחסים של החיוב שסופקו על ידי ספק סלולר SubscriptionManager.setSubscriptionPlans()

כל ההטמעות במכשירים:

• [C-0-1] חייבים להחזיר תוכניות מנויים רק לאפליקציה של ספק הסלולר סיפק אותם במקור.
• [C-0-2] אסור לגבות או להעלות תוכניות מנויים מרחוק.
• [C-0-3] חובה לאפשר רק שינויים מברירת המחדל, כמו SubscriptionManager.setSubscriptionOverrideCongested() מהאפליקציה של ספק הסלולר שמספקת כרגע תוכניות מנויים תקפות.

9.16. העברת נתוני אפליקציות

אם הטמעות המכשיר כוללות יכולת להעביר נתונים ממכשיר אל של המכשיר האחר והם לא מגבילים את נתוני האפליקציה שהוא מעתיק שהוגדר על ידי מפתח האפליקציה במניפסט דרך android:fullBackupContent הם:

• [C-1-1] אסור ליזום העברות של נתוני אפליקציה מ: מכשירים שבהם המשתמש לא הגדיר אימות ראשי בתור מתואר ב: 9.11.1 מסך נעילה ואימות מאובטחים.
• [C-1-2] חובה לאשר באופן מאובטח את האימות הראשי במקור במכשיר, ולאשר בכוונת המשתמש להעתיק את הנתונים מהמקור המכשיר לפני העברת נתונים.
• [C-1-3] חייבים להשתמש באימות של מפתח אבטחה כדי לוודא שהאימות המכשיר ומכשיר היעד בהעברה ממכשיר למכשיר במכשירי Android לגיטימיים שמותקנת בהם תוכנת אתחול נעולה.
• [C-1-4] חובה להעביר נתוני אפליקציה רק לאותה אפליקציה של מכשיר היעד, עם אותו שם חבילה ואישור החתימה.
• [C-1-5] חובה לציין סימן לכך שמכשיר המקור מכיל נתונים הועבר על ידי העברת נתונים ממכשיר למכשיר בתפריט ההגדרות. משתמש לא אמורה להיות אפשרות להסיר את האינדיקציה הזו.

9.17. מסגרת הווירטואליזציה של 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 ב-upstream (AOSP) והמדיניות חייבת להרכיב את כל הכללים הקיימים של אף פעם.

• [C-1-4] חובה לאפשר רק קוד חתום לפלטפורמה אפליקציות בעלות הרשאותאסור לאפשר לקוד לא מהימן (למשל, אפליקציות של צד שלישי) ליצור וגם הפעלת מכונה וירטואלית מוגנת pVM . הערה: האפשרות הזו עשויה להשתנות בגרסאות עתידיות של Android.

• [C-1-5] אסור להפעיל מכונה וירטואלית מוגנת pVM כדי להריץ קוד שהוא לא חלק מתדמית היצרן או העדכונים שלו. כל מה שלא נכלל בהפעלה מאומתת של Android (למשל, קבצים שהורדו מהאינטרנט או מהתקנה ממקור לא ידוע) אסור לאפשר הרצה של מכונה וירטואלית .

התחלה של דרישות חדשות

• [C-1-5] חובה לאפשר רק ל-pVM שלא ניתן לניפוי באגים להפעיל קוד מהמפעל של התמונה או של עדכוני הפלטפורמה שלה, כולל עדכונים של באפליקציות.

סיום הדרישות החדשות

אם המכשיר כולל תמיכה בממשקי API של Android Virtualization Framework (android.system.virtualmachine.*), אז כל מכונה וירטואלית מוגנת כלשהי pVM מופע:

• [C-2-1] חייבת להיות יכולת להפעיל את כל מערכות ההפעלה הזמינות וירטואליזציה של APEX במכונה וירטואלית מוגנת pVM .
• [C-2-2] אסור להפעיל מכונה וירטואלית מוגנת pVM כדי להריץ מערכת הפעלה שלא נחתמה על ידי מכשיר ההטמעה של המכשיר או ספק מערכת ההפעלה.
• [C-2-3] אסור להפעיל מכונה וירטואלית מוגנת pVM כדי להריץ נתונים כקוד (למשל: SELinux אף פעם לא מאפשר execmem).

• [C-2-4] אסור לשנות, להשמיט או להחליף את כללי ברירת המחדל שקיימים בתוך המערכת/sepolicy/microdroid שסופקה בקוד הפתוח של Android ב-upstream פרויקט (AOSP).

• [C-2-5] חובה להטמיע את Protected Virtual Machine pVM מנגנוני הגנה לעומק (למשל, SELinux למכונות וירטואליות) גם למערכות הפעלה שאינן Microdroid.
• [C-2-6] חייב לוודא ש ה-pVM נכשל הקושחה מסרבת להפעיל אם אין אפשרות לבצע אימות אי אפשר לאמת את התמונות הראשוניות שתפעילו ה-VM. האימות חייב להתבצע בתוך המכונה הווירטואלית.
• [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 API, ולאחר מכן בכל התחומים:

• [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 בצורה נכונה, כלומר לספק את הערכים הנכונים.

10. בדיקת תאימות לתוכנה

הטמעות של מכשירים חייבות לעבור את כל הבדיקות שמתוארות בקטע הזה. עם זאת, חשוב לדעת שאף חבילה של בדיקת תוכנה לא מקיפה לחלוטין. מהסיבה הזו, מומלץ מאוד להטמיע מכשירים מספר מינימלי של שינויים שאפשר לבצע בקובץ העזר, של Android זמין מפרויקט הקוד הפתוח של Android. כך תפחיתו את הסיכון להצגת באגים שגורמים לאי-תאימות. שדורשים עיבוד חוזר ועדכונים פוטנציאליים למכשיר.

10.1. חבילה לבדיקת תאימות

הטמעות מכשירים:

• [C-0-1] חייבים לעבור את הכלי לבדיקת תאימות ל-Android (CTS). זמין מפרויקט הקוד הפתוח של Android, באמצעות עלות המשלוח הסופית שמותקנת במכשיר.

• [C-0-2] חייבים להבטיח תאימות במקרים של אי-בהירות ב-CTS ולכל יישומים מחדש של חלקים מקוד המקור של ההפניה.

ה-CTS נועד לפעול במכשיר אמיתי. כמו כל תוכנה, CTS עלול להכיל באגים. ל-CTS יהיו גרסאות בנפרד הגדרת תאימות, וייתכן שגרסאות מרובות של ה-CTS יושקו עבור Android מגרסה 14.

הטמעות מכשירים:

• [C-0-3] חובה לעבור את גרסת ה-CTS האחרונה שזמינה למועד המכשיר הושלמה.

• יש להשתמש ביישום ההפניה בעץ הקוד הפתוח של Android כמה שיותר.

10.2. מאמת CTS

מאמת ה-CTS כלול בחבילה לבדיקת תאימות. נועד להיות מופעל על ידי מפעיל אנושי כדי לבדוק פונקציונליות שלא יכולה שנבדקות על ידי מערכת אוטומטית, כמו למשל תפקוד תקין של מצלמה מחיישנים.

הטמעות מכשירים:

• [C-0-1] חובה להפעיל בצורה נכונה את כל המקרים הרלוונטיים במאמת ה-CTS.

לשירות ה-CTS Verifier יש בדיקות של סוגי חומרה רבים, כולל חומרה מסוימת זה אופציונלי.

הטמעות מכשירים:

• [C-0-2] חייבים לעבור את כל הבדיקות לחומרה שיש להם. למשל, אם במכשיר יש מד תאוצה, הוא חייב לבצע כראוי מקרה בדיקה של מד תאוצה ב-CTS Verifier.

מקרי בדיקה של תכונות שצוינו כאופציונליות בהגדרת התאימות הזו ייתכן שהמערכת תדלג על המסמך או תשמיט אותו.

• [C-0-2] בכל מכשיר ובכל גרסת build חייבים להפעיל את ה-CTS Verifier בצורה תקינה. כפי שצוין למעלה. עם זאת, מכיוון שגרסאות build רבות הן דומות מאוד, לא מצופה מהם להריץ באופן מפורש את מאמת ה-CTS במערכות build השונים רק בצורה טריוויאלית. באופן ספציפי, הטמעות של מכשירים שונה מיישום שעבר את מאמת ה-CTS רק על ידי קבוצה של לוקאלים, מיתוג וכדומה. ייתכן להשמיט את בדיקת CTS Verifier.

11. תוכנות Updatable

• [C-0-1] הטמעות מכשירים חייבות לכלול מנגנון שמחליף את את כל תוכנת המערכת. המנגנון לא צריך לבצע "שידור חי" שדרוגים – כלומר, ייתכן שתידרש הפעלה מחדש של המכשיר. ניתן להשתמש בכל שיטה, בתנאי שהיא יכולה להחליף את כל שהותקנה מראש במכשיר. למשל, כל אחת מהאפשרויות הבאות כדי לעמוד בדרישה הזו:

  • "אלחוטי (OTA)" הורדות עם עדכון אופליין באמצעות הפעלה מחדש.
  • 'שיתוף אינטרנט בין מכשירים' מתעדכן בחיבור USB ממחשב מארח.
  • "אופליין" מתעדכנת באמצעות הפעלה מחדש ועדכון מקובץ באחסון נשלף.

• [C-0-2] מנגנון העדכון השתמש בעדכוני תמיכה מבלי לאפס את נתוני המשתמש . כלומר, מנגנון העדכון חייב לשמור נתונים פרטיים של האפליקציה של אפליקציה משותפת. שימו לב שתוכנת Android ב-upstream כוללת על מנגנון העדכון שעומד בדרישה הזו.

• [C-0-3] חובה לחתום על העדכון כולו ולהפעיל את מנגנון העדכון במכשיר חייבים לאמת את העדכון והחתימה מול מפתח ציבורי שמאוחסן במכשיר.

• [C-SR-1] מומלץ מאוד לבצע גיבוב (hash) של העדכון על ידי מנגנון החתימה עם SHA-256 ומאמתים את הגיבוב מול המפתח הציבורי באמצעות ECDSA NIST P-256.

אם ההטמעות של המכשירים כוללות תמיכה בנתונים לא נמדדים חיבור כגון 802.11 או פרופיל Bluetooth PAN (רשת תקשורת אישית), ואז:

• [C-1-1] חייבת לתמוך בהורדות OTA עם עדכון אופליין באמצעות הפעלה מחדש.

יישומים של מכשירים צריכים לוודא שתמונת המערכת זהה בבינארי לתוצאה הצפויה בעקבות OTA. אתר OTA שמבוסס על בלוקים בפרויקט הקוד הפתוח של Android ב-upstream, שנוסף מאז Android 5.1, עומד בדרישה הזו.

בנוסף, הטמעות של מכשירים צריכות לתמוך בעדכוני מערכת A/B. ה-AOSP מטמיע את התכונה הזו באמצעות בקרת האתחול HAL.

אם נמצאה שגיאה בהטמעה של המכשיר לאחר השקתו, אבל בתוך משך החיים הסביר של המוצר שלו, שנקבע בהתייעצות עם צוות התאימות של Android כדי להשפיע על התאימות של צד שלישי של Google:

• [C-2-1] הטמעה של המכשיר חייבת לתקן את השגיאה באמצעות תוכנה זמין לעדכון שניתן להחיל בהתאם למנגנון שתיארנו.

Android כולל תכונות שמאפשרות לאפליקציה של בעלי המכשיר (אם יש כזו) שליטה בהתקנה של עדכוני מערכת. אם מערכת המשנה של עדכון המערכת למכשירים מדווחים על android.software.device_admin ואז:

• [C-3-1] חובה ליישם את ההתנהגות שמתוארת ב-SystemUpdatePolicy בכיתה.

12. יומן שינויים במסמך

לסיכום השינויים בהגדרת התאימות בגרסה הזו:

• יומן שינויים במסמכים

13. יצירת קשר

אפשר להצטרף אל פורום התאימות ל-Android ולבקש הבהרות או להעלות בעיות שלדעתך המסמך לא שער.