במסמך הזה מוצגת סקירה כללית של פעולות הפיתוח והבדיקה שאתם יכולים לבצע כדי להתאים את עצמכם ללוח הזמנים של השקת פלטפורמת Android, ולהבטיח חוויית משתמש חלקה ב-Android 17.
כל גרסה של Android מגיעה עם תכונות חדשות ושינויים בהתנהגות שנועדו לשפר את היעילות, האבטחה והביצועים של Android. במקרים רבים האפליקציה שלכם תפעל מההתחלה בדיוק כמו שציפיתם, אבל לפעמים אולי תצטרכו לעדכן אותה בהתאם לשינויים בפלטפורמה.
המשתמשים יכולים לקבל גישה לפלטפורמה החדשה ברגע שקוד המקור שלה מתפרסם ב-AOSP (פרויקט קוד פתוח של Android). לכן חשוב שהאפליקציות שלכם יהיו מוכנות, יפעלו כמצופה אצל המשתמשים וינצלו את התכונות החדשות ואת ממשקי ה-API כדי למקסם את השימוש בפלטפורמה החדשה.
העברה טיפוסית כוללת שני שלבים, שיכולים להתבצע בו-זמנית:
- מוודאים שהאפליקציה תואמת (עד לגרסה הסופית של Android 17)
- טירגוט התכונות וממשקי ה-API החדשים של הפלטפורמה (בהקדם האפשרי אחרי הגרסה הסופית)
מוודאים תאימות ל-Android 17
חשוב לבדוק את הפונקציונליות של האפליקציה הקיימת ב-Android 17 כדי לוודא שהמשתמשים שיעדכנו לגרסה העדכנית של Android ייהנו מחוויית שימוש טובה. חלק מהשינויים בפלטפורמה יכולים להשפיע על האופן שבו האפליקציה פועלת, לכן חשוב לבדוק אותה בשלב מוקדם ובאופן יסודי, ולבצע את כל השינויים הנדרשים.
בדרך כלל אפשר לשנות את האפליקציה ולפרסם עדכון בלי לשנות את targetSdkVersion של האפליקציה. באופן דומה, לא אמור להיות צורך להשתמש בממשקי API חדשים או לשנות את ה-compileSdkVersion של האפליקציה, אבל זה תלוי באופן שבו האפליקציה בנויה ובפונקציונליות של הפלטפורמה שבה היא משתמשת.
לפני שמתחילים לבדוק, חשוב להכיר את השינויים בהתנהגות של כל האפליקציות. השינויים האלה עשויים להשפיע על האפליקציה, גם אם לא משנים את ה-targetSdkVersion שלה.
צורבים קובץ אימג' של מערכת Android 17 במכשיר, או מורידים קובץ אימג' של המערכת לאמולטור Android.
בודקים את השינויים בהתנהגות המערכת כדי לזהות אזורים שבהם האפליקציה עשויה להיות מושפעת.
מתקינים את האפליקציה במכשיר או באמולטור ומריצים בדיקות. חשוב להתמקד בשינויים בהתנהגות המערכת ולבדוק את כל תהליכי העבודה באפליקציה.
מבצעים בקוד רק את השינויים שנדרשים כדי להתאים לשינויים בהתנהגות או כדי לפתור בעיות. צריך לבצע קומפילציה מחדש עם אותה רמת API שהאפליקציה טירגטה במקור – אין צורך לטרגט ל-Android 17.
חותמים על קובץ ה-Android App Bundle או ה-APK המעודכן, מעלים אותו ומפרסמים אותו.
בדיקת התאימות של האפליקציה ל-Android 17
ברוב המקרים, בדיקת התאימות ל-Android 17 דומה לבדיקת אפליקציות רגילה. זה זמן טוב לעיין בהנחיות הבסיסיות לאיכות האפליקציה ובשיטות המומלצות לבדיקה.
כדי לבדוק, מתקינים את האפליקציה שפורסמה במכשיר עם Android 17, ועוברים על התהליכים והפונקציונליות כדי לזהות בעיות. כדי להתמקד בבדיקות, עיינו בשינויים בהתנהגות של כל האפליקציות שהוצגו ב-Android 17, שיכולים להשפיע על אופן הפעולה של האפליקציה או לגרום לה לקרוס.
חשוב גם לבדוק אם יש שימוש בממשקים מוגבלים שאינם SDK. צריך להחליף כל ממשק מוגבל שהאפליקציה משתמשת בו בממשק מקביל ציבורי של SDK או NDK. כדאי לשים לב לאזהרות של logcat שמדגישות את הגישות האלה, ולהשתמש ב-StrictMode method detectNonSdkApiUsage() כדי לתפוס אותן באופן פרוגרמטי.
לבסוף, חשוב לבדוק באופן מלא את הספריות וערכות ה-SDK באפליקציה כדי לוודא שהן פועלות כצפוי ב-Android 17, ולפעול לפי השיטות המומלצות בנושא פרטיות, ביצועים, חוויית משתמש, טיפול בנתונים והרשאות. אם נתקלתם בבעיה, נסו לעדכן לגרסה העדכנית של ה-SDK או לפנות למפתח ה-SDK לקבלת עזרה.
אחרי שמסיימים את הבדיקות ומבצעים את העדכונים, מומלץ לפרסם את האפליקציה התואמת באופן מיידי. כך המשתמשים יוכלו לבדוק את האפליקציה בשלב מוקדם, והמעבר ל-Android 17 יהיה חלק יותר כשהם יעדכנו את המכשיר.
מעדכנים את הטירגוט של האפליקציה ויוצרים אותה עם ממשקי API חדשים
אחרי שמפרסמים גרסה תואמת של האפליקציה, השלב הבא הוא להוסיף תמיכה מלאה ב-Android 17. כדי לעשות את זה, צריך לעדכן את targetSdkVersion של האפליקציה ולהשתמש בממשקי ה-API וביכולות החדשים של Android 17.
אתם יכולים לבצע את העדכונים האלה מתי שתרצו, אבל חשוב לזכור את הדרישות של Google Play לטירגוט הפלטפורמה החדשה.
כשאתם מתכננים את העבודה כדי לתמוך באופן מלא ב-Android 17, כדאי לעיין בשינויים בהתנהגות שמשפיעים על אפליקציות שמטרגטות ל-Android 17. השינויים הממוקדים האלה בהתנהגות עלולים לגרום לבעיות פונקציונליות שתצטרכו לטפל בהן. בחלק מהמקרים, השינויים האלה דורשים פיתוח משמעותי, ולכן מומלץ ללמוד עליהם ולטפל בהם כמה שיותר מוקדם. כדי לזהות שינויים ספציפיים בהתנהגות שמשפיעים על האפליקציה, אתם יכולים להשתמש במתגי התאימות כדי לבדוק את האפליקציה כשהשינויים שנבחרו מופעלים.
בשלבים הבאים מוסבר איך לתמוך באופן מלא ב-Android 17.
כדי ליצור אפליקציות ל-Android 17, צריך להתקין את הגרסה העדכנית של Android Studio Preview. עליכם לוודא שיש לכם מכשיר או אמולטור עם Android 17.
מעדכנים את targetSdkVersion ואת ההגדרות האחרות של
הגרסה.
בודקים את השינויים בהתנהגות שרלוונטיים לאפליקציות שמטרגטות ל-Android 17. מזהים את האזורים שבהם האפליקציה עשויה להיות מושפעת, ומתכננים איך לתמוך בהם.
מבצעים את השינויים הנדרשים בקוד ובארכיטקטורה כדי לתמוך בשינויים בפרטיות המשתמשים ב-Android 17.
כדאי להשתמש בממשקי ה-API של Android 17 כדי להוסיף תכונות ויכולות חדשות לאפליקציות. לקמפל מחדש ל-Android 17.
בודקים במכשיר או באמולטור עם Android 17. חשוב להתמקד באזורים שבהם שינויים בהתנהגות עשויים להשפיע על האפליקציה. כדאי לנסות פונקציונליות שמשתמשת בממשקי API חדשים. לשלוח משוב על הפלטפורמה ועל ה-API. לדווח על בעיות בפלטפורמה, ב-API או בערכת SDK של צד שלישי.
אחרי שממשקי ה-API של Android 17 יהיו סופיים, מעדכנים שוב את targetSdkVersion ואת תצורות ה-build האחרות, מבצעים עדכונים נוספים ובודקים את האפליקציה.
חותמים על קובץ ה-Android App Bundle או ה-APK המעודכן, מעלים אותו ומפרסמים אותו.
הורדת ה-SDK, שינוי הטירגוט, פיתוח באמצעות ממשקי API חדשים
כדי להתחיל לבדוק את התמיכה המלאה ב-Android 17, צריך להוריד את Android 17 SDK וכלים אחרים שנדרשים באמצעות גרסת טרום-ההשקה (Preview) העדכנית של Android Studio. בשלב הבא, מעדכנים את targetSdkVersion ו-compileSdkVersion של האפליקציה, ומקמפלים אותה מחדש. פרטים נוספים זמינים במדריך להגדרת SDK.
בדיקת האפליקציה ב-Android 17
אחרי שיוצרים את האפליקציה ומתקינים אותה במכשיר עם Android 17, מתחילים לבדוק אותה כדי לוודא שהיא פועלת כמו שצריך כשהיא מטרגטת ל-Android 17. חלק מהשינויים בהתנהגות חלים רק כשהאפליקציה מטרגטת את הפלטפורמה החדשה, לכן כדאי לבדוק את השינויים האלה לפני שמתחילים.
כמו בבדיקת התאימות הבסיסית, צריך לעבור על כל התהליכים והפונקציונליות ולחפש בעיות. חשוב להתמקד בבדיקות של השינויים בהתנהגות של אפליקציות שמטרגטות ל-Android 17. זה גם זמן טוב לבדוק את האפליקציה לפי הנחיות האיכות לאפליקציות והשיטות המומלצות לבדיקה.
חשוב לבדוק אם יש שימושים בממשקים מוגבלים שאינם SDK שעשויים להיות רלוונטיים. כדאי לשים לב לאזהרות של logcat שמדגישות את הגישות האלה, ולהשתמש בשיטה StrictMode detectNonSdkApiUsage() כדי לתפוס אותן באופן פרוגרמטי.
לבסוף, חשוב לבדוק באופן מלא את הספריות וערכות ה-SDK באפליקציה כדי לוודא שהן פועלות כצפוי ב-Android 17, ולפעול לפי השיטות המומלצות בנושא פרטיות, ביצועים, חוויית משתמש, טיפול בנתונים והרשאות. אם נתקלתם בבעיה, נסו לעדכן לגרסה העדכנית של ה-SDK או לפנות למפתח ה-SDK לקבלת עזרה.
בדיקה באמצעות מתגי תאימות של אפליקציות
ב-Android 17 יש מתגים שמאפשרים לבדוק בקלות את האפליקציה עם שינויים ממוקדים בהתנהגות. באפליקציה שניתן לנפות בה באגים, המתגים מאפשרים:
- לבדוק שינויים ממוקדים בלי לשנות בפועל את targetSdkVersion של האפליקציה. אתם יכולים להשתמש במתגים כדי לחייב הפעלה של שינויים ספציפיים בהתנהגות של גרסת ה-Target SDK, וכך להעריך את ההשפעה על האפליקציה הקיימת.
- התמקדו בבדיקה של שינויים ספציפיים בלבד. במקום לטפל בכל השינויים המטורגטים בבת אחת, המתגים מאפשרים להשבית את כל השינויים המטורגטים מלבד אלה שרוצים לבדוק.
- ניהול מתגים באמצעות adb. אתם יכולים להשתמש בפקודות adb כדי להפעיל ולהשבית את השינויים שניתנים להפעלה והשבתה בסביבת הבדיקה האוטומטית שלכם.
- ניפוי באגים מהיר יותר באמצעות מזהי שינויים סטנדרטיים. לכל שינוי שניתן להפעלה או להשבתה יש מזהה ושם ייחודיים, שבעזרתם אפשר לנפות באגים במהירות כדי למצוא את שורש הבעיה בפלט של היומן.
המתגים יכולים לעזור לכם להתכונן לשינוי הטירגוט של האפליקציה, או בזמן שאתם מפתחים באופן פעיל תמיכה ב-Android 17. מידע נוסף זמין במאמר שינויים במסגרת התאימות (Android 17).