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

1. מבוא

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

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

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

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

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

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

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

1.1 מבנה המסמך

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1. חומרה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.2. מולטימדיה

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

  • [5.1.1/H-0-1] AMR-NB
  • [5.1.1/H-0-2] AMR-WB
  • [5.1.1/H-0-3] MPEG-4 AAC Profile‏ (AAC LC)
  • [5.1.1/H-0-4] MPEG-4 HE AAC Profile‏ (AAC+)
  • [5.1.1/H-0-5] AAC ELD (‏AAC משופר עם עיכוב נמוך)

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

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

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

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

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

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

2.2.3. תוכנות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.5. מודל אבטחה

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

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

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

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

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

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

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

2.3.1. חומרה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.2. מולטימדיה

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

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

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

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

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

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

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

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

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

  • [5.3/T-SR] MPEG-2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.3. תוכנות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.1. חומרה

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

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

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

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

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

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

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

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

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

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

2.4.2. מולטימדיה

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

2.4.3. תוכנות

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.1. חומרה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • חיישן האור הרגיש לסביבה הבסיסי עשוי להיות זהה לפוטומטר.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.2. מולטימדיה

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

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

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

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

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

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

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

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

2.5.3. תוכנות

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.5. מודל אבטחה

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

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

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

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

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

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

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

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

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

2.4.1. חומרה

גודל המסך

  • [7.1.1.1/Tab-0-1] חייב להיות מסך בגודל של 18 עד 46 ס"מ.

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

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

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

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

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

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

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

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

3. תוכנות

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

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

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

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

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

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

3.1.1. תוספים ל-Android

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

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

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

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

3.2.1. הרשאות

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

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

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

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

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

לדוגמה:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3.1. ממשקי Application Binary Interface

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.4.1. תאימות ל-WebView

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כלומר:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.2. ווידג'טים

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

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

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

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

3.8.3. התראות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.6. עיצובים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.9. ניהול קלט

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

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

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

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

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

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

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

3.8.11. שומרי מסך (לשעבר 'חלומות')

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

3.8.12. מיקום

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

  • [C-1-1]