הוספת תמיכה ב-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.

מוודאים שאין פעילויות שמתמקדות בהסחת דעת

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

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

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

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

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

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

אופטימיזציה של האפליקציה ל-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, או שיצרן ציוד מקורי (OEM) משבית את ה-Wi-Fi לטובת רשת סלולרית.

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

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

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