הפצת אפליקציות ל-Android לבודקים באמצעות Gradle


אפשר לשלב את App Distribution בתהליך ה-build של Android באמצעות הפלאגין App Distribution של Gradle. התוסף מאפשר לכם לציין את הבודקים והערות הגרסה בקובץ Gradle של האפליקציה, וכך להגדיר הפצות לסוגים שונים של גרסאות build ולוריאציות של האפליקציה.

במדריך הזה מוסבר איך להפיץ קובצי APK לבודקים באמצעות התוסף App Distribution Gradle.

לפני שמתחילים

  1. אם עדיין לא עשיתם זאת, עליכם להוסיף את Firebase לפרויקט Android שלכם.

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

  2. פותחים את הדף App Distribution במסוף Firebase. כשמוצגת בקשה, בוחרים את פרויקט Firebase, בוחרים את האפליקציה באמצעות מחליף האפליקציות ולוחצים על Get started (תחילת העבודה).

שלב 1. הגדרת פרויקט Android

  1. בקובץ Gradle ברמת השורש (ברמת הפרויקט) (<project>/build.gradle.kts או <project>/build.gradle), מוסיפים את פלאגין Gradle של App Distribution כתלות:

    Kotlin

    plugins {
        // ...
        id("com.android.application") version "7.3.0" apply false
    
        // Make sure that you have the Google services Gradle plugin dependency
        id("com.google.gms.google-services") version "4.5.0" apply false
    
        // Add the dependency for the App Distribution Gradle plugin
        id("com.google.firebase.appdistribution") version "5.3.0" apply false
    }

    Groovy

    plugins {
        // ...
        id 'com.android.application' version '7.3.0' apply false
    
        // Make sure that you have the Google services Gradle plugin dependency
        id 'com.google.gms.google-services' version '4.5.0' apply false
    
        // Add the dependency for the App Distribution Gradle plugin
        id 'com.google.firebase.appdistribution' version '5.3.0' apply false
    }
  2. בקובץ Gradle של המודול (ברמת האפליקציה) (בדרך כלל <project>/<app-module>/build.gradle.kts או <project>/<app-module>/build.gradle), מוסיפים את הפלאגין App Distribution Gradle:

    Kotlin

    plugins {
      id("com.android.application")
    
      // Make sure that you have the Google services Gradle plugin
      id("com.google.gms.google-services")
    
      // Add the App Distribution Gradle plugin
      id("com.google.firebase.appdistribution")
    }

    Groovy

    plugins {
      id 'com.android.application'
    
      // Make sure that you have the Google services Gradle plugin
      id 'com.google.gms.google-services'
    
      // Add the App Distribution Gradle plugin
      id 'com.google.firebase.appdistribution'
    }
  3. אם אתם עובדים מאחורי שרת Proxy או חומת אש של ארגון, אתם צריכים להוסיף את מאפיין המערכת הבא של Java שמאפשר ל-App Distribution להעלות את ההפצות שלכם ל-Firebase:

    -Djavax.net.ssl.trustStore=/path/to/truststore -Djavax.net.ssl.trustStorePassword=password
    

שלב 2. אימות באמצעות Firebase

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

שלב 3. הגדרת מאפייני ההפצה

בקובץ Gradle של המודול (ברמת האפליקציה) (בדרך כלל <project>/<app-module>/build.gradle.kts או <project>/<app-module>/build.gradle), מגדירים את App Distribution על ידי הוספה של לפחות קטע firebaseAppDistribution אחד.

לדוגמה, כדי להפיץ את גרסת ה-build‏ release לבודקים, פועלים לפי ההוראות הבאות::

Kotlin

import com.google.firebase.appdistribution.gradle.firebaseAppDistribution

android {

  // ...

  buildTypes {
      getByName("release") {
          firebaseAppDistribution {
              artifactType = "APK"
              releaseNotesFile = "/path/to/releasenotes.txt"
              testers = "ali@example.com, bri@example.com, cal@example.com"
          }
      }
  }

  // ...
}

Groovy

android {

  // ...

  buildTypes {
      release {
          firebaseAppDistribution {
              artifactType="APK"
              releaseNotesFile="/path/to/releasenotes.txt"
              testers="ali@example.com, bri@example.com, cal@example.com"
          }
      }
  }

  // ...
}

אפשר להגדיר את App Distribution עבור סוגי build וטעמי מוצר.

לדוגמה, כדי להפיץ גרסאות build של debug ו-release בטעמי המוצר demo ו-full, פועלים לפי ההוראות הבאות:

Kotlin

import com.google.firebase.appdistribution.gradle.firebaseAppDistribution

android {

  // ...

  buildTypes {
      getByName("debug") {...}
      getByName("release") {...}
  }

  flavorDimensions += "version"
  productFlavors {
      create("demo") {
          dimension = "version"
          firebaseAppDistribution {
              releaseNotes = "Release notes for demo version"
              testers = "demo@testers.com"
          }
      }
      create("full") {
          dimension = "version"
          firebaseAppDistribution {
              releaseNotes = "Release notes for full version"
              testers = "full@testers.com"
          }
      }
  }

  // ...
}

Groovy

android {

  // ...

  buildTypes {
      debug {...}
      release {...}
  }

  flavorDimensions "version"
  productFlavors {
      demo {
          dimension "version"
          firebaseAppDistribution {
              releaseNotes="Release notes for demo version"
              testers="demo@testers.com"
          }
      }
      full {
          dimension "version"
          firebaseAppDistribution {
              releaseNotes="Release notes for full version"
              testers="full@testers.com"
          }
      }
  }

  // ...
}

משתמשים בפרמטרים הבאים כדי להגדיר את ההפצה:

App Distribution יצירת פרמטרים
appId

מזהה האפליקציה ב-Firebase. השלב הזה נדרש רק אם לא מותקן הפלאגין Google Services Gradle. אפשר למצוא את מזהה האפליקציה בקובץ google-services.json או במסוף Firebase בדף ההגדרות הכלליות. הערך בקובץ build.gradle מבטל את הערך שמופק מהתוסף google-services.

appId="1:1234567890:android:321abc456def7890"
serviceCredentialsFile

הנתיב לקובץ ה-JSON של המפתח הפרטי של חשבון השירות. חובה רק אם משתמשים באימות של חשבון שירות.

artifactType

מציין את סוג הקובץ של האפליקציה. אפשר להגדיר את הערך "AAB" או "APK".

artifactPath

הנתיב המוחלט לקובץ ה-APK או AAB שרוצים להעלות.

releaseNotes או releaseNotesFile

נתוני הגרסה של הבנייה הזו.

אפשר לציין את הערות הגרסה ישירות או את הנתיב לקובץ טקסט פשוט.

testers או testersFile

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

אפשר לציין את הבודקים כרשימה של כתובות אימייל שמופרדות בפסיקים:

testers="ali@example.com, bri@example.com, cal@example.com"

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

testersFile="/path/to/testers.txt"
groups או groupsFile

קבוצות הבודקים שרוצים להפיץ להן את הגרסאות (ראו ניהול בודקים). הקבוצות מצוינות באמצעות כתובות אימייל חלופיות של קבוצות, שאפשר למצוא בכרטיסייה Testers במסוף Firebase‏ App Distribution.

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

groups="qa-team, android-testers"

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

groupsFile="/path/to/tester-groups.txt"
testDevices או testDevicesFile

מכשירי הבדיקה שרוצים להריץ עליהם בדיקות של סוכן App Testing.

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

testDevices="model=shiba,version=34,locale=en,orientation=portrait"

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

testDevicesFile="/path/to/testDevices.txt"
testUsername

שם המשתמש לכניסה אוטומטית שישמש במהלך בדיקות של סוכן App Testing.

testPassword או testPasswordFile

הסיסמה לכניסה אוטומטית שתשמש במהלך בדיקות של סוכן App Testing.

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

testPasswordFile="/path/to/testPassword.txt"
testUsernameResource

שם המשאב של השדה של שם המשתמש לכניסה אוטומטית, לשימוש במהלך בדיקות של סוכן App Testing.

testPasswordResource

שם המשאב של שדה הסיסמה לכניסה אוטומטית, לשימוש במהלך בדיקות של סוכן App Testing.

testNonBlocking

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

resultsBucket

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

stacktrace

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

שלב 4. הפצת האפליקציה לבודקים

  1. לבסוף, כדי לארוז את אפליקציית הבדיקה ולהזמין בודקים, צריך ליצור את יעדי הבנייה BUILD-VARIANT ו-appDistributionUploadBUILD-VARIANT באמצעות Gradle Wrapper של הפרויקט, כאשר BUILD-VARIANT הוא גרסת המוצר האופציונלית וסוג build שהגדרתם בשלב הקודם. מידע נוסף על גרסאות מוצר זמין במאמר הגדרת וריאציות של build.

    לדוגמה, כדי להפיץ את האפליקציה באמצעות וריאציית ה-build‏ release, מריצים את הפקודה הבאה:

    ./gradlew assembleRelease appDistributionUploadRelease
    

    לחלופין, אם ביצעתם אימות באמצעות חשבון Google ולא סיפקתם פרטי כניסה בקובץ ה-build של Gradle, צריך לכלול את המשתנה FIREBASE_TOKEN:

    export FIREBASE_TOKEN=1/a1b2c3d4e5f67890
    ./gradlew --stop // Only needed for environment variable changes
    ./gradlew assembleRelease appDistributionUploadRelease
    
  2. אפשר גם לשנות את הערכים שהוגדרו בקובץ build.gradle באמצעות העברת ארגומנטים בשורת הפקודה בפורמט --<property-name>=<property-value>. לדוגמה:

    • כדי להעלות גרסת build לניפוי באגים אל App Distribution:

      ./gradlew bundleDebug appDistributionUploadDebug
          --artifactType="APK"
    • כדי להזמין בודקים נוספים או להסיר בודקים קיימים מהפרויקט שלכם ב-Firebase:

      ./gradlew appDistributionAddTesters
          --projectNumber=<project_number>
          --emails="anothertester@email.com, moretesters@email.com"
      ./gradlew appDistributionRemoveTesters
          --projectNumber=<project_number>
          --emails="anothertester@email.com, moretesters@email.com"

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

    אפשר גם לציין בודקים באמצעות --file="/path/to/testers.txt" במקום --emails.

    המשימות appDistributionAddTesters ו-appDistributionRemoveTesters מקבלות גם את הארגומנטים הבאים:

    • ‫projectNumber: מספר הפרויקט ב-Firebase.

    • ‫serviceCredentialsFile: הנתיב לקובץ פרטי הכניסה של שירות Google. זה אותו ארגומנט שמשמש את פעולת ההעלאה.

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

  • ‫firebase_console_uri – קישור למסוף Firebase שבו מוצגת גרסה אחת. אתם יכולים לשתף את הקישור הזה עם מפתחים אחרים בארגון שלכם.
  • ‫testing_uri – קישור לגרסה בחוויית הבודקים (אפליקציית Android מובנית) שמאפשר לבודקים לראות את הערות הגרסה ולהתקין את האפליקציה במכשיר שלהם. הבודק צריך גישה לגרסה כדי להשתמש בקישור.
  • ‫binary_download_uri – קישור חתום שמוריד ישירות את קובץ הבינארי של האפליקציה (קובץ APK או AAB) ומתקין אותו. התוקף של הקישור יפוג אחרי שעה.

אחרי שמפיצים את הגרסה, היא זמינה במרכז הבקרה של App Distribution מסוף Firebase למשך 150 ימים (חמישה חודשים). כשנותרו 30 יום עד לתפוגה של גרסת ה-build, מופיעה הודעת תפוגה גם במסוף וגם ברשימת גרסאות ה-build של הבודק במכשיר הבדיקה שלו.

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

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

השלבים הבאים