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

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

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

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

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

הפעלת הגדרה ללא 'לפני ההפעלה' מובילה לשגיאת פריסה

הייתה בעיה ב-Android Studio Ladybug Feature Drop Canary 9 שגרמה להסרת מידע על הגדרות הרצה מפרויקטים שנפתחו בגרסה הזו. אם פתחתם את הפרויקט עם הגרסה הזו בשלב מסוים, והפעלת האפליקציה גורמת לשגיאה 'טעינת ארטיפקטים של build', צריך לוודא שבקטע 'לפני ההפעלה' של הגדרת ההפעלה הפעילה מופיע השלב 'Gradle-aware Make'. כדי לוודא זאת, לוחצים על Run/Debug Configurations > Edit Configurations, לוחצים על הגדרת ההרצה הפעילה ומוודאים שיש שלב Gradle-aware Make בקטע Before launch. לצערנו, Android Studio לא יכול לתקן את הבעיה הזו באופן אוטומטי כי יכול להיות שחלק מהגדרות ההרצה הוגדרו בכוונה בלי השלב 'Gradle-aware Make'.

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

כשפורסים שינויים בקוד למכשיר עם API 35 באמצעות האפשרות Apply Changes & Restart Activity (החלת שינויים והפעלה מחדש של הפעילות), האפליקציה לא מופעלת מחדש ולא רואים את ההשפעה של השינויים. אם מריצים מחדש את האפליקציה, אפשר לראות את ההשפעה של שינויי הקוד. הצוות שלנו בודק את הנושא.

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

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

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

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

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

אם אתם מבחינים שלא ניתן לבדוק את כל הצמתים של Compose כשאתם משתמשים בכלי לבדיקת פריסה, סביר להניח שזה נובע מבג שתוקן בגרסה 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 > Generate Signed Bundle / APK ומנסים להגדיר חתימת אפליקציה עבור App Bundle או 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. אם התהליך הזה נכשל, יכול להיות שסביבת הפיתוח המשולבת לא תופעל אצל משתמשים מסוימים שהגדירו אפשרויות VM מותאמות אישית בקובץ .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 Platforms (פלטפורמות SDK), מסמנים את התיבה 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 וגרסאות בטא של Android Studio היא PreviewX.Y במקום X.Y עבור <version>. לדוגמה, בגרסאות Canary של Android Studio 4.1 נעשה שימוש בספרייה AndroidStudioPreview4.1, במקום בספרייה AndroidStudio4.1 שמשמשת לגרסאות Release Candidate ולגרסאות יציבות.

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

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

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

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

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

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

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

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

עריכת קוד

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

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

יש אינטראקציות ידועות בין שירות ה-daemon של 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 תקרוס עם שגיאת פילוח.
  • פתרון עקיף 3: בודקים שוב את קיצורי הדרך כדי לוודא שקיצור הדרך להזנת הקלט הבא לא מוגדר ל-Control+Space, כי זה גם קיצור הדרך להשלמת הקוד ב-Android Studio. ב-Ubuntu 14.04 ‏ (Trusty),‏ Super+Space הוא קיצור הדרך שמוגדר כברירת מחדל, אבל יכול להיות שעדיין יש הגדרות מגרסאות קודמות. כדי לבדוק את קישורי קיצורי הדרך, מריצים את הפקודה ibus-setup בשורת הפקודה כדי לפתוח את חלון ההעדפות של IBus. בקטע מקשי קיצור, מסמנים את האפשרות שיטת הקלט הבאה. אם הוא מוגדר ל-Control+Space, משנים אותו ל-Super+Space או לקיצור דרך אחר לפי בחירתכם.

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

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

הסנכרון של Gradle נכשל: צינור שבור

הבעיה היא שתהליך ה-daemon של Gradle מנסה להשתמש ב-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. מידע נוסף זמין במדריך למשתמש בנושא IPv6 ברשת.

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

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

  • אם אתם משתמשים בשרת proxy, נסו להתחבר ישירות. אם החיבור הישיר פועל, יכול להיות שתצטרכו להשתמש ב-keytool כדי להוסיף את האישור של שרת ה-proxy לקובץ cacerts כדי להתחבר דרך ה-proxy.
  • מתקינים מחדש 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 משפיעה על גרסאות 7.0 ואילך של Android Gradle Plugin כי נדרשת גרסה 7.0 ואילך של Gradle. החל מ-Gradle 7.0, מעקב אחרי קבצים מופעל כברירת מחדל. אם אתם עובדים ב-Mac OS והפרויקט שלכם נשמר בתיקייה /System/Volumes/Data, מעקב Gradle אחרי שינויים בקבצים לא יפעל כמו שצריך. כתוצאה מכך, מערכת ה-Build לא תזהה שינויים בקבצים ולכן לא תעדכן את חבילות ה-APK. לאחר מכן, קוד הפריסה המצטברת לא יעשה דבר כי מצב ה-APK המקומי זהה למצב ה-APK במכשיר.

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

‫Android Emulator HAXM ב-macOS High Sierra

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

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

  3. אם מוצגת האזהרה אפשרות הטעינה נחסמה לתוכנת המערכת מהמפתח Intel Corporation Apps, לוחצים על אישור:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הוספת נקודות עצירה (breakpoint) ב-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/.

כלי ניפוי הבאגים המקורי קורס עם ההודעה 'תהליך ניפוי הבאגים הסתיים עם קוד יציאה 127'

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

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

בקטע הזה מתוארות בעיות מוכרות בכלי הפרופילים.

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

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

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

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

יכול להיות שתיתקלו בשגיאות מסוג 'ההקלטה לא הופסקה' ב-CPU Profiler של Android Studio כשבוחרים בהגדרות 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, יכול להיות שהניפוי באגים המקורי וה-Profilers של Android Studio לא יפעלו בצורה תקינה, ויכול להיות שתופיע הודעת השגיאה AdbCommandRejectedException או Failed to connect port בקובץ כשבוחרים באפשרות Help > Show Log (עזרה > הצגת יומן).idea.log שדרוג כלי הפלטפורמה לגרסה 29.0.4 ואילך פותר את שתי הבעיות.

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

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

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

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

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

השימוש בתוסף CMake simple highlighter מונע את הצגת התוכן בחלון Build Output. הגרסה מתבצעת ומופיעה הכרטיסייה 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 ברשימת מיפויי המקשים. מידע נוסף זמין כאן.

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

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

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

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

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

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

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

יכול להיות שלא תהיה אפשרות לשנות את נתוני הפלט של הווריאנטים בזמן הבנייה

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

// 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() כדי לקבל את קובץ המניפסט לכל וריאציה, אפשר להתקשר אל 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)
        }
    }
}

בעיות בתמיכה ב-AGP 7.3.0 AIDL וב-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

  • חסר פלט של lint: לא מודפס פלט טקסט של lint ב-stdout כשהמשימה של lint היא UP-TO-DATE (בעיה מספר 191897708). תוקן ב-AGP 7.1.0-alpha05.
  • בעיות בבדיקת יחידות של פרויקט אפליקציה שמשתמש בתוסף Hilt: נתיב המחלקה של בדיקת היחידות מכיל את מחלקות האפליקציה שלא עברו אינסטרומנטציה, כלומר 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

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

תוקן ב-Android Studio 3.6

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

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

תוקן ב-Android Studio 3.5.2

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

תוקן ב-Android Studio 3.3.1

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

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