1. מבוא
במסמך הזה מפורטות הדרישות שצריכות להתקיים כדי שיהיו מכשירים שתואם ל-Android 15.
השימוש ב: "חובה", "אסור", "נדרש", "צריך", "אסור", "צריך", 'אסור', 'מומלץ', 'מאי' ו'אופציונלי' בהתאם לתקן IETF מוגדר ב-RFC2119.
כפי שנעשה בו שימוש במסמך הזה, הכלי 'מטמיע מכשירים' או 'כלי יישום' הוא אדם או ארגון המפתח פתרון חומרה/תוכנה שמפעיל את Android 15. 'הטמעה במכשיר' או 'הטמעה' האם הערך חומרה/תוכנה כך שפיתחו.
כדי לקבוע מכשיר שמתאים ל-Android 15, היישומים חייבים לעמוד בדרישות המוצגות בתנאי התאימות הגדרה, כולל כל מסמך שמאוחד באמצעות הפניה.
כאשר ההגדרה הזו או בדיקות התוכנה שמתוארות ב סעיף 10 שקט, לא ברור או לא הושלמה, באחריות מטמיע המכשיר לוודא תאימות להטמעות קיימות.
לכן, פרויקט הקוד הפתוח של Android הוא גם ההפניה וגם ההטמעה המועדפת של Android. Device (מכשיר) מומלץ מאוד לבסס את ההטמעות שלהם במידה הרבה ביותר האפשרית ב-upstream את קוד המקור הזמין פרויקט קוד פתוח של Android. למרות שרכיבים מסוימים יכולים באופן היפותטי להחליף אותן בהטמעות חלופיות, מומלץ מאוד לפעול בהתאם לתקנה הזו, כי המעבר של בדיקות התוכנה ייפגע לקשה יותר. באחריות המיישם לדאוג במלואו תאימות התנהגותית להטמעה הרגילה של Android, כולל וגם מעבר לחבילה לבדיקת התאימות. לבסוף, שימו לב שרכיבים מסוימים החלפות ושינויים אסורים באופן מפורש במסמך זה.
רבים מהמשאבים המקושרים במסמך הזה נגזרים באופן ישיר או בעקיפין מ-Android SDK והוא יהיה זהה מבחינה פונקציונלית במאמרי העזרה של ערכת ה-SDK הזו. בכל המקרים שבהם התאימות הזו הגדרה או חוסר התאמה בין החבילה לבדיקת התאימות ל-SDK בתיעוד של ה-SDK, תיעוד ה-SDK נחשב כמקור מהימן. כל מידע טכני הפרטים שבמקורות המידע המקושרים במסמך הזה מובאת בחשבון כחלק מהגדרת התאימות הזו.
1.1 מבנה המסמך
1.1.1. דרישות לפי סוג המכשיר
סעיף 2 כולל את כל הדרישות שחלות על סוג מכשיר ספציפי. כל סעיף משנה של סעיף 2 שמיועד לסוג מכשיר ספציפי.
כל שאר הדרישות, שחלות באופן אוניברסלי על כל מכשיר Android והטמעות, מפורטות בסעיפים אחרי סעיף 2. הדרישות האלה נכללות כ"דרישות ליבה" במסמך הזה.
1.1.2. מזהה דרישה
מזהה הדרישה הוקצה לדרישות.
- המזהה מוקצה לדרישות חובה בלבד.
- הדרישות המומלצות מאוד מסומנות כ-[SR] אבל המזהה לא הוקצה.
- המזהה מורכב מהפרטים הבאים : מזהה סוג המכשיר – מזהה תנאי – מזהה דרישה (למשל C-0-1).
כל מזהה מוגדר כך:
- מזהה סוג המכשיר (מידע נוסף זמין ב-2. סוגי מכשירים)
- ג: ליבה (דרישות שחלות על כל ההטמעות של מכשירי Android)
- H: מכשיר נייד עם Android
- T: מכשיר Android TV
- תשובה: הטמעת 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 אינץ' עד 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
להיות זמין לאפליקציות צד שלישי על גבי אזור תצוגה פיזי בגודל 2.2 אינץ' לפחות אינץ' בקצה הקצר ו-3.4 אינץ' בקצה הארוך.[7.1.1.3/H-0-1]* חייבים להגדיר את הערך של
DENSITY_DEVICE_STABLE
לערך 92% או יותר מהצפיפות הפיזית בפועל של המסך המתאים.
אם הטמעות של מכשירים ניידים כוללות תמיכה ב-Vulkan:
- [7.1.4.2/H-1-1] חייב לעמוד בדרישות שצוינו בפרופיל Android Baseline 2021.
אם בהטמעות של מכשירים ניידים יש תמיכה בטווח דינמי גבוה
מוצג באמצעות Configuration.isScreenHdr()
,
הם:
- [7.1.4.5/H-1-1] חובה לפרסם תמיכה
EGL_EXT_gl_colorspace_bt2020_pq
,EGL_EXT_surface_SMPTE2086_metadata
EGL_EXT_surface_CTA861_3_metadata
,VK_EXT_swapchain_colorspace
וגםVK_EXT_hdr_metadata
תוספים.
הטמעות של מכשירים ניידים:
- [7.1.4.6/H-0-1] חובה לדווח אם המכשיר
תומך ביכולת הפרופיילינג של ה-GPU דרך מאפיין מערכת
graphics.gpu.profiler.support
.
אם הטמעות של מכשירים ניידים מוצהרות על תמיכה דרך מאפיין מערכת
graphics.gpu.profiler.support
, הן:
- [7.1.4.6/H-1-1] חובה לדווח כפלט מעקב Protobuf שתואם לסכימה של מוני GPU ו-GPU שלבי העיבוד (re אונלייןs) שמוגדרים במסמכי התיעוד של Perfetto.
- [7.1.4.6/H-1-2] חובה לדווח על ערכים תואמים למוני ה-GPU של המכשיר פרוטו של חבילת מעקב נגדי gpu.
- [7.1.4.6/H-1-3] חובה לדווח על ערכים תואמים ל-GPU RenderStages של המכשיר אחרי עיבוד של אובייקט מנות למעקב אחרי שלב.
- [7.1.4.6/H-1-4] חובה לדווח על תדירות GPU trackpoint כפי שצוין בפורמט: power/gpu_frequency.
הטמעות של מכשירים ניידים:
- [7.1.5/H-0-1] חייבת לכלול תמיכה במכשירים מדור קודם מצב תאימות של אפליקציה כפי שמוטמע על ידי ה-upstream הפתוחה של Android קוד המקור. כלומר, אסור שהטמעות במכשירים ישנו את הטריגרים שבהם מופעל מצב תאימות, ואסור לשנות את של מצב התאימות עצמו.
- [7.2.1/H-0-1] חייבת לכלול תמיכה בצדדים שלישיים אפליקציות לעריכת שיטות קלט (IME).
- [7.2.3/H-0-2] חייבים לשלוח גם בלחיצה רגילה וגם בלחיצה ארוכה
אירוע של פונקציית 'הקודם' (
KEYCODE_BACK
) לאפליקציה בחזית. המערכת לא יכולה להשתמש באירועים האלה יכול להיות מופעל על ידי מחוץ למכשיר Android (למשל חומרה חיצונית). המקלדת המחוברת למכשיר Android). - [7.2.3/H-0-3] חייבים לספק את הפונקציה 'בית' ב- כל המסכים התואמים ל-Android שמספקים את מסך הבית.
- [7.2.3/H-0-4] חייבים לספק את פונקציית החזרה בכל המכשירים במסכים התואמים ל-Android ובפונקציה 'אחרונים' לפחות במסכים שתואמים ל-Android.
- [7.2.4/H-0-1] חייב לתמוך בקלט מסך מגע.
- [7.2.4/H-SR-1] מומלץ מאוד להפעיל את
אפליקציית עזרה שהמשתמש בוחר. כלומר, האפליקציה שמטמיעה
VoiceInteractionService או פעילות המטפלת ב-
ACTION_ASSIST
בלחיצה ארוכה עלKEYCODE_MEDIA_PLAY_PAUSE
אוKEYCODE_HEADSETHOOK
אם הפעילות בחזית לא מטפלת באירועים האלה בלחיצה ארוכה. - [7.3.1/H-SR-1] מומלץ מאוד לכלול תמונה עם 3 צירים מד תאוצה.
אם יישומים של מכשירים ניידים כוללים מד תאוצה ב-3 צירים:
- [7.3.1/H-1-1] חייבת להיות אפשרות לדווח על אירועים בתדירות של עד של לפחות 100Hz.
אם יישומים של מכשירים ניידים כוללים מקלט GPS/GNSS ומדווחים על
יכולת לאפליקציות באמצעות התכונה android.hardware.location.gps
הם:
- [7.3.3/H-2-1] חובה לדווח על מדידות GNSS ברגע שהן נמצאים, גם אם המיקום המחושב מ-GPS/GNSS עדיין לא דווח.
- [7.3.3/H-2-2] חובה לדווח על GNSS על מערכים של פסאודוטווח (pseudoranges) ו-pseudoranges בתנאים של שמיים פתוחים לאחר קביעת המיקום, קבוע או נע עם פחות מ-0.2 מטר לשנייה בריבוע תאוצה מספיקה כדי לחשב את המיקום בטווח של 20 מטרים, בטווח של 0.2 מטר לשנייה, לפחות ב-95% מהזמן.
אם מוטמעים במכשיר נייד ג'ירוסקופ עם 3 צירים:
- [7.3.4/H-3-1] חייבת להיות אפשרות לדווח על אירועים בתדירות של עד של לפחות 100Hz.
- [7.3.4/H-3-2] חייבת להיות יכולת למדוד שינויי כיוון עד 1,000 מעלות לשנייה.
יישומים של מכשירים ניידים שמאפשרים לבצע שיחה קולית ולציין
כל ערך מלבד PHONE_TYPE_NONE
ב-getPhoneType
:
- [7.3.8/H] צריכה לכלול חיישן קירבה.
הטמעות של מכשירים ניידים:
- [7.3.11/H-SR-1] מומלץ מאוד לתמוך בחיישן התנוחה עם 6 דרגות חופש.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם המכשירים תומכים בפרוטוקול Wi-Fi Neighbor Awareness Networking (NAN) על ידי
הצהרה על PackageManager.FEATURE_WIFI_AWARE
ועל מיקום Wi-Fi (עגול Wi-Fi
זמן נסיעה – RTT) על ידי הצהרה על PackageManager.FEATURE_WIFI_RTT
, ואז:
[7.4.2.5/H-1-1] חובה לדווח על הטווח באופן מדויק: בטווח של +/-1 מטר ברוחב פס של 160MHz באחוזון ה-68 (כפי מחושב באמצעות פונקציית ההפצה המצטברת), +/-2 מטרים ברוחב פס של 80MHz האחוזון ה-68, +/-4 מטרים ברוחב פס של 40 MHz באחוזון ה-68, ו- +/-8 מטרים ברוחב פס של 20MHz באחוזון ה-68 במרחקים של 10 MHz ס"מ, 1 מ', 3 מ' ו-5 מ', כפי שניתן לראות ב- Wi-FiRttManager#startRanging Android API.
[7.4.2.5/H-SR-1] מומלץ מאוד לדווח על טווח מדויק בטווח של +/-1 מטר ברוחב פס של 160MHz ב-90 אחוזון (כפי שחושב באמצעות פונקציית ההתפלגות המצטברת), +/-2 מטרים ברוחב פס של 80MHz באחוזון 90, +/-4 מטרים ב-40MHz רוחב פס באחוזון ה-90, ו-+/-8 מטרים ברוחב פס של 20 מגה-הרץ האחוזון ה-90 במרחקים של 10 ס"מ, כפי שניתן לראות בעזרת Wi-FiRttManager#startRanging Android API.
מומלץ מאוד לבצע את השלבים להגדרת המדידה שמפורטים כיול הנוכחות.
אם מוצהר על FEATURE_BLUETOOTH_LE
על הטמעות של מכשירים ניידים, הן:
- [7.4.3/H-1-3] חובה למדוד ולפצות על Rx
כדי להבטיח שהחציון RSSI של BLE הוא -50dBm +/-15dB במרחק של 1 מ'
מכשיר הייחוס משודר ב-
ADVERTISE_TX_POWER_HIGH
. - [7.4.3/H-1-4] חובה למדוד ולפצות על Tx
כדי להבטיח שהחציון RSSI של BLE הוא -50dBm +/-15dB בסריקה
מכשיר עזר ממוקם במרחק 1 מטר ומשדר ב
ADVERTISE_TX_POWER_HIGH
.
אם הטמעות של מכשירים להחזקה ביד כוללות התקן מצלמה לוגי שמפרט
יכולות באמצעות
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
הם:
- [7.5.4/H-1-1] חייב להיות שדה ראייה רגיל (FOV) כברירת מחדל והוא חייב להיות בין 50 מעלות.
הטמעות של מכשירים ניידים:
- [7.6.1/H-0-1] חייבים להיות לפחות 4GB של אחסון בלתי תנודתי שזמין לנתונים פרטיים של האפליקציה (שנקראת גם מחיצת "/data" ).
- [7.6.1/H-0-2] חייב להחזיר "true" עבור
ActivityManager.isLowRamDevice()
כשיש פחות מ-1GB בזיכרון זמינים לליבה ולמרחב המשתמשים.
אם הטמעות במכשירים ניידים מצהירות על תמיכה ב-ABI של 32 ביט בלבד:
[7.6.1/H-1-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות 416MB לפחות אם תצוגת ברירת המחדל משתמשת במאגר נתונים זמני רזולוציה של עד qHD (למשל FWVGA).
[7.6.1/H-2-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות 592MB לפחות אם תצוגת ברירת המחדל משתמשת במאגר נתונים זמני רזולוציה של עד HD+ (למשל HD, WSVGA).
[7.6.1/H-3-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות בגודל 896MB לפחות אם בתצוגת ברירת המחדל נעשה שימוש במאגר נתונים זמני ברזולוציה של עד FHD (למשל WSXGA+ ).
[7.6.1/H-4-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות 1344MB לפחות אם תצוגת ברירת המחדל משתמשת רזולוציות של מאגרי נתונים זמניים עד QHD (למשל QWXGA).
אם הטמעות במכשירים ניידים מוצהרות על תמיכה בכל ממשק ABI של 64 ביט (עם או בלי ממשק ABI של 32 ביט):
[7.6.1/H-5-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות יהיה 816MB לפחות אם במסך ברירת המחדל נעשה שימוש ברזולוציות של מאגר נתונים זמני למעלה ל-qHD (למשל FWVGA).
[7.6.1/H-6-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות לפחות 944MB אם צג ברירת המחדל משתמש ברזולוציות של מאגר נתונים זמני עד HD+ (למשל: HD, WSVGA).
[7.6.1/H-7-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות לפחות 1280MB אם מסך ברירת המחדל משתמש ברזולוציית מאגר נתונים זמני של עד FHD (למשל WSXGA+ ).
[7.6.1/H-8-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות לפחות 1824MB אם צג ברירת המחדל משתמש ברזולוציית מאגר נתונים זמני של עד QHD (למשל, QWXGA).
שימו לב ש"הזיכרון שזמין לליבה ולמרחב המשתמשים" שלמעלה מתייחס מקום זיכרון בנוסף לכל זיכרון שכבר מיועד לחומרה כמו רדיו, וידאו וכו', שלא נמצאים במסגרת הליבה שליטה בהטמעות של מכשירים.
אם הטמעות במכשירים ניידים כוללות נפח זיכרון של 1GB או פחות זמינים לליבה ולמרחב המשתמשים, הם:
- [7.6.1/H-9-1] חובה להצהיר על דגל התכונה
android.hardware.ram.low
. - [7.6.1/H-9-2] חייב להיות לפחות 1.1GB של אחסון בלתי נדיף לאפליקציה מידע פרטי (שנקרא גם "מחיצה "/data").
אם הטמעות במכשירים ניידים כוללות יותר מ-1GB של זיכרון פנוי לליבה ולמרחב המשתמשים, הם:
- [7.6.1/H-10-1] חייב להיות בנפח של 4GB לפחות אחסון בלתי נדיף זמין מידע פרטי של האפליקציה (שנקראת גם מחיצה ' /data').
- יש להצהיר על דגל התכונה
android.hardware.ram.normal
.
אם הטמעות במכשירים ניידים כוללות נפח של 2GB או גדול יותר ופחות מ-4GB של זיכרון פנוי ליבה ולמרחב המשתמש, הם:
- [7.6.1/H-SR-1] מומלץ מאוד לתמוך במרחב משתמשים של 32 ביט בלבד (גם אפליקציות וגם קוד מערכת)
אם הטמעות במכשירים ניידים כוללות פחות מ-2GB של זיכרון פנוי את הליבה ומרחב המשתמשים:
- [7.6.1/H-1-1] חייב לתמוך רק ב-ABI אחד (64 ביט בלבד או 32 ביט) בלבד).
הטמעות של מכשירים ניידים:
- [7.6.2/H-0-1] אסור להגיש בקשה נפח אחסון משותף של פחות מ-1GiB.
- [7.7.1/H] צריכה לכלול יציאת USB שתומכת במצב היקפי.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם הטמעות של מכשירים ניידים כוללות יציאת USB
תמיכה
באמצעות שלט רחוק שפועל בתוך
במצב של ציוד היקפי:
- [7.7.1/H-1-1] חובה להטמיע את Android Open Accessory (AOA) API.
סיום הדרישות החדשות
אם הטמעות של מכשירים ניידים כוללות יציאת USB שתומכת במצב מארח, הם:
- [7.7.2/H-1-1] חובה להטמיע את סיווג האודיו בחיבור USB כפי שמתועד בתיעוד של Android SDK.
הטמעות של מכשירים ניידים:
- [7.8.1/H-0-1] חייב לכלול מיקרופון.
- [7.8.2/H-0-1] חייב להיות פלט אודיו וצריך להצהיר עליו
android.hardware.audio.output
.
אם הטמעות של מכשירים ניידים מסוגלות לעמוד בכל הביצועים הדרישות לתמיכה במצב VR וכוללות תמיכה במצב הזה, הן:
- [7.9.1/H-1-1] חובה להצהיר על
סימון תכונה
android.hardware.vr.high_performance
. - [7.9.1/H-1-2] חובה לכלול בקשה
הטמעה של
android.service.vr.VrListenerService
שניתן להפעיל באמצעות VR בקשות דרךandroid.app.Activity#setVrModeEnabled
.
אם בהטמעות של מכשירים ניידים יש יציאת USB-C אחת או יותר במארח למצב ולהטמיע (סיווג אודיו ב-USB), בנוסף לדרישות 7.7.2:
- [7.8.2.2/H-1-1] חייב לספק את מיפוי התוכנה הבא של קודי ממשק אנושי:
פעולה | מיפויים | הקשר | התנהגות |
---|---|---|---|
A | דף שימוש במכשיר HID: 0x0C שימוש ב-HID: 0x0CD מפתח ליבה: KEY_PLAYPAUSE מפתח Android: KEYCODE_MEDIA_PLAY_PAUSE |
הפעלת מדיה | קלט: לחיצה קצרה פלט: הפעלה או השהיה |
קלט: לחיצה ארוכה על פלט: הפעלת פקודה קולית שליחה: android.speech.action.VOICE_SEARCH_HANDS_FREE אם המכשיר
נעול או כשהמסך כבוי. שולח
אחרת, android.speech.RecognizerIntent.ACTION_WEB_SEARCH |
|||
שיחה נכנסת | קלט: לחיצה קצרה פלט: קבלת השיחה |
||
קלט: לחיצה ארוכה על פלט: דחיית השיחה |
|||
שיחה פעילה | קלט: לחיצה קצרה פלט: סיום השיחה |
||
קלט: לחיצה ארוכה על פלט: השתקה או ביטול ההשתקה של המיקרופון |
|||
B | דף שימוש במכשיר HID: 0x0C שימוש ב-HID: 0x0E9 מפתח ליבה: KEY_VOLUMEUP מפתח Android: VOLUME_UP |
הפעלת מדיה, שיחה פעילה | קלט: לחיצה קצרה או ארוכה פלט: מגדיל את עוצמת הקול של המערכת או של האוזניות |
C | דף שימוש במכשיר HID: 0x0C שימוש במכשיר ממשק אנושי (HID): 0x0EA מפתח ליבה: KEY_VOLUMEDOWN מפתח Android: VOLUME_DOWN |
הפעלת מדיה, שיחה פעילה | קלט: לחיצה קצרה או ארוכה פלט: הפחתת עוצמת הקול של המערכת או האוזניות |
D | דף שימוש במכשיר HID: 0x0C שימוש ב-HID: 0x0CF מפתח ליבה: KEY_VOICECOMMAND מפתח Android: KEYCODE_VOICE_ASSIST |
כל ההתראות. ניתן להפעיל בכל מקרה. | קלט: לחיצה קצרה או ארוכה פלט: הפעלת פקודה קולית |
- [7.8.2.2/H-1-2] חייב להפעיל את ACTION_HEADSET_PLUG בזמן כניסת תקע, אבל רק לאחר שממשקי האודיו ונקודות הקצה ב-USB נספר בצורה נכונה כדי לזהות את סוג הטרמינל המחובר.
כשהמערכת מזהה את טרמינל האודיו 0x0302 של USB, הוא:
- [7.8.2.2/H-2-1] חייב לשדר את ה-Intent ACTION_HEADSET_PLUG עם 'מיקרופון' מוגדר ל-0.
כשהמערכת מזהה את טרמינל האודיו 0x0402 של USB, הוא:
- [7.8.2.2/H-3-1] חייב לשדר את ה-Intent ACTION_HEADSET_PLUG עם 'מיקרופון' מוגדר ל-1.
כאשר מתבצעת קריאה ל-API AudioManager.getDevices() כשהציוד ההיקפי ב-USB מופעל קישרו אותו:
[7.8.2.2/H-4-1] חובה לציין מכשיר מסוג AudioDeviceInfo.TYPE_USB_HEADSET והתפקיד
isSink()
אם השדה של סוג הטרמינל של אודיו ב-USB הוא 0x0302.[7.8.2.2/H-4-2] חובה לציין מכשיר מסוג סוג AudioDeviceInfo.TYPE_USB_HEADSET ותפקיד
isSink()
אם מסוף האודיו USB שדה הסוג הוא 0x0402.[7.8.2.2/H-4-3] חובה לציין מכשיר מסוג סוג AudioDeviceInfo.TYPE_USB_HEADSET ותפקיד
isSource()
אם מסוף האודיו USB שדה הסוג הוא 0x0402.[7.8.2.2/H-4-4] חייב להופיע מכשיר מסוג AudioDeviceInfo.TYPE_USB_DEVICE והתפקיד
isSink()
אם השדה של סוג הטרמינל של אודיו ב-USB הוא 0x603.[7.8.2.2/H-4-5] חובה לציין מכשיר מסוג סוג AudioDeviceInfo.TYPE_USB_DEVICE ותפקיד
isSource()
אם מסוף האודיו USB שדה הסוג הוא 0x604.[7.8.2.2/H-4-6] חובה לציין מכשיר מסוג סוג AudioDeviceInfo.TYPE_USB_DEVICE ותפקיד
isSink()
אם סוג מסוף האודיו USB הוא 0x400.[7.8.2.2/H-4-7] חובה לציין מכשיר מסוג סוג AudioDeviceInfo.TYPE_USB_DEVICE ותפקיד
isSource()
אם מסוף האודיו USB שדה הסוג הוא 0x400.[7.8.2.2/H-SR-1] מומלץ מאוד לאחר חיבור של ציוד היקפי לאודיו מסוג USB-C, לביצוע ספירה של תיאורי USB, זיהוי סוגי מסופים ו-Intent שידור ACTION_HEADSET_PLUG תוך 1,000 אלפיות השנייה.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם
עבור
הטמעות של מכשירים ניידים
שמצהירים בהן
android.hardware.audio.output
וגם android.hardware.microphone
,
הם:
מידע נוסף על הדרישות לגבי RTL ו-TTL זמין בקטע
5.6.
[5.6/H-1-1] חייבת להיות נסיעה רציפה ממוצעת של 300 אלפיות שנייה או פחות מ-5 מדידות, עם סטייה אבסולוטית ממוצעת קטנה מ- 30 אלפיות השנייה, מעל את נתיבי הנתונים הבאים: "רמקול למיקרופון", מתאם לולאת חזרה 3.5 מ"מ (אם נתמך), לולאה חוזרת ב-USB (אם נתמך).
ל-[5.6/H-1-2] נדרש זמן אחזור ממוצע של הקשה לכוונון של 300 אלפיות שנייה, או לפחות 5 מדידות מהרמקול לנתיב הנתונים של המיקרופון.
סיום הדרישות החדשות
אקטואטור תהודה ליניארי (LRA) הוא מערכת קפיץ בעלת מסה יחידה בעלת תדר תהודה דומיננטי שבו המסה מתורגמת בכיוון בתנועה הרצויה.
אם הטמעות של מכשירים ניידים כוללות לפחות מטרה כללית אחת 7.10 אקטואטור תהודה ליניארית, הם:
[7.10/H] צריך למקם את המיקום של האקטואטור ליד המיקום שבו בדרך כלל מחזיקים את המכשיר או נוגעים בו בידיים.
[7.10/H] צריך להזיז את האקטואטור הפיזי בציר ה-X (בצד שמאל) בכיוון הטבעי של המכשיר.
אם להטמעות של מכשירים ניידים יש מטרה כללית אקטואטור פיזי, שהוא מפעיל תהודה לינארית בציר ה-X (LRA), הוא:
- [7.10/H] תדר התהודה של ה-LRA בציר ה-X צריך להיות קטן מ-200 Hz.
אם הטמעות של מכשירים ניידים מתבצעות בהתאם למיפוי של קבועים פיזיים, הן:
- [7.10/H]* צריך לאמת את סטטוס ההטמעה על ידי הרצה של android.os.Vibrator.areAllמיקוםsSupported() ו-android.os.Vibrator.arePrimitivesSupported() ממשקי API.
[7.10/H]* צריכה לבצע הערכת איכות קבועים פיזיים.
[7.10/H]* צריך לאמת ולעדכן את החלופה לפי הצורך של פרימיטיביים שאינם נתמכים כפי שמתואר הדרכה להטמעת מודעות קבועים.
2.2.2. מולטימדיה
הטמעות של מכשירים ניידים חייבות לתמוך בקידוד האודיו הבא וב והפיכתם לזמינים לאפליקציות של צד שלישי:
- [5.1/H-0-1] AMR-NB
- [5.1/H-0-2] AMR-WB
- [5.1/H-0-3] MPEG-4 AAC Profile (AAC LC)
- [5.1/H-0-4] MPEG-4 HE AAC Profile (AAC+)
- [5.1/H-0-5] AAC ELD (משופר עבור השהיה נמוכה AAC)
הטמעות של מכשירים ניידים חייבות לתמוך בקידוד הווידאו הבא כדי שיהיו זמינים לאפליקציות של צד שלישי:
הטמעות של מכשירים ניידים חייבות לתמוך בפענוח הקוד הבא של סרטונים כדי שיהיו זמינים לאפליקציות של צד שלישי:
- [5.3/H-0-1] H.264 AVC
- [5.3/H-0-2] H.265 HEVC
- [5.3/H-0-3] MPEG-4 SP
- [5.3/H-0-4] VP8
- [5.3/H-0-5] VP9
- [5.3/H-0-6] AV1
2.2.3. תוכנות
הטמעות של מכשירים ניידים:
- [3.2.3.1/H-0-1] חייב להיות
האפליקציה שמטפלת ב-
ACTION_GET_CONTENT
,ACTION_OPEN_DOCUMENT
,ACTION_OPEN_DOCUMENT_TREE
, וגםACTION_CREATE_DOCUMENT
את כוונות ה-SDK כפי שמתואר במסמכי ה-SDK, ומספקות למשתמש מחיר יקר לצורך גישה לנתונים של ספק המסמכים באמצעותDocumentsProvider
API. - [3.2.3.1/H-0-2]* חייבים לטעון אחד מראש או יותר אפליקציות או רכיבי שירות עם handler של Intent, כל הדפוסים של סינון Intent ציבורי שהוגדרו על ידי האפליקציה הבאה ה-Intents שמפורטים כאן.
- [3.2.3.1/H-SR-1] הם קפדניים מומלץ לטעון מראש אפליקציית אימייל שיכולה לטפל ב-ACTION_SENDTO או ACTION_SEND או ACTION_SEND_MULTIPLE מנסה לשלוח אימייל.
- [3.4.1/H-0-1] חובה לספק דירוג מלא
של ה-API של
android.webkit.Webview
. - [3.4.2/H-0-1] חייב לכלול דפדפן נפרד עבור גלישה כללית של משתמשים באינטרנט.
- [3.8.1/H-SR-1] מומלץ מאוד כדי להטמיע מרכז אפליקציות שמוגדר כברירת מחדל שתומך בהצמדת קיצורי דרך בתוך האפליקציה, ווידג'טים ו-widgetFeatures.
- [3.8.1/H-SR-2] מומלץ מאוד כדי להטמיע מרכז אפליקציות המשמש כברירת מחדל שמספק גישה מהירה לתכונות קיצורי דרך שמסופקים על ידי אפליקציות צד שלישי דרך ShortcutManager API.
- [3.8.1/H-SR-3] מומלץ מאוד כדי לכלול אפליקציית מרכז אפליקציות שמוגדרת כברירת מחדל שמציגה תגים של סמלי האפליקציות.
- [3.8.2/H-SR-1] מומלץ מאוד כדי לתמוך בווידג'טים של אפליקציות צד שלישי.
- [3.8.3/H-0-1] חובה לאפשר צד שלישי
של אפליקציות שיודיעו למשתמשים על אירועים חשובים באמצעות
Notification
NotificationManager
מחלקות API. - [3.8.3/H-0-2] חייבת להיות תמיכה עשירה התראות.
- [3.8.3/H-0-3] חובה ליידע את התמיכה התראות.
- [3.8.3/H-0-4] חייב לכלול קישור לוח התראות, שמאפשר למשתמש לשלוט באופן ישיר (למשל, מענה, לטיפול בהמשך, ביטול, חסימה) על ידי המשתמש מבחינת תקציב, כמו או את לוח הבקרה כפי שהם מוטמעים ב-AOSP.
- [3.8.3/H-0-5] חובה להציג את האפשרויות
סופק באמצעות
RemoteInput.Builder setChoices()
בלוח ההתראות. - [3.8.3/H-SR-1] מומלץ מאוד
כדי להציג את האפשרות הראשונה שמסופקת דרך
RemoteInput.Builder setChoices()
בלוח ההתראות, ללא פעולה נוספת מצד המשתמש. - [3.8.3/H-SR-2] מומלץ מאוד
כדי להציג את כל האפשרויות שסופקו דרך
RemoteInput.Builder setChoices()
בלוח ההתראות כשהמשתמש מרחיב את כל ההתראות לוח ההתראות. - [3.8.3.1/H-SR-1] מומלץ מאוד
כדי להציג פעולות שעבורן
Notification.Action.Builder.setContextual
מוגדר כ-true
בשרשור עם התשובות שמוצגות על ידיNotification.Remoteinput.Builder.setChoices
. - [3.8.4/H-SR-1] מומלץ מאוד כדי להטמיע עוזר דיגיטלי במכשיר שיטפל בפעולת ה-Assist.
אם יישומים של מכשירים ניידים תומכים בהתראות MediaStyle הם:
- [3.8.3.1/H-SR-2] מומלץ מאוד
כדי לספק למשתמש אפשרות למחיר מסוים (לדוגמה, מתג להחלפת פלט) שמתבצעת אליו גישה
ממשק המשתמש של המערכת שמאפשר למשתמשים לעבור בין המדיה הזמינה המתאימה
מסלולים (לדוגמה, מכשירי Bluetooth ומסלולים שסופקו ל-
MediaRouter2Manager
) כשאפליקציה מפרסמת התראתMediaStyle
עם אסימוןMediaSession
.
אם בהטמעות במכשירים, כולל מקש הניווט של הפונקציה האחרונה בתור המפורטים בסעיף 7.2.3 משנים את הממשק, הם:
- [3.8.3/H-1-1] חובה להטמיע את המסך את התנהגות ההצמדה ולספק למשתמש תפריט הגדרות כדי שיוכלו להחליף מצב. .
אם הטמעות של מכשירים ניידים תומכות בפעולת Assist:
- [3.8.4/H-SR-2] מומלץ מאוד
כדי להשתמש בלחיצה ארוכה על המקש
HOME
בתור האינטראקציה הייעודית להפעלת לאפליקציית העוזר הדיגיטלי, כפי שמתואר בסעיף 7.2.3. חובה להפעיל אפליקציית העזרה שהמשתמש בחר. כלומר האפליקציה שמטמיעהVoiceInteractionService
, או פעילות שמטפלת בהכוונה שלACTION_ASSIST
.
אם יש תמיכה בהטמעות של מכשירים ניידים conversation notifications
ולקבץ אותם לקטע נפרד מהתראות ולא משיחות שקטות.
התראות:
- [3.8.4/H-1-1]* חייב להיות מסך התראות על שיחות לפני התראות על הודעות שאינן שיחה עם למעט התראות מתמשכות בנוגע לשירות שפועל בחזית חשיבות:high התראות.
אם בהטמעות של מכשירי Android ניידים יש תמיכה במסך נעילה:
- [3.8.10/H-1-1] חייבים להציג את סמל המנעול התראות במסך, כולל התבנית של התראות מדיה.
אם בהטמעות של מכשירים ניידים יש תמיכה במסך נעילה מאובטח:
- [3.9/H-1-1] חייבים להטמיע את הטווח המלא של ניהול מכשירים לכללי המדיניות שמוגדרים במסמכי התיעוד של Android SDK.
אם הטמעות של מכשירים ניידים כוללות תמיכה
ControlsProviderService
ו-Control
ממשקי API שמאפשרים לאפליקציות של צד שלישי לפרסם אמצעי בקרה במכשירים, ואז:
- [3.8.16/H-1-1] חובה להצהיר על התכונה
דיווח
android.software.controls
ומגדירים אותו ל-true
. - [3.8.16/H-1-2] חובה לספק משתמש
בעלות יכולת להוסיף, לערוך, לבחור ולהפעיל את
ממשק השליטה במכשירים מועדפים מאמצעי הבקרה שנרשמו על ידי הצד השלישי
אפליקציות דרך
ControlsProviderService
וגםControl
ממשקי API. - [3.8.16/H-1-3] חייבת לספק גישה אל משתמש זה מציע את המחירון שלו תוך שלוש אינטראקציות ממרכז אפליקציות המוגדר כברירת מחדל.
[3.8.16/H-1-4] חייב להיות רינדור מדויק למשתמש הזה מבחינת השם והסמל של כל אפליקציית צד שלישי מספק אמצעי בקרה דרך
ControlsProviderService
וכל השדות שצוינו על ידיControl
ממשקי API.[3.8.16/H-1-5] חובה לספק משתמש אפשרות לבטל את ההסכמה לשימוש בפקדי מכשירים שמשמשים לאימות לצורך אימות את אמצעי הבקרה שנרשמו על ידי אפליקציות צד שלישי
ControlsProviderService
וגםControl
API שלControl.isAuthRequired
.[3.8.16/H-1-6] הטמעות במכשירים חייב להתאים באופן מדויק את התקציב של המשתמש באופן הבא:
- אם המכשיר הגדיר את
config_supportsMultiWindow=true
והאפליקציה מצהירה על המטא-נתוניםMETA_DATA_PANEL_ACTIVITY
בControlsProviderService
כולל את שם הרכיב פעילות חוקית (כפי שהוגדר על ידי ה-API), חובה להטמיע באפליקציה פעילות בתקציב של משתמש זה. - אם האפליקציה לא מצהירה על מטא-נתונים
META_DATA_PANEL_ACTIVITY
, הוא חייב לעבד את השדות שצוינו כפי שסופקו על ידיControlsProviderService
וכל השדות שצוינו על ידי ממשקי API של שליטה.
- אם המכשיר הגדיר את
[3.8.16/H-1-7] אם האפליקציה מצהירה על המטא-נתונים
META_DATA_PANEL_ACTIVITY
, חייב להעביר את הערך שמוגדר בהגדרה [3.8.16/H-1-5] באמצעותEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
כשמפעילים את הפעילות המוטמעת.
לעומת זאת, אם הטמעות של מכשירים ניידים לא מיישמים אמצעי בקרה כאלה, הם:
- [3.8.16/H-2-1] חובה לדווח
null
עבורControlsProviderService
וגםControl
ממשקי API. - [3.8.16/H-2-2] חובה להצהיר על התכונה
דיווח
android.software.controls
ומגדירים אותו ל-false
.
אם הטמעתם של מכשירים ניידים לא פועלת במצב 'נעילת משימה', כשהמשתמשים מעתיקים תוכן ללוח העריכה:
- [3.8.17/H-1-1] חובה להציג למשתמש אישור לכך שהנתונים שהועתק ללוח (לדוגמה, תמונה ממוזערת או התראה עם "התוכן הועתק"). בנוסף, צריך לכלול כאן אינדיקציה אם הנתונים שבלוח העריכה יסונכרנו במכשירים שונים.
הטמעות של מכשירים ניידים:
- [3.10/H-0-1] חייב לתמוך בנגישות של צד שלישי שירותים שונים.
- [3.10/H-SR-1] מומלץ מאוד לטעון מראש שירותי נגישות במכשיר שניתנים להשוואה עם פונקציונליות או חריגה ממנה של 'גישה באמצעות מתג' ו-TalkBack (לשפות שנתמכות על ידי הרכיבים שהותקנו מראש שירותי נגישות של המרת טקסט לדיבור (TTS)), כפי שהם מסופקים בחלונית השיחה (TalkBack) פתוחה פרויקט המקור.
- [3.11/H-0-1] חייבת לתמוך בהתקנה של מנועי TTS של צד שלישי.
- [3.11/H-SR-1] מומלץ מאוד לכלול מנוע TTS שתומך בשפות הזמינות במכשיר.
- [3.13/H-SR-1] מומלץ מאוד לכלול קישור רכיב של ממשק המשתמש של ההגדרות המהירות.
אם על הטמעות של מכשירים ניידים עם Android מוצהר על FEATURE_BLUETOOTH
או
תמיכה של FEATURE_WIFI
, הם:
- [3.16/H-1-1] חייב לתמוך בהתאמת המכשיר הנלווה .
אם פונקציית הניווט מוצגת כפעולה במסך, שמבוססת על תנועות:
- [7.2.3/H] האזור לזיהוי התנועה של דף הבית הפונקציה לא יכולה להיות בגובה של יותר מ-32dp מתחתית מסך.
אם בהטמעות של מכשירים ניידים יש פונקציית ניווט בתור תנועה מכל מקום בקצה השמאלי והימני של המסך:
- [7.2.3/H-0-1] אזור התנועה של פונקציית הניווט הרוחב צריך להיות פחות מ-40dp בכל צד. אזור התנועות אמור להיות כברירת מחדל ברוחב 24dp.
אם בהטמעות של מכשירים ניידים יש תמיכה במסך נעילה מאובטח שווה ל-2GB או שווה ל-2GB של הזיכרון הזמינים לליבה ולמרחב המשתמש, הם:
- [3.9/H-1-2] חובה להצהיר על תמיכה בפרופילים מנוהלים באמצעות
סימון תכונה
android.software.managed_users
.
אם באפליקציות של מכשירי Android ניידים מוצהר על תמיכה במצלמה דרך
android.hardware.camera.any
הם:
- [7.5.4/H-1-1] חייב להיענות ל-
android.media.action.STILL_IMAGE_CAMERA
ו-android.media.action.STILL_IMAGE_CAMERA_SECURE
Intent ומפעילים את המצלמה במצב תמונת סטילס, כפי שמתואר ב-SDK. - [7.5.4/H-1-2] חייבים לכבד את
android.media.action.VIDEO_CAMERA
כוונה להפעיל את המצלמה במצב וידאו, כפי שמתואר ב-SDK.
אם אפליקציית ההגדרות של המכשיר מטמיעה פונקציונליות של פיצול, באמצעות הטמעת פעילות, ואז:
- [3.2.3.1/ H-1-1] חייבת להיות פעילות שמטפלת
Settings#ACTION_SETTINGS_CHANNEL_DEEP_LINK_ACTIVITY Intent כשפונקציונליות הפיצול מופעלת. הפעילות חייבת להיות מוגנת באמצעות
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
והיא חייבת תתחיל את הפעילות של ה-Intent שנותחה מ- הגדרות#חוץ_Settings_CHANNELDED_DEEP_LINK_INTENT_URI.
אם יישומי מכשירים מאפשרים למשתמשים לבצע שיחות מכל סוג שהוא,
- [7.4.1.2/H-0-1] חובה להצהיר על דגל התכונה
android.software.telecom
. - [7.4.1.2/H-0-2] חובה להטמיע את מסגרת הטלוויזיה.
2.2.4. ביצועים ועוצמה
- [8.1/H-0-1] זמן אחזור עקבי של פריימים. אסור שזמן האחזור של הפריים יהיה עקבי או עיכוב בעיבוד הפריימים הרבה מ-5 פריימים בשנייה, והם צריכים להיות נמוכים ממסגרת של פריימים בשנייה.
- [8.1/H-0-2] זמן אחזור של ממשק המשתמש. הטמעת מכשירים חייבת להבטיח חוויית משתמש עם זמן אחזור קצר על ידי גלילה רשימה של 10,000 רשומות, כפי שהוגדרו על ידי חבילת בדיקת התאימות של Android (CTS) בפחות מ-36 שניות.
- [8.1/H-0-3] החלפת משימות. מתי הושקו מספר אפליקציות והפעלה מחדש של אפליקציה שכבר פועלת של האפליקציה לאחר ההפעלה, חייבת להימשך פחות משנייה.
הטמעות של מכשירים ניידים:
- [8.2/H-0-1] חייב להבטיח רצף כתיבת ביצועים של 5MB לשנייה לפחות.
- [8.2/H-0-2] חייבת להבטיח כתיבה אקראית של לפחות 0.5MB לשנייה.
- [8.2/H-0-3] חייבים לוודא הקראה ברצף של לפחות 15MB לשנייה.
- [8.2/H-0-4] חייבת להבטיח קריאה אקראית של לפחות 3.5MB לשנייה.
אם הטמעות של מכשירים ניידים כוללות תכונות לשיפור השימוש במכשיר שכלולות ב-AOSP או מרחיבות את התכונות שכלולות ב-AOSP ב-AOSP, ריכזנו כאן:
- [8.3/H-1-1] חייבים לספק למשתמשים מספיק אפשרויות כדי להפעיל ומשביתים את תכונת החיסכון בסוללה.
- [8.3/H-1-2] חייבים לספק למשתמשים מספיק כסף להצגה את כל האפליקציות שפטורות ממצבי 'המתנה' ו'נמנום' של חיסכון בסוללה.
הטמעות של מכשירים ניידים:
- [8.4/H-0-1] חייב לספק קישור פרופיל כוח לכל רכיב שמגדיר את ערך הצריכה הנוכחית לגבי כל רכיב חומרה והתרוקנות משוערת של הסוללה שנגרמה על ידי הרכיבים לאורך זמן, כפי שמתואר באתר פרויקט הקוד הפתוח של Android.
- [8.4/H-0-2] חובה לדווח על כל אספקת החשמל במיליאמפר שעות (mAh).
- [8.4/H-0-3] חובה לדווח על עוצמת המעבד (CPU)
צריכה עבור כל מזהה ייחודי (UID) של כל תהליך. פרויקט הקוד הפתוח של Android עומד
באמצעות ההטמעה של מודול הליבה של
uid_cputime
. - [8.4/H-0-4] חייבים להשתמש בחשמל הזה
זמינה דרך
adb shell dumpsys batterystats
פקודת מעטפת למפתח האפליקציה. - צריך לשייך את [8.4/H] אל רכיב החומרה עצמו אם אין אפשרות לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.
אם הטמעות במכשירים ניידים כוללות מסך או פלט וידאו:
- [8.4/H-1-1] חייבים לכבד את
android.intent.action.POWER_USAGE_SUMMARY
Intent ומציג תפריט הגדרות שמציג את צריכת החשמל הזו.
הטמעות של מכשירים ניידים:
[8.5/H-0-1] חייב לספק תקציב של משתמש לראות את כל האפליקציות שיש בהן שירות פעיל שפועל בחזית או משימות ביוזמת המשתמש, כולל משך הזמן של כל אחד מהשירותים כי היא התחילה כפי שמתואר במסמך ה-SDK.
[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
בכוונה טובה.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
יישומי מכשירים חייבים להצהיר על תמיכה ב
android.software.credentials
וגם:
[9/H-0-2] חייב לפעול בהתאם לכוונה
android.settings.CREDENTIAL_PROVIDER
כדי לאפשר בחירה של ספק מועדף לניהול פרטי הכניסה. הספק הזה יופעל במילוי אוטומטי יהיה גם מיקום ברירת המחדל לשמירת פרטי כניסה חדשים שהוזנו דרך 'מנהל פרטי הכניסה'.[9/H-0-3] החברה חייבת לתמוך בו-זמנית לפחות בשני ספקים של פרטי כניסה ולספק מחיר נוח למשתמש באפליקציית ההגדרות כדי להפעיל או להשבית ספקים.
סיום הדרישות החדשות
אם בהטמעות המכשירים מוצהר על תמיכה ב-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, SHA-1 ו-SHA-2 פונקציות גיבוב (hash) כדי שיתמכו בצורה תקינה בתכונות הנתמכות של מערכת Android Keystore באזור המבודד באופן מאובטח מהקוד שפועל הליבה (kernel) ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים קוד ליבה או מרחב משתמש שיכול לגשת למצב הפנימי של בסביבה מבודדת, כולל DMA. קוד פתוח של Android ב-upstream פרויקט (AOSP) עומד בדרישה הזו באמצעות ההטמעה של Trusty, אבל פתרון מבוסס ARM TrustZone או פתרון מאובטח על ידי צד שלישי או להטמיע בידוד תקין שמבוסס על hypervisor אפשרויות.
- [9.11/H-0-4] חייבים לבצע את מסך הנעילה בסביבת ההפעלה המבודדת ורק כאשר בוצעה בהצלחה, תאפשר את השימוש במפתחות שקשורים לאימות. מסך הנעילה חייבים לאחסן את פרטי הכניסה באופן שמאפשר רק ביצוע מבודד כדי לבצע אימות של מסך הנעילה. Android בהמשך הדרך פרויקט קוד פתוח מספק Gatekeeper Hardware Layer Abstraction Layer (HAL) ו-Trusty, שיכולים לשמש כדי למלא את הדרישה הזו.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
[9.11/H-0-5] חייבת לתמוך באימות עם מפתחות כאשר מפתח חתימת אימות (attestation) מוגן באמצעות חומרה מאובטחת, והחתימה מבוצעת בחומרה מאובטחת. חייבים
לשתף את המפתחות של חתימת האימות בין מספר גדול מספיק של מכשירים כדי למנוע את השימוש במפתחותמניעה לא לשמש כקבוע מזהי מכשיר ייחודיים.אחת הדרכים לעמוד בדרישה הזו היא לשתף אותו מפתח אימות, אלא אם לפחות 100,000 יחידות של מק"ט נתון שהופק. אם מפיקים יותר מ-100,000 יחידות של מק"ט, ייתכן שייעשה שימוש במפתח עבור כל 100,000 יחידות.
סיום הדרישות החדשות
חשוב לשים לב: אם ההטמעה של המכשיר כבר הופעלה בגרסה קודמת של Android
גרסה מסוימת, מכשיר כזה פטור מהדרישה לקיום מאגר מפתחות.
שמגובות בסביבת הפעלה מבודדת ותומכת באימות (attestation) של המפתח,
אלא אם מוצהר על התכונה android.hardware.fingerprint
שדורשת
מאגר מפתחות שמגובה על ידי סביבת הפעלה מבודדת.
כשהטמעות של מכשירים ניידים תומכות במסך נעילה מאובטח:
- [9.11/H-1-1] המשתמשים חייבים לבחור את האפשרות הכי קצרה הזמן הקצוב לתפוגה של שינה, כלומר זמן המעבר מביטול הנעילה למצב הנעילה באורך 15 שניות או פחות.
- [9.11/H-1-2] המשתמשים חייבים לאפשר למשתמשים להסתיר אותם ומשביתים את כל סוגי האימות, מלבד האימות הראשי שמתואר במאמר 9.11.1 Secure Lock Screen. ה-AOSP עומד דרישה למצב 'ללא 'ביטול נעילה עם טביעת אצבע''.
אם בהטמעות של מכשירים יש מסך נעילה מאובטח וכולל סביבה אמינה אחת או יותר שמטמיעה את TrustAgentService
System API, הן:
- [9.11.1/H-1-1] חובה לאתגר את המשתמש באחת משיטות האימות הראשיות המומלצות (למשל: קוד אימות, קו ביטול נעילה, סיסמה) בתדירות גבוהה יותר מפעם אחת בכל 72 שעות.
אם בהטמעות של מכשירים ניידים יש כמה משתמשים
לא מצהירים על דגל התכונה android.hardware.telephony
, הם:
- [9.5/H-2-1] חייבת לתמוך בפרופילים מוגבלים. תכונה שמאפשרת לבעלי מכשירים לנהל משתמשים נוספים ליכולות של המכשיר. עם פרופילים מוגבלים, בעלי המכשירים יכולים להגדיר במהירות סביבות נפרדות שבהן משתמשים נוספים יעבדו, יכולת לנהל הגבלות פרטניות יותר באפליקציות זמינים בסביבות האלה.
אם בהטמעות של מכשירים ניידים יש כמה משתמשים
מצהירים על דגל התכונה android.hardware.telephony
, הם:
- [9.5/H-3-1] אסור שתמיכה מוגבלת אבל חייבים להתאים להטמעת AOSP של אמצעי הבקרה כדי לאפשר /להשבית את הגישה של משתמשים אחרים לשיחות קוליות ול-SMS.
אם ההטמעה של מכשירים ניידים מוגדרת כ-UserManager.isHeadlessSystemUserMode
אל true
,
- [9.5/H-4-1] אסור לכלול תמיכה ב-eUICC, וגם לא לכרטיסי eSIM עם יכולת ביצוע שיחה.
- [9.5/H-4-2] אין להצהיר על תמיכה ב
android.hardware.telephony
.
ב-Android, באמצעות System API VoiceInteractionService תומך במנגנון זיהוי של מילת הפעלה מאובטחת תמיד ללא חיווי גישה למיקרופון וזיהוי שאילתות פועל כל הזמן, ללא מיקרופון או מצלמה אינדיקציה לגישה.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
הגדרות מוגבלות
ההגדרות המוגבלות מציגות למשתמש אזהרות גלויות ומבקש את אישור המשתמש כדי להעניק הרשאות עבור כל אפליקציה שהיא:
- התקנה אחרי שמורידים דרך אפליקציה
(לדוגמה, אפליקציית הודעות או דפדפן) שאינו
'חנות אפליקציות' אפליקציה שזוהתה על ידי
PackageManager
בתורPACKAGE_DOWNLOADED_FILE
. - התקנה מקובץ מקומי
(לדוגמה, האפליקציה הותקנה ממקור לא ידוע)
זוהה על ידי
PackageManager
בתורPACKAGE_SOURCE_LOCAL_FILE
.
לגבי כל אחת מההרשאות שנאכפות המזהים המשויכים שלהם:
- התראות ותזכורות:
AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
- גישה לכל הקבצים:
AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
- הצגה מעל אפליקציות אחרות:
AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
- התקנת אפליקציות לא מוכרות:
AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
- ניהול המדיה:
AppOpsManager.OPSTR_MANAGE_MEDIA
- שינוי הגדרות המערכת:
AppOpsManager.OPSTR_WRITE_SETTINGS
- תמונה בתוך תמונה:
AppOpsManager.OPSTR_PICTURE_IN_PICTURE
- הפעלת המסך:
AppOpsManager.OPSTR_TURN_SCREEN_ON
- התראות במסך מלא:
AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
- שליטה ב-Wi-Fi:
AppOpsManager.OPSTR_CHANGE_WIFI_STATE
- נגישות:
AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
- האזנה להתראות:
AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
- גישה לנתוני השימוש:
AppOpsManager.OPSTR_GET_USAGE_STATS
- מנהל המכשיר:
Manifest.permission.BIND_DEVICE_ADMIN
- נא לא להפריע:
Manifest.permission.MANAGE_NOTIFICATIONS
אפליקציות כאלה מסומנות בתווית "אפליקציות מכוסות" לגבי הדרישות שמפורטות בקטע הזה.
הטמעות מכשירים:
[9.8/H-0-1] חובה להטמיע הגדרות מוגבלות כפי שמתואר למעלה, הבאים:
- הרשאות מיוחדות
- נגישות (
AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
) - האזנה להתראות (
AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
) - אפליקציות לניהול המכשיר (
Manifest.permission.BIND_DEVICE_ADMIN
) - תצוגה מעל אפליקציות אחרות (
AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
) - גישה לנתוני השימוש (
AppOpsManager.OPSTR_GET_USAGE_STATS
)
- נגישות (
- תפקידים (אפליקציות ברירת מחדל)
- חייגן (
RoleManager.ROLE_DIALER
) - SMS (
RoleManager.ROLE_SMS
)
- חייגן (
- הרשאות בתחילת ההפעלה
- זמן ריצה של SMS (
Manifest.permission_group.SMS
)
- זמן ריצה של SMS (
- הרשאות מיוחדות
[9.8/H-0-2] חייבים להפעיל הגדרות מוגבלות כברירת מחדל, מומלץ מאוד שלא יהיה לכל משתמש מחיר שמאפשר למשתמש כדי להשבית הגדרות מוגבלות עבור כל האפליקציות.
[9.8/H-0-3] חובה לוודא שמתקבל אישור משתמש לגבי כל האפליקציה המכוסה לפני שניתן להעניק את ההרשאה שנאכפה.
[9.8/H-0-4] כדי להפעיל הגדרות מוגבלות יש לאפשר רק אישור משתמש להשיג מדף AppInfo של האפליקציה המכוסה, באמצעות EnhancedConfirmationManager API.
[9.8/H-0-5] מומלץ מאוד לשלב אותו ולהתקשר אליו EnhancedConfirmationManager לכל ההרשאות המיוחדות, כדי לקבוע באופן דינמי אם הן הגדרה מוגבלת.
- התראות ותזכורות:
AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
- גישה לכל הקבצים:
AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
- הצגה מעל אפליקציות אחרות:
AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
- התקנת אפליקציות לא מוכרות:
AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
- ניהול המדיה:
AppOpsManager.OPSTR_MANAGE_MEDIA
- שינוי הגדרות המערכת:
AppOpsManager.OPSTR_WRITE_SETTINGS
- תמונה בתוך תמונה:
AppOpsManager.OPSTR_PICTURE_IN_PICTURE
- הפעלת המסך:
AppOpsManager.OPSTR_TURN_SCREEN_ON
- התראות במסך מלא:
AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
- שליטה ב-Wi-Fi:
AppOpsManager.OPSTR_CHANGE_WIFI_STATE
- נגישות:
AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
- האזנה להתראות:
AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
- גישה לנתוני השימוש:
AppOpsManager.OPSTR_GET_USAGE_STATS
- מנהל המכשיר:
Manifest.permission.BIND_DEVICE_ADMIN
- נא לא להפריע:
Manifest.permission.MANAGE_NOTIFICATIONS
- התראות ותזכורות:
סיום הדרישות החדשות
אם הטמעות של מכשירים ניידים תומכים ב-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 בייטים של נתונים (לא כולל שידורי אודיו) יועברו משירות הזיהוי של מילות ההפעלה בכל התוצאה של מילת ההפעלה.
- [9.8/H-1-7] אסור לאפשר העברה של יותר מ-5 ביט של נתונים של שירות הזיהוי של מילת ההפעלה בכל תוצאה שלילית של מילת הפעלה.
- [9.8/H-1-8] חובה לאפשר העברה של נתונים רק אל מחוץ למילת ההפעלה שירות זיהוי בבקשת אימות של מילת הפעלה משרת המערכת.
- [9.8/H-1-9] אסור לאפשר לאפליקציה להתקנה על ידי משתמש לספק את שירות לזיהוי מילות הפעלה.
- [9.8/H-1-10] אסור להציג בממשק המשתמש נתונים כמותיים לגבי השימוש במיקרופון עד השירות לזיהוי מילות הפעלה.
- [9.8/H-1-11] חובה לתעד את מספר הבייטים שכלולים בכל שידור מהשירות לזיהוי מילות הפעלה כדי לאפשר בדיקת אבטחה חוקרים בתחום.
- [9.8/H-1-12] חייבת לתמוך במצב ניפוי באגים שמתעד תוכן גולמי מכל שמועברים משירות הזיהוי של מילות הפעלה כדי לאפשר בדיקה של חוקרי אבטחה.
[9.8/H-1-14] חובה להציג את האינדיקטור של המיקרופון, כפי שמתואר בקטע 9.8.2, כשתוצאה מוצלחת של מילת ההפעלה מועברת אל הקול על שירות האינטראקציה או ישות דומה.
[9.8/H-1-15] חייבים לוודא ששידורי האודיו מגיעים במילת ההפעלה המוצלחת התוצאות נשלחות בכיוון אחד משירות זיהוי מילות ההפעלה אל שירות אינטראקציה קולית.
[9.8/H-SR-1] מומלץ מאוד להודיע למשתמשים לפני שמגדירים כספק של שירות הזיהוי של מילות הפעלה.
[9.8/H-SR-2] מומלץ מאוד לאסור העברת לא מובְנים של השירות לזיהוי מילות הפעלה.
[9.8/H-SR-3] מומלץ מאוד להתחיל מחדש את התהליך שמארח שירות זיהוי מילות הפעלה לפחות פעם בשעה או כל 30 אירועים של טריגרים באמצעות חומרה, המוקדם מביניהם.
אם הטמעות המכשירים כוללות אפליקציה שמשתמשת ב-System API
HotwordDetectionService
, או מנגנון דומה לזיהוי מילות הפעלה ללא
אינדיקציה לשימוש במיקרופון, האפליקציה:
- [9.8/H-2-1] חובה לספק הודעה מפורשת למשתמש לגבי כל ביטוי של מילת הפעלה נתמך.
- [9.8/H-2-2] אסור לשמור נתוני אודיו גולמיים או נתונים שנובעים מהם. באמצעות השירות לזיהוי מילות הפעלה.
- [9.8/H-2-3] אסור לשדר משירות זיהוי מילות ההפעלה, אודיו
נתונים שבאמצעותם אפשר לשחזר (באופן מלא או חלקי) את האודיו,
או תוכן אודיו שלא קשור למילת ההפעלה עצמה, מלבד
ContentCaptureService
או דיבור במכשיר שירות זיהוי.
אם הטמעות של מכשירים ניידים תומכים ב-System API
VisualQueryDetectionService
או מנגנון אחר לזיהוי שאילתות
ללא אינדיקציה למיקרופון או למצלמה, הם:
- [9.8/H-3-1] חובה לוודא ששירות זיהוי השאילתות יכול לשדר רק
נתונים למערכת,
ContentCaptureService
, או דיבור במכשיר שירות זיהוי (נוצר על ידיSpeechRecognizer#createOnDeviceSpeechRecognizer()
). - [9.8/H-3-2] אסור לאפשר העברת מידע של אודיו או וידאו
מתוך
VisualQueryDetectionService
, מלבדContentCaptureService
או שירות זיהוי דיבור במכשיר. - [9.8/H-3-3] חובה להציג הודעה למשתמש בממשק המשתמש של המערכת כשהמכשיר מזהה משתמש בכוונה להשתמש באפליקציה של העוזר הדיגיטלי (למשל, על ידי זיהוי הנוכחות של המשתמש דרך המצלמה).
- [9.8/H-3-4] חובה להציג אינדיקטור של מיקרופון ולהציג את התוכן שזוהה שאילתת משתמש בממשק המשתמש, מיד לאחר זיהוי שאילתת המשתמש.
- [9.8/H-3-5] אסור לאפשר לאפליקציה להתקנה על ידי משתמש לספק את שירות לזיהוי שאילתות חזותיות.
אם מוצהר על android.hardware.microphone
על הטמעות של מכשירים ניידים, הן:
- [9.8.2/H-4-1] חובה להציג את האינדיקטור של המיקרופון כאשר
אפליקציה ניגשת לנתוני אודיו מהמיקרופון, אבל לא כאשר
רק
HotwordDetectionService
יכול לגשת למיקרופון,SOURCE_HOTWORD
אוContentCaptureService
או אפליקציות עם התפקידים שנקראו בסעיף 9.1 עם מזהה CDD [C-4-X]. - [9.8.2/H-4-2] חייבת להציג את הרשימה של 'אחרונים' ו'פעילים'
אפליקציות שמשתמשות במיקרופון כפי שהוחזר
PermissionManager.getIndicatorAppOpUsageData()
, יחד עם כל שיוך (Attribution) הודעות שמשויכות אליהם. - [9.8.2/H-4-3] אסור להסתיר את האינדיקטור של המיקרופון עבור אפליקציות מערכת עם ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמשים.
- [9.8.2/H-4-4] חייבת להציג את הרשימה של 'אחרונים' ו'פעילים'
אפליקציות שמשתמשות במיקרופון כפי שהוחזר על ידי
PermissionManager.getIndicatorAppOpUsageData()
, יחד עם הודעות השיוך (Attribution) שמשויכות אליהן.
אם מוצהר על android.hardware.camera.any
על הטמעות של מכשירים ניידים, הן:
- [9.8.2/H-5-1] חובה להציג את האינדיקטור של המצלמה כאשר האפליקציה ניגשת לנתוני המצלמה בשידור חי, אבל לא כשהמצלמה אפליקציות שמשתמשות בתפקידים שצוינו סעיף 9.1 עם מזהה CDD [C-4-X].
- [9.8.2/H-5-2] חובה להציג אפליקציות פעילות ואפליקציות אחרונות באמצעות
מצלמה כפי שהוחזרה מ-
PermissionManager.getIndicatorAppOpUsageData()
, יחד עם הודעות השיוך (Attribution) שמשויכות אליהן. - [9.8.2/H-5-3] אסור להסתיר את האינדיקטור של המצלמה עבור אפליקציות מערכת עם ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמשים.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
'הפעלה מאומתת' היא תכונה שמבטיחה את תקינות התוכנה של המכשיר. אם הטמעות במכשירים תומכים בתכונה הזו:
- [9.10/H-1-1] חובה לאמת את כל המחיצות לקריאה בלבד שנטענו במהלך רצף ההפעלה של Android, ותקציר VBMeta חייב לכלול את כל המחיצות המאומתות האלה בחישוב שלו.
סיום הדרישות החדשות
2.2.6. תאימות לכלים למפתחים ולאפשרויות
הטמעות של מכשירים ניידים (* לא רלוונטי לטאבלט):
- [6.1/H-0-1]* חייב לתמוך בפקודת המעטפת
cmd testharness
.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
הטמעות של מכשירים ניידים (* לא רלוונטי לטאבלט):
- Perfetto
- [6.1/H-0-2]
*חייבים לחשוף/system/bin/perfetto
בינארית למשתמש המעטפת ש-cmdline פועל לתיעוד בלבד. - [6.1/H-0-3]
*הקובץ הבינארי של Perfetto חייב לקבל בתור קלט הגדרת Protobuf שתואמת לסכימה המוגדרת לתיעוד בלבד. - [6.1/H-0-4]
*הקובץ הבינארי של Perfetto חייב לכתוב בתור פלט מעקב של Protobuf התואם לסכימה המוגדרת לתיעוד בלבד. - [6.1/H-0-5]
*חייבים לספק, באמצעות Perfetto הבינארי, לפחות מקורות הנתונים שמתוארים לתיעוד בלבד. - [6.1/H-0-6]
*הדימון (daemon) שזוהה חייב להיות מופעל כברירת מחדל (מאפיין המערכתpersist.traced.enable
).
- [6.1/H-0-2]
סיום הדרישות החדשות
2.2.7. שיעור ביצועי מדיה להחזקה ביד
אפשר לעיין בסעיף 7.11 להגדרה של שיעור ביצועי המדיה.
2.2.7.1. מדיה
אם הטמעות במכשירים ניידים מוחזרות ערך של android.os.Build.VERSION_CODES.U
עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, הן:
- המדיה חייבת לעמוד בדרישות המדיה שמפורטות ב-Android 14 CDD בסעיף 2.2.7.1.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם הטמעות של מכשירים ניידים חוזרים
android.os.Build.VERSION_CODES.V
עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, הן:
סיום הדרישות החדשות
- [5.1/H-1-1] חובה לפרסם את המספר המקסימלי של מפענח וידאו באמצעות חומרה.
סשנים שיכולים לפעול בו-זמנית בכל שילוב קודק באמצעות
CodecCapabilities.getMaxSupportedInstances()
והקבוצהVideoCapabilities.getSupportedPerformancePoints()
אמצעי תשלום.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [5.1/H-1-2] חייבת להיות תמיכה ב-6 מופעים של מפענח וידאו בחומרה של 8 ביט (SDR) סשנים (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב קודק שפועל בו-זמנית עם 3 הפעלות ב-1080p resolution@30fps ו-3 הפעלות ב-4K הרזולוציה@30fps, אלא אם כן AV1. בכל הסשנים אסור לכלול יותר ממסגרת אחת ירידה בשנייה. רכיבי קודק AV1 נדרשים רק כדי לתמוך ברזולוציה של 1080p, אבל עדיין הם נדרשים כדי לתמוך ב-6 מכונות בקצב של 1080p30fps.
סיום הדרישות החדשות
- [5.1/H-1-3] חובה לפרסם את המספר המקסימלי של מקודדי וידאו כחומרה
סשנים שיכולים לפעול בו-זמנית בכל שילוב קודק באמצעות
CodecCapabilities.getMaxSupportedInstances()
והקבוצהVideoCapabilities.getSupportedPerformancePoints()
אמצעי תשלום.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [5.1/H-1-4] חייב לתמוך ב-6 מופעים של מקודד וידאו עם חומרת 8 ביט (SDR) סשנים (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב קודק שפועל בו-זמנית עם 4 הפעלות ב-1080p resolution@30 fps ו-2 הפעלות ב-4K הרזולוציה@30fps, אלא אם כן AV1. בכל הסשנים אסור לכלול יותר ממסגרת אחת ירידה בשנייה. רכיבי קודק AV1 נדרשים רק כדי לתמוך ברזולוציה של 1080p, אבל עדיין נדרשת לתמיכה ב-6 מכונות בקצב של 1080p30fps.
סיום הדרישות החדשות
- [5.1/H-1-5] חובה לפרסם את המספר המרבי של מקודד וידאו כחומרה
סשנים של מפענח, שיכולים להריץ בו-זמנית בכל שילוב קודק באמצעות
CodecCapabilities.getMaxSupportedInstances()
והקבוצהVideoCapabilities.getSupportedPerformancePoints()
אמצעי תשלום.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [5.1/H-1-6] חייבת להיות תמיכה ב-6 מופעים של מפענח וידאו בחומרה של 8 ביט (SDR) ומקודדים של וידאו בחומרה (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב קודק שפועל בו-זמנית עם 3 הפעלות בקצב של 4K@30fps רזולוציה (אלא אם AV1), שמתוכם 2 לכל היותר הם סשנים של מקודד ו-3 פעילויות באתר ברזולוציה של 1080p. בכל הסשנים אסור לכלול יותר ממסגרת אחת ירידה בשנייה. רכיבי קודק AV1 נדרשים רק כדי לתמוך ברזולוציה של 1080p, אבל עדיין נדרשת לתמיכה ב-6 מכונות בקצב של 1080p30fps.
סיום הדרישות החדשות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [5.1/H-1-19] חייבת להיות תמיכה בשלושה מופעים של מפענח וידאו בחומרת 10 ביט (HDR) ומקודדים של וידאו בחומרה (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב קודק שפועל בו-זמנית ברזולוציה של 4K@30fps (אלא אם הוא AV1) שמתוכם 1 הוא סשן מקודד, ואפשר להגדיר אותו פורמט קלט RGBA_1010102 דרך משטח GL. עבור בכל הסשנים, אסור ירידה של יותר ממסגרת אחת בכל שנייה. יצירת מטא-נתונים של HDR על ידי המקודד אין צורך אם הקידוד הוא משטח ה-GL. הסשנים של קודק AV1 נדרשת רק כדי לתמוך ברזולוציה של 1080p גם כשהדרישה הזו מחייבת באיכות 4K.
סיום הדרישות החדשות
- [5.1/H-1-7] זמן האחזור לאתחול קודק חייב להיות 40 אלפיות השנייה או פחות עבור קידוד וידאו של 1080p או פחות עבור כל מקודדי הווידאו בחומרה כאשר עוד לא טעונה. הטעינה כאן מוגדרת כסרטון ברזולוציית 1080p עד 720p בו-זמנית מבצע המרת קידוד באמצעות קודק וידאו בחומרה יחד עם רזולוציה של 1080p אתחול הקלטת אודיו-וידאו. ב-Dolby vision Codec, הקודק זמן האחזור של האתחול חייב להיות 50 אלפיות השנייה או פחות.
- [5.1/H-1-8] זמן האחזור לאתחול קודק חייב להיות 30 אלפיות השנייה או פחות עבור סשן של קידוד אודיו בקצב העברת נתונים של 128kbps או קצב נמוך יותר לכל מקודדי האודיו כאשר עוד לא טעונה. הטעינה כאן מוגדרת כסרטון ברזולוציית 1080p עד 720p בו-זמנית מבצע המרת קידוד באמצעות קודק וידאו בחומרה יחד עם רזולוציה של 1080p אתחול הקלטת אודיו-וידאו.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [5.1/H-1-9] חייבת להיות תמיכה בשני מופעים של מפענח וידאו עם חומרה מאובטחת סשנים (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב קודק שפועל בו-זמנית ב- 4k resolution@30 fps (אלא אם AV1) גם 8-bit (SDR) וגם תוכן באיכות HDR באיכות 10 ביט. בכל הסשנים אסור לכלול יותר ממסגרת אחת ירידה בשנייה. סשנים של קודק AV1 נדרשים רק כדי לתמוך ברזולוציה של 1080p גם דרישה זו מחייבת איכות 4K.
סיום הדרישות החדשות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [5.1/H-1-10] חייבת להיות תמיכה בשלושה מופעים של מפענח וידאו לא מאובטח בחומרה יחד עם מופע אחד של סשן של מפענח וידאו עם חומרה מאובטחת (סה"כ 4 מופעים) (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב של קודק שפועלים בו-זמנית עם 3 הפעלות ב-4K resolution@30fps (אלא אם AV1) שכולל סשן אחד של מפענח מאובטח וסשן אחד של nn-Secure ב-1080p. הרזולוציה@30fps, כאשר 2 סשנים יכולים להיות ב-HDR באיכות 10 ביט לכל היותר. בכל הסשנים אסור לכלול יותר ממסגרת אחת ירידה בשנייה. סשנים של קודק AV1 נדרשים רק כדי לתמוך ברזולוציה של 1080p גם דרישה זו מחייבת איכות 4K.
סיום הדרישות החדשות
- [5.1/H-1-11] חייב לתמוך במפענח מאובטח בכל חומרה של AVC, HEVC, במפענח VP9 או AV1 במכשיר.
- [5.1/H-1-12] זמן האחזור לאתחול קודק חייב להיות 40 אלפיות השנייה או פחות עבור סשן של פענוח וידאו ברזולוציה של 1080p או פחות לכל מפענחי הווידאו בחומרה כשיש עומס. הטעינה כאן מוגדרת כטמפרטורה בו-זמנית בין 1080p ל-720p של המרת קידוד של וידאו בלבד באמצעות קודקי וידאו של חומרה יחד עם אתחול הפעלת אודיו-וידאו ברזולוציה של 1080p. ב-Dolby vision Codec, הקודק זמן האחזור של האתחול חייב להיות 50 אלפיות השנייה או פחות.
- [5.1/H-1-13] זמן האחזור לאתחול קודק חייב להיות 30 אלפיות השנייה או פחות עבור סשן של פענוח אודיו בקצב העברת נתונים של 128kbps או פחות לכל מפענחי האודיו עוד לא טעונה. הטעינה כאן מוגדרת כסרטון ברזולוציית 1080p עד 720p בו-זמנית מבצע המרת קידוד באמצעות קודק וידאו בחומרה יחד עם רזולוציה של 1080p אתחול של הפעלת אודיו-וידאו.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [5.1/H-1-14] חייבת להיות תמיכה במפענח חומרה של AV1 ראשי 10, רמה 4.1
וגרעיניות סרטעם אפקט גרעיניות סרט על הרכב GPU.
סיום הדרישות החדשות
- [5.1/H-1-15] חייב להיות לפחות מפענח חומרה אחד לפענוח וידאו שתומך ב-4K60.
- [5.1/H-1-16] חייב להיות לפחות מקודד אחד של חומרה של וידאו שתומך ב-4K60.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [5.1/H-1-21] חייבת לתמוך ב-
FEATURE_DynamicColorAspect
בכל סרטוני חומרה מפענחים (AVC, HEVC, VP9, AV1 ואילך). הערה: כלומר, אפליקציות יכולות מעדכנים את היבטי הצבע של תוכן הסרטון במהלך סשן הפענוח. מפענחים שתומכים בתוכן של 10 ביט ו-8 ביט חייבים לתמוך באופן דינמי מעבר בין תוכן של 8 ל-10 ביט במצב 'על משטח'. מפענחים שתומכים פונקציית ההעברה ל-HDR חייבת לתמוך במעבר דינמי בין SDR ל-HDR תוכן.
סיום הדרישות החדשות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [5.1/H-1-22] חייבת לתמוך בקידוד, בפענוח, בעריכה באמצעות GPU ובהצגת סרטונים בתוכן ביחס גובה-רוחב לאורך ללא קשר למטא נתונים של הסיבוב עבור הרזולוציה הגבוהה ביותר שנתמכת במצלמה או 4K, הנמוך מביניהם. הערה: כולל פרופילים של HDR, אם קודק תומך ב-HDR. רכיבי קודק AV1 נדרשים רק כדי תמיכה ברזולוציה של 1080p. הדרישה הזו היא רק לקודק חומרה או ל-GPU ו-DPU.
סיום הדרישות החדשות
- [5.3/H-1-1] אסור לשחרר יותר מפריים אחד ב-10 שניות (כלומר, פחות מ- ירידה של 0.167 אחוז בפריים) תוך שימוש בסשן וידאו של 4K בקצב של 60fps.
- [5.3/H-1-2] אסור להפיל יותר מפריים אחד ב-10 שניות במהלך סרטון שינוי רזולוציה בסשן וידאו של 60 fps בסשן של 4K.
- [5.6/H-1-1] חייב להיות זמן אחזור של 'הקשה לגוון' של 80 אלפיות שנייה או פחות באמצעות בדיקת ההקשה לכוונון CTS של ה-CTS.
- [5.6/H-1-2] זמן האחזור של האודיו הלוך ושוב הוא 80 אלפיות שנייה או לפחות בנתיב נתונים נתמך אחד.
- [ 5.6/H-1-3] חייבת להיות תמיכה באודיו של 24 ביט לפחות לפלט סטריאו של 3.5 מ"מ
אם יש חיבור ליציאת אודיו ב-USB, אם הוא נתמך בכל הנתונים
לתצורות של סטרימינג וזמן אחזור קצר. לזמן אחזור קצר
הגדרה אישית, האפליקציה צריכה להשתמש באודיו במסגרת קריאה חוזרת (callback) עם זמן אחזור קצר
במצב תצוגה. להגדרת הסטרימינג, יש להשתמש ב-Java AudioTrack באמצעות
את האפליקציה. בתצורה של זמן אחזור קצר וגם בתצורה של סטרימינג, טכנולוגיית HAL
sink הפלט צריך לקבל
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
אוAUDIO_FORMAT_PCM_FLOAT
לפורמט הפלט של היעד.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [5.6/H-1-4] צריכה תמיכה ב->= 4 ערוצים בהתקני אודיו USB.
(ההגדרה הזו משמשת את בקרי די-ג'יי להשמעה מקדימה של שירים.)
סיום הדרישות החדשות
- [5.6/H-1-5] חייבת להיות תמיכה במכשירי MIDI שתואמים למחלקות, ולהצהיר על סימון התכונה MIDI.
- [5.6/H-1-9] חייבת לתמוך לפחות ב-12 ערוצים במיקס. כאן משתמע יכולת לפתוח AudioTrack עם מסכה של 7.1.4 ערוצים ובאופן תקין לחלק את כל הערוצים לסטריאו או לחלק את כל הערוצים ל'סטריאו'.
- [5.6/H-SR] מומלץ מאוד לתמוך בתמהיל של 24 ערוצים עם לספק לפחות תמיכה במסכות של 9.1.6 ו-22.2 ערוצים.
- [5.7/H-1-2] חייבת לתמוך ב-
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
עם חדשות לפענוח תוכן.
גודל דגימה מינימלי | 4 MiB |
מספר מינימלי של תתי-דגימות – H264 או HEVC | 32 |
מספר מינימלי של דוגמאות משנה – VP9 | 9 |
מספר מינימלי של תתי-דגימות – AV1 | 288 |
גודל מינימלי של מאגר נתונים זמני של תת-דגימה | MiB1 |
גודל כללי מינימלי למאגר הנתונים הזמני של מטבעות וירטואליים | 500 KiB |
המספר המינימלי של סשנים בו-זמנית | 30 |
מספר מפתחות מינימלי לכל סשן | 22 |
מספר כולל מינימלי של מפתחות (כל הסשנים) | 80 |
המספר הכולל המינימלי של מפתחות DRM (הכול סשנים) | 6 |
גודל ההודעה | 16 KiB |
פענוח פריימים לשנייה (FPS) | 60 fps |
- [5.1/H-1-17] חייב להיות לפחות מפענח אחד של חומרה לפענוח תמונה שתומך ב-AVIF פרופיל בסיס.
- [5.1/H-1-18] חייב לתמוך במקודד AV1 שיכול לקודד עד 480p ברזולוציה של 30fps ו-1Mbps.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [5.1/H-1-20] חייב לתמוך ב-
Feature_HdrEditing
תכונה לכל מקודדי החומרה AV1 ו-HEVC שקיימים במכשיר באיכות 4K או הרזולוציה הגבוהה ביותר שנתמכת על ידי מצלמה, הנמוך מביניהם.
סיום הדרישות החדשות
- [5.12/H-SR] מומלץ מאוד לתמוך בתמיכה
Feature_HdrEditing
לכל מקודדי החומרה AV1 ו-HEVC שקיימים במכשיר. - [5.12/H-1-2] חייבת לתמוך בפורמט צבע RGBA_1010102 בכל החומרה AV1 ו מקודדי HEVC קיימים במכשיר.
- [5.12/H-1-3] חייבים לפרסם תמיכה לתוסף EXT_YUV_target כדי לדגום מתוך טקסטורות של YUV גם ב-8 וגם ב-10 ביט.
- [7.1.4/H-1-1] חייבות להיות לפחות 6 שכבות-על של חומרה בעיבוד המסך (DPU), כאשר לפחות שניים מהם יכולים להציג תוכן וידאו של 10 ביט.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם הטמעות של מכשירים ניידים חוזרים
android.os.Build.VERSION_CODES.V
עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, והם כוללים
במקודד חומרה AVC או HEVC, הן:
סיום הדרישות החדשות
- [5.2/H-2-1] חייבת לעמוד ביעד האיכות המינימלי שהוגדר בסרטון עקומת עיוות קצב של המקודד עבור קודקי חומרה מסוג AVC ו-HEVC, כפי שמוגדר ב- מריצים בדיקות של איכות קידוד הווידאו (VEQ) ברמת ביצועים 14 (PC14).
2.2.7.2. מצלמה
אם הטמעות במכשירים ניידים מוחזרות ערך של android.os.Build.VERSION_CODES.U
עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, הן:
- המדיה חייבת לעמוד בדרישות המדיה שמפורטות ב-Android 14 CDD בסעיף 2.2.7.2.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם הטמעות של מכשירים ניידים חוזרים
android.os.Build.VERSION_CODES.V
עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, הן:
סיום הדרישות החדשות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [7.5/H-1-1] חייבת להיות מצלמה אחורית ראשית עם ברזולוציה של 12 מגה-פיקסלים לפחות שתומכת בצילום וידאו 4k@30fps, 1080p@60fps 720p@60fps. המצלמה האחורית הראשית למצלמה האחורית עם מזהה המצלמה הנמוך ביותר.
סיום הדרישות החדשות
- [7.5/H-1-2] חייבת להיות מצלמה קדמית ראשית ברזולוציה של 6 מגה-פיקסלים לפחות ותמיכה בצילום וידאו בקצב של 1080p@30fps. המשחק הראשי המצלמה הקדמית היא המצלמה הקדמית עם מזהה המצלמה הנמוך ביותר.
- [7.5/H-1-3] חייב לתמוך בנכס
android.info.supportedHardwareLevel
בתורFULL
ומעלה לראשי תיבות של חזרה ו-LIMITED
ומעלה לשחקנים ראשיים ראשוניים. מצלמה. - [7.5/H-1-4] חייבת תמיכה
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
לשתי הראשיות מצלמות. - [7.5/H-1-5] חייב להיות זמן אחזור של צילום JPEG עם Camera2 < 1,000 ms לרזולוציה של 1080p כפי שנמדדה על ידי בדיקת הביצועים של מצלמת CTS בקטע תנאי התאורה של ITS (3,000K) בשתי המצלמות הראשיות.
- [7.5/H-1-6] חייב להיות זמן אחזור בהפעלה של מצלמה2 (צריך לפתוח את המצלמה כדי לראות תצוגה מקדימה ראשונה) מסגרת) < 500 אלפיות השנייה כפי שנמדדו על ידי בדיקת הביצועים של מצלמת CTS במסגרת ITS בתנאי התאורה (3,000K) של שתי המצלמות הראשיות.
- [7.5/H-1-8] חייבת לתמוך ב-
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
ו-android.graphics.ImageFormat.RAW_SENSOR
למצלמה האחורית הראשית. - [7.5/H-1-9] חייבת להיות מצלמה ראשית אחורית שתומכת ב-720p או 1080p @ 240fps.
- [7.5/H-1-10] חייב להיות מספר מינימלי של ZOOM_RATIO < 1.0 למצלמות הראשיות, אם יש היא מצלמת RGB מסוג Ultrawide שפונה לאותו כיוון.
- [7.5/H-1-11] חייבים להטמיע סטרימינג בשידור חי בו-זמנית בשידור הראשי מצלמות.
- [7.5/H-1-12] חייבת תמיכה
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
לשתי הראשיות המצלמה הקדמית והמצלמה הראשית. - [7.5/H-1-13] חייבת לתמוך ביכולת
LOGICAL_MULTI_CAMERA
במצלמה האחורית הראשית, אם יש יותר מ-RGB אחורי אחד מצלמות. - [7.5/H-1-14] חייבת לתמוך ביכולת
STREAM_USE_CASE
בשתי הפלטפורמות הראשיות המצלמה הקדמית והמצלמה הראשית. - [7.5/H-1-15] חייבת תמיכה תוספים למצב לילה דרך תוספי CameraX ו- Camera2 עבור הראשי מצלמות.
- [7.5/H-1-16] חייבת לתמוך ביכולת DYNAMIC_RANGE_TEN_BIT הראשית מצלמות.
- [7.5/H-1-17] חייבת להיות תמיכה ב-Control_SCENE_mode_FACE_PRIORITY וזיהוי פנים (StatISTICS_FACE_DETECT_מצב_SIMPLE או StatISTICS_FACE_DETECT_מצב_FULL) למצלמות הראשיות.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [7.5/H-1-18] חייבת להיות תמיכה ב-
JPEG_R
עבור החלק האחורי הראשי המצלמות הראשיות. - [7.5/H-1-19] חייבת תמיכה
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
ל-1080p HLG10 תצוגה מקדימה עם JPEG ביחס גובה-רוחב מקסימלי של 16:9, ותצוגה מקדימה באיכות 720p HLG10 עם שילובים של שידור JPEG עם יחס גובה-רוחב מקסימלי של 16:9 מצלמה אחורית. - [7.5/H-1-20] חייב להיות פלט ברירת מחדל
JPEG_R
לפלט הראשי המצלמה האחורית והמצלמה הראשית באפליקציית המצלמה המקורית.
סיום הדרישות החדשות
2.2.7.3. חומרה
אם בהטמעות במכשירים ניידים מוחזר הערך android.os.Build.VERSION_CODES.U
למשך
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, הן:
- המדיה חייבת לעמוד בדרישות המדיה שמפורטות ב-Android 14 CDD בסעיף 2.2.7.3.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם הטמעות של מכשירים ניידים חוזרים
android.os.Build.VERSION_CODES.V
עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, הן:
סיום הדרישות החדשות
- [7.1.1.1/H-2-1] רזולוציית המסך חייבת להיות לפחות 1080p.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [7.1.1.3/H-2-1] דחיסות מסך של לפחות 400 dpi אם רוחב המסך של המכשיר הוא < 600dp
סיום הדרישות החדשות
- [7.1.1.3/H-3-1] מסך HDR חייב להיות תומך ב- 1,000 nit לפחות בממוצע.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [7.6.1/H-2-1] חייב להיות זיכרון פיזי בנפח של 8GB לפחות,
עם 6.64GB לפחות זמינים לליבה (kernel) כפי שדווח על ידי
android.app.ActivityManager.MemoryInfo.totalMem
.
סיום הדרישות החדשות
2.2.7.4. ביצועים
אם בהטמעות במכשירים ניידים מוחזר הערך android.os.Build.VERSION_CODES.U
למשך
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, הן:
- חייבת לעמוד בדרישות הביצועים שמפורטות ב-Android 14 CDD בסעיף 2.2.7.4.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם הטמעות של מכשירים ניידים חוזרים
android.os.Build.VERSION_CODES.V
עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, הן:
סיום הדרישות החדשות
- [8.2/H-1-1] חייבים להבטיח ביצועי כתיבה רציפים של לפחות 150MB לשנייה.
- [8.2/H-1-2] חייבים להבטיח ביצועי כתיבה אקראיים של לפחות 10MB לשנייה.
- [8.2/H-1-3] חייבת להבטיח ביצועי קריאה רציפים של לפחות 250MB לשנייה.
- [8.2/H-1-4] חייבת להבטיח ביצועי קריאה אקראיים של לפחות 100MB לשנייה.
- [8.2/H-1-5] חייבים להבטיח ביצועי קריאה וכתיבה סדרתיים מקבילים עם ביצועי קריאה פי 2 וכתיבה של לפחות 50MB לשנייה.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
2.2.7.5. גרפיקה
אם הטמעות במכשירים ניידים מוחזרות ערך של android.os.Build.VERSION_CODES.V
עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, הן:
- [7.1.4.1/H-1-1] הדרישה הזו בוטלה ב-Android 15 (AOSP ניסיוני).
- [7.1.4.1/H-1-2] חייב לתמוך
EGL_IMG_context_priority
וגםEGL_EXT_protected_content
תוספים. - [7.1.4.1/H-1-3] חייבת תמיכה
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
ו-VK_KHR_global_priority
.
סיום הדרישות החדשות
2.3. דרישות לטלוויזיה
מכשיר Android TV מתייחס להטמעה של מכשיר Android, הוא ממשק בידור שמשמש לצריכה של מדיה דיגיטלית, סרטים, משחקים, אפליקציות ו/או טלוויזיה בשידור חי למשתמשים שיושבים במרחק של כ-6 מ"מ (10 מטרים), ממשק משתמש גרפי").
הטמעות של מכשירי Android מסווגים כטלוויזיה אם הם עומדים בכל הקריטריונים הבאים:
- החברה סיפקה מנגנון לשליטה מרחוק בממשק המשתמש שעבר עיבוד שנמצא במרחק של כ-3 מטרים מהמשתמש.
- מסך מוטמע עם אורך אלכסון גדול מ-24 אינץ' או כולל יציאת פלט וידאו, כגון VGA , HDMI , DisplayPort או יציאה אלחוטית למסך.
הדרישות הנוספות המפורטות בהמשך הקטע הזה הן ספציפיות ל-Android הטמעות של מכשירי טלוויזיה.
2.3.1. חומרה
הטמעות של מכשירי טלוויזיה:
- [7.2.2/T-0-1] חובה לתמוך בלחצני החיצים (D-pad).
- [7.2.3/T-0-1] חייבים לספק את 'דף הבית' ואת 'הקודם' למשימות ספציפיות.
- [7.2.3/T-0-2] חייבים לשלוח גם בלחיצה רגילה וגם בלחיצה ארוכה
אירוע של פונקציית 'הקודם' (
KEYCODE_BACK
) לאפליקציה בחזית. - [7.2.6.1/T-0-1] חייבת לכלול תמיכה במשחק
בקרים והצהרה על דגל הפיצ'ר
android.hardware.gamepad
. - [7.2.7/T] אמור לספק שלט רחוק שממנו שמשתמשים יכולים לגשת לניווט ללא מגע קלט של מקשי ליבה לניווט.
אם בהטמעות של מכשירי טלוויזיה נעשה שימוש בג'ירוסקופ ב-3 צירים:
- [7.3.4/T-1-1] צריכה להיות אפשרות לדווח על אירועים עד של לפחות 100Hz.
- [7.3.4/T-1-2] חייבת להיות יכולת למדוד שינויי כיוון עד 1,000 מעלות לשנייה.
הטמעות של מכשירי טלוויזיה:
- [7.4.3/T-0-1] חייב לתמוך ב-Bluetooth וב Bluetooth LE.
- [7.6.1/T-0-1] חייבים להיות לפחות 4GB של אחסון בלתי תנודתי שזמין לנתונים פרטיים של האפליקציה (שנקראת גם מחיצת "/data" ).
אם הטמעות של מכשיר טלוויזיה כוללות יציאת USB שתומכת במצב מארח, הם:
- [7.5.3/T-1-1] חייבת לכלול תמיכה במצלמה חיצונית שמתחבר באמצעות יציאת ה-USB הזו אבל לא בהכרח מחובר תמיד.
אם ההטמעה של מכשירי טלוויזיה היא 32 ביט:
[7.6.1/T-1-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות בגודל של 896MB לפחות, אם נעשה שימוש באחת מהדחיסות הבאות:
- 400dpi או יותר במסכים קטנים/רגילים
- xhdpi ומעלה במסכים גדולים
- tvdpi ומעלה במסכים גדולים במיוחד
אם ההטמעות של מכשיר טלוויזיה הן בגרסת 64 ביט:
[7.6.1/T-2-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות בגודל של 1280MB לפחות, אם אחת מהדחיסות הבאה היא בשימוש:
- 400dpi או יותר במסכים קטנים/רגילים
- xhdpi ומעלה במסכים גדולים
- tvdpi ומעלה במסכים גדולים במיוחד
שימו לב ש"הזיכרון שזמין לליבה ולמרחב המשתמשים" שלמעלה מתייחס בנוסף לכל הזיכרון הקיים שמיועד לרכיבי חומרה כמו רדיו, וידאו וכן הלאה, בשליטת הליבה על יישומי המכשיר.
הטמעות של מכשירי טלוויזיה:
- [7.8.1/T] צריכה לכלול מיקרופון.
- [7.8.2/T-0-1] חובה לכלול פלט אודיו שהוצהר עליו
android.hardware.audio.output
.
2.3.2. מולטימדיה
הטמעות של מכשירי טלוויזיה חייבות לתמוך בקידוד האודיו הבא ומקודדים בפורמטים שונים כדי שיהיו זמינים לאפליקציות של צד שלישי:
- [5.1/T-0-1] MPEG-4 AAC Profile (AAC LC)
- [5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
- [5.1/T-0-3] AAC ELD (משופר עם השהיה נמוכה AAC)
הטמעות של מכשירי טלוויזיה חייבות לתמוך בקידוד הווידאו הבא כדי שיהיו זמינים לאפליקציות של צד שלישי:
הטמעות של מכשירי טלוויזיה:
- [5.2.2/T-SR-1] מומלץ מאוד לתמיכה קידוד H.264 של סרטונים ברזולוציה של 720p ו-1080p בקצב של 30 FPS.
הטמעות של מכשירי טלוויזיה חייבות לתמוך בפענוח הווידאו הבא כדי שיהיו זמינים לאפליקציות של צד שלישי:
- [5.3.3/T-0-1] MPEG-4 SP
- [5.3.4/T-0-2] H.264 AVC
- [5.3.5/T-0-3] H.265 HEVC
- [5.3.6/T-0-4] VP8
- [5.3.7/T-0-5] VP9
- [5.3.1/T-0-6] MPEG-2
- [5.3.2/T-0-7] AV1
הטמעות של מכשירי טלוויזיה חייבים לתמוך בפענוח MPEG-2, כפי שמפורט ב סעיף 5.3.1, בקצבי פריימים סטנדרטיים וברזולוציות של עד ו- כולל:
- [5.3.1/T-1-1] איכות HD 1080p בקצב של 29.97FPS עם פרופיל ראשי ברמה גבוהה.
- [5.3.1/T-1-2] HD 1080i בקצב של 59.94FPS עם פרופיל ראשי ברמה גבוהה. הם חייבים לבטל שילוב של וידאו MPEG-2 משולב ולהפוך אותו לזמין לאפליקציות של צד שלישי.
הטמעות של מכשירי טלוויזיה חייבות לתמוך בפענוח H.264, כפי שמפורט ב סעיף 5.3.4, בקצבי פריימים סטנדרטיים וברזולוציות של עד ו- כולל:
- [5.3.4/T-1-1] HD 1080p בקצב של 60 פריימים לשנייה עם פרופיל הבסיס
- [5.3.4/T-1-2] HD 1080p בקצב של 60 פריימים לשנייה עם פרופיל ראשי
- [5.3.4/T-1-3] HD 1080p בקצב של 60 פריימים לשנייה עם רמת פרופיל גבוהה 4.2
הטמעות של מכשירי טלוויזיה עם מפענחי חומרה מסוג H.265 חייבים תמיכה פענוח בפורמט H.265, כמפורט בסעיף 5.3.5, בקצבי פריימים רגילים של וידאו. וברזולוציות עד וכולל:
- [5.3.5/T-1-1] HD 1080p בקצב של 60 פריימים לשנייה עם פרופיל ראשי רמת 4.1
אם הטמעות של מכשירי טלוויזיה עם מפענחי חומרה H.265 תומכות במסגרת פענוח בפורמט H.265 ופרופיל פענוח UHD:
- [5.3.5/T-2-1] חייבת לתמוך בפרופיל פענוח UHD בקצב של 60 פריימים לשנייה (FPS) בפרופיל הראשי ב-Main10 ברמה 5
הטמעות של מכשירי טלוויזיה חייבות לתמוך בפענוח קוד VP8, כפי שמפורט ב סעיף 5.3.6, בקצבי פריימים סטנדרטיים וברזולוציות של עד ו- כולל:
- [5.3.6/T-1-1] פרופיל פענוח באיכות HD 1080p בקצב של 60FPS
הטמעות של מכשירי טלוויזיה עם מפענחי חומרה VP9 חייבים לתמוך ב-VP9 שלך, כמפורט בסעיף 5.3.7, בקצבי פריימים רגילים של וידאו, עד וכולל:
- [5.3.7/T-1-1] איכות HD 1080p בקצב של 60FPS עם פרופיל 0 (עומק צבעים של 8 ביט)
אם הטמעות של מכשירי טלוויזיה עם מפענחי חומרה מסוג VP9 תומכות ב-VP9 ופרופיל הפענוח באיכות UHD:
- [5.3.7/T-2-1] חייבת לתמוך בפרופיל פענוח UHD של 60 FPS עם פרופיל 0 (עומק צבעים של 8 ביט).
- [5.3.7/T-SR1] מומלץ מאוד לתמוך פרופיל פענוח UHD בקצב של 60 פריימים לשנייה, עם פרופיל 2 (עומק צבעים של 10 ביט).
הטמעות של מכשירי טלוויזיה:
- [5.5/T-0-1] חייבת לכלול תמיכה במאסטר של המערכת הפחתת עוצמת הקול ופלט האודיו הדיגיטלי ביציאות נתמכות, מלבד פלט אודיו דחוס (שבהם לא מתבצע פענוח קוד של אודיו) במכשיר).
אם בהטמעות של מכשירי טלוויזיה אין מסך מובנה, אבל תומכת במסך חיצוני שמחובר באמצעות HDMI, כי הן:
- [5.8/T-0-1] חייבים להגדיר את מצב פלט ה-HDMI הרזולוציה הגבוהה ביותר לפורמט הפיקסל שנבחר שפועל עם 50Hz או 60Hz קצב הרענון של המסך החיצוני, בהתאם לקצב הרענון של הסרטון עבור האזור שבו המכשיר נמכר.
- [5.8/T-SR-1] מומלץ מאוד לספק למשתמש בורר ניתן להגדרה של קצב הרענון ב-HDMI.
- [5.8] צריך להגדיר את קצב הרענון למצב פלט HDMI ל-50Hz או 60Hz, בהתאם לקצב הרענון של הווידאו באזור שהמכשיר נמכר בו.
אם בהטמעות של מכשירי טלוויזיה אין מסך מובנה, אבל תומכת במסך חיצוני שמחובר באמצעות HDMI, כי הן:
- [5.8/T-1-1] חייב לתמוך ב-HDCP 2.2.
אם הטמעות של מכשירי טלוויזיה לא תומכות בפענוח UHD, במקום זאת תומכות במסך חיצוני המחובר באמצעות HDMI, הן:
- [5.8/T-2-1] חייב לתמוך ב-HDCP 1.4
2.3.3. תוכנות
הטמעות של מכשירי טלוויזיה:
- [3/T-0-1] חובה להצהיר על התכונות
android.software.leanback
ו-android.hardware.type.television
. - [3.2.3.1/T-0-1] חובה לטעון מראש אחד או יותר אפליקציות או רכיבי שירות עם handler של Intent, לכל הדפוסים של סינון Intent ציבורי שמוגדרים לפי ה-Intentים הבאים של אפליקציות המפורטים כאן.
- [3.4.1/T-0-1] חובה לספק מידע מלא
של ה-API של
android.webkit.Webview
.
אם בהטמעות של מכשירי Android TV יש תמיכה במסך נעילה:
- [3.8.10/T-1-1] חייבים להציג את סמל המנעול התראות במסך, כולל התבנית של התראות מדיה.
הטמעות של מכשירי טלוויזיה:
- [3.8.14/T-SR-1] מומלץ מאוד כדי לתמוך במצב 'תמונה בתוך תמונה' (PIP) בריבוי חלונות.
- [3.10/T-0-1] חייב לתמוך בנגישות של צד שלישי שירותים שונים.
- [3.10/T-SR-1] מומלץ מאוד טעינה מראש של שירותי נגישות במכשיר להשוואה עם או מעבר הפונקציונליות של 'גישה באמצעות מתג' ו-TalkBack (לשפות הנתמכות על ידי את שירותי הנגישות המותקן מראש של המרת טקסט לדיבור (TTS), כפי שמסופק פרויקט הקוד הפתוח TalkBack.
אם יישומים של מכשירי טלוויזיה ידווחו על התכונה
android.hardware.audio.output
, הן:
- [3.11/T-SR-1] מומלץ מאוד לכלול מנוע TTS שתומך בשפות הזמינות במכשיר.
- [3.11/T-1-1] חייבת לתמוך בהתקנה של מנועי TTS של צד שלישי.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
הטמעות של מכשירי טלוויזיה:
- [3.12/T-0-1] חייב לתמוך במסגרת של קלט טלוויזיה.
סיום הדרישות החדשות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
Android Television קלט Framework (TIF) מפשט העברה של תוכן בשידור חי למכשירי Android TV. TIF מספקת API ליצירת מודולים לקלט ששולטים במכשירי Android TV.
הטמעות של מכשירי טלוויזיה:
- [3/T-0-2] חובה להצהיר על הפיצ'ר של הפלטפורמה
android.software.live_tv
. - [3/T-0-3] חייבת לתמוך בכל ממשקי ה-API מסוג TIF, שמשתמש בממשקי ה-API האלה מקורות קלט מבוססי TIF של צד שלישי ניתן להתקין את השירות ולהשתמש בו במכשיר.
Android Television Tur Framework (TF) מאחד את הטיפול בתוכן בשידור חי מטיונר עם תוכן בסטרימינג מ-IP במכשירי Android TV. מסגרת Turner מספקת ממשק API סטנדרטי כדי ליצור שירותי קלט שמשתמשים ב-Android TVTunr.
אם בהטמעות של מכשירים יש תמיכה בטיונר:
- [3/T-1-1] חייבת לתמוך בכל ממשקי ה-API של Tur Framework, ניתן להתקין את האפליקציה שמשתמשת בממשקי ה-API האלה במכשיר ולהשתמש בה.
סיום הדרישות החדשות
2.3.4. ביצועים ועוצמה
- [8.1/T-0-1] זמן אחזור עקבי של פריימים. אסור שזמן האחזור של הפריים יהיה עקבי או עיכוב בעיבוד הפריימים הרבה מ-5 פריימים בשנייה, והם צריכים להיות נמוכים ממסגרת של פריימים בשנייה.
- [8.2/T-0-1] חייב להבטיח רצף מהירות כתיבת הנתונים של 5MB/s לפחות.
- [8.2/T-0-2] חובה להקפיד על כתיבה אקראית של לפחות 0.5MB לשנייה.
- [8.2/T-0-3] חייב להבטיח רצף קריאה של נתוני ביצועים של 15MB לשנייה לפחות.
- [8.2/T-0-4] חייבת להבטיח קריאה אקראית של 3.5MB לשנייה לפחות.
אם ההטמעות של מכשירי טלוויזיה כוללות תכונות שמשפרות את עוצמת המכשיר שכלולות ב-AOSP או מרחיבות את התכונות שכלולות ב-AOSP ב-AOSP, ריכזנו כאן:
- [8.3/T-1-1] חייבים לספק למשתמשים מספיק אפשרויות כדי לאפשר את ההפעלה ומשביתים את תכונת החיסכון בסוללה.
אם בהטמעות של מכשירי טלוויזיה אין סוללה:
- [8.3/T-1-2] חובה לרשום את המכשיר בתור מכשיר ללא סוללה, כפי שמתואר במאמר תמיכה במכשירים ללא סוללה.
אם הטמעות של מכשירי טלוויזיה כוללים סוללה:
- [8.3/T-1-3] חייבים לספק למשתמשים מספיק כסף להצגה את כל האפליקציות שפטורות ממצבי 'המתנה' ו'נמנום' של חיסכון בסוללה.
הטמעות של מכשירי טלוויזיה:
- [8.4/T-0-1] חובה לספק פרופיל כוח לכל רכיב שמגדיר את ערך הצריכה הנוכחית לגבי כל רכיב חומרה והתרוקנות משוערת של הסוללה שנגרמה על ידי הרכיבים לאורך זמן, כפי שמתואר באתר פרויקט הקוד הפתוח של Android.
- [8.4/T-0-2] חובה לדווח על כל אספקת החשמל במיליאמפר שעות (mAh).
- [8.4/T-0-3] חובה לדווח על עוצמת המעבד (CPU)
צריכה עבור כל מזהה ייחודי (UID) של כל תהליך. פרויקט הקוד הפתוח של Android עומד
באמצעות ההטמעה של מודול הליבה של
uid_cputime
. - צריך לשייך את [8.4/T] אל רכיב החומרה עצמו אם אין אפשרות לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.
- [8.4/T-0-4] חייבים להשתמש בחשמל הזה
זמינה דרך
adb shell dumpsys batterystats
פקודת מעטפת למפתח האפליקציה.
2.3.5. דגם אבטחה
הטמעות של מכשירי טלוויזיה:
- [9/T-0-1] חובה להצהיר על
android.hardware.security.model.compatible
. - [9.11/T-0-1] חובה לגבות את ההטמעה של מאגר המפתחות עם סביבת הפעלה מבודדת.
- [9.11/T-0-2] חייבות להיות הטמעות של RSA, AES, אלגוריתמים קריפטוגרפיים מסוג ECDSA ו-HMAC, MD5, SHA-1 ו-SHA-2 פונקציות גיבוב (hash) כדי שיתמכו בצורה תקינה בתכונות הנתמכות של מערכת Android Keystore באזור המבודד באופן מאובטח מהקוד שפועל הליבה (kernel) ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים קוד ליבה או מרחב משתמש שיכול לגשת למצב הפנימי של בסביבה מבודדת, כולל DMA. קוד פתוח של Android ב-upstream פרויקט (AOSP) עומד בדרישה הזו באמצעות ההטמעה של Trusty, אבל פתרון מבוסס ARM TrustZone או פתרון מאובטח על ידי צד שלישי או להטמיע בידוד תקין שמבוסס על hypervisor אפשרויות.
- [9.11/T-0-3] חייבים לבצע את מסך הנעילה בסביבת ההפעלה המבודדת ורק כאשר בוצעה בהצלחה, תאפשר את השימוש במפתחות שקשורים לאימות. מסך הנעילה חייבים לאחסן את פרטי הכניסה באופן שמאפשר רק ביצוע מבודד כדי לבצע אימות של מסך הנעילה. Android בהמשך הדרך פרויקט קוד פתוח מספק Gatekeeper Hardware Layer Abstraction Layer (HAL) ו-Trusty, שיכולים לשמש כדי למלא את הדרישה הזו.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
[9.11/T-0-4] חייבת לתמוך באימות עם מפתחות כאשר מפתח חתימת אימות (attestation) מוגן באמצעות חומרה מאובטחת, והחתימה מבוצעת בחומרה מאובטחת. חייבים
לשתף את המפתחות של חתימת האימות בין מספר גדול מספיק של מכשירים כדי למנוע את השימוש במפתחותמניעה לא לשמש כקבוע מזהי מכשיר ייחודיים.אחת הדרכים לעמוד בדרישה הזו היא לשתף אותו מפתח אימות, אלא אם לפחות 100,000 יחידות של מק"ט נתון שהופק. אם מפיקים יותר מ-100,000 יחידות של מק"ט, ייתכן שייעשה שימוש במפתח עבור כל 100,000 יחידות.
סיום הדרישות החדשות
חשוב לשים לב: אם ההטמעה של המכשיר כבר הופעלה בגרסה קודמת של Android
גרסה מסוימת, מכשיר כזה פטור מהדרישה לקיום מאגר מפתחות.
שמגובות בסביבת הפעלה מבודדת ותומכת באימות (attestation) של המפתח,
אלא אם מוצהר על התכונה android.hardware.fingerprint
שדורשת
מאגר מפתחות שמגובה על ידי סביבת הפעלה מבודדת.
אם בהטמעות של מכשירי טלוויזיה יש תמיכה במסך נעילה מאובטח:
- [9.11/T-1-1] המשתמשים חייבים לבחור באפשרות 'שינה' זמן קצוב למעבר ממצב לא נעול למצב נעול, עם הזמן המינימלי הקצוב לתפוגה שמוגדר ל-15 שניות או פחות.
אם בהטמעות של מכשירי טלוויזיה יש כמה משתמשים
לא מצהירים על דגל התכונה android.hardware.telephony
, הם:
- [9.5/T-2-1] חייבת לתמוך בפרופילים מוגבלים. תכונה שמאפשרת לבעלי מכשירים לנהל משתמשים נוספים ליכולות של המכשיר. עם פרופילים מוגבלים, בעלי המכשירים יכולים להגדיר במהירות סביבות נפרדות שבהן משתמשים נוספים יעבדו, יכולת לנהל הגבלות פרטניות יותר באפליקציות זמינים בסביבות האלה.
אם בהטמעות של מכשירי טלוויזיה יש כמה משתמשים
מצהירים על דגל התכונה android.hardware.telephony
, הם:
- [9.5/T-3-1] אסור שתמיכה מוגבלת אבל חייבים להתאים להטמעת AOSP של אמצעי הבקרה כדי לאפשר /להשבית את הגישה של משתמשים אחרים לשיחות קוליות ול-SMS.
אם בהטמעות של מכשירי טלוויזיה מוצהר על android.hardware.microphone
, הן:
- [9.8.2/T-4-1] חובה להציג את האינדיקטור של המיקרופון כאשר אפליקציה ניגשת לנתוני אודיו מהמיקרופון, אבל לא כאשר ניתן לגשת למיקרופון רק באמצעות HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService או אפליקציות עם התפקידים שצוינו בסעיף 9.1 הרשאות עם מזהה CDD C-3-X.
- [9.8.2/T-4-2] אסור להסתיר את האינדיקטור של המיקרופון עבור אפליקציות מערכת עם ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמשים.
אם בהטמעות של מכשירי טלוויזיה מוצהר על android.hardware.camera.any
, הן:
- [9.8.2/T-5-1] חובה להציג את האינדיקטור של המצלמה כאשר האפליקציה ניגשת לנתוני המצלמה בשידור חי, אבל לא כשהמצלמה אפליקציות שמשתמשות בתפקידים שצוינו בסעיף 9.1 ניגשות אליהם. הרשאות עם מזהה CDD [C-3-X].
- [9.8.2/T-5-2] אסור להסתיר את האינדיקטור של המצלמה עבור אפליקציות מערכת עם ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמשים.
2.3.6. תאימות לכלים למפתחים ולאפשרויות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
הטמעות של מכשירי טלוויזיה:
- Perfetto
- [6.1/T-0-1] חייבים לחשוף
/system/bin/perfetto
בינארית למשתמש המעטפת ש-cmdline פועל התיעוד של Perfetto. - [6.1/T-0-2] הקובץ הבינארי שמוגדר בקובץ חייב לקבל בתור קלט הגדרת Protobuf שתואמת לסכימה המוגדרת לתיעוד בלבד.
- [6.1/T-0-3] הקובץ הבינארי שמוגדר בקובץ חייב להיות כתוב בתור פלט מעקב של Protobuf התואם לסכימה המוגדרת לתיעוד בלבד.
- [6.1/T-0-4] חובה לספק, באמצעות Perfetto הבינארי, לפחות מקורות הנתונים שמתוארים לתיעוד בלבד.
- [6.1/T-0-5] הדימון עקב מעקב
חייבים להיות מופעלים כברירת מחדל (מאפיין המערכת
persist.traced.enable
).
- [6.1/T-0-1] חייבים לחשוף
סיום הדרישות החדשות
2.4. דרישות השעון
מכשיר Android Watch מתייחס להטמעה של מכשיר Android, שעונדים על הגוף, אולי על פרק כף היד.
הטמעות של מכשירי Android מסווגים כ'שעון' אם הם עומדים בכל הקריטריונים הבאים:
- מסך עם אורך אלכסון פיזי בטווח של 1.1 עד 2.5 אינץ'.
- חשוב לספק מנגנון לענידה על הגוף.
הדרישות הנוספות המפורטות בהמשך הקטע הזה הן ספציפיות ל-Android הטמעות של מכשירי השעון.
2.4.1. חומרה
הטמעות של מכשירי השעון:
[7.1.1.1/W-0-1] חייב להיות מסך עם גודל אלכסון פיזי בטווח של 1.1 עד 2.5 אינץ'.
[7.2.3/W-0-1] הפונקציה 'בית' חייבת להיות זמינה למשתמש, באמצעות הפונקציה Back למעט כאשר היא נמצאת ב-
UI_MODE_TYPE_WATCH
.[7.2.4/W-0-1] חייב לתמוך בקלט מסך מגע.
[7.3.1/W-SR-1] מומלץ מאוד לכלול תמונה עם 3 צירים מד תאוצה.
אם הטמעות של מכשירי שעון כוללות תמיכה ב-Vulkan:
- [7.1.4.2/W-1-1] חייב לעמוד בדרישות שצוינו בפרופיל Android Baseline 2021.
אם ההטמעות של מכשיר השעון כוללות מקלט GPS/GNSS ומדווחים על
יכולת לאפליקציות באמצעות התכונה android.hardware.location.gps
הם:
- [7.3.3/W-1-1] חובה לדווח על מדידות GNSS ברגע שהן נמצאים, גם אם המיקום המחושב מ-GPS/GNSS עדיין לא דווח.
- [7.3.3/W-1-2] חובה לדווח על GNSS על מערכים של פסאודונג' או על פסאודו-טווח בתנאים של שמיים פתוחים לאחר קביעת המיקום, קבוע או נע עם פחות מ-0.2 מטר לשנייה בריבוע תאוצה מספיקה כדי לחשב את המיקום בטווח של 20 מטרים, בטווח של 0.2 מטר לשנייה, לפחות ב-95% מהזמן.
אם ההטמעות של מכשיר השעון כוללות ג'ירוסקופ ב-3 צירים:
- [7.3.4/W-2-1] חייבת להיות יכולת למדוד שינויים בכיוון עד 1,000 מעלות לשנייה.
הטמעות של מכשירי השעון:
[7.4.3/W-0-1] חייב לתמוך ב-Bluetooth.
[7.6.1/W-0-1] חייב להיות לפחות 1GB של אחסון בלתי נדיף שזמין לנתונים פרטיים של האפליקציה (שנקראת גם מחיצת 'נתונים/נתונים').
[7.6.1/W-0-2] חייב להיות זיכרון בנפח של 416MB לפחות זמינים לליבה ולמרחב המשתמשים.
[7.8.1/W-0-1] חייב לכלול מיקרופון.
[7.8.2/W] יכול להיות פלט אודיו.
2.4.2. מולטימדיה
ללא דרישות נוספות.
2.4.3. תוכנות
הטמעות של מכשירי השעון:
- [3/W-0-1] חובה להצהיר על התכונה
android.hardware.type.watch
. - [3/W-0-2] חייבת לתמוך ב-uiMode = UI_mode_TYPE_Watch.
- [3.2.3.1/W-0-1] חובה לטעון מראש אחד או יותר אפליקציות או רכיבי שירות עם handler של Intent, כל הדפוסים של סינון Intent ציבורי שהוגדרו על ידי האפליקציה הבאה ה-Intents שמפורטים כאן.
הטמעות של מכשירי השעון:
- [3.8.4/W-SR-1] מומלץ מאוד כדי להטמיע עוזר דיגיטלי במכשיר שיטפל בפעולת ה-Assist.
אפליקציות בשעון שבהן מוצהר על android.hardware.audio.output
דגל פיצ'ר:
- [3.10/W-1-1] חייב לתמוך בנגישות של צד שלישי שירותים שונים.
- [3.10/W-SR-1] מומלץ מאוד לטעון מראש שירותי נגישות במכשיר שניתנים להשוואה עם פונקציונליות או גבוהה ממנה של 'גישה באמצעות מתג' ו-TalkBack (לשפות שנתמכות על ידי הרכיבים שהותקנו מראש שירותי נגישות של המרת טקסט לדיבור (TTS) כפי שמסופקים לפרויקט קוד פתוח של TalkBack.
אם יישומים של מכשיר צפייה מדווחים על התכונה android.hardware.audio.output, הם:
[3.11/W-SR-1] מומלץ מאוד לכלול מנוע TTS שתומך בשפות הזמינות במכשיר.
[3.11/W-0-1] חייבת לתמוך בהתקנה של מנועי TTS של צד שלישי.
2.4.4. ביצועים ועוצמה
אם ההטמעות של מכשיר השעון כוללות תכונות לשיפור השימוש במכשיר שכלולות ב-AOSP או מרחיבות את התכונות שכלולות ב-AOSP ב-AOSP, ריכזנו כאן:
- [8.3/W-SR-1] מומלץ מאוד לספק לאפשר למשתמשים להציג את כל האפליקציות שפטורות מבהמתנה של אפליקציה, נמנום מצבי חיסכון בסוללה.
- [8.3/W-SR-2] מומלץ מאוד לספק מבחינת המשתמש: להפעיל ולהשבית את תכונת החיסכון בסוללה.
הטמעות של מכשירי השעון:
- [8.4/W-0-1] חייב לספק פרופיל כוח לכל רכיב שמגדיר את ערך הצריכה הנוכחית לגבי כל רכיב חומרה והתרוקנות משוערת של הסוללה שנגרמה על ידי הרכיבים לאורך זמן, כפי שמתואר באתר פרויקט הקוד הפתוח של Android.
- [8.4/W-0-2] חובה לדווח על כל אספקת החשמל במיליאמפר שעות (mAh).
- [8.4/W-0-3] חובה לדווח על עוצמת המעבד (CPU)
צריכה עבור כל מזהה ייחודי (UID) של כל תהליך. פרויקט הקוד הפתוח של Android עומד
באמצעות ההטמעה של מודול הליבה של
uid_cputime
. - [8.4/W-0-4] חייבים להשתמש בחשמל הזה
זמינה דרך
adb shell dumpsys batterystats
פקודת מעטפת למפתח האפליקציה. - צריך לשייך את [8.4/W] אל רכיב החומרה עצמו אם אין אפשרות לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.
2.4.5. דגם אבטחה
הטמעות של מכשירי השעון:
- [9/W-0-1] חובה להצהיר על
android.hardware.security.model.compatible
.
אם ההטמעות של מכשיר השעון כוללות משתמשים מרובים וגם
לא מצהירים על דגל התכונה android.hardware.telephony
, הם:
- [9.5/W-1-1] חייבת לתמוך בפרופילים מוגבלים. תכונה שמאפשרת לבעלי מכשירים לנהל משתמשים נוספים ליכולות של המכשיר. עם פרופילים מוגבלים, בעלי המכשירים יכולים להגדיר במהירות סביבות נפרדות שבהן משתמשים נוספים יעבדו, יכולת לנהל הגבלות פרטניות יותר באפליקציות זמינים בסביבות האלה.
אם ההטמעות של מכשיר השעון כוללות משתמשים מרובים וגם
מצהירים על דגל התכונה android.hardware.telephony
, הם:
- [9.5/W-2-1] אסור שתמיכה מוגבלת אבל חייבים להתאים להטמעת AOSP של אמצעי הבקרה כדי לאפשר /להשבית את הגישה של משתמשים אחרים לשיחות קוליות ול-SMS.
אם בהטמעות של מכשירים יש מסך נעילה מאובטח וכולל סביבה אמינה אחת או יותר שמטמיעה את TrustAgentService
System API, הן:
- [9.11.1/W-1-1] חובה לאתגר את המשתמש באחת משיטות האימות הראשיות המומלצות (למשל: קוד אימות, קו ביטול נעילה, סיסמה) בתדירות גבוהה יותר מפעם אחת בכל 72 שעות.
2.5. דרישות לגבי רכב
המונח הטמעה של Android Automotive מתייחס ליחידה הראשית של הרכב שפועלת Android כמערכת הפעלה לחלק מהמערכת או מכולן ו/או פונקציות של מידע ובידור.
הטמעות של מכשירי Android מסווגים ככלי רכב אם מוצהר על כך
את התכונה android.hardware.type.automotive
או לענות על כל הקריטריונים הבאים
קריטריונים.
- שמוטמעים כחלק מכלי רכב או שניתן לחבר אותם.
- משתמשים במסך שבשורת המושב של הנהג בתור המסך הראשי.
הדרישות הנוספות המפורטות בהמשך הקטע הזה הן ספציפיות ל-Android הטמעת מכשירים בכלי רכב.
2.5.1. חומרה
הטמעות של מכשירים בכלי רכב:
- [7.1.1.1/A-0-1] חייב להיות מסך 6 לפחות אינץ' בגודל אלכסון פיזי.
- [7.1.1.1/A-0-2] חייבת להיות פריסה של גודל מסך לפחות 750 dp x 480 dp
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם בהטמעות של מכשירי רכב יש תמיכה בריבוי משתמשים בו-זמנית
(כשמספר משתמשי Android יכולים לבצע פעולות במכשיר בו-זמנית,
וכל אחד מהם משתמש במסך משלו
config_multiuserVisibleBackgroundUsers
מופעלת), הם:
- ל-[7.1.1.1/A-1-1] חייב להיות מסך נפרד של
בגודל אלכסון פיזי באורך של 6 אינץ' לפחות לכל אזור נוסעים.
המסך הראשי. צריך לתייג את זה בתור
CarOccupantZoneManager.DISPLAY_TYPE_MAIN
לכל אזור נוסעים. - [7.1.1.1/A-1-2] חייבת להיות פריסה של גודל מסך לפחות 750 dp x 480 dp לכל מסך ראשי.
סיום הדרישות החדשות
אם בהטמעות של מכשירי כלי רכב יש תמיכה ב-OpenGL ES 3.1:
- [7.1.4.1/A-0-1] חובה להצהיר OpenGL ES 3.1 ואילך.
- [7.1.4.1/A-0-2] חייבת לתמוך ב-Vulkan 1.1.
- [7.1.4.1/A-0-3] חובה לכלול טעינה של Vulkan וייצא את כל הסמלים.
אם הטמעות של מכשירים בכלי רכב כוללות תמיכה ב-Vulkan:
- [7.1.4.2/A-1-1] חייב לעמוד בדרישות שצוינו בפרופיל Android Baseline 2021.
הטמעות של מכשירים בכלי רכב:
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [7.1.7/A-0-1] חובה להגדיר
מסכים משניים
בטווח הראייה של הנהג,
FLAG_PRIVATE
.
סיום הדרישות החדשות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [7.2.3/A-0-1] חייב לספק
דף הביתופונקציות 'הקודם', ו-MAY לספקחזרה והפונקציותאחרונות.
סיום הדרישות החדשות
- [7.2.3/A-0-2] חייבים לשלוח גם בלחיצה רגילה וגם בלחיצה ארוכה
אירוע של פונקציית 'הקודם' (
KEYCODE_BACK
) לאפליקציה בחזית. - [7.3/A-0-1] חובה להטמיע את התוכן ולדווח עליו
GEAR_SELECTION
,NIGHT_MODE
,PERF_VEHICLE_SPEED
וגםPARKING_BRAKE_ON
. - [7.3/A-0-2] הערך של
NIGHT_MODE
הדגל חייב להיות תואם למצב היום/הלילה של מרכז הבקרה והוא צריך להתבסס על קלט מחיישן אור הסביבה. יכול להיות שחיישן אור הסביבה הבסיסי יהיה זהה בתור PhotoMeter. - [7.3/A-0-3] חובה לספק שדה מידע נוסף לחיישן
TYPE_SENSOR_PLACEMENT
כחלק מ-SensorAdditionalInfo לכל חיישן שמסופק. - [7.3/A-SR1] תמונת השער מיקום באמצעות שילוב של GPS/GNSS עם חיישנים נוספים. אם בוחרים במיקום לדעתך, מומלץ מאוד ליישם ולדווח החיישן התואם סוגים שונים ו/או מזהי נכסי רכב בשימוש.
[7.3/A-0-4] המיקום נשלחה בקשה דרך LocationManager#requestLocationUpdates() אסור שתהיה התאמה למפה.
[7.3.1/A-0-4] חייב לעמוד בדרישות של Android מערכת הקואורדינטות של חיישן הרכב.
[7.3/A-SR-1] מומלץ מאוד להוסיף תמונה עם 3 צירים מד תאוצה וג'ירוסקופ עם 3 צירים.
[7.3/A-SR-2] מומלץ מאוד ליישם את ההמלצה ולדווח עליה חיישן
TYPE_HEADING
.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם בהטמעות של מכשירי רכב יש תמיכה בריבוי משתמשים בו-זמנית
(כשמספר משתמשי Android יכולים לבצע פעולות במכשיר בו-זמנית,
וכל אחד מהם משתמש במסך משלו
config_multiuserVisibleBackgroundUsers
מופעלת), הם:
- [7.3/A-1-1] חייבים להגדיר את
NIGHT_MODE
מסמנים באופן עקבי ערך זהה למצב היום/הלילה של מרכז הבקרה כל המסכים, כולל המסכים של המושבים האחוריים.
סיום הדרישות החדשות
אם ההטמעות של מכשירים ב-Automotive כוללות מד תאוצה:
- [7.3.1/A-1-1] צריכה להיות אפשרות לדווח על אירועים עד לתדירות מסוימת של לפחות 100Hz.
אם יישומי המכשירים כוללים מד תאוצה ב-3 צירים, הם:
- [7.3.1/A-SR-1] מומלץ מאוד להטמיע את חיישן מורכב למד תאוצה עם צירים מוגבלים.
אם בהטמעות של מכשירים בכלי רכב יש מד תאוצה שנמוך מ- הם:
- [7.3.1/A-1-3] חובה להטמיע את התוכן ולדווח עליו
חיישן
TYPE_ACCELEROMETER_LIMITED_AXES
. - [7.3.1/A-1-4] חובה להטמיע את התוכן ולדווח עליו
חיישן
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
אם ההטמעות של מכשירים בכלי רכב כוללות ג'ירוסקופ, הן:
- [7.3.4/A-2-1] צריכה להיות אפשרות לדווח על אירועים עד לתדירות מסוימת של לפחות 100Hz.
- [7.3.4/A-2-3] חייבת להיות יכולת למדוד שינויי כיוון עד 250 מעלות לשנייה.
- [7.3.4/A-SR-1] מומלץ מאוד להגדיר את טווח המדידה של הג'ירוסקופ עד 250dps+ כדי למקסם את הרזולוציה ככל האפשר.
אם ההטמעות של מכשירים בכלי רכב כוללות ג'ירוסקופ ב-3 צירים:
- [7.3.4/A-SR-2] מומלץ מאוד להטמיע את חיישן מרוכב לג'ירוסקופ עם צירים מוגבלים.
אם ההטמעות של מכשירים בכלי רכב כוללות ג'ירוסקופ עם פחות מ-3 צירים:
- [7.3.4/A-4-1] חובה להטמיע את התוכן ולדווח עליו
חיישן
TYPE_GYROSCOPE_LIMITED_AXES
. - [7.3.4/A-4-2] חובה להטמיע את התוכן ולדווח עליו
חיישן
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
אם ההטמעות של מכשיר כלי הרכב כוללות מקלט GPS/GNSS, אבל לא כוללות קישוריות נתונים המבוססת על רשת סלולרית, הן:
- [7.3.3/A-3-1] יש לקבוע את המיקום בפעם הראשונה מקלט ה-GPS/GNSS מופעל או לאחר יותר מ-4 ימים בתוך 60 שניות.
- [7.3.3/A-3-2] חייב לעמוד בקריטריונים של 'זמן עד לתיקון הראשון' כפי כמתואר בסעיפים 7.3.3/C-1-2 ו-7.3.3/C-1-6 לגבי כל שאר בקשות המיקום (כלומר בקשות שזו לא הפעם הראשונה) או אחרי 4 ימים ומעלה). הדרישה 7.3.3/C-1-2 היא בדרך כלל נפגשים בכלי רכב ללא קישוריות נתונים לרשת סלולרית, באמצעות חיזוי מסלול GNSS שחושב על המקלט, או באמצעות את המיקום הידוע האחרון של הרכב, יחד עם היכולת להביא בחשבון למשך 60 שניות לפחות, עם דיוק מיקום שמספק 7.3.3/C-1-3, או שילוב של שניהם.
אם ההטמעות של כלי הרכב כוללות חיישן TYPE_HEADING
, הן:
- [7.3.4/A-4-3] חייבת להיות אפשרות לדווח על אירועים עד לתדירות מסוימת של לפחות 1Hz.
- [7.3.4/A-SR-3] STRONGLY_recommended לדיווח על אירועים עד של לפחות 10Hz.
- הוא צריך להיות מתייחס לצפון אמיתי.
- השירותים אמורים להיות זמינים גם כשהרכב יציב.
- צריכה להיות רזולוציה של מעלה אחת לפחות.
הטמעות של מכשירים בכלי רכב:
- [7.4.3/A-0-1] חייב לתמוך ב-Bluetooth ואמור תמיכה ב-Bluetooth LE.
- [7.4.3/A-0-2] הטמעות של Android Automotive
הנתונים חייבים לתמוך בפרופילים הבאים של Bluetooth:
- שיחות טלפון באמצעות פרופיל Hands-Free (HFP).
- הפעלת מדיה בפרופיל הפצת אודיו (A2DP).
- הפקד להפעלת מדיה בפרופיל שלט רחוק (AVRCP).
- שיתוף אנשי קשר באמצעות פרופיל הגישה לספר הטלפונים (PBAP).
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [7.4.3/A-SR-1] מומלץ מאוד לתמיכה פרופיל גישה להודעות (MAP) אם המכשיר מוגדר לאזור הנהג/ת.
סיום הדרישות החדשות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם בהטמעות של מכשירי רכב יש תמיכה בריבוי משתמשים בו-זמנית
(כשמספר משתמשי Android יכולים לבצע פעולות במכשיר בו-זמנית,
וכל אחד מהם משתמש במסך משלו
config_multiuserVisibleBackgroundUsers
מופעלת), הם:
- [7.4.3/A-1-1] חייב להיות עצמאי ולא להפריע עם חוויית BT.
סיום הדרישות החדשות
הטמעות של מכשירים בכלי רכב:
- [7.4.5/A] צריכה לכלול תמיכה ברשת סלולרית באמצעות קישוריות נתונים מבוססת-רשת.
- [7.4.5/A] יכול להיות שתשתמשו ב-System API
קבוע
NetworkCapabilities#NET_CAPABILITY_OEM_PAID
עבור הרשתות שאמורות להיות זמינות לאפליקציות המערכת.
אם יישומי המכשיר כוללים תמיכה בשידורי AM/FM, וחשיפה את הפונקציונליות של כל אפליקציה, הם:
- [7.4/A-1-1]
חובה להצהיר על תמיכה ב-
FEATURE_BROADCAST_RADIO
.
מצלמה אחורית היא מצלמה שפונה לכל העולם שאפשר למקם בכל אחד מניחים אותו על הרכב ופונים לחלק החיצוני של תא הנהג ברכב. כלומר, תמונות סצנות בצד הרחוק של גוף הרכב, כמו מצלמה אחורית.
מצלמה קדמית היא מצלמה שפועלת מול המשתמש ואפשר למקם אותה בכל מניחים את המכשיר על הרכב ופונים אליו בתוך תא המטען. זה זה של המשתמש, למשל לשיחות ועידה בווידאו ואפליקציות דומות.
הטמעות של מכשירים בכלי רכב:
- [7.5/A-SR-1] מומלץ מאוד לכלול תווית אחת או יותר שמיועדות לעולם מצלמות.
- עשויים לכלול מצלמה אחת או יותר שמיועדות למשתמש.
- [7.5/A-SR-2] מומלץ מאוד לתמוך בשידורים בו-זמנית של כמה מצלמות.
אם ההטמעות של כלי רכב כוללות לפחות מצלמה אחת, עולמיים, בשביל מצלמה כזאת, הם:
- [7.5/A-1-1] חייבים לכוון את הכיוון של הממד הארוך של המצלמה עם צירים של חיישני רכב של Android במישור X-Y.
- [7.5/A-SR-3] מומלץ מאוד להשתמש במיקוד קבוע או ב-EDOF חומרה (עומק שדה מורחב)
- [7.5/A-1-2] חייבת להיות המצלמה הראשית שפונה לעולם. עם מזהה המצלמה הנמוך ביותר.
אם ההטמעות של כלי רכב כוללות לפחות מצלמה אחת, גלוי למשתמש ואז:
- [7.5/A-2-1] המצלמה הראשית בפני המשתמש חייבת להיות המצלמה הקדמית עם מזהה המצלמה הנמוך ביותר.
- יכול להיות שהגודל של המצלמה יהיה מכוון כך שהממד הארוך של המצלמה יתאים ל-X-Y מישור של צירים של חיישנים לרכב Android.
אם ההטמעות במכשירים של כלי רכב כוללות מצלמה שאפשר לגשת אליה דרך
android.hardware.Camera
או android.hardware.camera2
API, ואז:
- [7.5/A-3-1] חייב לעמוד בדרישות הליבה לגבי המצלמה בסעיף 7.5.
אם ההטמעות של מכשירי כלי רכב כוללות מצלמה שאינה נגישה
באמצעות API android.hardware.Camera
או android.hardware.camera2
, ואז
הם:
- [7.5/A-4-1] חייבת להיות גישה דרך שירות מערכת תצוגה מורחבת.
אם ההטמעות של מכשיר כלי רכב כוללות מצלמה אחת או יותר שאפשר לגשת אליהן דרך עבור מצלמה כזו, שירות של מערכת תצוגה מורחבת:
- [7.5/A-5-1] אסור לסובב או לשקף את התצוגה המקדימה של המצלמה באופן אופקי.
- [7.5/A-SR-4] מומלץ מאוד שהרזולוציה תהיה 1.3 לפחות מגה פיקסל.
אם ההטמעה של מכשירים בכלי רכב כוללת מצלמה אחת או יותר
ניתן לגשת אליו דרך 'שירות תצוגה מורחבת' וגם דרך android.hardware.Camera
או android.hardware.Camera2
, ואז בשביל מצלמה כזו הם:
- [7.5/A-6-1] חובה לדווח על אותו מזהה מצלמה.
אם ההטמעות של מכשירים בכלי רכב מספקות API קנייני של מצלמה:
- [7.5/A-7-1] חובה להטמיע API כזה של מצלמה באמצעות
android.hardware.camera2
API או Extended View System API.
הטמעות של מכשירים בכלי רכב:
[7.6.1/A-0-1] חייב להיות בנפח של 4 GB לפחות אחסון בלתי תנודתי שזמין לנתונים פרטיים של האפליקציה (מחיצה
/data
).[7.6.1/A] צריך לקבוע את הפורמט של מחיצת הנתונים כדי להציע ביצועים משופרים ומשך חיים משופר באחסון Flash (לדוגמה, באמצעות מערכת הקבצים
f2fs
).
אם הטמעות של מכשירי Automotive מספקות אחסון חיצוני משותף באמצעות באחסון הפנימי שלא ניתן להסרה, הן:
- [7.6.1/A-SR-1] מומלץ מאוד לצמצם
תקורת קלט/פלט (I/O) על פעולות המבוצעות באחסון החיצוני, לדוגמה על ידי
באמצעות
SDCardFS
.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם בהטמעות של מכשירי רכב יש תמיכה בריבוי משתמשים בו-זמנית
(כשמספר משתמשי Android יכולים לבצע פעולות במכשיר בו-זמנית,
וכל אחד מהם משתמש במסך משלו
config_multiuserVisibleBackgroundUsers
מופעלת), הם:
- [7.6.1/A-1-1] חייב להיות במכונת AAOS אחת,
נפח אחסון בלתי נדיף בנפח של 4GB לפחות לכל משתמש Android שעובד בו-זמנית
זמין לנתונים פרטיים של האפליקציה (מחיצה
/data
).
סיום הדרישות החדשות
אם ההטמעה של מכשירי כלי רכב היא בגרסת 64 ביט:
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
[7.6.1/A-2-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות בגודל של 816MB לפחות לכל תצוגה ראשית אם אחת מערכי הדחיסות הבאות נמצאת בשימוש:
- 280dpi או פחות במסכים קטנים/רגילים
- ldpi או פחות במכשירים גדולים במיוחד
- mdpi או פחות במכשירים עם מסכים גדולים
[7.6.1/A-2-2] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות בגודל 944MB לפחות לכל תצוגה ראשית אם אחת מערכי הדחיסות הבאות נמצאת בשימוש:
- xhdpi ומעלה במסכים קטנים/רגילים
- hdpi ומעלה במסכים גדולים
- mdpi ומעלה במסכים גדולים במיוחד
[7.6.1/A-2-3] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות בגודל של 1280MB לפחות לכל תצוגה ראשית אם אחת מערכי הדחיסות הבאות נמצאת בשימוש:
- 400 dpi או יותר במסכים קטנים/רגילים
- xhdpi ומעלה במסכים גדולים
- tvdpi ומעלה במסכים גדולים במיוחד
[7.6.1/A-2-4] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות בגודל של 1,824MB לפחות לכל תצוגה ראשית אם אחת מערכי הדחיסות הבאות נמצאת בשימוש:
- 560dpi ומעלה במסכים קטנים/רגילים
- 400 dpi או יותר במסכים גדולים
- xhdpi ומעלה במסכים גדולים במיוחד
שימו לב ש"הזיכרון שזמין לליבה ולמרחב המשתמשים" שלמעלה מתייחס מקום זיכרון בנוסף לכל זיכרון שכבר מיועד לחומרה כמו רדיו, וידאו וכו', שלא נמצאים במסגרת הליבה שליטה בהטמעות של מכשירים.
סיום הדרישות החדשות
הטמעות של מכשירים בכלי רכב:
- [7.7.1/A] צריכה לכלול יציאת USB שתומכת במצב היקפי.
הטמעות של מכשירים בכלי רכב:
- [7.8.1/A-0-1] חייב לכלול מיקרופון.
הטמעות של מכשירים בכלי רכב:
- [7.8.2/A-0-1] חובה לכלול פלט אודיו וצריך להצהיר עליו
android.hardware.audio.output
.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם בהטמעות של מכשירי רכב יש תמיכה בריבוי משתמשים בו-זמנית
(כשמספר משתמשי Android יכולים לבצע פעולות במכשיר בו-זמנית,
וכל אחד מהם משתמש במסך משלו
config_multiuserVisibleBackgroundUsers
מופעלת), הם:
- [7.8.2/A-1-1] צריך להיות מכשיר לפלט אודיו לכל ראשי להציג בכמה מערכות בו-זמנית של משתמשים.
- [7.8.2/A-1-2] חייב להיות אזור אודיו של הנהג שמכסה את רמקול של תא הנהג ברכב. אפשר לשתף את הקול של הנהג/ת באזור הנוסע הקדמי תחום מסוים או יכול להיות פלט אודיו משלו.
סיום הדרישות החדשות
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
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם בהטמעות של מכשירי רכב יש תמיכה בריבוי משתמשים בו-זמנית
(כשמספר משתמשי Android יכולים לבצע פעולות במכשיר בו-זמנית,
וכל אחד מהם משתמש במסך משלו
config_multiuserVisibleBackgroundUsers
מופעלת), הם:
- [5.5.3/A-1-1] חייבים להגדיר עקומות נפח זהות עבור כל שידורי פלט האודיו ממפים לאותה קבוצת עוצמת קול שהוגדרה קובץ תצורת האודיו ברכב.
סיום הדרישות החדשות
2.5.3. תוכנות
הטמעות של מכשירים בכלי רכב:
[3/A-0-1] חובה להצהיר על התכונה
android.hardware.type.automotive
.[3/A-0-2] חייבת להיות תמיכה ב-uiMode =
UI_MODE_TYPE_CAR
.[3/A-0-3] חייבת לתמוך בכל ממשקי ה-API הציבוריים
android.car.*
מרחב שמות.
אם ההטמעות של מכשירים בכלי רכב מספקות API קנייני באמצעות
android.car.CarPropertyManager
עם
android.car.VehiclePropertyIds
,
הם:
- [3/A-1-1] אסור לשייך הרשאות מיוחדות למערכת לשימוש של האפליקציה במאפיינים האלה, או למנוע מאפליקציות של צד שלישי משימוש במאפיינים האלה.
- [3/A-1-2] אסור לשכפל נכס רכב שכבר קיימת ב-SDK.
הטמעות של מכשירים בכלי רכב:
[3.2.1/A-0-1] חובה לתמוך בכולם ולאכוף את כולם קבועים של הרשאות, כפי שמתואר בדף העזר בנושא הרשאת רכב.
[3.2.3.1/A-0-1] חובה לטעון מראש אחד או יותר אפליקציות או רכיבי שירות עם handler של Intent, לכל הדפוסים של סינון Intent ציבורי שמוגדרים לפי ה-Intentים הבאים של אפליקציות המפורטים כאן.
[3.4.1/A-0-1] חובה לספק מידע מלא של ה-API של
android.webkit.Webview
.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [3.8/A-0-1] אסור לאפשר למשתמשים משניים מלאים שאינם המשתמשים הקיימים בחזית להפעיל פעילויות ולקבל גישה לממשק המשתמש בכל המסכים.
אם בהטמעות של מכשירי רכב יש תמיכה בריבוי משתמשים בו-זמנית
(כשמספר משתמשי Android יכולים לבצע פעולות במכשיר בו-זמנית,
וכל אחד מהם משתמש במסך משלו
config_multiuserVisibleBackgroundUsers
מופעלת),
למשתמשים משניים מלאים שאינם המשתמשים הנוכחיים בחזית
אבל יש להם גישה לממשק המשתמש במסך, הם:
[3.8/A-1-1] חובה להטמיע את הרשימה המוגדרת מראש הבאה של
UserRestrictions
:[3.8/A-1-2] אסור לאפשר למשתמש הזה כדי לשנות את ההגדרות הבאות לכל משתמש אחר, דרך ההגדרות או דרך API:
- מצב יום/לילה
- שילוב של שפה ואזור
- date
- זמן
- אזור זמן
- תכונות של צבע התצוגה (כולל בהירות, תאורת לילה, 'שימוש חכם בדיגיטל' - גווני אפור וצמצום צבעים בהירים)
סיום הדרישות החדשות
הטמעות של מכשירים בכלי רכב:
[3.8.3/A-0-1] חייב להופיע במסך התראות שנעשה בהן שימוש ב
Notification.CarExtender
API כשמתקבלת בקשה לאפליקציות של צד שלישי.[3.8.4/A-SR-1] מומלץ מאוד כדי להטמיע עוזר דיגיטלי במכשיר שיטפל בפעולת ה-Assist.
אם ההטמעות של מכשירים בכלי רכב כוללות לחצן 'לחיצה לדיבור':
- [3.8.4/A-1-1] חייבים להשתמש בלחיצה קצרה של
לחצן הדחיפה לדיבור בתור האינטראקציה הייעודית להפעלת
אפליקציית עזרה שהמשתמש בוחר. כלומר, האפליקציה שמטמיעה
VoiceInteractionService
.
הטמעות של מכשירים בכלי רכב:
- [3.8.3.1/A-0-1] חייב להיות תקין
לעבד משאבים כפי שמתואר ב
Notifications on Automotive OS
מסמכי תיעוד בנושא SDK. - [3.8.3.1/A-0-2] חייב להופיע
PLAY ו-MUTE לפעולות של התראות במקום אלה שסופקו על ידי
Notification.Builder.addAction()
- [3.8.3.1/A] אמורה להגביל את שימוש במשימות ניהול עשירות, כמו פקדי ערוץ לכל התראה. ייתכן להשתמש בעלות משתלמת למשתמש לכל אפליקציה כדי להפחית את הפקדים.
אם בהטמעות של מכשירי רכב יש תמיכה בנכסי HAL של משתמשים:
- [3.9.3/A-1-1] חובה להטמיע את כל
מאפיינים של מחזור החיים של משתמש
INITIAL_USER_INFO
,SWITCH_USER
,CREATE_USER
,REMOVE_USER
.
הטמעות של מכשירים בכלי רכב:
- [3.14/A-0-1] חייב לכלול מסגרת של ממשק משתמש לתמיכה אפליקציות צד שלישי שמשתמשות בממשקי API של מדיה, כפי שמתואר בסעיף 3.14.
- [3.14/A-0-2] חייב לאפשר למשתמש לבצע אינטראקציה באופן בטוח עם אפליקציות מדיה בזמן הנהיגה.
- [3.14/A-0-3] חייב לתמוך ב
CAR_INTENT_ACTION_MEDIA_TEMPLATE
פעולת Intent מרומזת עםCAR_EXTRA_MEDIA_PACKAGE
נוסף. - [3.14/A-0-4] חייבת להיות אפשרות לנווט אל של אפליקציית מדיה העדפה activity, אבל חייבים להפעיל אותה רק כשההגבלות על חוויית המשתמש ברכב לא בתוקף.
- [3.14/A-0-5] חייב להופיע במסך
הודעות שגיאה
שהוגדרו על ידי אפליקציות מדיה, וחייב לתמוך בתוספות האופציונליות
ERROR_RESOLUTION_ACTION_LABEL
ו-ERROR_RESOLUTION_ACTION_INTENT
. - [3.14/A-0-6] חייבת לתמוך במחיר של חיפוש בתוך האפליקציה עבור אפליקציות שתומכות בחיפוש.
- [3.14/A-0-7] חייב לכבד
CONTENT_STYLE_BROWSABLE_HINT
וגםCONTENT_STYLE_PLAYABLE_HINT
הגדרות בזמן הצגת MediaBrowser ההיררכיה.
אם ההטמעות של מכשירי כלי רכב כוללות אפליקציית מרכז אפליקציות שמוגדרת כברירת מחדל, הן:
- [3.14/A-1-1] חובה לכלול שירותי מדיה ולפתוח אותם
עם
CAR_INTENT_ACTION_MEDIA_TEMPLATE
בכוונה טובה.
הטמעות של מכשירים בכלי רכב:
- [3.8/A] עשויים להגביל את האפליקציה
בקשות לעבור למצב מסך מלא כמו שמתואר במאמר
immersive documentation
. - [3.8/A] יכול להיות להשאיר את שורת הסטטוס וגם שסרגל הניווט גלוי כל הזמן.
- [3.8/A] עשויים להגביל את האפליקציה בקשות לשנות את הצבעים מאחורי רכיבי ממשק המשתמש של המערכת, כדי להבטיח את הרכיבים האלה אפשר לראות בבירור כל הזמן.
2.5.4. ביצועים ועוצמה
הטמעות של מכשירים בכלי רכב:
- [8.2/A-0-1] חובה לדווח על מספר
בייטים שנקראים ונכתבים באחסון לא תנודתי לכל UID של כל תהליך, כך שה
הנתונים הסטטיסטיים זמינים למפתחים דרך System API
android.car.storagemonitoring.CarStorageMonitoringManager
. פתיחת Android פרויקט המקור עומד בדרישה באמצעות מודול הליבהuid_sys_stats
. - [8.3/A-1-3] חייבת לתמוך במצב גראז'.
- [8.3/A] צריכה להיות במצב חנייה לפחות במשך הזמן
15 דקות אחרי כל נסיעה, אלא אם:
- הסוללה מרוקנת.
- לא נקבעו משימות שלא פעילות.
- הנהג יוצא ממצב החניה.
- [8.4/A-0-1] חייב לספק פרופיל כוח לכל רכיב שמגדיר את ערך הצריכה הנוכחית לגבי כל רכיב חומרה והתרוקנות משוערת של הסוללה שנגרמה על ידי הרכיבים לאורך זמן, כפי שמתואר באתר פרויקט הקוד הפתוח של Android.
- [8.4/A-0-2] חובה לדווח על כל אספקת החשמל במיליאמפר שעות (mAh).
- [8.4/A-0-3] חובה לדווח על עוצמת המעבד (CPU)
צריכה עבור כל מזהה ייחודי (UID) של כל תהליך. פרויקט הקוד הפתוח של Android עומד
באמצעות ההטמעה של מודול הליבה של
uid_cputime
. - צריך לשייך את [8.4/A] אל רכיב החומרה עצמו אם אין אפשרות לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.
- [8.4/A-0-4] חייבים להשתמש בחשמל הזה
זמינה דרך
adb shell dumpsys batterystats
פקודת מעטפת למפתח האפליקציה.
2.5.5. דגם אבטחה
אם הטמעות של מכשירי רכב תומכים במספר משתמשים, הן:
- [9.5/A-1-1] אסור לאפשר למשתמשים לקיים אינטראקציה עם או לעבור אל משתמש במערכת ללא GUI, מלבד הקצאת מכשירים.
- [9.5/A-1-2] חייב לעבור למשתמש משני
לפני
BOOT_COMPLETED
. - [9.5/A-1-3] חייבת לתמוך באפשרות ליצור משתמש אורח גם כשהגעת למספר המשתמשים המקסימלי במכשיר.
אם בהטמעות של מכשירים ב-Automotive מוצהר על android.hardware.microphone
,
הם:
- [9.8.2/A-1-1] חובה להציג את האינדיקטור של המיקרופון כאשר
אפליקציה ניגשת לנתוני אודיו מהמיקרופון, אבל לא כאשר
יש גישה למיקרופון רק ב-
HotwordDetectionService
,SOURCE_HOTWORD
.ContentCaptureService
או אפליקציות עם התפקידים שצוינו ב- סעיף 9.1 עם מזהה CDD [C-4-X]. - [9.8.2/A-1-2] אסור להסתיר את האינדיקטור של המיקרופון עבור אפליקציות מערכת עם ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמשים.
- [9.8.2/A-1-3] למשתמש חייב להיות אפשרות לעבור למצב של את המיקרופון באפליקציית ההגדרות.
אם בהטמעות של מכשירים ב-Automotive צוין android.hardware.camera.any
, אז
הם:
- [9.8.2/A-2-1] חובה להציג את האינדיקטור של המצלמה כאשר האפליקציה ניגשת לנתוני המצלמה בשידור חי, אבל לא כשהמצלמה אפליקציות שיש להן גישה לתפקידים שמוגדרים בהם, הרשאות סעיף 9.1 עם מזהה CDD [C-4-X].
- [9.8.2/A-2-2] אסור להסתיר את האינדיקטור של המצלמה עבור אפליקציות מערכת עם ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמשים.
- [9.8.2/A-2-3] המשתמש חייב לאפשר למשתמש להחליף את מצב המצלמה באפליקציית ההגדרות.
- [9.8.2/A-2-4] חובה להציג אפליקציות אחרונות ואפליקציות פעילות באמצעות המצלמה כפי שהוחזר
החל מ-
PermissionManager.getIndicatorAppOpUsageData()
, יחד עם הודעות שיוך (Attribution) שמשויכות אליהן.
הטמעות של מכשירים בכלי רכב:
- [9/A-0-1] חובה להצהיר על
android.hardware.security.model.compatible
. - [9.11/A-0-1] חובה לגבות את ההטמעה של מאגר המפתחות עם סביבת הפעלה מבודדת.
- [9.11/A-0-2] חייבות להיות הטמעות של RSA, AES, אלגוריתמים קריפטוגרפיים מסוג ECDSA ו-HMAC, MD5, SHA-1 ו-SHA-2 פונקציות גיבוב (hash) כדי שיתמכו בצורה תקינה בתכונות הנתמכות של מערכת Android Keystore באזור המבודד באופן מאובטח מהקוד שפועל הליבה (kernel) ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים קוד ליבה או מרחב משתמש שיכול לגשת למצב הפנימי של בסביבה מבודדת, כולל DMA. קוד פתוח של Android ב-upstream פרויקט (AOSP) עומד בדרישה הזו באמצעות ההטמעה של Trusty, אבל פתרון מבוסס ARM TrustZone או פתרון מאובטח על ידי צד שלישי או להטמיע בידוד תקין שמבוסס על hypervisor אפשרויות.
- [9.11/A-0-3] חייבים להפעיל את מסך הנעילה בסביבת ההפעלה המבודדת ורק כאשר בוצעה בהצלחה, תאפשר את השימוש במפתחות שקשורים לאימות. מסך הנעילה חייבים לאחסן את פרטי הכניסה באופן שמאפשר רק ביצוע מבודד כדי לבצע אימות של מסך הנעילה. Android בהמשך הדרך פרויקט קוד פתוח מספק Gatekeeper Hardware Layer Abstraction Layer (HAL) ו-Trusty, שיכולים לשמש כדי למלא את הדרישה הזו.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
[9.11/A-0-4] חייבת לתמוך באימות עם מפתחות כאשר מפתח חתימת אימות (attestation) מוגן באמצעות חומרה מאובטחת, והחתימה מבוצעת בחומרה מאובטחת. חייבים
לשתף את המפתחות של חתימת האימות בין מספר גדול מספיק של מכשירים כדי למנוע את השימוש במפתחותמניעה לא לשמש כקבוע מזהי מכשיר ייחודיים.אחת הדרכים לעמוד בדרישה הזו היא לשתף אותו מפתח אימות, אלא אם לפחות 100,000 יחידות של מק"ט נתון שהופק. אם מפיקים יותר מ-100,000 יחידות של מק"ט, ייתכן שייעשה שימוש במפתח עבור כל 100,000 יחידות.
סיום הדרישות החדשות
חשוב לשים לב: אם ההטמעה של המכשיר כבר הופעלה בגרסה קודמת של Android
גרסה מסוימת, מכשיר כזה פטור מהדרישה לקיום מאגר מפתחות.
שמגובות בסביבת הפעלה מבודדת ותומכת באימות (attestation) של המפתח,
אלא אם מוצהר על התכונה android.hardware.fingerprint
שדורשת
מאגר מפתחות שמגובה על ידי סביבת הפעלה מבודדת.
הטמעות של מכשירים בכלי רכב:
- [9.14/A-0-1] הודעות שמירת סף ממערכות משנה של רכבים במסגרת Android, למשל, הודעה שמותרת להוסיף לרשימת ההיתרים הסוגים והמקורות של ההודעות.
- [9.14/A-0-2] הטיימר המפקח (watchdog) חייב לעמוד התקפות של מניעת שירות (DoS) מ-Android Framework או מאפליקציות של צד שלישי. הזה מגנה מפני תוכנות זדוניות שמציפה את רשת הרכבים בתנועה, מה שעלול לגרום לתקלה במערכות המשנה של הרכב.
2.5.6. תאימות לכלים למפתחים ולאפשרויות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
הטמעות של מכשירים בכלי רכב:
- Perfetto
- [6.1/A-0-1] חייבים לחשוף
/system/bin/perfetto
בינארית למשתמש המעטפת ש-cmdline פועל התיעוד של Perfetto. - [6.1/A-0-2] הקובץ הבינארי הקבוע חייב לקבל בתור קלט הגדרת Protobuf שתואמת לסכימה המוגדרת לתיעוד בלבד.
- [6.1/A-0-3] הקובץ הבינארי שמוגדר בקובץ חייב להיות כתוב בתור פלט מעקב של Protobuf התואם לסכימה המוגדרת לתיעוד בלבד.
- [6.1/A-0-4] חובה לספק באמצעות Perfetto הבינארי, לפחות מקורות הנתונים שמתוארים לתיעוד בלבד.
- [6.1/A-0-5] הדימון עקב מעקב
חייבים להיות מופעלים כברירת מחדל (מאפיין המערכת
persist.traced.enable
).
- [6.1/A-0-1] חייבים לחשוף
סיום הדרישות החדשות
2.6. דרישות לטאבלט
מכשיר Android Tablet מתייחס להטמעה של מכשיר Android, בדרך כלל עומד בכל הקריטריונים הבאים:
- מאפשרת להחזיק את שתי הידיים.
- לא כולל מבנה צדפה או תצורה ניתנת להמרה.
- יישומים של מקלדת פיזית המשמשים עם המכשיר מתחברים על ידי אמצעי חיבור רגיל (למשל, USB, Bluetooth).
כולל מקור כוח שמספק ניידות, כמו סוללה.
מסך בגודל של יותר מ-7 אינץ' וקטן מ-18 אינץ', במדידה באלכסון.
להטמעות של מכשירי טאבלט יש דרישות דומות לאלו של מכשירים ניידים בפועל. החריגות מסומנות באמצעות * בקטע הזה וציינו גם בסעיף הזה.
2.6.1. חומרה
ג'ירוסקופ
אם בהטמעות במכשירי טאבלט נעשה שימוש בג'ירוסקופ ב-3 צירים:
- [7.3.4/Tab-1-1] חייבת להיות אפשרות למדוד את הכיוון משתנה עד 1,000 מעלות לשנייה.
זיכרון ואחסון מינימליים (סעיף 7.6.1)
פירוט צפיפות המסך שרשום למסכים קטנים/רגילים במכשירים ניידים הדרישות לא רלוונטיות לטאבלטים.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
מצב ציוד היקפי בחיבור USB (סעיף 7.7.1)
אם ההטמעות של מכשיר הטאבלט כוללות יציאת USB שתומכת בציוד היקפי במצב הזה:
- [7.7.1/Tab] יכול להיות שה-API של Android Open Accessory (AOA) יוטמע.
סיום הדרישות החדשות
מצב מציאות מדומה (סעיף 7.9.1)
ביצועים גבוהים של מציאות מדומה (סעיף 7.9.2)
הדרישות לגבי מציאות מדומה לא רלוונטיות לטאבלטים.
2.6.2. דגם אבטחה
מפתחות ופרטי כניסה (סעיף 9.11)
למידע נוסף, כדאי לעיין בסעיף [9.11].
אם ההטמעות של מכשירי טאבלט כוללות משתמשים מרובים וגם
לא מצהירים על דגל התכונה android.hardware.telephony
, הם:
- [9.5/T-1-1] חייבת לתמוך בפרופילים מוגבלים. תכונה שמאפשרת לבעלי מכשירים לנהל משתמשים נוספים ליכולות של המכשיר. עם פרופילים מוגבלים, בעלי המכשירים יכולים להגדיר במהירות סביבות נפרדות שבהן משתמשים נוספים יעבדו, יכולת לנהל הגבלות פרטניות יותר באפליקציות זמינים בסביבות האלה.
אם ההטמעות של מכשירי טאבלט כוללות משתמשים מרובים וגם
מצהירים על דגל התכונה android.hardware.telephony
, הם:
- [9.5/T-2-1] אסור שתמיכה מוגבלת אבל חייבים להתאים להטמעת AOSP של אמצעי הבקרה כדי לאפשר /להשבית את הגישה של משתמשים אחרים לשיחות קוליות ול-SMS.
2.6.2. תוכנות
- [3.2.3.1/Tab-0-1] חובה לטעון מראש או יותר אפליקציות או רכיבי שירות עם handler של Intent, הדפוסים של סינון Intent ציבורי שמוגדרים לפי ה-Intentים הבאים של אפליקציות המפורטים כאן.
3. תוכנות
3.1. תאימות ל-API מנוהל
סביבת הביצוע המנוהלת של Dalvik בייטקוד היא כלי הרכב העיקרי אפליקציות ל-Android. ממשק תכנות היישומים (API) של Android הוא קבוצת ממשקים של פלטפורמת Android שנחשפו לאפליקציות שפועלות בסביבת זמן ריצה מנוהלת.
הטמעות מכשירים:
[C-0-1] חובה לספק הטמעות מלאות, כולל כל המסמכים המתועדים של כל ממשק API מתועד שנחשף על ידי Android SDK או כל ממשק API המעוצב באמצעות ה-" @SystemApi" סמן Android בזרם ה-upstream קוד המקור.
[C-0-2] חובה לתמוך או לשמר את כל הסוגים, השיטות והרכיבים המשויכים מסומנת בהערת TestApi (@TestApi).
[C-0-3] אסור להשמיט ממשקי API מנוהלים ולשנות את ממשקי ה-API או חתימות. לסטות מההתנהגות המתועדת או לכלול אי-תפעול, למעט במקרים שבהם מותר באופן ספציפי במסגרת הגדרת התאימות הזו.
[C-0-4] ממשקי ה-API חייבים להמשיך לפעול ולהתנהג באופן סביר, גם כאשר תכונות חומרה מסוימות שעבורן Android כולל ממשקי API מושמטים. ראו סעיף 7 לגבי הדרישות הספציפיות לתרחיש הזה.
[C-0-5] אסור לאפליקציות של צד שלישי להשתמש בממשקים שהם לא SDK, מוגדרים כ-methods ושדות בחבילות השפה של Java בנתיב האתחול של האתחול ב-AOSP, והם לא חלק מהציבור SDK. זה כולל ממשקי API שמעוצבים עם ההערה
@hide
אבל לא עם@SystemAPI
, כמו שמתואר במסמכי ה-SDK ובכיתה פרטית או במסגרת חבילה פרטית.[C-0-6] חובה לשלוח את המוצרים עם כל ממשק שאינו SDK עבור כל ממשק מוגבל רשימות שנמסרות באמצעות הסימונים הזמניים ורשימות הישויות שנחסמו
prebuilts/runtime/appcompat/hiddenapi-flags.csv
להסתעפות המתאימה ברמת ה-API ב-AOSP.[C-0-7] חייבת לתמוך בתצורה החתומה מנגנון עדכון דינמי להסרת ממשקים שאינם SDK מרשימה מוגבלת באמצעות הטמעת תצורה חתומה בכל APK באמצעות המפתחות הציבוריים הקיימים נמצאים ב-AOSP.
עם זאת:
- יכול להיות, אם חסר API מוסתר או שהוא הוטמע באופן שונה במכשיר הטמעה, להעביר את ה-API המוסתר לרשימת הישויות שנחסמו או להשמיט אותו כל הרשימות המוגבלות.
- אולי, אם עדיין לא קיים API מוסתר ב-AOSP, כדאי להוסיף את ממשק API לכל אחת מהרשימות המוגבלות.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-0-8] אסור לתמוך בהתקנת אפליקציות שמטרגטות רמת API
פחות מ-
2324.
סיום הדרישות החדשות
3.1.1. תוספים ל-Android
מערכת Android תומכת בהרחבה של סביבת ה-API המנוהלת ברמת API מסוימת על ידי
מעדכנים את גרסת התוסף לרמת ה-API הזו.
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
API מחזיר את
גרסת התוסף של apiLevel
שסופק, אם יש תוספים בשבילו
רמת ה-API.
הטמעות של מכשירי Android:
[C-0-1] חובה לטעון מראש את הטמעת ה-AOSP של הספרייה המשותפת
ExtShared
ושירותיםExtServices
עם גרסאות שגדולות מ- או שוות ל- מספר הגרסאות המינימלי המותר לכל רמת API. לדוגמה, Android 7.0 הטמעות במכשירים, הרצה של רמת API 24 חייבת לכלול לפחות גרסה 1.[C-0-2] חובה להחזיר רק מספר גרסה תקף של תוסף מוגדר על ידי ה-AOSP.
[C-0-3] חייבת להיות תמיכה בכל ממשקי ה-API שהוגדרו בגרסאות התוספים הוחזר על ידי
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
ממש כמו התמיכה בממשקי API מנוהלים אחרים, מפורטות בסעיף 3.1.
3.1.2. ספריית Android
בגלל ההוצאה משימוש של לקוח HTTP ב-Apache, יישומי מכשירים:
- [C-0-1] אסור להציב את ספריית
org.apache.http.legacy
'סיווג אתחול'. - [C-0-2] חובה להוסיף את הספרייה
org.apache.http.legacy
לאפליקציה classpath רק אם האפליקציה עומדת באחד מהתנאים הבאים:- מוגדר טירגוט לרמת API 28 ומטה.
- מצהיר במניפסט שהוא זקוק לספרייה על ידי הגדרה של
מאפיין
android:name
של<uses-library>
עדorg.apache.http.legacy
.
הטמעת ה-AOSP עומדת בדרישות הבאות.
3.2. תאימות ל-Soft API
בנוסף לממשקי ה-API המנוהלים המפורטים בסעיף 3.1, ב-Android יש גם רכיב "רך" משמעותי של זמן ריצה בלבד בממשק API, דברים כמו כוונות, הרשאות והיבטים דומים של אפליקציות ל-Android לא ניתנת לאכיפה בזמן הידור של האפליקציה.
3.2.1. הרשאות
- [C-0-1] מטמיעי מכשירים חייבים לתמוך ולאכוף את כל ההרשאות קבועים, כפי שמתואר בדף העזר להרשאות. לידיעתך, בסעיף 9 מפורטות אפשרויות נוספות בדרישות שקשורות למודל האבטחה של Android.
3.2.2. בניית פרמטרים
ממשקי ה-API של Android כוללים כמה משתנים קבועים android.os.Build class שנועדו לתאר את המכשיר הנוכחי.
- [C-0-1] לספק ערכים עקביים ומשמעותיים בכל המכשירים בהטמעות, הטבלה הבאה כוללת הגבלות נוספות על הפורמטים של הערכים האלה שההטמעות במכשירים חייבים לעמוד בהם.
פרמטר | פרטים |
---|---|
גרסה.גרסה | הגרסה של מערכת Android שפועלת כרגע, בפורמט קריא לאנשים הפורמט. אחד מערכי המחרוזת של השדה הזה חייב להיות מוגדר ב מחרוזות הגרסאות המותרות ל-Android 15. |
VERSION.SDK | הגרסה של מערכת Android שפועלת כרגע, בפורמט לקוד של אפליקציה של צד שלישי. ב-Android 15, בשדה הזה חייב להיות ערך המספר השלם 15_INT. |
VERSION.SDK_INT | הגרסה של מערכת Android שפועלת כרגע, בפורמט לקוד של אפליקציה של צד שלישי. ב-Android 15, בשדה הזה חייב להיות ערך המספר השלם 15_INT. |
גרסה.INCREMENTAL | ערך שנבחר על ידי מכשיר ההטמעה שמגדיר את ה-build הספציפי
של מערכת Android שפועלת כרגע, בפורמט קריא לאנשים. הזה
אסור לעשות שימוש חוזר בערך הזה לגרסאות build שונות שזמינות למשתמשי הקצה. א'
השימוש הטיפוסי בשדה הזה הוא לציין את מספר ה-Build
בתהליך יצירת ה-build נעשה שימוש במזהה שינוי של בקרת מקור. הערך
חייב להיות ניתן לקידוד כ-ASCII ניתן להדפסה בגודל 7 סיביות ולהתאים לקידוד
הביטוי הרגולרי ^[^ :\/~]+$ . |
משחקי לוח | ערך שנבחר על ידי מכשיר ההטמעה שמזהה את
חומרה פנימית שבה נעשה שימוש במכשיר, בפורמט קריא לאנשים. אפשרית
בשדה הזה צריך לציין את הגרסה הספציפית של
במכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות
תואמים לביטוי הרגולרי ^[a-zA-Z0-9_-]+$ . |
מותג | ערך שמשקף את שם המותג המשויך למכשיר, כפי שהוא נקרא
משתמשי הקצה. חייב להיות בפורמט קריא לאנשים, והוא צריך לייצג את
יצרן המכשיר או מותג החברה שמתחתיו
שמשווקות. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים אותו
הביטוי הרגולרי ^[a-zA-Z0-9_-]+$ . |
נתמך_ABIS | השם של קבוצת ההוראות (סוג מעבד (CPU) + מוסכמות ABI) של נייטיב ראו סעיף 3.3. ממשק API מקורי תאימות. |
SupportED_32_BIT_ABIS | השם של קבוצת ההוראות (סוג מעבד (CPU) + מוסכמות ABI) של נייטיב ראו סעיף 3.3. ממשק API מקורי תאימות. |
SUPPORTED_64_BIT_ABIS | השם של קבוצת ההוראה השנייה (סוג מעבד (CPU) + מוסכמות ABI) של את הקוד המקורי. ראו סעיף 3.3. מודעות מותאמות תאימות ל-API. |
מעבד (CPU)_ABI | השם של קבוצת ההוראות (סוג מעבד (CPU) + מוסכמות ABI) של נייטיב ראו סעיף 3.3. ממשק API מקורי תאימות. |
מעבד (CPU)_ABI2 | השם של קבוצת ההוראה השנייה (סוג מעבד (CPU) + מוסכמות ABI) של את הקוד המקורי. ראו סעיף 3.3. מודעות מותאמות תאימות ל-API. |
מכשיר | ערך שנבחר על ידי מטמיע המכשיר שמכיל את שם הפיתוח
או שם קוד המזהה את התצורה של תכונות החומרה
לעיצוב התעשייתי של המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד
כ-ASCII בגרסת 7 סיביות ותואמים לביטוי הרגולרי
^[a-zA-Z0-9_-]+$ אסור לשנות את שם המכשיר הזה במהלך
כל משך החיים של המוצר. |
טביעת אצבע | מחרוזת שמשמשת לזיהוי ייחודי של ה-build הזה. היא צריכה להיות סבירה
קריא לאנשים. היא חייבת להיות בתבנית הבאה:
$(BRAND)/$(PRODUCT)/ לדוגמה: 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) שנעשה בו שימוש במוצר. מכשירים עם אותו יצרן 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 | ערך אופציונלי שנבחר על ידי מטמיע המכשיר שמכיל
מק"ט (Stock Keeping Unit) שמשמש למעקב אחרי תצורות ספציפיות
של המכשיר, לדוגמה, כל ציוד היקפי שכלול במכשיר כשהוא נמכר.
הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות ולהתאים
הביטוי הרגולרי ^([0-9A-Za-z.,_-]+)$ . |
סידורי | חייבת להיות 'UNKNOWN'. |
תגים | רשימה מופרדת בפסיקים של התגים שנבחרו על ידי הכלי להטמעת מכשירים
שעושה הבחנה נוספת בין ה-build. ניתן לקידוד את התגים כ-ASCII של 7 ביט
ולהתאים את הביטוי הרגולרי ^[a-zA-Z0-9._-]+ ו-חייב
הם כוללים אחד מהערכים שתואמים לשלושת הפלטפורמות הטיפוסיות של Android
בתצורת חתימה: מפתחות הפצה, מפתחות פיתוח ומפתחות בדיקה. |
שעה | ערך שמייצג את חותמת הזמן של מועד ה-build. |
סוג | ערך שנבחר על ידי ההטמעה של המכשיר, שמציין את זמן הריצה של ה-build. שדה זה חייב להכיל אחד מהערכים שתואם לשלוש הגדרות אופייניות של זמן ריצה ב-Android: משתמש, userdebug או eng. |
משתמש | שם או מזהה משתמש של המשתמש (או המשתמש האוטומטי) שיצר את build. אין דרישות לגבי הפורמט הספציפי של השדה הזה, למעט שהוא לא יכול להיות null או מחרוזת ריקה (""). |
אבטחה_תיקון | ערך שמציין את רמת תיקון האבטחה של ה-build. חובה לציין שה-build לא חשוף בשום צורה לבעיות שתוארו באמצעות 'מבזקי אבטחה ציבוריים' הייעודיים של Android. ההזמנה חייבת להיות בתוך בפורמט [YYYY-MM-DD], שתואם למחרוזת מוגדרת שמתועדת האבטחה הציבורית של Android תבליט או ב התראת אבטחה של Android, לדוגמה "2015-11-01". |
BASE_OS | ערך שמייצג את הפרמטר FINGERprint של ה-build אחרת תהיה זהה ל-build הזה, למעט התיקונים שסופקו מבזקי אבטחה ציבוריים של Android. חייבים לדווח על הערך הנכון, ואם build כזה לא קיים. צריך לדווח על מחרוזת ריקה (""). |
BOOTLOADER | ערך שנבחר על ידי מכשיר ההטמעה שמזהה את
גרסת תוכנת האתחול הפנימית שמותקנת במכשיר, בפורמט קריא לאנשים.
הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות ולהתאים
הביטוי הרגולרי ^[a-zA-Z0-9._-]+$ . |
getRadioVersion() | חייב (להיות או להחזיר) ערך שנבחר על ידי מטמיע המכשיר
זיהוי גרסת הרדיו/המודם הפנימית הספציפית שבה נעשה שימוש במכשיר,
בפורמט קריא לאנשים. אם למכשיר אין
רדיו/modem חייב להחזיר NULL. הערך בשדה הזה חייב להיות
ניתן לקידוד כ-ASCII בגרסת 7 סיביות ולהתאים את הביטוי הרגולרי
^[a-zA-Z0-9._-,]+$ |
getENTER() |
חייב (להיות או להחזיר) מספר סידורי של חומרה, חייב להיות זמין
וייחודיים בכל המכשירים עם אותו MODEL ו-MANUFACTURER. הערך של
חייב להיות ניתן לקידוד שדה זה כ-ASCII של 7 סיביות ולהתאים לביטוי הרגולרי
^[a-zA-Z0-9]+$ |
3.2.3. תאימות של Intent
3.2.3.1. אובייקטים נפוצים של Intent באפליקציות
הפורמט 'Intents של Android' מאפשר לרכיבי האפליקציה לבקש פונקציונליות מ רכיבי Android אחרים. פרויקט ה-upstream ב-Android כולל רשימה של שמטמיעים כמה דפוסי כוונה כדי לבצע פעולות נפוצות.
הטמעות מכשירים:
- [C-SR-1] מומלץ מאוד לטעון מראש אפליקציה אחת או יותר, או רכיבי שירות עם handler של Intent, לכל מסנן Intent הציבורי. הדפוסים המוגדרים לפי ה-Intents הבאים של אפליקציות המפורטים כאן ולספק את צורכי הלקוחות, כלומר, לעמוד בציפיות של המפתח לגבי כוונות אפליקציה כפי שמתואר ב-SDK.
בסעיף 2 לקבלת כוונות נדרשות להגשת בקשה לכל סוג מכשיר.
3.2.3.2. יישוב כוונות
[C-0-1] Android היא פלטפורמה שניתנת להרחבה, ולכן חייבים להטמיע במכשירים לאפשר כל דפוס Intent שיש הפניה אליו בקטע 3.2.3.1, למעט הגדרות, שיבטלו על ידי אפליקציות של צד שלישי. הטמעת קוד פתוח של Android ב-upstream מאפשרת זאת כברירת מחדל.
[C-0-2] אסור שמטמיעי מכשירים יוכלו לשייך הרשאות מיוחדות למערכת אפליקציות שימוש בדפוסי הכוונה האלה, או למנוע שימוש באפליקציות של צד שלישי לחייב את הדפוסים האלה ולקבל שליטה עליהם. האיסור הזה כוללת באופן ספציפי, בין היתר, את השבתת האפשרות 'בורר' משתמש שמאפשר למשתמש לבחור בין מספר אפליקציות יטפל באותו דפוס Intent.
[C-0-3] הטמעות במכשירים חייבות לספק ממשק משתמש למשתמשים לשנות את פעילות ברירת המחדל של Intent.
עם זאת, ייתכן שהטמעות מכשירים מספקות פעילויות ברירת מחדל עבור תבניות URI (למשל http://play.google.com) כאשר פעילות ברירת המחדל מספקת ל-URI של הנתונים. לדוגמה, דפוס של מסנן Intent שמציין את כתובת ה-URI של הנתונים 'http://www.android.com' ספציפי יותר תבנית ה-Intent העיקרית של הדפדפן עבור "http:// ".
ב-Android יש גם מנגנון שבו אפליקציות צד שלישי יכולות להכריז על התנהגות ברירת המחדל של מדיניות הקישור לאפליקציות לסוגים מסוימים של כוונות URI באינטרנט. כשיש הצהרות מוסמכות כאלה מוגדר בדפוסים של מסנני Intent באפליקציה, הטמעות מכשירים:
- [C-0-4] חובה לנסות לאמת מסנני Intent על ידי ביצוע של שלבי האימות שמוגדרים במפרט של קישורים לנכסים דיגיטליים כפי שהוטמע על ידי מנהל החבילות ב-upstream בקוד פתוח של Android פרויקט.
- [C-0-5] חובה לנסות לאמת את מסנני Intent במהלך ההתקנה של את האפליקציה ולהגדיר את כל מסנני Intent של URI שאומתו בהצלחה בתור רכיבי ה-handler שמוגדרים כברירת מחדל לאפליקציות עבור מזהי ה-URI שלהם.
- ב-MAY ניתן להגדיר מסנני Intent ספציפיים של URI כרכיבי handler שמוגדרים כברירת מחדל לאפליקציות עבור מזהי ה-URI שלהם, אם הם אומתו בהצלחה, אך מסנני URI של מועמדים אחרים נכשלים אימות. אם מכשיר כלשהו מבצע את הפעולה הזו, הוא חייב לספק את משתמש לשנות את תבנית ה-URI המתאימה בתפריט ההגדרות.
- חובה לספק למשתמש אמצעי בקרה של קישורים לאפליקציה לכל אפליקציה בהגדרות בתור
ככה:
- [C-0-6] המשתמש חייב להיות מסוגל לשנות את כל אפליקציית ברירת המחדל. ההתנהגות של קישורים לאפליקציה: תמיד פתוחה, שואלת תמיד או אף פעם לא נפתחת. שחייב לחול על כל מסנני ה-Intent של ה-URI של המועמדים באופן שווה.
- [C-0-7] המשתמש חייב לראות רשימה של כוונות ה-URI האפשריות מסננים.
- הטמעת המכשיר עשויה לספק למשתמש את היכולת לשנות מסנני Intent ספציפיים של ה-URI של המועמדים שהתקבלו בהצלחה לפי סינון לפי כוונת המשתמש.
- [C-0-8] הטמעת המכשיר חייבת לספק למשתמשים את היכולת הצגה וביטול של מסנני Intent ספציפיים של URI אפשריים, אם המכשיר מאפשר לחלק ממסנני ה-Intent של ה-URI של המועמדים להצליח בעוד שאחרים עלולים להיכשל.
3.2.3.3. מרחבי שמות של Intent
- [C-0-1] אסור לכלול במכשירים רכיבי Android שמטמיעים פועל לפי כל דפוס חדש של כוונת רכישה או של כוונות שידור באמצעות ACTION, CATEGORY או מחרוזת מפתח אחרת במרחב השמות android.* או com.android.* .
- [C-0-2] אסור לכלול בהטמעות של מכשירים רכיבי Android לפעול בהתאם לכל דפוס חדש של כוונת רכישה או של כוונות שידור באמצעות הפעולות ACTION, CATEGORY או מחרוזת מפתח אחרת במרחב חבילה ששייך לארגון אחר.
- [C-0-3] אסור למטמיעי מכשירים לשנות או להרחיב אף אחת מכוונות הרכישה הדפוסים המפורטים בסעיף 3.2.3.1.
- ייתכן שהטמעות מכשירים כוללות דפוסי כוונה שמשתמשים במרחבי שמות באופן ברור ומשויכים בבירור לארגון שלהם. האיסור הזה מקבילה לזו שצוינה במחלקות שפת Java בקטע 3.6.
3.2.3.4. כוונה לשידור
אפליקציות צד שלישי מסתמכות על הפלטפורמה כדי לשדר כוונות מסוימות להודיע להם על שינויים בסביבת החומרה או התוכנה.
הטמעות מכשירים:
- [C-0-1] חובה לשדר את מטרות השידור הציבורי שמפורטות כאן בתגובה לאירועי המערכת המתאימים, כפי שמתואר במסמכי התיעוד של ה-SDK. לתשומת ליבך, דרישה זו אינה מתנגשת עם סעיף 3.5, הגבלה על אפליקציות ברקע מתוארת גם ב-SDK התיעוד. כמו כן, כוונות שידור מסוימות מותנות בחומרה תמיכה, אם המכשיר תומך בחומרה הנדרשת, הם חייבים לשדר את את הכוונות שלו ומספקים את ההתנהגות בהתאם למסמכי התיעוד של ה-SDK.
3.2.3.5. אובייקטים מסוג Intent של אפליקציות מותנות
ב-Android יש הגדרות שמאפשרות למשתמשים לבחור בקלות אפליקציות ברירת מחדל, לדוגמה, מסך הבית או SMS.
כשהדבר הגיוני, הטמעות מכשירים חייבות לספק הגדרות דומות יהיו תואמים לדפוס של מסנן Intent ולשיטות ה-API שמתוארות. במסמכי התיעוד בנושא SDK, כפי שמפורט בהמשך.
אם הטמעות המכשירים ידווחו על android.software.home_screen
, הן:
- [C-1-1] חייב לכבד את
android.settings.HOME_SETTINGS
Intent להציג תפריט ברירת מחדל של הגדרות אפליקציה במסך הבית.
אם הטמעות המכשירים ידווחו על android.hardware.telephony.calling
, הן:
[C-2-1] חובה לספק תפריט הגדרות שיקרא
android.provider.Telephony.ACTION_CHANGE_DEFAULT
כוונה להציג תיבת דו-שיח לשינוי אפליקציית ברירת המחדל ל-SMS.[C-2-2] חייבים לכבד את
android.telecom.action.CHANGE_DEFAULT_DIALER
Intent להציג תיבת דו-שיח כדי לאפשר למשתמש לשנות את ברירת המחדל של טלפון תרגום מכונה.- חייבים להשתמש בממשק המשתמש של אפליקציית 'טלפון' המוגדרת כברירת המחדל על ידי המשתמשים שיחות יוצאות, למעט שיחות חירום, שבהן ייעשה שימוש אפליקציית 'טלפון' שהותקנה מראש.
[C-2-3] חובה לפעול בהתאם ל-android.telecom.action.CHANGE_PHONE_ACCOUNTS כוונה לספק למשתמשים אפשרות להגדיר את
ConnectionServices
המשויך ל-PhoneAccounts
, מכיוון וגם PhoneAccount ברירת מחדל שספק שירותי הטלקומוניקציה יקבל משמשים לביצוע שיחות יוצאות. הטמעת ה-AOSP עומדת בדרישה הזו עד כולל 'אפשרות לשיחות-חשבונות' בתפריט "שיחות" תפריט ההגדרות[C-2-4] חובה לאפשר
android.telecom.CallRedirectionService
לאפליקציה שמכילה אתandroid.app.role.CALL_REDIRECTION
תפקיד.[C-2-5] חובה לספק למשתמש אפשרות לבחור אפליקציה שמכילה את
android.app.role.CALL_REDIRECTION
תפקיד.[C-2-6] חובה לפעול בהתאם ל-android.intent.action.SENDTO ו-android.intent.action.VIEW כוונות ולספק פעילות לשליחה/הצגה של הודעות SMS.
[C-SR-1] מומלץ מאוד לכבד את android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_button, android.intent.action.VIEW ו- android.intent.action.DIAL עם אפליקציית חייגן בטעינה מראש, שיכולה לטפל בכוונות האלה לספק מילוי הזמנות כפי שמתואר ב-SDK.
אם הטמעות המכשירים ידווחו על android.hardware.nfc.hce
, הן:
- [C-3-1] חובה לפעול בהתאם לandroid.settings.NFC_PAYMENT_SETTINGS כוונה להציג תפריט של הגדרות האפליקציה כברירת מחדל לתשלום בשיטת 'מצמידים ומשלמים'.
- [C-3-2] חובה לציית ל-android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT כוונה להציג פעילות שבה נפתחת תיבת דו-שיח שבה מבקשים מהמשתמש לשנות שירות הדמיית כרטיס שמוגדר כברירת מחדל לקטגוריה מסוימת, כפי שמתואר ב-SDK.
אם הטמעות המכשירים ידווחו על android.hardware.nfc
, הן:
- [C-4-1] חובה לכבד את הכוונות האלה android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED ו- android.nfc.action.TECH_DISCOVERED, כדי להציג פעילות שעומדת בציפיות של המפתחים ביחס לכוונות האלה שמתוארים ב-SDK.
אם הטמעות המכשירים ידווחו על android.hardware.bluetooth
, הן:
- [C-5-1] חובה ליישם את הכללים של 'android.bluetooth.adapter.action.REQUEST_ENABLE' כוונה ולהציג פעילות מערכת כדי לאפשר למשתמש להפעיל Bluetooth.
- [C-5-2] חייבים לכבד את 'android.bluetooth.adapter.action.REQUEST_DISCOVERABLE' Intent ולהציג פעילות מערכת שמבקשת מצב גלוי.
אם הטמעות המכשירים תומכות בתכונה DND:
- [C-6-1] חובה להטמיע פעילות שמגיבה לכוונה
ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS
שבהטמעות עם UI_mode_TYPE_NORMAL זו חייבת להיות פעילות שבה המשתמש יכול להעניק או לדחות את הגישה של האפליקציה להגדרות המדיניות של DND.
אם הטמעות של מכשירים מאפשרות למשתמשים להשתמש בשיטות קלט של צד שלישי במכשיר, הן:
- [C-7-1] חובה לספק מנגנון נגיש למשתמש להוספה ולהגדרה
לשיטות קלט של צד שלישי בתגובה
android.settings.INPUT_METHOD_SETTINGS
בכוונה טובה.
אם הטמעות במכשירים תומכים בשירותי נגישות של צד שלישי:
- [C-8-1] חייב לכבד את
android.settings.ACCESSIBILITY_SETTINGS
כוונה לספק מנגנון נגיש למשתמש כדי להפעיל ולהשבית את שירותי נגישות של צד שלישי לצד תכונות הנגישות שנטענו מראש שירותים שונים.
אם יישומי המכשיר כוללים תמיכה ב-Wi-Fi Easy Connect וחושפים את פונקציונליות של אפליקציות צד שלישי:
- [C-9-1] חובה להטמיע את Settings#ACTION_processing_WIFI_EASY_CONNECT_URI ממשקי API של Intent כפי שמתואר במסמכי התיעוד של ה-SDK.
אם הטמעות במכשירים מספקות את מצב חוסך הנתונים, הן:
- [C-10-1] חובה לספק בהגדרות ממשק משתמש שמטפל
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
Intent, ומאפשרת למשתמשים להוסיף אפליקציות או להסיר מהן את רשימת ההרשאות.
אם הטמעות במכשירים לא מספקות את מצב חוסך הנתונים, הן:
- [C-11-1] חייבת להיות פעילות שמטפלת
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
בכוונה טובה, אבל יכול להיות שבכוונתך ליישם את זה כפעולה מלכתחילה.
אם הטמעתי מכשירים מצהירה על תמיכה במצלמה דרך
android.hardware.camera.any
, הן:
- [C-12-3] נקודת אחיזה חייבת, וחייבת לאפשר רק אפליקציות ל-Android שהותקנו מראש
לטפל בכוונות הבאות
MediaStore.ACTION_IMAGE_CAPTURE
MediaStore.ACTION_IMAGE_CAPTURE_SECURE
, ו-MediaStore.ACTION_VIDEO_CAPTURE
כפי שמתואר במסמך ה-SDK.
אם הטמעות המכשירים ידווחו על android.software.device_admin
, הן:
[C-13-1] חובה לפעול בהתאם לכוונה
android.app.action.ADD_DEVICE_ADMIN
כדי להפעיל ממשק משתמש שיעביר את המשתמש על ידי הוספת מנהל המכשיר את המערכת (או לאפשר להם לדחות אותה).[C-13-2] חובה לכבד את הכוונות android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_רון, android.app.action.SET_NEW_password ו- android.app.action.START_ENCRYPTION ויש להם פעילות למילוי הכוונות האלה, כפי שמתואר ב-SDK כאן.
אם בהטמעות במכשירים מוצהר על android.software.autofill
דגל תכונה, הם:
- [C-14-1] חובה להטמיע באופן מלא את
AutofillService
ו-AutofillManager
ממשקי API ופועלים בהתאם ל-android.settings.REQUEST_SET_AutoFILL_SERVICE כוונה להציג תפריט של הגדרות אפליקציה כברירת מחדל כדי להפעיל ולהשבית מילוי אוטומטי שינוי שירות המילוי האוטומטי שמוגדר כברירת מחדל עבור המשתמש.
אם ההטמעות במכשירים כוללים אפליקציה שהותקנה מראש או רוצים לאשר כדי לגשת לסטטיסטיקות השימוש של אפליקציות צד שלישי:
- [C-SR-2] מומלץ מאוד לספק מנגנון נגיש למשתמש כדי להעניק
או לבטל את הגישה לסטטיסטיקות השימוש בתגובה
android.settings.ACTION_USAGE_ACCESS_SETTINGS
Intent לאפליקציות שמצהירות בהן על
android.permission.PACKAGE_USAGE_STATS
הרשאה.
אם בהטמעות במכשירים נעשה שימוש כדי שלא לאפשר גישה לאפליקציות, כולל אפליקציות מותקנות מראש לאפליקציות גישה לסטטיסטיקות השימוש, הן:
- [C-15-1] עדיין צריכה להיות פעילות שמטפלת android.settings.ACTION_USAGE_ACCESS_SETTINGS אבל חייבים ליישם אותו כפעולה ללא פעולה, כלומר התנהגות שבה המשתמש סורב לקבל גישה.
אם יישומי מכשירים מציגים קישורים לפעילויות שצוינו על ידי AutofillService_passwordsActivity בהגדרות או בקישורים לסיסמאות משתמשים במנגנון דומה:
- [C-16-1] חובה להציג קישורים כאלה בכל שירותי המילוי האוטומטי שהותקנו.
אם הטמעות המכשיר תומכות ב-VoiceInteractionService
ויש עוד
המותקנת על ידי אפליקציה אחת בכל פעם, המשתמשת ב-API הזה:
- [C-18-1] חובה לכבד את
android.settings.ACTION_VOICE_INPUT_SETTINGS
כוונה להציג תפריט הגדרות ברירת מחדל של האפליקציה לקלט קולי ולסיוע.
אם יישומי מכשירים ידווחו על התכונה android.hardware.audio.output
,
הם:
- [C-SR-3] מומלץ מאוד לכבד את android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA ל-Intents של android.speech.tts.engine.GET_Example_TEXT יש פעילות שצריך לספק של הכוונות האלה כפי שמתואר כאן ב-SDK.
ב-Android יש תמיכה בשומרי מסך אינטראקטיביים, שנקראו בעבר בחלומות. שומרי המסך מאפשרים למשתמשים ליצור אינטראקציה עם אפליקציות כאשר מכשיר המכשיר שמחובר למקור חשמל לא פעיל או מחובר לאביזר עגינה בשולחן העבודה. הטמעות של מכשירים:
- צריכה לכלול תמיכה בשומרי מסך ולספק אפשרות הגדרות עבור
למשתמשים להגדיר את שומרי המסך בתגובה
Intent מסוג
android.settings.DREAM_SETTINGS
.
אם על הטמעת מכשירים מדווחות android.hardware.nfc.uicc
או android.hardware.nfc.ese
,
הם:
- [C-19-1] חובה להטמיע את הפרמטר NfcAdapter.ACTION_TRANSACTION_DETECTED Intent API (כ-"EVT_TRANSACTION" שמוגדר על ידי המפרט הטכני GSM Association TS.26 - דרישות מכשיר NFC).
3.2.4. פעילויות במסכים משניים או מרובים
אם הטמעות המכשירים מאפשרות להפעיל פעילויות רגילות ב-Android ביותר מסך אחד, הם:
- [C-1-1] חייבים להגדיר את
android.software.activities_on_secondary_displays
דגל של פיצ'ר. - [C-1-2] חובה להבטיח תאימות ל-API שדומה לפעילות שפועלת על במסך הראשי.
- [C-1-3] הפעילות החדשה חייבת להופיע בתצוגה של הפעילות
להפעיל אותו, כשהפעילות החדשה מופעלת בלי לציין יעד
תצוגה דרך
ActivityOptions.setLaunchDisplayId()
API. - [C-1-4] חייבים להרוס את כל הפעילויות, כשצג עם
Display.FLAG_PRIVATE
הסימון הוסר. - [C-1-5] חובה להסתיר תוכן באופן מאובטח בכל המסכים כשהמכשיר נעול
עם מסך נעילה מאובטח, אלא אם האפליקציה בוחרת להציג מעל מנעול
מסך באמצעות
Activity#setShowWhenLocked()
API. - צריך לכלול את הפרמטר
android.content.res.Configuration
שתואם לתצוגה הזו כדי שיוצג, כראוי, ולשמור על תאימות אם פעילות מופעלת ב מסך משני.
אם הטמעות המכשיר מאפשרות הפעלה של פעילויות רגילות ב-Android במכשיר משני למסכים ולמסכים משניים יש את android.view.Display.FLAG_PRIVATE דגל:
- [C-3-1] רק הבעלים של המסך, המערכת והפעילויות ש במסך הזה חייבת להיות אפשרות להפעיל אותו. כל אחד יכול להתחיל אל תצוגה עם android.view.Display.FLAG_PUBLIC לסמן.
3.3. תאימות ל-Native API
התאימות של קוד מקורי היא מאתגרת. לכן, מערכות הטמעה של מכשירים הם:
- [C-SR-1] מומלץ מאוד להשתמש בהטמעות של הספריות הרשומה למטה מתוך פרויקט ה-upstream של Android בקוד פתוח.
3.3.1. ממשקים בינאריים של אפליקציות
בייטקוד מנוהל של Dalvik יכול לקרוא לקוד נייטיב שמסופק באפליקציה
קובץ .apk
כקובץ .so
של ELF, שעבר הידור לחומרה המתאימה של המכשיר
של הארכיטקטורה, הקוד המקורי תלוי במעבד הבסיסי
עם הטכנולוגיה שלנו, Android מגדיר כמה ממשקי API בינאריים (ABI)
ו-Android NDK.
הטמעות מכשירים:
- [C-0-1] חייבת להיות תאימות לממשק ABI אחד או יותר של Android NDK.
- [C-0-2] חייבת לכלול תמיכה בקוד שפועל בסביבה המנוהלת כדי לקרוא לקוד נייטיב, באמצעות ממשק Java Native Interface הסטנדרטי של Java (JNI) סמנטיקה.
- [C-0-3] חייב להיות תואם למקור (כלומר תואם לכותרת) וגם תואם בינארי (ל-ABI) עם כל ספרייה נדרשת ברשימה שלמטה.
- [C-0-5] חובה לדווח באופן מדויק על הממשק המקורי של Application Binary Interface
(ABI) שנתמך על ידי המכשיר, באמצעות
android.os.Build.SUPPORTED_ABIS
,android.os.Build.SUPPORTED_32_BIT_ABIS
, וגםandroid.os.Build.SUPPORTED_64_BIT_ABIS
פרמטרים, כל אחד מהם מופרד בפסיקים של ממשקי ABI מסודרים מהגבוה לנמוך.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-0-6] חובה לדווח על קבוצת משנה מסוימת, באמצעות הפרמטרים שלמעלה
של ממשקי ABI ואסור לדווח על ממשק ABI שלא מופיע ברשימה.
armeabi
(כבר לא נתמך כיעד על ידי ה-NDK)armeabi-v7a
arm64-v8a
x86
x86-64
riscv64
סיום הדרישות החדשות
[C-0-7] צריך ליצור את כל הספריות הבאות, עם ממשקי API מקוריים זמין לאפליקציות שכוללות קוד נייטיב:
- libaaudio.so (תמיכה באודיו מקורי של AAudio)
- libamidi.so (תמיכה ב-MIDI מקורית, אם התכונה
android.software.midi
זמינה? הוא נתבע כפי שמתואר בסעיף 5.9) - libandroid.so (תמיכה בפעילות מובנית ב-Android)
- libc (ספריית C)
- libcamera2ndk.so
- libdl (קישור דינמי)
- libEGL.so (ניהול פלטפורמות של OpenGL נייטיב)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (רישום ביומן Android)
- libmediandk.so (תמיכה בממשקי API של מדיה מותאמת)
- libm (ספריית מתמטיקה)
- libneuralnetworks.so (Neural Networks API)
- libOpenMAXAL.so (תמיכה ב-OpenMAX AL 1.0.1)
- libOpenSLES.so (תמיכה באודיו ב-OpenSL ES 1.0.1)
- libRS.so
- libstdc++ (תמיכה מינימלית עבור C++ )
- libvulkan.so (Vulkan)
- libz (דחיסת Zlib)
- ממשק JNI
[C-0-8] אסור להוסיף או להסיר את הפונקציות הציבוריות של ספריות המקור שצוינו למעלה.
[C-0-9] חובה לכלול ספריות נוספות שאינן AOSP שנחשפו ישירות אפליקציות צד שלישי ב-
/vendor/etc/public.libraries.txt
.[C-0-10] אסור לחשוף ספריות מקוריות אחרות, שהוטמעו סופקו ב-AOSP כספריות מערכת, לאפליקציות צד שלישי שמטרגטות ל-API רמה 24 ומעלה כפי שמורים.
[C-0-11] חובה לייצא את כל רכיבי OpenGL ES 3.1 וחבילת התוספים ל-Android סמלי פונקציות, כפי שמוגדרים ב-NDK, דרך הספרייה
libGLESv3.so
. לתשומת ליבכם: חייבים לציין את כל הסמלים, אבל סעיף 7.1.4.1 מתאר בפירוט רב יותר על הדרישות בנוגע להטמעה המלאה של כל אחד מהרכיבים האלה את הפונקציות התואמות.[C-0-12] חובה לייצא סמלי פונקציות עבור הליבה פונקציית Vulkan 1.1 וגם
VK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
וגםVK_KHR_get_physical_device_properties2
תוספים דרךlibvulkan.so
הזה. שימו לב שלמרות שכל הסמלים חייבים להופיע, סעיף 7.1.4.2 מתארת בפירוט רב יותר את הדרישות למקרים שבהם הוא מצופה מההטמעה של כל פונקציות מתאימות.צריך להיבנות באמצעות קוד המקור וקובצי הכותרת הזמינים פרויקט קוד פתוח של Android ב-upstream.
לתשומת ליבכם: יכול להיות שגרסאות עתידיות של Android ייתמכו בתכונות נוספות ממשקי ABI.
3.3.2. תאימות לקוד מקורי של ARM 32-ביט
אם הטמעות של מכשירים מדווחות על תמיכה ב-ABI של armeabi
, הן:
- [C-3-1] חובה לתמוך ב-
armeabi-v7a
ולדווח על התמיכה, כמוarmeabi
מיועד רק לתאימות לאחור עם אפליקציות ישנות יותר.
אם הטמעות המכשירים מדווחות על תמיכה ב-ABI של armeabi-v7a
, באפליקציות
באמצעות ה-ABI הזה:
[C-2-1] חייב לכלול את השורות הבאות ב-
/proc/cpuinfo
, ואסור משנים את הערכים באותו המכשיר, גם כשממשקי ABI אחרים קוראים אותם.Features:
, ולאחר מכן רשימה של תכונות אופציונליות של מעבדי ARMv7 שנתמך על ידי המכשיר.CPU architecture:
, ואחריו מספר שלם שמתאר ארכיטקטורת ARM הנתמכת ברמה הגבוהה ביותר (למשל, '8' למכשירי ARMv8).
[C-2-2] הפעולות הבאות צריכות תמיד להישאר זמינות, גם שבו ה-ABI מוטמע בארכיטקטורת ARMv8, בתמיכה במעבד (CPU) המקורי או באמצעות אמולציית תוכנה:
- הוראות ל-SWP ול-SWPB.
- פעולות מחסום מסוג CP15ISB, CP15DSB ו-CP15DMB.
[C-2-3] חייבת לכלול תמיכה ב-Advanced SIMD (שנקראת גם NEON).
3.4. תאימות לאתרים
3.4.1. תאימות ל-WebView
אם הטמעות המכשירים מספקות הטמעה מלאה של
android.webkit.Webview
API, is:
- [C-1-1] חובה לדווח על
android.software.webview
. - [C-1-2] חובה להשתמש ב-build של פרויקט Chromium
מפרויקט הקוד הפתוח של Android ב-Android
ב-15 הסתעפות ליישום של
android.webkit.WebView
API. [C-1-3] מחרוזת סוכן המשתמש שמדווחת על ידי WebView חייבת להיות בפורמט הבא:
Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- הערך של המחרוזת $(VERSION) חייב להיות זהה לערך של android.os.Build.VERSION.VERSION.
- יכול להיות שהמחרוזת $(MODEL) תהיה ריקה, אבל אם היא לא ריקה, זהה לערך של android.os.Build.MODEL.
- "Build/$(BUILD)" ייתכן להשמיט, אבל אם קיים $(BUILD) המחרוזת חייבת להיות זהה לערך של android.os.Build.ID.
- הערך של המחרוזת $(CHROMIUM_VER) חייב להיות הגרסה של Chromium בפרויקט קוד פתוח של Android ב-upstream.
- ייתכן שהטמעות מכשירים לא ייכללו במחרוזת של סוכן המשתמש.
רכיב ה-WebView אמור לכלול תמיכה בכמה תכונות של HTML5 ואם היא תומכת בתכונה הזו, היא צריכה להתאים מפרט HTML5.
[C-1-4] חובה לעבד את התוכן שסופק או את התוכן של כתובת ה-URL המרוחקת בתהליך בנפרד מהאפליקציה שמייצרת את ה-WebView. ספציפית בתהליך הרינדור הנפרד חייבים להיות הרשאות נמוכות יותר, כמזהה משתמש נפרד, ללא גישה לספריית הנתונים של האפליקציה. אין להם גישה ישירה לרשת, ויש להם גישה רק לרמה המינימלית הנדרשת שירותי מערכת ב-Binnder. הטמעת ה-AOSP של WebView עומדת בדרישות בדרישה הזו.
חשוב לשים לב שאם הטמעתם של מכשירים היא בגרסת 32 ביט או שאתם מצהירים על דגל התכונה
android.hardware.ram.low
, הם פטורים מסעיף C-1-3.
3.4.2. תאימות דפדפן
אם ההטמעות במכשירים כוללים אפליקציית דפדפן עצמאית בזמן הגלישה באינטרנט, הם:
- [C-1-1] חייבת לתמוך בכל אחד מממשקי ה-API האלה שקשורים מודעות HTML5:
- [C-1-2] חייב לתמוך ב-HTML5/W3C webstorage API אמור לתמוך ב-HTML5/W3C IndexedDB API. שימו לב שככל שהאינטרנט גופים לגבי תקני פיתוח עוברים עדיפות ל-IndexedDB על פני webstorage, IndexedDB צפוי להפוך לרכיב נדרש בגרסה העתידית של Android.
- ייתכן שיישלחו מחרוזת של סוכן משתמש מותאם אישית באפליקציית הדפדפן הנפרדת.
- עליכם ליישם תמיכה עבור כמה שיותר HTML5 בגרסה הנפרדת יישום דפדפן (מבוסס על דפדפן WebKit ב-upstream או החלפה של צד שלישי).
עם זאת, אם הטמעות המכשיר לא כוללות דפדפן נפרד הם:
- [C-2-1] עדיין חייבת לתמוך בדפוסי הכוונה ציבורית, כפי שמתואר סעיף 3.2.3.1.
3.5. תאימות התנהגותית ל-API
הטמעות מכשירים:
- [C-0-9] חובה לוודא שתאימות התנהגותית של API מיושמת על כל מותקנות, אלא אם הן מוגבלות כפי שמתואר סעיף 3.5.1.
- [C-0-10] אסור להטמיע את הגישה להוספה לרשימת ההיתרים שמבטיחה שה-API תאימות התנהגותית רק לאפליקציות שנבחרו על ידי המכשיר של מודלים גדולים של שפה.
ההתנהגות של כל אחד מסוגי ה-API (מנוהלת, ממשק רך, נייטיב ואינטרנט) חייבת להיות בהתאם להטמעה המועדפת של upstream פרויקט קוד פתוח של Android. אזורים ספציפיים של תאימות הם:
- [C-0-1] אסור למכשירים לשנות את ההתנהגות או את הסמנטיקה של כוונת רכישה סטנדרטית.
- [C-0-2] אסור למכשירים לשנות את הסמנטיקה של מחזור החיים או מחזור החיים סוג מסוים של רכיב מערכת (כגון Service, Activity, ContentProvider וכו').
- [C-0-3] אסור לשנות במכשירים את הסמנטיקה של הרשאות רגילות.
- אסור שהמכשירים ישנו את המגבלות שנאכפות על אפליקציות ברקע.
באופן ספציפי יותר, באפליקציות שפועלות ברקע:
- [C-0-4] הוא חייב להפסיק לבצע קריאות חוזרות (callback) שנרשמו על ידי
כדי לקבל פלטים מ
GnssMeasurement
ו-GnssNavigationMessage
. - [C-0-5] הם חייבים להגביל את תדירות העדכונים
שסופקו לאפליקציה באמצעות
LocationManager
מחלקה של API, או אתWifiManager.startScan()
. - [C-0-6] אם האפליקציה מטרגטת רמת API 25 ומעלה, אסור
לאפשר רישום של מקלטי שידורים עבור שידורים מרומזים של
Intents רגילים של Android במניפסט של האפליקציה, אלא אם השידור
Intent מחייב
"signature"
או"signatureOrSystem"
protectionLevel
או נמצאים רשימת פטור. - [C-0-7] אם האפליקציה מטרגטת רמת API 25 ומעלה, היא חייבת להפסיק את השימוש
את שירותי הרקע של האפליקציה, בדיוק כאילו האפליקציה קוראת
שירותים
stopSelf()
אלא אם האפליקציה ממוקמת ברשימת היתרים זמנית לטיפול שגלויה למשתמש. - [C-0-8] אם האפליקציה מטרגטת רמת API 25 ומעלה, היא חייבת משחררים את ה-Wakelocks שהאפליקציה מחזיקה.
- [C-0-4] הוא חייב להפסיק לבצע קריאות חוזרות (callback) שנרשמו על ידי
כדי לקבל פלטים מ
- [C-0-11] מכשירים חייבים להחזיר את ספקי האבטחה הבאים בתור הראשונים
מערך של שבעה ערכי
Security.getProviders()
בסדר גודל נתון, עם השמות הנתונים (כפי שהוחזרו על ידיProvider.getName()
) והמחלקות, אלא אם האפליקציה שינתה את הרשימה באמצעותinsertProviderAt()
אוremoveProvider()
. מכשירים MAY להחזיר ספקים נוספים אחרי רשימת הספקים שצוינה שלמטה.- 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, במקום ליישם מחדש חלקים משמעותיים במערכת.
3.5.1. הגבלת אפליקציות
אם הטמעת מכשירים במכשיר מטמיע מנגנון קנייני להגבלת אפליקציות (למשל, שינוי או הגבלה של התנהגויות API שמתוארות ב-SDK) וגם המנגנון הזה מגביל יותר מקטגוריית ההמתנה מוגבלת של אפליקציות, הוא:
- [C-1-1] חובה לאפשר למשתמש לראות את רשימת האפליקציות המוגבלות.
- [C-1-2] חובה לאפשר למשתמשים להפעיל או להשבית את כל האפשרויות האלה הגבלות קנייניות לגבי כל אפליקציה.
[C-1-3] אסור להחיל אוטומטית את ההגבלות הקנייניות האלה ללא ראיות להתנהגות לא תקינה של המערכת, אבל ייתכן שיחולו הגבלות על אפליקציות כשמזוהות התנהגות לא תקינה של המערכת, כמו חסימות תקועות של מצב שינה, פעילות ממושכת שירותים וקריטריונים אחרים. ייתכן שהקריטריונים נקבעים לפי המכשיר אבל חייבים להיות קשורים להשפעה של האפליקציה על תקינות המערכת. המלצות אחרות קריטריונים שאינם קשורים אך ורק לתקינות המערכת, כמו למשל היעדר פופולריות בשוק, אסור להשתמש בו כקריטריונים.
[C-1-4] אסור להחיל אוטומטית את ההגבלות הקנייניות האלה על אפליקציות כשמשתמש השבית את ההגבלות על האפליקציות באופן ידני, והוא עשוי להציע למשתמש להחיל את ההגבלות הקנייניות האלה.
[C-1-5] חובה ליידע את המשתמשים אם הגבלות קנייניות כאלה חלות על אפליקציה באופן אוטומטי, חייבים לספק מידע כזה בפרק הזמן של 24 השעות. לפני היישום של ההגבלות הקנייניות האלה.
[C-1-6] חובה להחזיר את הערך true עבור ActivityManager.isBackgroundRestricted() עבור כל הקריאות ל-API מאפליקציה.
[C-1-7] אסור להגביל את האפליקציה בחזית שמופיעה באופן מפורש בשימוש של למשתמש.
[C-1-8] חובה להשעות את ההגבלות הקנייניות האלה באפליקציה בכל פעם המשתמש מתחיל להשתמש באפליקציה באופן מפורש ובכך הופך אותה לקדמת הבמה תרגום מכונה.
[C-1-10] חובה לספק מסמך או אתר ציבורי וברור שמתארים האופן שבו חלות הגבלות קנייניות. המסמך או האתר הזה חייבים להיות שניתן לקשר ממסמכי Android SDK והוא חייב לכלול:
- הפעלת תנאים להגבלות קנייניות.
- אילו פעולות אפשר להגביל באפליקציה ואיך אפשר להגביל אותה.
- איך ניתן לפטור אפליקציה מהגבלות כאלה.
- איך אפליקציה יכולה לבקש פטור מהגבלות קנייניות אם לתמוך בפטור כזה לאפליקציות שהמשתמש יכול להתקין.
אם אפליקציה הותקנה מראש במכשיר ומעולם לא הייתה בשימוש מפורש משתמש במשך יותר מ-30 יום, פטור [C-1-3] [C-1-5].
אם ההטמעות במכשירים מאריכות את ההגבלות שמוטמעות ב-AOSP, ריכזנו כאן:
- [C-2-1]חובה לפעול לפי ההטמעה שמתוארת במסמך הזה.
3.5.2. מצב תנומה של אפליקציה
אם הטמעות המכשיר כוללות 'מצב תנומה של אפליקציה' שנכלל ב-AOSP או מרחיב את התכונה שכלולה ב-AOSP, ואז:
- [C-1-1] חייב לעמוד בכל הדרישות המפורטות בסעיף 3.5.1, למעט [C-1-6] ו-[C-1-3].
- [C-1-2] חובה להחיל את ההגבלה על האפליקציה רק כאשר: ראיה לכך שהמשתמש לא השתמש באפליקציה במשך פרק זמן מסוים. הזה מומלץ מאוד להגדיר את משך הזמן של חודש אחד או יותר. השימוש חייב להיות מוגדר באמצעות אינטראקציה מפורשת של משתמש באמצעות UsageStats#getLastTimePlayback() או כל דבר אחר שיגרום לאפליקציה לצאת ממצב ההפסקה האוטומטית, כולל קישורי שירותים, קישורים של ספקי תוכן, שידורים מפורשים וכו'. שאחריהן יתבצע מעקב באמצעות פונקציה חדשה של UsageStats#getLastTimeConditionUsed().
- [C-1-3] חובה להחיל רק הגבלות שמשפיעות על כל משתמשי המכשירים, היא הוכחה לכך שהחבילה לא הייתה בשימוש על ידי אף משתמש במשך פרק זמן מסוים בזמן האימון. מומלץ מאוד להגדיר משך זמן של חודש אחד או יותר.
- [C-1-4] אסור לאפשר לאפליקציה להגיב לכוונות פעילות, קישורי שירותים, בקשות של ספקי תוכן או שידורים בעלי תוכן בוטה.
'מצב תנומה של אפליקציות' ב-AOSP עומד בדרישות שצוינו למעלה.
3.6. מרחבי שמות של API
מערכת Android פועלת לפי מוסכמות מרחב השמות של החבילות והמחלקות שמוגדרות ב-Java בשפת תכנות. כדי להבטיח תאימות לאפליקציות של צד שלישי, אסור להם לבצע שינויים אסורים כלשהו (ראו בהמשך) כדי מרחבי השמות הבאים של חבילות:
java.*
javax.*
sun.*
android.*
androidx.*
com.android.*
כלומר, הן:
- [C-0-1] אסור לשנות את ממשקי ה-API שגלויים לכולם בפלטפורמת Android באמצעות שינוי כל שיטה או חתימות של כיתה, או הסרת כיתות או כיתה. .
- [C-0-2] אסור להוסיף אלמנטים שגלויים לכולם (כמו סיווגים ממשקים, או שדות או שיטות למחלקות או לממשקים קיימים) או לבדיקה או ממשקי API של המערכת לממשקי ה-API במרחבי השמות שלמעלה. "חשיפה באופן ציבורי יסוד" הוא כל מבנה שלא מקושט באמצעות התג ' @הסתרה' סמן בתור בקוד המקור של Android ב-upstream.
מטמיעי מכשירים עשויים לשנות את ההטמעה הבסיסית של ממשקי ה-API, אבל שינויים כאלה:
- [C-0-3] אסור להשפיע על ההתנהגות המוצהרת ועל החתימה בשפת Java של כל ממשקי API שגלויים לכולם.
- [C-0-4] אסור לפרסם או לחשוף למפתחים בכל דרך אחרת.
עם זאת, משתמשים שמטמיעים מכשירים עשויים להוסיף ממשקי API מותאמים אישית מחוץ ל-Android הרגיל מרחב השמות, אבל ממשקי ה-API המותאמים אישית:
- [C-0-5] אסור להיות במרחב שמות בבעלות אדם אחר
של הארגון. לדוגמה, אסור למטמיעי מכשירים להוסיף ממשקי API
com.google.*
או מרחב שמות דומה: רק Google יכולה לעשות זאת. באופן דומה, אסור ל-Google להוסיף ממשקי API לחברות אחרות מרחבי שמות. - [C-0-6] חייבים להיות ארוזים בספרייה משותפת של Android כך שרק אפליקציות שמשתמשים בהן במפורש (באמצעות המנגנון <uses-library>) מושפעות מהשימוש המוגבר בזיכרון של ממשקי API כאלה.
משתמשים שמטמיעים מכשירים יכולים להוסיף ממשקי API מותאמים אישית בשפות נייטיב, מחוץ ל-NDK אבל ממשקי ה-API בהתאמה אישית:
- [C-1-1] אסור להיות בספרייה NDK או בספרייה אחרת ארגון כפי שמתואר כאן.
אם מטמיע מכשיר מציע לשפר אחד ממרחבי השמות של החבילות שלמעלה (למשל, הוספה של פונקציונליות חדשה ומועילה לממשק API קיים, או הוספת פונקציונליות חדשה API), מכשיר ההטמעה צריך להיכנס לכתובת source.android.com ולהתחיל את התהליך להוספת שינויים בהתאם למידע שמופיע באותו אתר.
חשוב לשים לב שההגבלות שלמעלה תואמות למוסכמות הסטנדרטיות בנוגע למתן שמות ממשקי API בשפת התכנות Java; המטרה של הקטע הזה היא פשוט לחזק את המוסכמות האלה ולאלץ אותן לכלול את המוסכמות האלה הגדרה.
3.7. תאימות לסביבת זמן ריצה
הטמעות מכשירים:
[C-0-1] חייבת להיות תמיכה בפורמט המלא של Dalvik Executable (DEX) ו-Dalvik bytecode לרשימה and semantics.
[C-0-2] חובה להגדיר את זמני הריצה של Dalvik להקצות זיכרון בהתאם לפלטפורמת Android ב-upstream, וכפי שצוין בטבלה הבאה. (עיינו בסעיף 7.1.1 לקבלת הגדרות של גודל המסך וצפיפות המסך).
צריכה להשתמש ב-Android RunTime (ART), ההפניה ל-upstream של Dalvik Executable Format, ואת ההפניה של מערכת ניהול החבילות.
אמורות להריץ בדיקות fuzz במצבי ביצוע שונים ולטרגט ארכיטקטורות כדי להבטיח את היציבות של סביבת זמן הריצה. פרטים נוספים JFuzz ו-DexFuzz באתר של פרויקט הקוד הפתוח של Android.
שימו לב שערכי הזיכרון המפורטים למטה נחשבים לערכים מינימליים ייתכן שהטמעות במכשירים מקצים יותר זיכרון לכל אפליקציה.
פריסת מסך | דחיסות מסך | זיכרון מינימלי של האפליקציה |
---|---|---|
שעון Android | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | ||
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | 36MB | |
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (xhdpi) | 48MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 56MB | |
420 dpi (420dpi) | 64MB | |
480 dpi (xxhdpi) | 88MB | |
560 dpi (560dpi) | 112MB | |
640 dpi (xxxhdpi) | 154MB | |
קטן/רגיל | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | 48MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (xhdpi) | 80MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 96MB | |
420 dpi (420dpi) | 112MB | |
480 dpi (xxhdpi) | 128MB | |
560 dpi (560dpi) | 192MB | |
640 dpi (xxxhdpi) | 256MB | |
גדולה | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | 48MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 80MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 96MB | |
320 dpi (xhdpi) | 128MB | |
360 dpi (360dpi) | 160MB | |
400 dpi (400dpi) | 192MB | |
420 dpi (420dpi) | 228MB | |
480 dpi (xxhdpi) | 256MB | |
560 dpi (560dpi) | 384MB | |
640 dpi (xxxhdpi) | 512MB | |
xlarge | 120 dpi (ldpi) | 48MB |
140 dpi (140dpi) | 80MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 96MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 144MB | |
320 dpi (xhdpi) | 192MB | |
360 dpi (360dpi) | 240MB | |
400 dpi (400dpi) | 288MB | |
420 dpi (420dpi) | 336MB | |
480 dpi (xxhdpi) | 384MB | |
560 dpi (560dpi) | 576MB | |
640 dpi (xxxhdpi) | 768MB |
3.8. תאימות לממשק משתמש
3.8.1. מרכז האפליקציות (מסך הבית)
Android כולל את אפליקציית מרכז האפליקציות (מסך הבית) ותמיכה עבור אפליקציות של צד שלישי שיחליפו את מרכז האפליקציות של המכשיר (מסך הבית).
אם ההטמעות של המכשיר מאפשרות לאפליקציות של צד שלישי להחליף את המכשיר במסך הבית, הם:
- [C-1-1] חובה להצהיר על הפיצ'ר
android.software.home_screen
בפלטפורמה. - [C-1-2] חייב להחזיר את
AdaptiveIconDrawable
כשאפליקציית הצד השלישי משתמשת בתג<adaptive-icon>
כדי לספק הסמל שלו, וגםPackageManager
השיטות לאחזור סמלים נקראות.
אם ההטמעות במכשיר כוללות מרכז אפליקציות שמוגדר כברירת מחדל שתומך באפליקציה הם:
- [C-2-1] חובה לדווח על
true
עבורShortcutManager.isRequestPinShortcutSupported()
. - [C-2-2] המשתמש צריך לעמוד בתנאים כדי לשאול את המשתמש לפני הוספת קיצור דרך בבקשה
באמצעות אפליקציות דרך
ShortcutManager.requestPinShortcut()
שיטת ה-API. - [C-2-3] חייבת לתמוך במקשי קיצור מוצמדים ובמקשי קיצור דינמיים וסטטיים קיצורי הדרך כפי שמתואר בדף קיצורי הדרך של האפליקציות.
לעומת זאת, אם הטמעות המכשירים לא תומכות בהצמדה של מקשי קיצור:
- [C-3-1] חובה לדווח על
false
עבורShortcutManager.isRequestPinShortcutSupported()
.
אם בהטמעות במכשיר מוטמע מרכז אפליקציות שמוגדר כברירת מחדל שמספק גישה לקיצורי הדרך הנוספים שמסופקים על ידי אפליקציות צד שלישי דרך קיצורי דרך הן:
- [C-4-1] חייבת לתמוך בכל תכונות קיצורי הדרך המתועדות (למשל,
קיצורי דרך דינמיים, הצמדת קיצורי דרך) וליישם באופן מלא את ממשקי ה-API של
ShortcutManager
סיווג API.
אם ההטמעות במכשיר כוללות אפליקציית מרכז אפליקציות שמוגדרת כברירת מחדל, ומוצגים בה תגים של סמלי האפליקציות, הם:
- [C-5-1] חובה לכבד את
NotificationChannel.setShowBadge()
שיטת ה-API. במילים אחרות, להציג עלות חזותית שמשויכת לסמל האפליקציה, אם הערך מוגדר כ-true
ולא יוצג סכמת תגים של סמל האפליקציה כשהכול מערוצי ההתראות של האפליקציה, הגדירו את הערך כ-false
. - יכולים לעקוף את התגים של סמל האפליקציה בסכמת התגים הקניינית שלהם אם
של צד שלישי מציינות שיש תמיכה בסכימת התגים הקניינית
באמצעות השימוש בממשקי API קנייניים, אבל צריך להשתמש במשאבים ובערכים
סופקו באמצעות ממשקי ה-API של תגי ההתראות שמתוארים ב-SDK,
כמו
Notification.Builder.setNumber()
וגםNotification.Builder.setBadgeIconType()
API.
אם ההטמעות במכשירים תומכים מונוכרומטי סמלים, הסמלים הבאים:
- [C-6-1] חובה להשתמש בו רק כשהמשתמש מפעיל אותם באופן מפורש (למשל, 'הגדרות' או התפריט של בוחר הטפטים).
3.8.2. ווידג'טים
מערכת Android תומכת בווידג'טים של אפליקציות צד שלישי על ידי הגדרת סוג רכיב API ומחזור חיים תואמים שמאפשרים לאפליקציות לחשוף "AppWidget" למשתמש הקצה.
אם הטמעות במכשירים תומכים בווידג'טים של אפליקציות של צד שלישי:
- [C-1-1] חובה להצהיר על תמיכה בתכונה 'פלטפורמה'
android.software.app_widgets
- [C-1-2] חובה לכלול תמיכה מובנית ב-AppWidgets ולאפשר חשיפה ממשק משתמש להוספה, הגדרה, הצגה והסרה של AppWidgets
- [C-1-3] חייבת להיות אפשרות להציג ווידג'טים שגודלם הוא 4 x 4 בגודל הרשת הרגיל. כדאי לעיין בהנחיות העיצוב של ווידג'ט האפליקציה במסמכי התיעוד של Android SDK.
- ייתכן שתתמוך בווידג'טים של אפליקציות במסך הנעילה.
אם בהטמעות במכשירים יש תמיכה בווידג'טים של אפליקציות של צד שלישי ובאפליקציה הם:
- [C-2-1] חובה לדווח על
true
עבורAppWidgetManager.html.isRequestPinAppWidgetSupported()
. - [C-2-2] המשתמש צריך לעמוד בתנאים כדי לשאול את המשתמש לפני הוספת קיצור דרך בבקשה
באמצעות אפליקציות דרך
AppWidgetManager.requestPinAppWidget()
שיטת ה-API.
3.8.3. התראות
Android כולל את Notification
וגם
NotificationManager
ממשקי API שמאפשרים למפתחי אפליקציות של צד שלישי להודיע למשתמשים על אירועים חשובים
למשוך משתמשים תשומת לב באמצעות רכיבי החומרה (למשל צליל, רטט
אור) ותכונות תוכנה (למשל לוח הודעות, סרגל מערכת) של
במכשיר.
3.8.3.1. הצגת התראות
אם הטמעות במכשירים מאפשרות לאפליקציות של צד שלישי להודיע למשתמשים על אירועים חשובים:
- [C-1-1] חייבת לתמוך בהתראות שמשתמשות בתכונות חומרה, כפי שמתואר ב מסמכי התיעוד בנושא ה-SDK, ובמידת האפשר, דרך הטמעת המכשיר חומרה. לדוגמה, אם יישום של מכשיר כולל רטט, חובה להשתמש בו להטמיע בצורה נכונה את ממשקי ה-API של הרטט. אם הטמעת המכשיר חסרה בחומרה, ממשקי ה-API התואמים חייבים להיות מוטמעים כפעולות ללא תפעול. מה קורה? מפורט יותר בסעיף 7.
- [C-1-2] חייב לעבד את כל המשאבים בצורה נכונה (סמלים, קובצי אנימציה וכו') שסופקו בממשקי ה-API או מדריך סגנון סמל של סרגל הסטטוס/סרגל המערכת, למרות שהן עשויות לספק חוויית משתמש חלופית לקבלת התראות יותר מזה שסופק על ידי ההפניה בהטמעת קוד פתוח של Android.
- [C-1-3] חובה לכבד את ההתנהגות שתוארו וליישם אותה באופן תקין ממשקי ה-API כדי לעדכן, להסיר ולקבץ התראות.
- [C-1-4] חייב לספק את ההתנהגות המלאה של NotificationChannel API מתועד ב-SDK.
- [C-1-5] חובה לספק למשתמש אפשרות לחסום ולשנות התראה מאפליקציית צד שלישי בכל רמה של ערוץ וחבילת אפליקציה.
- [C-1-6] חובה לספק למשתמש גם אפשרות להציג התראה שנמחקה הערוצים שלך.
[C-1-7] חובה לעבד באופן תקין את כל המשאבים (תמונות, סטיקרים, סמלים וכו') סופק באמצעות Notification.MessagingStyle לצד טקסט ההתראה, ללא אינטראקציה נוספת מצד המשתמש. עבור לדוגמה, חייבים להציג את כל המשאבים, כולל סמלים שסופקו באמצעות android.app.person בשיחה קבוצתית setGroupConversation.
[C-SR-1] מומלץ מאוד לספק למשתמש מחיר נוח לשלוט בהתראות שנחשפו לאפליקציות שקיבלו את התג הרשאת 'האזנה להתראות'. רזולוציית הניווט חייבת להיות כדי שהמשתמש יוכל שליטה עבור כל מאזין התראה כזה מהם סוגי ההתראות על המאזינים האלה. הסוגים חייבים לכלול "שיחות", "התראות", 'שקט' ו'מתמשך' התראות.
[C-SR-2] מומלץ מאוד לספק למשתמשים אפשרות לפרט אפליקציות שלא יכללו התראות ממאזינים ספציפיים להתראות.
[C-SR-3] מומלץ מאוד להציג למשתמשים מודעות שמתאימות באופן אוטומטי להוצאות שלהם לחסום התראות מאפליקציה מסוימת של צד שלישי בכל ערוץ ואפליקציה החבילה, אחרי שהמשתמש סגר את ההתראה כמה פעמים.
אמורות לתמוך בהתראות מתקדמות.
אמורות להיות מוצגות התראות עם עדיפות גבוהה יותר כהתראות 'שימו לב'.
צריכה להיות למשתמש אפשרות להשהות התראות.
יכול להיות בניהול רק מקרים שבהם אפליקציות צד שלישי יוכלו לשלוח התראות משתמשים באירועים חשובים כדי לצמצם בעיות בטיחות כמו הסחות דעת של הנהג.
ב-Android 11 יש תמיכה בהתראות על שיחות, התראות שנעשה בהן שימוש ב-MessagingStyle ומספק מזהה קיצור דרך לאנשים שפורסם.
הטמעות מכשירים:
- [C-SR-4] מומלץ מאוד לקבץ ולהציג
conversation notifications
לפני התראות על הודעות שאינן שיחה, מלבד התראות מתמשכות לגבי שירות שפועל בחזית ו-importance:high
התראות.
אם בהטמעות במכשירים יש תמיכה ב-conversation notifications
והאפליקציה מספקת את הנתונים הנדרשים
bubbles
, הן:
- [C-SR-5] מומלץ מאוד להציג את השיחה הזו כבועה. הטמעת ה-AOSP עומדת בדרישות הבאות באמצעות ממשק המשתמש של המערכת שמוגדר כברירת מחדל, הגדרות, מרכז האפליקציות.
אם בהטמעות במכשירים יש תמיכה בהתראות מתקדמות, הן:
- [C-2-1] חייבים להשתמש במשאבים המדויקים כמו
סופקו באמצעות
Notification.Style
מחלקה של API ומחלקות המשנה שלו עבור רכיבי המשאבים המוצגים. - צריך להציג כל אחד מרכיבי המשאב (למשל,
סמל, כותרת וטקסט סיכום) שמוגדרים ב
Notification.Style
. ה-API ומחלקות המשנה שלו.
התראות 'שימו לב' הן התראות מוצגת למשתמש כשהוא נכנס בנפרד לפלטפורמה שבה המשתמש נמצא מופעלת. אם ההטמעות במכשירים תומכים בתכונה 'שימו לב' התראות, ואז:
- [C-3-1] חובה להשתמש במשאבים ובתצוגת ההתראות של 'שימו לב'
כפי שמתואר ב
Notification.Builder
סיווג API כשמוצגות התראות 'שימו לב'. - [C-3-2] חובה להציג את הפעולות שסופקו באמצעות
Notification.Builder.addAction()
יחד עם תוכן ההתראה, ללא אינטראקציה נוספת מצד המשתמש כפי שמתואר ב-SDK.
3.8.3.2. שירות האזנה להתראות
Android כולל את NotificationListenerService
ממשקי API שמאפשרים לאפליקציות (לאחר שהמשתמש הפעיל אותן באופן מפורש) לקבל עותק של
את כל ההתראות כאשר הן מתפרסמות או מתעדכנות.
הטמעות מכשירים:
- [C-0-1] יש לעדכן את ההתראות באופן תקין ומהיר לכל שירותי המאזינים המותקנים ומותאמי המשתמשים, כולל את כל המטא-נתונים שמצורפים לאובייקט ההתראה.
- [C-0-2] חובה לכבד את
snoozeNotification()
קריאה ל-API, סגירת ההתראה וביצוע קריאה חוזרת אחרי הטיפול לטיפול בהמשך משך הזמן שמוגדר בקריאה ל-API.
אם בהטמעות של מכשירים יש למשתמש אפשרות להשהות התראות:
- [C-1-1] חייבת לשקף כראוי את הסטטוס של ההתראה במצב 'נודניק'
באמצעות ממשקי ה-API הרגילים כמו
NotificationListenerService.getSnoozedNotifications()
- [C-1-2] המשתמש צריך להיות זמין להשהיית התראות באופן יחסי מכל אפליקציה מותקנת של צד שלישי, אלא אם שירותים קבועים או שפועלים בחזית.
3.8.3.3. נא לא להפריע (נא לא להפריע) / מצב עדיפות
אם הטמעות המכשיר תומכות בתכונה DND (שנקרא גם 'מצב עדיפות'), הן:
- [C-1-1] חובה, כאשר הטמעת המכשיר מספקת אמצעי למשתמש כדי להעניק או לדחות לאפליקציות צד שלישי גישה להגדרות המדיניות של ה-DND, הצגת כללי DND אוטומטיים שנוצרו על ידי אפליקציות לצד הכללים שנוצרו על ידי המשתמשים ומוגדרים מראש.
- [C-1-3] חייב לכבד את
suppressedVisualEffects
ערכים שמועברים לאורך הערךNotificationManager.Policy
ואם אפליקציה הגדירה SUPPRESSED_EFFECT_SCREEN_OFF או SUPPRESSED_EFFECT_SCREEN_ON מסומן, יש לציין למשתמש ש האפקטים החזותיים מושבתים בתפריט ההגדרות של DND.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
3.8.3.4. הגנה על התראות רגישות
מידע רגיש כולל התראות, כמו סיסמאות חד-פעמיות, קודי אישור חד-פעמיים וקודי אימות או איפוס דומים, יכול להופיע ב התראות למשתמשים.
אם ההטמעות במכשירים מאפשרות לאפליקציות של צד שלישי להודיע למשתמשים על אירועים חשובים, הם:
[C-1-1] חובה לצנזר מידע רגיש מהעברתו אל מאזינים להתראות, אלא אם שירות המאזינים הוא אחד מהבאים:
- אפליקציות שחתומות על ידי המערכת עם
uid
< 10,000 - ממשק משתמש של המערכת
- קונכייה
- אפליקציה ייעודית למכשיר נלווית (הוגדרה על ידי
CompanionDeviceManager
) - תפקיד אחד (
SYSTEM_AUTOMOTIVE_PROJECTION
) - תפקיד אחד (
SYSTEM_NOTIFICATION_INTELLIGENCE
) - תפקיד בדף הבית
- אפליקציות שחתומות על ידי המערכת עם
הטמעת ה-AOSP של
NotificationAssistantServices
ממחישה ועומדת בדרישות האלה. צפייה
android.ext.services.notification
כדוגמה.
סיום הדרישות החדשות
3.8.4. ממשקי API מסייעים
מערכת Android כוללת את Assist APIs כדי לאפשר לאפליקציות לבחור כמה מידע מתוך ההקשר הנוכחי משותף עם Assistant במכשיר.
אם הטמעות מכשירים תומכות בפעולה Assist:
- [C-2-1] חובה לציין בבירור למשתמש הקצה מתי ההקשר משותף, על ידי
אחת משתי האפשרויות:
- בכל פעם שאפליקציית העזרה ניגשת להקשר, מוצג סמל לבן אור מסביב לקצוות המסך אם משך הזמן ארוך או ארוך יותר, הבהירות של הטמעת פרויקט הקוד הפתוח של Android.
- עבור אפליקציית העזרה המותקנת מראש, הצעת מחיר נמוכה יותר למשתמש במרחק של שני ניווטים בתפריט ההגדרות של אפליקציית העזרה והקלט הקולי שמוגדר כברירת מחדל, ושיתוף ההקשר רק כאשר אפליקציית העזרה מופעלת באופן מפורש על ידי את המשתמש באמצעות מילת הפעלה או קלט של מקש ניווט.
- [C-2-2] האינטראקציה הייעודית להפעלת אפליקציית העזרה, כפי שמתואר
בסעיף 7.2.3 חייבים להפעיל את
אפליקציית עזר מסוימת. במילים אחרות, האפליקציה שמטמיעה את
VoiceInteractionService
, או פעילות שמטפלת בהכוונה שלACTION_ASSIST
.
3.8.5. התראות והודעות קוליות
אפליקציות יכולות להשתמש בToast
API להצגת מחרוזות קצרות שאינן מודאליות למשתמש הקצה שנעלמות אחרי
לפרק זמן קצר, ולהשתמש בTYPE_APPLICATION_OVERLAY
window type API להצגת חלונות התראות כשכבת-על מעל אפליקציות אחרות.
אם הטמעות במכשירים כוללות פלט מסך או פלט וידאו:
[C-1-1] חובה לספק למשתמש אפשרות למנוע מאפליקציה להציג התראות חלונות שנעשה בהם שימוש ב
TYPE_APPLICATION_OVERLAY
. הטמעת ה-AOSP עומדת בדרישה הזו בכך שהיא כוללת פקדים בלוח ההתראות.[C-1-2] חייבים לפעול בהתאם ל-Toast API ולהציג טוסטים מאפליקציות למשתמשי קצה במקרים מסוימים באופן גלוי.
3.8.6. עיצובים
מערכת Android מספקת 'עיצובים' כמנגנון לאפליקציות ליישום סגנונות בכל פעילות או אפליקציה בשלמותה.
Android כולל 'Holo' ו-'Material' משפחת עיצובים כסדרה של סגנונות מוגדרים שמפתחי אפליקציות יוכלו להשתמש בהן אם הם רוצים להתאים מראה וסגנון של עיצוב Hoolo כפי שהוגדר על ידי Android SDK.
אם הטמעות במכשירים כוללות פלט מסך או פלט וידאו:
- [C-1-1] אסור לשנות את המאפיינים של עיצוב Hoolo שנחשפים תרגום מכונה.
- [C-1-2] חייב לתמוך ב-"Material" ואסור לשנות אף אחד מהמאפיינים האלה מאפייני העיצוב של חומר הלימוד או הנכסים שלהם חשופים לאפליקציות.
[C-1-3] חובה להגדיר את "sans-serif" משפחת גופנים ל Roboto גרסה 2.x עבור השפות ש-Roboto תומך בו או מספק למשתמש אפשרות לשנות את הגופן שבו נעשה שימוש ל-sans-serif משפחת הגופנים לRoboto גרסה 2.x עבור השפות הנתמכות ב-Roboto.
[C-1-4] חובה ליצור לוחות צבעים דינמיים של צבעים כפי שצוין ב-AOSP תיעוד של
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(מידע נוסף זמין כאןandroid.theme.customization.system_palette
והקבוצהandroid.theme.customization.theme_style
).[C-1-5] חובה ליצור לוחות צבעים דינמיים של צבעים באמצעות סגנונות של ערכת צבעים שצויין ב-
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
תיעוד (ראוandroid.theme.customization.theme_styles
), כלומרTONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
,FRUIT_SALAD
ו-MONOCHROMATIC
.צבע המקור משמש ליצירת לוחות צבעים דינמיים של צבעים כאשר נשלחים
android.theme.customization.system_palette
(כפי שמתועד ב-Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
).[C-1-6] ערך chroma
CAM16
חייב להיות גבוה מ-5.אמור להיגזר מהטפט דרך
com.android.systemui.monet.ColorScheme#getSeedColors
, שמספק מספר צבעי מקור חוקיים לבחירה אחד.צריך להשתמש בערך
0xFF1B6EF3
אם אף אחד מהצבעים שצוינו לא מתאים את דרישת צבע המקור שצוינה למעלה.
Android כולל גם את האפשרות 'ברירת המחדל של המכשיר' משפחת עיצובים כסדרה של סגנונות מוגדרים שבו מפתחי אפליקציות יוכלו להשתמש אם הם רוצים להתאים למראה ולתחושה של ערכת הצבעים במכשיר כפי שהוגדר בהטמעה של המכשיר.
- הטמעת מכשירים עשויה לשנות את מאפייני העיצוב שמוגדרים כברירת מחדל במכשיר שנחשפים לאפשרויות הבאות: תרגום מכונה.
ב-Android יש תמיכה בעיצוב וריאנטים עם סרגלי מערכת שקופים, שמאפשרים של מפתחי אפליקציות למלא את האזור שמאחורי הסטטוס וסרגל הניווט עם התוכן של האפליקציה. כדי לאפשר חוויית פיתוח עקבית חשוב לשמור על סגנון הסמלים של שורת הסטטוס של מכשירים שונים.
אם יישומי המכשיר כוללים שורת סטטוס של המערכת:
- [C-2-1] חובה להשתמש בלבן לסמלי סטטוס המערכת (כמו עוצמת אות רמת הטעינה) והתראות על ידי המערכת, אלא אם הסמל שמציינת סטטוס בעייתי או שאפליקציה מבקשת שורת סטטוס נורית באמצעות WindowInsetsController#APPEARANCE_Light_STATUS_BARS לסמן.
- [C-2-2] הטמעות של מכשירי Android חייבות לשנות את צבע המערכת סמלי הסטטוס לשחור (לפרטים, אפשר לקרוא את המאמר R.style) כשאפליקציה מבקשת שורת סטטוס של נורית.
3.8.7. טפטים מונפשים
ב-Android מוגדרים סוג רכיב ו-API ומחזור חיים תואמים שמאפשרים חשיפה אחת או יותר "טפטים מונפשים" למשתמש הקצה. טפטים דינמיים הם אנימציות, תבניות או תמונות דומות עם יכולות קלט מוגבלות שמוצגות כטפט, תרגום מכונה.
החומרה נחשבת מאפשרת הפעלה אמינה של טפטים מונפשים אם היא יכולה לפעול כל הטפטים המונפשים, ללא מגבלות על פונקציונליות, במסגרת סבירה ללא השפעות שליליות על אפליקציות אחרות. אם הגבלות חומרה שגורמת לטפטים ו/או לאפליקציות לקרוס, לתקלה, ליצור עוצמת המעבד (CPU) או הסוללה פועלים בקצב פריימים נמוך מדי, באופן שאינו מקובל, שנחשבת כחומרה שלא מאפשרת להפעיל טפט דינמי. לדוגמה, כמה טפטים דינמיים עשויים להשתמש בהקשר של OpenGL 2.0 או 3.x כדי לעבד את התוכן שלהם. טפט דינמי לא יפעל באופן מהימן בחומרה שלא תומכת בריבוי הקשרי OpenGL כי השימוש בטפט הפעיל בהקשר של OpenGL עלול להיות מתנגש עם אפליקציות אחרות שמשתמשות גם בהקשר של OpenGL.
- הטמעת מכשירים שמאפשרים להריץ טפטים דינמיים באופן מהימן, כפי שמתואר שלמעלה אמורה להטמיע טפטים מונפשים.
אם הטמעתם במכשיר טפטים דינמיים:
- [C-1-1] חובה לדווח על דגל הפלטפורמה android.software.live_wallpaper.
3.8.8. החלפת פעילות
קוד המקור של Android ב-upstream כולל את מסך הסקירה הכללית, a ממשק משתמש ברמת המערכת למעבר בין משימות ולהצגה של גישה מהזמן האחרון פעילויות ומשימות באמצעות תמונה ממוזערת של הגרפיקה של האפליקציה ברגע שהמשתמש עזב את האפליקציה בפעם האחרונה.
הטמעת מכשירים כולל מקש הניווט של הפונקציה האחרונה, כפי שמפורט סעיף 7.2.3 עשוי לשנות את הממשק.
אם בהטמעות של מכשירים, כולל מקש הניווט של הפונקציה האחרונה, כפי שמפורט ב 7.2.3 משנים את הממשק, הן:
- [C-1-1] חייבת לתמוך לפחות ב-7 פעילויות מוצגות.
- צריכה להציג לפחות כותרת של 4 פעילויות בכל פעם.
- אמורות להציג את צבע ההדגשה, הסמל וכותרת המסך האחרונים.
- אמורה להציג מחיר סגירה (x) אבל יכול להיות שיחול עיכוב עד שתהיה למשתמש אינטראקציה עם המסכים.
- עליכם להטמיע קיצור דרך כדי לעבור בקלות לפעילות הקודמת.
- אמורה להפעיל את פעולת המעבר המהיר בין שתי התוכנות האחרונות שהיו בשימוש אפליקציות, כשמקישים פעמיים על מקש הפונקציה האחרון.
- אמורה להפעיל את מצב ריבוי חלונות של מסך מפוצל, אם יש תמיכה, ללחיצה ארוכה על 'פונקציות אחרונות'.
- יכול להיות שיוצגו נכסים משויכים אחרונים כקבוצה שנעשית יחד.
- [C-SR-1] מומלץ מאוד להשתמש במשתמש Android OS (או ממשק דומה מבוסס על תמונות ממוזערות) למסך הסקירה הכללית.
3.8.9. ניהול קלט
Android כולל תמיכה ב: ניהול קלט ותמיכה לעורכים של שיטות קלט של צד שלישי.
אם הטמעות של מכשירים מאפשרות למשתמשים להשתמש בשיטות קלט של צד שלישי במכשיר, הן:
- [C-1-1] חובה להצהיר על תכונת הפלטפורמה android.software.input_methods וגם לתמוך בממשקי API של IME כפי שמוגדר במסמכי התיעוד של Android SDK.
3.8.10. בקרת מדיה במסך הנעילה
ה-API של הלקוח של השלט הרחוק הוצא משימוש ב-Android 5.0 לטובת תבנית של התראות מדיה שמאפשר לאפליקציות מדיה להשתלב עם פקדי הפעלה תוצג במסך הנעילה.
3.8.11. שומרי מסך (לשעבר Dreams)
להגדרות, יש לעיין בסעיף 3.2.3.5 בכוונה לצרף את שומרי המסך.
3.8.12. מיקום
אם יישומי המכשיר כוללים חיישן חומרה (למשל GPS) בעל יכולות בציון הקואורדינטות של המיקום,
- [C-1-2] חובה להציג את הסטטוס הנוכחי של המיקום בתפריט המיקום שב'הגדרות'.
- [C-1-3] אסור להציג מצבי מיקום בתפריט המיקום שב'הגדרות'.
3.8.13. Unicode וגופן
מערכת Android כוללת תמיכה בתווי האמוג'י שמוגדרים ב Unicode 10.0.
אם הטמעות במכשירים כוללות פלט מסך או פלט וידאו:
- [C-1-1] חייבת להיות אפשרות להציג את תווי האמוג'י האלה בגליף צבעים.
- [C-1-2] חייבת לכלול תמיכה בנושאים הבאים:
- גופן Roboto 2 עם משקלים שונים –sans-serif-thin, San-serif-light, Sans Serif-medium, sens-serif-black, sans-serif-מרוכז, Sans-Sift-endured Contracted לשפות הזמינות במכשיר.
- כיסוי מלא של Unicode 7.0 לאותיות לטיניות, יווניות וקיריליות, כולל טווחים לטיניים מורחבים A, B, C ו-D וכל הגליפים במטבע של Unicode 7.0.
- [C-1-3] אסור להסיר או לשנות את NotoColorEmoji.tff בתמונת המערכת. (ניתן להוסיף גופן חדש לאמוג'י כדי לשנות את האמוג'י במקום הזה NotoColorEmoji.tff)
- צריכה לתמוך בגוון העור ובאמוג'י משפחתי מגוונים, כפי שמצוין דוח טכני מס' 51 של Unicode.
אם הטמעות המכשירים כוללות IME, הן:
- צריכה לספק למשתמשים שיטת קלט לתווי האמוג'י האלה.
ב-Android יש תמיכה בעיבוד גופנים במיאנמר. במיאנמר יש כמה גופנים שאינם תואמים ל-Unicode, הידועים בשם "Zawgyi", לעיבוד של מיאנמר בשפות שונות.
אם הטמעות המכשירים כוללות תמיכה בבורמזית, הן:
- [C-2-1] חייב לעבד טקסט בגופן תואם Unicode כברירת מחדל. אסור להגדיר גופן שלא תואם ל-Unicode, אלא אם המשתמש בוחר אותה בכלי לבחירת שפה.
- [C-2-2] חייב לתמוך בגופן Unicode ובגופן שאינו תואם ל-Unicode אם במכשיר יש תמיכה בגופן שאינו תואם ל-Unicode. לא בפורמט Unicode אסור להסיר או להחליף את הגופן ב-Unicode.
- [C-2-3] יש לעבד טקסט עם גופן שאינו תואם ל-Unicode רק אם קוד שפה עם קוד סקריפט Qaag מוגדר (למשל my-Qaag). אין קודי שפה או אזורים אחרים של ISO (בין אם מוקצים, לא מוקצים או שמורים) כדי להתייחס לקובצי Unicode גופן שתואם למיאנמר. מפתחי אפליקציות ומחברים של דפי אינטרנט יכולים לציין את my-Qaag כקוד השפה הייעודי, כפי שיועד לכל שפה אחרת.
3.8.14. חלונות מרובים
אם יישומים של מכשירים יכולים להציג פעילויות מרובות באותו זמן:
- [C-1-1] חייבים להטמיע מצב כזה של ריבוי חלונות בהתאם התנהגות של אפליקציות וממשקי API שמתוארים ב-Android SDK מסמכי תיעוד לתמיכה במצב ריבוי חלונות ופגישות הדרישות הבאות:
- [C-1-2] חובה לכבד את
android:resizeableActivity
שמוגדר על ידי אפליקציה בקובץAndroidManifest.xml
כפי שמתואר ערכת ה-SDK הזו. - [C-1-3] אסור להציע מצב מסך מפוצל או מצב חופשי אם גובה המסך קטן מ-440dp ורוחב המסך קטן מ-440 dp.
- [C-1-4] אסור לשנות את הגודל של פעילות לגודל הקטן מ-220dp אינץ' למצבי ריבוי חלונות שאינם 'תמונה בתוך תמונה'.
- הטמעת מכשירים עם גודל מסך
xlarge
צריכה לתמוך בפריסה גמישה במצב תצוגה.
אם בהטמעות של מכשירים יש תמיכה במצבים של ריבוי חלונות, והמסך המפוצל במצב הזה:
- [C-2-2] חובה לחתוך את הפעילות בעגינה של מסך מפוצל עם כמה חלונות, אבל אמור להציג תוכן מסוים ממנו, אם אפליקציית מרכז האפליקציות היא החלון שבו מתמקדים.
- [C-2-3] חובה לפעול בהתאם להצהרה
AndroidManifestLayout_minWidth
שהוצהרה ו-AndroidManifestLayout_minHeight
של יישום מרכז האפליקציות של צד שלישי ולא לבטל את הערכים האלה. כשמציגים תוכן מסוים של הפעילות באביזר העגינה.
אם בהטמעות במכשירים יש תמיכה במצבי ריבוי חלונות ובמצב 'תמונה בתוך תמונה' במצב ריבוי חלונות, הם:
- [C-3-1] חובה להפעיל פעילויות במצב 'תמונה בתוך תמונה' בכמה חלונות
כשהאפליקציה:
* טירגוט לרמת API 26 ומעלה וההצהרה מוצהרת
android:supportsPictureInPicture
* טירגוט לרמת API 25 ומטה והצהרה על שתיהןandroid:resizeableActivity
וandroid:supportsPictureInPicture
. - [C-3-2] חייבים לחשוף את הפעולות ב-SystemUI בתור
מצוין על ידי הפעילות הנוכחית של התמונה בתוך התמונה (PIP) באמצעות
setActions()
API. - [C-3-3] חייב לתמוך ביחסי גובה-רוחב שגדולים מ- או שווים לו
1:2.39 וקטן מ-2.39:1 או שווה לו, כפי שצוין בפעילות PIP דרך
setAspectRatio()
API. - [C-3-4] חובה להשתמש ב-
KeyEvent.KEYCODE_WINDOW
כדי לשלוט בחלון 'תמונה בתוך תמונה'; אם מצב PIP לא מוטמע, המפתח חייב להיות זמינים לפעילות בחזית. - [C-3-5] חובה לספק למשתמשים מספיק כסף כדי לחסום את הצגת האפליקציה מצב PIP; שהטמעת ה-AOSP עומדת בדרישה הזו. הפקדים בלוח ההתראות.
[C-3-6] חובה להקצות את הרוחב והגובה המינימליים הבאים בשביל התמונה בתוך התמונה (PIP) חלון זמן שבו האפליקציה לא מצהירה על ערך כלשהו של
AndroidManifestLayout_minWidth
וגםAndroidManifestLayout_minHeight
:- מכשירים שהמצב Configuration.uiMode שלהם מוגדר מלבד
UI_MODE_TYPE_TELEVISION
רוחב וגובה מינימליים חייבים להיות 108dp. - מכשירים שהמצב Configuration.uiMode שלהם מוגדר לערך
UI_MODE_TYPE_TELEVISION
חובה להקצות רוחב מינימלי של 240dp וגובה מינימלי של 135dp.
- מכשירים שהמצב Configuration.uiMode שלהם מוגדר מלבד
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם הטמעות המכשיר כוללות יותר מרכיב אחד שתואם ל-Android והופכים אזורים כאלה לזמינים לאפליקציות, הם:
- [C-4-1] חייבת לתמוך במצב ריבוי חלונות.
אם הטמעות במכשירים תומכים במצב של ריבוי חלונות:
- [C-5-1] חובה להטמיע את הגרסה הנכונה של התוספים לניהול החלונות
רמת ה-API כפי שמתואר ב
WindowManager
תוספים.
סיום הדרישות החדשות
3.8.15. גזירה במסך
Android תומך בגזירה במסך כפי שמתואר
במסמך ה-SDK. ה-API DisplayCutout
מגדיר
אזור בקצה המסך שייתכן שאינו פעיל עבור אפליקציה
בגלל חיתוך התצוגה או תצוגה מעוקלת בקצוות.
אם הטמעתם במכשירים את המגרעת במסך, המכשיר:
- [C-1-5] אסור שיהיו גזירים אם יחס הגובה-רוחב של המכשיר הוא 1.0(1:1).
- [C-1-2] אסור לכלול יותר מגזיר אחד בכל קצה.
- [C-1-3] חובה לפעול בהתאם לסימוני המגרעת במסך שהוגדרו על ידי האפליקציה דרך
WindowManager.LayoutParams
API כפי שמתואר ב-SDK. - [C-1-4] חובה לדווח על הערכים הנכונים לכל מדדי המגרעת שמוגדרים
DisplayCutout
API.
3.8.16. ממשק השליטה במכשירים
Android כולל ControlsProviderService
ו-Control
ממשקי API שמאפשרים לאפליקציות של צד שלישי לפרסם פקדי מכשירים
הסטטוס והפעולה עבור המשתמשים.
דרישות ספציפיות למכשיר מופיעות בסעיף 2_2_3.
3.8.17. לוח
הטמעות מכשירים:
- [C-0-1] אסור לשלוח נתונים שבלוח העריכה לשום רכיב, פעילות, שירות או בכל חיבור לרשת, ללא פעולה מפורשת מצד המשתמש (למשל, לחיצה על לחצן בשכבת-העל), מלבד שירותים שמוזכרים ב 9.8.6 תיעוד תוכן וחיפוש באפליקציות.
אם בזמן העתקת התוכן מתבצעת הפעלה של הטמעות המכשירים, והתצוגה המקדימה שלו גלויה למשתמש.
ללוח של כל פריט ClipData
שבו
ClipData.getDescription().getExtras()
מכיל
android.content.extra.IS_SENSITIVE
, הן:
- [C-1-1] חובה לצנזר את התצוגה המקדימה הגלויה למשתמש
הטמעת קובץ העזר של AOSP עומדת בדרישות הבאות לגבי הלוח.
3.9. ניהול המכשיר
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
Android כולל תכונות המאפשרות בקרת אבטחה
אפליקציות הפעלה
אפליקציות בקר של מדיניות המכשיר לביצוע
פונקציות ניהול המכשיר ברמת המערכת, כמו אכיפת סיסמה
או לבצע מחיקה מרחוק, באמצעות
Android Device Administration API
ממשקי API של Device Policy Manager.
- [C-1-1] חובה להצהיר על
android.software.device_admin
. - [C-1-2] חובה לתמוך בהקצאת הרשאות ידנית של בעלי המכשיר כפי שמתואר ב 3.9.1 וגם סעיף 3.9.1.1.
סיום הדרישות החדשות
3.9.1. הקצאת מכשירים
3.9.1.1. ניהול הקצאות של בעלי המכשיר
אם הטמעות המכשירים מצהירות על android.software.device_admin
, הן:
- [C-1-1] חייבת לתמוך ברישום של Device Policy (DPC) בתור
האפליקציה של בעלי המכשיר
כפי שמתואר בהמשך:
- כאשר הטמעת המכשיר כוללת
לא משתמשים ולא
של נתוני המשתמש, הוא:
- [C-1-5] חובה לרשום את אפליקציית DPC כאפליקציה של בעלי המכשיר
או להפעיל את אפליקציית ה-DPC כדי לבחור אם
להפוך לבעלי מכשיר או לבעלים של פרופיל,
אם המכשיר מצהיר על תמיכה בתקשורת מטווח קצר (NFC) דרך
דגל התכונה
android.hardware.nfc
ומקבל הודעת NFC שמכיל רשומה עם סוג MIMEMIME_TYPE_PROVISIONING_NFC
. - [C-1-8] חובה לשלוח את ACTION_GET_PROVISIONING_מצב
Intent אחרי שההקצאה של בעלי המכשיר מופעלת, כך ש
אפליקציית DPC יכולה לבחור אם להפוך לבעלים של המכשיר או לפרופיל
בעלים, בהתאם לערכים של
android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES
, אלא אם ניתן לקבוע לכך שיש רק אפשרות חוקית אחת. - [C-1-9] חייבים לשלוח את ACTION_ADMIN_POLICY_COMPLIANCE כוונה לאפליקציה של בעלי המכשיר אם הוגדר בעל מכשיר במהלך ההקצאה, ללא קשר לשיטת ההקצאה שבה נעשה שימוש. לא תהיה למשתמש אפשרות להמשיך באשף ההגדרה עד האפליקציה של בעלי המכשיר הסתיימה.
- [C-1-5] חובה לרשום את אפליקציית DPC כאפליקציה של בעלי המכשיר
או להפעיל את אפליקציית ה-DPC כדי לבחור אם
להפוך לבעלי מכשיר או לבעלים של פרופיל,
אם המכשיר מצהיר על תמיכה בתקשורת מטווח קצר (NFC) דרך
דגל התכונה
- כאשר הטמעת המכשיר כוללת
משתמשים או
כך:
- [C-1-7] אסור לרשום אפליקציית DPC בתור האפליקציה של בעלי המכשיר עוד.
- כאשר הטמעת המכשיר כוללת
לא משתמשים ולא
של נתוני המשתמש, הוא:
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
[C-1-2] חובה להציג הודעת גילוי נאות הולמת (כמו שמוזכרים ב-AOSP) ולקבל הסכמה מפורשת ממשתמש הקצה לפני הפעלת האפליקציה מוגדר כבעלים של המכשיר, אלא אם המכשיר מוגדר באופן פרוגרמטי למצב הדגמה לקמעונאים לפני האינטראקציה על המסך עם משתמשי הקצה. אם בהטמעות המכשירים מוצהר על
android.software.device_admin
, אבל גם לכלול קניין רוחני פתרון לניהול מכשירים ולספק מנגנון לקדם אפליקציה שהוגדרה בפתרון שלהם בתור 'בעלי המכשיר מקביל" אל 'בעלי המכשיר' הרגיל כפי שמוכר על ידי התקן Android הרגיל DevicePolicyManager ובממשקי API הם:[C-2-1] חובה ליצור תהליך לאימות האפליקציה הספציפית הקידום שייך לניהול מכשירים תקין בארגון והוא הוגדר בפתרון הקנייני להיות בעלי הזכויות המקבילות ל'בעלי המכשיר'.
[C-2-2] חובה להציג את אותו גילוי נאות לגבי הסכמה לבעלי מכשיר ב-AOSP כמו תהליך ביוזמת
android.app.action.PROVISION_MANAGED_DEVICE
לפני רושמים את אפליקציית DPC בתור 'בעלי המכשיר'.[C-2-3] אסור לכתוב בתוך הקוד את ההסכמה או למנוע שימוש באפליקציות אחרות של בעלי המכשיר.
סיום הדרישות החדשות
3.9.1.2. ניהול הקצאות של פרופילים מנוהלים
אם הטמעות המכשירים מצהירות על android.software.managed_users
, הן:
- [C-1-1] חובה להטמיע את ממשקי ה-API מאפשרת לאפליקציה Device Policy Controller (DPC) להפוך ל הבעלים של פרופיל מנוהל חדש.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-1-2] תהליך הקצאת הפרופיל המנוהל (התהליך שהופעל על ידי בקר ה-DPC באמצעות android.app.action.PROVISION_MANAGED_PROFILE) או על ידי הפלטפורמה), מסך ההסכמה וחוויית המשתמש חייבים להתאים בהטמעת ה-AOSP.
סיום הדרישות החדשות
[C-1-3] חייבים לספק בהגדרות את ההרשאות הבאות למשתמשים כדי: לציין למשתמש כאשר פונקציית מערכת מסוימת הושבתה על ידי Device Policy Controller (DPC):
- סמל עקבי או עלות אחרת של המשתמש (לדוגמה, סמל מידע של AOSP) כדי לייצג מקרים שבהם הגדרה מסוימת מוגבלת על ידי אדמין של מכשירים.
- הודעת הסבר קצרה שתישלח מאדמין המכשיר דרך
setShortSupportMessage
- סמל האפליקציה בקר DPC.
[C-1-4] חובה להפעיל את ה-handler של ACTION_PROVISIONING_PROGRESSFUL Intent בפרופיל העבודה אם קיים בעלים של פרופיל כאשר ההקצאה מתבצעת על ידי android.app.action.PROVISION_MANAGED_PROFILE Intent וה-DPC יישם את ה-handler.
[C-1-5] חובה לשלוח ACTION_PROFILE_PROVISIONING_COMPLETE לשדר ל-DPC של פרופיל העבודה כאשר הקצאת ההרשאות מתחילה על ידי android.app.action.PROVISION_MANAGED_PROFILE בכוונה טובה.
[C-1-6] חובה לשלוח את ACTION_GET_PROVISIONING_מצב Intent אחרי שההקצאה של בעלי הפרופיל מופעלת, כך שאפליקציית ה-DPC יכול לבחור אם להפוך לבעלי מכשיר או לבעלים של פרופיל, למעט כאשר הקצאת ההרשאות מופעלת על ידי ה-Intent android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-7] חובה לשלוח את ACTION_ADMIN_POLICY_COMPLIANCE כוונה לפרופיל העבודה כאשר נוצר בעלים של פרופיל במהלך הקצאה ללא קשר לשיטת ההקצאה שבה נעשה שימוש, כשניהול ההקצאות מופעל על ידי ה-Intent android.app.action.PROVISION_MANAGED_PROFILE. למשתמש לא תהיה אפשרות להמשיך באשף ההגדרה עד הפרופיל האפליקציה של הבעלים הסתיימה.
[C-1-8] חובה לשלוח ACTION_MANAGED_PROFILE_PROVISIONED לשדר ל-DPC של הפרופיל האישי כשנוצר בעל פרופיל, ללא קשר לשיטת הקצאת ההרשאות שנבחרה.
3.9.2. תמיכה בפרופילים מנוהלים
אם הטמעות המכשירים מצהירות על android.software.managed_users
, הן:
- [C-1-1] חייבת לתמוך בפרופילים מנוהלים דרך
android.app.admin.DevicePolicyManager
ממשקי API. - [C-1-2] חובה לאפשר יצירה של פרופיל מנוהל אחד בלבד.
- [C-1-3] חובה להשתמש בתג סמל (בדומה לתג העבודה ב-AOSP) כדי לייצג את האפליקציות והווידג'טים המנוהלים ורכיבים אחרים בממשק המשתמש עם תגים כמו 'אחרונים' ו- התראות.
- [C-1-4] חייב להציג סמל התראה (בדומה לפעולת upstream של AOSP כדי לציין מתי המשתמש נמצא באפליקציית פרופיל מנוהל.
- [C-1-5] חייב להציג הודעה קופצת שמציינת שהמשתמש נמצא בחשבון מנוהל פרופיל אם וכאשר המכשיר יתעורר (ACTION_USER_PRESENT) האפליקציה בחזית נמצאת בפרופיל המנוהל.
- [C-1-6] במקומות שבהם קיים פרופיל מנוהל, חייב להיות מציגים תועלת ויזואלית 'בורר' של Intent כדי לאפשר למשתמש להעביר את הכוונה מהחשבון המנוהל למשתמש הראשי או להפך, אם הוא מופעל באמצעות מדיניות המכשיר בקר.
- [C-1-7] במקרים שבהם קיים פרופיל מנוהל, חובה לחשוף את המשתמש הבא
מחירים נוחים גם למשתמש הראשי וגם לפרופיל המנוהל:
- התייחסות נפרדת לשימוש בסוללה, במיקום, בחבילת הגלישה ובנפח האחסון של המשתמש הראשי והפרופיל המנוהל.
- ניהול עצמאי של אפליקציות VPN שמותקנות בתוך האפליקציה הראשית או פרופיל מנוהל.
- ניהול עצמאי של אפליקציות שמותקנות בתוך המשתמש הראשי או פרופיל מנוהל.
- ניהול עצמאי של חשבונות בתוך המשתמש הראשי או בחשבון המנוהל פרופיל.
- [C-1-8] חובה לוודא שהחייגן, אנשי הקשר והודעות הטקסט מותקנים מראש אפליקציות יכולות לחפש ולחפש מידע על מתקשרים (אם קיים) לצד הפרופילים מהפרופיל הראשי, אם המכשיר לבקרת מדיניות המכשירים מתיר זאת.
- [C-1-9] חייב לוודא שהוא עומד בכל דרישות האבטחה רלוונטי למכשיר שבו מופעלים משתמשים מרובים (ראו סעיף 9.5), למרות שהפרופיל המנוהל לא נספר כמשתמש אחר בנוסף למשתמש הראשי.
- [C-1-10] חובה לוודא שהנתונים של צילומי המסך נשמרים בפרופיל העבודה
אחסון, כאשר צילום מסך מצולם באמצעות
topActivity
חלון שבו התמקדות (זו שהמשתמש יצר אינטראקציה איתה לאחרונה בכל הפעילויות) והוא שייך אליה אפליקציה של פרופיל עבודה. - [C-1-11] אסור לצלם תוכן מסך אחר (סרגל מערכת, התראות או כל תוכן אחר של הפרופיל האישי), חוץ מאשר בפרופיל העבודה חלון/חלונות באפליקציה כששומרים צילום מסך בפרופיל העבודה (כדי להבטיח נתוני הפרופיל לא נשמרים בפרופיל העבודה).
אם בהטמעות המכשירים מוצהר על android.software.managed_users
וגם
android.software.secure_lock_screen
, הן:
- [C-2-1] חייבת להיות תמיכה באפשרות לקבוע פגישה נפרדת עם מסך נעילה
בדרישות הבאות כדי להעניק גישה לאפליקציות שפועלות בחשבון מנוהל
פרופיל בלבד.
- יישומים של מכשירים חייבים לפעול בהתאם
DevicePolicyManager.ACTION_SET_NEW_PASSWORD
Intent ומראה ממשק להגדרה של מסך נעילה נפרד פרטי הכניסה של הפרופיל המנוהל. - פרטי הכניסה למסך הנעילה של הפרופיל המנוהל חייבים להיות זהים מנגנוני אחסון וניהול של פרטי כניסה כפרופיל ההורה, כפי שמתועד אתר פרויקט קוד פתוח של Android
- מדיניות הסיסמאות של בקר DPC
חובה להחיל רק על פרטי הכניסה במסך הנעילה של הפרופיל המנוהל, אלא אם
שנקראה למכונה
DevicePolicyManager
שהוחזרה על ידיgetParentProfileInstance
- יישומים של מכשירים חייבים לפעול בהתאם
- כשמוצגים אנשי קשר מהפרופיל המנוהל בממשק המשתמש של השיחה, במהלך השיחה ובשיחות שלא נענו, שהותקן מראש. של הודעות, אנשי קשר ואפליקציות להעברת הודעות, שאותם צריך לתייג אותו תג שמשמש לציון אפליקציות פרופיל מנוהל.
3.9.3. תמיכה במשתמשים מנוהלים
אם הטמעות המכשירים מצהירות על android.software.managed_users
, הן:
- [C-1-1] חייבת להיות למשתמש אפשרות להתנתק מהמשתמש הנוכחי
לחזור למשתמש הראשי בסשן של משתמשים מרובים,
isLogoutEnabled
הפונקציה מחזירהtrue
. המחיר המיועד של המשתמש חייב להיות נגיש ממסך הנעילה בלי לבטל את נעילת המכשיר.
אם בהטמעות המכשירים מוצהר על android.software.device_admin
ומספקים
לאפשר למשתמשים במכשיר להוסיף משתמשים משניים נוספים:
- [C-SR-1] מומלץ מאוד להציג את אותה הסכמה של בעלי מכשיר AOSP גילוי נאות שהוצגו בתהליך הבקשה של android.app.action.PROVISION_MANAGED_DEVICE, לפני שמאפשרים להוסיף חשבונות במשתמש המשני החדש, כדי שהמשתמשים יבינו שהמכשיר מנוהל.
3.9.4. דרישות התפקידים לניהול מדיניות מכשירים
אם על ההטמעה במכשירים מדווחים android.software.device_admin
או
android.software.managed_users
, ואז:
- [C-1-1] חייבת להיות תמיכה בתפקיד 'ניהול מדיניות מכשירים' כפי שמוגדר ב
סעיף 9.1. האפליקציה שמכילה את התפקיד 'ניהול מדיניות המכשיר'
ייתכן שיהיה מוגדר על ידי הגדרה של
config_devicePolicyManagement
כשם החבילה. אחרי שם החבילה חייבים להופיע:
ואישור החתימה, אלא אם האפליקציה נטענת מראש.
אם שם חבילה לא מוגדר עבור config_devicePolicyManagement
כ-
שתוארו למעלה:
- [C-2-1] הטמעות של מכשירים חייבות לתמוך בהקצאת הרשאות ידנית ללא מכשיר בקשה לבעלי תפקיד בניהול מדיניות (AOSP מספק הטמעה של קובצי עזר).
אם שם חבילה מוגדר ל-config_devicePolicyManagement
כפי שמתואר
למעלה:
- [C-3-1] האפליקציה חייבת להיות מותקנת בכל המכשירים פרופילים למשתמש.
- [C-3-2] הטמעות מכשירים עשויות להגדיר אפליקציה שמעדכנת את
בעל תפקיד של ניהול מדיניות מכשיר לפני הקצאה באמצעות הגדרה
config_devicePolicyManagementUpdater
אם שם חבילה מוגדר ל-config_devicePolicyManagementUpdater
כ-
שתוארו למעלה:
- [C-4-1] האפליקציה חייבת להיות מותקנת מראש במכשיר.
- [C-4-2] האפליקציה חייבת להטמיע מסנן Intent שפותר את הבעיה
android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER
3.9.5. מסגרת של רזולוציית מדיניות המכשיר
אם על ההטמעה במכשירים מדווחים android.software.device_admin
או
android.software.managed_users
, ואז:
- [C-1-1] חובה לפתור את ההתנגשויות של מדיניות המכשיר כפי שמתועד ב Device Policy Resolution Framework
3.10. נגישות
ב-Android יש שכבת נגישות שעוזרת למשתמשים עם מוגבלויות לנווט במכשירים שלהם בקלות רבה יותר. בנוסף, Android מספק ממשקי API לפלטפורמה שמאפשרות לאפליקציות של שירותי נגישות לקבל קריאות חוזרות (callback) של משתמשים ואירועי מערכת, וליצור מנגנוני משוב חלופיים, כמו המרת טקסט לדיבור (TTS), משוב פיזי וניווט באמצעות כדור עקיבה/D-pad.
אם הטמעות במכשירים תומכים בשירותי נגישות של צד שלישי:
- [C-1-1] חובה לספק הטמעה של תכונות הנגישות ב-Android כפי שמתואר ממשקי API לנגישות מסמכי תיעוד בנושא SDK.
- [C-1-2] חובה ליצור אירועי נגישות ולספק את האירועים המתאימים
AccessibilityEvent
לכל הרשומותAccessibilityService
והטמעות כפי שמתואר ב-SDK. - [C-1-4] חובה לספק למשתמש מחיר שמאפשר שליטה בנגישות שירותים שמצהירים על AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_button שימו לב שבהטמעות במכשירים עם סרגל ניווט של המערכת, אמורה לאפשר למשתמש אפשרות ללחוץ על הלחצן סרגל ניווט כדי לשלוט בשירותים האלה.
אם הטמעות המכשירים כוללות שירותי נגישות שהותקנו מראש, הן:
- [C-2-1] חובה להטמיע את שירותי הנגישות המותקנים מראש האלה מוּדעוּת להפעלה ישירה אפליקציות כשאחסון הנתונים מוצפן באמצעות הצפנה מבוססת-קבצים (FBE).
- אמור לספק מנגנון בתהליך ההגדרה הראשוני שהמשתמשים יכולים להפעיל. שירותי נגישות רלוונטיים וגם אפשרויות להתאמת גודל הגופן, גודל התצוגה ותנועות הגדלה.
3.11. המרת טקסט לדיבור (TTS)
ב-Android יש ממשקי API שמאפשרים לאפליקציות להשתמש בהמרת טקסט לדיבור (TTS) (TTS) ומאפשרים לספקי שירות לספק יישומים של TTS שירותים שונים.
אם יישומים של מכשירים מדווחים על התכונה android.hardware.audio.output, הם:
- [C-1-1] חייבת לתמוך מסגרת Android TTS ממשקי API.
אם הטמעות המכשיר תומכות בהתקנה של מנועי TTS של צד שלישי, הן:
- [C-2-1] חובה לאפשר למשתמש לבחור טקסט לדיבור לשימוש ברמת המערכת.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
3.12. מסגרת של קלט טלוויזיה
Android Television קלט Framework (TIF) מפשט העברה של תוכן בשידור חי למכשירי Android TV. TIF מספקת API ליצירת מודולים לקלט ששולטים במכשירי Android TV.
אם הטמעות במכשירים תומכים ב-TIF:
- [C-1-1] חובה להצהיר על הפיצ'ר
android.software.live_tv
בפלטפורמה. - [C-1-2] חייבת לתמוך בכל ממשקי ה-API של TIF, כך שאפליקציה שמשתמשת ממשקי ה-API האלה וקלט מבוסס-TIF של צד שלישי ניתן להתקין את השירות ולהשתמש בו במכשיר.
סיום הדרישות החדשות
3.13. הגדרות מהירות
ב-Android יש רכיב בממשק המשתמש של ההגדרות המהירות שמאפשר גישה מהירה אל פעולות נפוצות או פעולות דחופות.
אם ההטמעות במכשירים כוללות רכיב בממשק המשתמש של ההגדרות המהירות ותומכות בצדדים שלישיים בהגדרות המהירות:
- [C-1-1] חובה לאפשר למשתמש להוסיף או להסיר את כרטיסי המידע
quicksettings
ממשקי API מאפליקציה של צד שלישי. - [C-1-2] אסור להוסיף כרטיס מידע באופן אוטומטי מאפליקציה של צד שלישי אל ההגדרות המהירות.
- [C-1-3] חובה להציג את כל המשבצות שנוספו על ידי המשתמשים מאפליקציות של צד שלישי לצד משבצות ההגדרה המהירות שסופקו על ידי המערכת.
3.14. ממשק משתמש של מדיה
אם יישומים של מכשירים כוללים אפליקציות שלא מופעלות באמצעות קול (האפליקציות) שמקיימות אינטראקציה עם
אפליקציות צד שלישי דרך MediaBrowser
או MediaSession
,
האפליקציות:
[C-1-2] חובה להציג בבירור סמלים שהתקבלו באמצעות
getIconBitmap()
אוgetIconUri()
וכותרות שהתקבלו דרךgetTitle()
כפי שמתואר ב-MediaDescription
. יכול להיות שהשם יהיה קצר יותר, כדי לעמוד בתקנות הבטיחות (למשל, הסחות דעת של הנהג).[C-1-3] חובה להציג את סמל האפליקציה של צד שלישי בכל פעם שיוצג תוכן שסופק על ידי באפליקציה הזו של צד שלישי.
[C-1-4] חייבת לאפשר למשתמש לבצע אינטראקציה עם כל התוכן של
MediaBrowser
ההיררכיה. יכול להיות להגביל את הגישה לחלק מההיררכיה כדי לעמוד בתקנות הבטיחות (למשל, הסחות דעת של הנהג), אבל אסור לתת יחס מועדף על סמך תוכן או ספק תוכן.[C-1-5] חייבים לשקול הקשה כפולה של
KEYCODE_HEADSETHOOK
אוKEYCODE_MEDIA_PLAY_PAUSE
בתורKEYCODE_MEDIA_NEXT
עבורMediaSession.Callback#onMediaButtonEvent
.
3.15. אפליקציות ללא התקנה
אם הטמעות במכשירים תומכים באפליקציות ללא התקנה, הן חייבות לעמוד בדרישות הבאות דרישות:
- [C-1-1] אפליקציות ללא התקנה חייבות לקבל רק הרשאות
android:protectionLevel
מוגדר ל-"instant"
. - [C-1-2] אסור שאפליקציות ללא התקנה יקיימו אינטראקציה עם אפליקציות מותקנות באמצעות כוונות מרומזות
אלא אם מתקיים אחד מהתנאים הבאים:
- מסנן דפוס Intent של הרכיב נחשף, ויש לו CATEGORY_BROWSABLE
- הפעולה היא אחת מהאפשרויות: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
- היעד חשוף באופן מפורש באמצעות android:visibleToInstantApps
- [C-1-3] אסור שאפליקציות ללא התקנה יקיימו אינטראקציה מפורשת עם אפליקציות מותקנות, אלא אם הרכיב נחשף דרך android:visibleToInstantApps.
- [C-1-4] אפליקציות מותקנות לא יכולות לראות פרטים על אפליקציות ללא התקנה המכשיר, אלא אם האפליקציה ללא התקנה מתחברת באופן מפורש המותקנת.
הטמעת מכשירים חייבת לספק למשתמשים את העלויות הבאות: אינטראקציה עם אפליקציות ללא התקנה. ה-AOSP עומד בדרישות הבאות ברירת המחדל של ממשק המשתמש, ההגדרות, ומרכז האפליקציות. הטמעות מכשירים:
- [C-1-5] חובה לספק למשתמש תקציב להצגה ומחיקה של אפליקציות ללא התקנה במטמון באופן מקומי לכל חבילת אפליקציה בנפרד.
- [C-1-6] חייבת לספק התראה קבועה למשתמש, שניתן
מכווץ בזמן שאפליקציה ללא התקנה פועלת בחזית. המשתמש הזה
ההתראה חייבת לכלול שאין צורך בהתקנה של אפליקציות ללא התקנה
ולספק למשתמש מחיר מסוים שמפנה את המשתמש לאפליקציה
במסך המידע בהגדרות. לגבי אפליקציות ללא התקנה שהופעלו באמצעות כוונות אינטרנט, למשל
מוגדר באמצעות שימוש ב-Intent עם פעולה שהוגדרה ל-
Intent.ACTION_VIEW
וגם עם סכמה של "http" או "https", עלות נוספת למשתמש אמורה לאפשר למשתמש לא להפעיל את האפליקציה ללא התקנה, להפעיל את הקישור המשויך לדפדפן האינטרנט שהוגדר, אם דפדפן זמינה במכשיר. - [C-1-7] חובה לאפשר גישה לאפליקציות ללא התקנה שפועלות בקטע 'אחרונים' אם הפונקציה 'אחרונים' זמינה במכשיר.
[C-1-8] חובה לטעון מראש אפליקציה או רכיב שירות אחד או יותר עם Intent שמתייחס לאובייקטים של Intent שמפורטים ב-SDK כאן. והפיכת הכוונות לגלויות לאפליקציות ללא התקנה.
3.16. התאמת מכשיר נלווה
מערכת Android כוללת תמיכה בהתאמת מכשירים נלווים כדי לנהל ביעילות רבה יותר
משויך למכשירים נלווים, ומספק את ה-CompanionDeviceManager
ממשק API לאפליקציות כדי לגשת לתכונה הזו.
אם הטמעות המכשירים תומכות בתכונה 'התאמת מכשירים נלווית', הן:
- [C-1-1] חובה להצהיר על דגל התכונה
FEATURE_COMPANION_DEVICE_SETUP
הקצר הזה. התשובות שלך יעזרו לנו להשתפר. - [C-1-2] חייבים לוודא שממשקי ה-API נמצאים ב
android.companion
החבילה מוטמעת במלואה.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-1-3] חובה לספק למשתמש אפשרויות תקציב שמאפשרות לבחור או לאשר שמכשיר נלווה קיים ופעיל, שחייבים להשתמש באותה הודעה שמוטמעת ב-AOSP ללא הוספה או שינוי.
סיום הדרישות החדשות
3.17. אפליקציות כבדות
אם בהטמעות במכשירים מוצהר על התכונה FEATURE_CANT_SAVE_STATE
,
ואז:
- [C-1-1] חייבת להיות רק אפליקציה מותקנת אחת שמציינת
cantSaveState
שפועלים במערכת בכל פעם. אם המשתמש יוצא מאפליקציה כזו בלי לצאת ממנה באופן מפורש (לדוגמה, על ידי לחיצה על בבית בזמן שהמערכת משאירה פעילות פעילה, במקום ללחוץ על 'חזרה' ללא פעילויות פעילות נוספות במערכת), לאחר מכן יישומים של מכשירים חייבים לתת עדיפות לאפליקציה הזו ב-RAM כפי שהיא מופיעה במכשירים אחרים דברים שצפויים להמשיך לפעול, כמו שירותים שפועלים בחזית. גם כשאפליקציה כזו פועלת ברקע, המערכת עדיין יכולה להפעיל חשמל בתכונות הניהול שלו, כמו הגבלת הגישה למעבד (CPU) ולרשת. - [C-1-2] חובה לספק ממשק משתמש נוח לבחירה באפליקציה שלא
להשתמש במנגנון שמירה/שחזור במצב הרגיל ברגע שהמשתמש
מפעילה אפליקציה שנייה שהוצהרה באמצעות
cantSaveState
. - [C-1-3] אסור להחיל שינויים אחרים במדיניות על אפליקציות שמציינות
cantSaveState
למשל, שינוי ביצועי המעבד (CPU) או שינוי העדיפות של התזמון.
אם יישומי מכשירים לא כוללים הצהרה על התכונה
FEATURE_CANT_SAVE_STATE
ואז:
- [C-1-1] חובה להתעלם מה
cantSaveState
שהוגדר על ידי האפליקציות, ואסור לשנות את התנהגות האפליקציה בהתאם .
3.18. אנשי קשר
Android כולל
Contacts Provider
ממשקי API שמאפשרים לאפליקציות לנהל פרטים של אנשי קשר השמורים במכשיר.
נתוני אנשי קשר שמוזנים ישירות למכשיר מסונכרנים בדרך כלל
עם שירות אינטרנט, אבל ייתכן שהנתונים מאוחסנים גם באופן מקומי בלבד במכשיר.
אנשי קשר ששמורים רק במכשיר נקראים מקומיים
אנשי הקשר.
אנשי קשר גולמיים
'משויכים אל' או 'מאוחסנים ב-' ה
חשבון
כאשר
ACCOUNT_NAME
,
וגם
ACCOUNT_TYPE
,
של אנשי הקשר הגולמיים תואמות
Account.name
וגם
סוג החשבון
השדות של החשבון.
חשבון מקומי שמוגדר כברירת מחדל: חשבון של אנשי קשר גולמיים שמאוחסנים רק בו
של המכשיר ולא משויכים לחשבון
מנהל החשבון,
שנוצרים עם ערכי null עבור
ACCOUNT_NAME
,
וגם
ACCOUNT_TYPE
,
עמודות.
חשבון מקומי מותאם אישית: חשבון של אנשי קשר גולמיים שמאוחסנים רק
ולא משויכים לחשבון ב-AccountManager,
נוצר עם ערך אחד לפחות שאינו null עבור הפונקציה
ACCOUNT_NAME
,
וגם
ACCOUNT_TYPE
,
עמודות.
הטמעות מכשירים:
- [C-SR-1] מומלץ מאוד לא ליצור חשבונות מקומיים בהתאמה אישית.
אם בהטמעות במכשירים נעשה שימוש בחשבון מקומי מותאם אישית:
- [C-1-1]
ACCOUNT_NAME
, של החשבון המקומי המותאם אישית חייב להיות מוחזר על ידיContactsContract.RawContacts.getLocalAccountName
- [C-1-2]
ACCOUNT_TYPE
של החשבון המקומי המותאם אישית חייב להיות מוחזר על ידיContactsContract.RawContacts.getLocalAccountType
- [C-1-3] אנשי קשר גולמיים שנוספו על ידי אפליקציות של צד שלישי עם
חשבון מקומי שמוגדר כברירת מחדל (כלומר, על ידי הגדרת ערכי null עבור
ACCOUNT_NAME
ו-ACCOUNT_TYPE
) חייבים להוסיף אל המקומים המותאמים אישית חשבון. - [C-1-4] אנשי קשר גולמיים שנוספו לחשבון המקומי המותאם אישית לא חייבים להיות מוסרים כשמוסיפים או מסירים חשבונות.
- [C-1-5] פעולות מחיקה שבוצעו בחשבון מקומי מותאם אישית
חייבים לגרום לכך שאנשי הקשר הגולמיים יימחקו באופן מיידי (כאילו
CALLER_IS_SYNCADAPTER
הפרמטר הוגדר כ-True, גם אם הפרמטרCALLER\_IS\_SYNCADAPTER
הוגדר ל-false או לא צוין.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
3.19. הגדרות שפה
הטמעות מכשירים:
- [C-0-1] אסור לאפשר למשתמשים לבחור תוכן ספציפי למגדר טיפול בשפה שאינה תומכת במגדר עם תרגומים. לעיון במשאבים דקדוקיים אפשר לקבל מידע נוסף.
סיום הדרישות החדשות
4. תאימות לאריזת אפליקציות
הטמעות של מכשירים:
[C-0-1] חייבת להיות יכולת להתקין ולהפעיל את Android "APK " קבצים בתור שנוצר על ידי ה-aapt שכלול SDK רשמי של Android.
- מאחר שהדרישה שלמעלה עשויה להיות מאתגרת, הטמעת מכשירים מומלץ להשתמש בניהול החבילות של קובץ העזר של AOSP המערכת.
[C-0-2] חייבת להיות תמיכה באימות ' .APK' באמצעות חבילת APK Signature Scheme v3.1 גרסה 3 של חתימת APK, גרסה 2 של חתימת APK וחתימת JAR.
[C-0-3] אסור להאריך .APK, מניפסט ל-Android, Dalvik bytecode, או רינדור פורמטים של בייטקוד (bytecode) באופן שימנע מקבצים כאלה מותקנים ופועלים בצורה תקינה במכשירים תואמים אחרים.
[C-0-4] אסור לאפשר שימוש באפליקציות מלבד האפליקציה הנוכחית 'המתקין הרשום' כדי שהחבילה תסיר את האפליקציה בלי להציג אישור משתמש, כפי שמתועד ב-SDK עבור
DELETE_PACKAGE
הרשאה. החריגים היחידים הם הטיפול באפליקציות של מאמת חבילות מערכת PACKAGE_NEEDS_Authentication כוונת הרכישה והטיפול באפליקציות של מנהל האחסון ACTION_MANAGE_STORAGE בכוונה טובה.[C-0-5] חייבת להיות פעילות שמטפלת
android.settings.MANAGE_UNKNOWN_APP_SOURCES
בכוונה טובה.[C-0-6] אסור להתקין חבילות של אפליקציות ממקורות לא ידועים מקורות, אלא אם האפליקציה שביקשה את ההתקנה עומד בכל הדרישות הבאות:
- חובה להצהיר על
REQUEST_INSTALL_PACKAGES
או להגדיר אתandroid:targetSdkVersion
ל-24 ומטה. - המשתמש חייב לקבל הרשאה להתקין אפליקציות מ- מקורות לא ידועים.
- חובה להצהיר על
צריכה לספק למשתמש אפשרות להעניק/לבטל את ההרשאה להתקין אפליקציות ממקורות לא ידועים לכל אפליקציה, אבל ייתכן שבוחרים להטמיע הפעולה הזו מושבתת ולהחזיר
RESULT_CANCELED
למשךstartActivityForResult()
, אם הטמעת המכשיר לא רוצה לאפשר למשתמשים את האפשרות הזו. עם זאת, גם במקרים כאלו, הן חייבות לציין למשתמש מדוע בחירה באפשרות הזאת.[C-0-7] חייבת להופיע תיבת דו-שיח עם אזהרה עם מחרוזת האזהרה סופק באמצעות ממשק API של המערכת
PackageManager.setHarmfulAppWarning
למשתמש לפני הפעלה של פעילות באפליקציה שסומנה באמצעות אותו API של המערכתPackageManager.setHarmfulAppWarning
, מזיקה.אמורה לספק למשתמש אפשרות לבחור להסיר או להפעיל בתיבת הדו-שיח של האזהרה.
[C-0-8] חובה להטמיע תמיכה במערכת קבצים מצטברת כפי שמתועד כאן.
[C-0-9] חייבת להיות תמיכה באימות קובצי .APK באמצעות APK Signature Scheme v4 וגם APK Signature Scheme v4.1
5. תאימות למולטימדיה
הטמעות מכשירים:
- [C-0-1] חייבת לתמוך בפורמטים של מדיה, מקודדים, מפענחים, סוגי קבצים
ופורמטים של מאגרי תגים שמוגדרים בסעיף 5.1
לכל קודק שהוצהר על ידי
MediaCodecList
. - [C-0-2] חובה להצהיר על תמיכה במקודדים ובמפענחים הזמינים ולדווח עליהם
לאפליקציות צד שלישי
MediaCodecList
- [C-0-3] חייבת להיות אפשרות לפענח את הקוד בצורה נכונה ולהפוך אותו לזמין לצד שלישי
אפליקציות לכל הפורמטים שהוא יכול לקודד. זה כולל את כל ה-Bitstreams
שהמקודדים יוצרים, והפרופילים שמדווחים
CamcorderProfile
הטמעות מכשירים:
- המטרה צריכה להיות זמן אחזור מינימלי של קודק, במילים אחרות,
- אין לצרוך ולאחסן אגי נתונים זמניים של קלט ולהחזיר רק מאגרי נתונים זמניים לאחר עיבוד.
- אין להחזיק במאגרי נתונים מפוענחים למשך זמן ארוך יותר מכפי שצוין על ידי (למשל, SPS).
- אסור להחזיק במאגרי נתונים מקודדים למשך זמן ארוך יותר מהנדרש על ידי ה-GOP שלנו.
כל רכיבי הקודק שמפורטים בקטע שבהמשך מסופקים כתוכנה בהטמעה המועדפת של Android מ-Android Open פרויקט מקור.
לתשומת ליבך, Google ו-Open Handset Alliance לא מבצעים הצהרה כי רכיבי הקודק האלה נטולי פטנטים של צד שלישי. האלה מומלץ להשתמש בקוד המקור הזה במוצרי חומרה או תוכנה בהטמעות של הקוד הזה, כולל בתוכנות קוד פתוח, תוכנת שיתוף, עשויה לחייב רישיונות פטנטים מבעלי הפטנטים הרלוונטיים.
5.1. רכיבי קודק של מדיה
5.1.1. קידוד אודיו
לפרטים נוספים קראו את הקטע 5.1.3. פרטי רכיבי הקודק של האודיו.
אם בהטמעות המכשירים מוצהר על android.hardware.microphone
,
הם חייבים לתמוך בקידוד של פורמטי האודיו הבאים ולהפוך אותם לזמינים
לאפליקציות צד שלישי:
- [C-1-1] PCM/WAVE
- [C-1-2] קובץ FLAC
- [C-1-3] אופוס
כל מקודדי האודיו חייבים לתמוך:
- [C-3-1] הזמנת פריימים של אודיו בבייט מקורי של 16 ביט PCM דרך
android.media.MediaCodec
API.
5.1.2. פענוח הקוד של האודיו
לפרטים נוספים קראו את הקטע 5.1.3. פרטי רכיבי הקודק של האודיו.
אם בהטמעות המכשירים מוצהר על תמיכה
android.hardware.audio.output
, חייבת לתמוך בפענוח
בפורמטים הבאים של אודיו:
- [C-1-1] פרופיל MPEG-4 AAC (AAC LC)
- [C-1-2] פרופיל MPEG-4 HE AAC (AAC+ )
- [C-1-3] פרופיל MPEG-4 HE AACv2 (משופר עבור AAC+ )
- [C-1-4] AAC ELD (AAC מושהה עם השהיה נמוכה)
- [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, כולל פרופיל הבסיס של USAC והטווח הדינמי של ISO/IEC 23003-4 פרופיל בקרה)
- [C-1-5] קובץ FLAC
- [C-1-6] MP3
- [C-1-7] MIDI
- [C-1-8] ורביס
- [C-1-9] PCM/WAVE כולל אודיו ברזולוציה גבוהה פורמטים של עד 24 ביט, תדירות דגימה של 192 kHz ו-8 ערוצים. שימו לב שהדרישה הזו מיועדת לפענוח בלבד, ושמכשיר מותר לבצע הפחתת דגימה ו החלשת מיקסים במהלך שלב ההפעלה.
- [C-1-10] אופוס
אם יישומי המכשיר תומכים בפענוח של מאגרי קלט מסוג AAC
סטרימינג מרובה-ערוצים (כלומר יותר משני ערוצים) ל-PCM דרך ברירת המחדל
במפענח אודיו AAC ב-API android.media.MediaCodec
, הקוד הבא חייב להיות
נתמך:
- [C-2-1] חובה לבצע פענוח קוד ללא הפחתת מיקס (לדוגמה: AAC 5.0 יש לפענח זרם לחמישה ערוצים של PCM, זרם AAC מסוג 5.1 חייב להיות מפוענח לשישה ערוצים של PCM).
- [C-2-2] המטא-נתונים של טווח דינמי חייבים להיות מוגדרים כפי שמוגדר ב'בקרת טווח דינמי'
(הרפובליקה הדמוקרטית של קונגו)" ב-ISO/IEC 14496-3, ומפתחות ה-DRC של
android.media.MediaFormat
כדי להגדיר את ההתנהגות של מפענח האודיו עם הטווח הדינמי. מפתחות AAC DRC הושקו ב-API 21 והם:KEY_AAC_DRC_ATTENUATION_FACTOR
,KEY_AAC_DRC_BOOST_FACTOR
KEY_AAC_DRC_HEAVY_COMPRESSION
,KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
וגםKEY_AAC_ENCODED_TARGET_LEVEL
- [C-SR-1] מומלץ מאוד שהדרישות C-2-1 ו-C-2-2 שמפורטות למעלה יהיו כל מפענחי האודיו מסוג AAC עומדים בדרישות.
בעת פענוח אודיו של USAC, MPEG-D (ISO/IEC 23003-4):
- [C-3-1] חובה לפרש ולהחיל מטא-נתונים של עוצמת קול וה-DRC בהתאם ל-MPEG-D DRC Dynamic Range Control Profile Level 1.
- [C-3-2] המפענח חייב להתנהג בהתאם להגדרות
מוגדר באמצעות המקשים
android.media.MediaFormat
הבאים:KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
וגםKEY_AAC_DRC_EFFECT_TYPE
מפענחי פרופיל MPEG-4 AAC, HE AAC ו-HE AACv2:
- עשויה לתמוך בעוצמה ובשליטה בטווח דינמי באמצעות ISO/IEC 23003-4 פרופיל של בקרת טווח דינמי.
אם תקן ISO/IEC 23003-4 נתמך ואם גם ISO/IEC 23003-4 וגם מטא-נתונים של ISO/IEC 14496-3 נמצאים ב-bitstream מפוענח, ואז:
- המטא-נתונים של ISO/IEC 23003-4 יקבלו עדיפות.
כל מפענחי האודיו חייבים לתמוך בפלט:
- [C-6-1] הזמנת פריימים של אודיו בבייט מקורי של 16 ביט PCM דרך
android.media.MediaCodec
API.
אם יישומי המכשיר תומכים בפענוח של מאגרי קלט מסוג AAC
סטרימינג מרובה-ערוצים (כלומר יותר משני ערוצים) ל-PCM דרך ברירת המחדל
מפענח אודיו AAC ב-API android.media.MediaCodec
, אז הקוד הבא חייב להיות
שבהן יש תמיכה:
- [C-7-1] האפליקציה חייבת להיות מוגדרת באמצעות פונקציית הפענוח
עם המפתח
KEY_MAX_OUTPUT_CHANNEL_COUNT
כדי לקבוע אם התוכן יעבור רמיקס לסטריאו (כשמשתמשים בערך של 2) או מתקבל באמצעות מספר הערוצים המקורי (בעת שימוש בערך שווה או גדול ממספר זה). לדוגמה, ערך של 6 ומעלה יגדיר ממפענח, שמפיק פלט של 6 ערוצים כשמזינים תוכן 5.1. - [C-7-2] במהלך הפענוח, המפענח חייב לפרסם את מסיכת הערוץ
בפורמט הפלט עם הפונקציה
KEY_CHANNEL_MASK
מקש, באמצעות הקבועיםandroid.media.AudioFormat
(לדוגמה:CHANNEL_OUT_5POINT1
).
אם בהטמעות של המכשיר יש תמיכה במפענחי אודיו שאינם ה-AAC שמוגדר כברירת מחדל ומסוגל להפיק פלט של אודיו מרובה-ערוצים (כלומר 2 ערוצים) כשמזינים תוכן דחוס בערוצים מרובים, ואז:
- [C-SR-2] מומלץ מאוד להגדיר את המפענח
באמצעות הפענוח באמצעות המפתח
KEY_MAX_OUTPUT_CHANNEL_COUNT
כדי לקבוע אם התוכן יעבור רמיקס לסטריאו (כשמשתמשים בערך של 2) או מתקבל באמצעות מספר הערוצים המקורי (בעת שימוש בערך שווה או גדול ממספר זה). לדוגמה, ערך של 6 ומעלה יגדיר ממפענח, שמפיק פלט של 6 ערוצים כשמזינים תוכן 5.1. - [C-SR-3] בזמן הפענוח מומלץ מאוד למפענח לפרסם
נעשה שימוש במסכת ערוצים בפורמט הפלט עם הפונקציה
KEY_CHANNEL_MASK
מקש, באמצעות קבועים של android.media.AudioFormat (לדוגמה:CHANNEL_OUT_5POINT1
).
5.1.3. פרטי רכיבי הקודק של האודיו
פורמט/קודק | פרטים | סוגי קבצים/פורמטים של קונטיינרים שנתמכים |
---|---|---|
MPEG-4 AAC פרופיל (AAC LC) |
תמיכה בתוכן מונו/סטריאו/5.0/5.1 לפי תקן תדירות הדגימה של 8 עד 48kHz. |
|
MPEG-4 HE AAC Profile (AAC+) | תמיכה בתוכן מונו/סטריאו/5.0/5.1 לפי תקן תדירות הדגימה של 16 עד 48kHz. |
|
MPEG-4 HE AACv2 פרופיל (AAC+ משופר) |
תמיכה בתוכן מונו/סטריאו/5.0/5.1 לפי תקן תדירות הדגימה של 16 עד 48kHz. |
|
AAC ELD (יעזור עם השהיה נמוכה של AAC) | תמיכה בתוכן מונו/סטריאו עם קצב דגימה רגיל מ-16 עד 48 קילו-הרץ. |
|
USAC | תמיכה בתוכן מונו/סטריאו עם קצב דגימה רגיל החל מ-7.35 עד 48kHz. | MPEG-4 (.mp4, .m4a) |
AMR-NB | 4.75 עד 12.2 kbps נדגם ב- 8 kHz | 3GPP (.3gp) |
AMR-WB | 9 קצבים מ-6.60 קילו-ביט לשנייה עד 23.85 קילו-ביט לשנייה שנדגמו ב-16 קילו-הרץ, כפי שמוגדר ב- AMR-WB, Adaptive Multi-Rate – קודק דיבור בפס רחב | 3GPP (.3gp) |
FLAC | גם במקודד וגם במפענח: מצבי מונו וסטריאו לפחות חייבים להיות נתמך. חייבים לתמוך בתהליכי דגימה של עד 192 kHz. 16 סיביות ו-24 סיביות חייבת להיות תמיכה ברזולוציה הזו. הטיפול בנתוני אודיו של FLAC 24 ביט חייב להיות זמין עם הגדרת אודיו מנקודה צפה (floating-point). |
|
MP3 | מונו/סטריאו 8-320Kbps קבוע (CBR) או קצב העברת נתונים משתנה (VBR) |
|
MIDI | MIDI סוג 0 ו-1. DLS גרסה 1 ו-2. XMF ו-Mobile XMF. תמיכה עבור פורמטים של רינגטונים RTTTL/RTX, OTA ו-iMelody |
|
וורביס | פענוח: תמיכה בתוכן מונו, סטריאו, 5.0 ו-5.1 עם דגימה
8,000, 12,000, 16,000, 24,000 ו-48,000 Hz. קידוד: תמיכה בתוכן מונו וסטריאו עם קצב דגימה של 8,000, 12,000, 16,000, 24,000 ו-48,000 Hz |
|
PCM/גל | קודק ה-PCM חייב לתמוך ב-PCM ליניארי של 16 ביט ובציפה (float) של 16 ביט. גל המחלץ צריך לתמוך ב-PCM ליניארי של 32 ביט, 24 ביט, 32 ביט וצפים של 32 ביט (עד למגבלת החומרה). חובה לספק תמיכה לשיעורי דגימה מתוך 8kHz עד 192kHz. | WAVE (.wav) |
Opus | פענוח: תמיכה בתוכן מונו, סטריאו, 5.0 ו-5.1
עם תדירות דגימה של 8,000, 12,000, 16,000, 24,000 ו-48,000 Hz.
קידוד: תמיכה בתוכן מונו וסטריאו עם תדירות דגימה של 8,000, 12,000, 16,000, 24,000 ו-48,000 Hz. |
|
5.1.4. קידוד התמונה
לפרטים נוספים קראו את המאמר 5.1.6. פרטי קודק התמונה.
הטמעת מכשירים חייבת לתמוך בקידוד של קידוד התמונות הבא:
- [C-0-1] JPEG
- [C-0-2] PNG
- [C-0-3] WebP
- [C-0-4] AVIF
- המכשירים חייבים לתמוך ב-
BITRATE_MODE_CQ
ובפרופיל Baseline.
- המכשירים חייבים לתמוך ב-
אם בהטמעות במכשירים יש תמיכה בקידוד HEIC באמצעות android.media.MediaCodec
לסוג המדיה MIMETYPE_IMAGE_ANDROID_HEIC
,
הם:
- [C-1-1] חייב לספק קודק מקודד HEVC עם שיפור חומרה,
תומך
BITRATE_MODE_CQ
במצב השליטה בקצב העברת נתונים,HEVCProfileMainStill
וגודל מסגרת של 512 x 512 פיקסלים.
5.1.5. פענוח הקוד של התמונה
לפרטים נוספים קראו את המאמר 5.1.6. פרטי קודק התמונה.
הטמעות של מכשירים חייבות לתמוך בפענוח קידוד התמונה הבא:
- [C-0-1] JPEG
- [C-0-2] GIF
- [C-0-3] PNG
- [C-0-4] BMP
- [C-0-5] WebP
- [C-0-6] גולמי
- [C-0-7] AVIF (פרופיל בסיס)
אם ההטמעות במכשירים תומכים בפענוח וידאו באמצעות HEVC, המכשירים האלה:
- [C-1-1] חייבת להיות תמיכה בפענוח תמונה בקידוד HEIF (HEIC).
מפענחי תמונות שתומכים בפורמט בעומק ביט גבוה (9 ביט לכל ערוץ):
- [C-2-1] חייבת לתמוך בפלט בפורמט שווה ערך של 8 ביט אם התבקש על ידי
באפליקציה, לדוגמה, דרך
ARGB_8888
הגדרה שלandroid.graphics.Bitmap
.
5.1.6. פרטי קודק התמונה
פורמט/קודק | פרטים | סוגי קבצים נתמכים/פורמטים נתמכים של קונטיינרים |
---|---|---|
JPEG | בסיס+מתקדם | JPEG (.jpg) |
GIF | GIF (.gif) | |
PNG | PNG (.png) | |
BMP | BMP (.bmp) | |
WebP | WebP (.webp) | |
גולמי | ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw) | |
HEIF | תמונה, אוסף תמונות, רצף תמונות | HEIF (.heif), HEIC (.heic) |
AVIF (פרופיל בסיס) | תמונה, אוסף תמונות, פרופיל בסיס של רצף תמונות | מאגר HEIF (.avif) |
מקודדים ומפענחים של תמונות שנחשפים דרך MediaCodec API
[C-1-1] חייב לתמוך ב-YUV420 בצבע גמיש 8:8:8 פורמט (
COLOR_FormatYUV420Flexible
) עדCodecCapabilities
.[C-SR-1] מומלץ מאוד לתמוך בפורמט הצבעים RGB888 למשטח הקלט במצב תצוגה.
[C-1-3] חייבת לתמוך לפחות באחד מישוריים או חצי-מישוריים פורמט צבעים של YUV420 8:8:8:
COLOR_FormatYUV420PackedPlanar
(מקביל ל-COLOR_FormatYUV420Planar
) אוCOLOR_FormatYUV420PackedSemiPlanar
(שווה ערך אלCOLOR_FormatYUV420SemiPlanar
). מומלץ מאוד לתמוך בהם ובשניהם.
5.1.7. רכיבי קודק של וידאו
- לאיכות מקובלת של וידאו בסטרימינג ולווידאו באינטרנט שירותים, יישומים של מכשירים צריכים להשתמש בקודק חומרה VP8 שעומד הדרישות.
אם ההטמעות במכשיר כוללות מקודד או מפענח וידאו:
[C-1-1] רכיבי קודק הווידאו חייבים לתמוך בגודלי בייט הזמני של קלט ופלט להכיל את המסגרת הדחוסה והלא דחוסה הגדולה ביותר האפשרית, כפי שנקבע לפי הסטנדרטי והתצורה, אבל גם לא באופן כללי.
[C-1-2] מקודדים ומפענחי וידאו חייבים לתמוך ב-YUV420 בצבע גמיש 8:8:8 פורמטים (
COLOR_FormatYUV420Flexible
) עדCodecCapabilities
.[C-1-3] מקודדים ומפענחי וידאו חייבים לתמוך לפחות באחד פורמט צבעים חצי-מישור YUV420 8:8:8:
COLOR_FormatYUV420PackedPlanar
(שווה ערך ל-COLOR_FormatYUV420Planar
) אוCOLOR_FormatYUV420PackedSemiPlanar
(שווה ערך ל-COLOR_FormatYUV420SemiPlanar
). אנחנו ממליצים מאוד שתומכים בשניהם.[C-SR-1] מומלץ מאוד לתמוך במקודדים ובמפענחים של וידאו לפחות אחד ממישורים או ממישורים חצי-מישוריים שעברו אופטימיזציה לחומרה YUV420 ביחס 8:8:8 (YV12, NV12, NV21 או פורמט דומה שעבר אופטימיזציה על ידי הספק).
[C-1-5] מפענחי וידאו שתומכים בפורמט בעומק ביט גבוה (יותר מ-9 ביט לכל ערוץ) חייב לתמוך בפלט בפורמט שווה ערך של 8 ביט אם שנדרשת על ידי האפליקציה. חייבים לשקף זאת באמצעות תמיכה פורמט צבע YUV420 8:8:8 דרך
android.media.MediaCodecInfo
.
אם הטמעתם את המכשיר כדי לפרסם תמיכה בפרופיל HDR באמצעות
Display.HdrCapabilities
,
הם:
- [C-2-1] חייב לתמוך בניתוח ובטיפול של מטא-נתונים סטטיים ב-HDR.
אם יישומי מכשירים מפרסמות תמיכה ברענון פנימי דרך
FEATURE_IntraRefresh
ב-MediaCodecInfo.CodecCapabilities
בכיתה, הם:
- [C-3-1] חייבת לתמוך בתקופות הרענון בטווח של 10-60 פריימים לפעול באופן מדויק במשך 20% מתקופת הרענון שהוגדרה.
אלא אם צוין אחרת באפליקציה באמצעות המאפיין KEY_COLOR_FORMAT
מפתח פורמט, הטמעות של מפענח וידאו:
- [C-4-1] ברירת המחדל של פורמט הצבע חייבת להיות מותאמת לתצוגת חומרה אם הוגדר באמצעות פלט משטח.
- [C-4-2] ברירת המחדל של פורמט הצבעים YUV420 8:8:8 צריכה להיות מותאמת למעבד (CPU) קריאה, אם הוגדר שלא להשתמש בפלט Surface.
5.1.8. רשימת רכיבי קודק של וידאו
פורמט/קודק | פרטים | סוגי קבצים/פורמטים של קונטיינרים שנתמכים |
---|---|---|
H.263 |
|
|
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 פרויקט קוד פתוח (אם הוא זמין) לכל פורמט וסוג של מדיה (במקודד או במפענח) שנתמך על ידי המכשיר.
- [C-2-2] רכיבי קודק שהשמות שלהם מתחילים ב-'OMX.google'. חייבת להתבסס על בקוד המקור של פרויקט הקוד הפתוח של Android.
- [C-SR-2] מומלץ מאוד שקודקים של תוכנת OMX יפעלו בקודק שאין לו גישה למנהלי התקנים לחומרה אחרים מלבד ממפי זיכרון.
אם הטמעות במכשירים תומכים ב-Codec 2.0 API:
- [C-3-1] חייב לכלול את קודק התוכנה המתאים מסוג Codec 2.0 מ פרויקט קוד פתוח של Android (אם הוא זמין) לכל פורמט וסוג של מדיה (במקודד או במפענח) שנתמך על ידי המכשיר.
- [C-3-2] חייב לכלול את קודקי התוכנה Codec 2.0 בקודק התוכנה כפי שסופק בפרויקט הקוד הפתוח של Android, כדי לאפשר כדי להעניק גישה צרה יותר לקודקי תוכנה.
- [C-3-3] רכיבי קודק שהשמות שלהם מתחילים ב-c2.android. חייבת להתבסס על בקוד המקור של פרויקט הקוד הפתוח של Android.
5.1.10. אפיון של קודק מדיה
אם הטמעות במכשירים תומכים ברכיבי קודק של מדיה:
- [C-1-1] חייב להחזיר את הערכים הנכונים של אפיון קודק המדיה באמצעות
MediaCodecInfo
API.
ובפרט:
- [C-1-2] רכיבי קודק שהשמות שלהם מתחילים ב-'OMX'. חייבים להשתמש בממשקי API של OMX הם בעלי שמות שתואמים להנחיות למתן שמות ל-OMX IL.
- [C-1-3] רכיבי קודק שהשמות שלהם מתחילים ב-'c2'. חייבים להשתמש ב-Codec 2.0 API כוללים שמות שתואמים להנחיות למתן שמות של Codec 2.0 ב-Android.
- [C-1-4] רכיבי קודק שהשמות שלהם מתחילים ב-'OMX.google'. או 'c2.android'. חובה לא להיות מוגדר כספק או עם שיפור מהירות באמצעות חומרה.
- [C-1-5] רכיבי קודק שפועלים בתהליך קודק (ספק או מערכת) גישה למנהלי התקנים של חומרה אחרים מלבד הקצאת זיכרון וממפות להיות מאופיינים כתוכנה בלבד.
- [C-1-6] רכיבי קודק שלא קיימים בפרויקט הקוד הפתוח של Android או שאינם מבוססים בקוד המקור שבפרויקט הזה חייב להיות מוגדר כספק.
- [C-1-7] רכיבי קודק שמשתמשים בהאצת חומרה חייבים להיות מאפיינים לשיפור המהירות באמצעות חומרה.
- [C-1-8] שמות של רכיבי קוד לא יכולים להיות מטעים. לדוגמה, קודקים שנקראים 'מפענחים' חייבים לתמוך בפענוח קוד, ובמקודדים שנקראים 'מקודדים' חייבת להיות תמיכה באמצעות הקידוד. רכיבי קודק עם שמות שמכילים פורמטים של מדיה חייבים לתמוך באלה פורמטים.
אם הטמעות המכשיר תומכות ברכיבי קודק וידאו:
- [C-2-1] כל רכיבי קודק הווידאו חייבים לפרסם נתונים על קצב פריימים שניתן להשיג בגדלים הבאים, אם הקודק תומך בהם:
SD (איכות נמוכה) | SD (איכות גבוהה) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
רזולוציית וידאו |
|
|
|
1920 x 1080 פיקסלים (חוץ מ-MPEG4, AV1) | 3840 x 2160 פיקסלים (HEVC, VP9, AV1) |
- [C-2-2] רכיבי קודק של וידאו שמאופיינים כהאצת חומרה חייבים
לפרסם מידע על נקודות ביצועים. כל אחת מהרשימות חייבת להיות נתמכת
נקודות ביצועים רגילות (מפורטות ב:
PerformancePoint
API), אלא אם הם כלולים בנקודת ביצועים רגילה אחרת שנתמכת. - בנוסף, הם היו צריכים לפרסם נקודות ביצועים מורחבות אם הם לתמוך בביצועי וידאו עקביים בהשוואה לביצועים הרגילים שצוינו.
5.2. קידוד וידאו
אם ההטמעות במכשירים תומכים במקודד וידאו כלשהו והופכים אותו לזמין
אפליקציות צד שלישי, ולהגדיר את
MediaFormat.KEY_BITRATE_MODE
עד
BITRATE_MODE_VBR
כך שהמקודד יפעל במצב קצב העברת נתונים משתנה, ואז,
כל עוד הוא לא משפיע על הסף המינימלי לאיכות,
את קצב העברת הנתונים המקודד :
- זה לא אמור להיות, יותר מ-1 חלון הזזה, מעל 15% מקצב העברת הנתונים בין פנים בתוך המסגרת (I-frame) במרווחים.
- לא יכול להיות יותר מ- 100% יותר מקצב העברת הנתונים בחלון הזזה של שנייה אחת.
אם ההטמעות במכשירים תומכים במקודד וידאו כלשהו והופכים אותו לזמין
אפליקציות צד שלישי ולהגדיר
MediaFormat.KEY_BITRATE_MODE
עד
BITRATE_MODE_CBR
כך שהמקודד פועל במצב קצב העברת נתונים קבוע, ואז קצב העברת הנתונים המקודד:
- [C-SR-2] מומלץ מאוד לא יותר מ-15% מקצב העברת הנתונים של יעד ההמרה בחלון הזזה של שנייה אחת.
אם יישומי המכשיר כוללים תצוגת מסך מוטמע עם
אורך אלכסון של 2.5 אינץ' לפחות, או כולל יציאת פלט וידאו או
להצהיר על תמיכה במצלמה דרך android.hardware.camera.any
דגל תכונה, הם:
- [C-1-1] חייבת לכלול תמיכה בסרטון אחד לפחות בפורמט VP8 או H.264 והופכים אותו לזמין לאפליקציות של צד שלישי.
- צריכה לתמוך גם במקודדי הווידאו VP8 וגם H.264 ולהפוך אותם לזמינים לאפליקציות של צד שלישי.
אם הטמעות המכשיר תומכות בסרטון H.264, VP8, VP9 או HEVC והופכים אותו לזמין לאפליקציות של צד שלישי, הם:
- [C-2-1] חייבת להיות תמיכה בקצבי העברת נתונים שניתנים להגדרה באופן דינמי.
- אמור לתמוך בקצבי פריימים משתנים, כאשר מקודד הווידאו אמור לקבוע משך הפריימים המיידי, על סמך חותמות הזמן של מאגרי קלט, להקצות את קטגוריית הביט שלה על סמך משך הפריים הזה.
אם בהטמעות המכשיר תומכים במקודד הווידאו MPEG-4 SP לאפליקציות צד שלישי הן:
- המקודד הנתמך צריך לתמוך בקצבי העברת נתונים שאפשר להגדיר באופן דינמי.
אם הטמעות המכשירים מספקות מקודדי וידאו או תמונות עם שיפור מהירות באמצעות חומרה,
והן תומכות במצלמת חומרה אחת או יותר שמחוברת או מתנתקת דרך
ממשקי ה-API של android.camera
:
- [C-4-1] כל מקודדי הווידאו והתמונה עם שיפור מהירות באמצעות חומרה חייבים לתמוך לקידוד פריימים ממצלמות החומרה.
- צריכה לתמוך בקידוד פריימים ממצלמות החומרה דרך כל הווידאו או מקודדי תמונות.
אם הטמעות המכשיר מספקות קידוד HDR:
- [C-SR-1] מומלץ מאוד לספק פלאגין ממשק API להמרת קידוד חלקה להמרה מפורמט HDR לפורמט SDR.
5.2.1. H.263
אם בהטמעות של מכשירים יש תמיכה במקודדי H.263 והפיכתם לזמינים לאפליקציות צד שלישי, הן:
- [C-1-1] חייבת להיות תמיכה ברזולוציית QCIF (176 x 144) באמצעות פרופיל בסיסי ברמה 45. רזולוציית SQCIF היא אופציונלית.
5.2.2. H.264
אם בהטמעות במכשירים יש תמיכה בקודק H.264:
- [C-1-1] חייבת לתמוך ב-Baseline Profile Level 3. עם זאת, תמיכה ב-ASO (הזמנת פרוסה שרירותית), FMO (גמישה) סדר Macroblock) ו-RS (פרוסות מיותרות) הוא אופציונלי. יתרה על כך, על תאימות למכשירי Android אחרים, מומלץ המקודדים לא משתמשים ב-ASO, ב-FMO וב-RS ליצירת פרופיל Baseline.
- [C-1-2] חייבת לתמוך בפרופילי קידוד וידאו באיכות SD (Standard Definition) בטבלה הבאה.
- צריכה לתמוך ברמה 4 של הפרופיל הראשי.
- צריכה לתמוך בפרופילי קידוד וידאו HD (איכות HD) בתור כפי שמצוין בטבלה הבאה.
אם בהטמעות במכשירים מדווחים על תמיכה בקידוד H.264 לרזולוציה של 720p או 1080p סרטונים ברזולוציה גבוהה באמצעות ממשקי ה-API של המדיה, הם:
- [C-2-1] חייבת לתמוך בפרופילי הקידוד שבטבלה הבאה.
SD (איכות נמוכה) | SD (איכות גבוהה) | HD 720p | HD 1080p | |
---|---|---|---|---|
רזולוציית וידאו | 240 x 320 פיקסלים | 720 x 480 פיקסלים | 720 x 1280 פיקסלים | 1920 x 1080 פיקסלים |
קצב הפריימים של הסרטון | 20 fps | 30 fps | 30 fps | 30 fps |
קצב העברת נתונים של וידאו | 384 Kbps | 2 Mbps | 4Mbps | 10Mbps |
5.2.3. VP8
אם הטמעות במכשירים תומכים בקודק VP8:
- [C-1-1] חייבת לתמוך בפרופילים של קידוד וידאו באיכות SD.
- צריכה לתמוך בפרופילים הבאים של קידוד וידאו באיכות HD (איכות גבוהה).
- [C-1-2] חייבת להיות תמיכה בכתיבת קובצי Matroska WebM.
- אמור לספק קודק חומרה VP8 שעומד דרישות קידוד חומרה של פרויקט RTC, כדי להבטיח איכות סבירה של שירותי סטרימינג של וידאו באינטרנט ושירותי שיחות ועידה בווידאו.
אם יישומים של מכשירים ניידים מדווחים על תמיכה בקידוד VP8 ל-720p או 1080p סרטונים ברזולוציה גבוהה באמצעות ממשקי ה-API של המדיה, הם:
- [C-2-1] חייבת לתמוך בפרופילי הקידוד שבטבלה הבאה.
SD (איכות נמוכה) | SD (איכות גבוהה) | HD 720p | HD 1080p | |
---|---|---|---|---|
רזולוציית וידאו | 180 x 320 פיקסלים | 640 x 360 פיקסלים | 720 x 1280 פיקסלים | 1920 x 1080 פיקסלים |
קצב הפריימים של הסרטון | 30 fps | 30 fps | 30 fps | 30 fps |
קצב העברת נתונים של וידאו | 800 Kbps | 2 Mbps | 4Mbps | 10Mbps |
5.2.4. VP9
אם בהטמעות במכשירים יש תמיכה בקודק VP9:
- [C-1-2] חייבת לתמוך בפרופיל 0 ברמה 3.
- [C-1-1] חייבת להיות תמיכה בכתיבת קובצי Matroska WebM.
- [C-1-3] חייבים ליצור נתוני CodecPrivate ואז
- הנתונים אמורים לתמוך בפרופילים של פענוח HD, כפי שמתואר בטבלה הבאה.
- [C-SR-1] מומלץ מאוד לתמוך בפרופילים של פענוח HD כפי שמצוין בטבלה הבאה, אם יש מקודד חומרה.
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
רזולוציית וידאו | 720 x 480 פיקסלים | 720 x 1280 פיקסלים | 1920 x 1080 פיקסלים | 3840 x 2160 פיקסלים |
קצב הפריימים של הסרטון | 30 fps | 30 fps | 30 fps | 30 fps |
קצב העברת נתונים של וידאו | 1.6 Mbps | 4Mbps | 5 Mbps | 20 Mbps |
אם בהטמעות של המכשיר נטען שהוא תומך בפרופיל 2 או בפרופיל 3 דרך ממשקי API של מדיה:
- תמיכה בפורמט 12 ביט היא אופציונלית.
5.2.5. H.265
אם בהטמעות במכשירים יש תמיכה בקודק H.265:
- [C-1-1] חובה לתמוך בפרופיל הראשי ברמה 3 עד רזולוציה של 512 x 512.
- [C-SR-1] מומלץ מאוד לתמוך פרופיל SD בגודל 720 x 480 פרופילי קידוד HD כפי שמצוין בטבלה הבאה, אם יש במקודד חומרה.
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
רזולוציית וידאו | 720 x 480 פיקסלים | 720 x 1280 פיקסלים | 1920 x 1080 פיקסלים | 3840 x 2160 פיקסלים |
קצב הפריימים של הסרטון | 30 fps | 30 fps | 30 fps | 30 fps |
קצב העברת נתונים של וידאו | 1.6 Mbps | 4Mbps | 5 Mbps | 20 Mbps |
5.2.6. AV1
אם בהטמעות במכשירים יש תמיכה בקודק AV1:
- [C-1-1] חייבת לתמוך בפרופיל הראשי, כולל תוכן של 8 ביט ו-10 ביט.
[C-1-2] חובה לפרסם נתוני ביצועים, כלומר לדווח על נתוני הביצועים באמצעות
getSupportedFrameRatesFor()
אוgetSupportedPerformancePoints()
ממשקי API לרזולוציות נתמכות בטבלה שבהמשך.[C-1-3] חובה לקבל מטא-נתונים של HDR ופלט אותם ב-bitstream
אם המקודד AV1 מואץ באמצעות חומרה, הוא:
- [C-2-1] חייבת לתמוך בפרופיל קידוד HD1080p לכל היותר, כולל בטבלה הבאה:
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
רזולוציית וידאו | 720 x 480 פיקסלים | 720 x 1280 פיקסלים | 1920 x 1080 פיקסלים | 3840 x 2160 פיקסלים |
קצב הפריימים של הסרטון | 30 fps | 30 fps | 30 fps | 30 fps |
קצב העברת נתונים של וידאו | 5 Mbps | 8Mbps | 16Mbps | 50 Mbps |
5.3. פענוח הקוד של הווידאו
אם בהטמעות במכשירים תומכים בקודקים מסוג VP8, VP9, H.264 או H.265, הן:
- [C-1-1] חייבת לתמוך ברזולוציה דינמית של וידאו ובשינוי של קצב הפריימים באמצעות ממשקי ה-API הרגילים של Android באותו זרם עבור כל גרסאות VP8 ו-VP9 קודקים H.264 ו-H.265 בזמן אמת ועד לרזולוציה המקסימלית הנתמכת לפי כל קודק במכשיר.
5.3.1. MPEG-2
אם בהטמעות במכשירים יש תמיכה במפענחי MPEG-2:
- [C-1-1] חייבת לתמוך ברמה הגבוהה של הפרופיל הראשי.
5.3.2. H.263
אם בהטמעות במכשירים יש תמיכה במפענחי H.263:
- [C-1-1] חובה לתמוך בפרופיל הבסיס ברמה 30 (רזולוציות CIF, QCIF ו-SQCIF הן @ 30fps 384kbps) ורמה 45 (QCIF ו- רזולוציות SQCIF בקצב 30fps 128kbps).
5.3.3. MPEG-4
בהטמעות במכשירים עם מפענחי MPEG-4:
- [C-1-1] חייבת לתמוך ב-Simple Profile Level 3.
5.3.4. H.264
אם בהטמעות במכשירים יש תמיכה במפענחי H.264:
- [C-1-1] חובה לתמוך בפרופיל הראשי ברמה 3.1 ובפרופיל Baseline. תמיכה עבור ASO (סידור פרוסות שרירותי), FMO (סידור גמיש של Macroblock) ו-RS (פרוסות מיותרות) הוא אופציונלי.
- [C-1-2] חייבת להיות אפשרות לפענח סרטונים באיכות SD (Standard Definition) הפרופילים שמפורטים בטבלה הבאה ומקודדים באמצעות פרופיל Baseline ו'פרופיל ראשי' רמת 3.1 (כולל 720p30).
- אמורה להיות אפשרות לפענח סרטונים בפרופילים באיכות HD כפי שמצוין בטבלה הבאה.
אם הגובה שמדווח על ידי השיטה Display.getSupportedModes()
הוא
שווה לרזולוציית הסרטון או גבוהה ממנה, הטמעות המכשירים:
- [C-2-1] חייב לתמוך בפרופילים של פענוח וידאו באיכות HD 720p, טבלה.
- [C-2-2] חייבים לתמוך בפרופילים של פענוח וידאו באיכות HD 1080p טבלה.
SD (איכות נמוכה) | SD (איכות גבוהה) | HD 720p | HD 1080p | |
---|---|---|---|---|
רזולוציית וידאו | 240 x 320 פיקסלים | 720 x 480 פיקסלים | 720 x 1280 פיקסלים | 1920 x 1080 פיקסלים |
קצב הפריימים של הסרטון | 30 fps | 30 fps | 60 fps | 30 FPS (60fpsטלוויזיה) |
קצב העברת נתונים של וידאו | 800 Kbps | 2 Mbps | 8Mbps | 20 Mbps |
5.3.5. H.265 (HEVC)
אם בהטמעות במכשירים יש תמיכה בקודק H.265:
- [C-1-1] חייבת לתמוך ברמה הראשית של הרמה 3 בפרופיל הראשי ובסרטון SD של פרופילים לפענוח כפי שמצוין בטבלה הבאה.
- הנתונים אמורים לתמוך בפרופילים של פענוח HD, כפי שמתואר בטבלה הבאה.
- [C-1-2] חייבת לתמוך בפרופילים של פענוח HD, כפי שמצוין בהמשך אם יש מפענח חומרה.
אם הגובה שמדווח על ידי השיטה Display.getSupportedModes()
הוא
שווה לרזולוציית הסרטון או גדולה ממנה, אז:
- [C-2-1] הטמעות של מכשירים חייבות לתמוך לפחות בתקן H.265 או VP9 של 720, 1080 ופרופילי UHD.
SD (איכות נמוכה) | SD (איכות גבוהה) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
רזולוציית וידאו | 352 x 288 פיקסלים | 720 x 480 פיקסלים | 720 x 1280 פיקסלים | 1920 x 1080 פיקסלים | 3840 x 2160 פיקסלים |
קצב הפריימים של הסרטון | 30 fps | 30 fps | 30 fps | 30/60fps (60fpsטלוויזיה עם פענוח באמצעות חומרת H.265) | 60 fps |
קצב העברת נתונים של וידאו | 600 Kbps | 1.6 Mbps | 4Mbps | 5 Mbps | 20 Mbps |
אם המכשיר מיישם הצהרה על תמיכה בפרופיל HDR באמצעות המדיה ממשקי API:
- [C-3-1] הטמעות מכשירים חייבות לקבל את המטא-נתונים הנדרשים של HDR מ- של האפליקציה, וגם תמיכה בחילוץ ובפלט של ה-HDR הנדרש מטא-נתונים מה-bitstream ו/או מהקונטיינר.
- [C-3-2] הטמעות מכשירים חייבות להציג תוכן HDR באופן תקין במסך המכשיר או ביציאת וידאו רגילה (למשל, HDMI).
5.3.6. VP8
אם הטמעות במכשירים תומכים בקודק VP8:
- [C-1-1] חייבת לתמוך בפרופילים של פענוח SD שבטבלה הבאה.
- עליהם להשתמש בקודק חומרה VP8 שעונה על הדרישות.
- הפרופילים אמורים לתמוך בפרופילים של פענוח HD בטבלה הבאה.
אם הגובה כפי שדווח על ידי השיטה Display.getSupportedModes()
שווה
או גדול מרזולוציית הסרטון, אז:
- [C-2-1] הטמעות מכשירים חייבות לתמוך בפרופילים של 720p מהטבלה הבאה.
- [C-2-2] הטמעות מכשירים חייבות לתמוך בפרופילים של 1080p מהטבלה הבאה.
SD (איכות נמוכה) | SD (איכות גבוהה) | HD 720p | HD 1080p | |
---|---|---|---|---|
רזולוציית וידאו | 180 x 320 פיקסלים | 640 x 360 פיקסלים | 720 x 1280 פיקסלים | 1920 x 1080 פיקסלים |
קצב הפריימים של הסרטון | 30 fps | 30 fps | 30 FPS (60fpsטלוויזיה) | 30 (60 fpsטלוויזיה) |
קצב העברת נתונים של וידאו | 800 Kbps | 2 Mbps | 8Mbps | 20 Mbps |
5.3.7. VP9
אם בהטמעות במכשירים יש תמיכה בקודק VP9:
- [C-1-1] חייב לתמוך בפרופילים של פענוח וידאו באיכות SD, כפי שמתואר מהטבלה הבאה.
- הנתונים אמורים לתמוך בפרופילים של פענוח HD, כפי שמתואר בטבלה הבאה.
אם בהטמעות המכשיר תומכים בקודק VP9 ובמפענח חומרה:
- [C-2-1] חייבת לתמוך בפרופילים של פענוח HD, כפי שמצוין בהמשך טבלה.
אם הגובה שמדווח על ידי השיטה Display.getSupportedModes()
הוא
שווה לרזולוציית הסרטון או גדולה ממנה, אז:
- [C-3-1] הטמעות של מכשירים חייבות לתמוך לפחות בתקן VP9 או H.265 של פרופילים במידות 720, 1080 ו-UHD.
SD (איכות נמוכה) | SD (איכות גבוהה) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
רזולוציית וידאו | 180 x 320 פיקסלים | 640 x 360 פיקסלים | 720 x 1280 פיקסלים | 1920 x 1080 פיקסלים | 3840 x 2160 פיקסלים |
קצב הפריימים של הסרטון | 30 fps | 30 fps | 30 fps | 30FPS (60fpsטלוויזיה עם פענוח חומרה מסוג VP9) | 60 fps |
קצב העברת נתונים של וידאו | 600 Kbps | 1.6 Mbps | 4Mbps | 5 Mbps | 20 Mbps |
אם בהטמעות של מכשירים יש תמיכה ב-VP9Profile2
או ב-VP9Profile3
דרך 'CodecProfileLevel'
ממשקי API למדיה:
- תמיכה בפורמט 12 ביט היא אופציונלית.
אם בהטמעות של המכשיר נטען שהוא תומך בפרופיל HDR (VP9Profile2HDR
,
VP9Profile2HDR10Plus
, VP9Profile3HDR
, VP9Profile3HDR10Plus
) דרך
ממשקי API למדיה:
- [C-4-1] הטמעות מכשירים חייבות לקבל את המטא-נתונים הנדרשים של HDR
(
KEY_HDR_STATIC_INFO
) עבור כל הפרופילים של HDR, וגם 'KEY_HDR10_PLUS_INFO' לפרופילים של HDR10Plus) מהאפליקציה. הם גם חייבים לתמוך בחילוץ ובפלט של המטא-נתונים הנדרשים של HDR מה-bitstream ו/או מהקונטיינר. - [C-4-2] הטמעות מכשירים חייבות להציג תוכן HDR באופן תקין במסך המכשיר או ביציאת וידאו רגילה (למשל, HDMI).
5.3.8. Dolby Vision
אם בהטמעות המכשיר מוצהר על תמיכה במפענח Dolby Vision דרך
HDR_TYPE_DOLBY_VISION
,
הם:
- [C-1-1] חובה לספק כלי חילוץ עם תמיכה ב-Dolby Vision.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-1-2] התוכן של Dolby Vision חייב להופיע בצורה תקינה אחת במכשיר במסך או במסך חיצוני שמחובר באמצעות יציאה רגילה של פלט וידאו (למשל, HDMI).
סיום הדרישות החדשות
- [C-1-3] חובה להגדיר את מזהה הטראק של שכבות הבסיס שתואמות לאחור (אם קיימות) כך שיהיו זהות שילבנו את מזהה המסלול של שכבת Dolby Vision.
5.3.9. AV1
אם הטמעות המכשירים תומכים בקודק AV1 והופכים אותו לזמין לאפליקציות של צד שלישי:
- [C-1-1] חייבת לתמוך בפרופיל הראשי, כולל תוכן של 8 ביט ו-10 ביט.
אם הטמעות המכשירים מספקות תמיכה בקודק AV1 עם חומרה ממפענח מהיר יותר, ואז:
- [C-2-1] חייבת להיות אפשרות לפענח פרופילים של פענוח וידאו באיכות HD 720p לפחות מ:
הטבלה שבהמשך כאשר הגובה מדווח לפי
Display.getSupportedModes()
שווה ל-720p או גדול ממנו. - [C-2-2] חייבת להיות אפשרות לפענח פרופילים של פענוח וידאו באיכות HD 1080p לפחות
מהטבלה למטה כשהגובה מדווח לפי
Display.getSupportedModes()
שווה ל-1080p או גדול ממנו.
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
רזולוציית וידאו | 720 x 480 פיקסלים | 720 x 1280 פיקסלים | 1920 x 1080 פיקסלים | 3840 x 2160 פיקסלים |
קצב הפריימים של הסרטון | 30 fps | 30 fps | 30 fps | 30 fps |
קצב העברת נתונים של וידאו | 5 Mbps | 8Mbps | 16Mbps | 50 Mbps |
אם ההטמעות במכשירים תומכים בפרופיל HDR דרך ממשקי Media API, הם:
- [C-3-1] חייבת להיות תמיכה בחילוץ ובפלט של מטא-נתונים של HDR Bitstream ו/או קונטיינר.
- [C-3-2] תוכן HDR חייב להציג כראוי במסך המכשיר או יציאה רגילה של פלט וידאו (לדוגמה, HDMI).
5.4. הקלטת אודיו
אומנם חלק מהדרישות שמפורטות בקטע הזה מפורטות החל מ-Android 4.3, אנחנו מתכננים את הגדרת התאימות לגרסאות עתידיות כדי לשנות אותן לחובה. מכשירי Android הקיימים והחדשים מוצלחים מאוד מומלץ לעמוד בדרישות שמפורטות בתור 'צריכות', או לא יוכלו להשיג תאימות ל-Android לאחר השדרוג .
5.4.1. הקלטת אודיו גולמית ופרטי מיקרופון
אם הטמעות המכשירים מצהירות על android.hardware.microphone
, הן:
[C-1-1] חובה לאפשר הקלטה של תוכן אודיו גולמי עבור כל שידור של
AudioRecord
אוAAudio
INPUT שנפתח בהצלחה. לכל הפחות, המאפיינים הבאים חייבים להיות נתמכים:- פורמט: PCM לינארי, 16 ביט
- קצב דגימה: 8,000, 11,025, 16,000, 44100, 48,000 Hz
- ערוצים: מונו
- מקורות אודיו:
DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
, אוVOICE_PERFORMANCE
. הדבר נכון גם לגבי הגדרות הקלט המקבילות שהוגדרו מראש ב-AAudio
, עבור לדוגמה,AAUDIO_INPUT_PRESET_CAMCORDER
.
אמורה לאפשר הקלטה של תוכן אודיו גולמי עם הרכיבים הבאים: מאפיינים:
- פורמט: PCM לינארי, 16 ביט ו-24 ביט
- שיעורי דגימה: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48,000 Hz
- ערוצים: מספר הערוצים שווה למספר המיקרופונים המכשיר
[C-1-2] חובה לתעד את קצב הדגימה ברמה גבוהה יותר ללא הגדלת הדגימה.
[C-1-3] חייב לכלול מסנן מתאים למניעת התמרה כאשר שיעורי הדגימה שתוארו למעלה מתועדים באמצעות שיטת הקטנת נתונים.
אמור לאפשר הקלטת רדיו AM ו-DVD באיכות של תוכן אודיו גולמי, פירושו את המאפיינים הבאים:
- פורמט: PCM לינארי, 16 ביט
- קצב דגימה: 22,050, 48,000 Hz
- ערוצים: סטריאו
[C-1-4] חובה לפעול בהתאם ל-API של
MicrophoneInfo
ולמלא כראוי את המידע על המיקרופונים הזמינים במכשיר לאפליקציות צד שלישי דרךAudioManager.getMicrophones()
API, להקלטת אודיו פעילה באמצעותMediaRecorder.AudioSources DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
אוVOICE_PERFORMANCE
. אם הטמעת המכשיר מאפשרת תיעוד באיכות רדיו AM ו-DVD של אודיו גולמי תוכן, הם:[C-2-1] חובה לצלם ללא דגימת-על בכל יחס שגבוה מ- 16000:22050 או 44100:48000.
[C-2-2] חייב לכלול מסנן מתאים למניעת התמרה בכל דגימות או דגימה כלפי מטה.
5.4.2. צילום לזיהוי קולי
אם הטמעות המכשירים מצהירות על android.hardware.microphone
, הן:
- [C-1-1] חובה לצלם
מקור האודיו
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION
הוא אחד מקצבי הדגימה, 44100 ו-48000. - [C-1-2] חובה להשבית כברירת מחדל כל עיבוד אודיו להפחתת רעש כאשר
הקלטת שידור אודיו מהאודיו של
AudioSource.VOICE_RECOGNITION
מקור. [C-1-3] חובה להשבית כברירת מחדל כל בקרת קליטה אוטומטית במהלך ההקלטה שידור אודיו ממקור האודיו
AudioSource.VOICE_RECOGNITION
.אמורה להציג מאפיינים של משרעת (המשרעת) שטוחה לעומת שכיחות בטווח התדרים הבינוני: במיוחד ±3dB מ-100Hz עד 4,000Hz לכל וכל מיקרופון שמשמש להקלטת מקור האודיו לזיהוי קולי.
[C-SR-1] מומלץ מאוד להראות רמות משרעת טווח תדרים: באופן ספציפי מ- ±20dB מ-30Hz עד 100Hz טווח תדרים בינוני לכל מיקרופון שמשמש להקלטת הקול מקור האודיו לזיהוי.
[C-SR-2] מומלץ מאוד להראות רמות משרעת טווח תדרים: באופן ספציפי מ- ±30dB מ-4000Hz עד 22KHz בהשוואה טווח התדרים הבינוני לכל מיקרופון שמשמש להקלטת הקול מקור האודיו לזיהוי.
צריך להגדיר את הרגישות לקלט האודיו, כך שמקור הטון סינוסאידי של 1,000 Hz הופעל ב- 90 dB רמת לחץ קול (SPL) (נמדד ליד המיקרופון) מניב תגובה אידיאלית של RMS 2,500 בטווח של 1,770 ו-3,530 ל-16 דגימות סיביות (או -22.35 db ±3dB התאמה מלאה לנקודה צפה/דיוק כפול דגימות) עבור כל מיקרופון שמשמש להקלטת הזיהוי הקולי מקור האודיו.
יש להקליט את שידור האודיו של זיהוי הקול כך שאמפליטודת ה-PCM רמות לינאריות עוקבות באופן לינארי אחר שינויים ב-SPL בטווח של 30 דציבלים לפחות מ-18- דציבלים עד +12dB re 90dB SPL במיקרופון.
צריך להקליט את שידור האודיו של זיהוי הקול עם הרמוניה עיוות (THD) קטן מ-1% ל-1kHz ברמת קלט של 90dB SPL המיקרופון.
אם בהטמעות המכשיר מוצהר על android.hardware.microphone
ורעש
טכנולוגיות דיכוי (הפחתה) שמותאמות לזיהוי דיבור:
- [C-2-1] חייבת להיות אפשרות לשלוט באפקט האודיו הזה באמצעות
API של
android.media.audiofx.NoiseSuppressor
. - [C-2-2] חייבת לזהות באופן ייחודי כל טכנולוגיה לביטול רעש
באמצעות השדה
AudioEffect.Descriptor.uuid
.
5.4.3. צילום לצורך ניתוב מחדש של ההפעלה
המחלקה android.media.MediaRecorder.AudioSource
כוללת את REMOTE_SUBMIX
מקור האודיו.
אם בהטמעות במכשירים מוצהרות גם android.hardware.audio.output
וגם
android.hardware.microphone
, הן:
[C-1-1] חובה להטמיע בצורה תקינה את מקור האודיו
REMOTE_SUBMIX
כדי כשאפליקציה משתמשת ב-API שלandroid.media.AudioRecord
כדי להקליט מקור האודיו, הוא מתעד שילוב של כל שידורי האודיו מלבד הבאים:AudioManager.STREAM_RING
AudioManager.STREAM_ALARM
AudioManager.STREAM_NOTIFICATION
5.4.4. מבטל הד אקוסטי
אם הטמעות המכשירים מצהירות על android.hardware.microphone
, הן:
- צריך להטמיע כלי לביטול הד אקוסטי
(AEC) טכנולוגיה שמכווננת לתקשורת קולית והוחלה על נתיב הצילום
בזמן צילום באמצעות
AudioSource.VOICE_COMMUNICATION
.
אם יישומי המכשיר מספקים ביטול הד אקוסטי, כלומר
נוסף לנתיב האודיו להקלטה כאשר AudioSource.VOICE_COMMUNICATION
נבחר, הם:
- [C-SR-1] מומלץ להצהיר על כך באמצעות AcousticEchoCanceler שיטת ה-API AcousticEchoCanceler.isAvailable()
- [C-SR-2] מומלץ מאוד כדי לאפשר את אפקט האודיו הזה ניתן לשליטה באמצעות AcousticEchoCanceler API.
- [C-SR-3] מומלץ מאוד לזהות כל טכנולוגיית AEC באופן ייחודי דרך ה-Audio Effects.Descriptor.uuid. השדה הזה.
5.4.5. צילום בו-זמנית
אם בהטמעות במכשירים מוצהר על android.hardware.microphone
,חובה
להטמיע תיעוד דיגיטלי של בו-זמנית כפי שמתואר במסמך הזה. פרטים נוספים:
- [C-1-1] חובה לאפשר גישה בו-זמנית למיקרופון באמצעות נגישות
הקלטת שירות עם
AudioSource.VOICE_RECOGNITION
ולפחות אחד לתיעוד אפליקציות באמצעות כלAudioSource
. - [C-1-2] חובה לאפשר גישה בו-זמנית למיקרופון באמצעות
אפליקציה עם תפקיד Assistant ולפחות אפליקציה אחת
מצלם באמצעות כל
AudioSource
מלבדAudioSource.VOICE_COMMUNICATION
אוAudioSource.CAMCORDER
. - [C-1-3] חובה להשתיק את הקלטת האודיו עבור כל אפליקציה אחרת, מלבד
שירות נגישות, והאפליקציה מצלמת באמצעות
AudioSource.VOICE_COMMUNICATION
אוAudioSource.CAMCORDER
. אבל, כאשר אפליקציה מצלמת דרךAudioSource.VOICE_COMMUNICATION
ואז אפליקציה אחרת יכול להקליט את השיחה הקולית אם זו אפליקציה בעלת הרשאות (מותקנת מראש) עם הרשאהCAPTURE_AUDIO_OUTPUT
. - [C-1-4] אם שתי אפליקציות או יותר מבצעות תיעוד בו-זמנית לאף אחת מהאפליקציות אין ממשק משתמש בחלק העליון, זה שהתחיל לתעד את הגרסה האחרונה מקבל אודיו.
5.5. הפעלת האודיו
ב-Android יש תמיכה כדי לאפשר לאפליקציות להפעיל אודיו באמצעות האודיו ציוד היקפי שמשמש לפלט כפלט כפי שמוגדר בסעיף 7.8.2.
5.5.1. הפעלת אודיו גולמי
אם הטמעות המכשירים מצהירות על android.hardware.audio.output
, הן:
[C-1-1] חובה לאפשר הפעלה של תוכן אודיו גולמי עם הרכיבים הבאים: מאפיינים:
- פורמטים של המקור: PCM לינארי, 16 ביט, 8 ביט, מספר ממשי (float)
- ערוצים: מונו, סטריאו, תצורות חוקיות בערוצים מרובים עם עד 8 ערוצים
- קצבי דגימה (ב-Hz):
- 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 בערוץ ההגדרות האישיות שצוינו למעלה
- 96000 במונו ובסטריאו
5.5.2. אפקטים קוליים
ב-Android יש API לאפקטים קוליים להטמעת מכשירים.
אם בהטמעות במכשירים מוצהר על התכונה android.hardware.audio.output
,
הם:
- [C-1-1] חייבת לתמוך ב-
EFFECT_TYPE_EQUALIZER
EFFECT_TYPE_LOUDNESS_ENHANCER
ניתנים לשליטה באמצעות תתי-מחלקות של אפקט אודיוEqualizer
ו-LoudnessEnhancer
. - [C-1-2] חייבת לתמוך בהטמעת API של Visualizer, שאפשר לשלוט בה באמצעות
הכיתה
Visualizer
. - [C-1-3] חייבת לתמוך בהטמעה של
EFFECT_TYPE_DYNAMICS_PROCESSING
שניתן לשלוט בהם דרך המחלקה המשנית של AudioImpactDynamicsProcessing
.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-1-4] חייבת להיות תמיכה באפקטים של אודיו עם והפלט והקלט של נקודה צפה (floating-point), כאשר האפקט התוצאות מוחזרות לצינור האודיו של framework. מתייחס למקרים רגילים להוסיף אפקטים או עזר, כמו אקולייזר. ההתנהגות המקבילה היא חזקה מומלץ כאשר לא ניתן לראות את תוצאות האפקט על ידי האודיו של המסגרת צינור עיבוד נתונים (למשל, אפקטים לאחר עיבוד או אפקטים שהוסרו).
סיום הדרישות החדשות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-1-5] חובה לוודא שאפקטים קוליים תומכים במספר ערוצים עד מספר ערוצי המיקסר שנקרא גם FCC_LIMIT, כשתוצאות האפקט מוחזרות לצינור עיבוד הנתונים של האודיו ב-framework. הזה מתייחס לאפקטים של הוספה או עזר טיפוסיים, אך לא כולל אפקטים מיוחדים. כמו אפקט דאון-מיקס, אפקט מיקס ואפקט מרחבי העולם שמשנים את מספר הערוצים. מומלץ להשתמש בהתנהגות מקבילה כאשר האפקטים לא נראים על ידי צינור עיבוד נתונים של framework (למשל, לאחר עיבוד או עומס אפקטים).
סיום הדרישות החדשות
- צריכה לתמוך ב-
EFFECT_TYPE_BASS_BOOST
,EFFECT_TYPE_ENV_REVERB
, הטמעותEFFECT_TYPE_PRESET_REVERB
ו-EFFECT_TYPE_VIRTUALIZER
שניתן לשלוט בו דרך מחלקות המשנהAudioEffect
BassBoost
,EnvironmentalReverb
,PresetReverb
,Virtualizer
. - [C-SR-1] מומלץ מאוד להוסיף תמיכה באפקטים בנקודה צפה (floating-point) מרובה-ערוצים.
5.5.3. עוצמת הקול של פלט האודיו
הטמעות של מכשירים בכלי רכב:
- אמורה לאפשר שינוי של עוצמת הקול של האודיו
בנפרד לכל שידור אודיו, באמצעות סוג התוכן או השימוש כפי שהוגדרו
לפי AudioAttributes
ושימוש באודיו ברכב כפי שהוגדר באופן ציבורי ב
android.car.CarAudioManager
.
5.5.4. הורדת אודיו
אם בהטמעות במכשירים יש תמיכה בהפעלה של הפחתת אודיו, הן:
- [C-SR-1] מומלץ מאוד לחתוך את תוכן האודיו שהופעל ללא פערים בין שני קליפים באותו פורמט כשמצוין על ידי API ללא פערים של AudioTrack ואת מאגר המדיה של MediaPlayer.
5.6. זמן אחזור של אודיו
זמן האחזור של האודיו הוא הזמן שחולף עד שאות אודיו עובר במערכת. סוגים רבים של אפליקציות מסתמכים על זמני אחזור קצרים כדי להשיג נתונים בזמן אמת אפקטים קוליים.
למטרות הסעיף הזה, צריך להשתמש בהגדרות הבאות:
- זמן אחזור של פלט מרווח הזמן בין המועד שבו האפליקציה כותבת מסגרת של נתונים מקודדים לפי PCM וכשהצליל התואם מוצג במתמר במכשיר או שהאות יוצא מהמכשיר דרך ואפשר לצפות בו באופן חיצוני.
- זמן אחזור של פלט קר הזמן שחולף בין ההפעלה של זרם הפלט לבין זמן ההצגה של הפריים הראשון על סמך חותמות זמן, כשפלט האודיו המערכת לא הייתה פעילה והושבתה לפני הבקשה.
- זמן אחזור רציף של הפלט את זמן האחזור של הפלט במסגרות הבאות, לאחר שהמכשיר משמיע אודיו.
- זמן אחזור של קלט. המרווח בין הזמן שבו צליל מוצג של סביבה למכשיר במתמר במכשיר או אות שנכנס למכשיר דרך יציאה וכשהאפליקציה קוראת את המסגרת המתאימה של נתונים מקודדים לפי PCM.
- קלט שאבד. החלק הראשוני של אות קלט שלא ניתן לשימוש, או לא זמין.
- זמן אחזור של קלט קר. משך הזמן שחולף בין התחלת השידור לבין המועד שבו מתקבלת פריים תקין ראשון, כשמערכת קלט האודיו לא פעילה הושבת לפני הבקשה.
- זמן אחזור של קלט רציף. את זמן האחזור של הקלט למסגרות הבאות, כשהמכשיר מקליט אודיו.
- זמן אחזור רציף הלוך ושוב. הסכום של זמן אחזור של קלט רציף ועוד זמן אחזור רציף של הפלט, בתוספת תקופת מאגר נתונים זמני אחת. התקופה של מאגר הנתונים הזמני מאפשרת הזמן שחולף עד שהאפליקציה תעבד את האות והזמן שבו האפליקציה תקצר את השלב ההבדל בין זרמי קלט לזרם פלט.
- OpenSL ES PCM bufferQueue API. קבוצת פריטים שקשורים ל-PCM OpenSL ES ממשקי API ב-Android NDK.
- AAudio Native Audio API. הקבוצה של ממשקי API של AAudio בתוך Android NDK.
- חותמת זמן. צמד שמכיל מיקום של מסגרת יחסי בתוך ואת הזמן המשוער שבו המסגרת נכנסת או יוצאת צינור עיבוד אודיו לעיבוד אודיו בנקודת הקצה המשויכת. עוד באותו הקשר AudioTimestamp.
- תקלה. הפרעה זמנית או ערך דגימה שגוי באות האודיו, נגרמה בדרך כלל על ידי פונקציית חוצץ תחתון לפלט, חריגה ממאגר הנתונים הזמני עבור קלט או כל מקור אחר של רעש דיגיטלי או אנלוגי.
- משמעות של סטייה מוחלטת (MAD). הממוצע של הערך המוחלט של סטיות מהממוצע של קבוצת ערכים.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
זמן האחזור של הקשה לטון (TTL), כפי שנמדד על ידי CTS Verifier, הוא השעה בין כשמקישים על המסך לבין צליל שנוצר כתוצאה מכך נשמעת הקשה ברמקול. הנתון הזה מחושב לפי הממוצע של 5 מדידות באמצעות ממשק API של אודיו מקורי של אודיו לפלט.
זמן האחזור של מסלול הלוך ושוב (RTL), כפי שנמדד על ידי מאמת ה-CTS, הוא הממוצע זמן אחזור רציף במשך 5 מדידות, שנמדד דרך נתיב לולאה חוזרת שפידים את הפלט בחזרה לקלט באמצעות ממשק ה-API של אודיו נייטיב AAudio. נתיבי הלולאה החוזרים הם:
- רמקול/מיקרופון: רמקול מובנה למיקרופון מובנה.
- אנלוגי: שקע אנלוגי 3.5 מ"מ ומתאם לולאה חוזרת.
- USB: מתאם USB ל-3.5 מ"מ ומתאם לולאה חוזרת או אודיו USB כבלים שונים וכבלים מסוג לולאה חוזרת.
FEATURE_AUDIO_PRO. התכונה
android.hardware.audio.pro
היא מוצהר.MPC שיעור ביצועי מדיה
סיום הדרישות החדשות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- זמן אחזור של מעקב ראש השעה לוקח מתנועת הראש שנקלטה על ידי יחידת המדידה האינטרציאלית (IMU) של מתאמי האוזניות זיהוי השינוי בצליל שנגרם על ידי את התנועה הזאת.
סיום הדרישות החדשות
אם בהטמעות במכשירים מוצהר על android.hardware.audio.output
, הן
חייבים לעמוד בדרישות הבאות או לעבור אותן:
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-1-1] חותמת הזמן של הפלט שהוחזרה על ידי
AudioTrack.getTimestamp
ו-
AAudioStream_getTimestamp
מדויק ל- +/- 2 אלפיות השנייה.
סיום הדרישות החדשות
[C-1-2] זמן אחזור של פלט קר של 500 אלפיות השנייה או פחות.
[C-1-3] פתיחת זרם פלט באמצעות
AAudioStreamBuilder_openStream()
חייבים התהליך נמשך פחות מ-1,000 אלפיות השנייה.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-1-4] זמני האחזור המחושבים הלוך ושוב על סמך קלט ופלט
חותמות זמן שהוחזרו על ידי
AAudioStream_getTimestamp
חייבות להיות בטווח של 200 אלפיות שנייה מ את זמן האחזור הלוך ושוב שנמדד עבורAAUDIO_PERFORMANCE_MODE_NONE
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
לרמקולים, קוויים ואלחוטיים אוזניות עם מיקרופון.
סיום הדרישות החדשות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם בהטמעות המכשירים מוצהר על android.hardware.audio.output
הם
מומלץ מאוד לעמוד בדרישות הבאות או לעבור אותן:
[C-SR-1] זמן אחזור של פלט קר של 100 אלפיות השנייה או פחות ברמקול בנתיב הנתונים.
[C-SR-2] זמן אחזור של 80 אלפיות שנייה או פחות מהקשה לטון.
[C-SR-4] זמני האחזור המחושבים הלוך ושוב על סמך קלט ופלט מומלץ מאוד להשתמש בחותמות זמן שהוחזרו על ידי
AAudioStream_getTimestamp
להיות בטווח של 30 אלפיות השנייה מזמן האחזור שנמדד הלוך ושובAAUDIO_PERFORMANCE_MODE_NONE
וגםAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
עבור רמקולים, אוזניות חוטיות ואלחוטיות.
סיום הדרישות החדשות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם יישומים של מכשירים עומדים בדרישות שלמעלה, לאחר כיול, בעת שימוש ב-AAudionative audio API, לפלט רציף זמן אחזור וזמן אחזור של פלט במצב התחלתי (cold start) בלפחות קטע אודיו אחד נתמך של המכשיר להצגת מידע, הם:
- [C-SR-5] מומלץ מאוד לדווח על אודיו עם זמן אחזור קצר
סימון תכונה
android.hardware.audio.low_latency
. - [C-SR-6] מומלץ מאוד לעמוד בדרישות לגבי זמן אחזור קצר אודיו דרך AAudio API.
- [C-SR-7] מומלץ מאוד לוודא שבשידורים שחוזרים
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
החל מ-AAudioStream_getPerformanceMode()
, הערך המוחזר על ידיAAudioStream_getFramesPerBurst()
קטן מהערך שהוחזר על ידיandroid.media.AudioManager.getProperty(String)
או שווה לו למפתח הנכסAudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER
.
סיום הדרישות החדשות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם ההטמעות של המכשיר לא עומדות בדרישות של אודיו עם זמן אחזור קצר באמצעות ממשק ה-API של אודיו מקורי של AAudio, הן:
- [C-2-1] אסור לדווח על תמיכה באודיו עם זמן אחזור קצר.
סיום הדרישות החדשות
אם ההטמעות במכשירים כוללות את android.hardware.microphone
,
הקלט צריך לעמוד בדרישות הבאות לגבי אודיו:
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-3-1] הגבלת השגיאה בחותמות הזמן של הקלט, כפי שהוחזר על ידי
AudioRecord.getTimestamp
או
AAudioStream_getTimestamp
, ל- +/- 2 ms. "שגיאה" כאן מתייחסת לסטייה מהערך הנכון.
סיום הדרישות החדשות
- [C-3-2] זמן אחזור קר input של 500 אלפיות השנייה או פחות.
- [C-3-3] פתיחת זרם קלט באמצעות
AAudioStreamBuilder_openStream()
חייבת התהליך נמשך פחות מ-1,000 אלפיות השנייה.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם ההטמעות במכשירים כוללות את android.hardware.microphone
,
מומלץ מאוד לעמוד בדרישות הבאות של אודיו:
- [C-SR-8] זמן אחזור של קלט קר של 100 אלפיות שנייה או פחות דרך המיקרופון בנתיב הנתונים.
- [C-SR-11] הגבלת השגיאה בחותמות הזמן של הקלט, כפי שהוחזרה על ידי
AudioRecord.getTimestamp
או
AAudioStream_getTimestamp
, ל- +/- 1 ms.
סיום הדרישות החדשות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם בהטמעות המכשירים מוצהר על android.hardware.audio.output
וגם
android.hardware.microphone
, הן:
- [C-SR-12] מומלץ מאוד זמן אחזור ממוצע במהלך נסיעה רציפה של 50 אלפיות שנייה או פחות מ-5 מדידות, עם סטייה אבסולוטית ממוצעת פחות מ-10 אלפיות שנייה, לפחות בנתיב נתמך אחד.
סיום הדרישות החדשות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
בטבלה הבאה מפורטות הדרישות לגבי RTL למכשירים ניידים
הטמעות כפי שמוגדר ב-2.2.1 ומצהירים בהן
android.hardware.audio.output
ו-android.hardware.microphone
.
מכשיר והצהרות | RTL (באלפיות שנייה) | MAD (אלפיות שנייה) | נתיבי הלולאה החוזרת |
---|---|---|---|
מוחזקת ביד | 250 | 30 | רמקול/מיקרופון, אנלוגי 3.5 מ"מ (אם נתמך), USB (אם נתמך) |
>= MPC_T (14) | 80 | 15 | לפחות נתיב אחד |
FEATURE_AUDIO_LOW_LATENCY | 50 | 10 | לפחות נתיב אחד |
FEATURE_AUDIO_PRO | 25 | 5 | לפחות נתיב אחד |
FEATURE_AUDIO_PRO | 20 | 5 | אנלוגי (אם נתמך) |
FEATURE_AUDIO_PRO | 25 | 5 | USB (אם אנלוגי לא נתמך) |
סיום הדרישות החדשות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם ההטמעות במכשירים כוללות תמיכה
spatial audio
עם מעקב אחר תנועות הראש
ולהצהיר על PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY
הם:
- [C-4-1] חייב להיות זמן אחזור מקסימלי של 300 אלפיות השנייה עבור מעקב ראש אחר עדכון אודיו.
סיום הדרישות החדשות
5.7. פרוטוקולי רשת
יישומי מכשירים חייבים לתמוך פרוטוקולים של רשת מדיה להפעלת אודיו ווידאו כפי שצוין במסמכי התיעוד של Android SDK.
לכל פורמט קודק ופורמט קונטיינר שצריך להטמיע במכשיר תמיכה, הטמעת המכשיר:
[C-1-1] חייב לתמוך ב-Codec או בקונטיינר הזה ב-HTTP וב-HTTPS.
[C-1-2] חייבת לתמוך בפורמטים המתאימים של פלחי מדיה, כפי שמוצג טבלת הפורמטים של פלחי המדיה שלמטה, פרוטוקול טיוטה של HTTP בשידור חי, גרסה 7.
[C-1-3] חייבת לתמוך בפורמטים המתאימים של המטען הייעודי (payload) של RTSP, כפי שמוצג טבלת RTSP למטה. למקרים חריגים, מומלץ לעיין בהערות השוליים של הטבלה סעיף 5.1.
פורמטים של פלחי מדיה
פורמטים של פלחים | הפניות | נדרשת תמיכה בקודק |
---|---|---|
MPEG-2 Transport Stream | ISO 13818 |
קודק הווידאו:
ו-MPEG-2. קודק האודיו:
|
AAC עם תגי פריים ו-ID3 של ADTS | ISO 13818-7 | ראו סעיף 5.1.1 לפרטים על AAC ועל הווריאציות שלו |
WebVTT | WebVTT |
RTSP (RTP, SDP)
השם בפרופיל | הפניות | נדרשת תמיכה בקודק |
---|---|---|
H264 AVC | RFC 6184 | ראו סעיף 5.1.8 לפרטים על H264 AVC |
MP4A-LATM | RFC 6416 | ראו סעיף 5.1.3 לפרטים על AAC ועל הווריאציות שלו |
H263-1998 |
RFC 3551 RFC 4629 RFC 2190 |
ראו סעיף 5.1.8 לפרטים על H263 |
H263-2000 | RFC 4629 | ראו סעיף 5.1.8 לפרטים על H263 |
AMR | RFC 4867 | ראו סעיף 5.1.3 לפרטים על AMR-NB |
AMR-WB | RFC 4867 | ראו סעיף 5.1.3 לפרטים על AMR-WB |
MP4V-ES | RFC 6416 | ראו סעיף 5.1.8 לפרטים על MPEG-4 SP |
קובץ mpeg4-גנרי | RFC 3640 | ראו סעיף 5.1.3 לפרטים על AAC ועל הווריאציות שלו |
MP2T | RFC 2250 | לפרטים נוספים, ראו MPEG-2 Transport Stream מתחת ל-HTTP Live Streaming |
5.8. מדיה מאובטחת
אם בהטמעות במכשירים תומכים בפלט וידאו מאובטח ומסוגלים כלומר:
- [C-1-1] חובה להצהיר על תמיכה ב-
Display.FLAG_SECURE
.
אם בהטמעות מכשירים מוצהר על תמיכה ב-Display.FLAG_SECURE
ותומכות
פרוטוקול תצוגה אלחוטית, הם:
- [C-2-1] חובה לקבע את הקישור באמצעות מנגנון קריפטוגרפי חזק כמו כמו HDCP 2.x ומעלה עבור מסכים שמחוברים באמצעות פרוטוקולים אלחוטיים. כמו Miracast.
אם בהטמעות המכשירים מוצהר על תמיכה ב-Display.FLAG_SECURE
וב-
תומכים במסך חיצוני עם חיבור קווי, הם:
- [C-3-1] חייב לתמוך ב-HDCP 1.2 ואילך בכל המסכים החיצוניים המחוברים באמצעות יציאה קווית שנגישה למשתמש.
5.9. ממשק דיגיטלי לכלים מוזיקליים (MIDI)
אם הטמעת דיווח על תמיכה בתכונה android.software.midi
במכשירים
דרך
android.content.pm.PackageManager
בכיתה, הם:
[C-1-1] חייבת להיות תמיכה ב-MIDI בכל העברות החומרה שתומכים ב-MIDI עבור מספקות קישוריות גנרית שאינה MIDI, כאשר העברות כאלה:
- מצב מארח USB, סעיף 7.7
- MIDI באמצעות Bluetooth LE בתפקיד מרכזי, סעיף 7.4.3
[C-1-2] חייבת להיות תמיכה בהעברה של תוכנות MIDI בתוך האפליקציה (מכשירי MIDI וירטואליים)
[C-1-3] חובה לכלול את libamidi.so (תמיכה מובנית ב-MIDI)
צריכה להיות תמיכה ב-MIDI במצב של ציוד היקפי בחיבור USB, סעיף 7.7
5.10. אודיו מקצועי
אם יישומים של מכשירים מדווחים על תמיכה בתכונה
android.hardware.audio.pro
דרך
android.content.pm.PackageManager
בכיתה, הם:
- [C-1-1] חובה לדווח על תמיכה בתכונה
android.hardware.audio.low_latency
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-1-2] חובה
להשמיע אודיו הלוך ושוב הרציף זמן האחזור, עומד בזמן האחזור הדרישות לגביFEATURE_AUDIO_PRO
כפי שהן מוגדרות בסעיף 5.6 זמן אחזור אודיושל 25 אלפיות השנייה או פחות למשך זמן נתמך אחד לפחות.
סיום הדרישות החדשות
- [C-1-3] חייבות לכלול יציאות USB שתומכות במצב מארח USB וב-USB מצב ציוד היקפי.
- [C-1-4] חובה לדווח על תמיכה בתכונה
android.software.midi
.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-1-5] חייבים לעמוד בדרישות
זמן אחזורואודיו ב-USB דרישות לגבי זמן אחזור באמצעות אודיו מקורי של אודיו API ו-AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
.
סיום הדרישות החדשות
- [C-1-6] זמן האחזור של הפלט במצב התחלתי חייב להיות 200 אלפיות השנייה או פחות.
- [C-1-7] זמן האחזור של קלט קר חייב להיות 200 אלפיות השנייה או פחות.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-1-8] זמן האחזור הממוצע של 'הקשה לטון' חייב להיות 80 אלפיות השנייה או פחות לפחות 5 מדידות לאורך נתיב הנתונים של הדובר למיקרופון.
- [C-SR-1] מומלץ מאוד לעמוד בזמני אחזור כפי שהוגדרו בסעיף זמן אחזור של אודיו 5.6, של 20 אלפיות השנייה או פחות, יותר מ-5 מדידות עם סטייה אבסולוטית ממוצעת של פחות מ-5 אלפיות שנייה מעל הנתיב בין הדובר למיקרופון.
- [C-SR-2] מומלץ מאוד לעמוד בדרישות של Pro Audio עבור זמן אחזור אודיו דו-כיווני רציף, זמן אחזור של קלט קר ופלט קר הדרישות לגבי זמן אחזור ואודיו ב-USB באמצעות ה-API של AAudio native audio מעל נתיב ה-MMAP.
[C-SR-3] מומלץ מאוד לספק רמה עקבית של מעבד (CPU) ביצועים בזמן שהאודיו פעיל והעומס על המעבד (CPU) משתנה. צריך לבדוק את זה באמצעות האפליקציה SynthMark ל-Android. SynthMark משתמש בסינתיסייזר תוכנה שפועל על פריים מדומה של אודיו שמודדים את ביצועי המערכת. לצפייה מסמכי תיעוד של SynthMark כדי לקבל הסבר על נקודות ההשוואה. סימן SynthMark צריך להריץ את האפליקציה באמצעות 'בדיקה אוטומטית' ומשיגים את התוצאות הבאות:
- voicemark.90 >= 32 קולות
- durationmark.fixed.little <= 15 מילי-שניות
- durationmark.dynamic.little <= 50 מילי-שניות
אמור לצמצם את אי הדיוק של שעון האודיו וסחף ביחס לזמן הסטנדרטי.
צריך לצמצם את הסחף של שעון האודיו ביחס למעבד (CPU)
CLOCK_MONOTONIC
כששניהם פעילים.זה אמור לצמצם את זמן האחזור של האודיו במתמרים ששמורים במכשיר.
יש לצמצם את זמן האחזור של האודיו באודיו דיגיטלי בחיבור USB.
צריך לתעד את המדידות של זמן האחזור של האודיו בכל הנתיבים.
אמורה לצמצם את הרעידות בזמני הכניסה של הקריאה החוזרת להשלמת מאגר האודיו של האודיו, כי משפיעה על האחוז השימושי של רוחב הפס המלא במעבד (CPU) על ידי הקריאה החוזרת (callback).
השימוש הרגיל אמור לספק אפס תקלות אודיו בזמן האחזור המדווח.
אמורה לספק הפרש בין זמן האחזור בין הערוצים.
זמן האחזור הממוצע של MIDI אמור לצמצם את זמן האחזור בכל אמצעי התחבורה.
צריכה לצמצם את השונות של זמן האחזור של MIDI בעומס (רעידות) בכל ההעברות.
צריכה לספק חותמות זמן מדויקות לשימוש ב-MIDI בכל אמצעי התחבורה.
צריכה למזער את הרעש של אות האודיו במתמרים במכשיר, כולל מיד לאחר ההפעלה במצב התחלתי (cold start).
אמור להיות אפס הבדל בשעון האודיו בין צד הקלט לצדדים של הפלט נקודות הקצה התואמות, כששתיהן פעילות. דוגמאות לתאימות נקודות הקצה (endpoints) כוללות את המיקרופון והרמקול במכשיר או את הקלט של שקע האודיו ופלט.
צריכה לטפל בקריאות חוזרות (callback) של השלמת מאגר הנתונים הזמני של הקלט ופלט נקודות הקצה המקבילות באותו שרשור כששתיהן פעילות, ומזינים הקריאה החוזרת של הפלט מיד אחרי החזרה מהקריאה החוזרת של הקלט. או אם לא ניתן לטפל בקריאות החוזרות (callback) באותו שרשור, יש להזין את פלט קריאה חוזרת (callback) זמן קצר לאחר הזנת הקריאה החוזרת של הקלט כדי לאפשר כך שיהיה תזמון עקבי של צד הקלט והפלט.
אמור לצמצם את הפרש המופעים בין אגירת אודיו של HAL בקלט ואת צדי הפלט של נקודות הקצה התואמות.
צריכה למזער את זמן האחזור של המגע.
צריכה למזער את ההשתנות של זמן האחזור של המגע במקרה של עומס (רעידות).
סיום הדרישות החדשות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם ההטמעות של מכשירים עומדות בכל הדרישות שפורטו למעלה, הן:
- [C-SR-4] מומלץ מאוד לדווח על תמיכה בתכונה
android.hardware.audio.pro
דרךandroid.content.pm.PackageManager
בכיתה.
סיום הדרישות החדשות
אם בהטמעות המכשיר יש שקע אודיו עם 4 מוליכים בגודל 3.5 מ"מ, הן:
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-2-1] חייבת להיות זמן אחזור ממוצע של אודיו הלוך ושוב ברציף, כפי שמוגדר ב- קטע 5.6 זמן אחזור אודיו, של 20 אלפיות שנייה או פחות, יותר מ-5 מדידות עם סטייה אבסולוטית ממוצעת של פחות מ-5 אלפיות השנייה את הנתיב של שקע האודיו באמצעות מתאם אודיו בלופ.
סיום הדרישות החדשות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-2-2]
[C-SR-5]מומלץ מאודחובה יש לפעול בהתאם לסעיף מפרטי מכשירים ניידים (שקע) של מפרט אוזניות האודיו החוטיות (גרסה 1.1).
סיום הדרישות החדשות
אם בהטמעות המכשיר משמיטים שקע אודיו של 4 מוליך בגודל 3.5 מ"מ וגם כוללות יציאות USB שתומכות במצב מארח USB, והן:
- [C-3-1] חובה להטמיע את סיווג האודיו ב-USB.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-3-2] זמן האחזור הממוצע של אודיו הלוך ושוב ברציפות הוא רציף 25 אלפיות השנייה או פחות, יותר מ-5 מדידות עם סטייה אבסולוטית ממוצעת פחות מ-5 אלפיות השנייה מהיציאה של מצב מארח ב-USB באמצעות סיווג אודיו ב-USB. (ניתן למדוד זאת באמצעות מתאם USB-3.5 מ"מ ורמקול עם לולאה חוזרת (loopback) מתאם או שימוש בממשק אודיו ב-USB עם כבלי תיקון שמחברים את של הקלט לפלט).
- [C-SR-6] מומלץ מאוד לתמוך בקלט/פלט (I/O) בו-זמנית בעד 8 ערוצים כל כיוון, תדירות דגימה של 96kHz ועומק של 24 ביט או 32 ביט עם ציוד היקפי בחיבור USB שתומך גם בדרישות האלה.
- [C-SR-7] מומלץ מאוד לעמוד בקבוצת הדרישות הזו בעזרת ממשק ה-API של אודיו מקורי של אודיו דרך נתיב ה-MMAP.
סיום הדרישות החדשות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם בהטמעות במכשירים יש יציאת HDMI:
- אמורה לתמוך בפלט בסטריאו ובשמונה ערוצים במהירות של 20 סיביות עומק של 24 ביט ו-192kHz ללא אובדן או דגימה מחדש של עומק הסיביות בהגדרה אחת לפחות.
סיום הדרישות החדשות
5.11. צילום למכשירים לא מעובדים
Android כולל תמיכה בהקלטת אודיו לא מעובד באמצעות
מקור האודיו android.media.MediaRecorder.AudioSource.UNPROCESSED
. לחשבון
OpenSL ES, ניתן לגשת אליה באמצעות ההגדרה הקבועה מראש של הרשומה
SL_ANDROID_RECORDING_PRESET_UNPROCESSED
אם המכשיר מיישם הכוונה לתמוך במקור אודיו לא מעובד ולהבטיח לאפליקציות צד שלישי, הן:
[C-1-1] חובה לדווח על התמיכה דרך
android.media.AudioManager
נכס PROPERTY_SUPPORT_AUDIO_SOURCE_UNProcessED.[C-1-2] חובה להציג תדירות של משרעת (אמפליטודה) שטוחה (לעומת זאת) בערך מאפיינים בטווח התדרים הבינוני: במיוחד ±10 dB החל 100 Hz עד 7,000 Hz לכל מיקרופון שמשמש להקלטת מקור האודיו.
[C-1-3] חובה להציג את רמות המשרעת בתדר הנמוך טווח: במיוחד בין ±20dB מ-5 z עד 100 Hz בהשוואה טווח התדרים עבור כל מיקרופון שמשמש להקלטת מקור אודיו שלא עבר עיבוד.
[C-1-4] חייבים להציג את רמות המשרעת בתדירות גבוהה טווח: במיוחד בין ±30dB מ-7,000 Hz עד 22 KHz, בהשוואה טווח התדרים עבור כל מיקרופון שמשמש להקלטת מקור אודיו שלא עבר עיבוד.
[C-1-5] חובה להגדיר את הרגישות לקלט האודיו, כך מקור הצליל שמושמע בעוצמה של 94 דציבלים ברמת לחץ הקול (SPL) מניב תגובה עם RMS של 520 לדגימות של 16 ביט (או -36 dB התאמה מלאה לנקודה צפה/כפולה לספק דגימות דיוק) לכל מיקרופון שמשמש להקלטת מקור האודיו.
[C-1-6] חייב להיות יחס אות לרעש (SNR) ב-60 דציבלים ומעלה עבור כל מיקרופון שמשמש להקלטת מקור האודיו הלא מעובד. (בעוד ש-SNR נמדדת כהפרש בין 94 dB SPL לבין המקבילה SPL של רעש עצמי, שקלול A).
[C-1-7] הערך של עיוות הרמוני (THD) חייב להיות קטן מ- 1% עבור 1 kHZ ב- 90 dB SPL רמת קלט בכל מיקרופון שנעשה בו שימוש להקליט את מקור האודיו הלא מעובד.
[C-1-8] אסור שיהיה עיבוד אותות אחר (למשל, רווח אוטומטי שליטה, מסנן מעבר גבוה או ביטול הד) בנתיב שאינו ברמה הרצויה כדי להעלות את הרמה לטווח הרצוי. במילים אחרות:
- [C-1-9] אם קיים בארכיטקטורה עיבוד אותות כלשהו מסיבה זו, חייבים להשבית אותו ולהציג באופן אפקטיבי אפס עיכוב זמן אחזור נוסף לנתיב האות.
- [C-1-10] מכפיל הרמות, אף על פי שהוא מותר בנתיב, אסור הוספת עיכוב או זמן אחזור בנתיב האות.
כל מדידות ה-SPL מתבצעות ישירות ליד המיקרופון בבדיקה. הדרישות האלה חלות על כמה הגדרות מיקרופון בכל מיקרופון.
אם בהטמעות המכשיר מוצהר על android.hardware.microphone
אבל לא
תומכים במקור אודיו לא מעובד, הם:
- [C-2-1] חייב להחזיר
null
לAudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)
API, כדי לציין כראוי את היעדר התמיכה. - [C-SR-1] עדיין מומלץ מאוד למלא כמה שיותר מהדרישות לנתיב האות של מקור ההקלטה שלא עבר עיבוד.
5.12. סרטון HDR
ב-Android 13 יש תמיכה בטכנולוגיות HDR, כפי שמתואר במסמך שיפורסם בקרוב.
פורמט הפיקסלים
אם מפענח וידאו מפרסם תמיכה ב-color_FormatYUVP010:
[C-1-1] חייבת לתמוך בפורמט P010 לקריאת מעבד (CPU) (ImageReader, MediaImage, ). ב-Android 13, P010 פועל בצורה רגועה כדי לאפשר צעדים שרירותיים עבור ה-Y ומתקני קרינת UV.
[C-1-2] חובה לאפשר ל-GPU לדגום את מאגר הפלט של P010 (כאשר שהוקצה עם שימוש ב-GPU_SAMPLING). כך מתאפשרת הרכבה של GPU והתאמה אישית למיפוי טונים של אפליקציות.
אם מפענח וידאו מפרסם תמיכה ב-COLOR_Format32bitABGR2101010, הוא:
- [C-2-1] חייבת לתמוך בפורמט RGBA_1010102 לשטח הפלט קריא למעבד (CPU) (פלט ByteBuffer).
אם מקודד וידאו מפרסם תמיכה ב-COLOR_FormatYUVP010, הוא:
- [C-3-1] חייבת להיות תמיכה בפורמט P010 למשטח קלט ולניתנת לכתיבה באמצעות מעבד (CPU) קלט (ImageWriter, MediaImage, ByteBuffer).
אם מקודד וידאו מפרסם תמיכה ב-COLOR_Format32bitABGR2101010, הוא:
- [C-4-1] חייב לתמוך בפורמט RGBA_1010102 עבור משטח קלט ומעבד (CPU) שניתן לכתיבה קלט (ImageWriter, ByteBuffer). הערה: המרה בין סוגים שונים של העברות במקודדים אין צורך בעקומות.
דרישות לצילום HDR
בכל מקודדי הווידאו שתומכים בפרופילים של HDR:
[C-5-1] אסור להניח שהמטא-נתונים של HDR מדויקים. לדוגמה, במסגרת המקודדת יכולים להיות פיקסלים מעבר לרמת ההארה המקסימלית, או ייתכן שההיסטוגרמה לא מייצגת את המסגרת.
צריך לצבור מטא-נתונים דינמיים של HDR כדי ליצור נתונים סטטיים מתאימים של HDR מטא-נתונים עבור שידורים מקודדים, והפלט צריך להיות בסוף כל בהפעלת הקידוד.
אם בהטמעות של המכשיר יש תמיכה בצילום HDR באמצעות ממשקי ה-API של CamcorderProfile ואז:
[C-6-1] חייבת להיות תמיכה בצילום תמונות HDR גם דרך ממשקי ה-API של Camera2.
[C-6-2] חייב לתמוך לפחות במקודד וידאו אחד עם שיפור מהירות באמצעות חומרה עבור כל טכנולוגיית HDR שנתמכת.
[C-6-3] חייבת להיות תמיכה (לכל הפחות) בצילום בפורמט HLG.
[C-6-4] חייבת להיות תמיכה בכתיבת המטא-נתונים של HDR (אם רלוונטי ל-HDR) טכנולוגית) לקובץ הווידאו שתועד. ל-AV1, ל-HEVC ול-DolbyVision כלומר, כוללים את המטא-נתונים בסטרימינג הביטים המקודד.
[C-6-5] חייבת לתמוך ב-P010 וב-COLOR_FormatYUVP010.
[C-6-6] כברירת מחדל חייבת להיות תמיכה ב-HDR למיפוי גוונים של SDR למפענח עם שיפור מהירות באמצעות חומרה לפרופיל שתועד. במילים אחרות, אם מכשיר יכול לצלם HDR10+ HEVC, מפענח HEVC שמוגדר כברירת מחדל חייב להיות מסוגל כדי לפענח את השידור שתועד ב-SDR.
דרישות לעריכת HDR
אם ההטמעות במכשירים כוללים מקודדי וידאו שתומכים בעריכת HDR, הם:
- יש להשתמש בזמן אחזור מינימלי ליצירת מטא-נתונים של HDR כשהם לא נמצאים, והם צריכים לטפל באלגנטיות במצבים שבהם המטא-נתונים קיימים ולא של אחרים. המטא-נתונים צריכים להיות מדויקים (לדוגמה, שמייצגים את רמת הבהירות וההיסטוגרמה בפועל של המסגרת).
אם הטמעת המכשיר כוללת רכיבי קודק שתומכים ב-FEATURE_HdrEditing
, אז
את רכיבי הקודק האלה:
[C-7-1] חייב לתמוך בפרופיל HDR אחד לפחות.
[C-7-2] חובה לתמוך ב-
FEATURE_HdrEditing
בכל פרופילי HDR שפורסמו על ידי את הקודק הזה. במילים אחרות, הם חייבים לתמוך ביצירת מטא-נתונים של HDR לא קיים בכל פרופילי HDR הנתמכים שמשתמשים במטא-נתונים של HDR.[C-7-3] חייב לתמוך בפורמטים הבאים של קלט מקודד וידאו, לשמר את האות המפוענח ל-HDR:
- RGBA_1010102 (כבר בעקומת העברת היעד) לשני הקלט ו-ByteBuffer ו-ByteBuffer חייבות לפרסם תמיכה עבור Color_Format32bitABGR2101010.
אם הטמעת המכשיר כוללת רכיבי קודק שתומכים ב-FEATURE_HdrEditing, אז המכשיר:
- [C-7-4] חובה לפרסם תמיכה לתוסף OpenGL מסוג EXT_YUV_target.
6. תאימות לכלים למפתחים ולאפשרויות
6.1. כלים למפתחים
הטמעות מכשירים:
- [C-0-1] חייבת לתמוך בכלים למפתחי Android שמסופקים ב-Android SDK.
- גשר לניפוי באגים ב-Android (adb)
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-0-2] חייבת לתמוך ב-adb כפי שמתועד ב-Android SDK ובמעטפת
ב-AOSP, שיכולות לשמש מפתחי אפליקציות
כולל
dumpsys
,cmd stats
, וגם Simpleperf.
סיום הדרישות החדשות
- [C-0-11] חייבת לתמוך בפקודת המעטפת
cmd testharness
. מתבצע שדרוג במכשירים מגרסה קודמת של Android ללא ייתכן שחסימת נתונים מתמידים תהיה פטורה מקוד C-0-11. - [C-0-3] אסור לשנות את הפורמט או את התוכן של מערכת המכשיר אירועים (batterystats, דיסקסטטים, טביעת אצבע, גרפיקה סטטיסטיים, netstats, התראה, Procstats) שתועדה באמצעות הפקודה dumpsys.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-0-10] חובה להקליט, ללא השמטת נתונים, ולבצע את האירועים הבאים
וזמין לפקודת המעטפת
cmd stats
StatsManager
מחלקה של System API.- הפעילות בחזית שונתה
- זוהתה חריגה
- נשלח דיווח על מיקום באתר
- AppCrashOccurred
- AppStartOccurred
- רמת הסוללה שונתה
- הסוללהSaverModeStateChanged
- BleScanresultReceived
- BleScanStateChanged
- ChargingStateChanged
- DeviceIdleModeStateChanged
- ForegroundServiceStateChanged
- GpsScanStateChanged
- InputDeviceשימוש שדווח
- JobStateChanged (שינוי מצב המשימה)
- מקלדת
- מקלדתSystemsEventReported
- PluggedStateChanged
- משימות מתוזמנות
- ScreenState השתנה
- SyncStateChanged
- זמן אמת ב-SystemElapse
- שימוש בלוח מגע
- UidProcessStateChanged
- מצב WakelockState השתנה
- מעורר התעוררות
- מצב Wi-FiLockState השתנה
- WifiMulticastLockStateChange
- מצב WifiScanState השתנה
סיום הדרישות החדשות
- [C-0-4] דימון (daemon) בצד המכשיר חייב להיות לא פעיל כברירת מחדל כדי להפעיל את ניפוי הבאגים ב-Android חייב להיות מנגנון נגיש למשתמש גשר.
- [C-0-5] חייבת לתמוך ב-adb מאובטח. Android כולל תמיכה באבטחה adb. פרוטוקול adb מאובטח מאפשר הפעלה של adb במארחים מאומתים מוכרים.
- [C-0-6] חייב לספק מנגנון שמאפשר לחבר את adb במחשב המארח. פרטים נוספים:
אם הטמעות של מכשירים ללא יציאת USB תומכות במצב היקפי:
- [C-3-1] חובה להטמיע adb באמצעות רשת מקומית (כמו אתרנט) או Wi-Fi).
- [C-3-2] חובה לספק מנהלי התקנים עבור Windows 7, Windows 8 ו-10, כדי לאפשר למפתחים להתחבר למכשיר באמצעות פרוטוקול adb.
אם בהטמעות של מכשירים יש תמיכה בחיבורי adb למכונה מארחת דרך ב-Wi-Fi או באתרנט, הן:
- [C-4-1] חייבת להשתמש בשיטה
AdbManager#isAdbWifiSupported()
החזרהtrue
.
אם בהטמעות של מכשירים יש תמיכה בחיבורי adb למכונה מארחת דרך Wi-Fi או אתרנט, וכן כולל מצלמה אחת לפחות, הם:
- [C-5-1] חייבת להשתמש בשיטה
AdbManager#isAdbWifiQrSupported()
החזרהtrue
.
Dalvik Debug Monitor Service (ddms)
- [C-0-7] חייבת להיות תמיכה בכל תכונות ה-ddms כפי שמתואר ב-Android SDK. מכיוון ש-ddms משתמשים ב-adb, התמיכה ב-ddms אמורה להיות לא פעילה כברירת מחדל, אבל חייבת להיות תמיכה בכל פעם שהמשתמש הפעיל את ממשק ה-Fגשר של Android לניפוי באגים, כמתואר למעלה.
-
- [C-0-9] חייבת לתמוך בכלי ה-systrace כפי שתועד ב-Android SDK. Systrace חייבת להיות לא פעילה כברירת מחדל וחייב להיות נגיש למשתמש מנגנון להפעלת Systrace.
-
- [C-SR-1] מומלץ מאוד לחשוף
/system/bin/perfetto
בינארית למשתמש המעטפת ש-cmdline פועל את התיעוד של Perfetto. - [C-SR-2] מומלץ מאוד לקבל את הקובץ הבינארי שמוגדר כקלט תצורת protobuf שתואמת לסכימה שמוגדרת ואת מסמכי התיעוד.
- [C-SR-3] מומלץ מאוד לכתוב את הקוד הבינארי שמוגדר כפלט מעקב Protobuf התואם לסכימה המוגדרת ואת מסמכי התיעוד.
- [C-SR-4] מומלץ מאוד לספק באמצעות הקובץ הבינארי Perfetto, לפחות את מקורות הנתונים שמתוארים בתיעוד Perfetto.
- [C-SR-1] מומלץ מאוד לחשוף
-
- [C-0-12] חובה לכתוב Atom מסוג
LMK_KILL_OCCURRED_FIELD_NUMBER
רישום נתונים סטטיסטיים כשאפליקציה מסתיימת על ידי Low Memory Killer.
- [C-0-12] חובה לכתוב Atom מסוג
מצב 'מסגרת בדיקה' אם הטמעות המכשיר תומכות בפקודת המעטפת
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 שהוחזרו על ידי הליבה (kernel) של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 מופעלות, ספירת השכבות היא ספריות שסופקו על ידי כלים חיצוניים (כלומר, לא חלק מהפלטפורמה או 'חבילת אפליקציה') נמצאה באפליקציות שניתנות לניפוי באגים ליצור ספרייה בסיסית של תמיכה ב-vkEnumerateInstanceLayerProperties() ו-vkCreateInstance() שיטות API.
6.2. אפשרויות למפתחים
Android כולל תמיכה במפתחים להגדרת אפליקציה שקשורות לפיתוח.
הטמעת מכשירים חייבת לספק חוויה עקבית אפשרויות למפתחים:
- [C-0-1] חייבים לכבד את android.settings.APPLICATION_DEVELOPMENT_SETTINGS כוונה להציג הגדרות שקשורות לפיתוח של אפליקציות. Android בהמשך הדרך מסתיר את תפריט 'אפשרויות למפתחים' כברירת מחדל ומאפשר למשתמשים להפעיל את 'אפשרויות למפתחים' אחרי לחיצה שבע (7) פעמים בתפריט Settings (הגדרות) > מידע על המכשיר > האפשרות מספר Build בתפריט.
- [C-0-2] חובה להסתיר את 'אפשרויות למפתחים' כברירת מחדל.
- [C-0-3] חייב לספק מנגנון ברור שלא נותן העדפה טיפול באפליקציה אחת של צד שלישי בניגוד לאפליקציה אחרת כדי לאפשר למפתח אפשרויות. חייבים לספק מסמך או אתר גלויים לכולם שמתארים איך להפעיל את 'אפשרויות למפתחים'. חובה לאפשר קישור למסמך או לאתר הזה מ- מסמכי Android SDK.
- צריכה להיות התראה ויזואלית מתמשכת למשתמש כשהמפתח האפשרויות מופעלות ויש חשש לגבי אבטחת המשתמש.
- ייתכן שנגביל באופן זמני את הגישה לתפריט 'אפשרויות למפתחים', באופן חזותי להסתיר או להשבית את התפריט, כדי למנוע הסחות דעת במקרים שבהם בטיחות המשתמש.
7. תאימות חומרה
אם המכשיר כולל רכיב חומרה מסוים שיש לו API למפתחים של צד שלישי:
- [C-0-1] הטמעת המכשיר חייבת להטמיע API כפי שמתואר בתיעוד של Android SDK.
אם מדובר בממשק API ב-SDK מקיים אינטראקציה עם רכיב חומרה שמצוין לגביו שהוא אופציונלי המכשיר לא כולל את הרכיב הזה:
- [C-0-2] צריך למלא את הגדרות הכיתה (כפי שמתועד על ידי ה-SDK) של הרכיב ממשקי API עדיין חייבים להיות מוצגים.
- [C-0-3] חובה להטמיע את ההתנהגויות של ה-API כפעולות ללא תפעול אופנה.
- [C-0-4] שיטות API חייבות להחזיר ערכי null כאשר ה-SDK מאפשר זאת התיעוד.
- [C-0-5] שיטות API חייבות להחזיר הטמעות ללא תפעול של מחלקות שבהן ערכי null אסורים לשימוש במסמכי התיעוד של ה-SDK.
- [C-0-6] שיטות API לא יכולות להקפיץ חריגות שלא תועדו על ידי ה-SDK התיעוד.
- [C-0-7] הטמעות של מכשירים חייבות לדווח באופן עקבי על חומרה מדויקת
הגדרות אישיות דרך
getSystemAvailableFeatures()
hasSystemFeature(String)
ב- android.content.pm.PackageManager לאותה טביעת אצבע של build.
דוגמה אופיינית לתרחיש שבו הדרישות האלה חלות: מערכת טלפוניה API: גם במכשירים שאינם טלפונים, יש להטמיע את ממשקי ה-API באופן סביר אין תפעול.
7.1. תצוגה וגרפיקה
ב-Android יש מתקנים שמתאימים באופן אוטומטי נכסי אפליקציות וממשק משתמש המתאימה למכשיר כדי להבטיח שאפליקציות של צד שלישי פועלות היטב במגוון רחב של צגי חומרה ותצורות. מסך התואם ל-Android הוא מסך תצוגה שמטמיע את כל התנהגויות וממשקי API שמתוארים במאמר מפתחי Android – תאימות למסכים סקירה כללית, (7.1) וסעיפי המשנה שלו, וגם כל סוג מכשיר נוסף וההתנהגויות הספציפיות שמפורטות בקטע 2 CDD.
הטמעות מכשירים:
- [C-0-1] חובה, כברירת מחדל, לעבד אפליקציות של צד שלישי רק מסכים שתואמים ל-Android.
היחידות שמוזכרות בדרישות בסעיף הזה מוגדרות כך:
- גודל אלכסון פיזי. המרחק באינצ'ים בין שני צבעים מנוגדים הפינות של החלק המואר של המסך.
- צפיפות. מספר הפיקסלים המוקפים על ידי קו ליניארי טווח אופקי או אנכי של 1 אינץ', מבוטא כפיקסלים לאינצ' (PPI או dpi). כשמופיעים ערכי PPI ו-DPI גם dpi אופקי וגם אנכי חייבים להיות בטווח הרשום.
- יחס גובה-רוחב. היחס בין הפיקסלים של המימד הארוך יותר מידות קצרות יותר של המסך. לדוגמה, תצוגה של 480x854 פיקסלים להיות 854/480 = 1.779, או בערך 16:9.
- פיקסל בלתי תלוי בדחיסות (dp). יחידת פיקסל וירטואלי מנורמלת לצפיפות מסך של 160. בשביל צפיפות מסוימת, d ומספר פיקסלים p, מספר הפיקסלים הבלתי תלויים בדחיסות dp, מחושב כך: dp = (160 / d) * p.
7.1.1. הגדרת המסך
7.1.1.1. הגודל והצורה של המסך
ה-framework של ממשק המשתמש של Android תומך במגוון של פריסת מסך לוגית
גדולים, ומאפשר לאפליקציות לשלוח שאילתות על המסך של התצורה הנוכחית
גודל הפריסה דרך Configuration.screenLayout
עם SCREENLAYOUT_SIZE_MASK
ו-Configuration.smallestScreenWidthDp
.
הטמעות מכשירים:
[C-0-1] חובה לדווח על גודל הפריסה הנכון
Configuration.screenLayout
כפי שמוגדר במסמכי התיעוד של Android SDK. באופן ספציפי, הטמעות במכשירים חייבות לדווח על הלוגיקה הנכונה מידות המסך של פיקסלים שלא תלויים בדחיסות (dp) כפי שמפורט בהמשך:- מכשירים שבהם מוגדר
Configuration.uiMode
בתור כל ערך מלבד UI_מצב_TYPE_WATCH, ודיווח על גודלsmall
עבורConfiguration.screenLayout
, חייב להיות לפחות 426 dp x 320 dp. - מכשירים שמדווחים על גודל של
normal
עבורConfiguration.screenLayout
, חייבת להיות לפחות 480 dp x 320 dp. - מכשירים שמדווחים על גודל של
large
עבורConfiguration.screenLayout
, חייב להיות לפחות 640 dp x 480 dp. - מכשירים שמדווחים על גודל של
xlarge
עבורConfiguration.screenLayout
, חייב להיות לפחות 960 dp x 720 dp.
- מכשירים שבהם מוגדר
[C-0-2] חובה לציית בצורה נכונה לבקשות מוצהר תמיכה בגדלי מסכים באמצעות <
supports-screens
> בקובץ AndroidManifest.xml, כפי שמתואר בתיעוד של Android SDK.ב-MAY יש מסכים שתואמים ל-Android עם פינות מעוגלות.
אם בהטמעות במכשירים יש תמיכה במסכים שאפשר לבצע בהם
הגדרת הגודל של UI_MODE_TYPE_NORMAL
ולהשתמש במסכים פיזיים עם פינות מעוגלות כדי לעבד את המסכים האלה.
הם:
[C-1-1] חובה לוודא שלפחות אחת מהדרישות הבאות בכל אחד מהתצוגות הבאות:
- הרדיוס של הפינות המעוגלות קטן מ-38dp או שווה לו.
- כאשר תיבה בגודל 18dp של 18dp מעוגנת לכל פינה של מסך, לפחות פיקסל אחד מכל תיבה גלוי במסך.
צריכה לכלול את התקציב של המשתמש לעבור למצב תצוגה עם פינות מלבניות.
אם אפשר ליישם במכשירים רק אפשרות של הגדרת מקלדת NO_KEYS
,
והם מתכוונים לדווח על תמיכה במצב ממשק המשתמש של UI_MODE_TYPE_NORMAL
שלהם:
- [C-4-1] גודל הפריסה חייב להיות לפחות לא כולל גזירי מסך 596 dp x 384 dp או יותר.
לפרטים על הטמעה נכונה של ממשקי ה-API המשניים או של התוספים, קראו את המאמר למסמכי התיעוד הציבוריים של Window Manager Jetpack.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם ההטמעות במכשירים כוללות אזור תצוגה אחד או יותר שתואם ל-Android שניתן לקפל, או לכלול ציר מתקפל בין מכשירים אזורי תצוגה שתואמים ל-Android והפיכת אזורי התצוגה לזמינים עבור אפליקציות, הן:
- [C-4-1] חובה להטמיע את הגרסה הנכונה של התוספים לניהול חלונות רמת ה-API, כפי שמתואר בתוספים של Windows Manager.
סיום הדרישות החדשות
7.1.1.2. יחס גובה-רוחב של המסך
הקטע הזה נמחק ב-Android 14.
7.1.1.3. דחיסות מסך
מסגרת ממשק המשתמש של Android מגדירה קבוצה של דחיסות לוגיות סטנדרטיות כדי לסייע מפתחי אפליקציות מטרגטים משאבי אפליקציות.
הטמעות של מכשירים:
[C-0-1] חובה לדווח על אחת מדחיסות המסגרת של Android שמפורטות ב-
DisplayMetrics
באמצעות ה-API שלDENSITY_DEVICE_STABLE
והערך הזה חייב להיות ערך סטטי לכל תצוגה פיזית. עם זאת, המכשיר עשוי דיווח עלDisplayMetrics.density
אחר בהתאם לשינויים בתצורת התצוגה שהמשתמש ביצע (עבור לדוגמה, גודל התצוגה) שהוגדר לאחר האתחול הראשוני.צריך להגדיר את צפיפות המסגרת הסטנדרטית של Android, שמבוססת על מספרים הקרוב ביותר לצפיפות הפיזית של המסך, או ערך שניתן למפות אותן מדידות של שדה ראייה שוות ערך למכשיר נישא.
אם יישומים של מכשירים מאפשרים לקנות משנים את גודל התצוגה של המכשיר, הם:
- [C-1-1] אסור שגודל המסך יהיה גדול מפי 1.5
DENSITY_DEVICE_STABLE
או להפיק ממד מסך מינימלי יעיל קטן מ-320dp (שווה ערך) למגדיר המשאבים sw320dp), המוקדם מביניהם. - [C-1-2] אסור לשנות את גודל המסך
קטן מ-0.85 כפול
DENSITY_DEVICE_STABLE
. - כדי להבטיח נוחות שימוש טובה וגודל עקבי של הגופנים, מומלץ
לספק את ההתאמה לעומס (scaling) של אפשרויות התצוגה המותאמת (תוך עמידה במגבלות)
שצוין למעלה)
- קטנה: 0.85x
- ברירת מחדל: 1x (קנה מידה של תצוגה מותאמת)
- גדול: פי 1.15
- גדול יותר: פי 1.3
- הגדול ביותר: 1.45x
7.1.2. מדדי פרסום ברשת המדיה
אם הטמעות המכשירים כוללות מסכים שתואמים ל-Android או פלט וידאו למסכי תצוגה שתואמים ל-Android, הם:
- [C-1-1] חובה לדווח על הערכים הנכונים בכל המסכים שתואמים ל-Android
שמוגדרים
android.util.DisplayMetrics
API.
אם ההטמעות במכשירים לא כוללות מסך מוטמע או פלט וידאו מוטמע, הם:
- [C-2-1] חובה לדווח על הערכים הנכונים במסך התואם ל-Android
כפי שמוגדר ב-API
android.util.DisplayMetrics
לברירת המחדלview.Display
של אמולציה.
7.1.3. כיוון מסך
הטמעות מכשירים:
- [C-0-1] חובה לדווח על כיווןי המסך הנתמכים
(
android.hardware.screen.portrait
ו/אוandroid.hardware.screen.landscape
) וחובה לדווח על אירוע נתמך אחד לפחות לכיוון מסוים. לדוגמה, מכשיר בכיוון קבוע לרוחב מסך, כמו טלוויזיה או מחשב נייד, לדיווח עלandroid.hardware.screen.landscape
. - [C-0-2] חובה לדווח על הערך הנכון של הערך הנוכחי של המכשיר
של הסרטון, בכל פעם שמתקבלת שאילתה דרך
android.content.res.Configuration.orientation
,android.view.Display.getOrientation()
או ממשקי API אחרים.
אם בהטמעות של מכשירים יש תמיכה בשני הכיוונים של המסך:
- [C-1-1] חייבת לתמוך בכיוון דינמי באמצעות אפליקציות במסך לאורך או לרוחב לכיוון מסוים. כלומר, המכשיר חייב להיענות לבקשה של האפליקציה עבור מסך ספציפי לכיוון מסוים.
- [C-1-2] אסור לשנות את גודל המסך או את הצפיפות שמדווחים כשמשנים את הכיוון.
- ייתכן שברירת המחדל היא 'לאורך' או 'לרוחב'.
7.1.4. האצת גרפיקה דו-ממדית ותלת-ממדית
7.1.4.1. OpenGL ES
הטמעות מכשירים:
- [C-0-1] חייב לזהות בצורה נכונה את הגרסאות הנתמכות של OpenGL ES (1.1, 2.0,
3.0, 3.1, 3.2) באמצעות ממשקי ה-API המנוהלים (למשל באמצעות
GLES10.getString()
) וממשקי ה-API המקוריים. - [C-0-2] חייבת לכלול תמיכה בכל ממשקי ה-API המנוהלים המתאימים, וגם ממשקי API מקוריים לכל גרסת OpenGL ES שבה הן זיהו שתומכות.
אם הטמעות במכשירים כוללות פלט מסך או פלט וידאו:
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-1-1] חייבת לתמוך
בשניהםOpenGL ES 1.1,ו-2.0, 3.0 ו-3.1 כמו מובנה ומפורט במסמכי התיעוד של Android SDK.
סיום הדרישות החדשות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-SR-1] מומלץ מאוד לתמוך ב-OpenGL ES 3.1.
סיום הדרישות החדשות
- צריכה לתמוך ב-OpenGL ES 3.2.
בדיקות dEQP של OpenGL ES מחולקות למחיצות למספר רשימות של בדיקות, כל אחת עם
תאריך/מספר גרסה משויך. הנתונים האלה נמצאים בעץ המקור של Android ב-
external/deqp/android/cts/main/glesXX-master-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] חובה לעבור את כל בדיקות ה-GL ES dEQP של OpenGL ES dEQP ברשימות הבדיקה בין הגרסאות
132383489 והגרסה שצוינה
סימון תכונה
android.software.opengles.deqp.level
, לכל אחד מהסוגים הנתמכים גרסת OpenGL ES. - [C-SR-2] מומלץ מאוד לתמוך ב-
EGL_KHR_partial_update
OES_EGL_image_external
תוספים. אמור לדווח באופן מדויק באמצעות השיטה
getString()
, כל טקסטורה או בפורמט הדחיסה שבו הם תומכים, שהוא בדרך כלל ספציפי לספק.צריכה לתמוך ב-
EGL_IMG_context_priority
וב-EGL_EXT_protected_content
תוספים.
אם הטמעות המכשיר מצהירות על תמיכה ב-OpenGL ES בגרסה 3.0, 3.1 או 3.2:
- [C-3-1] חובה לייצא את סמלי הפונקציות התואמים של הגרסה הזו בנוסף לסמלי הפונקציה OpenGL ES 2.0 בספרייה libGLESv2.so.
- [C-SR-3] מומלץ מאוד לתמוך ב-
OES_EGL_image_external_essl3
לתוסף.
אם בהטמעות במכשירים תומכים ב-OpenGL ES 3.2, הן:
- [C-4-1] חייבת לתמוך בחבילת התוספים ל-Android של OpenGL ES ל-Android בשלמותה.
אם בהטמעות המכשיר תומכות בחבילת התוספים ל-Android של OpenGL ES כלל, הם:
- [C-5-1] חובה לזהות את התמיכה דרך
android.hardware.opengles.aep
דגל של פיצ'ר.
אם הטמעות של מכשירים חושפות את התמיכה ב-EGL_KHR_mutable_render_buffer
הם:
- [C-6-1] חייבת לתמוך ב-
EGL_ANDROID_front_buffer_auto_refresh
לתוסף.
7.1.4.2. וולקן
Android כולל תמיכה ב-Vulkan, ממשק API עם תקורה נמוכה המשתמש בפלטפורמות שונות לגרפיקה תלת-ממדית בעלת ביצועים גבוהים.
אם בהטמעות במכשירים תומכים ב-OpenGL ES 3.1, הן:
- [C-SR-1] מומלץ מאוד לכלול תמיכה בנושא Vulkan 1.3.
- [C-4-1] אסור לתמוך בגרסת וריאנט של Vulkan (כלומר, וריאנט) חלק מגרסת הליבה של Vulkan חייב להיות אפס).
אם הטמעות במכשירים כוללות פלט מסך או פלט וידאו:
- [C-SR-2] מומלץ מאוד לכלול תמיכה בנושא Vulkan 1.3.
בדיקות dEQP של Vulkan מחולקות למחיצות (Partitions) לכמה רשימות של בדיקות, כל אחת עם
תאריך/גרסה שמשויכים אליה. הנתונים האלה נמצאים בעץ המקור של Android ב-
external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt
מכשיר
שתומך ב-Vulkan ברמת דיווח עצמי, מציין שהוא יכול לעבור את ה-dEQP
בדיקות בכל רשימות הבדיקה מהרמה הזו ומגרסאות קודמות.
אם הטמעות המכשירים כוללות תמיכה ב-Vulkan:
- [C-1-1] חובה לדווח על הערך הנכון של המספר השלם באמצעות הפונקציה
android.hardware.vulkan.level
ו-android.hardware.vulkan.version
דגלים בפיצ'ר. - [C-1-2] חובה לספור, לפחות
VkPhysicalDevice
אחד עבור ה-Vulkan Native APIvkEnumeratePhysicalDevices()
. - [C-1-3] חובה להטמיע באופן מלא את ממשקי ה-API של Vulkan 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] חובה לדווח על הגרסה המקסימלית של בדיקות dEQP של Vulkan
נתמך באמצעות התכונה הניסיונית
android.software.vulkan.deqp.level
. - [C-1-9] חייבת להיות תמיכה לפחות בגרסה
132317953
(החל מ-1 במרץ 2019) בתור דווחו בדגל התכונהandroid.software.vulkan.deqp.level
. - [C-1-10] חובה לעבור את כל בדיקות ה-dEQP של Vulkan ברשימות הבדיקות בין
גרסה
132317953
והגרסה שמצוינת דגלandroid.software.vulkan.deqp.level
של תכונה. - [C-1-11] אסור לציין תמיכה במימד VK_KHR_video_queue תוספי VK_KHR_video_decode_queue או VK_KHR_video_encode_queue
- [C-SR-3] מומלץ מאוד לתמוך ב-
VK_KHR_driver_properties
ו-VK_GOOGLE_display_timing
תוספים. - [C-1-12] אסור לספור תמיכה בתוסף VK_KHR_performance_query.
- [C-SR-4] מומלץ מאוד למלא את הדרישות שצוינו על ידי הפרופיל של Android Baseline 2022.
- [C-SR-5] מומלץ מאוד לתמוך ב-
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
ו-VK_EXT_global_priority
. - [C-SR-6] מומלץ מאוד להשתמש ב-
SkiaVk
עם HWUI.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
אם הטמעות מכשירים כוללות תמיכה ב-Vulkan, הן:
- [C-SR-8] מומלץ מאוד לא לשנות את המטען של Vulkan.
- [C-1-14] אסור לספור תוספים למכשיר Vulkan מסוג "KHR",
"GOOGLE" או "ANDROID" אלא אם התוספים האלה כלולים
סימון תכונה
android.software.vulkan.deqp.level
.
סיום הדרישות החדשות
אם הטמעות במכשירים לא כוללות תמיכה ב-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. האצת גרפיקה דו-ממדית
Android כולל מנגנון שבו אפליקציות יכולות להצהיר שהן דורשות לאפשר האצת חומרה עבור גרפיקה דו-ממדית באפליקציות, פעילות, רמת חלון או רמת תצוגה מפורטת דרך שימוש בתג מניפסט android:hardwareAccelerated או קריאות ישירות ל-API.
הטמעות מכשירים:
- [C-0-1] חייבים להפעיל שיפור מהירות באמצעות חומרה כברירת מחדל, וחובה להשבית את האצת החומרה אם המפתח מבקש זאת על ידי הגדרה android:hardwareAccelerated="false" או השבתה של שיפור המהירות באמצעות חומרה ישירות דרך ממשקי ה-API של Android View.
- [C-0-2] חייבת להראות התנהגות שתואמת מסמכי תיעוד של Android SDK בנושא שיפור המהירות באמצעות חומרה.
Android כולל אובייקט TextureView שמאפשר למפתחים לשלב ישירות טקסטורות של OpenGL ES עם האצת חומרה כיעדי עיבוד בהיררכיית ממשק משתמש.
הטמעות מכשירים:
- [C-0-3] חייבת לתמוך ב-TextureView API, וחייב להופיע התנהגות עקבית עם ההטמעה של Android ב-upstream.
7.1.4.5. מסכים עם טווח רחב
אם בהטמעות במכשירים יש הצהרה על תמיכה במסכים עם טווח רחב דרך
Configuration.isScreenWideColorGamut()
, הן:
- [C-1-1] מסך מכויל בצבע.
- [C-1-2] חייב להיות מסך שטווח הצבעים שלו מכסה את סולם הצבעים sRGB לגמרי בחלל CIE 1931 xyY.
- [C-1-3] חייב להיות מסך שגודלו של המכלול הוא לפחות 90% DCI-P3 במרחב CIE 1931 xyY.
- [C-1-4] חייבת לתמוך ב-OpenGL ES 3.1 או 3.2 ולדווח עליה כמו שצריך.
- [C-1-5] חובה לפרסם תמיכה ב
EGL_KHR_no_config_context
.EGL_EXT_pixel_format_float
,EGL_KHR_gl_colorspace
EGL_EXT_gl_colorspace_scrgb
,EGL_EXT_gl_colorspace_scrgb_linear
,EGL_EXT_gl_colorspace_display_p3
,EGL_EXT_gl_colorspace_display_p3_linear
, ו-EGL_EXT_gl_colorspace_display_p3_passthrough
תוספים. - [C-SR-1] אנחנו ממליצים מאוד לתמוך ב-
GL_EXT_sRGB
.
לעומת זאת, אם הטמעות של מכשירים לא תומכות במסכים עם מטווח רחב:
- [C-2-1] אמור לכסות 100% או יותר מה-sRGB במרחב CIE 1931 xyY, למרות סולם צבעי המסך לא מוגדר.
7.1.5. מצב תאימות לאפליקציה מדור קודם
Android מציין 'מצב תאימות' שבה המסגרת פועלת 'רגיל' מצב שווה ערך לגודל המסך (ברוחב 320dp) לתועלת המודל מדור קודם שלא פותחו לגרסאות ישנות של Android באופן בלתי תלוי בגודל המסך.
7.1.6. טכנולוגיית מסך
פלטפורמת Android כוללת ממשקי API שמאפשרים לאפליקציות לעבד את הגרפיקה לצג תואם Android. המכשירים חייבים לתמוך בכל אלה ממשקי API שהוגדרו על ידי Android SDK, אלא אם הדבר מותר במפורש במסמך הזה.
כל המסכים התואמים ל-Android בהטמעה של מכשיר:
- [C-0-1] חייבת להיות יכולת לעבד גרפיקה צבעונית של 16 ביט.
- אמורה לתמוך במסכים שיכולים להציג גרפיקה צבעונית של 24 ביט.
- [C-0-2] חייבת להיות אפשרות לעבד אנימציות.
- [C-0-3] חייב להיות יחס גובה-רוחב של פיקסל (PAR) בין 0.9 ל-1.15. כלומר, יחס הגובה-רוחב של הפיקסלים חייב להיות קרוב לריבוע (1.0) עם סובלנות של 10 ~ 15%.
7.1.7. מסכים משניים
ב-Android יש תמיכה בהפעלה של מסכים משניים שתואמים ל-Android יכולות שיתוף מדיה וממשקי API למפתחים לגישה למסכים חיצוניים.
אם יישומים של מכשירים תומכים במסך חיצוני באמצעות חיבור קווי, ברשת אלחוטית או בחיבור מסך נוסף מוטמע, הן:
- [C-1-1] חייבים ליישם את המדיניות
DisplayManager
שירות מערכת ו-API כפי שמתואר בתיעוד של Android SDK.
7.2. התקני קלט
הטמעות מכשירים:
- [C-0-1] חייב לכלול מנגנון קלט, כמו מסך מגע או ניווט ללא מגע, כדי לנווט בין הרכיבים של ממשק המשתמש.
7.2.1. מקלדת
אם ההטמעות במכשירים כוללות תמיכה באתרים של צדדים שלישיים באמצעות עורך שיטות קלט (IME), הם:
- [C-1-1] חובה להצהיר על
android.software.input_methods
דגל של פיצ'ר. - [C-1-2] חובה להטמיע את
Input Management Framework
באופן מלא - [C-1-3] חייבת להיות מותקנת מראש מקלדת תוכנה.
הטמעות מכשירים:
- [C-0-1] אסור לכלול מקלדת חומרה שלא תואמת לאחד הפורמטים שצוינו android.content.res.Configuration.keyboard (QWERTY או 12 מקשים).
- אמורות לכלול הטמעות נוספות של מקלדת רכה.
- עשויים לכלול מקלדת חומרה.
7.2.2. ניווט ללא מגע
Android כולל תמיכה בלחצני החיצים (d-pad), כדור עקיבה וגלגל בתור מנגנונים ניווט ללא מגע.
הטמעות מכשירים:
- [C-0-1] חובה לדווח על הערך הנכון עבור android.content.res.Configuration.navigation.
אם בהטמעות במכשירים אין ניווטים ללא מגע, הן:
- [C-1-1] חייב לספק מנגנון סביר של ממשק משתמש חלופי בחירה ועריכה של טקסט, תואמת למנועים לניהול קלט. הטמעת קוד פתוח של Android ב-upstream כוללת מנגנון בחירה מתאים לשימוש במכשירים שאין בהם קלט ניווט ללא מגע.
7.2.3. מקשי ניווט
בדף הבית, תוצאות אחרונות, וחזרה פונקציות שזמינות בדרך כלל באמצעות אינטראקציה עם לחצן פיזי ייעודי או חלק נפרד ממסך המגע, חיוניים פרדיגמת הניווט, ולכן הטמעות מכשירים:
- [C-0-1] חובה לספק למשתמש תקציב להשקת אפליקציות מותקנות
הם מכילים פעילות עם הערך
<intent-filter>
שמוגדר ל-ACTION=MAIN
CATEGORY=LAUNCHER
אוCATEGORY=LEANBACK_LAUNCHER
למכשיר טלוויזיה בפועל. הפונקציה 'בית' צריכה להיות המנגנון לתקציב של המשתמש הזה. - אמורות להיות לחצנים עבור פונקציות 'אחרונים' ו'הקודם'.
אם הפונקציות 'דף הבית', 'אחרונים' או 'חזרה' מסופקות:
- [C-1-1] חייבת להיות נגישות באמצעות פעולה אחת (למשל: הקשה, לחיצה כפולה או תנועה) כשכל אחד מהם נגיש.
- [C-1-2] חייבת לספק אינדיקציה ברורה לגבי הפעולה הבודדת שצריך להפעיל בכל פונקציה. סמל גלוי המוטבע על הלחצן ומוצגת בו תוכנה סמל בסרגל הניווט שמופיע במסך, או מנחה את המשתמש תהליך הגדרה מפורט לסימנים כאלה.
הטמעות מכשירים:
[C-SR-1] מומלץ מאוד לא לספק את מנגנון הקלט פונקציית התפריט כי הוא הוצא משימוש והוחלף בסרגל הפעולות החל מ-Android 4.0.
[C-SR-2] מומלץ מאוד לספק את כל פונקציות הניווט כמו שניתן לבטל. 'ביטול' מוגדרת כיכולת של המשתמש למנוע את פונקציית הניווט מהביצוע (למשל, חזרה לדף הבית, חזרה וכו') אם ההחלקה לא משוחררת מעבר לסף מסוים.
אם הטמעות מכשירים מספקות את פונקציית התפריט, הן:
- [C-2-1] חובה להציג את הלחצן 'אפשרויות נוספות' בכל פעם שהפעולה החלון הקופץ של תפריט האפשרויות הנוספות לא ריק וסרגל הפעולות גלוי.
- [C-2-2] אסור לשנות את המיקום של החלון הקופץ של האפשרויות הנוספות מוצגת על ידי לחיצה על לחצן האפשרויות הנוספות בסרגל הפעולות, אבל יכול להיות שהעיבוד החלון הקופץ 'אפשרויות נוספות' של הפעולה במיקום שהשתנה במסך כשהוא שמוצג על ידי בחירה של פונקציית התפריט.
אם הטמעות המכשיר לא מספקות את פונקציית התפריט, תאימות, הן:
- [C-3-1] חובה שפונקציית התפריט תהיה זמינה לאפליקציות
targetSdkVersion
קטן מ-10, באמצעות לחצן פיזי, מפתח תוכנה, או תנועות. פונקציית התפריט הזו צריכה להיות נגישה, אלא אם היא מוסתרת יחד עם פונקציות ניווט אחרות.
אם ההטמעות של מכשירים מספקות את פונקציית ה-Assist, הם:
- [C-4-1] חובה להפוך את פונקציית Assist לנגישה באמצעות פעולה אחת (למשל: הקשה, לחיצה כפולה או תנועה) כשניתן לגשת למקשי ניווט אחרים.
- [C-SR-3] מומלץ מאוד ללחוץ לחיצה ארוכה על הפונקציה Home לאינטראקציה ייעודית.
אם הטמעות מכשירים משתמשות בחלק נפרד מהמסך כדי להציג את במקשי הניווט, הם:
- [C-5-1] מקשי הניווט חייבים להשתמש בחלק נפרד של המסך, ולא זמינים לאפליקציות, ואסור להם להסתיר או לשבש בדרך אחרת את החלק במסך שזמין לאפליקציות.
- [C-5-2] חייב להפוך חלק מהמסך לאפליקציות עומדת בדרישות המוגדרות בסעיף 7.1.1.
- [C-5-3] חובה לפעול בהתאם לסימונים שהאפליקציה קבעה דרך
View.setSystemUiVisibility()
בשיטת API, כך שהחלק הייחודי הזה במסך (שנקרא גם סרגל הניווט) מוסתר כראוי, כפי שמתועד ערכת ה-SDK.
אם פונקציית הניווט מוצגת כפעולה במסך, שמבוססת על תנועות:
- [C-6-1]
WindowInsets#getMandatorySystemGestureInsets()
חייבים לשמש רק לדיווח על האזור לזיהוי תנועה במסך הבית. - [C-6-2] תנועות שמתחילות במלבן החרגה כפי שסופק על ידי
אפליקציה שפועלת בחזית דרך
View#setSystemGestureExclusionRects()
, אבל מחוץ ל-WindowInsets#getMandatorySystemGestureInsets()
, אסור ליירט את הפונקציה של ניווט כל עוד ההחרגה rect מותר במסגרת מגבלת ההחרגה המקסימלית כפי שמצוין תיעוד עבורView#setSystemGestureExclusionRects()
- [C-6-3] חובה לשלוח לאפליקציה בחזית
MotionEvent.ACTION_CANCEL
אירוע שנוצר בעקבות נגיעות מתחיל ליירט בעקבות תנועה במערכת, אם האפליקציה שנמצאת בחזית נשלחה בעברMotionEvent.ACTION_DOWN
אירוע. - [C-6-4] המשתמש חייב לספק למשתמש מספיק מקום לעבור למסך. לניווט מבוסס-לחצנים (לדוגמה, בהגדרות).
- אמורה לספק את הפונקציה 'דף הבית' כהחלקה למעלה מהקצה התחתון של הכיוון הנוכחי של המסך.
- אמורה לספק את הפונקציה 'אחרונים' כהחלקה למעלה והחזקה לפני השחרור, אותו האזור כמו התנועה במסך הבית.
- תנועות שמתחילות תוך
WindowInsets#getMandatorySystemGestureInsets()
לא אמורות להיות מושפעות מהגדרות החרגה שזמינות בחזית בקשה דרךView#setSystemGestureExclusionRects()
אם מסופקת פונקציית ניווט מכל מקום בקצה השמאלי והימני של הכיוון הנוכחי של המסך:
- [C-7-1] פונקציית הניווט חייבת להיות חוזרת ומופיעה החל מהקצה השמאלי והימני של הכיוון הנוכחי מסך.
- [C-7-2] אם חלוניות מערכת בהתאמה אישית ניתנות להחלקה זמינות בצד שמאל או הקצוות הימניים, הם חייבים להיות ממוקמים בשליש העליון של המסך באמצעות אינדיקציה חזותית ברורה ועקבית שגרירה פנימה תפעיל שהוזכרו למעלה, ולכן לא חזרה. יכול להיות שחלונית מערכת מוגדר על ידי משתמש כך שהוא יגיע אל מתחת לשליש העליון של המסך קצוות, אבל לוח המערכת לא יכול להשתמש ביותר מ-1/3 מהקצוות.
- [C-7-3] כשבאפליקציה בחזית יש את אחד מהמצבים הבאים: הצגה.SYSTEM_UI_FLAG_IMMERSIVE, תצוגה.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, windowInsetsController.BEHAVIOR_DEFAULT, או הוגדרו דגלים של windowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, החלקה מהקצוות חייבת להתנהג כמו שמוטמעת ב-AOSP, מתועד ב-SDK.
- [C-7-4] כשבאפליקציה בחזית יש הצגה.SYSTEM_UI_FLAG_IMMERSIVE, תצוגה.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, windowInsetsController.BEHAVIOR_DEFAULT, או דגל windowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE הוגדרו, חלוניות מערכת בהתאמה אישית שניתן להחליק חייבות להיות מוסתרות עד שהמשתמש מכניס או ביטול העמעום של סרגלי המערכת (שנקראים גם ניווט ושורת סטטוס) כפי שהוטמע ב-AOSP.
אם סופקה פונקציית הניווט 'הקודם' והמשתמש ביטל את הפעולה 'הקודם' תנועה, ואז:
- [C-8-1] חובה להתקשר אל
OnBackInvokedCallback.onBackCancelled()
. - [C-8-2] אסור להתקשר אל
OnBackInvokedCallback.onBackInvoked()
. - [C-8-3] אין לשלוח את האירוע KEYCODE_BACK.
אם פונקציית הניווט האחורית מסופקת, אבל האפליקציה בחזית
שאין להם OnBackInvokedCallback
רשום, ואז:
- המערכת אמורה לספק אנימציה לאפליקציה בחזית מציעה שהמשתמש חוזר, כפי שמצוין ב-AOSP.
אם הטמעות המכשירים תומכות ב-API של המערכת setNavBarMode
כדי
אפשר לכל אפליקציית מערכת עם ההרשאה android.permission.STATUS_BAR
להגדיר את
במצב סרגל הניווט, ואז:
- [C-9-1] חייבת לספק תמיכה בסמלים או בסמלים מבוססי-לחצנים שמתאימים לילדים. ניווט כפי שסופק בקוד ה-AOSP.
7.2.4. קלט מסך מגע
ב-Android יש תמיכה במגוון מערכות קלט של מצביע, כמו מסכי מגע, רפידות מגע ומכשירים מזויפים לקלט מגע. הטמעות מכשירים שמבוססות על מסך מגע משויכות לתצוגה כך שהמשתמש מקבל את החשיפה ישירות לבצע מניפולציות על פריטים במסך. מאחר שהמשתמש נוגע ישירות במסך, המערכת לא דורשת עלויות נוספות כדי לציין את האובייקטים. שעברו מניפולציה.
הטמעות מכשירים:
- אמורה להיות מערכת קלט של מצביע מסוג כלשהו. (כמו בעכבר או במגע).
- צריכה לתמוך בסמנים שנמצאים במעקב בלתי תלוי באופן מלא.
אם יישומי המכשיר כוללים מסך מגע (נגיעה אחת ואילך) במסך ראשי שתואם ל-Android, אפשר:
- [C-1-1] חובה לדווח על
TOUCHSCREEN_FINGER
עבורConfiguration.touchscreen
שדה API. - [C-1-2] חובה לדווח על
android.hardware.touchscreen
android.hardware.faketouch
תכונות ניסיוניות.
אם יישומים של המכשיר כוללים מסך מגע שיכול לעקוב אחר יותר מ- נגיעה אחת במסך ראשי שתואם ל-Android:
- [C-2-1] חובה לדווח על הסימונים המתאימים
android.hardware.touchscreen.multitouch
,android.hardware.touchscreen.multitouch.distinct
,android.hardware.touchscreen.multitouch.jazzhand
שתואם לסוג של מסך המגע הספציפי במכשיר.
אם הטמעות המכשיר מסתמכות על מכשיר קלט חיצוני, כמו עכבר או כדור עקיבה (כלומר לא לגעת ישירות במסך) לקלט של מכשיר ראשי מסך תואם ל-Android ועומד בדרישות של מגע מזויף 7.2.5:
- [C-3-1] אסור לדווח על סימון תכונה כלשהו שמתחיל ב-
android.hardware.touchscreen
- [C-3-2] חובה לדווח רק על
android.hardware.faketouch
. - [C-3-3] חובה לדווח על
TOUCHSCREEN_NOTOUCH
עבורConfiguration.touchscreen
שדה API.
7.2.5. קלט מגע מזויף
ממשק מגע מזויף מספק מערכת קלט של משתמש שתואמת לקבוצת משנה של יכולות של מסך מגע. לדוגמה, עכבר או שלט רחוק סמן במסך מתקרב למגע, אבל דורש מהמשתמש להצביע לראשונה להתמקד וללחוץ. מכשירים שונים לקליטת נתונים, כמו העכבר, משטח מגע, מבוסס ג'ירו עכבר אוויר, ג'ויסטיק, ג'ויסטיק ומשטח מגע מולטי-טאץ' יכולים לתמוך בזיוף אינטראקציות מגע. Android כולל את קבוע התכונה android.hardware.faketouch, תואם לתקן באיכות גבוהה ללא מגע התקן קלט (מבוסס-הצבעה), כמו עכבר או משטח מגע שיכולים להתאים לבצע אמולציה של קלט מבוסס מגע (כולל תמיכה בסיסית בתנועה), ולציין המכשיר תומך בקבוצת משנה אמולמית של פונקציונליות של מסך מגע.
אם ההטמעות במכשיר לא כוללות מסך מגע אלא כוללות מסך מגע אחר את המערכת של קלט המצביע שהם רוצים להעמיד, הם:
- צריך להצהיר על תמיכה בדגל הפיצ'ר
android.hardware.faketouch
.
אם בהטמעות המכשירים מוצהר על תמיכה ב-android.hardware.faketouch
,
הם:
- [C-1-1] חובה לדווח על מיקומי המסך המוחלטים X ו-Y של מיקום הסמן ולהציג מצביע חזותי על המסך.
- [C-1-2] חובה לדווח על אירוע המגע עם קוד הפעולה שמציין את שינוי מצב שמתרחש בסמן יורד או עולה במסך.
- [C-1-3] חייבת להיות תמיכה בסמן כלפי מטה ומעלה על גבי אובייקט במסך, מאפשרת למשתמשים לבצע אמולציה של הקשה על אובייקט במסך.
- [C-1-4] חובה לתמוך בסמן כלפי מטה, מצביע למעלה, מצביע למטה ואז מצביע למעלה באותו מקום על אובייקט במסך במסגרת סף זמן, מאפשר למשתמשים לבצע אמולציה של הקשה כפולה על אובייקט במסך.
- [C-1-5] חייבת לתמוך בסמן כלפי מטה בנקודה שרירותית על המסך, של סמן העכבר לכל נקודה שרירותית אחרת במסך, ואחריה מצביע למעלה, שמאפשר למשתמשים לחקות גרירה במגע.
- [C-1-6] חובה לתמוך במצביע תמיכה למטה ואז לאפשר למשתמשים להזיז במהירות את להופיע במיקום אחר במסך ואז מצביע למעלה על המסך. שמאפשר למשתמשים להשליך חפץ על המסך.
אם בהטמעות מכשירים מוצהר על תמיכה ב
android.hardware.faketouch.multitouch.distinct
, הן:
- [C-2-1] חובה להצהיר על תמיכה ב-
android.hardware.faketouch
. - [C-2-2] חייבת להיות תמיכה במעקב ייחודי אחרי שני מצביעים בלתי תלויים או יותר של קלטים.
אם בהטמעות מכשירים מוצהר על תמיכה ב
android.hardware.faketouch.multitouch.jazzhand
, הן:
- [C-3-1] חובה להצהיר על תמיכה ב-
android.hardware.faketouch
. - [C-3-2] חייבת להיות תמיכה במעקב ייחודי של 5 (מעקב אחר יד של אצבעות) או יותר קלט של מצביע באופן מלא באופן עצמאי.
7.2.6. תמיכה לבקרים לגיימינג
7.2.6.1. מיפויי לחצנים
הטמעות מכשירים:
- [C-1-1] חייבת להיות יכולת למפות אירועי HID לקבועים המתאימים של
InputEvent
כפי שמפורט בטבלאות הבאות. ההטמעה של Android ב-upstream עומדת בדרישה הזו.
אם בהטמעות של מכשירים מוטמעים בקר או נשלח עם בקר נפרד בתיבה שמספקים אמצעים לקלט כל האירועים המפורטים בטבלאות הבאות:
- [C-2-1] חובה להצהיר על דגל הפיצ'ר
android.hardware.gamepad
לחצן | שימוש במכשיר ממשק אנושי (HID)2 | לחצן Android |
---|---|---|
א1 | 0x09 0x0001 | KEYCODE_button_A (96) |
ב1 | 0x09 0x0002 | KEYCODE_button_B (97) |
X1 | 0x09 0x0004 | KEYCODE_button_X (99) |
כן1 | 0x09 0x0005 | KEYCODE_button_Y (100) |
לחצני החיצים (D-pad)1 לחצני החיצים (D-pad)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) |
לחיצה על הלחצן הימני1 | 0x09 0x000F | KEYCODE_button_THUMBR (107) |
לדף הקודם1 | 0x0c 0x0224 | KEYCODE_BACK (4) |
אירוע מרכזי אחד
2 חובה להצהיר על השימוש במכשיר ממשק אנושי (HID) שלמעלה במשחק pad CA (0x01 0x0005).
3 השימוש הזה חייב להיות בעל ערך לוגי מינימלי של 0, מקסימום לוגי של 7, מינימום 0 פיזי, מקסימום 315, יחידות במעלות וגודל דוח של 4. הערך הלוגי מוגדר סיבוב בכיוון השעון הרחק מהציר האנכי; לדוגמה, ערך לוגי של 0 מייצג ללא סיבוב, ולחיצה על הלחצן למעלה, בעוד ערך לוגי הערך 1 מייצג סיבוב של 45 מעלות, וגם המקשים שמאלה ולמעלה בוצעה לחיצה.
אמצעי בקרה אנלוגיים1 | שימוש במכשיר ממשק אנושי (HID) | לחצן Android |
---|---|---|
טריגר שמאלי | 0x02 0x00C5 | AXIS_LTRIGGER |
טריגר ימני | 0x02 0x00C4 | AXIS_RTRIGGER |
ג'ויסטיק שמאלי | 0x01 0x0030 0x01 0x0031 |
AXIS_X AXIS_Y |
ג'ויסטיק ימני | 0x01 0x0032 0x01 0x0035 |
AXIS_Z AXIS_RZ |
MotionEvent אחד
7.2.7. שלט רחוק
ראו סעיף 2.3.1 לדרישות ספציפיות למכשיר.
7.3. חיישנים
אם ההטמעות במכשירים כוללות חיישן מסוג מסוים ממשק API תואם למפתחים של צד שלישי, הטמעת המכשירים חובה להטמיע את ה-API הזה כפי שמתואר במסמכים של Android SDK. תיעוד הקוד הפתוח של Android בקטע חיישנים.
הטמעות מכשירים:
- [C-0-1] חובה לדווח בצורה מדויקת על נוכחות או היעד של חיישנים
android.content.pm.PackageManager
בכיתה. - [C-0-2] חובה להחזיר רשימה מדויקת של חיישנים נתמכים דרך
SensorManager.getSensorList()
ושיטות דומות. - [C-0-3] חובה להתנהג באופן סביר בכל ממשקי ה-API של החיישנים האחרים (לדוגמה,
החזרת
true
אוfalse
בהתאם לצורך כשאפליקציות מנסות להירשם מאזינים, ללא קריאה למאזינים של חיישנים כשהחיישנים המתאימים לא כיום; וכו').
אם ההטמעות במכשירים כוללות חיישן מסוג מסוים התואם למפתחים של צד שלישי, הם:
- [C-1-1] חובה לדווח על כל מדידות החיישנים באמצעות הערכים הרלוונטיים של מערכת היחידות הבין-לאומית (המדד) לכל אחד מהם סוג החיישן כפי שמוגדר במסמכי התיעוד של Android SDK.
- [C-1-2] חובה לדווח על נתוני החיישנים שזמן האחזור שלהם הוא 100 לכל היותר אלפיות שנייה + 2 * sample_time למקרה של שידור חיישן עם זמן אחזור מבוקש מקסימלי של 0 אלפיות השנייה כאשר מעבד האפליקציות פעיל. העיכוב הזה לא כולל עיכובים בסינון.
- [C-1-3] חובה לדווח על דגימת החיישן הראשונה תוך 400 אלפיות השנייה + 2 * segment_time של החיישן שמופעל. מותר להשתמש בדוגמה הזו לקבל דיוק של 0.
- [C-1-4] כל API שמצוין בתיעוד של Android SDK הוא חיישן רציף, יישומים של מכשירים חייבים לספק באופן רציף בדגימות נתונים תקופתיות שאמורות להיות רעידות מתחת ל-3%, כאשר רעידות מוגדרת כסטיית התקן של ההפרש שידווחו ערכים של חותמת זמן בין אירועים עוקבים.
- [C-1-5] חובה לוודא שהאירוע של החיישן אסור למנוע מהמעבד (CPU) של המכשיר להיכנס למצב השעיה או לצאת ממצב שינה ממצב השעיה.
- [C-1-6] חובה לדווח על מועד האירוע בננו-שניות כפי שמוגדר במסמכי התיעוד של Android SDK, שמייצגים את שהאירוע התרחש וסונכרן עם שעון SystemClock.elapsedRenano() .
- [C-SR-1] מומלץ מאוד שיש שגיאה בסנכרון של חותמת הזמן מתחת ל-100 אלפיות השנייה, ואמורה להיות שגיאת סנכרון חותמת זמן מתחת ל-1 אלפית שנייה.
- כאשר כמה חיישנים מופעלים, צריכת החשמל לא אמורה להיות גבוהה יותר סך צריכת החשמל של החיישן הבודד.
הרשימה שלמעלה היא חלקית. ההתנהגות המתועדת של ה-SDK של Android ומסמכי הקוד הפתוח של Android ב- חיישנים מהימן.
אם ההטמעות במכשירים כוללות חיישן מסוג מסוים התואם למפתחים של צד שלישי, הם:
- [C-1-6] חובה להגדיר רזולוציה שהיא לא אפס לכל החיישנים ולדווח על הערך
דרך
Sensor.getResolution()
שיטת ה-API.
חלק מסוגי החיישנים הם מורכבים, כלומר הם נגזרים מנתונים שסופקו חיישן אחד או יותר. (לדוגמה: חיישן הכיוון חיישן תאוצה לינארית).
הטמעות מכשירים:
- יש להטמיע את סוגי החיישנים האלה לכלול את החיישנים הפיזיים הנדרשים, כפי שמתואר בסוגי חיישנים.
אם ההטמעות במכשירים כוללות חיישן מורכב, הן:
- [C-2-1] חובה להטמיע את החיישן כפי שמתואר בקוד הפתוח של Android על חיישנים מורכבים.
אם ההטמעות במכשירים כוללות חיישן מסוג מסוים ממשק API תואם למפתחים של צד שלישי והחיישן מדווח על אחד בלבד ערך, ואז הטמעות מכשירים:
- [C-3-1] חובה להגדיר את הרזולוציה של החיישן ל-1 ולדווח על הערך
דרך
Sensor.getResolution()
שיטת ה-API.
אם ההטמעות במכשירים כוללות סוג חיישן מסוים שתומך SensorAdditionalInfo#TYPE_VEC3_CALIBRATION והחיישן חשוף למפתחים של צד שלישי, הם:
- [C-4-1] אסור לכלול כיול קבוע שנקבע על ידי היצרן בפרמטרים של הנתונים שסופקו.
אם יישומי המכשיר כוללים שילוב של מד תאוצה ב-3 צירים, חיישן ג'ירוסקופ עם 3 צירים או חיישן מגנטומטר:
- [C-SR-2] מומלץ מאוד לבדוק את מד התאוצה, הג'ירוסקופ למגנטומטר יש מיקום יחסי קבוע, כך שאם המכשיר ניתן לטרנספורמציה (למשל, מתקפל), צירי החיישן נשארים מיושרים ועקביים באמצעות מערכת הקואורדינטות של החיישן בכל המכשירים האפשריים של הטרנספורמציה.
7.3.1. מד תאוצה
הטמעות מכשירים:
- [C-SR-1] מומלץ מאוד לכלול מד תאוצה עם 3 צירים.
אם בהטמעות במכשירים נכללים מד תאוצה:
- [C-1-1] חייבת להיות אפשרות לדווח על אירועים בתדירות של עד 50Hz לפחות.
- [C-1-3] חייב לעמוד בדרישות של מערכת קואורדינטות של חיישן Android כפי שמפורט בממשקי ה-API של Android.
- [C-1-4] חייבת להיות מסוגלת למדוד מצניחה חופשית עד פי ארבע
gravity(4g)
או יותר בכל ציר. - [C-1-5] חייבת להיות ברזולוציה של 12 ביט לפחות.
- [C-1-6] חייבת להיות סטיית תקן של לא יותר מ-0.05 מטר/s^, כאשר יש לחשב את סטיית התקן על בסיס כל ציר על בסיס דגימות שנאספו במשך פרק זמן של 3 שניות לפחות, בקצב הדגימה המהיר ביותר.
- צריך לדווח על אירועים עד 200 Hz לפחות.
- הרזולוציה צריכה להיות לפחות 16 סיביות.
- צריך לכייל אותו בזמן השימוש אם המאפיינים משתנים על מחזור החיים ועל פיצוי, ומשמרים את הפרמטרים של הפיצוי בין הפעלות מחדש של המכשיר.
- הטמפרטורה אמורה לפצות על הטמפרטורה.
אם יישומי המכשירים כוללים מד תאוצה ב-3 צירים, הם:
- [C-2-1] חובה להטמיע את החיישן
TYPE_ACCELEROMETER
ולדווח עליו. - [C-SR-4] מומלץ מאוד להטמיע את
TYPE_SIGNIFICANT_MOTION
מרוכב. - [C-SR-5] מומלץ מאוד להטמיע מודעות ולדווח עליהן
חיישן
TYPE_ACCELEROMETER_UNCALIBRATED
. מכשירי Android הם בשימוש חזק מומלץ לעמוד בדרישה הזו כדי שהם יוכלו לשדרג במהדורה עתידית של פלטפורמה שבה יכול להיות שהדרישה הזו תהיה REQUIRED. - צריך להטמיע את
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
,TYPE_STEP_COUNTER
מחיישנים מורכבים, כפי שמתואר במסמך ה-SDK של Android.
אם בהטמעות המכשירים יש מד תאוצה עם פחות מ-3 צירים:
- [C-3-1] חובה להטמיע את החיישן
TYPE_ACCELEROMETER_LIMITED_AXES
ולדווח עליו. - [C-SR-6] מומלץ מאוד ליישם את ההמלצה ולדווח עליה
חיישן
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
אם יישומי המכשיר כוללים מד תאוצה ב-3 צירים ואחד
TYPE_SIGNIFICANT_MOTION
, TYPE_TILT_DETECTOR
, TYPE_STEP_DETECTOR
הוטמעו חיישנים מורכבים של TYPE_STEP_COUNTER
:
- [C-4-1] סכום הערכים צריכת החשמל חייבת להיות תמיד נמוכה מ-4 מגה-ואט.
- כל אחד מהם צריך להיות קטן מ-2 מגה-ואט ו-0.5 מגה-ואט כשהמכשיר במצב דינמי או סטטי.
אם הטמעת המכשיר כוללת מד תאוצה ב-3 צירים וחיישן ג'ירוסקופ עם 3 צירים, הם:
- [C-5-1] חובה להטמיע את
TYPE_GRAVITY
ואתTYPE_LINEAR_ACCELERATION
מחיישנים מורכבים. - [C-SR-7] מומלץ מאוד ליישם
חיישן מורכב
TYPE_GAME_ROTATION_VECTOR
.
אם יישומי המכשיר כוללים מד תאוצה ב-3 צירים, חיישן ג'ירוסקופ עם 3 צירים וחיישן מגנטומטר, הן:
- [C-6-1] חובה להטמיע חיישן מורכב של
TYPE_ROTATION_VECTOR
.
7.3.2. מגנטומטר
הטמעות מכשירים:
- [C-SR-1] מומלץ מאוד לכלול מגנטומטר (מצפן) עם 3 צירים.
אם הטמעתם במכשירים שונים מגנטומטר עם 3 צירים:
- [C-1-1] חובה להטמיע את החיישן
TYPE_MAGNETIC_FIELD
. - [C-1-2] חייבת להיות אפשרות לדווח על אירועים בתדירות של עד 10 Hz לפחות וצריכים לדווח על אירועים עד 50 Hz לפחות.
- [C-1-3] חייב לעמוד בדרישות של מערכת הקואורדינטות של חיישן Android כפי שמפורט ממשקי API של Android.
- [C-1-4] חייבת להיות יכולת למדוד בין -900 μT ל- +900 μT בכל אחד לפני רוויה.
- [C-1-5] ערך ההיסט של ברזל קשיח נמוך מ- 700 μT והוא צריך להיות ערך נמוך מ- 200 μT, על ידי הצבת המגנטומטר רחוק שדות מגנטיים דינמיים (בזרם חשמלי) וסטטיים (בהגברת מגנט).
- [C-1-6] הרזולוציה צריכה להיות שווה או צפופה יותר מ-0.6 μT.
- [C-1-7] חובה לתמוך בכיול מקוון ובפיצוי של הברזל הקשיח הטיה ולשמר את הפרמטרים של הפיצוי בין הפעלות מחדש של המכשיר.
- [C-1-8] חובה להחיל את הפיצוי על הברזל הרך – הכיול יכול להיות בזמן השימוש או במהלך הייצור של המכשיר.
- [C-1-9] חייבת להיות סטיית תקן, המחושבת על בסיס לכל ציר דגימות שנאספו במשך פרק זמן של 3 שניות לפחות, בדגימה המהירה ביותר קצב של עד 1.5μT; אמורה להיות סטיית תקן שלא גדולה מ- 0.5 μT.
- [C-1-10] חובה ליישם
TYPE_MAGNETIC_FIELD_UNCALIBRATED
באמצעות חיישן.
אם הטמעת המכשיר כוללת מגנטומטר ב-3 צירים, מד תאוצה וחיישן ג'ירוסקופ עם 3 צירים, הם:
- [C-2-1] חובה להטמיע חיישן מורכב מסוג
TYPE_ROTATION_VECTOR
.
אם יישומי המכשיר כוללים מגנטומטר ב-3 צירים ומד תאוצה, הם:
- יכול להיות שהחיישן
TYPE_GEOMAGNETIC_ROTATION_VECTOR
יוטמע.
אם יישומי המכשיר כוללים מגנטומטר ב-3 צירים, מד תאוצה
חיישן TYPE_GEOMAGNETIC_ROTATION_VECTOR
, הן:
- [C-3-1] חובה לצרוך פחות מ-10 מגה-ואט.
- צריך לצרוך פחות מ-3 מגה-ואט כשהחיישן רשום במצב אצווה ב-10Hz.
7.3.3. GPS
הטמעות מכשירים:
- [C-SR-1] מומלץ מאוד לכלול מקלט GPS/GNSS.
אם יישומי המכשיר כוללים מקלט GPS/GNSS ומדווחים על היכולת
לאפליקציות באמצעות דגל התכונה android.hardware.location.gps
, הן:
- [C-1-1] חייבת לתמוך בפלט מיקום בקצב של 1 Hz לפחות כאשר
נשלחה בקשה דרך
LocationManager#requestLocationUpdate
. - [C-1-2] חייבת להיות אפשרות לקבוע את המיקום בתנאים של שמיים פתוחים
(אותות חזקים, מולטי-נתיב זניח, HDOP < 2) בתוך 10 שניות (מהירה
זמן לתיקון הראשון), כשמחוברים למהירות נתונים של 0.5Mbps או מהירות יותר
חיבור לאינטרנט. כדי לעמוד בדרישה הזו, השימוש בכלים
סוג של שיטת 'GPS/GNSS' בסיוע או חזויים
כדי למזער את זמן הנעילה של ה-GPS/GNSS (נתוני הסיוע כוללים את זמן ההפניה,
מיקום הפניה ותקופת זמן לוויינית/שעון).
- [C-1-6] לאחר ביצוע חישוב מיקום כזה, המכשיר וההטמעות חייבות לקבוע את המיקום שלהן, בשמיים פתוחים, 5 שניות, כשבקשות המיקום מופעלות מחדש, עד שעה לאחר מכן את חישוב המיקום הראשוני, גם כשהבקשה הבאה נעשה ללא חיבור נתונים ו/או לאחר מחזור חשמל.
במצב של שמיים פתוחים לאחר קביעת המיקום, כשהוא נייח או נע בפחות ממטר אחד לשנייה, בריבוע תאוצה:
- [C-1-3] חייבת להיות יכולת לקבוע את המיקום בטווח של 20 מטרים, ומהירות בטווח של 0.5 מטר לשנייה, לפחות ב-95% מהזמן.
- [C-1-4] חובה לעקוב בו-זמנית ולדווח עליהן באמצעות
GnssStatus.Callback
לפחות 8 לוויינים מקבוצת כוכבים אחת. - אמורה להיות אפשרות לעקוב בו-זמנית אחרי לפחות 24 לוויינים, מספר קבוצות כוכבים (למשל GPS + לפחות אחת של Glonass, ביידו, גליליאו).
[C-SR-2] מומלץ מאוד להמשיך לספק GPS/GNSS רגילים הפלט של נתוני המיקום באמצעות ממשקי ה-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 לכל Hz (שונות ל-Hz או rad^2 / s). השונות יכולה להשתנות עם קצב הדגימה, אך הערך הזה חייב להיות מוגבל. במילים אחרות, אם מודדים את השונות של הג'יירו בקצב דגימה של 1 Hz שהוא לא אמור להיות גדול יותר מ-1e-7 rad^2/s^2.
- [C-SR-2] מומלץ מאוד ששגיאת כיול תהיה קטנה מ- 0.01 rad/s כשהמכשיר נייח בטמפרטורת החדר.
- [C-SR-3] מומלץ מאוד להשתמש ברזולוציה של 16 ביט או יותר.
- צריך לדווח על אירועים עד 200 Hz לפחות.
אם הטמעת המכשיר כוללת ג'ירוסקופ עם 3 צירים:
- [C-2-1] חובה להטמיע את החיישן
TYPE_GYROSCOPE
. - [C-SR-4] מומלץ מאוד להטמיע את
TYPE_GYROSCOPE_UNCALIBRATED
באמצעות חיישן.
אם ההטמעות במכשירים כוללים ג'ירוסקופ עם פחות מ-3 צירים:
- [C-3-1] חובה להטמיע את החיישן
TYPE_GYROSCOPE_LIMITED_AXES
ולדווח עליו. - [C-SR-5] מומלץ מאוד ליישם את ההמלצה ולדווח עליה
חיישן
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
אם יישומי המכשיר כוללים ג'ירוסקופ ב-3 צירים, חיישן מד תאוצה וחיישן מגנטומטר, הן:
- [C-4-1] חובה להטמיע חיישן מורכב של
TYPE_ROTATION_VECTOR
.
אם הטמעת המכשיר כוללת מד תאוצה ב-3 צירים וג'ירוסקופ עם 3 צירים הם:
- [C-5-1] חובה להטמיע את
TYPE_GRAVITY
ואתTYPE_LINEAR_ACCELERATION
מחיישנים מורכבים. - [C-SR-6] מומלץ מאוד ליישם
TYPE_GAME_ROTATION_VECTOR
מרוכב.
7.3.5. ברומטר
הטמעות מכשירים:
- [C-SR-1] מומלץ מאוד לכלול ברומטר (לחץ אוויר סביבתי) חיישן).
אם הטמעת מכשירים במכשיר כוללת ברומטר:
- [C-1-1] חובה להטמיע את החיישן
TYPE_PRESSURE
ולדווח עליו. - [C-1-2] חייבת להיות אפשרות לספק אירועים בתדירות של 5Hz או יותר.
- [C-1-3] חובה לפצות על הטמפרטורה.
- [C-SR-2] מומלץ מאוד לאפשר דיווח על מדידות לחץ טווח של 300hPa עד 1100hPa.
- הדיוק שלו אמור להיות מוחלט של 1hPa.
- רמת הדיוק היחסית אמורה להיות 0.12hPa על פני טווח של 20hPa (שווה ערך לדיוק של כ-1 מ' לשינוי של כ-200 מ' בגובה פני הים).
7.3.6. מדחום
אם יישומי המכשיר כוללים מדחום סביבתי (חיישן טמפרטורה), הם:
- [C-1-1] חובה להגדיר
SENSOR_TYPE_AMBIENT_TEMPERATURE
לחיישן טמפרטורת הסביבה ולחיישן חייבים למדוד את הסביבה הטמפרטורה שבה (חדר/תא המטען) מהמקום שבו המשתמש מקיים אינטראקציה עם במעלות צלזיוס.
אם יישומי המכשיר כוללים חיישן מדחום שמודד מלבד טמפרטורת הסביבה, כמו הטמפרטורה של המעבד (CPU), במקרים הבאים:
- [C-2-1] אסור להגדיר
SENSOR_TYPE_AMBIENT_TEMPERATURE
חיישן הטמפרטורה.
אם הטמעת המכשיר כוללת חיישן לניטור טמפרטורת העור, ואז:
- [C-SR-1] מומלץ מאוד לתמוך PowerManager.getThermalHeadroom API.
7.3.7. פוטומטר
- ייתכן שהטמעות המכשיר כוללות פוטומטר (חיישן אור רגיש לסביבה).
7.3.8. חיישן קירבה
- ייתכן שהטמעות במכשירים כוללות חיישן קירבה.
אם יישומים של מכשירים כוללים חיישן קירבה, והם מדווחים רק על בינארית 'near' או 'רחוק' קריאה,
- [C-1-1] חובה למדוד את הקרבה של עצם באותו כיוון מסך. כלומר, חיישן הקירבה צריך להיות מכוון לזיהוי עצמים קרוב למסך, כי הכוונה העיקרית של סוג החיישן הזה היא זיהוי טלפון שנמצא בשימוש של המשתמש. אם הטמעות המכשיר כוללות חיישן קירבה בכל כיוון אחר, אסור שהוא יהיה נגיש באמצעות ה-API הזה.
- [C-1-2] רמת דיוק של ביט אחד או יותר.
- [C-1-3] חובה להשתמש ב-0 ס"מ בתור הקריאה הקרובה וב-5 ס"מ קריאה רחוקה.
- [C-1-4] חובה לדווח על טווח ורזולוציה מקסימלי של 5.
7.3.9. חיישנים באיכות גבוהה
אם ההטמעות במכשירים כוללות קבוצה של חיישנים באיכות גבוהה יותר, כפי שהוגדר בקטע הזה כדי להפוך אותם לזמינים לאפליקציות צד שלישי, הם:
- [C-1-1] חובה לזהות את היכולת באמצעות
סימון תכונה
android.hardware.sensor.hifi_sensors
.
אם בהטמעות המכשירים מוצהר על android.hardware.sensor.hifi_sensors
,
הם:
[C-2-1] חייב להיות חיישן
TYPE_ACCELEROMETER
שמאפשר:- טווח המדידה חייב להיות בין -8G ל-8G+, מומלץ מאוד להגדיר טווח מדידה בין -16G לפחות ו-16G+.
- רזולוציית המדידה חייבת להיות לפחות 2048 LSB/g.
- תדירות המדידה המינימלית חייבת להיות 12.5Hz או נמוכה יותר.
- תדירות המדידה המקסימלית חייבת להיות 400 Hz או יותר. אמור
תומכים ב-SensorDirectChannel
RATE_VERY_FAST
. - הרעש במדידה חייב להיות נמוך מ-400 μg/לצאת.
- חובה להשתמש בחיישן הזה בצורת חיישן שלא נכנס למצב שינה עם אגירת נתונים יכולת של 3,000 אירועי חיישנים לפחות.
- צריכת החשמל באצווה חייבת להיות נמוכה מ-3 מגה-ואט.
- [C-SR-1] מומלץ מאוד שרוחב הפס למדידה של 3dB יהיה בגודל של לפחות 80% מתדר ה-Nyquist וספקטרום הרעש הלבן. רוחב פס.
- אמורה להתבצע הליכה אקראית של האצה בפחות מ-30 μg תמצאו ב- Wi-Fi בטמפרטורת החדר.
- אמור להיות שינוי בהטיה לעומת טמפרטורה של ≤ +/- 1 mg/°C .
- אמור להיות קו הכי מתאים של לא ליניאריות של ≤ 0.5%, ושינוי הרגישות לעומת הטמפרטורה הוא ≤ 0.03%/C°.
- אמורה להיות רגישות חוצה-צירים של < 2.5 % ווריאציה של הרגישות של צירים שונים < 0.2% בטווח טמפרטורת הפעולה של המכשיר.
[C-2-2] חייב להיות
TYPE_ACCELEROMETER_UNCALIBRATED
עם אותו ערך דרישות איכות כמוTYPE_ACCELEROMETER
.[C-2-3] חייב להיות חיישן
TYPE_GYROSCOPE
שמאפשר:- טווח המדידה חייב להיות בין -1000 ל- +1000 dps.
- רזולוציית המדידה חייבת להיות לפחות 16 LSB/dps.
- תדירות המדידה המינימלית חייבת להיות 12.5Hz או נמוכה יותר.
- תדירות המדידה המקסימלית חייבת להיות 400 Hz או יותר. אמור
תומכים ב-SensorDirectChannel
RATE_VERY_FAST
. - הרעש במדידה חייב להיות נמוך מ-0.014°/s/לצאת.
- [C-SR-2] מומלץ מאוד שרוחב הפס למדידה של 3dB יהיה בגודל של לפחות 80% מתדר ה-Nyquist וספקטרום הרעש הלבן. רוחב פס.
- צריכה להיות הליכה אקראית של קצב של פחות מ- 0.001 °/s תמצאו Hz בחדר לטמפרטורה.
- אמור להיות שינוי בהטיה לעומת טמפרטורה של ≤ +/- 0.05 °C/ s / °C.
- צריך להיות שינוי ברגישות לעומת הטמפרטורה של 0.02% / °C.
- הקו המתאים ביותר צריך להיות לא ליניארי, כלומר 0.2% או פחות.
- צפיפות הרעש אמורה להיות ≤ 0.007 °/s/COLUMNHz.
- אמורה להיות שגיאת כיול בגודל של פחות מ-0.002 rad/s טווח טמפרטורות 10 ~ 40°C כשהמכשיר נייח.
- הרגישות ל-g צריכה להיות נמוכה מ-0.1°/s/g.
- אמורה להיות רגישות חוצה-צירים של < 4.0 % ורגישות לרוחב צירים וריאציה < 0.3% בטווח טמפרטורת הפעולה של המכשיר.
[C-2-4] חובה לספק
TYPE_GYROSCOPE_UNCALIBRATED
באיכות זהה בדרישות האלה,TYPE_GYROSCOPE
.[C-2-5] חייב להיות חיישן
TYPE_GEOMAGNETIC_FIELD
שמאפשר:- טווח המדידה חייב להיות בין -900 ל- +900 μT.
- רזולוציית המדידה חייבת להיות לפחות 5 LSB/uT.
- תדירות המדידה המינימלית חייבת להיות 5Hz או נמוכה יותר.
- תדירות המדידה המקסימלית חייבת להיות 50Hz או יותר.
- הרעש במדידה חייב להיות נמוך מ-0.5 UT.
[C-2-6] חובה לספק
TYPE_MAGNETIC_FIELD_UNCALIBRATED
באיכות זהה דרישות כמוTYPE_GEOMAGNETIC_FIELD
ובנוסף:- חובה להשתמש בחיישן הזה בצורת חיישן שלא נכנס למצב שינה עם אגירת נתונים יכולת של 600 אירועי חיישנים לפחות.
- [C-SR-3] מומלץ מאוד להשתמש בספקטרום של רעש לבן מ-1 הרץ עד לפחות 10 Hz כשקצב הדיווח הוא 50Hz או יותר.
[C-2-7] חייב להיות חיישן
TYPE_PRESSURE
שמאפשר:- טווח המדידה חייב להיות בין 300 ל-1100 hPa.
- רזולוציית המדידה חייבת להיות לפחות 80 LSB/hPa.
- תדירות המדידה המינימלית חייבת להיות 1 Hz או נמוכה יותר.
- תדירות המדידה המקסימלית חייבת להיות 10Hz או יותר.
- הרעש במדידה חייב להיות נמוך מ-2 Pa/😂.
- חובה להשתמש בחיישן הזה בצורת חיישן שלא נכנס למצב שינה עם אגירת נתונים יכולת של 300 אירועי חיישן לפחות.
- צריכת החשמל באצווה חייבת להיות נמוכה מ-2 מגה-ואט.
[C-2-8] חייב להיות חיישן
TYPE_GAME_ROTATION_VECTOR
.[C-2-9] חייב להיות חיישן
TYPE_SIGNIFICANT_MOTION
ש:- צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי ו- 1.5 mW כשהמכשיר נמצא בתנועה.
[C-2-10] חייב להיות חיישן
TYPE_STEP_DETECTOR
ש:- חובה להשתמש בחיישן הזה בצורת חיישן שלא נכנס למצב שינה עם אגירת נתונים יכולת של 100 אירועי חיישן לפחות.
- צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי ו- 1.5 mW כשהמכשיר נמצא בתנועה.
- צריכת החשמל באצווה חייבת להיות נמוכה מ-4 מגה-ואט.
[C-2-11] חייב להיות חיישן
TYPE_STEP_COUNTER
ש:- צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי ו- 1.5 mW כשהמכשיר נמצא בתנועה.
[C-2-12] חייב להיות חיישן
TILT_DETECTOR
ש:- צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי ו- 1.5 mW כשהמכשיר נמצא בתנועה.
[C-2-13] חותמת הזמן של האירוע של אותו אירוע פיזי שדווח על ידי מד התאוצה, הג'יירוסקופ והמגנטומטר חייבים להיות בטווח של 2.5 אלפיות השנייה שתי רשתות נוירונים זו מול זו. חותמת הזמן של האירוע של אותו אירוע פיזי שדווח על ידי מד התאוצה והג'ירוסקופ צריכים להיות בטווח של 0.25 אלפיות שנייה מכל אחד אחר.
[C-2-14] חותמות הזמן של אירועים מחיישן הג'ירוסקופ צריכות להיות מוצגות באותו הזמן בתור מערכת המשנה של המצלמה, ותוך אלפיות שנייה אחת משגיאה.
[C-2-15] חובה לשלוח דגימות לאפליקציות תוך 5 אלפיות שנייה השעה שבה הנתונים זמינים באחד מהחיישנים הפיזיים שצוינו למעלה לאפליקציה.
[C-2-16] אסור שצריכת החשמל תהיה גבוהה מ-0.5 מגה-ואט כשהמכשיר סטטי ו- 2.0 mW כשהמכשיר נמצא בתנועה כששילוב של החיישנים הבאים מופעל:
SENSOR_TYPE_SIGNIFICANT_MOTION
SENSOR_TYPE_STEP_DETECTOR
SENSOR_TYPE_STEP_COUNTER
SENSOR_TILT_DETECTORS
[C-2-17] עשויים להיות חיישן
TYPE_PROXIMITY
, אבל אם קיים חיישן כזה עם יכולת מינימלית של מאגר נתונים זמני של 100 אירועי חיישן.
שימו לב שכל הדרישות של צריכת החשמל בקטע הזה לא כוללות את של מעבד האפליקציות. הוא כולל את הכוח נמשך על ידי כל שרשרת החיישנים - החיישן, כל מעגלים תומכים, מערכת ייעודית לעיבוד חיישנים וכו'.
אם ההטמעות במכשירים כוללות תמיכה ישירה בחיישנים:
- [C-3-1] חובה להצהיר בצורה נכונה על תמיכה בסוגי ערוצים ישירים
לדווח על רמת המחירים דרך
isDirectChannelTypeSupported
ו-getHighestDirectReportRateLevel
API. - [C-3-2] חייב לתמוך לפחות באחד משני סוגי הערוצים הישירים של חיישנים לכל החיישנים שמצהירים על תמיכה בערוץ ישיר של חיישן.
- צריכה לתמוך בדיווח על אירועים דרך ערוץ ישיר של חיישן
חיישן (וריאנט ללא מצב שינה) מהסוגים הבאים:
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
7.3.10. חיישנים ביומטריים
רקע נוסף על מדידת אבטחה ביומטרית לביטול נעילה, אפשר לעיין במאמר מסמכי תיעוד בנושא אבטחה ביומטרית.
אם הטמעתם במכשיר מסך נעילה מאובטח:
- צריכה לכלול חיישן ביומטרי
ניתן לסווג חיישנים ביומטריים כסיווג 3 (לשעבר חזק), Class 2 (לשעבר Weak) או Class 1 (לשעבר Convenience) בהתבסס על שיעורי הזיוף וההתחזות שלהם, ועל האבטחה צינור עיבוד נתונים ביומטרי. הסיווג הזה קובע את היכולות של החיישן הביומטרי צריך להתממשק עם הפלטפורמה ועם צד שלישי תרגום מכונה. החיישנים צריכים לעמוד בדרישות נוספות שמפורטות בהמשך, אם רוצים לסווג אותם כרמה 1, רמה 2 או רמה 3. הנתונים הביומטריים של רמה 2 וגם של סיווג 3 מקבלים יכולות נוספות: כמפורט בהמשך.
אם ההטמעות במכשיר מאפשרות לצד שלישי גישה לחיישן ביומטרי אפליקציות דרך android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt, וגם android.provider.Settings.ACTION_BIOMETRIC_ENROLL, הם:
- [C-4-1] האפליקציה חייבת לעמוד בדרישות לדיווח ביומטרי ברמה Class 3 או Class 2 כפי שמוגדר במסמך הזה.
- [C-4-2] חובה לזהות ולכבד כל שם של פרמטר שמוגדר כקבוע בקטע המאמתים והשילובים שלו. לעומת זאת, אסור להכיר בקבועים של מספרים שלמים שמועברים canAuthenticate(int) ו-setAllowedAuthenticator(int) שיטות אחרות שלא מתועדות כקבועים ציבוריים מאמתי חשבונות וכל שילובים שלהם.
- [C-4-3] חובה להטמיע את ACTION_BIOMETRIC_ENROLL פעולה במכשירים עם מידע ביומטרי מסוג רמה 3 או סיווג 2. הפעולה הזו חייבת להציג רק את נקודות הכניסה לרמה 3. או מידע ביומטרי מסוג רמה 2.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-4-4] חובה לאפשר לאפליקציות להוסיף תוכן מותאם אישית אל
BiometricPrompt
באמצעות הפורמטיםPromptContentView
של תצוגת התוכן. התוכן המוצג אין להרחיב את הפורמטים כדי לאפשר תמונות, קישורים, תוכן אינטראקטיבי, או צורות מדיה אחרות שלא נכללות עדיין בBiometricPrompt
API. התאמות סגנוניות שלא משנות, מסתירות או חותכות אותו ליצירת תוכן (כמו שינוי מיקום, מרווח פנימי, שוליים טיפוגרפיה).
סיום הדרישות החדשות
אם הטמעות במכשירים תומכים בזיהוי ביומטרי פסיבית:
- [C-5-1] כברירת מחדל חובה לדרוש שלב אישור נוסף (למשל, לחיצה על לחצן).
- [C-SR-1] מומלץ מאוד לקבוע הגדרה שמאפשרת למשתמשים לבטל את ההעדפה של האפליקציה ותמיד להשתמש בתוספות שלב האישור.
- [C-SR-2] מומלץ מאוד לוודא שפעולת האישור מאובטחת כך שמערכת ההפעלה או התוכנה בליבה לא יוכלו לזייף אותה. לדוגמה, המשמעות היא שפעולת האישור מבוססת על לחצן פיזי עובר דרך סיכת קלט/פלט לשימוש כללי (GPIO) בלבד, רכיב מאובטח (SE) שלא ניתן להפעיל באמצעותו שום אמצעי אחר מלבד לחיצה על הלחצן הפיזי.
- [C-5-2] חובה להטמיע גם תהליך אימות מרומז (ללא שלב אישור) שתואם ל- setConfirmationrequired(boolean), אילו אפליקציות יכולות להשתמש בהן לתהליכי כניסה.
אם בהטמעות במכשירים יש כמה חיישנים ביומטריים:
[C-7-1] חובה כאשר מידע ביומטרי נמצא בנעילה (למשל, המידע הביומטרי מושבת עד שהמשתמש מבטל את הנעילה באמצעות אימות ראשי) או נעילה לזמן מוגבל (כלומר, המידע הביומטרי מושבת באופן זמני עד שהמשתמש ימתין זמן מה עקב יותר מדי ניסיונות כושלים, ננעל גם את כל שאר נתונים ביומטריים של קבוצה ביומטרית נמוכה יותר. במקרה של נעילה לזמן מוגבל, זמן ההשהיה לפני ניסיון חוזר לאימות ביומטרי חייב להיות זמן ההשהיה המקסימלי של כל המידע הביומטרי בנעילה מוגבלת בזמן.
[C-SR-12] מומלץ מאוד כאשר מידע ביומטרי נמצא בנעילה (למשל, המידע הביומטרי מושבת עד שהמשתמש מבטל את הנעילה באמצעות אימות ראשי) או נעילה לזמן מוגבל (כלומר, המידע הביומטרי מושבת באופן זמני עד המשתמש ממתין לפרק זמן מסוים) עקב יותר מדי ניסיונות כושלים, כדי גם לנעול את כל שאר הנתונים הביומטריים מאותו סיווג ביומטרי. במקרה של נעילה לזמן מוגבל, זמן ההשהיה לפני ניסיון חוזר לאימות ביומטרי מאוד מומלץ להגדיר את משך ההשהיה המקסימלי לפני ניסיון חוזר של כל המידע הביומטרי תלוי בזמן בזמן האחרון.
[C-7-2] חובה לאתגר את המשתמש לגבי האימות הראשי המומלץ (לדוגמה: קוד אימות, קו ביטול נעילה, סיסמה) כדי לאפס את מונה הנעילה של מידע ביומטרי ננעלת מחוץ למכשיר. ייתכן שנאפשר להשתמש בנתונים ביומטריים ברמה 3 כדי לאפס את הנעילה מונה נעול על מידע ביומטרי נעול של אותה רמה או קבוצה נמוכה יותר. רמה 2 או ברמה 1 אסור לאפשר לנתונים ביומטריים להשלים נעילה של איפוס נתונים ביומטריים כלשהם.
[C-SR-3] מומלץ מאוד לדרוש אישור ביומטרי אחד בלבד לכל אימות (למשל, אם יש גישה גם לחיישני טביעות האצבע וגם לחיישן הפנים במכשיר, onAuthenticationSuled יש לשלוח לאחר אישור אחד מהם).
כדי שהטמעות המכשירים יאפשרו גישה למפתחות של מאגר מפתחות אפליקציות צד שלישי:
- [C-6-1] חייבת לעמוד בדרישות של רמה 3, כפי שמוגדר כאן שבהמשך.
- [C-6-2] חובה להציג נתונים ביומטריים של רמה 3 בלבד במהלך האימות מחייב BIOMETRIC_STRONG, או שהאימות מופעל באמצעות CryptoObject.
אם בהטמעות במכשירים רוצים להתייחס לחיישן ביומטרי כמו רמה 1 (לשעבר נוחות), הן:
- [C-1-1] שיעור קבלה שגוי חייב להיות נמוך מ-0.002%.
- [C-1-2] חובה לציין שהמצב הזה עלול להיות פחות מאובטח מקוד אימות חזק. הסיסמה או הדפוס, ולפרט בבירור את הסיכונים שכרוכים בהפעלתו, אם שיעורי האישורים של זיוף והתחזות גבוהים מ-7%, כפי שנמדד על ידי פרוטוקולים לבדיקה של נתונים ביומטריים במערכת Android.
- [C-1-9] חובה לאתגר את המשתמש לגבי האימות הראשי המומלץ (למשל קוד אימות, קו ביטול נעילה, סיסמה) אחרי עשרים ניסיונות כושלים לכל היותר פחות מתשעים שניות לפני ניסיון חוזר לצורך אימות ביומטרי, כאשר ניסוי שקרי הוא ניסיון עם איכות צילום הולמת (BIOMETRIC_ACQUIRED_GOOD) שלא תואם למידע ביומטרי רשום.
- [C-SR-4] מומלץ מאוד להקטין את המספר הכולל של הניסיונות השגויים לאימות ביומטרי שמצוין בסעיפים [C-1-9], אם הזיוף והמתחזה שיעורי הקבלה גבוהים מ-7% כפי שנמדד על ידי הנתונים הביומטריים של Android פרוטוקולים של בדיקה.
- [C-1-3] חובה לנסות להגבלת קצב של יצירת הבקשות לאימות ביומטרי, כאשר מספר
ניסוי שקרי הוא ניסיון עם איכות צילום הולמת
(
BIOMETRIC_ACQUIRED_GOOD
) שלא תואם למידע ביומטרי רשום. - [C-SR-5] מומלץ מאוד להגביל את מספר הניסיונות להגבלת קצב של יצירת בקשות לפחות 30 שניות לאחר חמש ניסויי שווא לאימות ביומטרי עבור המספר המקסימלי של בדיקות שווא לכל [C-1-9] - כאשר ניסיון שווא הוא אחד איכות צילום הולמת (BIOMETRIC_ACQUIRED_GOOD) שלא תואמת מידע ביומטרי רשום.
- [C-SR-6] מומלץ מאוד להפעיל את כל הלוגיקה של הגבלת קצב של יצירת בקשות ב-TEE.
- [C-1-10] חובה להשבית את המידע הביומטרי לאחר ההשהיה לפני ניסיון חוזר של האימות הראשי מופעלת לראשונה, כפי שמתואר בקטע [C-0-2] של סעיף 9.11.
- [C-1-11] שיעור הבקשות של זיוף ומתחזה חייב להיות נמוך מ-30%, עם (1) שיעור הצטרפות של מתחזה ומתחזה למצגת ברמה א' מין של כלי תקיפה (PAI) שגודלם לא עולה על 30%, ו-(2) זיוף שיעור קבלת המתחזה של מין PAI ברמה B שאינו גבוה מ-40%, כמו שנמדדות באמצעות פרוטוקולים לבדיקת ביומטריה של Android.
- [C-1-4] חובה למנוע הוספה של מידע ביומטרי חדש בלי לאמת קודם שרשרת אמון, באמצעות בקשה מהמשתמש לאשר קיים או להוסיף מכשיר חדש פרטי כניסה (קוד אימות/דפוס/סיסמה) שמאובטחים על ידי TEE, Android Open הטמעת פרויקט מקור מספקת במסגרת המסגרת את המנגנון לביצוע אז.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-1-5] חובה להסיר לחלוטין את כל הנתונים הביומטריים שניתנים לזיהוי של המשתמש כשמסירים את החשבון של המשתמש (כולל באמצעות איפוס להגדרות המקוריות) או מתי האימות הראשי המומלץ (למשל, קוד אימות, קו ביטול נעילה, סיסמה) הוסרו.
סיום הדרישות החדשות
- [C-1-6] חובה לכבד את הדגל הספציפי של אותו מידע ביומטרי (למשל,
DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
,DevicePolicymanager.KEYGUARD_DISABLE_FACE
, אוDevicePolicymanager.KEYGUARD_DISABLE_IRIS
).
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-1-7] חובה לאתגר את המשתמש לגבי האימות הראשי המומלץ
(כמו קוד אימות, קו ביטול נעילה, סיסמה) פעם ב-24 שעות או פחות.
הערה: שדרוג מכשירים שהושקו ב-Android מגרסה 9 ומטה חייבים לבקש מהמשתמש לבצע את האימות הראשי המומלץ (כמו קוד אימות, קו ביטול נעילה, סיסמה) אחת ל-72 שעות או פחות.
סיום הדרישות החדשות
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-1-8] חובה לאתגר את המשתמש לתחרות הראשית המומלצת
אימות (למשל קוד אימות, קו ביטול נעילה, סיסמה) או מידע ביומטרי ברמה 3 (חזק)
אחרי אחד מהתנאים הבאים:
- פרק זמן של 4 שעות ללא פעילות, או
- 3 ניסיונות לאימות ביומטרי שנכשלו.
- פרק הזמן הקצוב לתפוגה שהוגדר לחוסר פעילות וספירת האימות שנכשלה תאופס
אחרי כל אישור של פרטי הכניסה של המכשיר.
הערה: שדרוג המכשירים הושק ב-Android בגרסה 9 או גרסאות קודמות עשויות להיות פטורות מקוד C-1-8.
סיום הדרישות החדשות
- [C-SR-7] מומלץ מאוד להשתמש בלוגיקה במסגרת המסגרת הרעיונית בפרויקט הקוד הפתוח של Android כדי לאכוף את המגבלות שצוינו [C-1-7] ו-[C-1-8] למכשירים חדשים.
- [C-SR-8] מומלץ מאוד לציין שיעור דחייה שקרי של פחות מ-10%, כפי שנמדד במכשיר.
- [C-SR-9] מומלץ מאוד שזמן האחזור יהיה פחות משנייה אחת, לפי המדידה מרגע הזיהוי של המידע הביומטרי ועד לביטול נעילת המסך, מידע ביומטרי רשום.
- [C-1-12] שיעור הבקשות של זיוף והתחזות לא יכול להיות גבוה מ-40% לכל כלי תקיפה של תצוגה (PAI), כפי שנמדד על ידי פרוטוקולים לבדיקה של נתונים ביומטריים ב-Android.
- [C-SR-13] מומלץ מאוד להשתמש בזיוף שיעור קבלת המתחזה לא גבוה מ-30% לכל כלי תקיפה של תצוגה (PAI), כפי שנמדד על ידי פרוטוקולים לבדיקה של נתונים ביומטריים ב-Android.
- [C-SR-8] מומלץ מאוד לציין שיעור דחייה שקרי של פחות מ-10%, כפי שנמדד במכשיר.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-1-15] חובה לאפשר למשתמשים להסיר מידע ביומטרי אחד או יותר חדשים.
סיום הדרישות החדשות
[C-SR-14] מומלץ מאוד לחשוף את הסיווג הביומטרי של מהחיישן הביומטרי והסיכונים הקשורים להפעלתו.
[C-SR-17] מומלץ מאוד להטמיע את ממשקי AIDL החדשים (למשל:
IFace.aidl
ו-IFingerprint.aidl
).
אם בהטמעות במכשירים רוצים להתייחס לחיישן ביומטרי כמו רמה 2 (לשעבר חלשות), הן:
- [C-2-1] חייבת לעמוד בכל הדרישות של רמה 1 שמפורטות למעלה.
- [C-2-2] שיעור הבקשות של זיוף ומתחזה חייב להיות נמוך מ-20%, עם (1) שיעור הסכמה של זיוף ומתחזה מין של כלי תקיפה מסוג מצגת ברמה A (PAI) שאינם גבוהים מ-20%, ו-(2) שיעור הבקשות של זיוף ומתחזה של מינים שונים של PAI ברמה B. גבוה מ-30%, כפי שנמדד על ידי פרוטוקולים לבדיקה של נתונים ביומטריים במערכת Android.
- [C-SR-15] מומלץ מאוד להשתמש בזיוף או במתחזה שיעור קבלה לא גבוה מ-20% לכל כלי תקיפה של תצוגה (PAI), כפי שנמדד על ידי פרוטוקולים לבדיקה של נתונים ביומטריים ב-Android.
- [C-2-3] חייבים לבצע את התאמה ביומטרית בסביבת ביצוע מבודדת מחוץ ל-Android של המשתמש או של הליבה שלו, למשל סביבת ביצוע מהימנה (TEE), בצ'יפ עם ערוץ מאובטח לסביבת ההפעלה המבודדת או במכונה וירטואלית מוגנת שעומדת בדרישות שמפורטות בסעיף 9.17.
- [C-2-4] כל הנתונים המזהים צריכים להיות מוצפנים וקריפטוגרפיים. שעברו אימות כך שלא ניתן יהיה לרכוש אותם, לקרוא אותם או לשנות אותם מחוץ ל את סביבת הביצוע המבודדת או צ'יפ עם ערוץ מאובטח סביבת הפעלה מבודדת, כפי שמתועד בהטמעה הנחיות באתר הפרויקט של Android בקוד פתוח או במכונה וירטואלית מוגנת בשליטת hypervisor שעומדת בדרישות שמפורטות בסעיף 9.17.
- [C-2-5] למידע ביומטרי שמבוסס על מצלמה, תוך אימות ביומטרי
או מתבצע רישום:
- חובה להפעיל את המצלמה במצב שמונע מפריימים של המצלמה קריאה או שינוי מחוץ לסביבת הביצוע המבודדת או בצ'יפ באמצעות ערוץ מאובטח לסביבת הפעלה מבודדת מכונה וירטואלית הנשלטת על ידי hypervisor שעומדת בדרישות שבסעיף 9.17.
- בפתרונות RGB למצלמה אחת, ניתן להשתמש בפריימים של המצלמה קריא מחוץ לסביבת הביצוע המבודדת כדי לתמוך בפעולות כמו תצוגה מקדימה להרשמה, אבל עדיין אסור שתהיה אפשרות לשנות אותו.
- [C-2-6] אסור לאפשר לאפליקציות של צד שלישי להבחין בין נתונים ביומטריים אישיים.
- [C-2-7] אסור לאפשר גישה לא מוצפנת לנתונים ביומטריים שניתנים לזיהוי, או את הנתונים הנובעים ממנו (כגון הטמעות) אל מעבד האפליקציות מחוץ להקשר של רשת TEE או של מכונה וירטואלית מוגנת בשליטת על ידי hypervisor שעומד בדרישות בסעיף 9.17. מכשירים משודרגים שהושקו בגרסת Android 9 או גרסאות קודמות לא פטורים מ-C-2-7.
[C-2-8] חייב להיות צינור עיבוד נתונים מאובטח, כך פגיעה במערכת או בליבה לא יכולה לאפשר להחדיר נתונים ישירות לבצע אימות שקרי כמשתמש. הערה: אם הטמעות המכשיר כבר הושקו ב-Android בגרסה 9 או גרסאות קודמות ולא יכולים לעמוד בדרישה של C-2-8 דרך תוכנת מערכת ייתכן שהם יהיו פטורים מהדרישה הזו.
[C-SR-10] מומלץ מאוד לכלול זיהוי מצב חיים לכולם שיטות ביומטריות וזיהוי תשומת לב לזיהוי ביומטרי של פנים.
[C-2-9] החיישן הביומטרי חייב להיות זמין לצד שלישי תרגום מכונה.
אם בהטמעות במכשירים רוצים להתייחס לחיישן ביומטרי כמו רמה 3 (לשעבר Strong), הן:
- [C-3-1] חייב לעמוד בכל הדרישות של סיווג 2 שלמעלה, מלבד [C-1-7] ו-[C-1-8].
- [C-3-2] חייבת להיות הטמעה של מאגר מפתחות שמגובה בחומרה.
- [C-3-3] שיעור הבקשות של זיוף והתחזות לא יכול להיות גבוה מ-7%, עם (1) שיעור הסכמה של זיוף ומתחזה מין של כלי תקיפה מסוג PAI (רמה A) שלא עולה על 7%, ו (2) שיעור הבקשות של זיוף והתחזות למין PAI ברמה B לא גבוה יותר מ-20%, כפי שנמדד על ידי פרוטוקולים לבדיקה של נתונים ביומטריים במערכת Android.
- [C-3-4] חובה לאתגר את המשתמש לתחרות הראשית המומלצת אימות (כמו קוד אימות, קו ביטול נעילה, סיסמה) פעם אחת בכל 72 שעות או פחות.
- [C-3-5] חובה ליצור מחדש מזהה מאמת לכל המידע הביומטרי ברמה 3 שנתמך במכשיר, אם אחת מהן נרשמו מחדש.
- [C-3-6] חובה להפעיל לצד שלישי מפתחות של מאגר מפתחות עם גיבוי ביומטרי תרגום מכונה.
[C-SR-16] מומלץ מאוד להשתמש במתחזה או במתחזה שיעור ההצטרפות לא גבוה מ- 7% לכל מין של כלי תקיפה מסוג PAI, כפי שנמדד על ידי פרוטוקולים לבדיקה של נתונים ביומטריים ב-Android. אם בהטמעות המכשיר יש חיישן טביעות אצבע מתחת למסך (UDFPS), הם:
[C-SR-11] מומלץ מאוד למנוע את האזור שאפשר לגעת בו ב-UDFPS מהפרעה לניווט ב-3 לחצנים( חלק מהמשתמשים עשויים להזדקק לו למטרות נגישות).
7.3.11. חיישן תנוחה
הטמעות מכשירים:
- MAY תמיכה בחיישן תנוחה עם 6 דרגות חופש.
אם יישומים של מכשירים תומכים בחיישן תנוחת מיקום עם 6 דרגות חופש:
- [C-1-1] חובה להטמיע את
TYPE_POSE_6DOF
ולדווח עליו באמצעות חיישן. - [C-1-2] חייב להיות מדויק יותר מהווקטור הסיבוב לבדו.
7.3.12. חיישן זווית ציר
אם בהטמעות במכשירים יש תמיכה בחיישן זווית של ציר:
- [C-1-1] חובה להטמיע את
TYPE_HINGLE_ANGLE
ולדווח עליו. - [C-1-2] חייבת לתמוך לפחות בשתי קריאות בין 0 ל-360 מעלות (כולל, למשל 0 ו-360 מעלות).
- [C-1-3] חייב להחזיר התעוררות
החיישן של
getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)
.
7.3.13. IEEE 802.1.15.4 (UWB)
אם הטמעות המכשיר כוללות תמיכה ב-802.1.15.4 וחושפים את פונקציונליות באפליקציה של צד שלישי:
- [C-1-2] חובה לדווח על הדגל של תכונת החומרה
android.hardware.uwb
. - [C-1-3] חייבת לתמוך בכל ערכות התצורה הבאות (מוגדרות מראש
שילובים של פרמטרים של FIRA UCI)
שמוגדר בהטמעת ה-AOSP.
CONFIG_ID_1
: טווחSTATIC STS DS-TWR
של unicast בהגדרת FiRa, מצב דחוי, טווח של 240 אלפיות השנייה.CONFIG_ID_2
: טווחSTATIC STS DS-TWR
בהגדרת FiRa, אחד לרבים, מצב דחוי, טווח של 200 אלפיות השנייה. תרחיש נפוץ: טלפון חכם יוצרת אינטראקציה עם מכשירים חכמים רבים.CONFIG_ID_3
: זהה ל-CONFIG_ID_1
, מלבד זווית ההגעה (AoA) לא מתבצע דיווח על נתונים.CONFIG_ID_4
: זהה למצבCONFIG_ID_1
, מלבד מצב האבטחה P-STS מופעל.CONFIG_ID_5
: זהה למצבCONFIG_ID_2
, מלבד מצב האבטחה P-STS מופעל.CONFIG_ID_6
: זהה למצבCONFIG_ID_3
, מלבד מצב האבטחה P-STS מופעל.CONFIG_ID_7
: זהה ל-CONFIG_ID_2
, מלבד בעל שליטה יחיד ב-P-STS מצב המקשים מופעל.
- [C-1-4] חובה לספק למשתמש מחיר כניסה כדי לאפשר לו להחליף מצב של UWB הפעלה/כיבוי של הרדיו.
- [C-1-5] חובה לאכוף באפליקציות שמשתמשות ברדיו UWB להחזיק את
UWB_RANGING
הרשאה (מתחת לקבוצת ההרשאותNEARBY_DEVICES
).
לעבור את בדיקות התאימות והאישור הרלוונטיות שהוגדרו לפי תקן ארגונים, כולל FIRA, עותק מוסתר וגם CSA דואגת לכך שהגדרה 802.1.15.4 תפעל בצורה תקינה.
7.4. קישוריות נתונים
7.4.1. טלפוניה
'טלפוניה' כפי שנעשה בהם שימוש בממשקי Android API, והמסמך הזה מתייחס באופן ספציפי חומרה שקשורה לביצוע שיחות קוליות ולשליחת הודעות SMS, או יצירת חבילת גלישה דרך רשת סלולרית (למשל GSM, CDMA, LTE, NR) או CDMA עמוקה מאוד, מכשיר שתומך באפשרות 'טלפוניה' עשויה לבחור להציע חלק שירותי התקשרות, העברת הודעות ונתונים בהתאם למוצר.
- ניתן להשתמש ב-Android MAY במכשירים שלא כוללים חומרת טלפון. ש Android תואם למכשירים שאינם טלפונים.
אם ההטמעות של המכשירים כוללות טלפוניה מסוג GSM או CDMA, הן:
- [C-1-1] חובה להצהיר על דגל הפיצ'ר
android.hardware.telephony
סימונים של תכונות משנה אחרות בהתאם לטכנולוגיה. - [C-1-2] חייבים להטמיע תמיכה מלאה ב-API בטכנולוגיה הזו.
- צריכה לאפשר את כל סוגי השירותים הסלולריים הזמינים (2G, 3G, 4G, 5G וכו')
במהלך שיחות חירום (ללא קשר לסוגי הרשתות שהוגדרו
SetAllowedNetworkTypeBitmap()
).
אם ההטמעות של מכשירים לא כוללות חומרת טלפון:
- [C-2-1] חובה להטמיע את כל ממשקי ה-API כללא תפעול.
אם בהטמעות המכשיר יש תמיכה ב-eUICC, בכרטיסי eSIM או בכרטיסי SIM מוטמעים, וגם מנגנון קנייני להפיכת הפונקציונליות של eSIM לזמינה עבור צדדים שלישיים מפתחים:
- [C-3-1] חובה להצהיר על
android.hardware.telephony.euicc
דגל של פיצ'ר.
אם יישומים של מכשירים לא מגדירים את מאפיין המערכת ro.telephony.iwlan\_operation\_mode
כ'מדור קודם', הם:
- [C-4-1] אסור לדווח על 'NETWORK_TYPE_IWLAN' באמצעות NetworkRegistrationInfo#getAccessNetworkTechnology() כאשר NetworkRegistrationInfo#getTransportType() מדווח כ-'TRANSPORT_TYPE_WWAN' אותה מכונת NetworkRegistrationInfo.
אם בהטמעות של המכשיר יש תמיכה בתת-מערכת מולטימדיה אחת (IMS) של IP הרשמה לשירות טלפוניה מולטימדיה (MMTEL) וגם תכונות של שירותי תקשורת מגוונים (RCS) וצפויים לעמוד בדרישות עם דרישות של ספק סלולר בנוגע לשימוש רישום IMS לכל תנועת ה-IMS שמצביעה על תנועה, אנשי החברה:
- [C-5-1] חובה להצהיר על
android.hardware.telephony.ims
ולספק יישום מלא של התכונה ImsService API גם ל-MMTEL וגם ל-RCS User Capability Exchange API. - [C-5-2] חובה להצהיר על
android.hardware.telephony.ims.singlereg
סימון תכונה חדשה ולספק הטמעה מלאה של SipTransport API, GbaService API, אינדיקציה למוכ"ז ייעודי באמצעות IRadio 1.6 HAL והקצאה באמצעות שרת הגדרה אוטומטית (ACS) או הקצאה קניינית אחרת באמצעות IMS Configuration API.
אם הטמעות המכשירים מדווחות על התכונה android.hardware.telephony
, אז:
- [C-6-1]
SmsManager#sendTextMessage
ו-SmsManager#sendMultipartTextMessage
התוצאות חייבות להוביל לקריאות תואמות אלCarrierMessagingService
לצורך אספקת פונקציונליות של העברת הודעות טקסט.SmsManager#sendMultimediaMessage
וגםSmsManager#downloadMultimediaMessage
התוצאות חייבות להוביל לקריאות תואמות אלCarrierMessagingService
לצורך אספקת פונקציונליות של העברת הודעות מולטימדיה. - [C-6-2] הבקשה שסווגה על ידי
android.provider.Telephony.Sms#getDefaultSmsPackage
חובה להשתמש SmsManager ממשקי API לשליחה ולקבלה של הודעות SMS ו-MMS. מסמך העזר של AOSP בחבילות/באפליקציות או ב'העברת הודעות', עומדים בדרישה הזו. - [C-6-3] האפליקציה שמגיבה
Intent#ACTION_DIAL
חייבת להיות תמיכה בהזנה של קודי חייגן שרירותיים בפורמט*#*#CODE#*#*
וגם מפעילהTelephonyManager#ACTION_SECRET_CODE
שידור. - [C-6-4] האפליקציה שמגיבה
Intent#ACTION_DIAL
חובה להשתמשVoicemailContract.Voicemails#TRANSCRIPTION
כדי להציג למשתמשים תמלול של דואר קולי ויזואלי, אם הוא תומך בפיצ'רים חזותיים תמלול ההודעות הקוליות. - [C-6-5] חייב לייצג את כל SubscriptionInfo עם נתונים שווי ערך
מזהי UUID קבוצתיים
כמנוי יחיד בכל העלויות הגלויות למשתמשים שמציגים
שליטה בפרטי כרטיס ה-SIM. דוגמאות להוצאות כאלה כוללות הגדרות
ממשקים שתואמים
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
אוEuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
- [C-6-6] אסור להציג או לאפשר שליטה ב-SubscriptionInfo עם UUID של קבוצה שאינו null וביט הזדמנויות בכל מחיר שנראה למשתמש לאפשר תצורה או שליטה בהגדרות של כרטיס SIM.
אם בהטמעות המכשירים מדווחות על התכונה android.hardware.telephony
ומספקים שורת סטטוס מערכת, ואז:
- [C-7-1] חובה לבחור מינוי פעיל שמייצג UUID קבוצתי להצגה למשתמש תמורת הטבות שניתנות עבור סטטוס כרטיס ה-SIM. מידע. דוגמאות להוצאות כאלה כוללות את שורת הסטטוס 'סלולרי' סמל האות או לחצן ההגדרות המהירות.
- [C-SR-1] מומלץ מאוד שהמינוי של הנציג נבחר להיות מינוי לנתונים פעילים אלא אם המכשיר הוא בקול שבמהלכה מומלץ מאוד שהנציג המינוי הוא המינוי הפעיל ל-Voice.
אם הטמעות המכשירים מדווחות על התכונה android.hardware.telephony
, אז:
- [C-6-7] חייבת להיות יכולת לפתוח ולנצל בו-זמנית את הערך המקסימלי מספר הערוצים הלוגיים (20 בסך הכול) לכל UICC בהתאם לתקן ETSI TS 102 221.
- [C-6-8] אסור להחיל אף אחת מההתנהגויות הבאות על אפליקציות ספק פעילות
(כפי שהוגדר על ידי
TelephonyManager#getCarrierServicePackageName
) באופן אוטומטי או ללא אישור מפורש של המשתמש:- ביטול הגישה לרשת או הגבלה שלה
- ביטול הרשאות
- הגבלת הביצוע של אפליקציות ברקע או בחזית מעבר לתכונות ניהול צריכת החשמל הקיימות שכלולות ב-AOSP
- השבתה או הסרה של האפליקציה
אם ההטמעה של המכשירים מדווחת על התכונה android.hardware.telephony
וגם
כל הפעילות,
מינויים לא הזדמנויות
שחולקים מזהה ייחודי אוניברסלי (UUID) של קבוצה מושבתים,
הוסר פיזית מהמכשיר, או מסומן כיצירתי, אז המכשיר:
- [C-8-1] חובה להשבית באופן אוטומטי את כל שאר הפעילויות הפעילות הזדמנויות למינויים באותה קבוצה.
אם אופן ההטמעה של המכשירים כולל טלפוניה GSM אבל לא טלפוניה מסוג CDMA, הם:
- [C-9-1] אסור להצהיר על
PackageManager#FEATURE_TELEPHONY_CDMA
. - [C-9-2] חובה להשליך
IllegalArgumentException
בניסיון לקבוע סוגי רשתות 3GPP2 במסיכות ביט מסוג רשת מועדף או מותר. - [C-9-3] חייבת להחזיר מחרוזת ריקה מ:
TelephonyManager#getMeid
אם בהטמעות המכשיר תומכות ב-eUICC עם כמה יציאות ופרופילים, הן:
- [C-10-1] חובה להצהיר על
android.hardware.telephony.euicc.mep
דגל של פיצ'ר.
7.4.1.1. תאימות לחסימת מספרים
אם הטמעות במכשירים ידווחו על התכונה android.hardware.telephony.calling
, הן:
- [C-1-1] חייבת לכלול תמיכה בחסימת מספרים
- [C-1-2] חובה להטמיע את
BlockedNumberContract
באופן מלא וממשק ה-API התואם, כפי שמתואר במסמכי התיעוד של ה-SDK. [C-1-3] חובה לחסום את כל השיחות וההודעות ממספר טלפון אחד 'BlockNumberProvider' ללא אינטראקציה עם האפליקציות. יוצא הדופן היחיד היא תופסק כשחסימת המספרים תופסק באופן זמני, כפי שמתואר ב-SDK התיעוד.
[C-1-4] חובה לכתוב אל ספק יומן השיחות בפלטפורמה עבור שיחה שנחסמה וחובה לסנן שיחות עם
BLOCKED_TYPE
תצוגת ברירת המחדל של יומן השיחות באפליקציית החייגן שהותקנה מראש.[C-1-5] אסור לכתוב לספק הטלפוניה להודעה שנחסמה.
[C-1-6] חובה להטמיע ממשק משתמש חסום לניהול מספרים, שנפתח עם הכוונה שהוחזרה על ידי
TelecomManager.createManageBlockedNumbersIntent()
.[C-1-7] אסור לאפשר למשתמשים משניים לצפות במספרים החסומים או לערוך אותם במכשיר, כי פלטפורמת Android מניחה שהמשתמש הראשי שליטה בשירותי הטלפוניה, מכונה אחת, במכשיר. הכול ממשק משתמש קשור לחסימה חייב להיות מוסתר אצל משתמשים משניים והרשימה החסומה חייבת להיות מוסתרת עדיין יש לכבד אותם.
צריך להעביר את המספרים החסומים לספק כשמכשיר מתעדכן ל-Android 7.0.
האפליקציה צריכה לאפשר למשתמש להציג שיחות חסומות במכשירים שמותקנים מראש אפליקציית חייגן.
7.4.1.2. API של Telecom
אם הטמעות המכשירים ידווחו על android.hardware.telephony.calling
, הן:
- [C-1-1] חייבת לתמוך בממשקי ה-API של
ConnectionService
שמתוארים ב-SDK. - [C-1-2] חובה להציג שיחה נכנסת חדשה ולספק למשתמש אפשרויות עבור
אישור או דחייה של השיחה הנכנסת כשמשתמש בשיחה פעילה
נוצר על ידי אפליקציית צד שלישי שלא תומכת בתכונת ההשהיה
צוין דרך
CAPABILITY_SUPPORT_HOLD
- [C-1-3] חייבת להיות אפליקציה שמממשת InCallService.
[C-SR-1] מומלץ מאוד להודיע למשתמש שעונה על השיחה הנכנסת תנתק את השיחה הנוכחית.
הטמעת ה-AOSP עומדת בדרישות האלה בהתראה 'שימו לב' שמציינת למשתמש שמענה לשיחה נכנסת יגרום הקריאה האחרת תושג.
[C-SR-2] מומלץ מאוד לטעון מראש את אפליקציית החייגן שמוגדרת כברירת מחדל מציגה רשומה ביומן השיחות ואת השם של אפליקציה של צד שלישי ביומן השיחות שלה. כשאפליקציית הצד השלישי מגדירה
EXTRA_LOG_SELF_MANAGED_CALLS
מקש תוספות בPhoneAccount
עדtrue
.[C-SR-3] מומלץ מאוד לטפל באוזניות אירועים של
KEYCODE_MEDIA_PLAY_PAUSE
ו-KEYCODE_HEADSETHOOK
עבורandroid.telecom
ממשקי API הבאים:- התקשרות אל
Connection.onDisconnect()
כשמזוהה לחיצה קצרה על האירוע המרכזי במהלך שיחה פעילה. - התקשרות אל
Connection.onAnswer()
כשמזוהה לחיצה קצרה על האירוע המרכזי במהלך שיחה נכנסת. - התקשרות אל
Connection.onReject()
כשמזוהה לחיצה ארוכה על האירוע המרכזי במהלך שיחה נכנסת. - החלפת מצב ההשתקה של
CallAudioState
.
- התקשרות אל
7.4.1.3. העברה ל-Keepalive לרשת סלולרית מסוג NAT-T
הטמעות מכשירים:
- היא צריכה לכלול תמיכה בהפחתה לעומס (Keepalive) ברשת סלולרית.
אם ההטמעות במכשיר כוללות תמיכה בעומס (payalive) לרשת סלולרית, וגם חושפת את הפונקציונליות לאפליקציות צד שלישי, היא:
- [C-1-1] חייבת לתמוך ב-SocketKeepAlive API.
- [C-1-2] חייבת להיות תמיכה בלפחות חריץ מודעה אחד בו-זמנית לפחות ברשת סלולרית.
- [C-1-3] חייבת לתמוך בכמה שיותר משבצות שידור פעילות סלולריות בו-זמנית נתמך על ידי HAL של רדיו סלולרי.
- [C-SR-1] מומלץ מאוד לתמוך בלפחות שלושה חיישנים של רשת סלולרית משבצות לכל מופע רדיו.
אם יישומי המכשיר לא כוללים תמיכה בהורדה של עומסי עבודה ברשת סלולרית, הם:
- [C-2-1] חייב להחזיר ERROR_UNSUPPORTED.
7.4.2. IEEE 802.11 (Wi-Fi)
הטמעות מכשירים:
- היא צריכה לכלול תמיכה עבור צורה אחת או יותר של 802.11.
אם הטמעות המכשירים כוללות תמיכה ב-802.11 וחושפים את פונקציונליות באפליקציה של צד שלישי:
- [C-1-1] חובה להטמיע את Android API התואם.
- [C-1-2] חובה לדווח על הדגל של תכונת החומרה
android.hardware.wifi
. - [C-1-3] חובה להטמיע את multicast API כפי שמתואר במסמכי התיעוד של ה-SDK.
יצירת דרישות חדשות לגיל 15 (תוכנית AOSP ניסיונית)
- [C-1-4] חייב לתמוך ב-DNS מרובה-מכשירים (mDNS) ואסור לסנן חבילות mDNS (224.0.0.251 או ff02::fb) בכל זמן הפעלה, גם בזמן שהמסך אינו במצב פעיל, אלא אם שחרור או סינון המנות האלה נדרשים כדי להישאר בטווחי צריכת החשמל הנדרשים על פי רגולציה בדרישות הרלוונטיות לשוק היעד.
- [C-1-4] חובה לתמוך ב-mDNS ואסור לסנן חבילות mDNS (224.0.0.251 או ff02::fb) בכל זמן, כולל המסך לא במצב פעיל, אלא אם נעילת Multicast לא מוחזקת החבילות מסוננות על ידי APF. החבילות לא נדרשות פעולות mDNS שהתבקשו כרגע על ידי אפליקציות דרך NsdManager ממשקי API. עם זאת, המכשיר עשוי לסנן מנות mDNS אם יש צורך בכך להישאר בטווחים של צריכת החשמל הנדרשת על פי הדרישות הרגולטוריות הרלוונטי לשוק היעד.
סיום הדרישות החדשות
- [C-1-5] אסור לטפל ב
WifiManager.enableNetwork()
הקריאה לשיטת ה-API כאינדיקציה מספקת לשינוי המצב הפעיל הנוכחיNetwork
שמשמש כברירת מחדל לתנועת אפליקציות, ומוחזר מאתConnectivityManager
שיטות API כמוgetActiveNetwork
וגםregisterDefaultNetworkCallback
. במילים אחרות, הם עשויים להשבית רק את הגישה לאינטרנט שמסופקת על ידי מישהו ספק רשת אחר (למשל, חבילת גלישה) אם הוא אימת בהצלחה שרשת ה-Wi-Fi מספקת גישה לאינטרנט. - [C-1-6] מומלץ מאוד במקרים שבהם
ConnectivityManager.reportNetworkConnectivity()
נקראת 'שיטת ה-API', בדקו מחדש את הגישה לאינטרנט בNetwork
. ברגע שההערכה קובעת שה-Network
הנוכחי לא מספק יותר גישה לאינטרנט, מעבר לכל רשת זמינה אחרת (למשל, רשת סלולרית שמספק גישה לאינטרנט. - [C-1-7] כתובת ה-MAC של המקור ומספר הרצף של גליל המכשיר צריכים להיות אקראיים בקשות למסגרות זמן, פעם אחת בתחילת כל סריקה, בזמן ש-STA מנותק.
- [C-1-8] חובה להשתמש בכתובת MAC עקבית אחת (לא צריכה להיות כתובת MAC אקראית כתובת באמצע הסריקה).
- [C-1-9] מספר הרצף של בקשת הבדיקה חייב לחזור כרגיל (ברציפות) בין בקשות גשושיות בסריקה.
- [C-1-10] מספר הרצף של בקשת גשושית הבדיקה צריך להיות אקראי בין גשוש האחרון לבקשת סריקה ובקשת גשושית הסריקה הראשונה של הסריקה הבאה.
- [C-SR-1] מומלץ מאוד להגדיר באקראי את כתובת ה-MAC של המקור
את כל התקשורת מסוג STA לנקודת גישה (AP) בזמן השיוך
שמשויכים לכל אחד.
- המכשיר חייב להשתמש בכתובת MAC אקראית שונה לכל SSID (FQDN ל-Passpoint) היא מתקשרת.
- המכשיר חייב לספק למשתמש אפשרות לשלוט רנדומיזציה לפי SSID (FQDN ל-Passpoint) ללא אקראיות אפשרויות אקראיות, וחייב להגדיר את מצב ברירת המחדל עבור רשתות Wi-Fi חדשות להגדרות אקראיות.
- [C-SR-2] מומלץ מאוד להשתמש ב-BSSID אקראי לכל AP שהם
יוצרים.
- כתובת ה-MAC חייבת להיות אקראית ותישמר בהתאם ל-SSID שמשמש את AP.
- ייתכן שה-DEVICE יכול לספק למשתמש אפשרות להשבית את התכונה הזו. אם קיימת אפשרות כזו, הרנדומיזציה חייבת להיות מופעלת כברירת מחדל.
אם הטמעות המכשיר כוללות תמיכה במצב חיסכון בסוללה ב-Wi-Fi, כפי שהוגדר בתקן IEEE 802.11 הן:
- יש להשבית את מצב החיסכון בסוללה ב-Wi-Fi בכל פעם שמתקבלת אפליקציה
מנעול אחד (
WIFI_MODE_FULL_HIGH_PERF
) או מנעולWIFI_MODE_FULL_LOW_LATENCY
דרךWifiManager.createWifiLock()
וגםWifiManager.WifiLock.acquire()
ממשקי ה-API והנעילה פעילים. - [C-3-2] זמן האחזור הממוצע בין המכשיר הלוך ושוב
ונקודת גישה כשהמכשיר נמצא בנעילת Wi-Fi עם זמן אחזור נמוך
המצב (
WIFI_MODE_FULL_LOW_LATENCY
) חייב להיות קטן יותר מהמצב זמן אחזור במהלך מצב 'נעילת ביצועים גבוהה' ב-Wi-Fi (WIFI_MODE_FULL_HIGH_PERF
). - [C-SR-3] מומלץ מאוד למזער את זמן האחזור בנסיעה הלוך ושוב של Wi-Fi
בכל פעם שמתקבלת נעילה של זמן אחזור קצר (
WIFI_MODE_FULL_LOW_LATENCY
) ונכנס לתוקף.
אם הטמעות המכשיר תומכות ב-Wi-Fi ומשתמשים ב-Wi-Fi לסריקת מיקום, הם:
- [C-2-1] חובה לספק למשתמשים אפשרות להפעיל או להשבית את הערך שנקרא
דרך
WifiManager.isScanAlwaysAvailable
שיטת ה-API.
7.4.2.1. Wi-Fi ישיר
הטמעות מכשירים:
- אמורה לכלול תמיכה ב-Wi-Fi ישיר (Wi-Fi מקצה לקצה).
אם הטמעות המכשירים כוללות תמיכה ב-Wi-Fi ישיר:
- [C-1-1] חו