אפשר לשלב את App Distribution בתהליך ה-build של Android באמצעות הפלאגין App Distribution ל-Gradle. הפלאגין מאפשר לציין את הבדיקות ואת הערות המוצר בקובץ Gradle של האפליקציה, וכך להגדיר הפצות לסוגים שונים של גרסאות build ולוריאציות שונות של האפליקציה.
במדריך הזה מוסבר איך להפיץ חבילות Android App Bundle (AAB) למפתחים לצורך בדיקה באמצעות הפלאגין App Distribution של Gradle.
App Distribution משתלב עם שירות השיתוף הפנימי של האפליקציות של Google Play כדי לעבד את קובצי ה-AAB שאתם מעלים ולהציג חבילות APK שעברו אופטימיזציה לתצורות המכשירים של הבוחנים. הפצת אפליקציות AAB מאפשרת לכם:
להריץ חבילות APK שעברו אופטימיזציה (ש-Google Play מספקת) ומותאמות למכשירים של הבוחנים.
זיהוי בעיות ספציפיות למכשיר וניפוי באגים שלהן.
לבדוק את התכונות של חבילות האפליקציות, כמו הפצת פיצ'רים ב-Play ו-Play Asset Delivery.
להקטין את גודל ההורדות של הבודקים.
ההרשאות הנדרשות
כדי להעלות קובצי AAB אל App Distribution, צריך לקשר את אפליקציית Firebase לאפליקציה ב-Google Play. כדי לבצע את הפעולות האלה, צריכה להיות לכם רמת הגישה הנדרשת.
אם אין לכם את הרשאת הגישה הנדרשת ל-Firebase, אתם יכולים לבקש מהבעלים של הפרויקט ב-Firebase להקצות לכם את התפקיד המתאים דרך הגדרות IAM במסוף Firebase. אם יש לכם שאלות לגבי הגישה לפרויקט ב-Firebase, כולל איך למצוא בעלים או להקצות בעלים, תוכלו לעיין בשאלות הנפוצות בנושא 'הרשאות וגישה לפרויקטים ב-Firebase'.
הטבלה הבאה רלוונטית לקישור אפליקציה ב-Firebase לאפליקציה ב-Google Play, וגם להעלאת קבצים מסוג AAB.
פעולה במסוף Firebase | הרשאת IAM נדרשת | תפקידי IAM שכוללים את ההרשאות הנדרשות כברירת מחדל | תפקידים נדרשים נוספים |
---|---|---|---|
קישור אפליקציה ב-Firebase לאפליקציה ב-Google Play | firebase.playLinks.update
|
אחד מהתפקידים הבאים: | גישה לחשבון פיתוח ב-Google Play בתור אדמין |
העלאת קובצי AAB אל App Distribution | firebaseappdistro.releases.update
|
אחד מהתפקידים הבאים: | –– |
לפני שמתחילים
אם עדיין לא עשיתם זאת, מוסיפים את Firebase לפרויקט Android. בסוף תהליך העבודה הזה תהיה לכם אפליקציית Android ב-Firebase בפרויקט שלכם ב-Firebase.
אם אתם לא משתמשים במוצרים אחרים של Firebase, עליכם רק ליצור פרויקט ולרשום את האפליקציה. אם תחליטו להשתמש במוצרים נוספים, הקפידו להשלים את כל השלבים המפורטים במאמר הוספת Firebase לפרויקט Android.
כדי ליצור קישור של Firebase ל-Google Play ולהעלות קובצי AAB, צריך לוודא שהאפליקציה עומדת בדרישות הבאות:
האפליקציה ב-Google Play ואפליקציית Firebase ל-Android רשומות עם אותו שם חבילה.
האפליקציה ב-Google Play מוגדרת במרכז הבקרה של האפליקציות ומופצת באחד מהמסלולים של Google Play (בדיקה פנימית, בדיקה בקבוצה מוגדרת, בדיקה של הקהל הרחב או ייצור).
הבדיקה של האפליקציה ב-Google Play הושלמה והאפליקציה פורסמה. האפליקציה שלכם תפורסם אם בעמודה סטטוס האפליקציה יופיע אחד מהסטטוסים הבאים: בדיקה פנימית (לא בדיקה פנימית של גרסת טיוטה), בדיקה בקבוצה מוגדרת, בדיקה של הקהל הרחב או סביבת ייצור.
מקשרים את אפליקציית Android ב-Firebase לחשבון הפיתוח ב-Google Play:
במסוף Firebase, עוברים אל
ובוחרים בכרטיסייה Integrations. Project settings בכרטיס Google Play, לוחצים על Link (קישור).
אם כבר יש לכם קישורים ל-Google Play, לוחצים במקום זאת על Manage (ניהול).פועלים לפי ההוראות במסך כדי להפעיל את השילוב עם App Distribution ולבחור לאילו אפליקציות ל-Android של Firebase לקשר את Google Play.
שלב 1. הגדרת הפרויקט ל-Android
בקובץ 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 }
בקובץ 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' }
אם אתם מאחורי שרת 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 = "AAB" releaseNotesFile = "/path/to/releasenotes.txt" testers = "ali@example.com, bri@example.com, cal@example.com" } } } // ... }
Groovy
android { // ... buildTypes { release { firebaseAppDistribution { artifactType="AAB" 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. מזהה האפליקציה מופיע בקובץ appId="1:1234567890:android:321abc456def7890" |
serviceCredentialsFile
|
הנתיב לקובץ ה-JSON של המפתח הפרטי של חשבון השירות. חובה רק אם משתמשים באימות של חשבון שירות. |
artifactType
|
מציין את סוג הקובץ של האפליקציה. אפשר להגדיר את הערך ל- |
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 (מידע נוסף זמין במאמר ניהול בודקים).
הקבוצות מצוינות באמצעות אפשר לציין את הקבוצות כרשימה של כינויים של קבוצות, מופרדים בפסיקים: 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. הפצת האפליקציה לבודקים
לבסוף, כדי לארוז את אפליקציית הבדיקה ולהזמין בודקים, יוצרים את היעדים
BUILD-VARIANT
ו-appDistributionUploadBUILD-VARIANT
באמצעות מעטפת Gradle של הפרויקט, כאשר BUILD-VARIANT הוא סוג המוצר וה-build האופציונליים שהגדרתם בשלב הקודם. מידע נוסף על טעמי מוצרים זמין במאמר הגדרת וריאציות גרסאות build.לדוגמה, כדי להפיץ את האפליקציה באמצעות גרסת build
release
, מריצים את הפקודה הבאה:./gradlew bundleRelease appDistributionUploadRelease
לחלופין, אם ביצעתם אימות באמצעות חשבון Google ולא סיפקתם פרטי כניסה בקובץ ה-build של Gradle, צריך לכלול את המשתנה
FIREBASE_TOKEN
:export FIREBASE_TOKEN=1/a1b2c3d4e5f67890 ./gradlew --stop // Only needed for environment variable changes ./gradlew bundleRelease appDistributionUploadRelease
אפשר גם לשנות את הערכים שהוגדרו בקובץ
build.gradle
על ידי העברת ארגומנטים של שורת הפקודה בפורמט--<property-name>=<property-value>
. לדוגמה:כדי להעלות גרסת build לניפוי באגים אל App Distribution:
./gradlew bundleDebug appDistributionUploadDebug --artifactType="AAB"
כדי להזמין בודקים נוספים או להסיר בודקים קיימים מהפרויקט ב-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 ימים (חמישה חודשים). 30 יום לפני שתוקף ה-build יפוג, תופיע הודעה על תפוגת התוקף במסוף וברשימה של ה-builds של הבוחן במכשיר הבדיקה שלו.
בודקים שלא הוזמנו לבדוק את האפליקציה יקבלו הזמנות באימייל כדי להתחיל, ובודקים קיימים יקבלו התראות באימייל על כך שגרסת build חדשה מוכנה לבדיקה (במדריך להגדרת בודקים מפורטות הוראות להתקנת אפליקציית הבדיקה). אתם יכולים לעקוב אחרי הסטטוס של כל בודק – אם הוא קיבל את ההזמנה ואם הוא הוריד את האפליקציה – במסוף Firebase.
לבודקים יש 30 ימים לאשר את ההזמנה לבדוק את האפליקציה, לפני שהתוקף שלה פג. כשנותרו 5 ימים לתוקף של ההזמנה, תופיע הודעה על תפוגה במסוף Firebase לצד הבוחן במהדורה. כדי לחדש את ההזמנה, שולחים אותה מחדש באמצעות התפריט הנפתח בשורה של הבוחן.
השלבים הבאים
כדאי להטמיע משוב מתוך האפליקציה כדי לאפשר לבודקים לשלוח בקלות משוב על האפליקציה (כולל צילומי מסך).
איך מציגים לבודקים התראות בתוך האפליקציה כשגרסאות build חדשות של האפליקציה זמינות להתקנה?
בcodelab של Android App Bundle מוסבר בהרחבה איך להפיץ גרסאות של חבילות App Bundle.
שיטות מומלצות להפצת אפליקציות ל-Android למבדקי בקרת איכות באמצעות CI/CD