החל משנת 2026, כדי להתאים את התהליך למודל הפיתוח היציב שלנו ולשמור על יציבות הפלטפורמה בסביבה העסקית, נפרסם קוד מקור ב-AOSP ברבעון השני וברבעון הרביעי. כדי ליצור תוספים ל-AOSP ולתרום לו, מומלץ להשתמש ב-android-latest-release במקום ב-aosp-main. ענף המניפסט android-latest-release תמיד יפנה לגרסה העדכנית ביותר שנדחפה ל-AOSP. מידע נוסף זמין במאמר שינויים ב-AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

1. מבוא

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

השימוש במילים MUST,‏ MUST NOT,‏ REQUIRED,‏ SHALL,‏ SHALL NOT,‏ SHOULD,‏ SHOULD NOT,‏ RECOMMENDED,‏ MAY ו-OPTIONAL הוא בהתאם לתקן IETF שמוגדר ב-RFC2119.

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

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

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

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

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

‫1.1 מבנה המסמך

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

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

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

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

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

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

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

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

‫1.1.3. מזהה הדרישה בחלק 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1. חומרה

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

‫[7.1.1.1/H-0-1] חייב להיות לפחות מסך אחד שתואם ל-Android, עם מידות של לפחות 2.2 אינץ' בצד הקצר ו-3.4 אינץ' בצד הארוך.
‫[7.1.1.3/H-SR-1] מומלץ מאוד לספק למשתמשים אפשרות לשנות את גודל התצוגה (צפיפות המסך).
‫[7.1.1.1/H-0-2] המכשיר חייב לתמוך בהרכבת GPU של מאגרי גרפיקה לפחות בגודל של הרזולוציה הגבוהה ביותר של כל תצוגה מובנית.
‫[7.1.1.1/H-0-3]^* חובה למפות כל תצוגה שזמינה לאפליקציות של צד שלישי לאזור תצוגה פיזי ללא הפרעות, שגודלו לפחות 2.2 אינץ' בצד הקצר ו-3.4 אינץ' בצד הארוך.UI_MODE_NORMAL
‫[7.1.1.3/H-0-1]^* חובה להגדיר את DENSITY_DEVICE_STABLE כ-92% או יותר מהצפיפות הפיזית בפועל של המסך המתאים.

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

‫[7.1.4.2/H-1-1] המכשיר חייב לעמוד בדרישות שצוינו בפרופיל הבסיס של Android‏ 2021.

אם הטמעות של מכשירים שניתן להחזיק ביד מצהירות על תמיכה בכל ABI של 64 ביט (עם או בלי ABI של 32 ביט) ומחזירות false עבור ActivityManager.isLowRamDevice(), הן:

‫[7.1.4.2/H-2-1] חובה לתמוך ב-Vulkan 1.1 או בגרסה מתקדמת יותר.

אם הטמעות של מכשירים שניתן להחזיק ביד טוענות לתמיכה במסכים עם טווח דינמי גבוה (HDR) באמצעות 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.4.6/H-0-1] המכשיר חייב לדווח אם הוא תומך ביכולת ליצור פרופיל של GPU באמצעות מאפיין מערכת graphics.gpu.profiler.support.

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

‫[7.1.4.6/H-1-1] חובה לדווח כפלט על עקבות של protobuf שתואם לסכימה של מוני GPU ושל שלבי עיבוד של GPU שמוגדרים במסמכי התיעוד של Perfetto.
‫[7.1.4.6/H-1-2] חובה לדווח על ערכים תואמים של מוני ה-GPU של המכשיר בהתאם ל-gpu counter trace packet proto.
‫[7.1.4.6/H-1-3] חובה לדווח על ערכים תואמים של GPU RenderStages (שלבי עיבוד של GPU) במכשיר בהתאם ל-render stage trace packet proto (פרוטוקול של מנות מעקב של שלבי עיבוד).
‫[7.1.4.6/H-1-4] חובה לדווח על נקודת מעקב של תדר GPU בהתאם לפורמט: power/gpu_frequency.

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

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

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

‫[7.3.1/H-1-1] חובה לדווח על אירועים בתדירות של לפחות 100 הרץ.

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

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

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

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

‫[7.3.8/H] מומלץ לכלול חיישן קירבה.

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

‫[7.3.11/H-SR-1] מומלץ מאוד לתמוך בחיישן תנוחה עם 6 דרגות חופש.

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

‫[7.4.1/H-1-1] חובה להצהיר על ה-feature flag‏ android.hardware.telephony.data.

הטמעות במכשירים שניתן להחזיק ביד שכוללות תמיכה ב-Bluetooth LE:

‫[7.4.3/H-SR-1] מומלץ מאוד לתמוך בהרחבת אורך מנות הנתונים של Bluetooth LE.

הערה: הדרישה הזו [7.4.3/H-SR-1] תהפוך ל-MUST בגרסת Android עתידית.

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

‫[7.4.2.4/H-1-1] חובה לכלול תמיכה ב-Wi-Fi Passpoint.

אם המכשירים תומכים בפרוטוקול Wi-Fi Neighbor Awareness Networking‏ (NAN) על ידי הצהרה על PackageManager.FEATURE_WIFI_AWARE ובפרוטוקול Wi-Fi Location (זמן הלוך ושוב של Wi-Fi‏ – RTT) על ידי הצהרה על PackageManager.FEATURE_WIFI_RTT, הם:

‫[7.4.2.5/H-1-1] המכשיר חייב לדווח על הטווח בצורה מדויקת בטווח של ‎+/-1 מטר ברוחב פס של 160 MHz באחוזון ה-68 (כפי שמחושב באמצעות פונקציית ההתפלגות המצטברת), ‎+/-2 מטרים ברוחב פס של 80 MHz באחוזון ה-68, ‎+/-4 מטרים ברוחב פס של 40 MHz באחוזון ה-68 ו-‎+/-8 מטרים ברוחב פס של 20 MHz באחוזון ה-68 במרחקים של 10 ס"מ, מטר אחד, 3 מטרים ו-5 מטרים, כפי שנצפה באמצעות WifiRttManager#startRanging Android API.
‫[7.4.2.5/H-SR-1] מומלץ מאוד לדווח על הטווח בצורה מדויקת בטווח של ‎+/-1 מטר ברוחב פס של ‎160 MHz באחוזון ה-90 (כפי שמחושב באמצעות פונקציית ההתפלגות המצטברת), ‎+/-2 מטרים ברוחב פס של ‎80 MHz באחוזון ה-90, ‎+/-4 מטרים ברוחב פס של ‎40 MHz באחוזון ה-90 ו-‎+/-8 מטרים ברוחב פס של ‎20 MHz באחוזון ה-90 במרחקים של 10 ס"מ, כפי שנצפה באמצעות WifiRttManager#startRanging Android API.

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

אם הטמעות של מכשירים שניתן להחזיק ביד תומכות בפרוטוקול זיהוי הקרבה (PD) של Wi-Fi – כפי שמצוין בהצהרה PackageManager.FEATURE_WIFI_RTT ובערך החזרה שאינו null מהפונקציה WifiRttManager#getProximityDetectionCharacteristics() – אז:

‫[7.4.2.6/H-1-1] אם מכשירים מפרסמים תמיכה ב-160 MHz, הם חייבים להשתמש ברוחב פס של 160 MHz למדידות טווח.
‫[7.4.2.6/H-1-2] כשמשתמשים בתקן IEEE 802.11az, המכשירים חייבים לדווח על הטווח בצורה מדויקת באחוזון ה-68 (מחושב באמצעות פונקציית ההתפלגות המצטברת) במרחקים של 10 ס"מ, מטר אחד, 3 מטרים ו-5 מטרים, כפי שנצפה באמצעות WifiRttManager#startContinuousRanging Android API:
- ‫‎+/-0.5 m ברוחב פס של 160 MHz
- ‫‎+/-1 m ברוחב פס של 80 MHz
- ‫+/-2 מ' ברוחב פס של 40 מגה-הרץ
- ‫‎+/-4 m ברוחב פס של 20 MHz
‫[7.4.2.6/H-1-3] כשמשתמשים בתקן IEEE 802.11mc, המכשירים חייבים לדווח על הטווח בצורה מדויקת באחוזון ה-68 (מחושב באמצעות פונקציית ההתפלגות המצטברת) במרחקים של 10 ס"מ, מטר אחד, 3 מטרים ו-5 מטרים, כפי שנצפה באמצעות WifiRttManager#startContinuousRanging Android API:
- ‫‎+/-2 m ברוחב פס של 80 MHz
- ‫‎+/-4 m ברוחב פס של 40 MHz
- ‫‎+/-8 m ברוחב פס של 20 MHz
‫[7.4.2.6/H-SR-1] כשמשתמשים בתקן IEEE 802.11az, מומלץ מאוד שמכשירים ידווחו על הטווח בצורה מדויקת באחוזון ה-90 (מחושב באמצעות פונקציית ההתפלגות המצטברת) במרחק של 10 ס"מ, כפי שנצפה באמצעות WifiRttManager#startContinuousRanging Android API:
- ‫‎+/-0.5 m ברוחב פס של 160 MHz
- ‫‎+/-1 m ברוחב פס של 80 MHz
- ‫+/-2 מ' ברוחב פס של 40 מגה-הרץ
- ‫‎+/-4 m ברוחב פס של 20 MHz
‫[7.4.2.6/H-SR-2] כשמשתמשים בתקן IEEE 802.11mc, מומלץ מאוד שמכשירים ידווחו על הטווח בצורה מדויקת באחוזון ה-90 (מחושב באמצעות פונקציית ההתפלגות המצטברת) במרחק של 10 ס"מ, כפי שנצפה באמצעות WifiRttManager#startContinuousRanging Android API:
- ‫‎+/-2 m ברוחב פס של 80 MHz
- ‫‎+/-4 m ברוחב פס של 40 MHz
- ‫‎+/-8 m ברוחב פס של 20 MHz

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

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

אם מכשירים ניידים תומכים בפרוטוקול זיהוי קירבה (PD) של Wi-Fi על ידי הצהרה על PackageManager.FEATURE_WIFI_PD ובמיקום Wi-Fi (זמן הלוך ושוב של Wi-Fi‏ – RTT) על ידי הצהרה על PackageManager.FEATURE_WIFI_RTT, אז הם:

‫[7.4.2.10/H-1-1] חובה להשתמש ברוחב פס של 160‎ MHz לפחות.
‫[7.4.2.10/H-1-2] חובה לדווח על הטווח בצורה מדויקת בטווח של ‎+/-0.25 מטרים ברוחב פס של 160 MHz באחוזון ה-68 (כפי שמחושב באמצעות פונקציית ההתפלגות המצטברת), כפי שנצפה באמצעות WifiRttManager#startRanging Android API.

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

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

‫[7.4.3/H-1-3] חובה למדוד את ה-Rx offset ולבצע פיצוי כדי לוודא שערך ה-RSSI החציוני של BLE הוא ‎-50 dBm +/-15 dB במרחק של מטר אחד ממכשיר ייחוס שמשדר ב-ADVERTISE_TX_POWER_HIGH.
‫[7.4.3/H-1-4] חובה למדוד את ה-Tx offset ולבצע פיצוי כדי לוודא שערך ה-RSSI החציוני של BLE הוא ‎-50 dBm +/-15 dB כשסורקים ממכשיר ייחוס שממוקם במרחק של מטר אחד ומשדר ב-ADVERTISE_TX_POWER_HIGH.

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

‫[7.5.1/H-1-1] הרזולוציה צריכה להיות לפחות 2 מגה-פיקסל.

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

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

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

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

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

‫[7.6.1/H-1-1] הזיכרון שזמין לליבת המערכת ולמרחב המשתמש חייב להיות לפחות 416 MB אם התצוגה שמוגדרת כברירת מחדל משתמשת ברזולוציות של מאגר מסגרות עד qHD (למשל, FWVGA).
‫[7.6.1/H-2-1] הזיכרון שזמין לליבת המערכת ולמרחב המשתמש חייב להיות לפחות 592 MB אם התצוגה שמוגדרת כברירת מחדל משתמשת ברזולוציות של מאגר מסגרות עד HD+‎ (למשל HD,‏ WSVGA).
‫[7.6.1/H-3-1] הזיכרון שזמין לליבת מערכת ההפעלה ולמרחב המשתמש חייב להיות לפחות 896 MB אם התצוגה שמוגדרת כברירת מחדל משתמשת ברזולוציות של מאגר מסגרות עד FHD (לדוגמה, WSXGA+).
‫[7.6.1/H-4-1] הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 1,344 MB אם התצוגה שמוגדרת כברירת מחדל משתמשת ברזולוציות של מאגר מסגרות עד QHD (לדוגמה, QWXGA).

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

‫[7.6.1/H-5-1] הזיכרון שזמין לליבת המערכת ולמרחב המשתמש חייב להיות לפחות 816 MB אם התצוגה שמוגדרת כברירת מחדל משתמשת ברזולוציות של framebuffer עד qHD (לדוגמה, FWVGA).
‫[7.6.1/H-6-1] הזיכרון שזמין לליבת המערכת ולמרחב המשתמש חייב להיות לפחות 944 MB אם התצוגה שמוגדרת כברירת מחדל משתמשת ברזולוציות של מאגר מסגרות עד HD+‎ (לדוגמה, HD, ‏ WSVGA).
‫[7.6.1/H-7-1] הזיכרון שזמין לליבת המערכת ולמרחב המשתמש חייב להיות לפחות 1,280 MB אם התצוגה שמוגדרת כברירת מחדל משתמשת ברזולוציות של מאגר מסגרות עד FHD (לדוגמה, WSXGA+).
‫[7.6.1/H-8-1] הזיכרון שזמין לליבת המערכת ולמרחב המשתמש חייב להיות לפחות 1,824 MB אם התצוגה שמוגדרת כברירת מחדל משתמשת ברזולוציות של מאגר מסגרות עד QHD (למשל, QWXGA).

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

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

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

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

‫[7.6.1/H-10-1] חובה להקצות לפחות 4 GB של אחסון לא נדיף לנתונים פרטיים של האפליקציה (כלומר, מחיצת ‎/data).
צריך להצהיר על ה-feature flag‏ android.hardware.ram.normal.

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

‫[7.6.1/H-SR-1] מומלץ מאוד לתמוך רק במרחב משתמשים של 32 ביט (גם אפליקציות וגם קוד מערכת)

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

‫[7.6.1/H-1-1] חובה לתמוך רק בממשק ABI אחד (64 ביט בלבד או 32 ביט בלבד).

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

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

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

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

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

‫[7.7.2/H-1-1] חובה להטמיע את USB audio class כפי שמתואר במסמכי 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] חובה להצהיר על feature flag.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 usage page: 0x0C HID usage: 0x0CD Kernel key: `KEY_PLAYPAUSE` Android key: `KEYCODE_MEDIA_PLAY_PAUSE`	הפעלת מדיה	קלט: לחיצה קצרה פלט: הפעלה או השהיה
		הפעלת מדיה	קלט: לחיצה ארוכה פלט: הפעלת פקודה קולית שליחה: `android.speech.action.VOICE_SEARCH_HANDS_FREE` אם המכשיר נעול או שהמסך שלו כבוי. שליחה `android.speech.RecognizerIntent.ACTION_WEB_SEARCH` אחרת
		שיחה נכנסת	קלט: לחיצה קצרה פלט: מענה לשיחה
		שיחה נכנסת	קלט: לחיצה ארוכה על פלט: דחיית שיחה
		שיחה פעילה	קלט: לחיצה קצרה פלט: סיום השיחה
		שיחה פעילה	קלט: לחיצה ארוכה על פלט: השתקה או ביטול השתקה של המיקרופון
B	‫HID usage page: 0x0C HID usage: 0x0E9 Kernel key: `KEY_VOLUMEUP` Android key: `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] MUST trigger ACTION_HEADSET_PLUG upon a plug insert, but only after the USB audio interfaces and endpoints have been properly enumerated in order to identify the type of terminal connected.

כשמזוהים סוגים של מסופי אודיו ב-USB‏ 0x0302, הם:

‫[7.8.2.2/H-2-1] חובה לשדר Intent‏ ACTION_HEADSET_PLUG עם התוסף microphone שהוגדר לערך 0.

כשמזוהים סוגים של נקודות חיבור לאודיו ב-USB‏ 0x0402, המערכת:

‫[7.8.2.2/H-3-1] חובה לשדר Intent ACTION_HEADSET_PLUG עם התוסף microphone שהוגדר לערך 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-1] מומלץ מאוד לבצע ספירה של מתארי USB, לזהות סוגי מסופים ולשדר Intent ACTION_HEADSET_PLUG תוך פחות מ-1,000 מילישניות, כשמחברים ציוד היקפי לאודיו עם USB-C.

לגבי יישומים של מכשירים שניתן להחזיק ביד שמוצהרים בהם android.hardware.audio.output ו-android.hardware.microphone, אפשר לעיין בדרישות RTL ו-TTL בסעיף 5.6.

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

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

‫[7.10/H] מומלץ למקם את המפעיל קרוב למיקום שבו בדרך כלל מחזיקים את המכשיר או נוגעים בו בידיים.
‫[7.10/H] צריך להזיז את המפעיל ההפטי בציר X (שמאל-ימין) של הכיוון הטבעי של המכשיר.

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

‫[7.10/H] תדר התהודה של ה-LRA בציר X צריך להיות מתחת ל-200 הרץ.

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

‫[7.10/H]^* צריך לאמת את סטטוס ההטמעה באמצעות הפעלת ממשקי ה-API‏ android.os.Vibrator.areAllEffectsSupported() ו-android.os.Vibrator.arePrimitivesSupported().
‫[7.10/H]^* SHOULD perform a quality assessment for haptic constants.
‫[7.10/H]^* צריך לאמת ולעדכן, אם צריך, את הגדרת ברירת המחדל עבור פרימיטיבים שלא נתמכים, כפי שמתואר בהנחיות ההטמעה עבור קבועים.

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‏ (AAC LC)
‫[5.1/H-0-4] פרופיל MPEG-4 HE AAC ‏ (AAC+)
‫[5.1/H-0-5] AAC ELD (enhanced low delay AAC)

‫[5.1/H-0-6] MPEG-D USAC עם MPEG-D DRC (Extended High Efficiency AAC)

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

‫[5.2/H-0-1] H.264 AVC
‫[5.2/H-0-2] VP8
‫[5.2/H-0-3] AV1

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

‫[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
‫[5.3/H-0-6] AV1

2.2.3. תוכנה

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

‫[3.2.3.1/H-0-1] חובה להשתמש באפליקציה שמטפלת ב-intents‏ ACTION_GET_CONTENT,‏ ACTION_OPEN_DOCUMENT,‏ ACTION_OPEN_DOCUMENT_TREE ו-ACTION_CREATE_DOCUMENT כפי שמתואר במסמכי ה-SDK, ולספק למשתמש גישה לנתונים של ספק המסמכים באמצעות DocumentsProvider API.

‫[3.2.3.1/H-0-2] חובה לטעון מראש רכיב אחד או יותר של אפליקציה או שירות עם handler של Intent, לכל דפוסי מסנן ה-Intent הציבורי שמוגדרים על ידי ה-Intent של האפליקציה שמפורטים כאן.

הערה: הדף 'Common App Intents' (פעולות נפוצות באפליקציה) יכלול את ה-Intent החדש והנדרש android.settings.VPN_APP_EXCLUSION_SETTINGS.

‫[3.2.3.1/H-SR-1] מומלץ מאוד לטעון מראש אפליקציית אימייל שיכולה לטפל ב-Intent של ACTION_SENDTO או ACTION_SEND או ACTION_SEND_MULTIPLE כדי לשלוח אימייל.

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

‫[3.4.2/H-0-1] חובה לכלול אפליקציית דפדפן עצמאית לשימוש כללי של משתמשים לגלישה באינטרנט.

‫[3.8.1/H-0-1] חובה להטמיע מרכז אפליקציות שמוגדר כברירת מחדל ותומך בהצמדת ווידג'טים בתוך האפליקציה.

‫[3.8.1/H-SR-1] מומלץ מאוד להטמיע משגר ברירת מחדל שתומך בהצמדת קיצורי דרך, ווידג'טים ו-widgetFeatures בתוך האפליקציה.
‫[3.8.1/H-SR-2] מומלץ מאוד להטמיע משגר ברירת מחדל שמספק גישה מהירה לקיצורי הדרך הנוספים שמסופקים על ידי אפליקציות צד שלישי באמצעות ShortcutManager API.
‫[3.8.1/H-SR-3] מומלץ מאוד לכלול אפליקציית מרכז אפליקציות שמוצגים בה תגים לסמלי האפליקציות.

‫[3.8.2/H-SR-1] מומלץ מאוד לתמוך בווידג'טים של אפליקציות צד שלישי.

‫[3.8.2/H-0-1] המכשיר חייב לתמוך בווידג'טים של אפליקציות צד שלישי.

‫[3.8.3/H-0-1] חובה לאפשר לאפליקציות צד שלישי להודיע למשתמשים על אירועים חשובים באמצעות המחלקות Notification ו-NotificationManager של ה-API.
‫[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-1] מומלץ מאוד להציג את האפשרות הראשונה שמופיעה דרך RemoteInput.Builder setChoices() במרכז ההתראות בלי שהמשתמש יצטרך לבצע אינטראקציה נוספת.
‫[3.8.3/H-SR-2] מומלץ מאוד להציג את כל האפשרויות שמופיעות ב-RemoteInput.Builder setChoices() במרכז ההתראות, כשמשתמש מרחיב את כל ההתראות במרכז ההתראות.
‫[3.8.3.1/H-SR-1] מומלץ מאוד להציג פעולות שבהן Notification.Action.Builder.setContextual מוגדר כtrue בשורה עם התשובות שמוצגות על ידי Notification.Remoteinput.Builder.setChoices.
‫[3.8.4/H-SR-1] מומלץ מאוד להטמיע עוזר דיגיטלי במכשיר כדי לטפל בפעולת העזרה.

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

‫[3.8.3.1/H-SR-2] מומלץ מאוד לספק למשתמשים אמצעי גישה (לדוגמה, מתג פלט) שאפשר לגשת אליו מממשק המשתמש של המערכת, כדי לאפשר להם לעבור בין נתיבי מדיה מתאימים שזמינים (לדוגמה, מכשירי Bluetooth ונתיבים שסופקו ל-MediaRouter2Manager) כשבאפליקציה מתפרסמת התראה מסוג MediaStyle עם טוקן MediaSession.

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

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

‫[3.8.3.1/H-0-1] חובה להציג התראה על עדכון חי מקודם במקום בולט במסך הנעילה.
‫[3.8.3.1/H-0-12] ההתראה חייבת להופיע בראש רשימת ההתראות התראה קופצת ומעליה התראות צבעוניות (כאשר setColorized הוא true) כאשר ההתראה המקודמת על עדכון בשידור חי מוצגת בין התראות אחרות.
- יכול להיות שהמערכת תקבע את סדר ההצגה של התראות על עדכונים בזמן אמת של אפליקציות מקודמות במרכז ההתראות ובמסך הנעילה, אם יותר מאפליקציה אחת עומדת בדרישות להצגת התראות על עדכונים בזמן אמת.
‫[3.8.3.1/H-0-2] חובה להציג התראה על עדכון חי מקודם במצב המורחב.
[3.8.3.1/H-0-3] MUST NOT provide a user-affordance to collapse the expanded notification above.
‫[3.8.3.1/H-0-4] חובה להציג את הסגנונות הבסיסיים (מודגש, נטוי וקו תחתון) של תוכן טקסט בהתראה מקודמת על עדכון בזמן אמת, כפי שסופק על ידי StyleSpan או UnderlineSpan.
‫[3.8.3.1/H-0-5] MUST display only standard action objects (via Notification.Action), and MUST hide non-standard action objects such as input boxes, reply buttons, and contextual actions (via addRemoteInput() and setContextual()) in a Promoted Live Update Notification, even when the notification contains them.
‫[3.8.3.1/H-0-6] חובה להציג ייצוג קומפקטי, שנקרא גם Status Chip במסמכי ה-SDK, עבור הודעה מקודמת על עדכון בשידור חי שחובה לכלול Notification.getSmallIcon().
- ‫[3.8.3.1/H-0-7] שדות אחרים הם אופציונליים בייצוג הקומפקטי, אבל בכל מקרה שבו אפשר להרחיב את הייצוג הקומפקטי, צריך להציג את ‫Notification.getShortCriticalText() אם הוא קיים, או את Notification.when אם Notification.getShortCriticalText לא קיים.
- ‫[3.8.3.1/H-0-8] אם יש יותר מהתראה אחת על עדכון בזמן אמת שקודם, חובה להציג לפחות אחת מהן בשורת הסטטוס כייצוג קומפקטי.
- ‫[3.8.3.1/H-0-9] חובה להציג את ההתראה המשויכת (מומלץ) או לפתוח את האפליקציה המשויכת (באמצעות Notification.contentIntent), כשהמשתמש מקיש על הייצוג הקומפקטי.
- ‫[3.8.3.1/H-0-13] חובה להציג את אותו התוכן בהתראה המשויכת כמו בהתראה שזמינה במרכז ההתראות.
‫[3.8.3.1/H-0-10] חובה לספק למשתמשים אפשרות להשבית ולהפעיל את ההצגה המקודמת של התראות מאפליקציות ספציפיות.
‫[3.8.3.1/H-0-11] חובה להציג בצורה נכונה את כל ההתראות על עדכונים בשידור חי, כולל, בין היתר, התראות על עדכונים בשידור חי שלא מקודמות או שמקודמות רק באופן חלקי בהתאם למאפייני הקידום. התראות כאלה שלא מקודמות חייבות להיות מוצגות במצב לא מקודם.

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

‫[3.8.3/H-1-1] חובה להטמיע את ההתנהגות של הקפאת המסך ולספק למשתמש תפריט הגדרות להפעלה או להשבתה של התכונה.

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

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

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

‫[3.8.4/H-1-1]^* חובה להציג התראות על שיחות לפני התראות שלא קשורות לשיחות, למעט התראות על שירותים שפועלים בחזית והתראות עם חשיבות:גבוהה.

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

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

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

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

אם הטמעות של מכשירים שניתן להחזיק ביד כוללות תמיכה בממשקי ה-API‏ ControlsProviderService ו-Control ומאפשרות לאפליקציות של צד שלישי לפרסם ממשק השליטה במכשירים, הן:

‫[3.8.16/H-1-1] חובה להצהיר על דגל התכונה android.software.controls ולהגדיר אותו כ-true.
‫[3.8.16/H-1-2] חובה לספק למשתמש אמצעי נוח לשימוש שמאפשר לו להוסיף, לערוך, לבחור ולהפעיל את אמצעי הבקרה המועדפים שלו במכשיר מתוך אמצעי הבקרה שנרשמו על ידי אפליקציות צד שלישי באמצעות ממשקי ה-API‏ ControlsProviderService ו-Control.
[3.8.16/H-1-3] חובה לספק גישה למזמינות המשתמש הזו תוך שלוש אינטראקציות ממרכז האפליקציות שמוגדר כברירת מחדל.
[3.8.16/H-1-4] חובה להציג בצורה מדויקת במזמינוּת המשתמש הזו את השם והסמל של כל אפליקציית צד שלישי שמספקת אמצעי בקרה באמצעות ControlsProviderService API, וגם את כל השדות שצוינו ומסופקים על ידי ממשקי Control API.
‫[3.8.16/H-1-5] חובה לספק למשתמש אפשרות ביטול של אמצעי בקרה במכשיר שאינם דורשים אימות, מתוך אמצעי הבקרה שנרשמו על ידי אפליקציות של צד שלישי באמצעות ControlsProviderService ו-Control API.Control.isAuthRequired
‫[3.8.16/H-1-6] הטמעות של מכשירים חייבות להציג את אמצעי ההנגשה למשתמש בצורה מדויקת, באופן הבא:
- אם המכשיר הגדיר את config_supportsMultiWindow=true והאפליקציה מצהירה על המטא-נתונים META_DATA_PANEL_ACTIVITY בהצהרה ControlsProviderService, כולל ComponentName של פעילות תקפה (כפי שהוגדרה על ידי ה-API), האפליקציה חייבת להטמיע את הפעילות הזו במזמינוּת המשתמש הזו.
- אם האפליקציה לא מצהירה על מטא-נתונים META_DATA_PANEL_ACTIVITY, היא חייבת להציג את השדות שצוינו כפי שהם מסופקים על ידי ControlsProviderService API, וגם את השדות שצוינו על ידי ממשקי Control API.
‫[3.8.16/H-1-7] אם האפליקציה מציינת את המטא-נתונים [META_DATA_PANEL_ACTIVITY, היא חייבת לעבור את ההגדרה שמוגדרת ב- [3.8.16/H-1-5] באמצעות [EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS כשמפעילים את הפעילות המוטמעת.

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

‫[3.8.16/H-2-1] חובה לדווח על null עבור ממשקי ה-API‏ ControlsProviderService ו-Control.
‫[3.8.16/H-2-2] חובה להצהיר על דגל התכונה android.software.controls ולהגדיר אותו לערך false.

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

‫[3.8.17/H-1-1] חובה להציג למשתמש אישור שהנתונים הועתקו ללוח (למשל, תמונה ממוזערת או התראה עם הכיתוב 'התוכן הועתק'). בנוסף, צריך לציין כאן אם הנתונים בלוח העריכה יסונכרנו בין המכשירים.

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

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

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

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

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

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

‫[3.20.1/H-0-1] חובה להטמיע את כל הדרישות של זרם האודיו של Assistant.

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

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

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

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

‫[3.9/H-1-2] חובה להצהיר על תמיכה בפרופילים מנוהלים באמצעות android.software.managed_users דגל התכונה.

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

‫[7.5.4/H-1-1] חובה לכבד את הכוונות של התגים android.media.action.STILL_IMAGE_CAMERA ו-android.media.action.STILL_IMAGE_CAMERA_SECURE ולהפעיל את המצלמה במצב של תמונות סטילס, כפי שמתואר ב-SDK.
‫[7.5.4/H-1-2] חובה לכבד את הכוונה להפעיל את המצלמה במצב וידאו כפי שמתואר ב-SDK.android.media.action.VIDEO_CAMERA

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

‫[3.2.3.1/ H-1-1] חובה שתהיה אפליקציה עם פעילות שמטפלת ב-intent‏ Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY כשהפונקציונליות של המסך המפוצל מופעלת. הפעילות חייבת להיות מוגנת על ידי android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK, והיא חייבת להתחיל את הפעילות של Intent שנותח מתוך Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.

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

‫[7.4.1.2/H-0-1] חובה להצהיר על ה-feature flag‏ android.software.telecom.

‫[7.4.1.2/H-0-2] חובה להטמיע את מסגרת הטלקום.

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

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

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

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

אם הטמעות של מכשירים שניתן להחזיק ביד כוללות תכונות לשיפור ניהול צריכת החשמל של המכשיר, שנכללות ב-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] חובה לדווח על צריכת הספק של ה-CPU לכל UID של תהליך. פרויקט הקוד הפתוח של Android עומד בדרישה באמצעות הטמעה של מודול ליבת uid_cputime.
‫[8.4/H-0-4] חובה להציג את נתוני צריכת החשמל האלה למפתח האפליקציה באמצעות פקודת ה-Shell‏ adb shell dumpsys batterystats.
‫[8.4/H] צריך לשייך את השימוש בחשמל לרכיב החומרה עצמו אם אי אפשר לשייך אותו לאפליקציה.

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

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

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

‫[8.5/H-0-1] חובה לספק למשתמשים מזמינוּת לראות את כל האפליקציות עם שירותים שפועלים בחזית או עם משימות שהמשתמש יזם, כולל משך הפעולה של כל אחד מהשירותים האלה מאז שהתחיל, כפי שמתואר במסמך ה-SDK.
‫[8.5/H-0-2]חובה לספק למשתמש אמצעי להפסקת אפליקציה שמריצה שירות שפועל בחזית או עבודה שהמשתמש הפעיל.

2.2.5. מודל אבטחה

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

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

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

‫[9.1/H-0-2] אסור להעניק את ACCESS_FINE_LOCATION כברירת מחדל לאפליקציה הזו.

הטמעות של מכשירים חייבות להצהיר על תמיכה ב-android.software.credentials וב:

‫[9/H-0-2] חובה לכבד את android.settings.CREDENTIAL_PROVIDER הכוונה לאפשר בחירה של ספק מועדף למנהל האישורים. הספק הזה יופעל לצורך מילוי אוטומטי, והוא גם יהיה מיקום ברירת המחדל לשמירת פרטי כניסה חדשים שיוזנו דרך Credential Manager.
‫[9/H-0-3] המכשיר חייב לתמוך בלפחות 2 ספקי אישורים בו-זמנית, ולספק למשתמש אפשרות באפליקציית ההגדרות להפעלה או להשבתה של ספקים.
‫[9.5/H-1-1] הדרישה הוסרה ב-Android 16.

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

‫[9.11/H-0-2] חובה לגבות את ההטמעה של מאגר המפתחות באמצעות סביבת ביצוע מבודדת.
‫[9.11/H-0-3] חובה להטמיע אלגוריתמים קריפטוגרפיים מסוג RSA, ‏ AES,‏ ECDSA ו-HMAC, ופונקציות גיבוב מסוג MD5, ‏ SHA-1 ו-SHA-2, כדי לתמוך בצורה תקינה באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בקרנל ומעליו. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד במצב ליבה או במרחב משתמשים יכול לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. פרויקט הקוד הפתוח של Android‏ (AOSP) עומד בדרישה הזו באמצעות ההטמעה של Trusty, אבל יש גם אפשרויות חלופיות: פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת שנבדקה על ידי צד שלישי של בידוד מתאים שמבוסס על היפר-ויז'ור.
‫[9.11/H-0-4] חובה לבצע את האימות במסך הנעילה בסביבת ביצוע מבודדת, ורק אם האימות מצליח, לאפשר את השימוש במפתחות שקשורים לאימות. פרטי הכניסה במסך הנעילה צריכים להיות מאוחסנים באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות במסך הנעילה. פרויקט הקוד הפתוח של Android מספק את שכבת ההפשטה של החומרה (HAL) של Gatekeeper ואת Trusty, שאפשר להשתמש בהם כדי לעמוד בדרישה הזו.
‫[9.11/H-0-5] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה של האימות מוגן על ידי חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. אסור להשתמש במפתחות החתימה של האימות כמזהי מכשיר קבועים.

הערה: כדי לעמוד בדרישה הזו, אתם צריכים לשתף את אותו מפתח אישור עבור מק"ט מסוים, אלא אם יוצרו לפחות 100,000 יחידות של אותו מק"ט. אם מיוצרות יותר מ-100,000 יחידות של אותו מק"ט, אפשר להשתמש במפתח אחר לכל קבוצה של 100,000 יחידות לאחר מכן. לחלופין, אפשר להשתמש בפתרון Remote Key Provisioning (הקצאת מפתחות מרחוק) כדי להקצות למכשיר מפתחות אימות לזמן קצר.

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

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

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

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

‫[9.11.1/H-1-1] חובה להציג למשתמש אתגר לאימות באמצעות אחת משיטות האימות הראשיות המומלצות (כמו קוד אימות, קו ביטול נעילה או סיסמה) בתדירות גבוהה יותר מפעם אחת בכל 72 שעות.

אם הטמעות של מכשירים שניתן להחזיק ביד כוללות מסך נעילה מאובטח וסביבת אמון אחת או יותר שקוראות ל-TrustAgentService.grantTrust() System API עם הדגל FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, הן:

‫[9.11.1/H-1-1] חובה להתקשר אל TrustManagerService.revokeTrust() אחרי אחד מהמקרים הבאים:
- עד 24 שעות ממועד מתן ההרשאה.
- חלון של 8 שעות של חוסר פעילות.

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

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

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

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

הגדרות מוגבלות

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

האפליקציה מותקנת אחרי שהיא הורדה דרך אפליקציה (לדוגמה, אפליקציית הודעות או דפדפן) שאינה אפליקציית 'חנות אפליקציות' שמזוהה על ידי PackageManager כPACKAGE_DOWNLOADED_FILE.
האפליקציה מותקנת מקובץ מקומי (לדוגמה, האפליקציה הועברה למכשיר בשיטת Sideloading) ומזוהה על ידי PackageManager כ-PACKAGE_SOURCE_LOCAL_FILE.

לגבי כל אחת מההרשאות שנאכפות והמזהים המשויכים שלהן שמפורטים בקטע [9.8/H-0-5] בהמשך.

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

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

‫[9.8/H-0-1] חובה להטמיע הגדרות מוגבלות כמו שמתואר למעלה עבור:
- הרשאות מיוחדות
  - נגישות (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
  - מאזין להתראות (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
  - אפליקציות לניהול מכשירים (Manifest.permission.BIND_DEVICE_ADMIN)
  - הצגה מעל אפליקציות אחרות (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
  - גישה לנתוני שימוש (AppOpsManager.OPSTR_GET_USAGE_STATS)
- תפקידים (אפליקציות ברירת מחדל)
  - ‫Dialer (RoleManager.ROLE_DIALER)
  - SMS (RoleManager.ROLE_SMS)
- הרשאות בזמן ריצה
  - זמן הריצה של ה-SMS (Manifest.permission_group.SMS)
‫[9.8/H-0-2] חובה להפעיל את ההגדרה 'הגדרות מוגבלות' כברירת מחדל, ומומלץ מאוד שלא לאפשר למשתמשים להשבית את ההגדרה 'הגדרות מוגבלות' לכל האפליקציות.
‫[9.8/H-0-3] חובה לוודא שמתקבל אישור מהמשתמש לכל אפליקציה שחלה עליה המדיניות לפני שניתן להעניק הרשאות כלשהן שמופעלות.
‫[9.8/H-0-4] חובה לאפשר רק אישור משתמש כדי להפעיל הגדרות מוגבלות שניתן להשיג מדף פרטי האפליקציה של האפליקציה הרלוונטית, באמצעות API של EnhancedConfirmationManager.
‫[9.8/H-0-5] מומלץ מאוד לשלב את EnhancedConfirmationManager ולקרוא לו עבור כל ההרשאות המיוחדות, כדי לקבוע באופן דינמי אם מדובר בהגדרה מוגבלת.
- שעונים מעוררים ותזכורות: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
- גישה לכל הקבצים: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
- הצגה מעל אפליקציות אחרות: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
- התקנת אפליקציות ממקורות לא מוכרים: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
- ניהול מדיה: AppOpsManager.OPSTR_MANAGE_MEDIA
- שינוי הגדרות המערכת: AppOpsManager.OPSTR_WRITE_SETTINGS
- תמונה בתוך תמונה: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
- הפעלת המסך: AppOpsManager.OPSTR_TURN_SCREEN_ON
- התראות במסך מלא: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
- שליטה ב-Wi-Fi: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
- נגישות: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
- מאזין להתראות: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
- גישה לנתוני השימוש: AppOpsManager.OPSTR_GET_USAGE_STATS
- אדמין של המכשיר: Manifest.permission.BIND_DEVICE_ADMIN
- נא לא להפריע: Manifest.permission.MANAGE_NOTIFICATIONS

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

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

‫[9.8/H-1-1] חובה לוודא ששירות זיהוי מילות ההפעלה יכול להעביר נתונים רק למערכת, ContentCaptureService, או לשירות זיהוי דיבור במכשיר שנוצר על ידי SpeechRecognizer#createOnDeviceSpeechRecognizer().
‫[9.8/H-1-2] חובה לוודא ששירות זיהוי מילות ההפעלה יכול להעביר נתוני אודיו מהמיקרופון או נתונים שנגזרים מהם לשרת המערכת רק דרך HotwordDetectionService API, או ל-ContentCaptureService רק דרך ContentCaptureManager API.
‫[9.8/H-1-3] אסור לספק אודיו מהמיקרופון שאורכו יותר מ-30 שניות עבור בקשה בודדת להפעלת שירות זיהוי מילת ההפעלה באמצעות חומרה.
‫[9.8/H-1-4] אסור לספק אודיו ממיקרופון עם נתונים זמניים שגילם מעל 8 שניות עבור בקשה בודדת לשירות זיהוי מילת הפעלה.
‫[9.8/H-1-5] אסור לספק שמע ממיקרופון עם מאגר נתונים זמני (באפר) שגילו יותר מ-30 שניות לשירות אינטראקציה קולית או לישות דומה.
‫[9.8/H-1-6] אסור לאפשר העברה של יותר מ-100 בייטים של נתונים (לא כולל זרמי אודיו) משירות זיהוי מילת ההפעלה בכל תוצאה מוצלחת של מילת הפעלה.
‫[9.8/H-1-7] אסור לאפשר העברה של יותר מ-5 ביטים של נתונים משירות זיהוי מילת ההפעלה בכל תוצאה שלילית של מילת הפעלה.
‫[9.8/H-1-8] חובה לאפשר העברת נתונים משירות זיהוי מילת ההפעלה רק בבקשה לאימות מילת ההפעלה משרת המערכת.
‫[9.8/H-1-9] אסור לאפשר לאפליקציה שניתנת להתקנה על ידי משתמש לספק את שירות זיהוי מילת ההפעלה.
‫[9.8/H-1-10] אסור להציג בממשק המשתמש נתונים כמותיים על השימוש במיקרופון על ידי שירות זיהוי מילות ההפעלה.
‫[9.8/H-1-11] חובה לתעד את מספר הבייטים שנכללים בכל שידור משירות זיהוי מילת ההפעלה, כדי לאפשר לחוקרי אבטחה לבדוק את הנתונים.
‫[9.8/H-1-12] חובה לתמוך במצב ניפוי באגים שמתעד את התוכן הגולמי של כל שידור משירות זיהוי מילת ההפעלה, כדי לאפשר לחוקרי אבטחה לבדוק את התוכן.
‫[9.8/H-1-14] חובה להציג את אינדיקטור המיקרופון, כפי שמתואר בקטע 9.8.2, כשתוצאה מוצלחת של מילת הפעלה מועברת לשירות האינטראקציה הקולית או לישות דומה.
‫[9.8/H-1-15] חובה לוודא שזרמי האודיו שמועברים בתוצאות מוצלחות של זיהוי מילת הפעלה מועברים באופן חד-כיווני משירות זיהוי מילת ההפעלה לשירות האינטראקציה הקולית.
‫[9.8/H-SR-1] מומלץ מאוד להודיע למשתמשים לפני שמגדירים אפליקציה כספק של שירות זיהוי מילת ההפעלה.
‫[9.8/H-SR-2] מומלץ מאוד לא לאפשר את ההעברה של נתונים לא מובנים משירות זיהוי מילות ההפעלה.
‫[9.8/H-SR-3] מומלץ מאוד להפעיל מחדש את התהליך שמארח את שירות זיהוי מילות ההפעלה לפחות פעם בשעה או כל 30 אירועים של הפעלת חומרה, לפי המוקדם מביניהם.

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

‫[9.8/H-2-1] חובה לספק למשתמש הודעה מפורשת לגבי כל צירוף מילים להפעלה קולית שנתמך.
‫[9.8/H-2-2] אסור לשמור נתוני אודיו גולמיים או נתונים שמקורם בהם באמצעות שירות זיהוי מילת ההפעלה.
‫[9.8/H-2-3] אסור לשדר משירות זיהוי מילות ההפעלה נתוני אודיו, נתונים שאפשר להשתמש בהם כדי לשחזר (באופן מלא או חלקי) את האודיו או תוכן אודיו שלא קשור למילת ההפעלה עצמה, אלא רק אל ContentCaptureService או אל שירות זיהוי הדיבור במכשיר.

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

‫[9.8/H-3-1] חובה לוודא ששירות זיהוי השאילתות יכול להעביר נתונים רק למערכת, או ל-ContentCaptureService, או לשירות זיהוי דיבור במכשיר (שנוצר על ידי SpeechRecognizer#createOnDeviceSpeechRecognizer()).
‫[9.8/H-3-2] אסור לאפשר העברה של נתוני אודיו או וידאו מחוץ ל-VisualQueryDetectionService, אלא ל-ContentCaptureService או לשירות זיהוי דיבור במכשיר.
‫[9.8/H-3-3] חובה להציג הודעה למשתמש בממשק המשתמש של המערכת כשהמכשיר מזהה כוונה של המשתמש להשתמש באפליקציה של העוזר הדיגיטלי (לדוגמה, על ידי זיהוי נוכחות המשתמש באמצעות המצלמה).
‫[9.8/H-3-4] חובה להציג אינדיקטור למיקרופון ולהציג את שאילתת המשתמש שזוהתה בממשק המשתמש מיד אחרי ששאילתת המשתמש זוהתה.
‫[9.8/H-3-5] אסור לאפשר לאפליקציה שניתנת להתקנה על ידי משתמש לספק את שירות הזיהוי של שאילתות חזותיות.

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

‫[9.8.2/H-4-1] חובה להציג את אינדיקטור המיקרופון כשלאפליקציה יש גישה לנתוני אודיו מהמיקרופון, אבל לא כשגישה למיקרופון ניתנת רק ל-HotwordDetectionService, ל-SOURCE_HOTWORD, ל-ContentCaptureService או לאפליקציות שממלאות את התפקידים שמפורטים בקטע 9.1 עם מזהה CDD‏ [C-4-X].
‫[9.8.2/H-4-2] חובה להציג את רשימת האפליקציות האחרונות והפעילות שמשתמשות במיקרופון, כפי שמוחזרות מ-PermissionManager.getIndicatorAppOpUsageData(), יחד עם הודעות השיוך שקשורות אליהן.
‫[9.8.2/H-4-3] אסור להסתיר את אינדיקטור המיקרופון באפליקציות מערכת שיש להן ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמש.
‫[9.8.2/H-4-4] חובה להציג את רשימת האפליקציות האחרונות והפעילות שמשתמשות במיקרופון, כפי שמוחזרות מ-PermissionManager.getIndicatorAppOpUsageData(), יחד עם כל הודעות השיוך שקשורות אליהן.

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

‫[9.8.2/H-5-1] חובה להציג את אינדיקטור גישה למצלמה כשלאפליקציה יש גישה לנתונים בשידור חי מהמצלמה, אבל לא כשלאפליקציה או לאפליקציות יש גישה למצלמה רק אם הן מחזיקות בתפקידים שמפורטים בקטע 9.1 עם מזהה CDD‏ [C-4-X].
‫[9.8.2/H-5-2] חובה להציג את האפליקציות האחרונות והפעילות באמצעות המצלמה כפי שמוחזר מ-PermissionManager.getIndicatorAppOpUsageData(), יחד עם הודעות השיוך שקשורות אליהן.
[9.8.2/H-5-3] אסור להסתיר את אינדיקטור הגישה למצלמה באפליקציות מערכת שיש להן ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמש.

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

‫[9.8.8/H-6-1] חובה להציג אינדיקטור שגלוי למשתמש.

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

‫[9.10/H-1-1] חובה לאמת את כל המחיצות לקריאה בלבד שמועמסות במהלך רצף האתחול של Android, וסיכום ה-VBMeta חייב לכלול בחישוב שלו את כל המחיצות המאומתות האלה.

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

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

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

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

‫Perfetto
- ‫[6.1/H-0-2] חובה לחשוף קובץ בינארי למשתמש במעטפת, ששורת הפקודה שלו תואמת למסמכי התיעוד של perfetto./system/bin/perfetto
- ‫[6.1/H-0-3] קובץ ה-binary של perfetto חייב לקבל כקלט קובץ הגדרה של protobuf שתואם לסכימה שמוגדרת בתיעוד של perfetto.
- ‫[6.1/H-0-4] קובץ הבינארי של perfetto חייב לכתוב כפלט עקבות של protobuf שתואמים לסכימה שמוגדרת במסמכי התיעוד של perfetto.
- ‫[6.1/H-0-5] חובה לספק, באמצעות הקובץ הבינארי של perfetto, לפחות את מקורות הנתונים שמתוארים בתיעוד של perfetto.
- ‫[6.1/H-0-6] שירות ה-daemon של perfetto traced חייב להיות מופעל כברירת מחדל (מאפיין המערכת persist.traced.enable).

2.2.7. Handheld Media Performance Class

ביצענו שינויים משמעותיים במבנה הדרישות של מחלקת הביצועים של המדיה. החל מ-API 37, הוספנו רמות חדשות: 1, 10, 20 ו-37. בנוסף, צמצמנו את מורכבות הדרישות באמצעות הפניה אל דף המדידות של רמת הביצועים של מדיה, שבו מפורטת כל דרישה שנמדדת לפי רמת הביצועים של מדיה.

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

2.2.7.1. מדיה

אם הטמעות של מכשירים ניידים מחזירות ערך שאינו אפס עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, הן:

חייב לעמוד בכל דרישות המדיה שמפורטות בסעיף 2.2.7.1 ב-CDD של Android 17, בהתאם לרמת סיווג הביצועים של המדיה שהמכשיר הצהיר עליה.
‫[5.1/H-1-1] חובה לפרסם את המספר המקסימלי של סשנים של פענוח וידאו בחומרה שאפשר להריץ בו-זמנית בכל שילוב של קודקים באמצעות השיטות CodecCapabilities.getMaxSupportedInstances() ו-VideoCapabilities.getSupportedPerformancePoints() שמתאימות לרמת הביצועים של המדיה שהמכשיר הצהיר עליה.
‫[5.1/H-1-2] המכשיר חייב לתמוך בסשנים של פענוח וידאו בחומרה (AVC,‏ HEVC,‏ VP9,‏ AV1 או גרסאות מאוחרות יותר), במופעים מקבילים ובנשירת פריימים בהתאם לרמת הסיווג של ביצועי המדיה שהוגדרה במכשיר.
‫[5.1/H-1-3] חובה לפרסם את המספר המקסימלי של סשנים של קידוד וידאו בחומרה שאפשר להפעיל בו-זמנית בכל שילוב של קודקים באמצעות השיטות CodecCapabilities.getMaxSupportedInstances() ו-VideoCapabilities.getSupportedPerformancePoints() שמתאימות לרמת הביצועים של המדיה שהמכשיר הצהיר עליה.
‫[5.1/H-1-4] חובה לתמוך בסשנים של מקודד וידאו בחומרה (AVC,‏ HEVC,‏ VP9,‏ AV1 או גרסאות מאוחרות יותר), במופעים מקבילים ובנשירת פריימים בהתאם לרמת הסיווג של ביצועי המדיה שהמכשיר הצהיר עליה.
‫[5.1/H-1-5] חובה לפרסם את המספר המקסימלי של סשנים מקבילים של קידוד ופענוח וידאו בחומרה בכל שילוב של קודקים באמצעות השיטות CodecCapabilities.getMaxSupportedInstances() ו-VideoCapabilities.getSupportedPerformancePoints() שמתאימות לרמת הביצועים של המדיה שהמכשיר הצהיר עליה.
‫[5.1/H-1-6] חובה לתמוך במפענח וידאו חומרה ובמקודד וידאו חומרה בסשנים (AVC,‏ HEVC,‏ VP9,‏ AV1 או גרסאות מאוחרות יותר), במופעים מקבילים ובנשירת פריימים בהתאם לרמת הביצועים של המדיה שהוגדרה במכשיר.
‫[5.1/H-1-7] לכל מקודדי הווידאו בחומרה חייבת להיות השהיה בהפעלת קודק עבור סשן קידוד וידאו ברזולוציית 1080p או ברזולוציה נמוכה יותר, כשהמכשיר נמצא בעומס שמתאים לרמת הביצועים של המדיה שהוגדרה במכשיר.
‫[5.1/H-1-8] לכל מקודדי האודיו חייבת להיות השהיה בהפעלת קודק עבור סשן קידוד אודיו בקצב העברת נתונים של ‎128 kbps או פחות, כשהמכשיר נמצא בעומס שמתאים לרמת הביצועים של המדיה שהוגדרה למכשיר.
‫[5.1/H-1-9] המכשיר חייב לתמוך ב-2 מקרים של פעולות פענוח מאובטחות של וידאו בחומרה (AVC,‏ HEVC,‏ VP9,‏ AV1 או גרסה מאוחרת יותר) ובמספר השמטות של פריימים שמתאים לרמת הביצועים של המדיה שהוגדרה במכשיר.
‫[5.1/H-1-10] המכשיר חייב לתמוך ב-3 מקרים של מפגשי פענוח וידאו בחומרה לא מאובטחת, יחד עם מקרה אחד של מפגש פענוח וידאו בחומרה מאובטחת (4 מקרים בסך הכול) (AVC,‏ HEVC,‏ VP9,‏ AV1 או גרסאות מאוחרות יותר), ברזולוציות ובמספרים של ירידות פריימים שמתאימים לרמת הסיווג של ביצועי המדיה שהוגדרה במכשיר.
‫[5.1/H-1-11] חובה לתמוך במפענח מאובטח לכל מפענח חומרה של AVC,‏ HEVC,‏ VP9 או AV1 שמתאים לרמת סיווג הביצועים של המדיה שהוגדרה במכשיר.
‫[5.1/H-1-12] חובה שתהיה השהיה בהפעלת קודק עבור סשן פענוח קוד של סרטון ברזולוציית 1080p או ברזולוציה נמוכה יותר, לכל מפענחי קוד של סרטונים בחומרה, כשהם פועלים בעומס שמתאים לרמת הביצועים של המדיה שהמכשיר הצהיר עליה.
‫[5.1/H-1-13] לכל מפענחי האודיו חייבת להיות השהיה בהפעלת קודק עבור סשן פענוח אודיו בקצב העברת נתונים של ‎128 kbps או פחות, כשהמערכת נמצאת בעומס שמתאים לרמת הביצועים של המדיה שהוגדרה במכשיר.
‫[5.1/H-1-14] חובה לתמוך בפרופיל, בתכונה ובשיטת התצוגה של מפענח חומרה AV1, שמתאימים לרמת הסיווג של ביצועי המדיה שהמכשיר הצהיר עליה.
‫[5.1/H-1-15] חובה להשתמש לפחות במפענח וידאו אחד בחומרה שתומך ב-4K60 בהתאם לרמת סיווג הביצועים של המדיה שהוגדרה במכשיר.
‫[5.1/H-1-16] חובה להשתמש לפחות במקודד וידאו אחד בחומרה שתומך ב-4K60 בהתאם לרמת סיווג הביצועים של המדיה שהוגדרה במכשיר.
‫[5.1/H-1-17] חובה להשתמש לפחות במפענח תמונות אחד בחומרה שתומך בפרופיל Baseline של AVIF בהתאם לרמת סיווג הביצועים של המדיה שהוגדרה במכשיר.
‫[5.1/H-1-18] חובה לתמוך במקודד AV1 שעומד בדרישות של קצב העברת נתונים, פריימים לשנייה ורזולוציה, בהתאם לרמת הביצועים של המדיה שהוגדרה למכשיר.
‫[5.1/H-1-19] המכשיר חייב לתמוך ב-3 מקרים של מפענח וידאו (HDR) בחומרה של 10 ביט ובסשנים של מקודד וידאו בחומרה (AVC,‏ HEVC,‏ VP9,‏ AV1 או גרסה מתקדמת יותר), ברזולוציה ובנשירת פריימים שמתאימים לרמת סיווג הביצועים של המדיה שהוגדרה במכשיר.
‫[5.1/H-1-20] חובה לתמוך בתכונה Feature_HdrEditing בכל מקודדי החומרה AV1 ו-HEVC שקיימים במכשיר, בהתאם לרמת סיווג הביצועים של המדיה שהוגדרה במכשיר.
‫[5.1/H-1-21] חובה לתמוך ב-FEATURE_DynamicColorAspect בכל מפענחי הווידאו של החומרה (AVC,‏ HEVC,‏ VP9,‏ AV1 או גרסאות מאוחרות יותר) שמתאימים לרמת סיווג הביצועים של המדיה שהמכשיר הצהיר עליה.
‫[5.1/H-1-22] המכשיר חייב לתמוך בקידוד, בפענוח, בעריכה באמצעות GPU ובהצגה של תוכן וידאו ביחס גובה-רוחב לאורך שמתאים לרמת הביצועים של המדיה שהוגדרה במכשיר.
‫[5.2/H-2-1] אם ההטמעה של המכשיר תומכת במקודדי חומרה של AVC או HEVC, היא חייבת לעמוד ביעד האיכות המינימלי שמוגדר על ידי עקומות קצב העיוות של מקודדי הווידאו עבור הקודקים האלה, בהתאם לרמת סיווג הביצועים של המדיה שהוגדרה במכשיר.

‫[5.2/H-2-2] המכשיר חייב לתמוך ב-MMAP בנתיב הרמקול שמתאים לרמת הביצועים של המדיה שהוגדרה במכשיר.

‫[5.3/H-1-1] חובה לעמוד בדרישות של ביצועי סשן הווידאו ושל ירידה במספר הפריימים (frame drop) שמתאימות לרמת סיווג הביצועים של המדיה שהוגדרה במכשיר.
‫[5.3/H-1-2] חובה לעמוד בדרישות הביצועים של שינוי רזולוציית הסרטון בהתאם לרמת סיווג הביצועים של המדיה שהוגדרה למכשיר.
‫[5.6/H-1-1] המכשיר חייב לעמוד בדרישות של זמן האחזור בין הקשה להשמעת הטון, בהתאם לרמת הביצועים של המדיה שהוגדרה במכשיר.
[5.6/H-1-2] המכשיר חייב לעמוד בדרישות של זמן טעינת אודיו (audio latency) הלוך ושוב, בהתאם לרמת סיווג הביצועים של המדיה שהוגדרה למכשיר.
‫[5.6/H-1-3] המכשיר חייב לעמוד בדרישות האודיו של 24 ביט שמתאימות לרמת הביצועים של המדיה שהוגדרה במכשיר.
‫[5.6/H-1-4] חובה לתמוך במכשירי שמע USB עם 4 ערוצים ומעלה, בהתאם לרמת סיווג הביצועים של המדיה שהוגדרה במכשיר.
‫[5.6/H-1-5] חובה לתמוך במכשירי MIDI שתואמים לסיווג, ולהצהיר על דגל התכונה MIDI שמתאים לרמת סיווג הביצועים של המדיה שהוצהרה על ידי המכשיר.
‫[5.6/H-1-9] המכשיר חייב לתמוך במיקס של לפחות 12 ערוצים בהתאם לרמת סיווג הביצועים של המדיה שהוגדרה במכשיר.

‫[5.6/H-3-1] המכשיר חייב להיות מסוגל לעבור בין השמעה של גלי סינוס ללא חוסר נתונים במאגרי האודיו, בהתאם לרמת סיווג הביצועים של המדיה שהוגדרה במכשיר.
‫[5.6/H-3-2] חובה לעמוד בדרישות של ערוץ הפלט של מכשיר אודיו בחיבור USB בהתאם לרמת הביצועים של המדיה שהוגדרה במכשיר.
‫[5.6/H-3-3] המכשיר חייב לעמוד בדרישות של ערוצי הקלט של מכשיר אודיו בחיבור USB בהתאם לרמת הביצועים של המדיה שהוגדרה למכשיר.

‫[5.6/H-SR-1] מומלץ מאוד לתמוך במיקס של ערוצי אודיו בהתאם לרמת סיווג הביצועים של המדיה שהמכשיר הצהיר עליה.
‫[5.7/H-1-2] המכשיר חייב לתמוך ב-MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL עם יכולות הפענוח שמתאימות לרמת סיווג הביצועים של המדיה שהוגדרה במכשיר.
‫[5.12/H-1-2] המכשיר חייב לעמוד בדרישות של פורמט הצבע עבור מקודדי חומרה AV1 ו-HEVC בהתאם לרמת סיווג הביצועים של המדיה שהוגדרה למכשיר.
‫[5.12/H-1-3] חובה לפרסם תמיכה בתוסף EXT_YUV_target בהתאם לרמת סיווג הביצועים של המדיה שהמכשיר הצהיר עליה.
‫[7.1.4/H-1-1] המכשיר חייב לעמוד בדרישות של יחידת עיבוד התצוגה (DPU) בהתאם לרמת סיווג הביצועים של המדיה שהוגדרה למכשיר.

2.2.7.2. מצלמה

אם הטמעות של מכשירים שניתן להחזיק ביד מחזירות ערך שאינו אפס עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, הן:

חייב לעמוד בדרישות המצלמה שמפורטות בסעיף 2.2.7.2 ב-Android 17 CDD, בהתאם לרמת סיווג הביצועים של המדיה שהוגדרה למכשיר.

אם הטמעות של מכשירים שניתן להחזיק ביד מחזירות ערך שאינו אפס עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, הן:

‫[7.5/H-1-1] המכשיר חייב לעמוד בדרישות הרזולוציה של המצלמה הראשית שפונה לאחור ובדרישות של צילום הווידאו, בהתאם לרמת הסיווג של ביצועי המדיה שהוגדרה למכשיר.
‫[7.5/H-1-2] המכשיר חייב לעמוד בדרישות הרזולוציה של המצלמה הקדמית הראשית ושל צילום הווידאו, בהתאם לרמת הביצועים של המדיה שהוגדרה למכשיר.
‫[7.5/H-1-3] חובה לתמוך בדרישות המאפיינים של android.info.supportedHardwareLevel בהתאם לרמת סיווג הביצועים של המדיה שהמכשיר הצהיר עליה.
‫[7.5/H-1-4] חובה לתמוך ב-CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME עבור המצלמות הראשיות בהתאם לרמת סיווג הביצועים של המדיה שהוגדרה למכשיר.
‫[7.5/H-1-5] המכשיר חייב לעמוד בדרישות של זמן האחזור של לכידת JPEG ב-camera2, בהתאם לרמת הסיווג של ביצועי המדיה שהוצהרה על ידי המכשיר.
‫[7.5/H-1-6] המכשיר חייב לעמוד בדרישות של זמן האחזור להפעלה של camera2 שמתאימות לרמת הביצועים של המדיה שהוגדרה למכשיר.
‫[7.5/H-1-8] המכשיר חייב לעמוד בדרישות של צילום במצלמת RAW בהתאם לרמת הביצועים של המדיה שהוגדרה למכשיר.
‫[7.5/H-1-9] המכשיר חייב לעמוד בדרישות של צילום וידאו במהירות גבוהה במצלמה הראשית שפונה לאחור, בהתאם לרמת הסיווג של ביצועי המדיה שהוצהרה לגבי המכשיר.
‫[7.5/H-1-10] המכשיר חייב לעמוד בדרישות המינימליות של יחס הזום בהתאם לרמת הסיווג של ביצועי המדיה שהוצהרה לגביו.
‫[7.5/H-1-11] חובה להטמיע סטרימינג בו-זמני מהמצלמות הקדמיות והאחוריות במצלמות הראשיות בהתאם לרמת הסיווג של ביצועי המדיה שהוגדרה במכשיר.
‫[7.5/H-1-12] המכשיר חייב לתמוך בייצוב וידאו במצלמה האחורית הראשית בהתאם לרמת הביצועים של המדיה שהוגדרה למכשיר.
‫[7.5/H-1-13] המכשיר חייב לתמוך ביכולת LOGICAL_MULTI_CAMERA של המצלמה הראשית שפונה לאחור, בהתאם לרמת הסיווג של ביצועי המדיה שהוגדרה במכשיר.
‫[7.5/H-1-14] המכשיר חייב לתמוך ביכולת STREAM_USE_CASE גם במצלמה הקדמית הראשית וגם במצלמה האחורית הראשית, בהתאם לרמת הביצועים של המדיה שהוגדרה במכשיר.
‫[7.5/H-1-15] חובה לתמוך בתוספים של מצב לילה באמצעות CameraX ותוספים של Camera2 למצלמות ראשיות שתואמות לרמת סיווג הביצועים של המדיה שהוגדרה במכשיר.
‫[7.5/H-1-16] חובה לתמוך ביכולת DYNAMIC_RANGE_TEN_BIT במצלמות הראשיות שמתאימות לרמת הביצועים של המדיה שהוגדרה למכשיר.
‫[7.5/H-1-17] המכשיר חייב לתמוך בתכונות של זיהוי פנים במצלמות הראשיות בהתאם לרמת הביצועים של המדיה שהוגדרה למכשיר.
‫[7.5/H-1-18] המכשיר חייב לתמוך ב-JPEG_R במצלמות האחוריות והקדמיות הראשיות, בהתאם לרמת סיווג הביצועים של המדיה שהוגדרה במכשיר.
‫[7.5/H-1-19] חובה לתמוך ב-CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION במצלמה האחורית הראשית בהתאם לרמת סיווג הביצועים של המדיה שהוגדרה למכשיר.
‫[7.5/H-1-20] כברירת מחדל, אפליקציית המצלמה המקורית חייבת להפיק JPEG_R עבור המצלמות הראשיות האחורית והקדמית, בהתאם לרמת סיווג הביצועים של המדיה שהוגדרה במכשיר.

‫[7.5/H-1-21] חובה לכלול לפחות מצלמה אחת שפונה קדימה או מצלמה אחת שפונה אחורה, בהתאם לרמת הביצועים של המדיה שהוצהרה במכשיר.

2.2.7.3. חומרה

אם הטמעות של מכשירים שניתן להחזיק ביד מחזירות 20 עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, אז הן:

‫[7.1.1.1/H-1-1] חובה שתהיה רזולוציית מסך של 1080p לפחות.
‫[7.1.1.3/H-1-1] חובה שהצפיפות במסך תהיה לפחות ‎400 dpi.
‫[7.6/H-1-1] חייב להיות זמין לליבת המערכת נפח של לפחות ‎5.12 GiB, כפי שמדווח על ידי android.app.ActivityManager.MemoryInfo.

אם הטמעות של מכשירים ניידים מחזירות ערך שאינו אפס עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, הן:

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

אם הטמעות של מכשירים ניידים מחזירות ערך שאינו אפס עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, הן:

‫[7.1.1.1/H-1-1] הפריט הזה לא נכלל בכוונה.
‫[7.1.1.1/H-2-1] הרזולוציה של המסך חייבת להתאים לרמת הביצועים של המדיה שהמכשיר הצהיר עליה.
‫[7.1.1.3/H-1-1] הפריט הזה לא נכלל בכוונה.
‫[7.1.1.3/H-2-1] צריכה להיות למכשיר צפיפות מסך שתואמת לרמת הביצועים של המדיה שהוגדרה במכשיר.
‫[7.1.1.3/H-3-1] המכשיר חייב לתמוך בדרישות של מסך HDR בהתאם לרמת הסיווג של ביצועי המדיה שהוגדרה למכשיר.
‫[7.6.1/H-1-1] הפריט הזה לא נכלל בכוונה.
‫[7.6.1/H-2-1] המכשיר חייב לעמוד בדרישות הזיכרון שמתאימות לרמת סיווג הביצועים של המדיה שהוצהרה לגביו.

‫2.2.7.4. ביצועים

אם הטמעות של מכשירים שניתן להחזיק ביד מחזירות ערך שאינו אפס עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, הן:

המכשיר חייב לעמוד בדרישות הביצועים שמפורטות בסעיף 2.2.7.4 של Android 17 CDD, בהתאם לרמת סיווג הביצועים של המדיה שהוגדרה למכשיר.

אם הטמעות של מכשירים שניתן להחזיק ביד מחזירות ערך שאינו אפס עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, הן:

‫[8.2/H-1-1] חובה לוודא שביצועי הכתיבה הרציפה תואמים לרמת סיווג הביצועים של המדיה שהוכרזה על ידי המכשיר.
‫[8.2/H-1-2] חובה לוודא שביצועי הכתיבה האקראית תואמים לרמת סיווג ביצועי המדיה המוצהרת של המכשיר.
‫[8.2/H-1-3] חובה לוודא שביצועי הקריאה הרציפה תואמים לרמת סיווג הביצועים של המדיה שהוצהרה על ידי המכשיר.
‫[8.2/H-1-4] חובה לוודא שביצועי הקריאה האקראית תואמים לרמת הסיווג של ביצועי המדיה שהמכשיר הצהיר עליה.
‫[8.2/H-1-5] חובה לוודא ביצועים של קריאה וכתיבה סדרתיות מקבילות בהתאם לרמת סיווג הביצועים של המדיה שהוצהרה על ידי המכשיר.

‫2.2.7.5. גרפיקה

אם הטמעות של מכשירים ניידים מחזירות ערך שאינו אפס עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, הן:

‫[7.1.4.1/H-1-2] המכשיר חייב לתמוך בתוספי EGL הנדרשים שמתאימים לרמת סיווג הביצועים של המדיה שהוצהרה לגבי המכשיר.
‫[7.1.4.1/H-1-3] חובה לתמוך בתכונות הנדרשות של Vulkan שמתאימות לרמת סיווג הביצועים של המדיה שהוגדרה למכשיר.

2.3. דרישות לגבי טלוויזיות

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

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

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

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

2.3.1. חומרה

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

‫[7.2.2/T-0-1] חובה לתמוך בלחצני ניווט.
‫[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 הרץ.
‫[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] הזיכרון שזמין לליבה ולמרחב המשתמש חייב להיות לפחות 1,280MB אם נעשה שימוש באחת מהצפיפויות הבאות:
- ‫400dpi או יותר במסכים קטנים או רגילים
- ‫xhdpi או יותר במסכים גדולים
- ‫tvdpi או יותר במסכים גדולים במיוחד

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

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

‫2.3.2. מולטימדיה

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

‫[5.1/T-0-1] פרופיל MPEG-4 AAC‏ (AAC LC)
‫[5.1/T-0-2] פרופיל MPEG-4 HE AAC ‏ (AAC+)
‫[5.1/T-0-3] AAC ELD (enhanced low delay AAC)

‫[5.1/T-0-4] MPEG-D USAC with MPEG-D DRC (Extended High Efficiency AAC)

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

‫[5.2/T-0-1] H.264
‫[5.2/T-0-2] VP8
‫[5.2/T-0-3] AV1

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

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

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

‫[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
‫[5.3.2/T-0-7] AV1

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

‫[5.3.1/T-1-1] HD 1080p at 29.97 frames per second with Main Profile High Level.
‫[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 בקצב של 60 פריימים לשנייה עם פרופיל Baseline
‫[5.3.4/T-1-2] HD 1080p בקצב של 60 פריימים לשנייה עם Main Profile
‫[5.3.4/T-1-3] HD 1080p בקצב של 60 פריימים לשנייה עם High Profile Level 4.2

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

‫[5.3.5/T-1-1] HD 1080p at 60 frames per second with Main Profile Level 4.1

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

‫[5.3.5/T-2-1] חובה לתמוך בפרופיל הפענוח של UHD ב-60 פריימים לשנייה עם פרופיל Main10 Level 5 Main Tier

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

‫[5.3.6/T-1-1] פרופיל פענוח HD 1080p בקצב של 60 פריימים לשנייה

הטמעות של מכשירי טלוויזיה עם מפענחי חומרה 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-SR1] מומלץ מאוד לתמוך בפרופיל הפענוח של UHD ב-60 פריימים לשנייה עם פרופיל 2 (עומק צבע של 10 ביט).

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

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

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

‫[5.8/T-0-1] חובה להגדיר את מצב פלט ה-HDMI לרזולוציה הגבוהה ביותר עבור פורמט הפיקסלים שנבחר, שפועל עם קצב רענון של 50Hz או 60Hz בצג החיצוני, בהתאם לקצב הרענון של הסרטון באזור שבו המכשיר נמכר.
‫[5.8/T-SR-1] מומלץ מאוד לספק למשתמש אפשרות לבחור את קצב הרענון של 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.2.3.1/T-0-1] חובה לטעון מראש אפליקציה אחת או יותר או רכיבי שירות עם handler של Intent, לכל דפוסי מסנני ה-Intent הציבוריים שמוגדרים על ידי ה-Intent של האפליקציה הבאים שמפורטים כאן.
‫[3.4.1/T-0-1] חובה לספק הטמעה מלאה של android.webkit.Webview API.

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

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

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

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

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

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

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

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

‫[3/T-0-2] חובה להצהיר על תכונת הפלטפורמה android.software.live_tv.
‫[3/T-0-3] המכשיר חייב לתמוך בכל ממשקי ה-API של TIF, כך שאפשר יהיה להתקין ולהשתמש במכשיר באפליקציה שמשתמשת בממשקי ה-API האלה ובשירות third-party TIF-based inputs.

‫Android Television Tuner Framework ‏ (TF) מאחד את הטיפול בתוכן בשידור חי מ-Tuner עם תוכן בסטרימינג מ-IP במכשירי Android TV. ה-Tuner Framework מספק API סטנדרטי ליצירת שירותי קלט שמשתמשים בטיונר של Android TV.

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

‫[3/T-1-1] המכשיר חייב לתמוך בכל ממשקי ה-API של Tuner Framework, כך שאפשר יהיה להתקין ולהשתמש במכשיר באפליקציה שמשתמשת בממשקי ה-API האלה.

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

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

אם הטמעות של מכשירי טלוויזיה כוללות תכונות לשיפור ניהול צריכת החשמל במכשיר, שנכללות ב-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] חובה להציג את נתוני צריכת החשמל באמצעות פקודת ה-shell‏ adb shell dumpsys batterystats למפתחי האפליקציה.

‫2.3.5. מודל אבטחה

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

‫[9/T-0-1] חובה להצהיר על התכונה android.hardware.security.model.compatible

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

‫[9.1/T-0-1] אסור להעניק את ACCESS_FINE_LOCATION כברירת מחדל לאפליקציה הזו.

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

‫[9.11/T-0-1] חובה לגבות את ההטמעה של מאגר המפתחות באמצעות סביבת ביצוע מבודדת.
‫[9.11/T-0-2] חובה להטמיע אלגוריתמים קריפטוגרפיים מסוג RSA,‏ AES,‏ ECDSA ו-HMAC ופונקציות גיבוב מסוג MD5,‏ SHA-1 ו-SHA-2 כדי לתמוך בצורה תקינה באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בקרנל ומעליו. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד של ליבה או של מרחב משתמשים עשוי לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. פרויקט הקוד הפתוח של Android (AOSP) עומד בדרישה הזו באמצעות ההטמעה של Trusty, אבל אפשרות חלופית היא פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת של היפר-ויז'ר מתאים שנבדקה על ידי צד שלישי.
‫[9.11/T-0-3] חובה לבצע את האימות במסך הנעילה בסביבת הביצוע המבודדת, ורק אם האימות מצליח, לאפשר שימוש במפתחות שקשורים לאימות. פרטי הכניסה במסך הנעילה חייבים להיות מאוחסנים באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות במסך הנעילה. פרויקט הקוד הפתוח של Android מספק את שכבת ההפשטה של החומרה (HAL) של Gatekeeper ואת Trusty, שאפשר להשתמש בהם כדי לעמוד בדרישה הזו.
‫[9.11/T-0-4] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה של האימות מוגן על ידי חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. אסור להשתמש במפתחות החתימה של האימות כמזהי מכשיר קבועים.

הערה: כדי לעמוד בדרישה הזו, אתם צריכים לשתף את אותו מפתח אישור עבור מק"ט מסוים, אלא אם יוצרו לפחות 100,000 יחידות של אותו מק"ט. אם מיוצרות יותר מ-100,000 יחידות של אותו מק"ט, אפשר להשתמש במפתח אחר לכל קבוצה של 100,000 יחידות לאחר מכן. לחלופין, אפשר להשתמש בפתרון Remote Key Provisioning (הקצאת מפתחות מרחוק) כדי להקצות למכשיר מפתחות אימות לזמן קצר.

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

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

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

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

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

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

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

‫[9.8.2/T-4-1] חובה להציג את אינדיקטור המיקרופון כשאפליקציה ניגשת לנתוני אודיו מהמיקרופון, אבל לא כשהגישה למיקרופון מתבצעת רק על ידי HotwordDetectionService,‏ SOURCE_HOTWORD,‏ ContentCaptureService או אפליקציות שמחזיקות בתפקידים שמפורטים בסעיף 9.1 הרשאות עם מזהה CDD‏ C-3-X.
‫[9.8.2/T-4-2] אסור להסתיר את אינדיקטור המיקרופון באפליקציות מערכת שיש להן ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמש.

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

[9.8.2/T-5-1] חובה להציג את אינדיקטור גישה למצלמה כשמצלמה ניגשת לנתונים בשידור חי, אבל לא כשמצלמה ניגשת רק לאפליקציות שמחזיקות בתפקידים שצוינו בסעיף 9.1 הרשאות עם מזהה CDD‏ [C-3-X].
[9.8.2/T-5-2] אסור להסתיר את אינדיקטור גישה למצלמה באפליקציות מערכת שיש להן ממשקי משתמש גלויים או אינטראקציית משתמש ישירה.

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

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

‫Perfetto
- ‫[6.1/T-0-1] חובה לחשוף קובץ בינארי /system/bin/perfetto למשתמש של מעטפת הפקודות, ששורת הפקודה שלו תואמת לתיעוד של Perfecto.
- ‫[6.1/T-0-2] קובץ ה-binary של perfetto חייב לקבל כקלט הגדרת protobuf שתואמת לסכימה שמוגדרת במאמרי העזרה של perfetto.
- ‫[6.1/T-0-3] קובץ הבינארי של perfetto חייב לכתוב כפלט עקבות של protobuf שתואמים לסכימה שמוגדרת במסמכי התיעוד של perfetto.
- ‫[6.1/T-0-4] חובה לספק, באמצעות קובץ הבינארי של perfetto, לפחות את מקורות הנתונים שמתוארים במסמכי התיעוד של perfetto.
- ‫[6.1/T-0-5] שד ה-daemon של perfetto traced חייב להיות מופעל כברירת מחדל (מאפיין המערכת persist.traced.enable).

2.4. דרישות לצפייה

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

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

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

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

2.4.1. חומרה

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

‫[7.1.1.1/W-0-1] חובה להשתמש במסך עם גודל פיזי באלכסון בטווח של 1.1 עד 2.5 אינץ'.
‫[7.2.3/W-0-1] חובה שהמשתמש יוכל להשתמש בפונקציית 'בית' ובפונקציית 'הקודם', אלא אם המכשיר נמצא במצב UI_MODE_TYPE_WATCH.
‫[7.2.4/W-0-1] חובה לתמוך בקלט ממסך מגע.
‫[7.3.1/W-SR-1] מומלץ מאוד לכלול מד תאוצה בעל 3 צירים.

אם הטמעות של מכשירי Watch כוללות מקלט 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 מטר לשנייה, לפחות ב-95% מהזמן.

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

‫[7.3.4/W-2-1] חובה שתהיה אפשרות למדוד שינויים בהתמצאות במרחב עד 1,000 מעלות לשנייה.

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

‫[7.4.1/W-1-1] חובה להצהיר על התכונה android.hardware.telephony.data.

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

‫[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.2.3.1/W-0-1] חובה לטעון מראש אפליקציה אחת או יותר או רכיבי שירות עם handler של Intent, לכל דפוסי מסנני ה-Intent הציבוריים שמוגדרים על ידי ה-Intent של האפליקציה הבאים שמפורטים כאן.

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

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

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

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

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

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

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

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

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

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

[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] חובה להציג את נתוני צריכת החשמל האלה למפתח האפליקציה באמצעות פקודת ה-Shell‏ adb shell dumpsys batterystats.
[8.4/W] צריך להיות משויך לרכיב החומרה עצמו אם אי אפשר לשייך את צריכת החשמל של רכיב החומרה לאפליקציה.

‫2.4.5. מודל אבטחה

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

‫[9/W-0-1] חובה להצהיר על התכונה android.hardware.security.model.compatible.

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

‫[9.1/W-0-1] אסור להעניק את ACCESS_FINE_LOCATION כברירת מחדל לאפליקציה הזו.

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

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

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

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

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

‫[9.11.1/W-1-1] המערכת חייבת לדרוש מהמשתמש להשתמש באחת משיטות האימות העיקריות המומלצות (כמו קוד אימות, קו ביטול נעילה או סיסמה) בתדירות גבוהה יותר מפעם אחת בכל 72 שעות לפחות פעם אחת בכל 336 שעות (14 ימים) .

אם הטמעות המכשיר כוללות מסך נעילה מאובטח וסביבה אמינה אחת או יותר, שקוראות ל-System API‏ TrustAgentService.grantTrust() עם הדגל FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, הן:

‫[9.11.1/W-2-1] חובה לעמוד בתנאים הבאים כדי להתקשר אל grantTrust() עם הדגל הזה:
- המכשיר מחובר למכשיר פיזי ראשי שניתן להחזיק ביד בקרבת מקום, שיש לו מסך נעילה משלו, וגם
- המשתמש אימת את הזהות שלו מול מסך הנעילה או מול אימות ביומטרי מסוג Class 3 ב-30 השניות האחרונות.
‫[9.11.1/W-2-2] המכשיר חייב להגדיר את המצב שלו ל-TrustState.TRUSTABLE כשהמכשיר הלביש מוסר מהיד או מהגוף, ו-TrustAgent לא ביטל את המהימנות.

2.5. דרישות בתחום הרכב

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

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

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

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

2.5.1. חומרה

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

‫[7.1.1.1/A-0-1] חובה שמכשיר יכלול מסך בגודל של לפחות 6 אינץ' באלכסון פיזי.
‫[7.1.1.1/A-0-2] חובה להשתמש בפריסת גודל מסך של לפחות ‎750 dp x 480 dp.
‫[7.1.1.1/A-0-3] המכשיר חייב לתמוך בהרכבת GPU של מאגרי גרפיקה בגודל לפחות כמו הרזולוציה הגבוהה ביותר של כל תצוגה מובנית.

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

‫[7.1.1.1/A-1-1] חייב להיות מסך נפרד בגודל של לפחות 6 אינץ' באלכסון פיזי לכל אזור תפוס לתצוגה הראשית. צריך לתייג את זה בתור CarOccupantZoneManager.DISPLAY_TYPE_MAIN לכל אזור תפוסה.
‫[7.1.1.1/A-1-2] לכל מסך ראשי חייב להיות פריסת גודל מסך של לפחות ‎750 dp x 480 dp.

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

‫[7.1.4.1/A-0-1] חובה להצהיר על OpenGL ES 3.1 או גרסה מתקדמת יותר.
‫[7.1.4.1/A-0-2] המכשיר חייב לתמוך ב-Vulkan 1.1.
‫[7.1.4.1/A-0-3] חובה לכלול טוען Vulkan ולייצא את כל הסמלים.

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

‫[7.1.4.2/A-1-1] חייב לעמוד בדרישות שצוינו בפרופיל Android Baseline 2021.

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

‫[7.1.4.5/A-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.4.6/A-0-1] המכשיר חייב לדווח אם הוא תומך ביכולת ליצור פרופיל של ה-GPU באמצעות מאפיין מערכת graphics.gpu.profiler.support.

אם הטמעות של מכשירים לרכב מצהירות על תמיכה באמצעות מאפיין מערכת graphics.gpu.profiler.support, הן:

‫[7.1.4.6/A-1-1] חובה לדווח כפלט על עקבות של protobuf שתואם לסכימה של מוני GPU ו-GPU RenderStages שמוגדרים במסמכי Perfetto.
‫[7.1.4.6/A-1-2] חובה לדווח על ערכים תואמים למונים של ה-GPU במכשיר בהתאם ל-gpu counter trace packet proto.
‫[7.1.4.6/A-1-3] חובה לדווח על ערכים תואמים של GPU RenderStages במכשיר בהתאם ל-render stage trace packet proto.
‫[7.1.4.6/A-1-4] חובה לדווח על נקודת מעקב של תדר GPU בהתאם לפורמט: power/gpu_frequency.

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

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

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

‫[7.1.7/A-0-1] חובה להגדיר מסכים משניים בקו הראייה של הנהג כFLAG_PRIVATE.
‫[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-SR1] יכול לבצע ניווט משוער של המיקום על ידי שילוב של GPS/GNSS עם חיישנים נוספים. אם המיקום מחושב באמצעות ניווט משוער, מומלץ מאוד ליישם ולדווח על סוגי החיישנים ו/או על מזהי מאפייני הרכב שבהם נעשה שימוש.
‫[7.3/A-0-4] המיקום שמתבקש באמצעות ‫LocationManager#requestLocationUpdates() אסור להיות מיקום שנקבע על ידי התאמה למפה.
‫[7.3.1/A-0-4] חובה לעמוד בדרישות של מערכת הקואורדינטות של חיישני הרכב ב-Android.
[7.3/A-SR-1] מומלץ מאוד לכלול מד תאוצה ב-3 צירים וג'ירוסקופ ב-3 צירים.
‫[7.3/A-SR-2] מומלץ מאוד להטמיע את חיישן TYPE_HEADING ולדווח עליו.

‫[7.3/A-1-1] חובה להגדיר את ערך הדגל NIGHT_MODE באופן עקבי עם מצב יום/לילה בלוח הבקרה בכל המסכים, כולל המסכים במושב האחורי.

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

‫[7.3.1/A-1-1] המכשיר חייב להיות מסוגל לדווח על אירועים בתדירות של לפחות 100 הרץ.

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

‫[7.3.1/A-SR-1] מומלץ מאוד להטמיע את החיישן המורכב עבור מד תאוצה עם צירים מוגבלים.

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

‫[7.3.1/A-1-3] חובה להטמיע את חיישן TYPE_ACCELEROMETER_LIMITED_AXES ולדווח עליו.
‫[7.3.1/A-1-4] חובה להטמיע ולדווח על חיישן TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

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

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

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

‫[7.3.4/A-SR-2] מומלץ מאוד להטמיע את החיישן המורכב עבור גירוסקופ עם צירים מוגבלים.

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

‫[7.3.4/A-4-1] חובה להטמיע ולדווח על חיישן TYPE_GYROSCOPE_LIMITED_AXES.
‫[7.3.4/A-4-2] חובה להטמיע ולדווח על TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED חיישן.

אם הטמעות של מכשירים לרכב כוללות מקלט GPS/GNSS, אבל לא כוללות קישוריות נתונים שמבוססת על רשת סלולרית, הן:

‫[7.3.3/A-3-1] חובה לקבוע את המיקום בפעם הראשונה שמפעילים את מקלט ה-GPS/GNSS או אחרי 4 ימים ומעלה, תוך 60 שניות.
‫[7.3.3/A-3-2] חובה לעמוד בקריטריונים של זמן עד לתיקון הראשון כפי שמתואר ב-7.3.3/C-1-2 וב-7.3.3/C-1-6 לכל שאר הבקשות למיקום (כלומר, בקשות שהן לא הפעם הראשונה או אחרי 4 ימים ומעלה). הדרישה 7.3.3/C-1-2 מתקיימת בדרך כלל ברכבים ללא קישוריות נתונים שמבוססת על רשת סלולרית, באמצעות שימוש בתחזיות מסלול GNSS שמחושבות במקלט, או באמצעות שימוש במיקום האחרון הידוע של הרכב יחד עם היכולת לבצע ניווט משוער למשך 60 שניות לפחות עם דיוק מיקום שעומד בדרישה 7.3.3/C-1-3, או שילוב של שתי האפשרויות.

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

‫[7.3.4/A-4-3] חובה לדווח על אירועים בתדירות של לפחות 1 הרץ.
‫[7.3.4/A-SR-3] מומלץ מאוד לדווח על אירועים בתדירות של לפחות 10 הרץ.
הכיוון צריך להיות ביחס לצפון האמיתי.
האפשרות צריכה להיות זמינה גם כשהרכב לא בתנועה.
מומלץ שהרזולוציה תהיה לפחות מעלה אחת.

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

‫[7.4.3/A-0-1] המכשיר חייב לתמוך ב-Bluetooth, ומומלץ לתמוך ב-Bluetooth LE.
‫[7.4.3/A-0-2] הטמעות של Android Automotive חייבות לתמוך בפרופילי ה-Bluetooth הבאים:
- שיחות טלפון באמצעות פרופיל דיבורית (HFP).
- הפעלת מדיה באמצעות פרופיל הפצת אודיו (A2 DP).
- שליטה בהפעלת מדיה באמצעות פרופיל שלט רחוק לאודיו/וידאו (AVRCP).
- שיתוף אנשי קשר באמצעות פרופיל הגישה לספר הטלפונים (PBAP).
‫[7.4.3/A-SR-1] מומלץ מאוד לתמוך ב-Message Access Profile (פרופיל גישה להודעות, MAP) אם למכשיר יש אזור נהג.

‫[7.4.3/A-1-1] חובה שהמכשיר יהיה עצמאי ולא יפריע לחוויית ה-BT של משתמשים אחרים.

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

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

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

‫[7.4/A-1-1] חובה להצהיר על תמיכה ב-FEATURE_BROADCAST_RADIO.

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

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

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

‫[7.5/A-SR-1] מומלץ מאוד לכלול מצלמה אחת או יותר שפונות אל העולם.
יכול להיות שיכלול מצלמה אחת או יותר שפונות למשתמש.
‫[7.5/A-SR-2] מומלץ מאוד לתמוך בסטרימינג בו-זמני של כמה מצלמות.

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

‫[7.5/A-1-1] חובה לכוון את המצלמה כך שהמימד הארוך שלה יתיישר עם מישור ה-X-Y של צירי החיישנים של Android Automotive.
‫[7.5/A-SR-3] מומלץ מאוד להשתמש בחומרה עם פוקוס קבוע או עם עומק שדה מורחב (EDOF).
‫[7.5/A-1-2] המצלמה הראשית שפונה החוצה חייבת להיות המצלמה שפונה החוצה עם מזהה המצלמה הנמוך ביותר.

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

‫[7.5/A-2-1] המצלמה הראשית שפונה למשתמש חייבת להיות המצלמה שפונה למשתמש עם מזהה המצלמה הנמוך ביותר.
יכול להיות שהמצלמה תהיה מכוונת כך שהמימד הארוך שלה יהיה מיושר עם מישור ה-X-Y של צירי החיישנים של Android Automotive.

אם הטמעות של מכשירים לרכב כוללות מצלמה שאפשר לגשת אליה באמצעות ממשקי ה-API‏ android.hardware.Camera או android.hardware.camera2, הן:

‫[7.5/A-3-1] חובה לעמוד בדרישות הליבה של המצלמה שמפורטות בסעיף 7.5.

אם הטמעות של מכשירים לרכב כוללות מצלמה שלא ניתן לגשת אליה באמצעות ממשקי ה-API‏ android.hardware.Camera או android.hardware.camera2, אז:

‫[7.5/A-4-1] חובה שתהיה גישה אליו דרך שירות המערכת Extended View.

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

‫[7.5/A-5-1] אסור לסובב את התצוגה המקדימה של המצלמה או לבצע בה היפוך אופקי.
‫[7.5/A-SR-4] מומלץ מאוד שהרזולוציה תהיה לפחות 1.3 מגה-פיקסל.

אם הטמעות של מכשירים לרכב כוללות מצלמה אחת או יותר שאפשר לגשת אליהן גם דרך שירות מערכת התצוגה המורחבת וגם דרך android.hardware.Cameraאו android.hardware.Camera2 API, אז לגבי מצלמה כזו:

‫[7.5/A-6-1] חובה לדווח על אותו מזהה מצלמה.

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

‫[7.5/A-7-1] חובה להטמיע ממשק API כזה למצלמה באמצעות android.hardware.camera2 API או Extended View System API.

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

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

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

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

‫[7.6.1/A-1-1] חובה, במופע יחיד של AAOS, לפחות 4 GB לכל משתמש Android בו-זמני של אחסון לא נדיף שזמין לנתונים פרטיים של אפליקציות (מחיצת /data).

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

‫[7.6.1/A-2-1] הזיכרון שזמין לליבת מערכת ההפעלה ולמרחב המשתמש חייב להיות לפחות 816 MB לכל מסך ראשי אם נעשה שימוש באחת מהצפיפויות הבאות:
- ‫280 dpi או פחות במסכים קטנים או רגילים
- ‫ldpi או פחות במסכים גדולים במיוחד
- ‫mdpi או נמוך יותר במסכים גדולים
‫[7.6.1/A-2-2] הזיכרון שזמין לליבת המערכת ולמרחב המשתמש חייב להיות לפחות 944 MB לכל מסך ראשי אם נעשה שימוש באחת מהצפיפויות הבאות:
- ‫xhdpi או יותר במסכים קטנים או רגילים
- ‫hdpi או יותר במסכים גדולים
- ‫mdpi או יותר במסכים גדולים במיוחד
‫[7.6.1/A-2-3] הזיכרון שזמין לליבת המערכת ולמרחב המשתמש חייב להיות לפחות 1,280 MB לכל מסך ראשי אם נעשה שימוש באחת מהצפיפויות הבאות:
- ‫400 dpi או יותר במסכים קטנים או רגילים
- ‫xhdpi או יותר במסכים גדולים
- ‫tvdpi או יותר במסכים גדולים במיוחד
‫[7.6.1/A-2-4] הזיכרון שזמין לליבת המערכת ולמרחב המשתמש חייב להיות לפחות 1,824 MB לכל מסך ראשי אם נעשה שימוש באחת מהצפיפויות הבאות:
- ‫560 dpi או יותר במסכים קטנים או רגילים
- ‫400 dpi או יותר במסכים גדולים
- ‫xhdpi או יותר במסכים גדולים במיוחד

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

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

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

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

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

‫[7.7.2/A-1-1] חובה להטמיע את מחלקת האודיו של USB כפי שמתואר במסמכי ה-Android SDK.

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

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

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

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

‫[7.8.2/A-1-1] חובה להשתמש במכשיר פלט אודיו לכל מסך ראשי במערכות מרובות משתמשים בו-זמנית.
‫[7.8.2/A-1-2] חובה להגדיר אזור אודיו לנהג שמכסה את הרמקול הכללי בתא הנוסעים. באזור של הנוסע הקדמי אפשר לשתף את אזור האודיו של הנהג או להגדיר פלט אודיו משלו.

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

‫[7.8.2.2/A-1-1] חובה לפרט מכשיר מסוג AudioDeviceInfo.TYPE_USB_HEADSET ותפקיד isSink() אם השדה של סוג מסוף האודיו ב-USB הוא 0x0302.
‫[7.8.2.2/A-1-2] חובה לפרט מכשיר מסוג AudioDeviceInfo.TYPE_USB_HEADSET ותפקיד isSink() אם השדה של סוג מסוף האודיו ב-USB הוא 0x0402.
‫[7.8.2.2/A-1-3] חובה לפרט מכשיר מסוג AudioDeviceInfo.TYPE_USB_HEADSET ותפקיד isSink() אם השדה של סוג מסוף האודיו ב-USB הוא 0x0603.
‫[7.8.2.2/A-1-4] חובה לציין מכשיר מסוג AudioDeviceInfo.TYPE_USB_HEADSET ותפקיד isSink() אם השדה של סוג מסוף האודיו ב-USB הוא 0x0400.

2.5.2. מולטימדיה

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

‫[5.1/A-0-1] פרופיל MPEG-4 AAC ‏ (AAC LC)
‫[5.1/A-0-2] פרופיל MPEG-4 HE AAC ‏ (AAC+)
‫[5.1/A-0-3] AAC ELD (enhanced low delay AAC)

‫[5.1/A-0-4] MPEG-D USAC with MPEG-D DRC (Extended High Efficiency 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-1] H.265 HEVC

‫[5.5.3/A-1-1] חובה להגדיר עקומות עוצמת קול זהות לכל זרמי פלט האודיו שממופים לאותה קבוצת עוצמת קול, כפי שמוגדר בקובץ ההגדרות של האודיו ברכב.

‫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.*.

אם הטמעות של מכשירים לרכב מספקות API קנייני באמצעות android.car.CarPropertyManager עם android.car.VehiclePropertyIds, הן:

‫[3/A-1-1] אסור להקצות הרשאות מיוחדות לשימוש של אפליקציית המערכת במאפיינים האלה, או למנוע מאפליקציות של צד שלישי להשתמש במאפיינים האלה.
‫[3/A-1-2] אסור לשכפל מאפיין של רכב שכבר קיים ב-SDK.

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

‫[3.2.1/A-0-1] חובה לתמוך בכל קבועי ההרשאות ולאכוף אותם, כפי שמתואר בדף ההפניה בנושא הרשאות לרכב.
‫[3.2.3.1/A-0-1] חובה לטעון מראש אפליקציה אחת או יותר או רכיבי שירות עם handler של Intent, לכל התבניות של מסנני ה-Intent הציבוריים שמוגדרים על ידי ה-Intent של האפליקציה הבאים שמפורטים כאן.
‫[3.2.3.1/A-0-2] חובה להשתמש באפליקציה שמטפלת ב-intent‏ ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, ו-ACTION_CREATE_DOCUMENT כפי שמתואר במסמכי ה-SDK, ולספק למשתמש אמצעי גישה לנתונים של ספק המסמכים באמצעות DocumentsProvider API.

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

‫[3.2.3.1/A-1-1] חובה להשתמש בפעילות שמטפלת ב-intent‏ Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY כשהפונקציונליות של הפיצול מופעלת. הפעילות חייבת להיות מוגנת על ידי android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK, והיא חייבת להתחיל את הפעילות של הכוונה שנותחה מ-Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.
‫[3.4.1/A-0-1] חובה לספק הטמעה מלאה של android.webkit.Webview API.

‫[3.8/A-1-1] חובה להטמיע את רשימת UserRestrictions המוגדרת מראש הבאה עבור משתמשים משניים מלאים שאינם המשתמש הנוכחי בחזית, אבל יש להם גישה לממשק המשתמש של התצוגה שהוקצתה להם. רשימת UserRestrictions היא: DISALLOW_CONFIG_LOCALE, DISALLOW_CONFIG_BLUETOOTH, DISALLOW_BLUETOOTH, DISALLOW_CAMERA_TOGGLE, וDISALLOW_MICROPHONE_TOGGLE.
‫[3.8/A-1-2] אסור לאפשר למשתמשים משניים מלאים שאינם המשתמש הנוכחי בחזית, אבל יש להם גישה לממשק המשתמש של התצוגה שהוקצתה להם, לשנות את המצב 'יום/לילה', את הלוקאל, את התאריך, את השעה, את אזור הזמן או את התכונות של צבע התצוגה (כולל בהירות, תאורת לילה, גווני אפור של שימוש חכם בדיגיטל והפחתת צבעים בהירים) עבור משתמש אחר כלשהו דרך ההגדרות או דרך API.

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

‫[3.8.3/A-0-1] חובה להציג הודעות שמשתמשות ב-API‏ Notification.CarExtender כשמתקבלת בקשה מאפליקציות של צד שלישי.
‫[3.8.4/A-SR-1] מומלץ מאוד להטמיע במכשיר עוזר דיגיטלי לטיפול בפעולת העזרה.

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

‫[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] חובה להציג את האפשרויות PLAY ו-MUTE לפעולות שקשורות להתראות במקום האפשרויות שמופיעות דרך Notification.Builder.addAction()
‫[3.8.3.1/A] צריך להגביל את השימוש במשימות ניהול מתקדמות, כמו אמצעי בקרה לכל ערוץ התראות. יכול להיות שיהיה שימוש במזמינוּת ממשק משתמש לכל אפליקציה כדי לצמצם את אמצעי הבקרה.

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

‫[3.9.3/A-1-1] חובה להטמיע את כל המאפיינים של מחזור החיים של המשתמש:‏ INITIAL_USER_INFO,‏ SWITCH_USER,‏ CREATE_USER ו-REMOVE_USER.

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

‫[3.14/A-0-1] חובה לכלול מסגרת ממשק משתמש לתמיכה באפליקציות צד שלישי שמשתמשות בממשקי ה-API של המדיה, כפי שמתואר בקטע 3.14.
‫[3.14/A-0-2] חובה לאפשר למשתמש אינטראקציה בטוחה עם אפליקציות מדיה בזמן נהיגה.
‫[3.14/A-0-3] חובה לתמוך בפעולת Intent מרומזת עם התוסף CAR_INTENT_ACTION_MEDIA_TEMPLATECAR_EXTRA_MEDIA_PACKAGE.
‫[3.14/A-0-4] חובה לספק אמצעי ניווט אל פעילות ההעדפות של אפליקציית מדיה, אבל האפשרות הזו צריכה להיות זמינה רק כשלא חלות הגבלות על חוויית המשתמש ברכב.
‫[3.14/A-0-5] חובה להציג הודעות שגיאה שהוגדרו על ידי אפליקציות מדיה, וחובה לתמוך בתוספים האופציונליים 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-0-8] חובה להצהיר על ה-feature flag‏ android.software.car.templates_host.
‫[3.14/A-0-9] חובה להצהיר על ה-feature flag‏ com.android.car.background_audio_while_driving.
‫[3.14/A-0-10] חובה להצהיר על feature flag android.software.car.templates_host.media.

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

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

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

‫[3.8/A] יכול להיות שהמערכת תגביל את בקשות האפליקציה להיכנס למצב מסך מלא, כפי שמתואר בקטע immersive documentation.
‫[3.8/A] יכול להיות ששורת הסטטוס וסרגל הניווט תמיד יהיו גלויים.
‫[3.8/A] יכול להיות שהמערכת תגביל את הבקשות של האפליקציה לשנות את הצבעים שמאחורי רכיבי ה-UI של המערכת, כדי לוודא שהרכיבים האלה יהיו גלויים בבירור בכל שלב.

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

‫[7.1.1/A-0-1] חובה להצהיר על ה-feature flag‏ android.software.car.display_compatibility.

בזמן הפעלת אפליקציות בחזית עם התכונה android.software.car.display_compatibility או אפליקציות ללא התכונה android.hardware.type.automotive, במכשירי Automotive:

‫[7.1.1/A-1-1] חובה לספק את הפונקציה 'הקודם'.

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

‫[7.4.1.2/A-1-1] חובה להצהיר על מתג ה-feature flag android.software.telecom.

‫[7.4.1.2/A-1-2] חובה להטמיע את מסגרת הטלקום.

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

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

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

‫[8.2/A-0-1] חובה לדווח על מספר הבייטים שנקראו ונכתבו לאחסון לא נדיף לכל UID של תהליך, כדי שהנתונים הסטטיסטיים יהיו זמינים למפתחים דרך System API‏ android.car.storagemonitoring.CarStorageMonitoringManager. פרויקט הקוד הפתוח של Android עומד בדרישה באמצעות מודול הליבה uid_sys_stats.
‫[8.2/A-0-2] חובה להבטיח ביצועים של כתיבה רציפה של לפחות 5 MB/s.
‫[8.2/A-0-3] חובה לוודא ביצועים של כתיבה אקראית של לפחות ‎0.5 MB/s.
‫[8.2/A-0-4] חובה לוודא ביצועים של קריאה רציפה במהירות של 15 MB/s לפחות.
‫[8.2/A-0-5] חובה לוודא ביצועים של קריאה אקראית במהירות של לפחות ‎3.5 MB/s.

אם הטמעות של מכשירים לרכב מחזירות את הערך android.os.Build.VERSION_CODES.U או ערך גבוה יותר עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, הן:

‫[8.2/A-1-1] חובה לוודא ביצועים של כתיבה רציפה של לפחות 150 MB/s.
‫[8.2/A-1-2] חובה לוודא שביצועי הכתיבה האקראית הם לפחות 10 MB/s.
‫[8.2/A-1-3] חובה לוודא ביצועי קריאה רציפים של לפחות 250 MB/s.
‫[8.2/A-1-4] חובה לוודא ביצועים של קריאה אקראית במהירות של 100 MB/s לפחות.
‫[8.2/A-1-5] חובה להבטיח ביצועים מקבילים של קריאה וכתיבה ברצף, עם ביצועי קריאה של פי 2 וביצועי כתיבה של פי 1, לפחות 50 MB/s.
‫[8.3/A-1-3] חובה לתמוך במצב מוסך.
‫[8.3/א] צריך להיות במצב חנייה למשך 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/א] אם אי אפשר לשייך את צריכת החשמל של רכיב החומרה לאפליקציה, צריך לשייך אותה לרכיב החומרה עצמו.
‫[8.4/A-0-4] חובה להציג את נתוני צריכת החשמל האלה למפתח האפליקציה באמצעות פקודת ה-Shell‏ adb shell dumpsys batterystats.

‫2.5.5. מודל אבטחה

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

‫[9.5/A-1-1] אסור לאפשר למשתמשים ליצור אינטראקציה עם משתמש המערכת ללא ראש או לעבור אליו, למעט הקצאת הרשאות למכשיר.
‫[9.5/A-1-2] חובה לעבור אל משתמש משני לפני BOOT_COMPLETED.
‫[9.5/A-1-3] המכשיר חייב לתמוך באפשרות ליצור משתמש אורח גם אם הגעתם למספר המשתמשים המקסימלי במכשיר.

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

‫[9.8/A-1-1] חובה לוודא ששירות זיהוי השאילתות יכול להעביר נתונים רק למערכת, ל-ContentCaptureService או לשירות זיהוי דיבור במכשיר (שנוצר על ידי SpeechRecognizer#createOnDeviceSpeechRecognizer()).
‫[9.8/A-1-2] אסור לאפשר העברה של מידע אודיו או וידאו מחוץ ל-VisualQueryDetectionService, אלא ל-ContentCaptureService או לשירות זיהוי דיבור במכשיר.
‫[9.8/A-1-3] חובה להציג הודעה למשתמש בממשק המשתמש של המערכת כשהמכשיר מזהה כוונה של המשתמש להשתמש באפליקציה של העוזר הדיגיטלי (למשל, על ידי זיהוי נוכחות המשתמש באמצעות המצלמה).
‫[9.8/A-1-4] חובה להציג אינדיקטור למיקרופון ולהציג את שאילתת המשתמש שזוהתה בממשק המשתמש מיד אחרי ששאילתת המשתמש זוהתה.
‫[9.8/A-1-5] אסור לאפשר לאפליקציה שניתנת להתקנה על ידי משתמש לספק את שירות הזיהוי של שאילתות חזותיות.

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

‫[9.8.2/A-1-1] חובה להציג את האינדיקטור של המיקרופון כשלאפליקציה יש גישה לנתוני אודיו מהמיקרופון, אבל לא כשגישה למיקרופון ניתנת רק ל-HotwordDetectionService, ל-SOURCE_HOTWORD, ל-ContentCaptureService או לאפליקציות שמחזיקות בתפקידים שמפורטים בקטע 9.1 עם מזהה CDD‏ [C-4-X].
‫[9.8.2/A-1-2] אסור להסתיר את אינדיקטור המיקרופון באפליקציות מערכת שיש להן ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמש.
‫[9.8.2/A-1-3] חובה לספק למשתמש אפשרות להפעיל או להשבית את המיקרופון באפליקציית ההגדרות.

אם הטמעות של מכשירים לרכב מצהירות על android.hardware.camera.any:

[9.8.2/A-2-1] חובה להציג את אינדיקטור גישה למצלמה כשמצלמה ניגשת לנתונים בשידור חי, אבל לא כשמצלמה ניגשת רק לאפליקציות שמחזיקות בתפקידים כפי שמוגדר בסעיף 9.1 הרשאות עם מזהה CDD‏ [C-4-X].
[9.8.2/A-2-2] אסור להסתיר את אינדיקטור גישה למצלמה באפליקציות מערכת שיש להן ממשקי משתמש גלויים או אינטראקציית משתמש ישירה.
‫[9.8.2/A-2-3] חובה לספק למשתמש אפשרות להפעלה או להשבתה של המצלמה באפליקציית ההגדרות.
‫[9.8.2/A-2-4] חובה להציג את האפליקציות האחרונות והפעילות באמצעות מצלמה כפי שמוחזר מ-PermissionManager.getIndicatorAppOpUsageData(), יחד עם כל הודעות השיוך שקשורות אליהן.

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

‫[9/A-0-1] חובה להצהיר על התכונה android.hardware.security.model.compatible.
‫[9.11/A-0-1] חובה לגבות את ההטמעה של מאגר המפתחות באמצעות סביבת ביצוע מבודדת.
‫[9.11/A-0-2] חובה להטמיע אלגוריתמים קריפטוגרפיים מסוג RSA,‏ AES,‏ ECDSA ו-HMAC ופונקציות גיבוב מסוג MD5,‏ SHA-1 ו-SHA-2 כדי לתמוך בצורה תקינה באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בקרנל ומעליו. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד במצב ליבה או במרחב משתמשים יכול לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA. פרויקט הקוד הפתוח של Android‏ (AOSP) עומד בדרישה הזו באמצעות ההטמעה של Trusty, אבל יש גם אפשרויות חלופיות: פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת שנבדקה על ידי צד שלישי של בידוד מתאים שמבוסס על היפר-ויז'ור.
‫[9.11/A-0-3] חובה לבצע את האימות במסך הנעילה בסביבת ביצוע מבודדת, ורק אם האימות הצליח, לאפשר את השימוש במפתחות שקשורים לאימות. פרטי הכניסה במסך הנעילה צריכים להיות מאוחסנים באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות במסך הנעילה. פרויקט הקוד הפתוח של Android מספק את שכבת ההפשטה של החומרה (HAL) של Gatekeeper ואת Trusty, שאפשר להשתמש בהם כדי לעמוד בדרישה הזו.
‫[9.11/A-0-4] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה של האימות מוגן על ידי חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. אסור להשתמש במפתחות החתימה של האימות כמזהי מכשיר קבועים.

הערה: כדי לעמוד בדרישה הזו, אתם צריכים לשתף את אותו מפתח אישור עבור מק"ט מסוים, אלא אם יוצרו לפחות 100,000 יחידות של אותו מק"ט. אם מיוצרות יותר מ-100,000 יחידות של אותו מק"ט, אפשר להשתמש במפתח אחר לכל קבוצה של 100,000 יחידות לאחר מכן. לחלופין, אפשר להשתמש בפתרון Remote Key Provisioning (הקצאת מפתחות מרחוק) כדי להקצות למכשיר מפתחות אימות לזמן קצר.

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

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

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

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

‫Perfetto
- ‫[6.1/A-0-1] חובה לחשוף קובץ בינארי למשתמש של מעטפת הפקודות, ששורת הפקודה שלו תואמת למסמכי התיעוד של Perfecto./system/bin/perfetto
- ‫[6.1/A-0-2] קובץ ה-binary של perfetto חייב לקבל כקלט הגדרת protobuf שתואמת לסכימה שמוגדרת במאמרי העזרה של perfetto.
- ‫[6.1/A-0-3] קובץ ה-binary של perfetto חייב לכתוב כפלט עקבות של protobuf שתואמים לסכימה שמוגדרת במסמכי התיעוד של perfetto.
- ‫[6.1/A-0-4] חובה לספק, באמצעות קובץ הבינארי של perfetto, לפחות את מקורות הנתונים שמתוארים במסמכי התיעוד של perfetto.
- ‫[6.1/A-0-5] שירות ה-daemon של perfetto traced חייב להיות מופעל כברירת מחדל (מאפיין המערכת persist.traced.enable).

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

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

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

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

2.6.1. חומרה

Gyroscope

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

‫[7.3.4/Tab-1-1] המכשיר חייב להיות מסוגל למדוד שינויים בהתמצאות במרחב עד 1,000 מעלות לשנייה.

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

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

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

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

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

2.6.2. מודל אבטחה

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

ראו סעיף [9.11].

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

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

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

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

2.6.2. תוכנה

[3.2.3.1/Tab-0-1] חובה לבצע טעינה מראש של אפליקציה אחת או יותר או של רכיבי שירות עם handler של Intent, לכל דפוסי מסנני ה-Intent הציבוריים שמוגדרים על ידי ה-Intent הבאים של האפליקציה שמפורטים כאן.

3. תוכנה

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

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

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

‫[C-0-1] חובה לספק הטמעות מלאות, כולל כל ההתנהגויות המתועדות, של כל API מתועד שנחשף על ידי Android SDK או כל API שמסומן בסמן '‎@SystemApi' בקוד המקור של Android במעלה הזרם.
‫[C-0-2] חובה לתמוך בכל המחלקות, השיטות והרכיבים המשויכים שסומנו באמצעות ההערה TestApi ‏ (@TestApi) או לשמור אותם
[C-0-3] אסור להשמיט ממשקי API מנוהלים, לשנות ממשקי API או חתימות, לחרוג מההתנהגות המתועדת או לכלול בלי תפעול (no-ops), אלא אם מותר לעשות זאת באופן ספציפי בהגדרת התאימות הזו.
‫[C-0-4] חובה להשאיר את ממשקי ה-API ולפעול בצורה סבירה, גם אם מושמטות תכונות חומרה מסוימות שעבורן Android כולל ממשקי API. בקטע 7 מפורטות הדרישות הספציפיות לתרחיש הזה.
‫[C-0-5] אסור לאפשר לאפליקציות של צד שלישי להשתמש בממשקים שאינם SDK, שמוגדרים כשיטות ושדות בחבילות של שפת Java שנמצאות בנתיב המחלקה של אתחול ב-AOSP, ושלא מהווים חלק מה-SDK הציבורי. המידע הזה כולל ממשקי API עם ההערה @hide אבל לא עם @SystemAPI, כפי שמתואר במסמכי ה-SDK, וגם חברים פרטיים בכיתה וחברים בכיתה שמוגבלים לחבילה.
‫[C-0-6] חובה לשלוח עם כל ממשק שאינו SDK באותן רשימות מוגבלות שסופקו באמצעות הדגלים הזמניים והדגלים של רשימת החסימה בנתיב prebuilts/runtime/appcompat/hiddenapi-flags.csv לכל ענף של רמת API מתאימה ב-AOSP.
‫[C-0-7] חובה לתמוך במנגנון העדכון הדינמי של ההגדרה החתומה כדי להסיר ממשקים שאינם SDK מרשימה מוגבלת על ידי הטמעת הגדרה חתומה בכל חבילת APK, באמצעות המפתחות הציבוריים הקיימים ב-AOSP.

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

‫[C-0-8] אסור לתמוך בהתקנת אפליקציות שמטרגטות רמת API נמוכה מ-24 26.

3.1.1. תוספים ל-Android

מערכת Android תומכת בהרחבת ממשק ה-API המנוהל של רמת API מסוימת על ידי עדכון גרסת התוסף של אותה רמת API. ‫android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) API מחזיר את גרסת התוסף של apiLevel שסופקה, אם יש תוספים לרמת ה-API הזו.

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

‫[C-0-1] חובה לטעון מראש את ההטמעה של AOSP של הספרייה המשותפת ExtShared והשירותים ExtServices עם גרסאות שגדולות או שוות לגרסאות המינימליות שמותרות לכל רמת API. לדוגמה, הטמעות של מכשירי Android מגרסה 7.0 ומעלה, שפועלת בהם רמת API‏ 24, חייבות לכלול לפחות גרסה 1.
‫[C-0-2] הפונקציה חייבת להחזיר רק מספר גרסה תקין של התוסף שהוגדר על ידי AOSP.
‫[C-0-3] המכשיר חייב לתמוך בכל ממשקי ה-API שמוגדרים בגרסאות התוסף שמוחזרות על ידי android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) באותו אופן שבו נתמכים ממשקי API מנוהלים אחרים, בהתאם לדרישות שמפורטות בקטע 3.1.

3.1.2. ספריית Android

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

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

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

3.2. תאימות API רכה

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

3.2.1. הרשאות

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

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

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

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

פרמטר	פרטים
VERSION.RELEASE	הגרסה של מערכת Android שפועלת כרגע, בפורמט קריא (לבני אדם). בשדה הזה צריך להזין אחת ממחרוזות הערכים שמוגדרות במחרוזות גרסה מותרות ל-Android 17.
גרסת ה-SDK	הגרסה של מערכת Android שפועלת כרגע, בפורמט שנגיש לקוד אפליקציה של צד שלישי. ב-Android 17, השדה הזה חייב להכיל את הערך השלם 17_INT.
VERSION.SDK&lowbar;INT	הגרסה של מערכת Android שפועלת כרגע, בפורמט שנגיש לקוד אפליקציה של צד שלישי. ב-Android 17, השדה הזה חייב להכיל את הערך השלם 17&lowbar;INT.
VERSION.INCREMENTAL	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמציין את הגרסה הספציפית של מערכת Android שפועלת כרגע, בפורמט שקריא לבני אדם. אסור להשתמש באותו ערך עבור גרסאות שונות שזמינות למשתמשי קצה. ‫ בדרך כלל משתמשים בשדה הזה כדי לציין את מספר Build או את המזהה של השינוי בניהול הגרסאות ששימש ליצירת הגרסה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט שניתן להדפסה, ולהתאים לביטוי הרגולרי `^[^ :\/~]+$`.
משחקי לוח	ערך שנבחר על ידי מי שמטמיע את המכשיר ומזהה את החומרה הפנימית הספציפית שבה נעשה שימוש במכשיר, בפורמט שקריא לבני אדם. אפשר להשתמש בשדה הזה כדי לציין את הגרסה הספציפית של הלוח שמפעיל את המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי `^[a-zA-Z0-9_-]+$`.
מותג	ערך שמשקף את שם המותג שמשויך למכשיר כפי שהוא מוכר למשתמשי הקצה. הערך צריך להיות בפורמט שניתן לקריאה על ידי בני אדם, ולייצג את יצרן המכשיר או את מותג החברה שמשווקת את המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי `^[a-zA-Z0-9_-]+$`.
SUPPORTED&lowbar;ABIS	השם של סט הפקודות (סוג ה-CPU + מוסכמת ה-ABI) של קוד מקורי. ראו סעיף 3.3. ‫Native API Compatibility.
SUPPORTED&lowbar;32&lowbar;BIT&lowbar;ABIS	השם של סט הפקודות (סוג ה-CPU + מוסכמת ה-ABI) של קוד מקורי. ראו סעיף 3.3. ‫Native API Compatibility.
SUPPORTED&lowbar;64&lowbar;BIT&lowbar;ABIS	השם של סט הפקודות השני (סוג ה-CPU + מוסכמת ה-ABI) של קוד Native. ראו סעיף 3.3. תאימות ל-API מקורי.
CPU&lowbar;ABI	השם של סט הפקודות (סוג ה-CPU + מוסכמת ה-ABI) של קוד מקורי. ראו סעיף 3.3. ‫Native API Compatibility.
CPU&lowbar;ABI2	השם של סט הפקודות השני (סוג ה-CPU + מוסכמת ה-ABI) של קוד Native. ראו סעיף 3.3. תאימות ל-API מקורי.
מכשיר	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם הפיתוח או את שם הקוד שמזהה את ההגדרה של תכונות החומרה והעיצוב התעשייתי של המכשיר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי `^[a-zA-Z0-9_-]+$`. אסור לשנות את שם המכשיר הזה במהלך חיי המוצר.
טביעת אצבע	מחרוזת שמזהה את הגרסה הזו באופן ייחודי. הוא צריך להיות קריא לאנשים במידה סבירה. היא חייבת להיות בפורמט הבא: ‪$(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) לדוגמה: acme/myproduct/ mydevice:17/LMYXX/3359:userdebug/test-keys טביעת האצבע לא יכולה לכלול תווי רווח לבן. הערך של השדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט.
חומרה	השם של החומרה (משורת הפקודה של ליבת המערכת או מ-‎ /proc). הוא צריך להיות קריא לאנשים. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי `^[a-zA-Z0-9_-]+$`.
מארח	מחרוזת שמזהה באופן ייחודי את המארח שעליו נוצר ה-build, בפורמט קריא לאנשים. אין דרישות לגבי הפורמט הספציפי של השדה הזה, אבל אסור שהערך שלו יהיה null או מחרוזת ריקה ("").
מזהה	מזהה שנבחר על ידי מי שמטמיע את המכשיר כדי להתייחס לגרסה ספציפית, בפורמט קריא לאנשים. הערך של השדה הזה יכול להיות זהה לערך של android.os.Build.VERSION.INCREMENTAL, אבל הוא צריך להיות בעל משמעות מספקת כדי שמשתמשי הקצה יוכלו להבחין בין גרסאות תוכנה שונות. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט, ולהתאים לביטוי הרגולרי `^[a-zA-Z0-9._-]+$`.
יצרן	השם המסחרי של יצרן הציוד המקורי (OEM) של המוצר. אין דרישות לגבי הפורמט הספציפי של השדה הזה, חוץ מהדרישה שהוא לא יכול להיות null או מחרוזת ריקה (""). אסור לשנות את השדה הזה במהלך מחזור החיים של המוצר.
SOC&lowbar;MANUFACTURER	השם המסחרי של יצרן המערכת הראשית על שבב (SOC) שמשמש במוצר. במכשירים עם אותו יצרן של SOC צריך להשתמש באותו ערך קבוע. צריך לפנות ליצרן ה-SOC כדי לקבל את הקבוע הנכון לשימוש. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט, חייב להתאים לביטוי הרגולרי `^([0-9A-Za-z ]+)`, לא יכול להתחיל או להסתיים ברווח לבן, ולא יכול להיות שווה ל-"unknown". אסור לשנות את השדה הזה במהלך חיי המוצר.
SOC&lowbar;MODEL	שם הדגם של המערכת הראשית על שבב (SOC) שמשמשת במוצר. במכשירים עם אותו מודל SOC צריך להשתמש באותו ערך קבוע. צריך לפנות ליצרן ה-SOC כדי לקבל את הקבוע הנכון לשימוש. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט, להתאים לביטוי הרגולרי `^([0-9A-Za-z ._/+-]+)$`, לא להתחיל או להסתיים ברווח ולא להיות שווה ל-unknown. אסור לשנות את הערך של השדה הזה במהלך חיי המוצר.
MODEL	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם המכשיר כפי שהוא מוצג למשתמש הקצה. השם הזה צריך להיות זהה לשם שמשמש לשיווק המכשיר ולמכירתו למשתמשי קצה. אין דרישות לגבי הפורמט הספציפי של השדה הזה, אבל הוא לא יכול להיות null או מחרוזת ריקה (""). מומלץ מאוד לא לשנות את השדה הזה במהלך חיי המוצר.
מוצר	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמכיל את שם הפיתוח או את שם הקוד של המוצר הספציפי (מק"ט), שחייב להיות ייחודי באותו מותג. חייב להיות קריא לבני אדם, אבל לא בהכרח מיועד לצפייה של משתמשי קצה. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי `^[a-zA-Z0-9_-]+$`. שם המוצר לא יכול להשתנות במהלך חיי המוצר.
ODM&lowbar;SKU	ערך אופציונלי שנבחר על ידי מי שמטמיע את המכשיר, שמכיל מק"ט (מספר קטלוגי) שמשמש למעקב אחרי תצורות ספציפיות של המכשיר, למשל, כל הציוד ההיקפי שנכלל במכשיר כשהוא נמכר. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי `^([0-9A-Za-z.,_-]+)$`.
SERIAL	חייבת להחזיר את הערך UNKNOWN.
תגים	רשימה מופרדת בפסיקים של תגים שנבחרו על ידי המפתח של המכשיר כדי להבחין בין הגרסאות. התגים חייבים להיות ניתנים לקידוד כ-ASCII של 7 ביט [0x0A] ולהתאים לביטוי הרגולרי `^[a-zA-Z0-9._-]+`. בנוסף, התגים חייבים [0x0A] לכלול אחד מהערכים שמתאימים לשלוש הגדרות החתימה האופייניות של פלטפורמת Android: release-keys, ‏ dev-keys ו-test-keys.
שעה	ערך שמייצג את חותמת הזמן של מועד הבנייה.
סוג	ערך שנבחר על ידי מי שמטמיע את המכשיר, שמציין את הגדרת זמן הריצה של הגרסה. השדה הזה חייב להכיל אחד מהערכים שמתאימים לשלושת ההגדרות הטיפוסיות של זמן הריצה ב-Android: user,‏ userdebug או eng.
משתמש	שם או מזהה משתמש של המשתמש (או משתמש אוטומטי) שיצר את הגרסה. אין דרישות לגבי הפורמט הספציפי של השדה הזה, אבל אסור שהערך שלו יהיה null או מחרוזת ריקה ("").
SECURITY&lowbar;PATCH	ערך שמציין את רמת תיקון האבטחה של גרסת build. הוא חייב לציין שהגרסה לא פגיעה בשום צורה לבעיות שמתוארות בחדשות האבטחה הציבוריות של Android עד למועד שנקבע. התאריך צריך להיות בפורמט [YYYY-MM-DD], בהתאם למחרוזת מוגדרת שמתועדת בחדשות האבטחה הציבוריות של Android או ב ייעוץ בנושא אבטחה של Android. לדוגמה: ‎2015-11-01.
BASE&lowbar;OS	ערך שמייצג את הפרמטר FINGERPRINT של ה-build, שהוא זהה ל-build הזה בכל המובנים, למעט התיקונים שסופקו בעדכון האבטחה ל-Android לציבור. היא חייבת לדווח על הערך הנכון, ואם גרסה כזו לא קיימת, לדווח על מחרוזת ריקה ("").
BOOTLOADER	ערך שנבחר על ידי מי שמטמיע את המכשיר ומזהה את הגרסה הספציפית של תוכנת האתחול הפנימית שנעשה בה שימוש במכשיר, בפורמט שקריא לאנשים. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII של 7 ביט ולהתאים לביטוי הרגולרי `^[a-zA-Z0-9._-]+$`.
getRadioVersion()	חייב להיות ערך שנבחר על ידי המפתח של המכשיר (או ערך שמוחזר על ידי המכשיר) שמזהה את הגרסה הספציפית של הרדיו או המודם הפנימיים שנעשה בהם שימוש במכשיר, בפורמט שקריא לבני אדם. אם למכשיר אין רדיו או מודם פנימיים, הוא חייב להחזיר NULL. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי `^[a-zA-Z0-9._-,]+$`.
getSerial()‎	חייב להיות (או להחזיר) מספר סידורי של חומרה, שחייב להיות זמין וייחודי במכשירים עם אותו דגם ואותו יצרן. הערך בשדה הזה חייב להיות ניתן לקידוד כ-ASCII בן 7 ביט ולהתאים לביטוי הרגולרי `^[a-zA-Z0-9]+$`.
STRONGBOX&lowbar;MANUFACTURER	השם המסחרי של יצרן שבב StrongBox שמשמש במוצר. הספק של StrongBox מספק את הקבוע הנכון. במכשירים עם אותו ספק StrongBox צריך להשתמש באותו ערך קבוע. הערך בשדה הזה חייב להתאים לביטוי הרגולרי `^([0-9A-Za-z ]+)` ואסור להיות שווה ל-"unsupported". השדה הזה לא יכול להשתנות במהלך חיי המוצר.
STRONGBOX&lowbar;MODEL	שם הדגם של שבב StrongBox שמשמש במוצר. הספק של StrongBox מספק את הקבוע הנכון. מכשירים עם אותו ספק StrongBox צריכים להשתמש באותו ערך קבוע. הערך בשדה הזה חייב להתאים לביטוי הרגולרי `^([0-9A-Za-z ._/+-]+)$` ואסור להיות שווה ל-"unsupported". אסור לשנות את השדה הזה במהלך חיי המוצר.

‫3.2.3. תאימות לכוונת החיפוש

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

‫Android intents מאפשרים לרכיבי אפליקציה לבקש פונקציונליות מרכיבי Android אחרים. פרויקט Android upstream כולל רשימה של אפליקציות שמיישמות כמה תבניות של כוונות כדי לבצע פעולות נפוצות.

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

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

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

‫3.2.3.2. החלטה לגבי Intent

‫[C-0-1] מכיוון ש-Android היא פלטפורמה ניתנת להרחבה, הטמעות של מכשירים חייבות לאפשר לאפליקציות של צד שלישי לבטל כל תבנית של Intent שמפנה אל סעיף 3.2.3.1, למעט הגדרות. ההטמעה של קוד פתוח ב-Android מאפשרת זאת כברירת מחדל.
‫[C-0-2] אסור ליצרני מכשירים לצרף הרשאות מיוחדות לשימוש של אפליקציות מערכת בדפוסי הכוונות האלה, או למנוע מאפליקציות של צד שלישי לבצע קישור לדפוסים האלה ולהשתלט עליהם. האיסור הזה כולל, בין היתר, השבתה של ממשק המשתמש 'בוחר האפליקציות' שמאפשר למשתמש לבחור בין כמה אפליקציות שכולן מטפלות באותו דפוס כוונות.
‫[C-0-3] הטמעות של מכשירים חייבות לספק למשתמשים ממשק משתמש לשינוי פעילות ברירת המחדל של כוונות.
עם זאת, יכול להיות שהטמעות של מכשירים יספקו פעילויות ברירת מחדל לתבניות URI ספציפיות (לדוגמה, http://play.google.com) אם פעילות ברירת המחדל מספקת מאפיין ספציפי יותר ל-URI של הנתונים. לדוגמה, תבנית של מסנן Intent שמציינת את URI הנתונים 'http://www.android.com' היא ספציפית יותר מתבנית ה-Intent הבסיסית של הדפדפן עבור 'http://'.

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

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

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

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

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

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

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

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

‫3.2.3.5. הפעלת כוונות מותנית באפליקציות

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

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

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

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

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

‫[C-2-1] חובה לספק תפריט הגדרות שיפעיל את ה-Intent‏ android.provider.Telephony.ACTION_CHANGE_DEFAULT להצגת תיבת דו-שיח לשינוי אפליקציית ברירת המחדל ל-SMS.
‫[C-2-2] המכשיר חייב לכבד את הכוונה android.telecom.action.CHANGE_DEFAULT_DIALER להציג תיבת דו-שיח שתאפשר למשתמש לשנות את אפליקציית הטלפון שמוגדרת כברירת מחדל.
- חובה להשתמש בממשק המשתמש של אפליקציית הטלפון שנבחרה על ידי המשתמש כברירת מחדל לשיחות נכנסות ויוצאות, למעט שיחות חירום, שבהן נעשה שימוש באפליקציית הטלפון שהותקנה מראש.
‫[C-2-3] חובה לכבד את הכוונה android.telecom.action.CHANGE_PHONE_ACCOUNTS כדי לספק למשתמש אפשרות להגדיר את ConnectionServices שמשויך ל-PhoneAccounts, וגם חשבון טלפון שמוגדר כברירת מחדל שספק שירותי הטלקומוניקציה ישתמש בו כדי לבצע שיחות יוצאות. ההטמעה של AOSP עומדת בדרישה הזו באמצעות הכללת תפריט 'אפשרויות לחשבונות לביצוע שיחות' בתפריט ההגדרות 'שיחות'.
‫[C-2-4] חובה לאפשר android.telecom.CallRedirectionService לאפליקציה עם התפקיד android.app.role.CALL_REDIRECTION.
‫[C-2-5] חובה לספק למשתמש אפשרות לבחור אפליקציה עם התפקיד android.app.role.CALL_REDIRECTION.
‫[C-2-6] חובה לכבד את ה-Intents‏ android.intent.action.SENDTO ו-android.intent.action.VIEW ולספק פעילות לשליחה או להצגה של הודעות SMS.
‫[C-SR-1] מומלץ מאוד לכבד את ה-Intents‏ android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW & android.intent.action.DIAL עם אפליקציית חיוג שנטענה מראש שיכולה לטפל ב-Intents האלה ולספק מילוי כפי שמתואר ב-SDK.

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

‫[C-3-1] חובה לכבד את כוונת android.settings.NFC_PAYMENT_SETTINGS להציג תפריט הגדרות של אפליקציית ברירת מחדל לתשלום בטאץ'.
‫[C-3-2] חובה לכבד את כוונת android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT כדי להציג פעילות שפותחת תיבת דו-שיח שבה המשתמש מתבקש לשנות את שירות ברירת המחדל של הדמיית כרטיס לקטגוריה מסוימת, כפי שמתואר ב-SDK.

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

‫[C-4-1] האפליקציה חייבת לכבד את מנגנוני ה-Intent האלה android.nfc.action.NDEF_DISCOVERED,‏ android.nfc.action.TAG_DISCOVERED ו-android.nfc.action.TECH_DISCOVERED, כדי להציג פעילות שתואמת לציפיות המפתחים לגבי מנגנוני ה-Intent האלה, כפי שמתואר ב-SDK.

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

‫[C-5-1] חובה לכבד את כוונת 'android.bluetooth.adapter.action.REQUEST_ENABLE' ולהציג פעילות מערכת כדי לאפשר למשתמש להפעיל את ה-Bluetooth.
‫[C-5-2] חובה לכבד את ה-intent‏ 'android.bluetooth.adapter.action.REQUEST_DISCOVERABLE' ולהציג פעילות מערכת שמבקשת מצב גלוי.

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

‫[C-6-1] האפליקציה חייבת להטמיע פעילות שתגיב לאינטנט ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS. במקרים של הטמעות עם UI_MODE_TYPE_NORMAL, הפעילות הזו חייבת להיות פעילות שבה המשתמש יכול להעניק לאפליקציה גישה להגדרות של מדיניות 'נא לא להפריע', או לדחות את הגישה.

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

‫[C-7-1] חובה לספק מנגנון שנגיש למשתמשים להוספה ולהגדרה של שיטות קלט מצד שלישי בתגובה לכוונת android.settings.INPUT_METHOD_SETTINGS.

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

‫[C-8-1] חובה לכבד את הכוונה של android.settings.ACCESSIBILITY_SETTINGS לספק מנגנון נגיש למשתמש להפעלה ולהשבתה של שירותי הנגישות של צד שלישי לצד שירותי הנגישות שנטענו מראש.

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

‫[C-9-1] חובה להטמיע את ממשקי ה-API של Intent‏ Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI כפי שמתואר במסמכי התיעוד של ה-SDK.

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

‫[C-10-1] חובה לספק ממשק משתמש בהגדרות שמטפל ב-intent‏ Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, כדי לאפשר למשתמשים להוסיף אפליקציות לרשימת ההיתרים או להסיר אפליקציות ממנה.

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

‫[C-11-1] חובה להגדיר פעילות שמטפלת ב-intent‏ Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, אבל אפשר להטמיע אותה כפעולה שלא עושה כלום.

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

‫[C-12-3] חובה לטפל ב-intents הבאים, וחובה לאפשר רק לאפליקציות Android שהותקנו מראש לטפל בהם: MediaStore.ACTION_IMAGE_CAPTURE,‏ MediaStore.ACTION_IMAGE_CAPTURE_SECURE ו-MediaStore.ACTION_VIDEO_CAPTURE, כפי שמתואר במסמך ה-SDK.

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

‫[C-13-1] המכשיר חייב לכבד את הכוונה android.app.action.ADD_DEVICE_ADMIN להפעיל ממשק משתמש כדי להוסיף את האדמין של המכשיר למערכת (או לאפשר למשתמש לדחות את ההוספה).
‫[C-13-2] חובה לכבד את הכוונות android.app.action.PROVISION_MANAGED_PROFILE,‏ android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD,‏ android.app.action.SET_NEW_PASSWORD ו-android.app.action.START_ENCRYPTION, ולכלול פעילות שתספק את המימוש של הכוונות האלה כפי שמתואר ב-SDK כאן.

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

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

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

[C-SR-2] מומלץ מאוד לספק מנגנון שנגיש למשתמשים כדי להעניק או לבטל גישה לנתוני השימוש בתגובה ל-Intent‏ android.settings.ACTION_USAGE_ACCESS_SETTINGS עבור אפליקציות שמצהירות על ההרשאה android.permission.PACKAGE_USAGE_STATS.

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

‫[C-15-1] עדיין חייבת להיות פעילות שמטפלת בתבנית intent‏ android.settings.ACTION_USAGE_ACCESS_SETTINGS, אבל היא חייבת להיות מוטמעת כפעולה שלא עושה כלום, כלומר שתהיה לה התנהגות שוות ערך לזו שמתרחשת כשהמשתמש מסרב לתת גישה.

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

‫[C-16-1] חובה להציג קישורים כאלה לכל שירותי המילוי האוטומטי המותקנים.

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

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

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

‫[C-SR-3] מומלץ מאוד לכבד את מנגנוני ה-Intent ‏android.intent.action.TTS_SERVICE,‏ android.speech.tts.engine.INSTALL_TTS_DATA ו-android.speech.tts.engine.GET_SAMPLE_TEXT. צריך להגדיר פעילות שתספק את המידע הנדרש למנגנוני ה-Intent האלה, כפי שמתואר ב-SDK כאן.

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

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

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

‫[C-19-1] חובה להטמיע את NfcAdapter.ACTION_TRANSACTION_DETECTED Intent API (כ-EVT_TRANSACTION כפי שמוגדר במפרט הטכני של GSM Association‏ TS.26 – דרישות לטלפונים עם NFC).

‫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] חובה להסתיר תוכן בצורה מאובטחת בכל המסכים כשהמכשיר נעול באמצעות מסך נעילה מאובטח, אלא אם האפליקציה בוחרת להציג תוכן מעל מסך הנעילה באמצעות Activity#setShowWhenLocked() API.
צריך לכלול android.content.res.Configuration שמתאים לתצוגה הזו כדי שהאפליקציה תוצג, תפעל כמו שצריך ותישאר תואמת אם פעילות מופעלת בתצוגה המשנית.

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

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

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

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

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

3.3.1. Application Binary Interfaces

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

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

‫[C-0-1] חובה שתהיה תאימות לאחד או יותר מממשקי Android NDK ABI שהוגדרו.
‫[C-0-2] חובה לכלול תמיכה בקוד שפועל בסביבה המנוהלת כדי להתקשר לקוד Native, באמצעות הסמנטיקה הרגילה של Java Native Interface ‏ (JNI).
‫[C-0-3] חייבת להיות תואמת לקוד המקור (כלומר, תואמת לכותרת) ותואמת לקובץ הבינארי (לממשק ABI) לכל ספרייה נדרשת ברשימה שבהמשך.
‫[C-0-5] חובה לדווח בצורה מדויקת על ממשק הבינארי של האפליקציה (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 (אין יותר תמיכה כיעד ב-NDK)
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
- riscv64
‫[C-0-7] חובה לספק את כל הספריות הבאות, שמספקות ממשקי API מקוריים, לאפליקציות שכוללות קוד Native:
- ‫libaaudio.so (תמיכה באודיו מקורי של AAudio)
- ‫libamidi.so (תמיכה מקומית ב-MIDI, אם התכונה android.software.midi מוצהרת כפי שמתואר בקטע 5.9)
- ‫libandroid.so (תמיכה בפעילות Native ב-Android)
- libc (ספריית C)
- libcamera2ndk.so
- ‫libdl (מקשר דינמי)
- ‫libEGL.so (ניהול מקורי של משטחי OpenGL)
- ‫libGLESv1_CM.so‏ (OpenGL ES 1.x)
- ‫libGLESv2.so (OpenGL ES 2.0)
- ‫libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (רישום ביומן ב-Android)
- ‫libmediandk.so (תמיכה בממשקי API מקוריים של מדיה)
- ‫libm (ספריית מתמטיקה)
- 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] אסור לחשוף ספריות Native אחרות שהוטמעו וסופקו ב-AOSP כספריות מערכת, לאפליקציות של צד שלישי שמיועדות לרמת API 24 ומעלה, כי הן שמורות.
‫[C-0-11] חובה לייצא את כל הסמלים של פונקציות OpenGL ES 3.1 ו-Android Extension Pack, כפי שמוגדר ב-NDK, דרך ספריית libGLESv3.so. שימו לב: כל הסמלים חייבים להיות נוכחים, אבל בקטע 7.1.4.1 מפורטים הדרישות לגבי המקרים שבהם נדרש יישום מלא של כל הפונקציות התואמות.
‫[C-0-12] חובה לייצא סמלי פונקציות עבור פונקציית הליבה של Vulkan 1.1, וגם את התוספים 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.

שימו לב שבגרסאות עתידיות של 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:, ואחריה רשימה של תכונות אופציונליות של מעבד ARMv7 שהמכשיר תומך בהן.
- ‫CPU architecture:, ואחריו מספר שלם שמתאר את ארכיטקטורת ה-ARM הנתמכת הגבוהה ביותר במכשיר (למשל, '8' למכשירי ARMv8).
‫[C-2-2] חובה לשמור תמיד על הזמינות של הפעולות הבאות, גם במקרה ש-ABI מיושם בארכיטקטורת ARMv8, באמצעות תמיכה מקומית במעבד או באמצעות אמולציה של תוכנה:
- הוראות ל-SWP ול-SWPB.
- פעולות מחסום של CP15ISB,‏ CP15DSB ו-CP15DMB.
‫[C-2-3] חובה לכלול תמיכה בתוסף Advanced SIMD (שנקרא גם NEON).

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

3.4.1. תאימות ל-WebView

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

‫[C-1-1] חובה לדווח על android.software.webview.
‫[C-1-2] חובה להשתמש בגרסת ה-build של פרויקט Chromium מתוך פרויקט המקור הפתוח של Android ב-Android 17 branch לצורך הטמעה של android.webkit.WebView API.
‫[C-1-3] מחרוזת ה-User Agent שמוחזרת על ידי WebView לאפליקציות שמטרגטות SDK ברמה 36 ומטה צריכה להיות בפורמט הבא:

Mozilla/5.0 (Linux; Android $(VERSION); \[$(MODEL)\] \[Build/$(BUILD)\]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- הערך של המחרוזת $(VERSION) חייב להיות זהה לערך של android.os.Build.VERSION.RELEASE.
- מחרוזת $(MODEL) יכולה להיות ריקה, אבל אם היא לא ריקה, הערך שלה חייב להיות זהה לערך של android.os.Build.MODEL.
- אפשר להשמיט את המחרוזת Build/$(BUILD), אבל אם היא מופיעה, היא חייבת להיות זהה לערך של android.os.Build.ID.$(BUILD)
- הערך של המחרוזת $(CHROMIUM_VER) חייב להיות הגרסה של Chromium בפרויקט המקור הפתוח של Android.
- יכול להיות שהטמעות של מכשירים לא יכללו את המילה Mobile במחרוזת של סוכן המשתמש.
רכיב WebView צריך לכלול תמיכה בכמה שיותר תכונות של HTML5, ואם הוא תומך בתכונה מסוימת, הוא צריך להיות תואם למפרט HTML5.
‫[C-1-4] חובה להציג את התוכן שסופק או את התוכן של כתובת ה-URL המרוחקת בתהליך ששונה מהאפליקציה שיוצרת את מופע ה-WebView. תהליך הרינדור הנפרד חייב להיות בעל הרשאות נמוכות יותר, לפעול כמזהה משתמש נפרד, לא להיות בעל גישה לספריית הנתונים של האפליקציה, לא להיות בעל גישה ישירה לרשת, וגישה רק לשירותי המערכת הנדרשים באמצעות Binder. ההטמעה של WebView ב-AOSP עומדת בדרישה הזו.

הערה: אם ההטמעות של המכשיר הן 32 ביט או שמצהירים על feature flag android.hardware.ram.low, הן פטורות מדרישה C-1-4.

‫[C-1-5] מחרוזת ברירת המחדל של סוכן המשתמש שמדווחת על ידי WebView עבור אפליקציות שמיועדות לרמה 37 ומעלה של SDK חייבת להיות בפורמט הבא:
```
Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) ; wv)
AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0
$(CHROMIUM_MAJOR_VER).0.0.0 Mobile Safari/537.36
```
- הערך של המחרוזת $(VERSION) חייב להיות הערך הסטטי 10.
- המחרוזת $(MODEL) חייבת להיות האות הסטטית K.
- הערך של המחרוזת $(CHROMIUM_MAJOR_VER) חייב להיות הגרסה הראשית של Chromium בפרויקט המקור הפתוח של Android.
- יכול להיות שהטמעות של מכשירים לא יכללו את המילה Mobile במחרוזת של סוכן המשתמש.

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

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

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

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

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

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

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

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

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

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

3.5.1. הגבלת אפליקציות

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

‫[C-1-1] המערכת חייבת לאפשר למשתמש לראות את רשימת האפליקציות המוגבלות.
‫[C-1-2] חובה לספק למשתמשים אפשרות להפעיל או להשבית את כל ההגבלות הקנייניות האלה בכל אפליקציה.
‫[C-1-3] אסור להחיל את ההגבלות הקנייניות האלה באופן אוטומטי ללא הוכחה להתנהגות של מערכת לא תקינה, אבל מותר להחיל את ההגבלות על אפליקציות לאחר זיהוי התנהגות של מערכת לא תקינה, כמו נעילת השהיה (wakelock) תקועה, שירותים שפועלים במשך זמן רב וקריטריונים אחרים. יכול להיות שהקריטריונים ייקבעו על ידי מפתחי המכשיר, אבל הם חייבים להיות קשורים להשפעה של האפליקציה על תקינות המערכת. אסור להשתמש בקריטריונים אחרים שלא קשורים באופן מובהק לבריאות המערכת, כמו חוסר פופולריות של האפליקציה בשוק.
‫[C-1-4] אסור להחיל באופן אוטומטי את ההגבלות הקנייניות האלה על אפליקציות כשהמשתמש השבית את ההגבלות על האפליקציות באופן ידני, ומותר להציע למשתמש להחיל את ההגבלות הקנייניות האלה.
‫[C-1-5] חובה להודיע למשתמשים אם ההגבלות הקנייניות האלה חלות על אפליקציה באופן אוטומטי. חובה לספק את המידע הזה במהלך 24 השעות שלפני החלת ההגבלות הקנייניות האלה.
‫[C-1-6] חובה להחזיר true לשיטה ActivityManager.isBackgroundRestricted()‎ עבור כל קריאות ה-API מאפליקציה.
‫[C-1-7] אסור להגביל את האפליקציה המובילה בחזית שבה המשתמש משתמש באופן מפורש.
‫[C-1-8] חובה להשעות את ההגבלות הקנייניות האלה על אפליקציה בכל פעם שמשתמש מתחיל להשתמש באפליקציה באופן מפורש, כך שהיא הופכת לאפליקציה העליונה בחזית.
‫[C-1-10] חובה לספק מסמך או אתר ציבורי וברור שמתארים איך מוחלות הגבלות קנייניות. חובה שיהיה קישור למסמך או לאתר הזה ממסמכי Android SDK, והם צריכים לכלול:
- תנאים להפעלת הגבלות קנייניות.
- מהן ההגבלות שאפשר להחיל על אפליקציה ואיך עושים את זה.
- איך אפשר להחריג אפליקציה מהגבלות כאלה.
- איך אפליקציה יכולה לבקש פטור ממגבלות קנייניות, אם היא תומכת בפטור כזה לאפליקציות שהמשתמש יכול להתקין.

אם אפליקציה מותקנת מראש במכשיר ולא נעשה בה שימוש מפורש על ידי משתמש במשך יותר מ-30 יום, היא פטורה מהדרישות [C-1-3] ו-[C-1-5].

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

‫[C-2-1]חובה לפעול לפי ההטמעה שמתוארת במסמך הזה.

3.5.2. מצב תנומה של אפליקציות

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

‫[C-1-1] חייב לעמוד בכל הדרישות שבסעיף 3.5.1, למעט [C-1-6] ו- [C-1-3].
‫[C-1-2] חובה להחיל את ההגבלה על האפליקציה עבור משתמש רק אם יש הוכחה לכך שהמשתמש לא השתמש באפליקציה במשך תקופה מסוימת. מומלץ מאוד להגדיר את משך הזמן הזה לחודש אחד או יותר. השימוש חייב להיות מוגדר על ידי אינטראקציה מפורשת של המשתמש באמצעות UsageStats#getLastTimeVisible() API או כל פעולה שתגרום לאפליקציה לצאת ממצב של עצירה בכוח, כולל קישורי שירות, קישורי ספק תוכן, שידורים מפורשים וכו', שייעקבו על ידי API חדש בשם UsageStats#getLastTimeAnyComponentUsed().
‫[C-1-3] חובה להחיל הגבלות שמשפיעות על כל המשתמשים במכשיר רק אם יש הוכחה לכך שאף משתמש לא השתמש בחבילה במשך תקופה מסוימת. מומלץ מאוד להגדיר את משך הזמן הזה לחודש אחד או יותר.
‫[C-1-4] אסור שהאפליקציה לא תגיב לפעילויות, לקישורי שירות, לבקשות של ספקי תוכן או לשידורים מפורשים.

התרדמה של אפליקציות ב-AOSP עומדת בדרישות שלמעלה.

3.6. API Namespaces

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

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

כלומר, הם:

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

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

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

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

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

מפתחי מכשירים יכולים להוסיף ממשקי API מותאמים אישית בשפות מקומיות, מחוץ לממשקי ה-API של NDK, אבל ממשקי ה-API המותאמים אישית:

‫[C-1-1] אסור שהקוד יהיה בספריית NDK או בספרייה שבבעלות ארגון אחר, כפי שמתואר כאן.

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

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

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

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

‫[C-0-1] חובה לתמוך בפורמט המלא של Dalvik Executable ‏ (DEX) ובמפרט ובסמנטיקה של Dalvik bytecode.
‫[C-0-2] חובה להגדיר את סביבות זמן הריצה של Dalvik להקצאת זיכרון בהתאם לפלטפורמת Android upstream, וכפי שמצוין בטבלה הבאה. (הגדרות של גודל המסך וצפיפות המסך מופיעות בקטע 7.1.1).
מומלץ להשתמש ב-Android RunTime‏ (ART), בהטמעה של Dalvik Executable Format במעלה הזרם, ובמערכת לניהול חבילות של ההטמעה.
מומלץ להריץ בדיקות fuzzing במצבי ביצוע שונים ובארכיטקטורות יעד שונות כדי לוודא שהיציבות של זמן הריצה. אפשר לעיין ב-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)	‫48MB
	‫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)	‫80MB
	‫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)	‫48MB
	‫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)	‫80MB
	‫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().

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

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

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

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

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

‫[C-6-1] חובה להשתמש בהן רק כשמשתמש מפעיל אותן באופן מפורש (למשל, דרך ההגדרות או תפריט בחירת הטפט).

3.8.2. ווידג'טים

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

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

‫[C-1-1] חובה להצהיר על תמיכה בתכונת הפלטפורמה android.software.app_widgets.
‫[C-1-2] חובה לכלול תמיכה מובנית בווידג'טים של אפליקציות ולחשוף אמצעים בממשק המשתמש להוספה, להגדרה, לתצוגה מקדימה, להסרה, לצפייה ולשינוי הגודל של הווידג'טים של אפליקציות אלא אם יש חשש לגבי בטיחות המשתמש (למשל,הסחת דעת של הנהג).

‫[C-1-3] המכשיר חייב להיות מסוגל להציג ווידג'טים בגודל 4x4 ברשת בגודל רגיל. פרטים נוספים זמינים בהנחיות לעיצוב ווידג'טים לאפליקציות במסמכי התיעוד של Android SDK.

‫[C-1-4] חובה לתמוך בתצוגות מקדימות של ווידג'טים שנוצרות באופן דינמי.
‫[C-1-5] חובה לספק למשתמש אפשרות להסכים להוספת הווידג'ט באמצעות תצוגה מקדימה שבה מוצגת למשתמש בקשה לפני הוספת הווידג'ט שהאפליקציות מבקשות להוסיף באמצעות AppWidgetManager.requestPinAppWidget().
‫[C-1-6] האפליקציה חייבת לתמוך בהצמדה של ווידג'טים בתוך האפליקציה.
‫[C-1-7] חובה לדווח על true עבור AppWidgetManager.html.isRequestPinAppWidgetSupported().

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

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

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

‫3.8.3. התראות

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

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

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

‫[C-1-1] המכשיר חייב לתמוך בהתראות שמשתמשות בתכונות חומרה, כפי שמתואר במסמכי ה-SDK, ובמידה האפשרית עם חומרת ההטמעה של המכשיר. לדוגמה, אם הטמעה של מכשיר כוללת ויברטור, חובה להטמיע את ממשקי ה-API של הוויברטור בצורה נכונה. אם חסרה חומרה בהטמעה של מכשיר, חובה להטמיע את ממשקי ה-API המתאימים כבלי תפעול (no-ops). התנהגות זו מתוארת בפירוט נוסף בקטע 7.
‫[C-1-2] חובה להציג בצורה נכונה את כל המשאבים (סמלים, קובצי אנימציה וכו') שסופקו בממשקי ה-API או במדריך לסגנון הסמלים של סרגל המערכת/הסטטוס, אבל אפשר לספק חוויית משתמש חלופית להתראות, שונה מזו שסופקה בהטמעה של Android Open Source.
‫[C-1-3] חובה לכבד ולהטמיע בצורה נכונה את ההתנהגויות שמתוארות בממשקי ה-API לעדכון, להסרה ולקיבוץ של התראות.
‫[C-1-4] חובה לספק את ההתנהגות המלאה של NotificationChannel API שמתועדת ב-SDK.
‫[C-1-5] חובה לספק למשתמש אפשרות לחסימה ולשינוי של התראות מאפליקציות מסוימות של צד שלישי, לכל ערוץ ולכל חבילת אפליקציות.
‫[C-1-6] חובה לספק למשתמש אפשרות להצגת ערוצי התראות שנמחקו.
‫[C-1-7] חובה להציג בצורה נכונה את כל המשאבים (תמונות, סטיקרים, סמלים וכו') שסופקו באמצעות Notification.MessagingStyle לצד טקסט ההתראה, ללא אינטראקציה נוספת של המשתמש. לדוגמה, חובה להציג את כל המשאבים, כולל הסמלים שסופקו דרך android.app.Person בשיחה קבוצתית שהוגדרה דרך setGroupConversation.
‫[C-SR-1] מומלץ מאוד לספק למשתמשים אפשרות לשלוט בהתראות שמוצגות באפליקציות שקיבלו הרשאת גישה לנתוני ההתראות. רמת הפירוט חייבת להיות כזו שהמשתמש יוכל לשלוט בכל מאזין התראות כזה, ולבחור אילו סוגי התראות יגושרו למאזין הזה. הסוגים חייבים לכלול התראות מסוג conversations,‏ alerting,‏ silent ו-important ongoing.
[C-SR-2] מומלץ מאוד לספק למשתמשים מזמינוּת לציין אפליקציות שיוחרגו מההתראות של listener התראות ספציפי.
‫[C-SR-3] מומלץ מאוד להציג באופן אוטומטי למשתמש אמצעי נוחות לחסימת ההתראות של אפליקציית צד שלישי מסוימת בכל ערוץ ובכל חבילת אפליקציות, אחרי שהמשתמש סגר את ההתראה מספר פעמים.
צריכה להיות תמיכה בהתראות מתקדמות.
צריכה להציג חלק מההתראות בעדיפות גבוהה יותר כהתראות 'שימו לב'.
צריכה להיות למשתמש אפשרות להשהות את ההתראות.
יכול להיות שהאפליקציה תנהל רק את הנראות והתזמון של מקרים שבהם אפליקציות צד שלישי יכולות להודיע למשתמשים על אירועים חשובים, כדי לצמצם בעיות בטיחות כמו הסחת דעת של הנהג.

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

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

[C-SR-4] מומלץ מאוד לקבץ ולהציג את conversation notifications לפני התראות שאינן שיחות, למעט התראות על שירות שפועל בחזית והתראות על importance:high.

אם ההטמעות של המכשיר תומכות ב-conversation notifications והאפליקציה מספקת את הנתונים הנדרשים ל-bubbles, הן:

‫[C-SR-5] מומלץ מאוד להציג את השיחה הזו כבועה. ההטמעה של AOSP עומדת בדרישות האלה עם ממשק המשתמש של המערכת, ההגדרות וה-Launcher שמוגדרים כברירת מחדל.

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

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

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

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

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

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

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

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

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

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

‫3.8.3.3. מצב DND (נא לא להפריע) / מצב עדיפות

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

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

‫3.8.3.4. הגנה על התראות רגישות

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

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

‫[C-1-1] חובה להסתיר מידע רגיש מההתראות לפני שהוא מועבר למאזינים להתראות, אלא אם שירות המאזין הוא אחד מהשירותים הבאים:
- אפליקציות שנחתמו על ידי המערכת עם uid < 10000
- ממשק משתמש של המערכת
- קונכייה
- אפליקציה נלווית ייעודית (מוגדרת על ידי CompanionDeviceManager)
- SYSTEM_AUTOMOTIVE_PROJECTION תפקיד
- SYSTEM_NOTIFICATION_INTELLIGENCE תפקיד
- תפקיד HOME

ההטמעה של NotificationAssistantServices ב-AOSP מדגימה את הדרישות האלה ועומדת בהן. android.ext.services.notification לדוגמה.

‫3.8.4. Assist APIs

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

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

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

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

‫[C-2-2] האינטראקציה שמוגדרת להפעלת אפליקציית העזרה, כפי שמתואר בקטע 7.2.3, חייבת להפעיל את אפליקציית העזרה שנבחרה על ידי המשתמש, כלומר את האפליקציה שמטמיעה את VoiceInteractionService, או פעילות שמטפלת ב-intent‏ ACTION_ASSIST.

3.8.5. התראות וחלונות קופצים

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

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

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

3.8.6. עיצובים

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

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

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

‫[C-1-1] אסור לשנות אף אחד ממאפייני העיצוב של Holo שחשופים לאפליקציות.
‫[C-1-2] חובה לתמוך במשפחת העיצוב 'Material' ואסור לשנות אף אחד ממאפייני העיצוב Material או מהנכסים שלהם שמוצגים לאפליקציות.
[C-1-3] חובה להגדיר את משפחת הגופנים sans-serif ל-Roboto גרסה 2.x בשפות שבהן יש תמיכה ב-Roboto, או לספק למשתמש מזמינוּת לשנות את הגופן שמשמש למשפחת הגופנים sans-serif ל-Roboto גרסה 2.x בשפות שבהן יש תמיכה ב-Roboto.
‫[C-1-4] חובה ליצור לוחות צבעים דינמיים בגוונים שונים, כפי שמפורט במסמכי AOSP בנושא Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (ראו android.theme.customization.system_palette ו-android.theme.customization.theme_style).
[C-1-5] חובה ליצור פלטות דינמיות של גווני צבעים באמצעות סגנונות של ערכות צבעים שמפורטים במסמכי Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES התיעוד (ראו android.theme.customization.theme_styles), כלומר TONAL_SPOT,‏ VIBRANT,‏ EXPRESSIVE,‏ SPRITZ,‏ RAINBOW, FRUIT_SALAD ו-MONOCHROMATIC.

הצבע שמוגדר ב-"צבע המקור" משמש ליצירת פלטות דינמיות של גווני צבע כששולחים אותו עם android.theme.customization.system_palette (כפי שמתואר ב-Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).
‫[C-1-6] חייב להיות בעל ערך כרומה CAM16 של 5 או יותר.
- צריך להיות נגזר מהטפט באמצעות com.android.systemui.monet.ColorScheme#getSeedColors, שמספק כמה צבעי מקור תקינים שאפשר לבחור מתוכם.
- מומלץ להשתמש בערך 0xFF1B6EF3 אם אף אחד מהצבעים שצוינו לא עומד בדרישה של צבע המקור שצוינה למעלה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

‫3.8.9. ניהול קלט

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

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

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

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

החל מ-Android 5.0,‏ Remote Control Client API הוצא משימוש לטובת Media Notification Template, שמאפשר לאפליקציות מדיה להשתלב עם אמצעי בקרה להפעלה שמוצגים במסך הנעילה.

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

הגדרות של כוונת הגדרה של שומרי מסך מפורטות בקטע 3.2.3.5.

‫3.8.12. מיקום

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

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

‫3.8.13. יוניקוד וגופן

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

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

‫[C-1-1] חובה שתהיה אפשרות להציג את תווי האמוג'י האלה כגליף צבעוני.
‫[C-1-2] חובה לכלול תמיכה ב:
- גופן Roboto 2 עם משקלים שונים – sans-serif-thin, ‏ sans-serif-light,‏ sans-serif-medium, ‏ sans-serif-black, ‏ sans-serif-condensed,‏ sans-serif-condensed-light לשפות שזמינות במכשיר.
- כיסוי מלא של Unicode 7.0 של לטינית, יוונית וקירילית, כולל הטווחים Latin Extended A,‏ B,‏ C ו-D, וכל הגליפים בבלוק של סמלי המטבעות ב-Unicode 7.0.
[C-1-3] אסור להסיר או לשנות את NotoColorEmoji.tff בקובץ אימג' של המערכת. (מותר להוסיף גופן אמוג'י חדש כדי להחליף את האמוג'י ב-NotoColorEmoji.tff)
צריך לתמוך באמוג'י של גוון עור ושל משפחות מגוונות, כפי שמפורט בדוח הטכני של Unicode מספר 51.

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

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

‫Android כולל תמיכה בעיבוד של גופנים במיאנמר. במיאנמר יש כמה גופנים שלא תואמים ל-Unicode, שנקראים בדרך כלל Zawgyi, לצורך עיבוד שפות מיאנמר.

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

‫[C-2-1] חובה להציג טקסט עם גופן שתואם ל-Unicode כברירת מחדל; אין להגדיר גופן שלא תואם ל-Unicode כגופן ברירת מחדל, אלא אם המשתמש בוחר בו בכלי לבחירת שפה.
‫[C-2-2] המכשיר חייב לתמוך בגופן Unicode ובגופן שלא תואם ל-Unicode, אם המכשיר תומך בגופן שלא תואם ל-Unicode. גופן שלא תואם ל-Unicode לא יכול להסיר או להחליף את גופן ה-Unicode.
‫[C-2-3] חובה להציג טקסט בגופן שלא תואם ל-Unicode רק אם מצוין קוד שפה עם קוד סקריפט Qaag (למשל, my-Qaag). אי אפשר להשתמש בקודי שפה או אזור אחרים לפי תקן ISO (בין אם הם הוקצו, לא הוקצו או שמורים) כדי להתייחס לגופן במיאנמר שלא תואם ל-Unicode. מפתחי אפליקציות ויוצרי דפי אינטרנט יכולים לציין את my-Qaag כקוד השפה הייעודי, כמו שהם עושים לגבי כל שפה אחרת.

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

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

‫[C-1-1] המכשיר חייב להטמיע מצבי ריבוי חלונות כאלה בהתאם להתנהגויות האפליקציה ולממשקי ה-API שמתוארים במסמכי התיעוד של ערכת ה-SDK של Android בנושא תמיכה במצב ריבוי חלונות, ולעמוד בדרישות הבאות:
‫[C-1-2] הדרישה הוסרה ב-Android 16.
‫[C-1-3] אסור להציע מצב מסך מפוצל או מצב חלונות חופשיים אם גובה המסך קטן מ-440 dp ורוחב המסך קטן מ-440 dp.
‫[C-1-4] אסור לשנות את הגודל של פעילות לגודל קטן מ-220 dp במצבי ריבוי חלונות שאינם תמונה בתוך תמונה.

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

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

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

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

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

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

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

‫[C-4-1] חובה לתמוך במצב ריבוי חלונות.

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

[C-5-1] חובה להטמיע את הגרסה הנכונה של Window Manager Extensions רמת API כפי שמתואר בWindowManager Extensions.

‫3.8.15. מגרעת במסך

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

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

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

3.8.16. ממשק השליטה במכשירים

‫Android כולל ממשקי API של ControlsProviderService ושל Control שמאפשרים לאפליקציות של צד שלישי לפרסם אמצעי בקרה במכשיר כדי שהמשתמשים יוכלו לראות במהירות את הסטטוס ולבצע פעולות.

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

‫3.8.17. לוח

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

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

אם הטמעות במכשיר יוצרות תצוגה מקדימה שמוצגת למשתמש כשתוכן מועתק ללוח העריכה עבור פריט ClipData כלשהו שבו ClipData.getDescription().getExtras() מכיל android.content.extra.IS_SENSITIVE, הן:

‫[C-1-1] חובה לצנזר את התצוגה המקדימה שגלוי למשתמש

ההטמעה לדוגמה של AOSP עומדת בדרישות האלה של לוח העריכה.

‫3.8.18. כפתור המיקום

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

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

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

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

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

‫3.9.1. הקצאת מכשירים

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

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

‫[C-1-1] המכשיר חייב לתמוך בהרשמה של בקר מדיניות מכשיר (DPC) כאפליקציית בעלים של המכשיר, כפי שמתואר בהמשך:
- אם בהטמעה של המכשיר לא מוגדרים משתמשים או נתוני משתמשים, המכשיר:
  - ‫[C-1-5] חובה לרשום את אפליקציית ה-DPC כאפליקציית בעלי המכשיר או לאפשר לאפליקציית ה-DPC לבחור אם להפוך לבעלי המכשיר או לבעלי הפרופיל, אם המכשיר מצהיר על תמיכה בתקשורת מטווח קצר (NFC) באמצעות דגל התכונה android.hardware.nfc ומקבל הודעת NFC שמכילה רשומה עם סוג MIME‏ MIME_TYPE_PROVISIONING_NFC.
  - ‫[C-1-8] חובה לשלוח את intent‏ ACTION_GET_PROVISIONING_MODE אחרי שהפעלתם את הקצאת ההרשאות לבעלות על המכשיר, כדי שאפליקציית ה-DPC תוכל לבחור אם להפוך לבעלות על המכשיר או לבעלות על הפרופיל, בהתאם לערכים של android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, אלא אם אפשר לקבוע מההקשר שיש רק אפשרות תקפה אחת.
  - ‫[C-1-9] חובה לשלוח את כוונת ACTION_ADMIN_POLICY_COMPLIANCE לאפליקציית בעלי המכשיר אם בעלי המכשיר הוגדרו במהלך ההקצאה, ללא קשר לשיטת ההקצאה שבה נעשה שימוש. המשתמש לא יכול להמשיך באשף ההגדרה עד שאפליקציית הבעלים של המכשיר מסיימת את הפעולה.
- אם בהטמעה במכשיר יש משתמשים או נתוני משתמשים, המכשיר:
  - ‫[C-1-7] אסור לרשום יותר אפליקציות DPC כאפליקציה של בעלי המכשיר.
‫[C-1-2] הדרישה הוסרה ב-Android 15.
‫[C-2-1] הדרישה הוסרה ב-Android 15.
‫[C-2-2] הדרישה הוסרה ב-Android 15.
‫[C-2-3] הדרישה הוסרה ב-Android 15.

3.9.1.2. הקצאת פרופילים מנוהלים

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

‫[C-1-1] חובה להצהיר על android.software.device_admin וליישם את ממשקי ה-API שמאפשרים לאפליקציית בקר מדיניות מכשיר (DPC) להפוך לבעלים של פרופיל מנוהל חדש.
‫[C-1-2] הדרישה הוסרה ב-Android 16.
‫[C-1-3] חובה לספק את אמצעי הנוחות הבאים למשתמשים בהגדרות כדי לציין למשתמש מתי פונקציית מערכת מסוימת הושבתה על ידי בקר מדיניות המכשיר (DPC):
- סמל עקבי או מזמינוּת אחרת למשתמש (לדוגמה, סמל המידע של AOSP במעלה הזרם) שמייצג מצב שבו הגדרה מסוימת מוגבלת על ידי אדמין מכשיר.
- הודעת הסבר קצרה, כפי שסופקה על ידי מנהל המכשיר באמצעות setShortSupportMessage.
- הסמל של אפליקציית ה-DPC.
‫[C-1-4] חובה להפעיל את ה-handler של intent מסוג ACTION_PROVISIONING_SUCCESSFUL בפרופיל העבודה אם הוגדר בעלים של הפרופיל כשמתחילים את ההקצאה באמצעות intent מסוג android.app.action.PROVISION_MANAGED_PROFILE, וה-DPC הטמיע את ה-handler.
‫[C-1-5] חובה לשלוח שידור של ACTION_PROFILE_PROVISIONING_COMPLETE אל ה-DPC של פרופיל העבודה כשמופעלת הקצאת הרשאות על ידי intent של android.app.action.PROVISION_MANAGED_PROFILE.
‫[C-1-6] חובה לשלוח את כוונת הפעולה ACTION_GET_PROVISIONING_MODE אחרי שהפעלת ההקצאה של בעלי הפרופיל מופעלת, כדי שאפליקציית ה-DPC תוכל לבחור אם להפוך לבעלי המכשיר או לבעלי הפרופיל, אלא אם ההקצאה מופעלת על ידי כוונת הפעולה android.app.action.PROVISION_MANAGED_PROFILE.
‫[C-1-7] חובה לשלוח את הכוונה ACTION_ADMIN_POLICY_COMPLIANCE לפרופיל העבודה כשמוגדר בעלים של הפרופיל במהלך ההקצאה, ללא קשר לשיטת ההקצאה שבה נעשה שימוש, אלא אם ההקצאה מופעלת על ידי הכוונה android.app.action.PROVISION_MANAGED_PROFILE. המשתמש לא יכול להמשיך באשף ההגדרה עד שהאפליקציה Profile Owner תסיים את הפעולה.
‫[C-1-8] חובה לשלוח שידור של ACTION_MANAGED_PROFILE_PROVISIONED אל ה-DPC של הפרופיל האישי כשמוגדר בעל פרופיל, בלי קשר לשיטת ההקצאה שבה נעשה שימוש.

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

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

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

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

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

‫3.9.3. תמיכה למשתמשים מנוהלים

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

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

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

‫[C-SR-1] מומלץ מאוד להציג את אותם גילויים בנוגע להסכמה של בעלי המכשיר ב-AOSP שהוצגו בתהליך שהופעל על ידי android.app.action.PROVISION_MANAGED_DEVICE, לפני שמאפשרים להוסיף חשבונות למשתמש המשני החדש, כדי שהמשתמשים יבינו שהמכשיר מנוהל.

‫3.9.4. דרישות התפקיד לניהול מדיניות המכשירים

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

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

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

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

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

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

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

‫[C-4-1] האפליקציה חייבת להיות מותקנת מראש במכשיר.
‫[C-4-2] האפליקציה חייבת להטמיע מסנן Intent שמזהה את android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER.

‫3.9.5. מסגרת לפתרון בעיות במדיניות המכשיר

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

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

‫3.10. נגישות

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

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

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

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

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

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

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

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

‫[C-1-1] חובה לתמוך בממשקי ה-API של מסגרת ה-TTS של Android.

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

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

‫3.12. לא רלוונטי

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

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

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

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

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

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

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

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

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

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

‫3.18. אנשי קשר

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

רשומות RawContacts משויכות לAccount או מאוחסנות בו אם הערכים בעמודות ACCOUNT_NAME ו-ACCOUNT_TYPE של אנשי הקשר הגולמיים תואמים לערכים בשדות Account.name ו-Account.type של החשבון.

חשבון מקומי שמוגדר כברירת מחדל: חשבון של אנשי קשר גולמיים שמאוחסנים רק במכשיר ולא משויכים לחשבון ב-AccountManager. החשבון נוצר עם ערכי null בעמודות ACCOUNT_NAME ו-ACCOUNT_TYPE.

חשבון מקומי בהתאמה אישית: חשבון של אנשי קשר גולמיים שמאוחסנים רק במכשיר ולא משויכים לחשבון ב-AccountManager. החשבון נוצר עם ערכים שאינם null בשתי העמודות ACCOUNT_NAME ו-ACCOUNT_TYPE.

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

‫[C-SR-1] מומלץ מאוד לא ליצור חשבונות מקומיים בהתאמה אישית.

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

‫[C-1-1] הערך של ACCOUNT_NAME, של חשבון מקומי בהתאמה אישית, חייב להיות מוחזר על ידי ContactsContract.RawContacts.getLocalAccountName
‫[C-1-2] הערך ACCOUNT_TYPE של חשבון מקומי בהתאמה אישית חייב להיות מוחזר על ידי ContactsContract.RawContacts.getLocalAccountType
‫[C-1-3] אנשי קשר גולמיים שנוספו על ידי אפליקציות של צד שלישי בלי לציין חשבון, חייבים להתווסף לחשבון ברירת המחדל של אנשי הקשר במכשיר. אם חשבון ברירת המחדל של אנשי הקשר הוא DEFAULT_ACCOUNT_STATE_LOCAL או DEFAULT_ACCOUNT_STATE_NOT_SET, אנשי הקשר הגולמיים האלה חייבים להישמר בחשבון המקומי בהתאמה אישית.
‫[C-1-4] אסור להסיר אנשי קשר גולמיים שנוספו לחשבון מקומי בהתאמה אישית כשמוסיפים או מסירים חשבונות.
‫[C-1-5] פעולות מחיקה שבוצעו מול חשבון מקומי בהתאמה אישית חייבות לגרום לטיהור מיידי של אנשי הקשר הגולמיים (כאילו הפרמטר CALLER_IS_SYNCADAPTER הוגדר כ-true), גם אם הפרמטר CALLER_IS_SYNCADAPTER הוגדר כ-false או לא צוין.

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

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

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

‫[C-1-6] צריך להחזיר את החשבונות של כרטיסי ה-SIM עד ContactsContract.SimContacts.getSimAccounts.

‫3.18.2. הכלי לבחירת אנשי קשר במערכת

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

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

‫[C-1-1] אפליקציות שמטרגטות רמת API ‏37 ומעלה חייבות להטמיע את כלי הבחירה של אנשי הקשר במערכת (com.android.contactspicker).
‫[C-1-2] חובה להטמיע את הכוונה Intent.ACTION_PICK_CONTACTS.

‫3.19. הגדרות השפה

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

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

‫3.20. חוויות שימוש שמבוססות על Assistant

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

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

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

‫3.20.1. הדרישות לשידור אודיו של Assistant

אפליקציה עם ההרשאה MANAGE_ASSISTANT_AUDIO:

‫[C-0-1] חובה לאפשר שינוי של עוצמת הקול של STREAM_ASSISTANT באופן פרוגרמטי.

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

‫[C-1-1] חובה להטמיע את STREAM_ASSISTANT כזרם אודיו מופרד, ואסור להגדיר אותו ככינוי לזרם אחר.
‫[C-1-2] חובה לוודא שעוצמת הקול של הפעלת האודיו באמצעות AudioAttributes עם USAGE_ASSISTANT נשלטת על ידי STREAM_ASSISTANT.
‫[C-1-3] חובה לוודא שבאוזניות Bluetooth מסוימות, מדד עוצמת הקול STREAM_ASSISTANT נשאר זהה כשהאוזניות עוברות בין פרופילי אודיו של A2DP ו-HFP.
‫[C-1-4] חובה למנוע מכל זרם אחר מלבד STREAM_ASSISTANT לשנות את עוצמת הקול של STREAM_ASSISTANT או את ההנחתה שמוחלת על ההפעלה של USAGE_ASSISTANT, בזמן ש-MODE_ASSISTANT_CONVERSATION פעיל.
‫[C-1-5] חובה לשנות את עוצמת הקול של הסטרימינג ולא את עוצמת הקול של סטרימינג אחר, כשמשנים את עוצמת הקול באמצעות כפתורי עוצמת הקול של המכשיר או של ציוד היקפי (כמו אוזניות Bluetooth), וכשמתקיימים התנאים הבאים:STREAM_ASSISTANT
- MODE_ASSISTANT_CONVERSATION פעיל, ו
- אין התאמה אישית ספציפית לאפליקציה או הפעלה מרחוק של תוכן.
‫[C-1-6] כל שינוי בעוצמת הקול של Assistant חייב להשתקף בממשק המשתמש.

‫3.21. תמיכה בתכונות של סנכרון מכשיר נלווה

‫Android כולל תמיכה בתכונות סנכרון נתונים במכשירים משלימים.

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

‫[C-1-1] חובה להטמיע את ContextualModeManager#isModeSyncSupported() API.
‫[C-1-2] חובה לסנכרן את ההגדרה שמציינת שמצב 'נא לא להפריע' מופעל דרך הערוץ המאובטח CompanionDeviceManager באמצעות פורמט נתונים שתואם להטמעה שמוגדרת כברירת מחדל CompanionDeviceManagerService.
‫[C-1-3] חובה להפעיל את הסנכרון הזה אם ContextualModeManager#isModeSyncEnabled() מחזירה true.

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

‫[C-1-4] חובה לסנכרן את ההגדרה שמציינת שמצב טיסה מופעל דרך הערוץ המאובטח CompanionDeviceManager באמצעות פורמט נתונים שתואם להטמעה של ברירת המחדל CompanionDeviceManagerService.
‫[C-1-5] חובה להפעיל את הסנכרון הזה אם Settings.Global.AIRPLANE_MODE_SYNC מופעל.

4. תאימות של חבילות אפליקציות

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

‫[C-0-1] המכשיר חייב להיות מסוגל להתקין ולהפעיל קובצי Android‏ (‎.apk) שנוצרו על ידי הכלי aapt שכלול ב-Android SDK הרשמי.
- הדרישה שלמעלה עשויה להיות מאתגרת, ולכן מומלץ להשתמש במערכת לניהול חבילות של הטמעת ההפניה של AOSP.

‫[C-0-2] חובה לתמוך באימות קובצי ‎.apk באמצעות APK Signature Scheme v3.2,‏ APK Signature Scheme v3.1,‏ APK Signature Scheme v3,‏ APK Signature Scheme v2 ו-JAR signing.

‫[C-0-3] אסור להרחיב את הפורמטים של ‎.apk,‏ Android Manifest,‏ Dalvik bytecode או RenderScript bytecode באופן שימנע את ההתקנה וההפעלה התקינות של הקבצים האלה במכשירים תואמים אחרים.
‫[C-0-4] אסור לאפשר לאפליקציות אחרות מלבד 'המתקין הרשום' הנוכחי של החבילה להסיר את האפליקציה בשקט ללא אישור מהמשתמש, כפי שמתואר ב-SDK עבור ההרשאה DELETE_PACKAGE. היוצאים מן הכלל היחידים הם אפליקציית אימות החבילות של המערכת שמטפלת ב-intent‏ PACKAGE_NEEDS_VERIFICATION, ואפליקציית ניהול האחסון שמטפלת ב-intent‏ ACTION_MANAGE_STORAGE.
‫[C-0-5] חובה להגדיר פעילות שמטפלת באובייקט מסוג Intent‏ android.settings.MANAGE_UNKNOWN_APP_SOURCES.
‫[C-0-6] אסור להתקין חבילות של אפליקציות ממקורות לא ידועים, אלא אם האפליקציה שמבקשת את ההתקנה עומדת בכל הדרישות הבאות:
- חובה להצהיר על ההרשאה REQUEST_INSTALL_PACKAGES או להגדיר את android:targetSdkVersion ל-24 או פחות.
- המשתמש חייב להעניק הרשאה להתקנת אפליקציות ממקורות לא ידועים.
מומלץ לספק למשתמשים מזמינוּת להעניק או לבטל את ההרשאה להתקנת אפליקציות ממקורות לא מוכרים לכל אפליקציה, אבל אפשר גם לבחור ליישם את זה כפעולה שלא עושה כלום ולהחזיר RESULT_CANCELED עבור startActivityForResult(), אם ההטמעה במכשיר לא רוצה לאפשר למשתמשים לבחור. עם זאת, גם במקרים כאלה, הם צריכים להסביר למשתמש למה לא מוצגת לו אפשרות כזו.
‫[C-0-7] חובה להציג למשתמש תיבת דו-שיח עם מחרוזת האזהרה שסופקה דרך ממשק ה-API של המערכת PackageManager.setHarmfulAppWarning לפני הפעלת פעילות באפליקציה שסומנה על ידי אותו ממשק API של המערכת PackageManager.setHarmfulAppWarning כבעלת פוטנציאל לגרום נזק.
מומלץ לספק למשתמשים אפשרות לבחור אם להסיר או להפעיל אפליקציה בתיבת הדו-שיח של האזהרה.
‫[C-0-8] חובה להטמיע תמיכה במערכת קבצים מצטברת כפי שמתואר כאן.
‫[C-0-9] חייבת לתמוך באימות קובצי ‎ .apk באמצעות APK Signature Scheme v4 ו-APK Signature Scheme v4.1.

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

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

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

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

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

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

‫[C-1-4] MPEG-D USAC עם MPEG-D DRC (Extended High Efficiency AAC)

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

‫[C-3-1] מסגרות אודיו של PCM 16-bit native byte order דרך ממשק android.media.MediaCodec API.

כשמקודדים אודיו MPEG-D USAC עם MPEG-D DRC (AAC יעיל במיוחד):

‫[C-3-2] כל זרמי הביטים חייבים להכיל את קבוצות המטא-נתונים בהתאם לפרופיל של MPEG-D לשליטה בעוצמת הקול או לפרופיל של MPEG-D לשליטה בטווח הדינמי, רמה 1 ומעלה, בהתאם לתקן ISO/IEC 23003-4.

‫5.1.2. פענוח אודיו

פרטים נוספים מופיעים בקטע 5.1.3. פרטים על קודק אודיו.

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

‫[C-1-1] פרופיל MPEG-4 AAC‏ (AAC LC)
‫[C-1-2] פרופיל MPEG-4 HE AAC ‏ (AAC+)
‫[C-1-3] פרופיל MPEG-4 HE AACv2 (AAC+ משופר)
‫[C-1-4] AAC ELD (קידוד AAC עם השהיה נמוכה משופרת)
‫[C-1-5] FLAC
‫[C-1-6] MP3
‫[C-1-7] MIDI
‫[C-1-8] Vorbis
‫[C-1-9] PCM/WAVE כולל פורמטים של אודיו ברזולוציה גבוהה עד 24 ביט, תדירות דגימה של ‎192 kHz ו-8 ערוצים. הערה: הדרישה הזו היא רק לגבי פענוח, ומותר למכשיר לבצע דגימה נמוכה ומיקס נמוך במהלך שלב ההפעלה.
‫[C-1-10] Opus
[C-1-11] xHE-AAC (פרופיל HE AAC מורחב של ISO/IEC 23003-3, שכולל את פרופיל Baseline של USAC ואת פרופיל בקרת הטווח הדינמי של ISO/IEC 23003-4)

‫[C-1-12] קובץ IAMF בגרסה 1.0 שמכיל זרמי אודיו מקודדים בפורמטים AAC,‏ FLAC,‏ Opus או PCM

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

‫[C-2-1] חובה לבצע פענוח ללא מיקס דאון (לדוגמה, צריך לפענח סטרימינג של AAC 5.0 לחמישה ערוצים של PCM, וסטרימינג של AAC 5.1 צריך לפענח לשישה ערוצים של PCM).
‫[C-2-2] המטא-נתונים של הטווח הדינמי חייבים להיות כפי שמוגדר ב-"Dynamic Range Control (DRC)" בתקן ISO/IEC 14496-3, וandroid.media.MediaFormat מפתחות ה-DRC משמשים להגדרת ההתנהגויות שקשורות לטווח הדינמי של מפענח האודיו. מפתחות ה-DRC של AAC הוצגו ב-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.
‫[C-SR-1] מומלץ מאוד שכל מפענחי האודיו מסוג AAC יעמדו בדרישות C-2-1 ו-C-2-2 שפורטו למעלה.

כשמפענחים אודיו בפורמט USAC, ‏ MPEG-D (ISO/IEC 23003-4):

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

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

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

אם יש תמיכה בתקן ISO/IEC 23003-4 ואם יש מטא-נתונים של ISO/IEC 23003-4 וגם של ISO/IEC 14496-3 בזרם ביטים מפוענח, אז:

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

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

‫[C-6-1] פריימים של אודיו בפורמט PCM 16-bit native byte order דרך API‏ android.media.MediaCodec.

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

‫[C-7-1] האפליקציה חייבת לאפשר הגדרה באמצעות פענוח עם המפתח KEY_MAX_OUTPUT_CHANNEL_COUNT כדי לשלוט אם התוכן יומר לסטריאו (כשמשתמשים בערך 2) או אם הפלט יהיה באמצעות מספר הערוצים המקורי (כשמשתמשים בערך ששווה למספר הזה או גדול ממנו). לדוגמה, ערך של 6 ומעלה יגרום למפענח להפיק 6 ערוצים כשמוזן לו תוכן של 5.1.
‫[C-7-2] במהלך פענוח, המפענח חייב לפרסם את מסכת הערוץ שבה נעשה שימוש בפורמט הפלט באמצעות המפתח KEY_CHANNEL_MASK, תוך שימוש בקבועי android.media.AudioFormat (לדוגמה: CHANNEL_OUT_5POINT1).

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

‫[C-8-1] חובה לתמוך בפענוח של IAMF בגרסה 1.0 שמכיל זרמי אודיו מקודדים ב-AAC,‏ FLAC,‏ Opus או PCM, וחובה להציג מפענח IAMF דרך android.media.MediaCodec API.
‫[C-8-2] המפענח של IAMF חייב לפעול בהתאם למסכת הערוצים שמשמשת להגדרה שלו באמצעות המפתח KEY_CHANNEL_MASK, תוך שימוש בקבועי android.media.AudioFormat כמו CHANNEL_OUT_5POINT1.
‫[C-8-3] חובה לוודא שמפענח IAMF מפרסם את מסכת הערוצים הפעילה בפורמט הפלט באמצעות המפתח KEY_CHANNEL_MASK, באמצעות קבועי android.media.AudioFormat כמו CHANNEL_OUT_5POINT1.

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

‫[C-SR-2] מומלץ מאוד להגדיר את המפענח באמצעות האפליקציה, תוך שימוש בפענוח עם המפתח KEY_MAX_OUTPUT_CHANNEL_COUNT, כדי לשלוט בהמרה של התוכן לסטריאו (כשמשתמשים בערך 2) או בפלט באמצעות מספר הערוצים המקורי (כשמשתמשים בערך ששווה למספר הזה או גדול ממנו). לדוגמה, ערך של 6 ומעלה יגרום למפענח להפיק 6 ערוצים כשמוזן לו תוכן של 5.1.
‫[C-SR-3] כשמפענחים, מומלץ מאוד שהמפענח יפרסם את מסכת הערוצים שבה נעשה שימוש בפורמט הפלט עם המפתח KEY_CHANNEL_MASK, באמצעות הקבועים android.media.AudioFormat (לדוגמה: CHANNEL_OUT_5POINT1).

5.1.3. פרטים על קודק אודיו

פורמט/קודק	פרטים	סוגי קבצים או פורמטים של קונטיינרים שנתמכים
‫G.711 μ-law ו-A-law	תמיכה בתוכן מונו/סטריאו/5.1 עם דגימה ב-8 kHz	WAVE ‏(‎.wav)
פרופיל MPEG-4 AAC ‏(AAC LC)	תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם תדירויות דגימה סטנדרטיות מ-8 עד 48 kHz.	‫3GPP ‏(‎.3gp) ‫MPEG-4 ‏(‎.mp4,‏ ‎.m4a) ‫ADTS raw AAC ‏ (.aac, לא נתמך ADIF) ‫MPEG-TS ‏ (.ts, לא ניתן לחיפוש, פענוח קוד בלבד) ‫Matroska ‏ (.mkv, פענוח בלבד)
פרופיל MPEG-4 HE AAC ‏ (AAC+)	תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם תדירויות דגימה רגילות מ-16 עד 48 קילוהרץ.	‫3GPP ‏(‎.3gp) ‫MPEG-4 ‏(‎.mp4,‏ ‎.m4a)
‫MPEG-4 HE AACv2 פרופיל (AAC+ משופר)	תמיכה בתוכן מונו/סטריאו/5.0/5.1 עם תדירויות דגימה רגילות מ-16 עד 48 קילוהרץ.	‫3GPP ‏(‎.3gp) ‫MPEG-4 ‏(‎.mp4,‏ ‎.m4a)
‫AAC ELD (קידוד AAC עם זמן אחזור נמוך משופר)	תמיכה בתכנים במונו או בסטריאו עם תדירויות דגימה סטנדרטיות מ-16 עד 48kHz.	‫3GPP ‏(‎.3gp) ‫MPEG-4 ‏(‎.mp4,‏ ‎.m4a)
‫USAC MPEG-D USAC עם MPEG-D DRC‏ (Extended High Efficiency AAC)	פענוח: תמיכה בתוכן מונו/סטריאו עם תדירויות דגימה רגילות מ-7.35 עד 48 kHz. קידוד: תמיכה בתוכן מונו/סטריאו עם תדירויות דגימה של 44.1 ו-48 kHz.	‫MPEG-4 ‏(‎.mp4,‏ ‎.m4a)
AMR-NB	‫4.75 עד 12.2 kbps נדגם ב-8 kHz	‫3GPP ‏(‎.3gp)
AMR-WB	‫9 שיעורים מ-6.60‎ kbit/s עד 23.85‎ kbit/s בדגימה ב-16‎ kHz, כפי שמוגדר ב- AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec	‫3GPP ‏(‎.3gp)
FLAC	גם במקודד וגם במפענח: חובה לתמוך לפחות במצבי מונו וסטריאו. חובה לתמוך בתדירויות דגימה של עד 192kHz, וברזולוציה של 16 ביט ו-24 ביט. הטיפול בנתוני אודיו מסוג FLAC 24-bit חייב להיות זמין עם הגדרת אודיו מסוג נקודה צפה.	FLAC‏ (‎.flac) ‫MPEG-4 ‏(‎.mp4,‏ ‎.m4a, פענוח בלבד) ‫Matroska ‏ (.mkv, פענוח בלבד)
MP3	מונו/סטריאו 8-320Kbps קבוע (CBR) או משתנה (VBR)	MP3‏ (‎.mp3) ‫MPEG-4 ‏(‎.mp4,‏ ‎.m4a, פענוח בלבד) ‫Matroska ‏ (.mkv, פענוח בלבד)
MIDI	‫MIDI Type 0 ו-1. גרסה 1 וגרסה 2 של DLS. XMF ו-Mobile XMF. תמיכה בפורמטים של צלצולים RTTTL/RTX,‏ OTA ו-iMelody	סוג 0 ו-1 (‎.mid,‏ ‎.xmf,‏ ‎.mxmf) ‫RTTTL/RTX ‏(‎.rtttl,‏ ‎.rtx) iMelody ‏ (.imy)
Vorbis	פענוח: תמיכה בתוכן מונו, סטריאו, 5.0 ו-5.1 עם קצבי דגימה של 8,000, 12,000, 16,000, 24,000 ו-48,000 הרץ. קידוד: תמיכה בתוכן מונו וסטריאו עם קצבי דגימה של 8,000, 12,000, 16,000, 24,000 ו-48,000 הרץ.	‫Ogg ‏ (.ogg) ‫MPEG-4 ‏(‎.mp4,‏ ‎.m4a, פענוח בלבד) Matroska ‏(‎.mkv) ‫Webm ‏(‎.webm)
PCM/WAVE	קודק PCM חייב לתמוך ב-PCM ליניארי של 16 ביט וב-float של 16 ביט. הכלי WAVE extractor צריך לתמוך ב-PCM ליניארי של 16 ביט, 24 ביט ו-32 ביט, וב-float של 32 ביט (שיעורים עד למגבלת החומרה). חובה לתמוך בתדירויות דגימה מ-‎8 kHz עד ‎192 kHz.	WAVE ‏(‎.wav)
Opus	פענוח: תמיכה בתוכן מונו, סטריאו, 5.0 ו-5.1 עם קצבי דגימה של 8,000, 12,000, 16,000, 24,000 ו-48,000 הרץ. קידוד: תמיכה בתוכן מונו וסטריאו עם קצבי דגימה של 8,000, 12,000, 16,000, 24,000 ו-48,000 הרץ.	‫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
‫[C-0-4] AVIF
- המכשירים צריכים לתמוך ב-BITRATE_MODE_CQ ובפרופיל Baseline.

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

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

‫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] AVIF (פרופיל Baseline)

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

‫[C-1-1] חובה לתמוך בפענוח של תמונות בפורמט HEIF ‏ (HEIC).

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

‫[C-2-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)
‫AVIF (פרופיל Baseline)	פרופיל Baseline של תמונה, אוסף תמונות או רצף תמונות	מאגר HEIF ‏(‎.avif)

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

‫[C-1-1] חובה לתמוך בפורמט צבע גמיש YUV420 8:8:8 ‏ (COLOR_FormatYUV420Flexible) דרך CodecCapabilities.
‫[C-SR-1] מומלץ מאוד לתמוך בפורמט הצבע RGB888 עבור קלט במצב Surface.
‫[C-1-3] המכשיר חייב לתמוך לפחות באחד מפורמטי הצבעים YUV420 8:8:8:‏ planar או semiplanar‏: COLOR_FormatYUV420PackedPlanar (שווה ל-COLOR_FormatYUV420Planar) או COLOR_FormatYUV420PackedSemiPlanar (שווה ל-COLOR_FormatYUV420SemiPlanar). מומלץ מאוד לתמוך בשניהם.

‫5.1.7. קודקים של וידאו

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

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

‫[C-1-1] קודקים של וידאו חייבים לתמוך בגדלים של bytebuffer של פלט וקלט, שיכולים להכיל את המסגרת הדחוסה והלא דחוסה הגדולה ביותר האפשרית, כפי שנקבע בתקן ובתצורה, אבל גם לא להקצות יותר מדי.
‫[C-1-2] מקודדים ומפענחים של וידאו חייבים לתמוך בפורמטים גמישים של צבע YUV420 8:8:8 (COLOR_FormatYUV420Flexible) עד CodecCapabilities.
‫[C-1-3] מקודדים ומפענחים של סרטונים חייבים לתמוך לפחות באחד מפורמטי הצבעים YUV420 8:8:8 planar או semiplanar: ‏COLOR_FormatYUV420PackedPlanar (שווה ערך ל-COLOR_FormatYUV420Planar) או COLOR_FormatYUV420PackedSemiPlanar (שווה ערך ל-COLOR_FormatYUV420SemiPlanar). מומלץ מאוד לתמוך בשניהם.
‫[C-SR-1] מומלץ מאוד שמקודדים ומפענחים של סרטונים יתמכו לפחות באחד מהפורמטים הבאים של צבע 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] אם ההגדרה היא לא להשתמש בפלט Surface, ברירת המחדל חייבת להיות פורמט צבע YUV420 8:8:8 שעבר אופטימיזציה לקריאת CPU

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

‫[C-5-1] מפענחי וידאו שמשתמשים בטכנולוגיית קידוד משנת 2003 ואילך (כמו AV1,‏ AVC,‏ HEVC,‏ VP8,‏ VP9 או VVC) חייבים:
- תומכות בגודל מינימלי של ‎144 x 144 px, וגם
- לפרסם את התמיכה הזו באמצעות VideoCapabilities API, כמו השיטות getSupportedWidths() ו-getSupportedHeightsFor().
‫[C-5-2] מקודדי וידאו שמשתמשים בטכנולוגיית קידוד משנת 2003 ואילך (כמו AV1,‏ AVC,‏ HEVC,‏ VP8,‏ VP9 או VVC) חייבים:
- תמיכה בקלט של Surface בגודל המינימלי הבא לכל מקודד:
  - ‫AVC: ‏160x160 px
  - ‫VP8, ‏ HEVC, ‏ VP9 (אם המקודד מסופק): 160x160 פיקסלים
  - ‫AV1 (אם יש מקודד): ‎256x256 px
- יכולים ליצור זרם נתונים עם גודל פריים גדול יותר מהגודל המינימלי, בתנאי שהם מקודדים את הגודל הנכון באמצעות מידע על מלבן החיתוך.

‫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)
AV1	פרטים נוספים זמינים בסעיף 5.2 ובסעיף 5.3.	MPEG-4 ‏(‎.mp4) ‫Matroska ‏ (.mkv, פענוח בלבד)

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

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

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

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

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

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

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

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

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

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

	איכות רגילה (SD)	איכות רגילה (SD)	HD 720p	HD 1080p	UHD
רזולוציית הווידאו	‫176x144 פיקסלים (H263, ‏ MPEG2, ‏ MPEG4) ‫‎352 x 288 px (MPEG4 encoder, H263, MPEG2) ‫320 x 180 px (VP8, VP8) ‫‎320 x 240 פיקסלים (אחר)	‫‎704 x 576 px (H263) ‫‎640 x 360 פיקסלים (VP8, ‏ VP9) ‫‎640 x 480 פיקסלים (MPEG4 encoder) ‫‎720 x 480 פיקסלים (אחר, AV1)	‫‎1408 x 1152 פיקסלים (H263) ‫1280 x 720 פיקסלים (אחר, AV1)	‫‎1,920 x 1,080 פיקסלים (מלבד MPEG4,‏ AV1)	‫3840 x 2160 px (HEVC, VP9, AV1)

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

5.2. קידוד סרטונים

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

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

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

[C-SR-2] מומלץ מאוד שלא לחרוג ב-15% מקצב העברת הנתונים של היעד בחלון הזזה של שנייה אחת.

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

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

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

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

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

[C-SR-1] מומלץ מאוד לספק תוסף ל-API של המרת קידוד חלקה כדי להמיר מפורמט HDR לפורמט SDR.

5.2.1. H.263

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

‫[C-1-1] חובה לתמוך ברזולוציית QCIF‏ (‎176 x 144) באמצעות פרופיל Baseline ברמה 45. הרזולוציה SQCIF היא אופציונלית.

5.2.2. H.264

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

‫[C-1-1] חובה לתמוך בפרופיל Baseline ברמה 3. עם זאת, התמיכה ב-ASO (Arbitrary Slice Ordering), ב-FMO (Flexible Macroblock Ordering) וב-RS (Redundant Slices) היא אופציונלית. בנוסף, כדי לשמור על תאימות למכשירי Android אחרים, מומלץ שמקודדים לא ישתמשו ב-ASO, ב-FMO וב-RS עבור פרופיל Baseline.
‫[C-1-2] חובה לתמוך בפרופילים של קידוד וידאו באיכות רגילה (SD) שמפורטים בטבלה הבאה.
צריכה לתמוך ברמה 4 של הפרופיל הראשי.
צריכה להיות תמיכה בפרופילים של קידוד סרטונים באיכות HD (High Definition) כמו שמופיע בטבלה הבאה.

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

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

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

5.2.3. VP8

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

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

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

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

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

‫5.2.4. VP9

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

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

	SD	HD 720p	HD 1080p	UHD
רזולוציית הווידאו	‫720 x 480 פיקסלים	‫‎1280 x 720 פיקסלים	‫‎1,920 x 1,080 פיקסלים	‫3,840 על 2,160 פיקסלים
קצב פריימים של סרטון	‫30 פריימים לשנייה	‫30 פריימים לשנייה	‫30 פריימים לשנייה	‫30 פריימים לשנייה
קצב העברת נתונים של וידאו	‎1.6 Mbps	4Mbps	‎5 Mbps	‎20 Mbps

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

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

‫5.2.5. H.265

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

‫[C-1-1] חובה לתמוך ברמה 3 של פרופיל ראשי עד לרזולוציה של ‎512 x 512.
[C-SR-1] מומלץ מאוד לתמוך בפרופיל SD‏ 720x480 ובפרופילי קידוד HD, כפי שמצוין בטבלה הבאה, אם יש מקודד חומרה.

	SD	HD 720p	HD 1080p	UHD
רזולוציית הווידאו	‫720 x 480 פיקסלים	‫‎1280 x 720 פיקסלים	‫‎1,920 x 1,080 פיקסלים	‫3,840 על 2,160 פיקסלים
קצב פריימים של סרטון	‫30 פריימים לשנייה	‫30 פריימים לשנייה	‫30 פריימים לשנייה	‫30 פריימים לשנייה
קצב העברת נתונים של וידאו	‎1.6 Mbps	4Mbps	‎5 Mbps	‎20 Mbps

‫5.2.6. AV1

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

‫[C-1-1] חובה לתמוך בפרופיל הראשי, כולל תוכן של 8 ביט ו-10 ביט.
‫[C-1-2] חובה לפרסם נתוני ביצועים, כלומר לדווח על נתוני ביצועים באמצעות ממשקי ה-API‏ getSupportedFrameRatesFor() או getSupportedPerformancePoints() עבור הרזולוציות הנתמכות שמפורטות בטבלה שלמטה.
‫[C-1-3] המכשיר חייב לקבל מטא-נתונים של HDR ולהוציא אותם לזרם הביטים

אם מקודד AV1 מאיץ את הפעולה באמצעות חומרה, הוא:

‫[C-2-1] המכשיר חייב לתמוך בפרופיל קידוד עד HD1080p כולל, מהטבלה שלמטה:

	SD	HD 720p	HD 1080p	UHD
רזולוציית הווידאו	‫720 x 480 פיקסלים	‫‎1280 x 720 פיקסלים	‫‎1,920 x 1,080 פיקסלים	‫3,840 על 2,160 פיקסלים
קצב פריימים של סרטון	‫30 פריימים לשנייה	‫30 פריימים לשנייה	‫30 פריימים לשנייה	‫30 פריימים לשנייה
קצב העברת נתונים של וידאו	‎5 Mbps	8Mbps	16Mbps	‫50 Mbps

5.3. פענוח סרטונים

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

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

‫5.3.1. MPEG-2

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

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

‫5.3.2. H.263

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

‫[C-1-1] חובה לתמוך בפרופיל Baseline ברמה 30 (רזולוציות CIF, ‏ QCIF ו-SQCIF בקצב של 30fps ו-384kbps) וברמה 45 (רזולוציות QCIF ו-SQCIF בקצב של 30fps ו-128kbps).

5.3.3. MPEG-4

אם המכשירים כוללים יישומי מפענח MPEG-4, הם:

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

‫5.3.4. H.264

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

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

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

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

	איכות רגילה (SD)	איכות רגילה (SD)	HD 720p	HD 1080p
רזולוציית הווידאו	‫320 x 240 פיקסלים	‫720 x 480 פיקסלים	‫‎1280 x 720 פיקסלים	‫‎1,920 x 1,080 פיקסלים
קצב פריימים של סרטון	‫30 פריימים לשנייה	‫30 פריימים לשנייה	‫60 פריימים לשנייה	‫30 פריימים לשנייה (60 פריימים לשנייה ב^{טלוויזיה})
קצב העברת נתונים של וידאו	‫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] הטמעות של מכשירים חייבות לתמוך בפרופילים של 720, ‏ 1080 ו-UHD של לפחות אחד מהפורמטים H.265 או VP9.

	איכות רגילה (SD)	איכות רגילה (SD)	HD 720p	HD 1080p	UHD
רזולוציית הווידאו	‫352 x 288 פיקסלים	‫720 x 480 פיקסלים	‫‎1280 x 720 פיקסלים	‫‎1,920 x 1,080 פיקסלים	‫3,840 על 2,160 פיקסלים
קצב פריימים של סרטון	‫30 פריימים לשנייה	‫30 פריימים לשנייה	‫30 פריימים לשנייה	‫30/60 fps (60 fps^{טלוויזיה עם פענוח חומרה H.265})	‫60 פריימים לשנייה
קצב העברת נתונים של וידאו	‎600 Kbps	‎1.6 Mbps	4Mbps	‎5 Mbps	‎20 Mbps

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

‫[C-3-1] הטמעות של מכשירים חייבות לקבל את המטא-נתונים הנדרשים של HDR מהאפליקציה, וגם לתמוך בחילוץ ובהוצאה של המטא-נתונים הנדרשים של HDR מזרם הביטים או מהקונטיינר.
‫[C-3-2] הטמעות של מכשירים חייבות להציג תוכן HDR בצורה תקינה במסך המכשיר או ביציאת וידאו רגילה (למשל, 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
רזולוציית הווידאו	‫320 x 180 px	‫640 x 360 פיקסלים	‫‎1280 x 720 פיקסלים	‫‎1,920 x 1,080 פיקסלים
קצב פריימים של סרטון	‫30 פריימים לשנייה	‫30 פריימים לשנייה	‫30 פריימים לשנייה (60 פריימים לשנייה ב^{טלוויזיה})	‫30 (60 פריימים לשנייה^{טלוויזיה})
קצב העברת נתונים של וידאו	‫800 Kbps	2 Mbps	8Mbps	‎20 Mbps

5.3.7. VP9

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

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

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

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

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

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

	איכות רגילה (SD)	איכות רגילה (SD)	HD 720p	HD 1080p	UHD
רזולוציית הווידאו	‫320 x 180 px	‫640 x 360 פיקסלים	‫‎1280 x 720 פיקסלים	‫‎1,920 x 1,080 פיקסלים	‫3,840 על 2,160 פיקסלים
קצב פריימים של סרטון	‫30 פריימים לשנייה	‫30 פריימים לשנייה	‫30 פריימים לשנייה	‫30 fps (60 fps^{טלוויזיה עם פענוח חומרה VP9})	‫60 פריימים לשנייה
קצב העברת נתונים של וידאו	‎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 (KEY_HDR_STATIC_INFO לכל פרופילי ה-HDR, וגם 'KEY_HDR10_PLUS_INFO' לפרופילי HDR10Plus) מהאפליקציה. הם גם חייבים לתמוך בחילוץ של מטא-נתוני ה-HDR הנדרשים מזרם הביטים או מהקונטיינר, ובהפקתם.
‫[C-4-2] הטמעות של מכשירים חייבות להציג תוכן HDR בצורה תקינה במסך המכשיר או ביציאת וידאו רגילה (למשל, 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

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

‫[C-1-1] חובה לתמוך בפרופיל הראשי, כולל תוכן של 8 ביט ו-10 ביט.

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

‫[C-2-1] המכשיר חייב להיות מסוגל לפענח לפחות פרופילים של פענוח וידאו באיכות HD 720p מהטבלה שלמטה, כשהגובה שמדווח על ידי שיטת Display.getSupportedModes() שווה ל-720p או גדול ממנו.
‫[C-2-2] המכשיר חייב להיות מסוגל לפענח לפחות פרופילים של פענוח וידאו באיכות HD 1080p מהטבלה שלמטה, כשהגובה שמדווח על ידי שיטת Display.getSupportedModes() שווה ל-1080p או גדול ממנו.

	SD	HD 720p	HD 1080p	UHD
רזולוציית הווידאו	‫720 x 480 פיקסלים	‫‎1280 x 720 פיקסלים	‫‎1,920 x 1,080 פיקסלים	‫3,840 על 2,160 פיקסלים
קצב פריימים של סרטון	‫30 פריימים לשנייה	‫30 פריימים לשנייה	‫30 פריימים לשנייה	‫30 פריימים לשנייה
קצב העברת נתונים של וידאו	‎5 Mbps	8Mbps	16Mbps	‫50 Mbps

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

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

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

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

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

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

‫[C-1-1] חובה לאפשר צילום של תוכן אודיו גולמי לכל זרם קלט AudioRecord או AAudio שנפתח בהצלחה. לכל הפחות, חובה לתמוך במאפיינים הבאים:
- פורמט: Linear PCM, ‏ 16 ביט
- תדירויות דגימה: 8000, ‏ 11025, ‏ 16000, ‏ 44100, ‏ 48000 הרץ
- ערוצים: מונו
- מקורות אודיו: DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED, או VOICE_PERFORMANCE. הדבר נכון גם לגבי הגדרות קבועות מראש של קלט מקבילות ב-AAudio, למשל AAUDIO_INPUT_PRESET_CAMCORDER.
צריך לאפשר צילום של תוכן אודיו גולמי עם המאפיינים הבאים:
- פורמט: Linear PCM, ‏ 16 ביט ו-24 ביט
- תדירויות דגימה: 8,000,‏ 11,025,‏ 16,000,‏ 22,050,‏ 24,000,‏ 32,000,‏ 44,100,‏ 48,000 הרץ
- ערוצים: מספר הערוצים זהה למספר המיקרופונים במכשיר
‫[C-1-2] חובה לצלם בתדירויות דגימה שצוינו למעלה ללא הגדלת קצב הדגימה.
‫[C-1-3] חובה לכלול מסנן מתאים נגד Aliasing כשקצב הדגימה שצוין למעלה נדגם עם דגימת יתר.
צריך לאפשר הקלטה של תוכן אודיו גולמי באיכות של רדיו AM ו-DVD, כלומר עם המאפיינים הבאים:
- פורמט: Linear PCM, 16-bit
- תדירויות דגימה: 22050, ‏ 48000 הרץ
- ערוצים: סטריאו
‫[C-1-4] חובה לכבד את MicrophoneInfo API ולמלא בצורה נכונה את המידע לגבי המיקרופונים הזמינים במכשיר שאפליקציות צד שלישי יכולות לגשת אליהם דרך AudioManager.getMicrophones() API, עבור AudioRecord פעיל באמצעות MediaRecorder.AudioSources DEFAULT,‏ MIC,‏ CAMCORDER,‏ VOICE_RECOGNITION,‏ VOICE_COMMUNICATION,‏ UNPROCESSED או VOICE_PERFORMANCE. אם יישומי המכשיר מאפשרים רדיו AM וצילום של תוכן אודיו גולמי באיכות DVD:
‫[C-2-1] חובה לצלם ללא הגדלת דגימה בכל יחס גבוה מ-16000:22050 או 44100:48000.
‫[C-2-2] חובה לכלול מסנן מתאים נגד aliasing לכל דגימת יתר או דגימת חסר.

5.4.2. הקלטה לזיהוי דיבור

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

‫[C-1-1] חובה ללכוד מקור אודיו android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION באחת מתדירויות הדגימה הבאות: 44100 ו-48000.
‫[C-1-2] חובה להשבית כברירת מחדל כל עיבוד אודיו להפחתת רעשים כשמקליטים שידור אודיו ממקור האודיו AudioSource.VOICE_RECOGNITION.
‫[C-1-3] חובה להשבית כברירת מחדל את כל בקרת עוצמת הקול האוטומטית כשמקליטים זרם אודיו ממקור האודיו של AudioSource.VOICE_RECOGNITION.
צריכה להיות לו בערך תגובת תדר שטוחה בטווח התדרים האמצעי: במיוחד ±3dB מ-100 הרץ עד 4,000 הרץ לכל מיקרופון שמשמש להקלטת מקור האודיו של זיהוי הדיבור.
[C-SR-1] מומלץ מאוד להציג רמות אמפליטודה בטווח התדרים הנמוך: במיוחד מ-‎±20 dB מ-30 Hz עד 100 Hz בהשוואה לטווח התדרים הבינוני עבור כל מיקרופון שמשמש להקלטת מקור האודיו של זיהוי הדיבור.
[C-SR-2] מומלץ מאוד להציג רמות אמפליטודה בטווח התדרים הגבוה: במיוחד מ-‎±30 dB מ-4,000 הרץ עד 22,000 הרץ בהשוואה לטווח התדרים הבינוני עבור כל מיקרופון שמשמש להקלטת מקור האודיו של זיהוי הדיבור.
מומלץ להגדיר את רגישות קלט האודיו כך שמקור טון סינוסואידי בתדר 1,000 הרץ שמושמע ברמת לחץ קול (SPL) של 90 דציבלים (נמדד ליד המיקרופון) יניב תגובה אידיאלית של RMS 2,500 בטווח של 1,770 עד 3,530 עבור 16 דגימות ביט (או ‎-22.35 db ±3dB Full Scale עבור דגימות של נקודה צפה/דיוק כפול) עבור כל מיקרופון שמשמש להקלטת מקור האודיו של זיהוי הדיבור.
מומלץ להקליט את זרם האודיו של זיהוי הדיבור, כך שרמות האמפליטודה של ה-PCM יעקבו באופן לינארי אחרי שינויים ב-SPL של הקלט בטווח של לפחות 30dB, מ-‎-18dB עד ‎+12dB re 90dB SPL במיקרופון.
מומלץ להקליט את זרם האודיו של זיהוי הדיבור עם עיוות הרמוני כולל (THD) של פחות מ-1% עבור 1‎ kHz ברמת קלט של 90‎ dB SPL במיקרופון.

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

‫[C-2-1] חובה לאפשר שליטה באפקט האודיו הזה באמצעות android.media.audiofx.NoiseSuppressor API.
‫[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.

אם הטמעות המכשיר מספקות Acoustic Echo Canceler (מבטל הד אקוסטי) שמוכנס לנתיב האודיו של הלכידה כשבוחרים באפשרות AudioSource.VOICE_COMMUNICATION, הן:

[C-SR-1] [C-1-1] are STRONGLY_RECOMMENDED MUST declare this via AcousticEchoCanceler API method AcousticEchoCanceler.isAvailable() returning true.

‫[C-1-2] חובה לשקף את ההפעלה של ה-AEC בנתיב האודיו עבור גורמי צורה שאינם שעונים, באמצעות שיטת AcousticEchoCanceler API‏ AcousticEchoCanceler.getEnabled, שצריכה להחזיר true כשהיא פעילה ו-false כשהיא לא פעילה.

מומלץ מאוד להשתמש ב-[C-SR-2] [C-SR-1] כדי לאפשר שליטה באפקט האודיו הזה באמצעות ה-API‏ AcousticEchoCanceler.
[C-SR-3] [C-SR-2] מומלץ מאוד לזהות באופן ייחודי כל הטמעה של טכנולוגיית AEC באמצעות השדה AudioEffect.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.5. הפעלת אודיו

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

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

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

‫[C-1-1] חובה לאפשר הפעלה של תוכן אודיו גולמי עם המאפיינים הבאים:
- פורמטים של מקור: Linear PCM, ‏ 16 ביט, 8 ביט, float
- ערוצים: מונו, סטריאו, הגדרות תקינות של ערוצים מרובים עם עד 8 ערוצים
- שיעורי דגימה (בהרץ):
  - ‫8,000, ‏11,025, ‏16,000, ‏22,050, ‏24,000, ‏32,000, ‏44,100, ‏48,000 בהגדרות הערוצים שמופיעות למעלה
  - ‫96,000 במונו ובסטריאו

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

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

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

‫[C-1-1] חובה לתמוך בהטמעות של EFFECT_TYPE_EQUALIZER ושל EFFECT_TYPE_LOUDNESS_ENHANCER שניתנות לשליטה באמצעות מחלקות המשנה AudioEffect‏ Equalizer ו-LoudnessEnhancer.
‫[C-1-2] חובה לתמוך בהטמעה של Visualizer API, שאפשר לשלוט בה באמצעות המחלקה Visualizer.
‫[C-1-3] חובה לתמוך בהטמעה של EFFECT_TYPE_DYNAMICS_PROCESSING שאפשר לשלוט בה באמצעות מחלקת המשנה AudioEffect‏ DynamicsProcessing.
‫[C-1-4] חובה לתמוך באפקטים של אודיו עם קלט ופלט של נקודה צפה, כשתוצאות האפקט מוחזרות לצינור האודיו של המסגרת. הכוונה היא לאפקטים רגילים של הוספה או עזר, כמו אקולייזר. מומלץ מאוד להשתמש בהתנהגות שוות ערך אם האפקט לא נראה בצינור האודיו של המסגרת, כמו אפקטים אחרי העיבוד או אפקטים שהועברו.
‫[C-1-5] חובה לוודא שאפקטים של אודיו תומכים בכמה ערוצים עד למספר הערוצים של המיקסר, שנקרא גם FCC_LIMIT, כשתוצאות האפקט מוחזרות לצינור האודיו של המסגרת. הכוונה היא לאפקטים רגילים של הכנסה או עזר, אבל לא לאפקטים מיוחדים כמו מיקס דאון, מיקס אפ או אפקטים של מיקום במרחב שמשנים את מספר הערוצים. מומלץ להשתמש בהתנהגות שוות ערך כשלא רואים את האפקטים בצינור האודיו של המסגרת, כמו אפקטים אחרי העיבוד או אפקטים שהועברו.
צריך לתמוך בהטמעות של EFFECT_TYPE_BASS_BOOST,‏ EFFECT_TYPE_ENV_REVERB,‏ EFFECT_TYPE_PRESET_REVERB ו-EFFECT_TYPE_VIRTUALIZER שאפשר לשלוט בהן באמצעות מחלקות המשנה AudioEffect‏ BassBoost,‏ EnvironmentalReverb,‏ PresetReverb ו-Virtualizer.
‫[C-SR-1] מומלץ מאוד לתמוך באפקטים בנקודה צפה ובריבוי ערוצים.

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

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

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

‫5.5.4. הפחתת עומס אודיו

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

‫[C-SR-1] מומלץ מאוד לחתוך את תוכן האודיו שמופעל ללא הפסקה בין שני קליפים באותו פורמט, אם מצוין על ידי AudioTrack gapless API ומאגר המדיה של MediaPlayer.
[C-SR-2] מומלץ מאוד להטמיע הפחתת עומס בהפעלה לפורמטים AAC,‏ MP3,‏ OPUS ו-PCM.

אם הטמעות של מכשירים מצהירות על תמיכה בהפחתת עומס PCM של MMAP (מוצהר על ידי יציאת מיקס עם דגלים שמכילים את AUDIO_OUTPUT_FLAG_COMPRESS_OFFLOAD ו-AUDIO_OUTPUT_FLAG_MMAP_NOIRQ), הן:

‫[C-1-1] חובה לתמוך לפחות ב-AUDIO_FORMAT_PCM_16_BIT,‏ ב-44.1 kHz וב-48 kHz לסטריאו ולמונו.
‫[C-1-2] הגודל של מאגר הנתונים הזמני חייב להיות מסוגל לאחסן אודיו למשך 5 שניות לפחות בפורמט PCM סטריאו 48 kHz,‏ 16 ביט לכל דגימה.

‫5.5.5. פרמטרים של הפעלה

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

‫[C-1-1] המערכת חייבת לתמוך במהירויות בין 0.5 ל-2.0 עם גובה צליל של 1.0.

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

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

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

זמן האחזור של הפלט. המרווח בין הרגע שבו אפליקציה כותבת פריים של נתונים עם קידוד PCM לבין הרגע שבו הצליל התואם מוצג בסביבה במתמר במכשיר או שהאות יוצא מהמכשיר דרך יציאה וניתן לצפייה חיצונית.
זמן אחזור של פלט ראשוני. הזמן שחלף בין התחלת זרם הפלט לבין זמן ההצגה של הפריים הראשון על סמך חותמות זמן, כשהמערכת של פלט האודיו הייתה במצב לא פעיל וכבויה לפני הבקשה.
זמן האחזור של הפלט הרציף. השהיית הפלט של פריימים עוקבים, אחרי שהמכשיר מפעיל אודיו.
זמן אחזור של קלט. המרווח בין הרגע שבו הסביבה מציגה צליל למכשיר באמצעות מתמר במכשיר או אות שנכנס למכשיר דרך יציאה, לבין הרגע שבו אפליקציה קוראת את המסגרת המתאימה של נתונים שמקודדים ב-PCM.
הקלט אבד. החלק הראשוני של אות קלט שלא ניתן לשימוש או שלא זמין.
זמן האחזור של קלט בהפעלה מההתחלה. הזמן שחלף בין התחלת הסטרימינג לבין קבלת הפריים התקין הראשון, כשמערכת קלט האודיו הייתה במצב לא פעיל וכבויה לפני הבקשה.
זמן אחזור ארוך של קלט. השהיית הקלט של פריים עוקב, בזמן שהמכשיר מקליט אודיו.
זמן אחזור רציף. סכום זמן האחזור של הקלט הרציף בתוספת זמן האחזור של הפלט הרציף בתוספת תקופת מאגר אחת. תקופת ההשהיה מאפשרת לאפליקציה לעבד את האות ולצמצם את ההבדל בין השלב של זרמי הקלט והפלט.
‫OpenSL ES PCM buffer queue API. קבוצת ממשקי ה-API שקשורים ל-PCM של OpenSL ES בתוך Android NDK.
‫AAudio native audio API. קבוצת ממשקי ה-API של AAudio בתוך Android NDK.
חותמת זמן. זוג שמורכב ממיקום יחסי של פריים בתוך סטרימינג ומהזמן המשוער שבו הפריים הזה נכנס לצינור העיבוד של האודיו בנקודת הקצה המשויכת או יוצא ממנו. אפשר לעיין גם בAudioTimestamp.
glitch. הפרעה זמנית או ערך דגימה שגוי באות האודיו, בדרך כלל בגלל buffer underrun בפלט, buffer overrun בקלט או כל מקור אחר של רעש דיגיטלי או אנלוגי.
mean absolute deviation (MAD). הממוצע של הערך המוחלט של הסטיות מהממוצע של קבוצת ערכים.
זמן האחזור של הקשה להשמעת צליל (TTL), כפי שנמדד על ידי CTS Verifier, הוא הזמן שחולף מרגע ההקשה על המסך ועד לרגע שבו נשמע צליל שנוצר כתוצאה מההקשה ברמקול. הערך הזה הוא ממוצע של 5 מדידות באמצעות AAudio native audio API לפלט.
זמן האחזור הלוך ושוב (RTL), כפי שנמדד על ידי CTS Verifier, הוא זמן האחזור הממוצע הרציף על פני 5 מדידות, שנמדד על פני נתיב של משוב שמעביר את הפלט בחזרה לקלט, באמצעות AAudio native audio API.

נתיבי הלולאה החוזרת הם:
- רמקול/מיקרופון: רמקול מובנה למיקרופון מובנה.
- אנלוגי: שקע אנלוגי של 3.5 מ"מ ומתאם loopback.
- ‫USB: מתאם מ-USB ל-3.5 מ"מ ומתאם ללולאה חוזרת, או ממשק שמע USB וכבלים ללולאה חוזרת.
‫FEATURE_AUDIO_LOW_LATENCY. התכונה android.hardware.audio.low_latency מוצהרת.
‫FEATURE_AUDIO_PRO. התכונה android.hardware.audio.pro מוצהרת.
‫MPC. Media Performance Class.
זמן האחזור של מעקב התנועות של הראש. הזמן שחולף מרגע שתנועת הראש נקלטת על ידי יחידת מדידה אינרציאלית (IMU) ועד שהמתמרים באוזניות מזהים את השינוי בצליל שנגרם כתוצאה מהתנועה.

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

‫[C-0-1] חובה לוודא שכשאפליקציה מתקשרת אל android.media.AudioManager.setCommunicationDevice() עם device נתמך (כמו אוזניות חוטיות, רמקולים מובנים או אוזניות כפתור, או אוזניות USB), הקריאה החוזרת (callback) של android.media.AudioManager.OnCommunicationDeviceChangedListener.onCommunicationDeviceChanged() מופעלת עם מכשיר האודיו הזה תוך 1,500 אלפיות השנייה מהרגע שבו הקריאה של setCommunicationDevice() מחזירה true.

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

‫[C-1-1] הדרישה הוסרה ב-Android 15.
‫[C-1-2] חביון פלט של 500 אלפיות השנייה או פחות.
‫[C-1-3] פתיחת זרם פלט באמצעות AAudioStreamBuilder_openStream() חייבת להימשך פחות מ-1,000 אלפיות השנייה.
‫[C-1-4] זמן האחזור הכולל המחושב על סמך חותמות הזמן של הקלט והפלט שמוחזרות על ידי AAudioStream_getTimestamp חייב להיות בטווח של 200 אלפיות השנייה מזמן האחזור הכולל שנמדד עבור AAUDIO_PERFORMANCE_MODE_NONE ו-AAUDIO_PERFORMANCE_MODE_LOW_LATENCY ברמקולים, באוזניות קוויות ובאוזניות אלחוטיות.
‫[C-SR-1] הדרישה הוסרה ב-Android 15.
‫[C-SR-2] הדרישה הוסרה ב-Android 15.
‫[C-SR-4] הדרישה הוסרה ב-Android 15.
‫[C-SR-5] הדרישה הוסרה ב-Android 15.
‫[C-SR-6] הדרישה הוסרה ב-Android 15.
‫[C-SR-7] הדרישה הוסרה ב-Android 15.
‫[C-2-1] הדרישה הוסרה ב-Android 15.

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

‫[C-3-1] הדרישה הוסרה ב-Android 15.
‫[C-3-2] זמן האחזור של קלט במצב התנעה קרה הוא 500 אלפיות השנייה או פחות.
‫[C-3-3] פתיחת זרם קלט באמצעות AAudioStreamBuilder_openStream() חייבת להימשך פחות מ-1,000 אלפיות השנייה.
‫[C-SR-8] הדרישה הוסרה ב-Android 15.
‫[C-SR-11] הדרישה הוסרה ב-Android 15.
‫[C-SR-12] הדרישה הוסרה ב-Android 15.

בטבלה הבאה מוגדרות הדרישות לRTL עבור הטמעות של מכשירים שניתן להחזיק ביד כפי שמוגדר ב2.2.1 שמצהירים על android.hardware.audio.output ועל android.hardware.microphone.

מכשיר והצהרות	RTL (אלפיות השנייה)	MAD (מילישניות)	נתיבי לולאה חוזרת (loopback)
מוחזקת ביד	200	25	רמקול/מיקרופון, אנלוגי 3.5 מ"מ (אם נתמך), USB (אם נתמך)
‫MPC 37 ואילך	65	10	כל נתיבי הנתונים הנתמכים
‫>= MPC_T (13) MPC 33 through MPC 36	80	15	לפחות נתיב אחד
FEATURE_AUDIO_LOW_LATENCY	50	10	לפחות נתיב אחד
FEATURE_AUDIO_PRO	25	5	לפחות נתיב אחד
FEATURE_AUDIO_PRO	20	5	אנלוגי (אם נתמך)
FEATURE_AUDIO_PRO	25	5	USB (אם לא נתמכת אנלוגיה)

בטבלה הבאה מוגדרות הדרישות לTTL להטמעה של מכשירים שניתן להחזיק ביד כפי שמוגדר ב2.2.1 שמצהירים על android.hardware.audio.output ועל android.hardware.microphone.

מכשיר והצהרות	TTL (מילישניות)
מוחזקת ביד	250
‫MPC 37 ואילך	65
‫>= MPC_T (13) MPC 33 through MPC 36	80
‫MPC_S (12) MPC 31	100
FEATURE_AUDIO_PRO	80

אם הטמעות של מכשירים כוללות תמיכה ב-spatial audio עם מעקב ראש ומצהירות על הדגל PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY, הן:

‫[C-4-1] חובה להציג חביון מקסימלי של 300 ms בין מעקב הראש לבין עדכון האודיו.

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

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

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

‫[C-1-1] חובה לתמוך ב-Codec או בקונטיינר באמצעות HTTP ו-HTTPS.
‫[C-1-2] חובה לתמוך בפורמטים המתאימים של פלחי מדיה, כפי שמוצג בטבלה של פורמטים של פלחי מדיה בהמשך, באמצעות פרוטוקול טיוטה של HTTP Live Streaming, גרסה 7.
‫[C-1-3] חובה לתמוך בפורמטים המתאימים של מטען ייעודי (payload) של RTSP, כמו שמוצג בטבלת RTSP שבהמשך. מקרים יוצאים מן הכלל מפורטים בהערות השוליים של הטבלה בסעיף 5.1.

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

פורמטים של פלחים	הפניה/ות	תמיכה נדרשת ב-Codec
MPEG-2 Transport Stream	ISO 13818	קודקים של וידאו: H264 AVC MPEG-4 SP MPEG-2 פרטים על H264 AVC, ‏ MPEG2-4 SP,‏ ו-MPEG-2 זמינים בקטע 5.1.8. קודק אודיו: קובץ AAC פרטים על AAC והווריאציות שלו מופיעים בסעיף 5.1.3.
‫AAC עם מסגור ADTS ותגי ID3	ISO 13818-7	פרטים על AAC והווריאציות שלו מופיעים בסעיף 5.1.1 .
WebVTT	WebVTT

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

הפניה/ות

תמיכה נדרשת ב-Codec

MPEG-2 Transport Stream

ISO 13818

קודקים של וידאו:

H264 AVC
MPEG-4 SP
MPEG-2

פרטים על H264 AVC, ‏ MPEG2-4 SP,‏
ו-MPEG-2 זמינים בקטע 5.1.8.

קודק אודיו:

קובץ AAC

פרטים על AAC והווריאציות שלו מופיעים בסעיף 5.1.3.

‫AAC עם מסגור ADTS ותגי ID3

ISO 13818-7

פרטים על AAC והווריאציות שלו מופיעים בסעיף 5.1.1 .

WebVTT

‫RTSP (RTP, SDP)

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

5.8. Secure Media

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

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

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

‫[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
- ‫MIDI over Bluetooth LE acting in central role, section 7.4.3
‫[C-1-2] חובה לתמוך בהעברת נתוני MIDI בין אפליקציות (מכשירי MIDI וירטואליים)
‫[C-1-3] חובה לכלול את libamidi.so (תמיכה מקומית ב-MIDI)
צריך לתמוך ב-MIDI במצב ציוד היקפי בחיבור USB, סעיף 7.7

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

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

‫[C-1-1] חובה לדווח על תמיכה בתכונה android.hardware.audio.low_latency.
‫[C-1-2] חובה לעמוד בדרישות זמן האחזור של FEATURE_AUDIO_PRO כפי שמוגדרות בקטע 5.6 זמן אחזור אודיו .
‫[C-1-3] חובה לכלול יציאות USB שתומכות במצב מארח USB ובמצב ציוד היקפי USB.
‫[C-1-4] חובה לדווח על תמיכה בתכונה android.software.midi.
[C-1-5] המכשיר חייב לעמוד בדרישות של זמן טעינת אודיו (audio latency) ב-USB באמצעות AAudio native audio API ו-AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
‫[C-1-6] חובה שזמן האחזור של הפלט במצב 'הפעלה קרה' יהיה 200 אלפיות השנייה או פחות.
‫[C-1-7] חובה שזמן האחזור של קלט קר יהיה 200 אלפיות השנייה או פחות.

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

‫[C-2-2] חייב לעמוד בדרישות של הקטע מפרטים של מכשירים ניידים (שקע) במפרט של אוזניות חוטיות (גרסה 1.1).

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

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

‫5.11. צילום ללא עיבוד

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

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

‫[C-1-1] חובה לדווח על התמיכה באמצעות המאפיין PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED‏ android.media.AudioManager property.
‫[C-1-2] חייבת להיות משרעת שטוחה בקירוב לעומת מאפייני התדר בטווח התדרים האמצעי: באופן ספציפי, ‎±10 dB מ-‎100 Hz עד ‎7,000 Hz לכל מיקרופון שמשמש להקלטת מקור האודיו שלא עבר עיבוד.
‫[C-1-3] רמות האמפליטודה צריכות להיות בטווח התדרים הנמוך: במיוחד מ-‎±20 dB מ-5 z עד 100 Hz בהשוואה לטווח התדרים הבינוני לכל מיקרופון שמשמש להקלטת מקור האודיו שלא עבר עיבוד.
‫[C-1-4] רמות האמפליטודה צריכות להיות בטווח התדרים הגבוה: במיוחד מ-‎±30 dB מ-7,000 Hz עד 22 KHz בהשוואה לטווח התדרים הבינוני עבור כל מיקרופון שמשמש להקלטת מקור האודיו שלא עבר עיבוד.
‫[C-1-5] חובה להגדיר את רגישות קלט האודיו כך שמקור צליל סינוסי בתדר 1,000 Hz שמופעל ברמת לחץ קול (SPL) של 94 dB יניב תגובה עם RMS של 520 עבור דגימות של 16 ביט (או ‎-36 dB Full Scale עבור דגימות של נקודה צפה/דיוק כפול) לכל מיקרופון שמשמש להקלטת מקור האודיו שלא עבר עיבוד.
‫[C-1-6] יחס האות לרעש (SNR) של כל מיקרופון שמשמש להקלטת מקור האודיו הלא מעובד חייב להיות 60 dB ומעלה. (לעומת זאת, יחס האות לרעש נמדד כהפרש בין 94 dB SPL לבין רמת לחץ הקול המקבילה של הרעש העצמי, עם משקל A).
‫[C-1-7] בכל מיקרופון שמשמש להקלטת מקור האודיו הלא מעובד, העיוות ההרמוני הכולל (THD) צריך להיות נמוך מ-1% עבור 1 kHz ברמת קלט של 90 dB SPL.
‫[C-1-8] אסור שיהיה עיבוד אותות אחר (למשל, בקרת עוצמה אוטומטית, מסנן מעביר גבוה או ביטול הד) בנתיב, מלבד מכפיל רמה כדי להביא את הרמה לטווח הרצוי. במילים אחרות:
- ‫[C-1-9] אם יש עיבוד אותות בארכיטקטורה מסיבה כלשהי, הוא חייב להיות מושבת ולא לגרום להשהיה או לזמן אחזור נוסף בנתיב האות.
- ‫[C-1-10] מותר להשתמש במכפיל הרמה בנתיב, אבל אסור שהוא יגרום לעיכוב או לזמן אחזור בנתיב האות.

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

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

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

‫5.12. וידאו HDR

‫Android 13 תומך בטכנולוגיות HDR כפי שמתואר במסמך שיפורסם בקרוב.

פורמט Pixel

אם דקודר וידאו מפרסם תמיכה ב-COLOR_FormatYUVP010, אז:

‫[C-1-1] חובה לתמוך בפורמט P010 לקריאה של מעבד (ImageReader, ‏ MediaImage,‏ ByteBuffer). ב-Android 13, ‏ P010 מורחב כדי לאפשר צעדים שרירותיים למישורי Y ו-UV.
‫[C-1-2] מאגר הפלט P010 חייב להיות ניתן לדגימה על ידי GPU (כשהוא מוקצה עם שימוש ב-GPU_SAMPLING). ההגדרה הזו מאפשרת לאפליקציות להשתמש בהרכבה של GPU ובמיפוי טונים מותאם אישית.

אם דקודר וידאו מפרסם תמיכה ב-COLOR_Format32bitABGR2101010, הוא:

‫[C-2-1] חובה לתמוך בפורמט RGBA_1010102 עבור משטח הפלט ובפלט שניתן לקריאה על ידי CPU (פלט ByteBuffer).

אם מקודד וידאו מפרסם תמיכה ב-COLOR_FormatYUVP010, הוא:

‫[C-3-1] חובה לתמוך בפורמט P010 עבור משטח קלט וקלט שניתן לכתיבה על ידי CPU (ImageWriter, ‏ MediaImage, ‏ ByteBuffer).

אם מקודד וידאו מפרסם תמיכה ב-COLOR_Format32bitABGR2101010, הוא:

‫[C-4-1] חובה לתמוך בפורמט RGBA_1010102 עבור משטח קלט וקלט שניתן לכתיבה על ידי CPU (ImageWriter, ‏ ByteBuffer). הערה: אין צורך להמיר בין עקומות העברה שונות במקודדים.

הדרישות לצילום ב-HDR

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

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

אם הטמעות המכשיר תומכות בצילום HDR באמצעות ממשקי ה-API של CamcorderProfile:

‫[C-6-1] המכשיר חייב לתמוך בצילום HDR באמצעות ממשקי ה-API של Camera2.
‫[C-6-2] המכשיר חייב לתמוך לפחות במקודד וידאו אחד עם שיפור מהירות באמצעות חומרה לכל טכנולוגיית HDR נתמכת.
‫[C-6-3] המכשיר חייב לתמוך (לפחות) בצילום בפורמט HLG.
‫[C-6-4] חובה לתמוך בכתיבת המטא-נתונים של HDR (אם רלוונטי לטכנולוגיית ה-HDR) בקובץ הסרטון שצולם. במקרה של AV1, ‏ HEVC ו-DolbyVision, המשמעות היא הכללת המטא-נתונים בזרם הסיביות המקודד.
‫[C-6-5] חובה לתמוך ב-P010 וב-COLOR_FormatYUVP010.
‫[C-6-6] חובה לתמוך במיפוי טונים מ-HDR ל-SDR במפענח המוגדר כברירת מחדל עם האצת חומרה עבור הפרופיל שצולם. במילים אחרות, אם מכשיר יכול לצלם בפורמט HDR10+‎ HEVC, מפענח HEVC שמוגדר כברירת מחדל חייב להיות מסוגל לפענח את הזרם שצולם בפורמט SDR.

הדרישות לעריכת HDR

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

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

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

‫[C-7-1] המכשיר חייב לתמוך בפרופיל HDR אחד לפחות.
‫[C-7-2] חובה לתמוך ב-FEATURE_HdrEditing בכל פרופילי ה-HDR שרכיב הקודק הזה מפרסם. במילים אחרות, חובה לתמוך ביצירת מטא-נתונים של HDR כשאין מטא-נתונים כאלה בכל פרופילי ה-HDR הנתמכים שנעשה בהם שימוש במטא-נתונים של HDR.
‫[C-7-3] המכשיר חייב לתמוך בפורמטים הבאים של קלט מקודד וידאו, ששומרים באופן מלא על אות HDR מפוענח:
- ‫RGBA_1010102 (already in the target transfer curve) for both input surface and ByteBuffer and MUST advertise support for COLOR_Format32bitABGR2101010.

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

‫[C-7-4] חובה לפרסם תמיכה בתוסף EXT_YUV_target OpenGL.

הדרישות לגבי מסך HDR

אם הטמעות במכשירים מקבלות תוכן מאגר זמני שמקודד באמצעות ADATASPACE_TRANSFER_HLG, והתוכן הזה נשלח לתצוגה באמצעות SurfaceControl.Transaction#setBuffer, הן:

‫[C-8-1] חובה לפעול בהתאם להמלצה לגבי גרפיקה לבנה שמופיעה ב-BT. 2408-7, ולהציג את התוכן הזה רק אם הוא גדול פי 4.926 מתוכן SDR לכל היותר.

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

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

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

‫[C-0-1] חובה לתמוך בכלים למפתחי Android שמופיעים ב-Android SDK.
‫Android Debug Bridge (adb)
‫[C-0-2] חובה לתמוך ב-adb כפי שמתואר ב-Android SDK ובפקודות של מעטפת הפקודות (shell) שמופיעות ב-AOSP, שבהן יכולים להשתמש מפתחי אפליקציות, כולל dumpsys,‏ cmd stats ו-Simpleperf.
‫[C-0-11] חייבת להיות תמיכה בפקודת השורת הפקודה cmd testharness. יכול להיות שיישום של שדרוג מכשירים מגרסה קודמת של Android ללא בלוק נתונים קבוע יהיה פטור מדרישה C-0-11.
‫[C-0-3] אסור לשנות את הפורמט או את התוכן של אירועי מערכת המכשיר (batterystats, ‏ diskstats, ‏ fingerprint, ‏ graphicsstats, ‏ netstats,‏ notification, ‏ procstats) שנרשמים ביומן באמצעות הפקודה dumpsys.
‫[C-0-10] חובה לתעד, ללא השמטה, ולהפוך את האירועים הבאים לנגישים ולזמינים לפקודת shell‏ cmd stats ולמחלקת System API‏ StatsManager.
- ActivityForegroundStateChanged
- AnomalyDetected
- AppBreadcrumbReported
- AppCrashOccurred
- AppStartOccurred
- BatteryLevelChanged
- BatterySaverModeStateChanged
- BleScanResultReceived
- BleScanStateChanged
- ChargingStateChanged
- DeviceIdleModeStateChanged
- ForegroundServiceStateChanged
- GpsScanStateChanged
- InputDeviceUsageReported
- JobStateChanged
- KeyboardConfigured
- KeyboardSystemsEventReported
- PluggedStateChanged
- PressureStallInformation
- ScheduledJobStateChanged
- ScreenStateChanged
- SyncStateChanged
- SystemElapsedRealtime
- TouchpadUsage
- UidProcessStateChanged
- WakelockStateChanged
- WakeupAlarmOccurred
- WifiLockStateChanged
- WifiMulticastLockStateChanged
- WifiScanStateChanged
‫[C-0-4] שד ה-adb בצד המכשיר חייב להיות לא פעיל כברירת מחדל, וחייב להיות מנגנון שהמשתמש יכול לגשת אליו כדי להפעיל את Android Debug Bridge.
‫[C-0-5] חובה לתמוך ב-adb מאובטח. ‫Android כולל תמיכה ב-adb מאובטח. ‫adb מאובטח מאפשר להשתמש ב-adb במארחים מאומתים מוכרים.
‫[C-0-6] חובה לספק מנגנון שמאפשר להתחבר ל-adb ממחשב מארח. פרטים נוספים:

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

‫[C-3-1] חובה להטמיע את adb דרך רשת מקומית (כמו Ethernet או Wi-Fi).
‫[C-3-2] חובה לספק מנהלי התקנים ל-Windows 7, ‏ Windows 8 ו-Windows 10, כדי לאפשר למפתחים להתחבר למכשיר באמצעות פרוטוקול adb.

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

‫[C-4-1] הפונקציה AdbManager#isAdbWifiSupported() חייבת להחזיר את הערך true.

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

‫[C-5-1] הפונקציה AdbManager#isAdbWifiQrSupported() חייבת להחזיר true.
‫Dalvik Debug Monitor Service (ddms)
- ‫[C-0-7] חובה לתמוך בכל התכונות של ddms כפי שמתועד ב-Android SDK. מכיוון ש-ddms משתמש ב-adb, התמיכה ב-ddms צריכה להיות לא פעילה כברירת מחדל, אבל היא חייבת להיות נתמכת בכל פעם שהמשתמש מפעיל את Android Debug Bridge, כמו שמתואר למעלה.
‫SysTrace
- ‫[C-0-9] חייב לתמוך בכלי systrace כפי שמתואר ב-Android SDK. הכלי Systrace צריך להיות מושבת כברירת מחדל, וחייב להיות מנגנון שנגיש למשתמשים להפעלת Systrace.
‫Perfetto
- ‫[C-SR-1] מומלץ מאוד לחשוף /system/bin/perfetto קובץ בינארי למשתמש בשורת הפקודה, שתואם לשורת הפקודה למסמכי התיעוד של perfetto.
- ‫[C-SR-2] מומלץ מאוד לקבל את קובץ ה-binary של perfetto כקלט של הגדרת protobuf שתואמת לסכימה שמוגדרת במסמכי התיעוד של perfetto.
- ‫[C-SR-3] מומלץ מאוד להשתמש בבינארי של perfetto כדי לכתוב כפלט עקבות של protobuf שתואמים לסכימה שמוגדרת במסמכי התיעוד של perfetto.
- ‫[C-SR-4] מומלץ מאוד לספק, באמצעות קובץ הבינארי של perfetto, לפחות את מקורות הנתונים שמתוארים במסמכי התיעוד של perfetto.
Low Memory Killer
- ‫[C-0-12] חובה לכתוב LMK_KILL_OCCURRED_FIELD_NUMBER Atom ביומן statsd כשמפסיקים אפליקציה באמצעות Low Memory Killer.
מצב מסגרת בדיקה

אם הטמעות המכשירים תומכות בפקודת ה-Shell‏ cmd testharness ומריצות את הפקודה cmd testharness enable, הן:
- ‫[C-2-1] חובה להחזיר את הערך true עבור ActivityManager.isRunningInUserTestHarness()
- ‫[C-2-2] חובה ליישם מצב מסגרת בדיקה כפי שמתואר במסמכי התיעוד בנושא מצב מסגרת בדיקה.
מידע על עבודת ה-GPU

הטמעות במכשיר:
- ‫[C-0-13] חובה להטמיע את פקודת ה-shell‏ dumpsys gpu --gpuwork כדי להציג את נתוני העבודה המצטברים של ה-GPU שהוחזרו על ידי נקודת המעקב של ליבת power/gpu_work_period, או לא להציג נתונים אם נקודת המעקב לא נתמכת. ההטמעה ב-AOSP היא frameworks/native/services/gpuservice/gpuwork/.

אם הטמעות של מכשירים מדווחות על תמיכה ב-Vulkan 1.0 ומעלה באמצעות android.hardware.vulkan.version feature flags, הן:

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

אם הטמעות של מכשירים מגדירות את מאפייני המערכת graphics.gpu.profiler.support ו-graphics.gpu.profiler.support.gpu_frequency לערך true, הן:

‫[C-6-1] חובה לדווח על נקודת מעקב של תדר GPU בפורמט power/gpu_frequency, כפי שמוגדר ב-power.proto.

אם הטמעות של מכשירים מגדירות את שני מאפייני המערכת graphics.gpu.profiler.support ו-graphics.gpu.profiler.support.gpu_counters לערך true, הן:

‫[C-7-1] חובה לספק כלי ליצירת נתונים של Perfetto למקור נתונים בשם gpu.counters, שאפשר להריץ עליו שאילתות באמצעות: perfetto --query.
‫[C-7-2] חובה לדווח על תיאורי מוני ה-GPU בהתאם ל-GPU counter trace packet proto.
‫[C-7-3] חובה לדווח על ערכים תואמים עבור מוני ה-GPU של המכשיר בהתאם ל-proto של מנות מעקב של מוני GPU.
‫[C-7-4] חובה לתעד את תיאורי הטקסט של כל מוני ה-GPU המופעלים ללא חותמת זמן במעקב אחר perfetto.
‫[C-7-6] חובה לספק קבוצת ברירת מחדל לא ריקה של מוני ביצועים של GPU לצורך יצירת פרופילים, כפי שמפורט ב-GpuCounterSpec#select_by_default.
- חובה לאפשר הפעלה של כל מוני ברירת המחדל האלה בו-זמנית.
- כל הערכים האלה חייבים להישלח אל Perfetto כשהם מופעלים.
‫[C-7-7] חובה לשקף את השימוש ב-GPU לפחות עבור מונה אחד שנבחר כברירת מחדל, באמצעות GpuCounterSpec#select_by_default.

אם הטמעות של מכשירים מגדירות את מאפייני המערכת graphics.gpu.profiler.support ו-graphics.gpu.profiler.support.gpu_counters.period כ-true, הן:

‫[C-8-1] חובה לכבד את הערך של counter_period_ns עבור תדירות הדגימה של מוני ה-GPU. קצב הדגימה הנתמך חייב להיות 1ms או מהיר יותר.
‫[C-SR-5] מומלץ מאוד לתמוך בתדירות דגימה של 0.2 ms או מהירה יותר.

אם הטמעות של מכשירים מגדירות את מאפייני המערכת graphics.gpu.profiler.support ו-graphics.gpu.profiler.support.gpu_counters.groups כ-true, הן:

‫[C-9-1] חייב להיות לפחות מונה אחד בכל אחת מקבוצות המונים של ה-GPU הבאות, כפי שמצוין ב-GpuCounterSpec: ‏COMPUTE, ‏FRAGMENTS, ‏MEMORY, ‏PRIMITIVES ו-VERTICES.

אם בהטמעות של המכשיר מוגדרים שני מאפייני המערכת graphics.gpu.profiler.support ו-graphics.gpu.profiler.support.gpu_counters.groups כ-true, והמכשיר תומך במעקב אחר קרני אור, המאפיינים:

‫[C-10-1] חובה להוסיף מונה לקבוצה RAY_TRACING.

אם הטמעות של מכשירים מגדירות את מאפייני המערכת graphics.gpu.profiler.support ו-graphics.gpu.profiler.support.gpu_counters.zeroes_optimization כ-true, הן:

‫[C-11-1] באותו סשן של מעקב Perfetto, מונה ה-GPU חייב לדווח רק על ערכים אפסיים אם הערך הקודם או הבא שדווחו הם לא אפסיים.

אם הטמעות של מכשירים מגדירות את מאפייני המערכת graphics.gpu.profiler.support ו-graphics.gpu.profiler.support.render_stages כ-true, הן:

‫[C-12-1] חובה לספק מפיק נתונים של Perfetto למקור נתונים בשם gpu.renderstages, שאפשר לשלוח אליו שאילתות באמצעות perfetto --query.
‫[C-12-2] חובה לדווח על ערכים תואמים לשלבי רינדור של GPU בהתאם ל-GPU render stage event proto.

אם הטמעות של מכשירים מגדירות את מאפייני המערכת graphics.gpu.profiler.support ו-graphics.gpu.profiler.support.render_stages.queue_submit כ-true, הן:

‫[C-13-1] לכל קריאה לשליחת תור של Vulkan, הדרייבר של Vulkan חייב לפלוט אירוע למעקב ב-Perfetto בהתאם למפרט של הודעת האירוע של Vulkan API.
- האירוע הזה חייב להכיל submission_id ייחודי שגדל באופן מונוטוני, שתואם ל-submission_id באירוע המקביל של שלב העיבוד ב-GPU.

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

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

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

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

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

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

מערכת Android כוללת כלים להתאמה אוטומטית של נכסי אפליקציות ופריסות של ממשקי משתמש בהתאם למכשיר, כדי להבטיח שאפליקציות של צד שלישי יפעלו בצורה טובה במגוון תצורות ותצוגות של חומרה. צג שתואם ל-Android הוא מסך שמיישם את כל ההתנהגויות וממשקי ה-API שמתוארים במאמר Android Developers - Screen compatibility overview, בקטע הזה (7.1) ובקטעי המשנה שלו, וגם כל התנהגות נוספת שספציפית לסוג המכשיר ומפורטת בקטע 2 של מסמך ה-CDD הזה.

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

‫[C-0-1] חובה, כברירת מחדל, להציג אפליקציות של צד שלישי רק במסכים שתואמים ל-Android.

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

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

‫7.1.1. הגדרת תצורה של מסך

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

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

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

[C-0-1] חובה לדווח על גודל הפריסה הנכון של Configuration.screenLayout, כפי שמוגדר במסמכי ה-Android SDK. באופן ספציפי, הטמעות של מכשירים חייבות לדווח על המידות הנכונות של המסך בפיקסלים לוגיים שאינם תלויים בצפיפות (dp), כמו שמוצג בהמשך:
- במכשירים שבהם הערך של Configuration.uiMode הוא כל ערך אחר מלבד UI_MODE_TYPE_WATCH, ומוחזר גודל של small עבור Configuration.screenLayout, הגודל המינימלי צריך להיות 426dp x 320dp.
- במכשירים שמדווחים על גודל normal עבור Configuration.screenLayout, צריך להיות לפחות 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, כפי שמתואר במסמכי ה-SDK של Android.
יכול להיות שיש לו מסכים תואמי Android עם פינות מעוגלות.

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

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

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

‫[C-4-1] חובה שגודל הפריסה, לא כולל חיתוכי תצוגה, יהיה לפחות ‎596 dp x 384 dp או יותר.

פרטים על הטמעה נכונה של ממשקי ה-API של תוסף או של sidecar זמינים במסמכי העזרה הציבוריים של Window Manager Jetpack.

‫[C-4-1] הדרישה הוסרה ב-Android 15.

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

הקטע הזה הוסר ב-Android 14.

‫7.1.1.3. דחיסות מסך

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

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

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

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

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

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

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

בדיקות ה-dEQP של OpenGL ES מחולקות למספר רשימות בדיקה, שלכל אחת מהן משויך תאריך או מספר גרסה. הם נמצאים בעץ המקור של Android בכתובת external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt. מכשיר שתומך ב-OpenGL ES ברמה מסוימת לפי דיווח עצמי, מציין שהוא יכול לעבור את הבדיקות של dEQP בכל רשימות הבדיקות מהרמה הזו ומגרסאות קודמות.

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

‫[C-2-1] המכשיר חייב לדווח באמצעות ממשקי ה-API המנוהלים של OpenGL ES וממשקי ה-API המקוריים על כל תוספי OpenGL ES אחרים שהוא הטמיע, ולהיפך, הוא לא יכול לדווח על מחרוזות של תוספים שהוא לא תומך בהם.
‫[C-2-2] חובה לתמוך בתוספים EGL_KHR_image,‏ EGL_KHR_image_base,‏ EGL_ANDROID_image_native_buffer,‏ EGL_ANDROID_get_native_client_buffer,‏ EGL_KHR_wait_sync,‏ EGL_KHR_get_all_proc_addresses,‏ EGL_ANDROID_presentation_time,‏ EGL_KHR_swap_buffers_with_damage,‏ EGL_ANDROID_recordable ו-EGL_ANDROID_GLES_layers.
[C-2-3] חובה לדווח על הגרסה המקסימלית של בדיקות OpenGL ES dEQP שנתמכות באמצעות feature flag android.software.opengles.deqp.level.
‫[C-2-4] חובה לתמוך לפחות בגרסה 132383489 (מ-1 במרץ 2020) כפי שדווח בדגל התכונה android.software.opengles.deqp.level.
‫[C-2-5] המכשיר חייב לעבור את כל הבדיקות של OpenGL ES dEQP ברשימות הבדיקות בין גרסה 132383489 לבין הגרסה שצוינה בדגל התכונה android.software.opengles.deqp.level, לכל גרסה נתמכת של OpenGL ES.
‫[C-SR-2] מומלץ מאוד לתמוך בתוספים EGL_KHR_partial_update ו-OES_EGL_image_external.
צריכים לדווח בצורה מדויקת באמצעות השיטה getString() על כל פורמט דחיסה של טקסטורה שהם תומכים בו, שלרוב הוא ספציפי לספק.
מומלץ לתמוך בתוספים EGL_IMG_context_priority ו-EGL_EXT_protected_content.

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

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

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

‫[C-4-1] המכשיר חייב לתמוך בחבילת ההרחבות של 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, הן:

‫[C-SR-1] מומלץ מאוד לכלול תמיכה ב-Vulkan 1.3.
‫[C-4-1] אסור לתמוך בגרסת וריאציה של Vulkan (כלומר, החלק variant של גרסת הליבה של Vulkan חייב להיות אפס).

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

‫[C-SR-2] מומלץ מאוד לכלול תמיכה ב-Vulkan 1.3.

בדיקות ה-Vulkan dEQP מחולקות למספר רשימות בדיקה, שלכל אחת מהן משויך תאריך או גרסה. הם נמצאים בעץ המקור של Android בכתובת external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. מכשיר שתומך ב-Vulkan ברמה מסוימת לפי דיווח עצמי, מציין שהוא יכול לעבור את הבדיקות של dEQP בכל רשימות הבדיקות מהרמה הזו ומקודמות לה.

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

‫[C-1-1] חובה לדווח על ערך השלם הנכון באמצעות סימון התכונות android.hardware.vulkan.level ו-android.hardware.vulkan.version.
‫[C-1-2] חובה למנות לפחות VkPhysicalDevice אחד עבור Native API של Vulkan‏ vkEnumeratePhysicalDevices().
‫[C-1-3] חובה להטמיע באופן מלא את ממשקי ה-API של Vulkan 1.1 לכל VkPhysicalDevice שמופיע ברשימה.
‫[C-1-4] חובה למנות שכבות, שנכללות בספריות Native שנקראות libVkLayer*.so בספריית Native של חבילת האפליקציה, באמצעות ממשקי ה-API של Native‏ Vulkan‏ vkEnumerateInstanceLayerProperties() ו-vkEnumerateDeviceLayerProperties().

‫[C-1-5] אסור למנות שכבות שסופקו על ידי ספריות מחוץ לחבילת האפליקציה, או לספק דרכים אחרות למעקב אחר Vulkan API או ליירוט שלו, אלא אם המאפיין android:debuggable של האפליקציה מוגדר כ-true או שהמטא-נתונים com.android.graphics.injectLayers.enable מוגדרים כ-true , למעט שכבות של יצרני ציוד מקורי ופלטפורמות בהתאם לתיעוד בנושא הטמעה של Vulkan.

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

‫[C-1-7] חובה לתמוך בתוספים הבאים:
- VK_EXT_present_mode_fifo_latest_ready
- VK_KHR_present_wait2
- VK_KHR_android_surface
- VK_KHR_incremental_present
- VK_KHR_present_id
- VK_KHR_present_id2
- VK_KHR_surface
- VK_KHR_swapchain

‫[C-1-8] חובה לדווח על הגרסה המקסימלית של בדיקות Vulkan dEQP שנתמכות באמצעות דגל התכונה android.software.vulkan.deqp.level.
‫[C-1-9] חובה לתמוך לפחות בגרסה 132317953 (מ-1 במרץ 2019) כפי שמדווח בדגל התכונה android.software.vulkan.deqp.level.
‫[C-1-10] חובה לעבור את כל הבדיקות של Vulkan dEQP ברשימות הבדיקה בין גרסה 132317953 לבין הגרסה שצוינה בדגל התכונה android.software.vulkan.deqp.level.
‫[C-1-11] אסור למנות תמיכה בתוספים VK_KHR_video_queue,‏ VK_KHR_video_decode_queue או VK_KHR_video_encode_queue.

‫[C-SR-3] מומלץ מאוד לתמוך בתוספים הבאים:
- VK_EXT_present_timing
- VK_GOOGLE_display_timing
- VK_KHR_driver_properties

‫[C-1-12] אסור למנות תמיכה בתוסף VK_KHR_performance_query
‫[C-SR-4] מומלץ מאוד לעמוד בדרישות שצוינו בפרופיל Android Baseline 2022.
‫[C-SR-5] מומלץ מאוד לתמוך ב-VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory וב-VK_EXT_global_priority.
‫[C-SR-6] מומלץ מאוד להשתמש ב-SkiaVk עם HWUI.

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

‫[C-SR-8] מומלץ מאוד לא לשנות את טוען Vulkan.
‫[C-1-14] אסור למנות תוספים של מכשיר Vulkan מהסוגים KHR,‏ GOOGLE או ANDROID, אלא אם התוספים האלה נכללים בדגל התכונה android.software.vulkan.deqp.level.

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

‫[C-2-1] אסור להצהיר על אף אחד ממתגי ה-feature flag של Vulkan (לדוגמה, android.hardware.vulkan.level, android.hardware.vulkan.version).
‫[C-2-2] אסור למנות VkPhysicalDevice כלשהם עבור Vulkan Native API‏ vkEnumeratePhysicalDevices().

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

‫[C-3-1] חובה לחשוף תמיכה בSYNC_FD סוגי סמפור חיצוניים וסוגי נקודות אחיזה ובתוסף VK_ANDROID_external_memory_android_hardware_buffer.
‫[C-SR-7] מומלץ מאוד להפוך את התוסף לזמין לאפליקציות של צד שלישי ולאפשר לאפליקציה לייצא מטען ייעודי (payload) של גדר גיאוגרפית אל מתארי קבצים של POSIX ולייבא מטען ייעודי (payload) של גדר גיאוגרפית ממתארי קבצים של POSIX, כפי שמתואר כאן.VK_KHR_external_fence_fd

‫7.1.4.3. RenderScript

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

‫[C-0-1] חובה לתמוך ב-Android RenderScript, כמו שמפורט בתיעוד של Android SDK.

‫7.1.4.4. האצת עיבוד גרפי בדו-ממד

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

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

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

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

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

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

‫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-1] מומלץ מאוד לתמוך ב-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] חובה להצהיר על ה-feature flag‏ android.software.input_methods.
‫[C-1-2] חובה להטמיע באופן מלא את Input Management Framework
‫[C-1-3] חובה לכלול מקלדת וירטואלית שמותקנת מראש.

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

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

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

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

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

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

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

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

‫7.2.3. מקשי ניווט

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

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

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

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

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

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

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

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

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

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

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

‫[C-4-1] חובה להנגיש את פונקציית העזרה באמצעות פעולה אחת (למשל הקשה, לחיצה כפולה או תנועה) כשלחצני ניווט אחרים נגישים.
‫[C-SR-3] מומלץ מאוד להשתמש בלחיצה ארוכה על פונקציית HOME כאינטראקציה המיועדת הזו.

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

‫[C-5-1] מקשי הניווט צריכים להשתמש בחלק נפרד של המסך, שלא זמין לאפליקציות, ואסור להם להסתיר את החלק של המסך שזמין לאפליקציות או להפריע לו בדרך אחרת.
‫[C-5-2] חובה להקצות חלק מהמסך לאפליקציות שעומדות בדרישות שמוגדרות בסעיף 7.1.1.
‫[C-5-3] חובה לכבד את ההגדרות שנקבעו על ידי האפליקציה באמצעות ה-method‏ View.setSystemUiVisibility() של API, כך שהחלק הנפרד הזה במסך (שנקרא גם סרגל הניווט) יוסתר בצורה תקינה, כפי שמתואר במסמכי ה-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] פונקציית הניווט חייבת להיות 'חזרה' ולהיות זמינה כהחלקה משני הקצוות – הימני והשמאלי – של המסך בכיוון הנוכחי.
‫[C-7-2] אם יש חלוניות מערכת מותאמות אישית שאפשר להחליק כדי לפתוח אותן בקצוות הימני או השמאלי, הן צריכות להיות ממוקמות בשליש העליון של המסך, עם אינדיקציה חזותית ברורה וקבועה שגרירה פנימה תפתח את החלוניות האלה, ולא תפעיל את לחצן 'הקודם'. משתמש יכול להגדיר חלונית מערכת כך שהיא תופיע מתחת לשליש העליון של קצה המסך, אבל חלונית המערכת לא יכולה להשתמש ביותר משליש מקצה המסך.
‫[C-7-3] כשהאפליקציה שפועלת בחזית מכילה את הדגלים View.SYSTEM_UI_FLAG_IMMERSIVE,‏ View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY,‏ WindowInsetsController.BEHAVIOR_DEFAULT או WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, החלקות מהקצוות חייבות לפעול כמו שהן מיושמות ב-AOSP, כפי שמתואר במסמכי ה-SDK.
‫[C-7-4] אם באפליקציה שפועלת בחזית מוגדרים הדגלים View.SYSTEM_UI_FLAG_IMMERSIVE,‏ View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY,‏ WindowInsetsController.BEHAVIOR_DEFAULT או WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, חובה להסתיר את חלוניות המערכת המותאמות אישית שניתן להחליק כדי לפתוח אותן עד שהמשתמש יציג את סרגלי המערכת (כלומר, סרגל הניווט וסרגל המצב) או יבטל את ההאפלה שלהם, כמו שמוטמע ב-AOSP.

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

‫[C-8-1] חובה לקרוא ל-OnBackInvokedCallback.onBackCancelled().
‫[C-8-2] אסור לקרוא ל-OnBackInvokedCallback.onBackInvoked().
‫[C-8-3] אסור לשלוח את האירוע KEYCODE_BACK.

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

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

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

‫[C-9-1] חובה לספק תמיכה בסמלים ידידותיים לילדים או בניווט מבוסס-לחצנים, כפי שמופיע בקוד AOSP.

‫7.2.4. קלט ממסך מגע

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

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

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

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

‫[C-1-1] חובה לדווח על TOUCHSCREEN_FINGER בשדה Configuration.touchscreen של ה-API.
‫[C-1-2] חובה לדווח על סימון התכונות android.hardware.touchscreen ו-android.hardware.faketouch.

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

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

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

‫[C-3-1] אסור לדווח על אף דגל תכונה שמתחיל ב-android.hardware.touchscreen.
‫[C-3-2] חובה לדווח רק על android.hardware.faketouch.
‫[C-3-3] חובה לדווח על TOUCHSCREEN_NOTOUCH בשדה Configuration.touchscreen של ה-API.

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

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

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

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

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

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

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

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

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

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

‫[C-2-1] חובה להצהיר על ה-feature flag‏ android.hardware.gamepad

כפתור	שימוש ב-HID²	Android Button
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
כפתורי החיצים (D-pad) למעלה¹ כפתורי החיצים (D-pad) למטה¹	0x01 0x0039³	‫AXIS_HAT_Y⁴
כפתורי החיצים (D-pad) שמאלה1 כפתורי החיצים (D-pad) ימינה¹	0x01 0x0039³	‫AXIS_HAT_X⁴
לחצן כתף שמאלי¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
לחצן ימני עליון¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
לחיצה על הסטיק השמאלי¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
לחיצה על הסטיק הימני¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
הקודם¹	0x0c 0x0224	KEYCODE_BACK (4)

‫1 KeyEvent

‫2 השימושים ב-HID שצוינו למעלה חייבים להיות מוצהרים ב-Game pad CA ‏ (0x01 0x0005).

‫3 השימוש הזה צריך לכלול Logical Minimum של 0,‏ Logical Maximum של 7,‏ Physical Minimum של 0,‏ Physical Maximum של 315,‏ Units in Degrees ו-Report Size של 4. הערך הלוגי מוגדר כסיבוב בכיוון השעון מהציר האנכי. לדוגמה, ערך לוגי של 0 מייצג מצב ללא סיבוב ולחיצה על לחצן החלק העליון, בעוד שערך לוגי של 1 מייצג סיבוב של 45 מעלות ולחיצה על המקשים 'חלק עליון' ו'שמאלה'.

‫4 MotionEvent

פקדים אנלוגיים¹	שימוש ב-HID	Android Button
Left Trigger	0x02 0x00C5	AXIS_LTRIGGER
הדק ימני	0x02 0x00C4	AXIS_RTRIGGER
הג'ויסטיק השמאלי	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
הג'ויסטיק הימני	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

‫1 MotionEvent

‫7.2.7. שליטה מרחוק

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

7.3. חיישנים

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

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

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

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

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

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

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

‫[C-1-6] חובה להגדיר רזולוציה שונה מאפס לכל החיישנים, ולדווח על הערך באמצעות שיטת ה-API ‏Sensor.getResolution().

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

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

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

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

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

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

‫[C-3-1] חובה להגדיר את הרזולוציה ל-1 עבור החיישן ולדווח על הערך באמצעות שיטת ה-API‏ Sensor.getResolution().

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

‫[C-4-1] אסור לכלול בנתונים שסופקו פרמטרים קבועים של כיול שנקבעו במפעל.

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

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

‫7.3.1. מד תאוצה

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

‫[C-SR-1] מומלץ מאוד לכלול מד תאוצה ב-3 צירים.

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

‫[C-1-1] המכשיר חייב להיות מסוגל לדווח על אירועים בתדירות של 50 Hz לפחות.
‫[C-1-3] חובה לעמוד בדרישות של מערכת הקואורדינטות של חיישן Android כמו שמפורט בממשקי ה-API של Android.
‫[C-1-4] המכשיר חייב להיות מסוגל למדוד נפילה חופשית עד פי ארבעה מ-gravity(4g) או יותר בכל ציר.
‫[C-1-5] הרזולוציה חייבת להיות לפחות 12 ביט.
‫[C-1-6] סטיית התקן חייבת להיות קטנה או שווה ל-0.05 מ'/ש'^, כאשר סטיית התקן צריכה להיות מחושבת על בסיס כל ציר בנפרד על דגימות שנאספו במשך תקופה של לפחות 3 שניות בקצב הדגימה המהיר ביותר.
צריך לדווח על אירועים בתדירות של 200 Hz לפחות.
מומלץ שהרזולוציה תהיה לפחות 16 ביט.
צריך לבצע כיול בזמן השימוש אם המאפיינים משתנים במהלך מחזור החיים, ולבצע פיצוי, ולשמור את פרמטרי הפיצוי בין הפעלות מחדש של המכשיר.
צריך להיות עם פיצוי טמפרטורה.

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

‫[C-2-1] חובה להטמיע את חיישן TYPE_ACCELEROMETER ולדווח עליו.
‫[C-SR-4] מומלץ מאוד להטמיע את TYPE_SIGNIFICANT_MOTION החיישן המורכב.
‫[C-SR-5] מומלץ מאוד להטמיע ולדווח על חיישן TYPE_ACCELEROMETER_UNCALIBRATED. מומלץ מאוד שמכשירי Android יעמדו בדרישה הזו כדי שיהיה אפשר לשדרג אותם לגרסת הפלטפורמה הבאה, שבה יכול להיות שהדרישה הזו תהיה חובה.
מומלץ להטמיע את החיישנים המורכבים TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR,‏ TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER כפי שמתואר במסמך Android SDK.

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

‫[C-3-1] חובה להטמיע את חיישן TYPE_ACCELEROMETER_LIMITED_AXES ולדווח עליו.
‫[C-SR-6] מומלץ מאוד להטמיע ולדווח על חיישן TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

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

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

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

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

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

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

‫7.3.2. מגנטומטר

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

‫[C-SR-1] מומלץ מאוד לכלול מגנטומטר (מצפן) ב-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.
‫[C-1-10] חובה להטמיע את החיישן TYPE_MAGNETIC_FIELD_UNCALIBRATED.

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

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

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

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

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

‫[C-3-1] צריכת החשמל חייבת להיות פחות מ-10 mW.
החיישן צריך לצרוך פחות מ-3 mW כשהוא רשום למצב אצווה בתדר של 10 Hz.

‫7.3.3. GPS

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

‫[C-SR-1] מומלץ מאוד לכלול מקלט GPS/GNSS.

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

‫[C-1-1] המכשיר חייב לתמוך בפלט של מיקום בקצב של 1 Hz לפחות כשמבקשים זאת באמצעות LocationManager#requestLocationUpdate.
‫[C-1-2] המכשיר חייב להיות מסוגל לקבוע את המיקום בתנאי שמיים פתוחים (אותות חזקים, ריבוי נתיבים זניח, HDOP < 2) תוך 10 שניות (זמן מהיר עד לתיקון הראשון), כשהוא מחובר לחיבור אינטרנט עם מהירות נתונים של 0.5 Mbps או יותר. הדרישה הזו מתקיימת בדרך כלל באמצעות שימוש בטכניקה כלשהי של GPS/GNSS מסוג Assisted או Predicted, כדי לצמצם את זמן הנעילה של GPS/GNSS (נתוני הסיוע כוללים זמן ייחוס, מיקום ייחוס ונתוני אפמריס/שעון של לוויין).
- ‫[C-1-6] אחרי ביצוע חישוב מיקום כזה, הטמעות של מכשירים חייבות לקבוע את המיקום שלהם, בשמיים פתוחים, תוך 5 שניות, כשבקשות המיקום מופעלות מחדש, עד שעה אחרי חישוב המיקום הראשוני, גם כשמגישים את הבקשה הבאה ללא חיבור נתונים, ו/או אחרי הפעלה מחדש.
בתנאי שמיים פתוחים אחרי קביעת המיקום, כשנמצאים במצב נייח או בתנועה עם תאוצה של פחות ממטר אחד לשנייה בריבוע:
- ‫[C-1-3] המכשיר חייב להיות מסוגל לקבוע את המיקום בטווח של 20 מטרים, ואת המהירות בטווח של 0.5 מטרים לשנייה, לפחות ב-95% מהזמן.
- ‫[C-1-4] חובה לעקוב אחרי לפחות 8 לוויינים מקבוצת לוויינים אחת ולדווח עליהם בו-זמנית באמצעות GnssStatus.Callback.
- צריך להיות מסוגל לעקוב בו-זמנית אחרי לפחות 24 לוויינים מכמה קבוצות כוכבים (למשל, GPS + לפחות אחד מהלוויינים Glonass,‏ Beidou,‏ Galileo).
‫[C-SR-2] מומלץ מאוד להמשיך לספק פלט רגיל של מיקום GPS/GNSS באמצעות ממשקי API של ספק מיקום GNSS במהלך שיחת טלפון במקרה חירום.
‫[C-SR-3] מומלץ מאוד לדווח על מדידות GNSS מכל המערכות לווייניות שנמצאות במעקב (כפי שמדווח בהודעות GnssStatus), למעט SBAS.
‫[C-SR-4] מומלץ מאוד לדווח על AGC ועל התדירות של מדידת GNSS.
‫[C-SR-5] מומלץ מאוד לדווח על כל הערכות הדיוק (כולל כיוון, מהירות וגובה) כחלק מכל מיקום GPS/GNSS.
‫[C-SR-6] מומלץ מאוד לדווח על מדידות GNSS ברגע שהן נמצאות, גם אם מיקום שמחושב מ-GPS/GNSS עדיין לא דווח.
‫[C-SR-7] מומלץ מאוד לדווח על טווחי פסאודו ועל קצב שינוי טווחי פסאודו של GNSS, שבתנאי שמיים פתוחים אחרי קביעת המיקום, במצב נייח או בתנועה עם תאוצה של פחות מ-0.2 מטר לשנייה בריבוע, מספיקים לחישוב המיקום בטווח של 20 מטרים והמהירות בטווח של 0.2 מטרים לשנייה, לפחות ב-95% מהזמן.

‫7.3.4. ג'ירוסקופ

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

‫[C-SR-1] מומלץ מאוד לכלול חיישן ג'ירוסקופ.

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

‫[C-1-1] המכשיר חייב להיות מסוגל לדווח על אירועים בתדירות של 50 Hz לפחות.
‫[C-1-4] הרזולוציה חייבת להיות 12 ביט ומעלה.
‫[C-1-5] חייב להיות עם מדידת פיצוי טמפרטורה.
‫[C-1-6] חובה לכייל ולבצע פיצוי בזמן השימוש, ולשמור את פרמטרי הפיצוי בין הפעלות מחדש של המכשיר.
‫[C-1-7] השונות לא יכולה להיות גדולה מ-‎1e-7 rad^2 / s^2 per Hz (variance per Hz, or rad^2 / s). השונות יכולה להשתנות בהתאם לקצב הדגימה, אבל היא חייבת להיות מוגבלת על ידי הערך הזה. במילים אחרות, אם מודדים את השונות של הג'ירוסקופ בקצב דגימה של 1 Hz, היא לא צריכה להיות גדולה מ-‎1e-7 rad^2/s^2.
‫[C-SR-2] מומלץ מאוד ששגיאת הכיול תהיה קטנה מ-0.01 רדיאן/שנייה כשהמכשיר נייח בטמפרטורת החדר.
‫[C-SR-3] מומלץ מאוד שהרזולוציה תהיה 16 ביט או יותר.
צריך לדווח על אירועים בתדירות של 200 Hz לפחות.

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

‫[C-2-1] חובה להטמיע את TYPE_GYROSCOPE החיישן.
‫[C-SR-4] מומלץ מאוד להטמיע חיישן TYPE_GYROSCOPE_UNCALIBRATED.

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

‫[C-3-1] חובה להטמיע את חיישן TYPE_GYROSCOPE_LIMITED_AXES ולדווח עליו.
‫[C-SR-5] מומלץ מאוד להטמיע ולדווח על חיישן TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

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

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

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

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

‫7.3.5. ברומטר

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

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

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

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

הטמעות של מכשירים שמצהירות על מאפיין המערכת sensor.barometer.high_quality.implemented:

‫[C-2-1] חובה לדווח על מדידות לחץ בטווח של 300 hPa עד 1,100 hPa, עם דיוק מוחלט של ‎+/- 1 hPa.
‫[C-2-2] חובה שיהיה דיוק יחסי של 0.15 hPa בטווח של 100 hPa , ששווה לדיוק של ‎~1 m בשינוי של ‎~1,000 m בגובה פני הים.
‫[C-2-3] המכשיר חייב להיות יציב בטווח של ‎+/- 0.5 hPa כשמשתמש מקיש על המכשיר, לוחץ עליו או סוחט אותו.
‫[C-2-4] חייב להיות יציב בטווח של ‎+/- 0.15 hPa כשמשתמש הולך עם המכשיר ביד או בכיס.
‫[C-2-5] אסור לבצע החלקה עם קבוע זמן של יותר מ-300 ms להפעלות מעל 5 Hz, ואסור שההחלקה תזלוג בין הפעלות של חיישנים.
[C-2-6] חייב להיות יציב בטווח של ‎+/- 0.15 hPa כשחושפים אותו לתאורה ולתדרי רדיו יומיומיים ממקורות נפוצים כמו Bluetooth, חיבור לרשת סלולרית או Wi-Fi.

‫7.3.6. מדחום

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

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

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

‫[C-2-1] אסור להגדיר SENSOR_TYPE_AMBIENT_TEMPERATURE לחיישן הטמפרטורה.

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

‫[C-SR-1] מומלץ מאוד לתמוך בממשק ה-API‏ PowerManager.getThermalHeadroom.

‫7.3.7. פוטומטר

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

‫7.3.8. חיישן קירבה

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

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

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

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

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

‫[C-1-1] חובה לזהות את היכולת באמצעות feature flag‏ android.hardware.sensor.hifi_sensors.

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

‫[C-2-1] חובה לכלול חיישן TYPE_ACCELEROMETER ש:
- חייב להיות לו טווח מדידה של לפחות ‎-8g עד ‎+8g, ומומלץ מאוד שיהיה לו טווח מדידה של לפחות ‎-16g עד ‎+16g.
- חייבת להיות רזולוציית מדידה של לפחות 2048 LSB/g.
- חייב להיות בעל תדירות מדידה מינימלית של 12.5 Hz או פחות.
- חייב להיות בעל תדירות מדידה מקסימלית של 400 Hz ומעלה; צריך לתמוך ב-SensorDirectChannel RATE_VERY_FAST.
- חייב להיות רעש מדידה שלא עולה על ‎400 μg/√Hz.
- חובה להטמיע חיישן מסוג non-wake-up עם יכולת אחסון בזיכרון של לפחות 3,000 אירועים של החיישן.
- צריכת החשמל של העיבוד באצווה לא יכולה להיות גבוהה מ-3 mW.
- ‫[C-SR-1] מומלץ מאוד להשתמש ברוחב פס למדידה של 3 dB, של לפחות 80% מתדירות נייקוויסט, ובספקטרום של רעש לבן בתוך רוחב הפס הזה.
- צריך להיות בעל תאוצה אקראית של פחות מ-30 μg √Hz שנבדקה בטמפרטורת החדר.
- צריך להיות שינוי הטיה לעומת טמפרטורה של ‎≤ +/- 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.5 Hz או פחות.
- חייב להיות בעל תדירות מדידה מקסימלית של 400 Hz ומעלה; צריך לתמוך ב-SensorDirectChannel RATE_VERY_FAST.
- חייב להיות בעל רעש מדידה שלא עולה על ‎0.014&°/s/√Hz.
- ‫[C-SR-2] מומלץ מאוד להשתמש ברוחב פס למדידה של 3 dB, שהוא לפחות 80% מתדירות נייקוויסט, ובספקטרום של רעש לבן בתוך רוחב הפס הזה.
- צריך להיות בעל שיעור של הליכה אקראית (random walk) של פחות מ-0.001°‎/s √Hz שנבדק בטמפרטורת החדר.
- צריכה להיות הטיה של ≤ ‎+/- 0.05&°/ s / °C ביחס לטמפרטורה.
- רמת הרגישות צריכה להשתנות בהתאם לטמפרטורה בשיעור של ‎≤ 0.02% / °C.
- צריך לכלול קו בעל ההתאמה הטובה ביותר עם אי-ליניאריות של ‎≤ 0.2%‎.
- צריכה להיות לו צפיפות רעש של ‎≤ 0.007&°/s/√Hz.
- צריכה להיות שגיאת כיול קטנה מ-0.002 rad/s בטווח הטמפרטורה 10 עד 40 מעלות צלזיוס כשהמכשיר נייח.
- רצוי שתהיה רגישות ל-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.
- חייב להיות בעל תדירות מדידה מינימלית של 5 Hz או פחות.
- חייב להיות בעל תדירות מדידה מקסימלית של 50 Hz ומעלה.
- חייב להיות בעל רעשי מדידה שלא עולים על 0.5 מיקרוטסלה.
‫[C-2-6] חובה לכלול TYPE_MAGNETIC_FIELD_UNCALIBRATED עם אותן דרישות איכות כמו TYPE_GEOMAGNETIC_FIELD, ובנוסף:
- חובה להטמיע חיישן כזה שלא מפעיל את המכשיר, עם יכולת אחסון בזיכרון של לפחות 600 אירועים של החיישן.
- ‫[C-SR-3] מומלץ מאוד להשתמש בספקטרום של רעש לבן מ-1 Hz עד 10 Hz לפחות כשקצב הדיווח הוא 50 Hz ומעלה.
‫[C-2-7] חייב להיות חיישן TYPE_PRESSURE ש:
- חייב להיות לו טווח מדידה של לפחות 300 עד 1,100 hPa.
- חייבת להיות רזולוציית מדידה של לפחות 80 LSB/hPa.
- חייב להיות בעל תדירות מדידה מינימלית של 1 Hz או פחות.
- חייב להיות בעל תדירות מדידה מקסימלית של 10 הרץ ומעלה.
- חייב להיות רעש מדידה שלא עולה על ‎2 Pa/√Hz.
- חובה להטמיע חיישן כזה שלא מפעיל את המכשיר, עם יכולת אחסון בזיכרון של לפחות 300 אירועים של החיישן.
- צריכת החשמל של העיבוד באצווה חייבת להיות טובה מ-2 mW.
‫[C-2-8] חובה לכלול חיישן TYPE_GAME_ROTATION_VECTOR.
‫[C-2-9] חובה לכלול חיישן TYPE_SIGNIFICANT_MOTION ש:
- צריכת האנרגיה לא יכולה להיות גבוהה מ-0.5 mW כשהמכשיר נייח, ומ-1.5 mW כשהמכשיר בתנועה.
‫[C-2-10] חובה לכלול חיישן TYPE_STEP_DETECTOR ש:
- חובה להטמיע חיישן כזה שלא מפעיל את המכשיר, עם יכולת אחסון בזיכרון הזמני של לפחות 100 אירועים של החיישן.
- צריכת האנרגיה לא יכולה להיות גבוהה מ-0.5 mW כשהמכשיר נייח, ומ-1.5 mW כשהמכשיר בתנועה.
- צריכת החשמל של העיבוד באצווה לא יכולה להיות גבוהה מ-4 mW.
‫[C-2-11] חייב להיות חיישן TYPE_STEP_COUNTER ש:
- צריכת האנרגיה לא יכולה להיות גבוהה מ-0.5 mW כשהמכשיר נייח, ומ-1.5 mW כשהמכשיר בתנועה.
‫[C-2-12] חובה לכלול חיישן TILT_DETECTOR ש:
- צריכת האנרגיה לא יכולה להיות גבוהה מ-0.5 mW כשהמכשיר נייח, ומ-1.5 mW כשהמכשיר בתנועה.
‫[C-2-13] חותמת הזמן של האירוע הפיזי זהה לזו שדווחה על ידי מד התאוצה, הג'ירוסקופ והמגנטומטר, וההפרש ביניהן לא יכול להיות גדול מ-2.5 אלפיות השנייה. חותמת הזמן של האירוע הפיזי זהה לזו שדווחה על ידי מד התאוצה והג'ירוסקופ, וההפרש ביניהן צריך להיות עד 0.25 אלפיות השנייה.
‫[C-2-14] חותמות הזמן של אירועי חיישן הג'ירוסקופ חייבות להיות באותו בסיס זמן כמו מערכת המשנה של המצלמה, עם שגיאה של עד אלפית השנייה.
‫[C-2-15] חובה לספק דגימות לאפליקציות תוך 5 אלפיות השנייה מהרגע שבו הנתונים זמינים באחד מהחיישנים הפיזיים שלמעלה לאפליקציה.
‫[C-2-16] צריכת החשמל לא יכולה להיות גבוהה מ-0.5 mW כשהמכשיר נייח ומ-2.0 mW כשהמכשיר בתנועה, כשמופעל שילוב כלשהו של החיישנים הבאים:
- 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. חיישנים ביומטריים

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

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

מומלץ לכלול חיישן ביומטרי

חיישנים ביומטריים יכולים להיות מסווגים כרמה 3 (לשעבר חזק),

‫Class 2 (לשעבר Weak) או Class 1 (לשעבר Convenience) על סמך שיעורי הקבלה של זיוף והתחזות, ועל סמך האבטחה של צינור הנתונים הביומטריים. הסיווג הזה קובע את היכולות של החיישן הביומטרי ליצור אינטראקציה עם הפלטפורמה ועם אפליקציות של צד שלישי. כדי שחיישנים יסווגו כסוג 1, סוג 2 או סוג 3, הם צריכים לעמוד בדרישות נוספות שמפורטות בהמשך. לנתונים ביומטריים ברמה 2 וברמה 3 יש יכולות נוספות, כמו שמפורט בהמשך.

אם הטמעות במכשיר מאפשרות לאפליקציות של צד שלישי לגשת לחיישן ביומטרי באמצעות android.hardware.biometrics.BiometricManager,‏ android.hardware.biometrics.BiometricPrompt ו-android.provider.Settings.ACTION_BIOMETRIC_ENROLL, הן:

‫[C-4-1] המכשיר חייב לעמוד בדרישות לנתונים ביומטריים ברמה 3 או ברמה 2, כפי שמוגדר במסמך הזה.
‫[C-4-2] המערכת חייבת לזהות ולכבד כל שם פרמטר שמוגדר כקבוע במחלקה Authenticators וכל שילוב שלהם. לעומת זאת, אסור לכבד או לזהות קבועים מסוג integer שמועברים לשיטות canAuthenticate(int) ו-setAllowedAuthenticators(int), מלבד אלה שמתועדים כקבועים ציבוריים ב-Authenticators וכל השילובים שלהם.
‫[C-4-3] חובה להטמיע את הפעולה ACTION_BIOMETRIC_ENROLL במכשירים עם נתונים ביומטריים ברמה 3 או ברמה 2. הפעולה הזו חייבת להציג רק את נקודות הכניסה להרשמה לנתונים ביומטריים מסוג רמה 3 או רמה 2.
‫[C-4-4] חובה לאפשר לאפליקציות להוסיף תוכן בהתאמה אישית ל-BiometricPrompt באמצעות פורמטים של הצגת תוכן PromptContentView. אסור להרחיב את פורמטי התצוגה של התוכן כדי לאפשר הצגה של תמונות, קישורים, תוכן אינטראקטיבי או סוגים אחרים של מדיה שלא נכללים כבר ב-BiometricPromptAPI. מותר לבצע התאמות סגנוניות שלא משנות את התוכן הזה, לא מסתירות אותו ולא חותכות אותו (כמו שינוי המיקום, הריווח הפנימי, השוליים והטיפוגרפיה).

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

‫[C-5-1] כברירת מחדל, המערכת חייבת לדרוש שלב אישור נוסף (לדוגמה, לחיצה על לחצן).
‫[C-SR-1] מומלץ מאוד להוסיף הגדרה שתאפשר למשתמשים לבטל את ההעדפות של האפליקציה ולדרוש תמיד שלב אישור נלווה.
‫[C-SR-2] מומלץ מאוד לאבטח את פעולת האישור כך שמערכת הפעלה או ליבת מערכת שנפרצו לא יוכלו לזייף אותה. לדוגמה, המשמעות היא שפעולת האישור שמבוססת על לחצן פיזי מנותבת דרך פין קלט/פלט (GPIO) לשימוש כללי שהוא רק קלט של רכיב מאובטח (SE), שלא ניתן להפעיל אותו בשום דרך אחרת מלבד לחיצה על לחצן פיזי.
‫[C-5-2] בנוסף, האפליקציה חייבת להטמיע תהליך אימות מרומז (ללא שלב אישור) שמתאים ל-setConfirmationRequired(boolean), שאפליקציות יכולות להגדיר כדי להשתמש בו בתהליכי כניסה.

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

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

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

‫[C-6-1] חובה לעמוד בדרישות של Class 3 כפי שמוגדרות בקטע הזה בהמשך.
‫[C-6-2] חובה להציג רק נתונים ביומטריים ברמה 3 כשהאימות דורש BIOMETRIC_STRONG, או כשהאימות מופעל באמצעות CryptoObject.

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

‫[C-1-1] שיעור הקבלה השגוי (FAR) חייב להיות נמוך מ-0.002%.
‫[C-1-2] אם שיעורי הקבלה של זיוף והתחזות גבוהים מ-7% כפי שנמדד על ידי פרוטוקולי הבדיקה של נתונים ביומטריים ב-Android, חובה לציין שהמצב הזה עשוי להיות פחות מאובטח מקוד אימות, קו פתיחת נעילה או סיסמה חזקים, ולפרט באופן ברור את הסיכונים בהפעלת המצב הזה.
[C-1-9] המערכת חייבת לבקש מהמשתמש את שיטת האימות העיקרית המומלצת (למשל, קוד אימות, קו פתיחת נעילה, סיסמה) אחרי לא יותר מעשרים ניסיונות כושלים, ולא לפני שחלפו לפחות תשעים שניות מאז ההשהיה לפני ניסיון חוזר לאימות ביומטרי – ניסיון כושל הוא ניסיון עם איכות לכידה מספקת (BIOMETRIC_ACQUIRED_GOOD) שלא תואם לנתונים ביומטריים רשומים.
‫[C-SR-4] מומלץ מאוד להקטין את המספר הכולל של ניסיונות בחינם כוזבים לאימות ביומטרי שצוין ב-‎[C-1-9] אם שיעורי הקבלה של זיוף ומתחזים גבוהים מ-7% כפי שנמדד על ידי פרוטוקולי הבדיקה של Android Biometrics.
‫[C-1-3] חובה להגביל את מספר הניסיונות לאימות ביומטרי – כאשר ניסיון כושל הוא ניסיון עם איכות לכידה מספקת (BIOMETRIC_ACQUIRED_GOOD) שלא תואמת לנתונים ביומטריים רשומים.
‫[C-SR-5] מומלץ מאוד להגביל את מספר הניסיונות ל-5 ניסיונות שגויים לאימות ביומטרי למשך 30 שניות לפחות, בהתאם למספר המקסימלי של ניסיונות שגויים לכל [C-1-9] – ניסיון שגוי הוא ניסיון עם איכות לכידה מספקת (BIOMETRIC_ACQUIRED_GOOD) שלא תואם לנתונים ביומטריים רשומים.
‫[C-SR-6] מומלץ מאוד להשתמש בכל הלוגיקה של הגבלת קצב הבקשות ב-TEE.
‫[C-1-10] חובה להשבית את הנתונים הביומטריים אחרי שההשהיה של האימות הראשי הופעלה בפעם הראשונה, כפי שמתואר ב-‫[C-0-2] בקטע 9.11.
‫[C-1-11] קצב קבלת הזיוף והמתחזים לא יכול להיות גבוה מ-30%, עם (1) קצב קבלת הזיוף והמתחזים עבור מינים של מכשיר להתקפת הצגה (PAI) ברמה א' שלא גבוה מ-30%, ועם (2) קצב קבלת הזיוף והמתחזים של מינים של מכשיר להתקפת הצגה (PAI) ברמה ב' שלא גבוה מ-40%, כפי שנמדד על ידי פרוטוקולי הבדיקה של Android Biometrics.
‫[C-1-4] המכשיר חייב למנוע הוספה של נתונים ביומטריים חדשים בלי ליצור קודם שרשרת מהימנות, על ידי כך שהמשתמש יאשר נתונים קיימים או יוסיף נתונים חדשים לאימות המכשיר (קוד אימות, תבנית או סיסמה) שמאובטחים על ידי TEE. ההטמעה של Android Open Source Project מספקת את המנגנון במסגרת הפעולה כדי לעשות זאת.
‫[C-1-5] חובה להסיר לחלוטין את כל הנתונים הביומטריים שניתן לזהות של משתמש כשמסירים את החשבון שלו (כולל באמצעות איפוס להגדרות המקוריות) או כשמסירים את שיטת האימות הראשית המומלצת (כמו קוד אימות, קו פתיחת נעילה או סיסמה).
‫[C-1-6] חובה לכבד את הדגל האישי של אותו נתון ביומטרי (כלומר, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT,‏ DevicePolicymanager.KEYGUARD_DISABLE_FACE או DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
‫[C-1-7] המערכת חייבת לדרוש מהמשתמש אימות ראשי מומלץ (כמו קוד אימות, קו ביטול נעילה או סיסמה) פעם ב-24 שעות או פחות.
‫[C-1-8] המערכת חייבת לבקש מהמשתמש לבצע אימות ראשי מומלץ (כמו קוד אימות, קו ביטול נעילה או סיסמה) או אימות ביומטרי מסוג 3 (חזק) אחרי כל אחד מהמקרים הבאים:
- תקופת המתנה של 4 שעות עד שהחיבור ינותק.
- 3 ניסיונות כושלים של אימות ביומטרי.
- תקופת ההמתנה עד שהחיבור ינותק ומספר ניסיונות האימות הכושלים מתאפסים אחרי כל אישור מוצלח של פרטי הכניסה של המכשיר.
‫[C-SR-7] מומלץ מאוד להשתמש בלוגיקה במסגרת שסופקה על ידי פרויקט הקוד הפתוח של Android כדי לאכוף את האילוצים שצוינו ב-‫[C-1-7] וב-‫[C-1-8] במכשירים חדשים.
‫[C-SR-8] מומלץ מאוד ששיעור הדחייה השגוי יהיה נמוך מ-10%, כפי שנמדד במכשיר.
‫[C-SR-9] מומלץ מאוד שזמן האחזור יהיה מתחת לשנייה אחת, מהרגע שבו זוהה נתון ביומטרי ועד שהמסך נפתח, עבור כל נתון ביומטרי רשום.
‫[C-1-12] שיעור הקבלה של זיוף ומתחזה לא יעלה על 40% לכל סוג של מכשיר לביצוע מתקפת הצגה (PAI), כפי שנמדד על ידי פרוטוקולי הבדיקה של Android Biometrics.
‫[C-SR-13] מומלץ מאוד ששיעור הקבלה של זיוף ומתחזה לא יהיה גבוה מ-30% לכל סוג של מכשיר להתקפת הצגה (PAI), כפי שנמדד על ידי פרוטוקולי הבדיקה של אמצעי הזיהוי הביומטריים ב-Android.
‫[C-SR-8] מומלץ מאוד ששיעור הדחייה השגוי יהיה נמוך מ-10%, כפי שנמדד במכשיר.
‫[C-1-15] המערכת חייבת לאפשר למשתמשים להסיר רישום של נתונים ביומטריים בודדים או מרובים.
‫[C-SR-14] מומלץ מאוד לחשוף את הסיווג הביומטרי של החיישן הביומטרי ואת הסיכונים הכרוכים בהפעלתו.
[C-SR-17] מומלץ מאוד להטמיע את ממשקי ה-AIDL החדשים (לדוגמה, IFace.aidl ו-IFingerprint.aidl).

אם רוצים להגדיר חיישן ביומטרי במכשיר כרמה 2 (לשעבר חלש), צריך:

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

הערה: אם יישומי המכשיר כבר הושקו ב-Android בגרסה 9 ומטה, ולא ניתן לעמוד בדרישה [C-2-8] באמצעות עדכון של תוכנת המערכת, יכול להיות שיהיה פטור מהדרישה.
‫[C-SR-10] מומלץ מאוד לכלול זיהוי של נוכחות אדם חי בכל השיטות הביומטריות, וזיהוי של תשומת לב בשיטות ביומטריות של הפנים.
‫[C-2-9] חובה להפוך את החיישן הביומטרי לזמין לאפליקציות של צד שלישי.

אם רוצים להגדיר חיישן ביומטרי במכשיר כרמה 3 (לשעבר חזק), צריך:

‫[C-3-1] חייב לעמוד בכל הדרישות של סיווג 2 שפורטו למעלה, למעט [C-1-7] ו- [C-1-8].
‫[C-3-2] חובה להטמיע חנות מפתחות עם גיבוי חומרה.
‫[C-3-3] שיעור הקבלה של מתחזים וזיופים לא יעלה על 7%, עם (1) שיעור קבלה של מתחזים וזיופים עבור מינים של מכשירים לזיוף הצגה (PAI) ברמה א' שלא יעלה על 7%, ו-(2) שיעור קבלה של מתחזים וזיופים של מינים של מכשירי PAI ברמה ב' שלא יעלה על 20%, כפי שנמדד על ידי פרוטוקולי הבדיקה של Android Biometrics.
‫[C-3-4] חובה לבקש מהמשתמש אימות ראשי מומלץ (כמו קוד אימות, קו ביטול נעילה או סיסמה) פעם ב-72 שעות או פחות.
‫[C-3-5] חובה ליצור מחדש מזהה אמצעי אימות לכל הנתונים הביומטריים ברמה 3 שנתמכים במכשיר אם נרשם מחדש אחד מהם.
‫[C-3-6] חובה להפעיל מפתחות של חנות מפתחות עם אימות ביומטרי לאפליקציות של צד שלישי.
‫[C-SR-16] מומלץ מאוד ששיעור הקבלה של התחזות ומתחזה לא יהיה גבוה מ-7% לכל מין של מכשיר להתקפת הצגה (PAI), כפי שנמדד על ידי פרוטוקולי הבדיקה של אמצעי הזיהוי הביומטריים של Android.

אם הטמעות המכשירים מכילות חיישן טביעות אצבע מתחת למסך (UDFPS), הן:

[C-SR-11] מומלץ מאוד למנוע את ההפרעה של אזור המגע של UDFPS לניווט ב-3 כפתורים (שחלק מהמשתמשים עשויים להזדקק לו למטרות נגישות).

‫7.3.11. חיישן תנוחה

הטמעות במכשיר:

יכול להיות שיש תמיכה בחיישן תנוחה עם 6 דרגות חופש.

אם הטמעות המכשירים תומכות בחיישן תנוחה עם 6 דרגות חופש, הן:

‫[C-1-1] חובה להטמיע את חיישן TYPE_POSE_6DOF ולדווח עליו.
‫[C-1-2] חייב להיות מדויק יותר מווקטור הסיבוב בלבד.

‫7.3.12. חיישן זווית הציר

אם הטמעות המכשירים תומכות בחיישן זווית הציר, הן:

‫[C-1-1] חובה להטמיע ולדווח על TYPE_HINGE_ANGLE.
‫[C-1-2] המכשיר חייב לתמוך לפחות בשתי קריאות בין 0 ל-360 מעלות (כולל, כלומר כולל 0 ו-360 מעלות).
‫[C-1-3] חייב להחזיר חיישן התעוררות עבור getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

‫7.3.13. IEEE 802.1.15.4 (UWB)

אם הטמעות המכשירים כוללות תמיכה ב-802.1.15.4 וחושפות את הפונקציונליות לאפליקציה של צד שלישי, הן:

‫[C-1-2] חובה לדווח על דגל התכונה של החומרה android.hardware.uwb.
‫[C-1-3] חובה לתמוך בכל קבוצות ההגדרות הבאות (שילובים מוגדרים מראש של פרמטרים של FIRA UCI) שמוגדרות בהטמעה של AOSP.
- ‫CONFIG_ID_1: מדידת טווח חד-שידור STATIC STS DS-TWR בהגדרה של FiRa, מצב דחוי, מרווח מדידת הטווח הוא 240 אלפיות השנייה.
- ‫CONFIG_ID_2: טווח STATIC STS DS-TWR אחד לרבים שמוגדר על ידי FiRa, מצב דחוי, מרווח טווח של 200 אלפיות השנייה. תרחיש שימוש אופייני: טלפון חכם באינטראקציה עם הרבה מכשירים חכמים.
- ‫CONFIG_ID_3: כמו CONFIG_ID_1, אבל לא מדווחים נתונים של זווית ההגעה (AoA).
- ‫CONFIG_ID_4: זהה ל-CONFIG_ID_1, אבל מצב האבטחה P-STS מופעל.
- ‫CONFIG_ID_5: זהה ל-CONFIG_ID_2, אבל מצב האבטחה P-STS מופעל.
- ‫CONFIG_ID_6: זהה ל-CONFIG_ID_3, אבל מצב האבטחה P-STS מופעל.
- ‫CONFIG_ID_7: זהה ל-CONFIG_ID_2, אלא שמצב המקשים של P-STS individual controlee מופעל.
‫[C-1-4] חובה לספק למשתמש אפשרות להפעיל או להשבית את מצב הרדיו של UWB.
‫[C-1-5] חובה לאכוף את ההרשאה UWB_RANGING (במסגרת קבוצת ההרשאות NEARBY_DEVICES) באפליקציות שמשתמשות ברדיו UWB.

כדי לוודא שפרוטוקול 802.1.15.4 פועל בצורה תקינה, חשוב לעבור את בדיקות התאימות והאישורים הרלוונטיות שמוגדרות על ידי ארגוני סטנדרטים, כולל FIRA,‏ CCC ו-CSA.

‫7.3.14. חיישנים בהתאמה אישית

כדי לספק חוויה ייחודית, הטמעות של מכשירים עשויות לכלול חיישנים נוספים שלא נכללים ב-Android או ב-Wear OS, שאפליקציות שנטענו מראש יכולות לגשת אליהם.

עבור חיישנים כאלה, מזהה החיישן:

‫[C-0-1] הערך חייב להיות גבוה מ-65536.

אם החיישן המותאם אישית מיועד למטרות שקשורות לבריאות או לכושר, הוא:

‫[C-0-2] חובה להגן על הפונקציה באמצעות הרשאה של הפלטפורמה או הרשאה של המערכת.

‫7.4. קישוריות נתונים

‫7.4.1. טלפוניה

המונח 'טלפוניה' כפי שמשתמשים בו בממשקי ה-API של Android ובמסמך הזה מתייחס באופן ספציפי לחומרה שקשורה לביצוע שיחות קוליות ולשליחת הודעות SMS, או ליצירת חיבור לאינטרנט עם חבילת גלישה דרך רשת סלולרית (למשל, GSM, ‏ CDMA, ‏ LTE, ‏ NR) GSM או CDMA. מכשיר שתומך ב'טלפוניה' יכול להציע חלק משירותי השיחות, ההודעות והנתונים או את כולם, בהתאם למוצר.

יכול להיות שיהיה אפשר להשתמש ב-Android במכשירים שלא כוללים חומרה לטלפוניה. כלומר, Android תואמת למכשירים שהם לא טלפונים.

אם הטמעות המכשירים כוללות טלפוניה של GSM או CDMA, הן:

‫[C-1-1] חובה להצהיר על feature flag‏ android.hardware.telephony ועל feature flags אחרים של תכונות משנה בהתאם לטכנולוגיה.
‫[C-1-2] חובה להטמיע תמיכה מלאה ב-API של הטכנולוגיה הזו.
צריכה להיות אפשרות להשתמש בכל סוגי שירותי הסלולר הזמינים (2G,‏ 3G,‏ 4G,‏ 5G וכו') במהלך שיחות חירום (ללא קשר לסוגי הרשת שהוגדרו על ידי SetAllowedNetworkTypeBitmap()).

אם הטמעות המכשירים לא כוללות חומרת טלפוניה, הן:

‫[C-2-1] חובה להטמיע את כל ממשקי ה-API כפעולות שלא עושות כלום (no-ops).

אם ההטמעות במכשיר תומכות ב-eUICC או ב-eSIM/כרטיסי SIM מוטמעים וכוללות מנגנון קנייני להנגשת הפונקציונליות של eSIM למפתחים של צד שלישי, הן:

‫[C-3-1] חובה להצהיר על ה-feature flag‏ android.hardware.telephony.euicc.

אם הטמעות של מכשירים לא מגדירות את מאפיין המערכת ro.telephony.iwlan_operation_mode לערך legacy, הן:

‫[C-4-1] אסור לדווח על NETWORK_TYPE_IWLAN באמצעות NetworkRegistrationInfo#getAccessNetworkTechnology() כשמדווח על NetworkRegistrationInfo#getTransportType() בתור TRANSPORT_TYPE_WWAN עבור אותו מופע של NetworkRegistrationInfo.

אם הטמעות במכשירים תומכות ברישום יחיד של IP Multimedia Subsystem‏ (IMS) גם עבור תכונות של שירות טלפוניה מולטימדיה (MMTEL) וגם עבור שירות תקשורת מגוון (RCS), והן צפויות לעמוד בדרישות של ספקי סלולר לגבי שימוש ברישום יחיד של IMS לכל תנועת האיתות של IMS, הן:

[C-5-1] חובה להצהיר על android.hardware.telephony.ims feature flag ולספק הטמעה מלאה של ImsService API עבור MMTEL ו-RCS User Capability Exchange API.
‫[C-5-2] חובה להצהיר על android.hardware.telephony.ims.singlereg דגל התכונה ולספק הטמעה מלאה של SipTransport API,‏ GbaService API,‏ ייעודי bearer indications באמצעות IRadio 1.6 HAL, והקצאת הרשאות באמצעות Auto Configuration Server ‏ (ACS) או מנגנון קנייני אחר להקצאת הרשאות באמצעות IMS Configuration API.

אם הטמעות המכשיר מדווחות על התכונה android.hardware.telephony, אז:

‫[C-6-1] הפונקציות SmsManager#sendTextMessage ו-SmsManager#sendMultipartTextMessage חייבות להוביל לקריאות תואמות לפונקציה CarrierMessagingService כדי לספק פונקציונליות של הודעות טקסט. ‫SmsManager#sendMultimediaMessage ו-SmsManager#downloadMultimediaMessage חייבות להוביל לקריאות תואמות אל ‫CarrierMessagingService כדי לספק פונקציונליות של הודעות מולטימדיה.
‫[C-6-2] האפליקציה שצוינה על ידי android.provider.Telephony.Sms#getDefaultSmsPackage חייבת להשתמש בממשקי API של SmsManager כששולחים ומקבלים הודעות SMS ו-MMS. ההטמעה של AOSP ב-packages/apps/Messaging עומדת בדרישה הזו.
‫[C-6-3] האפליקציה שמגיבה ל-Intent#ACTION_DIAL חייבת לתמוך בהזנה של קודי חיוג שרירותיים בפורמט *#*#CODE#*#* ולהפעיל שידור תואם של TelephonyManager#ACTION_SECRET_CODE.
[C-6-4] האפליקציה שמגיבה ל-Intent#ACTION_DIAL חייבת להשתמש ב-VoicemailContract.Voicemails#TRANSCRIPTION כדי להציג למשתמשים תמלול של רשימת הודעות קוליות, אם היא תומכת בתמלולים של רשימת הודעות קוליות.
‫[C-6-5] חובה לייצג את כל SubscriptionInfo עם מזהי UUID מקבילים של קבוצות כמנוי יחיד בכל הממשקים שגלויים למשתמשים ומציגים את פרטי כרטיס ה-SIM ומאפשרים לשלוט בהם. דוגמאות לממשקי הגדרות שמתאימים ל-Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS או ל-EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.
‫[C-6-6] אסור להציג או לאפשר שליטה ב-SubscriptionInfo עם UUID של קבוצה שאינו null וביט אופורטוניסטי בכל ממשקי משתמש שמאפשרים הגדרה או שליטה בהגדרות של כרטיס ה-SIM.

אם הטמעות המכשירים מדווחות על התכונה android.hardware.telephony ומספקות סרגל סטטוס של המערכת, אז:

‫[C-7-1] חובה לבחור מינוי פעיל מייצג עבור UUID של קבוצה מסוימת כדי להציג למשתמש בכל אמצעי גישה שמספק מידע על סטטוס כרטיס ה-SIM. דוגמאות לאפשרויות כאלה כוללות את סמל האות הסלולרית בשורת הסטטוס או את הכפתור בהגדרות המהירות.
‫[C-SR-1] מומלץ מאוד לבחור את המינוי המייצג כמינוי הנתונים הפעיל, אלא אם המכשיר נמצא בשיחה קולית. במקרה כזה, מומלץ מאוד שהמינוי המייצג יהיה המינוי הפעיל לשיחות קוליות.

אם הטמעות המכשיר מדווחות על התכונה android.hardware.telephony, אז:

‫[C-6-7] המכשיר חייב להיות מסוגל לפתוח את המספר המקסימלי של ערוצים לוגיים (20 בסך הכול) לכל כרטיס UICC, ולהשתמש בהם בו-זמנית, בהתאם לתקן ETSI TS 102 221.
‫[C-6-8] אסור להחיל באופן אוטומטי או ללא אישור מפורש מהמשתמש את ההתנהגויות הבאות על אפליקציות פעילות של ספקי סלולר (כפי שמצוין על ידי TelephonyManager#getCarrierServicePackageName):
- ביטול או הגבלה של הגישה לרשת
- ביטול הרשאות
- הגבלת ההרצה של אפליקציות ברקע או אפליקציה שפועלת בחזית מעבר לתכונות הקיימות לניהול צריכת החשמל שכלולות ב-AOSP
- השבתה או הסרה של האפליקציה

אם יישומי המכשיר מדווחים על התכונה android.hardware.telephony ועל כל המינויים הפעילים, שאינם אופורטוניסטיים שמשתפים UUID של קבוצה מושבתים, מוסרים פיזית מהמכשיר או מסומנים כאופורטוניסטיים, אז המכשיר:

‫[C-8-1] חובה להשבית באופן אוטומטי את כל המינויים הפעילים שנותרו לרכישה בהזדמנות באותה קבוצה.

אם הטמעות המכשירים כוללות טלפוניה של GSM אבל לא של CDMA, הן:

‫[C-9-1] אסור להצהיר על PackageManager#FEATURE_TELEPHONY_CDMA.
[C-9-2] חובה להקפיץ הודעת שגיאה (throw) IllegalArgumentException בניסיון להגדיר סוגי רשתות 3GPP2 במסיכות ביטים של סוג רשת מועדף או מותר.
‫[C-9-3] חייבת להחזיר מחרוזת ריקה מ-TelephonyManager#getMeid.

אם הטמעות המכשיר תומכות ב-eUICC עם מספר יציאות ופרופילים, הן:

‫[C-10-1] חובה להצהיר על ה-feature flag‏ android.hardware.telephony.euicc.mep.

אם הטמעות המכשירים תומכות בקישוריות של נתונים סלולריים, הן:

‫[C-SR-11] מומלץ מאוד להצהיר על התכונה android.hardware.telephony.data.

אם הטמעות של מכשירים מדווחות על android.hardware.telephony.data, הן:

‫[C-12-1] המכשיר חייב לתמוך לפחות בשני חיבורים בו-זמניים לרשת סלולרית, כמו הקשרים של PDP, חיבורי PDN וחיבורי DN.

‫7.4.1.1. תאימות לחסימת מספרים

אם הטמעות של מכשירים מדווחות על התכונה android.hardware.telephony.calling הן:

‫[C-1-1] חובה לכלול תמיכה בחסימת מספרים
‫[C-1-2] חובה להטמיע באופן מלא את BlockedNumberContract ואת ה-API המתאים, כפי שמתואר בתיעוד של ה-SDK.
‫[C-1-3] חובה לחסום את כל השיחות וההודעות ממספר טלפון ב-BlockedNumberProvider ללא אינטראקציה עם אפליקציות. החריג היחיד הוא כשביטול חסימת המספרים מבוטל באופן זמני, כפי שמתואר במסמכי ה-SDK.
‫[C-1-4] חובה לכתוב אל ספק יומן השיחות של הפלטפורמה לגבי שיחה חסומה, וחובה לסנן שיחות עם BLOCKED_TYPE מתוך תצוגת ברירת המחדל של יומן השיחות באפליקציית החייגן שהותקנה מראש.
‫[C-1-5] אסור לכתוב אל ספק הטלפוניה עבור הודעה חסומה.
‫[C-1-6] חובה להטמיע ממשק משתמש לניהול מספרים חסומים, שנפתח באמצעות הכוונה שמוחזרת על ידי השיטה TelecomManager.createManageBlockedNumbersIntent().
‫[C-1-7] אסור לאפשר למשתמשים משניים להציג או לערוך את המספרים החסומים במכשיר, כי פלטפורמת Android מניחה שלמשתמש הראשי יש שליטה מלאה בשירותי הטלפוניה, מופע יחיד, במכשיר. כל ממשק המשתמש שקשור לחסימה צריך להיות מוסתר ממשתמשים משניים, ועדיין צריך להתייחס לרשימת החסימה.
צריך להעביר את המספרים החסומים לספק כשהמכשיר מתעדכן ל-Android 7.0.
מומלץ לספק למשתמשים אפשרות להצגת שיחות חסומות באפליקציית החייגן שהותקנה מראש.

‫7.4.1.2. Telecom API

אם בהטמעות של מכשירים מוצהרים הערכים android.hardware.microphone ו-android.hardware.audio.output, ולא מוצהר הערך android.hardware.type.television, המכשירים:

‫[C-0-1] חובה להצהיר על ה-feature flag‏ android.software.telecom.
‫[C-0-2] חובה להטמיע את מסגרת הטלקום.

אם הטמעות של מכשירים מדווחות על android.hardware.telephony.calling, הן:

‫[C-1-1] חובה לתמוך בממשקי ה-API של ConnectionService שמתוארים ב-SDK.
‫[C-1-2] חובה להציג שיחה נכנסת חדשה ולאפשר למשתמש לקבל או לדחות את השיחה הנכנסת כשהמשתמש נמצא בשיחה פעילה שמתבצעת דרך אפליקציית צד שלישי שלא תומכת בתכונת ההמתנה שצוינה באמצעות CAPABILITY_SUPPORT_HOLD.
‫[C-1-3] חובה להשתמש באפליקציה שמטמיעה את InCallService.
‫[C-SR-1] מומלץ מאוד להודיע למשתמש שמענה לשיחה נכנסת ינתק שיחה פעילה.

ההטמעה של AOSP עומדת בדרישות האלה באמצעות התראת "שימו לב" שמציינת למשתמש שאם הוא יענה לשיחה נכנסת, השיחה השנייה תנותק.
‫[C-SR-2] מומלץ מאוד לטעון מראש את אפליקציית החייגן שמוגדרת כברירת מחדל, שמציגה רשומה ביומן השיחות ואת השם של אפליקציית צד שלישי ביומן השיחות שלה, כשאפליקציית הצד השלישי מגדירה את מפתח התוספים EXTRA_LOG_SELF_MANAGED_CALLS ב-PhoneAccount ל-true.
‫[C-SR-3] מומלץ מאוד לטפל באירועים KEYCODE_MEDIA_PLAY_PAUSE ו-KEYCODE_HEADSETHOOK של אוזניות השמע עבור ממשקי ה-API של android.telecom באופן הבא:
- התקשרות Connection.onDisconnect() כשמזוהה לחיצה קצרה על אירוע המקש במהלך שיחה פעילה.
- הפונקציה Call Connection.onAnswer() מופעלת כשמזוהה לחיצה קצרה על אירוע המקש במהלך שיחה נכנסת.
- הפונקציה Call Connection.onReject() מופעלת כשמזוהה לחיצה ארוכה על אירוע המקש במהלך שיחה נכנסת.
- השתקה או ביטול השתקה של CallAudioState.

‫7.4.1.3. הפחתת עומס של הודעות Keepalive ב-NAT-T ברשת סלולרית

הטמעות במכשיר:

צריך לכלול תמיכה בהעברת עומס של שמירת חיבור סלולרי.

אם הטמעות של מכשירים כוללות תמיכה בהעברת עומס של שמירת חיבור סלולרי פעיל (Cellular keepalive offload) וחושפות את הפונקציונליות לאפליקציות של צד שלישי, הן:

‫[C-1-1] חובה לתמוך ב-SocketKeepAlive API.
‫[C-1-2] המכשיר חייב לתמוך לפחות במשבצת אחת של שמירת חיבור בו-זמנית ברשת סלולרית.
‫[C-1-3] חובה לתמוך בכמה שיותר משבצות זמן בו-זמניות של שמירת חיבור סלולרי פעיל, בהתאם לתמיכה ב-HAL של רדיו סלולרי.
‫[C-SR-1] מומלץ מאוד לתמוך בלפחות שלושה משבצות זמן לשידור אותות חיים סלולריים לכל מופע רדיו.

אם הטמעות המכשירים לא כוללות תמיכה בהעברת עומס של שמירת חיבור סלולרי, הן:

‫[C-2-1] חובה להחזיר ERROR_UNSUPPORTED.

‫7.4.2. IEEE 802.11 (Wi-Fi)

הטמעות במכשיר:

צריך לכלול תמיכה בצורה אחת או יותר של 802.11.

אם הטמעות המכשירים כוללות תמיכה ב-802.11 וחושפות את הפונקציונליות לאפליקציה של צד שלישי, הן:

‫[C-1-1] חובה להטמיע את ממשק ה-API התואם ל-Android.
‫[C-1-2] חובה לדווח על דגל התכונה של החומרה android.hardware.wifi.
‫[C-1-3] חובה להטמיע את multicast API כפי שמתואר במסמכי ה-SDK.
‫[C-1-4] חובה לתמוך ב-mDNS ואסור לסנן חבילות mDNS ‏(224.0.0.251 או ff02::fb) בכל זמן פעולה, כולל כשהמסך לא במצב פעיל, אלא אם נעילת ה-multicast לא מוחזקת והחבילות מסוננות על ידי APF. החבילות לא נדרשות כדי לבצע פעולות mDNS שמוגדרות כרגע באפליקציות דרך ממשקי ה-API של NsdManager. עם זאת, המכשיר עשוי לסנן חבילות mDNS אם הסינון נדרש כדי לעמוד בטווחים של צריכת החשמל שנדרשים לפי הדרישות הרגולטוריות שחלות על שוק היעד.
‫[C-1-5] אסור להתייחס להפעלת method של WifiManager.enableNetwork() API כאל אינדיקציה מספקת להחלפת Network הפעיל כרגע, שמשמש כברירת מחדל לתעבורת נתונים של אפליקציות ומוחזר על ידי methods של ConnectivityManager API כמו getActiveNetwork ו-registerDefaultNetworkCallback. במילים אחרות, הם יכולים להשבית את הגישה לאינטרנט שסופקה על ידי כל ספק רשת אחר (למשל, חבילת גלישה) רק אם הם מאמתים בהצלחה שרשת ה-Wi-Fi מספקת גישה לאינטרנט.
‫[C-1-6] מומלץ מאוד, כשקוראים לשיטת ה-API‏ ConnectivityManager.reportNetworkConnectivity(), להעריך מחדש את הגישה לאינטרנט ב-Network, וכשההערכה קובעת ש-Network הנוכחי כבר לא מספק גישה לאינטרנט, לעבור לכל רשת זמינה אחרת (למשל, נתונים סלולריים) שמספקת גישה לאינטרנט.
‫[C-1-7] חובה להגריל את כתובת ה-MAC של המקור ואת המספר הסידורי של מסגרות בקשת הבדיקה, פעם אחת בתחילת כל סריקה, בזמן שה-STA מנותק.
‫[C-1-8] חובה להשתמש בכתובת MAC עקבית אחת (אסור להקצות כתובת MAC אקראית באמצע הסריקה).
‫[C-1-9] חובה לבצע איטרציה של מספר הרצף של בקשת הבדיקה כרגיל (באופן עוקב) בין בקשות הבדיקה בסריקה.
‫[C-1-10] חובה להקצות מספר רצף אקראי לבקשת בדיקה בין בקשת הבדיקה האחרונה של סריקה לבין בקשת הבדיקה הראשונה של הסריקה הבאה.
‫[C-SR-1] מומלץ מאוד להקצות באופן אקראי את כתובת ה-MAC של המקור שמשמשת לכל התקשורת של STA לנקודת גישה (AP) בזמן השיוך והשיוך.
- המכשיר חייב להשתמש בכתובת MAC רנדומלית שונה לכל SSID (FQDN for Passpoint) שהוא מתקשר איתו.
- המכשיר חייב לספק למשתמש אפשרות לשלוט באקראיות לכל SSID (FQDN ל-Passpoint) עם אפשרויות לא אקראיות ואקראיות, וחייב להגדיר את מצב ברירת המחדל להגדרות חדשות של Wi-Fi כאקראי.
‫[C-SR-2] מומלץ מאוד להשתמש ב-BSSID אקראי לכל נקודת גישה שהם יוצרים.
- כתובת ה-MAC חייבת להיות אקראית וקבועה לכל SSID שמשמש את נקודת הגישה.
- יכול להיות שהמכשיר יציע למשתמש אפשרות להשבית את התכונה הזו. אם קיימת אפשרות כזו, חובה להפעיל את האקראיות כברירת מחדל.

אם ההטמעות במכשיר כוללות תמיכה במצב חיסכון בצריכת חשמל ב-Wi-Fi, כפי שמוגדר בתקן IEEE 802.11, הן:

צריך להשבית את מצב החיסכון באנרגיה של 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-3] מומלץ מאוד לצמצם את זמן האחזור של הלוך ושוב ב-Wi-Fi בכל פעם שמתבצעת נעילה של זמן אחזור קצר (WIFI_MODE_FULL_LOW_LATENCY) ונכנסת לתוקף.

אם הטמעות המכשירים תומכות ב-Wi-Fi ומשתמשות ב-Wi-Fi לסריקת מיקום, הן:

‫[C-2-1] חובה לספק למשתמש אפשרות להפעיל או להשבית את קריאת הערך באמצעות רכיב ה-method של WifiManager.isScanAlwaysAvailable API.

‫7.4.2.1. Wi-Fi ישיר

הטמעות במכשיר:

צריך לכלול תמיכה ב-Wi-Fi Direct (Wi-Fi peer-to-peer).

אם הטמעות המכשירים כוללות תמיכה ב-Wi-Fi ישיר, הן:

‫[C-1-1] חובה להטמיע את ה-API המתאים ל-Android כפי שמתואר במסמכי ה-SDK.
‫[C-1-2] חובה לדווח על תכונת החומרה android.hardware.wifi.direct.
‫[C-1-3] חובה לתמוך בפעולה רגילה של Wi-Fi.
‫[C-1-4] חובה לתמוך בפעולות של Wi-Fi ו-Wi-Fi Direct בו-זמנית.
[C-SR-1] מומלץ מאוד ליצור כתובת MAC אקראית למקור של כל החיבורים החדשים שנוצרים ב-Wi-Fi ישיר.

‫7.4.2.2. הגדרה של קישור ישיר עם מנהור Wi-Fi

הטמעות במכשיר:

מומלץ לכלול תמיכה בהגדרה של קישור ישיר במנהור Wi-Fi‏ (TDLS), כפי שמתואר בתיעוד של Android SDK.

אם הטמעות המכשירים כוללות תמיכה ב-TDLS וה-TDLS מופעל על ידי ה-API של WiFiManager, הן:

‫[C-1-1] חובה להצהיר על תמיכה ב-TDLS באמצעות WifiManager.isTdlsSupported.
מומלץ להשתמש ב-TDLS רק אם הדבר אפשרי ומועיל.
צריך להשתמש בהיוריסטיקה כלשהי ולא להשתמש ב-TDLS אם הביצועים שלה עלולים להיות גרועים יותר מאשר שימוש בנקודת הגישה ל-Wi-Fi.

‫7.4.2.3. Wi-Fi Aware

הטמעות במכשיר:

צריך לכלול תמיכה ב-Wi-Fi Aware.

אם ההטמעות של המכשירים כוללות תמיכה ב-Wi-Fi Aware וחושפות את הפונקציונליות לאפליקציות של צד שלישי, הן:

‫[C-1-1] חובה להטמיע את ממשקי ה-API של WifiAwareManager כפי שמתואר בתיעוד ה-SDK.
‫[C-1-2] חובה להצהיר על השימוש ב-feature flag‏ android.hardware.wifi.aware.
‫[C-1-3] חובה לתמוך בפעולות של Wi-Fi ו-Wi-Fi Aware בו-זמנית.
‫[C-1-4] חובה להקצות כתובת אקראית לממשק הניהול של Wi-Fi Aware במרווחי זמן של עד 30 דקות, ובכל פעם ש-Wi-Fi Aware מופעל, אלא אם מתבצעת פעולת מדידת מרחק של Aware או שפעיל נתיב נתונים של 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

אם הטמעות של מכשירים כוללות תמיכה ב-802.11 (Wi-Fi), הן:

צריך לכלול תמיכה ב-Wi-Fi Passpoint.

אם הטמעות המכשירים כוללות תמיכה ב-Wi-Fi Passpoint, הן:

‫[C-1-2] חובה להטמיע את ממשקי ה-API שקשורים ל-Passpoint WifiManagerכפי שמתואר בתיעוד של ה-SDK.
‫[C-1-3] חובה לתמוך בתקן IEEE 802.11u, במיוחד בנושאים שקשורים לחיפוש ולבחירה של רשתות, כמו Generic Advertisement Service‏ (GAS) ו-Access Network Query Protocol‏ (ANQP).
‫[C-1-4] חובה להצהיר על השימוש ב-feature flag‏ android.hardware.wifi.passpoint.
‫[C-1-5] חייב לפעול בהתאם להטמעה של AOSP כדי לגלות רשתות Passpoint, להתאים אותן ולשייך אותן.
‫[C-1-6] חובה לתמוך לפחות בקבוצת המשנה הבאה של פרוטוקולים להקצאת הרשאות למכשירים, כפי שמוגדר ב-Wi-Fi Alliance Passpoint R2: אימות EAP-TTLS ו-SOAP-XML.
‫[C-1-7] חובה לעבד את אישור שרת ה-AAA כפי שמתואר במפרט Hotspot 2.0 R3.
‫[C-1-8] חובה לתמוך בשליטה של המשתמש בהקצאת הרשאות דרך כלי בחירת ה-Wi-Fi.
‫[C-1-9] חובה לשמור את הגדרות Passpoint גם אחרי הפעלה מחדש.
‫[C-SR-1] מומלץ מאוד לתמוך בתכונה של אישור התנאים וההגבלות.
‫[C-SR-2] מומלץ מאוד לתמוך בתכונה 'מידע על המקום'.

אם מסופק מתג גלובלי להשבתת Passpoint בשליטת המשתמש, ההטמעות:

‫[C-3-1] חובה להפעיל את Passpoint כברירת מחדל.

‫7.4.2.5. מיקום Wi-Fi (זמן הלוך ושוב ב-Wi-Fi‏ – RTT)

הטמעות במכשיר:

מומלץ לכלול תמיכה במיקום Wi-Fi.

אם הטמעות של מכשירים כוללות תמיכה במיקום Wi-Fi וחושפות את הפונקציונליות לאפליקציות של צד שלישי, הן:

‫[C-1-1] חובה להטמיע את ממשקי ה-API של WifiRttManager כפי שמתואר בתיעוד ה-SDK.
‫[C-1-2] חובה להצהיר על השימוש ב-feature flag‏ android.hardware.wifi.rtt.
‫[C-1-3] חובה לבצע רנדומיזציה של כתובת ה-MAC של המקור עבור כל פרץ RTT שמופעל בזמן שממשק ה-Wi-Fi שבו מופעל ה-RTT לא משויך לנקודת גישה.
‫[C-1-4] הדיוק צריך להיות בטווח של 2 מטרים ברוחב פס של 80 MHz באחוזון ה-68 (כפי שמחושב באמצעות פונקציית ההתפלגות המצטברת).
‫[C-SR-1] מומלץ מאוד לדווח על המיקום בצורה מדויקת, בטווח של 1.5 מטרים ברוחב פס של 80 MHz באחוזון ה-68 (כפי שמחושב באמצעות פונקציית ההתפלגות המצטברת).

‫7.4.2.6. העברה של שמירת חיבור Wi-Fi פעיל

הטמעות במכשיר:

צריך לכלול תמיכה בהעברת נתונים של שמירת חיבור Wi-Fi.

אם הטמעות של מכשירים כוללות תמיכה בהפחתת עומס של Wi-Fi keepalive ומציגות את הפונקציונליות לאפליקציות של צד שלישי, הן:

‫[C-1-1] חובה לתמוך ב-API‏ SocketKeepAlive.
‫[C-1-2] חובה לתמוך לפחות בשלושה משבצות זמן בו-זמניות של שמירת חיבור באמצעות Wi-Fi

אם הטמעות של מכשירים לא כוללות תמיכה בהעברת נתונים של שמירת חיבור ה-Wi-Fi במצב לא פעיל, הן:

‫[C-2-1] הפונקציה חייבת להחזיר את הערך ERROR_UNSUPPORTED.

‫7.4.2.7. חיבור קל ל-Wi-Fi (פרוטוקול הקצאת הרשאות למכשיר)

הטמעות במכשיר:

צריך לכלול תמיכה בחיבור קל ל-Wi-Fi‏ (DPP).

אם הטמעות המכשירים כוללות תמיכה ב-Wi-Fi Easy Connect וחושפות את הפונקציונליות לאפליקציות של צד שלישי, הן:

‫[C-1-1] חובה שהמתודה WifiManager#isEasyConnectSupported()‎ תחזיר את הערך true.

‫7.4.2.8. אימות אישור שרת Wi-Fi בארגון

אם אישור השרת של ה-Wi-Fi לא מאומת או ששם הדומיין של שרת ה-Wi-Fi לא מוגדר, הטמעות המכשיר:

‫[C-SR-1] מומלץ מאוד לא לספק למשתמש אפשרות להוסיף באופן ידני רשת Wi-Fi ארגונית באפליקציית ההגדרות.

‫7.4.2.9. סימון כרשת מהימנה בשימוש הראשון (TOFU)

אם הטמעות המכשירים תומכות ב-Trust on first usage ‏ (TOFU) ומאפשרות למשתמש להגדיר תצורות של WPA/WPA2/WPA3-Enterprise, הן:

‫[C-4-1] חובה לספק למשתמש אפשרות לבחור להשתמש ב-TOFU.

‫7.4.2.10. זיהוי קירבה באמצעות Wi-Fi (טווח קירבה ישיר)

אם הטמעות המכשירים כוללות תמיכה בזיהוי קירבה באמצעות Wi-Fi, אז הן:

‫[C-1-1] חובה לכלול תמיכה בזיהוי קירבה.
‫[C-1-2] חובה להצהיר על השימוש ב-feature flag‏ android.hardware.wifi.rtt.
‫[C-1-3] השיטה WifiRttManager#getProximityDetectionCharacteristics() חייבת להחזיר ערך שאינו null.
‫[C-1-4] חובה להטמיע את ממשקי ה-API של WifiRttManager למדידת מרחק רציפה.
‫[C-1-5] המכשיר חייב לתמוך בפעולות של Wi-Fi וזיהוי קירבה באמצעות Wi-Fi בו-זמנית.
[C-1-6] חייב להיות מדויק בטווח של 2 מטרים ברוחב פס של 80 MHz באחוזון ה-68 (כפי שמחושב באמצעות פונקציית ההתפלגות המצטברת).
‫[C-1-7] חובה לבצע מדידת טווח של זיהוי קרבה (PD) בפס התדרים הגבוה ביותר שזמין (‎6 GHz,‏ ‎5 GHz או ‎2.4 GHz) באמצעות רוחב הפס המקסימלי הנתמך בסדר העדיפות הבא: ‎160 MHz,‏ ‎80 MHz,‏ ‎40 MHz ו-‎20 MHz.
‫[C-SR-1] מומלץ מאוד לדווח על המיקום בצורה מדויקת, בטווח של 1.5 מטרים ברוחב פס של 80 MHz באחוזון ה-68 (כפי שמחושב באמצעות פונקציית ההתפלגות המצטברת).
‫[C-SR-2] מומלץ מאוד לתמוך בטווח של 802.11az NTB.

‫7.4.3. Bluetooth

אם הטמעות המכשירים תומכות בפרופיל Bluetooth Audio, הן:

צריכה להיות תמיכה בקודקים מתקדמים של אודיו ובקודקים של אודיו ל-Bluetooth (לדוגמה, LDAC).

אם הטמעות המכשיר תומכות ב-HFP, ב-A2DP וב-AVRCP, הן:

צריך לתמוך בחיבור של 5 מכשירים לפחות.

אם הטמעות של מכשירים מצהירות על התכונה android.hardware.vr.high_performance:

‫[C-1-1] חובה לתמוך ב-Bluetooth 4.2 וב-Bluetooth LE Data Length Extension.

‫Android כולל תמיכה ב-Bluetooth וב-Bluetooth עם צריכת אנרגיה נמוכה.

אם הטמעות המכשירים כוללות תמיכה ב-Bluetooth וב-Bluetooth Low Energy, הן:

‫[C-2-1] חובה להצהיר על התכונות הרלוונטיות של הפלטפורמה (android.hardware.bluetooth ו-android.hardware.bluetooth_le בהתאמה) ולהטמיע את ממשקי ה-API של הפלטפורמה.
מומלץ להטמיע פרופילים רלוונטיים של Bluetooth כמו A2DP,‏ AVRCP,‏ OBEX,‏ HFP וכו' בהתאם למכשיר.

אם הטמעות של מכשירים כוללות תמיכה ב-Bluetooth עם צריכת אנרגיה נמוכה (BLE), הן:

‫[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() כדי לציין אם יש תמיכה בפרסום בטכנולוגיית Low Energy.
‫[C-3-5] חובה להטמיע זמן קצוב לתפוגה של כתובת פרטית שניתנת לפתרון (RPA) שלא עולה על 15 דקות, ולשנות את הכתובת כשהזמן הקצוב לתפוגה מסתיים, כדי להגן על פרטיות המשתמשים כשהמכשיר משתמש באופן פעיל ב-BLE לסריקה או לפרסום. כדי למנוע התקפות תזמון, גם מרווחי הזמן הקצובים צריכים להיות אקראיים, בין 5 ל-15 דקות.
מומלץ לתמוך בהעברת העומס של לוגיקת הסינון לערכת השבבים של Bluetooth בזמן הטמעה של ScanFilter API.
צריכה להיות תמיכה בהעברת הסריקה באצווה לערכת השבבים של Bluetooth.
צריך לתמוך בהצגת כמה מודעות עם לפחות 4 מיקומי מודעות.

אם הטמעות המכשירים תומכות ב-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).

אם הטמעות המכשירים כוללות תמיכה ב-Bluetooth או ב-Bluetooth עם צריכת אנרגיה נמוכה (BLE), הן:

‫[C-6-1] חובה להגביל את הגישה למטא-נתונים של Bluetooth (כמו תוצאות סריקה) שאפשר להשתמש בהם כדי לגזור את מיקום המכשיר, אלא אם האפליקציה השולחת את הבקשה עוברת בהצלחה בדיקת הרשאות android.permission.ACCESS_FINE_LOCATION על סמך המצב הנוכחי שלה (פעילה או פועלת ברקע).

אם הטמעות המכשירים כוללות תמיכה ב-Bluetooth או ב-Bluetooth עם צריכת אנרגיה נמוכה (BLE), ובקובץ מניפסט של אפליקציה לא מופיעה הצהרה מהמפתח שלפיה הוא לא מקבל מיקום מ-Bluetooth, המכשירים:

‫[C-6-2] הגישה ל-Bluetooth חייבת להיות מוגבלת באמצעות התג android.permission.ACCESS_FINE_LOCATION.

אם הטמעות של מכשירים מחזירות true עבור ה-API‏ BluetoothAdapter.isLeAudioSupported(), הן:

‫[C-7-1] חובה לתמוך בלקוח unicast.
‫[C-7-2] חובה לתמוך ב-2M PHY.
‫[C-7-3] חובה לתמוך בפרסום מורחב של LE.
‫[C-7-4] חובה לתמוך ב-2 חיבורי CIS לפחות ב-CIG.
‫[C-7-5] חובה להפעיל בו-זמנית את לקוח ה-BAP בשידור יחיד, את רכיב ה-CSIP set coordinator, את שרת ה-MCP, את בקר ה-VCP ואת שרת ה-CCP.
‫[C-SR-1] מומלץ מאוד להפעיל את לקוח ה-unicast של HAP.

אם הטמעות של מכשירים מחזירות true עבור ה-API‏ BluetoothAdapter.isLeAudioBroadcastSourceSupported(), הן:

‫[C-8-1] חובה לתמוך בלפחות 2 קישורי BIS ב-BIG.
‫[C-8-2] חובה להפעיל בו-זמנית את מקור השידור של BAP ואת העוזר לשידור של BAP.
‫[C-8-3] חובה לתמוך בפרסום תקופתי של LE.

אם הטמעות של מכשירים מחזירות true עבור ה-API‏ BluetoothAdapter.isLeAudioBroadcastAssistantSupported(), הן:

‫[C-9-1] חובה לתמוך ב-PAST (העברה תקופתית של סנכרון פרסום).
‫[C-9-2] חובה לתמוך בפרסום תקופתי של LE.

אם הטמעות של מכשירים מצהירות על FEATURE_BLUETOOTH_LE, הן:

‫[C-10-1] חובה שהמדידות של RSSI יהיו בטווח של ‎+/-9 dB ב-95% מהמדידות במרחק של מטר אחד ממכשיר ייחוס שמשדר ב-ADVERTISE_TX_POWER_HIGH בסביבה עם קו ראייה.
‫[C-10-2] חובה לכלול תיקונים של Rx/Tx כדי לצמצם את הסטיות בכל ערוץ, כך שהמדידות בכל אחד מ-3 הערוצים, בכל אחת מהאנטנות (אם נעשה שימוש בכמה אנטנות), יהיו בטווח של ‎+/-3 dB אחת מהשנייה ב-95% מהמדידות.

אם הטמעות של מכשירים מצהירות על FEATURE_BLUETOOTH_LE_CHANNEL_SOUNDING, הן:

[C-11-1] חובה לדווח על feature flag של החומרה android.hardware.bluetooth_le.channel_sounding.
‫[C-11-2] חובה לדווח על הטווח בצורה מדויקת בטווח של ‎+/- 0.5 m באחוזון ה-90, כפי שמחושב באמצעות פונקציית ההתפלגות המצטברת, במרחק של מטר אחד.

אם הטמעות של מכשירים מצהירות על FEATURE_BLUETOOTH_LE, הן:

‫[C-SR-2] מומלץ מאוד למדוד את ההיסט של קליטת האות (Rx) ולפצות עליו כדי לוודא שערך ה-RSSI הממוצע של BLE הוא ‎-60 dBm +/-10 dB במרחק של מטר אחד ממכשיר ייחוס שמשדר ב-ADVERTISE_TX_POWER_HIGH, כאשר המכשירים מוצבים כך שהם נמצאים ב 'מישורים מקבילים' והמסכים פונים לאותו כיוון.
‫[C-SR-3] מומלץ מאוד למדוד את היסט השידור ולפצות עליו כדי לוודא שערך ה-RSSI הממוצע של BLE הוא ‎-60 dBm +/-10 dB‎ כשסורקים ממכשיר ייחוס שממוקם במרחק של מטר אחד ומשדר ב-ADVERTISE_TX_POWER_HIGH, כאשר המכשירים מוצבים כך שהם נמצאים ב'מישורים מקבילים' והמסכים פונים לאותו כיוון.

מומלץ מאוד לפעול לפי השלבים להגדרת המדידה שמפורטים במאמר דרישות לכיול של נוכחות.

7.4.4. תקשורת מטווח קצר (NFC)

הטמעות במכשיר:

צריך לכלול משדר-מקלט וחומרה קשורה לתקשורת מטווח קצר (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 Forum (כפי שמוגדר במפרט הטכני של NFC Forum‏ NFCForum-TS-DigitalProtocol-1.0) באמצעות תקני ה-NFC הבאים:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- סוגי תגים 2, 3, 4, 5 של NFC Forum (מוגדרים על ידי NFC Forum)
‫[C-SR-1] מומלץ מאוד שתהיה אפשרות לקרוא ולכתוב הודעות NDEF וגם נתונים גולמיים באמצעות תקני ה-NFC הבאים. שימו לב: תקני ה-NFC מוגדרים כהמלצה חזקה, אבל מתוכנן שינוי בהגדרת התאימות בגרסה עתידית, כך שהם יהפכו לחובה. התקנים האלה הם אופציונליים בגרסה הזו, אבל יהיו חובה בגרסאות עתידיות. מומלץ מאוד שמכשירים קיימים וחדשים שמריצים את הגרסה הזו של Android יעמדו בדרישות האלה כבר עכשיו, כדי שיהיה אפשר לשדרג אותם לגרסאות פלטפורמה עתידיות.
‫[C-1-13] חובה לבצע סקר לכל הטכנולוגיות הנתמכות במצב גילוי NFC.
צריך להיות במצב גילוי NFC בזמן שהמכשיר פעיל, המסך פעיל ומסך הנעילה לא נעול.
צריכה להיות אפשרות לקרוא את הברקוד וכתובת ה-URL (אם הם מקודדים) של מוצרי Thinfilm NFC Barcode.

שימו לב שהקישורים שזמינים לציבור לא זמינים למפרטים של JIS,‏ ISO ו-NFC Forum שצוינו למעלה.

‫Android כולל תמיכה במצב Host Card Emulation ‏ (HCE) של NFC.

אם הטמעות במכשירים כוללות ערכת שבבים של בקר NFC עם יכולת HCE (עבור NfcA ו/או NfcB) ותמיכה בניתוב של מזהה אפליקציה (AID), הן:

‫[C-2-1] חובה לדווח על קבוע התכונה android.hardware.nfc.hce.
‫[C-2-2] חובה לתמוך ב-NFC HCE APIs כפי שמוגדר ב-Android SDK.

אם הטמעות המכשירים כוללות ערכת שבבים של בקר NFC עם יכולת HCE עבור NfcF, ומטמיעות את התכונה עבור אפליקציות צד שלישי, הן:

‫[C-3-1] חובה לדווח על קבוע התכונה android.hardware.nfc.hcef.
‫[C-3-2] חובה להטמיע את ממשקי ה-API של NFC-F Card Emulation כפי שמוגדרים ב-Android SDK.

אם הטמעות המכשירים כוללות תמיכה כללית ב-NFC כפי שמתואר בקטע הזה, ותמיכה בטכנולוגיות MIFARE (‏MIFARE Classic,‏ MIFARE Ultralight,‏ NDEF ב-MIFARE Classic) בתפקיד הקורא/כותב, הן:

‫[C-4-1] חובה להטמיע את ממשקי ה-API התואמים ל-Android כפי שמתואר בתיעוד של Android SDK.
‫[C-4-2] חובה לדווח על התכונה com.nxp.mifare מהשיטה android.content.pm.PackageManager.hasSystemFeature(). הערה: זו לא תכונה רגילה של Android, ולכן היא לא מופיעה כקבוע במחלקה android.content.pm.PackageManager.

‫7.4.5. פרוטוקולי רישות וממשקי API

‫7.4.5.1. יכולת רשת מינימלית

הטמעות במכשיר:

‫[C-0-1] חובה לכלול תמיכה בצורה אחת או יותר של רשת נתונים. באופן ספציפי, הטמעות של מכשירים חייבות לכלול תמיכה לפחות בתקן נתונים אחד עם יכולת של 200 Kbit/sec או יותר. דוגמאות לטכנולוגיות שעומדות בדרישה הזו כוללות EDGE, ‏ HSPA, ‏ EV-DO,‏ 802.11g, ‏ Ethernet ו-Bluetooth PAN.
בנוסף, המכשיר צריך לתמוך לפחות בתקן נפוץ אחד של נתונים אלחוטיים, כמו 802.11 (Wi-Fi), אם תקן פיזי של רשת (כמו אתרנט) הוא חיבור הנתונים העיקרי.
יכול להיות שיהיו כמה דרכים לחיבור נתונים.

‫7.4.5.2. IPv6

הטמעות במכשיר:

‫[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 API כמו getsockname() או IPV6_PKTINFO חייבים להחזיר את כתובת ה-IP והיציאה שמשמשים בפועל לשליחה ולקבלה של מנות ברשת, וגלויים ככתובת ה-IP והיציאה של המקור לשרתי אינטרנט (ווב).

רמת התמיכה הנדרשת ב-IPv6 תלויה בסוג הרשת, כפי שמוצג בדרישות הבאות.

אם ההטמעות של המכשירים תומכות ב-Wi-Fi, הן:

‫[C-1-1] חובה לתמוך בפעולה של dual-stack ו-IPv6 בלבד ב-Wi-Fi.

אם הטמעות המכשירים תומכות באתרנט, הן:

‫[C-2-1] חובה לתמוך בפעולה של dual-stack ו-IPv6 בלבד ב-Ethernet.

אם הטמעות המכשירים תומכות בנתונים סלולריים, הן:

‫[C-3-1] חובה לתמוך בפעולת IPv6 (IPv6 בלבד ואולי גם dual-stack) בחיבור סלולרי.

אם ההטמעות של המכשירים תומכות ביותר מסוג רשת אחד (למשל, Wi-Fi וחבילת גלישה), הן:

‫[C-4-1] המכשיר חייב לעמוד בו-זמנית בדרישות שלמעלה בכל רשת כשהוא מחובר בו-זמנית ליותר מסוג רשת אחד.

‫7.4.5.3. פורטלים שבויים

פורטל שבוי הוא רשת שנדרשת בה כניסה לחשבון כדי לקבל גישה לאינטרנט.

אם הטמעות של מכשירים מספקות הטמעה מלאה של android.webkit.Webview API: הן:

‫[C-1-1] חובה לספק אפליקציית פורטל חובה לטיפול ב-Intent ACTION_CAPTIVE_PORTAL_SIGN_IN ולהצגת דף ההתחברות לפורטל החובה, על ידי שליחת ה-Intent הזה, בקריאה ל-System API ConnectivityManager#startCaptivePortalApp(Network, Bundle).
‫[C-1-2] המכשיר חייב לזהות פורטלים שבויים ולתמוך בכניסה דרך אפליקציית הפורטל השבוי כשהמכשיר מחובר לכל סוג רשת, כולל רשת סלולרית, Wi-Fi, אתרנט או Bluetooth.
‫[C-1-3] חובה לתמוך בכניסה לפורטלים שבויים באמצעות DNS בטקסט גלוי כשהמכשיר מוגדר לשימוש במצב קפדני של DNS פרטי.
‫[C-1-4] חובה להשתמש ב-DNS מוצפן בהתאם לתיעוד של ערכת ה-SDK‏ android.net.LinkProperties.getPrivateDnsServerName ושל android.net.LinkProperties.isPrivateDnsActive לכל התנועה ברשת שלא מתקשרת באופן מפורש עם הפורטל לשליטה בגישה.
‫[C-1-5] חובה לוודא שכשמשתמש מתחבר לפורטל שבוי, הרשת שמוגדרת כברירת מחדל לשימוש באפליקציות (כפי שמוחזרת על ידי ConnectivityManager.getActiveNetwork,‏ ConnectivityManager.registerDefaultNetworkCallback, ומשמשת כברירת מחדל על ידי ממשקי API של Java לרשת, כמו java.net.Socket, וממשקי API מקוריים, כמו connect()) היא כל רשת זמינה אחרת שמספקת גישה לאינטרנט, אם יש כזו.

‫7.4.6. הגדרות הסנכרון

הטמעות במכשיר:

‫[C-0-1] חובה להגדיר את הגדרת הסנכרון האוטומטי הראשית כהגדרה שמופעלת כברירת מחדל, כדי שהשיטה getMasterSyncAutomatically() תחזיר את הערך true.

‫7.4.7. חוסך הנתונים (Data Saver)

אם ההטמעות במכשיר כוללות חיבור בתשלום לפי נפח השימוש, הן:

‫[C-SR-1] מומלץ מאוד לספק את מצב חוסך הנתונים.

אם הטמעות המכשיר מספקות את מצב חיסכון הנתונים, הן:

‫[C-1-1] חובה לתמוך בכל ממשקי ה-API בכיתה ConnectivityManager, כפי שמתואר במסמכי ה-SDK

אם הטמעות המכשירים לא מספקות את מצב חיסכון הנתונים, הן:

‫[C-2-1] חייב להחזיר את הערך RESTRICT_BACKGROUND_STATUS_DISABLED עבור ConnectivityManager.getRestrictBackgroundStatus()
‫[C-2-2] אסור לשדר ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

‫7.4.8. רכיבים מאובטחים

אם הטמעות המכשירים תומכות ברכיבי אבטחה עם יכולת Open Mobile API ומאפשרות לאפליקציות של צד שלישי לגשת אליהם, הן:

‫[C-1-1] חובה למנות את קוראי האלמנטים המאובטחים הזמינים באמצעות android.se.omapi.SEService.getReaders() API.
‫[C-1-2] חובה להצהיר על דגלי התכונות הנכונים באמצעות android.hardware.se.omapi.uicc למכשיר עם רכיבים מאובטחים מבוססי UICC, android.hardware.se.omapi.ese למכשיר עם רכיבים מאובטחים מבוססי eSE ו- android.hardware.se.omapi.sd למכשיר עם רכיבים מאובטחים מבוססי SD.

‫7.4.9. UWB

אם ההטמעות של המכשירים כוללות תמיכה בתקן 802.1.15.4 וחושפות את הפונקציונליות לאפליקציה של צד שלישי, הן:

‫[C-1-1] חובה להטמיע את Android API המתאים ב-android.uwb.
‫[C-1-2] חובה לדווח על דגל התכונה של החומרה android.hardware.uwb.
‫[C-1-3] המכשיר חייב לתמוך בכל פרופילי ה-UWB הרלוונטיים שמוגדרים בהטמעה של Android.
‫[C-1-4] חובה לספק למשתמש אפשרות להפעיל או להשבית את מצב הרדיו של UWB.
‫[C-1-5] חובה לוודא שאפליקציות שמשתמשות ברדיו UWB מחזיקות בהרשאה UWB_RANGING (בקבוצת ההרשאות NEARBY_DEVICES).
‫[C-SR-1] מומלץ מאוד לעבור את בדיקות התאימות וההסמכה הרלוונטיות שמוגדרות על ידי ארגוני תקנים, כולל FIRA, ‏ CCC ו-CSA.
‫[C-1-6] חובה לוודא שמדידות המרחק הן בטווח של ‎+/-15 cm עבור 95% מהמדידות בסביבת קו הראייה במרחק של מטר אחד בחדר לא מחזיר אור.
‫[C-1-7] חובה לוודא שהחציון של מדידות המרחק במרחק של מטר אחד ממכשיר הייחוס הוא בטווח [0.75 מ', 1.25 מ'], כאשר מרחק האמת נמדד מהקצה העליון של המכשיר הנבדק.
‫[C-SR-2] מומלץ מאוד לפעול לפי השלבים להגדרת המדידה שמפורטים בדרישות הכיול של נוכחות.

‫7.5. מצלמות

אם הטמעות המכשירים כוללות לפחות מצלמה אחת, הן:

‫[C-1-1] חובה להצהיר על ה-feature flag‏ android.hardware.camera.any.
‫[C-1-2] אפליקציה חייבת להיות מסוגלת להקצות בו-זמנית 3 מפות סיביות בגודל התמונות שנוצרות על ידי חיישן המצלמה ברזולוציה הגדולה ביותר במכשיר, בזמן שהמצלמה פתוחה לצורך תצוגה מקדימה בסיסית וצילום תמונות סטילס.RGBA_8888
‫[C-1-3] חובה לוודא שאפליקציית המצלמה שמותקנת מראש כברירת מחדל, שמטפלת ב-intent‏ MediaStore.ACTION_IMAGE_CAPTURE,‏ MediaStore.ACTION_IMAGE_CAPTURE_SECURE או MediaStore.ACTION_VIDEO_CAPTURE, אחראית להסרת המיקום של המשתמש במטא-נתונים של התמונה לפני שליחתה לאפליקציה המקבלת, אם לאפליקציה המקבלת אין ACCESS_FINE_LOCATION.

‫[C-1-6] חובה להוסיף תווית לכל סוג של מכשיר מצלמה באמצעות השדה CameraCharacteristics.INFO_DEVICE_TYPE עם הערכים BUILT_IN,‏ EXTERNAL או VIRTUAL. חובה גם להוסיף תוויות לכל פריים של פלט המצלמה באמצעות השדה CaptureResult.INFO_DEVICE_TYPE.
חשוב במיוחד לוודא ש-CaptureResult.INFO_DEVICE_TYPE מסומן בצורה נכונה במצבים שבהם מזהה מצלמה ממופה מחדש באופן דינמי למקור מצלמה אחר.

אם הטמעות המכשירים כוללות מצלמה אחת לפחות, ואפליקציית המצלמה המובנית מטפלת ב-Intents‏ MediaStore.ACTION_MOTION_PHOTO_CAPTURE או MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE, הן:

‫[C-1-4] חובה לוודא שכשמטפלים ב-Intents האלה, אפליקציית המצלמה שהותקנה מראש מסירה את מיקום המשתמש במטא-נתונים של התמונה לפני שהיא נשלחת לאפליקציות מקבלות שאין להן ACCESS_FINE_LOCATION.
‫[C-1-5] חובה לוודא שהתמונה עם התנועה שמוחזרת משתמשת במפרט של פורמט תמונה עם תנועה 1.0.

אם הטמעות המכשירים תומכות ביכולת פלט של HDR 10-bit, הן:

‫[C-2-1] כל מכשיר מצלמה שתומך בפלט של 10 ביט חייב לתמוך לפחות בפרופיל HLG HDR.
‫[C-2-2] חובה לתמוך בפלט של 10 ביט במצלמה הראשית האחורית או במצלמה הראשית הקדמית.
‫[C-SR-1] מומלץ מאוד לתמוך בפלט של 10 ביט בשתי המצלמות הראשיות.
‫[C-2-3] חובה לתמוך באותם פרופילי HDR בכל המצלמות המשנה הפיזיות עם יכולת BACKWARD_COMPATIBLE של מצלמה לוגית, ובמצלמה הלוגית עצמה.

במכשירי מצלמה לוגית שתומכים ב-HDR באיכות 10 ביט ומטמיעים את android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API, מתבצעות הפעולות הבאות:

‫[C-3-1] חובה לתמוך במעבר בין כל המצלמות הפיזיות שתואמות לאחור באמצעות הפקד CONTROL_ZOOM_RATIO במצלמה הלוגית.

‫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] אסור לשקף את תמונת הסטילס הסופית שצולמה או את זרמי הווידאו שמוחזרים לקריאות חוזרות (callback) של האפליקציה או שנשמרים באחסון המדיה.
‫[C-1-6] חובה לשקף את התמונה שמוצגת בתצוגה המקדימה אחרי הצילום באותו אופן כמו זרם התמונות בתצוגה המקדימה של המצלמה.
עשוי לכלול תכונות (כמו פוקוס אוטומטי, פלאש וכו') שזמינות למצלמות שפונות לאחור, כפי שמתואר בסעיף 7.5.1.

אם הטמעות מכשירים מסוגלות להסתובב על ידי המשתמש (כגון באופן אוטומטי באמצעות מד תאוצה או באופן ידני באמצעות קלט של משתמשים):

‫[C-2-1] התצוגה המקדימה של המצלמה חייבת להיות הפוכה אופקית ביחס לאוריינטציה הנוכחית של המכשיר.

‫7.5.3. מצלמה חיצונית

מצלמה חיצונית היא מצלמה שאפשר לחבר או לנתק פיזית מהמכשיר בכל שלב, והיא יכולה להיות מכוונת לכל כיוון. דוגמאות למצלמות חיצוניות הן מצלמות USB.

הטמעות במכשיר:

יכול להיות שתהיה תמיכה במצלמה חיצונית שלא תמיד מחוברת.

אם ההטמעות של המכשירים כוללות תמיכה במצלמה חיצונית, הן:

‫[C-1-1] חובה להצהיר על דגל התכונה של הפלטפורמה android.hardware.camera.external ו-android.hardware camera.any.
‫[C-1-2] אם המצלמה החיצונית מתחברת דרך יציאת המארח של ה-USB, המכשיר חייב לתמוך ב-USB Video Class (UVC 1.0 ומעלה).
‫[C-1-3] חובה לעבור את בדיקות ה-CTS של המצלמה עם מכשיר מצלמה חיצוני פיזי מחובר. פרטים על בדיקות CTS של מצלמות זמינים בכתובת source.android.com.
צריך לתמוך בדחיסת וידאו כמו MJPEG כדי לאפשר העברה של זרמי נתונים לא מקודדים באיכות גבוהה (כלומר, זרמי נתונים של תמונות גולמיות או של תמונות שנדחסו בנפרד).
יכול להיות שיש תמיכה בכמה מצלמות.
יכול להיות שהמכשיר תומך בקידוד וידאו שמבוסס על מצלמה.

אם יש תמיכה בקידוד וידאו שמבוסס על מצלמה:

‫[C-2-1] הטמעה של המכשיר חייבת לאפשר גישה לזרם MJPEG לא מקודד בו-זמנית (רזולוציית QVGA או רזולוציה גבוהה יותר).

‫7.5.4. התנהגות של Camera API

‫Android כוללת שני חבילות API לגישה למצלמה. חבילת ה-API החדשה יותר android.hardware.camera2 מאפשרת לאפליקציה שליטה במצלמה ברמה נמוכה יותר, כולל זרימות יעילות של צילום רצף או סטרימינג ללא העתקה, ובקרות לכל פריים של חשיפה, הגברה, איזון לבן, המרת צבעים, הפחתת רעשים, חידוד ועוד.

חבילת ה-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 לתצוגה מקדימה של נתונים שסופקו לקריאות חוזרות (callback) של אפליקציות, אם האפליקציה מעולם לא קראה ל-android.hardware.Camera.Parameters.setPreviewFormat(int).
‫[C-0-2] בנוסף, הנתונים חייבים להיות בפורמט הקידוד NV21 כשיישום רושם מופע android.hardware.Camera.PreviewCallback ומערכת ההפעלה קוראת לשיטה onPreviewFrame() ופורמט התצוגה המקדימה הוא YCbCr_420_SP, הנתונים במערך ה-byte[] מועברים אל onPreviewFrame(). כלומר, NV21 חייב להיות ברירת המחדל.
‫[C-0-3] מכשיר android.hardware.Camera חייב לתמוך בפורמט YV12 (כפי שמצוין בקבוע android.graphics.ImageFormat.YV12) לתצוגות מקדימות של המצלמה, גם במצלמה הקדמית וגם במצלמה האחורית. (מקודד הווידאו והמצלמה בחומרה יכולים להשתמש בכל פורמט פיקסלים מקורי, אבל ההטמעה במכשיר חייבת לתמוך בהמרה ל-YV12).
‫[C-0-4] חובה לתמוך בפורמטים android.hardware.ImageFormat.YUV_420_888 ו-android.hardware.ImageFormat.JPEG כפלט דרך android.media.ImageReader API עבור מכשירי android.hardware.camera2 שמפרסמים יכולת REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE ב-android.request.availableCapabilities.
‫[C-0-5] המכשיר חייב להטמיע את Camera API המלא שכלול בתיעוד של Android SDK, גם אם הוא כולל פוקוס אוטומטי בחומרה או יכולות אחרות. לדוגמה, מצלמות שאין להן פוקוס אוטומטי עדיין צריכות להפעיל מופעים רשומים של android.hardware.Camera.AutoFocusCallback (גם אם זה לא רלוונטי למצלמה ללא פוקוס אוטומטי). שימו לב שהדבר חל על מצלמות קדמיות. לדוגמה, למרות שרוב המצלמות הקדמיות לא תומכות בפוקוס אוטומטי, עדיין צריך "לזייף" את הקריאות החוזרות (callbacks) של ה-API כמו שמתואר.
‫[C-0-6] חובה לזהות ולכבד כל שם פרמטר שמוגדר כקבוע במחלקה android.hardware.Camera.Parameters ובמחלקה android.hardware.camera2.CaptureRequest. לעומת זאת, בהטמעות של מכשירים אסור לכבד או לזהות קבועי מחרוזת שמועברים לשיטה android.hardware.Camera.setParameters(), מלבד אלה שמתועדים כקבועים ב-android.hardware.Camera.Parameters. כלומר, הטמעות במכשירים חייבות לתמוך בכל הפרמטרים הסטנדרטיים של המצלמה אם החומרה מאפשרת זאת, ואסור להן לתמוך בסוגים של פרמטרים מותאמים אישית של המצלמה. לדוגמה, הטמעות של מכשירים שתומכים בצילום תמונות באמצעות טכניקות צילום עם טווח דינמי גבוה (HDR) חייבות לתמוך בפרמטר המצלמה Camera.SCENE_MODE_HDR.
‫[C-0-7] חובה לדווח על רמת התמיכה המתאימה באמצעות המאפיין android.info.supportedHardwareLevel, כפי שמתואר ב-Android SDK, ולדווח על דגלי התכונות המתאימים של המסגרת.
‫[C-0-8] בנוסף, המכשיר חייב להצהיר על יכולות המצלמה האישיות שלו android.hardware.camera2 באמצעות המאפיין android.request.availableCapabilities, ולהצהיר על דגלי התכונות המתאימים. המכשיר חייב להגדיר את דגל התכונה אם אחד ממכשירי המצלמה המחוברים תומך בתכונה.
‫[C-0-9] חייב לשדר את Camera.ACTION_NEW_PICTURE הכוונה בכל פעם שמצולמת תמונה חדשה על ידי המצלמה והערך של התמונה נוסף למאגר המדיה.
‫[C-0-10] חובה לשדר את Camera.ACTION_NEW_VIDEO ה-intent בכל פעם שמצלמים סרטון חדש באמצעות המצלמה, והערך של התמונה נוסף למאגר המדיה.
‫[C-0-11] חובה שכל המצלמות שנגישות דרך ממשק ה-API android.hardware.Camera שהוצא משימוש יהיו נגישות גם דרך ממשק ה-API android.hardware.camera2.
‫[C-0-12] חובה לוודא שהמראה של הפנים לא משתנה, כולל, בין היתר, שינוי של גיאומטריית הפנים, גוון העור של הפנים או החלקת העור של הפנים בכל API של android.hardware.camera2 או של android.hardware.Camera.
‫[C-SR-1] במכשירים עם כמה מצלמות RGB שמוצבות קרוב זו לזו ומכוונות לאותו כיוון, מומלץ מאוד לתמוך במכשיר מצלמה לוגי שמציג את היכולת CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, שכוללת את כל מצלמות ה-RGB שמכוונות לאותו כיוון כמכשירי משנה פיזיים.

אם הטמעות של מכשירים מספקות API קנייני של מצלמה לאפליקציות של צד שלישי, הן:

‫[C-1-1] חובה להטמיע ממשק API כזה למצלמה באמצעות android.hardware.camera2 API.
יכול להיות שספקים יספקו תגים או תוספים ל-API של android.hardware.camera2.

אם הטמעות של מכשירים מכוונות את צינור המצלמה של צד שלישי כך שיהיה שווה לצינור המצלמה המובנית עבור המצלמה הקדמית הראשית והמצלמה האחורית הראשית, הן:

‫[C-2-1] חובה להצהיר על מאפיין המערכת ro.camera.default_app_social_media_parity_enabled.

‫7.5.5. כיוון המצלמה

אם במכשירים יש מצלמה קדמית או מצלמה אחורית, המצלמות האלה:

‫[C-1-1] חובה לכוון את המצלמה כך שהמימד הארוך שלה יהיה מקביל למימד הארוך של המסך. כלומר, כשמחזיקים את המכשיר לרוחב, המצלמות חייבות לצלם תמונות לרוחב. ההגדרה הזו חלה ללא קשר לכיוון הטבעי של המכשיר, כלומר היא חלה גם על מכשירים שהכיוון הראשי שלהם הוא לרוחב וגם על מכשירים שהכיוון הראשי שלהם הוא לאורך.

מכשירים שעומדים באחד מהקריטריונים הבאים פטורים מהדרישה הזו:
- המכשיר כולל מסכים עם גיאומטריה משתנה, כמו מסכים מתקפלים או מסכים עם ציר, וכשהמצב של הקיפול או הציר במכשיר משתנה, המכשיר עובר בין מצב לאורך (primary) לרוחב (primary) (או להיפך).
- הטמעות של מכשירים שהמשתמש לא יכול לסובב, כמו מכשירים לרכב.

‫7.6. זיכרון ואחסון

‫7.6.1. זיכרון ואחסון מינימליים

הטמעות במכשיר:

‫[C-0-1] חובה לכלול מנהל הורדות שאפליקציות יכולות להשתמש בו כדי להוריד קבצים של נתונים, והן צריכות להיות מסוגלות להוריד קבצים בודדים בגודל של לפחות 100MB למיקום ברירת המחדל של ה'מטמון'.

‫7.6.2. נפח אחסון משותף של אפליקציות

הטמעות במכשיר:

‫[C-0-1] המכשיר חייב להציע אחסון שמשותף בין האפליקציות, שנקרא גם 'אחסון חיצוני משותף', 'אחסון משותף לאפליקציות' או נתיב Linux ‏'/sdcard' שבו הוא מותקן.
‫[C-0-2] חובה להגדיר אחסון משותף שמוטמע כברירת מחדל, כלומר 'מוכן לשימוש', בלי קשר לשאלה אם האחסון מיושם ברכיב אחסון פנימי או במדיה לאחסון נתונים שאפשר להסיר (למשל, חריץ לכרטיס Secure Digital).
‫[C-0-3] חובה לטעון את האחסון השיתופי של האפליקציה ישירות בנתיב Linux‏ sdcard או לכלול קישור סמלי של Linux מ-sdcard לנקודת הטעינה בפועל.
[C-0-4] חובה להפעיל נפח אחסון ייעודי לאפליקציות כברירת מחדל לכל האפליקציות שמטרגטות רמת API‏ 29 ומעלה, למעט במצב הבא:
- כשהאפליקציה מבקשת android:requestLegacyExternalStorage="true" במניפסט שלה.
‫[C-0-5] חובה לצנזר מטא-נתונים של מיקום, כמו תגי GPS Exif, שמאוחסנים בקובצי מדיה כשניגשים לקבצים האלה דרך MediaStore, אלא אם לאפליקציה שקוראת לפונקציה יש הרשאה מסוג ACCESS_MEDIA_LOCATION.

יכול להיות שהטמעות של מכשירים יעמדו בדרישות שלמעלה באמצעות אחת מהאפשרויות הבאות:

אחסון נשלף שמשתמשים יכולים לגשת אליו, כמו חריץ לכרטיס Secure Digital ‏ (SD).
חלק מהאחסון הפנימי (שאי אפשר להסיר) כפי שהוא מיושם ב-פרויקט קוד פתוח של Android ‏ (AOSP).

אם הטמעות של מכשירים משתמשות באחסון נשלף כדי לעמוד בדרישות שלמעלה:

‫[C-1-1] חובה להטמיע אזהרה בממשק המשתמש בצורת הודעה קופצת או חלון קופץ, שמוצגת למשתמש כשלא מוכנס אמצעי אחסון לחריץ.
‫[C-1-2] חובה לכלול אמצעי אחסון בפורמט FAT (למשל כרטיס SD) או לציין על הקופסה ובחומרים אחרים שזמינים בזמן הרכישה שאמצעי האחסון נרכש בנפרד.

אם הטמעות במכשירים משתמשות בחלק מהאחסון שלא ניתן להסרה כדי לעמוד בדרישות שלמעלה, הן:

מומלץ להשתמש בהטמעה של AOSP של האחסון המשותף הפנימי של האפליקציה.
יכול להיות שנשתף את נפח האחסון עם הנתונים הפרטיים של האפליקציה.

אם הטמעות המכשירים כוללות יציאת USB עם תמיכה במצב ציוד היקפי של USB, הן:

‫[C-3-1] חובה לספק מנגנון לגישה לנתונים באחסון המשותף של האפליקציה ממחשב מארח.
צריך לחשוף תוכן משני נתיבי האחסון באופן שקוף דרך שירות סריקת המדיה של Android‏ android.provider.MediaStore.
יכול להיות שימוש באחסון USB בנפח גדול, אבל מומלץ להשתמש בפרוטוקול העברת מדיה כדי לעמוד בדרישה הזו.

אם הטמעות המכשירים כוללות יציאת USB עם מצב ציוד היקפי USB ותמיכה בפרוטוקול העברת מדיה (MTP), הן:

צריכה להיות תאימות למארח ההפניה של Android MTP,‏ העברת קבצים ב-Android.
צריך לדווח על מחלקה של מכשיר USB עם הערך 0x00.
צריך לדווח על שם ממשק USB ‏ 'MTP'.

‫7.6.3. אחסון שניתן להתאמה

אם המכשיר אמור להיות נייד, בניגוד לטלוויזיה, הטמעות המכשיר הן:

‫[C-SR-1] מומלץ מאוד להטמיע את האחסון הניתן להעברה במיקום יציב לטווח ארוך, כי ניתוק לא מכוון עלול לגרום לאובדן נתונים או להשחתת נתונים.

אם יציאת התקן האחסון הנייד נמצאת במיקום יציב לטווח ארוך, למשל בתוך תא הסוללה או כיסוי מגן אחר, ההטמעות של המכשיר הן:

‫[C-SR-2] מומלץ מאוד להטמיע אחסון שניתן להתאמה.

‫7.7. USB

הגדרות

מצב מארח USB הוא מצב שבו הטמעת המכשיר פועלת כמארח USB, מספקת חשמל באפיק ומתקשרת עם ציוד היקפי.
מצב התקן USB, שנקרא גם מצב ציוד היקפי, מתרחש כשיישום של מכשיר פועל כציוד היקפי של USB, מתחבר למארח דרך יציאה במעלה הזרם ומגיב לבקשות מהמארח.
יציאת USB היא מנגנון לחיבור USB, בין אם מדובר בשקע USB פיזי או בממשק לא סטנדרטי (לדוגמה, פיני פוגו).

אם יש יציאת USB בהטמעות של מכשירים, היא:

צריכה להיות תמיכה במצב התקן USB.
צריכה להיות תמיכה במצב מארח USB.
צריכה להיות תמיכה בהשבתת העברת נתונים באמצעות USB.

‫7.7.1. מצב התקן USB

אם ההטמעות של המכשירים כוללות יציאת USB שתומכת במצב ציוד היקפי של מכשיר:

‫[C-1-1] היציאה חייבת להיות ניתנת לחיבור למארח USB עם יציאת USB מסוג A או מסוג C.
‫[C-1-2] חובה לדווח על הערך הנכון של iSerialNumber בתיאור של מכשיר בתקן USB דרך android.os.Build.SERIAL.
‫[C-1-3] חובה לזהות מטענים של 1.5A ו-3.0A בהתאם לתקן הנגד Type-C, וחובה לזהות שינויים בפרסום אם הם תומכים ב-USB Type-C.

‫[C-SR-1] היציאה צריכה להיות מסוג USB micro-B, ‏ micro-AB או Type-C. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה, כדי שיהיה אפשר לשדרג אותם לגרסאות עתידיות של הפלטפורמה.

‫[C-SR-2] היציאה צריכה להיות ממוקמת בתחתית המכשיר (בהתאם לכיוון הטבעי) או שצריך להפעיל סיבוב מסך בתוכנה לכל האפליקציות (כולל מסך הבית), כדי שהתצוגה תופיע בצורה נכונה כשהיציאה ממוקמת בתחתית המכשיר. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה, כדי שיהיה אפשר לשדרג אותם לגרסאות פלטפורמה עתידיות.
‫[C-SR-3] צריך להטמיע תמיכה בשאיבת זרם של 1.5 אמפר במהלך ציוץ HS ותנועה, כפי שמפורט במפרט הטעינה של סוללות USB, גרסה 1.2. מומלץ מאוד שמכשירי Android קיימים וחדשים יעמדו בדרישות האלה, כדי שיהיה אפשר לשדרג אותם לגרסאות עתידיות של הפלטפורמה.
[C-SR-4] מומלץ מאוד לא לתמוך בשיטות טעינה קנייניות שמשנות את המתח של Vbus מעבר לרמות ברירת המחדל, או משנות את תפקידי המקור/הצרכן, כי שיטות כאלה עלולות לגרום לבעיות תאימות למטענים או למכשירים שתומכים בטעינה בתקן USB PD. ההמלצה הזו מוגדרת כ "מומלץ מאוד", אבל בגרסאות עתידיות של Android יכול להיות שנדרוש מכל מכשירי Type-C לתמוך בפעולה הדדית מלאה עם מטעני Type-C רגילים.
[C-SR-5] מומלץ מאוד לתמוך בטעינה בתקן USB PD להעברת נתונים ולהחלפת תפקידים של חשמל כאשר הם תומכים ב-USB Type-C ובמצב מארח USB.
צריכה להיות תמיכה בטעינה בתקן USB PD לטעינה במתח גבוה ותמיכה במצבים חלופיים כמו יציאת תצוגה.
מומלץ להטמיע את ממשק ה-API ואת המפרט של Android Open Accessory ‏ (AOA) כפי שמתואר בתיעוד של Android SDK.

אם הטמעות של מכשירים כוללות יציאת USB ומיישמות את מפרט AOA, הן:

‫[C-2-1] חובה להצהיר על תמיכה בתכונת החומרה android.hardware.usb.accessory.
‫[C-2-2] מחלקת האחסון ההמוני ב-USB חייבת לכלול את המחרוזת android בסוף המחרוזת iInterface של תיאור הממשק של האחסון ההמוני ב-USB

‫7.7.2. מצב מארח USB

אם הטמעות של מכשירים כוללות יציאת USB שתומכת במצב מארח, הן:

‫[C-1-1] חובה להטמיע את Android USB host API כפי שמתואר ב-Android SDK, וחובה להצהיר על תמיכה בתכונת החומרה android.hardware.usb.host.
‫[C-1-2] חובה להטמיע תמיכה בחיבור של ציוד היקפי רגיל ב-USB. הם חייבים לעמוד באחד מהתנאים הבאים:
- יציאת USB-C במכשיר או כבלים שמתאימים יציאה קניינית במכשיר ליציאת USB-C רגילה (מכשיר USB-C).
- יציאת USB Type-A במכשיר או כבלים שמתאימים יציאה קניינית במכשיר ליציאת USB Type-A רגילה.
- יציאת מיקרו USB מסוג AB במכשיר, שאמורה להגיע עם כבל שמתאים ליציאת USB מסוג A רגילה.
‫[C-1-3] אסור לשלוח עם מתאם שממיר מיציאות USB Type-A או micro-AB ליציאת USB Type-C (שקע).
[C-SR-1] מומלץ מאוד להטמיע את USB audio class כמו שמתואר במסמכי ה-Android SDK.
צריך לתמוך בטעינת מכשיר היקפי מחובר מסוג USB בזמן שהוא במצב מארח. צריך לפרסם זרם מקור של לפחות 1.5A כפי שמצוין בקטע Termination Parameters (פרמטרים של סיום) של USB Type-C Cable and Connector Specification Revision 1.2 (מפרט של כבל ומחבר USB Type-C, גרסה 1.2) למחברי USB Type-C או להשתמש בטווח זרם הפלט של Charging Downstream Port (CDP) (יציאת טעינה במורד הזרם) כפי שמצוין ב-USB Battery Charging specifications, revision 1.2 (מפרטים של טעינת סוללה באמצעות USB, גרסה 1.2) למחברי Micro-AB.
מומלץ להטמיע את תקני USB Type-C ולתמוך בהם.

אם הטמעות של מכשירים כוללות יציאת USB שתומכת במצב מארח ובמחלקה של אודיו USB, הן:

‫[C-2-1] המכשיר חייב לתמוך בסוג ה-HID של USB.
‫[C-2-2] חובה לתמוך בזיהוי ובמיפוי של שדות נתוני ה-HID הבאים שצוינו בטבלאות השימוש ב-USB HID ובבקשת השימוש בפקודה קולית לקבועים של KeyEvent כמו שמופיע בהמשך:
- דף שימוש (0xC) מזהה שימוש (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
- דף השימוש (0xC) מזהה השימוש (0x0E9): KEYCODE_VOLUME_UP
- דף שימוש (0xC) מזהה שימוש (0x0EA): KEYCODE_VOLUME_DOWN
- דף שימוש (0xC) מזהה שימוש (0x0CF): KEYCODE_VOICE_ASSIST

אם הטמעות של מכשירים כוללות יציאת USB שתומכת במצב מארח ובמסגרת Storage Access Framework‏ (SAF), הן:

‫[C-3-1] המכשיר חייב לזהות מכשירי MTP (פרוטוקול העברת מדיה) שמחוברים מרחוק ולאפשר גישה לתוכן שלהם באמצעות כוונות ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT ו-ACTION_CREATE_DOCUMENT.

אם הטמעות של מכשירים כוללות יציאת USB שתומכת במצב מארח וב-USB Type-C, הן:

‫[C-4-1] חובה להטמיע פונקציונליות של אספקת חשמל בתפקיד כפול (DRP) כפי שמוגדר במפרט USB Type-C (סעיף 4.5.1.3.3). בחיבורי DRP, במכשירים שכוללים שקע אודיו בגודל 3.5 מ"מ, יכול להיות שזיהוי מקור הכוח של ה-USB (מצב מארח) מושבת כברירת מחדל, אבל המשתמש חייב להיות מסוגל להפעיל אותו.
‫[C-SR-2] מומלץ מאוד לתמוך ב-DisplayPort.
- צריכה להיות תמיכה בקצבי העברת נתונים של USB SuperSpeed.
- מומלץ מאוד לתמוך בטעינה בתקן USB PD להעברת נתונים ולהחלפת תפקידים של נתונים וחשמל.
‫[C-SR-3] מומלץ מאוד לא לתמוך במצב של אביזר מתאם אודיו, כפי שמתואר בנספח א' של מפרט כבל ומחבר USB Type-C, גרסה 1.2.
מומלץ ליישם את מודל Try.* שמתאים ביותר לגורם הצורה של המכשיר. לדוגמה, במכשיר שניתן להחזיק ביד מומלץ להטמיע את מודל Try.SNK.

‫7.7.3. טעינה בתקן USB PD

אם יישומי המכשיר כוללים יציאת USB-C, הם:

[C-SR-1] מומלץ מאוד להטמיע את מחלקת מחברי USB Type-C של ליבת המערכת ולהטמיע את הצמתים הנדרשים שמתארים חיבורי USB Type-C ותפקידים של חשמל ונתונים. פרטים על ההטמעה מופיעים במסמכי התיעוד בנושא USB Type-C ב-Android.

אם הטמעות המכשירים כוללות יציאת USB-C ותומכות באספקת חשמל, הן:

[C-SR-2] מומלץ מאוד להטמיע את כל הצמתים שמתארים את טעינה בתקן USB PD. פרטים על ההטמעה מופיעים במסמכי התיעוד בנושא USB PD ב-Android.

אם יישומי המכשירים כוללים יציאת USB-C ותומכים במצבים חלופיים, הם:

‫[C-SR-3] מומלץ מאוד להטמיע את המצבים החלופיים ואת המאפיינים שקשורים לזהות של מחלקת מחברי USB Type-C של ליבת המערכת. פרטים על ההטמעה מופיעים במסמכי התיעוד בנושא USB Type-C ב-Android.

אם יישומי המכשיר כוללים יציאת USB-C ותומכים במצב חלופי של Thunderbolt 3, הם:

‫[C-SR-4] מומלץ מאוד להטמיע את היכולת לבטל את המצב החלופי הנוכחי באמצעות מחבר מסוג C.

‫7.8. אודיו

‫7.8.1. מיקרופון

אם הטמעות המכשירים כוללות מיקרופון, הן:

‫[C-1-1] חובה לדווח על קבוע התכונה android.hardware.microphone.
‫[C-1-2] חובה לעמוד בדרישות בנוגע להקלטות אודיו שמפורטות בקטע 5.4.
[C-1-3] המכשיר חייב לעמוד בדרישות בנוגע לזמן טעינת אודיו (audio latency) שמפורטות בקטע 5.6.
[C-SR-1] מומלץ מאוד לתמוך בהקלטה של תדרים קרובים לאולטרסאונד, כפי שמתואר בסעיף 7.8.3.

אם בהטמעות של מכשירים לא נכלל מיקרופון, המכשירים:

‫[C-2-1] אסור לדווח על הקבוע של התכונה android.hardware.microphone.
‫[C-2-2] חובה להטמיע את API להקלטת אודיו לפחות כבלי תפעול, בהתאם לסעיף 7.

‫7.8.2. יעד השמע

אם יישומי המכשיר כוללים רמקול או יציאת פלט אודיו/מולטימדיה עבור ציוד היקפי של פלט אודיו, כמו שקע אודיו 3.5 מ"מ עם 4 מוליכים או יציאת מצב מארח USB באמצעות מחלקת אודיו USB, הם:

‫[C-1-1] חובה לדווח על קבוע התכונה android.hardware.audio.output.
‫[C-1-2] חובה לעמוד בדרישות בנוגע להפעלת אודיו שמפורטות בסעיף 5.5.
[C-1-3] המכשיר חייב לעמוד בדרישות בנוגע לזמן טעינת אודיו (audio latency) שמפורטות בקטע 5.6.
[C-SR-1] מומלץ מאוד לתמוך בהפעלה של צלילים בתדרים קרובים לאולטרסאונד, כפי שמתואר בקטע 7.8.3.

אם הטמעות המכשירים לא כוללות רמקול או יציאת פלט אודיו, הן:

‫[C-2-1] אסור לדווח על התכונה android.hardware.audio.output.
[C-2-2] חובה להטמיע את ממשקי ה-API שקשורים לפלט אודיו כבלי תפעול (no-ops) לפחות.

לצורך הסעיף הזה, 'יציאת פלט' היא ממשק פיזי כמו שקע אודיו של 3.5 מ"מ, HDMI או יציאת מצב מארח USB עם מחלקת אודיו USB. תמיכה בפלט אודיו באמצעות פרוטוקולים מבוססי רדיו כמו Bluetooth,‏ Wi-Fi או רשת סלולרית לא נחשבת כהכללה של 'יציאת פלט'.

‫7.8.2.1. יציאות אודיו אנלוגיות

כדי שמכשירים יתאימו לאוזניות ולאביזרי אודיו אחרים עם תקע אודיו בגודל 3.5 מ"מ בכל מערכת Android, אם ההטמעות של המכשירים כוללות יציאת אודיו אנלוגית אחת או יותר, הן צריכות:

‫[C-SR-1] מומלץ מאוד לכלול לפחות אחד מחיבורי האודיו בתור שקע אודיו 3.5 מ'מ עם 4 מוליכים.

אם הטמעות המכשיר כוללות שקע אודיו בגודל 3.5 מ"מ עם 4 מוליכים, הן:

‫[C-1-1] חובה לתמוך בהפעלת אודיו באוזניות סטריאו ובאוזניות סטריאו עם מיקרופון.
‫[C-1-2] חובה לתמוך בתקעי אודיו מסוג TRRS עם סדר הפינים של CTIA.
‫[C-1-3] חובה לתמוך בזיהוי ובמיפוי לקודי המקשים של 3 טווחי עכבה שווים בין המיקרופון לבין מוליכי הארקה בתקע האודיו:
- ‫70 אוהם או פחות: KEYCODE_HEADSETHOOK
- ‫210-290 אוהם: KEYCODE_VOLUME_UP
- ‫360-680 אוהם: KEYCODE_VOLUME_DOWN
‫[C-1-4] חובה להפעיל את ACTION_HEADSET_PLUG כשמחברים את התקע, אבל רק אחרי שכל המגעים בתקע נוגעים בפלחים הרלוונטיים שלהם בשקע.
‫[C-1-5] חובה שתהיה אפשרות להפעיל לפחות 150mV ± 10% של מתח יציאה בעכבת רמקול של 32 אוהם.
‫[C-1-6] חובה להשתמש במיקרופון עם מתח הטיה בין ‎1.8 V ל-‎2.9 V.
‫[C-1-7] חובה לזהות ולמפות את קוד המקש לטווח הבא של עכבה שוות ערך בין המיקרופון לבין מוליכי הארקה בתקע האודיו:
- 110-180 אוהם: KEYCODE_VOICE_ASSIST
‫[C-SR-2] מומלץ מאוד לתמוך בתקעים לאודיו עם סדר הפינים של OMTP.
‫[C-SR-3] מומלץ מאוד לתמוך בהקלטת אודיו מאוזניות סטריאו עם מיקרופון.

אם הטמעות של מכשירים כוללות שקע אודיו 3.5 מ"מ עם 4 מוליכים ותומכות במיקרופון, והן משדרות את android.intent.action.HEADSET_PLUG עם המיקרופון הנוסף שמוגדר כ-1, הן:

‫[C-2-1] המכשיר חייב לתמוך בזיהוי של מיקרופון באביזר אודיו מחובר.

‫7.8.2.2. יציאות אודיו דיגיטליות

בקטע 2.2.1 מפורטות הדרישות הספציפיות למכשירים.

‫7.8.3. תדרים קרובים לאולטרסאונד

אודיו בתדר קרוב לאולטרסאונד הוא פס התדרים 18.5kHz עד 20kHz.

הטמעות במכשיר:

חובה לדווח בצורה נכונה על התמיכה ביכולת של אודיו בתדרים קרובים לאולטרסאונד באמצעות AudioManager.getProperty API באופן הבא:

אם הערך של PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND הוא true, מקורות האודיו VOICE_RECOGNITION ו-UNPROCESSED חייבים לעמוד בדרישות הבאות:

‫[C-1-1] תגובת ההספק הממוצע של המיקרופון בפס התדרים 18.5‎ kHz עד 20‎ kHz חייבת להיות נמוכה ב-15‎ dB לפחות מהתגובה בתדר 2‎ kHz.
‫[C-1-2] יחס האות לרעש הלא משוקלל של המיקרופון בטווח של 18.5‎ kHz עד 20‎ kHz עבור צליל של 19‎ kHz ב-‎-26 dBFS חייב להיות לפחות 50‎ dB.

אם PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND הוא true:

‫[C-2-1] התגובה הממוצעת של הרמקול בטווח 18.5‎ kHz עד 20‎ kHz לא יכולה להיות נמוכה מ-40‎ dB מתחת לתגובה ב-2‎ kHz.

‫7.8.4. תקינות האות

הטמעות במכשיר:

מומלץ לספק נתיב אות אודיו ללא תקלות לזרמי קלט ופלט במכשירים ניידים, כפי שמוגדר על ידי אפס תקלות שנמדדו במהלך בדיקה של דקה אחת לכל נתיב. בדיקה באמצעות OboeTester Automated Glitch Test.

הבדיקה דורשת מתאם ללולאת אודיו, לשימוש ישירות בשקע 3.5 מ"מ, או בשילוב עם מתאם USB-C ל-3.5 מ"מ. מומלץ לבדוק את כל יציאות פלט האודיו.

נכון לעכשיו, OboeTester תומך בנתיבי AAudio, ולכן כדאי לבדוק את השילובים הבאים לגבי תקלות באמצעות AAudio:

מצב ביצועים	שיתוף	תדירות הדגימה של הפלט	In Chans	Out Chans
LOW_LATENCY	בלעדי	UNSPECIFIED	1	2
LOW_LATENCY	בלעדי	UNSPECIFIED	2	1
LOW_LATENCY	משותף	UNSPECIFIED	1	2
LOW_LATENCY	משותף	UNSPECIFIED	2	1
ללא	משותף	48000	1	2
ללא	משותף	48000	2	1
ללא	משותף	44100	1	2
ללא	משותף	44100	2	1
ללא	משותף	16000	1	2
ללא	משותף	16000	2	1

שידור אמין צריך לעמוד בקריטריונים הבאים של יחס אות לרעש (SNR) ועיוות הרמוני כולל (THD) עבור סינוס של 2,000 הרץ.

מתמר	THD	SNR
רמקול מובנה ראשי, שנמדד באמצעות מיקרופון חיצוני להשוואה	< 3.0%	‫‎>= 50 dB
מיקרופון מובנה ראשי, שנמדד באמצעות רמקול חיצוני להשוואה	< 3.0%	‫‎>= 50 dB
שקעים אנלוגיים מובנים בגודל 3.5 מ"מ, שנבדקו באמצעות מתאם loopback	‎< 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, ולהציג את התוספים ברשימת התוספים הזמינים של EGL.
‫[C-1-8] חובה להטמיע את GL_EXT_multisampled_render_to_texture2,‏ GL_OVR_multiview,‏ GL_OVR_multiview2,‏ GL_EXT_protected_textures ולחשוף את התוספים ברשימת התוספים הזמינים של GL.
‫[C-SR-1] מומלץ מאוד להטמיע את GL_EXT_external_buffer,‏ GL_EXT_EGL_image_array,‏ GL_OVR_multiview_multisampled_render_to_texture ולחשוף את התוספים ברשימת התוספים הזמינים של GL.
‫[C-SR-2] מומלץ מאוד לתמוך ב-Vulkan 1.1.
‫[C-SR-3] מומלץ מאוד להטמיע את VK_ANDROID_external_memory_android_hardware_buffer,‏ VK_GOOGLE_display_timing,‏ VK_KHR_shared_presentable_image ולחשוף אותו ברשימת התוספים הזמינים של Vulkan.
‫[C-SR-4] מומלץ מאוד לחשוף לפחות משפחת תורים אחת של Vulkan שבה flags מכיל גם את VK_QUEUE_GRAPHICS_BIT וגם את VK_QUEUE_COMPUTE_BIT, ו-queueCount הוא לפחות 2.
‫[C-1-7] המעבד הגרפי והמסך חייבים להיות מסוגלים לסנכרן את הגישה למאגר הקדמי המשותף, כך שהצגת תוכן VR בטכניקת רינדור לסירוגין של העין בקצב של 60fps עם שני הקשרים של רינדור תתבצע ללא חפצי רינדור גלויים.
‫[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-5] מומלץ מאוד לתמוך בהקצאה של AHardwareBuffers עם יותר משכבה אחת וסימונים ופורמטים שצוינו ב-C-1-10.
‫[C-1-11] המכשיר חייב לתמוך בפענוח H.264 ברזולוציה של לפחות ‎3,840 x 2,160 ב-30fps,‏ דחוס בממוצע ל-40Mbps (שווה ל-4 מקרים של ‎1,920 x 1,080 ב-30fps‏ – 10Mbps או ל-2 מקרים של ‎1,920 x 1,080 ב-60fps‏ – 20Mbps).
‫[C-1-12] חובה לתמוך ב-HEVC וב-VP9, חובה להיות מסוגל לפענח לפחות ‎1920 x 1080‎ ב-30fps דחוס לממוצע של ‎10 Mbps, ורצוי להיות מסוגל לפענח ‎3840 x 2160‎ ב-30fps-20 Mbps (שווה ל-4 מקרים של ‎1920 x 1080‎ ב-30fps-5 Mbps).
‫[C-1-13] חובה לתמוך בממשק API‏ HardwarePropertiesManager.getDeviceTemperatures ולהחזיר ערכים מדויקים של טמפרטורת העור.
‫[C-1-14] חובה להטמיע מסך, והרזולוציה שלו חייבת להיות לפחות ‎1920 x 1080.
‫[C-SR-6] מומלץ מאוד שהרזולוציה של המסך תהיה לפחות ‎2560 x 1440.
‫[C-1-15] התצוגה חייבת להתעדכן בקצב של 60 הרץ לפחות כשהמכשיר במצב VR.
‫[C-1-17] המסך חייב לתמוך במצב של שימור נמוך עם שימור של ‎≤ 5 milliseconds, כאשר שימור מוגדר כמשך הזמן שבו פיקסל פולט אור.
‫[C-1-18] חובה לתמוך ב-Bluetooth 4.2 וב-Bluetooth LE Data Length Extension section 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-7] מומלץ מאוד לתמוך בסוג הערוץ הישיר TYPE_HARDWARE_BUFFER לכל סוגי הערוצים הישירים שצוינו למעלה.
‫[C-1-21] המכשיר חייב לעמוד בדרישות שקשורות לג'ירוסקופ, למד תאוצה ולמגנטומטר עבור android.hardware.hifi_sensors, כפי שמפורט בקטע 7.3.9.
‫[C-SR-8] מומלץ מאוד לתמוך בתכונה android.hardware.sensor.hifi_sensors.
‫[C-1-22] זמן האחזור הכולל מתנועה לפוטון לא יכול להיות גבוה מ-28 מילישניות.
‫[C-SR-9] מומלץ מאוד שזמן האחזור הכולל מתנועה לפוטון לא יעלה על 20 אלפיות השנייה.
‫[C-1-23] חובה לכלול יחס של המסגרת הראשונה, שהוא היחס בין בהירות הפיקסלים במסגרת הראשונה אחרי מעבר משחור ללבן, לבין בהירות הפיקסלים הלבנים במצב יציב, של 85% לפחות.
‫[C-SR-10] מומלץ מאוד ששיעור המסגרת הראשונה יהיה לפחות 90%.
יכול להיות שיוקצה ליבה בלעדית לאפליקציה שבחזית, ויכול להיות שתהיה תמיכה ב-API‏ Process.getExclusiveCores כדי להחזיר את מספרי ליבות ה-CPU שמוקצות באופן בלעדי לאפליקציה המובילה שבחזית.

אם יש תמיכה בשימוש בלעדי בליבה, אז הליבה:

‫[C-2-1] אסור לאפשר לתהליכים אחרים במרחב המשתמשים לפעול בו (למעט מנהלי התקנים של מכשירים שמשמשים את האפליקציה), אבל מותר לאפשר לתהליכים מסוימים של ליבת המערכת לפעול בו לפי הצורך.

‫7.10. מגע

מכשירים שמיועדים לאחיזה ביד או לענידה עשויים לכלול מפעיל הפטי כללי, שזמין לאפליקציות למטרות שונות, כולל משיכת תשומת לב באמצעות צלצולים, אזעקות, התראות ומשוב כללי על מגע.

אם ההטמעות של המכשירים לא כוללות מפעיל הפטי כללי כזה, הן:

‫[7.10/C] הפונקציה MUST מחזירה false עבור Vibrator.hasVibrator().

אם הטמעות במכשירים כוללות לפחות מפעיל הפטי כללי אחד כזה, הן:

‫[C-1-1] מחזירה true עבור Vibrator.hasVibrator().
אסור להשתמש במפעיל הפטי (רטט) עם מסה מסתובבת אקסצנטרית (ERM).
מומלץ להטמיע את כל הקבועים הציבוריים עבור משוב פיזי ברור ב-android.view.HapticFeedbackConstants, כלומר (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START ו-GESTURE_END).
מומלץ להטמיע את כל הקבועים הציבוריים של משוב הפטי ברור ב-android.os.VibrationEffect כלומר (EFFECT_TICK,‏ EFFECT_CLICK,‏ EFFECT_HEAVY_CLICK ו-EFFECT_DOUBLE_CLICK) ואת כל הקבועים הציבוריים האפשריים של PRIMITIVE_*משוב הפטי עשיר ב-android.os.VibrationEffect.Composition כלומר (CLICK,‏ TICK,‏ LOW_TICK,‏ QUICK_FALL,‏ QUICK_RISE,‏ SLOW_RISE,‏ SPIN,‏ THUD). חלק מהפרימיטיבים האלה, כמו LOW_TICK ו-SPIN, עשויים להיות אפשריים רק אם הרטט יכול לתמוך בתדרים נמוכים יחסית.
מומלץ לפעול לפי ההנחיות למיפוי קבועים ציבוריים ב-android.view.HapticFeedbackConstants לקבועים המומלצים android.os.VibrationEffect, עם יחסי האמפליטודה המתאימים.
מומלץ להשתמש במיפויים של קבועי הפידבק ההפטי המקושרים האלה.
צריך לפעול בהתאם להערכת האיכות של ממשקי ה-API‏ createOneShot() ו-createWaveform().
מומלץ לוודא שהתוצאה של ה-API הציבורי android.os.Vibrator.hasAmplitudeControl() משקפת בצורה נכונה את היכולות של הוויברטור.
מומלץ לאמת את היכולות של התאמה לעומס של אמפליטודה על ידי הפעלת android.os.Vibrator.hasAmplitudeControl().

אם הטמעות המכשירים פועלות לפי מיפוי הקבועים של התחושה המישושית, הן:

מומלץ לאמת את סטטוס ההטמעה באמצעות הפעלת ממשקי ה-API‏ android.os.Vibrator.areAllEffectsSupported() ו-android.os.Vibrator.arePrimitivesSupported().
מומלץ לבצע הערכת איכות של קבועי המישוש.
מומלץ לאמת ולעדכן את הגדרת ברירת המחדל עבור פרימיטיבים לא נתמכים, כפי שמתואר בהנחיות ההטמעה של קבועים.
מומלץ לספק תמיכה חלופית כדי לצמצם את הסיכון לכשל, כפי שמתואר כאן.

‫7.11. סיווג ביצועים של מדיה

אפשר לקבל את סיווג הביצועים של המדיה בהטמעה של המכשיר באמצעות android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS API. הדרישות לסיווג ביצועים של מדיה מוגדרות לכל גרסת Android החל מגרסה R‏ (30). הערך המיוחד 0 מציין שהמכשיר לא שייך לסיווג ביצועים של מדיה.

אם הטמעות של מכשירים מחזירות ערך שאינו אפס עבור android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, הן:

‫[C-1-1] הפונקציה חייבת להחזיר ערך של android.os.Build.VERSION_CODES.R לפחות.
[C-1-2] חובה להיות הטמעה של מכשיר שניתן להחזיק ביד.
‫[C-1-3] חובה לעמוד בכל הדרישות של 'סיווג ביצועים של מדיה' שמתוארות בקטע 2.2.7.

במילים אחרות, סיווג הביצועים של המדיה ב-Android T מוגדר רק למכשירים ניידים בגרסה T, ‏ S או R.

בקטע 2.2.7 מפורטות הדרישות הספציפיות למכשירים.

8. ביצועים וצריכת חשמל

קריטריונים מסוימים של ביצועים וצריכת חשמל מינימליים הם קריטיים לחוויית המשתמש ומשפיעים על הנחות הבסיס של מפתחים כשמפתחים אפליקציה.

‫8.1. עקביות בחוויית המשתמש

אפשר לספק למשתמש הקצה ממשק משתמש חלק אם יש דרישות מינימליות מסוימות כדי להבטיח קצב פריימים עקבי וזמני תגובה עקביים לאפליקציות ולמשחקים. יכול להיות שיישומים במכשירים, בהתאם לסוג המכשיר, יכללו דרישות מדידות לגבי זמן האחזור של ממשק המשתמש ומעבר בין משימות, כמו שמתואר בקטע 2.

‫8.2. ביצועי גישת קלט/פלט של קבצים

הגדרת בסיס משותף לביצועים עקביים של גישה לקבצים באחסון הנתונים הפרטי של האפליקציה (מחיצת /data) מאפשרת למפתחי אפליקציות להגדיר ציפייה מתאימה שתעזור להם בתכנון התוכנה. במכשירים מסוימים, בהתאם לסוג המכשיר, עשויים להיות דרישות מסוימות שמתוארות בקטע 2 לפעולות הקריאה והכתיבה הבאות:

ביצועי כתיבה רציפה. הבדיקה בוצעה על ידי כתיבת קובץ בגודל 256MB באמצעות מאגר זמני לכתיבה בגודל 10MB.
ביצועים של כתיבה אקראית. הערך נמדד על ידי כתיבת קובץ בגודל 256MB באמצעות מאגר כתיבה בגודל 4KB.
ביצועים של קריאה רציפה. הנתון הזה נמדד על ידי קריאת קובץ בגודל 256MB באמצעות מאגר כתיבה בגודל 10MB.
ביצועי קריאה אקראית. הבדיקה מתבצעת על ידי קריאת קובץ בגודל 256MB באמצעות מאגר כתיבה בגודל 4KB.

8.3. מצבי חיסכון באנרגיה

אם הטמעות המכשירים כוללות תכונות לשיפור ניהול צריכת החשמל במכשיר, שנכללות ב-AOSP (למשל, אפליקציה במצב המתנה Bucket,‏ נמנום) או מרחיבות את התכונות כדי להחיל הגבלות חזקות יותר מאלה של אפליקציה במצב המתנה Bucket‏ RESTRICTED, הן:

‫[C-1-1] אסור לחרוג מההטמעה של AOSP להפעלת אלגוריתמים, לתחזוקה שלהם, להפעלת המכשיר ולשימוש בהגדרות מערכת גלובליות או ב-DeviceConfig של מצבי המתנה של האפליקציה ומצבי שינה לחיסכון בצריכת החשמל.
‫[C-1-2] אסור לסטות מההטמעה של AOSP לשימוש בהגדרות גלובליות או ב-DeviceConfig כדי לנהל את ההגבלות על משימות, אזעקות ורשתות עבור אפליקציות בכל דלי של מצב המתנה של אפליקציות.
[C-1-3] אסור לסטות מההטמעה של AOSP לגבי מספר הדליים של אפליקציה במצב המתנה שמשמשים לאפליקציה במצב המתנה.
[C-1-4] חובה להטמיע קטגוריות אפליקציה במצב המתנה ו-נמנום כמו שמתואר בניהול צריכת חשמל.
‫[C-1-5] חובה להחזיר את true עבור PowerManager.isPowerSaveMode() כשהמכשיר נמצא במצב חיסכון באנרגיה.
‫[C-1-6] חובה לספק למשתמשים מזמינוּת להצגת כל האפליקציות שמוחרגות ממצב המתנה של האפליקציה וממצבי נמנום או מכל ייעול חיי הסוללה, וחובה להטמיע את Intent‏ ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS כדי לבקש מהמשתמשים לאפשר לאפליקציה להתעלם מייעול חיי הסוללה.
[C-SR-1] מומלץ מאוד לספק למשתמשים מזמינוּת להפעיל ולהשבית את תכונת החיסכון בסוללה.
‫[C-SR-2] מומלץ מאוד לספק למשתמשים אפשרות להציג את כל האפליקציות שמוחרגות ממצב המתנה של האפליקציה וממצב שינה לחיסכון בסוללה.

אם הטמעות של מכשירים מרחיבות את תכונות ניהול צריכת החשמל שנכללות ב-AOSP, וההרחבה הזו מטילה הגבלות מחמירות יותר מאלה שמוטלות על המאגר של אפליקציות במצב המתנה בשימוש לא תדיר, צריך לעיין בקטע 3.5.1.

בנוסף למצבי חיסכון באנרגיה, יכול להיות שהטמעות של מכשירי Android יכללו חלק ממצבי השינה הבאים או את כולם, כפי שהם מוגדרים בממשק המתקדם להגדרת צריכת חשמל (ACPI).

אם הטמעות של מכשירים מטמיעות מצבי הפעלה S4 כפי שמוגדרים ב-ACPI, הן:

‫[C-1-1] המכשיר חייב להיכנס למצב הזה רק אחרי שהמשתמש ביצע פעולה מפורשת כדי להעביר את המכשיר למצב לא פעיל (למשל, סגירת מכסה שהוא חלק פיזי מהמכשיר או כיבוי של רכב או טלוויזיה) ולפני שהמשתמש מפעיל מחדש את המכשיר (למשל, פתיחת המכסה או הפעלה מחדש של הרכב או הטלוויזיה).

אם הטמעות של מכשירים מטמיעות מצבי הפעלה של S3 כפי שמוגדר על ידי ACPI, הן:

‫[C-2-1] המכשיר חייב לעמוד בדרישה C-1-1 שלמעלה, או שהוא חייב להיכנס למצב S3 רק כשאפליקציות של צד שלישי לא צריכות את משאבי המערכת (למשל, המסך, המעבד).

לעומת זאת, המערכת חייבת לצאת ממצב S3 כשיישומים של צד שלישי צריכים את משאבי המערכת, כפי שמתואר ב-SDK הזה.

לדוגמה, אם אפליקציות צד שלישי שולחות בקשה להשאיר את המסך פתוח באמצעות FLAG_KEEP_SCREEN_ON או להמשיך להפעיל את המעבד באמצעות PARTIAL_WAKE_LOCK, המכשיר לא יכול לעבור למצב S3 אלא אם המשתמש ביצע פעולה מפורשת כדי להעביר את המכשיר למצב לא פעיל, כפי שמתואר ב-C-1-1. לעומת זאת, בזמן שמשימה שמיושמת על ידי אפליקציות צד שלישי באמצעות JobScheduler מופעלת או בזמן ששירות העברת ההודעות בענן ב-Firebase מועבר לאפליקציות צד שלישי, המכשיר חייב לצאת ממצב S3, אלא אם המשתמש העביר את המכשיר למצב לא פעיל. אלה לא דוגמאות מקיפות, וב-AOSP מיושמים אותות השכמה רבים שמפעילים הוצאה ממצב שינה מהמצב הזה.

8.4. חישוב צריכת החשמל

דיווח מדויק יותר על צריכת החשמל מספק למפתחי האפליקציה תמריצים וכלים לאופטימיזציה של דפוס השימוש בחשמל של האפליקציה.

הטמעות במכשיר:

[C-SR-1] מומלץ מאוד לספק פרופיל צריכת חשמל לכל רכיב שמגדיר את ערך צריכת הזרם לכל רכיב חומרה ואת התרוקנות הסוללה המשוערת שנגרמת על ידי הרכיבים לאורך זמן, כפי שמתועד באתר פרויקט קוד פתוח של Android.
‫[C-SR-2] מומלץ מאוד לדווח על כל ערכי צריכת החשמל במיליאמפר-שעה (mAh).
‫[C-SR-3] מומלץ מאוד לדווח על צריכת החשמל של המעבד לכל UID של תהליך. פרויקט הקוד הפתוח של Android עומד בדרישה באמצעות הטמעה של מודול הליבה uid_cputime.
‫[C-SR-4] מומלץ מאוד להפוך את נתוני צריכת החשמל האלה לזמינים למפתחי האפליקציה באמצעות פקודת ה-Shell‏: adb shell dumpsys batterystats.
צריך לשייך את צריכת החשמל לרכיב החומרה עצמו אם אי אפשר לשייך אותה לאפליקציה.

‫8.5. ביצועים עקביים

הביצועים של אפליקציות שפועלות לאורך זמן ודורשות ביצועים גבוהים יכולים להשתנות באופן משמעותי, בגלל אפליקציות אחרות שפועלות ברקע או בגלל הגבלת מהירות המעבד (CPU throttling) עקב מגבלות טמפרטורה. ‫Android כוללת ממשקי תכנות כך שאם המכשיר מסוגל לכך, האפליקציה העליונה בחזית יכולה לבקש מהמערכת לבצע אופטימיזציה של הקצאת המשאבים כדי לטפל בתנודות כאלה.

הטמעות במכשיר:

‫[C-0-1] חובה לדווח על התמיכה במצב ביצועים רציף בצורה מדויקת באמצעות שיטת ה-API‏ PowerManager.isSustainedPerformanceModeSupported().
צריכה להיות תמיכה במצב ביצועים רציף.

אם הטמעות של מכשירים מדווחות על תמיכה במצב ביצועים רציף, הן:

‫[C-1-1] חובה לספק לאפליקציה המוצגת בחזית רמת ביצועים עקבית למשך 30 דקות לפחות, כשהאפליקציה מבקשת זאת.
‫[C-1-2] חובה לכבד את Window.setSustainedPerformanceMode() API וממשקי API קשורים אחרים.

אם הטמעות המכשירים כוללות שתי ליבות CPU או יותר, הן:

מומלץ לספק לפחות ליבת בלעדית אחת שאפשר לשריין לאפליקציה המובילה ברקע.

אם הטמעות של מכשירים תומכות בהקצאה של ליבה אחת בלעדית לאפליקציה העליונה ברקע, הן:

‫[C-2-1] חובה לדווח באמצעות שיטת ה-API‏ Process.getExclusiveCores() את מספרי הליבות הבלעדיות שאפשר לשריין עבור האפליקציה העליונה בחזית.
‫[C-2-2] אסור לאפשר תהליכים במרחב המשתמשים, מלבד מנהלי ההתקנים שבהם האפליקציה משתמשת כדי לפעול בליבות הבלעדיות, אבל מותר לאפשר לתהליכי ליבה מסוימים לפעול לפי הצורך.

אם הטמעות של מכשירים לא תומכות בליבה בלעדית, הן:

‫[C-3-1] חובה להחזיר רשימה ריקה דרך המתודה Process.getExclusiveCores() של ה-API.

‫8.6. מגבלות זיכרון של אפליקציות

‫MemoryLimiter, רכיב חדש של ActivityManagerService, ומגבלות ברירת המחדל של זיכרון האפליקציה, שנגזרות מזיכרון פיזי זמין, יטילו מגבלות על כמות ה-DRAM שמשמשת כל תהליך של אפליקציה בודדת. ההגבלה הזו חלה על כל הזיכרון שהוקצה בתהליך האפליקציה, כדי להבטיח שהמגבלות יפעלו כהתנהגות חוזית קריטית עם מפתחי האפליקציות.

הטמעות במכשיר:

‫[C-0-1] אסור להשתמש בשיטות, ברשימות היתרים או במדיניות כדי לעקוף את מגבלות הזיכרון בזמן הריצה שמוגדרות לאפליקציות.

9. תאימות של מודל האבטחה

הטמעות במכשיר:

‫[C-0-1] חובה להטמיע מודל אבטחה שתואם למודל האבטחה של פלטפורמת Android, כפי שמוגדר במסמך העזר בנושא אבטחה והרשאות בממשקי ה-API במסמכי התיעוד למפתחי Android.
‫[C-0-2] חובה לתמוך בהתקנה של אפליקציות בחתימה עצמית בלי לדרוש הרשאות או אישורים נוספים מצדדים שלישיים או מרשויות כלשהן.

אם הטמעות של מכשירים מצהירות על התכונה android.hardware.security.model.compatible:

‫[C-1-1] חובה לתמוך בדרישות שמפורטות בקטעי המשנה הבאים.

‫9.1. הרשאות

הטמעות במכשיר:

‫[C-0-1] חובה לתמוך במודל ההרשאות של Android ובמודל התפקידים של Android, כפי שמוגדר בתיעוד למפתחים של Android. באופן ספציפי, עליהם לאכוף כל הרשאה ותפקיד שמוגדרים כפי שמתואר במסמכי ה-SDK. אסור להשמיט, לשנות או להתעלם מהרשאות או מתפקידים.
יכול להיות שיוספו הרשאות נוספות, בתנאי שמחרוזות מזהי ההרשאות החדשות לא נמצאות במרחב השמות android.\*.
[C-0-2] הרשאות עם protectionLevel של PROTECTION_FLAG_PRIVILEGED חייבות להינתן רק לאפליקציות שמותקנות מראש בנתיבים בעלי הרשאות מיוחדות בקובץ אימג' של המערכת (וגם לקובצי APEX), ולהיות בתוך קבוצת המשנה של ההרשאות שנוספו לרשימת ההיתרים באופן מפורש לכל אפליקציה. הטמעה של AOSP עומדת בדרישה הזו על ידי קריאה של ההרשאות שנוספו לרשימת ההיתרים לכל אפליקציה מהקבצים בנתיב etc/permissions/, ושימוש בנתיב system/priv-app כנתיב בעל הרשאות מיוחדות.
‫[C-SR-1] מומלץ מאוד להעניק הרשאות עם protectionLevel של PROTECTION_SIGNATURE רק לאחת מהאפשרויות הבאות:
- אפליקציות שהותקנו מראש בקובץ האימג' של המערכת (וגם קובצי APEX).
- אפליקציות ברשימת ההיתרים עם הרשאות מותרות אם הן לא כלולות בקובץ אימג' של המערכת.
הערה: ההטמעה של AOSP עומדת בדרישה הזו על ידי קריאה של ההרשאות שמופיעות ברשימת ההיתרים לכל אפליקציה מהקבצים בנתיב etc/permissions/, ופועלת בהתאם להן.

הרשאות עם רמת הגנה מסוכנת הן הרשאות זמן ריצה. אפליקציות עם targetSdkVersion > 22 מבקשות אותן בזמן הריצה.

הטמעות במכשיר:

‫[C-0-3] חובה להציג למשתמש ממשק ייעודי שבו הוא יכול להחליט אם להעניק את ההרשאות המבוקשות בזמן הריצה, וגם לספק למשתמש ממשק לניהול הרשאות בזמן הריצה.
‫[C-0-5] אסור להעניק הרשאות בתחילת ההפעלה לאפליקציות, אלא אם:
- הן מותקנות בזמן משלוח המכשיר, וגם
- אפשר לקבל את הסכמת המשתמש לפני שהאפליקציה משתמשת בהרשאה,
או
- ההרשאות בזמן הריצה מוענקות על ידי מדיניות ברירת המחדל למתן הרשאות או על ידי החזקה של תפקיד בפלטפורמה.
‫[C-0-6] חובה להעניק את ההרשאה android.permission.RECOVER_KEYSTORE רק לאפליקציות מערכת שרושמות סוכן שחזור מאובטח כראוי. סוכן שחזור מאובטח מוגדר כסוכן תוכנה במכשיר שמסתנכרן עם אחסון מרוחק מחוץ למכשיר, שמצויד בחומרה מאובטחת עם הגנה ששווה או חזקה יותר מזו שמתוארת ב-Google Cloud Key Vault Service כדי למנוע מתקפות ברוט פורס על גורם הידע של מסך הנעילה.

הטמעות במכשיר:

[C-0-7] האפליקציה חייבת לפעול בהתאם למאפיינים של הרשאת המיקום ב-Android כשמבקשים נתוני מיקום או נתוני פעילות גופנית באמצעות API רגיל של Android או מנגנון קנייני. הנתונים האלה כוללים, בין היתר:
- מיקום המכשיר (למשל, קו רוחב וקו אורך) כפי שמתואר בסעיף 9.8.8.
- מידע שאפשר להשתמש בו כדי לקבוע או להעריך את מיקום המכשיר (למשל, SSID,‏ BSSID,‏ Cell ID או מיקום הרשת שהמכשיר מחובר אליה).
- הפעילות הגופנית של המשתמש או הסיווג של הפעילות הגופנית.

באופן ספציפי יותר, הטמעות במכשירים:

‫[C-0-8] חובה לקבל הסכמה מהמשתמש כדי לאפשר לאפליקציה לגשת לנתוני המיקום או נתוני הפעילות.
[C-0-9] חובה להעניק הרשאה בתחילת ההפעלה רק לאפליקציה שמחזיקה בהרשאה מספקת כפי שמתואר ב-SDK. לדוגמה, TelephonyManager#getServiceState דורשת android.permission.ACCESS_FINE_LOCATION.

החריגים היחידים למאפייני הרשאת המיקום ב-Android שצוינו למעלה הם אפליקציות שלא ניגשות למיקום כדי לגזור או לזהות את מיקום המשתמש. באופן ספציפי:

כשהאפליקציות מחזיקות בהרשאה RADIO_SCAN_WITHOUT_LOCATION.
למטרות הגדרה והתאמה אישית של המכשיר, שבהן לאפליקציות מערכת יש הרשאה NETWORK_SETTINGS או NETWORK_SETUP_WIZARD.

אפשר לסמן הרשאות כמוגבלות כדי לשנות את אופן הפעולה שלהן.

‫[C-0-10] אסור להעניק הרשאות שמסומנות בדגל hardRestricted לאפליקציה, אלא אם:
- קובץ APK של אפליקציה נמצא במחיצת המערכת.
- המשתמש מקצה לאפליקציה תפקיד שמשויכות אליו הרשאות hardRestricted.
- תוכנת ההתקנה מעניקה את hardRestricted לאפליקציה.
- לאפליקציה ניתנה ההרשאה hardRestricted בגרסה קודמת של Android.
‫[C-0-11] אפליקציות שמחזיקות בהרשאה softRestricted חייבות לקבל רק גישה מוגבלת, ואסור להן לקבל גישה מלאה עד שהן יתווספו לרשימת ההיתרים כפי שמתואר ב-SDK. ב-SDK מוגדרת גישה מלאה וגישה מוגבלת לכל הרשאה softRestricted (לדוגמה, READ_EXTERNAL_STORAGE).
‫[C-0-12] אסור לספק פונקציות בהתאמה אישית או ממשקי API כדי לעקוף את ההגבלות על הרשאות שמוגדרות בממשקי API‏ setPermissionPolicy ו-setPermissionGrantState.
‫[C-0-13] חובה להשתמש בממשקי AppOpsManager API כדי לתעד ולעקוב אחרי כל גישה תוכנתית לנתונים שמוגנים על ידי הרשאות מסוכנות מפעילויות ושירותים של Android.
‫[C-0-14] חובה להקצות תפקידים רק לאפליקציות עם פונקציות שעומדות בדרישות התפקיד.
‫[C-0-15] אסור להגדיר תפקידים שהם כפילויות או קבוצת-על של פונקציונליות של תפקידים שהוגדרו על ידי הפלטפורמה.

אם המכשירים כוללים חיישני נתונים שחושפים נתונים ביומטריים שקשורים לבריאות, כמו דופק או טמפרטורת העור, הנתונים הביומטריים האלה:

‫[C-0-16] חובה להגן על ההרשאות באמצעות הרשאות פלטפורמה מ-android.permission-group.HEALTH, אם יש הרשאה תואמת ב-HealthPermissions.
‫[C-0-17] חובה, אם אין הרשאת פלטפורמה שתואמת לסוג הנתונים הרצוי, להשתמש בהרשאת מערכת מותאמת אישית. (לדוגמה, ELECTROCARDIOGRAM).

אם המכשירים מדווחים על android.software.managed_users, הם:

‫[C-1-1] אסור שההרשאות הבאות יינתנו באופן שקט על ידי האדמין:
- מיקום (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- מצלמה (CAMERA)
- מיקרופון (RECORD_AUDIO)
- חיישן לביש (BODY_SENSORS)
- בריאות (HealthPermissions)
- פעילות גופנית (ACTIVITY_RECOGNITION)

אם המכשירים מדווחים על android.software.managed_users, הם:

‫[C-1-1] אסור שההרשאות הבאות יינתנו באופן שקט על ידי האדמין:
- מיקום (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- מצלמה (CAMERA)
- מיקרופון (RECORD_AUDIO)
- חיישן לביש (BODY_SENSORS)
- פעילות גופנית (ACTIVITY_RECOGNITION)

אם הטמעות של מכשירים מספקות למשתמשים אפשרות לבחור אילו אפליקציות יכולות לצייר מעל אפליקציות אחרות באמצעות פעילות שמטפלת ב-Intent‏ ACTION_MANAGE_OVERLAY_PERMISSION, הן:

‫[C-2-1] חובה לוודא שלכל הפעילויות עם מסנני Intent עבור Intent מסוג ACTION_MANAGE_OVERLAY_PERMISSION יש אותו מסך ממשק משתמש, ללא קשר לאפליקציה שמפעילה את ה-Intent או למידע שהיא מספקת.

אם הטמעות של מכשירים מדווחות על android.software.device_admin, הן:

‫[C-3-1] חובה להציג כתב ויתור במהלך הגדרת מכשיר בניהול מלא (הגדרת בעלי המכשיר) שבו מצוין שאדמין ה-IT יוכל לאפשר לאפליקציות לשלוט בהגדרות בטלפון, כולל המיקרופון, המצלמה והמיקום, עם אפשרויות למשתמש להמשיך בהגדרה או לצאת ממנה, אלא אם האדמין ביטל את ההסכמה לשליטה בהרשאות במכשיר.

אם בהטמעות של מכשירים מותקנות מראש חבילות שמכילות תפקידים של System UI Intelligence,‏ System Ambient Audio Intelligence,‏ System Audio Intelligence,‏ System Notification Intelligence,‏ System Text Intelligence או System Visual Intelligence, החבילות:

‫[C-4-1] חובה לעמוד בכל הדרישות שמופיעות בנושא הטמעות במכשירים בקטעים 9.8.6. נתונים ברמת מערכת ההפעלה ונתונים סביבתיים ו9.8.15. הטמעות של Sandboxed API.

9.2. ‫UID ובידוד תהליכים

הטמעות במכשיר:

[C-0-1] חובה לתמוך במודל ארגז החול של אפליקציות ל-Android, שבו כל אפליקציה פועלת כמזהה משתמש (UID) ייחודי בסגנון Unix ובתהליך נפרד.
‫[C-0-2] חובה לתמוך בהרצת כמה אפליקציות עם אותו מזהה משתמש ב-Linux, בתנאי שהאפליקציות חתומות ומבונות כראוי, כפי שמוגדר בהפניה בנושא אבטחה והרשאות.

‫9.3. הרשאות במערכת הקבצים

הטמעות במכשיר:

‫[C-0-1] חובה לתמוך במודל ההרשאות לגישה לקבצים ב-Android, כפי שמוגדר בהפניה בנושא אבטחה והרשאות.

9.4. סביבות הפעלה חלופיות

הטמעות של מכשירים חייבות לשמור על עקביות של מודל האבטחה ומודל ההרשאות של Android, גם אם הן כוללות סביבות זמן ריצה שמבצעות אפליקציות באמצעות תוכנה או טכנולוגיה אחרות, ולא באמצעות פורמט קובץ ההפעלה של Dalvik או קוד Native. במילים אחרות:

‫[C-0-1] סביבות זמן ריצה חלופיות חייבות להיות אפליקציות Android, ולפעול בהתאם למודל האבטחה הרגיל של Android, כפי שמתואר במקום אחר בסעיף 9.
‫[C-0-2] אין להעניק לסביבות זמן ריצה חלופיות גישה למשאבים מוגנים באמצעות הרשאות שלא נדרשו בקובץ AndroidManifest.xml של סביבת זמן הריצה באמצעות מנגנון <uses-permission>.
‫[C-0-3] סביבות הפעלה חלופיות לא יכולות לאפשר לאפליקציות להשתמש בתכונות שמוגנות על ידי הרשאות Android שמוגבלות לאפליקציות מערכת.
‫[C-0-4] סביבות ריצה חלופיות חייבות לפעול בהתאם למודל ארגז החול של Android, ואפליקציות מותקנות שמשתמשות בסביבת ריצה חלופית לא יכולות לעשות שימוש חוזר בארגז החול של אפליקציה אחרת שהותקנה במכשיר, אלא באמצעות המנגנונים הרגילים של 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 כוללת תמיכה במספר משתמשים ומספקת תמיכה בבידוד מלא של משתמשים ובשיבוט של פרופילי משתמשים עם בידוד חלקי (כלומר, פרופיל משתמש נוסף יחיד מסוג android.os.usertype.profile.CLONE).

הטמעות של מכשירים עשויות לאפשר שימוש בכמה משתמשים, אבל לא מומלץ לעשות זאת אם הן משתמשות במדיה ניידת לאחסון חיצוני ראשי.

אם הטמעות של מכשירים כוללות תמיכה בכמה משתמשים, הן:

‫[C-1-2] חובה, עבור כל משתמש, להטמיע מודל אבטחה שתואם למודל האבטחה של פלטפורמת Android, כפי שמוגדר במסמך העזר בנושא אבטחה והרשאות בממשקי ה-API.
‫[C-1-3] חובה להשתמש בספריות נפרדות ומבודדות של אחסון אפליקציות משותף (שנקראות גם /sdcard) לכל מופע של משתמש.
‫[C-1-4] חובה לוודא שאפליקציות שנמצאות בבעלות של משתמש מסוים ופועלות בשמו לא יכולות להציג, לקרוא או לכתוב בקבצים שנמצאים בבעלות של משתמש אחר, גם אם הנתונים של שני המשתמשים מאוחסנים באותו אמצעי אחסון או באותה מערכת קבצים.
‫[C-1-5] חובה להצפין את התוכן של כרטיס ה-SD כשמופעלת תמיכה בכמה משתמשים באמצעות מפתח שמאוחסן רק במדיה לא נשלפת שנגישה רק למערכת, אם הטמעות המכשיר משתמשות במדיה נשלפת עבור ממשקי ה-API של האחסון החיצוני. הפעולה הזו תגרום לכך שמחשב מארח לא יוכל לקרוא את המדיה, ולכן יישומי מכשירים יצטרכו לעבור ל-MTP או למערכת דומה כדי לספק למחשבים מארחים גישה לנתונים של המשתמש הנוכחי.

אם הטמעות במכשירים כוללות תמיכה בכמה משתמשים, אז לכל המשתמשים, למעט משתמשים שנוצרו במיוחד להפעלת שני מופעים של אותה אפליקציה, מתקיימים התנאים הבאים:

‫[C-2-1] חובה להשתמש בספריות נפרדות ומבודדות של אחסון משותף לאפליקציות (שנקראות גם /sdcard) לכל מופע משתמש.
‫[C-2-2] חובה לוודא שאפליקציות שנמצאות בבעלות של משתמש מסוים ופועלות בשמו לא יכולות להציג, לקרוא או לכתוב בקבצים שנמצאים בבעלות של משתמש אחר, גם אם הנתונים של שני המשתמשים מאוחסנים באותו נפח או באותה מערכת קבצים.

יכול להיות שהטמעות של מכשירים ייצרו פרופיל משתמש נוסף יחיד מסוג android.os.usertype.profile.CLONE עבור המשתמש הראשי (ורק עבור המשתמש הראשי) לצורך הפעלת שני מופעים של אותה אפליקציה. שני המופעים האלה חולקים אחסון מבודד באופן חלקי, מוצגים למשתמש הקצה במרכז האפליקציות בו-זמנית ומופיעים באותו תצוגת אפליקציות שהיו בשימוש לאחרונה. לדוגמה, אפשר להשתמש בזה כדי לתמוך במשתמש שמתקין שני מופעים נפרדים של אפליקציה אחת במכשיר עם שני כרטיסי SIM.

אם הטמעות של מכשירים יוצרות את פרופיל המשתמש הנוסף שצוין למעלה, הן:

‫[C-3-1] חובה לספק גישה רק לאחסון או לנתונים שכבר נגישים לפרופיל המשתמש הראשי או שנמצאים בבעלות ישירה של פרופיל המשתמש הנוסף הזה.
‫[C-3-2] אסור שהמכשיר יכלול את זה כפרופיל עבודה.
‫[C-3-3] חובה להפריד את נתוני האפליקציה הפרטית מחשבון המשתמש הראשי.
‫[C-3-4] אסור לאפשר יצירה של פרופיל משתמש נוסף אם הוקצה בעלים למכשיר (ראו סעיף 3.9.1), או לאפשר הקצאה של בעלים למכשיר בלי להסיר קודם את פרופיל המשתמש הנוסף.

אם הטמעות של מכשירים יוצרות את פרופיל המשתמש הנוסף שצוין למעלה, הן:

‫[C-4-1] המכשיר חייב לאפשר לאפליקציות של המשתמש הראשי לטפל בכוונות הבאות שמקורן בפרופיל הנוסף:
- Intent.ACTION_VIEW
- Intent.ACTION_SENDTO
- Intent.ACTION_SEND
- Intent.ACTION_EDIT
- Intent.ACTION_INSERT
- Intent.ACTION_INSERT_OR_EDIT
- Intent.ACTION_SEND_MULTIPLE
- Intent.ACTION_PICK
- Intent.ACTION_GET_CONTENT
- MediaStore.ACTION_IMAGE_CAPTURE
- MediaStore.ACTION_VIDEO_CAPTURE
‫[C-4-2] חובה להעביר את כל ההגבלות על המשתמשים במדיניות המכשיר ואת ההגדרות הנבחרות של restrictions(list below) שאינן קשורות למשתמש שהוחלו על המשתמש הראשי במכשיר לפרופיל המשתמש הנוסף הזה.
‫[C-4-3] חובה לאפשר כתיבת אנשי קשר מהפרופיל הנוסף הזה רק באמצעות הכוונות הבאות:
‫[C-4-4] אסור להפעיל סנכרון של אנשי קשר באפליקציות שפועלות בפרופיל המשתמש הנוסף הזה.
‫[C-4-5] חובה לאפשר לאפליקציות בפרופיל הנוסף שיש להן פעילות של מרכז האפליקציות לגשת לאנשי קשר שכבר נגישים לפרופיל המשתמש הראשי.

אם הטמעות של מכשירים יוצרות את פרופיל המשתמש הנוסף שצוין למעלה, הן כוללות לפחות מצלמה אחת, ואפליקציית המצלמה המובנית מטפלת ב-Intent‏ MediaStore.ACTION_MOTION_PHOTO_CAPTURE או MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE, הן:

‫[C-5-1] חובה לאפשר לאפליקציות של המשתמש הראשי לטפל בכוונות האלה שמקורן בפרופיל המשתמש הנוסף.

‫9.6. אזהרה לגבי SMS פרימיום

מערכת Android כוללת תמיכה באזהרת משתמשים מפני כל הודעת SMS פרימיום שהם שולחים. הודעות SMS פרימיום הן הודעות טקסט שנשלחות לשירות שרשום אצל ספק, ויכול להיות שהמשתמש יחויב עליהן.

אם הטמעות במכשיר מצהירות על תמיכה ב-android.hardware.telephony: הן:

‫[C-1-1] חובה להציג למשתמשים אזהרה לפני שליחת הודעת SMS למספרים שזוהו על ידי ביטויים רגולריים שמוגדרים בקובץ /data/misc/sms/codes.xml במכשיר. פרויקט הקוד הפתוח של Android מספק הטמעה שעומדת בדרישה הזו.

‫9.7. אמצעי אבטחה

ההטמעות של המכשירים חייבות לעמוד בדרישות של תכונות האבטחה גם בגרעין וגם בפלטפורמה, כפי שמתואר בהמשך.

ארגז החול של Android כולל תכונות שמשתמשות במערכת בקרת הגישה (MAC) של Linux עם אבטחה משופרת (SELinux), בארגז חול של seccomp ובתכונות אבטחה אחרות בליבת Linux. הטמעות במכשיר:

‫[C-0-1] חובה לשמור על תאימות לאפליקציות קיימות, גם כשמטמיעים את SELinux או תכונות אבטחה אחרות מתחת למסגרת Android.
‫[C-0-2] אסור להציג ממשק משתמש גלוי כשזוהה הפרת אבטחה ונחסמה בהצלחה על ידי תכונת האבטחה שהוטמעה מתחת למסגרת Android, אבל מותר להציג ממשק משתמש גלוי כשמתרחשת הפרת אבטחה שלא נחסמה ומובילה לניצול לרעה מוצלח.
‫[C-0-3] אסור לאפשר למשתמש או למפתח האפליקציה להגדיר את SELinux או תכונות אבטחה אחרות שהוטמעו מתחת למסגרת Android.
‫[C-0-4] אסור לאפשר לאפליקציה שיכולה להשפיע על אפליקציה אחרת באמצעות API (כמו Device Administration API) להגדיר מדיניות שפוגעת בתאימות.
‫[C-0-5] חובה לפצל את מסגרת המדיה למספר תהליכים, כדי לאפשר הענקת גישה מצומצמת יותר לכל תהליך, כפי שמתואר באתר של פרויקט הקוד הפתוח של Android.
‫[C-0-6] חובה להטמיע מנגנון ארגז חול לאפליקציות של ליבת המערכת, שמאפשר סינון של קריאות למערכת באמצעות מדיניות שניתנת להגדרה מתוכניות מרובות-הליכים. פרויקט הקוד הפתוח של Android (AOSP) עומד בדרישה הזו באמצעות הפעלת seccomp-BPF עם סנכרון של קבוצת השרשורים (TSYNC), כפי שמתואר בקטע Kernel Configuration (הגדרת ליבת המערכת) ב-source.android.com.

תכונות שלמות הליבה והגנה עצמית הן חלק בלתי נפרד מאבטחת Android. הטמעות במכשיר:

‫[C-0-7] חובה להטמיע מנגנונים להגנה מפני גלישת חוצץ במחסנית של הליבה. דוגמאות למנגנונים כאלה הן CC_STACKPROTECTOR_REGULAR ו-CONFIG_CC_STACKPROTECTOR_STRONG.
‫[C-0-8] חובה להטמיע אמצעי הגנה מחמירים על זיכרון הליבה, שבהם קוד הפעלה הוא לקריאה בלבד, נתונים לקריאה בלבד הם לא ניתנים להפעלה ולא לכתיבה, ונתונים שניתנים לכתיבה הם לא ניתנים להפעלה (לדוגמה, גם rodata וגם CONFIG_STRICT_KERNEL_RWX מופעלים).
‫[C-0-9] חובה להטמיע בדיקה סטטית ודינמית של גבולות גודל האובייקט של עותקים בין מרחב המשתמש לבין מרחב הליבה (לדוגמה, CONFIG_HARDENED_USERCOPY) במכשירים שנשלחים במקור עם רמת API‏ 28 ומעלה.
[C-0-10] אסור להפעיל זיכרון במרחב המשתמשים כשמבצעים פעולה במצב ליבה (למשל, PXN של חומרה או אמולציה באמצעות CONFIG_CPU_SW_DOMAIN_PAN או CONFIG_ARM64_SW_TTBR0_PAN) במכשירים שנשלחו במקור עם רמת API 28 ומעלה.
‫[C-0-11] אסור לקרוא או לכתוב בזיכרון של מרחב המשתמשים בקרנל מחוץ לממשקי API רגילים של גישת usercopy (למשל, PAN של חומרה או אמולציה באמצעות CONFIG_CPU_SW_DOMAIN_PAN או CONFIG_ARM64_SW_TTBR0_PAN) במכשירים שנשלחים במקור עם רמת API‏ 28 ומעלה.
[C-0-12] חובה להטמיע בידוד של טבלת דפי ליבה אם החומרה פגיעה ב-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).
‫[C-SR-1] מומלץ מאוד לשמור על נתוני ליבה שנכתבים רק במהלך האתחול, ולסמן אותם כקריאה בלבד אחרי האתחול (לדוגמה, __ro_after_init).
‫[C-SR-2] מומלץ מאוד לבצע רנדומיזציה של הפריסה של קוד הליבה והזיכרון, ולהימנע מחשיפות שיפגעו ברנדומיזציה (לדוגמה, CONFIG_RANDOMIZE_BASE עם אנטרופיה של טוען האתחול באמצעות /chosen/kaslr-seed Device Tree node או EFI_RNG_PROTOCOL).
‫[C-SR-3] מומלץ מאוד להפעיל את התכונה 'שלמות זרימת הבקרה' (CFI) בגרעין כדי לספק הגנה נוספת מפני התקפות של שימוש חוזר בקוד (לדוגמה, CONFIG_CFI_CLANG ו-CONFIG_SHADOW_CALL_STACK).
‫[C-SR-4] מומלץ מאוד לא להשבית את התכונות Control-Flow Integrity‏ (CFI), ‏ Shadow Call Stack‏ (SCS) או Integer Overflow Sanitization‏ (IntSan) ברכיבים שהתכונות האלה מופעלות בהם.
‫[C-SR-5] מומלץ מאוד להפעיל CFI, ‏ SCS ו-IntSan לכל רכיב נוסף במרחב המשתמשים שרגיש לאבטחה, כפי שמוסבר במאמרים בנושא CFI ו-IntSan.
‫[C-SR-6] מומלץ מאוד להפעיל אתחול של המחסנית בקרנל כדי למנוע שימוש במשתנים מקומיים שלא אותחלו (CONFIG_INIT_STACK_ALL או CONFIG_INIT_STACK_ALL_ZERO). בנוסף, הטמעות של מכשירים לא צריכות להניח את הערך שבו הקומפיילר משתמש כדי לאתחל את המשתנים המקומיים.
[C-SR-7] מומלץ מאוד להפעיל אתחול של heap בקרנל כדי למנוע שימוש בהקצאות של heap שלא אותחלו (CONFIG_INIT_ON_ALLOC_DEFAULT_ON), ואסור להניח את הערך שבו הקרנל משתמש כדי לאתחל את ההקצאות האלה.

אם הטמעות של מכשירים משתמשות בקרנל Linux שיכול לתמוך ב-SELinux, הן:

‫[C-1-1] חובה להטמיע SELinux.
‫[C-1-2] חובה להגדיר את SELinux למצב אכיפה גלובלי.
‫[C-1-3] חובה להגדיר את כל הדומיינים במצב אכיפה. אסור להשתמש בדומיינים במצב הרשאה, כולל דומיינים שספציפיים למכשיר או לספק.

‫[C-1-4] אסור:
- לשנות, להשמיט או להחליף את כללי neverallow שנמצאים בתיקייה system/sepolicy שסופקה בפרויקט Android Open Source Project (AOSP)‎.
- הפעלת תהליכים שאינם AOSP (כמו שירותים ספציפיים לספקים או ל-ODM) בדומיינים של AOSP SELinux (דומיינים שמכילים את המאפיין coredomain).
- מתייגים קבצים או ספריות שאינם AOSP (כמו אלה שנמצאים במחיצות /vendor או /odm) עם סוגי SELinux ספציפיים לפלטפורמת AOSP (סוגים שחסרים בהם המאפיינים vendor_file_type או odm_file_type).
- הקצאת הקשרים של מאפיינים שמוגדרים ב-AOSP למאפייני מערכת ספציפיים לספקים או ל-ODM.
המדיניות חייבת להתקמפל עם כל כללי neverallow שקיימים, גם עבור דומיינים של AOSP SELinux וגם עבור דומיינים ספציפיים למכשיר או לספק.

‫[C-1-5] חובה להריץ אפליקציות של צד שלישי שמטרגטות את רמת API‏ 28 ומעלה בארגזי חול של SELinux לכל אפליקציה, עם הגבלות SELinux לכל אפליקציה בספריית הנתונים הפרטית של כל אפליקציה.
מומלץ לשמור על מדיניות SELinux שמוגדרת כברירת מחדל בתיקייה system/sepolicy של פרויקט הקוד הפתוח של Android (AOSP), ולהוסיף למדיניות הזו רק את ההגדרות הספציפיות למכשיר.

אם ההטמעות במכשיר משתמשות בקרנל שאינו Linux או ב-Linux ללא SELinux, הן:

‫[C-2-1] חובה להשתמש במערכת בקרת גישה מחייבת ששווה ל-SELinux.

אם הטמעות של מכשירים משתמשות במכשירי קלט/פלט עם יכולת DMA, הן:

‫[C-SR-9] מומלץ מאוד לבודד כל מכשיר קלט/פלט שיכול לבצע DMA, באמצעות IOMMU (לדוגמה, ARM SMMU).

‫Android כולל כמה תכונות הגנה לעומק שהן חלק בלתי נפרד מאבטחת המכשיר. בנוסף, מערכת Android מתמקדת בהפחתת באגים נפוצים מסוגים מרכזיים שפוגעים באיכות ובאבטחה.

כדי לצמצם את הסיכויים לבאגים בזיכרון, הטמעות של מכשירים:

[C-SR-10] מומלץ מאוד לבדוק באמצעות כלים לזיהוי שגיאות בזיכרון במרחב המשתמש, כמו MTE למכשירי ARMv9,‏ HWASan למכשירי ARMv8+‎ או ASan לסוגים אחרים של מכשירים.
[C-SR-11] מומלץ מאוד לבדוק באמצעות כלים לזיהוי שגיאות בזיכרון הליבה, כמו KASAN (CONFIG_KASAN,‏ CONFIG_KASAN_HW_TAGS למכשירי ARMv9,‏ CONFIG_KASAN_SW_TAGS למכשירי ARMv8 או CONFIG_KASAN_GENERIC לסוגי מכשירים אחרים).
‫[C-SR-12] מומלץ מאוד להשתמש בכלים לזיהוי שגיאות זיכרון בסביבת ייצור, כמו MTE,‏ GWP-ASan ו-KFENCE.

אם הטמעות המכשירים משתמשות ב-TEE שמבוסס על Arm TrustZone, הן:

‫[C-SR-13] מומלץ מאוד להשתמש בפרוטוקול סטנדרטי לשיתוף זיכרון בין Android לבין TEE, כמו Arm Firmware Framework for Armv8-A ‏ (FF-A).
‫[C-SR-14] מומלץ מאוד להגביל את הגישה של אפליקציות מהימנות רק לזיכרון ששותף איתן באופן מפורש באמצעות הפרוטוקול שלמעלה. אם המכשיר תומך ברמת החריגה Arm S-EL2, מנהל המחיצות המאובטח צריך לאכוף את ההגדרה הזו. אחרת, מערכת ההפעלה של TEE צריכה לאכוף את זה.

טכנולוגיה לבטיחות הזיכרון היא טכנולוגיה שמצמצמת לפחות את הסוגים הבאים של באגים בסבירות גבוהה (מעל 90%) באפליקציות שמשתמשות באפשרות המניפסט android:memtagMode:

גלישת חוצץ בזיכרון הערימה
שימוש אחרי תקופת הניסיון
double free
wild free (free of a non-malloc pointer)

הטמעות במכשיר:

‫[C-SR-15] מומלץ מאוד להגדיר את הערך ro.arm64.memtag.bootctl_supported.

אם הטמעות של מכשירים מגדירות את מאפיין המערכת ro.arm64.memtag.bootctl_supported כ-True, הן:

‫[C-3-1] המערכת חייבת לאפשר לנכס arm64.memtag.bootctl לקבל רשימה של הערכים הבאים שמופרדים באמצעות פסיקים, ולהחיל את האפקט הרצוי בהפעלה מחדש הבאה:
- ‫memtag: מופעלת טכנולוגיה לשמירה על בטיחות הזיכרון, כפי שמוגדר למעלה
- ‫memtag-once: טכנולוגיה לשמירה על בטיחות הזיכרון כפי שהוגדרה למעלה מופעלת באופן זמני, ומושבתת אוטומטית לאחר האתחול הבא
- ‫memtag-off: טכנולוגיה לשמירה על בטיחות הזיכרון כפי שהוגדרה למעלה מושבתת
‫[C-3-2] חובה לאפשר למשתמש במעטפת להגדיר את arm64.memtag.bootctl.
‫[C-3-3] חובה לאפשר לכל תהליך לקרוא את arm64.memtag.bootctl.
‫[C-3-4] חובה להגדיר את arm64.memtag.bootctl למצב המבוקש הנוכחי בהפעלה, וחובה גם לעדכן את המאפיין, אם הטמעת המכשיר מאפשרת לשנות את המצב בלי לשנות את מאפיין המערכת.
‫[C-SR-16] מומלץ מאוד להציג הגדרת מפתח שקובעת memtag-once ומפעילה מחדש את המכשיר. עם טוען אתחול תואם, פרויקט קוד פתוח של Android עומד בדרישות שלמעלה באמצעות פרוטוקול טוען האתחול MTE.

אם מכשיר מסוים מצהיר על android.hardware.telephony, תומך ביכולת הרדיו CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK וכולל מודם סלולרי שתומך בחיבורי 2G, ההטמעה של המכשיר:

[C-SR-17] מומלץ מאוד לספק למשתמשים אפשרות להשבית ולהפעיל את רשת ה-2G.
‫[C-SR-18] מומלץ מאוד לא לבטל את האפשרות של המשתמש להשבית ולהפעיל את רשת 2G דרך ישות מכשיר אחרת, אלא רק דרך אדמין של המכשיר באמצעות UserManager.DISALLOW_CELLULAR_2G.
‫[C-SR-19] מומלץ מאוד להתקשר אל TelephonyManager.setAllowedNetworkTypesForReason עם הסיבה ALLOWED_NETWORK_TYPES_REASON_ENABLE_2G כדי לעמוד בדרישה הזו.
‫[C-SR-20] מומלץ מאוד לקבוע את התמיכה במודם סלולרי ב-2G באמצעות התקשרות אל TelephonyManager.getSupportedRadioAccessFamily. פרטים נוספים מופיעים במאמר בנושא השבתת רשת 2G.

‫9.8. פרטיות

‫9.8.1. היסטוריית השימוש

‫Android שומרת את היסטוריית הבחירות של המשתמש ומנהלת את ההיסטוריה הזו באמצעות UsageStatsManager.

הטמעות במכשיר:

‫[C-0-1] חובה לשמור על תקופת שמירה סבירה של היסטוריית המשתמשים.
‫[C-SR-1] מומלץ מאוד לשמור על תקופת השמירה של 14 ימים כפי שהוגדרה כברירת מחדל בהטמעה של AOSP.

מערכת Android מאחסנת את אירועי המערכת באמצעות המזהים StatsLog, ומנהלת את ההיסטוריה הזו באמצעות StatsManager ו-IncidentManager System API.

הטמעות במכשיר:

‫[C-0-2] צריך לכלול רק את השדות שמסומנים ב-DEST_AUTOMATIC בדוח האירוע שנוצר על ידי מחלקת System API‏ IncidentManager.
‫[C-0-3] אסור להשתמש במזהי אירועים של המערכת כדי לרשום ביומן אירועים אחרים, מלבד אלה שמתוארים במסמכי ה-SDK‏ StatsLog. אם נרשמים ביומן אירועים נוספים של המערכת, יכול להיות שהם ישתמשו במזהה אטום אחר בטווח שבין 100,000 ל-200,000.

‫9.8.2. מתבצעת הקלטה

הטמעות במכשיר:

‫[C-0-1] אסור לטעון מראש או להפיץ רכיבי תוכנה מוכנים לשימוש ששולחים את המידע הפרטי של המשתמש (לדוגמה, הקשות על המקשים, טקסט שמוצג במסך, דוח באגים) מהמכשיר בלי הסכמת המשתמש או בלי התראות ברורות ומתמשכות.
‫[C-0-2] חובה להציג אזהרה למשתמש ולקבל ממנו הסכמה מפורשת שמאפשרת לתעד מידע רגיש שמוצג במסך שלו בכל פעם שמפעילים הפעלת Cast של המסך או הקלטת המסך באמצעות MediaProjection.createVirtualDisplay() או ממשקי API קנייניים.
‫[C-0-3] חובה להציג למשתמש התראה מתמשכת בזמן שהפעלתם שיקוף מסך או הקלטת מסך. מערכת AOSP עומדת בדרישה הזו באמצעות הצגת סמל של התראה מתמשכת בשורת הסטטוס.
‫[C-SR-1] מומלץ מאוד להציג אזהרה למשתמשים שהיא בדיוק אותה הודעה שמוטמעת ב-AOSP, אבל אפשר לשנות אותה כל עוד ההודעה מזהירה את המשתמש בצורה ברורה שכל מידע רגיש במסך שלו מצולם.
‫[C-0-4] הדרישה הוסרה ב-Android 16.

הטמעות במכשיר:

‫[C-0-7] אסור להקליט, להקרין או להפעיל Cast של מידע רגיש, כמו:
- תוכן רגיש בהתראה שמופיע בקטע 3.8.3.4 הגנה על התראות עם תוכן רגיש
- חלונות של פעילות באפליקציות שמכילים סיסמאות חד-פעמיות
- תוכן רגיש כמו שם משתמש, סיסמה ופרטי כרטיס אשראי

אם הטמעות במכשיר כוללות פונקציונליות במערכת שמאפשרת לצלם את התוכן שמוצג במסך ו/או להקליט את זרם האודיו שמופעל במכשיר שלא באמצעות System API ContentCaptureService, או באמצעים קנייניים אחרים שמתוארים בסעיף 9.8.6 נתונים ברמת מערכת ההפעלה ונתונים סביבתיים, הן:

‫[C-1-1] חובה להציג למשתמש התראה מתמשכת בכל פעם שהפונקציונליות הזו מופעלת ומבצעת צילום או הקלטה באופן פעיל.

אם הטמעות של מכשירים כוללות רכיב שמופעל מחוץ לקופסה, שיכול להקליט אודיו מהסביבה ו/או להקליט את האודיו שמושמע במכשיר כדי להסיק מידע שימושי על ההקשר של המשתמש, הן:

[C-2-1] אסור לאחסן באחסון קבוע במכשיר או לשדר מהמכשיר את האודיו הגולמי שהוקלט או כל פורמט שאפשר להמיר בחזרה לאודיו המקורי או לגרסה כמעט זהה שלו, אלא אם יש הסכמה מהמשתמש מפורשת.

"אינדיקטור למיקרופון" הוא תצוגה במסך שמוצגת למשתמש באופן קבוע ואי אפשר להסתיר אותה. המשתמש מבין שהמיקרופון נמצא בשימוש(באמצעות טקסט, צבע, סמל ייחודיים או שילוב כלשהו שלהם).

'אינדיקטור גישה למצלמה' מתייחס לתצוגה במסך, שגלוי כל הזמן למשתמש ואי אפשר להסתיר אותו, והמשתמש מבין שהמצלמה נמצאת בשימוש (באמצעות טקסט, צבע, סמל ייחודיים או שילוב כלשהו).

אחרי השנייה הראשונה שבה מוצג האינדיקטור, הוא יכול להשתנות מבחינה ויזואלית, למשל להפוך לקטן יותר, והוא לא חייב להופיע כמו שהוא הופיע בהתחלה.

יכול להיות שאינדיקטור המיקרופון ימוזג עם אינדיקטור המצלמה שמוצג באופן פעיל, בתנאי שמשתמשים בטקסט, בסמלים או בצבעים כדי לציין למשתמש שהשימוש במיקרופון התחיל.

יכול להיות שאינדיקטור גישה למצלמה יאוחד עם אינדיקטור המיקרופון שמוצג באופן פעיל, בתנאי שהטקסט, הסמלים או הצבעים מציינים למשתמש שהשימוש במצלמה התחיל.

אם הטמעות של מכשירים מצהירות על android.hardware.microphone, הן:

‫[C-SR-1] מומלץ מאוד להציג אינדיקטור למיקרופון כשלאפליקציה יש גישה לנתוני אודיו מהמיקרופון, אבל לא כשלאפליקציות HotwordDetectionService,‏ SOURCE_HOTWORD,‏ ContentCaptureService או לאפליקציות שמחזיקות בתפקידים שמפורטים בסעיף 9.1 הרשאות עם מזהה CDD‏ [C-3-X] יש גישה למיקרופון.
‫[C-SR-2] מומלץ מאוד להציג את רשימת האפליקציות האחרונות והפעילות שמשתמשות במיקרופון, כפי שמוחזרות מ-PermissionManager.getIndicatorAppOpUsageData(), יחד עם הודעות השיוך שקשורות אליהן.
‫[C-SR-3] מומלץ מאוד לא להסתיר את חיווי המיקרופון באפליקציות מערכת שיש להן ממשקי משתמש גלויים או אינטראקציה ישירה עם המשתמש.

אם הטמעות של מכשירים מצהירות על android.hardware.camera.any, הן:

[C-SR-4] מומלץ מאוד להציג אינדיקטור גישה למצלמה כשמגיעים לנתונים חיים מהמצלמה באפליקציה, אבל לא כשמגיעים למצלמה רק מאפליקציות שמחזיקות בתפקידים שמוזכרים בסעיף 9.1 הרשאות עם מזהה CDD [C-3-X].
‫[C-SR-5] מומלץ מאוד להציג את האפליקציות האחרונות והפעילות באמצעות מצלמה שמוחזרת מ-PermissionManager.getIndicatorAppOpUsageData(), יחד עם הודעות שיוך שקשורות אליהן.
[C-SR-6] מומלץ מאוד לא להסתיר את אינדיקטור גישה למצלמה באפליקציות מערכת שיש להן ממשקי משתמש גלויים או אינטראקציית משתמש ישירה.

‫9.8.3. קישוריות

אם הטמעות המכשירים כוללות יציאת USB עם תמיכה במצב ציוד היקפי של USB, הן:

‫[C-1-1] חובה להציג ממשק משתמש שמבקש את הסכמת המשתמש לפני שמאפשרים גישה לתוכן של האחסון המשותף דרך יציאת ה-USB.

‫9.8.4. תנועה ברשת

הטמעות במכשיר:

‫[C-0-1] חובה להתקין מראש את אותם אישורי בסיס למאגר רשות האישורים (CA) שהמערכת סומכת עליהם כפי שסופקו בפרויקט הקוד הפתוח של Android.
‫[C-0-2] חובה לשלוח עם מאגר ריק של רשויות אישורים (CA) בסיסיות של משתמשים.
‫[C-0-3] חובה להציג למשתמש אזהרה שמציינת שאולי מתבצע מעקב אחרי תעבורת הרשת, כשמוסיפים רשות אישורים (CA) בסיסית של משתמש.

אם התנועה במכשיר מנותבת דרך VPN, ההטמעות במכשיר:

‫[C-1-1] חובה להציג למשתמש אזהרה שמציינת את אחת מהאפשרויות הבאות:
- יכול להיות שהתנועה ברשת תנוטר.
- התנועה ברשת מנותבת דרך אפליקציית ה-VPN הספציפית שמספקת את ה-VPN.

אם הטמעות של מכשירים כוללות מנגנון שמופעל כברירת מחדל ומוכן לשימוש, שמנתב את תנועת הנתונים ברשת דרך שרת proxy או שער VPN (לדוגמה, טעינה מראש של שירות VPN עם הרשאה android.permission.CONTROL_VPN), הן:

‫[C-2-1] חובה לבקש את הסכמת המשתמש לפני הפעלת המנגנון הזה, אלא אם ה-VPN מופעל על ידי Device Policy Controller באמצעות DevicePolicyManager.setAlwaysOnVpnPackage(). במקרה כזה, המשתמש לא צריך לספק הסכמה נפרדת, אבל חובה להודיע לו על כך.

אם הטמעות במכשירים מטמיעות אמצעי נוחות למשתמש כדי להפעיל את הפונקציה 'חיבור קבוע ל-VPN' של אפליקציית VPN של צד שלישי, הן:

‫[C-3-1] חובה להשבית את האפשרות הזו למשתמשים באפליקציות שלא תומכות בשירות VPN שפועל כל הזמן בקובץ AndroidManifest.xml באמצעות הגדרת המאפיין SERVICE_META_DATA_SUPPORTS_ALWAYS_ON לערך false.

‫9.8.5. מזהי המכשיר

הטמעות במכשיר:

[C-0-1] חובה למנוע מאפליקציה גישה למספר הסידורי של המכשיר, ולמספר ה-IMEI/MEID, למספר הסידורי של כרטיס ה-SIM ולמספר ה-IMSI (International Mobile Subscriber Identity), אלא אם האפליקציה עומדת באחת מהדרישות הבאות:
- היא אפליקציה חתומה של ספק סלולר שאומתה על ידי יצרני מכשירים.
- קיבל את ההרשאה READ_PRIVILEGED_PHONE_STATE.
- יש לו הרשאות ספק כפי שמוגדרות במאמר הרשאות ספק ב-UICC.
- הוא בעל מכשיר או בעל פרופיל שקיבל את ההרשאה READ_PHONE_STATE.
- (למספר סידורי של כרטיס SIM או ל-ICCID בלבד) האפליקציה נדרשת לזהות שינויים בזהות המנוי בהתאם לדרישות התקנות המקומיות.

‫9.8.6. מגן נתונים ברמת מערכת ההפעלה ונתונים סביבתיים

מערכת Android, באמצעות ממשקי ה-API של המערכת, תומכת במנגנון להטמעות של מכשירים כדי לתעד את הנתונים הרגישים הבאים:

טקסט וגרפיקה שמוצגים במסך, כולל, בין היתר, התראות ונתוני עזרה באמצעות AssistStructure API, פעילויות של לכידת מאגר מסך והקלטה של תוכן המסך של המכשיר.
נתוני מדיה, כמו אודיו או סרטון, שהוקלטו או הופעלו במכשיר.
אירועי קלט (למשל: מקלדת, עכבר, תנועה, קול, וידאו ונגישות).
כל מסך או נתונים אחרים שנשלחים דרך AugmentedAutofillService למערכת.
כל מסך או נתונים אחרים שאפשר לגשת אליהם באמצעות ממשקי API של Content Capture.
כל נתוני האפליקציה שמועברים למערכת דרך AppSearchManager API ושאפשר לגשת אליהם דרך AppSearchGlobalManager.query.
כל טקסט או נתונים אחרים שנשלחים דרך TextClassifier API אל TextClassifier של המערכת, כלומר אל שירות המערכת, כדי להבין את המשמעות של הטקסט, וגם כדי ליצור פעולות צפויות הבאות על סמך הטקסט.
נתונים שעברו אינדוקס על ידי הטמעת הפלטפורמה AppSearch, כולל, בין היתר, טקסט, גרפיקה, נתוני מדיה או נתונים דומים אחרים.
נתוני אודיו שהתקבלו כתוצאה משימוש ב-SpeechRecognizer#onDeviceSpeechRecognizer() על ידי Speech Recognizer Implementation (הטמעה של זיהוי דיבור).
נתוני אודיו שמתקבלים ברקע (באופן רציף) דרך AudioRecord, SoundTrigger או ממשקי API אחרים של אודיו, ולא מוצגים למשתמשים
נתוני מצלמה שהתקבלו ברקע (באופן רציף) דרך CameraManager או ממשקי API אחרים של מצלמה, ולא מוצג למשתמש אינדיקטור

כל הנתונים שתועדו על ידי DynamicInstrumentationEventService

אם הטמעות במכשירים מתעדות או משתפות נתונים רגישים מהסוגים שמפורטים למעלה, הן: ללא כוונת המשתמש ברורה, נפרדת או אינדיקטור פרטיות שגלוי למשתמש, הנתונים חייבים לעבור עיבוד בסביבת ביצוע מוגנת. בסביבה הזו:

‫[C-1-1] חובה להצפין את כל הנתונים האלה כשהם מאוחסנים במכשיר או בזמן ההעברה. ההצפנה הזו יכולה להתבצע באמצעות הצפנה מבוססת-קובץ ב-Android, או באמצעות כל אחת מההצפנות שמופיעות כגרסה 26 ומעלה של API, כפי שמתואר ב-Cipher SDK.
‫[C-1-2] אסור לגבות נתונים גולמיים או נתונים מוצפנים באמצעות שיטות גיבוי ל-Android או שיטות גיבוי אחרות של מידע אישי רגיש, כפי שמתואר למעלה.

‫[C-1-3] אסור לשלוח נתונים כאלה אל מחוץ למכשיר, אלא אם מתקיים אחד מהתנאים הבאים:
- כשמשתמש מביע כוונה מפורשת ^* לבצע את החישוב הספציפי בכל פעם שהנתונים משותפים.
- כשמשתמשים במנגנון לשמירה על הפרטיות, כמו פרטיות דיפרנציאלית, טכנולוגיות כמו RAPPOR או חישובים פדרטיביים סודיים.
- כשנתונים מעובדים בסביבת ביצוע מוגנת שמגנה עליהם מפני ספק השירות והתשתית, למשל ללא הרשאת אדמין, Confidential VMs, אימות (attestation) מרחוק, ללא תעבורת נתונים יוצאת (egress) של נתונים פרטיים, רישום ביומן מושבת, הסתרת כתובת IP והצפנה.
  - כל הטמעה שמשתמשת בשיטה הזו חייבת לספק למשתמשים אפשרות לבטל את ההסכמה.

‫[C-1-3] יכולה לעבד נתונים באמצעות סביבת ענן מהימנה של מחשוב בסיסי, שמגנה עליהם מפני ספק השירות והתשתית (למשל, ללא גישת אדמין, Confidential VMs, אימות (attestation) מרחוק, ללא תעבורת נתונים יוצאת (egress) של נתונים פרטיים, השבתת רישום ביומן, הסתרת כתובת IP והצפנה). כל הטמעה שמתבצעת באמצעות השיטה הזו:
- חובה לספק למשתמשים אפשרות לביטול ההסכמה, וגם
- חובה לספק למשתמשים שיטה ליצירת יומנים מקיפים ונגישים שמפרטים את תעבורת הנתונים הנכנסת (ingress) ותעבורת הנתונים היוצאת (egress) מהסביבה.

[C-1-4] אסור לשייך נתונים כאלה לזהות של משתמש כלשהו (למשל Account) במכשיר, אלא אם יש הסכמה מהמשתמש מפורשת בכל פעם שהנתונים משויכים.

‫[C-1-4] עשוי להציג את הנתונים האלה בממשקי משתמש בבעלות המערכת.

‫[C-1-5] אסור לשתף לשייך נתונים כאלה לזהות של משתמש כלשהו (למשל Account), אלא אם יש הסכמה מפורשת של המשתמש בכל פעם שהנתונים משותפים בכל פעם שהנתונים משויכים, אחרת השיוך לא יועבר לרכיבים אחרים של מערכת ההפעלה שלא עומדים בדרישות שמפורטות בקטע הנוכחי (9.8.6 נתונים ברמת מערכת ההפעלה ונתונים סביבתיים), בכל פעם שהנתונים משותפים. אלא אם הפונקציונליות הזו מובנית כממשק API של Android SDK‏ (AmbientContext,‏ HotwordDetectionService).
‫[C-1-6] חובה לספק למשתמש אפשרות למחיקת נתונים כאלה שנאספים על ידי ההטמעה או באמצעים הקנייניים, כשהנתונים מאוחסנים בכל צורה שהיא במכשיר או בסביבת הענן של בסיס המחשוב המהימן. אם המשתמש בוחר למחוק את הנתונים, חובה להסיר את כל הנתונים ההיסטוריים שנאספו.

‫[C-1-7] חובה לספק למשתמשים אפשרות לבטל את ההסכמה להצגת הנתונים שנאספו באמצעות AppSearch או באמצעים קנייניים בפלטפורמת Android (למשל, במפעיל האפליקציות).

[C-1-8] חובה לספק שיטה ליצירת יומנים מקיפים ונגישים שמפרטים את תעבורת הנתונים הנכנסת (ingress) והיוצאת (egress) מהסביבה.
‫[C-1-9] אסור שתהיה גישה ישירה לאינטרנט.
‫[C-1-10] יכול להציג ממשק משתמש מרחוק, כל עוד לא מוצגים נתונים לאפליקציית ה-APK של המארח שמציגה את ממשק המשתמש.
‫[C-1-11] חובה להפריד בין השירותים לבין רכיבים אחרים במערכת (לדוגמה, לא לקשר את השירות או לשתף מזהי תהליכים עם יישומים שלא נמצאים בסביבת הביצוע המוגנת).
‫[C-1-12] חובה לאפשר יציאה של מידע אישי רגיש רק במקרים הבאים:
- המשתמש יזם את הפעולה באופן מפורש* לצורך החישוב הספציפי בכל פעם שהנתונים משותפים; או
- שימוש במנגנון לשמירה על הפרטיות (למשל, טכנולוגיות של פרטיות דיפרנציאלית כמו RAPPOR / חישובים מאוחדים סודיים).
‫[C-1-13] חובה לאפשר זליגה של מידע אישי רגיש רק דרך:
- שירות מערכת שנכלל ברשימת ההיתרים של שירות המערכת PCCSandbox ועומד בדרישות של סביבת ביצוע מוגנת (9.8.6), או
- קובץ APK ייעודי של שער Private Compute Core ‏ (PCC) (מוגדר בסעיף 9.8.15).
‫[C-1-14] אסור לבצע גיבויים בענן של נתונים שהוסקו מנתונים רגישים, אלא אם הם מוצפנים מקצה לקצה (לדוגמה, באמצעות שירות הגיבוי של Android).

‫[C-SR-1] מומלץ מאוד לא לבקש את ההרשאה INTERNET.
‫[C-SR-2] מומלץ מאוד לגשת לאינטרנט רק דרך ממשקי API מובנים שמגובים על ידי הטמעות קוד פתוח שזמינות לציבור.
‫[C-SR-4] מומלץ מאוד להטמיע אותם באמצעות Android SDK API או מאגר קוד פתוח דומה בבעלות יצרן ציוד מקורי (OEM), ו / או לבצע אותם בהטמעה בתוך ארגז חול (ראו 9.8.15 הטמעות של API בארגז חול).

אם הטמעות במכשירים כוללות שירות שמטמיע את System API‏ ContentCaptureService, AppSearchManager.index, DynamicInstrumentationEventService או כל שירות קנייני אחר שמתעד את הנתונים כפי שמתואר למעלה, הן:

‫[C-2-1] אסור לאפשר למשתמשים להחליף את השירותים באפליקציה או בשירות שאפשר להתקין, ומותר רק לשירותים שהותקנו מראש לאסוף נתונים כאלה.
‫[C-2-2] אסור לאפשר לאפליקציות אחרות, מלבד מנגנון השירותים שהותקנו מראש, לתעד נתונים כאלה.
‫[C-2-3] חובה לספק למשתמשים אמצעי ברור ונגיש להשבתת השירותים.
‫[C-2-4] אסור להשמיט את האפשרות למשתמשים לנהל הרשאות ל-Android שניתנו לשירותים, וצריך לפעול לפי מודל ההרשאות ל-Android שמתואר בקטע 9.1. הרשאה.

‫[C-SR-3] מומלץ מאוד להפריד את השירותים מרכיבים אחרים במערכת (למשל, לא לקשור את השירות או לשתף מזהי תהליך) למעט המקרים הבאים:
- שיחות טלפון, אנשי קשר, ממשק משתמש של המערכת ומדיה

‫9.8.7. גישה ללוח

הטמעות במכשיר:

‫[C-0-1] אסור להחזיר נתונים חלקיים מהלוח (למשל, באמצעות ClipboardManager API) אלא אם אפליקציית הצד השלישי היא ה-IME שמוגדר כברירת מחדל או האפליקציה שמוצגת כרגע.
‫[C-0-2] חובה לנקות את הנתונים בלוח ההעתקה תוך 60 דקות לכל היותר אחרי שהם הוכנסו ללוח ההעתקה או נקראו ממנו.

‫9.8.8. מיקום

המיקום כולל מידע במחלקה Location של Android( כמו קו רוחב, קו אורך, גובה), וגם מזהים שאפשר להמיר למיקום. המיקום יכול להיות מדויק כמו DGPS (מערכת מיקום גלובלית דיפרנציאלית) או גס כמו מיקומים ברמת המדינה (כמו מיקום קוד המדינה – MCC – קוד המדינה של הנייד).

בהמשך מופיעה רשימה של סוגי מיקומים שמהם אפשר לגזור ישירות את המיקום של המשתמש או להמיר אותם למיקום של המשתמש. זו לא רשימה מקיפה, אבל היא יכולה לשמש כדוגמה למידע שממנו אפשר להסיק את המיקום באופן ישיר או עקיף:

‫GPS/GNSS/DGPS/PPP
- Global Positioning Solution או Global Navigation Satellite System או Differential Global Positioning Solution
- הנתונים האלה כוללים גם מדידות GNSS גולמיות וסטטוס GNSS
  - אפשר לגזור מיקום מדויק ממדידות GNSS גולמיות
טכנולוגיות אלחוטיות עם מזהים ייחודיים, כמו:
- נקודות גישה ל-Wi-Fi (כתובת MAC,‏ BSSID, שם או SSID)
- ‫Bluetooth/BLE (כתובת MAC,‏ BSSID, שם או SSID)
- UWB (MAC, BSSID, Name, or SSID)
- מזהה אנטנה סלולרית (3G,‏ 4G,‏ 5G וכו', כולל כל הטכנולוגיות העתידיות של מודם סלולרי שיש להן מזהים ייחודיים)

כנקודת התייחסות עיקרית, אפשר לעיין בממשקי ה-API של Android שנדרשות להם הרשאות ACCESS_FINE_Location או ACCESS_COARSE_Location.

הטמעות במכשיר:

‫[C-0-1] אסור להפעיל או להשבית את הגדרת המיקום של המכשיר ואת הגדרות הסריקה של Wi-Fi או Bluetooth ללא הסכמה מפורשת של המשתמש או ללא הפעלה על ידי המשתמש.
‫[C-0-2] חובה לספק למשתמש אפשרות גישה למידע שקשור למיקום, כולל בקשות מיקום אחרונות, הרשאות ברמת האפליקציה ושימוש בסריקת Wi-Fi/Bluetooth כדי לקבוע את המיקום.
‫[C-0-3] חובה לוודא שהאפליקציה שמשתמשת ב-Emergency Location Bypass API‏ LocationRequest.setLocationSettingsIgnored() היא הפעלה של מצב חירום שיזם המשתמש (למשל, חיוג ל-911 או שליחת הודעת טקסט ל-911). עם זאת, במערכות לרכב, יכול להיות שכלי רכב יתחיל סשן חירום בלי אינטראקציה פעילה של המשתמש במקרה של זיהוי התנגשות או תאונה (למשל, כדי לעמוד בדרישות של eCall).
‫[C-0-4] חובה לשמור על היכולת של ממשקי ה-API של מעקף המיקום במקרה חירום לעקוף את הגדרות המיקום במכשיר בלי לשנות את ההגדרות.
‫[C-0-5] חובה לתזמן התראה שמזכירה למשתמש שאפליקציה ברקע ניגשה למיקום שלו באמצעות ההרשאה ACCESS_BACKGROUND_LOCATION.

כשאפליקציה שאינה אפליקציית מערכת ופועלת בחזית ניגשת למיקום המדויק של המכשיר, המכשיר:

‫[C-SR-1] מומלץ מאוד להציג אינדיקטור שגלוי למשתמש.

‫9.8.9. אפליקציות מותקנות

אפליקציות ל-Android שמטרגטות לרמת API‏ 30 ומעלה לא יכולות לראות פרטים על אפליקציות אחרות שהותקנו כברירת מחדל (ראו Package visibility במסמכי ה-SDK של Android).

הטמעות במכשיר:

‫[C-0-1] אסור לחשוף לאפליקציה שמטרגטת רמת API‏ 30 ומעלה פרטים על אפליקציה מותקנת אחרת, אלא אם האפליקציה כבר יכולה לראות פרטים על האפליקציה המותקנת האחרת דרך ממשקי ה-API המנוהלים. האיסור הזה כולל, בין היתר, פרטים שנחשפים על ידי ממשקי API מותאמים אישית שנוספו על ידי מפתח המכשיר או שנגישים דרך מערכת הקבצים.
‫[C-0-2] אסור לתת לאפליקציה כלשהי הרשאת קריאה או כתיבה לקבצים בספרייה ייעודית ספציפית לאפליקציה של אפליקציה אחרת באחסון החיצוני. היוצאים מן הכלל היחידים הם:
- הסמכות של ספק שירותי אחסון חיצוני (לדוגמה, אפליקציות כמו DocumentsUI).
- Download Provider (ספק ההורדות) שמשתמש בסמכות הספק 'downloads' כדי להוריד קבצים לאחסון האפליקציה.
- אפליקציות של פרוטוקול העברת מדיה (MTP) שנחתמו על ידי הפלטפורמה ומשתמשות בהרשאת ACCESS_MTP כדי להעביר קבצים למכשיר אחר.
- אפליקציות שמתקינות אפליקציות אחרות ויש להן את ההרשאה INSTALL_PACKAGES יכולות לגשת רק לספריות מסוג obb למטרת ניהול קבצים להרחבת APK.

‫9.8.10. דוח על באג בקישוריות

אם הטמעות של מכשירים מצהירות על דגל התכונה android.hardware.telephony, הן:

‫[C-1-1] חובה לתמוך ביצירת דוחות על באגים בקישוריות באמצעות BUGREPORT_MODE_TELEPHONY עם BugreportManager.
‫[C-1-2] חובה לקבל את הסכמת המשתמש בכל פעם שמשתמשים ב-BUGREPORT_MODE_TELEPHONY כדי ליצור דוח, ואסור להציג למשתמש בקשה להסכמה לכל הבקשות העתידיות מהאפליקציה.
[C-1-3] אסור להחזיר את הדוח שנוצר לאפליקציה ששלחה את הבקשה בלי הסכמה מהמשתמש.
‫[C-1-4] דוחות שנוצרו באמצעות BUGREPORT_MODE_TELEPHONY חייבים לכלול לפחות את המידע הבא:
- TelephonyDebugService dump
- TelephonyRegistry dump
- WifiService dump
- ConnectivityService dump
- קובץ dump של מופע CarrierService של חבילת השיחות (אם הוא מאוגד)
- מאגר נתונים זמני של יומן הרדיו
- SubscriptionManagerService dump
‫[C-1-5] אסור לכלול את הפרטים הבאים בדוחות שנוצרו:
- כל סוג של מידע שלא קשור ישירות לניפוי באגים בקישוריות.
- יומני תנועה או פרופילים מפורטים של אפליקציות או חבילות שהמשתמשים התקינו (מזהי UID הם בסדר, שמות חבילות לא).
יכול לכלול מידע נוסף שלא משויך לזהות משתמש כלשהי. (לדוגמה, יומני ספקים).

אם הטמעות של מכשירים כוללות מידע נוסף (לדוגמה, יומני ספקים) בדוחות על באגים, והמידע הזה משפיע על הפרטיות, האבטחה, הסוללה, האחסון או הזיכרון, הן:

‫[C-SR-1] מומלץ מאוד להגדיר את הגדרת המפתח כהגדרה שמושבתת כברירת מחדל. ההטמעה לדוגמה של AOSP עומדת בדרישה הזו באמצעות האפשרות Enable verbose vendor logging בהגדרות למפתחים, שמאפשרת לכלול בדוחות על באגים יומני ספקים נוספים שספציפיים למכשיר.

‫9.8.11. שיתוף של נתוני Blob

‫Android, באמצעות BlobStoreManager מאפשר לאפליקציות לתרום בלובים של נתונים למערכת כדי לשתף אותם עם קבוצה נבחרת של אפליקציות.

אם ההטמעות במכשיר תומכות ב-blobs של נתונים משותפים כפי שמתואר בתיעוד של ה-SDK, הן:

‫[C-1-1] אסור לשתף נתונים בינאריים ששייכים לאפליקציות מעבר למה שהן התכוונו לאפשר (כלומר, היקף גישת ברירת המחדל ומצבי הגישה האחרים שאפשר לציין באמצעות BlobStoreManager.session#allowPackageAccess(),‏ BlobStoreManager.session#allowSameSignatureAccess() או BlobStoreManager.session#allowPublicAccess() אסור לשנות). הטמעת ההפניה של AOSP עומדת בדרישות האלה.
‫[C-1-2] אסור לשלוח מהמכשיר או לשתף עם אפליקציות אחרות את הגיבובים המאובטחים של בלובים של נתונים (שמשמשים לשליטה בגישה).

‫9.8.12. זיהוי מוזיקה

‫Android, באמצעות System API‏ MusicRecognitionManager, תומך במנגנון להטמעות של מכשירים כדי לבקש זיהוי מוזיקה, בהינתן הקלטת אודיו, ולהעביר את זיהוי המוזיקה לאפליקציה עם הרשאות שמטמיעה את MusicRecognitionService API.

אם הטמעות של מכשירים כוללות שירות שמטמיע את System API‏ MusicRecognitionManager או כל שירות קנייני שמעביר נתוני אודיו בסטרימינג כמו שמתואר למעלה, הן:

‫[C-1-1] חובה לוודא שלמתקשר של MusicRecognitionManager יש את ההרשאה MANAGE_MUSIC_RECOGNITION
‫[C-1-2] חובה לוודא שאפליקציה אחת מותקנת מראש לזיהוי מוזיקה, שמטמיעה את MusicRecognitionService.
‫[C-1-3] אסור לאפשר למשתמשים להחליף את MusicRecognitionManagerService או את MusicRecognitionService באפליקציה או בשירות שאפשר להתקין.
‫[C-1-4] חובה לוודא שכאשר MusicRecognitionManagerService ניגש להקלטת האודיו ומעביר אותה לאפליקציה שמטמיעה את MusicRecognitionService, הגישה לאודיו מתועדת באמצעות הפעלות של AppOpsManager.noteOp / startOp.

אם הטמעות של MusicRecognitionManagerService או של MusicRecognitionService במכשיר שומרות נתוני אודיו שצולמו, הן:

‫[C-2-1] אסור לאחסן קטעי אודיו גולמיים או טביעות אצבע של אודיו בדיסק, או בזיכרון למשך יותר מ-14 ימים.
‫[C-2-2] אסור לשתף נתונים כאלה מחוץ ל-MusicRecognitionService, אלא אם מתקבלת הסכמה מפורשת מהמשתמש בכל פעם שהנתונים משותפים.

‫9.8.13. SensorPrivacyManager

אם הטמעות של מכשירים מספקות למשתמש אמצעי תוכנה להשבתת הקלט מהמצלמה או מהמיקרופון בהטמעת המכשיר, הן:

‫[C-1-1] חובה להחזיר את הערך true באופן מדויק עבור ה-method הרלוונטי של ה-API ‏supportsSensorToggle().
‫[C-1-2] חובה, כשמנסים לגשת למיקרופון או למצלמה חסומים באפליקציה, להציג למשתמש אמצעי נוח לשימוש שלא ניתן לסגירה, שמציין בבירור שהחיישן חסום ודורש בחירה להמשך החסימה או לביטול החסימה, בהתאם להטמעה של AOSP שעומדת בדרישה הזו.
‫[C-1-3] חובה להעביר לאפליקציות רק נתונים ריקים (או מזויפים) של מצלמה ואודיו, ולא לדווח על קוד שגיאה בגלל שהמשתמש לא הפעיל את המצלמה או המיקרופון באמצעות האמצעי שמוצג למשתמש בהתאם ל-‫[C-1-2] שלמעלה.

‫9.8.14. לא רלוונטי

‫9.8.15. הטמעות של Private Compute Core ושל Gateway Application

מערכת Android, באמצעות קבוצה של ממשקי API של נציגים, מספקת מנגנון לעיבוד נתונים מאובטח ברמת מערכת ההפעלה ונתונים סביבתיים. אפשר להעביר את העיבוד הזה לאפליקציית APK שהותקנה מראש עם גישה מיוחדת ויכולות תקשורת מוגבלות, שנקראת הטמעה של API בארגז חול.

מומלץ מאוד להשתמש במסגרת Private Compute Core ‏ (PCC) שמתוארת בהמשך בהטמעות של מכשירים שכוללות אפליקציות שמבצעות במכשיר עיבוד של מידע אישי רגיש שמתואר בקטע 9.8.6 (נתונים ברמת מערכת ההפעלה ונתונים סביבתיים).

רכיבים של הטמעה של Sandboxed API בסביבת PCC:

‫[C-0-1] אסור לבקש את ההרשאה INTERNET.

‫[C-0-1] צריך להיות מוצהר באמצעות מאפיין android:isPrivateComputeCoreProcess="true" בהצהרת המניפסט שלו.

‫[C-0-2] חובה לגשת לאינטרנט רק דרך ממשקי API מובנים שמגובים בהטמעות של קוד פתוח שזמינות לציבור, באמצעות מנגנונים לשמירה על הפרטיות, או באופן עקיף דרך ממשקי API של Android SDK. מנגנון לשמירה על הפרטיות מוגדר כ'מנגנון שמאפשר ניתוח רק ברמת הצבירה ומונע התאמה בין אירועים שנרשמו או תוצאות שהתקבלו לבין משתמשים ספציפיים'. המטרה היא למנוע בדיקה של נתונים ברמת המשתמש (למשל, באמצעות טכנולוגיה של פרטיות דיפרנציאלית כמו RAPPOR).

‫[C-0-2] חובה לטעון מראש בקובץ אימג' של המערכת במכשיר.

‫[C-0-3] חובה להפריד את השירותים מרכיבים אחרים במערכת (למשל, לא לקשר את השירות או לשתף מזהי תהליכים עם הטמעות שלא פועלות כמזהה משתמש של PCC). למעט המקרים הבאים:
- טלפוניה, אנשי קשר, ממשק משתמש של המערכת ומדיה
‫[C-0-4] אסור לאפשר למשתמשים להחליף את השירותים באפליקציה או בשירות שניתנים להתקנה על ידי המשתמש.
‫[C-0-5] חובה לאפשר רק לשירותים שמותקנים מראש שמונו על ידי יצרן הציוד המקורי (מחזיקים בתפקיד מערכת מתאים שמוגדר ב-PCC Manager System Service), ועם הרשאות מתאימות, לתעד נתונים כאלה. אלא אם יכולת ההחלפה מוטמעת ב-AOSP (למשל, באפליקציות של עוזרים דיגיטליים) נתונים סביבתיים רגישים כפי שמתואר בסעיף 9.8.6.
‫[C-0-6] אסור לאפשר לאפליקציות כלשהן, מלבד מנגנון השירותים שהותקנו מראש, לאסוף נתונים כאלה. אלא אם יכולת התיעוד הזו מיושמת באמצעות Android SDK API.
‫[C-0-7] חובה לספק למשתמשים אפשרות להשבית את השירותים.
‫[C-0-8] אסור להשמיט את האפשרות למשתמש לנהל הרשאות ל-Android שניתנו לשירותים, וצריך לפעול לפי מודל ההרשאות ל-Android כפי שמתואר בסעיף 9.1. הרשאה.

‫[C-0-9] חייב לפעול בתהליך ייעודי עם UID ייחודי שהוקצה על ידי המסגרת, בנפרד מתהליך האפליקציה הראשי ומרכיבים אחרים בארגז החול.

כל גישה לרשת שנדרשת לרכיבי סביבת ה-PCC צריכה לעבור דרך שרת proxy באמצעות חבילת APK ייעודית שפועלת כאפליקציית שער PCC. הרכיבים המיועדים:

צריך להעניק ל-‎[C-1-1] את הרשאת הגישה המיוחדת android.permission.PROVIDE_PRIVATE_COMPUTE_SERVICES. ההרשאה הזו מציינת שהאפליקציה היא אפליקציית שער PCC.
‫[C-1-2] קוד המקור שלו חייב להיות זמין לאימות ציבורי.
‫[C-1-3] חובה להשתמש במנגנונים לשמירה על הפרטיות בכל יציאה של נתונים, כפי שמוגדר בסעיף 9.8.6
‫[C-1-4] חובה לתמוך במצב הביקורת של מסגרת ה-PCC, שכולל רישום של בקשות רשת, נקודות קצה של שרתים ונתונים אחרים שרלוונטיים לאימות של התנהגות ששומרת על הפרטיות כשהיא מופעלת

‫9.8.16. נתוני אודיו ומצלמה רציפים

אם הטמעות במכשיר אוספות נתונים כפי שמתואר בקטע 9.8.2 או בקטע 9.8.6, ואם ההטמעות האלה משתמשות בנתוני אודיו שהתקבלו ברקע (באופן רציף) באמצעות AudioRecord, SoundTrigger או ממשקי API אחרים של אודיו, או בנתוני מצלמה שהתקבלו ברקע (באופן רציף) באמצעות CameraManager או ממשקי API אחרים של מצלמה, הן:

‫[C-0-1] חובה להציג אינדיקטור מתאים (מצלמה או מיקרופון, בהתאם לסעיף 9.8.2 בנושא הקלטה), אלא אם:
- הגישה הזו מתבצעת בהטמעה של ארגז חול (ראו 9.8.15 הטמעה של API בארגז חול), דרך חבילה שמחזיקה בתפקיד אחד או יותר מהתפקידים הבאים: ממשק המשתמש של המערכת Intelligence,‏ System Ambient Audio Intelligence,‏ System Audio Intelligence,‏ System Notification Intelligence,‏ System Text Intelligence� או System Visual Intelligence.
- הגישה מתבצעת דרך ארגז חול, שמיושם ונאכף באמצעות מנגנונים ב-AOSP ‏ (HotwordDetectionService,‏ WearableSensingService, ‏ VisualQueryDetector).
- הגישה לאודיו מתבצעת למטרות עזרה על ידי אפליקציית העוזר הדיגיטלי, שמספקת את SOURCE_HOTWORD כמקור אודיו.
- הגישה מתבצעת על ידי המערכת ומיושמת באמצעות קוד פתוח.
‫[C-SR-1] מומלץ מאוד לדרוש הסכמת משתמש לכל פונקציונליות שמשתמשת בנתונים כאלה, ולהשבית את האפשרות הזו כברירת מחדל.
‫[C-SR-2] מומלץ מאוד להחיל את אותם כללים (כלומר, לפעול בהתאם להגבלות שמפורטות בסעיפים 9.8.2 בנושא הקלטה, 9.8.6 בנושא נתונים ברמת מערכת ההפעלה ונתונים סביבתיים, 9.8.15 בנושא הטמעות של API בארגז חול ו-9.8.16 בנושא נתוני אודיו ומצלמה רציפים) על נתוני מצלמה שמגיעים ממכשיר לביש מרוחק.

אם הטמעות של מכשירים מקבלות נתונים מהמצלמה או מהמיקרופון ממכשיר לביש מרוחק, והגישה לנתונים מתבצעת בצורה לא מוצפנת מחוץ למערכת Android, להטמעה בסביבת ארגז חול או לפונקציונליות בסביבת ארגז חול שנוצרה על ידי WearableSensingManager, הן:

‫[C-1-1] המכשיר חייב להורות למכשיר הלביש המרוחק להציג בו אינדיקטור נוסף.

אם מכשירים מספקים יכולת ליצור אינטראקציה עם אפליקציית עוזר דיגיטלי ללא מילת המפתח שהוקצתה (או טיפול בשאילתות משתמשים כלליות, או ניתוח נוכחות המשתמש באמצעות המצלמה), הם:

‫[C-2-1] חובה לוודא שההטמעה הזו מסופקת על ידי חבילה שמחזיקה בתפקיד android.app.role.ASSISTANT.
‫[C-2-2] חובה לוודא שההטמעה הזו משתמשת ב-API של Android‏ HotwordDetectionService או ב-API של Android‏ VisualQueryDetectionService או בשניהם.

‫9.8.17. Telemetry

מערכת Android מאחסנת יומנים של מערכת ואפליקציות באמצעות ממשקי StatsLog API. היומנים האלה מנוהלים באמצעות ממשקי API של StatsManager, שאפליקציות מערכת עם הרשאות מיוחדות יכולות להשתמש בהם.

בנוסף, StatsManager מספק דרך לאסוף נתונים שמסווגים כנתונים רגישים לפרטיות ממכשירים עם מנגנון לשמירה על הפרטיות. בפרט, StatsManager::query API מאפשר לשלוח שאילתות לגבי קטגוריות מוגבלות של מדדים שמוגדרות ב-StatsLog.

כל הטמעה שמבצעת שאילתות על מדדים מוגבלים ואוספת אותם מ-StatsManager:

‫[C-0-1] האפליקציה/ההטמעה חייבת להיות היחידה במכשיר, וצריכה להיות לה הרשאה READ_RESTRICTED_STATS.
‫[C-0-2] חובה לשלוח רק נתוני טלמטריה ויומן של המכשיר באמצעות מנגנון לשמירה על הפרטיות. המנגנון לשמירה על הפרטיות מוגדר כ "מנגנון שמאפשר ניתוח רק ברמת הצבירה ומונע התאמה של אירועים שנרשמו או של תוצאות שהתקבלו למשתמשים ספציפיים", כדי למנוע אפשרות לבדיקה של נתונים ברמת המשתמש (למשל, מנגנון שמיושם באמצעות טכנולוגיה לשמירה על הפרטיות כמו RAPPOR).
‫[C-0-3] אסור לשייך נתונים כאלה לזהות משתמש כלשהי (כמו חשבון) במכשיר.
‫[C-0-4] אסור לשתף נתונים כאלה עם רכיבים אחרים של מערכת ההפעלה שלא עומדים בדרישות שמפורטות בקטע הנוכחי (9.8.17. טלמטריה).
‫[C-0-5] חובה לספק למשתמשים אפשרות להפעיל או להשבית את האיסוף, השימוש והשיתוף של נתוני טלמטריה תוך שמירה על הפרטיות.
‫[C-0-6] חובה לספק למשתמשים אפשרות למחוק נתונים כאלה שההטמעה אוספת, אם הנתונים מאוחסנים במכשיר בכל צורה שהיא. אם המשתמש בחר למחוק את הנתונים, חובה להסיר את כל הנתונים שמאוחסנים כרגע במכשיר.
‫[C-0-7] חובה לחשוף את ההטמעה של פרוטוקול הבסיס לשמירה על פרטיות במאגר קוד פתוח.
‫[C-0-8] חובה לאכוף את מדיניות העברת הנתונים בקטע הזה כדי להגביל את איסוף הנתונים בקטגוריות של מדדים מוגבלים שמוגדרים ב-StatsLog.

‫9.8.18. פרטיות בפונקציות של סוכנים

הטמעות במכשיר:

‫[C-0-1] חובה לוודא שלכל הרכיבים שמבצעים AppFunctions יש הרשאה EXECUTE_APP_FUNCTIONS או EXECUTE_APP_FUNCTIONS_SYSTEM, והם נטענים מראש במכשיר.
‫[C-0-2] חובה להפעיל קריאה ל-AppFunction רק כתוצאה ישירה של פעולה מפורשת של המשתמש, וחובה לציין למשתמש באופן ברור איזו אפליקציה מופעלת ומהי הפעולה העיקרית שצריך לבצע באפליקציה הזו.
‫[C-0-3] אסור להעביר בקשה של אפליקציה של צד שלישי דרך שרת proxy או לשנות אותה כדי לגלות או להפעיל פונקציות של אפליקציות, אלא אם מתקיימים התנאים [C-0-1] ו-[C-0-2].
‫[C-0-4] אסור לאפשר לרכיבי מערכת להשתמש בנתונים רגישים ברמת מערכת ההפעלה או בנתונים סביבתיים (כפי שמוגדר בסעיף 9.8.6 אמצעי הגנה על נתונים ברמת מערכת ההפעלה ונתונים סביבתיים) או בנגזרות שלהם כדי ליצור או להגדיר תזכורות, אלא אם רכיבי המערכת פועלים בסביבת מחשוב מוגנת כפי שמוגדר בסעיף 9.8.6.

מונח מרכזי: 'תזכורת' מוגדרת כנקודת כניסה לאפליקציה שנוצרת באופן יזום מממשק מערכת, בלי שקדמה לה פעולה ישירה של המשתמש. תזכורות מעודדות או מנחות את המשתמש לבצע פעולה מסוימת בלי
לפגוע בחופש הבחירה שלו.

‫9.9. הצפנה של אחסון נתונים

כל המכשירים חייבים לעמוד בדרישות של סעיף 9.9.1. מכשירים שהושקו עם רמת API מוקדמת יותר מזו שמופיעה במסמך הזה פטורים מהדרישות של סעיפים 9.9.2 ו-9.9.3. במקום זאת, הם צריכים לעמוד בדרישות של סעיף 9.9 במסמך Android Compatibility Definition שמתאים לרמת ה-API שבה הושק המכשיר.

‫9.9.1. אתחול ישיר

הטמעות במכשיר:

‫[C-0-1] המכשיר חייב להטמיע את ממשקי ה-API של מצב אתחול ישיר, גם אם הוא לא תומך בהצפנת אחסון.
‫[C-0-2] עדיין צריך לשדר את ה-Intents‏ ACTION_LOCKED_BOOT_COMPLETED ו-ACTION_USER_UNLOCKED כדי לסמן לאפליקציות שמודעות למצב Direct Boot שמיקומי האחסון Device Encrypted‏ (DE) ו-Credential Encrypted‏ (CE) זמינים למשתמש.

‫9.9.2. דרישות הצפנה

הטמעות במכשיר:

‫[C-0-1] חובה להצפין את הנתונים הפרטיים של האפליקציה (מחיצת /data), וגם את מחיצת האחסון המשותף של האפליקציה (מחיצת /sdcard) אם היא חלק קבוע שלא ניתן להסרה מהמכשיר.
‫[C-0-2] חובה להפעיל את ההצפנה של אחסון הנתונים כברירת מחדל בזמן שהמשתמש משלים את חוויית ההגדרה הראשונית.
‫[C-0-3] חובה לעמוד בדרישה להצפנת נתוני אחסון שצוינה למעלה באמצעות הטמעה של אחת משתי שיטות ההצפנה הבאות:
- הצפנה מבוססת קבצים (FBE) והצפנת מטא-נתונים, כפי שמתואר בסעיף 9.9.3.1.
- הצפנה ברמת הבלוק לכל משתמש, כפי שמתואר בקטע 9.9.3.2.

‫9.9.3. שיטות הצפנה

אם ההטמעות של המכשירים מוצפנות, הן:

‫[C-1-1] המכשיר חייב לבצע אתחול בלי לבקש מהמשתמש פרטי כניסה, ולאפשר לאפליקציות שתומכות באתחול ישיר לגשת לאחסון Device Encrypted‏ (DE) אחרי שידור ההודעה ACTION_LOCKED_BOOT_COMPLETED.
‫[C-1-2] אסור לאפשר גישה לאחסון של נתונים מוצפנים של פרטי כניסה (CE) עד שיתקיימו שני התנאים הבאים:
- המשתמש מבטל את נעילת המכשיר באמצעות שיטת אימות ראשית (כמו סיסמה, קו פתיחת נעילה או קוד אימות).
- ההודעה ACTION_USER_UNLOCKED משודרת.
‫[C-1-13] אסור להציע שיטה כלשהי לפתיחת האחסון המוגן באמצעות CE ללא פרטי הכניסה שהמשתמש סיפק, מפתח נאמנות רשום או יישום של המשך הפעולה לאחר אתחול שעומד בדרישות שבסעיף 9.9.4.
‫[C-1-4] חובה להשתמש בהפעלה מאומתת.

‫9.9.3.1. הצפנה מבוססת-קבצים עם הצפנת מטא-נתונים

אם הטמעות המכשיר משתמשות בהצפנה מבוססת-קובץ עם הצפנת מטא-נתונים, הן:

‫[C-1-5] חובה להצפין את תוכן הקובץ ואת המטא-נתונים של מערכת הקבצים באמצעות AES-256-XTS או Adiantum. ‫AES-256-XTS מתייחס לתקן הצפנה מתקדם (AES) עם אורך מפתח הצפנה של 256 ביט, שפועל במצב XTS. האורך המלא של המפתח הוא 512 ביט. Adiantum מתייחס ל-Adiantum-XChaCha12-AES, כפי שמפורט בכתובת https://github.com/google/adiantum. מטא-נתונים של מערכת קבצים הם נתונים כמו גודל הקובץ, הבעלות, המצבים והמאפיינים המורחבים (xattrs).
‫[C-1-6] חובה להצפין שמות של קבצים באמצעות AES-256-CBC-CTS,‏ AES-256-HCTR2 או Adiantum.
‫[C-1-12] אם למכשיר יש הוראות Advanced Encryption Standard ‏ (AES) (כמו ARMv8 Cryptography Extensions במכשירים מבוססי ARM, או AES-NI במכשירים מבוססי x86), חובה להשתמש באפשרויות מבוססות AES שצוינו למעלה להצפנת שם הקובץ, תוכן הקובץ ומטא-נתונים של מערכת הקבצים, ולא ב-Adiantum.
‫[C-1-13] חובה להשתמש בפונקציית נגזרת מפתח (KDF) חזקה מבחינה קריפטוגרפית ובלתי הפיכה (למשל HKDF-SHA512) כדי להפיק את כל מפתחות המשנה הנדרשים (למשל מפתחות לכל קובץ) ממפתחות ה-CE וה-DE. המשמעות של 'חזק מבחינה קריפטוגרפית ולא ניתן להמרה' היא שלפונקציית הנגזרת של המפתח יש חוזק אבטחה של לפחות 256 ביטים, והיא מתנהגת כמשפחה של פונקציות פסאודו-אקראיות על פני הקלט שלה.
‫[C-1-14] אסור להשתמש באותם מפתחות או מפתחות משנה של הצפנה מבוססת-קבצים (FBE) למטרות קריפטוגרפיות שונות (למשל, גם להצפנה וגם לגזירת מפתחות, או לשני אלגוריתמים שונים להצפנה).
‫[C-1-15] חובה לוודא שכל הבלוקים שלא נמחקו בתוכן של קובץ מוצפן באחסון מתמיד הוצפנו באמצעות שילובים של מפתח הצפנה ושל וקטור אתחול (IV) שתלויים גם בקובץ וגם בהיסט בתוך הקובץ. בנוסף, כל השילובים האלה צריכים להיות שונים, אלא אם ההצפנה מתבצעת באמצעות חומרה להצפנה מוטבעת שתומכת רק באורך של 32 ביטים של וקטור אתחול.
‫[C-1-16] חובה לוודא שכל שמות הקבצים המוצפנים שלא נמחקו באחסון קבוע בספריות נפרדות הוצפנו באמצעות שילובים נפרדים של מפתח הצפנה ווקטור אתחול (IV).
‫[C-1-17] חובה לוודא שכל בלוקי המטא-נתונים של מערכת הקבצים המוצפנת באחסון מתמיד הוצפנו באמצעות שילובים שונים של מפתח הצפנה ושל וקטור אתחול (IV).
מפתחות שמגנים על אזורי אחסון של CE ו-DE ומטא-נתונים של מערכת קבצים:
- ‫[C-1-7] חובה לקשור באופן קריפטוגרפי למאגר מפתחות שמגובה בחומרה. מאגר המפתחות הזה חייב להיות קשור להפעלה מאומתת ול-Root of Trust של החומרה במכשיר.
- ‫[C-1-8] מפתחות CE חייבים להיות מקושרים לפרטי הכניסה של המשתמש למסך הנעילה.
- ‫[C-1-9] מקשי CE חייבים להיות משויכים לסיסמת ברירת מחדל אם המשתמש לא הגדיר פרטי כניסה למסך הנעילה.
- ‫[C-1-10] חייב להיות ייחודי ומובחן, כלומר, מפתח ה-CE או ה-DE של משתמש מסוים לא יכול להיות זהה למפתח ה-CE או ה-DE של משתמש אחר.
- ‫[C-1-11] חובה להשתמש בצפנים, באורכי מפתחות ובמצבים הנתמכים.
- ‫[C-1-12] חובה למחוק בצורה מאובטחת במהלך פתיחה ונעילה של תוכנת האתחול, כפי שמתואר כאן.
מומלץ להפוך אפליקציות חיוניות שמותקנות מראש (למשל, שעון מעורר, טלפון, Messenger) למודעות להפעלה ישירה.

פרויקט הקוד הפתוח של Android מספק הטמעה מועדפת של הצפנה מבוססת-קובץ שמבוססת על תכונת ההצפנה fscrypt של ליבת Linux, ושל הצפנת מטא-נתונים שמבוססת על התכונה dm-default-key של ליבת Linux.

‫9.9.3.2. הצפנה ברמת הבלוק לכל משתמש

אם הטמעות המכשירים משתמשות בהצפנה ברמת הבלוק לכל משתמש, הן:

‫[C-1-1] חובה להפעיל תמיכה בריבוי משתמשים כפי שמתואר בקטע 9.5.
‫[C-1-2] חובה לספק מחיצות לכל משתמש, באמצעות מחיצות גולמיות או נפחים לוגיים.
‫[C-1-3] חובה להשתמש במפתחות הצפנה ייחודיים ונפרדים לכל משתמש להצפנה של מכשירי הבלוק הבסיסיים.
‫[C-1-4] חובה להשתמש ב-AES-256-XTS להצפנה ברמת הבלוק של מחיצות המשתמש.
המפתחות שמגנים על מכשירים מוצפנים ברמת הבלוק לכל משתמש:
- ‫[C-1-5] חייב להיות קשור באופן קריפטוגרפי למאגר מפתחות שמגובה בחומרה. מאגר המפתחות הזה חייב להיות קשור להפעלה מאומתת ול-Root of Trust של החומרה במכשיר.
- ‫[C-1-6] חובה לקשר את האישורים למסך הנעילה של המשתמש המתאים.

אפשר להטמיע הצפנה ברמת הבלוק לכל משתמש באמצעות התכונה dm-crypt של ליבת Linux במחיצות לכל משתמש.

‫9.9.4. המשך הפעלה מחדש

התכונה 'המשך לאחר הפעלה מחדש' מאפשרת לבטל את הנעילה של נפח האחסון של כל האפליקציות, כולל אלה שעדיין לא תומכות בהפעלה ישירה, אחרי הפעלה מחדש שמתבצעת על ידי OTA. התכונה הזו מאפשרת למשתמשים לקבל התראות מאפליקציות מותקנות אחרי הפעלה מחדש.

הטמעה של Resume-on-Reboot חייבת להמשיך לוודא שאם מכשיר נופל לידי תוקף, יהיה לו קשה מאוד לשחזר את הנתונים המוצפנים ב-CE של המשתמש, גם אם המכשיר מופעל, האחסון ב-CE לא נעול והמשתמש פתח את נעילת המכשיר אחרי קבלת OTA. כדי להתגונן מפני מתקפות של גורמים פנימיים, אנחנו מניחים שהתוקף משיג גישה למפתחות קריפטוגרפיים לחתימה על שידורים.

פרטים נוספים:

‫[C-0-1] אסור לאחסון CE להיות קריא, גם לתוקף שיש לו פיזית את המכשיר, ושיש לו את היכולות והמגבלות הבאות:
- יכול להשתמש במפתח החתימה של כל ספק או חברה כדי לחתום על הודעות שרירותיות.
- יכול לגרום לקבלת עדכון OTA במכשיר.
- יכול לשנות את הפעולה של כל רכיב חומרה (AP, ‏ flash וכו') למעט כפי שמפורט בהמשך, אבל שינוי כזה כרוך בעיכוב של שעה לפחות ובמחזור הפעלה שמביא להרס של תוכן ה-RAM.
- אי אפשר לשנות את הפעולה של חומרה עמידה בפני חדירה (למשל Titan M).
- אי אפשר לקרוא את ה-RAM של המכשיר הפעיל.
- לא ניתן לקבל את פרטי הכניסה של המשתמש (קוד אימות, קו פתיחת נעילה, סיסמה) או לגרום להזנתם.

לדוגמה, הטמעה של מכשיר שמטמיעה את כל התיאורים שמופיעים כאן ועומדת בדרישות שלהם, תעמוד בדרישות של [C-0-1].

‫9.10. תקינות המכשיר

הדרישות הבאות מבטיחות שקיפות לגבי סטטוס תקינות המכשיר. הטמעות במכשיר:

‫[C-0-1] חובה לדווח בצורה נכונה באמצעות השיטה System API‏ PersistentDataBlockManager.getFlashLockState() אם מצב טוען האתחול מאפשר צריבה של קובץ האימג' של המערכת.
‫[C-0-2] חובה לתמוך בהפעלה מאומתת לצורך תקינות המכשיר.

אם יישומי המכשירים כבר הושקו ללא תמיכה בהפעלה מאומתת בגרסה קודמת של Android, ואי אפשר להוסיף תמיכה בתכונה הזו באמצעות עדכון תוכנת מערכת, יכול להיות שיהיה פטור מהדרישה.

הפעלה מאומתת היא תכונה שמבטיחה את תקינות התוכנה של המכשיר. אם ההטמעות במכשיר תומכות בתכונה, הן:

‫[C-1-1] חובה להצהיר על דגל התכונה של הפלטפורמה android.software.verified_boot.
‫[C-1-2] חובה לבצע אימות בכל רצף הפעלה.
‫[C-1-3] חובה להתחיל את האימות ממפתח חומרה בלתי ניתן לשינוי שהוא Root of Trust, ולהמשיך עד למחיצת המערכת.
‫[C-1-4] חובה להטמיע כל שלב באימות כדי לבדוק את השלמות והאותנטיות של כל הבייטים בשלב הבא לפני שמריצים את הקוד בשלב הבא.
‫[C-1-5] חובה להשתמש באלגוריתמים חזקים לאימות, כמו ההמלצות הנוכחיות של NIST לגבי אלגוריתמים לגיבוב (SHA-256) וגדלים של מפתחות ציבוריים (RSA-2048).
‫[C-1-6] אסור לאפשר אתחול מלא אם אימות המערכת נכשל, אלא אם המשתמש מסכים לנסות לאתחל בכל זאת. במקרה כזה, אסור להשתמש בנתונים מכל בלוק אחסון שלא אומת.
‫[C-1-7] אסור לאפשר שינוי של מחיצות מאומתות במכשיר, אלא אם המשתמש ביטל את הנעילה של טוען האתחול באופן מפורש.
‫[C-1-8] חובה להשתמש באחסון שמונע שינויים לא מורשים: לאחסון המידע לגבי פתיחת טוען האתחול. אחסון עם הוכחה לשיבוש פירושו שמנהל האתחול יכול לזהות אם בוצע שיבוש באחסון מתוך Android.
‫[C-1-9] המערכת חייבת להציג למשתמש בקשה לאישור פיזי בזמן השימוש במכשיר, לפני המעבר ממצב נעילת תוכנת האתחול למצב ביטול הנעילה של תוכנת האתחול.
‫[C-1-10] חובה להטמיע הגנה מפני חזרה לגרסה קודמת במחיצות שמשמשות את Android (למשל, מחיצות אתחול ומערכת) ולהשתמש באחסון עם הוכחה לשינוי לא מורשה כדי לאחסן את המטא-נתונים שמשמשים לקביעת גרסת מערכת ההפעלה המינימלית המותרת.
‫[C-1-11] חובה למחוק בצורה מאובטחת את כל נתוני המשתמש במהלך פתיחת הנעילה של תוכנת האתחול ונעילתה, בהתאם לסעיף 9.12. מחיקת נתונים' (כולל מחיצה של נתוני משתמשים וכל מרחבי NVRAM).
‫[C-1-14] חובה לאמת את החתימה לפחות פעם אחת בכל הפעלה של המכשיר עבור חבילות שמופיעות ברשימת ההיתרים ומצוינות כ-require-strict-signature בהגדרת המערכת.
[C-SR-2] מומלץ מאוד לאמת את כל קובצי ה-APK של אפליקציות בעלות הרשאות מיוחדות באמצעות שרשרת מהימנות שמושרשת במחיצות שמוגנות על ידי הפעלה מאומתת.
‫[C-SR-3] מומלץ מאוד לאמת כל ארטיפקט הפעלה שנטען על ידי אפליקציה עם הרשאות מחוץ לקובץ ה-APK שלה (כמו קוד שנטען באופן דינמי או קוד שעבר קומפילציה) לפני שמבצעים אותו, או מומלץ מאוד לא לבצע אותו בכלל.
מומלץ להטמיע הגנה מפני חזרה לגרסה קודמת לכל רכיב עם קושחה מתמשכת (למשל, מודם, מצלמה) ומומלץ להשתמש באחסון עם סימני פתיחה כדי לאחסן את המטא-נתונים שמשמשים לקביעת הגרסה המינימלית המותרת.

ב-Android Open Source Project (AOSP) יש הטמעה מועדפת של התכונה הזו במאגר external/avb/, שאפשר לשלב אותה בטוען האתחול שמשמש לטעינת Android.

אם להטמעות של מכשירים יש אפשרות לאמת את תוכן הקובץ על בסיס כל דף, אז הן:

‫[C-2-1] תמיכה באימות קריפטוגרפי של תוכן הקובץ בלי לקרוא את הקובץ כולו.
‫[C-2-2] אסור לאפשר לבקשות קריאה בקובץ מוגן להצליח אם התוכן שנקרא לא אומת בהתאם ל-‫[C-2-1] שלמעלה.
‫[C-2-4] חובה להחזיר את סכום הביקורת של הקובץ ב-O(1) עבור קבצים מופעלים.

אם הטמעות המכשירים כבר הושקו ללא אפשרות לאמת את תוכן הקובץ מול מפתח מהימן בגרסה קודמת של Android, ואי אפשר להוסיף תמיכה בתכונה הזו באמצעות עדכון תוכנה של המערכת, יכול להיות שיהיה פטור מהדרישה. פרויקט הקוד הפתוח של Android מספק הטמעה מועדפת של התכונה הזו שמבוססת על התכונה fs-verity של ליבת Linux.

‫9.11. מפתחות ופרטי כניסה

מערכת Android Keystore מאפשרת למפתחי אפליקציות לאחסן מפתחות קריפטוגרפיים במאגר ולהשתמש בהם בפעולות קריפטוגרפיות באמצעות KeyChain API או Keystore API. הטמעות במכשיר:

‫[C-0-1] המערכת חייבת לאפשר ייבוא או יצירה של לפחות 8,192 מפתחות.
‫[C-0-2] באימות במסך הנעילה צריך להיות מרווח זמן בין ניסיונות כושלים. אם n הוא מספר הניסיונות הכושלים, מרווח הזמן חייב להיות לפחות 30 שניות אם 9 < n < 30. אם n > 29, ערך מרווח הזמן חייב להיות לפחות 30*2^floor((n-30)/10) שניות או לפחות 24 שעות, לפי הקטן מביניהם.
לא צריכה להיות הגבלה על מספר המפתחות שאפשר ליצור.

אם ההטמעה של המכשיר תומכת במסך נעילה מאובטח, היא:

‫[C-1-1] חובה לגבות את ההטמעה של מאגר המפתחות באמצעות סביבת ביצוע מבודדת.

‫[C-1-2] חובה להטמיע אלגוריתמים קריפטוגרפיים מסוג RSA,‏ AES,‏ ECDSA,‏ ECDH (אם נתמך IKeyMintDevice),‏ 3DES ו-HMAC, ופונקציות גיבוב מסוג MD5,‏ SHA-1 ו-SHA-2 האלגוריתמים הקריפטוגרפיים ופונקציות הגיבוב שנדרשים על ידי הגרסה הנתמכת של IKeyMintDevice או IKeymasterDevice כדי לתמוך בצורה תקינה באלגוריתמים הנתמכים של מערכת Android Keystore באזור שמבודד בצורה מאובטחת מהקוד שפועל בקרנל ומעליו.

בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד של ליבה או של מרחב משתמשים יכול לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA.

פרויקט הקוד הפתוח של Android‏ (AOSP) עומד בדרישה הזו באמצעות ההטמעה של Trusty, אבל אפשרות חלופית היא פתרון אחר שמבוסס על ARM TrustZone או הטמעה מאובטחת של מפקח מכונות וירטואליות (hypervisor) שעברה ביקורת של צד שלישי.

‫[C-1-3] חובה לבצע את האימות במסך הנעילה בסביבת ביצוע מבודדת, ורק אם האימות מצליח, לאפשר שימוש במפתחות שקשורים לאימות. פרטי הכניסה למסך הנעילה צריכים להיות מאוחסנים באופן שמאפשר רק לסביבת הביצוע המבודדת לבצע אימות של מסך הנעילה. פרויקט הקוד הפתוח של Android מספק את שכבת ההפשטה של חומרה (HAL) של Gatekeeper ואת Trusty, שאפשר להשתמש בהם כדי לעמוד בדרישה הזו.
‫[C-1-4] חובה לתמוך באימות מפתחות, כאשר מפתח החתימה של האימות מוגן על ידי חומרה מאובטחת והחתימה מתבצעת בחומרה מאובטחת. אסור להשתמש במפתחות החתימה של האימות כמזהי מכשיר קבועים.

הערה: כדי לעמוד בדרישה הזו, אתם צריכים לשתף את אותו מפתח אישור עבור מק"ט מסוים, אלא אם יוצרו לפחות 100,000 יחידות של אותו מק"ט. אם מייצרים יותר מ-100,000 יחידות של המק"ט הזה, אפשר להשתמש במפתח אחר לכל קבוצה של 100,000 יחידות לאחר מכן. לחלופין, אפשר להשתמש בפתרון של הקצאת מפתחות מרחוק כדי להקצות למכשיר מפתחות אימות לזמן קצר.

‫[C-1-5] המערכת חייבת לאפשר למשתמש לבחור את הזמן הקצוב לתפוגה של מצב שינה למעבר ממצב לא נעול למצב נעול, עם זמן קצוב לתפוגה מינימלי של עד 15 שניות. במכשירים לרכב שנועלים את המסך בכל פעם שמערכת המולטימדיה מושבתת או שהמשתמש מוחלף, יכול להיות שלא תהיה אפשרות להגדיר את הזמן הקצוב לתפוגה של מצב שינה.
‫[C-1-6] המכשיר חייב לתמוך ב-IKeymasterDevice מגרסה 3.0 ואילך, או ב-IKeyMintDevice מגרסה 1 ואילך.

‫[C-SR-1] מומלץ מאוד לאכוף מרווח זמן מינימלי בין ניסיונות כושלים ייחודיים לשימוש בשיטות האימות העיקריות (כמו קוד אימות, קו ביטול נעילה או סיסמה), על סמך ההנחיות הבאות:

מספר הניסיונות הייחודיים שנכשלו	זמן קצוב מינימלי
0-4	0
5	דקה אחת
6	5 דקות
7	15 דקות
8	‫30 דקות
9	‫90 דקות
10	4 שעות
11	12 שעות
12	24 שעות
13	4 ימים
14	13 ימים
15	‫41 ימים
16	‫123 ימים
17	שנה אחת
18	‫3 שנים
19	9 שנים

‫9.11.1. נעילה מאובטחת, אימות ומכשירים וירטואליים

ההטמעה ב-AOSP מבוססת על מודל אימות מדורג, שבו אימות ראשי מבוסס על גורם ידע יכול להיות מגובה באימות ביומטרי משני חזק, או באמצעים שלישוניים חלשים יותר.

הטמעות במכשיר:

‫[C-SR-1] מומלץ מאוד להגדיר רק אחת מהאפשרויות הבאות כשיטת האימות הראשית:
- קוד אימות מספרי
- סיסמה אלפאנומרית
- דפוס החלקה ברשת של 3x3 נקודות בדיוק
שימו לב: שיטות האימות שצוינו למעלה הן שיטות האימות העיקריות המומלצות במסמך הזה.
‫[C-0-1] חובה להגביל את מספר הניסיונות הכושלים לאימות ראשי.
‫[C-SR-5] מומלץ מאוד להגדיר מגבלה של 20 ניסיונות כושלים לאימות ראשי, ואם המשתמשים מסכימים ומצטרפים לתכונה, לבצע 'איפוס נתוני היצרן' אחרי חריגה מהמגבלה של ניסיונות כושלים לאימות ראשי.

אם הטמעות המכשירים מגדירות קוד מספרי כשיטת האימות העיקרית המומלצת, אז:

‫[C-SR-6] מומלץ מאוד שקוד האימות יכלול לפחות 6 ספרות, או לחלופין אנטרופיה של 20 ביט.
‫[C-SR-7] מומלץ מאוד לא לאפשר הזנה אוטומטית של קוד אימות באורך של פחות מ-6 ספרות ללא אינטראקציה עם המשתמש, כדי למנוע חשיפה של אורך קוד האימות.

אם הטמעות של מכשירים מוסיפות או משנות את שיטות האימות העיקריות המומלצות ומשתמשות בשיטת אימות חדשה כדרך מאובטחת לנעילת המסך, שיטת האימות החדשה:

‫[C-2-1] חייבת להיות שיטת אימות המשתמש כפי שמתואר בקטע דרישת אימות משתמש לשימוש במפתח.

אם הטמעות של מכשירים מוסיפות או משנות את שיטות האימות לפתיחת הנעילה של מסך הנעילה, אם הן מבוססות על סוד ידוע ומשתמשות בשיטת אימות חדשה שתיחשב כדרך מאובטחת לנעילת המסך:

‫[C-3-1] האנטרופיה של האורך הקצר ביותר המותר של קלט חייבת להיות גדולה מ-10 ביט.
‫[C-3-2] האנטרופיה המקסימלית של כל הקלטים האפשריים חייבת להיות גדולה מ-18 ביט.
‫[C-3-3] שיטת האימות החדשה לא יכולה להחליף אף אחת משיטות האימות הראשיות המומלצות (כלומר, קוד אימות, קו פתיחת נעילה, סיסמה) שהוטמעו וסופקו ב-AOSP.
‫[C-3-4] שיטת האימות החדשה חייבת להיות מושבתת אם אפליקציית Device Policy Controller ‏ (DPC) הגדירה את מדיניות הדרישות לסיסמה באמצעות DevicePolicyManager.setRequiredPasswordComplexity()‎ עם קבוע מורכבות מגביל יותר מ-PASSWORD_COMPLEXITY_NONE, או באמצעות השיטה DevicePolicyManager.setPasswordQuality()‎ עם קבוע מגביל יותר מ-PASSWORD_QUALITY_BIOMETRIC_WEAK.
‫[C-3-5] שיטות אימות חדשות צריכות לחזור לשיטות האימות העיקריות המומלצות (כלומר, קוד אימות, קו ביטול נעילה, סיסמה) אחת ל-72 שעות או פחות, או לחלופין להבהיר למשתמש שחלק מהנתונים לא יגובו כדי לשמור על הפרטיות של הנתונים שלו.

אם הטמעות של מכשירים מוסיפות או משנות את שיטות האימות העיקריות המומלצות לפתיחת הנעילה של המסך ומשתמשות בשיטת אימות חדשה שמבוססת על נתונים ביומטריים כדי להיחשב כדרך מאובטחת לנעילת המסך, השיטה החדשה:

‫[C-4-1] חובה לעמוד בכל הדרישות שמתוארות בקטע 7.3.10 עבור Class 1 (לשעבר Convenience).
‫[C-4-2] חובה להשתמש במנגנון חלופי כדי להשתמש באחת משיטות האימות הראשיות המומלצות שמבוססות על סוד ידוע.
‫[C-4-3] צריך להשבית את האפשרות הזו ולאפשר רק את שיטת האימות העיקרית המומלצת לביטול הנעילה של המסך, אם אפליקציית Device Policy Controller‏ (DPC) הגדירה את מדיניות התכונות של Keyguard באמצעות קריאה לשיטה DevicePolicyManager.setKeyguardDisabledFeatures(), עם אחד מהדגלים הביומטריים המשויכים (כלומר, KEYGUARD_DISABLE_BIOMETRICS,‏ KEYGUARD_DISABLE_FINGERPRINT,‏ KEYGUARD_DISABLE_FACE או KEYGUARD_DISABLE_IRIS).

אם שיטות האימות הביומטרי לא עומדות בדרישות של סיווג 3 (לשעבר חזק) כמו שמתואר בקטע 7.3.10:

‫[C-5-1] צריך להשבית את השיטות אם אפליקציית Device Policy Controller‏ (DPC) הגדירה את מדיניות האיכות של דרישות הסיסמה באמצעות DevicePolicyManager.setRequiredPasswordComplexity()‎ עם דלי מורכבות מגביל יותר מ-PASSWORD_COMPLEXITY_LOW או באמצעות השיטה DevicePolicyManager.setPasswordQuality()‎ עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_BIOMETRIC_WEAK.
‫[C-5-2] המשתמש צריך להתבקש לבצע את האימות הראשי המומלץ (כמו קוד אימות, קו ביטול נעילה או סיסמה), כפי שמתואר ב‫[C-1-7] וב-‫[C-1-8] בסעיף 7.3.10.
‫[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_NONE.
- השיטה DevicePolicyManager.setRequiredPasswordComplexity() עם סיווג מורכבות מגביל יותר מאשר PASSWORD_COMPLEXITY_NONE.
‫[C-6-3] המשתמש צריך להתבקש להשתמש באחת משיטות האימות העיקריות המומלצות (כמו קוד אימות, קו ביטול נעילה או סיסמה) לפחות פעם אחת בכל 4 שעות או פחות. אם אסימון פיזי עומד בדרישות של הטמעות TrustAgent ב-C-X, חלות במקומו הגבלות הזמן הקצוב לתפוגה שהוגדרו ב-[C-9-5].
‫[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 או מכשיר לרכב).
‫[C-7-4] חובה להצפין את כל הטוקנים המאוחסנים שנוספו על ידי TrustAgentService.addEscrowToken().
‫[C-7-5] אסור לאחסן את מפתח ההצפנה או את אסימון הנאמנות באותו מכשיר שבו נעשה שימוש במפתח. לדוגמה, מותר שמפתח שמאוחסן בטלפון יבטל את הנעילה של חשבון משתמש בטלוויזיה. במכשירים לרכב, אסור לאחסן את אסימון הנאמנות בכל חלק של הרכב.
‫[C-7-6] חובה ליידע את המשתמש לגבי ההשלכות על האבטחה לפני הפעלת אסימון הנאמנות לצורך פענוח של אחסון הנתונים.
‫[C-7-7] חובה להשתמש במנגנון חלופי כדי להשתמש באחת משיטות האימות העיקריות המומלצות.
‫[C-7-9] המשתמש חייב להתבקש להשתמש באחת משיטות האימות העיקריות המומלצות (כמו קוד אימות, קו פתיחת נעילה או סיסמה) כפי שמתואר ב‫[C-1-7] וב‫[C-1-8] בסעיף 7.3.10, אלא אם יש חשש לגבי בטיחות המשתמש (למשל, הסחת דעת של הנהג).
[C-7-10] אסור להתייחס למסך נעילה כאל נעילה מאובטחת, והיא חייבת לעמוד בדרישות שמפורטות בסעיף C-8 בהמשך.
‫[C-7-11] אסור לאפשר ל-TrustAgents במכשירים אישיים ראשיים (לדוגמה: מכשירים ניידים) לבטל את הנעילה של המכשיר, ואפשר להשתמש בהם רק כדי לשמור על מצב לא נעול של מכשיר שכבר לא נעול למשך עד 4 שעות. ההטמעה שמוגדרת כברירת מחדל של TrustManagerService ב-AOSP עומדת בדרישה הזו.
‫[C-7-12] חובה להשתמש בערוץ תקשורת מאובטח מבחינה קריפטוגרפית (למשל UKEY2) כדי להעביר את אסימון הנאמנות ממכשיר האחסון למכשיר היעד.

אם בהטמעות של המכשיר נוספות או משתנות שיטות האימות לביטול הנעילה של מסך הנעילה שאינו מסך נעילה מאובטח כפי שמתואר למעלה, ונעשה שימוש בשיטת אימות חדשה לביטול הנעילה של מסך הנעילה:

‫[C-8-1] השיטה החדשה חייבת להיות מושבתת אם אפליקציית Device Policy Controller‏ (DPC) הגדירה את מדיניות איכות הסיסמה באמצעות השיטה DevicePolicyManager.setPasswordQuality() עם קבוע איכות מגביל יותר מ-PASSWORD_QUALITY_NONE, או באמצעות השיטה DevicePolicyManager.setRequiredPasswordComplexity() עם קבוע מורכבות מגביל יותר מ-PASSWORD_COMPLEXITY_NONE.
‫[C-8-2] אסור להם לאפס את טיימר התפוגה של הסיסמאות שהוגדרו על ידי DevicePolicyManager.setPasswordExpirationTimeout().
‫[C-8-3] אסור לחשוף API לשימוש של אפליקציות צד שלישי כדי לשנות את מצב הנעילה.

אם ההטמעות במכשיר מאפשרות לאפליקציות ליצור מסכים וירטואליים משניים ולא תומכות באירועי קלט משויכים, כמו באמצעות VirtualDeviceManager, הן:

‫[C-9-1] חובה לנעול את המסכים הווירטואליים המשניים האלה כשהמסך הווירטואלי הראשי של המכשיר נעול, ולבטל את הנעילה של המסכים הווירטואליים המשניים האלה כשהמסך הווירטואלי הראשי של המכשיר לא נעול.

אם הטמעות במכשיר מאפשרות לאפליקציות ליצור תצוגות וירטואליות משניות ותומכות באירועי קלט משויכים, למשל באמצעות VirtualDeviceManager, הן:

‫[C-10-1] חובה לתמוך במצבי נעילה נפרדים לכל מכשיר וירטואלי
‫[C-10-2] הדרישה הוסרה ב-Android 16.
‫[C-10-3] הדרישה הוסרה ב-Android 16.
‫[C-10-4] המכשיר חייב לנעול את כל המסכים כשהמשתמש מפעיל מצב חירום, כולל באמצעות אמצעי הנגישות למשתמש שנדרש למכשירים ניידים (ראו סעיף 2.2.5[9.11/H-1-2])
‫[C-10-5] חובה להשתמש במופעים נפרדים של מכשירים וירטואליים לכל משתמש
‫[C-10-6] חובה להשבית את הסטרימינג של האפליקציה כפי שמצוין ב-DevicePolicyManager.setNearbyAppStreamingPolicy.
‫[C-10-7] הדרישה הוסרה ב-Android 16.
‫[C-10-11] חובה להשבית את ממשק המשתמש של האימות במכשירים וירטואליים, כולל הזנת גורם ידע והנחיה ביומטרית
‫[C-10-12] הדרישה הוסרה ב-Android 16.
‫[C-10-13] אסור להשתמש במצב נעילה של מכשיר וירטואלי כאימות משתמש הרשאה באמצעות מערכת Android Keystore. מידע נוסף זמין במאמר בנושא KeyGenParameterSpec.Builder.setUserAuthentication*.
‫[C-10-14] אם המכשיר מטמיע לוח משותף, הוא חייב לספק למשתמשים אפשרות להפעיל שיתוף של הלוח בין מכשירים לפני שיתוף נתונים מהלוח בין מכשירים פיזיים לווירטואליים.
‫[C-10-15] חובה להציג התראות כשניגשים לנתונים בלוח העריכה, גם במכשיר שממנו בוצעה הגישה וגם במכשיר שממנו הועתקו הנתונים ללוח העריכה.

אם הטמעות של מכשירים מאפשרות למשתמש להעביר את גורם הידע של האימות הראשי ממכשיר מקור למכשיר יעד, למשל לצורך הגדרה ראשונית של מכשיר היעד, הן:

‫[C-11-1] חובה להצפין את גורם הידע עם ערבויות הגנה דומות לאלה שמתוארות במסמך המידע בנושא אבטחה של Google Cloud Key Vault Service כשמעבירים את גורם הידע ממכשיר המקור למכשיר היעד, כך שאי אפשר לפענח מרחוק את גורם הידע או להשתמש בו כדי לבטל את הנעילה של אחד מהמכשירים מרחוק.
‫[C-11-2] חובה, במכשיר המקור , לבקש מהמשתמש לאשר את גורם הידע של מכשיר המקור לפני העברת גורם הידע למכשיר היעד.
‫[C-11-3] חובה, במכשיר יעד שחסר בו גורם ידע להגדרת אימות ראשי, לבקש מהמשתמש לאשר גורם ידע שהועבר במכשיר היעד לפני הגדרת גורם הידע הזה כגורם הידע לאימות הראשי במכשיר היעד ולפני שהנתונים שהועברו ממכשיר המקור יהיו זמינים.

אם הטמעות המכשיר כוללות מסך נעילה מאובטח וסוכן מהימן אחד או יותר, שקוראים לממשק ה-API של המערכת עם הדגל FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, הן:TrustAgentService.grantTrust()

‫[C-12-1] חובה לקרוא רק ל-grantTrust() עם הדגל כשמתחברים למכשיר פיזי קרוב עם מסך נעילה משלו, וכשהמשתמש אימת את הזהות שלו מול מסך הנעילה הזה. מכשירים בקרבת מקום יכולים להשתמש במנגנוני זיהוי על פרק כף היד או זיהוי נשיאה על הגוף אחרי שהמשתמש מבטל את הנעילה פעם אחת, כדי לעמוד בדרישה לאימות המשתמש.
‫[C-12-2] חובה להעביר את הטמעת המכשיר למצב TrustState.TRUSTABLE כשהמסך כבוי (למשל, בלחיצה על לחצן או כשהמסך נכבה בגלל חוסר פעילות) ו-TrustAgent לא ביטל את האמון. מערכת AOSP עומדת בדרישה הזו.
‫[C-12-3] המכשיר חייב לעבור ממצב TrustState.TRUSTABLE למצב TrustState.TRUSTED רק אם TrustAgent עדיין מעניק אמון על סמך הדרישות שמופיעות בקטע [C-12-1].

‫[C-12-4] חובה לקרוא ל-TrustManagerService.revokeTrust() אם ההטמעות לא משתמשות בטווח מדויק ומאובטח מבחינה קריפטוגרפית, כפי שמוגדר ב-‫[C-12-5]:
- אחרי 24 שעות לכל היותר ממועד מתן ההרשאה, או
- אחרי חלון של 8 שעות ללא פעילות, או
- אם ההטמעות לא משתמשות בטווח מדויק ומאובטח מבחינה קריפטוגרפית כפי שמוגדר ב-[C-12-5], כשהחיבור הבסיסי למכשיר הפיזי הסמוך אובד.

‫[C-12-5] הטמעות שמסתמכות על טווח מאובטח ומדויק כדי לעמוד בדרישות של [C-12-4] חייבות להשתמש באחד מהפתרונות הבאים:
- הטמעות באמצעות UWB:
  - חייבים לעמוד בדרישות התאימות, האישור, הדיוק והכיול של UWB שמתוארות בסעיף 7.4.9.
  - חובה להשתמש באחד ממצבי האבטחה של P-STS שמפורטים בקטע 7.4.9.
- הטמעות באמצעות Neighbor Awareness Networking (NAN)‎ ב-Wi-Fi:
  - חייבים לעמוד בדרישות הדיוק שמופיעות בקטע 2.2.1 [7.4.2.5/H-SR-1], להשתמש ברוחב פס של 160 MHz (או יותר) ולפעול לפי שלבי הגדרת המדידה שמופיעים בקטע Presence Calibration.
  - חובה להשתמש ב-LTF מאובטח כפי שמוגדר ב-IEEE 802.11az.

אם הטמעות של מכשירים מאפשרות לאפליקציות ליצור מסכים וירטואליים משניים ולתמוך באירועי קלט משויכים, למשל באמצעות VirtualDeviceManager, והמסכים לא מסומנים ב-VIRTUAL_DISPLAY_FLAG_SECURE, הם:

‫[C-13-8] חובה לחסום פעילויות עם המאפיין android:canDisplayOnRemoteDevices או המטא-נתונים android.activity.can_display_on_remote_devices שמוגדרים כ-false, כך שלא ניתן יהיה להתחיל אותן במכשיר הווירטואלי.
‫[C-13-9] חובה לחסום פעילויות שלא מפעילות סטרימינג באופן מפורש ושמציינות שהן מציגות תוכן רגיש, כולל באמצעות SurfaceView#setSecure ו-FLAG_SECURE מלהתחיל במכשיר הווירטואלי.

אם הטמעות המכשירים תומכות במצבי הפעלה נפרדים של המסך באמצעות DeviceStateManager וגם תומכות במצבי נעילה נפרדים של המסך באמצעות KeyguardDisplayManager, הן:

‫[C-SR-2] מומלץ מאוד להשתמש באמצעי אימות שעומד בדרישות שמוגדרות בקטע 9.11.1 או באמצעי אימות ביומטרי שעומד לפחות בדרישות של סיווג 1 שמוגדרות בקטע 7.3.10, כדי לאפשר ביטול נעילה עצמאי מתצוגת ברירת המחדל של המכשיר.
‫[C-SR-3] מומלץ מאוד להגביל את ביטול הנעילה של תצוגה נפרדת באמצעות הגדרת זמן קצוב לתפוגת התצוגה.
[C-SR-4] מומלץ מאוד לאפשר למשתמש לנעול את כל המסכים באופן גלובלי באמצעות מצב חירום ממכשיר שניתן להחזיק ביד ראשי.

‫9.11.2. StrongBox

מערכת Android Keystore מאפשרת למפתחי אפליקציות לאחסן מפתחות קריפטוגרפיים במעבד מאובטח ייעודי, וגם בסביבת הביצוע המבודדת שתוארה למעלה. מעבד מאובטח ייעודי כזה נקרא StrongBox. בדרישות C-1-3 עד C-1-11 שבהמשך מוגדרות הדרישות שמכשיר צריך לעמוד בהן כדי להיחשב כ-StrongBox.

הטמעות של מכשירים עם מעבד מאובטח ייעודי:

‫[C-SR-1] מומלץ מאוד לתמוך ב-StrongBox. סביר להניח ש-StrongBox יהפוך לדרישה בגרסה עתידית.

אם ההטמעות של המכשיר תומכות ב-StrongBox, הן:

‫[C-1-1] חובה להצהיר על ‫FEATURE_STRONGBOX_KEYSTORE.
‫[C-1-2] חובה לספק חומרה ייעודית ומאובטחת שמשמשת לגיבוי של מאגר המפתחות ולאימות מאובטח של המשתמש. יכול להיות שהחומרה המאובטחת הייעודית תשמש גם למטרות אחרות.
‫[C-1-3] חייב להיות בעל מעבד נפרד שלא משתף מטמון, DRAM, מעבדי משנה או משאבי ליבה אחרים עם מעבד האפליקציה (AP).
‫[C-1-4] חובה לוודא שציוד היקפי שמשותף עם ה-AP לא יכול לשנות את העיבוד של StrongBox בשום צורה, או להשיג מידע מ-StrongBox. יכול להיות שה-AP יכבה או יחסום את הגישה ל-StrongBox.
‫[C-1-5] חובה שיהיה שעון פנימי עם רמת דיוק סבירה (‎+/- 10%) שלא ניתן לשינוי על ידי נקודת הגישה.
‫[C-1-6] חובה להשתמש במחולל מספרים אקראיים אמיתי שמפיק פלט בלתי צפוי עם התפלגות אחידה.
‫[C-1-7] חובה שתהיה עמידות בפני חבלה, כולל עמידות בפני חדירה פיזית ושיבושים.
‫[C-1-8] חובה שתהיה עמידות לערוץ צדדי, כולל עמידות מפני דליפת מידע דרך ערוצים צדדיים של הספק, תזמון, קרינה אלקטרומגנטית וקרינה תרמית.
‫[C-1-9] חובה לאחסן את התוכן בצורה מאובטחת כדי להבטיח את הסודיות, השלמות, האותנטיות, העקביות והעדכניות שלו. אסור לאפשר קריאה או שינוי של האחסון, אלא אם הדבר מותר על ידי ממשקי ה-API של StrongBox.

כדי לאמת את התאימות לדרישות [C-1-3] עד [C-1-9], הטמעות של מכשירים:

‫[C-1-10] חובה לכלול את החומרה שאושרה בהתאם לפרופיל ההגנה של IC מאובטח BSI-CC-PP-0084-2014 או BSI-CC-PP-0117-2022, או שנבדקה על ידי מעבדת בדיקה עם הסמכה לאומית שמשלבת הערכת פגיעות עם פוטנציאל גבוה להתקפה בהתאם ליישום של פוטנציאל התקפה על כרטיסים חכמים לפי הקריטריונים המשותפים.
‫[C-1-11] חובה לכלול את הקושחה שנבדקה על ידי מעבדת בדיקה עם הסמכה לאומית, שמשלבת הערכת פגיעות עם פוטנציאל גבוה להתקפה בהתאם לקריטריונים משותפים להערכת פוטנציאל התקפה על כרטיסים חכמים.
‫[C-SR-2] מומלץ מאוד לכלול את החומרה שנבדקה באמצעות יעד אבטחה, רמת הבטחת הערכה (EAL) 5, בתוספת AVA_VAN.5. סביר להניח שאישור EAL 5 יהפוך לדרישה בגרסה עתידית.
‫[C-SR-3] מומלץ מאוד לספק עמידות בפני מתקפות של משתמשים בעלי הרשאות גישה (IAR), כלומר משתמש בעל הרשאות גישה למפתחות חתימה של קושחה לא יכול ליצור קושחה שגורמת ל-StrongBox לדלוף סודות, לעקוף דרישות אבטחה פונקציונליות או לאפשר גישה לנתונים רגישים של משתמשים. הדרך המומלצת להטמיע IAR היא לאפשר עדכוני קושחה רק כשמספקים את הסיסמה של המשתמש הראשי דרך IAuthSecret HAL.

‫9.11.3. מסמך לאימות הזהות

מערכת פרטי הכניסה לזהות מוגדרת ומושגת באמצעות הטמעה של כל ממשקי ה-API בחבילה android.security.identity.*. ממשקי ה-API האלה מאפשרים למפתחי אפליקציות לאחסן ולאחזר מסמכים שמזהים את המשתמשים. הטמעות במכשיר:

[C-SR-1] מומלץ מאוד להטמיע את מערכת אישורי הזהות.

אם הטמעות של מכשירים מטמיעות את מערכת פרטי הזהות, הן:

‫[C-1-1] הפונקציה חייבת להחזיר ערך שאינו null עבור השיטה IdentityCredentialStore#getInstance().
‫[C-1-2] חובה להטמיע את מערכת אישורי הזהות (למשל, ממשקי ה-API של android.security.identity.*) באמצעות קוד שמתקשר עם אפליקציה מהימנה באזור שמבודד בצורה מאובטחת מהקוד שפועל בקרנל ומעליו. בידוד מאובטח חייב לחסום את כל המנגנונים הפוטנציאליים שבאמצעותם קוד במצב ליבה או במרחב משתמשים יכול לגשת למצב הפנימי של הסביבה המבודדת, כולל DMA.
‫[C-1-3] הפעולות הקריפטוגרפיות שנדרשות להטמעה של מערכת אישורי הזהות (למשל, ממשקי ה-API‏ android.security.identity.*) חייבות להתבצע באופן מלא באפליקציה המהימנה, וחומר המפתח הפרטי אסור לעולם לצאת מסביבת ההפעלה המבודדת, אלא אם נדרש אחרת באופן ספציפי על ידי ממשקי API ברמה גבוהה יותר (למשל, השיטה createEphemeralKeyPair()).
‫[C-1-4] האפליקציה המהימנה חייבת להיות מיושמת באופן שלא ישפיע על מאפייני האבטחה שלה (לדוגמה, נתוני אישורים לא ישוחררו אלא אם יתקיימו תנאי בקרת הגישה, לא ניתן יהיה ליצור קודי אימות הודעות (MAC) עבור נתונים שרירותיים) גם אם מערכת Android מתנהגת בצורה לא תקינה או שנפרצה.

פרויקט הקוד הפתוח של Android מספק הטמעה לדוגמה של אפליקציה מהימנה (libeic) שאפשר להשתמש בה כדי להטמיע את מערכת פרטי הזהות.

‫9.12. מחיקת נתונים

כל ההטמעות במכשירים:

‫[C-0-1] חובה לספק למשתמשים מנגנון לביצוע 'איפוס לנתוני היצרן'.
‫[C-0-2] חובה למחוק את כל הנתונים במערכת הקבצים של נתוני המשתמש כשמבצעים 'איפוס לנתוני היצרן'.
‫[C-0-3] חובה למחוק את הנתונים באופן שעומד בתקנים רלוונטיים בתעשייה, כמו NIST SP800-88, כשמבצעים 'איפוס להגדרות היצרן'.
‫[C-0-4] חובה להפעיל את התהליך 'איפוס להגדרות היצרן' שצוין למעלה כשמתבצעת קריאה ל-API של DevicePolicyManager.wipeData() על ידי אפליקציית בקר מדיניות המכשיר של המשתמש הראשי.
יכול להיות שתהיה אפשרות למחיקת נתונים מהירה שמבצעת רק מחיקה לוגית של נתונים.

‫9.13. מצב הפעלה בטוח

‫Android מספקת מצב אתחול בטוח, שמאפשר למשתמשים לאתחל למצב שבו רק אפליקציות מערכת שהותקנו מראש יכולות לפעול וכל אפליקציות הצד השלישי מושבתות. במצב הזה, שנקרא 'מצב אתחול בטוח', המשתמש יכול להסיר אפליקציות צד שלישי שעלולות להזיק.

הטמעות במכשיר:

‫[C-SR-1] מומלץ מאוד להטמיע מצב אתחול בטוח.

אם הטמעות המכשיר מטמיעות מצב הפעלה בטוח, הן:

‫[C-1-1] חובה לספק למשתמש אפשרות להיכנס למצב הפעלה בטוחה באופן שלא ניתן להפריע לו מאפליקציות צד שלישי שמותקנות במכשיר, אלא אם אפליקציית הצד השלישי היא בקר מדיניות מכשיר והיא הגדירה את הדגל UserManager.DISALLOW_SAFE_BOOT כ-true.
‫[C-1-2] המכשיר חייב לספק למשתמש את האפשרות להסיר כל אפליקציה של צד שלישי במצב בטוח.
צריך לספק למשתמש אפשרות להיכנס למצב אתחול בטוח מתפריט האתחול באמצעות תהליך עבודה ששונה מזה של אתחול רגיל.

‫9.14. בידוד של מערכות ברכב

מכשירים עם Android Automotive אמורים להחליף נתונים עם מערכות משנה קריטיות ברכב באמצעות vehicle HAL כדי לשלוח ולקבל הודעות ברשתות הרכב, כמו CAN bus.

אפשר לאבטח את חילופי הנתונים באמצעות הטמעה של תכונות אבטחה מתחת לשכבות של מסגרת Android, כדי למנוע אינטראקציה זדונית או לא מכוונת עם מערכות המשנה האלה.

‫9.15. תוכניות מינויים

'תוכניות מנויים' מתייחסות לפרטי תוכנית הקשר לחיוב שספק סלולרי מספק דרך SubscriptionManager.setSubscriptionPlans().

כל ההטמעות במכשירים:

‫[C-0-1] חובה להחזיר תוכניות מינוי רק לאפליקציה של ספק הסלולר שסיפק אותן במקור.
‫[C-0-2] אסור לגבות מרחוק או להעלות תוכניות מינוי.
‫[C-0-3] חובה לאפשר רק שינויים, כמו SubscriptionManager.setSubscriptionOverrideCongested(), מאפליקציית ספק סלולר שמספקת כרגע חבילות מינוי תקפות.

‫9.16. Application Data Migration

אם הטמעות של מכשירים כוללות יכולת להעביר נתונים ממכשיר אחד למכשיר אחר, ולא מגבילות את נתוני האפליקציה שהן מעתיקות רק למה שהוגדר על ידי מפתח האפליקציה במניפסט באמצעות המאפיין android:fullBackupContent, הן:

‫[C-1-1] אסור ליזום העברות של נתוני אפליקציה ממכשירים שבהם המשתמש לא הגדיר אימות ראשי כפי שמתואר בקטע 9.11.1 נעילת מסך מאובטחת ואימות.
‫[C-1-2] חובה לאשר באופן מאובטח את האימות הראשי במכשיר המקור ולאשר את כוונת המשתמש להעתקת הנתונים במכשיר המקור לפני העברת הנתונים.
‫[C-1-3] חובה להשתמש באימות (attestation) של מפתח אבטחה כדי לוודא שמכשיר המקור ומכשיר היעד בהעברה ממכשיר למכשיר הם מכשירי Android לגיטימיים, ושתוכנת האתחול שלהם נעולה.
‫[C-1-4] חובה להעביר נתוני אפליקציה רק לאותה אפליקציה במכשיר היעד, עם אותו שם חבילה ואותו אישור חתימה.
‫[C-1-5] בתפריט ההגדרות חייבת להיות אינדיקציה לכך שבוצעה מיגרציה של נתונים ממכשיר למכשיר במכשיר המקור. אסור לאפשר למשתמש להסיר את הסימן הזה.

‫9.17. Android Virtualization Framework

ממשקי ה-API של Android Virtualization Framework‏ (AVF) (android.system.virtualmachine.*) מאפשרים לאפליקציות ליצור מכונות וירטואליות (VM) במכשיר, מוגנות (pVM) ולא מוגנות (non-pVM), שנטענות ומריצות קבצים בינאריים מקוריים כמטענים ייעודיים (payloads).

אם הטמעות המכשיר מגדירות את FEATURE_VIRTUALIZATION_FRAMEWORK ל-true: הן:

‫[C-1-1] חובה לוודא שהפונקציה android.system.virtualmachine.VirtualMachineManager.getCapabilities() מחזירה אחת מהאפשרויות הבאות:
- CAPABILITY_PROTECTED_VM
- CAPABILITY_NON_PROTECTED_VM
- CAPABILITY_NON_PROTECTED_VM | CAPABILITY_PROTECTED_VM

‫9.18. אימות מפתח

הטמעות של מכשירים שמצהירות על רמת API‏ 36.1 ומעלה:

יכול להיות שהיא תכלול תמיכה בשירות לאימות מפתחים, כדי לאשר שאפליקציות מגיעות ממפתח מוכר.

הטמעות של מכשירים שמצהירות על רמת API‏ 36.1 ומעלה ומגדירות מאמת למפתחים על ידי הגדרה של config_developerVerificationServiceProviderPackageName ב-config.xml:

‫[9.18/C-1-1] חובה להפעיל את ההגדרה android.content.pm.verify.developer.DeveloperVerifierService לכל התקנה של חבילת אפליקציות, כולל התקנות חדשות ועדכונים של אפליקציות קיימות.

הטמעות של מכשירים שמצהירות על רמת API‏ 36.1 ומעלה:

יכול להיות שיהיה צורך להגדיר נציג להגדרת המדיניות הפעילה על ידי הגדרת config_developerVerificationPolicyDelegatePackageName ב-config.xml.

אם מוגדר מאמת מפתחים, ההטמעות במכשיר:

‫[9.18/C-2-1] חובה לאפשר רק למאמת המפתחים או לנציג המוגדר שלו להגדיר את מדיניות ההתקנה כפי שמוגדר ב-android.content.pm.PackageInstaller.

אם מאמת מופעל כחלק מהפעלת התקנת חבילה, הטמעות של מכשירים:

‫[9.18/C-3-1] חובה למנוע את ההתקנה של חבילת אפליקציה אם:
- ההתקנה נכשלת בגלל אימות הזהות של המפתח.
- מדיניות אימות המפתחים לסשן ההתקנה מוגדרת לכל ערך מלבד DEVELOPER_VERIFICATION_POLICY_NONE.
- אלא אם חלים סעיף 9.18/C-3-2 או סעיף 9.18/C-3-3.

‫[9.18/C-3-2] אסור למנוע את ההתקנה של חבילת אפליקציה, ללא קשר למדיניות או לסטטוס האימות, במקרים הבאים:
- החבילה מותקנת דרך ממשק הגישור של Android‏ (ADB).
- החבילה היא מאמת המפתחים שהוגדר או קובץ ההתקנה שלו.

‫[9.18/C-3-3] אסור למנוע את ההתקנה של חבילת אפליקציות אם כל התנאים הבאים מתקיימים:
- המדיניות מוגדרת לערך DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_WARN או DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_OPEN.
- האימות מדווח כלא הושלם.
- התוכנה להתקנה מציינת שהמשתמש ביקש במפורש להמשיך בהתקנה על ידי דיווח על DEVELOPER_VERIFICATION_USER_RESPONSE_INSTALL_ANYWAY.

יכולה לאפשר התקנה של חבילת אפליקציה ללא קשר למדיניות או לסטטוס האימות של התקנות שהופעלו על ידי בעלי המכשיר במכשיר מנוהל או על ידי בעלי הפרופיל בפרופיל מנוהל, אבל מומלץ מאוד למנוע התקנות כמו שמתואר בסעיף 9.18/C-3-1.

10. בדיקת תאימות של תוכנה

הטמעות במכשירים חייבות לעבור את כל הבדיקות שמתוארות בקטע הזה. עם זאת, חשוב לזכור שאין חבילת בדיקות תוכנה מקיפה לחלוטין. לכן, מומלץ מאוד למפתחים של מכשירים לבצע את המספר המינימלי האפשרי של שינויים בהטמעה המועדפת של Android שזמינה מ-פרויקט קוד פתוח של Android. כך אפשר לצמצם את הסיכון להחדרת באגים שיוצרים חוסר תאימות, שדורש עבודה מחדש ועדכונים פוטנציאליים של המכשיר.

10.1. חבילה לבדיקות תאימות (CTS)

הטמעות במכשיר:

‫[C-0-1] המכשיר חייב לעבור את חבילת בדיקות התאימות של Android‏ (CTS) שזמינה מ-Android Open Source Project, באמצעות תוכנת המשלוח הסופית במכשיר.
‫[C-0-2] חובה לוודא תאימות במקרים של דו-משמעות ב-CTS ובכל הטמעה מחדש של חלקים מקוד המקור של ההפניה.

ה-CTS מיועד להרצה במכשיר בפועל. בדומה לכל תוכנה, יכול להיות שה-CTS עצמו מכיל באגים. מערכת ה-CTS תהיה בגרסה נפרדת מהגדרת התאימות הזו, ויכול להיות שיפורסמו כמה עדכונים של ה-CTS ל-Android 17.

הטמעות במכשיר:

‫[C-0-3] המכשיר חייב לעבור את הגרסה העדכנית ביותר של CTS שזמינה בזמן השלמת התוכנה של המכשיר.
מומלץ להשתמש בהטמעה לדוגמה בעץ של Android Open Source כמה שיותר.

10.2. CTS Verifier

הכלי CTS Verifier כלול בחבילת בדיקות התאימות (CTS), והוא מיועד להפעלה על ידי מפעיל אנושי כדי לבדוק פונקציונליות שלא ניתן לבדוק באמצעות מערכת אוטומטית, כמו פעולה תקינה של מצלמה וחיישנים.

הטמעות במכשיר:

‫[C-0-1] חובה להריץ בצורה נכונה את כל המקרים הרלוונטיים בכלי לאימות CTS.

ב-CTS Verifier יש בדיקות להרבה סוגים של חומרה, כולל חומרה שהיא אופציונלית.

הטמעות במכשיר:

‫[C-0-2] המכשיר חייב לעבור את כל הבדיקות של החומרה שקיימת בו. לדוגמה, אם במכשיר יש מד תאוצה, הוא חייב לבצע בצורה תקינה את תרחיש הבדיקה של מד התאוצה ב-CTS Verifier.

אפשר לדלג על תרחישי בדיקה של תכונות שמסומנות כאופציונליות במסמך הזה של הגדרת התאימות, או להשמיט אותם.

‫[C-0-2] כל מכשיר וכל גרסת build חייבים להריץ את CTS Verifier בצורה תקינה, כפי שצוין למעלה. עם זאת, מכיוון שהרבה גרסאות דומות מאוד, לא מצפים ממפתחי מכשירים להריץ במפורש את CTS Verifier בגרסאות ששונות רק בפרטים שוליים. בפרט, הטמעות במכשירים ששונות מהטמעה שעברה את CTS Verifier רק בסט של הלוקאלים, המיתוג וכו' הכלולים, יכולות להשמיט את הבדיקה של CTS Verifier.

11. תוכנות שניתנות לעדכון

‫[C-0-1] הטמעות של מכשירים חייבות לכלול מנגנון להחלפה של כל תוכנת המערכת. המנגנון לא צריך לבצע שדרוגים 'בזמן אמת' – כלומר, יכול להיות שתידרש הפעלה מחדש של המכשיר. אפשר להשתמש בכל שיטה, בתנאי שהיא יכולה להחליף את כל התוכנה שהותקנה מראש במכשיר. לדוגמה, כל אחת מהגישות הבאות תעמוד בדרישה הזו:
- הורדות 'דרך האוויר' (OTA) עם עדכון אופליין באמצעות הפעלה מחדש.
- עדכונים 'קשורים' דרך USB ממחשב מארח.
- עדכונים במצב אופליין באמצעות הפעלה מחדש ועדכון מקובץ באחסון נייד.
‫[C-0-2] מנגנון העדכון שבו נעשה שימוש חייב לתמוך בעדכונים בלי למחוק את נתוני המשתמש. כלומר, מנגנון העדכון חייב לשמור על נתונים פרטיים של האפליקציה ועל נתונים משותפים של האפליקציה. שימו לב שתוכנת Android במעלה הזרם כוללת מנגנון עדכון שעומד בדרישה הזו.
‫[C-0-3] כל העדכון חייב להיות חתום, ומנגנון העדכון במכשיר חייב לאמת את העדכון והחתימה מול מפתח ציבורי שמאוחסן במכשיר.
‫[C-SR-1] מומלץ מאוד שמנגנון החתימה יגבב את העדכון באמצעות SHA-256 ויאמת את הגיבוב מול המפתח הציבורי באמצעות ECDSA NIST P-256.

אם ההטמעות במכשיר כוללות תמיכה בחיבור נתונים ללא הגבלה, כמו פרופיל 802.11 או Bluetooth PAN (רשת אישית), אז:

‫[C-1-1] חובה לתמוך בהורדות של OTA עם עדכון אופליין באמצעות הפעלה מחדש.

הטמעות של מכשירים צריכות לוודא שקובץ האימג' של המערכת זהה בינארית לתוצאה הצפויה אחרי OTA. ההטמעה של OTA מבוסס-בלוק בפרויקט הקוד הפתוח של Android (בגרסה שנוספה מאז Android 5.1) עומדת בדרישה הזו.

בנוסף, הטמעות של מכשירים צריכות לתמוך בעדכוני מערכת מסוג A/B. ב-AOSP, התכונה הזו מיושמת באמצעות boot control HAL.

אם נמצאה שגיאה בהטמעה של מכשיר אחרי שהוא הושק, אבל במסגרת משך החיים הסביר של המוצר שנקבע בהתייעצות עם צוות התאימות של Android, והשגיאה משפיעה על התאימות של אפליקציות של צד שלישי, אז:

‫[C-2-1] המפתח של המכשיר חייב לתקן את השגיאה באמצעות עדכון תוכנה שזמין להחלה בהתאם למנגנון שמתואר למעלה.

‫Android כולל תכונות שמאפשרות לאפליקציה של בעל המכשיר (אם היא קיימת) לשלוט בהתקנה של עדכוני מערכת. אם מערכת המשנה לעדכוני מערכת במכשירים מדווחת על android.software.device_admin, אז:

‫[C-3-1] חובה להטמיע את ההתנהגות שמתוארת במחלקה SystemUpdatePolicy.

12. יומן שינויים של מסמך

החל מ-Android 16, אין יומן שינויים שמתעדכן בנפרד. כל השינויים מהגרסה הקודמת מודגשים במסמך הזה.

13. צור קשר

אתם יכולים להצטרף לפורום התאימות של Android ולבקש הבהרות או להעלות בעיות שלדעתכם לא מפורטות במסמך.

הגדרת התאימות של Android 17 קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

1. מבוא

‫1.1 מבנה המסמך

1.1.1. דרישות לפי סוג המכשיר

‫1.1.2. מזהה הדרישה

‫1.1.3. מזהה הדרישה בחלק 2

2. סוגי מכשירים

‫2.1 הגדרות במכשירים

2.2. דרישות לגבי מכשירים ניידים

2.2.1. חומרה

2.2.2. מולטימדיה

2.2.3. תוכנה

‫2.2.4. ביצועים וצריכת חשמל

2.2.5. מודל אבטחה

הגדרות מוגבלות

2.2.6. תאימות של כלים ואפשרויות למפתחים

2.2.7. Handheld Media Performance Class

2.2.7.1. מדיה

2.2.7.2. מצלמה

2.2.7.3. חומרה

‫2.2.7.4. ביצועים

‫2.2.7.5. גרפיקה

2.3. דרישות לגבי טלוויזיות

2.3.1. חומרה

‫2.3.2. מולטימדיה

2.3.3. תוכנה

‫2.3.4. ביצועים וצריכת חשמל

‫2.3.5. מודל אבטחה

2.3.6. תאימות של כלים ואפשרויות למפתחים

2.4. דרישות לצפייה

2.4.1. חומרה

2.4.2. מולטימדיה

2.4.3. תוכנה

‫2.4.4. ביצועים וצריכת חשמל

‫2.4.5. מודל אבטחה

2.5. דרישות בתחום הרכב

2.5.1. חומרה

2.5.2. מולטימדיה

‫2.5.3. תוכנה

‫2.5.4. ביצועים וצריכת חשמל

‫2.5.5. מודל אבטחה

2.5.6. תאימות של כלים ואפשרויות למפתחים

2.6. הדרישות לטאבלטים

2.6.1. חומרה

2.6.2. מודל אבטחה

2.6.2. תוכנה

3. תוכנה

3.1. תאימות מנוהלת של API

3.1.1. תוספים ל-Android

3.1.2. ספריית Android

3.2. תאימות API רכה

3.2.1. הרשאות

3.2.2. פרמטרים של Build

‫3.2.3. תאימות לכוונת החיפוש

3.2.3.1. כוונות נפוצות באפליקציות

‫3.2.3.2. החלטה לגבי Intent

‫3.2.3.3. מרחבי שמות של כוונות

‫3.2.3.4. כוונות לשידור

‫3.2.3.5. הפעלת כוונות מותנית באפליקציות

‫3.2.4. פעילויות במסכים משניים או במספר מסכים

‫3.3. תאימות ל-API מקורי

3.3.1. Application Binary Interfaces

3.3.2. תאימות קוד מקורי של ARM בגרסת 32 ביט

3.4. תאימות לאינטרנט

3.4.1. תאימות ל-WebView

‫3.4.2. תאימות לדפדפנים

3.5. תאימות התנהגותית של API

3.5.1. הגבלת אפליקציות

3.5.2. מצב תנומה של אפליקציות

3.6. API Namespaces

3.7. תאימות בזמן ריצה

‫3.8. תאימות ממשק משתמש

3.8.1. מרכז האפליקציות (מסך הבית)

3.8.2. ווידג'טים

‫3.8.3. התראות

3.8.3.1. הצגת התראות

‫3.8.3.2. שירות מאזין להתראות

‫3.8.3.3. מצב DND (נא לא להפריע) / מצב עדיפות

‫3.8.3.4. הגנה על התראות רגישות

‫3.8.4. Assist APIs

הגדרת התאימות של Android 17