1. מבוא
במסמך הזה מפורטות הדרישות שצריכות להתקיים כדי שיהיו מכשירים שתואם ל-Android 13.
השימוש ב: "חובה", "אסור", "נדרש", "צריך", "אסור", "צריך", 'אסור', 'מומלץ', 'מאי' ו'אופציונלי' בהתאם לתקן IETF מוגדר ב-RFC2119.
כפי שנעשה בו שימוש במסמך הזה, הכלי 'מטמיע מכשירים' או 'כלי יישום' הוא אדם או ארגון המפתח פתרון חומרה/תוכנה שמפעיל את Android 13. 'הטמעה במכשיר' או 'הטמעה' האם הערך חומרה/תוכנה כך שפיתחו.
כדי לקבוע מכשיר שמתאים ל-Android 13, היישומים חייבים לעמוד בדרישות המוצגות בתנאי התאימות הגדרה, כולל כל מסמך שמאוחד באמצעות הפניה.
כאשר ההגדרה הזו או בדיקות התוכנה שמתוארות ב סעיף 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 יסווגו כמכשירים ניידים אם הם עומדים בכל הקריטריונים הבאים:
- מקור כוח שמספק ניידות, כמו סוללה.
- להיות בגודל מסך אלכסון פיזי בטווח של 3.3 אינץ' (או 2.5 אינץ' להטמעות של מכשירים שנשלחו ברמת API 29 או מוקדם יותר) עד 8 אינץ'.
הדרישות הנוספות המפורטות בהמשך הקטע הזה הן ספציפיות ל-Android הטמעות של מכשירים ניידים.
2.2.1. חומרה
הטמעות של מכשירים ניידים:
- [7.1.1.1/H-0-1] חייב להיות לפחות אחד מסך תואם ל-Android שעומד בכל הדרישות שמתוארות במאמר הזה מהמסמך.
[7.1.1.3/H-SR-1] מומלץ מאוד לספק למשתמשים אפשרות לשנות את גודל התצוגה (דחיסות המסך).
[7.1.1.1/H-0-2] חייב לתמוך בהרכב GPU של בתהליך אגירת נתונים גרפיים, בגודל של לפחות כמו הרזולוציה הגבוהה ביותר לכל תוכן מובנה מסך.
אם הטמעות של מכשירים ניידים תומכים בסיבוב מסך בתוכנה:
- [7.1.1.1/H-1-1]* חייב לבצע את המסך הלוגי שזמין באפליקציות של צד שלישי, להיות באורך של 2 אינץ' לפחות קצוות קצרים ו-2.7 אינץ' בשוליים הארוכים. מכשירים שנשלחו ב-Android API ברמה 29 או לפני כן עשויים להיות פטור מהדרישה הזו.
אם הטמעות של מכשירים ניידים לא תומכים בסיבוב המסך בתוכנה, הם:
- [7.1.1.1/H-2-1]* חייב ליצור את המסך הלוגי שזמין באפליקציות של צד שלישי, בגודל של לפחות 2.7 אינץ' את הקצוות הקצרים. מכשירים שנשלחו ב-Android API ברמה 29 או לפני כן עשויים להיות פטור מהדרישה הזו.
אם בהטמעות של מכשירים ניידים יש תמיכה בטווח דינמי גבוה
מוצג באמצעות Configuration.isScreenHdr()
, הם:
- [7.1.4.5/H-1-1] חובה לפרסם תמיכה
EGL_EXT_gl_colorspace_bt2020_pq
,EGL_EXT_surface_SMPTE2086_metadata
EGL_EXT_surface_CTA861_3_metadata
,VK_EXT_swapchain_colorspace
וגםVK_EXT_hdr_metadata
תוספים.
הטמעות של מכשירים ניידים:
- [7.1.4.6/H-0-1] חובה לדווח אם המכשיר
תומך ביכולת הפרופיילינג של ה-GPU דרך מאפיין מערכת
graphics.gpu.profiler.support
.
אם הטמעות של מכשירים ניידים מוצהרות על תמיכה דרך מאפיין מערכת
graphics.gpu.profiler.support
, הן:
- [7.1.4.6/H-1-1] חובה לדווח כפלט מעקב Protobuf שתואם לסכימה של מוני GPU ו-GPU שלבי העיבוד (re אונלייןs) שמוגדרים במסמכי התיעוד של Perfetto.
- [7.1.4.6/H-1-2] חובה לדווח על ערכים תואמים למוני ה-GPU במכשיר אחרי פרוטו של חבילת מעקב נגדי gpu.
- [7.1.4.6/H-1-3] חובה לדווח על ערכים תואמים ל-GPU RenderStages של המכשיר אחרי עיבוד של אובייקט מנות למעקב אחרי שלב.
- [7.1.4.6/H-1-4] חובה לדווח על תדירות GPU trackpoint כפי שצוין בפורמט: power/gpu_frequency.
הטמעות של מכשירים ניידים:
- [7.1.5/H-0-1] חייבת לכלול תמיכה במכשירים מדור קודם מצב תאימות של אפליקציה כפי שמוטמע על ידי ה-upstream הפתוחה של Android קוד המקור. כלומר, אסור שהטמעות במכשירים ישנו את הטריגרים שבהם מופעל מצב תאימות, ואסור לשנות את של מצב התאימות עצמו.
- [7.2.1/H-0-1] חייבת לכלול תמיכה בצדדים שלישיים אפליקציות לעריכת שיטות קלט (IME).
- [7.2.3/H-0-2] חייבים לשלוח גם בלחיצה רגילה וגם בלחיצה ארוכה
אירוע של פונקציית 'הקודם' (
KEYCODE_BACK
) לאפליקציה בחזית. המערכת לא יכולה להשתמש באירועים האלה יכול להיות מופעל על ידי מחוץ למכשיר Android (למשל חומרה חיצונית). המקלדת המחוברת למכשיר Android). - [7.2.3/H-0-3] חייבים לספק את הפונקציה 'בית' ב- כל המסכים התואמים ל-Android שמספקים את מסך הבית.
- [7.2.3/H-0-4] חייבים לספק את פונקציית החזרה בכל המכשירים במסכים התואמים ל-Android ובפונקציה 'אחרונים' לפחות במסכים שתואמים ל-Android.
- [7.2.4/H-0-1] חייב לתמוך בקלט מסך מגע.
- [7.2.4/H-SR-1] מומלץ מאוד להפעיל את
אפליקציית עזרה שהמשתמש בוחר. כלומר, האפליקציה שמטמיעה
VoiceInteractionService או פעילות המטפלת ב-
ACTION_ASSIST
בלחיצה ארוכה עלKEYCODE_MEDIA_PLAY_PAUSE
אוKEYCODE_HEADSETHOOK
אם הפעילות בחזית לא מטפלת באירועים האלה בלחיצה ארוכה. - [7.3.1/H-SR-1] מומלץ מאוד לכלול תמונה עם 3 צירים מד תאוצה.
אם יישומים של מכשירים ניידים כוללים מד תאוצה ב-3 צירים:
- [7.3.1/H-1-1] חייבת להיות אפשרות לדווח על אירועים בתדירות של עד של לפחות 100Hz.
אם יישומים של מכשירים ניידים כוללים מקלט GPS/GNSS ומדווחים על
יכולת לאפליקציות באמצעות התכונה android.hardware.location.gps
הם:
- [7.3.3/H-2-1] חובה לדווח על מדידות GNSS ברגע שהן נמצאים, גם אם המיקום המחושב מ-GPS/GNSS עדיין לא דווח.
- [7.3.3/H-2-2] חובה לדווח על GNSS על מערכים של פסאודוטווח (pseudoranges) ו-pseudoranges בתנאים של שמיים פתוחים לאחר קביעת המיקום, קבוע או נע עם פחות מ-0.2 מטר לשנייה בריבוע תאוצה מספיקה כדי לחשב את המיקום בטווח של 20 מטרים, בטווח של 0.2 מטר לשנייה, לפחות ב-95% מהזמן.
אם מוטמעים במכשיר נייד ג'ירוסקופ עם 3 צירים:
- [7.3.4/H-3-1] חייבת להיות אפשרות לדווח על אירועים בתדירות של עד של לפחות 100Hz.
- [7.3.4/H-3-2] חייבת להיות יכולת למדוד שינויי כיוון עד 1,000 מעלות לשנייה.
יישומים של מכשירים ניידים שמאפשרים לבצע שיחה קולית ולציין
כל ערך מלבד PHONE_TYPE_NONE
ב-getPhoneType
:
- [7.3.8/H] צריכה לכלול חיישן קירבה.
הטמעות של מכשירים ניידים:
- [7.3.11/H-SR-1] מומלץ מאוד לתמוך בחיישן התנוחה עם 6 דרגות חופש.
- [7.4.3/H] צריכה לכלול תמיכה ב-Bluetooth Bluetooth LE.
אם המכשירים תומכים בפרוטוקול Wi-Fi Neighbor Awareness Networking (NAN) על ידי
הצהרה על PackageManager.FEATURE_WIFI_AWARE
ועל מיקום Wi-Fi (עגול Wi-Fi
זמן נסיעה – RTT) על ידי הצהרה על PackageManager.FEATURE_WIFI_RTT
, ואז:
[7.4.2.5/H-1-1] חובה לדווח על הטווח באופן מדויק: בטווח של +/-1 מטר ברוחב פס של 160MHz באחוזון ה-68 (כפי מחושב באמצעות פונקציית ההפצה המצטברת), +/-2 מטרים ברוחב פס של 80MHz האחוזון ה-68, +/-4 מטרים ברוחב פס של 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.
מומלץ מאוד לבצע את השלבים להגדרת המדידה שמפורטים כיול הנוכחות.
אם הטמעות של מכשירים להחזקה ביד כוללות התקן מצלמה לוגי שמפרט
יכולות באמצעות
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
הם:
- [7.5.4/H-1-1] חייב להיות שדה ראייה רגיל (FOV) כברירת מחדל והיא חייבת להיות בין 50 ל-95 מעלות.
הטמעות של מכשירים ניידים:
- [7.6.1/H-0-1] חייבים להיות לפחות 4GB של אחסון בלתי תנודתי שזמין לנתונים פרטיים של האפליקציה (שנקראת גם מחיצת "/data" ).
- [7.6.1/H-0-2] חייב להחזיר את הערך 'true' עבור
ActivityManager.isLowRamDevice()
כשיש פחות מ-1GB בזיכרון זמינים לליבה ולמרחב המשתמשים.
אם הטמעות במכשירים ניידים מצהירות על תמיכה ב-ABI של 32 ביט בלבד:
[7.6.1/H-1-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות 416MB לפחות אם תצוגת ברירת המחדל משתמשת במאגר נתונים זמני רזולוציה של עד qHD (למשל FWVGA).
[7.6.1/H-2-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות 592MB לפחות אם תצוגת ברירת המחדל משתמשת במאגר נתונים זמני רזולוציה של עד HD+ (למשל HD, WSVGA).
[7.6.1/H-3-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות בגודל 896MB לפחות אם בתצוגת ברירת המחדל נעשה שימוש במאגר נתונים זמני ברזולוציה של עד FHD (למשל WSXGA+ ).
[7.6.1/H-4-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות 1344MB לפחות אם תצוגת ברירת המחדל משתמשת רזולוציות של מאגרי נתונים זמניים עד QHD (למשל QWXGA).
אם הטמעות במכשירים ניידים מוצהרות על תמיכה בכל ממשק ABI של 64 ביט (עם או בלי ממשק ABI של 32 ביט):
[7.6.1/H-5-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות יהיה 816MB לפחות אם במסך ברירת המחדל נעשה שימוש ברזולוציות של מאגר נתונים זמני למעלה ל-qHD (למשל FWVGA).
[7.6.1/H-6-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות לפחות 944MB אם צג ברירת המחדל משתמש ברזולוציות של מאגר נתונים זמני עד HD+ (למשל: HD, WSVGA).
[7.6.1/H-7-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות לפחות 1280MB אם מסך ברירת המחדל משתמש ברזולוציית מאגר נתונים זמני של עד FHD (למשל WSXGA+ ).
[7.6.1/H-8-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות לפחות 1824MB אם צג ברירת המחדל משתמש ברזולוציית מאגר נתונים זמני של עד QHD (למשל, QWXGA).
שימו לב ש"הזיכרון שזמין לליבה ולמרחב המשתמשים" שלמעלה מתייחס מקום זיכרון בנוסף לכל זיכרון שכבר מיועד לחומרה כמו רדיו, וידאו וכו', שלא נמצאים במסגרת הליבה שליטה בהטמעות של מכשירים.
אם הטמעות במכשירים ניידים כוללות נפח זיכרון של 1GB או פחות זמינים לליבה ולמרחב המשתמשים, הם:
- [7.6.1/H-9-1] חובה להצהיר על דגל התכונה
android.hardware.ram.low
. - [7.6.1/H-9-2] חייב להיות לפחות 1.1GB של אחסון בלתי נדיף לאפליקציה מידע פרטי (שנקרא גם "מחיצה "/data").
אם הטמעות במכשירים ניידים כוללות יותר מ-1GB של זיכרון פנוי לליבה ולמרחב המשתמשים, הם:
- [7.6.1/H-10-1] חייב להיות בנפח של 4GB לפחות אחסון בלתי נדיף זמין מידע פרטי של האפליקציה (שנקראת גם מחיצה ' /data').
- יש להצהיר על דגל התכונה
android.hardware.ram.normal
.
אם הטמעות במכשירים ניידים כוללות נפח של 2GB או גדול יותר ופחות מ-4GB של זיכרון פנוי ליבה ולמרחב המשתמש, הם:
- [7.6.1/H-SR-1] מומלץ מאוד לתמוך במרחב משתמשים של 32 ביט בלבד (גם אפליקציות וגם קוד מערכת)
אם הטמעות במכשירים ניידים כוללות פחות מ-2GB של זיכרון פנוי את הליבה ומרחב המשתמשים:
- [7.6.1/H-1-1] חייב לתמוך רק ב-ABI אחד (64 ביט בלבד או 32 ביט) בלבד).
הטמעות של מכשירים ניידים:
- [7.6.2/H-0-1] אסור להגיש בקשה נפח אחסון משותף של פחות מ-1GiB.
- [7.7.1/H] צריכה לכלול יציאת USB שתומכת במצב היקפי.
אם הטמעות של מכשירים ניידים כוללות יציאת USB שתומכת בציוד היקפי במצב הזה:
- [7.7.1/H-1-1] חובה להטמיע את Android Open Accessory (AOA) API.
אם הטמעות של מכשירים ניידים כוללות יציאת USB שתומכת במצב מארח, הם:
- [7.7.2/H-1-1] חובה להטמיע את סיווג האודיו בחיבור USB כפי שמתועד בתיעוד של Android SDK.
הטמעות של מכשירים ניידים:
- [7.8.1/H-0-1] חייב לכלול מיקרופון.
- [7.8.2/H-0-1] חייב להיות פלט אודיו וצריך להצהיר עליו
android.hardware.audio.output
.
אם הטמעות של מכשירים ניידים מסוגלות לעמוד בכל הביצועים הדרישות לתמיכה במצב VR וכוללות תמיכה במצב הזה, הן:
- [7.9.1/H-1-1] חובה להצהיר על
סימון תכונה
android.hardware.vr.high_performance
. - [7.9.1/H-1-2] חובה לכלול בקשה
הטמעה של
android.service.vr.VrListenerService
שניתן להפעיל באמצעות VR בקשות דרךandroid.app.Activity#setVrModeEnabled
.
אם בהטמעות של מכשירים ניידים יש יציאת USB-C אחת או יותר במארח למצב ולהטמיע (סיווג אודיו ב-USB), בנוסף לדרישות 7.7.2:
- [7.8.2.2/H-1-1] חייב לספק את מיפוי התוכנה הבא של קודי ממשק אנושי:
פעולה | מיפויים | הקשר | התנהגות |
---|---|---|---|
A | דף שימוש במכשיר HID: 0x0C שימוש ב-HID: 0x0CD מפתח ליבה: KEY_PLAYPAUSE מפתח Android: KEYCODE_MEDIA_PLAY_PAUSE |
הפעלת מדיה | קלט: לחיצה קצרה פלט: הפעלה או השהיה |
קלט: לחיצה ארוכה על פלט: הפעלת פקודה קולית שליחה: android.speech.action.VOICE_SEARCH_HANDS_FREE אם המכשיר
נעול או כשהמסך כבוי. שולח
אחרת, android.speech.RecognizerIntent.ACTION_WEB_SEARCH |
|||
שיחה נכנסת | קלט: לחיצה קצרה פלט: קבלת השיחה |
||
קלט: לחיצה ארוכה על פלט: דחיית השיחה |
|||
שיחה פעילה | קלט: לחיצה קצרה פלט: סיום השיחה |
||
קלט: לחיצה ארוכה על פלט: השתקה או ביטול ההשתקה של המיקרופון |
|||
B | דף שימוש במכשיר HID: 0x0C שימוש ב-HID: 0x0E9 מפתח ליבה: KEY_VOLUMEUP מפתח Android: VOLUME_UP |
הפעלת מדיה, שיחה פעילה | קלט: לחיצה קצרה או ארוכה פלט: מגדיל את עוצמת הקול של המערכת או של האוזניות |
C | דף שימוש במכשיר HID: 0x0C שימוש במכשיר ממשק אנושי (HID): 0x0EA מפתח ליבה: KEY_VOLUMEDOWN מפתח Android: VOLUME_DOWN |
הפעלת מדיה, שיחה פעילה | קלט: לחיצה קצרה או ארוכה פלט: הפחתת עוצמת הקול של המערכת או האוזניות |
D | דף שימוש במכשיר HID: 0x0C שימוש ב-HID: 0x0CF מפתח ליבה: KEY_VOICECOMMAND מפתח Android: KEYCODE_VOICE_ASSIST |
כל ההתראות. ניתן להפעיל בכל מקרה. | קלט: לחיצה קצרה או ארוכה פלט: הפעלת פקודה קולית |
- [7.8.2.2/H-1-2] חייב להפעיל את ACTION_HEADSET_PLUG בזמן כניסת תקע, אבל רק לאחר שממשקי האודיו ונקודות הקצה ב-USB נספר בצורה נכונה כדי לזהות את סוג הטרמינל המחובר.
כשהמערכת מזהה את טרמינל האודיו 0x0302 של USB, הוא:
- [7.8.2.2/H-2-1] חייב לשדר את ה-Intent ACTION_HEADSET_PLUG עם 'מיקרופון' מוגדר ל-0.
כשהמערכת מזהה את טרמינל האודיו 0x0402 של USB, הוא:
- [7.8.2.2/H-3-1] חייב לשדר את ה-Intent ACTION_HEADSET_PLUG עם 'מיקרופון' מוגדר ל-1.
כאשר מתבצעת קריאה ל-API AudioManager.getDevices() כשהציוד ההיקפי ב-USB מופעל קישרו אותו:
[7.8.2.2/H-4-1] חובה לציין מכשיר מסוג AudioDeviceInfo.TYPE_USB_HEADSET והתפקיד isSink() , אם השדה של סוג הטרמינל של אודיו ב-USB הוא 0x0302.
[7.8.2.2/H-4-2] חובה לציין מכשיר מסוג סוג AudioDeviceInfo.TYPE_USB_HEADSET והתפקיד isSink() אם מסוף האודיו USB שדה הסוג הוא 0x0402.
[7.8.2.2/H-4-3] חובה לציין מכשיר מסוג סוג AudioDeviceInfo.TYPE_USB_HEADSET והתפקיד isSource() אם מסוף האודיו USB שדה הסוג הוא 0x0402.
[7.8.2.2/H-4-4] חייב להופיע מכשיר מסוג AudioDeviceInfo.TYPE_USB_DEVICE והתפקיד isSink() אם השדה של סוג הטרמינל של אודיו ב-USB הוא 0x603.
[7.8.2.2/H-4-5] חובה לציין מכשיר מסוג סוג AudioDeviceInfo.TYPE_USB_DEVICE והתפקיד isSource() אם מסוף האודיו USB שדה הסוג הוא 0x604.
[7.8.2.2/H-4-6] חובה לציין מכשיר מסוג סוג AudioDeviceInfo.TYPE_USB_DEVICE והתפקיד isSink() אם סוג מסוף האודיו USB. הוא 0x400.
[7.8.2.2/H-4-7] חובה לציין מכשיר מסוג סוג AudioDeviceInfo.TYPE_USB_DEVICE והתפקיד isSource() אם מסוף האודיו USB שדה הסוג הוא 0x400.
[7.8.2.2/H-SR-1] מומלץ מאוד לאחר חיבור של ציוד היקפי לאודיו מסוג USB-C, לביצוע ספירה של תיאורי USB, זיהוי סוגי מסופים ו-Intent שידור ACTION_HEADSET_PLUG תוך 1,000 אלפיות השנייה.
אם על הטמעת מכשירים ניידים מוצהר על android.hardware.audio.output
וגם
android.hardware.microphone
, הן:
[5.6/H-1-1] חייבת להיות נסיעה רציפה ממוצעת של 500 אלפיות שנייה או פחות מ-5 מדידות, עם סטייה אבסולוטית ממוצעת של פחות מ-50 אלפיות השנייה, בנתיבי הנתונים הבאים: "רמקול למיקרופון", מתאם לולאת חזרה 3.5 מ"מ (אם נתמך), לולאה חוזרת ב-USB (אם נתמך).
ל-[5.6/H-1-2] נדרש זמן אחזור ממוצע של הקשה לכוונון של 500 אלפיות השנייה לכל היותר במהלך 5 מדידות לפחות מעל הרמקול לנתיב הנתונים של המיקרופון.
אם הטמעות של מכשירים ניידים כוללות לפחות מפעיל פיזי אחד:
- [7.10/H]* לא צריכה להשתמש במסה מסתובבת אקסצנטרית (ERM) אקטואטור פיזי (רטט).
- [7.10/H]* צריך למקם את המיקום של האקטואטור ליד המיקום שבו בדרך כלל מחזיקים את המכשיר או נוגעים בו.
- [7.10/H]* צריך להטמיע את כל הקבועים הציבוריים עבור משוב פיזי ברור ב-android.view.HapticFeedbackConstants כלומר (CLOCK_TICK, CONTEXT_CLICK, KEYboard_PRESS, KEYCARD_CONFIRM, KEYboard_TAP, long_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_הרחבה, אישור, REJECT, GESTURE_START ו-GESTURE_END).
- [7.10/H]* צריך להטמיע את כל הקבועים הציבוריים עבור
משוב פיזי ברור
ב-android.os.VibrationImpact
כלומר (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK וגם
EFFECT_DOUBLE_CLICK) וכל האפשרויות הגלויות לציבור
PRIMITIVE_*
קבועים עבור משוב פיזי עשיר ב-android.os.Vibrationמיקום.Composition כלומר (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). חלק מהפרימיטיביים האלה, ייתכן שניתן להשתמש ב-LOW_TICK וב-SPIN רק אם הרטט יכול לתמוך תדרים נמוכים יחסית. [7.10/H]* צריך לפעול בהתאם להנחיות למיפוי של קבועים ציבוריים ב-android.view.HapticFeedbackConstants לקבועים המומלצים של android.os.VibrationImpact, בקשרי המשרעת התואמים.
[7.10/H]* צריך לעקוב הערכת איכות בשביל createOneShot() ו-createWaveform() ממשקי API.
[7.10/H]* צריך לאמת שהתוצאה של הפונקציה android.os.Vibrator.hasAmplitudeControl() הציבורית ה-API משקף כראוי את היכולות של הרטט.
אקטואטור תהודה ליניארי (LRA) הוא מערכת קפיץ בעלת מסה יחידה בעלת תדר תהודה דומיננטי שבו המסה מתורגמת בכיוון בתנועה הרצויה.
אם הטמעות של מכשירים ניידים כוללות לפחות תהודה לינארית אחת ב-Actuator, הם:
- [7.10/H]* צריך להזיז את האקטואטור הפיזי בציר ה-X (שמאל-ימין) בכיוון לאורך.
אם בהטמעות של מכשירים ניידים יש אקטואטור פיזי בציר ה-X אקטואטור תהודה לינארית (LRA), הוא:
- [7.10/H]* אמורה להיות תדר התהודה של ציר ה-X LRA הוא פחות מ-200Hz.
אם הטמעות של מכשירים ניידים מתבצעות בהתאם למיפוי של קבועים פיזיים, הן:
- [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)
הטמעות של מכשירים ניידים חייבות לתמוך בקידוד הווידאו הבא כדי שיהיו זמינים לאפליקציות של צד שלישי:
הטמעות של מכשירים ניידים חייבות לתמוך בפענוח הקוד הבא של סרטונים כדי שיהיו זמינים לאפליקציות של צד שלישי:
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
.
אם הטמעות של מכשירים ניידים תומכות בפעולת Assist:
- [3.8.4/H-SR-2] מומלץ מאוד
כדי להשתמש בלחיצה ארוכה על המקש
HOME
בתור האינטראקציה הייעודית להפעלת לאפליקציית העוזר הדיגיטלי, כפי שמתואר בסעיף 7.2.3. חובה להפעיל אפליקציית העזרה שהמשתמש בחר. כלומר האפליקציה שמטמיעהVoiceInteractionService
, או פעילות שמטפלת ב-IntentACTION_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
API וגם כל השדות שצוינו על ידיControl
ממשקי API.[3.8.16/H-1-5] חובה לספק משתמש אפשרות לבטל את ההסכמה לשימוש בפקדי מכשירים שמשמשים לאימות לצורך אימות את אמצעי הבקרה שנרשמו על ידי אפליקציות צד שלישי
ControlsProviderService
וגםControl
API שלControl.isAuthRequired
.
לעומת זאת, אם הטמעות של מכשירים ניידים לא מיישמים אמצעי בקרה כאלה, הם:
- [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.
2.2.4. ביצועים ועוצמה
- [8.1/H-0-1] זמן אחזור עקבי של פריימים. אסור שזמן האחזור של הפריים יהיה עקבי או עיכוב בעיבוד הפריימים הרבה מ-5 פריימים בשנייה, והם צריכים להיות נמוכים ממסגרת של פריימים בשנייה.
- [8.1/H-0-2] זמן אחזור של ממשק המשתמש. הטמעת מכשירים חייבת להבטיח חוויית משתמש עם זמן אחזור קצר על ידי גלילה רשימה של 10,000 רשומות, כפי שהוגדרו על ידי חבילת בדיקת התאימות של Android (CTS) בפחות מ-36 שניות.
- [8.1/H-0-3] החלפת משימות. מתי הושקו מספר אפליקציות והפעלה מחדש של אפליקציה שכבר פועלת של האפליקציה לאחר ההפעלה, חייבת להימשך פחות משנייה.
הטמעות של מכשירים ניידים:
- [8.2/H-0-1] חייב להבטיח רצף כתיבת ביצועים של 5MB לשנייה לפחות.
- [8.2/H-0-2] חייבת להבטיח כתיבה אקראית של לפחות 0.5MB לשנייה.
- [8.2/H-0-3] חייבים לוודא הקראה ברצף של לפחות 15MB לשנייה.
- [8.2/H-0-4] חייבת להבטיח קריאה אקראית של לפחות 3.5MB לשנייה.
אם הטמעות של מכשירים ניידים כוללות תכונות לשיפור השימוש במכשיר שכלולות ב-AOSP או מרחיבות את התכונות שכלולות ב-AOSP ב-AOSP, ריכזנו כאן:
- [8.3/H-1-1] חייבים לספק למשתמשים מספיק אפשרויות כדי להפעיל ומשביתים את תכונת החיסכון בסוללה.
- [8.3/H-1-2] חייבים לספק למשתמשים מספיק כסף להצגה את כל האפליקציות שפטורות ממצבי 'המתנה' ו'נמנום' של חיסכון בסוללה.
הטמעות של מכשירים ניידים:
- [8.4/H-0-1] חייב לספק קישור פרופיל כוח לכל רכיב שמגדיר את ערך הצריכה הנוכחית לגבי כל רכיב חומרה והתרוקנות משוערת של הסוללה שנגרמה על ידי הרכיבים לאורך זמן, כפי שמתואר באתר פרויקט הקוד הפתוח של Android.
- [8.4/H-0-2] חובה לדווח על כל אספקת החשמל במיליאמפר שעות (mAh).
- [8.4/H-0-3] חובה לדווח על עוצמת המעבד (CPU)
צריכה עבור כל מזהה ייחודי (UID) של כל תהליך. פרויקט הקוד הפתוח של Android עומד
באמצעות ההטמעה של מודול הליבה של
uid_cputime
. - [8.4/H-0-4] חייבים להשתמש בחשמל הזה
זמינה דרך
adb shell dumpsys batterystats
פקודת מעטפת למפתח האפליקציה. - צריך לשייך את [8.4/H] אל רכיב החומרה עצמו אם אין אפשרות לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.
אם הטמעות במכשירים ניידים כוללות מסך או פלט וידאו:
- [8.4/H-1-1] חייבים לכבד את
android.intent.action.POWER_USAGE_SUMMARY
Intent ומציג תפריט הגדרות שמציג את צריכת החשמל הזו.
הטמעות של מכשירים ניידים:
- [8.5/H-0-1] חייבים לספק למשתמשים במחיר נוח
תפריט ההגדרות עם האפשרות להפסיק אפליקציה שפועלת בחזית
שירות ולהציג את כל האפליקציות שיש להן שירותים פעילים בחזית
משך הזמן של כל אחד מהשירותים האלה מאז שהוא התחיל כפי שמתואר בערכת ה-SDK
מסמך.
- ייתכן שאפליקציות מסוימות יהיו פטורות מעצירה או מרישום עבור המשתמשים, כפי שמתואר במסמך ה-SDK.
2.2.5. דגם אבטחה
הטמעות של מכשירים ניידים:
- [9.1/H-0-1] חובה לאפשר לאפליקציות של צד שלישי לגשת אל
נתוני שימוש דרך ההרשאה
android.permission.PACKAGE_USAGE_STATS
לספק מנגנון נגיש למשתמש כדי להעניק או לבטל גישה לאפליקציות כאלה בתוך תגובה לandroid.settings.ACTION_USAGE_ACCESS_SETTINGS
בכוונה טובה.
הטמעות של מכשירים ניידים:
- [9.11/H-0-2] חייבים לגבות את ההטמעה של מאגר המפתחות עם סביבת הפעלה מבודדת.
- [9.11/H-0-3] חייבות להיות הטמעות של RSA, AES, אלגוריתמים קריפטוגרפיים מסוג ECDSA ו-HMAC, MD5, SHA1 ו-SHA-2 פונקציות גיבוב (hash) כדי שיתמכו בצורה תקינה בתכונות הנתמכות של מערכת Android Keystore באזור המבודד באופן מאובטח מהקוד שפועל הליבה (kernel) ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים קוד ליבה או מרחב משתמש שיכול לגשת למצב הפנימי של בסביבה מבודדת, כולל DMA. קוד פתוח של Android ב-upstream פרויקט (AOSP) עומד בדרישה הזו באמצעות ההטמעה של Trusty, אבל פתרון מבוסס ARM TrustZone או פתרון מאובטח על ידי צד שלישי או להטמיע בידוד מתאים שמבוסס על hypervisor אפשרויות.
- [9.11/H-0-4] חייבים לבצע את מסך הנעילה בסביבת ההפעלה המבודדת ורק כאשר בוצעה בהצלחה, תאפשר את השימוש במפתחות שקשורים לאימות. מסך הנעילה חייבים לאחסן את פרטי הכניסה באופן שמאפשר רק ביצוע מבודד כדי לבצע אימות של מסך הנעילה. Android בהמשך הדרך פרויקט קוד פתוח מספק Gatekeeper Hardware Layer Abstraction Layer (HAL) ו-Trusty, שיכולים לשמש כדי למלא את הדרישה הזו.
- [9.11/H-0-5] חייבת לתמוך באימות עם מפתחות כאשר מפתח חתימת אימות (attestation) מוגן באמצעות חומרה מאובטחת, והחתימה מבוצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה לאימות מספיק גדול של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשיר. אחת הדרכים לעמידה בדרישה הזו היא לשתף אותו מפתח אימות, אלא אם לפחות 100,000 יחידות של מק"ט נתון שהופק. אם מפיקים יותר מ-100,000 יחידות של מק"ט, ניתן להשתמש במפתח עבור כל 100,000 יחידות.
- [9/H-0-1] חובה להצהיר על הקובץ android.hardware.security.model.תואם .
חשוב לשים לב: אם ההטמעה של המכשיר כבר הופעלה בגרסה קודמת של Android
גרסה מסוימת, מכשיר כזה פטור מהדרישה לקיום מאגר מפתחות.
שמגובות בסביבת הפעלה מבודדת ותומכת באימות (attestation) של המפתח,
אלא אם מוצהר על התכונה android.hardware.fingerprint
שדורשת
מאגר מפתחות שמגובה על ידי סביבת הפעלה מבודדת.
כשהטמעות של מכשירים ניידים תומכות במסך נעילה מאובטח:
- [9.11/H-1-1] המשתמשים חייבים לבחור את האפשרות הכי קצרה הזמן הקצוב לתפוגה של שינה, כלומר זמן המעבר מביטול הנעילה למצב הנעילה באורך 15 שניות או פחות.
- [9.11/H-1-2] המשתמשים חייבים לאפשר למשתמשים להסתיר אותם ומשביתים את כל סוגי האימות, מלבד האימות הראשי שמתואר במאמר 9.11.1 Secure Lock Screen. ה-AOSP עומד דרישה למצב 'ללא 'ביטול נעילה עם טביעת אצבע''.
אם בהטמעות של מכשירים ניידים יש כמה משתמשים
לא מצהירים על דגל התכונה android.hardware.telephony
, הם:
- [9.5/H-2-1] חייבת לתמוך בפרופילים מוגבלים. תכונה שמאפשרת לבעלי מכשירים לנהל משתמשים נוספים ליכולות של המכשיר. עם פרופילים מוגבלים, בעלי המכשירים יכולים להגדיר במהירות סביבות נפרדות שבהן משתמשים נוספים יעבדו, יכולת לנהל הגבלות פרטניות יותר באפליקציות זמינים בסביבות האלה.
אם בהטמעות של מכשירים ניידים יש כמה משתמשים
מצהירים על דגל התכונה android.hardware.telephony
, הם:
- [9.5/H-3-1] אסור שתמיכה מוגבלת אבל חייבים להתאים להטמעת AOSP של אמצעי הבקרה כדי לאפשר /להשבית את הגישה של משתמשים אחרים לשיחות קוליות ול-SMS.
ב-Android, באמצעות System API VoiceInteractionService תומך במנגנון זיהוי של מילת הפעלה מאובטחת תמיד ללא חיווי גישה למיקרופון
אם הטמעות של מכשירים ניידים תומכים ב-System API
HotwordDetectionService
או מנגנון אחר לזיהוי מילת הפעלה ללא
הם:
- [9.8/H-1-1] חובה לוודא שהשירות לזיהוי מילות הפעלה יכול לשדר רק נתונים ל-System או ל-ContentCaptureService
- [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-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
אם מוצהר על android.hardware.microphone
על הטמעות של מכשירים ניידים, הן:
- [9.8.2/H-4-1] חובה להציג את האינדיקטור של המיקרופון כאשר
אפליקציה ניגשת לנתוני אודיו מהמיקרופון, אבל לא כאשר
רק
HotwordDetectionService
יכול לגשת למיקרופון,SOURCE_HOTWORD
אוContentCaptureService
או אפליקציות עם התפקידים שנקראו בסעיף 9.1 עם מזהה CDD [C-4-X]. - [9.8.2/H-4-2] חייבת להציג את הרשימה של 'אחרונים' ו'פעילים'
אפליקציות שמשתמשות במיקרופון כפי שהוחזר
PermissionManager.getIndicatorAppOpUsageData()
, יחד עם כל שיוך (Attribution) הודעות שמשויכות אליהם.
אם מוצהר על android.hardware.camera.any
על הטמעות של מכשירים ניידים, הן:
- [9.8.2/H-5-1] חובה להציג את האינדיקטור של המצלמה כאשר האפליקציה ניגשת לנתוני המצלמה בשידור חי, אבל לא כשהמצלמה אפליקציות שמשתמשות בתפקידים שצוינו סעיף 9.1 עם מזהה CDD [C-4-X].
- [9.8.2/H-5-2] חובה להציג אפליקציות פעילות ואפליקציות אחרונות באמצעות
מצלמה כפי שהוחזרה מ-
PermissionManager.getIndicatorAppOpUsageData()
, יחד עם הודעות השיוך (Attribution) שמשויכות אליהן.
2.2.6. תאימות לכלים למפתחים ולאפשרויות
הטמעות של מכשירים ניידים (* לא רלוונטי לטאבלט):
- [6.1/H-0-1]* חייב לתמוך בפקודת המעטפת
cmd testharness
.
הטמעות של מכשירים ניידים (* לא רלוונטי לטאבלט):
- Perfetto
- [6.1/H-0-2]* חייבים לחשוף
/system/bin/perfetto
בינארית למשתמש המעטפת ש-cmdline פועל התיעוד של Perfetto. - [6.1/H-0-3]* הקובץ הבינארי שמוגדר בקובץ חייב לקבל בתור קלט הגדרת Protobuf שתואמת לסכימה המוגדרת לתיעוד בלבד.
- [6.1/H-0-4]* הקובץ הבינארי שמוגדר בקובץ חייב להיות כתוב בתור פלט מעקב של Protobuf התואם לסכימה המוגדרת לתיעוד בלבד.
- [6.1/H-0-5]* חייבים לספק, דרך Perfetto בינארי, לפחות מקורות הנתונים שמתוארים בתיעוד Perfetto.
- [6.1/H-0-6]* הדימון (daemon) שעבר מעקב חייב להיות
מופעל כברירת מחדל (מאפיין המערכת
persist.traced.enable
).
- [6.1/H-0-2]* חייבים לחשוף
2.2.7. שיעור ביצועי מדיה להחזקה ביד
אפשר לעיין בסעיף 7.11 להגדרה של שיעור ביצועי המדיה.
2.2.7.1. מדיה
אם הטמעות במכשירים ניידים מוחזרות ערך של android.os.Build.VERSION_CODES.S
למשך android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, ואז:
- האפליקציה חייבת לעמוד בדרישות המדיה שמפורטות ב-Android 12 CDD סעיף 2.2.7.1.
אם הטמעות במכשירים ניידים מוחזרות ערך של android.os.Build.VERSION_CODES.T
למשך android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, ואז:
- [5.1/H-1-1] חובה לפרסם את המספר המקסימלי של מפענח וידאו באמצעות חומרה.
סשנים שיכולים לפעול בו-זמנית בכל שילוב קודק באמצעות
CodecCapabilities.getMaxSupportedInstances()
ו-VideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-2] חייבת לתמוך ב-6 מופעים של הפעלות של מפענח וידאו באמצעות חומרה. (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב קודק שפועל בו-זמנית ב-1080p resolution@30fps.
- [5.1/H-1-3] חובה לפרסם את המספר המקסימלי של מקודדי וידאו כחומרה
סשנים שיכולים לפעול בו-זמנית בכל שילוב קודק באמצעות
CodecCapabilities.getMaxSupportedInstances()
ו-VideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-4] חייב לתמוך ב-6 מופעים של מקודד וידאו באמצעות חומרה סשנים (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב קודק שפועל בו-זמנית ב-1080p resolution@30fps.
- [5.1/H-1-5] חובה לפרסם את המספר המרבי של מקודד וידאו כחומרה
סשנים של מפענח, שאפשר להריץ בו-זמנית בכל שילוב קודק דרך
CodecCapabilities.getMaxSupportedInstances()
ו-VideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-6] חייבת להיות תמיכה ב-6 מופעים של חומרה ומפענח וידאו של חומרה סשנים של מקודד וידאו (AVC, HEVC, VP9, AV1 ואילך) בכל קודק משולב שפועלים בו-זמנית ברזולוציה של 1080p@30fps.
- [5.1/H-1-7] זמן האחזור לאתחול קודק חייב להיות 40 אלפיות השנייה או פחות עבור סשן של קידוד וידאו ברזולוציה של 1080p או פחות לכל מקודדי הווידאו בחומרה כשיש עומס. הטעינה כאן מוגדרת כטמפרטורה בו-זמנית בין 1080p ל-720p של המרת קידוד של וידאו בלבד באמצעות קודקי וידאו של חומרה יחד עם אתחול של הקלטת אודיו-וידאו ברזולוציה של 1080p. עבור קודק הראייה של Dolby, הפונקציה זמן האחזור לאתחול קודק חייב להיות 50 אלפיות השנייה או פחות.
- [5.1/H-1-8] זמן האחזור לאתחול קודק חייב להיות 30 אלפיות השנייה או פחות עבור סשן של קידוד אודיו בקצב העברת נתונים של 128kbps או קצב נמוך יותר לכל מקודדי האודיו כאשר עוד לא טעונה. הטעינה כאן מוגדרת כסרטון ברזולוציית 1080p עד 720p בו-זמנית מבצע המרת קידוד באמצעות קודק וידאו בחומרה יחד עם רזולוציה של 1080p אתחול הקלטת אודיו-וידאו.
- [5.1/H-1-9] חייבת להיות תמיכה בשני מופעים של מפענח וידאו עם חומרה מאובטחת סשנים (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב קודק שפועל בו-זמנית ב-1080p resolution@30fps.
- [5.1/H-1-10] חייבת להיות תמיכה בשלושה מופעים של מפענח וידאו לא מאובטח בחומרה יחד עם מופע אחד של סשן של מפענח וידאו עם חומרה מאובטחת (סה"כ 4 מכונות) (AVC, HEVC, VP9, AV1 ואילך) בכל שילוב של קודק פועלות בו-זמנית ב-1080p resolution@30fps.
- [5.1/ H-1-11] חייב לתמוך במפענח מאובטח בכל חומרה של AVC, HEVC, ממפענח VP9 או AV1 במכשיר.
- [5.1/H-1-12] זמן האחזור לאתחול קודק חייב להיות 40 אלפיות השנייה או פחות עבור סשן של פענוח וידאו ברזולוציה של 1080p או פחות לכל מפענחי הווידאו בחומרה כשיש עומס. הטעינה כאן מוגדרת כטמפרטורה בו-זמנית בין 1080p ל-720p של המרת קידוד של וידאו בלבד באמצעות קודקי וידאו של חומרה יחד עם אתחול הפעלת אודיו-וידאו ברזולוציה של 1080p. ב-Dolby vision Codec, הקודק זמן האחזור של האתחול חייב להיות 50 אלפיות השנייה או פחות.
- [5.1/H-1-13] זמן האחזור לאתחול קודק חייב להיות 30 אלפיות השנייה או פחות עבור סשן של פענוח אודיו בקצב העברת נתונים של 128kbps או פחות לכל מפענחי האודיו עוד לא טעונה. הטעינה כאן מוגדרת כסרטון ברזולוציית 1080p עד 720p בו-זמנית מבצע המרת קידוד באמצעות קודק וידאו בחומרה יחד עם רזולוציה של 1080p אתחול של הפעלת אודיו-וידאו.
- [5.1/H-1-14] חייבת להיות תמיכה במפענח חומרה של AV1 ראשי 10, רמה 4.1.
- [5.1/H-SR-1] מומלץ מאוד לתמוך בפילם Grain בחומרה מסוג AV1 וממפענח.
- [5.1/H-1-15] חייב להיות לפחות מפענח חומרה אחד לפענוח וידאו שתומך ב-4K60.
- [5.1/H-1-16] חייב להיות לפחות מקודד אחד של חומרה של וידאו שתומך ב-4K60.
- [5.3/H-1-1] אסור לשחרר יותר מפריים אחד ב-10 שניות (כלומר ירידה של פחות מ-0.167 אחוז בפריים) בסשן וידאו של 1080p 60fps עוד לא טעונה. הטעינה מוגדרת כוידאו בלבד ברזולוציה של 1080p עד 720p בו-זמנית של המרת קידוד באמצעות קודק וידאו של חומרה, וגם הפעלת אודיו בפורמט AAC של 128kbps.
- [5.3/H-1-2] אסור להפיל יותר מפריים אחד ב-10 שניות במהלך סרטון שינוי ברזולוציה בסשן וידאו של 60fps. טעינה מוגדרת סשן המרת קידוד של וידאו בלבד מ-1080p ל-720p באמצעות חומרה קודק וידאו, וגם הפעלת אודיו AAC של 128kbps.
- [5.6/H-1-1] זמן האחזור של הקשה לטון חייב להיות של 80 אלפיות השנייה או פחות באמצעות בדיקת 'מצמידים ומשלמים' של OboeTester או בדיקת 'מצמידים ומשלמים' של CTS Verifier.
- [5.6/H-1-2] זמן האחזור של האודיו הלוך ושוב הוא 80 אלפיות השנייה או פחות לפחות בנתיב נתונים נתמך אחד.
- [ 5.6/H-1-3] חייבת תמיכה באודיו >=24 ביט לפלט סטריאו של 3.5 מ"מ או יותר
מתאים לשקעים אם הוא קיים ובאודיו ב-USB אם הוא נתמך דרך
את כל נתיב הנתונים להגדרות של זמן אחזור קצר וסטרימינג. לרמה הנמוכה
הגדרה של זמן אחזור, האפליקציה צריכה להשתמש באודיו בזמן אחזור קצר
מצב קריאה חוזרת. לסטרימינג
הגדרה אישית, יש להשתמש ב-Java AudioTrack על ידי האפליקציה. בדרגה נמוכה
הגדרות זמן אחזור וסטרימינג, ה-sink של פלט HAL אמור לקבל
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
אוAUDIO_FORMAT_PCM_FLOAT
לפלט היעד שלו הפורמט. - [5.6/H-1-4] חייבת להיות תמיכה ביותר מ-4 ערוצים בהתקני אודיו USB (בשימוש של די-ג'יי). בקרים להאזנה מקדימה של שירים).
- [5.6/H-1-5] חייבת להיות תמיכה במכשירי MIDI שתואמים למחלקות, ולהצהיר על השימוש ב-MIDI דגל של פיצ'ר.
- [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 |
2.2.7.2. מצלמה
אם הטמעות במכשירים ניידים מוחזרות ערך של android.os.Build.VERSION_CODES.S
למשך android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, ואז:
- המצלמה חייבת לעמוד בדרישות שמפורטות ב-Android 12 CDD סעיף 2.2.7.2.
אם הטמעות במכשירים ניידים מוחזרות ערך של android.os.Build.VERSION_CODES.T
למשך android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, ואז:
- [7.5/H-1-1] חייבת להיות מצלמה אחורית ראשית עם רזולוציה של לפחות 12 מגה-פיקסלים שתומכים בצילום וידאו בקצב של 4k@30fps. המשחק הראשי המצלמה האחורית היא המצלמה האחורית עם מזהה המצלמה הנמוך ביותר.
- [7.5/H-1-2] חייבת להיות מצלמה קדמית ראשית ברזולוציה של לפחות 5 מגה-פיקסלים עם תמיכה בצילום וידאו בקצב של 1080p@30fps. המשחק הראשי המצלמה הקדמית היא המצלמה הקדמית עם מזהה המצלמה הנמוך ביותר.
- [7.5/H-1-3] חייבת לתמוך בנכס
android.info.supportedHardwareLevel
בתורFULL
ומעלה לחזרה הראשית ו-LIMITED
ומעלה לשיטה הראשית הקדמית מצלמה. - [7.5/H-1-4] תמיכה חייבת
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
לשתי הראשיות מצלמות. - [7.5/H-1-5] חייב להיות זמן אחזור של צילום JPEG עם מצלמה2 < 1,000 אלפיות השנייה עבור רזולוציה של 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
במכשיר הראשי מצלמה אחורית, אם יש יותר מ-1 מצלמות RGB אחוריות. - [7.5/H-1-14] חייבת להיות תמיכה ביכולת
STREAM_USE_CASE
בשני המכשירים הראשיים המצלמה הקדמית והמצלמה הראשית.
2.2.7.3. חומרה
אם בהטמעות במכשירים ניידים מוחזר הערך android.os.Build.VERSION_CODES.S
למשך
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, ואז:
- האפליקציה חייבת לעמוד בדרישות החומרה שמפורטות ב-Android 12 CDD סעיף 2.2.7.3.
אם בהטמעות במכשירים ניידים מוחזר הערך android.os.Build.VERSION_CODES.T
למשך
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, ואז:
- [7.1.1.1/H-2-1] רזולוציית המסך חייבת להיות לפחות 1080p.
- [7.1.1.3/H-2-1] דחיסות מסך של לפחות 400 dpi.
- [7.6.1/H-2-1] צריך להיות לכם זיכרון פיזי בנפח של 8GB לפחות.
2.2.7.4. ביצועים
אם בהטמעות במכשירים ניידים מוחזר הערך android.os.Build.VERSION_CODES.S
למשך
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, ואז:
- האפליקציה חייבת לעמוד בדרישות הביצועים שמפורטות ב-Android 12 CDD סעיף 2.2.7.4.
אם בהטמעות במכשירים ניידים מוחזר הערך android.os.Build.VERSION_CODES.T
למשך
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, ואז:
- [8.2/H-1-1] חייבים להבטיח ביצועי כתיבה רציפים של 125MB לשנייה לפחות.
- [8.2/H-1-2] חייבים להבטיח ביצועי כתיבה אקראיים של לפחות 10MB לשנייה.
- [8.2/H-1-3] חייבת להבטיח ביצועי קריאה רציפים של לפחות 250MB לשנייה.
- [8.2/H-1-4] חייבת להבטיח ביצועי קריאה אקראיים של לפחות 40MB לשנייה.
2.3. דרישות לטלוויזיה
מכשיר Android TV מתייחס להטמעה של מכשיר Android, הוא ממשק בידור שמשמש לצריכה של מדיה דיגיטלית, סרטים, משחקים, אפליקציות ו/או טלוויזיה בשידור חי למשתמשים שיושבים במרחק של כ-6 מ"מ (למשל, "להישען אחורה" או "3 מטר" בממשק המשתמש).
הטמעות של מכשירי Android מסווגים כטלוויזיה אם הם עומדים בכל הקריטריונים הבאים:
- החברה סיפקה מנגנון לשליטה מרחוק בממשק המשתמש שעבר עיבוד שנמצא במרחק של כ-3 מטרים מהמשתמש.
- מסך מוטמע עם אורך אלכסון גדול מ-24 אינץ' או כולל יציאת פלט וידאו, כגון VGA , HDMI , DisplayPort או יציאה אלחוטית למסך.
הדרישות הנוספות המפורטות בהמשך הקטע הזה הן ספציפיות ל-Android הטמעות של מכשירי טלוויזיה.
2.3.1. חומרה
הטמעות של מכשירי טלוויזיה:
- [7.2.2/T-0-1] חובה לתמוך בלחצני החיצים (D-pad).
- [7.2.3/T-0-1] חייבים לספק את 'דף הבית' ואת 'הקודם' למשימות ספציפיות.
- [7.2.3/T-0-2] חייבים לשלוח גם בלחיצה רגילה וגם בלחיצה ארוכה
אירוע של פונקציית 'הקודם' (
KEYCODE_BACK
) לאפליקציה בחזית. - [7.2.6.1/T-0-1] חייבת לכלול תמיכה במשחק
בקרים והצהרה על דגל הפיצ'ר
android.hardware.gamepad
. - [7.2.7/T] אמור לספק שלט רחוק שממנו שמשתמשים יכולים לגשת לניווט ללא מגע קלט של מקשי ליבה לניווט.
אם בהטמעות של מכשירי טלוויזיה נעשה שימוש בג'ירוסקופ ב-3 צירים:
- [7.3.4/T-1-1] צריכה להיות אפשרות לדווח על אירועים עד של לפחות 100Hz.
- [7.3.4/T-1-2] חייבת להיות יכולת למדוד שינויי כיוון עד 1,000 מעלות לשנייה.
הטמעות של מכשירי טלוויזיה:
- [7.4.3/T-0-1] חייב לתמוך ב-Bluetooth וב Bluetooth LE.
- [7.6.1/T-0-1] חייבים להיות לפחות 4GB של אחסון בלתי תנודתי שזמין לנתונים פרטיים של האפליקציה (שנקראת גם מחיצת "/data" ).
אם הטמעות של מכשיר טלוויזיה כוללות יציאת USB שתומכת במצב מארח, הם:
- [7.5.3/T-1-1] חייבת לכלול תמיכה במצלמה חיצונית שמתחבר באמצעות יציאת ה-USB הזו אבל לא בהכרח מחובר תמיד.
אם ההטמעה של מכשירי טלוויזיה היא 32 ביט:
[7.6.1/T-1-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות בגודל של 896MB לפחות, אם נעשה שימוש באחת מהדחיסות הבאות:
- 400dpi או יותר במסכים קטנים/רגילים
- xhdpi ומעלה במסכים גדולים
- tvdpi ומעלה במסכים גדולים במיוחד
אם ההטמעות של מכשיר טלוויזיה הן בגרסת 64 ביט:
[7.6.1/T-2-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות בגודל של 1280MB לפחות, אם אחת מהדחיסות הבאה היא בשימוש:
- 400dpi או יותר במסכים קטנים/רגילים
- xhdpi ומעלה במסכים גדולים
- tvdpi ומעלה במסכים גדולים במיוחד
שימו לב ש"הזיכרון שזמין לליבה ולמרחב המשתמשים" שלמעלה מתייחס בנוסף לכל הזיכרון הקיים שמיועד לרכיבי חומרה כמו רדיו, וידאו וכן הלאה, בשליטת הליבה על יישומי המכשיר.
הטמעות של מכשירי טלוויזיה:
- [7.8.1/T] צריכה לכלול מיקרופון.
- [7.8.2/T-0-1] חייב להיות פלט אודיו וצריך להצהיר עליו
android.hardware.audio.output
.
2.3.2. מולטימדיה
הטמעות של מכשירי טלוויזיה חייבות לתמוך בקידוד האודיו הבא ומקודדים בפורמטים שונים כדי שיהיו זמינים לאפליקציות של צד שלישי:
- [5.1/T-0-1] MPEG-4 AAC Profile (AAC LC)
- [5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
- [5.1/T-0-3] AAC ELD (משופר עם השהיה נמוכה AAC)
הטמעות של מכשירי טלוויזיה חייבות לתמוך בקידוד הווידאו הבא כדי שיהיו זמינים לאפליקציות של צד שלישי:
הטמעות של מכשירי טלוויזיה:
- [5.2.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
הטמעות של מכשירי טלוויזיה חייבים לתמוך בפענוח MPEG-2, כפי שמפורט ב סעיף 5.3.1, בקצבי פריימים סטנדרטיים וברזולוציות של עד ו- כולל:
- [5.3.1/T-1-1] איכות HD 1080p בקצב של 29.97FPS עם פרופיל ראשי ברמה גבוהה.
- [5.3.1/T-1-2] HD 1080i בקצב של 59.94 פריימים לשנייה עם פרופיל ראשי ברמה גבוהה. הם חייבים לבטל שילוב של וידאו MPEG-2 משולב ולהפוך אותו לזמין לאפליקציות של צד שלישי.
הטמעות של מכשירי טלוויזיה חייבות לתמוך בפענוח H.264, כפי שמפורט ב סעיף 5.3.4, בקצבי פריימים סטנדרטיים וברזולוציות של עד ו- כולל:
- [5.3.4/T-1-1] HD 1080p בקצב של 60 פריימים לשנייה עם פרופיל הבסיס
- [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 של צד שלישי.
הטמעות של מכשירי טלוויזיה:
- [3.12/T-0-1] חייב לתמוך במסגרת של קלט טלוויזיה.
2.3.4. ביצועים ועוצמה
- [8.1/T-0-1] זמן אחזור עקבי של פריימים. אסור שזמן האחזור של הפריים יהיה עקבי או עיכוב בעיבוד הפריימים הרבה מ-5 פריימים בשנייה, והם צריכים להיות נמוכים ממסגרת של פריימים בשנייה.
- [8.2/T-0-1] חייב להבטיח רצף מהירות כתיבת הנתונים של 5MB/s לפחות.
- [8.2/T-0-2] חובה להקפיד על כתיבה אקראית של לפחות 0.5MB לשנייה.
- [8.2/T-0-3] חייב להבטיח רצף קריאה של נתוני ביצועים של 15MB לשנייה לפחות.
- [8.2/T-0-4] חייבת להבטיח קריאה אקראית של 3.5MB לשנייה לפחות.
אם ההטמעות של מכשירי טלוויזיה כוללות תכונות שמשפרות את עוצמת המכשיר שכלולות ב-AOSP או מרחיבות את התכונות שכלולות ב-AOSP ב-AOSP, ריכזנו כאן:
- [8.3/T-1-1] חייבים לספק למשתמשים מספיק אפשרויות כדי לאפשר את ההפעלה ומשביתים את תכונת החיסכון בסוללה.
אם בהטמעות של מכשירי טלוויזיה אין סוללה:
- [8.3/T-1-2] חובה לרשום את המכשיר בתור מכשיר ללא סוללה, כפי שמתואר במאמר תמיכה במכשירים ללא סוללה.
אם הטמעות של מכשירי טלוויזיה כוללים סוללה:
- [8.3/T-1-3] חייבים לספק למשתמשים מספיק כסף להצגה את כל האפליקציות שפטורות ממצבי 'המתנה' ו'נמנום' של חיסכון בסוללה.
הטמעות של מכשירי טלוויזיה:
- [8.4/T-0-1] חובה לספק פרופיל כוח לכל רכיב שמגדיר את ערך הצריכה הנוכחית לגבי כל רכיב חומרה והתרוקנות משוערת של הסוללה שנגרמה על ידי הרכיבים לאורך זמן, כפי שמתואר באתר פרויקט הקוד הפתוח של Android.
- [8.4/T-0-2] חובה לדווח על כל אספקת החשמל במיליאמפר שעות (mAh).
- [8.4/T-0-3] חובה לדווח על עוצמת המעבד (CPU)
צריכה עבור כל מזהה ייחודי (UID) של כל תהליך. פרויקט הקוד הפתוח של Android עומד
באמצעות ההטמעה של מודול הליבה של
uid_cputime
. - צריך לשייך את [8.4/T] אל רכיב החומרה עצמו אם אין אפשרות לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.
- [8.4/T-0-4] חייבים להשתמש בחשמל הזה
זמינה דרך
adb shell dumpsys batterystats
פקודת מעטפת למפתח האפליקציה.
2.3.5. דגם אבטחה
הטמעות של מכשירי טלוויזיה:
- [9.11/T-0-1] חובה לגבות את ההטמעה של מאגר המפתחות עם סביבת הפעלה מבודדת.
- [9.11/T-0-2] חייבות להיות הטמעות של RSA, AES, אלגוריתמים קריפטוגרפיים מסוג ECDSA ו-HMAC, MD5, SHA1 ו-SHA-2 פונקציות גיבוב (hash) כדי שיתמכו בצורה תקינה בתכונות הנתמכות של מערכת Android Keystore באזור המבודד באופן מאובטח מהקוד שפועל הליבה (kernel) ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים קוד ליבה או מרחב משתמש שיכול לגשת למצב הפנימי של בסביבה מבודדת, כולל DMA. קוד פתוח של Android ב-upstream פרויקט (AOSP) עומד בדרישה הזו באמצעות ההטמעה של Trusty, אבל פתרון מבוסס ARM TrustZone או פתרון מאובטח על ידי צד שלישי או להטמיע בידוד מתאים שמבוסס על hypervisor אפשרויות.
- [9.11/T-0-3] חייבים לבצע את מסך הנעילה בסביבת ההפעלה המבודדת ורק כאשר בוצעה בהצלחה, תאפשר את השימוש במפתחות שקשורים לאימות. מסך הנעילה חייבים לאחסן את פרטי הכניסה באופן שמאפשר רק ביצוע מבודד כדי לבצע אימות של מסך הנעילה. Android בהמשך הדרך פרויקט קוד פתוח מספק Gatekeeper Hardware Layer Abstraction Layer (HAL) ו-Trusty, שיכולים לשמש כדי למלא את הדרישה הזו.
- [9.11/T-0-4] חייבת לתמוך באימות עם מפתחות כאשר מפתח חתימת אימות (attestation) מוגן באמצעות חומרה מאובטחת, והחתימה מבוצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה לאימות מספיק גדול של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשיר. אחת הדרכים לעמידה בדרישה הזו היא לשתף אותו מפתח אימות, אלא אם לפחות 100,000 יחידות של מק"ט נתון שהופק. אם מפיקים יותר מ-100,000 יחידות של מק"ט, ניתן להשתמש במפתח עבור כל 100,000 יחידות.
- [9/T-0-1] חובה להצהיר על הקובץ android.hardware.security.model.תואם .
חשוב לשים לב: אם ההטמעה של המכשיר כבר הופעלה בגרסה קודמת של Android
גרסה מסוימת, מכשיר כזה פטור מהדרישה לקיום מאגר מפתחות.
שמגובות בסביבת הפעלה מבודדת ותומכת באימות (attestation) של המפתח,
אלא אם מוצהר על התכונה android.hardware.fingerprint
שדורשת
מאגר מפתחות שמגובה על ידי סביבת הפעלה מבודדת.
אם בהטמעות של מכשירי טלוויזיה יש תמיכה במסך נעילה מאובטח:
- [9.11/T-1-1] המשתמשים חייבים לבחור באפשרות 'שינה' זמן קצוב למעבר ממצב לא נעול למצב נעול, עם הזמן המינימלי הקצוב לתפוגה שמוגדר ל-15 שניות או פחות.
אם בהטמעות של מכשירי טלוויזיה יש כמה משתמשים
לא מצהירים על דגל התכונה android.hardware.telephony
, הם:
- [9.5/T-2-1] חייבת לתמוך בפרופילים מוגבלים. תכונה שמאפשרת לבעלי מכשירים לנהל משתמשים נוספים ליכולות של המכשיר. עם פרופילים מוגבלים, בעלי המכשירים יכולים להגדיר במהירות סביבות נפרדות שבהן משתמשים נוספים יעבדו, יכולת לנהל הגבלות פרטניות יותר באפליקציות זמינים בסביבות האלה.
אם בהטמעות של מכשירי טלוויזיה יש כמה משתמשים
מצהירים על דגל התכונה android.hardware.telephony
, הם:
- [9.5/T-3-1] אסור שתמיכה מוגבלת אבל חייבים להתאים להטמעת AOSP של אמצעי הבקרה כדי לאפשר /להשבית את הגישה של משתמשים אחרים לשיחות קוליות ול-SMS.
אם בהטמעות של מכשירי טלוויזיה מוצהר על android.hardware.microphone
, הן:
- [9.8.2/T-4-1] חובה להציג את האינדיקטור של המיקרופון כאשר אפליקציה ניגשת לנתוני אודיו מהמיקרופון, אבל לא כאשר ניתן לגשת למיקרופון רק באמצעות HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService או אפליקציות עם התפקידים שצוינו בסעיף 9.1 הרשאות עם מזהה CDD C-3-X].
- [9.8.2/T-4-2] אסור להסתיר את האינדיקטור של המיקרופון עבור אפליקציות מערכת עם ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמשים.
אם בהטמעות של מכשירי טלוויזיה מוצהר על android.hardware.camera.any
, הן:
- [9.8.2/T-5-1] חובה להציג את האינדיקטור של המצלמה כאשר האפליקציה ניגשת לנתוני המצלמה בשידור חי, אבל לא כשהמצלמה אפליקציות שמשתמשות בתפקידים שצוינו בסעיף 9.1 ניגשות אליהם. הרשאות עם מזהה CDD [C-3-X].
- [9.8.2/T-5-2] אסור להסתיר את האינדיקטור של המצלמה עבור אפליקציות מערכת עם ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמשים.
2.3.6. תאימות לכלים למפתחים ולאפשרויות
הטמעות של מכשירי טלוויזיה:
- Perfetto
- [6.1/T-0-1] חייבים לחשוף
/system/bin/perfetto
בינארית למשתמש המעטפת ש-cmdline פועל התיעוד של Perfetto. - [6.1/T-0-2] הקובץ הבינארי שמוגדר בקובץ חייב לקבל בתור קלט הגדרת Protobuf שתואמת לסכימה המוגדרת לתיעוד בלבד.
- [6.1/T-0-3] הקובץ הבינארי שמוגדר בקובץ חייב להיות כתוב בתור פלט מעקב של Protobuf התואם לסכימה המוגדרת לתיעוד בלבד.
- [6.1/T-0-4] חובה לספק, באמצעות Perfetto בינארי, לפחות מקורות הנתונים שמתוארים במסמכי התיעוד של Perfetto.
- [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 צירים מד תאוצה.
אם ההטמעות של מכשיר השעון כוללות מקלט GPS/GNSS ומדווחים על
יכולת לאפליקציות באמצעות התכונה android.hardware.location.gps
הם:
- [7.3.3/W-1-1] חובה לדווח על מדידות GNSS ברגע שהן נמצאים, גם אם המיקום שמחושב מ-GPS/GNSS עדיין לא דווח.
- [7.3.3/W-1-2] חובה לדווח על GNSS על מערכים של פסאודוטווח (pseudoranges) ו-pseudoranges בתנאים של שמיים פתוחים לאחר קביעת המיקום, קבוע או נע עם פחות מ-0.2 מטר לשנייה בריבוע תאוצה מספיקה כדי לחשב את המיקום בטווח של 20 מטרים, בטווח של 0.2 מטר לשנייה, לפחות ב-95% מהזמן.
אם ההטמעות של מכשיר השעון כוללות ג'ירוסקופ ב-3 צירים:
- [7.3.4/W-2-1] חייבת להיות יכולת למדוד שינויים בכיוון עד 1,000 מעלות לשנייה.
הטמעות של מכשירי השעון:
[7.4.3/W-0-1] חייב לתמוך ב-Bluetooth.
[7.6.1/W-0-1] חייב להיות לפחות 1GB של אחסון בלתי נדיף שזמין לנתונים פרטיים של האפליקציה (שנקראת גם מחיצת 'נתונים/נתונים').
[7.6.1/W-0-2] חייב להיות זיכרון בנפח של 416MB לפחות זמינים לליבה ולמרחב המשתמשים.
[7.8.1/W-0-1] חייב לכלול מיקרופון.
[7.8.2/W] יכול להיות פלט אודיו.
2.4.2. מולטימדיה
ללא דרישות נוספות.
2.4.3. תוכנות
הטמעות של מכשירי השעון:
- [3/W-0-1] חובה להצהיר על התכונה
android.hardware.type.watch
. - [3/W-0-2] חייבת לתמוך ב-uiMode = UI_mode_TYPE_Watch.
- [3.2.3.1/W-0-1] חובה לטעון מראש אחד או יותר אפליקציות או רכיבי שירות עם handler של Intent, כל הדפוסים של סינון Intent ציבורי שהוגדרו על ידי האפליקציה הבאה ה-Intents שמפורטים כאן.
הטמעות של מכשירי השעון:
- [3.8.4/W-SR-1] מומלץ מאוד כדי להטמיע עוזר דיגיטלי במכשיר שיטפל בפעולת ה-Assist.
אפליקציות בשעון שבהן מוצהר על android.hardware.audio.output
דגל פיצ'ר:
- [3.10/W-1-1] חייב לתמוך בנגישות של צד שלישי שירותים שונים.
- [3.10/W-SR-1] מומלץ מאוד לטעון מראש שירותי נגישות במכשיר שניתנים להשוואה עם פונקציונליות או גבוהה ממנה של 'גישה באמצעות מתג' ו-TalkBack (לשפות שנתמכות על ידי הרכיבים שהותקנו מראש שירותי נגישות של המרת טקסט לדיבור (TTS) כפי שמסופקים לפרויקט קוד פתוח של TalkBack.
אם יישומים של מכשיר צפייה מדווחים על התכונה android.hardware.audio.output, הם:
[3.11/W-SR-1] מומלץ מאוד לכלול מנוע TTS שתומך בשפות הזמינות במכשיר.
[3.11/W-0-1] חייבת לתמוך בהתקנה של מנועי TTS של צד שלישי.
2.4.4. ביצועים ועוצמה
אם ההטמעות של מכשיר השעון כוללות תכונות לשיפור השימוש במכשיר שכלולות ב-AOSP או מרחיבות את התכונות שכלולות ב-AOSP ב-AOSP, ריכזנו כאן:
- [8.3/W-SR-1] מומלץ מאוד לספק לאפשר למשתמשים להציג את כל האפליקציות שפטורות מבהמתנה של אפליקציה, נמנום מצבי חיסכון בסוללה.
- [8.3/W-SR-2] מומלץ מאוד לספק מבחינת המשתמש: להפעיל ולהשבית את תכונת החיסכון בסוללה.
הטמעות של מכשירי השעון:
- [8.4/W-0-1] חייב לספק פרופיל כוח לכל רכיב שמגדיר את ערך הצריכה הנוכחית לגבי כל רכיב חומרה והתרוקנות משוערת של הסוללה שנגרמה על ידי הרכיבים לאורך זמן, כפי שמתואר באתר פרויקט הקוד הפתוח של Android.
- [8.4/W-0-2] חובה לדווח על כל אספקת החשמל במיליאמפר שעות (mAh).
- [8.4/W-0-3] חובה לדווח על עוצמת המעבד (CPU)
צריכה עבור כל מזהה ייחודי (UID) של כל תהליך. פרויקט הקוד הפתוח של Android עומד
באמצעות ההטמעה של מודול הליבה של
uid_cputime
. - [8.4/W-0-4] חייבים להשתמש בחשמל הזה
זמינה דרך
adb shell dumpsys batterystats
פקודת מעטפת למפתח האפליקציה. - צריך לשייך את [8.4/W] אל רכיב החומרה עצמו אם אין אפשרות לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.
2.4.5. דגם אבטחה
הטמעות של מכשירי השעון:
- [9/W-0-1] חובה להצהיר על
android.hardware.security.model.compatible
.
אם ההטמעות של מכשיר השעון כוללות משתמשים מרובים וגם
לא מצהירים על דגל התכונה android.hardware.telephony
, הם:
- [9.5/W-1-1] חייבת לתמוך בפרופילים מוגבלים. תכונה שמאפשרת לבעלי מכשירים לנהל משתמשים נוספים ליכולות של המכשיר. עם פרופילים מוגבלים, בעלי המכשירים יכולים להגדיר במהירות סביבות נפרדות שבהן משתמשים נוספים יעבדו, יכולת לנהל הגבלות פרטניות יותר באפליקציות זמינים בסביבות האלה.
אם ההטמעות של מכשיר השעון כוללות משתמשים מרובים וגם
מצהירים על דגל התכונה android.hardware.telephony
, הם:
- [9.5/W-2-1] אסור שתמיכה מוגבלת אבל חייבים להתאים להטמעת AOSP של אמצעי הבקרה כדי לאפשר /להשבית את הגישה של משתמשים אחרים לשיחות קוליות ול-SMS.
2.5. דרישות לגבי רכב
המונח הטמעה של Android Automotive מתייחס ליחידה הראשית של הרכב שפועלת Android כמערכת הפעלה לחלק מהמערכת או מכולן ו/או פונקציות של מידע ובידור.
הטמעות של מכשירי Android מסווגים ככלי רכב אם מוצהר על כך
את התכונה android.hardware.type.automotive
או לענות על כל הקריטריונים הבאים
קריטריונים.
- שמוטמעים כחלק מכלי רכב או שניתן לחבר אותם.
- משתמשים במסך שבשורת המושב של הנהג בתור המסך הראשי.
הדרישות הנוספות המפורטות בהמשך הקטע הזה הן ספציפיות ל-Android הטמעת מכשירים בכלי רכב.
2.5.1. חומרה
הטמעות של מכשירים בכלי רכב:
- [7.1.1.1/A-0-1] חייב להיות מסך 6 לפחות אינץ' בגודל אלכסון פיזי.
[7.1.1.1/A-0-2] חייבת להיות פריסה של גודל מסך לפחות 750 dp x 480 dp
[7.2.3/A-0-1] חובה לספק את הפונקציה 'דף הבית' ואת חודש מאי לספק פונקציות 'הקודם' ו'אחרונים'.
[7.2.3/A-0-2] חייבים לשלוח גם בלחיצה רגילה וגם בלחיצה ארוכה אירוע של פונקציית 'הקודם' (
KEYCODE_BACK
) לאפליקציה בחזית.[7.3/A-0-1] חובה להטמיע את התוכן ולדווח עליו
GEAR_SELECTION
,NIGHT_MODE
,PERF_VEHICLE_SPEED
וגםPARKING_BRAKE_ON
.[7.3/A-0-2] הערך של
NIGHT_MODE
הדגל חייב להיות תואם למצב היום/הלילה של מרכז הבקרה והוא צריך להתבסס על קלט מחיישן אור הסביבה. יכול להיות שחיישן אור הסביבה הבסיסי יהיה זהה בתור PhotoMeter.[7.3/A-0-3] חובה לספק שדה מידע נוסף לחיישן
TYPE_SENSOR_PLACEMENT
כחלק מ-SensorAdditionalInfo לכל חיישן שמסופק.[7.3/A-SR1] תמונת השער מיקום באמצעות שילוב של GPS/GNSS עם חיישנים נוספים. אם בוחרים במיקום לדעתך, מומלץ מאוד ליישם ולדווח החיישן התואם סוגים שונים ו/או מזהי נכסי רכב בשימוש.
[7.3/A-0-4] המיקום נשלחה בקשה דרך LocationManager#requestLocationUpdates() אסור שתהיה התאמה למפה.
[7.3.1/A-0-4] חייב לעמוד בדרישות של Android מערכת הקואורדינטות של חיישן הרכב.
[7.3/A-SR-1] מומלץ מאוד להוסיף תמונה עם 3 צירים מד תאוצה וג'ירוסקופ עם 3 צירים.
[7.3/A-SR-2] מומלץ מאוד ליישם את ההמלצה ולדווח עליה חיישן
TYPE_HEADING
.
אם בהטמעות של מכשירי כלי רכב יש תמיכה ב-OpenGL ES 3.1:
- [7.1.4.1/A-0-1] חובה להצהיר OpenGL ES 3.1 ואילך.
- [7.1.4.1/A-0-2] חייבת לתמוך ב-Vulkan 1.1.
- [7.1.4.1/A-0-3] חובה לכלול טעינה של Vulkan וייצא את כל הסמלים.
אם ההטמעות של מכשירים ב-Automotive כוללות מד תאוצה:
- [7.3.1/A-1-1] צריכה להיות אפשרות לדווח על אירועים עד לתדירות מסוימת של לפחות 100Hz.
אם יישומי המכשירים כוללים מד תאוצה ב-3 צירים, הם:
- [7.3.1/A-SR-1] מומלץ מאוד להטמיע את חיישן מורכב למד תאוצה עם צירים מוגבלים.
אם בהטמעות של מכשירים בכלי רכב יש מד תאוצה שנמוך מ- הם:
- [7.3.1/A-1-3] חובה להטמיע את התוכן ולדווח עליו
חיישן
TYPE_ACCELEROMETER_LIMITED_AXES
. - [7.3.1/A-1-4] חובה להטמיע את התוכן ולדווח עליו
חיישן
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
אם ההטמעות של מכשירים בכלי רכב כוללות ג'ירוסקופ, הן:
- [7.3.4/A-2-1] צריכה להיות אפשרות לדווח על אירועים עד לתדירות מסוימת של לפחות 100Hz.
- [7.3.4/A-2-3] חייבת להיות יכולת למדוד שינויי כיוון עד 250 מעלות לשנייה.
- [7.3.4/A-SR-1] מומלץ מאוד להגדיר את טווח המדידה של הג'ירוסקופ עד 250dps + כדי למקסם את הרזולוציה ככל האפשר.
אם ההטמעות של מכשירים בכלי רכב כוללות ג'ירוסקופ ב-3 צירים:
- [7.3.4/A-SR-2] מומלץ מאוד להטמיע את חיישן מרוכב לג'ירוסקופ עם צירים מוגבלים.
אם ההטמעות של מכשירים בכלי רכב כוללות ג'ירוסקופ עם פחות מ-3 צירים:
- [7.3.4/A-4-1] חובה להטמיע את התוכן ולדווח עליו
חיישן
TYPE_GYROSCOPE_LIMITED_AXES
. - [7.3.4/A-4-2] חובה להטמיע את התוכן ולדווח עליו
חיישן
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
אם ההטמעות של מכשיר כלי הרכב כוללות מקלט GPS/GNSS, אבל לא כוללות קישוריות נתונים המבוססת על רשת סלולרית, הן:
- [7.3.3/A-3-1] יש לקבוע את המיקום בפעם הראשונה מקלט ה-GPS/GNSS מופעל או לאחר יותר מ-4 ימים בתוך 60 שניות.
- [7.3.3/A-3-2] חייב לעמוד בקריטריונים של 'זמן עד לתיקון הראשון' כפי כמתואר בסעיפים 7.3.3/C-1-2 ו-7.3.3/C-1-6 לגבי כל שאר בקשות המיקום (כלומר בקשות שזו לא הפעם הראשונה) או אחרי 4 ימים ומעלה). הדרישה 7.3.3/C-1-2 היא בדרך כלל נפגשים בכלי רכב ללא קישוריות נתונים לרשת סלולרית, באמצעות חיזוי מסלול GNSS שחושב על המקלט, או באמצעות את המיקום הידוע האחרון של הרכב, יחד עם היכולת להביא בחשבון למשך 60 שניות לפחות, עם דיוק מיקום שמספק 7.3.3/C-1-3, או שילוב של שניהם.
אם ההטמעות של כלי הרכב כוללות חיישן TYPE_HEADING
, הן:
- [7.3.4/A-4-3] חייבת להיות אפשרות לדווח על אירועים עד לתדירות מסוימת של לפחות 1Hz.
- [7.3.4/A-SR-3] STRONGLY_recommended לדיווח על אירועים עד של לפחות 10Hz.
- הוא צריך להיות מתייחס לצפון אמיתי.
- השירותים אמורים להיות זמינים גם כשהרכב יציב.
- צריכה להיות רזולוציה של מעלה אחת לפחות.
הטמעות של מכשירים בכלי רכב:
- [7.4.3/A-0-1] חייב לתמוך ב-Bluetooth ואמור תמיכה ב-Bluetooth LE.
- [7.4.3/A-0-2] הטמעות של Android Automotive
הנתונים חייבים לתמוך בפרופילים הבאים של Bluetooth:
- שיחות טלפון באמצעות פרופיל Hands-Free (HFP).
- הפעלת מדיה בפרופיל הפצת אודיו (A2DP).
- הפקד להפעלת מדיה בפרופיל שלט רחוק (AVRCP).
- שיתוף אנשי קשר באמצעות פרופיל הגישה לספר הטלפונים (PBAP).
[7.4.3/A-SR-1] מומלץ מאוד לתמיכה פרופיל גישה להודעה (MAP).
[7.4.5/A] צריכה לכלול תמיכה ברשת סלולרית באמצעות קישוריות נתונים מבוססת-רשת.
[7.4.5/A] יכול להיות שתשתמשו ב-System API קבוע
NetworkCapabilities#NET_CAPABILITY_OEM_PAID
עבור הרשתות שאמורות להיות זמינות לאפליקציות המערכת.
מצלמה חיצונית היא מצלמה שמצלמת סצנות מחוץ למכשיר כמו המצלמה האחורית.
הטמעות של מכשירים בכלי רכב:
- צריכה לכלול מצלמה אחת או יותר לצפייה מבחוץ.
אם ההטמעות של מכשירים בכלי רכב כוללות מצלמת תצוגה חיצונית, מצלמה, הם:
- [7.5/A-1-1] אסור שתהיה גישה למצלמות חוץ מבחוץ דרך ממשקי ה-API של מצלמת Android, אלא אם הם עומדים בדרישות עם דרישות הליבה של המצלמה.
[7.5/A-SR-1] מומלץ מאוד לא לבצע רוטציה או לשקף לרוחב את התצוגה המקדימה של המצלמה.
[7.5/A-SR-2] מומלץ מאוד למצוא פתרון בגודל 1.3 מגה-פיקסל לפחות.
היא צריכה לכלול מיקוד קבוע או חומרת EDOF (עומק שדה מורחב).
ייתכן שבעתיד יוטמעו מיקוד אוטומטי בחומרה או מיקוד אוטומטי בתוכנה מנהל ההתקן של המצלמה.
אם ההטמעה של מכשירים בכלי רכב כוללת מצלמה חיצונית אחת או יותר, וטוענים את שירות המערכת החיצונית (EVS), ובמצלמה הזאת הם:
- [7.5/A-2-1] אסור לסובב או לשקף את הצורה תצוגה מקדימה של המצלמה.
הטמעות של מכשירים בכלי רכב:
- עשויים לכלול מצלמה אחת או יותר שזמינות לצד שלישי תרגום מכונה.
אם ההטמעות של כלי רכב כוללות לפחות מצלמה אחת ולהפוך אותה לאפליקציות צד שלישי, הן:
- [7.5/A-3-1] חובה לדווח על התכונה הניסיונית
android.hardware.camera.any
. - [7.5/A-3-2] אסור להצהיר על המצלמה כ- מצלמת המערכת.
- יכול להיות שתהיה תמיכה במצלמות חיצוניות שמתוארות בסעיף 7.5.3.
- ייתכן שיכללו תכונות (כמו מיקוד אוטומטי וכו') שזמינות למצלמה האחורית. מצלמות כפי שמתואר בקטע 7.5.1.
הטמעות של מכשירים בכלי רכב:
[7.6.1/A-0-1] חייבים להיות לפחות 4GB של אחסון בלתי תנודתי שזמין לנתונים פרטיים של האפליקציה (שנקראת גם מחיצת "/data" ).
[7.6.1/A] צריך לקבוע את הפורמט של מחיצת הנתונים כדי להציע ביצועים משופרים ואורך חיים ארוך יותר באחסון Flash, באמצעות מערכת הקבצים
f2fs
.
אם הטמעות של מכשירי Automotive מספקות אחסון חיצוני משותף באמצעות באחסון הפנימי שלא ניתן להסרה, הן:
- [7.6.1/A-SR-1] מומלץ מאוד לצמצם
תקורת קלט/פלט (I/O) על פעולות המבוצעות באחסון החיצוני, לדוגמה על ידי
באמצעות
SDCardFS
.
אם ההטמעה של מכשירי כלי רכב היא בגרסת 64 ביט:
[7.6.1/A-2-1] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות בגודל של 816MB לפחות, אם נעשה שימוש באחת מהדחיסות הבאות:
- 280dpi או פחות במסכים קטנים/רגילים
- ldpi או פחות במכשירים גדולים במיוחד
- mdpi או פחות במכשירים עם מסכים גדולים
[7.6.1/A-2-2] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות בגודל של 944MB לפחות אם אחת מהדחיסות הבאה מתבצעת:
- xhdpi ומעלה במסכים קטנים/רגילים
- hdpi ומעלה במסכים גדולים
- mdpi ומעלה במסכים גדולים במיוחד
[7.6.1/A-2-3] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות בגודל של 1280MB לפחות אם אחת מהדחיסות הבאה מתבצעת:
- 400dpi או יותר במסכים קטנים/רגילים
- xhdpi ומעלה במסכים גדולים
- tvdpi ומעלה במסכים גדולים במיוחד
[7.6.1/A-2-4] הזיכרון שזמין לליבה (kernel) ומרחב המשתמשים חייב להיות בגודל 1,824MB לפחות, אם נעשה שימוש באחת מהדחיסות הבאות:
- 560dpi ומעלה במסכים קטנים/רגילים
- 400dpi או יותר במסכים גדולים
- xhdpi ומעלה במסכים גדולים במיוחד
שימו לב ש"הזיכרון שזמין לליבה ולמרחב המשתמשים" שלמעלה מתייחס מקום זיכרון בנוסף לכל זיכרון שכבר מיועד לחומרה כמו רדיו, וידאו וכו', שלא נמצאים במסגרת הליבה שליטה בהטמעות של מכשירים.
הטמעות של מכשירים בכלי רכב:
- [7.7.1/A] צריכה לכלול יציאת USB שתומכת במצב היקפי.
הטמעות של מכשירים בכלי רכב:
- [7.8.1/A-0-1] חייב לכלול מיקרופון.
הטמעות של מכשירים בכלי רכב:
- [7.8.2/A-0-1] חובה לכלול פלט אודיו וצריך להצהיר עליו
android.hardware.audio.output
.
2.5.2. מולטימדיה
בהטמעות של מכשירים בכלי רכב צריכה להיות תמיכה בקידוד האודיו הבא ומקודדים בפורמטים שונים כדי שיהיו זמינים לאפליקציות של צד שלישי:
- [5.1/A-0-1] MPEG-4 AAC Profile (AAC LC)
- [5.1/A-0-2] MPEG-4 HE AAC Profile (AAC+)
- [5.1/A-0-3] AAC ELD (משופר עם השהיה נמוכה AAC)
בהטמעות של מכשירים בכלי רכב צריכה להיות תמיכה בקידוד הווידאו הבא כדי שיהיו זמינים לאפליקציות של צד שלישי:
הטמעות של מכשירים בכלי רכב חייבות לתמוך בפענוח הקוד הבא של סרטונים כדי שיהיו זמינים לאפליקציות של צד שלישי:
מומלץ מאוד להטמיע מכשירים בכלי רכב כדי לתמוך פענוח הסרטון הבא:
- [5.3/A-SR-1] H.265 HEVC
2.5.3. תוכנות
הטמעות של מכשירים בכלי רכב:
[3/A-0-1] חובה להצהיר על התכונה
android.hardware.type.automotive
.[3/A-0-2] חייבת להיות תמיכה ב-uiMode =
UI_MODE_TYPE_CAR
.[3/A-0-3] חייבת לתמוך בכל ממשקי ה-API הציבוריים
android.car.*
מרחב שמות.
אם ההטמעות של מכשירי כלי רכב מספקות API קנייני באמצעות
android.car.CarPropertyManager
עם
android.car.VehiclePropertyIds
,
הם:
- [3/A-1-1] אסור לשייך הרשאות מיוחדות למערכת לשימוש של האפליקציה במאפיינים האלה, או למנוע מאפליקציות של צד שלישי משימוש במאפיינים האלה.
- [3/A-1-2] אסור לשכפל נכס רכב שכבר קיימת ב-SDK.
הטמעות של מכשירים בכלי רכב:
[3.2.1/A-0-1] חובה לתמוך בכולם ולאכוף את כולם קבועים של הרשאות, כפי שמתואר בדף העזר בנושא הרשאת רכב.
[3.2.3.1/A-0-1] חובה לטעון מראש אחד או יותר אפליקציות או רכיבי שירות עם handler של Intent, לכל הדפוסים של סינון Intent ציבורי שמוגדרים לפי ה-Intentים הבאים של אפליקציות המפורטים כאן.
[3.4.1/A-0-1] חובה לספק מידע מלא של ה-API של
android.webkit.Webview
.[3.8.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.camera.any
, אז
הם:
- [9.8.2/A-2-1] חובה להציג את האינדיקטור של המצלמה כאשר האפליקציה ניגשת לנתוני המצלמה בשידור חי, אבל לא כשהמצלמה אפליקציות שמשתמשות בתפקידים שצוינו הרשאות סעיף 9.1 עם מזהה CDD [C-3-X].
- [9.8.2/A-2-2] אסור להסתיר את האינדיקטור של המצלמה עבור אפליקציות מערכת עם ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמשים.
הטמעות של מכשירים בכלי רכב:
- [9.11/A-0-1] חובה לגבות את ההטמעה של מאגר המפתחות עם סביבת הפעלה מבודדת.
- [9.11/A-0-2] חייבות להיות הטמעות של RSA, AES, אלגוריתמים קריפטוגרפיים מסוג ECDSA ו-HMAC, MD5, SHA1 ו-SHA-2 פונקציות גיבוב (hash) כדי שיתמכו בצורה תקינה בתכונות הנתמכות של מערכת Android Keystore באזור המבודד באופן מאובטח מהקוד שפועל הליבה (kernel) ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים קוד ליבה או מרחב משתמש שיכול לגשת למצב הפנימי של בסביבה מבודדת, כולל DMA. קוד פתוח של Android ב-upstream פרויקט (AOSP) עומד בדרישה הזו באמצעות ההטמעה של Trusty, אבל פתרון מבוסס ARM TrustZone או פתרון מאובטח על ידי צד שלישי או להטמיע בידוד מתאים שמבוסס על hypervisor אפשרויות.
- [9.11/A-0-3] חייבים להפעיל את מסך הנעילה בסביבת ההפעלה המבודדת ורק כאשר בוצעה בהצלחה, תאפשר את השימוש במפתחות שקשורים לאימות. מסך הנעילה חייבים לאחסן את פרטי הכניסה באופן שמאפשר רק ביצוע מבודד כדי לבצע אימות של מסך הנעילה. Android בהמשך הדרך פרויקט קוד פתוח מספק Gatekeeper Hardware Layer Abstraction Layer (HAL) ו-Trusty, שיכולים לשמש כדי למלא את הדרישה הזו.
- [9.11/A-0-4] חייבת לתמוך באימות עם מפתחות כאשר מפתח חתימת אימות (attestation) מוגן באמצעות חומרה מאובטחת, והחתימה מבוצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה לאימות מספיק גדול של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשיר. אחת הדרכים לעמידה בדרישה הזו היא לשתף אותו מפתח אימות, אלא אם לפחות 100,000 יחידות של מק"ט נתון שהופק. אם מפיקים יותר מ-100,000 יחידות של מק"ט, ניתן להשתמש במפתח עבור כל 100,000 יחידות.
- [9/A-0-1] חובה להצהיר על הקובץ android.hardware.security.model.תואם .
הערה: אם ההטמעה של המכשיר כבר הופעלה בגרסה קודמת של Android
גרסה מסוימת, מכשיר כזה פטור מהדרישה לקיום מאגר מפתחות.
שמגובות בסביבת הפעלה מבודדת ותומכת באימות (attestation) של המפתח,
אלא אם מוצהר על התכונה android.hardware.fingerprint
שדורשת
מאגר מפתחות שמגובה על ידי סביבת הפעלה מבודדת.
הטמעות של מכשירים בכלי רכב:
- [9.14/A-0-1] הודעות שמירת סף ממערכות משנה של רכבים במסגרת Android, למשל, הודעה שמותרת להוסיף לרשימת ההיתרים הסוגים והמקורות של ההודעות.
- [9.14/A-0-2] הטיימר המפקח (watchdog) חייב לעמוד התקפות של מניעת שירות (DoS) מ-Android Framework או מאפליקציות של צד שלישי. הזה מגנה מפני תוכנות זדוניות שמציפה את רשת הרכבים בתנועה, מה שעלול לגרום לתקלה במערכות המשנה של הרכב.
2.5.6. תאימות לכלים למפתחים ולאפשרויות
הטמעות של מכשירים בכלי רכב:
- Perfetto
- [6.1/A-0-1] חייבים לחשוף
/system/bin/perfetto
בינארית למשתמש המעטפת ש-cmdline פועל התיעוד של Perfetto. - [6.1/A-0-2] הקובץ הבינארי הקבוע חייב לקבל בתור קלט הגדרת Protobuf שתואמת לסכימה המוגדרת לתיעוד בלבד.
- [6.1/A-0-3] הקובץ הבינארי שמוגדר בקובץ חייב להיות כתוב בתור פלט מעקב של Protobuf שתואם לסכימה שמוגדרת לתיעוד בלבד.
- [6.1/A-0-4] חובה לספק באמצעות Perfetto בינארי, לפחות מקורות הנתונים שמתוארים בתיעוד Perfetto.
- [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)
פירוט צפיפות המסך שרשום למסכים קטנים/רגילים במכשירים ניידים הדרישות לא רלוונטיות לטאבלטים.
מצב ציוד היקפי בחיבור 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 לכל אחת מהרשימות המוגבלות.
3.1.1. תוספים ל-Android
מערכת Android תומכת בהרחבה של סביבת ה-API המנוהלת ברמת API מסוימת על ידי
מעדכנים את גרסת התוסף לרמת ה-API הזו.
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
API מחזיר את
גרסת התוסף של apiLevel
שסופק, אם יש תוספים בשבילו
רמת ה-API.
הטמעות של מכשירי Android:
[C-0-1] חובה לטעון מראש את הטמעת ה-AOSP של הספרייה המשותפת
ExtShared
ושירותיםExtServices
עם גרסאות שגדולות מ- או שוות ל- מספר הגרסאות המינימלי המותר לכל רמת API. לדוגמה, Android 7.0 הטמעות במכשירים, הרצה של רמת API 24 חייבת לכלול לפחות גרסה 1.[C-0-2] חובה להחזיר רק מספר גרסה תקף של תוסף מוגדר על ידי ה-AOSP.
[C-0-3] חייבת להיות תמיכה בכל ממשקי ה-API שהוגדרו בגרסאות התוספים הוחזר על ידי
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
ממש כמו התמיכה בממשקי API מנוהלים אחרים, מפורטות בסעיף 3.1.
3.1.2. ספריית Android
בגלל ההוצאה משימוש של לקוח HTTP ב-Apache, יישומי מכשירים:
- [C-0-1] אסור להציב את ספריית
org.apache.http.legacy
'סיווג אתחול'. - [C-0-2] חובה להוסיף את הספרייה
org.apache.http.legacy
לאפליקציה classpath רק אם האפליקציה עומדת באחד מהתנאים הבאים:- מוגדר טירגוט לרמת API 28 ומטה.
- מצהיר במניפסט שהוא זקוק לספרייה על ידי הגדרה של
מאפיין
android:name
של<uses-library>
עדorg.apache.http.legacy
.
הטמעת ה-AOSP עומדת בדרישות הבאות.
3.2. תאימות ל-Soft API
בנוסף לממשקי ה-API המנוהלים המפורטים בסעיף 3.1, ב-Android יש גם ממשק API 'soft' (רך) עם הרבה זמן ריצה בלבד, דברים כמו כוונות, הרשאות והיבטים דומים של אפליקציות ל-Android לא ניתנת לאכיפה בזמן הידור של האפליקציה.
3.2.1. הרשאות
- [C-0-1] מטמיעי מכשירים חייבים לתמוך ולאכוף את כל ההרשאות קבועים, כפי שמתואר בדף העזר להרשאות. לתשומת ליבכם, בסעיף 9 מפורטות רשימות נוספות של בדרישות שקשורות למודל האבטחה של Android.
3.2.2. בניית פרמטרים
ממשקי ה-API של Android כוללים כמה משתנים קבועים android.os.Build class שנועדו לתאר את המכשיר הנוכחי.
- [C-0-1] לספק ערכים עקביים ומשמעותיים בכל המכשירים בהטמעות, הטבלה הבאה כוללת הגבלות נוספות על הפורמטים של הערכים האלה שההטמעות במכשירים חייבים לעמוד בהם.
פרמטר | פרטים |
---|---|
גרסה.גרסה | הגרסה של מערכת Android שפועלת כרגע, בפורמט קריא לאנשים הפורמט. אחד מערכי המחרוזת של השדה הזה חייב להיות מוגדר ב מחרוזות הגרסאות המותרות ל-Android 13. |
VERSION.SDK | הגרסה של מערכת Android שפועלת כרגע, בפורמט לקוד של אפליקציה של צד שלישי. ב-Android 13, בשדה הזה חייב להיות ערך המספר השלם 13_INT. |
VERSION.SDK_INT | הגרסה של מערכת Android שפועלת כרגע, בפורמט לקוד של אפליקציה של צד שלישי. ב-Android 13, בשדה הזה חייב להיות ערך המספר השלם 13_INT. |
גרסה.INCREMENTAL | ערך שנבחר על ידי מכשיר ההטמעה שמגדיר את ה-build הספציפי של מערכת Android שפועלת כרגע, בפורמט קריא לאנשים. הזה אסור לעשות שימוש חוזר בערך הזה לגרסאות build שונות שזמינות למשתמשי הקצה. א' השימוש הטיפוסי בשדה הזה הוא לציין את מספר ה-Build בתהליך יצירת ה-build נעשה שימוש במזהה שינוי של בקרת מקור. הערך חייב להיות ניתן לקידוד כ-ASCII בפורמט 7 סיביות שניתן להדפסה ולהתאים לקידוד ביטוי רגולרי ' ^[^ :\/~]+$ ". |
משחקי לוח | ערך שנבחר על ידי מכשיר ההטמעה שמזהה את חומרה פנימית שבה נעשה שימוש במכשיר, בפורמט קריא לאנשים. אפשרית בשדה הזה צריך לציין את הגרסה הספציפית של במכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות תואמים לביטוי הרגולרי "^[a-zA-Z0-9_-]+$". |
מותג | ערך שמשקף את שם המותג המשויך למכשיר, כפי שהוא נקרא משתמשי הקצה. חייב להיות בפורמט קריא לאנשים, והוא צריך לייצג את יצרן המכשיר או מותג החברה שמתחתיו שמשווקות. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים אותו הביטוי הרגולרי "^[a-zA-Z0-9_-]+$". |
SUPPORTED_ABIS | השם של קבוצת ההוראות (סוג מעבד (CPU) + מוסכמות ABI) של נייטיב ראו סעיף 3.3. ממשק API מקורי תאימות. |
SUPPORTED_32_BIT_ABIS | השם של קבוצת ההוראות (סוג מעבד (CPU) + מוסכמות ABI) של נייטיב ראו סעיף 3.3. ממשק API מקורי תאימות. |
SUPPORTED_64_BIT_ABIS | השם של קבוצת ההוראה השנייה (סוג מעבד (CPU) + מוסכמות ABI) של את הקוד המקורי. ראו סעיף 3.3. מודעות מותאמות תאימות ל-API. |
מעבד [CPU_ABI] | השם של קבוצת ההוראות (סוג מעבד (CPU) + מוסכמות ABI) של נייטיב ראו סעיף 3.3. ממשק API מקורי תאימות. |
מעבד [CPU_ABI2] | השם של קבוצת ההוראה השנייה (סוג מעבד (CPU) + מוסכמות ABI) של את הקוד המקורי. ראו סעיף 3.3. מודעות מותאמות תאימות ל-API. |
מכשיר | ערך שנבחר על ידי מטמיע המכשיר שמכיל את שם הפיתוח או שם קוד המזהה את התצורה של תכונות החומרה לעיצוב התעשייתי של המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בגרסת 7 סיביות ותואמים לביטוי הרגולרי “^[a-zA-Z0-9_-]+$”. אסור לשנות את שם המכשיר הזה במהלך כל משך החיים של המוצר. |
טביעת אצבע | מחרוזת שמשמשת לזיהוי ייחודי של ה-build הזה. היא צריכה להיות סבירה
קריא לאנשים. היא חייבת להיות בתבנית הבאה:
$(BRAND)/$(PRODUCT)/ לדוגמה: acme/myproduct/ אסור שטביעת האצבע תכלול רווחים לבנים. הערך של חייב להיות מקודד בשדה הזה כ-ASCII של 7 ביט. |
חומרה | שם החומרה (משורת הפקודה של הליבה או /proc). הוא הנכסים צריכים להיות קריאים באופן סביר לאנשים. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בגרסת 7 סיביות ולהתאים את הביטוי הרגולרי “^[a-zA-Z0-9_-]+$”. |
מארח | מחרוזת שמשמשת לזיהוי ייחודי של המארח שעליו נבנה ה-build, ב- בפורמט קריא לאנשים. אין דרישות לגבי הפורמט הספציפי של שדה זה, מלבד שהוא לא יכול להיות null או מחרוזת ריקה (""). |
מזהה | מזהה שנבחר על ידי מטמיע המכשיר כדי להתייחס למאפיין ספציפי בפורמט קריא לאנשים. השדה הזה יכול להיות זהה לערך android.os.Build.VERSION.INCREMENTAL, אבל אמור להיות ערך מספיק שעוזר למשתמשי קצה להבחין בין גרסאות build של תוכנות. הערך חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות ולהתאים ביטוי “^[a-zA-Z0-9._-]+$”. |
יצרנים | השם המסחרי של יצרן הציוד המקורי (OEM) המוצר. אין דרישות לגבי הפורמט הספציפי של השדה הזה, למעט שהוא לא יכול להיות null או מחרוזת ריקה (""). השדה הזה אסור לשנות את המדיניות במהלך כל משך החיים של המוצר. |
SOC_MANUFACTURER | השם המסחרי של היצרן של המערכת הראשית ב- שבב (SOC) שנעשה בו שימוש במוצר. מכשירים עם אותו יצרן SOC צריך להשתמש באותו ערך קבוע. יש לבקש מיצרן ה-SOC את הקבוע הנכון שבו צריך להשתמש. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בגרסת 7 סיביות, חייב להתאים לביטוי הרגולרי '^([0-9A-Za-z ]+)' , אסור להתחיל או לסיים ברווח לבן, ואסור שהוא יהיה שווה ל-'לא ידוע'. אסור לשנות את השדה הזה במהלך כל משך החיים של המוצר. |
SOC_MODEL | שם הדגם של המערכת הראשית על שבב (SOC) שבו נעשה שימוש את המוצר. מכשירים עם אותו מודל SOC צריכים להשתמש באותו ערך קבוע עם ערך מסוים. צריך לבקש מיצרן ה-SOC לקבל את הקבוע הנכון לשימוש. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות ולהתאים בביטוי הרגולרי "^([0-9A-Za-z ._/+-]+)$", אסור להתחיל או מסתיים ברווח לבן, ואסור שהוא יהיה שווה ל-'unknown'. השדה הזה אסור לשנות את המדיניות במהלך כל משך החיים של המוצר. |
דגם | ערך שנבחר על ידי יישום ההטמעה של המכשיר, שמכיל את השם של כפי שמוכר למשתמש הקצה. הוא אמור להיות אותו השם שבו המכשיר משווק ונמכר למשתמשי הקצה. אין דרישות לגבי של השדה הזה, מלבד העובדה שהוא לא יכול להיות null או מחרוזת ריקה (""). אסור לשנות את השדה הזה במהלך כל משך החיים של המוצר. |
מוצר | ערך שנבחר על ידי מטמיע המכשיר שמכיל את שם הפיתוח או שם הקוד של המוצר הספציפי (מק"ט) חייב להיות ייחודי אותו מותג. התוכן חייב להיות קריא לאנשים, אבל הוא לא מיועד בהכרח לתצוגה על ידי משתמשי קצה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות תואמים לביטוי הרגולרי "^[a-zA-Z0-9_-]+$". המוצר הזה אסור לשנות את שם המוצר במהלך כל משך החיים של המוצר. |
ODM_SKU | ערך אופציונלי שנבחר על ידי מטמיע המכשיר שמכיל
מק"ט (Stock Keeping Unit) שמשמש למעקב אחרי תצורות ספציפיות
של המכשיר, לדוגמה, כל ציוד היקפי שכלול במכשיר כשהוא נמכר.
הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות ולהתאים
הביטוי הרגולרי ^([0-9A-Za-z.,_-]+)$ . |
סידורי | חייבת להיות 'UNKNOWN'. |
תגים | רשימה מופרדת בפסיקים של התגים שנבחרו על ידי הכלי להטמעת מכשירים שעושה הבחנה נוספת בין ה-build. ניתן לקידוד את התגים כ-ASCII של 7 ביט ומתאימים את הביטוי הרגולרי "^[a-zA-Z0-9._-]+" וחייבים הם כוללים אחד מהערכים שתואמים לשלושת הפלטפורמות הטיפוסיות של Android בתצורת חתימה: מפתחות הפצה, מפתחות פיתוח ומפתחות בדיקה. |
שעה | ערך שמייצג את חותמת הזמן של מועד ה-build. |
סוג | ערך שנבחר על ידי ההטמעה של המכשיר, שמציין את זמן הריצה של ה-build. שדה זה חייב להכיל אחד מהערכים שתואם לשלוש הגדרות אופייניות של זמן ריצה ב-Android: משתמש, userdebug או eng. |
משתמש | שם או מזהה משתמש של המשתמש (או המשתמש האוטומטי) שיצר את build. אין דרישות לגבי הפורמט הספציפי של השדה הזה, למעט שהוא לא יכול להיות null או מחרוזת ריקה (""). |
security_PATCH | ערך שמציין את רמת תיקון האבטחה של ה-build. חובה לציין שה-build לא חשוף בשום צורה לבעיות שתוארו באמצעות 'מבזקי אבטחה ציבוריים' הייעודיים של Android. ההזמנה חייבת להיות בתוך בפורמט [YYYY-MM-DD], שתואם למחרוזת מוגדרת שמתועדת עדכון אבטחה ציבורית של Android או ב התראת אבטחה של Android, לדוגמה "2015-11-01". |
BASE_OS | ערך שמייצג את הפרמטר FINGERprint של ה-build אחרת תהיה זהה ל-build הזה, למעט התיקונים שסופקו מבזקי אבטחה ציבוריים של Android. חייבים לדווח על הערך הנכון, ואם build כזה לא קיים. צריך לדווח על מחרוזת ריקה (""). |
BOOTLOADER | ערך שנבחר על ידי מכשיר ההטמעה שמזהה את גרסת תוכנת האתחול הפנימית שמותקנת במכשיר, בפורמט קריא לאנשים. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 סיביות ולהתאים ביטוי רגולרי '^[a-zA-Z0-9._-]+$'. |
getRadioVersion() | חייב (להיות או להחזיר) ערך שנבחר על ידי מטמיע המכשיר זיהוי גרסת הרדיו/המודם הפנימית הספציפית שבה נעשה שימוש במכשיר, בפורמט קריא לאנשים. אם למכשיר אין רדיו/modem חייב להחזיר NULL. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בגרסת 7 סיביות ולהתאים את הביטוי הרגולרי “^[a-zA-Z0-9._-,]+$”. |
getENTER() | חייב (להיות או להחזיר) מספר סידורי של חומרה, חייב להיות זמין וייחודיים בכל המכשירים עם אותו MODEL ו-MANUFACTURER. הערך של חייב להיות ניתן לקידוד שדה זה כ-ASCII של 7 סיביות ולהתאים לביטוי הרגולרי “^[a-zA-Z0-9]+$”. |
3.2.3. תאימות של Intent
3.2.3.1. אובייקטים נפוצים של Intent באפליקציות
הפורמט 'Intents של Android' מאפשר לרכיבי האפליקציה לבקש פונקציונליות מ רכיבי Android אחרים. פרויקט ה-upstream ב-Android כולל רשימה של שמטמיעים כמה דפוסי כוונה כדי לבצע פעולות נפוצות.
הטמעות מכשירים:
- [C-SR-1] מומלץ מאוד לטעון מראש אפליקציה אחת או יותר, או רכיבי שירות עם handler של Intent, לכל מסנן Intent הציבורי. הדפוסים המוגדרים לפי ה-Intents הבאים של אפליקציות המפורטים כאן ולספק את צורכי הלקוחות, כלומר, לעמוד בציפיות של המפתח לגבי כוונות אפליקציה כפי שמתואר ב-SDK.
בסעיף 2 לקבלת כוונות נדרשות להגשת בקשה לכל סוג מכשיר.
3.2.3.2. יישוב כוונות
[C-0-1] Android היא פלטפורמה שניתנת להרחבה, ולכן חייבים להטמיע במכשירים לאפשר כל דפוס Intent שיש הפניה אליו בקטע 3.2.3.1 , פרט להגדרות, שניתנות לשינוי על ידי אפליקציות של צד שלישי. הטמעת קוד פתוח של Android ב-upstream מאפשרת זאת כברירת מחדל.
[C-0-2] אסור שמטמיעי מכשירים יוכלו לשייך הרשאות מיוחדות למערכת אפליקציות שימוש בדפוסי הכוונה האלה, או למנוע שימוש באפליקציות של צד שלישי לחייב את הדפוסים האלה ולקבל שליטה עליהם. האיסור הזה כוללת באופן ספציפי, בין היתר, את השבתת המשתמש ה"בורר" שמאפשר למשתמש לבחור בין מספר אפליקציות יטפל באותו דפוס Intent.
[C-0-3] הטמעות במכשירים חייבות לספק ממשק משתמש למשתמשים לשנות את פעילות ברירת המחדל של Intent.
עם זאת, ייתכן שהטמעות מכשירים מספקות פעילויות ברירת מחדל עבור תבניות URI (למשל http://play.google.com) כאשר פעילות ברירת המחדל מספקת ל-URI של הנתונים. לדוגמה, דפוס של מסנן Intent שמציינים את ה-URI של הנתונים 'http://www.android.com' ספציפי יותר תבנית ה-Intent העיקרית של הדפדפן ל-'http:// '.
ב-Android יש גם מנגנון שבו אפליקציות צד שלישי יכולות להכריז על התנהגות ברירת המחדל של מדיניות הקישור של אפליקציות לסוגים מסוימים של כוונות URI באינטרנט. כשיש הצהרות מוסמכות כאלה מוגדר בדפוסים של מסנני Intent באפליקציה, הטמעות מכשירים:
- [C-0-4] חובה לנסות לאמת מסנני Intent על ידי ביצוע של שלבי האימות שמוגדרים במפרט של קישורים לנכסים דיגיטליים כפי שהוטמע על ידי מנהל החבילות ב-upstream בקוד פתוח של Android פרויקט.
- [C-0-5] חובה לנסות לאמת את מסנני Intent במהלך ההתקנה של את האפליקציה ולהגדיר את כל מסנני Intent של URI שאומתו בהצלחה בתור ברירת המחדל של הגורמים המטפלים באפליקציות עבור מזהי ה-URI שלהם.
- ב-MAY ניתן להגדיר מסנני Intent ספציפיים של URI כרכיבי handler שמוגדרים כברירת מחדל לאפליקציות עבור מזהי ה-URI שלהם, אם הם אומתו בהצלחה, אך מסנני URI של מועמדים אחרים נכשלים אימות. אם מכשיר כלשהו מבצע את הפעולה הזו, הוא חייב לספק את משתמש לשנות את תבנית ה-URI המתאימה בתפריט ההגדרות.
- חובה לספק למשתמש אמצעי בקרה של קישורים לאפליקציה לכל אפליקציה בהגדרות בתור
ככה:
- [C-0-6] המשתמש חייב להיות מסוגל לשנות את כל אפליקציית ברירת המחדל. ההתנהגות של קישורים לאפליקציה: תמיד פתוחה, שואלת תמיד או אף פעם לא נפתחת. שחייב לחול על כל מסנני ה-Intent של ה-URI של המועמדים באופן שווה.
- [C-0-7] המשתמש חייב לראות רשימה של כוונות ה-URI האפשריות מסננים.
- הטמעת המכשיר עשויה לספק למשתמש את היכולת לשנות מסנני Intent ספציפיים של URI אפשריים שעברו בהצלחה לפי סינון לפי כוונת המשתמש.
- [C-0-8] הטמעת המכשיר חייבת לספק למשתמשים את היכולת הצגה וביטול של מסנני Intent ספציפיים של URI אפשריים, אם המכשיר מאפשר לחלק ממסנני ה-Intent של ה-URI של המועמדים להצליח בעוד שאחרים עלולים להיכשל.
3.2.3.3. מרחבי שמות של Intent
- [C-0-1] אסור לכלול במכשירים רכיבי Android שמטמיעים פועל לפי כל דפוס חדש של כוונות או כוונות שידור באמצעות ACTION, CATEGORY או מחרוזת מפתח אחרת במרחב השמות android.* או com.android.* .
- [C-0-2] אסור לכלול בהטמעות של מכשירים רכיבי Android לפעול בהתאם לכל דפוס חדש של כוונת רכישה או של כוונות שידור באמצעות הפעולות ACTION, CATEGORY או מחרוזת מפתח אחרת במרחב חבילה ששייך לארגון אחר.
- [C-0-3] אסור למטמיעי מכשירים לשנות או להרחיב אף אחת מכוונות הרכישה הדפוסים המפורטים בסעיף 3.2.3.1.
- ייתכן שהטמעות מכשירים כוללות דפוסי כוונה שמשתמשים במרחבי שמות באופן ברור ומשויכים בבירור לארגון שלהם. האיסור הזה מקבילה לזו שצוינה במחלקות שפת Java בקטע 3.6.
3.2.3.4. כוונה לשידור
אפליקציות צד שלישי מסתמכות על הפלטפורמה כדי לשדר כוונות מסוימות להודיע להם על שינויים בסביבת החומרה או התוכנה.
הטמעות מכשירים:
- [C-0-1] חובה לשדר את מטרות השידור הציבורי שמפורטות כאן בתגובה לאירועי המערכת המתאימים, כפי שמתואר במסמכי התיעוד של ה-SDK. לתשומת ליבך, דרישה זו אינה מתנגשת עם סעיף 3.5, הגבלה על אפליקציות ברקע מתוארת גם ב-SDK התיעוד. כמו כן, כוונות שידור מסוימות מותנות בחומרה תמיכה, אם המכשיר תומך בחומרה הנדרשת, הם חייבים לשדר את את הכוונות שלו ומספקים את ההתנהגות בהתאם למסמכי התיעוד של ה-SDK.
3.2.3.5. אובייקטים מסוג Intent של אפליקציות מותנות
ב-Android יש הגדרות שמאפשרות למשתמשים לבחור בקלות אפליקציות ברירת מחדל, לדוגמה, מסך הבית או SMS.
כשהדבר הגיוני, הטמעות מכשירים חייבות לספק הגדרות דומות יהיו תואמים לדפוס של מסנן Intent ולשיטות ה-API שמתוארות. במסמכי התיעוד בנושא SDK, כפי שמפורט בהמשך.
אם הטמעות המכשירים ידווחו על android.software.home_screen
, הן:
- [C-1-1] חייב לכבד את
android.settings.HOME_SETTINGS
Intent להציג תפריט ברירת מחדל של הגדרות אפליקציה במסך הבית.
אם הטמעות של מכשירים מדווחים על android.hardware.telephony.calling, הן:
[C-2-1] חובה לספק תפריט הגדרות שיקרא
android.provider.Telephony.ACTION_CHANGE_DEFAULT
כוונה להציג תיבת דו-שיח לשינוי אפליקציית ברירת המחדל ל-SMS.[C-2-2] חייבים לכבד את
android.telecom.action.CHANGE_DEFAULT_DIALER
Intent להציג תיבת דו-שיח כדי לאפשר למשתמש לשנות את ברירת המחדל של טלפון תרגום מכונה.- חייבים להשתמש בממשק המשתמש של אפליקציית 'טלפון' המוגדרת כברירת המחדל על ידי המשתמשים שיחות יוצאות, למעט שיחות חירום, שעבורן ייעשה שימוש אפליקציית 'טלפון' שהותקנה מראש.
[C-2-3] חובה לפעול בהתאם ל-android.telecom.action.CHANGE_PHONE_ACCOUNTS כוונה לספק למשתמשים אפשרות להגדיר את
ConnectionServices
המשויך ל-PhoneAccounts
, מכיוון וגם PhoneAccount ברירת מחדל שספק שירותי הטלקומוניקציה יקבל משמשים לביצוע שיחות יוצאות. הטמעת ה-AOSP עומדת בדרישה הזו עד כולל 'אפשרות לשיחות-חשבונות' בתפריט "שיחות" תפריט ההגדרות[C-2-4] חובה לאפשר
android.telecom.CallRedirectionService
לאפליקציה שמכילה אתandroid.app.role.CALL_REDIRECTION
תפקיד.[C-2-5] חובה לספק למשתמש אפשרות לבחור אפליקציה שמכילה את
android.app.role.CALL_REDIRECTION
תפקיד.[C-2-6] חובה לפעול בהתאם ל-android.intent.action.SENDTO ו-android.intent.action.VIEW כוונות ולספק פעילות לשליחה/הצגה של הודעות SMS.
[C-SR-1] מומלץ מאוד לכבד את android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_button, android.intent.action.VIEW & 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] חובה להציג קישורים כאלה בכל שירותי המילוי האוטומטי שהותקנו.
[C-17-1] [עבר לגרסה 2.2.3]
אם הטמעות המכשיר תומכות ב-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
.
3.2.4. פעילויות במסכים משניים או מרובים
אם הטמעות המכשירים מאפשרות להפעיל פעילויות רגילות ב-Android ביותר מסך אחד, הם:
- [C-1-1] חייבים להגדיר את
android.software.activities_on_secondary_displays
דגל של פיצ'ר. - [C-1-2] חובה להבטיח תאימות ל-API שדומה לפעילות שפועלת על במסך הראשי.
- [C-1-3] הפעילות החדשה חייבת להופיע בתצוגה של הפעילות
להפעיל אותו, כשהפעילות החדשה מופעלת בלי לציין יעד
תצוגה דרך
ActivityOptions.setLaunchDisplayId()
API. - [C-1-4] חייבים להרוס את כל הפעילויות, כשצג עם
Display.FLAG_PRIVATE
הסימון הוסר. - [C-1-5] חובה להסתיר תוכן באופן מאובטח בכל המסכים כשהמכשיר נעול
עם מסך נעילה מאובטח, אלא אם האפליקציה בוחרת להציג מעל מנעול
מסך באמצעות
Activity#setShowWhenLocked()
API. - צריך לכלול את הפרמטר
android.content.res.Configuration
שתואם לתצוגה הזו כדי שיוצג, כראוי, ולשמור על תאימות אם פעילות מופעלת ב מסך משני.
אם הטמעות המכשיר מאפשרות הפעלה של פעילויות רגילות ב-Android במכשיר משני למסכים ולמסכים משניים יש את android.view.Display.FLAG_PRIVATE דגל:
- [C-3-1] רק הבעלים של המסך, המערכת והפעילויות ש במסך הזה חייבת להיות אפשרות להפעיל אותו. כל אחד יכול להתחיל אל תצוגה עם android.view.Display.FLAG_PUBLIC לסמן.
3.3. תאימות ל-Native API
התאימות של קוד מקורי היא מאתגרת. לכן, מערכות הטמעה של מכשירים הם:
- [C-SR-1] מומלץ מאוד להשתמש בהטמעות של הספריות הרשומה למטה מתוך פרויקט ה-upstream של Android בקוד פתוח.
3.3.1. ממשקים בינאריים של אפליקציות
בייטקוד מנוהל של Dalvik יכול לקרוא לקוד נייטיב שמסופק באפליקציה
קובץ .apk
כקובץ .so
של ELF, שעבר הידור לחומרה המתאימה של המכשיר
של הארכיטקטורה, הקוד המקורי תלוי במעבד הבסיסי
עם הטכנולוגיה שלנו, Android מגדיר כמה ממשקי API בינאריים (ABI)
ו-Android NDK.
הטמעות מכשירים:
- [C-0-1] חייבת להיות תאימות לממשק ABI אחד או יותר של Android NDK.
- [C-0-2] חייבת לכלול תמיכה בקוד שפועל בסביבה המנוהלת כדי לקרוא לקוד נייטיב, באמצעות ממשק Java Native Interface הסטנדרטי של Java (JNI) סמנטיקה.
- [C-0-3] חייב להיות תואם למקור (כלומר תואם לכותרת) וגם תואם בינארי (ל-ABI) עם כל ספרייה נדרשת ברשימה שלמטה.
- [C-0-5] חובה לדווח באופן מדויק על הממשק המקורי של Application Binary Interface
(ABI) שנתמך על ידי המכשיר, באמצעות
android.os.Build.SUPPORTED_ABIS
,android.os.Build.SUPPORTED_32_BIT_ABIS
, וגםandroid.os.Build.SUPPORTED_64_BIT_ABIS
פרמטרים, כל אחד מהם מופרד בפסיקים של ממשקי ABI מסודרים מהגבוה לנמוך. [C-0-6] חובה לדווח על קבוצת משנה מסוימת, באמצעות הפרמטרים שלמעלה של ממשקי ABI ואסור לדווח על ממשק ABI שלא מופיע ברשימה.
armeabi
(כבר לא נתמך כיעד על ידי ה-NDK)armeabi-v7a
arm64-v8a
x86
x86-64
[C-0-7] צריך ליצור את כל הספריות הבאות, עם ממשקי API מקוריים זמין לאפליקציות שכוללות קוד נייטיב:
- libaaudio.so (תמיכה באודיו מקורי של AAudio)
- libamidi.so (תמיכה ב-MIDI מקורית, אם התכונה
android.software.midi
זמינה? הוא נתבע כפי שמתואר בסעיף 5.9) - libandroid.so (תמיכה בפעילות מובנית ב-Android)
- libc (ספריית C)
- libcamera2ndk.so
- libdl (קישור דינמי)
- libEGL.so (ניהול פלטפורמות של OpenGL נייטיב)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (רישום ביומן Android)
- libmediandk.so (תמיכה בממשקי API של מדיה מותאמת)
- libm (ספריית מתמטיקה)
- libneuralnetworks.so (Neural Networks API)
- libOpenMAXAL.so (תמיכה ב-OpenMAX AL 1.0.1)
- libOpenSLES.so (תמיכה באודיו מסוג OpenSL ES 1.0.1)
- libRS.so
- libstdc++ (תמיכה מינימלית עבור C++ )
- libvulkan.so (Vulkan)
- libz (דחיסת Zlib)
- ממשק JNI
[C-0-8] אסור להוסיף או להסיר את הפונקציות הציבוריות של ספריות המקור שצוינו למעלה.
[C-0-9] חובה לכלול ספריות נוספות שאינן AOSP שנחשפו ישירות אפליקציות צד שלישי ב-
/vendor/etc/public.libraries.txt
.[C-0-10] אסור לחשוף ספריות מקוריות אחרות, שהוטמעו מסופקים ב-AOSP כספריות מערכת, לאפליקציות צד שלישי שמטרגטות ל-API רמה 24 ומעלה כפי שמורים.
[C-0-11] חובה לייצא את כל רכיבי OpenGL ES 3.1 וחבילת התוספים ל-Android סמלי פונקציות, כפי שמוגדרים ב-NDK, דרך הספרייה
libGLESv3.so
. לתשומת ליבכם: חייבים לציין את כל הסמלים, אבל סעיף 7.1.4.1 מתאר בפירוט רב יותר על הדרישות בנוגע להטמעה המלאה של כל אחד מהרכיבים האלה את הפונקציות התואמות.[C-0-12] חובה לייצא סמלי פונקציות ייצוא של פונקציית הליבה Vulkan 1.0 וגם
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 מתאר בפירוט רב יותר את הדרישות הנוגעות למקרים שבהם הוא מצופה מההטמעה של כל פונקציות מתאימות.צריך להיבנות באמצעות קוד המקור וקובצי הכותרת הזמינים פרויקט upstream של Android בקוד פתוח
לתשומת ליבכם: יכול להיות שגרסאות עתידיות של 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
הסתעפות של 13 בנוגע להטמעת
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#getLastTime ביעילות() או כל דבר אחר שיגרום לאפליקציה לצאת ממצב ההפסקה האוטומטית, כולל קישורי שירותים, קישורים של ספקי תוכן, שידורים מפורשים וכו'. שאחריהן יתבצע מעקב באמצעות פונקציה חדשה של UsageStats#getLastTimeConditionUsed().
- [C-1-3] חובה להחיל רק הגבלות שמשפיעות על כל משתמשי המכשירים, היא הוכחה לכך שהחבילה לא הייתה בשימוש על ידי אף משתמש במשך פרק זמן מסוים בזמן האימון. מומלץ מאוד להגדיר משך זמן של חודש אחד או יותר.
- [C-1-4] אסור לאפשר לאפליקציה להגיב לכוונות פעילות, קישורי שירותים, בקשות של ספקי תוכן או שידורים בעלי תוכן בוטה.
'מצב תנומה של אפליקציות' ב-AOSP עומד בדרישות שצוינו למעלה.
3.6. מרחבי שמות של API
מערכת Android פועלת לפי מוסכמות מרחב השמות של החבילות והמחלקות שמוגדרות ב-Java בשפת תכנות. כדי להבטיח תאימות לאפליקציות של צד שלישי, אסור להם לבצע שינויים אסורים כלשהו (ראו בהמשך) כדי מרחבי השמות הבאים של חבילות:
java.*
javax.*
sun.*
android.*
androidx.*
com.android.*
כלומר, הן:
- [C-0-1] אסור לשנות את ממשקי ה-API שגלויים לכולם בפלטפורמת Android באמצעות שינוי כל שיטה או חתימות של כיתה, או הסרת כיתות או כיתה. .
- [C-0-2] אסור להוסיף אלמנטים שגלויים לכולם (כמו סיווגים ממשקים, או שדות או שיטות למחלקות או לממשקים קיימים) או לבדיקה או ממשקי API של המערכת לממשקי ה-API במרחבי השמות שלמעלה. "חשיפה באופן ציבורי יסוד" הוא כל מבנה שאינו מעוטר באמצעות ' @הסתרה' סמן בתור בקוד המקור של Android ב-upstream.
מטמיעי מכשירים עשויים לשנות את ההטמעה הבסיסית של ממשקי ה-API, אבל שינויים כאלה:
- [C-0-3] אסור להשפיע על ההתנהגות המוצהרת ועל החתימה בשפת Java של כל ממשקי API שגלויים לכולם.
- [C-0-4] אסור לפרסם או לחשוף למפתחים בכל דרך אחרת.
עם זאת, משתמשים שמטמיעים מכשירים עשויים להוסיף ממשקי API מותאמים אישית מחוץ ל-Android הרגיל מרחב השמות, אבל ממשקי ה-API המותאמים אישית:
- [C-0-5] אסור להיות במרחב שמות בבעלות אדם אחר
של הארגון. לדוגמה, למטמיעי מכשירים אסור להוסיף ממשקי API
com.google.*
או מרחב שמות דומה: רק Google יכולה לעשות זאת. באופן דומה, אסור ל-Google להוסיף ממשקי API לחברות אחרות מרחבי שמות. - [C-0-6] חייבים להיות ארוזים בספרייה משותפת של Android כך שרק אפליקציות שמשתמשים בהן במפורש (באמצעות המנגנון <uses-library>) מושפעות מהשימוש המוגבר בזיכרון של ממשקי API כאלה.
משתמשים שמטמיעים מכשירים יכולים להוסיף ממשקי API מותאמים אישית בשפות נייטיב, מחוץ ל-NDK אבל ממשקי ה-API בהתאמה אישית:
- [C-1-1] אסור להיות בספרייה NDK או בספרייה אחרת ארגון כפי שמתואר כאן.
אם מטמיע מכשיר מציע לשפר אחד ממרחבי השמות של החבילות שלמעלה (למשל, הוספה של פונקציונליות חדשה ומועילה לממשק API קיים, או הוספת פונקציונליות חדשה API), מכשיר ההטמעה צריך להיכנס לכתובת source.android.com ולהתחיל את התהליך להוספת שינויים בהתאם למידע שמופיע באותו אתר.
חשוב לשים לב שההגבלות שלמעלה תואמות למוסכמות הסטנדרטיות בנוגע למתן שמות ממשקי API בשפת התכנות Java; המטרה של הקטע הזה היא פשוט לחזק את המוסכמות האלה ולאלץ אותן לכלול את המוסכמות האלה הגדרה.
3.7. תאימות לסביבת זמן ריצה
הטמעות מכשירים:
[C-0-1] חייבת להיות תמיכה בפורמט המלא של Dalvik Executable (DEX) ו-Dalvik bytecode לרשימה and semantics.
[C-0-2] חובה להגדיר את זמני הריצה של Dalvik להקצות זיכרון בהתאם לפלטפורמת Android ב-upstream, וכפי שצוין בטבלה הבאה. (עיינו בסעיף 7.1.1 לקבלת הגדרות של גודל המסך וצפיפות המסך).
צריכה להשתמש ב-Android RunTime (ART), ההפניה ל-upstream של Dalvik Executable Format, והפניה של מערכת ניהול החבילות.
אמורות להריץ בדיקות fuzz במצבי ביצוע שונים ולטרגט ארכיטקטורות כדי להבטיח את היציבות של סביבת זמן הריצה. פרטים נוספים JFuzz ו-DexFuzz באתר של פרויקט הקוד הפתוח של Android.
שימו לב שערכי הזיכרון המפורטים למטה נחשבים לערכים מינימליים ייתכן שהטמעות במכשירים מקצים יותר זיכרון לכל אפליקציה.
פריסת מסך | דחיסות מסך | זיכרון מינימלי של האפליקציה |
---|---|---|
שעון Android | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | ||
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | 36MB | |
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (xhdpi) | 48MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 56MB | |
420 dpi (420dpi) | 64MB | |
480 dpi (xxhdpi) | 88MB | |
560 dpi (560dpi) | 112MB | |
640 dpi (xxxhdpi) | 154MB | |
קטן/רגיל | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | 48MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (xhdpi) | 80MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 96MB | |
420 dpi (420dpi) | 112MB | |
480 dpi (xxhdpi) | 128MB | |
560 dpi (560dpi) | 192MB | |
640 dpi (xxxhdpi) | 256MB | |
גדולה | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | 48MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 80MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 96MB | |
320 dpi (xhdpi) | 128MB | |
360 dpi (360dpi) | 160MB | |
400 dpi (400dpi) | 192MB | |
420 dpi (420dpi) | 228MB | |
480 dpi (xxhdpi) | 256MB | |
560 dpi (560dpi) | 384MB | |
640 dpi (xxxhdpi) | 512MB | |
xlarge | 120 dpi (ldpi) | 48MB |
140 dpi (140dpi) | 80MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 96MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 144MB | |
320 dpi (xhdpi) | 192MB | |
360 dpi (360dpi) | 240MB | |
400 dpi (400dpi) | 288MB | |
420 dpi (420dpi) | 336MB | |
480 dpi (xxhdpi) | 384MB | |
560 dpi (560dpi) | 576MB | |
640 dpi (xxxhdpi) | 768MB |
3.8. תאימות לממשק משתמש
3.8.1. מרכז האפליקציות (מסך הבית)
Android כולל את אפליקציית מרכז האפליקציות (מסך הבית) ותמיכה עבור אפליקציות של צד שלישי שיחליפו את מרכז האפליקציות של המכשיר (מסך הבית).
אם ההטמעות של המכשיר מאפשרות לאפליקציות של צד שלישי להחליף את המכשיר במסך הבית, הם:
- [C-1-1] חובה להצהיר על הפיצ'ר
android.software.home_screen
בפלטפורמה. - [C-1-2] חייב להחזיר את
AdaptiveIconDrawable
כשאפליקציית הצד השלישי משתמשת בתג<adaptive-icon>
כדי לספק הסמל שלו, וגםPackageManager
השיטות לאחזור סמלים נקראות.
אם ההטמעות במכשיר כוללות מרכז אפליקציות שמוגדר כברירת מחדל שתומך באפליקציה הם:
- [C-2-1] חובה לדווח על
true
עבורShortcutManager.isRequestPinShortcutSupported()
. - [C-2-2] המשתמש צריך לעמוד בתנאים כדי לשאול את המשתמש לפני הוספת קיצור דרך בבקשה
באמצעות אפליקציות דרך
ShortcutManager.requestPinShortcut()
שיטת ה-API. - [C-2-3] חייבת לתמוך במקשי קיצור מוצמדים ובמקשי קיצור דינמיים וסטטיים קיצורי הדרך כפי שמתואר בדף קיצורי הדרך של האפליקציות.
לעומת זאת, אם הטמעות המכשירים לא תומכות בהצמדה של מקשי קיצור:
- [C-3-1] חובה לדווח על
false
עבורShortcutManager.isRequestPinShortcutSupported()
.
אם בהטמעות במכשיר מוטמע מרכז אפליקציות שמוגדר כברירת מחדל שמספק גישה לקיצורי הדרך הנוספים שמסופקים על ידי אפליקציות צד שלישי דרך קיצורי דרך הן:
- [C-4-1] חייבת לתמוך בכל תכונות קיצורי הדרך המתועדות (למשל,
קיצורי דרך דינמיים, הצמדת קיצורי דרך) וליישם באופן מלא את ממשקי ה-API של
ShortcutManager
סיווג API.
אם ההטמעות במכשיר כוללות אפליקציית מרכז אפליקציות שמוגדרת כברירת מחדל, ומוצגים בה תגים של סמלי האפליקציות, הם:
- [C-5-1] חובה לכבד את
NotificationChannel.setShowBadge()
שיטת ה-API. במילים אחרות, להציג עלות חזותית שמשויכת לסמל האפליקציה, אם הערך מוגדר כ-true
ולא יוצג סכמת תגים של סמל האפליקציה כשהכול מערוצי ההתראות של האפליקציה, הגדירו את הערך כ-false
. - יכולים לעקוף את התגים של סמל האפליקציה בסכמת התגים הקניינית שלהם אם
של צד שלישי מציינות שיש תמיכה בסכימת התגים הקניינית
באמצעות השימוש בממשקי API קנייניים, אבל צריך להשתמש במשאבים ובערכים
מסופקים באמצעות ממשקי ה-API של תגי ההתראות שמתוארים ב-SDK,
כמו
Notification.Builder.setNumber()
וגםNotification.Builder.setBadgeIconType()
API.
אם ההטמעות במכשירים תומכים מונוכרומטי סמלים, הסמלים הבאים:
- [C-6-1] חובה להשתמש בו רק כשהמשתמש מפעיל אותם באופן מפורש (למשל, 'הגדרות' או התפריט של בוחר הטפטים).
3.8.2. ווידג'טים
מערכת Android תומכת בווידג'טים של אפליקציות צד שלישי על ידי הגדרת סוג רכיב API ומחזור חיים תואמים שמאפשרים לאפליקציות לחשוף AppWidget למשתמש הקצה.
אם הטמעות במכשירים תומכים בווידג'טים של אפליקציות של צד שלישי:
- [C-1-1] חובה להצהיר על תמיכה בתכונה 'פלטפורמה'
android.software.app_widgets
- [C-1-2] חובה לכלול תמיכה מובנית ב-AppWidgets ולאפשר חשיפה ממשק משתמש להוספה, להגדרה, להצגה ולהסרה של AppWidgets.
- [C-1-3] חייבת להיות אפשרות להציג ווידג'טים שגודלם הוא 4 x 4 בגודל הרשת הרגיל. כדאי לעיין בהנחיות העיצוב של ווידג'ט האפליקציה במסמכי התיעוד של Android SDK.
- ייתכן שתתמוך בווידג'טים של אפליקציות במסך הנעילה.
אם בהטמעות במכשירים יש תמיכה בווידג'טים של אפליקציות של צד שלישי ובאפליקציה הם:
- [C-2-1] חובה לדווח על
true
עבורAppWidgetManager.html.isRequestPinAppWidgetSupported()
. - [C-2-2] המשתמש צריך לעמוד בתנאים כדי לשאול את המשתמש לפני הוספת קיצור דרך בבקשה
באמצעות אפליקציות דרך
AppWidgetManager.requestPinAppWidget()
שיטת ה-API.
3.8.3. התראות
Android כולל את Notification
וגם
NotificationManager
ממשקי API שמאפשרים למפתחי אפליקציות של צד שלישי להודיע למשתמשים על אירועים חשובים
למשוך משתמשים תשומת לב באמצעות רכיבי החומרה (למשל צליל, רטט
אור) ותכונות תוכנה (למשל לוח הודעות, סרגל מערכת) של
במכשיר.
3.8.3.1. הצגת התראות
אם הטמעות במכשירים מאפשרות לאפליקציות של צד שלישי להודיע למשתמשים על אירועים חשובים:
- [C-1-1] חייבת לתמוך בהתראות שמשתמשות בתכונות חומרה, כפי שמתואר ב מסמכי התיעוד בנושא ה-SDK, ובמידת האפשר, דרך הטמעת המכשיר חומרה. לדוגמה, אם יישום מכשיר כולל רטט, חובה להטמיע בצורה נכונה את ממשקי ה-API של הרטט. אם הטמעת המכשיר חסרה בחומרה, ממשקי ה-API התואמים חייבים להיות מוטמעים כפעולות ללא תפעול. מה קורה? מפורט יותר בסעיף 7.
- [C-1-2] עיבוד כל המשאבים חייב להיות תקין (סמלים, קובצי אנימציה וכו') שסופקו בממשקי ה-API או מדריך סגנון סמל של סרגל הסטטוס/סרגל המערכת, למרות שהן עשויות לספק חוויית משתמש חלופית לקבלת התראות יותר מזה שסופק על ידי ההפניה בהטמעת קוד פתוח של Android.
- [C-1-3] חובה לכבד את ההתנהגות שתוארו וליישם אותה באופן תקין ממשקי ה-API כדי לעדכן, להסיר ולקבץ התראות.
- [C-1-4] חייב לספק את ההתנהגות המלאה של NotificationChannel API מתועד ב-SDK.
- [C-1-5] חובה לספק למשתמש אפשרות לחסום ולשנות התראה מאפליקציית צד שלישי בכל רמה של ערוץ וחבילת אפליקציה.
- [C-1-6] חובה לספק למשתמש גם אפשרות להציג התראה שנמחקה הערוצים שלך.
- [C-1-7] חובה לעבד באופן תקין את כל המשאבים (תמונות, סטיקרים, סמלים וכו') סופק באמצעות Notification.MessagingStyle לצד טקסט ההתראה, ללא אינטראקציה נוספת מצד המשתמש. עבור לדוגמה, חייבים להציג את כל המשאבים, כולל סמלים שסופקו באמצעות android.app.person בשיחה קבוצתית setGroupConversation.
- [C-SR-1] מומלץ מאוד לספק למשתמש מחיר נוח לשלוט בהתראות שנחשפו לאפליקציות שקיבלו את התג הרשאת 'האזנה להתראות'. רזולוציית הניווט חייבת להיות כדי שהמשתמש יוכל שליטה עבור כל מאזין התראה כזה מהם סוגי ההתראות על המאזינים האלה. הסוגים חייבים לכלול "שיחות", "התראות", 'שקט' ו'מתמשך' התראות.
- [C-SR-2] מומלץ מאוד לספק למשתמשים אפשרות לפרט אפליקציות שלא יכללו התראות ממאזינים ספציפיים להתראות.
- [C-SR-3] מומלץ מאוד להציג למשתמשים מודעות שמתאימות באופן אוטומטי להוצאות שלהם לחסום התראות מאפליקציה מסוימת של צד שלישי בכל ערוץ ואפליקציה החבילה, אחרי שהמשתמש סגר את ההתראה כמה פעמים.
- אמורות לתמוך בהתראות מתקדמות.
- אמורות להיות מוצגות התראות עם עדיפות גבוהה יותר כהתראות 'שימו לב'.
- צריכה להיות למשתמש אפשרות להשהות התראות.
- יכול להיות בניהול רק מקרים שבהם אפליקציות צד שלישי יוכלו לשלוח התראות משתמשים באירועים חשובים כדי לצמצם בעיות בטיחות כמו הסחות דעת של הנהג.
ב-Android 11 יש תמיכה בהתראות על שיחות, התראות שנעשה בהן שימוש ב-MessagingStyle ומספק מזהה קיצור דרך לאנשים שפורסם.
הטמעות מכשירים:
- [C-SR-4] מומלץ מאוד לקבץ ולהציג
conversation notifications
לפני התראות על הודעות שאינן שיחה, מלבד התראות מתמשכות לגבי שירות שפועל בחזית ו-importance:high
התראות.
אם בהטמעות במכשירים יש תמיכה ב-conversation notifications
והאפליקציה מספקת את הנתונים הנדרשים
bubbles
, הן:
- [C-SR-5] מומלץ מאוד להציג את השיחה הזו כבועה. הטמעת ה-AOSP עומדת בדרישות הבאות באמצעות ממשק המשתמש של המערכת שמוגדר כברירת מחדל, הגדרות, מרכז האפליקציות.
אם בהטמעות במכשירים יש תמיכה בהתראות מתקדמות, הן:
- [C-2-1] חייבים להשתמש במשאבים המדויקים כמו
סופקו באמצעות
Notification.Style
מחלקה של API ומחלקות המשנה שלו עבור רכיבי המשאבים המוצגים. - צריך להציג כל אחד מרכיבי המשאב (למשל,
סמל, כותרת וטקסט סיכום) שמוגדרים ב
Notification.Style
. ה-API ומחלקות המשנה שלו.
התראות 'שימו לב' הן התראות מוצגת למשתמש כשהוא נכנס בנפרד לפלטפורמה שבה המשתמש נמצא מופעלת. אם ההטמעות במכשירים תומכים בתכונה 'שימו לב' התראות, ואז:
- [C-3-1] חובה להשתמש במשאבים ובתצוגת ההתראות של 'שימו לב'
כפי שמתואר ב
Notification.Builder
סיווג API כשמוצגות התראות 'שימו לב'. - [C-3-2] חובה להציג את הפעולות שסופקו באמצעות
Notification.Builder.addAction()
יחד עם תוכן ההתראה, ללא אינטראקציה נוספת מצד המשתמש כפי שמתואר ב-SDK.
3.8.3.2. שירות האזנה להתראות
Android כולל את NotificationListenerService
ממשקי API שמאפשרים לאפליקציות (לאחר שהמשתמש הפעיל אותן באופן מפורש) לקבל עותק של
את כל ההתראות כאשר הן מתפרסמות או מתעדכנות.
הטמעות מכשירים:
- [C-0-1] יש לעדכן את ההתראות באופן תקין ומהיר לכל שירותי המאזינים המותקנים ומותאמי המשתמשים, כולל את כל המטא-נתונים שמצורפים לאובייקט ההתראה.
- [C-0-2] חובה לכבד את
snoozeNotification()
קריאה ל-API, סגירת ההתראה וביצוע קריאה חוזרת אחרי הטיפול לטיפול בהמשך משך הזמן שמוגדר בקריאה ל-API.
אם בהטמעות של מכשירים יש למשתמש אפשרות להשהות התראות:
- [C-1-1] חייבת לשקף כראוי את הסטטוס של ההתראה במצב 'נודניק'
באמצעות ממשקי ה-API הרגילים כמו
NotificationListenerService.getSnoozedNotifications()
- [C-1-2] המשתמש צריך להיות זמין להשהיית התראות באופן יחסי מכל אפליקציה מותקנת של צד שלישי, אלא אם שירותים קבועים או שפועלים בחזית.
3.8.3.3. נא לא להפריע (נא לא להפריע)/ מצב עדיפות
אם הטמעות המכשיר תומכות בתכונה DND (שנקרא גם 'מצב עדיפות'), הן:
- [C-1-1] חובה, כאשר הטמעת המכשיר מספקת אמצעי למשתמש כדי להעניק או לדחות לאפליקציות צד שלישי גישה להגדרות המדיניות של ה-DND, הצגת כללי DND אוטומטיים שנוצרו על ידי אפליקציות לצד הכללים שנוצרו על ידי המשתמשים ומוגדרים מראש.
- [C-1-3] חייב לכבד את
suppressedVisualEffects
ערכים שמועברים לאורך הערךNotificationManager.Policy
ואם אפליקציה הגדירה SUPPRESSED_EFFECT_SCREEN_OFF או SUPPRESSED_EFFECT_SCREEN_ON מסומן, יש לציין למשתמש ש האפקטים החזותיים מושבתים בתפריט ההגדרות של DND.
3.8.4. ממשקי API של Assist
מערכת Android כוללת את Assist APIs כדי לאפשר לאפליקציות לבחור כמה מידע מתוך ההקשר הנוכחי משותף עם Assistant במכשיר.
אם הטמעות מכשירים תומכות בפעולה Assist:
- [C-2-1] חובה לציין בבירור למשתמש הקצה מתי ההקשר משותף, על ידי
אחת משתי האפשרויות:
- בכל פעם שאפליקציית העזרה ניגשת להקשר, מוצג סמל לבן אור מסביב לקצוות המסך אם משך הזמן ארוך או ארוך יותר, הבהירות של הטמעת פרויקט הקוד הפתוח של Android.
- עבור אפליקציית העזרה המותקנת מראש, הצעת מחיר נמוכה יותר למשתמש במרחק של שני ניווטים בתפריט ההגדרות של אפליקציית העזרה והקלט הקולי שמוגדר כברירת מחדל, ושיתוף ההקשר רק כאשר אפליקציית העזרה מופעלת באופן מפורש על ידי את המשתמש באמצעות מילת הפעלה או קלט של מקש ניווט.
- [C-2-2] האינטראקציה הייעודית להפעלת אפליקציית העזרה, כפי שמתואר
בסעיף 7.2.3 חייבים להפעיל את
אפליקציית עזר מסוימת. במילים אחרות, האפליקציה שמטמיעה את
VoiceInteractionService
, או פעילות שמטפלת בהכוונה שלACTION_ASSIST
.
3.8.5. התראות והודעות קוליות
אפליקציות יכולות להשתמש בToast
API להצגת מחרוזות קצרות שאינן מודאליות למשתמש הקצה שנעלמות אחרי
לפרק זמן קצר, ולהשתמש בTYPE_APPLICATION_OVERLAY
window type API להצגת חלונות התראות כשכבת-על מעל אפליקציות אחרות.
אם הטמעות במכשירים כוללות פלט מסך או פלט וידאו:
[C-1-1] חובה לספק למשתמש אפשרות למנוע מאפליקציה להציג התראות חלונות שנעשה בהם שימוש ברכיב
TYPE_APPLICATION_OVERLAY
הקצר הזה. התשובות שלך יעזרו לנו להשתפר. הטמעת ה-AOSP עומדת בדרישה הזו בכך שהיא כוללת פקדים בלוח ההתראות.[C-1-2] חייבים לפעול בהתאם ל-Toast API ולהציג טוסטים מאפליקציות למשתמשי קצה במקרים מסוימים באופן גלוי.
3.8.6. עיצובים
ב-Android יש 'עיצובים' כמנגנון לאפליקציות להחלת סגנונות פעילות או אפליקציה בשלמותה.
Android כולל "Holo" ו-"Material" משפחת עיצובים כסדרה של סגנונות מוגדרים שמפתחי אפליקציות יוכלו להשתמש בהן אם הם רוצים להתאים מראה וסגנון של עיצוב Hoolo כפי שהוגדר על ידי Android SDK.
אם הטמעות במכשירים כוללות פלט מסך או פלט וידאו:
- [C-1-1] אסור לשנות את המאפיינים של עיצוב Hoolo שנחשפים תרגום מכונה.
- [C-1-2] חייבים לתמוך במשפחת העיצובים Material (חומר) ואסור לשנות אף אחד מהם מאפייני העיצוב של חומר הלימוד או הנכסים שלהם חשופים לאפליקציות.
[C-1-3] חובה להגדיר את "sans-serif" משפחת גופנים ל Roboto גרסה 2.x עבור השפות ש-Roboto תומך בו או מספק למשתמש אפשרות לשנות את הגופן שבו נעשה שימוש ל-sans-serif משפחת הגופנים לRoboto גרסה 2.x עבור השפות הנתמכות ב-Roboto.
[C-1-4] חובה ליצור לוחות צבעים דינמיים של צבעים כפי שצוין ב-AOSP תיעוד של
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(מידע נוסף זמין כאןandroid.theme.customization.system_palette
והקבוצהandroid.theme.customization.theme_style
).[C-1-5] חובה ליצור לוחות צבעים דינמיים של צבעים באמצעות סגנונות של ערכת צבעים שצויין ב-
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
תיעוד (ראוandroid.theme.customization.theme_styles
), כלומרTONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
,FRUIT_SALAD
.צבע המקור משמש ליצירת לוחות צבעים דינמיים של צבעים כאשר נשלחים
android.theme.customization.system_palette
(כפי שמתועד ב-Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
).[C-1-6] ערך chroma
CAM16
חייב להיות גבוה מ-5.אמור להיגזר מהטפט דרך
com.android.systemui.monet.ColorScheme#getSeedColors
, שמספק מספר צבעי מקור חוקיים לבחירה אחד.צריך להשתמש בערך
0xFF1B6EF3
אם אף אחד מהצבעים שצוינו לא מתאים את דרישת צבע המקור שצוינה למעלה.
מערכת Android כוללת גם את משפחת העיצובים 'ברירת המחדל של המכשיר' כקבוצה של סגנונות מוגדרים שבו מפתחי אפליקציות יוכלו להשתמש אם הם רוצים להתאים למראה ולתחושה של ערכת הצבעים במכשיר כפי שהוגדר בהטמעה של המכשיר.
- הטמעת מכשירים עשויה לשנות את מאפייני העיצוב שמוגדרים כברירת מחדל במכשיר שנחשפים לאפשרויות הבאות: תרגום מכונה.
ב-Android יש תמיכה בעיצוב וריאנטים עם סרגלי מערכת שקופים, שמאפשרים של מפתחי אפליקציות למלא את האזור שמאחורי הסטטוס וסרגל הניווט עם התוכן של האפליקציה. כדי לאפשר חוויית פיתוח עקבית חשוב לשמור על סגנון הסמלים של שורת הסטטוס של מכשירים שונים.
אם יישומי המכשיר כוללים שורת סטטוס של המערכת:
- [C-2-1] חובה להשתמש בלבן לסמלי סטטוס המערכת (כמו עוצמת אות רמת הטעינה) והתראות על ידי המערכת, אלא אם הסמל שמציינת סטטוס בעייתי או שאפליקציה מבקשת שורת סטטוס נורית באמצעות WindowInsetsController#APPEARANCE_Light_STATUS_BARS לסמן.
- [C-2-2] הטמעות של מכשירי Android חייבות לשנות את צבע המערכת סמלי הסטטוס לשחור (לפרטים, אפשר לקרוא את המאמר R.style) כשאפליקציה מבקשת שורת סטטוס של נורית.
3.8.7. טפטים מונפשים
ב-Android מוגדרים סוג רכיב ו-API ומחזור חיים תואמים שמאפשרים חשיפה אחת או יותר "טפטים מונפשים" למשתמש הקצה. טפטים דינמיים הם אנימציות, תבניות או תמונות דומות עם יכולות קלט מוגבלות שמוצגות כטפט, תרגום מכונה.
החומרה נחשבת מאפשרת הפעלה אמינה של טפטים מונפשים אם היא יכולה לפעול כל הטפטים המונפשים, ללא מגבלות על פונקציונליות, במסגרת סבירה ללא השפעות שליליות על אפליקציות אחרות. אם הגבלות חומרה שגורמת לטפטים ו/או לאפליקציות לקרוס, לתקלה, ליצור עוצמת המעבד (CPU) או הסוללה פועלים בקצב פריימים נמוך מדי, באופן שאינו מקובל, שנחשבת כחומרה שלא מאפשרת להפעיל טפט דינמי. לדוגמה, כמה טפטים דינמיים עשויים להשתמש בהקשר של OpenGL 2.0 או 3.x כדי לעבד את התוכן שלהם. טפט דינמי לא יפעל באופן מהימן בחומרה שלא תומכת בריבוי הקשרי OpenGL כי השימוש בטפט הפעיל בהקשר של OpenGL עלול להיות מתנגש עם אפליקציות אחרות שמשתמשות גם בהקשר של OpenGL.
- הטמעת מכשירים שמאפשרים להריץ טפטים דינמיים באופן מהימן, כפי שמתואר שלמעלה אמורה להטמיע טפטים מונפשים.
אם הטמעתם במכשיר טפטים דינמיים:
- [C-1-1] חובה לדווח על דגל הפלטפורמה android.software.live_wallpaper.
3.8.8. החלפת פעילות
קוד המקור של Android ב-upstream כולל את מסך הסקירה הכללית, a ממשק משתמש ברמת המערכת למעבר בין משימות ולהצגה של גישה מהזמן האחרון פעילויות ומשימות באמצעות תמונה ממוזערת של הגרפיקה של האפליקציה ברגע שהמשתמש עזב את האפליקציה בפעם האחרונה.
הטמעת מכשירים כולל מקש הניווט של הפונקציה האחרונה, כפי שמפורט סעיף 7.2.3 עשוי לשנות את הממשק.
אם בהטמעות של מכשירים, כולל מקש הניווט של הפונקציה האחרונה, כפי שמפורט ב 7.2.3 משנים את הממשק, הן:
- [C-1-1] חייבת לתמוך לפחות ב-7 פעילויות מוצגות.
- צריכה להציג לפחות כותרת של 4 פעילויות בכל פעם.
- [C-1-2] חובה ליישם את ההתנהגות של הצמדת מסך ולספק למשתמש תפריט הגדרות כדי להפעיל או להשבית את התכונה.
- אמורות להציג את צבע ההדגשה, הסמל וכותרת המסך האחרונים.
- אמורה להציג מחיר סגירה (x) אבל יכול להיות שיחול עיכוב עד שתהיה למשתמש אינטראקציה עם המסכים.
- עליכם להטמיע קיצור דרך כדי לעבור בקלות לפעילות הקודמת.
- אמורה להפעיל את פעולת המעבר המהיר בין שתי התוכנות האחרונות שהיו בשימוש אפליקציות, כשמקישים פעמיים על מקש הפונקציה האחרון.
- אמורה להפעיל את מצב ריבוי חלונות של מסך מפוצל, אם יש תמיכה, ללחיצה ארוכה על 'פונקציות אחרונות'.
- יכול להיות שיוצגו נכסים משויכים אחרונים כקבוצה שנעשית יחד.
- [C-SR-1] מומלץ מאוד להשתמש במשתמש Android OS (או ממשק דומה מבוסס על תמונות ממוזערות) למסך הסקירה הכללית.
3.8.9. ניהול קלט
Android כולל תמיכה ב: ניהול קלט ותמיכה לעורכים של שיטות קלט של צד שלישי.
אם הטמעות של מכשירים מאפשרות למשתמשים להשתמש בשיטות קלט של צד שלישי במכשיר, הן:
- [C-1-1] חובה להצהיר על תכונת הפלטפורמה android.software.input_methods וגם לתמוך בממשקי API של IME כפי שמוגדר במסמכי התיעוד של Android SDK.
3.8.10. בקרת מדיה במסך הנעילה
ה-API של הלקוח של השלט הרחוק הוצא משימוש ב-Android 5.0 לטובת תבנית של התראות מדיה שמאפשר לאפליקציות מדיה להשתלב עם פקדי הפעלה תוצג במסך הנעילה.
3.8.11. שומרי מסך (לשעבר Dreams)
להגדרות, יש לעיין בסעיף 3.2.3.5 בכוונה לצרף את שומרי המסך.
3.8.12. מיקום
אם יישומי המכשיר כוללים חיישן חומרה (למשל GPS) בעל יכולות בציון הקואורדינטות של המיקום,
- [C-1-2] חובה להציג את הסטטוס הנוכחי של המיקום בתפריט המיקום שב'הגדרות'.
- [C-1-3] אסור להציג מצבי מיקום בתפריט המיקום שב'הגדרות'.
3.8.13. Unicode וגופן
מערכת Android כוללת תמיכה בתווי האמוג'י שמוגדרים ב Unicode 10.0.
אם הטמעות במכשירים כוללות פלט מסך או פלט וידאו:
- [C-1-1] חייבת להיות אפשרות להציג את תווי האמוג'י האלה בגליף צבעים.
- [C-1-2] חייבת לכלול תמיכה בנושאים הבאים:
- גופן Roboto 2 עם משקלים שונים –sans-serif-thin, San-serif-light, Sans Serif-medium, sens-serif-black, sans-serif-מרוכז, Sans-Sift-endured Contracted לשפות הזמינות במכשיר.
- כיסוי מלא של Unicode 7.0 לאותיות לטיניות, יווניות וקיריליות, כולל טווחים לטיניים מורחבים A, B, C ו-D וכל הגליפים במטבע של Unicode 7.0.
- [C-1-3] אסור להסיר או לשנות את NotoColorEmoji.tff בתמונת המערכת. (ניתן להוסיף גופן חדש לאמוג'י כדי לשנות את האמוג'י במקום הזה NotoColorEmoji.tff)
- צריכה לתמוך בגוון העור ובסמלי אמוג'י משפחתיים מגוונים, כפי שמצוין דוח טכני מס' 51 של Unicode.
אם הטמעות המכשירים כוללות IME, הן:
- צריכה לספק למשתמשים שיטת קלט לתווי האמוג'י האלה.
ב-Android יש תמיכה בעיבוד גופנים במיאנמר. במיאנמר יש כמה גופנים שאינם תואמים ל-Unicode, המוכרים בשם "Zawgyi", לעיבוד מיאנמר בשפות שונות.
אם הטמעות המכשירים כוללות תמיכה בבורמזית, הן:
- [C-2-1] חייב לעבד טקסט בגופן תואם Unicode כברירת מחדל. אסור להגדיר גופן שלא תואם ל-Unicode, אלא אם המשתמש בוחר אותה בכלי לבחירת שפה.
- [C-2-2] חייב לתמוך בגופן Unicode ובגופן שאינו תואם ל-Unicode אם במכשיר יש תמיכה בגופן שאינו תואם ל-Unicode. לא בפורמט Unicode אסור להסיר או להחליף את הגופן ב-Unicode.
- [C-2-3] יש לעבד טקסט עם גופן שאינו תואם ל-Unicode רק אם קוד שפה עם קוד סקריפט Qaag מוגדר (למשל my-Qaag). אין קודי שפה או אזורים אחרים של ISO (בין אם מוקצים, לא מוקצים או שמורים) כדי להתייחס לקובצי Unicode גופן שתואם למיאנמר. מפתחי אפליקציות ומחברים של דפי אינטרנט יכולים לציין את my-Qaag כקוד השפה הייעודי, כפי שיועד לכל שפה אחרת.
3.8.14. חלונות מרובים
אם יישומים של מכשירים יכולים להציג פעילויות מרובות באותו זמן:
- [C-1-1] חייבים להטמיע מצב כזה של ריבוי חלונות בהתאם התנהגות של אפליקציות וממשקי API שמתוארים ב-Android SDK מסמכי תיעוד לתמיכה במצב ריבוי חלונות ופגישות הדרישות הבאות:
- [C-1-2] חובה לכבד את
android:resizeableActivity
שמוגדר על ידי אפליקציה בקובץAndroidManifest.xml
כפי שמתואר ערכת ה-SDK הזו. - [C-1-3] אסור להציע מצב מסך מפוצל או מצב חופשי אם גובה המסך קטן מ-440dp ורוחב המסך קטן מ-440 dp.
- [C-1-4] אסור לשנות את הגודל של פעילות לגודל הקטן מ-220dp אינץ' למצבים של ריבוי חלונות שאינם 'תמונה בתוך תמונה'.
- הטמעת מכשירים עם גודל מסך
xlarge
צריכה לתמוך בפריסה גמישה במצב תצוגה.
אם בהטמעות של מכשירים יש תמיכה במצבים של ריבוי חלונות, והמסך המפוצל במצב הזה:
- [C-2-2] חובה לחתוך את הפעילות בעגינה של מסך מפוצל עם כמה חלונות, אבל אמור להציג תוכן מסוים ממנו, אם אפליקציית מרכז האפליקציות היא החלון שבו מתמקדים.
- [C-2-3] חובה לפעול בהתאם להצהרה
AndroidManifestLayout_minWidth
שהוצהרה ו-AndroidManifestLayout_minHeight
של יישום מרכז האפליקציות של צד שלישי ולא לבטל את הערכים האלה. כשמציגים תוכן מסוים של הפעילות באביזר העגינה.
אם בהטמעות המכשיר יש תמיכה במצבי ריבוי חלונות ובתמונה בתוך תמונה במצב ריבוי חלונות, הם:
- [C-3-1] חובה להפעיל פעילויות במצב 'תמונה בתוך תמונה' בכמה חלונות
כשהאפליקציה:
* טירגוט לרמת API 26 ומעלה וההצהרה מוצהרת
android:supportsPictureInPicture
* טירגוט לרמת API 25 ומטה והצהרה על שתיהןandroid:resizeableActivity
וandroid:supportsPictureInPicture
. - [C-3-2] חייבים לחשוף את הפעולות ב-SystemUI בתור
מצוין על ידי הפעילות הנוכחית של התמונה בתוך התמונה (PIP) באמצעות
setActions()
API. - [C-3-3] חייב לתמוך ביחסי גובה-רוחב שגדולים מ- או שווים לו
1:2.39 וקטן מ-2.39:1 או שווה לו, כפי שצוין בפעילות PIP דרך
setAspectRatio()
API. - [C-3-4] חובה להשתמש ב-
KeyEvent.KEYCODE_WINDOW
כדי לשלוט בחלון 'תמונה בתוך תמונה'; אם מצב PIP לא מוטמע, המפתח חייב להיות זמינים לפעילות בחזית. - [C-3-5] חובה לספק למשתמשים מספיק כסף כדי לחסום את הצגת האפליקציה מצב PIP; שהטמעת ה-AOSP עומדת בדרישה הזו. הפקדים בלוח ההתראות.
[C-3-6] חובה להקצות את הרוחב והגובה המינימליים הבאים בשביל התמונה בתוך התמונה (PIP) חלון זמן שבו האפליקציה לא מצהירה על ערך כלשהו של
AndroidManifestLayout_minWidth
וגםAndroidManifestLayout_minHeight
:- מכשירים שהמצב Configuration.uiMode שלהם מוגדר מלבד
UI_MODE_TYPE_TELEVISION
רוחב וגובה מינימליים חייבים להיות 108dp. - מכשירים שהמצב Configuration.uiMode שלהם מוגדר לערך
UI_MODE_TYPE_TELEVISION
חובה להקצות רוחב מינימלי של 240dp וגובה מינימלי של 135dp.
- מכשירים שהמצב Configuration.uiMode שלהם מוגדר מלבד
3.8.15. גזירה במסך
Android תומך בגזירה במסך כפי שמתואר
במסמך ה-SDK. ה-API DisplayCutout
מגדיר
אזור בקצה המסך שייתכן שאינו פעיל עבור אפליקציה
בגלל חיתוך התצוגה או תצוגה מעוקלת בקצוות.
אם הטמעתם במכשירים את המגרעת במסך, המכשיר:
- [C-1-5] אסור שיהיו גזירים אם יחס הגובה-רוחב של המכשיר הוא 1.0(1:1).
- [C-1-2] אסור לכלול יותר מגזיר אחד בכל קצה.
- [C-1-3] חובה לפעול בהתאם לסימוני המגרעת במסך שהוגדרו על ידי האפליקציה דרך
WindowManager.LayoutParams
API כפי שמתואר ב-SDK. - [C-1-4] חובה לדווח על הערכים הנכונים לכל מדדי המגרעת שמוגדרים
DisplayCutout
API.
3.8.16. ממשק השליטה במכשירים
Android כולל ControlsProviderService
ו-Control
ממשקי API שמאפשרים לאפליקציות של צד שלישי לפרסם פקדי מכשירים
הסטטוס והפעולה עבור המשתמשים.
דרישות ספציפיות למכשיר מופיעות בסעיף 2_2_3.
3.8.17. לוח
הטמעות מכשירים:
- [C-0-1] אסור לשלוח נתונים שבלוח העריכה לשום רכיב, פעילות, שירות או בכל חיבור לרשת, ללא פעולה מפורשת מצד המשתמש (למשל, לחיצה על לחצן בשכבת-העל), מלבד שירותים שמוזכרים ב 9.8.6 תיעוד תוכן וחיפוש באפליקציות.
אם בזמן העתקת התוכן מתבצעת הפעלה של הטמעות המכשירים, והתצוגה המקדימה שלו גלויה למשתמש.
ללוח של כל פריט ClipData
שבו
ClipData.getDescription().getExtras()
מכיל
android.content.extra.IS_SENSITIVE
, הן:
- [C-1-1] חובה לצנזר את התצוגה המקדימה הגלויה למשתמש
הטמעת קובץ העזר של AOSP עומדת בדרישות הבאות לגבי הלוח.
3.9. ניהול המכשיר
מערכת Android כוללת תכונות שמאפשרות לאפליקציות מבוססות אבטחה לפעול פונקציות ניהול המכשיר ברמת המערכת, כמו אכיפת סיסמה או לבצע מחיקה מרחוק, באמצעות Android Device Administration API
אם הטמעות המכשירים מיושמות את כל הטווח של ניהול מכשירים לכללי המדיניות שמוגדרים במסמכי התיעוד של Android SDK, הם:
- [C-1-1] חובה להצהיר על
android.software.device_admin
. - [C-1-2] חובה לתמוך בהקצאת הרשאות ידנית של בעלי המכשיר כפי שמתואר ב 3.9.1 וגם סעיף 3.9.1.1.
3.9.1 הקצאת מכשיר
3.9.1.1 הקצאה של הרשאות בעלי המכשיר
אם הטמעות המכשירים מצהירות על android.software.device_admin
, הן:
- [C-1-1] חייבת לתמוך ברישום של Device Policy (DPC) בתור
האפליקציה של בעלי המכשיר
כפי שמתואר בהמשך:
- כאשר הטמעת המכשיר כוללת
לא משתמשים ולא
של נתוני המשתמש, הוא:
- [C-1-5] חובה לרשום את אפליקציית DPC כאפליקציה של בעלי המכשיר
או להפעיל את אפליקציית ה-DPC כדי לבחור אם
להפוך לבעלי מכשיר או לבעלים של פרופיל,
אם המכשיר מצהיר על תמיכה בתקשורת מטווח קצר (NFC) דרך
דגל התכונה
android.hardware.nfc
ומקבל הודעת NFC שמכיל רשומה עם סוג 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 בתור האפליקציה של בעלי המכשיר עוד.
- כאשר הטמעת המכשיר כוללת
לא משתמשים ולא
של נתוני המשתמש, הוא:
- [C-1-2] חובה להציג הודעת גילוי נאות הולמת (כמו שמוזכרים ב-AOSP) ולקבל הסכמה מפורשת ממשתמש הקצה לפני הפעלת האפליקציה מוגדר כבעלים של המכשיר, אלא אם המכשיר מוגדר באופן פרוגרמטי למצב הדגמה לקמעונאים לפני האינטראקציה על המסך עם משתמשי הקצה.
אם בהטמעות המכשירים מוצהר על android.software.device_admin
, אבל גם
כוללים פתרון קנייני לניהול מכשירים ומספקים מנגנון
לקדם אפליקציה שהוגדרה בפתרון שלהם בתור 'בעלי המכשיר
מקביל" אל 'בעלי המכשיר' הרגיל כפי שמוכר על ידי התקן Android הרגיל
DevicePolicyManager
ובממשקי API הם:
- [C-2-1] חייב להיווצר תהליך לאימות האפליקציה הספציפית הקידום שייך לניהול מכשירים תקין בארגון והוא הוגדר בפתרון הקנייני להיות בעלי הזכויות המקבילות ל'בעלי המכשיר'.
- [C-2-2] חובה להציג את אותו גילוי נאות לגבי הסכמה לבעלי מכשיר ב-AOSP כמו
תהליך ביוזמת
android.app.action.PROVISION_MANAGED_DEVICE
לפני רושמים את אפליקציית DPC בתור 'בעלי המכשיר'. - [C-2-3] אסור לכתוב בתוך הקוד את ההסכמה או למנוע שימוש באפליקציות אחרות של בעלי המכשיר.
3.9.1.2 הקצאת פרופילים מנוהלים
אם הטמעות המכשירים מצהירות על android.software.managed_users
, הן:
[C-1-1] חובה להטמיע את ממשקי ה-API מאפשרת לאפליקציה Device Policy Controller (DPC) להפוך ל הבעלים של פרופיל מנוהל חדש.
[C-1-2] תהליך הקצאת הפרופיל המנוהל (התהליך שהופעל על ידי בקר ה-DPC באמצעות android.app.action.PROVISION_MANAGED_PROFILE) או על ידי הפלטפורמה), מסך ההסכמה וחוויית המשתמש חייבים להתאים בהטמעת ה-AOSP.
[C-1-3] חייבים לספק בהגדרות את ההרשאות הבאות למשתמשים כדי: לציין למשתמש כאשר פונקציית מערכת מסוימת הושבתה על ידי Device Policy Controller (DPC):
- סמל עקבי או עלות אחרת של המשתמש (לדוגמה, סמל מידע של AOSP) כדי לייצג מקרים שבהם הגדרה מסוימת מוגבלת על ידי אדמין של מכשירים.
- הודעת הסבר קצרה שתישלח מאדמין המכשיר דרך
setShortSupportMessage
- הסמל של אפליקציית בקר DPC.
[C-1-4] חובה להפעיל את ה-handler של ACTION_PROVISIONING_PROGRESSFUL Intent בפרופיל העבודה אם קיים בעלים של פרופיל כאשר ההקצאה מתבצעת על ידי android.app.action.PROVISION_MANAGED_PROFILE Intent וה-DPC יישם את ה-handler.
[C-1-5] חובה לשלוח ACTION_PROFILE_PROVISIONING_COMPLETE לשדר ל-DPC של פרופיל העבודה כאשר הקצאת ההרשאות מתחילה על ידי android.app.action.PROVISION_MANAGED_PROFILE בכוונה טובה.
[C-1-6] חובה לשלוח את ACTION_GET_PROVISIONING_מצב Intent אחרי שההקצאה של בעלי הפרופיל מופעלת, כך שאפליקציית ה-DPC יכול לבחור אם להפוך לבעלי מכשיר או לבעלים של פרופיל, למעט כאשר הקצאת ההרשאות מופעלת על ידי ה-Intent android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-7] חובה לשלוח את ACTION_ADMIN_POLICY_COMPLIANCE כוונה לפרופיל העבודה כאשר נוצר בעלים של פרופיל במהלך הקצאה ללא קשר לשיטת ההקצאה שבה נעשה שימוש, כשניהול ההקצאות מופעל על ידי ה-Intent android.app.action.PROVISION_MANAGED_PROFILE. למשתמש לא תהיה אפשרות להמשיך באשף ההגדרה עד הפרופיל האפליקציה של הבעלים הסתיימה.
[C-1-8] חובה לשלוח ACTION_MANAGED_PROFILE_PROVISIONED לשדר ל-DPC של הפרופיל האישי כשנוצר בעל פרופיל, ללא קשר לשיטת הקצאת ההרשאות שנבחרה.
3.9.2 תמיכה בפרופילים מנוהלים
אם הטמעות המכשירים מצהירות על android.software.managed_users
, הן:
- [C-1-1] חייבת לתמוך בפרופילים מנוהלים דרך
android.app.admin.DevicePolicyManager
ממשקי API. - [C-1-2] חובה לאפשר יצירה של פרופיל מנוהל אחד בלבד.
- [C-1-3] חובה להשתמש בתג סמל (בדומה לתג העבודה ב-AOSP) כדי לייצג את האפליקציות והווידג'טים המנוהלים ורכיבים אחרים בממשק המשתמש עם תגים כמו 'אחרונים' ו- התראות.
- [C-1-4] חייב להציג סמל התראה (בדומה לפעולת upstream של AOSP כדי לציין מתי המשתמש נמצא באפליקציית פרופיל מנוהל.
- [C-1-5] חייב להציג הודעה קופצת שמציינת שהמשתמש נמצא בחשבון מנוהל פרופיל אם וכאשר המכשיר יתעורר (ACTION_USER_PRESENT) האפליקציה בחזית נמצאת בפרופיל המנוהל.
- [C-1-6] במקומות שבהם קיים פרופיל מנוהל, חייב להיות מציגים תועלת ויזואלית 'בורר' של Intent כדי לאפשר למשתמש להעביר את הכוונה מהחשבון המנוהל למשתמש הראשי או להפך, אם הוא מופעל באמצעות מדיניות המכשיר בקר.
- [C-1-7] במקרים שבהם קיים פרופיל מנוהל, חובה לחשוף את המשתמש הבא
מחירים נוחים גם למשתמש הראשי וגם לפרופיל המנוהל:
- התייחסות נפרדת לשימוש בסוללה, במיקום, בחבילת הגלישה ובנפח האחסון של המשתמש הראשי והפרופיל המנוהל.
- ניהול עצמאי של אפליקציות VPN שמותקנות בתוך האפליקציה הראשית או פרופיל מנוהל.
- ניהול עצמאי של אפליקציות שמותקנות בתוך המשתמש הראשי או פרופיל מנוהל.
- ניהול עצמאי של חשבונות בתוך המשתמש הראשי או בחשבון המנוהל פרופיל.
- [C-1-8] חובה לוודא שהחייגן, אנשי הקשר והודעות הטקסט מותקנים מראש אפליקציות יכולות לחפש ולחפש מידע על מתקשרים (אם קיים) לצד הפרופילים מהפרופיל הראשי, אם המכשיר לבקרת מדיניות המכשירים מתיר זאת.
- [C-1-9] חייב לוודא שהוא עומד בכל דרישות האבטחה רלוונטי למכשיר שבו מופעלים משתמשים מרובים (ראו סעיף 9.5), למרות שהפרופיל המנוהל לא נספר כמשתמש אחר בנוסף למשתמש הראשי.
אם בהטמעות המכשירים מוצהר על 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.10. נגישות
ב-Android יש שכבת נגישות שעוזרת למשתמשים עם מוגבלויות לנווט במכשירים שלהם בקלות רבה יותר. בנוסף, Android מספק ממשקי API לפלטפורמה שמאפשרות לאפליקציות של שירותי נגישות לקבל קריאות חוזרות (callback) של משתמשים ואירועי מערכת, וליצור מנגנוני משוב חלופיים, כמו המרת טקסט לדיבור (TTS), משוב פיזי וניווט באמצעות כדור עקיבה/D-pad.
אם הטמעות במכשירים תומכים בשירותי נגישות של צד שלישי:
- [C-1-1] חובה לספק הטמעה של תכונות הנגישות ב-Android כפי שמתואר ממשקי API לנגישות מסמכי תיעוד בנושא SDK.
- [C-1-2] חובה ליצור אירועי נגישות ולספק את האירועים המתאימים
AccessibilityEvent
לכל הרשומותAccessibilityService
והטמעות כפי שמתואר ב-SDK. - [C-1-4] חובה לספק למשתמש מחיר שמאפשר שליטה בנגישות שירותים שמצהירים על AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_button שימו לב שבהטמעות במכשירים עם סרגל ניווט של המערכת, אמורה לאפשר למשתמש אפשרות ללחוץ על הלחצן סרגל ניווט כדי לשלוט בשירותים האלה.
אם הטמעות המכשירים כוללות שירותי נגישות שהותקנו מראש, הן:
- [C-2-1] חובה להטמיע את שירותי הנגישות המותקנים מראש האלה מוּדעוּת להפעלה ישירה אפליקציות כשאחסון הנתונים מוצפן באמצעות הצפנה מבוססת-קבצים (FBE).
- אמור לספק מנגנון בתהליך ההגדרה הראשוני שהמשתמשים יכולים להפעיל. שירותי נגישות רלוונטיים וגם אפשרויות להתאמת גודל הגופן, גודל התצוגה ותנועות הגדלה.
3.11. המרת טקסט לדיבור (TTS)
ב-Android יש ממשקי API שמאפשרים לאפליקציות להשתמש בהמרת טקסט לדיבור (TTS) (TTS) ומאפשרים לספקי שירות לספק יישומים של TTS שירותים שונים.
אם יישומים של מכשירים מדווחים על התכונה android.hardware.audio.output, הם:
- [C-1-1] חייבת לתמוך מסגרת Android TTS ממשקי API.
אם הטמעות המכשיר תומכות בהתקנה של מנועי TTS של צד שלישי, הן:
- [C-2-1] חובה לאפשר למשתמש לבחור טקסט לדיבור לשימוש ברמת המערכת.
3.12. מסגרת של קלט טלוויזיה
Android Television קלט Framework (TIF) מפשט את העברת השידורים החיים של Android TV. TIF מספקת ממשק API סטנדרטי כדי ליצור מודולי קלט ששולטים במכשירי Android TV.
אם הטמעות במכשירים תומכים ב-TIF:
- [C-1-1] חובה להצהיר על הפיצ'ר
android.software.live_tv
בפלטפורמה. - [C-1-2] חייבת לתמוך בכל ממשקי ה-API של TIF, כך שאפליקציה שמשתמשת ממשקי ה-API האלה וקלט מבוסס-TIF של צד שלישי ניתן להתקין את השירות ולהשתמש בו במכשיר.
3.13. הגדרות מהירות
ב-Android יש רכיב בממשק המשתמש של ההגדרות המהירות שמאפשר גישה מהירה אל פעולות נפוצות או פעולות דחופות.
אם ההטמעות במכשירים כוללות רכיב בממשק המשתמש של ההגדרות המהירות ותומכות בצדדים שלישיים בהגדרות המהירות:
- [C-1-1] חובה לאפשר למשתמש להוסיף או להסיר את כרטיסי המידע
quicksettings
ממשקי API מאפליקציה של צד שלישי. - [C-1-2] אסור להוסיף כרטיס מידע באופן אוטומטי מאפליקציה של צד שלישי אל ההגדרות המהירות.
- [C-1-3] חובה להציג את כל המשבצות שנוספו על ידי המשתמשים מאפליקציות של צד שלישי לצד משבצות ההגדרה המהירות שסופקו על ידי המערכת.
3.14. ממשק משתמש של מדיה
אם יישומים של מכשירים כוללים אפליקציות שלא מופעלות באמצעות קול (האפליקציות) שמקיימות אינטראקציה עם
אפליקציות צד שלישי דרך MediaBrowser
או MediaSession
,
האפליקציות:
[C-1-2] חובה להציג בבירור סמלים שהתקבלו באמצעות
getIconBitmap()
אוgetIconUri()
וכותרות שהתקבלו דרךgetTitle()
כפי שמתואר ב-MediaDescription
. יכול להיות שהשם יהיה קצר יותר, כדי לעמוד בתקנות הבטיחות (למשל, הסחות דעת של הנהג).[C-1-3] חובה להציג את סמל האפליקציה של צד שלישי בכל פעם שיוצג תוכן שסופק על ידי באפליקציה הזו של צד שלישי.
[C-1-4] חייבת לאפשר למשתמש לבצע אינטראקציה עם כל התוכן של
MediaBrowser
ההיררכיה. יכול להיות להגביל את הגישה לחלק מההיררכיה כדי לעמוד בתקנות הבטיחות (למשל, הסחות דעת של הנהג), אבל אסור לתת יחס מועדף על סמך תוכן או ספק תוכן.[C-1-5] חייבים לשקול הקשה כפולה של
KEYCODE_HEADSETHOOK
אוKEYCODE_MEDIA_PLAY_PAUSE
בתורKEYCODE_MEDIA_NEXT
עבורMediaSession.Callback#onMediaButtonEvent
.
3.15. אפליקציות ללא התקנה
אם הטמעות במכשירים תומכים באפליקציות ללא התקנה, הן חייבות לעמוד בדרישות הבאות דרישות:
- [C-1-1] אפליקציות ללא התקנה חייבות לקבל רק הרשאות
android:protectionLevel
מוגדר ל-"instant"
. - [C-1-2] אסור שאפליקציות ללא התקנה יקיימו אינטראקציה עם אפליקציות מותקנות באמצעות כוונות מרומזות
אלא אם מתקיים אחד מהתנאים הבאים:
- מסנן דפוס Intent של הרכיב נחשף, ויש לו CATEGORY_BROWSABLE
- הפעולה היא אחת מהאפשרויות: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
- היעד חשוף באופן מפורש באמצעות android:visibleToInstantApps
- [C-1-3] אסור שאפליקציות ללא התקנה יקיימו אינטראקציה מפורשת עם אפליקציות מותקנות, אלא אם הרכיב נחשף דרך android:visibleToInstantApps.
- [C-1-4] אפליקציות מותקנות לא יכולות לראות פרטים על אפליקציות ללא התקנה המכשיר, אלא אם האפליקציה ללא התקנה מתחברת באופן מפורש המותקנת.
הטמעת מכשירים חייבת לספק למשתמשים את העלויות הבאות: אינטראקציה עם אפליקציות ללא התקנה. ה-AOSP עומד בדרישות הבאות ברירת המחדל של ממשק המשתמש, ההגדרות, ומרכז האפליקציות. הטמעות מכשירים:
- [C-1-5] חובה לספק למשתמש תקציב להצגה ומחיקה של אפליקציות ללא התקנה במטמון באופן מקומי לכל חבילת אפליקציה בנפרד.
- [C-1-6] חייבת לספק התראה קבועה למשתמש, שניתן
מכווץ בזמן שאפליקציה ללא התקנה פועלת בחזית. המשתמש הזה
ההתראה חייבת לכלול שאין צורך בהתקנה של אפליקציות ללא התקנה
ולספק למשתמש מחיר מסוים שמפנה את המשתמש לאפליקציה
במסך המידע בהגדרות. לגבי אפליקציות ללא התקנה שהופעלו באמצעות כוונות אינטרנט, למשל
מוגדר באמצעות שימוש ב-Intent עם פעולה שהוגדרה ל-
Intent.ACTION_VIEW
וגם עם סכמה של "http" או "https", עלות נוספת למשתמש אמורה לאפשר למשתמש לא להפעיל את האפליקציה ללא התקנה, להפעיל את הקישור המשויך לדפדפן האינטרנט שהוגדר, אם דפדפן זמינה במכשיר. - [C-1-7] חובה לאפשר גישה לאפליקציות ללא התקנה שפועלות בקטע 'אחרונים' אם הפונקציה 'אחרונים' זמינה במכשיר.
[C-1-8] חובה לטעון מראש אפליקציה או רכיב שירות אחד או יותר עם Intent שמתייחס לאובייקטים של Intent שמפורטים ב-SDK כאן. והפיכת הכוונות לגלויות לאפליקציות ללא התקנה.
3.16. התאמת מכשיר נלווה
מערכת Android כוללת תמיכה בהתאמת מכשירים נלווים כדי לנהל ביעילות רבה יותר
משויך למכשירים נלווים, ומספק את ה-CompanionDeviceManager
ממשק API לאפליקציות כדי לגשת לתכונה הזו.
אם הטמעות המכשירים תומכות בתכונה 'התאמת מכשירים נלווית', הן:
- [C-1-1] חובה להצהיר על דגל התכונה
FEATURE_COMPANION_DEVICE_SETUP
הקצר הזה. התשובות שלך יעזרו לנו להשתפר. - [C-1-2] חייבים לוודא שממשקי ה-API נמצאים ב
android.companion
החבילה מוטמעת במלואה. - [C-1-3] חובה לאפשר למשתמשים לבחור או לאשר מודעה נלווית שהמכשיר קיים ופעיל.
3.17. אפליקציות כבדות
אם בהטמעות במכשירים מוצהר על התכונה FEATURE_CANT_SAVE_STATE
,
ואז:
- [C-1-1] חייבת להיות רק אפליקציה מותקנת אחת שמציינת
cantSaveState
שפועלים במערכת בכל פעם. אם המשתמש יוצא מאפליקציה כזו בלי לצאת ממנה במפורש (לדוגמה, על ידי לחיצה על בבית בזמן שהמערכת משאירה פעילות פעילה, במקום ללחוץ על 'חזרה' ללא פעילויות פעילות נוספות במערכת), לאחר מכן יישומים של מכשירים חייבים לתת עדיפות לאפליקציה הזו ב-RAM כפי שהיא מופיעה במכשירים אחרים דברים שצפויים להמשיך לפעול, כמו שירותים שפועלים בחזית. גם כשאפליקציה כזו פועלת ברקע, המערכת עדיין יכולה להפעיל חשמל בתכונות הניהול שלו, כמו הגבלת הגישה למעבד (CPU) ולרשת. - [C-1-2] חובה לספק ממשק משתמש נוח לבחירה באפליקציה שלא
להשתמש במנגנון שמירה/שחזור במצב הרגיל ברגע שהמשתמש
מפעילה אפליקציה שנייה שהוצהרה באמצעות
cantSaveState
. - [C-1-3] אסור להחיל שינויים אחרים במדיניות על אפליקציות שמציינות
cantSaveState
למשל, שינוי ביצועי המעבד (CPU) או שינוי העדיפות של התזמון.
אם יישומי מכשירים לא כוללים הצהרה על התכונה
FEATURE_CANT_SAVE_STATE
ואז:
- [C-1-1] חובה להתעלם מה
cantSaveState
שהוגדר על ידי האפליקציות, ואסור לשנות את התנהגות האפליקציה בהתאם .
3.18. אנשי קשר
Android כולל Contacts
Provider
ממשקי API שמאפשרים לאפליקציות לנהל פרטים של אנשי קשר השמורים במכשיר.
נתוני אנשי קשר שמוזנים ישירות למכשיר מסונכרנים בדרך כלל
עם שירות אינטרנט, אבל ייתכן שהנתונים מאוחסנים גם באופן מקומי בלבד במכשיר.
אנשי קשר ששמורים רק במכשיר נקראים מקומיים
אנשי הקשר.
אנשי קשר גולמיים
'משויכים אל' או 'מאוחסנים ב-' ה
חשבון
כאשר
ACCOUNT_NAME
,
וגם
ACCOUNT_TYPE
,
של אנשי הקשר הגולמיים תואמות
Account.name
וגם
סוג החשבון
השדות של החשבון.
חשבון מקומי שמוגדר כברירת מחדל: חשבון של אנשי קשר גולמיים שמאוחסנים רק בו
של המכשיר ולא משויך לחשבון ב-AccountManager,
נוצר עם ערכי null עבור
ACCOUNT_NAME
,
וגם
ACCOUNT_TYPE
,
עמודות.
חשבון מקומי מותאם אישית: חשבון של אנשי קשר גולמיים שמאוחסנים רק
ולא משויכים לחשבון ב-AccountManager,
נוצר עם ערך אחד לפחות שאינו null עבור הפונקציה
ACCOUNT_NAME
,
וגם
ACCOUNT_TYPE
,
עמודות.
הטמעות מכשירים:
- [C-SR-1] מומלץ מאוד לא ליצור חשבונות מקומיים בהתאמה אישית.
אם בהטמעות במכשירים נעשה שימוש בחשבון מקומי מותאם אישית:
- [C-1-1]
ACCOUNT_NAME
של החשבון המקומי המותאם אישית חייב להיות מוחזר על ידיContactsContract.RawContacts.getLocalAccountName
- [C-1-2]
ACCOUNT_TYPE
של החשבון המקומי המותאם אישית חייב להיות מוחזר על ידיContactsContract.RawContacts.getLocalAccountType
- [C-1-3] אנשי קשר גולמיים שנוספו על ידי אפליקציות של צד שלישי עם
חשבון מקומי שמוגדר כברירת מחדל (כלומר, על ידי הגדרת ערכי null עבור
ACCOUNT_NAME
ו-ACCOUNT_TYPE
) חייבים להוסיף אל המקומים המותאמים אישית חשבון. - [C-1-4] אנשי קשר גולמיים שנוספו לחשבון המקומי המותאם אישית לא חייבים להיות מוסרים כשמוסיפים או מסירים חשבונות.
- [C-1-5] פעולות מחיקה שבוצעו בחשבון מקומי מותאם אישית
חייבים לגרום לכך שאנשי הקשר הגולמיים יימחקו באופן מיידי (כאילו
CALLER_IS_SYNCADAPTER
הפרמטר הוגדר כ-True, גם אם הפרמטרCALLER\_IS\_SYNCADAPTER
הוגדר ל-false או לא צוין.
4. תאימות לאריזת אפליקציות
הטמעות של מכשירים:
[C-0-1] חייבת להיות יכולת להתקין ולהפעיל קובצי .APK של Android בתור שנוצר על ידי הכלי aapt, הכלול 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 Intent והאפליקציה של מנהל האחסון מטפלים ב-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
אם בהטמעות במכשירים יש תמיכה בקידוד 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] גולמי
אם ההטמעות במכשירים תומכים בפענוח וידאו באמצעות 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) |
מקודדים ומפענחים של תמונות שנחשפים דרך 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 |
|
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) | 3840 x 2160 פיקסלים (HEVC, VP9) |
- [C-2-2] רכיבי קודק של וידאו שמאופיינים כהאצת חומרה חייבים
לפרסם מידע על נקודות ביצועים. כל אחת מהרשימות חייבת להיות נתמכת
נקודות ביצועים רגילות (מפורטות ב:
PerformancePoint
API), אלא אם הם כלולים בנקודת ביצועים רגילה אחרת שנתמכת. - בנוסף, הם היו צריכים לפרסם נקודות ביצועים מורחבות אם הם לתמוך בביצועי וידאו עקביים בהשוואה לביצועים הרגילים שצוינו.
5.2. קידוד וידאו
אם ההטמעות במכשירים תומכים במקודד וידאו כלשהו והופכים אותו לזמין לאפליקציות צד שלישי, הן:
- זה לא אמור להיות, על פני שני חלונות הזזה, מעל 15% על קצב העברת הנתונים בין מרווחים בתוך הפריים (I-frame).
- לא אמור להיות יותר מ-100% מקצב העברת הנתונים בחלון הזזה של שנייה אחת.
אם יישומי המכשיר כוללים תצוגת מסך מוטמע עם
אורך אלכסון של 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] חייבת לתמוך ברמה 45 בפרופיל הבסיס.
- המקודד הנתמך צריך לתמוך בקצבי העברת נתונים שאפשר להגדיר באופן דינמי.
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.
- אמורה לתמוך בפרופילי הקידוד באיכות 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 |
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 וברמה 45.
5.3.3. MPEG-4
בהטמעות במכשירים עם מפענחי MPEG-4:
- [C-1-1] חייבת לתמוך ב-Simple Profile Level 3.
5.3.4. H.264
אם בהטמעות במכשירים יש תמיכה במפענחי H.264:
- [C-1-1] חובה לתמוך בפרופיל הראשי ברמה 3.1 ובפרופיל Baseline. תמיכה עבור ASO (סידור פרוסות שרירותי), FMO (סידור גמיש של Macroblock) ו-RS (פרוסות מיותרות) הוא אופציונלי.
- [C-1-2] חייבת להיות אפשרות לפענח סרטונים באיכות SD (Standard Definition) הפרופילים שמפורטים בטבלה הבאה ומקודדים באמצעות פרופיל Baseline ו'פרופיל ראשי' רמת 3.1 (כולל 720p30).
- אמורה להיות אפשרות לפענח סרטונים בפרופילים באיכות HD כפי שמצוין בטבלה הבאה.
אם הגובה שמדווח על ידי השיטה Display.getSupportedModes()
הוא
שווה לרזולוציית הסרטון או גבוהה ממנה, הטמעות המכשירים:
- [C-2-1] חייב לתמוך בפרופילים של פענוח וידאו באיכות HD 720p, טבלה.
- [C-2-2] חייבים לתמוך בפרופילים של פענוח וידאו באיכות HD 1080p טבלה.
SD (איכות נמוכה) | SD (איכות גבוהה) | HD 720p | HD 1080p | |
---|---|---|---|---|
רזולוציית וידאו | 240 x 320 פיקסלים | 720 x 480 פיקסלים | 720 x 1280 פיקסלים | 1920 x 1080 פיקסלים |
קצב הפריימים של הסרטון | 30 fps | 30 fps | 60 fps | 30 FPS (60fpsטלוויזיה) |
קצב העברת נתונים של וידאו | 800 Kbps | 2 Mbps | 8Mbps | 20 Mbps |
5.3.5. H.265 (HEVC)
אם בהטמעות במכשירים יש תמיכה בקודק H.265:
- [C-1-1] חייבת לתמוך ברמה הראשית של הרמה 3 בפרופיל הראשי ובסרטון SD של פרופילים לפענוח כפי שמצוין בטבלה הבאה.
- הנתונים אמורים לתמוך בפרופילים של פענוח HD, כפי שמתואר בטבלה הבאה.
- [C-1-2] חייבת לתמוך בפרופילים של פענוח HD, כפי שמצוין בהמשך אם יש מפענח חומרה.
אם הגובה שמדווח על ידי השיטה Display.getSupportedModes()
הוא
שווה לרזולוציית הסרטון או גדולה ממנה, ואז:
- [C-2-1] הטמעות של מכשירים חייבות לתמוך לפחות בתקן H.265 או VP9 של פרופילים ב-720, 1080 ו-UHD.
SD (איכות נמוכה) | SD (איכות גבוהה) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
רזולוציית וידאו | 352 x 288 פיקסלים | 720 x 480 פיקסלים | 720 x 1280 פיקסלים | 1920 x 1080 פיקסלים | 3840 x 2160 פיקסלים |
קצב הפריימים של הסרטון | 30 fps | 30 fps | 30 fps | 30/60fps (60fpsטלוויזיה עם פענוח באמצעות חומרת H.265) | 60 fps |
קצב העברת נתונים של וידאו | 600 Kbps | 1.6 Mbps | 4Mbps | 5 Mbps | 20 Mbps |
אם המכשיר מיישם הצהרה על תמיכה בפרופיל HDR באמצעות המדיה ממשקי API:
- [C-3-1] הטמעות מכשירים חייבות לקבל את המטא-נתונים הנדרשים של HDR מ- של האפליקציה, וגם תמיכה בחילוץ ובפלט של ה-HDR הנדרש מטא-נתונים מה-bitstream ו/או מהקונטיינר.
- [C-3-2] הטמעות מכשירים חייבות להציג תוכן HDR באופן תקין במסך המכשיר או ביציאת וידאו רגילה (למשל, HDMI).
5.3.6. VP8
אם הטמעות במכשירים תומכים בקודק VP8:
- [C-1-1] חייבת לתמוך בפרופילים של פענוח SD שבטבלה הבאה.
- עליהם להשתמש בקודק חומרה VP8 שעונה על הדרישות.
- הפרופילים אמורים לתמוך בפרופילים של פענוח HD בטבלה הבאה.
אם הגובה כפי שדווח על ידי השיטה Display.getSupportedModes()
שווה
או גדול מרזולוציית הסרטון, אז:
- [C-2-1] הטמעות מכשירים חייבות לתמוך בפרופילים של 720p מהטבלה הבאה.
- [C-2-2] הטמעות מכשירים חייבות לתמוך בפרופילים של 1080p מהטבלה הבאה.
SD (איכות נמוכה) | SD (איכות גבוהה) | HD 720p | HD 1080p | |
---|---|---|---|---|
רזולוציית וידאו | 180 x 320 פיקסלים | 640 x 360 פיקסלים | 720 x 1280 פיקסלים | 1920 x 1080 פיקסלים |
קצב הפריימים של הסרטון | 30 fps | 30 fps | 30 FPS (60fpsטלוויזיה) | 30 (60 fpsטלוויזיה) |
קצב העברת נתונים של וידאו | 800 Kbps | 2 Mbps | 8Mbps | 20 Mbps |
5.3.7. VP9
אם בהטמעות במכשירים יש תמיכה בקודק VP9:
- [C-1-1] חייב לתמוך בפרופילים של פענוח וידאו באיכות SD, כמו שמתואר כאן מהטבלה הבאה.
- הנתונים אמורים לתמוך בפרופילים של פענוח HD, כפי שמתואר בטבלה הבאה.
אם בהטמעות המכשיר תומכים בקודק VP9 ובמפענח חומרה:
- [C-2-1] חייבת לתמוך בפרופילים של פענוח HD, כפי שמצוין בהמשך טבלה.
אם הגובה שמדווח על ידי השיטה Display.getSupportedModes()
הוא
שווה לרזולוציית הסרטון או גדולה ממנה, ואז:
- [C-3-1] הטמעות של מכשירים חייבות לתמוך לפחות בתקן VP9 או H.265 של פרופילים במידות 720, 1080 ו-UHD.
SD (איכות נמוכה) | SD (איכות גבוהה) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
רזולוציית וידאו | 180 x 320 פיקסלים | 640 x 360 פיקסלים | 720 x 1280 פיקסלים | 1920 x 1080 פיקסלים | 3840 x 2160 פיקסלים |
קצב הפריימים של הסרטון | 30 fps | 30 fps | 30 fps | 30FPS (60fpsטלוויזיה עם פענוח חומרה מסוג VP9) | 60 fps |
קצב העברת נתונים של וידאו | 600 Kbps | 1.6 Mbps | 4Mbps | 5 Mbps | 20 Mbps |
אם בהטמעות של מכשירים יש תמיכה ב-VP9Profile2
או ב-VP9Profile3
דרך 'CodecProfileLevel'
ממשקי API למדיה:
- תמיכה בפורמט 12 ביט היא אופציונלית.
אם בהטמעות של המכשיר נטען שהוא תומך בפרופיל HDR (VP9Profile2HDR
,
VP9Profile2HDR10Plus
, VP9Profile3HDR
, VP9Profile3HDR10Plus
) דרך
ממשקי API למדיה:
- [C-4-1] הטמעות מכשירים חייבות לקבל את המטא-נתונים הנדרשים של HDR
(
KEY_HDR_STATIC_INFO
) עבור כל הפרופילים של HDR, וגם 'KEY_HDR10_PLUS_INFO' לפרופילים של HDR10Plus) מהאפליקציה. הם גם חייבים לתמוך בחילוץ ובפלט של המטא-נתונים הנדרשים של HDR מה-bitstream ו/או מהקונטיינר. - [C-4-2] הטמעות מכשירים חייבות להציג תוכן HDR באופן תקין במסך המכשיר או ביציאת וידאו רגילה (למשל, HDMI).
5.3.8. Dolby Vision
אם בהטמעות המכשיר מוצהר על תמיכה במפענח Dolby Vision דרך
HDR_TYPE_DOLBY_VISION
, הם:
- [C-1-1] חובה לספק כלי חילוץ עם תמיכה ב-Dolby Vision.
- [C-1-2] התוכן של Dolby Vision חייב להופיע בצורה תקינה במסך המכשיר או ביציאת וידאו רגילה (למשל, HDMI).
- [C-1-3] חובה להגדיר את מזהה הטראק של שכבות הבסיס שתואמות לאחור (אם קיימות) כך שיהיו זהות שילבנו את מזהה המסלול של שכבת Dolby Vision.
5.3.9. AV1
אם בהטמעות במכשירים יש תמיכה בקודק AV1:
- [C-1-1] חייבת לתמוך בפרופיל 0, כולל תוכן של 10 ביט.
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.4.6. רמות ההוספה של המיקרופון [הועבר ל-5.4.2]
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
. - צריכה לתמוך ב-
EFFECT_TYPE_BASS_BOOST
,EFFECT_TYPE_ENV_REVERB
, הטמעותEFFECT_TYPE_PRESET_REVERB
ו-EFFECT_TYPE_VIRTUALIZER
שניתן לשלוט בו דרך מחלקות המשנהAudioEffect
BassBoost
,EnvironmentalReverb
,PresetReverb
,Virtualizer
. - [C-SR-1] מומלץ מאוד להוסיף תמיכה באפקטים בנקודה צפה (floating-point) מרובה-ערוצים.
5.5.3. עוצמת הקול של פלט האודיו
הטמעות של מכשירים בכלי רכב:
- אמורה לאפשר שינוי של עוצמת הקול של האודיו
בנפרד לכל שידור אודיו, באמצעות סוג התוכן או השימוש כפי שהוגדרו
של
AudioAttributes
ושימוש באודיו ברכב כפי שהוגדר באופן ציבורי בandroid.car.CarAudioManager
.
5.5.4. הורדת אודיו
אם בהטמעות במכשירים יש תמיכה בהפעלה של הפחתת אודיו, הן:
- [C-SR-1] מומלץ מאוד לחתוך את תוכן האודיו שהופעל ללא פערים בין שני קליפים באותו פורמט כשמציינים אותם API ללא פערים של AudioTrack ואת מאגר המדיה של MediaPlayer.
5.6. זמן אחזור של אודיו
זמן האחזור של האודיו הוא הזמן שחולף עד שאות אודיו עובר במערכת. סוגים רבים של אפליקציות מסתמכים על זמני אחזור קצרים כדי להשיג נתונים בזמן אמת אפקטים קוליים.
למטרות הסעיף הזה, צריך להשתמש בהגדרות הבאות:
- זמן אחזור של פלט מרווח הזמן בין המועד שבו האפליקציה כותבת מסגרת של נתונים מקודדים לפי PCM וכשהצליל התואם מוצג במתמר במכשיר או שהאות יוצא מהמכשיר דרך שאפשר לצפות בהם באופן חיצוני.
- זמן אחזור של פלט קר הזמן שחולף בין ההפעלה של זרם הפלט לבין זמן ההצגה של הפריים הראשון על סמך חותמות זמן, כשפלט האודיו המערכת לא הייתה פעילה והושבתה לפני הבקשה.
- זמן אחזור רציף של הפלט את זמן האחזור של הפלט במסגרות הבאות, לאחר שהמכשיר משמיע אודיו.
- זמן אחזור של קלט. המרווח בין הזמן שבו צליל מוצג של סביבה למכשיר במתמר במכשיר או אות שנכנס למכשיר דרך יציאה וכשהאפליקציה קוראת את המסגרת המתאימה של נתונים מקודדים לפי PCM.
- קלט שאבד. החלק הראשוני של אות קלט שלא ניתן לשימוש, או לא זמין.
- זמן אחזור של קלט קר משך הזמן שחולף בין התחלת השידור לבין המועד שבו מתקבלת פריים תקין ראשון, כשמערכת קלט האודיו לא פעילה הושבת לפני הבקשה.
- זמן אחזור של קלט רציף. את זמן האחזור של הקלט למסגרות הבאות, כשהמכשיר מקליט אודיו.
- זמן אחזור רציף הלוך ושוב. הסכום של זמן אחזור של קלט רציף ועוד זמן אחזור רציף של הפלט, בתוספת תקופת מאגר נתונים זמני אחת. התקופה של מאגר הנתונים הזמני מאפשרת הזמן שחולף עד שהאפליקציה תעבד את האות והזמן שבו האפליקציה תקצר את השלב ההבדל בין זרמי קלט לזרם פלט.
- OpenSL ES PCM bufferQueue API. קבוצת פריטים שקשורים ל-PCM OpenSL ES ממשקי API ב-Android NDK.
- AAudio Native Audio API. הקבוצה של ממשקי API של AAudio בתוך Android NDK.
- חותמת זמן. צמד שמכיל מיקום של מסגרת יחסי בתוך ואת הזמן המשוער שבו המסגרת נכנסת או יוצאת צינור עיבוד אודיו לעיבוד אודיו בנקודת הקצה המשויכת. עוד באותו הקשר AudioTimestamp.
- תקלה. הפרעה זמנית או ערך דגימה שגוי באות האודיו, נגרמה בדרך כלל על ידי פונקציית חוצץ תחתון לפלט, חריגה ממאגר הנתונים הזמני עבור קלט או כל מקור אחר של רעש דיגיטלי או אנלוגי.
- פירוש סטייה מוחלטת. הממוצע של הערך המוחלט של סטיות מהממוצע של קבוצת ערכים.
- זמן אחזור של נגיעה בנגיעה. משך הזמן בין הקשה על המסך לבין הזמן שבו צליל שנוצר כתוצאה מאותה הקשה שנשמעת ברמקול.
אם בהטמעות במכשירים מוצהר על android.hardware.audio.output
, הן
חייבים לעמוד בדרישות הבאות או לעבור אותן:
- [C-1-1] חותמת הזמן של הפלט שהוחזרה על ידי
AudioTrack.getTimestamp
ו-
AAudioStream_getTimestamp
מדויק ל- +/- 2 אלפיות השנייה. [C-1-2] זמן אחזור של פלט קר של 500 אלפיות השנייה או פחות.
[C-1-3] פתיחת זרם פלט באמצעות
AAudioStreamBuilder_openStream()
חייבים התהליך נמשך פחות מ-1,000 אלפיות השנייה.
אם בהטמעות המכשירים מוצהר על android.hardware.audio.output
הם
מומלץ מאוד לעמוד בדרישות הבאות או לעבור אותן:
- [C-SR-1] זמן אחזור של פלט קר של 100 אלפיות השנייה או פחות בנתוני הרמקול נתיב.
[C-SR-2] זמן אחזור של 80 אלפיות שנייה או פחות מהקשה לטון.
[C-SR-4] חותמת הזמן של הפלט שהוחזרה על ידי AudioTrack.getTimestamp ו-
AAudioStream_getTimestamp
מדויק ל- +/- 1 אלפיות השנייה.
אם יישומים של מכשירים עומדים בדרישות שלמעלה, לאחר כיול, בעת שימוש ב-AAudionative audio API, לפלט רציף זמן אחזור וזמן אחזור של פלט במצב התחלתי (cold start) בלפחות קטע אודיו אחד נתמך של המכשיר להצגת מידע, הם:
- [C-SR-5] מומלץ מאוד לדווח על אודיו עם זמן אחזור קצר
סימון תכונה
android.hardware.audio.low_latency
. - [C-SR-6] מומלץ מאוד לעמוד בדרישות לגבי זמן אחזור קצר אודיו דרך AAudio API.
- [C-SR-7] מומלץ מאוד לוודא שבשידורים שחוזרים
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
החל מ-AAudioStream_getPerformanceMode()
, הערך המוחזר על ידיAAudioStream_getFramesPerBurst()
קטן מהערך שהוחזר על ידיandroid.media.AudioManager.getProperty(String)
או שווה לו למפתח הנכסAudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER
.
אם ההטמעות של המכשיר לא עומדות בדרישות של אודיו עם זמן אחזור קצר באמצעות ממשק ה-API של אודיו מקורי של AAudio, הן:
- [C-2-1] אסור לדווח על תמיכה באודיו עם זמן אחזור קצר.
אם ההטמעות במכשירים כוללות את android.hardware.microphone
,
הקלט צריך לעמוד בדרישות הבאות לגבי אודיו:
[C-3-1] הגבלת השגיאה בחותמות הזמן של הקלט, כפי שהוחזר על ידי AudioRecord.getTimestamp או
AAudioStream_getTimestamp
, ל- +/- 2 ms. "שגיאה" כאן מתייחסת לסטייה מהערך הנכון.[C-3-2] זמן אחזור קר input של 500 אלפיות השנייה או פחות.
[C-3-3] פתיחת זרם קלט באמצעות
AAudioStreamBuilder_openStream()
חייבת התהליך נמשך פחות מ-1,000 אלפיות השנייה.
אם ההטמעות במכשירים כוללות את android.hardware.microphone
,
מומלץ מאוד לעמוד בדרישות הבאות של קלט אודיו:
[C-SR-8] זמן אחזור של קלט קר של 100 אלפיות שנייה או פחות דרך המיקרופון בנתיב הנתונים.
[C-SR-11] הגבלת השגיאה בחותמות הזמן של הקלט, כפי שהוחזרה על ידי AudioRecord.getTimestamp או
AAudioStream_getTimestamp
, ל- +/- 1 ms.
אם בהטמעות המכשירים מוצהר על android.hardware.audio.output
וגם
android.hardware.microphone
, הן:
- [C-SR-12] מומלץ מאוד זמן אחזור ממוצע במהלך נסיעה רציפה של 50 אלפיות שנייה או פחות מ-5 מדידות, עם סטייה אבסולוטית ממוצעת פחות מ-10 אלפיות שנייה, לפחות בנתיב נתמך אחד.
5.7. פרוטוקולי רשת
יישומי מכשירים חייבים לתמוך פרוטוקולים של רשת מדיה להפעלת אודיו ווידאו כפי שצוין במסמכי התיעוד של Android SDK.
לכל פורמט קודק ופורמט קונטיינר שצריך להטמיע במכשיר תמיכה, הטמעת המכשיר:
[C-1-1] חייב לתמוך ב-Codec או בקונטיינר הזה ב-HTTP וב-HTTPS.
[C-1-2] חייבת לתמוך בפורמטים המתאימים של פלחי מדיה, כפי שמוצג טבלת הפורמטים של פלחי המדיה שלמטה, פרוטוקול טיוטה של HTTP בשידור חי, גרסה 7.
[C-1-3] חייבת לתמוך בפורמטים המתאימים של המטען הייעודי (payload) של RTSP, כפי שמוצג טבלת RTSP למטה. למקרים חריגים, מומלץ לעיין בהערות השוליים של הטבלה סעיף 5.1.
פורמטים של פלחי מדיה
פורמטים של פלחים | הפניות | נדרשת תמיכה בקודק |
---|---|---|
MPEG-2 Transport Stream | ISO 13818 |
קודק הווידאו:
ו-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
- [C-1-2] חייב להיות זמן אחזור רציף הלוך ושוב של האודיו, כפי שמוגדר ב- סעיף 5.6 זמן אחזור אודיו של 25 אלפיות השנייה לכל היותר בנתיב נתמך אחד.
- [C-1-3] חייבות לכלול יציאות USB שתומכות במצב מארח USB וב-USB מצב ציוד היקפי.
- [C-1-4] חובה לדווח על תמיכה בתכונה
android.software.midi
. - [C-1-5] חייב לעמוד בדרישות זמן האחזור ובדרישות האודיו ב-USB באמצעות
אודיו מותאם לאודיו
API ו-
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
. - [C-1-6] זמן האחזור של הפלט במצב התחלתי חייב להיות 200 אלפיות השנייה או פחות.
- [C-1-7] זמן האחזור של קלט קר חייב להיות 200 אלפיות השנייה או פחות.
- [C-1-8] זמן האחזור הממוצע של 'הקשה לטון' חייב להיות 80 אלפיות השנייה או פחות לפחות 5 מדידות לאורך נתיב הנתונים של הדובר למיקרופון.
- [C-SR-1] מומלץ מאוד לעמוד בזמני אחזור כפי שהוגדרו בסעיף זמן אחזור של אודיו 5.6, של 20 אלפיות השנייה או פחות, יותר מ-5 מדידות עם סטייה אבסולוטית ממוצעת של פחות מ-5 אלפיות שנייה מעל הנתיב בין הדובר למיקרופון.
- [C-SR-2] מומלץ מאוד לעמוד בדרישות של Pro Audio עבור זמן אחזור אודיו דו-כיווני רציף, זמן אחזור של קלט קר ופלט קר הדרישות לגבי זמן אחזור ואודיו ב-USB באמצעות ה-API של AAudio native audio מעל נתיב ה-MMAP.
[C-SR-3] מומלץ מאוד לספק רמה עקבית של מעבד (CPU) ביצועים כשהאודיו פעיל והעומס על המעבד (CPU) משתנה. צריך לבדוק את זה באמצעות האפליקציה SynthMark ל-Android. SynthMark משתמש בסינתיסייזר תוכנה שפועל על פריים מדומה של אודיו שמודדים את ביצועי המערכת. לצפייה מסמכי תיעוד של SynthMark כדי לקבל הסבר על נקודות ההשוואה. סימן SynthMark צריך להריץ את האפליקציה באמצעות בוחרים באפשרות 'בדיקה אוטומטית' ומקבלים את התוצאות הבאות:
- voicemark.90 >= 32 קולות
- durationmark.fixed.little <= 15 מילי-שניות
- durationmark.dynamic.little <= 50 מילי-שניות
אמור לצמצם את אי הדיוק של שעון האודיו וסחף ביחס לזמן הסטנדרטי.
צריך לצמצם את הסחף של שעון האודיו ביחס למעבד (CPU)
CLOCK_MONOTONIC
כששניהם פעילים.זה אמור לצמצם את זמן האחזור של האודיו במתמרים ששמורים במכשיר.
יש לצמצם את זמן האחזור של האודיו באודיו דיגיטלי בחיבור USB.
צריך לתעד את המדידות של זמן האחזור של האודיו בכל הנתיבים.
אמורה לצמצם את הרעידות בזמני הכניסה של הקריאה החוזרת להשלמת מאגר האודיו של האודיו, כי משפיעה על האחוז השימושי של רוחב הפס המלא במעבד (CPU) על ידי הקריאה החוזרת (callback).
השימוש הרגיל אמור לספק אפס תקלות אודיו בזמן האחזור המדווח.
אמורה לספק הפרש בין זמן האחזור בין הערוצים.
זמן האחזור הממוצע של MIDI אמור לצמצם את זמן האחזור בכל אמצעי התחבורה.
צריכה לצמצם את השונות של זמן האחזור של MIDI בעומס (רעידות) בכל ההעברות.
צריכה לספק חותמות זמן מדויקות לשימוש ב-MIDI בכל אמצעי התחבורה.
צריכה למזער את הרעש של אות האודיו במתמרים במכשיר, כולל מיד לאחר ההפעלה במצב התחלתי (cold start).
אמור להיות אפס הבדל בשעון האודיו בין צד הקלט לצדדים של הפלט נקודות הקצה התואמות, כששתיהן פעילות. דוגמאות לתאימות נקודות הקצה (endpoints) כוללות את המיקרופון והרמקול במכשיר או את הקלט של שקע האודיו ופלט.
צריכה לטפל בקריאות חוזרות (callback) של השלמת מאגר הנתונים הזמני של הקלט ופלט נקודות הקצה המקבילות באותו שרשור כששתיהן פעילות, ומזינים הקריאה החוזרת של הפלט מיד אחרי החזרה מהקריאה החוזרת של הקלט. או אם לא ניתן לטפל בקריאות החוזרות (callback) באותו שרשור, יש להזין את פלט קריאה חוזרת (callback) זמן קצר לאחר הזנת הקריאה החוזרת של הקלט כדי לאפשר כך שיהיה תזמון עקבי של צד הקלט והפלט.
אמור לצמצם את הפרש המופעים בין אגירת אודיו של HAL בקלט ואת צדי הפלט של נקודות הקצה התואמות.
צריכה למזער את זמן האחזור של המגע.
צריכה למזער את ההשתנות של זמן האחזור של המגע במקרה של עומס (רעידות).
אם ההטמעות של מכשירים עומדות בכל הדרישות שפורטו למעלה, הן:
- [C-SR-4] מומלץ מאוד לדווח על תמיכה בתכונה
android.hardware.audio.pro
דרךandroid.content.pm.PackageManager
בכיתה.
אם בהטמעות המכשיר יש שקע אודיו עם 4 מוליכים בגודל 3.5 מ"מ, הן:
- [C-2-1] חייבת להיות זמן אחזור ממוצע של אודיו הלוך ושוב ברציף, כפי שמוגדר ב- קטע 5.6 זמן אחזור אודיו, של 20 אלפיות שנייה או פחות, יותר מ-5 מדידות עם סטייה אבסולוטית ממוצעת של פחות מ-5 אלפיות השנייה הנתיב של שקע האודיו באמצעות מתאם אודיו בלופ.
- [C-SR-5] מומלץ מאוד לציית לציות קטע בנושא מפרטי מכשיר נייד (שקע) של מפרט אוזניות אודיו חוטיות (גרסה 1.1).
אם בהטמעות המכשיר משמיטים שקע אודיו של 4 מוליך בגודל 3.5 מ"מ וגם כוללות יציאות USB שתומכות במצב מארח USB, והן:
- [C-3-1] חובה להטמיע את סיווג האודיו ב-USB.
- [C-3-2] זמן האחזור הממוצע של אודיו הלוך ושוב ברציפות הוא רציף 25 אלפיות השנייה או פחות, יותר מ-5 מדידות עם סטייה אבסולוטית ממוצעת פחות מ-5 אלפיות השנייה מהיציאה של מצב מארח ב-USB באמצעות סיווג אודיו ב-USB. (ניתן למדוד זאת באמצעות מתאם USB-3.5 מ"מ ורמקול עם לולאה חוזרת (loopback) מתאם או שימוש בממשק אודיו ב-USB עם כבלי תיקון שמחברים את של הקלט לפלט).
- [C-SR-6] מומלץ מאוד לתמוך בקלט/פלט (I/O) בו-זמנית בעד 8 ערוצים כל כיוון, תדירות דגימה של 96kHz ועומק של 24 ביט או 32 ביט עם ציוד היקפי בחיבור USB שתומך גם בדרישות האלה.
- [C-SR-7] מומלץ מאוד לעמוד בקבוצת הדרישות הזו בעזרת ממשק ה-API של אודיו מקורי של אודיו דרך נתיב ה-MMAP.
אם בהטמעות במכשירים יש יציאת HDMI:
- אמורה לתמוך בפלט בסטריאו ובשמונה ערוצים במהירות של 20 סיביות עומק של 24 ביט ו-192kHz ללא אובדן או דגימה מחדש של עומק הסיביות בהגדרה אחת לפחות.
5.11. צילום למכשירים לא מעובדים
Android כולל תמיכה בהקלטת אודיו לא מעובד באמצעות
מקור האודיו android.media.MediaRecorder.AudioSource.UNPROCESSED
. לחשבון
OpenSL ES, ניתן לגשת אליה באמצעות ההגדרה הקבועה מראש של הרשומה
SL_ANDROID_RECORDING_PRESET_UNPROCESSED
אם המכשיר מיישם הכוונה לתמוך במקור אודיו לא מעובד ולהבטיח לאפליקציות צד שלישי, הן:
[C-1-1] חובה לדווח על התמיכה דרך
android.media.AudioManager
נכס PROPERTY_SUPPORT_AUDIO_SOURCE_UNProcessED.[C-1-2] חובה להציג תדירות של משרעת (אמפליטודה) שטוחה (לעומת זאת) בערך מאפיינים בטווח התדרים הבינוני: במיוחד ±10 dB החל 100 Hz עד 7,000 Hz לכל מיקרופון שמשמש להקלטת מקור האודיו.
[C-1-3] חובה להציג את רמות המשרעת בתדר הנמוך טווח: במיוחד בין ±20dB מ-5 z עד 100 Hz בהשוואה טווח התדרים עבור כל מיקרופון שמשמש להקלטת מקור אודיו שלא עבר עיבוד.
[C-1-4] חייבים להציג את רמות המשרעת בתדירות גבוהה טווח: במיוחד בין ±30dB מ-7,000 Hz עד 22 KHz, בהשוואה טווח התדרים עבור כל מיקרופון שמשמש להקלטת מקור אודיו שלא עבר עיבוד.
[C-1-5] חובה להגדיר את הרגישות לקלט האודיו, כך מקור הצליל שמושמע בעוצמה של 94 דציבלים ברמת לחץ הקול (SPL) מניב תגובה עם RMS של 520 לדגימות של 16 ביט (או -36 dB התאמה מלאה לנקודה צפה/כפולה לספק דגימות דיוק) לכל מיקרופון שמשמש להקלטת מקור האודיו.
[C-1-6] חייב להיות יחס אות לרעש (SNR) ב-60 דציבלים ומעלה עבור כל מיקרופון שמשמש להקלטת מקור האודיו הלא מעובד. (בעוד ש-SNR נמדדת כהפרש בין 94 dB SPL לבין המקבילה SPL של רעש עצמי, שקלול A).
[C-1-7] הערך של עיוות הרמוני (THD) חייב להיות קטן מ- 1% עבור 1 kHZ ברמת קלט של 90 dB SPL בכל מיקרופון שנעשה בו שימוש להקליט את מקור האודיו הלא מעובד.
[C-1-8] אסור שיהיה עיבוד אותות אחר (למשל, רווח אוטומטי שליטה, מסנן High Pass או ביטול הד) בנתיב שאינו ברמה הרצויה כדי להעלות את הרמה לטווח הרצוי. במילים אחרות:
- [C-1-9] אם קיים בארכיטקטורה עיבוד אותות כלשהו מסיבה זו, חייבים להשבית אותו ולהציג באופן אפקטיבי אפס עיכוב זמן אחזור נוסף לנתיב האות.
- [C-1-10] מכפיל הרמות, אף על פי שהוא מותר בנתיב, אסור הוספת עיכוב או זמן אחזור בנתיב האות.
כל מדידות ה-SPL מתבצעות ישירות ליד המיקרופון בבדיקה. הדרישות האלה חלות על כמה הגדרות מיקרופון בכל מיקרופון.
אם בהטמעות המכשיר מוצהר על android.hardware.microphone
אבל לא
תומכים במקור אודיו לא מעובד, הם:
- [C-2-1] חייב להחזיר
null
לAudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)
API, כדי לציין כראוי את היעדר התמיכה. - [C-SR-1] עדיין מומלץ מאוד למלא כמה שיותר מהדרישות לנתיב האות של מקור ההקלטה שלא עבר עיבוד.
5.12. סרטון HDR
ב-Android 13 יש תמיכה בטכנולוגיות HDR, כפי שמתואר במסמך שיפורסם בקרוב.
פורמט הפיקסלים
אם מפענח וידאו מפרסם תמיכה ב-color_FormatYUVP010:
[C-1-1] חייבת לתמוך בפורמט P010 לקריאת מעבד (CPU) (ImageReader, MediaImage, ). ב-Android 13, P010 פועל בצורה רגועה כדי לאפשר צעדים שרירותיים עבור ה-Y ומתקני קרינת UV.
[C-1-2] חובה לאפשר ל-GPU לדגום את מאגר הפלט של P010 (כאשר שהוקצה עם שימוש ב-GPU_SAMPLING). כך מתאפשרת הרכבה של GPU והתאמה אישית למיפוי טונים של אפליקציות.
אם מפענח וידאו מפרסם תמיכה ב-COLOR_Format32bitABGR2101010, הוא:
- [C-2-1] חייבת לתמוך בפורמט RGBA_1010102 לשטח הפלט קריא למעבד (CPU) (פלט ByteBuffer).
אם מקודד וידאו מפרסם תמיכה ב-COLOR_FormatYUVP010, הוא:
- [C-3-1] חייבת להיות תמיכה בפורמט P010 למשטח קלט ולניתנת לכתיבה באמצעות מעבד (CPU) קלט (ImageWriter, MediaImage, ByteBuffer).
אם מקודד וידאו מפרסם תמיכה ב-COLOR_Format32bitABGR2101010, הוא:
- [C-4-1] חייב לתמוך בפורמט RGBA_1010102 עבור משטח קלט ומעבד (CPU) שניתן לכתיבה קלט (ImageWriter, ByteBuffer). הערה: המרה בין סוגים שונים של העברות במקודדים אין צורך בעקומות.
דרישות לצילום HDR
בכל מקודדי הווידאו שתומכים בפרופילים של HDR:
[C-5-1] אסור להניח שהמטא-נתונים של HDR מדויקים. לדוגמה, במסגרת המקודדת יכולים להיות פיקסלים מעבר לרמת ההארה המקסימלית, או ייתכן שההיסטוגרמה לא מייצגת את המסגרת.
צריך לצבור מטא-נתונים דינמיים של HDR כדי ליצור נתונים סטטיים מתאימים של HDR מטא-נתונים עבור שידורים מקודדים, והפלט צריך להיות בסוף כל בהפעלת הקידוד.
אם בהטמעות של המכשיר יש תמיכה בצילום HDR באמצעות ממשקי ה-API של CamcorderProfile ואז:
[C-6-1] חייבת להיות תמיכה בצילום תמונות HDR גם דרך ממשקי ה-API של Camera2.
[C-6-2] חייב לתמוך לפחות במקודד וידאו אחד עם שיפור מהירות באמצעות חומרה עבור כל טכנולוגיית HDR שנתמכת.
[C-6-3] חייבת להיות תמיכה (לכל הפחות) בצילום בפורמט HLG.
[C-6-4] חייבת להיות תמיכה בכתיבת המטא-נתונים של HDR (אם רלוונטי ל-HDR) טכנולוגית) לקובץ הווידאו שתועד. ל-AV1, ל-HEVC ול-DolbyVision כלומר, כוללים את המטא-נתונים בסטרימינג הביטים המקודד.
[C-6-5] חייבת לתמוך ב-P010 וב-COLOR_FormatYUVP010.
[C-6-6] כברירת מחדל חייבת להיות תמיכה ב-HDR למיפוי גוונים של SDR למפענח עם שיפור מהירות באמצעות חומרה לפרופיל שתועד. במילים אחרות, אם מכשיר יכול לצלם HDR10+ HEVC, מפענח HEVC שמוגדר כברירת מחדל חייב להיות מסוגל כדי לפענח את השידור שתועד ב-SDR.
דרישות לעריכת HDR
אם ההטמעות במכשירים כוללים מקודדי וידאו שתומכים בעריכת HDR, הם:
- יש להשתמש בזמן אחזור מינימלי ליצירת מטא-נתונים של HDR כשהם לא נמצאים, והם צריכים לטפל באלגנטיות במצבים שבהם המטא-נתונים קיימים של מודלים אחרים ולא עבור אחרים. המטא-נתונים צריכים להיות מדויקים (לדוגמה, שמייצגים את רמת הבהירות וההיסטוגרמה בפועל של המסגרת).
אם הטמעת המכשיר כוללת רכיבי קודק שתומכים ב-FEATURE_HdrEditing, אז את רכיבי הקודק האלה:
[C-7-1] חייב לתמוך בפרופיל HDR אחד לפחות.
[C-7-2] חייבת להיות תמיכה ב-FEATURE_HdrEditing בכל פרופילי ה-HDR שמתפרסמים על ידי את הקודק הזה. במילים אחרות, הם חייבים לתמוך ביצירת מטא-נתונים של HDR לא קיים בכל פרופילי HDR הנתמכים שמשתמשים במטא-נתונים של HDR.
[C-7-3] חייב לתמוך בפורמטים הבאים של קלט מקודד וידאו, לשמר את האות המפוענח ל-HDR:
- RGBA_1010102 (כבר בעקומת העברת היעד) לשני הקלט ו-ByteBuffer ו-ByteBuffer חייבות לפרסם תמיכה עבור Color_Format32bitABGR2101010.
אם הטמעת המכשיר כוללת רכיבי קודק שתומכים ב-FEATURE_HdrEditing, אז המכשיר:
- [C-7-4] חובה לפרסם תמיכה לתוסף OpenGL מסוג EXT_YUV_target.
6. תאימות לכלים למפתחים ולאפשרויות
6.1. כלים למפתחים
הטמעות מכשירים:
- [C-0-1] חייבת לתמוך בכלים למפתחי Android שמסופקים ב-Android SDK.
גשר לניפוי באגים ב-Android (adb)
- [C-0-2] חייבת לתמוך ב-adb כפי שמתועד ב-Android SDK ובמעטפת
ב-AOSP, שיכולות לשמש מפתחי אפליקציות
כולל
dumpsys
cmd stats
- [C-0-11] חייבת לתמוך בפקודת המעטפת
cmd testharness
. מתבצע שדרוג במכשירים מגרסה קודמת של Android ללא ייתכן שחסימת נתונים מתמידים תהיה פטורה מקוד C-0-11. - [C-0-3] אסור לשנות את הפורמט או את התוכן של מערכת המכשיר אירועים (batterystats , דיסקסטטים, טביעת אצבע, גרפיקה סטטיסטיים, netstats, התראה, Procstats) שתועדה באמצעות הפקודה dumpsys.
- [C-0-10] חובה להקליט, ללא השמטת נתונים, ולבצע את האירועים הבאים
וזמין לפקודת המעטפת
cmd stats
StatsManager
מחלקה של System API.- הפעילות בחזית שונתה
- זוהתה חריגה
- נשלח דיווח על נתיבי ניווט ב-AppB
- AppCrashOccurred
- AppStartOccurred
- רמת הסוללה שונתה
- הסוללהSaverModeStateChanged
- BleScanresultReceived
- BleScanStateChanged
- ChargingStateChanged
- DeviceIdleModeStateChanged
- ForegroundServiceStateChanged
- GpsScanStateChanged
- JobStateChanged (שינוי מצב המשימה)
- PluggedStateChanged
- משימות מתוזמנות
- ScreenState השתנה
- SyncStateChanged
- זמן אמת ב-SystemElapse
- UidProcessStateChanged
- מצב WakelockState השתנה
- מעורר התעוררות
- מצב Wi-FiLockState השתנה
- WifiMulticastLockStateChange
- מצב WifiScanState השתנה
- [C-0-4] דימון (daemon) בצד המכשיר חייב להיות לא פעיל כברירת מחדל כדי להפעיל את ניפוי הבאגים ב-Android חייב להיות מנגנון נגיש למשתמש גשר.
- [C-0-5] חייבת לתמוך ב-adb מאובטח. Android כולל תמיכה באבטחה adb. פרוטוקול adb מאובטח מאפשר הפעלה של adb במארחים מאומתים מוכרים.
- [C-0-6] חייב לספק מנגנון שמאפשר לחבר את adb במחשב המארח. פרטים נוספים:
אם הטמעות של מכשירים ללא יציאת USB תומכות במצב היקפי:
- [C-3-1] חובה להטמיע adb באמצעות רשת מקומית (כמו אתרנט) או Wi-Fi).
- [C-3-2] חובה לספק מנהלי התקנים עבור Windows 7, Windows 8 ו-10, כדי לאפשר למפתחים להתחבר למכשיר באמצעות פרוטוקול adb.
אם בהטמעות של מכשירים יש תמיכה בחיבורי adb למכונה מארחת דרך ב-Wi-Fi או באתרנט, הן:
- [C-4-1] חייבת להשתמש בשיטה
AdbManager#isAdbWifiSupported()
החזרהtrue
.
אם בהטמעות של מכשירים יש תמיכה בחיבורי adb למכונה מארחת דרך Wi-Fi או אתרנט, וכן כולל מצלמה אחת לפחות, הם:
- [C-5-1] חייבת להשתמש בשיטה
AdbManager#isAdbWifiQrSupported()
החזרהtrue
.
- [C-0-2] חייבת לתמוך ב-adb כפי שמתועד ב-Android SDK ובמעטפת
ב-AOSP, שיכולות לשמש מפתחי אפליקציות
כולל
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, שבהם כל המוצרים של צדדים שלישיים תואמים ל-Android. אפליקציות יכולות לפעול, הטמעות מכשירים חייבות להטמיע את ממשקי ה-API האלה באופן תקין והתנהגויות, כפי שמפורט בקטע הזה.
היחידות שמוזכרות בדרישות בסעיף הזה מוגדרות כך:
- גודל אלכסון פיזי. המרחק באינצ'ים בין שני צבעים מנוגדים הפינות של החלק המואר של המסך.
- נקודות לאינץ' (dpi). מספר הפיקסלים המוקפים על ידי קו ליניארי לרוחב או אנכי באורך של 1 אינץ'. כשערכי DPI רשומים, גם פורמט אופקי וה-dpi האנכי חייבים להיות בטווח.
- יחס גובה-רוחב. היחס בין הפיקסלים של המימד הארוך יותר מידות קצרות יותר של המסך. לדוגמה, תצוגה של 480x854 פיקסלים להיות 854/480 = 1.779, או בערך 16:9.
- פיקסל בלתי תלוי בדחיסות (dp). יחידת הפיקסלים הווירטואליים מנורמלת מסך של 160 dpi, מחושב באופן הבא: פיקסלים = dps * (צפיפות/160).
7.1.1. הגדרת המסך
7.1.1.1. הגודל והצורה של המסך
ה-framework של ממשק המשתמש של Android תומך במגוון של פריסת מסך לוגית
גדולים, ומאפשר לאפליקציות לשלוח שאילתות על המסך של התצורה הנוכחית
גודל הפריסה דרך Configuration.screenLayout
עם SCREENLAYOUT_SIZE_MASK
ו-Configuration.smallestScreenWidthDp
.
הטמעות מכשירים:
[C-0-1] חובה לדווח על גודל הפריסה הנכון
Configuration.screenLayout
כפי שמוגדר במסמכי התיעוד של Android SDK. באופן ספציפי, הטמעות במכשירים חייבות לדווח על הלוגיקה הנכונה מידות המסך של פיקסלים שלא תלויים בדחיסות (dp) כפי שמפורט בהמשך:- מכשירים שבהם מוגדר
Configuration.uiMode
בתור כל ערך מלבד UI_מצב_TYPE_WATCH, ודיווח על גודלsmall
עבורConfiguration.screenLayout
, חייב להיות לפחות 426 dp x 320 dp. - מכשירים שמדווחים על גודל של
normal
עבורConfiguration.screenLayout
, חייבת להיות לפחות 480 dp x 320 dp. - מכשירים שמדווחים על גודל של
large
עבורConfiguration.screenLayout
, חייב להיות לפחות 640 dp x 480 dp. - מכשירים שמדווחים על גודל של
xlarge
עבורConfiguration.screenLayout
, חייב להיות לפחות 960 dp x 720 dp.
- מכשירים שבהם מוגדר
[C-0-2] חובה לציית בצורה נכונה לבקשות מוצהר תמיכה בגדלי מסכים באמצעות <
supports-screens
> בקובץ AndroidManifest.xml, כפי שמתואר בתיעוד של Android SDK.ב-MAY יש מסכים שתואמים ל-Android עם פינות מעוגלות.
אם הטמעות המכשיר תומכות ב-UI_MODE_TYPE_NORMAL
וכוללות
מסכים שתואמים ל-Android עם פינות מעוגלות:
[C-1-1] חובה לוודא שלפחות אחת מהדרישות הבאות עומד ב:
- הרדיוס של הפינות המעוגלות קטן מ-38dp או שווה לו.
- כאשר תיבה בגודל 15 על 15dp מעוגנת לכל פינה של מסך, לפחות פיקסל אחד מכל תיבה גלוי במסך.
צריכה לכלול את התקציב של המשתמש לעבור למצב תצוגה עם פינות מלבניות.
אם ההטמעות במכשירים כוללים מסכים שתואמים ל-Android מתקפל, או כולל ציר מתקפל בין כמה חלוניות תצוגה במסכים שזמינים לעיבוד אפליקציות צד שלישי:
- [C-2-1] חובה להטמיע את הגרסה היציבה והעדכנית ביותר של ב-extensions API או את הגרסה היציבה של sidecar API לשימוש בספרייה Window Manager Jetpack.
אם ההטמעות במכשירים כוללים מסכים שתואמים ל-Android מתקפל, או כולל ציר מתקפל בין מספר חלוניות תצוגה, שהציר או הקפל חוצה חלון אפליקציה במסך מלא, ואז:
- [C-3-1] חובה לדווח על המיקום, הגבולות והמצב של הציר או הקיפול או ממשקי API חיצוניים לאפליקציה.
לפרטים על הטמעה נכונה של ממשקי ה-API המשניים או של התוספים, קראו את המאמר למסמכי התיעוד הציבוריים של Window Manager Jetpack.
7.1.1.2. יחס גובה-רוחב של המסך
אין הגבלה על יחס הגובה-רוחב של המסך הפיזי
מסכים שתואמים ל-Android, יחס הגובה-רוחב של המסך הלוגי
שבו מתבצע עיבוד של אפליקציות צד שלישי, שהנגזרה שלהן עשויה להיות נגזרת מהגובה
ערכי הרוחב מדווחים באמצעות הפרמטר view.Display
ממשקי API והגדרות אישיות
ממשקי API חייבים לעמוד בדרישות הבאות:
[C-0-1] הטמעות במכשירים שבהם
Configuration.uiMode
מוגדר לערך הערך של יחס הגובה-רוחב שלUI_MODE_TYPE_NORMAL
חייב להיות קטן או שווה ל-1.86 (בערך 16:9), אלא אם האפליקציה עומדת באחד מהתנאים הבאים תנאים:- האפליקציה הצהירה שהיא תומכת ביחס גובה-רוחב של מסך גדול יותר
דרך
android.max_aspect
של מטא-נתונים. - האפליקציה מצהירה שניתן לשנות את גודלה דרך android:resizeableActivity .
- האפליקציה מטרגטת רמת API 24 ומעלה ולא מוצהרת עליה רמה
android:maxAspectRatio
דבר שיגביל את יחס הגובה-רוחב המותר.
- האפליקציה הצהירה שהיא תומכת ביחס גובה-רוחב של מסך גדול יותר
דרך
[C-0-3] הטמעות במכשירים שבהם
Configuration.uiMode
מוגדר בתור הערך של יחס הגובה-רוחב שלUI_MODE_TYPE_WATCH
חייב להיות 1.0 (1:1).
7.1.1.3. דחיסות מסך
מסגרת ממשק המשתמש של Android מגדירה קבוצה של דחיסות לוגיות סטנדרטיות כדי לסייע מפתחי אפליקציות מטרגטים משאבי אפליקציות.
[C-0-1] כברירת מחדל, הטמעות במכשירים חייבות לדווח רק על אחד צפיפות המסגרת של Android שרשומה ברשימה
DisplayMetrics
באמצעות ה-API שלDENSITY_DEVICE_STABLE
ואסור לשנות את הערך הזה בכל שלב. אבל המכשיר עשוי לדווח על דחיסות שרירותית שונה בהתאם לתצורת התצוגה. שינויים שהמשתמש ביצע (למשל, גודל התצוגה) שהוגדרו אחרי האות לאתחל.יישומים של מכשירים צריכים להגדיר את צפיפות המסגרת הסטנדרטית של Android שהוא הקרוב ביותר מבחינת מספר הצפיפות הפיזית של המסך, אלא אם צפיפות לוגית דוחפת את גודל המסך המדווח מתחת למינימום הנתמך. אם המיקום דחיסות המסגרת הרגילה של Android שהיא הקרובה ביותר מבחינה מספרית הצפיפות הפיזית מובילה לגודל המסך הקטן ביותר מהקטן ביותר גודל מסך תואם נתמך (ברוחב 320dp), יישומי מכשיר צריכים לדווח על צפיפות המסגרת הרגילה הבאה של Android.
אם יש אפשרות לשנות את גודל התצוגה של המכשיר:
- [C-1-1] אסור שגודל התצוגה יהיה גדול מפי 1.5 מהצפיפות המקורית ליצור ממד מסך מינימלי יעיל קטן מ-320dp (שווה ערך) למגדיר המשאבים sw320dp), המוקדם מביניהם.
- [C-1-2] אסור שגודל התצוגה יהיה קטן מפי 0.85 מהצפיפות המקורית.
- כדי להבטיח נוחות שימוש טובה וגודל עקבי של הגופנים, מומלץ
לספק את ההתאמה לעומס (scaling) של אפשרויות התצוגה המותאמת (תוך עמידה במגבלות)
שצוין למעלה)
- קטנה: 0.85x
- ברירת מחדל: 1x (קנה מידה של תצוגה מותאמת)
- גדול: פי 1.15
- גדול יותר: פי 1.3
- הגדול ביותר: 1.45x
7.1.2. מדדי פרסום ברשת המדיה
אם הטמעות המכשירים כוללות מסכים שתואמים ל-Android או פלט וידאו למסכי תצוגה שתואמים ל-Android, הם:
- [C-1-1] חובה לדווח על הערכים הנכונים בכל המסכים שתואמים ל-Android
שמוגדרים
android.util.DisplayMetrics
API.
אם ההטמעות במכשירים לא כוללות מסך מוטמע או פלט וידאו מוטמע, הם:
- [C-2-1] חובה לדווח על הערכים הנכונים במסך התואם ל-Android
כפי שמוגדר ב-API
android.util.DisplayMetrics
לברירת המחדלview.Display
של אמולציה.
7.1.3. כיוון מסך
הטמעות מכשירים:
- [C-0-1] חובה לדווח על כיווןי המסך הנתמכים
(
android.hardware.screen.portrait
ו/אוandroid.hardware.screen.landscape
) וחובה לדווח על אירוע נתמך אחד לפחות לכיוון מסוים. לדוגמה, מכשיר בכיוון קבוע לרוחב מסך, כמו טלוויזיה או מחשב נייד, לדיווח עלandroid.hardware.screen.landscape
. - [C-0-2] חובה לדווח על הערך הנכון של הערך הנוכחי של המכשיר
של הסרטון, בכל פעם שמתקבלת שאילתה דרך
android.content.res.Configuration.orientation
,android.view.Display.getOrientation()
או ממשקי API אחרים.
אם בהטמעות של מכשירים יש תמיכה בשני הכיוונים של המסך:
- [C-1-1] חייבת לתמוך בכיוון דינמי באמצעות אפליקציות במסך לאורך או לרוחב לכיוון מסוים. כלומר, המכשיר חייב להיענות לבקשה של האפליקציה לגבי מסך ספציפי לכיוון מסוים.
- [C-1-2] אסור לשנות את גודל המסך או את הצפיפות שמדווחים כשמשנים את הכיוון.
- ייתכן שברירת המחדל היא 'לאורך' או 'לרוחב'.
7.1.4. האצת גרפיקה דו-ממדית ותלת-ממדית
7.1.4.1 OpenGL ES
הטמעות מכשירים:
- [C-0-1] חייב לזהות בצורה נכונה את הגרסאות הנתמכות של OpenGL ES (1.1, 2.0,
3.0, 3.1, 3.2) באמצעות ממשקי ה-API המנוהלים (למשל באמצעות
GLES10.getString()
) וממשקי ה-API המקוריים. - [C-0-2] חייבת לכלול תמיכה בכל ממשקי ה-API המנוהלים המתאימים, וגם ממשקי API מקוריים לכל גרסת OpenGL ES שבה הן זיהו שתומכות.
אם הטמעות במכשירים כוללות פלט מסך או פלט וידאו:
- [C-1-1] חייבת לתמוך ב-OpenGL ES 1.1 ובגרסה 2.0, בצורה מובנית ומפורטת במסמכי התיעוד של Android SDK.
- [C-SR-1] מומלץ מאוד לתמוך ב-OpenGL ES 3.1.
- צריכה לתמוך ב-OpenGL ES 3.2.
בדיקות dEQP של OpenGL ES מחולקות למחיצות למספר רשימות של בדיקות, כל אחת עם
תאריך/מספר גרסה משויך. הנתונים האלה נמצאים בעץ המקור של Android ב-
external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt
מכשיר
שיש תמיכה ב-OpenGL ES ברמת דיווח עצמי, מציין שהוא יכול לעבור את ה-dEQP
בדיקות בכל רשימות הבדיקה מהרמה הזו ומגרסאות קודמות.
אם בהטמעות של מכשירים יש תמיכה באחת מהגרסאות של OpenGL ES, הן:
- [C-2-1] חובה לדווח על כך באמצעות ממשקי ה-API המנוהלים של OpenGL ES וממשקי API מקוריים תוספי OpenGL ES אחרים שהם הטמיעו, ולהפך חייבים לא לדווח על מחרוזות תוספים שהן לא תומכות בהן.
- [C-2-2] חייבת לתמוך ב-
EGL_KHR_image
, ב-EGL_KHR_image_base
EGL_ANDROID_image_native_buffer
,EGL_ANDROID_get_native_client_buffer
EGL_KHR_wait_sync
,EGL_KHR_get_all_proc_addresses
,EGL_ANDROID_presentation_time
,EGL_KHR_swap_buffers_with_damage
,EGL_ANDROID_recordable
ו-EGL_ANDROID_GLES_layers
תוספים. - [C-2-3] חובה לדווח על הגרסה המקסימלית של בדיקות dEQP של OpenGL ES
נתמך באמצעות התכונה הניסיונית
android.software.opengles.deqp.level
. - [C-2-4] חייבת להיות תמיכה לפחות בגרסה 132383489 (החל מ-1 במרץ 2020)
דווחו בדגל התכונה
android.software.opengles.deqp.level
. - [C-2-5] חובה לעבור את כל בדיקות ה-OpenGL ES dEQP ברשימות הבדיקה בין הגרסאות
132383489 והגרסה שצוינה ב
סימון תכונה
android.software.opengles.deqp.level
, לכל אחד מהסוגים הנתמכים גרסת OpenGL ES. - [C-SR-2] מומלץ מאוד לתמוך ב-
EGL_KHR_partial_update
OES_EGL_image_external
תוספים. - אמור לדווח באופן מדויק באמצעות השיטה
getString()
, כל טקסטורה או בפורמט הדחיסה שבו הם תומכים, שהוא בדרך כלל ספציפי לספק. - צריכה לתמוך ב-
EGL_IMG_context_priority
וב-EGL_EXT_protected_content
תוספים.
אם הטמעות המכשיר מצהירות על תמיכה ב-OpenGL ES בגרסה 3.0, 3.1 או 3.2:
- [C-3-1] חובה לייצא את סמלי הפונקציות התואמים של הגרסה הזו בנוסף לסמלי הפונקציה OpenGL ES 2.0 בספרייה libGLESv2.so.
- [C-SR-3] מומלץ מאוד לתמוך ב-
OES_EGL_image_external_essl3
לתוסף.
אם בהטמעות במכשירים תומכים ב-OpenGL ES 3.2, הן:
- [C-4-1] חייבת לתמוך בחבילת התוספים ל-Android של OpenGL ES ל-Android בשלמותה.
אם בהטמעות המכשיר תומכות בחבילת התוספים ל-Android של OpenGL ES כלל, הם:
- [C-5-1] חובה לזהות את התמיכה דרך
android.hardware.opengles.aep
דגל של פיצ'ר.
אם הטמעות של מכשירים חושפות את התמיכה ב-EGL_KHR_mutable_render_buffer
הם:
- [C-6-1] חייבת לתמוך ב-
EGL_ANDROID_front_buffer_auto_refresh
לתוסף.
7.1.4.2 Vulkan
Android כולל תמיכה ב-Vulkan , ממשק API שדורש תקורה נמוכה בפלטפורמות שונות לגרפיקה תלת-ממדית בעלת ביצועים גבוהים.
אם בהטמעות במכשירים תומכים ב-OpenGL ES 3.1, הן:
- [C-SR-1] מומלץ מאוד לכלול תמיכה ב-Vulkan 1.3.
- [C-4-1] אסור לתמוך בגרסת וריאנט של Vulkan (כלומר, וריאנט) חלק מגרסת הליבה של Vulkan חייב להיות אפס).
אם הטמעות במכשירים כוללות פלט מסך או פלט וידאו:
- [C-SR-2] מומלץ מאוד לכלול תמיכה ב-Vulkan 1.3.
בדיקות dEQP של Vulkan מחולקות למחיצות (Partitions) לכמה רשימות של בדיקות, כל אחת עם
תאריך/גרסה שמשויכים אליה. הנתונים האלה נמצאים בעץ המקור של Android ב-
external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt
מכשיר
שתומך ב-Vulkan ברמת דיווח עצמי, מציין שהוא יכול לעבור את ה-dEQP
בדיקות בכל רשימות הבדיקה מהרמה הזו ומגרסאות קודמות.
אם הטמעות במכשירים כוללות תמיכה ב-Vulkan 1.0 ואילך:
- [C-1-1] חובה לדווח על הערך הנכון של המספר השלם באמצעות הפונקציה
android.hardware.vulkan.level
ו-android.hardware.vulkan.version
דגלים בפיצ'ר. - [C-1-2] חובה לספור, לפחות
VkPhysicalDevice
אחד עבור ה-Vulkan ממשק API מקוריvkEnumeratePhysicalDevices()
הקצר הזה. התשובות שלך יעזרו לנו להשתפר. - [C-1-3] חובה להטמיע באופן מלא את ממשקי ה-API של Vulkan 1.0 לכל ספירה
VkPhysicalDevice
- [C-1-4] חובה לספור שכבות, שכלולות בספריות מקוריות שנקראות
libVkLayer*.so
בספריית הספרייה המקורית של חבילת האפליקציה, דרך ממשקי ה-API המקוריים של VulkanvkEnumerateInstanceLayerProperties()
ו-vkEnumerateDeviceLayerProperties()
הקצר הזה. התשובות שלך יעזרו לנו להשתפר. - [C-1-5] אסור לספור שכבות שסופקו על ידי ספריות מחוץ
של האפליקציה, או לספק דרכים אחרות למעקב או ליירוט של
Vulkan API, אלא אם האפליקציה כוללת את המאפיין
android:debuggable
מוגדר כ-true
. - [C-1-6] חובה לדווח על כל מחרוזות התוספים שהן תומכות בהן דרך ממשקי API מקוריים של Vulkan , ולעומת זאת אסור לדווח על מחרוזות תוסף שהם לא תומכים בהם בצורה נכונה.
- [C-1-7] חייבת לתמוך ב-VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, ו-VK_KHR_incremental_present.
- [C-1-8] חובה לדווח על הגרסה המקסימלית של בדיקות dEQP של Vulkan
נתמך באמצעות התכונה הניסיונית
android.software.vulkan.deqp.level
. - [C-1-9] חייבת להיות תמיכה לפחות בגרסה
132317953
(החל מ-1 במרץ 2019) בתור דווחו בדגל התכונהandroid.software.vulkan.deqp.level
. - [C-1-10] חובה לעבור את כל בדיקות ה-dEQP של Vulkan ברשימות הבדיקות בין
גרסה
132317953
והגרסה שמצוינת דגלandroid.software.vulkan.deqp.level
של תכונה. - [C-1-11] אסור לציין תמיכה במימד VK_KHR_video_queue תוספי VK_KHR_video_decode_queue או VK_KHR_video_encode_queue
- [C-SR-3] מומלץ מאוד לתמוך ב-
VK_KHR_driver_properties
ו-VK_GOOGLE_display_timing
תוספים. - צריכה לתמוך ב-
VkPhysicalDeviceProtectedMemoryFeatures
וב-VK_EXT_global_priority
. - [C-1-12] אסור לספור תמיכה בתוסף VK_KHR_performance_query.
- [C-SR-4] מומלץ מאוד למלא את הדרישות שצוינו על ידי פרופיל Android Baseline 2021.
אם הטמעות במכשירים לא כוללות תמיכה ב-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
.
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] חייבת להיות מסוגלת למדוד מצניחה חופשית עד פי ארבע כוח משיכה(4 ג') או יותר בכל ציר.
- [C-1-5] חייבת להיות ברזולוציה של 12 ביט לפחות.
- [C-1-6] חייבת להיות סטיית תקן של לא יותר מ-0.05 מטר/s^, כאשר יש לחשב את סטיית התקן על בסיס כל ציר על בסיס דגימות שנאספו במשך פרק זמן של 3 שניות לפחות, בקצב הדגימה המהיר ביותר.
- צריך לדווח על אירועים עד 200 Hz לפחות.
- הרזולוציה צריכה להיות לפחות 16 סיביות.
- צריך לכייל אותו בזמן השימוש אם המאפיינים משתנים במחזור החיים של התגמול, ושומרים על הפרמטרים של הפיצוי בין הפעלות מחדש של המכשיר.
- הטמפרטורה אמורה לפצות על הטמפרטורה.
אם יישומי המכשירים כוללים מד תאוצה ב-3 צירים, הם:
- [C-2-1] חובה להטמיע את החיישן
TYPE_ACCELEROMETER
ולדווח עליו. - [C-SR-4] מומלץ מאוד להטמיע את
TYPE_SIGNIFICANT_MOTION
מרוכב. - [C-SR-5] מומלץ מאוד להטמיע מודעות ולדווח עליהן
חיישן
TYPE_ACCELEROMETER_UNCALIBRATED
. מכשירי Android הם בשימוש חזק מומלץ לעמוד בדרישה הזו כדי שהם יוכלו לשדרג במהדורה עתידית של פלטפורמה שבה יכול להיות שהדרישה הזו תהיה REQUIRED. - צריך להטמיע את
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
,TYPE_STEP_COUNTER
מחיישנים מורכבים, כפי שמתואר במסמך ה-SDK של Android.
אם בהטמעות המכשירים יש מד תאוצה עם פחות מ-3 צירים:
- [C-3-1] חובה להטמיע את החיישן
TYPE_ACCELEROMETER_LIMITED_AXES
ולדווח עליו. - [C-SR-6] מומלץ מאוד ליישם את ההמלצה ולדווח עליה
חיישן
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
אם יישומי המכשיר כוללים מד תאוצה ב-3 צירים ואחד
TYPE_SIGNIFICANT_MOTION
, TYPE_TILT_DETECTOR
, TYPE_STEP_DETECTOR
הוטמעו חיישנים מורכבים של TYPE_STEP_COUNTER
:
- [C-4-1] סך צריכת החשמל הכוללת שלהם חייב להיות תמיד פחות מ-4 מגה-ואט.
- כל אחד מהם צריך להיות קטן מ-2 מגה-ואט ו-0.5 מגה-ואט כשהמכשיר במצב דינמי או סטטי.
אם הטמעת המכשיר כוללת מד תאוצה ב-3 צירים וחיישן ג'ירוסקופ עם 3 צירים, הם:
- [C-5-1] חובה ליישם
את החיישנים המורכבים
TYPE_GRAVITY
ו-TYPE_LINEAR_ACCELERATION
. - [C-SR-7] מומלץ מאוד ליישם
TYPE_GAME_ROTATION_VECTOR
מרוכב.
אם יישומי המכשיר כוללים מד תאוצה ב-3 צירים, חיישן ג'ירוסקופ עם 3 צירים וחיישן מגנטומטר, הן:
- [C-6-1] חובה להטמיע חיישן מורכב של
TYPE_ROTATION_VECTOR
.
7.3.2. מגנטומטר
הטמעות מכשירים:
- [C-SR-1] מומלץ מאוד לכלול מגנטומטר (מצפן) עם 3 צירים.
אם הטמעתם במכשירים שונים מגנטומטר עם 3 צירים:
- [C-1-1] חובה להטמיע את החיישן
TYPE_MAGNETIC_FIELD
. - [C-1-2] חייבת להיות אפשרות לדווח על אירועים בתדירות של עד 10 Hz לפחות וצריכים לדווח על אירועים עד 50 Hz לפחות.
- [C-1-3] חייב לעמוד בדרישות של מערכת הקואורדינטות של חיישן Android כפי שמפורט ממשקי API של Android.
- [C-1-4] חייבת להיות יכולת למדוד בין -900 μT ל- +900 μT בכל אחד לפני רוויה.
- [C-1-5] ערך ההיסט של ברזל קשיח נמוך מ- 700 μT והוא צריך להיות ערך נמוך מ- 200 μT, על ידי הצבת המגנטומטר רחוק שדות מגנטיים דינמיים (בזרם חשמלי) וסטטיים (בהגברת מגנט).
- [C-1-6] הרזולוציה צריכה להיות שווה או צפופה יותר מ-0.6 μT.
- [C-1-7] חובה לתמוך בכיול מקוון ובפיצוי של הברזל הקשיח הטיה ולשמר את הפרמטרים של הפיצוי בין הפעלות מחדש של המכשיר.
- [C-1-8] חובה להחיל את הפיצוי על הברזל הרך – הכיול יכול להיות בזמן השימוש או במהלך הייצור של המכשיר.
- [C-1-9] חייבת להיות סטיית תקן, המחושבת על בסיס לכל ציר דגימות שנאספו במשך פרק זמן של 3 שניות לפחות, בדגימה המהירה ביותר קצב של עד 1.5 μT; אמורה להיות סטיית תקן שלא גדולה מ- 0.5 μT.
- [C-1-10] חובה ליישם
TYPE_MAGNETIC_FIELD_UNCALIBRATED
באמצעות חיישן.
אם הטמעת המכשיר כוללת מגנטומטר ב-3 צירים, מד תאוצה וחיישן ג'ירוסקופ עם 3 צירים, הם:
- [C-2-1] חובה להטמיע חיישן מורכב מסוג
TYPE_ROTATION_VECTOR
.
אם יישומי המכשיר כוללים מגנטומטר ב-3 צירים ומד תאוצה, הם:
- יכול להיות שהחיישן
TYPE_GEOMAGNETIC_ROTATION_VECTOR
יוטמע.
אם יישומי המכשיר כוללים מגנטומטר ב-3 צירים, מד תאוצה
חיישן TYPE_GEOMAGNETIC_ROTATION_VECTOR
, הן:
- [C-3-1] חובה לצרוך פחות מ-10 מגה-ואט.
- צריך לצרוך פחות מ-3 מגה-ואט כשהחיישן רשום במצב אצווה ב-10Hz.
7.3.3. GPS
הטמעות מכשירים:
- [C-SR-1] מומלץ מאוד לכלול מקלט GPS/GNSS.
אם יישומי המכשיר כוללים מקלט GPS/GNSS ומדווחים על היכולת
לאפליקציות באמצעות דגל התכונה android.hardware.location.gps
, הן:
- [C-1-1] חייבת לתמוך בפלט מיקום בקצב של 1 Hz לפחות כאשר
נשלחה בקשה דרך
LocationManager#requestLocationUpdate
. - [C-1-2] חייבת להיות אפשרות לקבוע את המיקום בתנאים של שמיים פתוחים
(אותות חזקים, מולטי-נתיב זניח, HDOP < 2) בתוך 10 שניות (מהירה
זמן לתיקון הראשון), כשמחוברים למהירות נתונים של 0.5Mbps או מהירות יותר
חיבור לאינטרנט. כדי לעמוד בדרישה הזו, השימוש בכלים
סוג של שיטת 'GPS/GNSS' בסיוע או חזויים
כדי למזער את זמן הנעילה של ה-GPS/GNSS (נתוני הסיוע כוללים את זמן ההפניה,
מיקום הפניה ותקופת זמן לוויינית/שעון).
- [C-1-6] לאחר ביצוע חישוב מיקום כזה, המכשיר וההטמעות חייבות לקבוע את המיקום שלהן, בשמיים פתוחים, 5 שניות, כשבקשות המיקום מופעלות מחדש, עד שעה לאחר מכן את חישוב המיקום הראשוני, גם כשהבקשה הבאה נעשה ללא חיבור נתונים ו/או לאחר מחזור חשמל.
במצב של שמיים פתוחים לאחר קביעת המיקום, כשהוא נייח או נע בפחות ממטר אחד לשנייה, בריבוע תאוצה:
- [C-1-3] חייבת להיות יכולת לקבוע את המיקום בטווח של 20 מטרים, ומהירות בטווח של 0.5 מטר לשנייה, לפחות ב-95% מהזמן.
- [C-1-4] חובה לעקוב בו-זמנית ולדווח עליהן באמצעות
GnssStatus.Callback
לפחות 8 לוויינים מקבוצת כוכבים אחת. - אמורה להיות אפשרות לעקוב בו-זמנית אחרי לפחות 24 לוויינים, מספר קבוצות כוכבים (למשל GPS + לפחות אחת של Glonass, ביידו, גליליאו).
[C-SR-2] מומלץ מאוד להמשיך לספק GPS/GNSS רגילים פלט נתוני מיקום דרך GNSS Location Provider API בזמן שיחת חירום שיחה.
[C-SR-3] מומלץ מאוד לדווח על מדידות של GNSS מכל הסוגים קבוצות כוכבים שנמצאות במעקב (כפי שדווח בהודעות GnssStatus), למעט של SBAS.
[C-SR-4] מומלץ מאוד לדווח על AGC ועל תדירות של GNSS מדידה.
[C-SR-5] מומלץ מאוד לדווח על כל אומדני הדיוק (כולל תמיכה, מהירות ואנכי) כחלק מכל מיקום GPS/GNSS.
[C-SR-6] מומלץ מאוד לדווח על מדידות של GNSS בהקדם האפשרי הם נמצאים, גם אם המיקום המחושב מ-GPS/GNSS עדיין לא דווחו.
[C-SR-7] מומלץ מאוד לדווח על טווחים פסאודוניים של GNSS קצבים פסאודונימים, כלומר, בתנאים של שמיים פתוחים לאחר קביעת המיקום, כאשר עומדת במקום או נעה בטווח של פחות מ-0.2 מטר לשנייה בריבוע תאוצה מספיקה כדי לחשב את המיקום בטווח של 20 מטרים, בטווח של 0.2 מטר לשנייה, לפחות ב-95% מהזמן.
7.3.4. ג'ירוסקופ
הטמעות מכשירים:
- [C-SR-1] מומלץ מאוד לכלול חיישן ג'ירוסקופ.
אם ההטמעות במכשיר כוללות ג'ירוסקופ, הן:
- [C-1-1] חייבת להיות אפשרות לדווח על אירועים בתדירות של עד 50Hz לפחות.
- [C-1-4] חייבת להיות ברזולוציה של 12 ביט או יותר.
- [C-1-5] חובה לפצות על הטמפרטורה.
- [C-1-6] חובה לבצע כיול ותגמול בזמן השימוש, ולשמור את פרמטרים של פיצוי בין הפעלה מחדש של המכשיר.
- [C-1-7] השונות חייבת להיות שונה מ- 1e-7 rad^2 / s^2 לכל Hz (שונות ל-Hz או rad^2 / s). השונות יכולה להשתנות עם קצב הדגימה, אך הערך הזה חייב להיות מוגבל. במילים אחרות, אם מודדים את השונות של הג'יירו בקצב דגימה של 1 Hz שהוא לא אמור להיות גדול יותר מ-1e-7 rad^2/s^2.
- [C-SR-2] מומלץ מאוד ששגיאת כיול תהיה קטנה מ- 0.01 rad/s כשהמכשיר נייח בטמפרטורת החדר.
- [C-SR-3] מומלץ מאוד להשתמש ברזולוציה של 16 ביט או יותר.
- צריך לדווח על אירועים עד 200 Hz לפחות.
אם הטמעת המכשיר כוללת ג'ירוסקופ עם 3 צירים:
- [C-2-1] חובה להטמיע את החיישן
TYPE_GYROSCOPE
. - [C-SR-4] מומלץ מאוד להטמיע את
TYPE_GYROSCOPE_UNCALIBRATED
באמצעות חיישן.
אם ההטמעות במכשירים כוללים ג'ירוסקופ עם פחות מ-3 צירים:
- [C-3-1] חובה להטמיע את החיישן
TYPE_GYROSCOPE_LIMITED_AXES
ולדווח עליו. - [C-SR-5] מומלץ מאוד ליישם את ההמלצה ולדווח עליה
חיישן
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
אם יישומי המכשיר כוללים ג'ירוסקופ ב-3 צירים, חיישן מד תאוצה וחיישן מגנטומטר, הן:
- [C-4-1] חובה להטמיע חיישן מורכב מסוג
TYPE_ROTATION_VECTOR
.
אם הטמעת המכשיר כוללת מד תאוצה ב-3 צירים וג'ירוסקופ עם 3 צירים הם:
- [C-5-1] חובה להטמיע את
TYPE_GRAVITY
ואתTYPE_LINEAR_ACCELERATION
מחיישנים מורכבים. - [C-SR-6] מומלץ מאוד ליישם
TYPE_GAME_ROTATION_VECTOR
מרוכב.
7.3.5. ברומטר
הטמעות מכשירים:
- [C-SR-1] מומלץ מאוד לכלול ברומטר (לחץ אוויר סביבתי) חיישן).
אם יישומי מכשירים כוללים ברומטר, הם:
- [C-1-1] חובה להטמיע את החיישן
TYPE_PRESSURE
ולדווח עליו. - [C-1-2] חייבת להיות אפשרות לספק אירועים בתדירות של 5Hz או יותר.
- [C-1-3] חובה לפצות על הטמפרטורה.
- [C-SR-2] מומלץ מאוד לאפשר דיווח על מדידות לחץ טווח של 300hPa עד 1100hPa.
- הדיוק שלו אמור להיות מוחלט של 1hPa.
- רמת הדיוק היחסית אמורה להיות 0.12hPa על פני טווח של 20hPa (שווה ערך לדיוק של כ-1 מ' לשינוי של כ-200 מ' בגובה פני הים).
7.3.6. מדחום
אם יישומי המכשיר כוללים מדחום סביבתי (חיישן טמפרטורה), הם:
- [C-1-1] חובה להגדיר
SENSOR_TYPE_AMBIENT_TEMPERATURE
לחיישן טמפרטורת הסביבה ולחיישן חייבים למדוד את הסביבה הטמפרטורה שבה (חדר/תא המטען) מהמקום שבו המשתמש מקיים אינטראקציה עם במעלות צלזיוס.
אם יישומי המכשיר כוללים חיישן מדחום שמודד מלבד טמפרטורת הסביבה, כמו הטמפרטורה של המעבד (CPU), במקרים הבאים:
- [C-2-1] אסור להגדיר
SENSOR_TYPE_AMBIENT_TEMPERATURE
חיישן הטמפרטורה.
אם הטמעת המכשיר כוללת חיישן לניטור טמפרטורת העור, ואז:
- [C-SR-1] מומלץ מאוד לתמוך PowerManager.getThermalHeadroom API.
7.3.7. פוטומטר
- ייתכן שהטמעות המכשיר כוללות פוטומטר (חיישן אור רגיש לסביבה).
7.3.8. חיישן קירבה
- ייתכן שהטמעות במכשירים כוללות חיישן קירבה.
אם יישומים של מכשירים כוללים חיישן קירבה, והם מדווחים רק על בקריאה בינארית "ליד" או "רחוק", הן:
- [C-1-1] חובה למדוד את הקרבה של עצם באותו כיוון מסך. כלומר, חיישן הקירבה צריך להיות מכוון לזיהוי עצמים קרוב למסך, כי הכוונה העיקרית של סוג החיישן הזה היא זיהוי טלפון שנמצא בשימוש של המשתמש. אם הטמעות המכשיר כוללות חיישן קירבה בכל כיוון אחר, אסור שהוא יהיה נגיש באמצעות ה-API הזה.
- [C-1-2] רמת דיוק של ביט אחד או יותר.
- [C-1-3] חובה להשתמש ב-0 ס"מ בתור הקריאה הקרובה וב-5 ס"מ קריאה רחוקה.
- [C-1-4] חובה לדווח על טווח ורזולוציה מקסימלי של 5.
7.3.9. חיישנים באיכות גבוהה
אם ההטמעות במכשירים כוללות קבוצה של חיישנים באיכות גבוהה יותר, כפי שהוגדר בקטע הזה כדי להפוך אותם לזמינים לאפליקציות צד שלישי, הם:
- [C-1-1] חובה לזהות את היכולת באמצעות
סימון תכונה
android.hardware.sensor.hifi_sensors
.
אם בהטמעות המכשירים מוצהר על android.hardware.sensor.hifi_sensors
,
הם:
[C-2-1] חייב להיות חיישן
TYPE_ACCELEROMETER
שמאפשר:- טווח המדידה חייב להיות בין -8G ל-8G+, מומלץ מאוד להגדיר טווח מדידה בין -16G לפחות ו-16G+.
- רזולוציית המדידה חייבת להיות לפחות 2048 LSB/g.
- תדירות המדידה המינימלית חייבת להיות 12.5Hz או נמוכה יותר.
- תדירות המדידה המקסימלית חייבת להיות 400 Hz או יותר. אמור
תומכים ב-SensorDirectChannel
RATE_VERY_FAST
. - הרעש במדידה חייב להיות נמוך מ-400 μg/לצאת.
- חובה להשתמש בחיישן הזה בצורת חיישן שלא נכנס למצב שינה עם אגירת נתונים יכולת של 3,000 אירועי חיישנים לפחות.
- צריכת החשמל באצווה חייבת להיות נמוכה מ-3 מגה-ואט.
- [C-SR-1] מומלץ מאוד שרוחב הפס למדידה של 3dB יהיה בגודל של לפחות 80% מתדר ה-Nyquist וספקטרום הרעש הלבן. רוחב פס.
- אמורה להתבצע הליכה אקראית של האצה בפחות מ-30 μg תמצאו ב- Wi-Fi בטמפרטורת החדר.
- אמור להיות שינוי בהטיה לעומת טמפרטורה של ≤ +/- 1 mg/°C .
- אמור להיות קו הכי מתאים של לא ליניאריות של ≤ 0.5%, ושינוי הרגישות לעומת הטמפרטורה הוא ≤ 0.03%/C°.
- אמורה להיות רגישות חוצה-צירים של < 2.5 % ווריאציה של הרגישות של צירים שונים < 0.2% בטווח טמפרטורת הפעולה של המכשיר.
[C-2-2] חייב להיות
TYPE_ACCELEROMETER_UNCALIBRATED
עם אותו ערך דרישות איכות כמוTYPE_ACCELEROMETER
.[C-2-3] חייב להיות חיישן
TYPE_GYROSCOPE
שמאפשר:- טווח המדידה חייב להיות בין -1000 ל- +1000 dps.
- רזולוציית המדידה חייבת להיות לפחות 16 LSB/dps.
- תדירות המדידה המינימלית חייבת להיות 12.5Hz או נמוכה יותר.
- תדירות המדידה המקסימלית חייבת להיות 400 Hz או יותר. אמור
תומכים ב-SensorDirectChannel
RATE_VERY_FAST
. - הרעש במדידה חייב להיות נמוך מ-0.014°/s/לצאת.
- [C-SR-2] מומלץ מאוד שרוחב הפס למדידה של 3dB יהיה בגודל של לפחות 80% מתדר ה-Nyquist וספקטרום הרעש הלבן. רוחב פס.
- צריכה להיות הליכה אקראית של קצב של פחות מ- 0.001 °/s תמצאו Hz בחדר לטמפרטורה.
- אמור להיות שינוי בהטיה לעומת טמפרטורה של ≤ +/- 0.05 °C/ s / °C.
- צריך להיות שינוי ברגישות לעומת הטמפרטורה של 0.02% / °C.
- הקו המתאים ביותר צריך להיות לא ליניארי, כלומר 0.2% או פחות.
- צפיפות הרעש אמורה להיות ≤ 0.007 °/s/COLUMNHz.
- אמורה להיות שגיאת כיול בגודל של פחות מ-0.002 rad/s טווח טמפרטורות 10 ~ 40°C כשהמכשיר נייח.
- הרגישות ל-g צריכה להיות נמוכה מ-0.1°/s/g.
- אמורה להיות רגישות חוצה-צירים של < 4.0 % ורגישות לרוחב צירים וריאציה < 0.3% בטווח טמפרטורת הפעולה של המכשיר.
[C-2-4] חובה לספק
TYPE_GYROSCOPE_UNCALIBRATED
באיכות זהה בדרישות האלה,TYPE_GYROSCOPE
.[C-2-5] חייב להיות חיישן
TYPE_GEOMAGNETIC_FIELD
שמאפשר:- טווח המדידה חייב להיות בין -900 ל- +900 μT.
- רזולוציית המדידה חייבת להיות לפחות 5 LSB/uT.
- תדירות המדידה המינימלית חייבת להיות 5Hz או נמוכה יותר.
- תדירות המדידה המקסימלית חייבת להיות 50Hz או יותר.
- הרעש במדידה חייב להיות נמוך מ-0.5 UT.
[C-2-6] חובה לספק
TYPE_MAGNETIC_FIELD_UNCALIBRATED
באיכות זהה דרישות כמוTYPE_GEOMAGNETIC_FIELD
ובנוסף:- חובה להשתמש בחיישן הזה בצורת חיישן שלא נכנס למצב שינה עם אגירת נתונים יכולת של 600 אירועי חיישנים לפחות.
- [C-SR-3] מומלץ מאוד להשתמש בספקטרום של רעש לבן מ-1 הרץ עד לפחות 10 Hz כשקצב הדיווח הוא 50Hz או יותר.
[C-2-7] חייב להיות חיישן
TYPE_PRESSURE
שמאפשר:- טווח המדידה חייב להיות בין 300 ל-1100 hPa.
- רזולוציית המדידה חייבת להיות לפחות 80 LSB/hPa.
- תדירות המדידה המינימלית חייבת להיות 1 Hz או נמוכה יותר.
- תדירות המדידה המקסימלית חייבת להיות 10Hz או יותר.
- הרעש במדידה חייב להיות נמוך מ-2 Pa/😂.
- חובה להשתמש בחיישן הזה בצורת חיישן שלא נכנס למצב שינה עם אגירת נתונים יכולת של 300 אירועי חיישן לפחות.
- צריכת החשמל באצווה חייבת להיות נמוכה מ-2 מגה-ואט.
[C-2-8] חייב להיות חיישן
TYPE_GAME_ROTATION_VECTOR
.[C-2-9] חייב להיות חיישן
TYPE_SIGNIFICANT_MOTION
ש:- צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי ו- 1.5 mW כשהמכשיר נמצא בתנועה.
[C-2-10] חייב להיות חיישן
TYPE_STEP_DETECTOR
ש:- חובה להשתמש בחיישן הזה בצורת חיישן שלא נכנס למצב שינה עם אגירת נתונים יכולת של 100 אירועי חיישן לפחות.
- צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי ו- 1.5 mW כשהמכשיר נמצא בתנועה.
- צריכת החשמל באצווה חייבת להיות נמוכה מ-4 מגה-ואט.
[C-2-11] חייב להיות חיישן
TYPE_STEP_COUNTER
ש:- צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי ו- 1.5 mW כשהמכשיר נמצא בתנועה.
[C-2-12] חייב להיות חיישן
TILT_DETECTOR
ש:- צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי ו- 1.5 mW כשהמכשיר נמצא בתנועה.
[C-2-13] חותמת הזמן של האירוע של אותו אירוע פיזי שדווח על ידי מד התאוצה, הג'יירוסקופ והמגנטומטר חייבים להיות בטווח של 2.5 אלפיות השנייה שתי רשתות נוירונים זו מול זו. חותמת הזמן של האירוע של אותו אירוע פיזי שדווח על ידי מד התאוצה והג'ירוסקופ צריכים להיות בטווח של 0.25 אלפיות שנייה אחר.
[C-2-14] חותמות הזמן של אירועים מחיישן הג'ירוסקופ צריכות להיות מוצגות באותו הזמן בתור מערכת המשנה של המצלמה, ותוך אלפיות שנייה אחת משגיאה.
[C-2-15] חובה לשלוח דגימות לאפליקציות תוך 5 אלפיות שנייה השעה שבה הנתונים זמינים באחד מהחיישנים הפיזיים שצוינו למעלה לאפליקציה.
[C-2-16] אסור שצריכת החשמל תהיה גבוהה מ-0.5 מגה-ואט כשהמכשיר סטטי ו- 2.0 mW כשהמכשיר נמצא בתנועה כששילוב של החיישנים הבאים מופעל:
SENSOR_TYPE_SIGNIFICANT_MOTION
SENSOR_TYPE_STEP_DETECTOR
SENSOR_TYPE_STEP_COUNTER
SENSOR_TILT_DETECTORS
[C-2-17] עשויים להיות חיישן
TYPE_PROXIMITY
, אבל אם קיים חיישן כזה עם יכולת מינימלית של מאגר נתונים זמני של 100 אירועי חיישן.
שימו לב שכל הדרישות של צריכת החשמל בקטע הזה לא כוללות את של מעבד האפליקציות. הוא כולל את הכוח נמשך על ידי כל שרשרת החיישנים - החיישן, כל מעגלים תומכים, מערכת ייעודית לעיבוד חיישנים וכו'.
אם ההטמעות במכשירים כוללות תמיכה ישירה בחיישנים:
- [C-3-1] חובה להצהיר בצורה נכונה על תמיכה בסוגי ערוצים ישירים
לדווח על רמת המחירים דרך
isDirectChannelTypeSupported
ו-getHighestDirectReportRateLevel
API. - [C-3-2] חייב לתמוך לפחות באחד משני סוגי הערוצים הישירים של חיישנים לכל החיישנים שמצהירים על תמיכה בערוץ ישיר של חיישן.
- צריכה לתמוך בדיווח על אירועים דרך ערוץ ישיר של חיישן
חיישן (וריאנט ללא מצב שינה) מהסוגים הבאים:
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
7.3.10. חיישנים ביומטריים
רקע נוסף על מדידת אבטחה ביומטרית לביטול נעילה, אפשר לעיין במאמר מסמכי תיעוד בנושא אבטחה ביומטרית.
אם הטמעתם במכשיר מסך נעילה מאובטח:
- צריכה לכלול חיישן ביומטרי
ניתן לסווג חיישנים ביומטריים כסיווג 3 (לשעבר חזק), Class 2 (לשעבר Weak) או Class 1 (לשעבר Convenience) בהתבסס על שיעורי הזיוף וההתחזות שלהם, ועל האבטחה צינור עיבוד נתונים ביומטרי. הסיווג הזה קובע את היכולות של החיישן הביומטרי צריך להתממשק עם הפלטפורמה ועם צד שלישי תרגום מכונה. החיישנים צריכים לעמוד בדרישות נוספות שמפורטות בהמשך, אם רוצים לסווג אותם כרמה 1, רמה 2 או רמה 3. הנתונים הביומטריים של רמה 2 וגם של סיווג 3 מקבלים יכולות נוספות: כמפורט בהמשך.
אם ההטמעות במכשיר מאפשרות לצד שלישי גישה לחיישן ביומטרי אפליקציות דרך android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt, וגם android.provider.Settings.ACTION_BIOMETRIC_ENROLL, הם:
- [C-4-1] האפליקציה חייבת לעמוד בדרישות לדיווח ביומטרי ברמה Class 3 או Class 2 כפי שמוגדר במסמך הזה.
- [C-4-2] חובה לזהות ולכבד כל שם של פרמטר שמוגדר כקבוע בקטע המאמתים והשילובים שלו. לעומת זאת, אסור להכיר בקבועים של מספרים שלמים שמועברים canAuthenticate(int) ו-setAllowedAuthenticator(int) שיטות אחרות שלא מתועדות כקבועים ציבוריים מאמתי חשבונות וכל שילובים שלהם.
- [C-4-3] חובה להטמיע את ACTION_BIOMETRIC_ENROLL פעולה במכשירים עם מידע ביומטרי מסוג רמה 3 או סיווג 2. הפעולה הזו חייבת להציג רק את נקודות הכניסה לרמה 3. או מידע ביומטרי מסוג רמה 2.
אם הטמעות במכשירים תומכים בזיהוי ביומטרי פסיבית:
- [C-5-1] כברירת מחדל חובה לדרוש שלב אישור נוסף (למשל, לחיצה על לחצן).
- [C-SR-1] מומלץ מאוד לקבוע הגדרה שמאפשרת למשתמשים לבטל את ההעדפה של האפליקציה ותמיד להשתמש בתוספות שלב האישור.
- [C-SR-2] מומלץ מאוד לוודא שפעולת האישור מאובטחת כך שמערכת ההפעלה או התוכנה בליבה לא יוכלו לזייף אותה. לדוגמה, המשמעות היא שפעולת האישור מבוססת על לחצן פיזי עובר דרך סיכת קלט/פלט לשימוש כללי (GPIO) בלבד, רכיב מאובטח (SE) שלא ניתן להפעיל באמצעותו שום אמצעי אחר מלבד לחיצה על הלחצן הפיזי.
- [C-5-2] חובה להטמיע גם תהליך אימות מרומז (ללא שלב אישור) שתואם ל- setConfirmationrequired(boolean), אילו אפליקציות יכולות להשתמש בהן לתהליכי כניסה.
אם בהטמעות במכשירים יש כמה חיישנים ביומטריים:
- [C-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 הטמעת פרויקט מקור מספקת במסגרת המסגרת את המנגנון לביצוע אז.
- [C-1-5] חובה להסיר לחלוטין את כל הנתונים הביומטריים שניתנים לזיהוי של המשתמש כשמסירים את החשבון של המשתמש (כולל באמצעות איפוס להגדרות המקוריות).
- [C-1-6] חובה לכבד את הדגל הספציפי של אותו מידע ביומטרי (למשל,
DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
DevicePolicymanager.KEYGUARD_DISABLE_FACE
, אוDevicePolicymanager.KEYGUARD_DISABLE_IRIS
). - [C-1-7] חובה לאתגר את המשתמש לגבי האימות הראשי המומלץ (למשל, קוד אימות, קו ביטול נעילה, סיסמה) פעם ב-24 שעות או פחות. הערה: שדרוג מכשירים שהושקו ב-Android מגרסה 9 ומטה חייבים לבקש מהמשתמש לבצע את האימות הראשי המומלץ (למשל קוד אימות, קו ביטול נעילה, סיסמה) אחת ל-72 שעות או פחות.
- [C-1-8] חובה לאתגר את המשתמש לתחרות הראשית המומלצת
אימות (למשל: קוד אימות, קו ביטול נעילה, סיסמה) או מידע ביומטרי ברמה 3 (חזק)
אחרי אחד מהתנאים הבאים:
- פרק זמן של 4 שעות ללא פעילות, או
- 3 ניסיונות לאימות ביומטרי שנכשלו.
- פרק הזמן הקצוב לתפוגה שהוגדר לחוסר פעילות וספירת האימות שנכשלה תאופס אחרי כל אישור של פרטי הכניסה של המכשיר. הערה: שדרוג מכשירים שהושקו ב-Android גרסה 9 או גרסאות קודמות עשוי להיות פטור מ-C-1-8.
- [C-SR-7] מומלץ מאוד להשתמש בלוגיקה במסגרת המסגרת הרעיונית בפרויקט הקוד הפתוח של Android כדי לאכוף את המגבלות שצוינו [C-1-7] ו-[C-1-8] למכשירים חדשים.
- [C-SR-8] מומלץ מאוד ששיעור הדחייה השגוי יהיה נמוך מ- 10%, כפי שנמדד במכשיר.
- [C-SR-9] מומלץ מאוד שזמן האחזור יהיה פחות משנייה אחת, לפי המדידה מרגע הזיהוי של המידע הביומטרי ועד לביטול נעילת המסך, מידע ביומטרי רשום.
אם בהטמעות במכשירים רוצים להתייחס לחיישן ביומטרי כמו רמה 2 (לשעבר חלשות), הן:
[C-2-1] חייבת לעמוד בכל הדרישות של רמה 1 שמפורטות למעלה.
[C-2-2] שיעור הבקשות של זיוף ומתחזה חייב להיות נמוך מ-20%, עם (1) שיעור הצטרפות של מתחזה ומתחזה למצגת ברמה א' מין של כלי תקיפה (PAI) שגודלם לא עולה על 20%, ו-(2) זיוף שיעור קבלת המתחזה של מין PAI ברמה B שאינו גבוה מ-30%, כמו שנמדדת באמצעות פרוטוקולים לבדיקה של נתונים ביומטריים במערכת Android.
[C-2-3] חייבים לבצע את התאמה ביומטרית בסביבת ביצוע מבודדת מחוץ ל-Android של המשתמש או של הליבה שלו, כמו סביבת ביצוע מהימנה (TEE), או בצ'יפ עם ערוץ מאובטח לסביבת ההפעלה המבודדת.
[C-2-4] כל הנתונים המזהים צריכים להיות מוצפנים וקריפטוגרפיים. שעברו אימות כך שלא ניתן יהיה לרכוש אותם, לקרוא אותם או לשנות אותם מחוץ ל את סביבת הביצוע המבודדת או צ'יפ עם ערוץ מאובטח סביבת הפעלה מבודדת, כפי שמתועד בהטמעה הנחיות באתר של פרויקט הקוד הפתוח של Android.
[C-2-5] למידע ביומטרי שמבוסס על מצלמה, תוך אימות ביומטרי או מתבצע רישום:
- חובה להפעיל את המצלמה במצב שמונע מפריימים של המצלמה קריאה או שינוי מחוץ לסביבת הביצוע המבודדת או בצ'יפ באמצעות ערוץ מאובטח לסביבת ההפעלה המבודדת.
- בפתרונות RGB למצלמה אחת, ניתן להשתמש בפריימים של המצלמה קריא מחוץ לסביבת הביצוע המבודדת כדי לתמוך בפעולות כמו תצוגה מקדימה להרשמה, אבל עדיין אסור שתהיה אפשרות לשנות אותו.
[C-2-6] אסור לאפשר לאפליקציות של צד שלישי להבחין בין נתונים ביומטריים אישיים.
[C-2-7] אסור לאפשר גישה לא מוצפנת לנתונים ביומטריים שניתנים לזיהוי, או את הנתונים הנובעים ממנו (כגון הטמעות) אל מעבד האפליקציות מחוץ להקשר של אזור ה-TEE. שדרוג המכשירים הושק ב-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] חובה להפעיל לצד שלישי מפתחות של מאגר מפתחות עם גיבוי ביומטרי תרגום מכונה.
אם בהטמעות המכשיר יש חיישן טביעות אצבע מתחת למסך (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 [הועבר ל-7.4.9]
7.4. קישוריות נתונים
7.4.1. טלפוניה
המונח "טלפוניה" כפי שנעשה בו שימוש בממשקי ה-API של Android, והמסמך הזה מתייחס באופן ספציפי לחומרה שקשורה לביצוע שיחות קוליות ולשליחת הודעות SMS באמצעות GSM או רשת CDMA. למרות שהשיחות הקוליות האלה עשויות לעבור או לא לעבור בין חבילות, הם מיועדים ל-Android שנחשבים לבלתי תלויים בנתונים שאפשר להטמיע באמצעות אותה רשת. במילים אחרות, פונקציונליות הטלפוניה ב-Android, וממשקי ה-API מתייחסים באופן ספציפי לשימוש בפקודות קוליות שיחות והודעות SMS. לדוגמה, יישומים של מכשירים שלא ניתן לבצע בהם שיחות או הודעות SMS שנשלחות לא נחשבות למכשיר טלפוניה, ללא קשר האם הם משתמשים ברשת סלולרית לקישוריות נתונים.
- ניתן להשתמש ב-Android MAY במכשירים שלא כוללים חומרת טלפון. ש Android תואם למכשירים שאינם טלפונים.
אם ההטמעות של המכשירים כוללות טלפוניה מסוג GSM או CDMA, הן:
- [C-1-1] חובה להצהיר על דגל הפיצ'ר
android.hardware.telephony
סימונים של תכונות משנה אחרות בהתאם לטכנולוגיה. - [C-1-2] חייבים להטמיע תמיכה מלאה ב-API בטכנולוגיה הזו.
- צריכה לאפשר את כל סוגי השירותים הסלולריים הזמינים (2G, 3G, 4G, 5G וכו')
במהלך שיחות חירום (ללא קשר לסוגי הרשתות שהוגדרו
SetAllowedNetworkTypeBitmap()
).
אם ההטמעות של מכשירים לא כוללות חומרת טלפון:
- [C-2-1] חובה להטמיע את כל ממשקי ה-API כללא תפעול.
אם בהטמעות המכשיר יש תמיכה ב-eUICC, בכרטיסי eSIM או בכרטיסי SIM מוטמעים, וגם מנגנון קנייני להפיכת הפונקציונליות של eSIM לזמינה עבור צדדים שלישיים מפתחים:
- [C-3-1] חובה להצהיר על
android.hardware.telephony.euicc
דגל של פיצ'ר.
אם יישומי המכשיר לא מגדירים את מאפיין המערכת ro.telephony.iwlan\_operation\_mode
כ'מדור קודם', הם:
- [C-4-1] אסור לדווח על NETWORK_TYPE_IWLAN באמצעות NetworkRegistrationInfo#getAccessNetworkTechnology() כאשר NetworkRegistrationInfo#getTransportType() מדווח כ-'TRANSPORT_TYPE_WWAN' עבור אותה מופע NetworkRegistrationInfo.
אם בהטמעות של המכשיר יש תמיכה בתת-מערכת מולטימדיה אחת (IMS) של IP הרשמה לשירות טלפוניה מולטימדיה (MMTEL) וגם תכונות של שירותי תקשורת מגוונים (RCS) וצפויים לעמוד בדרישות עם דרישות של ספק סלולר בנוגע לשימוש רישום IMS לכל תעבורת הנתונים היוצאת מהאותות ב-IMS, הם:
- [C-5-1] חובה להצהיר על
android.hardware.telephony.ims
ולספק יישום מלא של התכונה ImsService API גם ל-MMTEL וגם ל-RCS User Capability Exchange API. - [C-5-2] חובה להצהיר על
android.hardware.telephony.ims.singlereg
סימון תכונה חדשה ולספק הטמעה מלאה של SipTransport API, GbaService API, אינדיקציה למוכ"ז ייעודי באמצעות IRadio 1.6 HAL והקצאה באמצעות שרת הגדרה אוטומטית (ACS) או הקצאה קניינית אחרת באמצעות IMS Configuration API.
אם הטמעות המכשירים מדווחות על התכונה android.hardware.telephony
, אז:
- [C-6-1]
SmsManager#sendTextMessage
ו-SmsManager#sendMultipartTextMessage
התוצאות חייבות להוביל לקריאות תואמות אלCarrierMessagingService
לצורך אספקת פונקציונליות של העברת הודעות טקסט.SmsManager#sendMultimediaMessage
וגםSmsManager#downloadMultimediaMessage
התוצאות חייבות להוביל לקריאות תואמות אלCarrierMessagingService
לצורך אספקת פונקציונליות של העברת הודעות מולטימדיה. - [C-6-2] הבקשה שסווגה על ידי
android.provider.Telephony.Sms#getDefaultSmsPackage
חובה להשתמש SmsManager ממשקי API לשליחה ולקבלה של הודעות SMS ו-MMS. מסמך העזר של AOSP בחבילות/באפליקציות או ב'העברת הודעות', עומדים בדרישה הזו. - [C-6-3] האפליקציה שמגיבה
Intent#ACTION_DIAL
חייבת להיות תמיכה בהזנה של קודי חייגן שרירותיים בפורמט*#*#CODE#*#*
וכן מפעילהTelephonyManager#ACTION_SECRET_CODE
שידור. - [C-6-4] האפליקציה שמגיבה
Intent#ACTION_DIAL
חובה להשתמשVoicemailContract.Voicemails#TRANSCRIPTION
כדי להציג למשתמשים תמלול של דואר קולי ויזואלי, אם הוא תומך בפיצ'רים חזותיים תמלול ההודעות הקוליות. - [C-6-5] חייב לייצג את כל SubscriptionInfo עם נתונים שווי ערך
מזהי UUID קבוצתיים
כמנוי יחיד בכל העלויות הגלויות למשתמשים שמציגים
שליטה בפרטי כרטיס ה-SIM. דוגמאות להוצאות כאלה כוללות הגדרות
ממשקים שתואמים
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
אוEuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
- [C-6-6] אסור להציג או לאפשר שליטה ב-SubscriptionInfo עם UUID של קבוצה שאינו null וביט הזדמנויות בכל מחיר שנראה למשתמש לאפשר תצורה או שליטה בהגדרות של כרטיס SIM.
אם בהטמעות המכשירים מדווחות על התכונה android.hardware.telephony
ומספקים שורת סטטוס מערכת, ואז:
- [C-7-1] חובה לבחור מינוי פעיל שמייצג UUID קבוצתי להצגה למשתמש תמורת הטבות שניתנות עבור סטטוס כרטיס ה-SIM. מידע. דוגמאות להוצאות כאלה כוללות את שורת הסטטוס 'סלולרי' סמל האות או לחצן ההגדרות המהירות.
- [C-SR-1] מומלץ מאוד שהמינוי של הנציג נבחר להיות מינוי לנתונים פעילים אלא אם המכשיר הוא בקול שבמהלכה מומלץ מאוד שהנציג המינוי הוא המינוי הפעיל ל-Voice.
אם הטמעות המכשירים מדווחות על התכונה android.hardware.telephony
, אז:
- [C-6-7] חייבת להיות יכולת לפתוח ולנצל בו-זמנית את הערך המקסימלי מספר הערוצים הלוגיים (20 בסך הכול) לכל UICC בהתאם לתקן ETSI TS 102 221.
- [C-6-8] אסור להחיל אף אחת מההתנהגויות הבאות על אפליקציות ספק פעילות
(כפי שהוגדר על ידי
TelephonyManager#getCarrierServicePackageName
) באופן אוטומטי או ללא אישור מפורש של המשתמש:- ביטול הגישה לרשת או הגבלה שלה
- ביטול הרשאות
- הגבלת הביצוע של אפליקציות ברקע או בחזית מעבר לתכונות ניהול צריכת החשמל הקיימות שכלולות ב-AOSP
- השבתה או הסרה של האפליקציה
אם ההטמעה של המכשירים מדווחת על התכונה android.hardware.telephony
וגם
כל הפעילות,
מינויים לא הזדמנויות
שחולקים מזהה ייחודי אוניברסלי (UUID) של קבוצה מושבתים,
הוסר פיזית מהמכשיר, או מסומן כיצירתי, אז המכשיר:
- [C-8-1] חובה להשבית באופן אוטומטי את כל שאר הפעילויות הפעילות הזדמנויות למינויים באותה קבוצה.
אם אופן ההטמעה של המכשירים כולל טלפוניה GSM אבל לא טלפוניה מסוג CDMA, הם:
- [C-9-1] אסור להצהיר על
PackageManager#FEATURE_TELEPHONY_CDMA
. - [C-9-2] חובה להשליך
IllegalArgumentException
בניסיון לקבוע סוגי רשתות 3GPP2 במסיכות ביט מסוג רשת מועדף או מותר. - [C-9-3] חייבת להחזיר מחרוזת ריקה מ:
TelephonyManager#getMeid
אם בהטמעות המכשיר תומכות ב-eUICC עם כמה יציאות ופרופילים, הן:
- [C-10-1] חובה להצהיר על
android.hardware.telephony.euicc.mep
דגל של פיצ'ר.
7.4.1.1. תאימות לחסימת מספרים
אם הטמעות במכשירים ידווחו על התכונה android.hardware.telephony.calling
, הן:
- [C-1-1] חייבת לכלול תמיכה בחסימת מספרים
- [C-1-2] חובה להטמיע את
BlockedNumberContract
באופן מלא וממשק ה-API התואם, כפי שמתואר במסמכי התיעוד של ה-SDK. [C-1-3] חובה לחסום את כל השיחות וההודעות ממספר טלפון אחד 'BlockNumberProvider' ללא אינטראקציה עם האפליקציות. יוצא הדופן היחיד היא תופסק כשחסימת המספרים תופסק באופן זמני, כפי שמתואר ב-SDK התיעוד.
[C-1-4] חובה לכתוב אל ספק יומן השיחות בפלטפורמה עבור שיחה שנחסמה וחובה לסנן שיחות עם
BLOCKED_TYPE
תצוגת ברירת המחדל של יומן השיחות באפליקציית החייגן שהותקנה מראש.[C-1-5] אסור לכתוב לספק הטלפוניה להודעה שנחסמה.
[C-1-6] חובה להטמיע ממשק משתמש חסום לניהול מספרים, שנפתח עם הכוונה שהוחזרה על ידי
TelecomManager.createManageBlockedNumbersIntent()
.[C-1-7] אסור לאפשר למשתמשים משניים לצפות במספרים החסומים או לערוך אותם במכשיר, כי פלטפורמת Android מניחה שהמשתמש הראשי שליטה בשירותי הטלפוניה, מכונה אחת, במכשיר. הכול ממשק משתמש קשור לחסימה חייב להיות מוסתר אצל משתמשים משניים והרשימה החסומה חייבת להיות מוסתרת עדיין יש לכבד אותם.
צריך להעביר את המספרים החסומים לספק כשמכשיר מתעדכן ל-Android 7.0.
האפליקציה צריכה לאפשר למשתמש להציג שיחות חסומות במכשירים שמותקנים מראש אפליקציית חייגן.
7.4.1.2. API של Telecom
אם הטמעות המכשירים ידווחו על android.hardware.telephony.calling
, הן:
- [C-1-1] חייבת לתמוך בממשקי ה-API של
ConnectionService
שמתוארים ב-SDK. - [C-1-2] חובה להציג שיחה נכנסת חדשה ולספק למשתמש אפשרויות עבור
אישור או דחייה של השיחה הנכנסת כשמשתמש בשיחה פעילה
נוצר על ידי אפליקציית צד שלישי שלא תומכת בתכונת ההשהיה
צוין דרך
CAPABILITY_SUPPORT_HOLD
- [C-1-3] חייבת להיות אפליקציה שמממשת InCallService.
[C-SR-1] מומלץ מאוד להודיע למשתמש שעונה על השיחה הנכנסת תנתק את השיחה הנוכחית.
הטמעת ה-AOSP עומדת בדרישות האלה בהתראה 'שימו לב' שמציינת למשתמש שמענה לשיחה נכנסת יגרום הקריאה האחרת תושג.
[C-SR-2] מומלץ מאוד לטעון מראש את אפליקציית החייגן שמוגדרת כברירת מחדל מציגה רשומה ביומן השיחות ואת השם של אפליקציה של צד שלישי ביומן השיחות שלה. כשאפליקציית הצד השלישי מגדירה
EXTRA_LOG_SELF_MANAGED_CALLS
מקש תוספות בPhoneAccount
עדtrue
.[C-SR-3] מומלץ מאוד לטפל באוזניות אירועים של
KEYCODE_MEDIA_PLAY_PAUSE
ו-KEYCODE_HEADSETHOOK
עבורandroid.telecom
ממשקי API הבאים:- התקשרות אל
Connection.onDisconnect()
כשמזוהה לחיצה קצרה על האירוע המרכזי במהלך שיחה פעילה. - התקשרות אל
Connection.onAnswer()
כשמזוהה לחיצה קצרה על האירוע המרכזי במהלך שיחה נכנסת. - התקשרות אל
Connection.onReject()
כשמזוהה לחיצה ארוכה על האירוע המרכזי במהלך שיחה נכנסת. - החלפת מצב ההשתקה של
CallAudioState
.
- התקשרות אל
7.4.1.3. העברה ל-Keepalive לרשת סלולרית מסוג NAT-T
הטמעות מכשירים:
- היא צריכה לכלול תמיכה בהפחתה לעומס (Keepalive) ברשת סלולרית.
אם ההטמעות במכשיר כוללות תמיכה בעומס (payalive) לרשת סלולרית, וגם חושפת את הפונקציונליות לאפליקציות צד שלישי, היא:
- [C-1-1] חייבת לתמוך ב-SocketKeepAlive API.
- [C-1-2] חייבת להיות תמיכה בלפחות חריץ מודעה אחד בו-זמנית לפחות ברשת סלולרית.
- [C-1-3] חייבת לתמוך בכמה שיותר משבצות שידור פעילות סלולריות בו-זמנית נתמך על ידי HAL של רדיו סלולרי.
- [C-SR-1] מומלץ מאוד לתמוך בלפחות שלושה חיישנים של רשת סלולרית משבצות לכל מופע רדיו.
אם יישומי המכשיר לא כוללים תמיכה בהורדה של עומסי עבודה ברשת סלולרית, הם:
- [C-2-1] חייב להחזיר ERROR_UNSUPPORTED.
7.4.2. IEEE 802.11 (Wi-Fi)
הטמעות מכשירים:
- היא צריכה לכלול תמיכה עבור צורה אחת או יותר של 802.11.
אם הטמעות המכשירים כוללות תמיכה ב-802.11 וחושפים את פונקציונליות באפליקציה של צד שלישי:
- [C-1-1] חובה להטמיע את Android API התואם.
- [C-1-2] חובה לדווח על הדגל של תכונת החומרה
android.hardware.wifi
. - [C-1-3] חובה להטמיע את multicast API כפי שמתואר במסמכי התיעוד של ה-SDK.
- [C-1-4] חייב לתמוך ב-DNS מרובה-מכשירים (mDNS) ואסור לסנן חבילות mDNS
(224.0.0.251) בכל זמן של הפעילות, כולל:
- גם כשהמסך לא במצב פעיל.
- להטמעות של מכשירי Android TV, גם במצב המתנה למצבי הכוחות.
- [C-1-5] אסור לטפל ב
WifiManager.enableNetwork()
הקריאה לשיטת ה-API כאינדיקציה מספקת לשינוי המצב הפעיל הנוכחיNetwork
שמשמש כברירת מחדל לתנועת אפליקציות, ומוחזר מאתConnectivityManager
שיטות API כמוgetActiveNetwork
וגםregisterDefaultNetworkCallback
. במילים אחרות, הם עשויים להשבית רק את הגישה לאינטרנט שמסופקת על ידי מישהו ספק רשת אחר (למשל, חבילת גלישה) אם הוא אימת בהצלחה שרשת ה-Wi-Fi מספקת גישה לאינטרנט. - [C-1-6] מומלץ מאוד במקרים שבהם
ConnectivityManager.reportNetworkConnectivity()
נקראת 'שיטת ה-API', בדקו מחדש את הגישה לאינטרנט בNetwork
. ברגע שההערכה קובעת שה-Network
הנוכחי לא מספק יותר גישה לאינטרנט, מעבר לכל רשת זמינה אחרת (למשל, רשת סלולרית שמספק גישה לאינטרנט. - [C-1-7] כתובת ה-MAC של המקור ומספר הרצף של גליל המכשיר צריכים להיות אקראיים בקשות למסגרות זמן, פעם אחת בתחילת כל סריקה, בזמן ש-STA מנותק.
- [C-1-8] חובה להשתמש בכתובת MAC עקבית אחת (לא צריכה להיות כתובת MAC אקראית כתובת באמצע הסריקה).
- [C-1-9] מספר הרצף של בקשת הבדיקה חייב לחזור כרגיל (ברציפות) בין בקשות גשושיות בסריקה.
- [C-1-10] מספר הרצף של בקשת גשושית הבדיקה צריך להיות אקראי בין גשוש האחרון לבקשת סריקה ובקשת גשושית הסריקה הראשונה של הסריקה הבאה.
- [C-SR-1] מומלץ מאוד להגדיר באקראי את כתובת ה-MAC של המקור
את כל התקשורת מסוג STA לנקודת גישה (AP) בזמן השיוך
שמשויכים לכל אחד.
- המכשיר חייב להשתמש בכתובת MAC אקראית שונה לכל SSID (FQDN ל-Passpoint) היא מתקשרת.
- המכשיר חייב לספק למשתמש אפשרות לשלוט רנדומיזציה לפי SSID (FQDN ל-Passpoint) ללא אקראיות אפשרויות אקראיות, וחייב להגדיר את מצב ברירת המחדל עבור רשתות Wi-Fi חדשות להגדרות אקראיות.
- [C-SR-2] מומלץ מאוד להשתמש ב-BSSID אקראי לכל AP שהם
יוצרים.
- כתובת ה-MAC חייבת להיות אקראית ותישמר בהתאם ל-SSID שמשמש את AP.
- ייתכן שה-DEVICE יכול לספק למשתמש אפשרות להשבית את התכונה הזו. אם קיימת אפשרות כזו, הרנדומיזציה חייבת להיות מופעלת כברירת מחדל.
אם הטמעות המכשיר כוללות תמיכה במצב חיסכון בסוללה ב-Wi-Fi, כפי שהוגדר בתקן IEEE 802.11 הן:
- יש להשבית את מצב החיסכון בסוללה ב-Wi-Fi בכל פעם שמתקבלת אפליקציה
מנעול אחד (
WIFI_MODE_FULL_HIGH_PERF
) או מנעולWIFI_MODE_FULL_LOW_LATENCY
דרךWifiManager.createWifiLock()
ו-WifiManager.WifiLock.acquire()
ממשקי ה-API והנעילה פעילים. - [C-3-2] זמן האחזור הממוצע בין המכשיר הלוך ושוב
ונקודת גישה כשהמכשיר נמצא בנעילת Wi-Fi עם זמן אחזור נמוך
המצב (
WIFI_MODE_FULL_LOW_LATENCY
) חייב להיות קטן יותר מהמצב זמן אחזור במהלך מצב 'נעילת ביצועים גבוהה' ב-Wi-Fi (WIFI_MODE_FULL_HIGH_PERF
). - [C-SR-3] מומלץ מאוד למזער את זמן האחזור בנסיעה הלוך ושוב של Wi-Fi
בכל פעם שמתקבלת נעילה של זמן אחזור קצר (
WIFI_MODE_FULL_LOW_LATENCY
) ונכנס לתוקף.
אם הטמעות המכשיר תומכות ב-Wi-Fi ומשתמשים ב-Wi-Fi לסריקת מיקום, הם:
- [C-2-1] חובה לספק למשתמשים אפשרות להפעיל או להשבית את הערך שנקרא
דרך
WifiManager.isScanAlwaysAvailable
שיטת ה-API.
7.4.2.1. Wi-Fi ישיר
הטמעות מכשירים:
- אמורה לכלול תמיכה ב-Wi-Fi ישיר (Wi-Fi מקצה לקצה).
אם הטמעות המכשירים כוללות תמיכה ב-Wi-Fi ישיר:
- [C-1-1] חובה להטמיע את Android API התואם כפי שמתואר במסמכי התיעוד של ה-SDK.
- [C-1-2] חובה לדווח על תכונת החומרה
android.hardware.wifi.direct
. - [C-1-3] חייבת להיות תמיכה בפעולת Wi-Fi רגילה.
- [C-1-4] חובה לתמוך בפעולות Wi-Fi ו-Wi-Fi ישיר בו-זמנית.
- [C-SR-1] מומלץ מאוד להגדיר באקראי את כתובת ה-MAC של המקור לכולם חיבורי Wi-Fi ישיר שנוצרו לאחרונה.
7.4.2.2. הגדרת קישור ישיר במנהרת Wi-Fi
הטמעות מכשירים:
- צריכה לכלול תמיכה ב הגדרת קישור ישיר במנהרת Wi-Fi (TDLS) כפי שמתואר בתיעוד של Android SDK.
אם הטמעות המכשירים כוללות תמיכה ב-TDLS וב-TDLS מופעל על ידי ב-WiFiManager API, הם:
- [C-1-1] חובה להצהיר על תמיכה ב-TDLS עד
WifiManager.isTdlsSupported
. - יש להשתמש ב-TDLS רק כאשר זה אפשרי ומועיל.
- חייבת להיות עם קצת היוריסטיקה ולא להשתמש ב-TDLS כשהביצועים שלה עשויים להיות יותר גרוע מאשר לעבור דרך נקודת הגישה ל-Wi-Fi.
7.4.2.3. עם חיבור ל-Wi-Fi
הטמעות מכשירים:
- צריכה לכלול תמיכה ב-Wi-Fi Aware.
אם הטמעות המכשירים כוללות תמיכה ב-Wi-Fi Aware וחושפים את פונקציונליות של אפליקציות צד שלישי, ואז:
- [C-1-1] חובה להטמיע את ממשקי ה-API של
WifiAwareManager
כפי שמתואר מסמכי התיעוד של ה-SDK. - [C-1-2] חובה להצהיר על דגל התכונה
android.hardware.wifi.aware
. - [C-1-3] חובה לתמוך בפעולות Wi-Fi ו-Wi-Fi Aware בו-זמנית.
- [C-1-4] הכתובת של ממשק הניהול עם מודעות ל-Wi-Fi צריכה להיות אקראית במרווחי זמן שונים לא יותר מ-30 דקות ובכל פעם ש-Wi-Fi Aware מופעל, אלא אם תג Aware פעולת הטווח מתבצעת או שנתיב נתונים של Aware פעיל (האקראי לא פועל צפוי כל עוד נתיב הנתונים פעיל).
אם ההטמעות במכשירים כוללות תמיכה ב-Wi-Fi Aware וגם מיקום Wi-Fi כפי שמתואר בסעיף 7.4.2.5 חושפת את הפונקציות האלה לאפליקציות צד שלישי, ואז:
- [C-2-1] חובה להטמיע את ממשקי ה-API של גילוי מבוסס-מיקום: setRangingEnabled, setMinDestinationMm, setMaxDestinationMm , וגם onServiceDiscoveredWithinRange.
7.4.2.4. Passpoint ל-Wi-Fi
אם הטמעות המכשירים כוללות תמיכה ברשת Wi-Fi 802.11:
- [C-1-1] חייבת לכלול תמיכה ב-Wi-Fi Passpoint.
- [C-1-2] חובה להטמיע את ממשקי ה-API מסוג
WifiManager
שקשורים ל-Passpoint, בתור כפי שמתואר במסמכי התיעוד של ה-SDK. - [C-1-3] חייבת לתמוך בתקן IEEE 802.11u, באופן ספציפי לחיפוש ולבחירה ברשת, למשל בפרסומות כלליות Service (GAS) ו-Access Network Query Protocol (ANQP).
- [C-1-4] חובה להצהיר על דגל הפיצ'ר
android.hardware.wifi.passpoint
. - [C-1-5] חובה לפעול לפי הטמעת ה-AOSP כדי לגלות, להתאים ולשייך לרשתות Passpoint.
- [C-1-6] חייבת להיות תמיכה לפחות בקבוצת המשנה הבאה של הקצאת מכשירים פרוטוקולים כפי שמוגדרים ב-Wi-Fi Alliance Passpoint R2: EAP-TTLS ו-SOAP-XML.
- [C-1-7] חובה לעבד את אישור שרת AAA כפי שמתואר ב- מפרט של נקודה לשיתוף אינטרנט 2.0 R3.
- [C-1-8] חובה לתמוך בשליטה על הקצאת ההרשאות של המשתמשים באמצעות בורר ה-Wi-Fi.
- [C-1-9] חובה לשמור על הגדרות אישיות של Passpoint בכל הפעלה מחדש.
- [C-SR-1] מומלץ מאוד לתמוך בתנאים ובהגבלות של תכונת הקבלה.
- [C-SR-2] אנחנו ממליצים מאוד לתמוך בפיצ'ר המידע על המקום.
אם קיים מתג Passpoint גלובלי להשבתה של הרשאות המשתמשים, ההטמעות:
- [C-3-1] חייבים להפעיל את Passpoint כברירת מחדל.
7.4.2.5. מיקום Wi-Fi (שעת הלוך ושוב של Wi-Fi – RTT)
הטמעות מכשירים:
- צריכה לכלול תמיכה במיקום Wi-Fi.
אם הטמעות המכשיר כוללות תמיכה במיקום ה-Wi-Fi וחושפים את פונקציונליות של אפליקציות צד שלישי, ואז:
- [C-1-1] חובה להטמיע את ממשקי ה-API של
WifiRttManager
כפי שמתואר מסמכי התיעוד של ה-SDK. - [C-1-2] חובה להצהיר על דגל התכונה
android.hardware.wifi.rtt
. - [C-1-3] כתובת ה-MAC של המקור חייבת להיות אקראית לכל רצף RTT שמתבצע כאשר ממשק ה-Wi-Fi שבו ה-RTT מופעל לא משויך לנקודת גישה (APN).
- [C-1-4] חייב להיות מדויק בטווח של 2 מטרים ברוחב פס של 80MHz בשלב ה-68 אחוזון (כפי שחושב באמצעות פונקציית ההתפלגות Cumulative).
- [C-SR-1] מומלץ מאוד לדווח על כך באופן מדויק בטווח של 1.5 מטרים ברוחב פס של 80MHz באחוזון 68 (כפי שמחושב באמצעות פונקציית ההתפלגות המצטברת).
7.4.2.6. הסרה של Keepalive ב-Wi-Fi
הטמעות מכשירים:
- צריכה לכלול תמיכה בהורדה של עומסי Keepalive ב-Wi-Fi.
אם יישומי המכשיר כוללים תמיכה בהורדה של עומסי Keepalive ל-Wi-Fi והם חושפים את הפונקציונליות לאפליקציות צד שלישי:
- [C-1-1] חייבת לתמוך ב-API של SocketKeepAlive.
- [C-1-2] חייבת להיות תמיכה לפחות בשלוש משבצות שידור חי בו-זמנית בחיבור Wi-Fi.
אם יישומי המכשיר לא כוללים תמיכה בהורדה של עומסי חיים ב-Wi-Fi, הם:
- [C-2-1] חייב להחזיר
ERROR_UNSUPPORTED
.
7.4.2.7. Wi-Fi Easy Connect (פרוטוקול להקצאת מכשירים)
הטמעות מכשירים:
- צריכה לכלול תמיכה ב-Wi-Fi Easy Connect (DPP).
אם יישומי המכשיר כוללים תמיכה ב-Wi-Fi Easy Connect וחושפים את פונקציונליות של אפליקציות צד שלישי:
- [C-1-1] חובה להוסיף את הפרמטר Wi-Manager#isEasyConnectSupported()
השיטה מחזירה
true
.
7.4.2.8. אימות אישור של שרת Wi-Fi ארגוני
אם האישור של שרת ה-Wi-Fi לא מאומת או אם שרת ה-Wi-Fi לא מאומת שם דומיין לא הוגדר, הטמעות מכשירים:
- [C-SR-1] מומלץ מאוד לא לספק למשתמש אפשרות הוספה ידנית של רשת Wi-Fi ארגונית באפליקציית ההגדרות.
7.4.2.9. אמון בשימוש הראשון (TOFU)
אם בהטמעות במכשירים יש תמיכה במהימנות בשימוש הראשון (TOFU) מאפשרות למשתמש לקבוע הגדרות WPA/WPA2/WPA3-Enterprise, ואז:
- [C-4-1] חובה לספק למשתמש אפשרות לבחור להשתמש ב-TOFU.
7.4.3. Bluetooth
אם בהטמעות של המכשיר יש תמיכה בפרופיל Bluetooth Audio, הן:
- צריכה לתמוך ברכיבי קודק אודיו מתקדמים ובקודקי אודיו של Bluetooth (למשל, LDAC) עם A2DP.
אם בהטמעות במכשירים יש תמיכה ב-HFP, ב-A2DP וב-AVRCP:
- צריכה לתמוך בלפחות 5 מכשירים מחוברים בסך הכול.
אם על הטמעות המכשיר מוצהר על android.hardware.vr.high_performance
הם:
- [C-1-1] חייבת להיות תמיכה ב-Bluetooth 4.2 ובתוסף אורך נתונים LE של Bluetooth LE.
ב-Android יש תמיכה ב-Bluetooth וב-Bluetooth עם צריכת אנרגיה נמוכה.
אם ההטמעות של המכשיר כוללות תמיכה ב-Bluetooth וב-Bluetooth עם צריכת אנרגיה נמוכה, הם:
- [C-2-1] חובה להצהיר על תכונות הפלטפורמה הרלוונטיות
(
android.hardware.bluetooth
וגםandroid.hardware.bluetooth_le
בהתאמה) ולהטמיע את ממשקי ה-API של הפלטפורמה. - צריך להטמיע פרופילים רלוונטיים של Bluetooth כמו A2DP, AVRCP, OBEX, HFP וכו', בהתאם למכשיר.
אם הטמעות במכשירים כוללות תמיכה ב‐Bluetooth Low Energy (BLE), הן:
- [C-3-1] חובה להצהיר על תכונת החומרה
android.hardware.bluetooth_le
. - [C-3-2] חובה להפעיל Bluetooth (פרופיל מאפיינים גנרי) שמבוסס על GATT ממשקי API כפי שמתואר במסמכי התיעוד של ה-SDK android.bluetooth
- [C-3-3] חובה לדווח על הערך הנכון עבור
BluetoothAdapter.isOffloadedFilteringSupported()
כדי לציין אם לוגיקת הסינון של ScanFilter מחלקות API מוטמעות. - [C-3-4] חובה לדווח על הערך הנכון עבור
BluetoothAdapter.isMultipleAdvertisementSupported()
כדי לציין אם יש תמיכה בפרסום עם צריכת אנרגיה נמוכה. - [C-3-5] חובה להטמיע זמן קצוב לתפוגה של כתובת פרטית (RPA) שניתנת לפתרון כדי להגן על פרטיות המשתמש, צריך לבצע רוטציה לכתובת URL במשך יותר מ-15 דקות בזמן הקצוב לתפוגה. כשהמכשיר משתמש ב-BLE באופן פעיל לסריקה או פרסום. כדי למנוע התקפות תזמון, פרקי זמן קצובים לתפוגה חייבים להיות אקראיים גם כן בין 5 ל-15 דקות
- צריכה לתמוך בהסרה של לוגיקת הסינון לערכת השבבים של Bluetooth כשמטמיעים את ScanFilter API.
- אמורה לתמוך בהסרה של הסריקה המקובצת לערכת השבבים של Bluetooth.
- צריכה לתמוך במודעות מרובות עם 4 מיקומים לפחות.
אם בהטמעות המכשיר תומכים ב-Bluetooth LE ומשתמשים ב-Bluetooth LE בשביל סריקת מיקום, הם:
- [C-4-1] חובה לספק למשתמשים אפשרות להפעיל או להשבית את הערך שנקרא
באמצעות System API
BluetoothAdapter.isBleScanAlwaysAvailable()
.
אם ההטמעות של המכשיר כוללות תמיכה ב-Bluetooth LE ובמכשירי שמיעה פרופיל, כפי שמתואר ב שירותי תמיכה באודיו למכשירי שמיעה באמצעות Bluetooth LE:
- [C-5-1] חייב להחזיר
true
למשך BluetoothAdapter.getProfileProxy(context, Listener, BluetoothProfile.HEARING_AID).
אם ההטמעות של המכשיר כוללות תמיכה ב-Bluetooth או ב-Bluetooth עם צריכת אנרגיה נמוכה, הם:
- [C-6-1] חובה להגביל את הגישה למטא-נתונים של Bluetooth (כמו סריקה)
תוצאות) שניתן להשתמש בהן כדי להסיק את מיקום המכשיר, אלא אם
האפליקציה ששלחה את הבקשה מעבירה בהצלחה
android.permission.ACCESS_FINE_LOCATION
על סמך המצב הנוכחי של החזית/הרקע.
אם ההטמעות של המכשיר כוללות תמיכה ב-Bluetooth או ב-Bluetooth עם צריכת אנרגיה נמוכה קובץ המניפסט של האפליקציה לא כולל הצהרה מהמפתח, שהם לא מפיקים מיקום מ-Bluetooth, ואז:
- [C-6-2] חובה להוסיף שער לגישת Bluetooth מאחורי
android.permission.ACCESS_FINE_LOCATION
.
אם הטמעות המכשיר מחזירות את הערך true
עבור
BluetoothAdapter.isLeAudioSupported()
API, ואז:
- [C-7-1] חייבת לתמוך בלקוח unicast.
- [C-7-2] חייבת לתמוך ב-2M PHY.
- [C-7-3] חייבת לתמוך בפרסום LE Extended.
- [C-7-4] חייבת להיות תמיכה לפחות בשני חיבורי CIS ב-CIG.
- [C-7-5] חובה להפעיל לקוח BAP unicast, מתאם הגדרות CSIP, שרת MCP, בקר VCP ושרת CCP בו-זמנית.
- [C-SR-1] מומלץ מאוד להפעיל לקוח HAP בפורמט unicast.
אם הטמעות המכשיר מחזירות את הערך true
עבור
BluetoothAdapter.isLeAudioBroadcastSourceSupported()
API, ואז:
- [C-8-1] חייבת לתמוך לפחות בשני קישורי BIS בנכס BIS.
- [C-8-2] חייבים להפעיל את מקור השידור BAP, עוזר השידור של BAP בו-זמנית.
- [C-8-3] חייבת לתמוך בפרסום תקופתי של LE.
אם הטמעות המכשיר מחזירות את הערך true
עבור
BluetoothAdapter.isLeAudioBroadcastAssistantSupported()
API, ואז:
- [C-9-1] חייבת להיות תמיכה ב-PAST (העברה תקופתית של סנכרון הפרסום).
- [C-9-2] חייבת לתמוך בפרסום תקופתי של LE.
אם הטמעות המכשירים מצהירות על FEATURE_BLUETOOTH_LE
, הן:
- [C-10-1] מדידות RSSI צריכות להיות בטווח של +/-9dB עבור 95%
מדדים במרחק של מטר ממכשיר עזר שמשודר
ADVERTISE_TX_POWER_HIGH
בקו הראייה. - [C-10-2] חובה לכלול תיקונים בפורמט Rx/Tx כדי לצמצם את הסטיות בכל ערוץ כך שהמדידות בכל אחד משלושת הערוצים, בכל אחת מהאנטנות (אם משתמשים מרובים), נמצאים בטווח של +/-3dB אחד מהשני למשך 95% מדידות.
- [C-SR-2] מומלץ מאוד למדוד קיזוזים של Rx ולפצות אותם
יש לוודא שה-RSSI החציוני של BLE הוא -60dBm +/-10dB במרחק של 1 מטר
מכשיר העזר משדר ב-
ADVERTISE_TX_POWER_HIGH
, שבו המכשירים כך שהם נמצאים ב'מישורים מקבילים' עם מסכים הפונים לאותו כיוון לכיוון מסוים. - [C-SR-3] מומלץ מאוד למדוד קיזוזים של Tx ולפצות אותם
מוודאים שה-RSSI החציוני של BLE הוא -60dBm +/-10dB בסריקה מהפניה
המכשיר נמצא במרחק של מטר אחד ומשדר ב:
ADVERTISE_TX_POWER_HIGH
, כאשר המכשירים מכוונים באופן שבו הם פועלים 'מישורים מקבילים' במסכים שפונים לאותו כיוון.
מומלץ מאוד לבצע את השלבים להגדרת המדידה שמפורטים כיול הנוכחות.
אם הטמעות המכשיר תומכות בגרסה 5.0 של Bluetooth:
- [C-SR-4] מומלץ מאוד לספק תמיכה לגבי:
- LE 2M PHY
- LE Codec PHY
- תוסף LE Advertising
- פרסום תקופתי
- לפחות 10 קבוצות מודעות
- לפחות 8 חיבורי LE בו-זמנית. כל חיבור יכול להיות בכל לטופולוגיה של החיבור.
- הפרטיות של שכבת הקישור של LE
- 'רשימת פתרון' בגודל של 8 רשומות לפחות
7.4.4. תקשורת מטווח קצר
הטמעות מכשירים:
- אמורה לכלול משדר וחומרה קשורה לקלט-טווח קצר תקשורת (NFC).
- [C-0-1] חובה להטמיע את
android.nfc.NdefMessage
וגםandroid.nfc.NdefRecord
ממשקי API, גם אם הם לא כוללים תמיכה ב-NFC או להצהיר על התכונהandroid.hardware.nfc
כי המחלקות מייצגות פורמט ייצוג נתונים שאינו תלוי בפרוטוקול.
אם ההטמעות של המכשירים כוללות חומרת NFC ומתכננים להפוך אותה לזמינה עבור באפליקציות צד שלישי:
- [C-1-1] חובה לדווח על התכונה
android.hardware.nfc
android.content.pm.PackageManager.hasSystemFeature()
method. - חייבת להיות יכולת לקרוא ולכתוב הודעות NDEF באמצעות ה-NFC הבא כפי שמפורט בהמשך:
- [C-1-2] צריכה להיות יכולת לפעול כקורא/כותב בפורום NFC
(כפי שמוגדר במפרט הטכני של פורום NFC
NFCForum-TS-DigitalProtocol-1.0) באמצעות תקני NFC הבאים:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- סוגי התגים של פורום NFC 1, 2, 3, 4, 5 (הוגדרו על ידי פורום NFC)
[C-SR-1] מומלץ מאוד להיות מסוגל לקרוא ולכתוב NDEF הודעות וגם נתונים גולמיים באמצעות תקני NFC הבאים. שימו לב למרות שתקני ה-NFC מפורטים כמומלץ מאוד, אנחנו מתכננים לשנות את הגדרת התאימות לגרסה עתידית חייבים. הסטנדרטים האלה הם אופציונליים בגרסה הזו, אבל הם נדרשים בגרסאות עתידיות. מכשירים קיימים וחדשים שבהם פועלת הגרסה הזו של אנחנו ממליצים מאוד ל-Android לעמוד בדרישות האלה עכשיו, הם יוכלו לשדרג לגרסאות עתידיות של הפלטפורמה.
[C-1-13] חובה לבצע סקר לכל הטכנולוגיות הנתמכות בזמן גילוי NFC במצב תצוגה.
אמור להיות במצב גילוי NFC כשהמכשיר לא במצב שינה עם שהמסך פעיל ונעילת המסך בוטלה.
צריכה להיות מסוגלת לקרוא את הברקוד ואת כתובת האתר (אם מקודדת) של ברקוד NFC של Thinfilm מוצרים.
לתשומת ליבכם: קישורים שזמינים באופן ציבורי לא זמינים ל-JIS, ל-ISO ול-NFC מפרטי הפורום שהוזכרו למעלה.
מערכת Android כוללת תמיכה במצב NFC Host Card Emulation (HCE).
אם הטמעות המכשיר כוללות ערכת שבבים של בקר NFC שמסוגלת לבצע HCE (עבור NfcA ו/או NfcB) ותומכות בניתוב מזהה אפליקציה (AID), הן:
- [C-2-1] חובה לדווח על קבוע התכונה
android.hardware.nfc.hce
. - [C-2-2] חייבת לתמוך בממשקי API של NFC HCE בתור שמוגדר ב-Android SDK.
אם הטמעות המכשיר כוללות ערכת שבבים של בקר NFC שמסוגלת לבצע HCE ב-NfcF, ומטמיעים את התכונה באפליקציות צד שלישי:
- [C-3-1] חובה לדווח על קבוע התכונה
android.hardware.nfc.hcef
. - [C-3-2] חובה להטמיע את ממשקי ה-API של האמולציה של כרטיסי NfcF כפי שמוגדר ב-Android SDK.
אם יישומים של מכשירים כוללים תמיכה כללית ב-NFC, כפי שמתואר קטע ותמיכה בטכנולוגיות MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF ב-MIFARE Classic) בתפקיד קורא/כתיבה,
- [C-4-1] חובה להטמיע את ממשקי ה-API התואמים של Android כפי שתועד על ידי ערכת ה-SDK של Android.
- [C-4-2] חובה לדווח על התכונה
com.nxp.mifare
android.content.pm.PackageManager.hasSystemFeature
() . לתשומת ליבך, זוהי לא תכונה רגילה של Android, ולכן אין מופיעים כקבוע במחלקהandroid.content.pm.PackageManager
.
7.4.5. פרוטוקולים וממשקי API של רשתות
7.4.5.1. קיבולת רשת מינימלית
הטמעות מכשירים:
- [C-0-1] חייבת לכלול תמיכה באחד או יותר מסוגי רשת נתונים. באופן ספציפי, הטמעות מכשירים חייבות לכלול תמיכה לפחות תקן נתונים אחד עם מהירות של 200 Kbit לשנייה או יותר. דוגמאות של טכנולוגיות שעומדות בדרישה הזו כוללות את EDGE, HSPA, EV-DO, 802.11g, אתרנט ו-Bluetooth PAN.
- היא צריכה לכלול גם תמיכה בנתונים אלחוטיים נפוצים לפחות רגיל, כמו 802.11 (Wi-Fi), כאשר תקן רשת פיזי (כמו אתרנט) הוא חיבור הנתונים הראשי.
- ייתכן שתטמיעו יותר מצורה אחת של קישוריות נתונים.
7.4.5.2. IPv6
הטמעות מכשירים:
- [C-0-2] חובה לכלול סטאק רשתות של IPv6 ולתמוך ב-IPv6
תקשורת באמצעות ממשקי ה-API המנוהלים, כמו
java.net.Socket
java.net.URLConnection
, וגם ממשקי ה-API המקוריים, כמוAF_INET6
שקעים. - [C-0-3] חייבים להפעיל את IPv6 כברירת מחדל.
- חייבים לוודא שתקשורת IPv6 אמינה כמו IPv4, לדוגמה:
- [C-0-4] חייבים לשמור על קישוריות IPv6 במצב 'נמנום'.
- [C-0-5] הגבלת הקצב של יצירת הבקשות חייבת לא לגרום למכשיר לאבד את IPv6 בכל רשת תואמת ל-IPv6 שמשתמשת בטווחי חיים RA באורך של 180 שניות לפחות.
- חייבים לוודא שתקשורת IPv6 אמינה כמו IPv4, לדוגמה:
- [C-0-6] חובה לספק אפליקציות של צד שלישי עם קישוריות IPv6 ישירה
לרשת כאשר הוא מחובר לרשת IPv6, ללא כתובת או
תרגום ליציאה המתרחשת באופן מקומי במכשיר. שני ממשקי API מנוהלים כמו
Socket#getLocalAddress
אוSocket#getLocalPort
) ו-NDK API כמוgetsockname()
אוIPV6_PKTINFO
חייבים להחזיר את כתובת ה-IP הכתובת והיציאה המשמשים בפועל לשליחה ולקבלה של חבילות, רשת וניתן לראות אותה ככתובת ה-IP המקורית וכיציאה לשרתי אינטרנט (אינטרנט).
הרמה הנדרשת של תמיכה ב-IPv6 תלויה בסוג הרשת, כפי שמוצג ב- בדרישות הבאות.
אם הטמעות במכשירים תומכים ב-Wi-Fi:
- [C-1-1] חייבת לתמוך בפעולה כפולה בסטאק וב-IPv6 בלבד ב-Wi-Fi.
אם בהטמעות במכשירים תומכים באתרנט:
- [C-2-1] חייבת לתמוך ב-Dual-stack וב-IPv6 בלבד ב- אתרנט.
אם הטמעות במכשירים תומכים בחבילת הגלישה, הן:
- [C-3-1] חייבת לתמוך בפעולת IPv6 (IPv6 בלבד ואולי גם סטאק כפול) ב- סלולרי.
אם הטמעות במכשירים תומכים ביותר מסוג רשת אחד (למשל, Wi-Fi וחבילת הגלישה), הן:
- [C-4-1] האפליקציה חייבת לעמוד בו-זמנית בדרישות שצוינו למעלה בכל רשת כשהמכשיר מחובר בו-זמנית ליותר מסוג אחד של רשת.
7.4.5.3. פורטלים שבויים
פורטל שבוי מתייחס לרשת שמחייבת כניסה כדי לקבל גישה לאינטרנט.
אם הטמעות המכשירים מספקות הטמעה מלאה של
android.webkit.Webview API
הם:
- [C-1-1] חובה לספק אפליקציית פורטל שבוי כדי לטפל בכוונה
ACTION_CAPTIVE_PORTAL_SIGN_IN
ולהציג את דף ההתחברות לפורטל שבוי, על ידי שליחת הכוונה הזו, קריאה ל-System APIConnectivityManager#startCaptivePortalApp(Network, Bundle)
- [C-1-2] חובה לבצע זיהוי של פורטלים שבויים והתחברות לתמיכה דרך אפליקציית פורטל שבוי כשהמכשיר מחובר לכל סוג רשת, כולל רשת סלולרית/נייד, Wi-Fi, אתרנט או Bluetooth.
- [C-1-3] חייבת להיות תמיכה בהתחברות לפורטלים שבויים באמצעות DNS ללא טקסט חופשי כשהמכשיר מוגדר לשימוש במצב מחמיר של DNS פרטי.
- [C-1-4] חובה להשתמש ב-DNS מוצפן בהתאם למסמכי התיעוד של ה-SDK עבור
android.net.LinkProperties.getPrivateDnsServerName
ו-android.net.LinkProperties.isPrivateDnsActive
לגבי כל התנועה ברשת שלא מתקשרת במפורש עם הוא פורטל שבוי. - [C-1-5] חייבים לוודא שבזמן שהמשתמש מתחבר למכשיר שבוי
פורטל, רשת ברירת המחדל המשמשת את האפליקציות (כפי שהוחזר על ידי
ConnectivityManager.getActiveNetwork
ConnectivityManager.registerDefaultNetworkCallback
, ומשמשים כברירת מחדל על ידי ממשקי API של רשתות Java כגון java.net.Socket, וממשקי API מקוריים כמו Connect() ) הם כל רשת זמינה אחרת שמספקת גישה לאינטרנט, אם היא זמינה.
7.4.6. הגדרות סנכרון
הטמעות מכשירים:
- [C-0-1] הגדרת הסנכרון האוטומטי הראשי חייבת להיות מופעלת כברירת מחדל, כדי
השיטה
getMasterSyncAutomatically()
הפונקציה מחזירה 'true'.
7.4.7. חסכונית בנתונים
אם הטמעות המכשירים כוללות חיבור עם חיוב לפי שימוש בנתונים:
- [C-SR-1] מומלץ מאוד לספק את מצב חוסך הנתונים (Data Saver).
אם הטמעות במכשירים מספקות את מצב חוסך הנתונים, הן:
- [C-1-1] חייבת לתמוך בכל ממשקי ה-API ב-
ConnectivityManager
כפי שמתואר בתיעוד ה-SDK
אם הטמעות במכשירים לא מספקות את מצב חוסך הנתונים, הן:
- [C-2-1] חייב להחזיר את הערך
RESTRICT_BACKGROUND_STATUS_DISABLED
עבורConnectivityManager.getRestrictBackgroundStatus()
- [C-2-2] אסור לשדר
ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
7.4.8. רכיבים מאובטחים
אם הטמעות במכשירים תומכים ב-Open Mobile API והפיכתם לזמינים לאפליקציות צד שלישי, הם:
[C-1-1] חובה לציין את הפרטים של קוראי הרכיבים המאובטחים הזמינים באמצעות
android.se.omapi.SEService.getReaders()
API.[C-1-2] חובה להצהיר על התכונות הניסיוניות הנכונות דרך
android.hardware.se.omapi.uicc
למכשיר עם רכיבים מאובטחים שמבוססים על UICC.android.hardware.se.omapi.ese
עבור המכשיר עם רכיבים מאובטחים מבוססי eSEandroid.hardware.se.omapi.sd
עבור המכשיר באמצעות רכיבים מאובטחים מבוססי SD.
7.4.9. UWB
אם הטמעות המכשיר כוללות תמיכה ב-802.1.15.4 וחושפים את באפליקציה של צד שלישי, ואז:
- [C-1-1] חובה להטמיע את ממשק ה-API התואם של Android ב-android.uwb.
- [C-1-2] חובה לדווח על הדגל של תכונת החומרה android.hardware.uwb.
- [C-1-3] חייבת להיות תמיכה בכל פרופילי UWB הרלוונטיים שמוגדרים ב-Android יישום בפועל.
- [C-1-4] חובה לספק למשתמש מחיר כניסה כדי לאפשר לו להחליף מצב של UWB הפעלה/כיבוי של הרדיו.
- [C-1-5] חובה לאכוף את הדרישה שלפיה אפליקציות שמשתמשות ברדיו UWB יחזיקו בהרשאת UWB_RANGING (בקבוצת ההרשאות NEARBY_ devices).
[C-SR-1] מומלץ מאוד לעבור את התאימות הרלוונטית בחינות הסמכה שהוגדרו על ידי ארגונים סטנדרטיים, כולל FIRA, CCC ו-CSA.
- [C-1-6] חובה לוודא שמידות המרחק הן בטווח של 95%-/ + ס"מ מהמדידות בסביבת קו הראייה במרחק של מטר אחד תא מחזיר אור.
- [C-1-7] חובה לוודא שהחציון של מדידות המרחק הוא 1 מטר ממכשיר העזר נמצא בטווח של [0.75 מטר, 1.25m], ואמת קרקע המרחק נמדד מהקצה העליון של ה-DUT, כשהוא מופנה כלפי מעלה ומוטה 45 מעלות.
- [C-SR-2] מומלץ מאוד לבצע את השלבים להגדרת המדידה צוין ב- כיול הנוכחות.
7.5. מצלמות
אם ההטמעות במכשירים כוללות לפחות מצלמה אחת, הן:
- [C-1-1] חובה להצהיר על דגל התכונה
android.hardware.camera.any
. - [C-1-2] חובה לאפשר לאפליקציה להקצות בו-זמנית שלוש מיפויי סיביות RGBA_8888 שווים לגודל התמונות שנוצרו על ידי חיישן המצלמה ברזולוציה הגבוהה ביותר במכשיר והמצלמה פתוחה של תצוגה מקדימה בסיסית ועדיין לצלם.
- [C-1-3] חובה לוודא שאפליקציית ברירת המחדל של המצלמה הותקנה מראש
טיפול בכוונות
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
, אוMediaStore.ACTION_VIDEO_CAPTURE
, אחראית להסרת מיקום המשתמש במטא-נתונים של התמונה לפני שולחת אותו לאפליקציה המקבלת כאשר האפליקציה המקבלת לא ישACCESS_FINE_LOCATION
.
אם בהטמעות המכשיר תומך ביכולת פלט HDR של 10 ביט:
- [C-2-1] חייבת לתמוך לפחות בפרופיל HLG HDR בכל מכשיר מצלמה שתומך בפלט של 10 ביט.
- [C-2-2] חייבת לתמוך בפלט של 10 ביט עבור המצלמה האחורית הראשית מצלמה קדמית ראשית.
- [C-SR-1] מומלץ מאוד לתמוך בפלט של 10 ביט בשני הערכים מצלמות.
- [C-2-3] חייבים לתמוך באותם פרופילי HDR לכולם מצלמות משנה פיזיות עם יכולות BACKWARD_COMPATIBLE של מצלמה לוגית וגם המצלמה הלוגית עצמה.
למכשירי מצלמות לוגיות שתומכים ב-HDR באיכות 10 ביט עם הטמעה של
android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO
API, is:
- [C-3-1] חייבת להיות תמיכה במעבר בין כל המכשירים הפיזיים שתואמים לאחור
מצלמות באמצעות הפקד
CONTROL_ZOOM_RATIO
במצלמה הלוגית.
7.5.1. מצלמה אחורית
מצלמה אחורית היא מצלמה שממוקמת בצד של המכשיר שנמצא מול המסך. כלומר, היא ממחישה סצנות בקצה הרחוק של כמו מצלמה רגילה.
הטמעות מכשירים:
- צריכה לכלול מצלמה אחורית.
אם ההטמעות במכשירים כוללות לפחות מצלמה אחורית אחת, הן:
- [C-1-1] חובה לדווח על דגל התכונה
android.hardware.camera
וגםandroid.hardware.camera.any
. - [C-1-2] חייבת להיות ברזולוציה של 2 מגה-פיקסלים לפחות.
- יש להטמיע מיקוד אוטומטי בחומרה או מיקוד אוטומטי בתוכנה במנהל ההתקן של המצלמה (שקוף לתוכנת האפליקציה).
- ייתכן שיש בהם חומרה עם מיקוד קבוע או EDOF (עומק שדה מורחב).
- עשויים לכלול הבזק.
אם יש במצלמה פלאש:
- [C-2-1] אסור שמנורת הפלאש תהיה מוארת
מופע אחד (
android.hardware.Camera.PreviewCallback
) נרשם במשטח התצוגה המקדימה של המצלמה, אלא אם האפליקציה הופעלה באופן מפורש של הפלאש על ידי הפעלת המאפייניםFLASH_MODE_AUTO
אוFLASH_MODE_ON
של אובייקטCamera.Parameters
. שימו לב שהאילוץ הזה לא חל על את אפליקציית המצלמה המובנית במכשיר, אבל רק לצד שלישי אפליקציות שמשתמשות ב-Camera.PreviewCallback
.
7.5.2. מצלמה קדמית
מצלמה קדמית היא מצלמה שממוקמת באותו צד של המכשיר בתור התצוגה, כלומר מצלמה שמשמשת בדרך כלל לצילום תמונת המשתמש, כמו שיחות ועידה בווידאו ואפליקציות דומות.
הטמעות מכשירים:
- עשויים לכלול מצלמה קדמית.
אם ההטמעות במכשירים כוללות לפחות מצלמה קדמית אחת:
- [C-1-1] חובה לדווח על דגל התכונה
android.hardware.camera.any
וגםandroid.hardware.camera.front
. - [C-1-2] חייבת להיות רזולוציה של VGA לפחות (640x480 פיקסלים).
- [C-1-3] אסור להשתמש במצלמה קדמית כברירת המחדל ממשק API של מצלמה ואסור להגדיר את ה-API לטיפול במצלמה קדמית בתור מצלמת ברירת המחדל האחורית, גם אם היא המצלמה היחידה במכשיר.
- [C-1-4] חובה לשקף את התצוגה המקדימה של המצלמה לרוחב ביחס
הכיוון שהוגדר על ידי האפליקציה, כשהאפליקציה הנוכחית כוללת
ביקשה באופן מפורש שהמצלמה
את התצוגה באמצעות קריאה
android.hardware.Camera.setDisplayOrientation()
. לעומת זאת, התצוגה המקדימה חייבת להיות משוכפלת לאורך ברירת המחדל של המכשיר. ציר אופקי כאשר האפליקציה הנוכחית לא מבקשת באופן מפורש כדי לסובב את תצוגת המצלמה באמצעות קריאהandroid.hardware.Camera.setDisplayOrientation()
. - [C-1-5] אסור לשקף את התמונה הסופית של תמונת סטילס או וידאו בסטרימינג חזרו לקריאות חוזרות של אפליקציה או מחויבות לאחסון מדיה.
- [C-1-6] חייבת לשקף את התמונה המוצגת לאחר הצפייה באותו אופן בתור שידור התמונות בתצוגה המקדימה של המצלמה.
- עשויים לכלול תכונות (כגון מיקוד אוטומטי, Flash וכו') שזמינות עבור מצלמות אחוריות, כפי שמתואר בסעיף 7.5.1.
אם יש אפשרות לבצע רוטציה של יישומי המכשיר על ידי המשתמש (כמו באופן אוטומטי באמצעות מד תאוצה או באופן ידני באמצעות קלט של משתמשים):
- [C-2-1] התצוגה המקדימה של המצלמה חייבת להיות משוכפלת לרוחב בכיוון הנוכחי של המכשיר.
7.5.3. מצלמה חיצונית
הטמעות מכשירים:
- עשויים לכלול תמיכה במצלמה חיצונית, שלא בהכרח תמיד מחובר.
אם הטמעתי מכשירים כוללים תמיכה במצלמה חיצונית, הם:
- [C-1-1] חובה להצהיר על תכונות הדגל של הפלטפורמה
android.hardware.camera.external
וגםandroid.hardware camera.any
- [C-1-2] חייבת להיות תמיכה ב-USB Video Class (UVC 1.0 ואילך) אם מחשב חיצוני המצלמה מתחברת דרך יציאת האירוח של ה-USB.
- [C-1-3] חובה לעבור בדיקות CTS של המצלמה עם התקן מצלמה חיצוני פיזי מחובר. פרטים על בדיקת CTS של המצלמה זמינים בכתובת source.android.com.
- צריכה לתמוך בדחיסות וידאו כמו MJPEG כדי לאפשר העברה של סטרימינג לא מקודד באיכות גבוהה (כלומר, תמונה גולמית או תמונה דחוסה באופן עצמאי ).
- יכול להיות שתומכות במספר מצלמות.
- ייתכן שתומכת בקידוד וידאו מבוסס מצלמה.
אם יש תמיכה בקידוד וידאו מבוסס מצלמה:
- [C-2-1] בו-זמנית לא מקודד / זרם MJPEG (רזולוציה QVGA או יותר) חייב להיות נגיש ההטמעה של המכשיר.
7.5.4. התנהגות ה-API של המצלמה
ב-Android יש שתי חבילות API שמאפשרות גישה למצלמה, הגרסה החדשה יותר ממשק ה-API של android.hardware.camera2 חושף את בקרת המצלמה ברמה נמוכה לאפליקציה, כולל תהליכים יעילים של רצף/סטרימינג ללא העתקה מוקדמת ובקרות לכל-פריים של חשיפה, רווח, עלייה באיזון לבן, המרת צבעים, הסרת רעשים, חידוד, ועוד.
חבילת ה-API הישנה יותר,android.hardware.Camera
, מסומנת כהוצאה משימוש ב-
גרסה 5.0 של Android, אבל היא עדיין אמורה להיות זמינה לשימוש באפליקציות. מכשיר Android
חייבים להבטיח את המשך התמיכה של ה-API, כפי שמתואר
בקטע הזה וב-Android SDK.
כל התכונות המשותפות לסיווג android.hardware.camera שהוצא משימוש ובחבילה החדשה יותר של android.hardware.camera2 חייבת להיות ביצועים זהים והאיכות של שני ממשקי ה-API. לדוגמה, עם הגדרות מקבילות, המהירות והדיוק של המיקוד האוטומטי חייבים להיות זהים, והאיכות של תמונות שמצלמים צריכים להיות זהים. תכונות שתלויות בסמנטיקה השונה של שני ממשקי ה-API לא נדרשות התאמה של מהירות או איכות, אבל הן צריכות להתאים בדיוק ככל האפשר.
בהטמעות של מכשירים צריך ליישם את ההתנהגויות הבאות ממשקי API הקשורים למצלמות, לכל המצלמות הזמינות. הטמעות מכשירים:
- [C-0-1] חובה להשתמש ב-
android.hardware.PixelFormat.YCbCr_420_SP
לתצוגה מקדימה נתונים שסופקו לקריאות חוזרות של אפליקציה כאשר אפליקציה מעולם לא התקשרהandroid.hardware.Camera.Parameters.setPreviewFormat(int)
. - [C-0-2] חייב להיות בפורמט הקידוד NV21 כשיישום
רושם
android.hardware.Camera.PreviewCallback
והמערכת קוראת ל-methodonPreviewFrame()
ול-Preview הוא YCbCr_420_SP, הנתונים בבייט[] שמועברים אלonPreviewFrame()
. כלומר, NV21 חייבת להיות ברירת המחדל. - [C-0-3] חייב לתמוך בפורמט YV12 (כפי שמצוין על ידי
קבוע של
android.graphics.ImageFormat.YV12
) לתצוגה המקדימה של המצלמה בשני המקומות מצלמות קדמיות ואחוריות עבורandroid.hardware.Camera
. (החומרה המצלמה ומקודד הווידאו עשויים להשתמש בכל פורמט של פיקסל מקורי, אבל ההטמעה חייבת לתמוך בהמרה ל-YV12). - [C-0-4] חייבים לתמוך ב-
android.hardware.ImageFormat.YUV_420_888
שלandroid.hardware.ImageFormat.JPEG
כפלט באמצעות API שלandroid.media.ImageReader
ל-android.hardware.camera2
מכשירים פרסוםREQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE
ב-android.request.availableCapabilities
. - [C-0-5] עדיין צריך להטמיע את ה-API המלא של המצלמה
שכלולות במסמכי התיעוד של Android SDK, גם אם המכשיר לא
כולל מיקוד אוטומטי בחומרה או יכולות אחרות. לדוגמה, מצלמות
ללא מיקוד אוטומטי, עדיין חייב להתקשר
android.hardware.Camera.AutoFocusCallback
מופעים (למרות שאין להם רלוונטיות למצלמה ללא מיקוד אוטומטי.) לתשומת ליבכם: הכלל הזה חל על מצלמות; למשל, למרות שרוב המצלמות הקדמית לא תומכות המיקוד האוטומטי, גם הקריאות החוזרות של ה-API עדיין צריכות להיות 'מזויפות', כפי שמתואר. - [C-0-6] חובה לזהות כל שם של פרמטר ולכבד אותו
מוגדר כקבוע
android.hardware.Camera.Parameters
והכיתהandroid.hardware.camera2.CaptureRequest
. לעומת זאת, אסור שהטמעות מכשירים יפעלו בהתאם לקבועים של מחרוזות או יזהו אותם מועבר ל-methodandroid.hardware.Camera.setParameters()
מלבד אלה מתועדות כקבועים ב-android.hardware.Camera.Parameters
. כלומר, בהטמעות המכשיר חייבות לתמוך בכל הפרמטרים הרגילים של המצלמה, אם מאפשרת חומרה, ואסור שהיא תתמוך בסוגי פרמטרים מותאמים אישית של מצלמה. למשל, הטמעות של מכשירים שתומכים בצילום תמונה באמצעות שיטות הדמיה עם טווח דינמי גבוה (HDR), חייבות לתמוך בפרמטר של המצלמהCamera.SCENE_MODE_HDR
- [C-0-7] חובה לדווח על רמת התמיכה המתאימה באמצעות
android.info.supportedHardwareLevel
כפי שמתואר ב-Android SDK, ולדווח על דגלים של רכיבי framework. - [C-0-8] בנוסף, אנחנו חייבים להצהיר על היכולות של המצלמה הנפרדת שלה
android.hardware.camera2
דרך נכס אחד (android.request.availableCapabilities
) ולהצהיר על דגלי התכונות המתאימים. חובה להגדיר את סימון התכונה אם מכשירי המצלמה המחוברים שלו. תומך בתכונה. - [C-0-9] חובה לשדר את
Camera.ACTION_NEW_PICTURE
בכל פעם שתמונה חדשה צולמה על ידי המצלמה התמונה נוספה לחנות המדיה. - [C-0-10] חובה לשדר את
Camera.ACTION_NEW_VIDEO
של כוונה בכל פעם שסרטון חדש מצולם על ידי המצלמה התמונה נוספה לחנות המדיה. - [C-0-11] כל המצלמות חייבות להיות נגישות דרך
android.hardware.Camera
אפשר לגשת ל-API גם דרךandroid.hardware.camera2
API. - [C-0-12] חובה לוודא שמראה הפנים לא ישתנה, כולל
אך לא רק שינוי בגיאומטריה של הפנים, גוון העור של הפנים או הפנים
החלקת העור בכל סוג של
android.hardware.camera2
אוandroid.hardware.Camera
API. - [C-SR-1] במכשירים עם כמה מצלמות RGB שפונים לאותו כיוון:
מומלץ מאוד לתמוך במכשיר מצלמה לוגי שמפרט
יכולת
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
שמורכבות מכל מצלמות ה-RGB שפונות לכיוון הזה כמכשירי משנה פיזיים.
אם הטמעות המכשיר מספקות API קנייני של מצלמה לאפליקציות צד שלישי, הם:
- [C-1-1] חובה להטמיע ממשק API של מצלמה כזה באמצעות
android.hardware.camera2
API. - עשויים לספק תגים ו/או תוספים של ספק עבור
android.hardware.camera2
API.
7.5.5. כיוון המצלמה
אם בהטמעות המכשיר יש מצלמה קדמית או אחורית, מצלמות כאלה:
- [C-1-1] צריך לכוון את הכיוון של הממד הארוך של המצלמה את המאפיין הארוך של המסך. כלומר, כשמחזיקים את המכשיר בשטח כיוון, המצלמות חייבות לצלם תמונות לרוחב. הזה חל ללא קשר לכיוון הטבעי של המכשיר. כלומר, חלה מכשירים עיקריים בפורמט אופקי וכן מכשירים ראשיים בפריסה לאורך.
מכשירים שעומדים בכל הקריטריונים הבאים פטורים מהדרישה שצוינה למעלה:
- המכשיר מטמיע מסכים עם גיאומטריה משתנה, כמו מסכים מתקפלים או צירים מסכים.
- כשמצב הקיפול או הציר של המכשיר משתנה, המכשיר עובר בין מפורמט לאורך, מהפורמט הראשי לרוחב ומהפך (להפך).
7.6. זיכרון ואחסון
7.6.1. נפח זיכרון ואחסון מינימלי
הטמעות מכשירים:
- [C-0-1] חייב לכלול מנהל ההורדות שייתכן שישמשו את האפליקציות להורדת קובצי נתונים, והן חייבות להיות מסוגלות להוריד קבצים בודדים בגודל של 100MB לפחות לברירת המחדל "מטמון" המיקום.
7.6.2. אחסון משותף באפליקציות
הטמעות מכשירים:
- [C-0-1] חובה להציע נפח אחסון משותף לאפליקציות, שלרוב נקראות גם ' כ'אחסון חיצוני משותף', 'אחסון משותף של אפליקציה' או באמצעות Linux נתיב "/sdcard" שאליו הוא מותקן.
- [C-0-2] חובה להגדיר אחסון משותף שמותקן כברירת מחדל, במכשירים אחרים 'הוצאה מהאריזה', ללא קשר אם האחסון מוטמע ב- רכיב אחסון פנימי או אמצעי אחסון נשלף (למשל, חריץ לכרטיס דיגיטלי).
- [C-0-3] חובה לטעון את האחסון המשותף של האפליקציה ישירות בנתיב Linux
sdcard
או לכלול קישור סימבולי של Linux מ-sdcard
לטעינה בפועל לנקודה. - [C-0-4] חובה להפעיל
נפח אחסון בהיקף
כברירת מחדל לכל
אפליקציות שמטרגטות לרמת API 29 ומעלה, למעט במצבים הבאים:
- מתי האפליקציה ביקשה
android:requestLegacyExternalStorage="true"
במניפסט שלהם.
- מתי האפליקציה ביקשה
- [C-0-5] חובה לצנזר מטא-נתונים של מיקום, כמו תגי GPS Exif, שמאוחסנים
קובצי מדיה כשניגשים לקבצים האלה דרך
MediaStore
, חוץ מאשר במקרים שבהם אפליקציית השיחות כוללת את ההרשאהACCESS_MEDIA_LOCATION
.
יישומי מכשירים עשויים לעמוד בדרישות שלמעלה באמצעות הבאים:
- אחסון נשלף שנגיש למשתמש, כמו חריץ לכרטיס Secure Digital (SD).
- חלק מהאחסון הפנימי (שלא ניתן להסרה) כפי שמוטמע פרויקט קוד פתוח של Android (AOSP).
אם יישומים של מכשירים משתמשים באחסון נשלף כדי לעמוד בדרישות שלמעלה בדרישות הבאות:
- [C-1-1] חובה להטמיע בממשק משתמש הודעה קופצת או הודעה קופצת שמזהירה את המשתמש כאשר לא הוכנס אמצעי אחסון לחריץ.
- [C-1-2] חייב לכלול אמצעי אחסון בפורמט FAT (למשל, כרטיס SD) או תוכנית על האריזה וחומרים אחרים שזמינים בזמן הרכישה שהאחסון יש לרכוש אמצעי הגעה לאתר בנפרד.
אם יישומים של מכשירים משתמשים בחלק מהאחסון שלא ניתן להסרה כדי לספק בדרישות שפורטו למעלה:
- צריכה להשתמש ביישום AOSP של האפליקציה הפנימית המשותפת אחסון.
- ייתכן לשיתוף נפח האחסון עם האפליקציה הפרטית.
אם בהטמעות המכשיר יש יציאת USB עם תמיכה במצב ציוד היקפי בחיבור USB. הם:
- [C-3-1] חייב לספק מנגנון לגישה לנתונים באפליקציה נפח אחסון משותף ממחשב מארח.
- תוכן משני נתיבי האחסון אמור להופיע בשקיפות
שירות סורק המדיה של Android ו-
android.provider.MediaStore
. - ייתכן להשתמש באחסון USB בנפח גדול, אבל צריך להשתמש בפרוטוקול Media Transfer Protocol (פרוטוקול העברת מדיה) כדי לעמוד בדרישות בדרישה הזו.
אם בהטמעות המכשיר יש יציאת USB עם מצב היקפי בחיבור USB ותמיכה Media Transfer Protocol (פרוטוקול העברת מדיה):
- אמורה להיות תואמת למארח MTP של Android, העברת קבצים ב-Android.
- אמור לדווח על סוג התקן USB 0x00.
- יש לדווח על שם ממשק ה-USB 'MTP'.
7.6.3. אחסון מותאם
אם המכשיר צפוי להיות נייד בטבע, בשונה מטלוויזיה, דוגמאות להטמעת מכשירים:
- [C-SR-1] מומלץ מאוד להטמיע את האחסון שניתן לאמץ מיקום יציב לטווח ארוך, מכיוון שניתוק שלהם בטעות עלול לגרום לאובדן/פגיעה בנתונים.
אם היציאה של מכשיר האחסון הנשלף נמצאת במיקום יציב לטווח הארוך, למשל, בתוך תא הסוללות או כיסוי מגן אחר, דוגמאות להטמעת מכשירים:
- [C-SR-2] מומלץ מאוד להטמיע אחסון שניתן להתאמה.
7.7. USB
אם בהטמעות של מכשירים יש יציאת USB:
- צריכה לתמוך במצב ציוד היקפי בחיבור USB והוא אמור לתמוך במצב אירוח USB.
- אמורה לתמוך בהשבתה של אותות הנתונים באמצעות USB.
7.7.1. מצב ציוד היקפי בחיבור USB
אם הטמעות המכשיר כוללות יציאת USB שתומכת במצב היקפי:
- [C-1-1] היציאה חייבת להיות ניתנת לחיבור למארח USB שיש לו יציאת USB מסוג A או Type-C.
- [C-1-2] חובה לדווח על הערך הנכון של
iSerialNumber
בתקן USB שמתאר את המכשיר דרךandroid.os.Build.SERIAL
. - [C-1-3] חייבים לזהות מטענים של 1.5A ו-3.0A לפי נגד Type-C והם חייבים לזהות שינויים במודעה, אם הם תומכים USB-C.
- [C-SR-1] היציאה צריכה להשתמש בגורם צורה של USB מסוג מיקרו-B, מיקרו-AB או Type-C. מומלץ מאוד להתאים מכשירי Android קיימים וחדשים כדי שניתן יהיה לשדרג לגרסאות עתידיות של הפלטפורמה.
- [C-SR-2] היציאה אמורה להיות ממוקמת בחלק התחתון של המכשיר (בהתאם לכיוון הטבעי) או לאפשר סיבוב מסך בתוכנה כל האפליקציות (כולל מסך הבית), כדי שהתצוגה תופיע כראוי כאשר המכשיר פועל באמצעות היציאה בתחתית המסך. מכשירי Android קיימים וחדשים מומלץ מאוד לעמוד בדרישות האלה, תהיה אפשרות לשדרג לגרסאות עתידיות של הפלטפורמה.
- [C-SR-3] צריך להטמיע תמיכה כדי לצייר זרם של 1.5 אמפר במהלך ציוץ HS ותנועה כפי שמצוין במפרט של טעינת סוללה ב-USB, גרסה 1.2. מומלץ מאוד להתאים מכשירי Android קיימים וחדשים כדי שניתן יהיה לשדרג לגרסאות עתידיות של הפלטפורמה.
- [C-SR-4] מומלץ מאוד לא לתמוך בקניין רוחני שיטות טעינה שמשנות את המתח ב-Vbus מעבר לרמות ברירת המחדל, או משנות את המתח תפקידי sink/מקור כאלה עלולים לגרום לבעיות ביכולת הפעולה ההדדית (interoperability) מטענים או מכשירים שתומכים בשיטות הסטנדרטיות של העברת חשמל ב-USB. בזמן אנחנו קוראים לזה 'מומלץ מאוד', בגרסאות עתידיות של Android ייתכן שיהיה צורך בכל המכשירים מסוג C כדי לתמוך ביכולת פעולה הדדית מלאה עם מטענים מסוג C.
- [C-SR-5] מומלץ מאוד לתמיכה ב-Power Delivery להצגת נתונים החלפת תפקידי כוח כשהם תומכים במצב מארח USB ו-USB מסוג C.
- אמורה להיות תמיכה בתקן אספקת חשמל לטעינה במתח גבוה ותמיכה מצבים חלופיים, כמו מסך חוץ.
- יש להטמיע את ה-API והמפרט של Android Open Accessory (AOA) בתור בתיעוד של ה-SDK של Android.
אם ההטמעות של המכשיר כוללות יציאת USB ומטמיעות את AOA למפרט, הן:
- [C-2-1] חובה להצהיר על תמיכה בתכונת החומרה
android.hardware.usb.accessory
- [C-2-2] סוג האחסון בנפח USB חייב לכלול את המחרוזת 'android'. ב
סוף תיאור הממשק
iInterface
מחרוזת של אחסון בנפח גדול ב-USB
7.7.2. מצב אירוח USB
אם הטמעות המכשירים כוללות יציאת USB שתומכת במצב מארח:
- [C-1-1] חובה להטמיע את ממשק ה-API של מארח ה-Android ל-Android, כפי שמתועד ב-
Android SDK וחובה להצהיר על תמיכה בתכונת החומרה
android.hardware.usb.host
- [C-1-2] חובה להטמיע תמיכה בחיבור ציוד היקפי סטנדרטי בחיבור USB.
במילים אחרות, הם חייבים:
- צריכה להיות במכשיר יציאה מסוג C או משלוח עם כבלים, כדי להתאים את המכשיר למכשיר יציאה קניינית ליציאת USB-C סטנדרטית (מכשיר USB-C).
- המכשיר צריך להיות מסוג A או שהוא עם כבלים שמתאימים למכשיר יציאה קניינית ליציאת USB-A סטנדרטית.
- צריכה להיות יציאת מיקרו-AB במכשיר, שאמורה להישלח עם כבל ליציאה רגילה מסוג A.
- [C-1-3] אסור לשלוח עם מתאם שממיר USB מסוג A או יציאות מיקרו-AB ליציאת מסוג C (שקע).
- [C-SR-1] מומלץ מאוד להטמיע את סיווג האודיו בחיבור USB כפי שמתועד בתיעוד של Android SDK.
- אמורה לתמוך בטעינת הציוד ההיקפי המחובר בחיבור USB בזמן המארח מצב; פרסום מקור נוכחי של 1.5A לפחות כפי שמצוין הקטע 'פרמטרים של סיום' תיקון 1.2 לכבל USB-C ולמחבר ל-USB-C או שימוש בטעינה במורד הזרם(CDP) בפלט של הטווח הנוכחי, מצוין במפרט של טעינת סוללה ב-USB, גרסה 1.2 למחברי Micro-AB.
- עליכם להטמיע ולתמוך בתקני USB Type-C.
אם הטמעות המכשיר כוללות יציאת USB שתומכת במצב מארח וחיבור USB שיעור אודיו, הם:
- [C-2-1] חייב לתמוך בסיווג USB HID.
- [C-2-2] חייבת לתמוך בזיהוי ובמיפוי של נתוני ממשק המשתמש הבאים:
השדות שמצוינים בטבלאות השימוש בחיבור USB HID
ואת בקשת השימוש בפקודות קוליות
אל
KeyEvent
קבועים כמו בהמשך:- מזהה השימוש של דף השימוש (0xC) (0x0CD):
KEYCODE_MEDIA_PLAY_PAUSE
- מזהה השימוש של דף השימוש (0xC) (0x0E9):
KEYCODE_VOLUME_UP
- מזהה השימוש של דף השימוש (0xC) (0x0EA):
KEYCODE_VOLUME_DOWN
- מזהה השימוש של דף השימוש (0xC) (0x0CF):
KEYCODE_VOICE_ASSIST
- מזהה השימוש של דף השימוש (0xC) (0x0CD):
אם הטמעות המכשיר כוללות יציאת USB שתומכת במצב מארח וגם במסגרת Storage Access Framework (SAF), הן:
- [C-3-1] חובה לזהות כל MTP (פרוטוקול העברת מדיה) שמחובר מרחוק
מכשירים ולהפוך את התוכן שלהם לנגיש דרך
ACTION_GET_CONTENT
, IntentsACTION_OPEN_DOCUMENT
ו-ACTION_CREATE_DOCUMENT
. .
אם הטמעות המכשיר כוללות יציאת USB שתומכת במצב מארח וב-USB מסוג ג', הן:
- [C-4-1] חובה להטמיע את הפונקציונליות של יציאת Dual Role כפי שהוגדרה ב-USB מפרט Type-C (סעיף 4.5.1.3.3). לשניים יציאות תפקידים, במכשירים שכוללים שקע אודיו 3.5 מ"מ, הכיור USB ייתכן שהזיהוי (מצב מארח) יהיה מושבת כברירת מחדל, אבל זה חייב להיות אפשרי משתמש כדי להפעיל אותו.
- [C-SR-2] מומלץ מאוד לתמיכה ב-DisplayPort, צריכה לתמוך ב-USB קצבי הנתונים של Superspeed, ומומלץ מאוד לתמיכה באספקת חשמל להחלפת נתונים ותפקידי כוח.
- [C-SR-3] מומלץ מאוד לא לתמוך במצב האביזר של מתאם האודיו שמתוארים בנספח א' של גרסה 1.2 של כבל USB-C ומפרט המחבר.
- כדאי להטמיע את מודל Try.* המתאים ביותר גורם הצורה של המכשיר. לדוגמה, במכשיר נייד יש להטמיע את אפשר לנסות מודל SNK.
7.8. אודיו
7.8.1. מיקרופון
אם ההטמעות במכשירים כוללים מיקרופון:
- [C-1-1] חובה לדווח על קבוע התכונה
android.hardware.microphone
. - [C-1-2] חייב לעמוד בדרישות של הקלטת אודיו ב: סעיף 5.4.
- [C-1-3] חייב לעמוד בדרישות זמן האחזור לאודיו סעיף 5.6.
- [C-SR-1] מומלץ מאוד לתמוך בהקלטת אולטרסאונד, כפי שמתואר בסעיף 7.8.3.
אם ההטמעות של המכשיר מושמטות ממיקרופון:
- [C-2-1] אסור לדווח על קבוע התכונה
android.hardware.microphone
. - [C-2-2] חובה להטמיע את ה-API של הקלטת האודיו לפחות כפעולות ללא תפעול, לכל סעיף 7.
7.8.2. יעד השמע
אם ההטמעות במכשיר כוללות רמקול או פלט אודיו/מולטימדיה יציאה לציוד היקפי לפלט אודיו כמו שקע אודיו עם 4 מוליך 3.5 מ"מ או במצב מארח USB באמצעות סיווג אודיו USB, הן:
- [C-1-1] חובה לדווח על קבוע התכונה
android.hardware.audio.output
. - [C-1-2] חייב לעמוד בדרישות להפעלת אודיו ב: סעיף 5.5.
- [C-1-3] חייב לעמוד בדרישות זמן האחזור לאודיו סעיף 5.6.
- [C-SR-1] מומלץ מאוד לתמוך בהפעלה כמעט באמצעות אולטרסאונד, כפי שמתואר בסעיף 7.8.3.
אם ההטמעות במכשירים לא כוללות רמקול או יציאת אודיו, הן:
- [C-2-1] אסור לדווח על התכונה
android.hardware.audio.output
. - [C-2-2] חובה להטמיע לפחות את ממשקי ה-API שקשורים לפלט האודיו כללא תפעול.
למטרות סעיף זה, "יציאת פלט" היא ממשק פיזי לדוגמה, שקע אודיו 3.5 מ"מ, HDMI או יציאה במצב מארח ב-USB עם סיווג אודיו ב-USB. תמיכה בפלט אודיו באמצעות פרוטוקולים מבוססי רדיו כמו Bluetooth, חיבור Wi-Fi או רשת סלולרית לא ייחשבו כהכללה של "יציאת פלט".
7.8.2.1. יציאות אודיו אנלוגיות
כדי שיהיו תואמים לאוזניות ולאביזרי אודיו אחרים. באמצעות תקע אודיו 3.5 מ"מ בכל הסביבה העסקית של Android, אם כוללים יציאת אודיו אנלוגית אחת או יותר, כלומר:
- [C-SR-1] מומלץ מאוד לכלול לפחות מאפיין אחד יציאות האודיו שיהיו שקע אודיו של 4 מוליכים 3.5 מ"מ.
אם בהטמעות של מכשירים יש שקע אודיו של 4 מוליך בגודל 3.5 מ"מ, הן:
- [C-1-1] חייבת לתמוך בהפעלת אודיו באוזניות סטריאו ובאוזניות סטריאו עם מיקרופון.
- [C-1-2] חייבת לתמוך במחברי האודיו ב-TRRS עם הזמנת ההצמדה של CTIA.
- [C-1-3] חייבת לתמוך בזיהוי ובמיפוי לקודי מפתחות
לאחר 3 טווחים של עכבה מקבילה בין המיקרופון לאדמה
מוליכים בשקע האודיו:
- 70 או פחות או פחות:
KEYCODE_HEADSETHOOK
- 210-290 אוהם:
KEYCODE_VOLUME_UP
- 360-680 אוהם:
KEYCODE_VOLUME_DOWN
- 70 או פחות או פחות:
- [C-1-4] חייבים להפעיל את
ACTION_HEADSET_PLUG
עם הכנסת התקע, אבל רק לאחר שכל אנשי הקשר על השקע נוגעים בקטעים הרלוונטיים. על השקע. - [C-1-5] חייבת להיות יכולת להפעיל לפחות 150mV ± 10% ממתח יציאה עכבה של רמקול של 32 אוהם.
- [C-1-6] חייבת להיות הטיית מיקרופון בין 1.8 וולט כ-2.9 וולט.
- [C-1-7] חובה לזהות את קוד המפתח ולמפות אותו בשביל
טווח של עכבה מקבילה בין המיקרופון למוליכי הקרקע
בשקע האודיו:
- 110-180 אוהם:
KEYCODE_VOICE_ASSIST
- 110-180 אוהם:
- [C-SR-2] מומלץ מאוד לתמוך בתקעי האודיו עם OMTP של ה-OMTP. סדר הצמדה.
- [C-SR-3] מומלץ מאוד לתמוך בהקלטת אודיו מסטריאו של אוזניות עם מיקרופון.
אם בהטמעות של המכשיר יש שקע אודיו של 4 מוליך בגודל 3.5 מ"מ ותומכות
מיקרופון, ולשדר את android.intent.action.HEADSET_PLUG
באמצעות
עבור מיקרופון שהוא 1, הוא:
- [C-2-1] חייבת לתמוך בזיהוי המיקרופון באודיו המחובר אחר.
7.8.2.2. יציאות אודיו דיגיטליות
דרישות ספציפיות למכשיר מופיעות בסעיף 2.2.1.
7.8.3. קרוב לאולטרסאונד
אודיו Near-Ultrasound הוא תדר של 18.5kHz עד 20kHz.
הטמעות מכשירים:
- חייבים לדווח בצורה נכונה על תמיכה ב יכולת אודיו כמעט-קולית דרך AudioManager.getProperty API באופן הבא:
אם PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND
הוא 'TRUE', חובה לעמוד בדרישות הבאות
מקורות האודיו VOICE_RECOGNITION
ו-UNPROCESSED
:
- [C-1-1] תגובת ההספק הממוצעת של המיקרופון בתדר של 18.5kHz עד 20kHz חייב להיות לא יותר מ-15 דציבלים מתחת לתגובה ב-2 קילו-הרץ.
- [C-1-2] יחס האות לא משוקלל לרעש של המיקרופון מעל 18.5kHz עד 20kHz לטון של 19 kHz של -26dBFS, צריך להיות לא פחות מ-50dB
אם PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND
הוא "true":
- [C-2-1] התגובה הממוצעת של הרמקול בתדרים 18.5 kHz עד 20 kHz חייבת להיות לא נמוכה מ- 40 dB מתחת לתגובה ב- 2 kHz.
7.8.4. תקינות האות
הטמעות מכשירים:
- אמור לספק נתיב אות אודיו ללא תקלות עבור שני הקלט ותזרים פלט במכשירים ניידים, כפי שמוגדר באמצעות אפס תקלות שנמדדת במהלך בדיקה של דקה אחת לכל נתיב. בודקים באמצעות OboeTester "בדיקת תקלה אוטומטית".
בבדיקה נדרש מתאם של אודיו בלופ, משמש ישירות בשקע 3.5 מ"מ או בשילוב עם מתאם USB-C ל-3.5 מ"מ. כל היציאות של פלט האודיו צריכות להיבדק.
OboeTester תומך כרגע בנתיבי AAudio, לכן יש לבדוק אם יש תקלות בשילובים הבאים של אודיו:
מצב ביצועים | שיתוף | תדירות הדגימה יוצאת | בצ'אנס | צ'אן אאוט |
---|---|---|---|---|
LOW_LATENCY | בלעדי | לא מסומן | 1 | 2 |
LOW_LATENCY | בלעדי | לא מסומן | 2 | 1 |
LOW_LATENCY | משותף | לא מסומן | 1 | 2 |
LOW_LATENCY | משותף | לא מסומן | 2 | 1 |
ללא | משותף | 48000 | 1 | 2 |
ללא | משותף | 48000 | 2 | 1 |
ללא | משותף | 44100 | 1 | 2 |
ללא | משותף | 44100 | 2 | 1 |
ללא | משותף | 16000 | 1 | 2 |
ללא | משותף | 16000 | 2 | 1 |
זרם אמין צריך לעמוד בקריטריונים הבאים עבור 'אות לרעש' יחס (SNR) ועיוות הרמוני כולל (THD) ל-2,000 Hz סינוס.
מתמר | THD | חיישן SNR |
---|---|---|
רמקול מובנה ראשי, שנמדד באמצעות מיקרופון חיצוני להתייחסות | < 3.0% | >= 50 dB |
מיקרופון מובנה ראשי, שנמדד באמצעות רמקול עזר חיצוני | < 3.0% | >= 50 dB |
שקעים אנלוגיים מובנים בגודל 3.5 מ"מ, נבדקים באמצעות מתאם לולאה חוזרת | < 1% | >= 60 dB |
מתאמי USB שסופקו עם הטלפון, נבדקו באמצעות מתאם לולאה חוזרת | < 1.0% | >= 60 dB |
7.9. מציאות מדומה
Android כולל ממשקי API ומתקנים לבניית 'מציאות מדומה' (VR) כולל חוויות VR בנייד באיכות גבוהה. Device (מכשיר) חייבים להטמיע בצורה תקינה את ממשקי ה-API וההתנהגויות האלה, כפי שמפורט בקטע הזה.
7.9.1. מצב מציאות מדומה
Android כולל תמיכה ב: מצב VR, תכונה שמטפלת ברינדור סטריאוסקופי של התראות ומשביתה אותן רכיבי ממשק משתמש של מערכת מונוקולרית, בזמן שאפליקציית VR מתמקדת במשתמש.
7.9.2. מצב מציאות מדומה – ביצועים גבוהים
אם ההטמעות במכשירים תומכים במצב VR:
- [C-1-1] חייבות להיות לפחות 2 ליבות פיזיות.
- [C-1-2] חובה להצהיר על התכונה
android.hardware.vr.high_performance
. - [C-1-3] חייבת להיות תמיכה במצב ביצועים טובים.
- [C-1-4] חייבת לתמוך ב-OpenGL ES 3.2.
- [C-1-5] חייבת לתמוך ב-
android.hardware.vulkan.level
0. - צריכה לתמוך ב-
android.hardware.vulkan.level
1 ומעלה. - [C-1-6] חובה ליישם
EGL_KHR_mutable_render_buffer
EGL_ANDROID_front_buffer_auto_refresh
,EGL_ANDROID_get_native_client_buffer
,EGL_KHR_fence_sync
,EGL_KHR_wait_sync
,EGL_IMG_context_priority
,EGL_EXT_protected_content
,EGL_EXT_image_gl_colorspace
, וחושפים את התוספים ברשימת תוספי ה-EGL הזמינים. - [C-1-8] חובה ליישם
GL_EXT_multisampled_render_to_texture2
GL_OVR_multiview
,GL_OVR_multiview2
,GL_EXT_protected_textures
, וחושפים את התוספים ברשימת תוספי GL הזמינים. - [C-SR-1] מומלץ מאוד להטמיע
GL_EXT_external_buffer
GL_EXT_EGL_image_array
,GL_OVR_multiview_multisampled_render_to_texture
, וחושפים את התוספים ברשימת תוספי GL הזמינים. - [C-SR-2] אנחנו ממליצים מאוד לתמוך ב-Vulkan 1.1.
- [C-SR-3] מומלץ מאוד להטמיע
VK_ANDROID_external_memory_android_hardware_buffer
VK_GOOGLE_display_timing
,VK_KHR_shared_presentable_image
, וחושפים אותו ברשימת התוספים הזמינים של Vulkan. - [C-SR-4] מומלץ מאוד לחשוף לפחות משפחת תור אחת של Vulkan שבה
flags
מכילים גם אתVK_QUEUE_GRAPHICS_BIT
וגם אתVK_QUEUE_COMPUTE_BIT
, ו-queueCount
הוא לפחות 2. - [C-1-7] ה-GPU והמסך חייבים להיות מסוגלים לסנכרן את הגישה מאגר נתונים זמני בחזית, כך שרינדור תוכן VR מתבצע במהירות של 60fps עם שתי מצלמות מהירות מתחלפות הקשרי עיבוד יוצגו ללא פריטי מידע שנוצרו בתהליך הפיתוח (Artifact)
- [C-1-9] חובה להטמיע תמיכה ב
AHardwareBuffer
דגליםAHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER
,AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA
והקבוצהAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
כפי שמתואר ב-NDK. - [C-1-10] חובה להטמיע תמיכה ב-
AHardwareBuffer
באמצעות שילוב של דגלי השימושAHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT
,AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE
,AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
לפחות בפורמטים הבאים:AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM
,AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM
,AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM
,AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT
. - [C-SR-5] מומלץ מאוד לתמוך בהקצאה של
AHardwareBuffer
s עם יותר משכבה אחת ודגלים ופורמטים שצוינו ב-C-1-10. - [C-1-11] חייבת לתמוך בפענוח H.264 לפחות ב- 3840 x 2160 בקצב של 30fps, דחוסה לממוצע של 40Mbps (שווה ל-4 מופעים של 1920 x1080 בקצב 30fps-10Mbps, או שני מופעים של 1920 x 1080 בקצב 60fps-20Mbps).
- [C-1-12] חייבת להיות תמיכה ב-HEVC וב-VP9. בנוסף, חייבת להיות יכולת פענוח לפחות 1,920 x 1,080 בקצב של 30fps, דחוסים ל-10Mbps בממוצע, והצריכה להיות יכול לפענח 3840 x 2160 בקצב של 30 Mbps-20 Mbps (שווה ערך ל- ארבעה מופעים של 1920 x 1080 ב- 30fps-5Mbps).
- [C-1-13] חייבת להיות תמיכה ב-API של
HardwarePropertiesManager.getDeviceTemperatures
ולהחזיר ערכים מדויקים לטמפרטורת העור. - [C-1-14] חייב להיות מסך מוטמע, והרזולוציה שלו חייבת להיות לפחות 1,920 x 1,080
- [C-SR-6] מומלץ מאוד שרזולוציית המסך תהיה לפחות 2,560 x 1,440.
- [C-1-15] המסך חייב להתעדכן לפחות 60 Hz במצב VR.
- [C-1-17] המסך חייב לתמוך במצב של התמדה נמוכה עם 5 אלפיות השנייה או פחות עקביות, מופיעה הגדרה של 'עקביות' כמשך הזמן שפיקסל פולט אור.
- [C-1-18] חייבת להיות תמיכה ב-Bluetooth 4.2 ובתוסף אורך נתונים של Bluetooth LE סעיף 7.4.3.
- [C-1-19] חובה לספק תמיכה ולדווח בצורה תקינה
סוג ערוץ ישיר
לכל סוגי החיישנים הבאים שמוגדרים כברירת מחדל:
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
- [C-SR-7] מומלץ מאוד לתמוך
TYPE_HARDWARE_BUFFER
סוג הערוץ הישיר לכל סוגי הערוצים הישירים המפורטים למעלה. - [C-1-21] חייבים לעמוד בדרישות שקשורות לג'ירוסקופ, למד התאוצה ולמגנטומטר
הדרישות עבור
android.hardware.hifi_sensors
, כפי שמפורט ב- סעיף 7.3.9. - [C-SR-8] מומלץ מאוד לתמוך
תכונה
android.hardware.sensor.hifi_sensors
. - [C-1-22] זמן האחזור של פוטון חייב להיות תנועה מקצה לקצה שלא עולה על 28 אלפיות השנייה.
- [C-SR-9] מומלץ מאוד להפעיל תנועה מקצה לקצה לזמן אחזור של פוטון לא יותר מ-20 אלפיות שנייה.
- [C-1-23] חייב להיות יחס פריים ראשון, שהוא היחס בין בהירות הפיקסלים בפריים הראשון לאחר מעבר משחור ל ואת הבהירות של פיקסלים לבנים במצב יציב, של לפחות 85%.
- [C-SR-10] מומלץ מאוד לשמור על יחס פריים ראשון של 90% לפחות.
- MAY מספק ליבה בלעדית לחזית
ו-MAY תומכים ב-API של
Process.getExclusiveCores
כדי להחזיר מספר ליבות המעבד (CPU) הבלעדיות לחזית העליונה תרגום מכונה.
אם יש תמיכה בליבה בלעדית, אז הליבה:
- [C-2-1] אסור לאפשר לתהליכים אחרים במרחב המשתמשים לפעול בו (למעט מנהלי התקנים של מכשירים שהאפליקציה משתמשת בהם), אבל יכול להיות שמותר להשתמש בליבה (kernel) מסוימת כדי לרוץ לפי הצורך.
7.10. מגע
דרישות ספציפיות למכשיר מופיעות בסעיף 2.2.1.
7.11. שיעור ביצועי מדיה
אפשר לקבל את סיווג ביצועי המדיה של הטמעת המכשיר מתוך
API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
. הדרישות
לסיווג ביצועי המדיה, לכל גרסת Android שמתחילה ב-
R (גרסה 30). הערך המיוחד של 0 מציין שהמכשיר לא
שיעור ביצועי המדיה.
אם יישומים של מכשירים מחזירות ערך שאינו אפס עבור
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, הן:
[C-1-1] חייב להחזיר ערך לפחות של
android.os.Build.VERSION_CODES.R
.[C-1-2] ההטמעה של המכשיר הנייד חייבת להיות במכשירים ניידים.
[C-1-3] חייב לעמוד בכל הדרישות של 'סיווג ביצועי מדיה' תיאור בסעיף 2.2.7.
במילים אחרות, סיווג ביצועי המדיה ב-Android T מוגדר רק עבור מכשירים ניידים בגרסאות T, S או R.
למידע ספציפי למכשיר, יש לעיין בסעיף 2.2.7 בדרישות שלנו.
8. ביצועים ועוצמה
קריטריונים מסוימים של ביצועים ועוצמה מינימליים הם קריטיים לחוויית המשתמש ולהשפיע על הנחות הבסיס שיהיו למפתחים כשמפתחים אפליקציה.
8.1. עקביות בחוויית המשתמש
ניתן לספק ממשק משתמש חלק למשתמשי הקצה אם יש כדי להבטיח שקצב הפריימים וזמני התגובה יהיו עקביים. אפליקציות ומשחקים. הטמעת מכשירים, בהתאם לסוג המכשיר, ייתכן שיהיו דרישות שניתנות למדידה לגבי זמן האחזור והמשימה של ממשק המשתמש שינוי, כפי שמתואר בקטע 2.
8.2. ביצועים של גישת קלט/פלט לקובץ
מתן בסיס משותף לביצועים עקביים של גישה לקובץ
אחסון נתונים פרטיים של אפליקציות (מחיצה של /data
) מאפשרת למפתחי אפליקציות
להגדיר ציפיות שיעזרו להם לתכנן את התוכנה. Device (מכשיר)
ייתכן שיש דרישות מסוימות, בהתאם לסוג המכשיר
שמתוארים בקטע 2,
ופעולות כתיבה:
- ביצועי כתיבה ברצף. נמדד על ידי כתיבת קובץ 256MB באמצעות מאגר אחסון זמני של 10MB.
- ביצועי כתיבה אקראיים. המדידה מתבצעת על ידי כתיבת קובץ בגודל 256MB לפי גודל של 4KB מאגר נתונים זמני.
- ביצועי קריאה ברצף. נמדד על ידי קריאת קובץ בגודל 256MB באמצעות מאגר אחסון זמני של 10MB.
- ביצועי קריאה אקראיים. המדידה מתבצעת על ידי קריאת קובץ בגודל 256MB לפי גודל של 4KB מאגר נתונים זמני.
8.3. מצבי חיסכון בסוללה
אם ההטמעות במכשירים כוללות תכונות לשיפור ניהול צריכת החשמל של המכשיר שכלולים ב-AOSP (למשל, קטגוריית המתנה של אפליקציה, Doze) או מרחיבות את התכונות כדי להחיל הגבלות מחמירות יותר מקטגוריית ההמתנה המוגבלת של אפליקציות, הן:
- [C-1-1] אסור לסטות מהטמעת ה-AOSP לטריגרים פעולות תחזוקה, אלגוריתמים של יציאה ממצב שינה ושימוש בהגדרות מערכת גלובליות הגדרת המכשיר של מצב 'המתנה' ו'נמנום' של חיסכון בסוללה.
- [C-1-2] אסור לסטות מהטמעת ה-AOSP לשימוש או DeviceConfig כדי לנהל את ויסות הנתונים (throttling) של משימות, התראות הרשת לאפליקציות בכל קטגוריה למצב המתנה.
- [C-1-3] אסור לסטות מיישום ה-AOSP עבור מספר קטגוריות בהמתנה של אפליקציה בשביל האפליקציה בהמתנה.
- [C-1-4] חובה להטמיע קטגוריות של אפליקציות במצב המתנה ואת האפשרות 'נמנום' בתור שמתואר במאמר ניהול צריכת חשמל.
- [C-1-5] חייב להחזיר
true
במחירPowerManager.isPowerSaveMode()
כשהמכשיר נמצא במצב חיסכון בסוללה. - [C-1-6] חובה לספק למשתמשים אפשרות להציג את כל האפליקציות שפטורות ממצב המתנה ו'נמנום', חיסכון בסוללה או כל אופטימיזציה אחרת של הסוללה וחובה ליישם את הפעולה ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS כוונה לבקש מהמשתמש לאפשר לאפליקציה להתעלם מהסוללה ואופטימיזציות.
- [C-SR-1] מומלץ מאוד לספק למשתמשים מספיק כסף כדי לאפשר להם להשבית את תכונת החיסכון בסוללה.
- [C-SR-2] מומלץ מאוד לספק למשתמשים אפשרות להציג את כל אפליקציות שפטורות ממצבי 'המתנה' ו'נמנום' של חיסכון בסוללה.
אם ההטמעות במכשירים מרחיבות את התכונות של ניהול צריכת החשמל שכלולות ב-AOSP, והתוסף הזה מחילה הגבלות מחמירות יותר קטגוריית ההמתנה של האפליקציות הנדירות, עיינו במאמר סעיף 3.5.1.
בנוסף למצבי החיסכון באנרגיה, הטמעות של מכשירי Android במאי להטמיע אחד או את כל ארבעת מצבי השינה של כוח שינה, כפי שהוגדרו על ידי Configuration ו-Power Interface (ACPI).
אם בהטמעות של מכשירים מיושמות מצבי הפעלה של S4 כפי שהוגדרו על ידי ACPI, הם:
- [C-1-1] חובה להזין את המצב הזה רק אחרי שהמשתמש ביצע פעולה מפורשת כדי להעביר את המכשיר למצב לא פעיל (למשל, על ידי סגירת מכסה שנמצא פיזית חלק מהמכשיר או כיבוי של רכב או טלוויזיה) ולפני משתמש מפעיל מחדש את המכשיר (למשל, על ידי פתיחת המכסה או סיבוב הרכב או להפעיל את הטלוויזיה מחדש).
אם בהטמעות של מכשירים מיושמים מצבי הפעלה של S3 כפי שהוגדרו על ידי ACPI, הם:
[C-2-1] חובה לעמוד בדרישות C-1-1 שלמעלה, או, חייבים להיכנס למצב S3 רק כשצד שלישי שאפליקציות לא צריכות את משאבי המערכת (למשל המסך, ה-CPU).
לעומת זאת, חייבים לצאת ממצב S3 כשאפליקציות של צד שלישי צריכות במשאבי המערכת, כפי שמתואר בערכת ה-SDK הזו.
לדוגמה, בזמן שהאפליקציות של הצד השלישי מבקשות להשאיר את המסך פועל עד
FLAG_KEEP_SCREEN_ON
, או שהמעבד (CPU) פועלPARTIAL_WAKE_LOCK
, אסור שהמכשיר יהיה במצב S3 אלא אם, כפי שמתואר ב-C-1-1, המשתמש נקט פעולה מפורשת כדי להציב את המכשיר במצב לא פעיל. לעומת זאת, כאשר משימה של אפליקציה של צד שלישי שההטמעה שלו מתבצעת דרך JobScheduler, או כאשר שירות העברת ההודעות בענן ב-Firebase מופעל לספקים של צד שלישי, המכשיר חייב לצאת ממצב S3, אלא אם המשתמש העביר את המכשיר למצב לא פעיל. התשובות לא מקיפות לדוגמה, ו-AOSP מטמיע אותות התעוררות נרחבים שעלולים לגרום ליציאה ממצב שינה מהמצב הזה.
8.4. חשבונאות של צריכת הכוח
חשבונאות ודיווח מדויקים יותר לגבי צריכת החשמל מספקים גם את התמריצים וגם את הכלים לאופטימיזציה של צריכת החשמל של האפליקציה.
הטמעות מכשירים:
- [C-SR-1] מומלץ מאוד לספק פרופיל כוח לכל רכיב שמגדיר את ערך הצריכה הנוכחית. לגבי כל רכיב חומרה והתרוקנות משוערת של הסוללה שנגרמה על ידי הרכיבים לאורך זמן, כפי שמתואר באתר פרויקט הקוד הפתוח של Android.
- [C-SR-2] מומלץ מאוד לדווח על כל ערכי צריכת החשמל במיליאמפר שעות (mAh).
- [C-SR-3] מומלץ מאוד לדווח על צריכת החשמל של המעבד (CPU) לפי ה-UID של כל תהליך.
פרויקט הקוד הפתוח של Android עומד בדרישה באמצעות
הטמעת מודול הליבה של
uid_cputime
. - [C-SR-4] מומלץ מאוד להפעיל את השימוש בחשמל הזה
adb shell dumpsys batterystats
פקודת מעטפת למפתח האפליקציה. - צריך להיות משויך לרכיב החומרה עצמו אם לא ניתן שיוך של צריכת החשמל של רכיב חומרה לאפליקציה.
8.5. ביצועים עקביים
יכולות להיות תנודות משמעותיות בביצועים של אפליקציות ממושכות, בעלות ביצועים גבוהים, בגלל שאפליקציות אחרות פועלות ברקע או ויסות נתונים (throttle) של המעבד עקב מגבלות הטמפרטורה. ב-Android יש ממשקים פרוגרמטיים, כך שכאשר המכשיר יכול, האפליקציה בחזית יכולה לבקש והמערכת תבצע אופטימיזציה של הקצאת המשאבים כדי לטפל בתנודות כאלה.
הטמעות מכשירים:
[C-0-1] חובה לדווח על התמיכה במצב 'ביצועים קבועים' באופן מדויק דרך
PowerManager.isSustainedPerformanceModeSupported()
שיטת ה-API.אמורה לתמוך במצב ביצועים קבועים.
אם יישומים של מכשירים ידווחו על תמיכה במצב ביצועים עקביים:
- [C-1-1] חובה לספק לאפליקציה בחזית ברמה עקבית של את הביצועים שלה למשך 30 דקות לפחות, כשהאפליקציה מבקשת אותם.
- [C-1-2] חייב לכבד את
Window.setSustainedPerformanceMode()
API וממשקי API קשורים אחרים.
אם הטמעות המכשיר כוללות שתי ליבות מעבד (CPU) או יותר:
- צריכה לספק לפחות ליבה בלעדית אחת שניתן להזמין מראש של האפליקציה בחזית.
אם בהטמעות במכשירים יש תמיכה בהזמנת ליבה בלעדית אחת לראש הרשימה באפליקציה בחזית, הן:
- [C-2-1] חובה לדווח דרך
Process.getExclusiveCores()
שיטת ה-API משתמשת במספרי הזיהוי של הליבות הבלעדיות שאפשר לשמור לפי האפליקציה בחזית. - [C-2-2] אסור לאפשר תהליכי מרחב של משתמשים מלבד מנהלי ההתקנים של המכשירים ששימשה את האפליקציה להרצה על ליבות בלעדיות, אבל ייתכן שהיא תאפשר תהליכי ליבה (kernel) שיפעלו לפי הצורך.
אם הטמעות של מכשירים לא תומכות בליבה בלעדית, הן:
- [C-3-1] חייבת להחזיר רשימה ריקה דרך
Process.getExclusiveCores()
שיטת ה-API.
9. תאימות של דגם אבטחה
הטמעות מכשירים:
[C-0-1] חובה להטמיע מודל אבטחה עקבי במודל האבטחה של פלטפורמת Android כפי שמוגדר מסמך עזר בנושא אבטחה והרשאות בממשקי ה-API בתיעוד למפתחים של Android.
[C-0-2] חייבת לתמוך בהתקנה של חתימה עצמית ללא צורך בהרשאות/אישורים נוספים מכל צדדים שלישיים/רשויות.
אם בהטמעות במכשירים מוצהר על android.hardware.security.model.compatible
הם:
- [C-1-1] חייבת לתמוך בדרישות שמפורטות בסעיפי המשנה הבאים.
9.1. הרשאות
הטמעות מכשירים:
[C-0-1] חייבת לתמוך במודל ההרשאות של Android מודל התפקידים ב-Android כפי שמוגדר בתיעוד למפתחים של Android. באופן ספציפי, חובה לאכוף כל הרשאה ותפקיד שמוגדרים כפי שמתואר מסמכי תיעוד בנושא SDK; אי אפשר להשמיט או לשנות תפקידים, או שהמערכת מתעלמת מהם.
יכול להיות שיתווספו עוד הרשאות, בתנאי שיש מחרוזות חדשות של מזהה ההרשאה אינם במרחב השמות
android.\*
.[C-0-2] הרשאות עם
protectionLevel
שלPROTECTION_FLAG_PRIVILEGED
חייבים להעניק את ההרשאה רק לאפליקציות שהותקנו מראש בנתיבים שיש בהם הרשאות של של המערכת (וכן קובצי APEX) בקבוצת המשנה של ההרשאות שנוספו באופן מפורש לרשימת ההיתרים לכל אפליקציה. הטמעת ה-AOSP עומדת בדרישה הזו. לשם כך, היא קוראת את המדיניות ופועלת בהתאם הרשאות שנמצאות ברשימת ההיתרים לכל אפליקציה מהקבצים בetc/permissions/
ושימוש בנתיבsystem/priv-app
בתור נתיב בעל הרשאות.
הרשאות עם רמת הגנה מסוכנות הן הרשאות בתחילת ההפעלה.
אפליקציות עם targetSdkVersion
> 22 לבקש אותם בזמן הריצה.
הטמעות מכשירים:
- [C-0-3] חובה להציג ממשק ייעודי למשתמש שיכול להחליט האם להעניק את ההרשאות הנדרשות בתחילת ההפעלה, וגם לספק ממשק שבו המשתמש יכול לנהל הרשאות בתחילת ההפעלה.
- [C-0-4] חובה להטמיע לפחות אחד מהסוגים של שני המשתמשים ממשקים. אם הטמעת המכשיר תומכת במכשיר נלווה, במכשיר הנלווה MAY ניתן לספק ממשק נוסף.
[C-0-5] אסור להעניק הרשאות סביבת זמן ריצה ל- באפליקציות, אלא אם:
- הם מותקנים בזמן משלוח המכשיר, וגם
ניתן לקבל את הסכמת המשתמש לפני הגשת הבקשה משתמש בהרשאה,
או
ההרשאות בתחילת ההפעלה מוענקות על ידי מדיניות ברירת המחדל להענקת הרשאות או עבור תפקיד פלטפורמה.
[C-0-6] חייבים לתת את ההרשאה
android.permission.RECOVER_KEYSTORE
רק לאפליקציות מערכת שרושמות סוכן שחזור מאובטח כראוי. א' סוכן שחזור שמאובטח כראוי מוגדר כסוכן תוכנה במכשיר שמסתנכרן עם אחסון מרוחק מחוץ למכשיר, שכולל חומרה מאובטחת עם הגנה מקבילה או חזקה יותר מתואר ב: שירות Google Cloud Key Vault למניעת התקפות מסוג brute-force על גורם הידע של מסך הנעילה.
הטמעות מכשירים:
[C-0-7] האפליקציה חייבת לפעול בהתאם לנכסים של הרשאות מיקום ב-Android מבקשת את נתוני המיקום או הפעילות הפיזית דרך ה-API הרגיל של Android או מנגנון קנייני. נתונים כאלה כוללים, בין היתר:
- מיקום המכשיר (למשל קו רוחב וקו אורך) כפי שמתואר ב סעיף 9.8.8.
- מידע שיכול לשמש כדי להעריך או להעריך את הביצועים של המכשיר המיקום (למשל SSID, BSSID, מזהה תא, או מיקום הרשת). שהמכשיר מחובר אליו).
- הפעילות הגופנית של המשתמש או סיווג הפעילות הגופנית.
באופן ספציפי יותר, הטמעות מכשירים:
- [C-0-8] חובה לקבל הסכמה מהמשתמשים כדי לאפשר לאפליקציה לגשת אל נתוני מיקום או פעילות גופנית.
- [C-0-9] חייבת להעניק הרשאה בתחילת ההפעלה רק לאפליקציה שמכילה את
הרשאה מספקת כפי שמתואר ב-SDK.
לדוגמה,
BrowseManager#getServiceState
נדרש
android.permission.ACCESS_FINE_LOCATION
).
החריגים היחידים למאפיינים של הרשאות המיקום ב-Android שצוינו למעלה הם עבור אפליקציות שלא ניגשות למיקום כדי להסיק או לזהות את מיקום המשתמש; ובאופן ספציפי:
- כשאפליקציות מחזיקות בהרשאה
RADIO_SCAN_WITHOUT_LOCATION
. - למטרות הגדרה והגדרה של המכשיר, כאשר אפליקציות המערכת כוללות את
הרשאה
NETWORK_SETTINGS
אוNETWORK_SETUP_WIZARD
.
אפשר לסמן הרשאות כמוגבלות בשינוי ההתנהגות.
[C-0-10] הרשאות שמסומנות בדגל
hardRestricted
לא יכולות להיות מוענק לאפליקציה, אלא אם:- קובץ APK של אפליקציה נמצא במחיצת המערכת.
- המשתמש מקצה תפקיד שמשויך ל-
hardRestricted
הרשאות לאפליקציה. - מנהל ההתקנה מעניק את ההרשאה
hardRestricted
לאפליקציה. - אפליקציה מקבלת את
hardRestricted
בגרסה קודמת של Android.
[C-0-11] אפליקציות עם הרשאת
softRestricted
חייבות להיות מוגבלות בלבד ולא לקבל גישה מלאה עד שהם יופיעו ברשימת ההיתרים, כפי שמתואר SDK, כאשר גישה מלאה ומוגבלת מוגדרת לכלsoftRestricted
(לדוגמה,READ_EXTERNAL_STORAGE
).[C-0-12] אסור לספק פונקציות מותאמות אישית או ממשקי API כדי לעקוף את הגבלות על הרשאות שהוגדרו ב-setAuthorPolicy ו-setAuthorGrantState ממשקי API.
[C-0-13] חייבים להשתמש בממשקי ה-API של AppOpsManager כדי לתעד ולעקוב אחרי כל פעילות, כל גישה פרוגרמטית לנתונים המוגנים באמצעות הרשאות מסוכנות פעילויות ושירותים ב-Android.
[C-0-14] חובה להקצות תפקידים רק לאפליקציות עם פונקציות לעמוד בדרישות התפקיד.
[C-0-15] אסור להגדיר תפקידים שהם עותקים כפולים או פונקציונליות של קבוצות-על של התפקידים שהפלטפורמה מגדירה.
אם המכשירים מדווחים על android.software.managed_users
, הם:
- [C-1-1] אסור לקבל את ההרשאות הבאות באופן שקט מטעם
admin:
- מיקום (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- מצלמה (CAMERA)
- מיקרופון (RECORD_AUDIO)
- חיישן גוף (BODY_SENSORS)
- פעילות גופנית (ACTIVITY_RECOGNITION)
אם יישומי מכשירים מאפשרים למשתמש לבחור אילו אפליקציות יוכלו
צייר מעל אפליקציות אחרות בפעילות שמטפלת
ACTION_MANAGE_OVERLAY_PERMISSION
בכוונה טובה, הם:
- [C-2-1] חובה לוודא שכל הפעילויות עם מסנני Intent
ACTION_MANAGE_OVERLAY_PERMISSION
ל-Intent יש מסך זהה בממשק המשתמש, בלי קשר לאפליקציה שמתחילה את התהליך או שהוא מספק.
אם יישומים של מכשירים מדווחים על android.software.device_admin, הם:
- [C-3-1] חובה להציג כתב ויתור במהלך הגדרת מכשיר מנוהלת באופן מלא (הגדרת בעל המכשיר) שמציינת שהאדמין ב-IT יוכל מאפשר לאפליקציות לשלוט בהגדרות בטלפון, כולל המיקרופון, המצלמה עם אפשרויות נוספות למשתמש להמשיך בהגדרה או לצאת מתהליך ההגדרה, אלא אם האדמין ביטל את השליטה בהרשאות במכשיר.
אם המכשיר מטמיע מראש חבילות שמכילות את אחד מהתפקידים System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence או System Visual Intelligence, החבילות:
- [C-4-1] חובה לעמוד בכל הדרישות שצוינו בהטמעות של מכשירים בסעיף '9.8.6 צילום תוכן'.
- [C-4-2] אסור להשתמש בהרשאה android.permission.INTERNET. זו הנחיה מחמירה יותר מהמומלץ מאוד שמפורטת בסעיף 9.8.6.
- [C-4-3] אסור לקשר לאפליקציות אחרות, מלבד אפליקציות המערכת הבאות: Bluetooth, 'אנשי קשר', מדיה, טלפוניה, SystemUI, ורכיבים שמספקים ממשקי API לאינטרנט.ההגדרה הזו מחמירה יותר מהמומלץ מאוד שמפורטת בסעיף 9.8.6.
9.2. UID ובידוד של תהליכים
הטמעות מכשירים:
- [C-0-1] חייבת לתמוך באפליקציה ל-Android ארגז חול, שבו כל אפליקציה פועלת בתור UID ייחודי של Unixstyle ובתהליך נפרד.
- [C-0-2] חייבת להיות תמיכה בהפעלה של מספר אפליקציות אותו מזהה משתמש ב-Linux, בתנאי שהאפליקציות חתומות כראוי ונבנה, כפי שמוגדר חומר עזר בנושא אבטחה והרשאות.
9.3. הרשאות במערכת הקבצים
הטמעות מכשירים:
- [C-0-1] חייבת לתמוך בגישה לקובץ ב-Android מודל ההרשאות כפי שמוגדר חומר עזר בנושא אבטחה והרשאות.
9.4. סביבות הפעלה חלופיות
אפליקציות המכשירים חייבות לשמור על עקביות באבטחה של Android מודל הרשאות, גם אם הם כוללים סביבות זמן ריצה שכוללות באמצעות תוכנה או טכנולוגיה אחרות מלבד קובץ ההפעלה של Dalvik פורמט או קוד נייטיב. במילים אחרות:
[C-0-1] זמני ריצה חלופיים חייבים להיות אפליקציות ל-Android, ולפעול בהתאם למודל האבטחה הסטנדרטי של Android, כמו שמתואר במקום אחר בקטע 9.
[C-0-2] אסור לתת לזמני ריצה חלופיים גישה למשאבים מוגן על ידי הרשאות שלא התבקשו ב-
AndroidManifest.xml
של סביבת זמן הריצה דרך <uses-permission
> על מנגנוני תשומת לב.[C-0-3] אסור לאפשר לאפליקציות להשתמש בסביבות זמני ריצה חלופיים תכונות שמוגנות באמצעות הרשאות Android שמוגבלות לאפליקציות מערכת.
[C-0-4] זמני ריצה חלופיים חייבים לעמוד בדרישות של מודל ארגז החול של Android ואת האפליקציות המותקנות באמצעות סביבת זמן ריצה חלופית, אסור לעשות שימוש חוזר בארגז החול של כל אפליקציה אחרת שמותקנת במכשיר, אלא אם המנגנונים הרגילים של Android של מזהה משתמש משותף ואישור חתימה.
[C-0-5] אסור להפעיל זמני ריצה חלופיים עם, להעניק או לקבל אישור גישה ל-Sandboxs שמתאימים לאפליקציות אחרות ל-Android.
[C-0-6] אסור להפעיל סביבות ריצה חלופיות, לקבל אותן או לאשר אותן לאפליקציות אחרות הרשאות כלשהן של משתמש-על (הרמה הבסיסית) או של כל מזהה משתמש.
[C-0-7] כשקובצי
.apk
של זמני ריצה חלופיים נכללים תמונת מערכת של יישומי מכשיר, חייב להיות חתום עליו באמצעות מפתח ייחודי מהמפתח שמשמש לחתימה על אפליקציות אחרות שכלולות במכשיר בפועל.[C-0-8] במהלך התקנת אפליקציות, זמני ריצה חלופיים חייבים הסכמת המשתמש להרשאות Android שמשמשות את האפליקציה.
[C-0-9] כשאפליקציה צריכה להשתמש במשאב של המכשיר שקיימת הרשאה תואמת של Android (כמו מצלמה, GPS וכו'), סביבת זמן הריצה החלופית חייבת להודיע למשתמש שהאפליקציה תוכל לגשת למשאב הזה.
[C-0-10] כשסביבת זמן הריצה לא מתעדת את האפליקציה באופן הזה, סביבת זמן הריצה חייבת להציג רשימה של כל ההרשאות שנמצא בסביבת זמן הריצה עצמה במהלך התקנת אפליקציה כלשהי באמצעות אותו זמן ריצה.
אם יש זמני ריצה חלופיים, צריך להתקין אפליקציות דרך
PackageManager
בתוך ארגזי חול (Sandbox) נפרדים של Android (מזהי משתמשים ב-Linux וכו').ייתכן שזמני ריצה חלופיים מספקים ארגז חול אחד של Android לכולם שמשותף לכולם באמצעות סביבת זמן הריצה החלופית.
9.5. תמיכה במשתמשים מרובים
Android כולל תמיכה במשתמשים מרובים
ומספקת תמיכה לבידוד מלא של משתמשים ולשכפול פרופילי משתמשים עם
בידוד חלקי(כלומר פרופיל משתמש אחד נוסף מסוג מסוים)
android.os.usertype.profile.CLONE
).
- ייתכן שהטמעת מכשירים במכשירים שונים, אבל לא אמורים לאפשר שימוש בריבוי משתמשים אם הם משתמשים מדיה נשלפת לאחסון חיצוני ראשי.
אם הטמעות במכשירים כוללות תמיכה בריבוי משתמשים, הן:
- [C-1-2] חובה להטמיע אמצעי אבטחה לכל משתמש תואם למודל האבטחה של פלטפורמת Android כפי שמוגדר מסמך עזר בנושא אבטחה והרשאות בממשקי ה-API.
- [C-1-3] חייב להיות אחסון משותף נפרד ונפרד של האפליקציה
(שנקראות גם
/sdcard
) ספריות לכל מופע של משתמש. - [C-1-4] חובה לוודא שאפליקציות שנמצאות בבעלות ובהפעלה של משתמש נתון לא יכול לרשום, לקרוא או לכתוב בקבצים שבבעלות אף משתמש אחר, גם אם הנתונים של שני המשתמשים מאוחסנים באותו נפח אחסון או באותה מערכת קבצים.
- [C-1-5] חובה להצפין את התוכן של כרטיס ה-SD כאשר האפשרות 'ריבוי משתמשים' מופעלת באמצעות מפתח המאוחסן רק במדיה שאינה נשלפת, הנגישה למערכת רק אם יישומים של מכשירים משתמשים במדיה נשלפת עבור ממשקי API של אחסון חיצוני. מאחר שהפעולה הזו תהפוך את המדיה לבלתי קריאה על ידי מחשב מארח, יישומים של מכשירים יידרשו לעבור ל-MTP או למערכת דומה כדי לספק מחשבים מארחים גישה לנתונים של המשתמש הנוכחי.
אם הטמעות המכשירים כוללות תמיכה במשתמשים מרובים, אז עבור כל המשתמשים למעט משתמשים שנוצרו במיוחד להפעלת מופעים כפולים של אותה אפליקציה, הם:
- [C-2-1] חייב להיות אחסון משותף נפרד ונפרד של האפליקציה (שנקרא גם /sdcard) לכל מופע של משתמש.
- [C-2-2] חייבים לוודא שאפליקציות שנמצאות בבעלותם ומופעלות על ידי מטעם משתמש נתון לא יכול לרשום את הקבצים שבבעלותו, לקרוא או לכתוב אותם על ידי כל משתמש אחר, גם אם הנתונים של שני המשתמשים מאוחסנים באותו מכשיר נפח אחסון או מערכת קבצים.
הטמעת מכשירים עשויים ליצור פרופיל משתמש אחד נוסף מסוג מסוים
android.os.usertype.profile.CLONE
מול המשתמש הראשי (ורק כנגד המשתמש הראשי
המשתמש הראשי) כדי להפעיל שני מופעים של אותה האפליקציה.
שתי המכונות האלה חולקות נפח אחסון מבודד חלקית,
משתמש הקצה במרכז האפליקציות בו-זמנית ויופיעו באותה תצוגת האחרונים.
לדוגמה, הוא יכול לשמש כדי לתמוך בהתקנה של
של אפליקציה אחת במכשיר עם SIM כפול.
אם הטמעות של מכשירים יוצרות את פרופיל המשתמש הנוסף שמתואר למעלה, ואז:
- [C-3-1] חובה לספק גישה רק לנפח אחסון או לנתונים שכבר נגיש לפרופיל המשתמש ההורה או נמצא בבעלות ישירה שלו פרופיל משתמש נוסף.
- [C-3-2] אסור להגדיר את הפרופיל כפרופיל עבודה.
- [C-3-3] חובה ליצור ספריות נתונים פרטיות של האפליקציה ששייכים להורה חשבון משתמש.
- [C-3-4] אסור לאפשר יצירה של פרופיל משתמש נוסף אם הוקצה בעלי מכשיר (ראו סעיף 3.9.1) או אפשר לבעלי מכשיר יוקצה בלי להסיר קודם את פרופיל המשתמש הנוסף.
9.6. אזהרה לגבי SMS פרימיום
ב-Android יש תמיכה באזהרה למשתמשים מפני הודעות יוצאות הודעת SMS פרימיום. הודעות SMS פרימיום הודעות הן הודעות טקסט שנשלחות לשירות שרשום אצל ספק הסלולר נחייב את המשתמש.
אם בהטמעות המכשירים מוצהר על תמיכה ב-android.hardware.telephony
,
הם:
- [C-1-1] חובה להזהיר משתמשים לפני שליחת הודעת SMS למספרים
מזוהה באמצעות ביטויים רגולריים שמוגדרים ב-
/data/misc/sms/codes.xml
בקובץ במכשיר. פרויקט הקוד הפתוח של Android ב-upstream מספק יישום שעומד בדרישה הזו.
9.7. תכונות אבטחה
הטמעת מכשירים חייבת להבטיח תאימות לתכונות אבטחה הליבה (kernel) והפלטפורמה כפי שמתואר בהמשך.
ה-Sandbox של Android כולל תכונות שמתבססות על טכנולוגיית Linux משופרת (SELinux) מערכת בקרת גישה (MAC), הרצה בארגז חול (sandboxing) ב-seccomp ועוד בתכונות האבטחה בליבה (kernel) של Linux. הטמעות מכשירים:
- [C-0-1] חייבת לשמור על תאימות לאפליקציות קיימות, גם במקרים שבהם SELinux או תכונות אבטחה אחרות מוטמעות מתחת ל-Android .
- [C-0-2] אסור שיהיה ממשק משתמש גלוי כשניתן זוהתה הפרה ונחסמה בהצלחה על ידי תכונת האבטחה שמוטמעות מתחת ל-framework של Android, אבל יכול להיות שממשק משתמש יהיה גלוי כאשר מתרחשת הפרת אבטחה שהחסימה שלה בוטלה וכתוצאה מכך ניצול מוצלח.
- [C-0-3] אסור להטמיע SELinux או תכונות אבטחה אחרות מתחת ל-framework של Android שאפשר להגדיר למשתמש או למפתח האפליקציה.
- [C-0-4] אסור לאפשר אפליקציה שיכולה להשפיע על אפליקציה אחרת באמצעות ממשק API (כמו Device Administration API) כדי להגדיר מדיניות שפוגעת בתאימות.
- [C-0-5] חייבים לפצל את מסגרת המדיה למספר תהליכים כדי אפשרות להעניק גישה לכל תהליך באופן צר יותר תיאור באתר פרויקט הקוד הפתוח של Android.
- [C-0-6] חובה להטמיע מנגנון הרצה בארגז חול (sandboxing) באפליקציית ליבה (kernel) שמאפשר לסנן קריאות מערכת באמצעות מדיניות שניתנת להגדרה, תוכנות מרובות שרשורים. פרויקט הקוד הפתוח של Android ב-upstream עומד בדרישות האלה דרישה באמצעות הפעלת seccomp-BPF עם threadgroup סנכרון (TSYNC) כפי שמתואר בקטע Kernel Configuration של source.android.com.
התכונות של תקינות הליבה וההגנה העצמית הן חלק בלתי נפרד מ-Android אבטחה. הטמעות מכשירים:
- [C-0-7] חובה להטמיע מנגנוני הגנה על גלישת מאגר נתונים זמני של ליבה (kernel).
דוגמאות למנגנונים כאלה:
CC_STACKPROTECTOR_REGULAR
CONFIG_CC_STACKPROTECTOR_STRONG
. - [C-0-8] חובה להטמיע הגנות מחמירות על זיכרון ליבה (kernel) כאשר קובץ הפעלה
הוא לקריאה בלבד, נתונים לקריאה בלבד אינם ניתנים להפעלה ולא לכתיבה,
לא ניתן להפעיל נתונים לכתיבה (למשל
CONFIG_DEBUG_RODATA
אוCONFIG_STRICT_KERNEL_RWX
). - [C-0-9] חובה להטמיע גודל אובייקט סטטי ודינמי
בדיקת גבולות של עותקים בין מרחב המשתמש ומרחב הליבה
(למשל
CONFIG_HARDENED_USERCOPY
) במכשירים שנשלחו במקור ברמת API 28 ומעלה. - [C-0-10] אסור להפעיל זיכרון-מרחב משתמש במהלך הרצה
במצב הליבה (למשל, חומרה PXN או אמולציה דרך
CONFIG_CPU_SW_DOMAIN_PAN
אוCONFIG_ARM64_SW_TTBR0_PAN
) במכשירים במקור במשלוח ברמת API 28 ומעלה. - [C-0-11] אסור לקרוא או לכתוב זיכרון של מרחב משתמש
ליבה (kernel) מחוץ לממשקי API רגילים לגישה לעותק משתמש (למשל, מספר PAN של החומרה, או
אמולציה באמצעות
CONFIG_CPU_SW_DOMAIN_PAN
אוCONFIG_ARM64_SW_TTBR0_PAN
) במכשירים שנשלחו במקור עם API ברמת 28 ומעלה. - [C-0-12] חובה להטמיע בידוד של דף ליבה (kernel) אם החומרה
חשופה ל-CVE-2017-5754 בכל המכשירים שנשלחו במקור עם רמת API
28 ומעלה (למשל,
CONFIG_PAGE_TABLE_ISOLATION
אוCONFIG_UNMAP_KERNEL_AT_EL0
). - [C-0-13] חובה להטמיע הקשחת חיזוי הסתעפות אם החומרה
חשופה ל-CVE-2017-5715 בכל המכשירים שנשלחו במקור עם רמת API
28 ומעלה (למשל,
CONFIG_HARDEN_BRANCH_PREDICTOR
). - [C-SR-1] מומלץ מאוד לשמור נתוני ליבה
שנכתב רק במהלך האתחול ומסומן לקריאה בלבד לאחר מכן
אתחול (למשל
__ro_after_init
). [C-SR-2] מומלץ מאוד ליצור באופן אקראי את הפריסה של קוד הליבה זיכרון, וכדי להימנע מחשיפות שעלולות לסכן את הרנדומיזציה (לדוגמה,
CONFIG_RANDOMIZE_BASE
עם אנטרופיה של תוכנת האתחול דרך/chosen/kaslr-seed Device Tree node
אוEFI_RNG_PROTOCOL
).[C-SR-3] מומלץ מאוד להפעיל את תקינות הזרימה (CFI) ב- הליבה לספק הגנה נוספת מפני התקפות שימוש חוזר בקוד (למשל
CONFIG_CFI_CLANG
ו-CONFIG_SHADOW_CALL_STACK
).[C-SR-4] מומלץ מאוד לא להשבית את שלמות האפליקציה (CFI), Shadow Call Stack (SCS) או Integer Overflow Sanitization (IntSan) פועל הרכיבים שבהם היא הופעלה.
[C-SR-5] מומלץ מאוד להפעיל את CFI, SCS ו-IntSan בכל רכיבים נוספים הרגישים מבחינת אבטחה למרחב המשתמשים, כמו שמוסבר CFI וגם IntSan.
[C-SR-6] מומלץ מאוד להפעיל אתחול סטאק בליבה (kernel) כדי למנוע שימושים במשתנים מקומיים לא מאותחלים (
CONFIG_INIT_STACK_ALL
אוCONFIG_INIT_STACK_ALL_ZERO
). כמו כן, יישומים של מכשירים לא צריכים להניח את הערך שמשמש את המהדר כדי לאתחל את המקומיים.[C-SR-7] מומלץ מאוד להפעיל אתחול ערימה בליבה (kernel) כדי למנוע שימושים בהקצאות אינסופיות של תמונת מצב של הזיכרון (
CONFIG_INIT_ON_ALLOC_DEFAULT_ON
) והם לא צריכים להניח את הערך שמשמש את הליבה לאתחול ההקצאות האלה.
אם יישומים של מכשירים משתמשים בליבה (kernel) של Linux שמסוגלת לתמוך SELinux:
- [C-1-1] חובה להטמיע את SELinux.
- [C-1-2] חייבים להגדיר את SELinux למצב אכיפה גלובלי.
- [C-1-3] חובה להגדיר את כל הדומיינים במצב אכיפה. אין מצב מתירנות מותרים דומיינים, כולל דומיינים ספציפיים למכשיר או לספק.
- [C-1-4] אסור לשנות, להשמיט או להחליף את הכללים הקיימים של אף פעם בתיקיית המערכת/sepolicy שסופקה ב-upstream ב-Android Open Source הפרויקט (AOSP) והמדיניות חייבים להיות מורכבים מכל הכללים הקיימים של אף פעם, גם לדומיינים של AOSP SELinux וגם לדומיינים ספציפיים למכשיר/לספק.
- [C-1-5] חייבות להפעיל אפליקציות של צד שלישי שמטרגטות לרמת API 28 ומעלה בארגזי Sandbox של SELinux לכל אפליקציה, עם הגבלות SELinux לכל אפליקציה לספריית המידע הפרטי של האפליקציה.
- מדיניות ברירת המחדל של SELinux אמורה להישאר כפי שהוגדרה במערכת או במדיניות של פרויקט הקוד הפתוח של Android ב-upstream ולהוסיף לו רק המדיניות הספציפית למכשיר שלהם.
אם בהטמעות של מכשירים נעשה שימוש בליבה (kernel) שאינה Linux או Linux ללא SELinux, הם:
- [C-2-1] חובה להשתמש במערכת בקרת גישה הכרחית ל-SELinux.
אם הטמעות של מכשירים עושות שימוש במכשירי קלט/פלט (I/O) שתומכים ב-DMA:
- [C-SR-9] מומלץ מאוד לבודד כל מכשיר קלט/פלט (I/O) שמסוגל להפר חוק ה-DMA, באמצעות IOMMU (למשל ARM SMMU).
ב-Android יש כמה תכונות של הגנה לעומק שהן חלק בלתי נפרד מהמכשיר אבטחה. בנוסף, מערכת Android מתמקדת בצמצום הסוגים העיקריים של באגים נפוצים שתורמים לאיכות נמוכה ולאבטחה נמוכה.
כדי לצמצם באגים בזיכרון, הטמעות במכשירים:
- [C-SR-10] מומלץ מאוד לבדוק אותם באמצעות שגיאת זיכרון במרחב המשתמש כלי זיהוי כמו MTE למכשירי ARMv9, HWASan למכשירי ARMv8+ או ASan. לסוגים אחרים של מכשירים.
- [C-SR-11] מומלץ מאוד לבדוק אותם באמצעות שגיאת זיכרון ליבה (kernel) כלי זיהוי כמו KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS עבור מכשירי ARMv9, CONFIG_KASAN_SW_TAGS למכשירי ARMv8 או CONFIG_KASAN_GENERIC עבור סוגי מכשירים אחרים).
- [C-SR-12] מומלץ מאוד להשתמש בכלים לזיהוי שגיאות זיכרון בסביבת ייצור כמו MTE, GWP-ASan ו-KFENCE.
אם בהטמעות במכשירים נעשה שימוש בסביבת TEE שמבוססת על Arm TrustZone:
- [C-SR-13] מומלץ מאוד להשתמש בפרוטוקול סטנדרטי לזיכרון בין Android לסביבת ה-TEE, כגון Arm Firmware Framework Armv8-A (FF-A).
- [C-SR-14] מומלץ מאוד להגביל אפליקציות מהימנות רק לגשת לזיכרון שכבר שותף איתם באופן מפורש דרך של Google. אם המכשיר תומך ברמת החריגה Arm S-EL2, ייאכף על ידי מנהל המחיצות המאובטחות. אחרת, זה צריך להיות נאכף על ידי מערכת ההפעלה TEE.
9.8. פרטיות
9.8.1. היסטוריית שימוש
מערכת Android שומרת את ההיסטוריה של הבחירות של המשתמש ומנהלת את ההיסטוריה הזו על ידי UsageStatsManager.
הטמעות מכשירים:
- [C-0-1] חובה לשמור על תקופת שמירה סבירה של היסטוריית משתמשים כזו.
- [C-SR-1] מומלץ מאוד לשמור על תקופת השמירה של 14 ימים מוגדר כברירת מחדל בהטמעת ה-AOSP.
אירועי המערכת נשמרים ב-Android באמצעות StatsLog
ולנהל היסטוריה כזו באמצעות StatsManager
IncidentManager
System API.
הטמעות מכשירים:
- [C-0-2] חובה לכלול רק את השדות המסומנים ב-
DEST_AUTOMATIC
דוח אירוע שנוצר על ידי מחלקת ה-System APIIncidentManager
. - [C-0-3] אסור להשתמש במזהי האירועים של המערכת כדי לתעד אירועים אחרים
ממה שמתואר במאמר
StatsLog
מסמכי SDK. אם נרשמים עוד אירועי מערכת, יכול להיות שהם ישתמשו טווח של 100,000 עד 200,000.
9.8.2. מתבצעת הקלטה
הטמעות מכשירים:
- [C-0-1] אסור לטעון מראש או להפיץ רכיבי תוכנה שנמצאים מחוץ לאריזה לשלוח את המידע הפרטי של המשתמש (למשל הקשות, טקסט שמוצג מסך, דוח על באג) מהמכשיר ללא הסכמת המשתמש או מחיקה התראות מתמשכות.
- [C-0-2] חובה להציג ולקבל הסכמה מפורשת מהמשתמשים כדי לאפשר תכנים רגישים
מידע שמוצג על מסך המשתמש לתיעוד בכל פעם
הפעלת Cast של התוכן או הקלטת המסך דרך
MediaProjection
או ממשקי API קנייניים. אסור לספק למשתמשים אפשרות להשבית אפליקציות עתידיות הצגת ההסכמה של המשתמש. - [C-0-3] חייבת להיות התראה מתמשכת למשתמש בזמן הפעלת Cast של התוכן במסך או הקלטת המסך מופעלות. AOSP עומד בדרישה הזו באמצעות הצגת סמל התראה מתמשכת בשורת הסטטוס.
אם הטמעות של מכשירים כוללות פונקציונליות במערכת,
מתעד את התוכן שמוצג במסך ו/או מקליט את שידור האודיו
יופעלו במכשיר שלא באמצעות ה-System API ContentCaptureService
, או
אמצעים קנייניים אחרים שמתוארים
סעיף 9.8.6 תיעוד תוכן:
- [C-1-1] חייבת להיות התראה מתמשכת למשתמש בכל פעם מופעלת ומקליטה/להקליט באופן פעיל.
אם הטמעות המכשיר כוללות רכיב שמופעל מוכן לשימוש, יכול הקלטת צלילי אווירה ו/או הקלטה של האודיו שמופעל במכשיר כדי להסיק מידע מועיל על ההקשר של המשתמש, הם:
- [C-2-1] אסור לאחסן באחסון מתמיד במכשיר או לשדר את האודיו הגולמי שהוקלט או כל פורמט שניתן להמיר בחזרה את האודיו המקורי או קרוב אליו, אלא אם קיבלת הסכמה מפורשת מהמשתמש.
'אינדיקטור של מיקרופון' מתייחס לצפייה במסך שגלוי תמיד למשתמש ולא ניתן לטשטש או להסתיר, כי המשתמשים מבינים כי נמצא בהם מיקרופון להשתמש בו(באמצעות טקסט, צבע, סמל או שילוב אחר).
'אינדיקטור מצלמה' מתייחס לתצוגה על המסך, שגלוית כל הזמן את המשתמש ולא ניתן לטשטש או להסתיר, כי המשתמשים מבינים כי המצלמה נמצאת בשימוש (באמצעות טקסט, צבע, סמל או שילוב אחר).
לאחר הצגת השנייה הראשונה, האינדיקטור יכול להשתנות באופן חזותי, כמו קטן יותר, ואין צורך להציג אותו כפי שהוצג במקור להבין.
יכול להיות שהאינדיקטור של המיקרופון ימוזג עם מצלמה שמוצגת באופן פעיל בתנאי שהטקסט, הסמלים או הצבעים מציינים למשתמש השימוש במיקרופון התחיל.
יכול להיות שהאינדיקטור של המצלמה ימוזג עם מיקרופון שמוצג באופן פעיל בתנאי שהטקסט, הסמלים או הצבעים מציינים למשתמש התחיל השימוש במצלמה.
אם הטמעות המכשירים מצהירות על android.hardware.microphone
, הן:
- [C-SR-1] מומלץ מאוד להציג אינדיקטור של מיקרופון כשאפליקציה
ניגש לנתוני אודיו מהמיקרופון, אבל לא כשהמיקרופון
הגישה מתבצעת רק דרך
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
, או האפליקציות בעלות התפקידים שצוינו בסעיף 9.1 הרשאות עם מזהה CDD [C-3-X]. . - [C-SR-2] מומלץ מאוד להציג את הרשימה של 'אחרונים' ו'פעילים'
אפליקציות שמשתמשות במיקרופון כפי שהוחזר
PermissionManager.getIndicatorAppOpUsageData()
, יחד עם כל שיוך (Attribution) הודעות שמשויכות אליהם. - [C-SR-3] מומלץ מאוד לא להסתיר את האינדיקטור של המיקרופון אפליקציות מערכת עם ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמשים.
אם הטמעות המכשירים מצהירות על android.hardware.camera.any
, הן:
- [C-SR-4] מומלץ מאוד להציג אינדיקטור של המצלמה כשהאפליקציה גישה לנתוני המצלמה בשידור חי, אבל לא כשניגשים למצלמה בלבד על ידי אפליקציות בעלות התפקידים שצוינו בסעיף 9.1 הרשאות עם CDD מזהה [C-3-X].
- [C-SR-5] מומלץ מאוד להציג אפליקציות פעילות ואפליקציות מהזמן האחרון באמצעות
מצלמה כפי שהוחזרה מ-
PermissionManager.getIndicatorAppOpUsageData()
, יחד עם הודעות השיוך (Attribution) שמשויכות אליהן. - [C-SR-6] מומלץ מאוד לא להסתיר את האינדיקטור של המצלמה אפליקציות עם ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמשים.
9.8.3. קישוריות
אם בהטמעות המכשיר יש יציאת USB עם תמיכה במצב ציוד היקפי בחיבור USB. הם:
- [C-1-1] חובה להציג ממשק משתמש כדי לבקש את הסכמת המשתמש לפני מאפשרת גישה לתוכן האחסון המשותף דרך יציאת ה-USB.
9.8.4. תנועה ברשת
הטמעות מכשירים:
- [C-0-1] חובה להתקין מראש את אותם אישורי בסיס בשביל המערכת המהימנה אחסון של רשות האישורים (CA) כפי שסיפק בפרויקט קוד פתוח של Android ב-upstream.
- [C-0-2] חובה לשלוח את המוצר עם חנות בסיס ריקה של משתמש שמנפיקה את האישורים (CA).
- [C-0-3] חייבת להופיע אזהרה למשתמש שמציינת את התנועה ברשת עשוי להיות מנוטר, כשמוסיפים רשות אישורים ברמה הבסיסית של משתמש.
אם התנועה במכשירים מנותבת דרך VPN, הטמעות המכשירים:
- [C-1-1] חובה להציג למשתמש אזהרה שמציינת:
- ייתכן שיש מעקב אחרי התנועה הזו ברשת.
- התנועה ברשת הזו מנותבת דרך רשת ה-VPN הספציפית אפליקציה שמספקת את ה-VPN.
אם להטמעות של מכשירים יש מנגנון שמוגדר מחוץ לאריזה כברירת מחדל,
מנתבת את תעבורת נתוני הרשת דרך שרת proxy או שער VPN (לדוגמה,
טוענים מראש שירות VPN עם אישור android.permission.CONTROL_VPN
), הם:
- [C-2-1] חובה לבקש את הסכמת המשתמש לפני הפעלת המנגנון הזה.
אלא אם ה-VPN מופעל על ידי בקר מדיניות המכשיר דרך
DevicePolicyManager.setAlwaysOnVpnPackage()
, במקרה כזה המשתמש לא צריך לתת הסכמה נפרדת, אבל חובה לקבל הודעה בלבד.
אם הטמעות המכשירים מביאות בחשבון את היתרונות של המשתמשים כדי להפעיל "VPN שפועל כל הזמן" באפליקציית VPN של צד שלישי:
- [C-3-1] חובה להשבית את הקריטריונים של המשתמש הזה לאפליקציות שאינן תומכות
שירות VPN שפועל כל הזמן בקובץ
AndroidManifest.xml
על ידי הגדרתSERVICE_META_DATA_SUPPORTS_ALWAYS_ON
ל-false
.
9.8.5. מזהי המכשיר
הטמעות מכשירים:
- [C-0-1] חובה למנוע גישה למספר הסידורי של המכשיר, וגם
רלוונטי, IMEI/MEID, מספר סידורי של SIM ונייד בינלאומי
זהות המנוי (IMSI) מאפליקציה, אלא אם היא עומדת באחד מהקריטריונים הבאים
דרישות:
- היא אפליקציית ספק חתומה שאומתה על ידי יצרני מכשירים.
- קיבל את ההרשאה
READ_PRIVILEGED_PHONE_STATE
. - יש הרשאות ספק כפי שמוגדר בהרשאות ספק ב-UICC.
- הוא בעל מכשיר או בעל פרופיל, שקיבלו את ההרשאה
ההרשאה
READ_PHONE_STATE
. - (למספר הסידורי של כרטיס ה-SIM/ל-ICCID בלבד) יש את דרישת התקנות המקומיות שהאפליקציה מזהה שינויים בזהות של המנוי.
9.8.6. תיעוד תוכן וחיפוש אפליקציות
ב-Android, באמצעות ה-System API ContentCaptureService
,
AugmentedAutofillService
, AppSearchGlobalManager.query
או אחר
אמצעים קנייניים, שתומכים במנגנון להטמעת מכשירים
את האינטראקציות הבאות של נתוני אפליקציות בין האפליקציות
המשתמש:
- טקסט וגרפיקה שמופיעים במסך, כולל, בין היתר,
התראות ונתוני סיוע דרך
AssistStructure
API. - נתוני מדיה, כמו אודיו או וידאו, מוקלטים או מופעלים על ידי המכשיר.
- אירועי קלט (למשל מקש, עכבר, תנועה, קול, וידאו ונגישות).
- כל אירוע אחר שאפליקציה מספקת למערכת דרך
Content Capture
או API שלAppSearchManager
, ל-Android עם יכולות דומות של ממשק ה-API הקנייניים. - כל טקסט או נתונים אחרים שנשלחים דרך
TextClassifier API
ל-System TextClassifier, כלומר לשירות המערכת כדי להבין המשמעות של הטקסט, וגם יצירת פעולות חזויות הבאות על סמך של הטקסט. - נתונים שנוספו לאינדקס על ידי ההטמעה של AppSearch, כולל, בין היתר מוגבלים לטקסט, גרפיקה, נתוני מדיה או נתונים דומים אחרים.
אם הטמעות במכשירים מתעדים את הנתונים שלמעלה, הן:
- [C-1-1] חובה להצפין את כל הנתונים האלה כשהם מאוחסנים במכשיר. הזה עשויה להתבצע באמצעות הצפנה המבוססת על קבצים ב-Android, או מהצופנים שרשומים כ-API בגרסה 26 ואילך שמתוארים ב-Cipher SDK.
- [C-1-2] אסור לגבות נתונים גולמיים או מוצפנים באמצעות שיטות גיבוי ל-Android או כל סוג אחר של גיבוי למעלה.
- [C-1-3] חובה לשלוח את כל הנתונים האלה ואת היומן של המכשיר רק באמצעות
מנגנון לשמירה על הפרטיות. המנגנון לשמירה על הפרטיות
מוגדרים בתור 'כלים שמאפשרים ניתוח מצטבר בלבד ומניעת
התאמה של אירועים רשומים או תוצאות נגזרות למשתמשים נפרדים", כדי
למנוע הצגה של נתונים לכל משתמש באופן פנימי (למשל, הטמעת נתונים
טכנולוגיה דיפרנציאלית של פרטיות כמו
RAPPOR
). - [C-1-4] אסור לשייך נתונים כאלה לזהות משתמש כלשהי (
בתור
Account
) במכשיר, אלא אם התקבלה הסכמה מפורשת מהמשתמש בכל פעם שהנתונים שמשויכים לכל אחד. - [C-1-5] אסור לשתף נתונים כאלה עם רכיבי מערכת הפעלה אחרים שלא לפעול לפי הדרישות המפורטות בקטע הנוכחי (9.8.6 תיעוד תוכן), אלא אם מתקבלת הסכמה מפורשת מהמשתמש בכל פעם הוא משותף.
- [C-1-6] חובה לספק למשתמשים אפשרות למחוק נתונים כאלה
ContentCaptureService
או אמצעים קנייניים אוספים אם מאוחסנים במכשיר בכל צורה שהיא. - [C-1-7] חובה לספק למשתמש אפשרות לבטל את ההסכמה לשימוש בנתונים שנאספים באמצעות AppSearch או באמצעים קנייניים להצגה בפלטפורמת Android. למשל, מרכז האפליקציות.
- [C-SR-1] מומלץ מאוד לא לבקש את הרשאת האינטרנט.
- [C-SR-2] מומלץ מאוד לגשת לאינטרנט רק דרך ממשקי API מובנים המגובים על ידי הטמעות קוד פתוח שזמינות לציבור.
אם הטמעות המכשירים כוללות שירות שמטמיע את System API
ContentCaptureService
, AppSearchManager.index
או כל שירות קנייני
שלוכלת את הנתונים כפי שמתואר למעלה, היא:
- [C-2-1] אסור לאפשר למשתמשים להחליף את השירותים יישום או שירות שניתנים להתקנה על-ידי המשתמש, וחייבים לאפשר רק שהותקנו מראש כדי לתעד נתונים כאלה.
- [C-2-2] אסור להפעיל אפליקציות מלבד השירותים שהותקנו מראש כדי לאפשר תיעוד של נתונים כאלה.
- [C-2-3] חובה לספק למשתמשים אפשרות להשבית את השירותים כל הזמן.
- [C-2-4] אסור להשמיט את תקציב המשתמשים לניהול הרשאות ב-Android מוחזקים על ידי השירותים ופועלים לפי ההרשאות ב-Android כפי שמתואר בסעיף 9.1. הרשאה.
[C-SR-3] מומלץ מאוד לשמור על הפרדה בין השירותים השונים רכיבי המערכת(למשל, לא מתבצע קישור של השירות או מזהים של תהליך השיתוף) חוץ מהדברים הבאים:
- טלפוניה, אנשי קשר, ממשק משתמש של המערכת ומדיה
מערכת Android, דרך SpeechRecognizer#onDeviceSpeechRecognizer()
, מאפשרת
כדי לבצע זיהוי דיבור במכשיר ללא חיבור לרשת.
כל הטמעה של SpeechRecognizer במכשיר חייבת לעמוד בכללי המדיניות
שמפורטות בקטע הזה.
9.8.7. גישה ללוח
הטמעות מכשירים:
- [C-0-1] אסור להחזיר נתונים שנחתכו מהלוח (למשל דרך
ClipboardManager
API), אלא אם האפליקציה של צד שלישי היא ה-IME המוגדר כברירת מחדל או שהיא האפליקציה מתמקד כרגע. - [C-0-2] חובה לנקות נתונים מהלוח 60 דקות לכל היותר אחרי המועד האחרון להיות בלוח או לקרוא מלוח העריכה.
9.8.8. מיקום
המיקום כולל מידע בקטגוריית המיקום של Android( כגון קו רוחב, קו אורך, גובה), וכן מזהים שניתן להמיר למיקום. המיקום יכול להיות מדויק כמו DGPS (מערכת מיקום גלובלית דיפרנציאלית) או משוער כמיקומים ברמת המדינה (כגון מיקום קוד המדינה - חשבון ניהול - נייד קוד מדינה).
בהמשך מופיעה רשימה של סוגי מיקומים שנגזרים באופן ישיר או שניתן להמיר אותו למיקום של משתמש. זה לא מידע מקיף , אבל צריך לשמש כדוגמה לאופן שבו המיקום יכול באופן ישיר או נגזרות באופן עקיף מ:
- GPS/GNSS/DGPS/PPP
- פתרון מיקום גלובלי או מערכת ניווט לוויינית גלובלית, או פתרון דיפרנציאלי למיקום גלובלי
- זה כולל גם מדידות של GNSS גולמיות וסטטוס GNSS
- ניתן לגזור את המיקום המדויק ממדידות GNSS גולמיות
- טכנולוגיות אלחוטיות עם מזהים ייחודיים כמו:
- נקודות גישה של Wi-Fi (MAC , BSSID , שם או SSID)
- Bluetooth/BLE (MAC, BSSID, שם או SSID)
- UWB (MAC, BSSID, שם או SSID)
- מזהה מגדל תקשורת (3G, 4G, 5G... כולל כל המודם הסלולרי בעתיד טכנולוגיות שיש להן מזהים ייחודיים)
למידע נוסף, כדאי לעיין בממשקי ה-API של Android שמחייבים הרשאות ACCESS_FINE_Location או ACCESS_COARSE_Location.
הטמעות מכשירים:
- [C-0-1] אסור להפעיל או להשבית את הגדרות המיקום של המכשיר ואת החיבור ל-Wi-Fi/Bluetooth של סריקת הגדרות ללא הסכמה מפורשת של המשתמש או יוזמת משתמש.
- [C-0-2] חייבת להיות למשתמשים אפשרות לגשת למיקום רלוונטי מידע כולל בקשות מיקום אחרונות, הרשאות ברמת האפליקציה ושימוש חיפוש נקודות Wi-Fi/Bluetooth לקביעת המיקום.
- [C-0-3] חובה לוודא שהאפליקציה משתמשת בממשק API של עקיפת מיקום במצב חירום [LocationRequest.setLocationSettingsignored()] הוא מצב חירום ביוזמת המשתמש (למשל, חייג 911 או טקסט ל-911). עם זאת, בכלי רכב עשויים להופיע להתחיל סשן חירום ללא אינטראקציה פעילה של המשתמש במקרה זוהתה תאונה/תאונה (למשל, כדי למלא את דרישות eCall).
- [C-0-4] חובה לשמר את היכולת של 'המעקף של מיקום החירום' לעקוף את הגדרות המיקום של המכשיר מבלי לשנות את ההגדרות.
- [C-0-5] חובה לתזמן התראה שתזכיר למשתמש אחרי שהאפליקציה נשלחה
הרקע ניגש למיקום שלו באמצעות
הרשאה [
ACCESS_BACKGROUND_LOCATION
].
9.8.9. אפליקציות מותקנות
אפליקציות ל-Android שמטרגטות לרמת API 30 ומעלה לא יכולות לראות פרטים על הגדרות אחרות אפליקציות מותקנות כברירת מחדל (מידע נוסף על הרשאות גישה לחבילה ב-Android מסמכי תיעוד בנושא SDK).
הטמעות מכשירים:
- [C-0-1] אסור לחשוף אפליקציות לאפליקציות שמטורגטות לרמת API 30 ומעלה על אפליקציות מותקנות אחרות, אלא אם האפליקציה כבר יכולה לראות את הפרטים על האפליקציה המותקנת האחרת באמצעות ממשקי ה-API המנוהלים. זה כולל אבל הוא לא מוגבל לפרטים שנחשפים על ידי ממשקי API מותאמים אישית שנוספו על ידי המכשיר. אחר, או לגשת אליו דרך מערכת הקבצים.
- [C-0-2] אסור לתת לאף אפליקציה גישת קריאה או כתיבה לקבצים
הספרייה הייעודית שספציפית לאפליקציה של האפליקציה
באחסון חיצוני. המקרים החריגים היחידים הם:
- הרשות של ספק האחסון החיצוני (למשל, אפליקציות כמו DocumentsUI).
- ספק הורדות שמשתמש בהרשאת הספק של 'הורדות' עבור מורידה קבצים לאחסון של האפליקציה.
- אפליקציות של פרוטוקול העברת מדיה (MTP) בחתימת פלטפורמה שמשתמשות הרשאה בעלת הרשאות ACCESS_MTP כדי לאפשר העברת קבצים אל במכשיר אחר.
- אפליקציות שמתקנות אפליקציות אחרות ושיש להן הרשאה INSTALL_PACKAGES יכולים לגשת רק לספריות "obb" לצורך ניהול קובצי הרחבת APK.
9.8.10. דוח על באג בקישוריות
אם בהטמעות המכשירים מוצהר על דגל התכונה android.hardware.telephony
,
הם:
- [C-1-1] חייבת להיות תמיכה ביצירת דוחות על באגים בקישוריות באמצעות
BUGREPORT_MODE_TELEPHONY
עם BugreportManager. - [C-1-2] חובה לקבל הסכמה מהמשתמש בכל פעם ש-
BUGREPORT_MODE_TELEPHONY
ששימשו ליצירת דוח ואסור להם לבקש מהמשתמש להביע הסכמה בקשות עתידיות מהאפליקציה. - [C-1-3] אסור להחזיר את הדוח שנוצר לאפליקציה שממנה נשלחה הבקשה את ההסכמה המפורשת של המשתמשים.
- [C-1-4] דוחות שנוצרו באמצעות
BUGREPORT_MODE_TELEPHONY
חייבים להכיל את הפרטים הבאים, לכל הפחות:- פלט של
TelephonyDebugService
- פלט של
TelephonyRegistry
- פלט של
WifiService
- פלט של
ConnectivityService
- קובץ dump של המכונה של
CarrierService
של חבילת השיחות (אם רלוונטי) - מאגר נתונים זמני של רדיו
- פלט של
- [C-1-5] אסור לכלול את הפרטים הבאים בדוחות שנוצרו:
- כל סוג של מידע שלא קשור ישירות לקישוריות ניפוי באגים.
- כל סוג של יומני תנועה של אפליקציות שהותקנו על ידי המשתמשים או פרופילים מפורטים של האפליקציות/החבילות שהותקנו על ידי המשתמשים (מזהי UID מותר, שמות החבילות הם לא).
- עשויים לכלול מידע נוסף שלא משויך לאף משתמש זהות. (למשל, יומנים של ספקים).
אם ההטמעות במכשירים כוללות מידע נוסף (למשל, יומני ספקים) דיווחים על באגים, והמידע הזה כולל פרטיות/אבטחה/סוללה/אחסון/זיכרון וכך:
- [C-SR-1] מומלץ מאוד להגדיר מפתח כברירת מחדל
מושבת. יישום העזר של ה-AOSP תואם לכך על ידי מתן
Enable verbose vendor logging
אפשרות לכלול בהגדרות המפתח עוד יומני ספקים שספציפיים למכשיר בדוחות איתור באגים.
9.8.11. שיתוף blobs נתונים
Android, באמצעות BlobStoreManager מאפשרת לאפליקציות לתרום blobs של נתונים למערכת ולשתף אותם עם קבוצת אפליקציות.
אם בהטמעות במכשירים יש תמיכה ב-blobs משותפים של נתונים, כפי שמתואר מסמכי התיעוד של ה-SDK, הם:
- [C-1-1] אסור לשתף blobs של נתונים ששייכים לאפליקציות מעבר למה שהם נועד לאפשר (כלומר, היקף גישת ברירת המחדל והגישה האחרת מצבים שאפשר לציין באמצעות BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess(), או BlobStoreManager.session#allowPublicAccess() אין לשנות). הטמעת קובץ העזר של AOSP עומדת בדרישות הבאות: בדרישות שלנו.
- [C-1-2] אסור לשלוח את הגיבובים המאובטחים מהמכשיר או לשתף אותם עם אפליקציות אחרות של blobs של נתונים (המשמשים לשליטה בגישה).
9.8.12. זיהוי מוזיקה
Android, באמצעות System API MusicRecognitionManager, תומך במנגנון במכשירים שונים כדי לבקש זיהוי מוזיקה, בהינתן הקלטת אודיו, להאציל את זיהוי המוזיקה לאפליקציה בעלת הרשאות שמטמיעה את ממשק ה-API של MusicRecognitionService.
אם הטמעות המכשירים כוללות שירות שמטמיע את System API MusicRecognitionManager או כל שירות קנייני שמשדר נתוני אודיו בתור כמתואר לעיל, הן:
- [C-1-1] חובה לאכוף את הדרישה שהקוראים של MusicRecognitionManager מחזיקים את
הרשאה מסוג
MANAGE_MUSIC_RECOGNITION
- [C-1-2] חובה לאכוף זיהוי מוזיקה אחד שמותקן מראש מטמיעים את MusicRecognitionService.
- [C-1-3] אסור לאפשר למשתמשים להחליף את MusicRecognitionManagerService או MusicRecognitionService עם אפליקציה או שירות שניתנים להתקנה על ידי המשתמש.
- [C-1-4] חובה לוודא שכאשר MusicRecognitionManagerService ניגש אל הקלטת האודיו ומעבירה אותה לאפליקציה שבה מטמיעים MusicRecognitionService, המעקב אחרי הגישה לאודיו על ידי הפעלות של AppOpsManager.noteOp / startOp.
אם יישומים של MusicRecognitionManagerService או של המכשיר MusicRecognitionService מאחסן את כל נתוני האודיו שהוקלטו, למשל:
- [C-2-1] אסור לאחסן בדיסק טביעות אצבע של אודיו או אודיו גולמיים, או בזיכרון למשך יותר מ-14 יום.
- [C-2-2] אסור לשתף נתונים כאלה מעבר ל-MusicRecognitionService, למעט עם הסכמה מפורשת של המשתמש בכל פעם שהוא משותף.
9.8.13. מנהל הפרטיות של החיישנים
אם יישומים של מכשירים מאפשרים למשתמש להשבית את התוכנה בתשלום את קלט המצלמה או המיקרופון להטמעת המכשיר, הם:
- [C-1-1] חובה להחזיר את הערך 'true' באופן מדויק של התשובות הרלוונטיות supportsSensorToggle() שיטת ה-API.
- [C-1-2] חובה, כשאפליקציה מנסה לגשת למיקרופון או למצלמה חסומים, להציג למשתמש מחיר לא ניתן לביטול, שברור מציין שהחיישן חסום ודורש בחירה כדי להמשיך חסימה או ביטול חסימה, בהתאם להטמעה של ה-AOSP שעומדת לדרישה.
- [C-1-3] חובה להעביר לאפליקציות נתוני מצלמה ואודיו ריקים (או מזויפים) ולא לדווח על קוד שגיאה כי המשתמש לא מפעיל את המצלמה או מיקרופון באמצעות תקציב המשתמש שמוצג לפי [C-1-2] למעלה.
9.9. הצפנה של מאגר הנתונים
כל המכשירים חייבים לעמוד בדרישות של סעיף 9.9.1. מכשירים שהופעלו ברמת API מוקדמת יותר מזו של המסמך הזה פטור מהדרישות של הסעיפים 9.9.2 ו-9.9.3; במקום זאת, חייב לעמוד בדרישות המפורטות בסעיף 9.9 של תאימות Android מסמך הגדרה שתואם לרמת ה-API שבה המכשיר הושק.
9.9.1. הפעלה ישירה
הטמעות מכשירים:
[C-0-1] חובה להטמיע את ממשקי ה-API של מצב הפעלה ישירה גם אם הם לא תומכים בהצפנת אחסון.
[C-0-2]
ACTION_LOCKED_BOOT_COMPLETED
ו-ACTION_USER_UNLOCKED
עדיין חייבים לשדר אובייקטים מסוג Intent כדי לאותת לאפליקציות שמודעות להפעלה ישירה מיקומי האחסון בהצפנת מכשיר (DE) ובהצפנת פרטי כניסה (CE) הם זמין למשתמש.
9.9.2. דרישות לגבי הצפנה
הטמעות מכשירים:
- [C-0-1] חובה לה