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

1. מבוא

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

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

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

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

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

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

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

‫1.1 מבנה המסמך

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

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

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

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

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

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

ההגדרות של כל מזהה מפורטות בהמשך:

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

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

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

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

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

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

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

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

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

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

  • להיות מחובר למקור מתח שמאפשר ניידות, כמו סוללה.
  • גודל המסך באלכסון הוא בין 2.5 ל-8 אינץ'.

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

הערה: דרישות שלא חלות על מכשירי Android Tablet מסומנות בכוכבית (*).

2.2.1. חומרה

גודל המסך (סעיף 7.1.1.1)

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

  • ‫[H-0-1] חובה שיהיה מסך בגודל פיזי של 2.5 אינץ' לפחות באלכסון.*

צפיפות המסך (סעיף 7.1.1.3)

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

  • ‫[H-SR] מומלץ מאוד לספק למשתמשים אפשרות לשנות את גודל התצוגה.

מצב תאימות לאפליקציות מדור קודם (סעיף 7.1.5)

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

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

מקלדת (סעיף 7.2.1)

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

  • ‫[H-0-1] חובה לכלול תמיכה באפליקציות של עורך שיטות קלט (IME) של צד שלישי.

מקשי ניווט (סעיף 7.2.3)

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

  • ‫[H-0-1] חובה לספק את הפונקציות 'מסך הבית', 'פריטים אחרונים' ו'הקודם'.

  • ‫[H-0-2] חובה לשלוח לאפליקציה שבחזית גם את האירוע הרגיל וגם את האירוע של לחיצה ארוכה על הפונקציה 'חזרה' (KEYCODE_BACK).

קלט ממסך מגע (סעיף 7.2.4)

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

  • ‫[H-0-1] המכשיר חייב לתמוך בהזנת קלט באמצעות מסך מגע.

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

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

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

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

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

ג'ירוסקופ (סעיף 7.3.4)

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

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

חיישן קרבה (סעיף 7.3.8)

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

  • מומלץ לכלול חיישן קירבה.

חיישן תנוחה (סעיף 7.3.12)

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

  • מומלץ לתמוך בחיישן תנוחה עם 6 דרגות חופש.

‫Bluetooth (סעיף 7.4.3)

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

  • צריך לכלול תמיכה ב-Bluetooth וב-Bluetooth LE.

חוסך הנתונים (סעיף 7.4.7)

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

  • ‫[H-1-1] חובה לספק את מצב החיסכון בחבילת הגלישה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אחסון משותף של אפליקציות (סעיף 7.6.2)

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

  • ‫[H-0-1] אסור לספק אחסון משותף לאפליקציה בגודל קטן מ-1GiB.

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

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

  • צריך לכלול יציאת USB שתומכת במצב ציוד היקפי.

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

  • ‫[H-1-1] חובה להטמיע את Android Open Accessory (AOA) API.*

מיקרופון (סעיף 7.8.1)

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

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

פלט אודיו (סעיף 7.8.2)

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

  • ‫[H-0-1] חובה להגדיר פלט אודיו ולהצהיר על android.hardware.audio.output.

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

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

  • ‫[H-1-1] חובה להצהיר על התכונה android.software.vr.mode.*

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

  • ‫[H-2-1] חובה לכלול אפליקציה שמטמיעה את android.service.vr.VrListenerService שאפשר להפעיל באמצעות אפליקציות VR דרך android.app.Activity#setVrModeEnabled.*

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

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

  • ‫[H-1-1] חובה להצהיר על feature flag‏ android.hardware.vr.high_performance.*

2.2.2. מולטימדיה

קידוד אודיו (סעיף 5.1.1)

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

  • ‫[H-0-1] AMR-NB
  • ‫[H-0-2] AMR-WB
  • ‫[H-0-3] פרופיל MPEG-4 AAC‏ (AAC LC)
  • ‫[H-0-4] פרופיל MPEG-4 HE AAC ‏ (AAC+)
  • ‫[H-0-5] AAC ELD (קידוד AAC משופר עם השהיה נמוכה)

פענוח אודיו (סעיף 5.1.2)

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

  • ‫[H-0-1] AMR-NB
  • ‫[H-0-2] AMR-WB

קידוד סרטונים (סעיף 5.2)

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

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

פענוח סרטונים (סעיף 5.3)

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

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

2.2.3. תוכנות

תאימות ל-WebView (סעיף 3.4.1)

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

  • ‫[H-0-1] חובה לספק הטמעה מלאה של android.webkit.Webview API.

תאימות לדפדפנים (סעיף 3.4.2)

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

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

מרכז האפליקציות (סעיף 3.8.1)

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

  • ‫[H-SR] מומלץ מאוד להטמיע אפליקציית הפעלה שמוגדרת כברירת מחדל ותומכת בהצמדה של קיצורי דרך ווידג'טים בתוך האפליקציה.

  • ‫[H-SR] מומלץ מאוד להטמיע משגר ברירת מחדל שמספק גישה מהירה לקיצורי הדרך הנוספים שמוצעים על ידי אפליקציות צד שלישי באמצעות ממשק ה-API של ShortcutManager.

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

ווידג'טים (סעיף 3.8.2)

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

  • ‫[H-SR] מומלץ מאוד לתמוך בווידג'טים של אפליקציות צד שלישי.

התראות (סעיף 3.8.3)

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

  • ‫[H-0-1] חובה לאפשר לאפליקציות צד שלישי להודיע למשתמשים על אירועים חשובים באמצעות מחלקות ה-API‏ Notification ו-NotificationManager.
  • ‫[H-0-2] חובה לתמוך בהתראות עשירות.
  • ‫[H-0-3] חובה לתמוך בהתראות 'שימו לב'.
  • ‫[H-0-4] חובה לכלול את מגש ההתראות, כדי לאפשר למשתמש לשלוט ישירות בהתראות (למשל, להשיב, לדחות, לבטל או לחסום) באמצעות אמצעי בקרה למשתמש כמו לחצני פעולה או לוח הבקרה, כפי שמיושם ב-AOSP.

חיפוש (סעיף 3.8.4)

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

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

הפעלת מדיה במסך הנעילה (סעיף 3.8.10)

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

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

ניהול מכשירים (סעיף 3.9)

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

  • ‫[H-1-1] חובה להטמיע את כל מגוון כללי ניהול המכשיר שמוגדרים במסמכי ה-SDK של Android.

נגישות (סעיף 3.10)

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

  • ‫[H-SR] חייב לתמוך בשירותי נגישות של צד שלישי.

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

המרת טקסט לדיבור (סעיף 3.11)

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

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

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

הגדרות מהירות (סעיף 3.13)

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

  • ‫[H-SR] מומלץ מאוד לכלול רכיב ממשק משתמש של הגדרות מהירות.

התאמה של מכשיר נלווה (סעיף 3.15)

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

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

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

עקביות חוויית המשתמש (סעיף 8.1)

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

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

ביצועי גישה לקלט/פלט של קבצים (סעיף 8.2)

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

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

מצבי חיסכון בחשמל (סעיף 8.3)

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

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

חשבונאות של צריכת חשמל (סעיפים 8.4)

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

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

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

2.2.5. מודל אבטחה

הרשאות (סעיפים 9.1)

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

  • ‫[H-0-1] חובה לאפשר לאפליקציות צד שלישי לגשת לסטטיסטיקת השימוש באמצעות ההרשאה android.permission.PACKAGE_USAGE_STATS ולספק מנגנון נגיש למשתמש כדי להעניק או לבטל גישה לאפליקציות כאלה בתגובה להצהרת הכוונות android.settings.ACTION_USAGE_ACCESS_SETTINGS.

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

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

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

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

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

2.3.1. חומרה

ניווט ללא מגע (סעיף 7.2.2)

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

מקשי ניווט (סעיף 7.2.3)

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

  • ‫[T-0-1] חובה לספק את הפונקציות 'דף הבית' ו'הקודם'.
  • ‫[T-0-2] חובה לשלוח את האירוע הרגיל ואת אירוע הלחיצה הארוכה של פונקציית החזרה (KEYCODE_BACK) לאפליקציה שבחזית.

מיפוי לחצנים (סעיף 7.2.6.1)

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

  • ‫[T-0-1] חובה לכלול תמיכה בבקרי משחקים ולהצהיר על דגל התכונה android.hardware.gamepad.

שליטה מרחוק (סעיף 7.2.7)

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

ג'ירוסקופ (סעיף 7.3.4)

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

  • ‫[T-1-1] חובה לתמוך בדיווח על אירועים בתדירות של 100 הרץ לפחות.

‫Bluetooth (סעיף 7.4.3)

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

  • ‫[T-0-1] המכשיר חייב לתמוך ב-Bluetooth וב-Bluetooth LE.

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

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

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

מיקרופון (סעיף 7.8.1)

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

  • צריך לכלול מיקרופון.

פלט אודיו (סעיף 7.8.2)

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

  • ‫[T-0-1] חובה להגדיר פלט אודיו ולהצהיר על android.hardware.audio.output.

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

קידוד אודיו (סעיף 5.1)

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

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

קידוד סרטונים (סעיף 5.2)

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

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

‫H-264 (סעיף 5.2.2)

היישומים של מכשירי טלוויזיה הם:

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

פענוח סרטונים (סעיף 5.3)

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

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

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

  • [T-SR] MPEG-2

‫H.264 (סעיף 5.3.4)

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

  • ‫[T-1-1] המכשיר חייב לתמוך ב-High Profile Level 4.2 ובפרופיל הפענוח HD 1080p (ב-60fps).
  • ‫[T-1-2] חובה שתהיה אפשרות לפענח סרטונים עם שני פרופילי HD כמו שמצוין בטבלה הבאה, שמקודדים עם פרופיל Baseline, פרופיל Main או פרופיל High ברמה 4.2

‫H.265 (HEVC) (סעיף 5.3.5)

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

  • ‫[T-1-1] חובה לתמוך בפרופיל הראשי ברמה 4.1, בדרגה Main.
  • ‫[T-SR] מומלץ מאוד לתמוך בקצב פריימים של 60fps לסרטונים באיכות HD 1080p.

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

  • ‫[T-2-1] הקודק חייב לתמוך בפרופיל Main10 Level 5 Main Tier.

‫VP8 (סעיף 5.3.6)

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

  • ‫[T-1-1] חובה לתמוך בפרופיל הפענוח HD 1080p60.

אם הטמעות של מכשירי טלוויזיה תומכות ב-codec‏ VP8 ותומכות ב-720p, הן:

  • ‫[T-2-1] חובה לתמוך בפרופיל הפענוח HD 720p60.

‫VP9 (סעיף 5.3.7)

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

  • ‫[T-1-1] חובה לתמוך בעומק צבע של 8 ביט, ומומלץ לתמוך בפרופיל VP9 2 (10 ביט).

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

  • ‫[T-2-1] חובה לתמוך ב-60fps ברזולוציה של 1080p.

Secure Media (סעיף 5.8)

אם מכשירי Android TV תומכים ברזולוציית 4K, הם:

  • ‫[T-1-1] חובה לתמוך ב-HDCP 2.2 בכל המסכים החיצוניים שמחוברים באמצעות כבל.

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

  • ‫[T-2-1] חייבת להיות תמיכה ב-HDCP 1.4 בכל המסכים החיצוניים שמחוברים באמצעות כבל.

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

  • ‫[T-SR] מומלץ מאוד לתמוך בפענוח בו-זמני של סטרימינג מאובטח. מומלץ מאוד לבצע פענוח בו-זמני של שני זרמים לפחות.

עוצמת הקול של האודיו (סעיף 5.5.3)

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

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

2.3.3. תוכנות

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

תאימות של WebView (סעיף 3.4.1)

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

  • ‫[T-0-1] חובה לספק הטמעה מלאה של android.webkit.Webview API.

הפעלת מדיה במסך הנעילה (סעיף 3.8.10)

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

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

חלונות מרובים (סעיף 3.8.14)

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

  • ‫[T-SR] מומלץ מאוד לתמוך במצב תמונה בתוך תמונה (PIP) של ריבוי חלונות.

נגישות (סעיף 3.10)

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

  • ‫[T-SR] חובה לתמוך בשירותי נגישות של צד שלישי.

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

המרת טקסט לדיבור (סעיף 3.11)

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

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

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

TV Input Framework (Section 3.12)

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

  • ‫[T-0-1] חובה לתמוך ב-TV Input Framework.

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

עקביות חוויית המשתמש (סעיף 8.1)

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

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

ביצועי גישה לקלט/פלט של קבצים (סעיף 8.2)

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

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

מצבי חיסכון בחשמל (סעיף 8.3)

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

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

חשבונאות של צריכת חשמל (סעיפים 8.4)

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

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

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-2] חובה לתמוך בהזנת קלט במסך מגע.

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

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

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

‫Bluetooth (סעיף 7.4.3)

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

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

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

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

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

מיקרופון (סעיף 7.8.1)

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

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

פלט אודיו (סעיף 7.8.1)

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

  • יכול להיות שיהיה פלט אודיו, אבל לא מומלץ.

2.4.2. מולטימדיה

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

2.4.3. תוכנות

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

  • ‫[W-0-1] חובה להצהיר על התכונה android.hardware.type.watch.
  • ‫[W-0-2] חובה לתמוך ב-uiMode = UI_MODE_TYPE_WATCH.

חיפוש (סעיף 3.8.4)

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

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

נגישות (סעיף 3.10)

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

  • ‫[W-1-1] חובה לתמוך בשירותי נגישות של צד שלישי.

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

המרת טקסט לדיבור (סעיף 3.11)

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

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

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

2.5. דרישות בנושא רכב

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

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

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

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

2.5.1. חומרה

גודל המסך (סעיף 7.1.1.1)

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

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

מקשי ניווט (סעיף 7.2.3)

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

  • ‫[A-0-1] חובה לספק את הפונקציה 'בית' ואפשר לספק את הפונקציות 'הקודם' ו'אחרונים'.
  • ‫[A-0-2] חובה לשלוח לאפליקציה שבחזית גם את האירוע הרגיל וגם את האירוע של לחיצה ארוכה על הפונקציה 'חזרה' (KEYCODE_BACK).

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

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

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

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

‫GPS (סעיף 7.3.3)

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

  • ‫[A-1-1] הדור של טכנולוגיית ה-GNSS חייב להיות השנה '2017' או חדש יותר.

ג'ירוסקופ (סעיף 7.3.4)

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

  • ‫[A-1-1] המכשיר חייב להיות מסוגל לדווח על אירועים בתדירות של 100 הרץ לפחות.

חיישנים ל-Android Automotive בלבד (סעיף 7.3.11) הילוך נוכחי (סעיף 7.3.11.1)

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

  • צריך לספק את הציוד הנוכחי כ-SENSOR_TYPE_GEAR.

מצב יום/לילה (סעיף 7.3.11.2)

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

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

סטטוס הנהיגה (סעיף 7.3.11.3)

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

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

מהירות הגלגל (סעיף 7.3.11.4)

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

  • ‫[A-0-1] חובה לספק את מהירות הרכב שמוגדרת כ-SENSOR_TYPE_CAR_SPEED.

‫Bluetooth (סעיף 7.4.3)

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

  • ‫[A-0-1] המכשיר חייב לתמוך ב-Bluetooth ורצוי שיתמוך ב-Bluetooth LE.

  • ‫[A-0-2] הטמעות של Android Automotive חייבות לתמוך בפרופילים הבאים של Bluetooth:

    • שיחות טלפון באמצעות פרופיל דיבורית (HFP).
    • הפעלת מדיה באמצעות פרופיל הפצת אודיו (A2DP).
    • שליטה בהפעלת מדיה באמצעות פרופיל שלט רחוק (AVRCP).
    • שיתוף אנשי קשר באמצעות פרופיל הגישה לספר הטלפונים (PBAP).
  • צריכה להיות תמיכה בפרופיל גישה להודעה (MAP).

יכולת רשת מינימלית (סעיף 7.4.5)

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

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

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

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

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

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

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

  • צריך לכלול יציאת USB שתומכת במצב ציוד היקפי.

מיקרופון (סעיף 7.8.1)

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

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

פלט אודיו (סעיף 7.8.2)

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

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

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

קידוד אודיו (סעיף 5.1)

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

  • ‫[A-1-1] פרופיל MPEG-4 AAC‏ (AAC LC)
  • ‫[A-1-2] פרופיל MPEG-4 HE AAC ‏ (AAC+)
  • ‫[A-1-3] AAC ELD (שיפור של AAC עם השהיה נמוכה)

קידוד סרטונים (סעיף 5.2)

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

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

פענוח סרטונים (סעיף 5.3)

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

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

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

  • ‫[A-SR] H.265 HEVC

‫2.5.3. תוכנות

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

  • ‫[A-0-1] חובה להצהיר על התכונה android.hardware.type.automotive.
  • ‫[A-0-2] חובה לתמוך ב-uiMode = UI_MODE_TYPE_CAR.
  • ‫[A-0-3] הטמעות של Android Automotive חייבות לתמוך בכל ממשקי ה-API הציבוריים במרחב השמות android.car.*.

תאימות ל-WebView (סעיף 3.4.1)

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

  • ‫[A-0-1] חובה לספק הטמעה מלאה של android.webkit.Webview API.

התראות (סעיף 3.8.3)

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

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

חיפוש (סעיף 3.8.4)

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

  • ‫[A-0-1] חובה להטמיע במכשיר עוזר דיגיטלי לטיפול בפעולת העזרה.

ממשק המשתמש של המדיה (סעיף 3.14)

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

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

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

מצבי חיסכון בחשמל (סעיף 8.3)

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

  • ‫[A-0-1] כל האפליקציות שמוחרגות ממצב המתנה של האפליקציה וממצבי חיסכון בסוללה של Doze חייבות להיות גלויות למשתמש הקצה.
  • ‫[A-0-2] האלגוריתמים להפעלה, לתחזוקה ולהתעוררות, והשימוש בהגדרות מערכת גלובליות של מצבי המתנה של אפליקציות ומצבי חיסכון בסוללה של Doze, לא יכולים להיות שונים מאלה של Android Open Source Project.

חשבונאות של צריכת חשמל (סעיפים 8.4)

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

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

2.2.5. מודל אבטחה

תמיכה במשתמשים מרובים (סעיף 9.5)

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

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

בידוד של מערכות רכב (סעיף 9.14)

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

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

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

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

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

  • להיות מחובר למקור מתח שמאפשר ניידות, כמו סוללה.
  • גודל המסך באלכסון הוא בין 7 ל-18 אינץ'.

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

2.4.1. חומרה

גודל המסך (סעיף 7.1.1.1)

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

  • ‫[Ta-0-1] חייב להיות בעל מסך בגודל 7 עד 18 אינץ'.

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

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

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

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

  • יכולים להטמיע את Android Open Accessory (AOA) API.

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

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

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

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 או חתימות, לחרוג מההתנהגות המתועדת או לכלול פעולות שלא עושות כלום, אלא אם מותר לעשות זאת באופן ספציפי בהגדרת התאימות הזו.

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

3.1.1. תוספים ל-Android

‫Android כוללת תמיכה בהרחבת ממשקי ה-API המנוהלים תוך שמירה על אותה גרסה של רמת ה-API.

  • ‫[C-0-1] הטמעות של מכשירי Android חייבות לטעון מראש את ההטמעה של AOSP של הספרייה המשותפת ExtShared ושל השירותים ExtServices עם גרסאות שגבוהות מהגרסאות המינימליות המותרות לכל רמת API או שוות להן. לדוגמה, הטמעות של מכשירי Android 7.0, שפועלת בהם רמת API‏ 24, חייבות לכלול לפחות גרסה 1.

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] כדי לספק ערכים עקביים ומשמעותיים בכל הטמעות המכשירים, הטבלה שלמטה כוללת הגבלות נוספות על הפורמטים של הערכים האלה, שהטמעות המכשירים חייבות לעמוד בהן.
פרמטר פרטים
VERSION.RELEASE הגרסה של מערכת Android שפועלת כרגע, בפורמט קריא. בשדה הזה צריך להזין אחד מערכי המחרוזת שמוגדרים בקטע 8.1.
גרסה.SDK הגרסה של מערכת Android שפועלת כרגע, בפורמט שקוד האפליקציה של צד שלישי יכול לגשת אליו. ב-Android 8.1, השדה הזה חייב להכיל את הערך השלם 8.1_INT.
VERSION.SDK_INT הגרסה של מערכת Android שפועלת כרגע, בפורמט שקוד האפליקציה של צד שלישי יכול לגשת אליו. ב-Android 8.1, השדה הזה חייב להכיל את הערך השלם 8.1_INT.
VERSION.INCREMENTAL ערך שנבחר על ידי המטמיע של המכשיר ומציין את הגרסה הספציפית של מערכת Android שפועלת כרגע, בפורמט שקריא לבני אדם. אסור להשתמש מחדש בערך הזה בגרסאות שונות שזמינות למשתמשי קצה. שימוש אופייני בשדה הזה הוא לציין את מספר ה-build או את מזהה השינוי בבקרת המקור ששימשו ליצירת ה-build. אין דרישות לגבי הפורמט הספציפי של השדה הזה, אבל אסור שהערך שלו יהיה null או מחרוזת ריקה ("").
משחקי לוח ערך שנבחר על ידי מי שמטמיע את המכשיר ומזהה את החומרה הפנימית הספציפית שבה נעשה שימוש במכשיר, בפורמט שקריא לבני אדם. אפשר להשתמש בשדה הזה כדי לציין את הגרסה הספציפית של הלוח שמפעיל את המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי '^[a-zA-Z0-9_-]+$'.
מותג ערך שמשקף את שם המותג שמשויך למכשיר, כפי שהוא מוכר למשתמשי הקצה. הערך צריך להיות בפורמט שניתן לקריאה על ידי בני אדם, ולייצג את יצרן המכשיר או את מותג החברה שמשווקת את המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי '^[a-zA-Z0-9_-]+$'.
SUPPORTED_ABIS השם של ערכת ההוראות (סוג ה-CPU + מוסכמת ה-ABI) של קוד מקורי. מידע נוסף זמין בסעיף 3.3. תאימות ל-API מקורי.
SUPPORTED_32_BIT_ABIS השם של ערכת ההוראות (סוג ה-CPU + מוסכמת ה-ABI) של קוד מקורי. מידע נוסף זמין בסעיף 3.3. תאימות ל-API מקורי.
SUPPORTED_64_BIT_ABIS השם של קבוצת ההוראות השנייה (סוג ה-CPU + מוסכמת ה-ABI) של קוד מקורי. מידע נוסף זמין בסעיף 3.3. תאימות ל-API מקורי.
CPU_ABI השם של ערכת ההוראות (סוג ה-CPU + מוסכמת ה-ABI) של קוד מקורי. מידע נוסף זמין בסעיף 3.3. תאימות ל-API מקורי.
CPU_ABI2 השם של קבוצת ההוראות השנייה (סוג ה-CPU + מוסכמת ה-ABI) של קוד מקורי. מידע נוסף זמין בסעיף 3.3. תאימות ל-API מקורי.
מכשיר ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם הפיתוח או את שם הקוד שמזהה את התצורה של תכונות החומרה והעיצוב התעשייתי של המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט, ולהתאים לביטוי הרגולרי '^[a-zA-Z0-9_-]+$'. שם המכשיר הזה לא יכול להשתנות במהלך חיי המוצר.
FINGERPRINT מחרוזת שמזהה באופן ייחודי את הגרסה הזו. הוא צריך להיות קריא לאנשים במידה סבירה. היא חייבת להיות בפורמט הבא:

‪$(BRAND)/$(PRODUCT)/
    $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

לדוגמה:

acme/myproduct/
    mydevice:8.1/LMYXX/3359:userdebug/test-keys

טביעת האצבע לא יכולה לכלול רווחים. אם יש רווחים לבנים בשדות אחרים שכלולים בתבנית שלמעלה, חובה להחליף אותם בטביעת האצבע של הגרסה בתו אחר, כמו קו תחתון ("_"). הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט.

חומרה השם של החומרה (משורת הפקודה של ליבת המערכת או מ-/proc). הוא צריך להיות קריא לאנשים במידה סבירה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי '^[a-zA-Z0-9_-]+$'.
מארח מחרוזת שמזהה באופן ייחודי את המארח שעליו נוצר ה-build, בפורמט קריא. אין דרישות לגבי הפורמט הספציפי של השדה הזה, אבל אסור שהערך שלו יהיה null או מחרוזת ריקה ("").
מזהה מזהה שנבחר על ידי מי שמטמיע את המכשיר כדי להתייחס לגרסה ספציפית, בפורמט שקריא לאנשים. הערך של השדה הזה יכול להיות זהה לערך של android.os.Build.VERSION.INCREMENTAL, אבל הוא צריך להיות בעל משמעות מספקת למשתמשי הקצה כדי להבחין בין גרסאות תוכנה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי '^[a-zA-Z0-9._-]+$'.
יצרן השם המסחרי של יצרן הציוד המקורי (OEM) של המוצר. אין דרישות לגבי הפורמט הספציפי של השדה הזה, אבל הוא לא יכול להיות null או מחרוזת ריקה (""). אסור לשנות את השדה הזה במהלך חיי המוצר.
MODEL ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם המכשיר כפי שהוא מוכר למשתמש הקצה. השם הזה צריך להיות זהה לשם שמשמש לשיווק המכשיר ולמכירתו למשתמשי קצה. אין דרישות לגבי הפורמט הספציפי של השדה הזה, אבל הוא לא יכול להיות null או מחרוזת ריקה (""). אסור לשנות את השדה הזה במהלך חיי המוצר.
מוצר ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם הפיתוח או את שם הקוד של המוצר הספציפי (מק"ט) שחייב להיות ייחודי באותו מותג. חובה שיהיה קריא לבני אדם, אבל הוא לא בהכרח מיועד לצפייה של משתמשי קצה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי '^[a-zA-Z0-9_-]+$'. שם המוצר הזה לא יכול להשתנות במהלך חיי המוצר.
מספר סידורי מספר סידורי של החומרה, שחייב להיות זמין וייחודי בכל המכשירים עם אותו דגם ואותו יצרן. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי '^([a-zA-Z0-9]{6,20})$'.
תגים רשימה של תגים שמופרדים בפסיקים, שנבחרו על ידי מי שמטמיע את המכשיר, כדי להבחין בין הגרסאות. השדה הזה חייב להכיל אחד מהערכים שמתאימים לשלושת סוגי ההגדרות הנפוצים של חתימה בפלטפורמת Android: release-keys, ‏ dev-keys, ‏ test-keys.
שעה ערך שמייצג את חותמת הזמן של מועד הבנייה.
סוג ערך שנבחר על ידי המטמיע של המכשיר ומציין את הגדרת זמן הריצה של ה-build. הערך בשדה הזה חייב להיות אחד מהערכים שמתאימים לשלושת ההגדרות הטיפוסיות של זמן הריצה ב-Android: user,‏ userdebug או eng.
משתמש שם או מזהה משתמש של המשתמש (או משתמש אוטומטי) שיצר את ה-build. אין דרישות לגבי הפורמט הספציפי של השדה הזה, אבל אסור שהערך שלו יהיה null או מחרוזת ריקה ("").
SECURITY_PATCH ערך שמציין את רמת תיקון האבטחה של גרסת build. הוא חייב לציין שה-build לא פגיע בשום צורה לאף אחת מהבעיות שמתוארות בחדשות האבטחה הציבוריות של Android שצוינו. התאריך צריך להיות בפורמט [YYYY-MM-DD], בהתאם למחרוזת מוגדרת שמתועדת בחדשות האבטחה הציבוריות של Android או בייעוץ בנושא אבטחה של Android, לדוגמה '2015-11-01'.
BASE_OS ערך שמייצג את הפרמטר FINGERPRINT של הגרסה, שזהה לגרסה הזו בכל פרט אחר מלבד התיקונים שמופיעים בעדכון האבטחה הציבורי של Android. היא חייבת לדווח על הערך הנכון, ואם אין גרסה כזו, לדווח על מחרוזת ריקה ("").
BOOTLOADER ערך שנבחר על ידי מי שמטמיע את המכשיר ומזהה את הגרסה הספציפית של טוען האתחול הפנימי שנעשה בו שימוש במכשיר, בפורמט שנוח לקריאה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי '^[a-zA-Z0-9._-]+$'.
getRadioVersion() חייב להיות ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את הגרסה הספציפית של הרדיו או המודם הפנימיים שמשמשים במכשיר, בפורמט שקריא לבני אדם. אם למכשיר אין רדיו או מודם פנימיים, הוא חייב להחזיר NULL. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי '^[a-zA-Z0-9._-,]+$'.

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

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

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

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

    • שעון שולחני
    • דפדפן
    • יומן
    • אנשי הקשר
    • גלריה
    • GlobalSearch
    • מרכז האפליקציות
    • מוזיקה
    • הגדרות
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 Open Source.
  • ‫[C-0-5] חובה לנסות לאמת את מסנני ה-Intent במהלך ההתקנה של האפליקציה, ולהגדיר את כל מסנני ה-Intent של UIR שאומתו בהצלחה כמטפלים באפליקציה כברירת מחדל ב-UIR שלהם.
  • יכול להיות שיוגדרו מסנני 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 או Broadcast 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.
3.2.3.5. הגדרות ברירת מחדל לאפליקציות

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

במקרים שבהם זה הגיוני, הטמעות של מכשירים חייבות לספק תפריט הגדרות דומה ולהיות תואמות לדפוס של מסנן הכוונות ולשיטות ה-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 עומדת בדרישה הזו כי היא כוללת תפריט 'אפשרויות לחשבונות לביצוע שיחות' בתפריט ההגדרות 'שיחות'.

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

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

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

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] חובה לשנות את הגודל של כל הפעילויות ב-VirtualDisplay בהתאם, אם משנים את הגודל של התצוגה עצמה.
  • יכול להיות שיוצג IME (עורך שיטות קלט, אמצעי בקרה למשתמש שמאפשר למשתמשים להזין טקסט) במסך הראשי, כששדה להזנת טקסט מתמקד במסך המשני.
  • צריך להטמיע את מיקוד הקלט במסך המשני באופן עצמאי מהמסך הראשי, כשקלט באמצעות מגע או מקלדת נתמך.
  • חייב להיות android.content.res.Configuration שמתאים לתצוגה הזו כדי שהפעילות תוצג, תפעל בצורה תקינה ותישאר תואמת אם היא תופעל בתצוגה משנית.

אם הטמעות של מכשירים מאפשרות הפעלה של פעילויות רגילות ב-Android במסכים משניים, ולמסכים הראשיים והמשניים יש ערכים שונים של android.util.DisplayMetrics:

  • ‫[C-2-1] אסור לאפשר פעילויות שלא ניתן לשנות את הגודל שלהן (שיש להן resizeableActivity=false ב-AndroidManifest.xml) ואפליקציות שמטרגטות רמת API 23 ומטה במסכים משניים.

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

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

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

מפתחי המכשירים הם:

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

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

3.3.1. Application Binary Interfaces

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

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

  • ‫[C-0-1] המכשיר חייב להיות תואם לממשקי ABI מוגדרים אחד או יותר, ולהטמיע תאימות ל-Android NDK.
  • ‫[C-0-2] חובה לכלול תמיכה בהפעלת קוד בסביבה מנוהלת כדי לקרוא לקוד מקומי, באמצעות הסמנטיקה של Java Native Interface (ממשק מקומי של Java) הרגיל (JNI).
  • ‫[C-0-3] חייבת להיות תאימות לקוד המקור (כלומר, תאימות לכותרת) ותאימות בינארית (ל-ABI) לכל ספרייה נדרשת ברשימה שלמטה.
  • ‫[C-0-4] אם יש תמיכה ב-ABI של 64 ביט, חובה לתמוך ב-ABI המקביל של 32 ביט.
  • ‫[C-0-5] חובה לדווח בצורה מדויקת על ממשק ה-ABI המקורי של האפליקציה (Application Binary Interface) שנתמך על ידי המכשיר, באמצעות הפרמטרים android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS ו-android.os.Build.SUPPORTED_64_BIT_ABIS. כל אחד מהפרמטרים האלה הוא רשימה של ממשקי ABI שמופרדים באמצעות פסיקים, בסדר יורד לפי העדיפות שלהם.
  • ‫[C-0-6] חובה לדווח, באמצעות הפרמטרים שלמעלה, רק על ממשקי ה-ABI שמתועדים ומתוארים בגרסה העדכנית של המסמכים בנושא ניהול ABI ב-Android NDK, וחובה לכלול תמיכה בתוסף Advanced SIMD (שנקרא גם NEON).

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

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

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

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

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

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

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

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

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

אם הטמעות המכשירים כוללות 32-bit ARM ABI, הן:

  • ‫[C-2-1] חובה לכלול את השורות הבאות ב-/proc/cpuinfo כשהוא נקרא על ידי אפליקציות ARM 32-bit כדי להבטיח תאימות לאפליקציות שנוצרו באמצעות גרסאות קודמות של Android NDK.

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

  • לא אמור לשנות את /proc/cpuinfo כשקוראים אותו באפליקציות ARM של 64 ביט או באפליקציות שאינן ARM.

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

3.4.1. תאימות ל-WebView

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

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

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

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

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

  • ‫[C-1-1] חייב לתמוך בכל אחד מממשקי ה-API האלה שמשויכים ל-HTML5:
  • ‫[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

ההתנהגויות של כל אחד מסוגי ה-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 ומעלה, היא חייבת לשחרר את נעילות ההשכמה שהיא מחזיקה.

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

3.6. API Namespaces

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

  • java.*
  • javax.*
  • sun.*
  • android.*
  • 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 upstream, וכפי שמצוין בטבלה הבאה. (הגדרות של גודל המסך וצפיפות המסך מופיעות בקטע 7.1.1).

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

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

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

פריסת המסך דחיסות מסך זיכרון מינימלי לאפליקציה
שעון Android ‫120 dpi (ldpi) ‫32MB
‫160 dpi (mdpi)
‫213 dpi ‏ (tvdpi)
‫240 dpi‏ (hdpi) 36MB
‫280 dpi (280dpi)
‫320 dpi‏ (xhdpi) 48MB
‫360 dpi (360dpi)
‫400 dpi (400dpi) ‫56MB
‫420 dpi (420dpi) ‫64MB
‫480 dpi (xxhdpi) ‫88MB
‫560 dpi (560dpi) ‫112MB
‫640 dpi ‏ (xxxhdpi) ‫154MB
קטן/רגיל ‫120 dpi (ldpi) ‫32MB
‫160 dpi (mdpi)
‫213 dpi ‏ (tvdpi) 48MB
‫240 dpi‏ (hdpi)
‫280 dpi (280dpi)
‫320 dpi‏ (xhdpi) ‫80MB
‫360 dpi (360dpi)
‫400 dpi (400dpi) ‫96MB
‫420 dpi (420dpi) ‫112MB
‫480 dpi (xxhdpi) ‫128MB
‫560 dpi (560dpi) ‫192MB
‫640 dpi ‏ (xxxhdpi) 256MB
גדולה ‫120 dpi (ldpi) ‫32MB
‫160 dpi (mdpi) 48MB
‫213 dpi ‏ (tvdpi) ‫80MB
‫240 dpi‏ (hdpi)
‫280 dpi (280dpi) ‫96MB
‫320 dpi‏ (xhdpi) ‫128MB
‫360 dpi (360dpi) ‫160MB
‫400 dpi (400dpi) ‫192MB
‫420 dpi (420dpi) ‫228MB
‫480 dpi (xxhdpi) 256MB
‫560 dpi (560dpi) ‫384MB
‫640 dpi ‏ (xxxhdpi) ‫512MB
xlarge ‫120 dpi (ldpi) 48MB
‫160 dpi (mdpi) ‫80MB
‫213 dpi ‏ (tvdpi) ‫96MB
‫240 dpi‏ (hdpi)
‫280 dpi (280dpi) ‫144MB
‫320 dpi‏ (xhdpi) ‫192MB
‫360 dpi (360dpi) 240MB
‫400 dpi (400dpi) ‫288MB
‫420 dpi (420dpi) ‫336MB
‫480 dpi (xxhdpi) ‫384MB
‫560 dpi (560dpi) ‫576MB
‫640 dpi ‏ (xxxhdpi) ‫768MB

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

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

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

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

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

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

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

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

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

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

  • ‫[C-5-1] חובה לכבד את שיטת ה-API‏ NotificationChannel.setShowBadge(). במילים אחרות, אם הערך מוגדר כ-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 ברשת בגודל סטנדרטי. פרטים נוספים מופיעים בהנחיות לעיצוב ווידג'טים לאפליקציות במסמכי ה-SDK של Android.
  • יכול להיות שתהיה תמיכה בווידג'טים של אפליקציות במסך הנעילה.

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

‫3.8.3. התראות

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

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

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

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

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

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

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

  • ‫[C-3-1] חובה להשתמש בתצוגת ההתראה הקופצת ובמשאבים כמו שמתואר במחלקת ה-API ‏Notification.Builder כשמוצגות התראות קופצות.
3.8.3.2. שירות מאזין של התראות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

‫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 ולתמוך בממשקי IME API כפי שמוגדר במסמכי ה-SDK של Android.
  • ‫[C-1-2] חובה לספק מנגנון שנגיש למשתמשים כדי להוסיף ולהגדיר שיטות קלט של צד שלישי בתגובה ל-intent ‏android.settings.INPUT_METHOD_SETTINGS.

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

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

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

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

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

‫Android כולל תמיכה בשומרי מסך אינטראקטיביים, שנקראו בעבר Dreams. שומרי מסך מאפשרים למשתמשים ליצור אינטראקציה עם אפליקציות כשמכשיר שמחובר למקור מתח נמצא במצב לא פעיל או כשהוא מחובר למעמד שולחני. יכול להיות שמכשירי Android Watch יטמיעו שומרי מסך, אבל סוגים אחרים של הטמעות במכשירים צריכים לכלול תמיכה בשומרי מסך ולספק למשתמשים אפשרות הגדרה של שומרי מסך בתגובה ל-intent‏ android.settings.DREAM_SETTINGS.

‫3.8.12. מיקום

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

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.
  • צריכה להיות תמיכה בגוון העור ובאמוג'י של משפחות מגוונות, כפי שמפורט בדוח הטכני של Unicode מספר 51.

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

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

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

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

  • ‫[C-1-1] חובה להטמיע מצבים כאלה של ריבוי חלונות בהתאם להתנהגויות של האפליקציה ולממשקי ה-API שמתוארים בתיעוד התמיכה במצב ריבוי חלונות ב-Android SDK, ולעמוד בדרישות הבאות:
  • ‫[C-1-2] אפליקציות יכולות לציין אם הן מסוגלות לפעול במצב מרובה חלונות בקובץ AndroidManifest.xml, באופן מפורש על ידי הגדרת מאפיין android:resizeableActivity לערך true או באופן מרומז על ידי הגדרת targetSdkVersion > 24. אסור להפעיל במצב ריבוי חלונות אפליקציות שבהן המאפיין הזה מוגדר במניפסט כ-false. יכול להיות שאפליקציות ישנות עם targetSdkVersion < 24 שלא הוגדר בהן המאפיין android:resizeableActivity יופעלו במצב ריבוי חלונות, אבל המערכת חייבת להציג אזהרה שלפיה יכול להיות שהאפליקציה לא תפעל כצפוי במצב ריבוי חלונות.
  • ‫[C-1-3] אסור להציע מצב מסך מפוצל או מצב חלונות חופשיים אם גובה המסך < 440dp ורוחב המסך < 440dp.
  • הטמעות של מכשירים עם גודל מסך 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] חובה להקצות רוחב וגובה מינימליים של 108dp לחלון PIP ורוחב מינימלי של 240dp וגובה של 135dp לחלון PIP כאשר Configuration.uiMode מוגדר כ-UI_MODE_TYPE_TELEVISION

‫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.
  • ‫[C-1-3] חובה להצהיר על תמיכה בפרופילים מנוהלים באמצעות android.software.managed_users דגל התכונה, אלא אם המכשיר מוגדר כך שהוא ידווח על עצמו כמכשיר עם זיכרון RAM נמוך או כך שהוא יקצה אחסון פנימי (לא ניתן להסרה) כאחסון משותף.

‫3.9.1 הקצאת מכשירים

‫3.9.1.1 הקצאת הרשאות לבעלי המכשיר

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

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

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

‫3.10. נגישות

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

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

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

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

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

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

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

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

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

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

‫3.12. TV Input Framework

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

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

  • ‫[C-1-1] חובה להצהיר על תכונת הפלטפורמה android.software.live_tv.
  • ‫[C-1-2] חובה לטעון מראש אפליקציה לטלוויזיה (TV App) ולעמוד בכל הדרישות שמתוארות בקטע 3.12.1.

3.12.1. אפליקציית טלוויזיה

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

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

אפליקציית הטלוויזיה שנדרשת להטמעות במכשירי Android שמצהירות על דגל התכונה android.software.live_tv, חייבת לעמוד בדרישות הבאות:

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

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

‫3.12.1.1. מדריך תוכניות אלקטרוני

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

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

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

  • ‫[C-1-1] חובה לאפשר ניווט בפונקציות הבאות באמצעות מקשי החיצים, החזרה והבית במכשירי הקלט של מכשיר Android TV (כלומר, בשלט רחוק, באפליקציית שלט רחוק או בבקר משחקים):

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

  • צריך להעביר אירועים מרכזיים אל כניסות HDMI באמצעות CEC.

‫3.12.1.3. קישור אפליקציות לקלט טלוויזיה

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

‫3.12.1.4. הזזה של ציר הזמן

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

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

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

  • ‫[SR] מומלץ מאוד לתמוך בהקלטת תוכניות טלוויזיה.
  • אם קלט הטלוויזיה תומך בהקלטה וההקלטה של תוכנית מסוימת לא אסורה, יכול להיות שהמדריך האלקטרוני לתוכניות יספק דרך להקליט תוכנית.

‫3.13. הגדרות מהירות

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

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

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

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

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

  • ‫[C-1-1] חובה להציג סמלים של MediaItem וסמלי התראות ללא שינוי.
  • ‫[C-1-2] חובה להציג את הפריטים האלה כפי שמתואר ב-MediaSession, למשל מטא-נתונים, סמלים, תמונות.
  • ‫[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 שלהן מוגדר כ-"ephemeral".
  • ‫[C-0-2] לאפליקציות ללא התקנה אסור לקיים אינטראקציה עם אפליקציות מותקנות באמצעות intent משתמע, אלא אם אחד מהתנאים הבאים מתקיים:
    • מסנן דפוסי ה-Intent של הרכיב חשוף וכולל CATEGORY_BROWSABLE
    • הפעולה היא אחת מהפעולות ACTION_SEND, ‏ ACTION_SENDTO, ‏ ACTION_SEND_MULTIPLE
    • היעד נחשף באופן מפורש באמצעות android:visibleToInstantApps
  • ‫[C-0-3] אסור לאפליקציות ללא התקנה ליצור אינטראקציה באופן מפורש עם אפליקציות מותקנות, אלא אם הרכיב נחשף באמצעות android:visibleToInstantApps.
  • ‫[C-0-4] אפליקציות מותקנות לא יכולות לראות פרטים על אפליקציות ללא התקנה במכשיר, אלא אם האפליקציה ללא התקנה מתחברת באופן מפורש לאפליקציה המותקנת.

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

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

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

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

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

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

  • ‫[C-0-1] חובה שתהיה אפשרות להתקין ולהפעיל קובצי Android ‏(‎.apk) שנוצרו על ידי הכלי aapt שכלול ב-Android SDK הרשמי.
  • הדרישה שלמעלה עשויה להיות מאתגרת, ולכן מומלץ להשתמש במערכת לניהול חבילות של הטמעת ההפניה של AOSP.
  • ‫[C-0-2] חובה לתמוך באימות קבצים מסוג ‎.apk באמצעות APK Signature Scheme v2 וחתימה על JAR.
  • ‫[C-0-3] אסור להרחיב את הפורמטים .apk, Android Manifest, Dalvik bytecode או RenderScript bytecode באופן שימנע את ההתקנה וההפעלה התקינות של הקבצים האלה במכשירים תואמים אחרים.
  • ‫[C-0-4] אסור לאפשר לאפליקציות אחרות מלבד 'המתקין הרשמי' הנוכחי של החבילה להסיר את האפליקציה בשקט ללא הנחיה כלשהי, כפי שמתואר ב-SDK להרשאה DELETE_PACKAGE. החריגים היחידים הם אפליקציית אימות החבילות של המערכת שמטפלת ב-Intent ‏PACKAGE_NEEDS_VERIFICATION ואפליקציית ניהול האחסון שמטפלת ב-Intent ‏ACTION_MANAGE_STORAGE.

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

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

הטמעות של מכשירים חייבות לכלול פעילות שמטפלת ב-Intent‏ android.settings.MANAGE_UNKNOWN_APP_SOURCES. הם צריכים לספק למשתמשים אפשרות להעניק או לבטל את ההרשאה להתקין אפליקציות ממקורות לא ידועים לכל אפליקציה, אבל הם יכולים לבחור ליישם את זה כפעולה שלא עושה כלום ולהחזיר RESULT_CANCELED עבור startActivityForResult(), אם ההטמעה במכשיר לא מאפשרת למשתמשים לבחור את האפשרות הזו. אבל גם במקרים כאלה, הם צריכים להסביר למשתמש למה לא מוצגת לו אפשרות כזו.

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

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

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

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

  • SHOULD aim for minimum codec latency, in others words, they
    • אסור לצרוך ולאחסן מאגרי קלט, וצריך להחזיר מאגרי קלט רק אחרי העיבוד.
    • אסור לשמור מאגרי מידע מפוענחים למשך זמן ארוך יותר מהזמן שצוין בתקן (למשל 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

‫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-5] FLAC
  • ‫[C-1-6] MP3
  • ‫[C-1-7] MIDI
  • ‫[C-1-8] Vorbis
  • ‫[C-1-9] PCM/WAVE
  • ‫[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] מטא-נתונים של טווח דינמי חייבים להיות בהתאם להגדרה של 'בקרת טווח דינמי (DRC)' בתקן ISO/IEC 14496-3, וandroid.media.MediaFormat מפתחות DRC להגדרת התנהגויות שקשורות לטווח הדינמי של מפענח האודיו. מפתחות ה-AAC DRC הוצגו ב-API 21 והם: KEY_AAC_DRC_ATTENUATION_FACTOR,‏ KEY_AAC_DRC_BOOST_FACTOR,‏ KEY_AAC_DRC_HEAVY_COMPRESSION,‏ KEY_AAC_DRC_TARGET_REFERENCE_LEVEL ו-KEY_AAC_ENCODED_TARGET_LEVEL

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

פורמט/קודק פרטים סוגי קבצים/פורמטים של קונטיינרים שנתמכים
פרופיל MPEG-4 AAC
(AAC LC) 		תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם תדירויות דגימה סטנדרטיות מ-8 עד 48 קילוהרץ.
  • ‫3GPP ‏(‎.3gp)
  • ‫MPEG-4 ‏(‎.mp4,‏ ‎.m4a)
  • ‫ADTS raw AAC ‏ (.aac, לא נתמך ADIF)
  • ‫MPEG-TS ‏(‎.ts, לא ניתן לחיפוש)
פרופיל MPEG-4 HE AAC ‏ (AAC+) תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם תדירויות דגימה רגילות מ-16 עד 48 קילוהרץ.
‫MPEG-4 HE AACv2
פרופיל (AAC+ משופר) 		תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם תדירויות דגימה רגילות מ-16 עד 48 קילוהרץ.
‫AAC ELD (קידוד AAC עם זמן אחזור נמוך משופר) תמיכה בתוכן מונו או סטריאו עם תדירויות דגימה סטנדרטיות מ-16 עד 48 קילוהרץ.
AMR-NB 4.75 עד 12.2 kbps נדגמו ב-8 kHz ‫3GPP ‏(‎.3gp)
AMR-WB ‫9 קצבים מ-6.60 kbit/s עד 23.85 kbit/s בדגימה של ‎16 kHz
FLAC מונו/סטריאו (ללא מספר ערוצים). תדירויות דגימה של עד 48kHz (אבל מומלץ להשתמש בתדירות דגימה של עד 44.1kHz במכשירים עם פלט של 44.1kHz, כי דגימת יתר מ-48kHz ל-44.1kHz לא כוללת מסנן מעביר נמוכים). מומלץ 16 ביט; לא מוחל דית'רינג ל-24 ביט. ‫FLAC (.flac) בלבד
MP3 מונו/סטריאו, קצב העברת נתונים קבוע (CBR) או משתנה (VBR) של 8-320Kbps MP3‏ (‎.mp3)
MIDI ‫MIDI Type 0 ו-1. גרסה 1 וגרסה 2 של DLS. XMF ו-Mobile XMF. תמיכה בפורמטים של רינגטונים RTTTL/RTX,‏ OTA ו-iMelody
  • סוג 0 ו-1 (‎.mid,‏ ‎.xmf,‏ ‎.mxmf)
  • ‫RTTTL/RTX ‏(‎.rtttl, ‏‎.rtx)
  • OTA ‏(‎.ota)
  • iMelody ‏ (.imy)
Vorbis
  • ‫Ogg ‏ (.ogg)
  • ‫Matroska ‏ (.mkv, ‏ Android 4.0 ואילך)
PCM/WAVE ‫PCM ליניארי של 16 ביט (שיעורים עד למגבלת החומרה). המכשירים חייבים לתמוך בתדירויות דגימה להקלטת PCM גולמי בתדירויות של 8,000, 11,025, 16,000 ו-44,100 הרץ. WAVE ‏(‎.wav)
Opus ‫Matroska ‏(‎.mkv), ‏ Ogg ‏(‎.ogg)

‫5.1.4. קידוד תמונות

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

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

  • ‫[C-0-1] JPEG
  • ‫[C-0-2] PNG
  • ‫[C-0-3] WebP

‫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] גולמי

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

פורמט/קודק פרטים סוגי קבצים/פורמטים של קונטיינרים שנתמכים
JPEG בסיסית + הדרגתית ‫JPEG ‏(‎.jpg)
GIF ‫GIF ‏(‎.gif)
PNG ‫PNG ‏(‎.png)
BMP BMP ‏(‎.bmp)
WebP WebP ‏(‎.webp)
גולמי ‫ARW ‏ (.arw), ‏ CR2 ‏ (.cr2), ‏ DNG ‏ (.dng), ‏ NEF ‏ (.nef), ‏ NRW ‏ (.nrw), ‏ ORF ‏ (.orf), ‏ PEF ‏ (.pef), ‏ RAF ‏ (.raf), ‏ RW2 ‏ (.rw2), ‏ SRW ‏ (.srw)

‫5.1.7. קודקים של סרטונים

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

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

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

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

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

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

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

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

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

פורמט/קודק פרטים סוגי קבצים נתמכים/
פורמטים של קונטיינרים
H.263
  • ‫3GPP ‏(‎.3gp)
  • ‫MPEG-4 ‏(‎.mp4)
H.264 AVC פרטים נוספים מופיעים בסעיף 5.2 ובסעיף 5.3.
  • ‫3GPP ‏(‎.3gp)
  • ‫MPEG-4 ‏(‎.mp4)
  • ‫MPEG-2 TS ‏ (.ts, אודיו AAC בלבד, לא ניתן לחיפוש, Android 3.0 ואילך)
H.265 HEVC פרטים נוספים מופיעים בקטע 5.3. ‫MPEG-4 ‏(‎.mp4)
MPEG-2 פרופיל ראשי MPEG2-TS
MPEG-4 SP ‫3GPP ‏(‎.3gp)
VP8 פרטים נוספים מופיעים בסעיף 5.2 ובסעיף 5.3.
VP9 פרטים נוספים מופיעים בקטע 5.3.

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) שניתנים להגדרה באופן דינמי עבור המקודד הנתמך.

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 עבור פרופיל הבסיס.
  • ‫[C-1-2] חובה לתמוך בפרופילים של קידוד וידאו באיכות רגילה (SD) שמפורטים בטבלה הבאה.
  • צריכה לתמוך ברמה 4 של פרופיל ראשי.
  • צריכה להיות תמיכה בפרופילים של קידוד וידאו באיכות HD (High Definition) כמו שמצוין בטבלה הבאה.

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

  • ‫[C-2-1] חובה לתמוך בפרופילי הקידוד שבטבלה הבאה.
איכות רגילה (SD) איכות רגילה (SD) HD 720p HD 1080p
רזולוציית וידאו ‫320 x 240 פיקסלים ‫720 x 480 פיקסלים ‫‎1280 x 720 פיקסלים ‎1,920 x 1,080 פיקסלים
קצב פריימים של סרטון ‫20 פריימים לשנייה ‫30 פריימים לשנייה ‫30 פריימים לשנייה ‫30 פריימים לשנייה
קצב העברת נתונים של וידאו ‫384 Kbps 2 Mbps 4Mbps 10Mbps

‫5.2.3. VP8

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

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

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

  • ‫[C-2-1] חובה לתמוך בפרופילי הקידוד שבטבלה הבאה.
איכות רגילה (SD) איכות רגילה (SD) HD 720p HD 1080p
רזולוציית וידאו ‫320 x 180 px ‫640 x 360 פיקסלים ‫‎1280 x 720 פיקסלים ‎1,920 x 1,080 פיקסלים
קצב פריימים של סרטון ‫30 פריימים לשנייה ‫30 פריימים לשנייה ‫30 פריימים לשנייה ‫30 פריימים לשנייה
קצב העברת נתונים של וידאו ‫800 Kbps 2 Mbps 4Mbps 10Mbps

‫5.2.4. VP9

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

  • צריכה להיות תמיכה בכתיבת קובצי Matroska WebM.

5.3. פענוח סרטונים

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

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

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

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

‫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 Profile ו-Main Profile Level 3.1 (כולל 720p30).
  • צריכה להיות אפשרות לפענוח סרטונים עם פרופילים של HD (איכות גבוהה) כמו שמצוין בטבלה הבאה.

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

  • ‫[C-2-1] חובה לתמוך בפרופילים של קידוד וידאו באיכות HD 720p בטבלה הבאה.
  • ‫[C-2-2] חובה לתמוך בפרופילים של קידוד וידאו באיכות HD 1080p בטבלה הבאה.
איכות רגילה (SD) איכות רגילה (SD) HD 720p HD 1080p
רזולוציית וידאו ‫320 x 240 פיקסלים ‫720 x 480 פיקסלים ‫‎1280 x 720 פיקסלים ‎1,920 x 1,080 פיקסלים
קצב פריימים של סרטון ‫30 פריימים לשנייה ‫30 פריימים לשנייה ‫60 פריימים לשנייה ‫30 פריימים לשנייה (60 פריימים לשנייהטלוויזיה)
קצב העברת נתונים של וידאו ‫800 Kbps 2 Mbps 8Mbps ‎20 Mbps

‫5.3.5. H.265 (‏HEVC)

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

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

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

  • ‫[C-2-1] הטמעות של מכשירים חייבות לתמוך בפענוח של לפחות אחד מהפורמטים H.265 או VP9 של פרופילים ברזולוציות 720, ‏ 1080 ו-UHD.
איכות רגילה (SD) איכות רגילה (SD) HD 720p HD 1080p UHD
רזולוציית וידאו ‫352 x 288 פיקסלים ‫720 x 480 פיקסלים ‫‎1280 x 720 פיקסלים ‎1,920 x 1,080 פיקסלים ‫3,840 x 2,160 פיקסלים
קצב פריימים של סרטון ‫30 פריימים לשנייה ‫30 פריימים לשנייה ‫30 פריימים לשנייה ‫30/60 fps (60 fpsטלוויזיה עם פענוח חומרה H.265) ‫60 פריימים לשנייה
קצב העברת נתונים של וידאו ‎600 Kbps ‫1.6 Mbps 4Mbps ‎5 Mbps ‎20 Mbps

‫5.3.6. VP8

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

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

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

  • ‫[C-2-1] הטמעות של מכשירים חייבות לתמוך בפרופילים של 720p בטבלה הבאה.
  • ‫[C-2-2] הטמעות של מכשירים חייבות לתמוך בפרופילים של 1080p בטבלה הבאה.
איכות רגילה (SD) איכות רגילה (SD) HD 720p HD 1080p
רזולוציית וידאו ‫320 x 180 px ‫640 x 360 פיקסלים ‫‎1280 x 720 פיקסלים ‎1,920 x 1,080 פיקסלים
קצב פריימים של סרטון ‫30 פריימים לשנייה ‫30 פריימים לשנייה ‫30 פריימים לשנייה (60 פריימים לשנייהטלוויזיה) ‫30 (60 פריימים לשנייהטלוויזיה)
קצב העברת נתונים של וידאו ‫800 Kbps 2 Mbps 8Mbps ‎20 Mbps

‫5.3.7. VP9

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

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

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

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

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

  • ‫[C-3-1] הטמעות של מכשירים חייבות לתמוך בפענוח של לפחות אחד מהפרופילים VP9 או H.265 של 720, ‏ 1080 ו-UHD.
איכות רגילה (SD) איכות רגילה (SD) HD 720p HD 1080p UHD
רזולוציית וידאו ‫320 x 180 px ‫640 x 360 פיקסלים ‫‎1280 x 720 פיקסלים ‎1,920 x 1,080 פיקסלים ‫3,840 x 2,160 פיקסלים
קצב פריימים של סרטון ‫30 פריימים לשנייה ‫30 פריימים לשנייה ‫30 פריימים לשנייה ‫30 פריימים לשנייה (60 פריימים לשנייהטלוויזיה עם פענוח חומרה VP9) ‫60 פריימים לשנייה
קצב העברת נתונים של וידאו ‎600 Kbps ‫1.6 Mbps 4Mbps ‎5 Mbps ‎20 Mbps

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

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

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

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

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

  • פורמט: Linear PCM, ‏ 16 ביט

  • תדירויות דגימה: 8,000,‏ 11,025,‏ 16,000,‏ 44,100 הרץ

  • ערוצים: מונו

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

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

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

  • פורמט: Linear PCM, ‏ 16 ביט

  • תדירויות דגימה: 22,050,‏ 48,000 הרץ
  • ערוצים: סטריאו

אם הטמעות המכשיר מאפשרות רדיו 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.
  • מומלץ להקליט את זרם האודיו של זיהוי הדיבור עם רגישות קלט מוגדרת כך שמקור של עוצמת קול של 90dB‏ (SPL) בתדר של 1,000Hz יניב RMS של 2,500 לדגימות של 16 ביט.
  • צריך להקליט את זרם האודיו של זיהוי הדיבור, כך שרמות המשרעת של ה-PCM יעקבו באופן לינארי אחרי שינויים ב-SPL של הקלט בטווח של 30dB לפחות, מ-‎-18 dB עד ‎+12 dB re 90 dB 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.5. הפעלת האודיו

מערכת Android כוללת תמיכה שמאפשרת לאפליקציות להפעיל אודיו דרך ציוד היקפי של פלט אודיו, כפי שמוגדר בסעיף 7.8.2.

5.5.1. הפעלת אודיו גולמי

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

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

    • פורמט: Linear PCM, ‏ 16 ביט
    • תדירויות דגימה: 8000, ‏ 11025, ‏ 16000, ‏ 22050, ‏ 32000, ‏ 44100
    • ערוצים: מונו, סטריאו

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

    • תדירויות דגימה: 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.
  • צריך לתמוך בהטמעות של EFFECT_TYPE_BASS_BOOST,‏ EFFECT_TYPE_ENV_REVERB,‏ EFFECT_TYPE_PRESET_REVERB ו-EFFECT_TYPE_VIRTUALIZER שניתן לשלוט בהן באמצעות מחלקות המשנה AudioEffect BassBoost,‏ EnvironmentalReverb,‏ PresetReverb ו-Virtualizer.

‫5.5.3 עוצמת הקול של פלט האודיו

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

  • מומלץ לאפשר כוונון של עוצמת הקול בנפרד לכל אחד משידורי האודיו באמצעות סוג התוכן או השימוש כפי שמוגדר על ידי AudioAttributes והשימוש באודיו ברכב כפי שמוגדר באופן ציבורי ב-android.car.CarAudioManager.

5.6. זמן אחזור אודיו

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

לצורך הסעיף הזה, משתמשים בהגדרות הבאות:

  • זמן האחזור של הפלט. המרווח בין הזמן שבו אפליקציה כותבת פריים של נתונים שמקודדים ב-PCM לבין הזמן שבו הצליל התואם מוצג לסביבה במתמר במכשיר, או שהאות יוצא מהמכשיר דרך יציאה וניתן לצפייה חיצונית.
  • זמן האחזור של פלט ראשוני. זמן האחזור של הפלט של הפריים הראשון, כשהמערכת של פלט האודיו הייתה במצב לא פעיל וכבויה לפני הבקשה.
  • זמן טעינה רציף של פלט. השהיית הפלט של פריים עוקב, אחרי שהמכשיר מפעיל אודיו.
  • זמן האחזור של הקלט. המרווח בין הרגע שבו הסביבה מציגה צליל למכשיר במתמר במכשיר או שאות נכנס למכשיר דרך יציאה, לבין הרגע שבו אפליקציה קוראת את המסגרת המתאימה של נתונים שמקודדים ב-PCM.
  • הקלט אבד. החלק הראשוני של אות קלט שלא ניתן להשתמש בו או שהוא לא זמין.
  • זמן אחזור של קלט במצב התחלתי. סכום הזמן של אובדן הקלט וזמן האחזור של הקלט עבור הפריים הראשון, כשמערכת קלט האודיו הייתה במצב לא פעיל וכבויה לפני הבקשה.
  • זמן אחזור ארוך של קלט. השהיית הקלט של פריים עוקב, בזמן שהמכשיר מקליט אודיו.
  • cold output jitter. השונות בין מדידות נפרדות של ערכי זמן האחזור של פלט קר.
  • cold input jitter. השונות בין מדידות נפרדות של ערכי זמן האחזור של קלט במצב התחלתי (cold start).
  • זמן טעינה רציף הלוך ושוב. סכום חביון הקלט הרציף, חביון הפלט הרציף ותקופת מאגר אחת. תקופת ההשהיה מאפשרת לאפליקציה לעבד את האות ולצמצם את ההפרש בין השלב של זרמי הקלט והפלט.
  • ‫OpenSL ES PCM buffer queue API. קבוצת ממשקי ה-API של OpenSL ES שקשורים ל-PCM בתוך Android NDK.
  • ‫AAudio native audio API. קבוצת ממשקי ה-API של AAudio בתוך Android NDK.

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

  • ‫[SR] זמן אחזור של 100 אלפיות השנייה או פחות בפלט של הפעלה קרה
  • ‫[SR] זמן האחזור של הפלט הרציף הוא 45 אלפיות שנייה או פחות
  • ‫[SR] מזעור הג'יטר של פלט קר

אם הטמעות המכשירים עומדות בדרישות שלמעלה אחרי כל כיול ראשוני כשמשתמשים ב-OpenSL ES PCM buffer queue API, לזמן אחזור רציף של פלט ולזמן אחזור של פלט במצב לא פעיל לפחות במכשיר אחד נתמך של פלט אודיו, הן:

  • ‫[SR] מומלץ מאוד לדווח על אודיו עם השהיה נמוכה על ידי הצהרה על דגל התכונה android.hardware.audio.low_latency.
  • [SR] מומלץ מאוד לעמוד גם בדרישות לאודיו עם זמן אחזור נמוך באמצעות AAudio API.

אם הטמעות של מכשירים לא עומדות בדרישות לאודיו עם השהיה נמוכה באמצעות ממשק ה-API של תור מאגר ה-PCM של OpenSL ES, הן:

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

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

  • ‫[SR] זמן אחזור של קלט קר של 100 אלפיות השנייה או פחות
  • ‫[SR] זמן אחזור רציף של קלט של 30 אלפיות השנייה או פחות
  • ‫[SR] זמן אחזור הלוך ושוב רציף של 50 אלפיות השנייה או פחות
  • ‫[SR] מזעור הג'יטר של קלט קר

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

פורמטים של פלחים במדיה

פילוח לפי פורמטים הפניה/ות תמיכה נדרשת ב-Codec
MPEG-2 Transport Stream ISO 13818 קודקים של וידאו:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
פרטים על H264 AVC, ‏ MPEG2-4 SP,‏
ו-MPEG-2 זמינים בקטע 5.1.3.

קודק אודיו:

  • קובץ AAC
פרטים על AAC והווריאציות שלו מופיעים בסעיף 5.1.1.
‫AAC עם מסגור ADTS ותגי ID3 ISO 13818-7 פרטים על AAC והווריאציות שלו מופיעים בסעיף 5.1.1
WebVTT WebVTT

RTSP ‏ (RTP, ‏ SDP)

שם הפרופיל הפניה/ות תמיכה נדרשת ב-Codec
H264 AVC RFC 6184 פרטים על H264 AVC מופיעים בסעיף 5.1.3
MP4A-LATM RFC 6416 פרטים על AAC והווריאציות שלו מופיעים בסעיף 5.1.1
H263-1998 ‫RFC 3551
RFC 4629
RFC 2190 		פרטים נוספים על H263 מופיעים בסעיף 5.1.3
H263-2000 RFC 4629 פרטים נוספים על H263 מופיעים בסעיף 5.1.3
AMR RFC 4867 פרטים נוספים על AMR-NB מופיעים בסעיף 5.1.1
AMR-WB RFC 4867 פרטים על AMR-WB מופיעים בסעיף 5.1.1
MP4V-ES RFC 6416 פרטים נוספים על MPEG-4 SP זמינים בקטע 5.1.3
mpeg4-generic RFC 3640 פרטים על AAC והווריאציות שלו מופיעים בסעיף 5.1.1
MP2T RFC 2250 פרטים נוספים זמינים בקטע MPEG-2 Transport Stream שמתחת לקטע HTTP Live Streaming

5.8. Secure Media

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

  • ‫[C-1-1] חובה להצהיר על תמיכה ב-Display.FLAG_SECURE.

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

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

אם הטמעות של מכשירים מצהירות על תמיכה ב-Display.FLAG_SECURE ותומכות בצג חיצוני קווי, הן:

  • ‫[C-3-1] חובה לתמוך ב-HDCP בגרסה 1.2 ומעלה בכל המסכים החיצוניים שמחוברים באמצעות כבל.

5.9. ממשק דיגיטלי לכלים מוזיקליים (MIDI)

אם הטמעות של מכשירים מדווחות על תמיכה בתכונה android.software.midi באמצעות המחלקה android.content.pm.PackageManager, הן:

  • ‫[C-1-1] חובה לתמוך ב-MIDI בכל תשתית תקשורת חומרה עם תמיכה ב-MIDI, שבה מסופקת קישוריות כללית שאינה MIDI, כאשר תשתית התקשורת היא:

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

5.10. אודיו מקצועי

אם הטמעות של מכשירים מדווחות על תמיכה בתכונה android.hardware.audio.pro באמצעות המחלקה android.content.pm.PackageManager, הן:

  • ‫[C-1-1] חובה לדווח על תמיכה בתכונה android.hardware.audio.low_latency.
  • ‫[C-1-2] זמן האחזור הרציף של האודיו הלוך ושוב, כפי שמוגדר בקטע 5.6 בנושא זמן האחזור של האודיו, חייב להיות 20 אלפיות השנייה או פחות, ומומלץ שיהיה 10 אלפיות השנייה או פחות, לפחות בנתיב נתמך אחד.
  • ‫[C-1-3] חובה לכלול יציאות USB שתומכות במצב מארח USB ובמצב ציוד היקפי USB.
  • ‫[C-1-4] חובה לדווח על תמיכה בתכונה android.software.midi.
  • ‫[C-1-5] חייב לעמוד בדרישות של זמן האחזור והשמע ב-USB באמצעות ה-API של תור מאגר PCM של OpenSL ES.
  • ‫[SR] מומלץ מאוד לספק רמה עקבית של ביצועי CPU בזמן שהאודיו פעיל ועומס ה-CPU משתנה. צריך לבדוק את זה באמצעות SimpleSynth commit 1bd6391. צריך להריץ את אפליקציית SimpleSynth עם הפרמטרים שבהמשך, ולהגיע לאפס הפסקות אחרי 10 דקות:
    • מחזורי עבודה: 200,000
    • טעינה משתנה: מופעל (ההגדרה הזו תעבור בין 100% ל-10% של ערך מחזורי העבודה כל 2 שניות, והיא מיועדת לבדיקת התנהגות של בקרת מהירות המעבד)
    • טעינה עם ייצוב: כבוי
  • מומלץ לצמצם את אי הדיוק והסחיפה של שעון האודיו ביחס לזמן הרגיל.
  • צריך לצמצם את הסחף של שעון האודיו ביחס למעבד CLOCK_MONOTONIC כששניהם פעילים.
  • מומלץ לצמצם את השהיית האודיו במתמרים במכשיר.
  • מומלץ לצמצם את זמן האחזור של האודיו ב-USB דיגיטלי.
  • מומלץ לתעד את מדידות זמן האחזור של האודיו בכל הנתיבים.
  • צריך למזער את הג'יטר בזמני הכניסה של הקריאה החוזרת להשלמת מאגר השמע, כי זה משפיע על אחוז רוחב הפס המלא של המעבד שניתן לשימוש על ידי הקריאה החוזרת.
  • מומלץ לספק אפס חוסרים (פלט) או עודפים (קלט) באודיו בשימוש רגיל בזמן האחזור המדווח.
  • צריך לספק אפס הבדלים בזמן האחזור בין הערוצים.
  • צריך למזער את זמן האחזור הממוצע של MIDI בכל אמצעי התקשורת.
  • צריך למזער את השונות בזמן האחזור של MIDI בעומס (jitter) בכל אמצעי התקשורת.
  • צריך לספק חותמות זמן מדויקות של MIDI בכל אמצעי התקשורת.
  • צריך לצמצם את הרעש באות האודיו במתמרים במכשיר, כולל התקופה מיד אחרי הפעלה במצב התחלתי.
  • מומלץ לספק אפס הפרש בשעון האודיו בין הצד של הקלט לבין הצד של הפלט בנקודות קצה תואמות, כששניהם פעילים. דוגמאות לנקודות קצה תואמות כוללות את המיקרופון והרמקול במכשיר, או את הקלט והפלט של שקע האודיו.
  • צריך לטפל בקריאות חוזרות (callback) להשלמת מאגר האודיו בצדדי הקלט והפלט של נקודות קצה תואמות באותו השרשור, כששניהם פעילים, ולהיכנס לקריאה החוזרת של הפלט מיד אחרי החזרה מהקריאה החוזרת של הקלט. לחלופין, אם אי אפשר לטפל בקריאות החוזרות (callback) באותו השרשור, צריך להזין את הקריאה החוזרת של הפלט זמן קצר אחרי הזנת הקריאה החוזרת של הקלט, כדי לאפשר לאפליקציה תזמון עקבי של צדדי הקלט והפלט.
  • מומלץ לצמצם את הפרש הפאזה בין אחסון האודיו ב-HAL בצד הקלט ובצד הפלט של נקודות קצה תואמות.
  • צריך למזער את זמן הטעינה של המגע.
  • צריך למזער את השונות בזמן האחזור של המגע בעומס (ג'יטר).

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

אם ההטמעות במכשירים עומדות בדרישות באמצעות ממשק ה-API של תור מאגר ה-PCM של OpenSL ES, הן:

  • ‫[SR] מומלץ מאוד לעמוד באותן דרישות גם באמצעות AAudio API.

אם הטמעות המכשירים כוללות שקע אודיו של 3.5 מ"מ עם 4 מוליכים, הן:

אם יישומי המכשיר לא כוללים שקע אודיו בגודל 3.5 מ"מ עם 4 מוליכים, וכוללים יציאות USB שתומכות במצב מארח USB, הם:

  • ‫[C-3-1] חובה להטמיע את מחלקת האודיו של USB.
  • ‫[C-3-2] חובה שזמן האחזור של האודיו הלוך ושוב יהיה רציף ויעמוד על 20 אלפיות השנייה או פחות ביציאת מצב המארח של ה-USB באמצעות מחלקת אודיו של USB.
  • זמן האחזור הרציף של האודיו הלוך ושוב צריך להיות 10 אלפיות השנייה או פחות ביציאת מצב המארח של ה-USB באמצעות מחלקת אודיו של USB.

אם יישומי המכשירים כוללים יציאת HDMI, הם:

  • ‫[C-4-1] חובה לתמוך בפלט בסטריאו ובשמונה ערוצים בעומק של 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 dB Full Scale עבור דגימות של נקודה צפה/דיוק כפול) לכל מיקרופון שמשמש להקלטת מקור האודיו שלא עבר עיבוד.

  • ‫[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‏ (ADB‏)‎

    • ‫[C-0-2] המכשיר חייב לתמוך בכל הפונקציות של adb כפי שמתועד ב-Android SDK, כולל dumpsys.
    • ‫[C-0-3] אסור לשנות את הפורמט או את התוכן של אירועי מערכת במכשיר (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) שנרשמים ביומן באמצעות dumpsys.
    • ‫[C-0-4] שירות ה-daemon של adb בצד המכשיר חייב להיות לא פעיל כברירת מחדל, וחייב להיות מנגנון שהמשתמש יכול לגשת אליו כדי להפעיל את Android Debug Bridge.
    • ‫[C-0-5] חובה לתמוך ב-adb מאובטח. ‫Android כולל תמיכה ב-adb מאובטח. ‫adb מאובטח מאפשר להשתמש ב-adb במארחים מאומתים מוכרים.

    • ‫[C-0-6] חובה לספק מנגנון שמאפשר להתחבר ל-adb ממכונת מארח. לדוגמה:

      • הטמעות של מכשירים ללא יציאת USB שתומכת במצב ציוד היקפי חייבות להטמיע את adb דרך רשת מקומית (כמו Ethernet או Wi-Fi).
      • חובה לספק מנהלי התקנים ל-Windows 7, ‏ 9 ו-10, כדי לאפשר למפתחים להתחבר למכשיר באמצעות פרוטוקול adb.

  • ‫Dalvik Debug Monitor Service (ddms)

    • ‫[C-0-7] חובה לתמוך בכל התכונות של ddms כפי שמתועד ב-Android SDK. מכיוון ש-ddms משתמש ב-adb, התמיכה ב-ddms צריכה להיות לא פעילה כברירת מחדל, אבל היא חייבת להיות נתמכת בכל פעם שהמשתמש מפעיל את Android Debug Bridge, כמו שמתואר למעלה.
  • קוף
    • ‫[C-0-8] חובה לכלול את מסגרת Monkey ולהפוך אותה לזמינה לשימוש באפליקציות.
  • SysTrace
    • ‫[C-0-9] חייב לתמוך בכלי systrace כפי שמתואר ב-Android SDK. הכלי Systrace צריך להיות מושבת כברירת מחדל, וחייב להיות מנגנון נגיש למשתמש להפעלת Systrace.

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

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

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

  • ‫[C-0-1] חובה לכבד את כוונת android.settings.APPLICATION_DEVELOPMENT_SETTINGS כדי להציג הגדרות שקשורות לפיתוח אפליקציות. ההטמעה של Android במעלה הזרם מסתירה את התפריט 'אפשרויות למפתחים' כברירת מחדל, ומאפשרת למשתמשים להפעיל את האפשרויות למפתחים אחרי שהם לוחצים שבע (7) פעמים על פריט התפריט הגדרות > מידע על המכשיר > מספר Build.
  • ‫[C-0-2] חובה להסתיר את האפשרויות למפתחים כברירת מחדל, וחובה לספק מנגנון להפעלת האפשרויות למפתחים בלי צורך בהוספה לרשימת ההיתרים.
  • יכול להיות שנצטרך להגביל באופן זמני את הגישה לתפריט אפשרויות הפיתוח, על ידי הסתרה חזותית או השבתה של התפריט, כדי למנוע הסחות דעת בתרחישים שבהם בטיחות המשתמש היא גורם לדאגה.

7. תאימות חומרה

אם מכשיר כולל רכיב חומרה מסוים שיש לו ממשק API תואם למפתחים של צד שלישי:

  • ‫[C-0-1] הטמעת המכשיר חייבת להטמיע את ה-API הזה כפי שמתואר במסמכי התיעוד של Android SDK.

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

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

7.1. תצוגה וגרפיקה

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

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

  • גודל פיזי באלכסון. המרחק באינצ'ים בין שתי פינות מנוגדות של החלק המואר של המסך.
  • נקודות לאינץ' (DPI). מספר הפיקסלים שכלולים בטווח לינארי אופקי או אנכי של אינץ' אחד. אם מצוינים ערכי dpi, גם ה-dpi האופקי וגם ה-dpi האנכי צריכים להיות בטווח.
  • יחס גובה-רוחב. היחס בין הפיקסלים של המימד הארוך יותר לבין הפיקסלים של המימד הקצר יותר של המסך. לדוגמה, מסך ברזולוציה של ‎480x854 פיקסלים יהיה ‎854/480 = 1.779, או בערך '16:9'.
  • פיקסל שלא תלוי בצפיפות (dp). יחידת הפיקסל הווירטואלית מנורמלת למסך של 160 dpi, ומחושבת כך: pixels = dps * (density/160).

‫7.1.1. הגדרת תצורה של מסך

7.1.1.1. גודל מסך

מסגרת ממשק המשתמש של Android תומכת במגוון גדלים שונים של פריסות מסך לוגיות, ומאפשרת לאפליקציות לשלוח שאילתה לגבי גודל פריסת המסך של ההגדרה הנוכחית באמצעות Configuration.screenLayout עם SCREENLAYOUT_SIZE_MASK ו-Configuration.smallestScreenWidthDp.

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

    • במכשירים שבהם הערך של Configuration.uiMode הוא כל ערך אחר מלבד UI_MODE_TYPE_WATCH, והגודל של Configuration.screenLayout הוא small, הגודל המינימלי של Configuration.screenLayout חייב להיות 426dp x 320dp.
    • במכשירים שמדווחים על גודל normal של Configuration.screenLayout, הגודל צריך להיות לפחות ‎480 dp x 320 dp.
    • במכשירים שמדווחים על גודל large עבור Configuration.screenLayout, הגודל המינימלי צריך להיות 640dp x 480dp.
    • במכשירים שמדווחים על גודל xlarge עבור Configuration.screenLayout, הגודל צריך להיות לפחות 960dp x 720dp.

  • ‫[C-0-2] הטמעות של מכשירים חייבות לכבד את ההצהרה של האפליקציות לגבי תמיכה בגדלי מסך באמצעות המאפיין <supports-screens> בקובץ AndroidManifest.xml, כפי שמתואר במסמכי ה-SDK של Android.

‫7.1.1.2. יחס גובה-רוחב של המסך

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

  • ‫[C-0-1] הטמעות של מכשירים עם Configuration.uiMode שהוגדר כ-UI_MODE_TYPE_NORMAL חייבות לכלול ערך של יחס גובה-רוחב בין 1.3333 ‏ (4:3) לבין 1.86 (בערך 16:9), אלא אם האפליקציה עומדת באחד מהתנאים הבאים, כך שאפשר להגדיר אותה ככזו שמוכנה למתיחה ארוכה יותר:

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

  • ‫[C-0-2] בהטמעות של מכשירים עם Configuration.uiMode שהוגדר כ-UI_MODE_TYPE_WATCH, חובה להגדיר את ערך יחס הגובה-רוחב כ-1.0 (1:1).

‫7.1.1.3. דחיסות מסך

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

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

    • ‫120 dpi (ldpi)
    • ‫160 dpi (mdpi)
    • ‫213 dpi ‏ (tvdpi)
    • ‫240 dpi‏ (hdpi)
    • ‫260 dpi ‏ (260dpi)
    • ‫280 dpi (280dpi)
    • ‫300 dpi (300dpi)
    • ‫320 dpi‏ (xhdpi)
    • ‫340 dpi (340dpi)
    • ‫360 dpi (360dpi)
    • ‫400 dpi (400dpi)
    • ‫420 dpi (420dpi)
    • ‫480 dpi (xxhdpi)
    • ‫560 dpi (560dpi)
    • ‫640 dpi ‏ (xxxhdpi)

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

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

  • ‫[C-1-1] חובה לדווח על ערכים נכונים לכל מדדי התצוגה שמוגדרים ב-API‏ android.util.DisplayMetrics.

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

  • ‫[C-2-1] חובה לדווח על ערכים סבירים לכל מדדי התצוגה שמוגדרים ב-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.0 וב-OpenGL ES 2.0, כפי שמתואר ומפורט בתיעוד Android SDK.
  • [SR] מומלץ מאוד לתמוך ב-OpenGL ES 3.0.
  • צריך לתמוך ב-OpenGL ES 3.1 או 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.
  • [SR] מומלץ מאוד לתמוך ב-EGL_KHR_partial_update.
  • צריכים לדווח בצורה מדויקת באמצעות השיטה getString() על כל פורמט דחיסה של טקסטורה שהם תומכים בו, שלרוב הוא ספציפי לספק.

אם הטמעות של מכשירים מצהירות על תמיכה ב-OpenGL ES 3.0,‏ 3.1 או 3.2, הן:

  • ‫[C-3-1] חובה לייצא את סמלי הפונקציות המתאימים לגרסאות האלה בנוסף לסמלי הפונקציות של OpenGL ES 2.0 בספרייה libGLESv2.so.

אם הטמעות המכשירים תומכות ב-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.0 או 3.1, הן:

  • ‫[SR] מומלץ מאוד לכלול תמיכה ב-Vulkan 1.0 .

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

  • מומלץ לכלול תמיכה ב-Vulkan 1.0.

הטמעות במכשירים, אם כוללות תמיכה ב-Vulkan 1.0:

  • ‫[C-1-1] חובה לדווח על ערך השלם הנכון באמצעות סימון התכונות android.hardware.vulkan.level ו-android.hardware.vulkan.version.
  • ‫[C-1-2] חובה למנות לפחות VkPhysicalDevice עבור Vulkan native API‏ vkEnumeratePhysicalDevices() .
  • ‫[C-1-3] חובה להטמיע באופן מלא את ממשקי Vulkan 1.0 API עבור כל VkPhysicalDevice שמופיע ברשימה.
  • ‫[C-1-4] חובה למנות שכבות, שנכללות בספריות מקוריות בשם libVkLayer*.so בספריית הספריות המקוריות של חבילת האפליקציה, באמצעות ממשקי ה-API המקוריים של Vulkan‏ vkEnumerateInstanceLayerProperties() ו-vkEnumerateDeviceLayerProperties() .
  • ‫[C-1-5] אסור למנות שכבות שסופקו על ידי ספריות מחוץ לחבילת האפליקציה, או לספק דרכים אחרות למעקב אחר Vulkan API או ליירוט שלו, אלא אם המאפיין android:debuggable של האפליקציה מוגדר כ-true.
  • ‫[C-1-6] חובה לדווח על כל מחרוזות התוספים שהן תומכות בהן באמצעות ממשקי ה-API המקוריים של Vulkan, ולהיפך, אסור לדווח על מחרוזות תוספים שהן לא תומכות בהן בצורה נכונה.

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

  • ‫[C-2-1] אסור להצהיר על אף אחד ממתגי ה-feature flag של Vulkan (למשל android.hardware.vulkan.level, ‏ android.hardware.vulkan.version).
  • ‫[C-2-2] אסור למנות VkPhysicalDevice עבור Vulkan native API vkEnumeratePhysicalDevices().
‫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 מסכים עם טווח צבעים רחב

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

  • ‫[C-1-1] חובה להשתמש במסך עם כיול צבעים.
  • ‫[C-1-2] חובה להשתמש במסך שטווח הצבעים שלו מכסה את טווח הצבעים sRGB באופן מלא במרחב CIE 1931 xyY.
  • ‫[C-1-3] חובה להשתמש במסך עם סולם צבעים ששטחו הוא לפחות 90% מ-NTSC 1953 במרחב CIE 1931 xyY.
  • ‫[C-1-4] המכשיר חייב לתמוך ב-OpenGL ES 3.0,‏ 3.1 או 3.2 ולדווח על כך בצורה תקינה.
  • ‫[C-1-5] חובה לפרסם תמיכה בתוספים EGL_KHR_no_config_context,‏ EGL_EXT_pixel_format_float,‏ EGL_KHR_gl_colorspace,‏ EGL_EXT_colorspace_scrgb_linear ו-EGL_GL_colorspace_display_p3.
  • [SR] מומלץ מאוד לתמוך ב-GL_EXT_sRGB.

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

  • ‫[C-2-1] צריך לכסות 100% או יותר מ-sRGB במרחב CIE 1931 xyY, למרות שסולם הצבעים של המסך לא מוגדר.

‫7.1.5. מצב תאימות לאפליקציות מדור קודם

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

‫7.1.6. טכנולוגיית המסך

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

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

  • ‫[C-0-1] המכשיר חייב לתמוך במסכים שיכולים לבצע רינדור של גרפיקה בצבע 16 ביט.
  • צריכים לתמוך בתצוגות עם גרפיקה צבעונית של 24 ביט.
  • ‫[C-0-2] חובה לתמוך במסכים שיכולים לבצע רינדור של אנימציות.
  • ‫[C-0-3] חובה להשתמש בטכנולוגיית תצוגה עם יחס גובה-רוחב של פיקסלים (PAR) בין 0.9 ל-1.15. כלומר, יחס הגובה-רוחב של הפיקסלים חייב להיות קרוב לריבוע (1.0) עם טווח שגיאה של 10% עד 15%.

‫7.1.7. מסכים משניים

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

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

  • ‫[C-1-1] חובה להטמיע את שירות המערכת ואת ה-API‏ DisplayManager כפי שמתואר במסמכי ה-SDK של Android.

7.2. התקני קלט

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

‫7.2.1. מקלדת

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

הטמעות של מכשירים: [C-0-1] אסור לכלול מקלדת חומרה שלא תואמת לאחד מהפורמטים שצוינו ב-android.content.res.Configuration.keyboard (QWERTY או 12 מקשים). צריך לכלול הטמעות נוספות של מקלדת וירטואלית. * יכול להיות שהמכשיר כולל מקלדת חומרה.

‫7.2.2. ניווט ללא מגע

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

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

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

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

‫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] מומלץ מאוד להשתמש בלחיצה ארוכה על הפונקציה HOME כאינטראקציה המיועדת הזו.

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

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

‫7.2.4. קלט ממסך מגע

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

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

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

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

  • ‫[C-1-1] חובה לדווח על TOUCHSCREEN_FINGER בשדה Configuration.touchscreen של ה-API.
  • ‫[C-1-2] חובה לדווח על סימוני התכונות android.hardware.touchscreen ו-android.hardware.faketouch

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

  • ‫[C-2-1] המכשיר חייב לדווח על דגלי התכונות המתאימים android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand בהתאם לסוג מסך המגע הספציפי במכשיר.

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

  • ‫[C-3-1] אסור לדווח על אף תג תכונה שמתחיל ב-android.hardware.touchscreen, וחובה לדווח רק על android.hardware.faketouch.

‫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] המכשיר חייב לתמוך בהצבעה כלפי מטה, ולאחר מכן לאפשר למשתמשים להזיז במהירות את האובייקט למיקום אחר במסך, ואז להצביע כלפי מעלה במסך, כדי לאפשר למשתמשים להעיף אובייקט במסך.
  • ‫[C-1-7] חובה לדווח על TOUCHSCREEN_NOTOUCH בשדה Configuration.touchscreen של API.

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

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

  • ‫[C-1-1] חובה להטמיע במוצר בקר או לשלוח אותו עם בקר נפרד בקופסה, שיאפשר להזין את כל האירועים שמפורטים בטבלאות שלמטה.
  • ‫[C-1-2] חובה שתהיה אפשרות למפות אירועי HID לקבועי Android view.InputEvent המשויכים, כפי שמפורט בטבלאות שלמטה. ההטמעה של Android ב-upstream כוללת הטמעה של בקרי משחקים שעומדת בדרישה הזו.
לחצן HID Usage2 Android Button
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
D-pad up1
D-pad down1 		0x01 0x00393 ‫AXIS_HAT_Y4
מקש החץ שמאלה1
מקש החץ ימינה1 		0x01 0x00393 AXIS_HAT_X4
הכפתור השמאלי העליון1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
הלחצן הימני העליון1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
לחיצה על המקל השמאלי1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
לחיצה על הג'ויסטיק הימני1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
דף הבית1 0x0c 0x0223 KEYCODE_HOME (3)
הקודם1 0x0c 0x0224 KEYCODE_BACK (4)

‫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 מייצג סיבוב של 0 מעלות ולחיצה על לחצן החלק העליון, בעוד שערך לוגי של 1 מייצג סיבוב של 45 מעלות ולחיצה על המקשים 'חלק עליון' ו'שמאלה'.

‫4 MotionEvent

פקדים אנלוגיים1 שימוש ב-HID Android Button
הדק שמאלי 0x02 0x00C5 AXIS_LTRIGGER
הדק ימני 0x02 0x00C4 AXIS_RTRIGGER
ג'ויסטיק שמאלי 0x01 0x0030
0x01 0x0031 		AXIS_X
AXIS_Y
ג'ויסטיק ימני 0x01 0x0032
0x01 0x0035 		AXIS_Z
AXIS_RZ

‫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] המכשיר חייב לדווח על כל המדידות של החיישנים באמצעות הערכים הרלוונטיים של היחידות הבינלאומיות (מטריות) לכל סוג חיישן, כפי שמוגדר במסמכי ה-SDK של Android.
  • ‫[C-1-2] חובה לדווח על נתוני חיישנים עם זמן אחזור מקסימלי של 100 מילי-שניות
  • ‫2 * sample_time במקרה של חיישן שמוזרם עם זמן אחזור מינימלי נדרש של 5 מילי-שניות + 2 * sample_time כשמעבד האפליקציה פעיל. העיכוב הזה לא כולל עיכובים שקשורים לסינון.
  • ‫[C-1-3] חובה לדווח על דגימת החיישן הראשונה תוך 400 מילי-שניות + 2 * sample_time מרגע הפעלת החיישן. מקובל שרמת הדיוק של המדגם הזה תהיה 0.

  • ‫[SR] צריך לדווח על שעת האירוע בננו-שניות, כפי שמוגדר במסמכי התיעוד של Android SDK. השעה הזו מייצגת את הזמן שבו האירוע קרה והיא מסונכרנת עם השעון SystemClock.elapsedRealtimeNano(). מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה, כדי שיהיה אפשר לשדרג אותם לגרסאות עתידיות של הפלטפורמה שבהן הרכיב הזה עשוי להיות חובה. שגיאת הסנכרון צריכה להיות מתחת ל-100 אלפיות השנייה.

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

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

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

הרשימה שלמעלה לא מלאה. ההתנהגות המתועדת של Android SDK והמסמכים של Android Open Source בנושא sensors הם המקור המוסמך.

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

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

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

אם יישומי המכשיר כוללים חיישן מורכב, הם:

  • ‫[C-2-1] חובה להטמיע את החיישן כפי שמתואר במסמכי התיעוד של Android Open Source בנושא חיישנים מורכבים.

‫7.3.1. מד תאוצה

  • הטמעות של מכשירים צריכות לכלול מד תאוצה ב-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 מ' לשנייה בריבוע, כאשר סטיית התקן מחושבת על בסיס כל ציר בנפרד על דגימות שנאספו במשך תקופה של לפחות 3 שניות בקצב הדגימה המהיר ביותר.
  • מומלץ מאוד להטמיע את חיישן TYPE_SIGNIFICANT_MOTION המורכב.
  • [SR] מומלץ מאוד להטמיע את חיישן TYPE_ACCELEROMETER_UNCALIBRATED אם יש אפשרות לכיול מקוון של מד התאוצה.
  • מומלץ להטמיע את חיישני TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER המורכבים כפי שמתואר במסמך Android SDK.
  • צריך לדווח על אירועים בתדירות של 200 הרץ לפחות.
  • מומלץ להשתמש ברזולוציה של 16 ביט לפחות.
  • צריך לכייל את המכשיר בזמן השימוש אם המאפיינים משתנים במהלך מחזור החיים שלו, ולשמור את פרמטרי הפיצוי בין הפעלות מחדש של המכשיר.
  • צריך להיות עם פיצוי טמפרטורה.
  • מומלץ להטמיע גם חיישן TYPE_ACCELEROMETER_UNCALIBRATED.

אם הטמעות המכשיר כוללות מד תאוצה בעל 3 צירים ואחד מהחיישנים המורכבים TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER מוטמע:

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

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

  • ‫[C-3-1] חובה להטמיע את החיישנים המורכבים TYPE_GRAVITY ו-TYPE_LINEAR_ACCELERATION.
  • מומלץ להטמיע את החיישן המורכב TYPE_GAME_ROTATION_VECTOR.
  • [SR] מומלץ מאוד להטמיע את חיישן TYPE_GAME_ROTATION_VECTOR במכשירי Android קיימים ובמכשירי Android חדשים.

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

  • ‫[C-4-1] חובה להטמיע חיישן מורכב TYPE_ROTATION_VECTOR.

‫7.3.2. מגנטומטר

  • הטמעות של מכשירים צריכות לכלול מגנטומטר (מצפן) עם 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).
  • מומלץ להטמיע חיישן TYPE_MAGNETIC_FIELD_UNCALIBRATED.
  • [SR] מומלץ מאוד להטמיע את חיישן TYPE_MAGNETIC_FIELD_UNCALIBRATED במכשירי Android קיימים ובמכשירי Android חדשים.

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

  • ‫[C-2-1] חובה להטמיע חיישן מורכב TYPE_ROTATION_VECTOR.

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

  • יכול להיות שיוטמע חיישן TYPE_GEOMAGNETIC_ROTATION_VECTOR.

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

  • ‫[C-3-1] צריכת החשמל חייבת להיות פחות מ-10mW.
  • החיישן צריך לצרוך פחות מ-3mW כשהוא רשום למצב אצווה בתדר של 10Hz.

‫7.3.3. GPS

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

  • מומלץ לכלול מקלט GPS/GNSS.

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

  • ‫[C-1-1] המכשיר חייב לתמוך בפלט של מיקום בקצב של לפחות 1 הרץ כשמבקשים זאת באמצעות LocationManager#requestLocationUpdate.
  • ‫[C-1-2] המכשיר חייב להיות מסוגל לקבוע את המיקום בתנאים של שמיים פתוחים (אותות חזקים, ריבוי נתיבים זניח, HDOP < 2) תוך 10 שניות (זמן מהיר עד לתיקון הראשון), כשהוא מחובר לחיבור אינטרנט עם מהירות נתונים של 0.5 Mbps או יותר. בדרך כלל, כדי לעמוד בדרישה הזו, משתמשים בטכניקה כלשהי של GPS/GNSS מסוג Assisted או Predicted כדי לצמצם את זמן הנעילה של GPS/GNSS (נתוני הסיוע כוללים זמן ייחוס, מיקום ייחוס ואפמריס/שעון של לוויין).
    • ‫[SR] אחרי ביצוע חישוב מיקום כזה, מומלץ מאוד שהמכשיר יוכל לקבוע את המיקום שלו, בשמיים פתוחים, תוך 10 שניות, כשבקשות המיקום מופעלות מחדש, עד שעה אחרי חישוב המיקום הראשוני, גם אם הבקשה הבאה מבוצעת ללא חיבור נתונים, או אחרי הפעלה מחדש.

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

    • ‫[C-1-3] המכשיר חייב להיות מסוגל לקבוע את המיקום בטווח של 20 מטרים, ואת המהירות בטווח של 0.5 מטרים לשנייה, לפחות ב-95% מהזמן.
    • ‫[C-1-4] חובה לעקוב אחרי לפחות 8 לוויינים מקבוצה אחת ולדווח עליהם בו-זמנית באמצעות GnssStatus.Callback.
    • המכשיר צריך להיות מסוגל לעקוב בו-זמנית אחרי לפחות 24 לוויינים מכמה קבוצות לוויינים (למשל GPS + לפחות אחת מהקבוצות Glonass,‏ Beidou,‏ Galileo).
    • ‫[C-1-5] חובה לדווח על הדור של טכנולוגיית ה-GNSS באמצעות ה-API לבדיקה getGnssYearOfHardware.
    • [SR] המשך לספק פלט מיקום רגיל של GPS/GNSS במהלך שיחת חירום.
    • ‫[SR] דיווח על מדידות GNSS מכל מערכות הניווט שנמצאות במעקב (כפי שמדווח בהודעות GnssStatus), למעט SBAS.
    • ‫[SR] דיווח על AGC ותדירות המדידה של GNSS.
    • ‫[SR] צריך לדווח על כל האומדנים של הדיוק (כולל כיוון, מהירות וגובה) כחלק מכל מיקום GPS.
    • [SR] מומלץ מאוד לעמוד בכמה שיותר מהדרישות הנוספות המחייבות למכשירים שמדווחים על השנה '2016' או '2017' דרך Test API LocationManager.getGnssYearOfHardware().

אם הטמעות במכשירים כוללות מקלט GPS/GNSS ומדווחות על היכולת לאפליקציות באמצעות תג התכונה android.hardware.location.gps ו-Test API מדווח על השנה '2016' או מאוחר יותר, הן:LocationManager.getGnssYearOfHardware()

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

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

  • ‫[C-3-1] חובה להמשיך לספק פלט רגיל של מיקום GPS/GNSS במהלך שיחת טלפון לשירותי חירום.
  • ‫[C-3-2] חובה לדווח על מדידות GNSS מכל מערכות הניווט שנמצאות במעקב (כפי שמדווח בהודעות GnssStatus), למעט SBAS.
  • ‫[C-3-3] חובה לדווח על AGC ותדירות המדידה של GNSS.
  • ‫[C-3-4] חובה לדווח על כל הערכות הדיוק (כולל כיוון, מהירות וגובה) כחלק מכל מיקום GPS.

‫7.3.4. ג'ירוסקופ

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

  • מומלץ לכלול ג'ירוסקופ (חיישן לשינוי זוויתי).
  • לא צריך לכלול חיישן ג'ירוסקופ אלא אם כלול גם מד תאוצה עם 3 צירים.

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

  • ‫[C-1-1] המכשיר חייב להיות מסוגל לדווח על אירועים בתדירות של 50 הרץ לפחות.
  • ‫[C-1-2] חובה להטמיע את חיישן TYPE_GYROSCOPE ומומלץ להטמיע גם את חיישן TYPE_GYROSCOPE_UNCALIBRATED.
  • ‫[C-1-3] חייב להיות מסוגל למדוד שינויים בכיוון עד 1,000 מעלות לשנייה.
  • ‫[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] מומלץ מאוד להטמיע את חיישן SENSOR_TYPE_GYROSCOPE_UNCALIBRATED במכשירי Android קיימים ובמכשירי Android חדשים.
  • [SR] מומלץ מאוד ששגיאת הכיול תהיה קטנה מ-0.01 רדיאן/שנייה כשהמכשיר נייח בטמפרטורת החדר.
  • צריך לדווח על אירועים בתדירות של 200 הרץ לפחות.

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

  • ‫[C-2-1] חובה להטמיע חיישן מורכב TYPE_ROTATION_VECTOR.

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

  • ‫[C-3-1] חובה להטמיע את החיישנים המורכבים TYPE_GRAVITY ו-TYPE_LINEAR_ACCELERATION.
  • [SR] מומלץ מאוד להטמיע את חיישן TYPE_GAME_ROTATION_VECTOR במכשירי Android קיימים ובמכשירי Android חדשים.
  • מומלץ להטמיע את החיישן המורכב TYPE_GAME_ROTATION_VECTOR.

‫7.3.5. ברומטר

  • הטמעות של מכשירים צריכות לכלול ברומטר (חיישן לחץ אוויר סביבתי).

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

  • ‫[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-1-2] הערך חייב להיות SENSOR_TYPE_TEMPERATURE.
  • ‫[C-1-3] חובה למדוד את הטמפרטורה של המעבד (CPU) של המכשיר.
  • ‫[C-1-4] אסור למדוד טמפרטורה אחרת.

שימו לב שסוג החיישן SENSOR_TYPE_TEMPERATURE הוצא משימוש ב-Android 4.0.

‫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.
    • חייבת להיות רזולוציית מדידה של לפחות ‎1,024 LSB/G.
    • חייב להיות בעל תדר מדידה מינימלי של ‎12.5 Hz או פחות.
    • חייב להיות בעל תדירות מדידה מקסימלית של 400 הרץ ומעלה.
    • חייב להיות רעש מדידה שלא עולה על ‎400 uG/√Hz.
    • חובה להטמיע חיישן כזה שלא מעיר את המכשיר, עם יכולת אחסון במאגר זמני של לפחות 3,000 אירועים של החיישן.
    • צריכת החשמל של העיבוד באצווה לא יכולה להיות גדולה מ-3mW.
    • צריכה להיות יציבות של הטיית רעש סטטי של ‎<15 μg √Hz ממערך נתונים סטטי של 24 שעות.
    • צריך להיות שינוי הטיה לעומת טמפרטורה של ‎≤ +/- 1mg / °C.
    • צריכה להיות לו אי-ליניאריות של קו ההתאמה הטובה ביותר של ‎≤ 0.5% ושינוי רגישות לעומת טמפרטורה של ‎≤ 0.03%/C°.
    • צריך להיות ספקטרום של רעש לבן כדי להבטיח את הכשירות המתאימה של שלמות הרעש של החיישן.

  • ‫[C-2-2] חובה לכלול TYPE_ACCELEROMETER_UNCALIBRATED עם אותן דרישות איכות כמו TYPE_ACCELEROMETER.

  • ‫[C-2-3] חייב להיות חיישן TYPE_GYROSCOPE ש:

    • חייב להיות לו טווח מדידה של לפחות ‎-1,000 עד ‎+1,000 dps.
    • חייב להיות בעל רזולוציית מדידה של לפחות 16 LSB/dps.
    • חייב להיות בעל תדר מדידה מינימלי של ‎12.5 Hz או פחות.
    • חייב להיות בעל תדירות מדידה מקסימלית של 400 הרץ ומעלה.
    • חייב להיות בעל רעשי מדידה שלא עולים על ‎0.014°/s/√Hz.
    • צריכה להיות יציבות הטיה במצב נייח של ‎ < 0.0002 °/s √Hz‎ ממערך נתונים סטטי של 24 שעות.
    • צריך להיות שינוי בהטיה לעומת הטמפרטורה של ‎≤ +/- 0.05 °/ s / °C.
    • צריך להיות שינוי ברגישות לעומת טמפרטורה של ‎≤ 0.02% / °C.
    • צריך לכלול קו בעל ההתאמה הטובה ביותר עם אי-ליניאריות של ‎≤ 0.2%‎.
    • צריכה להיות צפיפות רעש של ‎≤ 0.007 °/s/√Hz.
    • צריך להיות ספקטרום של רעש לבן כדי להבטיח את הכשירות המתאימה של שלמות הרעש של החיישן.
    • צריכה להיות שגיאת כיול קטנה מ-0.002 rad/s בטווח הטמפרטורות 10 עד 40 מעלות צלזיוס כשהמכשיר נייח.

  • ‫[C-2-4] חייב לכלול TYPE_GYROSCOPE_UNCALIBRATED עם אותן דרישות איכות כמו TYPE_GYROSCOPE.

  • ‫[C-2-5] חובה לכלול חיישן TYPE_GEOMAGNETIC_FIELD ש:
    • חייב להיות לו טווח מדידה של לפחות ‎-900 עד ‎+900 מיקרוטסלה (uT).
    • חייבת להיות רזולוציית מדידה של לפחות 5 LSB/uT.
    • חייב להיות בעל תדר מדידה מינימלי של 5 הרץ או פחות.
    • חייב להיות בעל תדירות מדידה מקסימלית של 50 הרץ ומעלה.
    • חייב להיות רעש מדידה שלא עולה על 0.5 מיקרוטסלה.
  • ‫[C-2-6] חובה להשתמש ב-TYPE_MAGNETIC_FIELD_UNCALIBRATED שעומד בדרישות האיכות של TYPE_GEOMAGNETIC_FIELD, ובנוסף:
    • חובה להטמיע חיישן כזה שלא מפעיל את המכשיר, עם יכולת אחסון במאגר זמני של לפחות 600 אירועים של החיישן.
    • צריך להיות ספקטרום של רעש לבן כדי להבטיח את הכשירות המתאימה של שלמות הרעש של החיישן.
  • ‫[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 ש:
    • חובה להטמיע חיישן כזה שלא מפעיל את המכשיר, עם יכולת אחסון זמני של לפחות 300 אירועים של החיישן.
    • צריכת החשמל של העיבוד באצווה לא יכולה להיות גבוהה מ-4mW.
  • ‫[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 אלפיות השנייה.
  • ‫[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 ו-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. חיישן טביעות אצבע

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

  • צריך לכלול חיישן טביעות אצבע.

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

  • ‫[C-1-1] חובה להצהיר על תמיכה בתכונה android.hardware.fingerprint.
  • ‫[C-1-2] חובה להטמיע באופן מלא את ה-API המתאים כפי שמתואר במסמכי ה-SDK של Android.
  • ‫[C-1-3] שיעור הקבלה השגוי (FAR) לא יכול להיות גבוה מ-0.002%.
  • [SR] מומלץ מאוד ששיעור הקבלה של זיופים ומתחזים לא יעלה על 7%.
  • ‫[C-1-4] חובה לציין שהמצב הזה עשוי להיות פחות מאובטח מקוד אימות, מקו ביטול נעילה או מסיסמה חזקים, ולפרט באופן ברור את הסיכונים בהפעלת המצב הזה, אם שיעורי הקבלה של זיופים ומתחזים גבוהים מ-7%.
  • ‫[C-1-5] חובה להגביל את קצב הניסיונות למשך 30 שניות לפחות אחרי חמישה ניסיונות שגויים לאימות טביעת אצבע.
  • ‫[C-1-6] חובה להטמיע חנות מפתחות שמגובה בחומרה, ולבצע את ההתאמה של טביעות האצבעות בסביבת מחשוב אמינה (TEE) או בשבב עם ערוץ מאובטח ל-TEE.
  • ‫[C-1-7] כל נתוני טביעות האצבע שניתן לזהות חייבים להיות מוצפנים ומאומתים באופן קריפטוגרפי, כך שלא ניתן יהיה להשיג, לקרוא או לשנות אותם מחוץ לסביבת מחשוב אמינה (TEE), כפי שמתואר בהנחיות ההטמעה באתר Android Open Source Project.
  • ‫[C-1-8] המערכת חייבת למנוע הוספה של טביעת אצבע בלי ליצור קודם שרשרת אמון, על ידי כך שהמשתמש יאשר אישורים קיימים או יוסיף אישור חדש למכשיר (קוד אימות, תבנית או סיסמה) שמאובטח על ידי TEE. הטמעת Android Open Source Project מספקת את המנגנון במסגרת הפעולה כדי לעשות זאת.
  • ‫[C-1-9] אסור לאפשר לאפליקציות של צד שלישי להבחין בין טביעות אצבע שונות.
  • ‫[C-1-10] חובה לכבד את הסימון DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
  • ‫[C-1-11] אם המכשיר משודרג מגרסה קודמת ל-Android 6.0, חובה להעביר את נתוני טביעת האצבע בצורה מאובטחת כדי לעמוד בדרישות שלמעלה, או להסיר אותם.
  • [SR] מומלץ מאוד ששיעור הדחייה השגוי יהיה נמוך מ-10%, כפי שנמדד במכשיר.
  • [SR] מומלץ מאוד שזמן האחזור יהיה מתחת לשנייה אחת, שנמדד מהרגע שבו נוגעים בחיישן טביעות האצבע ועד שהמסך נפתח, עבור אצבע אחת שרשומה.
  • מומלץ להשתמש בסמל טביעת האצבע של Android שמופיע בפרויקט הקוד הפתוח של Android.

‫7.3.11. חיישנים שזמינים רק ב-Android Automotive

חיישנים ספציפיים לרכב מוגדרים ב-android.car.CarSensorManager API.

‫7.3.11.1. הציוד הנוכחי

בסעיף 2.5.1 מפורטות הדרישות הספציפיות למכשירים.

‫7.3.11.2. מצב יום/לילה

בסעיף 2.5.1 מפורטות הדרישות הספציפיות למכשירים.

‫7.3.11.3. סטטוס הנהיגה

בסעיף 2.5.1 מפורטות הדרישות הספציפיות למכשירים.

‫7.3.11.4. מהירות הגלגלים

בסעיף 2.5.1 מפורטות הדרישות הספציפיות למכשירים.

‫7.3.12. חיישן תנוחה

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

  • יכול להיות שיש תמיכה בחיישן תנוחה עם 6 דרגות חופש.

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

  • ‫[C-1-1] חובה להטמיע את חיישן TYPE_POSE_6DOF ולדווח עליו.
  • ‫[C-1-2] חייב להיות מדויק יותר מווקטור הסיבוב בלבד.

‫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).
‫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] חובה להטמיע ממשק משתמש לניהול מספרים חסומים, שנפתח באמצעות הכוונה שמוחזרת על ידי שיטת TelecomManager.createManageBlockedNumbersIntent().
  • ‫[C-1-7] אסור לאפשר למשתמשים משניים להציג או לערוך את המספרים החסומים במכשיר, כי פלטפורמת Android מניחה שלמשתמש הראשי יש שליטה מלאה בשירותי הטלפוניה, מופע יחיד, במכשיר. צריך להסתיר את כל ממשק המשתמש שקשור לחסימה ממשתמשים משניים, ועדיין להתייחס לרשימת החסימה.
  • צריך להעביר את המספרים החסומים לספק כשהמכשיר מתעדכן ל-Android 7.0.
‫7.4.1.2. Telecom API

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

  • [C-SR] מומלץ מאוד לטפל באירועים KEYCODE_MEDIA_PLAY_PAUSE ו-KEYCODE_HEADSETHOOK של האוזניות עם המיקרופון עבור ממשקי ה-API של android.telecom באופן הבא:
    • הפונקציה Connection.onDisconnect() מופעלת כשמזוהה לחיצה קצרה על אירוע המקש במהלך שיחה פעילה.
    • התקשרות אל 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, גם במצבי המתנה.
  • צריך להגריל את כתובת ה-MAC של המקור ואת המספר הסידורי של מסגרות בקשת הבדיקה, פעם אחת בתחילת כל סריקה, בזמן שה-STA מנותק.
    • כל קבוצה של פריימים של בקשות בדיקה שמרכיבים סריקה אחת צריכה להשתמש בכתובת MAC עקבית אחת (אסור להגריל כתובת MAC באמצע הסריקה).
    • מספר הרצף של בקשת הבדיקה צריך לעבור איטרציה כרגיל (באופן עקבי) בין בקשות הבדיקה בסריקה
    • מספר הרצף של בקשת הבדיקה צריך להיות אקראי בין בקשת הבדיקה האחרונה של סריקה לבין בקשת הבדיקה הראשונה של הסריקה הבאה
  • צריך לאפשר רק את רכיבי המידע הבאים בפריימים של בקשות בדיקה, בזמן שה-STA מנותק:
    • ערכת פרמטרים של SSID ‏ (0)
    • קבוצת פרמטרים של DS‏ (3)
‫7.4.2.1. Wi-Fi ישיר

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

  • צריכה לכלול תמיכה ב-Wi-Fi Direct (Wi-Fi peer-to-peer).

אם הטמעות המכשירים כוללות תמיכה ב-Wi-Fi Direct, הן:

  • ‫[C-1-1] חובה להטמיע את ה-API המתאים ל-Android כפי שמתואר במסמכי ה-SDK.
  • ‫[C-1-2] חובה לדווח על תכונת החומרה android.hardware.wifi.direct.
  • ‫[C-1-3] חובה לתמוך בפעולה רגילה של Wi-Fi.
  • צריכה להיות תמיכה בפעולות של Wi-Fi ו-Wi-Fi Direct בו-זמנית.

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

אם הטמעות המכשירים כוללות תמיכה ב-TDLS וה-TDLS מופעל על ידי ה-API של WiFiManager, הן:

  • ‫[C-1-1] חובה להצהיר על תמיכה ב-TDLS באמצעות WifiManager.isTdlsSupported.
  • מומלץ להשתמש ב-TDL רק אם הדבר אפשרי ומועיל.
  • צריך להשתמש בהיוריסטיקה כלשהי ולא להשתמש ב-TDLS אם הביצועים שלו עלולים להיות גרועים יותר מאשר מעבר דרך נקודת הגישה ל-Wi-Fi.
‫7.4.2.3. 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.
‫7.4.2.4. פרוטוקול Passpoint ל-Wi-Fi

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

אם הטמעות המכשירים כוללות תמיכה ב-Wi-Fi Passpoint, הן:

  • ‫[C-1-1] חובה להטמיע את ממשקי ה-API שקשורים ל-Passpoint, כפי שמתואר בתיעוד ה-SDK.WifiManager
  • ‫[C-1-2] חובה לתמוך בתקן IEEE 802.11u, במיוחד בנוגע לגילוי רשת ובחירה ברשת, כמו Generic Advertisement Service (שירות פרסום כללי, GAS) ו-Access Network Query Protocol (פרוטוקול שאילתות של רשת גישה, ANQP).

לעומת זאת, אם הטמעות המכשירים לא כוללות תמיכה ב-Wi-Fi Passpoint:

  • ‫[C-2-1] ההטמעה של ממשקי ה-API שקשורים ל-Passpoint‏ WifiManager חייבת להחזיר את השגיאה UnsupportedOperationException.

‫7.4.3. ‫Bluetooth

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

  • צריכה להיות תמיכה בקודקים מתקדמים לאודיו ובקודקים לאודיו ב-Bluetooth (לדוגמה, LDAC).

אם הטמעות של מכשירים מצהירות על התכונה 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,‏ AVCP,‏ OBEX וכו', בהתאם למכשיר.

אם ההטמעות של המכשירים כוללות תמיכה ב-Bluetooth Low Energy, הן:

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

  • צריך לתמוך בהצגת כמה מודעות עם לפחות 4 מיקומי מודעות.

  • ‫[SR] מומלץ מאוד להטמיע פסק זמן של כתובת פרטית שניתנת לפתרון (RPA) שלא יעלה על 15 דקות, ולבצע רוטציה של הכתובת בתום פסק הזמן כדי להגן על פרטיות המשתמש.

‫7.4.4. תקשורת מטווח קצר

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

  • צריך לכלול משדר ומקלט ורכיבי חומרה קשורים לתקשורת מטווח קצר (NFC).
  • ‫[C-0-1] חובה להטמיע את ממשקי ה-API‏ android.nfc.NdefMessage ו-android.nfc.NdefRecord גם אם הם לא כוללים תמיכה ב-NFC או לא מצהירים על התכונה android.hardware.nfc, כי המחלקות מייצגות פורמט נתונים בלתי תלוי בפרוטוקול.

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

  • ‫[C-1-1] חובה לדווח על התכונה android.hardware.nfc באמצעות השיטה 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-3] חובה שתהיה אפשרות לשדר ולקבל נתונים באמצעות הפרוטוקולים והתקנים הבאים של עמית לעמית:

  • ISO 18092
  • ‫LLCP 1.2 (מוגדר על ידי NFC Forum)
  • ‫SDP 1.0 (מוגדר על ידי NFC Forum)
  • פרוטוקול NDEF Push
  • SNEP 1.0 (מוגדר על ידי NFC Forum)
  • ‫[C-1-4] המכשיר חייב לכלול תמיכה ב-Android Beam, ומומלץ להפעיל את Android Beam כברירת מחדל.
  • ‫[C-1-5] המכשיר חייב להיות מסוגל לשלוח ולקבל נתונים באמצעות Android Beam, כשהתכונה הזו מופעלת או כשמופעל מצב NFC P2p קנייני אחר.
  • ‫[C-1-6] חובה להטמיע את שרת ברירת המחדל של SNEP. הודעות NDEF תקפות שמתקבלות על ידי שרת SNEP שמוגדר כברירת מחדל חייבות להישלח לאפליקציות באמצעות כוונת android.nfc.ACTION_NDEF_DISCOVERED. השבתה של Android Beam בהגדרות לא יכולה להשבית את השליחה של הודעת NDEF נכנסת.
  • ‫[C-1-7] חובה לכבד את הכוונה של android.settings.NFCSHARING_SETTINGS להציג את ההגדרות של שיתוף באמצעות NFC.
  • ‫[C-1-8] חובה להטמיע את שרת ה-NPP. הודעות שמתקבלות בשרת NPP חייבות לעבור עיבוד באותו אופן כמו בשרת ברירת המחדל של SNEP.
  • ‫[C-1-9] חובה להטמיע לקוח SNEP ולנסות לשלוח NDEF P2P לדואר יוצא לשרת SNEP שמוגדר כברירת מחדל כש-Android Beam מופעל. אם לא נמצא שרת SNEP שמוגדר כברירת מחדל, הלקוח חייב לנסות לשלוח לשרת NPP.
  • ‫[C-1-10] חובה לאפשר לפעילויות שפועלות בחזית להגדיר את הודעת ה-NDEF היוצאת של P2P באמצעות android.nfc.NfcAdapter.setNdefPushMessage, ו-android.nfc.NfcAdapter.setNdefPushMessageCallback, ו-android.nfc.NfcAdapter.enableForegroundNdefPush.
  • מומלץ להשתמש בתנועה או באישור במסך, כמו 'הצמדה להעברה', לפני שליחת הודעות NDEF יוצאות מ-P2P.
  • ‫[C-1-11] המכשיר חייב לתמוך בהעברת חיבור NFC ל-Bluetooth אם הוא תומך בפרופיל Bluetooth Object Push.
  • ‫[C-1-12] חובה לתמוך בהעברת חיבור ל-Bluetooth כשמשתמשים ב-android.nfc.NfcAdapter.setBeamPushUris, על ידי הטמעה של המפרטים Connection Handover version 1.2 ו-Bluetooth Secure Simple Pairing Using NFC version 1.0 מ-NFC Forum. ביישום כזה חובה להטמיע את שירות ה-LLCP להעברה עם שם השירות urn:nfc:sn:handover כדי להחליף את רשומות הבקשה/הבחירה להעברה באמצעות NFC, וחובה להשתמש בפרופיל של Bluetooth Object Push להעברת הנתונים בפועל באמצעות Bluetooth. מסיבות שקשורות לתאימות לגרסאות קודמות (כדי לשמור על תאימות למכשירי Android 4.1), ההטמעה צריכה עדיין לקבל בקשות SNEP GET להחלפת בקשת ההעברה או רשומות הבחירה באמצעות NFC. עם זאת, ההטמעה עצמה לא אמורה לשלוח בקשות SNEP GET כדי לבצע העברת חיבור.
  • ‫[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 APIs כפי שמוגדר ב-Android SDK.

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

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

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

  • ‫[C-0-1] חובה לכלול תמיכה בצורה אחת או יותר של רשת נתונים. באופן ספציפי, הטמעות של מכשירים חייבות לכלול תמיכה לפחות בתקן נתונים אחד עם יכולת של 200Kbit/sec או יותר. דוגמאות לטכנולוגיות שעומדות בדרישה הזו כוללות EDGE,‏ HSPA,‏ EV-DO,‏ 802.11g,‏ Ethernet,‏ Bluetooth PAN וכו'.
  • ‫[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 שניות לפחות.
  • צריך גם לכלול תמיכה לפחות בתקן נפוץ אחד של נתונים אלחוטיים, כמו 802.11 ‏ (Wi-Fi), כשחיבור הנתונים העיקרי הוא תקן פיזי של רשת (כמו Ethernet)
  • יכול להיות שיהיו כמה דרכים לחיבור לנתונים.

רמת התמיכה הנדרשת ב-IPv6 תלויה בסוג הרשת, באופן הבא:

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

  • ‫[C-1-1] חובה לתמוך בפעולה של dual-stack ו-IPv6 בלבד ב-Wi-Fi.

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

  • ‫[C-2-1] חובה לתמוך בפעולה של dual-stack ב-Ethernet.

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

  • ‫[C-3-1] המכשיר חייב לעמוד בדרישות האלה בו-זמנית בכל רשת שהוא מחובר אליה, אם הוא מחובר בו-זמנית ליותר מרשת אחת (לדוגמה, Wi-Fi וחבילת גלישה), .
  • צריכה להיות תמיכה בפעולת IPv6 (IPv6 בלבד ואולי גם dual-stack) בחבילת גלישה.

‫7.4.6. הגדרות סנכרון

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

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

‫7.4.7. חסכונית בנתונים

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

  • [SR] מומלץ מאוד לספק את מצב חיסכון בחבילת הגלישה.

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

  • ‫[C-1-1] חובה לתמוך בכל ממשקי ה-API בכיתה ConnectivityManager, כפי שמתואר במסמכי ה-SDK
  • ‫[C-1-2] חובה לספק ממשק משתמש בהגדרות שמטפל בכוונת Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, כדי לאפשר למשתמשים להוסיף אפליקציות לרשימת ההיתרים או להסיר אפליקציות ממנה.

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

  • ‫[C-2-1] חייבת להחזיר את הערך RESTRICT_BACKGROUND_STATUS_DISABLED עבור ConnectivityManager.getRestrictBackgroundStatus()
  • ‫[C-2-2] אסור לשדר ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
  • ‫[C-2-3] חובה להגדיר פעילות שמטפלת ב-Intent‏ Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, אבל אפשר להטמיע אותה כפעולה שלא עושה כלום.

‫7.5. מצלמות

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

  • ‫[C-1-1] חובה להצהיר על ה-feature flag‏ android.hardware.camera.any.
  • ‫[C-1-2] אפליקציה חייבת להיות מסוגלת להקצות בו-זמנית 3 מפות סיביות מסוג RGBA_8888 שוות לגודל התמונות שנוצרות על ידי חיישן המצלמה עם הרזולוציה הגדולה ביותר במכשיר, בזמן שהמצלמה פתוחה לצורך תצוגה מקדימה בסיסית וצילום תמונות סטילס.

‫7.5.1. מצלמה אחורית

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

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

  • צריך לכלול מצלמה אחורית.

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

  • ‫[C-1-1] חובה לדווח על דגל התכונה android.hardware.camera ו-android.hardware.camera.any.
  • ‫[C-1-2] הרזולוציה חייבת להיות לפחות 2 מגה-פיקסל.
  • חייב להיות במצלמה פוקוס אוטומטי בחומרה או פוקוס אוטומטי בתוכנה שמוטמעים במנהל ההתקן של המצלמה (שקוף לתוכנת האפליקציה).
  • יכול להיות שיש להם חומרה עם פוקוס קבוע או EDOF (עומק שדה מורחב).
  • יכול להיות שיהיה פלאש.

אם המצלמה כוללת פלאש:

  • ‫[C-2-1] אסור להפעיל את מנורת הפלאש בזמן שמופע של android.hardware.Camera.PreviewCallback רשום בפלטפורמה של תצוגה מקדימה של המצלמה, אלא אם האפליקציה הפעילה את הפלאש באופן מפורש על ידי הפעלת המאפיינים FLASH_MODE_AUTO או FLASH_MODE_ON של אובייקט Camera.Parameters. חשוב לציין שההגבלה הזו לא חלה על אפליקציית המצלמה המובנית במערכת של המכשיר, אלא רק על אפליקציות של צד שלישי שמשתמשות ב-Camera.PreviewCallback.

‫7.5.2. מצלמה קדמית

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

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

  • עשוי לכלול מצלמה קדמית

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

  • ‫[C-1-1] חובה לדווח על דגל התכונה android.hardware.camera.any ו-android.hardware.camera.front.
  • ‫[C-1-2] הרזולוציה חייבת להיות VGA לפחות (640x480 פיקסלים).
  • ‫[C-1-3] אסור להשתמש במצלמה הקדמית כברירת מחדל ב-Camera API, ואסור להגדיר את ה-API כך שישתמש במצלמה הקדמית כברירת מחדל של המצלמה האחורית, גם אם זו המצלמה היחידה במכשיר.
  • ‫[C-1-5] התצוגה המקדימה של המצלמה חייבת להיות הפוכה אופקית ביחס לכיוון שצוין על ידי האפליקציה, אם האפליקציה הנוכחית ביקשה במפורש שהתצוגה של המצלמה תסתובב באמצעות קריאה לשיטה android.hardware.Camera.setDisplayOrientation(). לעומת זאת, התצוגה המקדימה חייבת להיות הפוכה לאורך הציר האופקי שמוגדר כברירת מחדל במכשיר, אם האפליקציה הנוכחית לא מבקשת במפורש שהתצוגה של המצלמה תסתובב באמצעות קריאה לשיטה android.hardware.Camera.setDisplayOrientation().
  • ‫[C-1-6] אסור לשקף את תמונת הסטילס או את זרמי הווידאו הסופיים שצולמו ומוחזרים לקריאות חוזרות (callback) של האפליקציה או שנשמרים באחסון המדיה.
  • ‫[C-1-7] חובה לשקף את התמונה שמוצגת בתצוגה המקדימה של המצלמה באותו אופן כמו בזרם התמונות של התצוגה המקדימה של המצלמה.
  • יכול לכלול תכונות (כמו פוקוס אוטומטי, פלאש וכו') שזמינות למצלמות שפונות לאחור, כפי שמתואר בסעיף 7.5.1.

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

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

‫7.5.3. מצלמה חיצונית

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

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

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

  • ‫[C-1-1] חובה להצהיר על דגל התכונה של הפלטפורמה android.hardware.camera.external ו-android.hardware camera.any.
  • ‫[C-1-2] אם המצלמה החיצונית מתחברת דרך יציאת ה-USB, המכשיר חייב לתמוך ב-USB Video Class ‏ (UVC 1.0 ומעלה).
  • צריכה להיות תמיכה בדחיסת וידאו כמו MJPEG כדי לאפשר העברה של סטרימינג באיכות גבוהה ללא קידוד (כלומר סטרימינג של תמונות לא ערוכות או סטרימינג של תמונות שנדחסו בנפרד).
  • יכול להיות שתהיה תמיכה בכמה מצלמות.
  • יכול להיות שהמכשיר תומך בקידוד וידאו שמבוסס על מצלמה. אם נתמך, המכשיר חייב להיות מסוגל לגשת לסטרימינג בו-זמני לא מוצפן / MJPEG (רזולוציית QVGA או יותר).

‫7.5.4. התנהגות של Camera API

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

חבילת ה-API הישנה יותר, android.hardware.Camera, מסומנת כחבילה שהוצאה משימוש ב-Android 5.0, אבל היא עדיין אמורה להיות זמינה לשימוש באפליקציות. הטמעות של מכשירי Android חייבות להבטיח את המשך התמיכה ב-API כפי שמתואר בקטע הזה וב-Android SDK.

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

  • ‫[C-0-1] חובה להשתמש ב-android.hardware.PixelFormat.YCbCr_420_SP כדי להציג נתונים בתצוגה מקדימה שמועברים לקריאות חוזרות (callback) של אפליקציה, אם האפליקציה מעולם לא הפעילה את android.hardware.Camera.Parameters.setPreviewFormat(int).
  • ‫[C-0-2] אם אפליקציה רושמת מופע של android.hardware.Camera.PreviewCallback והמערכת קוראת לשיטה onPreviewFrame() ופורמט התצוגה המקדימה הוא YCbCr_420_SP, הנתונים ב-byte[] שמועברים אל onPreviewFrame() חייבים להיות בפורמט הקידוד NV21. כלומר, 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.Camera.setParameters(), מלבד אלה שמתועדים כקבועים ב-android.hardware.Camera.Parameters. כלומר, הטמעות של מכשירים חייבות לתמוך בכל הפרמטרים הסטנדרטיים של המצלמה אם החומרה מאפשרת זאת, ואסור להן לתמוך בסוגים של פרמטרים מותאמים אישית של המצלמה. לדוגמה, הטמעות במכשירים שתומכות בצילום תמונות באמצעות טכניקות צילום עם טווח דינמי גבוה (HDR) חייבות לתמוך בפרמטר המצלמה Camera.SCENE_MODE_HDR.
  • ‫[C-0-7] חובה לדווח על רמת התמיכה המתאימה באמצעות המאפיין android.info.supportedHardwareLevel כפי שמתואר ב-Android SDK, ולדווח על הפעלת התכונות המתאימות ב-framework.
  • ‫[C-0-8] חובה גם להצהיר על יכולות המצלמה האישיות של android.hardware.camera2 באמצעות המאפיין android.request.availableCapabilities ולהצהיר על דגלי התכונות המתאימים. חובה להגדיר את דגל התכונה אם אחד ממכשירי המצלמה המחוברים תומך בתכונה.
  • ‫[C-0-9] חייב לשדר את Camera.ACTION_NEW_PICTURE הכוונה בכל פעם שהמצלמה מצלמת תמונה חדשה והתמונה נוספת למאגר המדיה.
  • ‫[C-0-10] חובה לשדר את כוונת Camera.ACTION_NEW_VIDEO בכל פעם שמצלמים סרטון חדש באמצעות המצלמה והערך של התמונה נוסף למאגר המדיה.

‫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] חובה לאכוף את ההרשאה android.permission.WRITE_EXTERNAL_STORAGE באחסון המשותף הזה, כפי שמתואר ב-SDK. אחרת, אפליקציות שמקבלות הרשאה כזו חייבות להיות מסוגלות לכתוב לאחסון המשותף.

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

  • אחסון נשלף שמשתמש יכול לגשת אליו, כמו חריץ לכרטיס SD ‏ (Secure Digital).
  • חלק מאמצעי האחסון הפנימי (שאי אפשר להסיר) כפי שמיושם בפרויקט קוד פתוח של Android ‏ (AOSP).

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

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

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

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

אם הטמעות המכשיר כוללות כמה נתיבי אחסון משותפים (כמו חריץ לכרטיס SD ואחסון פנימי משותף), הן:

  • ‫[C-3-1] חובה לאפשר רק לאפליקציות Android מותקנות מראש עם הרשאת WRITE_EXTERNAL_STORAGE לכתוב לאחסון החיצוני המשני, אלא אם הכתיבה היא לספריות ספציפיות לחבילה או בתוך URI שמוחזר על ידי הפעלת intent‏ ACTION_OPEN_DOCUMENT_TREE.

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

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

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

  • צריכה להיות תאימות למארח ההפניה של Android MTP, ‏ Android File Transfer.
  • צריך לדווח על מחלקה של מכשיר USB עם הערך 0x00.
  • צריך לדווח על שם ממשק USB ‏ 'MTP'.

‫7.6.3. אחסון שניתן להתאמה

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

  • [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] היציאה צריכה להיות מסוג מיקרו-B, מיקרו-AB או USB Type-C. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה כדי שיהיה אפשר לשדרג אותם לגרסאות עתידיות של הפלטפורמה.
  • [SR] היציאה צריכה להיות ממוקמת בתחתית המכשיר (בהתאם לכיוון הטבעי) או לאפשר סיבוב מסך בתוכנה לכל האפליקציות (כולל מסך הבית), כך שהתצוגה תהיה תקינה כשהמכשיר מוצב כשהיציאה בתחתית. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה כדי שיהיה אפשר לשדרג אותם לגרסאות עתידיות של הפלטפורמה.
  • ‫[SR] צריך להטמיע תמיכה בשאיבת זרם של 1.5 אמפר במהלך ציוץ HS ותנועה, כפי שמפורט במפרט הטעינה של סוללות USB, גרסה 1.2. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה כדי שיהיה אפשר לשדרג אותם לגרסאות עתידיות של הפלטפורמה.
  • ‫[SR] מומלץ מאוד לא לתמוך בשיטות טעינה קנייניות שמשנות את המתח של Vbus מעבר לרמות ברירת המחדל, או משנות את תפקידי המקור/הצרכן, כי זה עלול לגרום לבעיות תאימות למטענים או למכשירים שתומכים בשיטות הסטנדרטיות של אספקת מתח ב-USB. ההמלצה הזו מוגדרת כ "מומלץ מאוד", אבל יכול להיות שבעתיד נדרוש מכל המכשירים עם חיבור USB-C לתמוך בפעולה הדדית מלאה עם מטענים רגילים עם חיבור USB-C.
  • [SR] מומלץ מאוד לתמוך באספקת חשמל להחלפת תפקידים של נתונים וחשמל, אם הם תומכים ב-USB מסוג C ובמצב מארח USB.
  • צריכה להיות תמיכה בטעינה מהירה במתח גבוה (Power Delivery) ותמיכה במצבים חלופיים כמו תצוגה חיצונית.
  • מומלץ להטמיע את ממשק ה-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 ליציאת Type-C (שקע).
  • ‫[SR] מומלץ מאוד להטמיע את USB audio class כמו שמתואר במסמכי התיעוד של Android SDK.
  • צריך לתמוך בטעינת מכשיר הציוד ההיקפי שמחובר ב-USB בזמן שהוא במצב מארח. צריך לפרסם זרם מקור של לפחות 1.5A כפי שמצוין בקטע Termination Parameters (פרמטרים של סיום) במפרט של כבל ומחבר USB Type-C, גרסה 1.2 למחברי USB Type-C, או להשתמש בטווח זרם הפלט של יציאת טעינה במורד הזרם (CDP) כפי שמצוין במפרטים של טעינת סוללה ב-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 (פרוטוקול העברת מדיה) שמחוברים מרחוק ולאפשר גישה לתוכן שלהם באמצעות כוונות הפעולה ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT ו-ACTION_CREATE_DOCUMENT. .

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

  • ‫[C-4-1] חובה להטמיע פונקציונליות של יציאה עם תפקיד כפול, כפי שמוגדר במפרט USB Type-C (סעיף 4.5.1.3.3).
  • ‫[SR] מומלץ מאוד לתמוך ב-DisplayPort, מומלץ לתמוך בשיעורי העברת נתונים ב-USB SuperSpeed, ומומלץ מאוד לתמוך באספקת חשמל להחלפת תפקידים של נתונים וחשמל.
  • ‫[SR] מומלץ מאוד לא לתמוך במצב אביזר של מתאם אודיו, כפי שמתואר בנספח א' של מפרט כבלים ומחברים מסוג USB-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 להקלטת אודיו לפחות כפעולות ללא שינוי, בהתאם לסעיף 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 שקשורים לפלט אודיו כפעולות שלא עושות כלום לפחות.

לצורך הסעיף הזה, 'יציאת פלט' היא ממשק פיזי כמו שקע אודיו של 3.5 מ"מ, HDMI או יציאת מצב מארח USB עם מחלקת אודיו USB. תמיכה בפלט אודיו באמצעות פרוטוקולים מבוססי רדיו כמו Bluetooth,‏ Wi-Fi או רשת סלולרית לא נחשבת ככוללת 'יציאת פלט'.

‫7.8.2.1. יציאות אודיו אנלוגיות

כדי שמכשיר יהיה תואם לאוזניות ולאביזרי אודיו אחרים שמשתמשים בתקע אודיו בגודל 3.5 מ"מ בכל מערכת Android, אם הטמעת המכשיר כוללת יציאת אודיו אנלוגית אחת או יותר, לפחות אחת מיציאות האודיו צריכה להיות שקע אודיו בגודל 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] חובה שתהיה אפשרות להפעיל לפחות ‎150 mV ± 10% של מתח יציאה בעכבת רמקול של ‎32 אוהם.
  • ‫[C-1-6] חובה להשתמש במתח הטיה למיקרופון בין ‎1.8 V ל-‎2.9 V.
  • ‫[SR] מומלץ מאוד לזהות ולמפות את קוד המקש לטווח הבא של עכבה שוות ערך בין המיקרופון לבין מוליכי הארקה בתקע האודיו:
    • 110-180 אוהם: KEYCODE_VOICE_ASSIST
  • צריכה להיות תמיכה בתקעי אודיו עם סדר הפינים של OMTP.
  • צריכה להיות תמיכה בהקלטת אודיו מאוזניות סטריאו עם מיקרופון.

אם הטמעות המכשירים כוללות שקע אודיו 3.5 מ"מ עם 4 מוליכים ותמיכה במיקרופון, והן משדרות את android.intent.action.HEADSET_PLUG עם הערך הנוסף של המיקרופון שמוגדר כ-1, הן:

  • ‫[C-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.5kHz עד 20kHz עבור צליל של 19kHz ב-‎-26 dBFS חייב להיות לפחות 50dB.

אם PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND הוא true:

  • ‫[C-2-1] התגובה הממוצעת של הרמקול בטווח של 18.5‎ kHz עד 20‎ kHz לא יכולה להיות נמוכה מ-40‎ dB מתחת לתגובה ב-2‎ kHz.

‫7.9. מציאות מדומה

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

‫7.9.1. מצב מציאות מדומה

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

‫7.9.2. מציאות מדומה עם ביצועים גבוהים

אם הטמעות של מכשירים מזהות את התמיכה ב-VR עם ביצועים גבוהים לתקופות ארוכות יותר של שימוש על ידי המשתמשים באמצעות feature flag‏ android.hardware.vr.high_performance, הן:

  • ‫[C-1-1] המכשיר חייב לכלול לפחות 2 ליבות פיזיות.
  • ‫[C-1-2] חובה להצהיר על android.software.vr.mode feature.
  • ‫[C-1-3] חובה לתמוך במצב ביצועים רציף.
  • ‫[C-1-4] חובה לתמוך ב-OpenGL ES 3.2.
  • ‫[C-1-5] המכשיר חייב לתמוך ברמת חומרה 0 של Vulkan, ומומלץ לתמוך ברמת חומרה 1 של Vulkan.
  • ‫[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.
  • ‫[C-1-7] המעבד הגרפי והמסך חייבים להיות מסוגלים לסנכרן את הגישה למאגר הקדמי המשותף, כך שרינדור לסירוגין של תוכן VR ב-60fps עם שני הקשרים של רינדור יוצג ללא ארטיפקטים גלויים של קריעה.
  • ‫[C-1-8] חובה להטמיע את GL_EXT_multisampled_render_to_texture,‏ GL_OVR_multiview,‏ GL_OVR_multiview2,‏ GL_OVR_multiview_multisampled_render_to_texture,‏ GL_EXT_protected_textures,‏ GL_EXT_EGL_image_array,‏ GL_EXT_external_buffer ולחשוף את התוספים ברשימת התוספים הזמינים של GL.
  • ‫[C-1-9] חובה להטמיע תמיכה בדגלים AHardwareBuffer‏ AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER ו-AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA כפי שמתואר ב-NDK.
  • ‫[C-1-10] חובה להטמיע תמיכה ב-AHardwareBuffers עם יותר משכבה אחת.
  • ‫[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, חובה להיות מסוגל לפענח לפחות ‎1920x1080@30fps-10Mbps ורצוי להיות מסוגל לפענח ‎3840x2160@30fps-20Mbps (שווה ערך ל-4 מקרים של ‎1920x1080@30fps-5Mbps).
  • ‫[C-1-13] המכשיר חייב לתמוך ב-API‏ HardwarePropertiesManager.getDeviceTemperatures ולהחזיר ערכים מדויקים של טמפרטורת העור.
  • ‫[C-1-14] חובה להטמיע מסך, והרזולוציה שלו חייבת להיות לפחות Full HD‏(1080p). מומלץ מאוד שהרזולוציה תהיה Quad HD‏ (1440p) או גבוהה יותר.
  • ‫[C-1-15] התצוגה חייבת להתעדכן בקצב של 60 הרץ לפחות בזמן שהמכשיר במצב VR.
  • ‫[C-1-16] זמן האחזור של התצוגה (כפי שנמדד במעבר מאפור לאפור, מלבן לשחור ומשחור ללבן) חייב להיות ≤ 6 מילישניות.
  • ‫[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-1-20] חובה לתמוך בסוג הערוץ הישיר TYPE_HARDWARE_BUFFER לכל סוגי הערוצים הישירים שמופיעים למעלה.
  • [SR] מומלץ מאוד לתמוך בתכונה android.hardware.sensor.hifi_sensors ולעמוד בדרישות שקשורות לג'ירוסקופ, למד התאוצה ולמגנטומטר עבור android.hardware.hifi_sensors.
  • יכול להיות שהמערכת תספק ליבה בלעדית לאפליקציה שפועלת בחזית, ויכול להיות שהיא תתמוך ב-API‏ Process.getExclusiveCores כדי להחזיר את מספרי ליבות ה-CPU שבלעדיות לאפליקציה המובילה שפועלת בחזית. אם ליבה בלעדית נתמכת, אסור שהליבה תאפשר לתהליכים אחרים במרחב המשתמשים לפעול בה (למעט מנהלי התקנים שמשמשים את האפליקציה), אבל היא יכולה לאפשר לתהליכי ליבה מסוימים לפעול בה לפי הצורך.

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

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

‫8.1. עקביות חוויית המשתמש

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

‫8.2. ביצועי גישה לקובץ I/O

הגדרת בסיס משותף לביצועים עקביים של גישה לקבצים באחסון הנתונים הפרטי של האפליקציה (מחיצת /data) מאפשרת למפתחי אפליקציות להגדיר ציפייה מתאימה שתעזור להם בתכנון התוכנה. הטמעות במכשירים, בהתאם לסוג המכשיר, עשויות לכלול דרישות מסוימות שמתוארות בקטע 2 עבור פעולות הקריאה והכתיבה הבאות:

  • ביצועי כתיבה רציפה. הבדיקה מתבצעת על ידי כתיבת קובץ בגודל 256MB באמצעות מאגר כתיבה בגודל 10MB.
  • ביצועים של כתיבה אקראית. הבדיקה מתבצעת על ידי כתיבת קובץ בגודל 256MB באמצעות מאגר זמני לכתיבה בגודל 4KB.
  • ביצועים של קריאה רציפה. הבדיקה מתבצעת על ידי קריאת קובץ בגודל 256MB באמצעות מאגר זמני לכתיבה בגודל 10MB.
  • ביצועים של קריאה אקראית. הבדיקה מתבצעת על ידי קריאת קובץ בגודל 256MB באמצעות מאגר כתיבה בגודל 4KB.

8.3. מצבי חיסכון בסוללה

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

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

אם הטמעות של מכשירים מטמיעות מצבי הפעלה S3 ו-S4 כפי שהוגדרו על ידי ACPI, הן:

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

8.4. חישוב צריכת החשמל

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

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

  • [SR] מומלץ מאוד לספק פרופיל צריכת חשמל לכל רכיב שמגדיר את ערך צריכת הזרם לכל רכיב חומרה ואת קצב ניקוז הסוללה המשוער שנגרם על ידי הרכיבים לאורך זמן, כפי שמתועד באתר Android Open Source Project.
  • ‫[SR] מומלץ מאוד לדווח על כל ערכי צריכת החשמל במיליאמפר לשעה (mAh).
  • ‫[SR] מומלץ מאוד לדווח על צריכת החשמל של המעבד לכל UID של תהליך. פרויקט הקוד הפתוח של Android עומד בדרישה באמצעות הטמעה של מודול הליבה uid_cputime.
  • ‫[SR] מומלץ מאוד להפוך את נתוני צריכת החשמל האלה לזמינים למפתח האפליקציה באמצעות פקודת ה-shell‏ adb shell dumpsys batterystats.
  • צריך לשייך את צריכת החשמל לרכיב החומרה עצמו אם אי אפשר לשייך אותה לאפליקציה.

‫8.5. ביצועים עקביים

הביצועים של אפליקציות שפועלות לאורך זמן ודורשות ביצועים גבוהים יכולים להשתנות באופן משמעותי, בגלל אפליקציות אחרות שפועלות ברקע או בגלל הגבלת מהירות המעבד (CPU throttling) עקב מגבלות טמפרטורה. ‫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] אסור לאפשר תהליכים במרחב המשתמשים, למעט מנהלי ההתקנים שבהם האפליקציה משתמשת כדי לפעול בליבות הבלעדיות, אבל מותר לאפשר לתהליכי ליבה מסוימים לפעול לפי הצורך.

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

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-1-1] מומלץ מאוד לספק מנגנון שנגיש למשתמשים כדי להעניק או לבטל גישה לנתונים הסטטיסטיים של השימוש בתגובה לכוונת android.settings.ACTION_USAGE_ACCESS_SETTINGS באפליקציות שמצהירות על ההרשאה android.permission.PACKAGE_USAGE_STATS.

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

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

9.2. ‫UID ובידוד תהליכים

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

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

‫9.3. הרשאות במערכת הקבצים

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

9.4. סביבות הפעלה חלופיות

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

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

  • ‫[C-0-2] אין להעניק לסביבות זמן ריצה חלופיות גישה למשאבים שמוגנים על ידי הרשאות שלא נדרשו בקובץ AndroidManifest.xml של סביבת זמן הריצה באמצעות המנגנון <uses-permission>.

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

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

  • ‫[C-0-5] סביבות ריצה חלופיות לא יכולות לפתוח את ארגזי החול שמתאימים לאפליקציות אחרות ל-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 או למערכת דומה כדי לספק למחשבים מארחים גישה לנתונים של המשתמש הנוכחי.

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

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

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

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

9.6. אזהרה לגבי SMS פרימיום

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

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

  • ‫[C-1-1] חובה להציג אזהרה למשתמשים לפני שליחת הודעת SMS למספרים שמזוהים על ידי ביטויים רגולריים שמוגדרים בקובץ /data/misc/sms/codes.xml במכשיר. פרויקט הקוד הפתוח של Android מספק הטמעה שעומדת בדרישה הזו.

‫9.7. תכונות אבטחה של ליבת המערכת

ארגז החול של Android כולל תכונות שמשתמשות במערכת בקרת הגישה (MAC) של Security-Enhanced 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 Open Source Project.
  • ‫[C-0-6] חובה להטמיע מנגנון ארגז חול לאפליקציות של ליבת מערכת, שמאפשר סינון של קריאות למערכת באמצעות מדיניות שניתנת להגדרה מתוכניות מרובות-הליכים. פרויקט הקוד הפתוח של Android (AOSP) עומד בדרישה הזו באמצעות הפעלת seccomp-BPF עם סנכרון של קבוצת השרשורים (TSYNC), כפי שמתואר בקטע Kernel Configuration (הגדרת ליבת המערכת) ב-source.android.com.

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

  • ‫[C-0-7] חובה להטמיע אמצעי הגנה מפני הצפת מאגרים זמניים במחסנית הליבה (למשל CONFIG_CC_STACKPROTECTOR_STRONG).
  • ‫[C-0-8] חובה להטמיע הגנות קפדניות על זיכרון הליבה, שבהן קוד הפעלה הוא לקריאה בלבד, נתונים לקריאה בלבד הם לא ניתנים להפעלה ולא ניתנים לכתיבה, ונתונים שניתנים לכתיבה הם לא ניתנים להפעלה (לדוגמה, CONFIG_DEBUG_RODATA או CONFIG_STRICT_KERNEL_RWX).
  • [SR] מומלץ מאוד לשמור את נתוני הליבה שנכתבים רק במהלך האתחול, ולסמן אותם כקריאה בלבד אחרי האתחול (לדוגמה, __ro_after_init).
  • ‫[SR} מומלץ מאוד להטמיע בדיקה סטטית ודינמית של גבולות גודל האובייקט של עותקים בין מרחב המשתמש ומרחב הליבה (למשל, CONFIG_HARDENED_USERCOPY).
  • [SR] מומלץ מאוד לא להפעיל אף פעם זיכרון של מרחב משתמשים כשמריצים בקרנל (למשל PXN של חומרה, או הדמיה באמצעות CONFIG_CPU_SW_DOMAIN_PAN או CONFIG_ARM64_SW_TTBR0_PAN).
  • ‫[SR] מומלץ מאוד אף פעם לא לקרוא או לכתוב זיכרון במרחב המשתמשים בקרנל מחוץ לממשקי API רגילים של usercopy (למשל, PAN של חומרה או אמולציה באמצעות CONFIG_CPU_SW_DOMAIN_PAN או CONFIG_ARM64_SW_TTBR0_PAN).
  • ‫[SR] מומלץ מאוד להקצות באופן אקראי את הפריסה של קוד הליבה והזיכרון, ולהימנע מחשיפות שיפגעו בהקצאה האקראית (למשל, CONFIG_RANDOMIZE_BASE עם אנטרופיה של טוען האתחול באמצעות /chosen/kaslr-seed Device Tree node או EFI_RNG_PROTOCOL).

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

  • ‫[C-1-1] חובה להטמיע SELinux.
  • ‫[C-1-2] חובה להגדיר את SELinux למצב אכיפה גלובלי.
  • ‫[C-1-3] חובה להגדיר את כל הדומיינים במצב אכיפה. אסור להשתמש בדומיינים במצב הרשאה, כולל דומיינים שספציפיים למכשיר או לספק.
  • ‫[C-1-4] אסור לשנות, להשמיט או להחליף את כללי neverallow שקיימים בתיקייה system/sepolicy שסופקה בפרויקט קוד פתוח של Android ‏ (AOSP) במעלה הזרם, והמדיניות חייבת לעבור קומפילציה עם כל כללי neverallow שקיימים, גם בדומיינים של AOSP SELinux וגם בדומיינים ספציפיים למכשיר או לספק.
  • מומלץ לשמור על מדיניות SELinux שמוגדרת כברירת מחדל בתיקייה system/sepolicy של פרויקט הקוד הפתוח של Android (AOSP), ולהוסיף למדיניות הזו רק את ההגדרות הספציפיות למכשיר.

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

  • ‫[C-2-1] חובה להשתמש במערכת בקרת גישה מחייבת ששווה ל-SELinux.

‫9.8. פרטיות

‫9.8.1. היסטוריית השימוש

מערכת Android שומרת את היסטוריית הבחירות של המשתמש ומנהלת את ההיסטוריה הזו באמצעות UsageStatsManager.

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

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

‫9.8.2. ההקלטה התחילה

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

  • ‫[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] חובה להציג למשתמש אזהרה שמציינת שאולי מתבצע מעקב אחרי תעבורת הרשת, כשמוסיפים רשות אישורים בסיסית של משתמש.

אם התנועה במכשיר מנותבת דרך 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.9 הצפנה של אחסון נתונים

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

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

אם הטמעות המכשירים תומכות במסך נעילה מאובטח כפי שמתואר בקטע 9.11.1 ותומכות בהצפנת אחסון נתונים עם ביצועי הצפנה בתקן ההצפנה המתקדם (AES) מעל 50MiB/sec, הן:

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

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

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. הצפנה מבוססת קבצים

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

  • ‫[C-1-1] המכשיר חייב לבצע אתחול בלי לבקש מהמשתמש פרטי כניסה, ולאפשר לאפליקציות שתומכות ב-Direct Boot לגשת לאחסון Device Encrypted‏ (DE) אחרי שידור ההודעה ACTION_LOCKED_BOOT_COMPLETED.
  • ‫[C-1-2] חובה לאפשר גישה לאחסון Credential Encrypted‏ (CE) רק אחרי שהמשתמש פותח את נעילת המכשיר על ידי הזנת פרטי הכניסה שלו (למשל, קוד גישה, קוד אימות, קו ביטול נעילה או טביעת אצבע) וההודעה ACTION_USER_UNLOCKED משודרת.
  • ‫[C-1-3] אסור להציע שיטה כלשהי לפתיחת הנעילה של האחסון המוגן באמצעות CE ללא פרטי הכניסה שהמשתמש סיפק.
  • ‫[C-1-4] המכשיר חייב לתמוך בהפעלה מאומתת ולוודא שמפתחות DE קשורים באופן קריפטוגרפי ל-Root of Trust בחומרה של המכשיר.
  • ‫[C-1-5] המערכת חייבת לתמוך בהצפנת תוכן הקובץ באמצעות AES עם אורך מפתח של 256 ביט במצב XTS.

  • ‫[C-1-6] המכשיר חייב לתמוך בהצפנת שם הקובץ באמצעות AES עם אורך מפתח של 256 ביט במצב CBC-CTS.

  • המפתחות שמגנים על אזורי האחסון של CE ו-DE:

  • ‫[C-1-7] חובה להיות קשור באופן קריפטוגרפי למאגר מפתחות שמגובה בחומרה.

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

  • ‫[C-1-10] חובה שיהיה ייחודי ושונה, כלומר שאף מפתח CE או DE של משתמש לא יהיה זהה למפתח CE או DE של משתמש אחר.

  • מומלץ להטמיע באפליקציות חיוניות שנטענות מראש (לדוגמה: שעון מעורר, טלפון, Messenger) תמיכה באתחול ישיר.

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

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

‫9.9.3. הצפנה מלאה של הדיסק

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

  • ‫[C-1-1] חובה להשתמש ב-AES עם מפתח של 128 ביט (או יותר) ובמצב שנועד לאחסון (לדוגמה, AES-XTS, ‏ AES-CBC-ESSIV).
  • ‫[C-1-2] חובה להשתמש בקוד גישה שמוגדר כברירת מחדל כדי לעטוף את מפתח ההצפנה, ואסור לכתוב את מפתח ההצפנה באחסון בכל שלב ללא הצפנה.
  • ‫[C-1-3] חובה להצפין את מפתח ההצפנה באמצעות AES כברירת מחדל, אלא אם המשתמש ביטל את ההצפנה באופן מפורש, למעט כשהמפתח נמצא בשימוש פעיל. פרטי הכניסה למסך הנעילה צריכים להיות מוצפנים באמצעות אלגוריתם הצפנה איטי (למשל PBKDF2 או scrypt).
  • ‫[C-1-4] אלגוריתם ברירת המחדל להארכת הסיסמה שצוין למעלה חייב להיות קשור באופן קריפטוגרפי למאגר המפתחות הזה, אם המשתמש לא הגדיר פרטי כניסה לביטול נעילת המסך או השבית את השימוש בסיסמה להצפנה, והמכשיר מספק מאגר מפתחות שמגובה בחומרה.
  • ‫[C-1-5] אסור לשלוח את מפתח ההצפנה מהמכשיר (גם אם הוא עטוף בקוד הגישה של המשתמש ו/או במפתח שקשור לחומרה).

פרויקט הקוד הפתוח של Android מספק הטמעה מועדפת של התכונה הזו, שמבוססת על התכונה dm-crypt של ליבת Linux.

‫9.10. תקינות המכשיר

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

  • ‫[C-0-1] חובה לדווח בצורה נכונה באמצעות שיטת System API‏ PersistentDataBlockManager.getFlashLockState() אם מצב טוען האתחול מאפשר צריבה של קובץ האימג' של המערכת. הסטטוס FLASH_LOCK_UNKNOWN שמור להטמעות של מכשירים שמשדרגים מגרסה קודמת של Android שבה לא הייתה קיימת שיטת ה-API החדשה הזו של המערכת.

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

  • ‫[C-1-1] חובה להצהיר על ה-feature flag של הפלטפורמה 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] אסור לאפשר שינוי של מחיצות מאומתות במכשיר, אלא אם המשתמש ביטל את הנעילה של טוען האתחול באופן מפורש.
  • ‫[SR] אם יש במכשיר כמה שבבים נפרדים (למשל, רדיו, מעבד תמונה ייעודי), מומלץ מאוד לאמת כל שלב בתהליך האתחול של כל אחד מהשבבים האלה.
  • [SR] מומלץ מאוד להשתמש באחסון שקשה לזייף: כשמבטל נעילת טוען האתחול. אחסון עם הוכחה להתעסקות במכשיר מאפשר לטוען האתחול לזהות אם נעשתה התעסקות באחסון מתוך מערכת ההפעלה ברמה גבוהה (HLOS).
  • ‫[SR] מומלץ מאוד להציג למשתמש הנחיה בזמן השימוש במכשיר ולדרוש אישור פיזי לפני מעבר ממצב נעילת טוען האתחול למצב ביטול הנעילה של טוען האתחול.
  • [SR] מומלץ מאוד להטמיע הגנה מפני חזרה לגרסה קודמת במערכת ההפעלה ברמה גבוהה (למשל, מחיצות אתחול ומערכת) ולהשתמש באמצעי אחסון שקשה לזייף כדי לאחסן את המטא-נתונים שמשמשים לקביעת גרסת מערכת ההפעלה המינימלית המותרת.
  • מומלץ להטמיע הגנה מפני חזרה לגרסה קודמת לכל רכיב עם קושחה מתמשכת (למשל מודם, מצלמה) ומומלץ להשתמש באחסון עם סימני פתיחה כדי לאחסן את המטא-נתונים שמשמשים לקביעת הגרסה המינימלית המותרת.

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

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

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

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

9.11. מפתחות ופרטי כניסה

מערכת Android Keystore מאפשרת למפתחי אפליקציות לאחסן מפתחות קריפטוגרפיים במאגר ולהשתמש בהם בפעולות קריפטוגרפיות באמצעות KeyChain API או Keystore API. הטמעות במכשיר:

  • ‫[C-0-1] המערכת חייבת לאפשר ייבוא של יותר מ-8,192 מפתחות לפחות.
  • ‫[C-0-2] האימות במסך הנעילה חייב להגביל את מספר הניסיונות, וחייב לכלול אלגוריתם של נסיגה אקספוננציאלית. אם יש יותר מ-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 שדורשת מאגר מפתחות שמגובה בחומרה.

‫9.11.1. מסך נעילה מאובטח

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

  • ‫[C-1-1] חובה לציין את המשתמש בממשק המשתמש של ההגדרות ומסך הנעילה במצבים שבהם הנעילה האוטומטית של המסך נדחית או שסוכן האמון יכול לבטל את הנעילה של המסך. מערכת AOSP עומדת בדרישה הזו באמצעות הצגת תיאור טקסט לתפריטים 'הגדרה של נעילה אוטומטית' ו'הגדרה של נעילה מיידית של לחצן ההפעלה', וסמל שקל להבחין בו במסך הנעילה.
  • ‫[C-1-2] חובה לכבד ולהטמיע באופן מלא את כל ממשקי ה-API של סביבות אמינות במחלקה DevicePolicyManager, כמו הקבוע KEYGUARD_DISABLE_TRUST_AGENTS.
  • ‫[C-1-3] אסור ליישם באופן מלא את הפונקציה TrustAgentService.addEscrowToken() במכשיר שמשמש כמכשיר אישי ראשי (למשל, מכשיר נייד), אבל מותר ליישם באופן מלא את הפונקציה בהטמעות של מכשירים שבדרך כלל משותפים.
  • ‫[C-1-4] חובה להצפין את האסימונים שנוספו על ידי TrustAgentService.addEscrowToken() לפני אחסונם במכשיר.
  • ‫[C-1-5] אסור לאחסן את מפתח ההצפנה במכשיר.
  • ‫[C-1-6] חובה ליידע את המשתמש לגבי ההשלכות על האבטחה לפני הפעלת אסימון הנאמנות לצורך פענוח של אחסון הנתונים.

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

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

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

  • ‫[C-3-1] האנטרופיה של האורך הקצר ביותר המותר של קלט חייבת להיות גדולה מ-10 ביט.
  • ‫[C-3-2] האנטרופיה המקסימלית של כל הקלטים האפשריים חייבת להיות גדולה מ-18 ביט.
  • ‫[C-3-3] אסור להחליף אף אחת משיטות האימות הקיימות (קוד אימות,תבנית, סיסמה) שהוטמעו וסופקו ב-AOSP.
  • ‫[C-3-4] צריך להיות מושבת כשאפליקציית Device Policy Controller‏ (DPC) הגדירה את מדיניות איכות הסיסמה באמצעות השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_SOMETHING.

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

  • ‫[C-4-1] חובה להשתמש במנגנון חלופי כדי להשתמש באחת משיטות האימות העיקריות שמבוססות על סוד ידוע ועומדות בדרישות לשימוש כמסך נעילה מאובטח.
  • ‫[C-4-2] חובה להשבית את האפשרות הזו ולאפשר רק לאימות הראשי לבטל את נעילת המסך כשמדיניות בקרת המכשיר (DPC) מוגדרת באמצעות השיטה DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) או השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_UNSPECIFIED.
  • ‫[C-4-3] המשתמש חייב להתבקש לבצע אימות ראשי (למשל: קוד אימות, קו ביטול נעילה, סיסמה) לפחות פעם ב-72 שעות או פחות.

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

  • ‫[C-5-1] חובה להשתמש במנגנון חלופי כדי להשתמש באחת משיטות האימות העיקריות שמבוססות על סוד ידוע ועומדות בדרישות לשימוש כמסך נעילה מאובטח.
  • ‫[C-5-2] חובה להשבית את התכונה ולאפשר רק את האימות הראשי כדי לבטל את נעילת המסך, אם אפליקציית Device Policy Controller‏ (DPC) הגדירה את מדיניות התכונה keguard באמצעות קריאה לשיטה DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
  • ‫[C-5-3] קצב קבלת טביעת אצבע שגוי חייב להיות שווה או טוב יותר ממה שנדרש לחיישן טביעת אצבע כפי שמתואר בקטע 7.3.10, או לחלופין, חייב להיות מושבת ולאפשר רק את האימות הראשי כדי לבטל את נעילת המסך כאשר אפליקציית בקר מדיניות המכשיר (DPC) הגדירה את מדיניות איכות הסיסמה באמצעות השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • [SR] מומלץ מאוד ששיעורי הקבלה של זיופים ומתחזים יהיו שווים לשיעורים הנדרשים עבור חיישן טביעת אצבע, או גבוהים מהם, כפי שמתואר בסעיף 7.3.10.

אם שיעורי הקבלה של זיוף ומתחזה לא שווים לשיעורים הנדרשים או גבוהים מהם עבור חיישן טביעת אצבע, כפי שמתואר בקטע 7.3.10, ואפליקציית Device Policy Controller ‏ (DPC) הגדירה את מדיניות איכות הסיסמה באמצעות השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_BIOMETRIC_WEAK, אז:

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

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

‫9.12. מחיקת נתונים

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

  • ‫[C-0-1] חובה לספק למשתמשים מנגנון לביצוע 'איפוס לנתוני היצרן'.
  • ‫[C-0-2] חובה למחוק את כל הנתונים שנוצרו על ידי המשתמשים. כלומר, כל הנתונים חוץ מהדברים הבאים:
    • קובץ האימג' של המערכת
    • קבצים של מערכת ההפעלה שנדרשים על ידי קובץ האימג' של המערכת
  • ‫[C-0-3] חובה למחוק את הנתונים באופן שעומד בתקנים הרלוונטיים בתחום, כמו NIST SP800-88.
  • ‫[C-0-4] חובה להפעיל את התהליך של 'איפוס להגדרות היצרן' שצוין למעלה כשמתבצעת קריאה ל-API של DevicePolicyManager.wipeData() על ידי אפליקציית בקר מדיניות המכשיר של המשתמש הראשי.
  • יכול להיות שתהיה אפשרות למחיקת נתונים מהירה שמבצעת רק מחיקה לוגית של נתונים.

‫9.13. מצב הפעלה בטוח

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

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

  • ‫[SR] מומלץ מאוד להטמיע מצב אתחול בטוח.

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

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

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

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

‫9.14. בידוד של מערכות ברכב

מכשירים עם Android Automotive צפויים להחליף נתונים עם מערכות משנה קריטיות ברכב באמצעות vehicle HAL כדי לשלוח ולקבל הודעות ברשתות הרכב, כמו CAN bus.

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

10. בדיקת תאימות של תוכנה

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

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

10.1. חבילה לבדיקות תאימות (CTS)

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

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

10.2. CTS Verifier

הטמעות במכשירים חייבות להריץ בצורה נכונה את כל המקרים הרלוונטיים ב-CTS Verifier. הכלי CTS Verifier כלול בחבילת בדיקות התאימות (CTS), והוא מיועד להפעלה על ידי מפעיל אנושי כדי לבדוק פונקציונליות שלא ניתן לבדוק באמצעות מערכת אוטומטית, כמו פעולה תקינה של מצלמה וחיישנים.

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

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

11. תוכנות שניתנות לעדכון

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

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

  • הורדות 'Over-the-air (OTA)' עם עדכון אופליין באמצעות הפעלה מחדש.
  • עדכונים 'קשורים' דרך USB ממחשב מארח.
  • עדכונים במצב אופליין באמצעות הפעלה מחדש ועדכון מקובץ באחסון נייד.

עם זאת, אם הטמעת המכשיר כוללת תמיכה בחיבור נתונים ללא הגבלה, כמו פרופיל 802.11 או Bluetooth PAN (רשת אישית), המכשיר חייב לתמוך בהורדות OTA עם עדכון אופליין באמצעות הפעלה מחדש.

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

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

בנוסף, הטמעות במכשירים צריכות לתמוך בעדכוני מערכת מסוג A/B. ב-AOSP, התכונה הזו מיושמת באמצעות boot control HAL.

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

‫Android כולל תכונות שמאפשרות לאפליקציה של בעל המכשיר (אם היא קיימת) לשלוט בהתקנה של עדכוני מערכת. כדי לאפשר זאת, מערכת המשנה לעדכוני מערכת במכשירים שמדווחים על android.software.device_admin חייבת להטמיע את ההתנהגות שמתוארת במחלקה 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 ולבקש הבהרות או להעלות בעיות שלדעתכם לא מכוסות במסמך.