כדי לראות איך האפליקציה נראית ומתנהגת במכשיר, צריך ליצור אותה ולהריץ אותה. ב-Android Studio אפשר להגדיר פרויקטים חדשים כדי לפרוס את האפליקציה במכשיר וירטואלי או פיזי בכמה קליקים בלבד.
בסקירה הכללית הזו נסביר איך משתמשים ב-Android Studio כדי ליצור ולהריץ את האפליקציה לצורכי בדיקה וניפוי באגים. במאמר יצירת אפליקציה לצורך פרסום למשתמשים מוסבר איך משתמשים ב-Android Studio כדי ליצור אפליקציה שאפשר לפרסם למשתמשים. מידע מפורט יותר על ניהול והתאמה אישית של גרסאות build, עם או בלי Android Studio, זמין במאמר הגדרת גרסאות build.
build והרצה בסיסיים
כדי ליצור ולהריץ את האפליקציה:
- בסרגל הכלים, בוחרים את האפליקציה בתפריט הגדרות ההרצה.
בתפריט של מכשיר היעד, בוחרים את המכשיר שבו רוצים להריץ את האפליקציה.
אם לא הגדרתם מכשירי Android, תצטרכו ליצור מכשיר וירטואלי של Android כדי להשתמש ב-Android Emulator או לחבר מכשיר פיזי.
לוחצים על הפעלה
.
אם תנסו להריץ את הפרויקט במכשיר שמשויך אליו אזהרה או שגיאה, תופיע אזהרה ב-Android Studio. שינויים בסמליות ובסגנון מאפשרים להבדיל בין שגיאות (בחירות של מכשירים שמובילות לתצורה שבורה) לבין אזהרות (בחירות של מכשירים שעלולות להוביל להתנהגות בלתי צפויה, אבל עדיין אפשר להריץ אותן).
מעקב אחרי תהליך ה-build
כדי להציג פרטים על תהליך ה-build, בוחרים באפשרות View > Tool Windows > Build או לוחצים על Build
בסרגל חלון הכלים. בחלון הכלי Build מוצגות המשימות ש-Gradle מבצעת כדי ליצור את האפליקציה, כפי שמוצג באיור 1.
- כרטיסיית סנכרון: משימות ש-Gradle מבצע כדי לסנכרן עם קובצי הפרויקט. בדומה לכרטיסייה Build Output, אם נתקלתם בשגיאת סנכרון, תוכלו לבחור רכיבים בעץ כדי לקבל מידע נוסף על השגיאה. בנוסף, מוצג סיכום של ההשפעה של ההורדות כדי לקבוע אם הורדות של יחסי תלות משפיעות לרעה על ה-build.
- כרטיסיית Build Output: כאן מוצגות המשימות ש-Gradle מבצע כעץ, שבו כל צומת מייצג שלב build או קבוצה של יחסי תלות בין משימות. אם מופיעות שגיאות בזמן ה-build או בזמן הידור, צריך לבדוק את העץ ולבחור רכיב כדי לקרוא את הפלט של השגיאה, כפי שמתואר באיור 2.
איור 2. בודקים אם יש הודעות שגיאה בכרטיסייה Build Output. - הכרטיסייה Build Analyzer: מידע על ניתוח הביצועים של ה-build. מידע נוסף זמין במאמר פתרון בעיות בביצועים של גרסאות build באמצעות Build Analyzer.
- הפעלה מחדש: הפעולה האחרונה של ה-build מבוצעת שוב. אם הפעלתם בפעם האחרונה את Build > Make Selected Module, המערכת תבנה את המודול הנוכחי. אם הפקודה האחרונה שהופעלה הייתה Build > Make Project, המערכת תיצור קובצי build ביניים לכל המודולים בפרויקט.
- מסננים: מסננים אזהרות, משימות או את שניהם שהושלמו בהצלחה. כך קל יותר למצוא בעיות בפלט.
אם הווריאציות של ה-build משתמשות בטעמי המוצר, Gradle מפעיל גם משימות כדי ליצור את טעמי המוצר האלה. כדי להציג את רשימת כל משימות ה-build הזמינות, לוחצים על View (תצוגה) > Tool Windows (חלונות כלים) > Gradle או על Gradle
בסרגל של חלון הכלים.
אם מתרחשת שגיאה במהלך תהליך ה-build, יכול להיות ש-Gradle יציע אפשרויות שורת פקודה שיעזרו לכם לפתור את הבעיה, כמו --stacktrace או --debug. כדי להשתמש באפשרויות של שורת הפקודה בתהליך ה-build:
- פותחים את תיבת הדו-שיח Settings (הגדרות) או Preferences (העדפות):
- ב-Windows או ב-Linux, בוחרים באפשרות File (קובץ) > Settings (הגדרות) בסרגל התפריטים.
- ב-macOS, בוחרים באפשרות Android Studio > Preferences בסרגל התפריטים.
- עוברים אל Build, Execution, Deployment > Compiler.
- בשדה הטקסט לצד Command-line Options, מזינים את אפשרויות שורת הפקודה.
- לוחצים על אישור כדי לשמור ולצאת.
Gradle מחיל את האפשרויות האלה בשורת הפקודה בפעם הבאה שתנסו ליצור את האפליקציה.
תכונות מתקדמות ל-build ולהרצה
דרך ברירת המחדל ליצירת build ולהרצת האפליקציה ב-Android Studio אמורה להספיק כדי לבדוק אפליקציה פשוטה. עם זאת, אפשר להשתמש בתכונות האלה ליצירת build ולהרצה בתרחישי שימוש מתקדמים יותר:
כדי לפרוס את האפליקציה במצב ניפוי באגים, לוחצים על ניפוי באגים
.
הפעלת האפליקציה במצב ניפוי באגים מאפשרת להגדיר נקודות עצירה בקוד, לבדוק משתנים ולהעריך ביטויים בזמן ריצה ולהפעיל כלים לניפוי באגים. מידע נוסף זמין במאמר ניפוי באגים באפליקציה.אם יש לכם אפליקציה גדולה ומורכבת יותר, השתמשו באפשרות 'החלת השינויים' במקום ללחוץ על הפעלה
. כך חוסכים זמן, כי לא צריך להפעיל מחדש את האפליקציה בכל פעם שרוצים לפרוס שינוי. מידע נוסף על Apply Changes זמין בקטע פריסה מצטברת באמצעות Apply Changes.אם אתם משתמשים ב-Jetpack Compose, העריכה בזמן אמת היא תכונה ניסיונית שמאפשרת לעדכן רכיבים של Composable בזמן אמת בלי ללחוץ שוב על הפעלה
.
כך תוכלו להתמקד בכתיבת קוד של ממשק המשתמש עם מינימום הפרעות. מידע נוסף זמין בקטע עריכה בזמן אמת (ניסיוני).אם יש לכם אפליקציה עם כמה גרסאות או וריאנטים של גרסאות build, תוכלו לבחור איזה וריאנט של build לפרוס באמצעות חלון הכלי Build Variants. מידע נוסף על הפעלת וריאנט build ספציפי זמין בקטע שינוי הווריאנט של ה-build.
כדי לשפר את אפשרויות ההתקנה, ההפעלה והבדיקה של האפליקציה, אפשר לשנות את ההגדרה של ההרצה או ניפוי הבאגים. מידע נוסף על יצירת הגדרות run/debug בהתאמה אישית זמין בקטע יצירת הגדרות run/debug.
מומלץ להשתמש ב-Android Studio לצורכי הפיתוח, אבל אפשר גם לפרוס את האפליקציה במכשיר וירטואלי או פיזי מהשורה הפקודה. מידע נוסף זמין במאמר פיתוח האפליקציה משורת הפקודה.
פריסה מצטברת באמצעות Apply Changes
ב-Android Studio 3.5 ואילך, האפשרות Apply Changes מאפשרת לדחוף שינויים בקוד ובמשאבים לאפליקציה שפועלת בלי להפעיל מחדש את האפליקציה, ובמקרים מסוימים בלי להפעיל מחדש את הפעילות הנוכחית. הגמישות הזו עוזרת לכם לקבוע כמה מהאפליקציה יופעל מחדש כשתרצו לפרוס ולבדוק שינויים קטנים מצטברים, תוך שמירה על המצב הנוכחי של המכשיר.
התכונה 'החלת שינויים' משתמשת ביכולות בהטמעת JVMTI של Android שנתמכות במכשירים עם Android מגרסה 8.0 (רמת API 26) ומעלה. למידע נוסף על האופן שבו פועלת התכונה Apply Changes, אפשר לעיין במאמר Android Studio Project Marble: Apply Changes.
דרישות
הפעולות 'החלת שינויים' זמינות רק אם מתקיימים התנאים הבאים:
- יוצרים את קובץ ה-APK של האפליקציה באמצעות גרסת build לניפוי באגים.
- פורסים את האפליקציה במכשיר יעד או במהדמה שפועלת עם Android 8.0 (רמת API 26) ואילך.
שימוש ב-Apply Changes
אפשר להשתמש באפשרויות הבאות כדי לפרוס את השינויים במכשיר תואם:
החלת השינויים והפעלה מחדש של הפעילות 
: המערכת תנסה להחיל את השינויים בקוד ובמשאבים על ידי הפעלה מחדש של הפעילות, אבל בלי להפעיל מחדש את האפליקציה. באופן כללי, אפשר להשתמש באפשרות הזו כשמשנים קוד בגוף של שיטה או משנים משאב קיים.
אפשר לבצע את הפעולה הזו גם על ידי הקשה על Control+Alt+F10 (Control+Command+Shift+R ב-macOS).
Apply Code Changes (החלת שינויים בקוד) 
: המערכת תנסה להחיל רק את השינויים בקוד בלי להפעיל מחדש שום דבר. באופן כללי, אפשר להשתמש באפשרות הזו כשמשנים קוד בגוף של שיטה אבל לא משנים משאבים. אם שיניתם גם את הקוד וגם את המשאבים, צריך להשתמש באפשרות החלת השינויים והפעלה מחדש של הפעילות במקום זאת.
אפשר לבצע את הפעולה הזו גם על ידי הקשה על Control+F10 (Control+Command+R ב-macOS).
הפעלה : פריסת כל השינויים והפעלה מחדש של האפליקציה. השתמשו באפשרות הזו אם אי אפשר להחיל את השינויים שביצעת באף אחת מהאפשרויות של החלת השינויים. מידע נוסף על סוגי השינויים שדורשים הפעלה מחדש של האפליקציה זמין בקטע מגבלות של החלת שינויים.
הפעלת ברירת מחדל להחלת שינויים
כשלוחצים על החלת השינויים והפעלה מחדש של הפעילות או על החלת השינויים בקוד, מערכת Android Studio יוצרת קובץ APK חדש ומחליטה אם אפשר להחיל את השינויים. אם לא ניתן להחיל את השינויים והם יגרמו לכך שהפעולה 'החלת שינויים' תיכשל, ב-Android Studio תופיע בקשה להריץ את האפליקציה שוב.
אם אתם לא רוצים להופיע הודעה בכל פעם שזה קורה, תוכלו להגדיר את Android Studio להריץ מחדש את האפליקציה באופן אוטומטי כשלא ניתן להחיל את השינויים. כדי להפעיל את ההתנהגות הזו:
פותחים את תיבת הדו-שיח הגדרות או העדפות:
- ב-Windows או ב-Linux, בוחרים באפשרות File (קובץ) > Settings (הגדרות) בתפריט.
- ב-macOS, לוחצים על Android Studio > Preferences בתפריט.
עוברים אל Build, Execution, Deployment (יצירה, ביצוע, פריסה) > Deployment (פריסה).
מסמנים את תיבות הסימון כדי להפעיל ברירת מחדל להרצה אוטומטית לאחת או לשתי הפעולות של Apply Changes.
לוחצים על אישור.
שינויים תלויי-פלטפורמה
חלק מהתכונות של 'החלת שינויים' תלויות בגרסאות ספציפיות של פלטפורמת Android. כדי להחיל שינויים כאלה, צריך לפרוס את האפליקציה במכשיר שפועלת בו אותה גרסה של Android (או גרסה מתקדמת יותר). לדוגמה, כדי להוסיף שיטה, צריך מכשיר עם Android מגרסה 11 ואילך.
מגבלות של Apply Changes
האפשרות 'החלת שינויים' נועדה לזרז את תהליך הפריסה של האפליקציה. עם זאת, יש כמה מגבלות על הזמנים שבהם אפשר להשתמש בה.
שינויים בקוד שמחייבים הפעלה מחדש של האפליקציה
יש שינויים בקוד ובמשאבים שלא ניתן להחיל עד שמפעילים מחדש את האפליקציה, כולל:
- הוספה או הסרה של שדה
- הסרת שיטה
- שינוי חתימות של שיטות
- שינוי של מודификаторים של שיטות או כיתות
- שינוי ירושת הכיתה
- שינוי ערכים ב-enums
- הוספה או הסרה של משאב
- שינוי קובץ המניפסט של האפליקציה
- שינוי ספריות מקוריות (קבצי SO)
ספריות ופלאגינים
חלק מהספריות והיישומי הפלאגין מבצעים שינויים באופן אוטומטי בקובצי המניפסט של האפליקציה או במשאבים שמצוינים במניפסט. העדכונים האוטומטיים האלה יכולים להפריע ל'החלת שינויים' בדרכים הבאות:
- אם ספרייה או פלאגין מבצעים שינויים במניפסט של האפליקציה, לא תוכלו להשתמש באפשרות'החלת השינויים'. כדי לראות את השינויים, צריך להפעיל מחדש את האפליקציה.
- אם ספרייה או פלאגין מבצעים שינויים בקובצי המשאבים של האפליקציה, אי אפשר להשתמש באפשרות Apply Code Changes (החלת שינויים בקוד) . כדי לראות את השינויים, צריך להשתמש באפשרות Apply Changes and Restart Activity (החלת השינויים והפעלה מחדש של הפעילות) (או להפעיל מחדש את האפליקציה).
כדי למנוע את המגבלות האלה, משביתים את כל העדכונים האוטומטיים של הווריאנטים של גרסאות ה-build לצורך ניפוי באגים.
לדוגמה, Firebase Crashlytics מעדכן את המשאבים של האפליקציה במזהה build ייחודי בכל build, ולכן אי אפשר להשתמש באפשרות Apply Code Changes (החלת שינויים בקוד) , וצריך להפעיל מחדש את הפעילות של האפליקציה כדי לראות את השינויים. כדי להשתמש ב-Apply Code Changes לצד Crashlytics ב-builds לניפוי באגים, צריך להשבית את ההתנהגות הזו.
קוד שמתייחס ישירות לתוכן ב-APK שהותקן
אם הקוד מפנה ישירות לתוכן מ-APK של האפליקציה שמותקן במכשיר, הקוד הזה עלול לגרום לקריסות או לפעולה לא תקינה אחרי שלוחצים על Apply Code Changes (החלת השינויים בקוד) . ההתנהגות הזו מתרחשת כי כשלוחצים על Apply Code Changes, קובץ ה-APK הבסיסי במכשיר מוחלף במהלך ההתקנה. במקרים כאלה, אפשר ללחוץ על החלת השינויים והפעלה מחדש של הפעילות או על הפעלה במקום זאת.
אם תיתקלו בבעיות אחרות בזמן השימוש בתכונה 'החלת שינויים', תוכלו לדווח על באג.
עריכה בזמן אמת
Live Edit היא תכונה ניסיונית ב-Android Studio שמאפשרת לעדכן רכיבים מורכבים (composables) במהירות באמולטורים ובמכשירים פיזיים. כך תוכלו להתמקד בכתיבת הקוד למשך זמן ארוך יותר בלי הפרעה.
שינוי וריאנט ה-build
כברירת מחדל, כשאתם לוחצים על הפעלה 
, Android Studio יוצרת את גרסת ניפוי הבאגים של האפליקציה, שנועדה לשימוש רק במהלך הפיתוח.
כדי לשנות את גרסת ה-build שבה Android Studio משתמשת, מבצעים אחת מהפעולות הבאות:
- בתפריט, בוחרים באפשרות Build > Select Build Variant.
- בתפריט, בוחרים באפשרות View > Tool Windows > Build Variants.
- לוחצים על הכרטיסייה יצירת וריאציות בסרגל של חלון הכלים.
בפרויקטים ללא קוד מקורי/C++, בחלונית Build Variants יש שתי עמודות: Module ו-Active Build Variant. הערך של Active Build Variant (גרסת build פעילה) של המודול קובע איזו גרסת build מערכת הפיתוח המשולבת פורסת במכשיר המחובר ומוצגת בעורך.
איור 9. בחלונית Build Variants יש שתי עמודות לפרויקטים שאין להם קוד מקורי/C++.
כדי לעבור בין הווריאנטים, לוחצים על התא Active Build Variant של המודול ובוחרים את הווריאנט הרצוי מהרשימה.
בפרויקטים עם קוד מקורי/C++, בחלונית Build Variants יש שלוש עמודות:
- מודול
- Active Build Variant
- Active ABI
הערך של Active Build Variant במודול קובע את גרסת ה-build שה-IDE פורס למכשיר ומוצגת בעורך. במודולים ילידים, הערך של Active ABI קובע את ABI שבו עורך הקוד משתמש, אבל לא משפיע על מה שנפרס.
איור 10. בחלונית Build Variants נוספת העמודה Active ABI לפרויקטים עם קוד מקורי/C++.
כדי לשנות את גרסת ה-build או את ה-ABI, לוחצים על התא של העמודה Active Build Variant או Active ABI ובוחרים את גרסת ה-build או את ה-ABI הרצויים מהרשימה. אחרי שמשנים את הבחירה, סביבת הפיתוח המשולבת מסנכרנת את הפרויקט באופן אוטומטי. שינוי של אחת מהעמודות באפליקציה או במודול הספרייה יחיל את השינוי על כל השורות התלויות.
כברירת מחדל, פרויקטים חדשים מוגדרים עם שתי וריאציות build: וריאנט לניפוי באגים ווריאנט להפצה. צריך ליצור את גרסת המהדורה כדי להכין את האפליקציה להפצה ציבורית. כדי להגדיר וריאציות אחרות של האפליקציה עם תכונות או דרישות שונות למכשירים, אפשר להגדיר וריאנטים נוספים של גרסאות build.
מחלוקות בתיבת הדו-שיח Build Variants ב-Android Studio
בתיבת הדו-שיח Build Variants ב-Android Studio, יכול להיות שיופיעו הודעות שגיאה שמציינות התנגשויות בין וריאנטים של גרסאות build, כמו:
השגיאה הזו לא מעידה על בעיה ב-build ב-Gradle. המשמעות היא ש-IDE של Android Studio לא יכול לפתור סמלים בין הווריאנטים של המודולים שנבחרו.
לדוגמה, אם יש לכם מודול M1 שמבוסס על הווריאנט v1 של המודול M2, אבל ב-IDE של M2 נבחר הווריאנט v2, יש לכם ב-IDE סמלים שלא נפתרו. נניח ש-M1 תלויה בכיתה שזמינה רק ב-v1. כשבוחרים ב-v2, סביבת הפיתוח המשולבת לא מכירה את הכיתה הזו. לכן לא ניתן לפתור את שם הכיתה, ומוצגות שגיאות בקוד של המודול M1.
הודעות השגיאה האלה מופיעות כי סביבת הפיתוח המשולבת לא יכולה לטעון קוד של כמה וריאנטים בו-זמנית. עם זאת, לגבי ה-build של האפליקציה, אין השפעה למשתנה שנבחר בתיבת הדו-שיח הזו, כי Gradle יוצר את האפליקציה באמצעות קוד המקור שצוין במתכונים ל-build של Gradle, ולא על סמך מה שנטען כרגע בסביבת הפיתוח המשולבת.
שינוי ההגדרה של הרצה/ניפוי באגים
כשמריצים את האפליקציה בפעם הראשונה, Android Studio משתמשת בהגדרת ברירת מחדל להרצה. הגדרת ההרצה קובעת אם לפרוס את האפליקציה מ-APK או מ-Android App Bundle, וגם את המודול להרצה, החבילה לפריסה, הפעילות להפעלה, מכשיר היעד, הגדרות הסימולטור, האפשרויות של Logcat ועוד.
הגדרת ברירת המחדל להרצה/ניפוי באגים יוצרת קובץ APK, מפעילה את פעילות הפרויקט שמוגדרת כברירת מחדל ומשתמשת בתיבת הדו-שיח Select Deployment Target (בחירת יעד הפריסה) כדי לבחור את מכשיר היעד. אם הגדרות ברירת המחדל לא מתאימות לפרויקט או למודול, תוכלו להתאים אישית את ההגדרות של ההרצה או ניפוי הבאגים, או ליצור הגדרות חדשות ברמת הפרויקט, ברמת ברירת המחדל וברמת המודול.
כדי לערוך הגדרת הפעלה/ניפוי באגים, בוחרים באפשרות הפעלה > עריכת הגדרות. למידע נוסף, ראו יצירה ועריכה של הגדרות הפעלה/ניפוי באגים.