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

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

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

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

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

עמידה בדרישות בנושא הסחת דעת הנהג (DD)

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

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

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

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

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

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

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

הפסקת ההפעלה ומניעת הפעלה מחדש

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

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

האזנה למגבלות של חוויית המשתמש

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

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

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

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

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

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

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

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

בדיקת ההטמעה

כדי לוודא שהאפליקציה עומדת בדרישות בנושא הסחת דעת הנהג (DD):

  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 מאפשרת ליצרני ציוד מקורי (OEM) לקבוע אם אפליקציות יכולות להציג או להסתיר את סרגלי המידע כדי להיכנס למצב אימרסיבי ולצאת ממנו. לדוגמה, אם מונעים מאפליקציות להסתיר את סרגלי המידע, יצרני הציוד המקורי יכולים להבטיח שאמצעי הבקרה של הרכב, כמו בקרת האקלים, תמיד יהיו נגישים במסך. אם יצרן ציוד מקורי (OEM) מנע מאפליקציות לשלוט בסרגלי המידע, לא קורה כלום כשאפליקציה קוראת לממשקי ה-API של WindowInsetsController (או WindowInsetsControllerCompat) כדי להציג או להסתיר את סרגלי המידע. כדי לדעת אם האפליקציה הצליחה לשנות את ה-insets, אתם יכולים לעיין במסמכי התיעוד של show ו-hide.

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

<!-- 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 קיימת, כמו בדוגמה הבאה:

val 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 לטובת רשת סלולרית.

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

שימוש במקורות חלופיים

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