בנוסף לתמיכה באפליקציות שנוצרו לשימוש בזמן נהיגה, מערכת ההפעלה 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, אפליקציות תואמות עוברות תהליך בדיקה ידני כדי לוודא שהן בטוחות לשימוש ברכב. פרטים נוספים זמינים במאמר חלוקה למכוניות.
תכונות נדרשות של Android Automotive OS
כדי להופיע ב-Play Store ברכב, אפליקציות שנוצרו ל-Android Automotive OS חייבות לכלול את הרכיב <uses-feature> בקובץ AndroidManifest.xml עבור התכונה android.hardware.type.automotive:
<manifest ...> ... <!-- Depending on the track you choose to distribute your app, the android:required attribute can also be "false" or left unset. See Choose a track for Android Automotive OS. --> <uses-feature android:name="android.hardware.type.automotive" android:required="[true|false]" /> ... </manifest>
בנוסף לרכיב שמוצג בדוגמת הקוד הקודמת, אפליקציות שנוצרו ל-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, שבמהלכה צריך להשהות את הפעלת הווידאו והאודיו מהאפליקציה.
רשומות מניפסט ספציפיות לקטגוריה
בנוסף לדרישות הקודמות, שחלות על כל האפליקציות שמוגדרות כ'בהמתנה', יש דרישות נוספות לקטגוריות 'סרטונים' ו'משחקים':
- לגבי אפליקציות וידאו, אפשר לעיין במאמר סימון האפליקציה כאפליקציית וידאו.
- למשחקים, אפשר לעיין במאמר סימון האפליקציה כמשחק.
אופטימיזציה של האפליקציה ל-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 מוסבר איך לזהות אם האפליקציה הצליחה לשנות את הרכיבים הפנימיים.
כמו כן, יצרני ציוד מקורי יכולים לקבוע אם אפליקציות יכולות להגדיר את הצבע והשקיפות של סרחי המערכת, כדי לוודא שהסרחים והרכיבים שבתוכם יהיו גלויים תמיד. אם האפליקציה שלכם תוצג מקצה לקצה, ודאו שרק תוכן לא קריטי מוצג מאחורי שורת המשימות. יכול להיות שהתוכן הזה לא יוצג אם יצרן הציוד המקורי של המכשיר מונע הגדרה של הצבע או השקיפות של העמודות.
<!-- 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: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, או שיצרן ציוד מקורי משבית את ה-Wi-Fi לטובת רשת סלולרית.
חשוב להתכונן לתרחישים האלה באפליקציה שלכם על ידי הפחתה הדרגתית של הפונקציונליות שתלויה בגישה לאינטרנט, למשל על ידי הצעת תוכן אופליין. מידע נוסף זמין במאמר שיטות מומלצות לביצוע אופטימיזציה של הרשת.
שימוש במשאבים חלופיים
כדי להתאים את האפליקציה לשימוש ברכב, אפשר להשתמש במסנן המשאבים car כדי לספק משאבים חלופיים כשהאפליקציה פועלת ברכב עם Android Automotive OS. לדוגמה, אם אתם משתמשים במשאבי מאפיינים כדי לאחסן ערכים של הוספת רווח, תוכלו להשתמש בערך גדול יותר לקבוצת המשאבים car כדי להגדיל את יעדי המגע.
הפצת האפליקציה
אחרי שבודקים את האפליקציה בהתאם להנחיות האיכות לאפליקציות לרכב לפי הקטגוריה שלה, אפשר להשתמש ב-Google Play כדי להפיץ אותה לרכב עם Google מובנית. לפרטים נוספים על תהליך הפרסום, אפשר לעיין במאמר הפצה לרכבים.
שליחת משוב על אפליקציות שמושהות
אם נתקלתם בבעיה או אם יש לכם בקשה להוספת תכונה במהלך הפיתוח של האפליקציה המושהית ל-Android Automotive OS, תוכלו לדווח על כך באמצעות Google Issue Tracker. חשוב למלא את כל המידע הנדרש בתבנית הדיווח על הבעיה. לפני שמדווחים על בעיה חדשה, כדאי לבדוק אם היא כבר דווחה ברשימת הבעיות. כדי להירשם ולצבוע בעד בעיות, לוחצים על הכוכב של הבעיה במעקב. מידע נוסף זמין במאמר הרשמה לבעיה.