בעיות מוכרות ב-Android Studio ובפלאגין Android Gradle

בדף הזה מתועדות בעיות ידועות ב-Android Studio Ladybug ובפלאגין Android Gradle בגרסה 8.7.0. אם נתקלתם בבעיה שלא מופיעה כאן, תוכלו לדווח על באג.

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

בעיות מוכרות ב-Android Studio

בקטע הזה מתוארות בעיות ידועות בגרסה היציבה האחרונה של Android Studio.

האפשרות 'החלת השינויים והפעלה מחדש של הפעילות' לא מפעילה מחדש את הפעילות במכשירים או במהדמנים עם API ברמה 35

כשפורסים שינויים בקוד במכשיר API 35 באמצעות 'החלת השינויים והפעלה מחדש של הפעילות', האפליקציה לא מופעלת מחדש ולא רואים את ההשפעה של השינויים. אם תפעילו מחדש את האפליקציה, תוכלו לראות את ההשפעה של השינויים בקוד. הצוות שלנו בודק את הנושא.

חלון Assistant של Firebase מציג הודעת שגיאה

אם מוצגת הודעת שגיאה בחלון של Firebase Assistant ('כלים' > 'Firebase' בתפריט הראשי), צריך לבטל את התוקף של המטמון ולהפעיל מחדש את Android Studio כדי לתקן את השגיאה.

אי אפשר לבודד תצוגה באמצעות הכלי לבדיקת פריסות

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

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

אם שמתם לב שלא ניתן לבדוק את כל הצמתים ב-Compose כשמשתמשים ב-Layout Inspector, סביר להניח שמדובר באג שטופל בגרסה 1.5.0-alpha04 של Compose. אם נתקלת בבעיה הזו, עליך לוודא שדרגת את Compose לגרסה 1.5.0-alpha04 ואילך.

שגיאה בזמן העיבוד של התצוגה המקדימה של 'כתיבה'

החל מ-Android Studio Chipmunk, אם מופיעה הודעת השגיאה java.lang.NoSuchFieldError: view_tree_saved_state_registry_owner או java.lang.ClassNotFoundException: androidx.savedstate.R$id בחלונית הבעיות, צריך לכלול במודול יחסי תלות של debugImplementation ל-androidx.lifecycle:lifecycle-viewmodel-savedstate.

אם מופיעה הודעת השגיאה java.lang.NoSuchFieldError: view_tree_lifecycle_owner בחלונית הבעיות, צריך לכלול במודול יחסי תלות של debugImplementation ל-androidx.lifecycle:lifecycle-runtime.

אם מופיעה הודעת השגיאה java.lang.NoClassDefFoundError: Could not initialize class androidx.customview.poolingcontainer.PoolingContainer או java.lang.NoClassDefFoundError: androidx/customview/poolingcontainer/PoolingContainerListener בחלונית הבעיות, צריך לכלול במודול יחסי תלות של debugImplementation ל-androidx.customview:customview-poolingcontainer.

שגיאה כשמשתמשים בסיסמאות שונות למפתח ולמאגר המפתחות

החל מגרסה 4.2, Android Studio פועלת עכשיו ב-JDK 11. העדכון הזה גורם לשינוי בהתנהגות הבסיסית שקשור למפתחות החתימה.

כשעוברים אל Build > GenerateSigned Bundle / APK ומנסים להגדיר חתימה על אפליקציה לחבילת אפליקציות או ל-APK, הזנת סיסמאות שונות למפתח ולמאגר המפתחות עשויה לגרום לשגיאה הבאה:

Key was created with errors:
Warning: Different store and Key passwords not supported for PKCS12 Key stores

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

Android Studio לא מופעל אחרי התקנת גרסה 4.2

Studio מנסה לייבא קובצי vmoptions קודמים ולנקות אותם כדי שיוכלו לפעול עם מנקה האשפה שמשמש את JDK 11. אם התהליך הזה נכשל, יכול להיות שה-IDE לא יופעל אצל משתמשים מסוימים שהגדירו אפשרויות מותאמות אישית של מכונות וירטואליות בקובץ ‎.vmoptions.

כדי לעקוף את הבעיה, מומלץ להוסיף הערה לאפשרויות בהתאמה אישית בקובץ vmoptions. (באמצעות התו '#'). קובץ ‎.vmoptions נמצא במיקומים הבאים:

Windows

C:\Users\YourUserName\AppData\[Local|Roaming]\Google\AndroidStudio4.2\studio64.exe.vmoptions

macOS

~/Library/Application Support/Google/AndroidStudio4.2/studio.vmoptions

Linux

~/.config/Google/AndroidStudio4.2/studio64.vmoptions

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

אפליקציות שמשתמשות בכלי לבדיקת מסדי נתונים קורסות באמולטור של Android 11

אפליקציות שמשתמשות בכלי לבדיקת מסדי נתונים עשויות לקרוס כשהן פועלות במהלך הדמיה של Android 11, ועשויה להופיע ב-logcat שגיאה כמו זו:

 Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)

כדי לפתור את הבעיה, צריך לשדרג את המהדר של Android 11 לגרסה 9 ואילך. לשם כך, עוברים אל Tools (כלים) > SDK Manager (מנהל SDK). בכרטיסייה SDK Platforms, מסמנים את התיבה Show Package Details ובוחרים גרסה 9 ואילך של אמולטור Android 11.

Studio לא מופעל אחרי השדרוג

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

ב-Android Studio מגרסה 4.1 ואילך:

  • Windows: %APPDATA%\Google\AndroidStudio<version>
    דוגמה: C:\Users\your_user_name\AppData\Roaming\Google\AndroidStudio4.1

  • macOS: ~/Library/Application Support/Google/AndroidStudio<version>
    דוגמה: ~/Library/Application Support/Google/AndroidStudio4.1

  • Linux: ~/.config/Google/AndroidStudio<version> ו-~/.local/share/Google/AndroidStudio<version>
    דוגמה: ~/.config/Google/AndroidStudio4.1 ו-~/.local/share/Google/AndroidStudio4.1

ב-Android Studio 4.0 וגרסאות קודמות:

  • Windows: %HOMEPATH%\.AndroidStudio<version>\config
    דוגמה: C:\Users\your_user_name\.AndroidStudio3.6\config

  • macOS: ~/Library/Preferences/AndroidStudio<version>
    דוגמה: ~/Library/Preferences/AndroidStudio3.6

  • Linux: ~/.AndroidStudio<version>/config
    דוגמה: ~/.AndroidStudio3.6/config

חשוב לזכור שספריית התצורה של גרסאות Canary ו-Beta של Android Studio היא PreviewX.Y במקום X.Y עבור <version>. לדוגמה, גרסאות build של Android Studio 4.1 Canary משתמשות ב-AndroidStudioPreview4.1, במקום בספרייה AndroidStudio4.1 שמשמשת לגרסאות Release Candidate ולגרסאות יציבות.

בעיה ב-compilation בפרויקטים של Kotlin לפלטפורמות מרובות

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

התנגשויות במיפוי מקשים ב-Linux

ב-Linux, מקשי קיצור מסוימים מתנגשים עם מקשי הקיצור שמוגדרים כברירת מחדל ב-Linux ועם מקשי הקיצור של מנהלי חלונות פופולריים, כמו KDE ו-GNOME. יכול להיות שמקשי הקיצור המתנגשים האלה לא יפעלו כצפוי ב-Android Studio.

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

טקסט קטן בממשק המשתמש ב-ChromeOS

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

  1. לוחצים על קובץ > הגדרות כדי לפתוח את החלון הגדרות.
  2. עוברים אל מראה והתנהגות > מראה.
  3. בוחרים באפשרות שימוש בגופן בהתאמה אישית.
  4. להגדיל את גודל הגופן.
  5. בחלון הגדרות, עוברים אל עריכה > גופן.
  6. להגדיל את גודל הגופן.
  7. לוחצים על אישור.

עריכת קוד

בקטע הזה מתוארות בעיות ידועות שקשורות לעורך הקוד.

קלט מקלדת קפוא – בעיות ב-'iBus' ב-Linux

יש אינטראקציות ידועות בין הדימון iBus ב-Linux לבין Android Studio. בתרחישים מסוימים, סביבת הפיתוח האינטגרטיבית מפסיקה להגיב לקלט מהמקלדת או מתחילה להזין תווים אקראיים. הבאג הזה נגרם בגלל סנכרון חסר בין iBus ל-XLib + AWT, והוא כבר דווח ל-JetBrains ול-iBus. יש כרגע שלושה פתרונות עקיפים לבעיה הזו:

  • פתרון עקיף 1: מאלצים את iBus לעבור למצב סינכרוני. לפני שמפעילים את Android Studio, מריצים את הפקודה הבאה בשורת הפקודה: 
    $ IBUS_ENABLE_SYNC_MODE=1 ibus-daemon -xrd
  • פתרון עקיף 2: משביתים את הקלט של iBus ב-Android Studio. כדי להשבית את הקלט של iBus רק ב-Android Studio, מריצים את הפקודה הבאה בשורת הפקודה: 
    $ XMODIFIERS= ./bin/studio.sh
    הפתרון החלופי הזה משבית רק את שיטות הקלט ב-Android Studio, ולא באפליקציות אחרות שאתם מריצים. חשוב לזכור שאם תפעילו מחדש את הדימון בזמן ש-Android Studio פועל (לדוגמה, על ידי הפעלת ibus-daemon -rd), תשביתו בפועל את שיטות הקלט של כל האפליקציות האחרות, ויכול להיות שתגרמו גם לקריסה של JVM של Android Studio בגלל שגיאת חלוקה (segmentation fault).
  • פתרון עקיף 3: בודקים שוב את קישורי המקשי הקיצור כדי לוודא שמקשי הקיצור להזנת הקלט הבא לא מוגדרים כ-Control+Space, כי אלה גם מקשי הקיצור להשלמת הקוד ב-Android Studio. ב-Ubuntu 14.04 (Trusty) המקש Super+Space הוא קיצור הדרך שמוגדר כברירת מחדל, אבל יכול להיות שההגדרות מהגרסאות הקודמות עדיין קיימות. כדי לבדוק את קישורי המקשי הקיצור, מריצים את הפקודה ibus-setup בשורת הפקודה כדי לפתוח את חלון ההעדפות של IBus. בקטע מקשי קיצור, מסמנים את האפשרות שיטת הקלט הבאה. אם ההגדרה היא Control+Space, משנים אותה ל-Super+Space או למקש קיצור אחר לבחירתכם.

הגדרות אישיות של פרויקט

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

Gradle Sync Failed: Broken Pipe

הבעיה היא ש-Gradle daemon מנסה להשתמש ב-IPv4 במקום ב-IPv6.

  • פתרון עקיף 1: ב-Linux, מוסיפים את הקטע הבא לקובץ ~/.profile או ~/.bash_profile: 
    export _JAVA_OPTIONS="-Djava.net.preferIPv6Addresses=true"
  • פתרון חלופי 2: בקובץ vmoptions של Android Studio, משנים את השורה -Djava.net.preferIPv4Addresses=true לשורה -Djava.net.preferIPv6Addresses=true. למידע נוסף, אפשר לעיין במדריך למשתמש בנושא Networking IPv6.

שגיאות מסוג 'peer not authenticated' (הצד השני לא מאומת) מסנכרון Gradle או מ-SDK Manager

הסיבה העיקרית לשגיאות האלה היא אישור חסר ב-$JAVA_HOME/jre/lib/certificates/cacerts. כדי לפתור את השגיאות האלה, צריך לפעול לפי השלבים הבאים:

  • אם אתם מאחורי שרת proxy, נסו להתחבר ישירות. אם החיבור הישיר פועל, כדי להתחבר דרך שרת ה-proxy יכול להיות שתצטרכו להשתמש ב-keytool כדי להוסיף את האישור של שרת ה-proxy לקובץ cacerts.
  • מתקינים מחדש JDK נתמך ללא שינוי. יש בעיה מוכרת שמשפיעה על משתמשי Ubuntu, וכתוצאה מכך /etc/ssl/certs/java/cacerts ריק. כדי לעקוף את הבעיה, מריצים את הפקודה הבאה בשורת הפקודה: 
    sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

פריסה

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

[Mac OS בלבד] עדכונים מצטברים לא חלים עקב בעיה במעקב אחר קבצים ב-Gradle בפרויקטים שנשמרו ב-/System/Volumes/Data

בעיה 18149 ב-Gradle משפיעה על הפלאגין של Android Gradle בגרסה 7.0 ואילך, כי נדרשת בו גרסה 7.0 ואילך של Gradle. החל מגרסה 7.0 של Gradle, מעקב אחר קבצים מופעל כברירת מחדל. אם אתם עובדים ב-Mac OS והפרויקט שלכם נשמר בתיקייה /System/Volumes/Data, מעקב הקבצים של Gradle לא יתעד כראוי את השינויים בקבצים. כתוצאה מכך, מערכת ה-Build לא תזהה שינויים בקובץ ולכן לא תעדכן את חבילות ה-APK. במקרה כזה, קוד הפריסה המצטבר לא יבצע שום פעולה כי מצב ה-APK המקומי זהה למצב במכשיר.

כדי לעקוף את הבעיה, צריך להעביר את הספרייה של הפרויקט לספריית המשתמש, כלומר, ל-/Users/username. לאחר מכן, מערכת ה-build תקבל הודעה על שינויים בקובץ באמצעות מעקב הקבצים של Gradle, והשינויים המצטברים יוחלו בהצלחה.

Android Emulator HAXM ב-macOS High Sierra

כדי לקבל את התאימות והיציבות הטובות ביותר עם macOS, נדרש HAXM מגרסה 6.2.1 ואילך ב-Android Emulator ב-macOS High Sierra (10.13). עם זאת, ב-macOS 10.13 התהליך של התקנת תוספים לליבה כמו HAXM מורכב יותר. צריך לאפשר באופן ידני את ההתקנה של תוסף הליבה עצמו באופן הבא:

  1. קודם כול, מנסים להתקין את הגרסה האחרונה של HAXM ממנהל ה-SDK.
  2. ב-MacOS, עוברים אל העדפות המערכת > אבטחה ופרטיות.

  3. אם מופיעה ההתראה System software from developer "Intel Corporation Apps" was blocked from loading (אפשרות הטעינה נחסמה לתוכנת המערכת מהמפתח 'Intel Corporation Apps'), לוחצים על Allow (אישור):

מידע נוסף ופתרונות זמינים בדף האינטרנט הזה של Apple וב בעיה 62395878.

החלת השינויים

בקטע הזה מתוארות בעיות ידועות שקשורות להחלת השינויים.

שם האפליקציה החדש לא הוחל

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

בעיה בסביבת זמן הריצה של Android שגורמת להצגת שגיאה

אם אתם משתמשים במכשיר עם Android מגרסה 8.0 או 8.1, יכול להיות שתראו את ההודעה 'VERIFICATION_ERROR' כשתנסו להחיל שינויים מסוגים מסוימים (במיוחד אם אתם משתמשים ב-Kotlin). ההודעה הזו נובעת מבעיה ב-Android Runtime, ותוקנה ב-Android 9.0 ואילך. למרות שהבעיה גורמת לכך שהפעולה Apply Changes תיכשל, עדיין תוכלו להריץ סמל ההפעלהאת האפליקציה שוב כדי לראות את השינויים. עם זאת, מומלץ לשדרג את המכשיר ל-Android מגרסה 9.0 ואילך.

ניפוי באגים ובדיקה

בקטע הזה מתוארות בעיות ידועות שקשורות לניפוי באגים ובדיקה של האפליקציה.

בדיקות JUnit של משאבים חסרים ב-classpath כשמריצים מ-Android Studio

אם יש לכם תיקיות משאבים ספציפיות במודולים של Java, המשאבים האלה לא יימצאו כשמריצים בדיקות מ-IDE. אפשר להריץ בדיקות באמצעות Gradle משורת הפקודה. אפשר גם להריץ את המשימה check של Gradle מה-IDE. פרטים נוספים זמינים בבעיה 64887.

הבעיה הזו מתרחשת בגלל שבגרסה 13 של IntelliJ צריך רק תיקייה אחת בתור classpath. ה-builder של IntelliJ מעתיק את כל המשאבים לתיקיית ה-build הזו, אבל Gradle לא מעתיק את המשאבים.

  • פתרון עקיף 1: מריצים את המשימה check של Gradle מה-IDE במקום להריץ בדיקת יחידה.
  • פתרון עקיף 2: מעדכנים את סקריפט ה-build כדי להעתיק את המשאבים באופן ידני לתיקיית ה-build. מידע נוסף זמין בתגובה מס' 13.

הרצת בדיקות JUnit עשויה לגרום לקמפל את הקוד פעמיים

כשיוצרים פרויקט חדש, יכול להיות שההגדרה של תבנית JUnit תיווצר עם שני שלבים של 'לפני ההשקה': Make ו-Make עם תמיכה ב-Gradle. לאחר מכן, ההגדרה הזו מועברת לכל הגדרות ההרצה של JUnit שנוצרו.

  • כדי לפתור את הבעיה בפרויקט הנוכחי, לוחצים על Run > Edit Configurations ומשנים את הגדרת ברירת המחדל של JUnit כך שתכלול רק את שלב ה-Make שתומך ב-Gradle.
  • כדי לפתור את הבעיה בכל הפרויקטים העתידיים, לוחצים על קובץ > סגירת הפרויקט. אמור להופיע מסך הפתיחה. לאחר מכן לוחצים על Configure > Project Defaults > Run Configurations ומשנים את ההגדרה של JUnit כך שתכלול רק את שלב ה-Make שתומך ב-Gradle.

חלק מההגדרות של הרצה לבדיקה לא פועלות

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

  • הגדרות ההרצה של Gradle (שסמלן הוא הלוגו של Gradle) לא פועלות.
  • הגדרות ההרצה של JUnit (שיש להן סמל ללא Android ירוק) לא חלות על בדיקות של מכשירי מדידה, שאי אפשר להריץ ב-JVM המקומי.
בנוסף, Android Studio שומר את הגדרת ההרצה שנוצרה בהקשר נתון (למשל, לחיצה ימנית על שיטה או כיתה ספציפית), ולא יציע להריץ בהגדרה אחרת בעתיד. כדי לפתור את הבעיה, לוחצים על Run > Edit Configurations ומסירים את ההגדרות שנוצרו באופן שגוי.

הוספת נקודות עצירה ב-Java בזמן ניפוי באגים בקוד מקורי

כשהאפליקציה מושהית בנקודת עצירה בקוד המקורי, יכול להיות שמאתרי הבאגים Auto ו-Dual לא יזהו באופן מיידי נקודות עצירה חדשות ב-Java שהגדרתם. כדי למנוע את הבעיה הזו, מוסיפים נקודות עצירה ב-Java לפני שמתחילים סשן ניפוי באגים או בזמן שהאפליקציה מושהית בנקודת עצירה ב-Java. מידע נוסף זמין בבעיה 229949.

יציאה מכלי הניפוי הבאגים המקורי

כשמשתמשים במנטר הבאגים Auto או Dual כדי לנפות באגים בקוד Java ובקוד מקומי, אם נכנסים לפונקציה מקומית מתוך קוד Java (לדוגמה, מנטר הבאגים משהה את הביצוע בשורה בקוד Java שמפעילה פונקציה מקומית, ולוחצים על Step Into ) ואתם רוצים לחזור לקוד Java, לוחצים על Resume Program (במקום על Step Out או על Step Over ). תהליך האפליקציה עדיין יושהה, לכן צריך ללחוץ על Resume Program בכרטיסייה your-module-java כדי להמשיך אותו. מידע נוסף זמין בבעיה 224385.

תהליך ניפוי הבאגים המקורי נתקע בזמן טעינת ספריות

כשמשתמשים בניפוי הבאגים המקורי בפעם הראשונה אחרי השדרוג ל-Android Studio 4.2 ואילך, יכול להיות שהוא יפסיק להגיב בזמן טעינת הספריות ממכשיר Android. זוהי בעיה קשה שעדיין מתרחשת גם אם מפסיקים ומפעילים מחדש את מנתח הבאגים. כדי לפתור את הבעיה, צריך למחוק את המטמון של LLDB ב-$USER/.lldb/module-cache/.

הכלי לניפוי באגים מקורי קורס עם הודעת השגיאה "Debugger process finished with exit code 127"

השגיאה הזו מתרחשת בפלטפורמות מבוססות-Linux כשמפעילים את מנתח הבאגים המקורי. המשמעות היא שספרייה אחת שנדרשת לניפוי הבאגים המקורי לא מותקנת במערכת המקומית. יכול להיות ששם הספרייה החסרה כבר מודפס בקובץ idea.log. אם לא, תוכלו להשתמש במסוף כדי לנווט לספריית ההתקנה של Android Studio ולהריץ את שורת הפקודה bin/lldb/bin/LLDBFrontend --version כדי לבדוק אילו ספריות חסרות. בדרך כלל, הספרייה החסרה היא ncurses5 כי חלק מההפצות האחרונות של Linux כבר שודרגו ל-ncurses6.

כלים לניתוח ביצועים (profilers)

בקטע הזה מתוארות בעיות ידועות ב-Profilers.

Native Memory Profiler: הפרופיילינג לא זמין במהלך הפעלת האפליקציה

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

כפתרון עקיף, אפשר להשתמש בכלי הניתוח של שורת הפקודה העצמאי של Perfetto כדי לתעד פרופילים של הפעלה.

שגיאות זמן קצוב ב-CPU Profiler

יכול להיות שתקבלו את השגיאה 'הקלטה נכשלה להפסיק' ב-Android Studio CPU Profiler כשתבצעו את ההגדרות Sample Java Methods או Trace Java Methods. לרוב מדובר בשגיאות זמן קצוב פג, במיוחד אם מוצגת הודעת השגיאה הבאה בקובץ idea.log:

Wait for ART trace file timed out

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

אם נתקלתם בבעיות של זמן קצוב לתפוגה ב-Profiler, עליכם לשלוח דוח באג שכולל את היצרן או הדגם של המכשירים ואת כל הרשומות הרלוונטיות מ-idea.log ומ-logcat.

חריגה ב-ADB במהלך ניפוי באגים או יצירת פרופיל

כשמשתמשים ב-Platform Tools 29.0.3, יכול להיות שהניפוי באגים המקורי והכלי לניתוח ביצועים של Android Studio לא יפעלו כראוי, ויכול להיות שתופיע הודעת השגיאה 'AdbCommandRejectedException' או 'Failed to connect port' בקובץ idea.log כשבוחרים באפשרות Help > Show Log. שדרוג של Platform Tools לגרסה 29.0.4 ואילך פותר את שתי הבעיות.

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

  1. פותחים את SDK Manager מ-Android Studio בלחיצה על Tools > SDK Manager או על SDK Manager בסרגל הכלים.

  2. מסמנים את התיבה לצד Android SDK Platform-Tools. סמל ההורדה אמור להופיע בעמודה הימנית.

  3. לוחצים על אישור או על אישור.

פלאגין מונע את הפעולה של חלון הפלט של ה-build

שימוש בפלאגין CMake simple highlighter מונע את הצגת התוכן בחלון Build Output. ה-build פועל והכרטיסייה Build Output מופיעה, אבל לא מודפס פלט (בעיה מס' 204791544).

סדר ההתקנה מונע הפעלה

התקנה של גרסה חדשה יותר של Android Studio לפני גרסה ישנה יותר עלולה למנוע את ההפעלה של הגרסה הישנה יותר. לדוגמה, אם קודם מתקינים את גרסת ה-Canary של Android Studio ואז מנסים להתקין ולהפעיל את הגרסה היציבה, יכול להיות שהגרסה היציבה לא תופעל. במקרים כאלה, צריך לנקות את המטמון כדי להפעיל את הגרסה היציבה (הישנה). ב-macOS, כדי לנקות את המטמון, מוחקים את הספרייה Library/ApplicationSupport/Google/AndroidStudioversion_number. ב-Windows, כדי לנקות את המטמון משתמשים בניקוי הדיסק.

Espresso Test Recorder לא פועל עם Compose

Espresso Test Recorder לא פועל בפרויקטים שכוללים Compose. במאמר בדיקת הפריסה של Compose מוסבר איך יוצרים בדיקות ממשק משתמש לפרויקטים שכוללים את Compose.

מקשי הקיצור של Logcat מתנגשים במבנים של מקלדות שאינן באנגלית

אם אתם משתמשים במבנה מקלדת שאינו אנגלי, מקשי הקיצור שמוגדרים כברירת מחדל ב-Logcat עשויים להתנגש עם המבנה ולמנוע מכם להקליד תווים מסוימים כשאתם עורכים טקסט ב-Android Studio. כדי לעקוף את הבעיה, צריך למחוק את מפת המפתחות של Logcat שנמצאת בהתנגשות או למפות אותה מחדש. כדי לערוך את מפות המפתחות של Logcat ב-Android Studio, עוברים אל Android Studio > Settings > Keymap ומחפשים את Logcat ברשימת מפות המפתחות. מידע נוסף זמין בבעיה מס' 263475910.

הבעיה הזו תיפתר על ידי הסרת קיצור הדרך של Logcat בתיקון 1 של Android Studio Electric Eel.

בעיות ידועות בפלאגין של Android Gradle

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

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

כשמריצים איתור שגיאות בקוד עם checkDependencies = true מתוך מודול של אפליקציה, יחסי התלות בספריות של תכונות דינמיות לא נבדקים אלא אם הם גם יחסי תלות של האפליקציה (בעיה מס' 191977888). כדי לעקוף את הבעיה, אפשר להריץ את המשימה lint בספריות האלה.

חתימה על קובץ ששמו מכיל תווים של חזרה לתחילת השורה

חתימה על קובצי JAR (סכימת v1) לא תומכת בשמות קבצים שמכילים תווים של העברת שורה (בעיה מס' 63885809).

שינוי של פלטי הווריאציות בזמן ה-build עשוי שלא לפעול

השימוש ב-Variant API כדי לשנות את הפלט של הווריאנטים לא עובד עם הפלאגין החדש. הוא עדיין פועל למשימות פשוטות, כמו שינוי שם ה-APK במהלך ה-build, כפי שמתואר בהמשך: 

// If you use each() to iterate through the variant objects,
// you need to start using all(). That's because each() iterates
// through only the objects that already exist during configuration time—
// but those object don't exist at configuration time with the new model.
// However, all() adapts to the new model by picking up object as they are
// added during execution.
android.applicationVariants.all { variant ->
    variant.outputs.all {
        outputFileName = "${variant.name}-${variant.versionName}.apk"
    }
}

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

הפרמטר manifestOutputFile לא זמין יותר

השיטה processManifest.manifestOutputFile() כבר לא זמינה, ומתקבלת השגיאה הבאה כשקוראים לה: 

A problem occurred configuring project ':myapp'.
   Could not get unknown property 'manifestOutputFile' for task
   ':myapp:processDebugManifest' of type
   com.android.build.gradle.tasks.ProcessManifest.

במקום להפעיל את manifestOutputFile() כדי לקבל את קובץ המניפסט של כל וריאנט, אפשר להפעיל את processManifest.manifestOutputDirectory() כדי להחזיר את הנתיב של הספרייה שמכילה את כל המניפסטים שנוצרו. לאחר מכן תוכלו לאתר מניפסט ולהחיל עליו את הלוגיקה שלכם. בדוגמה הבאה מוצג שינוי דינמי של קוד הגרסה במניפסט:

android.applicationVariants.all { variant ->
    variant.outputs.all { output ->
        output.processManifest.doLast {
            // Stores the path to the maifest.
            String manifestPath = "$manifestOutputDirectory/AndroidManifest.xml"
            // Stores the contents of the manifest.
            def manifestContent = file(manifestPath).getText()
            // Changes the version code in the stored text.
            manifestContent = manifestContent.replace('android:versionCode="1"',
                    String.format('android:versionCode="%s"', generatedCode))
            // Overwrites the manifest with the new text.
            file(manifestPath).write(manifestContent)
        }
    }
}

בעיות בתמיכה ב-AIDL ב-AGP 7.3.0 וב-Kotlin 1.7.x

שימוש ב-AGP 7.3.0 עם KAPT ב-Kotlin 1.7.x גורם להסרת קבוצות המקור של AIDL לגרסאות build ספציפיות. עדיין תוכלו להשתמש בקבוצות המקור האחרות של AIDL, כולל אלה של main/, סוגים של גרסאות build, טעמים של מוצרים ושילובים של טעמים של מוצרים. אם אתם צריכים להשתמש בקבוצות המקור של AIDL שספציפיות לגרסה, המשיכו להשתמש ב-Kotlin 1.6.21.

בעיות ידועות שתוקנו

בקטע הזה מתוארות בעיות ידועות שתוקנו במהדורה האחרונה. אם נתקלת באחת מהבעיות האלה, עליך לעדכן את Android Studio לגרסה היציבה האחרונה או לגרסת הבטא האחרונה.

הבעיה נפתרה ב-Android Studio 2021.1.1

  • חסר פלט של איתור שגיאות בקוד: אין פלט טקסט של איתור שגיאות בקוד שמודפס ב-stdout כשמשימה האיתור היא UP-TO-DATE (בעיה מס' 191897708). התיקון מופיע ב-AGP 7.1.0-alpha05.
  • בעיות בבדיקות יחידה של פרויקט אפליקציה שמשתמש בפלאגין Hilt: נתיב ה-classpath של בדיקת היחידה מכיל את כיתות האפליקציה שלא עברו הטמעה, כלומר Hilt לא מטמיע את כיתות האפליקציה כדי לטפל בהזרקת יחסי התלות כשמריצים בדיקות יחידה (בעיה מס' 213534628). תוקנה ב-AGP 7.1.1.

הבעיה נפתרה ב-Android Studio 2020.3.1

  • החרגות של Lint בפרויקטים של Kotlin: בפרויקטים של Kotlin שמגדירים את checkDependencies = true עשויות להתרחש שגיאות או חריגות של נקודת הצבעה null (בעיה מס' 158777858).

הבעיה נפתרה ב-Android Studio 4.2

  • IDE קופא ב-macOS Big Sur: יכול להיות ש-Android Studio 4.1 יקפא כשפותחים תיבת דו-שיח.

הבעיה נפתרה ב-Android Studio 4.1

  • הפעלה מחדש כדי להחיל את הגדרות הזיכרון מהגרסה הקודמת של סביבת הפיתוח המשולבת: אחרי שמעדכנים את Android Studio, צריך להפעיל מחדש את Android Studio כדי להחיל את הגדרות הזיכרון שהועברו מגרסה קודמת של סביבת הפיתוח המשולבת.
  • המערכת לא יוצרת יותר כברירת מחדל את הכיתה של המניפסט עם מחרוזות ההרשאות בהתאמה אישית: אם רוצים ליצור את הכיתה, צריך להגדיר את הערך android.generateManifestClass = true.

הבעיה נפתרה ב-Android Studio 3.6

  • שגיאה בהתקנת APK ב-LineageOS: ייתכן שהפריסה של האפליקציה במכשירים עם גרסאות מסוימות של LineageOS או CyanogenMod תיכשל ותגרום להשלכת חריגה מסוג INSTALL_PARSE_FAILED_NOT_APK.

    ב-Android Studio 3.6 Beta 1 ואילך, סביבת הפיתוח המשולבת מטפלת בחריג הזה על ידי ביצוע התקנה מלאה של האפליקציה כשפורסים אותה במכשירי LineageOS או CyanogenMod. כתוצאה מכך, ייתכן שיחלפו זמנים ארוכים יותר עד לפריסה.

הבעיה נפתרה ב-Android Studio 3.5.2

  • סגנון קוד XML שגוי: כשעורכים קוד XML, סגנון הקוד שגוי כשבוחרים באפשרות Code > Reformat Code בסרגל התפריטים.

הבעיה נפתרה ב-Android Studio 3.3.1

  • שגיאות של חוסר זיכרון בסריקה של פרויקטים מבוססי C++‎: כש-Gradle סורק פרויקט שכולל קוד C++‎ ביותר ממיקום אחד באותו כונן, הסריקה כוללת את כל הספריות שמתחת לספרייה המשותפת הראשונה. סריקת מספר גדול של ספריות וקבצים עלולה להוביל לשגיאות של 'אין מספיק זיכרון'.

    למידע נוסף על הבעיה הזו, אפשר לקרוא את הבאג שמשויך אליה.