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

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

בדיקת האפליקציה הקיימת באמצעות אמולטור Android Automotive OS

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

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

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

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

עבודה עם insets וחותכים של מסכים במסך

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

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

עמודות מערכת, מצב עשיר ורינדור מקצה לקצה

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

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

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