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


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

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

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

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

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

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

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

    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.4.2" apply false

    // Add the dependency for the App Distribution Gradle plugin
    id("com.google.firebase.appdistribution") version "5.0.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.4.2' apply false

    // Add the dependency for the App Distribution Gradle plugin
    id 'com.google.firebase.appdistribution' version '5.0.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 אחד לפחות.

לדוגמה, כדי להפיץ את הגרסה המאוחדת 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 בגרסת הדגמה ובגרסה המלאה של המוצר, פועלים לפי ההוראות הבאות:

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 פרמטרים של build
appId

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

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

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

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

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

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

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

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

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

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

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

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

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

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

groups="qa-team, android-testers"

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

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

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

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

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

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

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

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

שם המשתמש להתחברות אוטומטית לשימוש במהלך הבדיקות האוטומטיות.
testPassword או testPasswordFile

הסיסמה להתחברות אוטומטית לשימוש במהלך הבדיקות האוטומטיות.

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

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

שם המשאב של השדה של שם המשתמש לצורך התחברות אוטומטית, שישמש במהלך בדיקות אוטומטיות.
testPasswordResource

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

מריצים בדיקות אוטומטיות באופן אסינכרוני. תוצאות הבדיקה האוטומטיות מופיעות במסוף Firebase.
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). הקישור תקף לשעה אחת.

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

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

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

השלבים הבאים