כדי לראות איך האפליקציה נראית ופועלת במכשיר, צריך ליצור ולהפעיל אותה. ב-Android Studio אפשר להגדיר פרויקטים חדשים כך שתוכלו לפרוס את האפליקציה במכשיר וירטואלי או פיזי בכמה קליקים בלבד.
בסקירה הכללית הזו נתמקד בשימוש ב-Android Studio כדי ליצור ולהפעיל את האפליקציה לבדיקה ולניפוי באגים. במאמר איך מפתחים אפליקציה כדי להפיץ אותה למשתמשים מוסבר איך משתמשים ב-Android Studio כדי לפתח אפליקציה ולהפיץ אותה למשתמשים. מידע מפורט יותר על ניהול והתאמה אישית של ה-build עם או בלי Android Studio זמין במאמר הגדרת ה-build.
יצירה והרצה בסיסיות
כדי ליצור ולהפעיל את האפליקציה, פועלים לפי השלבים הבאים:
- בסרגל הכלים, בוחרים את האפליקציה בתפריט של הגדרות ההפעלה.
בתפריט של מכשיר היעד, בוחרים את המכשיר שבו רוצים להפעיל את האפליקציה.
תפריט מכשיר היעד בסרגל הכלים של Android Studio. אם לא הגדרתם מכשירים, אתם צריכים ליצור מכשיר וירטואלי של Android כדי להשתמש באמולטור Android או לחבר מכשיר פיזי.
לוחצים על הפעלה
.
אם תנסו להפעיל את הפרויקט במכשיר שיש בו שגיאה או אזהרה, תקבלו אזהרה ב-Android Studio. שינויים בסמלים ובסגנון מבדילים בין שגיאות (בחירות של מכשירים שגורמות להגדרות לא תקינות) לבין אזהרות (בחירות של מכשירים שעשויות לגרום להתנהגות לא צפויה אבל עדיין אפשר להריץ אותן).
מעקב אחרי תהליך ה-build
כדי לראות פרטים על תהליך ה-build, בוחרים באפשרות View > Tool Windows > Build או לוחצים על Build 
בסרגל של חלון הכלי. בחלון של הכלי Build מוצגות המשימות ש-Gradle מבצע כדי ליצור את ה-build של האפליקציה, כמו שמוצג באיור 1.
- הכרטיסייה Sync: מציגה משימות ש-Gradle מבצע כדי לסנכרן עם קובצי הפרויקט. בדומה לכרטיסייה Build Output, אם נתקלים בשגיאת סנכרון, בוחרים רכיבים בעץ כדי לקבל מידע נוסף על השגיאה. בנוסף, מוצג סיכום של ההשפעה של ההורדות כדי לקבוע אם הורדות של יחסי תלות משפיעות לרעה על ה-build.
- הכרטיסייה Build Output: מציגה את המשימות ש-Gradle מבצע כעץ, שבו כל צומת מייצג שלב build או קבוצה של יחסי תלות בין משימות. אם אתם מקבלים שגיאות בזמן ה-build או בזמן הקימפול, בדקו את העץ ובחרו רכיב כדי לקרוא את פלט השגיאה, כמו שמוצג באיור 2.
איור 2. בודקים אם יש הודעות שגיאה בכרטיסייה Build Output. - הכרטיסייה Build Analyzer: מספקת מידע על ניתוח ביצועי ה-build של ה-build שלכם. מידע נוסף זמין במאמר פתרון בעיות בביצועי ה-build באמצעות Build Analyzer.
- הפעלה מחדש: הפעלה מחדש של פעולת היצירה האחרונה. אם הפעולה האחרונה שהרצתם הייתה Build > Make Selected Module, המודול הנוכחי ייבנה. אם הפעלתם לאחרונה את Build > Make Project (build > יצירת פרויקט), ייווצרו קובצי build זמניים לכל המודולים בפרויקט.
- מסננים: סינון של אזהרות, משימות או שניהם שהושלמו בהצלחה. כך קל יותר למצוא בעיות בפלט.
אם וריאנט ה-build משתמש בגרסאות מוצר, Gradle מפעיל גם משימות כדי ליצור את גרסאות המוצר האלה. כדי לראות את רשימת כל משימות ה-build הזמינות, לוחצים על View > Tool Windows > Gradle או על Gradle 
בסרגל של חלון הכלי.
אם מתרחשת שגיאה במהלך תהליך ה-build, יכול להיות ש-Gradle ימליץ על אפשרויות של שורת הפקודה שיעזרו לכם לפתור את הבעיה, כמו --stacktrace או --debug. כדי להשתמש באפשרויות של שורת הפקודה בתהליך ה-build:
- פותחים את תיבת הדו-שיח הגדרות או העדפות:
- ב-Windows או ב-Linux, בוחרים באפשרות קובץ > הגדרות בסרגל התפריטים.
- ב-macOS, בוחרים באפשרות Android Studio > Preferences מסרגל התפריטים.
- עוברים אל Build, Execution, Deployment > Compiler.
- בשדה הטקסט שליד Command-line Options, מזינים את האפשרויות של שורת הפקודה.
- לוחצים על אישור כדי לשמור ולצאת.
Gradle יפעיל את האפשרויות האלה של שורת הפקודה בפעם הבאה שתנסו ליצור את האפליקציה.
פיתוח והרצה באמצעות סוכן ה-AI
לסוכן ה-AI ב-Android Studio יש גישה לכלים שמאפשרים לו ליצור ולפרוס את האפליקציה, ואז לאמת את מצב האפליקציה בשבילכם. כשמשתמשים במצב סוכן, הסוכן יכול לבצע משימות כמו:
- פורסים את האפליקציה במכשיר פיזי מחובר או באמולטור.
- בודקים את המסך ומצלמים צילומי מסך כדי לאמת את השינויים בממשק המשתמש.
- בודקים ב-Logcat אם יש שגיאות זמן ריצה או הודעות ספציפיות ביומן.
- מבצעים פעולות באפליקציה באמצעות פקודות
adb shellכדי לנווט או להזין נתונים.
השימוש בסוכן ה-AI כדי ליצור ולהריץ את האפליקציה שימושי למשימות בכמה שלבים, שבהן הסוכן צריך לבצע שינויים באופן איטרטיבי ולוודא שהם פועלים כצפוי.
תכונות מתקדמות של פיתוח והרצה
הדרך שמוגדרת כברירת מחדל לבנייה ולהפעלה של האפליקציה ב-Android Studio אמורה להספיק כדי לבדוק אפליקציה. עם זאת, אתם יכולים להשתמש בתכונות הבנייה וההפעלה האלה לתרחישי שימוש מתקדמים יותר:
כדי לפרוס את האפליקציה במצב ניפוי באגים, לוחצים על Debug
.
הפעלת האפליקציה במצב ניפוי באגים מאפשרת להגדיר נקודות עצירה בקוד, לבחון משתנים ולהעריך ביטויים בזמן ריצה, ולהפעיל כלים לניפוי באגים. מידע נוסף זמין במאמר ניפוי באגים באפליקציה.אם יש לכם אפליקציה גדולה ומורכבת יותר, השתמשו ב-Apply Changes במקום ללחוץ על Run
. כך אתם חוסכים זמן, כי אתם לא צריכים להפעיל מחדש את האפליקציה בכל פעם שאתם רוצים לפרוס שינוי. מידע נוסף על Apply Changes זמין בקטע פריסה הדרגתית באמצעות Apply Changes.אם אתם משתמשים ב-Jetpack Compose, התכונה הניסיונית "עריכה בזמן אמת" מאפשרת לכם לעדכן רכיבים קומפוזביליים בזמן אמת בלי ללחוץ שוב על הפעלה
. כך אתם יכולים להתמקד בכתיבת קוד של ממשק המשתמש עם כמה שפחות הפרעות. מידע נוסף זמין בקטע עריכה בזמן אמת (ניסיוני).אם יש לכם אפליקציה עם כמה וריאנטים של build או כמה גרסאות, אתם יכולים לבחור איזה וריאנט של build לפרוס באמצעות החלון של הכלי Build Variants. מידע נוסף על הפעלת וריאנט build ספציפי זמין בקטע שינוי וריאנט ה-build.
כדי לשנות את האפשרויות להתקנה, להפעלה ולבדיקה של האפליקציה, אתם יכולים לשנות את הגדרת ההרצה/ניפוי הבאגים. מידע נוסף על יצירת הגדרות הרצה/ניפוי באגים בהתאמה אישית זמין בקטע יצירת הגדרות הרצה/ניפוי באגים.
מומלץ להשתמש ב-Android Studio לצורכי הפיתוח, אבל אפשר גם לפרוס את האפליקציה במכשיר וירטואלי או פיזי משורת הפקודה. מידע נוסף זמין במאמר פיתוח האפליקציה משורת הפקודה.
פריסה הדרגתית באמצעות Apply Changes
ב-Android Studio מגרסה 3.5 ואילך, התכונה Apply Changes מאפשרת להעביר שינויים בקוד ובמשאבים לאפליקציה שפועלת בלי להפעיל אותה מחדש, ובמקרים מסוימים, בלי להפעיל מחדש את הפעילות הנוכחית. הגמישות הזו מאפשרת לכם לשלוט בחלק של האפליקציה שמופעל מחדש כשאתם רוצים לפרוס ולבדוק שינויים קטנים ומצטברים, תוך שמירה על המצב הנוכחי של המכשיר.
התכונה "החלת השינויים" משתמשת ביכולות בהטמעה של Android JVMTI שנתמכות במכשירים עם Android בגרסה 8.0 (רמת API 26) ומעלה. מידע נוסף על אופן הפעולה של Apply Changes זמין במאמר Android Studio Project Marble: Apply Changes.
דרישות
הפעולות של Apply Changes זמינות רק אם אתם עומדים בתנאים הבאים:
- אתם יוצרים את ה-APK של האפליקציה באמצעות וריאנט build לניפוי באגים.
- אתם פורסים את האפליקציה במכשיר יעד או באמולטור שפועלת בהם גרסת Android 8.0 (רמת API 26) ומעלה.
שימוש ב-Apply Changes
כדי לפרוס את השינויים במכשיר תואם, אפשר להשתמש באפשרויות הבאות:
Apply Changes and Restart Activity 
: ניסיון להחיל את השינויים במשאבים ובקוד על ידי הפעלה מחדש של הפעילות, אבל בלי להפעיל מחדש את האפליקציה. בדרך כלל, אפשר להשתמש באפשרות הזו כשמשנים קוד בגוף של שיטה או משנים משאב קיים.
אפשר גם ללחוץ על Control+Alt+F10 (Control+Command+Shift+R ב-macOS).
החלת שינויים בקוד 
: ניסיון להחיל רק את השינויים בקוד בלי להפעיל מחדש שום דבר. בדרך כלל, אפשר להשתמש באפשרות הזו כשמשנים קוד בגוף של שיטה, אבל לא משנים משאבים. אם שיניתם גם את הקוד וגם את המשאבים, השתמשו במקום זאת באפשרות Apply Changes and Restart Activity.
אפשר גם ללחוץ על Control+F10 (או Control+Command+R ב-macOS).
Run : פריסת כל השינויים והפעלה מחדש של האפליקציה. השתמשו באפשרות הזו אם אי אפשר להחיל את השינויים שביצעתם באמצעות אחת מהאפשרויות של Apply Changes. בקטע המגבלות של Apply Changes מפורטים סוגי השינויים שמחייבים הפעלה מחדש של האפליקציה.
הפעלת חלופה להרצה של Apply Changes
כשלוחצים על Apply Changes and Restart Activity או על Apply Code Changes, המערכת של Android Studio יוצרת קובץ APK חדש ובודקת אם אפשר להחיל את השינויים. אם אי אפשר להחיל את השינויים והם יגרמו לכשל ב-Apply Changes, תופיע ב-Android Studio בקשה להפעיל את האפליקציה שוב.
אם אתם לא רוצים לקבל בקשה בכל פעם שזה קורה, אתם יכולים להגדיר את Android Studio כך שיפעיל מחדש את האפליקציה באופן אוטומטי כשאי אפשר להחיל את השינויים. כדי להפעיל את ההתנהגות הזו, פועלים לפי השלבים הבאים:
פותחים את תיבת הדו-שיח הגדרות או העדפות:
- ב-Windows או ב-Linux, בוחרים בתפריט File > Settings.
- ב-macOS, בוחרים בתפריט באפשרות Android Studio > Preferences.
עוברים אל Build, Execution, Deployment > Deployment.
מסמנים את התיבות כדי להפעיל את ההרצה האוטומטית של חלופות לאחת מהפעולות של Apply Changes או לשתיהן.
לוחצים על אישור.
שינויים שתלויים בפלטפורמה
חלק מהתכונות של Apply Changes תלויות בגרסאות ספציפיות של פלטפורמת Android. כדי להחיל שינויים כאלה, צריך לפרוס את האפליקציה במכשיר עם גרסת Android הזו (או גרסה חדשה יותר). לדוגמה, כדי להוסיף אמצעי תשלום צריך מכשיר עם Android מגרסה 11 ואילך.
המגבלות של Apply Changes
התכונה Apply Changes נועדה לזרז את תהליך פריסת האפליקציה. עם זאת, יש כמה מגבלות על השימוש בו.
שינויים בקוד שמחייבים הפעלה מחדש של האפליקציה
יש שינויים בקוד ובמשאבים שאי אפשר להחיל עד שמפעילים מחדש את האפליקציה, כולל:
- הוספה או הסרה של שדה
- הסרת שיטה
- שינוי חתימות של שיטות
- שינוי של מגדירי הגישה של שיטות או מחלקות
- שינוי ירושת המחלקות
- שינוי ערכים בטיפוסים בני מנייה (enum)
- הוספה או הסרה של משאב
- שינוי קובץ המניפסט של האפליקציה
- שינוי של ספריות Native (קובצי SO)
ספריות ופלאגינים
חלק מהספריות והפלאגינים מבצעים שינויים באופן אוטומטי בקובצי המניפסט של האפליקציה או במשאבים שהמניפסט מפנה אליהם. העדכונים האוטומטיים האלה יכולים להפריע לפעולה של Apply Changes בדרכים הבאות:
- אם ספרייה או פלאגין מבצעים שינויים במניפסט של האפליקציה, אי אפשר להשתמש ב-Apply Changes. כדי לראות את השינויים, צריך להפעיל מחדש את האפליקציה.
- אם ספרייה או פלאגין מבצעים שינויים בקובצי המשאבים של האפליקציה, אי אפשר להשתמש באפשרות החלת שינויים בקוד . כדי לראות את השינויים, צריך להשתמש באפשרות Apply Changes and Restart Activity (או להפעיל מחדש את האפליקציה).
כדי להימנע מהמגבלות האלה, צריך להשבית את כל העדכונים האוטומטיים של וריאנטים של גרסאות build לניפוי באגים.
לדוגמה, Firebase Crashlytics מעדכן את משאבי האפליקציה עם מזהה build ייחודי בכל build, מה שמונע מכם להשתמש בהחלת שינויים בקוד ומחייב אתכם להפעיל מחדש את הפעילות של האפליקציה כדי לראות את השינויים. כדי להשתמש בהחלת שינויים בקוד לצד Crashlytics עם גרסאות build לניפוי באגים, צריך להשבית את ההתנהגות הזו.
קוד שמפנה ישירות לתוכן ב-APK מותקן
אם הקוד מפנה ישירות לתוכן מ-APK של האפליקציה שמותקן במכשיר, הקוד הזה עלול לגרום לקריסות או להתנהגות לא תקינה אחרי לחיצה על החלת שינויים בקוד . הסיבה לכך היא שכאשר לוחצים על Apply Code Changes, ה-APK הבסיסי במכשיר מוחלף במהלך ההתקנה. במקרים כאלה, אפשר ללחוץ על Apply Changes and Restart Activity או על Run .
אם נתקלתם בבעיות אחרות בזמן השימוש ב-Apply Changes, דווחו על באג.
עריכה בזמן אמת
"עריכה בזמן אמת" היא תכונה ניסיונית ב-Android Studio שמאפשרת לעדכן רכיבים קומפוזביליים באמולטורים ובמכשירים פיזיים בזמן אמת. הפונקציונליות הזו מצמצמת את המעברים בין כתיבת האפליקציה לבין פיתוח האפליקציה, ומאפשרת לכם להתמקד בכתיבת הקוד למשך זמן רב יותר בלי הפרעות.
שינוי וריאנט ה-build
כברירת מחדל, כשלוחצים על Run 
, Android Studio יוצר את גרסת ניפוי הבאגים של האפליקציה, שמיועדת לשימוש רק במהלך הפיתוח.
כדי לשנות את וריאנט ה-build שבו משתמשים ב-Android Studio, מבצעים אחת מהפעולות הבאות:
- בתפריט, בוחרים באפשרות Build (פיתוח) > Select Build Variant (בחירת וריאנט build).
- בתפריט, בוחרים באפשרות View > Tool Windows > Build Variants.
- לוחצים על הכרטיסייה Build Variants בסרגל של חלון הכלי.
בפרויקטים בלי קוד נייטיב או קוד C++, בחלונית Build Variants יש שתי עמודות: Module ו-Active Build Variant. הערך של Active Build Variant במודול קובע איזה וריאנט build סביבת הפיתוח המשולבת (IDE) פורסת במכשיר המחובר, והוא גלוי בכלי העריכה.
כדי לעבור בין וריאנטים, לוחצים על התא Active Build Variant של מודול ובוחרים את הווריאנט הרצוי מהרשימה.
בפרויקטים עם קוד נייטיב או קוד C++, בחלונית Build Variants יש שלוש עמודות:
- מודול
- וריאנט build פעיל
- Active ABI
הערך של Active Build Variant של המודול קובע את וריאנט ה-build שסביבת הפיתוח המשולבת (IDE) פורסת במכשיר, והוא גלוי בכלי העריכה. במודולים מקוריים, הערך של Active ABI קובע את ה-ABI שבו משתמש העורך, אבל לא משפיע על מה שנפרס.
כדי לשנות את וריאנט ה-build או את ה-ABI, לוחצים על התא בעמודה Active Build Variant או Active ABI ובוחרים את הווריאנט או ה-ABI הרצויים מהרשימה. אחרי שמשנים את הבחירה, סביבת הפיתוח המשולבת מסנכרנת את הפרויקט באופן אוטומטי. אם משנים את אחת מהעמודות האלה במודול של אפליקציה או ספרייה, השינוי חל על כל השורות שתלויות בהן.
כברירת מחדל, פרויקטים חדשים מוגדרים עם שני וריאנטים של build: וריאנט build לניפוי באגים ווריאנט build להפצה. צריך ליצור את גרסת ה-release כדי להכין את האפליקציה לפרסום לציבור. כדי להגדיר וריאציות אחרות של האפליקציה עם תכונות או דרישות מכשיר שונות, אתם יכולים להגדיר וריאנטים נוספים של build.
קונפליקטים בתיבת הדו-שיח Build Variants ב-Android Studio
בתיבת הדו-שיח Build Variants ב-Android Studio, יכול להיות שיופיעו הודעות שגיאה שמצביעות על התנגשויות בין וריאנטים של build, כמו:
השגיאה הזו לא מצביעה על בעיה ב-build של Gradle. היא מציינת שסביבת הפיתוח המשולבת (IDE) של Android Studio לא יכולה לפתור סמלים בין הווריאציות של המודולים שנבחרו.
לדוגמה, אם יש לכם מודול M1 שתלוי בווריאנט v1 של מודול M2, אבל ב-IDE נבחר וריאנט v2 של M2, יש לכם סמלים לא פתורים ב-IDE. נניח ש-M1 תלוי בכיתה שזמינה רק ב-v1. כשבוחרים ב-v2, הכיתה הזו לא ידועה ל-IDE. לכן, הוא לא מצליח לזהות את שם הכיתה ומוצגות שגיאות בקוד של המודול M1.
הודעות השגיאה האלה מופיעות כי ה-IDE לא יכול לטעון קוד לכמה וריאנטים בו-זמנית. עם זאת, מבחינת ה-build של האפליקציה, לגרסה שנבחרה בתיבת הדו-שיח הזו אין השפעה, כי Gradle יוצר את ה-build של האפליקציה עם קוד המקור שצוין במתכוני ה-build של Gradle, ולא על סמך מה שנטען כרגע ב-IDE.
שינוי הגדרת ההרצה/ניפוי הבאגים
כשמפעילים את האפליקציה בפעם הראשונה, Android Studio משתמש בהגדרת הפעלה שמוגדרת כברירת מחדל. הגדרת ההרצה מציינת אם לפרוס את האפליקציה מ-APK או מ-קובץ Android App Bundle, וגם את המודול להרצה, החבילה לפריסה, הפעילות להתחלה, מכשיר היעד, הגדרות האמולטור, אפשרויות Logcat ועוד.
הגדרת ברירת המחדל של הרצה/ניפוי באגים יוצרת קובץ APK, מפעילה את הפעילות שמוגדרת כברירת מחדל בפרויקט ומשתמשת בתיבת הדו-שיח Select Deployment Target כדי לבחור את מכשיר היעד. אם הגדרות ברירת המחדל לא מתאימות לפרויקט או למודול, אתם יכולים להתאים אישית את הגדרת ההרצה/ניפוי הבאגים או ליצור הגדרה חדשה ברמת הפרויקט, ברירת המחדל והמודול.
כדי לערוך הגדרת הרצה/ניפוי באגים, בוחרים באפשרות Run > Edit Configurations. מידע נוסף זמין במאמר יצירה ועריכה של הגדרות הרצה/ניפוי באגים.