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

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

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

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

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

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

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

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

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

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

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

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

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

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

הסבר על המגבלות של חוויית המשתמש (UX)

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

בדיקת ההטמעה

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

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

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

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

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