שדרוג הגרסאות של יחסי התלות

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

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

הערה: בדיקות אפליקציה טובות הן המפתח להבטיח שהשדרוגים לא יגרמו לשיבושים ב-build או באפליקציה בדרכים בלתי צפויות.

שדרוג האסטרטגיה

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

יצירת ספרייה	האם אתם מפתחים אפליקציה שמשתמשים מורידים ומפעילים במכשיר? או שאתם יוצרים ספרייה כדי לעזור למפתחים אחרים ליצור אפליקציות? אם אתם מפתחים אפליקציה, עליכם להתמקד בשמירה על עדכניות ויציבות של האפליקציה. אם אתם מפתחים ספרייה, כדאי להתמקד באפליקציות של מפתחים אחרים. השדרוגים משפיעים על הצרכנים שלכם. אם משדרגים אחת מהתלות, הגרסה הזו הופכת למועמדת לפתרון התלות ב-Gradle, ויכול להיות שהשימוש של האפליקציה בתלות הזו ייפגע. קודם כול, צמצום יחסי התלות של הספרייה ככל האפשר. ככל שיש לכם פחות יחסי תלות, כך ההשפעה על פתרון יחסי התלות של הצרכן קטנה יותר. חשוב לפעול בהתאם לשיטת ניהול הגרסאות הסמנטית כדי לציין את סוגי השינויים שאתם מבצעים. לדוגמה, AndroidX פועל לפי תיוג גרסת סמנטית ומוסיף סכימה לתיוג גרסת טרום-השקה. נסו להימנע משדרוגים לגרסה major כדי לא לגרום לשיבושים אצל הצרכנים. כדאי ליצור גרסה מועמדת להשקה (RC) של הספרייה כדי שהמשתמשים יוכלו לבדוק אותה בשלב מוקדם. בהנחיות בנושא תאימות לאחור לכותבי ספריות מוסבר איך לשמור על תאימות של ממשק ה-Application Binary Interface ‏ (ABI) של הספרייה. כדאי להשתמש בכלים ובבדיקות אינטגרציה כמו Binary compatibility validator כדי לוודא ששינויי ה-ABI תואמים לשינוי הגרסה המיועד. אם תפיצו תיקונים ב-patch לגרסאות נמוכות יותר של הספרייה, הצרכנים לא יצטרכו לשדרג את הספרייה לגרסה הבאה של major או minor, אלא אם הם רוצים תכונות חדשות. מומלץ להימנע משדרוג של יחסי תלות טרנזיטיביים בשדרוגים האלה. אם השדרוג של הספרייה מחייב שינויים משמעותיים שעשויים להיות קשים במיוחד לצרכנים, כדאי לשקול לפרסם אותם כפריט חדש כדי שהגרסה הישנה והגרסה החדשה יוכלו להתקיים זו לצד זו ולאפשר השקה הדרגתית יותר. הערה: אם השדרוג של אחת מהתלות מכיל שינוי משמעותי ב-API, מומלץ לשדרג אותו במהדורה major או minor ולבצע את השינויים הנדרשים. אם לא תעשו זאת, משתמשים בספרייה שלכם עשויים לעשות זאת, וכתוצאה מכך יהיו אי-תאימות בין הספרייה לבין הספרייה התלויה. יכול להיות שהדבר יקרה גם אם לא יהיו שינויים בספרייה. אפשר לפרסם גרסה חדשה רק כדי לשדרג את התלות הזו.
מחזור הפצה	באיזו תדירות אתם משחררים את האפליקציה או הספרייה? מחזורי פיתוח והשקה קצרים יותר נותר פחות זמן לשדרוג. אתם יכולים להיעזר בהם כדי לא להתעכב. שדרוגים קטנים תכופים יכולים להקל על עומס העבודה. אם שדרוג של ספרייה יגרום לבעיות, תוכלו לבטל את השדרוג מהר יותר. אם אתם משתמשים בפלאגינים או בכלים שעוזרים לבצע אוטומציה של שדרוגי יחסי התלות, חשוב לנתח את התוצאות כדי לבדוק אם יש סיכונים. מחזורי פיתוח והשקה ארוכים יותר יש לכם יותר זמן לבצע שדרוגים ולבדוק אותם. סביר להניח שגרסאות חדשות יותר של יחסי התלות יפורסמו במהלך המחזור. החזרה לאחור של שדרוגים והשקה מחדש של האפליקציה או הספרייה נמשכים זמן רב יותר.
איך להתעדכן בתכונות החדשות	האם אתם מעדיפים להשתמש בתכונות ובממשקי ה-API העדכניים ביותר, או לשדרג רק כשאתם צריכים תכונה או תיקון באג? כדאי לשקול את היתרונות והחסרונות של שדרוגים תכופים. שדרוגים עתידיים יהיו קלים יותר (פחות שינויים שצריך לשלב), אבל תצטרכו להסתכן בשדרוגים בתדירות גבוהה יותר. בדיקת שדרוגים לגרסאות טרום-השקה (אלפא, בטא, גרסה מועמדת להשקה) של ספריות יכולה לעזור בהכנה לקראת זמינות של גרסאות יציבות.
תלות חדשה	אם מוסיפים יחסי תלות חדשים, מומלץ לבצע תהליך בדיקה קפדני של הספרייה כדי לבדוק את כל קריטריונים הסיכון שלה, כדי לוודא שהם נבדקו כראוי. לא לאפשר הוספה של יחסי תלות חדשים בלי בדיקה.
צוות ייעודי	האם יש לכם צוות ייעודי ל-build? האם מהנדסי התוכנה שלכם אחראים על התחזוקה של ה-build? לרוב, צוות ייעודי יכול להקדיש יותר זמן לניתוח סיכוני השדרוג ולבדיקת הגרסאות החדשות כדי לוודא שה-build פועל כמו שצריך לפני שהמהנדסים משתמשים בגרסאות החדשות.
סוג השדרוג	יש שדרוגים חשובים יותר מאחרים. כדאי לחשוב אילו תכונות הכי חשובות לכם. בדרך כלל, לשדרוגים של כלי build, כמו Gradle ופלאגינים של Gradle, יש השפעה פחותה על המשתמשים, ורוב הסיכון הוא פנימי ל-build. ה-build עצמו עוזר לאמת את השינויים האלה. קשה יותר לאמת שדרוגים של ספריות ו-SDK, והם מהווים סיכון גבוה יותר למשתמשים. Android Gradle Plugin‏ (AGP) – כלי העבודה המשמשים ליצירת האפליקציה או הספרייה של Android. זהו השדרוג החשוב ביותר שאפשר לבצע, כי הוא כולל לעיתים קרובות או מאפשר שיפורי ביצועים, תיקוני באגים, כללי איתור שגיאות חדשים ותמיכה בגרסאות חדשות של פלטפורמת Android. Gradle – בדרך כלל צריך לשדרג את Gradle כשמשדרגים את AGP או פלאגין אחר של Gradle. פלאגינים אחרים של Gradle – לפעמים ממשק ה-API של הפלאגין של Gradle משתנה. כשמעדכנים את Gradle, כדאי לבדוק אם יש עדכונים לפלאגינים שבהם אתם משתמשים. Kotlin ו-Java – בספריות ובפלאגינים מסוימים נדרשות גרסאות מינימום של Kotlin או Java, או שאתם רוצים לנצל את התכונות החדשות של השפה, ממשקי ה-API או שיפורי הביצועים. פלטפורמת Android – חנות Play דורשת שדרוגים שוטפים של Android SDK. מומלץ לבדוק גרסאות חדשות של Android SDK בהקדם האפשרי. שדרוגים מסוימים של SDK מחייב שינויים באפליקציה, כמו הרשאות חדשות או שימוש בממשקי API חדשים. ספריות – האם אתם רוצים לתת עדיפות לספריות על סמך הקרבה שלהן לארכיטקטורה הכוללת? ספריות שקשורות לפלטפורמה ולארכיטקטורה, כמו AndroidX, משתנות לעיתים קרובות כדי לנצל תכונות חדשות או לעזור בשינויים מופשטים בפלטפורמה. צריך לשדרג את הספריות האלה לפחות בכל פעם שמשדרגים את פלטפורמת Android או ספריות אחרות שקשורות לארכיטקטורה. שדרוגים אחרים של ספריות אפשר לפזר או לדחות, אלא אם אתם זקוקים לתכונה חדשה או לתיקוני באגים ספציפיים. Android Studio – עדכון Android Studio מאפשר לכם לגשת לתכונות ולתיקוני הבאגים האחרונים בפלטפורמה ובכלים הבסיסיים של IntelliJ IDEA, ולעבוד עם ערכות ה-SDK העדכניות ביותר של Android.
כלים זמינים	אם אתם משתמשים בפלאגינים או בכלים שעוזרים לבצע אוטומציה של שדרוגי יחסי התלות, חשוב לנתח את התוצאות כדי לבדוק אם יש סיכונים.

אסטרטגיות לסוגים ספציפיים של שדרוגים

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

איור 1. יצירת קשרים.

כשמשדרגים כל סוג של רכיב, צריך לחשוב איך השדרוג ישפיע על רכיבים אחרים ב-build.

Android Gradle Plugin‏ (AGP)	Android Studio כולל כלי עזר לשדרוג של AGP שיכול לעזור לכם לבצע את המשימות האלה. אם אתם משתמשים במאמן או מבצעים את השדרוג באופן ידני, כדאי לשקול את הנושאים הבאים: הערות הגרסה של APG משדרגים את Gradle לפחות לגרסה שמופיעה ברשימה. משדרגים את Android Studio לגרסה שתומכת בגרסה שנבחרה של AGP. משתמשים בגרסאות של Android Studio ו-AGP שתומכות ב-Android SDK שבו רוצים להשתמש. בודקים את התאימות ל-SDK Build Tools, ל-NDK ול-JDK. אם אתם מפתחים פלאגין של Gradle (לשימוש פנימי או ציבורי) שמרחיב את AGP או משתמש בנתונים ממנו, כדאי לבדוק אם אתם צריכים לשדרג את הפלאגין. לפעמים AGP מפסיקה את השימוש בממשקי API ומסירה אותם מאוחר יותר, מה שגורם לאי-תאימות עם יישומי פלאגין קודמים.
השפה, ה-compiler והזמן הריצה של Kotlin	כדאי לעיין בהערות המוצר של Kotlin כדי לבדוק אם יש בעיות מוכרות או חוסר תאימות. אם אתם משתמשים ב-Jetpack פיתוח נייטיב: אם גרסת Kotlin החדשה נמוכה מ-2.0.0: מוצאים את הפלאגין התואם של Compose compiler. משדרגים את kotlinCompilerExtensionVersion ב-build.gradle.kts של כל המודולים שבהם הוא מופיע. אם גרסת Kotin החדשה היא 2.0.0 ואילך: מגדירים את Compose Compiler Gradle Plugin באותה גרסה כמו של קומפילטור Kotlin. אם אתם משתמשים ב-Kotlin Symbol Processing ‏ (KSP), תוכלו לעיין במאמר מדריך למתחילים בנושא KSP כדי לקבל מידע על ההגדרה, ובמאמר גרסאות KSP כדי לקבל מידע על הגרסאות הזמינות. חשוב לזכור שצריך להשתמש בגרסה של KSP שתואמת לגרסה של Kotlin. לדוגמה, אם אתם משתמשים ב-Kotlin 2.0.21, תוכלו להשתמש בכל גרסה של הפלאגין KSP שמתחילה ב-2.0.21, למשל 2.0.21-1.0.25. בדרך כלל לא תצטרכו לשדרג את מעבדי KSP (כמו הקומפילר של Room, שמופיע כיחס תלות ksp בקובצי ה-build). הפלאגין של KSP מספק הפשטה של חלק גדול מ-API של הקומפילר, ו-KSP API שמשמש את המעבדים יציב. שדרוג של כל יתר הפלאגינים של Kotlin Compiler שבהם אתם משתמשים. ממשק ה-API של פלאגין קומפילר Kotlin משתנה לעיתים קרובות בין גרסאות, והפלאגינים חייבים להשתמש ב-API תואם. אם הפלאגין מופיע בקטע Compiler plugins, צריך להשתמש באותה גרסה כמו של קומפילר Kotlin. לגבי כל פלאגין אחר ל-compile, צריך לבדוק את המסמכים שלו כדי למצוא את המיפוי המתאים. חשוב לזכור שפלאגינים של קומפילטור שלא מתוחזקים לצד קומפילטור Kotlin עצמו לעיתים קרובות מתעכבים בזמן הפרסום שלהם, בזמן שהם ממתינים ליציבות של ה-API של פלאגין הקומפילטור. לפני שמשדרגים את Kotlin, צריך לבדוק אם יש שדרוגים תואמים לכל הפלאגינים של המהדר שבהם אתם משתמשים. לבסוף, במקרים מסוימים השפה של Kotlin משתנה, וצריך לעדכן את הקוד. בדרך כלל זה קורה אם אתם מנסים תכונות ניסיוניות. אם הקוד לא נוצר כראוי אחרי שדרוג המהדר של Kotlin, כדאי לבדוק אם יש שינויים בשפה או שגיאות בספריית זמן הריצה בהערות המוצר של Kotlin.
פלאגינים של קומפילר Kotlin	אם אתם צריכים לשדרג פלאגין של קומפילר Kotlin, עליכם לשדרג לגרסה התואמת של Kotlin שבה אתם משתמשים. רוב הפלאגינים של מהדר Kotlin משתמשים באותה גרסה כמו מהדר Kotlin, או שהם מתחילים בגרסה הנדרשת של מהדר Kotlin. לדוגמה, אם גרסת הפלאגין היא 2.0.21-1.0.25, צריך להשתמש בגרסה 2.0.21 של קומפילטור Kotlin. לפעמים שינוי גרסת המהדר של Kotlin מחייב שינויים אחרים.
ספריות	ספריות הן יחסי התלות הנפוצים ביותר שצריך לשדרג ב-build. השדרוגים הזמינים יופיעו בעורך של Android Studio. בחלק מהספריות מצוין compileSdk או minSdk מינימלי שנדרש כדי להשתמש בספרייה. אם לא משתמשים לפחות ב-compileSdk שצוין, תהליכי ה-build נכשלים. עם זאת, הערך של minSdk באפליקציה מוגדר באופן אוטומטי לערך המקסימלי של כל ערכי minSdk שצוינו בקבצי ה-build וביחסי התלות בספרייה. בחלק מהספריות מצוין גם גרסת Kotlin מינימלית לשימוש. מעדכנים את הגרסה של Kotlin בקובצי ה-build כך שתהיה לפחות הגרסה שצוינה.
Gradle	לפעמים גרסאות חדשות של Gradle מבטלות את התמיכה בממשקי API קיימים, ומסירות אותם בגרסה עתידית. אם אתם מפתחים פלאגין של Gradle, כדאי לשדרג את הפלאגין בהקדם האפשרי, במיוחד אם הפלאגין הזה הוא ציבורי. חלק מהשדרוגים של Gradle דורשים לאתר גרסאות חדשות של הפלאגינים שבהם אתם משתמשים. חשוב לזכור שהפלאגינים האלה עשויים להתעכב בפיתוח שלהם בזמן שהם משדרגים את הפלאגינים כך שיתאימו לממשקי ה-API העדכניים ביותר של פלאגינים של Gradle. כדי לשדרג את Gradle: קוראים את נתוני הגרסה של הגרסה שבה רוצים להשתמש. משדרגים את גרסת Gradle בקובץ gradle/wrapper/gradle-wrapper.properties. מריצים את הפקודה ./gradlew wrapper --gradle-version latest כדי לשדרג את קובץ ה-jar ואת הסקריפטים של Gradle wrapper. משדרגים את הפלאגינים של Gradle. משדרגים את JDK שמשמש להרצת Gradle.
פלאגינים של Gradle	לפעמים, פלאגינים משודרגים של Gradle משתמשים בממשקי API חדשים או משתנים של Gradle, שדורשים שדרוג של Gradle או אולי שינויים בתצורה שלהם בקובצי ה-build. בכל מקרה, יוצגו אזהרות או שגיאות ב-build כדי לציין את חוסר התאימות. בכל פעם שמשדרגים פלאגינים, צריך לשדרג גם את Gradle.
Android SDK	ב-Android Studio יש כלי לשדרוג Android SDK שיכול לעזור במשימות האלה. אם אתם משתמשים במאמן או מבצעים את השדרוג באופן ידני, כדאי לשקול את הנושאים הבאים: כל גרסה של Android SDK כוללת תכונות וממשקי API חדשים, תיקוני באגים ושינויים בהתנהגות. חובה לעדכן את targetSdk בחנות Play, אבל מומלץ לעדכן את targetSdk לפני המועדים הסופיים כדי שיהיה לכם מספיק זמן לבצע את השינויים הנדרשים. לפני שמשדרגים את Android SDK, חשוב לקרוא בעיון את הערות המוצר. חשוב לשים לב לקטע 'שינויים בהתנהגות', שכולל את הפרטים הבאים: הרשאות חדשות שתצטרכו לבקש בזמן ההתקנה או בזמן הריצה. ממשקי API שהוצאו משימוש והחלופות שלהם. שינויים משמעותיים בממשקי API או בהתנהגות. ממשקי API חדשים של Kotlin או Java, שעשויים להשפיע על הקוד שלכם. הקטע 'שינויים בהתנהגות' יכול להיות ארוך למדי, אבל חשוב להקדיש לו תשומת לב רבה כי לרוב הוא מכיל שינויים קריטיים שצריך לבצע באפליקציה. צריך לשדרג את targetSdk כדי לעמוד בדרישות של חנות Play. השדרוג של compileSdk הוא אופציונלי, והוא מעניק גישה לממשקי API חדשים. חשוב לזכור שספריות מסוימות, כמו AndroidX, כוללות דרישת compileSdk מינימלית. כדי ליהנות מהפיצ'רים החדשים של ה-SDK במהלך הפיתוח ולהבטיח תאימות במהלך ה-build, צריך לשדרג את הפלאגין של Android Gradle ‏ (AGP) ואת Android Studio. אלה כוללים כלים חדשים ומשופרים ל-SDK חדשים. גרסאות מינימום של כלים לרמת API של Android כשמשדרגים את Android SDK, צריך לשדרג את כל ספריות AndroidX שבהן אתם משתמשים. ב-AndroidX נעשה לעיתים קרובות שימוש בממשקי API חדשים ומעודכנים כדי לשפר את התאימות והביצועים בגרסאות השונות של Android SDK.
Android Studio	באופן כללי, אפשר לשדרג את Android Studio בכל שלב. יכול להיות שיוצגו לכם הודעות עם בקשה לשדרג את AGP או לשדרג את Android SDK. מומלץ מאוד לבצע את השדרוגים האלה, אבל זו לא חובה. אם תרצו להשתמש ב-Android Studio כדי לשדרג את AGP או את Android SDK בשלב מאוחר יותר, תוכלו למצוא את האפשרויות האלה בתפריט Tools: כלי לשדרוג של APG… הכלי לשדרוג Android SDK…
Java	אם יש לכם קוד מקור של Java באפליקציית Android, כדאי לכם להשתמש בממשקי API חדשים יותר של Java. כל גרסה של Android SDK תומכת בקבוצת משנה של ממשקי API של Java ובתכונות שפה. AGP מספק תאימות לגרסאות ישנות יותר של Android SDK באמצעות תהליך שנקרא desugaring. הערות המוצר של Android SDK מציינות את רמת Java הנתמכת ובעיות פוטנציאליות. חלק מהבעיות האלה עשויות להשפיע גם על קוד המקור של Kotlin, כי ל-Kotlin יש גישה לאותם ממשקי API של Java. חשוב לשים לב במיוחד לקטע JDK API שמופיע בקטע 'שינויים התנהגותיים' בנתוני הגרסה, גם אם אין לכם קוד מקור של Java. השימוש ב-JDK מצוין בכמה מקומות בסקריפטים ל-build. מידע נוסף זמין במאמר גרסאות Java ב-Android build.

ניתוח שדרוגים

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

• שינוי הקוד עקב שינויים ב-API?
• להוסיף בדיקות הרשאות חדשות?
• ליצור בדיקות נוספות או לשנות בדיקות קיימות כדי לזהות שינויים בהתנהגות?

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

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

המפתח לשדרוגים מוצלחים הוא ניתוח השדרוג:

1. לבדוק את ההבדלים ביחסי התלות לפני ואחרי השדרוגים.
2. בודקים כל שינוי ומזהים את הסיכונים הכרוכים בו.
3. לצמצם את הסיכונים או לאשר או לדחות שינויים.

זיהוי הבדלים ביחסי התלות

השלב הראשון בניתוח השדרוג הוא לקבוע איך יחול שינוי ביחסי התלות. כדאי להשתמש בניהול גרסאות (VCS, כמו Git) ובפלאגין Dependency Guard כדי לראות שינויים במהירות. המטרה היא ליצור קובץ snapshot לפני ואחרי השינוי ולהשוות ביניהם.

זהירות: Dependency Guard הוא פלאגין של Gradle של צד שלישי. גורמים זדוניים יכולים לפגוע בפלאגינים חיצוניים באמצעות התקפות אדם בתווך (MITM) או דרך שרת פיתוח שנפרץ. מומלץ מאוד להפעיל את אימות יחסי התלות כדי לאמת את יחסי התלות שאתם מורידים וכוללים בפרויקט.

הגדרה ויצירה של קו הבסיס הראשון

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

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

• Lint

  • כדי להתייחס לאזהרות כאל שגיאות, מוסיפים

  android {
      // ...
      lint {
          warningsAsErrors = true
      }
  }
  

  ל-build.gradle.kts בכל מודול.

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

• קומפילטור Kotlin: מפעילים את -Werror כדי להתייחס לכל האזהרות כשגיאות. איך מגדירים אפשרויות

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

בעזרת קווים בסיסיים של אזהרות קל יותר לראות אזהרות חדשות שמופיעות במהלך השדרוג של יחסי התלות. אפשר לראות שינויים ביחסי התלות ובגרסאות שלהם באמצעות Dependency Guard.

בקטלוג הגרסאות gradle/libs.versions.toml, מוסיפים את הפרטים הבאים:

[versions]
dependencyGuard = "0.5.0"

[plugins]
dependency-guard = { id = "com.dropbox.dependency-guard", version.ref = "dependencyGuard" }

מוסיפים את הטקסט הבא לקובץ ה-build של האפליקציה:

Kotlin

plugins {
    alias(libs.plugins.dependency.guard)
}

dependencyGuard {
    configuration("releaseRuntimeClasspath")
}

Groovy

plugins {
    alias(libs.plugins.dependency.guard)
}

dependencyGuard {
    configuration('releaseRuntimeClasspath')
}

ההגדרה releaseRuntimeClasspath היא יעד סביר, אבל אם רוצים להשתמש בהגדרה אחרת, מריצים את ./gradlew dependencyGuard בלי הגדרה שמופיעה בקובץ ה-build כדי לראות את כל ההגדרות הזמינות.

אחרי ההגדרה, מריצים את הפקודה ./gradlew dependencyGuard כדי ליצור דוח ב-app/dependencies/releaseRuntimeClasspath.txt. זהו הדוח הבסיסי. כדי לשמור את השינויים, צריך לבצע השמירה במערכת בקרת הגרסאות (VCS).

חשוב לזכור ש-Dependency Guard מתעד רק את רשימת יחסי התלות בספריות. יש יחסי תלות אחרים בקובצי ה-build, כמו גרסאות Android SDK ו-JDK. ביצוע השמירה במערכת ה-VCS לפני ששינויים ביחסי התלות מאפשרים להדגיש את השינויים האלה גם ב-diff של מערכת ה-VCS.

שדרוג והשוואה לערך הבסיס

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

מריצים את ./gradlew lint כדי לראות אזהרות או שגיאות חדשות של איתור שגיאות בקוד. פותרים את הבעיות החשובות ומריצים את הפקודה ./gradlew lint -Dlint.baselines.continue=true כדי לעדכן את ערך הבסיס של ההתראות. אם השתמשתם בכלים אחרים כדי לתעד את ערכי הבסיס של ההתראות, עליכם לטפל בהתראות חדשות ולעדכן גם את ערכי הבסיס שלהן.

מריצים את הפקודה ./gradlew dependencyGuard כדי לעדכן את דוח הבסיס. לאחר מכן מריצים את ההבדלים ב-VCS כדי לראות שינויים שלא קשורים לספרייה. סביר להניח שהיא תכלול הרבה יותר שדרוגים של הספרייה ממה שחשבתם.

ניתוח הסיכונים

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

כמה שיקולים:

שדרוגים של גרסאות ראשיות	האם מספר הגרסה הראשית השתנה? במיקום גרסאות סמנטי, המספר הראשון נקרא הגרסה הראשית. לדוגמה, אם הגרסה של ספרייה שודרגה מ-1.2.3 ל-2.0.1, הגרסה הראשית השתנתה. בדרך כלל, המשמעות היא שמפתח הספרייה ביצע שינויים לא תואמים בין הגרסאות, כמו הסרה או שינוי של חלקים ב-API. אם מופיעה ההודעה הזו, חשוב לשים לב במיוחד לספריות שהושפעו כשבודקים את השיקולים הבאים. אם הקוד שלכם משתמש בממשקי API ניסיוניים (שדרושה הסכמה לשימוש בהם באמצעות הערות או מפרטי קובץ build), גם שינויים קלים בגרסה או תיקון של גרסה, כמו שדרוג מ-1.2.3 ל-1.3.1 או מ-1.2.3 ל-1.2.5, עלולים להוות סיכונים נוספים.
ממשק API לא יציב	חלק מהגרסאות של הספריות עשויות לכלול ממשקי API לא יציבים. בדרך כלל מדובר בממשקי API שנמצאים בתהליך פיתוח או תלויים בממשק API לא יציב אחר. בדרך כלל, ספריות כאלה מוגבלות לגרסאות מקדימות, כמו גרסאות אלפא, גרסאות פיתוח או גרסאות ניסיוניות, אבל יש ספריות שכוללות ממשקי API שמסומנים כניסיוניים או לא יציבים. אם אפשר, כדאי להימנע מממשקי API כאלה. אם אתם צריכים להשתמש בהם, הקפידו לתעד את השימוש שלכם ולבדוק אם יש שינויים או הסרות במהדורות מאוחרות יותר.
התנהגות דינמית	ספריות מסוימות פועלות בצורה שונה בהתאם לגורמים חיצוניים. לדוגמה, ספרייה שמתקשרת עם שרת תלויה בשינויים בשרת הזה. האם הספרייה צריכה להתאים לגרסה מסוימת של השרת? האם הספרייה יכולה להתחבר לגרסאות שונות של שרת? האם גורם חיצוני אחר משפיע על ההתנהגות הנכונה של הספרייה?
מיזוג מניפסטים	ספריות שפורסמו כקובצי Android Archives ‏ (AAR) יכולות להכיל משאבים ומניפסטים שמוזגו לאפליקציה. רכיבים כאלה יכולים להוסיף הרשאות חדשות ורכיבי Android חדשים, כמו פעילויות או מקלטי שידורים, שפועלים באופן עקיף.
עדכונים בזמן ריצה	בחלק מהספריות נעשה שימוש בתכונות שאפשר לעדכן מחוץ לאפליקציה. ספרייה עשויה להשתמש ב-Play Services, שמשודרג בנפרד מ-Android SDK. ספריות אחרות עשויות לקשר לשירותים באפליקציות חיצוניות שמתעדכנות בנפרד (לרוב באמצעות AIDL).
כמה גרסאות אתם מדלגים עליהן?	ככל שממתינים יותר זמן לשדרוג ספרייה, כך עולים הסיכונים הפוטנציאליים. אם אתם רואים שינוי משמעותי בגרסה, למשל מ-1.2.3 ל-1.34.5, כדאי להקדיש תשומת לב מיוחדת לספרייה הזו.
מדריכים להעברת נתונים (מיגרציה)	בודקים אם יש בספרייה מדריך להעברת נתונים. כך תוכלו לצמצם באופן משמעותי את ניתוח הסיכונים ואת תכנון הפחתת הסיכון. חשוב לזכור: אם יש מדריך כזה, סימן שהמפתח התמקד בתאימות והביא בחשבון את הצורך בצמצום ההשפעה של השדרוג.
נתוני גרסה	קוראים את נתוני הגרסה (אם הם זמינים) של כל ספרייה שעברה שינוי. מחפשים סימנים לשינויים שגורמים לשיבושים או לדרישות חדשות, כמו הרשאות שנוספו.
קובצי README	בחלק מקובצי ה-README של ספריות מפורטים סיכונים פוטנציאליים, במיוחד אם בספרייה לא מוצגים תיאורי גרסאות. מחפשים _בעיות ידועות_, במיוחד בעיות אבטחה ידועות.
בדיקת נקודות חולשה ידועות	ב-Play SDK Index מתבצע מעקב אחרי נקודות חולשה בערכות SDK פופולריות רבות. מערכת Play Console מדווחת אם אתם משתמשים באחת מערכות ה-SDK הרשומים עם נקודות חולשה ידועות. כשעורכים קובצי build ב-Android Studio, סביבת הפיתוח המשולבת בודקת את מדד ה-SDK ומסמנת שימוש בגרסאות ספרייה חשופות. המכון הלאומי לתקנים וטכנולוגיה (NIST) מנהל מסד נתונים לאומי של נקודות חולשה (NVD). הפלאגין Dependency Check ל-Gradle בודק את יחסי התלות שבהם אתם משתמשים מול NVD. כדי להשתמש ב-Dependency Check, מבקשים מפתח API של NVD, מגדירים את הפלאגין של Gradle ומריצים את ./gradlew dependencyCheckAnalyze. לתשומת ליבכם, הפעולה הזו עשויה להימשך זמן רב. זהירות: Dependency Check הוא פלאגין של Gradle של צד שלישי. גורמים זדוניים יכולים לפגוע בפלאגינים חיצוניים באמצעות התקפות אדם בתווך או דרך שרת פיתוח שנפרץ. מומלץ מאוד להפעיל את אימות יחסי התלות כדי לאמת את יחסי התלות שאתם מורידים וכוללים בפרויקט.
התנגשויות בין גרסאות	האם הגרסאות נפתרות כמצופה? מחפשים קונפליקטים, במיוחד הבדלים משמעותיים בגרסאות. במאמר פתרון יחסי התלות ב-Gradle מוסבר איך לחפש התנגשויות. באופן ספציפי, מחפשים את -> בדוח ./gradlew app:dependencies. כשהדבר אפשרי, כדאי לעבוד עם מחברי יחסי התלות כדי לפתור את הבעיות. אם החברה מאפשרת זאת, אפשר לתרום שינויים לספרייה (העלאה ל-upstream) כדי לשפר את התאימות שלה.
בדיקת הרישיונות	כשמשדרגים ספרייה, חשוב לבדוק אם יש שינויים ברישיונות. יכול להיות שהספרייה עצמה תשתנה לרישיון שלא תואם יותר לאפליקציה או לספרייה שלכם. יחסי תלות טרנזיטיביים חדשים עלולים גם להציג רישיונות לא תואמים. במאמר אימות רישיונות מוסבר איך בודקים את קבוצת הרישיונות הנוכחית בכל יחסי התלות.
סיכוני תחזוקה ואיכות	בספריות עם מאגרים ציבוריים: כמה שותפים מנהלים את הספרייה? מתי בוצע השדרוג האחרון, ותדירות השינוי בספרייה? איך נראה עומס הבקשות הפתוחות (אם יש כזה)? כדאי לקרוא אותו בעיון כדי לקבל מושג על בעיות פוטנציאליות ועל החוב הטכני של הספרייה. עד כמה בדיקות היחידה מכסות את הספרייה? האם יש דפוסים שליליים מוכרים בקוד? האם הספרייה מתועדת היטב? האם יש הרבה תגובות _fixme_ בקוד?
קוד פתוח לעומת קוד סגור	אם הספרייה היא קוד פתוח, קל יותר לנפות באגים בהשוואה לקוד סגור, בין שהבעיות נמצאות בקוד שלכם ובין שהן נמצאות בקוד הספרייה. צמצום יחסי התלות במקורות סגורים והקפדה על בדיקה נוספת במהלך ההערכה שלהם. האם יש חלופות טובות שמתאימות לתרחיש לדוגמה שלכם? אילו הסכמי רמת שירות זמינים לספריות מקוד מקור סגור? אם בוחרים להשתמש בספרייה של קוד סגור, צריך להיות מוכנים לכתוב עוד תרחישי בדיקה כדי לצמצם את הסיכונים.

הרצת build

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

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

שימוש ב-lint כדי לזהות בעיות ב-API

Android lint יכול לזהות בעיות רבות באפליקציה, כולל בעיות שנובעות מגרסאות משתנות של יחסי התלות או של Android SDK. לדוגמה, אם משדרגים את compileSdk ומשתמשים בממשקי ה-API החדשים שלו, הכלי יזהה את ממשקי ה-API שלא זמינים בגרסאות קודמות של ה-SDK.

Lint פועל בעורך של Android Studio, ומדווח על בעיות בזמן ביצוע השינויים. אבל בדרך כלל הוא לא פועל כחלק מה-build ב-Studio או כשמריצים build בשורת הפקודה, אלא אם משתמשים ביעדים build או lint.

אם אתם משתמשים ב-Continuous Integration (CI), כדאי להריץ את gradlew build או את gradlew lint במהלך ה-builds של ה-CI (או לפחות ב-builds היומיים) כדי לזהות את סוגי השגיאות האלה.

אם אתם לא משתמשים ב-CI, חשוב להריץ את gradlew lint לפחות מדי פעם.

הערה: כללי איתור שגיאות כלליים וכללי איתור שגיאות ברמת Android SDK מסופקים עם AGP, וכללים ספציפיים לספריות נארזים עם הספריות שלהם. חשוב לוודא ש-AGP ויחסי התלות בספריות עדכניים ככל האפשר, כדי לוודא שכללי האיתור של שגיאות בקוד (lint) העדכניים ביותר חלים על הקוד שלכם. חשוב במיוחד לעשות זאת לגבי כללי איתור שגיאות בקוד חדשים שנוספו או שודרגו לגרסה חדשה של Android SDK.

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

צמצום סיכונים

אחרי שבודקים את הסיכונים בשדרוג, מחליטים איך לצמצם אותם:

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

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

אימות רישיונות

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

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

אם רישיון לא תואם (או שהשתנה כך שהוא כבר לא תואם), אי אפשר להשתמש בגרסה הזו של הספרייה. אפשר:

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