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

1. מבוא

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

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

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

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

במקרים שבהם ההגדרה הזו או בדיקות התוכנה שמתוארות בסעיף 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
  • W: הטמעת Android Watch
  • כרטיסייה: הטמעת טאבלט 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.

2.2.1. חומרה

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

• [7.1.1.1/H-0-1] חייב להיות לפחות מסך אחד שתואם ל-Android בגודל אלכסון פיזי לפחות, וכל מסך תואם ל-Android חייב לעמוד בכל הדרישות שמתוארות במסמך הזה.
• [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-3] חייבים לספק את פונקציית דף הבית בכל המסכים שתואמים ל-Android שמספקים את מסך הבית.
• [7.2.3/H-0-4] חייבים לספק את פונקציית החזרה בכל המסכים שתואמים ל-Android ואת הפונקציה 'אחרונים' לפחות באחד מהמסכים שתואמים ל-Android.
• [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 לפחות.

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

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

אם מוטמעים במכשיר נייד ג'ירוסקופ עם 3 צירים:

• [7.3.4/H-3-1] צריכה להיות אפשרות לדווח על אירועים עד תדירות של 100 Hz לפחות.
• [7.3.4/H-3-2] חייבת להיות מסוגלת למדוד שינויי כיוון של עד 1,000 מעלות לשנייה.

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

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

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

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

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

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

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

• [7.5.4/H-1-1] חייב להיות שדה ראייה רגיל (FOV) כברירת מחדל, והוא חייב להיות בין 50 ל-90 מעלות.

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

• [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).

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

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

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

• [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.

אם הטמעות של מכשירים ניידים כוללות יציאת USB-C אחת או יותר במצב מארח ומטמיעים אותן (סיווג אודיו USB), בנוסף לדרישות שמפורטות בסעיף 7.7.2, הן:

• [7.8.2.2/H-1-1] צריך לספק את מיפוי התוכנה הבא של קודי ממשק אנושי (HID):

פעולה	מיפויים	הקשר	התנהגות
A	דף שימוש במכשיר HID: 0x0C שימוש ב-HID: 0x0CD מפתח ליבה: KEY_PLAYPAUSE מפתח Android: KEYCODE_MEDIA_PLAY_PAUSE	הפעלת מדיה	קלט: לחיצה קצרה פלט: הפעלה או השהיה
			קלט: לחיצה ארוכה על פלט: הפעלת פקודה קולית שליחה: android.speech.action.VOICE_SEARCH_HANDS_FREE אם המכשיר נעול או כשהמסך כבוי. אחרת, יישלח android.speech.RecognizerIntent.ACTION_WEB_SEARCH
		שיחה נכנסת	קלט: לחיצה קצרה פלט: קבלת השיחה
			קלט: לחיצה ארוכה על פלט: דחיית השיחה
		שיחה פעילה	קלט: לחיצה קצרה פלט: סיום השיחה
			קלט: לחיצה ארוכה על פלט: השתקה או ביטול ההשתקה של המיקרופון
B	דף שימוש במכשיר HID: 0x0C שימוש ב-HID: 0x0E9 מפתח ליבה: KEY_VOLUMEUP מפתח Android: VOLUME_UP	הפעלת מדיה, שיחה פעילה	קלט: לחיצה קצרה או ארוכה פלט: מגדיל את עוצמת הקול של המערכת או של האוזניות
C	דף שימוש במכשיר HID: 0x0C שימוש במכשיר ממשק אנושי (HID): 0x0EA מפתח ליבה: KEY_VOLUMEDOWN מפתח Android: VOLUME_DOWN	הפעלת מדיה, שיחה פעילה	קלט: לחיצה קצרה או ארוכה פלט: הפחתת עוצמת הקול של המערכת או האוזניות
D	דף שימוש במכשיר HID: 0x0C שימוש ב-HID: 0x0CF מפתח ליבה: KEY_VOICECOMMAND מפתח Android: KEYCODE_VOICE_ASSIST	כל ההתראות. ניתן להפעיל בכל מקרה.	קלט: לחיצה קצרה או ארוכה פלט: הפעלת פקודה קולית

• [7.8.2.2/H-1-2] חייבת להפעיל את ACTION_HEADSET_PLUG לאחר הכנסת התקע, אבל רק לאחר שממשקי האודיו ונקודות הקצה בחיבור USB צוינו כראוי כדי לזהות את סוג הטרמינל המחובר.

כשהמערכת מזהה את טרמינל האודיו 0x0302 של USB, הוא:

• [7.8.2.2/H-2-1] חייב לשדר Intent ACTION_HEADSET_PLUG באמצעות "מיקרופון" מוגדר ל-0.

כשהמערכת מזהה את טרמינל האודיו 0x0402 של USB, הוא:

• [7.8.2.2/H-3-1] חייב לשדר Intent ACTION_HEADSET_PLUG באמצעות "מיקרופון" מוגדר ל-1.

כאשר מתבצעת קריאה ל-API AudioManager.getDevices() בזמן שהציוד ההיקפי ב-USB מחובר:

• [7.8.2.2/H-4-1] חובה לרשום מכשיר מסוג AudioDeviceInfo.TYPE_USB_HEADSET והתפקיד isSink() אם השדה של סוג טרמינל האודיו ב-USB הוא 0x0302.

• [7.8.2.2/H-4-2] חובה לרשום מכשיר מסוג AudioDeviceInfo.TYPE_USB_HEADSET והתפקיד isSink() אם השדה של סוג מסוף האודיו ב-USB הוא 0x0402.

• [7.8.2.2/H-4-3] חובה לרשום מכשיר מסוג AudioDeviceInfo.TYPE_USB_HEADSET והתפקיד isSource() אם השדה של סוג טרמינל אודיו ב-USB הוא 0x0402.

• [7.8.2.2/H-4-4] חובה לרשום מכשיר מסוג AudioDeviceInfo.TYPE_USB_DEVICE והתפקיד isSink() אם השדה של סוג טרמינל האודיו ב-USB הוא 0x603.

• [7.8.2.2/H-4-5] חובה לכלול רשימה של מכשיר מסוג AudioDeviceInfo.TYPE_USB_DEVICE והתפקיד isSource() אם השדה של סוג מסוף האודיו ב-USB הוא 0x604.

• [7.8.2.2/H-4-6] חובה לציין מכשיר מסוג AudioDeviceInfo.TYPE_USB_DEVICE עם התפקיד isSink() אם השדה של סוג מסוף האודיו ב-USB הוא 0x400.

• [7.8.2.2/H-4-7] חובה לציין מכשיר מסוג AudioDeviceInfo.TYPE_USB_DEVICE והתפקיד isSource() אם השדה של סוג מסוף האודיו ב-USB הוא 0x400.

• [7.8.2.2/H-SR] מומלץ מאוד בעת חיבור של ציוד היקפי בחיבור USB-C, לבצע ספירה של מתארי USB, לזהות סוגי טרמינל ולשדר את Intent ACTION_HEADSET_PLUG תוך פחות מ-1,000 אלפיות השנייה.

2.2.2. מולטימדיה

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

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

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

• [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.3.1/H-SR] מומלץ מאוד להציג פעולות שעבורן Notification.Action.Builder.setContextual מוגדר כ-true בשורה עם התשובות שמוצגות על ידי Notification.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] חייב לתמוך בתכונת התאמת המכשירים הנלווית.

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

• [7.2.3/H] אזור זיהוי התנועה של הפונקציה 'בית' צריך להיות בגובה של לא יותר מ-32dp בחלק התחתון של המסך.

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

• [7.2.3/H-0-1] אזור התנועה של פונקציית הניווט חייב להיות קטן מ-40dp בכל צד. אזור התנועה אמור להיות ברוחב של 24dp כברירת מחדל.

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

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

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

2.2.5. דגם אבטחה

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

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

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

• [9.11/H-0-2]* חייבים לגבות את ההטמעה של מאגר המפתחות באמצעות סביבת הפעלה מבודדת.
• [9.11/H-0-3]* חייבים להיות הטמעות של אלגוריתמים קריפטוגרפיים מסוג RSA, AES, ECDSA ו-HMAC HMAC, וגם פונקציות גיבוב (hash) משפחתיות מסוג MD5, SHA1 ו-SHA-2 כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שבו מבודד באופן מאובטח מהקוד שפועל בליבה (kernel) ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבהם קוד ליבה או מרחב משתמשים יכול לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. פרויקט הקוד הפתוח של Android (AOSP) ב-upstream עומד בדרישה הזו באמצעות ההטמעה של Trusty. במקום זאת, יש עוד אפשרויות לפתרון מבוסס ARM TrustZone או הטמעה מאובטחת של צד שלישי עם בידוד מתאים שמבוסס על hypervisor.
• [9.11/H-0-4]* חייבים לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק כשהפעולה מבוצעת בהצלחה, לאפשר שימוש במפתחות שקשורים לאימות. יש לאחסן את פרטי הכניסה של מסך הנעילה באופן שיאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. פרויקט הקוד הפתוח של Android ב-upstream מספק את Gatekeeper Hardware Layer Abstraction Layer (HAL) ואת Trusty, ואפשר להשתמש בהם כדי לעמוד בדרישה הזו.
• [9.11/H-0-5]* חייבים לתמוך באימות של מפתחות כאשר חתימת האימות מוגן באמצעות חומרה מאובטחת, והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות חתימת האימות בין מספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת הדרכים לעמוד בדרישה הזו היא לשתף את אותו מפתח אימות, אלא אם יוצרים לפחות 100,000 יחידות של מק"ט נתון. אם מפיקים יותר מ-100,000 יחידות של מק"ט, יכול להיות שייעשה שימוש במפתח שונה לכל 100,000 יחידות.

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

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

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

אם בהטמעות במכשירים ניידים נכללים כמה משתמשים ולא מצהירים על התכונה הניסיונית android.hardware.telephony, הם:

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

אם בהטמעות במכשירים ניידים נכללים כמה משתמשים ומצהירים על התכונה הניסיונית android.hardware.telephony, הם:

• [9.5/H-3-1] אסור לתמוך בפרופילים מוגבלים, אבל הם חייבים להתאים להטמעת AOSP של פקדים כדי לאפשר או להשבית למשתמשים אחרים את הגישה לשיחות קוליות ול-SMS.

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

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

• [6.1/H-0-1]* חייב לתמוך בפקודת המעטפת cmd testharness.

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

• Perfetto
  • [6.1/H-0-2]* חייבים לחשוף קובץ בינארי של /system/bin/perfetto למשתמש המעטפת, ש-cmdline עומד בדרישות של מסמכי התיעוד של Perfetto.
  • [6.1/H-0-3]* הקובץ הבינארי הקבוע חייב לקבל כקלט הגדרת Protobuf שתואמת לסכימה שהוגדרה במסמכי התיעוד של Perfetto.
  • [6.1/H-0-4]* הקובץ הבינארי הקבוע חייב להיות כתוב כפלט כפלט של מעקב Protobuf שתואם לסכימה שהוגדרה במסמכי התיעוד המפורטים.
  • [6.1/H-0-5]* חייבים לספק, באמצעות הקובץ הבינארי, לפחות את מקורות הנתונים שמתוארים במסמכי התיעוד של Perfetto.

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

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

• [7.3.4/T-1-1] צריכה להיות אפשרות לדווח על אירועים עד תדירות של 100 Hz לפחות.
• [7.3.4/T-1-2] חייבת להיות אפשרות למדוד שינויי כיוון של עד 1,000 מעלות לשנייה.

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

• [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.

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

• [5.3.3/T-0-1] MPEG-4 SP
• [5.3.4/T-0-2] H.264 AVC
• [5.3.5/T-0-3] H.265 HEVC
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9
• [5.3.1/T-0-6] MPEG-2

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

• [5.3.1/T-1-1] איכות HD 1080p בקצב של 29.97 פריימים לשנייה, עם פרופיל ראשי ברמה גבוהה.
• [5.3.1/T-1-2] איכות HD 1080i בקצב של 59.94 פריימים לשנייה, עם רמה גבוהה של פרופיל ראשי. הם חייבים לבטל את השילוב של וידאו MPEG-2 משולב וכדי שיהיה זמין לאפליקציות של צד שלישי.

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

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

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

• [5.3.5/T-1-1] איכות HD 1080p בקצב של 60 פריימים לשנייה, בפרופיל הראשי ברמה 4.1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [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.3/T-1-3] חובה לאפשר למשתמשים להציג את כל האפליקציות שפטורות ממצבים 'חיסכון בסוללה' ו'הנמכה של אפליקציות'.

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

• [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.3.5. דגם אבטחה

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

• [9.11/T-0-1] חייבים לגבות את ההטמעה של מאגר המפתחות באמצעות סביבת הפעלה מבודדת.
• [9.11/T-0-2] חייבות להיות הטמעות של אלגוריתמים קריפטוגרפיים RSA , AES , ECDSA ו-HMAC HMAC ופונקציות הגיבוב המשפחתי MD5, SHA1 ו-SHA-2 כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שבו מבודד באופן מאובטח מהקוד שפועל בליבה (kernel) ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבהם קוד ליבה או מרחב משתמשים יכול לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. פרויקט הקוד הפתוח של Android (AOSP) ב-upstream עומד בדרישה הזו באמצעות ההטמעה של Trusty. במקום זאת, יש עוד אפשרויות לפתרון מבוסס ARM TrustZone או הטמעה מאובטחת של צד שלישי עם בידוד מתאים שמבוסס על hypervisor.
• [9.11/T-0-3] חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק כשהפעולה מבוצעת בהצלחה, לאפשר שימוש במפתחות שקשורים לאימות. יש לאחסן את פרטי הכניסה של מסך הנעילה באופן שיאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. פרויקט הקוד הפתוח של Android ב-upstream מספק את Gatekeeper Hardware Layer Abstraction Layer (HAL) ואת Trusty, ואפשר להשתמש בהם כדי לעמוד בדרישה הזו.
• [9.11/T-0-4] חייבת להיות תמיכה באימות עם מפתחות כאשר חתימת האימות מוגן באמצעות חומרה מאובטחת, והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות חתימת האימות בין מספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת הדרכים לעמוד בדרישה הזו היא לשתף את אותו מפתח אימות, אלא אם יוצרים לפחות 100,000 יחידות של מק"ט נתון. אם מפיקים יותר מ-100,000 יחידות של מק"ט, יכול להיות שייעשה שימוש במפתח שונה לכל 100,000 יחידות.

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

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

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

אם בהטמעות של מכשירי טלוויזיה נכללים כמה משתמשים ולא מצהירים על התכונה הניסיונית android.hardware.telephony, הם:

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

אם בהטמעות של מכשירי טלוויזיה נכללים כמה משתמשים ומצהירים על התכונה הניסיונית android.hardware.telephony, הם:

• [9.5/T-3-1] אסור לתמוך בפרופילים מוגבלים, אבל הם חייבים להתאים להטמעת AOSP של אמצעי הבקרה כדי לאפשר או להשבית למשתמשים אחרים את הגישה לשיחות קוליות ול-SMS.

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

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

• Perfetto
  • [6.1/T-0-1] חייב לחשוף קובץ בינארי של /system/bin/perfetto למשתמש המעטפת, ש-cmdline עומד בדרישות של מסמכי התיעוד של Perfetto.
  • [6.1/T-0-2] הקובץ הבינארי Perfetto חייב לקבל כקלט הגדרת Protobuf שתואמת לסכימה שהוגדרה במסמכי התיעוד של Perfetto.
  • [6.1/T-0-3] הקובץ הבינארי הקבוע חייב להיות ייכתב כפלט של מעקב Protobuf שתואם לסכימה שהוגדרה במסמכי התיעוד המפורטים.
  • [6.1/T-0-4] חייבים לספק, באמצעות הקובץ הבינארי Perfetto, לפחות את מקורות הנתונים שמתוארים במסמכי התיעוד של Perfetto.

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 צירים.

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

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

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

• [7.3.4/W-2-1] חייבת להיות מסוגלת למדוד שינויי כיוון של עד 1,000 מעלות לשנייה.

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

• [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.

• [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.4.5. דגם אבטחה

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

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

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

• [9.5/W-2-1] אסור לתמוך בפרופילים מוגבלים, אבל הם חייבים להתאים להטמעת AOSP של אמצעי הבקרה כדי לאפשר או להשבית למשתמשים אחרים את הגישה לשיחות קוליות ול-SMS.

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/A-0-1] חובה להטמיע את GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED וגם PARKING_BRAKE_ON ולדווח עליהם.
• [7.3/A-0-2] הערך של הדגל NIGHT_MODE חייב להיות תואם למצב יום/לילה במרכז הבקרה והוא צריך להתבסס על הקלט מחיישן האור בסביבה. יכול להיות שחיישן אור הסביבה הבסיסי יהיה זהה לחיישן פוטומטר.
• [7.3/A-0-3] חובה לספק שדה מידע נוסף לחיישן TYPE_SENSOR_PLACEMENT כחלק מ-SensorAdditionalInfo לכל חיישן שסופק.
• [7.3/A-0-1] יכול להיות שהמיקום יתוקן על ידי מיזוג GPS/GNSS עם חיישנים נוספים. אם הדעה לגבי המיקום היא מתה, מומלץ מאוד להטמיע את סוגי החיישנים המתאימים ו/או את מזהי הנכסים של הרכב שבהם נעשה שימוש ולדווח עליהם.
• [7.3/A-0-2] המיקום המבוקש דרך LocationManager#requestLocationUpdates() לא חייב להיות תואם למפה.

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

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

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

• [7.3.4/A-2-1] צריכה להיות אפשרות לדווח על אירועים עד תדירות של 100 Hz לפחות.
• [7.3.4/A-2-2] חובה להטמיע גם את החיישן TYPE_GYROSCOPE_UNCALIBRATED.
• [7.3.4/A-2-3] חייבת להיות אפשרות למדוד שינויי כיוון של עד 250 מעלות לשנייה.
• [7.3.4/A-SR] מומלץ מאוד להגדיר את טווח המדידה של הג'ירוסקופ ל- +/-250dps כדי למקסם את הרזולוציה האפשרית

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

• [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.5/A-1-1] אסור שתהיה גישה למצלמות חוץ דרך ממשקי ה-API של מצלמת Android, אלא אם הן עומדות בדרישות הליבה של המצלמה.
• [7.5/A-SR] מומלץ מאוד לא לסובב או לשקף את התצוגה המקדימה של המצלמה באופן אופקי.
• [7.5.5/A-SR] מומלץ מאוד לכוון את הכיוון כך שהממד הארוך של המצלמה יכוון לקו האופק.
• [7.5/A-SR] מומלץ מאוד שהרזולוציה תהיה 1.3 מגה-פיקסלים לפחות.
• היא צריכה לכלול מיקוד קבוע או חומרת EDOF (עומק שדה מורחב).
• ייתכן שבנהג של המצלמה מוטמע מיקוד אוטומטי בחומרה או מיקוד אוטומטי בתוכנה.

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

• [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.2.1/A-0-1] חייבת להיות תמיכה בכל קבועי ההרשאות ולאכוף אותם, כפי שמתואר בדף העזר בנושא הרשאת רכב.

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

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

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

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

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

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

• [3.8.3.1/A-0-1] עיבוד המשאבים חייב להיות תקין, כפי שמתואר במסמכי התיעוד של Notifications on Automotive OS SDK.
• [3.8.3.1/A-0-2] חובה להציג את אפשרויות ההפעלה וההשתקה של פעולות ההתראות במקום הפעולות שסופקו דרך Notification.Builder.addAction()
• [3.8.3.1/A] אמורה להגביל את השימוש במשימות ניהול מתקדמות, כמו אמצעי בקרה לכל ערוץ בנפרד. ייתכן להשתמש בעלות משתלמת למשתמש לכל אפליקציה כדי להפחית את הפקדים.

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

• [3.14/A-0-1] חייבת לכלול מסגרת של ממשק משתמש לתמיכה באפליקציות צד שלישי שמשתמשות בממשקי API של מדיה, כפי שמתואר בסעיף 3.14.
• [3.14/A-0-2] המשתמש חייב לאפשר למשתמש ליצור אינטראקציה בטוחה עם אפליקציות מדיה בזמן הנהיגה.
• [3.14/A-0-3] חייב לתמוך בפעולה המשתמעת של Intent CAR_INTENT_ACTION_MEDIA_TEMPLATE עם תוספת CAR_EXTRA_MEDIA_PACKAGE.
• [3.14/A-0-4] חובה לספק אפשרות לכניסה לפעילות המועדפת של אפליקציית מדיה, אבל חייבים להפעיל אותה רק כשאין הגבלות על חוויית המשתמש ברכב.
• [3.14/A-0-5] חובה להציג הודעות שגיאה שהוגדרו על ידי Media Applications. בנוסף, חייבים לתמוך בתוספות האופציונליות ERROR_RESOLUTION_ACTION_LABEL ו-ERROR_RESOLUTION_ACTION_INTENT.
• [3.14/A-0-6] חייבת לתמוך בעלות על חיפוש בתוך האפליקציה עבור אפליקציות שתומכות בחיפוש.
• [3.14/A-0-7] ההגדרות של CONTENT_STYLE_BROWSABLE_HINT ו-CONTENT_STYLE_PLAYABLE_HINT יוצגו בהיררכיה של MediaBrowser.

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

• [3.14/A-1-1] חובה לכלול שירותי מדיה ולפתוח אותם עם Intent של CAR_INTENT_ACTION_MEDIA_TEMPLATE.

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

• [3.8/A] יכול להיות שתגביל את הבקשות של האפליקציות כדי להגביל את היכולת לעבור למצב מסך מלא כמו שמתואר ב-immersive documentation.
• [3.8/A] יכול להיות ששורת הסטטוס וסרגל הניווט יישארו גלויים כל הזמן.
• [3.8/A] יכול להיות שנגביל את הבקשות של האפליקציות כדי להגביל את היכולת לשנות את הצבעים מאחורי רכיבי ממשק המשתמש של המערכת, כדי להבטיח שהרכיבים האלה גלויים באופן ברור תמיד, כפי שמתואר ב-WindowManager.LayoutParams#FLAG_TRANSLUCENT_STATUS וב-WindowManager.LayoutParams#FLAG_TRANSLUCENT_NAVIGATION.

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

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

• [8.2/A-0-1] חובה לדווח על מספר הבייטים שנקראים ונכתבים באחסון לא נדיף בהתאם ל-UID של כל תהליך, כדי שהנתונים הסטטיסטיים יהיו זמינים למפתחים דרך System API android.car.storagemonitoring.CarStorageMonitoringManager. פרויקט הקוד הפתוח של Android עומד בדרישה באמצעות מודול הליבה uid_sys_stats.
• [8.3/A-1-3] חובה לעבור למצב חנייה לפחות פעם אחת לפני שהרכב כבה.
• [8.3/A-1-4] חייב להיות במצב טעינה במשך 15 דקות לפחות, אלא אם:
  • הסוללה מרוקנת.
  • לא נקבעו משימות שלא פעילות.
  • הנהג יוצא ממצב החניה.
• [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] אסור לאפשר למשתמשים ליצור אינטראקציה עם משתמש במערכת ללא GUI או לעבור אליו, מלבד לצורך הקצאת מכשירים.
• [9.5/A-1-2] חייב לעבור למשתמש משני לפני BOOT_COMPLETED.
• [9.5/A-1-3] חייבת לתמוך באפשרות ליצור משתמש אורח גם כשהגעת למספר המשתמשים המקסימלי במכשיר.

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

• [9.11/A-0-1] חייבים לגבות את ההטמעה של מאגר המפתחות באמצעות סביבת הפעלה מבודדת.
• [9.11/A-0-2] חייבות להיות הטמעות של אלגוריתמים קריפטוגרפיים RSA , AES , ECDSA ו-HMAC HMAC ופונקציות הגיבוב המשפחתי MD5, SHA1 ו-SHA-2 כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שבו מבודד באופן מאובטח מהקוד שפועל בליבה (kernel) ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבהם קוד ליבה או מרחב משתמשים יכול לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. פרויקט הקוד הפתוח של Android (AOSP) ב-upstream עומד בדרישה הזו באמצעות ההטמעה של Trusty. במקום זאת, יש עוד אפשרויות לפתרון מבוסס ARM TrustZone או הטמעה מאובטחת של צד שלישי עם בידוד מתאים שמבוסס על hypervisor.
• [9.11/A-0-3] חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק כשהפעולה מבוצעת בהצלחה, לאפשר שימוש במפתחות שקשורים לאימות. יש לאחסן את פרטי הכניסה של מסך הנעילה באופן שיאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. פרויקט הקוד הפתוח של Android ב-upstream מספק את Gatekeeper Hardware Layer Abstraction Layer (HAL) ואת Trusty, ואפשר להשתמש בהם כדי לעמוד בדרישה הזו.
• [9.11/A-0-4] חייבת להיות תמיכה באימות עם מפתחות כאשר חתימת האימות מוגן באמצעות חומרה מאובטחת, והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות חתימת האימות בין מספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת הדרכים לעמוד בדרישה הזו היא לשתף את אותו מפתח אימות, אלא אם יוצרים לפחות 100,000 יחידות של מק"ט נתון. אם מפיקים יותר מ-100,000 יחידות של מק"ט, יכול להיות שייעשה שימוש במפתח שונה לכל 100,000 יחידות.

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

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

• [9.11/A-1-1] חייבת לאפשר למשתמש לבחור את הזמן הקצוב לתפוגה של מצב שינה לצורך מעבר ממצב נעילה למצב נעול. הזמן הקצוב לתפוגה שמוגדר להפסקה של עד 15 שניות הוא עד 15 שניות.

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

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

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

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

• Perfetto
  • [6.1/A-0-1] חייב לחשוף קובץ בינארי של /system/bin/perfetto למשתמש המעטפת, ש-cmdline עומד בדרישות של מסמכי התיעוד Perfetto.
  • [6.1/A-0-2] הקובץ הבינארי perfetto חייב לקבל כקלט הגדרת Protobuf שתואמת לסכימה שהוגדרה בתיעוד Perfetto.
  • [6.1/A-0-3] הקובץ הבינארי הקבוע חייב להיות כותב כפלט למעקב אחר אב-טיפוס, שתואם לסכימה המוגדרת במסמכי התיעוד המפורטים.
  • [6.1/A-0-4] חייב לספק, באמצעות הקובץ הבינארי Perfetto, לפחות את מקורות הנתונים שמתוארים במסמכי התיעוד של Perfetto.

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

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

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

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

2.6.1. חומרה

גודל המסך

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

ג'ירוסקופ

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

• [7.3.4/Tab-1-1] חייבת להיות אפשרות למדוד שינויי כיוון של עד 1,000 מעלות לשנייה.

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

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

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

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

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

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

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

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

2.6.2. דגם אבטחה

מפתחות ופרטי כניסה (סעיף 9.11)

למידע נוסף, כדאי לעיין בסעיף [9.11].

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

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

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

• [9.5/T-2-1] אסור לתמוך בפרופילים מוגבלים, אבל הם חייבים להתאים להטמעת AOSP של אמצעי הבקרה כדי לאפשר או להשבית למשתמשים אחרים את הגישה לשיחות קוליות ול-SMS.

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] אסור לאפליקציות של צד שלישי להשתמש בממשקים שאינם SDK, שמוגדרים כ-methods ושדות בחבילות השפה של Java שנמצאות בנתיב class האתחול ב-AOSP, ולא מהווים חלק מה-SDK הציבורי. זה כולל ממשקי API שמעוצבים עם ההערה @hide אבל לא עם @SystemAPI, כפי שמתואר במסמכי ה-SDK ובחברים במחלקה פרטית ובכיתה פרטית או במסגרת חבילה.

• [C-0-6] החבילה חייבת להישלח עם כל ממשק שאינו SDK, שתצורף לאותן רשימות מוגבלות שצוינו ברשימת ההרשאות הזמניות ובסימונים של רשימת הישויות שנחסמו בנתיב prebuilts/runtime/appcompat/hiddenapi-flags.csv, להסתעפות המתאימה של רמת ה-API ב-AOSP.

  עם זאת:

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

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

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 שפועלת כרגע, בפורמט קריא לאנשים. שדה זה חייב להכיל אחד מערכי המחרוזת 10.
VERSION.SDK	הגרסה של מערכת Android שפועלת כרגע, בפורמט שאפשר לגשת אליו לפי קוד של אפליקציה של צד שלישי. ב-Android 10, בשדה הזה חייב להיות ערך המספר השלם 10_INT.
VERSION.SDK_INT	הגרסה של מערכת Android שפועלת כרגע, בפורמט שאפשר לגשת אליו לפי קוד של אפליקציה של צד שלישי. ב-Android 10, בשדה הזה חייב להיות ערך המספר השלם 10_INT.
גרסה.INCREMENTAL	ערך שנבחר על ידי מכשיר ההטמעה, שמגדיר את ה-build הספציפי של מערכת Android שרצה כרגע, בפורמט קריא לאנשים. אסור לעשות שימוש חוזר בערך הזה לגרסאות build שונות שזמינות למשתמשי הקצה. בדרך כלל משתמשים בשדה הזה כדי לציין איזה מספר build או מזהה שינוי של בקרת מקור שימש ליצירת ה-build. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII ניתן להדפסה בגרסת 7 סיביות, ולהתאים את הביטוי הרגולרי "^[^ :\/~]+$ ".
משחקי לוח	ערך שנבחר על ידי יישום ההטמעה של המכשיר, שמזהה את החומרה הפנימית הספציפית שבה המכשיר משתמש, בפורמט קריא לאנשים. אפשר להשתמש בשדה הזה כדי לציין את הגרסה הספציפית של הלוח שמפעיל את המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-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:10/LMYXX/3359:userdebug/test-keys אסור שטביעת האצבע תכלול רווחים לבנים. הערך בשדה הזה חייב להיות ניתן לקידוד כ-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. התגים חייבים להיות ניתנים לקידוד כ-ASCII בגרסת 7 ביט והם זהים לביטוי הרגולרי ^[a-zA-Z0-9._-]+ ” וחייבים להיות באחד מהערכים המתאימים לשלוש התצורות הטיפוסיות של חתימת פלטפורמת 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:

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

3.2.3.2. יישוב כוונות

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

• [C-0-2] אסור שמטמיעי מכשירים יוכלו להקצות הרשאות מיוחדות לאפליקציות מערכת שימוש בדפוסי הכוונה האלה, או למנוע מאפליקציות של צד שלישי להיות כפופות לדפוסים האלה ולקבל שליטה עליהם. האיסור הזה כולל באופן ספציפי, בין היתר, השבתה של ממשק המשתמש מסוג 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 שמוגדר בהתאם לדפוסים חדשים של כוונות או כוונות שידור, שמשתמשים ב-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 RoleManager.createRequestRoleIntent(String) עם RoleManager.ROLE_SMS כדי להציג תיבת דו-שיח לשינוי אפליקציית ברירת המחדל ל-SMS.

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

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

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

• [C-2-4] חובה לאשר את ההרשאה android.telecom.CallRedirectionService לאפליקציה שמוגדר לה התפקיד android.app.role.CALL_REDIRECTION.

• [C-2-5] חובה לאפשר למשתמש לבחור אפליקציה לתפקיד android.app.role.CALL_REDIRECTION.

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

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

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

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

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

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

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

אם הטמעות המכשיר מאפשרות להפעיל פעילויות רגילות ב-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)

  • libamidi.so (תמיכה ב-MIDI מקורית, אם נתבעה בעלות על התכונה android.software.midi, כפי שמתואר בסעיף 5.9)
  • 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 10, לצורך ההטמעה של ה-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.

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

חשוב לשים לב שאם הטמעות של מכשירים הן בגרסת 32 ביט או מצהירות על הדגל android.hardware.ram.low של התכונה, הן פטורות מקוד C-1-3.

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

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

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

• [C-0-1] אסור שהמכשירים ישנו את ההתנהגות או הסמנטיקה של Intent רגיל.
• [C-0-2] אסור למכשירים לשנות את הסמנטיקה של מחזור החיים או של מחזור החיים בסוג מסוים של רכיב מערכת (לדוגמה: Service, Activity, 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-1-1] חובה לספק למשתמשים אפשרות צפייה ברשימה של האפליקציות המוגבלות.
• [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 יכולה לעשות זאת. באופן דומה, אסור ל-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
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)	36MB
	240 dpi (hdpi)
	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
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)	48MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	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
	140 dpi (140dpi)	48MB
	160 dpi (mdpi)
	180 dpi (180dpi)	80MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	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
	140 dpi (140dpi)	80MB
	160 dpi (mdpi)
	180 dpi (180dpi)	96MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	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 לאחזור סמלים נקראות.

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

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

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

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

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

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

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

3.8.3. התראות

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

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

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

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

3.8.4. חיפוש

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.9. ניהול קלט

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

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

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

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

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

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

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

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

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

3.8.12. מיקום

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

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

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, הן:

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

ב-Android יש תמיכה בעיבוד גופנים במיאנמר. במיאנמר יש כמה גופנים שאינם תואמים ל-Unicode, הידועים בשם "זאוגי", לעיבוד שפות במיאנמר.

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

* [C-2-1] MUST render text with Unicode compliant font as default;
  non-Unicode compliant font MUST NOT be set as default font unless the user
  chooses it in the language picker.
* [C-2-2] MUST support a Unicode font and a non-Unicode compliant font if a
  non-Unicode compliant font is supported on the device.  Non-Unicode
  compliant font MUST NOT remove or overwrite the Unicode font.
* [C-2-3] MUST render text with non-Unicode compliant font ONLY IF a
  language code with [script code Qaag](
  http://unicode.org/reports/tr35/#unicode_script_subtag_validity) is
  specified (e.g. my-Qaag). No other ISO language or region codes (whether
  assigned, unassigned, or reserved) can be used to refer to non-Unicode
  compliant font for Myanmar. App developers and web page authors can
  specify my-Qaag as the designated language code as they would for any
  other language.

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

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

• [C-1-1] חובה להטמיע את המצבים האלה של ריבוי חלונות בהתאם להתנהגות האפליקציות ולממשקי ה-API שמתוארים במסמכי התיעוד לתמיכה במצב ריבוי חלונות של Android SDK, ולעמוד בדרישות הבאות:
• [C-1-2] חובה לפעול בהתאם למדיניות android:resizeableActivity שהוגדרה על ידי אפליקציה בקובץ AndroidManifest.xml כמו שמתואר ב-SDK הזה.
• [C-1-3] אסור להציע מצב מסך מפוצל או מצב חופשי אם גובה המסך קטן מ-440dp ורוחב המסך קטן מ-440dp.
• [C-1-4] אסור לשנות את הגודל של פעילות לגודל של פחות מ-220dp במצבי ריבוי חלונות שאינם 'תמונה בתוך תמונה'.
• הטמעות של מכשירים שגודל המסך שלהם 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-3] חובה לדווח על true עבור DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-4] חובה לרשום את האפליקציה DPC כאפליקציה של בעלי המכשיר בתגובה לפעולת Intent android.app.action.PROVISION_MANAGED_DEVICE.
    • [C-1-5] חובה לרשום את אפליקציית DPC כאפליקציה של בעלי המכשיר אם המכשיר מצהיר על תמיכה בתקשורת מטווח קצר (NFC) דרך דגל התכונה android.hardware.nfc ומקבל הודעת NFC שמכילה רשומה עם סוג MIME MIME_TYPE_PROVISIONING_NFC.
  • כשהטמעת המכשיר כוללת נתוני משתמש, היא:
    • [C-1-6] חובה לדווח על false עבור DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-7] אסור לרשום יותר אפליקציית DPC כאפליקציה של בעלי המכשיר.
• [C-1-2] חובה לבצע פעולת אישור מסוימת בתהליך ההקצאה כדי לאשר שהאפליקציה תוגדר כבעלת המכשיר. ההסכמה יכולה להתבצע באמצעות פעולת משתמש או באמצעים פרוגרמטיים מסוימים במהלך ההקצאה, אבל אסור שהיא תהיה כתובה בתוך הקוד או מונעת שימוש באפליקציות אחרות של בעלי המכשיר.

אם בהטמעות המכשירים מוצהר על android.software.device_admin, אבל כוללים גם פתרון קנייני לניהול של בעלי המכשיר ומספקים מנגנון לקידום אפליקציה שהוגדרה בפתרון שלהם כ'שווה ערך של בעלי המכשיר' אל 'בעלי המכשיר' הרגיל כפי שזוהו על ידי ממשקי ה-API הרגילים של 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'. כדי לאפשר למשתמש להעביר את הכוונה מהפרופיל המנוהל אל המשתמש הראשי, או להיפך, אם הופעל על ידי הבקר לניהול מדיניות המכשירים (DPC).
• [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, הן:

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

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

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

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

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

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

• [C-1-5] מומלץ להקיש הקשה כפולה על KEYCODE_HEADSETHOOK או על KEYCODE_MEDIA_PLAY_PAUSE בתור KEYCODE_MEDIA_NEXT למשך MediaSession.Callback#onMediaButtonEvent.

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

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

• [C-0-1] אפליקציות ללא התקנה חייבות לקבל רק הרשאות שבהן android:protectionLevel מוגדר ל-"instant".
• [C-0-2] אסור שאפליקציות ללא התקנה יקיימו אינטראקציה עם אפליקציות מותקנות באמצעות כוונות מרומזות, אלא אם מתקיים אחד מהתנאים הבאים:
  • מסנן דפוס Intent של הרכיב נחשף, ויש לו CATEGORY_BROWSABLE
  • הפעולה היא אחת מהאפשרויות: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
  • היעד חשוף באופן מפורש באמצעות android:visibleToInstantApps
• [C-0-3] אסור לאפליקציות ללא התקנה לבצע אינטראקציה ישירה עם אפליקציות מותקנות, אלא אם הרכיב נחשף דרך android:visibleToInstantApps.
• [C-0-4] אפליקציות מותקנות לא יכולות לראות פרטים על אפליקציות ללא התקנה במכשיר, אלא אם האפליקציה ללא התקנה מתחברת באופן מפורש לאפליקציה שמותקנת במכשיר.
• הטמעת מכשירים חייבת לכלול את העלויות הבאות למשתמשים עבור אינטראקציה עם אפליקציות ללא התקנה. ה-AOSP עומד בדרישות של ברירת המחדל לממשק המשתמש של המערכת, להגדרות ולמרכז האפליקציות. הטמעות מכשירים:
  • [C-0-5] חובה לספק למשתמש תקציב להצגה ומחיקה של אפליקציות ללא התקנה שנשמרו במטמון באופן מקומי עבור כל חבילת אפליקציה בנפרד.
  • [C-0-6] חייבת לספק התראה קבועה למשתמש שאפשר לכווץ בזמן שאפליקציה ללא התקנה פועלת בחזית. ההתראה הזו למשתמש חייבת לכלול את העובדה שאפליקציות ללא התקנה לא דורשות התקנה, ומספקת למשתמש אפשרות שמפנה את המשתמש למסך פרטי האפליקציה ב'הגדרות'. לאפליקציות ללא התקנה שהופעלו דרך כוונות אינטרנט, כפי שהוגדרו על ידי שימוש ב-Intent עם פעולה מוגדרת כ-Intent.ACTION_VIEW ועם סכימה של "http" או 'https', עלות נוספת למשתמש אמורה לאפשר למשתמש לא להפעיל את האפליקציה ללא התקנה ולהפעיל את הקישור המשויך לדפדפן האינטרנט שהוגדר, אם יש דפדפן זמין במכשיר.
  • [C-0-7] חובה לאפשר גישה לאפליקציות ללא התקנה מהפונקציה 'לאחרונה' אם הפונקציה 'לאחרונה' זמינה במכשיר.

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_STATUS ובכוונת האפליקציה של מנהל האחסון שמטפלת בכוונת ACTION_MANAGE_STORAGE.

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

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

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

• אמורה לספק למשתמש אפשרות להעניק/לבטל הרשאה להתקנת אפליקציות ממקורות לא ידועים לכל אפליקציה, אך ייתכן שבוחרים ליישם זאת כ-no-op והחזרה 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
• [C-1-2] קובץ FLAC
• [C-1-3] אופוס

כל מקודדי האודיו חייבים לתמוך:

• [C-3-1] הזמנת פריימים של אודיו עם בייט מקורי של 16 ביט PCM דרך ה-API של android.media.MediaCodec.

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 כולל פורמטים של אודיו ברזולוציה גבוהה של עד 24 ביט, תדירות דגימה של 192 kHz ו-8 ערוצים. הערה: הדרישה הזו חלה רק על פענוח הקוד, ושמכשיר יכול לבצע הפחתה לדוגמה או לבצע הפחתת מיקס במהלך שלב ההפעלה.
• [C-1-10] אופוס

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

• [C-2-1] חובה לבצע פענוח ללא רמיקס (לדוגמה, חובה לפענח זרם 5.0 AAC לחמישה ערוצים של PCM, וחובה לפענח זרם AAC של 5.1 לשישה ערוצים של PCM).
• [C-2-2] המטא-נתונים של טווח דינמי חייבים להיות מוגדרים ב-"Dynamic Range Control (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.
• [SR] מומלץ מאוד שכל מפענחי האודיו מסוג AAC עונים על הדרישות C-2-1 ו-C-2-2 שמפורטות למעלה.

בעת פענוח אודיו של 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 יקבלו עדיפות.

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

• [C-6-1] הזמנת פריימים של אודיו עם בייט מקורי של 16 ביט PCM דרך ה-API של android.media.MediaCodec.

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

פורמט/קודק	פרטים	סוגי קבצים/פורמטים של קונטיינרים שנתמכים
פרופיל MPEG-4 AAC (AAC LC)	תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם קצב דגימה סטנדרטי מ-8 עד 48kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) קובץ AAC גולמי של ADTS (.aac, ADIF לא נתמך) MPEG-TS (.ts, לא ניתן לחיפוש, פענוח בלבד) Matroska (.mkv, פענוח בלבד)
MPEG-4 HE AAC Profile (AAC+)	תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם קצב דגימה סטנדרטי של 16 עד 48kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 פרופיל (AAC+ משופר)	תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם קצב דגימה סטנדרטי של 16 עד 48kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (יעזור עם השהיה נמוכה של AAC)	תמיכה בתוכן מונו/סטריאו עם קצב דגימה סטנדרטי מ-16 עד 48kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC	תמיכה בתוכן מונו/סטריאו עם קצב דגימה סטנדרטי מ-7.35 עד 48kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4.75 עד 12.2 kbps נדגם ב- 8 kHz	3GPP (.3gp)
AMR-WB	9 קצבים מ- 6.60 kbit לשנייה עד 23.85 kbit/s שנדגמו ב- 16 kHz, כפי שמוגדר ב-AMR-WB, Adaptive Multi-Rate – Wideband Speech Codec	3GPP (.3gp)
FLAC	גם במקודד וגם במפענח: לפחות מצבי מונו וסטריאו צריכים להיות נתמכים. חייבים לתמוך בתהליכי דגימה של עד 192 kHz. חייבת להיות תמיכה ברזולוציות של 16 ביט ו-24 ביט. הטיפול בנתוני אודיו בפורמט FLAC 24 ביט חייב להיות זמין עם הגדרת אודיו בנקודה צפה (floating-point).	FLAC‏ (‎.flac) MPEG-4 (.mp4, .m4a, פענוח בלבד) Matroska (.mkv, פענוח בלבד)
MP3	מונו/סטריאו 8-320Kbps קבוע (CBR) או קצב העברת נתונים משתנה (VBR)	MP3‏ (‎.mp3) MPEG-4 (.mp4, .m4a, פענוח בלבד) Matroska (.mkv, פענוח בלבד)
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) MPEG-4 (.mp4, .m4a, פענוח בלבד) Matroska (.mkv) Webm (.webm)
PCM/גל	קודק ה-PCM חייב לתמוך ב-PCM ליניארי של 16 ביט ובציפה (float) של 16 ביט. מחלץ WAVE חייב לתמוך ב-PCM לינארי של 16 ביט, 24 ביט, 32 ביט ובמצב צף של 32 ביט (קצב החיבור מוגבל לחומרה). קצב הדגימה חייב להיות נתמך מ-8kHz עד 192kHz.	WAVE (.wav)
Opus		Ogg (.ogg) MPEG-4 (.mp4, .m4a, פענוח בלבד) Matroska (.mkv) Webm (.webm)

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

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

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

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

אם בהטמעות במכשירים יש תמיכה בקידוד HEIC באמצעות android.media.MediaCodec עבור סוג מדיה MIMETYPE_IMAGE_ANDROID_HEIC:

• [C-1-1] חייב לספק קודק מקודד HEVC עם שיפור מהירות באמצעות חומרה שתומך במצב בקרה על קצב העברת נתונים BITRATE_MODE_CQ, בפרופיל HEVCProfileMainStill ובגודל מסגרת של 512 x 512 פיקסלים.

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)

מפענחי תמונות שתומכים בפורמט בעומק ביט גבוה (יותר מ-9 ביט לכל ערוץ)

• [C-1-1] חייבת לתמוך בפלט בפורמט מקביל של 8 ביט אם האפליקציה מבקשת לעשות זאת, למשל באמצעות הגדרת ARGB_8888 של android.graphics.Bitmap.

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)

מקודדים ומפענחים של תמונות שנחשפים דרך MediaCodec API

• [C-1-1] חייב לתמוך בפורמט צבע גמיש 8:8:8 ב-YUV420 (COLOR_FormatYUV420Flexible) עד CodecCapabilities.

• [SR] מומלץ מאוד לתמוך בפורמט הצבעים RGB888 במצב Surface של קלט.

• [C-1-3] חובה לתמוך לפחות באחד מהפורמטים של צבעים מישוריים או חצי-מישוריים: YUV420 ביחס 8:8:8: COLOR_FormatYUV420PackedPlanar (שווה ל-COLOR_FormatYUV420Planar) או COLOR_FormatYUV420PackedSemiPlanar (מקביל ל-COLOR_FormatYUV420SemiPlanar). אנחנו ממליצים מאוד שתומכים בשניהם.

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

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

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

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

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

• [C-1-3] מקודדים ומפענחי וידאו חייבים לתמוך לפחות באחד בפורמט YUV420 מישור או חצי-מישורי 8:8:8: COLOR_FormatYUV420PackedPlanar (שווה ל-COLOR_FormatYUV420Planar) או COLOR_FormatYUV420PackedSemiPlanar (מקביל ל-COLOR_FormatYUV420SemiPlanar). אנחנו ממליצים מאוד שתומכים בשניהם.

• [SR] מומלץ מאוד להשתמש במקודדים ומפענחים של וידאו כדי לתמוך לפחות באחד בפורמט מישורי או חצי-מישור שעבר אופטימיזציה לחומרה, בפורמט YUV420 8:8:8 (YV12, NV12, NV21 או פורמט מותאם אישית של ספק).

• [C-1-5] מפענחי וידאו שתומכים בפורמט בעומק ביט גבוה (9 ביט לכל ערוץ) חייבים לתמוך בפלט של פורמט מקביל של 8 ביט, אם האפליקציה ביקשה אותו. השינוי הזה חייב לבוא לידי ביטוי בתמיכה בפורמט YUV420 8:8:8 דרך android.media.MediaCodecInfo.

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

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

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

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

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

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

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

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

5.1.9. אבטחה של קודק מדיה

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

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

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

• [C-1-1] חובה לספק תמיכה ברכיבי קודק מדיה באמצעות ממשקי API של OMX או Codec 2.0 (או שניהם), כמו בפרויקט הקוד הפתוח של Android, ולא להשבית או לעקוף את הגנות האבטחה. זה לא אומר שכל קודק חייב להשתמש ב-OMX או ב-Codec 2.0 API, אלא רק שהתמיכה באחד מממשקי ה-API האלה חייבת להיות זמינה, והתמיכה בממשקי ה-API הזמינים חייבת לכלול את הגנות האבטחה הקיימות.
• [C-SR] מומלץ מאוד לכלול תמיכה ב-Codec 2.0 API.

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

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

אם הטמעות במכשירים תומכים ב-Codec 2.0 API:

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

5.1.10. אפיון של קודק מדיה

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

• [C-1-1] חייב להחזיר את הערכים הנכונים של אפיון קודק המדיה דרך ה-API של MediaCodecInfo.

ובפרט:

• [C-1-2] רכיבי קודק שהשמות שלהם מתחילים ב-'OMX'. חייבים להשתמש בממשקי ה-API של OMX ולהיות עם שמות שתואמים להנחיות למתן שמות ל-OMX IL.
• [C-1-3] רכיבי קודק שהשמות שלהם מתחילים ב-'c2'. חייבים להשתמש ב-Codec 2.0 API ולהיות עם שמות שתואמים להנחיות למתן שמות של Codec 2.0 עבור Android.
• [C-1-4] רכיבי קודק שהשמות שלהם מתחילים ב-'OMX.google'. או 'c2.android'. אסור להיות מסווג כספק או עם שיפור מהירות באמצעות חומרה.
• [C-1-5] רכיבי קודק שפועלים בתהליך קודק (ספק או מערכת) שיש להם גישה למנהלי התקנים של חומרה אחרים מלבד מקצי זיכרון וממפים, אסור להיות מאופיינים כתוכנות בלבד.
• [C-1-6] רכיבי קודק שלא נמצאים בפרויקט הקוד הפתוח של Android או שלא מבוססים על קוד המקור בפרויקט הזה חייבים להיות מאופיינים כספק.
• [C-1-7] רכיבי קודק שמשתמשים בהאצת חומרה חייבים להיות מאופיינים בתור עם שיפור מהירות באמצעות חומרה.
• [C-1-8] שמות של רכיבי קוד לא יכולים להיות מטעים. לדוגמה, רכיבי קודק שנקראים 'מפענחים' חייבים לתמוך בפענוח קוד, ובמקודדים שנקראים 'מקודדים' חייבת לתמוך בקידוד. רכיבי קודק עם שמות שמכילים מדיה חייבים לתמוך בפורמטים האלה.

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

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

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p	HD 1080p	UHD
רזולוציית וידאו	176 x 144 פיקסלים (H263, MPEG2, MPEG4) 352 x 288 פיקסלים (מקודד MPEG4, H263, MPEG2) 320 x 180 פיקסלים (VP8, VP8) 320 x 240 פיקסלים (אחר)	704 x 576 פיקסלים (H263) 640 x 360 פיקסלים (VP8, VP9) 640 x 480 פיקסלים (מקודד MPEG4) 720 x 480 פיקסלים (אחר)	1408 x 1152 פיקסלים (H263) 720 x 1280 פיקסלים (אחר)	1920 x 1080 פיקסלים (חוץ מ-MPEG4)	3840 x 2160 פיקסלים (HEVC, VP9)

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

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

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

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

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

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 (איכות גבוהה) כפי שמצוין בטבלה הבאה.

אם הטמעות במכשירים מדווחים על תמיכה בקידוד 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 (איכות HD).
• [C-1-2] חייבת להיות תמיכה בכתיבת קובצי 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:

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

	SD	HD 720p	HD 1080p	UHD
רזולוציית וידאו	720 x 480 פיקסלים	720 x 1280 פיקסלים	1920 x 1080 פיקסלים	3840 x 2160 פיקסלים
קצב הפריימים של הסרטון	30 fps	30 fps	30 fps	30 fps
קצב העברת נתונים של וידאו	1.6 Mbps	4Mbps	‎5 Mbps	‎20 Mbps

אם בהטמעות במכשירים שונים נטען שהם תומכים בפרופיל 2 או בפרופיל 3 דרך ממשקי Media API:

• תמיכה בפורמט 12 ביט היא אופציונלית.

5.2.5. H.265

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

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

	SD	HD 720p	HD 1080p	UHD
רזולוציית וידאו	720 x 480 פיקסלים	720 x 1280 פיקסלים	1920 x 1080 פיקסלים	3840 x 2160 פיקסלים
קצב הפריימים של הסרטון	30 fps	30 fps	30 fps	30 fps
קצב העברת נתונים של וידאו	1.6 Mbps	4Mbps	‎5 Mbps	‎20 Mbps

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

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

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

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	‎20 Mbps

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	‎5 Mbps	‎20 Mbps

אם בהטמעות של המכשיר נטען שהוא תומך בפרופיל HDR (HEVCProfileMain10HDR10, HEVCProfileMain10HDR10Plus) באמצעות ממשקי ה-API של המדיה:

• [C-3-1] הטמעות מכשירים חייבות לקבל את המטא-נתונים הנדרשים של HDR (MediaFormat#KEY_HDR_StatIC_INFO לכל פרופילי ה-HDR) מהאפליקציה באמצעות MediaCodec API, בנוסף לתמיכה בחילוץ המטא-נתונים של HDR (MediaFormat#KEY_HDR_StatIC_INFO לכל הפרופילים של HDR, וכן תמיכה במפרט HDR#KEY_HDR10_PLUS_INFOשמוגדר במפרטי ה-HDR#Plus10_PLUS10 ) הם חייבים גם לתמוך בפלט של המטא-נתונים הנדרשים של HDR (MediaFormat#KEY_HDR_StatIC_INFO לכל פרופילי ה-HDR) מה-bitstream ו/או מהקונטיינר, כפי שהוגדרו במפרט הרלוונטי.

• [C-SR] יישומי המכשיר מומלץ מאוד כדי לתמוך בפלט של המטא-נתונים MediaFormat#KEY_HDR10_PLUS_INFO של פרופילי HDR10Plus דרך MediaCodec#getOutputFormat(int).

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

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

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	‎20 Mbps

5.3.7. VP9

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

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

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

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

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

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

	SD (איכות נמוכה)	SD (איכות גבוהה)	HD 720p	HD 1080p	UHD
רזולוציית וידאו	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	‎5 Mbps	‎20 Mbps

אם בהטמעות של מכשירים נטען שהם תומכים ב-VP9Profile2 או ב-VP9Profile3 דרך ממשקי ה-API של מדיה 'CodecProfileLevel':

• תמיכה בפורמט 12 ביט היא אופציונלית.

אם בהטמעות של המכשיר נטען שהוא תומך בפרופיל HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) באמצעות ממשקי ה-API של המדיה:

• [C-4-1] הטמעות מכשירים חייבות לקבל מהאפליקציה את המטא-נתונים הנדרשים של HDR (MediaFormat#KEY_HDR_STATIC_INFO לכל פרופילי HDR, וגם את הפרמטר MediaCodec#PARAMETER_KEY_HDR10_PLUS_INFO לפרופילים של HDR10Plus) באמצעות MediaCodec API, וגם תמיכה בחילוץ המטא-נתונים הנדרשים של HDR (MediaFormat#KEY_HDR_STATIC_INFO עבור כל פרופילי HDR, וכן MediaFormat#KEY_HDR10_PLUS_INFO עבור הפרופילים של HDR10Plus) מהמפרט הרלוונטי של ה-bitstream ו/או הקונטיינר. הם חייבים גם לתמוך בפלט של המטא-נתונים הנדרשים של HDR (MediaFormat#KEY_HDR_STATIC_INFO לכל הפרופילים של HDR) מה-bitstream ו/או מהקונטיינר, כפי שמוגדר במפרט הרלוונטי.

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

• [C-SR] הטמעות המכשירים מומלצות מאוד כדי לתמוך בפלט של המטא-נתונים MediaFormat#KEY_HDR10_PLUS_INFO לפרופילים של HDR10Plus דרך MediaCodec#getOutputFormat(int).

• [C-SR] מומלץ מאוד להשתמש בהטמעות של מכשירים כדי להציג בצורה תקינה תוכן HDR לפרופילים של VP9Profile2HDR10Plus ו-VP9Profile3HDR10Plus במסך המכשיר או ביציאת פלט וידאו רגילה (למשל, HDMI).

5.3.8. Dolby Vision

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

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

5.3.9. AV1

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

• [C-1-1] חייבת לתמוך בפרופיל 0, כולל תוכן של 10 ביט.

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

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

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

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

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

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

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

  • פורמט: PCM לינארי, 16 ביט ו-24 ביט
  • קצבי דגימה: 8,000, 11,025, 16,000, 22050, 24,000, 32,000, 44100, 48,000 Hz
  • ערוצים: מספר הערוצים המקסימלי המותר של מיקרופונים במכשיר

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

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

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

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

• [C-1-4] חובה לפעול בהתאם ל-API של MicrophoneInfo ולמלא בצורה תקינה את המידע על המיקרופונים הזמינים במכשיר שאפשר לגשת אליהם דרך ה-API של AudioManager.getMicrophones(), ועל המיקרופונים הפעילים שזמינים לאפליקציות הצד השלישי דרך ממשקי ה-API של AudioRecord.getActiveMicrophones() ו-MediaRecorder.getActiveMicrophones(). אם הטמעת המכשיר מאפשרת תיעוד באיכות רדיו 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.4.4. מבטל הד אקוסטי

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

• צריך להטמיע טכנולוגיה של ביטול הד אקוסטית (AEC) שמכווננת לתקשורת קולית ומוחלת בנתיב הצילום באמצעות AudioSource.VOICE_COMMUNICATION

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

• [C-SR] מומלץ להצהיר על כך באמצעות שיטת AcousticEchoCanceler של ה-API AcousticEchoCanceler.isAvailable()
• [C-SR] הם STRONGLY_מומלצים על מנת לאפשר שליטה באפקט האודיו הזה באמצעות AcousticEchoCanceler API.
• [C-SR] מומלץ מאוד לזהות כל הטמעה של טכנולוגיית AEC באמצעות השדה Audio Effects.Descriptor.uuid.

5.4.5. צילום בו-זמנית

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

• [C-1-1] חובה לאפשר גישה בו-זמנית למיקרופון באמצעות שירות נגישות לתיעוד נתונים עם AudioSource.VOICE_RECOGNITION ולפחות אפליקציה אחת ללכידת נתונים בכל AudioSource.
• [C-1-2] חובה לאפשר גישה בו-זמנית למיקרופון באמצעות אפליקציה מותקנת מראש שיש לה תפקיד Assistant ולפחות אפליקציה אחת שתומכת בכל AudioSource חוץ מ-AudioSource.VOICE_COMMUNICATION או AudioSource.CAMCORDER.
• [C-1-3] חובה להשתיק את הקלטת האודיו בכל אפליקציה אחרת, מלבד שירות נגישות, בזמן שאפליקציה מקליטת באמצעות AudioSource.VOICE_COMMUNICATION או AudioSource.CAMCORDER. עם זאת, כשאפליקציה מקליטה דרך AudioSource.VOICE_COMMUNICATION, אפליקציה אחרת יכולה להקליט את השיחה הקולית, אם היא אפליקציה בעלת הרשאות (מותקנת מראש) עם ההרשאה CAPTURE_AUDIO_OUTPUT.
• [C-1-4] אם שתי אפליקציות או יותר מבצעות הקלטה בו-זמנית, ואם לאף אחת מהאפליקציות אין ממשק משתמש, האפליקציה שהתחילו להקליט בפעם האחרונה תקבל אודיו.

5.4.6. רמות הגברה של המיקרופון

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

• צריכה להציג מאפייני תדרים של משרעת (משרעת-המרה) שטוחה בערך בטווח התדרים: במיוחד ±3dB מ-100Hz עד 4000Hz לכל מיקרופון שמשמש להקלטת מקור האודיו של זיהוי הקול.
• צריך להגדיר את הרגישות לקלט האודיו, כך שמקור טונה סינוסאידי של 1000Hz יופעל ב- 90 dB רמת לחץ קול (SPL) יוביל לתגובה עם RMS של 2,500 לדגימות של 16 ביט (או -22.35 דציבלים להקלטה מלאה של דגימות קול עבור כל נקודה/כפולה).
• [C-SR] מומלץ מאוד להציג רמות משרעת בטווח התדרים הנמוכים: במיוחד מ-±20dB מ-5 Hz עד 100 Hz בהשוואה לטווח התדר באמצע כל מיקרופון שמשמש להקלטת מקור האודיו של זיהוי הקול.
• [C-SR] מומלץ מאוד להציג רמות משרעת בטווח התדרים הגבוה: במיוחד מ-±30dB מ-4,000Hz עד 22KHz בהשוואה לטווח התדר באמצע עבור כל מיקרופון שמשמש להקלטת מקור האודיו לזיהוי הקול.

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 במונו ובסטריאו

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

  • קצב דגימה: 24,000

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

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

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

• [C-1-1] חייבת לתמוך בהטמעות של EFFECT_TYPE_EQUALIZER ו-EFFECT_TYPE_LOUDNESS_ENHANCER שנשלטות באמצעות מחלקות המשנה Audioנקט 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
• [C-SR] מומלץ מאוד להשתמש באפקטים כדי לתמוך בנקודה צפה (floating-point) ובכמה ערוצים.

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

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

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

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

• [C-SR] זמן אחזור של פלט במצב קר של 100 אלפיות השנייה או פחות. כרגע מומלץ מאוד להשתמש במכשירים קיימים וחדשים שבהם פועלת הגרסה הזו של Android. במהדורה עתידית של הפלטפורמה לשנת 2021 נדרוש זמן אחזור של פלט במצב התחלתי (cold start) של 200 אלפיות השנייה או פחות כברירת מחדל.
• [C-SR] זמן אחזור של פלט רציף של 45 אלפיות השנייה או פחות.
• [C-SR] מזעור הרעידות בפלט הקר.
• [C-SR] חותמת הזמן של הפלט שהוחזרה על ידי AudioTrack.getTimestamp ו-AAudioStream_getTimestamp מדויקת ל-1 אלפיות השנייה או ל- +/-.

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

• [C-SR] מומלץ מאוד לדווח על אודיו עם זמן אחזור קצר באמצעות הצהרה על סימון התכונה android.hardware.audio.low_latency.
• [C-SR] מומלץ מאוד לעמוד בדרישות לגבי אודיו עם זמן אחזור קצר דרך AAudio API.
• [C-SR] מומלץ מאוד לוודא שבשידורים שחוזרים AAUDIO_PERFORMANCE_MODE_LOW_LATENCY מ-AAudioStream_getPerformanceMode(), הערך שהוחזר על ידי AAudioStream_getFramesPerBurst() קטן או שווה לערך שהוחזר על ידי android.media.AudioManager.getProperty(String) עבור מפתח הנכס AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

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

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

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

• [C-3-1] הגבלה של השגיאה בחותמות הזמן של הקלט, כפי שהוחזרה על ידי AudioRecord.getTimestamp או AAudioStream_getTimestamp, ל- +/- 2 ms. "שגיאה" כאן מתייחסת לסטייה מהערך הנכון.
• [C-3-2] זמן אחזור של קלט קר של 500 אלפיות השנייה או פחות.

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

• [C-SR] זמן אחזור של קלט קר של 100 אלפיות השנייה או פחות. כרגע מומלץ מאוד להשתמש במכשירים קיימים וחדשים שבהם פועלת הגרסה הזו של Android. בהשקה עתידית של הפלטפורמה ב-2021 נדרוש זמן אחזור של 200 אלפיות השנייה לכל היותר מסוג קלט קר.
• [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 ו-MPEG2-4 SP זמינים בסעיף 5.1.3 ו-MPEG-2. קודק האודיו: קובץ 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, במקרים שבהם העברות כאלה הן:

  • מצב מארח USB, סעיף 7.7
  • מצב ציוד היקפי בחיבור USB, סעיף 7.7
  • MIDI באמצעות Bluetooth LE בתפקיד מרכזי, סעיף 7.4.3

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

• [C-1-3] חובה לכלול את libamidi.so (תמיכה מובנית ב-MIDI)

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

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

• [C-1-1] חובה לדווח על תמיכה בתכונה android.hardware.audio.low_latency.
• [C-1-2] זמן אחזור רציף של אודיו הלוך ושוב חייב להיות באורך של 20 אלפיות שנייה או פחות, כמוגדר בסעיף 5.6 זמן אחזור אודיו, והוא צריך להיות 10 אלפיות שנייה או פחות מנתיב נתמך אחד לפחות.
• [C-1-3] חייבות לכלול יציאות USB שתומכות במצב מארח USB ובמצב היקפי בחיבור USB.
• [C-1-4] חובה לדווח על תמיכה בתכונה android.software.midi.
• [C-1-5] חייבת לעמוד בדרישות זמן האחזור ובדרישות האודיו ב-USB באמצעות ה-API של תור מאגר הנתונים הזמני ב-OpenSL ES ולפחות נתיב אחד של AAudioNative audio API.
• [SR] מומלץ מאוד לעמוד בדרישות זמן האחזור ובדרישות האודיו ב-USB באמצעות ה-API של AAudioNative audio דרך נתיב MMAP.
• [C-1-6] זמן האחזור של הפלט במצב התחלתי חייב להיות 200 אלפיות השנייה או פחות.
• [C-1-7] זמן האחזור של קלט קר חייב להיות 200 אלפיות השנייה או פחות.
• [SR] מומלץ מאוד לספק רמה עקבית של ביצועי המעבד (CPU), בזמן שהאודיו פעיל והעומס על המעבד (CPU) משתנה. צריך לבדוק את זה באמצעות גרסת האפליקציה ל-Android של מזהה ההתחייבות מסוג SynthMark 09b13c6f49ea089f8c31e5d035f912cc405b7ab8. SynthMark משתמש בסינתיסייזר תוכנה שרץ על פריים סימולציה של אודיו שמודד את ביצועי המערכת. צריך להריץ את אפליקציית SynthMark באמצעות האפשרות 'בדיקה אוטומטית' ולהשיג את התוצאות הבאות:
  • voicemark.90 >= 32 קולות
  • durationmark.fixed.little <= 15 מילי-שניות
  • durationmark.dynamic.little <= 50 מילי-שניות

ניתן לעיין במסמכי התיעוד של SynthMark להסבר על נקודות ההשוואה.

• אמור לצמצם את אי הדיוק של שעון האודיו וסחף ביחס לזמן הסטנדרטי.
• צריך לצמצם את הסחף של שעון האודיו ביחס למעבד (CPU) CLOCK_MONOTONIC כששניהם פעילים.
• זה אמור לצמצם את זמן האחזור של האודיו במתמרים ששמורים במכשיר.
• יש לצמצם את זמן האחזור של האודיו באודיו דיגיטלי בחיבור USB.
• צריך לתעד את המדידות של זמן האחזור של האודיו בכל הנתיבים.
• אמור לצמצם את הרעידות בזמני הכניסה של הקריאה החוזרת להשלמת מאגר הנתונים הזמני של האודיו, כי הפעולה הזו משפיעה על אחוז השימוש מרוחב הפס המלא במעבד (callback).
• השימוש הרגיל אמור לספק אפס תקלות אודיו בזמן האחזור המדווח.
• אמורה לספק הפרש בין זמן האחזור בין הערוצים.
• זמן האחזור הממוצע של MIDI אמור לצמצם את זמן האחזור בכל אמצעי התחבורה.
• צריכה לצמצם את השונות של זמן האחזור של MIDI בעומס (רעידות) בכל ההעברות.
• צריכה לספק חותמות זמן מדויקות לשימוש ב-MIDI בכל אמצעי התחבורה.
• אמורה למזער את הרעש של אות האודיו במתמרים במכשיר, כולל פרק הזמן שמיד אחרי ההפעלה במצב התחלתי.
• אמור להיות אפס הפרשים בשעון האודיו בין צד הקלט לצד הפלט של נקודות הקצה התואמות, כששניהם פעילים. דוגמאות לנקודות קצה תואמות כוללות את המיקרופון והרמקול במכשיר או את הקלט והפלט של שקע האודיו.
• צריכה לטפל בקריאות חוזרות (callback) של השלמת מאגר הנתונים של האודיו בשביל צדי הקלט והפלט של נקודות הקצה המתאימות באותו השרשור כששניהם פעילים, ולהזין את הקריאה החוזרת של הפלט מיד אחרי שהיא חוזרת מהקריאה החוזרת של הקלט. לחלופין, אם לא ניתן לטפל בקריאות החוזרות באותו שרשור, צריך להזין את הקריאה החוזרת (callback) של הפלט זמן קצר לאחר הזנת הקריאה החוזרת של הקלט, כדי לאפשר לאפליקציה תזמון עקבי של צד הקלט והפלט.
• אמור לצמצם את הפרש המופעים בין אגירת אודיו של HAL עבור צד הקלט וצד הפלט של נקודות הקצה המתאימות.
• צריכה למזער את זמן האחזור של המגע.
• צריכה למזער את ההשתנות של זמן האחזור של המגע במקרה של עומס (רעידות).
• זמן האחזור מקלט המגע לפלט האודיו אמור להיות 40 אלפיות השנייה או פחות.

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

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

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

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

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

• [C-3-1] חובה להטמיע את סיווג האודיו ב-USB.
• [C-3-2] נדרש זמן אחזור רציף של 20 אלפיות שנייה או פחות לאודיו הלוך ושוב ביציאת מצב מארח USB באמצעות סיווג אודיו ב-USB.
• זמן האחזור של האודיו הלוך ושוב הרציף צריך להיות 10 אלפיות השנייה או פחות דרך יציאת USB במצב מארח באמצעות סיווג אודיו ב-USB.
• [C-SR] מומלץ מאוד לתמוך בקלט/פלט (I/O) סימולטני של עד 8 ערוצים בכל כיוון, בקצב דגימה של 96kHz ועומק של 24 ביט או 32 ביט, כשמשתמשים בציוד היקפי בחיבור USB שתומך גם בציוד היקפי בחיבור USB.

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

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

• [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-SR] מומלץ מאוד לתמוך בפקודת המעטפת cmd testharness.
  • [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.

• Perfetto

  • [C-SR] מומלץ מאוד לחשוף קובץ בינארי של /system/bin/perfetto למשתמש במעטפת, ש-cmdline עומדת בדרישות של מסמכי התיעוד.
  • [C-SR] מומלץ מאוד לקבל את הקובץ הבינארי Perfetto כקלט של הגדרת Protobuf שתואמת לסכימה שהוגדרה במסמכי התיעוד של Perfetto.
  • [C-SR] מומלץ מאוד לכתוב כפלט מעקב של Protobuf שתואם לסכימה שהוגדרה בתיעוד Perfetto.
  • [C-SR] מומלץ מאוד לספק, באמצעות הקובץ הבינארי הקבוע, לפחות את מקורות הנתונים שמתוארים במסמכי התיעוד של Perfetto.

• מצב 'מסגרת בדיקה'

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

  • [C-2-1] חייב להחזיר true במחיר ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] חובה להטמיע את מצב 'מסגרת בדיקה' כמו שמתואר במסמכי התיעוד של מצב 'מסגרת'.

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

• ב-MAY יש מסכים שתואמים ל-Android עם פינות מעוגלות.

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

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

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

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

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

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

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

  • האפליקציה מצהירה שאפשר לשנות את גודלה באמצעות המאפיין android:resizeableActivity.
  • האפליקציה מצהירה על android:minAspectRatio שיגביל את יחס הגובה-רוחב המותר.

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

7.1.1.3. דחיסות מסך

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

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

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

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

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

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

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

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

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

אם בהטמעות במכשירים תומכים ב-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.
• [C-SR] מומלץ מאוד לתמוך בתוספים VK_KHR_driver_properties ו-VK_GOOGLE_display_timing.

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

• [C-3-1] חובה לחשוף את התמיכה בסוגי הכינויים והסמפור החיצוניים SYNC_FD ובתוסף 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]
• [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_EXT_gl_colorspace_display_p3_linear ו-EGL_EXT_gl_colorspace_display_p3_passthrough.
• [C-SR] אנחנו ממליצים מאוד לתמיכה ב-GL_EXT_sRGB.

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

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

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

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

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

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

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

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

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

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

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

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

7.2. התקני קלט

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

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

7.2.1. מקלדת

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

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

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

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

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

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

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

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

• [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-SR] מומלץ מאוד שפונקציית התפריט תהיה זמינה לאפליקציות אם הערך של 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.

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

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() חייבים לשמש רק לדיווח על האזור של זיהוי תנועה במסך הבית.
• [C-6-2] תנועות שמתחילות ברכיב החרגה כפי שסופק על ידי האפליקציה בחזית דרך View#setSystemGestureExclusionRects(), אבל מחוץ ל-WindowInsets#getMandatorySystemGestureInsets() אסור ליירט את התנועות שמתחילות בתוך מלבן ההחרגה כפי שצוין בתיעוד של פונקציית הניווט View#setSystemGestureExclusionRects().
• [C-6-3] חובה לשלוח לאפליקציה בחזית אירוע MotionEvent.ACTION_CANCEL אחרי שהנגיעות יתחילו ליירט בגלל תנועת מערכת, אם האפליקציה בחזית נשלחה בעבר אירוע MotionEvent.ACTION_DOWN.
• [C-6-4] למשתמש חייב להיות מספיק מקום לעבור לניווט מבוסס-לחצנים במסך (לדוגמה, ב'הגדרות').
• אמורה לספק את הפונקציה 'בית' כהחלקה למעלה מהקצה התחתון של המסך הנוכחי.
• האפשרות 'אחרונים' צריכה לאפשר את הפונקציה של החלקה למעלה ואחיזה לפני השחרור, מאותו האזור שבו פועלת התנועה 'מסך הבית'.
• תנועות שמתחילות בתוך WindowInsets#getMandatorySystemGestureInsets() לא אמורות להיות מושפעות משיטות החרגה שהאפליקציה מספקת דרך האפליקציה View#setSystemGestureExclusionRects().

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

• [C-7-1] פונקציית הניווט חייבת להיות חוזרת (Back) ומוצגת כהחלקה מהקצה השמאלי והימני של המסך בכיוון הנוכחי.
• [C-7-2] אם חלוניות מערכת בהתאמה אישית ניתנות להחלקה מצוינות בקצה השמאלי או הימני, הן חייבות להיות ממוקמות בשליש העליון של המסך באמצעות סימון חזותי ברור ועקבי שגרירה פנימה תפעיל את החלוניות שהוזכרו, ולכן לא תתבצע חזרה. יכול להיות שמשתמש הגדיר חלונית מערכת כך שהיא תגיע מתחת לשליש העליון של המסך, אבל אסור להציג בחלונית המערכת יותר מ-1/3 מהקצוות.
• [C-7-3] אם באפליקציה בחזית מוגדרים הדגלים View.SYSTEM_UI_FLAG_IMMERSIVE או View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, החלקה מהקצוות חייבת להתנהג כמו שמוטמעת ב-AOSP, שמתועד ב--SDK.
• [C-7-4] כשבאפליקציה בחזית מוגדרים הדגלים View.SYSTEM_UI_FLAG_IMMERSIVE או View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, חלוניות מערכת בהתאמה אישית שניתן להחליק חייבות להיות מוסתרות עד שהמשתמש נכנס לסרגל המערכת (שנקרא גם ניווט ושורת סטטוס) כפי שהן מוטמעות ב-AOSP.

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

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

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

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

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

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

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

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

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

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

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

7.3.1. מד תאוצה

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

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

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

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

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

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

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

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

7.3.2. מגנטומטר

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

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

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

• [C-SR] מומלץ מאוד לכלול מקלט 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-SR] מומלץ מאוד להמשיך לספק פלט מיקום רגיל של GPS או GNSS באמצעות ממשקי API של ספק המיקום של GNSS במהלך שיחת טלפון במצב חירום.
  • [C-SR] מומלץ מאוד לדווח על מדידות של GNSS מכל קבוצות הכוכבים שבמעקב (כפי שדווח בהודעות GnssStatus), פרט ל-SBAS.
  • [C-SR] מומלץ מאוד לדווח על AGC ועל תדירות מדידת GNSS.
  • [C-SR] מומלץ מאוד לדווח על כל הערכות הדיוק (כולל נושא, מהירות ואנכי) כחלק מכל מיקום של GPS או GNSS.
  • [C-SR] מומלץ מאוד לדווח על מדידות של GNSS ברגע שהן נמצאו, גם אם המיקום שחושב על ידי GPS או GNSS עדיין לא דווח.
  • [C-SR] מומלץ מאוד לדווח על תזוזות פסאודו-טווח של GNSS וקצבי פסאודו-טווח, שבתנאי שמיים פתוחים לאחר קביעת המיקום, בזמן שהן נייחות או נעות עם תאוצה של פחות מ-0.2 מטר לשנייה, מספיקות לחישוב המיקום בטווח של 20 מטר, והמהירות בטווח של 0.2 מטר לשנייה, לפחות 95% מהמרחק.

7.3.4. ג'ירוסקופ

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

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

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

• [C-1-1] חייבת להיות אפשרות לדווח על אירועים בתדירות של עד 50Hz לפחות.
• [C-1-2] חובה להטמיע את החיישן TYPE_GYROSCOPE ומומלץ מאוד להטמיע גם את החיישן TYPE_GYROSCOPE_UNCALIBRATED.
• [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] שגיאת כיול מומלץ מאוד לערך של פחות מ-0.01 rad/s כאשר המכשיר נייח בטמפרטורת החדר.
• צריך לדווח על אירועים עד 200 Hz לפחות.

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

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

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

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

7.3.5. ברומטר

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

• [C-SR] מומלץ מאוד לכלול ברומטר (חיישן לחץ אוויר סביבתי).

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

• [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 או נמוכה יותר.
  • תדירות המדידה המקסימלית חייבת להיות 400 Hz או יותר. צריכה לתמוך ב-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 או נמוכה יותר.
  • תדירות המדידה המקסימלית חייבת להיות 400 Hz או יותר. צריכה לתמוך ב-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/לצאת.
  • כשהמכשיר לא נייח, אמורה להופיע שגיאת כיול בטווח טמפרטורות של 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.
• [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_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• צריכה לתמוך בדיווח על אירועים באמצעות ערוץ ישיר של חיישן לחיישן הראשי (וריאנט שלא נמצא במצב שינה) מהסוגים הבאים:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. חיישנים ביומטריים

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

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

• צריכה לכלול חיישן ביומטרי

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

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

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

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

• [C-0-2] חייב לעמוד בדרישות של המילה Strong כפי שהן מוגדרות במסמך הזה.

בנוסף:

• [C-0-3] חובה להתאים לפעולת אישור מפורשת (למשל, לחיצה על לחצן), אם הביומטריה חזקה היא פסיבית (למשל, פנים או קשתית העין, שלא קיים בהם אות מפורש לכוונת המשתמש).
  • [C-SR] מומלץ מאוד שהפעולה לאימות של מידע ביומטרי פסיבית תתבצע באופן מאובטח כך שלא תהיה אפשרות לזייף אותה דרך מערכת ההפעלה או בליבה (kernel). לדוגמה, המשמעות היא שפעולת האישור שמבוססת על לחצן פיזי מנותבת דרך סיכת קלט/פלט (GPIO) לשימוש כללי בלבד (GPIO) של רכיב מאובטח (SE) שלא ניתן לנוע בכל אמצעי אחר מלבד לחיצה על לחצן פיזי.

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

• [C-1-1] שיעור קבלה שגוי חייב להיות נמוך מ-0.002%.
• [C-1-2] חובה לציין שהמצב הזה עלול להיות פחות מאובטח מקוד אימות, קו ביטול נעילה או סיסמה חזקים, ולפרט באופן ברור את הסיכונים להפעלתו אם שיעור הסכמות של הזיוף וההתחזות גבוה מ-7%.
• [C-1-3] חובה להגביל את הקצב של יצירת הבקשות למשך 30 שניות לפחות לאחר חמישה ניסיונות כושלים לאימות ביומטרי – כאשר ניסוי שקרי הוא בעל איכות צילום הולמת (BIOMETRIC_ACQUIRED_GOOD) שלא תואמת למידע ביומטרי רשום.
• [C-1-4] חובה למנוע הוספה של מידע ביומטרי חדש בלי ליצור קודם שרשרת אמון, באמצעות דרישה של המשתמש לאשר קיים או להוסיף פרטי כניסה חדשים למכשיר (קוד אימות/קו ביטול נעילה/סיסמה) שמאבטחים על ידי TEE. הטמעת פרויקט קוד פתוח של Android מספקת בתוך המסגרת את המנגנון לביצוע פעולה זו.
• [C-1-5] חובה להסיר לחלוטין את כל הנתונים הביומטריים שניתנים לזיהוי של המשתמש כשהחשבון של המשתמש הוסר (כולל דרך איפוס להגדרות המקוריות).
• [C-1-6] חובה ליישם את הדגל הספציפי של המידע הביומטרי הזה (לדוגמה: DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE או DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
• [C-1-7] חובה לדרוש מהמשתמש לבקש את האימות הראשי המומלץ (למשל קוד אימות, קו ביטול נעילה, סיסמה) פעם ב-24 שעות או פחות במכשירים חדשים שמושקים עם Android בגרסה 10, פעם בכל 72 שעות או פחות במכשירים שמשדרגים מגרסה קודמת של Android.

• [C-1-8] חובה לבקש מהמשתמש לבצע את האימות הראשי המומלץ (למשל: קוד אימות, קו ביטול נעילה, סיסמה) אחרי אחת מהאפשרויות הבאות:

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

  יכול להיות שמכשירים שמשדרגים מגרסה קודמת של Android יהיו פטורים מקוד C-1-8.

• [C-SR] מומלץ מאוד ששיעור הדחייה השגוי יהיה נמוך מ-10%, כפי שנמדד במכשיר.

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

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

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

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

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

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

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

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 כללא תפעול.

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

• [C-3-1] חובה לספק הטמעה מלאה של EuiccManager API.

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

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

• [C-1-1] חייבת לכלול תמיכה בחסימת מספרים
• [C-1-2] חובה להטמיע באופן מלא את BlockedNumberContract ואת ה-API התואם, כפי שמתואר במסמכי התיעוד של ה-SDK.
• [C-1-3] חובה לחסום את כל השיחות וההודעות ממספר טלפון שנמצא ב-'blockNumberProvider' ללא אינטראקציה עם האפליקציות. יוצא הדופן היחיד הוא כאשר חסימת המספרים מבוטלת באופן זמני, כפי שמתואר במסמכי התיעוד של ה-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-1-3] חייבת להיות אפליקציה שבה מוטמע InCallService.

• [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-1-6] מומלץ מאוד כאשר מתבצעת קריאה לשיטת ה-API של ConnectivityManager.reportNetworkConnectivity(), חשוב להעריך מחדש את הגישה לאינטרנט דרך Network וכשההערכה קובעת שגישה Network לאינטרנט מספקת כבר לא מספקת גישה לאינטרנט. (
• [C-SR] מומלץ מאוד לבצע רנדומיזציה של כתובת ה-MAC של המקור ומספר הרצף של מסגרות בקשות הבדיקה, פעם אחת בתחילת כל סריקה, בזמן ש-STA מנותק.
  • כל קבוצה של מסגרות לבקשת בדיקה שמורכבת מסריקה אחת אמורה להשתמש בכתובת MAC עקבית אחת (לא צריכה להיות רנדומיזציה של כתובת MAC באמצע הסריקה).
  • מספר הרצף של בקשת גשושיות אמור לחזור על עצמו כרגיל (ברצף) בין בקשות גשול בסריקה.
  • מספר הרצף של בקשות גשושיות אמור להיות אקראי בין בקשת גשול האחרונה בסריקה לבין בקשת גשול הראשונה בסריקה הבאה.
• [C-SR] מומלץ מאוד לעשות זאת, בעוד שה-STA מנותק, כדי לאפשר רק את הרכיבים הבאים במסגרות של בקשות הבדיקה:
  • קבוצת פרמטרים של SSID (0)
  • קבוצת פרמטרים של DS (3)

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

• [C-3-1] חובה להשבית את מצב החיסכון בסוללה ב-Wi-Fi בכל פעם שיש באפליקציה נעילה של WIFI_MODE_FULL_HIGH_PERF או נעילה של WIFI_MODE_FULL_LOW_LATENCY דרך ממשקי API של WifiManager.createWifiLock() ו-WifiManager.WifiLock.acquire() והנעילה פעילה.
• [C-3-2] זמן האחזור הממוצע בין המכשיר לנקודת גישה לבין המכשיר במצב נעילה נמוכה ב-Wi-Fi (WIFI_MODE_FULL_LOW_LATENCY) חייב להיות קטן יותר מזמן האחזור במהלך מצב של נעילת ביצועים גבוהה ב-Wi-Fi (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR] מומלץ מאוד למזער את זמן האחזור של תהליך הלוך ושוב בחיבור Wi-Fi בכל פעם שמתקבלת נעילה של זמן אחזור נמוך (WIFI_MODE_FULL_LOW_LATENCY) ונכנסת לתוקף.

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

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

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

• אמורה לכלול תמיכה בהגדרת קישור ישיר ל-Wi-Fi (TDLS), כפי שמתואר בתיעוד של Android SDK.

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

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

7.4.2.3. עם חיבור ל-Wi-Fi

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

• צריכה לכלול תמיכה ב-Wi-Fi Aware.

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

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

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

• [C-2-1] חובה להטמיע את ממשקי ה-API לגילוי מבוסס-מיקום: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm ו-onServiceDiscoveredWithinRange.

7.4.2.4. Passpoint ל-Wi-Fi

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

• היא צריכה לכלול תמיכה ב-Wi-Fi Passpoint.

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

אם הטמעות המכשיר כוללות תמיכה במיקום 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.2.6. הסרה של Keepalive ב-Wi-Fi

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

• צריכה לכלול תמיכה בהורדה של עומסי Keepalive ב-Wi-Fi.

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

• [C-1-1] חייבת לתמוך ב-API של SocketKeepAlive.

• [C-1-2] חייבת להיות תמיכה בלפחות שלוש משבצות מודעה קבועות בו-זמנית ב-Wi-Fi ולפחות חריץ מודעה אחד מסוג מודעה ברשת סלולרית.

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

• [C-2-1] חייב להחזיר ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (פרוטוקול להקצאת מכשירים)

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

• צריכה לכלול תמיכה ב-Wi-Fi Easy Connect (DPP).

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

• [C-1-1] חובה להטמיע את ממשקי ה-API של Intent מסוג Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI כפי שמתואר במסמכי התיעוד של ה-SDK.
• [C-1-2] הפונקציה Wi-Manager#isEasyConnectSupported() מחזירה את הערך true.

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 עם צריכת אנרגיה נמוכה, הן:

• [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().

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

• [C-5-1] חייבת להחזיר true עבור BluetoothAdapter.getProfileProxy(context, Listener, BluetoothProfile.HEARING_AID).

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

• [C-3-1] חובה לדווח על קבוע התכונה android.hardware.nfc.hcef.
• [C-3-2] חובה להטמיע את ממשקי ה-API של האמולציה של כרטיסי NfcF ב-Android SDK.

אם הטמעות המכשירים כוללות תמיכה כללית ב-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-1-1] חייבת לתמוך בכל ממשקי ה-API במחלקה ConnectivityManager, כפי שמתואר במסמכי התיעוד של ה-SDK
• [C-1-2] בהגדרות המשתמשים חייבים לספק ממשק משתמש שמטפל ב-Intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, שמאפשר למשתמשים להוסיף אפליקציות לרשימת ההיתרים או להסיר אפליקציות ממנה.

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

• [C-2-1] חייב להחזיר את הערך RESTRICT_BACKGROUND_STATUS_DISABLED עבור ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] אסור לשדר את ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
• [C-2-3] חייבת להיות פעילות שמטפלת ב-Intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, אבל יכול להיות שצריך להטמיע אותה כפעולה ללא תפעול.

7.4.8. רכיבים מאובטחים

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

• [C-1-1] חובה לספור את הקוראים הזמינים של 'רכיבים מאובטחים' כשמפעילים את השיטה android.se.omapi.SEService.getReaders().

7.5. מצלמות

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

• [C-1-1] חובה להצהיר על דגל התכונה android.hardware.camera.any.
• [C-1-2] חייבת להיות אפשרות לאפליקציה להקצות בו-זמנית 3 מפות סיביות של RGBA_8888 השווה לגודל התמונות שמופקות על ידי חיישן המצלמה ברזולוציה הגבוהה ביותר במכשיר, והמצלמה פתוחה למטרת תצוגה מקדימה בסיסית וצילום עדיין.
• [C-1-3] לפני השליחה לאפליקציה המקבלת אם אין לאפליקציה המקבלת את התכונה ACCESS_FINE_LOCATION חשוב להסיר את המיקום של המשתמש מהמטא-נתונים של התמונה לפני ההתקנה של אפליקציית המצלמה שמוגדרת מראש כברירת מחדל.MediaStore.ACTION_IMAGE_CAPTUREMediaStore.ACTION_IMAGE_CAPTURE_SECUREMediaStore.ACTION_VIDEO_CAPTURE

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 ובמחלקה android.hardware.camera2.CaptureRequest. לעומת זאת, אסור שהטמעות במכשירים יפעלו כקבועים של מחרוזות שמועברים ל-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.request.availableCapabilities על יכולות המצלמה הנפרדות של android.hardware.camera2 ולהצהיר על פיצ'רים ניסיוניים מתאימים. חובה להגדיר את התכונה הניסיונית אם אחד ממכשירי המצלמה המחוברים אליה תומך בתכונה.
• [C-0-9] חובה לשדר את ה-Intent Camera.ACTION_NEW_PICTURE בכל פעם שתמונה חדשה צולמה על ידי המצלמה והרשומה של התמונה מתווספת לחנות המדיה.
• [C-0-10] חובה לשדר את ה-Intent Camera.ACTION_NEW_VIDEO בכל פעם שסרטון חדש מצולם על ידי המצלמה וכניסת התמונה מתווספת לחנות המדיה.
• [C-0-11] כל המצלמות צריכות להיות נגישות דרך API של android.hardware.Camera שהוצא משימוש, שאפשר לגשת אליו גם דרך ה-API של android.hardware.camera2.
• [C-SR] במכשירים עם כמה מצלמות RGB שפונה לאותו כיוון, מומלץ מאוד לתמוך במכשיר מצלמה לוגי עם רשימת יכולות CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, שמורכב מכל מצלמות ה-RGB שפונות לכיוון הזה כמכשירי משנה פיזיים.

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

• [C-1-1] חובה להטמיע API כזה של מצלמה באמצעות android.hardware.camera2 API.
• ייתכן לספק תגים ו/או תוספים של הספק ל-API של android.hardware.camera2.

7.5.5. כיוון המצלמה

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

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

7.6. זיכרון ואחסון

7.6.1. נפח זיכרון ואחסון מינימלי

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

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

7.6.2. אחסון משותף באפליקציות

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

• [C-0-1] חובה להציע נפח אחסון שמשותף לאפליקציות, שנקרא גם 'אחסון חיצוני משותף', 'אחסון משותף לאפליקציות' או באמצעות הנתיב " /sdcard" ב-Linux שאליו הוא מותקן.
• [C-0-2] חובה להגדיר אמצעי אחסון משותף שטעון כברירת מחדל. כלומר, "הוצאה מהאריזה", גם אם האחסון מוטמע על רכיב אחסון פנימי או על אמצעי אחסון נשלף (למשל, חריץ לכרטיס Secure Digital).
• [C-0-3] חובה לטעון את האחסון המשותף של האפליקציה ישירות בנתיב sdcard של Linux או לכלול קישור סימבולי של Linux מ-sdcard לנקודת הטעינה עצמה.
• [C-0-4] חובה לאכוף את ההרשאה android.permission.WRITE_EXTERNAL_STORAGE באחסון המשותף הזה כפי שמתועד ב-SDK.
• [C-0-5] חובה להפעיל נפח אחסון בהיקף כברירת מחדל לכל האפליקציות שמטרגטות לרמת API 29 ומעלה, חוץ מאשר במצבים הבאים:
  • כשהאפליקציה הותקנה לפני שהמכשיר שודרג לרמת API 29, בלי קשר ל-API המטורגט של האפליקציה.
  • כאשר האפליקציה ביקשה android:requestLegacyExternalStorage="true" במניפסט.
  • כשהאפליקציה מקבלת את ההרשאה android.permission.WRITE_MEDIA_STORAGE.
• [C-0-6] חובה לאכוף את העובדה שלאפליקציות שמופעלת בהן נפח אחסון היקף לא תהיה גישה ישירה למערכת הקבצים לקבצים שנמצאים מחוץ לספריות הספציפיות לאפליקציה, כפי שהוא מוחזר באמצעות שיטות API של Context כמו Context.getExternalFilesDirs(), Context.getExternalCacheDirs(), Context.getExternalMediaDirs() ו-Context.getObbDirs().
• [C-0-7] חובה לצנזר מטא-נתונים של מיקום, כמו תגי GPS Exif, ששמורים בקובצי מדיה כשניגשים לקבצים האלה דרך MediaStore, חוץ מאשר כשאפליקציית השיחות מחזיקה בהרשאה ACCESS_MEDIA_LOCATION.

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

• אחסון נשלף שנגיש למשתמש, כמו חריץ לכרטיס Secure Digital (SD).
• חלק מהאחסון הפנימי (לא ניתן להסרה) כפי שמוטמע בפרויקט קוד פתוח (AOSP) של Android.

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

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

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

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

אם הטמעות המכשיר כוללות כמה נתיבי אחסון משותפים (כמו חריץ לכרטיס SD וגם אחסון פנימי משותף), הן:

• [C-2-1] חובה לאפשר רק לאפליקציות Android שמותקנות מראש וקיבלו הרשאות WRITE_MEDIA_STORAGE לכתוב באחסון החיצוני המשני, למעט כשכותבים לספריות הספציפיות לחבילה או בתוך URI שמוחזר על-ידי הפעלה של ה-Intent ACTION_OPEN_DOCUMENT_TREE.
• [C-2-2] חובה לדרוש שהגישה הישירה המשויכת להרשאה android.permission.WRITE_MEDIA_STORAGE תינתן רק לאפליקציות שגלויות למשתמשים רק אם ניתנה גם ההרשאה android.permission.WRITE_EXTERNAL_STORAGE.
• [SR] מומלץ מאוד שאפליקציות ל-Android שהותקנו מראש וקיבלו הרשאות ישתמשו בממשקי API ציבוריים כמו MediaStore כדי לקיים אינטראקציה עם התקני אחסון, במקום להסתמך על הגישה הישירה שהוענקה על ידי android.permission.WRITE_MEDIA_STORAGE.

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

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

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

• אמורה להיות תואמת למארח MTP של Android, העברת קבצים ב-Android.
• אמור לדווח על סוג התקן USB 0x00.
• יש לדווח על שם ממשק ה-USB 'MTP'.

7.6.3. אחסון מותאם

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

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

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

• [SR] מומלץ מאוד להטמיע אחסון שניתן ליישם.

7.7. USB

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

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

7.7.1. מצב ציוד היקפי בחיבור USB

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

• [C-1-1] היציאה חייבת להיות מחוברת למארח USB שיש בו יציאת USB סטנדרטית מסוג A או 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 (שקע).
• [C-SR] מומלץ מאוד להטמיע את סיווג האודיו USB, כפי שמתועד במסמכי התיעוד של Android SDK.
• אמורה לתמוך בטעינת הציוד ההיקפי המחובר בחיבור USB במצב מארח. פרסום מקור זרם של לפחות 1.5A כפי שצוין בקטע 'פרמטרים לסיום סיום' בתיקון 1.2 של כבל USB-C ומפרט מחבר מסוג USB-C עבור מחברי USB-C או באמצעות טווח הנוכחי של פלט טעינה ביציאת USB-C, כפי שמצוין במפרט לטעינת סוללה ב-USB, גרסה 1.2 למחברי מיקרו-AB.
• עליכם להטמיע ולתמוך בתקני USB Type-C.

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

• [C-2-1] חייב לתמוך בסיווג USB HID.
• [C-2-2] חייבת לתמוך בזיהוי ובמיפוי של שדות נתוני ה-HID הבאים, המפורטים ב-USB HID Usage Tables (טבלאות שימוש ב-USB HID) ובבקשה לשימוש בפקודות קוליות (Voice Command Usage) אל הקבועים של 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.2.2. יציאות אודיו דיגיטליות

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

דרישות ספציפיות למכשיר מופיעות בסעיף 2.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.8.4. תקינות האות

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

• אמור לספק נתיב של אות אודיו ללא תקלה עבור שידורי הקלט והפלט במכשירים ניידים, כפי שמוגדר באמצעות אפס תקלות שנמדדות בבדיקה של דקה אחת בכל נתיב. השתמשו ב-[OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) 'בדיקת תקלה אוטומטית'.

לצורך הבדיקה נדרש מתאם אודיו בלופ, שמשתמשים בו ישירות בשקע 3.5 מ"מ או בשילוב עם מתאם USB-C עד 3.5 מ"מ. כל היציאות של פלט האודיו צריכות להיבדק.

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

מצב ביצועים	שיתוף	תדירות הדגימה יוצאת	בצ'אנס	צ'אן אאוט
LOW_LATENCY	בלעדי	לא מסומן	1	2
LOW_LATENCY	בלעדי	לא מסומן	2	1
LOW_LATENCY	משותף	לא מסומן	1	2
LOW_LATENCY	משותף	לא מסומן	2	1
ללא	משותף	48000	1	2
ללא	משותף	48000	2	1
ללא	משותף	44100	1	2
ללא	משותף	44100	2	1
ללא	משותף	16000	1	2
ללא	משותף	16000	2	1

זרם אמין צריך לעמוד בקריטריונים הבאים של יחס אות לרעש (SNR) ושל עיוות הרמוני כולל (THD) ל-2,000 Hz סינוס.

מתמר	THD	חיישן SNR
רמקול מובנה ראשי, שנמדד באמצעות מיקרופון חיצוני להתייחסות	< 3.0%	>= 50 dB
מיקרופון מובנה ראשי, שנמדד באמצעות רמקול עזר חיצוני	< 3.0%	>= 50 dB
שקעים אנלוגיים מובנים בגודל 3.5 מ"מ, נבדקים באמצעות מתאם לולאה חוזרת	< 1%	>= 60 dB
מתאמי USB שסופקו עם הטלפון, נבדקו באמצעות מתאם לולאה חוזרת	< 1.0%	>= 60 dB

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 בקצב של 1920 x 1080 ב- 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-0-1] חובה לדווח על תמיכה במצב Sustained Performance באופן מדויק באמצעות שיטת ה-API PowerManager.isSustainedPerformanceModeSupported().

• אמורה לתמוך במצב ביצועים קבועים.

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

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

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

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

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

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

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

• [C-3-1] חייבת להחזיר רשימה ריקה באמצעות שיטת ה-API Process.getExclusiveCores().

9. תאימות של דגם אבטחה

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

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

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

9.1. הרשאות

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

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

• יכול להיות שיתווספו עוד הרשאות, בתנאי שהמחרוזות החדשות של מזהה ההרשאה לא נמצאות במרחב השמות של android.\*.

• [C-0-2] הרשאות עם protectionLevel של PROTECTION_FLAG_PRIVILEGED חייבות להיות מוענקות רק לאפליקציות שהותקנו מראש בנתיבים עם ההרשאות שבתמונת המערכת ובקבוצת המשנה של ההרשאות שנוספו באופן מפורש לרשימת ההיתרים, לכל אפליקציה. הטמעת ה-AOSP עומדת בדרישה הזו: היא קוראת את ההרשאות שכלולות ברשימת ההיתרים לכל אפליקציה מהקבצים בנתיב etc/permissions/ ומשתמשת בנתיב system/priv-app כנתיב בעל ההרשאות.

הרשאות עם רמת הגנה מסוכנות הן הרשאות בתחילת ההפעלה. אפליקציות עם targetSdkVersion > 22 לבקש אותם בזמן הריצה.

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

• [C-0-3] חובה להציג ממשק ייעודי למשתמשים כדי להחליט אם להעניק את ההרשאות הנדרשות בתחילת ההפעלה, וגם לספק ממשק למשתמש לניהול הרשאות בתחילת הריצה.
• [C-0-4] חייבת להיות הטמעה אחת בלבד של שני ממשקי המשתמש.
• [C-0-5] אסור להעניק הרשאות סביבת זמן ריצה לאפליקציות שהותקנו מראש, אלא אם:
  • אפשר לקבל את הסכמת המשתמש לפני שהאפליקציה משתמשת בו.
  • ההרשאות בתחילת ההפעלה משויכות לדפוס Intent, שבו האפליקציה שהותקנה מראש מוגדרת כ-handler שמוגדר כברירת מחדל.
• [C-0-6] חובה להעניק את ההרשאה android.permission.RECOVER_KEYSTORE רק לאפליקציות מערכת שרושמות סוכן שחזור מאובטח כראוי. סוכן שחזור שמאובטח כראוי מוגדר כסוכן תוכנה במכשיר שמסתנכרן עם אחסון מרוחק מחוץ למכשיר, ומצויד בחומרה מאובטחת עם הגנה מקבילה או חזקה יותר ממה שמתואר בשירות הכספת למפתחות של Google Cloud, כדי למנוע התקפות מסוג brute-force על גורם הידע במסך הנעילה.

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

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

  • מיקום המכשיר (למשל, קו רוחב וקו אורך).
  • מידע שיכול לשמש כדי לקבוע או להעריך את מיקום המכשיר (למשל SSID , BSSID, מזהה תא, סריקות Bluetooth או המיקום של הרשת שאליה המכשיר מחובר).
  • הפעילות הגופנית של המשתמש או סיווג הפעילות הגופנית.

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

• [C-0-8] חובה לקבל את הסכמת המשתמשים כדי לאפשר לאפליקציה לגשת לנתוני המיקום או לנתוני הפעילות הגופנית.
• [C-0-9] חייבת לתת הרשאה בתחילת ההפעלה רק לאפליקציה שיש לה הרשאה מספקת, כפי שמתואר ב-SDK. לדוגמה, הפונקציה טלפוניהManager#getServiceState מחייבת android.permission.ACCESS_FINE_LOCATION).

אפשר לסמן הרשאות כמוגבלות בשינוי ההתנהגות.

• [C-0-10] הרשאות שמסומנות בדגל hardRestricted לא יוענקו לאפליקציה, אלא אם:

  • קובץ APK של אפליקציה נמצא במחיצת המערכת.
  • המשתמש מקצה לאפליקציה תפקיד שמשויך להרשאות hardRestricted.
  • מנהל ההתקנה מעניק את ההרשאה hardRestricted לאפליקציה.
  • אפליקציה מקבלת את hardRestricted בגרסה קודמת של Android.

• [C-0-11] אפליקציות עם הרשאת גישה ל-softRestricted חייבות לקבל גישה מוגבלת בלבד, ואסור להן לקבל גישה מלאה עד שיתווספו לרשימת ההיתרים כפי שמתואר ב-SDK. באפליקציות האלה מוגדרת גישה מלאה ומוגבלת לכל הרשאה של softRestricted (לדוגמה, WRITE_EXTERNAL_STORAGE ו-READ_EXTERNAL_STORAGE).

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

• [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. הרשאות במערכת הקבצים

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

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

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

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). דוגמאות למנגנונים כאלה: CC_STACKPROTECTOR_REGULAR ו-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) אם החומרה חשופה ל-CVE-2017-5754 בכל המכשירים שנשלחו במקור עם רמת API 28 ומעלה (למשל CONFIG_PAGE_TABLE_ISOLATION או CONFIG_UNMAP_KERNEL_AT_EL0).
• [C-0-13] חובה להטמיע הקשחת חיזוי הסתעפות אם החומרה חשופה ל-CVE-2017-5715 בכל המכשירים שנשלחו במקור עם רמת API 28 ומעלה (למשל CONFIG_HARDEN_BRANCH_PREDICTOR).
• [SR] מומלץ מאוד לשמור נתוני ליבה שנכתבו רק במהלך האתחול ומסומנים לקריאה בלבד לאחר האתחול (למשל __ro_after_init).

• [C-SR] מומלץ מאוד להגדיר באופן אקראי את הפריסה של קוד הליבה ושל הזיכרון, וכדי להימנע מחשיפות שעלולות לפגוע ברנדומיזציה (למשל, CONFIG_RANDOMIZE_BASE עם אנטרופיה של תוכנת אתחול דרך /chosen/kaslr-seed Device Tree node או EFI_RNG_PROTOCOL).

• [C-SR] מומלץ מאוד להפעיל את שלמות תהליך הבקרה (CFI) בליבה (kernel) כדי לספק הגנה נוספת מפני התקפות שימוש חוזר בקוד (למשל CONFIG_CFI_CLANG ו-CONFIG_SHADOW_CALL_STACK).

• [C-SR] מומלץ מאוד לא להשבית את Control-Flow Integrity (CFI), את: Shadow Call Stack (SCS) או את Integer Overflow Sanitization (IntSan) ברכיבים שבהם היא מופעלת.
• [C-SR] מומלץ מאוד להפעיל את CFI, SCS ו-IntSan ברכיבים נוספים של מרחב משתמש רגיש מבחינת אבטחה, כפי שמוסבר ב-CFI וב-IntSan.

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

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-0-2] חובה להציג ולקבל הסכמה מפורשת מהמשתמשים. ההודעה הזו כוללת באופן משמעותי הודעה זהה לזו שמופיעה ב-AOSP בכל פעם שמפעילים העברה של מסך או הקלטת מסך דרך MediaProjection או ממשקי API קנייניים. אסור לספק למשתמשים אפשרות להשבית תצוגה עתידית של הסכמת המשתמש.

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

אם הטמעות המכשיר כוללות פונקציונליות במערכת שמתעדת את התוכן שמוצג במסך ו/או מקליטה את שידור האודיו שמופעל במכשיר ולא באמצעות System API ContentCaptureService או אמצעים קנייניים אחרים שמתוארים בסעיף 9.8.6 צילום תוכן:

• [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.8.5. מזהי המכשיר

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

• [C-0-1] חובה למנוע גישה למספר הסידורי של המכשיר, ובמקרים הרלוונטיים גם IMEI/MEID, המספר הסידורי של ה-SIM והזהות הבינלאומית של מנוי בנייד (IMSI), אלא אם האפליקציה עומדת באחת מהדרישות הבאות:
  • היא אפליקציית ספק חתומה שאומתה על ידי יצרני מכשירים.
  • קיבל את ההרשאה READ_PRIVILEGED_PHONE_STATE.
  • יש הרשאות ספק כפי שמוגדר בהרשאות ספק ב-UICC.
  • הם בעלי מכשיר או בעלים של פרופיל שקיבלו את ההרשאה READ_PHONE_STATE.
  • (למספר הסידורי של כרטיס ה-SIM/ל-ICCID בלבד) יש דרישה לתקנות המקומיות שלפיה האפליקציה תזהה שינויים בזהות של המנוי.

9.8.6. תיעוד תוכן

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

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

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

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

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

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

• [C-SR] מומלץ מאוד לשמור על הפרדה בין רכיבי השירות להקלטת התוכן, לדוגמה, לא לקשר את המזהים של תהליך השיתוף או את השירות, מרכיבי מערכת אחרים, חוץ מהדברים הבאים:

  • טלפוניה, אנשי קשר, ממשק משתמש של המערכת ומדיה

9.8.7. גישה ללוח

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

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

9.8.8. מיקום

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

• [C-0-1] אסור להפעיל או להשבית את הגדרת המיקום של המכשיר ואת ההגדרות של סריקת Wi-Fi/Bluetooth ללא הסכמה מפורשת מהמשתמש או ביוזמת המשתמש.
• [C-0-2] חובה לספק למשתמשים אפשרות לגשת למידע שקשור למיקום, כולל בקשות מיקום אחרונות, הרשאות ברמת האפליקציה ושימוש בסריקת Wi-Fi/Bluetooth לקביעת המיקום.
• [C-0-3] חובה לוודא שהאפליקציה שמשתמשת בממשק ה-API של עקיפת מיקום חירום [LocationRequest.setLocationSettingsignored()] היא מצב חירום ביוזמת המשתמש (למשל: מחייגים ל-911 או שולחים הודעת טקסט ל-911).
• [C-0-4] חובה לשמר את היכולת של ממשק ה-API לעקיפת מיקום למצב חירום לעקוף את הגדרות המיקום של המכשיר בלי לשנות את ההגדרות.
• [C-0-5] חובה לתזמן התראה שתזכיר למשתמש אחרי שאפליקציה ברקע ניגשה למיקום שלו באמצעות ההרשאה [ACCESS_BACKGROUND_LOCATION].

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

כל המכשירים חייבים לעמוד בדרישות של סעיף 9.9.1. מכשירים שהושקו ברמת API מוקדמת יותר מזו של המסמך הזה פטורים מהדרישות של הסעיפים 9.9.2 ו-9.9.3; במקום זאת, הן חייבות לעמוד בדרישות המפורטות בסעיף 9.9 במסמך 'הגדרת תאימות ל-Android', שמתאימות לרמת ה-API שבה המכשיר הופעל.

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

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

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

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

9.9.2. דרישות לגבי הצפנה

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

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

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

מכשירים מוצפנים:

• [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 או Adiantum. AES-256-XTS מתייחס לתקן ההצפנה המתקדם עם אורך מפתח להצפנה של 256 ביט, שמופעל במצב XTS; האורך המלא של המפתח הוא 512 ביטים. Adiantum מתייחס ל-Adiantum-XChaCha12-AES, כפי שמצוין בכתובת https://github.com/google/adiantum.
• [C-1-6] חובה להצפין את שמות הקבצים באמצעות AES-256-CBC-CTS או Adiantum.

• [C-1-12] חובה להשתמש ב-AES-256-XTS לתוכן קבצים וב-AES-256-CBC-CTS לשמות הקבצים (במקום ב-Adiantum) אם יש במכשיר הוראות לתיקון ההצפנה המתקדם (AES). הוראות AES הן תוספי קריפטוגרפיה ARMv8 במכשירים מבוססי ARM או AES-NI במכשירים מבוססי x86. אם אין במכשיר הוראות AES, יכול להיות שהוא ישתמש ב-Adiantum.

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

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

אם הטמעות מכשירים כבר הושקו ללא תמיכה ב-C-1-8 עד C-10 בגרסה קודמת של Android, ולא ניתן להוסיף להן תמיכה בדרישות האלה באמצעות עדכון תוכנת מערכת, יכול להיות שהן יהיו פטורות מהדרישות.

פרויקט הקוד הפתוח של Android ב-upstream מספק הטמעה מועדפת של התכונה הזו במאגר external/avb/, ואפשר לשלב אותה בתוכנת האתחול שמשמשת לטעינת Android.

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

• [C-R] מומלץ לתמוך ב-Android Protected Confirm API.

אם ההטמעות במכשירים תומכים ב-Android Protected Certificate API, הם:

• [C-3-1] חובה לדווח על true עבור ה-API של ConfirmationPrompt.isSupported().

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

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

9.11. מפתחות ופרטי כניסה

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

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

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

• [C-1-1] חייבים לגבות את ההטמעה של מאגר המפתחות באמצעות סביבת הפעלה מבודדת
• [C-1-2] חייבות להיות הטמעות של אלגוריתמים קריפטוגרפיים RSA, AES, ECDSA ו-HMAC, וגם פונקציות גיבוב (hash) משפחתיות של MD5, SHA1 ו-SHA-2, כדי לתמוך כראוי באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמופרד באופן מאובטח מהקוד שפועל בליבה (kernel) ומעלה. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבהם קוד ליבה או מרחב משתמשים יכול לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. פרויקט הקוד הפתוח של Android (AOSP) ב-upstream עומד בדרישה הזו באמצעות ההטמעה של Trusty. במקום זאת, יש עוד אפשרויות לפתרון מבוסס ARM TrustZone או הטמעה מאובטחת של צד שלישי עם בידוד מתאים שמבוסס על hypervisor.
• [C-1-3] חובה לבצע את האימות של מסך הנעילה בסביבת הביצוע המבודדת, ורק כשהפעולה מבוצעת בהצלחה, תתאפשר שימוש במפתחות שקשורים לאימות. יש לאחסן את פרטי הכניסה של מסך הנעילה באופן שיאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. פרויקט הקוד הפתוח של Android ב-upstream מספק את Gatekeeper Hardware Layer Abstraction Layer (HAL) ואת Trusty, ואפשר להשתמש בהם כדי לעמוד בדרישה הזו.
• [C-1-4] חייבת להיות תמיכה באימות עם מפתחות כאשר מפתח חתימת האימות מוגן באמצעות חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. חובה לשתף את מפתחות חתימת האימות בין מספר גדול מספיק של מכשירים כדי למנוע שימוש במפתחות כמזהי מכשירים. אחת הדרכים לעמוד בדרישה הזו היא לשתף את אותו מפתח אימות, אלא אם יוצרים לפחות 100,000 יחידות של מק"ט נתון. אם מפיקים יותר מ-100,000 יחידות של מק"ט, יכול להיות שייעשה שימוש במפתח שונה לכל 100,000 יחידות.

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

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

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

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

• [C-4-1] חייבת לעמוד בכל הדרישות שמפורטות בסעיף 7.3.10 בנוגע לנוחות.
• [C-4-2] חייב להיות מנגנון של חזרה למצב הקודם כדי להשתמש באחת משיטות האימות הראשיות המומלצות המבוססות על סוד ידוע.
• [C-4-3] חובה להשבית ולאפשר לאימות הראשי המומלץ לבטל את נעילת המסך רק כשהאפליקציה 'בקר מדיניות מכשירים (DPC)' הגדיר את מדיניות התכונה של מגן המפתחות באמצעות קריאה ל-method DevicePolicyManager.setKeyguardDisabledFeatures(), יחד עם כל אחד מהדגלים הביומטריים המשויכים (למשל KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE או KEYGUARD_DISABLE_IRIS).

אם שיטות האימות הביומטרי לא עומדות בדרישות עבור חזק כפי שמתואר בסעיף 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] חובה לאמת את המשתמש לגבי אחת משיטות האימות הראשיות המומלצות (למשל: קוד אימות, קו ביטול נעילה, סיסמה) לפחות פעם ב-4 שעות או פחות.
• [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 בהמשך.
• [C-7-11] אסור לאפשר לסוכנים מהימנים לבטל את הנעילה של המכשיר באמצעות מכשירים אישיים ראשיים (למשל, בהחזקה ביד), והם יכולים להשתמש בהם רק כדי להשאיר מכשיר שכבר לא נעול במצב ביטול הנעילה למשך עד 4 שעות. הטמעת ברירת המחדל של TrustManagerService ב-AOSP עומדת בדרישה הזו.
• [C-7-12] חובה להשתמש בערוץ תקשורת מאובטח מבחינה קריפטוגרפית (למשל UKEY2) כדי להעביר את אסימון הנאמנות ממכשיר האחסון למכשיר היעד.

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

• [C-8-1] השיטה החדשה חייבת להיות מושבתת אם האפליקציה Device Policy Controller (DPC) הגדירה את המדיניות בנושא איכות הסיסמאות באמצעות השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_UNSPECIFIED.
• [C-8-2] אסור להם לאפס את הטיימרים לתפוגת הסיסמה שהוגדרו על ידי DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] אסור לחשוף API לשימוש של אפליקציות צד שלישי לשינוי מצב הנעילה.

9.11.2. StrongBox

מערכת Android Keystore מאפשרת למפתחי אפליקציות לאחסן מפתחות קריפטוגרפיים במעבד ייעודי מאובטח, וגם בסביבת הביצוע המבודדת שמתוארת למעלה. מעבד מאובטח ייעודי כזה נקרא 'StrongBox'. בדרישות C-1-3 עד C-1-11 שבהמשך מוגדרות הדרישות שמכשיר חייב לעמוד בהן כדי לעמוד בדרישות של StrongBox.

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

• [C-SR] אנחנו ממליצים מאוד לתמיכה ב-StrongBox. סביר להניח ש-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-1-10] חייבת לכלול את החומרה שאושרה מול Secure IC Protection Profile BSI-CC-PP-0084-2014 או שנבדקה על ידי מעבדת בדיקות שקיבלה הכרה לאומית, שמשולבת בה הערכה של פוטנציאל תקיפה גבוה בהתאם לקריטריונים נפוצים ליישום פוטנציאל התקפה על כרטיסי Smartcards.
  • [C-1-11] חייבת לכלול את הקושחה שנבדקת על ידי מעבדת בדיקות בעלת הסמכה לאומית, המשלבת הערכה של נקודות חולשה פוטנציאליות של התקפת גבוהה בהתאם לקריטריונים נפוצים של פוטנציאל התקפה על כרטיסי Smartcards.
  • [C-SR] מומלץ מאוד לכלול את החומרה שנבדקת באמצעות Security Target, Evaluation Assurance Level (EAL) 5, בתוספת AVA_VAN.5. סביר להניח שאישור EAL 5 יהפוך לדרישה בגרסה עתידית.

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

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

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

• [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 כוללת מנגנון עדכון שעומד בדרישה הזו.

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

• [C-SR] מומלץ מאוד לבצע גיבוב של העדכון באמצעות SHA-256 ולאמת את הגיבוב מול המפתח הציבורי באמצעות ECDSA NIST P-256.

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