בניית אפליקציות בהמתנה ל-Android Automotive OS

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

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

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

כדי לפרסם בחנות Play ברכב, אפליקציות שפותחו עבור Android Automotive OS חייב לכלול את <uses-feature> הבא בAndroidManifest.xml file:

<manifest ...>
    ...
    <uses-feature
        android:name="android.hardware.type.automotive"
        android:required="true" />
    ...
</manifest>

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

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

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

בנוסף לרכיב שמוצג בדוגמת הקוד הקודמת, אפליקציות שנוצרו ל-Android Automotive OS חייבות לכלול את הרכיבים הבאים של <uses-feature> ברכיב הבסיס <manifest>:

<uses-feature
  android:name="android.hardware.wifi"
  android:required="false"/>
<uses-feature
  android:name="android.hardware.screen.portrait"
  android:required="false"/>
<uses-feature
  android:name="android.hardware.screen.landscape"
  android:required="false"/>

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

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

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

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

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

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

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

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

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

אופטימיזציה למסכים גדולים

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

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

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

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

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

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

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

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

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

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

<!-- 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 לרכבים.

אפשר להשתמש בPackageManager.hasSystemFeature API לזיהוי אם האפליקציה פועלת ב-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 כדי ליצור משטחי מגע גדולים יותר.

הפצת האפליקציה

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

שליחת משוב על אפליקציות בהמתנה

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

דיווח על בעיה חדשה