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

‫1. הקדמה

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

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

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

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

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

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

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

1.1 מבנה המסמך

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

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

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

1.1.2. מזהה דרישה

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

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

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

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

1.1.3. מזהה דרישה בסעיף 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1. חומרה

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

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

אם בהטמעות של מכשירים ניידים יש תמיכה במסכים עם טווח דינמי גבוה עד Configuration.isScreenHdr():

  • [7.1.4.5/H-1-1] חייב לפרסם תמיכה לתוספים EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace ו-VK_EXT_hdr_metadata.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 (משופר נמוך השהיה נמוכה)

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

  • [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.2.3.1/H-0-1] חייבת להיות אפליקציה שמטפלת באובייקטים מסוג ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE וACTION_CREATE_DOCUMENT כפי שמתואר במסמכי ה-SDK. בנוסף, חובה לספק למשתמש אפליקציה שמאפשרת לו לגשת לנתוני ספק המסמכים באמצעות DocumentsProvider API.
  • [3.4.1/H-0-1] חייב לספק הטמעה מלאה של ה-API של android.webkit.Webview.
  • [3.4.2/H-0-1] חייב לכלול אפליקציית דפדפן נפרדת לגלישה כללית של משתמשים באינטרנט.
  • [3.8.1/H-SR] מומלץ מאוד להטמיע מרכז אפליקציות שמוגדר כברירת מחדל שתומך בהצמדה של קיצורי דרך, ווידג'טים ו-widgetFeatures בתוך האפליקציה.
  • [3.8.1/H-SR] מומלץ מאוד להטמיע מרכז אפליקציות שמוגדר כברירת מחדל שמספק גישה מהירה לקיצורי הדרך הנוספים שמסופקים על ידי אפליקציות צד שלישי דרך ShortcutManager API.
  • [3.8.1/H-SR] מומלץ מאוד לכלול אפליקציית מרכז אפליקציות שמוגדרת כברירת מחדל שמציגה תגים לסמלי האפליקציות.
  • [3.8.2/H-SR] מומלץ מאוד לתמוך בווידג'טים של אפליקציות של צד שלישי.
  • [3.8.3/H-0-1] אפליקציות של צד שלישי חייבות להודיע למשתמשים על אירועים חשובים באמצעות מחלקות ה-API Notification ו-NotificationManager.
  • [3.8.3/H-0-2] חייבת לתמוך בהתראות מתקדמות.
  • [3.8.3/H-0-3] חייבת לתמוך בהתראות שימו לב.
  • [3.8.3/H-0-4] חייב לכלול לוח התראות שמאפשר למשתמש לשלוט באופן ישיר (לדוגמה: להשיב, להפעיל נודניק, לסגור או לחסום) בהתראות דרך תקציב המשתמשים, כגון לחצני פעולה או לוח הבקרה כפי שהוטמע ב-AOSP.
  • [3.8.3/H-0-5] חובה להציג את האפשרויות שסופקו דרך RemoteInput.Builder setChoices() בלוח ההתראות.
  • [3.8.3/H-SR] מומלץ מאוד להציג את האפשרות הראשונה של RemoteInput.Builder setChoices() בלוח ההתראות, ללא אינטראקציה נוספת מצד המשתמש.
  • [3.8.3/H-SR] מומלץ מאוד להציג את כל האפשרויות שזמינות דרך RemoteInput.Builder setChoices() בלוח ההתראות כשהמשתמש מרחיב את כל ההתראות בלוח ההתראות.
  • [3.8.4/H-SR] מומלץ מאוד להטמיע עוזר דיגיטלי במכשיר שיטפל בפעולת סיוע.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.5. דגם אבטחה

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

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

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

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

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

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

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

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

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

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] צריכה להיות אפשרות לדווח על אירועים עד תדירות של 100 Hz לפחות.

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.2. מולטימדיה

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

  • [5.1/T-0-1] MPEG-4 AAC Profile (AAC LC)
  • [5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
  • [5.1/T-0-3] AAC ELD (משופר עם השהיה נמוכה AAC)

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

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

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

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

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

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

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

  • [5.3.4.4/T-1-1] איכות HD 1080p בקצב של 60FPS עם פרופיל Basline
  • [5.3.4.4/T-1-2] HD 1080p בקצב של 60 פריימים לשנייה עם פרופיל ראשי
  • [5.3.4.4/T-1-3] איכות HD 1080p בקצב של 60 FPS ברמה 4.2 של פרופיל גבוה

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

  • [5.3.5.4/T-1-1] HD 1080p בקצב של 60 FPS ברמה 4.1 של פרופיל ראשי

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

  • [5.3.5.5/T-2-1] חייב לתמוך בפרופיל פענוח באיכות UHD בקצב של 60 פריימים לשנייה, בפרופיל הראשי ב-Main10 ברמה 5.

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

  • [5.3.6.4/T-1-1] פרופיל פענוח באיכות HD 1080p בקצב של 60FPS

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

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

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

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

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

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

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

  • [5.8/T-1-1] חייב לתמוך ב-HDCP 2.2.

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

  • [5.8/T-2-1] חייב לתמוך ב-HDCP 1.4

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 TV יש תמיכה במסך נעילה:

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

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

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

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

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

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

  • [3.12/T-0-1] חייב לתמוך במסגרת של קלט טלוויזיה.

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

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

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

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

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

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

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

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

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

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

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

2.4.1. חומרה

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

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

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

  • [7.2.4/W-0-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 (בשפות שנתמכות על ידי המנוע של המרת טקסט לדיבור (TTS)) שהותקן מראש, כפי שמסופק בפרויקט קוד פתוח של TalkBack.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [7.3.11/A-0-1] חייב לספק את הציוד הנוכחי בתור 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.4/A-0-1] חובה לספק את מהירות הרכב כפי שהוגדרה על ידי SENSOR_TYPE_CAR_SPEED.

  • [7.3.11.5/A-0-1] חובה לציין את סטטוס בלם החנייה כפי שמוגדר ב-SENSOR_TYPE_PARKING_BRAKE.

  • [7.4.3/A-0-1] צריכה לתמוך ב-Bluetooth והיא צריכה לתמוך ב-Bluetooth LE.

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

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

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

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

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

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

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

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

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

אם ההטמעה של מכשירי כלי רכב היא בגרסת 32 ביט:

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

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

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

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

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

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

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

    • 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] הזיכרון הזמין לליבה ולמרחב המשתמש חייב להיות לפחות 1280MB אם נעשה שימוש בצפיפות:

    • 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] חייבת לתמוך בכל ממשקי ה-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-SR] מומלץ מאוד להטמיע עוזר דיגיטלי במכשיר שיטפל בפעולת Assist.

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

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

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

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

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

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

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

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

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

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

2.5.5. דגם אבטחה

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

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

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

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

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

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

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

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

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

2.4.1. חומרה

גודל המסך

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

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

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

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

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

  • [7.7.1/Tab] יכול להיות שה-API של Android Open Accessory (AOA) יוטמע.

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

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

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

3. תוכנה

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

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

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

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

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

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

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

  • [C-0-5] חובה להגביל את השימוש באפליקציות של צד שלישי בממשקי API מוסתרים, שמוגדרים כממשקי API במרחב השמות של Android שמעוצב עם ההערה @hidden אבל לא ב-@SystemAPI או ב-@TestApi, כפי שמתואר במסמכי ה-SDK. הם נשלחים יחד עם כל אחד מהממשקי API המוסתרים באותן רשימות מוגבלות שסופקו דרך רשימת התנאים וההגבלות והקבצים של רשימת הישויות שנחסמו בנתיב prebuilts/runtime/appcompat/ להסתעפות המתאימה של רמת ה-API. עם זאת:

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

3.1.1. תוספים ל-Android

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

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

3.1.2. ספריית Android

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

  • [C-0-1] אסור למקם את הספרייה org.apache.http.legacy בנתיב קטגוריית האתחול.
  • [C-0-2] חובה להוסיף את הספרייה org.apache.http.legacy לנתיב הכיתה של האפליקציה רק אם האפליקציה עומדת באחד מהתנאים הבאים:
    • מוגדר טירגוט לרמת API 28 ומטה.
    • במניפסט הוא מצהיר שנדרשת הספרייה על ידי הגדרת המאפיין android:name של <uses-library> ל-org.apache.http.legacy.

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

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

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

3.2.1. הרשאות

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

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

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

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

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

לדוגמה:

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

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

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

3.2.3. תאימות של Intent

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3. תאימות ל-Native API

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

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

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

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

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

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

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

    • armeabi
    • armeabi-v7a
    • arm64-v8a
    • x86
    • x86-64

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

    • libaaudio.so (תמיכה באודיו מקורי של AAudio)

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

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

  • [C-0-9] חובה לכלול ספריות נוספות שאינן של AOSP שחשופות ישירות לאפליקציות של צד שלישי ב-/vendor/etc/public.libraries.txt.
  • [C-0-10] אסור לחשוף ספריות מקוריות אחרות, שהוטמעו וסיפקו ב-AOSP כספריות מערכת, לאפליקציות של צד שלישי שמטרגטות לרמת API 24 ומעלה כפי שהן נשמרות.
  • [C-0-11] חובה לייצא את כל סמלי הפונקציה OpenGL ES 3.1 וחבילת תוספים של Android, כפי שמוגדרים ב-NDK, דרך הספרייה libGLESv3.so. לתשומת ליבכם: חובה לציין את כל הסמלים, אבל סעיף 7.1.4.1 מתאר בפירוט רב יותר את הדרישות שבהן צריך לעמוד כדי ליישם את כל הפונקציות התואמות.
  • [C-0-12] חובה לייצא סמלי פונקציות עבור סמלי הליבה של פונקציית Vulkan 1.0, וגם את התוספים VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 ו-VK_KHR_get_physical_device_properties2 דרך הספרייה libvulkan.so. לתשומת ליבכם: חובה לציין את כל הסמלים, אבל סעיף 7.1.4.2 מתאר בפירוט רב יותר את הדרישות שבהן צריך לעמוד כדי ליישם את כל הפונקציות התואמות.
  • יש לבנות באמצעות קוד המקור וקובצי הכותרת הזמינים בפרויקט קוד פתוח של Android ב-upstream

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

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

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

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

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

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

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

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

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

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

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

3.4.1. תאימות ל-WebView

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.5.1. הגבלת רקע

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

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

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

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

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

כלומר, הן:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.2. ווידג'טים

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

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

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

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

3.8.3. התראות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.5. התראות והודעות קוליות

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

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

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

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

3.8.6. עיצובים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.9. ניהול קלט

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

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

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

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

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

3.8.10. בקרת מדיה במסך הנעילה

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

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

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

3.8.12. מיקום

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

3.8.13. Unicode וגופן

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

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

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

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

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

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

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

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

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

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

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

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

3.8.15. גזירה בתצוגה

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

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

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

3.9. ניהול המכשיר

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

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

  • [C-1-1] חובה להצהיר על android.software.device_admin.
  • [C-1-2] חייבת לתמוך בהקצאת הרשאות ידנית של בעלי המכשיר כפי שמתואר בסעיף 3.9.1 וסעיף 3.9.1.1.

3.9.1 הקצאת מכשיר

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

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

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

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

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

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

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

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

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

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

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

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

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

3.9.3 תמיכה במשתמשים מנוהלים

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

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

3.10. נגישות

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-1-1] חובה להצהיר על הפיצ'ר android.software.live_tv בפלטפורמה.
  • [C-1-2] חייבת לתמוך בכל ממשקי ה-API של TIF, כך שניתן יהיה להתקין במכשיר אפליקציה שמשתמשת בממשקי ה-API האלה ואת שירות הקלט מבוסס TIF של צד שלישי.

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

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

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

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

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

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

  • [C-1-1] חייבים להציג סמלים וסמלי התראות של MediaItem ללא שינויים.
  • [C-1-2] חייבים להציג את הפריטים האלה כפי שמתואר על ידי MediaSession, למשל מטא-נתונים, סמלים ותמונות.
  • [C-1-3] חובה להציג את כותרת האפליקציה.
  • [C-1-4] חייבת להיות חלונית הזזה או מנגנון אחר להצגת ההיררכיה של MediaBrowser ולאפשר למשתמש לעמוד בהיררכיה של MediaBrowser.
  • [C-1-5] מומלץ להקיש הקשה כפולה על KEYCODE_HEADSETHOOK או על KEYCODE_MEDIA_PLAY_PAUSE בתור KEYCODE_MEDIA_NEXT למשך MediaSession.Callback#onMediaButtonEvent.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.1. רכיבי קודק של מדיה

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

לפרטים נוספים קראו את הקטע 5.1.3. פרטי רכיבי הקודק של האודיו.

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

  • [C-1-1] PCM/WAVE

5.1.2. פענוח הקוד של האודיו

לפרטים נוספים קראו את הקטע 5.1.3. פרטי רכיבי הקודק של האודיו.

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

  • [C-1-1] פרופיל MPEG-4 AAC (AAC LC)
  • [C-1-2] פרופיל MPEG-4 HE AAC (AAC+ )
  • [C-1-3] פרופיל MPEG-4 HE AACv2 (משופר עבור AAC+ )
  • [C-1-4] AAC ELD (AAC מושהה עם השהיה נמוכה)
  • [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile), כולל את פרופיל הבסיס של USAC ואת פרופיל ISO/IEC 23003-4 Dynamic Range Control Profile)
  • [C-1-5] קובץ FLAC
  • [C-1-6] MP3
  • [C-1-7] MIDI
  • [C-1-8] ורביס
  • [C-1-9] PCM/WAVE
  • [C-1-10] אופוס

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

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

בעת פענוח אודיו של USAC, MPEG-D (ISO/IEC 23003-4):

  • [C-3-1] המטא-נתונים של עוצמת קול ו-DRC חייבים להיות מפורשים ולהחיל אותם בהתאם לרמת פרופיל 1 של בקרת טווח דינמי של MPEG-D DRC.
  • [C-3-2] המפענח MUST פועל בהתאם להגדרות שהוגדרו עם מפתחות android.media.MediaFormat הבאים: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL ו-KEY_AAC_DRC_EFFECT_TYPE.

מפענחי פרופיל MPEG-4 AAC, HE AAC ו-HE AACv2:

  • MAY תומך בעוצמת קול ובטווח דינמי באמצעות פרופיל של בקרת טווח דינמית לפי ISO/IEC 23003-4.

אם ISO/IEC 23003-4 נתמך ואם גם המטא-נתונים ISO/IEC 23003-4 וגם המטא-נתונים של ISO/IEC 14496-3 נמצאים ב-bitstream מפוענח:

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

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

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

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

לפרטים נוספים קראו את המאמר 5.1.6. פרטי קודק התמונה.

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

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

5.1.5. פענוח הקוד של התמונה

לפרטים נוספים קראו את המאמר 5.1.6. פרטי קודק התמונה.

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

  • [C-0-1] JPEG
  • [C-0-2] GIF
  • [C-0-3] PNG
  • [C-0-4] BMP
  • [C-0-5] WebP
  • [C-0-6] גולמי
  • [C-0-7] HEIF (HEIC)

5.1.6. פרטי קודק התמונה

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

5.1.7. רכיבי קודק של וידאו

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

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

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

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

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

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

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

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

5.1.8. רשימת רכיבי קודק של וידאו

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

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

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

  • אסור שקצב העברת הנתונים יהיה על פני שני חלונות הזזה בקצב של יותר מ-15% בין מרווחים פנימיים (I-frame).
  • קצב העברת הנתונים לא אמור להיות גבוה מ-100% בערך במהלך חלון הזזה של שנייה אחת.

אם הטמעות המכשיר כוללות תצוגת מסך מוטמעת באורך אלכסון של 2.5 אינץ' לפחות, או כוללות יציאת פלט וידאו או מצהירה על תמיכה במצלמה באמצעות התכונה הניסיונית android.hardware.camera.any, הן:

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

אם ההטמעות במכשירים תומכים במקודדי הווידאו H.264, VP8, VP9 או HEVC והופכים אותם לזמינים באפליקציות צד שלישי:

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

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

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

5.2.1. H.263

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

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

5.2.2. H-264

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

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

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

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

5.2.3. VP8

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

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

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

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

5.2.4. VP9

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

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

5.3. פענוח הקוד של הווידאו

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

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

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

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

5.3.1. MPEG-2

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

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

5.3.2. H.263

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

  • [C-1-1] חובה לתמוך בפרופיל הבסיס ברמה 30 וברמה 45.

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

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

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

5.3.5. H.265 (‏HEVC)

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

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

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

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

5.3.6. VP8

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

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

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

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

5.3.7. VP9

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

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

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

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

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

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

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

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

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

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

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

    • פורמט: PCM לינארי, 16 ביט
    • קצבי דגימה: 8,000, 11,025, 16,000, 44,100 Hz
    • ערוצים: מונו

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • פורמט: PCM לינארי, 16 ביט, 8 ביט, מספר ממשי (float)
    • ערוצים: מונו, סטריאו, הגדרות חוקיות מרובות ערוצים עם עד 8 ערוצים
    • קצבי דגימה (ב-Hz):
      • 8000, 11025, 16000, 22050, 32000, 44100 או 48000 בהגדרות הערוצים שצוינו למעלה
      • 96000 במונו ובסטריאו

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

    • קצב דגימה: 24000, 48000

5.5.2. אפקטים קוליים

ב-Android יש API לאפקטים קוליים בהטמעות במכשירים.

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

  • [C-1-1] חייבת לתמוך בהטמעות של EFFECT_TYPE_EQUALIZER ו-EFFECT_TYPE_LOUDNESS_ENHANCER שניתן לשלוט בהן באמצעות מחלקות המשנה Audio Effects Equalizer, LoudnessEnhancer.
  • [C-1-2] חייבת להיות תמיכה בהטמעה של ממשק API של Visualizer, שאפשר לשלוט בו באמצעות המחלקה Visualizer.
  • [C-1-3] חייבת לתמוך בהטמעה של EFFECT_TYPE_DYNAMICS_PROCESSING שניתן לשלוט בה באמצעות מחלקה משנית של Audio במסך DynamicsProcessing.
  • צריכה לתמוך בהטמעות של EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB ו-EFFECT_TYPE_VIRTUALIZER שאפשר לשלוט בהן באמצעות מחלקות המשנה BassBoost, EnvironmentalReverb, PresetReverb ו-Virtualizer.AudioEffect

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

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

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

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

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

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

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

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

  • [C-SR] זמן אחזור של פלט במצב קר של 100 אלפיות השנייה או פחות
  • [C-SR] זמן אחזור רציף של 45 אלפיות השנייה או פחות
  • [C-SR] מזעור רעידות הפלט במצב קר
  • [C-SR] חותמת הזמן של הפלט שהוחזרה על ידי AudioTrack.getTimestamp ו-AAudioStream_getTimestamp מדויקת ל-1 אלפיות השנייה או ל- +/-.

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

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

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

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

  • [C-SR] זמן אחזור של קלט קר של 100 אלפיות השנייה או פחות.
  • [C-SR] זמן אחזור רציף של 30 אלפיות השנייה לכל היותר.
  • [C-SR] זמן אחזור רציף הלוך ושוב של 50 אלפיות השנייה או פחות.
  • [C-SR] מזעור רעידות הקלט הקרה.
  • [C-SR] הגבלה של השגיאה בחותמות הזמן של הקלט, כפי שהוחזרה על ידי AudioRecord.getTimestamp או AAudioStream_getTimestamp, ל- +/- 1 אלפיות השנייה.

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

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

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

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

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

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

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

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

קודק האודיו:

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

RTSP (RTP, SDP)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • [C-0-2] חייבת לתמוך ב-adb כפי שמתואר ב-Android SDK ובפקודות המעטפת שמסופקות ב-AOSP, שבהן מפתחי אפליקציות יכולים להשתמש, כולל dumpsys ו-cmd stats.
    • [C-0-3] אסור לשנות את הפורמט או את התוכן של אירועי מערכת של המכשיר (batterystats , דיסקים, טביעות אצבע, Graphicsstats, netstats, התראה, Procstats) שתועדו באמצעות הפקודה dumpsys.
    • [C-0-10] חובה לתעד, ללא השמטת נתונים, ולהפוך את האירועים הבאים לנגישים וזמינים לפקודת המעטפת cmd stats ולמחלקה StatsManager System API.
      • הפעילות בחזית שונתה
      • זוהתה חריגה
      • נשלח דיווח על נתיבי ניווט ב-AppB
      • AppCrashOccurred
      • AppStartOccurred
      • רמת הסוללה שונתה
      • הסוללהSaverModeStateChanged
      • BleScanresultReceived
      • BleScanStateChanged
      • ChargingStateChanged
      • DeviceIdleModeStateChanged
      • ForegroundServiceStateChanged
      • GpsScanStateChanged
      • JobStateChanged (שינוי מצב המשימה)
      • PluggedStateChanged
      • משימות מתוזמנות
      • ScreenState השתנה
      • SyncStateChanged
      • זמן אמת ב-SystemElapse
      • UidProcessStateChanged
      • מצב WakelockState השתנה
      • מעורר התעוררות
      • מצב Wi-FiLockState השתנה
      • WifiMulticastLockStateChange
      • מצב WifiScanState השתנה
    • [C-0-4] דימון (daemon) בצד המכשיר חייב להיות לא פעיל כברירת מחדל, וחייב להיות מנגנון נגיש למשתמש כדי להפעיל את גשר ניפוי הבאגים ב-Android.
    • [C-0-5] חייבת לתמוך ב-adb מאובטח. Android כולל תמיכה ב-adb מאובטח. פרוטוקול adb מאובטח מאפשר הפעלה של adb במארחים מאומתים מוכרים.

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

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

  • Dalvik Debug Monitor Service (ddms)

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

אם הטמעות מכשירים מדווחות על תמיכה ב-Vulkan 1.0 ואילך באמצעות התכונות הניסיוניות של android.hardware.vulkan.version:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.1.1. הגדרת המסך

7.1.1.1. הגודל והצורה של המסך

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

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

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

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

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

  • ייתכן שיש בהם מסך עם פינות מעוגלות.

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

  • [C-1-1] חובה לוודא שהרדיוס של הפינות המעוגלות קטן מ-38 dp או שווה לו.
  • לאפשר למשתמש לעבור למצב תצוגה עם הפינות המלבניות?
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)
    • 160 dpi (mdpi)
    • 213 dpi (tvdpi)
    • 240 dpi (hdpi)
    • 260 dpi (260dpi)
    • 280 dpi (280dpi)
    • 300 dpi (300dpi)
    • 320 dpi (xhdpi)
    • 340 dpi (340dpi)
    • 360 dpi (360dpi)
    • 400 dpi (400dpi)
    • 420 dpi (420dpi)
    • 480 dpi (xxhdpi)
    • 560 dpi (560dpi)
    • 640 dpi (xxxhdpi)

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

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

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

7.1.2. מדדי פרסום ברשת המדיה

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

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

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

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

7.1.3. כיוון מסך

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

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

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

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

7.1.4. האצת גרפיקה דו-ממדית ותלת-ממדית

7.1.4.1 OpenGL ES

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • היא צריכה לכלול תמיכה ב-Vulkan 1.1.

אם הטמעות מכשירים כוללות תמיכה ב-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 , ולעומת זאת אסור לדווח על מחרוזות תוספים שהן לא תומכות בהן בצורה נכונה.
  • [C-1-7] חייבת לתמוך בתוספים VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain ו-VK_KHR_incremental_present.

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

  • [C-2-1] אסור להצהיר על תכונות ניסיוניות של Vulkan (למשל android.hardware.vulkan.level, android.hardware.vulkan.version).
  • [C-2-2] אסור לספור VkPhysicalDevice ל-API המקורי של Vulkan vkEnumeratePhysicalDevices().

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

  • [C-3-1] חובה לחשוף את התמיכה בסוגי הכינויים והסמפור החיצוני של SYNC_FD.
  • [SR] מומלץ מאוד לתמוך בתוסף VK_ANDROID_external_memory_android_hardware_buffer.
7.1.4.3 RenderScript
  • [C-0-1] הטמעות מכשירים חייבות לתמוך ב-Android RenderScript, כפי שמפורט במסמכים של Android SDK.
7.1.4.4 האצת גרפיקה דו-ממדית

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

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

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

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

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

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

אם הטמעות במכשירים טוענים שיש תמיכה במסכים עם טווח רחב דרך Configuration.isScreenWideColorGamut():

  • [C-1-1] מסך מכויל בצבע.
  • [C-1-2] חייב להיות מסך שכל סולם הצבעים של sRGB מכסה את כל מכלול הצבעים של CIE 1931 xyY.
  • [C-1-3] חייב להיות מסך עם שטח של 90% לפחות מ-DCI-P3 במרחב CIE 1931 xyY.
  • [C-1-4] חייבת לתמוך ב-OpenGL ES 3.1 או 3.2 ולדווח עליה כמו שצריך.
  • [C-1-5] חובה לפרסם תמיכה לתוספים EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3 ו-EGL_KHR_gl_colorspace_display_p3.
  • [SR] מומלץ מאוד לתמוך ב-GL_EXT_sRGB.

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

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

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

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

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

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

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

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

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

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

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

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

7.2. התקני קלט

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

7.2.1. מקלדת

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

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

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

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

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

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

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

7.2.3. מקשי ניווט

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

  • [C-0-1] חובה להציע למשתמשים אפשרות להשיק אפליקציות מותקנות עם פעילות שהוגדרה בהם <intent-filter> שמוגדר עם ACTION=MAIN וגם CATEGORY=LAUNCHER או CATEGORY=LEANBACK_LAUNCHER בהטמעות של מכשירי טלוויזיה. הפונקציה 'בית' צריכה להיות המנגנון לתקציב של המשתמש הזה.
  • אמורות להיות לחצנים עבור פונקציות 'אחרונים' ו'הקודם'.

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

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

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

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

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

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

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

אם הטמעות במכשירים מציעות את פונקציית Assist, הן: * [C-4-1] חייבות להפוך את פונקציית Assist לנגישה באמצעות פעולה אחת (למשל: הקשה, לחיצה כפולה או תנועה) כאשר יש גישה למקשי ניווט אחרים. * [SR] מומלץ מאוד ללחוץ לחיצה ארוכה על הפונקציה Home כאינטראקציה ייעודית.

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

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

7.2.4. קלט מסך מגע

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

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

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

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

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

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

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

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

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

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

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

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

  • צריך להצהיר על תמיכה בדגל הפיצ'ר android.hardware.faketouch.

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

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

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

  • [C-2-1] חובה להצהיר על תמיכה ב-android.hardware.faketouch.
  • [C-2-2] חייבת להיות תמיכה במעקב ייחודי אחרי שני קלטים של מצביע בלתי תלוי או יותר.

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

  • [C-3-1] חובה להצהיר על תמיכה ב-android.hardware.faketouch.
  • [C-3-2] חייבת להיות תמיכה במעקב נפרד אחרי 5 (מעקב אחר יד של אצבעות) או יותר קלט של מצביע בנפרד.

7.2.6. תמיכה לבקרים לגיימינג

7.2.6.1. מיפויי לחצנים

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

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

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

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

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

4 MotionEvent

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

MotionEvent אחד

7.2.7. שלט רחוק

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

7.3. חיישנים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.3.1. מד תאוצה

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

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

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

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

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

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

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

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

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

7.3.2. מגנטומטר

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

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

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

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

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

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

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

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

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

7.3.3. GPS

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

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

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

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

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

    • [C-1-3] חייבת להיות אפשרות לקבוע את המיקום בטווח של 20 מטר, והמהירות היא בטווח של 0.5 מטר לשנייה, לפחות ב-95% מהזמן.
    • [C-1-4] חובה לעקוב בו-זמנית ולדווח באמצעות GnssStatus.Callback לפחות 8 לוויינים מקבוצת כוכבים אחת.
    • אמורה להיות אפשרות לעקוב בו-זמנית אחרי לפחות 24 לוויינים, מכמה קבוצות כוכבים (למשל, GPS + לפחות לוויין אחד, בייטו, גלילאו).
    • [C-1-5] חובה לדווח על יצירת הטכנולוגיה של GNSS דרך ה-API לבדיקה 'getGnssYearOfHardware'.
    • [SR] ממשיכים לספק פלט מיקום רגיל של GPS/GNSS במהלך שיחת טלפון בשעת חירום.
    • [SR] דיווח על מדידות של GNSS מכל קבוצות הכוכבים שבמעקב (כפי שדווח בהודעות GnssStatus), פרט ל-SBAS.
    • [SR] דיווח על AGC ותדירות המדידה של GNSS.
    • [SR] דיווח על כל הערכות הדיוק (כולל נושא, מהירות ואנכי) כחלק מכל מיקום של GPS או GNSS.
    • [SR] מומלץ מאוד לעמוד בדרישות רבות ככל האפשר בהתאם לדרישות החובה הנוספות עבור מכשירים שמדווחים על שנת '2016' או '2017' דרך Test API LocationManager.getGnssYearOfHardware().

אם הטמעות המכשיר כוללות מקלט GPS/GNSS ומדווחים על היכולת לאפליקציות באמצעות דגל התכונה android.hardware.location.gps ו-LocationManager.getGnssYearOfHardware() Test API מדווח על שנת 2016 ואילך, הן:

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

אם בהטמעות המכשיר יש מקלט GPS/GNSS ומדווחים על היכולת לאפליקציות באמצעות דגל התכונה android.hardware.location.gps ו-LocationManager.getGnssYearOfHardware() Test API מדווח על שנת 2017 ואילך:

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

אם בהטמעות המכשיר יש מקלט GPS/GNSS ודיווח על היכולת לאפליקציות באמצעות דגל התכונה android.hardware.location.gps ו-LocationManager.getGnssYearOfHardware() Test API מדווח על שנת 2018 ואילך:

  • [C-4-1] חובה להמשיך לספק פלט רגיל של GPS/GNSS לאפליקציות במהלך שיחת חירום פעילה ברשת (מבוססת-MS) ברשת.
  • [C-4-2] חובה לדווח על מיקומים ומדידות ל-API של ספק המיקום של GNSS.

7.3.4. ג'ירוסקופ

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

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

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

  • [C-1-1] חייבת להיות אפשרות לדווח על אירועים בתדירות של עד 50Hz לפחות.
  • [C-1-2] חובה להטמיע את החיישן של TYPE_GYROSCOPE וגם להטמיע את החיישן TYPE_GYROSCOPE_UNCALIBRATED.
  • [C-1-3] חייבת להיות יכולת למדוד שינויי כיוון של עד 1,000 מעלות לשנייה.
  • [C-1-4] חייבת להיות ברזולוציה של 12 סיביות או יותר והרזולוציה צריכה להיות 16 סיביות או יותר.
  • [C-1-5] חובה לפצות על הטמפרטורה.
  • [C-1-6] חובה לבצע כיול ותגמול בזמן השימוש, ולשמור על הפרמטרים של הפיצוי בין הפעלה מחדש של המכשיר.
  • [C-1-7] השונות חייבת להיות שונה מ- 1e-7 rad^2 / s^2 לכל Hz (שונות ל-Hz או rad^2 / s). השונות יכולה להשתנות בהתאם לקצב הדגימה, אבל חייבת להיות מוגבלת על ידי הערך הזה. במילים אחרות, אם מודדים את השונות של הג'יירו בקצב דגימה של 1 Hz, הוא לא אמור להיות גדול מ-1e-7 rad^2/s^2.
  • [SR] מומלץ מאוד להטמיע את החיישן SENSOR_TYPE_GYROSCOPE_UNCALIBRATED במכשירי Android קיימים וחדשים.
  • [SR] שגיאת כיול מומלץ מאוד לערך של פחות מ-0.01 rad/s כאשר המכשיר נייח בטמפרטורת החדר.
  • צריך לדווח על אירועים עד 200 Hz לפחות.

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

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

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

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

7.3.5. ברומטר

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

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

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

7.3.6. מדחום

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

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

  • [C-1-1] חובה להגדיר את הערך SENSOR_TYPE_AMBIENT_TEMPERATURE וצריך למדוד את הטמפרטורה בסביבה (בחדר או בתא הנוסעים) מהמקום שבו המשתמש מקיים אינטראקציה עם המכשיר במעלות צלזיוס.
  • [C-1-2] חייב להיות מוגדר כ-SENSOR_TYPE_TEMPERATURE.
  • [C-1-3] חובה למדוד את הטמפרטורה של המעבד (CPU) של המכשיר.
  • [C-1-4] אסור למדוד טמפרטורה אחרת.

חשוב לשים לב שסוג החיישן SENSOR_TYPE_TEMPERATURE הוצא משימוש ב-Android 4.0.

7.3.7. פוטומטר

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

7.3.8. חיישן קירבה

  • ייתכן שהטמעות במכשירים כוללות חיישן קירבה.

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

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

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

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

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

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

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

    • טווח המדידה חייב להיות בין 8G- ל-8G+. טווח המדידה צריך להיות בין 16G- ל-16G.
    • רזולוציית המדידה חייבת להיות לפחות 2048 LSB/g.
    • תדירות המדידה המינימלית חייבת להיות 12.5Hz או נמוכה יותר.
    • תדירות המדידה המקסימלית חייבת להיות 400Hz או יותר. היא צריכה לתמוך ב-SensorDirectChannel RATE_VERY_FAST.
    • הרעש במדידה חייב להיות נמוך מ-400 μg/לצאת.
    • החיישן הזה חייב להטמיע צורה שאינה במצב שינה, עם יכולת אגירת נתונים של 3,000 אירועי חיישנים לפחות.
    • צריכת החשמל באצווה חייבת להיות נמוכה מ-3 מגה-ואט.
    • [C-SR] מומלץ מאוד רוחב פס למדידה 3dB של לפחות 80% מתדר Nyquist וספקטרום של רעש לבן בתוך רוחב הפס הזה.
    • אמורה להיות האצה אקראית של הליכה אקראית של פחות מ-30 μg תמצאו נבדק בטמפרטורת החדר.
    • אמור להיות שינוי בהטיה לעומת טמפרטורה של ≤ +/- 1 mg/°C .
    • הקו המתאים ביותר צריך להיות לא ליניארי עם ערך של 0.5% או פחות, ושינוי הרגישות לעומת הטמפרטורה לא צריך להיות 0.03%/C°.
    • צריכה להיות רגישות חוצה-צירים של פחות מ-2.5 % ושונות של רגישות חוצה צירים נמוכה מ-0.2% בטווח טמפרטורות של פעולת מכשיר.

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

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

    • טווח המדידה חייב להיות בין -1000 ל- +1000 dps.
    • רזולוציית המדידה חייבת להיות לפחות 16 LSB/dps.
    • תדירות המדידה המינימלית חייבת להיות 12.5Hz או נמוכה יותר.
    • תדירות המדידה המקסימלית חייבת להיות 400Hz או יותר. היא צריכה לתמוך ב-SensorDirectChannel RATE_VERY_FAST.
    • הרעש במדידה חייב להיות נמוך מ-0.014°/s/לצאת.
    • [C-SR] מומלץ מאוד רוחב פס למדידה 3dB של לפחות 80% מתדר Nyquist וספקטרום של רעש לבן בתוך רוחב הפס הזה.
    • צריכה להיות הליכה אקראית של קצב של פחות מ- 0.001 °/s תמצאו Hz נבדקת בטמפרטורת החדר.
    • אמור להיות שינוי בהטיה לעומת טמפרטורה של ≤ +/- 0.05 °C/ s / °C.
    • צריך להיות שינוי ברגישות לעומת הטמפרטורה של 0.02% / °C.
    • הקו המתאים ביותר צריך להיות לא ליניארי, כלומר 0.2% או פחות.
    • צפיפות הרעש אמורה להיות ≤ 0.007 °/s/COLUMNHz.
    • כשהמכשיר לא נייח, אמורה להופיע שגיאת כיול בטווח טמפרטורות של 10 ~ 40°C מתחת ל-0.002 rad/s.
    • הרגישות ל-g צריכה להיות נמוכה מ-0.1°/s/g.
    • צריכה להיות רגישות חוצה-צירים של פחות מ-4.0%, ושמידת הרגישות בכל צירים תהיה נמוכה מ-0.3% בטווח הטמפרטורות של פעולת המכשיר.

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

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

    • טווח המדידה חייב להיות בין -900 ל- +900 μT.
    • רזולוציית המדידה חייבת להיות לפחות 5 LSB/uT.
    • תדירות המדידה המינימלית חייבת להיות 5Hz או נמוכה יותר.
    • תדירות המדידה המקסימלית חייבת להיות 50Hz או יותר.
    • הרעש במדידה חייב להיות נמוך מ-0.5 UT.

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

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

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

    • טווח המדידה חייב להיות בין 300 ל-1100 hPa.
    • רזולוציית המדידה חייבת להיות לפחות 80 LSB/hPa.
    • תדירות המדידה המינימלית חייבת להיות 1 Hz או נמוכה יותר.
    • תדירות המדידה המקסימלית חייבת להיות 10Hz או יותר.
    • הרעש במדידה חייב להיות נמוך מ-2 Pa/😂.
    • החיישן הזה חייב להטמיע צורה שאינה במצב שינה, עם יכולת אגירת נתונים של 300 אירועי חיישן לפחות.
    • צריכת החשמל באצווה חייבת להיות נמוכה מ-2 מגה-ואט.
  • [C-2-8] חייב להיות חיישן TYPE_GAME_ROTATION_VECTOR שעומד בתנאים הבאים:
    • החיישן הזה חייב להטמיע צורה שאינה במצב שינה, עם יכולת אגירת נתונים של 300 אירועי חיישן לפחות.
    • צריכת החשמל באצווה חייבת להיות נמוכה מ-4 מגה-ואט.
  • [C-2-9] חייב להיות חיישן TYPE_SIGNIFICANT_MOTION שעומד בתנאים הבאים:
    • צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי, ו-1.5 מגה-ואט כשהמכשיר נמצא בתנועה.
  • [C-2-10] חייב להיות חיישן TYPE_STEP_DETECTOR ש:
    • החיישן הזה חייב להטמיע צורה שאינה במצב שינה, עם יכולת אגירת נתונים של 100 אירועי חיישן לפחות.
    • צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי, ו-1.5 מגה-ואט כשהמכשיר נמצא בתנועה.
    • צריכת החשמל באצווה חייבת להיות נמוכה מ-4 מגה-ואט.
  • [C-2-11] חייב להיות חיישן TYPE_STEP_COUNTER ש:
    • צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי, ו-1.5 מגה-ואט כשהמכשיר נמצא בתנועה.
  • [C-2-12] חייב להיות חיישן TILT_DETECTOR ש:
    • צריכת החשמל חייבת להיות לא נמוכה מ-0.5 מגה-ואט כשהמכשיר סטטי, ו-1.5 מגה-ואט כשהמכשיר נמצא בתנועה.
  • [C-2-13] חותמת הזמן של האירוע הפיזי של אותו אירוע פיזי שדווחה באמצעות מד התאוצה, הג'ירוסקופ והמגנטומטר חייבים להיות בטווח של 2.5 אלפיות שנייה זה מזה. חותמת הזמן של האירוע של אותו אירוע פיזי שדווחה על ידי מד התאוצה והג'ירוסקופ צריכה להיות בטווח של 0.25 אלפיות שנייה זה מזה.
  • [C-2-14] חותמות הזמן של אירועים מחיישן הג'יירוסקופ צריכות להיות באותו בסיס זמן כמו מערכת המשנה של המצלמה, ותוך אלפיות שנייה אחת משגיאה.
  • [C-2-15] חובה לשלוח דגימות לאפליקציות בתוך 5 אלפיות שנייה מהמועד שבו הנתונים זמינים באפליקציה בכל אחד מהחיישנים הפיזיים שלמעלה.
  • [C-2-16] אסור שצריכת החשמל תהיה גבוהה מ-0.5 מגה-ואט כשהמכשיר סטטי ו-2.0 מגה-ואט כשהמכשיר בתנועה כאשר שילוב כלשהו של החיישנים הבאים מופעל:
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] עשויים להיות חיישן TYPE_PROXIMITY, אבל אם יש חיישן כזה, חייבת להיות בו יכולת מינימלית של מאגר נתונים זמני של 100 אירועי חיישן.

שימו לב שכל דרישות צריכת החשמל בסעיף הזה לא כוללות את צריכת החשמל של מעבד האפליקציות. זה כולל את ההספק הנובע מכל שרשרת החיישנים – החיישן, מעגל תומך, כל מערכת ייעודית לעיבוד חיישנים וכו'.

אם ההטמעות במכשירים כוללות תמיכה ישירה בחיישנים:

  • [C-3-1] חובה להצהיר בצורה נכונה על תמיכה בסוגי ערוצים ישירים ושיעורי דיווח ישיר דרך ה-API של isDirectChannelTypeSupported ושל getHighestDirectReportRateLevel.
  • [C-3-2] חייבת לתמוך לפחות באחד משני סוגי הערוצים הישירים של חיישנים בכל החיישנים שמצהירים על תמיכה בערוץ ישיר של חיישנים.
  • צריכה לתמוך בדיווח על אירועים דרך ערוץ ישיר של חיישן לחיישן הראשי (וריאנט שלא נמצא במצב שינה) מהסוגים הבאים:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. חיישנים ביומטריים

7.3.10.1. חיישני טביעות אצבע

אם הטמעתם במכשיר מסך נעילה מאובטח:

  • צריכה לכלול חיישן טביעות אצבע.

אם ההטמעות במכשירים כוללות חיישן טביעות אצבע והופכות את החיישן לזמין לאפליקציות צד שלישי:

  • [C-1-1] חובה להצהיר על תמיכה בתכונה android.hardware.fingerprint.
  • [C-1-2] חובה להטמיע באופן מלא את ה-API התואם כפי שמתואר בתיעוד של Android SDK.
  • [C-1-3] שיעור קבלה שגוי חייב להיות נמוך מ-0.002%.
  • [SR] מומלץ מאוד ששיעור הקבלה של זיוף ומתחזה לא יעלה על 7%.
  • [C-1-4] חובה לציין שהמצב הזה עלול להיות פחות מאובטח מקוד אימות, קו ביטול נעילה או סיסמה חזקים, ולפרט באופן ברור את הסיכונים להפעלתו אם שיעור הסכמות של הזיוף וההתחזות גבוה מ-7%.
  • [C-1-5] חובה להגביל את הקצב של יצירת הבקשות למשך 30 שניות לפחות לאחר חמש ניסיונות שווא לאימות באמצעות טביעת אצבע.
  • [C-1-6] האפליקציה חייבת לכלול הטמעה של מאגר מפתחות שמגובה בחומרה, וצריך לבצע את ההתאמה של טביעת האצבע בסביבת ביצוע מהימנה (TEE) או על שבב עם ערוץ מאובטח ל-TEE.
  • [C-1-7] כל הנתונים של טביעות האצבע שניתן לזהות צריכים להיות מוצפנים ומאומתים באמצעות קריפטוגרפיה, כך שלא ניתן יהיה לאסוף אותם, לקרוא אותם או לשנות אותם מחוץ לאזור TEE, או שבב עם ערוץ מאובטח ל-TEE, כפי מתועד בהנחיות ההטמעה באתר של פרויקט הקוד הפתוח של Android.
  • [C-1-8] חובה למנוע הוספה של טביעת אצבע בלי ליצור קודם שרשרת אמון על ידי דרישת המשתמש לאשר קיים או להוסיף פרטי כניסה חדשים למכשיר (קוד אימות/קו ביטול נעילה/סיסמה) שמאובטחים על ידי TEE. ההטמעה של פרויקט קוד פתוח של Android מספקת את המנגנון שב-framework כדי לעשות זאת.
  • [C-1-9] אסור לאפשר לאפליקציות של צד שלישי להבחין בין טביעות אצבע בודדות.
  • [C-1-10] MUST יפעל בהתאם לסימון DevicePolicyManager.KEYGUARD_DISABLE_FINGERprint.
  • [C-1-11] כשמשדרגים מגרסה ישנה יותר מ-Android 6.0, צריך להעביר או להסיר את נתוני טביעות האצבע באופן מאובטח כדי לעמוד בדרישות שפורטו למעלה.
  • [C-1-12] חובה להסיר לחלוטין את כל נתוני טביעות האצבע המזהים של המשתמש כשמסירים את חשבון המשתמש (כולל איפוס להגדרות המקוריות).
  • [C-1-13] אסור לאפשר למעבד האפליקציות גישה לא מוצפנת לנתוני טביעות אצבע שניתן לזהות או לנתונים שנגזרים מהם (למשל הטמעות).
  • [SR] מומלץ מאוד ששיעור דחייה שקרי של פחות מ-10% יהיה נמוך מ-10%, כפי שנמדד במכשיר.
  • [SR] מומלץ מאוד שזמן האחזור יהיה פחות משנייה אחת, שנמדד מרגע המגע בחיישן טביעות האצבע ועד לביטול נעילת המסך, עבור אצבע רשומה אחת.
  • יש להשתמש בסמל טביעת האצבע של Android שסופק בפרויקט הקוד הפתוח של Android.
7.3.10.2. חיישנים ביומטריים אחרים

אם הטמעתם במכשירים שונים חיישן ביומטרי אחד או יותר שלא מבוסס על טביעות אצבע והם יהיו זמינים לאפליקציות צד שלישי:

  • [C-1-1] שיעור קבלה שגוי חייב להיות גבוה מ-0.002%.
  • [C-SR] מומלץ מאוד ששיעור ההסכמה של זיוף ומתחזה לא יעלה על 7%.
  • [C-1-2] חובה לציין שהמצב הזה עלול להיות פחות מאובטח מקוד אימות, קו ביטול נעילה או סיסמה חזקים, ולפרט באופן ברור את הסיכונים להפעלתו אם שיעור הסכמות של הזיוף וההתחזות גבוה מ-7%.
  • [C-1-3] חובה להגביל את הקצב של יצירת הבקשות למשך 30 שניות לפחות לאחר חמישה ניסיונות כושלים לאימות ביומטרי – כאשר ניסוי שקרי הוא בעל איכות צילום הולמת (ACQUIRED_GOOD) שלא תואם לנתונים ביומטריים רשומים
  • [C-1-4] האפליקציה חייבת לכלול הטמעה של מאגר מפתחות שמגובה על ידי חומרה, ולבצע את ההתאמה הביומטרית בסביבת TEE או על שבב דרך ערוץ מאובטח לסביבת TEE.
  • [C-1-5] כל הנתונים המזהים חייבים להיות מוצפנים ומאומתים באופן קריפטוגרפי, כך שלא ניתן יהיה להשיג אותם, לקרוא אותם או לשנות אותם מחוץ ל-TEE, או שבב עם ערוץ מאובטח ל-TEE, כפי מתועד בהנחיות ההטמעה באתר של פרויקט הקוד הפתוח של Android.
  • [C-1-6] חובה למנוע הוספה של מידע ביומטרי חדש בלי ליצור קודם שרשרת אמון על ידי כך שהמשתמש יצטרך לאשר קיים או להוסיף פרטי כניסה חדשים למכשיר (קוד אימות/תבנית/סיסמה) שמאובטחים על ידי צוות TEE. ההטמעה של פרויקט קוד פתוח של Android מספקת את המנגנון שבמסגרת כדי לעשות זאת.
  • [C-1-7] אסור לאפשר לאפליקציות של צד שלישי להבחין בין מזהים ביומטריים.
  • [C-1-8] חובה ליישם את הדגל הספציפי של המידע הביומטרי הזה (למשל: DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE או DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
  • [C-1-9] חובה להסיר לחלוטין את כל הנתונים הביומטריים שניתנים לזיהוי של המשתמש כשמסירים את החשבון של המשתמש (כולל דרך איפוס להגדרות המקוריות).
  • [C-1-10] אסור לאפשר למעבד האפליקציות גישה לא מוצפנת לנתונים ביומטריים שניתנים לזיהוי או לנתונים שנגזרים מהם (כמו הטמעות) מחוץ להקשר של סביבת TEE.
  • [C-SR] מומלץ מאוד ששיעור הדחייה השגוי יהיה נמוך מ-10%, כפי שנמדד במכשיר.
  • [C-SR] מומלץ מאוד שזמן האחזור יהיה פחות משנייה אחת, שנמדד מרגע זיהוי המידע הביומטרי ועד לביטול נעילת המסך, עבור כל מידע ביומטרי רשום.

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. סטטוס הנהיגה

הדרישה הזו הוצאה משימוש.

7.3.11.4. מהירות הגלגלים

למידע על דרישות ספציפיות למכשיר, ראו סעיף 2.5.1.

7.3.11.5. בלם חנייה

למידע על דרישות ספציפיות למכשיר, ראו סעיף 2.5.1.

7.3.12. חיישן תנוחה

הטמעות מכשירים:

  • MAY תמיכה בחיישן תנוחה עם 6 דרגות חופש.

אם יישומים של מכשירים תומכים בחיישן תנוחת מיקום עם 6 דרגות חופש:

  • [C-1-1] חובה להטמיע את החיישן TYPE_POSE_6DOF ולדווח עליו.
  • [C-1-2] חייב להיות מדויק יותר מהווקטור הסיבוב לבדו.

7.4. קישוריות נתונים

7.4.1. טלפוניה

המונח 'טלפוניה' כפי שנעשה בו שימוש בממשקי ה-API של Android והמסמך הזה מתייחס באופן ספציפי לחומרה שקשורה לביצוע שיחות קוליות ולשליחת הודעות SMS דרך רשת GSM או CDMA. השיחות הקוליות האלה לא בהכרח יעברו בין חבילות, אבל הן מיועדות ל-Android שנחשבות לבלתי תלויות בקישוריות נתונים שעשויות להיות מוטמעות באמצעות אותה רשת. במילים אחרות, הפונקציונליות וממשקי ה-API של Android ב-Android מתייחסים באופן ספציפי לשיחות קוליות ול-SMS. לדוגמה, יישומים של מכשירים שלא יכולים לבצע שיחות או לשלוח/לקבל הודעות SMS אינם נחשבים למכשיר טלפוניה, גם אם הם משתמשים ברשת סלולרית לחיבור הנתונים.

  • ניתן להשתמש ב-Android MAY במכשירים שלא כוללים חומרת טלפון. כלומר, מערכת Android תואמת למכשירים שאינם טלפונים.

אם ההטמעות של המכשירים כוללות טלפוניה מסוג GSM או CDMA, הן:

  • [C-1-1] חובה להצהיר על דגל הפיצ'ר android.hardware.telephony וסימונים של תכונות משנה אחרות בהתאם לטכנולוגיה.
  • [C-1-2] חייבים להטמיע תמיכה מלאה ב-API בטכנולוגיה הזו.

אם ההטמעות של מכשירים לא כוללות חומרת טלפון:

  • [C-2-1] חובה להטמיע את כל ממשקי ה-API כללא תפעול.
7.4.1.1. תאימות לחסימת מספרים

אם הטמעות במכשירים מדווחות על android.hardware.telephony feature, הן:

  • [C-1-1] חייבת לכלול תמיכה בחסימת מספרים
  • [C-1-2] חובה להטמיע באופן מלא את BlockedNumberContract ואת ה-API התואם, כפי שמתואר במסמכי התיעוד של ה-SDK.
  • [C-1-3] חובה לחסום את כל השיחות וההודעות ממספר טלפון ב-'BlockedNumberProvider', ללא אינטראקציה עם האפליקציות. יוצא הדופן היחיד הוא כאשר חסימת המספרים מבוטלת באופן זמני, כפי שמתואר במסמכי התיעוד של ה-SDK.
  • [C-1-4] אסור לכתוב לספק יומן השיחות של הפלטפורמה לגבי שיחה שנחסמה.
  • [C-1-5] אסור לכתוב לספק הטלפוניה על הודעה חסומה.
  • [C-1-6] חובה להטמיע ממשק משתמש חסום לניהול מספרים, שנפתח באמצעות Intent שהוחזר על ידי השיטה TelecomManager.createManageBlockedNumbersIntent().
  • [C-1-7] אסור לאפשר למשתמשים משניים לראות או לערוך את המספרים החסומים במכשיר, כי פלטפורמת Android מניחה שלמשתמש הראשי יש שליטה מלאה על שירותי הטלפוניה, אירוע אחד, במכשיר. כל ממשקי המשתמש הקשורים לחסימה חייבים להיות מוסתרים עבור משתמשים משניים, והרשימה החסומה עדיין חייבת להיות נכללת.
  • המכשיר אמור להעביר את המספרים החסומים לספק לאחר עדכון המכשיר ל-Android 7.0.
7.4.1.2. API של Telecom

אם הטמעות המכשירים ידווחו על android.hardware.telephony, הן:

  • [C-1-1] חייבת לתמוך בממשקי ה-API של ConnectionService שמתוארים ב-SDK.
  • [C-1-2] חובה להציג שיחה נכנסת חדשה ולאפשר למשתמש לאשר או לדחות את השיחה הנכנסת כשהמשתמש נמצא בשיחה פעילה שלא תומכת בתכונת ההשהיה שצוינה דרך CAPABILITY_SUPPORT_HOLD.

  • [C-SR] מומלץ מאוד להודיע למשתמש שמענה לשיחה נכנסת יגרום להפסקת השיחה הפעילה.

    הטמעת ה-AOSP עומדת בדרישות האלה באמצעות התראה 'שימו לב' שמציינת למשתמש שמענה לשיחה הנכנסת יגרום להסרה של השיחה השנייה.

  • [C-SR] מומלץ מאוד לטעון מראש את אפליקציית החייגן שמוגדרת כברירת מחדל, שבה מופיעה רשומה ביומן השיחות והשם של אפליקציה של צד שלישי ביומן השיחות שלה, כשאפליקציית הצד השלישי מגדירה את מפתח התוספות EXTRA_LOG_SELF_MANAGED_CALLS ב-PhoneAccount שלה ל-true.

  • [C-SR] מומלץ מאוד לטפל באירועי KEYCODE_MEDIA_PLAY_PAUSE ו-KEYCODE_HEADSETHOOK של אוזניות האודיו בממשקי ה-API של android.telecom כמו שמפורט בהמשך:
    • קוראים לפונקציה Connection.onDisconnect() כשמזוהה לחיצה קצרה על האירוע המרכזי במהלך שיחה פעילה.
    • קוראים לפונקציה Connection.onAnswer() כשמזוהה לחיצה קצרה על האירוע המרכזי במהלך שיחה נכנסת.
    • קוראים לפונקציה Connection.onReject() כשמזוהה לחיצה ארוכה על האירוע המרכזי במהלך שיחה נכנסת.
    • החלפת מצב ההשתקה של CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

הטמעות מכשירים:

  • היא צריכה לכלול תמיכה עבור צורה אחת או יותר של 802.11.

אם הטמעות המכשירים כוללות תמיכה ב-802.11 וחושפות את הפונקציונליות לאפליקציית צד שלישי:

  • [C-1-1] חובה להטמיע את Android API התואם.
  • [C-1-2] חובה לדווח על הדגל של תכונת החומרה android.hardware.wifi.
  • [C-1-3] חובה להטמיע את multicast API כפי שמתואר במסמכי התיעוד של ה-SDK.
  • [C-1-4] חובה לתמוך ב-Multicast DNS (mDNS) ואסור לסנן חבילות mDNS (224.0.0.251) בכל זמן הפעולה, כולל:
    • גם כשהמסך לא במצב פעיל.
    • להטמעות של מכשירי Android TV, גם במצב המתנה.
  • [C-1-5] אסור להתייחס לקריאה ל-method של ה-API של WifiManager.enableNetwork() בתור אינדיקציה מספקת לשינוי של ה-Network הפעיל הנוכחי, שמשמש כברירת מחדל לתנועת גולשים של אפליקציות, שמוחזרת באמצעות שיטות API של ConnectivityManager כמו getActiveNetwork ו-registerDefaultNetworkCallback. במילים אחרות, הם עשויים להשבית את הגישה לאינטרנט שמסופקת על ידי ספק רשת אחר (למשל, נתונים לנייד) רק אם הוא מוודא שרשת ה-Wi-Fi מספקת גישה לאינטרנט.
  • [C-SR] מומלץ מאוד לבצע הערכה מחדש של הגישה לאינטרנט דרך Network כשמתבצעת קריאה ל-API של ConnectivityManager.reportNetworkConnectivity(). אחרי שההערכה קובעת שמכשיר Network הנוכחי כבר לא מספק גישה לאינטרנט, צריך לעבור לרשת זמינה אחרת (למשל, חבילת גלישה) שמספקת גישה לאינטרנט.
  • [C-SR] מומלץ מאוד לבצע רנדומיזציה של כתובת ה-MAC של המקור ומספר הרצף של מסגרות בקשות הבדיקה, פעם אחת בתחילת כל סריקה, בזמן ש-STA מנותק.
    • לכל קבוצה של מסגרות בקשת בדיקה שמורכבת מסריקה אחת, יש להשתמש בכתובת MAC עקבית אחת (אסור להגדיר כתובת MAC אקראית באמצע הסריקה).
    • מספר הרצף של בקשת גשושיות צריך לחזור על עצמו כרגיל (ברציפות) בין בקשות גשול בסריקה.
    • מספר הרצף של בקשת גשושית צריך להיות אקראי בין בקשת גשול האחרונה בסריקה לבין בקשת גשול הראשונה בסריקה הבאה.
  • [C-SR] מומלץ מאוד להשתמש ב-STA מנותקות, כדי לאפשר רק את הרכיבים הבאים במסגרות של בקשות הבדיקה:
    • קבוצת פרמטרים של SSID (0)
    • קבוצת פרמטרים של DS (3)

אם הטמעות במכשירים תומכים ב-Wi-Fi ומשתמשים ב-Wi-Fi לסריקת מיקום:

  • [C-2-1] חובה לאפשר למשתמשים להפעיל או להשבית את הערך שמוקרא באמצעות שיטת ה-API WifiManager.isScanAlwaysAvailable.
7.4.2.1. Wi-Fi ישיר

הטמעות מכשירים:

  • אמורה לכלול תמיכה ב-Wi-Fi ישיר (Wi-Fi מקצה לקצה).

אם הטמעות המכשירים כוללות תמיכה ב-Wi-Fi ישיר:

  • [C-1-1] חובה להטמיע את Android API התואם כפי שמתואר במסמכי התיעוד של ה-SDK.
  • [C-1-2] חובה לדווח על תכונת החומרה android.hardware.wifi.direct.
  • [C-1-3] חייבת להיות תמיכה בפעולת Wi-Fi רגילה.
  • [C-1-4] חובה לתמוך בפעולות Wi-Fi ו-Wi-Fi ישיר בו-זמנית.

הטמעות מכשירים:

אם הטמעות המכשירים כוללות תמיכה ב-TDLS וב-TDLS מופעל באמצעות ה-Wi-FiManager API, הן:

  • [C-1-1] חובה להצהיר על תמיכה ב-TDLS עד WifiManager.isTdlsSupported.
  • יש להשתמש ב-TDLS רק כאשר זה אפשרי ומועיל.
  • אמור להיות שימוש בשיטה היוריסטית או לא להשתמש ב-TDLS אם הביצועים שלו נמוכים יותר מאשר דרך נקודת הגישה ל-Wi-Fi.
7.4.2.3. עם חיבור ל-Wi-Fi

הטמעות מכשירים:

אם הטמעות המכשיר כוללות תמיכה ב-Wi-Fi Aware וחושפים את הפונקציונליות לאפליקציות צד שלישי:

  • [C-1-1] חובה להטמיע את ממשקי ה-API של WifiAwareManager כפי שמתואר במסמכי התיעוד של ה-SDK.
  • [C-1-2] חובה להצהיר על דגל התכונה android.hardware.wifi.aware.
  • [C-1-3] חובה לתמוך בפעולות Wi-Fi ו-Wi-Fi Aware בו-זמנית.
  • [C-1-4] הכתובת של ממשק הניהול עם מודעות ל-Wi-Fi חייבת תפעל באקראי במרווחים של לא יותר מ-30 דקות ובכל פעם ש-Wi-Fi Aware מופעל.

אם הטמעות המכשיר כוללות תמיכה ב-Wi-Fi Aware ובמיקום Wi-Fi, כפי שמתואר בסעיף 7.4.2.5 וחושפות את הפונקציות האלה לאפליקציות צד שלישי:

7.4.2.4. Passpoint ל-Wi-Fi

הטמעות מכשירים:

אם הטמעות המכשירים כוללות תמיכה ב-Wi-Fi Passpoint:

  • [C-1-1] חובה להטמיע את ממשקי ה-API WifiManager שקשורים ל-Passpoint, כמו שמתואר במסמכי התיעוד של ה-SDK.
  • [C-1-2] חייבת לתמוך בתקן IEEE 802.11u, שקשור ספציפית לגילוי ולבחירה של רשת, כגון שירות פרסום כללי (GAS) ופרוטוקול Access Network Query Protocol (ANQP).

לעומת זאת, אם הטמעות המכשירים לא כוללות תמיכה ב-Wi-Fi Passpoint:

  • [C-2-1] ההטמעה של ממשקי ה-API מסוג WifiManager שקשורים ל-Passpoint חייבת לגרום להצגת UnsupportedOperationException.
7.4.2.5. מיקום Wi-Fi (שעת הלוך ושוב של Wi-Fi – RTT)

הטמעות מכשירים:

אם הטמעות המכשיר כוללות תמיכה במיקום Wi-Fi וחושפים את הפונקציונליות לאפליקציות צד שלישי:

  • [C-1-1] חובה להטמיע את ממשקי ה-API של WifiRttManager כפי שמתואר במסמכי התיעוד של ה-SDK.
  • [C-1-2] חובה להצהיר על דגל התכונה android.hardware.wifi.rtt.
  • [C-1-3] כתובת ה-MAC של המקור חייבת להיות אקראית לכל רצף RTT שמתבצע בזמן שממשק ה-Wi-Fi שבו מופעל RTT לא משויך לנקודת גישה.

7.4.3. ‫Bluetooth

אם בהטמעות של המכשיר יש תמיכה בפרופיל Bluetooth Audio, הן:

  • צריכה לתמוך ברכיבי קודק אודיו מתקדמים ובקודקי אודיו של Bluetooth (למשל LDAC).

אם בהטמעות במכשירים יש תמיכה ב-HFP, ב-A2DP וב-AVRCP:

  • צריכה לתמוך בלפחות 5 מכשירים מחוברים בסך הכול.

אם בהטמעות במכשירים מוצהר על התכונה android.hardware.vr.high_performance, הן:

  • [C-1-1] חייבת להיות תמיכה ב-Bluetooth 4.2 ובתוסף אורך נתונים LE של Bluetooth LE.

ב-Android יש תמיכה ב-Bluetooth וב-Bluetooth עם צריכת אנרגיה נמוכה.

אם ההטמעות של המכשירים כוללות תמיכה ב-Bluetooth וב-Bluetooth עם צריכת אנרגיה נמוכה, הן:

  • [C-2-1] חובה להצהיר על תכונות הפלטפורמה הרלוונטיות (android.hardware.bluetooth ו-android.hardware.bluetooth_le בהתאמה) ולהטמיע את ממשקי ה-API של הפלטפורמה.
  • עליך להטמיע פרופילים רלוונטיים של Bluetooth כמו A2DP, AVRCP, OBEX, HFP וכו', בהתאם למכשיר.

אם ההטמעות במכשירים כוללות תמיכה ב-Bluetooth Low Energy:

  • [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 דקות, ולבצע רוטציה לכתובת בזמן הקצוב כדי להגן על פרטיות המשתמש.

אם בהטמעות של מכשירים תומכים ב-Bluetooth LE ומשתמשים ב-Bluetooth LE לסריקת מיקום, הם:

  • [C-4-1] חובה לספק למשתמשים אפשרות להפעיל או להשבית את הערך שנקרא דרך System API BluetoothAdapter.isBleScanAlwaysAvailable().

7.4.4. תקשורת מטווח קצר

הטמעות מכשירים:

  • היא צריכה לכלול משדר וחומרה קשורה לתקשורת מטווח קצר (NFC).
  • [C-0-1] חובה להטמיע ממשקי API של android.nfc.NdefMessage ו-android.nfc.NdefRecord, גם אם הם לא כוללים תמיכה ב-NFC או אם הם לא כוללים בהצהרה על התכונה android.hardware.nfc, כי המחלקות מייצגות פורמט ייצוג נתונים שאינו תלוי בפרוטוקול.

אם ההטמעות של מכשירים כוללות חומרת NFC ומתכננים להפוך אותה לזמינה לאפליקציות צד שלישי, הן:

  • [C-1-1] חובה לדווח על התכונה android.hardware.nfc באמצעות ה-method android.content.pm.PackageManager.hasSystemFeature().
  • חייבת להיות יכולת לקרוא ולכתוב הודעות NDEF באמצעות תקני NFC הבאים:
  • [C-1-2] חייבת להיות יכולת לפעול כקורא/כותב בפורום NFC (כפי שמוגדר במפרט הטכני NFCForum-TS-DigitalProtocol-1.0) באמצעות תקני NFC הבאים:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • סוגי התגים של פורום NFC 1, 2, 3, 4, 5 (הוגדרו על ידי פורום NFC)

  • [SR] מומלץ מאוד לקרוא ולכתוב הודעות NDEF וגם נתונים גולמיים באמצעות תקני NFC הבאים. לתשומת ליבכם: בעוד שתקני ה-NFC מצויינים כ'מומלץ מאוד', הגדרת התאימות לגרסה עתידית מתוכננת לשנות אותם ל'חובה'. בגרסה הזו התקנים האלה הם אופציונליים, אבל הם יידרשו בגרסאות עתידיות. אנחנו ממליצים מאוד שמכשירים קיימים וחדשים שבהם פועלת הגרסה הזו של Android יעמדו בדרישות האלה עכשיו, כדי שניתן יהיה לשדרג לגרסאות עתידיות של הפלטפורמה.

  • [C-1-3] חייבת להיות יכולת להעביר ולקבל נתונים באמצעות התקנים והפרוטוקולים הבאים מקצה לקצה:

  • [C-1-4] חייבת לכלול תמיכה ב-Android Beam ו-צריך להפעיל את Android Beam כברירת מחדל.
  • [C-1-5] חייבת להיות אפשרות לשלוח ולקבל באמצעות Android Beam, כאשר Android Beam מופעל או מופעל מצב קנייני אחר של NFC P2p.
  • [C-1-6] חובה להטמיע את שרת ברירת המחדל של SNEP. הודעות NDEF חוקיות שהתקבלו בשרת SNEP כברירת מחדל חייבות להישלח לאפליקציות באמצעות Intent android.nfc.ACTION_NDEF_DISCOVERED. כשמשביתים את Android Beam בהגדרות, אסור להשבית את השליחה של הודעת NDEF נכנסת.
  • [C-1-7] חובה לפעול בהתאם לכוונה של android.settings.NFCSHARING_SETTINGS להציג הגדרות שיתוף באמצעות NFC.
  • [C-1-8] חובה להטמיע את שרת ה-NPP. העיבוד של הודעות שהתקבלו דרך שרת ה-NPP חייב להיות זהה לעיבוד של שרת ברירת המחדל של SNEP.
  • [C-1-9] חובה להטמיע לקוח SNEP ולנסות לשלוח P2P NDEF לשרת ברירת המחדל כש-Android Beam מופעל. אם לא נמצא שרת SNEP שמוגדר כברירת מחדל, הלקוח חייב לנסות לשלוח לשרת NPP.
  • [C-1-10] חובה לאפשר לפעילויות בחזית להגדיר את הודעת ה-P2P NDEF היוצאת באמצעות android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback ו-android.nfc.NfcAdapter.enableForegroundNdefPush.
  • צריך להשתמש בתנועה או באישור במסך, כמו 'Touch to Beam', לפני שליחה של הודעות P2P NDEF יוצאות.
  • [C-1-11] המכשיר חייב לתמוך בהעברה של חיבור NFC ל-Bluetooth כשהמכשיר תומך בדחיפה של אובייקט Bluetooth.
  • [C-1-12] חייבת לתמוך בהעברת החיבור ל-Bluetooth במהלך השימוש ב-android.nfc.NfcAdapter.setBeamPushUris, על ידי הטמעת המפרטים של 'שיתוף חיבור גרסה 1.2' ו'התאמה פשוטה של Bluetooth באמצעות NFC גרסה 1.0' מהפורום של NFC. יישום כזה חייב להטמיע את שירות LLCP המסירה עם שם השירות “urn:nfc:sn:handover” לצורך החלפה של בקשת ההעברה/בחירת רשומות ב-NFC, ועליו להשתמש בפרופיל הדחיפה לאובייקט Bluetooth כדי לבצע בפועל את העברת הנתונים מ-Bluetooth. מסיבות מדור קודם (כדי לשמור על תאימות למכשירי Android 4.1), ההטמעה עדיין אמורה לקבל בקשות SNEP GET לצורך החלפת בקשת ההעברה או הרשומות שנבחרו ב-NFC. עם זאת, היישום עצמו לא אמור לשלוח בקשות SNEP GET לביצוע מסירת חיבור.
  • [C-1-13] חובה לבצע סקר לכל הטכנולוגיות הנתמכות במצב גילוי NFC.
  • המכשיר צריך להיות במצב גילוי NFC בזמן שהמכשיר לא במצב שינה, כשהמסך פעיל ומסך הנעילה לא נעול.
  • צריכה להיות יכולת לקרוא את הברקוד ואת כתובת ה-URL (אם מקודדים) של מוצרי ברקוד Thinfilm NFC.

שימו לב שהקישורים שזמינים לציבור לא זמינים במפרטים של הפורום של JIS, ISO ו-NFC שמצוינים למעלה.

מערכת Android כוללת תמיכה במצב NFC Host Card Emulation (HCE).

אם הטמעות המכשיר כוללות ערכת שבבים של בקר NFC שמסוגלת לפעול ב-HCE (ל-NfcA ו/או ל-NfcB) ותומכות בניתוב של מזהה אפליקציה (AID), הן:

  • [C-2-1] חובה לדווח על קבוע התכונה android.hardware.nfc.hce.
  • [C-2-2] חייבת להיות תמיכה בממשקי API של NFC HCE כפי שמוגדר ב-Android SDK.

אם הטמעות המכשיר כוללות ערכת שבבים של בקר NFC שמסוגלת להשתמש ב-HCE עבור NfcF, ומטמיעות את התכונה באפליקציות צד שלישי:

אם הטמעות המכשירים כוללות תמיכה כללית ב-NFC כפי שמתואר בקטע הזה ותומכות בטכנולוגיות MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF on MIFARE Classic) בתפקיד הקורא/הכתיבה:

  • [C-4-1] חובה להטמיע את ממשקי ה-API התואמים של Android כפי שתועד על ידי Android SDK.
  • [C-4-2] חובה לדווח על התכונה com.nxp.mifare מהשיטה android.content.pm.PackageManager.hasSystemFeature(). חשוב לשים לב שזו לא תכונה רגילה של Android, ולכן היא לא מופיעה כקבוע במחלקה android.content.pm.PackageManager.

7.4.5. קיבולת רשת מינימלית

הטמעות מכשירים:

  • [C-0-1] חייבת לכלול תמיכה בסוג אחד או יותר של רשתות נתונים. באופן ספציפי, הטמעות במכשירים חייבות לכלול תמיכה בתקן נתונים אחד לפחות שיכול להגיע ל- 200 Kbit לשנייה או יותר. דוגמאות לטכנולוגיות שעומדות בדרישה הזו כוללות את EDGE, HSPA, EV-DO, 802.11g, אתרנט ו-Bluetooth PAN.
  • היא צריכה לכלול גם תמיכה בתקן נפוץ אחד לפחות של נתונים אלחוטיים, כמו 802.11 (Wi-Fi), כאשר תקן רשת פיזי (כמו אתרנט) הוא חיבור הנתונים הראשי.
  • ייתכן שתטמיעו יותר מצורה אחת של קישוריות נתונים.
  • [C-0-2] חייבת לכלול סטאק רשתות של IPv6 ולתמוך בתקשורת IPv6 באמצעות ממשקי ה-API המנוהלים, כגון java.net.Socket ו-java.net.URLConnection, וכן בממשקי ה-API המקוריים, כמו שקעי AF_INET6.
  • [C-0-3] חייבים להפעיל את IPv6 כברירת מחדל.
  • חייבים לוודא שתקשורת IPv6 אמינה כמו IPv4, לדוגמה:
    • [C-0-4] חייבים לשמור על קישוריות IPv6 במצב 'נמנום'.
    • [C-0-5] אסור שהגבלת קצב של יצירת הבקשות תגרום לביטול של קישוריות IPv6 למכשיר בכל רשת תואמת IPv6 שמשתמשת ב-RA משך חיים של 180 שניות לפחות.
  • [C-0-6] חובה לספק אפליקציות של צד שלישי עם קישוריות IPv6 ישירה לרשת כאשר הן מחוברות לרשת IPv6, ללא כל צורה של כתובת או תרגום יציאה המתרחשות באופן מקומי במכשיר. גם ממשקי ה-API המנוהלים כמו Socket#getLocalAddress או Socket#getLocalPort) וגם ממשקי NDK כמו getsockname() או IPV6_PKTINFO חייבים להחזיר את כתובת ה-IP והיציאה שמשמשת בפועל לשליחה ולקבלה של חבילות ברשת.

הרמה הנדרשת של תמיכה ב-IPv6 תלויה בסוג הרשת, כפי שמוצג בדרישות הבאות.

אם הטמעות במכשירים תומכים ב-Wi-Fi:

  • [C-1-1] חייבת לתמוך בפעולה כפולה בסטאק וב-IPv6 בלבד ב-Wi-Fi.

אם בהטמעות במכשירים תומכים באתרנט:

  • [C-2-1] חייבת להיות תמיכה בפעולה של מקבץ כפול באתרנט.

אם הטמעות במכשירים תומכים בחבילת הגלישה, הן:

  • אמורה לתמוך בפעולה IPv6 (IPv6 בלבד ואולי גם סטאק כפול) ברשת סלולרית.

אם הטמעות במכשירים תומכים ביותר מסוג רשת אחד (למשל, ב-Wi-Fi ובחבילת הגלישה), הן:

  • [C-3-1] המכשיר חייב לעמוד בו-זמנית בדרישות שצוינו למעלה בכל רשת, כשהמכשיר מחובר לכמה סוגי רשת.

7.4.6. הגדרות סנכרון

הטמעות מכשירים:

  • [C-0-1] הגדרת הסנכרון האוטומטי הראשי חייבת להיות מופעלת כברירת מחדל, כדי שהשיטה getMasterSyncAutomatically() תחזיר את הערך 'true'.

7.4.7. חסכונית בנתונים

אם הטמעות המכשירים כוללות חיבור עם חיוב לפי שימוש בנתונים:

  • [SR] מומלץ מאוד לספק את מצב חוסך הנתונים (Data Saver).

אם הטמעות במכשירים מספקות את מצב חוסך הנתונים, הן:

אם הטמעות במכשירים לא מספקות את מצב חוסך הנתונים, הן:

  • [C-2-1] חייב להחזיר את הערך RESTRICT_BACKGROUND_STATUS_DISABLED עבור ConnectivityManager.getRestrictBackgroundStatus()
  • [C-2-2] אסור לשדר את ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
  • [C-2-3] חייבת להיות פעילות שמטפלת ב-Intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, אבל יכול להיות שצריך להטמיע אותה כפעולה ללא תפעול.

7.4.8. רכיבים מאובטחים

אם הטמעות במכשירים תומכים באלמנטים מאובטחים עם יכולות Open Mobile API והופכים לזמינים באפליקציות של צד שלישי:

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] התצוגה המקדימה של המצלמה חייבת להשקף את התצוגה המקדימה של המצלמה, ביחס לכיוון שהוגדר על ידי האפליקציה, כאשר האפליקציה הנוכחית ביקשה באופן מפורש לסובב את מסך המצלמה באמצעות קריאה לשיטה android.hardware.Camera.setDisplayOrientation(). לעומת זאת, התצוגה המקדימה חייבת לשקף לאורך הציר האופקי המוגדר כברירת מחדל במכשיר אם האפליקציה הנוכחית לא מבקשת באופן מפורש לסובב את תצוגת המצלמה באמצעות קריאה לשיטה android.hardware.Camera.setDisplayOrientation().
  • [C-1-5] אסור לשקף את תמונת הסטילס או הווידאו הסופית שחוזרות לשיחות חוזרות של האפליקציה או שהיא מחויבת לאחסון של מדיה.
  • [C-1-6] חייבת לשקף את התמונה שמופיעה ב-postview באותו אופן כמו התמונה של התצוגה המקדימה של המצלמה.
  • ייתכן שיכללו תכונות (כמו מיקוד אוטומטי, פלאש וכו') הזמינות למצלמות אחוריות, כפי שמתואר בסעיף 7.5.1.

אם המשתמשים יכולים לבצע סיבוב של יישומי המכשיר (למשל באופן אוטומטי באמצעות מד תאוצה או באופן ידני באמצעות קלט של משתמשים):

  • [C-2-1] התצוגה המקדימה של המצלמה חייבת להיות משוכפלת לרוחב המסך ביחס לכיוון הנוכחי של המכשיר.

7.5.3. מצלמה חיצונית

הטמעות מכשירים:

  • עשויים לכלול תמיכה במצלמה חיצונית שלא בהכרח מחוברת תמיד.

אם הטמעתי מכשירים כוללים תמיכה במצלמה חיצונית, הם:

  • [C-1-1] חובה להצהיר על דגל הפלטפורמה android.hardware.camera.external ו-android.hardware camera.any.
  • [C-1-2] חייבת להיות תמיכה ב-USB Video Class (UVC 1.0 ואילך) אם המצלמה החיצונית מתחברת דרך יציאת המארח USB.
  • [C-1-3] חובה לעבור בדיקות CTS של המצלמה כשמחוברים אליהן התקן מצלמה חיצוני. פרטים על בדיקת CTS של המצלמה זמינים בכתובת source.android.com.
  • צריכה לתמוך בדחיסות וידאו כמו MJPEG כדי לאפשר העברה של שידורים לא מקודדים באיכות גבוהה (כלומר, סטרימינג של תמונה גולמית או שידור דחוס בנפרד).
  • יכול להיות שתומכות במספר מצלמות.
  • ייתכן שתומכת בקידוד וידאו מבוסס מצלמה.

אם יש תמיכה בקידוד וידאו מבוסס מצלמה:

  • [C-2-1] שידור לא מקודד / MJPEG בו-זמנית (רזולוציית QVGA או יותר) חייב להיות נגיש להטמעה של המכשיר.

7.5.4. התנהגות ה-API של המצלמה

ב-Android יש שתי חבילות API שמאפשרות גישה למצלמה, הגרסה החדשה יותר של android.hardware.camera2 API שחושפת את בקרת המצלמה ברמה נמוכה יותר לאפליקציה, כולל תהליכי סטרימינג יעילים של רצף/סטרימינג אפסי ואפשרות שליטה בכל פריים בחשיפה, בעוצמת הקול, בשיפור איזון לבן, המרת צבעים, הסרת רעשים, חידוד ועוד.

חבילת ה-API הישנה יותר, android.hardware.Camera, מסומנת כהוצאה משימוש ב-Android 5.0, אך היא עדיין אמורה להיות זמינה לשימוש אפליקציות. הטמעות במכשירי Android חייבות להבטיח את המשך התמיכה ב-API, כפי שמתואר בקטע הזה וב-Android SDK.

לכל התכונות שנפוצות בין המחלקה android.hardware.camera שהוצאה משימוש לבין החבילה החדשה יותר של android.hardware.camera2 חייבת להיות ביצועים ואיכות זהים בשני ממשקי ה-API. לדוגמה, עם הגדרות מקבילות, המהירות והדיוק של המיקוד האוטומטי חייבים להיות זהים, והאיכות של תמונות שמצלמים חייבת להיות זהה. תכונות שתלויות בסמנטיקה השונה של שני ממשקי ה-API לא חייבות להיות מהירות או איכות תואמות, אבל הן צריכות להתאים עד כמה שאפשר.

בהטמעות של מכשירים צריך ליישם את ההתנהגויות הבאות בממשקי ה-API שקשורים למצלמות, בכל המצלמות הזמינות. הטמעות מכשירים:

  • [C-0-1] חובה להשתמש ב-android.hardware.PixelFormat.YCbCr_420_SP לנתוני תצוגה מקדימה שסופקו לקריאות חוזרות של אפליקציה אם אפליקציה לא התקשרה אף פעם ל-android.hardware.Camera.Parameters.setPreviewFormat(int).
  • [C-0-2] חייב להיות בפורמט הקידוד NV21 כשאפליקציה רושמת מכונת android.hardware.Camera.PreviewCallback והמערכת קוראת ל-method onPreviewFrame() ופורמט התצוגה המקדימה הוא YCbCr_420_SP, הנתונים בבייט[] שמועברים אל onPreviewFrame(). כלומר, NV21 חייבת להיות ברירת המחדל.
  • [C-0-3] חייבת לתמוך בפורמט YV12 (כפי שמצוין בקבוע android.graphics.ImageFormat.YV12) לתצוגה מקדימה של המצלמה עבור android.hardware.Camera במצלמה הקדמית וגם במצלמה האחורית. (המצלמה ומקודד הווידאו של החומרה עשויים להשתמש בכל פורמט של פיקסל מקורי, אבל הטמעת המכשיר חייבת לתמוך בהמרה ל-YV12).
  • [C-0-4] חייבת לתמוך בפורמטים android.hardware.ImageFormat.YUV_420_888 ו-android.hardware.ImageFormat.JPEG כפלט באמצעות ה-API של android.media.ImageReader למכשירי android.hardware.camera2 שמפרסמים את היכולת REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE ב-android.request.availableCapabilities.
  • [C-0-5] עדיין חובה להטמיע את ה-מצלמה API המלא שמופיע בתיעוד של Android SDK, גם אם המכשיר כולל מיקוד אוטומטי בחומרה או יכולות אחרות. למשל, מצלמות ללא מיקוד אוטומטי חייבות עדיין לקרוא למופעים רשומים של android.hardware.Camera.AutoFocusCallback (למרות שאין להם רלוונטיות למצלמה ללא מיקוד אוטומטי). שים לב: הדבר נכון לגבי מצלמות קדמיות. לדוגמה, למרות שרוב המצלמות הקדמית לא תומכות במיקוד אוטומטי, הקריאות החוזרות של ה-API עדיין צריכות להיות "מזויפות" כפי שמתואר.
  • [C-0-6] חובה לזהות כל שם של פרמטר שמוגדר כקבוע במחלקה android.hardware.Camera.Parameters ולכבד אותו. לעומת זאת, אסור שהטמעות במכשירים יפעלו כקבועים של מחרוזות שמועברים ל-method android.hardware.Camera.setParameters() ולא יזוהו כקבועים בandroid.hardware.Camera.Parameters. כלומר, בהטמעות במכשירים צריכה להיות תמיכה בכל הפרמטרים הרגילים של המצלמה, אם החומרה מאפשרת זאת, ואסור שהן יתמכו בסוגי פרמטרים מותאמים אישית של המצלמה. לדוגמה, הטמעות של מכשירים שתומכות בצילום תמונות באמצעות שיטות צילום בטווח דינמי גבוה (HDR) חייבות לתמוך בפרמטר Camera.SCENE_MODE_HDR של המצלמה.
  • [C-0-7] חובה לדווח על רמת התמיכה המתאימה בנכס android.info.supportedHardwareLevel כפי שמתואר ב-Android SDK, ולדווח על הסימונים המתאימים של framework.
  • [C-0-8] בנוסף, חובה להצהיר על יכולות המצלמה הנפרדות של android.hardware.camera2 באמצעות המאפיין android.request.availableCapabilities ולהצהיר על דגלי התכונות המתאימים; חובה להגדיר את התכונה הניסיונית אם אחד ממכשירי המצלמה המצורפים תומך בה.
  • [C-0-9] חובה לשדר את ה-Intent Camera.ACTION_NEW_PICTURE בכל פעם שתמונה חדשה צולמה על ידי המצלמה והרשומה של התמונה מתווספת לחנות המדיה.
  • [C-0-10] חובה לשדר את ה-Intent Camera.ACTION_NEW_VIDEO בכל פעם שסרטון חדש מצולם על ידי המצלמה וכניסת התמונה מתווספת לחנות המדיה.
  • [C-SR] מומלץ מאוד לתמוך במכשיר מצלמה לוגי עם רשימה של יכולות CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, במכשירים עם כמה מצלמות שפונות לאותו כיוון, ולכלול כל מצלמה פיזית שפונה לאותו כיוון, כל עוד סוג המצלמה הפיזי נתמך על ידי ה-framework ו-CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL למצלמות הפיזיות הוא LIMITED, FULL או LEVEL_3.

7.5.5. כיוון המצלמה

אם בהטמעות המכשיר יש מצלמה קדמית או אחורית, מצלמות כאלה:

  • [C-1-1] צריך לכוון את המצלמה כך שהממד הארוך של המצלמה יתאים לממד הארוך של המסך. כלומר, כשמחזיקים את המכשיר לרוחב, המצלמות חייבות לצלם תמונות לרוחב. הכלל הזה חל ללא קשר לכיוון הטבעי של המכשיר. כלומר, הוא חל על מכשירים ראשיים בפורמט אופקי וגם על מכשירים ראשיים בפורמט אנכי.

7.6. זיכרון ואחסון

7.6.1. נפח זיכרון ואחסון מינימלי

הטמעות מכשירים:

  • [C-0-1] חייב לכלול מנהל הורדות שיכול לשמש אפליקציות להורדת קובצי נתונים, והן חייבות להיות מסוגלות להוריד קבצים בודדים בגודל 100MB לפחות למיקום ברירת המחדל של המטמון.

7.6.2. אחסון משותף באפליקציות

הטמעות מכשירים:

  • [C-0-1] חובה להציע נפח אחסון שישותף על ידי אפליקציות. לרוב נקרא גם 'אחסון חיצוני משותף', 'אחסון משותף של אפליקציות' או דרך נתיב Linux '/sdcard' שבו הוא מותקן.
  • [C-0-2] חובה להגדיר אמצעי אחסון משותף שטעון כברירת מחדל. כלומר, "הוצאה מהאריזה", גם אם האחסון מוטמע על רכיב אחסון פנימי או על אמצעי אחסון נשלף (למשל, חריץ לכרטיס Secure Digital).
  • [C-0-3] חובה לטעון את האחסון המשותף של האפליקציה ישירות בנתיב sdcard של Linux או לכלול קישור סימבולי של Linux מ-sdcard לנקודת הטעינה עצמה.
  • [C-0-4] חובה לאכוף את ההרשאה android.permission.WRITE_EXTERNAL_STORAGE באחסון המשותף הזה כפי שמתועד ב-SDK. בכל אפליקציה שמקבלת את ההרשאה הזו, נפח האחסון המשותף חייב להיות ניתן לכתיבה בכל מקרה אחר.

הטמעת מכשירים עשויה לעמוד בדרישות שלמעלה באמצעות:

  • אחסון נשלף שנגיש למשתמש, כמו חריץ לכרטיס Secure Digital (SD).
  • חלק מהאחסון הפנימי (לא ניתן להסרה) כפי שמוטמע בפרויקט קוד פתוח (AOSP) של Android.

אם הטמעות של מכשירים משתמשות באחסון נשלף כדי לעמוד בדרישות שלמעלה:

  • [C-1-1] חובה להטמיע ממשק משתמש של הודעה קופצת או הודעה קופצת שמזהירה את המשתמש מפני שלא נוסף אמצעי אחסון לחריץ.
  • [C-1-2] חובה לכלול אמצעי אחסון בפורמט FAT (למשל כרטיס SD) או להציג על האריזה וחומרים אחרים שזמינים בזמן הרכישה, שאותם יש לרכוש בנפרד את אמצעי האחסון.

אם הטמעות של מכשירים עושות שימוש בחלק מהאחסון שלא ניתן להסרה כדי לעמוד בדרישות שלמעלה:

  • צריך להשתמש ביישום AOSP של האחסון המשותף הפנימי של האפליקציה.
  • ייתכן לשיתוף נפח האחסון עם האפליקציה הפרטית.

אם הטמעות המכשיר כוללות כמה נתיבי אחסון משותפים (כמו חריץ לכרטיס SD וגם אחסון פנימי משותף), הן:

  • [C-2-1] חובה לאפשר רק לאפליקציות Android שמותקנות מראש וקיבלו הרשאות WRITE_EXTERNAL_STORAGE לכתוב באחסון החיצוני המשני, למעט כשכותבים לספריות הספציפיות לחבילה או בתוך URI שמוחזר על-ידי הפעלה של ה-Intent ACTION_OPEN_DOCUMENT_TREE.

אם בהטמעות של מכשירים יש יציאת USB עם תמיכה במצב ציוד היקפי בחיבור USB, בהמשך:

  • [C-3-1] חובה לספק מנגנון לגישה לנתונים באחסון המשותף של האפליקציה ממחשב מארח.
  • התוכן משני נתיבי האחסון אמור להופיע בצורה שקופה דרך שירות סורק המדיה של Android ודרך android.provider.MediaStore.
  • ייתכן שתשתמשו באחסון גדול ב-USB, אבל תצטרכו להשתמש בפרוטוקול העברת מדיה כדי לעמוד בדרישה הזו.

אם בהטמעות של מכשירים יש יציאת USB עם מצב היקפי בחיבור USB ותומכות בפרוטוקול להעברת מדיה:

  • אמורה להיות תואמת למארח MTP של Android, העברת קבצים ב-Android.
  • אמור לדווח על סוג התקן USB 0x00.
  • יש לדווח על שם ממשק ה-USB 'MTP'.

7.6.3. אחסון מותאם

אם המכשיר צפוי להיות נייד בטבעו שלא כמו בטלוויזיה, יישומים של מכשירים הם:

  • [SR] מומלץ מאוד להטמיע את האחסון שניתן לאמץ במיקום יציב לטווח ארוך, כי ניתוק שלהם בטעות עלול לגרום לאובדן או לשחיקה של נתונים.

אם היציאה של התקן האחסון הנשלפת נמצאת במיקום יציב לטווח ארוך, למשל בתוך תא הסוללות או כיסוי מגן אחר, דוגמאות להטמעות של המכשירים:

7.7. USB

אם בהטמעות של מכשירים יש יציאת USB:

  • צריכה לתמוך במצב ציוד היקפי בחיבור USB והוא אמור לתמוך במצב אירוח USB.

7.7.1. מצב ציוד היקפי בחיבור USB

אם הטמעות המכשיר כוללות יציאת USB שתומכת במצב היקפי:

  • [C-1-1] היציאה חייבת להיות מחוברת למארח USB שיש בו יציאת USB סטנדרטית מסוג A או Type-C.
  • [C-1-2] חובה לדווח על הערך הנכון של iSerialNumber במתאר של מכשיר USB סטנדרטי עד android.os.Build.SERIAL.
  • [C-1-3] חייבים לזהות מטענים עם הספק 1.5A ו-3.0A בהתאם לתקן של נגד Type-C. בנוסף, הם חייבים לזהות שינויים במודעה אם הם תומכים ב-USB מסוג C.
  • [SR] היציאה צריכה להשתמש בגורם צורה של USB מסוג מיקרו-B, מיקרו-AB או USB. מכשירי Android קיימים וחדשים מומלץ מאוד לעמוד בדרישות האלה, כדי שאפשר יהיה לשדרג אותם לגרסאות עתידיות של הפלטפורמה.
  • [SR] היציאה צריכה להיות ממוקמת בחלק התחתון של המכשיר (בהתאם לכיוון הטבעי) או לאפשר סיבוב מסך של התוכנה בכל האפליקציות (כולל מסך הבית), כדי שהמסך ייחתך כראוי כשהמכשיר מיושר עם היציאה התחתונה. מכשירי Android קיימים וחדשים מומלץ מאוד לעמוד בדרישות האלה, כדי שאפשר יהיה לשדרג אותם לגרסאות עתידיות של הפלטפורמה.
  • [SR] אמורה להטמיע תמיכה כדי למשוך זרם של 1.5 A במהלך ציוץ ותנועה של HS כפי שמצוין במפרט של טעינת סוללה ב-USB, גרסה 1.2. מכשירי Android קיימים וחדשים מומלץ מאוד לעמוד בדרישות האלה, כדי שאפשר יהיה לשדרג אותם לגרסאות עתידיות של הפלטפורמה.
  • [SR] מומלץ מאוד לא לתמוך בשיטות טעינה קנייניות שמשנות את מתח Vbus מעבר לרמות ברירת המחדל, או שישנו תפקידים של sink/מקור, כי הדבר עלול לגרום לבעיות ביכולת הפעולה ההדדית (interoperability) במטענים או במכשירים שתומכים בשיטות הסטנדרטיות של העברת חשמל ב-USB. התכונה הזו נקראת 'מומלץ מאוד', אבל בגרסאות עתידיות של Android יכול להיות שנדרוש שכל המכשירים מסוג C יתמכו ביכולת פעולה הדדית מלאה עם מטענים סטנדרטיים מסוג C.
  • [SR] מומלץ מאוד לתמוך ב-Power Delivery להחלפת נתונים ותפקידי חשמל כשהם תומכים במצב מארח USB-C ו-USB.
  • אמורה להיות תמיכה באספקת חשמל לטעינה במתח גבוה ותמיכה במצבים חלופיים, כמו מסך חוץ.
  • יש להטמיע את ה-API והמפרט של Android Open Accessory (AOA), כפי שמתואר במסמכי התיעוד של Android SDK.

אם הטמעות המכשירים כוללות יציאת USB ומטמיעות את מפרט AOA:

  • [C-2-1] חובה להצהיר על תמיכה בתכונת החומרה android.hardware.usb.accessory.
  • [C-2-2] סוג האחסון בנפח USB חייב לכלול את המחרוזת 'android' בסוף תיאור הממשק iInterface של אחסון בנפח גדול ב-USB.

7.7.2. מצב אירוח USB

אם הטמעות המכשירים כוללות יציאת USB שתומכת במצב מארח:

  • [C-1-1] חובה להטמיע את ממשק ה-API של מארח USB ל-Android כפי שמתואר ב-Android SDK. כמו כן, חובה להצהיר על תמיכה בתכונת החומרה android.hardware.usb.host.
  • [C-1-2] חובה להטמיע תמיכה כדי לחבר ציוד היקפי סטנדרטי בחיבור USB. כלומר, חייב להיות באחת מהאפשרויות הבאות:
    • צריכה להיות במכשיר יציאה מסוג C או ספינה עם כבלים, שמאפשרת להתאים יציאה קניינית במכשיר ליציאת USB מסוג C סטנדרטית (מכשיר USB-C).
    • צריך להיות מכשיר מסוג A או חיבור עם כבלים, שמאפשר להתאים יציאה קניינית במכשיר ליציאת USB מסוג A סטנדרטית.
    • צריכה להיות בהם יציאת מיקרו-AB במכשיר, שאמורה להישלח עם כבל שמתאים ליציאה סטנדרטית מסוג A.
  • [C-1-3] אסור לשלוח עם מתאם שמבצע המרה מיציאות USB מסוג A או מיציאות מיקרו-AB לשקע מסוג C (שקע).
  • [SR] מומלץ מאוד להטמיע את סיווג האודיו USB כפי שמתועד בתיעוד של Android SDK.
  • צריכה לתמוך בטעינת ציוד היקפי בחיבור USB מחובר במצב מארח; פרסום זרם מקור של 1.5A לפחות כפי שמצוין בקטע 'פרמטרים של סיום' בתיקון 1.2 כבל ומפרט מחבר של USB Type-C עבור מחברים מסוג USB-C, או שימוש בטווח הנוכחי של פלט בשקע USB מסוג C(CDP) כמפורט במפרט הטעינה של סוללת USB, גרסה 1.2.
  • עליכם להטמיע ולתמוך בתקני USB Type-C.

אם הטמעות המכשירים כוללות יציאת USB שתומכת במצב מארח ואת סיווג האודיו ב-USB:

  • [C-2-1] חייב לתמוך בסיווג USB HID.
  • [C-2-2] חייבת לתמוך בזיהוי ובמיפוי של שדות נתוני ה-HID הבאים, המפורטים בטבלאות השימוש של USB HID ובבקשה לשימוש בפקודות קוליות עם הקבועים KeyEvent הבאים:
    • מזהה השימוש של דף השימוש (0xC) (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
    • מזהה השימוש של דף השימוש (0xC) (0x0E9): KEYCODE_VOLUME_UP
    • מזהה השימוש של דף השימוש (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
    • מזהה השימוש של דף השימוש (0xC) (0x0CF): KEYCODE_VOICE_ASSIST

אם ההטמעות של המכשירים כוללות יציאת USB שתומכת במצב מארח ואת Storage Access Framework (SAF), הן:

  • [C-3-1] חובה לזהות מכשירי MTP (פרוטוקול העברת מדיה) שמחוברים מרחוק, ולהפוך את התוכן שלהם לנגיש באמצעות ה-Intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT ו-ACTION_CREATE_DOCUMENT. .

אם הטמעות המכשירים כוללות יציאת USB שתומכת במצב מארח ו-USB Type-C:

  • [C-4-1] חובה ליישם את הפונקציונליות של יציאת שני תפקידים, כפי שהוגדרה במפרט USB Type-C (סעיף 4.5.1.3.3).
  • [SR] מומלץ מאוד לתמיכה ב-DisplayPort, צריכה לתמוך בקצבי נתונים של USB Superspeed, ומומלץ מאוד לתמוך באספקת החשמל (Power Delivery) להחלפת נתונים והחלפת תפקידי כוח.
  • [SR] מומלץ מאוד לא לתמוך במצב האביזר של מתאם האודיו כפי שמתואר בנספח א' של גרסה 1.2 של כבל USB-C ומפרט המחבר.
  • עליכם להטמיע את מודל Try.* המתאים ביותר לגורם הצורה של המכשיר. לדוגמה, במכשיר ידני צריך להטמיע את המודל Try.SNK.

7.8. אודיו

7.8.1. מיקרופון

אם ההטמעות במכשירים כוללים מיקרופון:

  • [C-1-1] חובה לדווח על קבוע התכונה android.hardware.microphone.
  • [C-1-2] חייבת לעמוד בדרישות לגבי הקלטת אודיו שמפורטות בסעיף 5.4.
  • [C-1-3] חייב לעמוד בדרישות זמן האחזור של האודיו שמפורטות בסעיף 5.6.
  • [SR] מומלץ מאוד לתמוך בהקלטת אולטרסאונד, כפי שמתואר בסעיף 7.8.3.

אם ההטמעות של המכשיר מושמטות ממיקרופון:

  • [C-2-1] אסור לדווח על קבוע התכונה android.hardware.microphone.
  • [C-2-2] חובה להטמיע את ה-API של הקלטת האודיו לפחות כפעולות ללא תפעול, לפי סעיף 7.

7.8.2. יעד השמע

אם בהטמעות המכשיר יש רמקול או יציאת פלט אודיו/מולטימדיה לציוד היקפי לפלט אודיו, כמו שקע אודיו 4 מוליך 3.5 מ"מ או יציאה של מצב מארח USB באמצעות סיווג אודיו ב-USB:

  • [C-1-1] חובה לדווח על קבוע התכונה android.hardware.audio.output.
  • [C-1-2] חייב לעמוד בדרישות להפעלת אודיו שמפורטות בסעיף 5.5.
  • [C-1-3] חייב לעמוד בדרישות זמן האחזור של האודיו שמפורטות בסעיף 5.6.
  • [SR] מומלץ מאוד לתמוך בהפעלה כמעט באולטרסאונד כפי שמתואר בסעיף 7.8.3.

אם ההטמעות במכשירים לא כוללות רמקול או יציאת אודיו, הן:

  • [C-2-1] אסור לדווח על התכונה android.hardware.audio.output.
  • [C-2-2] חובה להטמיע לפחות את ממשקי ה-API שקשורים לפלט האודיו כללא תפעול.

למטרות הסעיף הזה, "יציאת פלט" היא ממשק פיזי כמו שקע אודיו 3.5 מ"מ, HDMI או יציאה במצב מארח USB עם סיווג אודיו ב-USB. תמיכה בפלט אודיו בפרוטוקולים מבוססי רדיו כמו Bluetooth , Wi-Fi או רשת סלולרית לא עומדת בדרישות להכללה של "יציאת פלט".

7.8.2.1. יציאות אודיו אנלוגיות

כדי שיתאימו לאוזניות ואביזרי אודיו אחרים באמצעות תקע אודיו 3.5 מ"מ בכל הסביבה העסקית של Android, אם בהטמעות במכשירים יש יציאת אודיו אנלוגית אחת או יותר:

  • [C-SR] מומלץ מאוד לכלול לפחות אחת מיציאות האודיו שיהיו שקע אודיו עם 4 מוליכים בגודל 3.5 מ"מ.

אם בהטמעות של מכשירים יש שקע אודיו של 4 מוליך בגודל 3.5 מ"מ, הן:

  • [C-1-1] חייבת לתמוך בהפעלת אודיו באוזניות סטריאו ובאוזניות סטריאו עם מיקרופון.
  • [C-1-2] חייבת לתמוך במחברי האודיו ב-TRRS עם הזמנת ההצמדה של CTIA.
  • [C-1-3] חייבת לתמוך בזיהוי ובמיפוי לקודי המפתחות עבור 3 הטווחים הבאים של העכבה המקבילה בין המיקרופון למוליכי הקרקע בתקע האודיו:
    • 70 או פחות או פחות: KEYCODE_HEADSETHOOK
    • 210-290 אוהם: KEYCODE_VOLUME_UP
    • 360-680 אוהם: KEYCODE_VOLUME_DOWN
  • [C-1-4] חייבים להפעיל את ACTION_HEADSET_PLUG בכל הכנסת תקע, אבל רק אחרי שכל אנשי הקשר בשקע נוגעים במקטעים הרלוונטיים בשקע.
  • [C-1-5] חייבת להיות מסוגלת להניע לפחות 150mV ± 10% ממתח היציאה בעכבת רמקול של 32 אוהם.
  • [C-1-6] חייבת להיות הטיית מיקרופון בין 1.8 וולט כ-2.9 וולט.
  • [C-1-7] חובה לזהות את קוד המפתח ולמפות אותו לטווח הבא של העכבה המקבילה בין המיקרופון למוליכי הקרקע בתקע האודיו:
    • 110-180 אוהם: KEYCODE_VOICE_ASSIST
  • [C-SR] מומלץ מאוד לתמוך בתקעי אודיו עם הזמנת ההצמדה של OMTP.
  • [C-SR] מומלץ מאוד לתמוך בהקלטת אודיו מאוזניות סטריאו עם מיקרופון.

אם בהטמעות של מכשירים יש שקע אודיו של 4 מוליך בגודל 3.5 מ"מ ותומכות במיקרופון, והמיקרופון של android.intent.action.HEADSET_PLUG מוגדר לערך 1 הנוסף:

  • [C-2-1] חייבת להיות תמיכה בזיהוי המיקרופון באביזר האודיו המחובר.

7.8.3. קרוב לאולטרסאונד

אודיו Near-Ultrasound הוא תדר של 18.5kHz עד 20kHz.

הטמעות מכשירים:

  • חייבים לדווח בצורה נכונה על תמיכה באודיו כמעט-קולי דרך ה-API של AudioManager.getProperty API באופן הבא:

אם הערך PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND הוא 'true', מקורות האודיו VOICE_RECOGNITION ו-UNPROCESSED חייבים לעמוד בדרישות הבאות:

  • [C-1-1] תגובת ההספק הממוצעת של המיקרופון בתדרים 18.5kHz עד 20kHz חייבת להיות לא יותר מ-15dB מתחת לתגובה ב-2kHz.
  • [C-1-2] יחס האות הלא משוקלל לרעש של המיקרופון מעל 18.5 kHz עד 20kHz לטון של 19kHz ב- -26dBFS חייב להיות לא פחות מ-50dB

אם הערך של PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND הוא 'true':

  • [C-2-1] התגובה הממוצעת של הרמקול בתדרים 18.5 kHz עד 20 kHz חייבת להיות לא נמוכה מ- 40 dB מתחת לתגובה ב- 2 kHz.

7.9. מציאות מדומה

ב-Android יש ממשקי API ומתקנים לבניית אפליקציות "מציאות מדומה" (VR), כולל חוויות VR בנייד באיכות גבוהה. הטמעות של מכשירים חייבות להטמיע בצורה תקינה את ממשקי ה-API וההתנהגויות האלה, כפי שמפורט בקטע הזה.

7.9.1. מצב מציאות מדומה

ב-Android יש תמיכה במצב VR, תכונה שמטפלת ברינדור סטריאוסקופי של התראות ומשביתה רכיבי ממשק משתמש חד-קולריים של המערכת בזמן שאפליקציית VR מתמקדת במשתמש.

7.9.2. מצב מציאות מדומה – ביצועים גבוהים

אם ההטמעות במכשירים תומכים במצב VR:

  • [C-1-1] חייבות להיות לפחות 2 ליבות פיזיות.
  • [C-1-2] חובה להצהיר על התכונה android.hardware.vr.high_performance.
  • [C-1-3] חייבת להיות תמיכה במצב ביצועים טובים.
  • [C-1-4] חייבת לתמוך ב-OpenGL ES 3.2.
  • [C-1-5] חייבת לתמוך ב-android.hardware.vulkan.level 0.
  • צריכה לתמוך ב-android.hardware.vulkan.level 1 ומעלה.
  • [C-1-6] חובה להטמיע את EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace, ולהציג את התוספים ברשימת התוספים הזמינים.
  • [C-1-8] חובה להטמיע את GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures, ולחשוף את התוספים ברשימת תוספי ה-GL הזמינים.
  • [C-SR] מומלץ מאוד להטמיע את GL_EXT_external_buffer, GL_EXT_EGL_image_array ולחשוף את התוספים ברשימת תוספי ה-GL הזמינים.
  • [C-SR] אנחנו ממליצים מאוד לתמוך ב-Vulkan 1.1.
  • [C-SR] מומלץ מאוד להטמיע את VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image ולחשוף אותו ברשימת התוספים הזמינים של Vulkan.
  • [C-SR] מומלץ מאוד לחשוף לפחות משפחת תור אחת של Vulkan שבה flags מכיל גם את VK_QUEUE_GRAPHICS_BIT וגם את VK_QUEUE_COMPUTE_BIT, ו-queueCount הוא לפחות 2.
  • [C-1-7] ה-GPU והמסך חייבים להיות מסוגלים לסנכרן את הגישה למאגר הנתונים הקדמי המשותף, כך שעיבוד עיניים מתחלפות של תוכן VR במהירות של 60fps עם שני הקשרי רינדור יוצג ללא פריטי מידע שנוצרו בתהליך העיבוד (Artifact).
  • [C-1-9] חובה ליישם תמיכה ב-AHardwareBuffer בדגלים AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA ו-AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT כפי שמתואר ב-NDK.
  • [C-1-10] חובה להטמיע תמיכה ב-AHardwareBuffer עם כל שילוב של דגלי השימוש AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT לפחות בפורמטים הבאים: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
  • [C-SR] מומלץ מאוד לתמוך בהקצאה של ערכי AHardwareBuffer עם יותר משכבה אחת ודגלים ופורמטים שצוינו ב-C-1-10.
  • [C-1-11] חייבת לתמוך בפענוח H.264 של לפחות 3840 x 2160 בקצב של 30 Mbps, בדחיסה לממוצע של 40Mbps (שווה ל-4 מופעים של 1920 x1080 ב- 30Mbps-10Mbps או שני מופעים של 1080 x 10Mbps).
  • [C-1-12] חייבת לתמוך ב-HEVC וב-VP9. היא חייבת להיות מסוגלת לפענח לפחות 1920 x 1080 בקצב של 1920x1080 ב- 30fps, דחוסה עד 10Mbps.
  • [C-1-13] האפליקציה חייבת לתמוך ב-API של HardwarePropertiesManager.getDeviceTemperatures ולהחזיר ערכים מדויקים של טמפרטורת העור.
  • [C-1-14] חייב להיות מסך מוטמע, והרזולוציה שלו חייבת להיות לפחות 1920 x 1080.
  • [C-SR] מומלץ מאוד שרזולוציית המסך תהיה לפחות 2560 x 1440.
  • [C-1-15] המסך חייב להתעדכן לפחות 60 Hz במצב VR.
  • [C-1-17] המסך חייב לתמוך במצב של התמדה נמוכה עם תדירות של 5 אלפיות השנייה או פחות. מדד זה מוגדר כמשך הזמן שבו פיקסל פולט אור.
  • [C-1-18] חייבת להיות תמיכה ב-Bluetooth 4.2 ובתוסף אורך נתונים של Bluetooth LE בסעיף 7.4.3.
  • [C-1-19] חובה לתמוך בסוג ערוץ ישיר ולדווח עליו כראוי בכל סוגי החיישנים הבאים שמוגדרים כברירת מחדל:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR] אנחנו ממליצים מאוד לתמוך בסוג הערוץ הישיר TYPE_HARDWARE_BUFFER בכל סוגי הערוצים הישירים שמפורטים למעלה.
  • [C-1-21] חייב לעמוד בדרישות שקשורות לג'ירוסקופ, מד התאוצה והמגנטומטר עבור android.hardware.hifi_sensors, כפי שמפורט בסעיף 7.3.9.
  • [C-SR] מומלץ מאוד לתמוך בתכונה android.hardware.sensor.hifi_sensors.
  • [C-1-22] זמן האחזור של תנועה מקצה לקצה לפוטון חייב להיות לא יותר מ-28 אלפיות השנייה.
  • [C-SR] מומלץ מאוד שזמן האחזור של תנועה מקצה לקצה לפוטון לא יעלה על 20 אלפיות השנייה.
  • [C-1-23] חייב להיות יחס פריים ראשון, שהוא היחס בין בהירות הפיקסלים בפריים הראשון לאחר מעבר משחור ללבן לבין הבהירות של פיקסלים לבנים במצב יציב, של 85% לפחות.
  • [C-SR] מומלץ מאוד לשמור על יחס פריים ראשון של 90% לפחות.
  • MAY מספק ליבה בלעדית לאפליקציה בחזית, ו-MAY תומך ב-API Process.getExclusiveCores כדי להחזיר את הנתונים של ליבות ה-CPU שבלעדיות לאפליקציה בחזית.

אם יש תמיכה בליבה בלעדית, אז הליבה:

  • [C-2-1] אסור לאפשר לתהליכים אחרים של מרחב משתמשים לפעול (למעט מנהלי התקנים של מכשירים שהאפליקציה משתמשת בהם), אבל יכול להיות לאפשר לכמה תהליכי ליבה לפעול לפי הצורך.

8. ביצועים ועוצמה

חלק מהקריטריונים של ביצועים מינימליים והספק יש קריטי לחוויית המשתמש ומשפיעים על הנחות הבסיס שיהיו למפתחים במהלך פיתוח האפליקציה.

8.1. עקביות בחוויית המשתמש

אם יש דרישות מינימליות מסוימות, כדאי לספק ממשק משתמש חלק למשתמשי הקצה, כדי להבטיח שקצב הפריימים וזמני התגובה יהיו עקביים באפליקציות ובמשחקים. בהטמעות של מכשירים, בהתאם לסוג המכשיר, ייתכן שיהיו דרישות שניתנות למדידה לגבי זמן האחזור בממשק המשתמש ולמעבר בין משימות, כמו שמתואר בקטע 2.

8.2. ביצועים של גישת קלט/פלט לקובץ

יצירת בסיס משותף לעקביות בביצועי הגישה לקבצים באחסון הנתונים הפרטיים של האפליקציה (המחיצה /data), מאפשרת למפתחי אפליקציות להגדיר ציפיות שיעזרו להם לתכנן את התוכנה. בהטמעות של מכשירים, בהתאם לסוג המכשיר, ייתכן שיש דרישות מסוימות שמתוארות בסעיף 2 לגבי פעולות הקריאה והכתיבה הבאות:

  • ביצועי כתיבה ברצף. המדידה מתבצעת על ידי כתיבת קובץ של 256MB באמצעות מאגר נתונים זמני של 10MB.
  • ביצועי כתיבה אקראיים. המדידה מתבצעת על ידי כתיבת קובץ של 256MB באמצעות מאגר נתונים זמני של 4KB.
  • ביצועי קריאה ברצף. המדידה מתבצעת על ידי קריאת קובץ של 256MB באמצעות מאגר נתונים זמני של 10MB.
  • ביצועי קריאה אקראיים. המדידה מתבצעת על ידי קריאת קובץ של 256MB באמצעות מאגר נתונים זמני של 4KB.

8.3. מצבי חיסכון בסוללה

אם הטמעות המכשירים כוללות תכונות לשיפור ניהול צריכת החשמל של המכשיר שכלולות ב-AOSP או להרחבת התכונות שכלולות ב-AOSP:

  • [C-1-1] אסור לסטות מהטמעה של AOSP לאלגוריתמים של הטריגרים, התחזוקה וההתעוררות, ושימוש בהגדרות המערכת הגלובליות של מצב המתנה ומצב 'נמנום' של חיסכון בסוללה.
  • [C-1-2] אסור לסטות מהטמעה של AOSP לשימוש בהגדרות גלובליות לניהול ויסות הנתונים (throttling) של משימות, התראות ורשת עבור אפליקציות בכל קטגוריה במצב המתנה של אפליקציה.
  • [C-1-3] אסור לסטות מהטמעת ה-AOSP של מספר קטגוריות ההמתנה של האפליקציה שמשמשות למצב המתנה של אפליקציה.
  • [C-1-4] חובה להטמיע קטגוריות של אפליקציות במצב המתנה ואת האפשרות 'נמנום' כפי שמתואר בניהול צריכת חשמל.
  • [C-1-5] חובה להחזיר true במחיר PowerManager.isPowerSaveMode() כשהמכשיר נמצא במצב חיסכון בסוללה.
  • [C-SR] מומלץ מאוד לאפשר למשתמשים להפעיל או להשבית את תכונת החיסכון בסוללה.
  • [C-SR] מומלץ מאוד לספק למשתמשים אפשרות להציג את כל האפליקציות שפטורות ממצבי חיסכון בסוללה ו-App Standby.

בנוסף למצבי החיסכון בסוללה, בהטמעות של מכשירי Android ייתכן מיושם כל אחד מארבעת המצבים של אספקת החשמל במצב שינה, או את כולם, כפי שהוגדרו על ידי Advanced Configuration (הגדרות אישיות) ו-Power Interface (ACPI).

אם הטמעות של מכשירים מטמיעות מצבי כוח של S4 כפי שהוגדרו ב-ACPI, הן:

  • [C-1-1] חובה להיכנס למצב הזה רק אחרי שהמשתמש ביצע פעולה מפורשת כדי להעביר את המכשיר למצב לא פעיל (למשל, על ידי סגירת מכסה ששייך פיזית למכשיר או כיבוי של רכב או טלוויזיה), ולפני שהמשתמש מפעיל מחדש את המכשיר (למשל, על ידי פתיחת המכסה או הפעלה מחדש של הרכב או הטלוויזיה).

אם הטמעות של מכשירים מטמיעות מצבי כוח של S3 כפי שהוגדרו ב-ACPI:

  • [C-2-1] חובה לעמוד בדרישות C-1-1 שלמעלה, או שחובה להזין את מצב S3 רק כשאפליקציות של צד שלישי לא צריכות את משאבי המערכת (למשל מסך או מעבד (CPU).

    לעומת זאת, חובה לצאת ממצב S3 כשאפליקציות של צד שלישי צריכות את משאבי המערכת, כפי שמתואר ב-SDK הזה.

    לדוגמה, באפליקציות של צד שלישי שמבקשות להשאיר את המסך פועל עד FLAG_KEEP_SCREEN_ON או להשאיר את המעבד (CPU) פועל עד PARTIAL_WAKE_LOCK, המכשיר לא יכול לעבור למצב S3 אלא אם, כפי שמתואר ב-C-1-1, המשתמש ביצע פעולה מפורשת כדי להעביר את המכשיר למצב לא פעיל. לעומת זאת, בזמן שמופעלת משימה שאפליקציות צד שלישי מטמיעות דרך JobScheduler או העברת הודעות בענן ב-Firebase לאפליקציות צד שלישי, המכשיר חייב לצאת ממצב S3, אלא אם המשתמש שינה את המכשיר במצב לא פעיל. אלה לא דוגמאות מקיפות, ו-AOSP מיישם אותות נרחבים של התעוררות ממצב שינה כדי לגרום להתעוררות מהמצב הזה.

8.4. חשבונאות של צריכת הכוח

חשבונאות ודיווח מדויקים יותר על צריכת החשמל מספקים למפתח האפליקציה גם את התמריצים וגם את הכלים לאופטימיזציה של דפוס השימוש בחשמל של האפליקציה.

הטמעות מכשירים:

  • [SR] מומלץ מאוד לספק פרופיל חשמל לכל רכיב שמגדיר את ערך הצריכה הנוכחית של כל רכיב חומרה ואת התרוקנות הסוללה המשוערת שנגרמה על ידי הרכיבים לאורך זמן, כפי שתועד באתר של פרויקט הקוד הפתוח של Android.
  • [SR] מומלץ מאוד לדווח על כל ערכי צריכת החשמל באלפיות השנייה (mAh).
  • [SR] מומלץ מאוד לדווח על צריכת החשמל של המעבד (CPU) לפי ה-UID של כל תהליך. פרויקט הקוד הפתוח של Android עומד בדרישה באמצעות הטמעת מודול הליבה של uid_cputime.
  • [SR] מומלץ מאוד להפעיל את השימוש הזה בחשמל באמצעות פקודת המעטפת adb shell dumpsys batterystats למפתח האפליקציה.
  • צריך להיות משויך לרכיב החומרה עצמו אם אין אפשרות לשייך לאפליקציה את צריכת החשמל של רכיב החומרה.

8.5. ביצועים עקביים

יכולות להיות תנודות משמעותיות בביצועים של אפליקציות ממושכות, שמניבות ביצועים גבוהים, בגלל אפליקציות אחרות שפועלות ברקע או בגלל ויסות נתונים (throttle) של המעבד (CPU) עקב מגבלות טמפרטורה. ב-Android יש ממשקים פרוגרמטיים, כך שכאשר המכשיר יכול להיות מסוגל, האפליקציה בחלק העליון של המסך תוכל לבקש שהמערכת תבצע אופטימיזציה של הקצאת המשאבים כדי לטפל בתנודות כאלה.

הטמעות מכשירים:

אם יישומי מכשירים ידווחו על תמיכה במצב ביצועים עקביים:

  • [C-1-1] האפליקציה חייבת לספק רמת ביצועים עקבית לאפליקציה בחזית במשך 30 דקות לפחות, כשהאפליקציה מבקשת זאת.
  • [C-1-2] חובה לפעול בהתאם ל-API של Window.setSustainedPerformanceMode() ולממשקי API קשורים אחרים.

אם הטמעות המכשיר כוללות שתי ליבות מעבד (CPU) או יותר:

  • אמורות לספק לפחות ליבה בלעדית אחת שאפשר להזמין באמצעות האפליקציה העליונה שפועלת בחזית.

אם הטמעות במכשירים תומכים בהזמנת ליבה בלעדית אחת לאפליקציה בחזית העליונה:

  • [C-2-1] חובה לדווח באמצעות שיטת ה-API Process.getExclusiveCores() על מספרי הזיהוי של הליבות הבלעדיות שאפשר לשריין באפליקציה העליונה בחזית.
  • [C-2-2] אסור לאפשר לתהליכים במרחב המשתמש לפעול בליבות בלעדיות, מלבד מנהלי ההתקנים של המכשירים שהאפליקציה משתמשת בהם, אבל יכול להיות שיידרשו תהליכי ליבה מסוימים לפעול לפי הצורך.

אם הטמעות של מכשירים לא תומכות בליבה בלעדית, הן:

9. תאימות של דגם אבטחה

הטמעות מכשירים:

  • [C-0-1] חובה להטמיע מודל אבטחה שתואם למודל האבטחה של פלטפורמת Android, כפי שמוגדר במסמך העזר בנושא אבטחה והרשאות בממשקי ה-API שבמסמכי התיעוד למפתחים של Android.

  • [C-0-2] חובה לתמוך בהתקנה של אפליקציות בחתימה עצמית בלי לדרוש הרשאות/אישורים נוספים מרשות/צדדים שלישיים. באופן ספציפי, מכשירים תואמים חייבים לתמוך במנגנוני האבטחה שמתוארים בסעיפי המשנה הבאים.

9.1. הרשאות

הטמעות מכשירים:

  • [C-0-1] חייבת לתמוך במודל ההרשאות של Android כפי שמוגדר במסמכים למפתחים של Android. באופן ספציפי, הן חייבות לאכוף כל הרשאה שמוגדרת כפי שמתואר במסמכי התיעוד של ה-SDK. אי אפשר להשמיט, לשנות או להתעלם מהרשאות.

  • יכול להיות שיתווספו עוד הרשאות, בתנאי שהמחרוזות החדשות של מזהה ההרשאה לא נמצאות במרחב השמות של android.\*.

  • [C-0-2] הרשאות עם ערך protectionLevel של PROTECTION_FLAG_PRIVILEGED חייבות להיות מוענקות רק לאפליקציות שהותקנו מראש בנתיבים עם ההרשאות המתאימות בתמונת המערכת, ובקבוצת המשנה של ההרשאות שנתתם באופן מפורש לרשימת ההיתרים עבור כל אפליקציה. כדי ליישם את הדרישה הזו, הטמעת ה-AOSP עומדת בדרישה הזו: עליכם לקרוא את ההרשאות שברשימת ההיתרים לכל אפליקציה מהקבצים בנתיב etc/permissions/ ולהשתמש בנתיב system/priv-app כנתיב בעל הרשאות.

הרשאות עם רמת הגנה מסוכנות הן הרשאות בתחילת ההפעלה. אפליקציות עם targetSdkVersion > 22 מבקשות אותן בזמן הריצה.

הטמעות מכשירים:

  • [C-0-3] חובה להציג ממשק ייעודי למשתמשים כדי להחליט אם להעניק את ההרשאות הנדרשות בתחילת ההפעלה, וגם לספק ממשק למשתמש לניהול הרשאות בתחילת הריצה.
  • [C-0-4] חייבת להיות הטמעה אחת בלבד של שני ממשקי המשתמש.
  • [C-0-5] אסור להעניק הרשאות סביבת זמן ריצה לאפליקציות שהותקנו מראש, אלא אם:
    • אפשר לקבל את הסכמת המשתמש לפני שהאפליקציה משתמשת בו.
    • ההרשאות בתחילת ההפעלה משויכות לדפוס Intent, שבו האפליקציה שהותקנה מראש מוגדרת כ-handler שמוגדר כברירת מחדל.
  • [C-0-6] חובה להעניק את ההרשאה android.permission.RECOVER_KEYSTORE רק לאפליקציות מערכת שרושמות סוכן שחזור מאובטח כראוי. סוכן שחזור שמאובטח כראוי מוגדר כסוכן תוכנה במכשיר שמסתנכרן עם אחסון מרוחק מחוץ למכשיר, ומצויד בחומרה מאובטחת עם הגנה מקבילה או חזקה יותר ממה שמתואר בשירות הכספת למפתחות של Google Cloud, כדי למנוע התקפות מסוג brute-force על גורם הידע במסך הנעילה.

אם הטמעת את המכשירים במכשיר כולל אפליקציה שהותקנה מראש או שברצונך לאפשר לאפליקציות של צד שלישי לגשת לסטטיסטיקות השימוש, הן:

  • [SR] מומלץ מאוד לספק מנגנון נגיש למשתמש כדי להעניק או לבטל גישה לנתוני השימוש בתגובה ל-Intent של android.settings.ACTION_USAGE_ACCESS_SETTINGS עבור אפליקציות עם הצהרה על ההרשאה android.permission.PACKAGE_USAGE_STATS.

אם יישומים של מכשירים ניידים מתכוונים למנוע מאפליקציות כלשהן, כולל אפליקציות שהותקנו מראש, לגשת לנתוני השימוש, הן:

  • [C-1-1] עדיין חייבת להיות פעילות שמטפלת בדפוס ה-Intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, אבל חייבים להטמיע אותה כפעולה ללא תפעול (no-op), כלומר התנהגות מקבילה לזו של דחיית הגישה של המשתמש.

9.2. UID ובידוד של תהליכים

הטמעות מכשירים:

  • [C-0-1] חייבת לתמוך במודל Sandbox של אפליקציות Android, שבו כל אפליקציה פועלת כ-UID ייחודי של Unixstyle ובתהליך נפרד.
  • [C-0-2] חייבת לתמוך בהפעלת אפליקציות מרובות כאותו מזהה משתמש ב-Linux, בתנאי שהאפליקציות חתומות ובבנייה כראוי, כפי שמוגדר בחומר העזר בנושא אבטחה והרשאות.

9.3. הרשאות במערכת הקבצים

הטמעות מכשירים:

9.4. סביבות הפעלה חלופיות

יישומים של מכשירים חייבים לשמור על עקביות בין מודל ההרשאות והאבטחה של Android, גם אם הם כוללים סביבות זמן ריצה שמבצעות אפליקציות באמצעות תוכנה או טכנולוגיה אחרת מאלה של Dalvik Executable Format או קוד ה-Native. במילים אחרות:

  • [C-0-1] זמני ריצה חלופיים חייבים להיות אפליקציות ל-Android והם חייבים לפעול בהתאם למודל האבטחה הסטנדרטי של Android, כמו שמתואר במקום אחר בסעיף 9.

  • [C-0-2] אסור לתת לזמני ריצה חלופיים גישה למשאבים שמוגנים על ידי הרשאות שלא התבקשו בקובץ AndroidManifest.xml של סביבת זמן הריצה באמצעות המנגנון <uses-permission>.

  • [C-0-3] אסור להגדיר זמני ריצה חלופיים לאפליקציות להשתמש בתכונות שמוגנות באמצעות הרשאות של Android שמוגבלות לאפליקציות מערכת.

  • [C-0-4] זמני ריצה חלופיים חייבים לציית לדגם ארגז החול של Android ולאפליקציות מותקנות באמצעות סביבת זמן ריצה חלופית, אסור להשתמש שוב ב-Sandbox של אפליקציות אחרות שמותקנות במכשיר, אלא באמצעות המנגנונים הרגילים של Android שכוללים מזהה משתמש משותף ואישור חתימה.

  • [C-0-5] אסור להפעיל זמני ריצה חלופיים עם ארגזי חול שתואמים לאפליקציות אחרות ל-Android, להעניק להם גישה או לקבל גישה אליהם.

  • [C-0-6] אסור להפעיל זמני ריצה חלופיים עם, אם נותנים לאפליקציות אחרות הרשאות של משתמש-העל (root) או של כל מזהה משתמש אחר.

  • [C-0-7] כשקובצי .apk של זמני ריצה חלופיים נכללים בתמונת המערכת של יישומי המכשיר, הם חייבים להיות חתומים באמצעות מפתח נפרד מהמפתח המשמש לחתימה על אפליקציות אחרות שכלולות בהטמעות המכשיר.

  • [C-0-8] כשמתקינים אפליקציות, על זמני ריצה חלופיים לקבל את הסכמת המשתמשים להרשאות Android שהאפליקציה משתמשת בהן.

  • [C-0-9] כשאפליקציה צריכה להשתמש במשאב במכשיר שעבורו יש הרשאה תואמת של Android (לדוגמה: מצלמה, GPS וכו'), סביבת זמן הריצה החלופית חייבת להודיע למשתמש שהאפליקציה תוכל לגשת למשאב הזה.

  • [C-0-10] כשסביבת זמן הריצה לא מתעדת יכולות של אפליקציות באופן הזה, סביבת זמן הריצה חייבת להציג רשימה של כל ההרשאות שיש בסביבת זמן הריצה עצמה במהלך התקנה של אפליקציות שמשתמשות באותו זמן ריצה.

  • אם יש זמני ריצה חלופיים, צריך להתקין אפליקציות דרך PackageManager בארגזי חול נפרדים של Android (מזהי משתמשים ב-Linux וכו').

  • ייתכן שזמני ריצה חלופיים מספקים ארגז חול יחיד של Android לכל האפליקציות שמשתמשות בסביבת זמן הריצה החלופית.

9.5. תמיכה במשתמשים מרובים

Android כולל תמיכה במשתמשים מרובים ומספק תמיכה בבידוד מלא של המשתמשים.

  • ייתכן שהטמעת מכשירים במכשירים שונים, אבל לא מומלץ לאפשר שימוש בריבוי משתמשים אם הם משתמשים במדיה נשלפת לאחסון חיצוני ראשי.

אם ההטמעות במכשירים כוללות כמה משתמשים, הן:

  • [C-1-1] חייבת לעמוד בדרישות הבאות לגבי תמיכה במשתמשים מרובים.
  • [C-1-2] חובה להטמיע לכל משתמש מודל אבטחה שתואם למודל האבטחה של פלטפורמת Android, כפי שמוגדר במסמך העזר בנושא אבטחה והרשאות בממשקי ה-API.
  • [C-1-3] לכל מופע של משתמש חייבת להיות ספריות נפרדות ומבודדות של אחסון אפליקציות (שנקראות גם /sdcard).
  • [C-1-4] חובה לוודא שאפליקציות שנמצאות בבעלותו של משתמש מסוים שפועלות בשמו לא יכולות להציג, לקרוא או לכתוב בקבצים שבבעלות משתמש אחר, גם אם הנתונים של שני המשתמשים מאוחסנים באותה נפח אחסון או באותה מערכת קבצים.
  • [C-1-5] חובה להצפין את התוכן של כרטיס ה-SD כאשר האפשרות 'ריבוי משתמשים' מופעלת באמצעות מפתח המאוחסן רק במדיה שאינה נשלפת, הנגישה למערכת רק אם יישומים של מכשירים משתמשים במדיה נשלפת עבור ממשקי API של אחסון חיצוני. במצב כזה, קובצי המדיה לא יהיו ניתנים לקריאה על ידי מחשב מארח, ולכן ההטמעות של המכשירים יצטרכו לעבור ל-MTP או למערכת דומה כדי לספק למחשבים של המארחים גישה לנתונים של המשתמש הנוכחי.

אם בהטמעות המכשירים נכללים כמה משתמשים ולא מצהירים על התכונה הניסיונית android.hardware.telephony, הם:

  • [C-2-1] חייבת לתמוך בפרופילים מוגבלים, תכונה שמאפשרת לבעלי מכשירים לנהל משתמשים נוספים ואת היכולות שלהם במכשיר. עם פרופילים מוגבלים, בעלי מכשירים יכולים להגדיר במהירות סביבות נפרדות שבהן משתמשים נוספים יוכלו לעבוד, עם יכולת לנהל הגבלות פרטניות יותר באפליקציות שזמינות בסביבות האלה.

אם בהטמעות המכשירים נכללים כמה משתמשים ומצהירים על דגל התכונה android.hardware.telephony:

  • [C-3-1] אסור לתמוך בפרופילים מוגבלים, אבל הם חייבים להתאים להטמעת AOSP של אמצעי בקרה כדי לאפשר או להשבית את הגישה של משתמשים אחרים לשיחות קוליות ול-SMS.

9.6. אזהרת SMS פרימיום

ב-Android יש תמיכה באזהרה של משתמשים מפני הודעות SMS פרימיום יוצאות. הודעות SMS פרימיום הן הודעות טקסט שנשלחות לשירות שרשום אצל ספק סלולר והן עשויות לחייב את המשתמש.

אם הטמעות המכשירים מצהירות על תמיכה ב-android.hardware.telephony, הן:

  • [C-1-1] חובה להזהיר משתמשים לפני שליחת הודעת SMS למספרים שמזוהים באמצעות ביטויים רגולריים שמוגדרים בקובץ /data/misc/sms/codes.xml במכשיר. פרויקט הקוד הפתוח של Android ב-upstream מספק הטמעה שעומדת בדרישה הזו.

9.7. תכונות אבטחה

הטמעות של מכשירים חייבות להבטיח תאימות לתכונות האבטחה בליבה ובפלטפורמה, כפי שמתואר בהמשך.

ארגז החול של Android כולל תכונות שמשתמשות במערכת בקרת גישה (MAC) חיונית ל-Linux (SELinux), הרצה בארגז חול (sandboxing) ב-seccomp ותכונות אבטחה נוספות בליבה (kernel) של Linux. הטמעות מכשירים:

  • [C-0-1] חייבת לשמור על תאימות לאפליקציות קיימות, גם אם SELinux או תכונות אבטחה אחרות מוטמעות מתחת ל-framework של Android.
  • [C-0-2] ממשק משתמש לא גלוי כשתזוהה הפרת אבטחה ונחסם בהצלחה על ידי תכונת האבטחה שמוטמעת מתחת ל-framework של Android. עם זאת, יכול להיות שממשק המשתמש יהיה גלוי כשמתרחשת הפרת אבטחה לא חסומה שמובילה לניצול מוצלח.
  • [C-0-3] אסור להפעיל את SELinux או כל תכונת אבטחה אחרת שמוטמעת מתחת למסגרת Android, שאפשר להגדיר למשתמש או למפתח האפליקציה.
  • [C-0-4] אסור לאפשר לאפליקציה שעשויה להשפיע על אפליקציה אחרת באמצעות ממשק API (כגון Device Administration API) להגדיר מדיניות שמפרה את התאימות.
  • [C-0-5] חייבים לפצל את מסגרת המדיה לכמה תהליכים כדי שאפשר יהיה להעניק גישה בצורה מצומצמת יותר לכל תהליך, כפי שמתואר באתר של פרויקט הקוד הפתוח של Android.
  • [C-0-6] חובה להטמיע מנגנון ארגז חול (sandboxing) של אפליקציית ליבה שמאפשר לסנן קריאות מערכת באמצעות מדיניות שניתנת להגדרה מתוכנות עם שרשורים מרובים. פרויקט קוד פתוח של Android ב-upstream עומד בדרישה הזו באמצעות הפעלת seccomp-BPF עם סנכרון קבוצת שרשור (TSYNC), כפי שמתואר בקטע 'הגדרת ליבה' (Kernel) של source.android.com.

התכונות של תקינות הליבה וההגנה העצמית הן חלק בלתי נפרד מאבטחה של Android. הטמעות מכשירים:

  • [C-0-7] חובה להטמיע הגנות מפני גלישת מאגר נתונים זמני של ליבה (kernel) (למשל CONFIG_CC_STACKPROTECTOR_STRONG).
  • [C-0-8] חובה ליישם אמצעי הגנה מחמירים על זיכרון ליבה (kernel) כאשר קוד ההפעלה הוא לקריאה בלבד, נתונים לקריאה בלבד לא ניתנים להפעלה ולא לכתיבה, ונתונים ניתנים לכתיבה לא ניתנים להפעלה (למשל CONFIG_DEBUG_RODATA או CONFIG_STRICT_KERNEL_RWX).
  • [C-0-9] חובה להטמיע בדיקת גבולות של גודל אובייקט סטטי ודינמי של עותקים בין מרחב משתמש ומרחב ליבה (kernel) (למשל, CONFIG_HARDENED_USERCOPY) במכשירים שנשלחו במקור עם רמת API 28 ומעלה.
  • [C-0-10] אסור להפעיל זיכרון-מרחב משתמש כשמפעילים מצב ליבה (kernel) (למשל, PXN של חומרה או אמולציה דרך CONFIG_CPU_SW_DOMAIN_PAN או CONFIG_ARM64_SW_TTBR0_PAN) במכשירים שנשלחו במקור עם רמת API 28 ומעלה.
  • [C-0-11] אסור לקרוא או לכתוב זיכרון-מרחב משתמש בליבה (kernel) מחוץ לממשקי API רגילים לגישה לעותק משתמש (למשל, מספר חשבון קבוע (PAN) בחומרה, או אמולציה דרך CONFIG_CPU_SW_DOMAIN_PAN או CONFIG_ARM64_SW_TTBR0_PAN, במכשירים שנשלחו במקור עם רמת API 28 ומעלה.
  • [C-0-12] חובה להטמיע בידוד של דף ליבה (kernel) בכל המכשירים שנשלחו במקור עם API ברמה 28 ומעלה (למשל: CONFIG_PAGE_TABLE_ISOLATION או 'CONFIG_UNMAP_KERNEL_AT_EL0').
  • [SR] מומלץ מאוד לשמור נתוני ליבה שנכתבו רק במהלך האתחול ומסומנים לקריאה בלבד לאחר האתחול (למשל __ro_after_init).
  • [SR] מומלץ מאוד להגדיר באופן אקראי את הפריסה של קוד הליבה ושל הזיכרון, וכדי להימנע מחשיפות שעלולות לסכן את הרנדומיזציה (למשל, CONFIG_RANDOMIZE_BASE עם אנטרופיה של תוכנת אתחול דרך /chosen/kaslr-seed Device Tree node או EFI_RNG_PROTOCOL).

אם הטמעות המכשירים משתמשות בליבה (kernel) של Linux, הן:

  • [C-1-1] חובה להטמיע את SELinux.
  • [C-1-2] חייבים להגדיר את SELinux למצב אכיפה גלובלי.
  • [C-1-3] חובה להגדיר את כל הדומיינים במצב אכיפה. אסור להשתמש בדומיינים של מצב מתירנות, כולל דומיינים ספציפיים למכשיר או לספק.
  • [C-1-4] אסור לשנות, להשמיט או להחליף את הכללים של אף פעם שלא קיימים בתיקיית המערכת/סמדיניות שמסופקת בפרויקט קוד פתוח של Android (AOSP) ב-upstream. בנוסף, המדיניות חייבת להדר את כל כללי אף פעם קיימים, גם בדומיינים של AOSP SELinux וגם בדומיינים ספציפיים למכשירים או לספקים.
  • [C-1-5] חובה להפעיל אפליקציות של צד שלישי שמטרגטות לרמת API 28 ומעלה בארגזי חול של SELinux לכל אפליקציה, כולל הגבלות SELinux לכל אפליקציה, בספריית הנתונים הפרטיים של כל אפליקציה.
  • אמורה לשמור את מדיניות ברירת המחדל של SELinux שצוינה בתיקיית המערכת/sepolicy של פרויקט הקוד הפתוח של Android ב-upstream, ולהוסיף אותה למדיניות הזו רק לצורך הגדרה ספציפית למכשיר שלה.

אם הטמעות המכשיר כבר הושקו בגרסה קודמת של Android ולא יכולות לעמוד בדרישות [C-1-1] ו-[C-1-5] באמצעות עדכון תוכנה, יכול להיות שהן יהיו פטורות מהדרישות האלה.

אם הטמעות של מכשירים משתמשות בליבה (kernel) אחרת מלבד Linux, הן:

  • [C-2-1] חובה להשתמש במערכת בקרת גישה הכרחית שמקבילה ל-SELinux.

ב-Android יש כמה תכונות של הגנה לעומק, חלק בלתי נפרד מאבטחת המכשיר.

הטמעות מכשירים:

  • [C-SR] מומלץ מאוד לא להשבית את Control-Flow Integrity (CFI) או את Integer Overflow Sanitization (IntSan) ברכיבים שבהם היא מופעלת.
  • [C-SR] מומלץ מאוד להפעיל גם את CFI וגם את IntSan ברכיבים נוספים של מרחב משתמש רגיש מבחינת אבטחה, כפי שמוסבר ב-CFI וב-IntSan.

9.8. פרטיות

9.8.1. היסטוריית שימוש

מערכת Android שומרת את ההיסטוריה של הבחירות של המשתמש ומנהלת את ההיסטוריה הזו באמצעות UsageStatsManager.

הטמעות מכשירים:

  • [C-0-1] חובה לשמור על תקופת שמירה סבירה של היסטוריית משתמשים כזו.
  • [SR] מומלץ מאוד להשאיר את תקופת השמירה של 14 ימים כפי שהוגדרה כברירת מחדל בהטמעת AOSP.

מערכת Android שומרת את אירועי המערכת באמצעות המזהים StatsLog, ומנהלת את ההיסטוריה הזו באמצעות StatsManager ו-IncidentManager System API.

הטמעות מכשירים:

  • [C-0-2] חובה לכלול רק את השדות המסומנים ב-DEST_AUTOMATIC בדוח האירוע שנוצר על ידי מחלקת ה-System API IncidentManager.
  • [C-0-3] אסור להשתמש במזהי האירועים של המערכת כדי לתעד אירוע אחר מלבד מה שמתואר במסמכי ה-SDK של StatsLog. אם נרשמים עוד אירועי מערכת, יכול להיות שהם ישתמשו במזהה Atom אחר בטווח שבין 100,000 ל-200,000.

9.8.2. מתבצעת הקלטה

הטמעות מכשירים:

  • [C-0-1] אסור לטעון מראש או להפיץ רכיבי תוכנה מוכנים מראש ששולחים את המידע הפרטי של המשתמש (למשל הקשות, טקסט שמוצג במסך) אל מחוץ למכשיר ללא הסכמת המשתמש או ניקוי התראות מתמשכות.

אם הטמעות המכשיר כוללות פונקציונליות במערכת שמתעדת את התוכן שמוצג במסך ו/או מקליטה את שידור האודיו שמופעל במכשיר:

  • [C-1-1] חייבת להיות התראה מתמשכת למשתמש בכל פעם שהפונקציונליות הזו מופעלת, והמערכת מתעדת/מקליטה באופן פעיל.

אם הטמעות המכשיר כוללות רכיב שמופעל מחוץ לאריזה ומסוגל להקליט אודיו ברקע כדי להסיק מידע שימושי לגבי ההקשר של המשתמש:

  • [C-2-1] אסור לאחסן באחסון מתמיד במכשיר או לשדר מהמכשיר את האודיו הגולמי המוקלט או כל פורמט שניתן להמיר בחזרה לאודיו המקורי או לפקס קרוב, למעט בהסכמת המשתמש המפורשת.

9.8.3. קישוריות

אם בהטמעות של מכשירים יש יציאת USB עם תמיכה במצב ציוד היקפי בחיבור USB, בהמשך:

  • [C-1-1] חובה להציג ממשק משתמש שמבקש את הסכמת המשתמש לפני שמאפשרים גישה לתוכן של האחסון המשותף דרך יציאת ה-USB.

9.8.4. תנועה ברשת

הטמעות מכשירים:

  • [C-0-1] חובה להתקין מראש את אותם אישורי בסיס עבור חנות של רשות האישורים (CA) המהימנה על ידי המערכת, כפי שמסופק בפרויקט קוד פתוח של Android ב-upstream.
  • [C-0-2] חובה לשלוח את המוצר עם חנות בסיס ריקה של משתמש שמנפיקה את האישורים (CA).
  • [C-0-3] חובה להציג למשתמש אזהרה שמציינת שיכול להיות שיתבצע מעקב אחרי התנועה ברשת, כשנוסיף את רשות האישורים הבסיסית של המשתמש.

אם התנועה במכשירים מנותבת דרך VPN, הטמעות המכשירים:

  • [C-1-1] חובה להציג למשתמש אזהרה שמציינת:
    • ייתכן שיש מעקב אחרי התנועה הזו ברשת.
    • התנועה הזו ברשת מנותבת דרך אפליקציית ה-VPN הספציפית שמספקת את ה-VPN.

אם הטמעות המכשיר כוללות מנגנון, שמופעל מחוץ לאריזה כברירת מחדל, שמנתב את תעבורת הנתונים ברשת דרך שרת proxy או שער VPN (לדוגמה, טעינה מראש של שירות VPN עם הענקת android.permission.CONTROL_VPN), הן:

  • [C-2-1] חובה לבקש את הסכמת המשתמש לפני הפעלה של המנגנון הזה, אלא אם ה-VPN מופעל על ידי בקר מדיניות המכשירים דרך DevicePolicyManager.setAlwaysOnVpnPackage(). במקרה כזה המשתמש לא צריך לתת הסכמה נפרדת, אלא רק לקבל הודעה על כך.

אם הטמעות של מכשירים מטמיעות את האפשרות לאפשר למשתמש להפעיל תמיד את הפונקציה 'VPN שפועל כל הזמן' באפליקציית VPN של צד שלישי:

  • [C-3-1] חובה להשבית בקובץ AndroidManifest.xml את העלות הכספית של המשתמש הזה לאפליקציות שלא תומכות בשירות VPN שפועל כל הזמן. לשם כך, צריך להגדיר את המאפיין SERVICE_META_DATA_SUPPORTS_ALWAYS_ON לערך false.

9.9. הצפנה של מאגר הנתונים

אם ביצועי הקריפטוגרפיה מסוג Advanced Encryption Standard (AES) נמדדים באמצעות טכנולוגיית AES בעלת הביצועים הטובים ביותר הזמינה במכשיר (למשל, תוספי ARM Cryptography)

  • [C-1-1] חייבת לתמוך בהצפנת אחסון נתונים של הנתונים הפרטיים של האפליקציה (מחיצה /data), וכן במחיצת האחסון המשותף של האפליקציה (המחיצה /sdcard), אם היא חלק קבוע ולא נשלף מהמכשיר, למעט הטמעות של מכשירים שבדרך כלל משותפות (למשל טלוויזיה).
  • [C-1-2] חובה להפעיל את ההצפנה של אחסון הנתונים כברירת מחדל בזמן שהמשתמש השלים את חוויית ההגדרה הראשונית, למעט הטמעות במכשירים שבדרך כלל משותפות (למשל טלוויזיה).

אם הביצועים הקריפטוגרפיים של AES הם או נמוכים מ- 50 MiB/sec, בהטמעות מכשירים ייעשה שימוש ב-Adiantum-XChaCha12-AES במקום בפורמט AES-1 (AES-256-XTS) שמצוין בסעיף 9.9.2 [C-1-5]; AES-256 ב-Adiantum-XChaCha12-AES

אם הטמעות של מכשירים כבר הושקו בגרסה קודמת של Android ואי אפשר לעמוד בדרישה באמצעות עדכון תוכנת מערכת, יכול להיות שהן יהיו פטורות מהדרישות שפורטו למעלה.

הטמעות מכשירים:

9.9.1. הפעלה ישירה

הטמעות מכשירים:

  • [C-0-1] חייבים להטמיע את ממשקי ה-API של מצב הפעלה ישירה גם אם הם לא תומכים בהצפנת Storage.

  • [C-0-2] ה-Intents ACTION_LOCKED_BOOT_COMPLETED ו-ACTION_USER_UNLOCKED עדיין חייבים להיות משודרים כדי לאותת לאפליקציות עם מודעות לאתחול ישיר שמיקומי אחסון בהצפנת מכשיר (DE) והצפנה עם פרטי כניסה זמינים עבור המשתמש.

9.9.2. הצפנה מבוססת קבצים

אם הטמעות של מכשירים תומכות ב-FBE:

  • [C-1-1] חובה לבצע אתחול בלי לאתגר את המשתמש להזנת פרטי כניסה ולאפשר לאפליקציות שמופעלות בצורה ישירה (Direct Run) לגשת לאחסון בהצפנה במכשיר (DE) אחרי שידור ההודעה של ACTION_LOCKED_BOOT_COMPLETED.
  • [C-1-2] חייבים לאפשר גישה לאחסון של פרטי כניסה מוצפנים רק לאחר שהמשתמש ביטל את נעילת המכשיר על ידי אספקת פרטי הכניסה שלו (למשל קוד גישה, קוד אימות, קו ביטול נעילה או טביעת אצבע) ושודרה ההודעה של ACTION_USER_UNLOCKED.
  • [C-1-3] אסור להציע שיטה כלשהי לביטול הנעילה של אחסון מוגן לפי CE ללא פרטי הכניסה שסופקו על ידי המשתמש או מפתח נאמנות רשום.
  • [C-1-4] חייבת לתמוך ב'הפעלה מאומתת' ולוודא שמפתחות ה-DE קשורים באופן קריפטוגרפי ל-Root of Trust של החומרה.
  • [C-1-5] חייבת להיות תמיכה בהצפנת תוכן של קבצים באמצעות AES-256-XTS. AES-256-XTS מתייחס לתקן ההצפנה המתקדם עם אורך מפתח של 256 ביט, שמופעל במצב XTS. האורך המלא של מפתח XTS הוא 512 ביטים.

  • [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] כברירת מחדל, חייבים להשתמש בהצפנה, אורכי המפתחות ומצבים שנתמכים על ידי המנדטוריות.

  • [C-SR] מומלץ מאוד להצפין מטא-נתונים של מערכת קבצים, כמו גודל הקבצים, הבעלות, המצבים ומאפיינים מורחבים (xattrs), עם מפתח קריפטוגרפי שקשור ל-Root of Trust של חומרת המכשיר.

  • צריכה להיות מותקנת מראש אפליקציות חיוניות שהותקנו מראש (למשל שעון מעורר, טלפון, Messenger) עם מודעות לאתחול ישיר.

  • ייתכן שתהיה תמיכה בצפנים, באורך מפתחות ובמצבים חלופיים להצפנה של תוכן קבצים ושמות של קבצים.

פרויקט הקוד הפתוח של Android ב-upstream מספק הטמעה מועדפת של התכונה הזו, על סמך תכונת ההצפנה בליבה (kernel) ext4 של Linux.

9.9.3. הצפנת דיסק מלא

אם הטמעות המכשיר תומכות בהצפנת דיסק מלאה (FDE):

  • [C-1-1] חובה להשתמש ב-AES במצב שמיועד לאחסון (לדוגמה, XTS או CBC-ESSIV), עם מפתח הצפנה באורך 128 ביט לפחות.
  • [C-1-2] חובה להשתמש בקוד גישה כברירת מחדל כדי לארוז את מפתח ההצפנה, ואסור לכתוב את מפתח ההצפנה באחסון בשום שלב בלי להצפין אותו.
  • [C-1-3] פרוטוקול AES חייב להצפין את מפתח ההצפנה כברירת מחדל, אלא אם המשתמש מבטל את הסכמתו באופן מפורש, למעט כשהוא בשימוש פעיל, כשפרטי הכניסה למסך הנעילה נמתחים באמצעות אלגוריתם מתיחה איטית (למשל PBKDF2 או scrypt).
  • [C-1-4] אלגוריתם ברירת המחדל שלמעלה למתיחת הסיסמאות חייב להיות מקושר באופן קריפטוגרפי למאגר המפתחות, אם המשתמש לא ציין פרטי כניסה במסך הנעילה או השבית את השימוש בקוד הגישה להצפנה, והמכשיר מספק מאגר מפתחות שמגובה על ידי חומרה.
  • [C-1-5] אסור לשלוח מפתח הצפנה מהמכשיר (גם אם הוא ארוז עם קוד הגישה של המשתמש ו/או מפתח שקשור לחומרה).

פרויקט הקוד הפתוח של Android ב-upstream מספק את ההטמעה המועדפת של התכונה הזו, בהתבסס על תכונת הליבה של Linux dm-crypt.

9.10. תקינות המכשיר

הדרישות הבאות מבטיחות שקיימת שקיפות לגבי סטטוס תקינות המכשיר. הטמעות מכשירים:

  • [C-0-1] חובה לדווח בצורה נכונה באמצעות שיטת ה-API של המערכת PersistentDataBlockManager.getFlashLockState() אם מצב תוכנת האתחול מאפשר להבהב של תמונת המערכת. המצב FLASH_LOCK_UNKNOWN שמור להטמעות של מכשירים שמשדרגים מגרסה קודמת של Android שבה לא הייתה השיטה החדשה של ממשק ה-API של המערכת.

  • [C-0-2] חייבת להיות תמיכה ב'הפעלה מאומתת' לשמירה על תקינות המכשיר.

אם הטמעות המכשיר כבר הושקו ללא תמיכה ב'הפעלה מאומתת' בגרסה קודמת של Android ואי אפשר להוסיף תמיכה בתכונה הזו באמצעות עדכון תוכנה של המערכת, יכול להיות שהן יהיו פטורות מהדרישה הזו.

'הפעלה מאומתת' היא תכונה שמבטיחה את תקינות התוכנה של המכשיר. אם הטמעות במכשירים תומכים בתכונה הזו:

  • [C-1-1] חובה להצהיר על דגל הפיצ'ר של הפלטפורמה android.software.verified_boot.
  • [C-1-2] חובה לבצע אימות בכל רצף אתחול.
  • [C-1-3] חובה להתחיל את האימות ממפתח חומרה שלא ניתן לשינוי, שהוא ה-Root of Trust (תחושת ה-Root of Trust) ולעבור עד למחיצת המערכת.
  • [C-1-4] חובה להטמיע כל שלב אימות כדי לבדוק את התקינות והאותנטיות של כל הבייטים בשלב הבא לפני הרצת הקוד בשלב הבא.
  • [C-1-5] חובה להשתמש באלגוריתמים לאימות חזקים כמו ההמלצות הנוכחיות של NIST לאלגוריתמים לגיבוב (SHA-256) ולגדלים של מפתחות ציבוריים (RSA-2048).
  • [C-1-6] אסור לאפשר אתחול כשאימות המערכת נכשל, אלא אם המשתמש מסכים לנסות להפעיל אותו בכל מקרה. במקרה כזה, אין להשתמש בנתונים מבלוקים של אחסון לא מאומת.
  • [C-1-7] אסור לאפשר שינוי של מחיצות מאומתות במכשיר, אלא אם המשתמש ביטל את הנעילה של תוכנת האתחול באופן מפורש.
  • [C-SR] אם יש במכשיר מספר צ'יפים נפרדים (למשל רדיו, מעבד תמונות מיוחד), מומלץ מאוד לבדוק כל שלב לאחר האתחול תהליך האתחול של כל אחד מהצ'יפים האלה.
  • [C-1-8] חובה להשתמש באחסון מסוג tamper-evident): לאחסון אם תוכנת האתחול לא נעולה. המשמעות של פגיעה באחסון היא שתוכנת האתחול יכולה לזהות אם מישהו חיבל באחסון מתוך Android.
  • [C-1-9] בזמן השימוש במכשיר חייבת להופיע בקשה לאישור פיזי לפני שמאפשרים מעבר ממצב נעילה של תוכנת האתחול למצב ביטול הנעילה של תוכנת האתחול.
  • [C-1-10] חובה להטמיע הגנה על חזרה למצב קודם למחיצות שמשמשות את Android (למשל הפעלה, מחיצות מערכת) ולהשתמש באחסון שמבטיח התעסקות במכשיר לאחסון המטא-נתונים שמשמשים לקביעת הגרסה המינימלית של מערכת ההפעלה המותרת.
  • [C-SR] מומלץ מאוד לאמת את כל קובצי ה-APK של האפליקציות בעלי ההרשאות עם שרשרת אמון שפועלת ב-/system, שמוגנת על ידי הפעלה מאומתת.
  • [C-SR] מומלץ מאוד לאמת ארטיפקטים של הפעלה שנטענו על ידי אפליקציה בעלת הרשאות מחוץ לקובץ ה-APK שלה (כמו קוד שנטען באופן דינמי או קוד שעבר הידור) לפני שמפעילים אותם, או מומלץ מאוד לא להפעיל אותם.
  • יש להטמיע הגנת חזרה למצב קודם עבור כל רכיב עם קושחה קבועה (למשל מודם, מצלמה) ויש להשתמש באחסון מפני זיוף לצורך אחסון המטא-נתונים המשמשים לקביעת הגרסה המינימלית המותרת.

אם הטמעות מכשירים כבר הושקו ללא תמיכה ב-C-1-8 עד C-10 בגרסה קודמת של Android, ולא ניתן להוסיף להן תמיכה בדרישות האלה באמצעות עדכון תוכנת מערכת, יכול להיות שהן יהיו פטורות מהדרישות.

פרויקט קוד פתוח של Android ב-upstream מספק הטמעה מועדפת של התכונה הזו במאגר external/avb/, ואפשר לשלב אותו בתוכנת האתחול שמשמשת לטעינת Android.

הטמעות מכשירים:

אם ההטמעות במכשירים תומכים ב-Android Protected Certificate API, הם:

  • [C-3-1] חובה לדווח על true עבור ה-API של ConfirmationPrompt.isSupported().
  • [C-3-2] חשוב לוודא שחומרה מאובטחת תקבל שליטה מלאה על המסך, כך שמערכת ההפעלה של Android לא תוכל לחסום אותה ללא זיהוי באמצעות החומרה המאובטחת.
  • [C-3-3] חייבים לוודא שהחומרה המאובטחת מקבלת שליטה מלאה על מסך המגע.

9.11. מפתחות ופרטי כניסה

מערכת Android Keystore מאפשרת למפתחי אפליקציות לאחסן מפתחות קריפטוגרפיים בקונטיינר ולהשתמש בהם בפעולות קריפטוגרפיות באמצעות KeyChain API או Keystore API. הטמעות מכשירים:

  • [C-0-1] חובה לאפשר ייבוא או יצירה של לפחות 8,192 מפתחות.
  • [C-0-2] חובה להגדיר מספר ניסיונות להגבלת קצב של אימות במסך הנעילה וחייב להיות אלגוריתם של השהיה מעריכית לפני ניסיון חוזר (exponential backoff). מעבר ל-150 ניסיונות כושלים, העיכוב חייב להיות לפחות 24 שעות בכל ניסיון.
  • אסור להגביל את מספר המפתחות שאפשר ליצור

כשהטמעת המכשיר תומכת במסך נעילה מאובטח, הוא:

  • [C-1-1] חייבים לגבות את ההטמעה של מאגר המפתחות באמצעות סביבת הפעלה מבודדת
  • [C-1-2] חייבות להיות הטמעות של אלגוריתמים קריפטוגרפיים RSA, AES, ECDSA ו-HMAC, וגם פונקציות גיבוב (hash) משפחתיות של MD5, SHA1 ו-SHA-2, כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמופרד באופן מאובטח מהקוד שפועל בליבה (kernel) ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבהם קוד ליבה או מרחב משתמשים יכול לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. פרויקט הקוד הפתוח של Android (AOSP) ב-upstream עומד בדרישה הזו באמצעות ההטמעה של Trusty. במקום זאת, יש עוד אפשרויות לפתרון מבוסס ARM TrustZone או הטמעה מאובטחת של צד שלישי עם בידוד מתאים שמבוסס על hypervisor.
  • [C-1-3] חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק כשהפעולה מבוצעת בהצלחה, תתאפשר שימוש במפתחות שקשורים לאימות. יש לאחסן את פרטי הכניסה של מסך הנעילה באופן שיאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. פרויקט הקוד הפתוח של Android ב-upstream מספק את Gatekeeper Hardware Layer Abstraction Layer (HAL) ואת Trusty, ואפשר להשתמש בהם כדי לעמוד בדרישה הזו.
  • [C-1-4] חייבת להיות תמיכה באימות עם מפתחות כאשר מפתח חתימת האימות מוגן באמצעות חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות חתימת האימות בין מספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת הדרכים לעמוד בדרישה הזו היא לשתף את אותו מפתח אימות, אלא אם יוצרים לפחות 100,000 יחידות של מק"ט נתון. אם מפיקים יותר מ-100,000 יחידות של מק"ט, יכול להיות שייעשה שימוש במפתח שונה לכל 100,000 יחידות.
  • [C-1-5] חובה לאפשר למשתמשים לבחור את הזמן הקצוב לתפוגה של מצב שינה לצורך מעבר ממצב נעילה למצב נעול. הזמן הקצוב לתפוגה שמוגדר במכשיר הוא עד 15 שניות.

חשוב לשים לב שאם הטמעה של מכשיר כבר הושקה בגרסה קודמת של Android, המכשיר הזה פטור מהדרישה לגבות מאגר מפתחות בסביבת הפעלה מבודדת, ולתמוך באימות (attestation) של המפתחות, אלא אם מוצהר על התכונה android.hardware.fingerprint שדורשת מאגר מפתחות שמגובה על ידי סביבת הפעלה מבודדת.

9.11.1. מסך נעילה מאובטח

הטמעת AOSP מבוססת על מודל אימות רב-שכבתי שבו אפשר לגבות אימות ראשי שמבוסס על מפעל ידע באמצעות נתונים ביומטריים חזקים משניים או שיטות שלישיות חלשות יותר.

הטמעות מכשירים:

  • [C-SR] מומלץ מאוד להגדיר רק אחת מהאפשרויות הבאות כשיטת האימות הראשית:
    • קוד אימות מספרי
    • סיסמה אלפאנומרית
    • תבנית החלקה על גבי רשת של 3x3 נקודות בדיוק

חשוב לשים לב ששיטות האימות שצוינו למעלה נקראות שיטות האימות הראשיות המומלצות במסמך הזה.

אם הטמעות במכשירים מוסיפים או משנים את שיטות האימות הראשיות המומלצות ומשתמשים בשיטת אימות חדשה כדרך מאובטחת לנעילת המסך, שיטת האימות החדשה:

  • [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] חייב לעמוד בכל הדרישות המתוארות בסעיף 7.3.10.2.
  • [C-4-2] חייב להיות מנגנון של חזרה למצב הקודם כדי להשתמש באחת משיטות האימות הראשיות המומלצות המבוססות על סוד ידוע.
  • [C-4-3] חובה להשבית ולאפשר לאימות הראשי המומלץ רק ביטול של נעילת המסך כשהאפליקציה Device Policy Controller (DPC) הגדירה את המדיניות בנושא תכונת ההגנה על ידי הקשה על ידי קריאה ל-method DevicePolicyManager.setKeyguardDisabledFeatures(), יחד עם כל אחד מהסימונים הביומטריים המשויכים (למשל KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE או KEYGUARD_DISABLE_IRIS).
  • [C-4-4] חובה לבקש מהמשתמש לבצע את האימות הראשי המומלץ (למשל: קוד אימות, קו ביטול נעילה, סיסמה) לפחות פעם ב-72 שעות או פחות.
  • [C-4-5] שיעור קבלה שגוי חייב להיות גבוה או גבוה מזה שנדרש לחיישן טביעות האצבע, כפי שמתואר בסעיף סעיף 7.3.10. לחלופין, חייבים להשבית אותו, ולאפשר לאימות הראשי המומלץ רק לבטל את נעילת המסך רק כשהאפליקציה Device Policy Controller (DPC) הגדירה את המדיניות בנושא איכות הסיסמה באמצעות השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר.PASSWORD_QUALITY_BIOMETRIC_WEAK
  • [C-SR] מומלץ מאוד ששיעורי התרמיות של זיופים ושל חיקויים יהיו זהים לנדרש עבור חיישן טביעות אצבע או גדולים יותר, כפי שמתואר סעיף 7.3.10.
  • [C-4-6] חייב להיות צינור עיבוד נתונים מאובטח כך שפגיעה במערכת ההפעלה או בליבה לא תאפשר להחדיר נתונים ישירות כדי לבצע אימות שקרי כמשתמש.
  • [C-4-7] חובה לבצע התאמה עם פעולת אישור מפורשת (למשל: לחיצה על לחצן) כדי לאפשר גישה למפתחות של מאגר המפתחות אם האפליקציה מגדירה את הערך true כ-KeyGenParameterSpec.Built.setUserAuthenticationRequired() והערך הביומטרי הוא פסיבי (למשל, פנים או קשתית העין, שלא קיים בהם אות מפורש של כוונה).
  • [C-SR] מומלץ מאוד שפעולת האישור לשימוש במידע ביומטרי פסיבית תתבצע באופן מאובטח כך שלא תהיה אפשרות לזייף אותה דרך מערכת ההפעלה או בליבה (kernel). לדוגמה, המשמעות היא שפעולת האישור שמבוססת על לחצן פיזי מנותבת דרך סיכת קלט/פלט (GPIO) לשימוש כללי בלבד (GPIO) של רכיב מאובטח (SE) שלא ניתן לנוע בכל אמצעי אחר מלבד לחיצה על לחצן פיזי.

אם שיטות האימות הביומטרי לא עומדות בשיעורי הקבלה של הזיוף וההתחזות, כפי שמתואר בסעיף 7.3.10:

  • [C-5-1] חובה להשבית את השיטות אם האפליקציה Device Policy Controller (DPC) הגדירה את המדיניות בנושא איכות הסיסמאות באמצעות השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • [C-5-2] חובה לאמת את המשתמש לצורך אימות ראשי מומלץ (למשל: קוד אימות, קו ביטול נעילה, סיסמה) אחרי 4 שעות של זמן קצוב לתפוגה ללא פעילות. הזמן הקצוב לתפוגה שהוגדר לחוסר פעילות מתאפס אחרי אישור מוצלח של פרטי הכניסה של המכשיר.
  • [C-5-3] אסור להתייחס לשיטות האלה כמסך נעילה מאובטח, והן חייבות לעמוד בדרישות שמתחילות ב-C-8 בסעיף הזה בהמשך.

אם הטמעות במכשירים מוסיפים או משנים את שיטות האימות לביטול הנעילה של מסך הנעילה, ושיטת אימות חדשה מבוססת על אסימון פיזי או על המיקום:

  • [C-6-1] נדרש להם מנגנון של חזרה למצב הקודם כדי להשתמש באחת משיטות האימות הראשיות המומלצות המבוססות על סוד ידוע, ועומדות בדרישות כדי שיטופלו כמסך נעילה מאובטח.
  • [C-6-2] השיטה החדשה חייבת להיות מושבתת ורק אחת משיטות האימות הראשיות המומלצות לביטול נעילת המסך כשהאפליקציה Device Policy Controller (DPC) הגדירה את המדיניות באמצעות השיטה DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) או השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מאשר PASSWORD_QUALITY_UNSPECIFIED.
  • [C-6-3] חובה לאמת את המשתמש לגבי אחת משיטות האימות הראשיות המומלצות (למשל: קוד אימות, קו ביטול נעילה, סיסמה) לפחות פעם אחת בכל 72 שעות או פחות.
  • [C-6-4] אין להתייחס לשיטה החדשה כמסך נעילה מאובטח, והיא חייבת לעמוד בדרישות שמפורטות ב-C-8 בהמשך.

אם בהטמעות של מכשירים יש מסך נעילה מאובטח וכולל סביבה אמינה אחת או יותר שמטמיעה את TrustAgentService System API, הן:

  • [C-7-1] כשנעילת המכשיר דחוית או מופעלת על ידי סביבה אמינה, חייבת להיות אינדיקציה ברורה לכך בתפריט ההגדרות ובמסך הנעילה. לדוגמה, AOSP עומד בדרישה הזו על ידי הצגת טקסט תיאור עבור 'ההגדרה 'נעילה אוטומטית'' ו'לחצן ההפעלה ננעל באופן מיידי' בתפריט ההגדרות, וכן סמל ייחודי במסך הנעילה.
  • [C-7-2] חובה ליישם באופן מלא את כל ממשקי ה-API של סוכן מהימנות ברמה DevicePolicyManager, כמו הקבוע KEYGUARD_DISABLE_TRUST_AGENTS.
  • [C-7-3] אסור להטמיע באופן מלא את הפונקציה TrustAgentService.addEscrowToken() במכשיר שמשמש כמכשיר אישי ראשי (למשל, כף יד). עם זאת, ייתכן שהפונקציה תיושם באופן מלא בהטמעות של מכשירים שבדרך כלל משותפים (למשל, מכשירי Android TV או Automotive).
  • [C-7-4] חובה להצפין את כל האסימונים המאוחסנים שנוספו על ידי TrustAgentService.addEscrowToken().
  • [C-7-5] אסור לאחסן את מפתח ההצפנה באותו מכשיר שבו משתמשים במפתח. לדוגמה, מותר להשתמש במפתח ששמור בטלפון כדי לבטל את הנעילה של חשבון משתמש בטלוויזיה.
  • [C-7-6] חובה להודיע למשתמש על השלכות האבטחה לפני שמפעילים את אסימון הנאמנות כדי לפענח את אחסון הנתונים.
  • [C-7-7] כדי להשתמש באחת משיטות האימות הראשיות המומלצות, חייב להיות מנגנון של חזרה למצב הקודם.
  • [C-7-8] חובה לאמת את המשתמש באחת מהשיטות המומלצות לאימות ראשי (למשל: קוד אימות, קו ביטול נעילה, סיסמה) לפחות פעם אחת בכל 72 שעות או פחות.
  • [C-7-9] אחרי פרק זמן של 4 שעות ללא פעילות, חייבים לאלץ את המשתמש להשתמש באחת מהשיטות המומלצות לאימות הראשי (למשל: קוד אימות, קו ביטול נעילה, סיסמה). הזמן הקצוב לתפוגה שהוגדר לחוסר פעילות מתאפס אחרי אישור מוצלח של פרטי הכניסה של המכשיר.
  • [C-7-10] אסור להתייחס אל כמסך נעילה מאובטח, והוא חייב לפעול בהתאם למגבלות שמפורטות ב-C-8 בהמשך.

אם יישומי המכשיר מוסיפים או משנים את שיטות האימות לביטול הנעילה של מסך הנעילה שאינו מסך נעילה מאובטח, כפי שמתואר למעלה, ומשתמשים בשיטת אימות חדשה לביטול הנעילה של מגן המקשים:

9.11.2. StrongBox

מערכת Android Keystore מאפשרת למפתחי אפליקציות לאחסן מפתחות קריפטוגרפיים במעבד ייעודי מאובטח, וגם בסביבת הביצוע המבודדת שמתוארת למעלה.

הטמעות מכשירים:

  • [C-SR] אנחנו ממליצים מאוד לתמיכה ב-StrongBox.

אם הטמעות במכשירים תומכים ב-StrongBox:

  • [C-1-1] חובה להצהיר על FEATURE_STRONGBOX_KEYSTORE.

  • [C-1-2] חובה לספק חומרה ייעודית מאובטחת שמשמשת לגיבוי של מאגר מפתחות ואבטחה של אימות משתמשים.

  • [C-1-3] חייב להיות מעבד (CPU) נפרד שלא חולק עם מעבד האפליקציות (AP), מטמון, מעבד DRAM, מעבדים משותפים או משאבי ליבה אחרים.

  • [C-1-4] חובה לוודא שציוד היקפי שמשותף עם AP לא יכול לשנות את העיבוד של StrongBox או לקבל מידע כלשהו מ-StrongBox. ייתכן ש-AP משביתים או חוסמים את הגישה ל-StrongBox.

  • [C-1-5] חייב להיות שעון פנימי בעל רמת דיוק סבירה (מעל 10%), חסין מפני מניפולציות על ידי AP.

  • [C-1-6] חייב להיות מחולל מספרים אקראיים אמיתי שמפיק פלט בעל פיזור אחיד ובלתי צפוי.

  • [C-1-7] חייבת להיות עמידות בפני זיוף, כולל עמידות בפני חדירה פיזית ותקלות.

  • [C-1-8] חייבת להיות עמידות בערוץ צדדי, כולל עמידות בפני דליפת מידע באמצעות חשמל, תזמון, קרינה אלקטרומגנטית וערוצי קרינה תרמיים.

  • [C-1-9] חייב להיות אחסון מאובטח שמבטיח סודיות, תקינות, אותנטיות, עקביות ועדכניות התוכן. אסור לקרוא או לשנות את האחסון, למעט בהתאם למה שמותר על ידי ממשקי ה-API של StrongBox.

  • כדי לאמת תאימות ל-[C-1-3] עד [C-1-9], הטמעות המכשירים:

  • [C-SR] מומלץ מאוד לספק עמידות למתקפות פנימיות (IAR), כלומר, גורמים פנימיים עם גישה למפתחות חתימה של קושחה לא יכולים לייצר קושחה שגורמת ל-StrongBox להדליף סודות, כדי לעקוף דרישות אבטחה פונקציונליות או לאפשר גישה אחרת לנתוני משתמש רגישים. הדרך המומלצת ליישום IAR היא לאפשר עדכוני קושחה רק כאשר הסיסמה הראשית של המשתמש מסופקת על ידי IAuthSecret HAL.

9.12. מחיקת נתונים

כל ההטמעות במכשירים:

  • [C-0-1] חובה לספק למשתמשים מנגנון לביצוע 'איפוס לנתוני היצרן'.
  • [C-0-2] חובה למחוק את כל הנתונים שנוצרו על ידי משתמשים. כלומר, כל הנתונים מלבד הנתונים הבאים:
    • תמונת המערכת
    • כל הקבצים של מערכת ההפעלה שנדרשים על ידי תמונת המערכת
  • [C-0-3] חובה למחוק את הנתונים באופן שיעמוד בתקנים רלוונטיים בתחום, כגון NIST SP800-88.
  • [C-0-4] התהליך חייב להפעיל את תהליך איפוס נתוני היצרן שצוין למעלה כשאפליקציית 'בקר לניהול מדיניות מכשירים' של המשתמש הראשי מופעלת על ידי ל-API DevicePolicyManager.wipeData().
  • עשויה לספק אפשרות מהירה למחיקת נתונים שמבצעת רק מחיקה לוגית של נתונים.

9.13. מצב הפעלה בטוחה

ב-Android יש מצב הפעלה בטוח, שמאפשר למשתמשים לבצע הפעלה למצב שבו רק אפליקציות מערכת שהותקנו מראש מורשות לפעול, וכל האפליקציות של צד שלישי מושבתות. המצב הזה, שנקרא 'מצב הפעלה בטוחה', מאפשר למשתמש להסיר אפליקציות של צד שלישי שעלולות להזיק.

הטמעות מכשירים הן:

  • [SR] מומלץ מאוד להטמיע את מצב הפעלה בטוח.

אם בהטמעות של מכשירים מוגדר מצב הפעלה בטוח:

  • [C-1-1] חייבת לספק למשתמש אפשרות להיכנס למצב הפעלה בטוחה באופן שלא יפריע לפעולה של אפליקציות צד שלישי שמותקנות במכשיר, למעט במקרים שבהם האפליקציה של הצד השלישי היא Device Policy Controller, והסימון UserManager.DISALLOW_SAFE_BOOT מוגדר כ-true.

  • [C-1-2] חייבים לספק למשתמש את האפשרות להסיר אפליקציות של צד שלישי במצב בטוח.

  • אמורה לספק למשתמש אפשרות להיכנס למצב הפעלה בטוחה מתפריט ההפעלה באמצעות תהליך עבודה שונה מזה של הפעלה רגילה.

9.14. בידוד של מערכת לכלי רכב

מכשירי Android Automotive צפויים לשתף נתונים עם מערכות משנה קריטיות לרכב באמצעות HAL של הרכב כדי לשלוח ולקבל הודעות ברשתות של רכבים כמו אפיק CAN.

כדי לאבטח את בורסת הנתונים, אפשר להטמיע תכונות אבטחה מתחת לשכבות ה-framework של Android כדי למנוע אינטראקציה זדונית או לא מכוונת עם מערכות המשנה האלה.

9.15. תוכניות מנויים

'תוכניות מנויים' מתייחסות לפרטי תוכנית היחסים של החיוב שסופקו על ידי ספק סלולר דרך SubscriptionManager.setSubscriptionPlans().

כל ההטמעות במכשירים:

  • [C-0-1] חייבים להחזיר תוכניות מנויים רק לאפליקציה של ספק הסלולר שסיפקה אותן במקור.
  • [C-0-2] אסור לגבות או להעלות תוכניות מנויים מרחוק.
  • [C-0-3] חובה לאפשר רק שינויים מברירת המחדל, כמו SubscriptionManager.setSubscriptionOverrideCongested(), מהאפליקציה של ספק הסלולר שמספקת כרגע תוכניות מנויים תקפות.

10. בדיקת תאימות לתוכנה

הטמעות של מכשירים חייבות לעבור את כל הבדיקות שמתוארות בקטע הזה. עם זאת, חשוב לדעת שאף חבילה של בדיקת תוכנה לא מקיפה לחלוטין. לכן, מומלץ מאוד לבצע את השינויים המינימליים בהפניה ובהטמעה המועדפת של Android שזמינה בפרויקט הקוד הפתוח של Android. כך תפחיתו את הסיכון להצגת באגים שגורמים לאי-תאימות שמחייבת עבודה חוזרת ועדכונים פוטנציאליים של המכשיר.

10.1. חבילה לבדיקת תאימות

הטמעות מכשירים:

  • [C-0-1] חייבים לעבור את חבילת בדיקת התאימות ל-Android (CTS) שזמינה בפרויקט הקוד הפתוח של Android, באמצעות תוכנת המשלוח הסופית שמוגדרת במכשיר.

  • [C-0-2] חובה להבטיח תאימות במקרים של אי-בהירות ב-CTS ולכל הטמעה מחדש של חלקים מקוד מקור ההפניה.

ה-CTS נועד לפעול במכשיר אמיתי. כמו כל תוכנה, ה-CTS עשוי עצמו להכיל באגים. הגרסאות של ה-CTS יהיו נפרדות מהגדרת התאימות הזו, וייתכן שגרסאות מרובות של ה-CTS יושקו ל-Android 9.

הטמעות מכשירים:

  • [C-0-3] חובה לעבור את גרסת CTS האחרונה שזמינה כשתוכנת המכשיר הושלמה.

  • עליכם להשתמש בהטמעת קובצי העזר בעץ הקוד הפתוח של Android עד כמה שניתן.

10.2. מאמת CTS

מאמת ה-CTS כלול בחבילה לבדיקת תאימות, והוא מיועד להפעלה על ידי מפעיל אנושי כדי לבדוק פונקציונליות שלא ניתנת לבדיקה על ידי מערכת אוטומטית, כמו למשל תפקוד נכון של מצלמה וחיישנים.

הטמעות מכשירים:

  • [C-0-1] חובה להפעיל בצורה נכונה את כל המקרים הרלוונטיים במאמת ה-CTS.

ה-CTS Verifier כולל בדיקות של סוגי חומרה רבים, כולל חומרה אופציונלית.

הטמעות מכשירים:

  • [C-0-2] חייבים לעבור את כל הבדיקות לחומרה שיש במכשיר. לדוגמה, אם במכשיר יש מד תאוצה, עליו לבצע בצורה נכונה את מקרה הבדיקה של מד התאוצה ב-CTS Verifier.

מקרי בדיקה של תכונות שצוינו כאופציונליות במסמך הגדרת התאימות הזה ייתכן שהמערכת תדלג או תשמיט אותן.

  • [C-0-2] כל מכשיר וכל גרסת build חייבים להפעיל באופן תקין את מאמת ה-CTS, כפי שצוין למעלה. עם זאת, מכיוון שגרסאות build רבות דומות מאוד, מטמיעי המכשירים לא צפויים להפעיל באופן מפורש את מאמת ה-CTS על גרסאות build שההבדל היחיד ביניהן הוא טריוויאלי. באופן ספציפי, יישומים של מכשירים שונים מיישום שעבר את CTS Verifier רק באמצעות קבוצת הלוקאלים, המיתוג וכו' שכלולים בו. ייתכן שבדיקת ה-CTS Verifier לא תכלול את הנתונים האלה.

11. תוכנות Updatable

  • [C-0-1] הטמעות מכשירים חייבות לכלול מנגנון שיחליף את תוכנת המערכת במלואה. המנגנון לא נדרש לבצע שדרוגים "בזמן אמת" – כלומר, ייתכן שתידרש הפעלה מחדש של המכשיר. אפשר להשתמש בכל שיטה, כל עוד היא יכולה להחליף את כל התוכנה שהותקנה מראש במכשיר. למשל, כל אחת מהגישות הבאות עומדת בדרישה הזו:

    • הורדות בחיבור אלחוטי (OTA) עם עדכון אופליין באמצעות הפעלה מחדש.
    • 'שיתוף אינטרנט בין מכשירים' מתעדכן ב-USB ממחשב מארח.
    • עדכונים במצב 'אופליין' על ידי הפעלה מחדש ועדכון מקובץ באחסון נשלף.

  • [C-0-2] מנגנון העדכון חייב לתמוך בעדכונים בלי לאפס את נתוני המשתמשים. כלומר, מנגנון העדכון חייב לשמור נתונים פרטיים של אפליקציות ונתונים ששותפו באפליקציות. שימו לב שתוכנת Android בערוץ ה-upstream כוללת מנגנון עדכון שעומד בדרישה הזו.

אם ההטמעות של המכשירים כוללות תמיכה בחיבור נתונים לא נמדד, כמו פרופיל 802.11 או פרופיל PAN (רשת תקשורת אישית) של Bluetooth, הן:

  • [C-1-1] חייבת לתמוך בהורדות OTA עם עדכון אופליין באמצעות הפעלה מחדש.

בהטמעות של מכשירים שמושקים עם Android 6.0 ואילך, מנגנון העדכון צריך לתמוך באימות שתמונת המערכת זהה לתוצאה החזויה בעקבות OTA. הטמעת OTA מבוססת-בלוקים בפרויקט הקוד הפתוח של 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
    שינויים מהותיים בדרישות התאימות.

  • Docs
    שינויים קוסמטיים או שינויים שקשורים לפיתוח.

לתצוגה הטובה ביותר, יש להוסיף את הפרמטרים pretty=full ו-no-merges לכתובות ה-URL של יומן השינויים.

13. יצירת קשר

תוכלו להצטרף לפורום התאימות ל-Android ולבקש הבהרות או להעלות כל בעיה שלדעתכם המסמך לא עוסק בה.