אנדרואיד 14
8 באפריל, 2024
2. סוגי התקנים
ראה גרסה
התחל דרישות חדשות
אם יישומי מכשיר כף יד מצהירים על
FEATURE_BLUETOOTH_LE
, הם:- [ 7.4 .3/H-1-3] יש למדוד ולפצות על היסט Rx כדי להבטיח שה-BLE RSSI החציוני הוא -50dBm +/-15dB במרחק 1 מטר מהתקן ייחוס המשדר ב-
ADVERTISE_TX_POWER_HIGH
. - [ 7.4 .3/H-1-4] יש למדוד ולפצות על היסט Tx כדי להבטיח שה-BLE RSSI החציוני הוא -50dBm +/-15dB בעת סריקה מהתקן ייחוס הממוקם במרחק של 1 מטר ומשדר ב-
ADVERTISE_TX_POWER_HIGH
.
- [ 7.4 .3/H-1-3] יש למדוד ולפצות על היסט Rx כדי להבטיח שה-BLE RSSI החציוני הוא -50dBm +/-15dB במרחק 1 מטר מהתקן ייחוס המשדר ב-
ראה גרסה
אם יישומי מכשיר כף יד תומכים ב-System API
HotwordDetectionService
או במנגנון אחר לזיהוי מילות הפעלה ללא חיווי גישה למיקרופון, הם:- [9.8/H-1-6] אסור לאפשר שידור של יותר מ-100 בתים של נתונים מתוך שירות זיהוי מילות העזר בכל תוצאת מילת הפעלה מוצלחת למעט נתוני אודיו המועברים דרך HotwordAudioStream .
ראה גרסה
שנה את [9.8/H-1-13] ל:
- [9.8/H-SR-3] מומלץ בחום להפעיל מחדש את התהליך המארח את שירות זיהוי מילות המפתח לפחות פעם בשעה או כל 30 אירועי הפעלת חומרה, המוקדם מביניהם.
ראה גרסה
הוסרו הדרישות [9.8.2/H-4-3], [9.8.2/H-4-4], [9.8.2/H-5-3].
ראה גרסה
אם יישומי מכשיר כף יד מחזירים את
android.os.Build.VERSION_CODES.U
עבורandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, אז הם:- [ 7.5 /H-1-3] חייב לתמוך ב-
android.info.supportedHardwareLevel
במאפייןFULL
או טוב יותר עבור המצלמה הראשית האחוריתLIMITED
או טוב יותר עבור המצלמה הראשית הקדמית.
- [ 7.5 /H-1-3] חייב לתמוך ב-
ראה גרסה
אם למימושים של מכשירי טלוויזיה אין תצוגה מובנית, אלא תומכים בצג חיצוני המחובר באמצעות HDMI, הם:
- [ 5.8 /T-0-1] חייב להגדיר את מצב פלט HDMI לרזולוציה הגבוהה ביותר עבור פורמט הפיקסלים הנבחר שעובד עם קצב רענון של 50Hz או 60Hz עבור הצג החיצוני, בהתאם לקצב רענון הווידאו באזור שבו המכשיר נמכר יש להגדיר
את מצב פלט HDMI כדי לבחור את הרזולוציה המקסימלית שניתן לתמוך בקצב רענון של 50Hz או 60Hz.
- [ 5.8 /T-0-1] חייב להגדיר את מצב פלט HDMI לרזולוציה הגבוהה ביותר עבור פורמט הפיקסלים הנבחר שעובד עם קצב רענון של 50Hz או 60Hz עבור הצג החיצוני, בהתאם לקצב רענון הווידאו באזור שבו המכשיר נמכר יש להגדיר
3. תוכנה
ראה גרסה
- הדרישה הוסרה [C-1-9]
5. תאימות מולטימדיה
ראה גרסה
אם יישומי מכשירים מצהירים על תמיכה במפענח Dolby Vision דרך
HDR_TYPE_DOLBY_VISION
, הם:- [C-1-3] חייב להגדיר את מזהה הרצועה של שכבות בסיס תואמות לאחור (אם קיימות) להיות זהה למזהה הרצועה המשולבת של שכבת Dolby Vision.
7. תאימות חומרה
ראה גרסה
אם יישומי מכשירים תומכים במסכים המסוגלים לתצורת גודל
UI_MODE_TYPE_NORMAL
ומשתמשים בתצוגות פיזיות עם פינות מעוגלות כדי להציג את המסכים הללו, הם:- [C-1-1] חייב להבטיח שלפחות אחת מהדרישות הבאות מתקיימת עבור כל תצוגה כזו:
- כאשר תיבה
של 15על 18 dp על1518 dp מעוגנת בכל פינה של התצוגה הלוגית, לפחות פיקסל אחד מכל תיבה נראה על המסך.
- כאשר תיבה
- [C-1-1] חייב להבטיח שלפחות אחת מהדרישות הבאות מתקיימת עבור כל תצוגה כזו:
ראה גרסה
החזיר את הדרישות הבאות:
אם יישומי מכשירים מצהירים על
FEATURE_BLUETOOTH_LE
, הם:[C-SR-2] מומלץ בחום למדוד ולפצות על היסט Rx כדי להבטיח שה-BLE RSSI החציוני הוא -60dBm +/-10dB במרחק 1m מהתקן ייחוס המשדר ב-
ADVERTISE_TX_POWER_HIGH
, כאשר המכשירים מכוונים כך שהם ב'מישורים מקבילים' עם מסכים פונים לאותו כיוון.[C-SR-3] מומלץ בחום למדוד ולפצות על היסט Tx כדי להבטיח שה-BLE RSSI החציוני הוא -60dBm +/-10dB בעת סריקה מהתקן ייחוס הממוקם במרחק של 1 מטר ומשדר ב-
ADVERTISE_TX_POWER_HIGH
, כאשר המכשירים מכוונים כאלה שהם ב'מישורים מקבילים' עם מסכים פונים לאותו כיוון.
ראה גרסה
העבירו את הדרישות [C-10-3] ו-[C-10-4] ל -2.2.1. חומרה .
- [C-10-3] יש למדוד ולפצות על היסט Rx כדי להבטיח שה-BLE RSSI החציוני הוא -55dBm +/-10dB במרחק של 1m מהתקן ייחוס המשדר ב-
ADVERTISE_TX_POWER_HIGH
. - [C-10-4] יש למדוד ולפצות על היסט Tx כדי להבטיח שה-BLE RSSI החציוני הוא -55dBm +/-10dB בעת סריקה מהתקן ייחוס הממוקם במרחק של 1 מטר ומשדר ב-
ADVERTISE_TX_POWER_HIGH
.
20 בנובמבר 2023
2. סוגי התקנים
ראה גרסה
אם יישומי מכשיר כף יד מצהירים על תמיכה בכל 64 סיביות ABI (עם או בלי ABI של 32 סיביות):
ראה גרסה
- [ 7.5 /H-1-13] חייב לתמוך ביכולת
LOGICAL_MULTI_CAMERA
עבור המצלמה הראשית הפונה לאחור אם יש יותר מ-1 מצלמות RGB אחוריות.
- [ 7.5 /H-1-13] חייב לתמוך ביכולת
ראה גרסה
[ 5.8 /T-0-1] חייב להגדיר את מצב פלט HDMI לרזולוציה הגבוהה ביותר עבור פורמט ה-SDR או HDR הנבחר שעובד עם קצב רענון של 50Hz או 60Hz עבור הצג החיצוני.
יש להגדיר את מצב פלט HDMI כדי לבחור את הרזולוציה המקסימלית שניתן לתמוך בקצב רענון של 50Hz או 60Hz.
ראה גרסה
- [9/W-0-1] חייב להכריז על
android.hardware.security.model.compatible feature
.
- [9/W-0-1] חייב להכריז על
6. תאימות כלים ואפשרויות למפתחים
ראה גרסה
- [C-0-12] חייב לכתוב
LMK_KILL_OCCURRED_FIELD_NUMBER
Atom ל-
ראה גרסה
- [C-0-13] חייב ליישם את פקודת המעטפת
dumpsys gpu --gpuwork
כדי להציג
- [C-0-12] חייב לכתוב
9. תאימות מודל אבטחה
ראה גרסה
אם יישומי מכשירים משתמשים בליבת לינוקס שמסוגלת לתמוך ב-SELinux, הם:
ראה גרסה
אם הטמעות של מכשירים משתמשות בליבה שאינה לינוקס או לינוקס ללא SELinux, הם:
4 באוקטובר 2023
2. סוגי התקנים
ראה גרסה
יישומי מכשירי אנדרואיד מסווגים כמכשירי כף יד אם הם עומדים בכל הקריטריונים הבאים:
- בעל גודל מסך אלכסוני פיזי בטווח של 4 אינץ'
3.3 אינץ' (או 2.5 אינץ' עבור יישומי מכשירים שנשלחו ברמת API 29 ומעלה)עד 8 אינץ'.
התחל דרישות חדשות
- יש ממשק קלט של מסך מגע.
- בעל גודל מסך אלכסוני פיזי בטווח של 4 אינץ'
ראה גרסה
יישומי מכשיר כף יד:
- [ 7.1 .1.1/H-0-1] חייב להיות בעל
מסך אחד לפחות תואם אנדרואיד שעומד בכל הדרישות המתוארות במסמך זה.צג שגודלו לפחות 2.2 אינץ' בקצה הקצר ו-3.4 אינץ' בקצה הארוך.
אם יישומי מכשיר כף יד תומכים בסיבוב מסך תוכנה, הם:
- [ 7.1 .1.1/H-1-1]* חייב להפוך את המסך הלוגי שזמין עבור יישומי צד שלישי להיות לפחות 2 אינץ' בקצה/ים הקצרים ו-2.7 אינץ' בקצה/ים הארוכים. מכשירים שנשלחו ב-Android API ברמה 29 ומעלה עשויים להיות פטורים מדרישה זו.
אם יישומי מכשיר כף יד אינם תומכים בסיבוב מסך תוכנה, הם:
- [ 7.1 .1.1/H-2-1]* חייב להפוך את המסך הלוגי שזמין עבור יישומי צד שלישי להיות בגודל של 2.7 אינץ' לפחות בקצה/ים הקצרים. מכשירים שנשלחו ב-Android API ברמה 29 ומעלה עשויים להיות פטורים מדרישה זו.
התחל דרישות חדשות
אם יישומי מכשיר כף יד מכריזים על
android.hardware.audio.output
ו-android.hardware.microphone
, הם:[ 5.6 /H-1-1] חייב להיות ממוצע רציף רציף של 300 אלפיות שניות או פחות מעל 5 מדידות, עם סטייה מוחלטת ממוצעת של פחות מ -30ms , בנתיבי הנתונים הבאים: "רמקול למיקרופון", 3.5 מ"מ מתאם loopback (אם נתמך), USB loopback (אם נתמך).
[ 5.6 /H-1-2] חייבת להיות השהייה ממוצעת של הקשה לטון של 300 אלפיות שניות או פחות על פני לפחות 5 מדידות דרך נתיב הנתונים של הרמקול למיקרופון.
אם יישומי מכשיר כף יד כוללים לפחות מפעיל הפטי אחד, הם:
- [ 7.10 /H]* אסור להשתמש במפעיל הפטי (רטט) אקסצנטרי מסתובב (ERM).
- [ 7.10 /H]* צריך ליישם את כל הקבועים הציבוריים עבור הפטיקה ברורה ב- android.view.HapticFeedbackConstants כלומר (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_TUALREAL, VFITUALREAL, VFITUALRE, VFI ECT, GESTURE_START ו-GESTURE_END).
- [ 7.10 /H]* צריך ליישם את כל הקבועים הציבוריים עבור הפטיקה ברורה ב- android.os.VibrationEffect , כלומר (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK ו-EFFECT_DOUBLE_CLICK) וכל קבועי
PRIMITIVE_*
הציבוריים האפשריים ב- Android rich.fos . לחץ, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). חלק מהפרימיטיבים הללו, כגון LOW_TICK ו-SPIN עשויים להיות מעשיים רק אם הוויברטור יכול לתמוך בתדרים נמוכים יחסית. - [7.10/H]* צריך לעקוב אחר ההנחיות למיפוי קבועים ציבוריים ב- android.view.HapticFeedbackConstants לקבועים המומלצים של android.os.VibrationEffect , עם קשרי המשרעת המתאימים.
- [ 7.10 /H]* צריך לעקוב אחר הערכת איכות עבור APIs של createOneShot() ו- createWaveform() .
- [ 7.10 /H]* צריך לוודא שהתוצאה של ה-API הציבורי של android.os.Vibrator.hasAmplitudeControl() משקפת נכונה את יכולות הוויברטור שלהם.
- [ 7.10 /H]* צריך למקם את מיקום המפעיל ליד המיקום שבו המכשיר מוחזק או נוגע בו בידיים.
אם יישומי מכשירי כף יד כוללים לפחות מפעיל תהודה ליניארי אחד לשימוש כללי 7.10 , הם:
- [ 7.10 /H] צריך למקם את מיקום המפעיל ליד המיקום שבו המכשיר מוחזק או נוגע בו בידיים.
- [ 7.10 /H] צריך להזיז את המפעיל ההפטי בציר ה-X (שמאל-ימין) של כיוון
הדיוקןהטבעי של המכשיר .
אם למימושים של מכשירי כף יד יש מפעיל הפטי למטרות כלליות שהוא מפעיל תהודה ליניארי בציר X (LRA), הם:
- [ 7.10 /H] תדר התהודה של ציר ה-X LRA צריך להיות מתחת ל-200 הרץ.
- [ 7.1 .1.1/H-0-1] חייב להיות בעל
ראה גרסה
יישומי מכשיר כף יד חייבים לתמוך בפורמטים הבאים של קידוד וידאו ולהפוך אותם לזמינים ליישומי צד שלישי:
- [ 5.2 /H-0-3] AV1
יישומי מכשיר כף יד חייבים לתמוך בפורמטים הבאים של פענוח הווידאו ולהפוך אותם לזמינים ליישומי צד שלישי:
- [ 5.3 /H-0-6] AV1
ראה גרסה
אם יישומי מכשירים הכוללים את מקש הניווט של הפונקציות האחרונות כמפורט בסעיף 7.2.3 משנים את הממשק, הם:
- [ 3.8 .3/H-1-1] חייבים ליישם את התנהגות הצמדת המסך ולספק למשתמש תפריט הגדרות כדי להחליף את התכונה.
אם יישומי מכשיר כף יד כוללים תמיכה ב-
ControlsProviderService
ו-Control
APIs ומאפשרים ליישומי צד שלישי לפרסם פקדי מכשירים , אז הם:- [ 3.8 .16/H-1-6] יישומי מכשיר חייבים להציג במדויק את מימון המשתמש באופן הבא:
- אם המכשיר הגדיר
config_supportsMultiWindow=true
והאפליקציה מצהירה על המטא-נתוניםMETA_DATA_PANEL_ACTIVITY
בהצהרתControlsProviderService
, כולל ComponentName של פעילות חוקית (כפי שהוגדר על ידי ה-API), אז האפליקציה חייבת להטמיע את הפעילות האמורה בתקציב הזה של המשתמש. - אם האפליקציה לא מצהירה על מטא-נתונים
META_DATA_PANEL_ACTIVITY
, עליה להציג את השדות שצוינו כפי שסופקו על-ידיControlsProviderService
API וכן כל שדות שצוינו שסופקו על-ידי ממשקי ה- Control API.
- אם המכשיר הגדיר
- [ 3.8 .16/H-1-7] אם האפליקציה מצהירה על המטא-נתונים
META_DATA_PANEL_ACTIVITY
, עליה להעביר את הערך של ההגדרה שהוגדרה ב-[3.8.16/H-1-5] באמצעותEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
בעת הפעלת הפעילות המוטבעת.
אם יישומי מכשירים מאפשרים למשתמשים לבצע שיחות מכל סוג שהוא, הם
- [ 7.4.1.2 /H-0-1] חייב להכריז על דגל התכונה
android.software.telecom
. - [ 7.4.1.2 /H-0-2] חייב ליישם את מסגרת הטלקום .
ראה גרסה
יישומי מכשיר כף יד:
- [ 8.5 /H-0-1] חייב לספק תקציב למשתמש
בתפריט ההגדרותכדי לראות את כל האפליקציות עם שירותי חזית פעילים או עבודות ביוזמת המשתמש, כולל משך הזמן של כל אחד מהשירותים הללו מאז שהחל כמתואר במסמך ה-SDK .והיכולת לעצור אפליקציה שמפעילה שירות קדמי או עבודה ביוזמת המשתמש.עם היכולת לעצור אפליקציה שמפעילה שירות חזית ולהציג את כל האפליקציות שיש להן שירותי חזית פעילים ואת משך הזמן של כל אחד מהשירותים הללו מאז שהחל כמתואר במסמך SDK .- אפליקציות מסוימות עשויות להיות פטורות מעצירה או מלהיות רשומות בתקציב משתמש כזה כמתואר במסמך ה-SDK .
- [ 8.5 /H-0-1] חייב לספק תקציב למשתמש
- [ 8.5 /H-0-2]חייבים לספק תקציב למשתמש כדי לעצור אפליקציה שמפעילה שירות קדמה או עבודה ביוזמת המשתמש.
ראה גרסה
אם יישומי מכשירים מצהירים על תמיכה ב- android.hardware.telephony
, הם:
- [ 9.5 /H-1-1] אסור להגדיר
UserManager.isHeadlessSystemUserMode
ל-true
.
אם להטמעות המכשיר יש מסך נעילה מאובטח וכוללות סוכן אמון אחד או יותר, המטמיע את TrustAgentService
System API, הם:
- [ 9.11.1 /H-1-1] חייב לאתגר את המשתמש באחת משיטות האימות העיקריות המומלצות (למשל: PIN, דפוס, סיסמה) בתדירות גבוהה יותר מפעם אחת בכל 72 שעות.
אם יישומי מכשיר כף יד מגדירים UserManager.isHeadlessSystemUserMode
ל- true
, הם
אם יישומי מכשיר כף יד תומכים ב-System API HotwordDetectionService
או במנגנון אחר לזיהוי מילות הפעלה ללא חיווי גישה למיקרופון, הם:
- [9.8/H-1-1] חייב לוודא ששירות זיהוי מילות העזר יכול להעביר נתונים רק למערכת,
ContentCaptureService
או לשירות זיהוי דיבור במכשיר שנוצר על ידיSpeechRecognizer#createOnDeviceSpeechRecognizer()
. - [9.8/H-1-6] אסור לאפשר שידור של יותר מ-100 בתים של נתונים (לא כולל זרמי אודיו) מתוך שירות זיהוי מילות העזר בכל תוצאה מוצלחת של מילת הפעלה.
- [9.8/H-1-15] חייב להבטיח שזרמי אודיו המסופקים על תוצאות מילות מפתח מוצלחות מועברות בכיוון אחד משירות זיהוי מילות העזר לשירות האינטראקציה הקולית.
אם יישומי מכשיר כוללים יישום המשתמש ב-System API HotwordDetectionService
, או מנגנון דומה לזיהוי מילת עזר ללא חיווי שימוש במיקרופון, היישום:
- [9.8/H-2-3] אסור לשדר משירות זיהוי מילות העזר, נתוני אודיו, נתונים שניתן להשתמש בהם כדי לשחזר (מלא או חלקי) את האודיו, או תוכן אודיו שאינו קשור למילת ההפעלה עצמה, למעט
ContentCaptureService
או שירות זיהוי דיבור במכשיר.
אם יישומי מכשיר כף יד תומכים ב-System API VisualQueryDetectionService
או במנגנון אחר לזיהוי שאילתות ללא חיווי גישה למיקרופון ו/או למצלמה, הם:
- [9.8/H-3-1] חייב לוודא ששירות זיהוי השאילתות יכול להעביר נתונים רק למערכת, או
ContentCaptureService
, או לשירות זיהוי דיבור במכשיר (נוצר על ידיSpeechRecognizer#createOnDeviceSpeechRecognizer()
). - [9.8/H-3-2] אסור לאפשר העברת מידע אודיו או וידאו כלשהו מתוך
VisualQueryDetectionService
, למעטContentCaptureService
או שירות זיהוי דיבור במכשיר. - [9.8/H-3-3] חייב להציג הודעת משתמש בממשק המשתמש של המערכת כאשר המכשיר מזהה את כוונת המשתמש להתחבר ליישום Digital Assistant (למשל על ידי זיהוי נוכחות משתמש באמצעות מצלמה).
- [9.8/H-3-4] חייב להציג מחוון מיקרופון ולהציג את שאילתת המשתמש שזוהה בממשק המשתמש מיד לאחר זיהוי שאילתת המשתמש.
- [9.8/H-3-5] אסור לאפשר לאפליקציה הניתנת להתקנה על ידי משתמש לספק את שירות זיהוי השאילתות החזותי.
ראה גרסה
אם יישומי מכשיר כף יד מחזירים את android.os.Build.VERSION_CODES.T
עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, אז הם:
- חייב לעמוד בדרישות המדיה המפורטות בסעיף 2.2.7.1 של Android 13 CDD .
התחל דרישות חדשות
אם יישומי מכשיר כף יד מחזירים אתandroid.os.Build.VERSION_CODES.U
עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, אז הם:- [5.1/H-1-1] חייב לפרסם את המספר המרבי של הפעלות מפענח וידאו חומרה שניתן להפעיל בו-זמנית בכל שילוב codec באמצעות השיטות
CodecCapabilities.getMaxSupportedInstances()
ו-VideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-2] חייב לתמוך ב-6 מופעים של הפעלות מפענח וידאו חומרה של 8 סיביות (SDR) (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב codec הפועל במקביל ל-3 הפעלות ברזולוציית 1080p@30 fps ו-3 מפגשים ברזולוציית 4k@30fps, אלא אם כן AV1. AV1 codec נדרשים רק לתמיכה ברזולוציית 1080p, אך עדיין נדרשים לתמוך ב-6 מופעים ברזולוציה של 1080p30fps.
- [5.1/H-1-3] חייב לפרסם את המספר המרבי של הפעלות מקודד וידאו חומרה שניתן להפעיל בו-זמנית בכל שילוב codec באמצעות השיטות
CodecCapabilities.getMaxSupportedInstances()
ו-VideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-4] חייב לתמוך ב-6 מופעים של הפעלות מקודד וידאו חומרה של 8 סיביות (SDR) (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב codec הפועל במקביל ל-4 הפעלות ברזולוציית 1080p@30 fps ו-2 מפגשים ברזולוציית 4k@30fps, אלא אם כן AV1. AV1 codec נדרשים רק לתמיכה ברזולוציית 1080p, אך עדיין נדרשים לתמוך ב-6 מופעים ברזולוציה של 1080p30fps.
- [5.1/H-1-5] חייב לפרסם את המספר המרבי של הפעלות מקודד ומפענח וידאו חומרה שניתן להפעיל בו-זמנית בכל שילוב codec באמצעות השיטות
CodecCapabilities.getMaxSupportedInstances()
ו-VideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-6] חייב לתמוך ב-6 מופעים של מפענח וידאו חומרה 8 סיביות (SDR) ומקודד וידאו חומרה (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב codec הפועל במקביל ל-3 הפעלות ב-4K @30fps רזולוציה (אלא אם AV1), מתוכם לכל היותר 2 מפגשי מקודד ו-3 מפגשים ברזולוציית 1080p. AV1 codec נדרשים רק לתמיכה ברזולוציית 1080p, אך עדיין נדרשים לתמוך ב-6 מופעים ברזולוציה של 1080p30fps.
- [5.1/H-1-19] חייב לתמוך בשלושה מופעים של מפענח וידאו חומרה 10 סיביות (HDR) ומקודד וידאו חומרה (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב codec הפועל במקביל ברזולוציית 4K@30fps (אלא אם כן AV1) שמתוכם לכל היותר 1 הוא סשן מקודד, שניתן להגדיר בפורמט קלט RGBA_1010102 דרך משטח GL. יצירת מטא נתונים של HDR על ידי המקודד אינה נדרשת אם קידוד ממשטח GL. הפעלות codec AV1 נדרשות רק כדי לתמוך ברזולוציית 1080p גם כאשר דרישה זו דורשת 4K.
- [5.1/H-1-7] חייב להיות חביון אתחול ה-codec של 40 ms או פחות עבור הפעלה של קידוד וידאו של 1080p ומטה עבור כל מקודדי הווידאו החומרה בעת עומס. הטעינה כאן מוגדרת כהפעלה מקבילה של 1080p עד 720p של המרת קידוד של וידאו בלבד באמצעות רכיבי רכיבי Codec של חומרה יחד עם אתחול הקלטת אודיו-ווידאו של 1080p. עבור Dolby vision codec, זמן האחזור של אתחול ה-codec חייב להיות 50 ms או פחות.
- [5.1/H-1-8] חייב להיות חביון אתחול ה-codec של 30 ms או פחות עבור הפעלת קידוד אודיו של 128 kbps או קצב סיביות נמוך יותר עבור כל מקודדי האודיו בעת עומס. הטעינה כאן מוגדרת כהפעלה מקבילה של 1080p עד 720p של המרת קידוד של וידאו בלבד באמצעות רכיבי רכיבי Codec של חומרה יחד עם אתחול הקלטת אודיו-ווידאו של 1080p.
- [5.1/H-1-9] חייב לתמוך בשני מקרים של הפעלות מפענח וידאו חומרה מאובטחות (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב קודקים הפועל במקביל ברזולוציית 4k@30 fps (אלא אם כן AV1) עבור שניהם 8- תוכן סיביות (SDR) ו-10 סיביות HDR. הפעלות codec AV1 נדרשות רק כדי לתמוך ברזולוציית 1080p גם כאשר דרישה זו דורשת 4K.
- [5.1/H-1-10] חייב לתמוך ב-3 מופעים של הפעלות מפענח וידאו לא מאובטחות בחומרה יחד עם מופע אחד של הפעלת מפענח וידאו מאובטח של חומרה (סה"כ 4 מופעים) (AVC, HEVC, VP9, AV1 ומעלה) בכל codec שילוב הפועל במקביל ל-3 מפגשים ברזולוציית 4K@30 fps (אלא אם כן AV1) הכולל הפעלה אחת של מפענח מאובטח ו-nn-Secure הפעלה אחת ברזולוציית 1080p@30fps כאשר לכל היותר 2 מפגשים יכולים להיות ב-10 סיביות HDR. הפעלות codec AV1 נדרשות רק כדי לתמוך ברזולוציית 1080p גם כאשר דרישה זו דורשת 4K.
- [5.1/H-1-11] חייב לתמוך במפענח מאובטח עבור כל מפענח AVC, HEVC, VP9 או AV1 חומרה במכשיר.
- [5.1/H-1-12] חייב להיות חביון אתחול ה-codec של 40 ms או פחות עבור הפעלת פענוח וידאו של 1080p או פחות עבור כל מפענחי הווידאו החומרה בעת עומס. הטעינה כאן מוגדרת כהפעלה מקבילה של 1080p עד 720p של המרת קידוד של וידאו בלבד באמצעות רכיבי רכיבי Codec של חומרה יחד עם אתחול השמעת אודיו-ווידאו של 1080p. עבור Dolby vision codec, זמן האחזור של אתחול ה-codec חייב להיות 50 ms או פחות.
- [5.1/H-1-13] חייב להיות חביון אתחול ה-codec של 30 ms או פחות עבור פענוח פענוח אודיו של 128 kbps או קצב סיביות נמוך יותר עבור כל מפענחי האודיו בעת עומס. הטעינה כאן מוגדרת כהפעלה מקבילה של 1080p עד 720p של המרת קידוד של וידאו בלבד באמצעות רכיבי רכיבי Codec של חומרה יחד עם אתחול השמעת אודיו-ווידאו של 1080p.
- [5.1/H-1-14] חייב לתמוך במפענח חומרה AV1 Main 10, רמה 4.1 ו-film Grain.
- [5.1/H-1-15] חייב להיות בעל לפחות מפענח וידאו חומרה אחד התומך ב-4K60.
- [5.1/H-1-16] חייב להיות בעל מקודד וידאו חומרה אחד לפחות התומך ב-4K60.
- [5.3/H-1-1] אסור להפיל יותר מפריים אחד ב-10 שניות (כלומר פחות מ-0.167 אחוזים של ירידת פריים) עבור סשן וידאו של 4K 60 פריימים לשנייה תחת עומס.
- [5.3/H-1-2] אסור להפיל יותר מפריים אחד ב-10 שניות במהלך שינוי ברזולוציית וידאו בסשן וידאו של 60 פריימים לשנייה תחת עומס עבור סשן של 4K.
- [5.6/H-1-1] חייבת להיות השהיית הקשה לטון של 80 מילישניות או פחות באמצעות מבחן הקשה לטון של CTS Verifier.
- [5.6/H-1-2] חייב להיות חביון אודיו הלוך ושוב של 80 מילישניות או פחות לאורך נתיב נתונים נתמך אחד לפחות.
- [5.6/H-1-3] חייב לתמוך ב->=24 סיביות אודיו עבור פלט סטריאו מעל שקעי אודיו של 3.5 מ"מ אם קיימים ומעל אודיו USB אם נתמך דרך כל נתיב הנתונים לתצורות חביון ותצורות סטרימינג נמוכות. עבור תצורת האחזור הנמוך, האפליקציה צריכה להשתמש ב-Audio במצב התקשרות חוזרת עם אחזור נמוך. עבור תצורת הסטרימינג, האפליקציה צריכה להשתמש ב-Java AudioTrack. הן בתצורות האחזור הנמוך והן בתצורות הסטרימינג, כיור הפלט של HAL צריך לקבל
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
אוAUDIO_FORMAT_PCM_FLOAT
עבור פורמט הפלט שלו. - [5.6/H-1-4] חייב לתמוך בהתקני אודיו USB 4 ערוצים (זה משמש בקרי DJ לתצוגה מקדימה של שירים.)
- [5.6/H-1-5] חייבים לתמוך בהתקני MIDI תואמי מעמד ולהכריז על דגל תכונת MIDI.
- [5.6/H-1-9] חייב לתמוך במיקס של 12 ערוצים לפחות. זה מרמז על היכולת לפתוח אודיו-טראק עם מסכת ערוצים 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 |
גודל מאגר מינימלי של תת-דגימה | 1 MiB |
גודל מאגר קריפטו מינימלי כללי | 500 KiB |
מספר מינימלי של מפגשים במקביל | 30 |
מספר מינימלי של מפתחות להפעלה | 20 |
מספר מינימלי הכולל של מפתחות (כל ההפעלות) | 80 |
מספר מינימלי הכולל של מפתחות DRM (כל ההפעלות) | 6 |
גודל הודעה | 16 KiB |
מסגרות מפוענחות לשנייה | 60 פריימים לשנייה |
- [5.1/H-1-17] חייב להיות בעל לפחות מפענח תמונת חומרה אחד התומך בפרופיל AVIF Baseline.
- [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 שכבות חומרה ב-HWC (HWC), כאשר לפחות 2 מהם מסוגלים להציג תוכן וידאו של 10 סיביות.
אם יישומי מכשיר כף יד מחזירים את android.os.Build.VERSION_CODES.U
עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
והם כוללים תמיכה במקודד AVC או HEVC חומרה, אז הם:
- [5.2/H-2-1] חייב לעמוד ביעד האיכות המינימלי שהוגדר על ידי עקומות קצב עיוות מקודד הווידאו עבור רכיבי codec AVC ו-HEVC חומרה, כפי שהוגדר בתיעוד הקרוב.
ראה גרסה
android.os.Build.VERSION_CODES.U
עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, אז הם:- [ 7.5 /H-1-1] חייבת להיות מצלמה אחורית ראשית עם רזולוציה של לפחות 12 מגה פיקסל התומכת בצילום וידאו במהירות 4k@30fps. המצלמה הראשית הפונה לאחור היא המצלמה הפונה לאחור עם מזהה המצלמה הנמוך ביותר.
- [ 7.5 /H-1-2] חייבת להיות מצלמה קדמית ראשית עם רזולוציה של לפחות 6 מגה פיקסל ולתמוך בצילום וידאו ב-1080p@30fps. המצלמה הקדמית העיקרית היא המצלמה הקדמית עם מזהה המצלמה הנמוך ביותר.
- [ 7.5 /H-1-3] חייב לתמוך במאפיין
android.info.supportedHardwareLevel
כמלא או טוב יותר עבור שתי המצלמות הראשיות. - [ 7.5 /H-1-4] חייב לתמוך ב-
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
עבור שתי המצלמות הראשיות. - [ 7.5 /H-1-5] חייב להיות בעל זמן צילום JPEG של מצלמה 2 < 1000
900אלפיות השנייה עבור רזולוציית 1080p כפי שנמדדה על ידי מצלמת CTS PerformanceTest בתנאי תאורה ITS (3000K) עבור שתי המצלמות הראשיות. - [ 7.5 /H-1-6] חייב להיות חביון הפעלה של camera2 (מצלמה פתוחה למסגרת התצוגה המקדימה הראשונה) < 500 ms כפי שנמדד על ידי PerformanceTest מצלמת CTS בתנאי תאורה ITS (3000K) עבור שתי המצלמות הראשיות.
- [ 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 רחבה במיוחד הפונה לאותו כיוון.
- [ 7.5 /H-1-11] יש ליישם זרימה מקבילה קדמית אחורית במצלמות ראשיות.
- [ 7.5 /H-1-12] חייב לתמוך ב-
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
הן עבור המצלמה הקדמית והאחורית הראשית. - [ 7.5 /H-1-13] חייב לתמוך ביכולת
LOGICAL_MULTI_CAMERA
עבור המצלמות הראשיות אם יש יותר מ-1 מצלמות RGB הפונות לאותו כיוון. - [ 7.5 /H-1-14] חייב לתמוך ביכולת
STREAM_USE_CASE
הן עבור המצלמה הקדמית והאחורית הראשית. - [ 7.5 /H-1-15] חייב לתמוך בהרחבות מצב
Bokeh ולילהבאמצעות שני הרחבות CameraX ו-Camera2 עבור מצלמות ראשיות. - [ 7.5 /H-1-16] חייב לתמוך ביכולת DYNAMIC_RANGE_TEN_BIT עבור המצלמות הראשיות.
- [ 7.5 /H-1-17] חייב לתמוך ב- CONTROL_SCENE_MODE_FACE_PRIORITY ובזיהוי פנים ( STATISTICS_FACE_DETECT_MODE_SIMPLE או STATISTICS_FACE_DETECT_MODE_FULL ) עבור המצלמות הראשיות.
ראה גרסה
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 התומך בממוצע של לפחות 1000 ניטים.
- [7.6.1/H-2-1] חייב להיות לפחות 8 GB של זיכרון פיזי.
ראה גרסה
android.os.Build.VERSION_CODES.U
עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, אז הם:- [8.2/H-1-1] חייב להבטיח ביצועי כתיבה רציפים של לפחות 150 MB/s.
- [8.2/H-1-2] חייב להבטיח ביצועי כתיבה אקראית של לפחות 10 MB/s.
- [8.2/H-1-3] חייב להבטיח ביצועי קריאה רציפים של לפחות 250 MB/s.
- [8.2/H-1-4] חייב להבטיח ביצועי קריאה אקראית של לפחות 100 MB/s.
- [8.2/H-1-5] חייב להבטיח ביצועי קריאה וכתיבה מקבילים ברצף עם ביצועי קריאה וכתיבה פי 2 של לפחות 50 MB/s.
ראה גרסה
יישומי מכשירי טלוויזיה חייבים לתמוך בפורמטים הבאים של קידוד הווידאו ולהפוך אותם לזמינים ליישומי צד שלישי:
- [ 5.2 /T-0-3] AV1
יישומי מכשירי טלוויזיה חייבים לתמוך בפורמטים הבאים של פענוח הווידאו ולהפוך אותם לזמינים ליישומי צד שלישי:
- [ 5.3.2 /T-0-7] AV1
ראה גרסה
אם להטמעות של מכשירים יש מסך נעילה מאובטח וכוללות סוכן אמון אחד או יותר, שמיישם את TrustAgentService
System API, הם:
- [ 9.11.1 /W-1-1] חייב לאתגר את המשתמש באחת משיטות האימות העיקריות המומלצות (למשל: PIN, דפוס, סיסמה) בתדירות גבוהה יותר מפעם אחת בכל 72 שעות.
ראה גרסה
אם יישומי מכשירים כוללים תמיכה בשידורי רדיו 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-SR-1] מומלץ בחום לכלול מצלמה אחת או יותר הפונה לעולם.
- עשוי לכלול מצלמה אחת או יותר הפונה למשתמש.
- [7.5/A-SR-2] מומלץ בחום לתמוך בהזרמה במקביל של מצלמות מרובות.
אם יישומי מכשירי רכב כוללים לפחות מצלמה אחת הפונה לעולם, אז עבור מצלמה כזו, הם:
- [7.5/A-1-1] חייב להיות מכוון כך שהממד הארוך של המצלמה יתיישר עם מישור ה-XY של צירי חיישן הרכב של אנדרואיד.
- [7.5/A-SR-3] מומלץ בחום להחזיק בחומרה עם מיקוד קבוע או EDOF (עומק שדה מורחב).
- [7.5/A-1-2] חייבת להיות המצלמה הראשית הפונה לעולם כמצלמה הפונה לעולם עם מזהה המצלמה הנמוך ביותר.
אם יישומי מכשירי רכב כוללים לפחות מצלמה אחת הפונה למשתמש, אז עבור מצלמה כזו:
- [7.5/A-2-1] המצלמה הראשית הפונה למשתמש חייבת להיות המצלמה הפונה למשתמש עם מזהה המצלמה הנמוך ביותר.
- עשוי להיות מכוון כך שהממד הארוך של המצלמה יתיישר עם מישור ה-XY של צירי חיישן הרכב של אנדרואיד.
אם הטמעות של מכשירי רכב כוללים מצלמה הנגישה באמצעות android.hardware.Camera
או android.hardware.camera2
API, אז הם:
- [7.5/A-3-1] חייב לעמוד בדרישות הליבה של המצלמה בסעיף 7.5.
אם יישומי מכשירי רכב כוללים מצלמה שאינה נגישה דרך android.hardware.Camera
או android.hardware.camera2
API, אז הם:
- [7.5/A-4-1] חייב להיות נגיש באמצעות שירות מערכת התצוגה המורחבת.
אם יישומי מכשירי רכב כוללים מצלמה אחת או יותר הנגישה באמצעות שירות מערכת התצוגה המורחבת, עבור מצלמה כזו, הם:
- [7.5/A-5-1] אסור לסובב או לשקף אופקית את התצוגה המקדימה של המצלמה.
- [7.5/A-SR-4] מומלץ בחום לקבל רזולוציה של לפחות 1.3 מגה פיקסל.
אם יישומי מכשירי רכב כוללים מצלמה אחת או יותר הנגישות הן באמצעות שירות מערכת התצוגה המורחבת והן באמצעות android.hardware.Camera
או android.hardware.Camera2
API, עבור מצלמה כזו, הם:
- [7.5/A-6-1] חייב לדווח על אותו מזהה מצלמה.
אם יישומי מכשירי רכב מספקים ממשק API של מצלמה קנייני, הם:
- [7.5/A-7-1] חייבים ליישם ממשק API כזה של מצלמה באמצעות
android.hardware.camera2
API או Extended View System API.
ראה גרסה
הטמעות של מכשירי רכב:
- [ 3.8 /A-0-1] אסור לאפשר למשתמשים משניים מלאים שאינם משתמשי החזית הנוכחיים להפעיל פעילויות ויש להם גישה לממשק המשתמש בכל תצוגה.
ראה גרסה
אם יישומי מכשירי רכב מצהירים על 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] חייבים לספק אישור משתמש כדי להחליף את המיקרופון באפליקציית ההגדרות.
אם יישומי מכשירי רכב מכריזים על android.hardware.camera.any
, אז הם:
- [ 9.8.2 /A-2-1] חייב להציג את מחוון המצלמה כאשר אפליקציה ניגשת לנתוני מצלמה חיה, אך לא כאשר המצלמה ניגשת רק על ידי אפליקציות (ים) המחזיקה בתפקידים כפי שהוגדרו
נקראתבסעיף 9.1 הרשאות עם מזהה CDD [C-4-X][C-3-X].
אם ליישומי מכשירים יש מסך נעילה מאובטח וכולל סוכן אמון אחד או יותר, אשר מיישם את ה- API של מערכת TrustAgentService
, הם:
- [ 9.11.1 /A-1-1] חייב לאתגר את המשתמש באחת משיטות האימות הראשיות המומלצות (למשל: סיכה, דפוס, סיסמא) בתדירות גבוהה יותר מפעם אחת ל 336 שעות.
3. תוכנה
ראה עדכון
יישומי מכשירים:
- [C-0-8] אסור לתמוך בהתקנת יישומים הממוקדים לרמת API פחות מ- 23.
3.2.3.5. כוונות יישום מותנות :
ראה עדכון
אם יישומי מכשירים מדווחים על
android.hardware.nfc.uicc
אוandroid.hardware.nfc.ese
, הם:- [C-19-1] חייב ליישם את ה- NFCADAPTER.Action_Transaction_DETECTED API של כוונה (כ- "EVT_TRANSACTION" שהוגדר על ידי המפרט הטכני של איגוד GSM TS.26-דרישות המכשיר NFC) .
3.3.1. ממשקים בינאריים של יישום :
ראה עדכון
יישומי מכשירים:
- [C-0-12] חייבים לייצא סמלי
VK_KHR_swapchain
עבור הליבהVulkan 1.0VK_KHR_get_physical_device_properties2
1.1 סמלי פונקציה, כמו גם אתVK_KHR_surface
libvulkan.so
VK_KHR_android_surface
VK_KHR_maintenance1
שים לב כי בעוד שכל הסמלים חייבים להיות קיימים, סעיף 7.1.4.2 מתאר ביתר פירוט את הדרישות למועד הצפוי המלא של כל פונקציות תואמות.
- [C-0-12] חייבים לייצא סמלי
ראה עדכון
אם יישומי המכשירים כוללים פלט מסך או וידאו, הם: הם:
- [C-1-5] חייבים לייצר
VIBRANT
טונאליות צבעוניות דינאמיותMONOCHROMATIC
שימושEXPRESSIVE
נושאSPRITZ
RAINBOW
FRUIT_SALAD
android.theme.customization.theme_styles
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
TONAL_SPOT
.
- [C-1-5] חייבים לייצר
ראה עדכון
אם יישומי מכשירים הכוללים את מקש הניווט של הפונקציות האחרונות כמפורט בסעיף 7.2.3 משנים את הממשק, הם:
- [C-1-2] חייב ליישם את התנהגות הצמדת המסך ולספק למשתמש תפריט הגדרות כדי להחליף את התכונה.
ראה עדכון
אם יישומי מכשירים מכריזים על
android.software.managed_users
, הם: הם:- [C-1-10] חייב להבטיח כי נתוני צילום המסך נשמרים באחסון פרופיל העבודה כאשר צילום מסך נלכד בחלון
topActivity
שיש לו מיקוד (זה שהמשתמש התקשר איתו אחרון בין כל הפעילויות) ושייך לפרופיל עבודה אפליקציה . - [C-1-11] אסור ללכוד תוכן מסך אחר (סרגל מערכות, התראות או תוכן פרופיל אישי) למעט חלון היישום של פרופיל העבודה/Windows בעת שמירת צילום מסך לפרופיל העבודה (כדי להבטיח שנתוני הפרופיל האישי הם לא נשמר בפרופיל העבודה).
- [C-1-10] חייב להבטיח כי נתוני צילום המסך נשמרים באחסון פרופיל העבודה כאשר צילום מסך נלכד בחלון
3.9.5 מסגרת רזולוציית מדיניות המכשירים : פרק חדש
ראה עדכון
אם יישומי מכשירים מדווחים על
android.software.device_admin
אוandroid.software.managed_users
, אז הם:- [C-1-1] חייב לפתור קונפליקטים של מדיניות המכשירים כפי שתועד בתיעוד AOSP.
5. תאימות מולטימדיה
ראה עדכון
יישומי מכשירים חייבים לתמוך בקידוד קידוד התמונה הבאה:
- [C-0-4] AVIF
- על התקנים לתמוך
BITRATE_MODE_CQ
ובפרופיל הבסיס.
- על התקנים לתמוך
- [C-0-4] AVIF
ראה עדכון
יישומי מכשירים חייבים לתמוך בפענוח קידוד התמונה הבאה:
[C-0-7] AVIF (פרופיל בסיס)
ראה עדכון
פורמט/codec פרטים סוגי קבצים נתמכים/פורמטים של מכולות 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) ראה עדכון
פורמט/codec פרטים סוגי קבצים/פורמטים של מכולות לתמיכה 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, לפענח בלבד)
ראה עדכון
אם יישומי מכשירים תומכים בקודקי וידאו:
- [C-2-1] כל קודקי הווידיאו חייבים לפרסם נתוני קצב מסגרות בר השגה עבור הגדלים הבאים אם נתמכים על ידי ה- CODEC:
SD (באיכות נמוכה) SD (איכות גבוהה) HD 720p HD 1080p UHD רזולוציית וידאו - 176 x 144 px (H263, MPEG2, MPEG4)
- 352 x 288 px (מקודד MPEG4, H263, MPEG2)
- 320 x 180 px (VP8, VP8)
- 320 x 240 px (אחר)
- 704 x 576 px (H263)
- 640 x 360 px (VP8, VP9)
- 640 x 480 px (מקודד MPEG4)
- 720 x 480 px (אחר, AV1 )
- 1408 x 1152 px (H263)
- 1280 x 720 px (אחר, AV1 )
1920 x 1080 px (מלבד MPEG4, AV1 ) 3840 x 2160 px (HEVC, VP9, AV1 ) ראה עדכון
אם יישומי מכשירים תומכים בקודד וידאו כלשהו והופכים אותו לרשות אפליקציות של צד שלישי, הם: הם:- לא אמור להיות, על פני שני חלונות הזזה, יותר מ- 15% מעל קצב הסיביות בין מרווחי פנים (I-Frame).
- לא אמור להיות יותר מ 100% מעל קצב הסיביות מעל חלון הזזה של שניה אחת.
אם יישומי מכשירים תומכים בקודד וידאו כלשהו והופך אותו לרשות אפליקציות של צד שלישי, ומגדיר את
MediaFormat.KEY_BITRATE_MODE
ל-BITRATE_MODE_VBR
כך שהקידוד פועל במצב קצב סיביות משתנה, אם כן, כל עוד הוא לא משפיע על רצפת האיכות המינימלית , קצב הסיביות המקודד:-
[C-5-1] לא צריךלהיות , על חלון הזזה אחד, יותר מ- 15% מעל קצב הסיביות בין מרווחי פנים (I-Frame). -
[C-5-2] לא אמורלהיות יותר מ 100% מעל קצב הסיביות מעל חלון הזזה של שניה אחת.
אם יישומי מכשירים תומכים בקודד וידאו כלשהו והופך אותו לרשות אפליקציות של צד שלישי ומגדיר את
MediaFormat.KEY_BITRATE_MODE
ל-BITRATE_MODE_CBR
כך שהקידוד יפעל במצב קצב סיביות קבוע, אז קצב הסיביות המקודד:-
[C-6-1] חייב[C-SR-2] מומלץ מאוד לא להיות יותר מ -15% מעל קצב הסיביות היעד מעל חלון הזזה של שניה אחת.
ראה עדכון
אם יישומי מכשירים תומכים ב- H.263 מקודדים והפכו אותו לרשות אפליקציות של צד שלישי, הם: הם:
- [C-1-1] חייב לתמוך ברזולוציית QCIF (176 x 144) באמצעות רמת פרופיל הבסיס 45. רזולוציית SQCIF היא אופציונלית.
-
צריך לתמוך באופן דינמי של סיביות הניתנות להגדרה עבור המקודד הנתמך.
ראה עדכון
אם יישומי מכשירים תומכים ב- H.265 Codec, הם: הם:
- [C-1-1] חייב לתמוך ברמת הפרופיל הראשי 3 עד 512 x 512 רזולוציה .
-
צריך לתמוך בפרופילי קידוד HD כפי שצוין בטבלה הבאה. - [C-SR-1] מומלץ מאוד לתמוך בפרופיל SD 720 x 480 ובפרופילי קידוד HD כפי שצוין בטבלה הבאה אם יש מקודד חומרה.
5.2.6. AV1 : קטע חדש
ראה עדכון
אם יישומי מכשירים תומכים ב- AV1 Codec אז הם: הם:
- [C-1-1] חייב לתמוך בפרופיל הראשי כולל תוכן של 8 סיביות ו -10 סיביות.
[C-1-2] חייבים לפרסם נתוני ביצועים IE נתוני ביצועי דוחות באמצעות ממשקי ה- API של
getSupportedFrameRatesFor()
אוgetSupportedPerformancePoints()
לקבלת רזולוציות נתמכות בטבלה שלהלן.[C-1-3] חייב לקבל מטא נתונים של HDR ולהפיק אותה לזרם Bitstream
אם מקודד AV1 הוא מואץ חומרה, אז הוא:
- [C-2-1] חייב לתמוך עד וכולל פרופיל קידוד HD1080P מהטבלה שלהלן:
SD HD 720p HD 1080p UHD רזולוציית וידאו 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px דירוג מסגרת הסרטון 30 פריימים לשנייה 30 פריימים לשנייה 30 פריימים לשנייה 30 פריימים לשנייה קצב העברת וידאו 5 מגהביט לשנייה 8 מגהביט לשנייה 16 מגהביט לשנייה 50 מגהביט לשנייה ראה עדכון
אם יישומי מכשירים תומכים במפענחים של H.263, הם: הם:
- [C-1-1] חייב לתמוך ברמת פרופיל הבסיס 30 (CIF, QCIF ו- SQCIF Resolutions @ 30FPS 384KBPs) ורמה 45 (QCIF ו- SQCIF Resolutions @ 30FPS 128KBPs) .
ראה עדכון
אם יישומי מכשירים תומכים ב- AV1 Codec, הם:- [C-1-1] חייב לתמוך בפרופיל 0 כולל תוכן של 10 סיביות.
אם יישומי מכשירים תומכים ב- AV1 Codec והופכים אותו לזמין ליישומי צד ג ', הם: הם:
- [C-1-1] חייב לתמוך בפרופיל הראשי כולל תוכן של 8 סיביות ו -10 סיביות.
אם יישומי מכשירים מספקים תמיכה ל- AV1 Codec עם מפענח מואץ חומרה אז הם:
- [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 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px דירוג מסגרת הסרטון 30 פריימים לשנייה 30 פריימים לשנייה 30 פריימים לשנייה 30 פריימים לשנייה קצב העברת וידאו 5 מגהביט לשנייה 8 מגהביט לשנייה 16 מגהביט לשנייה 50 מגהביט לשנייה אם יישומי מכשירים תומכים בפרופיל HDR באמצעות ממשקי ה- API של המדיה, אז הם:
- [C-3-1] חייב לתמוך בחילוץ ויציאה של מטא נתונים HDR מהזרם ו/או המכולה.
- [C-3-2] חייב להציג כראוי תוכן HDR במסך המכשיר או ביציאת פלט וידאו רגילה (לדוגמה, HDMI).
ראה עדכון
אם יישומי מכשירים מכריזים על
android.hardware.microphone
, הם: הם:- צריך להגדיר רגישות לקלט שמע כך שמקור טון סינוסואידי של 1000 הרץ הושמע ברמת לחץ קול של 90 dB (SPL) (נמדד
במרחק של 30 ס"מ מהסביבהלמיקרופון ) מניב תגובה אידיאלית של RMS 2500 בטווח של 1770 ו 3530 עבור 16 דגימות סיביות (או -22.35 dB ± 3dB סולם מלא עבור נקודה צפה/דגימות דיוק כפול) עבור כל מיקרופון המשמש להקלטת מקור השמע לזיהוי הקול.
- צריך להגדיר רגישות לקלט שמע כך שמקור טון סינוסואידי של 1000 הרץ הושמע ברמת לחץ קול של 90 dB (SPL) (נמדד
ראה עדכון
אם יישומי מכשירים מכריזים על התכונה
android.hardware.audio.output
, הם:- [C-1-4] חייב לתמוך באפקטים שמע עם קלט ופלט של נקודה צפה.
- [C-1-5] חייב לוודא שאפקטים של שמע תומכים בערוצים מרובים עד לספירת ערוצי המיקסר המכונה גם FCC_LIMIT.
ראה עדכון
אם יישומי מכשירים מכריזים על
android.hardware.audio.output
הם מומלצים בחום לעמוד או לחרוג מהדרישות הבאות:- [C-SR-4] חותמת זמן הפלט שהוחזרה על ידי Audiotrack.getTimestamp ו-
AAudioStream_getTimestamp
מדויקת ל +/- 1 ms.
- [C-SR-4] ההשהיה המחושבת של הלוך ושוב על בסיס קלט ופלט חותמות חותמות שהוחזרו על ידי
AAudioStream_getTimestamp
מומלצות מאוד להיות בטווח של 30 msec מההשהיה הנסיעה הנסיעה עבורAAUDIO_PERFORMANCE_MODE_NONE
ו-AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
עבור Wearts, Wearts.
- [C-SR-4] חותמת זמן הפלט שהוחזרה על ידי Audiotrack.getTimestamp ו-
7. תאימות חומרה
ראה עדכון
אנדרואיד כולל מתקנים המתאימים אוטומטית את נכסי היישומים ופריסות ממשק המשתמש באופן מתאים עבור המכשיר כדי להבטיח כי יישומי צד שלישי פועלים היטב במגוון
תצורות חומרה .מגוון תצוגות ותצורות חומרה. תצוגה תואמת אנדרואיד היא מסך תצוגה המיישם את כל ההתנהגויות והממשקי API המתוארים במפתחי אנדרואיד-סקירה כללית של תאימות מסך , פרק זה (7.1) וסעיפי המשנה שלו, כמו גם כל התנהגויות ספציפיות לסוג המכשיר המתועדות בסעיף 2 של CDD זה.בתצוגות תואמות אנדרואיד, בהן כל היישומים התואמים אנדרואיד של אנדרואיד של צד שלישי יכולים להפעיל, על יישומי המכשירים ליישם כראוי ממשקי API והתנהגויות אלה, כמפורט בסעיף זה.התחל דרישות חדשות
יישומי מכשירים:
- [C-0-1] חייב, כברירת מחדל, להביא ליישומי צד ג 'רק לתצוגות תואמות אנדרואיד.
היחידות המפנות על ידי הדרישות בסעיף זה מוגדרות כדלקמן:
- גודל אלכסוני פיזי . המרחק בסנטימטרים בין שתי פינות מנוגדות של החלק המואר של התצוגה.
- צפיפות
נקודות לאינץ '(DPI). מספר הפיקסלים המקיפים על ידי טווח אופקי או אנכי ליניארי של 1 " , המתבטא כפיקסלים לאינץ '(PPI או DPI) . כאשר מופיעים ערכיDPIPPI ו- DPI , DPI אופקי וגם אנכי חייבים ליפול בטווח המופיע . - יחס רוחב -גובה . היחס בין הפיקסלים של הממד הארוך יותר למימד הקצר יותר של המסך. לדוגמה, תצוגה של 480x854 פיקסלים תהיה 854/480 = 1.779, או בערך "16: 9".
- פיקסל עצמאי בצפיפות (DP) .
יחידתהפיקסלים הווירטואלית מנורמלת לצפיפות מסךמסך של 160 DPIשל 160. עבור צפיפות מסוימת D, ומספר פיקסלים P, מספר ה- DP של פיקסלים עצמאיים בצפיפות, מחושב כ:PIXELS = DPS * (צפיפות/160)dp = (160 / d) * עמ ' .
ראה עדכון
אם יישומי מכשירים תומכים במסכי המסכים המסוגלים לתצורת הגודל של
UI_MODE_TYPE_NORMAL
וכוללים שימושתואם אנדרואידלתצוגה פיזית עם פינות מעוגלות כדי להעניק מסכים אלה , הם:- [C-1-1] חייב להבטיח שלפחות אחת מהדרישות הבאות מתקיימת עבור כל תצוגה כזו :
- הרדיוס של הפינות המעוגלות פחות או שווה ל 38 dp.
כאשר תיבת 15 DP על 15 DP מעוגנת בכל פינה בתצוגה הלוגית, לפחות פיקסל אחד של כל קופסה גלוי על המסך.
צריך לכלול את הרווחת של המשתמש כדי לעבור למצב התצוגה עם הפינות המלבניות.
התחל דרישות חדשות
אם יישומי מכשירים מסוגלים רק לתצורת המקלדת
NO_KEYS
, ומתכוונים לדווח על תמיכה בתצורתUI_MODE_TYPE_NORMAL
UI, הם: הם: הם: הם: הם: הם: הם:- [C-4-1] חייב להיות בעל גודל פריסה, למעט כל גזרות תצוגה, של לפחות 596 dp x 384 dp ומעלה.
אם יישומי המכשירים כוללים תצוגה (ים) תואמים אנדרואיד המתקפלים, או כוללת ציר מתקפל בין לוחות תצוגה מרובים והופך תצוגה (ים) מסוג זה להעברת אפליקציות של צד שלישי, הם: הם: הם: הם: הם: הם:
- [C-2-1] חייבים ליישם את הגרסה היציבה האחרונה הזמינה של ה- API של Extensions או הגרסה היציבה של API של Sidecar שתשמש את ספריית JetPack של מנהל החלונות .
אם יישומי המכשירים כוללים תצוגה (ים) תואמים אנדרואיד המתקפלים, או כוללת ציר מתקפל בין לוחות תצוגה מרובים, ואם הציר או הקיפול חוצה חלון יישום מסך מלא, הם: הם:
- [C-3-1] חייב לדווח על המיקום, גבולות ומצב הציר או קפל דרך הרחבות או ממשקי API של SideCar ליישום.
אם יישומי המכשירים כוללים אזורי תצוגה תואמים אנדרואיד אחד או יותר מתקפלים, או כוללים ציר מתקפל בין אזורי לוח תצוגה תואמים אנדרואיד מרובים והפוך אזורי תצוגה כאלה לזמינים ליישומים, הם: הם:
- [C-4-1] חייב ליישם את הגרסה הנכונה של רמת ה- API של מנהל החלונות כמתואר בתיעוד הקרוב.
7.1.1.2. יחס רוחב -גובה מסך : הוסר
ראה עדכון
יישומי מכשירים:
- [C-0-1]
כברירת מחדל, יישומי המכשיריםחייבים לדווחרקעל אחת מצפיפות המסגרת של אנדרואיד המופיעותDisplayMetrics
באמצעות API שלDENSITY_DEVICE_STABLE
וערך זה חייב להיות ערך סטטי עבור כל תצוגה פיזיתאסור להשתנות בכל עת; עם זאת,עם זאת המכשיר עשוי לדווח עלDisplayMetrics.density
צפיפות שרירותיתשונה. צפיפות בהתאם לשינויי תצורת התצוגה שנעשו על ידי המשתמש (לדוגמה, גודל התצוגה) מוגדר לאחר האתחול הראשוני.
- יישומי מכשירים צריכים להגדיר את צפיפות המסגרת הסטנדרטית של אנדרואיד שהיא הקרובה ביותר לצפיפות הפיזית של המסך, אלא אם כן צפיפות הגיונית זו דוחפת את גודל המסך המדווח מתחת למינימום הנתמך. אם צפיפות המסגרת הסטנדרטית של אנדרואיד שהיא הקרובה ביותר לצפיפות הפיזית גורמת לגודל מסך קטן מגודל המסך התואם הקטן ביותר הנתמך (320 DP), יישומי המכשירים צריכים לדווח על צפיפות המסגרת האנדרואיד הסטנדרטית הנמוכה ביותר.
התחל דרישות חדשות
- צריך להגדיר את צפיפות המסגרת הסטנדרטית של אנדרואיד שהיא הקרובה ביותר לצפיפות הפיזית של המסך, או ערך שימפה לאותו מדידות שדה-תצוגה זוויתי מקבילות של מכשיר כף יד.
אם יישומי מכשירים מספקים
קיימתמקור לשינוי גודל התצוגה של המכשיר , הם : הם:- [C-1-1]
אסור לקנה מידה של גודל התצוגהאסור לסדר את התצוגה הגדולה יותר מ- 1.5 פעמיםDENSITY_DEVICE_STABLE
צפיפות מקוריתאו להפיק ממד מסך מינימלי יעיל קטן מ- 320dP (שווה ערך ל- SW320DP במוקדמות המשאבים), המגיע לראשונה. -
אסור לקנה מידה של גודל התצוגה[C-1-2] אסור לסדר את התצוגה הקטנה יותר מ- 0.85 פעמיםמהצפיפות המקוריתDENSITY_DEVICE_STABLE
.
- [C-0-1]
ראה עדכון
אם יישומי מכשירים כוללים תמיכה ב- Vulkan
1.0 ומעלה, הם: הם:[C-1-3] חייב ליישם באופן מלא את ה-
Vulkan 1.0Vulkan 1.1 ממשקי API עבור כלVkPhysicalDevice
המנוי.[C-1-5] אסור למנות שכבות המסופקות על ידי ספריות מחוץ לחבילת היישומים, או לספק דרכים אחרות להתחקות או ליירט של ה- Vulkan API, אלא אם כן לאפליקציה יש את האפליקציה
android:debuggable
מוגדרת כ-true
או Metadatacom.android.graphics.injectLayers.enable
מוגדר כ-true
.
- צריך לתמוך ב-
VkPhysicalDeviceProtectedMemoryFeatures
ו-VK_EXT_global_priority
.
- [C-1-13] חייבים לעמוד בדרישות שצוינו על ידי פרופיל Baseodeate 2021 Android 2021 .
[C-SR-5] מומלצים מאוד לתמוך ב-
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
ו-VK_EXT_global_priority
.[C-SR-6] מומלץ מאוד להשתמש
SkiaVk
עם HWUI.
אם יישומי המכשירים כוללים תמיכה בוולקן 1.1 ולהצהיר על אחד מדגלי התכונה של וולקן המתוארים כאן , הם: הם:
- [C-SR-7] מומלץ מאוד להפוך את הרחבת
VK_KHR_external_fence_fd
לזמינה ליישומי צד ג 'ולאפשר ליישום לייצא עומס גדר ויבוא עומס גדר מתאורי קבצי POSIX כמתואר כאן .
ראה עדכון
אם ליישומי מכשירים יש חיישנים ביומטריים מרובים, הם:
[C-7-1] חייב, כאשר ביומטרי נמצא במנעול (כלומר הביומטרי מושבת עד שהמשתמש מתבטל באימות ראשוני) או נעילה של זמן (כלומר הביומטרי מושבת באופן זמני עד שהמשתמש ימתין לפרק זמן) בגלל יותר מדי ניסיונות כושלים, ננעל גם את כל שאר הביומטריה של מעמד ביומטרי נמוך יותר. במקרה של נעילת נעילה, זמן הגיבוי לאימות ביומטרי חייב להיות זמן הגיבוי המרבי של כל הביומטריה במנעול זמן.
[C-SR-12] מומלץ מאוד, כאשר ביומטרי נמצא במנעול (כלומר הביומטרי מושבת עד שהמשתמש מתבטל באימות ראשוני) או נעילה של זמן (כלומר הביומטרי מושבת באופן זמני עד שהמשתמש ימתין זמן מה מרווח) בגלל יותר מדי ניסיונות כושלים, לנעול גם את כל שאר הביומטריה של אותה מעמד ביומטרי. במקרה של נעילה כבולה בזמן, זמן הגיבוי לאימות ביומטרי מומלץ מאוד להיות זמן הגיבוי המרבי של כל הביומטריה במנעול זמן.
[C-7-2] חייב לאתגר את המשתמש לאימות הראשי המומלץ (למשל: סיכה, תבנית, סיסמה) כדי לאפס את דלפק הנעילה עבור ביומטרי שננעול. ניתן לאפשר ביומטריה של Class 3 לאפס את דלפק הנעילה לביומטריה נעולה מאותה מעמד או נמוך יותר. אסור לאפשר לביומטריה של Class 2 או Class 1 להשלים פעולת נעילה של איפוס עבור ביומטריה כלשהי.
אם יישומי מכשירים מעוניינים להתייחס לחיישן ביומטרי ככיתה 1 (לשעבר נוחות ), הם: הם:
[C-1-12] חייב להיות בעל זיוף וקצב קבלת מתחם שאינו גבוה מ- 40% לכל מינים של מכשיר התקפה מצגת (PAI) , כפי שנמדד על ידי פרוטוקולי הבדיקה של אנדרואיד ביומטריה .
[C-SR-13] מומלץ מאוד לקבל שיעור קבלת זיוף ולחומרה שאינו גבוה מ- 30% לכל מינים של מכשיר התקפה מצגת (PAI) , כפי שנמדד על ידי פרוטוקולי הבדיקה של אנדרואיד ביומטריה .
[C-SR-14] מומלץ מאוד לחשוף את המחלקה הביומטרית של החיישן הביומטרי ואת הסיכונים המתאימים להפעיל אותו.
[C-SR-17] מומלץ מאוד ליישם את ממשקי ה- AIDL החדשים (כגון,
IFace.aidl
ו-IFingerprint.aidl
).
אם יישומי מכשירים מעוניינים להתייחס לחיישן ביומטרי ככיתה 2 (לשעבר חלשה ), הם:
- [C-SR-15] מומלץ מאוד לקבל שיעור קבלת זיוף ולחומרה שאינו גבוה מ- 20% לכל מינים של מכשיר התקפה מצגת (PAI) , כפי שנמדד על ידי פרוטוקולי הבדיקה של אנדרואיד ביומטריה .
- [C-2-3] חייב לבצע את ההתאמה הביומטרית בסביבת ביצוע מבודדת מחוץ למשתמש אנדרואיד או שטח גרעינים, כמו סביבת הביצוע המהימנה (TEE),
אועל שבב עם ערוץ מאובטח לסביבת הביצוע המבודדת או מוגן מכונה וירטואלית העומדת בדרישות בסעיף 9.17 . - [C-2-4] חייב להיות כל הנתונים שניתן לזהות מוצפנים ומאמתים קריפטוגרפיה כך שלא ניתן לרכוש אותם, לקרוא או לשנותם מחוץ לסביבת הביצוע המבודדת או שבב עם ערוץ מאובטח לסביבת הביצוע המבודדת כפי שתועדה בהנחיות היישום באתר פרויקט הקוד הפתוח של אנדרואיד או במכונה וירטואלית מוגנת הנשלטת על ידי Hypervisor העומדת בדרישות בסעיף 9.17 .
- [C-2-5] עבור ביומטריה מבוססת מצלמה, ואילו אימות או הרשמה מבוסס ביומטרי מתרחשים:
- חייבת להפעיל את המצלמה במצב המונע לקרוא או לשנות את מסגרות המצלמה מחוץ לסביבת הביצוע המבודדת או לשבב עם ערוץ מאובטח לסביבת הביצוע המבודדת או למכונה וירטואלית מוגנת הנשלטת על ידי Hypervisor העומדת בדרישות בסעיף 9.17 .
- עבור פתרונות מצלמה יחידה של RGB, מסגרות המצלמה יכולות להיות ניתנות לקריאה מחוץ לסביבת הביצוע המבודדת כדי לתמוך בפעולות כמו תצוגה מקדימה להרשמה, אך עדיין לא ניתן לשנותו.
- [C-2-7] אסור לאפשר גישה לא מוצפנת לנתונים ביומטריים שניתן לזהות או לנתונים הנגזרים ממנו (כגון הטמעה) למעבד היישומים מחוץ להקשר של ה- TEE או המכונה הווירטואלית המוגנת הנשלטת על ידי Hypervisor העומדת בדרישות בסעיף סעיף 9.17 . מכשירי שדרוג שהושקו בגרסת אנדרואיד 9 ומעלה אינם פטורים מ- C-2-7.
אם יישומי מכשירים רוצים להתייחס לחיישן ביומטרי ככיתה 3 (לשעבר חזקה ), הם:
- [C-SR-16] מומלץ מאוד לקבל שיעור קבלת זיוף ולחומרה שאינו גבוה מ- 7% לכל מינים של מכשיר התקפה מצגת (PAI) , כפי שנמדד על ידי פרוטוקולי הבדיקה של אנדרואיד ביומטריה .
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
: STASTSTATIC STS DS-TWR
, מצב נדחה, מרווח טווח 240 ms. -
CONFIG_ID_2
:STATIC STS DS-TWR
מוגדר על ידי FIRA, מצב נדחה, מרווח טווח 200 ms. מקרה שימוש אופייני: טלפון חכם מקיים אינטראקציה עם מכשירים חכמים רבים. -
CONFIG_ID_3
: זהה ל-CONFIG_ID_1
, למעט נתוני Angle of-Arward (AOA) לא מדווחים. -
CONFIG_ID_4
: זהה ל-CONFIG_ID_1
, למעט מצב אבטחה P-STS מופעל. -
CONFIG_ID_5
: זהה ל-CONFIG_ID_2
, למעט מצב אבטחה של P-STS מופעל. -
CONFIG_ID_6
: זהה ל-CONFIG_ID_3
, למעט מצב אבטחה של P-STS מופעל. -
CONFIG_ID_7
: זהה ל-CONFIG_ID_2
, למעט P-STS מצב מפתח שליטה פרטני מופעל.
-
- [C-1-4] חייב לספק חיבור משתמש כדי לאפשר למשתמש להחליף את מצב הרדיו UWB/כיבוי.
- [C-1-5] חייבים לאכוף כי אפליקציות המשתמשות ברדיו UWB מחזיקות ברשות
UWB_RANGING
(תחת קבוצת ההרשאותNEARBY_DEVICES
).
העברת בדיקות ההתאמה וההסמכה הרלוונטיות שהוגדרו על ידי ארגונים סטנדרטיים, כולל FIRA , CCC ו- CSA מסייעת להבטיח נכון 802.1.15.4 פונקציות.
- [C-1-2] חייב לדווח על תכונת החומרה דגל
ראה עדכון
"טלפוניה" כפי שמשמשת ממשקי ה- API של אנדרואיד ומסמך זה מתייחס באופן ספציפי לחומרה הקשורה להצבת שיחות קוליות ושליחת הודעות SMS , או הקמת נתונים ניידים באמצעות רשת ניידת (למשל GSM, CDMA, LTE, NR) GSM או CDMA. מכשיר התומך ב"טלפוניה "עשוי לבחור להציע חלק משירותי השיחה, ההודעות והנתונים כמתאימים למוצר.
באמצעות רשת GSM או CDMA. אמנם שיחות קוליות אלה עשויות להיות מנות מנות, אך הן למטרות אנדרואיד הנחשבות ללא תלות בקישוריות נתונים שעשויה להיות מיושמת באמצעות אותה רשת. במילים אחרות, הפונקציונליות של אנדרואיד "טלפוניה" וממשקי API מתייחסים באופן ספציפי לשיחות קוליות ו- SMS. לדוגמה, יישומי מכשירים שאינם יכולים לבצע שיחות או לשלוח/לקבל הודעות SMS אינן נחשבות למכשיר טלפוניה, ללא קשר אם הם משתמשים ברשת סלולרית לצורך קישוריות נתונים.ראה עדכון
אם יישומי מכשירים כוללים תמיכה ב- 802.11 וחשפו את הפונקציונליות ליישום של צד שלישי, הם: הם:
- [C-1-4] חייב לתמוך ב- DNS Multicast (MDNs) ואסור לסנן מנות MDNS (224.0.0.251 או FF02 :: FB ) בכל עת של פעולה, כולל כאשר המסך אינו במצב פעיל, אלא אם כן יורד או ירידה או סינון מנות אלה נחוץ כדי להישאר בטווחי צריכת חשמל הנדרשים על ידי דרישות רגולטוריות החלות על שוק היעד.
עבור יישומי מכשירי טלוויזיה אנדרואיד, גם כאשר הם נמצאים במצבי כוח המתנה.
- [C-1-4] חייב לתמוך ב- DNS Multicast (MDNs) ואסור לסנן מנות MDNS (224.0.0.251 או FF02 :: FB ) בכל עת של פעולה, כולל כאשר המסך אינו במצב פעיל, אלא אם כן יורד או ירידה או סינון מנות אלה נחוץ כדי להישאר בטווחי צריכת חשמל הנדרשים על ידי דרישות רגולטוריות החלות על שוק היעד.
ראה עדכון
אם יישומי מכשירים מכריזים על Feature_bluetooth_le, הם: הם:
- [C-SR-2] מומלצים בחום למדוד ולפצות על קיזוז RX כדי להבטיח שהחציון BLE RSSI הוא -60dBM +/- 10 dB במרחק של 1M ממכשיר הפניה המשדר ב-
ADVERTISE_TX_POWER_HIGH
, שם מכוונים מכוונים כך שהם ב'מטוסים מקבילים 'עם מסכים הפונים לאותו כיוון. - [C-SR-3] מומלצים מאוד למדוד ולפצות על קיזוז TX כדי להבטיח שהחציון BLL RSSI הוא -60dBM +/- 10 dB בעת סריקה ממכשיר התייחסות ממוקם במרחק של 1 מ 'ומעבירים ב-
ADVERTISE_TX_POWER_HIGH
, שם מכשירים מכוונים כך שהם נמצאים ב'מטוסים מקבילים 'עם מסכים הפונים לאותו כיוון.
- [C-10-3] חייב למדוד ולפצות על קיזוז RX כדי להבטיח שהחציון BLE RSSI הוא -55dBM +/- 10 dB במרחק של 1M ממכשיר הפניה המשדר ב-
ADVERTISE_TX_POWER_HIGH
. - [C-10-4] חייב למדוד ולפצות על קיזוז TX כדי להבטיח שהחציון BLE RSSI הוא -55dBM +/- 10 dB בעת סריקה ממכשיר הפניה ממוקם במרחק של 1M ומשדר ב-
ADVERTISE_TX_POWER_HIGH
.
אם יישומי מכשירים תומכים ב- Bluetooth גרסה 5.0, אז הם:
- [C-SR-4] מומלץ מאוד לספק תמיכה ל:
- LE 2M PHY
- Le Codec Phy
- סיומת פרסום של LE
- פרסום תקופתי
- לפחות 10 ערכות פרסומת
- לפחות 8 חיבורים LE במקביל. כל חיבור יכול להיות בשני תפקידי טופולוגיה של חיבור.
- פרטיות שכבת קישור
- גודל "רשימת פיתרון" של לפחות 8 רשומות
- [C-SR-2] מומלצים בחום למדוד ולפצות על קיזוז RX כדי להבטיח שהחציון BLE RSSI הוא -60dBM +/- 10 dB במרחק של 1M ממכשיר הפניה המשדר ב-
ראה עדכון
- [C-1-7] חייב להבטיח כי החציון של מדידות המרחק בגובה 1 מ 'ממכשיר ההתייחסות הוא בתוך [0.75 מ', 1.25 מ '], שם נמדד מרחק האמת הקרקע מהקצה העליון של ה- DUT.
הפנים כלפי מעלה ומוטות 45 מעלות.
- [C-1-7] חייב להבטיח כי החציון של מדידות המרחק בגובה 1 מ 'ממכשיר ההתייחסות הוא בתוך [0.75 מ', 1.25 מ '], שם נמדד מרחק האמת הקרקע מהקצה העליון של ה- DUT.
ראה עדכון
מצלמה הפונה לאחור היא מצלמה הממוקמת בצד המכשיר מול התצוגה; כלומר, זה מציג סצינות בצד הרחוק של המכשיר, כמו מצלמה מסורתית.
מצלמה הפונה לאחור היא מצלמה הפונה לעולם שמציגה סצינות בצד הרחוק של המכשיר, כמו מצלמה מסורתית; במכשירי כף יד, זוהי מצלמה שנמצאת בצד המכשיר מול התצוגה.
ראה עדכון
מצלמה הפונה קדמית היא מצלמה הממוקמת באותו צד של המכשיר כמו התצוגה; כלומר, מצלמה המשמשת בדרך כלל לתמונת המשתמש, למשל עבור ועידת וידאו ויישומים דומים.
מצלמה הפונה קדמית היא מצלמה הפונה למשתמש המשמשת בדרך כלל לדימוי של המשתמש, כמו למשל עבור ועידת וידיאו ויישומים דומים; במכשירי כף יד, זוהי מצלמה הממוקמת באותו צד של המכשיר כמו התצוגה.
ראה עדכון
מצלמה חיצונית היא מצלמה שניתן לחבר או לנתק פיזית מיישום המכשיר בכל עת ויכולה להתמודד עם כל כיוון; כמו מצלמות USB.
ראה עדכון
יישומי מכשירים חייבים ליישם את ההתנהגויות הבאות עבור ממשקי ה- API הקשורים למצלמה, עבור כל המצלמות הזמינות. יישומי מכשירים:
- [C-SR-1] עבור מכשירים עם מצלמות RGB מרובות בסמיכות ופנים לאותו כיוון, מומלץ מאוד לתמוך במכשיר מצלמה לוגי המפרט יכולת
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, המורכב מכל מצלמות ה- RGB הפונות לכיוון זה בכיוון זה כיוון זה בכיוון זה בכיוון זה בכיוון זה בכיוון זה בכיוון זה בכיוון זה כמכוניות משנה פיזיות.
- [C-SR-1] עבור מכשירים עם מצלמות RGB מרובות בסמיכות ופנים לאותו כיוון, מומלץ מאוד לתמוך במכשיר מצלמה לוגי המפרט יכולת
ראה עדכון
מכשירים העומדים בכל הקריטריונים הבאים פטורים מהדרישה לעיל:
- יישומי מכשירים שאינם מסוגלים להסתובב על ידי המשתמש כמו מכשירי רכב.
ראה עדכון
מכשירים המיועדים להיות כף יד או שחוקים עשויים לכלול מפעיל מטרה כללי, העומד לרשות יישומים למטרות, כולל קבלת תשומת לב באמצעות רינגטונים, אזעקות, התראות וכן משוב כללי של מגע.
אם יישומי מכשירים אינם כוללים מפעיל מטרה כללי כזה, הם: הם:
- [7.10/c] חייב להחזיר שווא עבור
Vibrator.hasVibrator()
.
אם יישומי מכשירים אכן כוללים לפחות מפעיל האפטי מטרה כללי כזה, הם: הם:
- [C-1-1] חייב להחזיר נכון עבור
Vibrator.hasVibrator()
. - אסור להשתמש במפעיל המסה המסתובב האקסצנטרי (ERM) (ויברטור).
- צריך ליישם את כל הקבועים הציבוריים עבור Haptics ברורים ב-
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
andGESTURE_END
). - צריך ליישם את כל הקבועים הציבוריים עבור Haptics ברורים ב-
android.os.VibrationEffect
, כלומר (EFFECT_TICK
,EFFECT_CLICK
,EFFECT_HEAVY_CLICK
EFFECT_DOUBLE_CLICK
) וכל קבועיPRIMITIVE_*
ציבוריים בר ביצוע עבור Haptics עשירים ב-android.os.VibrationEffect.Composition
איות, לחץ (CLICK
,TICK
,LOW_TICK
,,QUICK_FALL
,QUICK_RISE
,SLOW_RISE
,SPIN
,THUD
). חלק מהפרימיטיביות הללו, כמוLOW_TICK
SPIN
עשויים להיות בר ביצוע רק אם הוויברטור יכול לתמוך בתדרים נמוכים יחסית. - SHOULD follow the guidance for mapping public constants in
android.view.HapticFeedbackConstants
to the recommendedandroid.os.VibrationEffect
constants, with the corresponding amplitude relationships. - SHOULD use these linked haptic constants mappings .
- SHOULD follow quality assessment for
createOneShot()
andcreateWaveform()
APIs. - SHOULD verify that the result of the public
android.os.Vibrator.hasAmplitudeControl()
API correctly reflects their vibrator's capabilities. - SHOULD verify the capabilities for amplitude scalability by running
android.os.Vibrator.hasAmplitudeControl()
.
If device implementations follow the haptic constants mapping, they:
- SHOULD verify the implementation status by running
android.os.Vibrator.areAllEffectsSupported()
andandroid.os.Vibrator.arePrimitivesSupported()
APIs. - SHOULD perform a quality assessment for haptic constants.
- SHOULD verify and update if needed the fallback configuration for unsupported primitives as described in the implementation guidance for constants.
- SHOULD provide fallback support to mitigate the risk of failure as described here .
See Section 2.2.1 for device-specific requirements.
- [7.10/c] חייב להחזיר שווא עבור
9. Security Model Compatibility
See revision
Device implementations:
- [C-0-4] MUST have one and only one implementation of both user interfaces.
If device implementations pre-install any packages that hold any of the System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence , or System Visual Intelligence roles, the packages:
- [C-4-1] MUST fulfill all requirements outlined for device implementations in sections
"9.8.6 Content Capture""9.8.6 OS-level and ambient data and 9.8.15 Sandboxed API implementations".
- [C-4-2] MUST NOT have android.permission.INTERNET permission. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
- [C-4-3] MUST NOT bind to other apps, except for the following system apps: Bluetooth, Contacts, Media, Telephony, SystemUI, and components providing Internet APIs. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
If device implementations include a default application to support the
VoiceInteractionService
they:- [C-5-1] MUST NOT grant
ACCESS_FINE_LOCATION
as the default for that application.
See revision
If device implementations create the additional user profile discussed above, then they:
- [C-4-5] MUST visually distinguish the dual instance application icons when the icons are presented to users.
- [C-4-6] MUST provide a user-affordance to delete entire clone profile data.
- [C-4-7] MUST uninstall all Clone apps, delete the private app data directories and their content, and delete Clone profile data, when the user chooses to delete entire Clone profile data.
- SHOULD prompt the user to delete entire Clone Profile data when the last clone app is deleted.
- [C-4-8] MUST inform the user that app data will be deleted when the clone application is uninstalled, or provide an option to users to keep app data when the application is uninstalled from the device.
- [C-4-9] MUST delete the private app data directories and their content, when the user chooses to delete the data during uninstall.
[C-4-1] MUST allow the below intents originating from the additional profile to be handled by applications of the primary user on the device:
-
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] MUST inherit all device policy user restrictions and selected non-user restrictions(list below) applied on the primary user of the device to this additional user profile.
[C-4-3] MUST only allow writing contacts from this additional profile via the following intents:
[C-4-4] MUST NOT have contact syncs running for applications running in this additional user profile.
- [C-4-14] MUST have separate permission and storage management for the applications running in this additional profile
- [C-4-5] MUST only allow applications in the additional profile that have a launcher activity to access contacts that are already accessible to the parent user profile.
See revision
A Memory Safety technology is a technology that mitigates at least the following classes of bugs with a high (> 90%) probability in applications that use the
android:memtagMode
manifest option:- heap buffer overflow
- use after free
- double free
- wild free (free of a non-malloc pointer)
Device implementations:
- [C-SR-15] Are STRONGLY RECOMMENDED to set
ro.arm64.memtag.bootctl_supported
.
If device implementations set the system property
ro.arm64.memtag.bootctl_supported
to true, they:[C-3-1] MUST allow the system property
arm64.memtag.bootctl
to accept a comma-separated list of the following values, with the desired effect applied on the next subsequent reboot:-
memtag
: a Memory Safety technology as defined above is enabled -
memtag-once
: a Memory Safety technology as defined above is transiently enabled, and is automatically disabled upon, next reboot -
memtag-off
: a Memory Safety technology as defined above is disabled
-
[C-3-2] MUST allow the shell user to set
arm64.memtag.bootctl
.[C-3-3] MUST allow any process to read
arm64.memtag.bootctl
.[C-3-4] MUST set
arm64.memtag.bootctl
to the currently requested state upon boot, it MUST also update the property, if the device implementation allows to modify the state without changing the system property.[C-SR-16] Are STRONGLY RECOMMENDED to show a Developer Setting that sets memtag-once and reboots the device. With a compatible bootloader, the Android Open Source Project meets the above requirements through the MTE bootloader protocol .
- [C-SR-17] Are STRONGLY RECOMMENDED to show a Setting in the Security Settings menu that allows the user to enable
memtag
.
See revision
Device implementations:
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
enabled that includes exactly the same message as AOSPwhenevereach and every time a session to capture the screencasting or screen recordingisenabledstarted via theMediaProjection.createVirtualDisplay()
,VirtualDeviceManager.createVirtualDisplay()
, or proprietary APIs.MUST NOT provide users an affordance to disable future display of the user consent.
[C-SR-1] Are STRONGLY RECOMMENDED to display a user warning which is exactly the same message as implemented in AOSP but CAN be altered as long as the message clearly warns the user that any sensitive information on the user's screen is captured.
[C-0-4] MUST NOT provide users an affordance to disable future prompts of the user consent to capture the screen, unless the session is started by a system app that the user has allowed to
associate()
with theandroid.app.role.COMPANION_DEVICE_APP_STREAMING
or theandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
device profile.
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
9.8.6. OS-level and ambient data : This section was renamed from Content Capture and App Search to OS-level and ambient data .
See revision
Android, through the System APIs
, supports a mechanism for device implementations to capture the followingContentCaptureService
,AugmentedAutofillService
,AppSearchGlobalManager.query
, or by other proprietary meansapplication data interactions between the applications and the usersensitive data :- Any screen or other data sent via the
AugmentedAutofillService
to the system. - Any screen or other data accessible via
Content Capture
API. - Any screen or other data accessible via
FieldClassificationService
API - Any application data passed to the system via the
AppSearchManager
API and accessible viaAppSearchGlobalManager.query
.
- Any other events that an application provides to the system via the
Content Capture
API or orAppSearchManager
API a similarly capable Android and proprietary API.
- Audio data obtained as a result of using
SpeechRecognizer#onDeviceSpeechRecognizer()
by the Speech Recognizer Implementation. - Audio data obtained in background (continuously) through
AudioRecord
,SoundTrigger
or other Audio APIs, and not resulting in a user-visible indicator - Camera data obtained in background (continuously) through CameraManager or other Camera APIs, and not resulting in a user-visible indicator
If device implementations capture any of the data above, they:
[C-1-3] MUST only send all such data
and the logoff the device using a privacy-preserving mechanism , except with explicit user consent every time the data is shared . The privacy-preserving mechanism is defined as “those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users”, to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such asRAPPOR
).[C-1-5] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.6
Content CaptureOS-level and ambient data ), except with explicit user consent every time it is מְשׁוּתָף. Unless such functionality is built as an Android SDK API (AmbientContext
,HotwordDetectionService
).[C-1-6] MUST provide user affordance to erase such data that the
implementation or the proprietary means collectsContentCaptureService
ifwhen the data is stored in any form on the device. If the user chooses to erase the data, MUST remove all collected historical data.
- [C-SR-3] Are STRONGLY RECOMMENDED to be implemented with Android SDK API or a similar OEM-owned open-source repository; and / or be performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementations).
Android, through
SpeechRecognizer#onDeviceSpeechRecognizer()
provides ability to perform speech recognition on the device, without involving the network. Any implementation of on-device SpeechRecognizer MUST follow the policies outlined in this section.- Any screen or other data sent via the
9.8.10. Connectivity Bug Report :
See revision
If device implementations declare the
android.hardware.telephony
feature flag, they:- [C-1-4] Reports generated using
BUGREPORT_MODE_TELEPHONY
MUST contain at least the following information:-
SubscriptionManagerService
dump
-
- [C-1-4] Reports generated using
9.8.14. Credential Manager : Removed
9.8.15. Sandboxed API Implementations : New section
See revision
Android, through a set of delegate APIs provides a mechanism to process secure OS-level and ambient data. Such processing can be delegated to a preinstalled apk with privileged access and reduced communication capabilities, known as a Sandboxed API Implementation.
Any Sandboxed API implementation:
- [C-0-1] MUST NOT request the INTERNET permission.
- [C-0-2] MUST only access the internet through structured APIs backed by publicly available open-source implementations using privacy-preserving mechanisms, or indirectly via Android SDK APIs. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST keep the services separate from other system components (eg not binding the service or sharing process IDs) except for the following:
- Telephony, Contacts, System UI, and Media
- [C-0-4] MUST NOT allow users to replace the services with a user-installable application or service
- [C-0-5] MUST only allow the preinstalled services to capture such data. Unless the replacement capability is built into AOSP (eg for Digital Assistant Apps).
- [C-0-6] MUST NOT allow any apps other than the preinstalled services mechanism to be able to capture such data. Unless such capture capability is implemented with an Android SDK API.
- [C-0-7] MUST provide user affordance to disable the services.
- [C-0-8] MUST NOT omit user affordance to manage Android permissions that are held by the services and follow the Android permissions model as described in Section 9.1. Permission .
9.8.16. Continuous Audio and Camera data : New section
See revision
In addition to requirements outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, and 9.8.15 Sandboxed API implementations, implementations that make use of Audio data obtained in background (continuously) through AudioRecord, SoundTrigger or other Audio APIs OR Camera data obtained in background (continuously) through CameraManager or other Camera APIs:
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
- This access is performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementation), through a package holding one or more of the following roles: System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence , or System Visual Intelligence .
- The access is performed through a sandbox, implemented and enforced via mechanisms in AOSP (
HotwordDetectionService
,WearableSensingService
,VisualQueryDetector
). - Audio access is performed for assistive purposes by the Digital Assistant application, supplying
SOURCE_HOTWORD
as an audio source. - The access is performed by the system and implemented with open-source code.
- [C-SR-1] Is STRONGLY RECOMMENDED to require user consent for every functionality utilizing such data, and be disabled by default.
- [C-SR-2] STRONGLY RECOMMENDED to apply the same treatment (ie follow the restrictions outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, 9.8.15 Sandboxed API implementations, and 9.8.16 Continuous Audio and Camera data) to Camera data coming from a remote wearable device.
If the Camera data is supplied from a remote wearable device and accessed in an unencrypted form outside Android OS, sandboxed implementation or a sandboxed functionality built by
WearableSensingManager
, then they:- [C-1-1] MUST indicate to the remote wearable device to display an additional indicator there.
If devices provide capability to engage with a Digital Assistant Application without the assigned keyword (either handling generic user queries, or analyzing user presence through camera):
- [C-2-1] MUST ensure such implementation is provided by a package holding the
android.app.role.ASSISTANT
role. - [C-2-2] MUST ensure such implementation utilizes
HotwordDetectionService
and/orVisualQueryDetectionService
Android APIs.
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
9.8.17. Telemetry : New section
See revision
Android stores system and app logs using StatsLog APIs. These logs are managed via StatsManager APIs which can be used by privileged system applications.
StatsManager also provides a way to collect data categorized as privacy sensitive from devices with a privacy preserving mechanism. In particular,
StatsManager::query
API provides the ability to query restricted metric categories defined in StatsLog .Any implementation querying and collecting restricted metrics from StatsManager:
- [C-0-1] MUST be the sole application/implementation on the device and hold the
READ_RESTRICTED_STATS
permission. - [C-0-2] MUST only send telemetry data and the log of the device using a privacy-preserving mechanism. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST NOT associate such data with any user identity (such as Account ) on the device.
- [C-0-4] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.17 Privacy-preserving Telemetry).
- [C-0-5] MUST provide a user affordance to enable/disable privacy-preserving telemetry collection, use, and sharing.
- [C-0-6] MUST provide user affordance to erase such data that the implementation collects if the data is stored in any form on the device. If the user chose to erase the data, MUST remove all data currently stored on the device.
- [C-0-7] MUST disclose underlying privacy-preserving protocol implementation in an open source repository.
- [C-0-8 ]MUST enforce data egress policies in this section to gate collection of data in restricted metric categories defined in StatsLog .
- [C-0-1] MUST be the sole application/implementation on the device and hold the
See revision
Device implementationsIf device implementations have the ability to verify file content on the per-page basis, then they :
[
C-0-3C-2-1 ] support cryptographically verifying file contentagainst a trusted keywithout reading the whole file.[
C-0-4C-2-2 ] MUST NOT allow the read requests on a protected file to succeed when the read contentdo not verify against a trusted keyis not verified per [C-2-1] above .
- [C-2-4] MUST return file checksum in O(1) for enabled files.
See revision
The Android Keystore System allows app developers to store cryptographic keys in a container and use them in cryptographic operations through the KeyChain API or the Keystore API . Device implementations:
- [C-0-3] MUST limit the number of failed primary authentication attempts.
- [C-SR-2] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations add or modify the authentication methods to unlock the lock screen if based on a known secret and use a new authentication method to be treated as a secure way to lock the screen, then:
- [C-SR-3] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-2-1] A PIN of a length less than 6 digits MUST NOT allow automatic entry without user interaction to avoid revealing the PIN length.
9.11.1. Secure Lock Screen, Authentication and Virtual Devices :
See revision
Device implementations:
- [C-0-1] MUST limit the number of failed primary authentication attempts.
- [C-SR-5] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations set a numerical PIN as the recommended primary authentication method, then:
- [C-SR-6] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-SR-7] A PIN of a length less than 6 digits is STRONGLY RECOMMENDED NOT to allow automatic entry without user interaction to avoid revealing the PIN length.
אם ליישומי מכשירים יש מסך נעילה מאובטח וכולל סוכן אמון אחד או יותר, אשר מיישם את ה- API של מערכת
TrustAgentService
, הם:[C-7-8] The user MUST be challenged for one of the recommended primary authentication (eg: PIN, pattern, password) methods at least once every 72 hours or less unless the safety of the user (eg driver distraction) is of דְאָגָה.If device implementations allow applications to create secondary virtual displays and support associated input events such as via VirtualDeviceManager and the displays are not marked with VIRTUAL_DISPLAY_FLAG_SECURE, they:
[C-13-10] MUST disable installation of apps initiated from virtual devices.9.17. Android Virtualization Framework :
See revision
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), the Android host:- [C-1-1] MUST support all the APIs defined by the
android.system.virtualmachine
package. - [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines (pVM) .
- [C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.
- [C-1-4] MUST only allow platform signed code & privileged apps
MUST NOT allow untrusted code (eg 3p apps)to create and run aProtected Virtual MachinepVM . Note: This might change in future Android releases.
- [C-1-5] MUST NOT allow a
Protected Virtual MachinepVM to execute code that is not part of the factory image or their updates.Anything that is not covered by Android Verified Boot (eg files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine.
- [C-1-5] MUST only allow a non-debuggable pVM to execute code from the factory image or their platform updates which also includes any updates to privileged apps.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then anyProtected Virtual MachinepVM instance:- [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a
Protected Virtual MachinepVM . - [C-2-2] MUST NOT allow a
Protected Virtual MachinepVM to run an operating system that is not signed by the device implementor or OS vendor. - [C-2-3] MUST NOT allow a
Protected Virtual MachinepVM to execute data as code (eg SELinux neverallow execmem).
- [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
- [C-2-5] MUST implement
Protected Virtual MachinepVM defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems. - [C-2-6] MUST ensure that the pVM fails
firmware refusesto boot ifit cannot verify the initialimages that the VM will run cannot be verified. The verification MUST be done inside the VM. - [C-2-7] MUST ensure that the pVM fails
firmware refusesto boot if the integrity of the instance.img is compromised.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then the hypervisor:- [C-3-1] MUST ensure that memory pages exclusively owned by a VM (either pVM or host VM) are accessible only to the virtual machine itself or the hypervisor, not by other virtual machines - either protected or non-protected.
MUST NOT allow any pVM to have access to a page belonging to another entity (ie other pVM or hypervisor), unless explicitly shared by the page owner. This includes the host VM. This applies to both CPU and DMA accesses. - [C-3-2] MUST wipe a page after it is used by a pVM and before it is returned to the host (eg the pVM is destroyed).
- [C-
3-3SR-1 ] Is STRONGLY RECOMMENDED to ensureMUST ensurethat that the pVM firmware is loaded and executed prior to any code in a pVM. - [C-3-4] MUST ensure that each VM derives a per-VM secret which
{Boot Certificate Chain (BCC) and Compound Device Identifier (CDIs) provided to a pVM instancecan only be derived by that particular VM instance and changes upon factory reset and OTA.
If the device implements support for the Android Virtualization Framework APIs, then across all areas:
- [C-4-1] MUST NOT provide functionality to a pVM that allows bypassing the Android Security Model.
If the device implements support for the Android Virtualization Framework APIs, then:
- [C-5-1] MUST be capable to support Isolated Compilation but may disable Isolated Compilation feature on the device shipment
of an ART runtime update.
If the device implements support for the Android Virtualization Framework APIs, then for Key Management:
- [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (To ensure it cannot be spoofed).
- [C- SR-2
6-2] Is STRONGLY RECOMMENDED to use DICE as the per-VM secret derivation mechanism.MUST do DICE properly ie provide the correct values.
- [C-1-1] MUST support all the APIs defined by the