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

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

1. מבוא

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

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

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

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

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

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

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

1.1 מבנה המסמך

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

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

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

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

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

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

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

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

1.1.3. מזהה הדרישה בקטע 2

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

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

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

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

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

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

2.1 הגדרות המכשיר

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

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

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

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

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

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

2.2.1. חומרה

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

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

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

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

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

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

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

• [7.3.8/H] צריך לכלול חיישן קרבה.

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

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

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

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

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

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

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

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

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

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

  • xhdpi ומעלה במסכים קטנים או רגילים^*
  • hdpi ומעלה במסכים גדולים
  • mdpi ומעלה במסכים גדולים במיוחד

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

  • 400dpi או יותר במסכים קטנים/רגילים^*
  • xhdpi ומעלה במסכים גדולים
  • tvdpi ומעלה במסכים גדולים במיוחד

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

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

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

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

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

• [7.6.1/H-6-1] אם משתמשים באחת מהצפיפויות הבאות, נפח הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 944MB:

  • xhdpi ומעלה במסכים קטנים או רגילים^*
  • hdpi ומעלה במסכים גדולים
  • mdpi ומעלה במסכים גדולים במיוחד

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

  • 400dpi או יותר במסכים קטנים/רגילים^*
  • xhdpi ומעלה במסכים גדולים
  • tvdpi ומעלה במסכים גדולים במיוחד

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

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

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

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

• [7.6.2/H-0-1] אסור לספק אחסון משותף של אפליקציה בנפח קטן מ-1GB.
• [7.7.1/H] צריכה לכלול יציאת USB שתומכת במצב ציוד היקפי.

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

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

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

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

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

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

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

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

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

• [7.9.2/-1-1] חובה להצהיר על דגל התכונה android.hardware.vr.high_performance.

2.2.2. מולטימדיה

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

• [5.1.1/H-0-1] AMR-NB
• [5.1.1/H-0-2] AMR-WB
• [5.1.1/H-0-3] MPEG-4 AAC Profile‏ (AAC LC)
• [5.1.1/H-0-4] MPEG-4 HE AAC Profile‏ (AAC+)
• [5.1.1/H-0-5] AAC ELD‏ (AAC משופר עם זמן אחזור קצר)

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

• [5.1.2/H-0-1] AMR-NB
• [5.1.2/H-0-2] AMR-WB

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

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

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

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

2.2.3. תוכנות

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

• [3.4.1/H-0-1] חובה לספק הטמעה מלאה של ה-API של android.webkit.Webview.
• [3.4.2/H-0-1] חובה לכלול אפליקציית דפדפן נפרדת לגלישה באינטרנט של משתמשים רגילים.
• [3.8.1/H-SR] מומלץ מאוד להטמיע מרכז אפליקציות שמוגדר כברירת מחדל ותומך בהצמדה של קיצורי דרך וווידג'טים בתוך האפליקציה.
• [3.8.1/H-SR] מומלץ מאוד להטמיע מרכז אפליקציות שמספק גישה מהירה לקיצורי הדרך הנוספים שמוצעים על ידי אפליקציות צד שלישי באמצעות ה-API של ShortcutManager.
• [3.8.1/H-SR] מומלץ מאוד לכלול אפליקציית מרכז אפליקציות שמוגדרת כברירת מחדל ומציגה תגים לסמלי האפליקציות.
• [3.8.2/H-SR] מומלץ מאוד לתמוך בווידג'טים של אפליקציות צד שלישי.
• [3.8.3/H-0-1] חובה לאפשר לאפליקציות צד שלישי להודיע למשתמשים על אירועים משמעותיים באמצעות כיתות ה-API Notification ו-NotificationManager.
• [3.8.3/H-0-2] חובה לתמוך בהתראות מתקדמות.
• [3.8.3/H-0-3] חובה לתמוך בהתראות מראש.
• [3.8.3/H-0-4] חובה לכלול חלונית התראות, שמאפשרת למשתמש לשלוט ישירות בהתראות (למשל, להשיב, להעביר למצב נודניק, לסגור או לחסום אותן) באמצעות רכיבי ממשק משתמש כמו לחצני פעולה או לוח הבקרה כפי שהם מוטמעים ב-AOSP.
• [3.8.4/H-SR] מומלץ מאוד להטמיע עוזרת במכשיר כדי לטפל בפעולת העזרה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.5. מודל אבטחה

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

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

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

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

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

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

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

2.3.1. חומרה

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

• [7.2.2/T-0-1] חובה לתמוך בD-pad.
• [7.2.3/T-0-1] חובה לספק את הפונקציות 'דף הבית' ו'הקודם'.
• [7.2.3/T-0-2] חובה לשלוח לאפליקציה שבחזית גם את האירוע הרגיל וגם את האירוע של לחיצה ארוכה על פונקציית החזרה אחורה (KEYCODE_BACK).
• [7.2.6.1/T-0-1] חובה לכלול תמיכה בפקדי משחק ולהצהיר על דגל התכונה android.hardware.gamepad.
• [7.2.7/T] צריך לספק שלט רחוק שממנו המשתמשים יכולים לגשת לניווט ללא מגע ולקלידות של מפתחות הניווט המרכזיים.

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.2. מולטימדיה

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

• [5.1/T-0-1] MPEG-4 AAC Profile‏ (AAC LC)
• [5.1/T-0-2] MPEG-4 HE AAC Profile‏ (AAC+)
• [5.1/T-0-3] AAC ELD (enhanced low delay AAC)

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

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

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

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

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

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

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

• [5.3/T-SR] MPEG-2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [5.8/T-2-1] חובה לתמוך ב-HDCP 1.4 בכל המסכים החיצוניים המקושרים.

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

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

2.3.3. תוכנות

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

• [3/T-0-1] חובה להצהיר על התכונות android.software.leanback ו-android.hardware.type.television.
• [3.4.1/T-0-1] חובה לספק הטמעה מלאה של ממשק ה-API android.webkit.Webview.

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

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

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

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

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

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

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

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

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

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

• [8.2/T-0-4] חובה להבטיח ביצועי קריאה אקראית של לפחות 3.5MB/s.

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

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

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

• [8.4/T-0-1] חובה לספק פרופיל צריכת חשמל לכל רכיב, שמגדיר את ערך הצריכה הנוכחי של כל רכיב חומרה ואת הירידה המשוערת בנפח הסוללה שנגרמת על ידי הרכיבים לאורך זמן, כפי שמופיע באתר של Android Open Source Project.
• [8.4/T-0-2] חובה לדווח על כל ערכי צריכת החשמל במיליאמפר-שעה (mAh).
• [8.4/T-0-3] חובה לדווח על צריכת החשמל של המעבד לכל מזהה משתמש (UID) של תהליך. פרויקט הקוד הפתוח של Android עומד בדרישות באמצעות הטמעת מודול הליבה uid_cputime.
• [8.4/T] צריך לשייך לרכיב החומרה עצמו אם לא ניתן לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.
• [8.4/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] הפונקציה 'דף הבית' חייבת להיות זמינה למשתמש, וגם הפונקציה 'הקודם', מלבד כשהמכשיר נמצא ב-UI_MODE_TYPE_WATCH.

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

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

• [7.4.3/W-0-1] חובה שתהיה תמיכה ב-Bluetooth.

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

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

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

• [7.8.2/W] יכול להיות שיש לו פלט אודיו, אבל לא צריך להיות.

2.4.2. מולטימדיה

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

2.4.3. תוכנות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.1. חומרה

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

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

• [7.1.1.1/A-0-2] חובה להשתמש בפריסה בגודל מסך של לפחות 750dp x 480dp.

• [7.2.3/A-0-1] חובה לספק את הפונקציה 'דף הבית', ואפשר לספק את הפונקציות 'חזרה' ו'פריטים אחרונים'.

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

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

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

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

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

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

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

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

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

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

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

• [7.3.11.2/A-0-1] חובה לתמוך במצב יום/לילה שמוגדר בתור SENSOR_TYPE_NIGHT.
• [7.3.11.2/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.

• [7.4.3/A-0-1] חובה שתהיה תמיכה ב-Bluetooth ומומלץ שתהיה תמיכה ב-Bluetooth LE.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.2. מולטימדיה

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

• [5.1/A-0-1] MPEG-4 AAC Profile‏ (AAC LC)
• [5.1/A-0-2] MPEG-4 HE AAC Profile‏ (AAC+)
• [5.1/A-0-3] AAC ELD (‏AAC משופר עם זמן אחזור קצר)

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

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

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

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

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

• [5.3/A-SR] H.265 HEVC

2.5.3. תוכנות

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

• [3/A-0-1] חובה להצהיר על התכונה android.hardware.type.automotive.
• [3/A-0-2] חובה לתמוך ב-uiMode = UI_MODE_TYPE_CAR.

• [3/A-0-3] יש צורך שתמיכת Android Automotive תכלול את כל ממשקי ה-API הציבוריים במרחב השמות android.car.*.

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

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

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

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

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

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

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

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

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

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

2.2.5. מודל אבטחה

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

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

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

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

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

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

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

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

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

2.4.1. חומרה

גודל המסך

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

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

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

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

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

• [7.7.1/Tab]אפשר להטמיע את Android Open Accessory (AOA) API.

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

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

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

3. תוכנות

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

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

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

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

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

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

3.2.1. הרשאות

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

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

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

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

פרמטר	פרטים
VERSION.RELEASE	הגרסה של מערכת Android שפועלת כרגע, בפורמט קריא לבני אדם. השדה הזה חייב לכלול אחד מערכי המחרוזות שהוגדרו בקטע 8.0.
VERSION.SDK	הגרסה של מערכת Android שפועלת כרגע, בפורמט שגלוי לקוד של אפליקציות של צד שלישי. ב-Android מגרסה 8.0, הערך בשדה הזה חייב להיות המספר השלם 8.0_INT.
VERSION.SDK_INT	הגרסה של מערכת Android שפועלת כרגע, בפורמט שגלוי לקוד של אפליקציות של צד שלישי. ב-Android מגרסה 8.0, הערך בשדה הזה חייב להיות המספר השלם 8.0_INT.
VERSION.INCREMENTAL	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמציין את ה-build הספציפי של מערכת Android שפועלת כרגע, בפורמט שקריא לבני אדם. אסור להשתמש שוב בערך הזה לגרסאות build שונות שזמינות למשתמשי קצה. השימוש הנפוץ בשדה הזה הוא לציין את מספר ה-build או את מזהה השינוי במערכת הבקרה למקורות הקוד ששימשו ליצירת ה-build. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
משחקי לוח	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את החומרה הפנימית הספציפית שבה המכשיר משתמש, בפורמט שקריא לבני אדם. אפשר להשתמש בשדה הזה כדי לציין את הגרסה הספציפית של הלוח שמפעיל את המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי '^[a-zA-Z0-9_-]+$'.
BRAND	ערך שמשקף את שם המותג שמשויך למכשיר כפי שהוא ידוע למשתמשי הקצה. חייב להיות בפורמט שאפשר לקרוא אותו, וצריך לייצג את היצרן של המכשיר או את מותג החברה שדרכו המכשיר משווק. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי '^[a-zA-Z0-9_-]+$'.
SUPPORTED_ABIS	השם של קבוצת ההוראות (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי.
SUPPORTED_32_BIT_ABIS	השם של קבוצת ההוראות (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי.
SUPPORTED_64_BIT_ABIS	השם של קבוצת ההוראות השנייה (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי.
CPU_ABI	השם של קבוצת ההוראות (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי.
CPU_ABI2	השם של קבוצת ההוראות השנייה (סוג המעבד + מוסכמת ABI) של קוד מקורי. קטע 3.3 תאימות ל-API מקורי.
מכשיר	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם הפיתוח או שם הקוד שמזהה את ההגדרה של תכונות החומרה והעיצוב התעשייתי של המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי '^[a-zA-Z0-9_-]+$'. אסור לשנות את שם המכשיר במהלך משך החיים של המוצר.
FINGERPRINT	מחרוזת שמזהה באופן ייחודי את ה-build הזה. הוא אמור להיות קריא לאנשים באופן סביר. היא חייבת לפעול לפי התבנית הבאה: $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) לדוגמה: acme/myproduct/     mydevice:8.0/LMYXX/3359:userdebug/test-keys האצבעית אסור שתכלול תווים של רווח לבן. אם בשדות אחרים שכלולים בתבנית שלמעלה יש תווים של רווחים לבנים, חובה להחליף אותם בטביעת האצבע של ה-build בתווים אחרים, כמו הקו התחתון ('_'). הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט.
חומרה	שם החומרה (משורת הפקודה של הליבה או מ-/proc). הוא אמור להיות קריא לאנשים באופן סביר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי '^[a-zA-Z0-9_-]+$'.
HOST	מחרוזת שמזהה באופן ייחודי את המארח שבו נוצר ה-build, בפורמט שקריא לבני אדם. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
מזהה	מזהה שנבחר על ידי מי שמטמיע את המכשיר כדי להפנות למהדורה ספציפית, בפורמט קריא לבני אדם. השדה הזה יכול להיות זהה ל-android.os.Build.VERSION.INCREMENTAL, אבל כדאי להגדיר לו ערך בעל משמעות מספקת כדי שמשתמשי הקצה יוכלו להבחין בין גרסאות build של תוכנה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי ‎“^[a-zA-Z0-9._-]+$‎”.
יצרן	השם המסחרי של יצרן הציוד המקורי (OEM) של המוצר. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד האיסור להגדיר אותו כ-null או כמחרוזת ריקה (""). אסור לשנות את השדה הזה במהלך מחזור החיים של המוצר.
דגם	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם המכשיר כפי שהוא ידוע למשתמש הקצה. השם הזה אמור להיות זהה לשם שתחתיו המכשיר משווק ונמכר למשתמשי קצה. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד האיסור להגדיר אותו כ-null או כמחרוזת ריקה (""). אסור לשנות את השדה הזה במהלך מחזור החיים של המוצר.
מוצר	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם הפיתוח או שם הקוד של המוצר הספציפי (מק"ט), שחובה שיהיה ייחודי באותו מותג. חייב להיות קריא לבני אדם, אבל לא בהכרח מיועד לצפייה על ידי משתמשי קצה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי '^[a-zA-Z0-9_-]+$'. אסור לשנות את שם המוצר הזה במהלך כל משך החיים של המוצר.
SERIAL	מספר סידורי של חומרה, שחייב להיות זמין וייחודי במכשירים עם אותו דגם ויצרן. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי ‎“^([a-zA-Z0-9]{6,20})$‎”.
תגים	רשימה של תגים מופרדים בפסיקים שנבחרו על ידי מי שמטמיע את המכשיר, ומשמשים להבדיל בין גרסאות build שונות. השדה הזה חייב לכלול אחד מהערכים התואמים לשלושת ההגדרות הטיפוסיות לחתימה בפלטפורמת Android: release-keys,‏ dev-keys ו-test-keys.
שעה	ערך שמייצג את חותמת הזמן של מועד ה-build.
סוג	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמציין את הגדרת זמן הריצה של ה-build. השדה הזה חייב לכלול אחד מהערכים שתואמים לשלושת ההגדרות הנפוצות של Android בסביבת זמן ריצה: user,‏ userdebug או eng.
משתמש	שם או מזהה משתמש של המשתמש (או המשתמש האוטומטי) שיצר את ה-build. אין דרישות לגבי הפורמט הספציפי של השדה הזה, מלבד הדרישה שהוא לא יכול להיות null או המחרוזת הריקה ("").
SECURITY_PATCH	ערך שמציין את רמת תיקון האבטחה של גרסה זמינה ל-build. חובה לציין שה-build לא חשוף בשום צורה לאף אחת מהבעיות המתוארות בעדכון האבטחה הציבורי הייעודי של Android. התאריך חייב להיות בפורמט [YYYY-MM-DD] ולהתאים למחרוזת מוגדרת שמפורטת בעדכון האבטחה הציבורי של Android או בעדכון האבטחה של Android, לדוגמה '2015-11-01'.
BASE_OS	ערך שמייצג את הפרמטר FINGERPRINT של ה-build, שהוא זהה ל-build הזה מלבד התיקונים שסופקו בעדכון האבטחה הציבורי של Android. חובה לדווח על הערך הנכון, ואם לא קיים build כזה, צריך לדווח על מחרוזת ריקה ("").
BOOTLOADER	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את גרסת האתחול הפנימית הספציפית שמשמשת במכשיר, בפורמט שקריא לבני אדם. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי ‎“^[a-zA-Z0-9._-]+$‎”.
getRadioVersion()	הערך חייב להיות (או להחזיר) ערך שנבחר על ידי מי שמטמיע את המכשיר, שמזהה את גרסת הרדיו/המודם הפנימית הספציפית שמשמשת במכשיר, בפורמט שקריא לבני אדם. אם למכשיר אין רדיו/מודם פנימיים, חובה להחזיר את הערך NULL. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי ‎“^[a-zA-Z0-9._-,]+$”.

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

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

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

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

  • שעון שולחני
  • דפדפן
  • יומן
  • אנשי הקשר
  • גלריה
  • GlobalSearch
  • מרכז האפליקציות
  • מוזיקה
  • הגדרות

3.2.3.2. פתרון של כוונה

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

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

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

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

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

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

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

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

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

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

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

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

3.2.3.5. הגדרות ברירת המחדל של האפליקציות

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

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

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

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

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

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

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

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

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

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

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

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

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. תאימות ל-API מקורי

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

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

3.3.1. ממשקי Application Binary Interface

קוד בייט מטופל של Dalvik יכול להפעיל קוד מקומי שסופק בקובץ .apk של האפליקציה כקובץ ELF .so שעבר הידור לארכיטקטורת החומרה המתאימה של המכשיר. מאחר שקוד מקורי תלוי מאוד בטכנולוגיית המעבד הבסיסית, מערכת 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) המקורי שנתמך במכשיר, באמצעות הפרמטרים android.os.Build.SUPPORTED_ABIS,‏ android.os.Build.SUPPORTED_32_BIT_ABIS ו-android.os.Build.SUPPORTED_64_BIT_ABIS. כל אחד מהפרמטרים הוא רשימה מופרדת בפסיקים של ממשקי ABI, שממוינים מהמועדף ביותר לפחות מועדף.
• [C-0-6] חובה לדווח, באמצעות הפרמטרים שלמעלה, רק על ממשקי ABI שמתועדים ומתווארים בגרסה האחרונה של מסמכי התיעוד של Android NDK ABI Management, וחובה לכלול תמיכה בתוסף Advanced SIMD (נקרא גם NEON).

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

  • libaaudio.so (תמיכה באודיו מקורי של AAudio)
  • libandroid.so (תמיכה בפעילות Native ב-Android)
  • libc (ספריית C)
  • libcamera2ndk.so
  • libdl (מקשר דינמי)
  • libEGL.so‏ (ניהול פלטפורמה מקורי של OpenGL)
  • libGLESv1_CM.so‏ (OpenGL ES 1.x)
  • libGLESv2.so‏ (OpenGL ES 2.0)
  • libGLESv3.so‏ (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (רישום ביומן ב-Android)
  • libmediandk.so (תמיכה בממשקי API מקומיים של מדיה)
  • libm (ספריית מתמטיקה)
  • 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] חובה לציין ב-/vendor/etc/public.libraries.txt רשימה של ספריות נוספות שאינן AOSP שחשופות ישירות לאפליקציות של צד שלישי.
• [C-0-10] אסור לחשוף אפליקציות צד שלישי שמטרגטות רמת API 24 ואילך לספריות מקוריות אחרות, שהוגדרו וסופק ב-AOSP כספריות מערכת, כי הן שמורות.
• [C-0-11] חובה לייצא את כל סמלי הפונקציות של OpenGL ES 3.1 ו-Android Extension Pack, כפי שמוגדרים ב-NDK, דרך הספרייה libGLESv3.so. שימו לב: חובה לכלול את כל הסמלים, אבל בקטע 7.1.4.1 מתוארות בפירוט רב יותר הדרישות לגבי המועד שבו צפויה ההטמעה המלאה של כל אחת מהפונקציות התואמות.
• [C-0-12] חובה לייצא סמלי פונקציות של סמלי הליבה של פונקציות Vulkan 1.0, וגם של התוספים VK_KHR_surface,‏ VK_KHR_android_surface,‏ VK_KHR_swapchain,‏ VK_KHR_maintenance1 ו-VK_KHR_get_physical_device_properties2 דרך הספרייה libvulkan.so. שימו לב: חובה לכלול את כל הסמלים, אבל בקטע 7.1.4.2 מתוארות בפירוט רב יותר הדרישות לגבי המועד שבו צפויה ההטמעה המלאה של כל אחת מהפונקציות התואמות.
• צריך לבנות אותו באמצעות קוד המקור וקבצי הכותרת שזמינים ב-Android Open Source Project

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

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

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

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

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

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

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

  • Features:, ואחריה רשימה של תכונות אופציונליות של מעבד 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 בקוד המקור בענף Android 8.0, לצורך הטמעת ה-API של android.webkit.WebView.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כלומר:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.3. התראות

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

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

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

• [C-1-1] חובה לתמוך בהתראות שמשתמשות בתכונות חומרה, כפי שמתואר במסמכי התיעוד של ה-SDK, ובמידת האפשר עם חומרת הטמעת המכשיר. לדוגמה, אם הטמעת המכשיר כוללת ויברטור, חובה לטמיע כראוי את ממשקי ה-API של הרטט. אם בהטמעה של מכשיר חסר חומרה, חובה להטמיע את ממשקי ה-API התואמים כ-no-ops. ההתנהגות הזו מפורטת בהרחבה בקטע 7.
• [C-1-2] חובה להציג בצורה נכונה את כל המשאבים (סמלים, קובצי אנימציה וכו') שסופקו בממשקי ה-API, או במדריך הסגנון של הסמלים בסרגל הסטטוס או בסרגל המערכת, למרות שיכול להיות שהם יספקו חוויית משתמש חלופית להתראות מזו שסופקה בהטמעת העזר של Android Open Source.
• [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] חובה להשתמש בתצוגה ובמשאבים של ההתראות המפורטות כפי שמתואר בכיתה של ה-API Notification.Builder כשמוצגות התראות מפורטות.

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

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

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

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

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

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

3.8.3.3. 'נא לא להפריע'

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

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

3.8.4. חיפוש

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

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

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

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

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

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

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

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

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

3.8.5. התראות והודעות קצרות

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

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

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

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

3.8.6. עיצובים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.8. מעבר בין פעילויות

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

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

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

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

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

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

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. שומרי מסך (לשעבר 'חלומות')

ב-Android יש תמיכה בשומרי מסך אינטראקטיביים, שנקראים בעבר 'חלומות'. שומרי מסך מאפשרים למשתמשים לקיים אינטראקציה עם אפליקציות כשמכשיר שמחובר למקור חשמל נמצא במצב מנוחה או מונח במעמד. אפשר להטמיע שומר מסך במכשירי Android Watch, אבל סוגים אחרים של הטמעות במכשירים אמורים לכלול תמיכה בשומרי מסך ולספק למשתמשים אפשרות להגדיר שומר מסך בתגובה לכוונה 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, ‏ sans-serif-light, ‏ sans-serif-medium, ‏ sans-serif-black, ‏ sans-serif-condensed, ‏ sans-serif-condensed-light – בשפות הזמינות במכשיר.
  • כיסוי מלא של Unicode 7.0 של שפות לטינית, יוונית וקירילית, כולל הטווחים A,‏ B,‏ C ו-D של לטינית מורחבת וכל הגליפים בבלוק של סמלי המטבעות ב-Unicode 7.0.
• צריכה לתמוך בגווני העור ובאמוג'י של משפחות מגוונות כפי שמפורט בדוח הטכני מס' 51 של Unicode.

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

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

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

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

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

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

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

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

• [C-3-1] חובה להפעיל פעילויות במצב 'תמונה בתוך תמונה' עם כמה חלונות כשהאפליקציה: * מטרגטת לרמת API 26 ומעלה ומצהירה על android:supportsPictureInPicture * מטרגטת לרמת API 25 ומטה ומצהירה גם על android:resizeableActivity וגם על android:supportsPictureInPicture.
• [C-3-2] חובה לחשוף את הפעולות ב-SystemUI שלהן, כפי שמצוין בפעילות ה-PIP הנוכחית, דרך ה-API של setActions().
• [C-3-3] חובה לתמוך ביחסי גובה-רוחב שגדולים מ-1:2.39 או שווים לו, וקטנים מ-2.39:1 או שווים לו, כפי שצוין בפעילות ה-PIP דרך ה-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 הקצאת מכשיר (Provisioning)

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

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

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

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

• [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] חובה לספק את האפשרויות הבאות למשתמש בהגדרות כדי לציין למשתמש מתי פונקציית מערכת מסוימת הושבתה על ידי ה-Device Policy Controller‏ (DPC):

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

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

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

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

3.10. נגישות

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

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

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

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

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

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

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

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

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

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

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

3.12. TV Input Framework

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

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

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

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

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

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

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

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

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

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

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

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

3.12.1.2. ניווט

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

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

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

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

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

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

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

3.12.1.4. שינוי מועד השידור

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

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

3.12.1.5. הקלטת טלוויזיה

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

• [SR] STRONGLY RECOMMENDED to support TV recording.
• צריך לספק ממשק משתמש להפעלת תוכניות שהוקלטו.
• אם הקלט של הטלוויזיה תומך בהקלטה והקלטת תוכנית לא אסורה, יכול להיות שה-EPG יספק דרך להקליט תוכנית.

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

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

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

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

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

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

• [C-1-1] חובה להציג סמלי MediaItem וסמלי התראות ללא שינוי.
• [C-1-2] חובה להציג את הפריטים האלה כפי שמתואר ב-MediaSession, למשל: מטא-נתונים, סמלים, תמונות.
• [C-1-3] חובה להציג את שם האפליקציה.
• [C-1-4] חובה לכלול מגירה להצגת היררכיית MediaBrowser.

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

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

• [C-0-5] חובה שתהיה פעילות שמטפלת ב-Intent‏ android.settings.MANAGE_UNKNOWN_APP_SOURCES.

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

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

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

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

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

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

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

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

כל הקודקים שמפורטים בקטע שבהמשך מוצעים כהטמעות תוכנה בהטמעת Android המועדפת מ-Android Open Source Project.

לתשומת ליבך: 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 Profile‏ (AAC LC)
• [C-1-2] MPEG-4 HE AAC Profile‏ (AAC+)
• [C-1-3] פרופיל MPEG-4 HE AACv2‏ (enhanced AAC+)
• [C-1-4] AAC ELD‏ (AAC משופר עם זמן השהיה קצר)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE
• [C-1-10] Opus

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

• [C-2-1] חובה לבצע את פענוח הנתונים ללא ערבוב למטה (למשל, חובה לבצע פענוח של שידור AAC 5.0 לחמישה ערוצים של 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‏ (AAC+)	תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם תדירויות דגימה רגילות של 16 עד 48kHz.
פרופיל MPEG-4 HE AACv2 (enhanced AAC+)	תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם תדירויות דגימה רגילות של 16 עד 48kHz.
AAC ELD (AAC משופר עם זמן אחזור נמוך)	תמיכה בתוכן מונו/סטריאו עם תדירויות דגימה רגילות של 16 עד 48kHz.
AMR-NB	4.75 עד 12.2kbps דגימה ב-8kHz	3GPP‏ (‎.3gp)
AMR-WB	9 שיעורי דגימה מ-6.60kbit/s עד 23.85kbit/s, בתדירות דגימה של 16kHz
FLAC	מונו/סטריאו (ללא ערוצים מרובים). תדירויות דגימה של עד 48kHz (אבל מומלץ להשתמש בתדירויות של עד 44.1kHz במכשירים עם פלט של 44.1kHz, כי המכשיר להקטנת תדירות הדגימה מ-48kHz ל-44.1kHz לא כולל מסנן מסנן תדר נמוך). מומלץ 16 ביט. לא חל רעש דיגיטלי (dither) על 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)
Vorbis		Ogg‏ (‎.ogg) Matroska‏ (‎.mkv, Android 4.0 ואילך)
PCM/WAVE	PCM לינאריים של 16 ביט (שיעורים עד למגבלת החומרה). המכשירים חייבים לתמוך בתדירויות דגימה של הקלטת PCM גולמי בתדרים של 8000,‏ 11025,‏ 16000 ו-44100Hz.	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	Base+progressive	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] קודיקי וידאו חייבים לתמוך בגדלים של מאגרי בייטים של פלט וקלט שיכולים להכיל את התמונה הגדולה ביותר שניתן לדחוס ולא לדחוס, בהתאם לסטנדרט ולתצורה, אבל גם לא להקצות יותר מדי.

• [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	WebM‏ (‎.webm) Matroska‏ (‎.mkv)
VP9	פרטים נוספים זמינים בקטע 5.3	WebM‏ (‎.webm) Matroska‏ (‎.mkv)

5.2. קידוד וידאו

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

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

5.2.2. H-264

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

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

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

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

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

5.2.3. VP8

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

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

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

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

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p	HD 1080p
רזולוציית וידאו	320 x 180 פיקסלים	640 x 360 פיקסלים	‎1280 x 720 פיקסלים	‎1,920 x 1,080 פיקסלים
קצב מסגרות של סרטון	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] חובה לתמוך בפרופיל Baseline ברמה 30 וברמה 45.

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

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

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

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

5.3.5. H.265 (‏HEVC)

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

• [C-1-1] חובה לתמוך ברמה הראשית של פרופיל Main ברמה 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 פיקסלים	‎1280 x 720 פיקסלים	‎1,920 x 1,080 פיקסלים	3840 x 2160 פיקסלים
קצב מסגרות של סרטון	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30 פריימים לשנייה (FPS)	30/60‎ FPS (60‎ FPSטלוויזיה עם פענוח חומרה של H.265)	60 fps
קצב העברת נתונים של וידאו	600 Kbps	1.6 Mbps	4Mbps	‎5 Mbps	‎20 Mbps

5.3.6. VP8

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

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

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

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

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

5.3.7. VP9

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

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

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

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

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

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

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

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

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

5.4.1. הקלטת אודיו בפורמט RAW

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

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

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

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

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

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

  • פורמט: PCM לינארי, 16 ביט
  • תדירות דגימה: 22050, ‏ 48000Hz
  • ערוצים: סטריאו

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

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

5.4.2. הקלטה לצורך זיהוי קולי

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

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

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

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

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

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

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

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

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

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

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

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

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

5.6. זמן אחזור אודיו (audio latency)

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

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

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

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

• [SR] זמן אחזור של 100 אלפיות השנייה או פחות בפלט קר
• [SR] זמן אחזור רציף של פלט של 45 אלפיות השנייה או פחות
• [SR] Minimize the cold output jitter

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

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

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

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

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

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

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

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

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

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

• [C-1-2] חובה לתמוך בפורמטים של קטעי המדיה שמפורטים בטבלה 'פורמטים של קטעי מדיה' שבהמשך, באמצעות טיוטת פרוטוקול HTTP Live Streaming, גרסה 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 עם מסגרת ADTS ותגי ID3	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-generic	RFC 3640	פרטים על AAC ועל הווריאציות שלו מופיעים בקטע 5.1.1.
MP2T	RFC 2250	פרטים נוספים זמינים בקטע MPEG-2 Transport Stream בקטע 'סטרימינג בשידור חי ב-HTTP'.

5.8. Secure Media

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

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

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

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

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

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

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

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

• [SR] מומלץ מאוד לדווח על תמיכה בתכונה android.software.midi באמצעות הכיתה android.content.pm.PackageManager.

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

• מצב מארח USB (קטע 7.7 USB)
• מצב ציוד היקפי בחיבור USB (קטע 7.7 USB)
• MIDI ב-Bluetooth LE בתפקיד מרכזי (קטע 7.4.3 Bluetooth)

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

• [C-1-1] אסור לדווח על תמיכה בתכונה android.software.midi.

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

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

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

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

• [SR] מומלץ מאוד לדווח על תמיכה בתכונה android.hardware.audio.pro באמצעות הכיתה android.content.pm.PackageManager.

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

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

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

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

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

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

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

• [C-4-1] חובה להטמיע את מחלקת האודיו של USB.

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

• [C-5-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 מ-5Hz עד 100Hz בהשוואה לטווח התדרים הבינוני בכל מיקרופון שמשמש להקלטת מקור האודיו הלא מעובד.

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

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

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

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

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

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

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

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

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

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

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

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

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

• ממשק הגישור של Android‏ (adb)

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

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

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

• Dalvik Debug Monitor Service‏ (ddms)

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

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

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

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

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

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

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

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

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

• [C-0-2] עדיין צריך להציג הגדרות מלאות של כיתות (כפי שמפורט ב-SDK) לממשקי ה-API של הרכיבים.
• [C-0-3] חובה להטמיע את ההתנהגויות של ה-API כ-no-ops באופן סביר כלשהו.
• [C-0-4] שיטות API חייבות להחזיר ערכי null במקרים שבהם מותר לעשות זאת לפי מסמכי התיעוד של ה-SDK.
• [C-0-5] שיטות API חייבות להחזיר הטמעות של no-op של כיתות שבהן ערכים null אסורים לפי מסמכי ה-SDK.
• [C-0-6] אסור לשיטות API להוציא חריגות שלא מתועדות במסמכי התיעוד של ה-SDK.
• [C-0-7] הטמעות של מכשירים חייבות לדווח באופן עקבי על פרטי הגדרת חומרה מדויקים באמצעות השיטות getSystemAvailableFeatures() ו-hasSystemFeature(String) בכיתה android.content.pm.PackageManager לאותו טביעת אצבע של build.

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

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

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

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

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

7.1.1. הגדרת מסך

7.1.1.1. גודל מסך

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

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

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

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

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 ‏24 ואילך, והיא לא מצהירה על 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)
  • 160dpi‏ (mdpi)
  • 213dpi‏ (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)
  • 480dpi‏ (xxhdpi)
  • 560 dpi (560dpi)
  • 640dpi‏ (xxxhdpi)

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

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

• [C-1-1] אסור לשנות את גודל התצוגה לגודל גדול יותר מפי 1.5 מהצפיפות המקורית, או ליצור מימד מסך מינימלי יעיל קטן מ-320dp (שווה ערך למאפיין המשאב sw320dp), לפי המוקדם מביניהם.
• [C-1-2] אסור לשנות את גודל התצוגה לגודל קטן יותר מ-0.85 פי הצפיפות המקורית.
• כדי להבטיח נוחות שימוש וגדלים עקביים של גופנים, מומלץ לספק את האפשרויות הבאות של שינוי קנה המידה של תצוגה מקורית (תוך ציות למגבלות שצוינו למעלה)
• קטן: 0.85x
• ברירת מחדל: 1x (קנה מידה של תצוגה מקורית)
• גדולה: 1.15x
• גדול יותר: 1.3x
• הגדול ביותר 1.45x

7.1.2. מדדי רשת המדיה

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

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

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

• [C-2-1] חובה לדווח על ערכים סבירים לכל מדדי התצוגה שהוגדרו ב-API של android.util.DisplayMetrics עבור view.Display ברירת המחדל המאומלל.

7.1.3. כיוון מסך

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

• [C-0-1] חובה לדווח על כיווני המסך הנתמכים (android.hardware.screen.portrait ו/או android.hardware.screen.landscape) ועל כיוון אחד לפחות שנתמך. לדוגמה, מכשיר עם מסך אופקי קבוע, כמו טלוויזיה או מחשב נייד, אמור לדווח רק על android.hardware.screen.landscape.
• [C-0-2] חובה לדווח על הערך הנכון של הכיוון הנוכחי של המכשיר בכל פעם שמתבצעת שאילתה דרך android.content.res.Configuration.orientation,‏ android.view.Display.getOrientation() או ממשקי API אחרים.

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

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

7.1.4. האצת גרפיקה 2D ו-3D

7.1.4.1 OpenGL ES

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

• [C-0-1] חובה לזהות בצורה נכונה את הגרסאות הנתמכות של OpenGL ES‏ (1.1,‏ 2.0,‏ 3.0,‏ 3.1,‏ 3.2) באמצעות ממשקי ה-API המנוהלים (למשל, באמצעות השיטה GLES10.getString()) וממשקי ה-API המקומיים.
• [C-0-2] חובה לכלול את התמיכה בכל ממשקי ה-API המנוהלים ובכל ממשקי ה-API הנתמכים המתאימים לכל גרסאות OpenGL ES שזוהו כנתמכות.

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

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

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

• [C-2-1] חובה לדווח באמצעות ממשקי ה-API המנוהלים של OpenGL ES וממשקי ה-API הנתמכים על כל תוסף אחר של OpenGL ES שהוטמע, ולהפך, אסור לדווח על מחרוזות של תוספים שאין תמיכה בהם.
• [C-2-2] חובה לתמוך בתוספים EGL_KHR_image, ‏ EGL_KHR_image_base, ‏ EGL_ANDROID_image_native_buffer, ‏ EGL_ANDROID_get_native_client_buffer, ‏ EGL_KHR_wait_sync, ‏ EGL_KHR_get_all_proc_addresses, ‏ EGL_ANDROID_presentation_time, ‏ EGL_KHR_swap_buffers_with_damage ו-EGL_ANDROID_recordable.
• [SR] מומלץ מאוד לתמוך ב-EGL_KHR_partial_update.
• עליהם לדווח בצורה מדויקת באמצעות השיטה getString() על כל פורמט דחיסת טקסטורה שהם תומכים בו, בדרך כלל פורמט ספציפי לספק.

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

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

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

• [C-4-1] חובה לתמוך בחבילת התוספים של OpenGL ES ל-Android במלואה.

אם הטמעות המכשירים תומכות ב-Android Extension Pack של 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] אסור להצהיר על אף אחד מתגי ה-feature flag של 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 האצת גרפיקה 2D

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

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

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

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

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

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

7.1.4.5 מסכים עם מגוון רחב של צבעים

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

• [C-1-1] חובה שיהיה מסך עם כיול צבע.
• [C-1-2] חובה שיהיה מסך שסולם הצבעים שלו מכסה את סולם הצבעים sRGB במלואו במרחב CIE 1931 xyY.
• [C-1-3] חייב להיות מסך ששטח המגוון שלו הוא לפחות 90% מ-NTSC 1953 במרחב xyY של CIE 1931.
• [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. התקני קלט

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

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

7.2.1. מקלדת

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

• [C-1-1] חובה להצהיר על דגל התכונה android.software.input_methods.
• [C-1-2] חובה להטמיע באופן מלא את Input Management Framework
• [C-1-3] חובה שתהיה מקלדת תוכנה טעונה מראש.

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

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

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

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

• [C-0-1] חובה לדווח על הערך הנכון של android.content.res.Configuration.navigation.

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

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

7.2.3. מקשי ניווט

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

• [C-0-1] חובה לספק את פונקציית הבית.
• צריך לספק לחצנים לפונקציות 'פריטים אחרונים' ו'חזרה'.

אם הפונקציות 'דף הבית', 'פריטים אחרונים' או 'חזרה' זמינות, הן:

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

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

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

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

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

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

אם הטמעות במכשירים מספקות את פונקציית Assistant, הן: [C-4-1] חייבות לאפשר גישה לפונקציית Assistant באמצעות פעולה אחת (למשל הקשה, לחיצה כפולה או תנועה) כשיש גישה למקשות ניווט אחרים. [SR] STRONGLY RECOMMENDED to use long press on HOME function as this designated interaction.

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

• [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 בשדה ה-API Configuration.touchscreen.
• [C-1-2] חובה לדווח על דגלי התכונות android.hardware.touchscreen ו-android.hardware.faketouch

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

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

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

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

7.2.5. קלט מגע מזויף

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

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

• צריך להצהיר על תמיכה ב-feature flag‏ android.hardware.faketouch.

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

• [C-1-1] חובה לדווח על המיקומים המוחלטים X ו-Y במסך של מיקום הסמן ולהציג סמן חזותי במסך.
• [C-1-2] חובה לדווח על אירוע מגע עם קוד הפעולה שמציין את שינוי המצב שמתרחש בסמן כשהוא יורד או עולה במסך.
• [C-1-3] חובה לתמוך בהזזת הסמן למטה ולמעלה על אובייקט במסך, כדי לאפשר למשתמשים לדמות הקשה על אובייקט במסך.
• [C-1-4] חובה לתמוך בתנועות של הצבעה למטה, הצבעה למעלה, הצבעה למטה ואז הצבעה למעלה באותו מקום על אובייקט במסך, בתוך ערך סף זמן, כדי לאפשר למשתמשים לזייף הקשה כפולה על אובייקט במסך.
• [C-1-5] חובה לתמוך בתנועת הסמן למטה בנקודה שרירותית במסך, בתנועת הסמן לכל נקודה שרירותית אחרת במסך, ולאחר מכן בתנועת הסמן למעלה, כדי לאפשר למשתמשים לדמות גרירה במגע.
• [C-1-6] חובה לתמוך בתנועת הסמן למטה, ולאחר מכן לאפשר למשתמשים להזיז במהירות את האובייקט למיקום אחר במסך, ואז להזיז את הסמן למעלה במסך, כדי לאפשר למשתמשים להעיף אובייקט במסך.
• [C-1-7] חובה לדווח על TOUCHSCREEN_NOTOUCH בשדה ה-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 במקור כוללת הטמעה של בקרי משחקים שעומדים בדרישות האלה.

לחצן	שימוש ב-HID2	Android Button
A1	0x09 0x0001	KEYCODE_BUTTON_A‏ (96)
B1	0x09 0x0002	KEYCODE_BUTTON_B‏ (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X‏ (99)
Y1	0x09 0x0005	KEYCODE_BUTTON_Y‏ (100)
לוח החיוג למעלה1 לוח החיוג למטה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)
לחיצה על מקש ה-D-Pad הימני1	0x09 0x000F	KEYCODE_BUTTON_THUMBR‏ (107)
דף הבית1	0x0c 0x0223	KEYCODE_HOME‏ (3)
הקודם1	0x0c 0x0224	KEYCODE_BACK‏ (4)

1 KeyEvent

2 יש להצהיר על שימושי ה-HID שלמעלה בתוך אישור CA של משחקייה (0x01 0x0005).

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

4 MotionEvent

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

אירוע MotionEvent אחד

7.2.7. שלט רחוק

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

7.3. חיישנים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.3.1. מד תאוצה

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

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

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

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

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

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

• [C-1-1] חובה להטמיע את החיישן TYPE_MAGNETIC_FIELD.
• [C-1-2] חייב להיות מסוגל לדווח על אירועים בתדירות של 10Hz לפחות, ומומלץ לדווח על אירועים בתדירות של 50Hz לפחות.
• [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] חובה לתמוך בניפוי ובתיקון אונליין של הטיה חזקה (hard iron bias), ולשמור את פרמטרי התיקון בין הפעלות מחדש של המכשיר.
• [C-1-8] חובה להחיל את הפיצוי של ברזל רך – אפשר לבצע את ההתאמה בזמן השימוש או במהלך ייצור המכשיר.
• [C-1-9] סטיית התקן, המחושבת על בסיס ציר לכל מדגם שנאסף במשך תקופה של 3 שניות לפחות בקצב הדגימה המהיר ביותר, חייבת להיות לא יותר מ-1.5 מיקרו-טסלה. מומלץ שסטיית התקן תהיה לא יותר מ-0.5 מיקרו-טסלה.
• צריך להטמיע חיישן 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] צריך להיות צריכת אנרגיה של פחות מ-10mW.
• צריכת האנרגיה אמורה להיות פחות מ-3mW כשהחיישן רשום למצב באצ'ט ב-10Hz.

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

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

  • [C-1-3] חובה שאפשר יהיה לקבוע את המיקום בטווח של 20 מטר ואת המהירות בטווח של 0.5 מטר לשנייה, לפחות ב-95% מהמקרים.
  • [C-1-4] חובה לעקוב בו-זמנית אחרי לפחות 8 לוויינים מקבוצת לוויינים אחת ולדווח עליהם באמצעות GnssStatus.Callback.
  • צריכה להיות אפשרות לעקוב בו-זמנית אחרי לפחות 24 לוויינים, מכמה קבוצות של כוכבים (למשל, GPS + לפחות אחד מ-Glonass,‏ Beidou,‏ Galileo).
  • [C-1-5] חובה לדווח על הדור של טכנולוגיית ה-GNSS דרך ממשק ה-API לבדיקה 'getGnssYearOfHardware'.
  • [SR] המשך העברת נתוני מיקום רגילים של GPS/GNSS במהלך שיחת טלפון למקרה חירום.
  • [SR] דיווח על מדידות GNSS מכל מערכות הניווט שמבוצע מעקב אחריהן (כפי שמדווח בהודעות GnssStatus), מלבד SBAS.
  • [SR] Report AGC, and Frequency of GNSS measurement.
  • [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, וממשק ה-API לבדיקה LocationManager.getGnssYearOfHardware() מדווח על שנת 2017 ואילך, הן:

• [C-3-1] חובה להמשיך לספק פלט נתוני מיקום רגילים של GPS/GNSS במהלך שיחת חירום בטלפון.
• [C-3-2] חובה לדווח על מדידות GNSS מכל המערכות שבמעקב (כפי שמדווח בהודעות GnssStatus), מלבד SBAS.
• [C-3-3] חובה לדווח על AGC ועל תדירות המדידה של GNSS.
• [C-3-4] חובה לדווח על כל אומדני הדיוק (כולל כיוון, מהירות ונתונים אנכיים) כחלק מכל מיקום GPS.

7.3.4. ג'ירוסקופ

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

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

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

• [C-1-1] חייב להיות מסוגל לדווח על אירועים בתדירות של לפחות 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 לכל הרץ (הפרש לכל הרץ, או rad^2 / s). ניתן לשנות את השונות בהתאם לשיעור הדגימה, אבל היא חייבת להיות מוגבלת בערך הזה. במילים אחרות, אם מודדים את השונות של הגירוסקופ בקצב דגימה של 1Hz, היא לא אמורה להיות גבוהה מ-1e-7 rad^2/s^2.
• [SR] מומלץ מאוד להטמיע את החיישן SENSOR_TYPE_GYROSCOPE_UNCALIBRATED במכשירי Android קיימים וחדשים.
• [SR] מומלץ מאוד שהשגיאה בכיול תהיה פחות מ-0.01 rad/s כשהמכשיר נייח בטמפרטורת החדר.
• צריך לדווח על אירועים עד 200Hz לפחות.

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

• [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. מדחום

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

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

• [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 הרץ ומעלה.
  • רעש המדידה חייב להיות לא יותר מ-400 uG/√Hz.
  • חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון זמני של לפחות 3,000 אירועי חיישן.
  • צריכת החשמל של האצווה חייבת להיות לא יותר מ-3mW.
  • צריכה להיות יציבות של הטיה סטטית של רעש של פחות מ-15 μg √Hz ממערך נתונים סטטי של 24 שעות.
  • השינוי בסטייה לעומת הטמפרטורה צריך להיות ≤ +/- 1mg / °C.
  • יש להיות לקו ההתאמה הטובה ביותר סטייה לא לינארית של ≤ 0.5%, ושינויים ברגישות לעומת הטמפרטורה של ≤ 0.03%/°C.
  • צריך להיות ספקטרום של רעש לבן כדי להבטיח הסמכה מתאימה של תקינות הרעש במדד.

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

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

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

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

• [C-2-5] חייב להיות חיישן TYPE_GEOMAGNETIC_FIELD ש:
  • טווח המדידה חייב להיות לפחות בין -900 ל-900 uT.
  • חייבת להיות רזולוציית מדידה של לפחות 5 LSB/uT.
  • תדר המדידה המינימלי חייב להיות 5Hz או פחות.
  • תדירות המדידה המקסימלית חייבת להיות 50 הרץ ומעלה.
  • רעש המדידה חייב להיות לא יותר מ-0.5 uT.
• [C-2-6] חייב להיות TYPE_MAGNETIC_FIELD_UNCALIBRATED עם אותן דרישות איכות כמו TYPE_GEOMAGNETIC_FIELD, ובנוסף:
  • חובה להטמיע את החיישן הזה בצורה ללא התעוררות עם יכולת אחסון נתונים זמניים של לפחות 600 אירועי חיישן.
  • צריך להיות ספקטרום של רעש לבן כדי להבטיח הסמכה מתאימה של תקינות הרעש במדד.
• [C-2-7] חייב להיות חיישן TYPE_PRESSURE ש:
  • חייב להיות טווח מדידה של לפחות 300 עד 1,100 hPa.
  • חייבת להיות רזולוציית מדידה של לפחות 80 LSB/hPa.
  • תדר המדידה המינימלי חייב להיות 1Hz או פחות.
  • תדירות המדידה המקסימלית חייבת להיות 10 הרץ ומעלה.
  • רעש המדידה חייב להיות קטן מ-2 Pa/√Hz.
  • חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון זמני של לפחות 300 אירועי חיישן.
  • צריכת החשמל של האצווה חייבת להיות לא יותר מ-2mW.
• [C-2-8] חייב להיות חיישן TYPE_GAME_ROTATION_VECTOR ש:
  • חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון זמני של לפחות 300 אירועי חיישן.
  • צריכת החשמל של האצווה חייבת להיות לא יותר מ-4mW.
• [C-2-9] חייב להיות חיישן TYPE_SIGNIFICANT_MOTION ש:
  • צריכת האנרגיה חייבת להיות לא יותר מ-0.5mW כשהמכשיר נייח ו-1.5mW כשהמכשיר בתנועה.
• [C-2-10] חייב להיות חיישן TYPE_STEP_DETECTOR ש:
  • חובה להטמיע את החיישן הזה בצורה שלא מעוררת אותו, עם יכולת אחסון זמני של לפחות 100 אירועי חיישן.
  • צריכת האנרגיה חייבת להיות לא יותר מ-0.5mW כשהמכשיר נייח ו-1.5mW כשהמכשיר בתנועה.
  • צריכת החשמל של האצווה חייבת להיות לא יותר מ-4mW.
• [C-2-11] חייב להיות חיישן TYPE_STEP_COUNTER ש:
  • צריכת האנרגיה חייבת להיות לא יותר מ-0.5mW כשהמכשיר נייח ו-1.5mW כשהמכשיר בתנועה.
• [C-2-12] חייב להיות חיישן TILT_DETECTOR ש:
  • צריכת האנרגיה חייבת להיות לא יותר מ-0.5mW כשהמכשיר נייח ו-1.5mW כשהמכשיר בתנועה.
• [C-2-13] חותמת הזמן של האירוע של אותו אירוע פיזי שדווח על ידי חיישן ה-Accelerometer, חיישן ה-Gyroscope וחיישן המגנטומטר חייבת להיות בטווח של 2.5 אלפיות השנייה זה מזה.
• [C-2-14] חובה שתהיה חותמת זמן לאירועים של חיישן הג'ירוסקופ באותה בסיס זמן כמו למערכת המשנית של המצלמה, ובטווח שגיאה של מיליסיקון אחד.
• [C-2-15] חובה לספק דגימות לאפליקציות תוך 5 אלפיות השנייה מרגע שהנתונים זמינים באפליקציה דרך אחד מהחיישנים הפיזיים שלמעלה.
• [C-2-16] צריך להיות צריכת אנרגיה של פחות מ-0.5mW כשהמכשיר נייח ו-2.0mW כשהמכשיר בתנועה, כשכל שילוב של החיישנים הבאים מופעל:
  • 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%.
• [C-1-4] חובה להגביל את קצב הניסיונות למשך 30 שניות לפחות אחרי 5 ניסיונות כושלים לאימות באמצעות טביעת אצבע.
• [C-1-5] חובה להטמיע מאגר מפתחות שמבוסס על חומרה, ולבצע את ההתאמה של טביעות האצבע בסביבת מחשוב אמינה (TEE) או בשבב עם ערוץ מאובטח ל-TEE.
• [C-1-6] חובה להצפין את כל נתוני טביעת האצבע המזהים ולבצע להם אימות קריפטוגרפי, כך שלא ניתן יהיה לקבל אותם, לקרוא או לשנות אותם מחוץ לסביבת המחשוב המאובטחת (TEE), כפי שמתואר בהנחיות להטמעה באתר של Android Open Source Project.
• [C-1-7] חובה למנוע הוספה של טביעת אצבע בלי ליצור קודם שרשרת אמון, על ידי כך שהמשתמש יאשר פרטי כניסה קיימים או יוסיף פרטי כניסה חדשים למכשיר (מספר PIN/דפוס/סיסמה) שמאובטחים על ידי TEE. ההטמעה של Android Open Source Project מספקת את המנגנון במסגרת כדי לעשות זאת.
• [C-1-8] אסור לאפשר לאפליקציות צד שלישי להבדיל בין טביעות אצבע ספציפיות.
• [C-1-9] חובה לכבד את הדגל DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
• [C-1-10] כשמתבצעת שדרוג מגרסה ישנה יותר מ-Android 6.0, חובה להעביר את נתוני טביעת האצבע באופן מאובטח כדי לעמוד בדרישות שלמעלה, או להסיר אותם.
• [SR] מומלץ מאוד שהשיעור של דחייה שגויה יהיה פחות מ-10%, כפי שנמדד במכשיר.
• [SR] מומלץ מאוד שהזמן להצגת התוצאה יהיה פחות משנייה, נמדד מהרגע שבו נוגעים בחיישן טביעות האצבע ועד שהמסך נפתח, לאצבע אחת שרשומה.
• צריך להשתמש בסמל טביעת האצבע של Android שזמין בפרויקט הקוד הפתוח של Android.

7.3.11. חיישנים ל-Android Automotive בלבד

חיישנים ספציפיים לכלי רכב מוגדרים ב-android.car.CarSensorManager API.

7.3.11.1. הילוך נוכחי

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

7.3.11.2. מצב יום/לילה

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

7.3.11.3. סטטוס הנהיגה

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

7.3.11.4. מהירות הגלגלים

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

7.3.12. חיישן תנוחה

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

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

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

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

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

7.4.1. טלפוניה

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

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

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

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

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

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

7.4.1.1. תאימות לחסימת מספרים

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

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

7.4.2. IEEE 802.11‏ (Wi-Fi)

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

• צריכה לכלול תמיכה באחד או יותר מהטפסים של 802.11.

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

• [C-1-1] חובה להטמיע את ממשק ה-API התואם של Android.
• [C-1-2] חובה לדווח על הדגל של תכונת החומרה android.hardware.wifi.
• [C-1-3] חובה להטמיע את multicast API כפי שמתואר במסמכי התיעוד של ה-SDK.
• [C-1-4] חובה לתמוך ב-DNS של קבוצות מרובות (mDNS) ואסור לסנן חבילות mDNS (224.0.0.251) בכל שלב של הפעולה, כולל:
  • גם כשהמסך לא במצב פעיל.
  • להטמעות של מכשירי Android Television, גם במצבי המתנה.
• צריך לגרום לכך שכתובת ה-MAC של המקור ומספר הרצף של פריים הבקשה לבדיקה יהיו אקראיים, פעם אחת בתחילת כל סריקה, בזמן ש-STA מנותק.
  • בכל קבוצה של מסגרות של בקשות לבדיקה שמרכיבות סריקת רשת אחת, צריך להשתמש בכתובת MAC עקבית אחת (אסור לבחור כתובת MAC באופן אקראי באמצע הסריקה).
  • מספר הרצף של בקשת הבדיקה צריך לעבור חזרה כמו רגיל (באופן רציף) בין בקשות הבדיקה בסריקת
  • מספר הרצף של בקשת הבדיקה צריך להיות אקראי בין בקשת הבדיקה האחרונה של הסריקה לבין בקשת הבדיקה הראשונה של הסריקה הבאה
• כשה-STA מנותק, צריך לאפשר רק את רכיבי המידע הבאים בפריימים של בקשות בדיקה:
  • קבוצת פרמטרים של SSID (0)
  • קבוצת פרמטרים של DS (3)

7.4.2.1. Wi-Fi ישיר

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

• צריכה לכלול תמיכה ב-Wi-Fi Direct (Wi-Fi peer-to-peer).

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

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

7.4.2.2. הגדרת קישור ישיר ב-Wi-Fi דרך מנהרה

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

• צריכה לכלול תמיכה ב-Wi-Fi Tunneled Direct Link Setup ‏ (TDLS) כפי שמתואר במסמכי התיעוד של Android SDK.

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

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

7.4.2.3. Wi-Fi Aware

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

• צריכה לכלול תמיכה ב-Wi-Fi Aware.

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

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

7.4.2.4. Wi-Fi Passpoint

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

• צריכה לכלול תמיכה ב-Wi-Fi Passpoint.

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

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

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

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

7.4.3. Bluetooth

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

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

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

• [C-1-1] חובה לתמוך ב-Bluetooth 4.2 וב-Bluetooth LE Data Length Extension.

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

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

• [C-2-1] חובה להצהיר על תכונות הפלטפורמה הרלוונטיות (android.hardware.bluetooth ו-android.hardware.bluetooth_le בהתאמה) ולהטמיע את ממשקי ה-API של הפלטפורמה.
• צריך להטמיע פרופילים רלוונטיים של Bluetooth, כמו A2DP,‏ AVCP,‏ OBEX וכו', בהתאם למכשיר.

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

• [C-3-1] חובה להצהיר על תכונת החומרה android.hardware.bluetooth_le.
• [C-3-2] חובה להפעיל את ממשקי ה-API של Bluetooth המבוססים על GATT (פרופיל מאפיינים גנרי) כפי שמתואר במסמכי התיעוד של ה-SDK וב-android.bluetooth.
• [C-3-3] חובה לדווח על הערך הנכון של BluetoothAdapter.isOffloadedFilteringSupported() כדי לציין אם לוגיקה הסינון של כיתות ה-API ScanFilter מוטמעת.
• [C-3-4] חובה לדווח על הערך הנכון של BluetoothAdapter.isMultipleAdvertisementSupported() כדי לציין אם יש תמיכה בפרסום באנרגיה נמוכה.
• צריך לתמוך בהעברת הלוגיקה של הסינון לערכת השבבים של Bluetooth כשמטמיעים את ScanFilter API.
• צריכה להיות תמיכה בהעברת הסריקה האצווה לצ'יפסט של ה-Bluetooth.

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

• [SR] מומלץ מאוד להטמיע זמן קצוב לתפוגה של כתובת פרטית שניתן לפתור (RPA) שלא יהיה ארוך מ-15 דקות ולבצע רוטציה של הכתובת בתום הזמן הקצוב לתפוגה כדי להגן על פרטיות המשתמשים.

7.4.4. תקשורת מטווח קצר

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

• צריך לכלול משדר-מקלט וחומרה קשורה לתקשורת מטווח קצר (NFC).
• [C-0-1] חובה להטמיע ממשקי API של android.nfc.NdefMessage ו-android.nfc.NdefRecord גם אם הם לא כוללים תמיכה ב-NFC או מכריזים על התכונה android.hardware.nfc, כי הכיתות מייצגות פורמט של ייצוג נתונים שלא תלוי בפרוטוקול.

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

• [C-1-1] חובה לדווח על התכונה android.hardware.nfc מהשיטה android.content.pm.PackageManager.hasSystemFeature().
• חייבת להיות לה אפשרות לקרוא ולכתוב הודעות NDEF באמצעות תקני ה-NFC הבאים, כפי שמפורט בהמשך:
• [C-1-2] חייב להיות מסוגל לפעול כקורא/כותב של NFC Forum (כפי שמוגדר במפרט הטכני של NFC Forum,‏ NFCForum-TS-DigitalProtocol-1.0) באמצעות תקני ה-NFC הבאים:
  • NfcA‏ (ISO14443-3A)
  • NfcB‏ (ISO14443-3B)
  • NfcF‏ (JIS X 6319-4)
  • IsoDep‏ (ISO 14443-4)
  • סוגי תגים של NFC Forum‏ 1, 2, 3, 4, 5 (מוגדרים על ידי NFC Forum)

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

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

  • ISO 18092
  • LLCP 1.2 (הוגדר על ידי NFC Forum)
  • SDP 1.0 (הוגדר על ידי NFC Forum)
  • פרוטוקול NDEF Push
  • SNEP 1.0 (הוגדר על ידי NFC Forum)
• [C-1-4] חובה לכלול תמיכה ב-Android Beam, ורצוי להפעיל את Android Beam כברירת מחדל.
• [C-1-5] חייב להיות אפשרות לשלוח ולקבל באמצעות Android Beam, כש-Android Beam מופעל או כשמצב P2P אחר של NFC ייחודי מופעל.
• [C-1-6] חובה להטמיע את שרת ברירת המחדל של SNEP. הודעות NDEF תקינות שהתקבלו על ידי שרת SNEP שמוגדר כברירת מחדל חייבות להישלח לאפליקציות באמצעות הכוונה android.nfc.ACTION_NDEF_DISCOVERED. השבתת Android Beam בהגדרות לא מורשית להשבית את השליחה של הודעת NDEF נכנסת.
• [C-1-7] חובה לפעול בהתאם לכוונה של android.settings.NFCSHARING_SETTINGS להציג את הגדרות השיתוף ב-NFC.
• [C-1-8] חובה להטמיע את שרת ה-NPP. הודעות שמתקבלות בשרת ה-NPP חייבות לעבור עיבוד באותו אופן שבו הן עוברות עיבוד בשרת ברירת המחדל של SNEP.
• [C-1-9] חובה להטמיע לקוח SNEP ולנסות לשלוח הודעות NDEF יוצאות מסוג P2P לשרת SNEP שמוגדר כברירת מחדל כש-Android Beam מופעל. אם לא נמצא שרת SNEP שמוגדר כברירת מחדל, הלקוח חייב לנסות לשלוח לשרת NPP.
• [C-1-10] חובה לאפשר לפעילויות בחזית להגדיר את הודעת ה-NDEF היוצאת מסוג P2P באמצעות android.nfc.NfcAdapter.setNdefPushMessage, ו-android.nfc.NfcAdapter.setNdefPushMessageCallback ו-android.nfc.NfcAdapter.enableForegroundNdefPush.
• צריך להשתמש בתנועה או באישור במסך, כמו 'מצמידים כדי להעביר', לפני שליחת הודעות NDEF יוצאות מסוג P2P.
• [C-1-11] חובה לתמוך בהעברת חיבור NFC ל-Bluetooth כשהמכשיר תומך בפרופיל Bluetooth Object Push.
• [C-1-12] חובה לתמוך בהעברת חיבור ל-Bluetooth כשמשתמשים ב-android.nfc.NfcAdapter.setBeamPushUris, על ידי הטמעת המפרטים Connection Handover version 1.2 ו-Bluetooth Secure Simple Pairing Using NFC version 1.0 מ-NFC Forum. בהטמעה כזו חובה להטמיע את שירות ה-LLCP להעברה עם שם השירות 'urn:nfc:sn:handover' לצורך החלפת הבקשה להעברה או בחירת הרשומות דרך NFC, וחובה להשתמש בפרופיל Bluetooth Object Push להעברת הנתונים בפועל ב-Bluetooth. מטעמי תאימות לעבר (כדי לשמור על תאימות למכשירי Android 4.1), ההטמעה עדיין אמורה לקבל בקשות SNEP GET להחלפת בקשת ההעברה או רשומות נבחרות דרך NFC. עם זאת, לא מומלץ שההטמעה עצמה תשלח בקשות SNEP GET כדי לבצע העברת חיבור.
• [C-1-13] חובה לבצע סקירה של כל הטכנולוגיות הנתמכות במצב גילוי NFC.
• צריך להיות במצב חשיפת NFC כשהמכשיר פעיל, המסך פעיל ומסך הנעילה פתוח.
• אמורה להיות מסוגלת לקרוא את הברקוד ואת כתובת ה-URL (אם היא מקודדת) של מוצרים עם ברקוד NFC דק.

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

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

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

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

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

• [C-3-1] חובה לדווח על קבוע התכונה android.hardware.nfc.hcef.
• [C-3-2] חובה להטמיע את ממשקי ה-API של NfcF Card Emulation כפי שהם מוגדרים ב-Android SDK.

אם הטמעות המכשיר כוללות תמיכה כללית ב-NFC כפי שמתואר בקטע הזה ותמיכה בטכנולוגיות MIFARE‏ (MIFARE Classic, ‏ MIFARE Ultralight, ‏ NDEF ב-MIFARE Classic) בתפקיד הקורא/הסופר, הן:

• [C-4-1] חובה להטמיע את ממשקי ה-API התואמים של Android כפי שמתואר ב-Android SDK.
• [C-4-2] חובה לדווח על התכונה com.nxp.mifare מהשיטה android.content.pm.PackageManager.hasSystemFeature(). חשוב לזכור שזו לא תכונה רגילה של Android, ולכן היא לא מופיעה כקבועה בכיתה android.content.pm.PackageManager.

7.4.5. יכולת רשת מינימלית

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

• [C-0-1] חובה לכלול תמיכה באחת או יותר מהצורות של רשתות נתונים. באופן ספציפי, הטמעות במכשירים חייבות לכלול תמיכה בתקן נתונים אחד לפחות עם קצב העברה של 200Kbit/sec או יותר. דוגמאות לטכנולוגיות שעומדות בדרישות האלה כוללות את EDGE,‏ HSPA,‏ EV-DO,‏ 802.11g,‏ Ethernet,‏ Bluetooth PAN וכו'.
• [C-0-2] חובה לכלול סטאק של רשתות IPv6 ולתמוך בתקשורת IPv6 באמצעות ממשקי ה-API המנוהלים, כמו java.net.Socket ו-java.net.URLConnection, וגם באמצעות ממשקי ה-API המקומיים, כמו שקעים של AF_INET6.
• [C-0-3] חובה להפעיל את IPv6 כברירת מחדל.
• חובה לוודא שתקשורת IPv6 אמינה כמו IPv4, לדוגמה.
• [C-0-4] חובה לשמור על קישוריות IPv6 במצב שינה.
• [C-0-5] הגבלת הקצב לא מורשית לגרום לאובדן הקישוריות של המכשיר ל-IPv6 בכל רשת שתואמת ל-IPv6 ומשתמשת בטווח חיים של RA של לפחות 180 שניות.
• צריך לכלול גם תמיכה בתקן אחד לפחות של נתונים אלחוטיים נפוצים, כמו 802.11‏ (Wi-Fi), כשתקן פיזי של רשתות (כמו אתרנט) הוא חיבור הנתונים הראשי
• יכולים להטמיע יותר מסוג אחד של קישוריות נתונים.

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

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

• [C-1-1] חובה לתמוך ב-dual-stack ובפעולה ב-IPv6 בלבד ב-Wi-Fi.

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

• [C-2-1] חובה לתמוך בתפעול של שתי שכבות (dual-stack) ב-Ethernet.

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

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

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

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

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

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

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

• [SR] מומלץ מאוד לספק את מצב חיסכון בחבילת הגלישה.

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

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

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

• [C-2-1] חובה להחזיר את הערך RESTRICT_BACKGROUND_STATUS_DISABLED עבור ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] אסור לשדר ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
• [C-2-3] חייבת להיות פעילות שמטפלת ב-Intent‏ Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, אבל אפשר להטמיע אותה כפעולה ללא תוצאה (no-op).

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-4] התצוגה המקדימה של המצלמה חייבת להיות מוחזרת (mirrored) אופקית ביחס לכיוון שצוין על ידי האפליקציה, אם האפליקציה הנוכחית ביקשה במפורש שמסך המצלמה יתהפך באמצעות קריאה לשיטה android.hardware.Camera.setDisplayOrientation(). לעומת זאת, אם האפליקציה הנוכחית לא מבקשת במפורש לסובב את המסך של המצלמה באמצעות קריאה לשיטה android.hardware.Camera.setDisplayOrientation(), התצוגה המקדימה חייבת להיות מוחזרת על ציר אופקי ברירת המחדל של המכשיר.
• [C-1-5] אסור לשקף את התמונות הסטטיות או את הסטרימינג של הסרטונים הסופיים שצולמו, שמוחזרים להודעות החזרה (callbacks) של האפליקציה או מועברים לאחסון מדיה.
• [C-1-6] חובה לשקף את התמונה שמוצגת על ידי התצוגה המקדימה באותו אופן שבו מוצג זרם התמונות של תצוגה המקדימה במצלמה.
• יכולות לכלול תכונות (כמו פוקוס אוטומטי, פלאש וכו') שזמינות למצלמות הפונות לאחור, כפי שמתואר בקטע 7.5.1.

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

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

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

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

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

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

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

אם יש תמיכה בקידוד וידאו מבוסס-מצלמה:

• [C-2-1] חובה שאפשר יהיה לגשת להזרמה בו-זמנית ללא קידוד או MJPEG (רזולוציה QVGA או יותר) להטמעה במכשיר.

7.5.4. התנהגות Camera API

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

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

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

• [C-0-1] חובה להשתמש ב-android.hardware.PixelFormat.YCbCr_420_SP לנתוני תצוגה מקדימה שסופקו לקריאות חוזרות (callbacks) של אפליקציות, כשאפליקציה אף פעם לא התקשרה ל-android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] בנוסף, הנתונים חייבים להיות בפורמט הקידוד NV21 כשאפליקציה רושמת מופע android.hardware.Camera.PreviewCallback והמערכת קוראת לשיטה onPreviewFrame() ופורמט התצוגה המקדימה הוא YCbCr_420_SP, הנתונים ב-byte[] מועברים אל 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.
• [C-0-5] עדיין חובה להטמיע את Camera API המלא שכלול במסמכי התיעוד של Android SDK, גם אם המכשיר כולל פוקוס אוטומטי בחומרה או יכולות אחרות. לדוגמה, מצלמות ללא פוקוס אוטומטי עדיין חייבות לקרוא לכל המופעים הרשומים של android.hardware.Camera.AutoFocusCallback (למרות שאין לכך רלוונטיות למצלמה ללא פוקוס אוטומטי). שימו לב שההנחה הזו רלוונטית גם למצלמות קדמיות. לדוגמה, למרות שרוב המצלמות הקדמיות לא תומכות בפוקוס אוטומטי, עדיין צריך 'לזייף' את קריאות החזרה (callbacks) של ה-API כפי שמתואר.
• [C-0-6] חובה לזהות כל שם פרמטר שמוגדר כקבוע במחלקה android.hardware.Camera.Parameters ולכבד אותו. לעומת זאת, בהטמעות של מכשירים אסור להכיר או לכבד קבועות מחרוזת שמועברות לשיטה android.hardware.Camera.setParameters(), מלבד אלה שתועדו כקבועות ב-android.hardware.Camera.Parameters. כלומר, הטמעות של מכשירים חייבות לתמוך בכל הפרמטרים הרגילים של המצלמה, אם החומרה מאפשרת זאת, ואסור להן לתמוך בסוגי פרמטרים מותאמים אישית של מצלמה. לדוגמה, הטמעות של מכשירים שתומכות בצילומי תמונות באמצעות שיטות צילום עם טווח דינמי גבוה (HDR) חייבות לתמוך בפרמטר המצלמה Camera.SCENE_MODE_HDR.
• [C-0-7] חובה לדווח על רמת התמיכה המתאימה באמצעות המאפיין android.info.supportedHardwareLevel כפי שמתואר ב-Android SDK, ולדווח על דגלים מתאימים של תכונות מסגרת.
• [C-0-8] חובה גם להצהיר על יכולות המצלמה הנפרדות של android.hardware.camera2 באמצעות המאפיין android.request.availableCapabilities ולהצהיר על דגלים מתאימים של תכונות. חובה להגדיר את דגל התכונה אם אחד ממכשירי המצלמה המצורפים תומך בתכונה.
• [C-0-9] חובה לשדר את הכוונה Camera.ACTION_NEW_PICTURE בכל פעם שצולמת תמונה חדשה במצלמה והרשומה של התמונה נוספה למאגר המדיה.
• [C-0-10] חובה לשדר את הכוונה Camera.ACTION_NEW_VIDEO בכל פעם שמצלמים סרטון חדש במצלמה והתמונה נוספה למאגר המדיה.

7.5.5. כיוון המצלמה

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

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

7.6. זיכרון ואחסון

7.6.1. נפח זיכרון ואחסון מינימלי

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

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

7.6.2. אחסון משותף של אפליקציות

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

• [C-0-1] חובה להציע אחסון שאפשר לשתף עם אפליקציות. האחסון הזה נקרא גם 'אחסון חיצוני משותף', 'אחסון משותף של אפליקציות' או לפי הנתיב ב-Linux '‎/sdcard' שאליו הוא מחובר.
• [C-0-2] חובה להגדיר אחסון משותף שמחובר כברירת מחדל, כלומר "מחוץ לקופסה", ללא קשר לאופן שבו האחסון מיושם – ברכיב אחסון פנימי או באמצעי אחסון נשלף (למשל, חריץ לכרטיס Secure Digital).
• [C-0-3] חובה לחבר את האחסון המשותף של האפליקציה ישירות לנתיב Linux‏ sdcard או לכלול קישור סימבולי של Linux מ-sdcard לנקודת הטעינה בפועל.
• [C-0-4] חובה לאכוף את ההרשאה android.permission.WRITE_EXTERNAL_STORAGE באחסון השיתופי הזה, כפי שמתואר ב-SDK. אחרת, כל אפליקציה שמקבלת את ההרשאה הזו חייבת להיות מסוגלת לכתוב באחסון המשותף.

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

• אחסון נשלף שזמין למשתמש, כמו חריץ לכרטיס Secure Digital‏ (SD).
• חלק מהאחסון הפנימי (לא ניתן להסרה) כפי שהוא מיושם בפרויקט הקוד הפתוח של Android‏ (AOSP).

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

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

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

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

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

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

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

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

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

• צריכה להיות תאימות למארח ה-MTP של Android לדוגמה, Android File Transfer.
• צריך לדווח על סוג מכשיר USB של 0x00.
• צריך לדווח על שם ממשק USB של 'MTP'.

7.6.3. אחסון שניתן להתאמה

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

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

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

• [SR] מומלץ מאוד להטמיע אחסון שניתן להתאמה.

7.7. USB

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

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

7.7.1. מצב ציוד היקפי ב-USB

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

• [C-1-1] חובה שאפשר יהיה לחבר את היציאה למארח USB עם יציאת USB רגילה מסוג A או מסוג C.
• [C-1-2] חובה לדווח על הערך הנכון של iSerialNumber בתיאור המכשיר הסטנדרטי של USB דרך android.os.Build.SERIAL.
• [C-1-3] חובה לזהות מטענים של 1.5A ו-3.0A בהתאם לתקן הנגדים של Type-C, וחובה לזהות שינויים במודעה אם הם תומכים ב-USB Type-C.
• [SR] The port SHOULD use micro-B, micro-AB or Type-C USB form factor. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה.
• [SR] היציאה אמורה להיות ממוקמת בחלק התחתון של המכשיר (בהתאם לכיוון הטבעי) או להפעיל סיבוב מסך בתוכנה לכל האפליקציות (כולל מסך הבית), כדי שהמסך יוצג בצורה נכונה כשהמכשיר מונח כך שהיציאה נמצאת בתחתית. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה כדי שיוכלו לשדרג לגרסאות עתידיות של הפלטפורמה.
• [SR] צריך להטמיע תמיכה בזרם של 1.5A במהלך תנועה וצפצוף HS, כפי שמפורט במפרט טעינה של סוללות USB, גרסה 1.2. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה כדי שיוכלו לשדרג לגרסאות העתידיות של הפלטפורמה.
• [SR] מומלץ מאוד לא לתמוך בשיטות טעינה קנייניות שמשנה את מתח Vbus מעבר לרמות ברירת המחדל, או לשנות את התפקידים של מקור או נקודת קליטה, כי הן עלולות לגרום לבעיות בתאימות עם מטענים או מכשירים שתומכים בשיטות הסטנדרטיות של העברת חשמל ב-USB. אמנם ההמלצה היא 'מומלץ מאוד', אבל בגרסאות עתידיות של Android יכול להיות שנחייב את כל המכשירים עם חיבור Type-C לתמוך בתאימות מלאה עם מטענים רגילים עם חיבור Type-C.
• [SR] מומלץ מאוד לתמוך ב-Power Delivery להחלפת תפקידים של נתונים וחשמל כשיש תמיכה ב-USB Type-C ובמצב מארח USB.
• צריכה להיות תמיכה ב-Power Delivery לטעינה במתח גבוה ותמיכה במצבים חלופיים כמו Display Out.
• צריך להטמיע את המפרט ואת ממשק ה-API של Android Open Accessory‏ (AOA) כפי שמתואר במסמכי התיעוד של Android SDK.

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

• [C-2-1] חובה להצהיר על תמיכה בתכונה החומרה android.hardware.usb.accessory.
• [C-2-2] הכיתה של אחסון בנפח גדול ב-USB חייבת לכלול את המחרוזת 'android' בסוף המחרוזת iInterface של תיאור הממשק של אחסון בנפח גדול ב-USB

7.7.2. מצב מארח USB

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

• [C-1-1] חובה להטמיע את Android USB host API כפי שמתואר ב-Android SDK, וצריך להצהיר על תמיכה בתכונה החומרה android.hardware.usb.host.
• [C-1-2] חובה להטמיע תמיכה לחיבור ציוד היקפי סטנדרטי מסוג USB. במילים אחרות, חובה:
  • יש יציאת Type-C במכשיר או שסופקו כבלים שמתאימים יציאה קניינית במכשיר ליציאת USB Type-C רגילה (מכשיר USB Type-C).
  • יש יציאת USB מסוג A במכשיר או שצריך לשלוח כבל שמתאים יציאה קניינית במכשיר ליציאת USB רגילה מסוג A.
  • יש יציאת micro-AB במכשיר, שאמורה להגיע עם כבל עם מתאם ליציאת Type-A רגילה.
• [C-1-3] אסור לשלוח את המכשיר עם מתאם שממיר מיציאות USB מסוג A או מיציאות micro-AB ליציאת Type-C (שקע).
• [SR] STRONGLY RECOMMENDED to implement the USB audio class as documented in the Android SDK documentation.
• צריך לתמוך בטעינה של ציוד היקפי USB מחובר במצב מארח, לפרסם זרם מקור של לפחות 1.5A כפי שמפורט בקטע 'פרמטרים של סיום' במפרט של כבל USB Type-C ומחבר USB Type-C, גרסה 1.2 למחברים מסוג USB Type-C, או להשתמש בטווח זרם הפלט של יציאת טעינה במורד הזרם(CDP) כפי שמפורט במפרטים של טעינה של סוללות USB, גרסה 1.2 למחברים מסוג Micro-AB.
• צריך להטמיע ולתמוך בתקני USB Type-C.

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

• [C-2-1] חובה לתמוך בממשק ה-HID של USB.
• [C-2-2] חובה לתמוך בזיהוי ובמיפוי של שדות הנתונים הבאים של HID שצוינו בטבלאות השימוש של USB HID ובבקשת השימוש בפקודות קוליות, אל הקבועים KeyEvent כפי שמפורט בהמשך:
  • דף שימוש (0xC) מזהה שימוש (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • דף שימוש (0xC) מזהה שימוש (0x0E9): KEYCODE_VOLUME_UP
  • דף שימוש (0xC) מזהה שימוש (0x0EA): KEYCODE_VOLUME_DOWN
  • דף שימוש (0xC) מזהה שימוש (0x0CF): KEYCODE_VOICE_ASSIST

אם הטמעות המכשיר כוללות יציאת USB שתומכת במצב מארח וב-Storage Access Framework‏ (SAF), הן:

• [C-3-1] חובה לזהות כל מכשיר MTP (פרוטוקול העברת מדיה) שמחובר מרחוק ולאפשר גישה לתוכן שלו באמצעות האינטים ACTION_GET_CONTENT,‏ ACTION_OPEN_DOCUMENT ו-ACTION_CREATE_DOCUMENT. .

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

• [C-4-1] חובה להטמיע את הפונקציונליות של יציאה עם תפקיד כפול כפי שהוגדר במפרט USB Type-C (קטע 4.5.1.3.3).
• [SR] מומלץ מאוד לתמוך ב-DisplayPort, צריכה להיות תמיכה בקצבי העברת נתונים של USB SuperSpeed, ומומלץ מאוד לתמוך ב-Power Delivery להחלפת תפקידים של נתונים וחשמל.
• [SR] מומלץ מאוד לא לתמוך במצב 'אביזרי מתאם אודיו' כפי שמתואר בנספח א' של מפרט הכבל והמחבר מסוג USB-C, גרסה 1.2.
• צריך להטמיע את המודל Try.* שמתאים ביותר לגורם הצורה של המכשיר. לדוגמה, במכשיר נייד צריך להטמיע את המודל Try.SNK.

7.8. אודיו

7.8.1. מיקרופון

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

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

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

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

7.8.2. יעד השמע

אם הטמעות של מכשירים כוללות רמקול או יציאת אודיו/מדיה למכשיר היקפי של פלט אודיו, כמו שקע אודיו 3.5 מ"מ עם 4 מוליכים או יציאה במצב מארח USB באמצעות USB audio class, הן:

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

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

• [C-2-1] אסור לדווח על התכונה android.hardware.audio output.
• [C-2-2] חובה להטמיע את ממשקי ה-API שקשורים לפלט האודיו לפחות כ-no-ops.

לצורכי הקטע הזה, 'יציאת פלט' היא ממשק פיזי, כמו שקע אודיו בגודל 3.5 מ"מ, HDMI או יציאת USB במצב מארח עם אודיו מסוג USB. תמיכה בפלט אודיו באמצעות פרוטוקולים מבוססי-רדיו כמו Bluetooth,‏ Wi-Fi או רשת סלולרית לא נחשבת ככוללת 'יציאת פלט'.

7.8.2.1. יציאות אודיו אנלוגיות

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

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

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

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

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

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

אודיו קרוב לאולטרה-סאונד הוא התדר 18.5kHz עד 20kHz.

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

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

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

• [C-1-1] תגובת הכוח הממוצעת של המיקרופון בתחום התדרים 18.5kHz עד 20kHz חייבת להיות נמוכה ב-15dB לכל היותר מהתגובה בתדר 2kHz.
• [C-1-2] יחס האות לרעש ללא משקל של המיקרופון בטווח של 18.5kHz עד 20kHz עבור צליל של 19kHz ב-26dBFS חייב להיות לפחות 50dB.

אם הערך של PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND הוא 'true':

• [C-2-1] התגובה הממוצעת של הרמקול בתחום התדרים 18.5kHz עד 20kHz חייבת להיות גבוהה מ-40dB מתחת לתגובה בתדר 2kHz.

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 עם שני הקשרי רינדור, בלי שיהיו בו שיבושים גלויים של קריעה.
• [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.
• [C-1-9] חובה להטמיע תמיכה בדגלים AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER ו-AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA של AHardwareBuffer כפי שמתואר ב-NDK.
• [C-1-10] חובה להטמיע תמיכה ב-AHardwareBuffers עם יותר משכבה אחת.
• [C-1-11] חובה לתמוך בפענוח H.264 של לפחות 3840x2160@30fps-40Mbps (שווה ערך ל-4 מופעים של 1920x1080@30fps-10Mbps או ל-2 מופעים של 1920x1080@60fps-20Mbps).
• [C-1-12] חובה לתמוך ב-HEVC וב-VP9, חובה להיות מסוגלים לפענח לפחות 1920x1080@30fps-10Mbps וצריך להיות מסוגלים לפענח 3840x2160@30fps-20Mbps (שווה ערך ל-4 מופעים של 1920x1080@30fps-5Mbps).
• [C-1-13] חובה לתמוך ב-API של HardwarePropertiesManager.getDeviceTemperatures ולהחזיר ערכים מדויקים של טמפרטורת העור.
• [C-1-14] חייב להיות מסך מוטמע, ורזולוציית המסך חייבת להיות לפחות FullHD‏(1080p). מומלץ מאוד שהרזולוציה תהיה QuadHD‏ (1440p) ומעלה.
• [C-1-15] התצוגה חייבת להתעדכן במהירות של לפחות 60 הרץ במצב VR.
• [C-1-16] זמן האחזור של המסך במעבר מאפור לאפור, מלבן לשחור ומשחור ללבן חייב להיות ≤ 3 אלפיות השנייה.
• [C-1-17] המסך חייב לתמוך במצב עמידות נמוכה עם עמידות של 5 אלפיות שנייה לכל היותר. העמידות מוגדרת כמשך הזמן שבו פיקסל פולט אור.
• [C-1-18] חובה לתמוך ב-Bluetooth 4.2 וב-Bluetooth LE Data Length Extension קטע 7.4.3.
• [SR] מומלץ מאוד לתמוך בתכונה android.hardware.sensor.hifi_sensors, וחובה לעמוד בדרישות שקשורות לג'ירוסקופ, למד התאוצה ולמגנטומטר עבור android.hardware.hifi_sensors.
• יכול לספק ליבה בלעדית לאפליקציה בחזית, ויכול לתמוך ב-API ‏Process.getExclusiveCores כדי להחזיר את המספרים של ליבות המעבד שהן בלעדיות לאפליקציה העליונה בחזית.

אם יש תמיכה בליבה בלעדית, הליבה:

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

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

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

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

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

8.2. ביצועי הגישה של File I/O

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

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

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

מערכת Android כוללת את המצבים 'המתנה לאפליקציות' ו-Doze לחיסכון באנרגיה, כדי לבצע אופטימיזציה של השימוש בסוללה. [SR] All Apps exempted from these modes are STRONGLY RECOMMENDED to be made visible to the end user. [SR] מומלץ מאוד לא לסטות מפרויקט Android Open Source לגבי הטריגרים, התחזוק, אלגוריתמי ההפעלה והשימוש בהגדרות המערכת הגלובליות של מצבי החיסכון האלה באנרגיה.

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

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

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

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

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

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

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

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

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

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

• [C-0-1] חובה לדווח בצורה מדויקת על התמיכה במצב 'ביצועים יציבים' באמצעות שיטת ה-API PowerManager.isSustainedPerformanceModeSupported().

• צריכה להיות תמיכה במצב 'ביצועים יציבים'.

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

• [C-1-1] חובה לספק לאפליקציה העיקרית שבחזית רמת ביצועים עקבית למשך 30 דקות לפחות, כשהאפליקציה מבקשת זאת.
• [C-1-2] חובה לפעול בהתאם לממשק ה-API של Window.setSustainedPerformanceMode() ולממשקי API קשורים אחרים.

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

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

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

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

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

• [C-3-1] חובה להחזיר רשימה ריקה באמצעות שיטת ה-API Process.getExclusiveCores().

9. תאימות של מודל האבטחה

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

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

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

9.1. הרשאות

הטמעות במכשירים:

• [C-0-1] חובה לתמוך במודל ההרשאות של Android כפי שמוגדר במסמכי התיעוד למפתחים של Android. באופן ספציפי, חובה לאכוף כל הרשאה שמוגדרת כפי שמתואר במסמכי ה-SDK. אסור להשמיט, לשנות או להתעלם מהרשאות.

• מותר להוסיף הרשאות נוספות, בתנאי שמחרוזות מזהי ההרשאות החדשות לא נמצאות במרחב השמות android.\*.

• [C-0-2] חובה להעניק הרשאות עם protectionLevel של PROTECTION_FLAG_PRIVILEGED רק לאפליקציות שהועמסו מראש בנתיבים המורשים של קובץ האימג' של המערכת, ובמסגרת קבוצת המשנה של ההרשאות שמופיעות במפורש ברשימת ההיתרים של כל אפליקציה. ההטמעה של AOSP עומדת בדרישות האלה על ידי קריאה של ההרשאות שמופיעות ברשימת ההיתרים של כל אפליקציה מהקבצים שבנתיב etc/permissions/ וביצוע שלהן, ושימוש בנתיב system/priv-app כנתיב המורשה.

הרשאות עם רמת הגנה מסוכנת הן הרשאות בזמן ריצה. אפליקציות עם targetSdkVersion > 22 מבקשות אותן בסביבת זמן הריצה.

הטמעות במכשירים:

• [C-0-3] חובה להציג ממשק ייעודי למשתמש כדי שהוא יוכל להחליט אם להעניק את הרשאות זמן הריצה המבוקשות, וגם לספק ממשק למשתמש לניהול הרשאות זמן הריצה.
• [C-0-4] חובה שתהיה הטמעה אחת בלבד של שני ממשקי המשתמש.
• [C-0-5] אסור להעניק הרשאות זמן ריצה לאפליקציות שהותקנו מראש, אלא אם:
• ניתן לקבל את הסכמת המשתמש לפני שהאפליקציה משתמשת בה
• ההרשאות בסביבת זמן הריצה משויכות לדפוס כוונה (intent) שבו האפליקציה שמותקנת מראש מוגדרת כ-handler שמוגדר כברירת מחדל

אם הטמעות במכשירים כוללות אפליקציה שהותקנה מראש, או אם רוצים לאפשר לאפליקציות צד שלישי לגשת לנתוני הסטטיסטיקה של השימוש, צריך:

• [SR] מומלץ מאוד לספק מנגנון שגלוי למשתמשים כדי להעניק או לבטל גישה לנתונים הסטטיסטיים לגבי השימוש בתגובה לכוונה android.settings.ACTION_USAGE_ACCESS_SETTINGS באפליקציות שמצהירות על ההרשאה android.permission.PACKAGE_USAGE_STATS.

אם מטרת הטמעות במכשירים היא לא לאפשר לאף אפליקציה, כולל אפליקציות שמותקנות מראש, לגשת לנתוני סטטיסטיקת השימוש, צריך:

• [C-1-1] עדיין חייבת להיות פעילות שמטפלת בדפוס הכוונה android.settings.ACTION_USAGE_ACCESS_SETTINGS, אבל חובה להטמיע אותה כפעולה ללא תוצאה (no-op), כלומר עם התנהגות זהה לזו שמתרחשת כשהמשתמש נדחה לגישה.

9.2. בידוד של UID ותהליכים

הטמעות במכשירים:

• [C-0-1] חובה לתמוך במודל ארגז החול של אפליקציות Android, שבו כל אפליקציה פועלת כ-UID ייחודי בסגנון Unix ובתהליך נפרד.
• [C-0-2] חובה לתמוך בהרצה של כמה אפליקציות באותו מזהה משתמש ב-Linux, בתנאי שהאפליקציות נוצרו ונחתמו כראוי, כפי שמוגדר בחומר העזר בנושא אבטחה והרשאות.

9.3. הרשאות למערכת הקבצים

הטמעות במכשירים:

• [C-0-1] חובה לתמוך במודל הרשאות הגישה לקבצים של Android כפי שמוגדר בחומר העזר בנושא אבטחה והרשאות.

9.4. סביבות הפעלה חלופיות

הטמעות במכשירים חייבות לשמור על עקביות במודל האבטחה וההרשאות של Android, גם אם הן כוללות סביבות זמן ריצה שמריצות אפליקציות באמצעות תוכנה או טכנולוגיה אחרת מלבד פורמט Dalvik Executable או קוד מקורי. במילים אחרות:

• [C-0-1] סביבות זמן ריצה חלופיות חייבות להיות אפליקציות Android, ולעמוד במודל האבטחה הרגיל של Android, כפי שמתואר במקום אחר בסעיף 9.

• [C-0-2] אסור להעניק לממשקי זמן ריצה חלופיים גישה למשאבים שמוגנים על ידי הרשאות שלא נשלחו בבקשה בקובץ AndroidManifest.xml של סביבת זמן הריצה באמצעות המנגנון <uses-permission>.

• [C-0-3] אסור לסביבות זמן ריצה חלופיות לאפשר לאפליקציות להשתמש בתכונות שמוגנות על ידי הרשאות Android המוגבלות לאפליקציות מערכת.

• [C-0-4] סביבות זמן ריצה חלופיות חייבות לציית למודל ה-sandbox של 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 בתשלום שיוצאת. הודעות Premium SMS הן הודעות טקסט שנשלחות לשירות רשום אצל ספק, שעשויות לגרום לחיוב של המשתמש.

אם הטמעות במכשירים מצהירות על תמיכה ב-android.hardware.telephony, הן:

• [C-1-1] חובה להזהיר את המשתמשים לפני שליחת הודעת SMS למספרים שזוהו באמצעות ביטויים רגולריים שהוגדרו בקובץ /data/misc/sms/codes.xml במכשיר. ב-upstream של פרויקט Android Open Source יש הטמעה שעומדת בדרישות האלה.

9.7. תכונות אבטחה בליבה

ארגז החול של Android כולל תכונות שמשתמשות במערכת אבטחה משופרת ל-Linux‏ (SELinux) עם בקרת גישה (MAC) חובה, ב-seccomp sandboxing ובתכונות אבטחה אחרות בליבה של Linux. הטמעות במכשירים:

• [C-0-1] חובה לשמור על תאימות לאפליקציות קיימות, גם אם SELinux או תכונות אבטחה אחרות מוטמעות מתחת למסגרת Android.
• [C-0-2] אסור שיהיה ממשק משתמש גלוי כשמתגלה הפרת אבטחה ותכונה האבטחה שמיושמת מתחת למסגרת Android חוסמת אותה בהצלחה, אבל יכול להיות שיהיה ממשק משתמש גלוי כשמתרחשת הפרת אבטחה שלא נחסמה וכתוצאה מכך מתרחשת ניצול לרעה.
• [C-0-3] אסור לאפשר למשתמש או למפתח האפליקציה להגדיר את SELinux או תכונות אבטחה אחרות שמיושמות מתחת למסגרת Android.
• [C-0-4] אסור לאפשר לאפליקציה שיכולה להשפיע על אפליקציה אחרת דרך ממשק API (כמו Device Administration API) להגדיר מדיניות שמפרה את התאימות.
• [C-0-5] חובה לפצל את מסגרת המדיה למספר תהליכים כדי שניתן יהיה להעניק גישה מצומצמת יותר לכל תהליך, כפי שמתואר באתר של Android Open Source Project.
• [C-0-6] חובה להטמיע מנגנון של ארגז חול לאפליקציות בליבה שמאפשר סינון של קריאות מערכת באמצעות מדיניות שניתן להגדיר מתוכניות עם מספר רב של שרשורים. הפרויקט של Android Open Source עומד בדרישות האלה על ידי הפעלת seccomp-BPF עם סנכרון של קבוצת חוטים (TSYNC), כפי שמתואר בקטע 'הגדרת הליבה' באתר source.android.com.

תכונות שלמות הליבה והגנה עצמית הן חלק בלתי נפרד מאבטחת Android. הטמעות במכשירים:

• [C-0-7] חובה להטמיע מנגנוני הגנה מפני גלישת חוצץ במחסנית הליבה. דוגמאות למנגנונים כאלה הן CC_STACKPROTECTOR_REGULAR ו-CONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] חובה להטמיע הגנות מחמירות על זיכרון הליבה, שבהן קוד שניתן להרצה הוא לקריאה בלבד, נתונים לקריאה בלבד הם לא ניתנים להרצה ולא ניתנים לכתיבה, ונתונים שניתנים לכתיבה הם לא ניתנים להרצה (למשל CONFIG_DEBUG_RODATA או CONFIG_STRICT_KERNEL_RWX).
• [SR] מומלץ מאוד לשמור על נתוני הליבה שנכתבים רק במהלך האתחול כנתונים שמסומנים לקריאה בלבד אחרי האתחול (למשל __ro_after_init).
• [SR} מומלץ מאוד להטמיע בדיקות של גבולות גודל אובייקטים סטטיים ודינמיים של עותקים בין מרחב המשתמש למרחב הליבה (למשל CONFIG_HARDENED_USERCOPY).
• [SR] מומלץ מאוד לא להריץ אף פעם זיכרון במרחב המשתמש כשמריצים את הליבה (למשל, PXN בחומרה או זיכרון ממולא באמצעות CONFIG_CPU_SW_DOMAIN_PAN או CONFIG_ARM64_SW_TTBR0_PAN).
• [SR] מומלץ מאוד לא לקרוא או לכתוב זיכרון במרחב המשתמש בליבה מחוץ לממשקי ה-API הרגילים של הרשאת הגישה של usercopy (למשל, PAN של חומרה או זיכרון שמומר באמצעות CONFIG_CPU_SW_DOMAIN_PAN או CONFIG_ARM64_SW_TTBR0_PAN).
• [SR] מומלץ מאוד לבצע רנדומיזציה של הפריסה של קוד הליבה והזיכרון, ולהימנע מחשיפות שעלולות לפגוע ברנדומיזציה (למשל, CONFIG_RANDOMIZE_BASE עם אנטרופיה של מנהל האתחול דרך /chosen/kaslr-seed Device Tree node או EFI_RNG_PROTOCOL).

אם הטמעות במכשירים משתמשות בליבה של Linux, הן:

• [C-1-1] חובה להטמיע את SELinux.
• [C-1-2] חובה להגדיר את SELinux למצב אכיפה גלובלי.
• [C-1-3] חובה להגדיר את כל הדומיינים במצב אכיפה. אסור להשתמש בדומיינים במצב הרשאות רחבות, כולל דומיינים ספציפיים למכשיר או לספק.
• [C-1-4] אסור לשנות, להשמיט או להחליף את כללי neverallow שנמצאים בתיקייה system/sepolicy שסופקו ב-upstream של פרויקט הקוד הפתוח של Android‏ (AOSP). בנוסף, המדיניות חייבת לעבור הידור עם כל כללי neverallow הקיימים, גם לדומיינים של AOSP SELinux וגם לדומיינים ספציפיים למכשיר או לספק.
• צריך לשמור על מדיניות ברירת המחדל של SELinux שסופקת בתיקייה system/sepolicy של Android Open Source Project ב-upstream, ולהוסיף למדיניות הזו רק את ההגדרות הספציפיות למכשיר.

אם הטמעות במכשירים משתמשות בליבה שאינה Linux, הן:

• [C-2-1] חובה להשתמש במערכת חובה לבקרת גישה שדומה ל-SELinux.

9.8. פרטיות

9.8.1. היסטוריית השימוש

מערכת Android שומרת את ההיסטוריה של הבחירות של המשתמש ומנהלת את ההיסטוריה הזו באמצעות UsageStatsManager.

הטמעות במכשירים:

• [C-0-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] חובה להתקין מראש את אותם אישורי Root למאגר של רשות האישורים (CA) המהימנה במערכת, כפי שסופקו ב-upstream של פרויקט הקוד הפתוח של Android.
• [C-0-2] חובה לשלוח עם חנות ריקה של רשות אישורים ברמה הבסיסית של משתמש.
• [C-0-3] חובה להציג למשתמש אזהרה על כך שעשויה להתבצע מעקב אחרי תעבורת הרשת, כשמוסיפים רשות אישור ברמה הבסיסית של משתמש.

אם תעבורת הנתונים במכשיר מנותבת דרך VPN, הטמעות במכשירים:

• [C-1-1] חובה להציג למשתמש אזהרה שמציינת את אחד מהפרטים הבאים:
  • יכול להיות שהתנועה ברשת הזו תהיה במעקב.
  • תעבורת הנתונים הזו ברשת מנותבת דרך אפליקציית ה-VPN הספציפית שמספקת את ה-VPN.

אם להטמעות במכשירים יש מנגנון שמופעל כברירת מחדל ומנתב את תעבורת הנתונים ברשת דרך שרת proxy או שער VPN (לדוגמה, טעינת שירות VPN מראש עם הרשאת android.permission.CONTROL_VPN), הן:

• [C-2-1] חובה לבקש את הסכמת המשתמש לפני הפעלת המנגנון הזה, אלא אם ה-VPN מופעל על ידי בקר מדיניות המכשיר דרך DevicePolicyManager.setAlwaysOnVpnPackage(). במקרה כזה , המשתמש לא צריך לספק הסכמה נפרדת, אבל חובה להודיע לו על כך.

9.9. הצפנת אחסון נתונים

אם הטמעות במכשירים תומכות במסך נעילה מאובטח כפי שמתואר בקטע 9.11.1, הן:

• [C-1-1] חובה לתמוך בהצפנת אחסון הנתונים של הנתונים הפרטיים של האפליקציה (/data partition), וגם של מחיצת האחסון המשותף של האפליקציה (/sdcard partition) אם היא חלק קבוע ולא ניתן להסרה מהמכשיר.

אם הטמעות במכשירים תומכות במסך נעילה מאובטח כפי שמתואר בקטע 9.11.1, ותומכות בהצפנת אחסון נתונים עם ביצועי הצפנה של תקן הצפנה מתקדם (AES) מעל 50MiB/sec, הן:

• [C-2-1] חובה להפעיל את ההצפנה של אחסון הנתונים כברירת מחדל ברגע שהמשתמש משלים את חוויית ההגדרה של המכשיר החדש. אם הטמעות של מכשירים כבר הושקו בגרסה קודמת של Android וההצפנה מושבתת כברירת מחדל, מכשיר כזה לא יכול לעמוד בדרישות באמצעות עדכון של תוכנת המערכת, ולכן יכול להיות שהוא יהיה פטור.

• צריך לעמוד בדרישות של הצפנת האחסון של הנתונים שלמעלה באמצעות הטמעה של הצפנה מבוססת-קובץ (FBE).

9.9.1. Direct Boot

הטמעות במכשירים:

• [C-0-1] חובה להטמיע את ממשקי ה-API של מצב הפעלה ישיר גם אם הם לא תומכים בהצפנת אחסון.

• [C-0-2] עדיין צריך לשדר את ה-Intents‏ ACTION_LOCKED_BOOT_COMPLETED ו-ACTION_USER_UNLOCKED כדי לסמן לאפליקציות שתומכות בהפעלה ישירה (Direct Boot) שמיקומי האחסון של נתוני הכניסה המוצפנים (CE) ושל נתוני המכשיר המוצפנים (DE) זמינים למשתמש.

9.9.2. הצפנה מבוססת-קבצים

אם הטמעות במכשירים תומכות ב-FBE, הן:

• [C-1-1] חובה להפעיל את המכשיר בלי לבקש מהמשתמש להזין פרטי כניסה, ולאפשר לאפליקציות שתומכות בהפעלה ישירה לגשת לאחסון של המכשיר המוצפן (DE) אחרי שהודעת ACTION_LOCKED_BOOT_COMPLETED תופץ.
• [C-1-2] חובה לאפשר גישה לאחסון של פרטי הכניסה המוצפנים (CE) רק אחרי שהמשתמש מבטל את הנעילה של המכשיר על ידי מסירת פרטי הכניסה שלו (למשל, קוד גישה, קוד אימות, קו ביטול נעילה או טביעת אצבע) והודעת ACTION_USER_UNLOCKED מועברת.
• [C-1-3] אסור להציע שום שיטה לביטול הנעילה של האחסון המוגן ב-CE בלי פרטי הכניסה שהמשתמש סיפק.
• [C-1-4] חובה לתמוך בהפעלה מאומתת ולוודא שמפתחות DE מקושרים באופן קריפטוגרפית ל-Root of Trust של החומרה של המכשיר.
• [C-1-5] חובה לתמוך בהצפנת תוכן הקבצים באמצעות AES באורך מפתח של 256 ביט במצב XTS.

• [C-1-6] חובה לתמוך בהצפנת שם הקובץ באמצעות AES באורך מפתח של 256 ביט במצב CBC-CTS.

• המפתחות שמגינים על אזורי האחסון של CE ו-DE:

• [C-1-7] חובה לקשר באופן קריפטוגרפי ל-Keystore שמגובל בחומרה.

• [C-1-8] חובה לשייך מפתחות CE לפרטי הכניסה של משתמש במסך הנעילה.
• [C-1-9] חובה לשייך מפתחות CE לקוד גישה שמוגדר כברירת מחדל כשהמשתמש לא ציין פרטי כניסה למסך הנעילה.

• [C-1-10] חייב להיות ייחודי ומובהק, כלומר, מפתח CE או DE של משתמש לא תואם למפתחות CE או DE של משתמש אחר.

• [C-1-11] חובה להשתמש כברירת מחדל בקריפטוטקסטים, באורכי מפתחות ובמצבים הנתמכים באופן מחייב.

• צריך להפוך אפליקציות חיוניות שהוגדרו מראש (למשל: שעון מעורר, טלפון, Messenger) למודעות לטעינה ישירה.

• יכול לתמוך במצפינים חלופיים, באורכי מפתחות ובמצבים להצפנת תוכן הקובץ ושם הקובץ.

בפרויקט Android Open Source ב-upstream יש הטמעה מועדפת של התכונה הזו שמבוססת על תכונת ההצפנה 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 Open Source ב-upstream יש הטמעה מועדפת של התכונה הזו, שמבוססת על התכונה dm-crypt בליבה של Linux.

9.10. תקינות המכשיר

הדרישות הבאות מבטיחות שקיפות לגבי סטטוס תקינות המכשיר. הטמעות במכשירים:

• [C-0-1] חובה לדווח בצורה נכונה באמצעות שיטת System API‏ PersistentDataBlockManager.getFlashLockState() אם מצב האתחול מאפשר את ה-flashing של קובץ האימג' של המערכת. המצב FLASH_LOCK_UNKNOWN שמור להטמעות במכשירים שעברו שדרוג מגרסה קודמת של Android שבה שיטת ה-API החדשה הזו למערכת לא הייתה קיימת.

הפעלה מאומתת היא תכונה שמבטיחה את תקינות התוכנה במכשיר. אם הטמעת המכשיר תומכת בתכונה, היא:

• [C-1-1] חובה להצהיר על ה-feature flag של הפלטפורמה android.software.verified_boot.
• [C-1-2] חובה לבצע אימות בכל רצף הפעלה.
• [C-1-3] חובה להתחיל את האימות ממפתח חומרה בלתי ניתן לשינוי שהוא הבסיס לאמון, ולהמשיך עד למחיצה של המערכת.
• [C-1-4] חובה להטמיע כל שלב של אימות כדי לבדוק את השלמות והאותנטיות של כל הבייטים בשלב הבא לפני שמריצים את הקוד בשלב הבא.
• [C-1-5] חובה להשתמש באלגוריתמי אימות חזקים כמו ההמלצות הנוכחיות של NIST לאלגוריתמי גיבוב (SHA-256) ולגדלים של מפתחות ציבוריים (RSA-2048).
• [C-1-6] אסור לאפשר את השלמת האתחול אם אימות המערכת נכשל, אלא אם המשתמש מסכים לנסות את האתחול בכל מקרה. במקרה כזה, אסור להשתמש בנתונים מכל בלוקים של אחסון שלא אומתו.
• [C-1-7] אסור לאפשר שינוי של מחיצות מאומתות במכשיר, אלא אם המשתמש ביטול את הנעילה של מנהל האתחול באופן מפורש.
• [SR] אם יש במכשיר כמה צ'יפים נפרדים (למשל, רדיו, מעבד תמונות מיוחד), מומלץ מאוד לאמת כל שלב בתהליך האתחול של כל אחד מהצ'יפים האלה.
• [SR] מומלץ מאוד להשתמש באחסון עם תכונה למניעת זיוף: למקרה שהנעילת של מנהל האתחול תבוטל. אחסון עם תכונה של זיהוי פגיעה (tamper-evident) פירושו שהתוכנה להפעלת האתחול יכולה לזהות אם בוצעה פגיעה באחסון מתוך HLOS (מערכת הפעלה ברמה גבוהה).
• [SR] מומלץ מאוד להציג למשתמש הודעה בזמן השימוש במכשיר ולדרוש אישור פיזי לפני שמאפשרים מעבר ממצב נעילה של תוכנת האתחול למצב ביטול הנעילה של תוכנת האתחול.
• [SR] מומלץ מאוד להטמיע הגנה מפני חזרה לאחור ב-HLOS (למשל, אתחול, מחיצות מערכת) ולהשתמש באחסון עם אימות נגד פגיעה כדי לאחסן את המטא-נתונים שמשמשים לקביעת גרסת מערכת ההפעלה המינימלית המותרת.
• צריך להטמיע הגנה מפני חזרה לאחור בכל רכיב עם קושחת קבועה (למשל, מודם, מצלמה) ולהשתמש באחסון עם תכונה של אימות מניעת זיוף (tamper-evident) לאחסון המטא-נתונים שמשמשים לקביעת הגרסה המינימלית המותרת.

ב-upstream של פרויקט הקוד הפתוח של Android יש הטמעה מועדפת של התכונה הזו במאגר external/avb/, שאפשר לשלב בתוכנת האתחול שמשמשת לטעינת Android.

הטמעות במכשירים עם ביצועי הצפנה של Advanced Encryption Standard‏ (AES) מעל 50MB/שנייה:

• [C-2-1] חובה לתמוך בהפעלה מאומתת לצורך בדיקת תקינות המכשיר.

אם הטמעת מכשיר כבר הושקתה בלי תמיכה באתחול מאומת בגרסה קודמת של Android, לא ניתן להוסיף תמיכה בתכונה הזו באמצעות עדכון תוכנת מערכת, ולכן המכשיר הזה פטור מהדרישה.

9.11. מפתחות ופרטי כניסה

מערכת Android Keystore מאפשרת למפתחי אפליקציות לאחסן מפתחות קריפטוגרפיים בקונטיינר ולהשתמש בהם בפעולות קריפטוגרפיות באמצעות KeyChain API או Keystore API. הטמעות במכשירים:

• [C-0-1] חייב לאפשר לייבא לפחות 8,192 מפתחות.
• [C-0-2] באימות של מסך הנעילה חייב להיות הגבלת קצב ניסיונות, וחייבת להיות לו אלגוריתם חזרה איטרטיבית מעריכית. אחרי 150 ניסיונות כושלים, זמן ההשהיה חייב להיות לפחות 24 שעות לכל ניסיון.
• לא צריך להגביל את מספר המפתחות שאפשר ליצור

כשהטמעת המכשיר תומכת במסך נעילה מאובטח, היא:

• [C-1-1] חובה לגבות את הטמעת מאגר המפתחות באמצעות חומרה מאובטחת.
• [C-1-2] חובה שתהיה הטמעה של אלגוריתמים קריפטוגרפיים מסוג RSA,‏ AES,‏ ECDSA ו-HMAC ופונקציות גיבוב ממשפחת MD5,‏ SHA1 ו-SHA-2 כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בליבה ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד הליבה או קוד מרחב המשתמש עשויים לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. הפרויקט של Android Open Source (AOSP) עומד בדרישות האלה באמצעות ההטמעה של Trusty, אבל יש גם אפשרויות חלופיות: פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת של בידוד תקין שמבוסס על hypervisor, שעבר בדיקה על ידי צד שלישי.
• [C-1-3] חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק אם הוא מצליח, לאפשר שימוש במפתחות שמקושרים לאימות. בפרויקט הקוד הפתוח של Android שמשמש כמקור (upstream) יש את שכבת האובייקטים המצומצמים לחומרה (HAL) של Gatekeeper ו-Trusty, שאפשר להשתמש בהם כדי לעמוד בדרישות האלה.
• [C-1-4] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה לאימות מוגן בחומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות החתימה לאימות במספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת מהדרכים לעמוד בדרישות האלה היא לשתף את אותו מפתח אימות, אלא אם מיוצרות לפחות 100,000 יחידות של מק"ט נתון. אם מיוצרות יותר מ-100,000 יחידות של מק"ט מסוים, יכול להיות שייעשה שימוש במפתח שונה לכל 100,000 יחידות.

הערה: אם הטמעה של מכשיר כבר הושקתה בגרסה קודמת של Android, המכשיר הזה פטור מהדרישה לכלול מאגר מפתחות שמבוסס על חומרה ולתמוך באימות המפתחות, אלא אם הוא מצהיר על התכונה android.hardware.fingerprint שדורשת מאגר מפתחות שמבוסס על חומרה.

9.11.1. מסך נעילה מאובטח

אם להטמעות במכשירים יש נעילת מסך מאובטחת והן כוללות סוכן אמון אחד או יותר שמטמיע את TrustAgentService System API, הן:

• [C-1-1] חובה לציין למשתמש בממשק המשתמש של ההגדרות ומסך הנעילה מצבים שבהם נעילת המסך האוטומטית נדחית או שסוכן האמון יכול לבטל את נעילת המסך. מערכת AOSP עומדת בדרישות על ידי הצגת תיאור טקסט בתפריטים 'הגדרת נעילה אוטומטית' ו'הגדרת נעילה מיידית באמצעות לחצן ההפעלה', וכן סמל בולט במסך הנעילה.
• [C-1-2] חובה לפעול בהתאם לכל ממשקי ה-API של סוכני האמון בכיתה DevicePolicyManager ולהטמיע אותם באופן מלא, כמו הקבועה KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-1-3] אסור להטמיע באופן מלא את הפונקציה TrustAgentService.addEscrowToken() במכשיר שמשמש כמכשיר האישי הראשי (למשל, מכשיר נייד), אבל מותר להטמיע את הפונקציה באופן מלא בהטמעות של מכשירים ששותפים בדרך כלל.
• [C-1-4] חובה להצפין את האסימונים שנוספו על ידי TrustAgentService.addEscrowToken() לפני שמאחסנים אותם במכשיר.
• [C-1-5] אסור לאחסן את מפתח ההצפנה במכשיר.
• [C-1-6] חובה להודיע למשתמש על ההשלכות של האבטחה לפני שמפעילים את אסימון ההתחייבות להחזקה לצורך פירעון כדי לפענח את אחסון הנתונים.

אם הטמעות במכשירים מוסיפות או משנות את שיטות האימות לביטול נעילת מסך הנעילה, כדי ששיטת אימות כזו תיחשב כדרך מאובטחת לנעילת המסך, הן צריכות:

• [C-2-1] חייבת להיות שיטת אימות המשתמש כפי שמתואר בקטע דרישה לאימות משתמש לשימוש במפתח.
• [C-2-2] חובה לבטל את הנעילה של כל המפתחות כדי שאפליקציה של מפתח צד שלישי תוכל להשתמש בהם כשהמשתמש מבטל את הנעילה של מסך הנעילה המאובטח. לדוגמה, כל המפתחות חייבים להיות זמינים לאפליקציית מפתח של צד שלישי דרך ממשקי API רלוונטיים, כמו createConfirmDeviceCredentialIntent ו-setUserAuthenticationRequired.

אם הטמעות במכשירים מוסיפות או משנות את שיטות האימות כדי לבטל את נעילת מסך הנעילה אם הן מבוססות על סוד ידוע, כדי ששיטת אימות כזו תיחשב כדרך מאובטחת לנעילת המסך, הן:

• [C-3-1] האנטרופיה של האורך הקצר ביותר של קלט מותר חייבת להיות גדולה מ-10 ביט.
• [C-3-2] ההאנטרופיה המקסימלית של כל ערכי הקלט האפשריים חייבת להיות גדולה מ-18 ביט.
• [C-3-3] אסור להחליף אף אחת משיטות האימות הקיימות (קוד אימות,דפוס, סיסמה) שמוטמעות ומסופקות ב-AOSP.
• [C-3-4] חובה להשבית כשאפליקציית Device Policy Controller‏ (DPC) מגדירה את מדיניות איכות הסיסמאות באמצעות השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_SOMETHING.

אם הטמעות במכשירים מוסיפות או משנות את שיטות האימות כדי לבטל את נעילת מסך הנעילה אם הן מבוססות על טוקן פיזי או על המיקום, כדי ששיטת אימות כזו תיחשב כדרך מאובטחת לנעילת המסך, הן צריכות:

• [C-4-1] חייב להיות מנגנון חלופי לשימוש באחת משיטות האימות הראשיות שמבוססת על סוד ידוע ועומדת בדרישות לטיפול כמסך נעילה מאובטח.
• [C-4-2] חייב להיות מושבת ולאפשר רק לאימות הראשי לבטל את נעילת המסך כשאפליקציית 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) מגדירה את מדיניות התכונה של keguard באמצעות קריאה לשיטה DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
• [C-5-3] שיעור הקבלה השגוי חייב להיות שווה או חזק יותר מזה שנדרש לחיישן טביעות אצבע כפי שמתואר בקטע 7.3.10, או אחרת חייב להיות מושבת ולאפשר רק לאימות הראשי לבטל את נעילת המסך כשאפליקציית Device Policy Controller‏ (DPC) מגדירה את מדיניות איכות הסיסמה באמצעות השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-4] חובה לבצע אתגר למשתמש לאימות הראשי (למשל, קוד אימות, קו ביטול נעילה, סיסמה) לפחות פעם אחת בכל 72 שעות או פחות.

אם הטמעות במכשירים מוסיפות או משנות את שיטות האימות לביטול הנעילה של מסך הנעילה, ואם שיטת אימות כזו תשמש לביטול הנעילה של מגן המסך, אבל לא תיחשב כמסך נעילה מאובטח, אז:

• [C-6-1] חובה להחזיר את הערך false בשתי השיטות KeyguardManager.isKeyguardSecure() ו-KeyguardManager.isDeviceSecure().
• [C-6-2] חובה להשבית כשאפליקציית Device Policy Controller‏ (DPC) מגדירה את מדיניות איכות הסיסמה באמצעות השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_UNSPECIFIED.
• [C-6-3] אסור לאפס את הטיימר לתפוגת התוקף של הסיסמאות שהוגדרו על ידי DevicePolicyManager.setPasswordExpirationTimeout().
• [C-6-4] אסור לבצע אימות של גישה למאגרי מפתחות אם האפליקציה התקשרה ל-KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)).

9.12. מחיקת נתונים

כל הטמעות המכשירים:

• [C-0-1] חובה לספק למשתמשים מנגנון לביצוע 'איפוס לנתוני היצרן'.
• [C-0-2] חובה למחוק את כל הנתונים שנוצרו על ידי משתמשים. כלומר, כל הנתונים מלבד הנתונים הבאים:
  • קובץ האימג' של המערכת
  • כל קובץ מערכת הפעלה שנדרש לקובץ האימג' של המערכת
• [C-0-3] חובה למחוק את הנתונים באופן שיעמוד בתקני התעשייה הרלוונטיים, כמו NIST SP800-88.
• [C-0-4] חובה להפעיל את התהליך 'איפוס להגדרות המקוריות' שמתואר למעלה כשאפליקציית הבקר לניהול מדיניות המכשירים (DPC) של המשתמש הראשי קוראת ל-API‏ DevicePolicyManager.wipeData().
• יכול להיות שתהיה אפשרות למחיקת נתונים מהירה שמתבצעת רק מחיקה לוגית של הנתונים.

9.13. מצב הפעלה בטוח

ב-Android יש מצב הפעלה בטוח שמאפשר למשתמשים להפעיל את המכשיר במצב שבו רק אפליקציות מערכת מותקנות מראש יכולות לפעול, וכל האפליקציות של צד שלישי מושבתות. המצב הזה, שנקרא 'מצב הפעלה בטוח', מאפשר למשתמש להסיר אפליקציות צד שלישי שעלולות להזיק.

הטמעות במכשירים הן:

• [SR] STRONGLY RECOMMENDED to implement Safe Boot Mode.

אם הטמעות במכשירים מיישמות את מצב ההפעלה הבטוח, הן:

• [C-1-1] חובה לספק למשתמש אפשרות להיכנס למצב הפעלה בטוח באופן שלא ניתן להפרעה מאפליקציות צד שלישי שמותקנות במכשיר, אלא אם אפליקציית הצד השלישי היא 'בקר מדיניות המכשיר' והגדירה את הדגל UserManager.DISALLOW_SAFE_BOOT כ-true.

• [C-1-2] חובה לספק למשתמש את היכולת להסיר כל אפליקציה של צד שלישי במצב בטוח.

• צריך לספק למשתמש אפשרות להיכנס למצב הפעלה בטוח מתפריט האתחול באמצעות תהליך עבודה שונה מזה של הפעלה רגילה.

9.14. בידוד של מערכת הרכב

מכשירי Android Automotive צפויים להחליף נתונים עם תת-מערכות קריטיות ברכב באמצעות HAL הרכב כדי לשלוח ולקבל הודעות ברשתות הרכב, כמו CAN bus.

כדי לאבטח את חילופי הנתונים, אפשר להטמיע תכונות אבטחה מתחת לשכבות של Android framework כדי למנוע אינטראקציה זדונית או לא מכוונת עם תת-המערכות האלה.

10. בדיקת תאימות של תוכנות

הטמעות של מכשירים חייבות לעבור את כל הבדיקות שמתוארות בקטע הזה. עם זאת, חשוב לזכור שאף חבילת בדיקות תוכנה לא מקיפה לחלוטין. לכן, מומלץ מאוד למטמיעים של מכשירים לבצע את המספר המינימלי של שינויים האפשרי בהטמעה המועדפת והמומלצת של Android שזמינה בפרויקט Android Open Source. כך תוכלו לצמצם את הסיכון להוספת באגים שיוצרים אי-תאימות שדורשת עבודה מחדש ועדכונים פוטנציאליים של המכשיר.

10.1. חבילה לבדיקות תאימות (CTS)

הטמעות במכשירים:

• [C-0-1] חובה לעבור את Android Compatibility Test Suite‏ (CTS) שזמין בפרויקט Android Open Source, באמצעות תוכנת האספקה הסופית במכשיר.

• [C-0-2] חובה לוודא תאימות במקרים של אי-בהירות ב-CTS ובכל הטמעה מחדש של חלקים מקוד המקור של ההפניה.

ה-CTS מיועד להרצה במכשיר בפועל. כמו כל תוכנה, גם CTS עשוי להכיל באגים. הגרסה של CTS תהיה עצמאית מהגדרת התאימות הזו, ויכול להיות שיושקו כמה גרסאות של CTS ל-Android 8.0.

הטמעות במכשירים:

• [C-0-3] חובה לעבור את גרסת CTS העדכנית ביותר שזמינה בזמן השלמת תוכנת המכשיר.

• מומלץ להשתמש בהטמעת העזר ב-Android Open Source Tree כמה שיותר.

10.2. CTS Verifier

CTS Verifier נכלל בחבילת בדיקות התאימות, והוא מיועד להפעלה על ידי מפעיל אנושי כדי לבדוק פונקציונליות שלא ניתן לבדוק באמצעות מערכת אוטומטית, כמו הפעולה הנכונה של מצלמה וחיישנים.

הטמעות במכשירים:

• [C-0-1] חובה להריץ בצורה נכונה את כל התרחישים הרלוונטיים באימות CTS.

ב-CTS Verifier יש בדיקות לסוגים רבים של חומרה, כולל חומרה חלקית שהיא אופציונלית.

הטמעות במכשירים:

• [C-0-2] חובה לעבור את כל הבדיקות של החומרה שקיימת במכשיר. לדוגמה, אם במכשיר יש תאוצה, חובה להריץ בצורה נכונה את תרחיש הבדיקה של התאוצה ב-CTS Verifier.

מותר לדלג על תרחישי בדיקה של תכונות שצוינו כאופציונליות במסמך הגדרת התאימות הזה, או להשמיט אותן.

• [C-0-2] כל מכשיר וכל גרסה זמנית של האפליקציה חייבים להריץ בצורה תקינה את CTS Verifier, כפי שצוין למעלה. עם זאת, מאחר שגרסאות build רבות דומות מאוד, לא צפוי שמטמיעים של מכשירים יפעלו במפורש את CTS Verifier על גרסאות build ששונות רק בדרכים טריוויאליות. באופן ספציפי, הטמעות של מכשירים ששונות מהטמעה שעברה את CTS Verifier רק במיקומים שונים, בסמלי מותג וכו', יכולות להשמיט את הבדיקה של CTS Verifier.

11. תוכנה שניתן לעדכן

• [C-0-1] הטמעות במכשירים חייבות לכלול מנגנון להחלפת כל תוכנת המערכת. המנגנון לא חייב לבצע שדרוגים 'בזמן אמת' – כלומר, יכול להיות שיהיה צורך להפעיל מחדש את המכשיר.

אפשר להשתמש בכל שיטה, בתנאי שהיא יכולה להחליף את כל התוכנות שמותקנות מראש במכשיר. לדוגמה, כל אחת מהגישות הבאות תעמוד בדרישות האלה:

• הורדות 'Over-the-air (OTA)' עם עדכון אופליין באמצעות הפעלה מחדש.
• עדכונים 'מחוברים' דרך USB ממחשב מארח.

• עדכונים 'לא מקוונים' באמצעות הפעלה מחדש ועדכון מקובץ באחסון נשלף.

• [C-0-2] מנגנון העדכון שבו נעשה שימוש חייב לתמוך בעדכונים בלי למחוק את נתוני המשתמשים. כלומר, מנגנון העדכון חייב לשמור על נתונים פרטיים של האפליקציה ועל נתונים משותפים של האפליקציה. שימו לב שתוכנת Android במקור כוללת מנגנון עדכון שעומד בדרישות האלה.

אם הטמעות המכשיר כוללות תמיכה בחיבור נתונים ללא חיוב לפי שימוש, כמו פרופיל 802.11 או Bluetooth PAN (רשת אזור אישית), אז:

• [C-1-1] חובה לתמוך בהורדות OTA עם עדכון אופליין באמצעות הפעלה מחדש.

בהטמעות של מכשירים שמריצים את Android מגרסה 6.0 ואילך, מנגנון העדכון אמור לתמוך באימות שתמונת המערכת היא קביעה בינארית זהה לתוצאה הצפויה לאחר עדכון OTA. ההטמעה של OTA מבוססת-הבלוק ב-Android Open Source Project (פרויקט קוד הפתוח של Android) שנוספה מאז Android 5.1, עומדת בדרישות האלה.

בנוסף, הטמעות במכשירים אמורות לתמוך בעדכוני מערכת מסוג A/B. התכונה הזו מיושמת ב-AOSP באמצעות HAL לבקרת אתחול.

אם נמצאת שגיאה בהטמעת מכשיר אחרי שהמכשיר שוחרר, אבל במהלך משך החיים הסביר של המוצר, שנקבע בהתייעצות עם צוות התאימות של Android, והיא משפיעה על התאימות של אפליקציות של צד שלישי, אז:

• [C-2-1] מי שמטמיע את המכשיר חייב לתקן את השגיאה באמצעות עדכון תוכנה זמין שאפשר להחיל בהתאם למנגנון שמתואר למעלה.

מערכת Android כוללת תכונות שמאפשרות לאפליקציית הבעלים של המכשיר (אם היא קיימת) לשלוט בהתקנה של עדכוני המערכת. אם מערכת המשנה של עדכוני המערכת למכשירים מדווחת על android.software.device_admin, המשמעות היא שהמכשירים:

• [C-3-1] חובה להטמיע את ההתנהגות שמתוארת בכיתה SystemUpdatePolicy.

12. יומן השינויים של המסמך

סיכום של השינויים בהגדרת התאימות בגרסה הזו:

• תיעוד של יומן השינויים

סיכום של השינויים בקטעים של אנשים פרטיים:

1. מבוא
2. סוגי מכשירים
3. תוכנה
4. אריזת אפליקציות
5. מדיה מעורבת
6. כלים ואפשרויות למפתחים
7. תאימות חומרה
8. ביצועים וצריכת חשמל
9. מודל אבטחה
10. בדיקת תאימות תוכנה
11. תוכנות שניתן לעדכן
12. יומן השינויים של המסמך
13. יצירת קשר

12.1. טיפים לצפייה ביומן השינויים

השינויים מסומנים באופן הבא:

• CDD
  שינויים מהותיים בדרישות התאימות.

• מסמכים
  שינויים קוסמטיים או שינויים שקשורים ל-build.

כדי שהתצוגה תהיה הכי טובה, מוסיפים את הפרמטרים של כתובות ה-URL pretty=full ו-no-merges לכתובות ה-URL של יומני השינויים.

13. יצירת קשר

אתם יכולים להצטרף לפורום התאימות ל-Android ולבקש הבהרות או להעלות בעיות שלדעתכם לא מפורטות במסמך.