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

‫1. הקדמה

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

השימוש במאפיינים 'חובה', 'אסור', 'נדרש', 'נדרש', 'לא צריך', 'צריך', 'לא צריך', 'מומלץ', 'מאי' ו-'אופציונלי' הוא בהתאם לתקן IETF שמוגדר ב-RFC2119.

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

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

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

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

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

1.1 מבנה המסמך

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

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

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

1.1.2. מזהה דרישה

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

  • המזהה מוקצה לדרישות חובה בלבד.
  • הדרישות המומלצות מאוד מסומנות כ-[SR] אבל המזהה לא הוקצה.
  • המזהה מורכב מהפרטים הבאים : מזהה סוג המכשיר - מזהה תנאי - מזהה דרישה (למשל C-0-1).

כל מזהה מוגדר כך:

  • מזהה סוג המכשיר (מידע נוסף זמין בכתובת 2. סוגי מכשירים
    • ג: ליבה (דרישות שחלות על כל הטמעה של מכשירי Android)
    • H: מכשיר נייד עם Android
    • T: מכשיר Android TV
    • תשובה: הטמעת Android Automotive
  • מזהה תנאי
    • כשהדרישה היא לא מותנית, המזהה מוגדר כ-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 ב-upstream. כלומר, אסור להטמיע מכשירים בהטמעות או לשנות את הטריגרים או ערכי הסף שבהם מצב התאימות מופעל, ואסור להם לשנות את ההתנהגות של מצב התאימות עצמו.

מקלדת (סעיף 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] חייבת להיות אפשרות לדווח על אירועים בתדירות של עד 100Hz לפחות.

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

אם במכשירים ניידים נעשה שימוש בג'ירוסקופ, הן:

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

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

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

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

חיישן מיקום (סעיף 7.3.12)

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

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

Bluetooth (סעיף 7.4.3)

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

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

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

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

  • [H-1-1] חייבים להפעיל את מצב חוסך הנתונים (Data Saver).

זיכרון ואחסון מינימליים (סעיף 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] הזיכרון הזמין לליבה ולמרחב המשתמש חייב להיות לפחות 1344MB אם תצוגת ברירת המחדל משתמשת ברזולוציות של מאגר נתונים זמני עד QHD (למשל QWXGA).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מיקרופון (סעיף 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] חובה להצהיר על דגל התכונה android.hardware.vr.high_performance.*

2.2.2. מולטימדיה

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

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

  • [H-0-1] AMR-NB
  • [H-0-2] AMR-WB
  • [H-0-3] פרופיל AAC MPEG-4 (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] מומלץ מאוד להטמיע מרכז אפליקציות שמוגדר כברירת מחדל שמספק גישה מהירה לקיצורי הדרך הנוספים שמסופקים על ידי אפליקציות צד שלישי דרך ShortcutManager API.

  • [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] מומלץ מאוד להטמיע Assistant במכשיר כדי לטפל בפעולה בסיוע.

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

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

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

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

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

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

נגישות (סעיף 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 פריימים בשנייה, והם צריכים להיות נמוכים מ-1 פריימים בשנייה.
  • [H-0-2] זמן אחזור בממשק המשתמש. הטמעת מכשירים חייבת להבטיח חוויית משתמש עם זמן אחזור קצר על ידי גלילה ברשימה של 10,000 רשומות ברשימה, כפי שהוגדרה על ידי הכלי לבדיקת תאימות ל-Android (CTS), בתוך פחות מ-36 שניות.
  • [H-0-3] החלפת משימות. לאחר ההשקה של מספר אפליקציות, הפעלה מחדש של אפליקציה שכבר פועלת לאחר ההשקה חייבת להימשך פחות משנייה.

ביצועי גישה לקובץ I/O (סעיף 8.2)

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

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

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

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

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

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

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

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

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

2.2.5. דגם אבטחה

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

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

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

2.3. דרישות לטלוויזיה

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

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

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

Bluetooth (סעיף 7.4.3)

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

  • [T-0-1] חייבת לתמוך ב-Bluetooth וב-Bluetooth LE.

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

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

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

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

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

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

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

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

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

2.3.2. מולטימדיה

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

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

  • [T-0-1] פרופיל AAC MPEG-4 (AAC LC)
  • [T-0-2] פרופיל MPEG-4 HE AAC (AAC+)
  • [T-0-3] AAC ELD (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 (ב- 60 FPS).
  • [T-1-2] חייבת להיות אפשרות לפענח סרטונים בשני פרופילים של HD כפי שמצוין בטבלה הבאה, והם מקודדים באמצעות פרופיל בסיס, פרופיל ראשי או פרופיל גבוה 4.2

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

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

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

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

  • [T-2-1] הקודק חייב לתמוך בפרופיל הראשי (Main10) ברמה 5.

VP8 (סעיף 5.3.6)

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

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

אם הטמעות של מכשירי טלוויזיה תומכים בקודק VP8 ותומכות ב-720p:

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

VP9 (סעיף 5.3.7)

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

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

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

  • [T-2-1] חייבת לתמוך ב- 60 fps ב-1080p.

מדיה מאובטחת (סעיף 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 (בשפות שנתמכות על ידי מנוע המרת טקסט לדיבור (TTS) שנטענו מראש) כפי שמסופק בפרויקט קוד פתוח של TalkBack.

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

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

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

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

מסגרת של קלט טלוויזיה (סעיף 3.12)

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

  • [T-0-1] חייבת לתמוך במסגרת TV קלט.

2.2.4. ביצועים ועוצמה

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

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

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

ביצועי גישה לקובץ I/O (סעיף 8.2)

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

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

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

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

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

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

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

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

2.4. דרישות השעון

מכשיר Android Watch הוא הטמעה של מכשיר 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] הפונקציה Home חייבת להיות זמינה למשתמש, והפונקציה 'הקודם' חייבת להיות זמינה למשתמש, למעט במקרים שבהם היא פועלת ב-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_מצב_TYPE_Watch.

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

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

  • [W-SR] מומלץ מאוד להטמיע Assistant במכשיר כדי לטפל בפעולה בסיוע.

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

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

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

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

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

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

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

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

2.5. דרישות לגבי רכב

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

הטמעות של מכשירי Android מסווגים ככלי רכב אם הוצהרה בהן התכונה 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] חובה לספק את הפונקציה Home ו-MAY לספק פונקציות חזרה ופונקציות אחרונות.
  • [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 Hz לפחות.

חיישנים ל-Android כלי רכב בלבד (סעיף 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:

    • שיחות טלפון באמצעות פרופיל Hands-Free (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_מצב_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] חובה להטמיע Assistant במכשיר כדי לטפל בפעולת Assist.

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

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

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

2.2.4. ביצועים ועוצמה

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

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

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

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

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

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

2.2.5. דגם אבטחה

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

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

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

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

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

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

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

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

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

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

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

2.4.1. חומרה

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

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

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

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

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

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

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

  • ייתכן שה-API של Android Open Accessory (AOA) יוטמע.

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

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

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

3. תוכנה

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

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

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

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

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

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

3.1.1. תוספים ל-Android

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

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

3.2. תאימות ל-Soft API

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

3.2.1. הרשאות

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

3.2.2. בניית פרמטרים

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

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

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

לדוגמה:

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

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

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

3.2.3. תאימות של Intent

3.2.3.1. אובייקטים מרכזיים של Intent של אפליקציה

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

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

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

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

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

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

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

  • [C-0-4] חובה לנסות לאמת מסנני Intent על ידי ביצוע שלבי האימות שמוגדרים במפרט Digital Asset Links (המפרט של קישורים לנכסים דיגיטליים) כפי שהוטמע על ידי Package Manager בפרויקט הקוד הפתוח של Android.
  • [C-0-5] חובה לבצע ניסיון אימות של מסנני ה-Intent במהלך ההתקנה של האפליקציה, ולהגדיר את כל מסנני ה-Intent של ממשק המשתמש (UIR) שאומתו בהצלחה כרכיבי handler שמוגדרים כברירת מחדל ל-UIRs שלהם.
  • ייתכן שמסנני Intent ספציפיים של URI יוגדרו כרכיבי handler של אפליקציות כברירת מחדל למזהי ה-URI שלהם, אם הם אומתו בהצלחה אבל מסנני URI אפשריים אחרים נכשלים באימות. אם יישום של מכשיר עושה זאת, הוא חייב לספק למשתמש שינויים מתאימים לפי תבנית ה-URI בתפריט ההגדרות.
  • חובה לספק למשתמש אמצעי בקרה של קישורים לאפליקציה לכל אפליקציה בהגדרות באופן הבא:
    • [C-0-6] המשתמש חייב להיות מסוגל לשנות באופן גורף את התנהגות ברירת המחדל של קישורים לאפליקציה כדי שהאפליקציה תהיה: פתוחה תמיד, לשאול תמיד או אף פעם לא נפתחת. הפעולה הזו חייבת לחול באופן שווה על כל מסנני ה-Intent של ה-URI של המועמדים.
    • [C-0-7] המשתמש חייב לראות רשימה של מסנני Intent אפשריים ל-URI.
    • ייתכן שהטמעת המכשיר תאפשר למשתמש לבטל מסנני Intent ספציפיים של URI שאומתו, על בסיס סינון לפי כוונת רכישה.
    • [C-0-8] הטמעת המכשיר חייבת לספק למשתמשים את היכולת להציג ולבטל מסנני Intent של URI מועמדים ספציפיים אם ההטמעה של המכשיר מאפשרת למסנני Intent מסוימים של URI לאפשר את האימות בהצלחה, בעוד שאחרים יכולים להיכשל.
3.2.3.3. מרחבי שמות של Intent
  • [C-0-1] אסור לכלול בהטמעות של מכשירים רכיב של Android שמוגדר בהתאם לדפוסי Intent חדשים או לדפוסי כוונות שידור חדשים שמשתמשים ב-ACTION, CATEGORY או מחרוזת מפתח אחרת במרחב השמות של Android . או com.android.
  • [C-0-2] מטמיעי מכשירים לא רשאים לכלול רכיבי Android שמכבדים דפוסי כוונה חדשה או דפוסי כוונות שידור חדשים באמצעות ACTION, CATEGORY או מחרוזת מפתח אחרת בשטח חבילות ששייך לארגון אחר.
  • [C-0-3] אסור למטמיעי מכשירים לשנות או להרחיב אף אחד מדפוסי ה-Intent שמשמשים את אפליקציות הליבה שמפורטות בסעיף 3.2.3.1.
  • יכול להיות שהטמעות מכשירים כוללות דפוסי כוונה שמשתמשים במרחבי שמות באופן ברור וברור עם הארגון שלהם. איסור זה מקביל לזה שצוין לגבי מחלקות של שפות Java בסעיף 3.6.
3.2.3.4. כוונה לשידור

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-1-1] חייבים להגדיר את דגל התכונה android.software.activities_on_secondary_displays.
  • [C-1-2] חובה להבטיח תאימות ל-API שדומה לפעילות שפועלת במסך הראשי.
  • [C-1-3] הפעילות החדשה חייבת להופיע באותו מסך שבו היא הופעלה, כשהפעילות החדשה מופעלת בלי לציין תצוגת יעד דרך ה-API של ActivityOptions.setLaunchDisplayId().
  • [C-1-4] חובה להשמיד את כל הפעילויות לאחר הסרה של תצוגה עם הדגל Display.FLAG_PRIVATE.
  • [C-1-5] חובה לשנות את הגודל של כל הפעילויות ב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. תאימות ל-Native API

מטמיעי מכשירים הם:

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

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

3.3.1. ממשקים בינאריים של אפליקציות

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

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

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

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

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

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

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

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

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

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

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

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

3.4. תאימות לאתרים

3.4.1. תאימות ל-WebView

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

  • [C-1-1] חובה לדווח על android.software.webview.
  • [C-1-2] חובה להשתמש בגרסת ה-build של פרויקט Chromium מפרויקט הקוד הפתוח של Android ב-upstream בהסתעפות של Android 8.1, לצורך ההטמעה של ה-API של android.webkit.WebView.

  • [C-1-3] מחרוזת סוכן המשתמש שמדווחת על ידי WebView חייבת להיות בפורמט הבא:

    Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, like Gecko) גרסה/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

    • הערך של המחרוזת $(VERSION) חייב להיות זהה לערך של android.os.Build.VERSION.VERSION.
    • הערך של המחרוזת $(MODEL) חייב להיות זהה לערך של android.os.Build.MODEL.
    • הערך של המחרוזת $(BUILD) חייב להיות זהה לערך של android.os.Build.ID.
    • הערך של המחרוזת $(CHROMIUM_VER) חייב להיות הגרסה של Chromium בפרויקט קוד פתוח של Android במעלה הזרם.
    • ייתכן שהטמעות מכשירים לא ייכללו במחרוזת של סוכן המשתמש.

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

3.4.2. תאימות דפדפן

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

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

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

  • [C-2-1] עדיין חייבת לתמוך בדפוסים של כוונות ציבוריות, כפי שמתואר בסעיף 3.2.3.1.

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

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

  • [C-0-1] אסור שהמכשירים ישנו את ההתנהגות או הסמנטיקה של Intent רגיל.
  • [C-0-2] אסור שהמכשירים ישנו את הסמנטיקה של מחזור החיים או של מחזור החיים של סוג מסוים של רכיב מערכת (למשל 'שירות', 'פעילות', 'ContentProvider' וכו').
  • [C-0-3] אסור לשנות במכשירים את הסמנטיקה של הרשאות רגילות.
  • אסור שהמכשירים ישנו את המגבלות שנאכפות על אפליקציות ברקע. באופן ספציפי יותר, באפליקציות שפועלות ברקע:
    • [C-0-4] הם חייבים להפסיק לבצע קריאות חוזרות (callback) שרשומות באפליקציה כדי לקבל פלטים מה-GnssMeasurement ומה-GnssNavigationMessage.
    • [C-0-5] חובה להגביל את תדירות העדכונים שמסופקים לאפליקציה באמצעות מחלקת ה-API LocationManager או ה-method WifiManager.startScan().
    • [C-0-6] אם האפליקציה מטרגטת רמת API 25 ומעלה, אסור שהיא תאפשר רישום של מקלטי שידורים עבור שידורים מרומזים של Intents רגילים של Android במניפסט של האפליקציה, אלא אם כוונת השידור מחייבת הרשאה "signature" או "signatureOrSystem" protectionLevel או שהם נמצאים ברשימת הפטור.
    • [C-0-7] אם האפליקציה מטרגטת רמת API 25 ומעלה, האפליקציה חייבת להפסיק את שירותי הרקע של האפליקציה, בדיוק כאילו האפליקציה הייתה קריאה לשיטה stopSelf() של השירותים, אלא אם האפליקציה הוצבה ברשימת היתרים זמנית לטיפול במשימה שגלויה למשתמש.
    • [C-0-8] אם האפליקציה מטרגטת רמת API 25 ומעלה, האפליקציה חייבת לשחרר את ה-Wakelocks שהאפליקציה מחזיקה.

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

3.6. מרחבי שמות של API

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

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

כלומר, הן:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פריסת מסך דחיסות מסך זיכרון מינימלי של האפליקציה
שעון Android 120 dpi (ldpi) 32MB
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 לאחזור סמלים נקראות.

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

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

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

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

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

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

3.8.2. ווידג'טים

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

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

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

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

3.8.3. התראות

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

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

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

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

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

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

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

  • [C-3-1] חובה להשתמש בתצוגה ובמקורות המידע של 'שימו לב' כפי שמתואר במחלקה Notification.Builder של ה-API כשמוצגות התראות 'שימו לב'.
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] חייבת להטמיע פעילות שמגיבה להנחיה ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS. בהטמעות עם UI_מצב_TYPE_NORMAL, זו חייבת להיות פעילות שבה המשתמש יכול להעניק או לדחות את הגישה לאפליקציה להגדרות המדיניות של DND.
  • [C-1-2] חובה להציג בהטמעה של המכשיר אמצעי שמאפשר למשתמש להעניק או לדחות גישה של אפליקציות של צד שלישי להגדרות המדיניות של DND, צריך להציג כללי DND אוטומטיים שנוצרו על ידי אפליקציות לצד הכללים שנוצרו על ידי המשתמש ומוגדרים מראש.
  • [C-1-3] חובה לפעול בהתאם לערכים של suppressedVisualEffects שמועברים לאורך NotificationManager.Policy, ואם אפליקציה הגדירה אחד מהסימונים SUPPRESSED_EFFECT_SCREEN_OFF או SUPPRESSED_EFFECT_SCREEN_ON, התכונה צריכה לציין למשתמש שהאפקטים החזותיים מבוטלים בתפריט של הגדרות ה-DND.

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

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

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

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

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

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

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

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

  • [C-2-1] חובה לציין בבירור למשתמש הקצה מתי ההקשר משותף, באמצעות אחת מהאפשרויות הבאות:
    • בכל פעם שאפליקציית העזרה ניגשת להקשר, מציגה אור לבן בקצוות של המסך בהתאם למשך הזמן ולבהירות של יישום פרויקט הקוד הפתוח של Android, או עולה עליו.
    • באפליקציית העזרה המותקנת מראש, למשתמש אין אפשרות לנווט אל תפריט ההגדרות של ברירת המחדל של הקלט הקולי ושל אפליקציית העזרה, ולשתף את ההקשר רק כשהמשתמש מפעיל את אפליקציית העזרה באופן מפורש באמצעות מילת הפעלה או קלט של מקש ניווט.
  • [C-2-2] האינטראקציה הייעודית להפעלת אפליקציית העזרה כפי שמתואר בסעיף 7.2.3 חייבת להפעיל את אפליקציית העזרה שנבחרה על ידי המשתמש, כלומר האפליקציה שמטמיעה את VoiceInteractionService, או פעילות שמטפלת בכוונה 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 ולהציג הודעות טוסט מאפליקציות למשתמשי קצה באופן בולט לעין.

3.8.6. עיצובים

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

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

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

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

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

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

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

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

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

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

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

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

  • [SR] מומלץ מאוד להשתמש בממשק המשתמש של Android ב-upstream (או בממשק דומה שמבוסס על תמונות ממוזערות) למסך הסקירה הכללית.

3.8.9. ניהול קלט

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

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

  • [C-1-1] חובה להצהיר על תכונת הפלטפורמה android.software.input_methods שתומכת בממשקי API של IME כפי שמוגדר במסמכי התיעוד של Android SDK.
  • [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) שיכול לספק את קואורדינטות המיקום:

  • [C-1-1] מצבי מיקום חייבים להופיע בתפריט המיקום ב'הגדרות'.

3.8.13. Unicode וגופן

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

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

  • [C-1-1] חייבת להיות אפשרות להציג את תווי האמוג'י האלה בגליף צבעים.
  • [C-1-2] חייבת לכלול תמיכה בנושאים הבאים:
  • גופן Roboto 2 בעל משקלים שונים – Sans-serif-thin, San-serif-light, San-serif-medium, San-serif-black, San-serif-condensed, San-serif-Con העזרהd-light לשפות הזמינות במכשיר.
  • כיסוי מלא של Unicode 7.0 לאותיות לטיניות, יווניות וקיריליות, כולל הטווחים הלטיניים המורחבים 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] חובה להפעיל פעילויות במצב 'תמונה בתוך תמונה' בכמה חלונות, כשהאפליקציה: * טירגוט לרמה 26 ומעלה של API, ומצהירה על android:supportsPictureInPicture * רמת API לטירגוט ברמה 25 ומטה והצהרה גם על android:resizeableActivity וגם על android:supportsPictureInPicture.
  • [C-3-2] חייבות לחשוף את הפעולות ב-SystemUI שלהן, כפי שצוין בפעילות PIP הנוכחית דרך ה-API של setActions().
  • [C-3-3] חובה לתמוך ביחסי גובה-רוחב שגדולים מ-1:2.39 או שווים ל-2.39:1 או שווים ל-2.39:1, כפי שהוגדר על ידי הפעילות של PIP דרך ה-API של setAspectRatio().
  • [C-3-4] חייבים להשתמש בפונקציה KeyEvent.KEYCODE_WINDOW כדי לשלוט בחלון של התמונה בתוך התמונה (PIP). אם מצב PIP לא מוטמע, המפתח חייב להיות זמין לפעילות בחזית.
  • [C-3-5] חייבת להיות למשתמש אפשרות לחסום הצגה של אפליקציה במצב PIP. הטמעת 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] חייבת לתמוך ברישום לקוח של מדיניות מכשירים (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 כדי לאפשר לאפליקציה 'בקר לניהול מדיניות מכשירים (DPC)' להפוך לבעלים של פרופיל מנוהל חדש.

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

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

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

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

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

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

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

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

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

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

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

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

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

3.12. מסגרת של קלט טלוויזיה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.12.1.4. הקלטה תוך כדי צפייה

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

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

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

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

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

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

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

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

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

אם הטמעות המכשירים כוללות את ה-framework של ממשק המשתמש שתומכת באפליקציות צד שלישי שתלויות ב-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 של הרכיב נחשף, ויש לו CATEGORY_BROWSABLE
    • הפעולה היא אחת מהאפשרויות: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
    • היעד חשוף באופן מפורש באמצעות android:visibleToInstantApps
  • [C-0-3] אסור לאפליקציות ללא התקנה לבצע אינטראקציה מפורשת עם אפליקציות מותקנות, אלא אם הרכיב נחשף דרך android:visibleToInstantApps.
  • [C-0-4] אפליקציות ללא התקנה לא יכולות לראות פרטים על אפליקציות ללא התקנה במכשיר, אלא אם האפליקציה ללא התקנה מתחברת באופן מפורש לאפליקציה שמותקנת במכשיר.

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

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

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

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

4. תאימות לאריזת אפליקציות

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

  • [C-0-1] צריכה להיות אפשרות להתקין ולהפעיל קובצי Android .APK כפי שנוצרו על ידי הכלי aapt שכלול ב-SDK הרשמי של Android.
  • כיוון שהדרישה שלמעלה עשויה להיות מאתגרת, מומלץ בהטמעות של מכשירים להשתמש בהטמעות של מערכת ניהול החבילות של קובץ העזר ל-AOSP.
  • [C-0-2] חייבת להיות תמיכה באימות קובצי .APK באמצעות APK Signature Scheme v2 וחתימת JAR.
  • [C-0-3] אסור להרחיב את הפורמטים .APK , Android Manifest , Dalvik bytecode או RenderScript באופן שלא ימנע את ההתקנה של הקבצים האלה והפעלה שלהם במכשירים תואמים אחרים.
  • [C-0-4] אסור שאפליקציות חוץ מ'המתקין הנוכחי' של החבילה להסיר באופן שקט את האפליקציה ללא הנחיה, כפי שמתועד ב-SDK של ההרשאה DELETE_PACKAGE. יוצאי הדופן היחידים הם שימוש באפליקציה לאימות חבילות מערכת שמטפל ב-PACKAGE_NEEDS_formatted ובכוונת האפליקציה של מנהל האחסון שמטפלת בכוונת 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.

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

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

כל רכיבי הקודק המפורטים בקטע שבהמשך מסופקים כהטמעות תוכנה בהטמעה המועדפת של 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] ורביס
  • [C-1-9] PCM/WAVE
  • [C-1-10] אופוס

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

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

5.1.3. פרטי רכיבי הקודק של האודיו

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

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

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

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

  • [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 והופכים אותו לזמין לאפליקציות צד שלישי:

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

5.2.1. H.263

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

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

5.2.2. H-264

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

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

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

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

5.2.3. VP8

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

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

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

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

5.2.4. VP9

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

  • צריכה לתמוך בכתיבת קובצי 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] חובה לתמוך בפרופיל הבסיס ברמה 30 וברמה 45.

5.3.3. MPEG-4

בהטמעות במכשירים עם מפענחי MPEG-4:

  • [C-1-1] חייבת לתמוך ב-Simple Profile Level 3.

5.3.4. H.264

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

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

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

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

5.3.5. H.265 (‏HEVC)

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

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

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

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

5.3.6. VP8

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

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

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

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

5.3.7. VP9

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

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

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

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

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

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

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

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

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

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

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

  • פורמט: PCM לינארי, 16 ביט

  • קצבי דגימה: 8,000, 11,025, 16,000, 44,100 Hz

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

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

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

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

  • פורמט: PCM לינארי, 16 ביט

  • קצב דגימה: 22,050, 48,000 Hz
  • ערוצים: סטריאו

אם הטמעת המכשיר מאפשרת תיעוד באיכות רדיו AM ו-DVD של תוכן אודיו גולמי:

  • [C-2-1] חובה לצלם ללא דגימה גדולה בכל יחס שגבוה מ-16000:22050 או 44100:48000.
  • [C-2-2] חייב לכלול מסנן מתאים להסרת החיפוי כדי לדגום או להקטין את הדגימה.

5.4.2. צילום לזיהוי קולי

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

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

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

  • [C-2-1] חייבת להיות אפשרות לשלוט באפקט האודיו הזה באמצעות ה-API של android.media.audiofx.NoiseSuppressor.
  • [C-2-2] חייבת להיות זיהוי ייחודי של כל הטמעה של טכנולוגיה לביטול רעשים דרך השדה AudioEffect.Descriptor.uuid.

5.4.3. צילום לצורך ניתוב מחדש של ההפעלה

המחלקה android.media.MediaRecorder.AudioSource כוללת את מקור האודיו REMOTE_SUBMIX.

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

  • [C-1-1] חובה להטמיע בצורה תקינה את מקור האודיו REMOTE_SUBMIX כך שכשאפליקציה משתמשת ב-API של android.media.AudioRecord כדי להקליט ממקור האודיו הזה, היא מתעדת שילוב של כל שידורי האודיו, למעט הבאים:

    • AudioManager.STREAM_RING
    • AudioManager.STREAM_ALARM
    • AudioManager.STREAM_NOTIFICATION

5.5. הפעלת האודיו

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

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

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

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

    • פורמט: 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 שניתן לשלוט בהן באמצעות מחלקות המשנה Audio Effects Equalizer, LoudnessEnhancer.
  • [C-1-2] חייבת להיות תמיכה בהטמעה של ממשק API של Visualizer, שאפשר לשלוט בו באמצעות המחלקה Visualizer.
  • צריכה לתמוך בהטמעות של EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB ו-EFFECT_TYPE_VIRTUALIZER שאפשר לשלוט בהן באמצעות מחלקות המשנה BassBoost, EnvironmentalReverb, PresetReverb ו-Virtualizer.AudioEffect

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

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

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

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

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

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

  • זמן אחזור של פלט מרווח הזמן בין הרגע שבו האפליקציה כותבת פריים של נתונים מקודדים לפי PCM ועד שהצליל התואם מוצג לסביבה במתמר או באות במכשיר שיוצאים מהמכשיר דרך יציאה ואפשר לצפות בו באופן חיצוני.
  • זמן אחזור של פלט קר זמן האחזור של הפלט של הפריים הראשון, כאשר מערכת פלט האודיו לא הייתה פעילה והושבתה לפני הבקשה.
  • זמן אחזור רציף של הפלט זמן האחזור של הפלט בפריימים הבאים, לאחר שהמכשיר משמיע אודיו.
  • זמן אחזור של קלט. מרווח הזמן בין מצב שבו צליל מוצג על ידי הסביבה למכשיר במתמר או אות במכשיר, לבין הכניסה של אות למכשיר דרך יציאה לבין המועד שבו האפליקציה קוראת את המסגרת המתאימה של נתונים שמקודדים באמצעות PCM.
  • קלט שאבד. החלק הראשוני של אות קלט שלא ניתן לשימוש או לא זמין.
  • זמן אחזור של קלט קר סך זמן הקלט שאבד וזמן האחזור של הקלט של הפריים הראשון, כשמערכת קלט האודיו לא הייתה פעילה והושבתה לפני הבקשה.
  • זמן אחזור של קלט רציף. זמן האחזור של הקלט לפריימים הבאים בזמן שהמכשיר מקליט אודיו.
  • רעידות בפלט קר. השונות בין מדידות נפרדות של ערכי זמן אחזור של פלט קר.
  • רעידות של קלט קר. השונות בין מדידות נפרדות של ערכי זמן אחזור של קלט קר.
  • זמן אחזור רציף הלוך ושוב. הסכום של זמן אחזור קלט רציף, זמן אחזור רציף של פלט ועוד תקופה של מאגר נתונים זמני. פרק הזמן בין מאגר הנתונים הזמני מאפשר לאפליקציה לעבד את האות ואת הזמן שנדרש כדי לצמצם את הפרשי השלבים בין מקורות הקלט והפלט.
  • OpenSL ES PCM bufferQueue 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 bufferQueue API של OpenSL ESPM, עבור זמן אחזור של פלט רציף וזמן אחזור של פלט קר במכשיר אחד לפחות שנתמך בפלט אודיו:

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

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

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

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

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

5.7. פרוטוקולי רשת

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

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

  • [C-1-1] חייבת להיות תמיכה בכל רכיבי הקודק והפורמטים של המאגרים הנדרשים בסעיף 5.1 בפרוטוקול HTTP(S).

  • [C-1-2] חייבת לתמוך בפורמטים של קטעי מדיה שמוצגים בטבלה 'פורמטים של מדיה' בהמשך, ב-HTTP Live Streaming Streaming Protocol, גרסה 7.

  • [C-1-3] חייב לתמוך בפרופיל וידאו האודיו של RTP הבא וברכיבי הקודק הקשורים אליו בטבלת ה-RTSP שבהמשך. לגבי חריגים, מומלץ לעיין בהערות השוליים של הטבלה בסעיף 5.1.

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

פורמטים של פלחים הפניות נדרשת תמיכה בקודק
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 עם תגי פריים ו-ID3 של ADTS ISO 13818-7 מידע נוסף על קובץ AAC ועל הווריאציות שלו זמין בסעיף 5.1.1.
WebVTT WebVTT

RTSP (RTP, SDP)

השם בפרופיל הפניות נדרשת תמיכה בקודק
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-גנרי RFC 3640 מידע נוסף על קובץ AAC ועל הווריאציות שלו זמין בסעיף 5.1.1.
MP2T RFC 2250 לפרטים נוספים, ראו MPEG-2 Transport Stream מתחת ל-HTTP Live Streaming

5.8. מדיה מאובטחת

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

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

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

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

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

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

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

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

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

  • [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 OpenSL ES של מאגר הנתונים הזמני של PCM.
  • [SR] מומלץ מאוד לספק רמה עקבית של ביצועי המעבד (CPU), בזמן שהאודיו פעיל והעומס על המעבד (CPU) משתנה. צריך לבדוק את זה באמצעות SimpleSynth שמירה 1bd6391. צריך להריץ את אפליקציית SimpleSynth עם הפרמטרים הבאים ולהשיג אפס רווחים אחרי 10 דקות:
    • מחזורי עבודה: 200,000
    • טעינת משתנה: מופעלת (הפעולה הזו תשנה בין 100% ל-10% מהערך של מחזורי העבודה כל 2 שניות, ומטרתה לבדוק את ההתנהגות של מושל המעבד)
    • טעינה מיוצבת: מושבתת
  • אמור לצמצם את אי הדיוק של שעון האודיו וסחף ביחס לזמן הסטנדרטי.
  • צריך לצמצם את הסחף של שעון האודיו ביחס למעבד (CPU) CLOCK_MONOTONIC כששניהם פעילים.
  • זה אמור לצמצם את זמן האחזור של האודיו במתמרים ששמורים במכשיר.
  • יש לצמצם את זמן האחזור של האודיו באודיו דיגיטלי בחיבור USB.
  • צריך לתעד את המדידות של זמן האחזור של האודיו בכל הנתיבים.
  • אמור לצמצם את הרעידות בזמני הכניסה של הקריאה החוזרת להשלמת מאגר הנתונים הזמני של האודיו, כי הפעולה הזו משפיעה על אחוז השימוש מרוחב הפס המלא במעבד (callback).
  • אמור לספק אפס הפרעות אודיו (פלט) או חריגות (קלט) בשימוש רגיל בזמן אחזור שדווח.
  • אמורה לספק הפרש בין זמן האחזור בין הערוצים.
  • זמן האחזור הממוצע של MIDI אמור לצמצם את זמן האחזור בכל אמצעי התחבורה.
  • צריכה לצמצם את השונות של זמן האחזור של MIDI בעומס (רעידות) בכל ההעברות.
  • צריכה לספק חותמות זמן מדויקות לשימוש ב-MIDI בכל אמצעי התחבורה.
  • אמורה למזער את הרעש של אות האודיו במתמרים במכשיר, כולל פרק הזמן שמיד אחרי ההפעלה במצב התחלתי.
  • אמור להיות אפס הפרש בשעון האודיו בין צד הקלט לצד הפלט של נקודות הקצה התואמות, כששניהם פעילים. דוגמאות לנקודות קצה תואמות כוללות את המיקרופון והרמקול במכשיר או את הקלט והפלט של שקע האודיו.
  • צריכה לטפל בקריאות חוזרות (callback) של השלמת מאגר הנתונים של האודיו בשביל צדי הקלט והפלט של נקודות הקצה המתאימות באותו השרשור כששניהם פעילים, ולהזין את הקריאה החוזרת של הפלט מיד אחרי שהיא חוזרת מהקריאה החוזרת של הקלט. לחלופין, אם לא ניתן לטפל בקריאות החוזרות באותו שרשור, צריך להזין את הקריאה החוזרת (callback) של הפלט זמן קצר לאחר הזנת הקריאה החוזרת של הקלט, כדי לאפשר לאפליקציה תזמון עקבי של צד הקלט והפלט.
  • אמור לצמצם את הפרש המופעים בין אגירת אודיו של HAL עבור צד הקלט וצד הפלט של נקודות הקצה המתאימות.
  • צריכה למזער את זמן האחזור של המגע.
  • צריכה למזער את ההשתנות של זמן האחזור של המגע במקרה של עומס (רעידות).

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

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

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

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

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

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

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

  • [C-4-1] חייבת לתמוך בפלט בסטריאו ובשמונה ערוצים בעומק 20 או 24 ביט וב- 192kHz, ללא איבוד עומק או דגימה מחדש של עומק הסיביות.

5.11. צילום למכשירים לא מעובדים

ב-Android יש תמיכה בהקלטה של אודיו לא מעובד דרך מקור האודיו android.media.MediaRecorder.AudioSource.UNPROCESSED. ב-OpenSL ES, אפשר לגשת אליה באמצעות ההגדרה הקבועה מראש של SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

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

  • [C-1-1] חובה לדווח על התמיכה דרך הנכס android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNProcessED.

  • [C-1-2] חובה להציג מאפייני תדרים של משרעת (זרם ישר) שטוחה לעומת טווח התדרים: במיוחד ±10dB מ-100Hz עד 7,000Hz לכל מיקרופון שמשמש להקלטה של מקור האודיו הלא מעובד.

  • [C-1-3] חובה להציג את רמות המשרעת בטווח התדרים הנמוכים: במיוחד מ-±20dB מ-5 הרץ עד 100 הרץ בהשוואה לטווח התדרים הבינוני של כל מיקרופון שמשמש להקלטת מקור האודיו הלא מעובד.

  • [C-1-4] חובה להציג את רמות המשרעת בטווח התדרים הגבוה: במיוחד בין ±30dB מ-7,000Hz עד 22KHz בהשוואה לטווח התדרים באמצע כל מיקרופון שמשמש להקלטת מקור האודיו הלא מעובד.

  • [C-1-5] חובה להגדיר את מידת הרגישות של קלט האודיו, כך שמקור טון סינוסאידי של 1,000Hz שמופעל ברמת לחץ קול של 94dB (SPL) מניב תגובה עם RMS של 520 לדגימות של 16 ביט (או -36dB דגימות אודיו מלאות להקלטה תוך כדי הקלטה תוך שימוש בכל רמת דיוק של 94dB בדיוק)

  • [C-1-6] חייב להיות יחס אות לרעש (SNR) של 60 dB או יותר לכל מיקרופון שמשמש להקלטת מקור האודיו הלא מעובד. (בעוד ש-SNR נמדדת כהפרש בין 94 dB SPL לבין SPL שווה ערך לרעש עצמי, משוקלל A).

  • [C-1-7] רמת עיוות הרמונית כוללת (THD) חייבת להיות קטנה מ-1% ל- 1 kHZ ברמת קלט של 90dB SPL בכל מיקרופון שמשמש להקלטת מקור האודיו הלא מעובד.

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

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

כל מדידות ה-SPL מתבצעות ישירות ליד המיקרופון בבדיקה. הדרישות האלה חלות על כל מיקרופון בהגדרות שונות.

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

  • [C-2-1] חייבים להחזיר ערך של null ל-method AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) של ה-API, כדי לציין במדויק שאין תמיכה.
  • [SR] עדיין מומלץ מאוד לעמוד בכמה דרישות של נתיב האות עבור מקור ההקלטה שלא עבר עיבוד.

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

6.1. כלים למפתחים

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

  • [C-0-1] חייבת לתמוך בכלים למפתחי Android שמסופקים ב-Android SDK.

  • גשר לניפוי באגים ב-Android (adb)

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

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

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

  • Dalvik Debug Monitor Service (ddms)

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

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

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

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

  • [C-0-1] חובה לפעול בהתאם לכוונה android.settings.APPLICATION_DEVELOPMENT_SETTINGS כדי להציג הגדרות שקשורות לפיתוח של אפליקציות. הטמעת Android ב-upstream מסתירה את תפריט האפשרויות למפתחים כברירת מחדל ומאפשרת למשתמשים להפעיל את 'אפשרויות למפתחים' אחרי לחיצה שבע (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] שיטות ה-API חייבות להחזיר ערכי null כאשר הדבר מותר במסמכי התיעוד של ה-SDK.
  • [C-0-5] שיטות API חייבות להחזיר הטמעות ללא תפעול של מחלקות שבהן ערכי ה-null אינם מותרים לפי התיעוד של ה-SDK.
  • [C-0-6] שיטות API לא יכולות להקפיץ חריגות שלא תועדו במסמכי התיעוד של ה-SDK.
  • [C-0-7] הטמעות של מכשירים חייבות לדווח באופן עקבי על מידע מדויק של הגדרת החומרה באמצעות השיטות getSystemAvailableFeatures() ו-hasSystemFeature(String) במחלקה android.content.pm.PackageManager, עבור אותה טביעת אצבע של גרסת build.

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

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

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

היחידות שמוזכרות בדרישות בסעיף הזה מוגדרות כך:

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

7.1.1. הגדרת המסך

7.1.1.1. גודל מסך

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

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

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

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

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

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

  • [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, הקרובה ביותר לצפיפות הפיזית, מובילה לגודל המסך הקטן ביותר מגודל המסך התואם הנתמך הקטן ביותר (320 dp רוחב), יישומים במכשירים צריכים לדווח על צפיפות המסגרת הסטנדרטית הבאה של Android.

אם יש אפשרות לשנות את גודל התצוגה של המכשיר:

  • [C-1-1] אסור שגודל התצוגה יהיה גדול מפי 1.5 מהצפיפות המקורית או שגודל המסך המינימלי יהיה קטן מ-320dp (מקביל לערך אישור המשאב sw320dp), המוקדם מביניהם.
  • [C-1-2] אסור שגודל התצוגה יהיה קטן מפי 0.85 מהצפיפות המקורית.
  • כדי להבטיח נוחות שימוש טובה וגודל עקבי של הגופנים, מומלץ לספק את קנה המידה הבא של אפשרויות התצוגה המותאמת (תוך עמידה במגבלות המפורטות למעלה)
  • קטנה: 0.85x
  • ברירת מחדל: 1x (קנה מידה של תצוגה מותאמת)
  • גדול: פי 1.15
  • גדול יותר: פי 1.3
  • הגדול ביותר: 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 המנוהלים (למשל באמצעות ה-method GLES10.getString()) וממשקי ה-API המקוריים.
  • [C-0-2] חייבת לכלול את התמיכה בכל ממשקי ה-API המנוהלים וממשקי ה-API המקוריים התואמים בכל גרסת OpenGL ES שתומכת בהם.

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

  • [C-1-1] חייבת לתמוך ב-OpenGL ES 1.0 וגם בגרסה 2.0, כפי שהוא מוטמע ומפורט במסמכי התיעוד של Android SDK.
  • [SR] מומלץ מאוד לתמוך ב-OpenGL ES 3.0.
  • צריכה לתמוך ב-OpenGL ES 3.1 או 3.2.

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

  • [C-2-1] חובה לדווח על ממשקי ה-API המנוהלים על ידי OpenGL ES וממשקי API מקוריים אחרים שהם הטמיעו, ולעומת זאת אסור לדווח על מחרוזות תוספים שהן לא תומכות בהן.
  • [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] חייבת לתמוך בחבילת התוספים ל-Android של OpenGL ES ל-Android בשלמותה.

אם הטמעות במכשירים תומכים בחבילת התוספים ל-Android של OpenGL ES בשלמותה, הם:

  • [C-5-1] חובה לזהות את התמיכה באמצעות דגל התכונה android.hardware.opengles.aep.

אם הטמעות במכשירים חושפות את התמיכה בתוסף EGL_KHR_mutable_render_buffer, הן:

  • [C-6-1] חייבת לתמוך גם בתוסף EGL_ANDROID_front_buffer_auto_refresh.
7.1.4.2 Vulkan

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

אם בהטמעות במכשירים תומכים ב-OpenGL ES 3.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 לפחות ל-API המקורי של Vulkan vkEnumeratePhysicalDevices() .
  • [C-1-3] חובה להטמיע באופן מלא את ממשקי ה-API של Vulkan 1.0 לכל ערך 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] אסור להצהיר על תכונות ניסיוניות של Vulkan (למשל android.hardware.vulkan.level, android.hardware.vulkan.version).
  • [C-2-2] אסור לספור VkPhysicalDevice ל-API המקורי של Vulkan vkEnumeratePhysicalDevices().
7.1.4.3 RenderScript
  • [C-0-1] הטמעות מכשירים חייבות לתמוך ב-Android RenderScript, כפי שמפורט במסמכים של Android SDK.
7.1.4.4 האצת גרפיקה דו-ממדית

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

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

  • [C-0-1] חייבים להפעיל האצת חומרה כברירת מחדל. אם המפתח מבקש האצת חומרה, צריך להשבית אותה. לשם כך צריך להגדיר את android:hardwareAccelerated="false" או להשבית את האצת החומרה ישירות דרך ממשקי ה-API של Android View.
  • [C-0-2] ההתנהגות חייבת להיות תואמת למסמכי התיעוד של Android SDK בנושא שיפור המהירות באמצעות חומרה.

ב-Android יש אובייקט TextureView שמאפשר למפתחים לשלב באופן ישיר מרקמים של OpenGL ES עם האצת חומרה, בתור יעדי עיבוד בהיררכיה של ממשק משתמש.

  • [C-0-3] חייבת לתמוך ב-TextureView API, והוא חייב להראות התנהגות עקבית עם ההטמעה של Android ב-upstream.
7.1.4.5 מסכים עם טווח רחב

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

7.2. התקני קלט

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

7.2.1. מקלדת

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

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

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

מערכת Android כוללת תמיכה בלחצני החיצים (d-pad), כדור עקיבה וגלגל ענק כמנגנונים לניווט ללא מגע.

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

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

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

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.

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

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

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

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

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

  • [C-4-1] חובה לאפשר גישה לפונקציית Assist באמצעות פעולה אחת (למשל: הקשה, לחיצה כפולה או תנועה) כאשר יש גישה למקשי ניווט אחרים.
  • [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, שתואמת למכשיר קלט באיכות גבוהה שלא מבוססת על מגע (מבוסס-הצבעה), כמו עכבר או משטח מגע, שיכולים לבצע אמולציה הולמת של קלט מבוסס-מגע (כולל תמיכה בסיסית בתנועה), ומציין שהמכשיר תומך בקבוצת משנה אמולמית של פונקציונליות מסך מגע.

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

  • צריך להצהיר על תמיכה בדגל הפיצ'ר 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 בשדה ה-API של Configuration.touchscreen.

אם הטמעות המכשירים מצהירות על תמיכה ב-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 אל קבועי view.InputEvent של Android המשויכים, כפי שמפורט בטבלאות הבאות. ההטמעה של Android ב-upstream כוללת הטמעה לבקרי משחקים שעומדים בדרישה הזו.
לחצן שימוש במכשיר ממשק אנושי (HID)2 לחצן Android
א1 0x09 0x0001 KEYCODE_button_A (96)
ב1 0x09 0x0002 KEYCODE_button_B (97)
X1 0x09 0x0004 KEYCODE_button_X (99)
כן1 0x09 0x0005 KEYCODE_button_Y (100)
לחצני החיצים (D-pad)1
לחצני החיצים (D-pad)1 		0x01 0x00393 AXIS_HAT_Y4
לחצני החיצים (D-pad) משמאל1
לחצני החיצים (D-pad) ימין1 		0x01 0x00393 AXIS_HAT_X4
לחצן הכתף השמאלי1 0x09 0x0007 KEYCODE_button_L1 (102)
לחצן כתף ימין1 0x09 0x0008 KEYCODE_button_R1 (103)
לחיצה על הלחצן השמאלי1 0x09 0x000E KEYCODE_button_THUMBL (106)
לחיצה על הלחצן הימני1 0x09 0x000F KEYCODE_button_THUMBR (107)
דף הבית1 0x0c 0x0223 KEYCODE_HOME (3)
לדף הקודם1 0x0c 0x0224 KEYCODE_BACK (4)

אירוע מרכזי אחד

2 יש להצהיר על השימוש ב-HID שלמעלה ב-Game pad CA (0x01 0x0005).

3 השימוש הזה חייב להיות בעל מינימום לוגי של 0, מקסימום לוגי של 7, מינימום פיזי של 0, מקסימום פיזי של 315, יחידות במעלות וגודל דוח של 4. הערך הלוגי מוגדר כסיבוב של 45 מעלות בכיוון השעון, הרחק מהציר האנכי. לדוגמה, ערך לוגי של 0 מייצג שלא ניתן לסובב את הלחצן למעלה, בעוד שהערך הלוגי של 1 מייצג סיבוב של 45 מעלות, וגם סיבוב של 45 מעלות ושל המקשים שמאלה ולמעלה.

4 MotionEvent

אמצעי בקרה אנלוגיים1 שימוש במכשיר ממשק אנושי (HID) לחצן Android
טריגר שמאלי 0x02 0x00C5 AXIS_LTRIGGER
טריגר ימני 0x02 0x00C4 AXIS_RTRIGGER
ג'ויסטיק שמאלי 0x01 0x0030
0x01 0x0031 		AXIS_X
AXIS_Y
ג'ויסטיק ימני 0x01 0x0032
0x01 0x0035 		AXIS_Z
AXIS_RZ

MotionEvent אחד

7.2.7. שלט רחוק

ראו סעיף 2.3.1 לדרישות ספציפיות למכשיר.

7.3. חיישנים

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

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

  • [C-0-1] חובה לדווח בצורה מדויקת על נוכחות או היעדר של חיישנים בכל מחלקה android.content.pm.PackageManager.
  • [C-0-2] חובה להחזיר רשימה מדויקת של חיישנים נתמכים באמצעות SensorManager.getSensorList() ושיטות דומות.
  • [C-0-3] חובה להתנהג באופן סביר בכל ממשקי ה-API של החיישנים האחרים (לדוגמה, על ידי החזרת true או false בהתאם לצורך כאשר אפליקציות מנסות לרשום מאזינים, ללא קריאה למאזינים של חיישנים כאשר החיישנים המתאימים לא נמצאים, וכו').

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

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

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

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

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

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

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

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

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

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

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

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

7.3.1. מד תאוצה

  • יישומים של מכשירים צריכים לכלול מד תאוצה ב-3 צירים.

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

  • [C-1-1] חייבת להיות אפשרות לדווח על אירועים בתדירות של עד 50Hz לפחות.
  • [C-1-2] חובה להטמיע את החיישן TYPE_ACCELEROMETER ולדווח עליו.
  • [C-1-3] חייב לעמוד בדרישות של מערכת הקואורדינטות של חיישנים של Android, שמפורטות בממשקי ה-API של Android.
  • [C-1-4] חייבת להיות מסוגלת למדוד מצניחה חופשית עד פי ארבעה מכוח הכבידה(4 ג') או יותר בכל ציר.
  • [C-1-5] חייבת להיות ברזולוציה של 12 ביט לפחות.
  • [C-1-6] חייבת להיות סטיית תקן של פחות מ-0.05 מטר/s^, שבה יש לחשב את סטיית התקן על בסיס לכל ציר על סמך דגימות שנאספו במשך פרק זמן של 3 שניות לפחות בקצב הדגימה המהיר ביותר.
  • [SR] מומלץ מאוד להטמיע את החיישן המורכב TYPE_SIGNIFICANT_MOTION.
  • [SR] מומלץ מאוד להטמיע את החיישן TYPE_ACCELEROMETER_UNCALIBRATED אם זמין כיול של מד תאוצה באינטרנט.
  • צריך להטמיע את החיישנים המורכבים TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR ו-TYPE_STEP_COUNTER כמו שמתואר במסמך ה-SDK של Android.
  • צריך לדווח על אירועים עד 200 Hz לפחות.
  • הרזולוציה צריכה להיות לפחות 16 סיביות.
  • צריך לכייל את המכשיר בזמן השימוש אם המאפיינים משתנים במהלך מחזור החיים ומתגמלים אותם, ושומרים את הפרמטרים של הפיצוי בין הפעלה מחדש של המכשיר.
  • הטמפרטורה אמורה לפצות על הטמפרטורה.
  • צריך להטמיע גם את החיישן TYPE_ACCELEROMETER_UNCALIBRATED.

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

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

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

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

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

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

7.3.2. מגנטומטר

  • יישומים של מכשירים צריכים לכלול מגנטומטר (מצפן) עם 3 צירים.

אם הטמעתם במכשירים שונים מגנטומטר עם 3 צירים:

  • [C-1-1] חובה להטמיע את החיישן TYPE_MAGNETIC_FIELD.
  • [C-1-2] חייבת להיות אפשרות לדווח על אירועים עד לתדירות של 10 Hz לפחות, ועליכם לדווח על אירועים עד 50 Hz לפחות.
  • [C-1-3] חייב לעמוד בדרישות של מערכת הקואורדינטות של חיישנים של Android, שמפורטות בממשקי ה-API של Android.
  • [C-1-4] חייבת להיות יכולת למדוד בין -900 μT לבין +900 μT בכל ציר לפני שימוש ברוויה.
  • [C-1-5] ערך ההיסט של הברזל הקשיח שנמוך מ- 700 μT והערך צריך להיות נמוך מ- 200 μT, על ידי הצבת המגנטומטר רחוק מהשדות המגנטיים הדינמיים (עם הגברה הנוכחית) ומהשדות הסטטיים (בהגברת מגנט).
  • [C-1-6] הרזולוציה צריכה להיות שווה או צפופה יותר מ-0.6 μT.
  • [C-1-7] חובה לתמוך בכיול מקוון ובפיצוי על הטיית ברזל קשיח, ולשמר את הפרמטרים של הפיצוי בין הפעלה מחדש של המכשיר.
  • [C-1-8] חובה להחיל את הפיצוי עם הברזל הרך – אפשר לבצע את הכיול תוך כדי שימוש במכשיר או במהלך הייצור שלו.
  • [C-1-9] חייבת להיות סטיית תקן שמחושבת על בסיס כל ציר על בסיס דגימות שנאספו במשך תקופה של 3 שניות לפחות בקצב הדגימה המהיר ביותר, לא יותר מ- 1.5 μT; צריכה להיות סטיית תקן של לא יותר מ- 0.5 μT.
  • צריך להטמיע את החיישן TYPE_MAGNETIC_FIELD_UNCALIBRATED.
  • [SR] מומלץ מאוד להטמיע את החיישן TYPE_MAGNETIC_FIELD_UNCALIBRATED במכשירי Android קיימים וחדשים.

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

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

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

  • יכול להיות שהחיישן TYPE_GEOMAGNETIC_ROTATION_VECTOR יוטמע.

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

  • [C-3-1] חובה לצרוך פחות מ-10 מגה-ואט.
  • צריך לצרוך פחות מ-3 מגה-ואט כשהחיישן רשום במצב אצווה של 10 הרץ.

7.3.3. GPS

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

  • מקלט זה אמור לכלול מקלט GPS/GNSS.

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

  • [C-1-1] חייבת להיות תמיכה בפלט של המיקום בקצב של 1Hz לפחות כשנשלחת בקשה דרך LocationManager#requestLocationUpdate.
  • [C-1-2] חייבת להיות אפשרות לקבוע את המיקום בתנאים של שמיים פתוחים (אותות חזקים, מולטי-פתי זניח, HDOP < 2) תוך 10 שניות (זמן מהיר לתיקון הראשון), כשיש חיבור לאינטרנט במהירות של 0.5Mbps או מהירות נתונים גבוהה יותר. כדי לעמוד בדרישה הזו, משתמשים בדרך כלל בשיטה כלשהי של GPS/GNSS חזויות או בסיוע GPS כדי למזער את זמן הנעילה של ה-GPS/GNSS (נתוני הסיוע כוללים את זמן ההפניה, מיקום ההפניה והזמן/שעון הלוויין).
    • [SR] אחרי חישוב מיקום כזה, מומלץ מאוד שהמכשיר יוכל לקבוע את המיקום שלו בשמיים, בתוך 10 שניות כשבקשות המיקום מופעלות מחדש, עד שעה אחרי חישוב המיקום הראשוני, גם אם הבקשה הבאה נשלחת ללא חבילת גלישה ו/או אחרי מחזור חשמל.

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

    • [C-1-3] חייבת להיות אפשרות לקבוע את המיקום בטווח של 20 מטר, והמהירות היא בטווח של 0.5 מטר לשנייה, לפחות ב-95% מהזמן.
    • [C-1-4] חובה לעקוב בו-זמנית ולדווח באמצעות GnssStatus.Callback לפחות 8 לוויינים מקבוצת כוכבים אחת.
    • אמורה להיות אפשרות לעקוב בו-זמנית אחרי לפחות 24 לוויינים, מכמה קבוצות כוכבים (למשל, GPS + לפחות לוויין אחד, בייטו, גלילאו).
    • [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 ו-LocationManager.getGnssYearOfHardware() Test API מדווח על שנת 2016 ואילך, הן:

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

אם בהטמעות המכשיר יש מקלט GPS/GNSS ומדווחים על היכולת לאפליקציות באמצעות דגל התכונה android.hardware.location.gps ו-LocationManager.getGnssYearOfHardware() Test API מדווח על שנת 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] חייבת להיות אפשרות לדווח על אירועים בתדירות של עד 50Hz לפחות.
  • [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 לכל Hz (שונות ל-Hz או rad^2 / s). השונות יכולה להשתנות בהתאם לקצב הדגימה, אבל חייבת להיות מוגבלת על ידי הערך הזה. במילים אחרות, אם מודדים את השונות של הג'יירו בקצב דגימה של 1 Hz, הוא לא אמור להיות גדול מ-1e-7 rad^2/s^2.
  • [SR] מומלץ מאוד להטמיע את החיישן SENSOR_TYPE_GYROSCOPE_UNCALIBRATED במכשירי Android קיימים וחדשים.
  • [SR] שגיאת כיול מומלץ מאוד לערך של פחות מ-0.01 rad/s כאשר המכשיר נייח בטמפרטורת החדר.
  • צריך לדווח על אירועים עד 200 Hz לפחות.

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

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

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

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

7.3.5. ברומטר

  • יישומי המכשיר צריכים לכלול ברומטר (חיישן לחץ אוויר סביבתי).

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

  • [C-1-1] חובה להטמיע את החיישן TYPE_PRESSURE ולדווח עליו.
  • [C-1-2] חייבת להיות אפשרות לספק אירועים בתדירות של 5Hz או יותר.
  • [C-1-3] חובה לפצות על הטמפרטורה.
  • [SR] מומלץ מאוד לדווח על מדידות לחץ בטווח של 300hPa עד 1100hPa.
  • הדיוק שלו אמור להיות מוחלט של 1hPa.
  • רמת הדיוק היחסית אמורה להיות 0.12hPa על טווח של 20hPa (שווה ערך לדיוק של כ-1 מ' לשינוי של כ-200 מ' בגובה פני הים).

7.3.6. מדחום

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

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

  • [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] רמת דיוק של ביט אחד או יותר.

7.3.9. חיישנים באיכות גבוהה

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

  • [C-1-1] חובה לזהות את היכולת באמצעות דגל התכונה android.hardware.sensor.hifi_sensors.

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

  • [C-2-1] חייב להיות חיישן TYPE_ACCELEROMETER שמאפשר:

    • טווח המדידה חייב להיות בין -8G ל-8G+.
    • רזולוציית המדידה חייבת להיות לפחות 1,024 LSB/G.
    • תדירות המדידה המינימלית חייבת להיות 12.5Hz או נמוכה יותר.
    • תדירות המדידה המקסימלית חייבת להיות 400 Hz או יותר.
    • הרעש במדידה חייב להיות נמוך מ- 400 uG/שהזמנת Hz.
    • החיישן הזה חייב להטמיע צורה שאינה במצב שינה, עם יכולת אגירת נתונים של 3,000 אירועי חיישנים לפחות.
    • צריכת החשמל באצווה חייבת להיות נמוכה מ-3 מגה-ואט.
    • צריכה להיות יציבות של הטיית רעש נייחית של \<15 μg לצאת ממערך נתונים סטטי של 24 שעות.
    • אמור להיות שינוי בהטיה לעומת טמפרטורה של ≤ +/- 1mg / °C .
    • הקו המתאים ביותר צריך להיות לא ליניארי עם ערך של 0.5% או פחות, ושינוי הרגישות לעומת הטמפרטורה לא צריך להיות 0.03%/C°.
    • צריך להיות ספקטרום של רעש לבן כדי להבטיח התאמה הולמת של תקינות הרעש של החיישן.

  • [C-2-2] חובה לספק TYPE_ACCELEROMETER_UNCALIBRATED עם אותן דרישות איכות כמו במוצר TYPE_ACCELEROMETER.

  • [C-2-3] חייב להיות חיישן TYPE_GYROSCOPE שמאפשר:

    • טווח המדידה חייב להיות בין -1000 ל- +1000 dps.
    • רזולוציית המדידה חייבת להיות לפחות 16 LSB/dps.
    • תדירות המדידה המינימלית חייבת להיות 12.5Hz או נמוכה יותר.
    • תדירות המדידה המקסימלית חייבת להיות 400 Hz או יותר.
    • הרעש במדידה חייב להיות נמוך מ-0.014°/s/לצאת.
    • במערך נתונים סטטי של 24 שעות, צריכה להיות בו יציבות של ההטיה היציבה של פחות מ-0.0002 °/s Hz.
    • אמור להיות שינוי בהטיה לעומת טמפרטורה של ≤ +/- 0.05 °C/ s / °C.
    • צריך להיות שינוי ברגישות לעומת הטמפרטורה של 0.02% / °C.
    • הקו המתאים ביותר צריך להיות לא ליניארי, כלומר 0.2% או פחות.
    • צפיפות הרעש אמורה להיות ≤ 0.007 °/s/COLUMNHz.
    • צריך להיות ספקטרום של רעש לבן כדי להבטיח התאמה הולמת של תקינות הרעש של החיישן.
    • כשהמכשיר לא נייח, אמורה להופיע שגיאת כיול בטווח טמפרטורות של 10 ~ 40°C מתחת ל-0.002 rad/s.

  • [C-2-4] חובה לספק TYPE_GYROSCOPE_UNCALIBRATED עם אותן דרישות איכות כמו במוצר TYPE_GYROSCOPE.

  • [C-2-5] חייב להיות חיישן TYPE_GEOMAGNETIC_FIELD שעומד בתנאים הבאים:
    • טווח המדידה חייב להיות בין -900 ל- +900 uT.
    • רזולוציית המדידה חייבת להיות לפחות 5 LSB/uT.
    • תדירות המדידה המינימלית חייבת להיות 5Hz או נמוכה יותר.
    • תדירות המדידה המקסימלית חייבת להיות 50Hz או יותר.
    • הרעש במדידה חייב להיות נמוך מ-0.5 UT.
  • [C-2-6] חובה לספק TYPE_MAGNETIC_FIELD_UNCALIBRATED עם אותן דרישות איכות כמו TYPE_GEOMAGNETIC_FIELD, ובנוסף:
    • החיישן הזה חייב להטמיע צורה שאינה במצב שינה, עם יכולת אגירת נתונים של 600 אירועי חיישן לפחות.
    • צריך להיות ספקטרום של רעש לבן כדי להבטיח התאמה הולמת של תקינות הרעש של החיישן.
  • [C-2-7] חייב להיות חיישן TYPE_PRESSURE שעומד בתנאים הבאים:
    • טווח המדידה חייב להיות בין 300 ל-1100 hPa.
    • רזולוציית המדידה חייבת להיות לפחות 80 LSB/hPa.
    • תדירות המדידה המינימלית חייבת להיות 1 Hz או נמוכה יותר.
    • תדירות המדידה המקסימלית חייבת להיות 10Hz או יותר.
    • הרעש במדידה חייב להיות נמוך מ-2 Pa/😂.
    • החיישן הזה חייב להטמיע צורה שאינה במצב שינה, עם יכולת אגירת נתונים של 300 אירועי חיישן לפחות.
    • צריכת החשמל באצווה חייבת להיות נמוכה מ-2 מגה-ואט.
  • [C-2-8] חייב להיות חיישן TYPE_GAME_ROTATION_VECTOR שעומד בתנאים הבאים:
    • החיישן הזה חייב להטמיע צורה שאינה במצב שינה, עם יכולת אגירת נתונים של 300 אירועי חיישן לפחות.
    • צריכת החשמל באצווה חייבת להיות נמוכה מ-4 מגה-ואט.
  • [C-2-9] חייב להיות חיישן TYPE_SIGNIFICANT_MOTION שעומד בתנאים הבאים:
    • צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי, ו-1.5 מגה-ואט כשהמכשיר נמצא בתנועה.
  • [C-2-10] חייב להיות חיישן TYPE_STEP_DETECTOR ש:
    • החיישן הזה חייב להטמיע צורה שאינה במצב שינה, עם יכולת אגירת נתונים של 100 אירועי חיישן לפחות.
    • צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי, ו-1.5 מגה-ואט כשהמכשיר נמצא בתנועה.
    • צריכת החשמל באצווה חייבת להיות נמוכה מ-4 מגה-ואט.
  • [C-2-11] חייב להיות חיישן TYPE_STEP_COUNTER ש:
    • צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי, ו-1.5 מגה-ואט כשהמכשיר נמצא בתנועה.
  • [C-2-12] חייב להיות חיישן TILT_DETECTOR ש:
    • צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי, ו-1.5 מגה-ואט כשהמכשיר נמצא בתנועה.
  • [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 התואם כפי שמתואר בתיעוד של Android SDK.
  • [C-1-3] שיעור קבלה שגוי חייב להיות נמוך מ-0.002%.
  • [SR] מומלץ מאוד ששיעור הקבלה של זיוף ומתחזה לא יעלה על 7%.
  • [C-1-4] חובה לציין שהמצב הזה עלול להיות פחות מאובטח מקוד אימות, קו ביטול נעילה או סיסמה חזקים, ולפרט באופן ברור את הסיכונים להפעלתו אם שיעור הסכמות של הזיוף וההתחזות גבוה מ-7%.
  • [C-1-5] חובה להגביל את הקצב של יצירת הבקשות למשך 30 שניות לפחות לאחר חמש ניסיונות שווא לאימות באמצעות טביעת אצבע.
  • [C-1-6] האפליקציה חייבת לכלול הטמעה של מאגר מפתחות שמגובה בחומרה, וצריך לבצע את ההתאמה של טביעת האצבע בסביבת ביצוע מהימנה (TEE) או על שבב עם ערוץ מאובטח ל-TEE.
  • [C-1-7] כל הנתונים של טביעות האצבע שניתן לזהות צריכים להיות מוצפנים ומאומתים באמצעות קריפטוגרפיה, כך שלא ניתן יהיה להשיג אותם, לקרוא אותם או לשנות אותם מחוץ לסביבת הביצוע המהימנה (TEE), כפי שמפורט בהנחיות להטמעה באתר של פרויקט הקוד הפתוח של Android.
  • [C-1-8] חובה למנוע הוספה של טביעת אצבע בלי ליצור קודם שרשרת אמון על ידי דרישת המשתמש לאשר קיים או להוסיף פרטי כניסה חדשים למכשיר (קוד אימות/קו ביטול נעילה/סיסמה) שמאובטחים על ידי TEE. ההטמעה של פרויקט קוד פתוח של Android מספקת את המנגנון שב-framework כדי לעשות זאת.
  • [C-1-9] אסור לאפשר לאפליקציות של צד שלישי להבחין בין טביעות אצבע בודדות.
  • [C-1-10] MUST יפעל בהתאם לסימון DevicePolicyManager.KEYGUARD_DISABLE_FINGERprint.
  • [C-1-11] כשמשדרגים מגרסה ישנה יותר מ-Android 6.0, צריך להעביר או להסיר את נתוני טביעות האצבע באופן מאובטח כדי לעמוד בדרישות שפורטו למעלה.
  • [SR] מומלץ מאוד ששיעור דחייה שקרי של פחות מ-10% יהיה נמוך מ-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. חיישן תנוחה

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

  • MAY תמיכה בחיישן תנוחה עם 6 דרגות חופש.

אם יישומים של מכשירים תומכים בחיישן תנוחת מיקום עם 6 דרגות חופש:

  • [C-1-1] חובה להטמיע את החיישן TYPE_POSE_6DOF ולדווח עליו.
  • [C-1-2] חייב להיות מדויק יותר מהווקטור הסיבוב לבדו.

7.4. קישוריות נתונים

7.4.1. טלפוניה

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

  • ניתן להשתמש ב-Android MAY במכשירים שלא כוללים חומרת טלפון. כלומר, מערכת Android תואמת למכשירים שאינם טלפונים.

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

  • [C-1-1] חובה להצהיר על דגל הפיצ'ר android.hardware.telephony וסימונים של תכונות משנה אחרות בהתאם לטכנולוגיה.
  • [C-1-2] חייבים להטמיע תמיכה מלאה ב-API בטכנולוגיה הזו.

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

  • [C-2-1] חובה להטמיע את כל ממשקי ה-API כללא תפעול.
7.4.1.1. תאימות לחסימת מספרים

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

  • [C-1-1] חייבת לכלול תמיכה בחסימת מספרים
  • [C-1-2] חובה להטמיע באופן מלא את BlockedNumberContract ואת ה-API התואם, כפי שמתואר במסמכי התיעוד של ה-SDK.
  • [C-1-3] חובה לחסום את כל השיחות וההודעות ממספר טלפון ב-'BlockedNumberProvider', ללא אינטראקציה עם האפליקציות. יוצא הדופן היחיד הוא כאשר חסימת המספרים מבוטלת באופן זמני, כפי שמתואר במסמכי התיעוד של ה-SDK.
  • [C-1-4] אסור לכתוב לספק יומן השיחות של הפלטפורמה לגבי שיחה שנחסמה.
  • [C-1-5] אסור לכתוב לספק הטלפוניה על הודעה חסומה.
  • [C-1-6] חובה להטמיע ממשק משתמש חסום לניהול מספרים, שנפתח באמצעות Intent שהוחזר על ידי השיטה TelecomManager.createManageBlockedNumbersIntent().
  • [C-1-7] אסור לאפשר למשתמשים משניים לראות או לערוך את המספרים החסומים במכשיר, כי פלטפורמת Android מניחה שלמשתמש הראשי יש שליטה מלאה על שירותי הטלפוניה, אירוע אחד, במכשיר. כל ממשקי המשתמש הקשורים לחסימה חייבים להיות מוסתרים עבור משתמשים משניים, והרשימה החסומה עדיין חייבת להיות נכללת.
  • המכשיר אמור להעביר את המספרים החסומים לספק לאחר עדכון המכשיר ל-Android 7.0.
7.4.1.2. API של Telecom

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

  • [C-SR] מומלץ מאוד לטפל באירועי KEYCODE_MEDIA_PLAY_PAUSE ו-KEYCODE_HEADSETHOOK של אוזניות האודיו בממשקי ה-API של android.telecom כפי שמפורט בהמשך:
    • קוראים לפונקציה Connection.onDisconnect() כשמזוהה לחיצה קצרה על האירוע המרכזי במהלך שיחה פעילה.
    • קוראים לפונקציה Connection.onAnswer() כשמזוהה לחיצה קצרה על האירוע המרכזי במהלך שיחה נכנסת.
    • קוראים לפונקציה Connection.onReject() כשמזוהה לחיצה ארוכה על האירוע המרכזי במהלך שיחה נכנסת.
    • החלפת מצב ההשתקה של CallAudioState

7.4.2. IEEE 802.11 (Wi-Fi)

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

  • היא צריכה לכלול תמיכה עבור צורה אחת או יותר של 802.11.

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

  • [C-1-1] חובה להטמיע את Android API התואם.
  • [C-1-2] חובה לדווח על הדגל של תכונת החומרה android.hardware.wifi.
  • [C-1-3] חובה להטמיע את multicast API כפי שמתואר במסמכי התיעוד של ה-SDK.
  • [C-1-4] חובה לתמוך ב-Multicast 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 ישיר (Wi-Fi מקצה לקצה).

אם הטמעות המכשירים כוללות תמיכה ב-Wi-Fi ישיר:

  • [C-1-1] חובה להטמיע את Android API התואם כפי שמתואר במסמכי התיעוד של ה-SDK.
  • [C-1-2] חובה לדווח על תכונת החומרה android.hardware.wifi.direct.
  • [C-1-3] חייבת להיות תמיכה בפעולת Wi-Fi רגילה.
  • צריכה לתמוך בפעולות Wi-Fi ו-Wi-Fi ישיר בו-זמנית.

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

אם הטמעות המכשירים כוללות תמיכה ב-TDLS וב-TDLS מופעל באמצעות ה-Wi-FiManager API, הן:

  • [C-1-1] חובה להצהיר על תמיכה ב-TDLS עד WifiManager.isTdlsSupported.
  • יש להשתמש ב-TDLS רק כאשר זה אפשרי ומועיל.
  • אמור להיות שימוש בשיטה היוריסטית או לא להשתמש ב-TDLS אם הביצועים שלו נמוכים יותר מאשר דרך נקודת הגישה ל-Wi-Fi.
7.4.2.3. עם חיבור ל-Wi-Fi

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

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

  • [C-1-1] חובה להטמיע את ממשקי ה-API של WifiAwareManager כפי שמתואר במסמכי התיעוד של ה-SDK.
  • [C-1-2] חובה להצהיר על דגל התכונה android.hardware.wifi.aware.
  • [C-1-3] חובה לתמוך בפעולות Wi-Fi ו-Wi-Fi Aware בו-זמנית.
  • [C-1-4] הכתובת של ממשק הניהול עם מודעות ל-Wi-Fi חייבת להגדיר רנדומיזציה במרווחי זמן של לא יותר מ-30 דקות ובכל פעם ש-Wi-Fi Aware מופעל.
7.4.2.4. Passpoint ל-Wi-Fi

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

אם הטמעות המכשירים כוללות תמיכה ב-Wi-Fi Passpoint:

  • [C-1-1] חובה להטמיע את ממשקי ה-API WifiManager שקשורים ל-Passpoint, כמו שמתואר במסמכי התיעוד של ה-SDK.
  • [C-1-2] חייבת לתמוך בתקן IEEE 802.11u, שקשור ספציפית לגילוי ולבחירה של רשת, כגון שירות פרסום כללי (GAS) ופרוטוקול Access Network Query Protocol (ANQP).

לעומת זאת, אם הטמעות המכשירים לא כוללות תמיכה ב-Wi-Fi Passpoint:

  • [C-2-1] ההטמעה של ממשקי ה-API מסוג WifiManager שקשורים ל-Passpoint חייבת לגרום להצגת UnsupportedOperationException.

7.4.3. ‫Bluetooth

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

  • צריכה לתמוך ברכיבי קודק אודיו מתקדמים ובקודקי אודיו של Bluetooth (למשל LDAC).

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

  • [C-1-1] חייבת להיות תמיכה ב-Bluetooth 4.2 ובתוסף אורך נתונים LE של Bluetooth LE.

ב-Android יש תמיכה ב-Bluetooth וב-Bluetooth עם צריכת אנרגיה נמוכה.

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

  • [C-2-1] חובה להצהיר על תכונות הפלטפורמה הרלוונטיות (android.hardware.bluetooth ו-android.hardware.bluetooth_le בהתאמה) ולהטמיע את ממשקי ה-API של הפלטפורמה.
  • עליכם להטמיע פרופילים רלוונטיים של Bluetooth כמו A2DP, 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 באמצעות ה-method android.content.pm.PackageManager.hasSystemFeature().
  • חייבת להיות יכולת לקרוא ולכתוב הודעות NDEF באמצעות תקני NFC הבאים:
  • [C-1-2] חייבת להיות יכולת לפעול כקורא/כותב בפורום NFC (כפי שמוגדר במפרט הטכני NFCForum-TS-DigitalProtocol-1.0) באמצעות תקני NFC הבאים:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • סוגי התגים של פורום NFC 1, 2, 3, 4, 5 (הוגדרו על ידי פורום NFC)

  • [SR] מומלץ מאוד לקרוא ולכתוב הודעות NDEF וגם נתונים גולמיים באמצעות תקני NFC הבאים. לתשומת ליבכם: בעוד שתקני ה-NFC מצויינים כ'מומלץ מאוד', הגדרת התאימות לגרסה עתידית מתוכננת לשנות אותם ל'חובה'. בגרסה הזו התקנים האלה הם אופציונליים, אבל הם יידרשו בגרסאות עתידיות. אנחנו ממליצים מאוד שמכשירים קיימים וחדשים שבהם פועלת הגרסה הזו של Android יעמדו בדרישות האלה עכשיו, כדי שניתן יהיה לשדרג לגרסאות עתידיות של הפלטפורמה.

  • [C-1-3] חייבת להיות יכולת להעביר ולקבל נתונים באמצעות התקנים והפרוטוקולים הבאים מקצה לקצה:

  • ISO 18092
  • LLCP 1.2 (מוגדר על ידי פורום NFC)
  • SDP 1.0 (מוגדר על ידי פורום NFC)
  • פרוטוקול דחיפה מסוג NDEF
  • SNEP 1.0 (מוגדר על ידי פורום NFC)
  • [C-1-4] חייבת לכלול תמיכה ב-Android Beam ו-צריך להפעיל את Android Beam כברירת מחדל.
  • [C-1-5] חייבת להיות אפשרות לשלוח ולקבל באמצעות Android Beam, כאשר Android Beam מופעל או מופעל מצב קנייני אחר של NFC P2p.
  • [C-1-6] חובה להטמיע את שרת ברירת המחדל של SNEP. הודעות NDEF חוקיות שהתקבלו בשרת SNEP כברירת מחדל חייבות להישלח לאפליקציות באמצעות Intent 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 ולנסות לשלוח P2P NDEF לשרת ברירת המחדל כש-Android Beam מופעל. אם לא נמצא שרת SNEP שמוגדר כברירת מחדל, הלקוח חייב לנסות לשלוח לשרת NPP.
  • [C-1-10] חובה לאפשר לפעילויות בחזית להגדיר את הודעת ה-P2P NDEF היוצאת באמצעות android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback ו-android.nfc.NfcAdapter.enableForegroundNdefPush.
  • צריך להשתמש בתנועה או באישור במסך, כמו 'Touch to Beam', לפני שליחה של הודעות P2P NDEF יוצאות.
  • [C-1-11] המכשיר חייב לתמוך בהעברה של חיבור NFC ל-Bluetooth כשהמכשיר תומך בדחיפה של אובייקט Bluetooth.
  • [C-1-12] חייבת לתמוך בהעברת החיבור ל-Bluetooth במהלך השימוש ב-android.nfc.NfcAdapter.setBeamPushUris, על ידי הטמעת המפרטים של 'שיתוף חיבור גרסה 1.2' ו'התאמה פשוטה של Bluetooth באמצעות NFC גרסה 1.0' מהפורום של NFC. יישום כזה חייב להטמיע את שירות LLCP המסירה עם שם השירות “urn:nfc:sn:handover” לצורך החלפה של בקשת ההעברה/בחירת רשומות ב-NFC, ועליו להשתמש בפרופיל הדחיפה לאובייקט Bluetooth כדי לבצע בפועל את העברת הנתונים מ-Bluetooth. מסיבות מדור קודם (כדי לשמור על תאימות למכשירי Android 4.1), ההטמעה עדיין אמורה לקבל בקשות SNEP GET לצורך החלפת בקשת ההעברה או הרשומות שנבחרו ב-NFC. עם זאת, היישום עצמו לא אמור לשלוח בקשות SNEP GET לביצוע מסירת חיבור.
  • [C-1-13] חובה לבצע סקר לכל הטכנולוגיות הנתמכות במצב גילוי NFC.
  • המכשיר צריך להיות במצב גילוי NFC בזמן שהמכשיר לא במצב שינה, כשהמסך פעיל ומסך הנעילה לא נעול.
  • צריכה להיות יכולת לקרוא את הברקוד ואת כתובת ה-URL (אם מקודדים) של מוצרי ברקוד Thinfilm NFC.

(שימו לב שהקישורים שזמינים לציבור לא זמינים במפרטים של הפורום של JIS, ISO ו-NFC שמצוינים למעלה).

מערכת Android כוללת תמיכה במצב NFC Host Card Emulation (HCE).

אם הטמעות המכשיר כוללות ערכת שבבים של בקר NFC שמסוגלת לפעול ב-HCE (ל-NfcA ו/או ל-NfcB) ותומכות בניתוב של מזהה אפליקציה (AID), הן:

  • [C-2-1] חובה לדווח על קבוע התכונה android.hardware.nfc.hce.
  • [C-2-2] חייבת להיות תמיכה בממשקי API של NFC HCE כפי שמוגדר ב-Android SDK.

אם הטמעות המכשיר כוללות ערכת שבבים של בקר NFC שמסוגלת להשתמש ב-HCE עבור NfcF, ומטמיעות את התכונה באפליקציות צד שלישי:

אם הטמעות המכשירים כוללות תמיכה כללית ב-NFC כפי שמתואר בקטע הזה ותומכות בטכנולוגיות MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF on 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 לשנייה או יותר. דוגמאות לטכנולוגיות שעומדות בדרישה הזו: 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), כאשר תקן רשת פיזי (כמו אתרנט) הוא חיבור הנתונים הראשי.
  • ייתכן שתטמיעו יותר מצורה אחת של קישוריות נתונים.

הרמה הנדרשת של תמיכה ב-IPv6 תלויה בסוג הרשת, באופן הבא:

אם המכשירים תומכים ברשתות Wi-Fi, הם:

  • [C-1-1] חייבת לתמוך בפעולה כפולה בסטאק וב-IPv6 בלבד ב-Wi-Fi.

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

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

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

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

7.4.6. הגדרות סנכרון

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

  • [C-0-1] הגדרת הסנכרון האוטומטי הראשי חייבת להיות מופעלת כברירת מחדל, כדי שהשיטה getMasterSyncAutomatically() תחזיר את הערך 'true'.

7.4.7. חסכונית בנתונים

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

  • [SR] מומלץ מאוד לספק את מצב חוסך הנתונים (Data Saver).

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

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

  • [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] חובה להצהיר על דגל התכונה 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] אסור לשקף את תמונת הסטילס או הווידאו הסופית שחוזרות לשיחות חוזרות של האפליקציה או שהיא מחויבת לאחסון של מדיה.
  • [C-1-7] חייבת לשקף את התמונה שמופיעה ב-postview באותו אופן כמו התמונה של התצוגה המקדימה של המצלמה.
  • ייתכן שיכללו תכונות (כמו מיקוד אוטומטי, פלאש וכו') הזמינות למצלמות אחוריות, כפי שמתואר בסעיף 7.5.1.

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

  • [C-2-1] התצוגה המקדימה של המצלמה חייבת להיות משוכפלת לרוחב המסך ביחס לכיוון הנוכחי של המכשיר.

7.5.3. מצלמה חיצונית

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

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

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

  • [C-1-1] חובה להצהיר על דגל הפלטפורמה android.hardware.camera.external ו-android.hardware camera.any.
  • [C-1-2] חייבת להיות תמיכה ב-USB Video Class (UVC 1.0 ואילך) אם המצלמה החיצונית מתחברת דרך יציאת ה-USB.
  • צריכה לתמוך בדחיסות וידאו כמו MJPEG כדי לאפשר העברה של שידורים לא מקודדים באיכות גבוהה (כלומר, סטרימינג של תמונה גולמית או שידור דחוס בנפרד).
  • יכול להיות שתומכות במספר מצלמות.
  • ייתכן שתומכת בקידוד וידאו מבוסס מצלמה. אם יש תמיכה בשידור, שאינו מקודד / MJPEG בו-זמנית (רזולוציית QVGA או יותר) חייב להיות נגיש להטמעת המכשיר.

7.5.4. התנהגות ה-API של המצלמה

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

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

בהטמעות של מכשירים צריך ליישם את ההתנהגויות הבאות בממשקי ה-API שקשורים למצלמות, בכל המצלמות הזמינות. הטמעות מכשירים:

  • [C-0-1] חובה להשתמש ב-android.hardware.PixelFormat.YCbCr_420_SP לנתוני תצוגה מקדימה שסופקו לקריאות חוזרות של אפליקציה אם אפליקציה לא התקשרה אף פעם ל-android.hardware.Camera.Parameters.setPreviewFormat(int).
  • [C-0-2] חייב להיות בפורמט הקידוד NV21 כשאפליקציה רושמת מכונת android.hardware.Camera.PreviewCallback והמערכת קוראת ל-method onPreviewFrame() ופורמט התצוגה המקדימה הוא YCbCr_420_SP, הנתונים בבייט[] שמועברים אל onPreviewFrame(). כלומר, NV21 חייבת להיות ברירת המחדל.
  • [C-0-3] חייבת לתמוך בפורמט YV12 (כפי שמצוין בקבוע android.graphics.ImageFormat.YV12) לתצוגה מקדימה של המצלמה עבור android.hardware.Camera במצלמה הקדמית וגם במצלמה האחורית. (המצלמה ומקודד הווידאו של החומרה עשויים להשתמש בכל פורמט של פיקסל מקורי, אבל הטמעת המכשיר חייבת לתמוך בהמרה ל-YV12).
  • [C-0-4] חייבת לתמוך בפורמטים android.hardware.ImageFormat.YUV_420_888 ו-android.hardware.ImageFormat.JPEG כפלט באמצעות ה-API של android.media.ImageReader למכשירי android.hardware.camera2 שמפרסמים את היכולת REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE ב-android.request.availableCapabilities.
  • [C-0-5] עדיין חובה להטמיע את ה-מצלמה API המלא שמופיע בתיעוד של Android SDK, גם אם המכשיר כולל מיקוד אוטומטי בחומרה או יכולות אחרות. למשל, מצלמות ללא מיקוד אוטומטי חייבות עדיין לקרוא למופעים רשומים של android.hardware.Camera.AutoFocusCallback (למרות שאין להם רלוונטיות למצלמה ללא מיקוד אוטומטי). שים לב: הדבר נכון לגבי מצלמות קדמיות. לדוגמה, למרות שרוב המצלמות הקדמית לא תומכות במיקוד אוטומטי, הקריאות החוזרות של ה-API עדיין צריכות להיות "מזויפות" כפי שמתואר.
  • [C-0-6] חובה לזהות כל שם של פרמטר שמוגדר כקבוע במחלקה android.hardware.Camera.Parameters ולכבד אותו. לעומת זאת, אסור שהטמעות במכשירים יפעלו כקבועים של מחרוזות שמועברים ל-method 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] חובה לשדר את ה-Intent Camera.ACTION_NEW_PICTURE בכל פעם שתמונה חדשה צולמה על ידי המצלמה והרשומה של התמונה מתווספת לחנות המדיה.
  • [C-0-10] חובה לשדר את ה-Intent 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] חובה לטעון את האחסון המשותף של האפליקציה ישירות בנתיב sdcard של Linux או לכלול קישור סימבולי של Linux מ-sdcard לנקודת הטעינה עצמה.
  • [C-0-4] חובה לאכוף את ההרשאה android.permission.WRITE_EXTERNAL_STORAGE באחסון המשותף הזה כפי שמתועד ב-SDK. בכל אפליקציה שמקבלת את ההרשאה הזו, נפח האחסון המשותף חייב להיות ניתן לכתיבה בכל מקרה אחר.

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

  • אחסון נשלף שנגיש למשתמש, כמו חריץ לכרטיס Secure Digital (SD).
  • חלק מהאחסון הפנימי (לא ניתן להסרה) כפי שמוטמע בפרויקט קוד פתוח (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, העברת קבצים ב-Android.
  • אמור לדווח על סוג התקן 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 או Type-C.
  • [C-1-2] חובה לדווח על הערך הנכון של iSerialNumber במתאר של מכשיר USB סטנדרטי עד android.os.Build.SERIAL.
  • [C-1-3] חייבים לזהות מטענים עם הספק 1.5A ו-3.0A בהתאם לתקן של נגד Type-C. בנוסף, הם חייבים לזהות שינויים במודעה אם הם תומכים ב-USB מסוג C.
  • [SR] היציאה צריכה להשתמש בגורם צורה של USB מסוג מיקרו-B, מיקרו-AB או USB. מכשירי Android קיימים וחדשים מומלץ מאוד לעמוד בדרישות האלה, כדי שאפשר יהיה לשדרג אותם לגרסאות עתידיות של הפלטפורמה.
  • [SR] היציאה צריכה להיות ממוקמת בחלק התחתון של המכשיר (בהתאם לכיוון הטבעי) או לאפשר סיבוב מסך של התוכנה בכל האפליקציות (כולל מסך הבית), כדי שהמסך ייחתך כראוי כשהמכשיר מיושר עם היציאה התחתונה. מכשירי Android קיימים וחדשים מומלץ מאוד לעמוד בדרישות האלה, כדי שאפשר יהיה לשדרג אותם לגרסאות עתידיות של הפלטפורמה.
  • [SR] אמורה להטמיע תמיכה כדי למשוך זרם של 1.5 A במהלך ציוץ ותנועה של HS כפי שמצוין במפרט של טעינת סוללה ב-USB, גרסה 1.2. מכשירי Android קיימים וחדשים מומלץ מאוד לעמוד בדרישות האלה, כדי שאפשר יהיה לשדרג אותם לגרסאות עתידיות של הפלטפורמה.
  • [SR] מומלץ מאוד לא לתמוך בשיטות טעינה קנייניות שמשנות את מתח Vbus מעבר לרמות ברירת המחדל, או שישנו תפקידים של sink/מקור, כי הדבר עלול לגרום לבעיות ביכולת הפעולה ההדדית (interoperability) במטענים או במכשירים שתומכים בשיטות הסטנדרטיות של העברת חשמל ב-USB. התכונה הזו נקראת 'מומלץ מאוד', אבל בגרסאות עתידיות של Android יכול להיות שנדרוש שכל המכשירים מסוג C יתמכו ביכולת פעולה הדדית מלאה עם מטענים סטנדרטיים מסוג C.
  • [SR] מומלץ מאוד לתמוך ב-Power Delivery להחלפת נתונים ותפקידי חשמל כשהם תומכים במצב מארח USB-C ו-USB.
  • אמורה להיות תמיכה באספקת חשמל לטעינה במתח גבוה ותמיכה במצבים חלופיים, כמו מסך חוץ.
  • יש להטמיע את ה-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] חובה להטמיע את ממשק ה-API של מארח USB ל-Android כפי שמתואר ב-Android SDK. כמו כן, חובה להצהיר על תמיכה בתכונת החומרה android.hardware.usb.host.
  • [C-1-2] חובה להטמיע תמיכה כדי לחבר ציוד היקפי סטנדרטי בחיבור USB. כלומר, חייב להיות באחת מהאפשרויות הבאות:
    • צריכה להיות במכשיר יציאה מסוג C או ספינה עם כבלים, שמאפשרת להתאים יציאה קניינית במכשיר ליציאת USB מסוג C סטנדרטית (מכשיר USB-C).
    • צריך להיות מכשיר מסוג A או חיבור עם כבלים, שמאפשר להתאים יציאה קניינית במכשיר ליציאת USB מסוג A סטנדרטית.
    • צריכה להיות בהם יציאת מיקרו-AB במכשיר, שאמורה להישלח עם כבל שמתאים ליציאה סטנדרטית מסוג A.
  • [C-1-3] אסור לשלוח עם מתאם שמבצע המרה מיציאות USB מסוג A או מיציאות מיקרו-AB לשקע מסוג C (שקע).
  • [SR] מומלץ מאוד להטמיע את סיווג האודיו USB כפי שמתועד בתיעוד של Android SDK.
  • צריכה לתמוך בטעינת ציוד היקפי בחיבור USB מחובר במצב מארח; פרסום זרם מקור של 1.5A לפחות כפי שמצוין בקטע 'פרמטרים של סיום' בתיקון 1.2 כבל ומפרט מחבר של USB Type-C עבור מחברים מסוג USB-C, או שימוש בטווח הנוכחי של פלט בשקע USB מסוג C(CDP) כמפורט במפרט הטעינה של סוללת USB, גרסה 1.2.
  • עליכם להטמיע ולתמוך בתקני USB Type-C.

אם הטמעות המכשירים כוללות יציאת USB שתומכת במצב מארח ואת סיווג האודיו ב-USB:

  • [C-2-1] חייב לתמוך בסיווג USB HID
  • [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 (פרוטוקול העברת מדיה) שמחוברים מרחוק, ולהפוך את התוכן שלהם לנגיש באמצעות ה-Intents 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, ומומלץ מאוד לתמוך באספקת החשמל (Power Delivery) להחלפת נתונים והחלפת תפקידי כוח.
  • [SR] מומלץ מאוד לא לתמוך במצב האביזר של מתאם האודיו כפי שמתואר בנספח א' של גרסה 1.2 של כבל USB-C ומפרט המחבר.
  • עליכם להטמיע את מודל Try.* המתאים ביותר לגורם הצורה של המכשיר. לדוגמה, במכשיר ידני צריך להטמיע את המודל Try.SNK.

7.8. אודיו

7.8.1. מיקרופון

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

  • [C-1-1] חובה לדווח על קבוע התכונה android.hardware.microphone.
  • [C-1-2] חייבת לעמוד בדרישות לגבי הקלטת אודיו שמפורטות בסעיף 5.4.
  • [C-1-3] חייב לעמוד בדרישות זמן האחזור של האודיו שמפורטות בסעיף 5.6.
  • [SR] מומלץ מאוד לתמוך בהקלטת אולטרסאונד, כפי שמתואר בסעיף 7.8.3.

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

  • [C-2-1] אסור לדווח על קבוע התכונה android.hardware.microphone.
  • [C-2-2] חובה להטמיע את ה-API של הקלטת האודיו לפחות כפעולות ללא תפעול, לפי סעיף 7.

7.8.2. יעד השמע

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

  • [C-1-1] חובה לדווח על קבוע התכונה android.hardware.audio.output.
  • [C-1-2] חייב לעמוד בדרישות להפעלת אודיו שמפורטות בסעיף 5.5.
  • [C-1-3] חייב לעמוד בדרישות זמן האחזור של האודיו שמפורטות בסעיף 5.6.
  • [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, אם הטמעה של מכשיר כוללת יציאת אודיו אנלוגית אחת או יותר, לפחות אחת מיציאות האודיו צריכה להיות שקע אודיו עם 4 מוליכים 3.5 מ"מ.

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

  • [C-1-1] חייבת לתמוך בהפעלת אודיו באוזניות סטריאו ובאוזניות סטריאו עם מיקרופון.
  • [C-1-2] חייבת לתמוך במחברי האודיו ב-TRRS עם הזמנת ההצמדה של CTIA.
  • [C-1-3] חייבת לתמוך בזיהוי ובמיפוי לקודי המפתחות עבור 3 הטווחים הבאים של העכבה המקבילה בין המיקרופון למוליכי הקרקע בתקע האודיו:
    • 70 או פחות או פחות: KEYCODE_HEADSETHOOK
    • 210-290 אוהם: KEYCODE_VOLUME_UP
    • 360-680 אוהם: KEYCODE_VOLUME_DOWN
  • [C-1-4] חייבים להפעיל את ACTION_HEADSET_PLUG בכל הכנסת תקע, אבל רק אחרי שכל אנשי הקשר בשקע נוגעים במקטעים הרלוונטיים בשקע.
  • [C-1-5] חייבת להיות מסוגלת להניע לפחות 150mV ± 10% ממתח היציאה בעכבת רמקול של 32 אוהם.
  • [C-1-6] חייבת להיות הטיית מיקרופון בין 1.8 וולט כ-2.9 וולט.
  • [SR] מומלץ מאוד לזהות את קוד המפתח ולמפות אותו לטווח העכבה הבא בין המיקרופון למוליכי הקרקע בתקע האודיו:
    • 110-180 אוהם: KEYCODE_VOICE_ASSIST
  • אמורה לתמוך בשקעי אודיו עם סדר היציאה של OMTP.
  • אמורה לתמוך בהקלטת אודיו מאוזניות סטריאו עם מיקרופון.

אם בהטמעות של מכשירים יש שקע אודיו של 4 מוליך בגודל 3.5 מ"מ ותומכות במיקרופון, והמיקרופון של android.intent.action.HEADSET_PLUG מוגדר לערך 1 הנוסף:

  • [C-2-1] חייבת להיות תמיכה בזיהוי המיקרופון באביזר האודיו המחובר.

7.8.3. קרוב לאולטרסאונד

אודיו Near-Ultrasound הוא תדר של 18.5kHz עד 20kHz.

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

  • חייבים לדווח בצורה נכונה על תמיכה באודיו כמעט-קולי דרך ה-API של AudioManager.getProperty API באופן הבא:

אם הערך PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND הוא 'true', מקורות האודיו VOICE_RECOGNITION ו-UNPROCESSED חייבים לעמוד בדרישות הבאות:

  • [C-1-1] תגובת ההספק הממוצעת של המיקרופון בתדרים 18.5kHz עד 20kHz חייבת להיות לא יותר מ-15dB מתחת לתגובה ב-2kHz.
  • [C-1-2] יחס האות הלא משוקלל לרעש של המיקרופון מעל 18.5 kHz עד 20kHz לטון של 19kHz ב- -26dBFS חייב להיות לא פחות מ-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 עם ביצועים גבוהים למשך תקופות ארוכות יותר באמצעות סימון התכונה 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] ה-GPU והמסך חייבים להיות מסוגלים לסנכרן את הגישה למאגר הנתונים הקדמי המשותף, כך שעיבוד עיניים מתחלפות של תוכן VR במהירות של 60fps עם שני הקשרי רינדור יוצג ללא פריטי מידע שנוצרו בתהליך העיבוד (Artifact).
  • [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 של לפחות 3840x2160@30fps-40Mbps (שווה ל-4 מופעים של 1920x1080@30fps-10Mbps או שני מופעים של 1920x1080@60fps-20Mbps).
  • [C-1-12] חייבת לתמוך ב-HEVC וב-VP9. היא חייבת להיות מסוגלת לפענח לפחות 1920x1080@30fps-10Mbps, וצריכה להיות יכולת לפענח 3840x2160@30fps-20Mbps (שווה ערך ל-4 מופעים של 80Mbps@1920x).
  • [C-1-13] האפליקציה חייבת לתמוך ב-API של HardwarePropertiesManager.getDeviceTemperatures ולהחזיר ערכים מדויקים של טמפרטורת העור.
  • [C-1-14] חייב להיות מסך מוטמע, והרזולוציה שלו חייבת להיות לפחות FullHD(1080p) ומומלץ מאוד להיות באיכות QuadHD (1440p) ומעלה.
  • [C-1-15] המסך חייב להתעדכן לפחות 60 Hz במצב VR.
  • [C-1-16] זמן האחזור של התצוגה (כפי שנמדד בזמן ההחלפה 'אפור-לאפור', 'לבן לשחור' ו'שחור-לבן') חייב להיות ≤ 6 אלפיות השנייה.
  • [C-1-17] המסך חייב לתמוך במצב של התמדה נמוכה עם תדירות של 5 אלפיות השנייה או פחות. מדד זה מוגדר כמשך הזמן שבו פיקסל פולט אור.
  • [C-1-18] חייבת להיות תמיכה ב-Bluetooth 4.2 ובתוסף אורך נתונים של Bluetooth LE בסעיף 7.4.3.
  • [C-1-19] חובה לתמוך בסוג ערוץ ישיר ולדווח עליו כראוי בכל סוגי החיישנים הבאים שמוגדרים כברירת מחדל:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-1-20] חייב לתמוך בסוג הערוץ הישיר TYPE_HARDWARE_BUFFER לכל סוגי הערוצים הישירים המפורטים למעלה.
  • [SR] מומלץ מאוד לתמוך בתכונה android.hardware.sensor.hifi_sensors וחייבים לעמוד בדרישות שקשורות לג'ירוסקופ, למד התאוצה ולמגנטומטר עבור android.hardware.hifi_sensors.
  • MAY מספק ליבה בלעדית לאפליקציה בחזית, ו-MAY תומך ב-API Process.getExclusiveCores כדי להחזיר את הנתונים של ליבות ה-CPU שבלעדיות לאפליקציה בחזית. אם יש תמיכה בליבה בלעדית, אסור שתהליכים אחרים במרחב המשתמשים יוכלו לפעול עליה (למעט מנהלי התקנים של מכשירים שהאפליקציה משתמשת בהם), אבל יכול להיות שהיא תאפשר הרצה של תהליכי ליבה מסוימים לפי הצורך.

8. ביצועים ועוצמה

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

8.1. עקביות בחוויית המשתמש

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

8.2. ביצועים של גישת קלט/פלט לקובץ

יצירת בסיס משותף לעקביות בביצועי הגישה לקבצים באחסון הנתונים הפרטיים של האפליקציה (המחיצה /data), מאפשרת למפתחי אפליקציות להגדיר ציפיות שיעזרו להם לתכנן את התוכנה. בהטמעות של מכשירים, בהתאם לסוג המכשיר, ייתכן שיש דרישות מסוימות שמתוארות בסעיף 2 לגבי פעולות הקריאה והכתיבה הבאות:

  • ביצועי כתיבה ברצף. המדידה מתבצעת על ידי כתיבת קובץ של 256MB באמצעות מאגר נתונים זמני של 10MB.
  • ביצועי כתיבה אקראיים. המדידה מתבצעת על ידי כתיבת קובץ של 256MB באמצעות מאגר נתונים זמני של 4KB.
  • ביצועי קריאה ברצף. המדידה מתבצעת על ידי קריאת קובץ של 256MB באמצעות מאגר נתונים זמני של 10MB.
  • ביצועי קריאה אקראיים. המדידה מתבצעת על ידי קריאת קובץ של 256MB באמצעות מאגר נתונים זמני של 4KB.

8.3. מצבי חיסכון בסוללה

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

בנוסף למצבי החיסכון בסוללה, בהטמעות של מכשירי Android ייתכן מיושם כל אחד מארבעת המצבים של אספקת החשמל במצב שינה, או את כולם, כפי שהוגדרו על ידי Advanced Configuration (הגדרות אישיות) ו-Power Interface (ACPI).

אם בהטמעות במכשירים מיושמות מצבי כוח S3 ו-S4 כפי שהוגדרו ב-ACPI, הם:

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

8.4. חשבונאות של צריכת הכוח

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

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

  • [SR] מומלץ מאוד לספק פרופיל חשמל לכל רכיב שמגדיר את ערך הצריכה הנוכחית של כל רכיב חומרה ואת התרוקנות הסוללה המשוערת שנגרמה על ידי הרכיבים לאורך זמן, כפי שתועד באתר של פרויקט הקוד הפתוח של Android.
  • [SR] מומלץ מאוד לדווח על כל ערכי צריכת החשמל באלפיות השנייה (mAh).
  • [SR] מומלץ מאוד לדווח על צריכת החשמל של המעבד (CPU) לפי ה-UID של כל תהליך. פרויקט הקוד הפתוח של Android עומד בדרישה באמצעות הטמעת מודול הליבה של uid_cputime.
  • [SR] מומלץ מאוד להפעיל את השימוש הזה בחשמל באמצעות פקודת המעטפת adb shell dumpsys batterystats למפתח האפליקציה.
  • צריך להיות משויך לרכיב החומרה עצמו אם אין אפשרות לשייך לאפליקציה את צריכת החשמל של רכיב החומרה.

8.5. ביצועים עקביים

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

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

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

  • [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] מומלץ מאוד לספק מנגנון נגיש למשתמש כדי להעניק או לבטל גישה לנתוני השימוש בתגובה ל-Intent של 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] חייבת לתמוך במודל Sandbox של אפליקציות Android, שבו כל אפליקציה פועלת כ-UID ייחודי של Unixstyle ובתהליך נפרד.
  • [C-0-2] חייבת לתמוך בהפעלת אפליקציות מרובות כאותו מזהה משתמש ב-Linux, בתנאי שהאפליקציות חתומות ובבנייה כראוי, כפי שמוגדר בחומר העזר בנושא אבטחה והרשאות.

9.3. הרשאות במערכת הקבצים

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

9.4. סביבות הפעלה חלופיות

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

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

  • [C-0-2] אסור לתת לזמני ריצה חלופיים גישה למשאבים שמוגנים על ידי הרשאות שלא התבקשו בקובץ AndroidManifest.xml של סביבת זמן הריצה באמצעות המנגנון <uses-permission>.

  • [C-0-3] אסור להגדיר זמני ריצה חלופיים לאפליקציות להשתמש בתכונות שמוגנות באמצעות הרשאות של Android שמוגבלות לאפליקציות מערכת.

  • [C-0-4] זמני ריצה חלופיים חייבים לציית לדגם ארגז החול של Android ולאפליקציות מותקנות באמצעות סביבת זמן ריצה חלופית, אסור להשתמש שוב ב-Sandbox של אפליקציות אחרות שמותקנות במכשיר, אלא באמצעות המנגנונים הרגילים של 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] חובה להצפין את התוכן של כרטיס ה-SD כאשר האפשרות 'ריבוי משתמשים' מופעלת באמצעות מפתח המאוחסן רק במדיה שאינה נשלפת, הנגישה למערכת רק אם יישומים של מכשירים משתמשים במדיה נשלפת עבור ממשקי API של אחסון חיצוני. במצב כזה, קובצי המדיה לא יהיו ניתנים לקריאה על ידי מחשב מארח, ולכן ההטמעות של המכשירים יצטרכו לעבור ל-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 ב-upstream מספק הטמעה שעומדת בדרישה הזו.

9.7. תכונות אבטחת ליבה (kernel)

ארגז החול של Android כולל תכונות שמשתמשות במערכת בקרת גישה (MAC) חיונית ל-Linux (SELinux), הרצה בארגז חול (sandboxing) ב-seccomp ותכונות אבטחה נוספות בליבה (kernel) של Linux. הטמעות מכשירים:

  • [C-0-1] חייבת לשמור על תאימות לאפליקציות קיימות, גם אם SELinux או תכונות אבטחה אחרות מוטמעות מתחת ל-framework של Android.
  • [C-0-2] ממשק משתמש לא גלוי כשתזוהה הפרת אבטחה ונחסם בהצלחה על ידי תכונת האבטחה שמוטמעת מתחת ל-framework של Android. עם זאת, יכול להיות שממשק המשתמש יהיה גלוי כשמתרחשת הפרת אבטחה לא חסומה שמובילה לניצול מוצלח.
  • [C-0-3] אסור להפעיל את SELinux או כל תכונת אבטחה אחרת שמוטמעת מתחת למסגרת Android, שאפשר להגדיר למשתמש או למפתח האפליקציה.
  • [C-0-4] אסור לאפשר לאפליקציה שעשויה להשפיע על אפליקציה אחרת באמצעות ממשק API (כגון Device Administration API) להגדיר מדיניות שמפרה את התאימות.
  • [C-0-5] חייבים לפצל את מסגרת המדיה לכמה תהליכים כדי שאפשר יהיה להעניק גישה בצורה מצומצמת יותר לכל תהליך, כפי שמתואר באתר של פרויקט הקוד הפתוח של Android.
  • [C-0-6] חובה להטמיע מנגנון ארגז חול (sandboxing) של אפליקציית ליבה שמאפשר לסנן קריאות מערכת באמצעות מדיניות שניתנת להגדרה מתוכנות עם שרשורים מרובים. פרויקט קוד פתוח של Android ב-upstream עומד בדרישה הזו באמצעות הפעלת seccomp-BPF עם סנכרון קבוצת שרשור (TSYNC), כפי שמתואר בקטע 'הגדרת ליבה' (Kernel) של source.android.com.

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

  • [C-0-7] חובה להטמיע הגנות מפני גלישת מאגר נתונים זמני של ליבה (kernel) (למשל CONFIG_CC_STACKPROTECTOR_STRONG).
  • [C-0-8] חובה ליישם אמצעי הגנה מחמירים על זיכרון ליבה (kernel) כאשר קוד ההפעלה הוא לקריאה בלבד, נתונים לקריאה בלבד לא ניתנים להפעלה ולא לכתיבה, ונתונים ניתנים לכתיבה לא ניתנים להפעלה (למשל CONFIG_DEBUG_RODATA או CONFIG_STRICT_KERNEL_RWX).
  • [SR] מומלץ מאוד לשמור נתוני ליבה שנכתבו רק במהלך האתחול ומסומנים לקריאה בלבד לאחר האתחול (למשל __ro_after_init).
  • [SR} מומלץ מאוד ליישם בדיקת גודל של אובייקט סטטי ודינמי של עותקים בין מרחב משתמש ומרחב ליבה (למשל CONFIG_HARDENED_USERCOPY).
  • [SR] מומלץ מאוד לא להפעיל זיכרון-מרחב משתמש כשמריצים בליבה (kernel) (למשל, חומרה PXN או אמולציה דרך CONFIG_CPU_SW_DOMAIN_PAN או CONFIG_ARM64_SW_TTBR0_PAN).
  • [SR] מומלץ מאוד לא לקרוא או לכתוב זיכרון-מרחב של משתמש בליבה (kernel) מחוץ לממשקי API רגילים לגישה לעותק משתמש (למשל, מספר PAN של החומרה, או אמולציה באמצעות CONFIG_CPU_SW_DOMAIN_PAN או CONFIG_ARM64_SW_TTBR0_PAN).
  • [SR] מומלץ מאוד להגדיר באופן אקראי את הפריסה של קוד הליבה ושל הזיכרון, וכדי להימנע מחשיפות שעלולות לסכן את הרנדומיזציה (למשל, CONFIG_RANDOMIZE_BASE עם אנטרופיה של תוכנת אתחול דרך /chosen/kaslr-seed Device Tree node או EFI_RNG_PROTOCOL).

אם הטמעות המכשירים משתמשות בליבה (kernel) של Linux, הן:

  • [C-1-1] חובה להטמיע את SELinux.
  • [C-1-2] חייבים להגדיר את SELinux למצב אכיפה גלובלי.
  • [C-1-3] חובה להגדיר את כל הדומיינים במצב אכיפה. אסור להשתמש בדומיינים של מצב מתירנות, כולל דומיינים ספציפיים למכשיר או לספק.
  • [C-1-4] אסור לשנות, להשמיט או להחליף את הכללים של אף פעם שלא קיימים בתיקיית המערכת/סמדיניות שמסופקת בפרויקט קוד פתוח של Android (AOSP) ב-upstream. בנוסף, המדיניות חייבת להדר את כל כללי אף פעם קיימים, גם בדומיינים של AOSP SELinux וגם בדומיינים ספציפיים למכשירים או לספקים.
  • אמורה לשמור את מדיניות ברירת המחדל של SELinux שצוינה בתיקיית המערכת/sepolicy של פרויקט הקוד הפתוח של Android ב-upstream, ולהוסיף אותה למדיניות הזו רק לצורך הגדרה ספציפית למכשיר שלה.

אם הטמעות של מכשירים משתמשות בליבה (kernel) אחרת מלבד 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 ב-upstream.
  • [C-0-2] חובה לשלוח את המוצר עם חנות בסיס ריקה של משתמש שמנפיקה את האישורים (CA).
  • [C-0-3] חובה להציג למשתמש אזהרה שמציינת שיכול להיות שיתבצע מעקב אחרי התנועה ברשת, כשנוסיף את רשות האישורים הבסיסית של המשתמש.

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

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

אם הטמעות המכשיר כוללות מנגנון, שמופעל מחוץ לאריזה כברירת מחדל, שמנתב את תעבורת הנתונים ברשת דרך שרת proxy או שער VPN (לדוגמה, טעינה מראש של שירות VPN עם הענקת android.permission.CONTROL_VPN), הן:

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

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

  • [C-3-1] חובה להשבית בקובץ AndroidManifest.xml את העלות הכספית של המשתמש הזה לאפליקציות שלא תומכות בשירות VPN שפועל כל הזמן. לשם כך, צריך להגדיר את המאפיין SERVICE_META_DATA_SUPPORTS_ALWAYS_ON לערך false.

9.9. הצפנה של מאגר הנתונים

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

  • [C-1-1] חייבת לתמוך בהצפנת אחסון נתונים של הנתונים הפרטיים של האפליקציה (/data partition), וכן במחיצת האחסון המשותף של האפליקציה (/sdcard partition), אם היא חלק קבוע שלא ניתן להסרה מהמכשיר.

אם בהטמעות המכשיר יש תמיכה במסך נעילה מאובטח כפי שמתואר בסעיף 9.11.1 ותומכות בהצפנה של אחסון נתונים באמצעות תקן הצפנה מתקדם (AES) בביצועי הצפנה של יותר מ-50MiB לשנייה:

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

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

9.9.1. הפעלה ישירה

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

  • [C-0-1] חייבים להטמיע את ממשקי ה-API של מצב הפעלה ישירה גם אם הם לא תומכים בהצפנת Storage.

  • [C-0-2] ה-Intents ACTION_LOCKED_BOOT_COMPLETED ו-ACTION_USER_UNLOCKED עדיין חייבים להיות משודרים כדי לאותת לאפליקציות עם מודעות לאתחול ישיר שמיקומי אחסון בהצפנת מכשיר (DE) והצפנה עם פרטי כניסה זמינים עבור המשתמש.

9.9.2. הצפנה מבוססת קבצים

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

  • [C-1-1] חובה לבצע אתחול בלי לאתגר את המשתמש להזנת פרטי כניסה ולאפשר לאפליקציות שמופעלות בצורה ישירה (Direct Run) לגשת לאחסון בהצפנה במכשיר (DE) אחרי שידור ההודעה של ACTION_LOCKED_BOOT_COMPLETED.
  • [C-1-2] חייבים לאפשר גישה לאחסון של פרטי כניסה מוצפנים רק לאחר שהמשתמש ביטל את נעילת המכשיר על ידי אספקת פרטי הכניסה שלו (למשל קוד גישה, קוד אימות, קו ביטול נעילה או טביעת אצבע) ושודרה ההודעה של 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] חייב להיות קשור לקריפטוגרפיה ל-Keystore שמגובה על ידי חומרה.

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

  • [C-1-10] חייב להיות ייחודי וייחודי. במילים אחרות, אין מפתח CE או DE של משתמש שתואם למפתחות CE או DE של משתמש אחר.

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

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

פרויקט הקוד הפתוח של Android ב-upstream מספק הטמעה מועדפת של התכונה הזו, על סמך תכונת ההצפנה בליבה (kernel) 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 ב-upstream מספק את ההטמעה המועדפת של התכונה הזו, בהתבסס על תכונת הליבה של Linux dm-crypt.

9.10. תקינות המכשיר

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

  • [C-0-1] חובה לדווח בצורה נכונה באמצעות שיטת ה-API של המערכת PersistentDataBlockManager.getFlashLockState() אם מצב תוכנת האתחול מאפשר להבהב של תמונת המערכת. המצב FLASH_LOCK_UNKNOWN שמור להטמעות של מכשירים שמשדרגים מגרסה קודמת של Android שבה לא הייתה השיטה החדשה של ממשק ה-API של המערכת.

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

  • [C-1-1] חובה להצהיר על דגל הפיצ'ר של הפלטפורמה android.software.verified_boot.
  • [C-1-2] חובה לבצע אימות בכל רצף אתחול.
  • [C-1-3] חובה להתחיל את האימות ממפתח חומרה שלא ניתן לשינוי, שהוא ה-Root of Trust (תחושת ה-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] מומלץ מאוד להטמיע הגנה מפני החזרה למצב קודם עבור ה-HLOS (למשל הפעלה, מחיצות מערכת) ולהשתמש באחסון שמבטיח התעסקות במכשיר לאחסון המטא-נתונים שמשמשים לקביעת הגרסה המינימלית של מערכת ההפעלה המותרת.
  • יש להטמיע הגנת חזרה למצב קודם עבור כל רכיב עם קושחה קבועה (למשל מודם, מצלמה) ויש להשתמש באחסון מפני זיוף לצורך אחסון המטא-נתונים המשמשים לקביעת הגרסה המינימלית המותרת.

פרויקט קוד פתוח של Android ב-upstream מספק הטמעה מועדפת של התכונה הזו במאגר 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] חובה להגדיר מספר ניסיונות להגבלת קצב של אימות במסך הנעילה וחייב להיות אלגוריתם של השהיה מעריכית לפני ניסיון חוזר (exponential backoff). מעבר ל-150 ניסיונות כושלים, העיכוב חייב להיות לפחות 24 שעות בכל ניסיון.
  • אסור להגביל את מספר המפתחות שאפשר ליצור

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

  • [C-1-1] חובה לגבות את ההטמעה של מאגר המפתחות באמצעות חומרה מאובטחת.
  • [C-1-2] חייבות להיות הטמעות של אלגוריתמים קריפטוגרפיים RSA, AES, ECDSA ו-HMAC, וגם פונקציות גיבוב (hash) משפחתיות של MD5, SHA1 ו-SHA-2, כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמופרד באופן מאובטח מהקוד שפועל בליבה (kernel) ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבהם קוד ליבה או מרחב משתמשים יכול לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. פרויקט הקוד הפתוח של Android (AOSP) ב-upstream עומד בדרישה הזו באמצעות ההטמעה של Trusty. במקום זאת, יש עוד אפשרויות לפתרון מבוסס ARM TrustZone או הטמעה מאובטחת של צד שלישי עם בידוד מתאים שמבוסס על hypervisor.
  • [C-1-3] חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק כשהפעולה מבוצעת בהצלחה, תתאפשר שימוש במפתחות שקשורים לאימות. יש לאחסן את פרטי הכניסה של מסך הנעילה באופן שיאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. פרויקט הקוד הפתוח של Android ב-upstream מספק את Gatekeeper Hardware Layer Abstraction Layer (HAL) ואת 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] חובה להשבית ולאפשר לאימות הראשי לבטל את נעילת המסך רק כשהאפליקציה Device Policy Controller (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) הגדירה את המדיניות בנושא תכונות של נעילת מקשים על ידי קריאה ל-method DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
  • [C-5-3] שיעור קבלה שגוי או גבוה יותר מהערך שנדרש לחיישן טביעות אצבע כפי שמתואר בסעיף 7.3.10. לחלופין, חייבים להשבית אותו ולאפשר לאימות הראשי לבטל את נעילת המסך רק כשהאפליקציה Device Policy Controller (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] חייבת לספק למשתמש אפשרות להיכנס למצב הפעלה בטוחה באופן שלא יפריע לפעולה של אפליקציות צד שלישי שמותקנות במכשיר, למעט במקרים שבהם האפליקציה של הצד השלישי היא Device Policy Controller, והסימון UserManager.DISALLOW_SAFE_BOOT מוגדר כ-true.

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

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

9.14. בידוד של מערכת לכלי רכב

מכשירי Android Automotive צפויים לשתף נתונים עם מערכות משנה קריטיות לרכב באמצעות HAL של הרכב כדי לשלוח ולקבל הודעות ברשתות של רכבים כמו אפיק CAN.

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

10. בדיקת תאימות לתוכנה

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

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

10.1. חבילה לבדיקת תאימות

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

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

10.2. מאמת CTS

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

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

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

11. תוכנות Updatable

יישומי מכשירים חייבים לכלול מנגנון שיחליף את תוכנת המערכת במלואה. המנגנון לא נדרש לבצע שדרוגים "בזמן אמת" – כלומר, ייתכן שתידרש הפעלה מחדש של המכשיר.

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

  • הורדות בחיבור אלחוטי (OTA) עם עדכון אופליין באמצעות הפעלה מחדש.
  • 'שיתוף אינטרנט בין מכשירים' מתעדכן ב-USB ממחשב מארח.
  • עדכונים במצב 'אופליין' על ידי הפעלה מחדש ועדכון מקובץ באחסון נשלף.

עם זאת, אם הטמעת המכשיר כוללת תמיכה בחיבור נתונים ללא שימוש בנתונים, כמו פרופיל 802.11 או פרופיל Bluetooth PAN (רשת אזורית אישית), המכשיר חייב לתמוך בהורדות OTA עם עדכון אופליין באמצעות הפעלה מחדש.

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

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

בנוסף, הטמעות של מכשירים צריכות לתמוך בעדכוני מערכת A/B. ה-AOSP מטמיע את התכונה הזו באמצעות בקרת האתחול 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
    שינויים קוסמטיים או שינויים שקשורים לפיתוח.

לתצוגה הטובה ביותר, יש להוסיף את הפרמטרים pretty=full ו-no-merges לכתובות ה-URL של יומן השינויים.

13. יצירת קשר

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