הגדרת תאימות ל-Android 11

1. מבוא

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

השימוש במונחים MUST,‏ MUST NOT,‏ REQUIRED,‏ SHALL,‏ SHALL NOT,‏ SHOULD,‏ SHOULD NOT,‏ RECOMMENDED,‏ MAY ו-OPTIONAL הוא בהתאם לתקן IETF שמוגדר ב-RFC2119.

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

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

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

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

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

‫1.1 מבנה המסמך

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

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

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

‫1.1.2. מזהה הדרישה

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

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

כל מזהה מוגדר באופן הבא:

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

‫1.1.3. מזהה הדרישה בחלק 2

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1. חומרה

הטמעות במכשירים שניתן להחזיק ביד:

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

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

• ‫[7.1.1.1/H-1-1]* חובה להגדיר את המסך הלוגי שזמין לאפליקציות של צד שלישי כך שיהיה לפחות 2 אינץ' בקצוות הקצרים ו-2.7 אינץ' בקצוות הארוכים. מכשירים שהושקו ברמת API מוקדמת יותר מזו שמופיעה במסמך הזה פטורים מהדרישה הזו.

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

• ‫[7.1.1.1/H-2-1]* חובה להקצות למסך הלוגי שזמין לאפליקציות של צד שלישי לפחות 2.7 אינץ' בקצה הקצר. מכשירים שהושקו ברמת API מוקדמת יותר מזו שמופיעה במסמך הזה פטורים מהדרישה הזו.

אם הטמעות של מכשירים שניתן להחזיק ביד טוענות לתמיכה במסכים עם טווח דינמי גבוה (HDR) באמצעות 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 שמוגדרים במסמכי התיעוד של Perfetto.
• ‫[7.1.4.6/H-1-2] חובה לדווח על ערכים תואמים עבור מוני ה-GPU של המכשיר בהתאם ל-gpu counter trace packet proto.
• ‫[7.1.4.6/H-1-3] חובה לדווח על ערכים תואמים עבור שלבי העיבוד של ה-GPU במכשיר בהתאם ל-render stage trace packet proto.
• ‫[7.1.4.6/H-1-4] חובה לדווח על נקודת מעקב של תדר GPU בפורמט שצוין: power/gpu_frequency.

הטמעות במכשירים שניתן להחזיק ביד:

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

אם יישומים של מכשירים שניתן להחזיק ביד כוללים מד תאוצה ב-3 צירים, הם:

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

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

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

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

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

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

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

הטמעות במכשירים שניתן להחזיק ביד:

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

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

• ‫[7.4.7/H-1-1] חובה לספק את מצב חוסך הנתונים.

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

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

הטמעות במכשירים שניתן להחזיק ביד:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הטמעות במכשירים שניתן להחזיק ביד:

• ‫[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] חובה להצהיר על feature flag‏ android.hardware.vr.high_performance.
• ‫[7.9.1/H-1-2] חובה לכלול אפליקציה שמטמיעה את android.service.vr.VrListenerService שאפשר להפעיל באמצעות אפליקציות VR דרך android.app.Activity#setVrModeEnabled.

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

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

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

כשמזוהים סוגים של מסופי אודיו ב-USB‏ 0x0302, הם:

• ‫[7.8.2.2/H-2-1] המכשיר חייב לשדר Intent ‏ACTION_HEADSET_PLUG עם הערך 0 בתוספת microphone.

כשמזוהים סוגים של נקודות חיבור לאודיו ב-USB‏ 0x0402, המערכת:

• ‫[7.8.2.2/H-3-1] חובה לשדר את Intent ACTION_HEADSET_PLUG עם הערך 1 בתוספת microphone.

כשקוראים ל-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] מומלץ מאוד לבצע ספירה של תיאורי USB, לזהות סוגי מסופים ולשדר את Intent ACTION_HEADSET_PLUG תוך פחות מ-1,000 מילישניות, כשמחברים ציוד היקפי של אודיו מסוג USB-C.

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

• ‫[7.10/H-SR]* מומלץ מאוד לא להשתמש במפעיל הפטיקה (רטט) עם מסה מסתובבת אקסצנטרית(ERM).
• ‫[7.10/H]* מומלץ למקם את המפעיל קרוב למיקום שבו בדרך כלל מחזיקים את המכשיר או נוגעים בו בידיים.
• ‫[7.10/H-SR]* מומלץ מאוד להטמיע את כל הקבועים הציבוריים של משוב הפטי ברור ב-android.view.HapticFeedbackConstants, כלומר (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START ו-GESTURE_END).
• ‫[7.10/H-SR]* מומלץ מאוד להטמיע את כל הקבועים הציבוריים של משוב הפטי ברור ב-android.os.VibrationEffect, כלומר (EFFECT_TICK,‏ EFFECT_CLICK,‏ EFFECT_HEAVY_CLICK ו-EFFECT_DOUBLE_CLICK) ואת כל הקבועים הציבוריים של משוב הפטי עשיר ב-android.os.VibrationEffect.Composition, כלומר (PRIMITIVE_CLICK ו-PRIMITIVE_TICK).
• ‫[7.10/H-SR]* מומלץ מאוד להשתמש במיפויים האלה של קבועי רטט מקושרים.
• ‫[7.10/H-SR]* מומלץ מאוד לבצע הערכת איכות עבור ממשקי ה-API‏ createOneShot() ו-createWaveform().
• ‫[7.10/H-SR]* מומלץ מאוד להריץ את הפונקציה android.os.Vibrator.hasAmplitudeControl() כדי לוודא את היכולות של שינוי עוצמת הרטט.

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

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

• ‫[7.10/H]* צריך להזיז את המפעיל ההפטי בציר X של הכיוון לאורך.

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

• ‫[7.10/H-SR]* מומלץ מאוד שתדירות התהודה של ה-LRA בציר X תהיה מתחת ל-200 הרץ.

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

• ‫[7.10/H-SR]* מומלץ מאוד לבצע הערכת איכות של קבועי משוב הפטי.

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‏ (AAC LC)
• ‫[5.1/H-0-4] פרופיל MPEG-4 HE AAC ‏ (AAC+)
• ‫[5.1/H-0-5] AAC ELD (enhanced low delay AAC)

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

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

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

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

2.2.3. תוכנה

הטמעות במכשירים שניתן להחזיק ביד:

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

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

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

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

• ‫[3.8.4/H-1-1]* חובה להציג התראות על שיחות לפני התראות שלא קשורות לשיחות, למעט התראות על שירותים שפועלים ברקע והתראות עם חשיבות:גבוהה.

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

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

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

• ‫[3.9/H-1-1] חובה להטמיע את כל טווח המדיניות של ניהול המכשיר שמוגדר במסמכי ה-Android SDK.
• ‫[3.9/H-1-2] חובה להצהיר על תמיכה בפרופילים מנוהלים באמצעות android.software.managed_users דגל התכונה, אלא אם המכשיר מוגדר כך שהוא ידווח על עצמו כמכשיר עם RAM נמוך או כך שהוא מקצה אחסון פנימי (שאי אפשר להסיר) כאחסון משותף.

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

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

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

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

הטמעות במכשירים שניתן להחזיק ביד:

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

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

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

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

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

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

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

‫2.2.4. ביצועים וצריכת חשמל

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

הטמעות במכשירים שניתן להחזיק ביד:

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

אם הטמעות של מכשירים שניתן להחזיק ביד כוללות תכונות לשיפור ניהול צריכת החשמל של המכשיר, שנכללות ב-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] חובה להפוך את נתוני צריכת החשמל האלה לזמינים למפתח האפליקציה באמצעות פקודת ה-shell‏ adb shell dumpsys batterystats.
• ‫[8.4/H] צריך לשייך את השימוש בחשמל של רכיב החומרה לרכיב החומרה עצמו אם אי אפשר לשייך אותו לאפליקציה.

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

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

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 כדי לתמוך בצורה תקינה באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בקרנל ומעליו. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד של ליבה או של מרחב משתמשים יכול לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. פרויקט הקוד הפתוח של Android‏ (AOSP) עומד בדרישה הזו באמצעות ההטמעה של Trusty, אבל אפשרות חלופית היא פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת שנבדקה על ידי צד שלישי של בידוד מתאים שמבוסס על היפר-ויז'ר.
• ‫[9.11/H-0-4]* חובה לבצע את האימות במסך הנעילה בסביבת הביצוע המבודדת, ורק אם האימות יצליח, לאפשר את השימוש במפתחות שקשורים לאימות. פרטי הכניסה למסך הנעילה חייבים להיות מאוחסנים באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. פרויקט הקוד הפתוח של Android מספק את שכבת ההפשטה של חומרה (HAL) של Gatekeeper ואת Trusty, שאפשר להשתמש בהם כדי לעמוד בדרישה הזו.
• ‫[9.11/H-0-5]* חובה לתמוך באימות מפתחות, כאשר מפתח החתימה של האימות מוגן על ידי חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה של האימות במספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת הדרכים לעמוד בדרישה הזו היא לשתף את אותו מפתח אישור, אלא אם מיוצרות לפחות 100,000 יחידות של מק"ט נתון. אם מיוצרות יותר מ-100,000 יחידות של מק"ט מסוים, אפשר להשתמש במפתח אחר לכל 100,000 יחידות.

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

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

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

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

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

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

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

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

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

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

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

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

‫2.2.7 Handheld Media Performance Class

הגדרה של סוג ביצועים של מדיה מופיעה בקטע 7.11.

2.2.7.1. מדיה

אם הטמעות של מכשירים ניידים מחזירות android.os.Build.VERSION_CODES.R עבור 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) בכל שילוב של קודקים שפועלים בו-זמנית ברזולוציה של 720p ב-30fps.
• ‫[5.1/H-1-3] חובה לפרסם את המספר המקסימלי של סשנים של מקודד וידאו בחומרה שאפשר להריץ בו-זמנית בכל שילוב של קודקים באמצעות השיטות CodecCapabilities.getMaxSupportedInstances() ו-VideoCapabilities.getSupportedPerformancePoints().
• ‫[5.1/H-1-4] חובה לתמוך ב-6 מקרים של הפעלת מקודד וידאו בחומרה (AVC או HEVC) בכל שילוב של קודקים שפועלים בו-זמנית ברזולוציה של 720p ב-30 פריימים לשנייה.
• ‫[5.1/H-1-5] חובה לפרסם את המספר המקסימלי של הפעלות של מקודד וידאו בחומרה ומפענח וידאו בחומרה שאפשר להפעיל בו-זמנית בכל שילוב של קודקים באמצעות השיטות CodecCapabilities.getMaxSupportedInstances() ו-VideoCapabilities.getSupportedPerformancePoints().
• ‫[5.1/H-1-6] המכשיר חייב לתמוך ב-6 מקרים של פענוח קוד של סרטונים באמצעות חומרה וב-6 סשנים של קידוד סרטונים באמצעות חומרה (AVC או HEVC) בכל שילוב של קודקים שפועלים בו-זמנית ברזולוציה של 720p@30fps.
• ‫[5.1/H-1-7] חובה להשתמש בקידוד וידאו של 1080p או פחות, בכל מפעילי קידוד הווידאו בחומרה (מלבד קידוד Dolby Vision), עם זמן אחזור של 65ms או פחות לאתחול קודק, כשמערכת ההפעלה נמצאת בעומס. העומס מוגדר כאן כסשן בו-זמני של המרת קודק של וידאו בלבד מ-1080p ל-720p באמצעות קודקים של וידאו בחומרה, יחד עם אתחול של הקלטת אודיו ווידאו באיכות 1080p.
• ‫[5.1/H-1-8] חובה להשתמש במקודדי אודיו עם זמן אחזור של 50 מילי-שניות או פחות לאתחול קודק, עבור סשן קידוד אודיו עם קצב העברת נתונים של 128kbps או פחות, בכל מקודדי האודיו, כשהם נמצאים בעומס.עומס מוגדר כאן כסשן מקביל של המרת קידוד של וידאו בלבד מ-1080p ל-720p, באמצעות קודקים של וידאו בחומרה, יחד עם אתחול של הקלטת אודיו ווידאו ב-1080p.
• ‫[5.3/H-1-1] אסור להשמיט יותר מפריים אחד ב-10 שניות (כלומר, פחות מ-0.333 אחוז של השמטת פריימים) בסשן וידאו של 1080p ב-30 פריימים לשנייה בזמן עומס. העומס מוגדר כסשן המרה (transcoding) בו-זמני של סרטון באיכות 1080p לאיכות 720p, ללא אודיו, באמצעות קודקים של וידאו בחומרה, וגם הפעלה של אודיו בפורמט AAC בקצב העברת נתונים של 128kbps.
• ‫[5.3/H-1-2] אסור להשמיט יותר מפריים אחד ב-10 שניות במהלך שינוי רזולוציית וידאו בסשן וידאו של 30fps בעומס. העומס מוגדר כסשן המרה בו-זמני של וידאו בלבד מ-1080p ל-720p באמצעות קודקים של וידאו בחומרה, וגם הפעלה של אודיו בפורמט AAC ב-128Kbps.
• ‫[5.6/H-1-1] זמן האחזור של הקשה להשמעת צליל חייב להיות פחות מ-100 אלפיות השנייה באמצעות הבדיקה 'הקשה להשמעת צליל' ב-OboeTester או ב-CTS Verifier.

2.2.7.2. מצלמה

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

• ‫[7.5/H-1-1] חובה להשתמש במצלמה ראשית שפונה לאחור עם רזולוציה של לפחות 12 מגה-פיקסל שתומכת בצילום וידאו באיכות ‎4k@30fps. המצלמה הראשית שפונה לאחור היא המצלמה האחורית עם מזהה המצלמה הנמוך ביותר.
• ‫[7.5/H-1-2] חובה להשתמש במצלמה ראשית שפונה קדימה עם רזולוציה של 4 מגה-פיקסל לפחות, שתומכת בצילום וידאו ב-‎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 של פחות מ-1,000ms עבור רזולוציית 1080p, כפי שנמדד על ידי בדיקת הביצועים של המצלמה ב-CTS בתנאי התאורה של ITS ‏ (3,000K) עבור שתי המצלמות הראשיות.
• ‫[7.5/H-1-6] זמן האחזור של הפעלת camera2 (פתיחת המצלמה עד למסגרת התצוגה המקדימה הראשונה) חייב להיות < 600ms כפי שנמדד על ידי PerformanceTest של המצלמה ב-CTS בתנאי התאורה של ITS ‏ (3,000K) עבור שתי המצלמות הראשיות.

2.2.7.3. חומרה

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

• ‫[7.1.1.1/H-1-1] חובה שתהיה רזולוציית מסך של 1080p לפחות.
• ‫[7.1.1.3/H-1-1] חובה שהצפיפות במסך תהיה לפחות ‎400 dpi.
• ‫[7.6.1/H-1-1] חייב להיות זיכרון פיזי בנפח 6GB לפחות.

‫2.2.7.4. ביצועים

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

• ‫[8.2/H-1-1] חובה לוודא ביצועי כתיבה רציפים של לפחות 100MB/s.
• ‫[8.2/H-1-2] חובה לוודא ביצועי כתיבה אקראית של לפחות 10MB/s.
• ‫[8.2/H-1-3] חובה לוודא שביצועי הקריאה הסדרתית הם לפחות 200MB/s.
• ‫[8.2/H-1-4] חובה לוודא ביצועי קריאה אקראית של לפחות 25MB/s.

2.3. דרישות לגבי טלוויזיות

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

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

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

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

2.3.1. חומרה

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

• ‫[7.2.2/T-0-1] חובה לתמוך בלחצני ניווט.
• ‫[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] חובה לדווח על אירועים בתדירות של לפחות 100 הרץ.
• ‫[7.3.4/T-1-2] חובה שתהיה אפשרות למדוד שינויים בכיוון עד 1,000 מעלות לשנייה.

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

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

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

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

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

• ‫[7.6.1/T-1-1] הזיכרון שזמין לליבת המערכת ולמרחב המשתמש חייב להיות לפחות 896MB אם נעשה שימוש באחת מהצפיפויות הבאות:

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

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

• ‫[7.6.1/T-2-1] הזיכרון שזמין לליבת המערכת ולמרחב המשתמש חייב להיות לפחות 1,280MB אם נעשה שימוש באחת מהצפיפויות הבאות:

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

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

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

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

‫2.3.2. מולטימדיה

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

• ‫[5.1/T-0-1] פרופיל MPEG-4 AAC‏ (AAC LC)
• ‫[5.1/T-0-2] פרופיל MPEG-4 HE AAC ‏ (AAC+)
• ‫[5.1/T-0-3] AAC ELD (enhanced low delay AAC)

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

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

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

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

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

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

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

• ‫[5.3.1/T-1-1] HD 1080p במהירות של ‎29.97 פריימים לשנייה עם Main Profile High Level.
• ‫[5.3.1/T-1-2] ‏ HD ‏‎1080i‎ ב-‎59.94‎ פריימים לשנייה עם Main Profile High Level. הם חייבים לבטל את השזירה של סרטוני 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 פריימים לשנייה עם High Profile Level 4.2

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

• ‫[5.3.5/T-1-1] HD 1080p בקצב של 60 פריימים לשנייה עם Main Profile Level 4.1

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

• ‫[5.3.5/T-2-1] המכשיר חייב לתמוך בפרופיל הפענוח UHD ב-60 פריימים לשנייה עם פרופיל Main10 Level 5 Main Tier

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

• ‫[5.3.6/T-1-1] פרופיל פענוח HD 1080p בקצב של 60 פריימים לשנייה

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

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

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

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

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

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

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

• ‫[5.8/T-0-1] חובה להגדיר את מצב פלט ה-HDMI כדי לבחור את הרזולוציה המקסימלית שאפשר לתמוך בה עם קצב רענון של 50Hz או 60Hz.
• ‫[5.8/T-SR] מומלץ מאוד לספק למשתמשים אפשרות לבחור את קצב הרענון של 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] חובה לספק הטמעה מלאה של android.webkit.Webview API.

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

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

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

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

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

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

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

• ‫[3.12/T-0-1] חובה לתמוך ב-TV Input Framework (מסגרת קלט לטלוויזיה).

‫2.3.4. ביצועים וצריכת חשמל

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

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

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

אם הטלוויזיה לא כוללת סוללה:

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

אם הטלוויזיה כוללת סוללה:

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

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

• [8.4/T-0-1] חובה לספק פרופיל צריכת חשמל לכל רכיב שמגדיר את ערך צריכת הזרם לכל רכיב חומרה ואת התרוקנות הסוללה המשוערת שנגרמת על ידי הרכיבים לאורך זמן, כפי שמתועד באתר פרויקט קוד פתוח של Android.
• ‫[8.4/T-0-2] חובה לדווח על כל ערכי צריכת החשמל במיליאמפר לשעה (mAh).
• ‫[8.4/T-0-3] חובה לדווח על צריכת החשמל של ה-CPU לכל UID של תהליך. פרויקט הקוד הפתוח של Android עומד בדרישה באמצעות הטמעה של מודול ליבת uid_cputime.
• ‫[8.4/T] צריך לשייך את צריכת החשמל לרכיב החומרה עצמו אם אי אפשר לשייך אותה לאפליקציה.
• ‫[8.4/T-0-4] חובה להפוך את נתוני צריכת החשמל האלה לזמינים למפתח האפליקציה באמצעות פקודת ה-Shell‏ 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 כדי לתמוך בצורה תקינה באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בקרנל ומעליו. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד של ליבה או של מרחב משתמשים יכול לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. פרויקט הקוד הפתוח של Android‏ (AOSP) עומד בדרישה הזו באמצעות ההטמעה של Trusty, אבל אפשרות חלופית היא פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת שנבדקה על ידי צד שלישי של בידוד מתאים שמבוסס על היפר-ויז'ר.
• ‫[9.11/T-0-3] חובה לבצע את האימות במסך הנעילה בסביבת ביצוע מבודדת, ורק אם האימות מצליח, לאפשר שימוש במפתחות שקשורים לאימות. פרטי הכניסה למסך הנעילה חייבים להיות מאוחסנים באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. פרויקט הקוד הפתוח של Android מספק את שכבת ההפשטה של חומרה (HAL) של Gatekeeper ואת Trusty, שאפשר להשתמש בהם כדי לעמוד בדרישה הזו.
• ‫[9.11/T-0-4] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה של האימות מוגן על ידי חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה של האימות במספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת הדרכים לעמוד בדרישה הזו היא לשתף את אותו מפתח אישור, אלא אם מיוצרות לפחות 100,000 יחידות של מק"ט נתון. אם מיוצרות יותר מ-100,000 יחידות של מק"ט מסוים, אפשר להשתמש במפתח אחר לכל 100,000 יחידות.

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

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

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

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

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

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

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

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

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

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

2.4. דרישות לצפייה

מכשיר שעון Android הוא הטמעה של מכשיר Android שמיועד לענידה על הגוף, למשל על פרק כף היד.

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

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

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

2.4.1. חומרה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.2. מולטימדיה

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

2.4.3. תוכנה

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

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

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

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

צפייה בהטמעות במכשירים שמצהירים על תג התכונה android.hardware.audio.output:

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

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

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

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

‫2.4.4. ביצועים וצריכת חשמל

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

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

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

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

‫2.4.5. מודל אבטחה

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

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

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

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

2.5. דרישות בתחום הרכב

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

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

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

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

2.5.1. חומרה

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

• ‫[7.1.1.1/A-0-1] חובה שמכשיר יכלול מסך בגודל של לפחות 6 אינץ' באלכסון פיזי.

• ‫[7.1.1.1/A-0-2] חובה שגודל המסך יהיה לפחות ‎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 חייב להיות זהה למצב יום/לילה בלוח הבקרה, וצריך להתבסס על נתוני חיישן האור הסביבתי. יכול להיות שחיישן האור הרגיש לסביבה זהה לפוטומטר.
• ‫[7.3/A-0-3] חובה לספק את שדה המידע הנוסף על החיישן TYPE_SENSOR_PLACEMENT כחלק מהשדה SensorAdditionalInfo לכל חיישן שמסופק.
• ‫[7.3/A-0-1] המכשיר עשוי להשתמש בחישוב משוער של המיקום על ידי שילוב של GPS/GNSS עם חיישנים נוספים. אם המיקום מחושב באמצעות ניווט אינרציאלי, מומלץ מאוד להטמיע ולדווח על סוגי החיישנים המתאימים ו/או על מזהי מאפייני הרכב שבהם נעשה שימוש.
• ‫[7.3/A-0-2] אסור לבצע התאמה של המיקום שמתקבל באמצעות LocationManager#requestLocationUpdates()‎ למפה.

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

• ‫[7.3.1/A-1-1] חובה לדווח על אירועים בתדירות של לפחות 100 הרץ.
• ‫[7.3.1/A-1-2] חייב להיות תואם למערכת הקואורדינטות של חיישני הרכב ב-Android.

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

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

אם הטמעות של מכשירים לרכב כוללות מקלט 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, או שילוב של שתי האפשרויות.

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

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

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

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

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

מצלמה עם תצוגה חיצונית היא מצלמה שמצלמת סצנות מחוץ למכשיר, כמו מצלמת דרך.

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

• מומלץ לכלול מצלמות עם תצוגה חיצונית אחת או יותר.

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

• ‫[7.5/A-1-1] אסור שיהיו מצלמות עם תצוגה חיצונית שאפשר לגשת אליהן דרך ממשקי ה-API של מצלמת Android, אלא אם הן עומדות בדרישות הליבה של המצלמה.
• ‫[7.5/A-SR] מומלץ מאוד לא לסובב את התצוגה המקדימה של המצלמה או להפוך אותה אופקית.
• ‫[7.5.5/A-SR] מומלץ מאוד למקם את המצלמה כך שהמימד הארוך שלה יהיה מקביל לאופק.
• ‫[7.5/A-SR] מומלץ מאוד שהרזולוציה תהיה לפחות 1.3 מגה-פיקסל.
• צריך להיות בעל חומרה עם מיקוד קבוע או EDOF (עומק שדה מורחב).
• צריכה להיות תמיכה במסגרת הסנכרון של Android.
• יכול להיות שמוטמע במנהל ההתקן של המצלמה פוקוס אוטומטי של חומרה או פוקוס אוטומטי של תוכנה.

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

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

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

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

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

אם יישומי מכשירים לרכב הם 32 ביט:

• ‫[7.6.1/A-1-1] הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 512MB אם נעשה שימוש באחת מהצפיפויות הבאות:

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

• ‫[7.6.1/A-1-2] הזיכרון שזמין לליבת המערכת ולמרחב המשתמש חייב להיות לפחות 608MB אם נעשה שימוש באחת מהצפיפויות הבאות:

  • ‫xhdpi או יותר במסכים קטנים או רגילים
  • ‫hdpi או יותר במסכים גדולים
  • ‫mdpi או יותר במסכים גדולים במיוחד

• ‫[7.6.1/A-1-3] הזיכרון שזמין לליבת המערכת ולמרחב המשתמש חייב להיות לפחות 896MB אם נעשה שימוש באחת מהצפיפויות הבאות:

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

• ‫[7.6.1/A-1-4] הזיכרון שזמין לליבת המערכת ולמרחב המשתמש חייב להיות לפחות 1,344MB אם נעשה שימוש באחת מהצפיפויות הבאות:

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

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

• ‫[7.6.1/A-2-1] הזיכרון שזמין לליבת המערכת ולמרחב המשתמש חייב להיות לפחות 816MB אם נעשה שימוש באחת מהצפיפויות הבאות:

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

• ‫[7.6.1/A-2-2] הזיכרון שזמין לליבת המערכת ולמרחב המשתמש חייב להיות לפחות 944MB אם נעשה שימוש באחת מהצפיפויות הבאות:

  • ‫xhdpi או יותר במסכים קטנים או רגילים
  • ‫hdpi או יותר במסכים גדולים
  • ‫mdpi או יותר במסכים גדולים במיוחד

• ‫[7.6.1/A-2-3] הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 1,280MB אם נעשה שימוש באחת מהצפיפויות הבאות:

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

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

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

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

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

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

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

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

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

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

2.5.2. מולטימדיה

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

• ‫[5.1/A-0-1] פרופיל MPEG-4 AAC ‏ (AAC LC)
• ‫[5.1/A-0-2] פרופיל MPEG-4 HE AAC ‏ (AAC+)
• ‫[5.1/A-0-3] AAC ELD (enhanced low delay AAC)

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

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

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

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

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

• ‫[5.3/A-SR] 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] חובה לספק הטמעה מלאה של android.webkit.Webview API.

• ‫[3.8.3/A-0-1] חובה להציג התראות שמשתמשות ב-API‏ Notification.CarExtender כשמתקבלת בקשה מאפליקציות של צד שלישי.

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

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

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

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

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

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

• ‫[3.14/A-0-1] חובה לכלול מסגרת ממשק משתמש לתמיכה באפליקציות של צד שלישי שמשתמשות בממשקי ה-API של המדיה, כפי שמתואר בקטע 3.14.
• ‫[3.14/A-0-2] המערכת חייבת לאפשר למשתמש אינטראקציה בטוחה עם אפליקציות מדיה בזמן נהיגה.
• ‫[3.14/A-0-3] חובה לתמוך בפעולת ה-Intent המרומזת CAR_INTENT_ACTION_MEDIA_TEMPLATE עם התוסף CAR_EXTRA_MEDIA_PACKAGE.
• ‫[3.14/A-0-4] חובה לספק אמצעי ניווט אל פעילות ההעדפות של אפליקציית מדיה, אבל חובה להפעיל אותו רק כשמגבלות חוויית המשתמש ב-Car לא בתוקף.
• ‫[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] חובה לדווח על מספר הבייטים שנקראו ונכתבו לאחסון לא נדיף לכל מזהה משתמש של תהליך, כדי שהנתונים הסטטיסטיים יהיו זמינים למפתחים דרך System API‏ android.car.storagemonitoring.CarStorageMonitoringManager. פרויקט הקוד הפתוח של Android עומד בדרישה באמצעות מודול הליבה uid_sys_stats.
• ‫[8.3/A-1-3] חובה לתמוך במצב מוסך.
• ‫[8.3/A] צריך להיות במצב חניה למשך 15 דקות לפחות אחרי כל נסיעה, אלא אם:
  • הסוללה מרוקנת.
  • לא מתוזמנות משימות במצב המתנה.
  • הנהג יוצא ממצב חנייה.
• ‫[8.4/A-0-1] חובה לספק פרופיל צריכת חשמל לכל רכיב שמגדיר את ערך צריכת הזרם לכל רכיב חומרה ואת קצב ניקוז הסוללה המשוער שנגרם על ידי הרכיבים לאורך זמן, כפי שמתועד באתר Android Open Source Project.
• ‫[8.4/A-0-2] חובה לדווח על כל ערכי צריכת החשמל במיליאמפר לשעה (mAh).
• ‫[8.4/A-0-3] חובה לדווח על צריכת החשמל של המעבד (CPU) לכל UID של תהליך. פרויקט הקוד הפתוח של Android עומד בדרישה באמצעות הטמעה של מודול ליבת uid_cputime.
• ‫[8.4/A] צריך לשייך את צריכת החשמל לרכיב החומרה עצמו אם אי אפשר לשייך אותה לאפליקציה.
• ‫[8.4/A-0-4] חובה להציג את נתוני צריכת החשמל האלה למפתח האפליקציה באמצעות פקודת ה-Shell‏ adb shell dumpsys batterystats.

‫2.5.5. מודל אבטחה

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

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

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

• ‫[9.11/A-0-1] חובה לגבות את ההטמעה של מאגר המפתחות באמצעות סביבת ביצוע מבודדת.
• ‫[9.11/A-0-2] חובה להטמיע אלגוריתמים קריפטוגרפיים מסוג RSA,‏ AES,‏ ECDSA ו-HMAC ופונקציות גיבוב מסוג MD5,‏ SHA1 ו-SHA-2 כדי לתמוך בצורה תקינה באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בקרנל ומעליו. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד של ליבה או של מרחב משתמשים יכול לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. פרויקט הקוד הפתוח של Android‏ (AOSP) עומד בדרישה הזו באמצעות ההטמעה של Trusty, אבל אפשרות חלופית היא פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת שנבדקה על ידי צד שלישי של בידוד מתאים שמבוסס על היפר-ויז'ר.
• ‫[9.11/A-0-3] חובה לבצע את האימות במסך הנעילה בסביבת הביצוע המבודדת, ורק אם האימות מצליח, לאפשר שימוש במפתחות שקשורים לאימות. פרטי הכניסה למסך הנעילה חייבים להיות מאוחסנים באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. פרויקט הקוד הפתוח של Android מספק את שכבת ההפשטה של חומרה (HAL) של Gatekeeper ואת Trusty, שאפשר להשתמש בהם כדי לעמוד בדרישה הזו.
• ‫[9.11/A-0-4] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה של האימות מוגן על ידי חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה של האימות במספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת הדרכים לעמוד בדרישה הזו היא לשתף את אותו מפתח אישור, אלא אם מיוצרות לפחות 100,000 יחידות של מק"ט נתון. אם מיוצרות יותר מ-100,000 יחידות של מק"ט מסוים, אפשר להשתמש במפתח אחר לכל 100,000 יחידות.

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

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

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

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

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

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

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

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

• השימוש הוא בהחזקה בשתי הידיים.
• לא מדובר במחשב נייד מתקפל או במחשב נייד עם מסך מסתובב.
• הטמעות של מקלדות פיזיות שמשמשות לחיבור המכשיר באמצעות חיבור רגיל (למשל, USB,‏ Bluetooth).
• יש לו מקור כוח שמאפשר ניידות, כמו סוללה.
• גודל המסך באלכסון הוא בין 7 ל-18 אינץ'.

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

2.6.1. חומרה

גודל המסך

• ‫[7.1.1.1/Tab-0-1] חובה שיהיה מסך בטווח של 7 עד 18 אינץ'.

Gyroscope

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

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

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

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

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

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

• ‫[7.7.1/Tab] יכול ליישם את Android Open Accessory (AOA) API.

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

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

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

2.6.2. מודל אבטחה

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

ראו סעיף [9.11].

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

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

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

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

2.6.2. תוכנה

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

3. תוכנה

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

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

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

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

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

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

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

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

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

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

  אבל הם:

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

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 לנתיב המחלקה של האפליקציה רק אם האפליקציה עומדת באחד מהתנאים הבאים:
  • מטרגטת רמת API‏ 28 ומטה.
  • מצהירה במניפסט שלה שהיא צריכה את הספרייה על ידי הגדרת המאפיין android:name של <uses-library> לערך org.apache.http.legacy.

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

3.2. תאימות API רכה

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

3.2.1. הרשאות

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

3.2.2. פרמטרים של Build

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

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

‫3.2.3. תאימות לכוונת החיפוש

3.2.3.1. כוונות נפוצות באפליקציות

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

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

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

בקטע 2 מפורטים ה-intents של האפליקציה שחובה להשתמש בהם לכל סוג מכשיר.

‫3.2.3.2. החלטה לגבי Intent

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

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

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

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

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

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

‫3.2.3.3. מרחבי שמות של כוונות

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

‫3.2.3.4. כוונות לשידור

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

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

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

‫3.2.3.5. הפעלת כוונות מותנית באפליקציות

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

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

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

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

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

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

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

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

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

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

• ‫[C-2-5] חובה לספק למשתמש אפשרות לבחור אפליקציה עם התפקיד android.app.role.CALL_REDIRECTION.
• ‫[C-2-6] האפליקציה חייבת לכבד את מנגנוני ה-Intent‏ android.intent.action.SENDTO ו-android.intent.action.VIEW ולספק פעילות לשליחה או להצגה של הודעות SMS.
• [C-SR] מומלץ מאוד לכבד את ה-Intents‏ android.intent.action.ANSWER, ‏ android.intent.action.CALL, ‏ android.intent.action.CALL_BUTTON, ‏ android.intent.action.VIEW ו-android.intent.action.DIAL באמצעות אפליקציית חיוג שנטענה מראש ויכולה לטפל ב-Intents האלה ולספק את הפעולות שמתוארות ב-SDK.

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

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

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

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

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

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

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

• ‫[C-5-1] חובה לכבד את היעד (intent) android.bluetooth.adapter.action.REQUEST_ENABLE ולהציג פעילות מערכת כדי לאפשר למשתמש להפעיל את ה-Bluetooth.
• ‫[C-5-2] חובה לכבד את הכוונה android.bluetooth.adapter.action.REQUEST_DISCOVERABLE ולהציג פעילות מערכת שמבקשת מצב גלוי.

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

• ‫[C-6-1] חובה להטמיע פעילות שתגיב ל-Intent‏ ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS. בהטמעות עם UI_MODE_TYPE_NORMAL, הפעילות הזו חייבת להיות פעילות שבה המשתמש יכול להעניק לאפליקציה גישה להגדרות של מדיניות 'נא לא להפריע', או לדחות את הגישה.

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

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

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

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

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

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

אם הטמעות של מכשירים מספקות את מצב חיסכון הנתונים, הן: * [C-10-1] חייבות לספק ממשק משתמש בהגדרות, שמטפל ב-intent‏ Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ומאפשר למשתמשים להוסיף אפליקציות לרשימת ההיתרים או להסיר ממנה אפליקציות.

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

• ‫[C-11-1] חובה להגדיר פעילות שמטפלת ב-Intent‏ Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, אבל אפשר להטמיע אותה כפעולה שלא עושה כלום.

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

• ‫[C-12-1] המכשיר חייב לכבד את כוונת הפעולה android.media.action.STILL_IMAGE_CAMERA ואת כוונת הפעולה android.media.action.STILL_IMAGE_CAMERA_SECURE ולהפעיל את המצלמה במצב של תמונות סטילס, כפי שמתואר ב-SDK.
• ‫[C-12-2] המכשיר חייב לכבד את הכוונה (intent) android.media.action.VIDEO_CAMERA להפעיל את המצלמה במצב וידאו, כפי שמתואר ב-SDK.
• ‫[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.ADMIN_POLICY_COMPLIANCE,‏ android.app.action.GET_PROVISIONING_MODE,‏ android.app.action.PROVISIONING_SUCCESSFUL,‏ android.app.action.PROVISION_MANAGED_DEVICE,‏ android.app.action.PROVISION_MANAGED_PROFILE,‏ android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD,‏ android.app.action.SET_NEW_PASSWORD ו-android.app.action.START_ENCRYPTION, ולכלול פעילות שתספק מימוש של הכוונות האלה, כפי שמתואר ב-SDK כאן.

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

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

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

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

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

• ‫[C-15-1] עדיין חייבת להיות פעילות שמטפלת בתבנית intent‏ android.settings.ACTION_USAGE_ACCESS_SETTINGS, אבל היא חייבת להיות מוטמעת כפעולה שלא עושה כלום (no-op), כלומר להתנהג באופן שווה ערך לסירוב של המשתמש לגישה.

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

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

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

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

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

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

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

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

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

‫3.3. תאימות ל-API מקורי

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

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

3.3.1. Application Binary Interfaces

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

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

• ‫[C-0-1] חובה שתהיה תאימות לאחד או יותר מממשקי Android NDK ABI שהוגדרו.
• [C-0-2] חובה לכלול תמיכה בקוד שפועל בסביבה המנוהלת כדי לקרוא לקוד Native, באמצעות הסמנטיקה הרגילה של Java Native Interface‏ (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 מקוריים, לאפליקציות שכוללות קוד Native:

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

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

• ‫[C-0-9] חובה לפרט את הספריות הנוספות שאינן AOSP שנחשפות ישירות לאפליקציות של צד שלישי ב-/vendor/etc/public.libraries.txt.
• ‫[C-0-10] אסור לחשוף ספריות Native אחרות שהוטמעו וסופקו ב-AOSP כספריות מערכת לאפליקציות של צד שלישי שמטרגטות רמת API 24 ומעלה, כי הן שמורות.
• ‫[C-0-11] חובה לייצא את כל סמלי הפונקציות של OpenGL ES 3.1 ושל Android Extension Pack, כפי שמוגדר ב-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 מפורטים הדרישות לגבי המקרים שבהם נדרש יישום מלא של כל אחת מהפונקציות המתאימות.
• צריך לבצע את ה-build באמצעות קוד המקור וקובצי הכותרת שזמינים בפרויקט קוד פתוח של Android

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

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

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

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

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

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

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

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

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

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

3.4. תאימות לאינטרנט

3.4.1. תאימות ל-WebView

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

• ‫[C-1-1] חובה לדווח על android.software.webview.
• ‫[C-1-2] חובה להשתמש בגרסת ה-build של פרויקט Chromium מתוך פרויקט המקור הפתוח של Android ב-Android 11 לצורך הטמעה של 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.RELEASE.
  • המחרוזת $(MODEL) יכולה להיות ריקה, אבל אם היא לא ריקה, הערך שלה חייב להיות זהה לערך של android.os.Build.MODEL.
  • אפשר להשמיט את המחרוזת Build/$(BUILD), אבל אם היא מופיעה, המחרוזת $(BUILD) חייבת להיות זהה לערך של android.os.Build.ID.
  • הערך של המחרוזת $(CHROMIUM_VER) חייב להיות הגרסה של Chromium בפרויקט Android Open Source Project (פרויקט קוד פתוח של Android) במעלה הזרם.
  • יכול להיות שהטמעות של מכשירים לא יכללו את המילה Mobile במחרוזת של סוכן המשתמש.

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

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

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

‫3.4.2. תאימות לדפדפנים

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

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

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

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

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

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

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

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

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

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

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

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

• ‫[C-1-1] חובה לספק למשתמש אפשרות לראות את רשימת האפליקציות המוגבלות.
• ‫[C-1-2] חובה לספק למשתמשים אפשרות להפעיל או להשבית את ההגבלות בכל אפליקציה.
• ‫[C-1-3] אסור להחיל הגבלות באופן אוטומטי ללא הוכחה להתנהגות של מערכת לא תקינה, אבל מותר להחיל את ההגבלות על אפליקציות לאחר זיהוי התנהגות של מערכת לא תקינה, כמו נעילת השהיה (wakelock) שלא מסתיימת, שירותים שפועלים במשך זמן רב וקריטריונים אחרים. יכול להיות שהקריטריונים יוגדרו על ידי מפתחי המכשיר, אבל הם חייבים להיות קשורים להשפעה של האפליקציה על תקינות המערכת. אסור להשתמש בקריטריונים אחרים שלא קשורים באופן ישיר לתקינות המערכת, כמו חוסר פופולריות של האפליקציה בשוק.
• ‫[C-1-4] אסור להחיל באופן אוטומטי הגבלות על אפליקציות כשהמשתמש השבית את ההגבלות על אפליקציות באופן ידני, ומותר להציע למשתמש להחיל הגבלות על אפליקציות.
• ‫[C-1-5] חובה להודיע למשתמשים אם הגבלות על אפליקציות חלות על אפליקציה באופן אוטומטי. חובה לספק את המידע הזה תוך 24 שעות מרגע החלת ההגבלות.
• ‫[C-1-6] חובה להחזיר true עבור ActivityManager.isBackgroundRestricted() כאשר אפליקציה מוגבלת קוראת ל-API הזה.
• ‫[C-1-7] אסור להגביל את האפליקציה העליונה בחזית שבה המשתמש משתמש באופן מפורש.
• ‫[C-1-8] חובה להשעות את ההגבלות על אפליקציה שהופכת לאפליקציה העליונה בחזית כשהמשתמש מתחיל להשתמש באופן מפורש באפליקציה שהייתה מוגבלת.

3.6. API Namespaces

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

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

כלומר, הם:

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

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

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

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

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

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

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

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

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

• ‫[C-0-1] חובה לתמוך בפורמט המלא של Dalvik Executable ‏ (DEX) ובסמנטיקה ומפרט של Dalvik bytecode.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.2. ווידג'טים

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

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

• ‫[C-1-1] חובה להצהיר על תמיכה בתכונת הפלטפורמה android.software.app_widgets.
• ‫[C-1-2] חובה לכלול תמיכה מובנית בווידג'טים של אפליקציות, ולספק למשתמשים ממשק שמאפשר להם להוסיף, להגדיר, להציג ולהסיר ווידג'טים של אפליקציות ישירות מתוך מרכז האפליקציות.
• ‫[C-1-3] המכשיר חייב להיות מסוגל להציג ווידג'טים בגודל 4x4 ברשת בגודל רגיל. פרטים נוספים מופיעים בהנחיות לעיצוב ווידג'טים לאפליקציות במסמכי ה-Android SDK.
• יכול להיות שתהיה תמיכה בווידג'טים של אפליקציות במסך הנעילה.

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

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

‫3.8.3. התראות

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

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

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

• ‫[C-1-1] המכשיר חייב לתמוך בהתראות שמשתמשות בתכונות חומרה, כפי שמתואר במסמכי ה-SDK, ובמידת האפשר עם החומרה של הטמעת המכשיר. לדוגמה, אם יישום של מכשיר כולל מנגנון רטט, חובה ליישם בצורה נכונה את ממשקי ה-API של הרטט. אם בהטמעה של מכשיר מסוים חסרה חומרה, ממשקי ה-API המתאימים חייבים להיות מוטמעים כבלי תפעול (no-ops). התנהגות זו מתוארת בפירוט נוסף בקטע 7.
• ‫[C-1-2] חובה להציג בצורה נכונה את כל המשאבים (סמלים, קובצי אנימציה וכו') שסופקו בממשקי ה-API או במדריך הסגנון של הסמלים בסרגל המערכת או בסרגל הסטטוס, אבל אפשר לספק חוויית משתמש חלופית להתראות שונה מזו שסופקה בהטמעה של קוד פתוח של Android.
• ‫[C-1-3] חובה לכבד ולהטמיע בצורה נכונה את ההתנהגויות שמתוארות בממשקי ה-API כדי לעדכן, להסיר ולקבץ התראות.
• ‫[C-1-4] חובה לספק את ההתנהגות המלאה של API‏ NotificationChannel שמתועד ב-SDK.
• ‫[C-1-5] חובה לספק למשתמש אפשרות לחסימה ולשינוי של התראות מאפליקציה מסוימת של צד שלישי בכל ערוץ ובכל רמת חבילת אפליקציה.
• ‫[C-1-6] המכשיר חייב לספק גם אמצעי נוח למשתמש להצגת ערוצי התראות שנמחקו.
• ‫[C-1-7] חובה להציג בצורה נכונה את כל המשאבים (תמונות, סטיקרים, סמלים וכו') שסופקו דרך Notification.MessagingStyle לצד טקסט ההתראה, ללא אינטראקציה נוספת של המשתמש. לדוגמה, חובה להציג את כל המשאבים, כולל הסמלים שסופקו דרך android.app.Person בשיחה קבוצתית שהוגדרה דרך setGroupConversation.
• [C-SR] מומלץ מאוד להציג באופן אוטומטי למשתמש אמצעי נוח לחסימת ההתראות של אפליקציית צד שלישי מסוימת בכל ערוץ ובכל רמת חבילת אפליקציה, אחרי שהמשתמש סגר את ההתראה מספר פעמים.
• צריכה להיות תמיכה בהתראות מתקדמות.
• צריכה להציג חלק מההתראות בעדיפות גבוהה יותר כהתראות 'שימו לב'.
• צריכה להיות למשתמש אפשרות להשהות את ההתראות.
• יכול להיות שהאפליקציה תנהל את הנראות והתזמון של ההתראות שמוצגות למשתמשים על אירועים חשובים באפליקציות של צד שלישי, כדי לצמצם בעיות בטיחות כמו הסחת דעת של הנהג.

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

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

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

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

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

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

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

אם יישומי המכשיר תומכים בהתראות קופצות: הם:

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

‫3.8.3.2. שירות מאזין להתראות

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

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

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

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

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

‫3.8.3.3. מצב נא לא להפריע (DND)

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

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

‫3.8.4. חיפוש

‫Android כולל ממשקי API שמאפשרים למפתחים לשלב חיפוש באפליקציות שלהם ולחשוף את הנתונים של האפליקציה בחיפוש המערכת הגלובלי. באופן כללי, הפונקציונליות הזו כוללת ממשק משתמש יחיד בכל המערכת, שמאפשר למשתמשים להזין שאילתות, מציג הצעות בזמן שהמשתמשים מקלידים ומציג תוצאות. ממשקי Android API מאפשרים למפתחים לעשות שימוש חוזר בממשק הזה כדי לספק חיפוש באפליקציות שלהם, וגם מאפשרים למפתחים לספק תוצאות לממשק המשתמש הנפוץ של החיפוש הכללי.

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

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

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

אם לא מותקנות אפליקציות של צד שלישי שמשתמשות בחיפוש הגלובלי:

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

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

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

• ‫[C-2-1] חובה לציין בבירור למשתמש הקצה מתי מתבצע שיתוף של ההקשר, באחת מהדרכים הבאות:
  • בכל פעם שאפליקציית העזרה ניגשת להקשר, מופיע אור לבן בשולי המסך למשך זמן ועוצמת בהירות ששווים או גדולים מאלה של ההטמעה של פרויקט קוד פתוח של Android.
  • באפליקציית העזרה שהותקנה מראש, צריך לספק למשתמש אמצעי נוח לגישה לתפריט ההגדרות של אפליקציית העזרה ושל קלט ברירת המחדל של הפקודות הקוליות, במרחק של פחות משני מעברים, ולשתף את ההקשר רק כשהמשתמש מפעיל את אפליקציית העזרה באופן מפורש באמצעות מילת הפעלה או קלט של מקש הניווט של העזרה.
• ‫[C-2-2] האינטראקציה שמוגדרת להפעלת אפליקציית העזרה, כפי שמתואר בסעיף 7.2.3, חייבת להפעיל את אפליקציית העזרה שנבחרה על ידי המשתמש. במילים אחרות, האפליקציה שמטמיעה את VoiceInteractionService או פעילות שמטפלת ב-intent‏ ACTION_ASSIST.

3.8.5. התראות וחלונות קופצים

אפליקציות יכולות להשתמש ב-API‏ Toast כדי להציג למשתמש הקצה מחרוזות קצרות לא מודאליות שנעלמות אחרי פרק זמן קצר, וב-API‏ TYPE_APPLICATION_OVERLAY מסוג חלון כדי להציג חלונות התראה כשכבת-על מעל אפליקציות אחרות.

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

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

• ‫[C-1-2] חובה לכבד את Toast API ולהציג הודעות Toast מאפליקציות למשתמשי קצה באופן בולט כלשהו.

3.8.6. עיצובים

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

‫Android כולל משפחת עיצובים מסוג Holo ו-Material כקבוצה של סגנונות מוגדרים שמפתחי אפליקציות יכולים להשתמש בהם אם הם רוצים להתאים את המראה והתחושה של עיצוב Holo כפי שהוגדר ב-Android SDK.

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

• ‫[C-1-1] אסור לשנות אף אחד ממאפייני העיצוב של Holo שחשופים לאפליקציות.
• ‫[C-1-2] חובה לתמוך במשפחת העיצוב 'Material' ואסור לשנות אף אחד ממאפייני העיצוב Material או את הנכסים שלהם שחשופים לאפליקציות.
• ‫[C-1-3] חובה להגדיר את משפחת הגופנים sans-serif ל-Roboto גרסה 2.x בשפות ש-Roboto תומך בהן, או לספק למשתמש אפשרות לשנות את הגופן שמשמש למשפחת הגופנים sans-serif ל-Roboto גרסה 2.x בשפות ש-Roboto תומך בהן.

‫Android כוללת גם משפחת עיצובים בשם Device Default (ברירת המחדל של המכשיר) – קבוצה של סגנונות מוגדרים שמפתחי אפליקציות יכולים להשתמש בהם אם הם רוצים שהמראה והתחושה של האפליקציה יתאימו לעיצוב המכשיר כפי שהוגדר על ידי יצרן המכשיר.

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

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

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

• ‫[C-2-1] חובה להשתמש בצבע לבן לסמלי סטטוס של המערכת (כמו עוצמת האות ורמת הטעינה) ולהתראות שהמערכת מנפיקה, אלא אם הסמל מציין סטטוס בעייתי או שאפליקציה מבקשת סרגל סטטוס בהיר באמצעות הדגל SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.
• ‫[C-2-2] הטמעות של מכשירי Android חייבות לשנות את הצבע של סמלי סטטוס המערכת לשחור (לפרטים, אפשר לעיין ב-R.style) כשמוגשת בקשה מאפליקציה לסרגל סטטוס בהיר.

‫3.8.7. טפטים מונפשים

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

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

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

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

• ‫[C-1-1] חובה לדווח על דגל התכונה של הפלטפורמה android.software.live_wallpaper.

‫3.8.8. החלפת פעילות

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

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

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

• ‫[C-1-1] המכשיר חייב לתמוך בהצגה של עד 7 פעילויות לפחות.
• מומלץ להציג לפחות את הכותרת של 4 פעילויות בכל פעם.
• ‫[C-1-2] האפליקציה חייבת להטמיע את התנהגות הצמדת המסך ולספק למשתמש תפריט הגדרות להפעלה או להשבתה של התכונה.
• צריך להציג את צבע ההדגשה, הסמל ושם המסך בפריטים האחרונים.
• צריך להציג אמצעי לסגירה (x), אבל אפשר להציג אותו רק אחרי שהמשתמש יוצר אינטראקציה עם המסכים.
• מומלץ להטמיע קיצור דרך למעבר קל לפעילות הקודמת.
• צריך להפעיל את פעולת המעבר המהיר בין שתי האפליקציות האחרונות שהיו בשימוש, כשמקישים פעמיים על מקש הפונקציה של האפליקציות האחרונות.
• צריך להפעיל את מצב המסך המפוצל של חלונות מרובים, אם הוא נתמך, כשלוחצים לחיצה ארוכה על מקש הפונקציות של הפריטים האחרונים.
• יכול להיות שיוצגו קבוצות של אנשים שהיו איתכם בקשר לאחרונה, שמוצגות יחד.
• [SR] מומלץ מאוד להשתמש בממשק המשתמש של Android (או בממשק דומה שמבוסס על תמונות ממוזערות) למסך הסקירה הכללית.

‫3.8.9. ניהול קלט

‫Android כולל תמיכה בניהול קלט ותמיכה בעורכי שיטות קלט של צד שלישי.

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

• ‫[C-1-1] חובה להצהיר על תכונת הפלטפורמה android.software.input_methods ולתמוך בממשקי API של IME כפי שמוגדר במסמכי ה-Android SDK.

‫3.8.10. שליטה בהפעלת מדיה במסך הנעילה

השימוש ב-Remote Control Client API הוצא משימוש החל מ-Android 5.0, ובמקומו אפשר להשתמש בMedia Notification Template שמאפשר לאפליקציות מדיה להשתלב עם אמצעי בקרה להפעלה שמוצגים במסך הנעילה.

‫3.8.11. שומרי מסך (לשעבר Dreams)

הגדרות להגדרת שומרי מסך מפורטות בקטע 3.2.3.5.

‫3.8.12. מיקום

אם הטמעות של מכשירים כוללות חיישן חומרה (למשל GPS) שיכול לספק את קואורדינטות המיקום, הן

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

‫3.8.13. יוניקוד וגופן

‫Android כולל תמיכה בתווי האמוג'י שמוגדרים ב-Unicode 10.0.

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

• ‫[C-1-1] חובה שתהיה אפשרות להציג את תווי האמוג'י האלה כגליף צבעוני.
• ‫[C-1-2] חובה לכלול תמיכה ב:
  • גופן Roboto 2 עם משקלים שונים – sans-serif-thin, ‏ sans-serif-light, ‏ sans-serif-medium, ‏ sans-serif-black, ‏ sans-serif-condensed, ‏ sans-serif-condensed-light לשפות שזמינות במכשיר.
  • כיסוי מלא של Unicode 7.0 של לטינית, יוונית וקירילית, כולל הטווחים Latin Extended A,‏ B,‏ C ו-D, וכל הגליפים בבלוק של סמלי המטבעות ב-Unicode 7.0.
• צריך לתמוך באמוג'י של גווני עור ובאמוג'י של משפחות מגוונות, כפי שמפורט בדוח הטכני מספר 51 של Unicode.

אם יישומי המכשיר כוללים IME, הם:

• צריכה לספק למשתמש שיטה להזנת תווי האמוג'י האלה.

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

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

* [C-2-1] MUST render text with Unicode compliant font as default;
  non-Unicode compliant font MUST NOT be set as default font unless the user
  chooses it in the language picker.
* [C-2-2] MUST support a Unicode font and a non-Unicode compliant font if a
  non-Unicode compliant font is supported on the device.  Non-Unicode
  compliant font MUST NOT remove or overwrite the Unicode font.
* [C-2-3] MUST render text with non-Unicode compliant font ONLY IF a
  language code with [script code Qaag](
  http://unicode.org/reports/tr35/#unicode_script_subtag_validity) is
  specified (e.g. my-Qaag). No other ISO language or region codes (whether
  assigned, unassigned, or reserved) can be used to refer to non-Unicode
  compliant font for Myanmar. App developers and web page authors can
  specify my-Qaag as the designated language code as they would for any
  other language.

‫3.8.14. ריבוי חלונות

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

• ‫[C-1-1] חובה להטמיע מצבים כאלה של ריבוי חלונות בהתאם להתנהגויות האפליקציה ולממשקי ה-API שמתוארים במסמכי התמיכה של Android SDK בנושא מצב ריבוי חלונות, ולעמוד בדרישות הבאות:
• ‫[C-1-2] חובה לכבד את android:resizeableActivity שמוגדר על ידי אפליקציה בקובץ AndroidManifest.xml, כפי שמתואר ב-SDK הזה.
• ‫[C-1-3] אסור להציע מצב מסך מפוצל או מצב חלונות צפים אם גובה המסך קטן מ-440dp ורוחב המסך קטן מ-440dp.
• ‫[C-1-4] אסור לשנות את הגודל של פעילות לגודל קטן מ-220dp במצבי ריבוי חלונות, למעט במצב 'תמונה בתוך תמונה'.
• הטמעות של מכשירים עם גודל מסך xlarge צריכות לתמוך במצב חלונות חופשיים.

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

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

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

• ‫[C-3-1] האפליקציה חייבת להפעיל פעילויות במצב חלון צף מרובה חלונות כשהיא: * מטרגטת לרמת API‏ 26 ומעלה ומצהירה על android:supportsPictureInPicture * מטרגטת לרמת API‏ 25 ומטה ומצהירה על android:resizeableActivity וגם על android:supportsPictureInPicture.
• ‫[C-3-2] חובה לחשוף את הפעולות ב-SystemUI בהתאם לפעילות הנוכחית של PIP דרך ה-API‏ setActions().
• ‫[C-3-3] חובה לתמוך ביחסי גובה-רוחב שגדולים מ-1:2.39 או שווים לו, וקטנים מ-2.39:1 או שווים לו, כפי שמצוין בפעילות של PIP דרך setAspectRatio() API.
• ‫[C-3-4] חובה להשתמש ב-KeyEvent.KEYCODE_WINDOW כדי לשלוט בחלון PIP. אם מצב PIP לא מוטמע, המקש חייב להיות זמין לפעילות בחזית.
• ‫[C-3-5] חובה לספק למשתמש אמצעי לחסימת הצגת אפליקציה במצב תמונה בתוך תמונה. ההטמעה של AOSP עומדת בדרישה הזו כי יש אמצעי בקרה במרכז ההתראות.

• ‫[C-3-6] חובה להקצות את הרוחב והגובה המינימליים הבאים לחלון PIP כשבאפליקציה לא מוצהר ערך ל-AndroidManifestLayout_minWidth ול-AndroidManifestLayout_minHeight:

  • במכשירים עם ההגדרה Configuration.uiMode שמוגדרת כערך שונה מ-UI_MODE_TYPE_TELEVISION, חובה להקצות רוחב וגובה מינימליים של 108dp.
  • במכשירים עם Configuration.uiMode שהערך שלו מוגדר כ-UI_MODE_TYPE_TELEVISION, צריך להקצות רוחב מינימלי של 240dp וגובה מינימלי של 135dp.

‫3.8.15. מגרעת במסך

‫Android תומך בחלק חתוך במסך, כפי שמתואר במסמך ה-SDK. ממשק ה-API‏ DisplayCutout מגדיר אזור בקצה המסך שאולי לא יפעל באפליקציה בגלל חיתוך מסך או מסך קעור בקצה או בקצוות.

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

• ‫[C-1-5] אסור שיהיו חריצים אם יחס הגובה-רוחב של המכשיר הוא 1.0 (1:1).
• ‫[C-1-2] אסור שיהיה יותר מפתח אחד בכל קצה.
• [C-1-3] חובה לכבד את הדגלים של מגרעת במסך שמוגדרים על ידי האפליקציה באמצעות WindowManager.LayoutParams API, כפי שמתואר ב-SDK.
• ‫[C-1-4] חובה לדווח על ערכים נכונים לכל מדדי החיתוך שמוגדרים ב-API‏ DisplayCutout.

3.8.16. ממשק השליטה במכשירים

מערכת Android כוללת ממשקי API של ControlsProviderService ושל Control שמאפשרים לאפליקציות של צד שלישי לפרסם אמצעי בקרה במכשיר כדי שהמשתמשים יוכלו לראות במהירות את הסטטוס ולבצע פעולות.

בקטע 2_2_3 מפורטות הדרישות הספציפיות למכשירים.

‫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-3] חובה לדווח על true עבור DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • ‫[C-1-4] אפליקציית ה-DPC חייבת לרשום את אפליקציית ה-DPC כאפליקציה של בעלי המכשיר בתגובה לפעולת Intent android.app.action.PROVISION_MANAGED_DEVICE.
    • [C-1-5] אפליקציית ה-DPC חייבת להירשם כאפליקציית בעלי המכשיר אם המכשיר מצהיר על תמיכה בתקשורת מטווח קצר (NFC) באמצעות feature flag android.hardware.nfc ומקבל הודעת NFC שמכילה רשומה עם סוג MIME‏ MIME_TYPE_PROVISIONING_NFC.
  • אם בהטמעה של המכשיר יש נתוני משתמש, היא:
    • ‫[C-1-6] חובה לדווח על false עבור DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • ‫[C-1-7] אסור לרשום יותר אפליקציות DPC כאפליקציית בעלי המכשיר.
• ‫[C-1-2] האפליקציה חייבת לדרוש פעולה חיובית כלשהי לפני או במהלך תהליך ההקצאה כדי להסכים להגדרת האפליקציה כבעלים של המכשיר. ההסכמה יכולה להתקבל באמצעות פעולה של המשתמש או באמצעים תוכנתיים מסוימים, אבל חובה להציג הודעת גילוי נאות מתאימה (כפי שמצוין ב-AOSP) לפני שמתחילים בהקצאת הרשאות לבעלי המכשיר. בנוסף, מנגנון ההסכמה של בעל המכשיר שמשמש (ארגונים) להקצאת הרשאות לבעל המכשיר לא יכול להפריע לחוויית הגדרה ראשונית לשימוש שאינו ארגוני.
• ‫[C-1-3] אסור להגדיר את ההסכמה כקוד קשיח או למנוע את השימוש באפליקציות אחרות של בעל המכשיר.

אם הטמעות של מכשירים מצהירות על android.software.device_admin, אבל כוללות גם פתרון קנייני לניהול בעלי מכשירים ומספקות מנגנון לקידום אפליקציה שהוגדרה בפתרון שלהן כ'מקבילה לבעלי מכשירים' ל'בעלי מכשירים' רגילים כפי שמזוהים על ידי ממשקי ה-API הרגילים של DevicePolicyManager ב-Android, הן:

• ‫[C-2-1] חובה להטמיע תהליך לאימות האפליקציה הספציפית שמקודמת, כדי לוודא שהיא שייכת לפתרון לגיטימי לניהול מכשירים ארגוניים, וכבר הוגדרו לה בפתרון הקנייני זכויות שוות ערך לזכויות של 'בעלי המכשיר'.
• ‫[C-2-2] האפליקציה חייבת להציג את אותו גילוי נאות לבקשת הסכמה של בעלי המכשיר ב-AOSP כמו בתהליך שהופעל על ידי android.app.action.PROVISION_MANAGED_DEVICE לפני ההרשמה של אפליקציית ה-DPC כ'בעלים של המכשיר'.
• יכול להיות שיהיו נתוני משתמש במכשיר לפני שמצרפים את אפליקציית ה-DPC כ'בעלים של המכשיר'.

‫3.9.1.2 הקצאת פרופילים מנוהלים

אם הטמעות של מכשירים מצהירות על android.software.managed_users, הן:

• ‫[C-1-1] חובה להטמיע את ממשקי ה-API שמאפשרים לאפליקציית בקר מדיניות מכשיר (DPC) להפוך לבעלים של פרופיל מנוהל חדש.

• ‫[C-1-2] התהליך של הקצאת פרופיל מנוהל (התהליך שמופעל על ידי android.app.action.PROVISION_MANAGED_PROFILE) שמוצג למשתמשים חייב להיות תואם להטמעה של AOSP.

• ‫[C-1-3] חובה לספק את אמצעי הנוחות הבאים למשתמשים בהגדרות כדי לציין למשתמש מתי פונקציית מערכת מסוימת הושבתה על ידי בקר מדיניות המכשיר (DPC):

  • סמל עקבי או אמצעי אחר שמאפשר למשתמש לדעת (לדוגמה, סמל המידע של AOSP במעלה הזרם) מתי הגדרות מסוימות מוגבלות על ידי אדמין המכשיר.
  • הודעת הסבר קצרה, כפי שסופקה על ידי מנהל המכשיר באמצעות setShortSupportMessage.
  • הסמל של אפליקציית ה-DPC.

‫3.9.2 תמיכה בפרופילים מנוהלים

אם הטמעות של מכשירים מצהירות על android.software.managed_users, הן:

• ‫[C-1-1] חובה לתמוך בפרופילים מנוהלים באמצעות ממשקי android.app.admin.DevicePolicyManager API.
• ‫[C-1-2] המכשיר חייב לאפשר יצירה של פרופיל מנוהל אחד בלבד.
• ‫[C-1-3] חובה להשתמש בתג סמל (בדומה לתג העבודה של AOSP upstream) כדי לייצג את האפליקציות והווידג'טים המנוהלים ואלמנטים אחרים בממשק המשתמש עם תגים, כמו 'אחרונים' ו'התראות'.
• [C-1-4] חובה להציג סמל התראה (בדומה לתג עבודה של AOSP במעלה הזרם) כדי לציין מתי המשתמש נמצא באפליקציה של פרופיל מנוהל.
• ‫[C-1-5] חובה להציג הודעה קצרה שמעידה על כך שהמשתמש נמצא בפרופיל המנוהל אם וכאשר המכשיר מתעורר (ACTION_USER_PRESENT) והאפליקציה בחזית נמצאת בפרופיל המנוהל.
• ‫[C-1-6] אם קיים פרופיל מנוהל, חובה להציג אמצעי ויזואלי ב 'בוחר' הכוונות כדי לאפשר למשתמש להעביר את הכוונה מהפרופיל המנוהל למשתמש הראשי או להיפך, אם הופעל על ידי בקר מדיניות המכשיר.
• ‫[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 ולהציג ממשק להגדרת אמצעי אימות נפרד למסך הנעילה עבור הפרופיל המנוהל.
  • פרטי הכניסה למסך הנעילה של הפרופיל המנוהל חייבים להשתמש באותם מנגנונים לאחסון פרטי כניסה ולניהול של פרטי הכניסה כמו בפרופיל ההורה, כפי שמתואר באתר פרויקט קוד פתוח של Android.
  • מדיניות הסיסמאות של ה-DPC חייבת לחול רק על פרטי הכניסה למסך הנעילה של הפרופיל המנוהל, אלא אם היא מופעלת על מופע DevicePolicyManager שמוחזר על ידי getParentProfileInstance.
• כשמוצגים אנשי קשר מהפרופיל המנוהל ביומן השיחות שהותקן מראש, בממשק המשתמש של השיחה, בהתראות על שיחות פעילות ועל שיחות שלא נענו, ובאפליקציות של אנשי קשר והודעות, הם צריכים להיות מסומנים באותו תג שמשמש לסימון אפליקציות של פרופילים מנוהלים.

‫3.9.3 תמיכה בחשבון מנוהל

אם הטמעות של מכשירים מצהירות על android.software.managed_users, הן:

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

‫3.10. נגישות

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

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

• ‫[C-1-1] חובה לספק הטמעה של מסגרת הנגישות של Android, כפי שמתואר בתיעוד של ערכת ה-SDK בנושא ממשקי API להטמעת תכונות נגישות.
• ‫[C-1-2] המערכת חייבת ליצור אירועי נגישות ולספק את AccessibilityEvent המתאים לכל יישומי AccessibilityService הרשומים, כפי שמתואר ב-SDK.
• ‫[C-1-4] חובה להוסיף לחלק העליון של המסך כפתור שמאפשר למשתמש לשלוט בשירות הנגישות, כששירותי הנגישות המופעלים מצהירים על AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . הערה: הדרישה הזו לא חלה על הטמעות של מכשירים ללא סרגל ניווט במערכת, אבל הטמעות של מכשירים צריכות לספק למשתמשים אפשרות לשלוט בשירותי הנגישות האלה.

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

• ‫[C-2-1] חובה להטמיע את שירותי הנגישות האלה שמותקנים מראש כאפליקציות Direct Boot Aware כשנתוני האחסון מוצפנים באמצעות הצפנה מבוססת-קובץ (FBE).
• צריך לספק מנגנון בתהליך ההגדרה הראשונית כדי לאפשר למשתמשים להפעיל שירותי נגישות רלוונטיים, וגם אפשרויות להתאמת גודל הגופן, גודל התצוגה ומחוות ההגדלה.

‫3.11. המרת טקסט לדיבור (TTS)

‫Android כולל ממשקי API שמאפשרים לאפליקציות להשתמש בשירותי המרת טקסט לדיבור (TTS), ומאפשרים לספקי שירותים לספק הטמעות של שירותי TTS.

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

• ‫[C-1-1] חובה לתמוך בממשקי ה-API של מסגרת ה-TTS של Android.

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

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

‫3.12. TV Input Framework

מסגרת הקלט של Android Television‏ (TIF) מפשטת את העברת התוכן בשידור חי למכשירי Android Television. ‫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] חובה לאפשר למשתמש להוסיף או להסיר את האריחים שסופקו באמצעות ממשקי ה-API של quicksettings מאפליקציית צד שלישי.
• ‫[C-1-2] אסור להוסיף באופן אוטומטי לחצן מאפליקציה של צד שלישי ישירות להגדרות המהירות.
• ‫[C-1-3] חובה להציג את כל הכפתורים שנוספו על ידי המשתמש מאפליקציות של צד שלישי לצד הכפתורים של ההגדרות המהירות שסופקו על ידי המערכת.

‫3.14. ממשק משתמש של מדיה

אם הטמעות המכשירים כוללות אפליקציות שלא מופעלות באמצעות קול (האפליקציות) שמבצעות אינטראקציה עם אפליקציות של צד שלישי באמצעות MediaBrowser או MediaSession, האפליקציות:

• ‫[C-1-2] חובה להציג באופן ברור סמלים שהתקבלו באמצעות getIconBitmap()‎ או getIconUri()‎ וכותרות שהתקבלו באמצעות getTitle()‎, כפי שמתואר במאמר MediaDescription. יכול להיות שהמערכת תקצר את שמות הפריטים כדי לעמוד בתקנות הבטיחות (למשל, הסחת דעת של נהגים).

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

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

• ‫[C-1-5] חובה להתייחס ללחיצה כפולה על KEYCODE_HEADSETHOOK או על KEYCODE_MEDIA_PLAY_PAUSE כאל KEYCODE_MEDIA_NEXT עבור MediaSession.Callback#onMediaButtonEvent.

‫3.15. אפליקציות ללא התקנה

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

• ‫[C-0-1] חובה להעניק לאפליקציות ללא התקנה רק הרשאות שהערך android:protectionLevel שלהן מוגדר כ-"instant".
• ‫[C-0-2] אפליקציות ללא התקנה לא יכולות לקיים אינטראקציה עם אפליקציות מותקנות באמצעות intent משתמע, אלא אם אחד מהתנאים הבאים מתקיים:
  • מסנן דפוסי ה-Intent של הרכיב חשוף וכולל CATEGORY_BROWSABLE
  • הפעולה היא אחת מהפעולות ACTION_SEND, ‏ ACTION_SENDTO, ‏ ACTION_SEND_MULTIPLE
  • היעד נחשף באופן מפורש באמצעות android:visibleToInstantApps
• ‫[C-0-3] אסור לאפליקציות ללא התקנה ליצור אינטראקציה באופן מפורש עם אפליקציות מותקנות, אלא אם הרכיב נחשף באמצעות android:visibleToInstantApps.
• ‫[C-0-4] אפליקציות מותקנות לא יכולות לראות פרטים על אפליקציות ללא התקנה במכשיר, אלא אם האפליקציה ללא התקנה מתחברת באופן מפורש לאפליקציה המותקנת.

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

• ‫[C-1-1] חובה לספק את האפשרויות הבאות למשתמשים כדי ליצור אינטראקציה עם אפליקציות ללא התקנה. מערכת AOSP עומדת בדרישות עם ממשק המשתמש, ההגדרות וה-Launcher של המערכת שמוגדרים כברירת מחדל.
• ‫[C-1-2] חובה לספק למשתמש אפשרות לצפייה במטמון של אפליקציות מיידיות שנשמרות באופן מקומי ולמחיקה שלהן עבור כל חבילת אפליקציה בנפרד.
• ‫[C-1-3] חובה לספק התראה קבועה למשתמש שאפשר לכווץ בזמן שאפליקציה ללא התקנה פועלת בחזית. ההתראה הזו למשתמשים צריכה לכלול את המידע שאפליקציות ללא התקנה לא דורשות התקנה, ולספק למשתמש אפשרות לעבור למסך פרטי האפליקציה בהגדרות. באפליקציות ללא התקנה שמופעלות באמצעות כוונות אינטרנט, כפי שמוגדרות באמצעות כוונה עם פעולה שמוגדרת ל-Intent.ACTION_VIEW ועם סכימה של http או https, צריך לאפשר למשתמש לא להפעיל את האפליקציה ללא התקנה ולהפעיל את הקישור המשויך באמצעות דפדפן האינטרנט שהוגדר, אם דפדפן זמין במכשיר.
• ‫[C-1-4] חובה לאפשר גישה לאפליקציות מיידיות שפועלות מהפונקציה 'אפליקציות שהיו בשימוש לאחרונה', אם הפונקציה הזו זמינה במכשיר.
• ‫[C-1-5] חובה לטעון מראש אפליקציה אחת או יותר או רכיבי שירות עם handler של כוונות עבור הכוונות שמפורטות כאן ב-SDK, ולהפוך את הכוונות לגלויות באפליקציות מיידיות.

‫3.16. התאמת מכשיר נלווה

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

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

• ‫[C-1-1] חובה להצהיר על ה-feature flag‏ FEATURE_COMPANION_DEVICE_SETUP .
• ‫[C-1-2] חובה לוודא שממשקי ה-API בחבילה android.companion מוטמעים באופן מלא.
• ‫[C-1-3] חובה לספק למשתמש אמצעים לבחירה או לאישור של מכשיר נלווה שקיים ופועל.

‫3.17. אפליקציות כבדות

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

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

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

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

‫3.18. אנשי קשר

‫Android כולל ממשקי API של Contacts Provider שמאפשרים לאפליקציות לנהל את פרטי הקשר שמאוחסנים במכשיר. נתוני אנשי קשר שמוזנים ישירות למכשיר מסונכרנים בדרך כלל עם שירות אינטרנט, אבל יכול להיות שהנתונים יישמרו רק באופן מקומי במכשיר. אנשי קשר ששמורים רק במכשיר נקראים אנשי קשר מקומיים.

רשומות RawContacts משויכות לAccount או מאוחסנות בו, אם הערכים בעמודות ACCOUNT_NAME ו-ACCOUNT_TYPE של אנשי הקשר הגולמיים זהים לערכים בשדות Account.name ו-Account.type של החשבון.

חשבון מקומי שמוגדר כברירת מחדל: חשבון לאנשי קשר גולמיים שמאוחסנים רק במכשיר ולא משויכים לחשבון ב-AccountManager. החשבון הזה נוצר עם ערכי null בעמודות ACCOUNT_NAME ו-ACCOUNT_TYPE.

חשבון מקומי בהתאמה אישית: חשבון של אנשי קשר גולמיים שמאוחסנים רק במכשיר ולא משויכים לחשבון ב-AccountManager, שנוצר עם לפחות ערך אחד שאינו null בעמודות ACCOUNT_NAME ו-ACCOUNT_TYPE.

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

• [C-SR] מומלץ מאוד לא ליצור חשבונות מקומיים בהתאמה אישית.

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

• ‫[C-1-1] הערך ACCOUNT_NAME של חשבון מקומי בהתאמה אישית חייב להיות מוחזר על ידי ContactsContract.RawContacts.getLocalAccountName
• ‫[C-1-2] הערך ACCOUNT_TYPE של החשבון המקומי המותאם אישית חייב להיות מוחזר על ידי ContactsContract.RawContacts.getLocalAccountType
• ‫[C-1-3] אנשי קשר גולמיים שמוכנסים על ידי אפליקציות של צד שלישי עם חשבון מקומי שמוגדר כברירת מחדל (כלומר, על ידי הגדרת ערכי null עבור ACCOUNT_NAME ו-ACCOUNT_TYPE) חייבים להיות מוכנסים לחשבון מקומי מותאם אישית.
• ‫[C-1-4] אנשי קשר גולמיים שמוכנסים לחשבון מקומי בהתאמה אישית לא יכולים להימחק כשמוסיפים או מסירים חשבונות.
• ‫[C-1-5] פעולות מחיקה שמתבצעות מול חשבון מקומי מותאם אישית חייבות לגרום לטיהור מיידי של אנשי הקשר הגולמיים (כאילו הפרמטר CALLER_IS_SYNCADAPTER הוגדר כ-true), גם אם הפרמטר CALLER\_IS\_SYNCADAPTER הוגדר כ-false או לא צוין.

4. תאימות של חבילות אפליקציות

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

• ‫[C-0-1] המכשיר חייב להיות מסוגל להתקין ולהפעיל קובצי Android ‏(‎.apk) שנוצרו על ידי הכלי aapt שכלול ב-Android SDK הרשמי.
• יכול להיות שהדרישה שלמעלה תהיה מאתגרת, ולכן מומלץ להשתמש במערכת לניהול חבילות של הטמעת ההפניה של AOSP.

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

• ‫[C-0-2] חובה לתמוך באימות קובצי ‎.apk באמצעות APK Signature Scheme v3 , ‏ APK Signature Scheme v2 וחתימה על JAR.
• ‫[C-0-3] אסור להרחיב את הפורמטים של קובץ ה-APK, המניפסט של Android, הבייטקוד של Dalvik או הבייטקוד של RenderScript באופן שימנע את ההתקנה וההפעלה התקינות של הקבצים האלה במכשירים תואמים אחרים.

• ‫[C-0-4] אסור לאפשר לאפליקציות אחרות מלבד 'המתקין הרשמי' של החבילה להסיר את האפליקציה בשקט ללא אישור המשתמש, כפי שמתואר ב-SDK להרשאה DELETE_PACKAGE. היוצאים מן הכלל היחידים הם אפליקציית אימות החבילות של המערכת שמטפלת ב-intent‏ PACKAGE_NEEDS_VERIFICATION ואפליקציית ניהול האחסון שמטפלת ב-intent‏ ACTION_MANAGE_STORAGE.

• ‫[C-0-5] חובה להגדיר פעילות שמטפלת באובייקט מסוג Intent‏ android.settings.MANAGE_UNKNOWN_APP_SOURCES.

• ‫[C-0-6] אסור להתקין חבילות אפליקציות ממקורות לא מוכרים, אלא אם האפליקציה שמבקשת את ההתקנה עומדת בכל הדרישות הבאות:

  • האפליקציה חייבת להצהיר על ההרשאה REQUEST_INSTALL_PACKAGES או להגדיר את android:targetSdkVersion לערך 24 או נמוך יותר.
  • המשתמש חייב להעניק לאפליקציה הרשאה להתקין אפליקציות ממקורות לא מוכרים.

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

• ‫[C-0-7] חובה להציג למשתמש תיבת דו-שיח עם מחרוזת האזהרה שסופקה דרך ממשק ה-API של המערכת PackageManager.setHarmfulAppWarning לפני הפעלת פעילות באפליקציה שסומנה על ידי אותו ממשק API של המערכת PackageManager.setHarmfulAppWarning כאפליקציה שעלולה להזיק.

• מומלץ לספק למשתמשים אפשרות לבחור להסיר או להפעיל אפליקציה בתיבת הדו-שיח של האזהרה.

• ‫[C-0-8] חובה להטמיע תמיכה במערכת קבצים מצטברת כפי שמתואר כאן.

• ‫[C-0-9] חייב לתמוך באימות קובצי ‎ .apk באמצעות APK Signature Scheme v4.

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

5. תאימות למולטימדיה

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

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

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

• צריך לשאוף לזמן אחזור מינימלי של קודק, במילים אחרות, הם
  • לא צריכה לצרוך ולאחסן מאגרי קלט, ולהחזיר מאגרי קלט רק אחרי העיבוד.
  • אסור לשמור מאגרי נתונים מפוענחים למשך זמן ארוך יותר מזה שצוין בתקן (למשל SPS).
  • אסור לשמור על מאגרי נתונים זמניים מקודדים למשך זמן ארוך יותר מהנדרש על ידי מבנה ה-GOP.

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

חשוב לציין ש-Google ו-Open Handset Alliance לא מצהירות שהקודקים האלה פטורים מפטנטים של צד שלישי. למי שמתכוון להשתמש בקוד המקור הזה במוצרי חומרה או תוכנה, מומלץ לדעת שיישומים של הקוד הזה, כולל בתוכנות קוד פתוח או בתוכנות שיתופיות, עשויים לדרוש רישיונות פטנט מבעלי הפטנט הרלוונטיים.

5.1. קודקים של מדיה

5.1.1. קידוד אודיו

פרטים נוספים מופיעים בקטע 5.1.3. פרטים על קודק אודיו.

אם הטמעות של מכשירים מצהירות על android.hardware.microphone, הן חייבות לתמוך בקידוד של פורמטי האודיו הבאים ולהפוך אותם לזמינים לאפליקציות של צד שלישי:

• ‫[C-1-1] PCM/WAVE
• ‫[C-1-2] FLAC
• ‫[C-1-3] Opus

כל מקודדי האודיו חייבים לתמוך ב:

• ‫[C-3-1] מסגרות אודיו של סדר בתים מקורי של PCM 16-bit דרך 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 (פרופיל HE AAC מורחב של ISO/IEC 23003-3, שכולל את פרופיל ה-Baseline של USAC ואת פרופיל בקרת הטווח הדינמי של ISO/IEC 23003-4)
• ‫[C-1-5] FLAC
• ‫[C-1-6] MP3
• ‫[C-1-7] MIDI
• ‫[C-1-8] Vorbis
• ‫[C-1-9] PCM/WAVE כולל פורמטים של אודיו ברזולוציה גבוהה עד 24 ביט, תדירות דגימה של 192 kHz ו-8 ערוצים. חשוב לדעת שהדרישה הזו היא רק לגבי פענוח, ומותר למכשיר לבצע דגימת יתר ומיקס דאון במהלך שלב ההפעלה.
• ‫[C-1-10] Opus

אם הטמעות של מכשירים תומכות בפענוח של מאגרי קלט AAC של סטרימינג רב-ערוצי (כלומר, יותר משני ערוצים) ל-PCM באמצעות מפענח האודיו של AAC שמוגדר כברירת מחדל ב-android.media.MediaCodec API, המכשירים חייבים לתמוך בפעולות הבאות:

• ‫[C-2-1] חובה לבצע פענוח ללא מיקס דאון (למשל, שידור AAC בפורמט 5.0 חייב להיות מפוענח לחמישה ערוצי PCM, שידור AAC בפורמט 5.1 חייב להיות מפוענח לשישה ערוצי PCM).
• ‫[C-2-2] מטא-נתונים של טווח דינמי חייבים להיות כפי שמוגדר ב-Dynamic Range Control (DRC)‎ ב-ISO/IEC 14496-3, וandroid.media.MediaFormat מפתחות ה-DRC להגדרת ההתנהגויות שקשורות לטווח הדינמי של מפענח האודיו. מפתחות ה-DRC של AAC הוצגו ב-API 21 והם: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL ו-KEY_AAC_ENCODED_TARGET_LEVEL.
• ‫[SR] מומלץ מאוד שכל מפענחי האודיו מסוג AAC יעמדו בדרישות C-2-1 ו-C-2-2 שצוינו למעלה.

כשמפענחים אודיו בפורמט 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 בזרם ביטים מפוענח, אז:

• למטא-נתונים של ISO/IEC 23003-4 תהיה עדיפות.

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

• ‫[C-6-1] פריימים של אודיו בפורמט PCM‏ 16 ביט עם סדר בייטים מקורי דרך android.media.MediaCodec API.

5.1.3. פרטים על קודק אודיו

‫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] אם האפליקציה מבקשת זאת, למשל באמצעות ההגדרה ARGB_8888 של android.graphics.Bitmap, המכשיר חייב לתמוך בפלט בפורמט שווה ערך של 8 ביט.

5.1.6. פרטים על קודקים של תמונות

מקודדים ומפענחים של תמונות שנחשפים דרך MediaCodec API

• ‫[C-1-1] חובה לתמוך בפורמט צבע גמיש YUV420 8:8:8 (COLOR_FormatYUV420Flexible) באמצעות CodecCapabilities.

• ‫[SR] מומלץ מאוד לתמוך בפורמט הצבע RGB888 למצב Surface של קלט.

• ‫[C-1-3] חובה לתמוך לפחות באחד מפורמטי הצבעים YUV420 8:8:8: ‏ COLOR_FormatYUV420PackedPlanar (שווה ל-COLOR_FormatYUV420Planar) או COLOR_FormatYUV420PackedSemiPlanar (שווה ל-COLOR_FormatYUV420SemiPlanar). מומלץ מאוד לתמוך בשניהם.

‫5.1.7. קודקים של וידאו

• כדי להשיג איכות סבירה של סטרימינג של סרטונים באינטרנט ושירותי שיחות ועידה בווידאו, הטמעות של מכשירים צריכות להשתמש ב-codec VP8 בחומרה שעומד בדרישות.

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

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

• ‫[C-1-2] מקודדים ומפענחים של סרטונים חייבים לתמוך בפורמטים גמישים של צבעים YUV420 8:8:8 (COLOR_FormatYUV420Flexible) עד CodecCapabilities.

• ‫[C-1-3] מקודדים ומפענחים של סרטונים חייבים לתמוך לפחות באחד מפורמטי הצבעים YUV420 8:8:8 planar או semiplanar: ‏ COLOR_FormatYUV420PackedPlanar (שווה ל-COLOR_FormatYUV420Planar) או COLOR_FormatYUV420PackedSemiPlanar (שווה ל-COLOR_FormatYUV420SemiPlanar). מומלץ מאוד לתמוך בשניהם.

• ‫[SR] מומלץ מאוד שמקודדים ומפענחים של סרטונים יתמכו לפחות באחד מפורמטי הצבעים YUV420 8:8:8 (YV12, ‏ NV12, ‏ NV21 או פורמט מקביל שעבר אופטימיזציה על ידי הספק) במישור או במישור למחצה שעברו אופטימיזציה לחומרה.

• ‫[C-1-5] מפענחי וידאו שתומכים בפורמט עם עומק סיביות גבוה (9 סיביות ומעלה לכל ערוץ) חייבים לתמוך בפלט של פורמט שווה ערך של 8 סיביות אם האפליקציה מבקשת זאת. הדבר הזה חייב לבוא לידי ביטוי בתמיכה בפורמט צבע YUV420 8:8:8 באמצעות android.media.MediaCodecInfo.

אם הטמעות של מכשירים מפרסמות תמיכה בפרופיל HDR באמצעות Display.HdrCapabilities, הן:

• ‫[C-2-1] חובה לתמוך בניתוח ובטיפול במטא-נתונים סטטיים של HDR.

אם הטמעות של מכשירים מפרסמות תמיכה ברענון תוך-פריים באמצעות FEATURE_IntraRefresh בכיתה MediaCodecInfo.CodecCapabilities, הן:

• ‫[C-3-1] המכשיר חייב לתמוך בתקופות רענון בטווח של 10 עד 60 פריימים, ולפעול בצורה מדויקת בטווח של 20% מתקופת הרענון שהוגדרה.

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

• ‫[C-4-1] אם ההגדרה מתבצעת באמצעות פלט Surface, פורמט הצבע שמוגדר כברירת מחדל חייב להיות זה שעבר אופטימיזציה לתצוגת החומרה.
• ‫[C-4-2] אם ההגדרה היא לא להשתמש בפלט Surface, ברירת המחדל חייבת להיות פורמט צבע YUV420 8:8:8 שעבר אופטימיזציה לקריאת CPU.

‫5.1.8. רשימת קודקים של סרטונים

‫5.1.9. אבטחה של קודק מדיה

הטמעות של מכשירים חייבות להבטיח תאימות לתכונות האבטחה של רכיבי codec של מדיה, כפי שמתואר בהמשך.

‫Android כולל תמיכה ב-OMX, שהוא API להאצת מולטימדיה בפלטפורמות שונות, וגם ב-Codec 2.0, שהוא API להאצת מולטימדיה עם תקורה נמוכה.

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

• ‫[C-1-1] חובה לספק תמיכה ברכיבי codec של מדיה באמצעות ממשקי OMX או Codec 2.0 API (או שניהם) כמו בפרויקט הקוד הפתוח של Android, ולא להשבית או לעקוף את אמצעי ההגנה. המשמעות היא שלא כל קודק צריך להשתמש ב-OMX או ב-Codec 2.0 API, אלא שצריך להיות זמין לפחות אחד מממשקי ה-API האלה, והתמיכה בממשקי ה-API הזמינים צריכה לכלול את אמצעי ההגנה על האבטחה שקיימים.
• ‫[C-SR] מומלץ מאוד לכלול תמיכה ב-Codec 2.0 API.

אם הטמעות של מכשירים לא תומכות ב-Codec 2.0 API, הן:

• ‫[C-2-1] חובה לכלול את רכיב ה-codec התואם של תוכנת OMX מתוך פרויקט הקוד הפתוח של Android (אם הוא זמין) לכל פורמט וסוג מדיה (מקודד או מפענח) שנתמכים במכשיר.
• ‫[C-2-2] קודקים שהשמות שלהם מתחילים ב-'OMX.google.' חייב להתבסס על קוד המקור של פרויקט הקוד הפתוח של Android.
• [C-SR] מומלץ מאוד להפעיל את רכיבי ה-codec של תוכנת OMX בתהליך codec שאין לו גישה למנהלי התקנים של חומרה מלבד ממפי זיכרון.

אם הטמעות המכשיר תומכות ב-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] אסור ששמות רכיבי ה-Codec יהיו מטעים. לדוגמה, קודקים בשם decoders (מפענחים) חייבים לתמוך בפענוח, וקודקים בשם encoders (מקודדים) חייבים לתמוך בקידוד. קודקים עם שמות שמכילים פורמטים של מדיה חייבים לתמוך בפורמטים האלה.

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

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

• ‫[C-2-2] קודקים של וידאו שמסווגים כקודקים עם האצת חומרה חייבים לפרסם מידע על נקודות ביצועים. כל אחד מהם חייב לכלול את כל נקודות הביצועים הסטנדרטיות הנתמכות (שמופיעות ב-API‏ PerformancePoint), אלא אם הן נכללות בנקודת ביצועים סטנדרטית נתמכת אחרת.
• בנוסף, הם צריכים לפרסם נקודות ביצועים מורחבות אם הם תומכים בביצועי סרטון קבועים, שאינם אחד מהסטנדרטים המפורטים.

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 ומאפשרות לאפליקציות צד שלישי להשתמש בו, הן:

• צריכה להיות תמיכה בקצבי העברת נתונים (bitrate) שניתנים להגדרה באופן דינמי עבור המקודד הנתמך.

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

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

5.2.1. H.263

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

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

5.2.2. H.264

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

• ‫[C-1-1] חובה לתמוך בפרופיל Baseline ברמה 3. עם זאת, התמיכה ב-ASO (Arbitrary Slice Ordering), ב-FMO (Flexible Macroblock Ordering) וב-RS (Redundant Slices) היא אופציונלית. בנוסף, כדי לשמור על תאימות למכשירי Android אחרים, מומלץ שמקודדים לא ישתמשו ב-ASO, ב-FMO וב-RS עבור פרופיל Baseline.
• ‫[C-1-2] חובה לתמוך בפרופילים של קידוד וידאו באיכות רגילה (SD) שמפורטים בטבלה הבאה.
• צריכה לתמוך ברמה 4 של הפרופיל הראשי.
• צריכה לתמוך בפרופילים של קידוד וידאו באיכות HD (High Definition) כמו שמצוין בטבלה הבאה.

אם הטמעות של מכשירים מדווחות על תמיכה בקידוד H.264 לסרטונים ברזולוציה של 720p או 1080p באמצעות ממשקי ה-API של המדיה, הן:

• ‫[C-2-1] חובה לתמוך בפרופילי הקידוד שבטבלה הבאה.

5.2.3. VP8

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

• ‫[C-1-1] חובה לתמוך בפרופילי קידוד של סרטוני SD.
• צריכה להיות תמיכה בפרופילים הבאים של קידוד וידאו באיכות HD (High Definition).
• ‫[C-1-2] חובה לתמוך בכתיבת קובצי Matroska WebM.
• מומלץ לספק קודק VP8 בחומרה שעומד בדרישות הקידוד בחומרה של פרויקט WebM RTC, כדי להבטיח איכות מקובלת של סטרימינג של וידאו באינטרנט ושירותי שיחות ועידה בווידאו.

אם הטמעות של מכשירים מדווחות על תמיכה בקידוד VP8 לסרטונים ברזולוציה של 720p או 1080p דרך ממשקי ה-API של המדיה, הן:

• ‫[C-2-1] חובה לתמוך בפרופילי הקידוד שבטבלה הבאה.

‫5.2.4. VP9

אם הטמעות המכשירים תומכות ב-VP9 codec, הן:

• ‫[C-1-2] חייב לתמוך בפרופיל 0 ברמה 3.
• ‫[C-1-1] חובה לתמוך בכתיבה של קובצי Matroska WebM.
• ‫[C-1-3] חובה ליצור נתוני CodecPrivate.
• צריכה להיות תמיכה בפרופילים של פענוח HD, כמו שמצוין בטבלה הבאה.
• מומלץ מאוד להשתמש ב-SR כדי לתמוך בפרופילים של פענוח HD, כמו שמצוין בטבלה הבאה, אם יש מקודד חומרה.

אם הטמעות של מכשירים טוענות לתמיכה בפרופיל 2 או בפרופיל 3 דרך ממשקי ה-API של המדיה:

• התמיכה בפורמט 12 ביט היא אופציונלית.

‫5.2.5. H.265

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

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

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] חובה לתמוך בפרופיל Baseline ברמה 30 וברמה 45.

5.3.3. MPEG-4

אם המכשירים כוללים יישומי מפענח MPEG-4, הם:

• ‫[C-1-1] חובה לתמוך ברמת פרופיל פשוטה 3.

‫5.3.4. H.264

אם ההטמעות של המכשירים תומכות במפענחי H.264, הן:

• ‫[C-1-1] חובה לתמוך בפרופיל הראשי ברמה 3.1 ובפרופיל Baseline. התמיכה ב-ASO (Arbitrary Slice Ordering), ב-FMO (Flexible Macroblock Ordering) וב-RS (Redundant Slices) היא אופציונלית.
• ‫[C-1-2] חייב להיות מסוגל לפענח סרטונים עם פרופילי SD (איכות רגילה) שמפורטים בטבלה הבאה, ולקודד אותם עם פרופיל Baseline ופרופיל Main ברמה 3.1 (כולל 720p30).
• צריכה להיות אפשרות לפענח סרטונים עם פרופילים של HD (איכות גבוהה) כמו שמצוין בטבלה הבאה.

אם הגובה שמדווח על ידי השיטה Display.getSupportedModes() שווה לרזולוציית הסרטון או גדול ממנה, הטמעות במכשיר:

• ‫[C-2-1] המכשיר חייב לתמוך בפרופילים של פענוח וידאו באיכות HD 720p שמפורטים בטבלה הבאה.
• ‫[C-2-2] המכשיר חייב לתמוך בפרופילים של פענוח וידאו באיכות HD 1080p, שמופיעים בטבלה הבאה.

‫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.

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

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

‫5.3.6. VP8

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

• ‫[C-1-1] חובה לתמוך בפרופילים של פענוח SD בטבלה הבאה.
• מומלץ להשתמש במקודד VP8 לחומרה שעומד בדרישות.
• צריכים לתמוך בפרופילים של פענוח HD בטבלה הבאה.

אם הגובה שמוחזר על ידי השיטה Display.getSupportedModes() שווה לרזולוציית הסרטון או גדול ממנה:

• ‫[C-2-1] הטמעות של מכשירים חייבות לתמוך בפרופילים של 720p בטבלה הבאה.
• ‫[C-2-2] הטמעות של מכשירים חייבות לתמוך בפרופילים של 1080p בטבלה הבאה.

5.3.7. VP9

אם הטמעות המכשירים תומכות ב-VP9 codec, הן:

• ‫[C-1-1] חובה לתמוך בפרופילים של פענוח סרטוני SD, כמו שמצוין בטבלה הבאה.
• צריכה להיות תמיכה בפרופילים של פענוח HD, כמו שמצוין בטבלה הבאה.

אם ההטמעות במכשיר תומכות ב-VP9 codec ובמפענח חומרה:

• ‫[C-2-1] חובה לתמוך בפרופילים של פענוח HD, כמו שמצוין בטבלה הבאה.

אם הגובה שמדווח על ידי השיטה Display.getSupportedModes() שווה לרזולוציה של הסרטון או גדול ממנה:

• ‫[C-3-1] הטמעות של מכשירים חייבות לתמוך בפענוח של לפחות אחד מהפרופילים VP9 או H.265 ברזולוציות 720, ‏ 1080 ו-UHD.

אם הטמעות של מכשירים טוענות לתמיכה ב-VP9Profile2 או ב-VP9Profile3 באמצעות ממשקי ה-API של המדיה CodecProfileLevel:

• התמיכה בפורמט 12 ביט היא אופציונלית.

אם הטמעות של מכשירים טוענות לתמיכה בפרופיל HDR (‏VP9Profile2HDR, ‏ VP9Profile2HDR10Plus, ‏ VP9Profile3HDR, ‏ VP9Profile3HDR10Plus) דרך ממשקי ה-API של המדיה:

• ‫[C-4-1] הטמעות של מכשירים חייבות לקבל את המטא-נתונים הנדרשים של HDR (KEY_HDR_STATIC_INFO לכל פרופילי ה-HDR, וגם 'KEY_HDR10_PLUS_INFO' לפרופילי HDR10Plus) מהאפליקציה. הם גם חייבים לתמוך בחילוץ של מטא-נתונים נדרשים של HDR מזרם הביטים או מהמאגר, ובהפקתם.
• ‫[C-4-2] יישומי מכשירים חייבים להציג תוכן HDR בצורה תקינה במסך המכשיר או ביציאת וידאו רגילה (למשל, HDMI).

‫5.3.8. Dolby Vision

אם הטמעות של מכשירים מצהירות על תמיכה במפענח Dolby Vision דרך HDR_TYPE_DOLBY_VISION , הן:

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

‫5.3.9. AV1

אם הטמעות המכשירים תומכות ב-codec‏ AV1, הן:

• ‫[C-1-1] חובה לתמוך בפרופיל 0, כולל תוכן של 10 ביט.

5.4. הקלטת אודיו

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

5.4.1. הקלטת אודיו גולמי ופרטי מיקרופון

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

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

  • פורמט: Linear PCM, 16-bit
  • תדירויות דגימה: 8,000,‏ 11,025,‏ 16,000,‏ 44,100,‏ 48,000 הרץ
  • ערוצים: מונו

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

  • פורמט: Linear PCM, ‏ 16 ביט ו-24 ביט
  • תדירויות דגימה: 8,000,‏ 11,025,‏ 16,000,‏ 22,050,‏ 24,000,‏ 32,000,‏ 44,100,‏ 48,000 הרץ
  • ערוצים: מספר הערוצים זהה למספר המיקרופונים במכשיר

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

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

• צריך לאפשר הקלטה של תוכן אודיו גולמי באיכות של רדיו AM ו-DVD, כלומר עם המאפיינים הבאים:

  • פורמט: Linear PCM, 16-bit
  • תדירויות דגימה: 22050, ‏ 48000 הרץ
  • ערוצים: סטריאו
  • ‫[C-1-4] חובה לכבד את ממשק ה-API‏ MicrophoneInfo ולמלא בצורה נכונה את המידע על המיקרופונים הזמינים במכשיר שאפליקציות של צד שלישי יכולות לגשת אליהם דרך ממשק ה-API‏ AudioManager.getMicrophones(), ועל המיקרופונים הפעילים כרגע שאפליקציות של צד שלישי יכולות לגשת אליהם דרך ממשקי ה-API‏ AudioRecord.getActiveMicrophones() ו-MediaRecorder.getActiveMicrophones(). אם ההטמעות של המכשיר מאפשרות רדיו AM וצילום של תוכן אודיו גולמי באיכות DVD, הן:

• ‫[C-2-1] חובה לצלם ללא הגדלת דגימה בכל יחס גבוה מ-16000:22050 או 44100:48000.

• ‫[C-2-2] חובה לכלול מסנן מתאים נגד Aliasing לכל דגימת יתר או דגימת חסר.

5.4.2. הקלטה לזיהוי דיבור

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

• ‫[C-1-1] המכשיר חייב ללכוד את מקור האודיו android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION באחת מתדירויות הדגימה הבאות: 44100 ו-48000.
• ‫[C-1-2] חובה להשבית כברירת מחדל כל עיבוד אודיו להפחתת רעשים בעת הקלטת זרם אודיו ממקור האודיו AudioSource.VOICE_RECOGNITION.
• ‫[C-1-3] חובה להשבית כברירת מחדל את כל אמצעי השליטה האוטומטיים בעוצמת הקול כשמקליטים אודיו ממקור האודיו AudioSource.VOICE_RECOGNITION.
• מומלץ להקליט את זרם האודיו של זיהוי הדיבור עם מאפיינים של אמפליטודה שטוחה בקירוב לעומת תדר: באופן ספציפי, ‎±3 dB, מ-100 Hz עד 4,000 Hz.
• מומלץ להקליט את זרם האודיו של זיהוי הדיבור עם רגישות קלט מוגדרת כך שמקור של עוצמת קול (SPL) של 90dB ב-1000Hz יניב RMS של 2500 עבור דגימות של 16 ביט.
• מומלץ להקליט את זרם האודיו של זיהוי הדיבור, כך שרמות המשרעת של PCM יעקבו באופן ליניארי אחרי שינויים ב-SPL של הקלט בטווח של לפחות 30dB, מ-‎-18dB עד ‎+12dB re 90dB SPL במיקרופון.
• מומלץ להקליט את זרם האודיו של זיהוי הדיבור עם עיוות הרמוני כולל (THD) של פחות מ-1% עבור 1‎ kHz ברמת קלט של 90‎ dB SPL במיקרופון.

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

• ‫[C-2-1] חובה לאפשר שליטה באפקט האודיו הזה באמצעות android.media.audiofx.NoiseSuppressor API.
• ‫[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

אם הטמעות המכשיר מספקות Acoustic Echo Canceler (מבטל הד אקוסטי) שמוכנס לנתיב האודיו של הלכידה כשבוחרים באפשרות AudioSource.VOICE_COMMUNICATION, הן:

• ‫[C-SR] מומלץ מאוד להצהיר על כך באמצעות שיטת ה-API‏ AcousticEchoCanceler‏ AcousticEchoCanceler.isAvailable()
• מומלץ מאוד [C-SR] לאפשר שליטה באפקט האודיו הזה באמצעות AcousticEchoCanceler API.
• [C-SR] מומלץ מאוד להשתמש בשדה AudioEffect.Descriptor.uuid כדי לזהות באופן ייחודי כל הטמעה של טכנולוגיית AEC.

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. עוצמת המיקרופון

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

• צריכה להציג מאפיינים שטוחים בקירוב של אמפליטודה לעומת תדר בטווח התדרים האמצעי: במיוחד ±3dB מ-100 הרץ עד 4,000 הרץ לכל מיקרופון שמשמש להקלטת מקור האודיו של זיהוי הדיבור.
• מומלץ להגדיר את רגישות קלט האודיו כך שמקור טון סינוסי בתדר 1,000 הרץ שמופעל ברמת לחץ קול (SPL) של 90 דציבלים יניב תגובה עם RMS של 2,500 עבור דגימות של 16 ביט (או -22.35 דציבלים בסולם מלא עבור דגימות של נקודה צפה/דיוק כפול) לכל מיקרופון שמשמש להקלטת מקור האודיו של זיהוי הדיבור.
• מומלץ מאוד שרמות האמפליטודה של [C-SR] יהיו בטווח התדרים הנמוך: במיוחד מ-‎±20 dB מ-5 הרץ עד 100 הרץ בהשוואה לטווח התדרים הבינוני עבור כל מיקרופון שמשמש להקלטת מקור האודיו של זיהוי הדיבור.
• מומלץ מאוד להציג רמות אמפליטודה בטווח התדרים הגבוה: במיוחד מ-‎±30 dB מ-4,000 הרץ עד 22,000 הרץ בהשוואה לטווח התדרים הבינוני לכל מיקרופון שמשמש להקלטת מקור האודיו של זיהוי הקול.

5.5. הפעלת אודיו

מערכת Android כוללת תמיכה שמאפשרת לאפליקציות להפעיל אודיו דרך ציוד היקפי של פלט אודיו, כפי שמוגדר בסעיף 7.8.2.

‫5.5.1. הפעלת אודיו גולמי

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

• ‫[C-1-1] חובה לאפשר הפעלה של תוכן אודיו גולמי עם המאפיינים הבאים:

  • פורמטים של מקור: Linear PCM, ‏ 16 ביט, 8 ביט, float
  • ערוצים: מונו, סטריאו, הגדרות תקינות של ריבוי ערוצים עם עד 8 ערוצים
  • שיעורי דגימה (בהרץ):
    • ‫8,000, 11,025, 16,000, 22,050, 32,000, 44,100, 48,000 בהגדרות הערוץ שצוינו למעלה
    • ‫96,000 במונו ובסטריאו

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

  • תדירויות דגימה: 24000, ‏ 48000

‫5.5.2. אפקטים קוליים

‫Android מספקת API לאפקטים של אודיו להטמעות במכשירים.

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

• ‫[C-1-1] חובה לתמוך בהטמעות של EFFECT_TYPE_EQUALIZER ו-EFFECT_TYPE_LOUDNESS_ENHANCER שניתן לשלוט בהן באמצעות מחלקות המשנה של AudioEffect‏ Equalizer ו-LoudnessEnhancer.
• ‫[C-1-2] חובה לתמוך בהטמעה של Visualizer API, שאפשר לשלוט בה באמצעות המחלקה Visualizer.
• ‫[C-1-3] חובה לתמוך בהטמעה של EFFECT_TYPE_DYNAMICS_PROCESSING שניתנת לשליטה באמצעות מחלקת המשנה AudioEffect‏ DynamicsProcessing.
• צריך לתמוך בהטמעות של EFFECT_TYPE_BASS_BOOST,‏ EFFECT_TYPE_ENV_REVERB,‏ EFFECT_TYPE_PRESET_REVERB ו-EFFECT_TYPE_VIRTUALIZER שאפשר לשלוט בהן באמצעות מחלקות המשנה AudioEffect BassBoost,‏ EnvironmentalReverb,‏ PresetReverb ו-Virtualizer.
• ‫[C-SR] מומלץ מאוד לתמוך באפקטים בנקודה צפה ובערוצים מרובים.

‫5.5.3. עוצמת הקול של פלט האודיו

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

• צריך לאפשר כוונון של עוצמת הקול של כל אחד מזרמי האודיו בנפרד, באמצעות סוג התוכן או השימוש כפי שמוגדר ב-AudioAttributes, ושימוש באודיו ברכב כפי שמוגדר באופן ציבורי ב-android.car.CarAudioManager.

5.6. זמן אחזור אודיו

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

לצורך הסעיף הזה, משתמשים בהגדרות הבאות:

• זמן האחזור של הפלט. המרווח בין הזמן שבו אפליקציה כותבת פריים של נתונים מקודדים ב-PCM לבין הזמן שבו הצליל התואם מוצג לסביבה במתמר במכשיר, או שהאות יוצא מהמכשיר דרך יציאה וניתן לצפייה חיצונית.
• זמן אחזור של פלט ראשוני. זמן האחזור של הפלט של הפריים הראשון, כשהמערכת של פלט האודיו הייתה במצב לא פעיל וכבויה לפני הבקשה.
• זמן האחזור של הפלט הרציף. השהיית הפלט של פריימים עוקבים, אחרי שהמכשיר מפעיל אודיו.
• זמן אחזור של קלט. המרווח בין הרגע שבו הסביבה מציגה צליל למכשיר במתמר במכשיר או שהאות נכנס למכשיר דרך יציאה, לבין הרגע שבו האפליקציה קוראת את המסגרת המתאימה של נתונים שמקודדים ב-PCM.
• הקלט אבד. החלק הראשוני של אות קלט שלא ניתן לשימוש או שלא זמין.
• זמן האחזור של קלט בהפעלה מההתחלה. סכום הזמן של אובדן הקלט וזמן האחזור של הקלט במסגרת הראשונה, כשהמערכת של קלט האודיו הייתה במצב לא פעיל וכבויה לפני הבקשה.
• זמן אחזור ארוך של קלט. השהיית הקלט של פריים עוקב, בזמן שהמכשיר מקליט אודיו.
• cold output jitter. השונות בין מדידות נפרדות של ערכי השהייה של פלט במצב התחלתי (cold start).
• cold input jitter. השונות בין מדידות נפרדות של ערכי זמן האחזור של קלט במצב התחלתי (cold start).
• זמן אחזור רציף. סכום של חביון קלט רציף, חביון פלט רציף ותקופת מאגר אחת. תקופת ההשהיה מאפשרת לאפליקציה לעבד את האות ולצמצם את ההפרש בין השלב של זרמי הקלט והפלט.
• ‫OpenSL ES PCM buffer queue API. קבוצת ממשקי ה-API שקשורים ל-PCM ב-OpenSL ES בתוך Android NDK.
• ‫AAudio native audio API. קבוצת ממשקי ה-API של AAudio בתוך Android NDK.
• חותמת זמן. זוג שמורכב ממיקום יחסי של פריים בתוך סטרימינג ומהזמן המשוער שבו הפריים הזה נכנס לצינור העיבוד של האודיו בנקודת הקצה המשויכת או יוצא ממנו. אפשר לעיין גם בAudioTimestamp.
• glitch. הפרעה זמנית או ערך מדגם שגוי באות האודיו, בדרך כלל בגלל תת-גלישה של מאגר בפלט, גלישה של מאגר בקלט או כל מקור אחר של רעש דיגיטלי או אנלוגי.

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

• ‫[C-1-1] חותמת הזמן של הפלט שמוחזרת על ידי AudioTrack.getTimestamp ו-AAudioStream_getTimestamp מדויקת בטווח של ‎+/- 2 ms.
• ‫[C-1-2] זמן האחזור של פלט קר הוא 500 אלפיות השנייה או פחות.

אם הטמעות של מכשירים מצהירות על android.hardware.audio.output מומלץ מאוד לעמוד בדרישות הבאות או לעלות עליהן:

• ‫[C-SR] זמן אחזור של 100 אלפיות השנייה או פחות בפלט של הפעלה מההתחלה (cold startup). מומלץ מאוד שמכשירים קיימים וחדשים שמופעלת בהם גרסת Android הזו יעמדו בדרישות האלה כבר עכשיו. בגרסה עתידית של הפלטפורמה בשנת 2021, נדרוש זמן אחזור של פלט קר של 200 אלפיות השנייה או פחות.
• ‫[C-SR] זמן אחזור של פלט רציף של 45 אלפיות השנייה או פחות.
• ‫[C-SR] צמצום הג'יטר של פלט הקור.
• ‫[C-SR] חותמת הזמן של הפלט שמוחזרת על ידי AudioTrack.getTimestamp ו-AAudioStream_getTimestamp מדויקת בטווח של ‎+/- 1 ms.

אם ההטמעות במכשיר עומדות בדרישות שלמעלה, אחרי כל כיול ראשוני, כשמשתמשים גם בתור במאגר נתונים זמני (buffer queue) של OpenSL ES PCM וגם בממשקי ה-API של AAudio native audio, לזמן האחזור של פלט רציף ולזמן האחזור של פלט קר לפחות במכשיר אחד נתמך של פלט אודיו, הם:

• ‫[C-SR] מומלץ מאוד לדווח על אודיו עם זמן אחזור נמוך על ידי הצהרה על feature flag‏ android.hardware.audio.low_latency.
• ‫[C-SR] מומלץ מאוד לעמוד בדרישות לאודיו עם השהיה נמוכה באמצעות AAudio API.
• [C-SR] מומלץ מאוד לוודא שעבור סטרימינג שמחזיר AAUDIO_PERFORMANCE_MODE_LOW_LATENCY מ-AAudioStream_getPerformanceMode(), הערך שמוחזר על ידי AAudioStream_getFramesPerBurst() קטן מהערך שמוחזר על ידי android.media.AudioManager.getProperty(String) או שווה לו עבור מפתח הנכס AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

אם הטמעות המכשירים לא עומדות בדרישות של אודיו עם השהיה נמוכה באמצעות תור במאגר נתונים זמני (buffer queue) של ה-PCM של OpenSL ES וממשקי ה-API המקוריים של AAudio, הן:

• ‫[C-2-1] אסור לדווח על תמיכה באודיו עם זמן אחזור נמוך.

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

• ‫[C-3-1] השגיאה בחותמות הזמן של הקלט, שמוחזרות על ידי AudioRecord.getTimestamp או AAudioStream_getTimestamp, מוגבלת ל-‎+/- 2 ms. 'שגיאה' כאן פירושה הסטייה מהערך הנכון.
• ‫[C-3-2] זמן האחזור של קלט קר הוא 500 מילי-שניות או פחות.

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

• ‫[C-SR] זמן אחזור של קלט בהפעלה מההתחלה (cold startup) של 100 אלפיות השנייה או פחות. מומלץ מאוד שמכשירים קיימים וחדשים שמופעלת בהם גרסת Android הזו יעמדו בדרישות האלה כבר עכשיו. בגרסה עתידית של הפלטפורמה בשנת 2021, נדרוש זמן אחזור של קלט קר של 200 אלפיות השנייה או פחות כדרישת חובה.
• ‫[C-SR] זמן אחזור קבוע של קלט של 30 אלפיות השנייה או פחות.
• ‫[C-SR] זמן אחזור רציף הלוך ושוב של 50 אלפיות השנייה או פחות.
• ‫[C-SR] צמצום הג'יטר של קלט קר.
• ‫[C-SR] מגבילים את השגיאה בחותמות הזמן של הקלט, כפי שמוחזרות על ידי AudioRecord.getTimestamp או AAudioStream_getTimestamp, לערך של ‎+/- 1 ms.

‫5.7. פרוטוקולי רשת

ההטמעות במכשירים חייבות לתמוך בפרוטוקולים של רשתות מדיה להפעלת אודיו ווידאו, כפי שמפורט בתיעוד של Android SDK.

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

• ‫[C-1-1] חובה לתמוך בכל ה-Codecs ופורמטי הקונטיינר הנדרשים בקטע 5.1 דרך HTTP(S).

• ‫[C-1-2] חובה לתמוך בפורמטים של מקטעי מדיה שמוצגים בטבלה 'פורמטים של מקטעי מדיה' שבהמשך, באמצעות פרוטוקול טיוטה של HTTP Live Streaming, גרסה 7.

• ‫[C-1-3] חובה לתמוך בפרופיל האודיו והווידאו הבא של RTP ובקודקים הקשורים בטבלת ה-RTSP שלמטה. מקרים יוצאים מן הכלל מפורטים בהערות השוליים של הטבלה בסעיף 5.1.

פורמטים של פלחים של מדיה

‫RTSP (RTP, SDP)

5.8. Secure Media

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

• ‫[C-1-1] חובה להצהיר על תמיכה ב-Display.FLAG_SECURE.

אם הטמעות של מכשירים מצהירות על תמיכה ב-Display.FLAG_SECURE ותומכות בפרוטוקול של תצוגת Wi-Fi, הן:

• ‫[C-2-1] חובה לאבטח את הקישור באמצעות מנגנון חזק מבחינה קריפטוגרפית, כמו HDCP 2.x ומעלה, עבור המסכים שמחוברים באמצעות פרוטוקולים אלחוטיים כמו Miracast.

אם הטמעות של מכשירים מצהירות על תמיכה ב-Display.FLAG_SECURE ותומכות בצג חיצוני קווי, הן:

• ‫[C-3-1] חובה לתמוך ב-HDCP 1.2 ומעלה בכל המסכים החיצוניים שמחוברים דרך יציאה קווית שהמשתמש יכול לגשת אליה.

5.9. ממשק דיגיטלי לכלים מוזיקליים (MIDI)

אם הטמעות של מכשירים מדווחות על תמיכה בתכונה android.software.midi באמצעות המחלקה android.content.pm.PackageManager, הן:

• ‫[C-1-1] חובה לתמוך ב-MIDI בכל אמצעי התקשורת בחומרה שתומכים ב-MIDI, שדרכם מסופקת קישוריות כללית שאינה MIDI, כאשר אמצעי התקשורת האלה הם:

  • מצב מארח USB, סעיף 7.7
  • ‫MIDI over Bluetooth LE acting in central role, section 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] זמן טעינת אודיו (audio latency) הרציף הלוך ושוב, כפי שמוגדר בקטע 5.6 בנושא זמן טעינת אודיו (audio latency), חייב להיות 20 אלפיות השנייה או פחות, ומומלץ שיהיה 10 אלפיות השנייה או פחות לפחות בנתיב נתמך אחד.
• ‫[C-1-3] חייב לכלול יציאות USB שתומכות במצב מארח USB ובמצב ציוד היקפי USB.
• ‫[C-1-4] חובה לדווח על תמיכה בתכונה android.software.midi.
• ‫[C-1-5] המכשיר חייב לעמוד בדרישות של זמן האחזור והאודיו ב-USB באמצעות OpenSL ES PCM buffer queue API ולפחות נתיב אחד של AAudio native audio API.
• ‫[SR] מומלץ מאוד להשתמש ב-AAudio native audio API במקום ב-MMAP path כדי לעמוד בדרישות של זמן האחזור והאודיו ב-USB.
• ‫[C-1-6] חובה שזמן האחזור של הפלט במצב 'הפעלה קרה' יהיה 200 אלפיות השנייה או פחות.
• ‫[C-1-7] חובה שזמן האחזור של קלט קר יהיה 200 אלפיות השנייה או פחות.
• [SR] מומלץ מאוד לספק רמה עקבית של ביצועי מעבד בזמן שהאודיו פעיל ועומס המעבד משתנה. צריך לבצע את הבדיקה באמצעות גרסת אפליקציית Android של SynthMark עם מזהה commit‏ 09b13c6f49ea089f8c31e5d035f912cc405b7ab8. ‫SynthMark משתמשת בסינתיסייזר תוכנה שפועל במסגרת אודיו מדומה שמודדת את ביצועי המערכת. צריך להפעיל את אפליקציית SynthMark באמצעות האפשרות 'בדיקה אוטומטית' ולהשיג את התוצאות הבאות:
  • voicemark.90 >= 32 voices
  • latencymark.fixed.little <= 15 msec
  • latencymark.dynamic.little <= 50 msec

במסמכי התיעוד של SynthMark מוסבר על המדדים.

• מומלץ לצמצם את חוסר הדיוק של שעון האודיו ואת הסחף שלו ביחס לזמן רגיל.
• מומלץ למזער את הסחף של שעון האודיו ביחס למעבד CLOCK_MONOTONIC כששניהם פעילים.
• מומלץ לצמצם את זמן טעינת האודיו (audio latency) באמצעות מתמרים במכשיר.
• מומלץ לצמצם את זמן טעינת אודיו (audio latency) באודיו דיגיטלי ב-USB.
• צריך לתעד את מדידות זמן טעינת אודיו (audio latency) בכל הנתיבים.
• צריך למזער את הג'יטר בזמני הכניסה של קריאות חוזרות להשלמת מאגר שמע, כי הוא משפיע על אחוז רוחב הפס המלא של המעבד שניתן לשימוש על ידי הקריאה החוזרת.
• צריך לספק אפס תקלות באודיו בשימוש רגיל בערך השהיה שדווח.
• צריך לספק אפס הבדלים בזמן האחזור בין הערוצים.
• צריך למזער את זמן האחזור הממוצע של MIDI בכל אמצעי התקשורת.
• צריך לצמצם את השונות בזמן האחזור של MIDI בעומס (ג'יטר) בכל אמצעי התקשורת.
• צריך לספק חותמות זמן מדויקות של MIDI בכל אמצעי התקשורת.
• צריך לצמצם את הרעש באות האודיו במתמרים במכשיר, כולל התקופה מיד אחרי הפעלה במצב התחלתי.
• צריך לספק אפס הפרש בשעון האודיו בין הצד של הקלט לבין הצד של הפלט בנקודות קצה תואמות, כששניהם פעילים. דוגמאות לנקודות קצה תואמות כוללות את המיקרופון והרמקול במכשיר, או את הקלט והפלט של שקע האודיו.
• צריך לטפל בקריאות חוזרות להשלמת מאגר האודיו בצדדי הקלט והפלט של נקודות קצה תואמות באותו השרשור, כשהן פעילות, ולהיכנס לקריאה החוזרת של הפלט מיד אחרי החזרה מהקריאה החוזרת של הקלט. אם אי אפשר לטפל בקריאות החוזרות באותו השרשור, צריך להזין את הקריאה החוזרת של הפלט זמן קצר אחרי הזנת הקריאה החוזרת של הקלט, כדי לאפשר לאפליקציה תזמון עקבי של צדדי הקלט והפלט.
• צריך לצמצם את הפרש הפאזה בין אחסון אודיו ב-HAL בצד הקלט ובצד הפלט של נקודות קצה תואמות.
• מומלץ למזער את זמן התגובה למגע.
• צריך למזער את השונות בזמן האחזור של מגע בעומס (ג'יטר).
• זמן האחזור מהקלט של מגע ועד לפלט אודיו צריך להיות קטן מ-40 אלפיות השנייה או שווה לו.

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

• ‫[SR] מומלץ מאוד לדווח על תמיכה בתכונה android.hardware.audio.pro באמצעות המחלקה android.content.pm.PackageManager.

אם הטמעות המכשירים כוללות שקע אודיו של 3.5 מ"מ עם 4 מוליכים, הן:

• ‫[C-2-1] חובה שזמן טעינת אודיו (audio latency) הרציף הלוך ושוב יהיה 20 אלפיות השנייה או פחות דרך שקע האודיו.
• [SR] מומלץ מאוד לעמוד בדרישות של הקטע מפרטים של מכשירים ניידים (שקע) במפרט של אוזניות חוטיות (גרסה 1.1).
• זמן טעינת אודיו (audio latency) רציף הלוך ושוב צריך להיות 10 אלפיות השנייה או פחות בנתיב של שקע האודיו.

אם יישומי המכשיר לא כוללים שקע אודיו 3.5 מ"מ עם 4 מוליכים וכוללים יציאות USB שתומכות במצב מארח USB, הם:

• ‫[C-3-1] חובה להטמיע את מחלקת האודיו של USB.
• ‫[C-3-2] חובה שזמן טעינת אודיו (audio latency) הלוך ושוב יהיה רציף ויעמוד על 20 אלפיות השנייה או פחות ביציאת מצב המארח של ה-USB באמצעות מחלקת אודיו של USB.
• זמן טעינת האודיו (audio latency) הרציף הלוך ושוב צריך להיות 10 אלפיות השנייה או פחות ביציאת מצב המארח של ה-USB באמצעות מחלקת אודיו של USB.
• [C-SR] מומלץ מאוד לתמוך בקלט/פלט בו-זמני של עד 8 ערוצים בכל כיוון, קצב דגימה של 96kHz ועומק של 24 ביט או 32 ביט, כשמשתמשים בציוד היקפי לאודיו ב-USB שתומך גם בדרישות האלה.

אם הטמעות המכשירים כוללות יציאת HDMI, הן:

• צריך לתמוך בפלט בסטריאו ובשמונה ערוצים בעומק של 20 ביט או 24 ביט וב-192 kHz ללא אובדן של עומק הביט או דגימה מחדש, לפחות בהגדרה אחת.

‫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] חייבת להיות תצוגה של מאפייני אמפליטודה שטוחה בקירוב לעומת תדר בטווח התדרים האמצעי: באופן ספציפי, ‎±10dB מ-100 הרץ עד 7,000 הרץ לכל מיקרופון שמשמש להקלטת מקור האודיו שלא עבר עיבוד.

• ‫[C-1-3] רמות האמפליטודה חייבות להיות בטווח התדרים הנמוך: במיוחד מ-‎±20 dB מ-5 הרץ עד 100 הרץ בהשוואה לטווח התדרים הבינוני עבור כל מיקרופון שמשמש להקלטת מקור האודיו שלא עבר עיבוד.

• ‫[C-1-4] רמות האמפליטודה צריכות להיות בטווח התדרים הגבוה: במיוחד מ-‎±30 dB מ-7,000 הרץ עד 22,000 הרץ בהשוואה לטווח התדרים הבינוני עבור כל מיקרופון שמשמש להקלטת מקור האודיו שלא עבר עיבוד.

• ‫[C-1-5] חובה להגדיר את רגישות קלט האודיו כך שמקור טון סינוסואידי בתדר 1,000 הרץ שמופעל ברמת לחץ קול (SPL) של 94 דציבלים יניב תגובה עם RMS של 520 עבור דגימות של 16 ביט (או -36 דציבלים בסולם מלא עבור דגימות של נקודה צפה/דיוק כפול) לכל מיקרופון שמשמש להקלטת מקור האודיו שלא עבר עיבוד.

• ‫[C-1-6] לכל מיקרופון שמשמש להקלטת מקור האודיו הלא מעובד צריך להיות יחס אות לרעש (SNR) של 60 דציבלים ומעלה. (בעוד שיחס האות לרעש נמדד כהפרש בין 94 dB SPL לבין SPL שווה ערך של רעש עצמי, עם משקל A).

• ‫[C-1-7] העיוות ההרמוני הכולל (THD) צריך להיות פחות מ-1% ב-1‎ kHz ברמת קלט של 90‎ dB SPL בכל מיקרופון שמשמש להקלטת מקור האודיו שלא עבר עיבוד.

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

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

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

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

• ‫[C-2-1] חובה להחזיר null עבור שיטת ה-API‏ AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), כדי לציין בצורה נכונה שאין תמיכה.
• [SR] עדיין מומלץ מאוד כדי לעמוד בכמה שיותר דרישות של נתיב האות למקור ההקלטה שלא עבר עיבוד.

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

‫6.1. כלים למפתחים

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

• ‫[C-0-1] חובה לתמוך ב-Android Developer Tools שזמינים ב-Android SDK.

• ‫Android Debug Bridge (adb)

  • ‫[C-0-2] חובה לתמוך ב-adb כפי שמתואר ב-Android SDK ובפקודות ה-shell שמופיעות ב-AOSP, שבהן יכולים להשתמש מפתחי אפליקציות, כולל dumpsys cmd stats
  • ‫[C-0-11] חייבת להיות תמיכה בפקודת השורת הפקודה cmd testharness. יכול להיות ששדרוג של יישומי מכשירים מגרסה קודמת של Android ללא בלוק נתונים קבוע יהיה פטור מדרישה C-0-11.
  • ‫[C-0-3] אסור לשנות את הפורמט או את התוכן של אירועי מערכת במכשיר (batterystats , ‏ diskstats, ‏ fingerprint, ‏ graphicsstats, ‏ netstats, ‏ notification, ‏ procstats) שנרשמים ביומן באמצעות הפקודה dumpsys.
  • ‫[C-0-10] חובה לתעד, ללא השמטה, ולהפוך את האירועים הבאים לנגישים ולזמינים לפקודת ה-shell‏ cmd stats ולמחלקת System API‏ StatsManager.
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • ‫[C-0-4] שד ה-adb בצד המכשיר חייב להיות לא פעיל כברירת מחדל, וחייב להיות מנגנון שהמשתמש יכול לגשת אליו כדי להפעיל את Android Debug Bridge.
  • ‫[C-0-5] חובה לתמוך ב-adb מאובטח. ‫Android כולל תמיכה ב-adb מאובטח. ‫adb מאובטח מאפשר להשתמש ב-adb במארחים מאומתים מוכרים.
  • [C-0-6] חובה לספק מנגנון שמאפשר להתחבר ל-adb ממחשב מארח. פרטים נוספים:

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

  • ‫[C-3-1] חובה להטמיע את adb דרך רשת מקומית (כמו אתרנט או Wi-Fi).
  • ‫[C-3-2] חובה לספק מנהלי התקנים ל-Windows 7, ‏ Windows 8 ו-Windows 10, כדי לאפשר למפתחים להתחבר למכשיר באמצעות פרוטוקול adb.

  אם הטמעות של מכשירים תומכות בחיבורי adb למחשב מארח באמצעות Wi-Fi, הן:

  • ‫[C-4-1] השיטה AdbManager#isAdbWifiSupported() חייבת להחזיר true.

  אם הטמעות המכשירים תומכות בחיבורי adb למחשב מארח באמצעות Wi-Fi וכוללות לפחות מצלמה אחת, הן:

  • ‫[C-5-1] השיטה AdbManager#isAdbWifiQrSupported() חייבת להחזיר true.

• ‫Dalvik Debug Monitor Service (ddms)

  • ‫[C-0-7] חובה לתמוך בכל התכונות של ddms כפי שמתועד ב-Android SDK. מכיוון ש-ddms משתמש ב-adb, התמיכה ב-ddms צריכה להיות לא פעילה כברירת מחדל, אבל היא חייבת להיות נתמכת בכל פעם שהמשתמש מפעיל את Android Debug Bridge, כמו שמתואר למעלה.
• Monkey
  • ‫[C-0-8] חובה לכלול את מסגרת Monkey ולהפוך אותה לזמינה לשימוש באפליקציות.
• SysTrace
  • ‫[C-0-9] חייב לתמוך בכלי systrace כפי שמתואר ב-Android SDK. הכלי Systrace צריך להיות מושבת כברירת מחדל, וחייב להיות מנגנון נגיש למשתמש להפעלת Systrace.
• Perfetto
  • [C-SR] מומלץ מאוד לחשוף /system/bin/perfetto קובץ בינארי למשתמש של המעטפת, ששורת הפקודה תהיה תואמת לתיעוד של perfetto.
  • ‫[C-SR] מומלץ מאוד לקבל את קובץ ה-protobuf של ההגדרה כקלט בפורמט בינארי של perfetto, בהתאם לסכימה שמוגדרת במסמכי התיעוד של perfetto.
  • ‫[C-SR] מומלץ מאוד להשתמש בבינארי של perfetto כדי לכתוב כפלט עקבות של protobuf שתואמים לסכימה שמוגדרת במסמכי התיעוד של perfetto.
  • [C-SR] מומלץ מאוד לספק, באמצעות קובץ הבינארי של perfetto, לפחות את מקורות הנתונים שמתוארים במסמכי התיעוד של perfetto.
• Low Memory Killer
  • ‫[C-0-10] חובה לכתוב LMK_KILL_OCCURRED_FIELD_NUMBER Atom ביומן statsd כש-Low Memory Killer מפסיק את פעולת האפליקציה.
• מצב Test Harness אם הטמעות המכשיר תומכות בפקודת ה-Shell‏ cmd testharness ומריצות את cmd testharness enable, הן:
  • ‫[C-2-1] חובה להחזיר את הערך true עבור ActivityManager.isRunningInUserTestHarness()
  • ‫[C-2-2] חובה להטמיע מצב מסגרת בדיקה כפי שמתואר במסמכי התיעוד בנושא מצב מסגרת בדיקה.

אם הטמעות של מכשירים מדווחות על תמיכה ב-Vulkan 1.0 ומעלה באמצעות android.hardware.vulkan.version דגלי התכונות, הן:

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

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

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

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

• ‫[C-0-1] חובה לכבד את כוונת android.settings.APPLICATION_DEVELOPMENT_SETTINGS להצגת הגדרות שקשורות לפיתוח אפליקציות. ביישום Android במעלה הזרם, התפריט 'אפשרויות למפתחים' מוסתר כברירת מחדל, והמשתמשים יכולים להפעיל את האפשרויות למפתחים אחרי שלוחצים שבע (7) פעמים על פריט התפריט הגדרות > מידע על המכשיר > מספר Build.
• ‫[C-0-2] חובה להסתיר את האפשרות 'אפשרויות למפתחים' כברירת מחדל.
• ‫[C-0-3] חובה לספק מנגנון ברור שלא מעניק יתרון לאפליקציית צד שלישי אחת על פני אחרת כדי להפעיל את אפשרויות הפיתוח. חובה לספק מסמך או אתר שגלויים לציבור ומתארים איך להפעיל את אפשרויות הפיתוח. חייב להיות קישור למסמך או לאתר הזה ממסמכי ה-Android SDK.
• צריכה להיות התראה ויזואלית שמוצגת למשתמש באופן שוטף כשהאפשרות 'אפשרויות למפתחים' מופעלת, ויש חשש לגבי בטיחות המשתמש.
• יכול להיות שנצטרך להגביל באופן זמני את הגישה לתפריט 'אפשרויות למפתחים' על ידי הסתרה חזותית או השבתה של התפריט, כדי למנוע הסחות דעת בתרחישים שבהם בטיחות המשתמש נמצאת בסיכון.

7. תאימות חומרה

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

• ‫[C-0-1] ההטמעה של המכשיר חייבת להטמיע את ה-API הזה כפי שמתואר במסמכי התיעוד של Android SDK.

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

• ‫[C-0-2] עדיין צריך להציג הגדרות מלאות של מחלקות (כפי שמתועד ב-SDK) עבור ממשקי ה-API של הרכיבים.
• ‫[C-0-3] ההתנהגויות של ה-API חייבות להיות מיושמות כפעולות שלא עושות כלום (no-ops) בצורה סבירה כלשהי.
• ‫[C-0-4] ה-methods של ה-API חייבים להחזיר ערכי null במקרים שמותרים לפי תיעוד ה-SDK.
• ‫[C-0-5] שיטות ה-API חייבות להחזיר הטמעות no-op של מחלקות שבהן ערכי null לא מותרים לפי תיעוד ה-SDK.
• ‫[C-0-6] שיטות API לא יכולות להחזיר חריגים שלא מתועדים במסמכי ה-SDK.
• ‫[C-0-7] יישומי מכשירים חייבים לדווח באופן עקבי על מידע מדויק לגבי הגדרת החומרה באמצעות השיטות getSystemAvailableFeatures() ו-hasSystemFeature(String) במחלקה android.content.pm.PackageManager עבור אותם מאפיינים ייחודיים של גרסת build.

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

7.1. תצוגה וגרפיקה

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

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

• גודל אלכסוני פיזי. המרחק באינצ'ים בין שתי פינות מנוגדות של החלק המואר של המסך.
• נקודות לאינץ' (dpi). מספר הפיקסלים שכלולים בטווח לינארי אופקי או אנכי של אינץ' אחד. אם מצוינים ערכי DPI, גם ה-DPI האופקי וגם ה-DPI האנכי צריכים להיות בטווח.
• יחס גובה-רוחב. היחס בין הפיקסלים של המימד הארוך יותר לבין הפיקסלים של המימד הקצר יותר של המסך. לדוגמה, מסך ברזולוציה של ‎480x854 פיקסלים יהיה ‎854/480 = 1.779, או בערך '16:9'.
• פיקסל שלא תלוי בצפיפות (dp). יחידת הפיקסל הווירטואלית מנורמלת למסך של 160 dpi, והחישוב שלה הוא: פיקסלים = dps * (צפיפות/160).

‫7.1.1. הגדרת תצורה של מסך

‫7.1.1.1. גודל וצורה של המסך

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

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

• ‫[C-0-1] חובה לדווח על גודל הפריסה הנכון של Configuration.screenLayout כפי שמוגדר במסמכי ה-SDK של Android. באופן ספציפי, הטמעות של מכשירים חייבות לדווח על המידות הנכונות של המסך בפיקסלים לוגיים שלא תלויים בדחיסות (dp), כמו שמוצג בהמשך:

  • במכשירים שבהם הערך של Configuration.uiMode מוגדר כערך כלשהו שאינו UI_MODE_TYPE_WATCH, ומוגדר גודל של small עבור Configuration.screenLayout, הגודל חייב להיות לפחות 426dp x 320dp.
  • במכשירים שמדווחים על normal גודל עבור Configuration.screenLayout, הגודל צריך להיות לפחות 480dp x 320dp.
  • במכשירים שמדווחים על large גודל עבור Configuration.screenLayout, הגודל חייב להיות לפחות 640dp x 480dp.
  • במכשירים שמדווחים על גודל xlarge של Configuration.screenLayout, הגודל המינימלי צריך להיות 960dp x 720dp.

• ‫[C-0-2] חובה לכבד באופן תקין את הצהרת התמיכה של האפליקציות בגדלי מסך באמצעות המאפיין <supports-screens> בקובץ AndroidManifest.xml, כפי שמתואר בתיעוד של Android SDK.

• יכול להיות שיש לו מסכים תואמי Android עם פינות מעוגלות.

אם הטמעות המכשיר תומכות ב-UI_MODE_TYPE_NORMAL וכוללות מסכים שתואמים ל-Android עם פינות מעוגלות, הן:

• [C-1-1] חובה לוודא שלפחות אחת מהדרישות הבאות מתקיימת:
• רדיוס הפינות המעוגלות קטן מ-38dp או שווה לו.

• כשממקמים תיבה בגודל 15dp על 15dp בכל פינה של התצוגה הלוגית, לפחות פיקסל אחד מכל תיבה גלוי במסך.

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

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

• ‫[C-2-1] חובה להטמיע את הגרסה היציבה האחרונה הזמינה של Extensions API או את הגרסה היציבה של Sidecar API לשימוש בספריית Window Manager Jetpack.

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

• ‫[C-3-1] חובה לדווח לאפליקציה על המיקום, הגבולות והמצב של הציר או הקיפול באמצעות תוספים או ממשקי API של sidecar.

פרטים על הטמעה נכונה של ממשקי ה-API של תוסף או sidecar זמינים במסמכי העזרה הציבוריים של Window Manager Jetpack.

‫7.1.1.2. יחס גובה-רוחב של המסך

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

• ‫[C-0-1] הטמעות של מכשירים עם הערך Configuration.uiMode שמוגדר כ-UI_MODE_TYPE_NORMAL חייבות לכלול ערך של יחס גובה-רוחב שקטן מ-1.86 או שווה לו (בערך 16:9), אלא אם האפליקציה עומדת באחד מהתנאים הבאים:

  • האפליקציה הצהירה שהיא תומכת ביחס גובה-רוחב גדול יותר של המסך באמצעות ערך המטא-נתונים android.max_aspect.
  • האפליקציה מצהירה שאפשר לשנות את הגודל שלה באמצעות המאפיין android:resizeableActivity.
  • האפליקציה מטרגטת לרמת API 24 ומעלה, ולא מוצהר בה android:maxAspectRatio שמגביל את יחס הגובה-רוחב המותר.

• ‫[C-0-2] הטמעות במכשירים עם Configuration.uiMode שמוגדר כ-UI_MODE_TYPE_NORMAL צריכות לכלול ערך של יחס גובה-רוחב ששווה ל-1.3333 (4:3) או גדול ממנו, אלא אם אפשר להרחיב את האפליקציה על ידי עמידה באחד מהתנאים הבאים:

  • האפליקציה מצהירה שאפשר לשנות את הגודל שלה באמצעות המאפיין android:resizeableActivity.
  • האפליקציה מצהירה על android:minAspectRatio שיגביל את יחס הגובה-רוחב המותר.

• ‫[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 מהצפיפות המקורית.
• כדי להבטיח שימושיות טובה וגדלים עקביים של גופנים, מומלץ לספק את ההתאמות הבאות של אפשרויות התצוגה המקוריות (תוך הקפדה על המגבלות שצוינו למעלה)
• קטן: 0.85x
• ברירת מחדל: 1x (קנה מידה מקורי של התצוגה)
• גדול: 1.15x
• גדול יותר: 1.3x
• הגדול ביותר 1.45x

‫7.1.2. מדדים של רשת המדיה

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

• ‫[C-1-1] חובה לדווח על ערכים נכונים לכל מדדי התצוגה שתואמים ל-Android ומוגדרים ב-API‏ android.util.DisplayMetrics.

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

• ‫[C-2-1] חובה לדווח על ערכים נכונים של התצוגה שתואמת ל-Android, כפי שמוגדר ב-API‏ android.util.DisplayMetrics עבור view.Display ברירת המחדל שנוצר באמצעות אמולציה.

‫7.1.3. כיוון מסך

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

• ‫[C-0-1] חובה לדווח על כיווני המסך הנתמכים (android.hardware.screen.portrait או android.hardware.screen.landscape) וחובה לדווח על כיוון נתמך אחד לפחות. לדוגמה, מכשיר עם מסך לרוחב בעל כיוון קבוע, כמו טלוויזיה או מחשב נייד, צריך לדווח רק על android.hardware.screen.landscape.
• ‫[C-0-2] חובה לדווח על הערך הנכון של הכיוון הנוכחי של המכשיר, בכל פעם שמתבצעת שאילתה באמצעות android.content.res.Configuration.orientation, android.view.Display.getOrientation() או ממשקי API אחרים.

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

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

‫7.1.4. האצת עיבוד גרפי בדו-ממד ובתלת-ממד

‫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] מומלץ מאוד לתמוך ב-OpenGL ES 3.1.
• צריך לתמוך ב-OpenGL ES 3.2.

אם הטמעות המכשירים תומכות באחת מגרסאות 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-SR] מומלץ מאוד לתמוך בתוספים EGL_KHR_partial_update ו-OES_EGL_image_external.
• צריכים לדווח בצורה מדויקת באמצעות השיטה getString() על כל פורמט דחיסה של טקסטורה שהם תומכים בו, שלרוב הוא ספציפי לספק.

אם הטמעות של מכשירים מצהירות על תמיכה ב-OpenGL ES 3.0,‏ 3.1 או 3.2, הן:

• ‫[C-3-1] חובה לייצא את סמלי הפונקציות המתאימים לגרסה הזו בנוסף לסמלי הפונקציות של OpenGL ES 2.0 בספרייה libGLESv2.so.
• [SR] מומלץ מאוד לתמוך בתוסף OES_EGL_image_external_essl3.

אם הטמעות המכשירים תומכות ב-OpenGL ES 3.2, הן:

• ‫[C-4-1] המכשיר חייב לתמוך בחבילת ההרחבות של 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, הן:

• [SR] מומלץ מאוד לכלול תמיכה ב-Vulkan 1.1.

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

• צריך לכלול תמיכה ב-Vulkan 1.1.

בדיקות ה-dEQP של Vulkan מחולקות למספר רשימות בדיקה, שלכל אחת מהן משויך תאריך או גרסה. הם נמצאים בעץ המקור של Android בכתובת external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. מכשיר שתומך ב-Vulkan ברמה שמוגדרת על ידי המכשיר עצמו, מציין שהוא יכול לעבור את בדיקות dEQP בכל רשימות הבדיקה מהרמה הזו ומקודמות לה.

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

• ‫[C-1-1] חובה לדווח על ערך שלם נכון עם דגלי התכונות android.hardware.vulkan.level ו-android.hardware.vulkan.version.
• ‫[C-1-2] חובה לבצע ספירה של לפחות VkPhysicalDevice עבור Native API של Vulkan‏ vkEnumeratePhysicalDevices() .
• ‫[C-1-3] חובה להטמיע באופן מלא את ממשקי Vulkan 1.0 API עבור כל VkPhysicalDevice שמופיע ברשימה.
• ‫[C-1-4] חובה למנות שכבות, שנכללות בספריות Native שנקראות libVkLayer*.so בספריית Native של חבילת האפליקציה, באמצעות ממשקי ה-API של Native ב-Vulkan‏ vkEnumerateInstanceLayerProperties() ו-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] חובה לדווח על הגרסה המקסימלית של בדיקות Vulkan dEQP שנתמכות באמצעות דגל התכונה android.software.vulkan.deqp.level.
• ‫[C-1-9] חובה לתמוך לפחות בגרסה 132317953 (מ-1 במרץ 2019) כפי שמדווח בדגל התכונה android.software.vulkan.deqp.level.
• ‫[C-1-10] חובה לעבור את כל הבדיקות של Vulkan dEQP ברשימות הבדיקות בין גרסה 132317953 לגרסה שצוינה ב-feature flag android.software.vulkan.deqp.level.
• ‫[C-SR] מומלץ מאוד לתמוך בסיומות VK_KHR_driver_properties ו-VK_GOOGLE_display_timing.

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

• ‫[C-2-1] אסור להצהיר על אף אחד מסימוני התכונות של Vulkan (למשל, android.hardware.vulkan.level, android.hardware.vulkan.version).
• ‫[C-2-2] אסור למנות VkPhysicalDevice כלשהם עבור Native API של Vulkan‏ vkEnumeratePhysicalDevices().

אם הטמעות של מכשירים כוללות תמיכה ב-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, כפי שמפורט במסמכי ה-SDK של Android.

‫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 במעלה הזרם.

‫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.
• מומלץ מאוד להשתמש ב-STRONGLY RECOMMENDED כדי לתמוך ב-GL_EXT_sRGB.

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

• ‫[C-2-1] צריך לכסות 100% או יותר מ-sRGB במרחב CIE 1931 xyY, למרות שסולם הצבעים של המסך לא מוגדר.

‫7.1.5. מצב תאימות לאפליקציות מדור קודם

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

‫7.1.6. טכנולוגיית מסך

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

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

• ‫[C-0-1] המכשיר חייב להיות מסוגל לעבד גרפיקה צבעונית של 16 ביט.
• צריך לתמוך במסכים שיכולים להציג גרפיקה צבעונית של 24 ביט.
• ‫[C-0-2] חובה שתהיה אפשרות לעבד אנימציות.
• ‫[C-0-3] חובה שיהיה יחס גובה-רוחב של פיקסלים (PAR) בין 0.9 ל-1.15. כלומר, יחס הגובה-רוחב של הפיקסלים חייב להיות קרוב לריבוע (1.0) עם טווח שגיאה של 10% עד 15%.

‫7.1.7. מסכים משניים

‫Android כולל תמיכה בצגים משניים שתואמים ל-Android, כדי לאפשר שיתוף של מדיה וממשקי API למפתחים לגישה לצגים חיצוניים.

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

• ‫[C-1-1] חובה להטמיע את שירות המערכת ואת ה-API‏ DisplayManager כפי שמתואר בתיעוד של Android SDK.

7.2. התקני קלט

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

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

‫7.2.1. מקלדת

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

• ‫[C-1-1] חובה להצהיר על ה-feature flag‏ android.software.input_methods.
• ‫[C-1-2] חובה להטמיע באופן מלא את Input Management Framework
• ‫[C-1-3] חובה לכלול מקלדת וירטואלית שמותקנת מראש.

הטמעות של מכשירים: * [C-0-1] אסור לכלול מקלדת חומרה שלא תואמת לאחד מהפורמטים שצוינו ב-android.content.res.Configuration.keyboard (QWERTY או 12 מקשים). * צריך לכלול הטמעות נוספות של מקלדת וירטואלית. * יכול להיות שהמכשיר כולל מקלדת חומרה.

‫7.2.2. ניווט ללא מגע

‫Android כולל תמיכה בכפתורי החיצים (D-pad), בכדור עקיבה ובגלגל כשיטות לניווט ללא מגע.

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

• ‫[C-0-1] חובה לדווח על הערך הנכון של android.content.res.Configuration.navigation.

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

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

‫7.2.3. מקשי ניווט

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

• ‫[C-0-1] חובה לספק למשתמש אפשרות להפעיל אפליקציות מותקנות שיש להן פעילות עם <intent-filter> שהוגדר עם ACTION=MAIN ו-CATEGORY=LAUNCHER או CATEGORY=LEANBACK_LAUNCHER בהטמעות של מכשירי טלוויזיה. הפונקציה 'בית' צריכה להיות המנגנון שמאפשר את השימוש הזה.
• צריך לספק לחצנים לפונקציות 'פריטים אחרונים' ו'חזרה'.

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

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

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

• [SR] מומלץ מאוד לא לספק את מנגנון הקלט עבור פונקציית התפריט, כי היא הוצאה משימוש לטובת סרגל הפעולות מאז Android 4.0.

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

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

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

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

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

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

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

• ‫[C-5-1] מקשי הניווט צריכים להשתמש בחלק נפרד של המסך, שלא זמין לאפליקציות, ואסור להם להסתיר את החלק של המסך שזמין לאפליקציות או להפריע לו בדרך אחרת.
• ‫[C-5-2] חובה להקצות חלק מהמסך לאפליקציות שעומדות בדרישות שמוגדרות בסעיף 7.1.1.
• ‫[C-5-3] חובה לכבד את הדגלים שהוגדרו על ידי האפליקציה באמצעות שיטת ה-API‏ View.setSystemUiVisibility(), כך שהחלק הנפרד הזה במסך (כלומר, סרגל הניווט) יוסתר בצורה תקינה כפי שמתואר ב-SDK.

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

• ‫[C-6-1] WindowInsets#getMandatorySystemGestureInsets() חייב לשמש רק לדיווח על אזור הזיהוי של תנועת הבית.
• ‫[C-6-2] אסור ליירט תנועות שמתחילות בתוך מלבן החרגה שסופק על ידי האפליקציה שבחזית באמצעות View#setSystemGestureExclusionRects(), אבל מחוץ ל-WindowInsets#getMandatorySystemGestureInsets(), לצורך פונקציית הניווט, כל עוד מלבן ההחרגה מותר במסגרת מגבלת ההחרגה המקסימלית שצוינה במסמכי התיעוד של View#setSystemGestureExclusionRects().
• ‫[C-6-3] חובה לשלוח לאפליקציה שפועלת בחזית אירוע MotionEvent.ACTION_CANCEL ברגע שהמערכת מתחילה ליירט מגעים לצורך ביצוע תנועה מובנית במערכת, אם לאפליקציה שפועלת בחזית נשלח קודם אירוע MotionEvent.ACTION_DOWN.
• ‫[C-6-4] חובה לספק למשתמש אפשרות לעבור לניווט במסך שמבוסס על לחצנים (לדוגמה, בהגדרות).
• צריך לספק פונקציית מסך בית באמצעות החלקה כלפי מעלה מהקצה התחתון של המסך בכיוון הנוכחי.
• מומלץ לספק פונקציית 'אחרונים' באמצעות החלקה כלפי מעלה והחזקה לפני השחרור, מאותו אזור של תנועת הבית.
• מחוות שמתחילות בתוך WindowInsets#getMandatorySystemGestureInsets() לא אמורות להיות מושפעות ממלבני החרגה שסופקו על ידי האפליקציה שפועלת בחזית באמצעות View#setSystemGestureExclusionRects().

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

• ‫[C-7-1] פונקציית הניווט חייבת להיות 'חזרה' ולהיות זמינה באמצעות החלקה מהקצה השמאלי והימני של המסך, בהתאם לכיוון הנוכחי שלו.
• ‫[C-7-2] אם יש חלוניות מערכת מותאמות אישית שאפשר להחליק כדי לפתוח אותן בקצוות השמאליים או הימניים, הן צריכות להיות ממוקמות בשליש העליון של המסך, עם אינדיקציה חזותית ברורה וקבועה שגרירה פנימה תפתח את החלוניות האלה, ולא תפעיל את לחצן 'הקודם'. משתמש יכול להגדיר את חלונית המערכת כך שהיא תופיע מתחת לשליש העליון של קצה המסך, אבל חלונית המערכת לא יכולה להשתמש ביותר משליש מקצה המסך.
• [C-7-3] אם לאפליקציה שפועלת בחזית מוגדרים הדגלים View.SYSTEM_UI_FLAG_IMMERSIVE או View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, החלקה מהקצוות חייבת להתנהג כמו שהיא מיושמת ב-AOSP, כפי שמתואר ב-SDK.
• [C-7-4] כשהדגלים View.SYSTEM_UI_FLAG_IMMERSIVE או View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY מוגדרים באפליקציה שפועלת בחזית, חלוניות מערכת מותאמות אישית שאפשר להחליק כדי לפתוח אותן חייבות להיות מוסתרות עד שהמשתמש מציג את סרגלי המערכת (שנקראים גם סרגל הניווט וסרגל המצב), כמו שמוטמע ב-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, שמתאימה למכשיר קלט באיכות גבוהה שאינו מבוסס על מגע (מבוסס על מצביע), כמו עכבר או משטח מגע, שיכול לדמות קלט מבוסס-מגע בצורה מספקת (כולל תמיכה במחוות בסיסיות), ומציין שהמכשיר תומך בקבוצת משנה מדומה של פונקציונליות של מסך מגע.

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

• צריך להצהיר על תמיכה ב-feature flag‏ android.hardware.faketouch.

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

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

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

• ‫[C-2-1] חובה להצהיר על תמיכה ב-android.hardware.faketouch.
• ‫[C-2-2] המכשיר חייב לתמוך במעקב נפרד אחרי שני קלטים עצמאיים או יותר של מצביעים.

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

• ‫[C-3-1] חובה להצהיר על תמיכה ב-android.hardware.faketouch.
• ‫[C-3-2] המכשיר חייב לתמוך במעקב נפרד אחרי 5 (מעקב אחרי אצבעות) או יותר קלט של מצביעים באופן עצמאי לחלוטין.

‫7.2.6. תמיכה בשלט משחק

‫7.2.6.1. מיפוי לחצנים

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

• ‫[C-1-1] המכשיר חייב להיות מסוגל למפות אירועי HID לקבועי InputEvent המתאימים, כפי שמפורט בטבלאות שלמטה. ההטמעה של Android ב-upstream עומדת בדרישה הזו.

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

• ‫[C-2-1] חובה להצהיר על ה-feature flag‏ android.hardware.gamepad

‫1 KeyEvent

‫2 השימושים ב-HID שצוינו למעלה חייבים להיות מוצהרים ב-CA של לוח משחקים (0x01 0x0005).

‫3 השימוש הזה חייב לכלול Logical Minimum של 0,‏ Logical Maximum של 7,‏ Physical Minimum של 0,‏ Physical Maximum של 315,‏ Units in Degrees ו-Report Size של 4. הערך הלוגי מוגדר כסיבוב בכיוון השעון הרחק מהציר האנכי. לדוגמה, ערך לוגי של 0 מייצג מצב ללא סיבוב ולחיצה על לחצן החלק העליון, בעוד שערך לוגי של 1 מייצג סיבוב של 45 מעלות ולחיצה על המקשים 'חלק עליון' ו'שמאלה'.

‫4 MotionEvent

‫1 MotionEvent

‫7.2.7. שליטה מרחוק

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

7.3. חיישנים

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

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

• ‫[C-0-1] חובה לדווח בצורה מדויקת על נוכחות או היעדר של חיישנים לפי מחלקת android.content.pm.PackageManager.
• ‫[C-0-2] המכשיר חייב להחזיר רשימה מדויקת של חיישנים נתמכים באמצעות SensorManager.getSensorList() ושיטות דומות.
• ‫[C-0-3] חובה שההתנהגות תהיה סבירה בכל ממשקי ה-API האחרים של החיישנים (לדוגמה, החזרת true או false בהתאם כשיישומים מנסים לרשום מאזינים, לא מתבצעת קריאה למאזיני החיישנים כשהחיישנים התואמים לא קיימים וכו').

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

• ‫[C-1-1] המכשיר חייב לדווח על כל המדידות של החיישנים באמצעות הערכים הרלוונטיים של היחידות הבינלאומיות (מטריות) לכל סוג חיישן, כפי שמוגדר במסמכי ה-Android SDK.
• ‫[C-1-2] חובה לדווח על נתוני חיישנים עם זמן אחזור מקסימלי של 100 מילישניות + 2 * sample_time במקרה של זרם חיישנים עם זמן אחזור מקסימלי של 0 מילישניות כשהמעבד של האפליקציה פעיל. העיכוב הזה לא כולל עיכובים שקשורים לסינון.
• ‫[C-1-3] חובה לדווח על דגימת החיישן הראשונה תוך 400 מילי-שניות + 2 * sample_time מרגע הפעלת החיישן. מקובל שהדיוק של המדגם הזה יהיה 0.
• ‫[C-1-4] לכל API שמסומן במסמכי Android SDK כחיישן רציף, הטמעות במכשירים חייבות לספק באופן רציף דגימות נתונים תקופתיות עם תנודות (jitter) מתחת ל-3%. תנודות מוגדרות כסטיית התקן של ההפרש בין ערכי חותמות הזמן המדווחים בין אירועים עוקבים.
• ‫[C-1-5] חובה לוודא שזרם אירועי החיישן לא ימנע מהמעבד של המכשיר להיכנס למצב השהיה או לצאת ממצב השהיה.
• ‫[C-1-6] חובה לדווח על זמן האירוע בננו-שניות, כפי שמוגדר במסמכי התיעוד של Android SDK, שמייצג את הזמן שבו האירוע קרה וסונכרן עם השעון SystemClock.elapsedRealtimeNano().
• [C-SR] מומלץ מאוד ששגיאת הסנכרון של חותמות הזמן תהיה מתחת ל-100 אלפיות השנייה, ורצוי ששגיאת הסנכרון של חותמות הזמן תהיה מתחת לאלפית השנייה.
• כשכמה חיישנים מופעלים, צריכת החשמל לא צריכה להיות גבוהה מסכום צריכת החשמל המדווחת של כל חיישן בנפרד.

הרשימה שלמעלה לא מלאה. ההתנהגות המתועדת של Android SDK והתיעוד של Android Open Source בנושא חיישנים נחשבים למקור מהימן.

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

• ‫[C-1-6] חובה להגדיר רזולוציה שאינה אפס לכל החיישנים, ולדווח על הערך באמצעות שיטת ה-API‏ Sensor.getResolution().

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

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

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

אם יישומי המכשיר כוללים חיישן מורכב, הם:

• ‫[C-2-1] חובה להטמיע את החיישן כפי שמתואר במסמכי התיעוד של Android Open Source בנושא חיישנים מורכבים.

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

• ‫[C-3-1] החיישן חייב להגדיר את הרזולוציה ל-1 ולדווח על הערך באמצעות השיטה Sensor.getResolution() של ה-API.

אם הטמעות המכשיר כוללות סוג מסוים של חיישן שתומך ב-SensorAdditionalInfo#TYPE_VEC3_CALIBRATION והחיישן חשוף למפתחי צד שלישי, הם:

• ‫[C-4-1] אסור לכלול בנתונים שסופקו פרמטרים קבועים של כיול שנקבעו במפעל.

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

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

‫7.3.1. מד תאוצה

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

• ‫[C-SR] מומלץ מאוד לכלול מד תאוצה ב-3 צירים.

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

• ‫[C-1-1] המכשיר חייב להיות מסוגל לדווח על אירועים בתדירות של 50 הרץ לפחות.
• ‫[C-1-2] חובה להטמיע ולדווח על חיישן TYPE_ACCELEROMETER.
• ‫[C-1-3] חובה לעמוד בדרישות של מערכת הקואורדינטות של חיישן Android, כפי שמפורט בממשקי ה-API של Android.
• ‫[C-1-4] המכשיר חייב להיות מסוגל למדוד נפילה חופשית עד פי ארבעה מכוח המשיכה(4g) או יותר בכל ציר.
• ‫[C-1-5] הרזולוציה חייבת להיות לפחות 12 ביט.
• ‫[C-1-6] סטיית התקן לא יכולה להיות גדולה מ-0.05 m/s^‎, וצריך לחשב אותה על בסיס כל ציר בנפרד על דגימות שנאספו במשך תקופה של לפחות 3 שניות בקצב הדגימה המהיר ביותר.
• מומלץ מאוד להטמיע את TYPE_SIGNIFICANT_MOTION חיישן המורכב.
• מומלץ מאוד [SR] להטמיע ולדווח על חיישן TYPE_ACCELEROMETER_UNCALIBRATED. מומלץ מאוד שמכשירי Android יעמדו בדרישה הזו, כדי שיהיה אפשר לשדרג אותם לגרסת הפלטפורמה העתידית שבה הדרישה הזו עשויה להיות חובה.
• מומלץ להטמיע את חיישני TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER המורכבים כפי שמתואר במסמך Android SDK.
• צריך לדווח על אירועים בתדירות של 200 הרץ לפחות.
• מומלץ שהרזולוציה תהיה לפחות 16 ביט.
• צריך לבצע כיול בזמן השימוש אם המאפיינים משתנים במהלך מחזור החיים, ולבצע פיצוי, ולשמור את פרמטרי הפיצוי בין הפעלות מחדש של המכשיר.
• צריך להיות עם פיצוי טמפרטורה.

אם הטמעות המכשיר כוללות מד תאוצה ב-3 צירים ואחד מהחיישנים המורכבים TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER מוטמע:

• ‫[C-2-1] סכום צריכת החשמל שלהם חייב להיות תמיד פחות מ-4mW.
• כל אחד מהם צריך להיות מתחת ל-2mW ו-0.5mW כשהמכשיר במצב דינמי או סטטי.

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

• ‫[C-3-1] המכשיר חייב להטמיע את החיישנים המורכבים TYPE_GRAVITY ו-TYPE_LINEAR_ACCELERATION.
• ‫[C-SR] מומלץ מאוד להטמיע את חיישן TYPE_GAME_ROTATION_VECTOR המורכב.

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

• ‫[C-4-1] חובה להטמיע חיישן מורכב TYPE_ROTATION_VECTOR.

‫7.3.2. מגנטומטר

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

• ‫[C-SR] מומלץ מאוד לכלול מגנטומטר (מצפן) עם 3 צירים.

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

• ‫[C-1-1] חובה להטמיע את החיישן TYPE_MAGNETIC_FIELD.
• ‫[C-1-2] המכשיר חייב להיות מסוגל לדווח על אירועים בתדירות של 10 הרץ לפחות, ומומלץ לדווח על אירועים בתדירות של 50 הרץ לפחות.
• ‫[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-SR] מומלץ מאוד להטמיע חיישן TYPE_MAGNETIC_FIELD_UNCALIBRATED.

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

• ‫[C-2-1] חובה להטמיע TYPE_ROTATION_VECTOR חיישן מורכב.

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

• יכול להיות שיוטמע חיישן TYPE_GEOMAGNETIC_ROTATION_VECTOR.

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

• ‫[C-3-1] צריכת ההספק חייבת להיות פחות מ-10mW.
• החיישן צריך לצרוך פחות מ-3mW כשהוא רשום למצב אצווה בתדר של 10Hz.

‫7.3.3. GPS

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

• ‫[C-SR] מומלץ מאוד לכלול מקלט GPS/GNSS.

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

• ‫[C-1-1] המכשיר חייב לתמוך בפלט של מיקום בקצב של לפחות 1 הרץ כשמבקשים זאת באמצעות LocationManager#requestLocationUpdate.
• ‫[C-1-2] המכשיר חייב להיות מסוגל לקבוע את המיקום בתנאים של שמיים פתוחים (אותות חזקים, ריבוי נתיבים זניח, HDOP < 2) תוך 10 שניות (זמן מהיר עד לתיקון הראשון), כשהוא מחובר לחיבור אינטרנט עם מהירות נתונים של 0.5Mbps או יותר. הדרישה הזו מתקיימת בדרך כלל באמצעות שימוש בטכניקה כלשהי של GPS/GNSS מסוג Assisted או Predicted, כדי לצמצם את זמן הנעילה של GPS/GNSS (נתוני הסיוע כוללים זמן ייחוס, מיקום ייחוס ונתוני אפמריס/שעון של לוויין).
  • ‫[C-1-6] אחרי ביצוע חישוב מיקום כזה, הטמעות של מכשירים חייבות לקבוע את המיקום שלהם, בשטח פתוח, תוך 5 שניות, כשבקשות המיקום מופעלות מחדש, עד שעה אחרי חישוב המיקום הראשוני, גם אם הבקשה הבאה מבוצעת ללא חיבור נתונים, ו/או אחרי הפעלה מחדש.

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

  • ‫[C-1-3] המכשיר חייב להיות מסוגל לקבוע את המיקום בטווח של 20 מטרים, ואת המהירות בטווח של 0.5 מטרים לשנייה, לפחות ב-95% מהזמן.
  • ‫[C-1-4] חובה לעקוב אחרי לפחות 8 לוויינים מקבוצה אחת ולדווח עליהם בו-זמנית באמצעות GnssStatus.Callback.
  • צריך להיות מסוגל לעקוב בו-זמנית אחרי לפחות 24 לוויינים מכמה קבוצות כוכבים (למשל GPS + לפחות אחת מהמערכות Glonass,‏ Beidou,‏ Galileo).
  • [C-SR] מומלץ מאוד להמשיך לספק פלט מיקום רגיל של GPS/GNSS באמצעות ממשקי API של ספקי מיקום GNSS במהלך שיחת טלפון לשירותי חירום.
  • ‫[C-SR] מומלץ מאוד לדווח על מדידות GNSS מכל מערכות הניווט שנמצאות במעקב (כפי שמדווח בהודעות GnssStatus), למעט SBAS.
  • ‫[C-SR] מומלץ מאוד לדווח על AGC ותדירות המדידה של GNSS.
  • [C-SR] מומלץ מאוד לדווח על כל הערכות הדיוק (כולל כיוון, מהירות וגובה) כחלק מכל מיקום GPS/GNSS.
  • [C-SR] מומלץ מאוד לדווח על מדידות GNSS, ברגע שהן נמצאות, גם אם מיקום שמחושב מ-GPS/GNSS עדיין לא דווח.
  • ‫[C-SR] מומלץ מאוד לדווח על טווחי פסאודו ושיעורי טווחי פסאודו של GNSS, שבתנאי שמיים פתוחים אחרי קביעת המיקום, במצב נייח או בתנועה עם תאוצה של פחות מ-0.2 מטר לשנייה בריבוע, מספיקים לחישוב המיקום בטווח של 20 מטרים והמהירות בטווח של 0.2 מטר לשנייה, לפחות ב-95% מהזמן.

‫7.3.4. ג'ירוסקופ

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

• ‫[C-SR] מומלץ מאוד לכלול חיישן ג'ירוסקופ.

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

• ‫[C-1-1] המכשיר חייב להיות מסוגל לדווח על אירועים בתדירות של 50 הרץ לפחות.
• ‫[C-1-2] חובה להטמיע את חיישן TYPE_GYROSCOPE ומומלץ מאוד להטמיע גם את חיישן TYPE_GYROSCOPE_UNCALIBRATED.
• ‫[C-1-4] הרזולוציה חייבת להיות 12 ביט ומעלה, ומומלץ שתהיה 16 ביט ומעלה.
• ‫[C-1-5] חייב להיות עם מדידת פיצוי טמפרטורה.
• ‫[C-1-6] חייב להיות מכויל ומפוצה בזמן השימוש, ולשמור על פרמטרי הפיצוי בין הפעלות מחדש של המכשיר.
• ‫[C-1-7] השונות לא יכולה להיות גדולה מ-‎1e-7 rad^2 / s^2 per Hz (שונות לכל הרץ, או rad^2 / s). השונות יכולה להשתנות בהתאם לקצב הדגימה, אבל היא חייבת להיות מוגבלת על ידי הערך הזה. במילים אחרות, אם מודדים את השונות של הג'ירוסקופ בקצב דגימה של 1 הרץ, היא לא צריכה להיות גדולה מ-‎1e-7 rad^2/s^2.
• [SR] מומלץ מאוד ששגיאת הכיול תהיה קטנה מ-0.01 רדיאן/שנייה כשהמכשיר נייח בטמפרטורת החדר.
• צריך לדווח על אירועים בתדירות של 200 הרץ לפחות.

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

• ‫[C-2-1] חובה להטמיע TYPE_ROTATION_VECTOR חיישן מורכב.

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

• ‫[C-3-1] המכשיר חייב להטמיע את החיישנים המורכבים TYPE_GRAVITY ו-TYPE_LINEAR_ACCELERATION.
• ‫[C-SR] מומלץ מאוד להטמיע את חיישן TYPE_GAME_ROTATION_VECTOR המורכב.

‫7.3.5. ברומטר

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

• ‫[C-SR] מומלץ מאוד לכלול ברומטר (חיישן לחץ אוויר סביבתי).

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

• ‫[C-1-1] חובה להטמיע את חיישן TYPE_PRESSURE ולדווח עליו.
• ‫[C-1-2] המכשיר חייב להיות מסוגל להעביר אירועים בתדר של 5 הרץ או יותר.
• ‫[C-1-3] חייב להיות עם פיצוי טמפרטורה.
• ‫[SR] מומלץ מאוד כדי לאפשר דיווח על מדידות לחץ בטווח של 300hPa עד 1,100hPa.
• צריכה להיות לו רמת דיוק מוחלטת של 1hPa.
• צריך להיות בעל דיוק יחסי של 0.12hPa בטווח של 20hPa (שווה לדיוק של ‎~1m בשינוי של ‎~200m בגובה פני הים).

‫7.3.6. מדחום

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

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

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

• ‫[C-2-1] אסור להגדיר SENSOR_TYPE_AMBIENT_TEMPERATURE לחיישן הטמפרטורה.

‫7.3.7. פוטומטר

• יכול להיות שהטמעות של מכשירים יכללו פוטומטר (חיישן אור רגיש לסביבה).

‫7.3.8. חיישן קירבה

• יכול להיות שהטמעות של מכשירים יכללו חיישן קירבה.

אם יישומי המכשיר כוללים חיישן קירבה, הם:

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

‫7.3.9. חיישנים באיכות גבוהה

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

• ‫[C-1-1] חובה לזהות את היכולת באמצעות ה-feature flag‏ android.hardware.sensor.hifi_sensors.

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

• ‫[C-2-1] חובה לכלול חיישן TYPE_ACCELEROMETER ש:

  • חייב להיות לו טווח מדידה של לפחות ‎-8g עד ‎+8g, ומומלץ מאוד שיהיה לו טווח מדידה של לפחות ‎-16g עד ‎+16g.
  • חייבת להיות רזולוציית מדידה של לפחות 2048 LSB/g.
  • חייב להיות בעל תדירות מדידה מינימלית של 12.5 הרץ או פחות.
  • חייבת להיות תמיכה בתדירות מדידה מקסימלית של 400 הרץ ומעלה; מומלץ לתמוך ב-SensorDirectChannel RATE_VERY_FAST.
  • רעש המדידה לא יכול להיות מעל 400 מיקרוגרם חלקי שורש הרץ.
  • חובה להטמיע חיישן כזה שלא מעיר את המכשיר, עם יכולת שמירת נתונים זמנית של לפחות 3,000 אירועים של החיישן.
  • צריכת החשמל של העיבוד באצווה לא יכולה להיות גבוהה מ-3mW.
  • [C-SR] מומלץ מאוד שרוחב הפס של המדידה יהיה לפחות 80% מתדירות נייקוויסט, וספקטרום הרעש הלבן יהיה בתוך רוחב הפס הזה.
  • צריך להיות בעל תאוצה אקראית של פחות מ-30 מיקרוגרם √Hz שנבדקה בטמפרטורת החדר.
  • צריך להיות שינוי הטיה לעומת טמפרטורה של ‎≤ +/- 1 mg/°C.
  • צריך לכלול קו התאמה אופטימלי עם אי-ליניאריות של ‎≤ 0.5% ושינוי רגישות לעומת טמפרטורה של ‎≤ 0.03%/C°.
  • רצוי שתהיה רגישות בין-צירית של פחות מ-2.5 % ושונות ברגישות בין-צירית של פחות מ-0.2% בטווח טמפרטורת ההפעלה של המכשיר.

• ‫[C-2-2] חובה לכלול TYPE_ACCELEROMETER_UNCALIBRATED עם אותן דרישות איכות כמו TYPE_ACCELEROMETER.

• ‫[C-2-3] חובה לכלול חיישן TYPE_GYROSCOPE ש:

  • חייב להיות לו טווח מדידה של לפחות ‎-1,000 עד ‎+1,000 dps.
  • חייבת להיות רזולוציית מדידה של לפחות 16 LSB/dps.
  • חייב להיות בעל תדירות מדידה מינימלית של 12.5 הרץ או פחות.
  • חייבת להיות תמיכה בתדירות מדידה מקסימלית של 400 הרץ ומעלה; מומלץ לתמוך ב-SensorDirectChannel RATE_VERY_FAST.
  • חייב להיות בעל רעש מדידה שלא עולה על ‎0.014°/s/√Hz.
  • [C-SR] מומלץ מאוד שרוחב הפס של המדידה יהיה לפחות 80% מתדירות נייקוויסט, וספקטרום הרעש הלבן יהיה בתוך רוחב הפס הזה.
  • מומלץ ששיעור ההליכה האקראית יהיה פחות מ-0.001 °/s √Hz שנבדק בטמפרטורת החדר.
  • צריך להיות שינוי בהטיה לעומת הטמפרטורה של ‎≤ +/- 0.05 °/ s / °C.
  • רמת הרגישות צריכה להשתנות בהתאם לטמפרטורה בשיעור של ‎≤ 0.02% / °C.
  • צריך לכלול קו בעל ההתאמה הטובה ביותר עם אי-ליניאריות של ‎≤ 0.2%‎.
  • צפיפות הרעש צריכה להיות ≤ 0.007 °/s/√Hz.
  • צריכה להיות שגיאת כיול של פחות מ-0.002 רדיאן/שנייה בטווח הטמפרטורות 10 עד 40 מעלות צלזיוס כשהמכשיר נייח.
  • מומלץ שהרגישות ל-g תהיה נמוכה מ-0.1°‎/s/g.
  • רמת הרגישות לציר הניצב צריכה להיות < 4.0 % והשונות ברמת הרגישות לציר הניצב צריכה להיות < 0.3% בטווח טמפרטורות הפעולה של המכשיר.

• ‫[C-2-4] חובה להשתמש ב-TYPE_GYROSCOPE_UNCALIBRATED עם אותן דרישות איכות כמו TYPE_GYROSCOPE.

• ‫[C-2-5] חובה לכלול חיישן TYPE_GEOMAGNETIC_FIELD ש:

  • חייב להיות בעל טווח מדידה של לפחות ‎-900 עד ‎+900 מיקרוטסלה (μT).
  • חייבת להיות רזולוציית מדידה של לפחות 5 LSB/uT.
  • חייב להיות בעל תדירות מדידה מינימלית של 5 הרץ או פחות.
  • חייב להיות בעל תדירות מדידה מקסימלית של 50 הרץ ומעלה.
  • חייב להיות בעל רעשי מדידה שלא עולים על 0.5 מיקרוטסלה.

• ‫[C-2-6] חובה להשתמש ב-TYPE_MAGNETIC_FIELD_UNCALIBRATED שעומד באותן דרישות איכות כמו TYPE_GEOMAGNETIC_FIELD, ובנוסף:

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

• ‫[C-2-7] חייב להיות חיישן TYPE_PRESSURE ש:

  • חייב להיות לו טווח מדידה של לפחות 300 עד 1,100 hPa.
  • חייבת להיות רזולוציית מדידה של לפחות 80 LSB/hPa.
  • חייבת להיות תדירות מדידה מינימלית של 1 הרץ או פחות.
  • חייב להיות בעל תדירות מדידה מקסימלית של 10 הרץ ומעלה.
  • חייב להיות רעש מדידה שלא עולה על ‎2 Pa/√Hz.
  • חובה להטמיע חיישן כזה שלא מעיר את המכשיר, עם יכולת אחסון זמני של לפחות 300 אירועים של החיישן.
  • צריכת החשמל של העיבוד באצווה לא יכולה להיות גבוהה מ-2mW.
• ‫[C-2-8] חובה לכלול חיישן TYPE_GAME_ROTATION_VECTOR.
• ‫[C-2-9] חובה לכלול חיישן TYPE_SIGNIFICANT_MOTION ש:
  • צריכת האנרגיה לא יכולה להיות גבוהה מ-0.5mW כשהמכשיר נייח, ומ-1.5mW כשהמכשיר בתנועה.
• ‫[C-2-10] חובה לכלול חיישן TYPE_STEP_DETECTOR ש:
  • חובה להטמיע חיישן כזה שלא מפעיל את המכשיר, עם יכולת אגירה של לפחות 100 אירועים של החיישן.
  • צריכת האנרגיה לא יכולה להיות גבוהה מ-0.5mW כשהמכשיר נייח, ומ-1.5mW כשהמכשיר בתנועה.
  • צריכת החשמל של העיבוד באצווה לא יכולה להיות גבוהה מ-4mW.
• ‫[C-2-11] חובה לכלול חיישן TYPE_STEP_COUNTER ש:
  • צריכת האנרגיה לא יכולה להיות גבוהה מ-0.5mW כשהמכשיר נייח, ומ-1.5mW כשהמכשיר בתנועה.
• ‫[C-2-12] חובה לכלול חיישן TILT_DETECTOR ש:
  • צריכת האנרגיה לא יכולה להיות גבוהה מ-0.5mW כשהמכשיר נייח, ומ-1.5mW כשהמכשיר בתנועה.
• ‫[C-2-13] חותמת הזמן של האירוע הפיזי זהה לזו שדווחה על ידי מד התאוצה, הג'ירוסקופ והמגנטומטר, וההפרש ביניהן לא יכול להיות גדול מ-2.5 אלפיות השנייה. חותמת הזמן של האירוע הפיזי הזהה שדווח על ידי מד התאוצה והג'ירוסקופ צריכה להיות בהפרש של עד 0.25 אלפיות השנייה בין אחת לשנייה.
• ‫[C-2-14] חותמות הזמן של אירועי חיישן הג'ירוסקופ חייבות להיות באותו בסיס זמן כמו מערכת המשנה של המצלמה, עם שגיאה של עד אלפית השנייה.
• ‫[C-2-15] חובה לספק דגימות לאפליקציות תוך 5 אלפיות השנייה מהרגע שבו הנתונים זמינים באחד מהחיישנים הפיזיים שלמעלה לאפליקציה.
• ‫[C-2-16] צריכת החשמל לא יכולה להיות גבוהה מ-0.5 מיליוואט כשהמכשיר נייח ומ-2.0 מיליוואט כשהמכשיר בתנועה, כשמופעל שילוב כלשהו של החיישנים הבאים:
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS
• ‫[C-2-17] יכול להיות שיהיה מכשיר TYPE_PROXIMITY עם חיישן, אבל אם יש חיישן, הוא חייב לכלול מאגר נתונים זמני עם קיבולת מינימלית של 100 אירועים של חיישן.

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

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

• ‫[C-3-1] חובה להצהיר בצורה נכונה על תמיכה בסוגים של ערוצים ישירים וברמות של שיעורי דיווח ישירים באמצעות API‏ isDirectChannelTypeSupported ו-API‏ getHighestDirectReportRateLevel.
• ‫[C-3-2] חובה לתמוך לפחות באחד משני סוגי הערוצים הישירים של החיישנים עבור כל החיישנים שמצהירים על תמיכה בערוץ ישיר של חיישן.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• חובה לתמוך בדיווח על אירועים דרך ערוץ ישיר של חיישן עבור חיישן ראשי (גרסה ללא הפעלה) מהסוגים הבאים:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

‫7.3.10. חיישנים ביומטריים

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

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

• מומלץ לכלול חיישן ביומטרי

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

אם הטמעות המכשיר מאפשרות לאפליקציות של צד שלישי לגשת לחיישן ביומטרי באמצעות android.hardware.biometrics.BiometricManager,‏ android.hardware.biometrics.BiometricPrompt ו-android.provider.Settings.ACTION_BIOMETRIC_ENROLL, הן:

• ‫[C-4-1] המכשיר חייב לעמוד בדרישות לנתונים ביומטריים ברמה 3 או ברמה 2, כפי שמוגדר במסמך הזה.
• ‫[C-4-2] המערכת חייבת לזהות ולכבד כל שם פרמטר שהוגדר כקבוע במחלקה Authenticators וכל שילוב שלהם. לעומת זאת, אסור לכבד או לזהות קבועים מסוג integer שמועברים לשיטות canAuthenticate(int) ו-setAllowedAuthenticators(int), מלבד אלה שמתועדים כקבועים ציבוריים ב-Authenticators וכל שילוב שלהם.
• ‫[C-4-3] חובה להטמיע את הפעולה ACTION_BIOMETRIC_ENROLL במכשירים שיש בהם נתונים ביומטריים מסוג Class 3 או Class 2. הפעולה הזו חייבת להציג רק את נקודות הכניסה להרשמה לנתונים ביומטריים מסוג רמה 3 או רמה 2.

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

• ‫[C-5-1] כברירת מחדל, צריך לדרוש שלב אישור נוסף (למשל, לחיצה על לחצן).
• [C-SR] מומלץ מאוד להגדיר אפשרות שתאפשר למשתמשים לבטל את ההעדפות של האפליקציה ולדרוש תמיד שלב אימות נלווה.
• [C-SR] מומלץ מאוד לאבטח את פעולת האישור כך שפריצה למערכת ההפעלה או לליבה לא תוכל לזייף אותה. לדוגמה, המשמעות היא שפעולת האישור שמבוססת על לחצן פיזי מנותבת דרך פין קלט/פלט (GPIO) למטרה כללית שמוגדר כקלט בלבד של רכיב מאובטח (SE), שלא ניתן להפעיל אותו בשום דרך אחרת מלבד לחיצה על לחצן פיזי.
• ‫[C-5-2] בנוסף, חובה להטמיע תהליך אימות משתמע (ללא שלב אישור) שמתאים ל-setConfirmationRequired(boolean), שאפליקציות יכולות להגדיר לשימוש בתהליכי כניסה.

אם במכשירים יש כמה חיישנים ביומטריים, הם:

• [C-SR] מומלץ מאוד לדרוש אישור של נתון ביומטרי אחד בלבד לכל אימות (לדוגמה, אם במכשיר יש חיישנים של טביעת אצבע ושל פנים, צריך לשלוח את onAuthenticationSucceeded אחרי אישור של אחד מהם).

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

• ‫[C-6-1] חובה לעמוד בדרישות של סיווג 3 כפי שמוגדר בקטע הבא.
• ‫[C-6-2] המכשיר חייב להציג רק נתונים ביומטריים ברמה 3 כשנדרש אימות מסוג BIOMETRIC_STRONG, או כשהאימות מופעל באמצעות CryptoObject.

אם רוצים להגדיר חיישן ביומטרי כסוג 1 (לשעבר נוחות) בהטמעות של מכשירים, צריך:

• ‫[C-1-1] שיעור הקבלה השגוי (FAR) חייב להיות נמוך מ-0.002%.
• ‫[C-1-2] חובה לציין שהמצב הזה עשוי להיות פחות מאובטח מקוד אימות, מקו ביטול נעילה או מסיסמה חזקים, ולפרט באופן ברור את הסיכונים בהפעלת המצב הזה, אם שיעורי הקבלה של זיוף והתחזות גבוהים מ-7% כפי שנמדד על ידי פרוטוקולי הבדיקה של נתונים ביומטריים ב-Android.
• ‫[C-1-3] חובה להגביל את קצב הניסיונות למשך 30 שניות לפחות אחרי חמישה ניסיונות כוזבים לאימות ביומטרי – ניסיון כוזב הוא ניסיון עם איכות לכידה מספקת (BIOMETRIC_ACQUIRED_GOOD) שלא תואמת לנתונים ביומטריים רשומים.
• ‫[C-1-4] חובה למנוע הוספה של נתונים ביומטריים חדשים בלי ליצור קודם שרשרת של אמון, על ידי כך שהמשתמש יאשר פרטי כניסה קיימים או יוסיף פרטי כניסה חדשים למכשיר (קוד אימות, תבנית או סיסמה) שמאובטחים על ידי TEE. ההטמעה של פרויקט קוד פתוח של Android מספקת את המנגנון במסגרת הפעולה כדי לעשות זאת.
• ‫[C-1-5] חובה להסיר באופן מלא את כל הנתונים הביומטריים שניתן לזהות של משתמש כשמסירים את החשבון שלו (כולל באמצעות איפוס להגדרות המקוריות).
• ‫[C-1-6] חובה לכבד את הדגל האישי של אותו נתון ביומטרי (כלומר DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT,‏ DevicePolicymanager.KEYGUARD_DISABLE_FACE או DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
• ‫[C-1-7] המכשיר חייב לדרוש מהמשתמש אימות ראשי מומלץ (למשל קוד אימות, קו ביטול נעילה או סיסמה) פעם ב-24 שעות או פחות במכשירים חדשים עם Android מגרסה 10, ופעם ב-72 שעות או פחות במכשירים שמשדרגים מגרסה קודמת של Android.

• ‫[C-1-8] המערכת חייבת לבקש מהמשתמש לבצע את האימות הראשי המומלץ (למשל: קוד אימות, תבנית, סיסמה) אחרי אחד מהמקרים הבאים:

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

  אפשר לקבל פטור מהדרישה C-1-8 לגבי שדרוג מכשירים מגרסת Android קודמת. ‫* [C-SR] מומלץ מאוד להשתמש בלוגיקה ב-framework שסופק על ידי פרויקט הקוד הפתוח של Android כדי לאכוף את האילוצים שצוינו ב-[C-1-7] וב-[C-1-8] במכשירים חדשים. ‫* [C-SR] מומלץ מאוד ששיעור הדחייה השגוי יהיה נמוך מ-10%, כפי שנמדד במכשיר. ‫* [C-SR] מומלץ מאוד שזמן האחזור יהיה מתחת לשנייה אחת, מהרגע שבו מזוהה נתון ביומטרי ועד שהמסך נפתח, לכל נתון ביומטרי רשום.

אם רוצים להגדיר חיישן ביומטרי במכשיר כרמה 2 (לשעבר חלש), צריך:

• ‫[C-2-1] חובה לעמוד בכל הדרישות של סיווג 1 שפורטו למעלה.
• ‫[C-2-2] שיעור הקבלה של זיוף והתחזות לא יעלה על 20% כפי שנמדד על ידי פרוטוקולי הבדיקה של אמצעי הזיהוי הביומטרי ב-Android.
• ‫[C-2-3] חובה לבצע את ההתאמה הביומטרית בסביבת ביצוע מבודדת מחוץ למרחב המשתמש או לליבת המערכת של Android, כמו סביבת מחשוב אמינה (TEE), או על שבב עם ערוץ מאובטח לסביבת הביצוע המבודדת.
• ‫[C-2-4] כל הנתונים המזהים חייבים להיות מוצפנים ומאומתים באופן קריפטוגרפי, כך שלא ניתן יהיה להשיג, לקרוא או לשנות אותם מחוץ לסביבת הביצוע המבודדת או מחוץ לשבב עם ערוץ מאובטח לסביבת הביצוע המבודדת, כפי שמתואר בהנחיות ההטמעה באתר של פרויקט הקוד הפתוח של Android.
• ‫[C-2-5] במקרה של נתונים ביומטריים שמבוססים על מצלמה, בזמן שמתבצע אימות או רישום שמבוססים על נתונים ביומטריים:
  • המצלמה חייבת לפעול במצב שמונע קריאה או שינוי של פריימים של המצלמה מחוץ לסביבת הביצוע המבודדת או מחוץ לשבב עם ערוץ מאובטח לסביבת הביצוע המבודדת.
  • בפתרונות RGB עם מצלמה אחת, אפשר לקרוא את פריימים של המצלמה מחוץ לסביבת הביצוע המבודדת כדי לתמוך בפעולות כמו תצוגה מקדימה להרשמה, אבל אסור לשנות אותם.
• ‫[C-2-6] אסור לאפשר לאפליקציות של צד שלישי להבחין בין רישומים ביומטריים של משתמשים שונים.
• ‫[C-2-7] אסור לאפשר גישה לא מוצפנת לנתונים ביומטריים שניתן לזהות מהם את המשתמש או לנתונים שנגזרים מהם (כמו הטמעות) למעבד האפליקציות מחוץ להקשר של TEE.

• ‫[C-2-8] חובה להשתמש בצינור עיבוד מאובטח, כך שפריצה למערכת הפעלה או לליבת מערכת לא תאפשר להחדיר נתונים ישירות כדי ליצור אימות כוזב בתור המשתמש.

  אם הטמעות המכשירים כבר הושקו בגרסה קודמת של Android ולא עומדות בדרישה C-2-8 באמצעות עדכון תוכנת מערכת, יכול להיות שהן יהיו פטורות מהדרישה.

• [C-SR] מומלץ מאוד לכלול זיהוי של נוכחות אדם חי בכל שיטות הזיהוי הביומטרי, וזיהוי של תשומת לב בשיטות ביומטריות של הפנים.

אם רוצים להגדיר חיישן ביומטרי במכשיר כרמה 3 (לשעבר חזק), צריך:

• ‫[C-3-1] חייב לעמוד בכל הדרישות של Class 2 שפורטו למעלה, למעט [C-1-7] ו- [C-1-8]. שדרוג מכשירים מגרסת Android קודמת לא פוטר אתכם מדרישה C-2-7.
• ‫[C-3-2] חובה להטמיע חנות מפתחות עם גיבוי חומרה.
• ‫[C-3-3] קצב הקבלה של זיוף ומתחזה לא יכול להיות גבוה מ-7% כפי שנמדד על ידי פרוטוקולי הבדיקה של אמצעי הזיהוי הביומטריים ב-Android.
• ‫[C-3-4] חובה להציג למשתמש אתגר לאימות ראשי מומלץ (למשל, קוד אימות, קו ביטול נעילה, סיסמה) פעם ב-72 שעות או פחות.

‫7.3.12. חיישן תנוחה

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

• יכול להיות שיש תמיכה בחיישן תנוחה עם 6 דרגות חופש.

אם הטמעות המכשירים תומכות בחיישן תנוחה עם 6 דרגות חופש, הן:

• ‫[C-1-1] חובה להטמיע את החיישן TYPE_POSE_6DOF ולדווח עליו.
• ‫[C-1-2] חייב להיות מדויק יותר מווקטור הסיבוב בלבד.

‫7.3.13. חיישן זווית הציר

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

• ‫[C-1-1] חובה להטמיע ולדווח על TYPE_HINGLE_ANGLE.
• ‫[C-1-2] המכשיר חייב לתמוך בלפחות שני קריאות בין 0 ל-360 מעלות (כולל, כלומר כולל 0 ו-360 מעלות).
• ‫[C-1-3] חובה להחזיר חיישן הפעלה ממצב שינה עבור getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

‫7.4. קישוריות נתונים

‫7.4.1. טלפוניה

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

• יכול להיות שיהיה אפשר להשתמש ב-Android במכשירים שלא כוללים חומרה לטלפוניה. כלומר, Android תואמת למכשירים שהם לא טלפונים.

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

• ‫[C-1-1] חובה להצהיר על feature flag‏ android.hardware.telephony ועל feature flags אחרים של תכונות משנה בהתאם לטכנולוגיה.
• ‫[C-1-2] חובה להטמיע תמיכה מלאה ב-API של הטכנולוגיה הזו.

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

• ‫[C-2-1] חובה להטמיע את כל ממשקי ה-API כפעולות שלא עושות כלום (no-ops).

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

• ‫[C-3-1] חובה לספק הטמעה מלאה של EuiccManager API.

‫7.4.1.1. תאימות לחסימת מספרים

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

• ‫[C-1-1] חובה לכלול תמיכה בחסימת מספרים
• ‫[C-1-2] חובה להטמיע באופן מלא את BlockedNumberContract ואת ה-API המתאים, כפי שמתואר בתיעוד של ה-SDK.
• ‫[C-1-3] המכשיר חייב לחסום את כל השיחות וההודעות ממספר טלפון ב-BlockedNumberProvider ללא אינטראקציה עם אפליקציות. היוצא מן הכלל היחיד הוא כשביטול חסימת המספרים מבוטל באופן זמני, כפי שמתואר במסמכי ה-SDK.
• ‫[C-1-4] אסור לכתוב לספק יומן השיחות של הפלטפורמה לגבי שיחה חסומה.
• ‫[C-1-5] אסור לכתוב אל ספק הטלפוניה לגבי הודעה חסומה.
• ‫[C-1-6] חובה להטמיע ממשק משתמש לניהול מספרים חסומים, שנפתח באמצעות ה-intent שמוחזר על ידי ה-method‏ TelecomManager.createManageBlockedNumbersIntent().
• ‫[C-1-7] אסור לאפשר למשתמשים משניים להציג או לערוך את המספרים החסומים במכשיר, כי פלטפורמת Android מניחה שלמשתמש הראשי יש שליטה מלאה בשירותי הטלפוניה, מופע יחיד, במכשיר. כל ממשק המשתמש שקשור לחסימה חייב להיות מוסתר ממשתמשים משניים, ועדיין צריך להתייחס לרשימת החסימה.
• צריך להעביר את המספרים החסומים לספק כשהמכשיר מתעדכן ל-Android 7.0.

‫7.4.1.2. Telecom API

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

• ‫[C-1-1] חובה לתמוך בממשקי ה-API‏ ConnectionService שמתוארים ב-SDK.
• ‫[C-1-2] חובה להציג שיחה נכנסת חדשה ולספק למשתמש אפשרות לקבל או לדחות את השיחה הנכנסת, אם המשתמש נמצא בשיחה פעילה שמתבצעת דרך אפליקציית צד שלישי שלא תומכת בתכונת ההמתנה שצוינה באמצעות CAPABILITY_SUPPORT_HOLD.
• ‫[C-1-3] חובה להשתמש באפליקציה שמטמיעה את InCallService.

• [C-SR] מומלץ מאוד להודיע למשתמש שמענה לשיחה נכנסת יגרום לניתוק של שיחה פעילה.

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

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

• ‫[C-SR] מומלץ מאוד לטפל באירועים KEYCODE_MEDIA_PLAY_PAUSE ו-KEYCODE_HEADSETHOOK של אוזניות עם מיקרופון עבור ממשקי ה-API של android.telecom באופן הבא:
  • הפעלת Connection.onDisconnect() כשמזוהה לחיצה קצרה על אירוע המקש במהלך שיחה פעילה.
  • הפונקציה Call Connection.onAnswer() מופעלת כשמזוהה לחיצה קצרה על אירוע המקש במהלך שיחה נכנסת.
  • הפונקציה Call Connection.onReject() מופעלת כשמזוהה לחיצה ארוכה על אירוע המקש במהלך שיחה נכנסת.
  • השתקה או ביטול השתקה של CallAudioState.

‫7.4.2. IEEE 802.11 (Wi-Fi)

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

• צריך לכלול תמיכה בצורה אחת או יותר של 802.11.

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

• ‫[C-1-1] חובה להטמיע את ממשק ה-API התואם ל-Android.
• ‫[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] אסור להתייחס להפעלת method של ה-API‏ WifiManager.enableNetwork() כאל אינדיקציה מספקת להחלפת Network שמוגדר כפעיל כרגע ומשמש כברירת מחדל לתעבורת נתונים של אפליקציות, ומוחזר על ידי שיטות API‏ ConnectivityManager כמו getActiveNetwork ו-registerDefaultNetworkCallback. במילים אחרות, הם יכולים להשבית את הגישה לאינטרנט שסופקה על ידי ספק רשת אחר (למשל, חבילת גלישה) רק אם הם מאמתים בהצלחה שרשת ה-Wi-Fi מספקת גישה לאינטרנט.
• ‫[C-1-6] מומלץ מאוד, כשקוראים לשיטת ה-API‏ ConnectivityManager.reportNetworkConnectivity(), להעריך מחדש את הגישה לאינטרנט ב-Network, וכשההערכה קובעת ש-Network הנוכחי כבר לא מספק גישה לאינטרנט, לעבור לכל רשת זמינה אחרת (למשל חבילת גלישה) שמספקת גישה לאינטרנט.
• [C-SR] מומלץ מאוד לבצע אקראיות של כתובת ה-MAC של המקור ומספר הרצף של מסגרות בקשת הבדיקה, פעם אחת בתחילת כל סריקה, בזמן שה-STA מנותק.
  • כל קבוצה של פריימים של בקשות בדיקה שמרכיבים סריקה אחת צריכה להשתמש בכתובת MAC עקבית אחת (אסור להגריל כתובת MAC באמצע הסריקה).
  • מספר הרצף של בקשת הבדיקה צריך לעלות כרגיל (בסדר עוקב) בין בקשות הבדיקה בסריקה.
  • מספר הרצף של בקשת הבדיקה צריך להיות אקראי בין בקשת הבדיקה האחרונה של סריקה לבין בקשת הבדיקה הראשונה של הסריקה הבאה.
• ‫[C-SR] מומלץ מאוד, בזמן ש-STA מנותק, לאפשר רק את הרכיבים הבאים בפריים של בקשת בדיקה:
  • קבוצת פרמטרים של SSID ‏ (0)
  • קבוצת פרמטרים של DS‏ (3)

אם הטמעות המכשירים כוללות תמיכה במצב חיסכון בצריכת חשמל ב-Wi-Fi, כפי שמוגדר בתקן IEEE 802.11, הן:

• ‫[C-3-1] חובה להשבית את מצב החיסכון באנרגיה של Wi-Fi בכל פעם שאפליקציה מקבלת נעילה מסוג WIFI_MODE_FULL_HIGH_PERF או נעילה מסוג WIFI_MODE_FULL_LOW_LATENCY באמצעות ממשקי ה-API‏ WifiManager.createWifiLock() ו-WifiManager.WifiLock.acquire(), והנעילה פעילה.
• ‫[C-3-2] זמן הטעינה הממוצע הלוך ושוב בין המכשיר לנקודת גישה כשהמכשיר במצב נעילה של Wi-Fi עם זמן טעינה נמוך (WIFI_MODE_FULL_LOW_LATENCY) חייב להיות קצר יותר מזמן הטעינה במצב נעילה של Wi-Fi עם ביצועים גבוהים (WIFI_MODE_FULL_HIGH_PERF).
• ‫[C-SR] מומלץ מאוד למזער את זמן האחזור של הלוך ושוב ב-Wi-Fi בכל פעם שמתבצעת נעילה של זמן אחזור נמוך (WIFI_MODE_FULL_LOW_LATENCY) והיא נכנסת לתוקף.

אם הטמעות המכשירים תומכות ב-Wi-Fi ומשתמשות ב-Wi-Fi לסריקת מיקום, הן:

• ‫[C-2-1] חובה לספק למשתמש אמצעי נוח להפעלה או להשבתה של קריאת הערך באמצעות שיטת ה-API‏ WifiManager.isScanAlwaysAvailable.

‫7.4.2.1. Wi-Fi ישיר

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

• צריך לכלול תמיכה ב-Wi-Fi Direct (Wi-Fi peer-to-peer).

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

• ‫[C-1-1] חובה להטמיע את ה-API התואם ל-Android כפי שמתואר במסמכי ה-SDK.
• ‫[C-1-2] חובה לדווח על תכונת החומרה android.hardware.wifi.direct.
• ‫[C-1-3] חובה לתמוך בפעולה רגילה של Wi-Fi.
• ‫[C-1-4] חובה לתמוך בפעולות של Wi-Fi ו-Wi-Fi Direct בו-זמנית.

‫7.4.2.2. הגדרה של קישור ישיר עם מנהור Wi-Fi

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

• צריך לכלול תמיכה בהגדרה של קישור ישיר במנהור Wi-Fi‏ (TDLS) כפי שמתואר בתיעוד של Android SDK.

אם הטמעות המכשירים כוללות תמיכה ב-TDLS וה-TDLS מופעל על ידי ה-API של WiFiManager, הן:

• ‫[C-1-1] חובה להצהיר על תמיכה ב-TDLS באמצעות WifiManager.isTdlsSupported.
• מומלץ להשתמש ב-TDLS רק אם הדבר אפשרי ומועיל.
• מומלץ להשתמש בהיוריסטיקה כלשהי ולא להשתמש ב-TDLS אם הביצועים שלה עשויים להיות גרועים יותר מאשר מעבר דרך נקודת הגישה ל-Wi-Fi.

‫7.4.2.3. Wi-Fi Aware

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

• צריך לכלול תמיכה ב-Wi-Fi Aware.

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

• ‫[C-1-1] חובה להטמיע את ממשקי ה-API‏ WifiAwareManager כפי שמתואר בתיעוד ה-SDK.
• ‫[C-1-2] חובה להצהיר על השימוש ב-feature flag‏ android.hardware.wifi.aware.
• ‫[C-1-3] חובה לתמוך בפעולות של Wi-Fi ו-Wi-Fi Aware בו-זמנית.
• ‫[C-1-4] חובה להקצות כתובת אקראית לממשק הניהול של Wi-Fi Aware במרווחי זמן של עד 30 דקות, ובכל פעם שמפעילים את Wi-Fi Aware, אלא אם מתבצעת פעולת מדידת מרחק של Aware או שנתיב נתונים של Aware פעיל (לא צפוי הקצאה אקראית כל עוד נתיב הנתונים פעיל).

אם הטמעות המכשירים כוללות תמיכה ב-Wi-Fi Aware ובמיקום Wi-Fi כפי שמתואר בקטע 7.4.2.5, והן חושפות את הפונקציות האלה לאפליקציות של צד שלישי, אז:

• ‫[C-2-1] חובה להטמיע את ממשקי ה-API לחיפוש מיקום: setRangingEnabled,‏ setMinDistanceMm,‏ setMaxDistanceMm ו-onServiceDiscoveredWithinRange.

‫7.4.2.4. פרוטוקול Passpoint ל-Wi-Fi

אם הטמעות של מכשירים כוללות תמיכה ב-802.11 (Wi-Fi), הן:

• צריך לכלול תמיכה ב-Wi-Fi Passpoint.

אם הטמעות המכשירים כוללות תמיכה ב-Wi-Fi Passpoint, הן:

• ‫[C-1-2] חובה להטמיע את ממשקי ה-API שקשורים ל-Passpoint WifiManager כפי שמתואר בתיעוד ה-SDK.
• ‫[C-1-3] המכשיר חייב לתמוך בתקן IEEE 802.11u, במיוחד בנוגע לזיהוי רשת ובחירת רשת, כמו Generic Advertisement Service‏ (GAS) ו-Access Network Query Protocol‏ (ANQP).

לעומת זאת, אם ההטמעות של המכשירים לא כוללות תמיכה ב-Wi-Fi Passpoint:

• ‫[C-2-1] ההטמעה של ממשקי ה-API שקשורים ל-Passpoint‏ WifiManager חייבת להחזיר את השגיאה UnsupportedOperationException.

‫7.4.2.5. מיקום Wi-Fi (זמן הלוך ושוב ב-Wi-Fi‏ – RTT)

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

• מומלץ לכלול תמיכה במיקום Wi-Fi.

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

• ‫[C-1-1] חובה להטמיע את ממשקי ה-API‏ WifiRttManager כפי שמתואר בתיעוד ה-SDK.
• ‫[C-1-2] חובה להצהיר על השימוש ב-feature flag‏ android.hardware.wifi.rtt.
• ‫[C-1-3] חובה לבצע רנדומיזציה של כתובת ה-MAC של המקור עבור כל פרץ RTT שמופעל בזמן שממשק ה-Wi-Fi שבו מופעל ה-RTT לא משויך לנקודת גישה.

‫7.4.2.6. העברה של שמירת חיבור Wi-Fi פעיל

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

• צריך לכלול תמיכה בהעברת נתונים של שמירת חיבור Wi-Fi.

אם הטמעות של מכשירים כוללות תמיכה בהעברת עומס של שמירת חיבור 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 (פרוטוקול הקצאת הרשאות למכשיר)

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

• צריך לכלול תמיכה ב-Wi-Fi Easy Connect (DPP).

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

• ‫[C-1-1] הפונקציה WifiManager#isEasyConnectSupported()‎ חייבת להחזיר את הערך true.

‫7.4.3. Bluetooth

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

• צריכה להיות תמיכה בקודקים מתקדמים של אודיו ובקודקים של אודיו ל-Bluetooth (לדוגמה, LDAC).

אם הטמעות המכשיר תומכות ב-HFP, ב-A2DP וב-AVRCP, הן:

• צריך לתמוך בחיבור של 5 מכשירים לפחות.

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

• ‫[C-1-1] חובה לתמוך ב-Bluetooth 4.2 וב-Bluetooth LE Data Length Extension.

‫Android כולל תמיכה ב-Bluetooth וב-Bluetooth עם צריכת אנרגיה נמוכה.

אם הטמעות המכשירים כוללות תמיכה ב-Bluetooth וב-Bluetooth Low Energy, הן:

• ‫[C-2-1] חובה להצהיר על התכונות הרלוונטיות של הפלטפורמה (android.hardware.bluetooth ו-android.hardware.bluetooth_le בהתאמה) ולהטמיע את ממשקי ה-API של הפלטפורמה.
• מומלץ להטמיע פרופילים רלוונטיים של Bluetooth, כמו A2DP,‏ AVRCP,‏ OBEX,‏ HFP וכו', בהתאם למכשיר.

אם הטמעות של מכשירים כוללות תמיכה ב-Bluetooth עם צריכת אנרגיה נמוכה (BLE), הן:

• ‫[C-3-1] חובה להצהיר על תכונת החומרה android.hardware.bluetooth_le.
• ‫[C-3-2] חובה להפעיל את ממשקי ה-API של Bluetooth שמבוססים על GATT (פרופיל מאפיינים כלליים), כפי שמתואר במסמכי התיעוד של ה-SDK וב-android.bluetooth.
• ‫[C-3-3] חובה לדווח על הערך הנכון של BluetoothAdapter.isOffloadedFilteringSupported() כדי לציין אם מיושמת לוגיקת הסינון של מחלקות ה-API‏ ScanFilter.
• ‫[C-3-4] חובה לדווח על הערך הנכון של BluetoothAdapter.isMultipleAdvertisementSupported() כדי לציין אם יש תמיכה בפרסום עם צריכת אנרגיה נמוכה.
• ‫[C-3-5] חובה להטמיע זמן קצוב לתפוגה של כתובת פרטית שניתנת לפתרון (RPA) שלא עולה על 15 דקות, ולשנות את הכתובת כשהזמן הקצוב לתפוגה מסתיים, כדי להגן על פרטיות המשתמשים כשהמכשיר משתמש באופן פעיל ב-BLE לסריקה או לפרסום. כדי למנוע מתקפות תזמון, גם מרווחי הזמן הקצובים צריכים להיות אקראיים, בין 5 ל-15 דקות.
• צריכה להיות תמיכה בהעברת הלוגיקה של הסינון לערכת השבבים של Bluetooth כשמטמיעים את ScanFilter API.
• צריכה להיות תמיכה בהעברת הסריקה באצווה לערכת השבבים של Bluetooth.
• צריך לתמוך בהצגת כמה מודעות עם לפחות 4 מיקומי מודעות.

אם הטמעות המכשירים תומכות ב-Bluetooth LE ומשתמשות ב-Bluetooth LE לסריקת מיקום, הן:

• ‫[C-4-1] חובה לספק למשתמש אפשרות להפעיל או להשבית את קריאת הערך דרך System API‏ BluetoothAdapter.isBleScanAlwaysAvailable().

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

• ‫[C-5-1] הפונקציה BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID) חייבת להחזיר true.

7.4.4. תקשורת מטווח קצר (NFC)

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

• צריך לכלול משדר-מקלט וחומרה קשורה לתקשורת מטווח קצר (NFC).
• ‫[C-0-1] חובה להטמיע את ממשקי ה-API‏ android.nfc.NdefMessage ו-android.nfc.NdefRecord גם אם הם לא כוללים תמיכה ב-NFC או שמצהירים על התכונה android.hardware.nfc, כי המחלקות מייצגות פורמט של נתונים שאינו תלוי בפרוטוקול.

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

• ‫[C-1-1] חובה לדווח על התכונה android.hardware.nfc באמצעות השיטה android.content.pm.PackageManager.hasSystemFeature().
• חייבת להיות אפשרות לקרוא ולכתוב הודעות NDEF באמצעות תקני ה-NFC הבאים:
• ‫[C-1-2] המכשיר חייב להיות מסוגל לפעול כקורא/כותב של NFC Forum (כפי שמוגדר במפרט הטכני של NFC Forum‏ NFCForum-TS-DigitalProtocol-1.0) באמצעות תקני ה-NFC הבאים:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • סוגי תגי NFC‏ 1, 2, 3, 4, 5 (מוגדרים על ידי NFC Forum)

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

• ‫[C-1-13] חובה לבצע סקר לכל הטכנולוגיות הנתמכות בזמן שמצב הגילוי של NFC מופעל.

• צריך להיות במצב גילוי NFC בזמן שהמכשיר פעיל, המסך פעיל ונעילת המסך לא נעולה.
• צריכה להיות אפשרות לקרוא את הברקוד וכתובת ה-URL (אם הם מקודדים) של מוצרי Thinfilm NFC Barcode.

שימו לב: הקישורים שזמינים לציבור לא זמינים למפרטים של JIS,‏ ISO ו-NFC Forum שצוינו למעלה.

‫Android כולל תמיכה במצב Host Card Emulation ‏ (HCE) של NFC.

אם הטמעות המכשירים כוללות ערכת שבבים של בקר NFC עם יכולת HCE (עבור NfcA ו/או NfcB) ותמיכה בניתוב של מזהה אפליקציה (AID), הן:

• ‫[C-2-1] חובה לדווח על קבוע התכונה android.hardware.nfc.hce.
• ‫[C-2-2] חובה לתמוך בממשקי NFC HCE API כפי שמוגדרים ב-Android SDK.

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

• ‫[C-3-1] חובה לדווח על קבוע התכונה android.hardware.nfc.hcef.
• ‫[C-3-2] חובה להטמיע את ממשקי ה-API של NFC-F Card Emulation כפי שמוגדר ב-Android SDK.

אם הטמעות המכשירים כוללות תמיכה כללית ב-NFC כפי שמתואר בקטע הזה ותמיכה בטכנולוגיות MIFARE (‏MIFARE Classic, ‏ MIFARE Ultralight, ‏ NDEF ב-MIFARE Classic) בתפקיד הקורא/הכותב, הן:

• ‫[C-4-1] חובה להטמיע את ממשקי ה-API התואמים ל-Android כפי שמתואר ב-Android SDK.
• ‫[C-4-2] חובה לדווח על התכונה com.nxp.mifare מהשיטה android.content.pm.PackageManager.hasSystemFeature(). הערה: זו לא תכונה רגילה של Android, ולכן היא לא מופיעה כקבוע במחלקה android.content.pm.PackageManager.

‫7.4.5. פרוטוקולי רישות וממשקי API

‫7.4.5.1. יכולת רשת מינימלית

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

• ‫[C-0-1] חובה לכלול תמיכה בצורה אחת או יותר של רשת נתונים. באופן ספציפי, הטמעות של מכשירים חייבות לכלול תמיכה לפחות בתקן נתונים אחד עם יכולת של 200‎ Kbit/sec או יותר. דוגמאות לטכנולוגיות שעומדות בדרישה הזו כוללות EDGE, ‏ HSPA, ‏ EV-DO, ‏ 802.11g, ‏ Ethernet ו-Bluetooth PAN.
• בנוסף, צריך לכלול תמיכה לפחות בתקן נפוץ אחד של נתונים אלחוטיים, כמו 802.11 ‏ (Wi-Fi), כשחיבור הנתונים העיקרי הוא תקן פיזי של רשת (כמו אתרנט).
• יכול להיות שיהיו כמה דרכים לחיבור נתונים.

‫7.4.5.2. IPv6

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

• ‫[C-0-2] חובה לכלול מחסנית רשת IPv6 ולתמוך בתקשורת IPv6 באמצעות ממשקי ה-API המנוהלים, כמו java.net.Socket ו-java.net.URLConnection, וגם ממשקי ה-API המקוריים, כמו שקעי AF_INET6.
• ‫[C-0-3] חובה להפעיל IPv6 כברירת מחדל.
• חובה לוודא שהתקשורת ב-IPv6 אמינה כמו ב-IPv4, לדוגמה:
  • ‫[C-0-4] חובה לשמור על קישוריות IPv6 במצב שינה.
  • ‫[C-0-5] הגבלת קצב לא יכולה לגרום למכשיר לאבד קישוריות IPv6 בכל רשת שתואמת ל-IPv6 ומשתמשת בערכי זמן חיים של RA של לפחות 180 שניות.
• ‫[C-0-6] חובה לספק לאפליקציות של צד שלישי קישוריות IPv6 ישירה לרשת כשהמכשיר מחובר לרשת IPv6, ללא תרגום של כתובת או יציאה שמתבצע באופן מקומי במכשיר. גם ממשקי API מנוהלים כמו Socket#getLocalAddress או Socket#getLocalPort) וגם ממשקי NDK API כמו getsockname() או IPV6_PKTINFO חייבים להחזיר את כתובת ה-IP והיציאה שמשמשות בפועל לשליחה ולקבלה של מנות ברשת, ומוצגות ככתובת ה-IP והיציאה של המקור לשרתי אינטרנט (ווב).

רמת התמיכה הנדרשת ב-IPv6 תלויה בסוג הרשת, כפי שמוצג בדרישות הבאות.

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

• ‫[C-1-1] חובה לתמוך בפעולה של dual-stack ו-IPv6 בלבד ב-Wi-Fi.

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

• ‫[C-2-1] חובה לתמוך בפעולה של dual-stack ו-IPv6 בלבד ב-Ethernet.

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

• ‫[C-3-1] חובה לתמוך בפעולת IPv6 (IPv6 בלבד ואולי גם dual-stack) ברשת סלולרית.

אם ההטמעות של המכשיר תומכות ביותר מסוג רשת אחד (למשל, Wi-Fi ונתונים סלולריים), הן:

• ‫[C-4-1] המכשיר חייב לעמוד בדרישות שלמעלה בו-זמנית בכל רשת, כשהוא מחובר בו-זמנית ליותר מסוג רשת אחד.

‫7.4.5.3. פורטלים שבויים

פורטל שבוי הוא רשת שנדרשת בה כניסה לחשבון כדי לקבל גישה לאינטרנט.

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

• ‫[C-1-1] חובה לספק אפליקציית פורטל שבוי לטיפול ב-Intent‏ ACTION_CAPTIVE_PORTAL_SIGN_IN ולהצגת דף הכניסה לפורטל השבוי, על ידי שליחת ה-Intent הזה, בקריאה ל-System API‏ ConnectivityManager#startCaptivePortalApp(Network, Bundle).
• [C-1-2] המכשיר חייב לזהות פורטלים שבויים ולתמוך בכניסה דרך אפליקציית הפורטל השבוי, כשהמכשיר מחובר לכל סוג רשת, כולל רשת סלולרית, Wi-Fi, אתרנט או Bluetooth.
• [C-1-3] חובה לתמוך בכניסה לפורטלים שבויים באמצעות DNS בפורמט טקסט לא מוצפן, כשהמכשיר מוגדר לשימוש במצב קפדני של שרת DNS פרטי.
• ‫[C-1-4] חובה להשתמש ב-DNS מוצפן בהתאם לתיעוד של ערכת ה-SDK‏ android.net.LinkProperties.getPrivateDnsServerName ו-android.net.LinkProperties.isPrivateDnsActive לכל תעבורת הרשת שלא מתקשרת באופן מפורש עם פורטל הכניסה.
• ‫[C-1-5] חובה לוודא שכשמשתמש מתחבר לפורטל שבוי, הרשת שמוגדרת כברירת מחדל לשימוש באפליקציות (כפי שמוחזרת על ידי ConnectivityManager.getActiveNetwork,‏ ConnectivityManager.registerDefaultNetworkCallback, ומשמשת כברירת מחדל ממשקי API של Java לחיבור לרשת כמו java.net.Socket, וממשקי API מקוריים כמו connect()) היא כל רשת זמינה אחרת שמספקת גישה לאינטרנט, אם יש כזו.

‫7.4.6. הגדרות הסנכרון

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

• ‫[C-0-1] הגדרת הסנכרון האוטומטי הראשית חייבת להיות מופעלת כברירת מחדל, כדי שהשיטה getMasterSyncAutomatically() תחזיר את הערך true.

‫7.4.7. חוסך הנתונים (Data Saver)

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

• [SR] מומלץ מאוד לספק את מצב חיסכון בחבילת הגלישה.

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

• ‫[C-1-1] חובה לתמוך בכל ממשקי ה-API בכיתה ConnectivityManager, כפי שמתואר במסמכי ה-SDK

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

• ‫[C-2-1] חייבת להחזיר את הערך RESTRICT_BACKGROUND_STATUS_DISABLED עבור ConnectivityManager.getRestrictBackgroundStatus()
• ‫[C-2-2] אסור לשדר ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

‫7.4.8. רכיבים מאובטחים

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

• ‫[C-1-1] חובה למנות את קוראי האלמנטים המאובטחים הזמינים באמצעות android.se.omapi.SEService.getReaders() API.

• ‫[C-1-2] חובה להצהיר על דגלי התכונות הנכונים באמצעות android.hardware.se.omapi.uicc למכשיר עם רכיבים מאובטחים מבוססי UICC, ‏ android.hardware.se.omapi.ese למכשיר עם רכיבים מאובטחים מבוססי eSE ו-android.hardware.se.omapi.sd למכשיר עם רכיבים מאובטחים מבוססי SD.

‫7.5. מצלמות

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

• ‫[C-1-1] חובה להצהיר על ה-feature flag‏ android.hardware.camera.any.
• ‫[C-1-2] אפליקציה חייבת להיות מסוגלת להקצות בו-זמנית 3 מפות סיביות מסוג RGBA_8888 שוות לגודל התמונות שנוצרות על ידי חיישן המצלמה ברזולוציה הגדולה ביותר במכשיר, בזמן שהמצלמה פתוחה למטרת תצוגה מקדימה בסיסית וצילום תמונות סטילס.
• ‫[C-1-3] חובה לוודא שאפליקציית המצלמה שמותקנת מראש כברירת מחדל ומטפלת ב-Intent‏ MediaStore.ACTION_IMAGE_CAPTURE, ‏ MediaStore.ACTION_IMAGE_CAPTURE_SECURE או MediaStore.ACTION_VIDEO_CAPTURE, אחראית להסרת המיקום של המשתמש במטא-נתונים של התמונה לפני שליחתה לאפליקציה המקבלת, אם לאפליקציה המקבלת אין הרשאה ACCESS_FINE_LOCATION.

‫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 נרשם בפלטפורמה של תצוגה מקדימה של המצלמה, אלא אם האפליקציה הפעילה את הפנס באופן מפורש על ידי הפעלת המאפיינים android.hardware.Camera.PreviewCallback או FLASH_MODE_ON של אובייקט Camera.Parameters.FLASH_MODE_AUTO חשוב לדעת: ההגבלה הזו לא חלה על אפליקציית המצלמה המובנית במערכת של המכשיר, אלא רק על אפליקציות של צד שלישי שמשתמשות ב-Camera.PreviewCallback.

‫7.5.2. מצלמה קדמית

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

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

• עשוי לכלול מצלמה קדמית.

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

• ‫[C-1-1] חובה לדווח על דגל התכונה android.hardware.camera.any ו-android.hardware.camera.front.
• ‫[C-1-2] הרזולוציה חייבת להיות VGA לפחות (‎640x480 פיקסלים).
• ‫[C-1-3] אסור להשתמש במצלמה קדמית כברירת מחדל עבור Camera API, ואסור להגדיר את ה-API כך שיחשיב מצלמה קדמית כמצלמה אחורית שמוגדרת כברירת מחדל, גם אם זו המצלמה היחידה במכשיר.
• ‫[C-1-4] התצוגה המקדימה של המצלמה חייבת להיות הפוכה אופקית ביחס לכיוון שצוין על ידי האפליקציה, אם האפליקציה הנוכחית ביקשה במפורש שהתצוגה של המצלמה תסתובב באמצעות קריאה לשיטה android.hardware.Camera.setDisplayOrientation(). לעומת זאת, התצוגה המקדימה חייבת להיות הפוכה לאורך הציר האופקי שמוגדר כברירת מחדל במכשיר, אם האפליקציה הנוכחית לא מבקשת במפורש שהתצוגה של המצלמה תסתובב באמצעות קריאה לשיטה android.hardware.Camera.setDisplayOrientation().
• ‫[C-1-5] אסור לשקף את תמונת הסטילס או את זרמי הווידאו הסופיים שצולמו ומוחזרים לקריאות חוזרות (callback) של האפליקציה או שנשמרים באחסון המדיה.
• ‫[C-1-6] חובה לשקף את התמונה שמוצגת בתצוגה המקדימה אחרי הצילום באותו אופן כמו זרם התמונות בתצוגה המקדימה של המצלמה.
• יכול לכלול תכונות (כמו פוקוס אוטומטי, פלאש וכו') שזמינות למצלמות שפונות לאחור, כפי שמתואר בסעיף 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 host.
• ‫[C-1-3] המכשיר חייב לעבור את בדיקות ה-CTS של המצלמה עם מכשיר מצלמה חיצוני פיזי שמחובר אליו. פרטים על בדיקות CTS של מצלמות זמינים בכתובת source.android.com.
• צריך לתמוך בדחיסת סרטונים כמו MJPEG כדי לאפשר העברה של סטרימינג באיכות גבוהה ללא קידוד (כלומר, סטרימינג של תמונות גולמיות או של תמונות שנדחסו בנפרד).
• יכול להיות שיש תמיכה בכמה מצלמות.
• יכול להיות שהמכשיר תומך בקידוד וידאו שמבוסס על מצלמה.

אם יש תמיכה בקידוד וידאו שמבוסס על מצלמה:

• ‫[C-2-1] הטמעת המכשיר חייבת לאפשר גישה לשידור בו-זמני לא מוצפן / MJPEG (ברזולוציה QVGA או גבוהה יותר).

‫7.5.4. התנהגות של Camera API

‫Android כוללת שני חבילות API לגישה למצלמה. ה-API החדש יותר android.hardware.camera2 מאפשר לאפליקציה שליטה במצלמה ברמה נמוכה יותר, כולל זרימות יעילות של צילום רצף או סטרימינג ללא העתקה, ובקרות לכל פריים של חשיפה, הגברה, איזון לבן, המרת צבעים, הסרת רעשים, חידוד ועוד.

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

כל התכונות שמשותפות למחלקה android.hardware.Camera שהוצאה משימוש ולחבילה החדשה יותר android.hardware.camera2 חייבות לספק ביצועים ואיכות שווים בשני ממשקי ה-API. לדוגמה, בהגדרות שוות ערך, מהירות ודיוק הפוקוס האוטומטי חייבים להיות זהים, ואיכות התמונות שצולמו חייבת להיות זהה. תכונות שתלויות בסמנטיקה השונה של שני ממשקי ה-API לא צריכות להיות זהות במהירות או באיכות, אבל מומלץ שהן יהיו זהות ככל האפשר.

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

• ‫[C-0-1] חובה להשתמש ב-android.hardware.PixelFormat.YCbCr_420_SP כדי להציג נתונים בתצוגה מקדימה שמועברים לקריאות חוזרות (callback) של אפליקציה, אם האפליקציה מעולם לא קראה ל-android.hardware.Camera.Parameters.setPreviewFormat(int).
• ‫[C-0-2] חובה שהנתונים יהיו בפורמט הקידוד NV21 כשיישום רושם מופע של android.hardware.Camera.PreviewCallback והמערכת קוראת לשיטה onPreviewFrame() ופורמט התצוגה המקדימה הוא YCbCr_420_SP, הנתונים במערך ה-byte[] שמועבר ל-onPreviewFrame(). כלומר, NV21 חייב להיות ברירת המחדל.
• ‫[C-0-3] android.hardware.Camera חייב לתמוך בפורמט YV12 (כפי שמצוין על ידי הקבוע android.graphics.ImageFormat.YV12) בתצוגות מקדימות של המצלמה, גם במצלמה הקדמית וגם במצלמה האחורית. (מקודד הווידאו והמצלמה עשויים להשתמש בכל פורמט פיקסלים מקורי, אבל הטמעת המכשיר חייבת לתמוך בהמרה ל-YV12).
• ‫[C-0-4] חובה לתמוך בפורמטים android.hardware.ImageFormat.YUV_420_888 ו-android.hardware.ImageFormat.JPEG כפלט דרך android.media.ImageReader API למכשירי android.hardware.camera2 שמפרסמים יכולת REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE ב-android.request.availableCapabilities.
• ‫[C-0-5] המכשיר עדיין חייב להטמיע את Camera API המלא שכלול בתיעוד של Android SDK, גם אם המכשיר כולל פוקוס אוטומטי בחומרה או יכולות אחרות. לדוגמה, מצלמות שאין להן פוקוס אוטומטי עדיין צריכות להפעיל את כל המקרים הרשומים של android.hardware.Camera.AutoFocusCallback (גם אם זה לא רלוונטי למצלמה ללא פוקוס אוטומטי). שימו לב שהדבר חל על מצלמות קדמיות. לדוגמה, למרות שרוב המצלמות הקדמיות לא תומכות בפוקוס אוטומטי, עדיין צריך 'לזייף' את הקריאות החוזרות (callback) של ה-API, כפי שמתואר.
• ‫[C-0-6] המערכת חייבת לזהות ולכבד כל שם פרמטר שמוגדר כקבוע במחלקה android.hardware.Camera.Parameters ובמחלקה android.hardware.camera2.CaptureRequest. לעומת זאת, הטמעות של מכשירים לא יכולות לכבד או לזהות קבועי מחרוזות שמועברים לשיטה android.hardware.Camera.setParameters(), מלבד אלה שמתועדים כקבועים ב-android.hardware.Camera.Parameters. כלומר, הטמעות של מכשירים חייבות לתמוך בכל הפרמטרים הסטנדרטיים של המצלמה אם החומרה מאפשרת זאת, ואסור להן לתמוך בסוגים של פרמטרים מותאמים אישית של המצלמה. לדוגמה, הטמעות במכשירים שתומכות בצילום תמונות באמצעות טכניקות צילום עם טווח דינמי גבוה (HDR) חייבות לתמוך בפרמטר המצלמה Camera.SCENE_MODE_HDR.
• ‫[C-0-7] חובה לדווח על רמת התמיכה המתאימה באמצעות המאפיין android.info.supportedHardwareLevel כפי שמתואר ב-Android SDK, ולדווח על דגלי התכונות המתאימים של מסגרת העבודה.
• ‫[C-0-8] המכשיר חייב גם להצהיר על יכולות המצלמה האישיות שלו android.hardware.camera2 באמצעות המאפיין android.request.availableCapabilities, ולהצהיר על דגלי התכונות המתאימים. המכשיר חייב להגדיר את דגל התכונה אם אחד ממכשירי המצלמה המחוברים שלו תומך בתכונה.
• ‫[C-0-9] חייב לשדר את כוונת Camera.ACTION_NEW_PICTURE בכל פעם שמצולמת תמונה חדשה על ידי המצלמה והערך של התמונה נוסף למאגר המדיה.
• ‫[C-0-10] חובה לשדר את כוונת Camera.ACTION_NEW_VIDEO בכל פעם שסרטון חדש מצולם על ידי המצלמה והערך של התמונה נוסף למאגר המדיה.
• ‫[C-0-11] חובה שכל המצלמות שניתן לגשת אליהן דרך android.hardware.Camera API שהוצא משימוש, יהיו נגישות גם דרך android.hardware.camera2 API.
• ‫[C-0-12] חובה לוודא שמראה הפנים לא משתנה, כולל, בין היתר, שינוי גיאומטריית הפנים, גוון העור בפנים או החלקת העור בפנים בכל API של android.hardware.camera2 או android.hardware.Camera.
• ‫[C-SR] במכשירים עם כמה מצלמות RGB שפונות לאותו כיוון, מומלץ מאוד לתמוך במכשיר מצלמה לוגי שמציג את היכולת CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, שכוללת את כל מצלמות ה-RGB שפונות לאותו כיוון כמכשירי משנה פיזיים.

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

• ‫[C-1-1] חובה להטמיע ממשק API כזה למצלמה באמצעות android.hardware.camera2 API.
• יכול להיות ש-MAY יספק תגי ספק או תוספים ל-API‏ android.hardware.camera2.

‫7.5.5. כיוון המצלמה

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

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

‫7.6. זיכרון ואחסון

‫7.6.1. זיכרון ואחסון מינימליים

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

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

‫7.6.2. נפח אחסון משותף של אפליקציות

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

• ‫[C-0-1] חובה להציע אחסון שניתן לשיתוף בין אפליקציות, שנקרא גם 'אחסון חיצוני משותף', 'אחסון משותף לאפליקציות' או לפי נתיב Linux ‏'/sdcard' שבו הוא מותקן.
• ‫[C-0-2] חייב להיות מוגדר עם אחסון משותף שמוטמע כברירת מחדל, כלומר 'מוכן לשימוש', בלי קשר לשאלה אם האחסון מיושם ברכיב אחסון פנימי או במדיה לאחסון נתונים שאפשר להסיר (למשל, חריץ לכרטיס Secure Digital).
• ‫[C-0-3] חובה לטעון את האחסון השיתופי של האפליקציה ישירות בנתיב Linux‏ sdcard או לכלול קישור סמלי של Linux מ-sdcard לנקודת הטעינה בפועל.
• [C-0-4] חובה להפעיל נפח אחסון ייעודי לאפליקציות כברירת מחדל לכל האפליקציות שמטרגטות רמת API‏ 29 ומעלה, למעט במצב הבא:
  • כשהאפליקציה מבקשת android:requestLegacyExternalStorage="true" במניפסט שלה.
• ‫[C-0-5] חובה להסתיר מטא-נתונים של מיקום, כמו תגי Exif של GPS, שמאוחסנים בקובצי מדיה, כשניגשים לקבצים האלה דרך MediaStore, אלא אם לאפליקציה הקוראת יש הרשאת ACCESS_MEDIA_LOCATION.

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

• אחסון נשלף שמשתמשים יכולים לגשת אליו, כמו חריץ לכרטיס Secure Digital ‏ (SD).
• חלק מהאחסון הפנימי (שאי אפשר להסיר) כפי שהוא מוטמע ב-פרויקט קוד פתוח של Android ‏ (AOSP).

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

• ‫[C-1-1] האפליקציה חייבת להציג הודעה קופצת או הודעה קצרה ומתומצת בממשק המשתמש כדי להזהיר את המשתמש כשלא מוכנס אמצעי אחסון לחריץ.
• ‫[C-1-2] חובה לכלול אמצעי אחסון בפורמט FAT (למשל כרטיס SD) או לציין על הקופסה ובחומרים אחרים שזמינים בזמן הרכישה שאמצעי האחסון נרכש בנפרד.

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

• מומלץ להשתמש בהטמעה של AOSP של האחסון המשותף הפנימי של האפליקציה.
• יכול להיות שנשתף את נפח האחסון עם הנתונים הפרטיים של האפליקציה.

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

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

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

• התאימות צריכה להיות עם המארח של MTP ב-Android, ‏ Android File Transfer.
• צריך לדווח על מחלקה של מכשיר USB עם הערך 0x00.
• צריך לדווח על שם ממשק USB ‏ 'MTP'.

‫7.6.3. אחסון שניתן להתאמה

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

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

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

• [SR] מומלץ מאוד להטמיע אחסון שניתן להתאמה.

‫7.7. USB

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

• צריכה להיות תמיכה במצב ציוד היקפי USB ותמיכה במצב מארח USB.

‫7.7.1. מצב ציוד היקפי בחיבור USB

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

• ‫[C-1-1] היציאה חייבת להיות ניתנת לחיבור למארח USB עם יציאת USB מסוג A או מסוג C.
• ‫[C-1-2] חובה לדווח על הערך הנכון של iSerialNumber בתיאור המכשיר בתקן USB באמצעות android.os.Build.SERIAL.
• ‫[C-1-3] אם המכשיר תומך ב-USB Type-C, הוא חייב לזהות מטענים של 1.5A ו-3.0A בהתאם לתקן הנגד Type-C, וחייב לזהות שינויים בפרסום.
• [SR] היציאה צריכה להיות בפורמט USB מסוג מיקרו-B, מיקרו-AB או Type-C. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה כדי שיהיה אפשר לשדרג אותם לגרסאות עתידיות של הפלטפורמה.
• ‫[SR] היציאה צריכה להיות ממוקמת בחלק התחתון של המכשיר (בהתאם לכיוון הטבעי) או לאפשר סיבוב מסך בתוכנה לכל האפליקציות (כולל מסך הבית), כך שהתצוגה תהיה תקינה כשהמכשיר מוצב כשהיציאה בחלק התחתון. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה כדי שיהיה אפשר לשדרג אותם לגרסאות פלטפורמה עתידיות.
• ‫[SR] צריך להטמיע תמיכה בציור זרם של 1.5 אמפר במהלך ציוץ HS ותנועה, כפי שמצוין במפרט הטעינה של סוללת USB, גרסה 1.2. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה כדי שיהיה אפשר לשדרג אותם לגרסאות עתידיות של הפלטפורמה.
• [SR] מומלץ מאוד לא לתמוך בשיטות טעינה קנייניות שמשנות את המתח של Vbus מעבר לרמות ברירת המחדל, או משנות את תפקידי המקור/הצרכן, כי זה עלול לגרום לבעיות תאימות למטענים או למכשירים שתומכים בשיטות טעינה בתקן USB PD. ההמלצה הזו מוגדרת כ "מומלץ מאוד", אבל יכול להיות שבגרסאות עתידיות של Android נדרוש מכל המכשירים עם חיבור USB-C לתמוך בפעולה הדדית מלאה עם מטענים רגילים עם חיבור USB-C.
• [SR] מומלץ מאוד לתמוך בטעינה בתקן USB PD להחלפת תפקידים של נתונים וחשמל, אם הם תומכים ב-USB Type-C ובמצב מארח USB.
• צריכה להיות תמיכה בטעינה בתקן USB PD לטעינה במתח גבוה ותמיכה במצבים חלופיים כמו תצוגה חיצונית.
• מומלץ להטמיע את ממשק ה-API ואת המפרט של Android Open Accessory ‏ (AOA) כפי שמתואר בתיעוד של Android SDK.

אם הטמעות של מכשירים כוללות יציאת USB ומטמיעות את מפרט AOA, הן:

• ‫[C-2-1] חובה להצהיר על תמיכה בתכונת החומרה android.hardware.usb.accessory.
• ‫[C-2-2] מחלקת האחסון ההמוני ב-USB חייבת לכלול את המחרוזת android בסוף המחרוזת iInterface של תיאור הממשק של האחסון ההמוני ב-USB

‫7.7.2. מצב מארח USB

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

• ‫[C-1-1] חובה להטמיע את Android USB host API כפי שמתואר ב-Android SDK, וחובה להצהיר על תמיכה בתכונת החומרה android.hardware.usb.host.
• ‫[C-1-2] חובה להטמיע תמיכה בחיבור ציוד היקפי רגיל בחיבור USB, כלומר, חובה לבצע את אחת מהפעולות הבאות:
  • יש להם יציאת Type C במכשיר או שהם מגיעים עם כבלים שמתאימים יציאה קניינית במכשיר ליציאת USB Type-C רגילה (מכשיר USB Type-C).
  • יש לו יציאת USB מסוג A או שהוא מגיע עם כבלים שמתאימים יציאה קניינית במכשיר ליציאת USB רגילה מסוג A.
  • יש לו יציאת מיקרו AB במכשיר, שאמורה להגיע עם כבל שמתאים ליציאת Type-A רגילה.
• ‫[C-1-3] אסור לשלוח עם מתאם שממיר מיציאות USB מסוג A או מיקרו-AB ליציאה (שקע) מסוג C.
• ‫[C-SR] מומלץ מאוד להטמיע את מחלקת האודיו של USB כפי שמתואר במסמכי ה-Android SDK.
• צריך לתמוך בטעינת מכשיר ציוד היקפי שמחובר ב-USB בזמן שהוא במצב מארח. צריך לפרסם זרם מקור של לפחות 1.5A כפי שמצוין בקטע Termination Parameters (פרמטרים של סיום) של USB Type-C Cable and Connector Specification Revision 1.2 (מפרט של כבל ומחבר USB Type-C, גרסה 1.2) למחברי USB Type-C, או להשתמש בטווח זרם הפלט של Charging Downstream Port (CDP) (יציאת טעינה במורד הזרם) כפי שמצוין ב-USB Battery Charging specifications, revision 1.2 (מפרטים של טעינת סוללה ב-USB, גרסה 1.2) למחברי Micro-AB.
• מומלץ להטמיע את תקני USB Type-C ולתמוך בהם.

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

• ‫[C-2-1] המכשיר חייב לתמוך בסוג ה-HID של USB.
• ‫[C-2-2] חובה לתמוך בזיהוי ובמיפוי של שדות הנתונים הבאים של HID שצוינו בטבלאות השימוש ב-USB HID ובבקשת השימוש בפקודה קולית לקבועים של KeyEvent כמו שמוצג בהמשך:
  • דף שימוש (0xC) מזהה שימוש (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • דף השימוש (0xC) מזהה השימוש (0x0E9): KEYCODE_VOLUME_UP
  • דף שימוש (0xC) מזהה שימוש (0x0EA): KEYCODE_VOLUME_DOWN
  • דף שימוש (0xC) מזהה שימוש (0x0CF): KEYCODE_VOICE_ASSIST

אם הטמעות של מכשירים כוללות יציאת USB שתומכת במצב מארח ובמסגרת Storage Access Framework‏ (SAF), הן:

• ‫[C-3-1] המכשיר חייב לזהות מכשירי MTP (פרוטוקול העברת מדיה) שמחוברים מרחוק ולאפשר גישה לתוכן שלהם באמצעות כוונות (intent) מסוג ACTION_GET_CONTENT,‏ ACTION_OPEN_DOCUMENT ו-ACTION_CREATE_DOCUMENT. .

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

• ‫[C-4-1] חובה להטמיע פונקציונליות של יציאה עם תפקיד כפול, כפי שמוגדר במפרט USB Type-C (סעיף 4.5.1.3.3).
• ‫[SR] מומלץ מאוד לתמוך ב-DisplayPort, מומלץ לתמוך בשיעורי נתונים של USB SuperSpeed, ומומלץ מאוד לתמוך בטעינה בתקן USB PD להחלפת תפקידים של נתונים וחשמל.
• ‫[SR] מומלץ מאוד לא לתמוך במצב אביזר של מתאם אודיו, כפי שמתואר בנספח א' של המפרט של כבל ומחבר USB Type-C, גרסה 1.2.
• מומלץ להטמיע את המודל Try.* ‎ שמתאים ביותר לגורם הצורה של המכשיר. לדוגמה, במכשיר שניתן להחזיק ביד צריך להטמיע את מודל Try.SNK.

‫7.8. אודיו

‫7.8.1. מיקרופון

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

• ‫[C-1-1] חובה לדווח על קבוע התכונה android.hardware.microphone.
• ‫[C-1-2] חובה לעמוד בדרישות בנוגע להקלטות אודיו שמפורטות בקטע 5.4.
• ‫[C-1-3] המכשיר חייב לעמוד בדרישות בנוגע לזמן אחזור אודיו שמפורטות בסעיף 5.6.
• [SR] מומלץ מאוד לתמוך בהקלטה של תדרים קרובים לאולטרסאונד, כפי שמתואר בסעיף 7.8.3.

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

• ‫[C-2-1] אסור לדווח על הקבוע של התכונה android.hardware.microphone.
• [C-2-2] חובה להטמיע את ה-API להקלטת אודיו לפחות כבלי תפעול (no-ops), בהתאם לסעיף 7.

‫7.8.2. יעד השמע

אם יישומי המכשיר כוללים רמקול או יציאת פלט אודיו/מולטימדיה לציוד היקפי של פלט אודיו, כמו שקע אודיו 3.5 מ"מ עם 4 מוליכים או יציאת מצב מארח USB באמצעות מחלקת אודיו USB, הם:

• ‫[C-1-1] חובה לדווח על קבוע התכונה android.hardware.audio.output.
• ‫[C-1-2] חובה לעמוד בדרישות בנוגע להפעלת אודיו שמפורטות בקטע 5.5.
• ‫[C-1-3] המכשיר חייב לעמוד בדרישות בנוגע לזמן אחזור אודיו שמפורטות בסעיף 5.6.
• [SR] מומלץ מאוד לתמוך בהפעלה של תדרים קרובים לאולטרסאונד, כפי שמתואר בסעיף 7.8.3.

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

• ‫[C-2-1] אסור לדווח על התכונה android.hardware.audio.output.
• [C-2-2] חובה להטמיע את ממשקי ה-API שקשורים לפלט אודיו כבלי תפעול (no-ops) לפחות.

לצורך הסעיף הזה, 'יציאת פלט' היא ממשק פיזי כמו שקע אודיו של 3.5 מ"מ, HDMI או יציאת מצב מארח USB עם מחלקת אודיו USB. תמיכה בפלט אודיו באמצעות פרוטוקולים מבוססי רדיו כמו Bluetooth,‏ Wi-Fi או רשת סלולרית לא נחשבת ככוללת 'יציאת פלט'.

‫7.8.2.1. יציאות אודיו אנלוגיות

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

• [C-SR] מומלץ מאוד לכלול לפחות יציאת אודיו אחת מסוג שקע אודיו 3.5 מ"מ עם 4 מוליכים.

אם הטמעות המכשיר כוללות שקע אודיו בגודל 3.5 מ"מ עם 4 מוליכים, הן:

• ‫[C-1-1] חובה לתמוך בהפעלת אודיו באוזניות סטריאו ובאוזניות סטריאו עם מיקרופון.
• ‫[C-1-2] חובה לתמוך בתקעי אודיו מסוג TRRS עם סדר הפינים של CTIA.
• ‫[C-1-3] המכשיר חייב לתמוך בזיהוי ובמיפוי של קודי המקשים ל-3 הטווחים הבאים של עכבה שוות ערך בין המיקרופון לבין מוליכי ההארקה בתקע האודיו:
  • ‫70 אוהם או פחות: KEYCODE_HEADSETHOOK
  • ‫210-290 אוהם: KEYCODE_VOLUME_UP
  • ‫360-680 אוהם: KEYCODE_VOLUME_DOWN
• ‫[C-1-4] חובה להפעיל את ACTION_HEADSET_PLUG כשמכניסים את התקע, אבל רק אחרי שכל המגעים בתקע נוגעים בפלחים הרלוונטיים שלהם בשקע.
• ‫[C-1-5] חובה שתהיה אפשרות להפעיל לפחות 150mV ± 10% של מתח יציאה בעכבת רמקול של 32 אוהם.
• ‫[C-1-6] חובה להשתמש במיקרופון עם מתח הטיה בין ‎1.8 V ל-‎2.9 V.
• ‫[C-1-7] המכשיר חייב לזהות את קוד המקש ולמפות אותו לטווח הבא של עכבה שוות ערך בין המיקרופון לבין מוליכי הארקה בתקע האודיו:
  • 110-180 אוהם: KEYCODE_VOICE_ASSIST
• ‫[C-SR] מומלץ מאוד לתמוך בתקעים לאודיו עם סדר הפינים של OMTP.
• ‫[C-SR] מומלץ מאוד לתמוך בהקלטת אודיו מאוזניות סטריאו עם מיקרופון.

אם הטמעות המכשירים כוללות שקע אודיו 3.5 מ"מ עם 4 מוליכים ותמיכה במיקרופון, והן משדרות את android.intent.action.HEADSET_PLUG עם הערך הנוסף של המיקרופון שמוגדר כ-1, הן:

• ‫[C-2-1] המכשיר חייב לתמוך בזיהוי של מיקרופון באביזר אודיו מחובר.

‫7.8.2.2. יציאות אודיו דיגיטליות

כדי להיות תואם לאוזניות ולאביזרי אודיו אחרים שמשתמשים במחברי USB-C ומיישמים (מחלקה של אודיו USB) במערכת האקולוגית של Android, כפי שמוגדר במפרט של אוזניות USB ל-Android.

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

‫7.8.3. תדרים קרובים לאולטרסאונד

אודיו בתדר קרוב לאולטרסאונד הוא פס התדרים 18.5kHz עד 20kHz.

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

• חובה לדווח בצורה נכונה על התמיכה ביכולת של אודיו בתדר קרוב לאולטרסאונד באמצעות AudioManager.getProperty API באופן הבא:

אם הערך של PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND הוא true, מקורות האודיו VOICE_RECOGNITION ו-UNPROCESSED חייבים לעמוד בדרישות הבאות:

• ‫[C-1-1] תגובת ההספק הממוצע של המיקרופון בטווח התדרים 18.5‎ kHz עד 20‎ kHz צריכה להיות לכל היותר 15‎ dB מתחת לתגובה ב-2‎ kHz.
• ‫[C-1-2] יחס האות לרעש הלא משוקלל של המיקרופון בטווח של 18.5‎ kHz עד 20‎ kHz עבור צליל של 19‎ kHz ב-‎-26 dBFS חייב להיות לפחות 50‎ dB.

אם PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND הוא true:

• ‫[C-2-1] התגובה הממוצעת של הרמקול בטווח 18.5‎ kHz עד 20‎ kHz לא יכולה להיות נמוכה מ-40‎ dB מתחת לתגובה ב-2‎ kHz.

‫7.8.4. תקינות האות

הטמעות במכשירים: * במכשירים ניידים, מומלץ לספק נתיב אות אודיו ללא תקלות גם לזרמי קלט וגם לזרמי פלט, כפי שמוגדר על ידי אפס תקלות שנמדדו במהלך בדיקה של דקה אחת לכל נתיב. בודקים באמצעות [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) 'בדיקת תקלות אוטומטית'.

הבדיקה דורשת מתאם ללולאת אודיו, שמשמש ישירות בשקע 3.5 מ"מ, או בשילוב עם מתאם USB-C ל-3.5 מ"מ. מומלץ לבדוק את כל יציאות פלט האודיו.

נכון לעכשיו, OboeTester תומך בנתיבי AAudio, ולכן צריך לבדוק את השילובים הבאים לגבי תקלות באמצעות AAudio:

שידור אמין צריך לעמוד בקריטריונים הבאים של יחס אות לרעש (SNR) ועיוות הרמוני כולל (THD) עבור סינוס של 2,000 הרץ.

7.9. מציאות מדומה

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

‫7.9.1. מצב מציאות מדומה

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

‫7.9.2. מצב מציאות מדומה – ביצועים גבוהים

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

• ‫[C-1-1] חייב לכלול לפחות 2 ליבות פיזיות.
• ‫[C-1-2] חובה להצהיר על התכונה android.hardware.vr.high_performance.
• ‫[C-1-3] חובה לתמוך במצב ביצועים רציף.
• ‫[C-1-4] מומלץ מאוד לתמוך ב-OpenGL ES 3.2.
• ‫[C-1-5] חובה לתמוך ב-android.hardware.vulkan.level 0.
• מומלץ לתמוך ב-android.hardware.vulkan.level 1 ומעלה.
• ‫[C-1-6] חובה להטמיע את EGL_KHR_mutable_render_buffer,‏ EGL_ANDROID_front_buffer_auto_refresh,‏ EGL_ANDROID_get_native_client_buffer,‏ EGL_KHR_fence_sync,‏ EGL_KHR_wait_sync,‏ EGL_IMG_context_priority,‏ EGL_EXT_protected_content,‏ EGL_EXT_image_gl_colorspace ולחשוף את התוספים ברשימת התוספים הזמינים של EGL.
• ‫[C-1-8] חובה להטמיע את GL_EXT_multisampled_render_to_texture2,‏ GL_OVR_multiview,‏ GL_OVR_multiview2,‏ GL_EXT_protected_textures ולחשוף את התוספים ברשימת התוספים הזמינים של GL.
• [C-SR] מומלץ מאוד להטמיע את GL_EXT_external_buffer,‏ GL_EXT_EGL_image_array ו-GL_OVR_multiview_multisampled_render_to_texture, ולחשוף את התוספים ברשימת התוספים הזמינים של GL.
• ‫[C-SR] מומלץ מאוד לתמוך ב-Vulkan 1.1.
• [C-SR] מומלץ מאוד להטמיע את VK_ANDROID_external_memory_android_hardware_buffer,‏ VK_GOOGLE_display_timing ו-VK_KHR_shared_presentable_image ולחשוף אותם ברשימת התוספים הזמינים של Vulkan.
• ‫[C-SR] מומלץ מאוד לחשוף לפחות משפחת תורים אחת של Vulkan שבה flags מכיל גם את VK_QUEUE_GRAPHICS_BIT וגם את VK_QUEUE_COMPUTE_BIT, ו-queueCount הוא לפחות 2.
• ‫[C-1-7] המעבד הגרפי והמסך חייבים להיות מסוגלים לסנכרן את הגישה למאגר הקדמי המשותף, כך שהצגת תוכן VR בטכנולוגיית רינדור לסירוגין של העיניים בקצב של 60fps עם שני הקשרים של רינדור תתבצע ללא חפצי רינדור גלויים.
• ‫[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] מומלץ מאוד לתמוך בהקצאה של AHardwareBufferעם יותר משכבה אחת ועם סימונים ופורמטים שצוינו ב-C-1-10.
• ‫[C-1-11] המכשיר חייב לתמוך בפענוח H.264 ברזולוציה של לפחות ‎3,840 x 2,160 ב-30fps, עם דחיסה לממוצע של ‎40Mbps (שווה ערך ל-4 מקרים של ‎1,920 x 1,080 ב-30fps‏ – ‎10Mbps או 2 מקרים של ‎1,920 x 1,080 ב-60fps‏ – ‎20Mbps).
• ‫[C-1-12] חובה לתמוך ב-HEVC וב-VP9, חובה להיות מסוגל לבצע פענוח ברזולוציה של לפחות ‎1,920 x 1,080‎ ב-30fps עם דחיסה לממוצע של ‎10 Mbps, ורצוי להיות מסוגל לבצע פענוח ברזולוציה של ‎3,840 x 2,160‎ ב-30fps עם דחיסה ל-‎20 Mbps (שווה ערך ל-4 מקרים של ‎1,920 x 1,080‎ ב-30fps עם דחיסה ל-‎5 Mbps).
• ‫[C-1-13] המכשיר חייב לתמוך ב-API‏ HardwarePropertiesManager.getDeviceTemperatures ולהחזיר ערכים מדויקים של טמפרטורת העור.
• ‫[C-1-14] חובה להטמיע מסך, והרזולוציה שלו חייבת להיות לפחות ‎1920 x 1080.
• [C-SR] מומלץ מאוד להשתמש ברזולוציית תצוגה של ‎2560 x 1440 לפחות.
• ‫[C-1-15] התצוגה חייבת להתעדכן בקצב של 60 הרץ לפחות כשהמכשיר במצב VR.
• ‫[C-1-17] המסך חייב לתמוך במצב שימור נמוך עם שימור של ‎≤ 5 מילי-שניות. שימור מוגדר כמשך הזמן שבו פיקסל פולט אור.
• ‫[C-1-18] המכשיר חייב לתמוך ב-Bluetooth 4.2 וב-Bluetooth LE Data Length Extension section 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] מומלץ מאוד לתמוך בסוג הערוץ הישיר TYPE_HARDWARE_BUFFER לכל סוגי הערוצים הישירים שמופיעים למעלה.
• ‫[C-1-21] המכשיר חייב לעמוד בדרישות שקשורות לג'ירוסקופ, למד התאוצה ולמגנטומטר עבור android.hardware.hifi_sensors, כפי שמפורט בסעיף 7.3.9.
• [C-SR] מומלץ מאוד לתמוך בתכונה android.hardware.sensor.hifi_sensors.
• ‫[C-1-22] זמן האחזור הכולל מתנועה לפוטון לא יכול להיות גבוה מ-28 מילישניות.
• ‫[C-SR] מומלץ מאוד שזמן האחזור הכולל מהתנועה ועד לפוטון לא יהיה גבוה מ-20 אלפיות השנייה.
• ‫[C-1-23] חובה שיהיה יחס פריים ראשון, שהוא היחס בין הבהירות של הפיקסלים בפריים הראשון אחרי מעבר משחור ללבן לבין הבהירות של הפיקסלים הלבנים במצב יציב, של 85% לפחות.
• [C-SR] מומלץ מאוד שיהיה יחס של לפחות 90% בין המסגרת הראשונה לבין שאר המסגרות.
• יכול להיות ש-MAY יספק ליבה בלעדית לאפליקציה שפועלת בחזית, ויכול להיות שהוא יתמוך ב-API‏ Process.getExclusiveCores כדי להחזיר את מספרי ליבות ה-CPU שבלעדיות לאפליקציה המובילה שפועלת בחזית.

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

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

‫7.10. מגע

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

‫7.11. סיווג ביצועים של מדיה

אפשר לקבל את סיווג הביצועים של המדיה בהטמעה של המכשיר באמצעות android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS API. הדרישות לסיווג ביצועי המדיה מוגדרות לכל גרסת Android החל מגרסה R‏ (30). הערך המיוחד 0 מציין שהמכשיר לא שייך לסיווג ביצועים של מדיה.

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

• ‫[C-1-1] הפונקציה חייבת להחזיר ערך של android.os.Build.VERSION_CODES.R לפחות.

• [C-1-2] חובה להיות הטמעה של מכשיר שניתן להחזיק ביד.

• ‫[C-1-3] חובה לעמוד בכל הדרישות של 'סיווג ביצועים של מדיה' שמתוארות בקטע 2.2.7.

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

8. ביצועים וצריכת חשמל

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

‫8.1. עקביות בחוויית המשתמש

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

‫8.2. ביצועי גישת קלט/פלט של קבצים

הגדרת בסיס משותף לביצועים עקביים של גישה לקבצים באחסון הנתונים הפרטי של האפליקציה (מחיצת /data) מאפשרת למפתחי אפליקציות להגדיר ציפייה מתאימה שתעזור להם בתכנון התוכנה. הטמעות במכשירים, בהתאם לסוג המכשיר, עשויות לכלול דרישות מסוימות שמתוארות בקטע 2 עבור פעולות הקריאה והכתיבה הבאות:

• ביצועי כתיבה רציפה. הבדיקה מתבצעת על ידי כתיבת קובץ בגודל 256MB באמצעות מאגר זמני לכתיבה בגודל 10MB.
• ביצועים של כתיבה אקראית. הבדיקה מתבצעת על ידי כתיבת קובץ בגודל 256MB באמצעות מאגר כתיבה בגודל 4KB.
• ביצועים של קריאה רציפה. הבדיקה מתבצעת על ידי קריאת קובץ בגודל 256MB באמצעות מאגר כתיבה בגודל 10MB.
• ביצועי קריאה אקראית. הבדיקה מתבצעת על ידי קריאת קובץ בגודל 256MB באמצעות מאגר כתיבה בגודל 4KB.

8.3. מצבי חיסכון באנרגיה

אם הטמעות של מכשירים כוללות תכונות לשיפור ניהול צריכת החשמל במכשיר שנכללות ב-AOSP (למשל, אפליקציה במצב המתנה, נמנום) או מרחיבות את התכונות שלא חלות עליהן הגבלות מחמירות יותר מאלה שחלות על ה-Rare App Standby Bucket, הן:

• ‫[C-1-1] אסור לסטות מההטמעה של AOSP לגבי ההפעלה, התחזוקה, האלגוריתמים של ההוצאה ממצב שינה והשימוש בהגדרות מערכת גלובליות של אפליקציה במצב המתנה ומצבי חיסכון בסוללה של נמנום.
• ‫[C-1-2] אסור לסטות מההטמעה של AOSP לשימוש בהגדרות גלובליות לניהול ההגבלה של משימות, אזעקה ורשת עבור אפליקציות בכל דלי של מצב המתנה של אפליקציות.
• ‫[C-1-3] אסור לסטות מההטמעה של AOSP לגבי מספר הדליים של אפליקציה במצב המתנה שמשמשים למצב המתנה של האפליקציה.
• ‫[C-1-4] חובה להטמיע App Standby Buckets ו-Doze כמו שמתואר בניהול צריכת חשמל.
• ‫[C-1-5] המכשיר חייב להחזיר true עבור PowerManager.isPowerSaveMode() כשהוא במצב חיסכון באנרגיה.
• ‫[C-SR] מומלץ מאוד לספק למשתמשים אפשרות להפעיל ולהשבית את התכונה לחיסכון בסוללה.
• [C-SR] מומלץ מאוד לספק למשתמשים אפשרות להציג את כל האפליקציות שמוחרגות ממצב המתנה של האפליקציה וממצב שינה לחיסכון באנרגיה.

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

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

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

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

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

• ‫[C-2-1] חייב לעמוד בדרישה C-1-1 שלמעלה, או, חייב להיכנס למצב S3 רק כשיישומים של צד שלישי לא צריכים את משאבי המערכת (למשל, המסך, המעבד).

  לעומת זאת, צריך לצאת ממצב S3 כשיישומים של צד שלישי צריכים את משאבי המערכת, כפי שמתואר ב-SDK הזה.

  לדוגמה, אם אפליקציות צד שלישי מבקשות להשאיר את המסך דולק באמצעות FLAG_KEEP_SCREEN_ON או להמשיך להפעיל את המעבד באמצעות PARTIAL_WAKE_LOCK, המכשיר לא יכול להיכנס למצב S3 אלא אם המשתמש ביצע פעולה מפורשת כדי להעביר את המכשיר למצב לא פעיל, כפי שמתואר ב-C-1-1. לעומת זאת, כשתהליך שמיושם על ידי אפליקציות צד שלישי באמצעות JobScheduler מופעל או כששירות העברת ההודעות בענן ב-Firebase מועבר לאפליקציות צד שלישי, המכשיר חייב לצאת ממצב S3, אלא אם המשתמש העביר את המכשיר למצב לא פעיל. אלו לא דוגמאות מקיפות, וב-AOSP מיושמים אותות השכמה רבים שמפעילים השכמה מהמצב הזה.

8.4. חישוב צריכת החשמל

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

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

• [SR] מומלץ מאוד לספק פרופיל צריכת חשמל לכל רכיב שמגדיר את ערך צריכת הזרם לכל רכיב חומרה ואת התרוקנות הסוללה המשוערת שנגרמת על ידי הרכיבים לאורך זמן, כפי שמתואר באתר פרויקט קוד פתוח של Android.
• ‫[SR] מומלץ מאוד לדווח על כל ערכי צריכת החשמל במיליאמפר לשעה (mAh).
• ‫[SR] מומלץ מאוד לדווח על צריכת החשמל של המעבד לכל UID של תהליך. פרויקט הקוד הפתוח של Android עומד בדרישה באמצעות הטמעה של מודול ליבת uid_cputime.
• ‫[SR] מומלץ מאוד להפוך את נתוני צריכת החשמל האלה לזמינים למפתח האפליקציה באמצעות פקודת ה-Shell‏ adb shell dumpsys batterystats.
• צריך לשייך את צריכת החשמל לרכיב החומרה עצמו אם אי אפשר לשייך אותה לאפליקציה.

‫8.5. ביצועים עקביים

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

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

• ‫[C-0-1] חובה לדווח על התמיכה במצב ביצועים רציף בצורה מדויקת באמצעות שיטת ה-API‏ PowerManager.isSustainedPerformanceModeSupported().

• צריכה להיות תמיכה במצב ביצועים רציף.

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

• ‫[C-1-1] המכשיר חייב לספק לאפליקציה המובילה בחזית רמת ביצועים עקבית למשך 30 דקות לפחות, כשהאפליקציה מבקשת זאת.
• ‫[C-1-2] חובה לכבד את API‏ Window.setSustainedPerformanceMode() וממשקי API קשורים אחרים.

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

• מומלץ לספק לפחות ליבת בלעדית אחת שאפשר לשריין לאפליקציה המובילה שבקדמת המסך.

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

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

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

• ‫[C-3-1] חובה להחזיר רשימה ריקה דרך שיטת ה-API ‏Process.getExclusiveCores().

9. תאימות של מודל האבטחה

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

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

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

‫9.1. הרשאות

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

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

• יכול להיות שיוסיפו הרשאות נוספות, בתנאי שמחרוזות מזהי ההרשאות החדשות לא נמצאות במרחב השמות android.\*.

• [C-0-2] הרשאות עם protectionLevel של PROTECTION_FLAG_PRIVILEGED חייבות להינתן רק לאפליקציות שמותקנות מראש בנתיבים בעלי הרשאות מיוחדות בקובץ אימג' של המערכת, ובקבוצת המשנה של ההרשאות שנוספו לרשימת ההיתרים באופן מפורש לכל אפליקציה. ההטמעה של AOSP עומדת בדרישה הזו על ידי קריאה של ההרשאות שנוספו לרשימת ההיתרים לכל אפליקציה מהקבצים בנתיב etc/permissions/, ושימוש בנתיב system/priv-app כנתיב בעל הרשאות מיוחדות.

הרשאות עם רמת הגנה מסוכנת הן הרשאות בזמן ריצה. אפליקציות עם targetSdkVersion > 22 מבקשות אותן בזמן הריצה.

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

• ‫[C-0-3] חובה להציג למשתמש ממשק ייעודי שבו הוא יכול להחליט אם להעניק את ההרשאות המבוקשות בזמן הריצה, וגם לספק למשתמש ממשק לניהול הרשאות בזמן הריצה.
• ‫[C-0-4] חובה להטמיע ממשק משתמש אחד בלבד.
• ‫[C-0-5] אסור להעניק הרשאות בתחילת ההפעלה לאפליקציות שהותקנו מראש, אלא אם:
  • אפשר לקבל את הסכמת המשתמש לפני שהאפליקציה משתמשת בנתונים.
  • ההרשאות שבתחילת ההפעלה משויכות לתבנית של intent שהאפליקציה שהותקנה מראש מוגדרת כ-handler ברירת המחדל שלה.
• ‫[C-0-6] חובה להעניק את ההרשאה android.permission.RECOVER_KEYSTORE רק לאפליקציות מערכת שרושמות סוכן שחזור מאובטח כראוי. סוכן שחזור מאובטח מוגדר כסוכן תוכנה במכשיר שמסתנכרן עם אחסון מרוחק מחוץ למכשיר, שמצויד בחומרה מאובטחת עם הגנה ששווה או חזקה יותר מזו שמתוארת ב-Google Cloud Key Vault Service כדי למנוע מתקפות ברוט פורס על גורם הידע של מסך הנעילה.

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

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

  • מיקום המכשיר (למשל, קו רוחב וקו אורך).
  • מידע שאפשר להשתמש בו כדי לקבוע או להעריך את מיקום המכשיר (למשל SSID,‏ BSSID,‏ Cell ID או מיקום הרשת שהמכשיר מחובר אליה).
  • הפעילות הגופנית של המשתמש או הסיווג של הפעילות הגופנית.

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

• ‫[C-0-8] חובה לקבל את הסכמת המשתמשים כדי לאפשר לאפליקציה לגשת לנתוני המיקום או נתוני הפעילות.
• [C-0-9] חובה להעניק הרשאה בתחילת ההפעלה רק לאפליקציה שמחזיקה בהרשאה מספקת כפי שמתואר ב-SDK. לדוגמה, השיטה TelephonyManager#getServiceState דורשת את ההרשאה android.permission.ACCESS_FINE_LOCATION.

אפשר לסמן הרשאות כמוגבלות כדי לשנות את אופן הפעולה שלהן.

• ‫[C-0-10] אסור להעניק לאפליקציה הרשאות שמסומנות בדגל hardRestricted, אלא אם:

  • קובץ APK של אפליקציה נמצא במחיצת המערכת.
  • המשתמש מקצה לאפליקציה תפקיד שמשויכות אליו הרשאות hardRestricted.
  • תוכנת ההתקנה מעניקה את hardRestricted לאפליקציה.
  • לאפליקציה ניתנה ההרשאה hardRestricted בגרסה קודמת של Android.

• ‫[C-0-11] אפליקציות שמחזיקות בהרשאה softRestricted חייבות לקבל רק גישה מוגבלת, ואסור להן לקבל גישה מלאה עד שהן יתווספו לרשימת ההיתרים כפי שמתואר ב-SDK. גישה מלאה וגישה מוגבלת מוגדרות לכל הרשאה softRestricted (לדוגמה, READ_EXTERNAL_STORAGE).

אם הטמעות של מכשירים מספקות למשתמשים מזמינוּת לבחור אילו אפליקציות יכולות לצייר מעל אפליקציות אחרות באמצעות Activity שמטפלת ב-Intent‏ ACTION_MANAGE_OVERLAY_PERMISSION, הן:

• ‫[C-2-1] חובה לוודא שלכל הפעילויות עם מסנני Intent עבור ה-Intent‏ ACTION_MANAGE_OVERLAY_PERMISSION יש אותו מסך ממשק משתמש, ללא קשר לאפליקציה שמפעילה את ה-Intent או למידע שהיא מספקת.

9.2. ‫UID ובידוד תהליכים

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

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

‫9.3. הרשאות במערכת הקבצים

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

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

9.4. סביבות הפעלה חלופיות

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

• ‫[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] אסור להפעיל סביבות ריצה חלופיות עם ארגזי חול שמתאימים לאפליקציות אחרות ל-Android, או להעניק להן גישה לארגזי חול כאלה או לקבל מהן גישה לארגזי חול כאלה.

• ‫[C-0-6] אסור להפעיל סביבות ריצה חלופיות עם הרשאות של סופר-משתמש (root) או של מזהה משתמש אחר, או להעניק הרשאות כאלה לאפליקציות אחרות.

• ‫[C-0-7] כשקבצי .apk של סביבות ריצה חלופיות נכללים בקובץ אימג' של המערכת של יישומי מכשירים, הם צריכים להיות חתומים במפתח ששונה מהמפתח שמשמש לחתימה על אפליקציות אחרות שנכללות ביישומי המכשירים.

• ‫[C-0-8] כשמתקינים אפליקציות, סביבות ריצה חלופיות חייבות לקבל את הסכמת המשתמש להרשאות Android שבהן נעשה שימוש באפליקציה.

• ‫[C-0-9] כשנדרש שימוש במשאב של מכשיר באפליקציה, שקיימת לו הרשאה תואמת ב-Android (כמו מצלמה, GPS וכו'), סביבת הריצה החלופית חייבת להודיע למשתמש שהאפליקציה תוכל לגשת למשאב הזה.

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

• זמני ריצה חלופיים צריכים להתקין אפליקציות באמצעות PackageManager בארגזי חול נפרדים של Android (מזהי משתמשים ב-Linux וכו').

• סביבות זמן ריצה חלופיות עשויות לספק ארגז חול יחיד של Android שמשותף לכל האפליקציות שמשתמשות בסביבת זמן הריצה החלופית.

‫9.5. תמיכה בכמה משתמשים

‫Android כולל תמיכה בריבוי משתמשים ומספק תמיכה בבידוד מלא של משתמשים.

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

אם יישומי המכשיר כוללים כמה משתמשים, הם:

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

‫9.6. אזהרה לגבי SMS פרימיום

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

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

• ‫[C-1-1] חובה להציג אזהרה למשתמשים לפני שליחת הודעת SMS למספרים שזוהו על ידי ביטויים רגולריים שמוגדרים בקובץ /data/misc/sms/codes.xml במכשיר. ההטמעה שנדרשת כדי לעמוד בדרישה הזו זמינה בפרויקט הקוד הפתוח של Android (AOSP).

‫9.7. אמצעי אבטחה

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

ארגז החול של Android כולל תכונות שמשתמשות במערכת בקרת הגישה (MAC) של Linux עם אבטחה משופרת (SELinux), בארגז חול של seccomp ובתכונות אבטחה אחרות בליבת Linux. הטמעות במכשיר:

• ‫[C-0-1] חובה לשמור על תאימות לאפליקציות קיימות, גם כשמטמיעים SELinux או תכונות אבטחה אחרות מתחת למסגרת Android.
• ‫[C-0-2] אסור שיהיה ממשק משתמש גלוי כשמתגלה הפרת אבטחה שנחסמת בהצלחה על ידי תכונת האבטחה שהוטמעה מתחת למסגרת Android, אבל יכול להיות ממשק משתמש גלוי כשמתרחשת הפרת אבטחה שלא נחסמת ומובילה לניצול לרעה מוצלח.
• ‫[C-0-3] אסור לאפשר למשתמש או למפתח האפליקציה להגדיר את SELinux או תכונות אבטחה אחרות שמוטמעות מתחת למסגרת Android.
• ‫[C-0-4] אסור לאפשר לאפליקציה שיכולה להשפיע על אפליקציה אחרת באמצעות API (כמו Device Administration API) להגדיר מדיניות שפוגעת בתאימות.
• ‫[C-0-5] חובה לפצל את מסגרת המדיה למספר תהליכים, כדי לאפשר הענקת גישה מצומצמת יותר לכל תהליך, כפי שמתואר באתר פרויקט קוד פתוח של Android.
• ‫[C-0-6] חובה להטמיע מנגנון ארגז חול לאפליקציות של ליבת מערכת ההפעלה, שמאפשר סינון של קריאות למערכת באמצעות מדיניות שניתנת להגדרה מתוכניות מרובות-הליכים. פרויקט קוד פתוח של Android (AOSP) עומד בדרישה הזו באמצעות הפעלת seccomp-BPF עם סנכרון של קבוצת השרשורים (TSYNC), כפי שמתואר בקטע בנושא הגדרת ליבת המערכת ב-source.android.com.

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

• ‫[C-0-7] חובה להטמיע מנגנונים להגנה מפני גלישת חוצץ במחסנית של הליבה. דוגמאות למנגנונים כאלה הן CC_STACKPROTECTOR_REGULAR ו-CONFIG_CC_STACKPROTECTOR_STRONG.
• ‫[C-0-8] חובה להטמיע אמצעי הגנה מחמירים על זיכרון הליבה, כך שקוד הפעלה יהיה לקריאה בלבד, נתונים לקריאה בלבד לא יהיו ניתנים להפעלה או לכתיבה, ונתונים שניתנים לכתיבה לא יהיו ניתנים להפעלה (לדוגמה, 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] אסור לקרוא או לכתוב בזיכרון של מרחב המשתמשים בקרנל מחוץ לממשקי API רגילים של גישה להעתקת משתמשים (למשל, PAN של חומרה או הדמיה באמצעות CONFIG_CPU_SW_DOMAIN_PAN או CONFIG_ARM64_SW_TTBR0_PAN) במכשירים שנשלחים במקור עם רמת API 28 ומעלה.
• ‫[C-0-12] חובה להטמיע בידוד של טבלת דפי ליבה אם החומרה פגיעה ל-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).
• [SR] מומלץ מאוד לשמור את נתוני הליבה שנכתבים רק במהלך האתחול, ולסמן אותם כקריאה בלבד אחרי האתחול (למשל __ro_after_init).

• [C-SR] מומלץ מאוד לבצע רנדומיזציה של הפריסה של קוד הליבה והזיכרון, ולהימנע מחשיפות שיפגעו ברנדומיזציה (למשל, CONFIG_RANDOMIZE_BASE עם אנטרופיה של טוען האתחול באמצעות /chosen/kaslr-seed Device Tree node או EFI_RNG_PROTOCOL).

• [C-SR] מומלץ מאוד להפעיל את התכונה 'שלמות זרימת הבקרה' (CFI) בליבת מערכת ההפעלה כדי לספק הגנה נוספת מפני התקפות של שימוש חוזר בקוד (למשל, CONFIG_CFI_CLANG ו-CONFIG_SHADOW_CALL_STACK).

• ‫[C-SR] מומלץ מאוד לא להשבית את התכונות Control-Flow Integrity (CFI), ‏ Shadow Call Stack (SCS) או Integer Overflow Sanitization (IntSan) ברכיבים שהן מופעלות בהם.
• ‫[C-SR] מומלץ מאוד להפעיל CFI, ‏ SCS ו-IntSan לכל רכיבי מרחב המשתמשים הנוספים שרגישים לאבטחה, כפי שמוסבר במאמרים בנושא CFI ו-IntSan.
• ‫[C-SR] מומלץ מאוד להפעיל אתחול של המחסנית בקרנל כדי למנוע שימוש במשתנים מקומיים לא מאותחלים (CONFIG_INIT_STACK_ALL או CONFIG_INIT_STACK_ALL_ZERO). בנוסף, הטמעות של מכשירים לא אמורות להניח את הערך שבו הקומפיילר משתמש כדי לאתחל את המשתנים המקומיים.
• [C-SR] מומלץ מאוד להפעיל אתחול של ערימה בקרנל כדי למנוע שימוש בהקצאות של ערימה לא מאותחלת (CONFIG_INIT_ON_ALLOC_DEFAULT_ON), ואין להניח את הערך שבו הקרנל משתמש כדי לאתחל את ההקצאות האלה.

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

• ‫[C-1-1] חובה להטמיע SELinux.
• ‫[C-1-2] חובה להגדיר את SELinux למצב אכיפה גלובלי.
• ‫[C-1-3] חובה להגדיר את כל הדומיינים במצב אכיפה. אסור להשתמש בדומיינים במצב הרשאה, כולל דומיינים שספציפיים למכשיר או לספק.
• ‫[C-1-4] אסור לשנות, להשמיט או להחליף את כללי neverallow שקיימים בתיקיית system/sepolicy שסופקה בפרויקט הקוד הפתוח של Android‏ (AOSP) מסוג upstream, והמדיניות חייבת לעבור קומפילציה עם כל כללי neverallow שקיימים, גם בדומיינים של AOSP SELinux וגם בדומיינים ספציפיים למכשיר או לספק.
• ‫[C-1-5] חובה להפעיל אפליקציות של צד שלישי שמיועדות לרמת API 28 ומעלה בארגזי חול של SELinux לכל אפליקציה, עם הגבלות SELinux לכל אפליקציה בספריית הנתונים הפרטיים של כל אפליקציה.
• מומלץ לשמור על מדיניות SELinux שמוגדרת כברירת מחדל ומסופקת בתיקייה system/sepolicy של פרויקט הקוד הפתוח של Android (AOSP), ולהוסיף למדיניות הזו רק את ההגדרות הספציפיות למכשיר.

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

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

• ‫[C-2-1] חובה להשתמש במערכת בקרת גישה מחייבת ששווה ל-SELinux.

‫Android כולל כמה תכונות הגנה מקיפות שחיוניות לאבטחת המכשיר.

‫9.8. פרטיות

‫9.8.1. היסטוריית השימוש

‫Android שומרת את היסטוריית הבחירות של המשתמש ומנהלת את ההיסטוריה הזו באמצעות UsageStatsManager.

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

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

מערכת Android מאחסנת את אירועי המערכת באמצעות המזהים StatsLog, ומנהלת את ההיסטוריה הזו באמצעות StatsManager ו-System API‏ IncidentManager.

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

• ‫[C-0-2] צריך לכלול רק את השדות שמסומנים ב-DEST_AUTOMATIC בדוח האירוע שנוצר על ידי מחלקת System API‏ IncidentManager.
• ‫[C-0-3] אסור להשתמש במזהי אירועי המערכת כדי לרשום ביומן אירועים אחרים מלבד אלה שמתוארים במסמכי ה-SDK של StatsLog. אם מתבצע רישום של אירועי מערכת נוספים, יכול להיות שהם ישתמשו במזהה אטום אחר בטווח שבין 100,000 ל-200,000.

‫9.8.2. מתבצעת הקלטה

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

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

אם הטמעות של מכשירים כוללות פונקציונליות במערכת שמאפשרת לצלם את התוכן שמוצג במסך ו/או להקליט את זרם האודיו שמופעל במכשיר, שלא באמצעות System API‏ ContentCaptureService או אמצעים קנייניים אחרים שמתוארים בקטע 9.8.6 צילום תוכן, הן:

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

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

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

‫9.8.3. קישוריות

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

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

‫9.8.4. תנועה ברשת

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

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

אם התנועה במכשיר מנותבת דרך 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 (International Mobile Subscriber Identity) מאפליקציה, אלא אם היא עומדת באחת מהדרישות הבאות:
  • היא אפליקציה חתומה של ספק סלולר שאומתה על ידי יצרני מכשירים.
  • קיבל את ההרשאה READ_PRIVILEGED_PHONE_STATE.
  • יש לו הרשאות ספק כפי שמוגדרות במאמר הרשאות ספק ב-UICC.
  • הוא בעל מכשיר או בעל פרופיל שקיבל את ההרשאה READ_PHONE_STATE.
  • (למספר סידורי של כרטיס SIM או ל-ICCID בלבד) יש דרישה בתקנות המקומיות שהאפליקציה תזהה שינויים בזהות המנוי.

‫9.8.6. תיעוד תוכן

מערכת Android, באמצעות System API‏ ContentCaptureService, או באמצעים קנייניים אחרים, תומכת במנגנון להטמעות במכשירים כדי לתעד את האינטראקציות הבאות בין האפליקציות לבין המשתמש.

• טקסט וגרפיקה שמוצגים במסך, כולל, בין היתר, התראות ונתוני סיוע באמצעות AssistStructure API.
• נתוני מדיה, כמו אודיו או סרטון, שהוקלטו או הופעלו במכשיר.
• אירועי קלט (למשל מקלדת, עכבר, תנועה, קול, וידאו ונגישות).
• כל אירוע אחר שאפליקציה מספקת למערכת באמצעות Content Capture API או API קנייני עם יכולות דומות.
• כל טקסט או נתונים אחרים שנשלחים דרך TextClassifier API אל TextClassifier של המערכת, כלומר אל שירות המערכת, כדי להבין את המשמעות של הטקסט, וגם כדי ליצור פעולות צפויות הבאות על סמך הטקסט.

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

• ‫[C-1-1] חובה להצפין את כל הנתונים האלה כשהם מאוחסנים במכשיר. ההצפנה הזו יכולה להתבצע באמצעות הצפנה מבוססת-קובץ של Android, או באמצעות כל אחת מההצפנות שמופיעות כגרסה 26 ומעלה של API, כפי שמתואר ב-Cipher SDK.
• ‫[C-1-2] אסור לגבות נתונים גולמיים או מוצפנים באמצעות שיטות גיבוי של Android או שיטות גיבוי אחרות.
• ‫[C-1-3] חובה לשלוח את כל הנתונים האלה ואת היומן של המכשיר רק באמצעות מנגנון לשמירה על הפרטיות. המנגנון לשמירה על הפרטיות מוגדר כ"מנגנון שמאפשר ניתוח רק ברמת הצבירה ומונע התאמה בין אירועים שנרשמו ביומן או תוצאות נגזרות לבין משתמשים ספציפיים", כדי למנוע בדיקה של נתונים ברמת המשתמש (למשל, מנגנון שמיושם באמצעות טכנולוגיה של פרטיות דיפרנציאלית כמו RAPPOR).
• ‫[C-1-4] אסור לשייך נתונים כאלה לזהות של משתמש (למשל Account) במכשיר, אלא אם התקבל מהמשתמש הסכמה מהמשתמש בכל פעם שהנתונים משויכים.
• ‫[C-1-5] אסור לשתף נתונים כאלה עם אפליקציות אחרות, אלא אם מתקבלת הסכמה מפורשת מהמשתמש בכל פעם שהנתונים משותפים.
• ‫[C-1-6] חובה לספק למשתמשים אפשרות למחוק נתונים כאלה שנאספים על ידי ContentCaptureService או באמצעים קנייניים, אם הנתונים מאוחסנים במכשיר בכל צורה שהיא.

אם הטמעות המכשיר כוללות שירות שמטמיע את System API‏ ContentCaptureService, או שירות קנייני כלשהו שתופס את הנתונים כפי שמתואר למעלה, הן:

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

• ‫[C-SR] מומלץ מאוד להפריד בין רכיבי שירות לכידת התוכן, למשל לא לקשור את השירות או לשתף מזהי תהליכים, מרכיבי מערכת אחרים, למעט:

  • שיחות טלפון, אנשי קשר, ממשק משתמש של המערכת ומדיה

‫9.8.7. גישה ללוח

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

• ‫[C-0-1] אסור להחזיר נתונים חלקיים בלוח (למשל באמצעות ClipboardManager API) אלא אם האפליקציה היא ה-IME שמוגדר כברירת מחדל או האפליקציה שמוצגת כרגע.

‫9.8.8. מיקום

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

• ‫[C-0-1] אסור להפעיל או להשבית את הגדרת המיקום של המכשיר ואת הגדרות הסריקה של Wi-Fi או סריקת Bluetooth ללא הסכמה מהמשתמש או ללא פעולה של המשתמש.
• ‫[C-0-2] חובה לספק למשתמש אפשרות גישה למידע שקשור למיקום, כולל בקשות מיקום אחרונות, הרשאות ברמת האפליקציה ושימוש בסריקת Wi-Fi/Bluetooth לקביעת מיקום.
• ‫[C-0-3] חובה לוודא שהאפליקציה שמשתמשת ב-Emergency Location Bypass API ‏[LocationRequest.setLocationSettingsIgnored()] היא סשן חירום שהמשתמש יזם (למשל, חיוג ל-911 או שליחת הודעת טקסט ל-911). עם זאת, במערכות Automotive, רכב עשוי ליזום סשן חירום ללא אינטראקציה פעילה של המשתמש במקרה של זיהוי התנגשות או תאונה (למשל, כדי לעמוד בדרישות של eCall).
• ‫[C-0-4] חובה לשמור על היכולת של Emergency Location Bypass API לעקוף את הגדרות המיקום של המכשיר בלי לשנות את ההגדרות.
• ‫[C-0-5] חובה לתזמן התראה שמזכירה למשתמש שאפליקציה ברקע ניגשה למיקום שלו באמצעות ההרשאה [ACCESS_BACKGROUND_LOCATION].

‫9.8.9. אפליקציות מותקנות

אפליקציות ל-Android שמטרגטות לרמת API‏ 30 ומעלה לא יכולות לראות פרטים על אפליקציות מותקנות אחרות כברירת מחדל (ראו Package visibility במסמכי ה-Android SDK).

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

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

‫9.8.10. דוח על באג בקישוריות

אם הטמעות של מכשירים יוצרות דוחות על באגים באמצעות System API‏ BUGREPORT_MODE_TELEPHONY עם BugreportManager, הן:

• ‫[C-1-1] חובה לקבל הסכמה מהמשתמש בכל פעם שמתבצעת קריאה ל-System API‏ BUGREPORT_MODE_TELEPHONY כדי ליצור דוח, ואסור להציג למשתמש בקשה להסכמה לכל הבקשות העתידיות מהאפליקציה.
• ‫[C-1-2] חובה להציג בקשה להסכמה מפורשת מהמשתמש ולקבל את הסכמתו לפני התחלת יצירת הדוחות, ואסור להחזיר את הדוח שנוצר לאפליקציה ששלחה את הבקשה בלי הסכמה מפורשת מהמשתמש.
• ‫[C-1-3] חובה ליצור דוחות לפי בקשה, שמכילים לפחות את המידע הבא:
  • פלט של TelephonyDebugService
  • TelephonyRegistry dump
  • פלט של WifiService
  • פלט של ConnectivityService
  • עותק של המופע CarrierService של חבילת השיחות (אם הוא מאוגד)
  • מאגר נתונים זמני של יומן הרדיו
• ‫[C-1-4] אסור לכלול את הפריטים הבאים בדוחות שנוצרו:
  • כל סוג של מידע שלא קשור לניפוי באגים בקישוריות.
  • יומני תנועה של אפליקציות שהמשתמשים התקינו או פרופילים מפורטים של אפליקציות/חבילות שהמשתמשים התקינו (מזהי משתמשים (UID) הם בסדר, שמות חבילות לא).
• יכול לכלול מידע נוסף שלא משויך לזהות של משתמש כלשהו. (לדוגמה, יומני ספקים).

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

• ‫[C-SR] מומלץ מאוד להגדיר את הגדרת המפתח כהגדרה מושבתת כברירת מחדל. ב-AOSP, האפשרות הזו קיימת בהגדרות למפתחים: Enable verbose vendor logging. היא מאפשרת לכלול בדוחות על באגים רישומי יומן של ספקים למכשירים ספציפיים.

‫9.8.11. שיתוף של נתוני Blob

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

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

• ‫[C-1-1] אסור לשתף נתוני Blob ששייכים לאפליקציות מעבר למה שהן התכוונו לאפשר (כלומר, היקף גישת ברירת המחדל ומצבי הגישה האחרים שאפשר לציין באמצעות BlobStoreManager.session#allowPackageAccess()‎, ‏ BlobStoreManager.session#allowSameSignatureAccess()‎ או BlobStoreManager.session#allowPublicAccess()‎ אסור לשנות). ההטמעה לדוגמה של AOSP עומדת בדרישות האלה.
• ‫[C-1-2] אסור לשלוח מהמכשיר או לשתף עם אפליקציות אחרות את הגיבובים המאובטחים של בלובים של נתונים (שמשמשים לשליטה בגישה).

‫9.9. הצפנה של אחסון נתונים

כל המכשירים חייבים לעמוד בדרישות של סעיף 9.9.1. מכשירים שהושקו ברמת API מוקדמת יותר מזו שמופיעה במסמך הזה פטורים מהדרישות של סעיפים 9.9.2 ו-9.9.3. במקום זאת, הם צריכים לעמוד בדרישות של סעיף 9.9 במסמך Android Compatibility Definition שמתאים לרמת ה-API שבה הושק המכשיר.

‫9.9.1. אתחול ישיר

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

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

• ‫[C-0-2] עדיין צריך לשדר את Intents‏ ACTION_LOCKED_BOOT_COMPLETED ו-ACTION_USER_UNLOCKED כדי לסמן לאפליקציות שמודעות ל-Direct Boot שמיקומי האחסון Device Encrypted‏ (DE) ו-Credential Encrypted‏ (CE) זמינים למשתמש.

‫9.9.2. דרישות הצפנה

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

• ‫[C-0-1] חובה להצפין את הנתונים הפרטיים של האפליקציה (מחיצת /data), וגם את מחיצת האחסון המשותף של האפליקציה (מחיצת /sdcard) אם היא חלק קבוע שלא ניתן להסרה מהמכשיר.
• ‫[C-0-2] חובה להפעיל את הצפנת אחסון הנתונים כברירת מחדל ברגע שהמשתמש משלים את חוויית ההגדרה הראשונית.

• ‫[C-0-3] חובה לעמוד בדרישה להצפנת נתוני האחסון שצוינה למעלה באמצעות הטמעה של אחת משתי שיטות ההצפנה הבאות:

  • הצפנה מבוססת קבצים (FBE) והצפנת מטא-נתונים כפי שמתואר בסעיף 9.9.3.1.
  • הצפנה ברמת הבלוק לכל משתמש, כפי שמתואר בקטע 9.9.3.2.

‫9.9.3. שיטות הצפנה

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

• ‫[C-1-1] המכשיר חייב לבצע אתחול בלי לבקש מהמשתמש פרטי כניסה, ולאפשר לאפליקציות שתומכות ב-Direct Boot לגשת לאחסון Device Encrypted‏ (DE) אחרי שידור ההודעה ACTION_LOCKED_BOOT_COMPLETED.
• ‫[C-1-2] חובה לאפשר גישה לאחסון Credential Encrypted‏ (CE) רק אחרי שהמשתמש פותח את נעילת המכשיר על ידי הזנת פרטי הכניסה שלו (למשל, קוד גישה, קוד אימות, קו ביטול נעילה או טביעת אצבע) וההודעה ACTION_USER_UNLOCKED משודרת.
• ‫[C-1-13] אסור להציע שיטה כלשהי לפתיחת הנעילה של האחסון המוגן באמצעות CE ללא פרטי הכניסה שהמשתמש סיפק, מפתח נאמנות רשום או יישום של חידוש ההפעלה לאחר אתחול שעומד בדרישות שבסעיף 9.9.4.
• ‫[C-1-4] חובה להשתמש בהפעלה מאומתת.

‫9.9.3.1. הצפנה מבוססת-קבצים עם הצפנת מטא-נתונים

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

• ‫[C-1-5] חובה להצפין את תוכן הקובץ ואת המטא-נתונים של מערכת הקבצים באמצעות AES-256-XTS או Adiantum. ‫AES-256-XTS מתייחס לתקן הצפנה מתקדם עם אורך מפתח הצפנה של 256 ביט, שפועל במצב XTS. האורך המלא של המפתח הוא 512 ביט. ‫Adiantum מתייחס ל-Adiantum-XChaCha12-AES, כפי שמפורט בכתובת https://github.com/google/adiantum. מטא-נתונים של מערכת קבצים הם נתונים כמו גודל קבצים, בעלות, מצבים ומאפיינים מורחבים (xattrs).
• ‫[C-1-6] חובה להצפין שמות של קבצים באמצעות AES-256-CBC-CTS או Adiantum.
• ‫[C-1-12] אם למכשיר יש הוראות Advanced Encryption Standard ‏ (AES)‏ (כמו ARMv8 Cryptography Extensions במכשירים מבוססי ARM, או AES-NI במכשירים מבוססי x86), חובה להשתמש באפשרויות מבוססות AES שצוינו למעלה להצפנת שם הקובץ, תוכן הקובץ ומטא-נתונים של מערכת הקבצים, ולא ב-Adiantum.
• ‫[C-1-13] חובה להשתמש בפונקציית נגזרת של מפתח (KDF) חזקה מבחינה קריפטוגרפית ובלתי הפיכה (למשל HKDF-SHA512) כדי להפיק את כל מפתחות המשנה הנדרשים (למשל מפתחות לכל קובץ) ממפתחות ה-CE וה-DE. 'חזק מבחינה קריפטוגרפית ולא ניתן להמרה' פירושו שפונקציית הנגזרת של המפתח כוללת חוזק אבטחה של לפחות 256 ביט ומתנהגת כמשפחה של פונקציות פסאודו-אקראיות על הקלט שלה.

• ‫[C-1-14] אסור להשתמש באותם מפתחות או מפתחות משנה של הצפנה מבוססת-קבצים (FBE) למטרות קריפטוגרפיות שונות (למשל, גם להצפנה וגם לגזירת מפתחות, או לשני אלגוריתמים שונים להצפנה).

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

• ‫[C-1-7] חובה לקשור באופן קריפטוגרפי למאגר מפתחות שמגובה בחומרה. מאגר המפתחות הזה חייב להיות קשור להפעלה מאומתת ול-Root of Trust של החומרה במכשיר.

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

• ‫[C-1-11] חובה להשתמש בצפנים, באורכי מפתחות ובמצבים הנתמכים.

• מומלץ להפוך אפליקציות חיוניות שמותקנות מראש (למשל, שעון מעורר, טלפון, Messenger) לתואמות להפעלה ישירה.

פרויקט הקוד הפתוח של Android מספק הטמעה מועדפת של הצפנה מבוססת-קובץ שמבוססת על תכונת ההצפנה fscrypt של ליבת Linux, ושל הצפנת מטא-נתונים שמבוססת על התכונה dm-default-key של ליבת Linux.

‫9.9.3.2. הצפנה ברמת הבלוק לכל משתמש

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

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

• ‫[C-1-4] חובה להשתמש ב-AES-256-XTS להצפנה ברמת הבלוק של מחיצות המשתמש.

• המפתחות שמגנים על מכשירים מוצפנים ברמת הבלוק לכל משתמש:

• ‫[C-1-5] חייב להיות קשור באופן קריפטוגרפי למאגר מפתחות שמגובה בחומרה. מאגר המפתחות הזה חייב להיות קשור להפעלה מאומתת ול-Root of Trust של החומרה במכשיר.

• ‫[C-1-6] חובה לקשר את האישורים לפרטי הכניסה של המשתמש במסך הנעילה.

אפשר להטמיע הצפנה ברמת הבלוק לכל משתמש באמצעות התכונה dm-crypt של ליבת Linux במחיצות לכל משתמש.

‫9.9.4. המשך הפעלה מחדש

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

הטמעה של Resume-on-Reboot חייבת להמשיך להבטיח שאם מכשיר נופל לידי תוקף, יהיה לו קשה מאוד לשחזר את הנתונים המוצפנים ב-CE של המשתמש, גם אם המכשיר מופעל, האחסון ב-CE לא נעול והמשתמש ביטל את הנעילה של המכשיר אחרי קבלת OTA. כדי להתמודד עם מתקפות מבפנים, אנחנו מניחים גם שהתוקף משיג גישה למפתחות קריפטוגרפיים לחתימה על שידורים.

פרטים נוספים:

• ‫[C-0-1] אסור לאחסון CE להיות קריא, גם לתוקף שיש לו את המכשיר פיזית, וגם אם יש לו את היכולות והמגבלות הבאות:

  • יכול להשתמש במפתח החתימה של כל ספק או חברה כדי לחתום על הודעות שרירותיות.
  • יכול לגרום לקבלת עדכון OTA במכשיר.
  • יכול לשנות את הפעולה של כל רכיב חומרה (AP, פלאש וכו') למעט כפי שמפורט בהמשך, אבל שינוי כזה כרוך בעיכוב של שעה לפחות ובהפעלה מחדש שמשמידה את התוכן של ה-RAM.
  • אי אפשר לשנות את הפעולה של חומרה עמידה בפני חדירה (למשל Titan M).
  • אי אפשר לקרוא את ה-RAM של המכשיר הפעיל.
  • לא ניתן להשיג את פרטי הכניסה של המשתמש (קוד אימות, קו ביטול נעילה, סיסמה) או לגרום להזנתם.

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

‫9.10. תקינות המכשיר

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

• ‫[C-0-1] חובה לדווח בצורה נכונה באמצעות השיטה PersistentDataBlockManager.getFlashLockState() של System API אם מצב טוען האתחול מאפשר צריבה של קובץ האימג' של המערכת. הסטטוס FLASH_LOCK_UNKNOWN שמור להטמעות של מכשירים שמשדרגים מגרסה קודמת של Android שבה לא הייתה קיימת שיטת ה-API החדשה הזו של המערכת.

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

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

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

• ‫[C-1-1] חובה להצהיר על דגל התכונה של הפלטפורמה android.software.verified_boot.
• ‫[C-1-2] חובה לבצע אימות בכל רצף הפעלה.
• ‫[C-1-3] חובה להתחיל את האימות ממפתח חומרה בלתי ניתן לשינוי שהוא Root of Trust, ולהמשיך עד למחיצת המערכת.
• ‫[C-1-4] חובה להטמיע כל שלב באימות כדי לבדוק את השלמות והאותנטיות של כל הבייטים בשלב הבא לפני שמריצים את הקוד בשלב הבא.
• ‫[C-1-5] חובה להשתמש באלגוריתמים חזקים לאימות, בהתאם להמלצות הנוכחיות של NIST לגבי אלגוריתמים לגיבוב (SHA-256) וגדלים של מפתחות ציבוריים (RSA-2048).
• ‫[C-1-6] אסור לאפשר אתחול אם אימות המערכת נכשל, אלא אם המשתמש מסכים לנסות לאתחל בכל זאת. במקרה כזה, אסור להשתמש בנתונים מבלוקים של אחסון שלא אומתו.
• ‫[C-1-7] אסור לאפשר שינוי של מחיצות מאומתות במכשיר, אלא אם המשתמש ביטל את הנעילה של טוען האתחול באופן מפורש.
• ‫[C-SR] אם יש במכשיר כמה שבבים נפרדים (למשל, רדיו, מעבד תמונות ייעודי), מומלץ מאוד לאמת כל שלב בתהליך האתחול של כל אחד מהשבבים האלה.
• ‫[C-1-8] חובה להשתמש באחסון שמונע שינויים לא מורשים: לאחסון המידע אם תוכנת האתחול פתוחה. אחסון עם הוכחה לשינוי לא מורשה פירושו שטוען האתחול יכול לזהות אם בוצעו שינויים לא מורשים באחסון מתוך Android.
• ‫[C-1-9] המערכת חייבת להציג למשתמש הנחיה בזמן השימוש במכשיר, ולדרוש אישור פיזי לפני המעבר ממצב נעילת תוכנת האתחול למצב ביטול הנעילה של תוכנת האתחול.
• ‫[C-1-10] חובה להטמיע הגנה מפני חזרה לגרסה קודמת עבור מחיצות שמשמשות את Android (למשל, מחיצות אתחול ומערכת) ולהשתמש באחסון עם הוכחה לשינוי לא מורשה כדי לאחסן את המטא-נתונים שמשמשים לקביעת גרסת מערכת ההפעלה המינימלית המותרת.
• [C-SR] מומלץ מאוד לאמת את כל קובצי ה-APK של אפליקציות עם הרשאות מיוחדות באמצעות שרשרת מהימנות שמושרשת במחיצות שמוגנות על ידי אתחול מאומת.
• [C-SR] מומלץ מאוד לאמת כל ארטיפקט הפעלה שנטען על ידי אפליקציה עם הרשאות מחוץ לקובץ ה-APK שלה (כמו קוד שנטען באופן דינמי או קוד שעבר קומפילציה) לפני שמבצעים אותו, או מומלץ מאוד לא לבצע אותו בכלל.
• מומלץ להטמיע הגנה מפני חזרה לגרסה קודמת לכל רכיב עם קושחה מתמשכת (למשל, מודם, מצלמה) ומומלץ להשתמש באחסון עם סימני פתיחה כדי לאחסן את המטא-נתונים שמשמשים לקביעת הגרסה המינימלית המותרת.

אם הטמעות המכשירים כבר הושקו בלי תמיכה בדרישות C-1-8 עד C-1-10 בגרסה קודמת של Android, ואי אפשר להוסיף תמיכה בדרישות האלה באמצעות עדכון תוכנת מערכת, יכול להיות שיהיה פטור מהדרישות.

ב-Android Open Source Project (פרויקט קוד פתוח של Android) יש הטמעה מועדפת של התכונה הזו במאגר external/avb/, שאפשר לשלב אותה בתוכנת האתחול שמשמשת לטעינת Android.

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

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

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

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

• [C-R] מומלץ לתמוך ב-Android Protected Confirmation API.

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

• ‫[C-3-1] חובה לדווח על true עבור ConfirmationPrompt.isSupported() API.

• ‫[C-3-2] חובה לוודא שקוד שפועל ב-Android OS, כולל הליבה שלה, זדוני או אחר, לא יכול ליצור תגובה חיובית ללא אינטראקציה עם המשתמש.

• ‫[C-3-3] חובה לוודא שהמשתמש יכול לבדוק ולאשר את ההודעה שמוצגת לו, גם אם מערכת ההפעלה Android, כולל ליבת המערכת, נפגעה.

‫9.11. מפתחות ופרטי כניסה

מערכת Android Keystore מאפשרת למפתחי אפליקציות לאחסן מפתחות קריפטוגרפיים במאגר ולהשתמש בהם בפעולות קריפטוגרפיות באמצעות KeyChain API או Keystore API. הטמעות במכשיר:

• ‫[C-0-1] המערכת חייבת לאפשר ייבוא או יצירה של לפחות 8,192 מפתחות.
• [C-0-2] האימות במסך הנעילה חייב להגביל את מספר הניסיונות, וחייב לכלול אלגוריתם של השהיה מעריכית לפני ניסיון חוזר (exponential backoff). אם יש יותר מ-150 ניסיונות כושלים, העיכוב חייב להיות לפחות 24 שעות לכל ניסיון.
• לא צריכה להיות הגבלה על מספר המפתחות שאפשר ליצור

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

• ‫[C-1-1] חובה לגבות את ההטמעה של מאגר המפתחות באמצעות סביבת הפעלה מבודדת.
• ‫[C-1-2] חובה להטמיע אלגוריתמים קריפטוגרפיים מסוג RSA,‏ AES,‏ ECDSA ו-HMAC ופונקציות גיבוב מסוג MD5,‏ SHA1 ו-SHA-2 כדי לתמוך בצורה תקינה באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בקרנל ומעליו. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד של ליבה או של מרחב משתמשים יכול לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. פרויקט הקוד הפתוח של Android‏ (AOSP) עומד בדרישה הזו באמצעות ההטמעה של Trusty, אבל אפשרות חלופית היא פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת שנבדקה על ידי צד שלישי של בידוד מתאים שמבוסס על היפר-ויז'ר.
• ‫[C-1-3] חובה לבצע את האימות במסך הנעילה בסביבת הביצוע המבודדת, ורק אם האימות מצליח, לאפשר שימוש במפתחות שקשורים לאימות. פרטי הכניסה למסך הנעילה חייבים להיות מאוחסנים באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. פרויקט הקוד הפתוח של Android מספק את שכבת ההפשטה של חומרה (HAL) של Gatekeeper ואת Trusty, שאפשר להשתמש בהם כדי לעמוד בדרישה הזו.
• ‫[C-1-4] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה של האימות מוגן על ידי חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה של האימות במספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת הדרכים לעמוד בדרישה הזו היא לשתף את אותו מפתח אישור, אלא אם מיוצרות לפחות 100,000 יחידות של מק"ט נתון. אם מיוצרות יותר מ-100,000 יחידות של מק"ט מסוים, אפשר להשתמש במפתח אחר לכל 100,000 יחידות.

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

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

‫9.11.1. מסך נעילה מאובטח ואימות

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

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

• ‫[C-SR] מומלץ מאוד להגדיר רק אחת מהשיטות הבאות כשיטת האימות הראשית:
  • קוד אימות מספרי
  • סיסמה אלפאנומרית
  • דפוס החלקה ברשת של 3x3 נקודות בדיוק

שימו לב: שיטות האימות שצוינו למעלה הן שיטות האימות העיקריות המומלצות שמוזכרות במסמך הזה.

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

• ‫[C-2-1] חייבת להיות שיטת אימות המשתמש כפי שמתואר במאמר דרישת אימות משתמש לשימוש במפתח.

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

• ‫[C-3-1] האנטרופיה של האורך הקצר ביותר המותר של קלט חייבת להיות גדולה מ-10 ביט.
• ‫[C-3-2] האנטרופיה המקסימלית של כל הקלטים האפשריים חייבת להיות גדולה מ-18 ביט.
• ‫[C-3-3] שיטת האימות החדשה לא יכולה להחליף אף אחת משיטות האימות העיקריות המומלצות (כלומר קוד אימות, קו פתיחת נעילה, סיסמה) שהוטמעו וסופקו ב-AOSP.
• ‫[C-3-4] צריך להשבית את שיטת האימות החדשה כשאפליקציית בקר מדיניות המכשיר (DPC) מגדירה את מדיניות איכות הסיסמה באמצעות השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_SOMETHING.
• ‫[C-3-5] שיטות אימות חדשות צריכות לחזור לשיטות האימות העיקריות המומלצות (כלומר, קוד אימות, תבנית, סיסמה) אחת ל-72 שעות או פחות, או לחלופין, להבהיר למשתמש שחלק מהנתונים לא יגובו כדי לשמור על הפרטיות של הנתונים שלו.

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

• ‫[C-4-1] חובה לעמוד בכל הדרישות שמתוארות בקטע 7.3.10 עבור Class 1 (לשעבר Convenience).
• ‫[C-4-2] חובה להשתמש במנגנון חלופי כדי להשתמש באחת משיטות האימות הראשיות המומלצות שמבוססות על סוד ידוע.
• ‫[C-4-3] חובה להשבית את האפשרות הזו ולאפשר רק את שיטת האימות העיקרית המומלצת לביטול הנעילה של המסך , כשאפליקציית Device Policy Controller‏ (DPC) הגדירה את מדיניות התכונות של Keyguard באמצעות קריאה לשיטה DevicePolicyManager.setKeyguardDisabledFeatures(), עם אחד מהדגלים הביומטריים המשויכים (כלומר KEYGUARD_DISABLE_BIOMETRICS, ‏ KEYGUARD_DISABLE_FINGERPRINT, ‏ KEYGUARD_DISABLE_FACE או KEYGUARD_DISABLE_IRIS).

אם שיטות האימות הביומטרי לא עומדות בדרישות של סיווג 3 (לשעבר חזק) כפי שמתואר בקטע 7.3.10:

• ‫[C-5-1] צריך להשבית את השיטות האלה אם אפליקציית Device Policy Controller‏ (DPC) הגדירה את מדיניות איכות הסיסמה באמצעות השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_BIOMETRIC_WEAK.
• ‫[C-5-2] המשתמש חייב להידרש לאימות ראשי מומלץ (למשל: קוד אימות, תבנית, סיסמה) כפי שמתואר ב‫[C-1-7] וב‫[C-1-8] בסעיף 7.3.10.
• ‫[C-5-3] אסור להתייחס לשיטות האלה כמסך נעילה מאובטח, והן חייבות לעמוד בדרישות שמתחילות ב-C-8 בקטע הבא.

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

• ‫[C-6-1] חובה להשתמש במנגנון חלופי כדי להשתמש באחת משיטות האימות הראשיות המומלצות שמבוססות על סוד ידוע, ולעמוד בדרישות כדי להיחשב כמסך נעילה מאובטח.
• ‫[C-6-2] השיטה החדשה חייבת להיות מושבתת, וצריך לאפשר רק אחת משיטות האימות הראשי המומלצות לביטול הנעילה של המסך, אם האפליקציה Device Policy Controller ‏ (DPC) הגדירה את המדיניות באמצעות השיטה DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) או השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_UNSPECIFIED.
• ‫[C-6-3] המשתמש חייב להתבקש להשתמש באחת משיטות האימות העיקריות המומלצות (למשל, קוד אימות, קו ביטול נעילה, סיסמה) לפחות פעם ב-4 שעות או פחות.
• ‫[C-6-4] אסור להתייחס לשיטה החדשה כאל מסך נעילה מאובטח, והיא צריכה לעמוד בדרישות שמפורטות בקטע C-8 בהמשך.

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

• ‫[C-7-1] חובה להציג אינדיקציה ברורה בתפריט ההגדרות ובמסך הנעילה כשהנעילה של המכשיר נדחית או שאפשר לבטל את הנעילה באמצעות סוכן מהימן. לדוגמה, מערכת AOSP עומדת בדרישה הזו על ידי הצגת תיאור טקסט להגדרה 'נעילה אוטומטית' ו'נעילה מיידית של לחצן ההפעלה' בתפריט ההגדרות, וסמל שקל להבחין בו במסך הנעילה.
• ‫[C-7-2] חובה לכבד ולהטמיע באופן מלא את כל ממשקי ה-API של סוכני האמון במחלקה DevicePolicyManager, כמו הקבוע KEYGUARD_DISABLE_TRUST_AGENTS.
• ‫[C-7-3] אסור להטמיע באופן מלא את הפונקציה TrustAgentService.addEscrowToken() במכשיר שמשמש כמכשיר אישי ראשי (למשל, מכשיר נייד), אבל מותר להטמיע באופן מלא את הפונקציה בהטמעות של מכשירים שבדרך כלל משותפים (למשל, Android TV או מכשיר לרכב).
• ‫[C-7-4] חובה להצפין את כל הטוקנים המאוחסנים שנוספו על ידי TrustAgentService.addEscrowToken().
• ‫[C-7-5] אסור לאחסן את מפתח ההצפנה או את אסימון הנאמנות באותו מכשיר שבו נעשה שימוש במפתח. לדוגמה, מותר שמפתח שמאוחסן בטלפון יבטל את הנעילה של חשבון משתמש בטלוויזיה. במכשירים לרכב, אסור לאחסן את אסימון הנאמנות בשום חלק של הרכב.
• ‫[C-7-6] חובה ליידע את המשתמש לגבי ההשלכות של האבטחה לפני הפעלת אסימון הנאמנות לצורך פענוח של אחסון הנתונים.
• ‫[C-7-7] חובה להשתמש במנגנון חלופי כדי להשתמש באחת משיטות האימות הראשיות המומלצות.
• ‫[C-7-8] המשתמש חייב להתבקש להשתמש באחת משיטות האימות העיקריות המומלצות (לדוגמה: קוד אימות, קו ביטול נעילה, סיסמה) לפחות פעם ב-72 שעות או פחות, אלא אם יש חשש לגבי בטיחות המשתמש (לדוגמה: הסחת דעת של הנהג).
• ‫[C-7-9] המשתמש חייב להידרש להשתמש באחת משיטות האימות הראשיות המומלצות (למשל: קוד אימות, תבנית, סיסמה) כפי שמתואר ב[C-1-7] וב[C-1-8] בסעיף 7.3.10, אלא אם יש חשש לגבי בטיחות המשתמש (למשל: הסחת דעת של הנהג).
• ‫[C-7-10] אסור להתייחס אליו כמסך נעילה מאובטח, והוא חייב לעמוד בדרישות שמפורטות בסעיף C-8 בהמשך.
• ‫[C-7-11] אסור לאפשר ל-TrustAgents במכשירים אישיים ראשיים (לדוגמה: מכשירים ניידים) לבטל את נעילת המכשיר, ואפשר להשתמש בהם רק כדי לשמור על מצב לא נעול של מכשיר שכבר לא נעול למשך עד 4 שעות. ההטמעה שמוגדרת כברירת מחדל של TrustManagerService ב-AOSP עומדת בדרישה הזו.
• ‫[C-7-12] חובה להשתמש בערוץ תקשורת מאובטח מבחינה קריפטוגרפית (למשל UKEY2) כדי להעביר את אסימון הנאמנות ממכשיר האחסון למכשיר היעד.

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

• ‫[C-8-1] צריך להשבית את השיטה החדשה אם אפליקציית Device Policy Controller‏ (DPC) הגדירה את מדיניות איכות הסיסמה באמצעות השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_UNSPECIFIED.
• ‫[C-8-2] אסור להם לאפס את טיימר התפוגה של הסיסמה שהוגדר על ידי DevicePolicyManager.setPasswordExpirationTimeout().
• ‫[C-8-3] אסור לחשוף API לשימוש של אפליקציות צד שלישי כדי לשנות את מצב הנעילה.

‫9.11.2. StrongBox

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

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

• ‫[C-SR] מומלץ מאוד לתמוך ב-StrongBox. סביר להניח ש-StrongBox יהפוך לדרישה בגרסה עתידית.

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

• ‫[C-1-1] חובה להצהיר על FEATURE_STRONGBOX_KEYSTORE.

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

• ‫[C-1-3] חובה להשתמש במעבד נפרד שלא משתף מטמון, DRAM, מעבדי משנה או משאבי ליבה אחרים עם מעבד האפליקציה (AP).

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

• ‫[C-1-5] חייב להיות שעון פנימי עם רמת דיוק סבירה (‎+-10%) שלא ניתן לשינוי על ידי נקודת הגישה.

• ‫[C-1-6] חובה להשתמש במחולל מספרים אקראיים אמיתי שמפיק פלט בלתי צפוי עם התפלגות אחידה.

• ‫[C-1-7] חייבת להיות עמידות בפני חבלה, כולל עמידות בפני חדירה פיזית ושיבושים.

• ‫[C-1-8] חובה שתהיה עמידות לערוצים צדדיים, כולל עמידות מפני דליפת מידע דרך ערוצים צדדיים של חשמל, תזמון, קרינה אלקטרומגנטית וקרינה תרמית.

• ‫[C-1-9] חובה לאחסן את התוכן בצורה מאובטחת כדי להבטיח את הסודיות, השלמות, האותנטיות, העקביות והעדכניות שלו. אסור לאפשר קריאה או שינוי של האחסון, אלא בהתאם להרשאות שניתנות על ידי ממשקי ה-API של StrongBox.

• כדי לאמת את התאימות לדרישות [C-1-3] עד [C-1-9], הטמעות במכשירים:

  • ‫[C-1-10] חובה לכלול את החומרה שאושרה בהתאם לפרופיל ההגנה של IC מאובטח BSI-CC-PP-0084-2014 או שנבדקה על ידי מעבדת בדיקה עם הסמכה לאומית שמשלבת הערכת פגיעות עם פוטנציאל גבוה להתקפה בהתאם ליישום של קריטריונים משותפים של פוטנציאל התקפה על כרטיסים חכמים.
  • ‫[C-1-11] חובה לכלול את הקושחה שנבדקה על ידי מעבדת בדיקה עם הסמכה לאומית, שמשלבת הערכת פגיעות עם פוטנציאל גבוה להתקפה בהתאם לקריטריונים משותפים להערכת פוטנציאל התקפה על כרטיסים חכמים.
  • ‫[C-SR] מומלץ מאוד לכלול את החומרה שנבדקת באמצעות יעד אבטחה, רמת הבטחת הערכה (EAL) 5, בתוספת AVA_VAN.5. סביר להניח שאישור EAL 5 יהפוך לדרישה בגרסה עתידית.

• מומלץ מאוד להשתמש ב-[C-SR] כדי לספק עמידות בפני מתקפות פנימיות (IAR). המשמעות היא שאדם בעל גישה למפתחות חתימה של קושחה לא יכול ליצור קושחה שגורמת ל-StrongBox לדלוף סודות, לעקוף דרישות אבטחה פונקציונליות או לאפשר גישה לנתונים רגישים של משתמשים. הדרך המומלצת להטמיע IAR היא לאפשר עדכוני קושחה רק כשמספקים את הסיסמה של המשתמש הראשי דרך IAuthSecret HAL.

‫9.11.3. מסמך לאימות הזהות

מערכת אישורי הזהות מוגדרת ומופעלת על ידי הטמעה של כל ממשקי ה-API בחבילה android.security.identity.*. ממשקי ה-API האלה מאפשרים למפתחי אפליקציות לאחסן ולאחזר מסמכים של זהויות משתמשים. הטמעות במכשיר:

• [C-SR] מומלץ מאוד להטמיע את מערכת אישורי הזהות.

אם הטמעות של מכשירים מטמיעות את מערכת פרטי הזהות, הן:

• ‫[C-0-1] הפונקציה IdentityCredentialStore#getInstance()‎ חייבת להחזיר ערך שאינו null.

• ‫[C-0-2] חובה להטמיע את מערכת אישורי הזהות (למשל, ממשקי ה-API של android.security.identity.*) באמצעות קוד שמתקשר עם אפליקציה מהימנה באזור שמבודד בצורה מאובטחת מהקוד שפועל בקרנל ומעליו. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד של ליבה או של מרחב משתמשים יכול לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA.

• ‫[C-0-3] הפעולות הקריפטוגרפיות שנדרשות להטמעה של מערכת פרטי הכניסה (למשל, ממשקי ה-API של android.security.identity.*) חייבות להתבצע באופן מלא באפליקציה המהימנה, ואסור שחומר המפתח הפרטי ייצא מסביבת הביצוע המבודדת, אלא אם נדרש אחרת באופן ספציפי על ידי ממשקי API ברמה גבוהה יותר (למשל, השיטה createEphemeralKeyPair()).

• ‫[C-0-4] אפליקציה מהימנה חייבת להיות מיושמת באופן שלא ישפיע על מאפייני האבטחה שלה (לדוגמה, נתוני אישורים לא ישוחררו אלא אם יתקיימו תנאי בקרת הגישה, לא ניתן יהיה ליצור קודי אימות הודעות (MAC) עבור נתונים שרירותיים) גם אם מערכת Android מתנהגת בצורה לא תקינה או שנפרצה.

‫9.12. מחיקת נתונים

כל ההטמעות במכשירים:

• ‫[C-0-1] חובה לספק למשתמשים מנגנון לביצוע 'איפוס לנתוני היצרן'.
• ‫[C-0-2] חובה למחוק את כל הנתונים במערכת הקבצים של נתוני המשתמשים.
• ‫[C-0-3] חובה למחוק את הנתונים באופן שעומד בתקנים הרלוונטיים בתחום, כמו NIST SP800-88.
• ‫[C-0-4] חובה להפעיל את התהליך של 'איפוס להגדרות היצרן' שצוין למעלה כשמתבצעת קריאה ל-API של DevicePolicyManager.wipeData() על ידי האפליקציה 'בקר לניהול מדיניות מכשירים (DPC)' של המשתמש הראשי.
• יכול להיות שתהיה אפשרות למחיקת נתונים מהירה שמבצעת רק מחיקה לוגית של נתונים.

‫9.13. מצב הפעלה בטוח

מערכת Android מספקת מצב אתחול בטוח, שמאפשר למשתמשים לאתחל למצב שבו רק אפליקציות מערכת שהותקנו מראש יכולות לפעול וכל האפליקציות של צד שלישי מושבתות. במצב הזה, שנקרא 'מצב אתחול בטוח', המשתמש יכול להסיר אפליקציות צד שלישי שעלולות להזיק.

הטמעות במכשיר:

• [SR] מומלץ מאוד להטמיע מצב אתחול בטוח.

אם הטמעות המכשיר מטמיעות מצב הפעלה בטוח, הן:

• ‫[C-1-1] חובה לספק למשתמש אפשרות להיכנס למצב הפעלה בטוח באופן שלא ניתן להפרעה על ידי אפליקציות צד שלישי שהותקנו במכשיר, אלא אם אפליקציית הצד השלישי היא בקר מדיניות מכשיר והיא הגדירה את הדגל UserManager.DISALLOW_SAFE_BOOT כ-True.

• ‫[C-1-2] חובה לספק למשתמש את האפשרות להסיר אפליקציות צד שלישי במצב בטוח.

• מומלץ לספק למשתמש אפשרות להיכנס למצב אתחול בטוח מתפריט האתחול באמצעות תהליך עבודה ששונה מזה של אתחול רגיל.

‫9.14. בידוד של מערכות ברכב

מכשירי Android Automotive אמורים להחליף נתונים עם מערכות משנה קריטיות ברכב באמצעות vehicle HAL כדי לשלוח ולקבל הודעות ברשתות הרכב, כמו CAN bus.

אפשר לאבטח את חילופי הנתונים באמצעות הטמעה של תכונות אבטחה מתחת לשכבות של Android framework, כדי למנוע אינטראקציה זדונית או לא מכוונת עם מערכות המשנה האלה.

‫9.15. תוכניות מינויים

'תוכניות מנויים' מתייחסות לפרטי תוכנית הקשר לחיוב שספק שירותי הסלולר מספק דרך SubscriptionManager.setSubscriptionPlans().

כל ההטמעות במכשירים:

• ‫[C-0-1] חובה להחזיר תוכניות מינוי רק לאפליקציית ספק הסלולר שסיפק אותן במקור.
• ‫[C-0-2] אסור לגבות מרחוק או להעלות תוכניות מינוי.
• [C-0-3] חובה לאפשר שינויים, כמו SubscriptionManager.setSubscriptionOverrideCongested(), רק דרך האפליקציה של ספק סלולר שמספק כרגע חבילות מינוי תקפות.

‫9.16. Application Data Migration

אם הטמעות המכשיר כוללות יכולת להעביר נתונים ממכשיר אחד למכשיר אחר, והן לא מגבילות את נתוני האפליקציה שהן מעתיקות למה שהוגדר על ידי מפתח האפליקציה במניפסט באמצעות המאפיין android:fullBackupContent, הן:

• ‫[C-1-1] אסור ליזום העברות של נתוני אפליקציות ממכשירים שבהם המשתמש לא הגדיר אימות ראשי כפי שמתואר בקטע 9.11.1 נעילת מסך מאובטחת ואימות.
• ‫[C-1-2] חובה לאשר באופן מאובטח את האימות הראשי במכשיר המקור ולאשר את כוונת המשתמש להעתיק את הנתונים במכשיר המקור לפני העברת הנתונים.
• ‫[C-1-3] חובה להשתמש באימות (attestation) של מפתח אבטחה כדי לוודא שמכשיר המקור ומכשיר היעד בהעברה ממכשיר למכשיר הם מכשירי Android לגיטימיים, ושתוכנת האתחול שלהם נעולה.
• ‫[C-1-4] חובה להעביר נתוני אפליקציה רק לאותה אפליקציה במכשיר היעד, עם אותו שם חבילה ואותו אישור חתימה.
• ‫[C-1-5] חובה להציג בתפריט ההגדרות אינדיקציה לכך שבוצעה מיגרציה של נתונים ממכשיר המקור באמצעות מיגרציה של נתונים ממכשיר למכשיר. משתמש לא אמור להיות מסוגל להסיר את הסימן הזה.

10. בדיקת תאימות של תוכנה

הטמעות במכשירים חייבות לעבור את כל הבדיקות שמתוארות בקטע הזה. עם זאת, חשוב לזכור שאין חבילת בדיקות תוכנה מקיפה לחלוטין. לכן, מומלץ מאוד למפתחים של מכשירים לבצע את המספר המינימלי האפשרי של שינויים בהטמעה המועדפת של Android שזמינה מ-Android Open Source Project (פרויקט קוד פתוח של Android). כך אפשר לצמצם את הסיכון להחדרת באגים שיוצרים חוסר תאימות, שדורש עבודה מחדש ועדכונים פוטנציאליים של המכשיר.

10.1. חבילה לבדיקות תאימות (CTS)

הטמעות במכשיר:

• ‫[C-0-1] המכשיר חייב לעבור את חבילת בדיקות התאימות של Android‏ (CTS) שזמינה מ-Android Open Source Project, באמצעות תוכנת המשלוח הסופית במכשיר.

• ‫[C-0-2] חובה לוודא תאימות במקרים של דו-משמעות ב-CTS ובכל הטמעה מחדש של חלקים מקוד המקור של ההפניה.

ה-CTS מיועד להרצה במכשיר בפועל. בדומה לכל תוכנה, יכול להיות שיהיו באגים ב-CTS עצמו. גרסת ה-CTS תהיה נפרדת מהגדרת התאימות הזו, ויכול להיות שיפורסמו כמה עדכונים של ה-CTS ל-Android 11.

הטמעות במכשיר:

• ‫[C-0-3] המכשיר חייב לעבור את הגרסה העדכנית ביותר של CTS שזמינה בזמן השלמת תוכנת המכשיר.

• מומלץ להשתמש בהטמעה לדוגמה בעץ של Android Open Source ככל האפשר.

10.2. CTS Verifier

הכלי CTS Verifier כלול בחבילת הבדיקות של התאימות, והוא מיועד להפעלה על ידי מפעיל אנושי כדי לבדוק פונקציונליות שלא ניתן לבדוק באמצעות מערכת אוטומטית, כמו פעולה תקינה של מצלמה וחיישנים.

הטמעות במכשיר:

• ‫[C-0-1] חובה להריץ בצורה נכונה את כל המקרים הרלוונטיים בכלי לאימות CTS.

ב-CTS Verifier יש בדיקות להרבה סוגים של חומרה, כולל חומרה אופציונלית.

הטמעות במכשיר:

• ‫[C-0-2] חובה לעבור את כל הבדיקות עבור החומרה שקיימת במכשיר. לדוגמה, אם במכשיר יש מד תאוצה, הוא חייב לבצע בצורה תקינה את תרחיש הבדיקה של מד התאוצה ב-CTS Verifier.

אפשר לדלג על תרחישי בדיקה של תכונות שמסומנות כאופציונליות במסמך הגדרת התאימות (CDD) או להשמיט אותם.

• ‫[C-0-2] כל מכשיר וכל גרסת build חייבים להריץ את CTS Verifier בצורה נכונה, כפי שצוין למעלה. עם זאת, מכיוון שהרבה גרסאות build דומות מאוד, לא מצפים ממפתחי מכשירים להריץ במפורש את CTS Verifier בגרסאות build ששונות רק בפרטים שוליים. בפרט, הטמעות במכשירים ששונות מהטמעה שעברה את הבדיקה ב-CTS Verifier רק בסט של הלוקאלים, המיתוג וכו' שכלולים בהן, יכולות לדלג על הבדיקה ב-CTS Verifier.

11. תוכנות שניתנות לעדכון

• ‫[C-0-1] הטמעות של מכשירים חייבות לכלול מנגנון להחלפה של כל תוכנת המערכת. המנגנון לא צריך לבצע שדרוגים 'בזמן אמת' – כלומר, יכול להיות שתידרש הפעלה מחדש של המכשיר. אפשר להשתמש בכל שיטה, בתנאי שהיא יכולה להחליף את כל התוכנה שהותקנה מראש במכשיר. לדוגמה, כל אחת מהגישות הבאות תעמוד בדרישה הזו:

  • הורדות 'דרך האוויר' (OTA) עם עדכון אופליין באמצעות הפעלה מחדש.
  • עדכונים 'קשורים' דרך USB ממחשב מארח.
  • עדכונים במצב אופליין באמצעות הפעלה מחדש ועדכון מקובץ באחסון נייד.

• ‫[C-0-2] מנגנון העדכון שבו משתמשים חייב לתמוך בעדכונים בלי למחוק את נתוני המשתמש. כלומר, מנגנון העדכון חייב לשמור על הנתונים הפרטיים של האפליקציה ועל הנתונים המשותפים של האפליקציה. שימו לב: תוכנת Android במעלה הזרם כוללת מנגנון עדכון שעומד בדרישה הזו.

• ‫[C-0-3] כל העדכון חייב להיות חתום, ומנגנון העדכון במכשיר חייב לאמת את העדכון והחתימה מול מפתח ציבורי שמאוחסן במכשיר.

• ‫[C-SR] מומלץ מאוד שמנגנון החתימה יגבב את העדכון באמצעות SHA-256 ויאמת את הגיבוב מול המפתח הציבורי באמצעות ECDSA NIST P-256.

אם ההטמעות במכשיר כוללות תמיכה בחיבור נתונים ללא הגבלה, כמו פרופיל 802.11 או Bluetooth PAN (רשת אישית), אז:

• ‫[C-1-1] חובה לתמוך בהורדות של OTA עם עדכון אופליין באמצעות הפעלה מחדש.

ביישומים של מכשירים שמופעלים עם Android 6.0 ואילך, מנגנון העדכון צריך לתמוך באימות שקובץ האימג' של המערכת זהה בינארית לתוצאה הצפויה אחרי עדכון OTA. ההטמעה של OTA מבוסס-בלוק בפרויקט הקוד הפתוח של Android (נוספה מאז Android 5.1) עומדת בדרישה הזו.

בנוסף, הטמעות של מכשירים צריכות לתמוך בעדכוני מערכת מסוג A/B. ב-AOSP, התכונה הזו מיושמת באמצעות boot control HAL.

אם נמצאה שגיאה בהטמעה של מכשיר אחרי שהוא הושק, אבל במסגרת משך החיים הסביר של המוצר שנקבע בהתייעצות עם צוות התאימות של Android, והשגיאה משפיעה על התאימות של אפליקציות של צד שלישי, אז:

• ‫[C-2-1] המפתח של המכשיר חייב לתקן את השגיאה באמצעות עדכון תוכנה שזמין להחלה בהתאם למנגנון שמתואר למעלה.

‫Android כולל תכונות שמאפשרות לאפליקציה Device Owner (אם היא קיימת) לשלוט בהתקנה של עדכוני מערכת. אם מערכת המשנה לעדכון המערכת במכשירים מדווחת על android.software.device_admin, אז:

• ‫[C-3-1] חובה להטמיע את ההתנהגות שמתוארת במחלקה SystemUpdatePolicy.

12. יומן שינויים של מסמך

סיכום השינויים בהגדרת התאימות בגרסה הזו:

• יומן שינויים של מסמכים

סיכום השינויים בקטעים שמתייחסים לאנשים פרטיים:

1. מבוא
2. סוגי מכשירים
3. תוכנה
4. אריזת אפליקציות
5. מולטימדיה
6. כלים ואפשרויות למפתחים
7. תאימות חומרה
8. ביצועים והספק
9. מודל אבטחה
10. בדיקת תאימות של תוכנה
11. תוכנות שאפשר לעדכן
12. יומן שינויים של המסמך
13. יצירת קשר

‫12.1 טיפים לצפייה ביומן השינויים

השינויים מסומנים כך:

• CDD
  שינויים מהותיים בדרישות התאימות.

• ‫Docs
  שינויים שקשורים למראה או למבנה.

כדי להציג את השינויים בצורה הכי טובה, כדאי להוסיף את הפרמטרים של כתובת ה-URL‏ pretty=full ו-no-merges לכתובות ה-URL של יומן השינויים.

13. צור קשר

אתם יכולים להצטרף לפורום התאימות של Android ולבקש הבהרות או להעלות בעיות שלדעתכם לא מכוסות במסמך.