הוספת תמיכה ב-Android Automotive OS לאפליקציה שמוגדרת במצב 'חניה'

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

בדיקת האפליקציה הקיימת במהדמ של Android Automotive OS

כדי להתחיל לפתח אפליקציה ל-Android Automotive OS, קודם צריך לבדוק את האפליקציה הקיימת במהדמ של Android Automotive OS. כדי להגדיר אמולטור, פועלים לפי השלבים המפורטים בקטע בדיקה באמצעות אמולטור של Android Automotive OS. לאחר מכן תוכלו להריץ את האפליקציה לפי ההוראות במאמר הפעלת האפליקציה במהדמה.

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

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

הגדרת קובץ המניפסט של האפליקציה

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

תכונות נדרשות של Android Automotive OS

כל האפליקציות שנוצרו ל-Android Automotive OS צריכות לעמוד בדרישות מסוימות כדי שאפשר יהיה להפיץ אותן באמצעות Google Play. למידע נוסף, ראו דרישות התכונות של Google Play.

רשומות מניפסט ספציפיות לקטגוריה

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

עמידה בדרישות בנושא הסחת דעת של נהגים

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

מניעת שימוש בזמן שההגבלות על חוויית המשתמש פעילות

כברירת מחדל, אי אפשר להשתמש בפעילויות או להפעיל אותן כשההגבלות על חוויית המשתמש פעילות. כדי לוודא שההתנהגות הזו חלה על האפליקציה, אסור לכלול את הרכיב <meta-data> הבא באף רכיב <activity> במניפסט:

<!-- NOT ALLOWED -->
<meta-data
  android:name="distractionOptimized"
  android:value="true"/>

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

לכל הפחות, הפעילות של האפליקציה תעבור למצב מחזור חיים 'בהשהיה'. האירוע הזה מתרחש כקריאה חוזרת ל-onPause() במחזור החיים, שבמהלכה צריך להשהות את ההפעלה של הווידאו והאודיו באפליקציה.

במכשירים שכוללים את מצב התאימות ל-Android Automotive OS, החסימה של המערכת גורמת לפעילויות של האפליקציה לעבור ממצב השהיה למצב עצירה.

עצירת ההפעלה ומניעת המשך ההפעלה

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

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

הקשבה להגבלות על חוויית המשתמש

כדי להאזין להגבלות על חוויית המשתמש, קודם צריך להוסיף יחסי תלות לספרייה android.car בקובץ build.gradle של מודול האפליקציה. זהו תוסף ל-Android SDK שמספק ממשקי API ספציפיים ל-Android Automotive OS.

android {
    ...
    useLibrary("android.car")
}

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

val car = Car.createCar(context)
val carUxRestrictionsManager =
    car.getCarManager(Car.CAR_UX_RESTRICTION_SERVICE) as CarUxRestrictionsManager

// You can either read the state directly ...
val currentUxRestrictions = carUxRestrictionsManager.currentUxRestrictions

// or listen to state changes
carUxRestrictionsManager.registerListener { carUxRestrictions: CarUxRestrictions -> ...}

// Don't forget to teardown and release resources when they're no longer needed
carUxRestrictionsManager.unregisterListener()
car.disconnect()

הערך היחיד ש-CarUxRestrictions מספק והאפליקציה צריכה להפנות אליו הוא ערך ההחזרה של isRequiresDistractionOptimization(). ערכים אחרים רלוונטיים רק לפעילויות שמסומנות כפעילויות שעברו אופטימיזציה להפחתת הסחות דעת.

בדיקה מעשית של ההטמעה

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

  1. התקנת האפליקציה בקובץ אימג' של מערכת בלי חנות Google Play או מצב תאימות.
  2. כשמרשת האפליקציות במרכז האפליקציות פתוחה, מבצעים סימולציה של נסיעה ומוודאים שלא ניתן לפתוח את האפליקציה.
  3. מפסיקים את הדמיית הנסיעה, פותחים את האפליקציה במסך ההפעלה ומתחילים להפעיל אותה.
  4. מפעילים שוב את הדמיית הנסיעה ומוודאים שההפעלה מושהית.
    1. אם האפליקציה תומכת בשילוב עם MediaSession, צריך להשתמש ב-adb shell cmd media_session dispatch play ולוודא שההפעלה לא מתחדשת.

אופטימיזציה של האפליקציה ל-Android Automotive OS

כדי לספק למשתמשים את חוויית השימוש הטובה ביותר ברכב, כדאי לזכור את הדברים הבאים כשאתם מפתחים אפליקציה ל-Android Automotive OS:

עבודה עם חלונות מוטמעים וחיתוך מסך

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

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

שורת הסטטוס, מצב צפייה היקפי ורינדור מקצה לקצה

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

בנוסף, מערכת ההפעלה Android Automotive OS מאפשרת ליצרני ציוד מקורי לקבוע אם אפליקציות יכולות להציג או להסתיר את שורת הסטטוסים כדי להיכנס ולצאת ממצב immersive. לדוגמה, על ידי מניעת האפשרות של אפליקציות להסתיר את סרגלי המידע, יצרני ציוד מקורי יכולים להבטיח שתמיד תהיה גישה למסך של אמצעי הבקרה ברכב, כמו אמצעי הבקרה על האקלים. אם יצרן ציוד מקורי (OEM) מנע מאפליקציות לשלוט בסרגלי המערכת, לא קורה כלום כשאפליקציה קוראת לממשקי ה-API של WindowInsetsController (או WindowInsetsControllerCompat) כדי להציג או להסתיר את סרגי המערכת. במסמכי העזרה של show ו-hide מוסבר איך לזהות אם האפליקציה הצליחה לשנות את הרכיבים הפנימיים.

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

<!-- Depending on OEM configuration, these style declarations
     (and the corresponding runtime calls) may be ignored -->
<style name="...">
  <item name="android:statusBarColor">...</item>
  <item name="android:navigationBarColor">...</item>
  <item name="android:windowTranslucentStatus">...</item>
  <item name="android:windowTranslucentNavigation">...</status>
</style>

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

התאמה למסכים בעלי צורה לא סדירה

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

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

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

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

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

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

השבתת תכונות

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

אפשר להשתמש ב-API‏ PackageManager.hasSystemFeature כדי לזהות אם האפליקציה פועלת ב-Android Automotive OS. לשם כך, בודקים את המאפיין FEATURE_AUTOMOTIVE, כפי שמתואר בדוגמה הבאה:

Kotlin

val packageManager: PackageManager = ... // Get a PackageManager from a Context
val isCar = packageManager.hasSystemFeature(PackageManager.FEATURE_AUTOMOTIVE)
if (isCar) {
  // Enable or disable a given feature
}

Java

PackageManager packageManager = ... // Get a PackageManager from a Context
boolean isCar = packageManager.hasSystemFeature(PackageManager.FEATURE_AUTOMOTIVE)
if (isCar) {
  // Enable or disable a given feature
}

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

לגבי התכונה 'תמונה בתוך תמונה' (PiP), פועלים לפי השיטות המומלצות כדי לבדוק אם התכונה זמינה ולפעול בהתאם.

טיפול בתרחישים אופליין

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

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

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

שימוש במשאבים חלופיים

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