1. מבוא
במסמך הזה מפורטות הדרישות שצריך לעמוד בהן כדי שהמכשירים יהיו תואמים ל-Android 14.
השימוש במילים 'חובה', 'אסור', 'נדרש', 'חייב', 'אסור', 'צריך', 'אסור', 'מומלץ', 'יכול להיות' ו'אופציונלי' הוא בהתאם לתקן IETF שמוגדר ב-RFC2119.
במסמך הזה, "מפתח מכשיר" או "מפתח" הוא אדם או ארגון שמפתחים פתרון חומרה/תוכנה שפועל ב-Android 14. 'הטמעה במכשיר' או 'הטמעה' היא הפתרון לחומרה או לתוכנה שפותח.
כדי להיחשב כתואם ל-Android 14, הטמעות במכשירים חייבות לעמוד בדרישות שמפורטות בהגדרת התאימות הזו, כולל מסמכים שצורפו באמצעות הפניה.
אם ההגדרה הזו או בדיקות התוכנה המתוארות בקטע 10 לא מתייחסות לנושא מסוים, לא ברורות או חלקיות, האחריות של מי שמטמיע את המכשיר היא לוודא שהוא תואם להטמעות הקיימות.
לכן, פרויקט הקוד הפתוח של Android הוא גם ההפניה וגם ההטמעה המועדפת של Android. אנחנו ממליצים מאוד למטמיעים של מכשירים לבסס את הטמעות שלהם, ככל האפשר, על קוד המקור 'במעלה הזרם' שזמין בפרויקט Android Open Source Project. באופן תיאורטי, אפשר להחליף חלק מהרכיבים בהטמעות חלופיות, אבל מומלץ מאוד לא לפעול לפי השיטה הזו, כי יהיה קשה יותר לעבור את בדיקות התוכנה. באחריות המטמיע לוודא תאימות התנהגות מלאה להטמעה הרגילה של Android, כולל חבילה לבדיקות תאימות (CTS) ומעבר לה. לסיום, חשוב לזכור שהמסמך הזה אוסר במפורש על החלפות ושינוי של רכיבים מסוימים.
מקורות מידע רבים שמקושרים במסמך הזה מגיעים ישירות או בעקיפין מ-Android SDK, והם יהיו זהים מבחינה פונקציונלית למידע שמופיע במסמכי התיעוד של ה-SDK הזה. במקרים שבהם הגדרת התאימות הזו או חבילת בדיקות התאימות לא תואמות למסמכי התיעוד של ה-SDK, מסמכי התיעוד של ה-SDK נחשבים למקוריים. כל הפרטים הטכניים שסופקו במשאבים המקושרים במסמך הזה נחשבים כחלק מההגדרה הזו של תאימות.
1.1 מבנה המסמך
1.1.1. דרישות לפי סוג מכשיר
קטע 2 מכיל את כל הדרישות שחלות על סוג מכשיר ספציפי. כל קטע משנה בקטע 2 מוקדש לסוג מכשיר ספציפי.
כל שאר הדרישות, שחלות באופן אוניברסלי על כל הטמעות במכשירי Android, מפורטות בקטעים שמופיעים אחרי קטע 2. הדרישות האלה נקראות במסמך הזה 'דרישות ליבה'.
1.1.2. מזהה הדרישה
מזהה הדרישה מוקצה לדרישות חובה.
- המזהה מוקצה לדרישות חובה בלבד.
- דרישות מומלצות מאוד מסומנות בתווית [SR], אבל לא מוקצה להן מזהה.
- המזהה מורכב מ : מזהה סוג המכשיר – מזהה התנאי – מזהה הדרישה (למשל, C-0-1).
כל מזהה מוגדר באופן הבא:
- מזהה סוג המכשיר (מידע נוסף זמין בקטע 2. סוגי מכשירים)
- C: ליבה (דרישות שחלות על כל ההטמעות במכשירי Android)
- H: מכשיר Android נייד
- T: מכשיר Android Television
- תשובה: הטמעה של 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 ניידים.
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
שזמין לאפליקציות של צד שלישי לאזור תצוגה פיזי ללא הפרעה, בגודל של לפחות 5.6 ס"מ בצד הקצר ו-8.6 ס"מ בצד הארוך.[7.1.1.3/H-0-1]* חובה להגדיר את הערך של
DENSITY_DEVICE_STABLE
כך שיהיה 92% או יותר מהצפיפות הפיזית בפועל של המסך התואם.
סיום הדרישות החדשות
אם הטמעות של מכשירים ניידים תומכות בסיבוב מסך בתוכנה, הן:
- [7.1.1.1/H-1-1]* חובה שהמסך הלוגי שזמין לאפליקציות של צד שלישי יהיה לפחות 5 ס"מ בצדדים הקצרים ו-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 ושל שלבי עיבוד (renderstages) של GPU שמוגדרים במסמכי העזרה של Perfetto.
- [7.1.4.6/H-1-2] חובה לדווח על ערכים תואמים למונה ה-GPU של המכשיר בהתאם ל-gpu counter trace packet proto.
- [7.1.4.6/H-1-3] חובה לדווח על ערכים תואמים של שלבי ה-Render של ה-GPU במכשיר בהתאם ל-proto של חבילות המעקב של שלבי ה-render.
- [7.1.4.6/H-1-4] חובה לדווח על נקודת מעקב של תדר GPU לפי הפורמט הבא: power/gpu_frequency.
הטמעות במכשירים ניידים:
- [7.1.5/H-0-1] חובה לכלול תמיכה במצב תאימות לאפליקציות מדור קודם כפי שהוטמע בקוד המקור הפתוח של 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, שבתנאי שדה פתוח אחרי שנקבע המיקום, במצב נייח או בתנועה עם פחות מ-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.
אם המכשירים תומכים בפרוטוקול WiFi 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 מטר ברוחב פס של 160 מגה-הרץ ב-68% (כפי שמחושב באמצעות פונקציית התפלגות מצטברת), +/-2 מטר ברוחב פס של 80 מגה-הרץ ב-68%, +/-4 מטר ברוחב פס של 40 מגה-הרץ ב-68% ו-+/-8 מטר ברוחב פס של 20 מגה-הרץ ב-68% במרחקים של 10 ס"מ, 1 מטר, 3 מטר ו-5 מטר, כפי שנצפה באמצעות WifiRttManager#startRanging Android API.
[7.4.2.5/H-SR-1] מומלץ מאוד לדווח על טווח מדויק בטווח של +/-1 מטר ברוחב פס של 160MHz ב-90% (כפי שמחושב באמצעות פונקציית התפלגות מצטברת), +/-2 מטר ברוחב פס של 80MHz ב-90%, +/-4 מטר ברוחב פס של 40MHz ב-90% ו-+/-8 מטר ברוחב פס של 20MHz ב-90% במרחק של 10 ס"מ, כפי שנצפה באמצעות WifiRttManager#startRanging Android API.
מומלץ מאוד לפעול לפי השלבים להגדרת המדידה שמפורטים במאמר כיול נוכחות.
יצירת דרישות חדשות
אם הטמעות של מכשירים ניידים מגדירות את FEATURE_BLUETOOTH_LE
, הן:
- [7.4.3/H-1-3] חובה למדוד את ההיסט של Rx ולבצע תיקון שלו כדי לוודא שהערך החציוני של RSSI ב-BLE הוא -50dBm +/-15 dB במרחק של 1 מ' ממכשיר העזרה שמשדר ב-
ADVERTISE_TX_POWER_HIGH
. - [7.4.3/H-1-4] חובה למדוד את ההיסט של ה-Tx ולבצע תיקון שלו כדי לוודא שהערך החציוני של ה-RSSI ב-BLE הוא -50dBm +/-15 dB כשמבצעים סריקה ממכשיר עזר שנמצא במרחק 1 מ' ומעביר במהירות
ADVERTISE_TX_POWER_HIGH
.
סיום הדרישות החדשות
אם הטמעות של מכשירים ניידים כוללות מכשיר מצלמה לוגי שמפרט את היכולות באמצעות CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, הן:
- ל-[7.5.4/H-1-1] חייב להיות שדה ראייה (FOV) רגיל כברירת מחדל, והוא חייב להיות בין 50 ל-90 מעלות.
הטמעות במכשירים ניידים:
- [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] אם ברזולוציות של מסך ברירת המחדל נעשה שימוש ב-framebuffer עד qHD (למשל FWVGA), נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 416MB.
[7.6.1/H-2-1] אם ברזולוציות של מסך ברירת המחדל נעשה שימוש ב-framebuffer עד HD+ (למשל, HD, WSVGA), נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 592MB.
[7.6.1/H-3-1] אם ברזולוציות של framebuffer של צג ברירת המחדל נעשה שימוש עד FHD (למשל, WSXGA+), נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 896MB.
[7.6.1/H-4-1] אם ברזולוציית המסך שמוגדרת כברירת מחדל נעשה שימוש ברזולוציות של framebuffer עד QHD (למשל QWXGA), נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 1,344MB.
אם הטמעות של מכשירי כף יד מכריזות על תמיכה ב-ABI כלשהו של 64 ביט (עם או בלי ABI של 32 ביט):
[7.6.1/H-5-1] אם ברזולוציית ברירת המחדל של המסך נעשה שימוש ברזולוציות של framebuffer עד qHD (למשל FWVGA), נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 816MB.
[7.6.1/H-6-1] אם ברזולוציות של מסך ברירת המחדל נעשה שימוש ב-framebuffer עד HD+ (למשל, HD, WSVGA), נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 944MB.
[7.6.1/H-7-1] אם ברזולוציות של framebuffer של צג ברירת המחדל נעשה שימוש ברזולוציות של עד FHD (למשל, WSXGA+), נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 1,280MB.
[7.6.1/H-8-1] אם ברזולוציות של מסך ברירת המחדל נעשה שימוש ברזולוציות של framebuffer עד QHD (למשל QWXGA), נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 1,824MB.
חשוב לזכור שהערך 'זיכרון שזמין לליבה ולמרחב המשתמש' מתייחס למרחב הזיכרון שסופק בנוסף לכל זיכרון שכבר הוקצה לרכיבי חומרה כמו רדיו, וידאו וכו', שלא נמצאים בשליטת הליבה בהטמעות במכשירים.
אם הטמעות במכשירים ניידים כוללות פחות מ-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] אסור לספק לאפליקציה אחסון משותף בנפח קטן מ-1GB.
- [7.7.1/H] צריכה לכלול יציאת USB שתומכת במצב ציוד היקפי.
אם הטמעות של מכשירים ניידים כוללות יציאת USB שתומכת במצב ציוד היקפי, הן:
- [7.7.1/H-1-1] חובה להטמיע את ה-API של Android Open Accessory (AOA).
אם הטמעות של מכשירים ניידים כוללות יציאת 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] חובה להצהיר על ה-feature flag
android.hardware.vr.high_performance
. - [7.9.1/H-1-2] חובה לכלול אפליקציה שמטמיעה את
android.service.vr.VrListenerService
, שאפשר להפעיל אותה באמצעות אפליקציות VR דרךandroid.app.Activity#setVrModeEnabled
.
אם הטמעות של מכשירים ניידים כוללות יציאת USB-C אחת או יותר במצב מארח ומטמיעות (USB audio class), בנוסף לדרישות שמפורטות בקטע 7.7.2, הן:
- [7.8.2.2/H-1-1] חובה לספק את המיפוי הבא של קודי HID בתוכנה:
פעולה | מיפויים | הקשר | התנהגות |
---|---|---|---|
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 בצורה נכונה כדי לזהות את סוג המסוף המחובר.
כשמזוהה מסוף אודיו מסוג USB עם הקוד 0x0302, הם:
- [7.8.2.2/H-2-1] חובה לשדר את ה-Intent ACTION_HEADSET_PLUG עם הערך הנוסף 'microphone' מוגדר ל-0.
כשמתבצעת זיהוי של מסוף אודיו מסוג USB 0x0402, הוא:
- [7.8.2.2/H-3-1] חובה לשדר את ה-Intent ACTION_HEADSET_PLUG עם הערך הנוסף 'microphone' שמוגדר כ-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 ו-role 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, לזהות סוגי מסופים ולשדר את ה-Intent ACTION_HEADSET_PLUG תוך פחות מ-1, 000 אלפיות שנייה כשמחברים ציוד היקפי של אודיו מסוג USB-C.
אם הטמעות של מכשירי כף יד מגדירות את 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, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START ו-GESTURE_END).
- [7.10/H]* צריך להטמיע את כל הקבועים הציבוריים של רטט ברור ב-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, יכולות להתבצע רק אם הוויברטור יכול לתמוך בתדרים נמוכים יחסית. - [7.10/H]* צריך לפעול לפי ההנחיות למיפוי של קבועים ציבוריים ב-android.view.HapticFeedbackConstants לקבועים המומלצים של android.os.VibrationEffect, עם יחסי האמפליטודה המתאימים.
- [7.10/H]* צריך לפעול בהתאם לבדיקת האיכות של ממשקי ה-API createOneShot() ו-createWaveform().
- [7.10/H]* צריך לוודא שהתוצאה של ממשק ה-API הציבורי android.os.Vibrator.hasAmplitudeControl() משקפת בצורה נכונה את היכולות של הוויברטור.
- [7.10/H]* צריך למקם את המפעיל ליד המיקום שבו המכשיר בדרך כלל מוחזק או נגע בו בידיים.
מפעיל רטט לינארי (LRA) הוא מערכת קפיץ עם מסה אחת, שיש לה תדר רטט דומיננטי שבו המסה מתרגמת בכיוון התנועה הרצויה.
אם הטמעות של מכשירים ניידים כוללות לפחות 7.10 אקטואטור לינארי רטטני למטרות כלליות, הן:
יצירת דרישות חדשות
- [7.10/H] מומלץ למקם את המפעיל ליד המיקום שבו המכשיר בדרך כלל מוחזק או נגע בו בידיים.
סיום הדרישות החדשות
- [7.10/H]
יש להזיז את המפעיל החשמלי של האפקט הרטט בציר X
(שמאל-ימין) של הכיוון הטבעי
לאורךשל המכשיר.
אם להטמעות של מכשירים ניידים יש מפעיל חישה כללי שהוא מפעיל תהוד לינארי בציר X (LRA), הן:
- [7.10/H] התדר הרטט של LRA בציר X צריך להיות מתחת ל-200Hz.
אם הטמעות במכשירים ניידים פועלות לפי מיפוי של קבועים של משוב מישוש, הן:
- [7.10/H]* צריך לאמת את סטטוס ההטמעה על ידי הפעלת ממשקי ה-API android.os.Vibrator.areAllEffectsSupported() ו-android.os.Vibrator.arePrimitivesSupported().
[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 משופר עם זמן אחזור קצר)
בהטמעות של מכשירים ניידים חייבת להיות תמיכה בפורמטים הבאים של קידוד וידאו, והם חייבים להיות זמינים לאפליקציות של צד שלישי:
בהטמעות של מכשירים ניידים חייבת להיות תמיכה בפורמטים הבאים של פענוח וידאו, והם חייבים להיות זמינים לאפליקציות של צד שלישי:
2.2.3. תוכנות
הטמעות במכשירים ניידים:
- [3.2.3.1/H-0-1] חובה שתהיה אפליקציה שמטפלת בכוונות (intents)
ACTION_GET_CONTENT
,ACTION_OPEN_DOCUMENT
,ACTION_OPEN_DOCUMENT_TREE
ו-ACTION_CREATE_DOCUMENT
כפי שמתואר במסמכי ה-SDK, ומספקת למשתמש אפשרות לגשת לנתונים של ספק המסמכים באמצעות ה-API שלDocumentsProvider
. - [3.2.3.1/H-0-2]* חובה לטעון מראש אפליקציה אחת או יותר או רכיבי שירות עם טיפול ב-Intent, לכל דפוסי המסננים הציבוריים של ה-Intent שמוגדרים על ידי כוונות האפליקציה הבאות שמפורטות כאן.
- [3.2.3.1/H-SR-1] מומלץ מאוד לטעון מראש אפליקציית אימייל שיכולה לטפל בכוונות ACTION_SENDTO או ACTION_SEND או ACTION_SEND_MULTIPLE לשליחת אימייל.
- [3.4.1/H-0-1] חובה לספק הטמעה מלאה של ה-API של
android.webkit.Webview
. - [3.4.2/H-0-1] חובה לכלול אפליקציית דפדפן נפרדת לגלישה באינטרנט של משתמשים רגילים.
- [3.8.1/H-SR-1] מומלץ מאוד להטמיע מרכז אפליקציות שמוגדר כברירת מחדל ותומך בהצמדה של קיצורי דרך, ווידג'טים ו-widgetFeatures בתוך האפליקציה.
- [3.8.1/H-SR-2] מומלץ מאוד להטמיע מרכז אפליקציות שמספק גישה מהירה למקשי הקיצור הנוספים שסופקו על ידי אפליקציות צד שלישי באמצעות ה-API של ShortcutManager.
- [3.8.1/H-SR-3] מומלץ מאוד לכלול אפליקציית מרכז אפליקציות שמוגדרת כברירת מחדל ומציגה תגים לסמלי האפליקציות.
- [3.8.2/H-SR-1] מומלץ מאוד לתמוך בווידג'טים של אפליקציות צד שלישי.
- [3.8.3/H-0-1] חובה לאפשר לאפליקציות צד שלישי להודיע למשתמשים על אירועים משמעותיים באמצעות כיתות ה-API
Notification
ו-NotificationManager
. - [3.8.3/H-0-2] חובה לתמוך בהתראות עשירות.
- [3.8.3/H-0-3] חובה לתמוך בהתראות מראש.
- [3.8.3/H-0-4] חובה לכלול חלונית התראות, שמאפשרת למשתמש לשלוט ישירות בהתראות (למשל, להשיב, לדחות לזמן מה, לסגור או לחסום) באמצעות רכיבי ממשק משתמש כמו לחצני פעולה או לוח הבקרה כפי שהוטמע ב-AOSP.
- [3.8.3/H-0-5] חובה להציג את האפשרויות שסופקו דרך
RemoteInput.Builder setChoices()
בחלונית ההתראות. - [3.8.3/H-SR-1] מומלץ מאוד להציג את האפשרות הראשונה שצוינה באמצעות
RemoteInput.Builder setChoices()
בחלונית ההתראות, ללא אינטראקציה נוספת של המשתמש. - [3.8.3/H-SR-2] מומלץ מאוד להציג את כל האפשרויות שמוצגות דרך
RemoteInput.Builder setChoices()
בלוח ההתראות כשהמשתמש מרחב את כל ההתראות בלוח ההתראות. - [3.8.3.1/H-SR-1] מומלץ מאוד להציג פעולות ש-
Notification.Action.Builder.setContextual
מוגדר בהן כ-true
, בהתאם לתשובות שמוצגות על ידיNotification.Remoteinput.Builder.setChoices
. - [3.8.4/H-SR-1] מומלץ מאוד להטמיע עוזרת במכשיר כדי לטפל בפעולת העזרה.
אם הטמעות במכשירים ניידים תומכות בהתראות בסגנון 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
, או פעילות שמטפלת ב-IntentACTION_ASSIST
.
אם הטמעות במכשירים ניידים תומכות בconversation notifications
ומקבצות אותן בקטע נפרד מהתראות ומהתראות שקשות שאינן שיחות, הן:
- [3.8.4/H-1-1]* חובה להציג התראות על שיחות לפני התראות אחרות, מלבד התראות על שירותים שפועלים בחזית והתראות importance:high.
אם הטמעות של מכשירי Android ניידים תומכות במסך נעילה, הן:
- [3.8.10/H-1-1] חובה להציג את ההתראות במסך הנעילה, כולל תבנית ההתראות של המדיה.
אם הטמעות של מכשירים ניידים תומכות במסך נעילה מאובטח, הן:
- [3.9/H-1-1] חובה להטמיע את כל המדיניות של ניהול המכשיר שמוגדרת במסמכי התיעוד של Android SDK.
אם הטמעות של מכשירים ניידים כוללות תמיכה בממשקי ה-API ControlsProviderService
ו-Control
, ומאפשרות לאפליקציות של צד שלישי לפרסם אמצעי בקרה למכשיר, הן:
- [3.8.16/H-1-1] חובה להצהיר על דגל התכונה
android.software.controls
ולהגדיר אותו כ-true
. - [3.8.16/H-1-2] חובה לספק למשתמש אפשרות להוסיף, לערוך, לבחור ולהפעיל את אמצעי הבקרה המועדפים עליו במכשיר, מתוך אמצעי הבקרה שרשומים באפליקציות של צד שלישי דרך ממשקי ה-API
ControlsProviderService
ו-Control
. - [3.8.16/H-1-3] חובה לספק גישה לאפשרות הזו של המשתמש תוך שלוש אינטראקציות ממרכז האפליקציות שמוגדר כברירת מחדל.
[3.8.16/H-1-4] חובה להציג בצורה מדויקת בממשק המשתמש הזה את השם והסמל של כל אפליקציית צד שלישי שמספקת אמצעי בקרה דרך ה-API של
ControlsProviderService
, וכן את כל השדות שצוינו על ידי ממשקי ה-API שלControl
.[3.8.16/H-1-5] חובה לספק למשתמש אפשרות לבטל את ההסכמה לשימוש באמצעי בקרה על מכשירים שנועדו לאימות טריוויאלי של אפליקציות, מתוך אמצעי הבקרה שנרשמו על ידי אפליקציות הצד השלישי דרך
ControlsProviderService
ו-Control.isAuthRequired
API שלControl
.
יצירת דרישות חדשות
- [3.8.16/H-1-6] הטמעות במכשירים חייבות להציג את היכולת של המשתמש בצורה מדויקת באופן הבא:
- אם במכשיר מוגדר
config_supportsMultiWindow=true
והאפליקציה מצהירה על המטא-נתוניםMETA_DATA_PANEL_ACTIVITY
בהצהרהControlsProviderService
, כולל ComponentName של פעילות חוקית (כפי שמוגדרת ב-API), האפליקציה חייבת להטמיע את הפעילות הזו בממשק המשתמש הזה. - אם האפליקציה לא מצהירה על מטא-נתונים
META_DATA_PANEL_ACTIVITY
, היא חייבת להציג את השדות שצוינו כפי שסופקו על ידי ממשק ה-APIControlsProviderService
, וגם את כל השדות שצוינו כפי שסופקו על ידי ממשקי ה-API של Control.
- אם במכשיר מוגדר
- [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
עבור ממשקי ה-API שלControlsProviderService
ושלControl
. - [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 ו'גישה באמצעות מתג' (בשפות שנתמכות במנוע ההמרה מראש של טקסט לדיבור), או שירותי נגישות עם פונקציונליות טובה יותר, כפי שמפורט בפרויקט הקוד הפתוח של 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 של זיכרון שזמין לליבה ולמרחב המשתמש, הן:
- [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
ולהפעיל את המצלמה במצב תמונה סטילס כפי שמתואר ב-SDK. - [7.5.4/H-1-2] חובה לפעול בהתאם לכוונה של
android.media.action.VIDEO_CAMERA
להפעיל את המצלמה במצב וידאו, כפי שמתואר ב-SDK.
אם אפליקציית ההגדרות של הטמעת המכשיר מטמיעה פונקציונליות מפוצלת באמצעות הטמעת פעילות, אז:
- [3.2.3.1/ H-1-1] חייבת להיות פעילות שמטפלת בכוונה Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY כשפונקציונליות הפיצול מופעלת. חובה להגן על הפעילות באמצעות
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
, והיא חייבת להפעיל את הפעילות של ה-Intent שעבר ניתוח מ-Settings#EXTRA_SETTINGS_EMBEDDED_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/s.
- [8.2/H-0-2] חובה להבטיח ביצועי כתיבה אקראיים של לפחות 0.5MB/s.
- [8.2/H-0-3] חובה להבטיח ביצועי קריאה רציפים של לפחות 15MB/s.
- [8.2/H-0-4] חובה להבטיח ביצועי קריאה אקראית של לפחות 3.5MB/s.
אם הטמעות של מכשירים ניידים כוללות תכונות לשיפור ניהול צריכת החשמל במכשיר שנכללות ב-AOSP או להרחבת התכונות שנכללות ב-AOSP, הן:
- [8.3/H-1-1] חובה לספק למשתמש אפשרות להפעיל ולהשבית את התכונה 'חיסכון בסוללה'.
- [8.3/H-1-2] חובה לספק למשתמשים אפשרות להציג את כל האפליקציות שפטורות ממצבי חיסכון באנרגיה 'המתנה לאפליקציה' ו'שינה עמוקה'.
הטמעות במכשירים ניידים:
- [8.4/H-0-1] חובה לספק פרופיל צריכת אנרגיה לכל רכיב, שמגדיר את ערך הצריכה הנוכחית של כל רכיב חומרה ואת הירידה המשוערת בנפח הסוללה שנגרמת על ידי הרכיבים לאורך זמן, כפי שמופיע באתר של Android Open Source Project.
- [8.4/H-0-2] חובה לדווח על כל ערכי צריכת האנרגיה בשעות מיליאמפר (mAh).
- [8.4/H-0-3] חובה לדווח על צריכת החשמל של המעבד לכל מזהה משתמש (UID) של תהליך. פרויקט הקוד הפתוח של Android עומד בדרישות באמצעות הטמעת מודול הליבה
uid_cputime
. - [8.4/H-0-4] חייבים להפוך את צריכת האנרגיה הזו לזמינה למפתח האפליקציה באמצעות הפקודה
adb shell dumpsys batterystats
במעטפת. - [8.4/H] צריך לשייך לרכיב החומרה עצמו אם לא ניתן לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.
אם הטמעות של מכשירים ניידים כוללות מסך או פלט וידאו, הן:
- [8.4/H-1-1] חובה לפעול בהתאם לכוונה של
android.intent.action.POWER_USAGE_SUMMARY
ולהציג תפריט הגדרות שבו מוצג השימוש בחשמל.
הטמעות במכשירים ניידים:
- [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 כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בליבה ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד הליבה או קוד מרחב המשתמש עשוי לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. בפרויקט Android Open Source (AOSP) ב-upstream מתקיימים הדרישות האלה באמצעות ההטמעה של Trusty, אבל יש גם אפשרויות חלופיות: פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת של בידוד תקין שמבוסס על hypervisor, שעבר בדיקה על ידי צד שלישי.
- [9.11/H-0-4] חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק אם הוא מצליח, לאפשר שימוש במפתחות שמקושרים לאימות. חובה לאחסן את פרטי הכניסה של מסך הנעילה באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. בפרויקט הקוד הפתוח של Android תוכלו למצוא את שכבת האובייקטים המצומצמים לחומרה (HAL) של Gatekeeper ו-Trusty, שאפשר להשתמש בהם כדי לעמוד בדרישות האלה.
- [9.11/H-0-5] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה לאימות מוגן על ידי חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה לאימות במספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת מהדרכים לעמוד בדרישות האלה היא לשתף את אותו מפתח אימות, אלא אם מיוצרות לפחות 100,000 יחידות של מק"ט נתון. אם מיוצרות יותר מ-100,000 יחידות של מק"ט מסוים, יכול להיות שייעשה שימוש במפתח שונה לכל 100,000 יחידות.
הערה: אם הטמעת מכשיר כבר הופעלה בגרסה קודמת של Android, המכשיר הזה פטור מהדרישה לכלול מאגר מפתחות שמגודר על ידי סביבת הפעלה מבודדת ולתמוך באימות המפתחות, אלא אם הוא מצהיר על התכונה android.hardware.fingerprint
, שדורשת מאגר מפתחות שמגודר על ידי סביבת הפעלה מבודדת.
כשהטמעות של מכשירים ניידים תומכות במסך נעילה מאובטח, הן:
- [9.11/H-1-1] חובה לאפשר למשתמש לבחור את זמן הקצוב הקצר ביותר למצב שינה, כלומר זמן המעבר ממצב פתוח למצב נעול, של 15 שניות או פחות.
- [9.11/H-1-2] חובה לספק למשתמש אפשרות להסתיר התראות ולהשבית את כל סוגי האימות, מלבד האימות הראשי שמתואר בקטע 9.11.1 מסך נעילה מאובטח. גרסת AOSP עומדת בדרישות כמצב נעילה.
יצירת דרישות חדשות
אם למכשירים יש נעילת מסך מאובטחת והם כוללים סוכן אמון אחד או יותר שמטמיע את System API של TrustAgentService
, הם:
- [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 APIHotwordDetectionService
או במנגנון דומה לזיהוי מילת הפעלה ללא אינדיקציה לשימוש במיקרופון, האפליקציה:
- [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()
, יחד עם הודעות שיוך שמשויכות אליהן.
אם הטמעות של מכשירים ניידים מגדירות את android.hardware.camera.any
, הן:
- [9.8.2/H-5-1] חובה להציג את אינדיקטור המצלמה כשאפליקציה ניגשת לנתוני מצלמה בשידור חי, אבל לא כשאפליקציות עם התפקידים שמפורטים בקטע 9.1 עם מזהה CDD [C-4-X] ניגשות למצלמה בלבד.
- [9.8.2/H-5-2] חובה להציג את האפליקציות האחרונות והפעילות באמצעות המצלמה, כפי שהן מופיעות ב-
PermissionManager.getIndicatorAppOpUsageData()
, יחד עם הודעות שיוך שמשויכות אליהן.
2.2.6. תאימות של כלים ואפשרויות למפתחים
הטמעות במכשירים ניידים (* לא רלוונטי לטאבלטים):
- [6.1/H-0-1]* חייב לתמוך בפקודת המעטפת
cmd testharness
.
הטמעות במכשירים ניידים (* לא רלוונטי לטאבלטים):
- Perfetto
- [6.1/H-0-2]* חובה לחשוף למשתמש המעטפת קובץ בינארי של
/system/bin/perfetto
, שבו שורת הפקודה תואמת למסמכי התיעוד של perfetto. - [6.1/H-0-3]* קובץ הבינארי של perfetto חייב לקבל כקלט קובץ תצורה של protobuf שתואם לסכימה שמוגדרת במסמכי התיעוד של perfetto.
- [6.1/H-0-4]* קובץ הבינארי של perfetto חייב לכתוב כפלט מעקב protobuf שתואם לסכימה שמוגדרת במסמכי התיעוד של perfetto.
- [6.1/H-0-5]* חובה לספק, באמצעות הקובץ הבינארי של perfetto, לפחות את מקורות הנתונים שמתוארים במסמכי התיעוד של perfetto.
- [6.1/H-0-6]* צריך להפעיל את הדימון של מעקב ה-perfetto כברירת מחדל (מאפיין המערכת
persist.traced.enable
).
- [6.1/H-0-2]* חובה לחשוף למשתמש המעטפת קובץ בינארי של
2.2.7. סיווג הביצועים של מדיה בנייד
ההגדרה של סיווג הביצועים של מדיה מפורטת בקטע 7.11.
2.2.7.1. מדיה
אם הטמעות של מכשירי כף יד מחזירות את הערך android.os.Build.VERSION_CODES.T
עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, המשמעות היא שהן:
- חייבת לעמוד בדרישות המדיה המפורטות בסעיף 2.2.7.1 ב-CDD של Android 13.
יצירת דרישות חדשות
אם הטמעות של מכשירי כף יד מחזירות את הערך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@30fps ו-3 סשנים ברזולוציה של 4K@30fps. קודקים של AV1 נדרשים לתמוך רק ברזולוציה של 1080p, אבל עדיין נדרשים לתמוך ב-6 מופעים בקצב פריימים של 1080p30.
- [5.1/H-1-3] חובה לפרסם את המספר המקסימלי של סשנים של מקודד וידאו לחומרה שאפשר להריץ בו-זמנית בכל שילוב של קודק באמצעות השיטות
CodecCapabilities.getMaxSupportedInstances()
ו-VideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-4] חובה לתמוך ב-6 מופעים של סשנים של קודק וידאו לחומרה של 8 ביט (SDR) (AVC, HEVC, VP9, AV1 או גרסאות מתקדמות יותר) בכל שילוב של קודקים שפועלים בו-זמנית עם 4 סשנים ברזולוציה 1080p@30fps ו-2 סשנים ברזולוציה 4K@30fps. קודקים של AV1 נדרשים לתמוך רק ברזולוציה של 1080p, אבל עדיין נדרשים לתמוך ב-6 מופעים בקצב פריימים של 1080p30.
- [5.1/H-1-5] חובה לפרסם את המספר המקסימלי של סשנים של מקודד וידאו לחומרה ושל מפענח וידאו לחומרה שאפשר להריץ בו-זמנית בכל שילוב של קודק באמצעות השיטות
CodecCapabilities.getMaxSupportedInstances()
ו-VideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-6] חובה לתמוך ב-6 מופעים של ממיר וידאו לחומרה של 8 ביט (SDR) ובסשנים של מקודד וידאו לחומרה (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב של קודקים שפועלים בו-זמנית עם 3 סשנים ברזולוציה 4K@30fps, מתוכם לכל היותר 2 סשנים של מקודד ו-3 סשנים ברזולוציה 1080p. קודקים של AV1 נדרשים לתמוך רק ברזולוציה של 1080p, אבל עדיין נדרשים לתמוך ב-6 מופעים בקצב פריימים של 1080p30.
- [5.1/H-1-19] חובה לתמוך ב-3 מופעים של ממיר וידאו לחומרה באיכות 10 ביט (HDR) ובסשנים של מקודד וידאו לחומרה (AVC, HEVC, VP9, AV1 או גרסאות מתקדמות יותר) בכל שילוב של קודקים שפועלים בו-זמנית ברזולוציה של 4K@30fps, מתוכם מקסימום סשן אחד של מקודד, שניתן להגדיר בפורמט קלט RGBA_1010102 דרך משטח GL. אין צורך ביצירת מטא-נתונים של HDR על ידי המקודד אם מבצעים קידוד מפני השטח של GL. סשנים של קודק AV1 נדרשים לתמוך רק ברזולוציה של 1080p, גם אם הדרישה היא 4K.
- [5.1/H-1-7] זמן האחזור להפעלת הקודק חייב להיות 40 אלפיות השנייה או פחות בסשן קידוד וידאו ברזולוציה של 1080p או פחות, לכל מקודדי הווידאו בחומרה במצב עומס. העומס מוגדר כאן כסשן המרה בו-זמנית של וידאו בלבד מ-1080p ל-720p באמצעות רכיבי קודק וידאו בחומרה, יחד עם האתחול של ההקלטה של אודיו ווידאו ב-1080p. בקודק Dolby Vision, זמן האחזור להפעלת הקודק חייב להיות 50 אלפיות השנייה או פחות.
- [5.1/H-1-8] זמן האחזור להפעלת הקודק חייב להיות 30 אלפיות השנייה או פחות בסשן קידוד אודיו בקצב העברת נתונים של 128kbps או פחות, לכל מקודדי האודיו במצב עומס. העומס מוגדר כאן כסשן המרה בו-זמנית של וידאו בלבד מ-1080p ל-720p באמצעות רכיבי קודק וידאו בחומרה, יחד עם האתחול של ההקלטה של אודיו ווידאו ב-1080p.
- [5.1/H-1-9] חייב לתמוך ב-2 מופעים של סשנים מאובטחים של מקודד וידאו בחומרה (AVC, HEVC, VP9, AV1 או גרסאות מתקדמות יותר) בכל שילוב של קודקים שפועלים בו-זמנית ברזולוציה של 1080p@30fps, גם לתוכן 8-bit (SDR) וגם לתוכן HDR 10-bit.
- [5.1/H-1-10] חובה לתמוך ב-3 מופעים של סשנים של מפענח וידאו בחומרה לא מאובטח יחד עם מופע אחד של סשן של מפענח וידאו מאובטח בחומרה (סה"כ 4 מופעים) (AVC, HEVC, VP9, AV1 או גרסאות מתקדמות יותר) בכל שילוב של קודקים שפועלים בו-זמנית עם 3 סשנים ברזולוציית 4K@30fps, כולל סשן אחד של מפענח מאובטח וסשן אחד של מפענח לא מאובטח ברזולוציית 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, זמן האחזור להפעלת הקודק חייב להיות 50 אלפיות השנייה או פחות.
- [5.1/H-1-13] זמן האחזור להפעלת הקודק חייב להיות 30 אלפיות השנייה או פחות בסשן של פענוח אודיו בקצב העברת נתונים של 128kbps או פחות, לכל מפענח האודיו במצב עומס. העומס מוגדר כאן כסשן המרה בו-זמנית של וידאו בלבד מ-1080p ל-720p באמצעות רכיבי קודק וידאו בחומרה, יחד עם האתחול של ההפעלה של אודיו ווידאו ב-1080p.
- [5.1/H-1-14] חובה לתמוך בפענח חומרה של AV1 Main 10, ברמה 4.1 ובגרעין של סרט.
- [5.1/H-1-15] חובה שיהיה לפחות ממיר וידאו אחד לחומרה שתומך ב-4K60.
- [5.1/H-1-16] חובה שיהיה לפחות מקודד וידאו אחד לחומרה שתומך ב-4K60.
- [5.3/H-1-1] אסור שיהיו יותר מפריים אחד שנופל ב-10 שניות (כלומר פחות מ-0.167 אחוז ירידה בפריימים) בסשן וידאו של 4K ב-60fps במצב עומס.
- [5.3/H-1-2] אסור להחמיץ יותר מפריים אחד ב-10 שניות במהלך שינוי ברזולוציית הווידאו בסשן וידאו של 60fps בעומס, עבור סשן 4K.
- [5.6/H-1-1] זמן האחזור של הקשה לצלצול חייב להיות 80 אלפיות השנייה או פחות באמצעות בדיקת הקשה לצלצול של CTS Verifier.
- [5.6/H-1-2] זמן האחזור של האודיו הלוך ושוב חייב להיות 80 אלפיות השנייה או פחות, דרך לפחות נתיב נתונים נתמך אחד.
- [5.6/H-1-3] חובה לתמוך באודיו של 24 ביט לפחות עבור פלט סטריאו דרך שקעי אודיו בגודל 3.5 מ "מ, אם יש כאלה, דרך אודיו USB, אם יש תמיכה לאורך כל נתיב הנתונים, עבור הגדרות סטרימינג וזמן אחזור קצר. בתצורה של זמן אחזור קצר, האפליקציה צריכה להשתמש ב-AAudio במצב קריאה חוזרת (callback) עם זמן אחזור קצר. בהגדרת הסטרימינג, האפליקציה צריכה להשתמש ב-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 ערוצים. המשמעות היא שאפשר לפתוח 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
עם יכולות הפענוח הבאות של תוכן.
גודל מינימלי של דגימה | 4MB |
מספר מינימלי של דגימות משנה – H264 או HEVC | 32 |
מספר מינימלי של דגימות משנה – VP9 | 9 |
מספר מינימלי של דגימות משנה – AV1 | 288 |
גודל שטח האחסון הזמני המינימלי של תמונת המשנה | 1MB |
גודל מינימלי של מאגר קריפטוגרפיה גנרי | 500 KiB |
מספר מינימלי של סשנים בו-זמניים | 30 |
מספר מפתחות מינימלי לכל סשן | 20 |
מספר מפתחות מינימלי כולל (כל הסשנים) | 80 |
המספר הכולל המינימלי של מפתחות DRM (כל הסשנים) | 6 |
גודל ההודעה | 16 KiB |
פריימים מוצפנים לשנייה | 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), ולפחות 2 מהן צריכות להיות מסוגלות להציג תוכן וידאו של 10 ביט.
אם הטמעות של מכשירים ניידים מחזירות את הערך android.os.Build.VERSION_CODES.U
עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
וכוללות תמיכה במקודד חומרה של AVC או HEVC, הן:
- [5.2/H-2-1] חייב לעמוד ביעד האיכות המינימלי שמוגדר על ידי עקומות ההפרעה-קצב הקידוד של מכשיר הקידוד של הווידאו, עבור קודיקים של חומרה מסוג AVC ו-HEVC, כפי שמוגדר בבדיקות של סיווג הביצועים 14 (PC14) – איכות קידוד הווידאו (VEQ).
סיום הדרישות החדשות
2.2.7.2. מצלמה
אם הטמעות של מכשירי כף יד מחזירות את הערך android.os.Build.VERSION_CODES.T
עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, המשמעות היא שהן:
- חייבת לעמוד בדרישות המדיה המפורטות בסעיף 2.2.7.2 ב-CDD של Android 13.
יצירת דרישות חדשות
אם הטמעות של מכשירי כף יד מחזירות את הערך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 במצלמה 2 חייב להיות קטן מ-1000
900אלפיות השנייה ברזולוציה של 1080p, כפי שנמדד על ידי בדיקת הביצועים של המצלמה ב-CTS בתנאים של תאורה ITS (3000K) בשתי המצלמות הראשיות. - [7.5/H-1-6] זמן האחזור של הפעלת המצלמה השנייה (פתיחת המצלמה עד לפריים הראשון בתצוגה המקדימה) חייב להיות קטן מ-500 אלפיות השנייה, כפי שנמדד על ידי בדיקת הביצועים של מצלמת 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
במצלמה האחורית הראשית אם יש יותר ממצלמה אחורית אחת מסוג RGB. - [7.5/H-1-14] חובה לתמוך ביכולת
STREAM_USE_CASE
גם במצלמה הקדמית הראשית וגם במצלמה האחורית הראשית. - [7.5/H-1-15] חובה לתמוך ב
תוספים של מצב לילה ו-Bokehבמצלמות הראשיות, דרך התוספים של CameraX ו-Camera2. - [7.5/H-1-16] חובה לתמוך ביכולת DYNAMIC_RANGE_TEN_BIT במצלמות הראשיות.
- [7.5/H-1-17] חובה לתמוך ב-CONTROL_SCENE_MODE_FACE_PRIORITY ובזיהוי פנים (STATISTICS_FACE_DETECT_MODE_SIMPLE או STATISTICS_FACE_DETECT_MODE_FULL) במצלמות הראשיות.
סיום הדרישות החדשות
2.2.7.3. חומרה
אם הטמעות של מכשירי כף יד מחזירות את הערך android.os.Build.VERSION_CODES.T
עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, המשמעות היא שהן:
- חייבת לעמוד בדרישות המדיה המפורטות בקטע 2.2.7.3 ב-CDD של Android 13.
יצירת דרישות חדשות
אם הטמעות של מכשירי כף יד מחזירות את הערך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 ניטים בממוצע לפחות.
- [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
, המשמעות היא שהן:
- חובה לעמוד בדרישות הביצועים המפורטות בסעיף 2.2.7.4 ב-CDD של Android 13.
יצירת דרישות חדשות
אם הטמעות של מכשירי כף יד מחזירות את הערךandroid.os.Build.VERSION_CODES.U
עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, המשמעות היא שהן:
- [8.2/H-1-1] חובה להבטיח ביצועי כתיבה רציפה של לפחות 150MB/s.
- [8.2/H-1-2] חובה להבטיח ביצועי כתיבה אקראיים של לפחות 10MB/s.
- [8.2/H-1-3] חובה להבטיח ביצועי קריאה רצופים של לפחות 250MB/s.
- [8.2/H-1-4] חובה להבטיח ביצועי קריאה אקראית של לפחות 100MB/s.
- [8.2/H-1-5] חובה להבטיח ביצועי קריאה וכתיבה סדרתיים במקביל, עם ביצועי קריאה כפולים וביצועי כתיבה יחידים של לפחות 50MB/s.
סיום הדרישות החדשות
2.3. דרישות לטלוויזיה
מכשיר Android Television הוא הטמעה של מכשיר Android שמהווה ממשק בידור לצפייה במדיה דיגיטלית, בסרטים, במשחקים, באפליקציות ו/או בטלוויזיה בשידור חי, למשתמשים שיושבים במרחק של כ-3 מטרים ('ממשק משתמש למנוחה' או 'ממשק משתמש ל-10 רגל').
הטמעות של מכשירי Android מסווגות כטלוויזיה אם הן עומדות בכל הקריטריונים הבאים:
- לספק מנגנון לשלוט מרחוק בממשק המשתמש שעבר רינדור במסך שעשוי להיות במרחק של שלושה מטרים מהמשתמש.
- מכיל מסך מובנה בגודל 24 אינץ' או יותר, או יציאת וידאו, כמו VGA, HDMI, DisplayPort או יציאה אלחוטית להצגה.
הדרישות הנוספות שמפורטות בהמשך הקטע הזה ספציפיות להטמעות במכשירי Android TV.
2.3.1. חומרה
הטמעות במכשירי טלוויזיה:
- [7.2.2/T-0-1] חובה לתמוך בD-pad.
- [7.2.3/T-0-1] חובה לספק את הפונקציות 'דף הבית' ו'הקודם'.
- [7.2.3/T-0-2] חובה לשלוח לאפליקציה שבחזית גם את האירוע הרגיל וגם את האירוע של לחיצה ארוכה על פונקציית החזרה אחורה (
KEYCODE_BACK
). - [7.2.6.1/T-0-1] חובה לכלול תמיכה בפקדים למשחקים ולהצהיר על דגל התכונה
android.hardware.gamepad
. - [7.2.7/T] צריך לספק שלט רחוק שממנו המשתמשים יכולים לגשת לניווט ללא מגע ולקלידות של ניווט ליבה.
אם הטמעות של מכשירי טלוויזיה כוללות ג'ירוסקופ ב-3 צירים, הן:
- [7.3.4/T-1-1] חייב להיות מסוגל לדווח על אירועים עד לתדירות של לפחות 100Hz.
- [7.3.4/T-1-2] חייב להיות מסוגל למדוד שינויים בכיוון עד 1,000 מעלות לשנייה.
הטמעות במכשירי טלוויזיה:
- [7.4.3/T-0-1] חובה לתמוך ב-Bluetooth וב-Bluetooth LE.
- [7.6.1/T-0-1] חייב להיות לפחות 4GB של אחסון לא נדיף שזמין לנתונים הפרטיים של האפליקציה (נקרא גם מחיצה '/data').
אם הטמעות של מכשירי טלוויזיה כוללות יציאת USB שתומכת במצב מארח, הן:
- [7.5.3/T-1-1] חובה לכלול תמיכה במצלמה חיצונית שמתחבר דרך יציאת ה-USB הזו, אבל לא בהכרח תמיד מחוברת.
אם הטמעות של מכשירי טלוויזיה הן 32 ביט:
[7.6.1/T-1-1] אם משתמשים באחת מהצפיפויות הבאות, נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 896MB:
- 400dpi או יותר במסכים קטנים/רגילים
- xhdpi ומעלה במסכים גדולים
- tvdpi ומעלה במסכים גדולים במיוחד
אם הטמעות במכשירי טלוויזיה הן של 64 ביט:
[7.6.1/T-2-1] אם משתמשים באחת מהצפיפויות הבאות, נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 1,280MB:
- 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 (enhanced low delay AAC)
הטמעות של מכשירי טלוויזיה חייבות לתמוך בפורמטים הבאים של קידוד וידאו ולהפוך אותם לזמינים לאפליקציות של צד שלישי:
הטמעות במכשירי טלוויזיה:
- [5.2.2/T-SR-1] מומלץ מאוד לתמוך בקידוד H.264 של סרטונים ברזולוציה 720p ו-1080p ב-30 פריימים לשנייה.
הטמעות של מכשירי טלוויזיה חייבות לתמוך בפורמטים הבאים של פענוח וידאו ולהפוך אותם לזמינים לאפליקציות של צד שלישי:
- [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
הטמעות של מכשירי טלוויזיה חייבות לתמוך בפענוח MPEG-2, כפי שמפורט בקטע 5.3.1, בקצב פריימים רגיל של וידאו וברזולוציות רגילות, עד לכלול:
- [5.3.1/T-1-1] HD 1080p בקצב של 29.97 פריימים לשנייה עם רמה גבוהה של פרופיל ראשי.
- [5.3.1/T-1-2] HD 1080i במהירות 59.94 פריימים לשנייה עם רמה גבוהה של פרופיל ראשי. חובה לבטל את המעבר בין השורות של סרטון MPEG-2 שמשולב, ולהפוך אותו לזמין לאפליקציות של צד שלישי.
הטמעות של מכשירי טלוויזיה חייבות לתמוך בפענוח H.264, כפי שמפורט בקטע 5.3.4, בקצב פריימים רגיל של וידאו וברזולוציות רגילות, עד לכלול:
- [5.3.4/T-1-1] HD 1080p בקצב של 60 פריימים לשנייה עם Baseline Profile
- [5.3.4/T-1-2] HD 1080p בקצב של 60 פריימים לשנייה עם פרופיל ראשי
- [5.3.4/T-1-3] HD 1080p בקצב של 60 פריימים לשנייה עם High Profile Level 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 פריימים לשנייה עם פרופיל Main10 ברמה 5 ברמה הראשית
הטמעות של מכשירי טלוויזיה חייבות לתמוך בפענוח VP8, כפי שמפורט בקטע 5.3.6, בקצב פריימים רגיל של וידאו וברזולוציות עד:
- [5.3.6/T-1-1] פרופיל פענוח של HD 1080p בקצב של 60 פריימים לשנייה
הטמעות של מכשירי טלוויזיה עם מפענחים לחומרה של VP9 חייבות לתמוך בפענוח VP9, כפי שמפורט בקטע 5.3.7, בשיעורי פריימים רגילים של וידאו וברזולוציות רגילות עד לכלול:
- [5.3.7/T-1-1] HD 1080p בקצב של 60 פריימים לשנייה עם פרופיל 0 (עומק צבע של 8 ביט)
אם הטמעות של מכשירי טלוויזיה עם מפענחים לחומרה של VP9 תומכות בפענוח VP9 ובפרופיל הפענוח של UHD, הן:
- [5.3.7/T-2-1] חובה לתמוך בפרופיל הפענוח של UHD במהירות 60 פריימים לשנייה עם פרופיל 0 (עומק צבע של 8 ביט).
- [5.3.7/T-SR1] מומלץ מאוד לתמוך בפרופיל הפענוח של UHD בקצב של 60 פריימים לשנייה עם פרופיל 2 (עומק צבע של 10 ביט).
הטמעות במכשירי טלוויזיה:
- [5.5/T-0-1] חובה לכלול תמיכה בעוצמת הקול הראשית של המערכת ובהפחתת עוצמת הקול של יציאת האודיו הדיגיטלי בממשקי יציאה נתמכים, מלבד יציאת אודיו דחוסה ללא תיקון שגיאות (passthrough) (שבה לא מתבצע פענוח אודיו במכשיר).
אם להטמעות של מכשירי טלוויזיה אין מסך מובנה, אלא תמיכה במסך חיצוני שמחובר באמצעות 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] חובה לטעון מראש אפליקציה אחת או יותר או רכיבי שירות עם טיפול בכוונה (intent), לכל דפוסי המסננים הציבוריים של הכוונה שהוגדרו על ידי כוונות האפליקציה הבאות שמפורטות כאן.
- [3.4.1/T-0-1] חובה לספק הטמעה מלאה של ה-API של
android.webkit.Webview
.
אם הטמעות של מכשירי Android Television תומכות במסך נעילה,הן:
- [3.8.10/T-1-1] חובה להציג את ההתראות במסך הנעילה, כולל תבנית ההתראות של המדיה.
הטמעות במכשירי טלוויזיה:
- [3.8.14/T-SR-1] מומלץ מאוד לתמוך במצב 'תמונה בתוך תמונה' (PIP) במספר חלונות.
- [3.10/T-0-1] חובה לתמוך בשירותי נגישות של צד שלישי.
- [3.10/T-SR-1] מומלץ מאוד לטעון מראש את שירותי הנגישות במכשיר, עם פונקציונליות דומה או טובה יותר מזו של שירותי הנגישות 'גישה באמצעות מתג' ו-TalkBack (עבור שפות שנתמכות במנוע ההמרה מ-Text ל-Speech שמותקן מראש), כפי שמפורט בפרויקט הקוד הפתוח של TalkBack.
אם הטמעות של מכשירי טלוויזיה מדווחות על התכונה android.hardware.audio.output
, הן:
- [3.11/T-SR-1] מומלץ מאוד לכלול מנוע TTS שתומך בשפות הזמינות במכשיר.
- [3.11/T-1-1] חובה לתמוך בהתקנה של מנועי TTS של צד שלישי.
הטמעות במכשירי טלוויזיה:
- [3.12/T-0-1] חובה לתמוך ב-TV Input Framework.
2.3.4. ביצועים וצריכת חשמל
- [8.1/T-0-1] זמן אחזור עקבי של פריימים. זמן אחזור לא עקבי של פריימים או עיכוב ברינדור של פריימים אסור לקרות בתדירות של יותר מ-5 פריימים לשנייה, וצריך להיות נמוך מפריים אחד לשנייה.
- [8.2/T-0-1] חובה להבטיח ביצועי כתיבה רצופים של לפחות 5MB/s.
- [8.2/T-0-2] חובה להבטיח ביצועי כתיבה אקראיים של לפחות 0.5MB/s.
- [8.2/T-0-3] חובה להבטיח ביצועי קריאה רציפים של לפחות 15MB/s.
- [8.2/T-0-4] חובה להבטיח ביצועי קריאה אקראית של לפחות 3.5MB/s.
אם הטמעות של מכשירי טלוויזיה כוללות תכונות לשיפור ניהול צריכת החשמל במכשיר שנכללות ב-AOSP או להרחבת התכונות שנכללות ב-AOSP, הן:
- [8.3/T-1-1] חובה לספק למשתמש אפשרות להפעיל ולהשבית את התכונה 'חיסכון בסוללה'.
אם למכשירי טלוויזיה אין סוללה, הם:
- [8.3/T-1-2] חובה לרשום את המכשיר כמכשיר ללא סוללה, כפי שמתואר בקטע תמיכה במכשירים ללא סוללה.
אם למכשירי טלוויזיה יש סוללה, הם:
- [8.3/T-1-3] חובה לספק למשתמשים אפשרות להציג את כל האפליקציות שפטורות ממצבי חיסכון האנרגיה 'המתנה לאפליקציה' ו'דוז'.
הטמעות במכשירי טלוויזיה:
- [8.4/T-0-1] חובה לספק פרופיל צריכת אנרגיה לכל רכיב, שמגדיר את ערך הצריכה הנוכחית של כל רכיב חומרה ואת הירידה המשוערת בנפח הסוללה שנגרמת על ידי הרכיבים לאורך זמן, כפי שמופיע באתר של Android Open Source Project.
- [8.4/T-0-2] חובה לדווח על כל ערכי צריכת האנרגיה במיליאמפר-שעה (mAh).
- [8.4/T-0-3] חובה לדווח על צריכת החשמל של המעבד לכל מזהה משתמש (UID) של תהליך. פרויקט הקוד הפתוח של Android עומד בדרישות באמצעות הטמעת מודול הליבה
uid_cputime
. - [8.4/T] צריך לשייך לרכיב החומרה עצמו אם לא ניתן לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.
- [8.4/T-0-4] חובה להפוך את צריכת האנרגיה הזו לזמינה למפתח האפליקציה באמצעות הפקודה
adb shell dumpsys batterystats
.
2.3.5. מודל אבטחה
הטמעות במכשירי טלוויזיה:
- [9/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, כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בליבה ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד הליבה או קוד מרחב המשתמש עשוי לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. בפרויקט Android Open Source (AOSP) ב-upstream מתקיימים הדרישות האלה באמצעות ההטמעה של Trusty, אבל יש גם אפשרויות חלופיות: פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת של בידוד תקין שמבוסס על hypervisor, שעבר בדיקה על ידי צד שלישי.
- [9.11/T-0-3] חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק אם הוא מצליח, לאפשר שימוש במפתחות שמקושרים לאימות. חובה לאחסן את פרטי הכניסה של מסך הנעילה באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. בפרויקט הקוד הפתוח של Android תוכלו למצוא את שכבת האובייקטים המצומצמים לחומרה (HAL) של Gatekeeper ו-Trusty, שאפשר להשתמש בהם כדי לעמוד בדרישות האלה.
- [9.11/T-0-4] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה לאימות מוגן על ידי חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה לאימות במספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת מהדרכים לעמוד בדרישות האלה היא לשתף את אותו מפתח אימות, אלא אם מיוצרות לפחות 100,000 יחידות של מק"ט נתון. אם מיוצרות יותר מ-100,000 יחידות של מק"ט מסוים, יכול להיות שייעשה שימוש במפתח שונה לכל 100,000 יחידות.
הערה: אם הטמעת מכשיר כבר הופעלה בגרסה קודמת של Android, המכשיר הזה פטור מהדרישה לכלול מאגר מפתחות שמגודר על ידי סביבת הפעלה מבודדת ולתמוך באימות המפתחות, אלא אם הוא מצהיר על התכונה android.hardware.fingerprint
, שדורשת מאגר מפתחות שמגודר על ידי סביבת הפעלה מבודדת.
אם הטמעות של מכשירי טלוויזיה תומכות במסך נעילה מאובטח, הן:
- [9.11/T-1-1] חובה לאפשר למשתמש לבחור את זמן הקצוב לתפוגה במצב שינה כדי לעבור ממצב פתוח למצב נעול, כאשר זמן הקצוב לתפוגה המינימלי המותר הוא עד 15 שניות או פחות.
אם הטמעות של מכשירי טלוויזיה כוללות כמה משתמשים ולא מצהירות על דגל התכונה android.hardware.telephony
, הן:
- [9.5/T-2-1] חובה לתמוך בפרופילים מוגבלים, תכונה שמאפשרת לבעלי המכשיר לנהל משתמשים נוספים ואת היכולות שלהם במכשיר. בעזרת פרופילים מוגבלים, בעלי המכשירים יכולים להגדיר במהירות סביבות נפרדות למשתמשים נוספים, ולנהל הגבלות מפורטות יותר על האפליקציות שזמינות בסביבות האלה.
אם הטמעות של מכשירי טלוויזיה כוללות כמה משתמשים ומצהירות על דגל התכונה android.hardware.telephony
, הן:
- [9.5/T-3-1] אסור לתמוך בפרופילים מוגבלים, אבל חובה להתאים את ההטמעה של אמצעי הבקרה ב-AOSP כדי לאפשר או להשבית למשתמשים אחרים גישה לשיחות הקוליות ול-SMS.
אם הטמעות של מכשירי טלוויזיה מכריזות על android.hardware.microphone
, הן:
- [9.8.2/T-4-1] חובה להציג את האינדיקטור של המיקרופון כשאפליקציה ניגשת לנתוני אודיו מהמיקרופון, אבל לא כשהגישה למיקרופון היא רק על ידי HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService או אפליקציות עם התפקידים שמפורטים בקטע 9.1 בנושא הרשאות עם מזהה CDD C-3-X].
- [9.8.2/T-4-2] אסור להסתיר את האינדיקטור של המיקרופון באפליקציות מערכת שיש להן ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמש.
אם הטמעות של מכשירי טלוויזיה מכריזות על android.hardware.camera.any
, הן:
- [9.8.2/T-5-1] חובה להציג את סמל המצלמה כשאפליקציה ניגשת לנתוני המצלמה בשידור חי, אבל לא כשאפליקציות עם התפקידים שמפורטים בקטע 9.1 הרשאות עם מזהה CDD [C-3-X] ניגשות למצלמה בלבד.
- [9.8.2/T-5-2] אסור להסתיר את האינדיקטור של המצלמה באפליקציות מערכת שיש להן ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמש.
2.3.6. תאימות של כלים ואפשרויות למפתחים
הטמעות במכשירי טלוויזיה:
- Perfetto
- [6.1/T-0-1] חובה לחשוף למשתמש המעטפת קובץ בינארי של
/system/bin/perfetto
, שבו שורת הפקודה תואמת למסמכי התיעוד של perfetto. - [6.1/T-0-2] קובץ הבינארי של perfetto חייב לקבל כקלט קובץ תצורה של protobuf שתואם לסכימה שמוגדרת במסמכי התיעוד של perfetto.
- [6.1/T-0-3] קובץ הבינארי של perfetto חייב לכתוב כפלט נתיב protobuf שתואם לסכימה שמוגדרת במסמכי התיעוד של perfetto.
- [6.1/T-0-4] חובה לספק, באמצעות הקובץ הבינארי של perfetto, לפחות את מקורות הנתונים שמתוארים במסמכי התיעוד של perfetto.
- [6.1/T-0-1] חובה לחשוף למשתמש המעטפת קובץ בינארי של
2.4. דרישות לשעון
מכשיר Android Watch הוא הטמעה של מכשיר Android שמיועד ללבישה על הגוף, אולי על פרק כף היד.
הטמעות של מכשירי Android מסווגות כשעון אם הן עומדות בכל הקריטריונים הבאים:
- המסך צריך להיות בגודל פיזי של 1.1 עד 2.5 אינץ' באלכסון.
- מכשיר עם מנגנון ללבישה על הגוף.
הדרישות הנוספות שמפורטות בהמשך הסעיף הזה ספציפיות להטמעות במכשירי Android Watch.
2.4.1. חומרה
הטמעות של מכשירי Watch:
[7.1.1.1/W-0-1] חייב לכלול מסך בגודל פיזי באלכסון של 1.1 עד 2.5 אינץ'.
[7.2.3/W-0-1] חובה שפונקציית הבית תהיה זמינה למשתמש, וגם פונקציית החזרה אחורה, מלבד כשהמכשיר נמצא ב-
UI_MODE_TYPE_WATCH
.[7.2.4/W-0-1] חובה לתמוך בקלט במסך מגע.
[7.3.1/W-SR-1] מומלץ מאוד לכלול תאוצה משולש-צירי.
אם הטמעות של מכשירי שעון כוללות מקלט GPS/GNSS ומדווחות על היכולת הזו לאפליקציות באמצעות דגל התכונה android.hardware.location.gps
, הן:
- [7.3.3/W-1-1] חובה לדווח על מדידות GNSS ברגע שהן מתקבלות, גם אם עדיין לא דווח על מיקום שמחושב מ-GPS/GNSS.
- [7.3.3/W-1-2] חובה לדווח על טווחי פסאודו וקצבי פסאודו של GNSS, שבתנאי שדה פתוח אחרי שנקבע המיקום, במצב נייח או בתנועה עם פחות מ-0.2 מטר לשנייה בריבוע של תאוצה, מספיקים כדי לחשב מיקום בטווח של 20 מטרים ומהירות בטווח של 0.2 מטר לשנייה, לפחות ב-95% מהמקרים.
אם הטמעות של מכשירי Watch כוללות ג'ירוסקופ ב-3 צירים, הן:
- [7.3.4/W-2-1] חייב להיות מסוגל למדוד שינויים בכיוון עד 1,000 מעלות לשנייה.
הטמעות של מכשירי Watch:
[7.4.3/W-0-1] חובה שתהיה תמיכה ב-Bluetooth.
[7.6.1/W-0-1] חייב להיות לפחות 1GB של אחסון לא נדיף שזמין לנתונים הפרטיים של האפליקציה (נקרא גם מחיצה '/data').
[7.6.1/W-0-2] חייבת להיות לפחות 416MB של זיכרון שזמין לליבה ולמרחב המשתמש.
[7.8.1/W-0-1] חייב לכלול מיקרופון.
[7.8.2/W] יכול להיות שיש לו פלט אודיו.
2.4.2. מולטימדיה
אין דרישות נוספות.
2.4.3. תוכנות
הטמעות של מכשירי Watch:
- [3/W-0-1] חובה להצהיר על התכונה
android.hardware.type.watch
. - [3/W-0-2] חובה לתמוך ב-uiMode = UI_MODE_TYPE_WATCH.
- [3.2.3.1/W-0-1] חובה לטעון מראש אפליקציה אחת או יותר או רכיבי שירות עם טיפול בכוונה, לכל דפוסי המסננים הציבוריים של הכוונה שהוגדרו על ידי כוונות האפליקציה הבאות שמפורטות כאן.
הטמעות של מכשירי Watch:
- [3.8.4/W-SR-1] מומלץ מאוד להטמיע במכשיר עוזרת כדי לטפל בפעולת העזרה.
צפייה בהטמעות במכשירים שמצהירות על דגל התכונה android.hardware.audio.output
:
- [3.10/W-1-1] חובה לתמוך בשירותי נגישות של צד שלישי.
- [3.10/W-SR-1] מומלץ מאוד לטעון מראש במכשיר שירותי נגישות שדומים לשירותי הנגישות של Switch Access ו-TalkBack (לשפות שנתמכות במנוע ההמרה מ-Text ל-Speech שמותקן מראש) או שעדיפים עליהם, כפי שמפורט בפרויקט הקוד הפתוח של TalkBack.
אם הטמעות של מכשירי Watch מדווחות על התכונה android.hardware.audio.output, הן:
[3.11/W-SR-1] מומלץ מאוד לכלול מנוע TTS שתומך בשפות הזמינות במכשיר.
[3.11/W-0-1] חובה לתמוך בהתקנה של מנועי TTS של צד שלישי.
2.4.4. ביצועים וצריכת חשמל
אם הטמעות של מכשירי Watch כוללות תכונות לשיפור ניהול צריכת החשמל במכשיר שכלולות ב-AOSP או להרחבת התכונות שכלולות ב-AOSP, הן:
- [8.3/W-SR-1] מומלץ מאוד לספק למשתמש אפשרות להציג את כל האפליקציות שפטורות ממצבי חיסכון האנרגיה 'המתנה לאפליקציה' ו'שינה עמוקה'.
- [8.3/W-SR-2] מומלץ מאוד לספק למשתמש אפשרות להפעיל ולהשבית את התכונה 'חיסכון בסוללה'.
הטמעות של מכשירי Watch:
- [8.4/W-0-1] חובה לספק פרופיל צריכת אנרגיה לכל רכיב, שמגדיר את ערך הצריכה הנוכחית של כל רכיב חומרה ואת הירידה המשוערת בנפח הסוללה שנגרמת על ידי הרכיבים לאורך זמן, כפי שמופיע באתר של Android Open Source Project.
- [8.4/W-0-2] חובה לדווח על כל ערכי צריכת האנרגיה בשעות מיליאמפר (mAh).
- [8.4/W-0-3] חובה לדווח על צריכת החשמל של המעבד לכל מזהה משתמש (UID) של תהליך. פרויקט הקוד הפתוח של Android עומד בדרישות באמצעות הטמעת מודול הליבה
uid_cputime
. - [8.4/W-0-4] חייבים להפוך את צריכת האנרגיה הזו לזמינה למפתח האפליקציה באמצעות הפקודה
adb shell dumpsys batterystats
במעטפת. - [8.4/W] צריך לשייך לרכיב החומרה עצמו אם אי אפשר לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.
2.4.5. מודל אבטחה
הטמעות של מכשירי Watch:
- [9/W-0-1] חובה להצהיר על התכונה
android.hardware.security.model.compatible
.
אם הטמעות של מכשירי Watch כוללות כמה משתמשים ולא מצהירות על דגל התכונה android.hardware.telephony
, הן:
- [9.5/W-1-1] חובה לתמוך בפרופילים מוגבלים, תכונה שמאפשרת לבעלי המכשיר לנהל משתמשים נוספים ואת היכולות שלהם במכשיר. בעזרת פרופילים מוגבלים, בעלי המכשירים יכולים להגדיר במהירות סביבות נפרדות למשתמשים נוספים, ולנהל הגבלות מפורטות יותר על האפליקציות שזמינות בסביבות האלה.
אם הטמעות של מכשירי Watch כוללות כמה משתמשים ומצהירות על דגל התכונה android.hardware.telephony
, הן:
- [9.5/W-2-1] אסור לתמוך בפרופילים מוגבלים, אבל חובה להתאים את ההטמעה של אמצעי הבקרה ב-AOSP כדי לאפשר או להשבית למשתמשים אחרים גישה לשיחות הקוליות ול-SMS.
יצירת דרישות חדשות
אם להטמעות במכשירים יש נעילת מסך מאובטחת והן כוללות סוכן אמון אחד או יותר שמטמיע את System API של TrustAgentService
, הן:
- [9.11.1/W-1-1] חובה לאתגר את המשתמש באחת משיטות האימות הראשיות המומלצות (למשל: קוד אימות, קו ביטול נעילה, סיסמה) בתדירות גבוהה יותר מפעם ב-72 שעות.
סיום הדרישות החדשות
2.5. דרישות לכלי רכב
הטמעת Android Automotive מתייחסת ליחידת ראש של רכב שפועלת ב-Android כמערכת הפעלה לחלק מהפונקציונליות של המערכת ו/או של מערכת המידע והבידור, או לכל הפונקציונליות הזו.
הטמעות של מכשירי Android מסווגות כ-Automotive אם הן מצהירות על התכונה android.hardware.type.automotive
או עומדות בכל הקריטריונים הבאים.
- מוטמעים כחלק מכלי רכב או מחברים אותם לכלי רכב.
- משתמשים במסך בשורה של מושב הנהג בתור המסך הראשי.
הדרישות הנוספות שמפורטות בהמשך הקטע הזה ספציפיות להטמעות של מכשירי Android Automotive.
2.5.1. חומרה
הטמעות במכשירים לכלי רכב:
- [7.1.1.1/A-0-1] חייב להיות מסך בגודל פיזי של לפחות 6 אינץ' באלכסון.
- [7.1.1.1/A-0-2] חובה להגדיר פריסה בגודל מסך של לפחות 750dp x 480dp.
- [7.2.3/A-0-1] חובה לספק את הפונקציה 'דף הבית', וניתן לספק את הפונקציות 'חזרה' ו'פריטים אחרונים'.
- [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
חייב להיות עקבי עם מצב היום/לילה בלוח הבקרה, וצריך להתבסס על הקלט של חיישן התאורה הסביבתית. חיישן האור הרגיש לסביבה שמשמש כבסיס עשוי להיות זהה לפוטומטר. - [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 ולייצא את כל הסמלים.
אם ההטמעות של מכשירי Automotive כוללות תאוצה, הן:
- [7.3.1/A-1-1] חייב להיות אפשרי לדווח על אירועים עד תדירות של לפחות 100Hz.
אם ההטמעות במכשירים כוללות מד תאוצה ב-3 צירים, הן:
- [7.3.1/A-SR-1] מומלץ מאוד להטמיע את החיישן המשולב למד תאוצה עם צירים מוגבלים.
אם הטמעות של מכשירים לכלי רכב כוללות מד תאוצה עם פחות מ-3 צירים, הן:
- [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 שמחושבים במקלט, או באמצעות המיקום האחרון הידוע של הרכב בשילוב עם היכולת לבצע חישוב משוער של המיקום (dead reckoning) למשך לפחות 60 שניות, עם דיוק מיקום שעומד בדרישות של 7.3.3/C-1-3, או בשילוב של שניהם.
אם הטמעות של מכשירי רכב כוללות חיישן TYPE_HEADING
, הן:
- [7.3.4/A-4-3] חייב להיות אפשרי לדווח על אירועים בתדירות של לפחות 1Hz.
- [7.3.4/A-SR-3] מומלץ מאוד לדווח על אירועים בתדירות של לפחות 10Hz.
- צריך להתייחס לצפון מוחלט.
- האפשרות הזו אמורה להיות זמינה גם כשהרכב עומד.
- צריכה להיות רזולוציה של לפחות מעלה אחת.
הטמעות במכשירים לכלי רכב:
- [7.4.3/A-0-1] חובה שתהיה תמיכה ב-Bluetooth, ומומלץ שתהיה תמיכה ב-Bluetooth LE.
- [7.4.3/A-0-2] יש לכלול בהטמעות של Android Automotive תמיכה בפרופילים הבאים של Bluetooth:
- שיחות טלפון באמצעות פרופיל דיבורית (HFP).
- הפעלת מדיה באמצעות פרופיל להפצת אודיו (A2DP).
- שליטה בהפעלת מדיה באמצעות פרופיל שלט רחוק (AVRCP).
- שיתוף אנשי קשר באמצעות פרופיל הגישה לספר הטלפונים (PBAP).
[7.4.3/A-SR-1] מומלץ מאוד לתמוך בפרופיל גישה להודעות (MAP).
[7.4.5/A] צריך לכלול תמיכה בחיבור נתונים מבוסס-רשת סלולרית.
[7.4.5/A] יכול להשתמש בערך הקבוע
NetworkCapabilities#NET_CAPABILITY_OEM_PAID
של System API לרשתות שצריכות להיות זמינות לאפליקציות המערכת.
יצירת דרישות חדשות
אם הטמעות במכשירים כוללות תמיכה ברדיו שידור AM/FM ומציגות את הפונקציונליות לכל אפליקציה, הן:
- [7.4
.10/A-0-1] חובה להצהיר על תמיכה ב-FEATURE_BROADCAST_RADIO
.
סיום הדרישות החדשות
מצלמת תצוגה חיצונית היא מצלמה שמצלמת סצנות מחוץ להטמעת המכשיר, כמו מצלמת הרכב האחורית.
הטמעות במכשירים לכלי רכב:
- צריך לכלול מצלמה אחת או יותר עם תצוגה חיצונית.
אם הטמעות של מכשירי רכב כוללות מצלמה עם תצוגה חיצונית, המצלמה הזו:
- [7.5/A-1-1] אסור שיהיו מצלמות חיצוניות שאפשר לגשת אליהן דרך Android Camera APIs, אלא אם הן עומדות בדרישות הליבה של המצלמה.
[7.5/A-SR-1] מומלץ מאוד לא לסובב את התצוגה המקדימה של המצלמה או להציג אותה במראה אופקית.
[7.5/A-SR-2] מומלץ מאוד שהרזולוציה שלהן תהיה לפחות 1.3 מגה-פיקסלים.
צריכה להיות להם חומרה עם מיקוד קבוע או חומרה עם EDOF (עומק שדה מורחב).
יכול להיות שהמיקוד האוטומטי של החומרה או התוכנה מוטמעים במנהל המצלמה.
אם הטמעות של מכשירים לכלי רכב כוללות מצלמה אחת או יותר של תצוגה חיצונית, ומטענות את השירות של מערכת התצוגה החיצונית (EVS), אז במצלמה כזו:
- [7.5/A-2-1] אסור לסובב או להציג בתמונת המראה של המצלמה בכיוון אופקי.
הטמעות במכשירים לרכב:
- יכול להיות שיהיו בו מצלמה אחת או יותר שזמינות לאפליקציות של צד שלישי.
אם הטמעות של מכשירים לכלי רכב כוללות מצלמה אחת לפחות ומאפשרות להשתמש בה באפליקציות של צד שלישי, הן:
- [7.5/A-3-1] חובה לדווח על ה-feature flag
android.hardware.camera.any
. - [7.5/A-3-2] אסור להצהיר על המצלמה כמצלמת מערכת.
- יכול להיות שתהיה תמיכה במצלמות חיצוניות כפי שמתואר בסעיף 7.5.3.
- יכולות לכלול תכונות (כמו פוקוס אוטומטי וכו') שזמינות למצלמות שתואמות לסעיף 7.5.1.
יצירת דרישות חדשות
מצלמה אחורית היא מצלמה שצופה לעולם החיצון, שאפשר למקם אותה בכל מקום ברכב והיא פונה אל מחוץ לתא הנוסעים. כלומר, היא מצלמת סצנות בצד הרחוק של גוף הרכב, כמו מצלמת הראות אחורית.
'מצלמה קדמית' היא מצלמה שמכוונת למשתמש, שיכולה להיות ממוקמת בכל מקום ברכב ומכוונת לתא הנוסעים. כלומר, היא מצלמת את המשתמש, למשל לצורך שיתוף מסך באפליקציות דומות.
הטמעות במכשירים לכלי רכב:
- [7.5/A-SR-1] מומלץ מאוד לכלול מצלמה אחת או יותר עם כיוון קדימה.
- יכול להיות שיהיו בו מצלמה אחת או יותר שמכוונת למשתמש.
- [7.5/A-SR-2] מומלץ מאוד לתמוך בסטרימינג בו-זמני של כמה מצלמות.
אם הטמעות של מכשירי רכב כוללות לפחות מצלמה אחת שמכוונת החוצה, אז לגבי מצלמה כזו:
- [7.5/A-1-1] חייב להיות בכיוון שבו הממד הארוך של המצלמה יהיה באותו מישור X-Y של צירי החיישן של Android Automotive.
- [7.5/A-SR-3] מומלץ מאוד להשתמש בחומרה עם מוקד קבוע או עם EDOF (עומק שדה מורחב).
- [7.5/A-1-2] חובה שהמצלמה הראשית הפונה לעולם תהיה המצלמה הפונה לעולם עם מזהה המצלמה הנמוך ביותר.
אם הטמעות של מכשירי רכב כוללות לפחות מצלמה אחת שפונה למשתמש, אז לגבי מצלמה כזו:
- [7.5/A-2-1] המצלמה הראשית הפונה למשתמש חייבת להיות המצלמה הפונה למשתמש עם מזהה המצלמה הנמוך ביותר.
- אפשר להציב אותה כך שהמימד הארוך של המצלמה יתיישר עם מישור X-Y של צירי החיישנים של Android Automotive.
אם הטמעות של מכשירים לכלי רכב כוללות מצלמה שאפשר לגשת אליה דרך API של android.hardware.Camera
או android.hardware.camera2
, הן:
- [7.5/A-3-1] חובה לעמוד בדרישות המרכזיות למצלמה שמפורטות בקטע 7.5.
אם הטמעות של מכשירי רכב כוללות מצלמה שאין גישה אליה דרך android.hardware.Camera
API או 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 כזה של מצלמה באמצעות API של
android.hardware.camera2
או API של מערכת תצוגה מורחבת.
סיום הדרישות החדשות
הטמעות במכשירים לכלי רכב:
[7.6.1/A-0-1] חייב להיות לפחות 4GB של אחסון לא נדיף שזמין לנתונים הפרטיים של האפליקציה (המכונה גם מחיצה '/data').
[7.6.1/A] צריך לעצב את מחיצה הנתונים כדי לשפר את הביצועים ואת משך החיים של האחסון בזיכרון פלאש, למשל באמצעות מערכת הקבצים
f2fs
.
אם הטמעות של מכשירי רכב מספקות אחסון חיצוני משותף באמצעות חלק מהאחסון הפנימי שלא ניתן להסיר, הן:
- [7.6.1/A-SR-1] מומלץ מאוד לצמצם את התקורה של הקלט/פלט (I/O) בפעולות שמבוצעות באחסון החיצוני, למשל באמצעות
SDCardFS
.
אם הטמעות של מכשירי רכב הן ב-64 ביט:
[7.6.1/A-2-1] אם משתמשים באחת מהצפיפויות הבאות, נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 816MB:
- 280dpi או פחות במסכים קטנים או רגילים
- ldpi או פחות במסכים גדולים במיוחד
- mdpi או פחות במסכים גדולים
[7.6.1/A-2-2] אם משתמשים באחת מהצפיפויות הבאות, נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 944MB:
- xhdpi ומעלה במסכים קטנים/רגילים
- hdpi ומעלה במסכים גדולים
- mdpi ומעלה במסכים גדולים במיוחד
[7.6.1/A-2-3] אם משתמשים באחת מהצפיפויות הבאות, נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 1,280MB:
- 400dpi או יותר במסכים קטנים/רגילים
- xhdpi ומעלה במסכים גדולים
- tvdpi ומעלה במסכים גדולים במיוחד
[7.6.1/A-2-4] אם משתמשים באחת מהצפיפויות הבאות, נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 1,824MB:
- 560dpi או יותר במסכים קטנים או רגילים
- 400dpi או יותר במסכים גדולים
- xhdpi ומעלה במסכים גדולים במיוחד
חשוב לזכור שהערך 'זיכרון שזמין לליבה ולמרחב המשתמש' מתייחס למרחב הזיכרון שסופק בנוסף לכל זיכרון שכבר הוקצה לרכיבי חומרה כמו רדיו, וידאו וכו', שלא נמצאים בשליטת הליבה בהטמעות במכשירים.
הטמעות במכשירים לרכב:
- [7.7.1/A] צריכה לכלול יציאת USB שתומכת במצב ציוד היקפי.
הטמעות במכשירים לכלי רכב:
- [7.8.1/A-0-1] חובה לכלול מיקרופון.
הטמעות במכשירים לכלי רכב:
- [7.8.2/A-0-1] חובה שיהיה פלט אודיו ויש להצהיר על
android.hardware.audio.output
.
2.5.2. מולטימדיה
הטמעות של מכשירים לכלי רכב חייבות לתמוך בפורמטים הבאים של קידוד ופענוח אודיו, ולהפוך אותם לזמינים לאפליקציות של צד שלישי:
- [5.1/A-0-1] MPEG-4 AAC Profile (AAC LC)
- [5.1/A-0-2] MPEG-4 HE AAC Profile (AAC+)
- [5.1/A-0-3] AAC ELD (AAC משופר עם זמן אחזור קצר)
הטמעות של מכשירים לכלי רכב חייבות לתמוך בפורמטים הבאים של קידוד וידאו ולהפוך אותם לזמינים לאפליקציות של צד שלישי:
הטמעות של מכשירים לכלי רכב חייבות לתמוך בפורמטים הבאים של פענוח וידאו ולהפוך אותם לזמינים לאפליקציות של צד שלישי:
מומלץ מאוד שתהיה תמיכה בפענוח הווידאו הבא בהטמעות של מכשירים לכלי רכב:
- [5.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] חובה לטעון מראש אפליקציה אחת או יותר או רכיבי שירות עם טיפול בכוונה, לכל דפוסי המסננים הציבוריים של הכוונה שהוגדרו על ידי כוונות האפליקציה הבאות שמפורטות כאן.
[3.4.1/A-0-1] חובה לספק הטמעה מלאה של ה-API
android.webkit.Webview
.
יצירת דרישות חדשות
- [3.8/A-0-1] אסור לאפשר למשתמשים משניים מלאים שאינם המשתמש הנוכחי בחזית להפעיל פעילויות ולקבל גישה לממשק המשתמש בכל המסכים.
סיום הדרישות החדשות
[3.8.3/A-0-1] חובה להציג התראות שמשתמשות ב-API של
Notification.CarExtender
כשאפליקציות צד שלישי מבקשות זאת.[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] חובה להציג את הלחצנים 'הפעלה' ו'השתקה' לפעולות התראות במקום הלחצנים שסופקו דרך
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] חובה לספק אפשרות לניווט לפעילות ההעדפות של אפליקציית המדיה, אבל חובה להפעיל אותה רק כשההגבלות על חוויית המשתמש ברכב לא בתוקף.
- [3.14/A-0-5] חובה להציג הודעות שגיאה שהוגדרו על ידי Media Applications, וחובה לתמוך בתוספים האופציונליים
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 Open Source Project.
- [8.4/A-0-2] חובה לדווח על כל ערכי צריכת האנרגיה בשעות מיליאמפר (mAh).
- [8.4/A-0-3] חובה לדווח על צריכת החשמל של המעבד לכל מזהה משתמש (UID) של תהליך. פרויקט הקוד הפתוח של Android עומד בדרישות באמצעות הטמעת מודול הליבה
uid_cputime
. - [8.4/A] צריך לשייך לרכיב החומרה עצמו אם לא ניתן לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.
- [8.4/A-0-4] חובה להפוך את צריכת האנרגיה הזו לזמינה למפתח האפליקציה באמצעות הפקודה
adb shell dumpsys batterystats
.
2.5.5. מודל אבטחה
אם הטמעות של מכשירים לכלי רכב תומכות בכמה משתמשים, הן:
- [9.5/A-1-1] אסור לאפשר למשתמשים לקיים אינטראקציה עם משתמש המערכת ללא ראש או לעבור אליו, מלבד הקצאת מכשיר.
- [9.5/A-1-2] חובה לעבור למשתמש משני לפני
BOOT_COMPLETED
. - [9.5/A-1-3] חובה לתמוך באפשרות ליצור משתמש אורח גם אם מספר המשתמשים המקסימלי במכשיר הושג.
יצירת דרישות חדשות
אם הטמעות של מכשירי רכב מגדירות את 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]ניגשות למצלמה בלבד. - [9.8.2/A-2-2] אסור להסתיר את האינדיקטור של המצלמה באפליקציות מערכת שיש להן ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמש.
יצירת דרישות חדשות
- [9.8.2/A-2-3] חובה לספק למשתמש אפשרות להפעיל או להשבית את המצלמה באפליקציית ההגדרות.
- [9.8.2/A-2-4] חובה להציג את האפליקציות האחרונות והפעילות באמצעות המצלמה, כפי שהן מופיעות ב-
PermissionManager.getIndicatorAppOpUsageData()
, יחד עם הודעות שיוך שמשויכות אליהן.
סיום הדרישות החדשות
הטמעות במכשירים לרכב:
- [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, כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בליבה ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד הליבה או קוד מרחב המשתמש עשוי לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. בפרויקט Android Open Source (AOSP) ב-upstream מתקיימים הדרישות האלה באמצעות ההטמעה של Trusty, אבל יש גם אפשרויות חלופיות: פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת של בידוד תקין שמבוסס על hypervisor, שעבר בדיקה על ידי צד שלישי.
- [9.11/A-0-3] חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק אם הוא מצליח, לאפשר שימוש במפתחות שמקושרים לאימות. חובה לאחסן את פרטי הכניסה של מסך הנעילה באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. בפרויקט הקוד הפתוח של Android תוכלו למצוא את שכבת האובייקטים המצומצמים לחומרה (HAL) של Gatekeeper ו-Trusty, שאפשר להשתמש בהם כדי לעמוד בדרישות האלה.
- [9.11/A-0-4] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה לאימות מוגן על ידי חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה לאימות במספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת מהדרכים לעמוד בדרישות האלה היא לשתף את אותו מפתח אימות, אלא אם מיוצרות לפחות 100,000 יחידות של מק"ט נתון. אם מיוצרות יותר מ-100,000 יחידות של מק"ט מסוים, יכול להיות שייעשה שימוש במפתח שונה לכל 100,000 יחידות.
הערה: אם הטמעת מכשיר כבר הופעלה בגרסה קודמת של Android, המכשיר הזה פטור מהדרישה לכלול מאגר מפתחות שמגודר על ידי סביבת הפעלה מבודדת ולתמוך באימות המפתחות, אלא אם הוא מצהיר על התכונה android.hardware.fingerprint
, שדורשת מאגר מפתחות שמגודר על ידי סביבת הפעלה מבודדת.
הטמעות במכשירים לכלי רכב:
- [9.14/A-0-1] חובה לנהל את ההודעות שמגיעות ממערכי המשנה של הרכב במסגרת Android, למשל, הוספה לרשימת ההיתרים של סוגי ההודעות ומקורות ההודעות המותרים.
- [9.14/A-0-2] חובה להפעיל מעקב אחר התקפות מניעת שירות (DoS) מהמסגרת של Android או מאפליקציות של צד שלישי. כך אפשר למנוע מתוכנות זדוניות להציף את הרשת של הרכב בתנועה, דבר שעלול לגרום לפעולה לא תקינה של תת-מערכות ברכב.
2.5.6. תאימות של כלים ואפשרויות למפתחים
הטמעות במכשירים לכלי רכב:
- Perfetto
- [6.1/A-0-1] חובה לחשוף למשתמש המעטפת קובץ בינארי של
/system/bin/perfetto
, שבו שורת הפקודה תואמת למסמכי התיעוד של perfetto. - [6.1/A-0-2] קובץ הבינארי של perfetto חייב לקבל כקלט קובץ תצורה של protobuf שתואם לסכימה שמוגדרת במסמכי התיעוד של perfetto.
- [6.1/A-0-3] קובץ הבינארי של perfetto חייב לכתוב כפלט נתיב protobuf שתואם לסכימה שמוגדרת במסמכי התיעוד של perfetto.
- [6.1/A-0-4] חובה לספק, באמצעות הקובץ הבינארי של perfetto, לפחות את מקורות הנתונים שמתוארים במסמכי התיעוד של perfetto.
- [6.1/A-0-1] חובה לחשוף למשתמש המעטפת קובץ בינארי של
2.6. דרישות לגבי טאבלטים
מכשיר טאבלט של Android מתייחס להטמעה של מכשיר 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] יכולים להטמיע את Android Open Accessory (AOA) API.
מצב מציאות מדומה (סעיף 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] חובה לטעון מראש אפליקציה אחת או יותר או רכיבי שירות עם טיפול בכוונה (intent), לכל דפוסי המסננים הציבוריים של הכוונה שהוגדרו על ידי כוונות האפליקציה הבאות שמפורטות כאן.
3. תוכנות
3.1. תאימות של ממשקי API מנוהלים
סביבת הביצוע המנוהלת של בייטקוד Dalvik היא הכלי העיקרי להרצת אפליקציות ל-Android. ממשק תכנות האפליקציות (API) של Android הוא קבוצת הממשקים של פלטפורמת Android שנחשפים לאפליקציות שפועלות בסביבת זמן הריצה המנוהלת.
הטמעות במכשירים:
[C-0-1] חובה לספק הטמעות מלאות, כולל כל ההתנהגויות המתועדות, של כל ממשק API מתועד שחשוף על ידי Android SDK או כל ממשק API שמעוטר בסמן @SystemApi בקוד המקור של Android במקור.
[C-0-2] חובה לתמוך בכל הכיתות, השיטות והרכיבים המשויכים שמסומנים בהערה TestApi (@TestApi).
[C-0-3] אסור להשמיט ממשקי API מנוהלים, לשנות ממשקי API או חתימות שלהם, לסטות מההתנהגות המתועדת או לכלול פעולות ללא פעולה (no-ops), אלא אם מותר לעשות זאת במפורש בהגדרת התאימות הזו.
[C-0-4] חובה להמשיך לשמור על ממשקי ה-API ולפעול בצורה סבירה, גם אם חלק מתכונות החומרה ש-Android כולל ממשקי API עבורן הושמטו. הדרישות הספציפיות לתרחיש הזה מפורטות בקטע 7.
[C-0-5] אסור לאפשר לאפליקציות צד שלישי להשתמש בממשקים שאינם SDK, שמוגדרים כשיטות ושדות בחבילות של שפת Java שנמצאות בנתיב הטעינה של AOSP, ולא נכללות ב-SDK הציבורי. הרשאות הגישה האלה כוללות ממשקי API עם ההערה
@hide
, אבל לא עם@SystemAPI
, כפי שמתואר במסמכים של ה-SDK, וגם חברי כיתות פרטיים וחברי כיתות שהגישה אליהם מוגבלת לחבילה.[C-0-6] חובה לשלוח כל ממשק שאינו SDK עם אותן רשימות מוגבלות שסופקו באמצעות הדגלים הזמניים והדגלים של רשימת הדחייה בנתיב
prebuilts/runtime/appcompat/hiddenapi-flags.csv
להסתעפות המתאימה ברמת ה-API ב-AOSP.[C-0-7] חובה לתמוך במנגנון העדכון הדינמי של signed config כדי להסיר ממשקים שאינם SDK מרשימת מכשירים מוגבלת, על ידי הטמעת תצורה חתומה בכל חבילת APK, באמצעות המפתחות הציבוריים הקיימים ב-AOSP.
עם זאת, הם:
- אם ממשק API מוסתר חסר או מוטמע באופן שונה בהטמעה במכשיר, אפשר להעביר את ממשק ה-API המוסתר לרשימת הדחייה או להשמיט אותו מכל הרשימות המוגבלות.
- אם ממשק API מוסתר עדיין לא קיים ב-AOSP, אפשר להוסיף את ממשק ה-API המוסתר לכל אחת מהרשימות המוגבלות.
יצירת דרישות חדשות
- [C-0-8] אסור לתמוך בהתקנה של אפליקציות שמטרגטות לרמת API נמוכה מ-23.
סיום הדרישות החדשות
3.1.1. תוספים ל-Android
ב-Android יש תמיכה בהרחבת ממשק ה-API המנוהל של רמת API מסוימת על ידי עדכון גרסת התוסף של רמת ה-API הזו. ה-API של android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
מחזיר את גרסת התוסף של apiLevel
שסופק, אם יש תוספים לרמת ה-API הזו.
הטמעות במכשירי Android:
[C-0-1] חובה לטעון מראש את ההטמעה של AOSP גם בספרייה המשותפת
ExtShared
וגם בשירותיםExtServices
בגרסאות שגדולות או שוות לגרסאות המינימליות המותרות לכל רמת API. לדוגמה, הטמעות במכשירי Android 7.0 שפועלות ברמת API 24 חייבות לכלול לפחות גרסה 1.[C-0-2] חובה להחזיר רק מספר גרסה תקין של התוסף שהוגדר על ידי AOSP.
[C-0-3] חובה לתמוך בכל ממשקי ה-API שמוגדרים בגרסאות התוסף שמוחזרות על ידי
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
באותה דרך שבה יש תמיכה בממשקי API מנוהלים אחרים, בהתאם לדרישות שמפורטות בקטע 3.1.
3.1.2. ספריית Android
עקב הוצאה משימוש של לקוח ה-HTTP של Apache, בהטמעות במכשירים:
- [C-0-1] אסור להציב את הספרייה
org.apache.http.legacy
ב-bootclasspath. - [C-0-2] חובה להוסיף את הספרייה
org.apache.http.legacy
ל-classpath של האפליקציה רק אם האפליקציה עומדת באחד מהתנאים הבאים:- הטירגוט הוא לרמת API 28 ומטה.
- מצהירה ב-manifest שלה שהיא זקוקה לספרייה על ידי הגדרת המאפיין
android:name
של<uses-library>
לערךorg.apache.http.legacy
.
ההטמעה של AOSP עומדת בדרישות האלה.
3.2. תאימות ל-Soft API
בנוסף לממשקי ה-API המנוהלים שמפורטים בקטע 3.1, Android כולל גם ממשק API 'רך' משמעותי שזמין רק בסביבת זמן הריצה, בדמות דברים כמו כוונות (intents), הרשאות והיבטים דומים של אפליקציות Android שלא ניתן לאכוף בזמן הידור האפליקציה.
3.2.1. הרשאות
- [C-0-1] למטמיעים של מכשירים חובה לתמוך בכל המשתנים הקבועים של ההרשאות ולאכוף אותם, כפי שמתואר בדף העזרה בנושא הרשאות. חשוב לשים לב שבקטע 9 מפורטות דרישות נוספות שקשורות למודל האבטחה של Android.
3.2.2. פרמטרים של build
ממשקי ה-API של Android כוללים מספר קבועים בכיתה android.os.Build שנועדו לתאר את המכשיר הנוכחי.
- [C-0-1] כדי לספק ערכים עקביים ומשמעותיים בכל הטמעות המכשירים, בטבלה הבאה מפורטות הגבלות נוספות על הפורמטים של הערכים האלה, שאליהם הטמעות המכשירים חייבות לעמוד.
פרמטר | פרטים |
---|---|
VERSION.RELEASE | הגרסה של מערכת Android שפועלת כרגע, בפורמט קריא לבני אדם. השדה הזה חייב לכלול אחד מערכי המחרוזות שמוגדרים בקטע מחרוזות גרסאות מותרות ל-Android 14. |
VERSION.SDK | הגרסה של מערכת Android שפועלת כרגע, בפורמט שגלוי לקוד של אפליקציות של צד שלישי. לגבי Android 14, השדה הזה חייב לכלול את הערך השלם 14_INT. |
VERSION.SDK_INT | הגרסה של מערכת Android שפועלת כרגע, בפורמט שגלוי לקוד של אפליקציות של צד שלישי. לגבי Android 14, השדה הזה חייב לכלול את הערך השלם 14_INT. |
VERSION.INCREMENTAL | ערך שנבחר על ידי מי שמטמיע את המכשיר, שמציין את גרסת ה-build הספציפית של מערכת Android שפועלת כרגע, בפורמט שקריא לבני אדם. אסור להשתמש שוב בערך הזה לגרסאות build שונות שזמינות למשתמשי קצה. השימוש הנפוץ בשדה הזה הוא לציין את מספר ה-build או את מזהה השינוי במערכת בקרת הגרסאות ששימשו ליצירת ה-build. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט שאפשר להדפיס, ולהתאים לביטוי הרגולרי ^[^ :\/~]+$. |
משחקי לוח | ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את החומרה הפנימית הספציפית שבה המכשיר משתמש, בפורמט שקריא לבני אדם. אפשר להשתמש בשדה הזה כדי לציין את הגרסה הספציפית של הלוח שמפעיל את המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי “^[a-zA-Z0-9_-]+$”. |
BRAND | ערך שמשקף את שם המותג שמשויך למכשיר כפי שהוא ידוע למשתמשי הקצה. חייב להיות בפורמט שאפשר לקרוא אותו, וצריך לייצג את היצרן של המכשיר או את מותג החברה שדרכו המכשיר משווק. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי “^[a-zA-Z0-9_-]+$”. |
SUPPORTED_ABIS | השם של קבוצת ההוראות (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי. |
SUPPORTED_32_BIT_ABIS | השם של קבוצת ההוראות (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי. |
SUPPORTED_64_BIT_ABIS | השם של קבוצת ההוראות השנייה (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי. |
CPU_ABI | השם של קבוצת ההוראות (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי. |
CPU_ABI2 | השם של קבוצת ההוראות השנייה (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי. |
מכשיר | ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם הפיתוח או שם הקוד שמזהה את ההגדרה של תכונות החומרה ואת העיצוב התעשייתי של המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד בתור ASCII של 7 ביט ולהתאים לביטוי הרגולרי '^[a-zA-Z0-9_-]+$'. אסור לשנות את שם המכשיר במהלך משך החיים של המוצר. |
FINGERPRINT | מחרוזת שמזהה באופן ייחודי את ה-build הזה. הוא אמור להיות קריא לאנשים באופן סביר. היא חייבת לפעול לפי התבנית הבאה:
$(BRAND)/$(PRODUCT)/ לדוגמה: acme/myproduct/ האצבעית אסור שתכלול תווים של רווח לבן. הערך בשדה הזה חייב להיות ניתן לקידוד כ-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 ]+)", אסור שיתחיל או יסתיים ברווחים ואסור שיהיה שווה ל-'unknown'. השדה הזה אסור שישתנה במהלך משך החיים של המוצר. |
SOC_MODEL | שם הדגם של המערכת הראשית על שבב (SoC) שמשמשת במוצר. במכשירים עם אותו מודל SOC צריך להשתמש באותו ערך קבוע. יש לפנות ליצרן ה-SOC כדי לקבל את הקבוע הנכון לשימוש. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי “^([0-9A-Za-z ._/+-]+)$”, אסור שהוא יתחיל או יסתיים במרווחים אסור שהוא יהיה שווה ל-'unknown'. השדה הזה אסור שישתנה במהלך משך החיים של המוצר. |
דגם | ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם המכשיר כפי שהוא ידוע למשתמש הקצה. השם הזה צריך להיות זהה לשם שתחתיו המכשיר משווק ונמכר למשתמשי הקצה. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או מחרוזת ריקה (""). אסור לשנות את השדה הזה במהלך מחזור החיים של המוצר. |
מוצר | ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם הפיתוח או שם הקוד של המוצר הספציפי (מק"ט), שחובה שיהיה ייחודי באותו מותג. חייב להיות קריא לבני אדם, אבל לא בהכרח מיועד לצפייה על ידי משתמשי קצה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט, ולהתאים לביטוי הרגולרי '^[a-zA-Z0-9_-]+$'. אסור לשנות את שם המוצר במהלך כל משך החיים שלו. |
ODM_SKU | ערך אופציונלי שנבחר על ידי מי שמטמיע את המכשיר, שמכיל מק"ט (מספר קטלוגי) המשמש למעקב אחרי הגדרות ספציפיות של המכשיר, למשל ציוד היקפי כלשהו שכלול במכשיר כשהוא נמכר.
הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי ^([0-9A-Za-z.,_-]+)$ . |
SERIAL | חובה להחזיר את הערך 'UNKNOWN'. |
תגים | רשימה של תגים מופרדים בפסיקים שנבחרו על ידי מי שמטמיע את המכשיר, שמבדילה עוד יותר את ה-build. חובה שאפשר יהיה לקודד את התגים כ-ASCII של 7 ביט, שתהיה התאמה לביטוי הרגולרי “^[a-zA-Z0-9._-]+” ושיהיו להם אחד מהערכים התואמים לשלושת הגדרות החתימה הטיפוסיות של פלטפורמת Android: release-keys, dev-keys ו-test-keys. |
שעה | ערך שמייצג את חותמת הזמן של מועד ה-build. |
סוג | ערך שנבחר על ידי מי שמטמיע את המכשיר, ומציין את הגדרת סביבת זמן הריצה של ה-build. השדה הזה חייב לכלול אחד מהערכים שתואמים לשלושת ההגדרות הנפוצות של Android בסביבת זמן ריצה: user, 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() | הערך חייב להיות (או להחזיר) ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את גרסת הרדיו/המודם הפנימית הספציפית שמשמשת במכשיר, בפורמט שקריא לבני אדם. אם למכשיר אין רדיו/מודם פנימיים, חובה להחזיר את הערך NULL. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי “^[a-zA-Z0-9._-,]+$”. |
getSerial() | חובה (להיות או להחזיר) מספר סידורי של חומרה, שחייב להיות זמין וייחודי במכשירים עם אותו דגם ויצרן. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי ^[a-zA-Z0-9]+$. |
3.2.3. תאימות לכוונה
3.2.3.1. כוונות נפוצות של אפליקציות
אובייקטים מסוג Intent ב-Android מאפשרים לרכיבי אפליקציה לבקש פונקציונליות מרכיבים אחרים ב-Android. הפרויקט של Android upstream כולל רשימה של אפליקציות שמטמיעות כמה דפוסי כוונה כדי לבצע פעולות נפוצות.
הטמעות במכשירים:
- [C-SR-1] מומלץ מאוד לטעון מראש אפליקציה אחת או יותר או רכיבי שירות עם בורר כוונות, לכל דפוסי המסנן הציבוריים של הכוונות שמוגדרים על ידי כוונות האפליקציה הבאות שמפורטות כאן, ולספק השלמה, כלומר לעמוד בציפיות של המפתח לגבי כוונות האפליקציה הנפוצות האלה כפי שמתואר ב-SDK.
בקטע 2 מפורטים כוונות האפליקציה החובה לכל סוג מכשיר.
3.2.3.2. פתרון של כוונה
[C-0-1] Android היא פלטפורמה ניתנת להרחבה, ולכן בהטמעות של מכשירים חייב להיות אפשרות לאפליקציות צד שלישי לשנות את כל דפוס הכוונה (intent) שמצוין בקטע 3.2.3.1, מלבד ההגדרות. ההטמעה של Android בקוד פתוח במקור מאפשרת זאת כברירת מחדל.
[C-0-2] אסור למטמיעים של מכשירים לצרף הרשאות מיוחדות לשימוש של אפליקציות המערכת בדפוסי הכוונה האלה, או למנוע מאפליקציות צד שלישי לקשר את עצמן לדפוסים האלה ולשלוט בהם. האיסור הזה כולל, בין היתר, השבתה של ממשק המשתמש 'בורר' שמאפשר למשתמש לבחור בין כמה אפליקציות שמטפלות באותו דפוס כוונה.
[C-0-3] הטמעות במכשירים חייבות לספק ממשק משתמש שמאפשר למשתמשים לשנות את פעילות ברירת המחדל של הכוונות.
עם זאת, הטמעות במכשירים עשויות לספק פעילויות ברירת מחדל לדפוסי URI ספציפיים (למשל http://play.google.com) אם פעילות ברירת המחדל מספקת מאפיין ספציפי יותר ל-URI של הנתונים. לדוגמה, דפוס של מסנן Intent שמציין את URI של הנתונים "http://www.android.com" הוא ספציפי יותר מדפוס ה-Intent המרכזי של הדפדפן עבור "http://".
ב-Android יש גם מנגנון שמאפשר לאפליקציות צד שלישי להצהיר על התנהגות ברירת המחדל המהימנה של קישור האפליקציה לסוגים מסוימים של כוונות URI באינטרנט. כשהצהרות מוסמכות כאלה מוגדרות בדפוסי המסננים של הכוונה באפליקציה, הטמעות במכשירים:
- [C-0-4] חובה לנסות לאמת מסנני Intent על ידי ביצוע שלבי האימות שמוגדרים במפרט של Digital Asset Links, כפי שהם מיושמים על ידי מנהל החבילות ב-Android Open Source Project (פרויקט Android בקוד פתוח) במקור.
- [C-0-5] חובה לנסות לאמת את מסנני הכוונה במהלך התקנת האפליקציה ולהגדיר את כל מסנני הכוונה של URI שאומתו כמטפלי אפליקציה שמוגדרים כברירת מחדל למזהי ה-URI שלהם.
- יכולים להגדיר מסנני כוונה ספציפיים של URI כמפעילי אפליקציה שמוגדרים כברירת מחדל למזהי ה-URI שלהם, אם הם אומתו בהצלחה אבל מסנני URI אחרים לא עברו את תהליך האימות. אם הטמעה במכשיר עושה זאת, היא חייבת לספק למשתמש את השינויים המתאימים לדפוס לכל URI בתפריט ההגדרות.
- חובה לספק למשתמש אמצעי בקרה לכל אפליקציה של קישורי אפליקציות בהגדרות, באופן הבא:
- [C-0-6] המשתמש חייב להיות מסוגל לשנות באופן מקיף את ברירת המחדל של התנהגות הקישורים לאפליקציה, כך שהיא תהיה: תמיד פתיחה, תמיד שאלה או אף פעם לא פתיחה. המדיניות הזו חייבת לחול באופן שווה על כל מסנני הכוונה של URI מועמדים.
- [C-0-7] המשתמש חייב להיות מסוגל לראות רשימה של מסנני הכוונה ל-URI שעומדים בקריטריונים.
- הטמעת המכשיר עשויה לספק למשתמש את היכולת לשנות את ההגדרות של מסנני הכוונה ספציפיים של URI שהתקבלו ואשר אומתו, על בסיס מסנן כוונה לכל אחד מהם.
- [C-0-8] אם ההטמעה במכשיר מאפשרת לחלק ממסנני הכוונה של כתובות URI מועמדות לעבור אימות, בעוד שחלק אחר לא עובר, ההטמעה במכשיר חייבת לספק למשתמשים את היכולת להציג ולשנות את ההגדרות של מסנני הכוונה הספציפיים של כתובות URI מועמדות.
3.2.3.3. מרחבי שמות של כוונות
- [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. כוונות מותנות של אפליקציות
ב-Android יש הגדרות שמאפשרות למשתמשים לבחור בקלות את אפליקציות ברירת המחדל שלהם, למשל למסך הבית או להודעות SMS.
במקרים שבהם זה הגיוני, הטמעות במכשירים חייבות לספק תפריט הגדרות דומה ולהיות תואמות לדפוס של מסנן הכוונה ולשיטות ה-API שמתוארות במסמכי התיעוד של ה-SDK, כפי שמתואר בהמשך.
אם הטמעות של מכשירים מדווחות על android.software.home_screen
, הן:
- [C-1-1] חובה לפעול בהתאם לכוונה של
android.settings.HOME_SETTINGS
להציג תפריט של הגדרות ברירת מחדל של אפליקציות במסך הבית.
אם הטמעות של מכשירים מדווחות על android.hardware.telephony.calling
, הן:
[C-2-1] חובה לספק תפריט הגדרות שיפעיל את הכוונה
android.provider.Telephony.ACTION_CHANGE_DEFAULT
כדי להציג תיבת דו-שיח לשינוי אפליקציית ברירת המחדל ל-SMS.[C-2-2] חובה לפעול בהתאם לכוונה של
android.telecom.action.CHANGE_DEFAULT_DIALER
להציג תיבת דו-שיח כדי לאפשר למשתמש לשנות את אפליקציית ברירת המחדל של הטלפון.- חובה להשתמש בממשק המשתמש של אפליקציית 'טלפון' שמוגדרת כברירת מחדל על ידי המשתמש לשיחות נכנסות ויוצאות, מלבד שיחות חירום שבהן תתבצע שימוש באפליקציית 'טלפון' שהותקנה מראש.
[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] חובה לפעול בהתאם ל-Intents android.intent.action.SENDTO ו-android.intent.action.VIEW ולספק פעילות לשליחה/להצגה של הודעות SMS.
[C-SR-1] מומלץ מאוד לתמוך ב-Intents android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW ו-android.intent.action.DIAL באמצעות אפליקציית חיוג שהוטענה מראש, שיכולה לטפל ב-Intents האלה ולספק את הביצוע כפי שמתואר ב-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 ו-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 ולהציג פעילות מערכת שמבקשת מצב גלוי.
אם הטמעות במכשירים תומכות בתכונה 'נא לא להפריע', הן:
- [C-6-1] חובה להטמיע פעילות שתגיב ל-intent
ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS
. כשמשתמשים ב-UI_MODE_TYPE_NORMAL, הפעילות הזו חייבת להיות פעילות שבה המשתמש יכול להעניק או לדחות לאפליקציה גישה להגדרות של מדיניות ההתראות.
אם הטמעות במכשיר מאפשרות למשתמשים להשתמש בשיטות קלט של צד שלישי במכשיר, הן:
- [C-7-1] חובה לספק מנגנון שגלוי למשתמשים כדי להוסיף ולהגדיר שיטות קלט של צד שלישי בתגובה לכוונה
android.settings.INPUT_METHOD_SETTINGS
.
אם הטמעות המכשירים תומכות בשירותי נגישות של צד שלישי, הן:
- [C-8-1] חובה לפעול בהתאם לכוונה של
android.settings.ACCESSIBILITY_SETTINGS
לספק מנגנון שזמין למשתמשים כדי להפעיל ולהשבית את שירותי הנגישות של הצד השלישי לצד שירותי הנגישות שהועלו מראש.
אם הטמעות במכשירים כוללות תמיכה ב-Wi-Fi Easy Connect ומאפשרות גישה לפונקציונליות באפליקציות של צד שלישי, הן:
- [C-9-1] חובה להטמיע את ממשקי ה-API של ה-Intent Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI כפי שמתואר במסמכי התיעוד של ה-SDK.
אם הטמעות במכשירים מספקות את מצב חיסכון הנתונים, הן:
- [C-10-1] חובה לספק ממשק משתמש בהגדרות, שמטפל בכוונה
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
ומאפשר למשתמשים להוסיף אפליקציות לרשימת ההיתרים או להסיר אותן ממנה.
אם הטמעות במכשירים לא מספקות את מצב חיסכון הנתונים, הן:
- [C-11-1] חובה שתהיה פעילות שמטפלת ב-Intent
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
, אבל אפשר להטמיע אותה כפעולה ללא פעולה (no-op).
אם הטמעות של מכשירים מכריזות על תמיכה במצלמה באמצעות android.hardware.camera.any
, הן:
- [C-12-3] חובה לטפל בכוונות הבאות
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
ו-MediaStore.ACTION_VIDEO_CAPTURE
באפליקציות Android מותקנות מראש, ורק להן לאפשר לטפל בהן, כפי שמתואר במסמך ה-SDK.
אם הטמעות של מכשירים מדווחות על android.software.device_admin
, הן:
[C-13-1] חובה לפעול בהתאם לכוונה
android.app.action.ADD_DEVICE_ADMIN
להפעיל ממשק משתמש כדי להנחות את המשתמש להוסיף את האדמין של המכשיר למערכת (או לאפשר לו לדחות אותו).[C-13-2] חובה לפעול בהתאם ל-intents android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD ו-android.app.action.START_ENCRYPTION, ולכלול פעילות שמספקת את הטיפול ב-intents האלה כפי שמתואר ב-SDK כאן.
אם הטמעות במכשירים מכריזות על דגל התכונה android.software.autofill
, הן:
- [C-14-1] חובה להטמיע באופן מלא את ממשקי ה-API של
AutofillService
ושלAutofillManager
, ולפעול בהתאם לכוונה של android.settings.REQUEST_SET_AUTOFILL_SERVICE להציג תפריט הגדרות ברירת מחדל של האפליקציה כדי להפעיל ולהשבית את המילוי האוטומטי ולשנות את שירות המילוי האוטומטי שמוגדר כברירת מחדל עבור המשתמש.
אם הטמעות במכשירים כוללות אפליקציה שמותקנת מראש, או אם רוצים לאפשר לאפליקציות של צד שלישי לגשת לנתוני הסטטיסטיקה של השימוש, צריך:
- [C-SR-2] מומלץ מאוד לספק מנגנון שגלוי למשתמשים כדי להעניק או לבטל גישה לנתוני השימוש בתגובה ל-intent android.settings.ACTION_USAGE_ACCESS_SETTINGS לאפליקציות שמצהירות על ההרשאה
android.permission.PACKAGE_USAGE_STATS
.
אם מטרת הטמעות במכשירים היא לא לאפשר לאף אפליקציה, כולל אפליקציות מותקנות מראש, לגשת לנתוני סטטיסטיקת השימוש, צריך:
- [C-15-1] עדיין חייבת להיות פעילות שמטפלת בדפוס ה-intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, אבל חובה להטמיע אותו כפעולה ללא תוצאה (no-op), כלומר עם התנהגות זהה לזו שמתרחשת כשהמשתמש נדחה לקבלת גישה.
אם הטמעות במכשירים מציגות קישורים לפעילויות שצוינו על ידי AutofillService_passwordsActivity בהגדרות, או קישורים לסיסמאות של משתמשים באמצעות מנגנון דומה, הן:
- [C-16-1] חובה להציג קישורים כאלה לכל שירותי המילוי האוטומטי המותקנים.
אם הטמעות במכשירים תומכות ב-VoiceInteractionService
ויש בהן יותר מאפליקציה אחת שמשתמשת ב-API הזה בכל פעם, הן:
- [C-18-1] חובה לפעול בהתאם לכוונה של
android.settings.ACTION_VOICE_INPUT_SETTINGS
להציג תפריט הגדרות ברירת מחדל של אפליקציה לקלט קולי ולעזרה.
אם הטמעות במכשירים מדווחות על התכונה android.hardware.audio.output
, הן:
- [C-SR-3] מומלץ מאוד להוסיף פעילות כדי לספק השלמה ל-intents android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA ו-android.speech.tts.engine.GET_SAMPLE_TEXT, כפי שמתואר ב-SDK כאן.
מערכת Android כוללת תמיכה בשומרי מסך אינטראקטיביים, שנקראים בעבר 'חלומות'. שומרי מסך מאפשרים למשתמשים לקיים אינטראקציה עם אפליקציות כשהמכשיר מחובר למקור חשמל, לא פעיל או מחובר למעמד. הטמעות במכשירים:
- צריך לכלול תמיכה בשומרי מסך ולספק אפשרות להגדרות שמאפשרת למשתמשים להגדיר שומרי מסך בתגובה לכוונה
android.settings.DREAM_SETTINGS
.
יצירת דרישות חדשות
אם הטמעות במכשירים מדווחות על android.hardware.nfc.uicc
או על android.hardware.nfc.ese
, הן:
- [C-19-1] חובה להטמיע את ה-Intent API NfcAdapter.ACTION_TRANSACTION_DETECTED (כמו 'EVT_TRANSACTION' שמוגדר במפרט הטכני TS.26 של GSM Association – דרישות למכשירי NFC).
סיום הדרישות החדשות
3.2.4. פעילויות במסך משני או במספר מסכים
אם הטמעות במכשירים מאפשרות להפעיל פעילויות רגילות ב-Android ביותר ממסך אחד, הן:
- [C-1-1] חובה להגדיר את הדגל
android.software.activities_on_secondary_displays
. - [C-1-2] חובה להבטיח תאימות ל-API דומה לפעילות שפועלת במסך הראשי.
- [C-1-3] חובה להציג את הפעילות החדשה באותו מסך שבו הוצגה הפעילות שהפעילה אותה, כשהפעילות החדשה מופעלת בלי לציין מסך יעד באמצעות ה-API של
ActivityOptions.setLaunchDisplayId()
. - [C-1-4] חובה להשמיד את כל הפעילויות כשמסירים תצוגה עם הדגל
Display.FLAG_PRIVATE
. - [C-1-5] חובה להסתיר את התוכן באופן מאובטח בכל המסכים כשהמכשיר נעול באמצעות מסך נעילה מאובטח, אלא אם האפליקציה בוחרת להופיע מעל מסך הנעילה באמצעות ה-API של
Activity#setShowWhenLocked()
. - צריך להגדיר את הערך
android.content.res.Configuration
שמתאים לתצוגה הזו כדי שהיא תוצג, תפעל בצורה תקינה ותשמור על תאימות אם פעילות מסוימת תושק בתצוגה המשנית.
אם הטמעות במכשירים מאפשרות להפעיל פעילויות Android רגילות במסכים משניים, ובמסך משני מוגדר הדגל android.view.Display.FLAG_PRIVATE:
- [C-3-1] רק הבעלים של המסך, המערכת והפעילויות שכבר מוצגות במסך הזה חייבים להיות מסוגלים להפעיל אותו. כל אחד יכול להפעיל את האפליקציה במסך עם הדגל android.view.Display.FLAG_PUBLIC.
3.3. תאימות ל-API מקורי
תאימות לקוד מקורי היא אתגר. לכן, למטמיעים של המכשירים יש:
- [C-SR-1] מומלץ מאוד להשתמש בהטמעות של הספריות שמפורטות בהמשך מפרויקט Android Open Source Project.
3.3.1. ממשקי Application Binary Interface
קוד בייט מטופל של Dalvik יכול להפעיל קוד מקורי שסופק בקובץ .apk
של האפליקציה כקובץ ELF .so
שעבר הידור לארכיטקטורת החומרה המתאימה של המכשיר. מאחר שקוד מקורי תלוי מאוד בטכנולוגיית המעבד הבסיסית, מערכת Android מגדירה מספר ממשקי Application Binary Interface (ABI) ב-Android NDK.
הטמעות במכשירים:
- [C-0-1] חייב להיות תואם ל-Android NDK ABI אחד או יותר.
- [C-0-2] חובה לכלול תמיכה בקוד שפועל בסביבה המנוהלת כדי לבצע קריאה לקוד מקומי, באמצעות סמנטיקה רגילה של Java Native Interface (JNI).
- [C-0-3] חייב להיות תואם למקור (כלומר תואם לכותרת) ולקובץ הבינארי (עבור ה-ABI) של כל ספרייה נדרשת ברשימה שבהמשך.
- [C-0-5] חובה לדווח במדויק על ממשק ה-ABI (Application Binary Interface) המקורי שנתמך במכשיר, באמצעות הפרמטרים
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 כבר לא תומך ב-target הזה)armeabi-v7a
arm64-v8a
x86
x86-64
[C-0-7] חובה להפוך את כל הספריות הבאות, שמספקות ממשקי API מקומיים, לזמינות לאפליקציות שכוללות קוד מקומי:
- libaaudio.so (תמיכה באודיו מקורי של AAudio)
- libamidi.so (תמיכה ב-MIDI מקורית, אם מוצגת הצהרה על התכונה
android.software.midi
כפי שמתואר בקטע 5.9) - libandroid.so (תמיכה בפעילות Native ב-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] חובה לציין ב-
/vendor/etc/public.libraries.txt
ספריות נוספות שאינן AOSP שחשופות ישירות לאפליקציות של צד שלישי.[C-0-10] אסור לחשוף אפליקציות צד שלישי שמטרגטות API ברמה 24 ואילך לספריות מקוריות אחרות, שהוגדרו וסופק ב-AOSP כספריות מערכת, כי הן שמורות.
[C-0-11] חובה לייצא את כל סמלי הפונקציות של OpenGL ES 3.1 ו-Android Extension Pack, כפי שמוגדרים ב-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 Open Source Project.
חשוב לזכור שיכול להיות שבגרסאות עתידיות של Android תהיה תמיכה ב-ABIs נוספים.
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, באמצעות תמיכה במעבד מקורי או באמצעות הדמיה של תוכנה:
- הוראות SWP ו-SWPB.
- פעולות מחסום CP15ISB, CP15DSB ו-CP15DMB.
[C-2-3] חובה לכלול תמיכה בתוסף Advanced SIMD (נקרא גם NEON).
3.4. תאימות לאינטרנט
3.4.1. תאימות ל-WebView
אם ההטמעות במכשירים מספקות הטמעה מלאה של API android.webkit.Webview
, הן:
- [C-1-1] חובה לדווח על
android.software.webview
. - [C-1-2] חובה להשתמש בגרסה המאוחדת של פרויקט Chromium מהפרויקט של Android בקוד פתוח (upstream) בהסתעפות Android 14, כדי להטמיע את ה-API של
android.webkit.WebView
. [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.RELEASE.
- המחרוזת $(MODEL) יכולה להיות ריקה, אבל אם היא לא ריקה, היא חייבת להיות בעלת אותו ערך כמו android.os.Build.MODEL.
- אפשר להשמיט את 'Build/$(BUILD)', אבל אם הוא מופיע, המחרוזת $(BUILD) חייבת להיות זהה לערך של android.os.Build.ID.
- הערך של המחרוזת $(CHROMIUM_VER) חייב להיות הגרסה של Chromium בפרויקט הקוד הפתוח של Android במקור (upstream).
- הטמעות של מכשירים עשויות להשמיט את המילה 'נייד' במחרוזת של סוכן המשתמש.
רכיב WebView צריך לכלול תמיכה בכמה שיותר תכונות HTML5, ואם הוא תומך בתכונה, הוא צריך לעמוד במפרט HTML5.
[C-1-4] חובה להציג את התוכן שסופק או את התוכן של כתובת ה-URL המרוחקת בתהליך שונה מהאפליקציה שיוצרת את מופע ה-WebView. באופן ספציפי, לתהליך המפרסם הנפרד חייבות להיות הרשאות נמוכות יותר, הוא צריך לפעול בתור מזהה משתמש נפרד, אין לו גישה לספריית הנתונים של האפליקציה, אין לו גישה ישירה לרשת ויש לו גישה רק לשירותי המערכת הנדרשים למינימום דרך Binder. ההטמעה של WebView ב-AOSP עומדת בדרישות האלה.
הערה: אם הטמעות המכשיר הן של 32 ביט או שהן מכריזות על דגל התכונה android.hardware.ram.low
, הן פטורות מ-C-1-3.
3.4.2. תאימות לדפדפנים
אם הטמעות במכשירים כוללות אפליקציית דפדפן עצמאית לגלישה כללית באינטרנט, הן:
- [C-1-1] חובה לתמוך בכל אחד מממשקי ה-API האלה שמשויכים ל-HTML5:
- [C-1-2] חובה לתמוך ב-webstorage API של HTML5/W3C, ומומלץ לתמוך ב-IndexedDB API של HTML5/W3C. חשוב לזכור שגופי התקנים לפיתוח אינטרנט עוברים להעדיף את IndexedDB על פני webstorage, ולכן IndexedDB צפוי להפוך לרכיב נדרש בגרסה עתידית של Android.
- מותר לשלוח מחרוזת של סוכן משתמש בהתאמה אישית באפליקציית הדפדפן העצמאית.
- צריך להטמיע תמיכה בחלקים רבים ככל האפשר של HTML5 באפליקציית הדפדפן העצמאית (בין אם היא מבוססת על אפליקציית הדפדפן WebKit במקור ובין אם היא החלפה של צד שלישי).
עם זאת, אם ההטמעות במכשירים לא כוללות אפליקציית דפדפן עצמאית, הן:
- [C-2-1] חובה להמשיך לתמוך בדפוסי הכוונה הציבוריים כפי שמתואר בקטע 3.2.3.1.
3.5. תאימות התנהגות של API
הטמעות במכשירים:
- [C-0-9] חובה לוודא שתוחל תאימות התנהגות של API בכל האפליקציות המותקנות, אלא אם הן מוגבלות כפי שמתואר בקטע 3.5.1.
- [C-0-10] אסור להטמיע את הגישה של רשימת ההיתרים שמבטיחה תאימות התנהגות של API רק לאפליקציות שנבחרו על ידי מפתחי המכשירים.
ההתנהגויות של כל סוגי ה-API (מנוהל, רך, מקורי ואינטרנט) חייבות להיות עקביות עם ההטמעה המועדפת של Android Open Source Project ב-upstream. תחומים ספציפיים של תאימות:
- [C-0-1] אסור למכשירים לשנות את ההתנהגות או את הסמנטיקה של כוונה רגילה.
- [C-0-2] אסור לשנות במכשירים את מחזור החיים או את סמנטיקה של מחזור החיים של סוג מסוים של רכיב מערכת (כמו Service, Activity, ContentProvider וכו').
- [C-0-3] אסור למכשירים לשנות את הסמנטיקה של הרשאה רגילה.
- אסור למכשירים לשנות את המגבלות שחלות על אפליקציות שפועלות ברקע.
באופן ספציפי יותר, לגבי אפליקציות ברקע:
- [C-0-4] חובה להפסיק את ביצוע הפונקציות החוזרות (callbacks) שנרשמו על ידי האפליקציה כדי לקבל את הפלט מ-
GnssMeasurement
ו-GnssNavigationMessage
. - [C-0-5] חובה להגביל את התדירות של העדכונים שסופקו לאפליקציה באמצעות סיווג ה-API
LocationManager
או השיטהWifiManager.startScan()
. - [C-0-6] אם האפליקציה מטרגטת רמת API 25 ואילך, אסור לאפשר לה לרשום מקבלי שידור (broadcast receivers) לשידורים המשתמעים של כוונות סטנדרטיות ל-Android במניפסט של האפליקציה, אלא אם הכוונה לשידור דורשת הרשאה
"signature"
או"signatureOrSystem"
protectionLevel
או שהיא נכללת ברשימת ההחרגות. - [C-0-7] אם האפליקציה מטרגטת רמת API 25 ואילך, היא חייבת להפסיק את שירותי הרקע של האפליקציה, בדיוק כמו שהאפליקציה הייתה מפעילה את ה-method
stopSelf()
של השירותים, אלא אם האפליקציה מופיעה ברשימת ההיתרים הזמנית כדי לטפל במשימה שגלויה למשתמש. - [C-0-8] אם האפליקציה מטרגטת לרמת API 25 ואילך, חובה לשחרר את ה-wakelocks שהאפליקציה מחזיקה.
- [C-0-4] חובה להפסיק את ביצוע הפונקציות החוזרות (callbacks) שנרשמו על ידי האפליקציה כדי לקבל את הפלט מ-
- [C-0-11] מכשירים חייבים להחזיר את ספקי האבטחה הבאים בתור שבעת ערכי המערך הראשונים מהשיטה
Security.getProviders()
, בסדר הנתון ובשמות ובכיתות הנתונים (כפי שהם מוחזרים על ידיProvider.getName()
), אלא אם האפליקציה שינתה את הרשימה באמצעותinsertProviderAt()
אוremoveProvider()
. יכול להיות שמכשירים יחזירו ספקים נוספים אחרי רשימת הספקים שמפורטת בהמשך.- AndroidNSSP –
android.security.net.config.NetworkSecurityConfigProvider
- AndroidOpenSSL –
com.android.org.conscrypt.OpenSSLProvider
- CertPathProvider –
sun.security.provider.CertPathProvider
- AndroidKeyStoreBCWorkaround –
android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
- BC –
com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
- HarmonyJSSE –
com.android.org.conscrypt.JSSEProvider
- AndroidKeyStore –
android.security.keystore.AndroidKeyStoreProvider
- AndroidNSSP –
הרשימה שלמעלה היא חלקית. חבילה לבדיקות תאימות (CTS) בודקת חלקים משמעותיים בפלטפורמה כדי לבדוק את התאימות ההתנהגותית, אבל לא את כולם. באחריות המטמיע לוודא תאימות התנהגותית לפרויקט הקוד הפתוח של Android. לכן, למטמיעים של מכשירים מומלץ להשתמש בקוד המקור שזמין דרך Android Open Source Project, במידת האפשר, במקום להטמיע מחדש חלקים משמעותיים במערכת.
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 ל-method 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] חובה להחיל את ההגבלה על האפליקציה למשתמש רק אם יש ראיות לכך שהמשתמש לא השתמש באפליקציה במשך תקופה מסוימת. מומלץ מאוד שהמשך הזמן יהיה חודש אחד או יותר. השימוש חייב להיות מוגדר על ידי אינטראקציה מפורשת של משתמש דרך ה-API UsageStats#getLastTimeVisible() או על ידי כל דבר שגורם לאפליקציה לצאת ממצב העצירה הכפויה, כולל קישורי שירות, קישורי ספקי תוכן, שידורים מפורשים וכו'. המעקב אחר האירועים האלה יתבצע באמצעות ה-API החדש UsageStats#getLastTimeAnyComponentUsed().
- [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 לבדיקה או למערכת. 'רכיב שחשוף לכולם' הוא כל מבנה שלא מעוטר בסמן '@hide' כפי שמשתמשים בו בקוד המקור של Android במקור.
למטמיעים של מכשירים מותר לשנות את ההטמעה הבסיסית של ממשקי ה-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 מותאמים אישית בשפות מקומיות, מחוץ לממשקי ה-API של NDK, אבל ממשקי ה-API המותאמים אישית:
- [C-1-1] אסור שהקוד יהיה בספריית NDK או בספרייה שבבעלות ארגון אחר, כפי שמתואר כאן.
אם מי שמטמיע את המכשיר רוצה לשפר אחד ממרחב השמות של החבילות שמפורטות למעלה (למשל, להוסיף פונקציונליות חדשה ומועילה ל-API קיים או להוסיף API חדש), הוא צריך להיכנס לאתר source.android.com ולהתחיל בתהליך של הוספת שינויים וקוד, בהתאם למידע באתר הזה.
חשוב לזכור שההגבלות שלמעלה תואמות למוסכמות הסטנדרטיות למתן שמות לממשקי API בשפת התכנות Java. המטרה של הקטע הזה היא פשוט לחזק את המוסכמות האלה ולהפוך אותן למחייבות באמצעות הכללה בהגדרת התאימות הזו.
3.7. תאימות בסביבת זמן הריצה
הטמעות במכשירים:
[C-0-1] חובה לתמוך בפורמט המלא של קובץ Dalvik הפעלה (DEX) ובסמנטיקה ומפרט של קוד בינארי של Dalvik.
[C-0-2] חובה להגדיר את זמני הריצה של Dalvik כך שיוקצו זיכרון בהתאם לפלטפורמת Android של upstream, כפי שמפורט בטבלה הבאה. (הגדרות של גודל המסך ודחיסות המסך מפורטות בקטע 7.1.1).
צריך להשתמש ב-Android RunTime (ART), בהטמעה של פורמט Dalvik Executable Format ב-upstream ובמערכת ניהול החבילות של ההטמעה.
מומלץ להריץ בדיקות fuzz במצבי ביצוע שונים ובארכיטקטורות טירגוט שונות כדי להבטיח את היציבות של סביבת זמן הריצה. אפשר לעיין במאמרים על JFuzz ו-DexFuzz באתר של פרויקט הקוד הפתוח של Android.
חשוב לדעת: ערכי הזיכרון שצוינו בהמשך נחשבים לערכים מינימליים, ויכול להיות שההטמעות במכשירים יוקצו יותר זיכרון לכל אפליקציה.
פריסת המסך | דחיסות מסך | נפח זיכרון מינימלי לאפליקציה |
---|---|---|
Android Watch | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160dpi (mdpi) | ||
180 dpi (180dpi) | ||
200 dpi (200dpi) | ||
213dpi (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 | |
480dpi (xxhdpi) | 88MB | |
560 dpi (560dpi) | 112MB | |
640dpi (xxxhdpi) | 154MB | |
קטן/רגיל | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160dpi (mdpi) | ||
180 dpi (180dpi) | 48MB | |
200 dpi (200dpi) | ||
213dpi (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 | |
480dpi (xxhdpi) | 128MB | |
560 dpi (560dpi) | 192MB | |
640dpi (xxxhdpi) | 256MB | |
גדולה | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | 48MB | |
160dpi (mdpi) | ||
180 dpi (180dpi) | 80MB | |
200 dpi (200dpi) | ||
213dpi (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 | |
480dpi (xxhdpi) | 256MB | |
560 dpi (560dpi) | 384MB | |
640dpi (xxxhdpi) | 512MB | |
xlarge | 120 dpi (ldpi) | 48MB |
140 dpi (140dpi) | 80MB | |
160dpi (mdpi) | ||
180 dpi (180dpi) | 96MB | |
200 dpi (200dpi) | ||
213dpi (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 | |
480dpi (xxhdpi) | 384MB | |
560 dpi (560dpi) | 576MB | |
640dpi (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] חובה להציג למשתמש בקשה לפני שמוסיפים קיצור דרך שנבקש על ידי אפליקציות באמצעות שיטת ה-API
ShortcutManager.requestPinShortcut()
. - [C-2-3] חובה לתמוך בקיצורי דרך מוצמדים ובקיצורי דרך דינמיים וסטטיים, כפי שמתואר בדף קיצורי הדרך לאפליקציות.
לעומת זאת, אם הטמעות במכשירים לא תומכות בהצמדה של קיצורי דרך באפליקציה, הן:
- [C-3-1] חובה לדווח על
false
עבורShortcutManager.isRequestPinShortcutSupported()
.
אם הטמעות במכשירים מטמיעות מרכז אפליקציות שמספק גישה מהירה למקשי הקיצור הנוספים שסופקו על ידי אפליקציות צד שלישי דרך ה-API ShortcutManager, הן:
- [C-4-1] חובה לתמוך בכל תכונות קיצור הדרך המתועדות (למשל, קיצורי דרך סטטיים ודינמיים, קיצורי דרך מוצמדים) ולהטמיע באופן מלא את ממשקי ה-API של סוג ה-API
ShortcutManager
.
אם הטמעות במכשירים כוללות אפליקציית מרכז אפליקציות שמוגדרת כברירת מחדל ומציגה תגים לסמלי האפליקציות, הן:
- [C-5-1] חובה לפעול בהתאם לשיטת ה-API
NotificationChannel.setShowBadge()
. במילים אחרות, אם הערך מוגדר כ-true
, מוצגת סמנטיקה חזותית שמשויכת לסמל האפליקציה. אם הערך מוגדר כ-false
בכל ערוצי ההתראות של האפליקציה, לא מוצגת סמנטיקה חזותית של תגים בסמל האפליקציה. - יכולים לשנות את התגים של סמל האפליקציה לתוכנית התגים הקניינית שלהם, אם אפליקציות של צד שלישי מציינות תמיכה בתוכנית התגים הקניינית באמצעות שימוש בממשקי API קנייניים, אבל צריכים להשתמש במשאבים ובערכים שסופקו באמצעות ממשקי ה-API של תגי ההתראות שמתוארים בSDK, כמו ה-API של
Notification.Builder.setNumber()
ושלNotification.Builder.setBadgeIconType()
.
אם הטמעות במכשירים תומכות בסמלים מונוכרומטיים, הסמלים האלה:
- [C-6-1] חובה להשתמש בהם רק כשהמשתמש מפעיל אותם במפורש (למשל דרך ההגדרות או תפריט הבחירה של הטפט).
3.8.2. ווידג'טים
מערכת Android תומכת בווידג'טים של אפליקציות של צד שלישי על ידי הגדרת סוג רכיב, API וחיי מחזור תואמים שמאפשרים לאפליקציות לחשוף AppWidget למשתמש הקצה.
אם הטמעות במכשירים תומכות בווידג'טים של אפליקציות של צד שלישי, הן:
- [C-1-1] חובה להצהיר על תמיכה בתכונה
android.software.app_widgets
של הפלטפורמה. [C-1-2] חובה לכלול תמיכה מובנית ב-AppWidgets ולהציג אפשרויות בממשק המשתמש להוספה, להגדרה, להצגה ולהסרה של AppWidgets
[C-1-3] חובה שאפשר יהיה להציג ב-widget בגודל רשת סטנדרטי 4 x 4. פרטים נוספים זמינים בהנחיות לעיצוב של ווידג'טים של אפליקציות במסמכי התיעוד של Android SDK.
יכול להיות שתהיה תמיכה בווידג'טים של אפליקציות במסך הנעילה.
אם הטמעות במכשירים תומכות בווידג'טים של אפליקציות צד שלישי ובהצמדה של קיצורי דרך באפליקציות, הן:
- [C-2-1] חובה לדווח על
true
עבורAppWidgetManager.html.isRequestPinAppWidgetSupported()
. - [C-2-2] חובה להציג למשתמש בקשה לפני שמוסיפים קיצור דרך שנבקש על ידי אפליקציות באמצעות שיטת ה-API
AppWidgetManager.requestPinAppWidget()
.
3.8.3. התראות
Android כולל ממשקי API של Notification
ושל NotificationManager
שמאפשרים למפתחי אפליקציות של צד שלישי להודיע למשתמשים על אירועים חשובים ולמשוך את תשומת הלב שלהם באמצעות רכיבי החומרה (למשל, צליל, רטט ואור) ותכונות התוכנה (למשל, חלונית ההתראות, שורת המערכת) של המכשיר.
3.8.3.1. הצגת ההתראות
אם הטמעות במכשירים מאפשרות לאפליקציות צד שלישי להודיע למשתמשים על אירועים משמעותיים, הן:
- [C-1-1] חובה לתמוך בהתראות שמשתמשות בתכונות חומרה, כפי שמתואר במסמכי התיעוד של ה-SDK, ובמידת האפשר עם חומרת ההטמעה של המכשיר. לדוגמה, אם הטמעת המכשיר כוללת ויברטור, חובה להטמיע בצורה נכונה את ממשקי ה-API של הרטט. אם הטמעה של מכשיר חסרה חומרה, צריך להטמיע את ממשקי ה-API התואמים כ-no-ops. התנהגות זו מפורטת בהרחבה בקטע 7.
- [C-1-2] חובה להציג בצורה נכונה את כל המשאבים (סמלים, קובצי אנימציה וכו') שסופקו ב-API או במדריך הסגנון של הסמלים בסרגל הסטטוס או בסרגל המערכת, למרות שאפשר לספק חוויית משתמש חלופית להתראות מזו שסופקה בהטמעת העזר של Android Open Source.
- [C-1-3] חובה לפעול בהתאם להתנהגויות המתוארות בממשקי ה-API ולהטמיע אותן בצורה תקינה כדי לעדכן, להסיר ולקבץ התראות.
- [C-1-4] חובה לספק את כל ההתנהגות של ה-API NotificationChannel שמתועדת ב-SDK.
- [C-1-5] חובה לספק למשתמש אפשרות לחסום ולשנות התראה מסוימת של אפליקציה של צד שלישי לכל ערוץ וחבילת אפליקציות.
- [C-1-6] חובה גם לספק למשתמש אפשרות להציג ערוצי התראות שנמחקו.
[C-1-7] חובה להציג בצורה נכונה את כל המשאבים (תמונות, סטיקרים, סמלים וכו') שסופקו באמצעות Notification.MessagingStyle לצד טקסט ההתראה, ללא אינטראקציה נוספת של המשתמש. לדוגמה, חובה להציג את כל המשאבים, כולל הסמלים שסופקו באמצעות android.app.Person, בשיחה קבוצתית שמוגדרת באמצעות setGroupConversation.
[C-SR-1] מומלץ מאוד לספק למשתמשים אפשרות לשלוט בהתראות שנחשפות לאפליקציות שקיבלו את ההרשאה 'האזנה להתראות'. רמת הפירוט חייבת להיות כזו שמאפשרת למשתמש לקבוע לכל מאזין התראות אילו סוגי התראות יתקבלו על ידו. הסוגים חייבים לכלול התראות מסוג 'שיחות', 'התראות', 'שקטות' ו'התראות פעילות חשובות'.
[C-SR-2] מומלץ מאוד לספק למשתמשים אפשרות לציין אפליקציות שלא יקבלו התראות ממאזין התראות ספציפי.
[C-SR-3] מומלץ מאוד להציג באופן אוטומטי אפשרות למשתמש לחסום התראה של אפליקציה מסוימת של צד שלישי לכל ערוץ ולרמת חבילת האפליקציות, אחרי שהמשתמש סוגר את ההתראה הזו כמה פעמים.
צריכה להיות תמיכה בהתראות עשירות.
צריך להציג חלק מההתראות בעדיפות גבוהה יותר כ'התראות 'שימו לב''.
צריכה להיות למשתמש אפשרות להשהות התראות.
יכולים לנהל רק את החשיפה ואת התזמון של הזמנים שבהם אפליקציות צד שלישי יכולות להודיע למשתמשים על אירועים משמעותיים, כדי לצמצם בעיות בטיחות כמו הסחת דעת של הנהג.
ב-Android 11 יש תמיכה בהתראות על שיחות. אלה התראות שמשתמשות ב-MessagingStyle ומספקות מזהה קיצור דרך שפורסם של אנשים.
הטמעות במכשירים:
- [C-SR-4] מומלץ מאוד לקבץ ולהציג את ההתראות של
conversation notifications
לפני התראות שלא קשורות לשיחות, למעט התראות על שירותים שפועלים בחזית והתראות שלimportance:high
.
אם ההטמעות במכשירים תומכות ב-conversation notifications
והאפליקציה מספקת את הנתונים הנדרשים ל-bubbles
, הן:
- [C-SR-5] מומלץ מאוד להציג את השיחה הזו כבועה. הטמעת AOSP עומדת בדרישות האלה באמצעות ממשק המשתמש, ההגדרות והמרכז להפעלת אפליקציות שמוגדרים כברירת מחדל.
אם הטמעות במכשירים תומכות בהתראות עשירות, הן:
- [C-2-1] חובה להשתמש במשאבים המדויקים שסופקו באמצעות סיווג ה-API
Notification.Style
ותת-הסיווגים שלו עבור רכיבי המשאבים המוצגים. - צריך להציג כל רכיב משאב (למשל, סמל, כותרת וטקסט סיכום) שמוגדר בכיתה של ה-API
Notification.Style
ובכיתות המשנה שלה.
התראות 'חשוב לדעת' הן התראות שמופיעות למשתמש ברגע שהן מתקבלות, ללא קשר לממשק שבו הוא נמצא. אם הטמעות במכשירים תומכות בהתראות מראש, הן:
- [C-3-1] חובה להשתמש בתצוגה ובמשאבים של התראות מראש כפי שמתואר בכיתה של ה-API
Notification.Builder
כשמוצגות התראות מראש. - [C-3-2] חובה להציג את הפעולות שסופקו דרך
Notification.Builder.addAction()
יחד עם תוכן ההתראה, ללא אינטראקציה נוספת של המשתמש, כפי שמתואר בSDK.
3.8.3.2. שירות מאזין להתראות
מערכת Android כוללת את ממשקי ה-API של NotificationListenerService
שמאפשרים לאפליקציות (אחרי שהמשתמש מפעיל אותם במפורש) לקבל עותק של כל ההתראות ברגע שהן מתפרסמות או מתעדכנות.
הטמעות במכשירים:
- [C-0-1] חייב לעדכן את ההתראות במלואן בצורה נכונה ומידית לכל שירותי המאזינים המותקנים והמופעלים על ידי משתמשים, כולל כל המטא-נתונים שמצורפים לאובייקט ההתראה.
- [C-0-2] חייבת לפעול בהתאם לקריאת ה-API של
snoozeNotification()
, לסגור את ההתראה ולבצע שיחה חוזרת אחרי משך ההשהיה שהוגדר בקריאת ה-API.
אם בהטמעות במכשירים יש למשתמש אפשרות להשהות התראות, הן:
- [C-1-1] חייב לשקף בצורה נכונה את סטטוס ההתראה שהושהתה באמצעות ממשקי ה-API הרגילים, כמו
NotificationListenerService.getSnoozedNotifications()
. - [C-1-2] חובה להפוך את האפשרות הזו לזמינה למשתמשים כדי לדחות התראות מכל אפליקציה של צד שלישי שמותקנת, אלא אם הן מגיעות משירותים מתמידים או משירותים שפועלים בחזית.
3.8.3.3. מצב 'נא לא להפריע' / מצב עדיפות
אם הטמעות המכשירים תומכות בתכונה 'נא לא להפריע' (שנקראת גם 'מצב עדיפות'), הן:
- [C-1-1] חובה, במקרים שבהם ההטמעה במכשיר מספקת למשתמש דרך להעניק או לדחות לאפליקציות של צד שלישי גישה להגדרת מדיניות ההתראות, להציג כללים אוטומטיים להתראות שנוצרו על ידי האפליקציות לצד הכללים שהוגדרו מראש על ידי המשתמש.
- [C-1-3] חובה לפעול בהתאם לערכים של
suppressedVisualEffects
שמועברים דרךNotificationManager.Policy
, ואם אפליקציה מגדירה את הדגלים SUPPRESSED_EFFECT_SCREEN_OFF או SUPPRESSED_EFFECT_SCREEN_ON, היא אמורה להציג למשתמש בתפריט ההגדרות של 'נא לא להפריע' שהאפקטים החזותיים מושבתים.
3.8.4. ממשקי Assist API
Android כולל את Assist APIs כדי לאפשר לאפליקציות לקבוע כמה מידע מההקשר הנוכחי ישותף עם העוזרת במכשיר.
אם ההטמעות במכשירים תומכות בפעולה 'עזרה', הן:
- [C-2-1] חובה לציין בבירור למשתמש הקצה מתי מתבצע שיתוף של ההקשר, באחת מהדרכים הבאות:
- בכל פעם שאפליקציית העזרה ניגשת להקשר, מוצגת תאורה לבנה סביב שולי המסך שתואמת או עולה על משך הזמן והבהירות של ההטמעה ב-Android Open Source Project.
- באפליקציית העזרה המותקנת מראש, לספק למשתמש אפשרות להיכנס לתפריט ההגדרות של הקלט הקולי והאפליקציה לסיוע תוך פחות משתי פעולות ניווט, ולשתף את ההקשר רק כשהמשתמש מפעיל את אפליקציית העזרה באופן מפורש באמצעות מילה מפתח או הקשה על מקש ניווט של אפליקציית העזרה.
- [C-2-2] האינטראקציה הייעודית להפעלת אפליקציית העזרה כפי שמתואר בקטע 7.2.3 חייבת להפעיל את אפליקציית העזרה שבחר המשתמש, כלומר האפליקציה שמטמיעה את
VoiceInteractionService
, או פעילות שמטפלת בכוונהACTION_ASSIST
.
3.8.5. התראות והודעות קצרות
אפליקציות יכולות להשתמש ב-API Toast
כדי להציג למשתמש הקצה מחרוזות קצרות לא מודאליות שנעלמות לאחר פרק זמן קצר, ולהשתמש ב-API מסוג חלון TYPE_APPLICATION_OVERLAY
כדי להציג חלונות התראה כשכבת-על מעל אפליקציות אחרות.
אם הטמעות במכשירים כוללות מסך או פלט וידאו, הן:
[C-1-1] חובה לספק למשתמש אפשרות לחסום אפליקציה כך שלא תציג חלונות התראה שמשתמשים ב-
TYPE_APPLICATION_OVERLAY
. ההטמעה של AOSP עומדת בדרישות האלה באמצעות אמצעי בקרה בסרגל ההתראות.[C-1-2] חובה לפעול בהתאם ל-Toast API ולהציג הודעות Toast מאפליקציות למשתמשים קצה באופן בולט.
3.8.6. עיצובים
מערכת Android מספקת 'עיצובים' כמנגנון לאפליקציות כדי להחיל סגנונות על פעילות או אפליקציה שלמה.
מערכת Android כוללת משפחת עיצובים של 'Holo' ו'Material', כקבוצה של סגנונות מוגדרים שמפתחי אפליקציות יכולים להשתמש בהם כדי להתאים את המראה והתחושה של העיצוב של Holo כפי שהוגדר ב-Android SDK.
אם הטמעות במכשירים כוללות מסך או פלט וידאו, הן:
- [C-1-1] אסור לשנות אף אחד ממאפייני העיצוב של Holo שנחשפים לאפליקציות.
- [C-1-2] חובה לתמוך במשפחת העיצובים 'Material' אסור לשנות אף אחד ממאפייני העיצוב של 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] כשאפליקציה מבקשת סרגל סטטוס בהיר, יש לשנות את הצבע של סמלי הסטטוס של המערכת לשחור (פרטים נוספים זמינים במאמר R.style) בהטמעות של מכשירי Android.
3.8.7. טפטים מונפשים
ב-Android מוגדר סוג רכיב, ממשק API ומחזור חיים תואמים שמאפשרים לאפליקציות לחשוף למשתמש הקצה 'טפטים חיים' אחד או יותר. טפטים דינמיים הם אנימציות, דפוסים או תמונות דומות עם יכולות קלט מוגבלות, שמוצגים כטפט מאחורי אפליקציות אחרות.
חומרה נחשבת ככזו שיכולה להריץ טפטים מונפשים באופן מהימן אם היא יכולה להריץ את כל הטפטים המונפשים, ללא הגבלות על הפונקציונליות, בקצב פריימים סביר וללא השפעות שליליות על אפליקציות אחרות. אם המגבלות בחומרה גורמות לטפטים או לאפליקציות לקרוס, לפעול בצורה לא תקינה, לצרוך יותר מדי חשמל או סוללה או לפעול בקצב פריימים נמוך באופן בלתי קביל, נחשב שהחומרה לא מסוגלת להפעיל טפטים חיים. לדוגמה, חלק מהטפטים החיים עשויים להשתמש בהקשר של OpenGL 2.0 או 3.x כדי ליצור את התוכן שלהם. טפטים חיים לא יפעלו בצורה מהימנה בחומרה שלא תומכת במספר הקשרים של OpenGL, כי השימוש של הטפטים החיים בהקשר של OpenGL עלול להתנגש עם אפליקציות אחרות שמשתמשות גם בהקשר של OpenGL.
- יש להטמיע טפטים דינמיים במכשירים שיכולים להריץ אותם באופן מהימן, כפי שמתואר למעלה.
אם הטמעות במכשירים מטמיעות טפטים מונפשים, הן:
- [C-1-1] חובה לדווח על דגל התכונה של הפלטפורמה android.software.live_wallpaper.
3.8.8. מעבר בין פעילויות
קוד המקור של Android במקור כולל את מסך הסקירה הכללית, ממשק משתמש ברמת המערכת למעבר בין משימות ולהצגת פעילויות ומשימות שנכנסתם אליהן לאחרונה באמצעות תמונה ממוזערת של המצב הגרפי של האפליקציה ברגע שבו המשתמש עזב אותה בפעם האחרונה.
הטמעות במכשירים, כולל מקש הניווט של הפריטים האחרונים כפי שמתואר בסעיף 7.2.3, עשויות לשנות את הממשק.
אם הטמעות במכשיר, כולל מקש הניווט של התכונה 'מהזמן האחרון' כפי שמתואר בסעיף 7.2.3, משנות את הממשק, הן:
- [C-1-1] חובה לתמוך בעד 7 פעילויות מוצגות.
- צריך להציג לפחות את השם של 4 פעילויות בכל פעם.
- [C-1-2] חובה להטמיע את ההתנהגות של הצמדת המסך ולספק למשתמש תפריט הגדרות כדי להפעיל או להשבית את התכונה.
- צריך להציג את צבע ההדגשה, הסמל וכותרת המסך ב'מהזמן האחרון'.
- צריך להציג אמצעי סגירה ('x'), אבל אפשר לעכב את הצגת האפשרות הזו עד שהמשתמש יבצע פעולה במסכים.
- צריך להטמיע קיצור דרך כדי לעבור בקלות לפעילות הקודמת.
- אמורה להפעיל את פעולת המעבר המהיר בין שתי האפליקציות האחרונות שהיו בשימוש, כשמקישים פעמיים על מקש הפונקציה של האפליקציות האחרונות.
- לחיצה ארוכה על מקש הפונקציות של האפליקציות האחרונות אמורה להפעיל את מצב החלוקה למספר חלונות, אם הוא נתמך.
- יכול להיות שתמונות וסרטונים שקשורים לתמונות וסרטונים אחרונים יוצגו כקבוצה שזזה יחד.
- [C-SR-1] מומלץ מאוד להשתמש בממשק המשתמש של Android במקור (או בממשק דומה שמבוסס על תמונות ממוזערות) במסך הסקירה הכללית.
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. שומרי מסך (לשעבר 'חלומות')
בקטע 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, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light – בשפות הזמינות במכשיר.
- כיסוי מלא של Unicode 7.0 של לטינית, יוונית וקירילית, כולל הטווחים A, B, C ו-D של לטינית מורחבת, וכל הגליפים בבלוק של סמלי המטבעות ב-Unicode 7.0.
- [C-1-3] אסור להסיר או לשנות את קובץ NotoColorEmoji.tff בתמונת המערכת. (אפשר להוסיף גופן אמוג'י חדש כדי לשנות את האמוג'י בקובץ NotoColorEmoji.tff).
- צריכה לתמוך בגווני עור ובאמוג'י של משפחות מגוונות, כפי שמפורט בדוח הטכני מס' 51 של Unicode.
אם הטמעות במכשירים כוללות IME, הן:
- צריך לספק למשתמש שיטת קלט לשימוש בתווי האמוג'י האלה.
מערכת Android כוללת תמיכה ברינדור של גופנים במיאנמר. בבורמה יש כמה גופנים שלא תואמים ל-Unicode, שנקראים בדרך כלל 'זוואג'י', לעיבוד שפות מיאנמר.
אם הטמעות במכשירים כוללות תמיכה בבורמזית, הן:
- [C-2-1] חובה להציג טקסט בגופן שתומך ב-Unicode כברירת מחדל. אסור להגדיר גופן שלא תומך ב-Unicode כברירת מחדל, אלא אם המשתמש בוחר בו בבורר השפות.
- [C-2-2] חובה לתמוך בגופן Unicode ובגופן שאינו תואם ל-Unicode, אם יש תמיכה בגופן שאינו תואם ל-Unicode במכשיר. אסור שגופן שלא תואם ל-Unicode יסיר או יחליף את הגופן של Unicode.
- [C-2-3] חובה להציג טקסט בגופן שלא תואם ל-Unicode רק אם צוין קוד שפה עם קוד סקריפט Qaag (למשל my-Qaag). אי אפשר להשתמש בקודים אחרים של שפות או אזורים לפי תקן ISO (מקצים, לא מקצים או שמורים) כדי להפנות לגופן לא תואם Unicode במיאנמר. מפתחי אפליקציות ומחברי דפי אינטרנט יכולים לציין את my-Qaag כקוד השפה הייעודי, כמו בכל שפה אחרת.
3.8.14. ריבוי חלונות
אם הטמעות במכשירים יכולות להציג כמה פעילויות בו-זמנית, הן:
- [C-1-1] חובה להטמיע מצבי ריבוי חלונות כאלה בהתאם להתנהגויות האפליקציה ולממשקי ה-API שמתוארים במסמכי התיעוד של Android SDK בנושא תמיכה במצב ריבוי חלונות, ותואמים לדרישות הבאות:
- [C-1-2] חובה לכבד את
android:resizeableActivity
שהוגדר על ידי אפליקציה בקובץAndroidManifest.xml
, כפי שמתואר בSDK הזה. - [C-1-3] אסור להציע מצב מסך מפוצל או מצב פורמט חופשי אם גובה המסך קטן מ-440dp ורוחבו קטן מ-440dp.
- [C-1-4] אסור לשנות את הגודל של פעילות לגודל קטן מ-220dp במצבים של חלונות מרובים, מלבד 'תמונה בתוך תמונה'.
- הטמעות של מכשירים עם גודל מסך
xlarge
אמורות לתמוך במצב 'טקסט חופשי'.
אם הטמעות במכשירים תומכות במצבים של חלונות מרובים ובמצב מסך מפוצל, הן:
- [C-2-2] חובה לחתוך את הפעילות במצב עגינה של כמה חלונות במסך מפוצל, אבל צריך להציג חלק מהתוכן שלה, אם חלון מרכז האפליקציות הוא החלון הממוקד.
- [C-2-3] חובה לפעול בהתאם לערכי
AndroidManifestLayout_minWidth
ו-AndroidManifestLayout_minHeight
שצוינו באפליקציית מרכז האפליקציות של הצד השלישי, ולא לשנות את הערכים האלה במהלך הצגת תוכן כלשהו של הפעילות במעגן.
אם הטמעות במכשירים תומכות במצבים של חלונות מרובים ובמצב 'תמונה בתוך תמונה' עם חלונות מרובים, הן:
- [C-3-1] חובה להפעיל פעילויות במצב 'תמונה בתוך תמונה' עם כמה חלונות כשהאפליקציה:
* מטרגטת לרמת API 26 ומעלה ומצהירה על
android:supportsPictureInPicture
* מטרגטת לרמת API 25 ומטה ומצהירה גם עלandroid:resizeableActivity
וגם עלandroid:supportsPictureInPicture
. - [C-3-2] חובה לחשוף את הפעולות ב-SystemUI שלהן, כפי שמצוין בפעילות ה-PIP הנוכחית, דרך ה-API
setActions()
. - [C-3-3] חובה לתמוך ביחסי גובה-רוחב שגדולים מ-1:2.39 או שווים לו, וקטנים מ-2.39:1 או שווים לו, כפי שצוין בפעילות ה-PIP דרך ה-API של
setAspectRatio()
. - [C-3-4] חובה להשתמש ב-
KeyEvent.KEYCODE_WINDOW
כדי לשלוט בחלון ה-PIP. אם מצב PIP לא מוטמע, המפתח חייב להיות זמין לפעילות שבחזית. - [C-3-5] חובה לספק למשתמש אפשרות לחסום את הצגת האפליקציה במצב PIP. ההטמעה של AOSP עומדת בדרישות האלה באמצעות אמצעי בקרה בסרגל ההתראות.
[C-3-6] חובה להקצות את הרוחב והגובה המינימליים הבאים לחלון ה-PIP כשאפליקציה לא מצהירה על ערך כלשהו עבור
AndroidManifestLayout_minWidth
ו-AndroidManifestLayout_minHeight
:- במכשירים שבהם ההגדרה של Configuration.uiMode היא לא
UI_MODE_TYPE_TELEVISION
, חייבים להקצות רוחב וגובה מינימלי של 108dp. - במכשירים שבהם הערך של Configuration.uiMode מוגדר ל-
UI_MODE_TYPE_TELEVISION
, חייבים להקצות רוחב מינימלי של 240dp וגובה מינימלי של 135dp.
- במכשירים שבהם ההגדרה של Configuration.uiMode היא לא
3.8.15. מגרעת במסך
Android תומך בחלון חתוך במסך, כפי שמתואר במסמך ה-SDK. ממשק ה-API DisplayCutout
מגדיר אזור בקצה המסך שעשוי להיות לא פונקציונלי לאפליקציה בגלל חור במסך או מסך מעוקל בקצוות.
אם ההטמעות במכשירים כוללות פריצות במסך, הן:
- [C-1-5] אסור לכלול קטעי חיתוך אם יחס הגובה-רוחב של המכשיר הוא 1.0 (1:1).
- [C-1-2] אסור לכלול יותר מחור אחד לכל קצה.
- [C-1-3] חובה לפעול בהתאם לסימונים של חתך המסך שהוגדרו על ידי האפליקציה דרך ה-API של
WindowManager.LayoutParams
, כפי שמתואר ב-SDK. - [C-1-4] חובה לדווח על ערכים נכונים לכל מדדי החיתוך שמוגדרים ב-API של
DisplayCutout
.
3.8.16. ממשק השליטה במכשירים
מערכת Android כוללת ממשקי API של ControlsProviderService
ושל Control
, שמאפשרים לאפליקציות צד שלישי לפרסם אמצעי בקרה על המכשיר כדי שהמשתמשים יוכלו לבדוק במהירות את הסטטוס ולבצע פעולות.
הדרישות הספציפיות למכשיר מפורטות בקטע 2_2_3.
3.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 הקצאת מכשיר (Provisioning)
3.9.1.1 הקצאה לבעלי המכשיר
אם הטמעות של מכשירים מגדירות את android.software.device_admin
, הן:
- [C-1-1] חובה לתמוך ברישום של לקוח מדיניות המכשיר (DPC) בתור אפליקציית הבעלים של המכשיר, כפי שמתואר בהמשך:
- כשמשתמשים ונתוני משתמשים לא מוגדרים בהטמעה במכשיר, היא:
- [C-1-5] חובה לרשום את אפליקציית ה-DPC כאפליקציית 'בעלי המכשיר' או לאפשר לאפליקציית ה-DPC לבחור אם להפוך ל'בעלי המכשיר' או ל'בעלי הפרופיל', אם המכשיר מצהיר על תמיכה בתקשורת מטווח קצר (NFC) באמצעות דגל התכונה
android.hardware.nfc
ומקבל הודעת NFC שמכילה רשומה עם סוג MIMEMIME_TYPE_PROVISIONING_NFC
. - [C-1-8] חובה לשלוח את הכוונה ACTION_GET_PROVISIONING_MODE אחרי שההקצאה של הבעלים של המכשיר מופעלת, כדי שאפליקציית ה-DPC תוכל לבחור אם להפוך לבעלים של המכשיר או לבעלים של הפרופיל, בהתאם לערכים של
android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES
, אלא אם ניתן לקבוע מההקשר שיש רק אפשרות תקפה אחת. - [C-1-9] חובה לשלוח את הכוונה ACTION_ADMIN_POLICY_COMPLIANCE לאפליקציית הבעלים של המכשיר אם הבעלים של המכשיר נוצר במהלך ההקצאה, ללא קשר לשיטת ההקצאה שבה נעשה שימוש. המשתמש לא יכול להמשיך באשף ההגדרה עד שהאפליקציה 'בעלי המכשיר' מסתיימת.
- [C-1-5] חובה לרשום את אפליקציית ה-DPC כאפליקציית 'בעלי המכשיר' או לאפשר לאפליקציית ה-DPC לבחור אם להפוך ל'בעלי המכשיר' או ל'בעלי הפרופיל', אם המכשיר מצהיר על תמיכה בתקשורת מטווח קצר (NFC) באמצעות דגל התכונה
- כשהטמעת המכשיר כוללת משתמשים או נתוני משתמשים, היא:
- [C-1-7] אסור יותר לרשום אפליקציית DPC כלשהי כאפליקציית הבעלים של המכשיר.
- כשמשתמשים ונתוני משתמשים לא מוגדרים בהטמעה במכשיר, היא:
[C-1-2] חובה להציג הודעה מתאימה בנושא גילוי נאות (כמו ההודעה שמופיעה ב-AOSP) ולקבל הסכמה מפורשת ממשתמש הקצה לפני שמגדירים אפליקציה כבעלים של המכשיר, אלא אם המכשיר מוגדר באופן פרוגרמטי למצב הדגמה בחנות הפיזית לפני האינטראקציה של משתמש הקצה במסך. אם הטמעות במכשירים מכריזות על
android.software.device_admin
, אבל כוללות גם פתרון ניהול מכשירים קנייני ומספקות מנגנון לקידום אפליקציה שמוגדרת בפתרון שלהן כ'בעלים של מכשיר' שזהה ל'בעלים של מכשיר' הרגיל, כפי שהוא מוכר בממשקי ה-API הרגילים של Android DevicePolicyManager, הן:[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 שמאפשרים לאפליקציית אמצעי בקרה למדיניות המכשיר (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] חובה להפעיל את הטיפולן של ה-intent ACTION_PROVISIONING_SUCCESSFUL בפרופיל העבודה אם הוגדר בעלים של פרופיל כשה-intent android.app.action.PROVISION_MANAGED_PROFILE הפעיל את ההקצאה, וה-DPC הטמיע את הטיפולן.
[C-1-5] חובה לשלוח את השידור ACTION_PROFILE_PROVISIONING_COMPLETE ל-DPC של פרופיל העבודה כשההקצאה מופעלת על ידי הכוונה android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-6] חובה לשלוח את הכוונה ACTION_GET_PROVISIONING_MODE אחרי שההקצאה של הבעלים של הפרופיל מופעלת, כדי שאפליקציית ה-DPC תוכל לבחור אם להפוך לבעלים של המכשיר או לבעלים של הפרופיל, למעט במקרים שבהם ההקצאה מופעלת על ידי הכוונה android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-7] חובה לשלוח את הכוונה ACTION_ADMIN_POLICY_COMPLIANCE לפרופיל העבודה כשבעל פרופיל מוגדר במהלך ההקצאה, ללא קשר לשיטת ההקצאה שבה נעשה שימוש, אלא אם ההקצאה מופעלת על ידי הכוונה android.app.action.PROVISION_MANAGED_PROFILE. המשתמש לא יכול להמשיך באשף ההגדרה עד שהאפליקציה של הבעלים של הפרופיל תסתיים.
[C-1-8] חובה לשלוח את השידור ACTION_MANAGED_PROFILE_PROVISIONED ל-DPC של הפרופיל האישי כשמגדירים בעל פרופיל, ללא קשר לשיטת הקצאת המשאבים שבה נעשה שימוש.
3.9.2 תמיכה בפרופיל מנוהל
אם הטמעות של מכשירים מגדירות את android.software.managed_users
, הן:
- [C-1-1] חובה לתמוך בפרופילים מנוהלים באמצעות ממשקי ה-API של
android.app.admin.DevicePolicyManager
. - [C-1-2] חובה לאפשר ליצור פרופיל מנוהל אחד בלבד.
- [C-1-3] חובה להשתמש בתג סמל (בדומה לתג העבודה של AOSP upstream) כדי לייצג את האפליקציות והווידג'טים המנוהלים ואת רכיבי ממשק המשתמש האחרים עם תגים, כמו 'מהזמן האחרון' ו'התראות'.
- [C-1-4] חובה להציג סמל התראה (בדומה לתג העבודה של AOSP upstream) כדי לציין מתי המשתמש נמצא באפליקציה של פרופיל מנוהל.
- [C-1-5] חובה להציג הודעה קופצת שמציינת שהמשתמש נמצא בפרופיל המנוהל אם והפעם שהמכשיר מתעורר (ACTION_USER_PRESENT) והאפליקציה שבחזית נמצאת בפרופיל המנוהל.
- [C-1-6] אם קיים פרופיל מנוהל, חובה להציג תכונה חזותית ב 'בורר' של הכוונה כדי לאפשר למשתמש להעביר את הכוונה מהפרופיל המנוהל למשתמש הראשי או להפך, אם האפשרות הזו מופעלת על ידי ה-Device Policy Controller.
- [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
ולהציג ממשק להגדרת פרטי כניסה נפרדים למסך הנעילה של הפרופיל המנוהל. - פרטי הכניסה של מסך הנעילה בפרופיל המנוהל חייבים להשתמש באותם מנגנונים לאחסון ולניהול של פרטי הכניסה כמו בפרופיל ההורה, כפי שמתואר באתר של פרויקט Android Open Source.
- מדיניות הסיסמאות של 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] חובה לפתור התנגשויות במדיניות המכשיר כפי שמתואר במסגרת לפתרון בעיות במדיניות המכשיר.
סיום הדרישות החדשות
3.10. נגישות
מערכת Android כוללת שכבת נגישות שעוזרת למשתמשים עם מוגבלויות לנווט במכשירים בקלות רבה יותר. בנוסף, Android מספק ממשקי API לפלטפורמה שמאפשרים להטמעות של שירותי נגישות לקבל קריאות חוזרות (callbacks) לאירועים של משתמשים ושל מערכות, וליצור מנגנוני משוב חלופיים, כמו המרה של טקסט לדיבור, משוב חישתי (haptic) וניווט באמצעות טרקלבל או מקש D.
אם הטמעות המכשירים תומכות בשירותי נגישות של צד שלישי, הן:
- [C-1-1] חובה לספק הטמעה של מסגרת הנגישות של Android כפי שמתואר במסמכי התיעוד של ממשקי ה-API לנגישות ב-SDK.
- [C-1-2] חובה ליצור אירועי נגישות ולשלוח את הערך המתאים של
AccessibilityEvent
לכל ההטמעות הרשמות שלAccessibilityService
, כפי שמתואר ב-SDK. - [C-1-4] חובה לספק למשתמש אמצעי בקרה על שירותי הנגישות שמצהירים על AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. לתשומת ליבכם: בהטמעות במכשירים עם סרגל ניווט של מערכת, צריך לאפשר למשתמש להשתמש בלחצן בסרגל הניווט של המערכת כדי לשלוט בשירותים האלה.
אם הטמעות במכשירים כוללות שירותי נגישות שהותקנו מראש, הן:
- [C-2-1] חובה להטמיע את שירותי הנגישות המותקנים מראש כאפליקציות Direct Boot Aware כשאחסון הנתונים מוצפן באמצעות הצפנה מבוססת-קובץ (FBE).
- צריך לספק מנגנון בתהליך ההגדרה מחוץ לקופסה כדי לאפשר למשתמשים להפעיל שירותי נגישות רלוונטיים, וגם אפשרויות לשינוי גודל הגופן, גודל המסך וביצוע תנועות להגדלה.
3.11. המרת טקסט לדיבור (TTS)
Android כולל ממשקי API שמאפשרים לאפליקציות להשתמש בשירותי Text-to-Speech (TTS), ומאפשרים לספקי שירותים לספק הטמעות של שירותי TTS.
אם הטמעות של מכשירים מדווחות על התכונה android.hardware.audio.output, הן:
- [C-1-1] חובה לתמוך בממשקי ה-API של Android TTS framework.
אם הטמעות במכשירים תומכות בהתקנה של מנועי TTS של צד שלישי, הן:
- [C-2-1] חובה לספק למשתמש אפשרות לבחור מנוע TTS לשימוש ברמת המערכת.
3.12. TV Input Framework
Android Television Input Framework (TIF) מפשט את העברת התוכן בשידור חי למכשירי Android Television. TIF מספק ממשק API סטנדרטי ליצירת מודולי קלט ששולטים במכשירי Android Television.
אם הטמעות במכשירים תומכות ב-TIF, הן:
- [C-1-1] חובה להצהיר על תכונת הפלטפורמה
android.software.live_tv
. - [C-1-2] חובה לתמוך בכל ממשקי ה-API של TIF, כך שאפשר יהיה להתקין אפליקציה שמשתמשת בממשקי ה-API האלה ובשירות הקלט של צד שלישי שמבוסס על TIF ולהשתמש בה במכשיר.
3.13. הגדרות מהירות
ב-Android יש רכיב בממשק המשתמש של ההגדרות המהירות שמאפשר גישה מהירה לפעולות שבהן משתמשים לעיתים קרובות או לפעולות דחופות.
אם הטמעות במכשירים כוללות רכיב ממשק משתמש של הגדרות מהירות ותומכות בהגדרות מהירות של צד שלישי, הן:
- [C-1-1] חובה לאפשר למשתמש להוסיף או להסיר את המשבצות שסופקו דרך ממשקי ה-API של
quicksettings
מאפליקציה של צד שלישי. - [C-1-2] אסור להוסיף באופן אוטומטי משבצת מאפליקציה של צד שלישי ישירות להגדרות המהירות.
- [C-1-3] חובה להציג את כל המשבצות שהמשתמשים הוסיפו מאפליקציות של צד שלישי, לצד המשבצות של ההגדרות המהירות שסופקו על ידי המערכת.
3.14. ממשק המשתמש של המדיה
אם הטמעות במכשירים כוללות אפליקציות שלא מופעלות באמצעות קול (האפליקציות) שמקיימות אינטראקציה עם אפליקציות של צד שלישי דרך MediaBrowser
או MediaSession
, האפליקציות:
[C-1-2] חובה להציג בבירור סמלים שהתקבלו דרך
getIconBitmap()
אוgetIconUri()
וכותרות שהתקבלו דרךgetTitle()
, כפי שמתואר בקטעMediaDescription
. יכול להיות שנקצר את השמות כדי לעמוד בתקנות הבטיחות (למשל, הסחת דעת של הנהג).[C-1-3] חובה להציג את סמל האפליקציה של הצד השלישי בכל פעם שמוצג תוכן שמסופק על ידי האפליקציה הזו של הצד השלישי.
[C-1-4] חובה לאפשר למשתמש לקיים אינטראקציה עם כל היררכיית
MediaBrowser
. יכולים להגביל את הגישה לחלק מההיררכיה כדי לעמוד בתקנות הבטיחות (למשל, הסחת דעת של הנהג), אבל אסור להעניק יחס מועדף על סמך תוכן או ספק תוכן.[C-1-5] MUST consider double tap of
KEYCODE_HEADSETHOOK
orKEYCODE_MEDIA_PLAY_PAUSE
asKEYCODE_MEDIA_NEXT
forMediaSession.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] חובה לספק התראה קבועה למשתמשים שאפשר לכווץ בזמן שאפליקציית Instant פועלת בחזית. ההודעה הזו חייבת לכלול את ההודעה שאפליקציות מיידיות לא דורשות התקנה, ולספק למשתמש אמצעי ניווט שמפנה אותו למסך פרטי האפליקציה בהגדרות. באפליקציות מיידיות שמופעלות באמצעות כוונות אינטרנט, כפי שהן מוגדרות באמצעות כוונה עם פעולה
Intent.ACTION_VIEW
וסכימת http או https, צריכה להיות אפשרות נוספת למשתמש שלא להפעיל את האפליקציה המיידית ולהפעיל את הקישור המשויך באמצעות דפדפן האינטרנט המוגדר, אם יש דפדפן זמין במכשיר. - [C-1-7] חובה לאפשר גישה לאפליקציות מיידיות שפועלות דרך התכונה 'מהזמן האחרון', אם התכונה 'מהזמן האחרון' זמינה במכשיר.
[C-1-8] חובה לטעון מראש אפליקציה אחת או יותר או רכיבי שירות אחד או יותר עם בורר כוונות (intent handler) לכוונות שמפורטות ב-SDK כאן, ולהפוך את הכוונות לגלויות לאפליקציות מיידיות.
3.16. התאמת מכשירים נלווים
מערכת Android כוללת תמיכה בהתאמה של מכשירי נלווה כדי לנהל בצורה יעילה יותר את השיוך למכשירים נלווים, ומספקת את ממשק ה-API CompanionDeviceManager
כדי לאפליקציות תהיה גישה לתכונה הזו.
אם הטמעות המכשירים תומכות בתכונה של התאמת מכשיר נלווה, הן:
- [C-1-1] חובה להצהיר על דגל התכונה
FEATURE_COMPANION_DEVICE_SETUP
. - [C-1-2] חובה לוודא שהממשקי ה-API בחבילה
android.companion
הווטמעו באופן מלא. - [C-1-3] חובה לספק למשתמש אמצעי עזר כדי לאפשר לו לבחור או לאשר שמכשיר נלווה נמצא ופועל.
3.17. אפליקציות כבדות
אם הטמעות במכשירים מכריזות על התכונה FEATURE_CANT_SAVE_STATE
, הן:
- [C-1-1] חייבת להיות מותקנת רק אפליקציה אחת שמציינת את
cantSaveState
שפועלת במערכת בכל רגע נתון. אם המשתמש יוצא מאפליקציה כזו בלי לצאת ממנה באופן מפורש (לדוגמה, על ידי לחיצה על לחצן הבית בזמן שהוא יוצא מפעילות פעילה במערכת, במקום לחיצה על לחצן החזרה אחורה כשאין פעילויות פעילות שנותרו במערכת), ההטמעות במכשיר חייבות לתת לאפליקציה הזו עדיפות ב-RAM, כמו שהן עושות לדברים אחרים שצפויים להמשיך לפעול, כמו שירותים בחזית. כשאפליקציה כזו פועלת ברקע, המערכת עדיין יכולה להחיל עליה תכונות של ניהול צריכת החשמל, כמו הגבלת המעבד והגישה לרשת. - [C-1-2] חובה לספק אפשרות בממשק המשתמש לבחור את האפליקציה שלא תשתתף במנגנון הרגיל לשמירת המצב או לשחזור שלו אחרי שהמשתמש יפעיל אפליקציה שנייה שהוגדרה באמצעות המאפיין
cantSaveState
. - [C-1-3] אסור להחיל שינויים אחרים במדיניות על אפליקציות שמציינות את הערך
cantSaveState
, כמו שינוי ביצועי המעבד או שינוי תעדוף התזמון.
אם הטמעות במכשירים לא מכריזות על התכונה FEATURE_CANT_SAVE_STATE
, הן:
- [C-1-1] חובה להתעלם מהמאפיין
cantSaveState
שהוגדר על ידי אפליקציות, ואסור לשנות את התנהגות האפליקציה על סמך המאפיין הזה.
3.18. אנשי הקשר
מערכת Android כוללת ממשקי API של Contacts Provider
שמאפשרים לאפליקציות לנהל את פרטי אנשי הקשר שמאוחסנים במכשיר.
בדרך כלל, פרטי אנשי קשר שמוזנים ישירות במכשיר מסונכרנים עם שירות אינטרנט, אבל יכול להיות שהנתונים נשמרים רק באופן מקומי במכשיר.
אנשי קשר ששמורים רק במכשיר נקראים אנשי קשר מקומיים.
RawContacts "משויכים" או "מאוחסנים" בחשבון כשהעמודות ACCOUNT_NAME
ו-ACCOUNT_TYPE
של אנשי הקשר הגולמיים תואמות לשדות Account.name ו-Account.type של החשבון.
חשבון מקומי שמוגדר כברירת מחדל: חשבון של אנשי קשר גולמיים שנשמרים רק במכשיר ולא משויכים לחשבון ב-AccountManager. אנשי הקשר האלה נוצרים עם ערכים של null בעמודות ACCOUNT_NAME
ו-ACCOUNT_TYPE
.
חשבון מקומי בהתאמה אישית: חשבון של אנשי קשר גולמיים שנשמרים רק במכשיר ולא משויכים לחשבון ב-AccountManager, שנוצרים עם ערך אחד לפחות שאינו null בעמודות ACCOUNT_NAME
ו-ACCOUNT_TYPE
.
הטמעות במכשירים:
- [C-SR-1] מומלץ מאוד לא ליצור חשבונות מקומיים בהתאמה אישית.
אם בהטמעות במכשירים נעשה שימוש בחשבון מקומי בהתאמה אישית:
- [C-1-1] ה-
ACCOUNT_NAME
של החשבון המקומי המותאם אישית חייב להוחזר על ידיContactsContract.RawContacts.getLocalAccountName
- [C-1-2] ה-
ACCOUNT_TYPE
של החשבון המקומי המותאם אישית חייב להוחזר על ידיContactsContract.RawContacts.getLocalAccountType
- [C-1-3] חובה להוסיף אנשי קשר גולמיים שמוטמעים על ידי אפליקציות צד שלישי באמצעות החשבון המקומי שמוגדר כברירת מחדל (כלומר, על ידי הגדרת ערכים null עבור
ACCOUNT_NAME
ו-ACCOUNT_TYPE
) לחשבון המקומי המותאם אישית. - [C-1-4] אסור להסיר אנשי קשר גולמיים שהוכנסו לחשבון המקומי המותאם אישית כשמוסיפים או מסירים חשבונות.
- [C-1-5] פעולות מחיקה שמבוצעות בחשבון המקומי המותאם אישית חייבות להוביל למחיקה מיידית של אנשי הקשר הגולמיים (כאילו הפרמטר
CALLER_IS_SYNCADAPTER
הוגדר כ-true), גם אם הפרמטרCALLER\_IS\_SYNCADAPTER
הוגדר כ-false או לא צוין.
4. תאימות של אריזת אפליקציות
הטמעות במכשירים:
[C-0-1] חייב להיות מסוגל להתקין ולהריץ קבצים מסוג ".apk" של Android שנוצרו באמצעות הכלי "aapt" שכלול ב-Android SDK הרשמי.
- מאחר שהדרישה שלמעלה עשויה להיות מאתגרת, מומלץ להשתמש במערכת ניהול החבילות של הטמעת העזר של AOSP בהטמעות במכשירים.
[C-0-2] חובה לתמוך באימות של קבצים מסוג ".apk" באמצעות APK Signature Scheme v3.1, APK Signature Scheme v3, APK Signature Scheme v2 וחתימת JAR.
[C-0-3] אסור להרחיב את הפורמטים של .apk, Android Manifest, קוד בינארי של Dalvik או קוד בינארי של RenderScript באופן שימנע את ההתקנה וההפעלה הנכונים של הקבצים האלה במכשירים תואמים אחרים.
[C-0-4] אסור לאפשר לאפליקציות אחרות מלבד 'מתקין הרשומה' הנוכחי של החבילה להסיר את האפליקציה בשקט, ללא אישור מהמשתמש, כפי שמתואר ב-SDK לגבי ההרשאה
DELETE_PACKAGE
. החריגים היחידים הם האפליקציה לאימות חבילות המערכת שמטפלת ב-intent PACKAGE_NEEDS_VERIFICATION, והאפליקציה לניהול האחסון שמטפלת ב-intent ACTION_MANAGE_STORAGE.[C-0-5] חובה שתהיה פעילות שמטפלת ב-intent
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] חובה להטמיע תמיכה ב-Incremental File System כפי שמתואר כאן.
[C-0-9] חובה לתמוך באימות של קובצי APK באמצעות APK Signature Scheme v4 ו-APK Signature Scheme v4.1.
5. תאימות למולטימדיה
הטמעות במכשירים:
- [C-0-1] חובה לתמוך בפורמטים של המדיה, בקודקים, במפענחים, בסוגי הקבצים ובפורמטים של הקונטיינרים שמוגדרים בקטע 5.1 לכל קודק שמוצהר על ידי
MediaCodecList
. - [C-0-2] חובה להצהיר ולדווח על תמיכה במקודדים ובמקודדים הזמינים לאפליקציות של צד שלישי דרך
MediaCodecList
. - [C-0-3] חייב להיות מסוגל לפענח כראוי את כל הפורמטים שהוא יכול לקודד ולהפוך אותם לזמינים לאפליקציות של צד שלישי. הנתונים האלה כוללים את כל זרמי הביט שהקודקים שלו יוצרים ואת הפרופילים שמדווחים ב-
CamcorderProfile
.
הטמעות במכשירים:
- צריך לשאוף לזמן אחזור מינימלי של הקודק. במילים אחרות, צריך
- אסור לצרוך ולאחסן מאגרי קלט ולהחזיר מאגרי קלט רק אחרי עיבוד.
- אסור לשמור מאגרי נתונים מפוענחים למשך זמן ארוך יותר מזה שצוין בתקן (למשל SPS).
- לא כדאי לשמור במאגרים המקודדים למשך זמן ארוך יותר מהנדרש על ידי מבנה ה-GOP.
כל הקודקים שמפורטים בקטע שבהמשך מוצעים כטמעות תוכנה בהטמעת Android המועדפת מפרויקט Android Open Source.
לתשומת ליבך, 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] Opus
כל מקודדי האודיו חייבים לתמוך באפשרויות הבאות:
- [C-3-1] פריימים של אודיו ב-PCM 16 ביט בסדר בייטים מקורי באמצעות ה-API של
android.media.MediaCodec
.
5.1.2. פענוח אודיו
פרטים נוספים זמינים בקטע 5.1.3. פרטי קודקי האודיו.
אם הטמעות של מכשירים מכריזות על תמיכה בתכונה android.hardware.audio.output
, הן חייבות לתמוך בפענוח של פורמטים האודיו הבאים:
- [C-1-1] MPEG-4 AAC Profile (AAC LC)
- [C-1-2] MPEG-4 HE AAC Profile (AAC+)
- [C-1-3] פרופיל MPEG-4 HE AACv2 (enhanced AAC+)
- [C-1-4] AAC ELD (AAC משופר עם זמן השהיה קצר)
- [C-1-11] xHE-AAC (פרופיל HE AAC מורחב ISO/IEC 23003-3, שכולל את פרופיל הבסיס USAC ופרופיל בקרת טווח דינמי ISO/IEC 23003-4)
- [C-1-5] FLAC
- [C-1-6] MP3
- [C-1-7] MIDI
- [C-1-8] Vorbis
- [C-1-9] PCM/WAVE, כולל פורמטים של אודיו ברזולוציה גבוהה עד 24 ביט, תדירות דגימה של 192kHz ו-8 ערוצים. חשוב לזכור שהדרישה הזו היא לצורך פענוח בלבד, ושמותר למכשיר לבצע דגימה לאחור (downsampling) ומייקס לאחור (downmix) במהלך שלב ההפעלה.
- [C-1-10] Opus
אם הטמעות במכשירים תומכות בפענוח של מאגרי קלט של AAC בסטרימינג מרובה ערוצים (כלומר יותר משני ערוצים) ל-PCM באמצעות מפענח האודיו AAC שמוגדר כברירת מחדל ב-API של android.media.MediaCodec
, חובה שתהיה תמיכה באפשרויות הבאות:
- [C-2-1] חובה לבצע את פענוח הנתונים ללא ערבוב למטה (למשל, צריך לבצע פענוח של שידור AAC 5.0 לחמישה ערוצים של PCM, ושל שידור AAC 5.1 לשישה ערוצים של PCM).
- [C-2-2] המטא-נתונים של הטווח הדינמי חייבים להיות כפי שמוגדרים ב'בקרת טווח דינמי (DRC)' ב-ISO/IEC 14496-3, ומפתחות ה-DRC מסוג
android.media.MediaFormat
כדי להגדיר את ההתנהגויות שקשורות לטווח הדינמי של מקודד האודיו. מפתחות ה-DRC של AAC הוצגו ב-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] מומלץ מאוד שכל מקודדי האודיו מסוג AAC יעמדו בדרישות C-2-1 ו-C-2-2 שלמעלה.
כשמפענחים אודיו מסוג USAC, MPEG-D (ISO/IEC 23003-4):
- [C-3-1] חובה לפרש את המטא-נתונים של עוצמת הקול ושל בקרת עוצמת הקול הדינמית ולהחיל אותם בהתאם לפרופיל בקרת עוצמת הקול הדינמית של MPEG-D DRC ברמה 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 נמצאים בזרם ביטים מפוענח, אז:
- המטא-נתונים של ISO/IEC 23003-4 יהיו בעלי עדיפות.
כל מקודדי האודיו חייבים לתמוך בפלט של:
- [C-6-1] פריימים של אודיו ב-PCM 16 ביט בסדר בייטים מקורי דרך ה-API של
android.media.MediaCodec
.
אם הטמעות במכשירים תומכות בפענוח של מאגרי קלט של 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 Profile (AAC LC) |
תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם תדירויות דגימה רגילות של 8 עד 48kHz. |
|
פרופיל MPEG-4 HE AAC (AAC+) | תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם תדירויות דגימה רגילות של 16 עד 48kHz. |
|
MPEG-4 HE AACv2 פרופיל (enhanced AAC+) |
תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם תדירויות דגימה רגילות של 16 עד 48kHz. |
|
AAC ELD (AAC משופר עם זמן אחזור נמוך) | תמיכה בתוכן מונו/סטריאו עם תדירויות דגימה רגילות של 16 עד 48kHz. |
|
USAC | תמיכה בתוכן מונו/סטריאו עם תדירויות דגימה רגילות של 7.35kHz עד 48kHz. | MPEG-4 (.mp4, .m4a) |
AMR-NB | 4.75 עד 12.2kbps דגימה ב-8kHz | 3GPP (.3gp) |
AMR-WB | 9 שיעורים מ-6.60kbit/s עד 23.85kbit/s שנדגמו ב-16kHz, כפי שמוגדר ב- AMR-WB, Adaptive Multi-Rate – Wideband Speech Codec | 3GPP (.3gp) |
FLAC | גם למקודד וגם למפענח: חובה שתהיה תמיכה לפחות במצבים Mono ו-Stereo. חובה שתהיה תמיכה בתדירויות דגימה של עד 192kHz, וברזולוציות של 16 ו-24 ביט. עיבוד נתוני אודיו של FLAC 24 ביט חייב להיות זמין עם הגדרת אודיו של נקודה צפה. |
|
MP3 | מונו/סטריאו 8-320Kbps קבוע (CBR) או קצב העברת נתונים משתנה (VBR) |
|
MIDI | MIDI מסוג 0 ו-1. DLS גרסה 1 ו-2. XMF ו-Mobile XMF. תמיכה בפורמטים של רינגטונים RTTTL/RTX, OTA ו-iMelody |
|
Vorbis | פענוח: תמיכה בתוכן מונו, סטריאו, 5.0 ו-5.1 עם שיעורי דגימה של 8,000, 12,000, 16,000, 24,000 ו-48,000Hz. קידוד: תמיכה בתוכן מונו וסטריאו עם שיעורי דגימה של 8,000, 12,000, 16,000, 24,000 ו-48,000Hz. |
|
PCM/WAVE | קודק PCM חייב לתמוך ב-PCM ליניארי של 16 ביט וב-float של 16 ביט. הכלי לחילוץ קובצי WAVE חייב לתמוך ב-PCM לינאריים של 16 ביט, 24 ביט ו-32 ביט וב-float של 32 ביט (בתדירויות עד למגבלה של החומרה). חובה לתמוך בתדירויות דגימה של 8kHz עד 192kHz. | WAVE (.wav) |
Opus | פענוח: תמיכה בתוכן מונו, סטריאו, 5.0 ו-5.1 עם שיעורי דגימה של 8,000, 12,000, 16,000, 24,000 ו-48,000Hz.
קידוד: תמיכה בתוכן מונו וסטריאו עם שיעורי דגימה של 8,000, 12,000, 16,000, 24,000 ו-48,000Hz. |
|
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
ובפרופיל הבסיס.
- המכשירים חייבים לתמוך ב-
סיום הדרישות החדשות
אם הטמעות במכשירים תומכות בקידוד HEIC דרך android.media.MediaCodec
לסוג המדיה MIMETYPE_IMAGE_ANDROID_HEIC
,
הן:
- [C-1-1] חובה לספק קודק מקודד HEVC שמואץ בחומרה שתומך במצב בקרת קצב העברת הנתונים
BITRATE_MODE_CQ
, בפרופילHEVCProfileMainStill
ובגודל פריים של 512 על 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 | Base+progressive | 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 (פרופיל בסיס) | פרופיל Baseline של תמונה, אוסף תמונות או רצף תמונות | קונטיינר HEIF (.avif) |
מקודדים ומפענחים של תמונות שחשופים דרך ממשק ה-API של MediaCodec
[C-1-1] חובה לתמוך בפורמט צבע גמיש YUV420 8:8:8 (
COLOR_FormatYUV420Flexible
) דרךCodecCapabilities
.[C-SR-1] מומלץ מאוד לתמוך בפורמט צבע RGB888 למצב Surface של הקלט.
[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] אם ההגדרה מתבצעת באמצעות פלט Surface, ברירת המחדל חייבת להיות פורמט הצבע המותאם בצורה אופטימלית לתצוגת החומרה.
- [C-4-2] צריך להגדיר כברירת מחדל פורמט צבע YUV420 8:8:8 שמותאם לקריאה של מעבד אם לא מגדירים שימוש בפלט Surface.
5.1.8. רשימת קודיקי וידאו
פורמט/קודק | פרטים | סוגי הקבצים או הפורמטים של הקונטיינרים שנתמכים |
---|---|---|
H.263 |
|
|
H.264 AVC | פרטים נוספים זמינים בקטע 5.2 ובקטע 5.3 |
|
H.265 HEVC | פרטים נוספים זמינים בקטע 5.3 |
|
MPEG-2 | פרופיל ראשי |
|
MPEG-4 SP |
|
|
VP8 | פרטים נוספים זמינים בקטע 5.2 ו5.3 |
|
VP9 | פרטים נוספים זמינים בקטע 5.3 |
|
AV1 | פרטים נוספים זמינים בקטע 5.2 ובקטע 5.3 |
|
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 Open Source (אם הוא זמין) לכל פורמט מדיה וסוג (מקודד או מפענח) שנתמכים במכשיר.
- [C-2-2] קודיקים עם שמות שמתחילים ב-'OMX.google.' חייב להתבסס על קוד המקור של פרויקט הקוד הפתוח של Android.
- [C-SR-2] מומלץ מאוד להריץ את קודקי התוכנה של OMX בתהליך קודק שאין לו גישה למנהלי חומרה מלבד ממיפויי זיכרון.
אם הטמעות במכשירים תומכות ב-Codec 2.0 API, הן:
- [C-3-1] חובה לכלול את קודק התוכנה התואם של Codec 2.0 מ-Android Open Source Project (אם הוא זמין) לכל פורמט מדיה וסוג (מקודד או מפענח) שנתמכים במכשיר.
- [C-3-2] חובה לאכלס את קודקי התוכנה של Codec 2.0 בתהליך של קודק התוכנה, כפי שמפורט בפרויקט Android Open Source, כדי לאפשר מתן גישה מצומצמת יותר לקודקי תוכנה.
- [C-3-3] קודיקים ששמותיהם מתחילים ב-'c2.android.' חייב להתבסס על קוד המקור של פרויקט הקוד הפתוח של Android.
5.1.10. אפיון של קודק מדיה
אם הטמעות המכשירים תומכות בקודקים של מדיה, הן:
- [C-1-1] חובה להחזיר ערכים נכונים של מאפייני הקודק של המדיה באמצעות ה-API של
MediaCodecInfo
.
ובפרט:
- [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 Open Source Project או שלא מבוססים על קוד המקור בפרויקט הזה חייבים להיות מסווגים כספק.
- [C-1-7] קודיקים שמשתמשים בהאצת חומרה חייבים להיות מסווגים ככאלה.
- [C-1-8] אסור ששמות הקודקים יהיו מטעים. לדוגמה, קודיקים בשם 'decoders' חייבים לתמוך בפענוח, וקודיקים בשם 'encoders' חייבים לתמוך בקידוד. קודיקים עם שמות שמכילים פורמטים של מדיה חייבים לתמוך בפורמטים האלה.
אם ההטמעות במכשיר תומכות בקודקים של וידאו:
- [C-2-1] כל קודיקי הווידאו חייבים לפרסם נתונים על קצב הפריימים שאפשר להשיג בגדלים הבאים, אם הקודק תומך בהם:
SD (איכות נמוכה) | SD (איכות גבוהה) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
רזולוציית וידאו |
|
|
|
1920 x 1080 פיקסלים (לא MPEG4, AV1) | 3840 x 2160 פיקסלים (HEVC, VP9, AV1) |
- [C-2-2] קודיקים של וידאו שמאופיינים כקודקים עם שיפור מהירות באמצעות חומרה חייבים לפרסם מידע על נקודות ביצועים. בכל אחת מהן חייבים להופיע כל נקודות הביצועים הרגילות הנתמכות (שמופיעות ב-API של
PerformancePoint
), אלא אם הן מכוסות בנקודת ביצועים רגילה אחרת שנתמכת. - בנוסף, הם צריכים לפרסם נקודות ביצועים מורחבות אם הם תומכים בביצועי וידאו עקביים שאינם אחד מהנתונים הסטנדרטיים שצוינו.
5.2. קידוד וידאו
- אסור שיהיו, בשני חלונות הזזה, יותר מ-15% מעל קצב הנתונים בין מרווחי הזמן של התמונות בתוך המסגרת (I-frame).
- לא צריך לחרוג מ-100% מעל קצב העברת הנתונים בחלון הזזה של שנייה אחת.
יצירת דרישות חדשות
אם הטמעות במכשירים תומכות בכל מכשיר קידוד וידאו ומאפשרות להשתמש בו באפליקציות של צד שלישי, ומגדירות אתMediaFormat.KEY_BITRATE_MODE
לערך BITRATE_MODE_VBR
כדי שהמכשיר יפעל במצב של קצב העברת נתונים משתנה, אז כל עוד זה לא משפיע על רמת האיכות המינימלית, קצב העברת הנתונים המקודד :
[C-5-1] חייבלהיות לא יותר מ-15% מעל קצב העברת הנתונים בין מרווחי הזמן של פריימים פנימיים (פרימי I) בחלון הזזה אחד.[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 היא אופציונלית.
צריכה להיות תמיכה בקצב העברת נתונים (bitrate) שניתן להגדיר באופן דינמי במקודד הנתמך.
5.2.2. H.264
אם הטמעות המכשירים תומכות בקודק H.264, הן:
- [C-1-1] חובה לתמוך בפרופיל Baseline ברמה 3. עם זאת, התמיכה ב-ASO (סידור שרירותי של פרוסות), ב-FMO (סידור גמיש של מק"טים) וב-RS (פרוסות יתירות) היא אופציונלית. בנוסף, כדי לשמור על תאימות למכשירי Android אחרים, מומלץ שלא להשתמש ב-ASO, ב-FMO וב-RS בפרופיל הבסיסי על ידי מקודדים.
- [C-1-2] חייב לתמוך בפרופילים של קידוד וידאו באיכות SD (רזולוציה רגילה) שמפורטים בטבלה הבאה.
- צריכה להיות תמיכה ברמת 4 בפרופיל הראשי.
- צריך לתמוך בפרופילים של קידוד וידאו באיכות HD (High Definition) כפי שמפורט בטבלה הבאה.
אם הטמעות במכשירים מדווחות על תמיכה בקידוד H.264 לסרטונים ברזולוציה של 720p או 1080p דרך ממשקי ה-API של המדיה, הן:
- [C-2-1] חובה לתמוך בפרופילי הקידוד שמפורטים בטבלה הבאה.
SD (איכות נמוכה) | SD (איכות גבוהה) | HD 720p | HD 1080p | |
---|---|---|---|---|
רזולוציית וידאו | 320 x 240 פיקסלים | 720 x 480 פיקסלים | 1280 x 720 פיקסלים | 1,920 x 1,080 פיקסלים |
קצב המסגרות של הסרטון | 20 פריימים לשנייה (FPS) | 30 פריימים לשנייה (FPS) | 30 פריימים לשנייה (FPS) | 30 פריימים לשנייה (FPS) |
קצב העברת נתונים של וידאו | 384 Kbps | 2 Mbps | 4Mbps | 10Mbps |
5.2.3. VP8
אם הטמעות במכשירים תומכות בקודק VP8, הן:
- [C-1-1] חובה לתמוך בפרופילים של קידוד וידאו ב-SD.
- צריכה להיות תמיכה בפרופילים הבאים של קידוד וידאו באיכות HD (High Definition).
- [C-1-2] חובה לתמוך בכתיבת קובצי Matroska WebM.
- צריך לספק קודק VP8 לחומרה שעומד בדרישות הקידוד של חומרת RTC בפרויקט WebM, כדי להבטיח איכות סבירה של סטרימינג של וידאו באינטרנט ושל שירותי ועידות וידאו.
אם הטמעות במכשירים מדווחות על תמיכה בקידוד VP8 בסרטונים ברזולוציה של 720p או 1080p דרך ממשקי ה-API של המדיה, הן:
- [C-2-1] חובה לתמוך בפרופילי הקידוד שמפורטים בטבלה הבאה.
SD (איכות נמוכה) | SD (איכות גבוהה) | HD 720p | HD 1080p | |
---|---|---|---|---|
רזולוציית וידאו | 320 x 180 פיקסלים | 640 x 360 פיקסלים | 1280 x 720 פיקסלים | 1,920 x 1,080 פיקסלים |
קצב המסגרות של הסרטון | 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 פיקסלים | 1280 x 720 פיקסלים | 1,920 x 1,080 פיקסלים | 3840 x 2160 פיקסלים |
קצב המסגרות של הסרטון | 30 פריימים לשנייה (FPS) | 30 פריימים לשנייה (FPS) | 30 פריימים לשנייה (FPS) | 30 פריימים לשנייה (FPS) |
קצב העברת נתונים של וידאו | 1.6 Mbps | 4Mbps | 5 Mbps | 20 Mbps |
אם הטמעות במכשירים טוענות שהן תומכות בפרופיל 2 או בפרופיל 3 דרך ממשקי ה-Media API:
- התמיכה בפורמט 12 ביט היא אופציונלית.
5.2.5. H.265
אם הטמעות המכשירים תומכות בקודק H.265, הן:
- [C-1-1] חובה לתמוך בפרופיל הראשי ברמה 3 ברזולוציה של עד 512x512.
צריך לתמוך בפרופילים של קידוד HD כפי שמצוין בטבלה הבאה.- [C-SR-1] מומלץ מאוד לתמוך בפרופיל SD 720 x 480 ובפרופילים של קידוד HD כפי שמצוין בטבלה הבאה, אם יש מקודד חומרה.
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
רזולוציית וידאו | 720 x 480 פיקסלים | 1280 x 720 פיקסלים | 1,920 x 1,080 פיקסלים | 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] חובה לפרסם נתוני ביצועים, כלומר לדווח על נתוני הביצועים באמצעות ממשקי ה-API של
getSupportedFrameRatesFor()
אוgetSupportedPerformancePoints()
ברזולוציות הנתמכות שמפורטות בטבלה שבהמשך.[C-1-3] חובה לקבל מטא-נתונים של HDR ולהעביר אותם לפלט של מקור הנתונים (bitstream)
אם מקודד AV1 מופעל באמצעות שיפור מהירות באמצעות חומרה, הוא:
- [C-2-1] חובה לתמוך בפרופיל קידוד HD1080p לכל היותר, כולל, מהטבלה הבאה:
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
רזולוציית וידאו | 720 x 480 פיקסלים | 1280 x 720 פיקסלים | 1,920 x 1,080 פיקסלים | 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] חובה לתמוך בפרופיל פשוט ברמה 3.
5.3.4. H.264
אם הטמעות המכשירים תומכות במפענחי H.264, הן:
- [C-1-1] חובה לתמוך בפרופיל הראשי ברמה 3.1 ובפרופיל Baseline. התמיכה ב-ASO (סידור שרירותי של פרוסות), ב-FMO (סידור גמיש של קטעי מקרו) וב-RS (פרוסות יתירות) היא אופציונלית.
- [C-1-2] חייב להיות מסוגל לפענח סרטונים עם הפרופילים של SD (רזולוציה רגילה) שמפורטים בטבלה הבאה, וקידוד שלהם בוצע באמצעות Baseline Profile ו-Main Profile ברמה 3.1 (כולל 720p30).
- צריכה להיות מסוגלת לפענח סרטונים עם פרופילים של HD (רזולוציה גבוהה) כפי שמצוין בטבלה הבאה.
אם הגובה שמדווח על ידי השיטה Display.getSupportedModes()
שווה לרזולוציית הסרטון או גדול ממנה, הטמעות במכשירים:
- [C-2-1] חובה לתמוך בפרופילים של פענוח וידאו באיכות HD 720p שמפורטים בטבלה הבאה.
- [C-2-2] חובה לתמוך בפרופילים של פענוח וידאו באיכות HD 1080p שמפורטים בטבלה הבאה.
SD (איכות נמוכה) | SD (איכות גבוהה) | HD 720p | HD 1080p | |
---|---|---|---|---|
רזולוציית וידאו | 320 x 240 פיקסלים | 720 x 480 פיקסלים | 1280 x 720 פיקסלים | 1,920 x 1,080 פיקסלים |
קצב המסגרות של הסרטון | 30 פריימים לשנייה (FPS) | 30 פריימים לשנייה (FPS) | 60 fps | 30 פריימים לשנייה (60 פריימים לשנייה בטלוויזיה) |
קצב העברת נתונים של וידאו | 800 Kbps | 2 Mbps | 8Mbps | 20 Mbps |
5.3.5. H.265 (HEVC)
אם הטמעות המכשירים תומכות בקודק H.265, הן:
- [C-1-1] חייב לתמוך ברמה הראשית של פרופיל Main ברמה 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 פיקסלים | 1280 x 720 פיקסלים | 1,920 x 1,080 פיקסלים | 3840 x 2160 פיקסלים |
קצב המסגרות של הסרטון | 30 פריימים לשנייה (FPS) | 30 פריימים לשנייה (FPS) | 30 פריימים לשנייה (FPS) | 30/60 FPS (60 FPSטלוויזיה עם פענוח חומרה של H.265) | 60 fps |
קצב העברת נתונים של וידאו | 600 Kbps | 1.6 Mbps | 4Mbps | 5 Mbps | 20 Mbps |
אם הטמעות במכשירים טוענות שהן תומכות בפרופיל HDR דרך ממשקי ה-Media API:
- [C-3-1] הטמעות במכשירים חייבות לקבל את המטא-נתונים הנדרשים של HDR מהאפליקציה, וגם לתמוך בחילוץ ובפלט של המטא-נתונים הנדרשים של HDR מזרם הביטים ו/או מהמאגר.
- [C-3-2] הטמעות במכשירים חייבות להציג תוכן HDR כראוי במסך המכשיר או ביציאת וידאו רגילה (למשל, HDMI).
5.3.6. VP8
אם הטמעות במכשירים תומכות בקודק VP8, הן:
- [C-1-1] חובה לתמוך בפרופילים של פענוח SD שמפורטים בטבלה הבאה.
- מומלץ להשתמש בקודק VP8 לחומרה שעומד בדרישות.
- צריכה להיות תמיכה בפרופילים של פענוח HD שמפורטים בטבלה הבאה.
אם הגובה שמדווח על ידי השיטה Display.getSupportedModes()
שווה לרזולוציית הסרטון או גדול ממנה, אז:
- [C-2-1] הטמעות של מכשירים חייבות לתמוך בפרופילים של 720p שמפורטים בטבלה הבאה.
- [C-2-2] הטמעות במכשירים חייבות לתמוך בפרופילים של 1080p שמפורטים בטבלה הבאה.
SD (איכות נמוכה) | SD (איכות גבוהה) | HD 720p | HD 1080p | |
---|---|---|---|---|
רזולוציית וידאו | 320 x 180 פיקסלים | 640 x 360 פיקסלים | 1280 x 720 פיקסלים | 1,920 x 1,080 פיקסלים |
קצב המסגרות של הסרטון | 30 פריימים לשנייה (FPS) | 30 פריימים לשנייה (FPS) | 30 פריימים לשנייה (60 פריימים לשנייה בטלוויזיה) | 30 (60fpsטלוויזיה) |
קצב העברת נתונים של וידאו | 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 | |
---|---|---|---|---|---|
רזולוציית וידאו | 320 x 180 פיקסלים | 640 x 360 פיקסלים | 1280 x 720 פיקסלים | 1,920 x 1,080 פיקסלים | 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
דרך ממשקי ה-API של המדיה 'CodecProfileLevel':
- התמיכה בפורמט 12 ביט היא אופציונלית.
אם הטמעות של מכשירים טוענות שהן תומכות בפרופיל HDR (VP9Profile2HDR
, VP9Profile2HDR10Plus
, VP9Profile3HDR
, VP9Profile3HDR10Plus
) דרך ממשקי ה-API של המדיה:
- [C-4-1] הטמעות במכשירים חייבות לקבל מהאפליקציה את המטא-נתונים הנדרשים של HDR (
KEY_HDR_STATIC_INFO
לכל פרופילי ה-HDR, וגם 'KEY_HDR10_PLUS_INFO' לפרופילים של HDR10Plus). הם חייבים גם לתמוך בחילוץ ובפלט של המטא-נתונים הנדרשים של HDR מזרם הביטים ו/או מהמאגר. - [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
- [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 פיקסלים | 1280 x 720 פיקסלים | 1,920 x 1,080 פיקסלים | 3840 x 2160 פיקסלים |
קצב המסגרות של הסרטון | 30 פריימים לשנייה (FPS) | 30 פריימים לשנייה (FPS) | 30 פריימים לשנייה (FPS) | 30 פריימים לשנייה (FPS) |
קצב העברת נתונים של וידאו | 5 Mbps | 8Mbps | 16Mbps | 50 Mbps |
אם הטמעות במכשירים תומכות בפרופיל HDR דרך ממשקי ה-API של מדיה, הן:
- [C-3-1] חובה לתמוך בחילוץ ובפלט של מטא-נתונים של HDR מזרם הביט או מהמאגר.
- [C-3-2] חובה להציג תוכן HDR כראוי במסך המכשיר או ביציאת וידאו רגילה (למשל, HDMI).
סיום הדרישות החדשות
5.4. הקלטת אודיו
חלק מהדרישות שמפורטות בקטע הזה מופיעות כ'מומלץ' מאז Android 4.3, אבל בהגדרת התאימות לגרסאות עתידיות אנחנו מתכננים לשנות את ההגדרה הזו ל'חובה'. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה שמפורטות כ'צריך', אחרת הם לא יוכלו לעמוד בדרישות התאימות ל-Android כשיתבצע השדרוג לגרסה העתידית.
5.4.1. הקלטת אודיו גולמי ומידע על המיקרופון
אם הטמעות של מכשירים מגדירות את android.hardware.microphone
, הן:
[C-1-1] חובה לאפשר תיעוד של תוכן אודיו גולמי לכל מקור נתונים (input) מסוג
AudioRecord
אוAAudio
שנפתח בהצלחה. חובה שתהיה תמיכה לפחות במאפיינים הבאים:- פורמט: Linear PCM, 16-ביט
- תדירות דגימה: 8000, 11025, 16000, 44100, 48000Hz
- ערוצים: מונו
- מקורות אודיו:
DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
אוVOICE_PERFORMANCE
. הדבר נכון גם להגדרות הקלט המוגדרות מראש המקבילות ב-AAudio
, למשלAAUDIO_INPUT_PRESET_CAMCORDER
.
צריך לאפשר תיעוד של תוכן אודיו גולמי עם המאפיינים הבאים:
- פורמט: Linear PCM, 16 ביט ו-24 ביט
- תדירות דגימה: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 הרץ
- ערוצים: מספר הערוצים שווה למספר המיקרופונים במכשיר
[C-1-2] חובה לצלם בתדירויות דגימה גבוהות יותר ללא דגימה מחדש.
[C-1-3] חובה לכלול מסנן מתאים לביטול רעשי aliasing כשקצב הדגימה שצוין למעלה מתועד באמצעות דגימה לאחור.
צריכה לאפשר הקלטה של תוכן אודיו גולמי באיכות רדיו AM ו-DVD, כלומר:
- פורמט: PCM לינארי, 16 ביט
- תדירות דגימה: 22050, 48000Hz
- ערוצים: סטריאו
[C-1-4] חובה לפעול בהתאם ל-API של
MicrophoneInfo
ולמלא כראוי את המידע על המיקרופונים הזמינים במכשיר שזמינים לאפליקציות של הצד השלישי דרך ה-API שלAudioManager.getMicrophones()
, עבור AudioRecord פעיל באמצעותMediaRecorder.AudioSources DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
אוVOICE_PERFORMANCE
. אם הטמעות במכשירים מאפשרות תיעוד של תוכן אודיו גולמי באיכות רדיו AM ואיכות DVD, הן:[C-2-1] חובה לצלם ללא דגימה מחדש ביחס גבוה מ-16000:22050 או 44100:48000.
[C-2-2] חובה לכלול מסנן מתאים לביטול רעשי aliasing לכל דגימה למעלה או למטה.
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 מ-4,000Hz עד 22KHz בהשוואה לטווח התדרים הבינוני בכל מיקרופון שמשמש להקלטת מקור האודיו לזיהוי הקול.
צריך להגדיר את רגישות הקלט של האודיו כך שמקור של צליל סינוסואידלי של 1,000Hz שיופעל ברמת לחץ קול (SPL) של 90dB (נמדד
במרחק של 30 ס"מ מלצד המיקרופון) יניב תגובה אידיאלית של RMS 2,500 בטווח של 1,770 עד 3,530 לדגימות של 16 ביט (או -22.35dB ±3dB Full Scale לדגימות של נקודת צפה/דיוק כפול) לכל מיקרופון שמשמש להקלטה של מקור האודיו לזיהוי הקול.צריך להקליט את מקור האודיו לזיהוי הקול כך שרמות האמפליטודה של PCM יעקבו באופן לינארי אחרי השינויים ב-SPL של הקלט בטווח של לפחות 30dB, מ-18dB ל-12dB ביחס ל-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] מומלץ מאוד להצהיר על כך באמצעות שיטת ה-API של AcousticEchoCanceler AcousticEchoCanceler.isAvailable()
- [C-SR-2] מומלץ מאוד לאפשר שליטה באפקט האודיו הזה באמצעות ה-API של AcousticEchoCanceler.
- [C-SR-3] מומלץ מאוד לזהות באופן ייחודי כל הטמעה של טכנולוגיית AEC באמצעות השדה AudioEffect.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 ערוצים
- קצבי דגימה (בהרץ):
- 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 בהגדרות הערוץ שמפורטות למעלה
- 96,000 במונו ובסטריאו
5.5.2. אפקטים קוליים
Android מספק API לאפקטים של אודיו להטמעות במכשירים.
אם הטמעות במכשירים מכריזות על התכונה android.hardware.audio.output
, הן:
- [C-1-1] חובה לתמוך בהטמעות של
EFFECT_TYPE_EQUALIZER
ו-EFFECT_TYPE_LOUDNESS_ENHANCER
שניתן לשלוט בהן באמצעות תתי-הסוגים של AudioEffectEqualizer
ו-LoudnessEnhancer
. - [C-1-2] חובה לתמוך בהטמעת API של ויזואליzer, שניתן לשלוט בו באמצעות הכיתה
Visualizer
. - [C-1-3] חובה לתמוך בהטמעה של
EFFECT_TYPE_DYNAMICS_PROCESSING
שניתן לשלוט בה באמצעות צאצא משנה של AudioEffectDynamicsProcessing
.
יצירת דרישות חדשות
- [C-1-4] חובה לתמוך באפקטים קוליים עם קלט ופלט של נקודה צפה.
- [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] מומלץ מאוד לתמוך באפקטים בספרות עשרוניות ובמספר ערוצים.
5.5.3. עוצמת הקול של פלט האודיו
הטמעות במכשירים לכלי רכב:
- צריך לאפשר לשנות את עוצמת האודיו בנפרד לכל שידור אודיו לפי סוג התוכן או השימוש, כפי שמוגדר ב-AudioAttributes, ושימוש באודיו ברכב כפי שמוגדר באופן ציבורי ב-
android.car.CarAudioManager
.
5.5.4. העברת אודיו
אם הטמעות במכשירים תומכות בהעברת אודיו להפעלה, הן:
- [C-SR-1] מומלץ מאוד לחתוך את תוכן האודיו ללא הפסקות (gapless) שמשוחק בין שני קליפים באותו פורמט, כפי שצוין על ידי AudioTrack gapless API ומיכל המדיה של MediaPlayer.
5.6. זמן אחזור אודיו (audio latency)
זמן האחזור של האודיו הוא זמן העיכוב כשאות אודיו עובר דרך מערכת. סוגים רבים של אפליקציות מסתמכים על זמני אחזור קצרים כדי ליצור אפקטים קוליים בזמן אמת.
לצורך סעיף זה, נעשה שימוש בהגדרות הבאות:
- זמן אחזור של הפלט. מרווח הזמן בין הזמן שבו אפליקציה כותבת פריים של נתונים בקידוד PCM לבין הזמן שבו הצליל התואם מוצג לסביבה באמצעות מתמר במכשיר, או שהאות יוצא מהמכשיר דרך יציאה וניתן לצפות בו באופן חיצוני.
- זמן האחזור של פלט קר. הזמן שחלף בין הפעלת מקור פלט לבין זמן הצגת הפריים הראשון, על סמך חותמות זמן, כשמערכת הפלט של האודיו הייתה במצב חוסר פעילות ומושבתת לפני הבקשה.
- זמן אחזור רציף של פלט. זמן האחזור של הפלט בפריימים הבאים, אחרי שהמכשיר מפעיל אודיו.
- זמן אחזור של קלט. מרווח הזמן בין המועד שבו צליל מוצג על ידי הסביבה למכשיר בטרנסדוסר במכשיר או שהאות נכנס למכשיר דרך יציאה, לבין המועד שבו אפליקציה קוראת את המסגרת התואמת של נתונים בקידוד PCM.
- קלט אבוד. החלק הראשוני של אותות קלט שלא ניתן להשתמש בהם או שהם לא זמינים.
- זמן אחזור של קלט במצב קר. הזמן שחלף בין תחילת הסטרימינג לבין קבלת המסגרת החוקית הראשונה, כשמערכת הקלט של האודיו הייתה במצב חוסר פעילות ומושבתת לפני הבקשה.
זמן אחזור רציף של קלט. זמן האחזור של הקלט בפריימים הבאים, בזמן שהמכשיר מקליט אודיו.
זמן אחזור רציף הלוך ושוב. הסכום של זמן האחזור הרציף של הקלט, זמן האחזור הרציף של הפלט ותקופת מאגר אחת. תקופת האחסון הזמני מאפשרת לאפליקציה לעבד את האות ולצמצם את הפער בפאזה בין מקורות הקלט והפלט.
OpenSL ES PCM buffer queue API. קבוצת ממשקי ה-API של OpenSL ES שקשורים ל-PCM ב-Android NDK.
AAudio native audio API. קבוצת ממשקי ה-API של AAudio ב-Android NDK.
חותמת זמן. זוג שמורכב ממיקום הפריים היחסי בתוך מקור הנתונים והזמן המשוער שבו הפריים הזה נכנס או יוצא מצינור עיבוד האודיו בנקודת הקצה המשויכת. אפשר לעיין גם במאמר AudioTimestamp.
glitch. הפסקה זמנית או ערך דגימה שגוי באות האודיו, שנגרמים בדרך כלל כתוצאה מחוסר מקום במאגר לפלט, ממלאי יתר במאגר לקלט או מכל מקור אחר של רעש דיגיטלי או אנלוגי.
סטיית התקן הממוצעת. הממוצע של הערך המוחלט של הסטיות מהממוצע של קבוצת ערכים.
זמן האחזור מהקשה לצלצול. משך הזמן שחולף מהמקישה על המסך ועד לשמע הצליל שנוצר כתוצאה מהמקישה הזו ברמקול.
אם הטמעות במכשירים מגדירות את android.hardware.audio.output
, הן חייבות לעמוד בדרישות הבאות או לעלות עליהן:
- [C-1-1] חותמת הזמן של הפלט שמוחזרת על ידי AudioTrack.getTimestamp ו-
AAudioStream_getTimestamp
מדויקת בטווח של +/- 2 אלפיות השנייה. [C-1-2] זמן אחזור של פלט במצב התחלה קר (cold start) של 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
מדויקת ל-+/- 1ms.
יצירת דרישות חדשות
- [C-SR-4] מומלץ מאוד שהזמן המשוער להעברה הלוך ושוב (RTT) המחושב על סמך חותמות הזמן של הקלט והפלט שמוחזרות על ידי
AAudioStream_getTimestamp
יהיה בטווח של 30 אלפיות השנייה מהזמן המשוער להעברה הלוך ושוב שנמדד עבורAAUDIO_PERFORMANCE_MODE_NONE
ו-AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
ברמקולים, באוזניות קוויות ובאוזניות אלחוטיות.
סיום הדרישות החדשות
אם הטמעות המכשירים עומדות בדרישות שלמעלה, אחרי כיול ראשוני, כשמשתמשים ב-AAudio native audio API, זמן האחזור של הפלט הרציף וזמן האחזור של הפלט לאחר הפעלה מחדש במכשיר אחד לפחות שתומך בפלט אודיו הם:
- [C-SR-5] STRONGLY RECOMMENDED to report low-latency audio by declaring
android.hardware.audio.low_latency
feature flag. - [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 אלפיות השנייה +/-. 'שגיאה' כאן פירושה סטייה מהערך הנכון. - [C-3-2] זמן אחזור של קלט קר של 500 אלפיות שנייה או פחות.
- [C-3-3] פתיחת מקור קלט באמצעות
AAudioStreamBuilder_openStream()
חייבת להימשך פחות מ-1,000 אלפיות שנייה.
אם הטמעות במכשירים כוללות את android.hardware.microphone
, מומלץ מאוד לעמוד בדרישות הבאות לגבי אודיו קלט:
[C-SR-8] זמן אחזור של קלט קר של 100 אלפיות השנייה או פחות דרך נתיב הנתונים של המיקרופון.
[C-SR-11] הגבלת השגיאה בחותמות הזמן של הקלט, כפי שהן מוחזרות על ידי AudioRecord.getTimestamp או
AAudioStream_getTimestamp
, ל-±1ms.
אם הטמעות של מכשירים מגדירות את android.hardware.audio.output
ו-android.hardware.microphone
, הן:
- [C-SR-12] מומלץ מאוד שזמן האחזור הממוצע הלוך ושוב יהיה 50 אלפיות השנייה או פחות ב-5 מדידות, עם סטייה ממוצעת אבסולוטית של פחות מ-10 אלפיות השנייה, לפחות בנתיב נתמך אחד.
5.7. פרוטוקולי רשת
הטמעות במכשירים חייבות לתמוך בפרוטוקולים של רשתות מדיה להפעלת אודיו ווידאו, כפי שמפורט במסמכי התיעוד של Android SDK.
לכל קודק ופורמט קונטיינר שהטמעה במכשיר נדרשת לתמוך בהם, ההטמעה במכשיר:
[C-1-1] חובה לתמוך בקודק או בקונטיינר הזה באמצעות HTTP ו-HTTPS.
[C-1-2] חובה לתמוך בפורמטים התואמים של קטעי המדיה, כפי שמתואר בטבלה של פורמטים של קטעי מדיה בהמשך, באמצעות טיוטת פרוטוקול HTTP Live Streaming, גרסה 7.
[C-1-3] חובה לתמוך בפורמטים התואמים של עומסי נתונים (payload) ב-RTSP, כפי שמופיע בטבלה של RTSP בהמשך. לחריגים, ראו הערות השוליים בטבלה בקטע 5.1.
פורמטים של קטעי מדיה
פורמטים של פלחים | מקורות מידע | תמיכה בקודקים הנדרשים |
---|---|---|
MPEG-2 Transport Stream | ISO 13818 |
קודיקים של וידאו:
ו-MPEG-2 מופיעים בקטע 5.1.8. קודיקים של אודיו:
|
AAC עם מסגרת ADTS ותגי ID3 | ISO 13818-7 | פרטים על AAC ועל הווריאציות שלו מופיעים בקטע 5.1.1 . |
WebVTT | WebVTT |
RTSP (RTP, SDP)
השם בפרופיל | מקורות מידע | תמיכה בקודקים הנדרשים |
---|---|---|
H264 AVC | RFC 6184 | פרטים על H264 AVC מופיעים בקטע 5.1.8 |
MP4A-LATM | RFC 6416 | פרטים על AAC ועל הווריאציות שלו מופיעים בקטע 5.1.3 |
H263-1998 |
RFC 3551 RFC 4629 RFC 2190 |
פרטים על H263 מופיעים בקטע 5.1.8 |
H263-2000 | RFC 4629 | פרטים על H263 מופיעים בקטע 5.1.8 |
AMR | RFC 4867 | פרטים על AMR-NB מופיעים בקטע 5.1.3 |
AMR-WB | RFC 4867 | פרטים על AMR-WB מופיעים בקטע 5.1.3 |
MP4V-ES | RFC 6416 | פרטים על MPEG-4 SP מופיעים בקטע 5.1.8 |
mpeg4-generic | RFC 3640 | פרטים על AAC ועל הווריאציות שלו מופיעים בקטע 5.1.3 |
MP2T | RFC 2250 | פרטים נוספים זמינים בקטע MPEG-2 Transport Stream בקטע 'סטרימינג בשידור חי ב-HTTP'. |
5.8. Secure Media
אם הטמעות המכשיר תומכות בפלט וידאו מאובטח ויכולות לתמוך במשטחים מאובטחים, הן:
- [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 over 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 ו-
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 לאורך הנתיב MMAP.
[C-SR-3] מומלץ מאוד לספק רמה עקבית של ביצועי מעבד בזמן שהאודיו פעיל ועומס המעבד משתנה. צריך לבדוק את זה באמצעות האפליקציה ל-Android SynthMark. ב-SynthMark נעשה שימוש בסינתיסייזר תוכנה שפועל על מסגרת אודיו מדומה למדידת ביצועי המערכת. הסבר על מדדי ההשוואה מופיע במסמכי התיעוד של SynthMark. צריך להפעיל את אפליקציית SynthMark באמצעות האפשרות 'בדיקה אוטומטית' ולקבל את התוצאות הבאות:
- voicemark.90 >= 32 voices
- latencymark.fixed.little <= 15 msec
- latencymark.dynamic.little <= 50 msec
צריך לצמצם את אי-הדיוק והסטייה של שעון האודיו ביחס לשעון הרגיל.
צריך לצמצם את ההבדל בין השעון של האודיו לבין השעון של המעבד (CPU)
CLOCK_MONOTONIC
כששניהם פעילים.צריך לצמצם את זמן האחזור של האודיו באמצעות מתמרים במכשיר.
צריך לצמצם את זמן האחזור של האודיו דרך אודיו דיגיטלי ב-USB.
צריך לתעד את מדידות זמן האחזור של האודיו בכל המסלולים.
צריך לצמצם את התנודות בזמני הכניסה של הקריאה החוזרת (Callback) להשלמת מאגר השמע, כי זה משפיע על האחוז הזמין של רוחב הפס המלא של המעבד (CPU) בקריאה החוזרת.
אמורה להיות אפס תקלות אודיו בשימוש רגיל עם זמן אחזור שדווח.
צריך להיות אפס הבדל בזמן האחזור בין הערוצים.
צריך לצמצם את זמן האחזור הממוצע של MIDI בכל אמצעי התעבורה.
צריך לצמצם את התנודות בזמן האחזור של MIDI במהלך עומס (Jitter) בכל אמצעי התחבורה.
צריך לספק חותמות זמן MIDI מדויקות בכל אמצעי התעבורה.
צריך לצמצם את הרעש של אותות האודיו במכשיר באמצעות מתמרים, כולל התקופה שלאחר ההפעלה במצב התחלתי.
צריך להיות אפס הבדל בין שעון האודיו בצד הקלט לבין שעון האודיו בצד הפלט של נקודות הקצה התואמות, כששניהם פעילים. דוגמאות לנקודות קצה תואמות הן המיקרופון והרמקול במכשיר, או הקלט והפלט של שקע האודיו.
צריך לטפל בקריאות חזרה (callbacks) להשלמת מאגר האודיו בצד הקלט ובצד הפלט של נקודות הקצה התואמות באותו חוט כששתיהן פעילות, ולהיכנס לקריאת החזרה (callback) של הפלט מיד אחרי החזרה מקריאת החזרה (callback) של הקלט. לחלופין, אם לא ניתן לטפל בקריאות החזרה באותו חוט, צריך להיכנס לקריאת החזרה של הפלט זמן קצר אחרי שמזינים את קריאת החזרה של הקלט, כדי לאפשר לאפליקציה תזמון עקבי של צידי הקלט והפלט.
צריך למזער את הפרש הפאזה בין האחסון במטמון של אודיו ב-HAL בצד הקלט ובצד הפלט של נקודות הקצה התואמות.
צריך למזער את זמן האחזור של המגע.
צריך לצמצם את השונות של זמן האחזור למגע במהלך עומס (רעידה).
אם הטמעות המכשירים עומדות בכל הדרישות שלמעלה, הן:
- [C-SR-4] מומלץ מאוד לדווח על תמיכה בתכונה
android.hardware.audio.pro
באמצעות הכיתהandroid.content.pm.PackageManager
.
אם הטמעות המכשירים כוללות שקע אודיו 3.5 מ"מ עם 4 מוליכים, הן:
[C-2-1] זמן האחזור הממוצע של אודיו במסלול הלוך ושוב, כפי שמוגדר בקטע 5.6 זמן אחזור של אודיו, חייב להיות 20 אלפיות השנייה או פחות, על פני 5 מדידות עם סטייה ממוצעת של פחות מ-5 אלפיות השנייה במסלול של שקע האודיו באמצעות Audio Loopback Dongle.
[C-SR-5] מומלץ מאוד לציית לקטע Mobile device (jack) specifications (מפרטים של שקע למכשיר נייד) שמופיע בWired Audio Headset Specification (v1.1) (מפרט של אוזניות אודיו חוטיות, גרסה 1.1).
אם הטמעות של מכשירים משמיטים שקע אודיו עם 4 מוליכים בגודל 3.5 מ"מ וכוללות יציאות USB שתומכות במצב מארח USB, הן:
- [C-3-1] חובה להטמיע את מחלקת האודיו של USB.
- [C-3-2] זמן האחזור הממוצע של אודיו במסלול הלוך ושוב חייב להיות 25 אלפיות השנייה או פחות, על פני 5 מדידות עם סטייה ממוצעת אבסולוטית של פחות מ-5 אלפיות השנייה ביציאת מצב המארח של USB באמצעות סיווג אודיו USB. (אפשר למדוד את זה באמצעות מתאם USB-3.5mm ו-Audio Loopback Dongle, או באמצעות ממשק אודיו USB עם כבלים לחיבור בין מקורות הקלט לבין יציאות הקלט).
- [C-SR-6] מומלץ מאוד שתהיה תמיכה בו-זמנית ב-I/O עד 8 ערוצים בכל כיוון, בקצב דגימה של 96kHz ובעומק של 24 או 32 ביט, כשמשתמשים בציוד היקפי של אודיו USB שתומך גם בדרישות האלה.
- [C-SR-7] מומלץ מאוד לעמוד בקבוצת הדרישות הזו באמצעות ממשק ה-API המקורי של אודיו ב-AAudio דרך הנתיב 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] חובה להציג רמות אמפליטודה בטווח התדרים הנמוכים: באופן ספציפי, מ-±20 dB מ-5 z עד 100 Hz בהשוואה לטווח התדרים הבינוני לכל מיקרופון שמשמש להקלטה של מקור האודיו הלא מעובד.
[C-1-4] חובה להציג רמות אמפליטודה בטווח התדרים הגבוהים: באופן ספציפי, מ-±30 dB מ-7,000 Hz עד 22 KHz בהשוואה לטווח התדרים הבינוני לכל מיקרופון שמשמש להקלטה של מקור האודיו הלא מעובד.
[C-1-5] חובה להגדיר את רגישות הקלט של האודיו כך שמקור צלילים סינוסיים של 1,000 Hz שיופעל ברמת לחץ קול (SPL) של 94 dB יניב תגובה עם ערך RMS של 520 לדגימות של 16 ביט (או -36 dB Full Scale לדגימות של נקודת צפה/דיוק כפול) לכל מיקרופון שמשמש להקלטה של מקור האודיו הלא מעובד.
[C-1-6] חובה שיחס האות לרעש (SNR) יהיה 60 dB או יותר בכל מיקרופון שמשמש להקלטה של מקור האודיו הלא מעובד. (לעומת זאת, SNR נמדד כהפרש בין 94 dB SPL לבין SPL שווה ערך של רעש עצמי, משוקל A).
[C-1-7] המערכת חייבת לכלול עיוות הרמוני כולל (THD) של פחות מ-1% עבור 1kHz ברמת קלט של 90dB SPL בכל מיקרופון שמשמש להקלטה של מקור האודיו הלא מעובד.
[C-1-8] אסור שתהיה עיבוד אותות אחר (למשל, בקרת רווח אוטומטית, מסנן מסוג High Pass או ביטול הדהוד) בנתיבים, מלבד מכפיל רמה כדי להביא את הרמה לטווח הרצוי. במילים אחרות:
- [C-1-9] אם יש עיבוד אותות בארכיטקטורה מסיבה כלשהי, חובה להשבית אותו ולהוסיף לנתיב האות אפס עיכוב או זמן אחזור נוסף.
- [C-1-10] מותר להוסיף את מכפיל הרמה למסלול, אבל אסור שהוא יביא לעיכוב או לזמן אחזור במסלול האות.
כל מדידות ה-SPL מתבצעות ישירות ליד המיקרופון שנבדק. אם משתמשים במספר הגדרות אישיות של מיקרופון, הדרישות האלה חלות על כל מיקרופון.
אם הטמעות במכשירים מכריזות על android.hardware.microphone
אבל לא תומכות במקור אודיו לא מעובד, הן:
- [C-2-1] חובה להחזיר את הערך
null
לשיטת ה-APIAudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)
כדי לציין בצורה נכונה את חוסר התמיכה. - [C-SR-1] עדיין מומלץ מאוד לעמוד בכמה שיותר מהדרישות של נתיב האות למקור ההקלטה הלא מעובד.
5.12. וידאו HDR
Android 13 תומך בטכנולוגיות HDR כפי שמתואר במסמך שיתפרסם בקרוב.
פורמט פיקסלים
אם מפענח וידאו מצהיר על תמיכה ב-COLOR_FormatYUVP010, אז:
[C-1-1] חובה לתמוך בפורמט P010 לקריאה במעבד (ImageReader, MediaImage, ByteBuffer). ב-Android 13, הקריטריונים של P010 הופכים להיות רגועים יותר כדי לאפשר צעד שרירותי למישורי Y ו-UV.
[C-1-2] ה-GPU חייב להיות מסוגל לדגום את מאגר הפלט של P010 (כשהוא מוקצה לשימוש ב-GPU_SAMPLING). כך אפשר להשתמש ב-GPU ליצירת קומפוזיציות ולמיפוי גוונים בהתאמה אישית באפליקציות.
אם מפענח וידאו מצהיר על תמיכה ב-COLOR_Format32bitABGR2101010, הוא:
- [C-2-1] חובה לתמוך בפורמט RGBA_1010102 למשטח הפלט ולפורמט שניתנים לקריאה על ידי המעבד (פלט של ByteBuffer).
אם רכיב קודק של וידאו מצהיר על תמיכה ב-COLOR_FormatYUVP010, הוא:
- [C-3-1] חובה לתמוך בפורמט P010 עבור פלטפורמת הקלט וקלט שניתנים לכתיבה על ידי המעבד (ImageWriter, MediaImage, ByteBuffer).
אם מקודד וידאו מצהיר על תמיכה ב-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 (כבר בקורב העברת היעד) גם ל-surface של הקלט וגם ל-ByteBuffer, וחובה לפרסם תמיכה ב-COLOR_Format32bitABGR2101010.
אם ההטמעה במכשיר כוללת קודיקים שתומכים ב-FEATURE_HdrEditing, המכשיר:
- [C-7-4] חובה לפרסם תמיכה בתוסף OpenGL EXT_YUV_target.
6. תאימות של כלים ואפשרויות למפתחים
6.1. כלים למפתחים
הטמעות במכשירים:
- [C-0-1] חובה לתמוך בכלים של Android למפתחים שכלולים ב-Android SDK.
-
- [C-0-2] חובה לתמוך ב-adb כפי שמתואר ב-Android SDK ובפקודות המעטפת שסופקו ב-AOSP, שבהן מפתחי אפליקציות יכולים להשתמש, כולל
dumpsys
cmd stats
- [C-0-11] חייבת לתמוך בפקודת המעטפת
cmd testharness
. יכול להיות ששדרוג הטמעות במכשירים מגרסה קודמת של Android ללא בלוק נתונים מתמיד יהיה פטור מהדרישה של C-0-11. - [C-0-3] אסור לשנות את הפורמט או את התוכן של אירועי המערכת במכשיר (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) שמתועדים ביומן באמצעות הפקודה dumpsys.
- [C-0-10] חובה לתעד את האירועים הבאים, בלי להשמיט אף אחד מהם, ולאפשר גישה אליהם ולאפשר אותם לפקודת המעטפת
cmd stats
ולכיתהStatsManager
System API.- ActivityForegroundStateChanged
- AnomalyDetected
- AppBreadcrumbReported
- AppCrashOccurred
- AppStartOccurred
- BatteryLevelChanged
- BatterySaverModeStateChanged
- BleScanResultReceived
- BleScanStateChanged
- ChargingStateChanged
- DeviceIdleModeStateChanged
- ForegroundServiceStateChanged
- GpsScanStateChanged
- JobStateChanged
- PluggedStateChanged
- ScheduledJobStateChanged
- ScreenStateChanged
- SyncStateChanged
- SystemElapsedRealtime
- UidProcessStateChanged
- WakelockStateChanged
- WakeupAlarmOccurred
- WifiLockStateChanged
- WifiMulticastLockStateChanged
- WifiScanStateChanged
- [C-0-4] הדימון של adb בצד המכשיר חייב להיות לא פעיל כברירת מחדל, וחייבת להיות מנגנון שזמין למשתמשים כדי להפעיל את Android Debug Bridge.
- [C-0-5] חובה לתמוך ב-adb מאובטח. ב-Android יש תמיכה ב-adb מאובטח. Secure adb מאפשר להפעיל את adb במארחים מוכרים ומאומתים.
- [C-0-6] חובה לספק מנגנון שמאפשר להתחבר ל-adb ממכונת מארח. פרטים נוספים:
אם הטמעות של מכשירים ללא יציאת USB תומכות במצב ציוד היקפי, הן:
- [C-3-1] חובה להטמיע את adb דרך רשת מקומית (כמו Ethernet או Wi-Fi).
- [C-3-2] חובה לספק מנהלי התקנים ל-Windows 7, 8 ו-10, שמאפשרים למפתחים להתחבר למכשיר באמצעות פרוטוקול adb.
אם הטמעות המכשירים תומכות בחיבורי adb למכונה המארחת דרך Wi-Fi או אתרנט, הן:
- [C-4-1] השיטה
AdbManager#isAdbWifiSupported()
חייבת להחזיר את הערךtrue
.
אם הטמעות המכשירים תומכות בחיבורי adb למכונה מארחת דרך Wi-Fi או אתרנט, וכוללות לפחות מצלמה אחת, הן:
- [C-5-1] השיטה
AdbManager#isAdbWifiQrSupported()
חייבת להחזיר את הערךtrue
.
- [C-0-2] חובה לתמוך ב-adb כפי שמתואר ב-Android SDK ובפקודות המעטפת שסופקו ב-AOSP, שבהן מפתחי אפליקציות יכולים להשתמש, כולל
Dalvik Debug Monitor Service (ddms)
- [C-0-7] חובה לתמוך בכל התכונות של DDMS כפי שמתואר ב-Android SDK. מכיוון ש-ddms משתמש ב-adb, התמיכה ב-ddms אמורה להיות לא פעילה כברירת מחדל, אבל חייבת להיות תמיכה בכל פעם שהמשתמש מפעיל את Android Debug Bridge, כפי שמתואר למעלה.
-
- [C-0-9] חובה לתמוך בכלי systrace כפי שמתואר ב-Android SDK. Systrace חייב להיות לא פעיל כברירת מחדל, וחייבת להיות מנגנון שזמין למשתמשים כדי להפעיל את Systrace.
-
- [C-SR-1] מומלץ מאוד לחשוף למשתמש המעטפת קובץ בינארי של
/system/bin/perfetto
, ש-cmdline שלו עומד בדרישות של מסמכי התיעוד של perfetto. - [C-SR-2] מומלץ מאוד שהקובץ הבינארי של perfetto יקבל כקלט קובץ תצורה של protobuf שתואם להסכימה שמוגדרת במסמכי התיעוד של perfetto.
- [C-SR-3] מומלץ מאוד לכתוב את הקובץ הבינארי של perfetto כמעקב protobuf כפלט, בהתאם לסכימה שמוגדרת במסמכי התיעוד של perfetto.
- [C-SR-4] מומלץ מאוד לספק, באמצעות הקובץ הבינארי של perfetto, לפחות את מקורות הנתונים שמתוארים במסמכי התיעוד של perfetto.
- [C-SR-1] מומלץ מאוד לחשוף למשתמש המעטפת קובץ בינארי של
-
- [C-0-12] חובה לכתוב
LMK_KILL_OCCURRED_FIELD_NUMBER
Atom ביומן statsd כשאפליקציה מסתיימת על ידי Low Memory Killer.
- [C-0-12] חובה לכתוב
מצב מסגרת בדיקה אם הטמעות המכשיר תומכות בפקודת המעטפת
cmd testharness
ומריצות אתcmd testharness enable
, הן:- [C-2-1] חובה להחזיר את הערך
true
עבורActivityManager.isRunningInUserTestHarness()
- [C-2-2] חובה להטמיע את מצב 'מסגרת בדיקה' כפי שמתואר במסמכי התיעוד של מצב 'מסגרת בדיקה'.
- [C-2-1] חובה להחזיר את הערך
מידע על משימות GPU
הטמעות במכשירים:
- [C-0-13] חובה להטמיע את פקודת המעטפת
dumpsys gpu --gpuwork
כדי להציג את נתוני העבודה המצטברים של ה-GPU שמוחזרים על ידי נקודת המעקבpower/gpu_work_period
בליבה, או לא להציג נתונים אם נקודת המעקב לא נתמכת. ההטמעה ב-AOSP היאframeworks/native/services/gpuservice/gpuwork/
.
- [C-0-13] חובה להטמיע את פקודת המעטפת
אם הטמעות במכשירים מדווחות על תמיכה ב-Vulkan 1.0 ואילך באמצעות דגלים של תכונות android.hardware.vulkan.version
, הן:
- [C-1-1] חובה לספק למפתח האפליקציה אפשרות להפעיל או להשבית שכבות לניפוי באגים ב-GPU.
- [C-1-2] כששכבות ניפוי הבאגים של ה-GPU מופעלות, חובה למנות שכבות בספריות שסופקו על ידי כלים חיצוניים (כלומר, לא חלק מהפלטפורמה או מחבילת האפליקציה) שנמצאות בספריית הבסיס של אפליקציות שניתן לנפות באגים בהן, כדי לתמוך בשיטות ה-API vkEnumerateInstanceLayerProperties() ו-vkCreateInstance().
6.2. אפשרויות למפתחים
Android כולל תמיכה למפתחים להגדרת הגדרות שקשורות לפיתוח אפליקציות.
הטמעות במכשירים חייבות לספק חוויה עקבית של אפשרויות למפתחים, והן:
- [C-0-1] חובה לפעול בהתאם לכוונה של android.settings.APPLICATION_DEVELOPMENT_SETTINGS כדי להציג הגדרות שקשורות לפיתוח אפליקציות. בהטמעה של Android במקור, תפריט האפשרויות למפתחים מוסתר כברירת מחדל, והמשתמשים יכולים להפעיל אותו אחרי שלוחצים שבע (7) פעמים על הפריט בתפריט הגדרות > מידע על המכשיר > מספר Build.
- [C-0-2] חובה להסתיר את האפשרויות למפתחים כברירת מחדל.
- [C-0-3] חובה לספק מנגנון ברור שלא נותן עדיפות לאפליקציה אחת של צד שלישי על פני אפליקציה אחרת כדי להפעיל את Developer Options. חובה לספק מסמך או אתר גלוי לכולם שמתארים איך מפעילים את אפשרויות הפיתוח. חובה שאפשר יהיה לקשר את המסמך או את אתר האינטרנט הזה למסמכים של Android SDK.
- צריכה להיות התראה חזותית מתמשכת למשתמש כשהאפשרויות למפתחים מופעלות ויש חשש לגבי בטיחות המשתמש.
- יכולים להגביל באופן זמני את הגישה לתפריט 'אפשרויות למפתחים', על ידי הסתרה חזותית או השבתה של התפריט, כדי למנוע הסחות דעת בתרחישים שבהם יש חשש לגבי בטיחות המשתמש.
7. תאימות חומרה
אם מכשיר כולל רכיב חומרה מסוים שיש לו ממשק API תואם למפתחים של צד שלישי:
- [C-0-1] ההטמעה במכשיר חייבת לכלול את ממשק ה-API הזה כפי שמתואר במסמכי התיעוד של Android SDK.
אם ממשק API ב-SDK מקיים אינטראקציה עם רכיב חומרה שצוין כאופציונלי, וההטמעה במכשיר לא כוללת את הרכיב הזה:
- [C-0-2] עדיין צריך להציג הגדרות מלאות של כיתות (כפי שמתועד ב-SDK) לממשקי ה-API של הרכיבים.
- [C-0-3] חובה להטמיע את ההתנהגויות של ה-API כ-no-ops באופן סביר כלשהו.
- [C-0-4] שיטות API חייבות להחזיר ערכים null במקרים שבהם מותר לעשות זאת במסמכי התיעוד של ה-SDK.
- [C-0-5] שיטות API חייבות להחזיר הטמעות של no-op של כיתות שבהן ערכים null לא מותרים לפי מסמכי ה-SDK.
- [C-0-6] אסור לשיטות API להוציא חריגות שלא מתועדות במסמכי התיעוד של ה-SDK.
- [C-0-7] הטמעות של מכשירים חייבות לדווח באופן עקבי על פרטי הגדרת חומרה מדויקים באמצעות השיטות
getSystemAvailableFeatures()
ו-hasSystemFeature(String)
בכיתה android.content.pm.PackageManager לאותו טביעת אצבע של build.
דוגמה אופיינית לתרחיש שבו הדרישות האלה חלות היא API של טלפוניה: גם במכשירים שאינם טלפונים, צריך להטמיע את ממשקי ה-API האלה כ-no-ops סבירים.
7.1. תצוגה וגרפיקה
מערכת Android כוללת תכונות שמתאמות באופן אוטומטי את נכסי האפליקציה ואת הפריסות של ממשק המשתמש בהתאם למכשיר, כדי להבטיח שאפליקציות של צד שלישי יפעלו בצורה תקינה במגוון תצורות חומרה ובמגוון תצוגות ותצורות חומרה. מסך תואם ל-Android הוא מסך שמטמיע את כל ההתנהגויות והממשקי ה-API שמתוארים במאמר Android Developers – Screen compatibility overview, בקטע הזה (7.1) ובקטעים המשניים שלו, וכן כל התנהגות נוספת ספציפית לסוג המכשיר שמתועדת בקטע 2 של ה-CDD הזה.
במסכים התואמים ל-Android שבהם אפשר להריץ את כל האפליקציות של צד שלישי שתואמות ל-Android, חייבים להטמיע את ממשקי ה-API ואת ההתנהגויות האלה במכשירים בצורה תקינה, כפי שמפורט בקטע הזה.
יצירת דרישות חדשות
הטמעות במכשירים:
- [C-0-1] חובה, כברירת מחדל, ליצור עיבוד (רנדור) של אפליקציות צד שלישי רק במסכים שתואמים ל-Android.
סיום הדרישות החדשות
היחידות שאליהם מתייחסות הדרישות בקטע הזה מוגדרות באופן הבא:
- גודל פיזי באלכסון. המרחק בסנטימטרים בין שני פינות מנוגדות של החלק המואר של המסך.
צפיפות הנקודות לאינץ' (dpi). מספר הפיקסלים שמקובצים בשטח אופקי או אנכי של אינץ' אחד, שמתבטא בפיקסלים לאינץ' (ppi או dpi). כאשר מוצגים ערכים שלdpippi ו-dpi, הערכים של dpi אופקי ואנכי חייבים להיות בטווח שצוין.- יחס גובה-רוחב. היחס בין מספר הפיקסלים של המידה הארוכה למספר הפיקסלים של המידה הקצרה של המסך. לדוגמה, במסך בגודל 480x854 פיקסלים, היחס יהיה 854/480 = 1.779, או בערך '16:9'.
- פיקסל שלא תלוי בצפיפות (dp).
יחידת הפיקסלים הווירטואלייםמסוג A, שמותאמת למסך של 160dpiעם דחיסות מסך של 160. לדחיסות מסוימת d ומספר פיקסלים p, מספר הפיקסלים הבלתי תלויים בדחיסות (dp) מחושב כך:pixels = dps * (density/160)dp = (160 / d) * p .
7.1.1. הגדרת מסך
7.1.1.1. גודל המסך וצורת המסך
מסגרת ממשק המשתמש של Android תומכת במגוון גדלים לוגיים שונים של פריסות מסך, ומאפשרת לאפליקציות לשלוח שאילתה לגבי גודל פריסת המסך של ההגדרה הנוכחית דרך Configuration.screenLayout
באמצעות SCREENLAYOUT_SIZE_MASK
ו-Configuration.smallestScreenWidthDp
.
הטמעות במכשירים:
[C-0-1] חובה לדווח על גודל הפריסה הנכון של
Configuration.screenLayout
כפי שמוגדר במסמכי התיעוד של Android SDK. באופן ספציפי, הטמעות של מכשירים חייבות לדווח על מידות המסך הנכונות של הפיקסלים (dp) לוגיים שאינם תלויים בדחיסות, כפי שמפורט בהמשך:- במכשירים שבהם הערך של
Configuration.uiMode
מוגדר כערך שאינו UI_MODE_TYPE_WATCH, ושהמערכת מדווחת על גודלsmall
עבורConfiguration.screenLayout
, חייבת להיות רזולוציה של לפחות 426dp x 320dp. - במכשירים שמדווחים על גודל
normal
שלConfiguration.screenLayout
, חייב להיות לפחות 480dp x 320dp. - במכשירים שמדווחים על גודל
large
שלConfiguration.screenLayout
, חייבת להיות רזולוציה של לפחות 640dp x 480dp. - מכשירים שמדווחים על גודל
xlarge
שלConfiguration.screenLayout
חייבים להיות בגודל של 960dp x 720dp לפחות.
- במכשירים שבהם הערך של
[C-0-2] חובה לפעול בהתאם לתמיכה המוצהרת של האפליקציות בגדלים שונים של מסכים באמצעות המאפיין <
supports-screens
> בקובץ AndroidManifest.xml, כפי שמתואר במסמכי התיעוד של Android SDK.יכול להיות שיש להם מסכים תואמי Android עם פינות מעוגלות.
אם הטמעות המכשירים תומכות במסכים עם תמיכה בהגדרת הגודל UI_MODE_TYPE_NORMAL
, וכוללות מסכים פיזיים
שתומכים ב-Android עם פינות מעוגלות לעיבוד המסכים האלה, הן:
[C-1-1] חובה לוודא שלכל תצוגה כזו מתקיימת לפחות אחת מהדרישות הבאות:
- הרדיוס של הפינות המעוגלות צריך להיות קטן מ-38dp או שווה לו.
- כש
תיבת 1518 dp על1518 dp מוצמדת לכל פינה של המסך הלוגי, לפחות פיקסל אחד מכל תיבה גלוי במסך.
צריך לכלול אפשרות למשתמש לעבור למצב התצוגה עם הפינות המלבניות.
יצירת דרישות חדשות
אם הטמעות המכשירים מסוגלות רק להגדרת מקלדת NO_KEYS
, ורוצים לדווח על תמיכה בהגדרת UI_MODE_TYPE_NORMAL
של ממשק המשתמש, צריך:
- [C-4-1] גודל הפריסה, לא כולל חתכים בתצוגה, חייב להיות לפחות 596dp x 384dp או יותר.
סיום הדרישות החדשות
אם הטמעות של מכשירים כוללות מסכים מתקפלים שתואמים ל-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] חובה להטמיע את הגרסה הנכונה של Window Manager Extensions ברמת ה-API, כפי שמתואר במאמר WindowManager Extensions.
סיום הדרישות החדשות
7.1.1.2. יחס הגובה-רוחב של המסך
אין הגבלה על יחס הגובה-רוחב של המסך הפיזי במסכים שתואמים ל-Android, אבל יחס הגובה-רוחב של המסך הלוגי שבו מתבצע העיבוד של אפליקציות צד שלישי, שאפשר להסיק מערכות הגובה והרוחב שדווחו דרך ממשקי ה-API של view.Display
ושל הגדרה, חייב לעמוד בדרישות הבאות:
[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
דחיסות המקור. - כדי להבטיח נוחות שימוש וגדלים עקביים של גופנים, מומלץ לספק את האפשרויות הבאות של שינוי קנה המידה של תצוגה מותאמת אישית (תוך ציות למגבלות שצוינו למעלה)
- קטן: 0.85x
- ברירת המחדל: 1x (קנה המידה של התצוגה המקורית)
- גדולה: 1.15x
- גדול יותר: 1.3x
- הגדול ביותר 1.45x
7.1.2. מדדי רשת המדיה
אם הטמעות המכשירים כוללות את המסכים התואמים ל-Android או את פלט הווידאו למסכים התואמים ל-Android, הן:
- [C-1-1] חובה לדווח על ערכים נכונים לכל מדדי התצוגה שתואמים ל-Android שמוגדרים ב-API של
android.util.DisplayMetrics
.
אם הטמעות המכשירים לא כוללות מסך מוטמע או פלט וידאו, הן:
- [C-2-1] חובה לדווח על ערכים נכונים של המסך התואם ל-Android, כפי שהם מוגדרים ב-API של
android.util.DisplayMetrics
עבורview.Display
ברירת המחדל המאומלל.
7.1.3. כיוון מסך
הטמעות במכשירים:
- [C-0-1] חובה לדווח על כיווני המסך שנתמכים (
android.hardware.screen.portrait
ו/אוandroid.hardware.screen.landscape
) ועל כיוון אחד לפחות שנתמך. לדוגמה, מכשיר עם מסך אופקי קבוע, כמו טלוויזיה או מחשב נייד, צריך לדווח רק עלandroid.hardware.screen.landscape
. - [C-0-2] חובה לדווח על הערך הנכון של כיוון המכשיר הנוכחי בכל פעם שמתבצעת שאילתה דרך
android.content.res.Configuration.orientation
,android.view.Display.getOrientation()
או ממשקי API אחרים.
אם הטמעות במכשירים תומכות בשני כיווני המסך, הן:
- [C-1-1] חובה לתמוך בכיוון דינמי של אפליקציות, לכיוון אנכי או לרוחב. כלומר, המכשיר חייב לפעול בהתאם לבקשת האפליקציה לכיוון מסך ספציפי.
- [C-1-2] אסור לשנות את גודל המסך או את הצפיפות שמדווחים כשמשנים את הכיוון.
- אפשר לבחור כיוון לאורך או לרוחב כברירת מחדל.
7.1.4. האצת גרפיקה 2D ו-3D
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.
בדיקות OpenGL ES dEQP מחולקות למספר רשימות בדיקות, לכל אחת מהן משויך תאריך או מספר גרסת. הם נמצאים בעץ המקור של 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] חובה לעבור את כל בדיקות dEQP של OpenGL ES ברשימות הבדיקות בין הגרסה 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] חובה לתמוך בחבילת התוספים של OpenGL ES ל-Android במלואה.
אם הטמעות המכשירים תומכות ב-Android Extension Pack של 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.
בדיקות Vulkan dEQP מחולקות למספר רשימות בדיקות, לכל אחת מהן תאריך או גרסה משויכים. הם נמצאים בעץ המקור של 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
אחד לממשק ה-API המקורי של VulkanvkEnumeratePhysicalDevices()
. - [C-1-3] חובה להטמיע באופן מלא את ממשקי ה-API של
Vulkan 1.0Vulkan 1.1 לכלVkPhysicalDevice
שמפורטים. - [C-1-4] חובה למנות שכבות שמכילות ספריות מקומיות בשם
libVkLayer*.so
בספריית הספריות המקומיות של חבילת האפליקציה, באמצעות ממשקי ה-API המקומיים של VulkanvkEnumerateInstanceLayerProperties()
ו-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] חובה לדווח על הגרסה המקסימלית של בדיקות Vulkan dEQP שנתמכות באמצעות דגל התכונה
android.software.vulkan.deqp.level
. - [C-1-9] חייב לתמוך לפחות בגרסה
132317953
(החל מ-1 במרץ 2019) כפי שצוין בדגל התכונהandroid.software.vulkan.deqp.level
. - [C-1-10] חובה לעבור את כל בדיקות Vulkan dEQP ברשימות הבדיקות בין הגרסה
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 המקורי של VulkanvkEnumeratePhysicalDevices()
.
אם הטמעות במכשירים כוללות תמיכה ב-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 האצת גרפיקה 2D
מערכת Android כוללת מנגנון שמאפשר לאפליקציות להצהיר שהן רוצות להפעיל האצת חומרה לגרפיקה 2D ברמת האפליקציה, הפעילות, החלון או התצוגה באמצעות תג המניפסט android:hardwareAccelerated או קריאות ישירות ל-API.
הטמעות במכשירים:
- [C-0-1] חובה להפעיל את שיפור המהירות באמצעות חומרה כברירת מחדל, וחובה להשבית את שיפור המהירות באמצעות חומרה אם המפתח מבקש זאת, על ידי הגדרת android:hardwareAccelerated="false" או השבתת שיפור המהירות באמצעות חומרה ישירות דרך Android View APIs.
- [C-0-2] חובה להציג התנהגות עקבית עם המסמכים של Android SDK בנושא שיפור מהירות באמצעות חומרה.
Android כולל אובייקט TextureView שמאפשר למפתחים לשלב ישירות טקסטורות של OpenGL ES שמואצות בחומרה כיעדים לעיבוד (render) בהיררכיית ממשק המשתמש.
הטמעות במכשירים:
- [C-0-3] חובה לתמוך ב-TextureView API, וחובה להציג התנהגות עקבית עם ההטמעה של Android במקור.
7.1.4.5 מסכים עם מגוון רחב של צבעים
אם הטמעות במכשירים מצהירות על תמיכה בצגים עם מגוון רחב של צבעים באמצעות Configuration.isScreenWideColorGamut()
, הן:
- [C-1-1] חובה שיהיה מסך עם כיול צבע.
- [C-1-2] חובה שיהיה צג שהספקטרום שלו מכסה את ספקטרום הצבעים של sRGB במלואו במרחב CIE 1931 xyY.
- [C-1-3] חייב להיות צג ששטח המגוון שלו הוא לפחות 90% מ-DCI-P3 במרחב CIE 1931 xyY.
- [C-1-4] חובה לתמוך ב-OpenGL ES 3.1 או 3.2 ולדווח על כך בצורה תקינה.
- [C-1-5] חובה לפרסם תמיכה בתוספים
EGL_KHR_no_config_context
,EGL_EXT_pixel_format_float
,EGL_KHR_gl_colorspace
,EGL_EXT_gl_colorspace_scrgb
,EGL_EXT_gl_colorspace_scrgb_linear
,EGL_EXT_gl_colorspace_display_p3
,EGL_EXT_gl_colorspace_display_p3_linear
ו-EGL_EXT_gl_colorspace_display_p3_passthrough
. - [C-SR-1] מומלץ מאוד לתמוך ב-
GL_EXT_sRGB
.
לעומת זאת, אם הטמעות במכשירים לא תומכות במסכים עם מגוון רחב של צבעים, הן:
- [C-2-1] צריך לכסות 100% או יותר מ-sRGB במרחב CIE 1931 xyY, למרות שסולם הצבעים של המסך לא מוגדר.
7.1.5. מצב תאימות לאפליקציות מדור קודם
ב-Android מוגדר 'מצב תאימות' שבו המסגרת פועלת במצב 'רגיל' שתואם לגודל מסך (רוחב 320dp) לטובת אפליקציות מדור קודם שלא פותחו לגרסאות ישנות של Android שקדמו לעצמאות מגודל המסך.
7.1.6. טכנולוגיית המסך
פלטפורמת Android כוללת ממשקי API שמאפשרים לאפליקציות ליצור גרפיקה עשירה ולהציג אותה במסך תואם ל-Android. המכשירים חייבים לתמוך בכל ממשקי ה-API האלה כפי שמוגדרים ב-Android SDK, אלא אם צוין אחרת במפורש במסמך הזה.
כל המסכים התואמים ל-Android בהטמעת המכשיר:
- [C-0-1] חייב להיות מסוגל ליצור גרפיקה צבעונית של 16 ביט.
- צריכה להיות תמיכה במסכים עם גרפיקה צבעונית של 24 ביט.
- [C-0-2] חייב להיות מסוגל לעבד אנימציות.
- [C-0-3] חייב להיות יחס גובה-רוחב של פיקסלים (PAR) בין 0.9 ל-1.15. כלומר, יחס הגובה-רוחב של הפיקסלים חייב להיות קרוב לריבוע (1.0) עם טווח סטייה של 10% עד 15%.
7.1.7. מסכים משניים
מערכת Android כוללת תמיכה במסכים משניים תואמי Android, כדי לאפשר שיתוף מדיה וממשקי API למפתחים לגישה למסכים חיצוניים.
אם הטמעות המכשיר תומכות במסך חיצוני באמצעות חיבור קווי, אלחוטי או צג מובנה נוסף, הן:
- [C-1-1] חובה להטמיע את השירות וה-API של המערכת
DisplayManager
כפי שמתואר במסמכי התיעוד של Android SDK.
7.2. התקני קלט
הטמעות במכשירים:
- [C-0-1] חובה לכלול מנגנון קלט, כמו מסך מגע או ניווט ללא מגע, כדי לנווט בין רכיבי ממשק המשתמש.
7.2.1. מקלדת
אם ההטמעות במכשירים כוללות תמיכה באפליקציות של צד שלישי של עורך שיטות קלט (IME), הן:
- [C-1-1] חובה להצהיר על ה-feature flag
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 כולל תמיכה בלחצן כיוון, בטרקר-בול ובגלגל כמנגנונים לניווט ללא מגע.
הטמעות במכשירים:
- [C-0-1] חובה לדווח על הערך הנכון של android.content.res.Configuration.navigation.
אם בהטמעות של מכשירים אין ניווטים ללא מגע, הן:
- [C-1-1] חובה לספק מנגנון חלופי סביר של ממשק משתמש לבחירה ולעריכה של טקסט, שתואמת למנועי ניהול קלט. ההטמעה של Android בקוד פתוח במקור כוללת מנגנון בחירה שמתאים לשימוש במכשירים שאין בהם מקורות קלט לניווט ללא מגע.
7.2.3. מקשי ניווט
הפונקציות בית, מהזמן האחרון וחזרה, שזמינות בדרך כלל דרך אינטראקציה עם לחצן פיזי ייעודי או עם חלק נפרד במסך המגע, הן חיוניות לתפיסה של ניווט ב-Android, ולכן גם להטמעות במכשירים:
- [C-0-1] חובה לספק למשתמש אפשרות להפעיל אפליקציות מותקנות שיש להן פעילות עם
<intent-filter>
שמוגדר כ-ACTION=MAIN
ו-CATEGORY=LAUNCHER
אוCATEGORY=LEANBACK_LAUNCHER
להטמעות במכשירי טלוויזיה. הפונקציה 'דף הבית' אמורה להיות המנגנון של האפשרות הזו למשתמש. - צריך לספק לחצנים לפונקציות 'פריטים אחרונים' ו'חזרה'.
אם הפונקציות 'דף הבית', 'פריטים אחרונים' או 'חזרה' זמינות, הן:
- [C-1-1] חובה שאפשר יהיה לגשת אליהם באמצעות פעולה אחת (למשל הקשה, לחיצה כפולה או מחווה) כשכל אחת מהן נגישה.
- [C-1-2] חובה לציין בבירור איזו פעולה יחידה תפעיל כל פונקציה. דוגמאות לאותות כאלה הן הדפסת סמל גלוי על הלחצן, הצגת סמל תוכנה בחלק של סרגל הניווט במסך או הדרכה של המשתמש בתהליך הדגמה מפורט ומדריך במהלך חוויית ההגדרה מחוץ לקופסה.
הטמעות במכשירים:
[C-SR-1] מומלץ מאוד לא לספק את מנגנון הקלט של פונקציית התפריט, כי הוא הוצא משימוש לטובת סרגל הפעולות החל מגרסה 4.0 של Android.
[C-SR-2] מומלץ מאוד לספק את כל פונקציות הניווט כפונקציות שניתן לבטל. 'ניתן לבטל' מוגדר כיכולת של המשתמש למנוע את הפעלת פונקציית הניווט (למשל, חזרה למסך הבית, חזרה אחורה וכו') אם הוא לא משחרר את החלקת האצבע אחרי ערך סף מסוים.
אם הטמעות במכשירים מספקות את הפונקציה 'תפריט', הן:
- [C-2-1] חובה להציג את לחצן האפשרויות הנוספות של הפעולות בכל פעם שתפריט האפשרויות הנוספות של הפעולות לא ריק וסרגל הפעולות גלוי.
- [C-2-2] אסור לשנות את המיקום של חלון הקופץ של האפשרויות הנוספות של הפעולות שמוצג כשבוחרים בלחצן האפשרויות הנוספות בסרגל הפעולות, אבל מותר להציג את חלון הקופץ של האפשרויות הנוספות של הפעולות במיקום שונה במסך כשבוחרים בפונקציית התפריט.
אם הטמעות במכשירים לא מספקות את הפונקציה Menu, כדי לשמור על תאימות לאחור, הן:
- [C-3-1] חובה להפוך את פונקציית התפריט לזמינה לאפליקציות כש
targetSdkVersion
קטן מ-10, באמצעות לחצן פיזי, מקש תוכנה או תנועות. הפונקציה 'תפריט' צריכה להיות נגישה, אלא אם היא מוסתרת יחד עם פונקציות ניווט אחרות.
אם הטמעות במכשירים מספקות את הפונקציה Assist, הן:
- [C-4-1] חובה להפוך את פונקציית Assist לנגישה באמצעות פעולה אחת (למשל הקשה, לחיצה כפולה או תנועה) כשמפתחות ניווט אחרים נגישים.
- [C-SR-3] מומלץ מאוד להשתמש בלחיצה ארוכה על לחצן הבית בתור האינטראקציה הייעודית הזו.
אם בהטמעות במכשירים נעשה שימוש בחלק נפרד מהמסך כדי להציג את לחצני הניווט, הן:
- [C-5-1] לחצני הניווט חייבים להשתמש בחלק נפרד מהמסך, שלא זמין לאפליקציות, אסור שהם יחסמו או יפריעו באופן אחר לחלק מהמסך שזמין לאפליקציות.
- [C-5-2] חובה להקצות חלק מהמסך לאפליקציות שעומדות בדרישות שמפורטות בסעיף 7.1.1.
- [C-5-3] חובה לכבד את הדגלים שהוגדרו על ידי האפליקציה באמצעות שיטת ה-API
View.setSystemUiVisibility()
, כדי שהחלק הייחודי הזה במסך (שנקרא גם סרגל הניווט) יהיה מוסתר כראוי, כפי שמתואר ב-SDK.
אם פונקציית הניווט מוצגת כפעולה מבוססת-תנועה במסך:
- [C-6-1]
WindowInsets#getMandatorySystemGestureInsets()
אסור להשתמש ב-WindowInsets#getMandatorySystemGestureInsets()
אלא כדי לדווח על אזור זיהוי התנועות להפעלת דף הבית. - [C-6-2] אסור ליירט תנועות שמתחילות בתוך מלבון החרגה שסופק על ידי האפליקציה שבחזית באמצעות
View#setSystemGestureExclusionRects()
, אבל מחוץ לWindowInsets#getMandatorySystemGestureInsets()
, עבור פונקציית הניווט, כל עוד מלבון החרגה מותר בתוך מגבלת החרגה המקסימלית כפי שצוין במסמכי העזרה של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] כשהאפליקציה שבחזית מוגדרים לה הדגלים View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT או WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, מחיקה מהקצוות חייבת להתנהג כפי שהיא מיושמת ב-AOSP, כפי שמתואר ב-SDK.
- [C-7-4] כשהאפליקציה שבחזית מוגדרים לה הדגלים View.SYSTEM_UI_FLAG_IMMERSIVE, View.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.
אם הטמעות במכשירים מספקות תמיכה ב-System API setNavBarMode
כדי לאפשר לכל אפליקציית מערכת עם ההרשאה android.permission.STATUS_BAR
להגדיר את המצב של סרגל הניווט, הן:
- [C-9-1] חובה לספק תמיכה בסמלים ידידותיים לילדים או בניווט מבוסס-לחצנים, כפי שמפורט בקוד AOSP.
7.2.4. קלט במסך מגע
Android כולל תמיכה במגוון מערכות קלט של סמן, כמו מסכי מגע, משטחי מגע ומכשירי קלט מזויפים של מגע. הטמעות במכשירים מבוססי מסך מגע משויכות למסך כך שהמשתמש מרגיש שהוא מבצע פעולות ישירות בפריטים במסך. מכיוון שהמשתמש נוגע ישירות במסך, המערכת לא צריכה אמצעי עזר נוספים כדי לציין את האובייקטים שבהם מבצעים פעולות.
הטמעות במכשירים:
- צריכה להיות מערכת קלט של סמן כלשהו (כמו עכבר או מגע).
- צריכה להיות תמיכה בסמנים עם מעקב עצמאי מלא.
אם הטמעות במכשירים כוללות מסך מגע (מסך מגע עם לחיצה אחת או יותר) בצג ראשי תואם ל-Android, הן:
- [C-1-1] חובה לדווח על
TOUCHSCREEN_FINGER
בשדה ה-APIConfiguration.touchscreen
. - [C-1-2] חובה לדווח על דגלי התכונות
android.hardware.touchscreen
ו-android.hardware.faketouch
.
אם הטמעות במכשירים כוללות מסך מגע שיכול לעקוב אחרי יותר ממגע אחד במסך ראשי תואם ל-Android, הן:
- [C-2-1] חובה לדווח על דגלי התכונות המתאימים
android.hardware.touchscreen.multitouch
,android.hardware.touchscreen.multitouch.distinct
,android.hardware.touchscreen.multitouch.jazzhand
, בהתאם לסוג מסך המגע הספציפי במכשיר.
אם הטמעות של מכשירים מסתמכות על התקן קלט חיצוני, כמו עכבר או טרקר-בול (כלומר, לא נוגעים ישירות במסך) כדי להזין נתונים במסך ראשי תואם ל-Android, ועומדות בדרישות לגבי מגע מזויף שמפורטות בקטע 7.2.5, הן:
- [C-3-1] אסור לדווח על דגל תכונה שמתחיל ב-
android.hardware.touchscreen
. - [C-3-2] חובה לדווח רק על
android.hardware.faketouch
. - [C-3-3] חובה לדווח על
TOUCHSCREEN_NOTOUCH
בשדה ה-APIConfiguration.touchscreen
.
7.2.5. קלט מגע מזויף
ממשק מגע מזויף מספק מערכת קלט של משתמש שמתקרבת לקבוצת משנה של יכולות מסך המגע. לדוגמה, עכבר או שלט רחוק שמניעים סמן במסך דומים למגע, אבל המשתמש צריך קודם להצביע או להתמקד ואז ללחוץ. מכשירים רבים לקליטת נתונים, כמו עכבר, משטח מגע, עכבר אוויר מבוסס-ג'ירו, סמן ג'ירו, ג'ויסטיק ומשטח מגע עם תמיכה במספר נקודות מגע, יכולים לתמוך באינטראקציות מגע מזויפות. Android כולל את המאפיין הקבוע android.hardware.faketouch, שמתאים למכשיר קלט לא מגע (מבוסס-סמן) באיכות גבוהה, כמו עכבר או משטח מגע, שיכול לדמות בצורה הולמת קלט מבוסס-מגע (כולל תמיכה בתנועות בסיסיות), ומציין שהמכשיר תומך בקבוצת משנה של פונקציונליות של מסך מגע.
אם הטמעות במכשירים לא כוללות מסך מגע אבל כן כוללות מערכת קלט אחרת של סמן שרוצים להפוך לזמינה, צריך:
- צריך להצהיר על תמיכה ב-feature flag
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 במקור עומדת בדרישה הזו.
אם הטמעות של מכשירים מטמיעות בקר או נשלחות עם בקר נפרד בקופסה, שמאפשרים להזין את כל האירועים שמפורטים בטבלאות הבאות, הן:
- [C-2-1] חובה להצהיר על דגל התכונה
android.hardware.gamepad
לחצן | שימוש ב-HID2 | Android Button |
---|---|---|
A1 | 0x09 0x0001 | KEYCODE_BUTTON_A (96) |
B1 | 0x09 0x0002 | KEYCODE_BUTTON_B (97) |
X1 | 0x09 0x0004 | KEYCODE_BUTTON_X (99) |
Y1 | 0x09 0x0005 | KEYCODE_BUTTON_Y (100) |
לוח החיוג למעלה1 לוח החיוג למטה1 |
0x01 0x00393 | AXIS_HAT_Y4 |
מקשי החיצים (D-pad) שמאלה1 מקשי החיצים (D-pad) ימינה1 |
0x01 0x00393 | AXIS_HAT_X4 |
לחצן הכתף השמאלי1 | 0x09 0x0007 | KEYCODE_BUTTON_L1 (102) |
לחצן הכתף הימני1 | 0x09 0x0008 | KEYCODE_BUTTON_R1 (103) |
לחיצה על מקש הלחצן הימני1 | 0x09 0x000E | KEYCODE_BUTTON_THUMBL (106) |
לחיצה על מקש ה-D-pad הימני1 | 0x09 0x000F | KEYCODE_BUTTON_THUMBR (107) |
הקודם1 | 0x0c 0x0224 | KEYCODE_BACK (4) |
1 KeyEvent
2 צריך להצהיר על שימושי ה-HID שלמעלה ב-CA של משטח המשחק (0x01 0x0005).
3 השימוש הזה חייב לכלול ערך מינימלי לוגי של 0, ערך מקסימלי לוגי של 7, ערך מינימלי פיזי של 0, ערך מקסימלי פיזי של 315, יחידות ב-Degrees ורזולוציית דוח של 4. הערך הלוגי מוגדר כסיבוב בכיוון השעון מהציר האנכי. לדוגמה, ערך לוגי של 0 מייצג סיבוב ללא לחיצה על לחצן למעלה, ואילו ערך לוגי של 1 מייצג סיבוב של 45 מעלות ולחיצה על המקשים למעלה ולשמאל.
אמצעי בקרה אנלוגיים1 | שימוש ב-HID | Android Button |
---|---|---|
טריגר שמאלי | 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 Open Source בנושא חיישנים.
הטמעות במכשירים:
- [C-0-1] חובה לדווח במדויק על נוכחות או על היעדר של חיישנים בהתאם ל-class
android.content.pm.PackageManager
. - [C-0-2] חובה להחזיר רשימה מדויקת של חיישנים נתמכים באמצעות השיטה
SensorManager.getSensorList()
ושיטות דומות. - [C-0-3] חובה לפעול באופן סביר בכל ממשקי ה-API האחרים של החיישנים (לדוגמה, על ידי החזרת הערך
true
אוfalse
בהתאם כשאפליקציות מנסים לרשום מאזינים, לא להפעיל מאזינים של חיישנים כשהחיישנים המתאימים לא נמצאים וכו').
אם הטמעות במכשירים כוללות סוג חיישן מסוים שיש לו ממשק API תואם למפתחים של צד שלישי, הן:
- [C-1-1] חובה לדווח על כל מדידות החיישן באמצעות הערכים הרלוונטיים של המערכת הבינלאומית של יחידות (מטריות) לכל סוג חיישן, כפי שמוגדר במסמכי התיעוד של Android SDK.
- [C-1-2] חובה לדווח על נתוני חיישנים עם זמן אחזור מקסימלי של 100 אלפיות שנייה + 2 * sample_time במקרה של שידור חיישנים עם זמן אחזור מבוקש מקסימלי של 0 אלפיות שנייה כשמעבד האפליקציה פעיל. העיכוב הזה לא כולל עיכובים בסינון.
- [C-1-3] חובה לדווח על הדגימה הראשונה של החיישן תוך 400 אלפיות שנייה + 2 * sample_time מהפעלת החיישן. מותר לדגימה הזו להיות עם רמת דיוק של 0.
- [C-1-4] כל ממשק API שמסומן במסמכי התיעוד של Android SDK בתור חיישן רציף חייב לספק באופן קבוע דגימות נתונים תקופתיות, שצריך להיות להן רמת רעידות (jitter) נמוכה מ-3%. רעידות מוגדרות כסטיית התקן של ההבדל בין ערכי חותמות הזמן שדווחו בין אירועים רצופים.
- [C-1-5] חובה לוודא שזרם האירועים של החיישן לא ימנע ממעבד המכשיר לעבור למצב השהיה או להתעורר ממצב השהיה.
- [C-1-6] חובה לדווח על שעת האירוע בננו-שניות כפי שמוגדר במסמכי התיעוד של Android SDK, שמייצגת את השעה שבה האירוע התרחש ומתואמת עם השעון SystemClock.elapsedRealtimeNano().
- [C-SR-1] מומלץ מאוד שהשגיאה בסנכרון של חותמת הזמן תהיה פחות מ-100 אלפיות השנייה, ורצוי שהיא תהיה פחות מ-1 אלפית השנייה.
- כשמפעילים כמה חיישנים, צריכת החשמל לא אמורה לחרוג מסך צריכת החשמל שדווחה על ידי כל חיישן בנפרד.
הרשימה שלמעלה לא מקיפה. יש להתייחס להתנהגות המתועדת של Android SDK ולמסמכי התיעוד של Android Open Source בנושא חיישנים כמקור מידע מהימן.
אם הטמעות במכשירים כוללות סוג חיישן מסוים שיש לו ממשק API תואם למפתחים של צד שלישי, הן:
- [C-1-6] חובה להגדיר רזולוציה שאינה אפס לכל החיישנים ולדווח על הערך באמצעות שיטת ה-API
Sensor.getResolution()
.
יש סוגים של חיישנים שהם מורכבים, כלומר אפשר להסיק אותם מנתונים שמספקים חיישן אחד או יותר. (דוגמאות: חיישן הכיוון וחישן התאוצה הלינארית).
הטמעות במכשירים:
- מומלץ להטמיע את סוגי החיישנים האלה, אם הם כוללים את החיישנים הפיזיים הנדרשים כפי שמתואר בקטע סוגי חיישנים.
אם הטמעות במכשירים כוללות חיישן מורכב, הן:
- [C-2-1] חובה להטמיע את החיישן כפי שמתואר במסמכי התיעוד של Android Open Source בנושא חיישנים מורכבים.
אם הטמעות במכשירים כוללות סוג חיישן מסוים שיש לו ממשק API תואם למפתחים של צד שלישי, והחיישן מדווח רק על ערך אחד, הטמעות במכשירים:
- [C-3-1] חובה להגדיר את הרזולוציה ל-1 עבור החיישן ולדווח על הערך באמצעות שיטת ה-API
Sensor.getResolution()
.
אם הטמעות במכשיר כוללות סוג חיישן מסוים שתומך ב-SensorAdditionalInfo#TYPE_VEC3_CALIBRATION והחיישן חשוף למפתחים של צד שלישי, הם:
- [C-4-1] אסור לכלול בנתונים שסופקו פרמטרים קבועים של כיול שהוגדרו במפעל.
אם הטמעות במכשירים כוללות שילוב של מד תאוצה משולש-צירים, חיישן ג'ירוסקופ משולש-צירים או חיישן מגנטומטר, הן:
- [C-SR-2] מומלץ מאוד לוודא שלמד תאוצה, לג'ירוסקופ ולמגנטומטר יש מיקום יחסי קבוע, כך שאם המכשיר ניתן לשינוי (למשל, מתקפל), צירי החיישנים יישארו מותאמים ועקביים למערכת הקואורדינטות של החיישן בכל מצבי השינוי האפשריים של המכשיר.
7.3.1. מד תאוצה
הטמעות במכשירים:
- [C-SR-1] מומלץ מאוד לכלול מד תאוצה ב-3 צירים.
אם ההטמעות במכשירים כוללות תאוצה, הן:
- [C-1-1] חייב להיות מסוגל לדווח על אירועים בתדירות של לפחות 50Hz.
- [C-1-3] חייב להיות תואם למערכת הקואורדינטות של חיישן Android כפי שמפורט בממשקי ה-API של Android.
- [C-1-4] חייב להיות מסוגל למדוד מירידה חופשית עד פי ארבעה מכוח הכבידה(4g) או יותר בכל ציר.
- [C-1-5] חייבת להיות רזולוציה של לפחות 12 ביט.
- [C-1-6] סטיית התקן חייבת להיות לא יותר מ-0.05 m/s^, כאשר סטיית התקן צריכה להיות מחושבת על בסיס ציר לפי דגימות שנאספו במשך תקופה של לפחות 3 שניות בקצב הדגימה המהיר ביותר.
- צריך לדווח על אירועים עד 200Hz לפחות.
- צריכה להיות להם רזולוציה של 16 ביט לפחות.
- צריך לבצע כיול במהלך השימוש אם המאפיינים משתנים במהלך מחזור החיים ומבוצעת תיקון, ולשמור את פרמטרים התיקון בין הפעלות מחדש של המכשיר.
- צריך לבצע פיצוי טמפרטורה.
אם ההטמעות במכשירים כוללות מד תאוצה ב-3 צירים, הן:
- [C-2-1] חובה להטמיע חיישן
TYPE_ACCELEROMETER
ולדווח עליו. - [C-SR-4] מומלץ מאוד להטמיע את החיישן המשולב
TYPE_SIGNIFICANT_MOTION
. - [C-SR-5] מומלץ מאוד להטמיע ולדווח על חיישן
TYPE_ACCELEROMETER_UNCALIBRATED
. מומלץ מאוד שמכשירי Android יעמדו בדרישות האלה כדי שיוכלו לשדרג לגרסה העתידית של הפלטפורמה, שבה ייתכן שהדרישה הזו תהיה חובה. - מומלץ להטמיע את החיישנים המשולבים
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
ו-TYPE_STEP_COUNTER
כפי שמתואר במסמך Android SDK.
אם הטמעות במכשירים כוללות תאוצה עם פחות מ-3 צירים, הן:
- [C-3-1] חובה להטמיע חיישן
TYPE_ACCELEROMETER_LIMITED_AXES
ולדווח עליו. - [C-SR-6] מומלץ מאוד להטמיע את החיישן
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
ולדווח עליו.
אם הטמעות במכשיר כוללות תאוצה תלת-ציונית וכל אחד מהחיישנים המשולבים TYPE_SIGNIFICANT_MOTION
, TYPE_TILT_DETECTOR
, TYPE_STEP_DETECTOR
, TYPE_STEP_COUNTER
מוטמע:
- [C-4-1] הסכום של צריכת האנרגיה שלהם תמיד חייב להיות פחות מ-4mW.
- כל אחת מהן צריכה להיות מתחת ל-2mW ו-0.5mW כשהמכשיר נמצא במצב דינמי או סטטי.
אם הטמעות במכשירים כוללות מד תאוצה ב-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] חייב להיות מסוגל לדווח על אירועים בתדירות של לפחות 10Hz, ומומלץ לדווח על אירועים בתדירות של לפחות 50Hz.
- [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] צריך להיות צריכת אנרגיה של פחות מ-10mW.
- צריכת האנרגיה אמורה להיות פחות מ-3mW כשהחיישן רשום במצב באצ'ט ב-10Hz.
7.3.3. GPS
הטמעות במכשירים:
- [C-SR-1] מומלץ מאוד לכלול מקלט GPS/GNSS.
אם הטמעות במכשירים כוללות מקלט GPS/GNSS ומדווחות על היכולת לאפליקציות באמצעות דגל התכונה android.hardware.location.gps
, הן:
- [C-1-1] חובה לתמוך במיקומי פלט בקצב של לפחות 1Hz כשמבקשים דרך
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] חובה לעקוב בו-זמנית אחרי לפחות 8 לוויינים מקבוצת לוויינים אחת ולדווח עליהם באמצעות
GnssStatus.Callback
. - צריך להיות אפשרי לעקוב בו-זמנית אחרי לפחות 24 לוויינים, מכמה קבוצות של לוויינים (למשל, GPS + לפחות אחד מ-Glonass, Beidou, Galileo).
[C-SR-2] מומלץ מאוד להמשיך לספק פלט נתוני מיקום רגילים של GPS/GNSS דרך ממשקי ה-API של ספקי מיקום GNSS במהלך שיחת טלפון למקרה חירום.
[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 לכל הרץ (הפרש לכל הרץ, או rad^2 / s). ניתן לשנות את סטיית התקן בהתאם לשיעור הדגימה, אבל היא חייבת להיות מוגבלת בערך הזה. במילים אחרות, אם מודדים את השונות של הגירוסקופ בקצב דגימה של 1Hz, היא לא אמורה להיות גבוהה מ-1e-7 rad^2/s^2.
- [C-SR-2] מומלץ מאוד שהשגיאה בכיול תהיה פחות מ-0.01 rad/s כשהמכשיר נייח בטמפרטורת החדר.
- [C-SR-3] מומלץ מאוד להשתמש ברזולוציה של 16 ביט או יותר.
- צריך לדווח על אירועים עד 200Hz לפחות.
אם ההטמעות במכשירים כוללות ג'ירוסקופ ב-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
לחישן הטמפרטורה הסביבתית, והחיישן חייב למדוד את הטמפרטורה הסביבתית (החדר או תא הרכב) שממנה המשתמש מבצע אינטראקציה עם המכשיר, במדד צלזיוס.
אם הטמעות במכשירים כוללות חיישן מדחום שמודד טמפרטורה שונה מטמפרטורת הסביבה, כמו טמפרטורת המעבד, הן:
- [C-2-1] אסור להגדיר את
SENSOR_TYPE_AMBIENT_TEMPERATURE
לחיישן הטמפרטורה.
אם הטמעות המכשירים כוללות חיישן למעקב אחרי טמפרטורת העור, הן:
- [C-SR-1] מומלץ מאוד לתמוך בממשק ה-API PowerManager.getThermalHeadroom.
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] חובה לזהות את היכולת באמצעות ה-feature flag
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 הרץ ומעלה. מומלץ לתמוך ב-SensorDirectChannel
RATE_VERY_FAST
. - רעש המדידה חייב להיות לא יותר מ-400 μg/√Hz.
- חובה להטמיע את החיישן הזה בצורה ללא התעוררות עם יכולת אחסון ב-buffer של לפחות 3,000 אירועי חיישן.
- צריכת החשמל של האצווה חייבת להיות לא יותר מ-3mW.
- [C-SR-1] מומלץ מאוד שרוחב הפס למדידת 3dB יהיה לפחות 80% מתדירות Nyquist, וספקטרום של רעש לבן בתוך רוחב הפס הזה.
- צריך להיות תנועה אקראית של תאוצה קטנה מ-30 μg √Hz שנבדקה בטמפרטורת החדר.
- השינוי בסטייה לעומת הטמפרטורה צריך להיות ≤ +/- 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
ש:- טווח המדידה חייב להיות לפחות -1,000 עד +1,000 דפיקות לשנייה.
- חייבת להיות רזולוציית מדידה של לפחות 16 LSB/dps.
- תדר המדידה המינימלי חייב להיות 12.5Hz או פחות.
- חייבת להיות תדירות מדידה מקסימלית של 400 הרץ ומעלה. מומלץ לתמוך ב-SensorDirectChannel
RATE_VERY_FAST
. - רעש המדידה חייב להיות לא יותר מ-0.014°/s/√Hz.
- [C-SR-2] מומלץ מאוד שרוחב הפס למדידת 3dB יהיה לפחות 80% מתדירות Nyquist, וספקטרום של רעש לבן בתוך רוחב הפס הזה.
- צריך להיות תנועה אקראית של קצב קטן מ-0.001°/s √Hz שנבדקה בטמפרטורת החדר.
- השינוי בסטייה לעומת הטמפרטורה צריך להיות ≤ +/- 0.05 °/ s / °C.
- השינוי ברגישות כתוצאה מטמפרטורה צריך להיות ≤ 0.02% / °C.
- יש להיות קו בעל התאמה הטובה ביותר עם סטייה לא לינארית של ≤ 0.2%.
- צפיפות הרעש צריכה להיות ≤ 0.007 °/s/√Hz.
- שגיאת העיבוד צריכה להיות קטנה מ-0.002 rad/s בטווח הטמפרטורות 10 עד 40 מעלות צלזיוס כשהמכשיר נייח.
- רגישות ה-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 או פחות.
- תדירות המדידה המקסימלית חייבת להיות 50 הרץ ומעלה.
- רעש המדידה חייב להיות לא יותר מ-0.5 uT.
[C-2-6] חייב להיות
TYPE_MAGNETIC_FIELD_UNCALIBRATED
עם אותן דרישות איכות כמוTYPE_GEOMAGNETIC_FIELD
, ובנוסף:- חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון ב-buffer של לפחות 600 אירועי חיישן.
- [C-SR-3] מומלץ מאוד להשתמש בספקטרום של רעש לבן מ-1Hz ל-10Hz לפחות כשקצב הדיווח הוא 50Hz ומעלה.
[C-2-7] חייב להיות חיישן
TYPE_PRESSURE
ש:- טווח המדידה חייב להיות לפחות 300 עד 1,100 hPa.
- חייבת להיות רזולוציית מדידה של לפחות 80 LSB/hPa.
- תדר המדידה המינימלי חייב להיות 1Hz או פחות.
- תדירות המדידה המקסימלית חייבת להיות 10 הרץ ומעלה.
- רעש המדידה חייב להיות לא יותר מ-2 Pa/√Hz.
- חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון ב-buffer של לפחות 300 אירועי חיישן.
- צריכת החשמל של האצווה חייבת להיות לא יותר מ-2mW.
[C-2-8] חייב להיות חיישן
TYPE_GAME_ROTATION_VECTOR
.[C-2-9] חייב להיות חיישן
TYPE_SIGNIFICANT_MOTION
ש:- צריכת האנרגיה חייבת להיות לא יותר מ-0.5mW כשהמכשיר נייח, ו-1.5mW כשהמכשיר בתנועה.
[C-2-10] חייב להיות חיישן
TYPE_STEP_DETECTOR
ש:- חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון ב-buffer של לפחות 100 אירועי חיישן.
- צריכת האנרגיה חייבת להיות לא יותר מ-0.5mW כשהמכשיר נייח, ו-1.5mW כשהמכשיר בתנועה.
- צריכת החשמל של האצווה חייבת להיות לא יותר מ-4mW.
[C-2-11] חייב להיות חיישן
TYPE_STEP_COUNTER
ש:- צריכת האנרגיה חייבת להיות לא יותר מ-0.5mW כשהמכשיר נייח, ו-1.5mW כשהמכשיר בתנועה.
[C-2-12] חייב להיות חיישן
TILT_DETECTOR
ש:- צריכת האנרגיה חייבת להיות לא יותר מ-0.5mW כשהמכשיר נייח, ו-1.5mW כשהמכשיר בתנועה.
[C-2-13] חותמת הזמן של אותו אירוע פיזי שדווח על ידי ה-Accelerometer, ה-Gyroscope וה-Magnetometer חייבת להיות בטווח של 2.5 אלפיות השנייה זו מזו. חותמת הזמן של אותו אירוע פיזי שדווח על ידי ה-Accelerometer וה-Gyroscope אמורה להיות בטווח של 0.25 אלפיות השנייה אחת מהשנייה.
[C-2-14] חובה שתהיה חותמת זמן לאירועים של חיישן הגירוסקופ באותה בסיס זמן כמו למערכת המשנית של המצלמה, ובטווח שגיאה של מיליסיקון אחד.
[C-2-15] חובה לספק דגימות לאפליקציות תוך 5 אלפיות השנייה ממועד זמינות הנתונים באפליקציה דרך אחד מהחיישנים הפיזיים שלמעלה.
[C-2-16] צריך להיות צריכת אנרגיה של פחות מ-0.5mW כשהמכשיר נייח ו-2.0mW כשהמכשיר בתנועה, כשכל שילוב של החיישנים הבאים מופעל:
SENSOR_TYPE_SIGNIFICANT_MOTION
SENSOR_TYPE_STEP_DETECTOR
SENSOR_TYPE_STEP_COUNTER
SENSOR_TILT_DETECTORS
[C-2-17] יכול להיות חיישן
TYPE_PROXIMITY
, אבל אם הוא קיים, חייבת להיות לו יכולת מאגר נתונים זמנית (buffer) של 100 אירועי חיישן לפחות.
חשוב לדעת שכל הדרישות לגבי צריכת החשמל בקטע הזה לא כוללות את צריכת החשמל של מעבד האפליקציות. הוא כולל את כל צריכת החשמל של שרשרת החיישנים כולה – החיישן, כל מעגל התמיכה, כל מערכת עיבוד נתונים ייעודית של חיישנים וכו'.
אם הטמעות המכשירים כוללות תמיכה ישירה בחיישנים, הן:
- [C-3-1] חובה להצהיר בצורה נכונה על תמיכה בסוגים של ערוצי דיווח ישיר ועל רמת הדיווחים הישירה באמצעות ממשקי ה-API
isDirectChannelTypeSupported
ו-getHighestDirectReportRateLevel
. - [C-3-2] חייבת להיות תמיכה לפחות באחד משני סוגי הערוצים הישירים של החיישן לכל החיישנים שמצהירים על תמיכה בערוץ ישיר של חיישן.
- צריך לתמוך בדיווח על אירועים דרך ערוץ ישיר של חיישן עבור חיישן ראשי (לא וריאנט של התעוררות) מהסוגים הבאים:
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
7.3.10. חיישנים ביומטריים
מידע נוסף על מדידת האבטחה של ביטול הנעילה הביומטרי זמין במאמר המסמכים בנושא מדידת האבטחה הביומטרית.
אם הטמעות במכשירים כוללות מסך נעילה מאובטח, הן:
- צריך לכלול חיישן ביומטרי
חיישנים ביומטריים יכולים להיות מסווגים כרמה 3 (לשעבר חזק), רמה 2 (לשעבר חלש) או רמה 1 (לשעבר נוחות) על סמך שיעורי הקבלה שלהם לזיוף ולהתחזות, ועל סמך האבטחה של צינור עיבוד הנתונים הביומטרי. הסיווג הזה קובע את היכולות של החיישן הביומטרי ליצירת ממשק עם הפלטפורמה ועם אפליקציות של צד שלישי. חיישנים צריכים לעמוד בדרישות נוספות שמפורטות בהמשך כדי לקבל סיווג של Class 1, Class 2 או Class 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] חובה לזהות ולכבד כל שם פרמטר שמוגדר כקבוע במחלקה Authenticators וכל שילוב שלהם. לעומת זאת, אסור להכיר או לכבד קבועים שלמים שמועברים לשיטות canAuthenticate(int) ו-setAllowedAuthenticators(int) מלבד אלה שמתועדים כקבועים ציבוריים ב-Authenticators וכל שילוב שלהם.
- [C-4-3] חובה להטמיע את הפעולה ACTION_BIOMETRIC_ENROLL במכשירים עם מידע ביומטרי מסוג Class 3 או Class 2. הפעולה הזו חייבת להציג רק את נקודות הכניסה להרשמה לזיהוי ביומטרי מסוג Class 3 או Class 2.
אם הטמעות במכשירים תומכות בביומטריה פסיבית, הן:
- [C-5-1] חובה לדרוש כברירת מחדל שלב אישור נוסף (למשל, לחיצה על לחצן).
- [C-SR-1] מומלץ מאוד להגדיר אפשרות שמאפשרת למשתמשים לשנות את ההעדפות של האפליקציה, ותמיד לדרוש שלב אישור.
- [C-SR-2] מומלץ מאוד לאבטח את פעולת האישור כך שלא ניתן יהיה לזייף אותה כתוצאה מפריצה למערכת ההפעלה או לליבה. לדוגמה, המשמעות היא שפעולת האישור שמבוססת על לחצן פיזי מנותבת דרך פין קלט/פלט (GPIO) למטרות כלליות (I/O) של רכיב מאובטח (SE) שלא ניתן להפעיל באמצעים אחרים מלבד לחיצה על לחצן פיזי.
- [C-5-2] חובה להטמיע בנוסף תהליך אימות משתמע (ללא שלב אישור) שתואם ל-setConfirmationRequired(boolean), שאפשר להגדיר באפליקציות כדי להשתמש בו בתהליכי כניסה.
אם יש במכשירים כמה חיישנים ביומטריים, הם:
יצירת דרישות חדשות
[C-7-1] חובה, כשמידע ביומטרי נעול (כלומר המידע הביומטרי מושבת עד שהמשתמש מבטל את הנעילה באמצעות אימות ראשי) או נעול לזמן מוגבל (כלומר המידע הביומטרי מושבת באופן זמני עד שהמשתמש ממתין לפרק זמן מסוים) בגלל יותר מדי ניסיונות כושלים, לנעול גם את כל המידע הביומטרי האחר ברמה ביומטרית נמוכה יותר. במקרה של נעילה זמנית, משך ההשהיה לאימות ביומטרי חייב להיות משך ההשהיה המקסימלי של כל הנתונים הביומטריים בנעילה זמנית.
[C-SR-12] מומלץ מאוד, במקרה של נעילה של מידע ביומטרי (כלומר, המידע הביומטרי מושבת עד שהמשתמש מבטל את הנעילה באמצעות אימות ראשי) או נעילה מוגבלת בזמן (כלומר, המידע הביומטרי מושבת באופן זמני עד שהמשתמש ממתין לפרק זמן מסוים) עקב יותר מדי ניסיונות כושלים, לנעול גם את כל שאר המידע הביומטרי מאותה סוג ביומטרי. במקרה של נעילת חשבון לטווח זמן מוגדר, מומלץ מאוד שהזמן להשהיה לפני ניסיון חוזר לאימות ביומטרי יהיה זמן ההשהיה המקסימלי של כל אמצעי האימות הביומטרי בנעילת חשבון לטווח זמן מוגדר.
[C-7-2] חובה לאתגר את המשתמש לאימות ראשי מומלץ (למשל: קוד אימות, דפוס, סיסמה) כדי לאפס את מונה הנעילה של נתונים ביומטריים שננעלו. יכול להיות שנתונים ביומטריים ברמה 3 יורשו לאפס את מונה החסימה של נתונים ביומטריים נעולים באותה רמה או ברמה נמוכה יותר. אסור לאפשר למידע ביומטרי ברמה 2 או ברמה 1 להשלים פעולת איפוס של נעילת אמצעי אימות ביומטרי.
סיום הדרישות החדשות
- [C-SR-3] מומלץ מאוד לדרוש אישור של רק מאפיין ביומטרי אחד לכל אימות (למשל, אם חיישני טביעות האצבע וזיהוי הפנים זמינים במכשיר, צריך לשלוח את onAuthenticationSucceeded אחרי אישור של אחד מהם).
כדי שהטמעות במכשירים יאפשרו לאפליקציות של צד שלישי לגשת למפתחות של מאגר המפתחות, הן צריכות:
- [C-6-1] חייב לעמוד בדרישות של Class 3 כפי שמוגדרות בקטע הזה בהמשך.
- [C-6-2] חובה להציג רק מידע ביומטרי מסוג Class 3 כשהאימות מחייב BIOMETRIC_STRONG, או כשהאימות מופעל באמצעות CryptoObject.
אם רוצים להתייחס לחיישן ביומטרי כסוג 1 (לשעבר נוחות) בהטמעות של המכשיר, צריך:
- [C-1-1] שיעור האישור השגוי חייב להיות קטן מ-0.002%.
- [C-1-2] חובה לציין שהמצב הזה עשוי להיות פחות מאובטח מקוד אימות, מקו ביטול נעילה או מסיסמה חזקה, ולפרט בבירור את הסיכונים שבהפעלה שלו, אם שיעורי הקבלה של התחזות וזיופים גבוהים מ-7%, כפי שנמדד לפי פרוטוקולי הבדיקה של Android Biometrics.
- [C-1-9] חובה לבקש מהמשתמש לבצע את האימות הראשי המומלץ (למשל, קוד אימות, דפוס, סיסמה) אחרי לא יותר מ-20 ניסיונות כושלים ולא פחות מ-90 שניות של זמן המתנה לאימות ביומטרי – כאשר ניסיון כוש הוא ניסיון באיכות צילום מספקת (BIOMETRIC_ACQUIRED_GOOD) שלא תואם למידע הביומטרי הרשום.
- [C-SR-4] מומלץ מאוד להקטין את המספר הכולל של ניסיונות כוזבים לאימות ביומטרי שצוין בקטע [C-1-9] אם שיעורי הקבלה של התחזות וזיופים גבוהים מ-7%, כפי שנמדד לפי פרוטוקולי הבדיקה של Android Biometrics.
- [C-1-3] חובה להגביל את מספר הניסיונות לאימות ביומטרי – ניסיון שקרי הוא ניסיון באיכות צילום מספקת (
BIOMETRIC_ACQUIRED_GOOD
) שלא תואם לנתונים הביומטריים הרשומים. - [C-SR-5] מומלץ מאוד להגביל את מספר הניסיונות ל-30 שניות לפחות אחרי 5 ניסיונות כושלים לאימות ביומטרי, עד למספר המקסימלי של ניסיונות כושלים לכל [C-1-9] – כאשר ניסיון כושל הוא ניסיון באיכות צילום מספקת (BIOMETRIC_ACQUIRED_GOOD) שלא תואם לנתונים הביומטריים הרשומים.
- [C-SR-6] מומלץ מאוד להעביר את כל הלוגיקה של הגבלת הקצב ל-TEE.
[C-1-10] חובה להשבית את האימות הביומטרי אחרי שההשהיה של האימות הראשי מופעלת בפעם הראשונה, כפי שמתואר בקטע [C-0-2] בקטע 9.11.
[C-1-11] חובה ששיעור הקבלה של התחזות וזיופים לא יעלה על 30%, כאשר (1) שיעור הקבלה של התחזות וזיופים של כלי התקפת הצגה (PAI) ברמה A לא יעלה על 30%, ו-(2) שיעור הקבלה של התחזות וזיופים של כלי PAI ברמה B לא יעלה על 40%, כפי שנמדד לפי פרוטוקולי הבדיקה של Android Biometrics.
[C-1-4] חובה למנוע הוספה של מידע ביומטרי חדש בלי ליצור קודם שרשרת אמון, על ידי כך שהמשתמש יאשר פרטי כניסה קיימים או יוסיף פרטי כניסה חדשים למכשיר (קוד אימות/דפוס/סיסמה) שמאובטחים על ידי TEE. ההטמעה של Android Open Source Project מספקת את המנגנון במסגרת כדי לעשות זאת.
[C-1-5] חובה להסיר לחלוטין את כל הנתונים הביומטריים המזהים של משתמש כשהחשבון שלו מוסר (כולל באמצעות איפוס להגדרות המקוריות).
[C-1-6] חובה לכבד את הדגל הספציפי של המידע הביומטרי הזה (כלומר
DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
,DevicePolicymanager.KEYGUARD_DISABLE_FACE
אוDevicePolicymanager.KEYGUARD_DISABLE_IRIS
).[C-1-7] חובה לאתגר את המשתמש לבצע את האימות הראשי המומלץ (למשל, קוד אימות, קו ביטול נעילה, סיסמה) פעם ב-24 שעות או פחות. הערה: במכשירים ששודרגו מגרסה 9 ואילך של Android, חובה לבקש מהמשתמש להזין את פרטי האימות הראשי המומלצים (למשל, קוד אימות, קו ביטול נעילה או סיסמה) פעם ב-72 שעות או פחות.
[C-1-8] חובה לבקש מהמשתמש לבצע את האימות הראשי המומלץ (למשל: קוד אימות, קו ביטול נעילה, סיסמה) או אימות ביומטרי מסוג 3 (חזק) לאחר אחד מהאירועים הבאים:
- זמן קצוב לתפוגה של 4 שעות לפעילות לא פעילה, או
- 3 ניסיונות כושלים לביצוע אימות ביומטרי.
- פרק הזמן של הזמן הקצוב לפעילות וספירת ניסיונות האימות שנכשלו מתאפסים אחרי אישור מוצלח של פרטי הכניסה של המכשיר. הערה: יכול להיות שמכשירים ששודרגו מגרסה 9 ואילך של Android יהיו פטורים מ-C-1-8.
[C-SR-7] מומלץ מאוד להשתמש בלוגיקה של המסגרת שסופקו על ידי Android Open Source Project כדי לאכוף את האילוצים שצוינו ב-[C-1-7] וב-[C-1-8] במכשירים חדשים.
[C-SR-8] מומלץ מאוד שהשיעור של דחייה שגויה יהיה קטן מ-10%, כפי שנמדד במכשיר.
[C-SR-9] מומלץ מאוד שהזמן עד לתגובה (latency) יהיה פחות משנייה, נמדד מהרגע שבו מתבצע זיהוי הביומטרי ועד שהמסך נפתח, לכל שיטה ביומטרית רשומה.
יצירת דרישות חדשות
[C-1-12] חובה ששיעור הקבלה של זיוף ותחזות לא יעלה על 40% לכל סוג של כלי התקפת הצגה (PAI), כפי שנמדד לפי פרוטוקולים של בדיקות ביומטריה ל-Android.
[C-SR-13] מומלץ מאוד שהשיעור של אישור זיוף וזיופים לא יהיה גבוה מ-30% לכל סוג של כלי התקפת הצגה (PAI), כפי שנמדד לפי פרוטוקולי הבדיקה של Android Biometrics.
[C-SR-14] מומלץ מאוד לחשוף את הסיווג הביומטרי של החיישן הביומטרי ואת הסיכונים המתאימים להפעלה שלו.
[C-SR-17] מומלץ מאוד להטמיע את ממשקי ה-AIDL החדשים (כמו
IFace.aidl
ו-IFingerprint.aidl
).
סיום הדרישות החדשות
אם רוצים להתייחס לחיישן ביומטרי כסוג 2 (לשעבר חלש) בהטמעות במכשירים, צריך:
[C-2-1] חובה לעמוד בכל הדרישות של סיווג 1 שמפורטות למעלה.
[C-2-2] חובה ששיעור הקבלה של התחזות וזיופים לא יעלה על 20%, כאשר (1) שיעור הקבלה של התחזות וזיופים של כלי התקפה מסוג 'הצגה' (PAI) ברמה A לא יעלה על 20%, ו-(2) שיעור הקבלה של התחזות וזיופים של כלי התקפה מסוג PAI ברמה B לא יעלה על 30%, כפי שנמדד לפי פרוטוקולי הבדיקה של Android Biometrics.
יצירת דרישות חדשות
- [C-SR-15] מומלץ מאוד שהשיעור של אישור זיופים ותרמיות לא יהיה גבוה מ-20% לכל סוג של כלי התקפת הצגה (PAI), כפי שנמדד לפי פרוטוקולי הבדיקה של Android Biometrics.
סיום הדרישות החדשות
- [C-2-3] חובה לבצע את ההתאמה הביומטרית בסביבת מחשוב מבודדת מחוץ למרחב המשתמש או הליבה של Android, כמו סביבת מחשוב אמינה (TEE),
אובשבב עם ערוץ מאובטח לסביבת המחשוב המבודדת או במכונה וירטואלית מוגנת שעומדת בדרישות שמפורטות בקטע 9.17. - [C-2-4] חובה להצפין את כל הנתונים המזהים ולאמת אותם באופן קריפטוגרפי, כך שלא ניתן יהיה לקבל אותם, לקרוא אותם או לשנות אותם מחוץ לסביבת הביצועים המבודדת, או להשתמש בשבב עם ערוץ מאובטח לסביבת הביצועים המבודדת, כפי שמתואר בהנחיות להטמעה באתר של Android Open Source Project, או במכונה וירטואלית מוגנת שבשליטת hypervisor שעומדת בדרישות שמפורטות בקטע 9.17.
- [C-2-5] לזיהוי ביומטרי שמבוסס על מצלמה, בזמן שמתבצע אימות או הרשמה מבוססי ביומטריה:
- חובה להפעיל את המצלמה במצב שמונע קריאה או שינוי של הפריימים של המצלמה מחוץ לסביבת הביצועים המבודדת, או שבמכשיר יש צ'יפ עם ערוץ מאובטח לסביבת הביצועים המבודדת או מכונה וירטואלית מוגנת שבשליטת hypervisor שעומדת בדרישות שמפורטות בקטע 9.17.
- בפתרונות עם מצלמת RGB אחת, אפשר לקרוא את הפריימים של המצלמה מחוץ לסביבת הביצועים המבודדת כדי לתמוך בפעולות כמו תצוגה מקדימה לצורך הרשמה, אבל עדיין אסור לשנות אותם.
- [C-2-6] אסור לאפשר לאפליקציות של צד שלישי להבדיל בין הרשמות ביומטריות ספציפיות.
- [C-2-7] אסור לאפשר גישה ללא הצפנה לנתונים ביומטריים מזהים או לכל נתון שמבוסס עליהם (כמו הטמעות) למעבד האפליקציות מחוץ להקשר של TEE או של המכונה הווירטואלית המוגנת שבשליטת hypervisor שעומדת בדרישות שמפורטות בסעיף 9.17. מכשירים ששודרגו מגרסה 9 ואילך של Android לא פטורים מ-C-2-7.
[C-2-8] חייב להיות צינור עיבוד נתונים מאובטח, כך שפגיעה במערכת ההפעלה או בליבה לא תאפשר להחדיר נתונים ישירות כדי לבצע אימות כוזב של המשתמש. הערה: אם הטמעות של מכשירים כבר הושקו ב-Android בגרסה 9 ואילך, ולא ניתן לעמוד בדרישות של C-2-8 באמצעות עדכון של תוכנת המערכת, יכול להיות שהן יקבלו פטור מהדרישה.
[C-SR-10] מומלץ מאוד לכלול זיהוי חיים בכל שיטות הזיהוי הביומטרי וזיהוי תשומת לב לזיהוי ביומטרי של פנים.
[C-2-9] חובה להפוך את החיישן הביומטרי לזמין לאפליקציות של צד שלישי.
אם רוצים להתייחס לחישן ביומטרי כסוג 3 (לשעבר חזק) בהטמעות של המכשיר, צריך:
- [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 Biometrics.
- [C-3-4] חובה לאתגר את המשתמש לבצע את האימות הראשי המומלץ (למשל, קוד אימות, קו ביטול נעילה, סיסמה) פעם ב-72 שעות או פחות.
- [C-3-5] חובה ליצור מחדש את מזהה המאמת לכל אמצעי אימות ביומטרי מסוג 3 שנתמכים במכשיר, אם אחד מהם נרשם מחדש.
- [C-3-6] חובה להפעיל מפתחות של מאגר מפתחות שמגובים בביומטריה לאפליקציות של צד שלישי.
יצירת דרישות חדשות
- [C-SR-16] מומלץ מאוד שהשיעור של אישור זיוף וזיופים לא יהיה גבוה מ-7% לכל סוג של כלי להתקפת הצגה (PAI), כפי שנמדד לפי פרוטוקולי הבדיקה של Android Biometrics.
סיום הדרישות החדשות
אם הטמעות במכשירים מכילות חיישן טביעות אצבע שמתחת למסך (UDFPS), הן:
- [C-SR-11] מומלץ מאוד למנוע מהאזור הניתן למגע של UDFPS להפריע לניווט באמצעות 3 לחצנים (שחלק מהמשתמשים עשויים להזדקק לו למטרות נגישות).
7.3.11. חיישן תנוחה
הטמעות במכשירים:
- יכול להיות שתהיה תמיכה בחיישן תנוחה עם 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
: מדידת טווח של unicastSTATIC STS DS-TWR
שהוגדרה על ידי 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
).
כדי לוודא ש-802.1.15.4 פועל כמו שצריך, צריך לעבור את בדיקות התאימות והאישור הרלוונטיות שמוגדרות על ידי ארגוני התקנים, כולל FIRA, CCC ו-CSA.
סיום הדרישות החדשות
7.4. קישוריות נתונים
7.4.1. טלפוניה
המונח 'טלפוניה', כפי שהוא מופיע בממשקי ה-API של Android ובמסמך הזה, מתייחס באופן ספציפי לחומרה שקשורה לביצוע שיחות קוליות ושליחת הודעות SMS , או ליצירת חיבור לאינטרנט בנייד באמצעות רשת סלולרית (למשל GSM, CDMA, LTE, NR) GSM או CDMA. במכשיר שתומך ב'טלפוניה' יכול להיות שיוצעו חלק משירותי השיחות, ההודעות והנתונים או כולם, בהתאם למוצר.
דרך רשת GSM או CDMA. יכול להיות שהשיחות הקוליות האלה יתבצעו באמצעות מעבר חבילות (packet-switched) או לא,אבל לצורכי Android הן נחשבות כבלתי תלויות בחיבור נתונים שעשוי להיות מיושם באמצעות אותה רשת. במילים אחרות,הפונקציונליות והממשקים של 'טלפוניה' ב-Android מתייחסים באופן ספציפי לשיחות קוליות ולהודעות SMS. לדוגמה, הטמעות של מכשירים שלא ניתן לבצע בהן שיחות או לשלוח/לקבל הודעות SMS לא נחשבות למכשירי טלפוניה, גם אם הן משתמשות ברשת סלולרית לחיבור נתונים.
- אפשר להשתמש ב-Android במכשירים שלא כוללים חומרה של טלפוניה. כלומר, Android תואם למכשירים שאינם טלפונים.
אם הטמעות המכשירים כוללות טלפון GSM או CDMA, הן:
- [C-1-1] חובה להצהיר על ה-feature flag
android.hardware.telephony
ועל סמנים אחרים של תכונות משנה בהתאם לטכנולוגיה. - [C-1-2] חובה להטמיע תמיכה מלאה ב-API של הטכנולוגיה הזו.
- צריך לאפשר את כל סוגי השירות הסלולרי הזמינים (2G, 3G, 4G, 5G וכו') במהלך שיחות חירום (ללא קשר לסוגים של הרשתות שמוגדרים על ידי
SetAllowedNetworkTypeBitmap()
).
אם הטמעות במכשירים לא כוללות חומרה של טלפוניה, הן:
- [C-2-1] חובה להטמיע את ממשקי ה-API המלאים כ-no-ops.
אם הטמעות במכשירים תומכות ב-eUICC או ב-eSIM/SIM מוטמע, וכוללות מנגנון קנייני שמאפשר למפתחים של צד שלישי להשתמש בפונקציות של eSIM, הן:
- [C-3-1] חובה להצהיר על ה-feature flag
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, אינדיקציות ייעודיות לשולח באמצעות HAL של IRadio 1.6, והקצאה באמצעות Auto Configuration Server (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
חייבת להשתמש בממשקי ה-API של SmsManager כששולחים ומקבלים הודעות SMS ו-MMS. ההטמעה של AOSP במארזים/באפליקציות/ב-Messaging עומדת בדרישות האלה. - [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 עם group UUID שאינו null וbit אופורטוניסטי בכל אמצעי גישה שגלוי למשתמשים ומאפשר הגדרה או שליטה בהגדרות של כרטיס ה-SIM.
אם הטמעות המכשיר מדווחות על התכונה android.hardware.telephony
ומציגות סרגל סטטוס של המערכת, אז:
- [C-7-1] חובה לבחור מינוי פעיל מייצג לgroup UUID נתון כדי להציג למשתמש בכל אמצעי העזרה שמספקים מידע על סטטוס ה-SIM. דוגמאות לאפשרויות כאלה הן סמל האות הסלולרי בסרגל הסטטוס או המשבצת של ההגדרות המהירות.
- [C-SR-1] מומלץ מאוד לבחור את המינוי שמייצג בתור המינוי הפעיל לנתונים, אלא אם המכשיר נמצא בשיחה קולית, שבמהלכה מומלץ מאוד לבחור את המינוי הפעיל לשיחות קוליות בתור המינוי שמייצג.
אם הטמעות במכשירים מדווחות על התכונה 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] חובה להצהיר על ה-feature flag
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] חובה לחסום את כל השיחות וההודעות ממספר טלפון ב-'BlockedNumberProvider' ללא אינטראקציה עם אפליקציות. היוצא מן הכלל היחיד הוא כשהחסימת מספרים מוסרת באופן זמני, כפי שמתואר במסמכי התיעוד של ה-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. Telecom API
אם הטמעות של מכשירים מדווחות על 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
של אוזניות האודיו עבור ממשקי ה-API שלandroid.telecom
באופן הבא:- קריאה למספר
Connection.onDisconnect()
כשזוהתה לחיצה קצרה על האירוע המרכזי במהלך שיחה פעילה. - קריאה ל-
Connection.onAnswer()
כשמתגלה הקשה קצרה על האירוע המרכזי במהלך שיחה נכנסת. - קריאה לפונקציה
Connection.onReject()
כשזוהתה לחיצה ממושכת על האירוע המרכזי במהלך שיחה נכנסת. - משנים את סטטוס ההשתקה של
CallAudioState
.
- קריאה למספר
7.4.1.3. העברת הודעות Keepalive של NAT-T לנייד
הטמעות במכשירים:
- צריכה לכלול תמיכה בהעברת נתונים (offload) של keepalive לרשת הסלולרית.
אם הטמעות במכשירים כוללות תמיכה בהעברת עומס של keepalive לרשת הסלולרית ומציגות את הפונקציונליות לאפליקציות של צד שלישי, הן:
- [C-1-1] חובה לתמוך ב-SocketKeepAlive API.
- [C-1-2] חובה לתמוך בחריץ אחד לפחות של keepalive בו-זמנית דרך רשת סלולרית.
- [C-1-3] חובה לתמוך במספר הסלוטים של keepalive הסלולריים בו-זמנית שנתמכים על ידי HAL של הרדיו הסלולרי.
- [C-SR-1] מומלץ מאוד לתמוך בלפחות שלושה משבצות של keepalive סלולרי לכל מכשיר רדיו.
אם הטמעות המכשירים לא כוללות תמיכה בהעברת עומס של keepalive הסלולר, הן:
- [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 Television, גם במצבי המתנה. - [C-1-5] אסור להתייחס לקריאה ל-method של ה-API
WifiManager.enableNetwork()
כסימן מספיק כדי להחליף את ה-Network
הפעיל כרגע, שמשמש כברירת מחדל לתנועת האפליקציה ומוחזר על ידי methods של ה-APIConnectivityManager
כמוgetActiveNetwork
ו-registerDefaultNetworkCallback
. במילים אחרות, הם עשויים להשבית את הגישה לאינטרנט שמספקת כל ספק רשת אחר (למשל, חבילת גלישה) רק אם הם מצליחים לאמת שרשת ה-Wi-Fi מספקת גישה לאינטרנט. - [C-1-6] מומלץ מאוד, כשמתבצעת קריאה לשיטת ה-API
ConnectivityManager.reportNetworkConnectivity()
, לבדוק מחדש את הגישה לאינטרנט ב-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 אקראי לכל נקודת גישה שיוצרים.
- כתובת ה-MAC חייבת להיות אקראית וקבועה לכל SSID שבו משתמש ה-AP.
- יכול להיות שהמכשיר יספק למשתמש אפשרות להשבית את התכונה הזו. אם האפשרות הזו קיימת, הרשאה אקראית חייבת להיות מופעלת כברירת מחדל.
אם הטמעות המכשירים כוללות תמיכה במצב חיסכון בחשמל של Wi-Fi כפי שמוגדר בתקן IEEE 802.11, הן:
- צריך להשבית את מצב חיסכון האנרגיה ב-Wi-Fi בכל פעם שאפליקציה מקבלת את המנעול
WIFI_MODE_FULL_HIGH_PERF
או את המנעולWIFI_MODE_FULL_LOW_LATENCY
דרך ממשקי ה-API שלWifiManager.createWifiLock()
ו-WifiManager.WifiLock.acquire()
, והנעילה פעילה. - [C-3-2] זמן האחזור הממוצע הלוך ושוב בין המכשיר לנקודת הגישה כשהמכשיר נמצא במצב Wi-Fi Low Latency Lock (
WIFI_MODE_FULL_LOW_LATENCY
) חייב להיות קצר יותר מזמן האחזור במצב Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF
). - [C-SR-3] מומלץ מאוד לצמצם את זמן האחזור הלוך ושוב ב-Wi-Fi בכל פעם שמתבצע נעילה עם זמן אחזור קצר (
WIFI_MODE_FULL_LOW_LATENCY
) והיא נכנסת לתוקף.
אם הטמעות במכשירים תומכות ב-Wi-Fi ומשתמשות ב-Wi-Fi לסריקה של מיקום, הן:
- [C-2-1] חובה לספק למשתמש אפשרות להפעיל או להשבית את קריאת הערך באמצעות שיטת ה-API
WifiManager.isScanAlwaysAvailable
.
7.4.2.1. Wi-Fi ישיר
הטמעות במכשירים:
- צריכה לכלול תמיכה ב-Wi-Fi Direct (Wi-Fi מקצה לקצה).
אם הטמעות המכשירים כוללות תמיכה ב-Wi-Fi Direct, הן:
- [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 Direct.
- [C-SR-1] מומלץ מאוד ליצור כתובת MAC אקראית של המקור לכל החיבורים החדשים שנוצרים ב-Wi-Fi Direct.
7.4.2.2. הגדרת קישור ישיר ב-Wi-Fi דרך מנהרה
הטמעות במכשירים:
- צריכה לכלול תמיכה ב-Wi-Fi Tunneled Direct Link Setup (TDLS) כפי שמתואר במסמכי התיעוד של Android SDK.
אם הטמעות המכשירים כוללות תמיכה ב-TDLS ו-TDLS מופעל על ידי WiFiManager API, הן:
- [C-1-1] חובה להצהיר על תמיכה ב-TDLS דרך
WifiManager.isTdlsSupported
. - מומלץ להשתמש ב-TDLS רק כשהדבר אפשרי ומועיל.
- צריך להיות שימוש בהיגוריית כלשהי ולא להשתמש ב-TDLS כשהביצועים שלו עשויים להיות גרועים יותר מאשר דרך נקודת הגישה ל-Wi-Fi.
7.4.2.3. Wi-Fi Aware
הטמעות במכשירים:
- צריכה לכלול תמיכה ב-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 Aware במרווחי זמן של עד 30 דקות ובכל פעם ש-Wi-Fi Aware מופעל, אלא אם מתבצעת פעולת טווח של Aware או שנתיב הנתונים של Aware פעיל (לא צפויה רנדומיזציה כל עוד נתיב הנתונים פעיל).
אם הטמעות במכשירים כוללות תמיכה ב-Wi-Fi Aware וב-Wi-Fi Location כפי שמתואר בקטע 7.4.2.5, ומאפשרות גישה לפונקציונליות הזו לאפליקציות של צד שלישי, הן:
- [C-2-1] חובה להטמיע את ממשקי ה-API לחיפוש מבוסס-מיקום: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm ו-onServiceDiscoveredWithinRange.
7.4.2.4. Wi-Fi Passpoint
אם הטמעות המכשירים כוללות תמיכה ב-802.11 (Wi-Fi), הן:
- [C-1-1] חובה לכלול תמיכה ב-Wi-Fi Passpoint.
- [C-1-2] חובה להטמיע את ממשקי ה-API של
WifiManager
שקשורים ל-Passpoint כפי שמתואר במסמכי התיעוד של ה-SDK. - [C-1-3] חובה לתמוך בתקן IEEE 802.11u, שקשור במיוחד לגילוי ולבחירה של רשתות, כמו שירות המודעות הגנריות (GAS) ופרוטוקול השאילתות של רשת הגישה (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 כפי שמתואר במפרט Hotspot 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 לא משויך לנקודת גישה.
- [C-1-4] חייב להיות מדויק בטווח של 2 מטרים ברוחב פס של 80MHz ב-68% העליון (כפי שמחושב באמצעות פונקציית ההתפלגות המצטברת).
- [C-SR-1] מומלץ מאוד לדווח על כך בצורה מדויקת בטווח של 1.5 מטר, ברוחב פס של 80MHz באחוזון ה-68 (כפי שמחושב באמצעות פונקציית ההתפלגות המצטברת).
7.4.2.6. העברת נתוני Wi-Fi Keepalive
הטמעות במכשירים:
- צריכה לכלול תמיכה בהעברת עומס של keepalive ב-Wi-Fi.
אם הטמעות במכשירים כוללות תמיכה בהעברת עומס של keepalive ב-Wi-Fi ומציגות את הפונקציונליות לאפליקציות של צד שלישי, הן:
- [C-1-1] חובה לתמוך ב-API של SocketKeepAlive.
- [C-1-2] חובה לתמוך ב-3 משבצות keepalive בו-זמנית לפחות דרך Wi-Fi
אם הטמעות המכשירים לא כוללות תמיכה בהעברת עומס של keepalive ב-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] השיטה WifiManager#isEasyConnectSupported() חייבת להחזיר את הערך
true
.
7.4.2.8. אימות אישור שרת Wi-Fi לארגון
אם אישור השרת של Wi-Fi לא מאומת או ששם הדומיין של שרת ה-Wi-Fi לא מוגדר, הטמעות המכשיר:
- [C-SR-1] מומלץ מאוד לא לספק למשתמש אפשרות להוסיף באופן ידני רשת Wi-Fi ארגונית באפליקציית ההגדרות.
7.4.2.9. סימון כרשת מהימנה בשימוש הראשון (TOFU)
אם הטמעות במכשירים תומכות ב-Trust on first usage (TOFU) ומאפשרות למשתמש להגדיר הגדרות של WPA/WPA2/WPA3-Enterprise, הן:
- [C-4-1] חובה לספק למשתמש אפשרות לבחור בשימוש ב-TOFU.
7.4.3. Bluetooth
אם הטמעות המכשירים תומכות בפרופיל האודיו של Bluetooth, הן:
- צריכה להיות תמיכה בקודקי אודיו מתקדמים ובקודקי אודיו ל-Bluetooth (למשל LDAC)
אם הטמעות המכשירים תומכות ב-HFP, ב-A2DP וב-AVRCP, הן:
- צריך לתמוך ב-5 מכשירים מחוברים לפחות.
אם הטמעות במכשירים מכריזות על התכונה android.hardware.vr.high_performance
, הן:
- [C-1-1] חובה לתמוך ב-Bluetooth 4.2 וב-Bluetooth LE Data Length Extension.
ב-Android יש תמיכה ב-Bluetooth וב-Bluetooth עם צריכת אנרגיה נמוכה.
אם הטמעות במכשירים כוללות תמיכה ב-Bluetooth וב-Bluetooth Low Energy, הן:
- [C-2-1] חובה להצהיר על תכונות הפלטפורמה הרלוונטיות (
android.hardware.bluetooth
ו-android.hardware.bluetooth_le
, בהתאמה) ולהטמיע את ממשקי ה-API של הפלטפורמה. - צריך להטמיע פרופילים רלוונטיים של Bluetooth, כמו A2DP, AVRCP, OBEX, HFP וכו', בהתאם למכשיר.
אם הטמעות המכשירים כוללות תמיכה ב-Bluetooth עם צריכת אנרגיה נמוכה (BLE), הן:
- [C-3-1] חובה להצהיר על תכונת החומרה
android.hardware.bluetooth_le
. - [C-3-2] חובה להפעיל את ממשקי ה-API של Bluetooth שמבוססים על GATT (פרופיל מאפיינים גנרי) כפי שמתואר במסמכי התיעוד של ה-SDK וב-android.bluetooth.
- [C-3-3] חובה לדווח על הערך הנכון של
BluetoothAdapter.isOffloadedFilteringSupported()
כדי לציין אם לוגיק הסינון של כיתות ה-API של ScanFilter מיושם. - [C-3-4] חובה לדווח על הערך הנכון של
BluetoothAdapter.isMultipleAdvertisementSupported()
כדי לציין אם יש תמיכה בפרסום באנרגיה נמוכה. [C-3-5] חובה להטמיע זמן קצוב לתפוגה של כתובת פרטית שניתן לפתור (RPA) שלא יהיה ארוך מ-15 דקות, ולבצע רוטציה של הכתובת בתום הזמן הקצוב לתפוגה כדי להגן על פרטיות המשתמשים כשהמכשיר משתמש באופן פעיל ב-BLE לצורך סריקה או פרסום. כדי למנוע התקפות תזמון, גם מרווחי הזמן לתפוגה חייבים להיות אקראיים בין 5 ל-15 דקות.
צריכה להיות תמיכה בהעברת הלוגיקה של הסינון לצ'יפסט של ה-Bluetooth כשמטמיעים את ScanFilter API.
צריכה להיות תמיכה בהעברת סריקות באצווה לצ'יפסט של ה-Bluetooth.
צריכה להיות תמיכה במודעות מרובות עם לפחות 4 משבצות.
אם הטמעות המכשירים תומכות ב-Bluetooth LE ומשתמשות ב-Bluetooth LE לסריקת מיקום, הן:
- [C-4-1] חובה לספק למשתמש אפשרות להפעיל או להשבית את הערך שנקרא דרך System API
BluetoothAdapter.isBleScanAlwaysAvailable()
.
אם הטמעות המכשירים כוללות תמיכה ב-Bluetooth LE ובפרופיל מכשירי שמיעה, כפי שמתואר במאמר תמיכה באודיו של מכשירי שמיעה באמצעות Bluetooth LE, הן:
- [C-5-1] חובה להחזיר את הערך
true
עבור BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).
אם הטמעות המכשירים כוללות תמיכה ב-Bluetooth או ב-Bluetooth Low Energy, הן:
- [C-6-1] חובה להגביל את הגישה לכל מטא-נתונים של Bluetooth (כמו תוצאות סריקות) שאפשר להשתמש בהם כדי להסיק את המיקום של המכשיר, אלא אם האפליקציה המבקשת עוברת בהצלחה בדיקת הרשאות
android.permission.ACCESS_FINE_LOCATION
על סמך המצב הנוכחי שלה בחזית או ברקע.
אם הטמעות במכשירים כוללות תמיכה ב-Bluetooth או ב-Bluetooth Low Energy, והמניפסט של האפליקציה לא כולל הצהרה מהמפתח/ת על כך שהם לא מפיקים מיקום באמצעות Bluetooth, הם:
- [C-6-2] חובה לפקח על הגישה ל-Bluetooth מאחורי
android.permission.ACCESS_FINE_LOCATION
.
אם הטמעות במכשירים מחזירות את הערך true
עבור ה-API BluetoothAdapter.isLeAudioSupported()
, הן:
- [C-7-1] חובה לתמוך בלקוח של שידור unicast.
- [C-7-2] חובה לתמוך ב-PHY של 2M.
- [C-7-3] חובה לתמוך בפרסום מורחב של LE.
- [C-7-4] חובה לתמוך לפחות בשני חיבורי CIS ב-CIG.
- [C-7-5] חובה להפעיל בו-זמנית את לקוח ה-unicast של BAP, את רכז הקבוצות של CSIP, את שרת ה-MCP, את הבקר של VCP ואת שרת ה-CCP.
- [C-SR-1] מומלץ מאוד להפעיל לקוח unicast של HAP.
אם הטמעות במכשירים מחזירות את הערך true
עבור ה-API BluetoothAdapter.isLeAudioBroadcastSourceSupported()
, הן:
- [C-8-1] חובה לתמוך לפחות בשני קישורי BIS ב-BIG.
- [C-8-2] חובה להפעיל בו-זמנית את מקור השידור של BAP ואת הכלי לעזרה בשידור של BAP.
- [C-8-3] חובה לתמוך בפרסום תקופתי של LE.
אם הטמעות במכשירים מחזירות את הערך true
עבור ה-API BluetoothAdapter.isLeAudioBroadcastAssistantSupported()
, הן:
- [C-9-1] חובה לתמוך ב-PAST (Periodic Advertising Sync Transfer).
- [C-9-2] חובה לתמוך בפרסום תקופתי של LE.
אם הטמעות של מכשירים מכריזות על FEATURE_BLUETOOTH_LE
, הן:
- [C-10-1] מדידות ה-RSSI חייבות להיות בטווח של +/-9dB ב-95% מהמדידות במרחק של מטר אחד ממכשיר ייחוס שמעביר בתדר
ADVERTISE_TX_POWER_HIGH
בסביבה עם קו ראייה ישיר. [C-10-2] חובה לכלול תיקוני Rx/Tx כדי לצמצם את הסטיות בכל ערוץ, כך שהמדידות בכל אחד מ-3 הערוצים, בכל אחת מהאנטנות (אם נעשה שימוש בכמה אנטנות), יהיו בטווח של +/-3dB זו מזו ב-95% מהמדידות.
[C-SR-2] מומלץ מאוד למדוד את ההיסט של Rx ולבצע תיקון שלו כדי לוודא שהערך החציוני של RSSI ב-BLE הוא -60dBm +/-10 dB במרחק של 1 מ' ממכשיר העזרה שמשדר ב-
ADVERTISE_TX_POWER_HIGH
, כאשר המכשירים מכוונים כך שהם נמצאים ב'מישורים מקבילים' והמסכים פונים לאותו כיוון.[C-SR-3] מומלץ מאוד למדוד את ההיסט של ה-Tx ולבצע תיקון שלו כדי לוודא שה-RSSI הממוצע של ה-BLE הוא -60dBm +/-10 dB בזמן הסריקה ממכשיר עזר שנמצא במרחק 1 מ' ומעביר ב-
ADVERTISE_TX_POWER_HIGH
, כאשר המכשירים מכוונים כך שהם נמצאים ב'מישורים מקבילים' והמסכים פונים לאותו כיוון.העברנו את הדרישות [C-10-3] ו-[C-10-4] לקטע 2.2.1. חומרה.
- [C-10-3] חובה למדוד את ההיסט של Rx ולבצע תיקון כדי לוודא שהערך החציוני של RSSI ב-BLE הוא -55dBm +/-10 dB במרחק של 1 מ' ממכשיר עזר שמשדר ב-
ADVERTISE_TX_POWER_HIGH
. - [C-10-4] חובה למדוד את ההיסט של ה-Tx ולבצע התאמה כדי לוודא שה-RSSI הממוצע של ה-BLE הוא -55dBm +/-10 dB במהלך הסריקה ממכשיר עזר שנמצא במרחק 1 מ' ומשדר ב-
ADVERTISE_TX_POWER_HIGH
.
מומלץ מאוד לפעול לפי שלבי הגדרת המדידה שמפורטים בקטע דרישות לכיול נוכחות.
אם הטמעות המכשירים תומכות ב-Bluetooth בגרסה 5.0, הן:
- [C-SR-4] מומלץ מאוד לספק תמיכה בנושאים הבאים:
- LE 2M PHY
- LE Codec PHY
- תוסף פרסום של LE
- פרסום תקופתי
- לפחות 10 קבוצות של מודעות
- לפחות 8 חיבורים בו-זמניים ל-LE. כל חיבור יכול להיות באחד משני התפקידים של טופולוגיית החיבור.
- פרטיות בשכבת הקישור של LE
- רשימת 'פתרון' בגודל של לפחות 8 רשומות
7.4.4. תקשורת מטווח קצר
הטמעות במכשירים:
- צריך לכלול משדר-מקלט וחומרה קשורה לתקשורת מטווח קצר (NFC).
- [C-0-1] חובה להטמיע את ממשקי ה-API
android.nfc.NdefMessage
ו-android.nfc.NdefRecord
גם אם הם לא כוללים תמיכה ב-NFC, או להצהיר על התכונהandroid.hardware.nfc
כי הכיתות מייצגות פורמט של ייצוג נתונים שלא תלוי בפרוטוקול.
אם הטמעות במכשירים כוללות חומרה של NFC ויש כוונה להפוך אותה לזמינה לאפליקציות צד שלישי, צריך:
- [C-1-1] חובה לדווח על התכונה
android.hardware.nfc
מה-methodandroid.content.pm.PackageManager.hasSystemFeature()
. - חייבת להיות לו אפשרות לקרוא ולכתוב הודעות NDEF באמצעות תקני ה-NFC הבאים, כפי שמפורט בהמשך:
- [C-1-2] חייב להיות מסוגל לפעול כקורא/כותב של NFC Forum (כפי שמוגדר במפרט הטכני של NFC Forum, NFCForum-TS-DigitalProtocol-1.0) באמצעות תקני ה-NFC הבאים:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- סוגי תגים של NFC Forum 1, 2, 3, 4, 5 (מוגדרים על ידי NFC Forum)
[C-SR-1] מומלץ מאוד שיהיו יכולות לקרוא ולכתוב הודעות NDEF וגם נתונים גולמיים באמצעות תקני ה-NFC הבאים. חשוב לזכור שתקני ה-NFC מוגדרים כ'מומלצים מאוד', אבל בהגדרת התאימות של גרסה עתידית הם צפויים להשתנות ל'חובה'. התקנים האלה הם אופציונליים בגרסה הזו, אבל יהיו נדרשים בגרסאות עתידיות. מומלץ מאוד למכשירים קיימים וחדשים עם גרסת Android הזו לעמוד בדרישות האלה כבר עכשיו, כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה.
[C-1-13] חובה לבצע סקירה של כל הטכנולוגיות הנתמכות במצב חיפוש של NFC.
צריך להיות במצב חשיפת NFC כשהמכשיר פעיל, המסך פעיל ומסך הנעילה לא נעול.
אמורה להיות מסוגלת לקרוא את הברקוד ואת כתובת ה-URL (אם היא מקודדת) של מוצרים עם ברקוד NFC דק.
חשוב לדעת: אין קישורים זמינים לכולם למפרטים של JIS, ISO ו-NFC Forum שצוינו למעלה.
מערכת 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 Card Emulation כפי שהם מוגדרים ב-Android SDK.
אם הטמעות המכשיר כוללות תמיכה כללית ב-NFC כפי שמתואר בקטע הזה, ותמיכה בטכנולוגיות MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF ב-MIFARE Classic) בתפקיד הקורא/הסופר, הן:
- [C-4-1] חובה להטמיע את ממשקי ה-API התואמים ל-Android כפי שמתואר ב-Android SDK.
- [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] חובה לכלול תמיכה באחת או יותר מהצורות של רשתות נתונים. באופן ספציפי, הטמעות במכשירים חייבות לכלול תמיכה לפחות בתקן נתונים אחד שיכול להגיע לקצב של 200Kbit/sec או יותר. דוגמאות לטכנולוגיות שעומדות בדרישות האלה כוללות את EDGE, HSPA, EV-DO, 802.11g, Ethernet ו-Bluetooth PAN.
- צריכה לכלול גם תמיכה בתקן אחד לפחות של נתונים אלחוטיים נפוצים, כמו 802.11 (Wi-Fi), כשתקן הרשתות הפיזי (כמו Ethernet) הוא חיבור הנתונים הראשי.
- יכולים להטמיע יותר מסוג אחד של קישוריות נתונים.
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 שניות.
- חובה לוודא שתקשורת IPv6 אמינה כמו IPv4, לדוגמה:
- [C-0-6] חובה לספק לאפליקציות של צד שלישי קישוריות IPv6 ישירה לרשת כשהן מחוברות לרשת IPv6, ללא כל סוג של תרגום כתובות או יציאות שמתרחש באופן מקומי במכשיר. גם ממשקי API מנוהלים כמו
Socket#getLocalAddress
אוSocket#getLocalPort
וגם ממשקי API של NDK כמוgetsockname()
אוIPV6_PKTINFO
חייבים להחזיר את כתובת ה-IP והיציאה שבהן נעשה שימוש בפועל לשליחה ולקבלה של חבילות ברשת, וגלויות ככתובת ה-IP והיציאה של המקור בשרתי אינטרנט (אינטרנט).
רמת התמיכה הנדרשת ב-IPv6 תלויה בסוג הרשת, כפי שמפורט בדרישות הבאות.
אם הטמעות המכשירים תומכות ב-Wi-Fi, הן:
- [C-1-1] חובה לתמוך ב-dual-stack ובפעולה ב-IPv6 בלבד ב-Wi-Fi.
אם הטמעות המכשירים תומכות ב-Ethernet, הן:
- [C-2-1] חובה לתמוך ב-dual-stack ובפעולה ב-IPv6 בלבד ב-Ethernet.
אם הטמעות במכשירים תומכות בנתונים סלולריים, הן:
- [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 APIConnectivityManager#startCaptivePortalApp(Network, Bundle)
. - [C-1-2] חובה לבצע זיהוי של פורטלים שבהם נדרש אישור כניסה (captive portal) ולתמוך בכניסה דרך אפליקציית הפורטל שבהם נדרש אישור כניסה כשהמכשיר מחובר לכל סוג רשת, כולל רשת סלולרית/ניידת, Wi-Fi, Ethernet או 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] מומלץ מאוד לספק את מצב חיסכון בחבילת הגלישה.
אם הטמעות במכשירים מספקות את מצב חיסכון הנתונים, הן:
- [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] חובה למנות את הקוראים הזמינים של רכיבים מאובטחים באמצעות API של
android.se.omapi.SEService.getReaders()
.[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] חובה להטמיע את Android API התואם ב-android.uwb.
- [C-1-2] חובה לדווח על הדגל של תכונת החומרה android.hardware.uwb.
- [C-1-3] חובה לתמוך בכל הפרופילים הרלוונטיים של UWB שמוגדרים בהטמעה של Android.
- [C-1-4] חובה לספק למשתמש אמצעי להפעלה או להשבתה של הרדיו ב-UWB.
- [C-1-5] חובה לאכוף שאפליקציות שמשתמשות ברדיו UWB יקבלו את ההרשאה UWB_RANGING (בקבוצת ההרשאות NEARBY_DEVICES).
- [C-SR-1] מומלץ מאוד לעבור את בדיקות התאימות והאישור הרלוונטיות שהוגדרו על ידי ארגוני התקנים, כולל FIRA, CCC ו-CSA.
- [C-1-6] חובה לוודא שמדידות המרחק נמצאות בטווח של +/-15 ס"מ ב-95% מהמדידות בסביבת קו הראייה במרחק של 1 מ' בתא לא רפלקטיבי.
- [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] חייבת להיות לאפליקציה אפשרות להקצות בו-זמנית 3 מפות ביטים מסוג 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 ביט ומטמיעים את API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO
:
- [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] אסור להשתמש במצלמה קדמית כברירת מחדל ל-Camera API, ואסור להגדיר את ה-API כך שיתייחס למצלמה קדמית כמצלמה אחורית שמוגדרת כברירת מחדל, גם אם זו המצלמה היחידה במכשיר.
- [C-1-4] התצוגה המקדימה של המצלמה חייבת להיות מוחזרת (mirrored) אופקית ביחס לכיוון שצוין על ידי האפליקציה, אם האפליקציה הנוכחית ביקשה במפורש שצילום המצלמה יוזז באמצעות קריאה ל-method
android.hardware.Camera.setDisplayOrientation()
. לעומת זאת, אם האפליקציה הנוכחית לא מבקשת במפורש לבצע סיבוב של מסך המצלמה באמצעות קריאה ל-methodandroid.hardware.Camera.setDisplayOrientation()
, חובה לבצע היפוך מראה של התצוגה המקדימה לפי ציר האופק שמוגדר כברירת מחדל במכשיר. - [C-1-5] אסור לשקף את התמונות הסטטיות או את הסטרימינג הסופי של הסרטונים שצולמו, שמוחזרים להודעות החזרה (callbacks) של האפליקציה או מועברים לאחסון מדיה.
- [C-1-6] חובה לשקף את התמונה שמוצגת על ידי התצוגה המקדימה באותו אופן שבו מוצג זרם התמונות של תצוגה המקדימה במצלמה.
- יכולות לכלול תכונות (כמו פוקוס אוטומטי, פלאש וכו') שזמינות למצלמות הפונות לאחור, כפי שמתואר בסעיף 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. התנהגות Camera API
Android כולל שתי חבילות API לגישה למצלמה. ה-API החדש יותר, android.hardware.camera2, חושף לאפליקציה אמצעי בקרה ברמה נמוכה יותר של המצלמה, כולל תהליכי סטרימינג או התפרצות יעילים ללא העתקה (zero-copy) ואמצעי בקרה לכל פריים של חשיפת התמונה, הגברה, שיפור של איזון הלבן, המרת צבעים, הסרת רעשי רקע, חידוד ועוד.
חבילת ה-API הישנה יותר, android.hardware.Camera
, מסומנת כמיושנת ב-Android 5.0, אבל היא עדיין אמורה להיות זמינה לשימוש באפליקציות. בהטמעות של מכשירי Android, חובה להבטיח את התמיכה המתמשכת ב-API כפי שמתואר בקטע הזה וב-Android SDK.
לכל התכונות המשותפות בין הכיתה android.hardware.Camera שנמצאת בשימוש מצומצם לבין החבילה החדשה יותר android.hardware.camera2, חייבים להיות ביצועים ואיכות זהים בשני ממשקי ה-API. לדוגמה, בהגדרות מקבילות, המהירות והדיוק של המיקוד האוטומטי חייבים להיות זהים, ואיכות התמונות שצולמו חייבת להיות זהה. אין דרישה שהתכונות שתלויות בסמינטיקה השונה של שני ממשקי ה-API יהיו בעלות מהירות או איכות זהות, אבל הן צריכות להיות דומות ככל האפשר.
הטמעות של מכשירים חייבות ליישם את ההתנהגויות הבאות לממשקי ה-API שקשורים למצלמה, לכל המצלמות הזמינות. הטמעות במכשירים:
- [C-0-1] חובה להשתמש ב-
android.hardware.PixelFormat.YCbCr_420_SP
לנתוני תצוגה מקדימה שסופקו להחזרות קריאה (callbacks) של אפליקציות, כשאף אפליקציה לא התקשרה ל-android.hardware.Camera.Parameters.setPreviewFormat(int)
. - [C-0-2] בנוסף, הנתונים חייבים להיות בפורמט הקידוד NV21 כשאפליקציה רושמת מופע
android.hardware.Camera.PreviewCallback
והמערכת קוראת לשיטהonPreviewFrame()
ופורמט התצוגה המקדימה הוא YCbCr_420_SP, הנתונים ב-byte[] מועברים אל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] חובה להטמיע את Camera API המלא שכלול במסמכי התיעוד של Android SDK, גם אם המכשיר כולל פוקוס אוטומטי בחומרה או יכולות אחרות. לדוגמה, מצלמות ללא פוקוס אוטומטי עדיין חייבות לקרוא לכל המכונות הרשמות של
android.hardware.Camera.AutoFocusCallback
(למרות שאין לכך רלוונטיות למצלמה ללא פוקוס אוטומטי). שימו לב שהדבר רלוונטי גם למצלמות קדמיות. לדוגמה, למרות שרוב המצלמות הקדמיות לא תומכות בפוקוס אוטומטי, עדיין צריך 'לזייף' את קריאות החזרה (callbacks) של ה-API כפי שמתואר. - [C-0-6] חובה לזהות ולכבד כל שם פרמטר שמוגדר כקבוע בכיתה
android.hardware.Camera.Parameters
ובכיתהandroid.hardware.camera2.CaptureRequest
. לעומת זאת, בהטמעות של מכשירים אסור להכיר או לכבד קבועים של מחרוזות שמועברים ל-methodandroid.hardware.Camera.setParameters()
, מלבד אלה שמתועדים כקבועים ב-android.hardware.Camera.Parameters
. כלומר, הטמעות במכשירים חייבות לתמוך בכל הפרמטרים הרגילים של המצלמה, אם החומרה מאפשרת זאת, ואסור להן לתמוך בסוגי פרמטרים מותאמים אישית של מצלמה. לדוגמה, הטמעות של מכשירים שתומכות בצילומי תמונות באמצעות שיטות צילום עם טווח דינמי גבוה (HDR) חייבות לתמוך בפרמטר המצלמהCamera.SCENE_MODE_HDR
. - [C-0-7] חובה לדווח על רמת התמיכה המתאימה באמצעות המאפיין
android.info.supportedHardwareLevel
כפי שמתואר ב-Android SDK, ולדווח על דגלים מתאימים של תכונות מסגרת. - [C-0-8] חובה גם להצהיר על יכולות המצלמה הנפרדות של
android.hardware.camera2
באמצעות המאפייןandroid.request.availableCapabilities
ולהצהיר על דגלים מתאימים של תכונות. חובה להגדיר את דגל התכונה אם אחד ממכשירי המצלמה המצורפים תומך בתכונה. - [C-0-9] חובה לשדר את הכוונה
Camera.ACTION_NEW_PICTURE
בכל פעם שצולמת תמונה חדשה במצלמה והרשומה של התמונה נוספה למאגר המדיה. - [C-0-10] חובה לשדר את הכוונה
Camera.ACTION_NEW_VIDEO
בכל פעם שמצלמים סרטון חדש במצלמה והתמונה נוספה למאגר המדיה. - [C-0-11] חובה שכל המצלמות יהיו נגישות דרך ממשק ה-API הישן
android.hardware.Camera
, וגם דרך ממשק ה-APIandroid.hardware.camera2
. - [C-0-12] חובה לוודא שלא מתבצע שינוי במראה הפנים, כולל, בין היתר, שינוי בגיאומטריה של הפנים, בגוון העור של הפנים או בשיפור העור של הפנים בכל ממשק API של
android.hardware.camera2
או שלandroid.hardware.Camera
. - [C-SR-1] במכשירים עם כמה מצלמות RGB בקרבת מקום שמכוונות לאותו כיוון, מומלץ מאוד לתמוך במכשיר מצלמה לוגי שמציג את היכולות
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, שמורכב מכל מצלמות ה-RGB שמכוונות לאותו כיוון כמכשירי משנה פיזיים.
אם הטמעות במכשירים מספקות ממשק API למצלמה קנייני לאפליקציות של צד שלישי, הן:
- [C-1-1] חובה להטמיע ממשק API כזה של מצלמה באמצעות API של
android.hardware.camera2
. - יכולים לספק תגים ו/או תוספי ספקים ל-API של
android.hardware.camera2
.
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] חובה לצנזר מטא-נתונים של מיקום, כמו תגי Exif של GPS, שמאוחסנים בקובצי מדיה כשמתבצעת גישה לקבצים האלה דרך
MediaStore
, אלא אם לאפליקציה הקוראת יש את ההרשאהACCESS_MEDIA_LOCATION
.
הטמעות של מכשירים יכולות לעמוד בדרישות שלמעלה באמצעות אחת מהאפשרויות הבאות:
- אחסון נשלף שזמין למשתמש, כמו חריץ לכרטיס Secure Digital (SD).
- חלק מהאחסון הפנימי (לא ניתן להסרה) כפי שהוא מיושם בפרויקט Android Open Source Project (AOSP).
אם הטמעות במכשירים משתמשות באחסון נשלף כדי לעמוד בדרישות שלמעלה, הן:
- [C-1-1] חובה להטמיע ממשק משתמש של הודעה קופצת או הודעה קבועה (toast) כדי להזהיר את המשתמש כשאין אמצעי אחסון מוכנס לחריץ.
- [C-1-2] חובה לכלול אמצעי אחסון בפורמט FAT (למשל כרטיס SD) או לציין על הקופסה ועל חומרים אחרים שזמינים בזמן הרכישה שצריך לרכוש את אמצעי האחסון בנפרד.
אם הטמעות במכשירים משתמשות בחלק מהאחסון שאינו ניתן להסרה כדי לעמוד בדרישות שלמעלה, הן:
- צריך להשתמש בהטמעה של AOSP לאחסון המשותף של האפליקציה הפנימית.
- יכולה לשתף את נפח האחסון עם הנתונים הפרטיים של האפליקציה.
אם להטמעות של המכשירים יש יציאת USB עם תמיכה במצב USB ציוד היקפי, הן:
- [C-3-1] חובה לספק מנגנון לגישה לנתונים באחסון המשותף של האפליקציה ממחשב מארח.
- צריך לחשוף תוכן משני נתיבי האחסון באופן שקוף באמצעות שירות סורק המדיה של Android ו-
android.provider.MediaStore
. - אפשר להשתמש באחסון בנפח גדול ב-USB, אבל מומלץ להשתמש בפרוטוקול העברת מדיה כדי לעמוד בדרישות.
אם להטמעות של המכשירים יש יציאת USB במצב USB ציוד היקפי ותמיכה ב-Media Transfer Protocol, הן:
- צריכה להיות תואמת למארח ה-MTP של Android לדוגמה, Android File Transfer.
- צריך לדווח על סוג מכשיר USB של 0x00.
- צריך לדווח על שם ממשק USB של 'MTP'.
7.6.3. Adoptable Storage
אם המכשיר צפוי להיות נייד, בניגוד לטלוויזיה, הטמעות המכשיר הן:
- [C-SR-1] מומלץ מאוד להטמיע את האחסון שניתן לאמץ במיקום יציב לטווח ארוך, כי ניתוק בטעות עלול לגרום לאובדן או לפגיעה בנתונים.
אם היציאה של מכשיר האחסון הנשלף נמצאת במיקום יציב לטווח ארוך, למשל בתא הסוללה או במכסה מגן אחר, הטמעות המכשיר הן:
- [C-SR-2] מומלץ מאוד להטמיע אחסון שניתן להתאמה.
7.7. USB
אם להטמעות של המכשירים יש יציאת USB, הן:
- צריכה להיות תמיכה במצב ציוד היקפי USB ובמצב מארח USB.
- צריכה להיות תמיכה בהשבתה של איתות נתונים דרך USB.
7.7.1. מצב ציוד היקפי ב-USB
אם הטמעות המכשירים כוללות יציאת USB שתומכת במצב ציוד היקפי:
- [C-1-1] חובה שאפשר יהיה לחבר את היציאה למארח USB עם יציאת USB רגילה מסוג A או מסוג C.
- [C-1-2] חובה לדווח על הערך הנכון של
iSerialNumber
בתיאור ההתקן הסטנדרטי של USB דרךandroid.os.Build.SERIAL
. - [C-1-3] חובה לזהות מטענים של 1.5A ו-3.0A בהתאם לתקן הנגדים של Type-C, וחובה לזהות שינויים במודעה אם הם תומכים ב-USB Type-C.
- [C-SR-1] היציאה אמורה להיות בפורמט USB מסוג micro-B, micro-AB או Type-C. מומלץ מאוד שכל מכשירי Android הקיימים והחדשים יעמדו בדרישות האלה כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה.
- [C-SR-2] היציאה אמורה להיות ממוקמת בחלק התחתון של המכשיר (בהתאם לכיוון הטבעי) או להפעיל סיבוב מסך בתוכנה לכל האפליקציות (כולל מסך הבית), כדי שהמסך יוצג בצורה נכונה כשהמכשיר מונח כך שהיציאה נמצאת בחלק התחתון. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה, כדי שיוכלו לשדרג לגרסאות עתידיות של הפלטפורמה.
- [C-SR-3] צריך להטמיע תמיכה בזרם של 1.5A במהלך תנועה וצפצוף HS, כפי שמפורט במפרט טעינה של סוללות USB, גרסה 1.2. מומלץ מאוד שכל מכשירי Android הקיימים והחדשים יעמדו בדרישות האלה כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה.
- [C-SR-4] מומלץ מאוד לא לתמוך בשיטות טעינה קנייניות שמשנה את המתח של Vbus מעבר לרמות ברירת המחדל, או לשנות את התפקידים של מקור או נקודת קצה, כי הן עלולות לגרום לבעיות בתאימות עם מטענים או מכשירים שתומכים בשיטות הסטנדרטיות של USB Power Delivery. אמנם ההמלצה היא 'מומלץ מאוד', אבל בגרסאות עתידיות של Android יכול להיות שנדרוש שכל המכשירים עם חיבור Type-C יתמכו בתאימות מלאה לטעינה באמצעות מטענים רגילים עם חיבור Type-C.
- [C-SR-5] מומלץ מאוד לתמוך ב-Power Delivery לנתונים ולהחלפת תפקידים של מתח כשיש תמיכה ב-USB Type-C ובמצב מארח USB.
- צריכה להיות תמיכה ב-Power Delivery לטעינה במתח גבוה ותמיכה במצבים חלופיים, כמו Display Out.
- צריך להטמיע את המפרט ואת ה-API של Android Open Accessory (AOA) כפי שמתואר במסמכי התיעוד של Android SDK.
אם הטמעות של מכשירים כוללות יציאת USB ומטמיעות את מפרט AOA, הן:
- [C-2-1] חובה להצהיר על תמיכה בתכונה החומרה
android.hardware.usb.accessory
. - [C-2-2] הכיתה של אחסון בנפח גדול ב-USB חייבת לכלול את המחרוזת 'android' בסוף המחרוזת
iInterface
של תיאור הממשק של אחסון בנפח גדול ב-USB
7.7.2. מצב מארח USB
אם הטמעות המכשירים כוללות יציאת USB שתומכת במצב מארח, הן:
- [C-1-1] חובה להטמיע את Android USB host API כפי שמתואר ב-Android SDK, וצריך להצהיר על תמיכה בתכונה החומרה
android.hardware.usb.host
. - [C-1-2] חובה להטמיע תמיכה לחיבור ציוד היקפי סטנדרטי מסוג USB. במילים אחרות, חובה:
- יש יציאת Type-C במכשיר או שסופקו כבלים שמתאימים יציאה קניינית במכשיר ליציאת USB Type-C רגילה (מכשיר USB Type-C).
- יש יציאת USB מסוג A במכשיר או שצריך לשלוח כבל שמתאים יציאה קניינית במכשיר ליציאת USB רגילה מסוג A.
- יש יציאת micro-AB במכשיר, שאמורה להגיע עם כבל עם מתאם ליציאת Type-A רגילה.
- [C-1-3] אסור לשלוח את המכשיר עם מתאם שממיר מיציאות USB מסוג A או מיציאות micro-AB ליציאת Type-C (שקע).
- [C-SR-1] מומלץ מאוד להטמיע את USB audio class כפי שמתואר במסמכי התיעוד של Android SDK.
- צריך לתמוך בטעינה של התקן ההיקפי המחובר מסוג USB במצב מארח, לפרסם זרם מקור של לפחות 1.5A כפי שמפורט בקטע 'פרמטרים של סיום' במפרט USB Type-C Cable and Connector Specification Revision 1.2 למחברים מסוג USB Type-C, או להשתמש בטווח זרם הפלט של יציאת טעינה במורד הזרם (CDP) כפי שמפורט במפרט USB Battery Charging specifications, revision 1.2 למחברים מסוג Micro-AB.
- צריך להטמיע ולתמוך בתקני USB Type-C.
אם הטמעות של מכשירים כוללות יציאת USB שתומכת במצב מארח ובסיווג האודיו של USB, הן:
- [C-2-1] חובה לתמוך בממשק ה-HID של USB.
- [C-2-2] חובה לתמוך בזיהוי ובמיפוי של שדות הנתונים הבאים של HID, שצוינו בטבלאות השימוש של USB HID ובבקשת השימוש בפקודות קוליות, לקבועות
KeyEvent
, כפי שמפורט בהמשך:- דף שימוש (0xC) מזהה שימוש (0x0CD):
KEYCODE_MEDIA_PLAY_PAUSE
- דף שימוש (0xC) מזהה שימוש (0x0E9):
KEYCODE_VOLUME_UP
- דף שימוש (0xC) מזהה שימוש (0x0EA):
KEYCODE_VOLUME_DOWN
- דף שימוש (0xC) מזהה שימוש (0x0CF):
KEYCODE_VOICE_ASSIST
- דף שימוש (0xC) מזהה שימוש (0x0CD):
אם הטמעות המכשירים כוללות יציאת USB שתומכת במצב מארח וב-Storage Access Framework (SAF), הן:
- [C-3-1] חובה לזהות כל מכשיר MTP (פרוטוקול העברת מדיה) שמחובר מרחוק, ולאפשר גישה לתוכן שלו באמצעות הכוונות
ACTION_GET_CONTENT
, ACTION_OPEN_DOCUMENT
ו-ACTION_CREATE_DOCUMENT
. .
אם הטמעות המכשירים כוללות יציאת USB שתומכת במצב מארח וב-USB Type-C, הן:
- [C-4-1] חובה להטמיע את הפונקציונליות של יציאה עם תפקיד כפול כפי שמוגדרת במפרט USB Type-C (קטע 4.5.1.3.3). ביציאות עם תפקיד כפול, במכשירים שכוללים שקע אודיו בגודל 3.5 מ"מ, יכול להיות שהזיהוי של שקע USB (מצב מארח) יהיה מושבת כברירת מחדל, אבל המשתמש חייב להיות מסוגל להפעיל אותו.
- [C-SR-2] מומלץ מאוד לתמוך ב-DisplayPort, צריך לתמוך בקצבי נתונים של USB SuperSpeed, ומומלץ מאוד לתמוך ב-Power Delivery להחלפת תפקידים של נתונים וחשמל.
- [C-SR-3] מומלץ מאוד לא לתמוך במצב 'מתאם אודיו' כפי שמתואר בנספח א' של גרסה 1.2 של מפרט הכבל והמחבר מסוג USB Type-C.
- צריך להטמיע את המודל Try.* שמתאים ביותר לגורם הצורה של המכשיר. לדוגמה, במכשיר נייד צריך להטמיע את המודל Try.SNK.
7.8. אודיו
7.8.1. מיקרופון
אם הטמעות במכשירים כוללות מיקרופון, הן:
- [C-1-1] חובה לדווח על קבוע התכונה
android.hardware.microphone
. - [C-1-2] חייב לעמוד בדרישות להקלטת אודיו שמפורטות בקטע 5.4.
- [C-1-3] חייב לעמוד בדרישות של זמן האחזור של האודיו שמפורטות בקטע 5.6.
- [C-SR-1] מומלץ מאוד לתמוך בהקלטה של אולטרסאונד קרוב כפי שמתואר בסעיף 7.8.3.
אם הטמעות של מכשירים לא כוללות מיקרופון, הן:
- [C-2-1] אסור לדווח על קבוע התכונה
android.hardware.microphone
. - [C-2-2] חובה להטמיע את ממשק ה-API להקלטת אודיו לפחות כ-no-ops, בהתאם לקטע 7.
7.8.2. יעד השמע
אם הטמעות של מכשירים כוללות רמקול או יציאת פלט אודיו/מולטימדיה למכשיר היקפי של פלט אודיו, כמו שקע אודיו בגודל 3.5 מ"מ עם 4 מוליכים או יציאה במצב מארח USB באמצעות USB audio class, הן:
- [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 שקשורים לפלט האודיו כ-no-ops לפחות.
לצורכי הקטע הזה, 'יציאת פלט' היא ממשק פיזי, כמו שקע אודיו בגודל 3.5 מ"מ, HDMI או יציאת USB במצב מארח עם אודיו מסוג USB. תמיכה בפלט אודיו באמצעות פרוטוקולים מבוססי רדיו כמו Bluetooth, Wi-Fi או רשת סלולרית לא נחשבת ככוללת 'יציאת פלט'.
7.8.2.1. יציאות אודיו אנלוגיות
כדי להיות תואמים לאוזניות ולאביזרי אודיו אחרים שמשתמשים בחיבור אודיו בגודל 3.5 מ"מ בסביבת Android, אם הטמעות המכשירים כוללות שקע אודיו אנלוגי אחד או יותר, הן:
- [C-SR-1] מומלץ מאוד לכלול לפחות אחד משקעי האודיו כתקע אודיו 3.5 מ"מ עם 4 מוליכים.
אם להטמעות של המכשירים יש שקע אודיו 3.5 מ"מ עם 4 מוליכים, הן:
- [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
- 70 אוהם או פחות:
- [C-1-4] חובה להפעיל את
ACTION_HEADSET_PLUG
כשמחברים את המחבר, אבל רק אחרי שכל המגעים במחבר נוגעים בקטעים הרלוונטיים בתקע. - [C-1-5] חייב להיות מסוגל להפעיל לפחות 150mV ± 10% מתח יציאה בהתנגדות של רמקול 32 אוהם.
- [C-1-6] המתח של המיקרופון חייב להיות בין 1.8V ל-2.9V.
- [C-1-7] חובה לזהות את הטווח הבא של עכבה שווה ערך בין המיקרופון לבין מוליכי הארקה בתקע האודיו ולמפות אותו לקוד המפתח:
- 110-180 אוהם:
KEYCODE_VOICE_ASSIST
- 110-180 אוהם:
- [C-SR-2] מומלץ מאוד לתמוך בכבלים עם מחברי אודיו לפי הסדר של OMTP.
- [C-SR-3] מומלץ מאוד לתמוך בהקלטת אודיו מאוזניות סטריאופוניות עם מיקרופון.
אם הטמעות של מכשירים כוללות שקע אודיו עם 4 מוליכים בגודל 3.5 מ"מ ותומכות במיקרופון, ומפיצות את ה-android.intent.action.HEADSET_PLUG
עם הערך הנוסף microphone מוגדר כ-1, הן:
- [C-2-1] חובה לתמוך בזיהוי המיקרופון באביזר האודיו המחובר.
7.8.2.2. שקעי אודיו דיגיטליים
הדרישות הספציפיות למכשיר מפורטות בקטע 2.2.1.
7.8.3. אולטרסאונד קרוב
אודיו קרוב לאולטרה-סאונד הוא התדר 18.5kHz עד 20kHz.
הטמעות במכשירים:
- חובה לדווח בצורה נכונה על התמיכה ביכולת אודיו ליד אולטרסאונד באמצעות ה-API AudioManager.getProperty באופן הבא:
אם הערך של PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND
הוא 'true', מקורות האודיו VOICE_RECOGNITION
ו-UNPROCESSED
חייבים לעמוד בדרישות הבאות:
- [C-1-1] תגובת הכוח הממוצעת של המיקרופון בתחום התדרים 18.5kHz עד 20kHz חייבת להיות נמוכה ב-15dB לכל היותר מהתגובה בתדר 2kHz.
- [C-1-2] יחס האות לרעש ללא משקל של המיקרופון בטווח של 18.5kHz עד 20kHz, עבור צליל של 19kHz ב-26dBFS, חייב להיות לפחות 50dB.
אם הערך של PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND
הוא 'true':
- [C-2-1] התגובה הממוצעת של הרמקול בתחום התדרים 18.5kHz עד 20kHz חייבת להיות גבוהה מ-40dB מתחת לתגובה בתדר 2kHz.
7.8.4. תקינות האות
הטמעות במכשירים:
- צריך לספק נתיב של אות אודיו ללא תקלות גם לזרמי הקלט וגם לזרמי הפלט במכשירים ניידים, כפי שמוגדר על ידי אפס תקלות שנמדדו במהלך בדיקה של דקה אחת לכל נתיב. בדיקה באמצעות OboeTester "Automated Glitch Test".
הבדיקה דורשת מתאם אודיו ל-loopback, שמחובר ישירות לתקע 3.5 מ"מ ו/או בשילוב עם מתאם USB-C ל-3.5 מ"מ. מומלץ לבדוק את כל יציאות הקול.
נכון לעכשיו, OboeTester תומך בנתיבים של AAudio, לכן צריך לבדוק את השילובים הבאים כדי לאתר באגים באמצעות AAudio:
מצב Perf | שיתוף | תדירות דגימה של פלט | ב-Chans | Out Chans |
---|---|---|---|---|
LOW_LATENCY | בלעדי | UNSPECIFIED | 1 | 2 |
LOW_LATENCY | בלעדי | UNSPECIFIED | 2 | 1 |
LOW_LATENCY | משותף | UNSPECIFIED | 1 | 2 |
LOW_LATENCY | משותף | UNSPECIFIED | 2 | 1 |
ללא | משותף | 48000 | 1 | 2 |
ללא | משותף | 48000 | 2 | 1 |
ללא | משותף | 44100 | 1 | 2 |
ללא | משותף | 44100 | 2 | 1 |
ללא | משותף | 16000 | 1 | 2 |
ללא | משותף | 16000 | 2 | 1 |
שידור מהימן אמור לעמוד בקריטריונים הבאים ליחס אות לרעש (SNR) ולעיוות הרמוני כולל (THD) עבור גל סינוס של 2,000Hz.
מתמר | THD | SNR |
---|---|---|
הרמקול המובנה הראשי, שנמדד באמצעות מיקרופון חיצוני | פחות מ-3.0% | 50dB או יותר |
המיקרופון המובנה הראשי, שנמדד באמצעות רמקול חיצוני למטרות השוואה | פחות מ-3.0% | 50dB או יותר |
שקעים אנלוגיים מובנים בגודל 3.5 מ"מ, שנבדקו באמצעות מתאם לולאה חוזרת | פחות מ-1% | 60dB או יותר |
מתאמי USB שסופקו עם הטלפון, נבדקו באמצעות מתאם לולאה חוזרת | < 1.0% | 60dB או יותר |
7.9. מציאות מדומה
Android כולל ממשקי API וכלים לפיתוח אפליקציות 'מציאות מדומה' (VR), כולל חוויות VR לנייד באיכות גבוהה. בהטמעות במכשירים חייבים להטמיע את ממשקי ה-API וההתנהגויות האלה בצורה תקינה, כפי שמתואר בקטע הזה.
7.9.1. מצב מציאות מדומה
Android כולל תמיכה במצב VR, תכונה שמטפלת ברינדור סטריאופוני של התראות ומשביתה רכיבים של ממשק המשתמש של המערכת עם מונוקול כאשר אפליקציית VR נמצאת במוקד המשתמשים.
7.9.2. מצב מציאות מדומה – ביצועים גבוהים
אם הטמעות המכשירים תומכות במצב VR, הן:
- [C-1-1] חייב להיות עם לפחות 2 ליבות פיזיות.
- [C-1-2] חובה להצהיר על התכונה
android.hardware.vr.high_performance
. - [C-1-3] חובה לתמוך במצב ביצועים יציבים.
- [C-1-4] חובה שתהיה תמיכה ב-OpenGL ES 3.2.
- [C-1-5] חובה לתמוך ב-
android.hardware.vulkan.level
0. - המערכת אמורה לתמוך ב-
android.hardware.vulkan.level
1 ואילך. - [C-1-6] חובה להטמיע את התוספים
EGL_KHR_mutable_render_buffer
,EGL_ANDROID_front_buffer_auto_refresh
,EGL_ANDROID_get_native_client_buffer
,EGL_KHR_fence_sync
,EGL_KHR_wait_sync
,EGL_IMG_context_priority
,EGL_EXT_protected_content
,EGL_EXT_image_gl_colorspace
ולהציג אותם ברשימה של תוספי 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 לכל עין, ללא פגמים גלויים של קריעה.
- [C-1-9] חובה להטמיע תמיכה בדגלים
AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER
,AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA
ו-AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
שלAHardwareBuffer
כפי שמתואר ב-NDK. - [C-1-10] חובה להטמיע תמיכה ב-
AHardwareBuffer
עם כל שילוב של דגלי השימושAHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT
,AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE
,AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
לפחות בפורמטים הבאים:AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM
,AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM
,AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM
,AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT
. - [C-SR-5] מומלץ מאוד לתמוך בהקצאה של
AHardwareBuffer
s עם יותר משכבה אחת, ודגלים ופורמטים כפי שמפורטים ב-C-1-10. - [C-1-11] חובה לתמוך בפענוח H.264 ברזולוציה של לפחות 3840 x 2160 ב-30fps, דחוסה במהירות ממוצעת של 40Mbps (שווה ערך ל-4 מופעים של 1920 x 1080 ב-30fps-10Mbps או ל-2 מופעים של 1920 x 1080 ב-60fps-20Mbps).
- [C-1-12] חובה שתהיה תמיכה ב-HEVC וב-VP9, חובה שתהיה יכולת לפענח לפחות 1920 x 1080 בקצב 30fps באיכות דחוסה של 10Mbps בממוצע, ומומלץ שתהיה יכולת לפענח 3840 x 2160 בקצב 30fps-20Mbps (שווה ערך ל-4 מופעים של 1920 x 1080 בקצב 30fps-5Mbps).
- [C-1-13] חובה לתמוך ב-
HardwarePropertiesManager.getDeviceTemperatures
API ולהחזיר ערכים מדויקים של טמפרטורת העור. - [C-1-14] חייב לכלול מסך מוטמע, והרזולוציה שלו חייבת להיות לפחות 1920 x 1080.
- [C-SR-6] מומלץ מאוד שהרזולוציה של המסך תהיה לפחות 2560 x 1440.
- [C-1-15] התצוגה חייבת להתעדכן במהירות של לפחות 60 הרץ במצב VR.
- [C-1-17] המסך חייב לתמוך במצב של עמידות נמוכה עם עמידות של 5 אלפיות שנייה לכל היותר. העמידות מוגדרת כמשך הזמן שבו פיקסל פולט אור.
- [C-1-18] חובה לתמוך ב-Bluetooth 4.2 וב-Bluetooth LE Data Length Extension (הארכת אורך הנתונים של 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%.
- יכול להיות שהמעבד יספק ליבה בלעדית לאפליקציה שבחזית, ויכול להיות שהוא יתמוך ב-API
Process.getExclusiveCores
כדי להחזיר את המספרים של ליבות המעבד שהן בלעדיות לאפליקציה העליונה שבחזית.
אם יש תמיכה בליבה בלעדית, הליבה:
- [C-2-1] אסור לאפשר להריץ בה תהליכים אחרים במרחב המשתמש (למעט מנהלי התקנים שבהם האפליקציה משתמשת), אבל מותר לאפשר להריץ בה תהליכים מסוימים בליבה לפי הצורך.
7.10. מגע
יצירת דרישות חדשות
מכשירים שנועדו לנשיאה ביד או ללבישה עשויים לכלול מפעיל חישה (haptic) למטרות כלליות, שזמין לאפליקציות למטרות שונות, כולל למשוך תשומת לב באמצעות צלצולים, אזעקות והתראות, וגם למשוב כללי למגע.
אם הטמעות המכשירים לא כוללות מפעיל חישה (actuator) כזה למטרות כלליות, הן:
- [7.10/C] חובה להחזיר את הערך false עבור
Vibrator.hasVibrator()
.
אם הטמעות במכשירים כוללות לפחות אחד ממפעילים כאלה של משוב מישוש למטרות כלליות, הן:
- [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
, עם יחסי האמפליטודה המתאימים. - צריך להשתמש במיפויים האלה של קבועים הקטיפטיים המקושרים.
- צריך לפעול לפי הערכת האיכות של ממשקי ה-API של
createOneShot()
ושלcreateWaveform()
. - צריך לוודא שהתוצאה של ממשק ה-API הציבורי
android.os.Vibrator.hasAmplitudeControl()
משקפת בצורה נכונה את היכולות של הוויברטור. - צריך לאמת את היכולות של התאמת העוצמה לעומס על ידי הפעלת
android.os.Vibrator.hasAmplitudeControl()
.
אם הטמעות במכשירים פועלות בהתאם למיפוי של הקבועים ההדמיים, הן:
- צריך לאמת את סטטוס ההטמעה על ידי הפעלת ממשקי ה-API
android.os.Vibrator.areAllEffectsSupported()
ו-android.os.Vibrator.arePrimitivesSupported()
. - צריך לבצע בדיקת איכות של קבועים של משוב מישוש.
- צריך לאמת את הגדרת ברירת המחדל לפרימיטיבים שלא נתמכים ולעדכן אותה לפי הצורך, כפי שמתואר בהנחיות להטמעה של קבועים.
- צריך לספק תמיכה חלופית כדי לצמצם את הסיכון לכשל, כפי שמתואר כאן.
סיום הדרישות החדשות
הדרישות הספציפיות למכשיר מפורטות בקטע 2.2.1.
7.11. Media Performance Class
אפשר לקבל את סיווג הביצועים של המדיה בהטמעה במכשיר מ-android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
API. הדרישות לסיווג ביצועי המדיה מוגדרות לכל גרסת 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. ביצועי הגישה של File I/O
מתן בסיס משותף לביצועים עקביים של גישה לקבצים באחסון הנתונים הפרטי של האפליקציה (מחיצה /data
) מאפשר למפתחי האפליקציות להגדיר ציפיות מתאימות שיעזרו להם בתכנון התוכנה. בהטמעות במכשירים, בהתאם לסוג המכשיר, יכולות להיות דרישות מסוימות לפעולות הקריאה והכתיבה הבאות, כפי שמתואר בקטע 2:
- ביצועי כתיבת רצף. נמדד על ידי כתיבת קובץ בגודל 256MB באמצעות מאגר כתיבה של 10MB.
- ביצועי כתיבה אקראיים. נמדד על ידי כתיבת קובץ בגודל 256MB באמצעות מאגר כתיבה של 4KB.
- ביצועי קריאה רציפים. נמדד על ידי קריאת קובץ בגודל 256MB באמצעות מאגר כתיבה של 10MB.
- ביצועי קריאה אקראית. נמדד על ידי קריאת קובץ בגודל 256MB באמצעות מאגר כתיבה של 4KB.
8.3. מצבי חיסכון בסוללה
אם הטמעות במכשיר כוללות תכונות לשיפור ניהול צריכת החשמל במכשיר שנכללות ב-AOSP (למשל, 'קטגוריית סטטוס המתנה של אפליקציות', 'Doze') או אם התכונות מורחבות כך שיחולו הגבלות חזקות יותר מאשר קטגוריית סטטוס המתנה של אפליקציות מוגבלת, הן:
- [C-1-1] אסור לסטות מההטמעה של AOSP לגבי ההפעלה, התחזוקה, אלגוריתמי ההתעוררות והשימוש בהגדרות המערכת הגלובליות או ב-DeviceConfig של המצבים לחיסכון באנרגיה 'המתנה לאפליקציה' ו'דוז'.
- [C-1-2] אסור לסטות מההטמעה של AOSP לגבי השימוש בהגדרות גלובליות או ב-DeviceConfig לניהול הצמצום של משימות, התראות ורשתות באפליקציות בכל קטגוריה של מצב המתנה של אפליקציות.
- [C-1-3] אסור לסטות מההטמעה של AOSP לגבי מספר הקטגוריות של סטטוס 'אפליקציה במצב המתנה' שמשמש לסטטוס 'אפליקציה במצב המתנה'.
- [C-1-4] חובה להטמיע קטגוריות של אפליקציות במצב המתנה ו-Doze כפי שמתואר בקטע ניהול צריכת החשמל.
- [C-1-5] חובה להחזיר את הערך
true
עבורPowerManager.isPowerSaveMode()
כשהמכשיר במצב חיסכון בסוללה. - [C-1-6] חובה לספק למשתמשים אפשרות להציג את כל האפליקציות שמוחרגו ממצבי חיסכון באנרגיה 'המתנה לאפליקציה' ו'דוז', או מכל אופטימיזציות הסוללה, וחובה להטמיע את הכוונה ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS כדי לבקש מהמשתמשים לאפשר לאפליקציה להתעלם מאופטימיזציות הסוללה.
- [C-SR-1] מומלץ מאוד לספק למשתמשים אפשרות להפעיל ולהשבית את התכונה 'חיסכון בסוללה'.
- [C-SR-2] מומלץ מאוד לספק למשתמש אפשרות להציג את כל האפליקציות שפטורות ממצבי חיסכון באנרגיה 'המתנה לאפליקציה' ו'דוז'.
אם הטמעות במכשירים מרחיבות את תכונות ניהול צריכת האנרגיה שכלולות ב-AOSP, וההרחבה הזו חלה על הגבלות מחמירות יותר מאשר הקטגוריה 'אפליקציות נדירות במצב המתנה', יש לעיין בקטע 3.5.1.
בנוסף למצבי חיסכון באנרגיה, הטמעות של מכשירי Android עשויות ליישם כל אחד מ-4 מצבי השינה או את כולם, כפי שהוגדרו על ידי Advanced Configuration and Power Interface (ACPI).
אם הטמעות של מכשירים מטמיעות מצבי צריכת אנרגיה מסוג S4 כפי שמוגדרים ב-ACPI, הן:
- [C-1-1] המכשיר חייב לעבור למצב הזה רק אחרי שהמשתמש ביצע פעולה מפורשת כדי להעביר את המכשיר למצב לא פעיל (למשל, סגירת מכסה שהוא חלק פיזי מהמכשיר או כיבוי רכב או טלוויזיה) ולפני שהמשתמש מפעיל מחדש את המכשיר (למשל, פתיחת המכסה או הפעלה מחדש של הרכב או הטלוויזיה).
אם הטמעות של מכשירים מטמיעות מצבי צריכת אנרגיה של S3 כפי שמוגדרים ב-ACPI, הן:
[C-2-1] חובה לעמוד בתנאי של C-1-1 שלמעלה, או חובה להיכנס למצב S3 רק כשאפליקציות של צד שלישי לא זקוקות למשאבי המערכת (למשל המסך, המעבד).
לעומת זאת, חייבים לצאת ממצב S3 כשאפליקציות של צד שלישי זקוקות למשאבי המערכת, כפי שמתואר ב-SDK הזה.
לדוגמה, כשאפליקציות של צד שלישי מבקשות להשאיר את המסך דלוק דרך
FLAG_KEEP_SCREEN_ON
או להפעיל את המעבד דרךPARTIAL_WAKE_LOCK
, אסור שהמכשיר יעבור למצב S3, אלא אם המשתמש ביצע פעולה מפורשת כדי להעביר את המכשיר למצב לא פעיל, כפי שמתואר בקטע C-1-1. לעומת זאת, כשמשימה שאפליקציות צד שלישי מטמיעות דרך JobScheduler מופעלת או כשהודעות מ-Firebase Cloud Messaging מועברות לאפליקציות צד שלישי, המכשיר חייב לצאת ממצב S3, אלא אם המשתמש העביר את המכשיר למצב לא פעיל. אלה לא דוגמאות מקיפות, ו-AOSP מטמיע אותות התעוררות נרחבים שמפעילים התעוררות מהמצב הזה.
8.4. ניהול חשבונות של צריכת חשמל
דיווח וניהול חשבונות מדויקים יותר של צריכת החשמל מספקים למפתחי האפליקציות את התמריצים והכלים לביצוע אופטימיזציה של דפוס צריכת החשמל באפליקציה.
הטמעות במכשירים:
- [C-SR-1] מומלץ מאוד לספק פרופיל צריכת אנרגיה לכל רכיב, שמגדיר את ערך הצריכה הנוכחית של כל רכיב חומרה ואת הירידה המשוערת בנפח הסוללה שנגרמת על ידי הרכיבים לאורך זמן, כפי שמופיע באתר של Android Open Source Project.
- [C-SR-2] מומלץ מאוד לדווח על כל ערכי צריכת החשמל במיליאמפר-שעה (mAh).
- [C-SR-3] מומלץ מאוד לדווח על צריכת האנרגיה של המעבד (CPU) לכל מזהה משתמש (UID) של תהליך.
פרויקט הקוד הפתוח של Android עומד בדרישות באמצעות הטמעת מודול הליבה
uid_cputime
. - [C-SR-4] מומלץ מאוד להפוך את צריכת החשמל הזו לזמינה למפתח האפליקציה באמצעות הפקודה
adb shell dumpsys batterystats
של מעטפת. - צריך לשייך לרכיב החומרה עצמו אם אי אפשר לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.
8.5. ביצועים עקביים
הביצועים עשויים להשתנות באופן משמעותי באפליקציות עם ביצועים גבוהים שפועלות לאורך זמן, בין שבגלל האפליקציות האחרות שפועלות ברקע ובין שבגלל צמצום המהירות של המעבד עקב מגבלות טמפרטורה. מערכת Android כוללת ממשקים פרוגרמטיים, כך שאם המכשיר מסוגל, האפליקציה העיקרית בחזית יכולה לבקש מהמערכת לבצע אופטימיזציה של הקצאת המשאבים כדי להתמודד עם תנודות כאלה.
הטמעות במכשירים:
[C-0-1] חובה לדווח בצורה מדויקת על התמיכה במצב ביצועים יציבים באמצעות שיטת ה-API
PowerManager.isSustainedPerformanceModeSupported()
.צריכה להיות תמיכה במצב 'ביצועים יציבים'.
אם הטמעות במכשירים מדווחות על תמיכה במצב ביצועים יציבים, הן:
- [C-1-1] חובה לספק לאפליקציה העיקרית בחזית רמת ביצועים עקבית למשך 30 דקות לפחות, כשהאפליקציה מבקשת זאת.
- [C-1-2] חובה לפעול בהתאם לממשק ה-API של
Window.setSustainedPerformanceMode()
ולממשקי API קשורים אחרים.
אם הטמעות במכשירים כוללות שני ליבות מעבד או יותר, הן:
- צריך לספק לפחות ליבה אחת בלעדית שאפשר לשמור לשימוש של האפליקציה העיקרית בחזית.
אם הטמעות במכשירים תומכות בהקצאת ליבה אחת בלעדית לאפליקציה העיקרית בחזית, הן:
- [C-2-1] חובה לדווח באמצעות שיטת ה-API
Process.getExclusiveCores()
על מספרי המזהים של הליבות הייעודיות שאפשר להקצות לאפליקציה העיקרית שבחזית. - [C-2-2] אסור לאפשר תהליכים במרחב המשתמש, מלבד מנהלי ההתקנים שבהם האפליקציה משתמשת כדי לפעול בליבות הבלעדיות, אבל מותר לאפשר להפעיל תהליכים מסוימים בליבה לפי הצורך.
אם הטמעות במכשירים לא תומכות בליבה בלעדית, הן:
- [C-3-1] חובה להחזיר רשימה ריקה באמצעות שיטת ה-API
Process.getExclusiveCores()
.
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. באופן ספציפי, הם חייבי