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

שלום לכולם.

תודה רבה שהצטרפתם אלינו לסשן הזה בנושא ניווט באיכות של אפליקציות שמותאמות למכשירים שונים ופרסום ב-Google Play לגורמי צורה שהם לא ניידים.

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

ואני פאוסטין ליאו, מנהלת תפעול בצוות לנושאי מהימנות ובטיחות ב-Play.

אנחנו שמחים שכולם כאן איתנו היום.

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

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

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

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

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

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

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

נתחיל מהבסיס: איך לתכנן את הארכיטקטורה של האפליקציה ולארוז אותה.

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

האם אתם יוצרים קובץ App Bundle אחד ומאוחד שמכיל את כל מה שצריך לכל הפלטפורמות שבהן אתם תומכים, או שאתם מחלקים את האפליקציה למודולים ספציפיים לפלטפורמה ויוצרים קובצי Android App Bundle‏ (AAB) לכל אחד מהם?

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

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

לכן, למרות שגישה מאוחדת של Android App Bundle עשויה להיראות פשוטה יותר לניהול, אנחנו ממליצים על הגישה המודולרית.

הנה דוגמה שממחישה למה אנחנו ממליצים על הגישה המודולרית הזו.

נניח שיש לכם אפליקציה שמתאימה גם לנייד וגם ל-Android TV.

אם תשלחו קובץ Android App Bundle אחד במסלול ההפצה הרגיל לנייד, והאפליקציה ל-Android TV תיכשל בבדיקה, כל ההפצה תיעצר.

לכן, זה ישפיע גם על ההשקה של האפליקציה ל-Android TV וגם על ההשקה של האפליקציה לנייד.

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

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

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

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

הגרסה של האפליקציה לנייד תפורסם כמתוכנן.

כמו שציינתי קודם, יש הרבה גישות למודולריזציה.

הנה דוגמה אחת לגישה למודולריזציה של אפליקציית ספרי אודיו שיש לה ממשק לנייד וממשק ל-Android Automotive OS.

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

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

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

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

...

rootProject.name = "MultiFormFactorApp"

// Define modules for each form factor
include(":app:automotive")
include(":app:mobile")
include(":core:network")
include(":data:books")
include(":data:reviews")
include(":feature:home")
include(":feature:player")
include(":feature:reviews")

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

הגישה המודולרית הזו קשורה ישירות לאסטרטגיית המסלולים שלכם ב-Play Console.

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

ב-Android TV, ב-Android XR וב-Android Automotive OS, יש לכם אפשרות לבחור.

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

עם זאת, יש שני מקרים חריגים.

ב-Wear OS, צריך להשתמש במסלול הייעודי של Wear OS.

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

אם אתם מנהלים כמה מסלולים, ניהול הגרסאות הוא קריטי.

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

לדוגמה, 01 לנייד, 02 ל-Wear OS,‏ 03 ל-Android Automotive OS וכן הלאה.

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

כך אפשר למנוע התנגשויות בין קודי גרסאות ב-Play Console.

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

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

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

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

לכן, בדיקה פנימית היא נקודת התחלה מצוינת.

היא מאפשרת להפיץ במהירות את האפליקציה לעד 100 בודקים, והכי חשוב – היא לא מפעילה בדיקה של Play.

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

בבדיקות פנימיות, תקבלו כתובת URL ייחודית שתוכלו לשתף עם הבודקים.

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

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

אתם יכולים לנהל את קבוצות הבדיקה הפנימית כרשימות של כתובות אימייל או באמצעות קבוצות Google.

לעומת זאת, בדיקה פתוחה לציבור מאפשרת לכם להריץ בדיקה עם קבוצה גדולה יותר ב-Google Play.

האפליקציה תהיה גלויה ב-Google Play, וכל אחד יוכל להצטרף לתוכנית הבדיקה הפתוחה.

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

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

זה בעצם יתרון עצום.

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

אז בואו נדבר קצת על תהליך הבדיקה, מה הוא כולל ולמה הוא חשוב.

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

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

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

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

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

שתי קבוצות ההנחיות האלה הן מקום מצוין להתחיל בו.

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

הבודקים שלנו יבדקו את האפליקציות שלכם במכשירים אמיתיים ובאמולטורים בהתאם להנחיות האלה.

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

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

אבל חשוב לזכור שהרשימה הזו לא כוללת את כל הנחיות האיכות לאפליקציות.

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

נתחיל עם Android TV.

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

אחת מהסיבות הנפוצות לדחיית אפליקציות ל-Android TV היא שחסרה תמונת באנר למסך הבית בכל שפה שהאפליקציה תומכת בה.

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

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

שנית, ברוב הטלוויזיות, המשתמשים יבצעו אינטראקציה עם המכשיר באמצעות שלט רחוק עם כפתורי החיצים (D-pad).

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

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

הסיבה הנפוצה השלישית לדחיית אפליקציות ל-Android TV היא שחסר מסנן Intent מסוג CATEGORY_LEANBACK_LAUNCHER בקובץ המניפסט של Android.

<application ...>
...
<activity
    android:name="com.example.TvActivity"
    android:label="@string/app_name"
    android:theme="@style/Theme.Leanback">
    <intent-filter>
      <action android:name=
           "android.intent.action.MAIN" />
      <category android:name=
           "Android.intent.category.
            LEANBACK_LAUNCHER" />
    </intent-filter>
  </activity>
</application>

המסנן הזה יזהה את האפליקציה שלכם כאפליקציה שמותאמת לטלוויזיה, ויאפשר ל-Google Play לזהות אותה כאפליקציית טלוויזיה גם למשתמשים.

כך, כשמשתמש בוחר את האפליקציה במסך הבית של הטלוויזיה, ה-intent הזה מזהה איזו פעילות להפעיל.

לכן חשוב לוודא שהוספתם אותו למניפסט.

‫Android XR הוא השלב הבא.

כשמפתחים אפליקציות למשקפי VR עם Android XR או למשקפי AR עם Android XR, חשוב לשים לב במיוחד לביצועים, לעיבוד (rendering) וליציבות של האפליקציות.

אתם יכולים להשתמש ב-Perfetto כדי ליצור פרופיל של ביצועי האפליקציות שנוצרו באמצעות Jetpack XR SDK, כדי לוודא שאתם עומדים בדרישות המינימליות של קצב הפריימים.

אם אתם משתמשים במנוע בזמן אמת כמו Unity, אתם יכולים להשתמש בכלי הפרופיילינג המובנים של המנוע כדי לוודא שאתם עומדים בדרישות הרינדור.

הקטגוריה הבאה היא רכבים, שכוללת גם את Android Auto וגם את Android Automotive OS.

ב-Android Auto וב-Android Automotive OS יש קטגוריות שהן ייחודיות לגורם הצורה הספציפי הזה.

רק אפליקציות מקטגוריות מסוימות יכולות להתפרסם בכלי רכב.

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

אני אסביר למה אני מתכוון.

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

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

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

אבל קטגוריות אחרות, כמו אפליקציות תקשורת לשיחות ב-Android Auto, נמצאות בגרסת בטא.

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

אפשר למצוא פרטים נוספים על כך ועל נושאים אחרים במדריכים למפתחים של Android לרכבים.

שם תוכלו למצוא קישורים להגשת מועמדות לתוכניות הגישה המוקדמת האלה.

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

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

אתם יכולים להשתמש באמולטור של Android Automotive OS כדי לצלם את צילומי המסך האלה.

הוא מוגדר כך שהוא יכול לצלם את המסך בדיוק בגודל שאתם צריכים.

ולסיום, הבטיחות היא הדבר הכי חשוב באפליקציות לרכבים.

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

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

ואחרון חביב, יש לנו את Wear OS.

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

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

@Composable
fun MyText() {
  Text(
    text = stringResource(R.string.compose_for_wear_os),
    modifier = Modifier.fillMaxWidth(),
    textAlign = TextAlign.Center,
    style = MaterialTheme.typography.titleLarge
  )
}

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

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

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

מה אפשר ללמוד מזה?

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

וגם כמה טיפים חשובים.

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

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

בנוסף, חשוב שתקיימו את מה שאתם מבטיחים.

אל תשתמשו רק בצילומי מסך של ניידים.

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

ואחרון חביב, תארו את הבעיה בצורה מדויקת.

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

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

תודה רבה לכולכם על הזמן שהקדשתם היום.

אנחנו כבר לא יכולים לחכות לראות את החוויות המדהימות שתביאו ל-Google Play, שמותאמות למגוון רחב של מכשירים.